최근에 발표할 일이 많이 있었다. 한때는 블로그만 쓰고 살았지만 어느 순간부터는 종종 발표할 일이 생기면서 종종 발표를 하고 다니게 됐다. 크고 작은 것들이 있지만 발표자료라고 할만한 정도의 것을 만들었던 것을 기준으로 하면 재작년에 6번 정도, 작년에 2번, 올해는 4번을 했다.(올해 이후로 발표를 할일은 없어 보이니...) 엄청 많은 수는 아니지만 그래도 꽤 발표를 하게 되었고 3년전과 비교해 보면 발표스킬도 나름 많이 나이진 것 같다. 최근에 처음 발표하는 분들도 많이 보고 발표에 대한 생각도 다각도로 생각해 보면서 조금 정리를 해본다.

말하기

• 말하기는 정말 많이 해보는 수밖에는 없다. 그냥 해보는 것만으로는 많이 늘지는 않을테고 믿을 만한 사람들을 놀고 발표할 때마다 연습을 해보고 피드백을 받아보고 다른 사람 발표를 볼 때 어떻게 하면 좋은지 자주 생각해 보는 게 좋아 보인다. 나로 말할것 같으면 글은 오래 썼으니 어느 정도 쓰더라도 말로하는 건 어려서부터 정말 자신이 없는 사람이고 긴장감에 특히 약해서 긴장되는 자리에서는 말을 더듬거나 머리가 하얗게 되서 아무 생각도 안나는 편이다.(혹 나를 면접본 사람은 익히알것이다.) 이런 긴장감도 많이 하게 되면 많이 하게되면 괜찮아 지는것 같고 나같은 경우는 이런걸 잘 못하니까 자주 자리를 가졌던 것 같다. 연습하기 좋은 무대는 그룹스터디를 하면서 발표를 하는 거다. 적은 수로 익숙한 사람들 앞에서 발표를 하면서 스킬을 늘리고 긴장감은 많이 해서 익숙해 지는 수밖에 없다.(나랑 오래 친했던 사람들은 2년전 JCO라는 큰 무대에서 발표할 때 내가 얼마나 떨었는지 기억할 꺼라 생각한다.)
• 나는 애드립을 잘 하는 편은 아니다. 그런 쪽으로는 센스가 좋지 못하기 때문에 발표중에 예상치 못한 상황이 생기면(보통 생긴다!) 당황해서 대처를 잘 못하는 편인데 그래서 연습을 많이 하곤 한다. 시간을 재보면서 발표자료와 말할 내용을 맞춰보면서 연습을 하고 연습을 많이 해서 예기치 못한 상황을 최대한 줄이려고 했다. 그래도 예기치 못한 상황은 생기지만 연습을 많이 해두면 대처하기에 좀 나은 것 같다.

• 예상치 못한 상황에 대한 준비는 해놓는 것이 좋다. 발표에는 여러 가지 상황이 있다. 인터넷이 갑자기 안될 수도 있고 라이브 코딩이 있으면 실수가 있을 수 있다. 인터넷을 할 수 있는 백업장비를 준비한다거나 인터넷이 안될때를 대비해서 스크린샷이라도 떠놓는다던지 해서 예상할 수 있는 상황에 대한 대안을 준비해 놓는 것이 좋다. 청중입장에서는 어떤 의외의 상황이든 발표자가 어리버리하고 있는건 보기에 좋지 않다. 그리고 라이브코딩을 한다면 완성된 예제코드나 복사해서 사용할 수 있는 코드 혹은 미리 스크린캐스트를 찍어놔서 잘못되었을 때 대안으로 설명할 수 있는 걸 준비해 주는 것이 좋다. 그리고 발표자료도 혹 모르니 클라우드 스토리지 같은데 올려두면 좋다.(재작년인가 발표를 몇일 앞두고 맥북 메인보드가 나가서 수리를 맡긴 관계로 남의 노트북으로 발표를 해야했다.)
• 시간은 정확하게 맞추면 좋다. 질문이나 돌발상황이 있을 수 있고 조금 빨리 발표끝냈다고 뭐라하는 사람은 없으니 총 발표시간의 5분정도 적게 잡아서 준비해도 좋다. 다만 긴장을 하면 말이 빨라질 수 있고 연습을 많이 하다 보면 연습때는 시간을 딱 맞췄지만 실제 할때는 할말이 대사처럼 정해져 있다보니(중간에 생각하는 시간이 적어지므로) 예상시간보다 더 빨리 끝나버릴 수 있다. 소제목단위로 몇분 정도에 끝나야 하는지 기억하고 있으면 현재 내가 빨리 진행되고 있는지 아니면 너무 느려져서 좀더 빨리 해야하는지 중간중간 확인할 수 있다.
• 발표준비를 하다보면 개그 욕심이 좀 나는데 나는 왠만하면 잘 안하는 편이다. 발표에 유머가 잘 섞이면 듣는 입장에서는 정말 편하게 들을 수 있지만 나는 평소에 유머센스가 그리 좋은 편이 아니기 때문에 무리해서 웃길려고 노력하지 않는다. 그리고 몇번해보니 내가 의도했던 웃음 포인트에서는 오히려 잘 웃지 않고 웃으라고 했는데 안웃으니까 당황해서 더 안좋더라는... 그냥 이미지나 메시지 같은데서 적당히 웃겨도 좋고 안웃겨도 좋은 정도로 하는 편이고 편하게 하다보면 오히려 잘 웃어주는 경우가 많았다.
  
  

