개발 컨퍼런스에서의 연사 경험을 통해 얻은 것들을 공유하고자 합니다. 많은 사람들 앞에서의 발표는 처음이거나 익숙하지 않은 분들께 도움이 될 수 있는 글이 되길 바랍니다.

(발표자료는 글 하단에 링크로 걸어두었습니다.)

서론

컨퍼런스 연사는 하늘과 같은 선배님이라고 생각했습니다.

여러분들은 평소에 개발 컨퍼런스나 아티클을 자주 읽으시나요?

저는 선배 개발자님들의 경험이 담긴 시간을 산다 라고 생각하여 이러한 컨퍼런스나 아티클을 자주 읽습니다. 기술적 도전이나 시도가 유의미한 인사이트를 도출해내는 것은 정말 어렵습니다. 그렇기에 오랜 시간 다양한 시도를 거치고 고민해야지만 흔히 저희가 말하는 인사이트를 도출할 수 있다고 생각합니다.

이러한 과정을 연사님들의 발표를 통해 온전히 얻기란 어렵지만, 그런데도 저는 정말 가치가 있다고 생각합니다. 인사이트를 통해 기술적 가치를 증명하고, 비즈니스 임팩트를 만드는 연사님들을 보며 늘 선망의 대상으로 여겼습니다. 제가 연사를 신청한 이유도 지금 생각해보면 그들을 닮고 싶었던 것이 큰 것 같습니다.

모두에게 열려있는 컨퍼런스 - 테오콘

스스로 의식하진 않았지만 컨퍼런스를 보며 미래에 나도 인프콘이나 feconf 와 같은 컨퍼런스에 서보고 싶다는 마음이 있었습니다. 그러던 어느 날!! 프론트엔드 커뮤니티에서 연사를 모집한다는 글이 올라왔습니다. 처음에는 저와는 무관하다 생각하여 신경 쓰지 않았습니다.

그런데 그 글을 보고 출퇴근하며 곰곰이 혼자 생각해보니 모두에게 열려있다고 하니 도전해볼 수 있지 않을까? 라는 생각이 머릿속을 떠나지 않았습니다. 컨퍼런스의 취지도 잘 읽어보니 서로 가진 지식과 경험을 나누는 인사이트에 초점이 맞춰져 있어 안심하고 도전해도 되겠다고 생각했습니다.

저는 팀 내에서 복잡한 요구명세를 쉽게 풀어낼 방법으로 패턴매칭을 소개하고 도입해본 경험이 있습니다. 이 과정에서 저희팀은 타입추론과 요구명세에 대한 완전성검사를 더욱 쉽게 해낼 수 있었고 결과적으로 dx와 코드 안전성이 향상되는 좋은 경험을 하였습니다.

비록 주니어지만 새로운 기술을 찾아 도입하고 결과적으로 팀 내 스펙으로 인정받아 도입되는 과정이 정말 좋았고 이를 통한 코드품질 향상도 행복했습니다. 패턴 매칭이 정말 좋다고 느끼는데 잘 알려지지 않은 문법이라 저는 이번 세미나를 통해 만인에게 이 기술을 알려보고 싶었습니다.

본론

1. 주제 정하기 - 세미나와 컨퍼런스는 다르다.

첫 인터뷰에서 저는 팀 내 기술 세션에서 제가 발표한 내용을 바탕으로 패턴 매칭에 대해 이야기하였습니다. 하지만 처참한 피드백이 오고 마는데요.🥺

🧑‍💻 : 내용이 나쁘다기보다는 우리가 컨퍼런스를 할 거잖아요.. 세미나 보다는 컨퍼런스에 가까운 형식이고 인사이트가 경험을 공유하는 자리였으면 좋겠어요.

저희 팀은 이미 모두 같은 문제 상황을 느끼며 일을 하고 있고, 패턴 매칭이 무엇인지도 알고 있는 팀이었습니다. 조금 더 쉽게 말하면 공감대를 형성할 필요가 없었습니다.지금 우리가 쓰는 코드를 패턴 매칭을 통해 더 잘 써봐야지! 를 위한 자리로 마련한 자료였기 때문에 컨퍼런스의 방향성과는 맞지 않았습니다.

