프리젠테이션, 프리젠테이션 젠
분류없음 2008/10/09 02:58 Tuna님의 글에서도 지적된 바 있지만, 올해 프리젠테이션 젠의 인기는 상당했다. 올해 다녀본 여러 세미나들에서 그 영향을 실감할 수 있었다.
프리젠테이션 젠과 프리젠테이션 스타일
얼마전, 프리젠테이션을 준비할 일이 있어서 이 책에서 말한 스타일 - 가르침은 안드로메다 보내고 - 대로 작성을 해보았는데, 40여 페이지 중 중간쯤을 넘어가니 뭔가 아니란 생각이 들었다. 그래도 당시엔 일단 밀어붙여서 해놓고 보자는 생각에 끝까지 그 형식을 유지했다. 돌이켜봐도 유치찬란하기 짝이 없는 PT였다.
프리젠테이션 젠의 키 메시지는, 키 메시지를 전달하는데 집중하자쯤으로 정리할 수 있다. 핵심 주제, 모든 프리젠테이션에 핵심 주제가 존재하던가? 제목은 있을지 몰라도 '키 메시지'라는 말이 적합한 프리젠테이션은 그리 많지 않다. 키 메시지가 존재하는 프리젠테이션은 주로 조직의 장들에게 (그것도 꽤 상층부의) 하거나, 혹은 갑에게 하게 된다.
프리젠테이션의 유형
훨씬 많은 젊은 개발자들이 해야 할 프리젠테이션의 유형은 '기술소개와 요약 전달'이다. 키 메시지를 찾는 것이 부적절한 유형이지만, 여기서 굳이 키 메시지를 추출해내자면 '이러이러한 점이 좋으니까 이걸 쓰자'의 형태가 주를 이룰 것이다. 그러나 이걸 키 메시지라 하기는 곤란하다. 정말 '이러이러한 점이 좋으니까 이걸 쓰자'가 키 메시지라면 내용은 갑에게 하는 프리젠테이션의 형태를 띠어야 하기 때문이다. 그러나 그 프리젠테이션의 관객은 갑이 아니라 같은 개발자인 경우가 더 많고, 그들의 관심사는 갑의 관심사와는 약간 거리가 있기 때문이다. 물론 개발자들도 당연히 TCO라던가 하는 - 주로 그래프로 나타나는 - 측면의 내용도 알아야 한다. 그러나 그것 말고도 더 많은 이야기를 해야 한다. 일반적으로 세세한 아키텍처나, 적용 케이스에 대한 이야기까지 필요로 한다.
있어 보이려고 이미지를 매 배경마다 깔아댄다거나 하는 것은 오히려 사람을 산만하게 만든다. 말 한 두 마디로 넘어갈 수 있는 것은 차라리 말로만 설명하고 넘어가는 게 낫다. 시각 메시지라는 건 생각 이상으로 강렬한 것이라서, 사람은 반드시 거기에 주의를 기울이게 되어 있다. 사람이 글자를 읽느라 발표자의 말을 흘려듣는 일이 없게 하려면 글자를 줄여야 한다는 프리젠테이션 젠의 가르침은, 아이러니하게도 그 주의를 되찾아 배경 이미지에게 줘버리는 양상으로 나타나곤 한다.
차라리 7줄 내외로 정리된 텍스트는 발표자의 말은 흘려들을지언정 사람들이 발표 주제에서 벗어나게 하지는 않는다. 그러나 본문과 긴밀하게 관계지어지지 않은 배경은 사람들을 아예 발표 주제로부터 탈선시키는 훌륭한 부수 효과를 가져온다. 프리젠테이션 젠에서 주의를 분산시킬 수 있다는 이유로 사용을 권장하지 않은 템플릿 및 매 페이지마다의 로고는 사실 그다지 사람들의 주의를 끌지 못한다. 템플릿이 구리면 전체 발표의 품질이 좀 구려보이는 역효과만 주의하면 되는 정도다.
우선 누가 드라이브할 것인가 - 이것이 중요하다. 슬라이드가 발표를 주도하는 것과, 발표자가 발표를 주도하는 것은 하늘과 땅 차이다. 구성, 양식, 말의 양, 상호작용의 방법까지 모두 달라야 한다. 어느 것이 나은 건 아니다. 주로 갑에게 하는 발표는 발표자 주도에 더 가깝고, 기술 전달은 슬라이드 주도에 더 가깝다. 이중 기술 전달 프리젠테이션에 대해 생각해보거나 경험해본 바를 적어보고자 한다.
기술 전달 프리젠테이션
슬라이드를 또 한 사람으로 가정하면 이야기가 쉽다. 이야기는 주거니 받거니 하면서 주제에서 벗어나면 안된다. 슬라이드가 많이 말하든, 발표자가 많이 말하든 그건 중요한 게 아니다. 중요한 건 전달이 잘 되느냐이다. 개인적 동기, 경험, 관점, 감정... 이런 것들은 발표자가 전달하기에 적절하다. 반면, 슬라이드가 전달하기 적합한 것은 시각화된 데이터, 아키텍처, 인터렉션... 이러한 것들이 있다.
특히 아키텍처에 대한 상세한 설명을 할 때는 적극적으로 애니메이션을 활용하는 것이 좋다. TCP/IP를 설명하는 예를 들자면, 패킷이 매 계층마다 캡슐화되는 것을 제아무리 말로 떠들거나 그림으로 그려가면서 이야기하는 것보다 두개의 스택 사이에서 움직이는 하나의 패킷을 묘사한 애니메이션이 훨씬 수월하다.
효과를 적절히 사용한 또 하나의 예는, 아키텍처 전체 레이어중 특정 부분을 집중해서 설명할 때 나머지 부분을 어둡게 처리하는 것이다. 주목과 집중을 위해서이다. 매우 기본적임에도 불구하고 의외로 소홀히 하는 경우가 많다.
나열하는 항목이 있고, 그 하나하나를 일정 시간동안 설명해야 한다면 나머지를 효과를 주어 필요할때마다 나타나게 하는 것도 기본적인 구성 중 하나이다. 요는 '현재 하고 있는 이야기에 집중하게 하는 것'이다. 그럼 이 경우에 왜 페이지를 분할하지 않고 나열을 하는가? 다른 페이지에 쓰면 되지 않는가? 물론 그래도 된다. 하지만 점진적 전개인 경우 이러한 전달이 훨씬 이해하기 쉽다.
결국 프리젠테이션은 가상 청중의 인지를 상상하며 구성해야 한다는 것이다. 내가 이 프리젠테이션의 청중이라면 어떻게 느낄까, 그것을 상상할 수 있는 능력은 매우 중요하다. (분야를 막론하고 이 능력이 안 중요한 곳은 없다)
또 하나, 코딩을 해야 하는 경우라면, 코딩을 직접 하는 것이 더 유리할 수 있다. 발표자에게는 쓸데없이 낭비하는 시간이라고 생각될 수 있지만, 청중 입장에서 열댓줄의 코드가 눈앞을 스쳐 지나가고 실행이 되는 모습은 일종의 시각적 자극 이상은 아무것도 아닐 수 있다. 이 경우에 청중은 멀찌감치 떨어져 눈앞의 '쇼'의 관람자가 되지만, 코딩이 적절한 속도로 이루어질 경우 청중은 뇌 속으로 페어 프로그래밍을 시작한다. 청중이 지루하지 않게, 그러나 생각해야 할 부분에서는 충분히 시간을 가지고 몰입할 수 있을만큼, 딱 적당한 정도의 코딩 시간이 필요하다.
좋은 프리젠테이션
모든 프리젠테이션의 목표가 같을 수는 없다. 같을 리도 없다. 그 목표를 위해 적절한 방법을 선택하는 것은 매우 중요하다. 십여년 전에도 이미 '잘 된 프리젠테이션'을 아주 드물지는 않게 접해왔다. 그 프리젠테이션이 배경과 효과와 7단어 규칙 따위를 잘 지켜서 잘 된 프리젠테이션이었던 것은 아니다. 전달하고자 하는 내용에 따른 전달 방식의 최적화, 거기서 모든 좋은 프리젠테이션이 출발한다. 그것은 프리젠테이션 젠 이전에도 그랬고, 그 이후에도 마찬가지다.
프리젠테이션 젠과 프리젠테이션 스타일
얼마전, 프리젠테이션을 준비할 일이 있어서 이 책에서 말한 스타일 - 가르침은 안드로메다 보내고 - 대로 작성을 해보았는데, 40여 페이지 중 중간쯤을 넘어가니 뭔가 아니란 생각이 들었다. 그래도 당시엔 일단 밀어붙여서 해놓고 보자는 생각에 끝까지 그 형식을 유지했다. 돌이켜봐도 유치찬란하기 짝이 없는 PT였다.
프리젠테이션 젠의 키 메시지는, 키 메시지를 전달하는데 집중하자쯤으로 정리할 수 있다. 핵심 주제, 모든 프리젠테이션에 핵심 주제가 존재하던가? 제목은 있을지 몰라도 '키 메시지'라는 말이 적합한 프리젠테이션은 그리 많지 않다. 키 메시지가 존재하는 프리젠테이션은 주로 조직의 장들에게 (그것도 꽤 상층부의) 하거나, 혹은 갑에게 하게 된다.
프리젠테이션의 유형
훨씬 많은 젊은 개발자들이 해야 할 프리젠테이션의 유형은 '기술소개와 요약 전달'이다. 키 메시지를 찾는 것이 부적절한 유형이지만, 여기서 굳이 키 메시지를 추출해내자면 '이러이러한 점이 좋으니까 이걸 쓰자'의 형태가 주를 이룰 것이다. 그러나 이걸 키 메시지라 하기는 곤란하다. 정말 '이러이러한 점이 좋으니까 이걸 쓰자'가 키 메시지라면 내용은 갑에게 하는 프리젠테이션의 형태를 띠어야 하기 때문이다. 그러나 그 프리젠테이션의 관객은 갑이 아니라 같은 개발자인 경우가 더 많고, 그들의 관심사는 갑의 관심사와는 약간 거리가 있기 때문이다. 물론 개발자들도 당연히 TCO라던가 하는 - 주로 그래프로 나타나는 - 측면의 내용도 알아야 한다. 그러나 그것 말고도 더 많은 이야기를 해야 한다. 일반적으로 세세한 아키텍처나, 적용 케이스에 대한 이야기까지 필요로 한다.
있어 보이려고 이미지를 매 배경마다 깔아댄다거나 하는 것은 오히려 사람을 산만하게 만든다. 말 한 두 마디로 넘어갈 수 있는 것은 차라리 말로만 설명하고 넘어가는 게 낫다. 시각 메시지라는 건 생각 이상으로 강렬한 것이라서, 사람은 반드시 거기에 주의를 기울이게 되어 있다. 사람이 글자를 읽느라 발표자의 말을 흘려듣는 일이 없게 하려면 글자를 줄여야 한다는 프리젠테이션 젠의 가르침은, 아이러니하게도 그 주의를 되찾아 배경 이미지에게 줘버리는 양상으로 나타나곤 한다.
차라리 7줄 내외로 정리된 텍스트는 발표자의 말은 흘려들을지언정 사람들이 발표 주제에서 벗어나게 하지는 않는다. 그러나 본문과 긴밀하게 관계지어지지 않은 배경은 사람들을 아예 발표 주제로부터 탈선시키는 훌륭한 부수 효과를 가져온다. 프리젠테이션 젠에서 주의를 분산시킬 수 있다는 이유로 사용을 권장하지 않은 템플릿 및 매 페이지마다의 로고는 사실 그다지 사람들의 주의를 끌지 못한다. 템플릿이 구리면 전체 발표의 품질이 좀 구려보이는 역효과만 주의하면 되는 정도다.
우선 누가 드라이브할 것인가 - 이것이 중요하다. 슬라이드가 발표를 주도하는 것과, 발표자가 발표를 주도하는 것은 하늘과 땅 차이다. 구성, 양식, 말의 양, 상호작용의 방법까지 모두 달라야 한다. 어느 것이 나은 건 아니다. 주로 갑에게 하는 발표는 발표자 주도에 더 가깝고, 기술 전달은 슬라이드 주도에 더 가깝다. 이중 기술 전달 프리젠테이션에 대해 생각해보거나 경험해본 바를 적어보고자 한다.
기술 전달 프리젠테이션
슬라이드를 또 한 사람으로 가정하면 이야기가 쉽다. 이야기는 주거니 받거니 하면서 주제에서 벗어나면 안된다. 슬라이드가 많이 말하든, 발표자가 많이 말하든 그건 중요한 게 아니다. 중요한 건 전달이 잘 되느냐이다. 개인적 동기, 경험, 관점, 감정... 이런 것들은 발표자가 전달하기에 적절하다. 반면, 슬라이드가 전달하기 적합한 것은 시각화된 데이터, 아키텍처, 인터렉션... 이러한 것들이 있다.
특히 아키텍처에 대한 상세한 설명을 할 때는 적극적으로 애니메이션을 활용하는 것이 좋다. TCP/IP를 설명하는 예를 들자면, 패킷이 매 계층마다 캡슐화되는 것을 제아무리 말로 떠들거나 그림으로 그려가면서 이야기하는 것보다 두개의 스택 사이에서 움직이는 하나의 패킷을 묘사한 애니메이션이 훨씬 수월하다.
효과를 적절히 사용한 또 하나의 예는, 아키텍처 전체 레이어중 특정 부분을 집중해서 설명할 때 나머지 부분을 어둡게 처리하는 것이다. 주목과 집중을 위해서이다. 매우 기본적임에도 불구하고 의외로 소홀히 하는 경우가 많다.
나열하는 항목이 있고, 그 하나하나를 일정 시간동안 설명해야 한다면 나머지를 효과를 주어 필요할때마다 나타나게 하는 것도 기본적인 구성 중 하나이다. 요는 '현재 하고 있는 이야기에 집중하게 하는 것'이다. 그럼 이 경우에 왜 페이지를 분할하지 않고 나열을 하는가? 다른 페이지에 쓰면 되지 않는가? 물론 그래도 된다. 하지만 점진적 전개인 경우 이러한 전달이 훨씬 이해하기 쉽다.
결국 프리젠테이션은 가상 청중의 인지를 상상하며 구성해야 한다는 것이다. 내가 이 프리젠테이션의 청중이라면 어떻게 느낄까, 그것을 상상할 수 있는 능력은 매우 중요하다. (분야를 막론하고 이 능력이 안 중요한 곳은 없다)
또 하나, 코딩을 해야 하는 경우라면, 코딩을 직접 하는 것이 더 유리할 수 있다. 발표자에게는 쓸데없이 낭비하는 시간이라고 생각될 수 있지만, 청중 입장에서 열댓줄의 코드가 눈앞을 스쳐 지나가고 실행이 되는 모습은 일종의 시각적 자극 이상은 아무것도 아닐 수 있다. 이 경우에 청중은 멀찌감치 떨어져 눈앞의 '쇼'의 관람자가 되지만, 코딩이 적절한 속도로 이루어질 경우 청중은 뇌 속으로 페어 프로그래밍을 시작한다. 청중이 지루하지 않게, 그러나 생각해야 할 부분에서는 충분히 시간을 가지고 몰입할 수 있을만큼, 딱 적당한 정도의 코딩 시간이 필요하다.
좋은 프리젠테이션
모든 프리젠테이션의 목표가 같을 수는 없다. 같을 리도 없다. 그 목표를 위해 적절한 방법을 선택하는 것은 매우 중요하다. 십여년 전에도 이미 '잘 된 프리젠테이션'을 아주 드물지는 않게 접해왔다. 그 프리젠테이션이 배경과 효과와 7단어 규칙 따위를 잘 지켜서 잘 된 프리젠테이션이었던 것은 아니다. 전달하고자 하는 내용에 따른 전달 방식의 최적화, 거기서 모든 좋은 프리젠테이션이 출발한다. 그것은 프리젠테이션 젠 이전에도 그랬고, 그 이후에도 마찬가지다.
