[PyCon] PyCon 2024 후기

 

반응형

파이콘 10주년 기념

 

소개

🔗 파이콘(PyCon)

https://2024.pycon.kr/

파이콘 한국 2024

• 날짜: 2024년 10월 26일 - 27일
• 장소: 수원 컨벤션센터 3층

• 세션 시간표

1일차

2일차

---

인증샷1

 

인증샷2

 

같은 날 수원 컨벤션센터에서는 펫축제가 열리고 있어서 많은 강아지들이 가득가득

눈으로 귀여움을 잔뜩 담고 3층으로 이동하니, 접수처와 많은 후원사 부스들이 있었다.

 

접수처에서는 이름표와 많은 굿즈들을 주었고 티켓 구매 했을 때 함께 구매한 티셔츠도 함께 수령할 수 있었다.

그리고 옆에서는 티셔츠, 후드집업 등 다양한 굿즈들을 추가 판매하고 있었는데 후드 집업이 너무 예뻐서 바로 구매!

후드집업 인증샷

 

토스, 크림, 두레이 등 다양한 후원사 부스에서 이벤트 참여하고 선물도 많이 받아왔다.

추가적으로 커뮤니티에서도 다양한 행사들을 홍보해서 나중에 참여해보려고 안내 책자들도 잔뜩 받아와서 두손 가득 짐을 들고 행사에 참여했다.

 

행사는 동일한 시간에 3개의 홀에서 각각 다른 세션을 발표하는 방식으로 진행됐다.

미리 공개된 세션 발표 주제를 보고, 본인이 흥미있고 궁금한 세션을 들으러 가면 된다.

 

나는 양일 모두 참석했고, 다음과 같은 세션에 참석하였다.

주니어이자, 자바 개발자인 나는 모르는 내용이 가득했지만 모두가 눈이 반짝반짝한 채로 열정 가득히 발표를 하고 세션을 경청하는 모습에 덩달아 기분 좋은 자극이 되었고 파이썬이 어떠한 언어이고, 어떻게 쓰이는 지에 대해 조금이나마 이해할 수 있는 계기가 되었다.

---

1일차

⌜S⌟SDLC - Integrating AI for Proactive Security in Python Development

🗣️ 심의팅 / Noflag

 

1. The Power of code security & AI

• OWASP TOP 10 ISSUE

2. Insecure Coding in Python

• Unsafe programming - RCE, SQLI, Pickle module unsafely deserializes objects, unexpected behavior

3. Leveraging AI for Vulnerability Detection

• Baking a generative AI Application
• About fine-tune
• Cloud Setting
• About RAG
• Choosing a method for training your model
• Safety filtering per request
• Local RAG with Gemma: 7B

4. Importance of SSDLC an Closing Remarks

• when will the information security vuln be fixed?
• Risk level
  • High : Lower probability. Higher risk if it occurs
  • Low: Low probability and low risk
  • Critical: High probability and High risk of impact
  • Medium: High probability but low risk
• Creating a secure program development cycle: gatekeeping at every step ..

---

FastAPI with Dependency Injector

🗣️ 한바름

 

1. 의존성 주입, 의존성 주입 프레임워크

• 의존성 주입
  • 소프트웨어 개발에서 중요한 디자인 패턴
  • 객체 지향 프로그램에서 객체 간의 의존성을 관리하는 방법
  • 객체는 자신이 필요한 의존성을 외부에서 주입 받을 수 있음
  • 코드의 재사용성이 높아지고, 테스트 가능성과 유지보수성이 크게 향상
• 도우미 함수(helper function)
  • def bbbb (aaaa: Callable = xxxx) -> …
• 파이썬은 함수도 객체이기 때문에, 클래스 외에도 함수에 의존성 주입도 가능
  • 하나의 함수로 다양한 세션 적용 가능
  • 재사용/관리 가능
• 의존성 주입 도입 결과
  • 의존성 객체가 어떻게 생성되는지 몰라도 됨
  • 의존성 객체 변경이 클라이언트 객체에 영향이 없음 (=결합도 낮아짐)
  • 의존성 객체의 라이프 사이클이 클라이언트 객체와 분리
  • 의존성이 변하는 케이스 대응
    • 클래스 생성자 Args 변경
      • Engine() → Engin(fule_type=”Gasoline”)
    • 클래스 타입의 변경

2. 의존성 주입 시 달라지는 점

• 의존성 외부에서 관리 (기존: 클라이언트 객체 생성만 하면, 의존성은 내부에서 생성)
• 의존성 객체 라이프 사이클 관리 (기존: 클라이언트 객체 스코프에 의존성 객체 라이프사이클 종속)
• 도우미 함수 필요 (선택)

3. 의존성 주입 프레임워크란?

• 의존성 주입 편의성 지원
• 의존성 생성 관리(초기화 정보들, 의존성 생성타입)
• 의존성 및 의존성이 주입된 객체 생성 역할

4. FastAPI의 의존성 주입

• Depends()
  • 개념
    • 의존성 생성 함수 등록
    • 의존성 필요 시 의존성 생성 함수 호출
    • Caching 지원
    • 요청 처리 시 중복 로직 처리
  • 단점
    • FastAPI 종속
    • Depends 사용한 의존성 주입만 교체 지원
• Dependency Injector
  • 장점
    • 상세한 문서
    • 의존성 주입 다양한 케이스 지원
    • FastAPI 비종속
  • 단점
    • 러닝커브 존재
    • 에러 지원 빈약
    • FastAPI Depends() 완전한 대체는 아님

5. 적용후기 및 정리

