개요

지난 주말, PyGotham의 초청으로 맨해튼에서 열린 연례 컨퍼런스에서 발표를 했다. 행사에서 얻는 것을 최대화하기 위해 참석하며 배운 내용을 정리한 노트를 준비했다. 다른 사람들에게도 흥미롭거나 유용할 수 있기를 바라며 이를 공유한다.

평점 및 리뷰

발표의 질

올해 발표들의 전반적인 수준에는 다소 실망했다. 마음에 들었던 발표도 몇 개 있었지만(아래 참조), 실망스러운 발표가 많았다.

문제의 일부는 내가 타깃 청중이 아니라는 점이다. 머신러닝 발표가 많은 비중을 차지했는데, 머신러닝 자체는 흥미롭다고 생각하지만 업무에 활용하지 않기 때문에 입문용 머신러닝 발표는 이미 충분히 들었다는 느낌이 들었다.

행사 운영

PyGotham 운영진이 행사를 마치 잘 기름칠된 기계처럼 매끄럽게 운영한 것에 박수를 보내고 싶다. 연사로서 필요한 정보를 제때 모두 제공받았다. 내가 본 모든 발표에서 음향과 영상 장비가 잘 작동했고, 모든 일정이 정시에 진행됐다. 음식도 맛있고 넉넉했는데, 다만 탄수화물 위주라는 점은 아쉬웠다.

장소

펜실베이니아 호텔은 컨퍼런스 장소로 훌륭하다. 세 개의 스테이지가 있었고 좌석도 충분해 보고 싶은 발표에 자리가 없어 못 들어가거나 비좁다고 느낀 적이 한 번도 없었다. 발표장들이 모두 가까이 붙어 있어 발표 사이 이동이 편했고, 다른 참가자들과 복도에서 대화할 수 있는 공간도 충분했다.

내 발표에 대한 소감

“내 발표 되돌아보기”(아래)를 참고.

인상 깊었던 발표

인터넷이 모두 썩어 사라지기 전에 아카이빙하기

연사: Nick Sweeting (Monadical)

웹페이지 아카이빙 커뮤니티가 이렇게 크고 관련 툴링이 이토록 성숙해 있는지 전혀 몰랐다. Nick은 우리가 중앙화된 데이터 저장소를 얼마나 쉽게 잃어버리는지 지적했다. 이는 알렉산드리아 도서관 같은 고대의 사례에도 해당하고, 지오시티즈나 텀블러 같은 디지털 정보에도 마찬가지다. 이런 저장소는 일반 사람들이 자신의 사본을 아카이빙하고 보존할 수 있는 도구를 갖출 때 살아남는다.

Nick은 웹페이지를 아카이빙할 수 있는 다양한 도구를 소개하고 인터넷 아카이빙에 헌신하는 여러 단체와 온라인 커뮤니티를 둘러보여 주었다. 툴링은 내가 예상했던 것보다 훨씬 성숙했는데, JavaScript와 RPC를 많이 사용해 HTML을 동적으로 생성하는 싱글 페이지 앱(SPA)까지 아카이빙할 수 있는 도구도 여러 개 있었다. 심지어 일반적인 유틸리티에도 강력한 아카이빙 기능이 들어 있다.

Nick은 JavaScript, CSS, 이미지를 포함한 단일 웹페이지를 완전히 다운로드하는 다음 wget 명령어를 보여주었다:

wget \
  --no-verbose \
  --adjust-extension \
  --convert-links \
  --force-directories \
  --backup-converted \
  --span-hosts \
  --no-parent \
  -e robots=off \
  --restrict-file-names=windows \
  --timeout=60 \
  --warc-file=archive.warc \
  --page-requisites \
  --user-agent="Lalala this is chrome I promise..." \
  --load-cookies="mycookies.txt" \
  --compression=auto \
  --no-check-certificate \
  --no-hsts \
  "https://2019.pygotham.org"

그 밖에 좋았던 점:

• Nick이 소개한 kiwix는 내가 처음 알게 된 프로젝트다. 위키피디아나 StackOverflow 같은 대형 콘텐츠 사이트의 오프라인 사본을 제공해 로컬에서 실행할 수 있게 해준다.
• Nick은 아카이빙 리소스와 커뮤니티 모음을 관리하고 있다.

본업이 아닌데 파이썬 프로젝트 유지보수하기

연사: Hynek Schlawack

