아주 천천히 써보는 FEConf 발표 준비 후기 (1/2)
이 글은 (구) 메쉬코리아 웹프론트엔드 팀 블로그에 2021년 4월 15일에 게시된 글입니다.
나는 계획을 잘 세우지 않는 편이다. “계획을 세워도 그대로 가지 않는 게 대부분이고, 계획만 고집해서는 변화하는 상황에 대처하기 힘들다”는 그럴싸한 변명으로 나의 충동적인 성향을 포장한 지도 오래됐다.
그렇지만, 세상에는 계획이라는 것을 세우고 치밀하게 접근해야만 잘 해내는 일이 분명히 있기 마련이다. 많은 사람이 관여하는 큰 행사일수록 더더욱 그렇다. 나에게는 FEConf 2020에서 발표를 했던 것이 그런 일이었다. 그 어느 때보다도 치밀하게 준비했고, 덕분에 개인적으로 만족스러운 발표를 할 수 있었다. 이 글에서는 컨퍼런스 발표를 준비한 과정이 어땠는지 복기하려 한다.
본격적인 이야기에 앞서, 발표했던 영상은 여기서 시청하실 수 있다.
https://www.youtube.com/embed/J4JHLESAiFk
튀어나온 옷깃과… 불안한 눈빛과… 그걸 지켜보는 나…
발표 제안하기
FEConf는 치열한 티케팅으로 유명한 국내 최대 규모의 웹 프론트엔드 개발 컨퍼런스다. 약간(?)의 관종기가 있는 나는 언젠가는 저기서 한 번 발표해보겠다고 오래전부터 생각해왔다. 물론, 팀 채용에 도움이 되겠지 하는 대의명분도 없었던 것은 아니었다.
하지만 티케팅이 치열한 행사에서 발표자로 선정되는 것 역시 쉬울 리가 없다. 아시다시피 자바스크립트 커뮤니티는 넓다. 그곳에서 활동하는 사람이 그렇게 많은데, 다들 하고 싶은 이야기가 얼마나 많겠는가. 커뮤니티 활동을 거의 하지 않는 나도 발표자 신청을 준비하고 있는데, 나 같은 사람이 많을 것 역시 뻔했다. “당신이 하는 생각은, 다른 누군가가 반드시 해봤을 생각이다.” 발표 역시 그렇다.
내가 발표자로 선정될 확률이 높을까? 아니었다. 나는 커뮤니티 활동을 하지 않는 편이다. 유명한 사람도 아니다. 이런 행사에 참여해봤던 전례도 없다. 빙글에서 주최하는 테크 톡에 한 번 참여해본 적은 있으나, 그렇게 사람이 많이 왔던 것은 아니었다. 게다가 오류 덕분에 영상 녹화도 실패해, 어떻게 발표를 했는지 아는 사람도 별로 없다. 그러니, 컨퍼런스를 준비하는 사람은 나를 모를 것이다. 그렇다면 내가 무엇을 해야 발표자로 선정이 될 수 있을까? 매력적인 주제, 그리고 내가 발표를 충분히 준비했다는 티가 팍팍 나는 제안서. 이 2개가 필요하다고 생각했다.
발표 주제 선정하기
먼저, 매력적인 주제란 어떤 주제일까? 발표를 듣는 사람의 입장에서 생각해봤다. FEConf 2020은 온라인으로 진행됐다. 발표는 영상 형태로 공유된다. 바쁜 시간을 투자해 긴 영상을 볼 때, 글로 읽는 것보다 얻어가는 것이 더 적다고 느낀다면 굉장히 허무할 것이다. 또, 그 내용이 시청자의 지식수준과 비슷하거나 떨어진다면, 발표를 보는 것 자체가 시간 낭비처럼 느껴질 것이다.
이렇게 생각하다 보니, ‘글로 많이 공유되지 않았으며, 내가 많이 경험해본 것’을 발표하자는 것을 기본적인 기조로 삼을 수 있었다. 그러다 보니, 우리 회사에서 프론트엔드 기능을 개발할 때마다 가장 첫 관문을 담당하는 OpenAPI Specification을 발표해보자는 생각을 하게 되었다.
OpenAPI Specification은 자바스크립트 커뮤니티에서 한국어로 글이 많이 공유되지 않았다. 덕분에 온갖 고생을 하기도 했다. 그러다 보니 나에게 노하우가 그래도 어느 정도는 쌓여있는 기술이기도 했다. 그러고 주위 친구들에게 이 기술을 써본 적이 있냐고 물어봤다. 생소하다는 답변만 돌아왔다. 가려운 곳을 잘 긁어주는 기술인데, 사람들에게 생소하다? 이런 주제야말로 발표했을 때 많은 사람들에게 도움이 될 수 있는 주제다. 이렇게 발표 주제가 정해졌다.
발표 주제 포장하기
하지만 발표 주제를 선정했다고 모든 것이 끝나는 것은 아니다. 발표 주제 선정은 준비 작업의 시작에 불과할 뿐이다. 이제 포장지로 주제를 감쌀 시간이다.
스타크래프트 게임 해설가 엄재경 씨와 스티브 잡스의 공통점은 무엇일까? 포장의 전문가라는 점이다. 엄재경 씨는 별로 중요하지 않을 것 같은 경기도 온갖 의미를 부여하고, 선수 하나하나에 캐릭터를 정해 게임을 보는 사람들을 환호하게 했다. 스티브 잡스야 뭐, ‘현실 왜곡 장’으로 유명하지 않았나. 그가 직접 발표하는 모든 제품은 이 행성에서 가장 멋있고(그가 즐겨 쓰던 표현이다), 나의 삶을 완전히 바꿔줄 것 같다는 느끼게 했다.
OpenAPI Specification이라는 기술 자체가 주위의 개발자들에게 워낙 생소하다 보니, 나도 이들처럼 포장을 해야겠다고 생각했다. 하지만, 포장은 그냥 한다고 되는 것이 아니다. 명품을 비닐봉지로 포장할 수도 없는 것이고, 마트 상품을 박스로 정성스레 포장할 수도 없는 노릇이다. 이 발표를 듣는 사람, 그리고 그들이 필요로 하는 것을 적확하게 긁어줄 수 있도록 발표를 구성해야 했다.
먼저, 이 발표의 타겟을 설정했다. 어쨌든, OpenAPI Specification은 전통적인 RESTful API를 위한 도구다. 물론 API에는 GraphQL부터 gRPC까지 다양한 대안이 있는 것이 맞다. 하지만 가장 전통적이고, 서버 개발자들이 가장 익숙해하는 것이 RESTful API인 것은 엄연한 현실이다. GraphQL을 쓰자고 설득하는 것이 조금 어려운 것이 아니니 말이다. 그래서 이 발표의 타겟을 “현업에서 RESTful API를 사용하고 있지만 개발에 불만족하는 사람”으로 꼽았다.
그렇다면 불만족하는 사람이 만족할만한 요소는 무엇일까? 여기서 내가 ‘셀링 포인트’로 꼽은 단어가 타입-세이프(type-safe)다. OpenAPI Specification은 명세 문서를 기반으로 API 함수를 자동으로 만들어준다. 타입스크립트 지원도 해준다. API 함수의 리턴 타입 역시 문서를 기반으로 자동으로 지정해준다. 타입스크립트를 처음 접하는 사람들이 가장 귀찮음을 느끼는 포인트를 잘 해결해주고, API 리턴 타입을 기반으로 타입-세이프한 개발을 할 수 있게 한다는 것이 내가 느낀 OpenAPI Specification의 가장 큰 장점이었다.
하지만 무조건 장점만 얘기하면 오히려 비전문적으로 보일 수 있다. 속된 말로 ‘약 팔이’나 ‘기술 장사’처럼 보인다면 그거야말로 최악이다. ‘아 그런가 보다.. 하지만 실제로 적용하면 뭐 불편하겠지~’ 정도의 인상만 남기고 잊히게 되기 때문이다. 다시 보고 싶은 유용한 발표를 하려면 이상적인 시나리오만 전달하는 것이 아니라 현실적으로 겪었던 어려움을 같이 전해 발표를 좀 더 실용적이게 느껴지도록 해야 한다.
이런 생각을 바탕으로 이 발표의 제목을 정했다. 여러 사람들의 의견을 들으며 조금씩 워딩을 조정했고, 덕분에 약간 미디엄식 click bait 같긴 하지만 어쨌든 현실은 잘 반영하고 있는 제목을 확정했다. 그 제목이 바로 여러분도 보셨을 “OpenAPI Specification으로 타입-세이프하게 API 개발하기: 희망 편 vs 절망 편”이었다.
발표 내용 구성하기
이렇게 발표 재료를 정하고, 타겟을 설정하고, 강조할 지점을 정하면서 발표를 어떻게 진행할지 자연스레 얼개가 짜이기 시작했다. 이제 내가 해야 하는 것은 그 얼개를 구체화해 제안서에 담아내는 일이었다.
전반적인 발표 구성은 ‘3의 법칙*’에 따라 도입부 — 희망 편 — 절망 편 3개 섹션으로 구성했다. 사람들이 가장 익숙하고 편안해하는 구성이기 때문이다. 여기에 덧붙여 마지막으로 짧은 요약정리 정도로 발표를 마무리하면 되겠다는 생각을 했다.
> 3의 법칙: 3은 적음의 끝이자 많음의 시작이다. 포인트를 3가지로 요약해 전달하면 내용이 많지도 적지도 않고 적당하게 느껴진다.
도입부: 스토리텔링
코로나19로 인해, FEConf 2020은 온라인으로 진행되었다. 온라인 발표와 오프라인 발표는 아주 다르다. 오프라인 발표는 한 번 세션을 선택하면 다른 세션으로 이동하기 힘들다. 눈치도 보이고, 다른 발표는 이미 자리가 꽉 차 있을 테니까. 하지만 온라인 발표는 지루하거나 내용이 마음에 들지 않으면 언제든지 끌 수 있다. 시청자의 이탈을 고려해, 도입부에는 스토리텔링 요소를 조금 넣었다.
현실 왜곡 장의 대가인 스티브 잡스는 아이폰을 발표할 때 초반부에 아이폰이 시장에서 어느 영역에 있을 것인지, 스크린이 화면을 꽉 채운 이유가 무엇인지, 스타일러스 펜을 쓰지 않는 이유가 무엇인지 등을 기존 제품과의 비교와 유저 스토리를 통해 완벽하게 제시했다. 비슷하게, 프론트엔드 개발자로서 일을 할 때 어떻게 하고 있는지, 그것이 얼마나 고통스러운 작업인지, 그리고 OpenAPI Specification이 그 문제를 어떤 문제를 해결해주는지 설명하는 것을 도입부로 삼는다면 사람들이 충분히 생소한 기술에 대한 발표에 흥미를 느낄 것이라 생각했다.
그래서 아래와 같이 ‘개발자의 경험’에 초점을 맞춰 도입부의 개요를 완성했다.
희망 편
처음에는 희망 편을, 단순히 ‘OpenAPI Specification이 이렇게 좋아요!’ 느낌으로 정리하려 했다. ‘3의 법칙’에 맞춰 개발자에게 좋은 점 / 생태계 / 프론트엔드 개발 편의로 3단 구성을 했고, 이를 사무실에 있던 팀원들에게 쓱 공유했다. 생소한 기술이다 보니 좀 더 프론트엔드 개발자 입장에서 와닿도록 설명해주는 것이 좋겠다는 피드백을 받았다. (해균님 감사합니다…)
피드백을 받은 후, 타겟 청중을 다시 생각하며 프론트엔드 개발 편의를 좀 더 많이 강조하는 쪽으로 구성을 틀었다. 발표의 제목을 생각하며 타입 세이프한 API 개발이 얼마나 편한지 좀 더 풀어서 설명하는 쪽으로 구성했다.
피드백을 거쳐 완성된 ‘희망 편’의 개요는 아래와 같다.
절망 편
사실 OpenAPI Specification은 여러 가지 이유로 실제 적용을 할 때 예상치 못한 귀찮음이 생기곤 한다. 특히 제너레이터가 이런저런 문제를 만들곤 하는데, 이런 점들을 솔직하게 정리하는 식으로 절망 편을 구성했다.
실제 발표 자료를 만들 때 좀 더 구체화를 하기로 다짐하고, 제안서에는 최대한 드라이하게 내가 실제로 겪었던 문제들을 정리했다. 어쨌든 발표자가 다양한 상황을 많이 겪었다는 것을 보여줘 신뢰를 얻자는 것이 처음 생각한 ‘절망 편’의 방향성이었기 때문이다.
희망 편보다는 약간 대충 정리된 절망 편의 개요는 아래와 같다.
보너스: 결론
절망 편에서 발표를 끝내면 정말로 이도 저도 아닌 발표가 된다. 이 기술이 괜찮고, 사람들이 많이 썼으면 좋겠다는 방향성을 명확하게 제시하는 것으로 발표를 마무리하는 것을 보여주며, 제안서를 마무리했다.
다행히 얼마 뒤 나는 발표자로 선정이 되었다. 이제 사람들에게 보일 발표 소개글 및 발표 자료 제작 등 본격적인 단계로 넘어가게 되었다.
(2부에서 계속…)
