이 글은 PyCon Korea 2025에서 진행된 <10년 이상의 파이콘 데이터로 DuckDB와 벡터 임베딩을 활용하여 기술 트랜드 인사이트 찾기> 세션을 정리한 내용입니다. DuckDB 고성능 분석 도구와 벡터 임베딩을 함께 사용해서 파이썬 커뮤니티의 변화를 살펴보며, 파이썬 생태계 발전에 대한 인사이트를 공유합니다. 발표 자료는 PyCon Korea 2025 공식 홈페이지에서 확인할 수 있으며, 추후 파이콘 한국 유튜브 채널을 통해 영상으로도 만나보실 수 있습니다.

10년 이상의 파이콘 데이터로 DuckDB와 벡터 임베딩을 활용하여 기술 트랜드 인사이트 찾기
박조은 개발자

2025년 파이콘 한국에서 전 세계 파이콘 데이터를 수집해서 분석하는 방법에 대한 튜토리얼을 진행하고, 분석한 내용에 대해 발표했다. 오늘은 해당 튜토리얼과 발표를 진행하며 느낀 소회를 공유하고자 한다. 개발자로서 우리는 종종 경험과 직관에 의존해 기술의 흐름을 이야기한다. "요즘 FastAPI가 대세인 것 같아", "AI 분야는 정말 빠르게 변하는구나"와 같은 생각들이다. 하지만 이런 감각을 데이터로 증명할 수 있다면 어떨까? 지난 10년간 파이썬 개발자들은 무엇에 열광했고, 어떤 문제를 해결하려 했으며, 지금은 어디를 향해 나아가고 있는지, 그 거대한 여정을 숫자로 그려볼 수 있다면 말이다.

이 글은 바로 그 질문에서 시작된 하나의 데이터 분석 프로젝트에 대한 기록이다. 2013년부터 2024년까지, 전 세계 주요 파이콘(PyCon) 컨퍼런스에서 발표된 6,000개 이상의 유튜브 영상 데이터를 분석하며 발견한 파이썬 생태계의 구체적인 변화와 미래 방향성에 대한 이야기를 풀어보고자 한다.

오픈소스 컨트리뷰션 아카데미로 시작된 프로젝트

이 방대한 분석의 씨앗은 '오픈소스 컨트리뷰션 아카데미'에서 싹텄다. 처음에는 ‘pyvideoeda/py-video-data’라는 GitHub 저장소에 파이콘 영상 메타데이터를 모으는 소박한 목표로 시작했다. 멘토로 참여하여 멘티들과 함께 수백, 수천 건의 데이터를 수집하며, CSV 파일 형태로 차곡차곡 쌓아갔다. 오픈소스 컨트리뷰션 아카데미에는 오픈소스에 기여하고 싶지만 Git이나 GitHub 사용이 처음인 분들을 위한 과정을 운영하게 되었다. 더 나아가 의미 있는 프로젝트를 만들어 오픈소스에 기여해 보는 경험을 해보면 좋겠다는 생각이 들어, 기존 전 세계 파이콘 유튜브 영상 정보를 정형 데이터로 수집해서 아카이빙해보는 취지로 시작했다. 아카이빙된 데이터로 다양한 분석을 시도해 볼 수 있을 거라는 생각이 들었다.

이미 파이썬 유튜브 영상에 대한 데이터를 저장하는 저장소가 있기는 하다. 바퀴를 다시 만드는 게 아닌가라는 생각이 들기도 했지만, 개별 비디오 단위로 되어 있고 파이콘 외 자료도 있어, 파이콘 위주의 데이터로 아카이빙을 해보면 어떨까라는 생각에서 시작되게 되었다.

데이터 수집 과정은 단순하지만 노동집약적이었다. 각 파이콘의 유튜브 채널을 찾아 영상 제목, 발표자, 설명, 업로드 날짜, 조회수 등의 메타데이터를 추출했다. 초기에는 수작업으로 진행했으나, AI를 활용한 바이브코딩, MCP 등의 자동화 스크립트를 개발하며 효율을 높였다. 그러나 각 컨퍼런스마다 영상 목록을 직접 찾아와야 했고, 일부는 발표가 누락된 것도 많았고, 실제 발표 연도와 영상의 연도가 다른 경우도 많았다. 이런 데이터 품질 문제를 해결하기 위해 정규표현식을 활용한 파싱, 수동 검증, 크로스 체크 등 지난한 정제 작업이 필요했다.

이 자리를 빌려 프로젝트의 초석을 다져준 커뮤니티 기여자들에게 다시 한번 감사를 전한다. 데이터 수집과 정제는 화려하지 않은 작업이지만, 이들의 헌신이 없었다면 이 분석은 시작조차 할 수 없었을 것이다.

