혼자서 몇 개의 앱을 운영하는 방법: 에이전트 하네스(Agent Harness) 설명

저는 집중 타이머, 어휘 트레이너, 디데이 카운터 등 몇 가지 작은 앱들을 혼자서 만들고 유지 관리하고 있습니다. 공동 창업자도, 직원도, 계약직도 없습니다. 오직 한 명의 사람과 AI 에이전트 무리뿐입니다.

사람들은 그 비결이 속도라고 생각합니다. AI 덕분에 코드를 더 빨리 타이핑할 수 있다고 말이죠. 하지만 그것이 아닙니다.

비결은 저 자신이나 AI가 증거 없이 무언가를 "완료(done)"되었다고 말하는 것을 거의 허용하지 않는다는 점에 있습니다.

진짜 병목 현상은 코드를 작성하는 것이 아니다

혼자 일할 때 위험한 실패 모드는 느린 타이핑이 아닙니다. 그것은 바로 '확신에 찬 틀림(confident wrongness)'입니다.

유능한 모델은 테스트를 실행하지도 않고 테스트가 통과했다고 기쁘게 말할 것입니다. 기능의 함수 시그니처(function signature)만 작성해 놓고는 기능이 완료되었다고 보고할 것입니다. 이를 잡아줄 동료가 없다면, 단 한 번의 "괜찮아 보이네요(looks good to me)"라는 말이 망가진 빌드를 스토어 심사 대기열로 밀어 넣을 수 있으며, 당신은 사흘 뒤 거절 이메일을 받고 나서야 그 사실을 알게 됩니다.

따라서 제가 앱을 중심으로 구축한 시스템은 출력(output)에 맞춰 조정된 것이 아닙니다. 그것은 '거짓 완료'를 비용이 많이 들게 만들도록 조정되었습니다. 저는 이것을 하네스(harness)라고 부릅니다. 즉, "AI가 완료했다고 말하는 것"과 "내가 그것을 믿는 것" 사이에 위치하는 특화된 에이전트(specialized agents), 오케스트레이터 워크플로우(orchestrator workflows), 그리고 검증 게이트(verification gates)입니다.

구성 요소들이 어떻게 맞물리는지 설명하겠습니다.

한 명의 전문가가 한 명의 제너럴리스트를 이긴다

모든 것을 다 하는 비서 한 명 대신, 저는 각 작업을 40개 이상의 특화된 에이전트(specialized agents) 중 하나에게 할당합니다. 각 에이전트는 좁은 직무를 가집니다: Flutter 리뷰어, 보안 리뷰어, 테스트 세트를 실제로 실행하는 것만이 목적인 테스트 실행자(test executor), 그리고 주장된 내용과 실제 차이(diff)를 비교하는 것만이 목적인 "현실 감사관(reality auditor)" 등입니다.

이것이 혼돈으로 변하지 않도록 유지하는 두 가지 규칙이 있습니다:

전문가(Specialists)가 더 신뢰하기 쉽습니다. 명시적인 체크리스트를 바탕으로 Dart만을 검토하는 리뷰어는

계획(Plan) — 요청을 위험 수준과 의존성을 가진 작업들로 분해합니다.
구현(Implement) — 변경 사항을 작성합니다. 금지되는 행위: '여기서 작업할 때'와 같은 리팩토링, 테스트 건너뛰기, 예외 무시 처리.
실제 실행(Run it for real) — 전용 실행 에이전트가 빌드, 테스트, 린팅을 실행하고 실제 종료 코드 및 출력을 포착합니다. '통과할 것 같다'는 주장은 받아들여지지 않으며, 오직 실제 출력만이 인정됩니다.
현실 감사(Reality audit) — 별도의 에이전트가 주장된 내용과 실제 변경 사항을 비교 분석합니다. 댓글만 있는 수정, 기능처럼 꾸민 빈 스텁(empty stubs), 그리고 X를 건드리지 않았음에도 'X를 변경했다'는 모든 것이 여기서 포착됩니다.
검토(Review) — 언어별 검토자입니다. Critical이 보내면 작업을 2단계로 되돌립니다.
검증 게이트(Verify gate) — 실제 변경 사항이 있었는지 확인하고, 각 요구사항을 존재하는 증거에 매핑하며, 빌드를 한 번 더 실행하고, 유출된 비밀 정보(leaked secrets)를 검색하는 최종 통과 단계입니다. 이 단계는 PASS 또는 REJECT만을 반환하며, 그 사이의 값은 없습니다.

이러한 모든 단계가 존재하는 이유는 제가 — 또는 모델이 — 저에게 거짓말을 했던 특정한 방식 때문입니다:

'작동할 것이다(It should work)'는 실제 실행 단계에서 실패합니다. 실제 출력이 없으면 통과도 없습니다.
빈 스텁에 대한 '완료(Done)'는 현실 감사 단계에서 실패합니다.
경고를 조용히 숨기는 '모두 녹색(All green)' 상태는 정적 검사(static check)에서 실패하며, 엄격 모드에서는 경고 자체가 실패입니다.