• 이슈
  • 완전한 프레임워크는 아님
  • 컨테이너 사용하는 모듈간 순환 참조 가능성
  • closure function 함수 주입은 안됨
  • 문서대로 해도 동작 안하는 경우도 있음

---

SpringBoot 하던 사람이 Django 찍먹 해 봄 : 저의 적응기를 공유합니다

🗣️ 이지훈

 

1. 소개

• 주요 기술
  • JAVA
  • Spring/SpringBoot
  • JPA
• 10년차
• JAVA 개발자

2. 계기

• 이직 → 파이썬 주 언어 회사
• Flask 로 되어 있던 웹 프레임워크를 Django 전환할 필요성을 팀 내에서 합의
• 팀 전체 러닝커브를 줄이기 위해 Django 튜토리얼 가이드의 작성 필요성
• Django 토이 프로젝트 시작
  • 기능: 질문 / 답변 / 회원가입 / 로그인(토큰 발급) / 추천(질문&답변)

3. 개발

• 개발 프로젝트 셋업
  • Django 사용 시
    • Django 문서와 팀 동료 도움
    • 공식 문서의 ‘시작하기’ 페이지 활용
    • 유저 가입 기능 → Django Admin 기능 활용
    • user 앱 추가 후 setting.py 기본 사용자 모델 커스터마이징
    • user 모델 추가, UserAdmin 모델 추가
    • 장고 기본 설정인 BasicTokenAuth를 그대로 사용
  • SpringBoot 사용 시
    • Spring 공식 문서 참고
    • SpringSecurity 선택
    • 라이브러리 Dependency SpringSecurity 업데이트
    • SecurityConfing로 Security 설정 초기화
      • UserDetailService 초기화
      • PasswordEncoder 초기화
    • 순환참조 오류 발생…..
      • 원인: configureGlobal 메서드와 filterChain 메서드에서 서로 PasswordEncoder를 참조하려고 하면서 순환 참조 오류 발생
      • 해결: Lombok 을 활용해 @ Lazy 를 사용하여 configureGlobal 메서드의 PasswordEncoder 에 작성 → 지연 초기화 혹은 configureGlobal를 제거하고 USerDetailService를 상속받는 클래스를 직접 구현
• 토큰 발급 API
  • Django 사용 시
    • view 단을 앱별로 모아서 관리하기 위해 API 앱 구현
      • 관심사 분리
      • 유지보수성과 가독성 향상
    • User 폴더 추가
    • serializers 추가
      • 직렬화, 역직렬화
    • view에 function view 방식으로 ObtainTokenView 구현
      • 로그인 성공 시 토큰 발급, 로그아웃 시 토큰 삭제
    • Serializer 와 view 에 대해 단위 테스트 코드 작성
  • SpringBoot 사용 시
    • Spring MVC 패턴에 따라 Controller/Service/Repository/DTO/Entity 계층별로 클래스 구성
    • 테스트 필수 계층 테스트 코드 작성
      • Controller
      • Service
    • 나머지 계층에도 테스트 코드가 필요하다면 해당 부분에 추가 작성
    • 하나의 API를 완성하기 위해 작성된 파일 총 10개, 총 라인 400줄, 글자수 1000자 이상
  • URL 및 접근 권한 관리
    • Django 사용 시
      • 프로젝트 내의 urls.py 파일만 찾아다니면 어떤 URL로 구성되어 있는 지 한눈에 파악 가능
      • api 접근 권한은 api 별로 구현단에서 직접 지정할 수 있도록 함
      • 특정 리소스에 대한 일괄 접근 제한은 따로 구성해보지 않음
    • SpringBoot 사용 시
      • 각 Controller에 작성된 api에 URL 지정
      • 전체를 한눈에 파악하려면 외부 툴(swagger)이나 IDE의 도움 필요
      • api별로 접근 제한 설정
        • @PreAuthorize(”hasRole(’ADMIN’)”)
      • 특정 리소스에 대한 일괄 접근 제한은 Security에서 구성 가능
      • 우선순위는 Security가 우선 적용됨.

4. SUMMARY

• 프로젝트 셋업과 구조
  • Django
    • 단일 urls.py 파일을 통해 URL을 중앙에서 관리
    • 접근 권한을 각 API에서 직접 제어 가능
    • 유지보수성과 가독성이 높음
  • SpringBoot
    • 각 컨트롤러에서 URL 지정
    • Security 설정에서 일괄 접근 제어 및 각각의 엔드포인트에서도 접근 제어 가능
    • 다양한 요구사항에 맞춘 세밀한 제어 가능
• API 구현과 테스트
  • Django
    • 프로젝트 구조가 간결
    • serializers와 view를 통해 효율적인 API 구현 가능
  • SpringBoot
    • 계층화된 구조로 인해 더 많은 파일과 코드 라인 필요 → 유연성과 확장성 뛰어남
    • 테스트 코드 작성에서도 SpringBoot는 더 많은 계층에 대해 테스트 필요

---

Django의 DB Connection과 Transaction 관리

🗣️ 명세균

 

1. 소개

• 토스 백엔드 개발 6년차
• 장고로 첫 개발 시작

2. Django의 DB Connection 관리

• QuerySet 실행 과정
• Connections 이란?
  • BaseConnectionHandler
    • 장고 DB Connection은 스레드/코루틴 task 단위로 DB_ALIAS별로 생성될 수 있음.
  • ConnectionHandler
    • BaseConnectionHandler 상속받음
    • 간단한 세팅함수와 현재 설정된 DB

3. DB Connection 종료

• request_started, request_finished 의 시그널에 close_old_connections 함수
• DatabaseWrapper 인스턴스에 할당된 close_at에 시간보다 현재시간이 크면 종료
• close_at 은 설정 가능 (CONN_MAX_AGE = 0: / = n: / = None: )

