2018.06.25

“경영진 앞에서 떨지 말 것” 개발자를 위한 프레젠테이션 성공 법칙

Andrew C. Oliver | InfoWorld
경영진을 상대로 프레젠테이션을 하는 것은 다른 기술 전문가들에게 프레젠테이션 하는 것과는 다르다. 오히려, 좋은 글쓰기를 위해 지켜야 할 것과 겹치는 부분이 많다. 청중을 염두에 둔 프레젠테이션을 할 것, 핵심 포인트를 생각하며 말할 것, 간략하고 명확하게 의견을 전달할 것 등이 요점이다. 경영자에게 프레젠테이션을 할 때는 당신이 상대하는 청중이 매우 바쁜 사람들이라는 것, 그리고 프로젝트의 영향력과 비용, 수반되는 위험 등을 알고자 하지 구체적인 세부 사항을 궁금해하는 것은 아니라는 것(그런 디테일을 세세히 알고 관리하라고 당신을 뽑은 것이다) 등을 기억해야 한다. 또 그들은 당신이 이 계획을 철저하게 계획했는지, 대안은 마련했는지, 충분한 사전 조사가 이루어졌는지를(물론 여기서도 그 여부만을 궁금해 할 뿐 디테일은 알고 싶어하지 않는다) 알고자 한다.

그렇다면 경영자에게 프레젠테이션을 할 때는 구체적으로 어떤 원칙을 지켜야 할까? 개발자와 엔지니어의 성공적인 프레젠테이션을 위한 튜토리얼을 소개한다.

경영자란 어떤 사람인가?
여러분의 청중이 경영자인지 아닌지를 판단하기 위해서는 우선 경영자가 어떤 이를 의미하는지 알아야 할 것이다.

논란의 여지는 있지만, 직함에 ‘매니저’나 ‘디렉터’가 달려있다고 해서 다 경영자는 아니다. 은행이나 금융기관에서 일하는 사람이라면 ‘VP’라는 타이틀을 달았다고 모두 경영자는 아니라는 걸 알 것이다. 심지어 일부 C레벨 인사들(CEO, CFO 등)도 경영자가 아닐 수 있다. 이제는 심각한 ‘타이틀 인플레이션’ 때문에 타이틀만 보고는 유의미한 정보를 얻기 힘들어졌다.

이 글에서 ‘경영자’라고 일컫는 이들은 쉽게 말해 자금을 운용하고 할당, 배분할 수 있는 권한을 지닌 사람을 지칭한다. 때로는 직접적인 권한은 없지만, 실질적으로 업무를 수행하는 낮은 직위 또는 중간 직위의 중간 관리자가 있을 수도 있다. 경영자에게 프레젠테이션을 한다는 것은 결국 어떤 프로젝트에 대한 재정적 혹은 비즈니스 전략적 의사 결정을 내리는 일이기 때문이다.

프레젠테이션의 목적은 무엇인가
우선 경영진에게 프레젠테이션을 하고 있는 이유에 대해 생각해 보자.

- 프로젝트에 요구되는 자원을 요구하기 위해서일 경우 : 경영진은 프로젝트의 비용/장점과, 수반되는 위험을 알고자 한다.
- 비즈니스에 핵심적인 기능을 하는 프로젝트나 서비스가 예상 또는 예정 경로를 벗어난 경우, 또는 예산을 초과한 경우 : 경영진은 왜, 어떻게 이런 일이 발생했으며 현재 있는 인력으로 문제를 해결할 수 있는지, 그리고 향후 비슷한 문제를 피하려면 어떻게 해야 할 지를 알고자 한다.
- 경영진이 기업 전략의 변경이나 대대적인 조직 개편을 고려하고 있으며, 결정을 내리기 전 기술 전문가의 의견을 궁금해하고 있는 경우 : 이들이 알고자 하는 것은 아마도 기업 구조나 진행중인 프로젝트, 혹은 현재 일하고 있는 사람일 것이다. 비즈니스나 제품에 대해 더 상세한 이해가 필요할 수도 있다. 이런 프레젠테이션은 다른 것보다 어렵다.

사실상 당신이 경영진에게 하게 되는 프레젠테이션은 저게 전부다. 그 외에는 설령 청자가 경영진이라고 해도 그것은 경영진에게 하는 ‘프레젠테이션’은 아니다. 또 경영자 외에 다른 이들이 청중에 여럿 포함되어 있는 경우에도 이는 ‘경영진에게 하는’ 프레젠테이션은 아니라 할 것이다. 이럴 때 그들은 단순히 그 자리에 중요성을 더하기 위해, 혹은 응원차원에서 앉아 있는 경우가 많다.

