"다음 테크 토크 발표자 지원 받습니다."

슬랙 공지를 보고 스크롤을 내리려다가 멈췄다. 격주로 하는 사내 테크 토크. 30분 발표, 10분 Q&A. 입사한 지 8개월인데 한 번도 안 했다. 팀 리드가 한 번 넌지시 물어봤을 때 "준비 좀 하고요"라고 얼버무렸다. 솔직히 무서웠다. 사람들 앞에서 말하는 게. 대학교 때 팀 프로젝트 발표에서도 항상 코드 데모를 맡았다. 설명하는 역할은 피했다.

근데 계속 피할 수만은 없다는 건 알고 있었다. 손을 떨면서 댓글을 달았다. "저 하겠습니다."

주제 선정에서 이미 삽질#

발표 일정이 2주 뒤로 잡혔다. 처음 든 생각은 "뭔가 대단한 걸 해야 한다"였다. React Server Components 딥다이브, 마이크로 프론트엔드 아키텍처, 서버리스 렌더링 최적화. 그런 거창한 주제를 떠올렸다.

3일 동안 자료를 찾다가 포기했다. 발표 준비가 공부가 됐다. 내가 충분히 모르는 주제를 발표하겠다고 한 거였다. 발표의 핵심은 내가 잘 아는 것을 다른 사람이 이해할 수 있게 전달하는 건데, 나 자신도 이해하지 못하는 걸 전달하려고 했다.

시니어한테 조언을 구했더니 "네가 최근에 실제로 겪은 문제를 말하는 게 가장 좋아"라고 했다. 추상적인 기술 설명보다 "이런 문제가 있었는데 이렇게 해결했다"가 듣는 사람한테도 더 재미있다고.

기술 발표에 대해 글을 쓴 한 개발자가 비슷한 말을 했다. 좋은 발표의 출발점은 외부적 동기(커리어, 인정)가 아니라 내부적 동기라고. "이미 존경과 돈이 충분하다고 가정해도 이 발표를 할 건가?"라는 질문을 던져보라고. 핵심은 자기가 진짜 흥미로운 아이디어를 공유하고 싶은가, 아니면 잘 보이고 싶은가의 차이라는 거였다.

내가 진짜 흥미롭게 느꼈던 건 거창한 아키텍처가 아니라, 지난 달에 상품 상세 페이지의 이미지 로딩 성능을 개선한 경험이었다. LCP가 4.2초에서 1.8초로 줄었다. 과정에서 실패한 시도도 있었고, 예상 밖의 발견도 있었다. 이게 내가 직접 겪은 거라 따로 자료를 찾을 필요가 없었다.

슬라이드 40장, 그리고 뺄셈#

첫 번째 버전의 슬라이드가 40장이었다. 30분 발표에 40장이면 장당 45초. 너무 빠르다.

문제는 양이 아니라 밀도였다. 슬라이드에 설명을 전부 적어놨다. 한 장에 문단이 3개. 발표자가 입으로 할 말을 화면에 다 적어놓으면 청중은 발표자 말을 안 듣고 슬라이드를 읽는다. 동료한테 리뷰를 부탁했더니 딱 한마디 했다. "글이 너무 많아."

25장으로 줄이는 과정이 발표 준비에서 가장 어려운 부분이었다. 15장을 빼는 게 아니라 15장분의 내용을 포기하는 거다. 성능 측정 방법에 대한 5분짜리 설명, Lighthouse 점수 해석 방법, 번들 분석 도구 비교. 전부 "넣으면 좋은 내용"이었지만 "없으면 안 되는 내용"은 아니었다.

이 뺄셈이 나중에 최선의 결정이었다는 걸 알게 된다.

새벽 3시의 슬라이드#

발표 전날 밤이었다. 혼자 리허설을 4번째 하고 있었다. 시간은 잘 맞았다. 흐름도 괜찮았다. 근데 뭔가 찝찝했다. 17번째 슬라이드에서 자꾸 걸렸다. 이미지 지연 로딩의 원리를 설명하는 슬라이드였는데, Intersection Observer API의 동작 원리를 코드로 보여주는 부분이었다. 기술적으로 정확했다. 근데 전체 흐름에서 템포를 죽이고 있었다.

새벽 3시에 결정했다. 그 슬라이드를 통째로 잘라냈다. 대신 한 줄로 요약했다. "뷰포트에 이미지가 보일 때만 로드합니다. 구현은 Intersection Observer API를 사용했습니다." 기술 상세는 "코드는 PR 링크 참고"로 대체했다.

이게 왜 좋은 결정이었는지는 발표 당일에 알았다. 그 슬라이드가 있었다면 거기서 2~3분을 쓰면서 청중의 집중력이 떨어졌을 거다. API 동작 원리는 듣는 사람의 절반은 이미 알고 있었고, 나머지 절반은 코드를 보면서 따라가느라 전체 흐름을 놓쳤을 거다. 빼니까 발표가 매끈하게 흘러갔다.

