35  콘퍼런스 CFP

컨퍼런스에서 연사를 모집할 때는 두 가지 방법이 있습니다. 잘 알려진 연사를 초청하거나, 그 밖의 모든 연사를 대상으로 선발 절차를 여는 것입니다. 새내기 연사라면 발표 기회는 대부분 후자의 절차를 통해 얻게 되며, 이 절차를 Call for Papers(CFP)라고 부릅니다.

이름에 속지 마십시오. 채택되기 위해 논문을 쓸 필요는 없습니다! 이 용어는 직접 작업한 논문을 제출하던 학술 콘퍼런스에서 유래한 것입니다. 하지만 다른 공통점도 있습니다. 제목과 초록을 갖춘 발표 제안을 하나 이상 보내면, 심사 위원회가 모든 제출물을 검토하여 발표 라인업을 구성합니다. 이 과정은 보통 3~6개월 전에 이루어지므로, 발표가 채택되면 발표를 준비할 시간이 있습니다.

발표는 여러분에게 많은 기회의 문을 열어 줄 수 있습니다. 직업적 인맥을 쌓는 일부터 고용주에게 자신을 알리는 일, 모두에게 알리고 싶은 멋진 아이디어나 라이브러리를 홍보하는 일까지 가능합니다. 누구나 발표에 도전해 보아야 합니다. 배운 것을 가르치고 의사소통 능력을 키울 수 있기 때문입니다.

“지난 5년간 제 커리어에 가장 큰 도움이 된 것은 Facebook에서 일한 것도, 매니저가 된 것도 아니었습니다. 바로 대중 연설 능력을 키운 것이었습니다.” - Charity Majors

그러나 밋업이나 사내 런치 앤 런(lunch-and-learn)을 넘어 본격적인 개발자 콘퍼런스로 나아가면 발표 기회를 얻기가 급격히 어려워집니다. 이 장은 여러분이 시작할 수 있도록 훌륭한 CFP를 작성하는 것을 돕는 데 초점을 맞춥니다. 실제 발표 조언은 이후의 장에서 다루겠습니다.

35.1 제가 무슨 자격으로 조언을 드리겠습니까?

저는 노련한 세계적 수준의 발표자가 아닙니다. 널리 쓰이는 라이브러리나 프레임워크를 메인테이닝하고 있지도 않습니다. 저는 2018년 1월에 첫 개발 직장에 들어갔습니다. 첫 밋업 발표는 2017년 12월이었습니다. 첫 콘퍼런스 발표는 2018년 8월이었습니다. 그 후 1년 반 동안 저는 약 250명 규모의 지역 커뮤니티 콘퍼런스부터 약 4천 명 규모의 더 큰 콘퍼런스까지 20개가 넘는 행사에서 발표했고, 해외로는 영국, 스웨덴, 인도에서 발표했으며 싱가포르와 하와이에서 열린 두 번의 JSConf에서도 발표했습니다.

이 이야기를 하는 것은 자랑하려는 것이 아니라, 제가 해 온 것과 아직 해 보지 못한 것(예를 들어 사회자를 맡거나 더 “권위 있는” 콘퍼런스에 초청받는 일)을 분명히 해 두려는 것일 뿐입니다. 제가 확실히 B급이나 C급 명단에 속한다는 것을 잘 알고 있습니다. 콘퍼런스 초청을 몇 번 받기도 해서 그만큼 CFP 과정에서 조금 자유로운 편이지만, 대부분은 여전히 그 과정을 거쳐야 합니다. 여러분이 초보자라면, 그래서 제 조언이 좀 더 와닿기를 바랍니다.

35.2 발표를 많이 보십시오

발표와 CFP, 그리고 콘퍼런스의 세계에는 그 나름의 특별한 언어가 있습니다. 그리고 다른 모든 언어와 마찬가지로, 몰입할 때 가장 잘 배울 수 있습니다.

제 YouTube 나중에 볼 동영상 목록에는 400개가 넘는 영상이 있습니다. 점심을 먹거나 심심할 때면 영상을 하나 틀어 발표를 봅니다. 대부분의 콘퍼런스는 발표 제목과 초록을 그대로 복사해 영상에 붙여 넣습니다. 곧 여러분도 그런 글을 쓰게 될 테니, 이제부터 그것들을 눈여겨보십시오. 발표를 보다 보면 YouTube 알고리즘도 학습되어 오락 영상 대신 발표 영상을 추천하기 시작하는데, 이는 제가 할 일을 미룰 때 좋은 자극이 됩니다.

Hacker News에서 더 많은 훌륭한 강연 목록을 찾을 수 있습니다.

35.3 밋업에서 발표하기

