작년에 이어 올해도 피츠버그에서 열린 PyCon US에 다녀왔다. 작년에는 발표가 선정되지 않기도 했고 미국 동부 여행까지 붙여서 정말 휴가 컨셉으로 다녀왔는데, 올해는... 너무나 바빠져서 아예 발표 신청서를 제출조차 못했다. T_T 게다가 NVIDIA GTC 기간에 우연찮게 참여하게 된 Python WheelNext 워킹그룹에 조인하여 Packaging Summit에도 참가하고, Python 3.14에 추가될 예정인 remote debugging 기능과 asyncio 디버깅 기능 관련하여 이를 aiomonitor에 통합하고 free-thread build를 테스트해보는 등 여러 스프린트에서 동시에 참여 요청이 와서 어쩐지 휴가 같았지만 출장이 되어버린 느낌이다.

Sponsor Talk

작년에는 사실 거의 보지 않았는데, 올해는 NVIDIA, Meta, Pydantic, Snowflakes 등 Python을 활용하거나 지원하는 기업들의 스폰서 세션 발표 주제들이 흥미로운 게 많아서 하루종일 스폰서 세션 톡들을 들었다.

• (NVIDIA) Accelerated Python: The Community and Ecosystem

  • NVIDIA는 Python이 명실공히 "AI 프로그래밍 언어"가 되었다는 사실을 받아들여 작년부터 PyCon US visionary sponsor를 진행하고 있다. 그래서 CUDA를 사용하는 패키지들의 배포를 원활하게 하기 위한 WheelNext 그룹에도 열심히 참여하고 있고, CUDA 프로그래밍 자체를 Python 상에서 바로 할 수 있도록 JIT 컴파일 방식으로 동작하는 공식 cuda 라이브러리도 개발하고 있다. 이 발표는 후자를 중심으로 Python과 CUDA 생태계의 결합에 대해 주로 다루었다.

• (Heroku) Building Scalable AI Tool Servers with Model Context Protocol (MCP)

  • 현재 MCP는 주로 Anthropic의 Claude Desktop 앱이나 CLI 모드를 이용해서 로컬 도구들을 호출하는 방식인데, 그러면 사용자가 직접 MCP tool들을 설치해주어야 하고, 보통은 해당 사용자의 데스크탑 환경을 동일한 권한으로 모두 접근할 수 있기 때문에 악의적인 MCP tool을 잘못 사용하면 개인정보 유출 문제나 언어모델의 확률적 동작으로 인한 시스템 오작동 등의 이슈가 있을 수 있다. 그래서 이런 MCP tool을 heroku의 오케스트레이션 스택에 올려 서버사이드에 호스팅하는 것에 관한 내용을 소개하였다.

• (Meta) High-Performance Python Type Checking and Free Threaded Execution

  • pyrefly 프로젝트에 대한 소개와, 메타에서 그동안 진행해온 free-threading 관련 작어들을 소개하는 발표였다. (순서는 이 반대였다) Free-threading (또는 "nogil" 빌드) 이게 가능해진 이유는 biased reference counting (BRC)이라는 아이디어가 나오면서다. BRC의 핵심 아이디어는, 여러 스레드가 공유하는 객체라 하더라도 실제로는 대부분의 접근이 특정 하나의 스레드에서만 발생하는 경우가 많다는 것에 착안하여, 원자적 업데이트가 이뤄지는 카운터와 비원자적 업데이트가 이뤄지는 카운터를 따로 두고 전자는 여러 스레드가 공유하되 후자는 특정("biased") 스레드가 독점하게 하여 lock contention이 확률적으로 드물게 발생하게 만듦으로써 성능을 끌어올리는 것이다. 이 발표에서는 BRC와 함께 CPython 3.13/3.14에 적용된 여러 멀티스레드-친화 아이디어들을 소개하였다.

