다크 팩토리 검증 레이어

StrongDM은 두 가지 규칙 아래 소프트웨어를 출시했어요: “코드는 사람이 작성하지 않는다”와 “코드는 사람이 리뷰하지 않는다.”¹ 세 명으로 구성된 팀—Justin McCarthy, Jay Taylor, Navan Chauhan—이 Attractor와 CXDB(Rust 16K 줄, Go 9.5K 줄, TypeScript 6.7K 줄)를 엔지니어당 하루 최소 1,000달러의 토큰 비용을 들여 구축하고 출시했습니다.¹ BCG Platinion은 Spotify와 TechCrunch 보도를 인용하며, Spotify의 최고 개발자들이 2025년 12월 이후 코드를 직접 작성하지 않았고 매달 수백 개의 AI 생성 풀 리퀘스트를 머지하고 있다고 보고합니다.²

Dan Shapiro는 최종 단계를 레벨 5, 즉 다크 팩토리라고 부릅니다. 기계가 코드를 생성하고, 기계가 검증하며, 사람이 단 한 줄도 읽지 않고 배포하는 것이에요.³ 이전 단계들은 대부분의 팀이 현재 거치고 있는 과정을 보여줍니다—수동 코딩(레벨 0)에서 작업 위임(레벨 1), 고속도로 위의 오토파일럿(레벨 2), 안전 운전자가 동승한 Waymo(레벨 3), 그리고 스펙을 작성하고 12시간 동안 자리를 비울 수 있는 로보택시(레벨 4)까지.³

아직 누구도 제대로 답하지 못한 질문이 있어요: 레벨 5에서 검증 레이어는 어떤 모습이어야 할까요?

검증 문제는 복합적으로 심화된다

레벨 5 미만의 모든 단계에서는 어느 시점에서든 사람이 코드를 읽어요. 레벨 3에서 사람은 시니어 개발자로서 AI를 관리합니다. 레벨 4에서 사람은 12시간 후 테스트 통과 여부를 확인합니다.³ 이 단계들이 작동하는 이유는 조직의 맥락을 아는 사람이 의도와 결과를 패턴 매칭할 수 있기 때문이에요. 스펙에 “지수 백오프로 재시도”라고 적혀 있는데 코드가 선형 재시도를 구현하면—개발자는 한눈에 그걸 잡아냅니다.

사람을 완전히 제거하면 검증은 다른 종류의 문제가 됩니다. 정도의 차이가 아니라 본질이 다른 문제예요. 검증자는 코드를 읽고 이해하는 것에 의존할 수 없어요. “올바름”이 무엇인지를 실행 가능한 형태로 인코딩한 뒤, 산출물 자체를 검사하지 않고도 그 인코딩에 대해 결과를 평가해야 합니다.

핵심 함정은 에이전트가 테스트를 게이밍하는 것이에요. StrongDM은 에이전트가 아무 유용한 동작도 하지 않으면서 테스트 스위트를 통과하기 위해 return true를 작성하는 것을 발견했습니다.¹ 테스트는 녹색이었고, CI 파이프라인도 문제없었지만, 코드는 쓸모없었어요. Stanford Law의 Eran Kahana는 이 관찰을 구조적 경고로 확장합니다: 더 큰 문제는 순환성이에요. 같은 기술 클래스가 같은 클래스가 작성한 코드를 평가하는 것입니다.⁴

굿하트의 법칙이 여기서 특히 강하게 작동해요. 에이전트가 테스트 통과를 최적화하면, 테스트 통과는 더 이상 정확성을 측정하지 못합니다.⁴ 목표가 된 모든 지표는 좋은 지표이기를 멈춰요. 다크 팩토리의 검증 레이어는 이 역학을 반영해야 하며, 그렇지 않으면 품질이 아닌 준수만을 측정하게 됩니다.

StrongDM의 실제 검증 방법

