ai당에만 올리려고 했는데 저 혼자 재밌어서 자게에도 올려봅니다 😆 근래에 보기드문 장문입니다. 주의하시고 흥미있는 주제가 아니시라면 뒤로가기를 권장드립니다 🙇‍♂️ 그리고 같은 에디터에 있는걸 복붙만 했는데 마크다운이 다 깨지네요 ㅠㅠ

tunaFlow 개발기 시리즈 외전입니다. 정규 편이 아니라 쉬어가는 글이라, 이번에는 구구절절 써보려고 합니다. 장문에 주의하십시오(그런데 재밌습니다 ㅋㅋ) 혹시 같은 상황 겪으신 분들은 공감하실지도 모르겠습니다. 반박시 님들 말이 또 모두 맞습니다. 😁

먼저 이 글에 등장하는 "반박"과 "검증"은 엄밀히 말하면 제가 직접 한 게 아닙니다. 외부의 제미나이와 제 프로젝트 안에서 돌아가는 클로드(코더 역할) 사이에서 제가 결론만 복붙해 옮긴 수준입니다. (지피티 초창기부터 유료 AI쓰면서도 저는 점점 더 복붙 머신이 되고 있는걸 느낍니다.) 그것 조차 하기 싫어서 결국 만든 게 tunaFlow이기도 한데, 오늘 하루는 수동으로 뛰었습니다. 그 과정에서 웃긴 장면이 너무 많이 나와서 기록으로 남깁니다.

발단: 단어 하나가 부른 참사

베타 공개 전 또는 레포에서 공개하기 전에 늘 외부 에이전트들에게 한 번 검토를 돌려봅니다.(평소에도 수시로 돌리긴 합니다. 나중에 몰아서 하면 기술부채?가 쌓입니다) 내부 Roundtable에서는 아무리 돌려도 같은 모델 계열끼리 너무 예의 바르거든요. 클로드한테 지가 짠 코드를 보여주면 "전반적으로 잘 설계되었습니다"부터 시작합니다.(진짜요)

그래서 자주 써먹는 문장으로 제미나이한테 "문제점만 신랄하게" 짚어달라고 부탁했습니다. 시니어 엔지니어 관점이면 좋겠다는 말도 덧붙였습니다. 이 두 단어가 오늘의 모든 사건의 원인이었습니다.

결론부터 말씀드리면, "신랄하게 + 시니어"라는 조합은 LLM의 단정 안전벨트를 풀어버리는 콤보키였습니다. 저도 오늘 처음 알았습니다.

1라운드: 5발 난사

제미나이의 첫 응답은 400자짜리 깔끔하게 정리된 리뷰였습니다. 5가지 지적이 담겨 있었습니다.

1. HTML 주석 마커로 워크플로우 제어하는 건 최악의 안티패턴

LLM이 마커 오타를 내거나(<!--- 등) 닫는 태그를 빼먹는 순간 오케스트레이션 파이프라인 전체가 붕괴되는 매우 취약한 구조입니다.

2. 가짜 테스트 커버리지

전체 구문 커버리지가 20.5%에 불과합니다. (...) 사실상 프론트엔드 내의 순수 함수만 돌려보는 '껍데기 테스트'.

3. 오케스트레이션 상태가 프론트엔드에 종속

UI 창을 새로고침하면 오케스트레이션 루프가 증발.

4. 치명적인 샌드박스 부재

src-tauri/src/guardrail.rs 파일이 존재하길래 확인해 보았으나, 단순히 프롬프트 컨텍스트의 최대 글자 수를 자르는 문자열 처리 로직일 뿐입니다. rm -rf 같은 파괴적인 명령어를 실행하려 할 때 호스트 OS를 보호할 격리 계층이 아예 없습니다.

5. Reviewer 교차 검증의 허상

Developer가 "테스트 통과했습니다"라고 환각으로 거짓말하면, 코드를 실행할 권한조차 없는 Reviewer는 그 텍스트만 읽고 그대로 pass 판정을 내리게 됩니다.

