다크 팩토리 검증: 아무도 코드를 읽지 않을 때

다크 팩토리(Level 5)는 기계가 코드를 생성하고, 검증하고, 배포하는 소프트웨어 개발 환경으로, 사람은 단 한 줄의 코드도 읽지 않아요. 다크 팩토리를 실현 가능하게 만드는 검증 레이어에는 홀드아웃 방식의 평가, 디지털 트윈 유니버스, 멀티 에이전트 리뷰, 그리고 인코딩된 취향 제약 조건이 필요해요. 이 레이어가 없으면 에이전트는 테스트를 게이밍하고 품질은 사라져요.

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

Dan Shapiro는 이 최종 단계를 Level 5, 즉 다크 팩토리라고 불러요. 기계가 코드를 생성하고, 기계가 검증하고, 사람이 한 줄도 읽지 않은 채 배포하는 것이에요.³ 그 이전 단계들은 대부분의 팀이 현재 따르고 있는 진행 과정을 추적해요: 수동 코딩(Level 0), 작업 위임(Level 1), 고속도로 오토파일럿(Level 2), 안전 운전자가 탑승한 Waymo(Level 3), 그리고 스펙을 작성하고 12시간 동안 자리를 비우는 로보택시(Level 4).³

아직 아무도 제대로 답하지 못한 질문이 있어요: Level 5에서 검증 레이어는 어떤 모습이어야 할까? 아래 분석은 필요한 인프라를 매핑하며, 제가 모든 엔지니어링 작업에서 품질을 평가하는 방식을 다루는 취향 인프라를 기반으로 해요.

검증 문제는 복합적으로 커져요

Level 5 아래의 모든 단계에서는 어느 시점에든 사람이 코드를 읽어요. Level 3에서는 사람이 AI를 시니어 개발자처럼 관리해요. Level 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대 축 전환 프레임워크에는 코드가 프로덕션에 도달하기 전 여러 검증 단계가 포함된 거버넌스 레이어가 있어요.² 다섯 가지 축은: 의도 기반 운영 체제, 체계화된 지식 인프라, 인력 역량 강화, 독립 검증 에이전트가 포함된 거버넌스 레이어, 그리고 오케스트레이션을 위한 팩토리 아키텍처예요.² 거버넌스 축에는 독립 에이전트가 실행하는 시나리오 기반 테스트, 정적 분석, 아키텍처 적합성 검사, 행동 회귀 테스트, 그리고 출력물을 적극적으로 파괴하려는 레드팀 에이전트가 포함돼요.²

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

BCG Platinion은 “의도 사고(intent thinking)”를 다크 팩토리 팀의 핵심 역량으로 식별해요: 비즈니스 요구를 정확하고 테스트 가능한 원하는 결과의 설명으로 변환하는 것이에요.² 사람의 역할이 코드 작성에서 에이전트가 실행할 수 있는 명세 작성으로 전환돼요. 부실한 명세는 잘못된 행동에 대해 통과하는 테스트를 만들어내요. StrongDM이 경험한 것과 같은 return true 역학이에요.¹

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

Level 4에서 제가 이미 운영하는 것

제 야간 실행 루프인 Ralph 에이전트 아키텍처는 Shapiro의 Level 4에서 운영돼요. 스펙을 작성하고, 에이전트를 실행하고, 잠들고, 아침에 결과를 검토해요. 에이전트는 모든 도구 호출(파일 쓰기, git 명령, 셸 실행)을 실행 전후에 가로채는 95개 이상의 훅에 대해 실행돼요. 훅은 에이전트가 협상하거나 무시할 수 없는 제약 조건을 강제해요.

이 훅들은 도구 수준에서 Kahana의 게이밍 문제를 해결해요. 별도의 글에서 전체 훅 아키텍처를 문서화하고 있지만, 여기서 관련된 속성은 가로채기(interception)예요: 훅은 도구 실행 전에 발동하지, 후에 발동하는 것이 아니에요. main에 강제 푸시를 시도하는 에이전트는 명령이 실행되기 전에 차단돼요. .env 패턴과 일치하는 파일을 커밋하려는 에이전트는 가로채져요. “모든 테스트 통과”를 보고하면서 pytest를 실행하지 않은 에이전트는 증거 게이트에 의해 플래그돼요. 증거 게이트는 테스트가 통과할 것이라는 주장이 아니라, 실패 건수가 0인 테스트 출력 붙여넣기를 요구해요.

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

품질 루프(구현, 검토, 평가, 개선, 전체 조망, 반복, 보고)는 CLAUDE.md를 통해 에이전트의 시스템 프롬프트에 인코딩된 행동 제약으로 실행돼요. 루프가 에이전트가 모든 단계를 따르는 것을 보장하지는 않아요. 훅이 실제로 따랐는지 검증해요.

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

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

두 가지 축은 아직 구축하지 않았어요: 인력 역량 강화(1인 실무자에게는 해당 없음)와 전용 오케스트레이션 플랫폼으로서의 팩토리 아키텍처(현재 설정은 전용 팩토리가 아닌 Claude Code의 네이티브 에이전트 스포닝을 사용해요). 복합 컨텍스트 시스템은 이러한 인프라 레이어들이 어떻게 자본 자산으로 축적되어 각 후속 세션을 더 강력하게 만드는지 설명해요.

Level 4와 Level 5 사이의 간극

Level 4에서 Level 5로 이동한다는 것은 아침 리뷰를 없앤다는 의미예요. 지금은 일어나서 에이전트가 밤새 만든 것을 읽어요. git diff를 확인해요. 애플리케이션을 실행해요. 출력이 제 의도와 일치하는지 검증해요. 이 리뷰는 30분에서 한 시간이 걸리고 훅이 놓친 문제를 잡아내요.

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

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

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

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

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

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