경영진이 진짜 신경 쓰는 부분
경영진에게 프레젠테이션을 할 때는 그들이 진짜 걱정하는, 또는 신경 쓰는 것들에 집중해야 한다. 서론을 너무 길게 하거나, 갑자기 기술적인 디테일로 들어가는 실수를 저지르지 말자.

경영자가 신경 쓰는 것에는 아래와 같은 것들이 있다.

- 이 프로젝트가 기업에게 가져다 줄 수 있는 (일반적, 재정적인) 이득은 무엇인가
- 프로젝트에 수반되는 위험은 어떠한가
- 이러한 변화가 조직에 어떤 영향을 미칠 것인가
- 계획을 성공적으로 이끌만한 인재가 적재적소에 배치되어 있는가

그리고 경영자는 다음 사항에는 관심이 없다.

- 웹 프레임워크, 컴퓨터 언어, 기타 사소한 기술적 디테일들
- 당신이 얼마나 똑똑한 사람이라고 스스로 생각하는지
- 비즈니스적 관점에서 명쾌하게 설명할 수 없는 기술적 디테일

일부 IT 조직에서는 “이 계획의 비즈니스적 타당성이 무엇인가요?”라는 질문을 통해 완곡하게 거절을 표현하기도 한다. 이런 질문을 받고 이러이러한 테스트 프레임워크를 사용하거나, 어떤 유닛 테스트를 실시하면 이러이러한 것이 달성된다고 열심히 설명하려는 사람도 있다. 하지만 경영진이 원하는 비즈니스적 타당성이란 그런 것이 아니다. 예컨대 공장에서라면 테스트 프레임워크와 관련된 의사 결정은 일선 관리자에게 프레젠테이션 해야 할 사항이다. 물론 이들이 최종적인 결정을 내릴 권한은 없다. 이들은 아마도 경영자에게 해당 테스트 프레임워크 도입과 관련한 예산을 청할 것이며, ‘유닛 테스트를 하는 것’의 비즈니스적 타당성에 대해 이야기하는 일은 없을 것이다. 이는 라인 아이템으로 “퀄리티 컨트롤에 집중” 항목에 편입되어 아웃티지를 30% 줄이고, 지난해 생산 아웃티지로 인해 발생한 손해에서 약 50만 달러를 절약하는 것을 목표로 삼게 될 것이다.

IT 조직의 ‘비즈니스적 타당성’이 진짜 비즈니스 케이스를 의미한다고 생각해서는 곤란하다. 이는 조직 내에서 사용하는 완곡 어법일 뿐이다. 


경영진 프레젠테이션 조직하기
경영진에게 하는 프레젠테이션은 크든 작든 아래의 구조를 따라야 한다.

당신은 누구이고, 왜 경영진이 당신의 말에 귀를 기울여야 하는가?

이 내용은 직설적으로 말하기보다 서두에 녹여내면 된다. 단순히 직위를 소개하라는 얘기도 아니고, 긴 자기소개를 하라는 말도 아니다. 단지 문제의 상황에서 당신이 적임자라는 인상을 줄 수 있는 경력이나 성공 사례를 소개하라는 얘기다.

예컨대 경영진이 나에 대해 잘 모르는 상황에서 내가 맡은 프로젝트에 대한 자원을 요청해야 하는 상황이라고 해보자. “안녕하십니까, 저는 루시드워크(Lucidworks)의 기술 계약 매니저 누구입니다. 저는 콘텐츠 마케팅 전략을 개발하고 있으며 다수의 콘텐츠를 제작해 본 경험이 있습니다. 루시드워크에서 일하기 전에는 다수의 포춘 500 기업과 스타트업에서 일하였습니다. JBoss에서 근무하던 웹 초기에는 블로그와 위키, 그리고 초기 소셜 미디어에 투자하도록 경영진을 설득한 경험이 있습니다. 이후 빅 데이터 컨설팅 기업을 운영하기도 했습니다” 정도로 자기 소개를 할 수 있을 것이다.

이러한 자기 소개에는 내가 누구이고, 조직 내에서 어떤 역할을 맡고 있으며, 어떤 가치를 창출하고 있고, 왜 내가 이러한 직무에 적합한 사람인가가 들어 있다.

