문제–해결책–근거 구조의 발표는 구체적인 어려움과 제안하는 대응, 그리고 그 대응을 뒷받침하는 자료를 연결합니다. 제안이나 설명에 유용하지만, “근거”가 해결책의 성공을 자신 있게 단언하는 말뿐이라면 청중을 오해하게 만들 수 있습니다.

관찰한 사실, 제안하는 변경, 근거로 확인할 수 있는 범위를 구분한 개요부터 작성하세요. 구분이 명확해지면 그 개요를 Presenti에서 편집 가능한 슬라이드 초안으로 만들 수 있습니다. 생성된 이야기가 없는 고객 성과를 채우거나 계획 중인 검증을 완료된 검증으로 바꾸게 해서는 안 됩니다.

문제·해결책·근거로 만드는 발표 스토리

청중이 구체적으로 이해할 수 있는 문제를 정의하세요

누가 언제 어려움을 겪으며 어떤 결과가 중요한지 밝힙니다. “우리 업무는 비효율적이다”는 의사결정에 쓰기에는 너무 넓습니다. “계정 식별 정보가 없는 문의는 지원팀이 조사하기 전에 추가 확인이 필요하다”는 구체적인 문제를 보여 줍니다.

눈에 보이는 현상과 추정하는 원인을 구분하세요. 식별 정보 누락이 일부 추가 문의를 설명할 수는 있지만, 모든 지연의 원인이 양식이라는 뜻은 아닙니다. 해당 양상을 측정했다면 표본, 기간, 출처를 제시합니다. 사례 하나뿐이라면 사례라고 부르세요.

선호하는 해결책만 합리적으로 보이도록 문제를 부풀리지 마세요. 청중은 제안을 듣기 전에도 문제 자체를 이해할 수 있어야 합니다.

변경안이 문제에 어떻게 대응하는지 보여 주세요

가상의 고객 문의 사례를 이어서 보겠습니다. 제안은 계정 식별 정보가 필요한 문의 유형에서 해당 입력을 필수로 하고, 그 정보를 어디서 찾는지 설명하는 것입니다. 조사 담당자가 접수 시 필요한 정보를 받는다는 직접적인 작동 원리가 있습니다.

그렇다고 모든 입력란을 필수로 해야 하는 것은 아닙니다. 계정이 없는 문의자도 있을 수 있고, 예외가 없는 양식은 정당한 문의를 막을 수 있습니다. 관련 예외나 대체 경로를 보여 주세요. 해결책 슬라이드는 빨간 도표를 초록색으로 바꾸는 데 그치지 않고, 얻는 점과 부담을 이해하게 해야 합니다.

청중이 제기할 법한 현실적인 대안도 검토하세요. 이 경우 필수 입력을 강제하지 않고 안내를 명확히 하면 부담은 작을 수 있지만 누락은 여전히 발생할 수 있습니다. 다른 선택이 없다고 주장하기보다, 왜 특정 방식을 시험해 보려는지 설명합니다.

근거의 종류와 주장의 범위를 맞추세요

근거에 따라 뒷받침할 수 있는 결론이 다릅니다.

  • 구체적인 예시는 제안한 양식이 문의 한 건을 어떻게 처리하는지 보여 줍니다. 문제가 얼마나 자주 발생하는지는 보여 주지 못합니다.
  • 작동하는 시연은 해당 환경에서 입력란이나 절차가 설명대로 동작함을 보여 줍니다. 실제 도입이나 사업 성과까지 입증하지는 않습니다.
  • 시범 운영 관찰은 관찰한 사람과 기간에 일어난 일을 설명합니다. 일반화하려면 조건과 맥락이 필요합니다.
  • 신뢰할 수 있는 기준과의 비교는 변화를 평가하는 데 도움이 됩니다. 다만 이용자, 업무량, 측정 방식의 차이가 결과에 영향을 줄 수 있습니다.

이 가상의 제안에는 아직 시범 운영 결과가 없습니다. 따라서 근거 슬라이드에는 문의 예시와 검증 계획을 넣어야 하며, “더 빠른 해결”이라고 적힌 상승 그래프를 넣어서는 안 됩니다. 결정할 것은 검증하지 않은 효과가 입증되었는지가 아니라 시범 운영을 할지입니다.

나중에 실제 결과가 나오면 정의와 분모를 제시하세요. 무엇을 추가 확인이 필요한 문의로 세었는지, 어떤 문의 유형을 포함했는지, 어느 기간인지 밝힙니다. 제출의 어려움도 함께 봐야 합니다. 많은 이용자가 문의를 제출하지 못하게 되었다면 추가 문의가 줄었다는 사실만으로는 설득하기 어렵습니다.

문의 예시, 작동하는 양식, 측정한 시범 운영이 각각 뒷받침할 수 있는 주장의 범위
Presenti 공식 편집 화면에 합성한 근거 비교 예시입니다. 문의 사례, 동작 시연, 시범 운영 결과의 차이를 보여 줍니다.

논리를 짧은 슬라이드 흐름으로 바꾸세요

요소가 세 가지라고 반드시 슬라이드도 세 장이어야 하는 것은 아닙니다. 시범 운영 제안이라면 다섯 장으로 나누어 청중이 논리를 검토할 여유를 줄 수 있습니다.

  1. 요청: 전면 도입이 아닌 제한된 시범 운영의 승인을 요청합니다.
  2. 문제: 불완전한 문의 한 건과 추가 확인이 필요한 이유를 설명합니다.
  3. 변경안: 식별 정보 입력란, 안내 문구, 예외 경로를 보여 줍니다.
  4. 근거와 미확인 사항: 예시로 알 수 있는 것과 시범 운영에서 측정할 것을 구분합니다.
  5. 결정: 시범 운영 담당자, 범위, 검토 시점, 계속하거나 수정할 조건을 명시합니다.

슬라이드를 인과관계가 드러나는 문장으로 연결하세요. “이 정보가 빠져 추가 확인이 필요합니다”는 문제에서 해결책으로 넘어가는 이유를 설명합니다. “양식으로 정보를 받을 수는 있지만, 사람들이 어렵지 않게 입력할 수 있는지는 더 확인해야 합니다”는 시연이 작동한다고 논의가 끝나지 않는 이유를 설명합니다.

더 넓은 설득형 발표를 준비한다면 데이터 스토리에 근거를 활용하는 안내(영어)를 참고해 어떤 비교를 본문에 넣고 어떤 세부 자료를 별도로 둘지 결정할 수 있습니다.

AI로 초안을 만들 때도 주장의 범위를 지키세요

확인된 문제 정의, 제안한 작동 방식, 이용 가능한 근거, 대안, 미확인 사항을 초안 도구에 제공합니다. 이 구분을 유지하는 슬라이드 제목을 요청하세요. 예를 들어 “시범 운영은 제안 단계로 설명하세요. 결과, 비율, 고객 발언, 출처를 만들어 내지 마세요”라고 지시할 수 있습니다.

레이아웃을 다듬기 전에 생성된 제목을 순서대로 읽어 보세요. “추가 확인을 줄일 수 있다”가 “지연을 없앤다”로 바뀌었다면 더 좁은 주장으로 되돌립니다. 근거 슬라이드에 원본 메모에 없는 사실이 있다면 삭제하거나 확인하세요. 이 구조의 목적은 논리를 검토하기 쉽게 만드는 것이지, 불확실한 제안을 필연적인 결과처럼 보이게 만드는 것이 아닙니다.