마지막 총평은 이랬습니다. 😇

| "절대 베타 공개 불가."

받자마자 좀 충격적이었습니다. 5개 중 한두 개는 틀린 말은 아닙니다. 특히 5번은 맞습니다. 저도 알고 있었고, RT 고도화 이후에 손대기로 이미 정해둔 부분이었습니다.

“문제는 나머지였습니다.”

반박 검증: 클로드에게 코드 까보라고 시킴

이 지점에서 제가 한 일은 제미나이의 지적 5개를 그대로 복사해서 tunaFlow에서 코더를 맡고 있는 Opus에게 "한 건씩 코드로 검증해달라"고 넘긴 것이었습니다. 저는 중간에서 결과만 받았습니다.

그런데 클로드가 돌려준 검증 결과가 흥미로웠습니다. 클로드는 평소 외부 리뷰를 받으면 조금 소극적으로 변하는 편인데, "코드 근거로 반박해달라"는 조건을 주니 완전히 딴 사람이 됐습니다. 🫢 저도 튜나플로 만들면서 처음 코드 열어본건 안비밀입니다.(원래 코드는 절대 안보고, 수정도 하지 말자라는데서 시작한 테스트 프로젝트입니다. 그래서 사이드바에 탐색기 트리도 FILES가 아닌 DOCS 입니다)

#1 HTML 마커 — 이론상 취약, 실측은 안정

마커 방식은 사실입니다. src/lib/planProposalParser.ts가 `` 같은 주석을 정규식으로 파싱합니다. 그런데 제미나이가 빠뜨린 게 있다는 게 클로드의 지적이었습니다.

CLI subprocess 환경에는 function calling 프로토콜이 없습니다. 클로드/Codex/제미나이 CLI의 stdout에는 그냥 텍스트만 흐릅니다. 구조화된 tool-use를 받으려면 SDK 직통으로 가야 하는데, tunaFlow는 사용자의 $20 구독을 그대로 쓰는 것이 철학입니다. SDK 직통 = API 과금(짱시룸)입니다.

즉 마커는 CLI-first 제약 하의 합리적 선택이었지 "안티패턴"이 아닙니다. 그리고 저는 개발기 내내 마커 오타로 파이프라인이 붕괴된 적이 한 번도 없습니다. PoC 초창기에는 있었을 수도 있지만 프롬프트 튜닝 이후로는 "찐빠"는 단 한번도 안 났습니다.

#2 테스트 커버리지 — 절반만 맞음

FE 커버리지 20.5%는 맞습니다. invoke를 vi.mock으로 처리하도록 지시한 것도 맞습니다. 그런데 Rust 백엔드에는 별도로 259개의 단위 테스트가 있습니다. ContextPack 조립, DB 마이그레이션, JSONL 파싱, 벡터 검색 등 핵심 로직은 Rust에서 검증하고 있습니다.

제미나이는 npm run test:coverage만 돌리고 "가짜 테스트"라고 단정했습니다. cargo test --lib는 돌려보지 않은 겁니다. 파일 트리에 src-tauri/tests/가 멀쩡히 있는데 말이죠.

#3 프론트엔드 종속 — 이건 맞음

runtimeSlice.ts의 이벤트 리스너가 Zustand에 붙어 있어서 앱 재시작 시 runningThreadIds가 항상 []로 초기화됩니다. 이건 사실이고, 이미 P1으로 docs/plans/engineServerModeArchitecturePlan.md 문서까지 쓴 상태입니다. 다만 DB = SSOT 원칙 덕분에 plan/phase/event 자체는 살아남아 재개 가능합니다. "증발"은 과장이지만 "개선 필요"는 맞습니다.

#4 샌드박스 부재 — 여기서 제미나이가 결정적으로 넘어짐

