[DeToks] Day 14 - 발표 직전, 기술보다 먼저 버텨야 했던 것들

Phase 2 발표가 가까워질수록 작업의 성격이 조금 달라졌다. 초반에는 구조를 바꾸고, 중반에는 Cache, RAG, Budget Gate 흐름을 정리했다. 그런데 막바지로 갈수록 중요한 건 기능 하나를 더 붙이는 게 아니었다.

이제는 버텨야 했다.

발표자료는 계속 손봐야 했고, 시연 흐름은 자연스럽게 이어져야 했고, 설명은 너무 어렵지 않아야 했다. DeToks 안에서는 여러 단계가 돌아가지만, 발표를 듣는 사람에게는 하나의 이야기로 보여야 했다.

Phase 1에서 무엇을 검증했나
왜 Phase 2에서 방향을 바꿨나
무엇을 덜어냈나
어떻게 호출을 줄였나
앞으로 무엇이 남았나

이 다섯 가지를 한 흐름으로 묶는 게 발표 직전의 가장 큰 일이었다.

기술은 정리됐지만 몸은 따라오지 않았다

Phase 2 후반에는 노트북도 사람도 꽤 지쳐 있었다. 특히 규철님의 노트북은 발열이 심해서, 공기청정기 위에 노트북을 올려서 작업했다.

사진으로 보면 조금 웃긴 장면처럼 남아 있지만, 당시에는 꽤 현실적인 문제였다. 발표 준비 막바지에는 작은 문제도 크게 느껴진다. 빌드가 느려지고, 팬이 계속 돌고, 화면 공유나 시연 중에 멈추면 어쩌나 하는 걱정이 생긴다.

프로젝트를 하다 보면 기술적인 문제와 생활적인 문제가 분리되지 않는다. 코드가 잘 돌아가도 노트북이 버티지 못하면 테스트가 끊긴다. 발표자료가 정리돼도 사람이 집중력을 잃으면 문장이 이상해진다. 기능은 거의 완성됐는데, 마지막 하루 이틀이 유난히 길게 느껴지는 이유가 여기에 있었다.

이 시점에서 우리가 해야 했던 건 새로운 기능을 더 욕심내는 게 아니라, 지금까지 만든 걸 안정적으로 설명할 수 있게 만드는 일이었다.

시연에서 보여줄 범위를 줄인다.
발표 문장을 다시 정리한다.
기술 용어를 쉽게 바꾼다.
과장된 표현을 걷어낸다.
남은 리스크를 숨기지 않는다.

Phase 2 발표자료를 만들면서 가장 많이 한 일도 사실 이쪽이었다. Cache, RAG, Budget Gate는 그 자체로 멋있어 보이는 단어지만, 단어만으로는 설득이 안 된다. 듣는 사람이 “그래서 사용자는 뭐가 좋아지는데?”를 바로 이해해야 했다.

발표자료를 다시 읽는 시간

발표 직전에는 이미 만든 슬라이드를 계속 다시 읽었다. 한 번 만들고 끝나는 게 아니라, 읽을 때마다 걸리는 부분을 고쳤다.

예를 들어 RAG는 처음엔 토큰 절감 흐름 안에 들어가 있다 보니, 자칫 “RAG가 토큰을 줄인다”처럼 보일 수 있었다. 하지만 정확히 말하면 RAG는 과거 자료를 찾는 장치다. 직접 토큰을 줄이는 건 cache와 압축에 더 가깝다. RAG는 필요한 기억을 찾아서 답변 품질을 높이는 쪽에 가깝고, 잘못 넣으면 오히려 context가 늘 수 있다.

Budget Gate도 마찬가지였다. 이름만 보면 뭔가를 막는 단계처럼 보인다. 하지만 실제로는 작업 실행을 막는 게 아니라, RAG context를 넣을지 말지를 결정하는 단계였다. 이걸 발표에서 잘못 말하면 전체 구조가 다르게 전달된다.

그래서 발표 문장을 계속 다듬었다.

RAG는 후보를 찾는다.
Budget Gate는 넣을지 결정한다.
Cache는 실행을 건너뛴다.
Task Graph는 이 판단을 task 단위로 가능하게 만든다.

이렇게 쪼개서 말해야 했다. 기술적으로 정확하면서도, 듣는 사람이 따라올 수 있어야 했다.

Phase 1 발표 때는 “토큰을 줄이면서도 기능을 유지했다”는 결과가 비교적 선명했다. Phase 2는 조금 더 어려웠다. 절감률 하나만 보여주면 끝나는 발표가 아니었다. 실행 흐름이 왜 바뀌었는지, 어떤 판단을 어디서 하는지, 왜 이 구조가 장기적으로 더 중요한지 보여줘야 했다.

밤까지 남아 있던 날

