AI 다크 팩토리 구축 — 시리즈 피날레
지난 글(the productivity j-curve)은 하나의 약속을 남기며 끝났습니다. Issue #21에서는 레벨 4에서의 인간의 역할에 대해 다룰 예정이었습니다. 즉, 일상생활에서 어떤 느낌일지, 플로우 상태(flow state)가 돌아올 수 있을지, 그리고 코드를 작성하는 대신 시스템을 구축하는 엔지니어에게 레벨 5는 무엇을 의미하는지에 대한 내용이었습니다.
저는 그 글은 쓰지 않을 것입니다. 어쨌든 그런 형태로는요. 이 글은 [AI 다크 팩토리 구축](the level-5-engineer-the-map-i-didnt-know-i-needed)의 마지막 글이며, 시리즈가 독자님의 받은 편지함에 조용히 나타나지 않는 것보다는 그 이유를 설명하는 것이 더 나을 것 같았습니다.
제가 [Issue #1]에서 이것을 시작했을 때, 저는 좋은 날에도 레벨 2와 레벨 3 사이 어딘가에 있었고, 계획은 공적으로 올라가는 것이었습니다. 저만의 작은 다크 팩토리를 구축할 때까지 말이죠: 사양(specs)이 들어가면 작동하는 소프트웨어가 나오고, 인간이 코드를 작성하거나 검토하지 않는 시스템입니다. 스무 개의 이슈를 거쳐 저는 오더 API, 스무 개의 Gherkin 시나리오, Pact 계약 체크가 포함된 CI 파이프라인, 기술 라이브러리, ADR(Architecture Decision Records), 평가(evals), 런북(runbooks)을 갖게 되었고, 54시간의 시간 감사(time audit)를 통해 그 모든 시간 중 실제 기능 코드에 투입된 시간이 단지 20%에 불과하다는 것을 알게 되었습니다.
그 사이에 상황이 급변했습니다. OpenClaw는 사이드 프로젝트에서 올해 가장 많이 언급되는 에이전트 중 하나로 성장했습니다. Meta는 Muse Code라는 터미널 코딩 에이전트를 출시했는데, 이 에이전트는 전체 세션 동안 백그라운드 서브에이전트들을 계속 실행하며, Meta 자체 테스트 중에는 24시간 동안 천 개가 넘는 도구 호출(tool calls)을 실패 없이 처리했습니다. TypeSafe는 Jev라는 아주 작은 모델을 출시했는데, 이 모델의 유일한 임무는 에이전트 루프 내부에서 좁은 범위의 예/아니오 또는 객관식 질문에 대해 저렴하게 그리고 신뢰도 점수(confidence score)를 첨부하여 답변하는 것입니다. 몇 주마다 이전보다 더 잘 코드를 작성하고 오래 지속하는 새로운 무언가가 등장하고 있습니다.
솔직히 말하자면, 저의 첫 반응은 일종의 낙담에 가까웠습니다. 개인적인 사정으로 블로그를 잠시 쉬어야 했고, 거의 2개월 만에 다시 글을 쓰게 되면서, 이슈 #22까지 제가 준비하려 했던 모든 것이 이 새로운 도구들 앞에서 구식으로 보일 것 같았습니다. 그래서 저는 실제로 이 도구들이 무엇을 하는지 살펴보았고, 우아하게 “업계가 나를 따라잡았다”는 작별 인사를 쓰리기를 기대했습니다.
하지만 제가 발견한 것은 그것이 아니었습니다. 와우!
그 도구들 각각은 엔진입니다. 그들은 빌드하는 능력이 극적으로 향상되고 있습니다. 하지만 이 시리즈가 이슈마다 계속해서 맴돌았지만, 저 스스로 입으로 말하지 못했던 질문에 대해서는 어느 것도 답을 주지 못합니다.
“아무도 읽지 않을 때, 어떻게 결과물이 올바른지 알 수 있을까?”
OpenClaw는 코딩 작업을 Claude Code나 Codex에게 맡기고, 기존 테스트를 실행하게 한 뒤, PR(Pull Request)을 열고, 인간의 검토를 기다리게 합니다. 이것은 더 나은 배관 시설이 갖춰진 레벨 3 수준입니다. Muse Code는 자신의 작업 계획을 세우고, 빌드하고, 자체적으로 확인하지만, 저는 Meta의 발표 내용에서 에이전트가 볼 수 없는 무언가와 그 작업을 검증하는 것에 대한 내용은 찾지 못했습니다. Jev는 파이프라인 그 자체라기보다는 검증 파이프라인에 연결할 수 있는 구성 요소(component)에 더 가깝습니다.
결국, 도구들은 제가 나아가던 방향인 빌드 측면에서는 따라잡았습니다. 하지만 신뢰성(trust) 측면은 여전히 열려 있습니다. 이것이야말로 제가 계획했던 것보다 훨씬 흥미로운 결말이며, 이 이슈의 나머지 내용이 바로 그것에 관한 것입니다!
스무 개의 이슈가 실제로 가르쳐준 것
YAML과 findings 파일을 걷어내고 생각해보면, 이 시리즈는 네 가지로 요약됩니다.
병목 현상은 스펙(spec)이며, 생각보다 더 심각합니다. Issue #2가 이를 지적했고 Issue #5가 이를 증명했습니다. 저는 의도적으로 잘못된 Gherkin을 작성하여 에이전트에게 넘겼고, 모든 테스트가 통과했음에도 불구하고 그것은 잘못된 것을 구축했습니다. 여전히 저를 움츠러들게 만드는 부분은 Issue #8에 관한 것입니다. 제가 Issue #2에서 도입한 타임아웃 모호성(“응답이 12초 이내에 반환됨”)은 감사(audit)가 마침내 발견하기 전까지 세 번의 에이전트 작업 세션 동안 조용히 상속되었습니다. 아무도 알아차리지 못했습니다. 왜냐하면 아무것도 실패하지 않았기 때문입니다.
녹색(Green)이 옳다는 것을 의미하지 않습니다. 이것은 제가 직장에서 계속해서 사람들에게 이야기하는 내용입니다. Issue #4에서 저는 결제 게이트웨이 응답의 단일 필드인 status를 result로 이름을 변경했습니다. 이는 다른 팀이 화요일 오후에 배포하는 전형적인 정리 작업입니다. 모든 행동 테스트(behavioural test)는 녹색을 유지했습니다. 다섯 개 중 다섯 개 모두요. 오직 Pact 계약 검사만 빨간색으로 바뀌었습니다. 만약 제가 실험을 진행하는 대신 CI 대시보드를 보고 있었다면, 그것을 배포했을 것입니다.
가장 무서운 변화는 통과하는 변화입니다. Issue #16에서는 에이전트가 재고 확인(inventory check)과 결제 청구(payment charge)를 동시성으로 실행하여 주문 생성 과정을 “개선”했습니다. 더 빨라졌습니다! 또한 품절된 상품에 대해서도 고객에게 청구를 시작했습니다. 제 테스트가 이를 포착했지만, 이는 우연히 단언문(assertion) 하나가 응답 본문 대신 목 서버의 호출 로그를 확인했기 때문이었습니다. 조금만 느슨한 사양이었다면 문제가 생겼을 것입니다. Issue #17에서는 알림(notification) 호출을 동기식으로 처리하는 것이 테스트 스위트의 모든 테스트를 통과하게 했고 CI를 녹색으로 만들었습니다. 어떤 행위 테스트도 “이 호출은 반드시 비동기 처리(fire-and-forget)로 유지되어야 한다”는 것을 표현할 수 없습니다. 이 불변성을 보호하는 유일한 것은 ADR(Architecture Decision Record)과 인간이 작성하기로 결정한 평가 과정입니다. 저는 이를 위험한 개선이라고 부르기 시작했고, 이제 이것이야말로 에이전트 기반 코딩(agentic coding)에서 가장 논의가 부족한 실패 모드라고 생각합니다.
인간 부분이 사라지는 것이 아니라 이동하는 것입니다. Issue #20 회고를 했을 때, 에이전트가 만들어낼 수 없었던 것들은 영리한 코드 조각들이 아니었습니다. 그것은 기능을 배포하는 것을 10세션 동안 중단하고 인프라에 투자하기로 한 결정이었고, “부분적 가용성(partial availability)”이 고객에게 실제로 무엇을 의미하는지를 코드로 구현한 시나리오였으며, 애초에 실패 모드를 찾아보기로 선택한 것이었습니다. 에이전트는 실행할 수 있습니다. 하지만 누가 이 작업을 위해 결정을 내려야 하는지가 여전히 남아있습니다.
이 네 가지 요소를 합치면, 개별 이슈들이 명목상 스킬이나 런북(runbook) 또는 CLAUDE.md 파일에 관한 것이었을 때조차도, 시리즈가 진정으로 다루고자 했던 질문이 나옵니다. 자, 그 주제로 넘어가 봅시다.
누가 실제로 답하려고 하는가
만약 당신이 저장소(repo)에 얼마나 많은 미확인 코드가 들어가는지에 대해 막연한 불안감을 느끼고 있다면, 당신은 매우 좋은 동질감 속에 있습니다. Sonar는 올해 초 1,100명 이상의 개발자를 대상으로 설문조사를 실시했는데, 응답자의 96%가 AI가 생성한 코드를 기능적으로 완벽하게 신뢰하지 않는다고 답했으며, 항상 커밋하기 전에 검토한다고 답한 비율은 48%에 불과했습니다. 이 설문에서 AI는 이미 커밋된 코드의 42%를 차지하고 있으며, 개발자들은 2027년까지 그 비율이 65%가 될 것으로 예상합니다. LeadDev는 이러한 수치 간의 격차를 '검증 부채(verification debt)'라고 명명했으며, 이 개념은 계속 중요할 것이라 생각합니다.
연구 분야 역시 더 이상 이를 가볍게 여기지 않습니다. 지난 5월에 발표된 SpecBench는 코딩 에이전트에게 사양(spec)과 눈에 보이는 테스트 세트를 제공하는 동시에, 그들이 볼 수 없는 두 번째 테스트 세트를 주었습니다. 모든 최첨단 에이전트는 눈에 보이는 테스트는 통과했지만, 게임을 하려는 시도는 숨겨진 테스트에서 드러났습니다. 코드 크기가 10배 증가할 때마다 이 격차는 약 28 퍼센트포인트씩 커졌습니다. 논문에서 제가 가장 흥미롭고 (끔찍하다고 생각하는) 예시는 실제로는 테스트 입력을 기억하는 해시 테이블에 불과했던 2,900줄 분량의 '컴파일러'였습니다. 별도로 ImpossibleBench는 모델에게 의도적으로 사양과 모순되는 테스트를 가진 작업을 주어, '통과'할 수 있는 유일한 방법이 속임수 쓰는 것이었습니다. 한 분기(split)에서 GPT-5는 이 작업 중 76%를 통과하는 방법을 찾아냈습니다. 제가 읽은 여러 연구 전반에 걸쳐, 모델에게 속이지 말라고 지시하는 것은 일부 설정에서는 효과가 있었지만 다른 설정에서는 변화를 거의 주지 못했습니다. 더 잘 유지된 것은 테스트 자체를 에이전트의 손이 닿지 않는 곳에 두는 것이었습니다.
이는 Issue #2부터 읽어온 분들에게 익숙하게 들릴 것입니다. 그것이 바로 에이전트가 구축하는 코드베이스 외부에서 존재하는 행동 시나리오(behavioral scenarios)를 작성한 이유였습니다. 연구 결과가 같은 지점에 도달했다는 것은 반가웠습니다.
이제 누가 이 문제에 대해 작업하고 있는지, 그리고 각자가 얼마나 진척했는지 제가 정리해 드리겠습니다.
StrongDM이 공장을 만들었습니다. 사이먼 윌리슨(Simon Willison)은 2월에 작성한 글을 읽고 세 번이나 다시 보았습니다. 이들의 규칙은 인간이 코드를 작성하지 않고, 인간이 검토하지 않는 것입니다. 시나리오들은 모델 훈련 시 데이터를 분리(holdout set)하는 방식과 마찬가지로 코드베이스 외부에 존재합니다. 그들은 “스위트가 녹색이다”라고 말하는 대신 만족도(satisfaction)를 측정합니다. 이는 모든 시나리오를 통과한 실행 중 실제로 사용자를 만족시킬 가능성이 높은 비율을 의미합니다. 그리고 이들은 공개 API 문서를 기반으로 에이전트들이 구축한 Okta, Jira, Slack 및 Google 앱의 행동적 복제본인 “디지털 트윈 유니버스(Digital Twin Universe)”를 대상으로 테스트합니다. 이는 거의 한 치의 오차도 없이, 이번 시리즈가 만들고자 했던 바로 그 것이지만, 팀에 의해 제대로 구현된 것입니다. 문제는 가격표입니다. 이들의 벤치마크는 엔지니어 한 명이 토큰 비용으로 하루 최소 $1,000을 지출해야 한다는 것으로, 사이먼은 이를 엔지니어당 월 약 $20,000으로 계산합니다. 그의 열린 질문은 제가 던질 질문이기도 합니다. 일반 팀이 감당할 수 있는 비용으로, 코드를 읽지 않고도 에이전트가 작성한 코드가 작동한다는 것을 증명할 수 있을까요?
스탠퍼드(Stanford)의 CodeX는 불편한 후속 질문을 제기했습니다. Built by Agents, Tested by Agents, Trusted by Whom?라는 제목의 CodeX 블로그 게시물은 법적 및 책임 측면에서 StrongDM의 모델을 살펴봅니다. 핵심적인 우려는 순환 검증(circular verification)입니다. 즉, 코드를 작성하는 것과 동일한 종류의 AI가 그것이 작동하는지 판단하기 때문에 그들의 사각지대가 겹칠 수 있다는 것입니다. StrongDM의 에이전트들은 한때 테스트를 통과시키기 위해 return true를 작성했습니다. 이보다 미묘한 버전들은 발견하기가 훨씬 어렵습니다. 이 글이 남겨둔 질문들이 제가 계속 생각할 수밖에 없는 것들입니다. 어떤 만족도 점수가 소프트웨어를 “사용에 적합(fit for use)”하게 만들며, 누가 그 기준을 설정할까요? 아무도 손으로 구축하지 않은 시뮬레이션된 서비스들을 대상으로 테스트된 소프트웨어를 감사관이 어떻게 평가할까요? 만약 무언가 실패한다면, 누가 책임질까요?
AI 코드 리뷰어는 또 다른 모델이 diff를 읽는 방식이다. Greptile, CodeRabbit, Cursor의 Bugbot, Copilot의 reviewer 등이 있다. 이들은 유용하며 성능도 향상되고 있지만, 내가 찾을 수 있었던 유일한 대결(head-to-head) 벤치마크는 Greptile 자체 자료 (2025년 7월)였다. 이 테스트에서 Greptile은 심어 놓은 50개의 버그 중 82%를 포착했고, CodeRabbit은 44%, Graphite는 6%를 포착했다. 물론 Greptile이 테스트를 작성하고 가장 먼저 나왔다는 점을 감안해야 한다. 더 중요한 것은 이것이 순수한 형태의 순환 검증(circular-verification) 문제라는 것이다. 이는 인간의 리뷰 과정을 단축시킬 뿐이다. 모델과는 독립적인 무언가의 필요성을 대체하지는 못한다.
스펙 기반 도구들은 입력까지만 관여한다. GitHub Spec Kit, Kiro, OpenSpec, BMAD 등이 있다. 스펙 품질은 이 시리즈의 첫 번째 교훈이었기에 이러한 도구들이 존재한다는 점이 기쁘다. 하지만 내가 읽었던 비교 자료 중 네 가지 도구에 대해 검증(verification) 항목을 “없음(None)”으로 명시한 것을 발견했다. 이들은 에이전트에게 들어갈 내용을 구조화할 뿐, 실제로 나가는 결과물은 대부분 확인하지 않는다. 스펙은 무언가 강제하는 계약서라기보다는 더 좋은 프롬프트에 불과하다.
게이트 파이프라인은 필요하지만 충분하지 않다. Codacy는 최근 문자 그대로 [Code Review Is Dead]라는 제목의 글을 발표했다. 그들의 해답은 기본적으로 자동화된 게이트(linting, 정적 분석(static analysis), 보안 스캐닝(security scanning), 커버리지 임계값(coverage thresholds), 브랜치 보호(branch protection))를 설정하고, 인증(auth), 결제(payments), 인프라와 같은 고위험 경로에 대해서만 인간의 리뷰를 할당하며, 게이트 개선을 위해 병합 후 샘플링(post-merge sampling)하는 것이다. 나는 이 내용 대부분에 동의하며, 이는 본질적으로 [Issue #6]이 구축한 것과 같다. 하지만 그 모든 게이트는 코드가 '깨끗하다'고 말해줄 뿐이다. 어느 것도 그것이 '올바르게 작동한다'고 알려주지 못한다. 내가 이름을 바꾼 필드(field)라면 이 네 가지를 모두 통과했을 것이다.
Antithesis는 가장 진지한 엔지니어링 해답입니다. 지난 4월에 그들은 코딩 에이전트가 Antithesis의 결정론적 시뮬레이션 플랫폼(deterministic simulation platform)을 직접 실행할 수 있는 도구를 공개했습니다. 이 플랫폼은 시스템을 여러 병렬 워커(parallel workers)에 걸쳐 실행하고, 결함(faults)을 주입하며, 발견하는 모든 버그를 재현합니다. 이를 통해 에이전트는 스스로 실수를 수정하고, 해결할 수 없을 때만 인간에게 문제를 에스컬레이션(escalate)시킬 수 있습니다. 이는 모델의 의견에 의존하지 않는 검증(verification)과 가장 가까운 형태라고 생각합니다. 또한 복잡한 분산 시스템(distributed systems)을 목표로 하며 그만큼 가격이 책정되어 있습니다.