좀 더 빠른 분석을 위해

데이터가 많아질 수록 CSV 파일을 직접 읽어 분석하는 방식의 비효율성이 명확해졌다. 복잡한 집계나 텍스트 분석에 상당한 시간이 소요되었기 때문이다. GitHub에 저장된 여러 개의 CSV 파일을 읽어와 특정 연도의 키워드 빈도를 집계하거나, 지역별 트렌드를 비교 분석하는 작업은 점점 버거워졌다.

구체적으로 말하면, 2018년부터 2024년까지의 모든 파이콘 데이터에서 "machine learning" 키워드가 포함된 발표의 연도별 추이를 분석하는 단순한 작업조차 로컬 메모리에 모든 CSV 파일을 로드하고, 각 행을 순회하며 문자열 매칭을 수행해야 했다. 6,000건이 넘는 데이터를 처리하는 데 수 분이 소요되었고, 분석 조건을 조금만 바꿔도 전체 프로세스를 다시 실행해야 했다.

앞으로 데이터가 계속 증가할 것이고, 분석의 복잡도도 높아질 것이 분명했다. 현재의 방식으로는 데이터가 10,000건, 20,000건으로 늘어날 때마다 분석 시간이 선형적으로 증가할 것이며, 결국에는 메모리 부족으로 분석이 느리고 어려워질 수도 있었다. 이는 단순한 불편함이 아니라, 프로젝트의 지속 가능성을 위협하는 근본적인 기술적 부채였다.

DuckDB와 Parquet

이때, 분석의 효율과 깊이를 동시에 향상시킬 수 있는 기술적 전환을 결심했다. 그 중심에는 DuckDB와 Parquet이 있다.

DuckDB는 별도의 서버 설치가 필요 없는 '인프로세스(in-process)' 분석용 데이터베이스다. SQLite가 트랜잭션 처리를 위한 OLTP(Online Transaction Processing) 데이터베이스라면, DuckDB는 분석을 위한 OLAP(Online Analytical Processing) 데이터베이스다. 복잡한 SQL 집계 쿼리를 놀랍도록 빠른 속도로 처리해 주어, 마치 로컬 파일에 대고 직접 고성능 데이터베이스 쿼리를 실행하는 것처럼 빠르게 분석할 수 있다.

DuckDB의 진정한 강점은 벡터화된 실행 엔진에 있다. 전통적인 데이터베이스가 한 번에 하나의 행을 처리하는 방식(row-at-a-time processing)이라면, DuckDB는 한 번에 컬럼 단위로 벡터화된 행을 일괄 처리한다. 이를 통해 분석 쿼리를 수 배에서 수십 배 빠르게 수행할 수 있게 한다. 여기에 컬럼 기반 저장 포맷인 Parquet을 더했다. 기존의 CSV가 데이터 전체를 한 줄씩(row-based) 저장하는 방식이라면, Parquet은 데이터를 컬럼 단위로 묶어 저장한다.

분석 작업의 대부분은 모든 컬럼이 아닌, 특정 컬럼만 필요로 한다. '발표 연도별 영상 수 집계'라는 분석을 위해서는 '발표 연도' 컬럼만 있으면 충분하다. 발표자 이름, 영상 설명, 조회수 등의 정보는 전혀 필요하지 않다. CSV에서는 이런 분석을 위해서도 전체 파일을 읽어야 하지만, Parquet은 필요한 컬럼만 선택적으로 읽을 수 있다. 이는 I/O 비용을 극적으로 줄여준다.

더 나아가 Parquet은 각 컬럼을 압축하여 저장한다. 같은 타입의 데이터가 연속적으로 배치되어 있어 압축률이 높고, 데이터 타입에 최적화된 인코딩(예: 정수는 delta encoding, 문자열은 dictionary encoding)을 적용할 수 있다. 실제로 이 전환을 통해 데이터 파일 크기는 51% 감소했고, 분석 쿼리 속도는 수십 배 빨라졌다. 수 분이 걸리던 집계 작업이 이제는 1초 이내에 완료되었다.

벡터 임베딩으로 의미 발견하기

텍스트의 숨겨진 의미를 파악하기 위해 벡터 임베딩을 사용했다. '머신러닝', '딥러닝', 'AI'가 단순히 텍스트로는 다른 단어지만, 의미적으로는 가깝다는 점에 착안한 것이다.

전통적인 키워드 빈도 분석은 한계가 명확하다. "neural network"라는 표현과 "deep learning"이라는 표현은 문자열로는 전혀 다르지만, 의미적으로는 거의 같은 개념을 지칭한다. 반면, "NumPy"와 "Numba"는 문자열로는 비슷해 보이지만, 하나는 배열 연산 라이브러리이고 다른 하나는 JIT 컴파일러로 완전히 다른 역할을 한다. 단순 문자열 매칭으로는 이런 의미적 관계를 포착할 수 없다.

