개요

지난 주말, PyTexas의 초청으로 텍사스주 오스틴에서 열린 연례 컨퍼런스에서 발표를 했다.

즐거운 여정이었고 많은 것을 배웠다. 하지만 비용도 만만치 않았다. 금전적으로도, 시간적으로도 그랬다. 이렇게 기록을 남기는 건 배운 내용을 공유하기 위해서이기도 하고, 컨퍼런스 참석으로 얻는 이점이 그 비용을 상쇄할 만한지 스스로 가늠해 보기 위해서이기도 하다.

인상 깊었던 발표

의도적인 배포: 피처 플래그 관리를 위한 모범 사례

발표자: Optimizely 소속 Caitlin Rubin

피처 플래그를 사용하면 소프트웨어 팀이 완전히 새로 배포하지 않고도 런타임에 애플리케이션의 동작을 바꿀 수 있다. 규모가 큰 변경의 경우 점진적 롤아웃을 하고 싶을 때가 많다. 1%의 사용자에게 먼저 적용하고, 이어서 5%, 25%로 확대하는 식이다. 그래야 프로덕션에서 문제가 터졌을 때 피해를 최소화할 수 있기 때문이다. 팀들은 이런 점진적 롤아웃을 피처 플래그로 구현하는 경우가 많다.

피처 플래그는 공유지의 비극 문제를 겪는다. 개별 개발자가 새 기능을 위해 플래그를 하나 추가하는 건 쉽다. 하지만 모두가 계속해서 새로운 피처 플래그를 추가하면 애플리케이션에는 실행 경로가 너무 많이 쌓여 프로그램 동작을 추론하기 어려워진다. 게다가 팀이 특정 기능을 전체에 활성화한 뒤에는, 개발자가 분기 로직을 제거하고 플래그를 정리하는 번거로운 작업을 할 유인이 거의 없다.

이 발표는 피처 플래그가 무엇인지, 왜 문제를 일으킬 수 있는지 간결하게 설명하고, 그 문제를 예방하는 구체적인 방법을 공유했다. 특히 Caitlin이 제안한 ‘WIP 제한(WIP limit, 진행 중 작업 제한)’이 마음에 들었다. 팀에서 WIP 제한을 2로 정하면, 한 번에 존재할 수 있는 피처 플래그는 두 개뿐이다. 이렇게 하면 개발자들이 피처 플래그를 언제 쓸지 신중하게 고민하게 되고, 더 이상 분기 로직이 필요 없을 때 플래그를 제거하도록 유도할 수 있다.

그 외에 좋았던 점:

• 슬라이드가 깔끔했고 텍스트로 청중을 압도하지 않았다
• 몇 초마다 슬라이드가 넘어가거나 업데이트되어 흐름이 끊기지 않았다
• Caitlin은 무대에서 여유가 느껴졌고 또렷하고 차분하게 말했다
• 발표 전반에 유머가 적절히 녹아 있었다

mypy로 ORM에서 벗어나기!

발표자: uStudio 소속 Thomas Stephens

나는 항상 객체-관계 매핑(ORM) 프레임워크를 꺼려 왔다. ORM은 개발자가 직렬화와 역직렬화 로직을 일일이 손으로 구현하지 않아도 애플리케이션 객체를 데이터 저장소에 넣고 빼올 수 있게 해준다. Thomas는 내가 ORM 시스템에 대해 막연하게 느껴 왔지만 말로 표현하지 못했던 문제를 정확히 짚어 줬다. 바로 ORM이 객체 모델을 ORM 프레임워크에 종속시킨다는 점이다.

나는 mypy를 본 적이 있고 매력도 이해했지만, 약 1년 전에 내 프로젝트(대부분 Python 2.7)에 적용해 보려다 잘 되지 않아 그냥 포기했다. mypy를 모른다면, Python용 정적 타입 체커라고 보면 된다. 코드 속 PEP 484 타입 힌트를 읽고 이를 위반할 때 알려준다.

이 발표는 mypy에 대한 부드러운 입문이자 이를 사용했을 때 얻을 수 있는 폭넓은 이점을 잘 보여 줬다. 바로 너무 많은 수고 없이 직접 데이터 직렬화와 역직렬화를 구현할 수 있다는 점이다. Thomas는 타입 체커에 크게 의존해 흔한 직렬화 오류를 예방하는 방법을 시연했다.

그 외에 좋았던 점:

• 해결하려는 문제를 명확하게 설명했다
• 따라가기 쉬운 간단한 라이브 코딩이었다
• 코드가 우아하고 명료했다

