파이콘 한국 2025 2일차

• 발표자: 데이터 엔지니어
• Python 기반 시스템의 개발, 운영 및 유지보수 실무 경험을 기반으로 습득한 Python 로깅 스킬 공유
• 회사에서 겪은 베스트 프랙티스, 파이선 로깅 라이브러리
• Worst Practice - 로깅을 남기지 않음
• Bad Practice 1 - print
• Bad Practice 2 - with open (logging 자체 함수)
  
• 문제: 파일io 비효율
• 파이썬 로깅 표준 라이브러리 소개 
• import logging
• 예시 코드
• Log Level (CRITICAL / FATAL/ ERROR / WARN / INFO / DEBUG …)(Numeric value)
• Log emit 내부코드 구조 설명
• Log Handler
• logger.addHandler(…)
• TimedRotatingFileHandler - 개발자가 설정한 시간에 의해서 로그 파일 로깅 로테이팅 시켜줌, (매일 시간, 특정 시간, interval, …)
• QueueHandler 로그 io 메인스레드 오버헤드 발생 가능, 웹 서버와 같이 빠른 반응 필요 시 스레드 분리해서 속도 저하 발생 않게 가능
• LogFilter - 개발자가 조건 지정 가능. 조건 로그만 출력 가능
• logger.addFilter(…)
• LogFormatter
• handler.setFormatter(…)
• ISO formatted time. localtime() 개체로 생성되면 타임존, ms는 누락 문제 있음. formatTime 개체 오버라이딩해서 해결 가능.
• Best Practice
• logstash Handler 도 공개되어 있어 붙이기만 해도 일래스틱서치로 보낼 수도 있고 등
• QA

• 발표자: @kodingwarrior
• 발표 어떤 사람을 위한?
• 기계가 주도적 코드 짜는 것 경험해보고 싶은 사람
• Ai 비용 절감
• 로컬 llm 코딩 에이전트
• Aider 소개, Aider와 페어 프로그래밍, 앞으로 미래
• Aider는 오픈소스 기반으로 가볍고 자유롭게 모델을 선택해서 사용할 수 있는 에이전트
  
• Pair Programming
• Navigator - Driver가 작성하는 코드를 검토하고 방향과 전략 제시 안내
• Driver - 작업 세부 구현
• 익숙한 방식 아닌가?
• Aider 기본 기능
• LLM 모델 선택적 사용 (클라우드 및 로컬)
• 터미널 기반, IDE 연동
• 대부분 언어 지원(100개 이상)
• Aider LLM Leaderboard - 모델 검색
• 데모 영상: Todo List 만들기 React app
• $ aider
• 프로그램 설명 프롬프트 작성 .md
• 어떻게 역할 분담을 할지?
• Aider 주요 3가지 모드
• /ask 질문/답변 여러번 반복. 요구사항 정리, 목표 설정
• /code 제공된 컨텍스트로부터 실제 코드 작성
• /achitect 하이브리드 (비추천)
• /copy 모드로 xml 프롬프트 생성
• 팁 몇 가지 (비용 절감, repomix-LLM 친화적 텍스트로 변환)
• 흔하디 흔한 환각 위험성
• 올바른 지시를 내리려면 배경 지식 필요
• 발표자가 느낀 효능
• 시간 절약
• 미루게 되는 습관을 해소
• 잘 모르는 영역의 궁금증을 빠른 속도로 해소
• 발표 준비하는 중에도 세상이 변했다
• 5월 클로드 코드 1.0 오픈
• 6월 Gemini CLI 발표
• 7월 3일 Cursor 1.2 발표
• 1주일 뒤에 AWS Kiro 발표
• 하지만 도구가 하는게 아니라 사람이 하는 거니까…
• QA
• 실제 적용해 보셨을 때 어떤 종류에서 특히 효과적? 반대로는?
• 대부분 잘 맞았고, 그런데 프론트엔트 코드는 조금 짝이 안 맞을 때 곤란
• Mcp 됨?
• 이슈 트래킹을 하고 있는데 아직 이슈 남아있다 안되는거 같다
• 한달 토큰 사용량 비용은?
• 어떻게 쓰냐에 다른데 월 50$ 나왔다. 사용하는 만큼 나오니까
• 회사 커스터마이징 클로드 코드와 Aider 병행 어떻게 생각?
• 기업이 말아주는 코딩 에이전트 쓰는게 정신건강에 이롭다…
• 모델 선택
• 시연은 소넷 4.0 사용
• 커서, 클로드 코드 등… 많은데 Aider의 기능적 비교 우위가 있나요?
• 하고 싶은 말은 많은데… 그나마는 비어있는 에디터 제공된다? 별로 없다