제가 앞에서 이미 말씀드렸지만 패턴 매칭은 잘 알려지지 않은 문법입니다. 그렇기에 초반에 사람들이 내 이야기를 듣고 호기심을 가질 수 있도록 문제상황에 대해 공감대를 만드는 것이 정말 중요합니다.

청중은 서론에 문제 상황을 들으며 "아 그래그래.. 맞지 맞지!.. 저럴때 힘들더라..나도 저럴 때가 많았어" 라는 이야기가 나오도록 해야 자연스럽게 문제 상황을 해결한 방법과 과정에도 호기심을 가지게 됩니다. 이러한 공감과 호기심이 중요하다는 것을 저는 잘 인지하지 못했고 이 부분을 만드는 데까지 정말 마지막 날까지 시간을 쏟은 것 같습니다.

여러분들도 어떠한 설득, 제안을 위한 말하기나 글쓰기를 하신다면 공감과 호기심을 유발하는 장치를 만드는 것이 정말 중요하다고 말씀드리고 싶습니다! (재미있다면 더 좋습니다 ⭐️)

2. 원고 작성하기 - 인사이트는 썰이다.

청중을 위한 글쓰기와 말하기는 대다수 사람들이 익숙하지 않습니다. 강단에서 멋진 발표를 하고 청중으로부터 공감과 박수를 받는 경험은 정말 귀하고 많은 사람이 경험하기 쉽지 않습니다. 하지만 우리는 늘 청중을 향해 말을 하고 있다는 사실을 인지하고 계셨나요?

친구, 선후배, 직장 동료, 부모님들에게 고민 상담이나 경험담을 풀어보시지 않았나요? 사실 우리는 타인의 문제를 들어주고 자기 경험을 통해 문제에 대한 해결책을 말해주는데 상당히 익숙해 있습니다. (연애, 진로 상담이 가장 대표적이겠지요.)

예를 한번 들어봅지요.

• 아둔한 친구 A : 어제 여자친구랑 연락을 자주 하지 않는다고 싸웠어.. 아니 일 중인데 바로바로 못 볼 수도 있지 않아?
• 나 : 아이고 이런.. 나도 예전에 그런 적이 있었는데 결국 헤어졌거든..? 그런데 지금 생각해보면 그땐 이렇게 말했으면 좋았을 것 같아. 예를 들어 ~~

문제 상황에 대한 공감과 경험으로 부터 오는 인사이트, 이를 통한 해결책을 아주 정확하고 간결하게 말해주고 있습니다. 이미 너무나 자주 하고 잘 해왔던 이야기인데 저는 컨퍼런스를 준비한다는 생각 때문에 문제상황에 대한 공감과 해결책이 다소 딱딱하고 일반적으로 이야기되었습니다. 이렇게 된다면 결과적으로 청중이 들었을 때 "인사이트가 없다", "지루하다" 등의 반응으로 이어지기 쉽다고 생각합니다.

결과적으로 컨퍼런스는 유사한 문제로 고민하고 있는 후배 개발자에게 먼저 고민하고 겪어본 선배 개발자가 썰을 풀어주는 시간이 되어야 한다는 것을 배웠습니다. 서론에서 말씀드렸지만 컨퍼런스 연사님을 하늘 같은 선배님이라고 느끼는 포인트를 만들어주어야 합니다.

그런데 개발자는 어떠한 존재입니까... IT직군에서 일하기에 MBTI도 I_T_로 맞춘 존재들입니다. 썰을 푸는데 익숙지 않기 때문에 팁을 얻었지만 잘 푸는 것이 상당히 어려웠습니다. 이럴 때 배운 것은 기-승-전-결을 세워 이야기를 빌드업 해나가면 정말 좋다는 것입니다.

제가 받은 피드백을 일반론적으로 풀어보면 이렇게 되는데요. 각 단계에서는 해당 반응을 끌어내면 지루하지 않게 청중이 원하는 인사이트에 대한 요구를 요소할 수 있습니다.