• (Pydantic) Building AI Applications the Pydantic Way

  • 큰 기대는 하지 않았지만 생각보다 인상깊었던 발표였다. pydantic 라이브러리를 만든 Samuel Colvin은 몇년 전부터 스타트업을 차렸는데, pydantic 자체는 계속 오픈소스로 개발하면서 이걸 활용한 logfire라는 SaaS를 만들어 파이썬 생태계의 다양한 패키지들(aiohttp, httpx, requests, django, wsgi, asgi, psycopg, asyncpg, sqlite3, redis, mysql, ...)과의 기본 통합을 제공함으로써 매우 쉽게 observability 대시보드를 만들어준다. 이번 발표에서는 Anthropic이나 OpenAI 라이브러리를 instrument하여 AI 쿼리의 토큰 사용량 모니터링이나 MCP 호출 횟수나 지연시간 등을 실시간 모니터링해주는 기능을 시연과 함께 보여주었다. 특히 "span" 개념을 활용해서 여러 계층적 API 호출이나 프레임워크 내부의 스택에서 실제로 어느 지점이 얼만큼 시간이 걸리는지 이런 것들을 보기 좋게 시각화해주는 부분이 인상적이었다. 다른 사람들도 DX (develope experience) 측면에서는 굉장히 훌륭한 솔루션이라는 평가가 많았다.

Typing Summit & Packaging Summit

한국이나 기타 다른 지역 파이콘에서는 거의 열리지 않지만 '본산'인 미국 파이콘에서 주로 열리는 다양한 Summit 프로그램들이 있다. Typing Summit, Education Summit처럼 사전 신청·초대 없이도 그냥 가서 참여할 수 있는 것들도 있고, Language Summit처럼 코어 개발자나 커뮤니티에서 아주 유명한(Python 사용자라면 누구나 알 만한 정도) 라이브러리를 개발하고 있다거나 한 사람들만 초대받아 갈 수 있는 것도 있다. 보통 이러한 Summit들은 해당 주제에 관심있는 사람들이 모여서 사전에 별도로 신청·선정한 주제 발표를 짧게는 3~4개, 길게는 6~7개 정도 포함하는데, 경우에 따라서는 Council 구성이나 오픈소스 조직 운영 절차·계획에 대한 논의 및 최근 진행사항 공유 등도 이루어진다. 말미에는 운영자나 모더레이터가 여러 개의 소주제 그룹으로 나누어 30분에서 1시간 정도 좀더 집중적인 자유토의를 진행하거나 기념사진을 찍는 경우도 있다.

내가 참여한 것은 이 중에서 Typing Summit과 Packaging Summit이었다.

Typing Summit

여러 주제의 발표들이 있었지만(사실 시차 문제로 중간에 졸아서 딱 ty/pyrefly 발표 말고는 기억이 ㅠㅠ), 장안의 화제는 Astral에서 Ruff에서 분기하여 개발한 새로운 타입체커인 ty와 Meta에서 기존 Ocaml 기반으로 개발한 pyre를 Astral이 개발한 Rust 기반 parser 기반으로 재작성한 pyrefly였다. 이 둘은 같은 parser를 공유하지만 그 구현과 접근 방법이 굉장히 달랐다.

Ty는 Salsa라 불리는 incremental computation 프레임워크를 사용해서 매우 세밀하게 코드 조각과 scope들의 의존성을 바탕으로 필요한 영역만 타입검사를 실행하는 방식이고, pyrefly는 기존의 Ocaml 구현체를 Rust로 재작성하면서 그 디자인 철학을 계승하여 사용자가 타입 주석을 덜 적었더라도 공격적으로 타입추론을 실행하는 방식을 택하고 있다.

둘 다 속도는 굉장히 빨랐다. 내 M4 Pro 맥북 기준으로 Backend.AI 오픈소스 모노리포 전체 1086개 소스 파일 검사에 ty는 약 1.8초, pyrefly는 2.2초 (mypy 1.16 기준 4.3초) 정도 걸렸다. 셋 다 모두 여러 번 반복 실행하여 캐시가 적용된 상태 기준이며, ty와 pyrefly는 첫 실행과 반복된 실행이 크게 차이가 나지 않았지만 mypy는 캐시를 끄면 11~13초 정도 걸렸다. ty의 경우 아직은 typed dict 추론이 제대로 안 된다든지 하는 식으로 빠진 기능들이 있어 바로 적용은 어려워보였지만, Astral 프로젝트들 자체가 현재 파이썬 커뮤니티에서 큰 인기를 끌고 있으므로 사람들의 관심빨로 곧 해결되지 않을까 싶다.