이것은 그 자체로 관료주의가 아닙니다. 1인 개발자는 두 번째 눈을 가질 수 없기 때문에, 두 번째 눈이 프로세스에 내장되어야 합니다. 그리고 이 루프는 제한적입니다. 만약 작업이 세 번의 라운드 동안 게이트를 통과하지 못하면, 워크플로우는 중단되고 무언가 빠져나갈 때까지 기준을 낮추기보다는 명확하게 실패했음을 알려줍니다.

새롭게 시작해도 살아남는 메모리(Memory that survives a fresh start)

컨텍스트 윈도우(Context windows)는 끝납니다. 하지만 제 프로젝트들은 그렇지 않습니다.

따라서 이 하네스(harness)는 세 가지 계층의 메모리를 유지합니다. 매 세션 시작 시 로드되는 짧은 인덱스(index), 필요할 때 읽어오는 더 긴 노트(notes), 그리고 지난 세션들에 대한 전체 텍스트 검색(full-text search)입니다. 제가 "지난번에 그 서명 키(signing key)를 어떻게 설정했더라?"라고 생각할 때, 시스템은 추측하는 대신 제가 실제로 무엇을 했는지 읽어올 수 있습니다. 저는 이 글을 쓰는 동안에도 그 검색 기능을 대여섯 번이나 사용했습니다.

그 위에는 더 조용한 루프(loop)가 작동합니다. 패턴 탐지기(pattern detector)가 여러 세션에 걸쳐 반복되는 작업을 감시하며, 동일한 형태의 작업이 충분히 자주 나타나면 이를 독자적인 기술(skill)로 전환할 후보로 표시합니다. 시스템은 제가 어떤 일을 너무 자주 수동으로 하고 있다는 것을 감지하고, 이를 자동화 대상으로 추천합니다. 저는 그 추천을 검토하며, 시스템이 스스로를 승격시키도록 내버려 두지는 않습니다.

내가 자동화를 거부하는 경계선들

모든 것을 수행하는 하네스는 결국 당신을 대신해 돌이킬 수 없는 일을 저지를 수 있는 하네스입니다. 따라서 가장 중요한 부분은 하네스가 행동하도록 허용되지 않는 지점들입니다:

발행(Publishing)은 수동입니다. 초안이 생성되면 검토를 위해 저에게 전달됩니다. 제가 직접 발행 버튼을 누릅니다. 언제나 말이죠.
라이브(Live) 전환에는 인간이 필요합니다. 테스트 설정을 라이브로 전환하는 것(결제, 공개 릴리스 등)은 별도의 명시적인 승인을 거쳐야 하며, 다른 변경 사항 묶음 속에 파묻힌 플래그(flag)로 처리되지 않습니다.
실패한 게이트(gate)에서는 아무것도 병합(merge)되지 않습니다. 검증 실패(빌드 오류, 보안 취약점 발견 등)는 병합을 차단합니다. 일정이 촉박하다고 해서 자동으로 무시되지 않습니다.

이것들은 제가 서서히 제거해 나가는 제한 사항들이 아닙니다. 이것이 바로 설계입니다. 에이전트 하네스(agent harness)의 레버리지(leverage)는 작업을 자동화하는 데서 오며, 안전함은 판단(judgment)을 자동화하기를 거부하는 데서 옵니다.

이것이 실제로 당신에게 가져다주는 것

이 글에서 한 가지만 얻어가신다면 이것입니다. 혼자 일할 때, 당신의 희소한 자원은 코드가 아닙니다. 그것은 방금 배포한 것이 당신이 의도한 바로 그 결과물이라는 '신뢰'입니다.

AI는 1인 제작자에게 수많은 손을 제공합니다. 하네스(Harness)는 그 손들에게 그 외에는 결여되어 있는 것, 즉 당신에게 위안이 되는 거짓말을 하지 않는 프로세스를 제공합니다. 그것이 혼자서 여러 개의 앱을 운영하는 것을 생존 가능하게 만드는 요소이며, 어떤 모델도 당신에게 거저 주지 않는 부분입니다. 당신이 직접 구축해야 합니다.

이 모든 것을 시작하기 위해 거대한 장비가 필요하지는 않습니다. 저의 방식은 하나의 에이전트와 하나의 규칙 — 실제로 테스트를 실행하라 — 로 시작되었으며, 제가 추측만으로 배포하고 있다는 사실을 깨달을 때마다 새로운 게이트(Gate)를 추가하며 성장했습니다. 만약 당신이 1인 빌더(Solo builder)라면, 이 방법론의 핵심은 단 한 줄로 요약됩니다: 당신이 스스로에게 가장 자주 하는 거짓말을 찾아내고, 그 거짓말을 하는 데 비용이 들게 만드는 단 하나의 체크(Check)를 구축하십시오.

저는 한 사람으로서, 다른 모든 이들이 잠든 시간 동안 이런 방식으로 작은 앱들을 만들고 있습니다. 다음 글들에서 저는 하네스를 구성 요소별로 하나씩 분해해 볼 것입니다 — 멀티 에이전트 코드 리뷰(Multi-agent code review), 메모리 루프(Memory loop), 그리고 제가 18일 만에 폐기한 자동화(Automation)까지 말이죠. 이것이 지도였습니다. 나머지는 실제 영역(Territory)입니다.