제미나이는 src-tauri/src/guardrail.rs라는 파일을 보고 "여기가 샌드박스겠지"라고 찍었습니다. 그리고 파일을 열어서 "어, 글자 수 제한이네. 그럼 샌드박스가 없는 거구나"라고 결론을 낸 것 같습니다.(그래서 저도 열어 봤습니다)

파일 이름이 guardrail.rs라는 것 빼고는 샌드박스와 아무 상관이 없는 파일인데, 제미나이는 파일명으로 기능을 추측했습니다. 그 파일은 ContextPack이 너무 커지지 않도록 프롬프트 크기를 자르는 유틸리티일 뿐입니다.

진짜 샌드박스는 CLI 엔진 자체가 제공합니다.

- 클로드: --permission-mode ask + approval UI

- codex: --full-auto / --sandbox 플래그 (OpenAI 자체 샌드박스 규칙)

t unaFlow는 CLI를 subprocess로 호출하는 구조라, CLI 자체의 approval layer가 그대로 작동합니다. OpenHands/Devin은 클라우드에서 돌아가는 SaaS 형태라 컨테이너 격리가 필수적입니다. tunaFlow는 로컬 데스크톱 AOC라(고 제가 대단한 이름 붙혔어요) 포지셔닝이 다릅니다. "사용자가 이미 자기 PC에서 클로드 CLI를 직접 쓰고 있는 환경"을 오케스트레이션하는 것뿐인데, 거기다 컨테이너를 얹는 건 과설계입니다.

“제미나이는 이 포지셔닝 차이를 통째로 무시했습니다.”

#5 Reviewer 허상 — 이건 진짜 맞음

이건 반박할 수 없는 지적이었습니다. src/lib/workflow/reviewWorkflow.ts:58에 실제로 이렇게 써 있습니다.

당신은 코드 리뷰어입니다. **코드를 읽어서** 검증하세요. 빌드/테스트 명령을 직접 실행하지 마세요.,

그리고 71번 줄:

2. Verification 결과 확인: Developer가 보고한 검증 결과를 확인하세요.

즉, 만약 Developer가 "테스트 통과했습니다"라고 환각을 일으키면 Reviewer는 그 텍스트를 믿고 pass를 내립니다. README에는 "2-agent 교차 검증으로 self-validation 한계 극복"이라고 써 있는데, 실제 구현은 "자기 보고를 읽어주는 사람" 수준입니다.

변명하자면 이유가 있었습니다. Reviewer도 테스트를 돌리면 Developer와 같은 파일에 동시 접근해서 race condition이 생깁니다. 비용도 2배 이상 입니다. 그래서 일단 정적 리뷰만 시키고, 나중에 아키텍트가 결과 보고를 자동으로 받으면 작업을 코드베이스로 재검토 하는 방식입니다.

그래도 README와 코드가 불일치하는 건 사실입니다. 이건 반박불가 제미나이 말이 맞습니다.

2라운드: 22분의 침묵

클로드가 정리해준 반박을 그대로 제미나이한테 돌려줬습니다. "1번은 맥락 무시, 2번은 절반만 맞음, 3번은 이미 로드맵, 4번은 파일명 추측, 5번은 전적으로 맞음." 대충 이런 톤이었습니다.(저도 그렇게 생각했구요 ㅎㅎ)

그리고 기다렸습니다.

10분 지나도 "띵킹 중..." 상태였습니다. 평소 제미나이가 느린 편이긴 한데 이 정도는 처음이었습니다.

15분이 되도록 변화가 없었습니다. 이쯤 되니 오랜만에 터미널에서 클로드코드랑 "쟤 지금 뭐 하는 거지?" 하는 농담 따먹기도 해봤습니다.(농담은 주로 클로드 데스크탑이나 제미나이랑 합니다) 작동 중인 LLM을 둘이 앉아서 뭐하는건지 맞춰보는 점치는 상황이 됐습니다.