4. DB Connection 유의점

• MySQL server has gone away
  • 원인
    • wait_timeout 보다 더 긴 시간동안 커넥션 쿼리가 발생하지 않으면 커넥션 종료
    • Django 서버가 그 사실을 모르고 종료된 커넥션에 쿼리를 호출하면 에러 발생
  • 해결방법
    • CONN_MAX_AGE 는 DB 서버의 wait_timeout 보다 짧게 설정해야 DB 서버가 끊은 커넥션에 쿼리를 날리는 불상사 예방 가능
  • 예외
    • CONN_MAX_AGE 값에 의해서 커넥션이 종료되는 시점은 request_started, request_finished 시점
• 종종 만나는 커넥션 문제
  • 상황
    • 요청이 아닌 오래 걸리는 배치에서 쿼리가 나가는 상황
    • 요청이 아닌 오랫동안 실행되는 컨슈머, 워커에서 쿼리가 나가는 상황
    • CONN_MAX_AGE보다 요청이 오래 걸리는 상황
  • 해결방법
    • Health_check_enabled
    • CONN_HEALTH_CHECKS → 매번 ping을 날리게 되어 오버헤드 있음.
• 장고의 CONN_MAX_AGE 개선
  • self.close_if_unusable_or_obsolete()
    • cursor를 반환할 때 CONN_HEALTH_CHECKS를 사용하지 않고 CONN_MAX_AGE가 더 잘 동작하도록 가능
    • cursor 반환 전에self.close_if_unusable_or_obsolete()코드 추가
• Aborted connection xxx to db
  • graceful하게 커넥션을 정리하고 서버가 내려가지 않음
  • CONN_MAX_AGE를 wait_timeout 보다 짧게 설정하더라도 CONN_MAX_AGE가 지난 시점에 딱 커넥션을 종료해주지 않음

5. Transaction 관리 방법

• using
• savepoint
  • default 값이 True이기 때문에, 기본적으로 트랜잭션 블록이 중첩되면 savepoint를 찍게 됨
  • 내부 트랜잭션에서 발생하는 에러를 제어하지 않으면 외부 트랜잭션까지 에러가 전파 되어서 전부 롤백이 되기 때문에 에러를 잘 핸들링하지 않으면 savepoint가 무의미해짐.
• attribute → 현재 커넥션의 트랜잭션 상태 제어 가능

6. Transaction 이슈 경험 공유

• savepoint 이슈
  • MySQL의 events_statements_summary_ … 테이블

7. 결론

• CONN_MAX_AGE
• 쓰레드/코루틴 task 단위
• savepoint

---

거의 모든 파이썬 이용자를 위한 거대언어모델(LLM)의 활용

🗣️ 박상현(David)

 

1. LLM이란?

• Large Language Model
  • Language
    • 자연어, 프로그래밍 언어, …
  • Model
    • 규칙 혹은 문법에 맞게 배열된 데이터들
• 모델에 입력한 토큰들로 다음 토큰 예측
  • 아주 거대해서 성능이 좋은, 입력 토큰들의 다음 토큰을 예측하는 함수.
  • 파이썬의 랭체인

2. LLM과 대화하기

• 대화의 개념은 없음
• 이전의 대화(prompt)를 넣어줘서 대화의 형식을 유도 → prompt을 쌓아감.
  • 메모리 크기 관리 필요
• 이미 기존에 쌓인 메모리 활용?
  • 기존 대화 이어가기
  • RAG
    • 검색 → DB → 정보 → context

3. LLM과 일하기

• 할루시네이션(Hallucination) 문제
  • 다음 토큰을 예측하여 글을 작성하는 능력만 있을 뿐, 정확하거나 올바른 데이터가 나오는 건 아님.
• String(알고 있는 문자열) → LLM → String → 모르는 문자열 → 문자열 처리 → 원하는 문자열
  • 입력값 외에 정확히 알거나 컨트롤 가능한 문자열이 없음.
  • String(알고 있는 문자열)에 알고 있는 문자열+알고 싶은 문자열 템플릿 제공
  • 예시
    • 역할 암시: 너는 인공지능 챗봇이야.
    • 답변 구조: CoT (LLM이 던지는 작은 의문(생각을 곱씹는 과정)을 토대로 결과를 도출하도록 생성)
    • 도구이름, 도구 입력
      • 도구: 인간이 미리 짜놓은 함수 (= 파이썬 함수)
      • 현실에서 존재하는 실제 함수(지식)를 사용. (학습한 내용에서 벗어남)
• LLM은 다음 토큰을 재귀적으로 호출
• 해당 과정은 랭체인의 Agent에 구현되어 있음.

4. 랭체인(LangChain)

• 함수의 이름, 입력값의 형태, docstring 등의 정보를 문자열로 반환
• LLM 응답의 JSON 형식 문자열을 파싱하는 파서 구성
• 생성을 중단할 stop word 설정
• LLM이 사용할 도구 이름들 설정
  • 함수의 이름을 신중하고 상세하게 선정
• Context를 담은 프롬프팅에 사용할 메모리 설정
• LangChain Hub
  • 여러 템플릿 참고 가능

---

2일차

자동화된 파이썬 웹 프레임워크 API Schema 제작기: The long way around

🗣️ 조규진

 

1. 소개

• 레블업 주식회사
• 백엔드 개발자
• RestAPI, DB 설계, 컨테이너 설계 등 담당

2. API 문서 자동화: 도입 배경

• Backend.AI는 REST API 및 GraphQL API를 병행하여 사용
• 그동안 Backend.AI의 API 문서는 구현을 담당한 사람이 별개의 문서 파일을 임의로 채워 넣음
  • 많은 부분을 놓침