무엇이 문제이고, 그래서 무엇을 요청하는 것인가
이 부분은 할 수 있는 한 최대한 간결, 명료하게 설명해야 한다. 필요에 따라 상황 설명이 조금 곁들여질 수는 있어도, 일단은 핵심부터 던지고 그 뒤에 설명을 덧붙여야 한다. 특히 문제가 무엇인가를 설명할 때 스토리텔링 하듯이 긴 형식을 택해서는 안 된다. 고객 사례나 다른 팩트는 우선 문제를 정의하고 난 뒤 이를 뒷받침할 예시로 사용해야 한다. 문제점 설명은 되도록 한 슬라이드 내로 끝내자.

현재 직면한 문제 상황을 정의하는 단순한 문장으로 시작하라. “데이터 센터의 CPU 전체를 바꾸려고 합니다. CPU 교체는 러시아 해커들이 야기한 여러 문제를 해결할 수 있을 것입니다”라거나 “제품 전체를 클라우드로 이전하려고 합니다” 같은 문장이다.

비용은 얼마나 드는가
영업사원이 끝까지 비용 얘기는 안 하고 상품의 장점만 계속 얘기하는 걸 알고 있을 것이다. 그리고 사는 사람 입장에서는 비용에 대한 확답을 듣기 전까지는 영업사원이 하는 모든 얘기가 건성으로 들린다는 것도. 이 상황에서는 당신이 바로 영업사원의 입장이다. 당신은 경영진을 설득해 뭔가를 사게 만들려는 사람이다. 이런 상황에서 비용 이야기를 맨 나중에 꺼내면, 듣는 사람 입장에서는 내내 당신이 가장 중요한 하나를 감춘 채 자신을 설득하려 한다는 느낌을 받게 된다.

프레젠테이션 초반에 들어가는 비용을 명확하게 이야기하고, 프레젠테이션을 통해 어떻게 그러한 비용이 산출되었는지를 근거를 가지고 설명해 나가야 하는 이유다. 그렇다고 ppt에 재무재표를 첨부하라는 것은 아니지만, 최소한의 비용 산출 근거는 제시해 주는 것이 좋다. 수학 문제를 풀 때 답을 도출한 과정을 그대로 보여주듯이 말이다.

비즈니스 및 전략적 관점에서의 장점
비즈니스적 장점이란 재정적인 것 또는 혹은 시장 경쟁력 강화 중 하나일 것이다. 예컨대 제품에 AI 기능을 추가하려고 한다고 해보자. 이 경우 AI 주도형 공습용 드론에 대한 수요가 존재하며, 아직 시장에는 이런 제품을 공급하는 기업이 없는 상황임을 피력하고, 먼저 시작할수록 경쟁사보다 유리해진다는 점을 강조하는 것이다. 또, 지금 결정을 내리지 않으면 입게 되는 손해에 대해서도 설명하자.

최신 인텔 칩과 관련해 예기치 못한 어떤 문제로 인해 프로젝트가 예정 경로를 벗어난 상황이라면 이에 대해 자세히 설명한다. “보안상의 흠결로 인해 해커가 우리의 클라우드 플랫폼을 이용하고, 코드를 디플로이 했으며, 다른 사람의 코드에도 액세스 할 수 있었다. 원래 일어날 수도 없고 일어 나서도 안 되는 일이지만, 보안상의 흠결로 인해 이런 일이 일어났다. 이 칩을 교체하면 이런 문제를 예방하고 추가적인 손실을 막을 수 있다. 또 고객에게 관련한 문제를 해결했음을 알려 신뢰를 회복할 수 있고, 여전히 동일한 문제를 안고 있는 경쟁사와 우리 기업을 차별화하는 기능도 할 것이다. 이 문제를 해결하지 않고 방치해 둔다면 경쟁사가 먼저 우리를 앞질러 나갈 것이고, 소비자는 더 안전한 경쟁사의 솔루션에 더 매혹될 것이다. 어쩌면 보안을 중요시하지 않는 기업이라는 오명을 얻을 수도 있다. 정확한 숫자는 예측할 수 없지만, 소비자 설문조사에 따르면 이 문제를 방치해 둘 경우 그 여파를 돈으로 환산하면 6백만 달러 가량이며 고객의 20% 가량을 잃을 수 있다” 라고 말이다.