벡터 임베딩은 이 문제의 해답이다. 자연어 처리 모델(예: BERT, Sentence Transformers)을 사용하여 텍스트를 고차원 벡터 공간의 한 점으로 변환한다. 의미적으로 유사한 텍스트는 벡터 공간에서도 가까운 위치에 놓이게 된다. 이를 통해 우리는 코사인 유사도(cosine similarity)와 같은 수학적 방법으로 텍스트 간의 의미적 유사성을 정량화할 수 있다.

파이콘 한국 2025 튜토리얼 실습에서 진행한 텍스트 임베딩후 PCA 시각화 <출처: 박조은>

파이콘 한국 2025 튜토리얼 실습에서 임베딩 프로젝터에 EuroPython 데이터 시각화 <출처: 박조은>

텍스트를 다차원 공간의 벡터 좌표로 변환해서, '비동기 처리'라는 주제 아래 asyncio, FastAPI, Coroutine 같은 기술들이 어떻게 하나의 클러스터를 형성하는지 시각적으로 파악할 수 있었다. K-means나 DBSCAN 같은 클러스터링 알고리즘을 적용하여, 명시적으로 태그되지 않은 발표들을 자동으로 주제별로 그룹화할 수 있었다. t-SNE나 PCA 같은 차원 축소 기법을 사용하여 고차원 벡터를 2~3차원 평면에 투영하면, 파이썬 생태계의 기술 지형도가 한눈에 들어왔다.

단순 키워드 빈도를 넘어, 기술 생태계의 보이지 않는 관계망을 들여다볼 준비를 마쳤다. 파이콘은 전 세계에서 열리지만, 주도를 하고 있는 미국과 유럽, 그리고 한국을 중점으로 분석했다.

데이터로 본 파이썬의 진화

지역별로 어떤 기술을 사용하는지 비교해 볼 수 있지 않을까라는 가설에서 분석을 시작했지만, 미국, 유럽, 한국의 기술 키워드와 트렌드는 크게 다르지 않았다. 미국에서 등장하는 주제가 유럽, 한국에서도 이어지고, 한국에서 먼저 등장하는 키워드도 있었다.

PyCon Korea 실용주의로 글로벌 트렌드를 선도하다

파이콘 한국의 데이터는 글로벌 기술을 빠르게 흡수하여, 한국의 개발 환경에 맞게 실용적으로 적용하는 패스트 팔로워의 모습을 보여준다. 하지만 단순히 '뒤따라가는' 것이 아니라, 특정 영역에서는 글로벌 트렌드를 선도하는 양상도 발견할 수 있었다.

연구에서 운영으로 AI 분야의 진화

AI 분야의 진화가 특히 인상적이다. 2015~2016년경 TensorFlow와 Keras가 처음 소개되던 시기, 발표의 대부분은 기초 개념을 활용한 발표가 주를 이루었다. 이는 당시 딥러닝이 아직 생소한 기술이었고, 커뮤니티가 이 새로운 패러다임을 이해하고 습득하는 데 집중했음을 보여준다. 2017~2018년에는 발표 주제가 구체적인 구현으로 옮겨간다. PyTorch로 이미지 분류 모델 만들기, LSTM을 활용한 시계열 예측 같은 발표가 증가했다. 이는 커뮤니티가 이론적 이해를 넘어 실제로 모델을 구축하고 실험하는 단계로 진입했음을 나타낸다.

그리고 2019~2020년부터 'MLOps'라는 키워드가 급격히 부상한다. 초기 딥러닝 프레임워크 도입 단계를 지나, 모델의 안정적인 배포와 운영을 다루는 MLOps가 빠르게 주요 화두로 자리 잡았다. "모델 버전 관리", "A/B 테스트 기반 모델 배포", "모델 모니터링과 재학습 파이프라인" 같은 주제들이 전면에 등장했다. 이는 AI를 연구의 대상으로만 보지 않고, 실제 서비스에 통합하려는 의지를 보여준다.

그리고 한국의 MLOps 관심이 빠르게 나타났다. 이는 한국 서비스들이 AI 도입에 적극적이었고, 그에 따라 운영상의 문제를 먼저 마주했기 때문으로 해석된다. 실제로 많은 서비스에 PoC(Proof of Concept) 단계의 AI 모델을 프로덕션 환경에 배포하면서 겪은 시행착오들이 발표로 공유되었다.

환각을 넘어 신뢰로 LLM과 RAG