• 기 - 공감 유도하기: 다양한 경험을 통해 얻은 지식으로 상대방의 어려움을 공감하고 이해한다.
• 승 - 공감을 바탕으로 호기심 만들기: 나의 해결책을 소개하며 어떻게 상황을 개선하고자 했는지 설명한다.
• 전 - 경험 공유를 통해 호기심을 집중력으로 바꾸기: 내가 시도한 해결책을 통해 얻은 인사이트를 공유하고, 그 과정에서 발생한 장단점을 솔직하게 언급한다.
• 결 - 성공적인 해결 방안 제시하여 도파민 분출시키기 : 내가 제안한 해결책이 어떻게 실제로 문제를 해결했는지를 간결하게 설명하여 마무리한다.

간단하게 제가 준비한 패턴 매칭에 대해서 기승전결을 세워보면 아래와 같습니다.

• 기 (공감) 🥺
  에이, 코드 복잡하면 머리 아프겠다. 너도 알다시피, 타입 체크하면서 분기 처리하는 거 진짜 복잡해지면서 끙끙대지 않니? 너만 혼자 겪은 게 아니라, 우리 프로젝트에도 그런 문제가 많았어.

• 승 (패턴매칭 도입) 😁
  그래서 나는 패턴 매칭 도입해 봤어. 이 패턴 매칭이라는 거, 개념 자체가 좀 신기하다고 생각하는데, 너도 한 번 알아봐봐! 코드 작성하면서 어떻게 도움이 되는지 알게 될 거야.

• 전 (ts-pattern 도입의 시행착오와 장점) 🤔
  근데 우리 프로젝트에 바로 도입하는 게 쉬운 건 아니었어. 팀도 설득해야 했고, 새로운 개념을 팀이 익힐 수 있도록 사내 세미나와 PR리뷰도 적극적으로 해야 했지. 그런 노력 끝에 얻은 게 참 많아졌어. 결과적으로 ts-pattern이라는 도구 덕에 코드 작성이 훨씬 수월해지고, 분기처리도 선언적으로 더 직관적으로 할 수 있게 됐어.

• 결 (패턴 매칭의 성과) 🤩
  덕분에 코드가 예전보다 훨씬 간결해지고, 타입 처리도 훨씬 편해졌어. 패턴 매칭 덕분에 dx도 좋아진 거 같아. 한번 너도 해봐! 그리고~~ (간단한 나의 철학을 담은 조언)

컨퍼런스에서 하고자 하는 내용을 썰을 푼다 라고 생각한 후 기승전결을 나눠 빌드업 하니 각 단계에서 무엇을 청중에게 말해주어야 관심을 가지고 집중력 있게 들어줄 수 있는지 알았습니다.

3. 장표 만들기 - 우리는 숏츠와 릴스의 시대에 살고 있다.

출퇴근 시간이나 누워서 숏츠나 릴스를 휙휙 넘기며 뇌를 녹여본 경험은 누구나 있으실 겁니다. 유튜브보다 짧은 틱톡, 릴스, 숏츠 등 15초 이내의 영상을 주로 시청하고 이를 통해 정보를 접하다 보니 짧고 빠른 결과 얻는 것에 너무나 익숙해졌습니다. 이에 따라 사람들은 무언가를 진득하게 하는 것을 부담을 느끼고 집중하기가 쉽지 않습니다.

빠른 전개와 참을성이 없어진 청자를 만족시키기 위해서는 발표 방법에 색다른 장치들을 포함해야 한다는 것을 배웠습니다.

1. 도치법은 말에만 있는 게 아닙니다.

타인의 얼굴을 보고 매력이나 호감도, 신뢰도, 공격성 등을 판단하는 데 걸리는 시간은 0.1초 미만이라고 합니다. 발표도 마찬가지입니다. 청자의 관심을 끌기 위해 공통된 문제에 대한 공감 혹은 강렬한 명언 등을 활용하여 청자를 효과적으로 후킹해야 이후의 이야기에도 호기심을 가진다는 것을 배웠습니다. 이를 위해 두괄식으로 결론에서 내가 하고 싶은 결과를 미리 서론에서 이야기해 청자에게 호기심과 관심을 끄는 방법이 정말 좋았습니다.