발표 후에 기술 블로그를 운영하는 한 개발자의 글에서 비슷한 원칙을 봤다. 좋은 발표에는 "What(핵심 아이디어 하나)", "Why(왜 청중이 관심을 가져야 하는가)", "How(구체적인 방법)"의 세 가지가 필요한데, 그 중에서 What은 12단어 이내여야 한다고. 하나의 핵심 아이디어에 집중하라는 거다. 내가 잘라낸 슬라이드는 How에 해당하는 세부 내용이었는데, 그걸 빼도 What과 Why는 충분히 전달됐다.

발표 당일 아침#

아침부터 배가 아팠다. 진짜 물리적으로. 긴장하면 배가 아픈 체질이다. 출근길 지하철에서 슬라이드를 처음부터 끝까지 머릿속으로 돌렸다. 역을 한 번 지나쳤다.

발표 시간 10분 전에 회의실에 들어갔다. 모니터 연결 확인, 슬라이드 확인. 사람들이 하나둘 들어왔다. 15명. 생각보다 많았다. 다른 팀 사람도 몇 명 있었다. 내 발표를 보러 온 건가? 아니면 그냥 테크 토크니까 온 건가? 어느 쪽이든 심장이 빨라졌다.

첫 슬라이드를 띄웠다. "상품 상세 페이지 이미지 로딩 최적화." 입을 열었는데 목소리가 떨렸다. "안녕하세요, 오늘은..." 이 다섯 글자가 이렇게 어려울 줄 몰랐다. 손에 들고 있던 프레젠터가 흔들렸다. 청중 중 한 명과 눈이 마주쳤는데, 그 사람이 살짝 고개를 끄덕였다. 그게 조금 도움이 됐다.

2분쯤 지나니까 가라앉기 시작했다. 문제 상황을 설명하면서 코드를 보여줬는데, 코드 얘기를 하니까 편해졌다. 익숙한 영역이었다. 내가 직접 짠 코드, 내가 직접 겪은 문제. 이건 "발표"가 아니라 "동료한테 내가 한 일을 설명하는" 거였다. 그 프레이밍이 긴장을 줄여줬다.

그 블로그에서 본 조언과 맞닿는 부분이 있었다. 발표자의 역할은 "무대 위의 퍼포머"가 아니라 "아이디어의 메신저"라는 거. 사람들이 나를 판단하러 온 게 아니라, 유용한 정보를 듣고 싶어서 온 거라고 생각하면 긴장이 줄어든다고. 실제로 그랬다. "이 사람들이 내 발표를 평가하고 있다"에서 "이 사람들한테 내가 겪은 걸 공유하고 있다"로 관점을 바꾸니까 몸이 풀렸다.

중간에 막혔다#

다음 슬라이드로 넘기고 나서 뭘 말해야 할지 까먹었다. 2초. 그 2초가 영원처럼 느껴졌다. 머릿속이 하얘졌다. 슬라이드에 적힌 키워드를 봤다. "CDN 캐시 설정 변경." 아, 맞다. CDN 얘기. 기억이 돌아왔다.

나중에 동료한테 물어봤다. "중간에 내가 멈춘 거 눈치 챘어?" 못 챘다고 했다. 발표자가 느끼는 2초의 침묵과 청중이 느끼는 2초의 침묵은 다르다. 발표자한테는 치명적인 실수 같지만, 청중한테는 그냥 "잠깐 생각을 정리하는 시간" 정도로 보인다. 이걸 알게 된 게 큰 수확이었다. 완벽하지 않아도 된다. 그리고 완벽하지 않은 부분을 청중은 대부분 모른다.

대답 못한 질문#

발표 자체보다 Q&A가 더 무서웠다. 예상 못한 질문이 올 수 있으니까. 리허설은 가능하지만 Q&A 리허설은 불가능하다.

질문 두 개가 나왔다. 첫 번째는 쉬웠다. "이 최적화를 다른 페이지에도 적용할 계획이 있나요?" "네, 다음 스프린트에 목록 페이지에도 적용할 예정입니다."

두 번째 질문이 문제였다. "이미지 포맷을 WebP로 변환하는 건 고려했나요? 현재 JPEG 대비 얼마나 개선이 될 수 있을까요?"

고려는 했다. 근데 도입하지 않은 이유가 있었다. 그 이유가 순간적으로 기억이 안 났다. CDN 설정 변경 때문이었는지, 호환성 문제였는지, 인프라 팀 리소스 부족이었는지. 머릿속에서 세 가지가 뒤섞였다. 2초가 지나고, 3초가 지나고.

대충 답할 수 있었다. "네, 고려했고, 여러 이유로 이번에는 도입하지 않았습니다." 이 정도로 넘어갈 수도 있었다. 근데 발표 전에 시니어가 해준 조언이 떠올랐다. "모르는 건 모른다고 해. 대충 답하는 거보다 100배 낫다."

