개요

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

평가

발표의 질

올해 발표들의 전반적인 수준은 다소 아쉬웠습니다. 마음에 들었던 발표도 몇 개 있었지만(아래 참조), 기대에 못 미친 발표가 많았습니다.

문제 중 하나는 제가 주요 대상 청중이 아니라는 점입니다. 머신러닝 발표가 많은 비중을 차지했는데, 머신러닝 자체는 흥미롭다고 생각하지만 제 업무에 활용하지는 않아서 입문용 머신러닝 발표는 이미 충분히 들었다는 느낌이었습니다.

행사 운영

PyGotham 운영진이 행사를 정말 매끄럽게 운영한 점에 박수를 보내고 싶습니다. 발표자로서 필요한 정보를 제때 모두 받을 수 있었고, 제가 본 모든 발표에서 음향과 영상 장비가 문제없이 작동했으며 모든 일정이 정시에 진행되었습니다. 음식도 맛있고 양도 넉넉했는데, 다만 탄수화물 위주였던 점은 조금 아쉬웠습니다.

장소

펜실베이니아 호텔은 컨퍼런스 장소로 훌륭했습니다. 세 개의 스테이지가 있었고 좌석도 충분해서 듣고 싶은 발표를 비좁거나 입장하지 못할 걱정 없이 볼 수 있었습니다. 모든 발표장이 가까이 붙어 있어 이동이 편했고, 참석자들과 복도에서 대화 나누기에도 충분한 공간이 있었습니다.

내 발표에 대한 소감

아래 “내 발표 되돌아보기”를 참조해 주세요.

인상 깊었던 발표

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

발표자: Monadical의 Nick Sweeting

웹페이지 아카이빙 커뮤니티가 이토록 크고 관련 도구가 이토록 성숙해 있는지 미처 몰랐습니다. Nick은 중앙화된 데이터 저장소가 얼마나 쉽게 사라지는지 짚어주었습니다. 이는 알렉산드리아 도서관 같은 고대의 사례에도 해당하고, 지오시티즈(Geocities)나 텀블러(Tumblr) 같은 디지털 정보에도 마찬가지입니다. 일반 사람들이 자신의 사본을 아카이빙하고 보존할 수 있는 도구를 가질 때 이러한 저장소가 살아남습니다.

Nick은 웹페이지를 아카이빙하는 다양한 도구를 소개하고 인터넷 아카이빙에 헌신하는 여러 단체와 온라인 커뮤니티를 둘러보여 주었습니다. 도구는 제가 예상했던 것보다 훨씬 성숙해 있었고, 자바스크립트와 RPC를 대량으로 사용해 HTML을 동적으로 생성하는 싱글 페이지 애플리케이션(SPA)조차 아카이빙할 수 있는 도구도 여러 개 있었습니다. 심지어 일반적으로 쓰는 유틸리티에도 강력한 아카이빙 기능이 들어 있었습니다.

Nick은 다음 wget 명령어를 보여주었습니다. 이 명령어는 자바스크립트, CSS, 이미지를 모두 포함해 단일 웹페이지를 완전히 다운로드합니다:

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)를 유지보수하고 있으며, 외부 풀 리퀘스트를 검토할 시간이 제한적입니다. 그는 자동화 도구를 활용해 검토 시간을 최소화하고 외부 기여자가 스스로 버그를 찾을 수 있도록 합니다. 이는 제가 생각하는 코드 리뷰의 첫 번째 원칙인 지루한 부분은 컴퓨터에 맡기자와 정확히 일치했습니다.

Hynek은 재미있고 활기 넘치는 발표자입니다. 그는 “안녕하세요, 여러분이 있었는지도 몰랐던 유럽 친구 Hynek입니다”라는 농담으로 시작합니다. 발표 내내 내용이 재미있고 때로는 짓궂은 유머가 곁들여질 것이라는 분위기를 바로 만들어줍니다.

그 외에 좋았던 점:

