AI 다크 팩토리 구조 해설: 자율 코딩 하네스를 이루는 다섯 가지 구성 요소와 검증 전략

핵심 메시지

• AI 다크 팩토리는 스펙 문서를 넣으면 검토와 검증까지 끝난 코드가 배포되어 나오는 저장소를 뜻하며, 코딩 하네스를 끝까지 밀어붙인 형태다.
• AI 코딩 자율성은 다섯 단계로 나뉘는데, 대부분의 사람은 계획과 검증에 사람이 남아 있는 3단계에 머물러야 하고 다크 팩토리는 그보다 높은 단계다.
• 핵심은 자유방임이 아니라 사전 설계다. 에이전트를 믿고 맡기기 위해 앞단에서 하네스를 공들여 만드는 것이 전제 조건이다.
• 지침 계층은 전역 규칙, 팩토리 규칙, 미션 문서 세 파일로 나뉘며, 미션 문서에는 범위 밖 항목을 적어 에이전트가 스펙을 거절할 수 있게 한다.
• 신뢰성을 좌우하는 것은 검증 구조다. 만드는 에이전트와 검증하는 에이전트를 분리하고, 빌더가 절대 볼 수 없는 별도의 시나리오로 결과를 확인한다.

쉽게 이해하기

AI 다크 팩토리는 사람이 조명을 켜지 않아도 돌아가는 무인 공장에서 이름을 따온 개념이다. 다음에 만들고 싶은 것에 대한 명세를 넣으면, 검토와 검증을 마친 코드가 배포까지 되어 나오는 저장소를 가리킨다. 발표자는 올해 초부터 자신의 유튜브 채널 콘텐츠를 검색하고 출처까지 인용해 주는 대화형 앱을 이 방식으로 만들었는데, 배포된 코드를 단 한 줄도 직접 보지 않았다고 말한다. 다만 아직 모든 종류의 작업에 신뢰할 수 있는 방식은 아니며 실험적 단계라는 단서를 분명히 붙인다.

위치를 가늠하기 위해 발표자는 댄 셔피로가 정리한 AI 코딩 자율성 5단계를 인용한다. 0단계는 수동 변속기처럼 사람이 대부분의 코드를 쓰고 자동 완성 정도만 AI에 맡기는 상태다. 1~2단계는 AI가 짝 프로그래머 역할을 하며 반복적인 뼈대 코드를 대신 만들어 주는 단계다. 3단계에서 비로소 코드 작성 자체는 대부분 에이전트가 맡지만, 계획과 최종 검증에는 사람이 그대로 남아 있다. 발표자는 이 3단계가 지금으로서는 가장 신뢰할 만하며 대부분이 머물러야 할 자리라고 못 박는다. 문제는 사람이 계획과 검증에 매번 끼어들어야 하므로 사람이 병목이 된다는 점이고, 다크 팩토리는 그 병목을 없애려는 시도다.

구조의 뼈대는 하나의 워크플로다. 발표자는 다크 팩토리를 깃허브 저장소로 두고, 넣고 싶은 스펙을 이슈로 등록한다. 이슈가 들어가면 계획, 구현, 테스트, 검증을 거쳐 풀 리퀘스트로 끝나는 흐름이 자동으로 돈다. 이때 코딩 에이전트는 헤드리스 모드, 즉 사람이 대화창을 붙잡지 않아도 배경 작업처럼 돌아가는 방식으로 호출된다. 사람이 매번 상호작용해야 한다면 다크 팩토리라는 개념 자체가 성립하지 않기 때문이다.

두 번째 부품은 대기열을 굴리는 자동화다. 발표자의 설정에서는 30분마다 크론 작업이 돌면서 들어온 이슈들을 분류한다. 이슈마다 라벨을 붙여 두기 때문에 실행과 실행 사이에도 상태가 유지된다. 수락된 것은 다음 실행에서 작업에 들어가고, 진행 중인 것은 건너뛰며, 검토가 필요한 것은 풀 리퀘스트가 열린 상태를 뜻한다. 우선순위도 정해져 있어 수정이 필요한 풀 리퀘스트를 가장 먼저 처리하고, 그다음이 검토, 그다음이 새 이슈 착수, 마지막이 신규 스펙 분류다. 여러 작업을 병렬로 돌릴 수도 있지만 사용량 한도에 금세 부딪히므로 몇 건 정도로 제한하기를 권한다. 사람을 완전히 빼는 것이 목표지만, 에이전트가 같은 문제를 고치려다 무한 반복에 빠지는 경우를 대비해 사람에게 넘기는 안전장치도 함께 둔다.