3. 그동안 문제가 되지 않았던 경우

• 서드파티 API 호출 수요 부재
  • 대부분의 고객들은 Backend.AI의 퍼스트 파티 프론트엔드인 WebUI 사용
  • 고객이 직접 API를 이용하여 Backend.AI의 기능에 접근할 일이 없었음
• 작은 개발팀의 규모
  • 대부분의 개발팀이 그동안의 API 히스토리를 이해하고 있었음
  • 타 부서에서 백엔드 개발자에게 물어보면 되는 정도로 충분했음

4. 새롭게 등장한 과제들

• API 연동 수요 증가
  • Backend.AI가 제공하는 API를 가공하여 새로운 형태의 제품을 만들고자 하는 고객 등장
  • 기존 고객의 API 수요 심화
    • 모니터링, 빌링 연동 등등…
• 사람이 늘어나고 코드 베이스가 방대해지면서 기존의 소통 방식으로는 한계에 봉착

⇒ 비대면 소통(비동기 소통)을 가능하게 만들기 위해 문서화가 필요하다는 결론이 나옴.

5. 요구사항

• 모든 RESP API Route에 대해 OpenAPI 형식의 API Schema 출력
  • 기존의 API Handler에 손대지 않고도 문서화 가능해야 함

6. FastAPI를 선택하지 않은 이유

FastAPI를 선택하지 않은 이유

• FastAPI를 사용하기에는 11만줄의 코드 베이스를 가지고 있음
• 10년이 넘은 레거시 소스임.
• OpenAPI Spec
  • REST API를 구조화하여 표현하기 위해 등장한 개념
  • API의 메서드, 리소스, 인증방식 등의 다양한 스펙 정의 가능
  • JSON Schema에 REST API에 득화된 독자 정의 추가하여 탄생
  • 3.1은 JSON Schema와 100% 호환

7. 구현

• 정적분석
  • 분석
    • Backend.AI Magager의 API Handler 정의 코드는 형식이 정형화 되어 있음
    • 그러니 ast 모듈을 이용해서 정적분석 시도
    • 소스코드 예시: Tech Stack
    • Python ast Module
      • 파이썬의 빌트 인 라이브러리
      • 파이썬 코드를 Abstract Syntax Tree 형식으로 해석하거나, 반대로 구조화된 AST를 파이썬 코드로 변환하는 기능 제공
      • 짜여진 파이썬 코드를 정적 분석 가능
  • 실행
    • 모든 API Handler가 담긴 소스 코드를 AST로 변환
    • Tree Traversal을 위해 AST → XML 로 재변환
    • 정형화된 XML Path를 따라 모든 Handler의 구조를 순회하여 함수명, Request body 형식 수집
  • 장점
    • API 구현체가 의존하는 외부 패키지 설치 필요 없음
    • 빠름
  • 단점
    • 노가다에 가까운 경로 설정
      • 유지보수 불가능
      • 상대적 경로 (XML Path)
      • API Handler의 선언 형식이 바뀌면 대응이 어려움
      • 한없이 낮아지는 코드 가독성
    • code base에 도배되게 됨
• 동적 분석
  • 분석
    • 모든 API Handler들의 entrypoint
    • aiohttp Application  객체의 내용을 동적으로 분석
    • aiohttp.web.Application
      • entrypoint
        • 모든 Handelr 들이 이 객체 안에서 정리됨
  • 실행
    • web.Application 객체의 router.routes() 메서드를 이용해 등록된 모든 Route Handler 를 순회
      • 함수명 등의 정보 가져옴
    • set_handler_atttr(wrapped, “request_schema”, checker)
  • 장점
    • 사람의 언어로 쓰여진 Spec generator를 만들 수 있음
  • 단점
    • Backend.AI의 의존성 설치 필요
      • aiohttp, aiodocker ..
  • Trafaret 한계
    • OpenAPI 스펙으로의 자동 변환 미지원
    • primitive type이 어떤 API 형식으로 정의되는 지를 모두 정의 필요
    • 응답 데이터에 대한 타입 정의를 추가 필요
      • pydantic 도입
        • Trafaret에 비해 Python typing 친화적
        • 추가적인 구현 없이도 Open Spec 변환 가능
        • typnig.get_type_hints() 함수를 사용하여 파이썬 객체의 타입 힌트 정보를 동적으로 가져올 수 있음

8. 결론

• 보완필요한 점
  • 다양한 Response Code 정보를 알려줄 필요가 있음
  • 모든 API Hander를 Pydantic으로 변환 필요
• 레거시가 많지 않다면 FastAPI 권장

---

Python ASGI 서버 구현기 with Pyo3

🗣️ 민태인

 

1. 소개

• NavyTree CTO
  • 배우들 오디션 숏폼 제작
• 장고로 입문
• PyCon 2019년 ~

2. 프로젝트 소개

• grais-asgi
  • Rust Asyncronous Server Gateway Interface의 두문자 에너그램
  • Python asyncio 생태계와 잘 호환되면서 높은 성능이 높음
  • grais
    • Rust 기반의 ASGI 서버 구현체
      • Uvicorn, hypercorn과 동일한 역할
• 프로젝트를 시작하게 된 계기
  • 짐 캘런
    • “본질을 이해하는 사람들은 극소수다.”
  • [low level] 드라이버 - 운영체제 - 네트워크 프로토콜 - ASGI - 애플리케이션 [high level]
    • 네트워크 프로토콜, ASGI에 지식이 부족함을 느낌
    • 부족함을 채우고자 프로젝트 진행
  • 한국에서 오픈소스가 나왔으면 좋겠다는 희망
    • 새로 만들고, 써보고, 피드백을 요구하는 Pycon 강연들이 많아지길 바람.
    • 본인이 먼저 행동하게 됨.