• 제가 몰랐던 몇 가지 도구를 알게 되었습니다:
  • isort: 파이썬 import 문을 정렬해 줍니다.
    • 제 파이썬 3 보일러플레이트 프로젝트에 추가했습니다.
    • 이 도구의 아쉬운 점은 “자동으로 수정”과 “도움이 안 되는 실패 메시지 표시” 두 가지 모드만 제공한다는 것입니다. 빌드 체크에서 원하는 동작이 아닙니다.
  • Black: 파이썬 코드의 공백을 포맷팅해 줍니다.
    • 흥미롭지만, 제가 선호하는 포매터인 yapf에 비해 유의미한 개선을 제공하는 것 같지는 않습니다.
  • tox: 서로 다른 가상 환경에서 파이썬 테스트 스크립트를 실행합니다.
    • 5년 전쯤 tox를 써본 것 같기도 한데, 당시에는 단위 테스트에서 동작을 모킹하는 용도로 썼던 것 같습니다. 지금의 프로젝트는 완전히 다른 것이어서, mock이 표준 라이브러리에 들어온 뒤 프로젝트 방향이 바뀐 건지 아니면 제가 잘못 기억하는 건지 헷갈립니다.
    • 어쨌든 괜찮아 보입니다. 여러 파이썬 환경에서 동작하는 프로젝트를 만든 적은 없지만, 기억해 두면 유용할 것 같습니다.
• Hynek의 예시 풀 리퀘스트 체크리스트와 기여 가이드가 마음에 들었습니다.
• 발표의 텍스트 개요를 공개한 사람을 처음 봤는데, Hynek의 개요가 도움이 되었습니다.

Make You An Async For Great Good!

발표자: Nexmo의 Mark Smith

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

Mark가 그토록 적은 코드로 asyncio의 기능을 얼마나 많이 재구현했는지에 놀랐습니다. 그의 구현은 스레드 안전성과 예외 처리를 비롯해 실제 asyncio 모듈의 중요한 기능들을 생략했지만, 핵심 기능은 구현해 냈습니다. 동시성 프로그래밍은 종종 이해하기 어렵기 때문에, 마법이 걷힌 버전의 라이브러리를 보니 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”, 즉 제안서 모집(call for proposals)을 작성합니다. 왜 자신이 이 컨퍼런스에서 발표해야 하는지, 그리고 행사 일정표에 실릴 소개 문구가 어떻게 참석자를 끌어모을지를 설명하는 몇 문단짜리 글입니다.

PyGotham은 제가 경험한 컨퍼런스 중 참석자가 모든 CFP를 보고 투표할 수 있었던 첫 번째 컨퍼런스였습니다. 저는 CFP를 몇 번 써본 적은 있지만 다른 사람의 CFP를 읽어본 적은 없었기 때문에, 어떤 발표가 선정될지에 대해 (어느 정도인지는 불분명하지만) 투표권을 가진 사람으로서 경험한 것은 깨달음을 주었습니다.

몇 가지 느낀 점:

• CFP 검토는 정말 지칩니다.
  • 제출된 제안서가 300건 정도 있었던 것 같습니다. 3~4번에 나눠서 봤지만, 에너지 수준에 따라 어떤 제안서에는 더 관대하고 인내심을 가지고 봤을 것이 분명합니다.
• 제 관심사와 대중의 관심사 사이에서 균형을 잡기가 어렵습니다.
  • 예를 들어 저는 머신러닝 발표에 큰 관심이 없지만, 다른 사람들은 관심이 많다는 걸 압니다. 그럼 그런 발표에 찬성표를 던져야 할까요, 반대표를 던져야 할까요?
• CFP에서 건방진 태도는 마이너스가 됩니다.
  • 일부 지원자는 CFP를 작성하는 것 자체를 귀찮아하는 듯한 태도를 보였습니다. “발표 주제는 무엇인가요?”라는 질문이 있고, 이어서 “참석자는 이 발표에서 무엇을 얻어갈 수 있나요?”라는 질문이 있었는데, 후자에 대해 “위 참조”나 “첫 번째 질문과 유의미하게 다르지 않다” 같은 성의 없는 답변을 단 경우를 여러 번 봤습니다.
  • 100개의 CFP를 검토하면서 읽은 것 중 90%를 탈락시켜야 할 때, 가장 탈락시키기 쉬운 것이 바로 그런 건방진 제안서입니다.

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

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

1. NERD Summit 2019
2. PyTexas 2019 (제 노트)
3. PyGotham 2019

돌이켜보면 세 번이라는 목표는 여전히 적절하다고 느낍니다. 컨퍼런스 하나가 끝나면 일주일에서 두 주 정도는 녹초가 되지만, 좋은 아이디어를 얻게 해주고 그렇지 않았다면 발견하지 못했을 도구와 기술을 접하게 해줍니다.