수반되는 위험과, 이 위험을 관리, 축소하는 방법
모든 일에는 크던 작든 위험이 따른다. 심지어 매일 아침 출근할 때에도 교통사고로 사망할 위험이 존재한다. 숨 한 번 쉴 때에도 공기 중에 독성 물질을 흡입해 암에 걸릴 위험이 존재한다. 이처럼 모든 일에는 위험이 존재할 수 밖에 없다. 이 사실을 받아들여야 한다.

그리고 이에 대해 설명해야 한다. “CPU 교체를 위해 시스템이 오프라인으로 전환되는 동안 아웃티지의 위험이 존재한다. 부가적으로, 일부 고객사에서 퍼포먼스 이슈가 발생할 수도 있다”는 식으로 말이다.

가능한 대안
한 가지 옵션만 검토하고 그것이 실패할 경우의 대안이나 솔루션을 생각해두지 않았다면 경영진은 당신의 계획에 신뢰를 갖지 못할 것이다. 경영진뿐 아니라 당신 스스로도 그래야 한다. 대안이 마련되지 않은 계획은 미완성의 계획이고, 공학적 실패이다.

예를 들자면 아래와 같다. “소프트웨어 패치에는 상당한(약 20~40%) 퍼포먼스 저하 위험이 따른다. 이러한 퍼포먼스 저하는 고객에게 실망을 안겨주고, 이들 중 상당수가 떠나가게 될 것이다. 때문에 소프트웨어 패치를 하지 않고 그냥 두고 보는 선택지도 고려해 보았지만, 그럼에도 불구하고 이 부분에서 퍼스트 무버가 됨으로써 경쟁사들에 비해 비교 우위를 가질 수 있고, 또 성능 향상에서도 얻는 장점이 있을 것이라 생각한다.” 같은 설명이 필요하다.

프레젠테이션, ‘이것만은 꼭...’
텍스트가 빼곡히 들어 찬 슬라이드
꼭 경영진에게 프레젠테이션 하는 게 아니어도 이런 만행은 해서는 안 되지만, 상대가 경영자일 때는 더더욱 해서는 안 되는 짓이다. 슬라이드에는 핵심만 적어 두고, 보다 시각적인 자료를 이용한다. 나머지는 구두로 설명한다.

쓸 데 없는 말을 하지 마라
경영진이 원하는 것은 문제의 핵심이지, 전체 사고 프로세스나 자료조사 과정을 원하는 것이 아니다. 그들이 원하는 것만 간단하게 전달하라.

Q&A를 위한 여지를 남겨 두어라
누구나 계획의 일부가 될 때는 자신의 의견이나 생각을 반영하고 싶어 한다. 또, 기술적 설명을 Q&A로 빼면 프레젠테이션이 간결해진다. 이 기사에서는 인텔의 Meltdown and Spectre 버그를 예시로 들었다. 하지만 기본적인 설명은 다른 사례에도 전부 적용된다. 필자가 사용한 예시에서는 기술 전문가에게나 통할 ‘가상화(virtualization)’라던가 ‘도커(Docker),’ 그리고 ‘컨테이너(container)’같은 전문 용어는 단 한차례도 등장하지 않았다. 그리고 이런 부분에 대해 청자는 틀림 없이 궁금함을 갖게 될 것이다. 질문은 곧 관심이고, 관심이야 말로 우리가 원하는 것이다.

철저한 자료 조사를 통해 팩트로 무장하라
연구 결과를 폭탄처럼 투여하라는 얘기는 아니다. 하지만 상대방의 질문에 답할 팩트 정도는 준비해 두어야 한다. 슬라이드에 비용/편익 분석 전체를 한 가득 띄울 필요는 없겠지만 누군가가 물어보면 별도의 핸드아웃 등을 준비해 궁금증을 해소해 줄 수 있어야 한다.

파워포인트가 싫다고? 안타깝게도, 당신에게는 선택권이 없다
필자는 한 지역 컨퍼런스에서 슬라이드 없는 프레젠테이션이라는 매우 실험적이고 독특한 프레젠테이션 형식을 시도했다가 완전히 실패한 적이 있다. 프레젠테이션은 테드(TED) 강연이 아니다. 파워포인트가 한물 간 수단 같아 보이더라도, 혹은 개인적으로 파워포인트가 별로라고 해도, 때로는 당신이 원하는 것보다 청자의 요구와 기대치에 더 맞춰야 할 때가 있는 법이다. editor@itworld.co.kr