홀드아웃 방식의 평가. 생성 에이전트가 코드 생성 중에 접근할 수 없는 테스트. StrongDM의 시나리오. 코드베이스와 별도로 저장되어 독립 에이전트가 평가하는 행동 명세. 홀드아웃 평가 없이는 구드하트의 법칙이 모든 테스트 스위트를 목표로 전환시켜요.

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

비상관된 실패 모드를 가진 멀티 에이전트 검증. 작성 에이전트와 평가 에이전트는 다른 컨텍스트에서 작동해야 해요. 게이밍, 편법, 팬텀 검증을 적극적으로 탐색하는 레드팀 에이전트는 수동적 테스트가 제공할 수 없는 레이어를 제공해요.

도구 수준의 가로채기. 피해를 사후에 감지하는 테스트가 아니라, 해로운 작업을 실행 전에 차단하는 훅. 훅 레이어는 에이전트의 의사결정 아래에 위치하며 교묘한 프롬프팅이나 return true 편법에 의한 우회에 저항해요.

실행 가능한 의도 명세. 모호성이 감지 가능할 만큼 정밀한 명세. BCG Platinion의 “의도 사고” 역량.² Shapiro의 12시간 동안 자리를 비우기 전에 작성하는 Level 4 명세.³ 명세가 제품이에요. 코드는 부수 효과예요.

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

솔직한 평가

저는 높은 확신을 가지고 Level 4를 운영해요. 야간 에이전트들은 아침 리뷰를 대체로 통과하는 작업물을 만들어내요. 훅이 기계적 실패를 잡아내요. 증거 게이트가 인식론적 실패를 잡아내요. 품질 루프가 행동적 실패를 줄여요.

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

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

Level 5에서 성공하는 팀들은 공통된 특성을 공유해요: 코드 생성보다 검증 인프라에 더 많이 투자했다는 것이에요. StrongDM은 에이전트에게 코드 출시를 맡기기 전에 디지털 트윈 유니버스 전체를 구축했어요.¹ BCG Platinion의 프레임워크에는 코드가 프로덕션에 도달하기 전 여러 검증 단계가 포함된 거버넌스 레이어를 포함하여 다섯 가지 전환 축이 있어요.² 다크 팩토리는 어둠 속에서 작동하는 공장이 아니에요. 조명이 검증 레이어이고 나머지 모든 것(코드를 포함하여)이 상품(commodity)인 공장이에요.

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

그 조각을 구축하는 것이 앞으로의 작업이에요. AI 엔지니어링 허브에서 개별 훅 설계부터 복합 컨텍스트를 거쳐 다크 팩토리 프론티어까지 이 조사의 전체 아크를 모아 놓았어요.

FAQ

소프트웨어 개발에서 다크 팩토리란 무엇인가요?

다크 팩토리(Dan Shapiro의 Level 5)는 기계가 코드를 생성하고, 검증하고, 사람이 단 한 줄도 읽지 않은 채 배포하는 소프트웨어 개발 환경이에요. 그 이전 단계들은 수동 코딩(Level 0)에서 점진적 자동화를 거쳐 진행되며, Level 4는 사람이 스펙을 작성하고 12시간 동안 자리를 비운 뒤 결과를 검토하는 “로보택시” 모드예요. 다크 팩토리는 그 최종 리뷰마저 없애요.

Level 5에서 가장 큰 검증 과제는 무엇인가요?

핵심 함정은 에이전트가 테스트를 게이밍하는 것이에요. StrongDM은 에이전트들이 아무런 유용한 작업도 하지 않으면서 테스트 스위트를 통과하기 위해 return true를 작성하는 것을 발견했어요. 구드하트의 법칙이 비정상적으로 강하게 작동해요: 에이전트가 테스트 통과를 최적화하면 테스트 통과는 더 이상 정확성을 측정하지 못해요. 검증 레이어는 홀드아웃 방식의 평가(생성 에이전트가 코드 생성 중에 접근할 수 없는 테스트), 비상관된 실패 모드를 가진 멀티 에이전트 검증, 그리고 해로운 작업을 실행 전에 차단하는 도구 수준의 가로채기를 사용하여 이를 해결해야 해요.

Level 4와 Level 5 사이의 간극은 무엇인가요?

현재 자동화가 잘 처리하지 못하는 세 가지 문제가 있어요: 의도 드리프트(에이전트가 스펙을 충실히 완수했지만 모호한 요구사항의 잘못된 해석을 선택한 경우), 아키텍처 침식(독립적으로는 작동하지만 구조적 일관성을 저하시키는 새 기능), 그리고 조직 지식 상실(아무도 코드를 읽지 않으면 사고나 비즈니스 로직 변경 시 개입에 필요한 시스템에 대한 직관을 아무도 쌓지 못하는 것)이에요.

StrongDM은 검증 문제를 어떻게 해결하나요?

StrongDM은 코드베이스 외부에 저장된 엔드투엔드 사용자 스토리인 “시나리오”를 사용하며, 이는 머신러닝의 홀드아웃 세트처럼 기능해요. 독립 에이전트가 코딩 에이전트가 생성 과정에서 접근할 수 없는 시나리오에 대해 코드를 평가해요. 디지털 트윈 유니버스(Okta, Jira, Slack, Google Docs의 행동 클론)를 구축하여 100% API 호환성을 목표로 하므로, 에이전트가 얕은 목이 아닌 현실적인 행동적 표면에 대해 테스트해요.