중간발표: MVP 프레젠테이션

이번 주 읽기: 발표는 기술 자랑이 아니다

7주 동안 팀 프로젝트를 진행했다. 이번 주는 중간발표다. 그런데 발표라고 하면 보통 “우리가 만든 기능을 보여드리겠습니다” 하고 버튼을 클릭하는 장면을 떠올린다. 하지만Gainer(2025)는 상담 기술 프로젝트의 발표는 그런 기술 시연과 근본적으로 달라야 한다고 말한다.

왜 다를까? 상담 도구는 사람의 마음을 다루는 도구이기 때문이다. “이 버튼을 누르면 위기 감지 기능이 작동합니다”라고 설명하는 것과, “자해 충동을 느끼는 내담자(상담을 받는 사람)가 이 화면을 열면, 3초 안에 전문가와 연결됩니다”라고 설명하는 것은 같은 기능을 소개하지만 관점이 완전히 다르다. 첫 번째는 기술 중심, 두 번째는 내담자 중심이다.

이 차이를 일상적 예로 들어보자. 새 냉장고를 파는 광고를 생각해보라. “이 냉장고는 인버터 컴프레서를 탑재하고 에너지 효율 1등급입니다” 하는 건 기술 중심 설명이다. “한밤중에 물 마시러 일어났을 때, 냉장고 소리가 거의 안 들려서 가족이 깨지 않습니다” 하는 건 사용자 중심 설명이다. 상담 도구의 발표도 마찬가지다. 기술 스펙이 아니라, 그 기술이 내담자의 경험을 어떻게 바꾸는지를 이야기해야 한다.

세네카 R. 게이너

상담 기술의 가치는 코드가 얼마나 정교한가로 결정되지 않는다. 그 코드가 내담자의 삶에 어떤 변화를 만드는가로 결정된다. 발표란 바로 그 변화의 가능성을 동료에게 설득하는 과정이다.

— Gainer (2025, p. 289)

Gainer는 이런 발표 방식을 “내담자 중심 설계 발표(Client-Centered Design Presentation)”라고 부른다. 네 단계로 구성된다. (1) 내담자가 겪는 고통이 무엇인지 설명한다. (2) 기존에는 이 문제를 어떻게 다뤘고, 왜 한계가 있었는지 짚는다. (3) 우리 AI 도구가 구체적으로 어떤 개선을 제공하는지 보여준다. (4) 아직 남아 있는 윤리적 문제와 앞으로의 계획을 솔직히 밝힌다.

이 네 단계가 왜 이런 순서일까? 청중의 심리를 생각해보면 이해가 된다. 먼저 문제를 제시하면 청중은 “그래, 이건 해결할 가치가 있는 문제야”라고 공감한다. 기존 한계를 짚으면 “기존 방법으로는 안 되는구나”라는 긴장이 생긴다. 그다음 솔루션을 보여주면 “아, 이렇게 하면 되는구나”라는 해소감을 느낀다. 마지막으로 한계를 솔직히 밝히면 “이 팀은 자기 도구의 한계를 알고 있구나”라는 신뢰가 쌓인다.

특히 4단계(한계 인정)가 상담 도구 발표에서 결정적으로 중요한 이유가 있다. 상담 도구는 사람의 정신건강을 다루기 때문에, 한계를 모르고 쓰면 해를 끼칠 수 있다. “우리 AI는 100% 정확합니다”라고 말하는 팀과, “우리 AI의 감정 인식 정확도는 현재 78%이고, 나머지 22%의 오류를 줄이기 위해 이런 보완 장치를 설계했습니다”라고 말하는 팀 중에서, 실제 상담 현장에서 더 신뢰받는 건 후자다.

칼 로저스

진정한 소통은 상대방의 내적 참조 틀에서 세상을 보려는 노력에서 시작된다. 발표도 마찬가지다 — 청중이 무엇을 알고 싶어하는지, 어떤 우려를 가지고 있는지를 먼저 이해해야 한다.

— Rogers (1961)

동료 피드백은 왜 중요한가