아직 밋업에서 발표해 본 적이 없다면, 콘퍼런스에서 발표하기 전에 밋업에서 두어 번 발표해 보기를 강력히 권합니다. 밋업은 발표에 대한 긴장을 떨쳐 내고, 사용하려는 발표 도구를 손에 익히고, 반려견이 아닌 사람들 앞에서 발표 내용을 시험해 볼 수 있는 최고의 기회입니다. 한편으로 밋업 주최자들은 늘 발표자를 찾고 있으므로, 여러분이 발표하면 그들에게도 도움이 됩니다. GitNation 같은 일부 밋업 주최자는 미래의 콘퍼런스 발표자를 발굴하는 데 밋업을 적극적으로 활용하므로, 밋업에서 한 발표를 계기로 콘퍼런스 발표자로 눈에 띌 수도 있습니다.

35.4 콘퍼런스 고르기

콘퍼런스를 알면 청중도 대략 알 수 있습니다. 처음 발표하는 사람들은 흔히 발표 자체를 목표로 삼지만, 발표자는 청중과 콘퍼런스 주최 측의 목표에 기여하기 위해 그 자리에 있다는 사실을 잊곤 합니다. 따라서 콘퍼런스와 청중을 잘 이해할수록 채택될 가능성도 높아집니다.

커뮤니티 목록을 통해 컨퍼런스를 찾을 수 있습니다:

콘퍼런스가 처음이라면 “게임의 규칙”이 꽤 불투명하게 느껴질 수 있으므로, 기본적이고 일반적인 사실 몇 가지를 소개합니다(콘퍼런스마다 예외는 있습니다!):

  • 컨퍼런스 주최 측이 원하는 것은 대략 우선순위대로 티켓을 판매하는 것, 훌륭한 콘텐츠 구성을 갖추는 것, 그리고 내년 티켓을 판매하는 것입니다. 연사 선정은 이러한 목표를 달성하는 데 있어 중요한 부분을 차지합니다.
  • 다행히도 여러분이 객석을 채울 필요는 없습니다. 그 일은 주최 측이 더 유명한 연사를 초청해 해결할 것입니다. 이 점이 중요합니다. 그들이 하는 방식을 따라 하지 마십시오. 아직은 아닙니다. 그들은 다른 게임을 하고 있으며, 발표나 초록의 구체적인 세부 내용은 덜 중요합니다. 여러분은 아직 그런 자격을 얻지 못했습니다.
  • 따라서 여러분이 할 일은 주최 측의 콘텐츠 선정에 한몫을 하는 것입니다. 이 선정은 컨퍼런스의 대상 청중에 따라 결정됩니다. 자리를 잡은 컨퍼런스일수록 티켓 판매가 보장되어 있으므로 “좋은 선정”을 더욱 중요하게 여깁니다.
  • 커뮤니티 콘퍼런스는 대개 특정 프레임워크나 언어에 초점을 맞춥니다. 예를 들어, JSConf는 정말 매우 다양한 주제를 다룹니다. 심지어 JS를 쓰거나 웹 프로그래밍을 하지 않아도 됩니다. JSConf에는 언제나 임베디드 JS 발표나 크리에이티브 코딩 발표, 또 다른 크리에이티브 코딩 발표, 또 또 다른 크리에이티브 코딩 발표를 위한 자리가 있습니다.
  • 기업 후원 컨퍼런스는 특정 회사의 제품을 사용하지 않더라도 참여할 수 있도록 어떤 아이디어나 흐름을 중심으로 열리는 경우가 많습니다. 예를 들어 Netlify는 JAMstackConf를 후원하지만, Netlify를 꼭 사용하거나 Netlify에 대해 이야기하지 않는 연사도 초청합니다. 이렇게 말하면 이해가 되실지 모르겠지만, 다루는 범위가 조금 더 좁고 “수평적”이라기보다는 “수직적”입니다.
  • 컨퍼런스의 발표자 자리는 한정되어 있습니다. 경험적으로 트랙당 하루에 8~12명의 발표자가 적당합니다(일부 정규 발표자 자리를 포기하면 라이트닝 토크 발표자를 더 많이 둘 수 있습니다). 따라서 사흘간 진행되는 단일 트랙 컨퍼런스에서는 발표가 최대 36개입니다. 컨퍼런스 지원자 수는 평균 200명에서 JSConf의 경우 800~1200명 정도까지 다양합니다. (초청제로만 운영되는 컨퍼런스도 있습니다). 이러한 변수에 따라 여러분의 확률은 낮아지기도 하고 높아지기도 합니다. 선정 과정이 얼마나 엄청나게 까다로운지 알고 나면 탈락해도 그렇게까지 쓰라리지는 않습니다. 사실상 대학 입시만큼이나 결과를 예측할 수 없습니다.
  • 하지만 앞서 구성의 다양성이 중요하다는 점을 확인했으므로, 여기에는 그 안에서 벌어지는 하위 게임이 있습니다. CFP 지원자의 70%가 React를 쓰더라도, JSConf는 갑자기 발표의 70%를 React로 채우고 싶어 하지 않습니다. 그래서 CFP는 명시적으로든 무의식적으로든 여러 분류로 나뉩니다. React CFP는 다른 React CFP와 그 장점을 놓고 비교됩니다. 그리고 경쟁이 덜 치열한 분류도 일부 있기 마련입니다. 다시 말하지만, 이것이 명시적인 방침은 아닐 수 있어도 어쨌든 실제로 일어납니다. 심사자들의 주관적인 관점에서 “좋은 구성”이 그만큼 중요하기 때문입니다.
  • 대부분의 컨퍼런스는 (다시 말하지만, 분명한 예외는 있습니다) 분야별로 무명보다 유명인을 선택합니다. 예를 들어, Sarah Drasner와 제가 둘 다 Vue나 디자인, SVG 애니메이션에 관한 CFP를 제출한다면, 저 대신 그녀를 선택하지 않는 것은 어리석은 일일 것입니다. 하지만 이런 일이 모든 발표에서 일어난다면, 무대에는 새로운 얼굴이 결코 등장하지 않을 것이고, 다음 세대 발표자를 길러 낼 통로도 없을 것입니다. 무명인 정도가 같다면, 소속 회사도 고려 대상이 됩니다. 이것이 바로 어느 정도의 공정성과 뜻밖의 발견, 그리고 새로움을 위해 “블라인드” CFP 심사가 중요한 이유입니다. 제 경험상, 대부분의 CFP는 블라인드가 *아닙니다*. 주된 이유는 대부분의 컨퍼런스에게는 객석을 채우는 일이 더 중요하기 때문입니다.