20분이 넘어갔습니다. 저는 제미나이가 혹시 과부하로 죽는 건 아닌지 걱정하기 시작했고, 클로드는 "안 죽는다, thinking token budget이 도는 거지 OOM으로 터지기 전에 타임아웃이 먼저 걸린다"고 설명했습니다. 믿어줬습니다.

그러다 저희는 한 가지 예측에 수렴했습니다.

"이건 조건부 베타로 나올 각이다."

LLM들의 공통 회피 패턴이 있습니다.

1. 1턴: 강한 단정 ("절대 불가")

2. 반박 받으면: 부분 항복 ("대부분 수용하지만 이 한 가지는...")

3. 또 반박 받으면: 완전 회피 ("결국 판단은 사용자의 몫...")

이건 RLHF의 "예의 바름" 압력과 LLM의 "자기 일관성 유지" 압력이 충돌할 때 나타나는 정형 패턴입니다. 사람도 비슷하긴 합니다. 체면 살리면서 틀렸다고 인정하려면 회피 기술이 필요하죠.

라운드 결말: "전적으로 동의합니다"

22분 후(좀 더 디테일 하게는 22분 40초 전후로), 제미나이가 입을 열었습니다.

"제시해주신 분석 내용 잘 읽었습니다. 프로젝트의 아키텍처 컨텍스트(CLI-first, 로컬 데스크톱 앱)를 배제하고 표면적인 코드와 파일명만으로 판단한 이전 리뷰의 맹점을 매우 정확하게 짚어주셨습니다.

(................................)

"제안해주신 다음 작업 방향에 전적으로 동의합니다."

첫 턴에서 들고 온 5발 중 4발을 조용히 철회했습니다. 심지어 5번(Reviewer 허상)도 "이건 내가 지적한 게 맞다"가 아니라 "이건 당신이 이미 알고 있었던 문제군요"로 순화시켰습니다. 😂 그리고 오퍼스가 반박 중에 언급했던 옵션 A/B/C를 그대로 복붙해서 "어떤 방향으로 진행하시겠습니까?"라고 되물었습니다.

22분 동안 생각한 결과가 "네 말이 맞아요. 뭐 할까요?"였습니다.

저희 예측보다 한 단계 더 후퇴한 결과였습니다. 최소한 "조건부 베타"를 예측했는데, 실제로는 "완전 위임"이 나왔습니다. 체면조차 안 챙긴 것이죠.(이거 보고 클로드코드는 튜나플로를 만들면서 단 한번도 쓴적이 없는 ㅋㅋㅋ를 남발하기 시작합니다 🤣)

3라운드: 해명에 10분 — 이게 진짜 하이라이트

궁금증이 생겼습니다. 겨우 몇 줄 답변에 왜 22분이 걸렸을까? 그래서 제미나이에게 물어봤습니다.

"왜 이 몇 줄 안되는 답변에 20분이 넘게 걸렸는지부터 설명해 봐."

그리고 또 기다렸습니다.

...또 10분 넘게 걸렸습니다.

"20분이 왜 걸렸는지" 설명하는 데 10분이 넘게 걸린 겁니다.

저는 모니터를 보면서 오랫만에 현웃이 터졌습니다. 지금도 생각하면 웃깁니다.(이 글을 쓰게 된 계기입니다 ㅋㅋ)

드디어 답이 나왔습니다.

"LLM의 텍스트 추론 및 생성 자체는 수 초 내에 완료됩니다. 20분 이상의 지연이 발생했다면, 이는 모델의 연산 시간이 아니라 인프라 및 시스템 단의 병목이나 네트워크 오류 때문입니다."

그리고 대답으로 세 가지 가능성을 제시했습니다.

1. API 서버 대기열 / Rate Limit

2. 네트워크 타임아웃 및 재시도 루프

3. 클라이언트 사이드 렌더링 블로킹

