개발자의 발표 잘하는 법: 두려움을 넘어서

저는 개발자로 일하면서 발표가 코딩보다 어렵다고 느낀 적이 많았습니다. 코드는 문제가 생기면 멈춰서 원인을 찾을 수 있지만, 발표는 여러 사람의 시선 앞에서 생각과 말이 동시에 움직여야 했기 때문입니다. 특히 팀 회의에서 제가 만든 기능을 설명하는 일은 익숙했지만, 다른 부서 사람들까지 참석하는 기술 공유 자리에서는 목소리가 작아지고 말이 빨라졌습니다. 머릿속으로는 순서까지 차분히 정리했다고 생각했는데, 막상 앞에 서면 첫 문장부터 흔들렸습니다. 지금도 긴장하긴 하지만, 예전처럼 두려움 때문에 발표 자체를 피하지는 않습니다.

▲ 관련 컬러 사진

가장 기억에 남는 실패는 입사 2년 차에 진행한 사내 발표였습니다. 새로운 화면 처리 방식을 소개하는 자리였고, 저는 구현 과정과 수치 자료를 꽤 많이 준비했습니다. 문제는 청중이 그 기술을 왜 알아야 하는지 설명하지 않은 채 내부 구조부터 이야기했다는 점입니다. 슬라이드에는 낯선 용어와 작은 글씨가 가득했고, 저는 준비한 내용을 빠짐없이 전달하려고 속도를 높였습니다. 발표가 끝난 뒤 한 동료가 “그래서 사용자에게 달라지는 점이 무엇인가요?”라고 물었을 때, 저는 그제야 가장 중요한 내용을 빼먹었다는 사실을 깨달았습니다. 많이 아는 것과 잘 설명하는 것은 전혀 다른 능력이었습니다.

발표의 시작은 자료가 아니라 목적이었다

그 실패 이후 저는 발표 자료를 만들기 전에 한 문장부터 적습니다. “이 발표가 끝났을 때 사람들이 무엇을 기억해야 하는가?”라는 질문입니다. 기술의 작동 원리를 설명하는 자리라도 청중이 얻어 가야 할 핵심은 대개 한두 가지로 좁혀집니다. 예를 들어 성능 개선을 발표한다면 모든 변경 파일을 보여주는 대신, 기존 방식의 불편함과 바뀐 뒤의 차이를 먼저 말합니다. 저는 최근 한 기능의 처리 시간을 줄인 경험을 공유하면서 복잡한 구조도부터 꺼내지 않고, 사용자가 기다리는 시간이 얼마나 줄었는지부터 설명했습니다. 그러자 청중의 표정이 달라졌고, 뒤의 기술적인 설명도 훨씬 자연스럽게 이어졌습니다.
발표를 준비할 때는 청중을 한 덩어리로 생각하지 않으려고 합니다. 같은 개발자라도 담당 분야와 경험에 따라 궁금한 점이 다르고, 기획자나 운영 담당자는 구현 세부보다 영향과 일정에 관심이 큽니다. 저는 발표 전 참석자 명단을 보고 각 사람이 어떤 질문을 할지 세 가지씩 적어봅니다. 그 질문을 중심으로 내용을 덜어내면 자료가 훨씬 단순해집니다. 예전에는 준비한 내용을 모두 보여줘야 성실하다고 여겼지만, 지금은 덜어낸 부분이 오히려 발표의 집중도를 높인다고 생각합니다. 발표자는 자신의 지식을 증명하는 사람이 아니라, 청중이 이해할 수 있도록 길을 안내하는 사람에 가깝습니다.

슬라이드는 읽는 문서가 아니라 말의 지도다

저는 한때 발표 화면에 설명을 거의 문장 그대로 적어두었습니다. 발표 중 머리가 하얘져도 화면을 보면 다시 이어갈 수 있다고 믿었기 때문입니다. 실제로는 반대였습니다. 화면에 글이 많으니 사람들은 제 목소리보다 슬라이드를 읽었고, 저는 화면의 문장을 그대로 따라 읽게 됐습니다. 지금은 한 화면에 하나의 주장만 남기고, 핵심 숫자나 비교 자료처럼 말로 전달하기 어려운 내용만 크게 보여줍니다. 세부 설명은 발표자 메모에 적어두되 화면에는 넣지 않습니다. 자료를 만든 뒤에는 화면을 보지 않고도 각 장의 핵심을 한 문장으로 말할 수 있는지 확인합니다.
한 번은 발표 전날까지 도표의 색과 간격을 고치느라 정작 말할 연습을 하지 못한 적도 있습니다. 당일에는 슬라이드가 깔끔해서 마음이 놓였지만, 페이지가 넘어가는 순간마다 다음에 무슨 말을 해야 할지 잠깐씩 멈췄습니다. 그 뒤로는 자료를 완성한 시점보다 말의 흐름을 확인한 시점을 더 중요하게 봅니다. 저는 발표 내용을 시작, 문제, 선택, 결과, 배운 점의 다섯 구간으로 나누고 각 구간 사이에 연결 문장을 준비합니다. “이제 구현 방식보다 결과를 보겠습니다”처럼 다음 내용을 예고하면 저도 호흡을 고를 수 있고, 듣는 사람도 흐름을 놓치지 않습니다.