지금까지 다룬 내용을 정리하면 다음과 같습니다. 처음 발표하는 사람이라면, “블라인드” CFP 심사 과정을 약속한 멀티 트랙, 다일 일정의 컨퍼런스에 자신이 잘 아는 프레임워크나 언어, 아키텍처를 주제로 지원하는 것이 가장 좋은 기회입니다. 선택할 수 있다면, 경쟁이 덜 치열한 주제로 발표하는 편이 더 승산이 있을 수 있습니다.

특히 모든 발표의 고품질 영상을 공개하는 콘퍼런스를 찾아보십시오. 여기에는 두 가지 목적이 있습니다. 첫 발표가 맡은 역할 중 하나는 다음 발표를 위한 명함이 되는 것입니다. 훌륭한 발표 하나만으로도 멋진 연사 경력을 시작할 수 있습니다. 둘째로, 해당 콘퍼런스에서 이전에 채택된 발표들의 정확한 성격과 분위기를 파악할 수 있으므로, 자신의 발표를 제안할 때와 그 발표를 준비할 때 조사하기가 훨씬 쉬워집니다.

35.5 주제 정하기

이제 대상 청중을 알게 되었으니, 제목이나 초록을 쓰기 시작하기도 전에 정리해야 할 것이 두 가지 있습니다.

먼저 주제를 찾아야 합니다. 가장 단순하게 말하면, 이는 여러분이 매우 관심 있는 것과 다른 모든 사람이 관심 있는 것 사이의 교집합을 찾는 일입니다. 장 18에서 다룬 관심의 접점(Nexus of Interest)은 이미 익숙하실 것입니다. 이렇게 관심도에 차이를 두는 이유는 간단합니다. 여러분은 청중보다 이 주제에 훨씬 더 많은 시간을 쏟게 되겠지만, 그래도 청중이 찾아와 주어야 하기 때문입니다(더 정확히 말하면, CFP 심사위원에게서 높은 점수를 받아야 하기 때문입니다).