2018.06.25

“경영진 앞에서 떨지 말 것” 개발자를 위한 프레젠테이션 성공 법칙

Andrew C. Oliver | InfoWorld
경영진을 상대로 프레젠테이션을 하는 것은 다른 기술 전문가들에게 프레젠테이션 하는 것과는 다르다. 오히려, 좋은 글쓰기를 위해 지켜야 할 것과 겹치는 부분이 많다. 청중을 염두에 둔 프레젠테이션을 할 것, 핵심 포인트를 생각하며 말할 것, 간략하고 명확하게 의견을 전달할 것 등이 요점이다. 경영자에게 프레젠테이션을 할 때는 당신이 상대하는 청중이 매우 바쁜 사람들이라는 것, 그리고 프로젝트의 영향력과 비용, 수반되는 위험 등을 알고자 하지 구체적인 세부 사항을 궁금해하는 것은 아니라는 것(그런 디테일을 세세히 알고 관리하라고 당신을 뽑은 것이다) 등을 기억해야 한다. 또 그들은 당신이 이 계획을 철저하게 계획했는지, 대안은 마련했는지, 충분한 사전 조사가 이루어졌는지를(물론 여기서도 그 여부만을 궁금해 할 뿐 디테일은 알고 싶어하지 않는다) 알고자 한다.

그렇다면 경영자에게 프레젠테이션을 할 때는 구체적으로 어떤 원칙을 지켜야 할까? 개발자와 엔지니어의 성공적인 프레젠테이션을 위한 튜토리얼을 소개한다.

경영자란 어떤 사람인가?
여러분의 청중이 경영자인지 아닌지를 판단하기 위해서는 우선 경영자가 어떤 이를 의미하는지 알아야 할 것이다.

논란의 여지는 있지만, 직함에 ‘매니저’나 ‘디렉터’가 달려있다고 해서 다 경영자는 아니다. 은행이나 금융기관에서 일하는 사람이라면 ‘VP’라는 타이틀을 달았다고 모두 경영자는 아니라는 걸 알 것이다. 심지어 일부 C레벨 인사들(CEO, CFO 등)도 경영자가 아닐 수 있다. 이제는 심각한 ‘타이틀 인플레이션’ 때문에 타이틀만 보고는 유의미한 정보를 얻기 힘들어졌다.

이 글에서 ‘경영자’라고 일컫는 이들은 쉽게 말해 자금을 운용하고 할당, 배분할 수 있는 권한을 지닌 사람을 지칭한다. 때로는 직접적인 권한은 없지만, 실질적으로 업무를 수행하는 낮은 직위 또는 중간 직위의 중간 관리자가 있을 수도 있다. 경영자에게 프레젠테이션을 한다는 것은 결국 어떤 프로젝트에 대한 재정적 혹은 비즈니스 전략적 의사 결정을 내리는 일이기 때문이다.

프레젠테이션의 목적은 무엇인가
우선 경영진에게 프레젠테이션을 하고 있는 이유에 대해 생각해 보자.

- 프로젝트에 요구되는 자원을 요구하기 위해서일 경우 : 경영진은 프로젝트의 비용/장점과, 수반되는 위험을 알고자 한다.
- 비즈니스에 핵심적인 기능을 하는 프로젝트나 서비스가 예상 또는 예정 경로를 벗어난 경우, 또는 예산을 초과한 경우 : 경영진은 왜, 어떻게 이런 일이 발생했으며 현재 있는 인력으로 문제를 해결할 수 있는지, 그리고 향후 비슷한 문제를 피하려면 어떻게 해야 할 지를 알고자 한다.
- 경영진이 기업 전략의 변경이나 대대적인 조직 개편을 고려하고 있으며, 결정을 내리기 전 기술 전문가의 의견을 궁금해하고 있는 경우 : 이들이 알고자 하는 것은 아마도 기업 구조나 진행중인 프로젝트, 혹은 현재 일하고 있는 사람일 것이다. 비즈니스나 제품에 대해 더 상세한 이해가 필요할 수도 있다. 이런 프레젠테이션은 다른 것보다 어렵다.

사실상 당신이 경영진에게 하게 되는 프레젠테이션은 저게 전부다. 그 외에는 설령 청자가 경영진이라고 해도 그것은 경영진에게 하는 ‘프레젠테이션’은 아니다. 또 경영자 외에 다른 이들이 청중에 여럿 포함되어 있는 경우에도 이는 ‘경영진에게 하는’ 프레젠테이션은 아니라 할 것이다. 이럴 때 그들은 단순히 그 자리에 중요성을 더하기 위해, 혹은 응원차원에서 앉아 있는 경우가 많다.