2. 읽는 것과 듣는 것을 같게 해야 합니다.

간결한 어투와 빠른 말 속도는 명확하고 간결하게 청중을 이해시키는 데 큰 도움을 줍니다. 특히 장표와 말하는 어투를 같게 하는 것이 청자들이 장표를 보면서 제 말 들었을 때 더 쉽게 집중할 수 있었습니다. 이때 말의 속도는 평소 말하는 것보다 조금 더 빠르게 말하는 것을 추천해 드립니다. 경험을 다루는 내용이라면 모르겠지만 기술을 다루는 부분에서는 다소 지루해질 수 있어서 빠른 내용 전개가 정말 중요하다고 배웠습니다.

3. 장표가 멈춰있으면 안됩니다.

앞서 말씀드렸던 것처럼 읽는 것과 듣는 것을 같게 해야 합니다. 내가 말을 계속 이어가더라도 장표가 멈춰있는 동안 청중의 흥미는 떨어질 수 있습니다. 그렇기에 말에 따라서 장표의 글자 색을 달리하거나 발표 자료의 전환과 함께 애니메이션 등을 활용하여 시각적인 효과를 주면 청중의 지루함을 방지하고 발표의 흐름을 잘 유지할 수 있는 것을 배웠습니다.

여기서 꿀팁은 코드를 보여줄 때는 codesnab을 이용하면 더욱 이쁘게 보여줄 수 있습니다. 코드를 보여주어야 할 상황에서는 특정한 줄에만 집중할 수 있도록 흐리게 처리를 하거나 코드가 추가되거나 삭제되었다고 하이라이트를 칠 수도 있어서 정말 유용하게 이번 발표에서 사용하였습니다.

4. 글보단 그림이 좋습니다.

숏츠와 릴스에 익숙해진 청자는 글과 코드를 읽는 것이 편하지 않습니다. 또한 컨퍼런스에서 모니터가 잘 안보일 수도 있고 짧은 시간동안 장표를 보기 때문에 이를 한눈에 볼 수 있는 시각적 자료는 매우 효과적입니다. 그림, 차트, 그래프 등을 활용하여 복잡한 정보를 간결하게 전달하면 청중이 빠르게 이해할 수 있다는 것을 배웠습니다.

5. 간결하되 뚜렷한 메시지를 전달해야합니다.

짧은 시간 동안에도 명확한 메시지를 전달하는 것이 중요합니다. 핵심 아이디어에 집중하고 불필요한 세부사항은 최소화하여 청중이 핵심 메시지를 빠르게 이해할 수 있도록 해야 합니다. 또한 중간중간 리캡을 통해서 내가 하고 있는 이야기가 무엇인지를 지속적으로 심어주는 것이 중요하다는 것을 배웠습니다.

4. 발표 - 기술 세션은 원래 시큰둥하다.

컨퍼런스를 참여하는 개발자가 모든 주제에 관해 관심이 있는 것은 아닙니다.

저 또한 컨퍼런스를 가서 모든 주제에 흥미를 느끼고 듣진 않습니다. 별 관심이 없어서 넘기는 주제도 있고, 이전 세션을 너무 많이 들어서 기가 빨릴 때도 있었습니다. 그래서 현장에서 모든 청중이 저의 발표에 집중하길 바라는 건 오만이라는 것을 배웠습니다. 그러나 저는 발표 당시에 이러한 사실을 간과하고 사람들이 집중을 안하고 다른 행동을 하는 것을 보고 "내가 너무 어렵고 빠르게 말하고 있나?" 라고 생각해 천천히 말한 것을 너무나 후회합니다.

결과적으로 말을 더 천천히 하다 보니 분위기는 지루해지고 오히려 사람들은 흥미를 잃기 시작했습니다. "앞에서 우리는 숏츠와 릴스의 시대에 살고 있다." 에서 말한 내용들은 이 과정에서 깨달은 것들입니다. 🥲