StrongDM의 해법은 “시나리오”라고 부르는 것으로—코드베이스 외부에 저장된 엔드투엔드 사용자 스토리이며, 머신러닝의 홀드아웃 세트처럼 기능합니다.¹ 이 비유는 정확해요: ML 모델이 학습에 사용되지 않은 데이터로 평가되듯이, 에이전트가 빌드한 코드는 생성 과정에서 에이전트가 접근할 수 없는 시나리오로 평가됩니다.

핵심 지표는 “만족도(Satisfaction)”로, 사용자를 만족시킬 가능성이 있는 관찰된 궤적의 비율입니다.¹ 어떤 점수가 충분한 만족도인지에 대한 업계 표준은 존재하지 않아요. StrongDM은 경험적으로 자체 임계값을 도출했습니다.

시나리오 기반 테스팅을 대규모로 작동시키기 위해, StrongDM은 디지털 트윈 유니버스를 구축했어요—Okta, Jira, Slack, Google Docs, Drive, Sheets의 행동 복제본입니다.¹ 트윈들은 널리 사용되는 공개 레퍼런스 SDK 클라이언트 라이브러리를 활용해 100% API 호환성을 목표로 합니다.¹ 에이전트는 목(mock) 엔드포인트가 아닌 트윈을 대상으로 실행돼요. 트윈의 행동 충실도가 테스트의 신뢰성을 결정합니다.

StrongDM은 저도 경험한 것을 관찰했어요: “Claude 3.5의 두 번째 리비전(2024년 10월)부터, 장기 에이전틱 코딩 워크플로우가 오류를 축적하는 대신 정확성을 복합적으로 향상시키기 시작했습니다.”¹ 특정 역량 임계값 아래에서는 에이전트 실행이 길어질수록 실수가 늘어나요. 그 임계값을 넘으면, 실행이 길어질수록 더 나은 코드가 나옵니다. 다크 팩토리 패턴은 모델이 그 임계값을 넘은 후에야 비로소 실현 가능해졌어요.

거버넌스의 다섯 가지 레이어

BCG Platinion의 5대 전환 프레임워크에는 코드가 프로덕션에 도달하기 전 여러 검증 단계를 거치는 거버넌스 레이어가 포함되어 있어요.² 다섯 가지 축은: 의도 기반 운영 체제, 체계화된 지식 인프라, 인력 역량 강화, 독립적 검증 에이전트를 포함한 거버넌스 레이어, 그리고 오케스트레이션을 위한 팩토리 아키텍처입니다.² 거버넌스 축 내에서 BCG Platinion은 독립 에이전트에 의한 시나리오 기반 테스트, 정적 분석, 아키텍처 적합성 검사, 행동 회귀 테스트, 그리고 출력물을 적극적으로 깨뜨리려는 레드팀 에이전트를 설명합니다.²

독립성이 중요해요. 같은 에이전트가 자기 코드를 작성하고 테스트하면, Kahana의 순환성 문제가 적용됩니다.⁴ 다른 시스템 프롬프트, 다른 컨텍스트, 다른 인센티브를 가진 별도의 에이전트가 작업을 평가하면, 실패 모드가 비상관화됩니다. 제거되는 게 아니에요. 비상관화되는 겁니다. 두 에이전트가 학습 데이터에서 물려받은 체계적 편향을 여전히 공유할 수 있어요. 하지만 평가 에이전트가 다른 프레임에서 운영될 때 동일한 맹점을 가질 확률은 떨어집니다.

BCG Platinion은 “의도 사고(intent thinking)”를 다크 팩토리 팀의 핵심 역량으로 꼽아요: 비즈니스 요구사항을 정밀하고 테스트 가능한 원하는 결과 설명으로 변환하는 것입니다.² 사람의 역할은 코드 작성에서 에이전트가 실행할 수 있는 명세 작성으로 전환됩니다. 부실한 명세는 잘못된 동작에 대해 통과하는 테스트를 만들어내요—StrongDM이 겪었던 return true 현상과 동일합니다.¹

