3P by GN⁺ | ★ favorite | 댓글 1개
  • 기술 발표는 배경 설명이 필요하지만 초반에 청중을 잃기 쉬워, 먼저 문제 상황을 보여준 뒤 맥락을 채우는 구성이 더 효과적임
  • 이 기법은 Lawrence Block의 글쓰기 조언처럼, 자연스럽게 쓴 첫 부분과 둘째 부분을 바꿔 긴장감 있는 장면을 앞에 두는 방식임
  • 배경을 먼저 설명하는 발표는 이미 아는 사람에게는 반복이고, 모르는 사람에게는 아직 들을 이유가 부족해 집중도가 떨어질 수 있음
  • JIT 기반 가상 머신 최적화 예시에서는 성능 프로파일, 개선처럼 보이는 코드 변경, 실제로는 더 느려진 데이터를 먼저 보여준 뒤 JIT·최적화·아키텍처를 설명함
  • 초반에 풀고 싶은 문제를 던지면 프로그래머는 자연스럽게 해법을 찾으려 하며, 이후 설명을 따라갈 동기가 생김

문제를 먼저 보여주는 발표 구조

  • 기술 발표에는 보통 맥락 설정과 해결할 문제 제시가 모두 필요함
  • 다만 배경 설명부터 시작하면 발표 초반의 흡인력이 약해짐
    • 이미 배경을 아는 청중에게는 반복 정보가 됨
    • 배경을 모르는 청중에게는 아직 이해하려는 동기가 생기지 않음
  • Kent Beck의 방법은 발표 자료를 원하는 순서대로 작성한 뒤, 첫 두 슬라이드나 문단, 장을 서로 바꾸는 것임
  • Lawrence Block의 Telling Lies for Fun and Profit에서 가져온 기법임
    • 이야기를 자연스럽게 쓰면 첫 장은 주인공 소개, 둘째 장은 사건 전개가 됨
    • 두 장을 바꾸면 주인공이 위험에 처한 장면으로 시작함
    • 긴장이 생긴 뒤에 인물 소개가 나오므로 독자가 그 인물을 알고 싶어질 이유가 생김

JIT 최적화 발표 예시와 청중 반응

  • JIT 컴파일 기반 가상 머신 최적화 발표라면 일반적으로 JITing, 성능 튜닝의 기본인 파레토, 현재 머신 아키텍처를 먼저 소개함
  • 하지만 핫스팟을 줄이는 일반적 최적화가 전체 성능을 더 느리게 만들 수 있고, 별문제 없어 보이는 변경이 큰 개선을 만들 수도 있음
  • 두 번째 슬라이드에서 시작하는 구성은 첫 슬라이드에 판단할 재료를 바로 배치함
    • 핫스팟이 보이는 성능 프로파일
    • 개선될 것처럼 보이는 코드 변경
    • 최적화가 실패했을 뿐 아니라 시스템을 더 느리게 만들었다는 데이터
  • 그 뒤에 JIT, 최적화, 아키텍처 설명을 넣으면 배경을 아는 청중도 미스터리의 해답을 기다리며 따라오고, 배경을 모르는 청중도 집중할 이유가 생김
  • 프로그래머는 문제가 제시되면 해결하려는 공학적 반응을 보이므로, 발표 첫 부분에서 함께 풀 문제를 던지는 구성이 효과적임

댓글과 토론