이 교집합은 막막하게 느껴지거나, 반대로 너무 넓어서 쓸모없게 느껴질 수도 있습니다.

  • 막막하게 느껴진다면: 어떤 주제로 발표하기 위해 그 주제에 대한 실무 경험이 많을 필요는 없습니다. 그 프레임워크나 라이브러리를 만든 사람일 필요도 없습니다. 내부 구조를 이해할 필요도 없습니다. 여러분이 특정 주제에 청중보다 더 많은 시간을 들였을 가능성이 높다면, 청중은 여러분에게서 배울 것이 있습니다. 어느 정도는 “미래를 담보로 잡는” 것도 가능합니다. 배우고 싶은 주제를 아직 배우기 전에 발표로 제안하고, 발표 채택을 인위적인 마감 기한으로 삼는 것입니다. 항상 이렇게 하라고 권하지는 않지만, 이 방법이 잘 통하는 것을 본 적이 있습니다.
  • 너무 광범위해서 쓸모없다고 느껴진다면: 전체적으로 보면 많은 사람들의 관심사는 예측 가능하다는 점을 이해하십시오. 사람들은 언제나 앞으로 무슨 일이 일어날지 알고 싶어 합니다. 사람들은 언제나 인기 있는 무언가에 대한 포괄적인 입문을 원합니다. 사람들은 언제나 앞으로 해야 할 가능성이 높은 일에 대해, 그 일을 성공적으로 겪어 본 사람들의 실제 “경험담”을 원합니다. 개발자들은 언제나 디자이너가 아니어도 디자인 요소를 손쉽게 더하는 방법을 원합니다. 디자이너들은 그 반대입니다. 아이디어가 필요하다면, 여러분의 경험 중 어떤 것이 화제가 되는 주제와 겹치는지 생각해 보십시오. 접근성, 자동화, AI, 디자인 시스템, 노코드, GraphQL, 서버리스, 서비스 디스커버리, 코드형 인프라(Infrastructure as Code) 같은 것들입니다. 모든 사람은 같은 불안을 가지고 있으며, 어떤 면에서 여러분은 그들의 불안을 해소해 주기 위해 그 자리에 있는 것입니다. 컨퍼런스 주최자들은 다른 컨퍼런스에서 영감을 얻으며, 여러분도 그렇게 해야 합니다.

여기서 아주 분명히 해 두겠습니다. 이 전략은 필요할 때만 쓰십시오. 화제가 되지 않는 기술에 대해 발표하는 것도 전혀 문제없습니다. 하지만 사람들은 정말로 유행어에 반응합니다!

다른 사람들의 관심사를 가늠하는 믿을 만한 방법은 커뮤니티 사람들이 모여드는 곳을 살펴보는 것입니다. Hacker News, 트위터, Reddit에서 어떤 주제가 계속 거론됩니까? 거대 커뮤니티에서 업계 커뮤니티로 범위를 좁혀 갈 수도 있습니다. 웹 개발이라면 Dev.to, CSS Tricks, Smashing Magazine 같은 사이트가 여기에 해당합니다. 가장 활발한 GitHub 저장소는 무엇입니까? 패키지 다운로드의 메가트렌드는 무엇입니까? 프레임워크와 라이브러리의 코어 팀 멤버들은 무엇을 내놓고 있습니까? 기업의 리더들(여러분이 다니는 회사의 리더든, 뉴스에 등장하는 유명한 리더든)은 어떤 흥미로운 일을 하고 있습니까? 하지만 사람들은 때때로 직접 보기 전까지는 자신이 무엇을 원하는지 모른다는 점을 알아 두십시오.

더 많이 만들어 보면 상대적인 관심도와 여러분 자신의 관심도도 가늠할 수 있습니다. 블로그 글을 더 많이 쓰고 어떤 글이 유난히 큰 반응을 얻는지 살펴보십시오. 트위터, HN, Reddit은 관심도를 가늠할 수 있는 훌륭한 피드백 수단입니다. 발표의 MVP는 블로그 글입니다.

글을 잘 쓰지 못해도 괜찮습니다. 데모를 만들 수도 있습니다. Diana Smith는 CSS 아트로 커리어를 쌓았고, 저는 그녀의 블로그 글을 한 번도 읽어 본 적이 없습니다. 그녀는 어디서든 발표자로 선정될 것이라고 장담할 수 있습니다(실제로 발표한 적이 있는 것으로 꽤 확신하지만, 지금 당장은 찾을 수가 없습니다). 여러분의 YouTube 시청 기록과 GitHub 타임라인 역시 여러분의 드러난 관심사를 보여 주는 훌륭한 지표입니다.

비기술적인 발표에 대해 특별히 한마디 하겠습니다. 저는 이런 발표를 무척 좋아합니다. 컨퍼런스 주최 측은 그렇지 않습니다. 커리어 관리, 가면 증후군, 연봉 협상, 원격 근무, 공개적으로 배우기(장 9)에 관한 조언은 어떻습니까? 이런 발표는 훌륭하며, 여러분이 선택하는 그 어떤 기술보다도 오래갑니다. 컨퍼런스에는 이런 발표가 더 많아야 합니다. 하지만 그렇지 않습니다.