발표 뒤에는 다른 팀이 피드백을 준다. 피드백이라고 하면 “잘했어요” “더 노력하세요” 같은 말을 떠올리기 쉬운데, 이런 피드백은 사실 학습에 거의 도움이 되지 않는다. 교육학 연구에 따르면, 효과적인 피드백은 세 가지 질문에 답한다. “목표가 무엇인가?” “지금 어디에 있는가?” “다음에 뭘 해야 하는가?”

일상적인 예를 들어보자. 운전을 배울 때 옆에서 “잘하고 있어”라고만 하면 도움이 안 된다. “지금 속도가 좀 빠르니까, 커브에서 30km/h로 줄여봐”라고 해야 구체적으로 뭘 고쳐야 하는지 알 수 있다. 프로젝트 피드백도 마찬가지다. “좋았습니다”보다 “접수 면접 화면에서 내담자가 동의서를 읽지 않고 넘어갈 수 있는 구조인데, 스크롤을 끝까지 내려야 동의 버튼이 활성화되는 방식은 어떨까요?”가 훨씬 유용하다.

Gainer(2025)는 이걸 상담 분야에 맞게 바꿔서 “공감적 피어 리뷰(Empathic Peer Review)”라고 부른다. 핵심은 피드백을 주는 사람이 “비평가”가 아니라 “함께 개선하는 동료” 역할을 한다는 것이다. 상담사 훈련에서 수퍼비전(선배 상담사의 지도)이 평가가 아니라 성장을 돕는 과정이듯, 동료 피드백도 약점을 지적하는 게 아니라 개선 가능성을 함께 찾는 과정이다.

공감적 피어 리뷰의 핵심은 “의도를 먼저 이해하라”는 것이다. 상대 팀이 왜 그런 설계를 했는지를 먼저 파악한 뒤에 제안을 해야 한다. “왜 이렇게 만들었어요?”라고 질문하는 건 비난이 아니라 탐색이다. 의도를 이해하면 더 정확한 피드백을 줄 수 있고, 받는 사람도 방어적이 되지 않는다. 이건 상담에서 “판단 없이 경청하기”와 같은 원리다.

마이클 램버트

치료 효과의 가장 강력한 예측 변인은 내담자-상담사 관계다. 동료 피드백에서도 마찬가지 — 피드백의 효과는 말의 내용보다, 주는 사람과 받는 사람의 관계의 질에 달려 있다.

— Lambert (2013)

구체적으로는 SBI 모델을 사용한다. S(Situation, 상황) — 어떤 장면에서, B(Behavior, 행동) — 어떤 기능이, I(Impact, 영향) — 어떤 효과를 냈는지를 연결해서 말하는 것이다. “접수 면접 화면에서 위기 플래그가 바로 표시되는 기능이 상담사의 판단 시간을 30초 이상 줄일 것 같다”처럼 말이다. 이렇게 하면 받는 사람도 정확히 뭘 고치면 되는지 알 수 있다.

SBI 모델의 반대 예도 보자. “UI가 별로예요” — 이건 S도, B도, I도 없다. 받는 사람은 뭘 어떻게 고쳐야 하는지 전혀 모른다. “전체적으로 좋은데 좀 아쉽네요” — 역시 구체적 정보가 없다. 반면 “위기 감지 화면(S)에서 긴급 연락처 버튼(B)이 화면 하단에 있는데, 위기 상황에서 내담자가 스크롤해야 찾을 수 있어서 접근이 늦어질 수 있다(I). 상단 고정 배너로 바꾸면 어떨까요?” — 이것이 SBI 모델의 좋은 예다.

MVP란 무엇인가: 완성이 아닌 검증

중간 발표에서 보여주는 건 완성품이 아니라 MVP(Minimum Viable Product, 최소 기능 제품)다. MVP의 핵심은 “이 아이디어가 실제로 작동하는가?”를 검증하는 것이다. 완벽한 디자인이나 모든 기능을 갖출 필요가 없다. 핵심 가설을 테스트할 수 있는 최소한의 기능만 있으면 된다.

