[Project] IT 프로젝트 최종 발표, 이것만 알면 달라진다

IT 프로젝트 최종 발표, 이것만 알면 달라진다

프로젝트 경진대회와 최종 심사 발표를 여러 차례 참관하면서 정리한 노하우입니다. 제가 직접 보고 느낀 것들을 한 곳에 모아봤습니다.

---

1. 발표는 "말"이 핵심이다

심사위원은 생각보다 화면을 잘 안 본다.
채점표를 작성하느라 고개를 숙이고 있는 시간이 꽤 길기 때문에,
화면 없이 음성만 들어도 흐름이 이해되도록 설명하는 것이 정말 중요하다.

1) 천천히, 강약 있게

빠르게 말할수록 듣는 쪽은 급격히 이해도가 떨어진다.
경험 많은 발표 코칭에서도 가장 많이 나오는 피드백이 "더 천천히"였다.
여기에 강조할 부분에서 톤을 확 올리고,
밝은 표정으로 자연스럽게 웃을 수 있는 분위기까지 만들면 청중의 몰입도가 확연히 달라진다.

2) 화면 전환은 여유 있게

슬라이드를 훅훅 넘기면 심사위원이 "지금 뭐였지?" 하는 순간이 생긴다.
한 화면이 충분히 인지된 후에 넘어가는 것이 좋다.

---

2. PPT, 적게 쓰고 크게 보여주기

1) 글자는 최소한으로

글이 많으면 뭘 읽어야 할지 눈에 들어오지 않는다. 핵심 키워드와 수치 위주로 구성하자.

2) 수치 강조의 기술

"AI 정확도 84% 개선"이라면 84% 를 화면 가득 크게 띄우는 것이 임팩트 있다.
처리 시간 단축, 성능 향상 등도 마찬가지. 다만 "3배 향상 → 4배 향상 → 5배 향상…" 식으로
수치 강조가 연달아 이어지면 오히려 감흥이 줄어드니 완급 조절이 필요하다.

3) 애니메이션 & 영상

PPT 애니메이션은 이해도를 높이는 동시에 정성을 보여주는 좋은 수단이다.
특히 아키텍처 슬라이드에서 데이터 흐름을 애니메이션으로 보여주거나, 짧은 시연 영상을 슬라이드에 삽입하면 전달력이 크게 올라간다.
라이브 시연이 불안정할 수 있는 구간은 아예 녹화 영상이나 애니메이션으로 대체하는 것도 현명한 전략이다.

4) Q&A 슬라이드 꿀팁

마지막 Q&A 화면에 전체 슬라이드 썸네일을 클릭 가능하게 매핑해두면, 질문이 들어왔을 때 관련 화면으로 즉시 이동할 수 있다.
실제로 이렇게 준비한 팀의 대응이 눈에 띄게 매끄러웠다.

5) 슬로건 활용

영상 포트폴리오나 홍보 자료에서 반복한 슬로건이 있다면,
발표 중에도 한 번쯤 자연스럽게 언급하면 위트 있고 일관된 인상을 줄 수 있다.

---

3. 시연, 1초의 빈틈도 없도록

1) 시나리오는 초 단위로

시연은 100% 계획대로 흘러가야 한다.
발표자 입장에서는 사소한 버벅임이라도, 듣는 사람에게는 치명적인 불안감으로 전달된다.
사전에 초 단위 시나리오를 작성하고 충분히 리허설하자.

2) 발표자가 리드, 시연자가 실행

"지금부터 ○○ 기능을 보여드리겠습니다" → 시연자가 클릭.
이 순서를 지키면 발표자가 시연을 지휘하는 느낌이 나고, 마치 한 사람이 발표하는 것처럼 자연스러워진다.

3) 화면은 크게, 중요한 건 확대해서

시연 중 글씨가 작으면 심사위원이 내용을 놓친다.
브라우저 확대(Ctrl +)도 방법이지만, 핵심 화면을 특정 비율로 확대한 별도 창을 미리 준비해두는 편이 훨씬 안정적이다.
실제로 확대를 잘 활용한 팀은 인상이 확 달랐다.