• 발표 내용: 파이썬 성능 최적화 - NumPy, Numba, Branchless Programming, Cache Prefetching
  
• 발표자: 소속 (주)휴이노

1. 배경

2. 파이썬의 CPU 최적화 필요성

• 문제점: 파이썬은 CPython 인터프리터의 오버헤드(바이트코드 디코딩, 동적 타입 검사, GIL, GC 등)로 인해 CPU-bound 작업에서 최소 8배 느림. 반면, I/O-bound 작업에서는 큰 차이가 없음.
• 한계: NumPy, Scikit-learn 같은 라이브러리는 이미 최적화되어 있지만, 커스텀 로직 구현 시 성능 병목 발생. 
• 여기서 파이썬의 약점. 파이썬 pip 라이브러리는 괜찮으나 커스텀 로직 구현 시 최적화 필수
• 해결 필요성: CPU-bound 워크로드에서 최적화.

3. NumPy와 Numba 소개

• NumPy: 고성능 배열 연산 라이브러리로, 대용량 데이터 처리와 행렬 연산에 최적화. 동적 타입 오버헤드를 줄이고 연속 메모리 레이아웃 제공.
• Numba: JIT(Just-In-Time) 컴파일 도구로, 런타임에 파이썬 코드를 최적화된 머신 코드로 변환. 특히 루프 최적화에 효과적이며, @jit 데코레이터로 간단히 적용 가능.

4. Branchless Programming

• 정의: 조건문 분기를 최소화하여 CPU 파이프라인 정지(flush)를 줄이는 프로그래밍 기법.

• CPU 파이프라인과 분기 예측:

• CPU는 명령어를 예측하여 파이프라인에서 병렬 처리.
• 분기 예측
• 예측 성공=빠른 실행
• 예측 실패=파이프라인 정지(flush)
• 분기 예측 실패 시 파이프라인 비우고 새 명령어를 가져와 시간/자원 낭비(패널티 발생).
• 현대 CPU는 약 95% 분기 예측률을 보이지만, 실패 시 성능 저하가 큼.

• 기법:

• 비트 연산: 조건문 대신 비트 연산으로 로직 처리.
• 룩업 테이블: 미리 계산된 결과 테이블을 사용해 분기 줄임(예: 가상 머신의 함수 테이블).
• 산술 연산: 조건문을 산술 연산으로 대체.
• 장점: 성능 향상(예: 8~11배 성능 향상 확인).
• 단점: 코드 가독성 저하, 디버깅 어려움, 일부 환경에서 비효율적.
• 분기 최소화 위한 추가 연산으로 오버헤드 발생
• 그래서 항상 벤치마크 해야함
• 적합 사례: 고성능 컴퓨팅, 실시간 시스템, 그래픽/게임 엔진, 암호 연산 등.

5. CPython의 한계

• CPython: 파이썬의 표준 구현체로, 바이트코드를 가상 머신에서 실행. 디코딩 과정에서 오버헤드 발생.

• 문제점:

• 동적 타입으로 매번 타입 검사 필요 → 오버헤드.
• GIL(Global Interpreter Lock)과 GC(Garbage Collection)로 추가 성능 저하.
• 해결 방향: JIT 컴파일(Numba), 정적 타입 활용(NumPy), branchless 기법.

6. Branchless 프로그래밍 예시

1. 예시1: 8비트 패리티 계산:

• 기존 방식: 루프와 조건문 사용 → 조건부 점프(jmp)로 분기 발생.
• 최적화: Numba JIT와 패리티 룩업 테이블 사용 → 조건문 제거, 분기 없는 코드.
• 결과: 머신 코드 분석 시 조건부 점프 제거, 8~11배 성능 향상.
• 기존 방식: 머신 코드 분석 jmp 생겨서 분기 생김
• 최적화 후 가장 코어한 머신 코드 부분만 비교하면 조건부 jmp가 없음 

2. 예시2: CTZ(Count Trailing Zeros):

• 암호 연산에서 자주 사용.
• 기존 방식: 32비트 루프와 조건문 → 다수 점프 발생.
• 최적화: 룩업 테이블 사용 → 점프 제거.
• 기본 방식: 여러 jmp 있음
• 브랜치리스 룩업 테이블 사용: jmp가 없어짐
• 결과: 8~11배 성능 향상.