2022년 말 ChatGPT의 등장 이후, 2023년에는 'LLM'(대규모 언어 모델)이라는 키워드가 폭발적으로 증가했고, 2024년에는 'RAG(검색 증강 생성)'가 핵심 키워드로 급부상했다.

RAG는 LLM이 가진 정보의 한계를 극복하기 위한 기술이다. LLM은 학습 데이터에 포함된 정보만 알고 있으며, 학습 이후의 정보나 기업 내부의 비공개 정보는 알지 못한다. 더 심각한 것은 '환각(Hallucination)' 현상이다. LLM이 확신에 찬 어조로 사실이 아닌 정보를 생성하는 이 문제는, 고객 서비스나 전문 상담 같은 신뢰도가 중요한 영역에서 LLM 활용을 가로막는 핵심 장애물이었다.

RAG는 이 문제에 대한 실용적 해법이다. 사용자의 질문이 들어오면, 먼저 조직의 내부 문서나 최신 데이터베이스를 검색하여 관련 정보를 찾는다. 그리고 이 검색 결과를 컨텍스트로 제공하여, LLM이 답변을 생성하도록 한다. 이를 통해 LLM은 자신이 학습하지 않은 최신 정보나 내부 정보를 바탕으로 답변할 수 있고, 환각 현상도 크게 줄일 수 있다. 발표들을 보면 RAG, 벡터 데이터베이스 등 주제들이 다수를 차지했다. 이는 커뮤니티가 단순히 LLM의 놀라운 능력에 감탄하는 단계를 넘어, 이를 실제 비즈니스 문제 해결에 활용하는 단계로 빠르게 진입했음을 보여준다.

웹 개발 FastAPI의 약진과 생산성의 재정의

웹 개발 분야에서는 'FastAPI'의 약진이 두드러진다. 2019년에 처음 출시된 FastAPI는 불과 몇 년 만에 파이콘 한국에서 가장 자주 언급되는 웹 프레임워크 중 하나가 되었다. FastAPI의 인기는 여러 요인이 복합적으로 작용한 결과다.

첫째, asyncio 기반의 비동기 처리로 높은 I/O 성능을 제공한다. 전통적인 WSGI 방식의 동기 프레임워크는 각 요청을 처리하는 동안 스레드나 프로세스가 블로킹되지만, ASGI 기반의 FastAPI는 I/O 작업(데이터베이스 쿼리, 외부 API 호출 등)을 기다리는 동안 다른 요청을 처리할 수 있다. 이는 동시 연결 수가 많은 현대의 웹 서비스에서 큰 이점이다.

둘째, 타입 힌트를 통한 자동 검증과 문서화다. 타입 힌트를 활용하여 입력 데이터의 유효성을 자동으로 검증하고, API 문서(Swagger UI)를 자동으로 생성한다. 이는 개발 생산성을 극대화하는 동시에, 런타임 오류를 줄이고 코드의 가독성을 높인다.

셋째, 현대적인 마이크로서비스 아키텍처(MSA) 환경에 최적화되어 있다. FastAPI는 가볍고 빠르며, 특정 기능에 집중된 작은 서비스를 만들기에 적합하다. 반면, Django는 ORM, Admin 페이지, 인증 시스템 등 풍부한 기능을 제공하는 '풀스택' 프레임워크로, 모놀리식 애플리케이션에 더 적합하다.

파이콘 한국에서 FastAPI 관련 발표가 급증한 것은, 모놀리식 아키텍처에서 MSA에 대한 관심이 높아졌음을 반영한다.

안정성과 재현 가능성의 추구하는 개발 환경

더불어 'Poetry', 'Rye' 같은 안정적인 의존성 관리 도구에 대한 관심도 눈에 띄게 증가했다. 전통적인 pip와 requirements.txt의 조합은 간단하지만, 몇 가지 근본적인 문제가 있다.

첫째, 의존성 해결이 완전하지 않다. pip는 패키지를 설치할 때 의존성 충돌을 자동으로 해결하지 못하고, 마지막에 설치된 버전을 사용한다. 이는 예측 불가능한 환경을 만들고, "내 컴퓨터에서는 되는데 배포 환경에서는 안 돼요" 같은 문제를 야기한다.

둘째, 개발 의존성과 프로덕션 의존성을 명확히 분리하기 어렵다. pytest, black 같은 개발 도구들이 프로덕션 환경에 설치될 필요는 없지만, requirements.txt로는 이를 구분하기 어렵다.

셋째, 재현 가능성이 보장되지 않는다. requirements.txt에 정확한 버전을 명시하더라도, 하위 의존성의 버전은 고정되지 않아 시간이 지나면서 다른 환경이 구성될 수 있다.