불리언만으로는 부족할 때… 상태 머신?

발표자: Netflix 소속 Harrington Joseph

슬라이드

애플리케이션은 종종 객체의 상태를 추적하기 위해 불리언을 사용한다. Harrington은 Netflix 소속인 만큼 비디오 플레이어를 예로 들었는데, 이는 문제를 잘 보여 줬다. 비디오는 재생 중이거나, 일시 정지되었거나, 정지된 상태일 수 있다. 순진한 접근이라면 is_playing이나 is_paused 같은 불리언으로 이를 추적하려 할 것이다.

이렇게 상태를 관리하면 개발자에게 큰 부담이 된다. 상태를 추론하기 위해 많은 작업을 해야 하기 때문이다. ‘정지’ 상태를 추론하려면 is_playing == False and is_paused == False를 확인해야 하는데, 이는 꽤나 복잡하다. 또 올바르지 않은 상태 전이를 검사해야 하는 부담도 개발자에게 넘어온다. 예를 들어 이미 정지된 비디오를 일시 정지할 수는 없으므로, 이런 제약을 강제하는 코드가 전체를 어지럽힌다.

Harrington은 pytransitions 라이브러리가 이 문제를 얼마나 우아하게 해결하는지 보여 줬다. 애플리케이션의 상태 전이를 간단한 상태 목록으로 정의하기만 하면, 라이브러리가 모든 전이를 대신 관리해 준다. 현재 어떤 상태에 있는지 확인할 수 있고, 올바르지 않은 상태 전이가 발생하면 라이브러리가 예외를 발생시킨다. 직접 검사하는 코드를 작성할 필요가 없다.

그 외에 좋았던 점:

• 아름다운 슬라이드
  • 다크 테마가 잘 어울렸다
  • 구문 강조가 적용된 전체 화면 코드 스니펫 덕분에 읽기 쉬웠다
  • 상태 머신을 설명하는 다이어그램이 훌륭하고 이해하기 쉬웠다
• 명확한 코드 예시
  • 핵심과 관련 없는 코드는 생략해 내용을 이해하기 쉬웠다

그 밖에 기억할 만한 것들

글을 위한 코드 리뷰 도구가 있다

이건 Python과는 아무 관련이 없었지만, 다른 참가자와 우연히 대화를 나누다 얻은 값진 수확이었다.

언젠가 해보고 싶은 프로젝트 중 하나는 Reviewable 같은 것을 만들되, 코드가 아니라 글 콘텐츠를 대상으로 하는 도구를 만드는 것이었다. 비슷한 도구를 찾아봤지만, 대형 출판사를 위한 무거운 도구들(예: 신문사용 도구로, 다수의 승인자가 얽힌 복잡한 워크플로에 최적화된 것)만 눈에 띄었다. Caitlin Rubin과 이야기할 때, 그녀가 Penflip이라는 그런 도구를 알고 있다고 말해 줬다.

첫날 Penflip에 접속을 시도했을 때는 여러 번 재시도해도 502 게이트웨이 오류만 떴다. 다음 날에는 페이지가 로드되긴 했지만 모든 것이 극도로 느렸고 결국 복구할 수 없는 서버 오류로 이어졌다. 더 이상 활발히 운영되는 제품이 아닌 듯했다.

그래도 제품 이름 하나를 알게 된 덕분에 다른 제품을 찾는 실마리가 생겼다. 알고 보니 ‘코드를 위한 코드 리뷰를 콘텐츠에 적용한’ 제품 중 실패한 사례가 한둘이 아니었다:

• Draft: 아직 동작하는 몇 안 되는 편집 앱 중 하나지만 리뷰 기능을 제대로 지원하지 않는 듯하다.
• Editorially: 평판이 좋았던 무료 도구였지만 2014년에 서비스를 종료했다. 서비스 종료를 아쉬워하는 글을 많이 찾을 수 있었다.
• Typewrite: 사이트는 아직 살아 있지만 가입조차 할 수 없을 정도로 기능이 망가져 있다. 마지막 트위터 게시물이 2014년이니 사실상 서비스가 중단된 것으로 보인다.
• Poetica: 언급된 것을 본 적은 있지만 지금은 사라졌다. 그리 인기가 많았던 것 같지는 않다.

파이썬의 선

여러 발표자가 파이썬의 선(The Zen of Python)을 언급했다. Python의 유명한 설계 원칙 모음이다. 나는 이 목록을 이전에 본 적이 없었지만, 알아 두면 좋은 내용이었다. Python 인터프리터에서 import this를 입력하면 이 내용을 볼 수 있다.

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

PyCon은 큰 행사다