• 발표 개요
• 슬라이드

Hynek은 여러 인기 오픈소스 프로젝트(attrs, structlog)를 유지보수하고 있으며, 외부 풀 리퀘스트를 검토할 수 있는 시간이 제한적이다. 그는 자동화된 도구를 활용해 검토 시간을 최소화하고 외부 기여자가 스스로 버그를 찾을 수 있도록 한다. 이는 코드 리뷰에 대한 나의 1원칙인 지루한 부분은 컴퓨터에게 맡기자와도 잘 맞아떨어진다.

Hynek은 재미있고 활기 넘치는 연사다. 그는 “안녕하세요, 여러분이 있는 줄도 몰랐던 유럽 친구 Hynek입니다”라고 농담을 던지며 시작하는데, 앞으로의 내용이 재미있고 때로는 익살스러울 것임을 예고하는 분위기를 만든다.

그 밖에 좋았던 점:

• 내가 몰랐던 몇 가지 도구를 알게 됐다:
  • isort: 파이썬 import 구문을 정렬해 준다.
    • 내 Python3 보일러플레이트 프로젝트에 추가했다.
    • 이 도구의 단점은 “자동으로 수정”과 “도움이 안 되는 실패 메시지를 보여주기” 두 가지 모드만 제공한다는 점이다(빌드 체크에서 원하는 동작이 아니다).
  • Black: 파이썬 코드의 공백을 포맷팅한다.
    • 흥미롭지만 내가 선호하는 포매터인 yapf에 비해 유의미한 개선을 제공하지는 않는 것 같다.
  • tox: 다양한 가상 환경에서 파이썬 테스트 스크립트를 실행한다.
    • 5년쯤 전에 tox를 써본 것 같은데, 당시에는 유닛 테스트에서 동작을 모킹하는 용도로 썼던 것 같다. 지금 이 프로젝트는 완전히 다른 것이 되어 있어서, mock이 표준 라이브러리에 들어오면서 초점이 바뀐 건지 내가 그냥 혼동하고 있는 건지 모르겠다.
    • 어쨌든 괜찮아 보인다. 여러 파이썬 환경에서 실행되는 프로젝트를 만든 적은 없지만, 필요할 때 꺼내 쓸 수 있도록 기억해 두면 좋을 것 같다.
• Hynek의 예시 풀 리퀘스트 체크리스트와 기여자 문서가 마음에 들었다.
• 누군가 발표 내용을 공개 텍스트 개요로 만든 것을 본 적이 없는데, Hynek의 개요는 도움이 됐다.

Make You An Async For Great Good!

연사: Mark Smith (Nexmo)

Mark는 동시성 코드를 작성하기 위한 파이썬 라이브러리인 asyncio 모듈을 소개했다. 그는 mysyncio라는 간소화된 버전을 직접 만들면서 라이브러리의 동작 원리를 파악했다고 설명했다.

Mark가 그토록 적은 코드로 asyncio 기능 중 얼마나 많은 부분을 재구현했는지에 감탄했다. 그의 구현은 스레드 안전성과 예외 처리 등 실제 asyncio 모듈의 핵심 기능 몇 가지를 생략했지만, asyncio의 핵심 기능은 구현해 냈다. 동시성 프로그래밍은 종종 이해하기 어려운데, Mark의 마법이 걷힌 버전을 보니 asyncio가 더 직관적으로 다가왔다.

내 발표 되돌아보기

연사: Michael Lynch (본인)

• 슬라이드

내 발표는 만족스러웠다. 준비 수준(5~7회 리허설)에도 만족했지만, 컨퍼런스 당일이 있는 주까지 미루지 말고 더 일찍 리허설을 시작했더라면 좋았을 것 같다.

PyTexas 발표 후 개선점으로 적어 둔 것은 말을 더 천천히 하고 노트북을 너무 자주 내려다보지 않는 것이었다. PyGotham에서는 천천히 말하는 데 너무 집중한 나머지 말투가 내 발표 내용에 질린 사람처럼 평평하게 들린 것 같다. 5~10분 정도 지나니 나아지긴 했지만, 앞으로 발표할 때는 말에 감정을 담는 것을 기억하고 싶다.

