Isopod
코드를 쓰는 에이전트가 아니라, 조직의 개발 프로세스를 굴리는 하네스
- 무엇
- 자연어로 쓴 개발 명세를 다중 에이전트가 끝까지 수행하게 만드는 하네스다.
- 왜
- 사람이 쓴 명세는 해석의 여지가 넓어, 어디까지 됐는지를 기계가 판정할 수 없다.
- 어떻게
- 명세를 검사 가능한 상태 머신으로 고정하고 의존 그래프를 가진 작업 카드로 쪼갠 뒤, 그래프가 소진될 때까지 에이전트를 사람 개입 없이 돌려 검증된 커밋을 만든다.
- 새로움
- 진행도를 에이전트의 보고가 아니라 그래프의 잔량으로 잰다.
검증 조건: B2B 3D 디지털트윈 SaaS 기업 Cupix의 대화형 AI 어시스턴트 개발에 약 2개월 투입. 3개 팀(내부 2 + 외부 1)이 트래커로 협업하고, 카드의 20.5%가 스코프 컷으로 폐기되고, 결정 17건이 서로를 대체하는 조건에서 굴렀다. 실험실 조건이 아니다.
왜 "에이전트한테 개발해달라고 시키는 것"과 다른가
코딩 에이전트는 한 건의 작업을 최적화한다. 조직은 지속되는 프로세스를 굴려야 한다. 실무가 요구하는 다섯 가지는 대부분의 에이전트 하네스가 아예 다루지 않는 축이고, 이걸 하나의 의존 그래프 위에서 한꺼번에 하는 도구는 조사 범위에서 없었다.
| 실무가 요구하는 것 | 일반 코딩 에이전트 · SDD 툴 | isopod |
|---|---|---|
| 스펙을 엄밀히 고정하고, 구현이 거기 부합함을 증명 | 스펙은 산문 프롬프트. 부합 여부는 "테스트가 초록"으로 갈음 | 스펙 스키마가 상태 머신을 필수로 요구(states·events·transitions, 불법 전이까지 열거) → 수용 기준마다 반증 예시 → 테스트가 전이를 겨냥 → 4계층 게이트를 전부 결정적 프로그램이 판정(TS 컴파일러 / AST 변이 / deep-diff / 프로세스 spawn) |
| 진행 상황을 언제든 보고 | 대화창 스크롤백이 유일한 상태 | 카드 200장이 버전 관리되는 SSOT, 7단계 상태 머신, 트래커 미러. "무엇이 어디까지"가 파일과 트래커 양쪽에 상시 존재 |
| 다른 팀과의 협업 | 없음 (혼자 도는 전제) | 외부 팀 카드는 읽기 전용 미러 — 소유권이 데이터 모델의 1급 개념이고, 쓰기 범위를 필드 단위로 제한하며, 코드가 예외를 던져 강제. 역방향 기대는 consumer_contract 로 박제 |
| 사람의 정책 결정을 기다리는 구간 | 없거나, 전부 승인 게이트라 파이프라인이 사람 속도로 내려감 | 게이트를 층으로 가름 — 요구사항 층에만 사람, 실행 층 0개(실측 385패스 무인). 미결 정책은 게이트 카드가 그래프 노드로 존재해, 그걸 의존하는 카드가 자동으로 대기한다 |
| 도중에 바뀐 스펙의 결정론적 추적 | 프롬프트를 다시 씀 = 이전 상태 소실 | 상태별 편집 규칙 + 마이그레이션 카드(배포된 카드를 고치지 않고 이전 경로를 새로 만든다). 폐기 시 역방향 의존 정리 / 신규 결정 시 정방향 주입 / 결정 대체 시 엣지 재검토 3축이 감사 함수로 코드화 |
| 이 전부가 한 시스템 안에서 | 인접 도구 6종 중 트래커 연동 내장 1종, 다중 팀 소유권 모델 0종 | 위 다섯이 하나의 의존 그래프 위에서 동작하고, 그 위를 에이전트가 소진까지 굴린다 |
핵심 수치 (전부 실측 · 재현 명령 첨부)
| 지표 | 값 | 비고 |
|---|---|---|
| 굴린 실무 조건 | 3개 팀 · 카드 200장 · 의존 엣지 438 | 스코프 컷 폐기 41장(20.5%), 서로를 대체한 결정 17건, 하위작업 시드 1,018개 |
| 에이전트가 완주한 스토리 | 73장 중 70장 검증 통과 (95.9%) | 사람이 직접 구현한 8장은 제외한 수치 |
| 무인 실행 에이전트 패스 | 385회 (5개 페르소나) | 실행 층 사람 승인 0회 |
| 에이전트 실측 비용 / 시간 | $2,754 / 144.4시간 | 검증 통과 스토리당 약 $39 |
| 최대 동시 실행 | 13 패스 (평균 1.81배) | 1분 단위 이벤트 버킷 측정 |
| 하네스 코드 | 14.2만 LOC, 테스트:소스 0.94 | 테스트 284파일 / 6.39만 LOC |
| 사고 → 룰 → 감사 코드 | 룰 29개 중 20개가 실제 사고 유래, 그래프 감사 22개 | 일부는 npm run check 로 자동 발화 |
기술적 하이라이트
isopod 의 설계 목표는 한 문장으로 요약된다 — 정책 판단은 LLM 에게, 나머지 전부는 결정적 기계에게. 아래 네 항목은 그 이음매를 어디에 어떻게 놓았는지다.
1. 토이 프로젝트가 아니라 다팀 실무 환경에서 굴린 하네스. 트래커로 협업하는 3개 팀(내부 2 + 외부 1)의 카드 200장·의존 엣지 438개를 관리했고, 스펙이 계속 바뀌는 조건에서 운영했다 — 카드의 20.5%(41장)가 스코프 컷으로 폐기됐고 결정(ADR) 17건이 누적되며 서로를 대체했다. 그래서 이 하네스는 "카드를 만드는 법"이 아니라 "이미 배포된 카드의 전제가 바뀌었을 때 이력을 위조하지 않고 옮기는 법" 을 갖는다 (마이그레이션 카드 + 상태별 편집 규칙 + 결정 대체 시 의존 엣지 재검토). 외부 팀 카드는 읽기 전용 미러이고, 그 소유권 경계는 문서 규약이 아니라 코드가 예외를 던져 강제한다(실행으로 확인). 조사한 인접 도구 6종 중 트래커 연동이 내장된 것은 1종뿐이고, 외부 팀 소유권 모델을 가진 것은 없다.
2. 사람은 정책 결정에만 — 최적화된 HITL 배치. 업계에는 승인 게이트를 어느 층에 둘지에 대한 원칙이 없어 실무는 대개 전부 넣거나 전부 뺀다. isopod 는 요구사항 층(스펙·카드 발행·관측 게이트)에만 사람을 두고 코드 실행 층에는 0개를 뒀다. 실측 385패스가 무인으로 돌았고, 사람이 치는 명령은 8종이다. 이 배치는 취향이 아니라 사고에서 나왔다 — 승인 대기로 파이프라인이 멈춘 사건 이후, 드리프트 신호를 게이트에서 spec 에이전트의 입력 주석으로 강등했다. 대기가 필요한 정책 결정은 게이트를 없애는 대신 게이트 카드로 그래프에 올려, 사람이 열 때까지 그 하류만 정확히 멈추게 했다.
3. 앵커 그래프의 결정론적 보장 — 두 모델 교차검증 hard-zero. 자연어 스펙을 앵커 그래프로 바꾸는 단계에서 서로 다른 두 모델이 독립 추출하고, 앵커 대칭차 0 AND 엣지 대칭차 0 이어야 통과한다. 핵심은 조인 키 설계다 — 모델이 지어낸 ID 가 아니라 원문 위의 문자 구간(span) 을 키로 쓴다. 인용문(claim_text)은 한 글자도 바꿀 수 없지만 그 자체가 정체성인 것은 아니고, 구간을 찾기 위한 포인터다. 두 추출기는 스펙을 독립적으로 분절하므로 같은 주장이라도 인용 길이가 다르다 — 문자열 비교면 전부 불일치지만, 구간이 겹치면 같은 주장이고 겹침에는 임계값이 없다. 통과 후에는 결정적 게이트(단일 관심사 / 묶기 / 폐기 / 종류별)가 돈다. 그리고 이 파이프라인 전체에서 LLM 판단 지점은 정확히 한 곳이다 — 카드 초안 단계이며, 그마저도 네 개의 판단이 전부 enum/bool/id 필드로 강제된다. 앵커 채택(복사·번호 재부여)과 카드 발행·정리 단계는 모델 호출 0회의 순수 결정론이다.
4. 상태 머신으로 정의되는 테스트 — TDD in action. 스펙 문서가 산문이 아니라 상태 머신이다. states · events · transitions 가 스키마상 필수이고, 각 전이는 legal 플래그를 달아 불법 전이까지 명시한다 (실제 카드 예: 전이 25개 중 15개가 불법 전이 → 그만큼의 네거티브 테스트). 수용 기준은 falsifying_examples(그 기준을 반증할 예시)를 함께 요구하고, 테스트 항목은 targets 로 전이에 연결된다. 여기에 red-baseline 이 붙는다 — 구현 전에 테스트가 실패함을 러너 자신의 subprocess exit code 로 증명해야 하고, 구현 에이전트는 테스트 파일을 고칠 수 없다. 스펙 단계에서는 "happy 케이스와 edge 케이스의 기대값이 같으면 거부"하는 규칙이 상수를 반환하는 스텁으로 통과하는 것을 원천 차단한다.
+ 게이트를 우회한 자리조차 결정적으로 남는다. 검증 게이트에는 면제 표면이 존재한다(L3/L4 의 n/a 판정, L1 경고 강등, L2 임계 하향 등). 이걸 막는 대신 세기로 했다 — 모든 면제가 단일 seam 을 통과해 원장(NDJSON)에 기록되고, 표면별 카운트가 리포트에 노출되며, seam 을 타지 않는 새 면제 지점은 정적 감사가 검출한다. 막으면 사람 응답 대기로 파이프라인이 멈추고(아래 §사고 2), 안 세면 어느 방어선이 실질 비활성인지 아무도 모른다.
본인 역할
하네스 전체 설계·구현 단독. 대상 프로젝트에서는 하네스 운영자로서 요구사항 층 (스펙 작성·카드 검토·발행·관측 게이트 개방)과 PR 리뷰·머지를 담당했고, 스펙→플랜→테스트→구현→리뷰 실행 구간은 하네스가 무인으로 수행했다.
정직한 한계 (상세는 전체 포트폴리오)
done은 여전히 "동작한다"의 완전한 증명이 아니다. 머지 직후 얇은 수직 슬라이스 스모크가 자동으로 돌아 런타임 진실이 파이프라인 안으로 들어오지만, 실패해도 상태 전이를 막지 않는다 — 증거 없는done을 리포트에 노출하는 데까지가 현재 설계다. 막으면 사람 응답 대기로 파이프라인이 정지한 사고의 직접 재발이기 때문이다.- 면제는 막지 않고 센다. 게이트 면제는 여전히 에이전트가 켤 수 있다. 달라진 것은 그것이 보이지 않던 것에서 지표가 됐다는 점이다. 그리고 본문의 70장은 이 계측 이전 데이터이므로 그 스토리들의 면제 분포는 소급해서 알 수 없다.
- 이식은 실증됐지 경제성이 증명된 것은 아니다. 두 번째 프로젝트에서 자연어 스펙 한 장만 남긴 빈 상태로 전 구간이 완주했다 — 앵커 19 → 카드 3+게이트 1 → 코드 스토리 3장 전부 검증 통과 → PR, 그리고 실제로 서버를 띄워 확인한 스펙 주장 13개 전부 성립. 다만 "하네스 수정 0"은 이 규모에서 성립하지 않는다 — roll 3회, 하네스 결함 4건 수정이 필요했다(셋은 원 프로젝트에도 잠재해 있다가 새 레이아웃에서 처음 발화). 그리고 이는 연습용 예제(카드 3장)이지 두 번째 실프로젝트가 아니다. 하네스 제작 비용은 여전히 측정하지 못했고, 단일 프로젝트 절감 추정액을 넘었을 가능성이 높다.
- 에이전트 CLI 지원은 2종 — 인접 도구(30+/40+/11 플랫폼) 대비 명백한 열세이며, 이는 의도적으로 안 한 축이다(N종 지원보다 어댑터가 실제 교체 가능함을 2종으로 증명하는 편을 택했다).
- 실무 표본은 단일 프로젝트 (roll 14회 / 스토리 73장). 두 번째 프로젝트는 카드 3장짜리 연습용 예제라 표본을 늘려주지 않는다. 공개 벤치마크 좌표계에 올린 적 없다.
- 하네스 기여와 모델 기여를 분리하는 대조 실험을 하지 않았다. 말할 수 있는 것은 "하네스가 없었으면 성립 불가한 구간"(의존 순서·자동 재시동·게이트·머지 검증)까지다.
모든 수치의 재현 명령은 전체 포트폴리오 부록에 있다. 회사명은 밝히되 제품·인명은 익명화했다.