여러 사람이 PyCon을 극찬했다. PyTexas는 소규모 지역 컨퍼런스지만, PyCon은 전국 규모의, 말하자면 메이저 리그다. 발표 품질이 높고 만나면 도움이 되는 사람들이 더 많다고 한다. 나는 그동안 PaperCall로 예정된 컨퍼런스를 확인해 왔는데, PyCon은 PaperCall을 사용하지 않는 듯해 제출 마감일을 놓쳤다. 내년에는 캘린더에 꼭 추가해 둬야겠다.

효과적인 발표의 공통점

• 발표자의 여유
  • 가장 좋았던 발표들은 발표자가 편안함을 느끼고 여유 있게 진행한 것들이었다.
  • 가장 좋은 예는 Adrienne Lowe의 기조연설, “The Zen of Python Teams.”였다.
• 개인적인 이야기
  • 발표자가 이야기의 일부일 때 더 몰입됐다. 어떤 문제를 해결하려 했는지, 어떤 어려움에 부딪혔는지, 무엇을 배웠는지. 이런 질문에 답하는 것이 “문제 Y를 해결하는 도구 X가 있다는 걸 아시나요?” 같은 건조한 요약보다 훨씬 더 흥미로웠다.

발표를 아쉽게 만든 요인

• 마이크 문제
  • 발표에 몰입을 깨는 가장 흔한 요인이 음질처럼 기본적이고 지루한 문제였다는 점이 안타깝다.
  • 컨퍼런스에서는 Tony Robbins식 귀에 거는 마이크를 사용했는데, 많은 발표자가 위치를 제대로 잡지 못해 소리가 자주 들렸다 안 들렸다 했다.
  • 다른 발표자들은 핸드 마이크를 선택했지만 입 가까이 대고 마이크가 잘 잡을 만큼 크게 말하는 데 어려움을 겪었다.
• 슬라이드 정체
  • 훌륭한 발표자들은 슬라이드를 빠르게 움직였다. 최소 30초마다 슬라이드를 넘기거나 새로운 불릿을 띄웠다. 60초 이상 같은 슬라이드를 그대로 둔 채 아무 변화도 주지 않을 때의 그 ‘정체된’ 느낌이 기억난다.
• 대본 읽기
  • 라이브 컨퍼런스에 참석하는 재미 중 하나는 청중으로서 발표의 일부가 된다는 데 있다. 발표자가 청중의 에너지에 반응하며 발표를 조정한다. 발표자가 긴 구간을 대본을 그대로 읽거나(더 나쁜 경우 발표 전체가 고정된 대본일 때), 라이브 발표의 재미가 사라진다.
• 움직이는 GIF
  • 몇 초 이상 화면에서 계속 반복 재생될 때 특히 산만하다고 느꼈다.
  • 가벼운 농담이 발표자의 요점을 오히려 흐리는 경우가 많다고 느꼈다.
• “이건 예전 슬라이드입니다.”
  • 몇몇 발표에는 이전 컨퍼런스에서 재활용하느라 1~2년 정도 지난 정보가 포함돼 있었다. 발표자는 슬라이드가 오래됐다고 양해를 구했지만, 사전에 리허설을 한 번만 했어도 잡을 수 있는 문제를 신경 쓰지 않았다는 느낌이 들어 항상 아쉬웠다.

내 발표 돌아보기

발표자: Michael Lynch (본인)

슬라이드

• 잘한 점

  • 준비성: 발표 전 몇 주 동안 5~8번 정도 리허설을 해서 내용에 대해 자신감이 있었다.
  • 슬라이드 진행 속도: 영상을 다시 보니 슬라이드 정체를 피하고 적절한 속도로 발표를 끌고 간 느낌이다.
  • Java를 살짝 디스한 부분(16:15 참고)이 웃음을 잘 끌어냈다.

• 개선할 점

  • 속도 조절: 말을 너무 빨리 했다. 타이머를 켜 두는 걸 잊어 시간 안에 끝내야 한다는 조급함에 쫓겼다. 리허설 때는 약 27분이 걸렸는데, 실제 발표에서는 너무 빨리 말한 탓에 30분 슬롯 중 22분밖에 쓰지 않았다.
  • 시선 처리: 화면을 내려다보며 내용을 읽는 데 시간을 너무 많이 썼고, 청중과 눈을 맞추는 데 소홀했다.
  • “테스트 코드에서는 매직 넘버를 써도 괜찮다”(19:58에서)
    • 이 문장은 더 충분한 근거가 필요했다. 다행히 Q&A에서 누군가 이 부분을 질문해 설명할 수 있었지만, 원래 발표 내용에 포함됐어야 했다.