Packaging Summit

PyPI (Python Package Index) 구축에도 오랜 기간 기여해왔고 최근에는 NVIDIA에서 Python 관련 각종 엔지니어링 총괄을 맡고 있는 Barry Warsaw (@warsaw)와 마찬가지로 CUDA Python 지원 관련 업무를 맡고 있는 Jonathan Dekhtiar (@DEKHTIARJonathan) 두 분이 주요 모더레이터로 진행한 Summit이었다.

GTC 가서 참여하게 된 WheelNext 그룹은 좀더 세부적으로 Python의 패키징 파일 형식인 wheel(.whl 확장자 파일들)의 차세대 규격을 논의하는 모임이고, Packaging Summit은 좀더 일반적으로 Python에서 다양한 패키지를 배포하거나 사용하는 사람들까지 아우르는 성격을 갖고 있다. 한국분으로는 NVIDIA에서 XGBoost 라이브러리의 maintainer를 담당하고 있는 조현수님도 WheelNext 미팅에서 이미 두 차례 이야기를 나눴는데 여기서 다시 만날 수 있기도 했다.

• Packaging Council 구성 계획
  • Barry가 PEP-XXX Python Steering Council 운영절차를 준용하여 패키징 관련 이슈들을 전담하여 다루는 council 구성을 제안하였다. 여기서 가장 큰 쟁점은 주요 의사결정에 참여할 수 있는 voting member의 범위가 어디까지인가 하는 점인데, "좀더 넓은 범위의 커뮤니티 참여자들"이라는 다소 모호한 표현 때문에 약간의 갑론을박이 있기도 했다.
• WheelNext 프로젝트 소개
  • Jonathan이 별도의 메인 세션 발표로도 이야기했지만, WheelNext 그룹에서 다루고 있는 주요 주제들을 요약 소개하였다.
  • 특히, variantlib의 주요 디자인과 현재 구현된 동작 방식을 중심으로 다수의 variant property 속성을 임의의 개수만큼 추가할 수 있도록 일관된 방법으로 나열한 속성값들의 hash 값을 wheel 파일명에 포함된 플랫폼 태그로 삼고, 이것을 key로 하는 key-value 테이블을 variants.json이라는 추가 파일 형태로 package index를 통해 서비스하는 것이 핵심 아이디어이다.