발표자료

• 자기소개: 난 이력에 거창하게 자랑같은 얘기를 막 적는걸 별로 안좋아하는 편이라 그동안은 발표자료에 자기소개를 잘 안넣었다. 하지만 발표자료에 신뢰성을 높히기 위해서 혹은 어떤 배경을 가진 사람인지 약간 아는 것이 발표내용을 듣는데도 좋을 꺼라는 생각에 최근에는 자기소개를 넣기 시작했다. 여전히 누군지 보다는 어떤 내용을 어떻게 설명하냐가 더 중요하다기 보기에 자기소개에 많은 시간을 할애하진 않는다.
• 목차: 목차는 넣는 것이 좋아 보인다. 나도 잘 안넣다가 최근에는 넣으려고 하는 편인데 청중들이 미리 어떤 얘기를 할지 예상하고 현재 어느 부분을 설명하고 있는지 예상할 수 있다는 장점이 있다. 어떤 발표자료는 장표마다 현재 전체 발표목차에서 어느 부분인지를 보여주는 인덱스를 추가한 것도 본적이 있는데 발표자료를 보는데 거슬리지 않는 정도에서 괜찮다 보인다.
• 나는 키노트를 사용한다. 발표를 시작했을 무렵에는 맥을 쓰기 시작했으므로 처음부터 키노트를 썼는데 키노트를 써보고 파워포인트가 얼마나 형편없는지 알게되었다. 파워포인트로도 발표자료를 못 만드는 것은 당연히 아니겠지만 라인 맞추기 등 키노트가 나은 점들이 있다고 본다. 하지만 파워포인트를 써본지가 너무 오래됐기 때문에 객관적인 비교는 아니므로 자기가 쓰기 편한 도구를 쓰면 된다.
  
  
  • 참고로 HTML5 슬라이드(reveal.js같은)는 거의 쓰지 않는다. 처음에 구글에서 HTML5 슬라이드를 공개했을 때는 너무 인상적이라 몇번 시도했지만 몇번 써본 결과 발표자료를 만드는데 불필요한 HTML 불필요한 HTML등을 다루는데 너무 시간이 많이 들어서 사용하지 않는다. 지금은 좋은 도구들이 많이 나오긴 했지만 여전히 슬라이드 전용도구에 비해서는 너무 간단하거나 손이 많이 간다. 발표자료는 원하는 내용을 보기 편하게 제공해야한다고 생각하기에 HTML5 슬라이드는 사용하지 않는다.(구글 Docs류도 마찬가지다.) 이쁘게 꾸밀 필요는 없고 간단하게 발표할 때는 종종 쓰기는 한다.
  • 내가 HTML5 슬라이드를 고려하는 경우라면 웹 프론트앤드쪽 발표를 하게 되서 발표자료안에 예제를 바로 시연할 수 있도록 구성할 수 있는 경우에만 고려할 것이다. 사실 키노트로 발표하다가 시연을 위해서 창을 바꿨다 돌아왔다 하는 것이 보기는 좋지 않으므로 예제를 발표자료와 잘 섞을 수 있는 경우가 HTML5 슬라이드의 장점이 가장 잘 부각되는 경우라고 생각한다.