3. 사전지식

• Rust
  • 시스템 프로그래밍이 주 목적
  • 타입 시스템으로 컴파일 시간에 메모리 안정성을 보장
    • 변수의 수명(lifetime) 추척
    • 예외 처리대신 에러 반환
  • 어려운 난이도
• 바인딩
  • 프로그래밍 언어가 해당 언어에 네이티브하지 않는 외부 라이브러리나 운영 체제 서비스를 사용할 수 있도록 만들어주는 글루 코드를 제공하는 API
  • Pyo3
    • 가장 많이 쓰이는 Python-Rust 바인딩
    • Pydantic 등에 사용 많이 됨

4. 시행착오

• [구현기1] asyncio.Protocol를 Rust로
  • 이유
    • 속도를 최대로 하기 위함
  • 단점
    • 무수한 lifetime 에러로 컴파일되지 않음
    • Python 호출 코드가 많아짐
    • Python으로 일부를 옮기고자 함.
• [구현기2] HTTP 프로토콜과 asyncio.Porotcol 구현 분리
  • Rust는 HTTP 프로토콜에만 집중
  • 데이터 송수신, 흐름 제어는 파이썬으로
  • 상태머신 기반
  • 장점
    • Lifetime 문제 해결
  • 단점
    • pyo3 한계상 코드가 살짝 난해하고 지저분함
• [구현기3] 복잡한 단일 구현 나누기
  • 너무나 비대해진 Http11Connection
  • ASGI  순서에 따라 단계 나눔
  • scope 처리
• [구현기4] 사용성
  • 핫 리로드, 앱 예외처리, graceful-shutdown …
  • 편리함을 위한 CLI 인터페이스
  • 문서화

5. 느낀 점

• 직접적으로 상관없는 애플리케이션을 개발할 때도 이해도가 올라간 느낌
• 도전을 응원하고 발표하는 기회를 많이 가졌으면 함.
  • 새로운 웹 프레임워크, DI 프레임워크 (개인적으로 추천!)

6. QnA

Q. CTO 병행하면서 어떻게 구현을 했는지? 그리고 어느 시간에 주로 작업했는지?

A. 초기 시작 때엔 CTO가 아니었음.

한 달~ 한달 반정도 작업, 주로 밤~새벽에 작업함, 3~4시간씩 작업함.

 

---

Python Backend에 클라우드를 더하다

🗣️ 황정식 / Huston

 

1. 소개

• 백엔드 엔지니어
• 장고 메인
• SecondSyndrome 회사에서 Kotlin 등 사용

2. DRF 백엔드 개발의 장/단점

• 장점
  • 장고와 함께 Django Integration을 지원하는 여러 라이브러리 활용
  • 빠른 웹 서비스 비즈니스 로직 개발 가능
  • 협업하기에 좋음
• 단점
  • 빠르게 개발을 할 순 있지만 성능에 대한 챌린지가 많음
  • 대량 트래픽 발생에 약한 모습을 보여줌
    • Gunicorn - workers : 성능은 코어수 * 4개까지 가능
    • GIL 등..
• DRF Backend 개발의 단점
  • 단일 트랜잭션으로 보면 DRF도 크게 떨어지지 않음
  • 글로벌 기업에서도 Python을 활용하여 백엔드 개발 가능성을 봄.

⇒ 클라우드를 사용하여 단점 극복하려 함. (성능 개선, 가용성 높임, 파이썬의 장점 유지)

 

3. 모빌리티 서비스

(차량 대여/반납 오버헤드 이슈와 해결)

• 설명
  • 초소형 전기차 대여 서비스
  • 앱: 회원/예약/대여/차량제어/반납
  • On-Board-Diagnostics(차량 자가 진단 장치) - Provider Server(외부 서버) - OPEN/CLOSE
  • 서비스: 유저관리 / 차량관리 / 결제관리 / 대여관리 .. 등
    • 주로 DB에 데이터를 넣고 빼는 기능
• 이슈
  • 차량 관리/제어에서 성능 이슈가 생김 (메인 기능 ㅠㅠ)

이미지1

• 문제사항
  • 응답 대기상태 (응답에 30s 소요)

이미지2

➡️ 응답 대기상태에서 신규 응답이 생기면 앱이 동작하지 않음

• 비동기 처리
  • Celery & Beat
    • 불확실성을 AWS의 Lamda 사용하여 해결
    • 속도 개선
      • Lamda 사용 전(기존)

이미지3

• Lamda 사용 후

이미지4

• 결과
  • 응답 시간 단축 (약 8~9s)

이미지5

4. 파이썬 장점

• 빠른 구현
  • 불확실한 요소가 많지만 고민하는 시가능ㄹ 아껴 빠르게 구현 시작 가능
• 상각하는 대로
  • 파이썬 백엔드에게 친숙한 파이썬 스크립트를 개발해서 창의력이 생김
• 문제 해결
  • 문제를 쉽고 빠르게 해결할 수 있는 장점

5. 메시징 서비스 개발

• AS-IS 분석하여 TO-BE 요구사항 확인
  • 요구사항
    • 메시지별 다른 서비스
      • Push: Firebase
      • SMS: N사
      • KAKAO: I사
    • 스케줄링 이슈
      • 즉시발송, 예약발송 필요
      • 고객별 메시지 내역 기록
    • 이미 있는 코드 활용
      • 발송 스크립트를 활용하여 개발 기간 최소화
  • 결론
    • 기존 코드를 최대한 활용하여 스케줄링 기능 추가
      • 특정 서비스로 모두 이관하여 개발 불가능
      • 서비스에서 제공하는 스케줄링 활용 불가능
      • 레거시 파이썬 스크립트는 최대한 수정없이 사용
    • 개발 요구사항에 스케줄러도 추가
      • AWS에서 EventBridge 스케줄러 사용
