기술을 말하는 기술

기술을 말하는 기술
: 개발자를 위한 프레젠테이션 스킬 특강
서다미 웹 프로덕트 엔지니어 | 강사
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
1
목차
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
2
1교시 | 프레젠테이션의 본질과 구조 설계
발표는 정보 전달이 아니다
🎯 목적 (Purpose)
🏗️ 구조 (Structure)
💡 설득 (Persuasion)
문제 해결을 설득하는 기술 (Presentation = Persuasion)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
3
이번 시간 미리보기 (Preview)
프레젠테이션의 진짜 목적
정보 전달 vs 설득
개발자 발표가 망하는 이유
흔한 실패 패턴 분석
올바른 발표 구조
4단계 프레임워크
Good vs Bad 비교
실전 예시로 익히기
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
4
프레젠테이션의 진짜 목적
백엔드 개발자 발표에서 중요한 건 무엇을 했는지보다, 그 작업이 왜 의미 있는지를 청중이 즉시 이해하게 만드는 것입니다.
❌ 정보 전달 (Information Transfer)
"저는 Redis를 사용해서 캐싱을 구현했고, TTL은 300초로 설정했습니다." → 청중은 왜 그게 중요한지 모른다
기능 목록, 구현 세부사항, 기술 스택 나열에 집중한다
발표자 중심: "내가 한 것"을 설명하는 데 그친다
문제의 배경이나 선택 이유 없이 기술만 설명한다
결과: 청중은 고개를 끄덕이지만 아무것도 기억하지 못한다
청중 반응: 😐 "그래서 뭐가 달라진 거죠?"
✅ 설득 / 문제 해결 (Persuasion)
"응답 속도가 3초에서 0.2초로 줄었고, 이로 인해 이탈률이 40% 감소했습니다." → 청중이 가치를 즉시 이해한다
문제 → 선택 이유 → 결과 → 임팩트 순서로 전달한다
청중 중심: "이게 당신에게 왜 중요한가"를 먼저 설명한다
기술은 수단이고, 해결된 문제와 얻은 효과를 핵심 메시지로 만든다
결과: 청중이 고개를 끄덕이며 "우리도 적용해야겠다"고 생각한다
청중 반응: 💡 "이 방법을 우리 팀에도 써야겠다!"
발표는 내가 한 일의 보고서가 아닙니다. 청중이 '왜 이게 나한테 중요한가'를 느끼게 만드는 설득의 기술입니다.
🎯 청중의 질문
"이게 왜 나한테 중요한가?" 이 질문에 답하는 발표가 기억에 남습니다.
📊 수치로 말하라
기능이 아닌 결과(응답속도, 비용 절감, 에러율)로 설득해야 합니다.
🔄 행동을 유도하라
발표가 끝난 후 청중이 무언가를 하게 만드는 것이 목표입니다.
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
5
발표를 듣는 사람의 입장
관심 (Attention) — 첫 15초가 전부다
청중의 첫 질문은 "이게 나랑 관련 있나? 들을 가치가 있나?"다. 이 질문에 답하지 못하면 청중은 이미 스마트폰을 꺼냅니다. 개발자 발표 실패 예: "안녕하세요, 오늘은 Redis에 대해 발표하겠습니다" → 청중: 😐. 성공 예: "우리 서비스 응답속도가 3초였습니다. 오늘 그걸 0.2초로 줄인 방법을 공유합니다" → 청중: 👀
이해 (Understanding) — 맥락이 없으면 내용도 없다
청중의 두 번째 질문은 "무슨 말인지 알겠는데, 왜 이 방법을 선택했지?"다. 기술 용어를 나열하면 비개발자 청중은 30초 만에 이탈합니다. 핵심은 기술 → 비유 → 임팩트 순서로 설명하는 것입니다. 예: "Redis는 DB 앞에 두는 고속 메모리 캐시입니다. 도서관 대신 책상 위에 자주 쓰는 책을 올려두는 것과 같습니다". 설명이 이해되지 않으면, 좋은 기술도 단순한 정보 조각으로 흩어집니다.
납득 (Conviction) — 수치와 결과가 설득한다
청중의 마지막 질문은 "그래서 이게 우리한테 왜 중요한가? 우리도 써야 하나?"다. 납득은 감정 + 논리의 조합으로 만들어집니다. 수치 없는 주장은 의견일 뿐입니다: "성능이 좋아졌습니다" vs "응답속도 93% 개선, 이탈률 40% 감소". 납득한 청중만이 발표 후 행동합니다.
"발표자의 역할은 청중을 관심 → 이해 → 납득의 3단계로 자연스럽게 이끄는 것입니다. 이 흐름이 끊기는 순간, 청중은 떠납니다."
❌ 흐름이 끊기는 발표
도입 없이 바로 기술 설명 시작
청중 배경 고려 없이 전문 용어 남발
결론 없이 "이상입니다"로 마무리
결과: 청중은 "그래서 뭐?" 상태로 자리를 뜬다
✅ 흐름을 만드는 발표
문제/수치로 관심을 먼저 잡는다
비유와 맥락으로 이해를 돕는다
결과와 임팩트로 납득시킨다
결과: 청중은 "우리도 적용해야겠다"고 생각한다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
6
개발자 발표가 망하는 이유
흔한 실패 패턴 4가지 (Common Failure Patterns)
① 📋 A~Z 나열 (Feature Dumping)
기능을 나열만 하면 청중은 핵심과 의미를 놓칩니다.
Bad 예시: "로그인 → 회원가입 → 마이페이지 → 게시판 → 댓글 구현했습니다"
해결 방향: 핵심 기능 1~2개만 골라 "왜 중요한가" 중심으로 설명하세요.
② 🔧 구현 순서 설명 (Chronological Trap)
개발 순서대로 말하면 자연스럽지만, 청중에게는 설득 구조가 아닙니다.
Bad 예시: "먼저 DB 설계하고, 그 다음 API 만들고, 프론트 연결했습니다"
해결 방향: 문제 → 선택 → 결과 순서로 재구성하세요.
③ 🤐 이유 없는 "했습니다" (No Why)
결과만 말하고 이유가 없으면 발표가 보고서처럼 들립니다.
Bad 예시: "Redis를 사용했습니다. JWT를 적용했습니다. MSA로 전환했습니다."
해결 방향: 모든 선택에 "왜냐하면 + 수치/근거"를 붙이세요.
④ 👥 청중 무시 (Audience Blindness)
청중의 수준과 관심사를 고려하지 않으면 아무리 좋은 내용도 전달되지 않습니다.
Bad 예시: 면접관(비개발자 HR) 앞에서 "TTL 300초, Eviction Policy LRU 설정했습니다"
해결 방향: 청중의 기술 수준과 원하는 것을 먼저 파악하고, 그들의 언어로 바꾸세요.
"개발자 발표가 망하는 건 실력이 없어서가 아니라 청중의 입장에서 생각하지 않았기 때문입니다"
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
7
Bad Case 실전 예시 — 그래서 뭐가 달라진 거죠?
"저희는 Redis를 사용했고, 캐싱을 적용해서 성능을 개선했습니다."
❌ 이 발표의 문제점
🔍 "왜 Redis인가?" — Memcached, 로컬 캐시 등 대안과 비교 없음
📉 "어떤 문제였나?" — 응답 지연이 얼마나 심각했는지 맥락 없음
📊 "얼마나 개선됐나?" — 수치 없는 "개선"은 설득이 아니라 주장입니다
👥 "청중에게 왜 중요한가?" — 이 개선이 서비스/비즈니스에 미친 영향 없음
✅ 이렇게 말해야 합니다
"피크 타임 DB 조회 병목으로 API 응답이 평균 2.3초였고, 이탈률이 35%에 달했습니다. 반복 조회 패턴을 분석해 Redis를 선택했고 — Memcached 대비 데이터 구조 유연성이 필요했기 때문입니다 — 적용 후 응답속도 87% 개선, 이탈률 12%로 감소했습니다."
"청중은 '무엇을 했는가'가 아니라 '왜 그 선택이었고, 얼마나 달라졌는가'를 듣고 싶다."
1. 문제를 수치로 — "느렸습니다" → "평균 2.3초, 이탈률 35%"
2. 선택 이유를 — "Redis를 썼습니다" → "Memcached 대비 이 이유로 선택"
3. 결과를 임팩트로 — "개선됐습니다" → "87% 개선, 이탈률 12%로 감소"
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
8
올바른 발표 구조 (Presentation Framework)
청중을 공감 → 이해 → 납득으로 이끄는 4단계
🔍 문제 정의 (Problem)
청중이 "맞아, 나도 이 문제 겪었어"라고 느끼게 만드는 단계입니다. 수치로 문제의 심각성을 먼저 보여줘야 합니다. 예: "피크 타임 API 응답이 평균 2.3초 — 사용자 이탈률 35%에 달했습니다." 핵심은 문제가 클수록 해결책의 가치도 커진다는 점입니다.
⚠️ 기존 방식의 한계 (Limitation)
"왜 그냥 두지 않았는가"를 설명하는 단계입니다. 기존 방법의 구체적 문제점을 짚어주세요. 예: "DB 직접 조회는 동일 데이터를 매번 재계산 — 트래픽 증가 시 병목이 심화됐습니다." 핵심은 한계를 인정해야 새 선택이 설득력을 얻는다는 것입니다.
💡 해결 방법 (Solution)
선택한 방법과 "왜 이걸 선택했는가"를 함께 말하는 단계입니다. 대안과의 비교, 선택 기준을 명확히 하세요. 예: "Redis 캐싱 도입 — Memcached 대비 데이터 구조 유연성과 Pub/Sub 지원이 필요했기 때문". 핵심은 "했습니다"가 아니라 "선택했습니다, 왜냐하면"입니다.
📈 결과 / 임팩트 (Result)
수치와 비즈니스 임팩트로 효과를 증명하는 단계입니다. 기술 지표 + 비즈니스 지표를 함께 제시하세요. 예: "응답속도 2.3초 → 0.3초 (87% 개선), 이탈률 35% → 12%, 서버 비용 월 30% 절감". 핵심은 숫자가 없는 결과는 주장일 뿐입니다.
❌ 이 구조 없이 발표하면:
기능 나열로 시작 → 청중 관심 이탈
이유 없는 "했습니다" → 신뢰 부족
수치 없는 결과 → 설득력 없음
청중: "그래서 뭐가 달라진 거죠?"
✅ 이 구조로 발표하면:
문제 공감으로 시작 → 청중 집중
선택 이유 명확 → 전문성 신뢰
수치로 증명 → 납득과 행동 유도
청중: "우리 팀에도 적용해야겠다!"
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
9
구조 적용 예시 — Redis 캐싱
4단계 프레임워크 실전 적용 — “이렇게 말하면 면접관이 고개를 끄덕인다”
1
🔍 문제 (Problem)
피크 타임 상품 상세 조회 API 응답이 평균 2,300ms였습니다. 동일한 데이터를 초당 300회 이상 DB에서 반복 조회하고 있었고, 이탈률은 35%에 달했습니다.
2
⚠️ 한계 (Limitation)
DB 직접 조회 방식은 트래픽이 2배 증가할 때마다 응답 지연이 기하급수적으로 악화됐습니다. 인덱스 최적화만으로는 한계가 명확했고, 이대로면 트래픽 피크 시 서버 다운 위험이 있었습니다.
3
💡 해결 (Solution)
Redis 캐싱을 도입했습니다. Memcached도 검토했지만, 상품 데이터의 복잡한 자료구조(Hash, List)와 향후 Pub/Sub 알림 기능 확장을 고려해 Redis를 선택했습니다. TTL은 조회 패턴 분석 결과 300초로 설정했습니다.
4
📈 결과 (Result)
응답속도 2,300ms → 280ms (87% 개선), DB 쿼리 수 70% 감소, 서버 비용 월 30% 절감. 이탈률은 35%에서 12%로 떨어졌고, 다음 달 MAU가 18% 증가했습니다.
❌ 이렇게 말하면 (Bad)
Redis를 사용해서 캐싱을 적용했고, 성능이 개선됐습니다.
왜 Redis인지, 얼마나 개선됐는지, 비즈니스 임팩트가 없다 → 청중: “그래서요?”
✅ 이렇게 말하면 (Good)
2,300ms 응답 지연 문제를 Redis 캐싱으로 해결해 87% 개선, 이탈률 35% → 12%로 낮췄습니다.
문제 수치 + 선택 이유 + 결과 임팩트가 모두 담겼다 → 청중: “우리도 적용해야겠다!”
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
10
구조 적용 예시 — JWT 인증
4단계 프레임워크 실전 적용 — “이렇게 말하면 면접관이 고개를 끄덕인다”
1
🔍 문제 (Problem)
MAU 50만 돌파 이후 로그인 요청이 초당 1,200건을 넘어섰습니다. 세션 기반 인증 서버의 메모리 사용률이 피크 타임 92%에 달했고, 서버 1대가 다운되면 전체 로그인이 불가능한 단일 장애점(SPOF) 문제가 있었습니다.
2
⚠️ 한계 (Limitation)
세션 서버를 수평 확장할 때마다 서버 간 세션 동기화 비용이 기하급수적으로 증가했습니다. Sticky Session으로 임시 해결했지만, 특정 서버에 트래픽이 몰리는 불균형 문제가 반복됐고 이는 근본적인 해결책이 아니었습니다.
3
💡 해결 (Solution)
JWT 기반 무상태(Stateless) 인증으로 전환했습니다. OAuth2 + Refresh Token 방식도 검토했지만, 내부 서비스 간 인증이 주목적이었기 때문에 구현 복잡도 대비 효과가 높은 JWT를 선택했습니다. Access Token 만료 시간은 보안과 UX를 고려해 15분으로 설정했습니다.
4
📈 결과 (Result)
인증 서버 메모리 사용률 92% → 23%로 감소, 서버 수평 확장 시 세션 동기화 비용 0, 로그인 응답속도 340ms → 80ms (76% 개선). 서버 인프라 비용 월 40% 절감, 이후 서버를 10대로 확장할 때도 인증 로직 변경 없이 적용됐습니다.
❌ 이렇게 말하면 (Bad)
JWT를 사용해서 인증을 구현했습니다.
왜 JWT인지, 기존 방식의 문제가 무엇인지, 수치 기반 결과가 없다 → 청중: “그래서요?”
✅ 이렇게 말하면 (Good)
세션 동기화 비용 문제를 JWT로 해결해 인증 서버 메모리 92% → 23%, 응답속도 76% 개선했습니다.
문제 수치 + 선택 이유 + 결과 임팩트가 모두 담겼다 → 청중: “이 사람, 제대로 알고 있네!”
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
11
Good Case vs Bad Case 비교
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
12
이 구조가 왜 효과적인가?(1)
문제 공감
"나도 이 문제 겪었어"
청중의 뇌가 활성화되는 순간 — 공감이 생기면 다음 말이 귀에 들어옵니다
한계 인식
"맞아, 기존 방법으로는 안 되지"
"왜 바꿔야 했는가"를 납득시키는 단계 — 한계를 인정해야 새 선택이 설득력을 얻습니다
해결 납득
"그래서 이 방법을 선택했구나"
이유가 있는 선택은 신뢰를 만듭니다 — "했습니다"가 아니라 "선택했습니다, 왜냐하면"
결과 확인
"효과가 있었네, 믿을 수 있어"
수치가 있는 결과는 주장이 아니라 증거입니다 — 청중이 행동하게 만드는 마지막 단계
문제를 먼저 공감시키면, 해결책은 자연스럽게 설득됩니다
발표자가 구조를 설계한다는 것 = 청중의 생각 흐름을 설계하는 것
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
13
이 구조가 왜 효과적인가?(2)
왜 이 순서여야 하는가?
🧠 인지심리학적 근거
공감 먼저 → 뇌의 방어막이 낮아진다 (Emotional Buy-in)
한계 인식 → "변화가 필요하다"는 내적 동의를 만듭니다
이유 있는 선택 → 전문성과 신뢰를 동시에 전달합니다
수치 결과 → 감정이 아닌 논리로 최종 납득시킵니다
❌ 순서를 바꾸면 생기는 일
해결책 먼저 → "왜 이게 필요하지?" 청중이 맥락을 모른다
결과 먼저 → "어떻게 그게 가능해?" 신뢰가 없다
한계 없이 → "기존 방법도 괜찮지 않나?" 변화 필요성을 못 느낀다
공감 없이 → 청중은 처음부터 관심을 끊는다
"좋은 발표 구조는 청중이 스스로 결론에 도달하게 만든다. 발표자가 설득하는 게 아니라, 청중이 납득하는 것입니다."
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
14
1교시 핵심 정리
🎯 발표의 목적
정보 전달이 아닌 설득 (Persuasion)
청중이 "왜 나한테 중요한가"를 느끼게 하라
🏗️ 올바른 구조
문제 → 한계 → 해결 → 결과
이 4단계가 청중을 납득으로 이끈다
💬 말하는 방식
"했습니다"가 아니라 "선택했습니다, 왜냐하면…"
이유와 수치가 설득력을 만듭니다
"발표는 내가 한 일을 설명하는 게 아니라, 청중이 납득하게 만드는 것입니다."
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
15
2교시 | 구조화 전략 심화 (Structuring Strategy)
논리적 흐름을 설계하라
💬 핵심 메시지 (Core Message)
🔗 논리 흐름 (Logical Flow)
👥 청중 분석 (Audience Analysis)
핵심 메시지에서 출발하는 구조화 전략 (Structuring from Core Message)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
16
이번 시간 미리보기 (Preview)
👥 청중 분석 (Audience Analysis)
누구에게, 무엇을, 어떻게 말할 것인가
💬 핵심 메시지 도출 (Core Message)
한 문장으로 발표를 설계하는 법
🏗️ 흐름 설계 (Flow Design)
도입·전개·결론의 밀도와 구조화 원칙
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
17
발표 전 반드시 물어야 할 3가지 (Audience Analysis)
👥 청중은 누구인가? (Who)
개발자 동료 / 기획자·PM / 면접관 / 경영진
같은 내용도 청중에 따라 말하는 방식이 완전히 달라집니다
핵심: 청중을 모르면 구조도 없습니다
🎯 청중이 원하는 것은? (What)
이해를 원하는가 / 판단을 원하는가 / 공감을 원하는가
청중의 목적이 발표의 구조를 결정합니다
핵심: 내가 하고 싶은 말이 아니라, 청중이 듣고 싶은 말을 하라
🧠 청중의 배경지식은? (Level)
전문가인가 / 비전문가인가 / 혼합인가
수준에 맞지 않으면 아무리 좋은 내용도 전달되지 않습니다
핵심: 너무 쉬우면 지루하고, 너무 어려우면 이탈합니다
청중 분석 없이 시작하는 발표는 과녁 없이 쏘는 화살입니다
청중 유형별로 구체적으로 어떻게 달라야 하는지 → 다음 페이지에서 확인해봅시다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
18
청중 유형별 발표 방식 (Audience Type Guide)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
19
핵심 메시지 도출법 (Core Message)
내 발표를 한 문장으로 요약하면?
💬 핵심 메시지 (Core Message)
이 발표로 청중이 기억할 한 문장
🏗️ 구조 설계 (Structure)
핵심 메시지를 뒷받침하는 논리 흐름
🖼️ 슬라이드 제작 (Slides)
구조에 맞게 시각화
핵심 메시지 먼저 → 구조 → 슬라이드
(슬라이드 먼저 만들면 구조가 흔들린다)
핵심 메시지가 없으면 슬라이드가 아무리 예뻐도 청중은 기억하지 못합니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
20
나쁜 핵심 메시지 vs 좋은 핵심 메시지
❌ 나쁜 핵심 메시지
"저희는 MSA를 도입했습니다."
문제점:
왜 도입했는지 없음
어떤 효과가 있었는지 없음
청중이 기억할 이유가 없음
→ 단순 사실 나열, 설득력 0
✅ 좋은 핵심 메시지
"트래픽 급증에 대응하기 위해 MSA로 전환했고, 장애 격리로 서비스 안정성을 확보했습니다."
잘된 이유:
문제 상황 포함 (트래픽 급증)
선택 이유 포함 (대응)
결과/임팩트 포함 (장애 격리, 안정성)
→ 문제 → 선택 → 결과가 한 문장에
좋은 핵심 메시지 = 문제 + 선택 이유 + 결과
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
21
발표 흐름 설계 — 도입·전개·결론의 밀도
🎣 도입 (Hook) 10%
청중의 관심을 잡으세요 — 문제 제시 또는 질문으로 시작
📖 전개 (Body) 75%
핵심 메시지를 논리적으로 전개 — 주장·근거·사례 반복
🎯 결론 (Close) 15%
핵심 메시지 재강조 + 기억에 남는 한 줄 마무리
전개가 약하면 설득이 안 되고, 도입이 약하면 청중이 이탈합니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
22
강력한 도입부 설계법 (Hook Patterns)
① 😱 문제 상황으로 시작
청중이 공감할 문제를 던집니다
예시: "배포 직후 서버가 다운됐던 경험, 있으신가요?"
② 📊 숫자/데이터로 시작
구체적 수치로 임팩트를 줍니다
예시: "저희 서비스는 배포 후 3분 만에 DB 커넥션이 고갈됐습니다."
③ ❓ 질문으로 시작
청중 스스로 생각하게 만듭니다
예시: "Redis와 Memcached, 여러분이라면 어떤 걸 선택하시겠어요?"
④ 📖 짧은 스토리로 시작
감정적 공감을 유도합니다
예시: "팀원 모두가 밤새 디버깅했지만 원인을 못 찾았습니다. 그 이유는 MSA 구조에 있었습니다."
도입부의 목표는 단 하나 — 청중이 "계속 듣고 싶다"고 느끼게 하는 것입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
23
전개부 구조화 원칙 (Body Structure)
① 🖼️ 한 슬라이드 = 한 주장 (One Slide, One Message)
슬라이드 하나에 여러 주장을 넣으면 청중은 아무것도 기억하지 못합니다
→ 전달하고 싶은 것이 2개라면 슬라이드도 2장으로 나누세요
② 🔗 주장 → 근거 → 사례 순서 (Claim → Evidence → Example)
주장만 하면 설득이 안 됩니다. 반드시 근거와 실제 사례를 붙이세요
→ "MSA가 좋다(주장) / 장애 격리가 가능하기 때문(근거) / 결제 서비스 장애 시 다른 서비스 정상 운영(사례)"
③ 📝 기술 용어는 반드시 한 줄 설명 추가 (Define Technical Terms)
청중이 모르는 용어가 나오는 순간 이해가 끊깁니다
→ "Redis(인메모리 데이터 저장소)를 활용해..."처럼 괄호 설명 습관화
전개부는 발표의 심장 — 논리가 탄탄해야 설득이 완성됩니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
24
기억에 남는 결론부 설계법 (Close Patterns)
1
🔁 핵심 메시지 재강조 (Reinforce Core Message)
발표 전체를 한 문장으로 다시 요약합니다
예시: "결국 저희가 MSA를 선택한 이유는 단 하나, 장애가 전파되지 않는 구조를 만들기 위해서였습니다."
2
🚀 다음 행동 유도 (Call to Action)
청중이 발표 후 무엇을 해야 하는지 명확히 제시합니다
예시: "오늘 배운 4단계 구조로 여러분의 프로젝트 발표를 다시 설계해보세요."
3
✨ 인상적인 한 줄 마무리 (Memorable Closing Line)
청중의 기억에 남을 강렬한 문장으로 끝냅니다
예시: "좋은 코드는 동작하지만, 좋은 발표는 사람을 움직입니다."
결론은 짧고 강하게 — 마지막 인상이 전체 발표를 결정합니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
25
기술 내용을 비기술 청중에게 전달하는 법
기술 → 비유 → 임팩트 3단계 변환 프레임 (Tech → Analogy → Impact)
🔧 기술 (Tech)
전문 용어 그대로의 설명
예시: "Redis는 인메모리 캐시 데이터베이스입니다"
🌉 비유 (Analogy)
청중이 이미 아는 것에 빗대어 설명
예시: "자주 쓰는 파일을 매번 서랍에서 꺼내는 대신 바탕화면에 올려두는 것과 같습니다"
📈 임팩트 (Impact)
비즈니스/사용자 관점의 결과로 마무리합니다
예시: "덕분에 응답 속도가 10배 빨라지고, 사용자 이탈률이 줄었습니다"
비기술 청중에게 기술을 설명하려 하지 말고, 그 기술이 만드는 변화를 설명하라
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
26
구조화 실전 예시 — MSA 전환 발표
핵심 메시지 → 도입 → 전개 → 결론 전체 흐름
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
27
2교시 핵심 정리
👥 청중 분석 (Audience Analysis)
발표 전 반드시 물어라 — 누구인가? 무엇을 원하는가? 배경지식은?
청중을 모르면 구조도 없습니다
💬 핵심 메시지 (Core Message)
한 문장으로 발표를 설계하라
메시지 먼저 → 구조 → 슬라이드 순서를 지켜라
🏗️ 흐름 설계 (Flow Design)
도입(10%) · 전개(75%) · 결론(15%)의 밀도를 지켜라
주장 → 근거 → 사례로 논리를 쌓아라
"구조가 없는 발표는 지도 없는 여행입니다."
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
28
3교시 | 스토리텔링과 논리 구조 — PREP
결론부터 말하라
📌 PREP
📖 스토리텔링 (Storytelling)
💡 설득 (Persuasion)
PREP 구조로 설득력을 높이는 스토리텔링 (Storytelling with Logic)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
29
이번 시간 미리보기 (Preview)
📖 왜 스토리텔링인가?
데이터 발표 vs 스토리 발표의 차이
⚠️ A~Z 나열의 위험
청중 집중력과 기억의 법칙
🔷 PREP 구조
4단계 논리 프레임워크 완전 정복
✅ 실전 적용
백엔드 예시로 PREP 직접 써보기
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
30
왜 스토리텔링인가?
데이터는 이해시키고, 스토리는 기억시킵니다
❌ 데이터만 있는 발표
Redis 캐싱 적용, TTL 300초, 응답속도 개선 — 수치는 있지만 맥락이 없습니다
청중은 숫자를 듣는 순간 "그래서 나한테 왜 중요하지?"를 묻습니다
발표가 끝나면 수치는 사라지고 인상만 남습니다
결과: 😐 "잘 했나 보네" — 공감도, 행동도 없습니다
✅ 스토리가 있는 발표
피크 타임마다 서버가 버벅였습니다. 사용자 이탈률 35%. 그래서 Redis를 선택했습니다.
문제 → 갈등 → 선택 → 결과의 흐름이 청중을 끌어당깁니다
수치가 맥락 안에 놓이면 비로소 의미를 가집니다
결과: 💡 "맞아, 우리 팀도 그 문제 있어!" — 공감과 행동을 이끌어냅니다
"사람은 논리로 이해하고, 감정으로 기억합니다"
🧠 기억
스토리는 데이터보다 22배 더 잘 기억됩니다. (Stanford 연구)
💬 공감
청중이 "나도 그랬어"를 느끼는 순간 설득이 시작됩니다.
🎯 행동
감정적으로 납득한 청중만이 발표 후 실제 행동으로 이어집니다.
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
31
A~Z 나열 습관이 왜 위험한가
⏰ 집중력은 시간이 지날수록 급격히 떨어진다
중요한 내용을 뒤에 배치하면 아무도 듣지 않습니다
🔚 A~Z 나열의 치명적 문제
청중은 "그래서 결론이 뭔데?"를 계속 기다리다 지칩니다
🎯 해결책: 결론 먼저 (Bottom Line Up Front)
중요한 것을 앞에 말하면 집중력이 낮아져도 핵심은 전달됩니다
중요한 것을 뒤에 말하면 아무도 듣지 않습니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
32
PREP 구조란?
결론부터 말하는 4단계 논리 프레임워크입니다
P — Point (결론)
결론을 먼저 말합니다
예시: "저는 ~을 선택했습니다 / ~을 주장합니다"
R — Reason (이유)
왜 그런 결론인지 근거를 제시합니다
예시: "왜냐하면 ~이기 때문입니다"
E — Example (사례)
구체적인 사례나 데이터로 뒷받침합니다
예시: "실제로 ~한 상황에서 ~했습니다"
P — Point (재강조)
결론을 다시 한번 강조하며 마무리합니다
예시: "따라서 ~을 선택/주장합니다"
PREP는 단순한 말하기 기술이 아니라 청중의 이해 흐름을 설계하는 구조입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
33
PREP ① — Point (결론)
결론을 먼저 말하면 생기는 일
방향 설정
"아, 이 발표가 어디로 가는지 알겠다"
이해 준비
"이유와 사례를 기다리며 집중한다"
납득 완성
"처음 결론이 맞았구나, 설득됐다"
① 짧고 명확하게
한 문장으로 결론을 담습니다
② 행동/선택이 담겨야
"~했습니다"가 아니라 "~을 선택했습니다"
③ 이유를 암시해야
청중이 "왜?"라는 질문을 갖게 만듭니다
좋은 Point = 청중이 "왜?"라고 묻게 만드는 문장
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
34
PREP ② — Reason (이유)
근거를 말하는 3가지 유형
📊 데이터 기반 근거 (Data-driven)
수치와 측정 결과로 뒷받침합니다
예시: "응답 시간이 2,000ms에서 280ms로 86% 감소했습니다"
→ 가장 설득력 높음, 면접/보고 발표에 필수
🧪 경험 기반 근거 (Experience-based)
직접 겪은 상황과 결과로 뒷받침합니다
예시: "실제 배포 후 DB 커넥션이 고갈되는 문제를 겪었습니다"
→ 공감을 유도, 스토리텔링에 효과적
🔗 논리 기반 근거 (Logic-based)
인과관계와 원리로 뒷받침합니다
예시: "인메모리 접근은 디스크 I/O보다 수십 배 빠르기 때문입니다"
→ 기술 청중에게 효과적
가장 강력한 근거 = 데이터 + 경험 + 논리를 함께 쓰는 것입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
35
PREP ③ — Example (사례)
좋은 예시의 조건과 소재
① 🎯 구체적이어야 한다
"성능이 좋아졌습니다" ❌ → "응답 속도가 2초에서 280ms로 줄었습니다" ✅
② 👥 청중이 공감 가능해야 한다
청중이 경험했거나 상상할 수 있는 상황을 써라
③ ✂️ 짧고 명확해야 한다
예시가 너무 길면 본론을 잃는다. 2~3문장으로 끝내라
🗄️ DB 병목 / 쿼리 최적화 경험
🔐 인증 방식 선택 (JWT vs Session)
📦 캐싱 도입 전후 비교 (Redis)
🏗️ 아키텍처 전환 (Monolith → MSA)
🐛 장애 대응 및 디버깅 경험
🚀 배포 자동화 (CI/CD) 도입 효과
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
36
PREP ④ — Point 재강조 (Reinforce)
처음 결론과 마지막 결론의 차이
🔵 처음 Point (방향 제시)
역할: 청중에게 발표의 방향을 알려줍니다
목적: "이 발표가 어디로 가는지" 설정
톤: 선언적 — "저는 ~을 선택했습니다"
예시: "DB 병목 해결을 위해 Redis 캐싱을 도입했습니다."
🟣 마지막 Point (행동 유도/강화)
역할: 청중의 기억에 결론을 각인시킵니다
목적: "이 발표를 통해 무엇을 해야 하는가" 유도
톤: 강조적 + 행동 유도 — "따라서 ~이 최선의 선택이었습니다"
예시: "반복 조회 패턴에는 Redis 캐싱이 가장 효과적인 선택이었습니다. 여러분의 프로젝트에도 적용해보세요."
처음 Point는 방향을 잡고, 마지막 Point는 기억을 남깁니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
37
PREP 실전 예시 — Redis 캐싱
PREP 한 사이클 = 30초~1분 안에 완성되는 설득의 단위
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
38
PREP 실전 예시 — JWT 인증
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
39
PREP 실전 예시 — MSA 구조
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
40
Bad Case → PREP 변환 연습
비포/애프터로 보는 PREP 적용 효과
❌ Before (나쁜 발표 문장)
"저희 팀은 처음에 세션 방식으로 인증을 구현했습니다. 그런데 서버가 늘어나면서 문제가 생겼습니다. 그래서 JWT로 바꿨습니다. JWT는 토큰 기반 인증 방식입니다. 저희는 Access Token과 Refresh Token을 사용했습니다."
문제점 리스트:
결론이 어디 있는지 모름
이유와 사례가 뒤섞임
청중이 "그래서 뭐가 중요한 거지?" 상태
✅ After (PREP 적용)
P: "세션 확장성 문제 해결을 위해 JWT를 도입했습니다."
R: "서버 수평 확장 시 세션 동기화 문제가 발생했기 때문입니다."
E: "서버 3대 운영 시 세션 불일치로 인증 실패가 빈번했습니다."
P: "JWT로 전환 후 수평 확장이 자유로워졌습니다."
같은 내용도 구조가 바뀌면 설득력이 달라진다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
41
PREP 자가점검 체크리스트
발표 전 반드시 확인하세요 (Self-Check)
이 6가지를 통과한 발표는 이미 상위 10%입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
42
3교시 핵심 정리
🎯 P — Point (결론)
결론을 먼저 말하세요
청중에게 방향을 먼저 제시합니다
💡 R — Reason (이유)
데이터·경험·논리로 뒷받침하세요
"왜냐하면"이 설득의 핵심입니다
📌 E — Example (사례)
구체적이고 공감 가능한 사례를 쓰세요
수치와 실제 경험이 가장 강력합니다
🔁 P — Point (재강조)
마지막 문장으로 기억을 남기세요
방향 제시 → 행동 유도로 마무리합니다
"결론을 먼저 말하는 사람이 설득한다."
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
43
4교시 | 개발자답게 말하기 — 선택과 트레이드오프
우리는 왜 이걸 선택했는가
🎯 선택 이유 (Reasoning)
⚖️ 트레이드오프 (Trade-off)
🧠 개발자 사고 (Developer Thinking)
기술 설명이 아니라 선택의 이유를 말하세요 (Reasoning over Reporting)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
44
이번 시간 미리보기 (Preview)
🗣️ "썼습니다" vs "선택했습니다"
기술 설명과 기술 선택의 차이
⚖️ 트레이드오프 (Trade-off)
모든 선택에는 얻는 것과 잃는 것이 있습니다
📊 트레이드오프 실전 예시
MSA / Redis / JWT 비교표
🔗 PREP + Trade-off 통합 구조
개발자답게 말하는 완성형 프레임
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
45
"썼습니다" vs "선택했습니다"
❌ 기술 설명 (Reporting)
"저희는 MySQL을 사용했습니다."
문제점:
왜 MySQL인지 이유가 없다
다른 선택지를 고려했는지 모른다
청중: "그래서 왜 MySQL이에요?"
→ 단순 보고, 설득력 없습니다
✅ 기술 선택 (Reasoning)
"데이터 정합성이 중요한 서비스라 트랜잭션 지원이 강력한 MySQL을 선택했습니다."
잘된 이유:
요구사항(데이터 정합성)이 명확하다
선택 기준(트랜잭션 지원)이 있다
청중: "아, 그래서 MySQL이구나!"
→ 근거 있는 선택, 신뢰감 형성
"이유가 없는 기술 선택은 설득이 아니다"
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
46
기술 선택 설명의 3단계
좋은 기술 선택 설명은 이 흐름을 따른다
1
🔍 문제 / 요구사항 정의 (Problem Definition)
"우리 서비스에서 해결해야 할 것은 무엇인가?"
예시: "트래픽 증가에 따른 DB 병목 문제"
2
⚖️ 선택지 비교 (Options Comparison)
"어떤 대안들을 검토했는가?"
예시: "DB 직접 조회 vs 캐싱 레이어 추가 (Memcached / Redis)"
💡 선택 이유 + 트레이드오프 (Decision + Trade-off)
"왜 이것을 선택했고, 무엇을 포기했는가?"
예시: "Redis 선택 — 영속성 지원과 다양한 자료구조가 장점, 메모리 비용은 감수"
이 3단계를 말할 수 있는 개발자가 "생각하는 개발자"로 보입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
47
트레이드오프 (Trade-off) 란?
모든 기술 선택에는 얻는 것과 잃는 것이 있습니다
🔍 완벽한 기술은 없습니다
Redis는 빠르지만 메모리 비용이 높습니다. JWT는 간편하지만 토큰 무효화가 어렵습니다. MSA는 유연하지만 운영 복잡도가 올라갑니다.
⚖️ 상황이 최선을 결정합니다
트래픽이 적은 초기 서비스에서 MSA는 오버엔지니어링입니다. 같은 기술도 상황에 따라 독이 될 수 있습니다.
🏆 트레이드오프를 아는 개발자가 신뢰받습니다
"이 기술의 단점은 ~이지만, 우리 상황에서는 ~이 더 중요했습니다"라고 말할 수 있어야 합니다.
트레이드오프를 말하지 않는 기술 설명은 절반짜리 설명입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
48
트레이드오프 설명 프레임 (Trade-off Framework)
4단계로 기술 선택을 설득력 있게 말하는 법
1
🎯 선택한 기술 + 목적 (What & Why)
"우리는 [기술]을 [목적]을 위해 선택했습니다"
예시: "응답 속도 개선을 위해 Redis를 선택했습니다"
2
✅ 장점 — 왜 선택했나 (Gain)
"이 기술의 핵심 강점은 ~입니다"
예시: "인메모리 방식으로 DB 대비 수십 배 빠른 읽기 속도"
3
⚠️ 단점 — 무엇을 포기했나 (Cost)
"대신 ~을 감수해야 했습니다"
예시: "메모리 비용 증가, 데이터 휘발성 리스크"
4
🏆 그럼에도 선택한 이유 — 우선순위 (Priority)
"우리 서비스에서는 ~이 더 중요했기 때문입니다"
예시: "응답 속도가 사용자 경험에 직결되므로 메모리 비용보다 우선"
이 4단계를 말할 수 있으면 어떤 기술 질문에도 흔들리지 않습니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
49
트레이드오프 예시 — MSA vs 모놀리식
트래픽 증가와 장애 격리가 우선순위였기 때문에 MSA를 선택했습니다. 운영 복잡도는 감수했습니다.
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
50
트레이드오프 예시 — Redis vs DB 직접 조회
반복 조회 패턴이 많고 응답 속도가 UX에 직결되어 Redis를 선택했습니다. 캐시 무효화 전략은 별도로 설계했습니다.
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
51
트레이드오프 예시 — JWT vs Session
서버 수평 확장이 필요한 구조였기 때문에 JWT를 선택했습니다. 보안 리스크는 Refresh Token 전략으로 보완했습니다.
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
52
PREP + Trade-off 통합 구조
개발자답게 말하는 완성형 프레임
🎯 P — Point (결론)
"~을 선택했습니다"
💡 R — Reason (이유)
"왜냐하면 ~이기 때문입니다"
📌 E — Example (사례)
"실제로 ~한 상황에서 ~했습니다"
⚖️ Trade-off
"대신 ~을 감수했고, ~으로 보완했습니다"
🔁 P — Point (재강조)
"따라서 ~이 최선의 선택이었습니다"
🔶기존 PREP에서 Trade-off 단계 추가:
단순 설명 → 깊이 있는 설득
"했습니다" → "선택했습니다, 왜냐하면, 그리고 이 점은 감수했습니다"
면접관/청중이 신뢰하는 개발자로 보인다
Trade-off를 말하는 순간, 당신은 "생각하는 개발자"가 됩니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
53
통합 구조 실전 예시 — MSA 선택
PREP + Trade-off 5단계 완전 적용
이 5단계를 말할 수 있으면 어떤 기술 면접 질문도 두렵지 않습니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
54
면접에서의 트레이드오프 설명법
"트레이드오프를 알고 선택한 개발자가 신뢰를 얻습니다"
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
55
깊이 있는 말을 만드는 3가지 습관
개발자답게 말하는 사람들의 공통점
❓ "왜?"를 3번 물어보기 (5 Whys 축약)
선택의 근본 이유를 파고드는 습관입니다
예시: 
"Redis를 썼다" → 왜? "빠르니까" → 왜 빠름이 필요? "응답 지연이 문제" → 왜 지연이 생겼나? "DB 반복 조회"
→ 3번 물으면 진짜 이유가 나온다
⚖️ 비교 대상을 항상 언급하기 (Always Compare)
선택은 비교에서 나옵니다. 대안을 언급해야 선택이 설득됩니다
예시: "Redis를 선택했습니다" ❌ → "Memcached와 비교했을 때 Redis의 영속성과 자료구조 다양성이 우리 요구사항에 더 적합했습니다" ✅
📊 숫자/결과로 마무리하기 (Quantify the Impact)
추상적인 말은 기억에 남지 않습니다. 수치가 설득력을 만듭니다
예시: "성능이 좋아졌습니다" ❌ → "응답 속도가 2,000ms → 280ms로 86% 개선됐습니다" ✅
이 3가지 습관이 쌓이면 어떤 기술 질문에도 자신 있게 답할 수 있게 됩니다.
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
56
4교시 핵심 정리
선택 이유를 말하라 (Reasoning)
"썼습니다"가 아니라 "선택했습니다, 왜냐하면"
요구사항 → 선택 기준 → 선택 이유 순서로
트레이드오프를 인식하라 (Trade-off)
모든 기술에는 얻는 것과 잃는 것이 있다
단점을 아는 개발자가 신뢰받는 개발자다
PREP + Trade-off로 완성하라 (Complete Framework)
P → R → E → Trade-off → P
이 5단계가 개발자답게 말하는 완성형 구조입니다
"기술의 깊이는 선택의 이유에서 드러납니다."
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
57
5교시 | 상황별 발표 전략 (Context-based Presentation Strategy)
같은 내용, 다른 전략
🎯 상황 파악 (Context)
👥 청중 맞춤 (Audience Fit)
🔄 전략 전환 (Strategy Shift)
청중과 목적에 따라 발표 방식이 달라집니다 (Right Message, Right Audience)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
58
이번 시간 미리보기 (Preview)
발표 상황 4가지 유형
면접 / 팀협업 / 보고 / 컨퍼런스
상황별 발표 전략
면접·팀협업·보고 각각의 핵심 원칙
대면 vs 비대면
환경에 따른 전달 방식의 차이
상황 파악 체크리스트
발표 전 반드시 확인할 5가지
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
59
발표 상황의 4가지 유형
상황마다 목적과 전략이 다르다
🎯 면접 발표 (Job Interview)
목적: 역량 증명
핵심: 결과·임팩트 중심
청중: 면접관 (평가자)
👥 팀·협업 발표 (Team Sync)
목적: 맥락 공유
핵심: 이해·공감 중심
청중: 팀원 (동료)
📋 보고 발표 (Reporting)
목적: 의사결정 유도
핵심: 추천안·결론 중심
청중: 상사·경영진 (결정자)
🎤 컨퍼런스·외부 발표 (Conference)
목적: 지식 공유·인상
핵심: 인사이트·스토리 중심
청중: 불특정 다수 (관심자)
같은 내용도 청중과 목적이 바뀌면 전략이 완전히 달라집니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
60
면접 발표 전략 — 결과/임팩트 중심
면접관이 원하는 것: 이 사람이 문제를 어떻게 해결했나?
① 📊 결과 수치를 반드시 포함
"좋아졌습니다" ❌ → "응답 속도 86% 개선" ✅
면접관은 임팩트를 숫자로 확인하고 싶습니다
② 🙋 내가 기여한 부분 명확히
"팀이 했습니다" ❌ → "제가 설계하고 구현했습니다" ✅
팀 공로를 인정하되, 나의 역할을 분명히 합니다
③ 📈 실패 경험도 성장 스토리로
"실패했습니다" ❌ → "실패를 통해 ~을 배웠습니다" ✅
실패를 숨기지 말고 성장의 증거로 활용합니다
1. 🔍 문제 — 어떤 문제가 있었나?
2. 🙋 내 역할 — 내가 무엇을 맡았나?
3. 💡 해결 — 어떻게 해결했나?
4. 📈 결과 — 수치로 증명
5. 🎓 배운 점 — 무엇을 얻었나?
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
61
면접 발표 Bad vs Good 예시
❌ Bad Case
팀 프로젝트에서 백엔드를 담당했습니다.
내가 무엇을 했는지 불명확
어떤 문제를 해결했는지 없음
결과/임팩트가 전혀 없음
면접관: "그래서 이 사람이 뭘 잘하는 거지?"
✅ Good Case
사용자 인증 병목을 해결하기 위해 JWT 도입을 제안하고 직접 구현했으며, 응답 속도가 30% 개선됐습니다.
문제 명확 (인증 병목)
내 역할 명확 (제안 + 구현)
결과 수치 포함 (30% 개선)
면접관: "이 사람은 문제를 주도적으로 해결했구나"
면접 발표의 핵심 = 문제 + 내 역할 + 수치 결과
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
62
팀·협업 발표 전략 — 이해/공유 중심
협업 발표의 목적: 팀원 모두가 같은 맥락을 갖게 하는 것
① 📖 배경 설명을 충분히 (Context First)
팀원마다 알고 있는 정보가 다릅니다
→ "왜 이 작업을 하게 됐는지"부터 설명하세요
② 🔤 전문용어는 풀어서 설명 (Plain Language)
같은 팀이라도 도메인 지식 차이가 있습니다
→ 약어·기술 용어는 처음 등장 시 반드시 설명하세요
③ 🚀 다음 액션(Action Item) 명확히 (Clear Next Steps)
발표 후 "그래서 우리가 뭘 해야 하지?"가 남으면 실패입니다
→ 담당자·기한·할 일을 명확히 정리하세요
1. 🔍 배경 — 왜 이 주제를 다루는가?
2. 📊 현황 — 지금 어떤 상태인가?
3. 💡 제안/결정 — 무엇을 하려 하는가?
4. ⚠️ 리스크 — 예상되는 문제는?
5. ✅ 액션 아이템 — 누가, 언제, 무엇을?
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
63
보고 발표 전략 — 의사결정 유도 중심
보고 받는 사람이 원하는 것: 무엇을 결정해야 하나?
① 🎯 결론/추천안을 먼저 (Conclusion First)
결정권자는 시간이 없습니다
→ "저는 A안을 추천합니다"를 첫 문장에
② 📌 근거는 간결하게 3가지 이내 (Concise Evidence)
많은 근거는 오히려 결정을 흐립니다
→ 핵심 근거 2~3가지만 선별해서 제시
③ ⚠️ 리스크와 대안도 함께 제시 (Risk + Alternative)
"이것만 하면 됩니다"는 신뢰를 잃습니다
→ 예상 리스크와 플랜 B를 함께 준비
1. 📊 현황 — 지금 상황은?
2. ⚠️ 문제 — 무엇이 문제인가?
3. 💡 추천안 — 무엇을 해야 하나?
4. 📈 기대효과 — 하면 어떻게 되나?
5. 🙏 요청사항 — 무엇을 결정해달라는가?
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
64
상황별 발표 전략 비교표
한눈에 보는 4가지 발표 상황 가이드
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
65
대면 발표 vs 비대면 발표
환경이 바뀌면 전달 전략도 바뀐다
비대면 발표는 "더 작은 무대"가 아니라 "다른 무대"다 — 전략을 바꿔야 합니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
66
비대면 발표 주의사항 (온라인·줌 특화)
자주 하는 실수 4가지와 해결법
카메라 보지 않고 화면만 봄
문제: 청중 입장에서 눈을 피하는 것처럼 보입니다
해결: 카메라 렌즈를 직접 보며 말하세요. 메모는 카메라 바로 아래에 배치하세요
마이크 환경 미체크
문제: 잡음·에코·음질 불량으로 집중력 저하
해결: 발표 10분 전 반드시 음질 테스트를 하세요. 이어폰 마이크 활용을 권장합니다
화면 공유 중 딴 창 노출
문제: 알림·개인 메시지·다른 탭이 노출되어 신뢰도 하락
해결: 발표 전 알림을 끄고, 발표용 브라우저 프로필을 별도로 사용하세요
반응 없는 화면에 페이스 무너짐
문제: 청중 반응이 안 보여 자신감 저하, 말이 빨라짐
해결: 의도적으로 "잠깐 확인할게요" 멘트로 반응을 유도하세요. 페이스 유지 연습을 하세요
비대면 발표는 기술적 준비가 곧 신뢰입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
67
발표 전 상황 파악 체크리스트
이 5가지를 모르면 발표 준비가 덜 된 것이다 (Pre-Presentation Checklist)
이 5가지를 알고 시작하는 발표와 모르고 시작하는 발표는 처음부터 다릅니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
68
5교시 핵심 정리
🎯 면접 발표
문제 + 내 역할 + 수치 결과
실패도 성장 스토리로 전환하라
👥 팀·협업 발표
배경 충분히 + 용어 설명 + 액션 아이템
팀원 모두가 같은 맥락을 갖게 하라
📋 보고 발표
결론 먼저 + 근거 3개 이내 + 리스크·대안
결정권자가 바로 판단할 수 있게 하라
💻 비대면 발표
카메라·마이크·조명 사전 체크
기술적 준비가 곧 신뢰입니다
"발표의 성패는 내용이 아니라 상황 파악에서 결정된다."
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
69
6교시 | 슬라이드 설계 + 시각화 도구 활용 (Slide Design & Visualization Tools)
슬라이드는 보조 도구다
🖼️ 슬라이드 설계 (Slide Design)
📊 시각화 (Visualization)
🛠️ 도구 활용 (Tool Usage)
한 장 = 한 메시지, 디자인보다 구조 (One Slide, One Message)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
70
이번 시간 미리보기 (Preview)
🖼️ 슬라이드 설계 원칙
한 장 = 한 메시지, 텍스트 줄이기
📊 시각화 활용법
다이어그램·코드·색상·폰트 가이드
🛠️ 도구 소개
Gamma / Canva / Notion 실전 활용법
⚖️ 도구 선택 기준
상황에 맞는 도구 고르는 법
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
71
슬라이드의 역할 재정의
슬라이드는 주인공이 아니다
❌ 흔한 오해
슬라이드 = 발표의 주인공
슬라이드를 화려하게 만드는 데 집중
발표자가 슬라이드를 읽는다
청중은 발표자가 아닌 화면만 본다
결과: 발표자가 슬라이드 뒤에 숨는다
✅ 올바른 관계
발표자 = 주인공 / 슬라이드 = 보조
슬라이드는 발표자의 말을 시각적으로 보완
청중은 발표자를 보고, 슬라이드는 이해를 돕는다
슬라이드 없이도 발표가 가능해야 한다
결과: 발표자가 빛난다
"슬라이드가 없어도 발표할 수 있어야 합니다.  슬라이드는 청중의 이해를 돕는 도구일 뿐입니다."
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
72
나쁜 슬라이드의 패턴 4가지
이 중 하나라도 해당된다면 지금 바로 고쳐라
① 📝 텍스트가 빽빽하게 가득 (Text Overload)
슬라이드가 문서가 되어버립니다
청중은 읽느라 발표자 말을 듣지 않습니다
→ 키워드만 남기고 나머지는 발표자 입으로
② 🔁 발표자가 슬라이드를 그대로 읽음 (Reading Slides)
슬라이드와 발표자가 같은 말을 하면 둘 중 하나는 불필요합니다
→ 슬라이드는 키워드, 발표자는 맥락과 이유를 말하라
③ ✨ 관계없는 화려한 애니메이션 (Distracting Animation)
애니메이션이 내용보다 눈에 띄면 집중력을 빼앗습니다
→ 애니메이션은 흐름을 돕는 경우에만 최소한으로
④ 🗂️ 한 장에 여러 메시지 혼재 (Multiple Messages)
청중은 무엇을 기억해야 할지 모릅니다
→ 전달하고 싶은 것이 2개라면 슬라이드도 2장으로
나쁜 슬라이드는 발표자를 가리고, 좋은 슬라이드는 발표자를 빛나게 합니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
73
한 장 = 한 메시지 원칙 (One Slide, One Message)
❌ Before: 텍스트 과부하 슬라이드
제목: "Redis 캐싱 도입 배경 및 구현 방법과 성능 개선 결과"
• 기존 시스템에서는 동일한 상품 조회 요청이 반복적으로 발생하여 DB에 과도한 부하가 집중되었고, 이로 인해 응답 시간이 평균 2초 이상으로 증가하는 문제가 발생하였습니다.
• Redis 인메모리 캐시를 도입하여 자주 조회되는 데이터를 메모리에 저장하고 DB 직접 접근을 최소화하는 방식으로 구현하였습니다.
• 결과적으로 응답 속도가 2,000ms에서 280ms로 86% 개선되었으며 DB 쿼리 수도 70% 감소하였습니다.
→ 문제: 읽기 힘들고, 핵심이 어디 있는지 모름
✅ After: 한 메시지 슬라이드
제목: "Redis 캐싱으로 응답 속도 86% 개선"
2,000ms → 280ms
DB 쿼리 수 70% 감소
→ 이유는 발표자가 말로 설명
슬라이드에서 문장을 지울수록 발표자의 말이 살아납니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
74
텍스트 줄이기 실전 법칙
슬라이드는 문서가 아니다
① ✂️ 문장 → 키워드로 (동사 제거)
Before: "Redis 캐싱을 도입하여 응답 속도를 개선했습니다"
After: "Redis 캐싱 → 응답 속도 86% 개선"
→ 동사·조사·접속사를 제거하면 핵심만 남습니다
② 🗣️ 설명은 발표자 입으로 (Presenter Explains)
슬라이드에 있는 내용은 청중이 이미 읽습니다
→ 슬라이드에 없는 맥락·이유·배경을 발표자가 말하라
→ 슬라이드 = 키워드 / 발표자 = 스토리
③ 📏 한 슬라이드 텍스트 30자 이내 목표 (30-char Rule)
제목 포함 30자를 넘으면 다시 줄여라
→ 줄이기 어렵다면 슬라이드를 2장으로 나눠라
→ 여백이 많을수록 핵심이 강조됩니다
슬라이드를 만들 때 "이 문장이 없어도 발표할 수 있나?"를 물어보세요
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
75
다이어그램 활용법 — 언제 쓸까?
텍스트보다 다이어그램이 효과적인 4가지 상황
① 🏗️ 시스템 구조 설명 (System Architecture)
서버·DB·캐시·API 간의 관계를 텍스트로 설명하면 복잡합니다
→ 아키텍처 다이어그램 한 장이 수백 단어를 대체합니다
예시: MSA 구조, 3-tier 아키텍처
② 🔄 처리 흐름/순서 설명 (Process Flow)
"A가 일어나면 B가 되고 C가 된다"는 흐름은 화살표로
→ 플로우차트, 시퀀스 다이어그램 활용
예시: 인증 흐름, 결제 프로세스
③ ⚖️ 비교/대조 (Comparison)
두 가지 이상을 비교할 때 표나 2컬럼 다이어그램이 효과적입니다
→ 텍스트 나열보다 한눈에 차이가 보입니다
예시: MSA vs 모놀리식, JWT vs Session
④ 🌲 계층 관계 (Hierarchy)
상위-하위 관계, 포함 관계를 시각화
→ 트리 구조, 계층 다이어그램 활용
예시: 도메인 구조, 패키지 의존성
다이어그램은 "이해를 돕는 도구"다 — 복잡한 다이어그램은 오히려 혼란을 줍니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
76
백엔드 발표에 자주 쓰이는 다이어그램 유형
상황에 맞는 다이어그램을 골라라
다이어그램은 "이해를 위한 도구"입니다 — 청중이 처음 봐도 이해할 수 있어야 합니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
77
코드 슬라이드 설계법
코드를 슬라이드에 넣을 때의 3가지 원칙
① 🔍 전체 코드 X, 핵심 부분만 (Key Snippet Only)
전체 코드를 보여주면 청중은 어디를 봐야 할지 모릅니다
→ 설명하려는 핵심 로직 5~10줄만 발췌
② 🎨 하이라이트로 주목 포인트 강조 (Highlight Key Lines)
코드 블록 안에서도 핵심 라인을 색상·화살표로 강조합니다
→ "이 부분이 핵심입니다"를 시각적으로 표현
③ 💬 코드 옆에 한 줄 설명 추가 (Inline Comment)
코드만 있으면 비기술 청중은 이해 불가입니다
→ 주석 또는 옆 텍스트로 "이 코드가 하는 일"을 한 줄로
코드만 있으면 비기술 청중은 이해 불가입니다
❌ Before: 50줄짜리 전체 서비스 코드 붙여넣기
→ 청중: "어디를 봐야 하지?"
✅ After: Redis 캐시 조회 핵심 5줄만 발췌
// 캐시 조회 → 없으면 DB 조회 후 캐시 저장
String cached = redis.get(key);
if (cached == null) {
  cached = db.find(key);
  redis.set(key, cached, TTL);
}
→ 핵심 로직만, 한 줄 주석으로 설명
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
78
색상 & 폰트 기본 원칙
발표 슬라이드 디자인 가이드 (Presentation Design Guide)
🎨 색상 (Color)
✅ 2~3색 이내로 제한
✅ 강조색 1개만 사용
✅ 배경은 밝게, 텍스트는 어둡게 (대비 확보)
❌ 무지개색 사용 금지
❌ 배경과 텍스트 색상 유사 금지
🔤 폰트 (Font)
✅ 제목: 28pt 이상
✅ 본문: 18pt 이상
✅ 폰트 종류: 2가지 이내
❌ 장식용 폰트 남용 금지
❌ 10pt 이하 텍스트 금지
⬜ 여백 (White Space)
✅ 슬라이드의 30% 이상은 여백
✅ 여백이 많을수록 핵심이 강조됨
✅ 요소 간 충분한 간격 유지
❌ 빈 공간을 채우려 하지 말 것
디자인의 목적은 "예쁨"이 아니라 "가독성"입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
79
도구 소개 — Gamma
AI 기반 프레젠테이션 도구
🤖 AI 기반 자동 슬라이드 생성
텍스트 입력만으로 슬라이드를 자동 구성합니다
내용 구조화·레이아웃을 자동 제안합니다
🌐 웹 기반, 설치 불필요
브라우저에서 바로 사용합니다
링크 공유로 즉시 발표 가능합니다
📱 반응형 레이아웃
PC·모바일·태블릿 모두 최적화됩니다
화면 크기에 자동 적응합니다
📄 발표/문서/웹페이지 모두 가능
하나의 콘텐츠로 다양한 형태로 출력합니다
포트폴리오·기술 문서로도 활용합니다
언제 쓰면 좋은가?
✅ 빠르게 발표 자료를 만들어야 할 때
✅ 디자인 감각이 없어도 깔끔한 슬라이드가 필요할 때
✅ 기술 발표·포트폴리오·강의 자료
✅ 링크로 공유하는 발표 자료
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
80
도구 소개 — Canva
풍부한 템플릿 기반 디자인 도구
🎨 풍부한 템플릿 (Rich Templates)
수천 개의 전문 디자인 템플릿을 제공합니다
비개발자도 쉽게 고품질 슬라이드를 제작할 수 있습니다
👥 협업 기능 (Collaboration)
팀원과 실시간 공동 편집이 가능합니다
댓글·피드백 기능으로 리뷰가 용이합니다
🏷️ 브랜드 키트 관리 (Brand Kit)
회사/팀 색상·폰트·로고를 일괄 관리합니다
일관된 브랜드 아이덴티티를 유지할 수 있습니다
언제 쓰면 좋은가?
✅ 디자인 퀄리티가 중요한 외부 발표
✅ 팀 협업으로 슬라이드를 만들 때
✅ 브랜드 가이드라인이 있는 발표
✅ SNS 카드뉴스·인포그래픽 제작
⚠️ 주의사항:
템플릿에 의존하면 내용보다 디자인에 시간을 쏟게 됩니다
→ 구조 먼저, 디자인은 나중에
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
81
도구 소개 — Notion
문서 기반 발표 & 포트폴리오 도구
📄 기술 문서 공유 (Tech Doc Sharing)
API 명세·아키텍처 문서를 링크로 공유합니다
발표 후 청중이 직접 열람 가능합니다
🔗 링크 기반 발표 (Link-based Presentation)
URL 하나로 발표 자료를 공유합니다
버전 관리·업데이트가 쉽습니다
🗂️ 포트폴리오 형태 (Portfolio)
프로젝트별 페이지 구성
이미지·코드·링크 모두 포함 가능
✅ 장점
문서와 발표 자료를 한 곳에서 관리
링크 공유로 항상 최신 버전을 유지
기술 문서·포트폴리오에 최적화
무료 플랜으로도 충분히 활용 가능
⚠️ 단점
슬라이드 형태의 발표에는 부적합
디자인 자유도가 낮음
오프라인 발표 환경에서 불편
Notion은 "발표 도구"보다 "발표 후 공유 도구"로 더 효과적입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
82
도구 선택 기준 비교표
상황에 맞는 도구를 고르기
도구는 목적에 맞게 선택하세요 — 가장 좋은 도구는 "지금 상황에 맞는 도구"입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
83
6교시 핵심 정리
🖼️ 한 장 = 한 메시지 (One Slide, One Message)
슬라이드에서 문장을 지울수록 발표자의 말이 살아납니다
텍스트는 키워드만, 설명은 발표자 입으로
📊 시각화를 적극 활용하라 (Visualize)
다이어그램·표·코드 스니펫으로 이해를 돕습니다
복잡한 구조는 텍스트보다 그림이 낫습니다
🎨 디자인은 가독성을 위해 (Design for Readability)
색상 2~3개, 폰트 2가지, 여백 30% 이상
예쁜 슬라이드보다 읽기 쉬운 슬라이드
🤖 빠른 제작 → Gamma
🎨 디자인 퀄리티 → Canva
📝 문서 공유 → Notion
📊 세밀한 커스텀 → PPT/Keynote
"좋은 슬라이드는 발표자를 빛나게 하고, 나쁜 슬라이드는 발표자를 가립니다."
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
84
7교시 | 발표 울렁증 극복 + 나만의 발표 스타일 만들기
떨리는 건 당연하다
😰 울렁증 (Presentation Anxiety)
🎨 자기 스타일 (Personal Style)
🧠 심리 전략 (Psychological Strategy)
울렁증을 극복하는 게 아니라 활용하는 법 (Use Your Nerves)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
85
이번 시간 미리보기 (Preview)
😰 울렁증의 원인과 심리
왜 떨리는지 이해하면 덜 떨립니다
🛠️ 울렁증 완화 실전 기법
호흡·시선·페이스·리허설
🧬 성격 유형별 발표 전략
내향형·외향형·MBTI 활용
🎨 나만의 발표 스타일
강점 기반으로 나다운 발표 만들기
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
86
발표 울렁증, 얼마나 흔한가?
나뿐만 아니라 모두가 긴장합니다
발표 불안을 느끼는 사람의 비율
😰 73%의 사람이 발표를 두려워한다
전 세계적으로 발표 공포는 가장 흔한 불안 중 하나입니다
🎤 전문 발표자도 떤다
TED 연사, 스티브 잡스도 발표 전 긴장했다고 고백했습니다
💡 떨림 = 준비된 에너지
긴장감은 뇌가 "이게 중요하다"고 신호를 보내는 것입니다
"발표가 두렵다는 건 그만큼 잘하고 싶다는 뜻입니다."
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
87
울렁증의 원인 — 심리적 메커니즘
왜 떨리는지 알면 덜 떨린다 (Understanding Anxiety)
① 😟 평가받는다는 불안 (Evaluation Anxiety)
"잘못하면 어떡하지? 나를 어떻게 볼까?"
→ 뇌가 사회적 위협으로 인식해 경계 반응을 발동합니다
→ 해결: "청중은 적이 아니라 내 편이다"로 인식 전환
② 🔍 실수에 대한 과도한 집중 (Fear of Mistakes)
"말이 막히면 어떡하지? 틀리면 어떡하지?"
→ 완벽주의가 오히려 긴장을 증폭시킵니다
→ 해결: "실수는 발표의 일부다. 청중은 생각보다 관대하다"
③ ❓ 경험 부족으로 인한 불확실성 (Uncertainty)
"어떻게 될지 모른다"는 불확실성이 불안을 만듭니다
→ 경험이 쌓일수록 불확실성이 줄어듭니다
→ 해결: 리허설과 반복 경험으로 예측 가능성 높이기
울렁증의 원인을 알면 "왜 떨리는지" 이해하고, 이해하면 덜 두렵게 됩니다.
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
88
울렁증이 사실은 도움이 된다
여키스-도슨 법칙 (Yerkes-Dodson Law)
긴장 수준 vs 퍼포먼스
😴 긴장이 너무 없으면
집중력·에너지 부족 → 밋밋한 발표
"너무 편안하면 오히려 퍼포먼스가 떨어진다"
⚡ 적정 긴장 = 최고 퍼포먼스
집중력 상승, 목소리에 힘이 생김
"약간의 떨림이 발표를 살아있게 만든다"
😱 긴장이 너무 많으면
뇌가 굳고, 말이 막히고, 실수 증가
"완전히 없애려 하지 말고, 조절하는 법을 익혀라"
"떨림을 없애려 하지 말고, 적정 수준으로 조절하라"
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
89
울렁증 완화 기법 ① — 호흡법
발표 직전 2회만 해도 효과 있다
01
👃 4초 들이쉬기 (Inhale)
코로 천천히 4초 동안 숨을 들이쉰다
배가 부풀어 오르는 것을 느껴라
02
⏸️ 7초 멈추기 (Hold)
숨을 참으며 7초 동안 유지한다
이 순간 심박수가 안정되기 시작한다
03
💨 8초 내쉬기 (Exhale)
입으로 천천히 8초 동안 내쉰다
긴장이 몸 밖으로 빠져나가는 것을 상상하라
🧠 부교감신경 활성화
심박수 안정, 뇌에 산소 공급 증가
😌 근육 이완
목·어깨·손의 긴장이 풀린다
🎤 목소리 안정
떨리는 목소리가 안정되고 힘이 생긴다
발표 5분 전, 화장실에서 2회만 해도 충분합니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
90
울렁증 완화 기법 ② — 시선 처리
눈이 어디를 향하느냐가 자신감을 만든다
❌ 잘못된 시선 처리
📺 슬라이드만 본다
→ 청중과 단절, 발표자가 슬라이드를 읽는 것처럼 보입니다
👇 바닥이나 천장을 본다
→ 자신감 없어 보임, 청중이 집중력을 잃습니다
👤 한 사람에게만 집중한다
→ 나머지 청중이 소외감을 느낍니다
✅ 올바른 시선 처리
🔤 Z자 패턴으로 시선 이동
왼쪽 앞 → 오른쪽 앞 → 왼쪽 뒤 → 오른쪽 뒤
청중 전체를 골고루 포함하는 느낌을 줍니다
⏱️ 3초 룰
한 사람과 3초 눈을 맞추고 다음 사람으로 이동
너무 짧으면 불안해 보이고, 너무 길면 부담스럽습니다
😊 고개 끄덕이는 사람 찾기
긍정적 반응을 보이는 청중을 찾아 에너지를 얻으세요
그 사람을 보며 자신감을 회복하세요
시선은 자신감의 언어입니다 — 카메라(청중)를 보는 연습을 하세요
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
91
울렁증 완화 기법 ③ — 페이스 조절
긴장하면 말이 빨라진다 — 의도적으로 늦춰라
긴장 시 말속도 패턴
⏸️ 문장 끝에서 1초 쉬기
마침표가 나오면 반드시 1초 멈춥니다
→ 청중에게 이해할 시간을 주고, 발표자도 숨을 고릅니다
🎯 중요한 단어 앞에서 멈추기
"가장 중요한 것은... (멈춤) ...바로 이것입니다"
→ 강조 효과 + 자연스러운 페이스 조절
👥 청중 반응 보며 속도 맞추기
청중이 메모하거나 고개를 끄덕이면 잠깐 기다려라
→ 청중 중심 발표가 자연스럽게 페이스를 조절합니다
느리게 말하는 것이 자신감 있어 보입니다 — 빠른 말은 불안의 신호다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
92
울렁증 완화 기법 ④ — 사전 준비 & 리허설
1회 리허설이 울렁증을 50% 줄인다
리허설 횟수 vs 울렁증 수준
🗣️ 소리 내어 말하기 (Speak Aloud)
머릿속으로만 하는 연습은 실전과 다릅니다
→ 반드시 실제 목소리로 말하며 연습하세요
⏱️ 타이머 켜고 연습 (Timed Practice)
시간 감각을 익혀야 실전에서 페이스를 유지할 수 있습니다
→ 발표 시간의 90%에 맞춰 연습하세요
📹 영상 녹화 후 셀프 피드백 (Record & Review)
자신의 발표를 보는 것이 가장 빠른 개선 방법입니다
→ 시선·속도·표정·제스처를 직접 확인하세요
준비가 자신감입니다 — 리허설 없이 자신감을 기대하지 마세요
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
93
성격 유형별 발표 전략 — 내향형 vs 외향형
내향형도 외향형도 훌륭한 발표자가 될 수 있다 — 방법이 다를 뿐입니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
94
MBTI별 발표 패턴 & 보완 포인트
내 유형의 강점을 살리고 약점을 보완하라
① 🔬 분석형 (NT — INTJ/INTP/ENTJ/ENTP)
강점: 논리·데이터·구조가 탄탄합니다
약점: 감성 연결이 약하고 딱딱하게 느껴질 수 있습니다
보완: 발표 시작에 공감 스토리 한 줄 추가하세요
② 💛 친화형 (NF — INFJ/INFP/ENFJ/ENFP)
강점: 스토리텔링과 감성 전달이 뛰어납니다
약점: 구조가 흐트러지고 결론이 늦게 나옵니다
보완: PREP 구조로 결론을 먼저 말하는 연습을 하세요
③ 📋 실행형 (SJ — ISTJ/ISFJ/ESTJ/ESFJ)
강점: 준비성이 철저하고 안정적입니다
약점: 즉흥 질문·돌발 상황에 당황하기 쉽습니다
보완: 예상 질문 3개를 미리 준비하고 연습하세요
④ 🎲 탐험형 (SP — ISTP/ISFP/ESTP/ESFP)
강점: 현장감 있고 에너지가 넘칩니다
약점: 사전 준비가 부족해 구조가 없을 수 있습니다
보완: 발표 전날 반드시 전체 흐름을 한 번 정리하세요
MBTI는 참고용입니다 — 유형에 갇히지 말고 강점을 극대화하라
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
95
나만의 발표 스타일 찾기 — 강점 기반 접근
3가지 질문으로 나의 발표 스타일을 탐색하라
① 🧠 나는 논리형인가, 감성형인가?
논리형: 데이터·구조·근거로 설득하는 것이 편합니다
감성형: 스토리·공감·감정으로 연결하는 것이 편합니다
→ 둘 다 강력합니다. 나의 자연스러운 방향을 파악하라
② 🗣️ 나는 말이 많은 편인가, 간결한 편인가?
말이 많은 편: 풍부한 설명이 강점, 시간 관리가 과제입니다
간결한 편: 핵심 전달이 강점, 충분한 설명이 과제입니다
→ 강점을 살리되, 약점을 보완하는 방향으로
③ 📋 나는 준비된 대로 하는 편인가, 즉흥적인 편인가?
준비형: 철저한 리허설로 안정감 확보
즉흥형: 큰 흐름만 잡고 현장 반응에 맞게 조절
→ 어느 쪽이든 최소한의 구조는 필요합니다
최고의 발표자를 따라 하지 말고, 최고의 나를 만들어라
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
96
발표 스타일 4가지 유형
나는 어떤 스타일인가?
📊 논리 설득형 (Logic-driven)
데이터와 구조로 압도합니다
강점: 신뢰감, 설득력, 명확성
대표 멘트: "수치로 증명하겠습니다"
보완: 감성 연결 포인트를 1~2개 추가하라
📖 스토리텔러형 (Story-driven)
공감과 흐름으로 청중을 끌어당깁니다
강점: 기억에 남음, 감정적 연결
대표 멘트: "이런 일이 있었습니다"
보완: PREP 구조로 결론을 먼저 말하라
⚡ 간결 임팩트형 (Impact-driven)
짧고 강하게, 핵심만 전달합니다
강점: 명확함, 시간 효율, 기억에 남는 한 줄
대표 멘트: "결론은 하나입니다"
보완: 충분한 근거와 사례를 추가하라
🤝 친절 설명형 (Clarity-driven)
천천히, 모두가 이해하게 만듭니다
강점: 포용성, 이해도 높음, 신뢰감
대표 멘트: "함께 따라오시면 됩니다"
보완: 페이스를 높이고 결론을 먼저 말하라
어떤 스타일이든 구조 + 연습이 뒷받침되면 강력해집니다
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
97
나만의 스타일 개발 로드맵
최고의 발표자를 따라 하지 말고, 최고의 나를 만들어라
1
🔍 현재 스타일 파악 (Self-Awareness)
나는 어떤 유형인가? 강점과 약점은?
→ 최근 발표를 녹화해서 객관적으로 분석하세요
→ 3가지 질문으로 나의 자연스러운 방향을 파악하세요
2
💪 강점 극대화 (Amplify Strengths)
내가 잘하는 것을 더 잘하게 만들어라
→ 논리형이라면 데이터를 더 강력하게
→ 스토리형이라면 구조를 더 탄탄하게
→ 강점이 발표의 핵심 무기가 됩니다
3
🛠️ 약점 보완 (Patch Weaknesses)
약점을 없애는 게 아니라 "치명적이지 않게" 만들어라
→ 논리형: 도입부에 공감 스토리 1개 추가
→ 스토리형: PREP 구조로 결론 먼저 말하기 연습
→ 약점은 보완하되, 강점에 집중하세요
"완벽한 발표자가 되려 하지 말고, 나다운 발표자가 되어보세요"
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
98
7교시 핵심 정리
😰 울렁증은 정상이다 (It's Normal)
73%가 발표를 두려워합니다
적정 긴장은 오히려 퍼포먼스를 높입니다
🛠️ 실전 기법 4가지 (Practical Techniques)
호흡 (4-7-8) → 시선 (Z자·3초 룰) → 페이스 (1초 멈춤) → 리허설 (소리·타이머·녹화)
준비가 자신감입니다
🧬 성격 유형을 활용하라 (Use Your Type)
내향형·외향형 모두 강점이 있습니다
MBTI 유형의 강점을 극대화하고 약점을 보완하라
🔍 현재 스타일 파악
💪 강점 극대화
🛠️ 약점 보완
🎨 나다운 발표자로 성장
"완벽한 발표자는 없습니다. 준비된 발표자만 있을 뿐입니다."
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
99
8교시 | 전달력 향상 + 마무리
말하는 방식이 내용만큼 중요하다
🎙️ 전달력 (Delivery)
🤝 비언어 커뮤니케이션 (Non-verbal)
🏁 마무리 (Wrap-up)
전달력은 타고나는 게 아니라 훈련되는 것입니다 (Delivery is a Skill)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
100
이번 시간 미리보기 (Preview)
🎙️ 전달력의 3요소 — 메라비언 법칙 (Mehrabian's Rule)
🔊 목소리 & 속도 — 톤·페이스 조절 (Voice & Pace)
👁️ 시선·제스처·자세 — 비언어 전략 (Non-verbal Strategy)
🏁 Q&A 대응 & 마무리 — 성장하는 발표자 (Growth Mindset)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
101
이번 시간 미리보기 (Preview)
"내용만 좋다고 전달이 잘 되지 않는다 — 메라비언 법칙 (Mehrabian's Rule)"
메라비언 법칙이란?
1971년 심리학자 앨버트 메라비언이 발표한 커뮤니케이션 이론으로, 사람이 상대방에게 받는 인상은 말의 내용, 목소리, 비언어라는 3가지 요소로 구성됩니다.
7%
말의 내용 (언어, 단어)
38%
목소리 (톤, 속도, 크기, 억양)
55%
비언어 (표정, 시선, 자세, 제스처)
📊 메라비언 법칙이 말하는 것
청중은 내용보다 전달 방식에 더 영향을 받는다
목소리 톤, 속도, 표정, 제스처가 신뢰를 결정한다
슬라이드가 완벽해도 전달이 나쁘면 설득 실패
"발표는 정보 전달이 아니라 신뢰 전달입니다"
핵심 메시지: 내용보다 "어떻게 말하느냐"가 전달력의 93%를 차지합니다.
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
102
목소리 — 톤과 속도 (Voice & Pace)
좋은 목소리 활용법 4가지
🔑 중요한 단어는 천천히, 크게
핵심 단어에서 속도를 줄이고 볼륨을 높여야 합니다 (Emphasis)
⬇️ 문장 끝을 올리지 않기
질문 억양(Rising Intonation)은 자신감을 떨어뜨립니다
⏸️ 침묵(Pause)을 두려워하지 말기
멈춤은 청중이 내용을 소화하는 시간입니다
⏱️ 1분 150~180단어 속도 유지
너무 빠르면 이해 불가, 너무 느리면 집중력 저하
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
103
목소리 Bad vs Good 예시
❌ Bad — 빠르고 단조로운 패턴
"저희는 Redis를 도입했고요, 캐싱을 적용했고요, 성능이 개선됐고요, 응답속도가 빨라졌고요..."
문장마다 "~고요"로 끝나는 나열
속도 변화 없이 일정한 톤
강조 없이 모든 내용이 동등하게 들림
청중이 어디가 핵심인지 모름
✅ Good — 강조+멈춤+속도 변화 패턴
"저희는 Redis를 도입했습니다. [멈춤] 그 결과... 응답속도가 3배 빨라졌습니다."
핵심 수치 앞에서 의도적 멈춤(Pause)
"3배"를 천천히, 크게 강조
문장을 짧게 끊어 호흡 조절
청중이 핵심을 자연스럽게 인식
"침묵은 약점이 아니라 무기다 (Silence is Power)"
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
104
시선 처리 (Eye Contact)
올바른 시선 처리 가이드 — 눈이 어디를 향하느냐가 자신감을 만듭니다
👤 한 사람에게 3초 → 다음 사람으로
한 문장을 한 사람에게 완성하듯 말하고 이동 (3-Second Rule)
🔤 Z자 또는 W자 패턴으로 스캔
청중 전체를 골고루 커버하는 시선 이동 경로입니다
📺 화면/노트를 보는 시간 30% 이내로
슬라이드를 읽는 발표자는 신뢰를 잃습니다
❌ 피해야 할 시선 패턴
화면만 보며 발표
한 곳만 고정 응시
바닥이나 천장 보기
노트를 읽는 행동
✅ 권장 시선 패턴
청중과 눈을 맞추며 대화하듯
고개를 들고 자신감 있게
반응 좋은 청중에게 에너지 받기
발표 전 청중 얼굴 미리 파악
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
105
제스처와 자세 (Gesture & Posture)
✅ 효과적인 제스처 3가지
🤲 손바닥 열기 (Open Palm)
개방적이고 신뢰감 있는 신호 (Openness Signal)
🖐️ 숫자 표현 시 손가락 활용
"세 가지가 있습니다" → 손가락 3개로 시각화
👆 강조할 때 포인터/테이블 활용
핵심 내용에서 시각적 주의 집중 유도
❌ 피해야 할 자세
🙅 팔짱 끼기
방어적·폐쇄적 인상 (Defensive Posture)
👖 주머니에 손 넣기
자신감 없어 보임 (Lack of Confidence)
🔄 좌우로 흔들기
불안감을 드러내는 습관 (Nervous Habit)
📱 발표 중 핸드폰 만지기
집중력 분산 신호
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
106
비대면 발표 전달력 특화 전략 (Online Delivery)
줌/온라인 발표에서의 전달력 체크리스트
🖥️ 환경 세팅 (Setup)
🎙️ 전달 방식 (Delivery)
카메라와 화면 사이를 자연스럽게 오가기
렌즈만 고정하면 오히려 어색합니다. 슬라이드 확인 → 렌즈 응시를 자연스럽게 번갈아 하면 충분합니다
목소리를 평소보다 10% 크게
온라인은 에너지가 반감됩니다
반응을 과장되게 표현하기
고개 끄덕임, 미소를 의도적으로 크게
슬라이드 전환 전 "다음으로 넘어가겠습니다" 예고
내용이 전환될 때는 청중이 따라오게 유도해주면 좋습니다.
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
107
Q&A 대응 전략 (Q&A Strategy)
질문을 받을 때의 3단계 플로우
👂 질문 듣기 + 한 줄 요약 반복
"지금 질문하신 내용은 ~에 관한 것이죠?" 확인 후 답변 시작 (Active Listening)
🤔 모르면 솔직히 + 찾아보겠다고
"지금 바로 답변드리기 어렵지만, 확인 후 공유드리겠습니다" (Intellectual Honesty)
✅ 답변 후 확인
"제 답변이 도움이 됐나요?" 또는 "추가로 궁금한 점 있으신가요?" (Confirmation)
❌ Q&A에서 자주 하는 실수
질문을 끝까지 듣지 않고 답변 시작
모르는 것을 아는 척 얼버무리기
너무 길게 답변해서 다른 질문 기회 차단
방어적으로 반응하기
✅ Q&A 고수의 태도
질문자에게 감사 표현 후 시작
모른다고 하는 것이 신뢰를 높인다
핵심만 간결하게 30초 이내로
질문을 발표의 연장선으로 활용
"모른다고 하는 것이 아는 척보다 신뢰를 높인다 (Honesty builds credibility)"
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
108
오늘 특강 전체 복습 — 1~8교시 핵심 흐름
8교시 전체 여정을 한 장에 정리
1교시 — 발표의 목적 (Purpose)
발표는 설득입니다. 정보 전달이 아닙니다
2교시 — 논리적 흐름 (Structure)
핵심 메시지에서 출발하는 구조화 전략
3교시 — PREP 구조 (PREP Framework)
결론부터 말하는 4단계 논리 프레임
4교시 — 트레이드오프 (Trade-off)
기술 선택의 이유를 설득력 있게 말하는 법
5교시 — 상황별 전략 (Context Strategy)
면접·팀·보고·컨퍼런스 맞춤 전략
6교시 — 슬라이드 설계 (Slide Design)
한 장 = 한 메시지, 시각화 원칙
7교시 — 울렁증 & 스타일 (Anxiety & Style)
나만의 발표 스타일 개발
8교시 — 전달력 (Delivery)
목소리·시선·제스처·Q&A 완성
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
109
나의 발표 체크리스트 (Final Checklist)
발표 전 반드시 확인하세요 (Self-Check Before Every Presentation)
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
110
성장하는 발표자가 되는 법 (Growth Loop)
발표 실력은 횟수에 비례한다
🎤 발표 (Present)
실전에서 직접 발표합니다
📝 피드백 수집 (Feedback)
녹화 또는 청중 반응을 분석합니다
🔧 개선 (Improve)
한 가지씩 고쳐서 다음 발표에 적용합니다
📈 성장 가속화 팁
🎥 발표를 녹화해서 본인이 시청하기
가장 빠른 피드백 루프
👥 스터디 그룹에서 발표 연습하기
실전과 유사한 환경 조성
📖 좋은 발표 영상 분석하기
TED, 컨퍼런스 발표 벤치마킹
✍️ 발표 후 3가지 개선점 메모하기
성장 일지 작성
"발표 실력은 타고나는 것이 아니라 반복으로 만들어진다 (Deliberate Practice)"
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
111
오늘 특강 핵심 요약 (Key Takeaways)
6가지 키워드로 압축
🏗️ 구조 (Structure)
핵심 메시지에서 출발하는 논리적 흐름 설계
🔁 PREP
결론 → 이유 → 사례 → 재강조, 결론부터 말하라
⚖️ 트레이드오프 (Trade-off)
기술 선택의 이유와 득실을 설득력 있게 설명
🎯 상황 파악 (Context)
청중·목적·환경에 맞는 맞춤 전략
📊 시각화 (Visualization)
한 장 = 한 메시지, 다이어그램과 표 적극 활용
🎙️ 전달력 (Delivery)
목소리·시선·제스처·Q&A로 완성되는 발표
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
112
코드는 서버에서 실행된다.
하지만 커리어는 당신의 말로 증명된다.
Great engineers build great systems. Great communicators build great careers.
🎤 발표력
🧠 설득력
🚀 커리어 성장
말하는 방식은 내용만큼 중요합니다. 전달력은 훈련된다는 걸 잊지 마세요!

여러분의 다음 발표를 응원합니다 💪
감사합니다.
기술을 말하는 기술
COPYRIGHT© DAMISEO All rights reserved.
113