솔직하게 말했다. "고려는 했는데, 당시에 도입하지 않은 구체적인 이유를 지금 바로 말씀드리기 어렵네요. 확인해서 슬랙으로 공유드릴게요."

그 순간에는 "발표자가 질문에 답 못하면 창피한 거 아닌가?"라는 생각이 스쳤다. 근데 회의실 분위기는 전혀 이상하지 않았다. 질문한 분도 "네, 궁금해서 물어본 거예요"라고 자연스럽게 넘어갔다.

다음 날 이유를 정리해서 슬랙에 올렸다. CDN 설정 변경에 인프라 팀의 작업이 필요했고, 그 분기에 인프라 팀의 리소스가 이미 꽉 차 있어서 다음 분기로 미뤘다는 거였다. 그리고 WebP 변환 시 예상 개선치도 추가로 조사해서 같이 적었다.

이 후속 메시지가 발표 자체보다 반응이 좋았다. "오 이거 정리 잘 해주셨네요", "우리 팀에도 비슷한 이슈가 있는데 참고할게요." 발표에서 답 못한 질문이 더 깊은 대화의 시작점이 된 거다.

발표 후에 달라진 것들#

발표가 끝나고 박수를 받았다. 형식적인 건지 진심인 건지는 모르겠다. 근데 "끝났다"는 안도감이 밀려왔다. 회의실을 나오는데 다른 팀 동료가 다가와서 "발표 좋았어요, 저도 비슷한 이슈가 있었는데 참고할게요"라고 했다. 2주 동안의 준비가 보상받는 느낌.

그리고 예상 못한 변화가 있었다. 발표를 하고 나니까 팀에서 "이미지 최적화 관련 사람"이 됐다. 이미지 관련 이슈가 생기면 "이거 전에 발표한 사람한테 물어보자"가 된다. 발표 하나가 팀 내 포지셔닝에 영향을 준 거다.

기술 문서 쓰는 것도 쉬워졌다. 슬라이드를 만드는 과정에서 "복잡한 내용을 구조화하는 연습"을 한 거다. 문제 상황, 시도한 방법, 결과. 이 흐름이 몸에 배니까 문서 작성에도 바로 적용됐다.

미팅에서 의견 말하기도 수월해졌다. 15명 앞에서 30분 발표한 사람이 5명 미팅에서 1분 발언 못 할 이유가 없다. 여전히 긴장은 되지만, "그 정도는 해봤으니까"라는 경험치가 심리적 버팀목이 된다.

다시 한다면 다르게 할 것들#

첫 발표를 복기하면서 적은 메모가 있다.

영상을 찍어둘 것. 다른 분 발표는 녹화해서 노션에 올려놓는데, 내 발표는 녹화를 깜빡했다. 자기 발표를 돌려보는 게 제일 효과적인 피드백이라는데, 기회를 놓쳤다.

리허설을 동료 앞에서 더 일찍 할 것. 혼자 4번 하고 동료 앞에서 1번 했는데, 동료 앞에서 하는 1번이 혼자 하는 4번보다 배우는 게 많았다. 사람이 앞에 있으면 완전히 다르다. 다음에는 슬라이드 초안이 나오는 시점에 바로 동료 앞에서 리허설한다.

코드 슬라이드의 폰트 크기를 키울 것. 20줄짜리 코드를 한 번에 보여주면 뒷자리에서 안 보인다. 중요한 부분만 먼저 보여주고, 전체 코드는 별도 링크로 제공하는 게 낫다.

Q&A 예상 질문을 더 많이 준비할 것. 5개 정도 준비했는데 부족했다. 다음에는 10개. 그리고 "모른다"라고 말하는 연습도 해둘 것. 첫 번째로 "모르겠습니다"라고 말하는 순간이 제일 어렵다. 두 번째부터는 좀 편해진다.

두 번째 발표#

6개월 후에 두 번째 발표를 했다. 주제는 디자인 시스템 컴포넌트의 접근성 개선. 이번에는 준비 과정이 훨씬 수월했다. 주제 선정에 3일 대신 1일, 슬라이드 제작에 1주 대신 4일, 리허설에 5번 대신 3번. 그리고 처음부터 동료 앞에서 리허설했다.

여전히 떨렸다. 근데 첫 번째 때의 "세상이 무너지는 것 같은" 떨림이 아니라 "좀 긴장되네" 수준의 떨림이었다. 크게 다른 건 없었다. 준비하고, 연습하고, 떨면서 하고, 끝나면 안도한다. 이 사이클은 바뀌지 않았다.

다만 하나 확신하게 된 건 있다. 발표는 준비한 사람이 가장 많이 배운다. 듣는 사람은 30분 동안 유용한 정보를 얻지만, 발표하는 사람은 2주 동안 그 주제에 대해 이전보다 2배는 더 깊이 이해하게 된다. 발표는 청중을 위한 것이기도 하지만, 결국 발표자 본인을 위한 거다. 떨면서라도 하는 이유가 거기에 있다.