현실적으로 말하면, 콘퍼런스의 최종 고객은 콘퍼런스에 참석하는 사람들의 상사입니다. 상사들은 직원을 보낸 데 대해 “이건 업무에 써먹을 수 있겠다” 싶은 투자 수익을 확인하고 싶어 합니다. 대부분의 상사는 기술 중심의 콘퍼런스에 사람을 보내는 쪽이 정당화하기 더 쉽다고 여기며, 그래서 기술 발표에 대한 수요가 더 많습니다. 덜 냉소적으로 말하자면, 투자 수익을 측정하고 거두는 데 걸리는 기간(2~3년, 수요가 많은 기술직 종사자의 전형적인 재직 기간)이 무엇에 투자할지를 좌우합니다.

미션 중심 회사, 예를 들어 비영리 단체나 정부 기관, 학교 시스템, 박물관 같은 곳에서 일한다면, 여러분의 사회적 영향을 발표에 어떻게 녹여 낼 수 있을지 꼭 살펴보십시오. 우리 대부분은 하루 종일 SaaS 앱과 마케팅 페이지를 만드는 데 시간을 보내기 때문에, 개발자들은 자신의 기술이 “현실 세계”에 어떻게 닿는지에 대한 영감을 늘 더 찾고 있습니다.

35.6 장르를 고르십시오