가장 큰 실수는 화면을 미러링하는 대신 Google Slides의 “발표자 뷰”로 발표를 띄운 것이었다. 화면의 타이머가 페이스 유지에 도움이 될 줄 알았는데, 내 슬라이드를 볼 수 없게 될 거라는 걸 깜빡했다. 슬라이드를 충분히 잘 알고 있어서 발표자 뷰의 작은 썸네일만 보고도 대부분 발표할 수 있었지만, 화면을 돌아서 텍스트를 읽어야 했던 순간이 여러 번 있었다.

• 잘된 점

  • 발표할 내용에 대해 편안함을 느꼈다.
  • 말하는 속도를 늦추고 청중에 집중하는 데 성공했다.

• 개선할 점

  • “발표자 뷰”로 발표하지 말고 노트북 화면을 미러링할 것.
  • 천천히 말한다고 해서 평평한 어조로 말하라는 뜻은 아니다. 이런 컨퍼런스에 오게 되어 신이 나는데, 발표에서 그 열정을 더 잘 보여줄 수 있다.
  • 내용 자체가 다소 딱딱하게 느껴진다. 좀 더 가볍게 만들고 농담을 더 넣을 필요가 있다.
  • 준비가 촉박하게 느껴지지 않도록 더 일찍 리허설을 시작할 것.

비용

PyTexas에 참석하는 데 쓴 약 1,200달러와 비교해 보라! 모든 컨퍼런스 주최 측이 그냥 내 집에서 차나 기차로 갈 수 있는 거리에서 컨퍼런스를 계획하고, 근처에 빈 방이 있는 친구가 살고 있다는 걸 보장해 준다면 정말 편할 것 같다.

시간 측면에서는 5~10시간 정도 준비했다. 이미 PyTexas 때 만든 슬라이드가 있어 준비가 훨씬 수월했고, 이전 컨퍼런스에서의 성찰을 바탕으로 발표 내용을 일부 수정하긴 했다.

기타 생각

“무엇을 개선할 수 있을까?”

이전 컨퍼런스에서는 사람들이 내 발표가 좋았다고 말하러 다가오면 그냥 고맙다고만 답했다. 올해는 “고마워요! 개선할 수 있을 것 같은 부분이 있을까요?”라고 물어봤다. 사람들은 이 질문에 약간 당황했지만, 보통 잠시 생각하더니 제안을 해 주었다.

컨퍼런스에는 피드백이 안타깝게도 부족하다. 누구나 발표 스킬과 슬라이드의 명확성을 개선할 수 있지만, 연사는 무엇이 잘 되고 무엇이 안 되는지에 대한 데이터가 별로 없다. 발표를 보다 보면 쉽게 고칠 수 있는 실수를 하고 있는데 연사에게 알려주고 싶은 순간이 계속 생긴다. 하지만 그런 조언을 먼저 건네는 것은 무례한 행동이고, 특히 연사가 애초에 발표에 대해 긴장하고 있을 가능성이 높을 때는 더욱 그렇다.

앞으로 내 발표가 끝난 뒤 사람들이 다가오면 고맙다고 하면서도 무엇을 더 잘할 수 있을지 물어보는 것을 잊지 않으려 한다. 내 발표를 봤다면 알려 달라, 무엇을 개선할 수 있을지.

컨퍼런스는 아이디어를 얻기 좋은 곳이다

컨퍼런스는 창의적인 사고를 자극한다. 현장에 앉아 있을 때까지는 매번 잊고 있지만, 참석하는 모든 컨퍼런스에서 그런 일이 일어난다. 컨퍼런스에서는 다른 곳에서는 절대 떠올리지 못했을 아이디어가 떠오른다.

가끔 발표를 들으며 마음이 딴 데로 새서 그런 건지, 아니면 연사가 자신의 사고 과정을 단계별로 설명해 주면 평소와는 다른 생각이 촉발되기 때문인지는 잘 모르겠다. 하지만 참석하는 모든 컨퍼런스에서 사업이나 앞으로 해보고 싶은 프로젝트에 대한 좋은 아이디어를 얻어 돌아온다.

암호화폐 훔치기에 대한 발표를 해야겠다

다른 곳에서는 떠올리지 못했을 아이디어의 한 예로, PyGotham에서 “How I Stole Your Siacoin”을 컨퍼런스 발표 주제로 만들어야겠다는 생각이 들었다. 재미있는 이야기이고, 파이썬을 활용하며, 레벤슈타인 거리나 공개키 암호 같은 몇 가지 주제를 재미있게 풀어낼 수 있다. 컨퍼런스 발표 주제로 만들 생각은 전혀 해본 적이 없었는데, 한 번 생각하고 나니 너무나 당연한 아이디어처럼 느껴졌다.