---

4. 질의응답, 여기서 판가름 난다

1) 심사위원의 질문 경향

유형	예시
도메인	"왜 이 문제를 풀려 했나?", "실제 사용자는 누구인가?"
비기능 요구사항	"보안은?", "확장 가능성은?", "기술 스택 선정 이유는?"
AI 관련	"모델 선택 이유", "성능 지표", "한계점은?"
엣지 케이스	"이 상황은 고려했나?", "이를 극복하기 위한 기능이 있나?"

도메인 이해도를 깊이 묻는 경우가 많으므로,
질문 대응은 기술 전문가보다 아이디어 원안자 또는 도메인 전문가가 맡는 것이 유리하다.
AI를 핵심 기능으로 사용했다면 AI 관련 답변을 특히 철저히 준비해야 한다.

2) 답변 잘하는 법

• 모든 구현에 이유를 붙이기 — "왜 선택지를 8개로 했나?", "이 기능은 왜 빠졌나?" 같은 질문에
  "추후 추가 예정입니다"보다 "저희는 ○○라고 판단해서 이렇게 구현했습니다"가 훨씬 설득력 있다.
• 구체적 경험 언급하기 — "이런 경험이 있어서 이 서비스를 기획했다"는 답변은 진정성과 설득력을 동시에 준다.
• 엣지 케이스 미리 정리하기 — 예외 상황 목록과 각각에 대한 대응 방안을 사전에 정리해두면 당황하지 않는다.

---

5. 개발 과정을 보여주면 신뢰가 올라간다

1) MVP에서 완성까지

1차 MVP가 무엇이었고, 유저 피드백을 어떻게 반영하며 발전시켜왔는지 과정을 보여주면
단순히 "잘 만들었다"보다 훨씬 강한 인상을 준다.

2) 자체 분석 지표로 검증

구현 결과를 스스로 정의한 분석 지표로 검증하고, 그 결과를 발표에 포함시키면 완성도에 대한 객관적 신뢰감을 줄 수 있다.

3) 반응형 체크

웹 서비스라면 반응형 렌더링이 매끄럽게 동작하는지 반드시 확인하자. 반응형 전환 시 버벅임은 감점 요인이 된다.

---

6. 기업 후원 프로그램이라면

기업에서 GPU, 멘토링 등 지원을 제공한 경우, 그 리소스를 얼마나 잘 활용했는지에 대한 관심이 높다.
"제공받은 ○○ 덕분에 이런 시도가 가능했다"는 식으로 자연스럽게 언급하면 좋은 인상을 줄 수 있다.

---

결국 좋은 발표는 준비의 양에 비례한다.
내용이 아무리 훌륭해도 전달이 어설프면 절반밖에 보여줄 수 없고, 반대로 탄탄한 준비는 내용 이상의 것을 보여준다.

---

부록: 기술 심사 관점에서의 반론

위 가이드는 주로 아이디어 피칭·서비스 기획 중심의 발표를 참관하며 정리한 내용입니다.
기술 심사 비중이 높은 대회에서는 조금 다른 시각이 필요하다는 의견도 있어 함께 정리해둡니다.

1) "심사위원은 화면을 잘 안 본다" — 항상 그렇진 않다

비즈니스 모델 피칭이라면 발표자의 스피치와 설득력이 가장 중요하고, 심사위원도 발표자의 눈을 보며 감정에 공감하려 한다.
하지만 백엔드 아키텍처, 데이터 플로우, 인프라 구성도 같은 기술적 내용을 설명할 때는
심사위원이 다이어그램을 아주 날카롭게 분석한다.
대용량 트래픽 처리 과정이나 DB 정규화 구조 등은 음성만으로 전달하기에 한계가 있기 때문이다.
복잡한 기술 흐름을 설명할 때는 오히려 시각 자료와 발표자의 설명이 완벽하게 동기화되어
심사위원의 시선을 화면으로 강하게 끌어와야 한다.

2) "수치 크게 띄우기" — 근거 없는 수치는 역효과