긴장을 없애기보다 다루는 연습

발표 전 긴장을 완전히 없애는 방법은 아직 찾지 못했습니다. 대신 긴장한 상태에서도 움직일 수 있는 장치를 만들었습니다. 발표 직전에는 물을 한 모금 마시고, 첫 문장만은 외워둡니다. 첫 문장이 자연스럽게 나오면 이후의 속도가 조금 안정되기 때문입니다. 또 발표 시작 전에 참석자 한두 명과 가볍게 인사를 나눕니다. 낯선 얼굴이 모두 평가자로 보일 때보다, 아까 대화를 나눈 사람들에게 설명한다고 생각할 때 부담이 줄어듭니다. 저는 발표 중 숨이 차면 문장 끝에서 억지로 이어가지 않고 잠시 멈춥니다. 그 짧은 침묵은 제게는 길게 느껴져도 청중에게는 생각을 정리하는 시간으로 받아들여졌습니다.
제가 특히 어려워했던 순간은 질문과 답변 시간이었습니다. 예전에는 모든 질문에 즉시 정확한 답을 내놓아야 한다고 생각해, 모르는 내용을 얼버무리거나 지나치게 긴 설명으로 돌려 말했습니다. 한번은 질문의 의도를 제대로 듣지 않고 제가 알고 있는 다른 문제를 설명하다가 동료에게 다시 질문을 부탁한 일도 있습니다. 그 후부터는 질문을 들으면 먼저 “질문하신 내용은 현재 방식에서 특정 조건의 문제가 생기는지에 대한 것으로 이해했습니다”라고 짧게 정리합니다. 잘 모르는 내용에는 “지금 정확한 수치는 확인하지 못했지만, 확인해서 공유하겠습니다”라고 말합니다. 모른다는 사실보다 모르는 것을 아는 척하는 태도가 신뢰를 더 크게 깎는다는 점을 배웠습니다.

혼자 하는 연습보다 실제 상황에 가까운 연습

거울 앞에서 발표하는 연습은 말의 속도를 확인하는 데는 도움이 됐지만, 실제 긴장까지 재현하지는 못했습니다. 그래서 저는 휴대전화로 발표를 녹음하거나 동료 한 명에게 먼저 설명합니다. 녹음 파일을 처음 들었을 때는 문장 끝을 흐리는 습관과 “그러니까”, “약간” 같은 말을 지나치게 반복하는 모습이 꽤 선명하게 드러났습니다. 처음에는 제 목소리를 듣는 일이 어색했지만, 한 번에 모든 문제를 고치려 하지 않고 매번 한 가지씩 줄였습니다. 지난 발표에서는 불필요한 추임새를 줄이는 데 집중했고, 다음 발표에서는 화면을 보느라 청중과 시선을 끊는 습관을 고쳤습니다. 작게 고친 습관이 쌓이면서 발표에 대한 막연한 공포도 구체적인 과제로 바뀌었습니다.

발표는 실력을 증명하는 자리가 아니라 연결하는 자리

돌이켜보면 저는 발표를 평가받는 시험처럼 여겼습니다. 한 번의 말실수나 질문에 대한 부족한 답변이 제 실력 전체를 보여준다고 걱정했습니다. 하지만 발표를 여러 번 경험하면서 사람들은 발표자의 완벽함보다 내용이 자신에게 어떤 의미인지, 그리고 질문을 진지하게 받아들이는지를 더 오래 기억한다는 사실을 알게 됐습니다. 발표가 끝난 뒤 누군가 제 설명을 바탕으로 더 나은 질문을 하거나, 다른 팀의 업무와 연결되는 의견을 내놓을 때 발표의 목적이 비로소 달성됐다고 느낍니다. 아직도 무대에 오르기 전 손에 땀이 나고 목소리가 떨리지만, 그 긴장이 제가 준비했다는 증거일 수도 있다고 받아들입니다. 발표가 두려운 개발자라면 온전한 발표자를 목표로 하기보다, 오늘 전하고 싶은 한 가지를 분명히 말하는 데서 시작해도 충분합니다.