7. Cache Prefetching

• 캐시 계층 구조: L1, L2, L3 캐시로 계층화. 데이터가 캐시에 있으면 빠른 접근 가능.
• 중요성: CPU와 메모리 간 속도 차이로 병목 발생. 캐시 활용으로 지연 최소화.
• 미래 데이터 예측해 미리 로드
• 미스 줄여 지연 최소화 
• 하드웨어: CPU 자동 예측 << 발표에선 이 부분만 소개
• 소프트웨어: 코드로 명시 builtinprefetch

• Cache Prefetching:

• 하드웨어 프리페칭: CPU가 미래에 필요한 데이터를 예측해 미리 로드.
• 소프트웨어 프리페칭: __builtin_prefetch 로 명시적 데이터 로드.
• 효과: 캐시 미스 줄여 지연 최소화.

• Sequential Processing:

• 메모리 순서대로 데이터 처리 → 공간 지역성 활용, 캐시 히트율 증가.
• 예: 배열 순차 접근 vs. 랜덤 접근 → 순차 접근이 20배 이상 빠름.
• 반례: Linked List, Graph는 비순차적이어서 캐시 효율 낮음.
• Pure 파이썬과 Cache Prefetching 한계
• 순수 파이썬: 최대 활용 불가능
• 이유: 연속성 데이터 타입 부재로 캐시 활용 제한.
• 대안:
• NumPy 배열: 연속 메모리 레이아웃으로 캐시 효율성 극대화.
• Typed List: 정적 타입으로 타입 검사 오버헤드 제거.
• 효과:  Cache Prefetch 활용 가능

8. 결론

• 순수 파이썬의 한계: 인터프리터 오버헤드, 동적 타입, 비효율적인 조건문 처리.
• 해결책:
• Numba: JIT 컴파일로 인터프리터 오버헤드 제거.
• NumPy: 동적 타입 문제 해결, 연속 메모리 제공.
• Branchless Programming: 조건문 최소화로 CPU 파이프라인 효율화.
• Cache Prefetching: 메모리 접근 최적화로 캐시 히트율 증가.
• 효과: CPU-bound 워크로드에서 C++ 수준 성능 달성 가능. (항상 벤치마킹으로 성능 검증 필요.)
• 결론: 파이썬은 CPU-bound 작업에서 성능 한계가 있지만, NumPy와 Numba를 활용한 branchless programming과 cache prefetching으로 이를 극복할 수 있습니다. 조건문 최소화, 룩업 테이블, 비트/산술 연산, 순차 메모리 처리로 성능을 8~20배 향상시킬 수 있으며, 고성능 컴퓨팅과 실시간 시스템에 적합합니다. 최적화 전후 벤치마킹은 필수이다.

• 파이썬 말고 다른 언어는 사람이 컨트롤하는 것보다 컴파일러가 더 잘해서 분기 예측 지양하는 경우가 많다고 알고 있는데 파이썬에서 직접 고려할정도로 중요한 이유가 있을까요?
• 룩업테이블 개수를 조정할 수 있다면 그런 요소 제어할 수 있다
• pep703 no-gil 그래도 중요할까요
• gil 사라지는건 스레드와 연관. Gc 등은 브랜치리스 프로그래밍과 영향이 없지 않을거라서 큰 차이 없을 듯
• CPython에서 os 마다 다른 컴파일러 사용. 브랜치리스 프로그래밍하려면 os와 컴파일러 고려해야할까요
• numba는 llvm으로 컴파일된다. 걱정되시는 부분이 시피유와 isa 차이 말씀하시는거 같은데 프로덕트 환경에 맞춰 테스트해야할 거 같다

• 발표자: 김준기 래블업

WheelNext 세션 요약

1. WheelNext 프로젝트 개요

• WheelNext란?: WheelNext는 차세대 Python 패키징 규격을 개발하기 위한 프로젝트로, 기존 wheel(.whl) 포맷의 한계를 극복하고 현대적인 요구사항(예: GPU 가속기 호환성, 최신 CPU 인스트럭션 지원 등)을 반영하려는 노력입니다.
• 참여 배경: 최근 WheelNext 워킹그룹에 조인하여 차세대 패키징 규격 논의에 참여. Python 패키징 생태계의 발전을 위해 다양한 주제(호환성, 성능 최적화 등)를 논의 중.
• 논의 주제: GPU 드라이버 호환성, CPU 인스트럭션 세트별 최적화, 다중 인덱스 처리 방식 등 기존 wheel 규격의 한계를 개선하는 방안.