프레젠테이션에서 노이즈를 제거하고 핵심 수치를 부각하는 것은 좋은 기법이다.
그러나 기술 심사에서는 수치 하나만 덩그러니 있으면 '근거 부족'으로 비칠 수 있다.
심사위원은 "그 84%가 어떤 환경에서, 어떻게 도출되었는가?"를 궁금해한다.
AS-IS와 TO-BE 비교, 테스트 부하 환경(예: n명 동시 접속 시 TPS 변화) 같은
구체적이고 객관적인 맥락이 작게라도 함께 명시되어야 엔지니어로서의 신뢰감을 줄 수 있다.

3) "질문 대응은 도메인 전문가가 유리" — 질문 성격에 따라 나눠야 한다

서비스 기획 의도나 타겟 유저에 대한 질문은 도메인 전문가가 답하는 것이 맞다.
하지만 IT 프로젝트 경진대회의 핵심 평가 요소는 팀의 기술적 문제 해결 능력이기도 하다.
"왜 낙관적 락 대신 Redis를 도입했나요?" 같은 기술 딥다이브 질문에 기획자가 답하거나 얼버무리면 치명적인 감점 요인이 된다.
비즈니스·기획 질문은 도메인 담당자가, 아키텍처·트러블슈팅 등 기술 질문은
해당 로직을 직접 구현한 개발자가 마이크를 잡는 식으로 역할을 나눠두는 것이 바람직하다.

4) "저희는 이렇게 판단했습니다" — 때로는 한계를 인정하는 것이 더 낫다

모든 구현에 이유를 붙이는 것은 좋은 엔지니어링 태도다.
그러나 심사위원이 명백한 설계 오류나 비효율을 지적했을 때 무리하게 "우리의 판단이었다"고 방어하면,
피드백을 수용하지 않는 고집스러운 팀으로 보일 수 있다.
기술에는 항상 트레이드오프가 존재한다.
*"프로젝트 기한 제약 때문에 A를 선택해 빠르게 구현했지만, 확장성 측면에서는 B가 더 적합하다고 판단하고 있고
리팩토링 계획이 있습니다."_처럼 *_한계를 객관적으로 수용하면서 개선 의지를 보이는 답변**이 훨씬 높은 평가를 받는다.

---

메모 원문