이렇게 스스로 발표를 망쳤다고 생각하고 강단에서 내려왔을 때 저에게 프론돌이님이 이런 말을 해주었습니다. "저도 컨퍼런스를 다녀봤는데 기술 세션 반응은 원래 좀 시큰둥해요. ㅋㅋㅋ 허브는 잘 몰랐겠지만,뒤에서 보면 사람들은 패턴 매칭에 대해 검색도 많이 하고 노션에 정리해가며 듣는 사람들이 정말 많았어요. 반응이 없다고 망했다고 생각하지 말아요."

개발자들은 컨퍼런스를 들으며 듣는 내용을 노션에 정리하며 검색도 동시에 하는 멀티플레이어들이 많다는걸 잘 몰랐습니다. 개발자들은 성향상 컨퍼런스를 들으며 자신이 모르거나 궁금한 부분이 있으면 내용을 들으며 인터넷 검색을 많이 합니다. 특히 제가 발표한 패턴 매칭은 타입스크립트, 함수형 언어, 선언적인 코드 등을 주로 다루기 때문에 개념이 궁금한 개발자들이 많아 인터넷 검색을 정말 많이 하고 있었다고 들었습니다. 그러나 중요한 것은 검색하며 듣는 것이 딴짓을 하는 게 절대 아닙니다! 이러한 행동은 개발자들에게 너무나 자연스럽고 현재 듣고 있는 내용에 집중하고 있다는 방증이기도 합니다. 그러나 처음 연사로 발표하는 저에게는 사람들이 발표를 안 듣고 컴퓨터만 보고 있는 것이 집중을 하지 않는다고 느껴 발표하면서 오히려 점점 위축되었습니다.

그리고 중요한 것은 컨퍼런스는 강의가 아니라는 점입니다.

이것은 테오가 제게 말해준 피드백입니다. 강의를 오는 사람들은 그 내용을 배우기 위해 오는 사람들입니다. 그러므로 모든 내용을 이해하고 습득하는 것이 중요하지만 컨퍼런스는 그렇지 않습니다. 세션에 관심이 없는 개발자들도 있을뿐더러 제가 패턴 매칭을 적용하고 인사이트를 도출하기까지의 과정을 30분이란 짧은 한 번의 발표를 통해 이해하길 바라는 것은 스스로 오히려 저의 경험을 얕게 평가하는 것이라고 말해주었습니다.

실제로 저도 컨퍼런스를 듣고 그 내용들이 모두 기억에 남진 않았습니다. 단순히 어떠한 키워드 몇 개만 남았고 집에 가서 필요할 때 다시 보기를 보거나 글을 읽는 경우가 많았습니다. 그러나 현장에서 사람들이 이해를 못 하나..? 라고 생각해 점점 말을 느리게 하고 준비한 내용을 더 쉽게 풀어 말할려고 하니 오히려 말이 길어지는 문제가 있었습니다.

여러분들이 기술 발표를 하게 된다면 청중의 표정이나 행동에 위축되지 마시고 준비한 내용을 그대로 무대에서도 하는 연습을 해보셨으면 좋겠습니다.

5. 네트워킹하기 - 좋은 개발자가 모이는 자리는 흔치 않다.

컨퍼런스에서의 연사 발표나 세션도 중요하지만, 네트워킹 또한 큰 의의가 있습니다. 특히 개발자들은 평소 내성적인 편이라는 오해가 있을 수 있지만, 컨퍼런스에서는 다양한 개발자들이 비슷한 관심사를 공유하며 소통하고자 하는 모습을 자주 볼 수 있었습니다.

개발자들이 모여 생태계를 만들고 함께 성장하는 것이 얼마나 중요한지를 느꼈습니다. 훌륭한 개발자들이 한자리에 모이는 것은 흔한 일이 아니기 때문에, 이런 자리에서 좋은 관계를 형성하고 정보를 교류하는 것은 정말 중요하다는 것을 배웠습니다.