MVP 개념의 역사를 잠깐 보자. 이 용어는 실리콘밸리의 린 스타트업(Lean Startup) 방법론에서 나왔다. 페이스북의 첫 버전은 하버드 대학교 학생들만 쓸 수 있는 간단한 프로필 페이지였다. 인스타그램의 첫 버전은 사진에 필터를 걸어 공유하는 기능 하나뿐이었다. 이들은 완성품을 만들기 전에 “사람들이 이 기능을 원하는가?”를 먼저 확인한 것이다. 상담 도구도 마찬가지다. 접수 면접 자동화 도구를 만든다면, 모든 상담 이론을 반영한 완벽한 시스템이 아니라, 기본적인 질문 흐름과 위기 감지 기능만 있어도 “이 접근이 유용한가?”를 검증할 수 있다.

MVP에서 흔히 하는 실수가 “Minimum”에만 집중하는 것이다. “Viable(쓸 만한)”도 핵심이다. 로그인도 안 되고, 버튼을 눌러도 반응이 없는 프로토타입은 최소이기는 하지만 쓸 만하지는 않다. 핵심 기능 하나가 처음부터 끝까지 제대로 작동하는 게 MVP의 기준이다. 상담 도구라면 “내담자가 접속해서 기본 정보를 입력하고, AI가 선별 질문을 제시하고, 결과를 상담사에게 전달하는” 전체 흐름이 끊기지 않고 돌아가야 한다.

발표 불안 다루기: 상담학과 학생도 떨린다

발표 앞에서 긴장하는 건 자연스러운 반응이다. 심리학에서는 이것을 “수행 불안(performance anxiety)”이라고 부른다. 흥미로운 점은 상담심리학을 전공하는 학생들도 발표 불안을 똑같이 경험한다는 것이다. 상담사가 되려면 남 앞에서 말하는 게 익숙해야 할 것 같지만, 실제로는 다른 사람 앞에서 자기 작업물을 보여주는 것과, 상담실에서 내담자와 1대1로 대화하는 것은 완전히 다른 상황이다.

발표 불안을 줄이는 실용적 방법 세 가지가 있다. 첫째, 충분한 리허설이다. 연구에 따르면 발표를 3회 이상 소리 내어 연습한 사람은 그렇지 않은 사람보다 불안 수준이 40% 낮았다. 둘째, 발표를 “평가”가 아닌 “공유”로 재정의하는 것이다. “나를 평가하는 자리”라고 생각하면 위협이 되지만, “내가 배운 것을 나누는 자리”라고 생각하면 부담이 줄어든다. 셋째, 완벽하지 않아도 괜찮다는 것을 인정하는 것이다. MVP를 보여주는 것이므로, 미완성인 부분이 있는 게 당연하다.

세네카 R. 게이너

완벽한 프로토타입은 존재하지 않는다. 중요한 건 핵심 가설을 테스트할 수 있느냐다. '이 AI 도구가 상담 과정의 이 문제를 개선하는가?' — 이 한 가지 질문에 답할 수 있으면 MVP는 성공이다.

— Gainer (2025, p. 291)

MVP 발표: 10분 안에 프로젝트의 가치 전달하기

MVP는 Minimum Viable Product의 약자로, “핵심 기능만 갖춘 최소한의 제품”이라는 뜻이다. 완성품을 보여주는 게 아니라, 가장 중요한 아이디어가 실제로 작동하는지를 검증하는 게 목적이다. 우리 프로젝트에서는 “이 AI 도구가 상담 과정의 특정 문제를 개선할 수 있는가?”가 핵심 가설이다.

발표는 총 10분이다. 네 단계로 나눈다. 1단계(2분): 문제 정의. 상담 현장에서 실제로 겪는 문제를 데이터와 사례로 설명한다. 예를 들어 “상담사가 접수 면접에 평균 45분을 쓴다”, “위기 내담자의 30%가 첫 상담 전에 이탈한다”처럼 숫자로 보여주면 설득력이 높다.Gainer(2025)는 여기에 익명화된 내담자 사례를 포함하라고 권한다. 기술적 문제를 인간적 맥락에 놓으면 청중이 훨씬 공감한다.

