유스콘 발표를 마치고(2) -
발표를 잘하는 건
Hands On Lab 발표 준비해나가기
앞에 내용에 이어 발표를 준비하며 받은 피드백, 다른 분들이 받은 피드백, 내가 느낀 점들을 정리해
'(Hands On Lab) 발표를 잘하는 건' 뭔지에 대해 나름대로 작성해보려고 한다.
그렇기에, 정답은 아니고 '이러면 좋겠구나' 정도의 이정표가 되면 좋겠다.
추가로, 내용들이 꽤나 딱딱할 수 있다. 필요한 부분만 봐도 좋을거 같다.
하나씩 발표를 위한 내용을 톺아보자.
맨 밑에 발표 준비를 위한 체크리스트도 있다.
장표
Eye First
세세한 디테일이 발표의 퀄리티를 한층 더 높여주는 걸 느꼈다.
적절한 짤이나 이모티콘들을 넣을 수 있다면 좋겠지만, 그게 안된다면 기본기에 충실하자.
정렬 통일시키기 : 중앙이나, 좌측 정렬 중 하나를 통일시켜 일관성을 유지
이전 장표는 왼쪽 상단
현재 장표는 가운데 중단
그다음 장표는 왼쪽은 그림, 글은 오른쪽 상단
등 정렬이 다르면, 청중이 따라가는데 불편함을 느끼게 된다.
한 화면당 3~4줄 이하
아무리 좋은 내용이라도, 한 번에 설명하는 건 어렵다.
끊어서 필요한 내용들만 3줄 정도로 설명을 해나가자.
다이어그램 활용하기 : 텍스트 위주 내용은 시각 자료로 대체
텍스트 위주 내용은 읽기가 어렵다.
지금 이 내용들조차도...
LLM을 사용해서 적극적으로 내용을 그림화 해보려고 하자.
글씨가 조금씩 깨질 순 있어도, 큰 노력하지 않아도 말하고자 하는 내용을 전달할 수 있다.
코드 블록 레이아웃
읽기 쉽게 넉넉한 여백을 확보시켜 주자.
❌ git branch checkout -b feature/ISSUE-1124_fix_error && git pull
✅ git branch checkout -b feature/ISSUE-1124_fix_error \
&& git pull
하이라이팅
마우스 포인터 금지 : 마우스로 가리키는 게 아닌 색깔로 하이라이팅
마우스 포인터는 작아서 잘 안 보일 수 있다.
강조하고 싶다면, 두 슬라이드로 나눠 색깔을 다르게 해서 강조시켜 주자.
분리해서 설명하기
git stash list --pretty=format:$'% gd\t% cr\t% s'
이와 같은 명령어를 설명해야 한다고 가정해 보자.
말로 설명하려고 하면?
% gd는 stash ID를 의미합니다.
% cr 은 생성된 시간을 의미합니다.
\t는 탭 구분자를 의미합니다.
...
가 아닌
사용자가 한눈에 보면서 따라올 수 있게 장표를 구성해 주자.
디자인이 마음에 안 들어도, 없는 거보다 100배는 훨씬 더 좋다고 생각한다.
발표 마음가짐
템포 조절
발표자는 이미 잘 알고 있으니 발표를 준비하고, 발표를 준비하며 더욱 잘 알게 될 것이다.
하지만, 청중들은 처음이다. 이걸 항상 명시해야 한다.
참을 인(忍) 3번을 생각하자. - 忍忍忍...
명령어를 엔터 칠 때도?
1. 입력 전 : 이제... "명령어를 실행해 보겠습니다", 기다려주기
2. 엔터 치기
3. 결과 확인 후 : "이런 결과가 나왔습니다.. 블라블라", 결과 보여주며 얘기하기
내가 하는 모든 행동들에 대해 "다음 화면으로 넘어가겠습니다.", "파일을 저장하겠습니다"
와 같이 알려주자.
페이스 맞추기
발표전에 멘토님이 말씀해 주셨다.
하는 사람이 1/3 도 안될 거예요.
그래도, 몇 명이 열심히 키보드 치는 게 보일 텐데
키보드를 멈출 때까지 기다려주세요.
따라 치는 사람을 파악해서, 타자 소리가 멈출 때까지 대기를 해주자.
그 후, 발표자들을 응시하며 "여기까지 괜찮을까요?" 등으로 페이스 확인을 하며 진행하자.
예상치 못한 상황 대처
발표 중에는 어떤 일이든 발생할 수 있다.
`마이크 배터리가 나갔다`, `온라인 발표가 끊겨 잠시 중지 후 다시 진행`, `리모컨이 동작을 안 한다`
이때, 당황하지 않고 질문을 받거나 아이스 브레이킹을 해나가려고 하자.
잠깐의 해프닝일 뿐이다.
또는
`발표자 사진을 찍기 위해 촬영해 주시는 분이 바로 앞으로 온다던가`, `청중이 전화를 받으러 급하게 나간다던가`, `발표 중 너무 더워서 뒷문을 연다던가`
멈칫은 할 수 있어도, 이런 일 때문에 발표의 페이스를 놓치지 말자.
상호작용은 한번 더 고민하기
발표 중 청중들과 상호작용을 하고 싶은 욕심이 들 수 있다.
예를 들어, 나는 이와 같은 상황을 해보려고 했다.
혹시, 그러면 오픈소스가 첫 PR 이 언제 올라왔을까요?
제가 5명에게 물어볼 건데
맞추는 사람에게 배민 상품권 2만 원을 발표가 끝나고 드리겠습니다.
A : 17년 6월..?
B : 15년 10월...?
네. 아쉽게도 아무도 못 맞추셨습니다.
정답은.. 년.. 월입니다.
계속해서 발표를 진행해 보겠습니다.
멘토님이 웬만하면 이런 상호작용은 하지 않는 게 좋다고 말씀 주셨다.
해피 케이스만 되는 게 아니라, 분위기가 싸해질 수도 있다고 하셨다.
그러면, 발표 시작부터 분위기의 어려움이나 내 멘털에 영향이 가서
그냥 안 하는 게 좋을 거 같다고 말씀 주셨다.
발표 유실력자가 아니라면
자신의 흐름대로 안 되는 경우에도 괜찮을지 생각하고 해 보자.
소프트스킬
몸 움직이지 않기
생각보다, 발표자가 하는 행동들이
청중들의 집중을 이목 시킨다는 것을 발표를 준비하면서, 발표를 보면서 느꼈다.
'레이저 포인터 / 마우스 움직이기'
'다리 떨기'
'불필요한 명령어 치기'
등등 웬만하면 하지 않고, 정자세로 하거나 필요한 행동들만 하자.
본인의 발표 스타일 다듬기
리허설을 하며 받은 내 피드백은 무의식적인 화법이 반복된다는 것이었다.
`그럼, 이제...`, `그러면`라는 말들을 너무 자주 하시는 거 같아요.
이건 하루아침에 어려울 수 있다.
이렇게 발표 스타일을 다듬기 위해서 발표 스크립트를 만드는 것도 좋은 방법이다.
나는 발표 스크립트를 보며, 발표하려니
코드도 치고, 말도 하고, 청중들도 보고, 스크립트로 보랴... 과부하가 올 거 같아서 스크립트는 안 보고 했다.
스크립트를 하나씩 치는 게 힘들다면, 먼저 리허설을 하고 크로버노트를 활용하는 것도 좋을 거 같다.
Hands On Lab
사전 세팅 미리 안내하기
너무 다양한 옵션들에 대해 제공하는 게 아닌 2,3 개의 선택지만 제공하고 자세히 설명하자.
docker, homebrew, linux, git 등의 설치방법이 있다고 할 때
사용자가 알고 싶은 건 다양한 설치방법이 아닌, 내 컴퓨터에 바로 설치가능한 방법 하나다.
청중들에게 미리 고지를 하고, 확인만 하자
생각보다, 발표 시간이 매우 부족하다.
그 부족한 시간에 각각 청중들이 다 설치가 되었는지, 기다려 주는 건 비효율적이다.
(어떤 사람은 2분 만에 설치를 끝낼 수도, 어떤 사람은 10분이 걸려도 설치를 못 끝낼 수도 있다)
미리 설치하라고 안내를 하고, 실습을 진행할 때는 '혹시, 설치 및 세팅 안되신 분들 계실까요?'와 같이 진행하자.
실습 도중에도 장표 잘 활용하기
내용이 복잡하다면, 청중들이 발표를 놓치기 쉽다.
'앞에서 뭐라는 거지..?', '내가 뭘 치고 있는 거지.' 등등
실습 시작 전에는 'tldr'과 같이 뭘 할 건지를 알려주고
실습 시작 후에는 '마무리'를 통해 뭘 배웠는지를 리마인드 해줘야 한다.
추가로, 이런 것까지 설명을 해줘야 하나...? 싶은 내용이 있다.
vi 에디터에서 `:wq` 가 뭔지
source 명령어가 뭔지
이 내용도 모두에게 좋은 발표를 위해선 준비하자. 청중은 잘 모르지만, 흥미를 가지기 위해 왔을 수도 있다.
화면전환 최소화
위 내용을 지키기 위해선 화면을 자주 전환하게 될 수도 있다.
화면을 자주 전환하면, 보는 사람들의 정신이 사나워진다.
정직하게, `장표 - 실습 코드 화면` 두 개로 승부하는 게 좋은 거 같다.
잘 준비한 장표 하나참을 인(忍) 3번
위 발표 마음가짐에서도 작성했지만
다시 한번, 발표자의 속도는 항상 빠르다. 특히, 긴장하면 속도가 더 빨라지는 사람이라면 더욱 주의해야 한다.
짧게 짧게 치기
친 명령어에 대해 설명하기
실행하기
결과 확인
을 의식적으로 지켜나가자.
사소하다면 팁들
체크포인트 잘 지키기
발표 시간이 엄격하게 지켜져야 하는 자리라면
체크포인트를 기반으로 발표를 잘 준비하자.
혹시나, 시간이 어디서 오버되었다면 '이 내용은 스킵해야겠다.', '여기를 조금 더 빨리 해야지' 같이
그냥 발표가 오버되겠다는 막연한 당황함이 아니라, 현명하게 대처할 수 있다.
마지막에 QR로 자기 PR 하기
내가 못해서 아쉬운 점이었다.
단순 발표를 한다면, 링크드인을
Hands On Lab을 한다면, 깃허브를
QR로 띄워서 자신의 팔로워를 늘리는 것도 가능할 것이다.
한 명 만을 위한 발표
발표를 하다 보면, 사용자의 집중력이 떨어져 가는 게 보일 수 있다.
자신이 이런 상황이 의식되고, 긴장이 되기 시작하는 사람이라면
발표를 잘 들어주는 한 명 만을 목적으로 발표를 온전히 집중해서 이끌어나가자.
괜히 모두를 신경 쓰고, 챙기면 이도저도 아니게 될 수 있다.
마무리
내용만 보면, `발표 한번 하는데 왜 이렇게 신경 써야 하는 게 많아..?`라고 생각이 들 수 있다.
사실, 이 모든 건 다 지킬필요 없을 수도 있다.
단, 한 가지만 기억하자.
발표가 마음에 안 들어서, 장표의 퀄리티가 마음에 안 들어서, 두려워서 등
준비에 진전이 없다고 생각할 수 있다.
기간을 잡고, 자기 목표를 정해서 커리큘럼을 따라간다고 생각하자.
3주 전 : 발표 주제 및 대상을 정하기
2주 전 : 리허설용 발표 템플릿 및 내용 초안을 작성
1주 전 : 발표 자료 완료하고, 발표 준비
전날 : 실수하지 않게, 놓치지 않게 체크리스트 및 정비
등등 사실 아쉬운 건 끝도 없을 수 있다.
모든 걸 다 100% 만족하게 할 수 있으면 좋겠지만 그건 어렵다.
60% 라도 완성이 되어있는 발표를 만드는 게 제일 중요하다고 생각한다.
혹여나 발표를 하고 싶다면. 꼭 유스콘을 신청해 보자.
발표 전 체크리스트
환경 설정
Hands On Lab을 할 때 특히나 신경 써야 하는 요소들
배경화면 정리 : 전환할 때 혹여나 보일 수 있으므로, 바탕화면 아이콘 및 파일들 제거
실행 중인 애플리케이션 정리 : 불필요한 변수를 제거하기 위해 발표 관련 앱만 실행하기, 알림 끄기
테마 및 글씨 크기 세팅 : 발표 도중 웬만하면 변경하지 않게 배경색, 글꼴 크기를 미리 세팅
자료 확인
이미지 품질 : 발표장 화면에서도 잘리지 않는지 확인
코드 블록 : 텍스트가 잘리지 않는지 확인
이와같은 이미지는 절대적 금지사전 세팅 안내하기 : 설치 방법 미리 공지
실습 파일 준비 : 예시 파일들 동작하는지 확인
리허설
발표 스크립트 : 말실수해도 따라갈 수 있게 스크립트 준비
시간 체크 : 각 섹션별 체크포인트에 대해 시간 기록
예상 질문 : Q&A 를 진행할 거라면, 3개 정도 미리 답변 준비