주제를 정했다면, CFP 제목과 초록을 좌우할 발표 장르가 여러 가지 있습니다. 물론 특정 장르를 고수하지 않거나 잘 알려진 장르를 비틀 수도 있지만, CFP라는 제약 안에서는 그냥 하나의 장르 안에 머무르는 편이 더 쉬운 경우가 많습니다. 시작하는 데 도움이 되도록 흔히 쓰이는 장르 10가지를 소개합니다. 이것이 전부는 아닙니다:

  • 경험담(War Story): 실무 경험이 어느 정도 있는 사람에게 첫 발표 장르로 아주 좋습니다. 직장에서 겪은 일을 이야기하기만 하면 됩니다. 좌절, 얻은 교훈, 그리고 특히 정량적으로 얻은 이점을 함께 담으십시오. 자신이 처한 구체적인 상황 말고는 어떤 분야에서도 세계 최고의 전문가일 필요가 없습니다. AirBnb처럼 이름난 곳에서 일한다면 대개 도움이 되지만, Millie Macdonald가 그랬듯이 이야기의 흥미로운 요소를 잘 내세운다면 덜 알려진 곳이어도 괜찮습니다.
  • 라이브러리/프레임워크/제품 출시: 콘퍼런스 주최 측은 무언가 큰일의 시작에 함께하고 싶어 합니다. 이 장르의 발표를 잘하려면 중요한 문제를 다루어야 하고, 그 문제에 대한 좋은 해결책을 개발했다는 생각을 설득력 있게 전달해야 합니다. 아직 완성하지 않았어도 괜찮지만, 물론 완성했다면 도움이 됩니다. 예시: Dan Abramov, Ryan Dahl
  • X 하는 법: GraphQL에서 오류 처리하는 법. Vue에서 입력 마스킹하는 법. 정적 사이트를 동적으로 만드는 법. 웹 A/V 아티스트가 되는 법. 공을 튀기는 14가지 방법. 감이 오실 것입니다!
  • X 입문: 밋업에서는 쉽게 다룰 수 있는 소재이지만, 콘퍼런스에서는 주목받기가 더 어렵습니다. 대개 콘퍼런스 주최 측이 문서나 README에 있어도 그만인 발표를 채택했다는 인상을 주고 싶어 하지 않기 때문입니다. 그러므로 좋은 X 입문 발표라면 구성과 제목도 창의적으로 정해야 합니다. 최근에 본 사례로 Louisa Barret의 색채 이론 입문 발표가 있는데, 제목은 그렇지 않았습니다. 제목은 닌자 거북이와 함께하는 색채 이론 가이드였습니다. 속성으로 배우는 TypeScript 입문처럼 단어 하나만 더해도 됩니다. 어떻게 하는 것인지 감이 오십니까?
  • What’s New in X: 새로 나온 것들을 있는 그대로 훑어보는 유형입니다. “State of X”라는 형식으로 꾸려지는 경우도 많습니다. 이런 종류의 발표를 하려면 Mark Erikson이나 Ben Ilegbodu, Sarah Drasner, Evan You처럼 어느 정도 자리를 잡은 사람이어야 하는 경우가 많습니다. 하지만 아주 유명하지 않더라도 Sacha Greif처럼 데이터를 가져오거나, Tara Manicsic처럼 그냥 재미있게 설명하는 방법도 있습니다.
  • 기초: 입문자에게 아주 좋은 장르입니다(입문자만을 위한 장르라는 뜻은 아닙니다). 알고리즘, 자료 구조, 상태 기계, 코루틴 같은 CS 기초는 누구나 알고 “있어야 하는” 지루한 것들을 더 친숙하고 최신의 맥락에서 재해석해 주기 때문에 언제나 사랑받습니다. 하지만 이 장르의 이름을 더 넓게 붙인 이유는 JS 이벤트 루프, 시각 디자인, 게임 프로그래밍 기법처럼 가르칠 만한 다른 기초도 떠올릴 수 있기 때문입니다.
  • 라이브 코딩: 많은 사람에게 부담스러운 장르입니다. 실수 하나로 발표가 만족스러운 결말 없이 엉망이 될 수 있기 때문입니다. 하지만 이런 “줄타기 묘기”는 청중을 매료시킵니다. 곡예사가 목숨을 건 묘기를 펼치는 모습을 즐겨 보는 것과 같은 이유입니다. 그들이 충분히 연습했다는 것을 알지만, 여전히 큰 사고가 날 위험은 있습니다. 동작하는 코드가 시간에 따라 만들어지는 모습을 지켜볼 수 있으면, 시연하는 도구나 개념에 대해 아주 큰 확신을 갖게 됩니다. 덜 알려진 장점 두 가지는 발표 도구로서의 IDE가 주는 익숙함과, 서두르지 않게 해 주는 자연스러운 안전장치입니다(저처럼 처음 발표하는 사람은 긴장을 숨기려고 말을 너무 빨리 하는 실수를 저질러 청중을 놓칠 위험이 있습니다). 제 최고의 발표는 라이브 코딩 발표이며, 저는 이 장르에 대한 관심이 높아지고 있다고 생각합니다. SmashingConf는 현재 100% 라이브 코딩으로 진행되는 콘퍼런스를 열고 있으며, React Live도 100% 라이브 코딩으로 진행됩니다.
  • 이단 발표: 마음이 약한 분께는 절대 권하지 않습니다. 이단 발표를 하려면 >80%의 사람들이 기술 X를 사랑하는 콘퍼런스에 가서, 기술 X가 왜 (아직) 충분히 좋지 않은지 말하거나 팬들이 그 기술을 과대 포장할 때 쓰는 상투적인 주장에 의문을 제기해야 합니다. DockerCon에서 발표된 Corey Quinn의 Heresy in the Church of Docker나 GraphQL Asia에서 발표된 Robert Zhu의 The Case Against GraphQL을 참고하십시오. 장점은 그렇게 실컷 깎아내리는 만큼 관심을 받는 것이 보장된다는 점입니다. 단점은 자신의 주장에 확신이 있어야 하며, 그렇지 않다면 갈기갈기 찢길 각오를 해야 한다는 점입니다.
  • 교차점 발표: 이는 분명 주제 선정에 뒤따르는 문제이지만, 대개 X에 관심이 있으면서 Y에도 관심이 있는 사람들은 X + Y를 다루는 발표를 충분히 접하지 못합니다. 주제의 교차점은 무한히 많아서 일일이 열거할 수 없지만, 교차점을 생각할 때 떠오르는 뻔한 팁과 요령, 메모를 그냥 이야기하면 됩니다.
  • 성능 발표: 속도광에게 아주 좋은 장르입니다. 흔한 사용 사례 하나를 골라 비효율적이고 높은 수치에서 시작한 다음, 기법을 하나씩 차례로 적용하며 그 수치를 깎아 내려가십시오. Jake와 Surma가 앱의 TTI를 6초에서 1초로 줄인 사례와 Sasha Aickin이 React SSR을 1025ms에서 5ms로 줄인 사례가 그 예입니다.

35.7 제목 정하기

제목은 초록보다 두 배 더 중요합니다. CFP 심사위원은 제목과 초록을 모두 살펴봅니다. 하지만 컨퍼런스 참석자는 대개 제목만 봅니다. 특히 여러 트랙으로 진행되는 컨퍼런스에서는 대부분 발표 제목만 인쇄할 공간밖에 없으며, 이 제목이 발표장이 텅 빌지, 아니면 서서 들어야 할 만큼 꽉 찰지를 가르는 결정적인 요인이 되는 경우가 많습니다(실제 경험으로 알게 된 사실입니다).

하지만 부담 갖지 마십시오. 채택된 후에도 제목은 얼마든지 다듬을 수 있습니다.

장르가 제목을 어느 정도 정해 준다면 그대로 따르십시오. (장르별 제목 예시는 모두 위의 장르 섹션에 정리해 두었습니다)

