개요

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

즐겁고 배울 점이 많은 출장이었지만 비용과 시간 면에서 부담도 컸습니다. 이 글은 배운 내용을 공유하고, 콘퍼런스 참석으로 얻는 이점이 그 비용을 상쇄하는지 스스로 판단해 보기 위해 정리한 기록입니다.

인상 깊었던 발표

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

발표자: Optimizely의 Caitlin Rubin

피처 플래그를 사용하면 전체를 새로 배포하지 않고도 런타임에 애플리케이션의 동작을 바꿀 수 있습니다. 규모가 큰 변경이라면 프로덕션에서 문제가 생겼을 때 피해를 최소화하기 위해 점진적 롤아웃을 하는 것이 좋습니다. 예를 들어 1%의 사용자에게 먼저 적용한 뒤 5%, 다시 25%로 점차 확대하는 방식입니다. 많은 팀이 이러한 점진적 롤아웃을 피처 플래그로 구현합니다.

피처 플래그는 공유지의 비극 문제를 겪습니다. 개별 개발자가 새 기능을 위해 플래그를 추가하는 것은 쉽지만, 모두가 계속 플래그를 추가하면 애플리케이션의 실행 경로가 너무 많아져 프로그램의 동작을 이해하기 어려워집니다. 게다가 기능이 전체 사용자에게 활성화된 뒤에는 개발자가 분기 로직을 정리하고 플래그를 제거하는 번거로운 작업을 할 동기가 거의 없습니다.

이 발표는 피처 플래그가 무엇인지, 왜 문제를 일으키는지 간결하게 설명하고 이를 예방하기 위한 구체적인 방법을 공유했습니다. 특히 Caitlin이 제안한 “WIP limit” — 진행 중인 작업 수 제한 — 이 인상 깊었습니다. 팀에서 WIP limit을 2로 정하면 동시에 존재할 수 있는 피처 플래그는 두 개뿐입니다. 이렇게 하면 개발자들이 피처 플래그를 언제 사용할지 신중하게 고민하게 되고, 분기 로직이 더 이상 필요 없을 때 플래그를 반드시 제거하게 됩니다.

그 밖에 좋았던 점:

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

mypy로 ORM에서 벗어나기!

발표자: uStudio의 Thomas Stephens

저는 예전부터 객체-관계 매핑(ORM) 프레임워크를 그다지 좋아하지 않았습니다. ORM은 개발자가 직렬화와 역직렬화 로직을 일일이 직접 구현하지 않고도 애플리케이션 객체를 데이터 저장소에 넣고 빼올 수 있게 해 줍니다. Thomas는 제가 늘 가지고 있었지만 말로 표현하지 못했던 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: 언급되는 것을 본 적은 있지만 지금은 서비스가 종료됐다. 그다지 인기가 있었던 것 같지는 않다.

Python의 선

여러 발표자가 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은 거기에 등록되어 있지 않아 제출 마감일을 놓쳤습니다. 내년에는 꼭 캘린더에 넣어둬야겠습니다.

효과적이었던 발표의 공통점

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

발표를 약하게 만든 요소

• 마이크 문제
  • 가장 기본적이고 지루한 요소인 음질 때문에 발표에 몰입이 깨지는 경우가 많았다는 점이 아쉽다.
  • 콘퍼런스에서는 귀에 거는 Tony Robbins 스타일 마이크를 사용했는데, 많은 발표자가 위치를 제대로 잡지 못해 소리가 자꾸 들렸다 안 들렸다 했다.
  • 다른 발표자들은 핸드 마이크를 선택했지만 입 가까이 대고 충분히 큰 목소리로 말하지 못해 마이크가 소리를 잘 잡지 못했다.
• 정체된 슬라이드
  • 가장 뛰어난 발표자들은 슬라이드를 brisk하게 넘겼다. 최소 30초에 한 번은 슬라이드를 넘기거나 새로운 불릿을 띄웠다. 60초 이상 같은 슬라이드를 그대로 둔 채 아무 변화도 주지 않을 때는 정체된 느낌이 들었다.
• 대본 읽기
  • 라이브 콘퍼런스의 재미 중 하나는 청중으로서 발표의 일부가 되는 것이다. 발표자가 청중의 에너지에 반응하며 발표를 조정한다. 발표자가 긴 구간을 대본 그대로 읽어 내려갈 때(혹은 전체 발표가 고정된 대본일 때)는 라이브 발표의 재미가 사라진다.