Poetry와 Rye 같은 현대적인 도구들은 이런 문제들을 해결한다. pyproject.toml에 의존성을 선언하고, 자동으로 의존성 해결을 수행하며, 모든 의존성(하위 의존성 포함)의 정확한 버전을 lock 파일에 기록한다. 이를 통해 팀원들과 CI/CD 환경에서 완전히 동일한 개발 환경을 재현할 수 있다.

파이콘 한국에서 이런 도구들에 대한 관심이 높아진 것은, 프로젝트의 복잡도가 증가하고 팀 단위 협업이 보편화되면서, 개발 환경의 안정성과 재현 가능성을 얼마나 중요하게 여기게 되었는지를 보여주는 지표다. 더 이상 개인의 로컬 환경에서만 돌아가는 코드로는 충분하지 않다. 팀 전체가 동일한 환경에서 작업하고, CI/CD 파이프라인에서 일관된 테스트가 수행되며, 프로덕션 환경에서 예측 가능하게 동작하는 것이 현대 소프트웨어 개발의 기본 요구사항이 되었다.

PyCon US 언어의 근본을 파고들어 한계를 넘다

파이콘 US는 파이썬 언어 자체의 근본적인 한계를 해결하고, 차세대 기술 표준을 제시하려는 글로벌 커뮤니티의 치열한 고민을 엿볼 수 있는 장이었다.

GIL 중심 구조에서 벗어나려는 기술적 전환

그 중심에는 'GIL(Global Interpreter Lock, 전역 인터프리터 락)' 문제가 있다. GIL은 C파이썬 인터프리터가 한 번에 단 하나의 스레드만 파이썬 바이트코드를 실행하도록 제어하는 메커니즘이다. 왜 이런 제약이 존재하는가?

파이썬이 처음 공개된 1991년 당시, 멀티코어 CPU는 일반적이지 않았다. GIL은 구현의 단순성, 참조 카운팅 기반 메모리 관리의 안전성, C 확장 모듈과의 통합 용이성 등 여러 실용적 이유로 선택되었다. GIL 덕분에 C파이썬의 C 확장 모듈 작성이 상대적으로 쉬워졌고, 이는 NumPy, SciPy 같은 핵심 라이브러리들이 빠르게 개발될 수 있었던 기반이 되었다. 또한 단일 스레드 성능도 최적화할 수 있었다.

하지만 30여 년이 지난 지금, 멀티코어 CPU는 표준이 되었다. 심지어 스마트폰도 6~10코어를 탑재하는 시대다. GIL은 CPU 집약적인 작업(예: 이미지 처리, 과학 계산)에서 멀티코어의 이점을 활용하지 못하게 만드는 제약이 되었다. 이런 작업을 여러 스레드로 병렬화하더라도, GIL 때문에 실제로는 한 번에 하나의 스레드만 실행되어 성능 향상이 거의 없거나, 오히려 컨텍스트 스위칭 오버헤드로 성능이 저하될 수 있다.

다만, I/O 집약적인 작업(네트워크 요청, 파일 읽기 등)에서는 GIL이 큰 문제가 되지 않으며, multiprocessing 모듈을 사용하면 멀티코어를 활용할 수 있다는 점도 언급할 필요가 있다. 이러한 배경에서 GIL을 선택적으로 비활성화하려는 제안(PEP 703: "Making the Global Interpreter Lock Optional in C파이썬")이 2023년에 승인되었다. Sam Gross가 제안한 이 PEP는 파이썬 3.13부터 실험적으로 구현되어, 런타임 옵션으로 GIL을 비활성화할 수 있는 '자유 스레딩(free-threading)' 모드를 제공한다.

단, GIL 제거에는 트레이드오프가 있다. 단일 스레드 성능이 다소 저하될 수 있고, 메모리 오버헤드가 증가하며, 기존 C 확장 모듈들과의 호환성 문제가 발생할 수 있다. 따라서 당분간은 두 모드가 공존하며, 사용자가 상황에 맞게 선택할 수 있게 될 것이다. 파이콘 US 2023, 2024에서 GIL 제거에 관한 다수의 발표와 토론이 이루어졌다.

Rust 성능과 안전성의 완벽한 조화

GIL 제약을 우회하는 방법으로 'Rust'가 주목받고 있다. Rust는 메모리 안전성을 컴파일 시점에 보장하면서도, C/C++과 비슷한 성능을 내는 시스템 프로그래밍 언어다. 파이썬 확장 모듈을 작성하는 전통적인 방법은 C나 C++을 사용하는 것이었다. 하지만 이는 위험한 작업이다. 메모리 관리를 수동으로 해야 하고, 작은 실수도 메모리 누수나 세그멘테이션 폴트로 이어진다. 더욱이, 멀티스레딩 환경에서는 경쟁 조건과 데이터 경합 같은 미묘하고 재현하기 어려운 버그가 발생할 수 있다.