문제 정의 단계에서 흔히 하는 실수가 있다. 문제를 너무 넓게 잡는 것이다. “한국의 정신건강 관리 시스템에 문제가 있습니다”는 2분 안에 설명할 수 없다. “대학 상담센터에서 접수 면접 대기 시간이 평균 2주인데, 그 사이에 30%의 학생이 상담을 포기합니다”처럼 구체적이고 좁은 문제를 잡아야 한다. 문제가 구체적일수록 솔루션도 명확해지고, 청중도 쉽게 이해한다.

2단계(2분): 이론 + 기술 접근. 어떤 상담 이론과 AI 기술을 결합했는지 설명한다. 여기서 함정이 있다. “GPT-4 API를 사용했습니다” 같은 기술 나열은 피한다. 대신 “내담자의 인지적 왜곡(잘못된 생각 패턴)을 실시간으로 파악하기 위해 LLM(대규모 언어 모델)의 맥락 이해 능력을 활용했습니다”처럼, 기술이 상담에 어떻게 쓰이는지를 설명한다.

이론과 기술을 연결하는 좋은 방법은 “~이론에 따르면, ~가 치료적으로 중요한데, 기존에는 ~한 한계가 있었고, AI의 ~능력을 활용하면 이 한계를 극복할 수 있다”는 구조로 설명하는 것이다. 예를 들어 “Beck의 인지행동 치료에 따르면, 자동적 사고(automatic thoughts)를 포착하는 것이 핵심인데, 내담자가 상담실 밖에서 경험하는 자동적 사고는 기존에 기록하기 어려웠고, AI 챗봇의 실시간 대화 기능을 활용하면 일상에서 자동적 사고를 즉시 포착하고 분석할 수 있다”는 식이다.

아론 T. 벡

인지행동치료의 핵심은 내담자가 자신의 자동적 사고를 인식하는 것이다. 이 인식 자체가 변화의 첫 걸음이다. 기술이 이 인식의 기회를 넓힐 수 있다면, 치료의 도달 범위도 넓어진다.

— Beck (1979)

3단계(4분): 라이브 데모. 가장 핵심적인 기능을 실시간으로 보여준다. 흔한 실수가 모든 기능을 다 보여주려는 것이다. 하나의 사용 시나리오를 처음부터 끝까지 완전하게 보여주는 게 훨씬 효과적이다. 예를 들어 “내담자가 접속 → 기본 정보 입력 → AI가 선별 질문 제시 → 위기 플래그 감지 → 상담사 대시보드에 알림”이라는 전체 흐름을 보여주는 식이다.

라이브 데모에서 가장 무서운 건 “데모의 저주(demo curse)”다. 연습할 때는 잘 돌아가던 기능이 발표 중에 갑자기 안 되는 현상이다. 이건 실제로 자주 일어난다. 대비 방법은 세 가지다. 첫째, 인터넷 연결이 끊겨도 작동하는 로컬 버전을 준비한다. 둘째, 주요 화면을 미리 캡처해서 백업 슬라이드로 만들어둔다. 셋째, “지금 기술적 문제가 있네요. 이 화면은 이렇게 작동합니다”라고 자연스럽게 넘어가는 멘트를 준비한다. 기술적 문제에 당황하는 것보다, 침착하게 대응하는 모습이 오히려 전문성을 보여준다.

세네카 R. 게이너

한계를 인식하지 않는 기술 발표는 윤리적으로 미성숙한 발표다. 상담 도구를 발표할 때, 아직 해결하지 못한 문제를 솔직히 밝히는 것이야말로 전문가다운 태도다.

— Gainer (2025, Chapter 12)

4단계(2분): 한계와 후반부 계획. 현재 프로토타입(시제품)의 기술적 한계(정확도, 안정성), 윤리적 과제(비밀보장, 편향, 안전장치 미비), 사용자 피드백에서 나온 개선점을 솔직하게 공유한다. 그리고 9~15주차에 무엇을 할 계획인지 로드맵을 제시한다.

한계를 말할 때도 구조를 갖추면 훨씬 전문적으로 들린다. “아직 많이 부족합니다”라는 모호한 말 대신, “기술적 한계: 감정 인식 정확도가 78%로, 분노와 좌절을 구분하지 못합니다. 윤리적 한계: 위기 감지 시 자동 알림 기능이 아직 구현되지 않았습니다. 개선 계획: 9주차에 윤리 모듈을 추가하고, 11주차에 감정 인식 모델을 개선합니다”처럼 범주별로 나눠서 말하자.