2. 현행 Wheel 규격 소개

• 역사:
• 1990년대 말: distutils가 Python 2.0에 포함되며 패키징의 시작.
• 파이썬 언어는 오래되었다. 역사를 쓰다보면 90년대 말 distutils.
• 2012년: Wheel 규격 제안(PEP 425, PEP 427 - Wheel 1.0, PEP 426 - 메타데이터 1.3).
• 2014~2016년: PEP 425(플랫폼 태그 확대), PEP 571(manylinux2010) 등으로 규격 확장.
• 의의: Wheel은 Python 패키지의 이진 배포를 표준화하여 설치 속도를 높이고, 플랫폼별 호환성을 제공. 기존 sdist 대비 효율적이며, PyPI(Python Package Index)를 통해 배포.
• Wheel 내부 구조(PEP 427): .whl 파일은 압축된 아카이브로, 메타데이터, 소스 코드, 이진 파일 등을 포함. 플랫폼 태그(예: cp39-cp39-win_amd64)로 특정 환경에 맞는 패키지 식별.
• 플랫폼 태그 형식: {python_tag}-{abi_tag}-{platform_tag} (예: cp39-cp39m-linux_x86_64). 특정 Python 버전, ABI, 플랫폼을 명시.
• 중앙 저장소: PyPI는 약 25TB 규모의 패키지를 호스팅하며, 모 CDN 업체의 후원으로 비용 절감 및 안정적 서비스 제공.

3. WheelNext 워킹그룹 논의

• 기존에 Wheel 잘 쓰고 있는데 왜? → 최근 하드웨어와 패키징 발전상을 다 반영하고 있지 못하다.
  
• 예: CUDA 등 GPU 드라이버별 최적화된 wheel을 선택하기 어려움.  CUDA 없는 시스템을 받으려면 지금의 wheel로는 안됨. 공식 홈페이지에 가서 조건을 맞춘 다음에 다운로드 눌러야 wheel설치 이런 불편들이 점점 더 많은 패키지에서 발생.
• 또는 인텔 시피유 어느 시기에 나온 것에 따라서 최신 CPU(예: Intel v3 이상)에서 성능 최적화된 패키지 받고 싶지만 구분 불가능
• 최신 시피유에서 더 빠른데 굳이 느리게 만들어 배포하는 상황
• 다중 인덱스 이슈: 버전 우선 vs 인덱스 우선 해석 모드의 모호성
  
• 문제 인식:
• GPU 호환성: CUDA 등 GPU 드라이버별 최적화된 wheel을 선택하기 어려움. 예: CUDA 없는 시스템에서 wheel 설치 시 공식 홈페이지 방문 및 조건 확인 필요.
• CPU 인스트럭션: 최신 CPU(예: Intel v3 이상)에서 성능 최적화된 패키지를 배포하려면 구형 CPU 호환성을 포기하거나 느린 버전으로 배포해야 함.
• 다중 인덱스 이슈: 버전 우선 vs 인덱스 우선 해석 모드의 모호성.
• 제안된 해결 방안:
• 하위 호환성 유지: 기존 wheel 사용자에게 영향 최소화.
• Variant Support: 제조사별(예: NVIDIA, Intel) 확장 태그 도입.
• variantlib: Wheel 도구에 플랫폼별 변형(variant) 지원 포함.
• pip 확장: Variant 태그를 인식해 최적의 wheel 자동 선택(예: NVIDIA CUDA 버전에 맞는 wheel 다운로드).
• 주요 어젠다:
• GPU 가속기(예: CUDA, AMD ROCm) 호환성 강화.
• CPU 인스트럭션 세트별 최적화(예: AVX, AVX2, AVX-512).
• 다중 인덱스 처리 방식 명확화.
• 
  

4. 논의 진행 방식

• WheelNext Summit 2025 (3월, 메타 먼로파크 오피스) 소개 받아 참석:
• 1부: 제안자 중심의 초안 설명 세션.
• 2부: 소그룹 자유 토의(화이트보드 활용, 질의응답 및 아이디어 제안).
• 참여자: 메타, NVIDIA 주도, 다수 빅테크 기업 및 Python 커뮤니티 참여.
• 주요 논의:
• 동일 태그 충돌 시 우선순위 설정.
• 래블업 건의사항
  
• uv(패키지 매니저)에서 최신 CPU 인스트럭션 미지원 문제 개선 건의(사진).
• 
  