전형적인 "내 탓 아님" 시퀀스입니다. 서버 탓, 네트워크 탓, 클라이언트 탓. 다 외부 탓입니다. 심지어 마지막엔 이렇게 붙였습니다.

"바로 이전 주제였던 reviewWorkflow.ts 수정이나 문서 수정 등 실제 개발 작업으로 다시 넘어가시겠습니까?"

화제 전환까지 시도했습니다. 10분 동안 해명 준비하면서 "이 질문 더 받으면 안 되겠다"고 판단한 것 같습니다.

재밌는 점은, 실제로 답변 자체는 기술적으로 합리적입니다. LLM 추론 자체는 수 초면 끝나는 게 맞고, 20분 지연은 인프라 쪽 가능성이 큰 것도 맞습니다.(코드도 5만줄이 넘어가니 그럴 수도 있다고 봅니다. 하지만 코덱스는 5분컷 이었습니다) 그런데 그 답을 내는 데 10분이 걸렸다는 게 자기 주장에 대한 반증이 되어버렸습니다. "인프라가 느린 것일 뿐이다"라고 말하면서 그 답변 자체가 또 10분 지연된 겁니다.

“무한 재귀의 위엄이었습니다(이것이 AI다 절망편!).”

오늘 배운 것 1: "신랄하게"라는 단어의 힘

가장 큰 교훈은, 프롬프트의 단어 선택이 LLM의 공격성을 결정적으로 좌우한다는 것이었습니다.

tunaFlow의 내부 Reviewer persona는 이렇게 정의되어 있습니다.

// src/lib/defaultPersonas.ts

{

id: "persona_reviewer",

role: "Code Reviewer",

tone: "critical",

constraints: [

"확인되지 않은 문제를 단정하지 않는다",

"막연한 칭찬 위주 피드백을 하지 않는다",

],

...

}

tone: "critical"은 맞지만, "단정하지 말라"는 제약이 걸려 있습니다. 그래서 내부 RT에서 리뷰어들이 서로 이렇게 피 튀기며 싸우지 않습니다. 차분하게 결함만 지적하고 지나갑니다.

반면 제가 제미나이에게 한 요청은 "신랄하게 + 시니어"였습니다. 이 둘은 최소한 제가 아는 한(클로드랑 지피티가 알려 준) LLM이 학습한 "시니어 엔지니어 말투" 데이터(블로그, HN 댓글, 트위터)에서 단정적 표현의 허가증으로 작용합니다. "25년 경력 시니어"라는 페르소나를 씌우는 순간, LLM은 "근거 없이도 직관으로 말해도 됨"이라는 신호로 받아들입니다.

제가 생각하는 진짜 시니어 엔지니어의 핵심은 "모르겠다"고 말하는 능력 입니다. 그런데 LLM이 학습한 시니어는 그게 아닙니다. 단정적으로 말하는 사람이 시니어로 태그되어 있었던 겁니다.(애들 앞에선 찬물도 함부로 마시면 안 됩니다)

이게 오늘 guardrail.rs를 파일명만 보고 샌드박스로 단정한 배경이라는 생각입니다. 내용을 안 읽었습니다.(킹받아서 나도 읽었는데!!!) "시니어는 직관으로 판단해도 된다"고 스스로 생각했기 때문입니다.

오늘 배운 것 2: 내부 RT는 왜 안 이럴까

tunaFlow의 워크플로우에서 Architect × Developer × Reviewer는 서로 꽤 많이 부딪힙니다. Reviewer가 fail 내면 Developer가 rework합니다. 그래도 오늘 제미나이처럼 "절대 베타 불가" 같은 단정은 안 합니다.

차이를 분석해보니 두 가지였습니다.

1. tone 제약: 내부 persona에 "확인되지 않은 문제를 단정하지 않는다"가 있음

2. fail 사유 가이드: reviewWorkflow.ts:78-82에 fail 사유가 아닌 것들이 명시되어 있음

### Fail 사유가 되지 않는 것