경영진이 진짜 신경 쓰는 부분
경영진에게 프레젠테이션을 할 때는 그들이 진짜 걱정하는, 또는 신경 쓰는 것들에 집중해야 한다. 서론을 너무 길게 하거나, 갑자기 기술적인 디테일로 들어가는 실수를 저지르지 말자.

경영자가 신경 쓰는 것에는 아래와 같은 것들이 있다.

- 이 프로젝트가 기업에게 가져다 줄 수 있는 (일반적, 재정적인) 이득은 무엇인가
- 프로젝트에 수반되는 위험은 어떠한가
- 이러한 변화가 조직에 어떤 영향을 미칠 것인가
- 계획을 성공적으로 이끌만한 인재가 적재적소에 배치되어 있는가

그리고 경영자는 다음 사항에는 관심이 없다.

- 웹 프레임워크, 컴퓨터 언어, 기타 사소한 기술적 디테일들
- 당신이 얼마나 똑똑한 사람이라고 스스로 생각하는지
- 비즈니스적 관점에서 명쾌하게 설명할 수 없는 기술적 디테일

일부 IT 조직에서는 “이 계획의 비즈니스적 타당성이 무엇인가요?”라는 질문을 통해 완곡하게 거절을 표현하기도 한다. 이런 질문을 받고 이러이러한 테스트 프레임워크를 사용하거나, 어떤 유닛 테스트를 실시하면 이러이러한 것이 달성된다고 열심히 설명하려는 사람도 있다. 하지만 경영진이 원하는 비즈니스적 타당성이란 그런 것이 아니다. 예컨대 공장에서라면 테스트 프레임워크와 관련된 의사 결정은 일선 관리자에게 프레젠테이션 해야 할 사항이다. 물론 이들이 최종적인 결정을 내릴 권한은 없다. 이들은 아마도 경영자에게 해당 테스트 프레임워크 도입과 관련한 예산을 청할 것이며, ‘유닛 테스트를 하는 것’의 비즈니스적 타당성에 대해 이야기하는 일은 없을 것이다. 이는 라인 아이템으로 “퀄리티 컨트롤에 집중” 항목에 편입되어 아웃티지를 30% 줄이고, 지난해 생산 아웃티지로 인해 발생한 손해에서 약 50만 달러를 절약하는 것을 목표로 삼게 될 것이다.

IT 조직의 ‘비즈니스적 타당성’이 진짜 비즈니스 케이스를 의미한다고 생각해서는 곤란하다. 이는 조직 내에서 사용하는 완곡 어법일 뿐이다. 


경영진 프레젠테이션 조직하기
경영진에게 하는 프레젠테이션은 크든 작든 아래의 구조를 따라야 한다.

당신은 누구이고, 왜 경영진이 당신의 말에 귀를 기울여야 하는가?

이 내용은 직설적으로 말하기보다 서두에 녹여내면 된다. 단순히 직위를 소개하라는 얘기도 아니고, 긴 자기소개를 하라는 말도 아니다. 단지 문제의 상황에서 당신이 적임자라는 인상을 줄 수 있는 경력이나 성공 사례를 소개하라는 얘기다.

예컨대 경영진이 나에 대해 잘 모르는 상황에서 내가 맡은 프로젝트에 대한 자원을 요청해야 하는 상황이라고 해보자. “안녕하십니까, 저는 루시드워크(Lucidworks)의 기술 계약 매니저 누구입니다. 저는 콘텐츠 마케팅 전략을 개발하고 있으며 다수의 콘텐츠를 제작해 본 경험이 있습니다. 루시드워크에서 일하기 전에는 다수의 포춘 500 기업과 스타트업에서 일하였습니다. JBoss에서 근무하던 웹 초기에는 블로그와 위키, 그리고 초기 소셜 미디어에 투자하도록 경영진을 설득한 경험이 있습니다. 이후 빅 데이터 컨설팅 기업을 운영하기도 했습니다” 정도로 자기 소개를 할 수 있을 것이다.

이러한 자기 소개에는 내가 누구이고, 조직 내에서 어떤 역할을 맡고 있으며, 어떤 가치를 창출하고 있고, 왜 내가 이러한 직무에 적합한 사람인가가 들어 있다.