Never Write Another HoC처럼 핵심 메시지를 압축해 담은 기억에 남는 이름을 떠올릴 수 있다면, 그렇게 하십시오. 발표가 좋으면 그 제목이 놀라울 만큼 자주 여러분에게 다시 인용되어 돌아올 것이므로, 두고두고 들어도 괜찮을 제목으로 정하십시오.

예시:

창의적이고 눈길을 끄는 제목을 짓는 것이 도움이 됩니다. CFP 심사위원들은 대개 구글 시트나 표에서 수백 개의 CFP를 훑어보게 된다는 점을 기억하십시오. 짧은 제목은 눈에 띕니다. 특별한 유행어도 눈에 띕니다. 다시 말하지만, 예전에 공개된 콘퍼런스 일정을 훑어보며 어떤 제목이 효과적인지 감을 잡으십시오.

위의 어느 것도 맞지 않는다면 억지로 짜내지 마십시오. 시연할 주요 기술을 다루는, 생각할 수 있는 가장 평범하고 실용적인 제목을 붙이십시오. 때로는 꾸밈없고 단순한 것이 가장 좋습니다!

35.8 초록 작성하기

장르와 제목을 정하고 나면 초록은 거의 저절로 써집니다. 하고 싶은 발표의 개요를 대략 잡아 보십시오. 도움이 된다면 발표에서 하고 싶은 것을 모두 글머리 기호로 나열하고, 요점을 묶고 정렬한 다음, 그것을 초록을 위한 브레인스토밍 재료로 활용할 수 있습니다. 발표 내용을 전부 드러내지는 말고, 흥미를 불러일으킬 만큼만 보여 주십시오.

대부분의 콘퍼런스는 초록만 요구하지만, 일부 콘퍼런스는 왜 여러분이 이 주제를 발표하기에 가장 적합한 사람인지에 대한 추가 설명을 적을 공간을 마련해 둡니다(보통 선택 사항이지만, 꼭 활용하십시오!!!).

초록의 첫 문단이 가장 중요합니다. 인쇄되어 배포되고 YouTube 설명란에도 쓰이는 부분이기 때문입니다. 대부분의 초록은 한 문단으로 이루어져 있습니다. 첫 문장은 주의를 끕니다. 마지막 문장은 승부를 결정짓습니다. 모든 글쓰기가 그렇듯, 글쓰기에 관한 Gary Provost의 변치 않는 조언이 여기에도 적용됩니다.

이 문장은 다섯 단어입니다. 여기 다섯 단어가 더 있습니다. 다섯 단어 문장도 괜찮습니다. 하지만 여럿이 모이면 단조로워집니다. 무슨 일이 일어나는지 들어 보십시오. 글이 지루해지고 있습니다. 소리가 웅웅거리기만 합니다. 고장 난 레코드판 같습니다. 귀는 변화를 원합니다. 이제 들어 보십시오. 저는 문장 길이에 변화를 주고, 음악을 만들어 냅니다. 음악입니다. 글이 노래합니다. 글에는 기분 좋은 리듬과 경쾌한 가락, 그리고 화음이 있습니다. 저는 짧은 문장을 씁니다. 그리고 중간 길이의 문장도 씁니다. 그리고 때로는, 독자가 충분히 쉬었다는 확신이 들 때, 상당히 긴 문장으로 독자를 사로잡을 것입니다. 에너지로 불타오르고 크레셴도의 모든 기세와 함께, 북의 울림과 심벌즈의 굉음과 함께 고조되는 문장, 곧 들어 보십시오, 이것은 중요합니다, 라고 말하는 소리들로 말입니다.

여러분의 발표에도 그렇게 하십시오. 가능하다면 단어를 더 적게 쓰십시오. 제 초록은 대부분 100단어 미만입니다.

초록은 시선을 사로잡는 데이터 포인트를 넣기에 좋은 곳입니다. JavaScript 사용자의 65%가 TypeScript를 도입했다는 사실을 알고 계셨습니까? 또는 개발자의 51%가 VSCode를 사용한다는 사실은 어떻습니까? 또는 “최근 JavaScript 코드 10만 줄을 TypeScript로 리팩터링했습니다”라는 이야기는 어떻습니까? 또는 제가 이 기묘한 비법 하나로 webpack 빌드 시간을 20% 단축했다는 이야기는 어떻습니까? 우리는 숫자에 약합니다.

대부분의 초록 제출 양식에서는 강조와 간단한 서식에 Markdown을 사용할 수 있습니다. 활용하십시오. 단, 절제해서.