피어 리뷰: 세 가지 평가 기준

피어 리뷰(동료 평가)는 세 가지 기준으로 진행한다. 첫째, 기능성(30%) — 핵심 기능이 의도대로 작동하는가? 상담 과정을 실제로 개선하는가? 둘째, 윤리성(40%) — 비밀보장, 안전장치, 위기 대응이 적절한가? 내담자에게 해가 되지 않는가? 셋째, 사용성(30%) — 상담사와 내담자가 직관적으로 쓸 수 있는가?

윤리성에 가장 높은 비중(40%)을 준 이유가 있다. 상담 도구는 사람의 마음을 다루기 때문이다. 기능이 아무리 뛰어나도 윤리적 안전장치가 없으면, 그 도구는 내담자에게 해를 끼칠 수 있다. 날카롭지만 안전장치 없는 수술 도구와 같은 것이다.

각 기준을 평가할 때 구체적으로 뭘 봐야 하는지 정리해보자. 기능성에서는 “이 기능이 실제로 상담 현장의 문제를 해결하는가?”를 핵심 질문으로 삼는다. 멋있어 보이지만 쓸모없는 기능은 높은 점수를 받을 수 없다. 윤리성에서는 “이 도구가 내담자에게 해를 끼칠 가능성은 없는가?”를 본다. 위기 감지 기능이 없거나, 면책 고지가 빠져 있거나, 개인정보 처리 방침이 없으면 감점 요인이다. 사용성에서는 “상담사나 내담자가 설명서 없이 쓸 수 있는가?”를 본다.Krug의 원칙대로, 사용자가 생각할 필요 없이 직관적으로 쓸 수 있어야 한다.

제이콥 닐슨

사용성 테스트에서 5명의 사용자만 테스트해도 사용성 문제의 85%를 발견할 수 있다. 완벽한 테스트보다 빈번한 테스트가 더 효과적이다.

— Nielsen (2000)

질의응답: 방어가 아니라 대화

발표 후 5분간의 질의응답 시간이 있다. 질문을 받으면 방어적으로 반응하기 쉽다. “그건 원래 그렇게 설계한 건데요” “시간이 부족해서 못 했어요” 같은 답변은 건설적이지 않다. 대신 세 단계로 응답하자. 첫째, 질문을 재진술한다(“위기 감지의 정확도에 대한 질문이시죠?”). 둘째, 현재 상태를 솔직히 말한다(“현재 정확도는 78%이고, 거짓 양성이 12%입니다”). 셋째, 개선 계획을 제시한다(“후반부에 학습 데이터를 늘려서 90% 이상을 목표로 하고 있습니다”).

흥미롭게도 이 세 단계는 상담에서 “반영(reflection)” 기법과 구조가 같다. 상담사가 내담자의 말을 먼저 반영하고, 현재 상태를 함께 확인하고, 다음 단계를 논의하는 것이다. 질의응답에서도 질문자의 의도를 먼저 이해하고, 사실을 공유하고, 함께 해결 방향을 모색하는 자세가 효과적이다.

피드백을 받은 후: 어떻게 정리할까

발표가 끝나면 피드백이 쏟아진다. 이걸 그냥 두면 혼란스럽다. Affinity Mapping이라는 기법으로 정리하자. 모든 피드백을 포스트잇에 하나씩 적고, 비슷한 것끼리 묶어서 범주를 만든다. 보통 “기능 개선”, “윤리적 보완”, “UX 개선”, “기술적 안정성” 네 묶음이 나온다.

Affinity Mapping을 디지털로 할 수도 있다. Google Jamboard, Miro, FigJam 같은 온라인 화이트보드 도구를 쓰면 팀원이 동시에 포스트잇을 붙이고 그룹핑할 수 있다. 물리적 포스트잇과 달리, 디지털 포스트잇은 색상 코딩, 투표, 댓글 기능을 활용할 수 있어서 우선순위 정하기가 더 쉽다.