어쩌면 아무것도 요청하지 말아야 할지도 모른다

올해 초 PyTexas가 끝난 뒤, 나는 새로운 프로젝트를 찾고 있었고 청중으로 가득한 방에 기술자들이 앉아 있으니, 사업의 고충에 대해 이야기하러 와 달라고 사람들에게 요청했어야 했다는 걸 깨달았다. 분명 누구나 업무 중에 그냥 매니지드 서비스에 위임하고 싶은 부분이 있을 것이다. (바라건대) 내가 유능한 개발자임을 보여줬으니, 그들이 무언가를 만들어 달라고 요청할 수도 있었을 것이다.

PyGotham에서는 발표 마지막에 업무 중에 없다고 느끼는 매니지드 서비스에 대해 이야기하러 와 달라고 초대하며 마무리했다. 그리고는, 아무 일도 일어나지 않았다.

최악의 경우에도 “무료에 무제한인 MailChimp 같은 걸 원해요” 같은 형편없는 아이디어라도 얻을 줄 알았다. 하지만 아무것도, 전혀 없었다. 그래서 이 전략에는 별 가치가 없을지도 모른다. 앞으로는 이 자리를 활용해 What Got Done에 새로운 사용자를 끌어모으는 데 써 볼 생각이다.

CFP를 검토하는 일은 깨달음을 준다

연사가 컨퍼런스에 지원할 때는 “CFP”, 즉 발표 제안서를 작성한다. 왜 자신이 컨퍼런스에서 발표해야 하는지, 그리고 행사 일정표에 참석자를 끌어모을 소개 문구는 무엇인지 몇 단락으로 설명하는 것이다.

PyGotham은 내가 경험한 컨퍼런스 중 참석자가 모든 CFP를 보고 투표할 수 있었던 첫 번째 컨퍼런스다. 나도 몇 번 CFP를 써 봤지만 다른 사람의 CFP를 읽어본 적은 한 번도 없어서, (어느 정도는 불명확한) 투표권을 가지고 어떤 발표가 선정될지에 영향력을 행사하는 입장에서 경험하는 것은 깨달음을 주는 일이었다.

몇 가지 느낀 점:

• CFP를 검토하는 일은 정말 지치는 일이다.
  • 제출된 제안서가 약 300개 정도 있었던 것 같다. 3~4번에 나눠서 봤지만, 에너지 수준에 따라 어떤 제안서에는 더 인내심을 갖고 관대하게 평가했을 것이 분명하다.
• 내 관심사와 대중의 관심사 사이에서 균형을 잡기가 어렵다.
  • 예를 들어 나는 머신러닝 발표에 큰 관심이 없지만, 다른 사람들은 관심이 있다는 걸 안다. 그런 발표에 찬성표를 던져야 할까, 반대표를 던져야 할까?
• CFP에서 건방진 태도는 좋은 결과를 가져오지 못한다.
  • 일부 제출자는 CFP를 작성하는 것이 자신보다 격이 낮다는 듯이 행동했다. “당신의 발표는 무엇에 관한 것인가요?”라는 질문이 있고, 이어서 “참석자는 당신의 발표에서 무엇을 얻어 가야 하나요?”라는 질문이 이어졌는데, 후자에 “위 참조” 또는 “첫 번째 질문과 의미 있게 다르지 않다” 같은 성의 없는 답변을 남긴 사람들을 여러 명 봤다.
  • 100개의 CFP를 검토하고 그중 90%를 탈락시켜야 할 때, 건방진 제안서가 가장 먼저 탈락시키기 쉽다.

일 년에 세 번의 컨퍼런스가 좋은 목표다

연초에 나는 2019년에 세 번의 컨퍼런스에서 발표하겠다는 목표를 세웠다. PyGotham으로 그 목표를 달성했다:

1. NERD Summit 2019
2. PyTexas 2019 (후기)
3. PyGotham 2019

돌이켜보면 세 번이라는 목표는 여전히 적절하다고 느껴진다. 각 컨퍼런스는 나를 일주일이나 이주 정도 지치게 만들지만, 좋은 아이디어를 자극하고 다른 방법으로는 발견하지 못했을 도구와 기술을 접하게 해준다.