발표 제목과 마찬가지로, 지원할 때 제출한 초록을 그대로 지켜야 하는 경우는 거의 없습니다. 아무도 칼을 들이대며 초록대로 발표하라고 감시하지 않습니다. 여러분에게는 내용을 바꿀 권리가 있습니다. 다만 너무 크게 바꾸거나 너무 막판에 바꾸지는 않기를 바랍니다. 이 권리를 자주 쓸 일은 없겠지만, 필요하다면 언제든 쓸 수 있습니다.

아무런 맥락 없이 개발자 친구 몇 명에게 초록을 보여 주십시오. 그들이 이해하지 못한다면, 그것은 문제입니다. 아마 여러분은 실제로 적어 둔 것보다 자신의 발표가 무엇인지 더 잘 알고 있을 것입니다. 찢어 버리고 다시 시도하십시오. 더 명확하게, 덜 추상적으로 쓰십시오. 그곳에 도달하는 구체적인 방법보다는 사람들이 여러분의 발표에서 무엇을 얻어 갈지에 호소하십시오(바로 그것이 사람들이 여러분의 발표를 들으러 와야 하는 이유입니다!).

35.9 CFP 프로세스 만들기

좋습니다, 이제 CFP를 하나 작성하셨습니다. 축하합니다! 아직 끝나지 않았습니다.

참고: 아래에서 제 과정을 설명하는 제가 CFP를 작성하는 방법에 관한 12분짜리 영상을 보실 수 있습니다.

아마 들어 보셨겠지만, 선별성과 무작위성 때문에 CFP 제출은 결국 확률 싸움입니다. 따라서 특정 CFP가 채택되는 것보다 지속 가능한 CFP 프로세스를 구축하는 것이 더 중요합니다. 여러분은 콘퍼런스당 2~5개의 CFP를 제출하게 될 것이며, 여러분에게 잘 맞는 콘퍼런스는 아마 매년 수십 개에 이를 것입니다.

의도치 않게 전업 CFP 작성자가 되는 일을 피하려면, 재사용할 수 있는 주제와 제목/초록 샘플을 모아 두는 것이 좋습니다. 저는 발표 준비 정도가 제각각인 주제를 5~10개쯤 가지고 다니는 편입니다(기억하십시오. 어떤 주제에 대해 이야기하기 위해 그 주제의 세계적인 전문가가 될 필요는 없습니다). 대규모 구직 활동에서 자기소개서를 다듬듯이, 각 제출물을 콘퍼런스의 대상 청중에 맞게 적절히 조정하십시오. 어떤 의미에서는 일자리, 적어도 단기 일거리를 찾고 있는 셈입니다.

좋은 사진을 하나 마련하고, 어디에서나 같은 사진을 사용하십시오. 사람들은 이름보다 얼굴을 더 빨리 알아봅니다.

짧은 자기소개를 작성해 두십시오. 계속해서 요청받게 될 것입니다. 인생 이야기를 늘어놓지 말고, 무슨 일을 하는지, 자신을 어떤 사람으로 규정하는지, 그리고 대체로 어떤 것에 관심이 있는지를 간단하게 적으십시오. 발표 경력이 쌓이면, 주최 측이 따로 묻지 않고 그대로 복사해 붙여 넣을 수 있도록 웹사이트에 짧은 버전, 중간 버전, 긴 버전의 자기소개를 올려 두는 것이 좋습니다.

발표 제안이 채택되고 녹화된 발표가 쌓이기 시작하면, 가장 좋았던 발표의 목록을 정리해 두십시오. 앞으로 CFP에 지원할 때 그 목록을 요청받게 됩니다. 그 발표들을 쉽게 찾아보고 공유할 수 있게 해 두면, 사람들이 CFP 없이도 여러분을 초대하기 시작할 것입니다.

35.10 CFP 예시와 동료 검토

물론 저는 이미 발표를 많이 보고 제목과 설명에 주의를 기울이라고 조언했습니다. 하지만 채택된 CFP의 예시를 보는 것이 도움이 되므로, 제가 가진 것을 여기에 나열하겠습니다:

CFP를 제출하기 전에 신뢰할 수 있는 동료 그룹에 공유하여 검토를 받으십시오.

35.11 다음 단계 & 추천 읽을거리

휴, 긴 장이었습니다. 도움이 되기를 바랍니다! 채택되면 제게 알려 주십시오. 응원하겠습니다.

늘 그렇듯, 이 단계에 대한 조언을 제공하는 사람이 저만 있는 것은 아닙니다. 제가 접한 다른 조언들은 다음과 같습니다:

저자 노트: 지금까지는 순전히 CFP를 통과시키는 방법에 관한 조언이었습니다. 이 책의 향후 판에서는 발표 조언에 관한 장을 추가할 예정입니다. 코로나19 때문에 지금은 그 부분을 뺐습니다.