다음으로 우선순위를 정한다. 긴급하고 중요한 것(위기 감지 오류, 데이터 유출 위험 등)은 바로 고친다. 중요하지만 급하지 않은 것(UI 개선, 추가 기능 등)은 후반부 개발 계획에 넣는다. 후반부(9~15주차) 로드맵은 윤리 → 기능 → 통합 순서로 짠다. 9~10주차에 윤리 모듈을 집중적으로 다루고, 11~12주차에 기능을 고도화하고, 13~14주차에 사용성 테스트를 하고, 15주차에 기말 발표를 한다.

우선순위를 정할 때 유용한 프레임워크가 “긴급도-중요도 매트릭스 (Eisenhower Matrix)”다. 세로축은 중요도(내담자 안전과 직결되는가?), 가로축은 긴급도(지금 당장 고쳐야 하는가?)다. 1사분면(중요+긴급)은 즉시 처리, 2사분면(중요+비긴급)은 계획적 개발, 3사분면(비중요+긴급)은 빠르게 처리, 4사분면(비중요+비긴급)은 보류. 상담 도구에서 1사분면의 예는 “자살 위기 감지 기능의 거짓 음성(놓침) 오류”, 4사분면의 예는 “로고 디자인 변경” 같은 것이다.

세네카 R. 게이너

피드백은 선물이다. 좋은 피드백은 프로젝트의 방향을 교정해주고, 팀이 보지 못한 맹점을 드러내준다. 피드백을 두려워하지 말고, 적극적으로 구하라.

— Gainer (2025, p. 295)

Gamma AI로 발표 자료 만들기

발표 자료는 Gamma AI(gamma.app)로 만든다. Gamma는 텍스트를 입력하면 슬라이드를 자동으로 만들어주는 AI 도구다. 프로젝트 요약(어떤 문제를 다루는지, 어떤 솔루션을 만들었는지, 핵심 기능은 뭔지, 한계는 뭔지)을 자연어로 적어서 넣으면 된다. 생성된 슬라이드를 발표 4단계(문제 → 이론/기술 → 데모 → 한계/계획)에 맞게 순서를 바꾸고, 프로토타입 스크린샷이나 데모 영상 링크를 넣는다.

Gamma AI를 처음 쓸 때 팁이 있다. 프롬프트(AI에게 주는 지시문)를 너무 짧게 쓰면 일반적인 내용의 슬라이드가 나온다. 대신 구체적으로 적자. “대학 상담센터의 접수 면접을 자동화하는 AI 도구에 대한 발표 자료를 만들어줘. 문제 정의(2분), 이론과 기술(2분), 라이브 데모(4분), 한계와 계획(2분) 순서로 구성해줘. 상담심리학 수업 학부생 대상이고, 토이가 깔끔한 스타일”처럼 말이다. 구체적인 프롬프트가 더 좋은 결과를 만든다.

몇 가지 주의할 점이 있다. 첫째, 슬라이드에 글자가 너무 많으면 안 된다. 슬라이드는 발표의 보조 자료이지, 대본이 아니다. 한 슬라이드에 문장 3개를 넘기지 말자. 키워드와 시각 자료 중심으로 구성하고, 자세한 설명은 말로 한다. 전문 발표에서 가장 흔한 실수가 슬라이드에 적힌 내용을 그대로 읽는 것이다. 청중은 읽을 수 있는데 발표자가 읽어주면 지루해진다.

둘째, 내담자 사례를 넣을 때는 반드시 익명으로 처리하고, 가상의 시나리오임을 밝힌다. “다음은 실제 사례가 아닌 교육용 가상 시나리오입니다”라는 문구를 슬라이드에 명시하자. 셋째, 라이브 데모 도중 인터넷이 끊기거나 서버에 문제가 생길 수 있으니, 주요 화면을 미리 캡처해서 백업 슬라이드로 준비한다. 데모가 실패했을 때 당황하지 않고 백업 슬라이드로 넘어가는 것은 전문성의 표시다.

세네카 R. 게이너

기술 발표에서 가장 흔한 실수는 모든 기능을 보여주려 하는 것이다. 내담자의 경험을 중심으로 한 가지 핵심 시나리오를 처음부터 끝까지 보여주는 것이 훨씬 설득력 있다.