• Quick Plugs
  • 정식 주제 발표가 아니더라도 참가한 사람들 누구나 자유롭게 3~5분 정도 라이트닝톡처럼 자신이 겪고 있는 문제나 아이디어들을 소개하는 시간이 따로 있었다.
  • 나도 얼른 그 자리에서 1장짜리 슬라이드를 만들어서 다음과 같은 아이디어 제안을 하였다.
    • "Splitbrain" 실험 : 원래 시작은 scie 기반으로 Backend.AI 서버 데몬들을 배포하려고 보니 엔터프라이즈 전용 플러그인들을 인식·적재하려면 wheel 파일들을 임시 디렉토리에 압축해제한 후 sys.path를 조작하여 강제 인식시키는 트릭을 써야 했다. 나름대로 잘 동작은 하지만, 플러그인의 의존성 트리와 메인 프로그램의 의존성 트리가 동일한 패키지를 참조하되 다른 버전을 참조하는 경우 미묘한 호환성 문제가 발생할 가능성이 있다는 문제가 있다. 현재로서는 개발자가 이런 문제가 생기지 않도록 직접 손으로 검증할 수 밖에 없는데, 여기서 착안한 것이 virtualenv를 다르게 가지는 subinterpreter를 하나의 Python 프로세스 안에 두는 방식으로 플러그인과 본체의 의존성 트리를 독립적으로 만들 수 있지 않을까? 하는 아이디어였다.
      • 사실 이 이슈는 variantlib 개발 과정에서도 맞닥뜨렸던 요구사항이다. 현재 차세대 패키지 설치 표준이라 할 수 있는 pyproject.toml을 통해 정의하는 build backend 기능을 사용할 때도 마찬가지다. 따라서 이들을 예로 들며 3rd party tool의 virtualenv를 분리하면서도 이를 하나의 Python 프로세스 안에서 실행할 수 있으면 어떨까 이야기했다.
      • 여기서 아직 기술적으로 해결해야 하는 문제로, 임의의 Python 패키지들이 native 모듈을 불러올 때 dlopen()의 플래그를 임의 지정할 수 있기 때문에 항상 namespace 기반 dlmopen()이나 RTLD_LOCAL을 사용한다는 보장이 없다는 점이다. 즉, Python 모듈들은 subinterpreter로 격리가 된다 하더라도 native symbol들은 여전히 충돌 문제가 발생할 수 있다. 앞으로 이러한 것을 packaging 규격의 일부로 강제 또는 권장해야 할 가능성에 대해 이야기하였다.
      • Eric Snow (@ericsnowcurrently) 또한 본인이 개발해온 subinterpreter의 새로운 응용 방안으로 관심을 보여주었다.
    • 하나의 Python 패키지에 대해서 단일 버전을 나타내는 whl 파일들이 다수(수십 개 이상)의 variant로 구성될 경우 대부분 바이너리 모듈만 다르고 나머지는 공통 요소로 존재하게 되는데, 이것을 컨테이너 레지스트리처럼 layered manifest/blob 방식으로 서버 상에서 표현함으로써 PyPI와 네트워크 부하를 줄이면 어떨까?
      • 발표 후에 PSF Fellow 등을 역임한 적이 있던 Jannis Leidel (@jezdez)가 좋은 아이디어라며 conda 쪽에도 유사한 시도가 최근에 있으니 찾아보라고 알려주셨다. 근데 막상 GitHub 저장소를 찾아보니 아직은 거의 실질적인 프로토타이핑이 진행되지 않은 상태였다. 나도 급하게 던져본 아이디어라도 구체적인 세부사항을 정의한 상태는 아니지만 variant 규격이 일반화되면 분명히 이슈가 될 수 있다 생각하고 미리 대비가 필요하다는 점 자체를 사람들 머릿속에 심는 것을 1차 목표로 하였다.

Lightning Talk

발표 신청조차 못한 대신(...) 작년 파이콘 한국에서 진행한 키노트 발표 "PyCon과 나의 10년 돌아보기"를 5분짜리 라이트닝톡으로 압축해서 발표하였다. 아무래도 길게 하고 싶은 말 다 하는 발표보다 정확히 5분 안에 맞춰야 하는 발표라 전날 미리 스크립트 써서 연습하고 분량조절도 해두고 나름 만반의 준비를 했다고 생각했는데, 정작 Arc 브라우저에서 Google Slides의 발표자보기 모드를 제대로 지원하지 않아서 AV팀과 한참 삽질하다가 결국 PowerPoint 포맷으로 다운로드해서 간신히 발표할 수 있었다. 발표 자체는 무난하게 진행하였지만 역시 발표도구는 평소에 익숙한 걸 써야 한다는 교훈을 얻었다. 사실 웬만하면 파워포인트를 쓰는 편이지만 작년 한국 파이콘 때 구글 슬라이드로 작업해둔 걸 그대로 가져왔다가... ㅠ_ㅠ 발표하는 장면을 파이콘 일본 커뮤니티의 테레다 상이 사진으로 멋지게 남겨주셨다.

Open Space

Astral.sh

ty, ruff, uv로 주제를 나누어 AMA (ask me anything) 하는 시간으로 진행되었다. 나는 uv를 모노리포 같은 구조로 사용하면 단일 저장소 내에서 다른 하위 디렉토리(별도의 pyproject.toml을 가지는 workspace)의 코드를 실행할 때마다 uv가 암묵적으로 .venv 디렉토리를 매번 새로 갈아치우는 문제에 대해 물어보았는데, venv는 휘발적인 임시 파일처럼 간주하는 설계 철학 때문이라고 한다. Backend.AI처럼 대규모 코드베이스에서는 이런 방식이면 다소 쓰기 어렵고... 내부 의존성 관리 같은 것까지 깊게 지원하지 않으면 당분간 uv를 모노리포 관리도구로 고려하는 건 어려워보였다. ㅠㅠ 회사 동료분의 요청으로 ty, uv와 같이 왜 두 글자 이름을 고집하는지도 물어보았는데 그냥 짧고 타이핑하기 쉬워서라는 간단한 답변을 들었다.;;