무엇이 문제이고, 그래서 무엇을 요청하는 것인가
이 부분은 할 수 있는 한 최대한 간결, 명료하게 설명해야 한다. 필요에 따라 상황 설명이 조금 곁들여질 수는 있어도, 일단은 핵심부터 던지고 그 뒤에 설명을 덧붙여야 한다. 특히 문제가 무엇인가를 설명할 때 스토리텔링 하듯이 긴 형식을 택해서는 안 된다. 고객 사례나 다른 팩트는 우선 문제를 정의하고 난 뒤 이를 뒷받침할 예시로 사용해야 한다. 문제점 설명은 되도록 한 슬라이드 내로 끝내자.

현재 직면한 문제 상황을 정의하는 단순한 문장으로 시작하라. “데이터 센터의 CPU 전체를 바꾸려고 합니다. CPU 교체는 러시아 해커들이 야기한 여러 문제를 해결할 수 있을 것입니다”라거나 “제품 전체를 클라우드로 이전하려고 합니다” 같은 문장이다.

비용은 얼마나 드는가
영업사원이 끝까지 비용 얘기는 안 하고 상품의 장점만 계속 얘기하는 걸 알고 있을 것이다. 그리고 사는 사람 입장에서는 비용에 대한 확답을 듣기 전까지는 영업사원이 하는 모든 얘기가 건성으로 들린다는 것도. 이 상황에서는 당신이 바로 영업사원의 입장이다. 당신은 경영진을 설득해 뭔가를 사게 만들려는 사람이다. 이런 상황에서 비용 이야기를 맨 나중에 꺼내면, 듣는 사람 입장에서는 내내 당신이 가장 중요한 하나를 감춘 채 자신을 설득하려 한다는 느낌을 받게 된다.

프레젠테이션 초반에 들어가는 비용을 명확하게 이야기하고, 프레젠테이션을 통해 어떻게 그러한 비용이 산출되었는지를 근거를 가지고 설명해 나가야 하는 이유다. 그렇다고 ppt에 재무재표를 첨부하라는 것은 아니지만, 최소한의 비용 산출 근거는 제시해 주는 것이 좋다. 수학 문제를 풀 때 답을 도출한 과정을 그대로 보여주듯이 말이다.

비즈니스 및 전략적 관점에서의 장점
비즈니스적 장점이란 재정적인 것 또는 혹은 시장 경쟁력 강화 중 하나일 것이다. 예컨대 제품에 AI 기능을 추가하려고 한다고 해보자. 이 경우 AI 주도형 공습용 드론에 대한 수요가 존재하며, 아직 시장에는 이런 제품을 공급하는 기업이 없는 상황임을 피력하고, 먼저 시작할수록 경쟁사보다 유리해진다는 점을 강조하는 것이다. 또, 지금 결정을 내리지 않으면 입게 되는 손해에 대해서도 설명하자.

최신 인텔 칩과 관련해 예기치 못한 어떤 문제로 인해 프로젝트가 예정 경로를 벗어난 상황이라면 이에 대해 자세히 설명한다. “보안상의 흠결로 인해 해커가 우리의 클라우드 플랫폼을 이용하고, 코드를 디플로이 했으며, 다른 사람의 코드에도 액세스 할 수 있었다. 원래 일어날 수도 없고 일어 나서도 안 되는 일이지만, 보안상의 흠결로 인해 이런 일이 일어났다. 이 칩을 교체하면 이런 문제를 예방하고 추가적인 손실을 막을 수 있다. 또 고객에게 관련한 문제를 해결했음을 알려 신뢰를 회복할 수 있고, 여전히 동일한 문제를 안고 있는 경쟁사와 우리 기업을 차별화하는 기능도 할 것이다. 이 문제를 해결하지 않고 방치해 둔다면 경쟁사가 먼저 우리를 앞질러 나갈 것이고, 소비자는 더 안전한 경쟁사의 솔루션에 더 매혹될 것이다. 어쩌면 보안을 중요시하지 않는 기업이라는 오명을 얻을 수도 있다. 정확한 숫자는 예측할 수 없지만, 소비자 설문조사에 따르면 이 문제를 방치해 둘 경우 그 여파를 돈으로 환산하면 6백만 달러 가량이며 고객의 20% 가량을 잃을 수 있다” 라고 말이다.