— Gainer (2025, Chapter 12)

10분 발표, 이렇게 연습하자

10분은 생각보다 짧다. 시간 배분을 정확히 해야 한다. 문제 정의 2분, 이론/기술 2분, 라이브 데모 4분, 한계와 계획 2분. 연습할 때는 반드시 타이머를 켜고, 시간이 초과되면 내용을 줄인다. 발표 후에는 5분간 질의응답 시간이 있다. 동료의 질문에 방어적으로 대응하지 말자. 질문은 공격이 아니라, 프로젝트를 더 좋게 만들기 위한 제안이다.

리허설의 효과는 연구로도 입증되어 있다. 발표를 소리 내어 연습하면 자기 말의 속도, 어조, 논리 흐름을 직접 들을 수 있다. 혼자 머릿속으로 리허설하는 것과 실제로 소리 내어 하는 것은 효과가 크게 다르다. 가능하면 팀원 앞에서 연습하고, 피드백을 받자. 팀원이 이해하지 못하는 부분이 있으면 청중도 못 알아들을 가능성이 높다.

시간 관리를 위한 실용적 팁이 있다. 발표 대본을 쓰되, 대본을 읽지는 말자. 대본은 내용을 정리하는 도구이고, 실제 발표에서는 키워드만 보면서 자연스럽게 말하는 게 좋다. 각 단계의 핵심 문장 하나씩만 외워두면 시간이 부족할 때 나머지를 생략하고 핵심만 전달할 수 있다. 가장 흔한 시간 초과 원인은 라이브 데모에서 예상치 못한 문제가 생기는 것이다. 데모 시간을 엄격히 4분으로 제한하고, 남은 기능은 “이런 기능도 있는데 시간 관계로 생략합니다”라고 짧게 언급만 하자.

제이콥 닐슨

가장 좋은 사용성 테스트는 실제 사용자가 실제 과제를 수행하는 것을 관찰하는 것이다. 발표 리허설도 마찬가지 — 실제 청중 앞에서 연습해야 진짜 문제가 드러난다.

— Nielsen (1994)

Google Forms로 피어 리뷰 설문 만들기

피어 리뷰를 체계적으로 하려면 설문 양식이 필요하다. Google Forms로 간단하게 만들 수 있다. 핵심 항목은 네 가지다. (1) 기능성 평가(5점 척도 + 서술형), (2) 윤리성 평가(5점 척도 + 서술형), (3) 사용성 평가(5점 척도 + 서술형), (4) SBI 피드백(서술형). 각 항목에 5점 척도로 점수를 매기게 하고, 그 아래에 구체적 근거를 적는 서술형 칸을 넣는다. “5점을 준 이유” 또는 “3점을 준 이유”를 적게 하면, 피드백의 구체성이 높아진다.

설문을 만들 때 한 가지 팁이 있다. “이 프로젝트의 가장 큰 강점은 무엇인가?”와 “이 프로젝트에서 가장 먼저 개선해야 할 점은 무엇인가?” 두 질문을 반드시 포함하자. 강점을 묻는 건 받는 팀의 동기부여를 위해서이고, 개선점을 묻는 건 실질적 도움을 위해서다. 둘 다 있어야 균형 잡힌 피드백이 된다.

칼 로저스

공감은 상대방의 세계에 들어가되, 자신을 잃지 않는 것이다. 피어 리뷰에서도 상대 팀의 의도를 이해하되, 비판적 시각을 유지하는 균형이 필요하다.

— Rogers (1980)

발표와 피어 리뷰가 끝나면 가장 중요한 단계가 남아 있다. 받은 피드백을 정리하고 후반부 개발 계획에 반영하는 것이다. 피드백을 그냥 읽고 넘기면 아무 의미가 없다. 팀 회의를 열어서 모든 피드백을 범주별로 분류하고, 각각에 대해 “수용할 것/보류할 것/거절할 것”을 결정하자. 거절하는 피드백에 대해서도 거절 이유를 기록해두면, 나중에 비슷한 질문이 나왔을 때 근거가 된다. 이 과정 자체가 프로젝트의 방향을 명확히 하는 좋은 기회다.