아직도 Python 2.x를 지원해야 하는 사람들 모임

이건 왠지 제목을 보고 안 가면 안 될 것 같았다. (...) 사실 나는 다행히도(!) Python 2.x를 계속 지원해야 하는 상황은 아니지만, 나름 엔터프라이즈 솔루션을 개발하고 공급하는 입장에서 이런 종류의 이슈들을 꽤 겪어보기도 했고 실제로 이 문제를 파이썬 커뮤니티에서 어떤 사람들이 맞닥뜨리고 있는지 알고 싶기도 했다. 모임에 참여한 사람들은 대부분 대학이나 연구기관에서 연산 클러스터를 운영하는 사람들이었는데, 사실 이 문제에 대해서 뾰족한 해결책이 있는 건 아니었고 다들 동병상련의 자리에 가까웠다. 결국은 사용자들과의 소통이 중요하다는 훈훈한 마무리.

관심 갔던 주요 발표들

주로 asyncio, packaging, free-threading 관련 발표들을 찾아보았다. 몇몇은 직접 들어가서 보기도 했고, 몇몇은 다른 일정과 겹쳐서 나중에 온라인으로 찾아보기도 했다.

• Zoom, Enhance: Asyncio's New Introspection Powers

  • Python 3.14에서는 remote debug 기능이 추가되어서 기존 실행 중인 파이썬 프로세스의 메모리를 인터프리터의 실행 중간에 '안전하게 실행할 수 있는 시점'에 코드를 주입하는 방법으로 원격 디버깅이 가능해진다. 기존에는 pdb 패키지를 이용해서 반드시 명시적인 tracing mode 진입을 하거나 aiomonitor처럼 별도로 라이브러리를 개발해서 inspection API를 만들어서 써야 했지만, 이제는 원본 프로그램의 변경 없이도 live inspection을 할 수 있는 길이 열린 것이다.

    이 발표에서는 이걸 활용하여 aiomonitor에서 제공하는 것과 유사한 task 별 stack frame 및 task 간 호출 관계를 트리와 테이블 형태로 보여주는 python -m asyncio pstree 및 python -m asyncio ps 기능을 소개해주었다.

• Reinventing the Wheel: A Community-Driven Roadmap for Python Packaging

  • WheeNext 그룹의 organizer 중 한 명인 Jonathan의 발표로, 워킹그룹에 대한 소개와 함께 현재 다루고 있는 주요 이슈들 및 variantlib의 디자인에 대해서 소개하는 발표였다.

• Using Rust in Free-Threaded vs Regular Python 3.13

  • 현재 Python에서 Rust로 작성한 모듈을 불러다 쓰는 방법으로 가장 널리 쓰이는 것이 pyo3인데, 이걸 free-thread 버전에서 사용할 때 고려할 점이나 예제들을 소개하는 발표였다. Rust 쪽에 노출되는 파이썬 상태값의 장기간 참조를 들고 있을 때 reference 검사를 생략하고 프로그래머가 직접 internal lock을 관리할 수 있도록 하는 frozen 매크로 추가도 소개하고, immutable 데이터 구조를 보다 적극적으로 활용해야 한다는 점을 강조하였다.

• Unraveling Community Support For Free-Threaded Python

  • Free-threading을 전면적으로 도입하기 위해서는 C/C++ 및 Rust 등으로 작성된 기존 native 모듈 기반의 패키지 생태계가 모두 따라와줘야 가능하다. 패키지 제작자들의 노력도 필요하지만, 기본적인 빌드 세팅을 성공했다 하더라도 실제 환경에서 돌려봐야만 알 수 있는 미묘한 멀티스레딩 버그들도 있을 수 있기 때문에 커뮤니티 전체가 함께 테스트해볼 것을 주문하는 발표이기도 했다. 이를 위해 thread sanitizer나 cache 정보와 같이 여러 스레드가 동시 변경할 가능성이 있는 자료구조를 다루는 방법도 소개하였다.