세 번째는 배포다. 발표자는 병합만으로는 부족하다는 점을 강조한다. 풀 리퀘스트가 병합되어도 실제 사용자 앞에 코드가 놓이지 않는다면 그것은 다크 팩토리가 아니라 풀 리퀘스트 생성기일 뿐이라는 것이다. 권장하는 방식은 블루-그린 배포로, 같은 애플리케이션을 두 벌 유지하다가 대기 중인 쪽을 갱신한 뒤 전환해 사용자 쪽 중단 시간을 없앤다.

네 번째는 지침 계층이고, 파일 세 개로 나뉜다. 전역 규칙은 저장소에서 코딩 에이전트가 늘 지켜야 할 관례와 제약이다. 팩토리 규칙은 자율 실행 중에만 적용되는 더 엄격한 경계로, 예컨대 사람이 지켜보지 않는 상황에서는 한 번에 너무 많은 일을 하지 않고 작은 단위로 쪼개 처리하도록 강제한다. 평소 작업에서도 알아야 할 내용인지가 두 파일을 가르는 기준이다. 세 번째 파일인 미션 문서에는 애플리케이션의 목표와 함께 범위 밖 항목을 적는다. 이 항목이 있어야 에이전트가 들어온 스펙을 거절할 수 있는데, 발표자는 사람이 자기 목표를 잊고 엉뚱한 요청을 넣을 때 에이전트가 되받아 지적할 수 있는 장치를 일부러 넣었다고 설명한다. 너무 복잡한 스펙은 쪼개자고 제안하는 것도 같은 맥락이다.

마지막이 검증 구조이며, 발표자가 가장 공을 들였다고 말하는 부분이다. 팩토리 안에는 만드는 빌더와 검사하는 검증자, 두 에이전트가 있다. 코딩 에이전트는 스스로 구현하는 과정에서 편향이 쌓이기 때문에, 구현 과정이나 원래 계획을 모르는 별도의 세션이 비판적으로 들여다봐야 한다는 것이다. 여기서 핵심 장치가 홀드아웃 시나리오다. 구현 세부와 완전히 분리해 "이 애플리케이션이 성공적으로 동작한다는 것이 무엇인지"를 작업 전에 미리 적어 두되, 빌더는 이 시나리오를 절대 볼 수 없게 한다. 빌더가 시나리오를 통과시키려고 앱을 뒤틀어 설계하는 것을 막기 위해서다. 빌더에게는 단위 테스트와 통합 테스트 정도만 주어 스스로 다듬게 하고, 검증자는 그와 별개의 검사 묶음을 돌린 뒤 문제를 빌더에게 되돌려 보낸다.

주요 인사이트

• 자율성을 올린다는 것은 사람이 손을 떼는 일이 아니라 앞단에 공학을 더 넣는 일이다. 발표자가 이것을 바이브 코딩과 분명히 구분하는 이유도 여기에 있다.
• 배포까지 자동화되지 않으면 자율 코딩 시스템은 완성되지 않는다. 병합에서 멈추는 순간 사람이 다시 마지막 관문이 되고, 없애려던 병목이 그대로 남는다.
• 규칙 파일을 전역과 자율 실행용으로 나눈 발상이 실용적이다. 사람이 지켜보는 작업에 걸면 답답하기만 한 제약이라도, 감시자가 없는 실행에서는 신뢰성을 지키는 장치가 된다.
• 에이전트에게 거절권을 주는 설계는 흔치 않다. 스펙을 유일한 진실로 삼지 않고 미션 문서와 대조해 범위 밖이면 되돌려 보내게 하면, 사람의 실수도 걸러지는 방향이 된다.
• 홀드아웃 시나리오의 요지는 정보 차단이다. 빌더가 채점 기준을 모르고 검증자가 구현 계획을 모를 때에만 두 역할이 서로의 편향을 상쇄한다.
• 발표자 스스로 다크 팩토리를 아직 실험적이라 부르고 가장 신뢰할 수 있는 자리는 3단계라고 말한다는 점은, 이 구조를 지금 당장 업무에 그대로 옮기기보다 부분적으로 빌려 쓰는 편이 낫다는 신호로 읽힌다.

자주 묻는 질문

관련 AI 소식