그날은 밤까지 학원에 남아 있었다. 발표자료도 보고, 시연 흐름도 보고, 중간중간 각자 맡은 부분을 다시 정리했다. 저녁을 먹으면서도 머릿속에는 발표 순서가 계속 남아 있었다.

그런데 그 분위기가 마냥 무겁지만은 않았다.

저녁을 먹고 있는데 시호님이 노래를 불러준다고 했다. 다들 지쳐 있던 시점이라 그런지, 그 말이 꽤 반가웠다.

시호님은 eill의 피날레를 시작으로 Pretender, 동그리모, 체인소맨 OP KICK BACK, 홍련화 같은 일본 노래들을 불러주셨다. 가사를 따라 부른 건 아니었고, 그냥 그 자리에서 듣고 있었다. 그런데 신기하게도 그 시간이 꽤 회복이 됐다.

프로젝트 막바지에는 쉬는 것도 잘 안 된다. 쉬고 있어도 “이거 아직 안 끝났는데”라는 생각이 남아 있다. 그런데 누가 노래를 불러주고, 같이 밥을 먹고, 잠깐 웃는 시간이 생기면 머리가 조금 식는다.

그날의 노래가 프로젝트 결과에 직접적인 영향을 줬다고 말하면 과할 수 있다. 하지만 팀이 마지막까지 버티는 데에는 분명 도움이 됐다. 기술 프로젝트도 결국 사람이 하는 일이라, 이런 장면이 꽤 오래 남는다.

팀 프로젝트의 체력

혼자 하는 프로젝트에서는 내가 지치면 그냥 멈추면 된다. 하지만 팀 프로젝트에서는 서로의 컨디션이 흐름에 영향을 준다. 누군가 막히면 같이 보고, 누군가 발표자료를 붙잡고 있으면 다른 사람이 옆에서 문장을 봐준다. 누군가 노트북 발열로 고생하면 다 같이 그 상황을 신경 쓴다.

Phase 2 후반에 느낀 건, 팀 프로젝트의 체력은 개인 체력의 합보다 조금 더 복잡하다는 점이었다.

각자 맡은 기능을 끝내는 체력
서로의 결과를 맞추는 체력
발표자료를 다시 읽는 체력
시연 실패를 감당하는 체력
마지막까지 분위기를 잃지 않는 체력

이런 것들이 다 필요했다.

특히 DeToks는 파트가 분명히 나뉘어 있었다. 번역과 압축, Task Graph, 세션과 RAG, CLI와 adapter, 발표자료와 시연이 서로 연결됐다. 한 파트만 잘한다고 끝나는 구조가 아니었다. 발표에서는 이 모든 것을 하나의 제품처럼 보여줘야 했다.

그래서 막바지에는 기술적인 정리만큼이나 팀 안에서 말이 잘 통하는 게 중요했다. 어떤 표현은 빼고, 어떤 한계는 인정하고, 어떤 숫자는 강조하고, 어떤 기능은 다음 과제로 남길지 계속 합의해야 했다.

완성보다 정리

5월 16일쯤의 작업을 한 단어로 말하면 완성보다는 정리에 가까웠다.

기능을 더 만들 수는 있었다. 작은 명령어를 추가하거나, 화면을 조금 더 다듬거나, 발표자료에 더 많은 예시를 넣을 수도 있었다. 하지만 그럴수록 발표는 흐려질 가능성이 컸다.

그래서 우선순위를 다시 잡았다.

새 기능보다 기존 흐름 정리
멋있는 표현보다 정확한 표현
많은 시연보다 실패 가능성이 낮은 시연
긴 설명보다 한 번에 이해되는 흐름

이 기준을 잡고 나니 조금 편해졌다. 발표는 모든 것을 보여주는 자리가 아니었다. 우리가 Phase 2에서 무엇을 배웠고, DeToks가 어떤 방향으로 바뀌었는지를 전달하는 자리였다.

Phase 1에서는 토큰 절감률과 기능 품질 유지가 중심이었다. Phase 2에서는 그 결과를 바탕으로, “입력을 줄이는 도구”에서 “반복 작업을 덜 실행하게 만드는 도구”로 방향을 바꾼 이야기가 중심이었다.

이 메시지만 선명하면 됐다.

시연을 줄이는 것도 결정이었다

발표 직전에는 시연을 어디까지 보여줄지도 계속 고민했다. 만든 기능을 전부 보여주고 싶은 마음은 당연히 있었다. Cache도 보여주고, RAG도 보여주고, Budget Gate도 보여주고, CLI 실행 흐름도 보여주고 싶었다.

하지만 시연은 욕심을 내면 금방 위험해진다. 발표장에서 라이브로 실행하는 순간에는 작은 변수도 크게 느껴진다. 네트워크, 노트북 상태, 모델 로딩 시간, 터미널 출력, 발표자의 말 속도까지 전부 영향을 준다.