• 아키텍처 구성 전, PoC 작성
  • One-time schedule 가능한 지, 얼마나 걸리는 지 검토
  • 가능성이 보여 진행하기로 결정
• 아키텍처

이미지6

6. 결론

• 파이썬은 다음과 같은 자신의 성격과 잘 맞아서 좋음.
  • 상상하는대로 재밌는 것을 구현하고 싶음
  • 빨리 구현해서 사용해보고 싶음
  • 어떤 새로운 걸 활용하고 싶음
• 파이썬과 클라우드를 활용하여 한계를 극복하는 경험 가졌으면 좋겠음

---

오픈소스 프로젝트 - 코드 0줄부터 스타 1.3k까지

🗣️ 김동규

 

1. 소개

• AutoRAG CEO (Co-Founder)
• RAG 연구원
• 디지털 노마드
• 2번의 창업 경험 (이번이 3번째)

2. AutoRAG란?

• Star History 에서 참고 가능 (1월 오픈 ~ 현재 1.9k까지 성장함)
• RAG란?
  • Perplexity 에서 질의응답 시, 최신의 정보가 없어서 정확한 정보를 답변하지 못한 GPT와 달리 정확한 대답을 함.
    • Perplexity : RAG 사용하여 ChatGPT와 동일한 기능을 함.
  • 정확한 정보를 넣어주는 기술
    • LLM이 알았으면 하는 문서를 RAG에 넣어주면, 질문에 따라 알맞은 문서를 RAG가 찾아 LLM에 제공
    • private하거나 domaintic한 정보를 LLM이 활용할 수 있도록 하는 기술
  • 문서 더미에서 필요한 정보를 검색하여 LLM이 가지고 있던 정보를 전달함.
• RAG를 만들 때 큰 문제
  • 데이터셋을 만들 때마다 달라짐.
    • 모든 문서에 좋은 방법이 없음
    • 각 문서마다 성능이 드라마틱하게 다름
    • 각각 적합한 방법을 찾아서 적용해야 함
  • 적합한 방법론이 무궁무진하게 많음
    • 랭체인 혹은 라마인덱스에 구현되어 있는 것들은 빙산의 일각
    • 모든 것을 직접 구현하고 성능을 측정해서 최적화하기엔 너무나 많은 시간 소요
• AutoRAG이란?
  • RAG 자동 최적화 툴
  • 수많은 RAG 실험을 효율적으로 편하게 하도록 자동화
  • YAML 설정파일만으로 여러 RAG 모듈을 자동 최적화
  • 문서로부터 평가 데이터셋 자동 생성
  • 직접 구현하지 않아도 최적의 RAG 조합을 찾음

3. 어떻게 오픈소스 프로젝트를 성장시켰는가?

• 오픈소스 홍보 방법
  • 커뮤니티 등에 홍보
    • 한달동안의 최소한의 기능 구현 후 런칭
    • 긱뉴스, 레딧, 아카라이브, 해커뉴스 등
      • 긱뉴스, 레딧에서 좋은 반응 → 200개 정도의 스타를 받음.
      • 기대했던 해커뉴스에는 좋은 반응을 얻지 못함.
  • 링크드인 활동 시작
    • 링크드인으로 관련 업계 사람들에게 쉽게 도달 가능
    • 최초에는 짧은 글을 올림 (단순 홍보)
    • 요즘에는 개발 블로그를 작성 후, 해당 블로그의 짧은 요약과 함께 공유
    • 라마인덱스 CEO에게 DM 및 일촌 신청
      • 라마인덱스를 사용하여 개발중임을 Git Link와 함께 DM을 보냄
      • 라마인덱스 SNS에 AutoRAG가 홍보된 것이 결정적인 계기
    • 최근에 또 다른 관계자에게 홍보가 되어 1.7k → 1.9k 로 성장
  • 직접 발표하기
    • Open-Source Gen AI Tools Demo Day에서 발표 → 스타 900개
    • AI 전문 유튜버 테디노트님의 라이브 참여
      • 한국 RAG 커뮤니티에서 알려지게 됨
      • 스타 1k 달성
    • 이후 링크드인, 컨퍼런스, 개발 블로그 꾸준히 하고 있음
  • 홍보에는 왕도가 없음을 알게 됨
    • 일회성이 아닌 꾸준히 유입될 수 있는 컨텐츠를 늘리는 것이 중요
    • 자신의 속도에 맞춰서 천천히 하지만 꾸준히 홍보 필요

4. 오픈소스를 하면서 힘들 때

• 반복되는 문서화
  • 오픈소스는 문서화가 생명
    • 불특정 다수가 보는 문서
    • 문서가 없으면 오픈소스를 활용 불가능
• 사용자 파악이 어려움
  • 누가 얼마나 쓰는지 파악이 어려움
  • 깃허브 스타가 곧 사용을 의미하지 않음
  • Contribute나 디스코드 질문 등만으로 사용자 파악 가능
  • 전체 사용자 중에 일부만 볼 수 있는 기분 때문에 허무할 때가 있음
• 반복되는 질문에 지침
  • FAQ 등을 만들어두어도 반복되는 질문들이 있음
  • 문서화 및 코드 로직 수정 등으로 고치려고 노력중
• 수익화 되지 않음
  • 현재는 사업화 진행중(일부 기능 유료화)