• 영문은 최대한 쓰지 않는다.: IT쪽이나 기술발표를 위주로 많이 하다보니 영문이 많이 있고 발표자료를 만들다 보면 솔직히 영문으로 쓰는게 훨씬 이쁘게 꾸밀 수 있는 경우가 많다.(이는 영어라서 이쁘게 보인다는 착각을 얘기하는게 아니라 타이포그라피자체가 한글보다 영어가 훨씬 발달했기 때문이다.) 예전에는 영어를 많이 쓰기도 했지만(문법에 오류있으면 창피하기도 하고) 지금은 거의 안쓴다. 발표를 듣는 사람이 대부분 한국 사람이므로 아무리 쉬운 영어라고 하더라도 읽고 받아들이는데 무조건 한글이 좋다. 메서드 이름이나 꼭 영어로 써야 하는 경우가 아니면 무조건 한글로 바꾼다. 개인적으로는 한국사람도 한번에 읽을 수 있는 2단어 혹은 좀 익숙한 말이면 3단어 정도까지가 한계라고 생각하고 그 이상이 되면 모두 한글로 변환한다. 인용하는 경우에도 한글로 보여주고 원문 링크등을 넣는 것이 차라리 낫다.

• 나는 발표자료에 중요 메시지만 넣는걸 선호한다. 그래서 내 발표자료는 나중에 발표자료만 보면 무슨 내용인지 알기가 좀 어려운 편이다. 내 발표 스타일은 가르 레이놀즈의 프리젠테이션 젠 시리즈(프리젠테이션 젠, 프리젠테이션 젠 디자인)의 영향을 많이 받았는데 이 책중에 발표자료는 발표자의 내용과 함께 있을때 완성되어야 하고 발표자료만 보고 무슨 내용인지 알 수 있다면 그냥 발표자료를 배포하면 되지 머하러 발표를 하느냐?라는 얘기가 나오는데 여기에 무척 공감을 하기 때문이다. 발표와 블로그에 글을 올리는 것은 다르다. 기술발표를 하면 기술등을 나중에 참고할 수 있게 발표자료에 넣기는 하지만(링크같은 경우는 나중에 참고할 수 있게 작게 넣는다. 발표중에 URL을 자세히 볼필요는 없으므로...) 발표자료 자체는 발표를 돕기 위한 도구일 뿐이다. 정 필요하다면 나중에 따로 글을 올리거나 설명을 해서 읽어 볼 수 있게 하는 것이 최고일 것이다.(그런 면에서 과거 KTH의 H3컨퍼런스에서 발표주제에 대한 설명을 묶어서 책으로 배포한 경우가 아주 좋은 예라고 생각한다.)
• 주로 이미지를 전체 배경으로 넣는다. 발표자료는 당연히 내용이 가장 중요하지만 디자인도 중요하다. 보기좋은 떡이 먹기도 좋다. 이쁘기만 하고 내용이 빈약하면 필요없겠지만 내용이 좋다면 보기 좋은 것이 더 좋다. 배경이미지를 넣는 것도 프리젠테이션 젠 시리즈에서 배운 것인데 이미지를 처음에 넣으면 이미지의 테두리가 다 보이게 화면에 작게 넣는 경우가 많게 되면데 전체 배경으로 깔거나 테두리 없는 이미지를 넣으면 보기가 훨씬 좋다. 전에는 성공이라는 메시지를 얘기한다면 Success라는 이미지를 찾아서 배경으로 깔았는데 최근에는 이렇게 하면 보기에 좀 이쁜 것 말고는 무슨 의미가 있겠는가 싶어서 이미지가 메시지를 상징할 수 있는 것으로 찾으려고 노력하고 있다. 배경이미지도 메시지를 쉽게 이해하고 받아들일 수 있도록 돕는 역할을 하는 것이므로...
  
  
  • 이미지를 찾을 때는 메시지를 잘 표현하는 이미지를 찾으면서 동시에 글씨를 넣을 수 있는 경우도 고려해서 찾는 편이다. 그래서 발표자료를 만들때 이미지를 찾는데 시간이 엄청나게 걸린다.
  • 이미지는 맘에 들었는데 글씨가 눈에 잘 안띈다면 흰색 혹은 검은색 배경을 글씨뒤에 살짝 넣어서 글씨가 잘 보이도록 한다. 이미지 배경에 겹쳐서 글자가 잘 안보이는 것은 정말 좋지 않으므로 그림을 가리더라도 배경을 살짝 깔면 좋고 약간 50~70%정도 투명도를 줘도 상당히 괜찮다.
  • 이미지는 iStock같은 곳이 퀄리티는 좋지만 유료이므로(발표자체가 무료인 경우가 많으므로 ㅠㅠ) 나는 주로 Flickr를 사용한다.
  • 이미지를 찾을때는 저작권을 많이 신경쓰는 편이다. 남의 작품을 맘대로 갔다 쓸 수는 없으므로 주로 검색 옵션에 CCL을 걸어서 조건에 맞는 저작권내에서만 사용하는 편이다. 간혹 안될때는 그냥 쓰는 경우도 있는데 대부분은 절대 저작권이 없거나 저작권을 확인할 수 없을것 같은 짤방일 경우뿐이다. 저작권자가 확실한 경우에는 메일을 보내서 허락을 득하는 것도 좋은 방법이다. 구글 이미지검색에도 라이센스 옵션을 걸어서 검색할 수 있는데 한글로 검색하는 경우에는 별로 믿지 않는 것이 좋다. 여러 사이트에서 CCL 이미지만 검색하는 CC Search같은 사이트도 있다.
  • CCL을 사용한 경우 보통 저작권자 표시는 기본적으로 포함되는데 (라이센스는 항상 어렵기에) 어떻게 표시해야 하는가?에 대해서는 나도 고민이 참 많다. 전에는 마지막 장에 리소스라고 넣어서 발표자료에 사용한 이미지의 원본 URL을 목차처럼 넣고는 했는데 이럴 경우 이미지 변경하고 할 때 관리가 너무 쉽지 않아서 요즘은 각 장표의 하단에 작게 원본 URL을 넣어서 출처를 밝히는 편이다.