그 외의 생각

연사로 참석하는 것이 일반 참가자로 참석하는 것보다 훨씬 가치 있다

앞으로 컨퍼런스에 더 참석할지 고민하면서, 연사가 아니라 일반 참가자로 가 볼지 고민한 적이 있다. 연사로 참석할 때의 가치는 한 차원 높다고 느낀다.

사람들은 연사에게 더 큰 관심을 보인다. 발표 전에도 “뭔가 잘하는 게 있겠지”라는 인식이 있기 때문에 그렇다. 발표 후에는 당신과 만나고 싶어 하는 사람들이 적어도 당신이 열정을 가진 주제 하나를 알고 있으니 대화를 시작하기도 쉽다.

나 역시 다른 참가자보다 발표자들이 더 오래 기억에 남았다. 흥미로운 사람들과 많은 대화를 나눴지만, 며칠이 지나도 기억에 남는 사람들은 발표를 한 사람들이었다.

무언가를 요청했어야 했다

모든 발표자는 발표에서 사실상 무료로 ‘행동 촉구(call to action)’ 기회를 얻는다. 대부분의 발표자에게 이는 자사에 지원하거나 자사 제품을 써 달라는 초대다. 나는 채용 중도 아니고 프로젝트 사이 공백기였기 때문에 행동 촉구를 해야겠다는 생각이 들지 않았다.

발표가 끝나고 한 시간쯤 지나서야 “아, 기업들에게 고충을 보내 달라고 요청했어야 했는데!”라는 생각이 들었다. 많은 PyTexas 참가자들이 일상 업무 중에 “이런 일 하기 싫다. 왜 이걸 대신해 주는 매니지드 서비스가 없을까?”라고 생각하는 부분이 있을 것 같다. 제품을 만드는 사람들이 충족되지 않은 수요를 가진 소규모 기업과 연결되기 어렵기 때문에 이런 문제들은 해결되지 않은 채 남는 경우가 많다. PyTexas는 “저에게 와서 이야기해 보세요. 어쩌면 그 서비스를 만들어 드릴 수도 있습니다”라고 말하기에 좋은 자리였을지 모른다.

싱글 트랙 컨퍼런스는 분위기가 다르다

이번이 내가 참석한 첫 싱글 트랙 컨퍼런스였다. 싱글 트랙이란 한 번에 하나의 발표만 진행되어 참가자들이 어떤 발표를 들을지 고민할 필요가 없고 선택지도 하나뿐이라는 뜻이다.

싱글 트랙의 장점은 모두가 같은 발표를 본다는 점이다. 그래서 누구와도 어떤 발표에 대해서든 대화할 수 있고, 상대방도 그 발표를 봤을 가능성이 높다. 발표자 입장에서도 청중 100%가 내 발표를 본다는 점이 좋다.

단점은 싱글 트랙 행사가 멀티 트랙 컨퍼런스에서 자연스럽게 생기는 자리 이동이 없다는 점이다. 멀티 트랙에서는 대부분 사람들이 발표가 끝날 때마다 다른 방으로 이동하면서 새로운 사람들을 만나게 된다. PyTexas에서는 대부분의 사람들이 하루 종일 한 테이블에만 머물러 있어 다른 컨퍼런스에서보다 교류가 적었다.

비용

이번 컨퍼런스에 참석하는 데 예상보다 더 많은 비용이 들었다:

금전적 비용을 넘어 시간 비용도 컸다. 이틀짜리 컨퍼런스였지만, 체감으로는 5일 정도를 소진했다. 오가는 데 각각 하루씩 걸렸고, 자리를 비운 동안 밀린 개인적인 일들을 처리하는 데도 하루가 걸렸다. 그 외에도 슬라이드 덱을 준비하고 리허설하는 데 20~30시간을 썼다.

결론: 계속 참가하되, 전략적으로

연초에 2019년에는 컨퍼런스 세 곳에서 발표하겠다는 목표를 세웠다. PyTexas가 두 번째였으니, 올해 한 번 정도 더 하면 적절한 횟수가 될 것 같다.

나에게 이점은 새로운 사람들을 만나고, 그렇지 않았다면 접하지 못했을 도구와 기술을 듣고, 공개 발표 연습을 할 수 있다는 점이다. 가장 큰 수확 중 하나는 Penflip에 대해 알게 된 것이었다. 전혀 예상치 못한 수확이었지만, 그들의 실패를 반면교사 삼아 많은 시간과 비용을 아낄 수 있을 것 같다.