5. 오픈소스를 하는 이유

• 개발자는 ‘오픈소스’를 좋아하기 때문
  • 오픈소스 홍보는 ‘홍보가’ 아닌 ‘정보 공유’ 같이 받아들여지기 때문
  • 부담없이 프로젝트 정보가 퍼질 수 있음
• 외부 기여
  • 현재 Full-time 개발팀 인원은 3명
  • 이슈와 생각하지 못한 버그에 대응 가능
  • 오픈소스이기에 버그를 리포트 받을 수 있음
  • 외부PR을 적극적으로 수용 가능
  • 사례
    • 후쿠오카 개발자가 Full-Request 요청
    • 모든 프롬프트를 일본어로 번역
    • 2개국어(영어, 한국어) 지원 → 3개국어(영어, 한국어, 일본어) 지원으로 확대
• 시작하기 쉬움
  • 오픈소스의 퀄리티 요구는 생각보다 낮아 최소 기능으로 검증 가능
    • 검증: 깃허브 레포 만드는 것.
  • 최초에 12개의 모듈 → 현재 50개의 기능으로 확대함

6. 정리

• 다양한 분야의 오픈소스가 활성화되었으면 좋겠음

---

해커의 관점에서 바라본 Django Framework

🗣️ 윤석찬

 

1. 소개

• 경희대 컴공과
• Python / Django Security Contributor

2. Django가 제공하는 기본적인 보안 기능

• XXS Protection
  • Cross-Site-Scripting 웹사이트에 악성 스크립트를 삽입하는 공격 방법
  • 주로 HTML, JS 같은 언어를 이용해 악성 스크립트 삽입
  • 사용자로 하여금 의도하지 않은 행위를 하게 만드는 위험 있음
• SQL Injection Protection
  • DB 쿼리에 악성 SQL 코드를 삽입하여 데이터를 조작하거나 탈취하는 공격 방법
  • Django ORM 기능으로 SQL Injection 보호
  • 버전에 따라 지원 안될 수 있음
• CSRF Protection
  • CSRF: 사용자가 자신의 의지와는 무관하게 악의적인 요청을 보내도록 만드는 웹 보안 취약점
• Clickjacking Protection
  • X-Frame-Options에 ‘DENY’ 설정
• Password Cracking Protecction
  • 디폴트로 ‘PBKDF2Passworldhasher’ 사용
  • SHA256 알고리즘을 720,000번 반복 → 해커들이 쉽게 크랙하지 못하도록 함

3. 발견된 취약점

• 1-Day Vulnerabilities
  • 1-day: 취약점에 대한 정보가 공개되고, 패치 버전이 존재하는 취약점
  • 취약점 목록
    • 입력받은 값을 검증받지 않고 쿼리에 바로 넣고 실행이 되어 악의적인 쿼리 호출 가능
    • 복잡한 정규식 사용, 입력길이 제한 없음, 반복적인 패턴 → 과도한 CPU 사용으로 DoS 유발 가능
      • 강연자가 발견한 취약점!
  • Conclusion
    • 최근 공개된 보안 이슈는 발생 가능성낮음
    • SQL Injection
      • 잘 사용되지 않는 기능을 사용해 트리거 됨
    • DoS
      • 비정상적으로 큰 입력값이 있어야 가능
    • 결론
      • Django는 여전히 안전하다고 확신함

4. 개발 시 주의해야할 점

• XXS
  • 응답 시, HttpResponse()를 사용하는 경우
    • 장고의 템플릿 필터를 사용하지 않기 때문임.
    • 사용자가 입력한 값이 코드에 삽입됨
  • 템블릿 필터 ‘safe’를 사용하는 경우
    • 데이터가 안전하다고 가정하고 진행하기 때문에 악의적인 사용 가능
  • 템블릿 필터에서 ‘autoescape off’ 사용
  • URL 형식 검증이 없는 경우
    • 허용된 프로토콜만 사용 가능하도록 제한 필요
• SQL Injection
  • Raw SQL 이용 시 안전하지 않은 방법으로 사용자 입력이 포함되는 경우
    • String Concatenation, Format String, …
    • Order by 구문 사용 시 주의 필요
  • 장고를 2022년 이후 업데이트를 하지 않은 경우
• Third Party Library
  • Exploitable Third-party Modules
    • Django-rest-framework, etc …
      • 강연자가 Django-rest-framework 에서 중급 정도의 취약점 발견
  • 정기적으로 라이브러리 업데이트 필요
  • 보안 문서 및 코드 리뷰 확인 필요
• Regular Expression Denial of Service
  • 백트래킹을 많이 유발하는 복잡한 정규표현식 패턴 사용
• SSRF
  • 공격자가 의도하지 않은 대상에 서버 측 요청을 할 수 있도록 허용하는 취약점
  • 내부 리소스에 대한 무단 액세스로 이어짐
    • 서버를 프록시처럼 사용하여 접근 가능
  • 엄격한 방화벽 규칙 사용 필요
• SECRET_KEY Leakage
  • 외부 노출 시 문제가 생김
    • 세션 하이재킹
    • CSRF 토큰 위조
    • 암호화된 데이터 복호화
    • 서명된 데이터 위조
    • 애플리케이션 전체 장악
  • 실제 발생한 보안 문제 발생한 사례가 많음
  • PicklesSerializer와 결합하여 더 큰 문제 발생

5. 결론

• Django는 안전해지고 있다
• 그럼에도 만능이 아니기 때문에 보안성 유의 필요
• 꾸준한 업데이트 필수적

6. QnA