• 코드는 신텍스 하일라이트를 준다. 개발관련 주제가 많으므로 코드가 들어가는 경우가 많이 있는데 보통 신텍스 하일라이트를 주는 편이다. 대부분의 개발자가 에디터에서 이렇게 사용하므로 그냥 코드를 넣은 것보다 훨씬 보기도 좋고 이쁘다. 경험상 맥에서는 이클립스에서 특정 테마를 적용한 뒤에 키노트로 복사하면 그 스타일을 그대로 입힐 수 있다. 하지만 난 이렇게 하지 않고 보통 하나하나 선택해서 일일이 색깍을 입힌다. 사실 무척 귀찮고 피곤한 일이긴 하지만 보는 사람이 훨씬 보기 좋고 신텍스 하일라이트는 보통 색이 아주 다양하게 적용되는데 발표자료에서는 코드의 일부만 보여주는 경우가 많으므로 색이 너무 다양하게 적용되면 오히려 보기가 좋지 않아보여서 IDE에서 적당한 테마를 고른뒤에 일부 색상만 적용해서 하일라이트를 입힌다. 코드를 보여주면 어쩔 수 없이 대량의 코드가 필요한 경우가 있는데 너무 많으면 어차피 보는 사람이 이해하기가 어려우므로 최대한 핵심부분만 보여주고 따로 예제코드를 나중에 볼 수 있게 제공하는 것이 낫다.(물론 이렇게 할 수 없는 경우도 당연히 있다.)
• 애니메이션은 거의 쓰지 않는다. 애니메이션을 쓰지 않는 이유는 이게 고난이도 기술이기 때문에 아주 잘 쓰지 않으면 오히려 안좋다고 생각하기 때문이다. 애니메이션이 자연스럽게 잘 쓰지 않으면 오히려 거추장스럽게 느껴지고 청중들이 애니메이션에 시선을 빼앗긴다고 생각하는 편이고 이는 발표내용을 전달하는데 그다지 도움이 안된다고 생각한다.(화려함에 신기해 할 수 있지만 뭐 그뿐이다.) 애니메이션이 이야기 전달에 도움이 되도록 해야 하는데 난 아직 그정도 스킬이 없으므로 쓰지 않는다. 그래서 동일한 이유로 Prezi를 좋아하지 않는다. 취향에 따라 다르겠지만 글자사이에 오가면서 화면이 회전되고 줌인/아웃이 되는게 발표를 듣는데 무슨 도움이 되는지 잘 모르겠다.(물론 Prezi를 잘 살려서 애니메이션 자체가 이야기의 흐름을 잘 타도록 만든 경우도 본 적이 있지만 난 그정도 스킬이 없고 내가 본 대부분의 Prezi발표자료도 그냥 화려한 애니메이션만 마구 넣었을 뿐이었다.)
• 발표끝나고 공유는 여러 가지 방법이 있는데 웹으로 만든 발표자료가 아니라면 대표적으로 slideshare와 Speaker Deck이 있다. 드랍박스나 다른 파일공유서비스로 공유할 수도 있지만 장기적으로 사람들이 볼려면 이런 서비스가 제일 좋다. 키노트로 사용한 경우에는 한글같은 폰트가 깨지는 경우가 많으므로 PDF로 내보내기를 한 뒤에 업로드를 하며 깨지지 않는다. 사실 발표자료는 이런 서비스에서 좋은 발표자료를 많이 보는 것도 꽤 많은 도움이 된다.
  
  