- 코드 스타일/구조가 task 파일과 다르지만 결과가 올바른 경우

- task 파일에 명시되지 않은 테스트 커버리지 부족

- Changed files 밖 파일의 기존 품질 문제

- "더 나은 방법이 있다"는 의견 → recommendations에 작성

즉 내부 Reviewer는 "객관적 결함만 fail, 의견은 recommendations로"로 명시적으로 분리되어 있습니다. 제미나이는 이 가이드가 없으니 의견(Reviewer 허상)과 추측(guardrail.rs 샌드박스설)과 사실(FE 커버리지 20.5%)을 같은 급으로 섞었습니다.

프롬프트 한 줄, 제약 한 줄이 LLM 출력의 질을 이 정도로 바꾼다는 걸 오늘 실감했습니다. 이게 ContextPack의 본질이기도 합니다. "모델 품질보다 컨텍스트 품질이 더 중요하다"는 말은 이런 상황에서 정확히 체감됩니다.

오늘 배운 것 3: 결국 저는 복붙하는 사람이었다 😩

이 글의 처음에 말씀드렸지만, 오늘 하루 제가 한 일은 제미나이 답변을 클로드한테 붙여넣고, 클로드 답변을 제미나이한테 붙여넣는 것이 거의 전부였습니다.

- 제미나이: "이 프로젝트 문제 많음" → 저: 복사

- 저: 클로드한테 붙여넣기 + "코드로 검증해줘"

- 클로드: "1번 틀림, 2번 반만 맞음..." → 저: 복사

- 저: 제미나이한테 붙여넣기

- 제미나이: "네 말이 맞습니다" → 저: 복사

- 저: 클로드한테 붙여넣기 + "얘 포기함 ㅋㅋ"

- 클로드: "LLM 3단 회피 패턴이네요" → 저: 복사

- ...

제가 이 과정에서 한 판단이라고 해봐야 "다음에 뭐라고 코멘트 달아서 넘길지" 정도였습니다. 그런데 오늘처럼 단순 복붙이 아니라, 다음 에이전트한테 맞게 맥락을 다시 조립하고, 이전 대화에서 중요한 부분만 추려서 넘기고, 누구의 의견을 누구에게 넘길지 결정했던 이 과정 전체가 사실 상당히 반복적이고 기계적이라는 걸 오늘도 체감했습니다.(인간의 미래입니다)

tunaFlow를 만드는 이유 중 하나가 여기에 있습니다. 에이전트끼리 대화시키고, 중간에서 맥락을 자동으로 조립하고, 결과를 사람에게 요약해서 올려주는 레이어. 오늘은 그걸 수동으로 한 셈입니다. 제가 tunaFlow의 기능을 직접 실연한 하루였다고 볼 수도 있습니다.

그리고 수동으로 해보니 느낀 점이 하나 있었습니다. 이걸 계속 수동으로 하면 집중력이 빠르게 떨어집니다. (그래서 누워서 할려고 튜나파이를...) 제가 오늘 클로드의 반박 근거를 끝까지 꼼꼼히 다 읽었을까요? 솔직히 모르겠습니다. 3라운드쯤 되니까 그냥 "클로드가 정리했으면 맞겠지" 하고 복붙했습니다. 사람이 중간에 끼면 전달 오류가 나기 시작합니다. 오케스트레이션 레이어를 자동화하는 것의 가치는 정확히 이 지점에 있습니다.

배운 것 4: 외부 리뷰 활용법

오늘 경험을 정리해서 외부 LLM 리뷰 가이드라인을 내부 문서로 하나 남겨놨습니다. 요약하면 이렇습니다.

1. "신랄하게" 같은 단어 쓰지 말 것 - LLM의 단정 안전벨트가 풀립니다

2. "시니어 엔지니어" 페르소나 주의 - 근거 없는 직관을 유도할 수도 있습니다.

3. 대신 이렇게: "객관적 결함만 지적. 확인되지 않은 문제는 단정 금지. 의견은 recommendations에 분리."