Rust는 이런 문제들을 상당 부분 해결한다. 소유권 시스템을 통해 메모리 안전성을 컴파일 시점에 검증하고, 데이터 경합을 컴파일 에러로 잡아낸다. 안전한 Rust 코드에서는 정의되지 않은 동작이 발생하지 않는다는 강력한 보장을 받는다. 다만, unsafe 블록 내에서는 이러한 보장이 적용되지 않으며, 배열 인덱스 범위 초과나 정수 오버플로우 같은 일부 오류는 여전히 런타임에 패닉을 발생시킬 수 있다.

PyO3는 Rust의 장점을 파이썬에서 활용할 수 있게 해주는 라이브러리다. Rust 코드를 작성하고, maturin 같은 빌드 도구와 PyO3를 사용하면, 이를 파이썬에서 네이티브 모듈처럼 임포트하여 사용할 수 있다. 중요한 점은, 파이썬 객체를 건드리지 않는 순수 계산 작업에서는 GIL을 명시적으로 해제할 수 있어 병렬 처리가 가능하다는 것이다. 단, Rust 코드가 파이썬 객체를 조작할 때는 여전히 GIL이 필요하다.

실제로 여러 프로젝트에서 성능 향상을 입증했다. Pydantic V2는 핵심 검증 로직을 Rust로 재작성하여, 워크로드에 따라 5~50배의 성능 향상을 달성했다(단순한 검증은 낮은 배수, 복잡한 중첩 검증은 높은 배수). Ruff는 파이썬 린터와 포매터를 하나의 도구로 통합하여 Rust로 작성함으로써, 기존의 Flake8이나 Black 대비 10~100배 빠른 속도를 보여주었다.

하지만 Rust 채택에는 트레이드오프가 있다. 학습 곡선이 가파르고, 컴파일 시간이 길며, 파이썬보다 개발 생산성이 낮다. 크로스 컴파일과 패키징도 복잡할 수 있다. 모든 경우에 Rust가 필요한 것은 아니며, Cython이나 Numba 같은 대안도 있다. 따라서 성능이 정말 중요한 병목 지점에서만 선택적으로 사용하는 것이 현실적이다. 그럼에도 불구하고, 극한의 성능이 필요한 프로젝트에서 Rust는 강력한 선택지로 자리 잡고 있다.

데이터 분석의 변화

데이터 분석 분야에서 주목할 만한 변화가 일어나고 있다. 파이썬 데이터 분석의 표준이었던 Pandas가 새로운 도전을 받고 있다. 'Polars'가 그 도전자다. Rust로 작성된 Polars는 특정 워크로드에서 뛰어난 병렬 처리 성능을 보여준다. 대용량 데이터 처리에 최적화된 벤치마크에서 Polars는 Pandas보다 수 배에서 수십 배 빠른 성능을 보이며, 병렬 처리가 효과적인 특정 연산(groupby, join 등)에서는 더 큰 성능 차이를 보이기도 한다.

다만, 데이터 크기, 연산 유형, 하드웨어 환경에 따라 성능 차이는 크게 달라지며, 일부 단순 연산에서는 Pandas가 더 효율적일 수 있다. 이러한 성능 향상은 어떻게 가능한가?

첫째, Rust의 특성이다. Rust는 소유권 시스템을 통한 자동 메모리 관리를 제공하면서도, 가비지 컬렉션 오버헤드가 없다. 제로 비용 추상화 원칙을 따라, 사용하지 않는 기능에 대해 비용을 지불하지 않으며, 효율적인 저수준 최적화가 가능하다.
둘째, 병렬 처리의 적극적 활용이다. Polars는 가능한 경우 데이터 처리 작업을 여러 CPU 코어에 분산시킨다. Pandas는 많은 연산이 단일 스레드로 실행되지만(NumPy의 일부 연산은 멀티스레딩 사용), Polars는 groupby, join, aggregation 같은 작업을 효과적으로 병렬화한다. 다만, 데이터가 작거나 병렬화하기 어려운 연산에서는 오버헤드가 발생할 수 있다.
셋째, 지연 평가다. Polars의 LazyFrame API는 연산을 즉시 실행하지 않고, 쿼리 계획을 먼저 세운다. 전체 쿼리를 분석하여 최적화한 후 실행함으로써, 불필요한 중간 데이터 생성을 피하고, 여러 연산을 효율적으로 결합할 수 있다.

그 기반에는 'Apache Arrow'라는 표준이 있다. Arrow는 컬럼 기반 인메모리 데이터 포맷과 처리 프레임워크로, 여러 데이터 시스템 간의 효율적인 데이터 공유를 가능하게 한다. Polars, DuckDB, Apache Spark 등이 모두 Arrow를 지원한다.