주의사항

• 폰트 사이즈에 신경써야 한다. 의외로 발표자료를 보면 폰트사이즈가 작은 경우가 너무 많다. 발표장소에 따라 다르지만 큰 장소라면 뒤에서도 잘 보이는지 신경을 많이 써야 한다. 난 절대 작아서 안보인다는 말이 나오지 않게 대빵만하게 70~90 포인트의 폰트를 선호하는 편이다. 발표 준강에 잘 안보여요라고 사람들이 말해주면 좋지만 청중들은 잘 그러지 않으므로 발표자가 미리 신경써야 한다. 특히 라이브 코딩이나 콘솔로 데모하는 경우에도 폰트크기를 뒤에서도 잘 보이도록 키워주어야 한다.
• 하단 10%정도는 사용하지 않는다. 발표하는 곳이 청중들보다 높은 곳에 있다면 좋겠지만 그렇지 않은 곳이 대부분이다. 뒤에 앉은 사람은 앞의 사람 들 때문에 발표자료의 하단부분은 잘 보이지 않으므로 하단부는 중요한 내용들을 넣지 않는 것이 좋다. 밑부분은 약간 공백을 두어도 좋다.
• 글씨나 배경이 명도/채도가 비슷하지 않도록 주의해야 한다. 사실 요즘은 모니터들이 다 좋아서 약간만 명도/채도가 달라도 비슷해 보이지만 대부분의 발표는 빔 프로젝터를 이용해서 한다. 좋은 빔 프로젝트라면 아주 잘 나오지만 대부분은 그렇게 고급 빔 프로젝터가 아니므로 내 모니터에서는 잘 보였지만 막상 발표하러 가보니 색이 흐려서 구분이 잘 안되는 경우가 많다. 그래서 명도/채도가 많이 차이나게 배색해야 발표당일날 이런 문제를 줄일 수 있다.
• 질문 : Q&A 시간에 질문을 받으면 질문을 다시 얘기해주는 것이 좋아보인다.(이건 나도 잘 안되는데...) 보통 질문자는 마이크가 없는 경우가 더 많기 때문에 발표자만 질문을 듣고 대답하면 사람들은 질문내용이 뭔지 모르는 경우가 많다.
  
  

마지막으로 내가 맨 처음 공개적으로 발표를 할 때 "어차피 발표끝나도 아무도 말을 안해줘서 잘 했는지 안했는지 모르니까 맘 편히해"라는 말을 들었는데 사실이다. 세미나 많이 가본 사람은 알겠지만 보통 청중이 큰 반응이 없고 끝나고 피드백을 주는 경우도 없다. 누가 후기라도 올려주면 욕이든 칭찬이든 감사할 따름이다. 발표자가 피드백을 받을 수 있는 다양한 방법을 연구해서 피드백을 받도록 하는 것도 다음 발표에 도움이 된다.

그리고 내가 세미나의 주최측의 일원이 될 경우에는 대부분 발표 리허설을 진행했었다. 발표 리허설의 경우는 커뮤니티내의 사람들이나 준비하는 사람들 위주로 진행했는데 경험상 발표준비가 어느 정도 수준이든간에(아주 부족하거나 상당한 퀄리티로 준비했거나) 무조건 리허설 전보다 수준이 올라간다. 일단 듣는 사람들이 친분이 있는 경우가 많고 리허설의 목표도 부족한 부분에 대한 의견제시이므로(모두 받아들일 필요는 없다) 꽤 양질의 피드백을 받을 수 있고 듣는 입장에서 어떻게 들리고 어떤 생각 혹은 궁금증이 생기는지 들을 수 있다. 이런 자리를 활용하면 발표 수준을 높힐 수 있고 여러 트랙이 아닌 한 트랙으로 진행하는 경우에는 다른 발표자가 어떤 내용을 설명하는지 알게 되는 것도 발표내용을 조정하는데 상당히 도움이 된다.