수반되는 위험과, 이 위험을 관리, 축소하는 방법
모든 일에는 크던 작든 위험이 따른다. 심지어 매일 아침 출근할 때에도 교통사고로 사망할 위험이 존재한다. 숨 한 번 쉴 때에도 공기 중에 독성 물질을 흡입해 암에 걸릴 위험이 존재한다. 이처럼 모든 일에는 위험이 존재할 수 밖에 없다. 이 사실을 받아들여야 한다.

그리고 이에 대해 설명해야 한다. “CPU 교체를 위해 시스템이 오프라인으로 전환되는 동안 아웃티지의 위험이 존재한다. 부가적으로, 일부 고객사에서 퍼포먼스 이슈가 발생할 수도 있다”는 식으로 말이다.

가능한 대안
한 가지 옵션만 검토하고 그것이 실패할 경우의 대안이나 솔루션을 생각해두지 않았다면 경영진은 당신의 계획에 신뢰를 갖지 못할 것이다. 경영진뿐 아니라 당신 스스로도 그래야 한다. 대안이 마련되지 않은 계획은 미완성의 계획이고, 공학적 실패이다.

예를 들자면 아래와 같다. “소프트웨어 패치에는 상당한(약 20~40%) 퍼포먼스 저하 위험이 따른다. 이러한 퍼포먼스 저하는 고객에게 실망을 안겨주고, 이들 중 상당수가 떠나가게 될 것이다. 때문에 소프트웨어 패치를 하지 않고 그냥 두고 보는 선택지도 고려해 보았지만, 그럼에도 불구하고 이 부분에서 퍼스트 무버가 됨으로써 경쟁사들에 비해 비교 우위를 가질 수 있고, 또 성능 향상에서도 얻는 장점이 있을 것이라 생각한다.” 같은 설명이 필요하다.

프레젠테이션, ‘이것만은 꼭...’
텍스트가 빼곡히 들어 찬 슬라이드
꼭 경영진에게 프레젠테이션 하는 게 아니어도 이런 만행은 해서는 안 되지만, 상대가 경영자일 때는 더더욱 해서는 안 되는 짓이다. 슬라이드에는 핵심만 적어 두고, 보다 시각적인 자료를 이용한다. 나머지는 구두로 설명한다.

쓸 데 없는 말을 하지 마라
경영진이 원하는 것은 문제의 핵심이지, 전체 사고 프로세스나 자료조사 과정을 원하는 것이 아니다. 그들이 원하는 것만 간단하게 전달하라.

Q&A를 위한 여지를 남겨 두어라
누구나 계획의 일부가 될 때는 자신의 의견이나 생각을 반영하고 싶어 한다. 또, 기술적 설명을 Q&A로 빼면 프레젠테이션이 간결해진다. 이 기사에서는 인텔의 Meltdown and Spectre 버그를 예시로 들었다. 하지만 기본적인 설명은 다른 사례에도 전부 적용된다. 필자가 사용한 예시에서는 기술 전문가에게나 통할 ‘가상화(virtualization)’라던가 ‘도커(Docker),’ 그리고 ‘컨테이너(container)’같은 전문 용어는 단 한차례도 등장하지 않았다. 그리고 이런 부분에 대해 청자는 틀림 없이 궁금함을 갖게 될 것이다. 질문은 곧 관심이고, 관심이야 말로 우리가 원하는 것이다.

철저한 자료 조사를 통해 팩트로 무장하라
연구 결과를 폭탄처럼 투여하라는 얘기는 아니다. 하지만 상대방의 질문에 답할 팩트 정도는 준비해 두어야 한다. 슬라이드에 비용/편익 분석 전체를 한 가득 띄울 필요는 없겠지만 누군가가 물어보면 별도의 핸드아웃 등을 준비해 궁금증을 해소해 줄 수 있어야 한다.

파워포인트가 싫다고? 안타깝게도, 당신에게는 선택권이 없다
필자는 한 지역 컨퍼런스에서 슬라이드 없는 프레젠테이션이라는 매우 실험적이고 독특한 프레젠테이션 형식을 시도했다가 완전히 실패한 적이 있다. 프레젠테이션은 테드(TED) 강연이 아니다. 파워포인트가 한물 간 수단 같아 보이더라도, 혹은 개인적으로 파워포인트가 별로라고 해도, 때로는 당신이 원하는 것보다 청자의 요구와 기대치에 더 맞춰야 할 때가 있는 법이다. editor@itworld.co.kr


X