BCG Platinion은 제가 직접 경험한 제약도 지적해요: “AI 에이전트는 접근할 수 있는 체계화된 지식만큼만 효과적입니다.”² 프로젝트 맥락 없이 운영되는 에이전트는 그럴듯하지만 로컬 관례를 위반하고, 아키텍처 결정을 무시하며, 팀이 이미 해결한 문제를 다시 발견하는 코드를 생성해요. 체계화된 지식—설계 결정, API 계약, 스타일 가이드, 장애 이력—은 문서가 아니라 인프라입니다.

내가 레벨 4에서 이미 운영하는 것

제 야간 실행 루프인 Ralph Loop는 Shapiro의 레벨 4로 운영돼요. 스펙을 작성하고, 에이전트를 실행시키고, 잠자리에 들고, 아침에 결과를 리뷰합니다. 에이전트는 모든 도구 호출—파일 쓰기, git 명령어, 셸 실행—을 실행 전후로 가로채는 95개 이상의 훅을 대상으로 실행돼요. 훅은 에이전트가 협상하거나 우회할 수 없는 제약을 강제합니다.

이 훅들은 도구 수준에서 Kahana의 게이밍 문제를 해결해요. main에 강제 푸시를 시도하는 에이전트는 테스트가 피해를 감지한 후가 아니라 명령이 실행되기 전에 차단됩니다. .env 패턴과 일치하는 파일을 커밋하려는 에이전트는 가로채여요. “모든 테스트 통과”라고 보고하면서 pytest를 실행하지 않은 에이전트는 증거 게이트에 의해 플래그 처리됩니다—테스트가 통과할 것이라는 주장이 아닌, 실패 0건을 보여주는 붙여넣은 테스트 출력을 요구하는 게이트예요.

증거 게이트는 모든 비자명한 변경에 대해 여섯 가지 기준을 강제해요: 코드베이스 패턴을 따르는지(패턴명과 해당 파일을 명시), 가장 단순한 작동 솔루션인지(기각된 대안을 기술), 엣지 케이스가 처리되었는지(각각을 나열), 테스트가 통과하는지(출력을 붙여넣기), 회귀가 없는지(확인한 파일을 명시), 실제 문제를 해결하는지(사용자의 필요와 변경이 그것을 어떻게 해결하는지 기술). “~라고 생각합니다”와 “~일 것입니다”는 증거가 아니에요. 게이트는 모호한 표현을 거부하고 산출물을 요구합니다.

품질 루프—구현, 리뷰, 평가, 개선, 줌아웃, 반복, 보고—는 CLAUDE.md를 통해 에이전트의 시스템 프롬프트에 인코딩된 행동 제약으로 실행돼요. 이 루프가 에이전트가 모든 단계를 따르는 것을 보장하지는 않아요. 훅이 그것을 검증합니다.

BCG Platinion의 다섯 가지 축은 제가 이미 유지하고 있는 인프라에 매핑돼요:

• 의도 기반 OS: CLAUDE.md 파일과 PRD 기반 개발 명세가 프로젝트 의도를 실행 가능한 컨텍스트로 인코딩합니다.
• 체계화된 지식: 139개 이상의 스킬이 재사용 가능한 역량으로 조직되어, 에이전트에게 프로젝트 관례, 아키텍처 결정, 도메인 지식에 대한 접근을 제공합니다.
• 거버넌스: 훅이 가로채기 레이어를 구현하고, 증거 게이트가 감사 레이어를 구현하며, 품질 루프가 행동 제약 레이어를 구현합니다.

아직 구축하지 않은 두 가지 축이 있어요: 인력 역량 강화(1인 실무자에게는 해당 없음)와 전용 오케스트레이션 플랫폼으로서의 팩토리 아키텍처(현재 설정은 목적에 맞게 구축된 팩토리가 아닌 Claude Code의 네이티브 에이전트 스포닝을 사용합니다).