Q. 웹개발 시 보안에 관심이 많은데, 소개해주신 패턴 말고도 최근에 있었던 이슈나 놓치기 좋은 포인트 소개 부탁

A. 최근에 프레임워크가 고도화되고 보안 취약점이 사라지고 있어서 DoS 취약점에 관심을 가지고 있음

예전에 비해 Http 파싱 등과 같이 보안 취약점이 발생하는 경우가 많음

최신 업데이트를 하는 것이 가장 중요하고 좋은 예방책임

Q. 취약점 발견은 테스트와 코드 분석 중 어떤 방법으로 발견?

A. 코드를 통해 발견함. 코드를 한두달씩 봄

Q. 코드를 어떤 방법으로 보는지? (위에서부터 차례로? 아니면 한 모듈을 잡고 보는지?)

A. 취약점이 많이 발생하는 유형이 있기 때문에, 관련 코어부터 점검함

---

험난한 암호화폐 세상을 여행하려는 Python 유저들을 위한 안내서

🗣️ 이왕원

 

1. 소개

• AI 스타트업 코디미에서 CTO
• AI, Web, Blockchain 등 공부 중

2. 암호화폐 생태계 순환 원리

• 검증자, 빌더(개발자 등), 유저
• 검증자
  • 블록체인 노드 유지
  • 물리적인 인프라에 기여
  • 해당 체인의 가상화폐를 얻음
• 빌더
  • DApp 개발
  • 프로젝트 개발 및 운영에 기여
  • DApp 사용 수수료, 추가화폐 발행 등 다양한 수익모델을 얻음
• 사용자
  • DApp 및 생태계 이용
  • 가상화폐 사용을 기여함
  • DApp 및 생태계 이용을 얻음
• 서로 상호보완적인 역할이기 때문에 생태계 유지 및 성장 가능
• 역설적으로는, 이 생태계가 완성되기 전까지는 이 선순환구조가 성립될 수 없다는 치명적인 문제가 있음

3. 암호화폐 에어드랍

• 에어드랍(Airdrop)?
  • 생태계에 기여한 실유저/빌더에게 암호화폐를 주는 정책
  • 재단 측에서는 초기 생태계 구성원을 끌어들이기 위해 암호화폐 에어드랍을 적극적으로 시행
• 에어드랍 헌터
  • 에어드랍 작업만 전문적으로 함
  • 생태계에 장기적으로 좋지 않은 영향을 줌
  • 결국 프로젝트 측에서는 이를 악성 시빌(sybil) 공격으로 규정하기에 이름
    • 한 개인이 다수의 계정이나 노드, 컴퓨터를 구성해 네트워크를 공격하는 기법 중 하나

4. 현상금 사냥꾼

• LayerZero
  • 여러 체인의 자산을 통합하는 크로스체인 플랫폼
  • 초기부터 꾸준하게 사용한 유저들에게 에어드랍 약속
  • 시간이 흘러 자체 코인을 발행하는 시점에서 총 지갑 수가 250만 개에 육박
  • 현상금 사냥꾼 제도 출범
    • 시빌공격하는 사람을 잡으면 15% 제공
• 대부분 여러 개의 계정을 가지고 있는 게 디폴트였기 때문에 문제가 됨
• 서로 제보하고 신상캐고 공개저격하는 문제가 생김

5. 파이썬을 활용한 온체인 데이터 분석/수집

• 현상금 사냥꾼 —> 데이터 분석과 동일함
• 각 트랜잭션 해시값을 비롯한 분석에 필요한 데이터 제공 (.csv)
• table 데이터이기 때문에 파이썬 데이터분석 유저가 다루기 좋은 형태
  • 범용적인 데이터 분석 툴(numpy, pandas 등) 사용 가능
• 아이디어 예시
  • 실유저는 장기 이용, Sybiler들은 단기 사용했을 것이다
    • 월 별로 평균 등 디테일한 분석 필요
    • Seaborn으로 사용기간 히스토그램 시각화
  • Sybil 지갑이라면 에어드랍 스냅샷 이후에 자금을 전부 회수했을 것이고, 실사용 지갑이면 계속 쓸테니 돈이 들어있지 않을까?
    • 명확하게 판별하는 기준을 이야기할 수 있으면, 어떤 수단과 방법을 동원해도 괜찮음
    • 주어진 데이터로만 분석하지 않아도 됨
    • 주어진 데이터에는 지갑 잔액 정보가 없기 때문에 web3.py로 직접 수집
      • 이더리움 호환 블록체인과 상호작용할 수 있게 해주는 파이썬 모듈
  • Sybil 지갑이라면 에어드랍 스냅샷 이후에는 지갑을 사용하지 않았을 것이고, 실사용지갑이면 계속 쓸테니 트랜잭션이 계쏙 발생했을 것이다
    • 각 지갑별 트랜잭션 데이터를 집계
    • block explorer 사용하여 분석
    • requests와 같은 모듈을 사용하여 RestAPI로 직접 호출

6. 정리

• 24.06.15 기준, 공식 발표에 대한 Sybil 기준은 아래와 같음
  • 브릿지 금액이 1달러 미만
  • 대량의 지갑 사이에 일정한 트랜잭션(tx) 기록이 있는지
  • 서비스 오픈 12달 이내 3번 미만의 트랜잭션 유무
  • 스냅샷 이후의 트랜잭션 기록이 없는지
• 확실한 기준을 정립하기 어려움
  • 여러 조건이 겹쳤을 때 판별하는 것으로 보완
• 이 과정이 유의미한 이유
  • 타 도메인의 데이터분석과 크게 다르지 않음
  • 난이도가 높지 않음
  • 가설 및 접근 전략을 세우기 위해 도메인 지식 중요