메모1)
시연 시나리오 100% 로 이상없이 초단위로 짜놓아야할듯함.
살짝의 흔들림이 듣는사람한테는 치명적으로 느껴짐.
메모2)
심사위원은 기록하는게 많아서 생각보다 화면을 다 보지않음.
그렇다는건 가능한 화면 하나하나만으로 설명되는게 아니라,
발표자가 말만으로도 깔끔명료하게 이해되도록 설명해야할듯함.
그리고 화면 전환도 훅훅 넘어가면 안되고, 가능한 이게 뭐지?가 이해된 후 넘어가는편이 좋을듯
메모3)
심사위원들은 기술적인것보다 도메인에 초점을 맞추고 질문하는 경향이 있음.
따라서 발표자(질문받는사람)는 기술적인 이해도가 높은 사람 보다는 아이디어 원안자
또는 도메인 이해도가 높은 사람이 하는게 좋을 듯함.
메모4)
비기능적인 요구사항에 대한 질문이 많다. 보안, 확장 가능성, 유지 보수, 적절한 기술 스택, 속도 등등
메모5)
굳은 상태에서 딱딱하게 하는것보다는 밝은 표정, 확실히 강조하는 높낮이가 있는 말투가 필요하다.
웃을 수 있는 분위기 만드는게 생각보다 너무 좋은듯함.
메모6)
PPT의 애니메이션 효과가 이해에 도움이 많이 될 수 있고, 정성이 훨씬 잘보인다.
그리고 수치를 크게크게 띄우면 띄울수록 강조가 잘된다.
AI 84% 개선 이런거는 84%만 크게 뙇 띄우면 좋을듯. 시간 단축 같은것도 보여주면좋다.
근데 또 수치로만 다 강조하면 과하게 느껴질수도 있다. Ex) 3배 향상, 또 4배 향상 ... 등등
메모7)
시연때는 발표자가 먼저 말하고 시연자가 동작을 움직여주는 순서가 필요하다.
발표자가 시연을 지휘한다는 느낌을 받을수있으면 좋겠음. 결국에 힌사람이 발표하는것처럼.
메모8)
시연때 중요한 부분들은 확대해서 보여주는거 엄청 인상깊었다.
어떻게 하는건지는 모르겠지만 글씨가 작아서 내용을 모를뻔했는데 확대해서 제대로 볼 수 있었다.
웹 화면은 확대 기능을 이용해도 될것같은데, 안정적인 시연을 위해서는 특정 비율로 확대된 창을 따로 띄우는것도 좋을듯함.
메모9)
어플리케이션을 스스로 분석지표를 거쳐 잘 구현되었는지 자체 점검하는것이 좋았음.
메모10)
PPT애니메이션으로도 시연의 특정 부분을 대체할 수 있다. 딜레이 될 수 있는 부분은 이걸로 대체해보는것도 나쁘지않을듯함.
메모11)
대답할때, 특정 경험을 언급하는것 정말 좋았다. 경험을 통해서 이런 서비스를 기획했다.
메모12)
OOOO에서 온 심사위원이라 그런지 본인들이 제공한 gpu, 본인들이 준 멘토링을 얼마나 잘 활용했고 어땠는가.
그런쪽의 관점을 생각보다 많이 가지고 있음. 본인들이 있어서 너네 프로젝트에 도움이 많이 되었지? 이런식인것 같기도하고??
메모13)
PPT에 영상을 싣는게 이해도 높이는 힘이 있는듯함.
메모14)
질문받는동안 PPT에 질문에 대한 관련 내용으로 넘어갈 수 있도록 마지막 Q&A화면에 모든PPT화면이 전부 매핑이 되어있는게 정말 좋았다.
바로 클릭해서 넘어가는게 좋았음.
메모15)
영상포트폴리오에서 계속 강조하던 슬로건 같은 말을 발표 PPT에서도 한번쯤 언급해주면 위트있게 진행할 수 있다.
메모16)
OOOO 코치님도 발표중에 제스쳐로 계속 천천히천천히를 강조하심.
듣는사람이 빠르면 빨라질수록 따라가기 어려워질수밖에 없다.
메모17)
아키텍처 화면에서도 확대나 강조 같은 걸 활용해서 어떤 기술을 어떻게 썼는지 보여주는게 중요하다.
데이터가 어떻게 이동했는지 애니메이션으로 보여주는것도 좋은듯.
메모18)
PPT화면에는 글이 가능한 적어야할듯하다.
글이 많으면 많을수록 뭘 읽어야할지 눈에 들어오지 않음.
메모19)
개발 과정을 보여줌을 통해 1차 MVP는 뭐였으며, 어떤식으로 개발을 발전해갔는가를 보여주는 것 좋았다.
유저 피드백을 통해서 MVP의 개선 사항을 어떻게 수정했는지를 보여줌.
메모20)
엣지케이스에 대해서 고려했는가? 얼마나 고려를 했는지에 대해서 궁금해함.
이 케이스를 극복하기위한 ~~이러한 기능이 있나요??
메모21)
진짜 구현한 모든것에 대해서 이유가 존재해야함.
(8개의 선택지를 줬다. 왜? 다른선택지는 왜안함?) 이런이런거 추가하지 않은 이유는?
에 대해서도 단순히 현재는 이렇지만 추가해나갈것이다. 보다는 '저희는 뭐뭐라 생각해서 이렇게 구현했습니다.' 가 더 좋을듯 하다.
메모22)
AI에 관점을 잡고 모든 질문을 AI 관련해서 물어보시는 분이 계셨음.
AI가 엄청 주요 관점이다보니 AI를 사용한다면 더더욱 답변 준비 잘해야할듯
메모23)
웹에서 반응형은 렌더링 관련해서도 잘되어있는지 확인하는것같다. 반응형일때 버벅이면 마이너스일듯.