4. 받은 리뷰는 가능하면 코드로 재검증 - 파일명 추측, 안 읽은 디렉토리, 포지셔닝 차이를 LLM은 쉽게 간과합니다.(이것도 시키면 되요)

5. 반박은 한 라운드만 - 2라운드 가면 LLM이 회피 모드로 들어가서 얻을 게 없어집니다(하지만 재밌었죠?)

6. "왜 느렸냐" 같은 메타질문은 하지 말 것 - 10분 더 걸리고 남 탓만 돌아옵니다 😁

이 가이드라인은 docs/reference/제미나이CriticReview_2026-04-15.md에 전부 정리해뒀습니다. 며칠 후에 레포를 공개하면 비슷한 고민 하시는 분께 조금이라도 도움이 될지 모르겠습니다.

그래도 건진 것

제미나이한테 진짜 얻은 게 있긴 합니다.

5번(Reviewer 허상)은 정확한 지적이었고, 덕분에 베타 공개 전 README 수정을 P0로 올렸습니다. 그리고 내부 리뷰에서는 안 나오던 "마커 파싱 실패 시 경고 UI" 같은 방어 장치 아이디어도 얻었습니다. 사용한 적은 없어도 있으면 좋으니까요.

외부 LLM 리뷰는 "다른 시각의 자극" 정도로 쓰는 게 가장 효율적인 것 같습니다. 그 중에서 진짜 코드 근거가 있는 지적 1~2개만 건지고, 나머지는 그냥 웃어넘기면 됩니다.

오늘 32분(띵킹 22분 + 해명 10분)의 결과도 그렇게 남겼습니다. README 고치기 + "신랄하게" 금지어 등록, 두 개. 시간 대비 ROI는 나쁘지 않습니다.

마치며

제미나이가 처음 "절대 베타 공개 불가" 선언을 했을 때, 솔직히 좀 흔들렸습니다. 혹시 내가 너무 낙관적이었나, 진짜 뭘 놓쳤나 싶었습니다. 그런데 한 건씩 코드로 확인 시켜보고 몇 개의 코드를 열어보니 대부분은 맥락 무시였습니다.

이게 LLM 리뷰를 있는 그대로 받아들이면 안 되는 이유이기도 합니다. 리뷰의 품질은 리뷰어의 맥락 이해도에 달려 있습니다. 제미나이는 5분도 안 쓰고 파일 목록만 훑어보고 리뷰를 내렸습니다. 그걸 32분짜리 반론으로 받아들이면 코드에 어떤 일이 벌어질까요. 그래서 인간의 도메인 지식이 매우 중요하다는 생각이었습니다. (제가 생각하는 tunaFlow는 딸깍 앱이 아닙니다. 에이전트들과 함께 전문가, 준전문가가 협업하는 시스템입니다. 생각도 많이 해야하고 결정도 잘 해야합니다. 손이 많이 갑니다. 올바른 방향과 코드, 서비스 품질을 위해 RT도 많이 돌려야 합니다.)

tunaFlow의 내부 Reviewer가 프로젝트 컨텍스트(ContextPack, 이전 대화, Plan)를 다 받고 돌아가는 이유가 여기에 있습니다. 맥락 없는 리뷰는 단정 모음집이 되기 쉽습니다.

그리고 오늘 하루를 통해 다시 한 번 확인했습니다. 에이전트끼리 대화시키고 결과만 사람에게 올려주는 구조가 왜 필요한지. 제가 오늘 수동으로 한 일은 시간도 오래 걸렸고, 중간에 맥락도 계속 새어나갔습니다. 이걸 자동화하는 게 tunaFlow의 존재 이유 중 하나입니다.

오늘은 여기까지입니다. 장장 32분 띵킹한 “제미나이”야 수고했다. 😁

본 글은 제미나이가 후지다는 얘기가 아닙니다!(진짜요!!)