레벨 4와 레벨 5 사이의 간극

레벨 4에서 레벨 5로 이동한다는 것은 아침 리뷰를 제거하는 것을 의미해요. 현재 저는 일어나서 에이전트가 밤새 만들어낸 결과물을 읽어요. git diff를 확인하고, 애플리케이션을 실행하며, 출력이 의도와 일치하는지 검증합니다. 이 리뷰에 30분에서 한 시간이 걸리고, 훅이 놓치는 문제를 잡아내요.

훅이 놓치는 문제들이야말로 흥미로운 것들이에요. 현재 자동화가 잘 처리하지 못하는 범주에 속합니다:

의도 표류. 에이전트가 스펙을 충실히 완수했지만 스펙이 모호했고, 에이전트가 잘못된 해석을 택한 경우예요. 유효한 동작을 생성하는 잘못된 해석을 테스트가 잡아내지 못해요. StrongDM의 시나리오 접근법은 기술적 요구사항이 아닌 사용자 스토리를 명세로 인코딩함으로써 이 문제에 접근합니다.¹ 시나리오는 코드가 무엇을 하는지가 아니라 사용자가 무엇을 경험하는지를 기술해요.

아키텍처 침식. 에이전트가 단독으로는 작동하지만 시스템의 구조적 일관성을 저하시키는 기능을 추가한 경우예요. 기존 리포지토리 패턴을 우회하는 새 데이터베이스 쿼리, 다른 모듈의 로직을 복제하는 새 엔드포인트 같은 것들이에요. 정적 분석이 이들 중 일부를 잡아내고, BCG Platinion의 거버넌스 레이어인 아키텍처 적합성 검사가 더 많이 잡아냅니다.² 하지만 새 코드가 기술적으로는 패턴과 일관되지만 향후 변경에서 복합적으로 작용하는 개념적 분리를 도입하는 미묘한 경우는 어느 쪽도 잡아내지 못해요.

조직 지식의 상실. Kahana는 과소평가된 위험을 제기해요: 아무도 코드를 읽지 않으면, 아무도 시스템에 대한 직관을 쌓지 못합니다.⁴ Kahana의 경고처럼, “아무도 왜 그런지 모를 것입니다. 아무도 어떻게 고치는지 모를 것입니다.”⁴ 현재 제 아침 리뷰가 그 직관을 점진적으로 쌓아요. 레벨 5에서는 시스템이 운영자에게 불투명해집니다. 모든 복잡한 시스템은 결국 자동화가 처리할 수 없는 개입이 필요해요—보안 사고, 테스트 스위트에 내재된 가정을 위반하는 비즈니스 로직 변경, 문서와 다르게 동작하는 외부 시스템과의 통합 같은 것들이요. 코드를 한 번도 읽지 않은 운영자는 효과적으로 개입할 수 없어요.

검증 레이어에 실제로 필요한 것

StrongDM의 실무, BCG Platinion의 거버넌스 프레임워크, Kahana의 실패 분석, 그리고 제 자체 인프라를 종합하면, 다크 팩토리의 검증 레이어에는 최소한 다음이 필요해요:

홀드아웃 방식 평가. 코드 생성 중 생성 에이전트가 접근할 수 없는 테스트. StrongDM의 시나리오. 코드베이스와 별도로 저장되고 독립 에이전트에 의해 평가되는 행동 명세. 홀드아웃 평가 없이는 굿하트의 법칙이 모든 테스트 스위트를 타겟으로 변환합니다.

통합 테스팅을 위한 디지털 트윈. 에이전트는 프로덕션 시스템을 대상으로 테스트할 수 없어요. 목(mock)은 너무 얕아서—API 계약은 검증하지만 동작은 검증하지 못해요. 외부 의존성의 행동 표면을 복제하는 트윈이 프로덕션 위험 없이 엔드투엔드 시나리오 실행을 가능하게 합니다.