• Building a NoGIL Load Balancer in 30 minutes

  • Free-threading 환경의 이점을 살려서, multiprocessing을 쓰지 않고 기본 파이썬 threading 패키지만 사용해서 간단한 피보나치 값 계산 서버를 만들고 소켓 기반 로드밸런서를 통해 어떤 성능 특성이 있는지 예시로 설명해주었다. 거의 계산을 하지 않는 "1"을 입력으로 줄 때는 큰 차이가 벌어지지 않지만, "30"과 같이 CPU 계산이 많이 들어가는 입력을 주면 확실히 멀티코어에서 nogil 빌드를 사용할 때 상대적인 성능 저하가 낮게 발생하는 모습을 보여주었다.

• The past, present, and future of virtual environments

  • Astral의 개발자 Zanie Blue의 발표 세션이었다. Python으로 만든 소프트웨어를 실전 배포할 때 필수적으로 알아야 하는 개념 중 하나가 가상환경(virtual environment; 줄여서 virtualenv 또는 venv라고 주로 부른다)이다. 처음 Python을 사용하는 사람들은 시스템 전역 패키지로 원하는 라이브러리 패키지들을 설치하는 경우가 많지만, 이렇게 하면 각 Python 프로그램마다 원치 않는 버전의 패키지를 사용하게 되어 쉽게 고장나게 된다. 이를 방지하기 위해 인터프리터는 공유하면서 패키지 공간을 격리해주는 venv 기술의 역사적 배경과 uv에서 앞으로 이를 어떻게 잘 추상화해서 다루고자 하는지 소개해주었다.

UN 본부 방문

원래는 작년에 방문했던 필라델피아 사는 친구 준호와 캠핑까지 갈까 계획했었지만, 싱가포르 출장 일정이 잡히는 바람에 그냥 하루 집에서 묵기만 하고 뉴욕에서의 휴가도 원래 3박 예정이었던 것을 1박으로 줄여서 진행하게 되었다.

그래서 그 하루의 소중한 시간을 어떻게 알차게 보내야 하나 했는데, 결국은 2가지로 정할 수 있었다. 하나는 출장일정이 미친 듯이 잡혀버린 바람에 사전투표와 본투표 모두 못하게 된 대통령선거의 국외부재자 투표였고, 다른 하나는 아래 사진에서 보는 것처럼 UN 본부에 방문하는 것이었다. 이번에는 필라델피아에서 NJ Transit 대신 Amtrak의 고급 열차를 타고 갔더니 중간에 기차 다 내리고 바꿔태우고 하는 불상사 없이 편안하게 뉴욕에 도착해서 바로 점심 간단히 먹고 호텔에 짐 맡겨두고 뉴욕 총영사관에 투표부터 하러 갔다. 그런 다음 여유있게 유명한 카페 하나 들러서 인생 가장 맛있는 카푸치노 한잔 한 뒤(라떼류는 개인적으로 웬만한 미국·유럽 카페 모두 마음에 들게 하는 곳이 잘 없는데 뉴욕 정도 되니까 있더라...) UN 본부로 갔다.