Arrow의 핵심 가치는 '제로 카피' 또는 최소 카피 데이터 공유다. 전통적으로 Pandas DataFrame을 Spark로 보내려면, 직렬화와 역직렬화 과정을 거쳐야 했다. 두 시스템이 모두 Arrow를 사용하면, 이런 오버헤드가 크게 줄어든다. 완전히 사라지는 것은 아니지만(특히 네트워크 전송 시), 동일 프로세스 내에서는 메모리 버퍼를 직접 공유할 수 있어 효율적이다.

Arrow는 서로 다른 언어(파이썬, R, Java, C++)와 시스템(Pandas, Polars, DuckDB, Spark)이 더 효율적으로 데이터를 교환할 수 있게 해주는 중요한 표준으로 자리잡아가고 있다. 하지만 Polars 채택에는 고려할 점들이 있다. Pandas에 비해 생태계가 훨씬 작고, 많은 라이브러리가 Pandas를 전제로 설계되어 있다. API가 다르므로 학습과 마이그레이션 비용이 있으며, 일부 기능이 아직 누락되어 있다. 따라서 Polars는 대용량 데이터 처리에서 특히 유용하지만, 소규모 데이터나 탐색적 분석, 기존 프로젝트에서는 Pandas가 여전히 실용적일 수 있다.

파이썬 데이터 생태계는 Pandas 중심에서 점진적으로 진화하여 더 다양한 선택지를 제공하고 있다. Polars는 Pandas를 대체하기보다는, 특정 사용 사례에서 보완적 도구로 자리잡아가고 있다.

EuroPython 오픈소스 철학과 시스템 운영의 성숙

EuroPython은 유럽 전역의 파이썬 커뮤니티를 대표하는 주요 컨퍼런스로, 다른 파이썬 컨퍼런스들과 마찬가지로 오픈소스와 커뮤니티 가치를 중시하며 다양한 기술적 주제를 다룬다.

관찰 가능성 시스템의 내부를 투명하게

최근 몇 년간 '모니터링'을 넘어 '관찰 가능성(Observability)'이라는 개념이 점차 중요해지고 있다. 이 두 개념의 차이는 무엇인가?

전통적인 모니터링은 "시스템이 다운되었는가?", "CPU 사용률이 80%를 넘었는가?" 같이 미리 정의된 질문에 답하는 데 초점을 맞춘다. 우리가 무엇을 측정할지 미리 알고 있을 때 유용하다. 하지만 복잡한 분산 시스템에서는 가능한 모든 문제를 미리 예측하여 알림을 설정하기 어렵다. 물론 현대의 모니터링 도구들도 임시 쿼리와 동적 분석을 지원하지만, 실무에서는 두 개념이 혼용되는 경우가 많다.

관찰 가능성은 시스템의 내부 상태를 추론할 수 있게 하는 것을 목표로 하는 접근 방식이다. 주로 로그, 메트릭, 트레이스라는 세 가지 신호를 활용하여, "왜 특정 사용자에게만 응답이 느려졌는가?", "어떤 코드 변경이 이 오류를 일으켰는가?" 같이 예상치 못한 질문에 답할 수 있게 한다.

로그는 특정 시점에 발생한 이벤트를 기록한다. "사용자가 로그인했다", "데이터베이스 연결 실패" 같은 텍스트 메시지다. 메트릭은 시간에 따라 변하는 수치 데이터다. CPU 사용률, 요청 처리 시간, 에러 발생 횟수 등이다. 트레이스는 하나의 요청이 여러 서비스를 거쳐 가는 전체 경로를 추적한다. 마이크로서비스 아키텍처에서 특정 요청이 어떤 서비스들을 어떤 순서로 거쳐 갔고, 각 단계에서 얼마나 시간이 걸렸는지 파악할 수 있게 한다. 이 외에도 프로파일링 데이터, 이벤트, 컨텍스트 정보 등 다양한 신호가 활용될 수 있다.

OpenTelemetry는 이런 관찰 가능성 데이터를 수집하고 전송하는 사실상 표준으로 자리잡아가고 있는 CNCF 프로젝트다. 특정 벤더(Datadog, New Relic 등)에 종속되지 않고, 표준화된 방식으로 로그, 메트릭, 트레이스를 수집할 수 있게 한다. 코드에서 OpenTelemetry API를 사용하면 벤더 종속성을 줄이고, 백엔드 시스템 교체를 상대적으로 용이하게 할 수 있다. 다만, 벤더별 고유 기능을 사용하거나 설정 및 대시보드를 재구성할 때는 여전히 마이그레이션 작업이 필요하다.