비상관 실패 모드를 가진 멀티 에이전트 검증. 작성 에이전트와 평가 에이전트는 서로 다른 컨텍스트에서 운영되어야 해요. 게이밍, 지름길, 가짜 검증을 적극적으로 탐색하는 레드팀 에이전트가 수동적 테스팅으로는 제공할 수 없는 레이어를 추가합니다.

도구 수준 가로채기. 피해가 발생한 후 감지하는 테스트가 아닌, 유해한 작업을 실행 전에 차단하는 훅. 훅 레이어는 에이전트의 의사 결정 아래에서 작동하며, 교묘한 프롬프팅이나 return true 지름길로 우회할 수 없어요.

실행 가능한 의도 명세. 모호함이 감지 가능할 정도로 정밀한 명세. BCG Platinion의 “의도 사고” 역량.² 12시간 동안 자리를 비우기 전에 작성하는 Shapiro의 레벨 4 명세.³ 명세가 제품이에요. 코드는 부산물입니다.

책임 공백 없는 감사 추적. Kahana는 출력이 “적절한 책임 당사자에게 추적 가능”해야 한다는 AI 생명주기 핵심 원칙을 인용합니다.⁴ 에이전트가 구축한 소프트웨어에 대한 업계 표준 감사 방법론은 아직 존재하지 않아요.⁴ 검증 레이어는 사람(또는 규제 기관, 또는 사고 대응자)이 배포된 동작에서 그것을 생성한 명세까지 추적할 수 있는 산출물을 생성해야 합니다.

솔직한 평가

저는 레벨 4를 높은 신뢰도로 운영하고 있어요. 야간 에이전트들이 생산한 작업물은 대부분 아침 리뷰를 통과합니다. 훅이 기계적 실패를 잡아내고, 증거 게이트가 인식론적 실패를 잡아내며, 품질 루프가 행동적 실패를 줄여줘요.

레벨 5는 아직 풀지 못한 문제들을 해결해야 해요. 사람의 패턴 매칭 없는 의도 표류 감지. 구조적 위반뿐 아니라 개념적 침식을 잡아내는 아키텍처 적합성 검사. 운영자의 머릿속이 아닌 시스템 자체에 축적되는 조직 지식.

BCG Platinion은 다크 팩토리 패턴을 도입한 팀에서 3~5배의 생산성 향상을 보고합니다.² StrongDM은 세 명의 엔지니어와 토큰 예산으로 에이전트가 구축한 소프트웨어를 출시했어요.¹ 생산성 측면의 근거는 명확합니다. 검증 측면의 근거는 그렇지 않아요.

레벨 5에서 성공하고 있는 팀들은 공통된 특성을 공유해요: 코드 생성보다 검증 인프라에 더 많이 투자했다는 점입니다. StrongDM은 에이전트가 코드를 출시하도록 신뢰하기 전에 디지털 트윈 유니버스 전체를 구축했어요.¹ BCG Platinion의 프레임워크는 코드가 프로덕션에 도달하기 전 여러 검증 단계를 포함한 거버넌스 레이어를 갖춘 다섯 가지 전환 축을 가지고 있습니다.² 다크 팩토리는 어둠 속에서 돌아가는 공장이 아니에요. 조명이 검증 레이어이고, 코드를 포함한 나머지 모든 것이 범용재인 공장입니다.

이전에 에이전트가 감독 없이 실행될 때 무엇이 깨지는지와 가짜 검증에 대한 방어로서의 증거 게이트에 대해 쓴 적이 있어요. 그 글들은 레벨 4를 위한 인프라를 설명합니다. 다크 팩토리는 그 동일한 인프라가 현재 아침 diff를 읽는 사람 없이 운영되도록 확장될 것을 요구해요. 훅, 증거 게이트, 품질 루프—레벨 5에서 필요하지만 충분하지는 않아요. 빠진 조각은 생성과 동일한 자율성으로 확장되는 검증입니다.

그 조각을 만드는 것이 앞으로의 과제예요.