UN 본부는 예전에 서상현님을 통해 사전에 가이드 투어 신청하면 내부 회의장들도 관람이 가능하다고 해서 미리 신청해두었는데 그 덕을 톡톡히 봤다. 사실 영화나 뉴스에서 어느 한 장면 장면 확대된 모습만 보다가, 실제로 하나의 연속된 공간으로 체험을 하니 그 느낌이 확 와닿았다고나 할까. 중세 유럽에서는 로마와 바티칸이 일종의 세계 수도에 가까운 역할을 하다가 르네상스와 대항해시대로 넘어오면서 서유럽의 다양한 도시들이 그 자리를 대체해나갔다고 할 수 있을 텐데, 종교나 특정 정치 권력에 소속되지 않은 '중립적 관점'에서의 세계 수도 역할을 하기 위해 디자인된 1950년대의 모더니즘 건축은 그 느낌이 굉장히 특이했다. 약간은 사회주의 국가들에서 보이는 대규모 국가 건축물들의 느낌도 살짝 났다. 일부러 특정 사상을 배제하고 인류애, 포용, 평화를 강조하기 위해 만들어진 공간이고, 각국에서 기증한 다양한 예술품들을 전시해놓은 것도 인상적이었다. 메인 로비에는 구소련에서 기증했을 스푸트니크 실물 모형도 걸려있었다. 스케일이나 인테리어 면에서는 이게 1950년대 지어진 건물이라는 것이 믿기지 않을 정도로 어떤 시대를 초월했다는 감각도 있었고, 한편으로는 생각보다 회의장 의자들이 닳아있다든지 이런 걸 보아 예산을 타이트하게 아껴쓰는구나 싶기도 했다.

약 1시간 정도 진행되는 영어 가이드 투어는 한국분이 진행해주셨는데, 한국어·영어·일본어·스페인어 4개 국어가 가능하다고 했다. 커버할 내용이 많아서 숨가쁘게 설명하셨는데 엄청 힘드실 듯... 투어를 통해 안전보장이사회·신탁통치이사회·경제사회이사회 및 총회 이렇게 4개의 주요 회의장을 둘러볼 수 있었는데, 세계적인 전쟁 이슈가 많은 상황이라 안보리는 비공개 회의 중이어서 직접 들어가서 볼 수는 없었다. 가이드만 잘 따라다니면 사진 촬영도 자유롭게 할 수 있었고(단, 영상 촬영은 불가) 생각보다 회원국 국민으로서(?) 대접받는다는 느낌이었다.

마무리

글을 쓰기 시작한 건 6월 초였는데, 위에서 언급한 것처럼 미쳐버린 출장 일정으로 이걸 5월 24일에 PyCon US에서 한국으로 돌아온 후 3번째(!) 해외출장 가는 비행기 안에서야 겨우겨우 마무리하고 있다. 그 사이에 싱가포르 일주일 갔다가 미국 서부 산타클라라에 일주일 갔다가 일주일 잠깐(...) 한국에 있다가 이번엔 다시 인도네시아 자카르타와 베트남 호찌민으로 출장을 와있다. 🫠

3년째 PyCon US에 참가하면서 계속 얼굴을 비추니 이제 그쪽 사람들도 "아, 이 친구는 이제 여기 오는 사람이구나-" 하고 받아들여주는 듯한 인상을 받는다. 동시에, 여러 계기로 WheelNext 그룹이나 Packaging Summit과 같은 활동에도 참여하게 되니 뭔가 단순 참관이 아니라 할일을 하러 가는 기분(시작은 분명 휴가였는데...)도 난다. ㅋㅋ

아침식사 때나 점심식사 때 테이블에 같이 앉는 랜덤한 참가자들하고 스몰톡을 해보면 아예 처음 와보는 학생이 대부분 비율을 차지했고, 간혹 나같은 고인물이나 혹은 아예 나이 지긋하신 분들이 무슨 대단한 스타트업 이런 걸 하지 않고 지역에서 소소하게 SI 비즈니스하면서 파이썬 커뮤니티에 기여·참여하는 경우들도 있었다. 이런 분들하고 이야기하다보면, 함께 갔던 배권한님이나 나동희님하고도 했던 이야기인데, 왜 이렇게 한국에서 아둥바둥 하며 살아야 하나... 싶은 현타가 살짝 온달까. 머리카락 희끗하면서도 재미있게 코드 이야기 하는 미국 사람들을 보면 그래서 부럽기도 하다. 이것이 단순히 시장 크기의 문제인지 문화적·사회적 차이인지 모르겠지만, 우리나라도 개발자나 기술자들이 나이 들도록 하고 싶은 일을 꾸준히 즐기면서 할 수 있는 환경이 마련되었으면 좋겠다는 생각이 들었다.