• 다가오는 이벤트:
• PyCon US 패키징 서밋 (5월 18일): 세션 발표 및 자유 발제. WheelNext 관련 최신 논의 공유 및 피드백 수집.

5. 정리 및 소감

• 참여 소감: Python Packaging Authority 산하 SIG(Special Interest Group)로 운영되지만, 메타와 NVIDIA가 주도. 빅테크들도 이 점을 잘 알고 있고, 그래서 더 적극적으로 파이썬 커뮤니티의 다양한 목소리를 수용하려는 노력(예: 서밋 주최, 토의 세션 등).
• 기대: 1~2년 내 pip install 명령 하나로 CUDA 및 다양한 가속기 특화 wheel 설치 가능. 패키징 과정 간소화 및 성능 최적화 기대.
• 느낀 점: 실리콘밸리 빅테크의 ‘표준화’라는 주제를 다루는지 경험할 수 있는 기회

• 배포하려면 다양한 머신들과 CI/CD 많이 필요할거 같다
• 패키지 배포하는 쪽에서 추가적인 자원 들이거나 지원을 받아야 하지 않을까

• 발표자: 배권한
• 어젠다
• 왜 옵저버빌러티가 필요한가
• LogFire
• 가벼운 얘기
• 왜 옵저버빌러티가 필요한가
• ELK Stack, Grafana
• 파이썬은 Senty
• DataDog AWS CloudWatch
• 설정하면 이전하기 힘듦
• 어느순간 표준이 생김 OpenTelemetric
• LogFire 장점
• Pydantic 개발자가 만듬 / 파이썬 친화
• Postgresql SQL 가능, 스키마 제공
• AI 붙어 있다
• MCP 서버 제공
• 자연어로 쓰면 sql
• 기능 요청 할당하면 추가해줌
• SaaS 가격도 쌈
• 단점
• 30일까지만 데이터 보관
• 작은 회사라 기술지원 쉽지 않음
• 백엔드 오픈소스는 미공개
• 연동 방법 - 쉽다 가입-토큰-import logfire
• LLM, Web framework, javascript, Databases, HTTP client, event stream, stripe, AWS lambda
• 만약 안되어 있다 - 요청(Opentelemtry 대비 최대 장점)
• 대시보드, Alert
• LogFire와 서비스 운영
• 모든 메트릭과 로그를 한곳에
• CDN 트래픽 기록한다
• OnCall 롤을 만든다
• 기간을 정해서 alert 을 받는 사람
• 대응하다 안되면 사람들을 깨운다
• 팀당 1~2명 보통 로테이션
• 개발자 하는 걸 추천
• 주간 레포트를 쓰고 팀에 공유
• 지표가 달라졌나?
• 주기적으로 관측가능성 자체에 대해 리뷰
• 비용
• 로그 필요 없으면 메트릭
• 삭제나 추가된 기능 공유
• 합성 메트릭
• 비율 계산 요청 대비 실패율 사용량 대비 스레드 대기율
• 파생 지표 평균 응답 시간
• 비즈니스 지표와 결합
• 모의 지표
• SLI SLO(서비스 수준 지표, 서비스 수준 목표)를 정의한다 
• 자주 들어오는 QA
• MSA 잘 되나요?
• 잘 됩니다
• 비싸요
• 주기적으로 로그 정리 조금 싸게 됨
• 로그로 서버 느려져요
• 오버헤드 조금 있습니다
• 개인정보는 어떻게 하나요
• 필드명으로 삭제하거나 익명화 기능 있음
• 기타 여러가지 질문들
• 메트릭 어떻게 수집
• 클라우드의 메트릭 어떻게 수집?
• 메트릭 로그가 너무 많은데요?
• 필터링 aggregation
• 회사 설득이 안됩니다
• 구글이 한다고 하세요
• 그래도 안돼요
• 네카라쿠배가
• 그래도 안돼요
• 토스 당근
• QA
• 오픈소스가 있는데 왜 LogFire를?
• 저도 오픈소스 좋아하지만 회사라면 SaaS로(문제 생기면 누구의 책임?)
• 
  
• 제일 좋은건 일단 로그 많이 남기고(모든 로그) 너무 많이 나온다고 뭐라고 하면 그때부터 로그 줄이기 추천

• 회계
• 2024 -4500만원 적자
• 2025 장소 0원(동국대학교). 티켓 수입 + 후원 + 굿즈 판매 + 부가 수입 + (굿즈 제작비 - 운영 비용 - 작년 빚) = 결산 +30만원