그래서 시연 기준을 다시 잡았다.

모든 기능을 보여주는 시연보다
핵심 흐름이 끊기지 않는 시연

DeToks의 Phase 2를 설명하는 데 필요한 건 아주 많은 화면이 아니었다. 사용자의 요청이 들어오고, 이전 결과를 확인하고, 필요한 task만 처리하고, context를 고르는 흐름이 보이면 됐다. 나머지는 발표 문장과 슬라이드에서 보완할 수 있었다.

이 결정도 생각보다 중요했다. 프로젝트 막바지에는 “이것도 보여주면 좋겠다”는 생각이 계속 든다. 하지만 발표는 만든 기능의 전체 목록이 아니라, 듣는 사람이 가져가야 할 메시지를 정리하는 자리다. 보여주고 싶은 걸 다 넣으면 오히려 중심이 흐려진다.

그래서 일부는 과감히 줄였다. 대신 Phase 2의 핵심 문장을 계속 살렸다.

같은 일은 다시 하지 않는다.
필요한 기억만 찾는다.
넣을 가치가 있는 context만 넣는다.

이 세 문장이 시연과 발표자료의 기준이 됐다.

문장을 맞추는 일

팀 발표에서 은근히 오래 걸리는 건 문장 맞추기다. 각자 맡은 파트가 다르기 때문에, 같은 기능을 조금씩 다른 말로 설명할 수 있다. 예를 들어 한 사람은 RAG를 “context 절감”이라고 부르고, 다른 사람은 “프로젝트 메모리”라고 부르면 듣는 사람은 헷갈린다.

그래서 발표 직전에는 표현도 맞춰야 했다.

RAG는 프로젝트 메모리
Cache는 재실행 방지
Budget Gate는 context 주입 판단
Task Graph는 task 단위 판단의 기반

이렇게 표현을 고정해두면 발표가 훨씬 안정된다. 각자 다른 파트를 말해도, 같은 방향을 보고 있다는 느낌이 생긴다.

처음에는 이런 작업이 조금 사소하게 느껴졌다. 코드가 더 중요하고, 시연이 더 중요하다고 생각하기 쉽다. 하지만 발표에서는 문장 하나가 기능의 인상을 바꾼다. “RAG로 토큰을 줄인다”와 “RAG로 필요한 과거 자료를 찾는다”는 완전히 다르게 들린다.

후자가 더 정확했고, 더 오래 버틸 수 있는 설명이었다.

사진으로 남은 것

돌아보면 발표자료의 슬라이드보다 이런 사진들이 그 기간을 더 정확하게 보여줄 때가 있다.

노트북을 식히던 장면은 프로젝트 막바지의 현실을 보여준다. 좋은 구조를 만들고 있어도, 실제 작업 환경은 늘 완벽하지 않다. 장비도 버텨야 하고, 사람도 버텨야 한다.

저녁을 먹던 장면은 팀의 분위기를 보여준다. 밤까지 남아 있었지만, 그 안에도 웃을 수 있는 시간이 있었다. 시호님의 노래는 그날의 작은 회복이었다.

블로그에 이런 이야기를 넣는 게 처음에는 조금 사적인가 싶었다. 하지만 프로젝트 기록에서 이런 장면을 빼면, 결과만 남고 과정은 사라진다. Phase 2는 기술적으로도 중요한 기간이었지만, 동시에 팀이 같이 버틴 기간이었다.

그래서 이 글은 기술 설명보다 사람 쪽에 조금 더 가깝게 남겨두고 싶었다.

발표 전 마지막 기준

5월 16일 이후 남은 건 최종 발표였다. 발표 장소는 인텔 코리아였고, 그곳은 과정 초반에 방문했던 곳이기도 했다. 처음 방문했을 때는 교육 과정의 시작점에 가까웠다면, 이번에는 우리가 만든 DeToks를 들고 다시 가는 느낌이었다.

발표 전 마지막으로 정리한 기준은 이랬다.

Phase 1은 가능성을 확인한 시간이었다.
Phase 2는 도구로 쓰기 위한 구조를 만든 시간이었다.

그리고 그 구조를 말할 때, 너무 어렵게 말하지 않기로 했다.

같은 일은 다시 하지 않는다.
필요한 기억만 찾는다.
넣을 가치가 있는 context만 넣는다.
그래도 필요한 작업은 끝까지 실행한다.

이 정도면 듣는 사람이 따라올 수 있다고 봤다.

그날 밤의 피곤함, 노트북 발열, 저녁, 노래, 다시 고친 발표 문장까지 전부 Phase 2의 일부였다. 코드와 발표자료만으로는 보이지 않는 부분이지만, 실제로는 이런 시간들이 마지막 발표를 가능하게 했다.

다음 글은 5월 19일, 인텔 코리아에서 진행한 Phase 2 최종 발표 회고로 이어진다.