Hacker News 의견들
  • 몇 주 전 PyCon에서 발표할 때 시간 안에 내용을 넣느라 고생했고, 결국 앞부분 몇 분짜리 도입부를 잘라냈음
    주제까지 서서히 올라가고, 왜 내가 이 얘기를 할 자격이 있는지 배경을 설명하는 부분을 없애고 바로 첫 번째 요점으로 들어갔는데, 거기에 괜찮은 농담이 들어 있어 잘 먹혔음
    주제가 충분히 흥미롭다면 도입을 건너뛰고 바로 본론으로 들어가도 되고, 농담을 섞으면 청중의 주의를 충분히 잡을 수 있다는 걸 배움

    • 이건 영업 발표에서도 중요함
      회사의 역사를 먼저 들려주는 영업 피치를 정말 싫어하고, 이상하게도 일본 대기업들이 특히 이런 면에서 최악인 경우가 많음
      각 슬라이드마다 “다음 슬라이드를 읽을 이유를 주지 않으면 청중이 일어나 나간다”고 생각해야 함
      내가 뭘 제공하는지 아직 모르는 상태라면 발표자의 존재 이유를 정당화할 필요가 없고, 결국 핵심은 발표자가 아니라 듣는 사람에게 있음
    • 동의하지만 이름이나 자격 같은 부드럽고 지루한 부분으로 시작하면 초반 긴장 상태에서도 말하기 쉽다는 장점이 있음
      그런 부분은 크게 버벅이기 어렵고, 그 사이 몸이 풀려 본 발표로 들어갈 수 있음
      물론 짧을수록 좋고, 그래서 첫 문장들은 단어 단위로 외워두는 편임
      가장 불안할 때도 첫 부분은 확실히 해낼 수 있고, 그다음부터는 더 자유롭게 말할 수 있음
    • 긴 도입부는 정말 싫고, 청중도 짧게 들어가는 걸 고마워함
      30초 정도는 괜찮지만 몇 분은 너무 길며, 발표든 YouTube 영상이든 마찬가지임
      사람들이 왜 그러는지는 이해함
      “이 사람이 자격이 있나?”, “맥락을 모르겠다” 같은 리스크를 줄이려는 거겠지만, 조금만 용기 내서 바로 핵심으로 들어가면 좋겠음
    • 기술 컨퍼런스 발표라면 소개 슬라이드에서 눈이 굴러가는 편임
      이미 그 발표를 들으러 선택했기 때문에 왜 흥미로운지 설명하는 건 이미 믿는 사람에게 설교하는 셈임
      해커 문화에서는 보통 자격증명보다 실력으로 사람을 판단하므로, “참고로 이걸 제가 만들었습니다” 정도는 끼워 넣을 수 있어도 이력서를 읽어주지는 말고 통찰로 설득해야 함
      모든 맥락에서 그런 건 아니고, 어떤 청중은 자격을 매우 중요하게 봄
      사람들이 그 발표를 직접 선택한 게 아니라면 충분한 맥락도 필요함
      그래도 대개는 먼저 관심을 잡고, 관심을 얻은 뒤에 도입으로 되돌아오는 편이 낫다
    • 글을 쓸 때도 도입부는 나에게는 나머지 문서를 쓰기 위해 필요하지만, 다 쓰고 나면 그 도입 내용이 불필요한 상투문처럼 되는 경우가 있음
  • 대학원 때 발표 훈련을 많이 받았고, 지도교수가 리허설 중 자주 퀴즈처럼 연습시켰음
    첫 슬라이드는 말을 하지 않을 때 잠시 띄워두는 자리, 책 표지 같은 것일 뿐이라고 봐야 함
    예를 들어 사회자가 “다음 발표자는 BlahBlah를 다룹니다”라고 소개하면 “감사합니다 SoAndSo. 저는 Godelski이고 다음 슬라이드 BlahBlah를 다루겠습니다”라고 답함
    반대로 “다음 발표자는 Godelski이고 BlahBlah에 관한 작업을 발표합니다”라고 소개하면 “감사합니다 SoAndSo. 다음 슬라이드”로 넘어감
    소개가 없을 때까지 포함해 변형은 있지만, 핵심은 소개자가 이미 말한 정보를 반복하지 않고 제목 슬라이드에서 빨리 벗어나는 것임
    그 슬라이드는 누가 말하고 무엇을 말할지만 보여주는 자리이며, 청중에게 더 전달할 정보가 있다면 그 슬라이드에 머물면 안 됨
    슬라이드 구성과 조직에는 더 많은 요소가 있지만 일반화하기는 어렵고, 다만 개요 슬라이드는 1초 미만으로 보이더라도 꽤 유용하다고 봄
    온라인에 슬라이드가 올라갈 때 더 중요하기도 함
    발표용 슬라이드는 말하기 보조로 만들기 때문에 온라인에 올리면 잘 맞지 않고, 슬라이드 노트를 쉽게 포함할 수 있으면 좋겠음
    Google Slides에서는 괜찮지만 PDF에서는 어렵고, beamer로는 이미 가능하거나 가능할 것 같으니 누군가 새 관행을 밀어붙일 수 있을 듯함

  • 내 기술 발표는 꽤 인기가 있고, 주제에 관심 없는 비기술직 사람들도 회사 안에서 슬라이드를 돌려봄
    이야기 구조가 핵심이고, 이야기가 없으면 발표는 흥미로울 수 없음
    발표를 만들면서 슬라이드를 계속 훑어 이야기 흐름이 자연스러운지 확인함
    발표 중에는 많은 정보가 화면에 한꺼번에 나타나지 않게 하고, PowerPoint 타임라인을 써서 내가 말하는 동안 슬라이드가 천천히 형성되도록 함
    거의 화이트보드를 쓰는 것처럼 보이게 하며, 슬라이드를 넘겼을 때 텍스트 벽이 튀어나오는 걸 좋아하는 사람은 없음
    텍스트만 있는 슬라이드를 피하는 건 아니지만, 내 이야기나 개념을 전달하는 최선의 방식인 경우가 드물어서 거의 쓰지 않음
    발표를 만들면서 너무 기술적이라 지루해지거나, 너무 비기술적이라 지루해지지 않는지도 계속 읽어봄
    균형이 중요하고, 갑자기 너무 깊게 기술적으로 들어가야 한다면 다음 몇 장에서는 다시 끌어올려야 하며 반대도 마찬가지임
    텍스트가 적어도 손그림 시각화를 많이 써서 개념을 정확히 설명하므로, 출력해도 여전히 이해되고 알아야 할 내용을 전달함
    마지막으로 어떤 앱을 쓰는지는 중요하지 않음
    나쁜 예술가가 도구 탓을 하는 법이고, 나는 PowerPoint를 쓰는데 iPad Pencil 지원과 완전한 애니메이션 타임라인이 있어 잘 쓰면 거의 영화를 만드는 수준이기 때문임
    다만 주로 슬라이드를 더 작은 조각으로 나누는 데 쓴다

  • 기술 발표는 항상 스포일러로 시작함
    바쁘거나 그냥 내 말을 믿어도 되는 사람은 가장 중요한 정보만 얻고 거의 바로 떠날 수 있음
    동의하지 않거나 주장에 대한 증거를 보고 싶은 사람은 계속 참여하면 됨

    • BLUF, 즉 Bottom Line Up Front와 비슷함
      메모나 이메일에서 더 자주 쓰는 표현이지만 개념은 같음
      끝에 무엇이 있는지 먼저 알려주면 배경 설명이 어디로 가는지 사람들이 이해함
      이야기의 척추를 써도 좋지만, 무지개 끝에 폭발 장면이 있다는 걸 청중에게 설득하려면 예고편을 먼저 보여줘야 함
    • 제품 시연에서 말하는 마지막 것을 먼저 하라는 아이디어와도 맞음
      청중이 보상을 “얻어내게” 만들 필요 없이 좋은 부분으로 바로 가고, 관심 있는 사람을 위해 나머지를 설명하면 됨
      여러 시연 리뷰에서 나온 내용도 여기에 있음: https://web.archive.org/web/20220126051034/https://www.secon...
    • 내가 쓰는 블로그 글도 모두 그렇게 함
      요약으로 시작하고, 적절할 때는 복사해 붙여 넣을 수 있는 완전한 재사용 코드까지 먼저 둠
      내가 남들에게 원하는 방식이 그래서 나도 그렇게 함
      자아는 내려놓고 유용함을 우선해야 함
    • 중요한 정보를 전달할 때는 역피라미드 구조가 거의 항상 좋음
      사람들이 왜 신경 써야 하는지를 먼저 말하게 되고, 덜 흥미로운 내용은 뒤로 가므로 시간이 초과되거나 누군가 집중을 잃어도 많이 놓치지 않음
      [1] https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)
  • 발표판 “I’m okay, the bull is dead”라고 볼 수 있음
    https://www.computerworld.com/article/1702433/i-m-ok-the-bul...

    • 글의 요지는 이해하지만, 나라면 정보를 조금씩 천천히 듣거나 더 나쁘게는 캐내야 하는 것보다 “차로 황소를 쳤어. 나는 괜찮지만 차는 망가졌어”를 먼저 듣고 싶음
      그런 상황에서 사람이 침착하지 못해 명확히 설명하지 못하는 건 이해할 수 있지만, 여기서는 그런 경우가 아니었던 것 같음
      침착하다면 상대를 위해 무슨 일이 있었는지 10~15초 설명을 먼저 해주는 편이 낫다
    • 작년에 이 주제로 큰 논의가 있었음: https://news.ycombinator.com/item?id=37087459
    • BLUF, 즉 핵심을 앞에 두기와 같은 원칙임
      결론과 영향을 먼저 말하고, 그 사건으로 이어진 배경을 나중에 채우면 됨
  • 기술 발표에도 여전히 이야기가 필요함
    표준적인 스토리텔링 기법처럼 관심을 끄는 사건, 즉 도입 사건으로 시작해야 함
    The Matrix는 Trinity가 잡히기 직전으로 시작하고, Bambi는 엄마가 총에 맞으며, Star Wars는 작은 배가 레이저를 쏘는 거대한 배에 쫓기며 시작함
    좋은 기술 발표는 좋은 이야기 구조를 따른다
    도입 사건, 작은 절정으로 쌓아 올리기, 잠깐 물러서기, 절정, 결론 순서임
    훌륭한 기술 발표자가 되고 싶다면 좋은 이야기를 하는 법에 관한 책을 읽는 게 좋음

    • 그 기법으로 청중을 화나게 하지 않도록 조심해야 함
      예를 들어 “David는 시골 어딘가의 방 3개짜리 집에서 개 boopy와 bloppy와 함께 산다...”로 시작하는 너무 긴 장문 기사들은 바로 닫게 됨
      예전에 코미디언이 진행한 훌륭한 발표 수업을 들었는데, 가장 기억에 남은 조언은 발표를 영웅 서사처럼 구성하라는 것이었음
      모두가 아는 구조임: 모든 게 좋다, 비극이 닥친다, 문제를 극복한다, 축하한다
      기술 발표에는 안 맞는다고 생각할 수 있고 모든 발표가 그럴 필요는 없지만, 생각보다 훨씬 자주 적용 가능함
      기본적으로 문제를 해결하는 모든 것은 이런 식으로 말할 수 있음
      그런데 너무 많은 발표가 “X 프로젝트에 대해 말하겠습니다. 슬라이드 개요입니다. 자, X란 무엇인가?”로 시작함
      대신 “우리는 Y를 하는 것들이 많았습니다. Z가 오기 전까지는 잘 됐죠. 그다음 재앙이 왔습니다. 기존 해결책 A는 이 경우 전혀 통하지 않았습니다. 그래서 X를 만들었습니다. 하지만 ... 때문에 안 됐고, 그래서 ... 해야 했고, 마침내 모든 게 동작했습니다”처럼 말할 수 있음
    • Bambi는 태어나는 장면으로 시작하고, 엄마는 영화 중반에 죽음
  • 첫 슬라이드는 텍스트 없는 이미지로 시작하는 걸 추천함
    그 이미지는 번호 없는 제목 슬라이드에 있던 발표 주제와 겉보기에는 아무 관련이 없어야 함
    그러면 사람들이 어떤 설명을 할지 궁금해하고 주의를 기울임
    수수께끼를 풀고 나서 두 번째 슬라이드로 넘어가 문제 정의나 연구 질문을 제시하고, 이후에는 일반적인 구조인 개요, 방법, 데이터, 실험, 평가 결과, 논의와 한계, 요약, 결론과 향후 작업으로 가면 됨
    단, 이건 구두 발표에만 통함
    대형 글로벌 기업에서 주류인 또 다른 중요한 슬라이드 덱 유형은 PowerPoint 발표와 Word 문서의 혼합물에 가까움
    슬라이드가 텍스트로 가득 차 있어 덱만 봐도 이해되도록 만들어지고, 발표용일 뿐 아니라 주로 이메일로 돌려 읽히기 위해 작성됨
    임원진이 발표를 듣지 않고 슬라이드만 훑을 수 있기 때문에, 좋은 발표를 보조하는 좋은 슬라이드의 규칙을 일부러 어김

    • 기술 논문에도 비슷한 조언이 적용된다고 봄
      적어도 내 분야인 컴퓨터 비전과 기계 학습에서는 첫 페이지에 멋지고 가능하면 자기 설명적인 그림을 크게 배치함
      PDF를 훑어보는 사람의 관심을 잡고 끌어들이는 역할임
      컴퓨터 비전에서는 보통 3D 재구성이나 객체 탐지가 강조된 이미지처럼 시각적으로 매력적인 것을 찾을 수 있음
      아니면 기준선보다 내 방법이 얼마나 나은지 보여주는 그래프를 쓸 수 있지만, 숫자의 의미를 잘 모르는 사람에게는 덜 흥미로울 수 있음
  • 시연에서는 오래전에 좋은 부분부터 시작하라는 걸 배웠음
    훌륭한 모니터링 소프트웨어가 있다면 설치 과정, 메트릭 수집 설정, 프런트엔드를 시계열 데이터베이스에 연결한 과정부터 시작한 뒤 예전에는 없던 멋진 그래프를 보여주지 말아야 함
    대신 예전에는 없던 멋진 그래프를 먼저 보여주고, 왜 그 그래프가 유용한지 설명해야 함
    그러고 나서 모두가 관심을 갖게 된 뒤에야 그 상태에 어떻게 도달했는지 시간을 들여 보여줄 수 있음
    멋진 곳에 도달하기까지 길고 지루한 과정으로 시작하는 시연을 너무 많이 봤고, 차라리 멋진 것을 먼저 보여줬다면 훨씬 나았을 것임

  • 기술 발표에는 천재적인 방식임
    다만 소설, TV 쇼 같은 오락 매체에서 이렇게 하면 늘 흥미가 떨어짐
    액션 장면을 이해하는 데 배경 정보가 필요 없다면, 배경 정보를 통째로 건너뛰어도 된다고 봄
    속도를 확 올렸다가 너무 빨리 다시 아무것도 없는 상태로 떨어뜨리지 않았으면 함

    • 뉴스 기사, 특히 스포츠나 정치 기사에서 이런 방식을 많이 씀
      그래도 이야기의 가장 중요한 부분을 먼저 내세우는 것이니 이유는 있음
    • 오락 매체에서는 종종 막판 임시방편처럼 느껴짐
      소설의 전개가 너무 느리고, 테스트 독자들이 흥미로운 일이 일어나기 전에 포기하니 편집자가 “10장에 있는 멋진 전투 장면을 앞에 넣어서 이 책이 뭘 하는지 보여주자”고 제안하는 식임
      그런 방식은 잘 통하는 경우가 드묾
  • 모든 문장과 문단을 읽었지만, 원글이 무엇을 전하려는지 아직 확실하지 않음
    “도입부를 건너뛰라”는 뜻인가?
    나는 발표를 시작할 때 발표가 무엇으로 구성될지 짧은 개요를 먼저 줌
    항상 청중에 맞춰 내용을 조정할 수는 없지만, 최소한 앞에서 색인이나 요약본을 주면 언제 집중하고 언제 잠깐 멍 때려도 되는지 알 수 있음

      1. 말할 내용을 말한다
      2. 말한다
      3. 말한 내용을 다시 말한다
        반복해서 강화할 핵심은 2~3개여야 하고, 그 이상이면 안 됨
        그리고 내 1순위 팁은, 발표가 더 자연스럽게 들리게 하고 싶을수록 사전에 더 많이 연습해야 한다는 것임
        경험 많은 발표자라면 이 규칙들을 언제 어떻게 깨야 하는지도 알게 됨
    • 이 글의 핵심은 “문제의 해법을 이해시키기 위해 기술적 배경을 먼저 설명하지 말고, 문제부터 시작하라. 그리고 맥락이나 기술적 배경은 두 번째로 설명하라”로 이해했음
    • 결국 텍스트의 동기 부여를 발명한 셈임
      물론 재발명임