부끄럽지만 제가 주변 지인들에게서 자주 듣는 이야기 중 하나는 "압축 성장 주니어"라는 표현이 있습니다. 낮은 연차임에도 불구하고 어떻게 그렇게 잘 컸냐는 질문을 자주 받는데...(실제론 정말 모자랍니다..하핫..😅), 그래도.. 저의 비결을 말해보자면 스승을 만들기입니다. 저는 주변에 가르침과 영감을 주는 분들이 많았고, 그들의 행동과 습관을 따라가면서 성장해왔습니다.

"fake it, until make it"
될 때까지 척하다 보면 그렇게 된다.

그런 스승들은 친구, 지인, 동료가 될 수도 있습니다. 그리고 이러한 스승들이 많을수록 성장은 더욱 빨라집니다. 이러한 훌륭한 스승을 만날 수 있는 최고의 장소 중 하나는 컨퍼런스라고 생각합니다. 그래서 컨퍼런스에서 연사 발표를 듣거나 하게 된다면 함께 참여한 분들과 자주 소통하며 인간관계를 쌓아보는 것을 적극 추천 해드립니다.

테오, 2기 운영진, 스피커, 참가자분들 정말 감사드립니다.🥹 (사실 여러분들 모두 제 마음속 스승이었습니다)

결론

핵심 요약 정리

1. 원고 주제 정하기

• 세미나와 컨퍼런스의 차이를 이해하고, 공감대 형성 가능한 문제상황을 선정한다.
• 경험을 통한 인사이트를 담은 주제를 선택하여 다양한 시각에서의 해결 방안을 고려한다.

2. 원고 작성하기

• 경험을 구체적으로 전달하고자 노력한다.
• "썰 푼다"는 마음가짐으로 시작하여 빌드업을 통해 청중의 이목을 집중시킨다.
• 기, 승, 전, 결의 구조를 활용하여 공감을 유도하고 경험을 공유함으로써 청중의 집중력을 유지한다.

3. 장표 만들기

• 빠른 전개와 청자의 참을성을 고려하여 발표 방법에 다양한 장치를 포함시킨다.

4. 발표하기

• 기술 발표 시, 청중의 반응에 신경 쓰면서 무대에서도 자연스럽게 내용을 전달하기 위해 연습한다.

5. 네트워킹하기:

• 개발자들의 모임에서 생태계를 형성하고 성장하는것은 정말 중요하다.
• 한자리에 모이는 좋은 기회를 놓치지말고 관계 형성과 정보 교류를 활발히 한다.

마무리하며

컨퍼런스는 높은 전문성이 필요한 장소로 생각되기도 하지만, 이번에 연사를 하며 느낀 점은 누구나 자신이 겪은 문제와 그에 대한 해결책을 공유할 수 있다는 것입니다. 작은 문제라도 누군가에게는 큰 도움이 될 수 있으며, 이를 통해 다양한 배움과 인사이트를 제공할 수 있다는 자신감을 얻었습니다.

컨퍼런스 연사로서 내 이야기를 전하면서 가장 크게 느낀 점은, 내가 겪은 문제가 부족하거나 간단하다고 생각하더라도 그것이 다른 누군가에게는 큰 도전이자 모험으로 다가올 수 있다는 것입니다. 나의 경험을 통해 어떻게 문제를 해결했는지, 어떤 접근 방식을 택했는지를 공유함으로써 성장할 수 있고 타인에게는 동기부여가 될 수 있다는 걸 배웠습니다.

그리고 이 과정을 도와주신 테오에게 늘 감사의 인사를 드리고 있습니다. 어마어마한 양의 피드백이 티키타카 되었었습니다.. 🥹 컨퍼런스를 준비하면서 겪은 이러한 경험들은 문제를 다루고 해결하는데 필요한 능력을 키우는 데 정말 큰 도움이 되었습니다.

컨퍼런스는 지식을 나누는 장이자, 서로의 성장을 위한 소중한 기회라고 생각합니다. 이 글을 통해서 여러분들도 새로운 도전에 용기를 얻으셨으면 좋겠습니다.

긴 글 읽어주셔서 감사합니다~! ❤️

테오콘 컨퍼런스 발표자료