그러나 관찰 가능성 도입에는 트레이드오프가 있다. 성능 오버헤드, 데이터 스토리지 비용 증가, 학습 곡선, 운영 복잡도 증가 등을 고려해야 한다. 완벽한 관찰 가능성을 달성하는 것은 비용이 많이 들며, 모든 조직에 필요한 것은 아니다. 소규모 서비스나 단순한 아키텍처에서는 전통적 모니터링만으로도 충분할 수 있다.

하지만 대규모 분산 시스템에서는 관찰 가능성이 매우 중요하다. 파이썬은 처음부터 범용 프로그래밍 언어로 설계되었으며, 현재는 복잡한 클라우드 네이티브 환경에서도 신뢰성 높은 서비스를 운영하는 데 중요한 역할을 하고 있다. EuroPython을 포함한 주요 파이썬 컨퍼런스들에서 OpenTelemetry와 관찰 가능성 주제가 다뤄지는 것은, 파이썬 커뮤니티가 이러한 운영 성숙도의 진화에 적극적으로 참여하고 있음을 보여준다.

마치며: 세 가지 흐름으로 본 파이썬의 미래

10년간 유튜브에 업로드된 각 지역의 파이콘 데이터를 통해, 파이썬 생태계의 주요한 세 가지 변화를 볼 수 있었다.

첫째, AI가 연구 중심에서 실용 중심으로 전환되고 있다

딥러닝 프레임워크의 초기 도입 단계를 지나, 커뮤니티의 관심은 "어떻게 모델을 학습시키는가"에서 "어떻게 모델을 안정적으로 배포하고 운영하는가"로 옮겨가고 있다. MLOps를 통한 운영 체계화, RAG를 통한 실용적 문제 해결은 파이썬이 AI 개발과 배포에서 중요한 역할을 하고 있음을 보여준다.

특히 LLM의 등장은 AI 활용의 진입 장벽을 낮췄다. API를 통해 강력한 AI 기능을 서비스에 통합할 수 있게 되었다. 하지만 동시에 환각, 프라이버시, 비용 같은 새로운 도전 과제도 등장했다. 파이썬 커뮤니티는 이런 문제들에 대한 RAG, 프롬프트 엔지니어링, 로컬 LLM 등의 실용적 해법을 모색하고 있다.

둘째, 파이썬의 성능 한계를 극복하려는 노력이 진행 중이다

GIL 선택적 비활성화 논의, Rust와의 연계, 그리고 Polars와 Arrow 같은 고성능 데이터 처리 도구의 등장은 파이썬이 성능 개선에 적극적으로 대응하고 있음을 보여준다.

중요한 것은, 파이썬이 저수준 언어가 되려는 것이 아니라는 점이다. 대신 "고수준의 생산성은 유지하되, 성능이 중요한 부분만 최적화를 적용한다"는 하이브리드 접근법을 택하고 있다. Rust로 작성된 핵심 로직을 파이썬으로 감싸는 것, PyO3로 파이썬과 Rust를 연결하는 것, Polars와 DuckDB 같은 고성능 라이브러리를 파이썬 인터페이스로 제공하는 것이 이런 전략의 예시다.

결과적으로, 개발자는 파이썬의 간결하고 표현력 높은 문법으로 코드를 작성하면서도, 필요한 부분에서는 향상된 성능을 얻을 수 있다. 다만, 모든 성능 문제가 해결된 것은 아니며, 여전히 워크로드에 따라 적절한 도구를 선택해야 한다.

셋째, 생태계가 안정성과 운영 성숙도를 향해 발전하고 있다

안정적인 개발 환경을 위한 의존성 관리 도구(Poetry, Rye, uv), 시스템 모니터링과 관찰 가능성(OpenTelemetry)에 대한 관심 증가는 파이썬이 대규모 프로덕션 환경에서도 활발히 사용되고 있음을 나타낸다.

이는 파이썬 커뮤니티가 성숙해지고 있음을 의미한다. 새로운 기술 탐색과 더불어, 지속 가능하고 유지보수 가능한 시스템 구축에도 집중하고 있다. "빠르게 프로토타입을 만든다"는 파이썬의 전통적 강점에, "안정적으로 운영하고 확장한다"는 관심이 더해지고 있다.

이 분석이 파이썬을 사용하는 개발자들에게 현재 트렌드를 이해하고, 미래를 준비하는 데 도움이 되기를 바란다. 파이썬 생태계는 지금도 계속 진화하고 있다. 10년 전, 파이썬은 주로 웹 애플리케이션 개발, 데이터 분석, 머신러닝 실험에 사용되었다. 오늘날에는 대규모 AI 서비스 운영, 빅데이터 처리, 복잡한 분산 시스템 관리에도 활용되고 있다. 다음 10년은 어떤 변화를 가져올지 지켜보는 것도 흥미로울 것이다.