발표 주제를 적으라고 하면 기술 이름부터 떠오른다. 새 프레임워크, 최근에 배운 기능, 재미있게 만든 도구가 있다. 이야기할 것은 많다. 그런데 그 이름만 보고 청중이 어떤 시간을 보내게 될지 상상하기는 어렵다. 발표자가 알고 있는 것과 청중이 가져갈 수 있는 것 사이에는 제안서 한 장만큼의 간격이 있다.
Sylwia Laskowska는 기술 컨퍼런스 발표 경험을 다룬 글에서 제안서, 준비, 이동과 부담을 함께 이야기한다. 2026년 10월 21일에 공개한 개인적 경험이며, 모든 행사의 선발이나 보상 방식이 같다는 근거는 아니다. 여기서는 그 경험을 내 이야기로 바꾸지 않고, 첫 발표 제안을 쓰는 가상의 예시를 만들어보려 한다.
기술 소개에서 한 장면으로
가상의 발표자가 작은 팀에서 보고서 작업을 자동화하는 주제를 고른다고 하자. 처음 제목은 파이썬으로 자동화 시작하기다. 틀린 제목은 아니지만 범위가 넓다. 어떤 사람이 어떤 문제를 해결하는지 보이지 않는다. 제목을 바꾸기 전에 청중이 발표를 듣기 전과 뒤에 무엇을 다르게 할 수 있어야 하는지 적어볼 수 있다.
예를 들어 대상은 매주 여러 CSV를 합치는 사람이고, 반복되는 문제는 열 이름이 조금씩 달라 작업이 멈추는 상황이라고 정한다. 발표 뒤에는 파일을 합치기 전에 입력 형식을 확인하는 작은 절차를 설계할 수 있게 한다. 그러면 다룰 기술을 모두 나열하지 않아도 중심이 생긴다. 도구는 그 장면을 설명하는 데 필요한 만큼 들어간다.
이 제안의 가상 제목은 CSV를 합치기 전에, 다른 열 이름을 발견하는 작은 검사 정도로 쓸 수 있다. 제목을 더 화려하게 만드는 대신 어느 실패를 다루는지 보이게 한다. 초록 첫 문장에는 대상과 장면을 넣고, 이어서 보여줄 예제와 가져갈 자료를 설명한다. 실제로 만든 자료가 없다면 배포하겠다고 미리 약속하지 않는다.
제안서에는 하지 않을 일도 자연스럽게 들어갈 수 있다. 이 발표에서는 대규모 데이터 처리나 운영 서비스 배포를 다루지 않는다고 적는 식이다. 청중에게 도움이 되는 경계다. 더 많은 주제를 넣어 폭넓어 보이게 하는 것보다, 정해진 시간에 끝낼 수 있는 약속을 고르는 편이 발표의 모양을 분명하게 만든다.
스무 분을 채우는 대신 나누기
설명을 위한 가상 발표 시간은 스무 분으로 잡아보자. 처음 몇 분에는 실제 문제를 이해할 수 있는 입력 자료를 보여준다. 중간에는 열 이름이 다른 파일을 그대로 합쳤을 때의 차이와 사전 검사 과정을 보여준다. 마지막에는 자신의 작업에 옮길 때 확인할 항목을 정리한다. 이 시간 배분은 성공이 검증된 공식이 아니라 초안을 점검하기 위한 틀이다.
리허설에서는 말한 분량만 재면 부족할 수 있다. 화면 전환과 예제 실행, 잠깐의 기다림도 시간에 들어간다. 질문을 받는 방식도 행사마다 다르니 실제 안내를 확인해야 한다. 아직 정해지지 않은 운영 조건은 제안서 단계의 가정과 분리해두면 된다. 모든 발표가 같은 길이와 장비를 제공한다고 생각하지 않는 것이다.
데모가 실패했을 때 보여줄 자료도 준비 계획에 넣을 수 있다. 여기서 중요한 것은 실패를 성공인 것처럼 꾸미는 일이 아니다. 실시간 실행이 막혔다고 알리고, 미리 저장한 입력과 예상 결과를 통해 설명을 이어갈 수 있게 하는 것이다. 녹화나 캡처를 사용할 경우에도 현재 실행과 구분해 소개해야 한다.
작은 예제가 익숙해지면 자료를 더 넣고 싶어진다. 그때에는 추가 내용이 청중의 다음 행동에 필요한지 물어볼 만하다. 다른 라이브러리를 비교하는 이야기가 흥미로워도, 이번 약속이 입력 검사를 설계하는 것이라면 세부 비교는 후속 글로 남길 수 있다. 빠진 지식의 양보다 남은 이야기의 연결이 중요하다.
발표를 고르는 사람의 질문
제안서를 읽는 사람은 작성자의 열정을 직접 볼 수 없다. 대상이 누구인지, 왜 지금 필요한지, 어떤 예제로 보여줄지 적힌 문장으로 판단해야 한다. 가상의 예시에서는 반복 작업을 가진 초급 개발자, CSV 열 이름 불일치, 실패를 발견하는 사전 검사가 그 답이 된다. 세 문장이 서로 맞물리는지 읽어보면 제안의 빈틈을 찾을 수 있다.
경험을 소개할 때에는 실제로 한 일만 적어야 한다. 아직 팀에서 사용하지 않은 예제라면 학습용 예제라고 말하면 된다. 동료가 겪은 문제를 허락 없이 자기 경험으로 쓰거나, 수치를 붙여 더 설득력 있게 보일 필요는 없다. 작게 확인한 사실을 정확하게 설명하는 것 자체가 발표자의 신뢰와 연결된다.
행사에 참여할지 결정하는 일도 별도의 작업이다. 제출 마감, 녹화 공개 조건, 이동과 비용 안내를 실제 행사 페이지에서 확인해야 한다. 누군가의 경험담만으로 지원이나 보상을 예상하면 준비를 마친 뒤 다른 부담을 발견할 수 있다. 이 글은 특정 행사를 추천하거나 신청을 대신하는 안내가 아니며, 실제 제출 전에는 해당 조건을 확인해야 한다.
첫 발표를 준비하는 일은 지식을 전부 정리하는 시험처럼 느껴질 수 있다. 하지만 제안서의 첫 문장은 조금 더 작아도 좋겠다. 누가 어떤 장면에서 막히고, 이 시간을 보낸 뒤 무엇을 해볼 수 있는가. 그 질문에 답이 생기면 도구 이름도 제자리를 찾는다. 지금 적어둔 발표 제목 아래에는 청중의 다음 행동이 한 문장으로 보이는가.
관련 글은 개발자에 대한 생각에서 이어 읽을 수 있습니다.
공개 원문을 참고해 AI의 도움으로 구성·작성한 글입니다. 본문의 가상 예시는 실제 수행 결과와 구분했으며, 표지는 Google Gemini로 만든 개념 일러스트입니다.