• 움짤
  • 주의를 분산시켰고, 특히 몇 초 이상 화면에서 계속 반복 재생될 때 더 그랬다.
  • 가벼운 농담이 발표자의 요지를 흐리는 경우가 많다고 느꼈다.
• “이건 예전 슬라이드입니다.”
  • 몇몇 발표에는 이전 콘퍼런스에서 재활용한 탓에 1~2년 전 정보가 포함되어 있었다. 발표자는 슬라이드가 오래됐다고 양해를 구했지만, 미리 리허설을 한 번만 했어도 잡을 수 있는 문제를 신경 쓰지 않았다는 인상을 받아 늘 아쉬웠다.

내 발표 되돌아보기

발표자: Michael Lynch (저)

슬라이드

• 잘한 점

  • 준비성: 발표 전 몇 주 동안 5~8회 리허설을 해서 내용에 익숙해졌다.
  • 슬라이드 진행 속도: 영상을 다시 보니 정체 없이 발표를 적절한 속도로 끌고 갔다.
  • Java를 살짝 디스한 부분(16:15 참조)이 큰 웃음을 얻었다.

• 개선할 점

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

그 밖의 생각

일반 참가자보다 발표자로 참석하는 편이 훨씬 가치 있다

앞으로 콘퍼런스에 계속 참석할지 고민하면서 발표자가 아니라 일반 참가자로 가볼까도 생각해 봤다. 발표자로 참석할 때가 열 배는 더 가치가 있다고 느꼈다.

발표자는 사람들에게 더 관심을 받는다. 발표 전에도 “뭔가 잘하는 게 있으니 발표를 하겠지”라는 인식이 있다. 발표가 끝난 뒤에는 발표 내용을 공통 화제로 삼아 말을 걸기 쉽기 때문에 더 많은 사람이 대화를 시도한다.

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

무언가를 요청했어야 했다

모든 발표자는 사실상 발표 중에 한 번의 “행동 요청” 기회를 얻는다. 대부분은 자사에 지원해 달라는 요청이나 자사 제품을 써 달라는 요청이다. 나는 채용 중도 아니고 프로젝트 사이의 휴식기에 있어 행동 요청을 생각하지 못했다.

발표가 끝난 지 한 시간쯤 지나서 “아, 기업들에 고충을 알려 달라고 할 걸!”이라는 생각이 들었다. PyTexas 참석자 중 상당수는 일상 업무에서 “이거 하기 싫다. 왜 이걸 대신 처리해 주는 관리형 서비스가 없을까?”라고 생각하는 지점이 있을 것이다. 이런 문제 중 상당수는 제품을 만드는 사람과 미충족 수요가 있는 중소기업을 연결하기 어려워 해결되지 않은 채 남아 있다. PyTexas에서 “저에게 이야기해 주세요. 그 서비스를 만들어 드릴 수도 있습니다”라고 말하기 좋은 자리였을지 모른다.

싱글 트랙 콘퍼런스의 분위기는 다르다

이번이 처음으로 참석한 싱글 트랙 콘퍼런스였다. 싱글 트랙이란 어느 시점이든 한 번에 하나의 발표만 진행된다는 뜻으로, 참석자는 들을 발표를 고를 필요가 없고 언제나 선택지는 하나뿐이다.

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

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

비용

이번 콘퍼런스 참석에는 예상보다 많은 비용이 들었습니다:

금전적 비용을 넘어 시간 비용도 컸습니다. 이틀짜리 콘퍼런스였지만 실제로는 5일 정도가 소모됐습니다. 이동에 왕복 각각 하루가 걸렸고, 자리를 비운 사이 밀린 개인 용무를 처리하는 데 하루가 더 들었습니다. 그 외에도 슬라이드 덱을 만들고 리허설하는 데 20~30시간을 썼습니다.

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

연초에 2019년에 콘퍼런스에서 세 번 발표하겠다는 목표를 세웠습니다. PyTexas는 두 번째 콘퍼런스였으니 올해 한 번 더 하면 적절한 수준일 것 같습니다.

제게 콘퍼런스의 이점은 새로운 사람을 만나고, 평소에는 접하지 못할 도구와 기법을 알게 되며, 대중 앞에서 말하는 연습을 할 수 있다는 점입니다. 가장 큰 수확 중 하나는 Penflip을 알게 된 것이었습니다. 전혀 예상하지 못한 발견이었지만 그들의 실패를 파악함으로써 많은 시간과 비용을 아낄 수 있을 것 같습니다.