당신의 소프트웨어 팩토리는 다크 키친(Dark Kitchen)입니다. 아무도 언급하지 않는 1,000달러의 비밀

2021년 여름, 모두가 다크 키친(dark kitchen)을 열었습니다. 도시 외곽의 산업 공간을 임대하고, Deliveroo에 브랜드를 올린 뒤, 식당 내부와 서비스 직원을 완전히 생략하는 방식이었죠. 그 제안은 반박하기 어려웠습니다. 실제 레스토랑의 운영 비용(overhead) 없이 생산할 수 있으니까요. 하지만 성공 사례들이 생략한 사실이 있습니다. Deliveroo의 수수료는 20~30%에 달했고, 운영자의 절반은 품질 관리(quality control) 프로세스가 없었으며, 브리게 드 구(brigade de goût, 음식이 주방을 떠나기 전 맛을 보는 팀)도 존재하지 않았습니다. 생산 라인은 계속 돌아갔고, 음식은 나갔습니다. 배달 음식은 그때나 지금이나 복권과 같습니다. 변한 것은 아무것도 없습니다. 하지만 이야기가 옆길로 샜군요.

요약(TLDR): 대부분의 소프트웨어 팩토리(software factory) 관련 게시물은 **속도(speed)**에 대해 이야기합니다. 한 달에 650개의 PR(Pull Request), 엔지니어 3명이서 100만 줄의 코드 등 말이죠. 하지만 그 수치들을 안전하게 실행할 수 있게 만드는 **하루 1,000달러짜리 계층(layer)**에 대해서는 아무도 언급하지 않습니다. 제 팩토리는 그것 없이 운영되었습니다. 그 결과물이 내놓은 결과가 그것을 아주 명확하게 보여주었습니다.

2026년, 모두가 **소프트웨어 팩토리(software factory)**를 열고 있습니다. 각 단계마다 인간의 확인(checkpoint) 없이 계획하고, 코딩하고, 테스트하고, 배포하는 에이전트(Agents)들 말입니다. 수치는 실재합니다. BCG Platinion의 2026년 4월 분석에 따르면, Spotify는 2025년 12월 이후로 단 한 줄의 수동 코드(manual line)도 작성하지 않았습니다 (월 650개의 AI 생성 PR, 마이그레이션 속도 90% 향상). OpenAI는 5개월 만에 100만 줄의 코드를 엔지니어 3명이서 수동 코드 없이 작성했습니다. 누구도 이 수치를 지어내지 않습니다. 그리고 그들이 생략하고 있는 사실 또한 지어낸 것이 아닙니다.

저의 파이프라인은 **이커머스 백엔드 (ecommerce backend)**를 위한 자동화된 변환 작업을 수행합니다 (유통업체의 CSV 피드에서 가져온 제품 데이터, 파트너 API 연동 등 일반적인 작업들). 대체로 자율적입니다. 에이전트(Agents)가 반복적인 작업을 처리하고, 저는 체크포인트에서 검토합니다. 적어도 그렇다고 생각했습니다. 팩토리는 제품을 출고했습니다. 그러자 파트너의 **라이브 API (live API)**에 대한 지원 티켓(Support tickets)이 쏟아졌습니다 (샌드박스 엔드포인트가 설정 파일에 그대로 있었음에도, 에이전트가 라이브 엔드포인트를 선택해 버린 것입니다). 고객 주문 기록은 제가 스택 내에 여전히 활성화되어 있다는 사실을 반쯤 잊고 있었던 외부 분석 서비스와 연결된 로깅 엔드포인트로 전송되었습니다. 그러더니 파이프라인은 사이트맵 작업의 일부로 스스로 범위 내에 있다고 판단한 내부 백엔드 경로(쿼리 스트링에 포함된 세션 토큰)를 **Google의 인덱싱 API (Google's indexing API)**에 제출했습니다. 코드는 컴파일되었고 파이프라인은 이상 없다고 보고했습니다. 에이전트는 작업을 완료로 표시했습니다. 적어도 다크 소울(Dark Souls)은 플레이가 잘못되었다는 것을 알 수 있도록 'YOU DIED' 화면이라도 보여줍니다. 대시보드는 저에게 초록색 체크 표시를 보여주었습니다.

에이전트는 당신이 말한 것을 정확히 수행합니다. **재앙 (disaster)**은 당신이 말하지 않은 모든 것입니다.

모두가 다크 키친을 열었던 그해 여름

다크 키친(Dark Kitchen) 모델은 스프레드시트 상으로는 완벽해 보였습니다. 홀을 없애고, 하나의 주방에서 여러 브랜드를 운영하며, 모든 주문을 기존 배달 플랫폼을 통해 처리하는 방식입니다. 플랫폼 수수료와 아무도 감사(Audit)하지 않았던 부분, 즉 주방에서 나간 음식이 고객이 실제로 주문한 것이 맞는지 여부를 고려하기 전까지는 단위 경제성(Unit economics)이 깔끔해 보였습니다.

구조적인 결함은 운영 내부에서는 보이지 않았습니다. 주방은 돌아갔고, 주문은 처리되었으며, 물량 지표는 건강해 보였습니다. 문제는 고객들이 불만을 제기하기 시작했을 때 나타났습니다 (잘못된 요리, 잘못된 온도, 완전히 잘못된 주소 등). 그때 이미 음식은 문 앞에 도착한 상태였습니다.

다크 키친 (Dark Kitchen) 열풍은 2021년 중반에 정점에 달했다가 2022년 말까지 급격히 위축되었습니다. 살아남은 운영자들은 주방과 배달 플랫폼 사이에 일종의 **품질 게이트 (quality gate)**를 구축했습니다. 인프라를 운영 규율 (operational discipline)의 완전한 대체제로 취급했던 이들은 가장 먼저 문을 닫았습니다. 그것이 패턴입니다. 2026년 버전의 소프트웨어 팩토리는 훨씬 더 큰 예산이 투입된 동일한 영화와 같습니다.

소프트웨어 팩토리의 실제 정체

제기되고 있는 실제 주장부터 시작해 보겠습니다. 소프트웨어 팩토리는 단순히 "AI가 코드를 더 빠르게 작성한다"는 의미가 아닙니다. 그것은 에이전트(agents)가 계획, 구현, 테스트 및 배포를 처리하며 각 단계에서 **인간의 체크포인트 (human checkpoint)**가 전혀 없는 완전한 생산 파이프라인을 의미합니다. 인간은 방향을 설정합니다. 팩토리는 검토(review) 사이의 시간 동안 작동합니다.

여기서 BCG Platinion의 2026년 4월 분석 프레임워크가 유용합니다. 그들의 용어인 **"다크 소프트웨어 팩토리 (Dark Software Factory)"**는 코드가 인간에 의해 전혀 작성되거나 검토되지 않는, AI 통합의 최고 단계를 나타냅니다. StrongDM 팀은 이를 두 가지 명시적인 규칙으로 실행에 옮겼습니다: 코드는 인간이 작성해서는 안 되며, 코드는 인간이 검토해서는 안 된다는 것입니다. 이는 지향점이 아니라, 엄격한 제약 조건 (hard constraint)으로서의 규칙입니다.

유포되고 있는 수치들은 다음과 같습니다: Spotify는 한 달에 650개의 AI 생성 PR (Pull Request)을 처리하며, 마이그레이션 속도가 90% 빨라졌고, 2025년 12월 이후 수동 코드 라인이 제로(0)입니다. OpenAI는 5개월 동안 3명의 엔지니어로 100만 라인의 신제품 코드를 작성했습니다. 이것들이 게시물들에 올라오는 수치들입니다.

하지만 게시물에 실리지 않은 내용이 있습니다: Cow-Shed Startup의 2026년 3월 분석에서 인용한 METR의 2025년 무작위 대조 시험 (randomised control trial)에 따르면, AI의 도움을 받아 작업하는 개발자들은 스스로 24% 더 빠르다고 추정했음에도 불구하고, 복잡한 작업에서는 19% 더 오래 걸리는 것으로 나타났습니다. 방향과 진폭 모두에서 오차가 발생한 것입니다. 팩토리는 빠르게 느껴지지만, 그것이 팩토리가 정확하다는 것과 같은 의미는 아닙니다.

아무도 링크드인 게시물에 쓰지 않는 결함

소프트웨어 팩토리 대시보드: 추적된 지표 vs 무시된 사각지대 (Software Factory Dashboard: Tracked Metrics vs Ignored Blind Spots)

제가 읽어본 모든 소프트웨어 팩토리 관련 게시물들(BCG 분석, 5단계 프레임워크, LinkedIn 스레드 분석 등)은 수준(level), 속도(speed), 그리고 도구(tooling)만을 다룹니다. 그중 어떤 것도 결과물이 파이프라인을 벗어나 **외부 시스템(external systems)**과 접촉할 때 어떤 일이 발생하는지는 다루지 않습니다.

속도 지표는 측정하기 쉽습니다. PR(Pull Request) 수를 세고, 배포 시간(deploy time)을 측정하며, 테스트 통과율(test pass rate)을 추적하고, 엔지니어 1인당 주간 생성 코드 라인 수를 계산할 수 있습니다. 하지만 쉽게 측정할 수 없는 것은 바로 **범위(scope)**입니다(에이전트가 건드려야 할 부분만 건드렸는지, 그리고 그 이상의 영역은 건드리지 않았는지 여부). 이 질문은 팩토리가 최적화하는 피드백 루프(feedback loop) 내에 존재하지 않습니다. 왜냐하면 그 피드백 루프는 경계(boundaries)가 아니라 출력물(outputs)을 측정하기 위해 구축되었기 때문입니다. 따라서 팩토리는 측정 가능한 것들을 측정하고, 해당 차원에서의 승리를 선언하며, 그 외의 모든 것들은 나중에 발견하게 될 부작용(side effect)으로 배송해 버립니다. 대개 이 부작용은 예상치 못한 것을 전달받은 외부 당사자로부터 발견하게 되는데

2026년 2월 Medium에 게시된 StrongDM의 공개 코드를 검토한 한 비평가는, 워크플로우(workflow)의 참신함에 휩쓸려 실제로 무엇이 생산되었는지 놓치기 쉽다고 지적했습니다. 그것이 바로 진단입니다. 공장은 **전진하고 있다는 느낌(sensation of forward motion)**을 전달합니다. 느낌(sensation)과 품질(quality)은 서로 다른 측정 도구입니다.

당신에게 없는 '브리게 드 구(Brigade de Goût)'

전문적인 주방에서 **브리게 드 구(brigade de goût, 맛 검사단)**는 요리를 하지 않습니다. 그들은 생산 라인의 일부가 아닙니다. 그들의 역할은 주방에서 만들어진 음식이 나가기 전에 맛을 보는 것입니다(음식을 만든 사람들과는 분리된 독립적인 계층이며, 해당 요리가 만들기 어려웠는지 쉬웠는지에 대해 이해관계가 없습니다). 그들은 배포되어서는 안 될 것을 잡아내기 위해 존재합니다.

대부분의 빌더(builder)들은 이와 같은 것을 가지고 있지 않습니다. 그들은 돌아가는 공장, 통과하는 테스트 스위트(test suite, 종종 작업을 수행하는 동일한 에이전트가 작성함), 그리고 "컴파일되었으니 괜찮다"라는 확신을 가지고 있습니다. 그 확신이야말로 StrongDM의 홀드아웃(holdout) 설정이 약화시키도록 설계된 바로 그 지점입니다.

Simon Willison의 2026년 2월 글에 따르면, 무언가를 진정한 소프트웨어 공장이라고 부르기 위한 신뢰성 임계값은 **인간 엔지니어 1인당 하루에 1,000달러 상당의 토큰(tokens)**입니다. 이는 홀드아웃 검증 계층(holdout validation layer)을 지속적으로 실행하는 비용입니다. 브리게 드 구에는 가격이 따릅니다. 이는 Deliveroo 수수료와 맞먹는 수준입니다(품질을 진지하게 다루는 데 드는 운영 오버헤드(operating overhead)를 아무도 앞세우고 싶어 하지 않기 때문에, 성공 사례 게시물에는 나타나지 않는 숫자입니다).

대부분의 1인 빌더는 하루에 1,000달러의 검증 토큰을 사용할 수 없습니다. 저 역시 불가능합니다. 이것은 변명이 아니라 실제적인 제약 사항입니다. 정답은 품질 게이트(quality gate)를 건너뛰는 것이 아닙니다. 먼저 수동 버전을 구축하는 것입니다(실제로 무엇을 잡아내려고 하는지 이해한 다음, 예산이 허용하는 범위 내에서 자동화하는 것입니다).

한 가지 중요한 차이점이 있습니다. **에이전트가 작성하는 테스트 스위트 (test suite)**는 당신의 맛 평가단 (brigade de goût)이 아닙니다. 에이전트는 자신이 알고 있는 테스트에 최적화됩니다. 홀드아웃 시나리오 (Holdout scenarios)가 효과가 있는 이유는 에이전트가 그것을 본 적이 없기 때문입니다. 만약 에이전트가 개발 과정에서 테스트를 볼 수 있다면, 실제 문제를 해결하지 않고도 테스트를 통과할 수 있습니다. 테스트 통과율은 100%일 수 있지만, 부작용의 영향 범위 (side-effect blast radius)는 여전히 상당할 수 있습니다. 제가 어떻게 아냐고요? 사실, 묻지 마세요. 즐거운 이야기는 아니니까요.

사건 이후 내가 한 일

파이프라인이 무엇을 건드렸는지 이해한 후, 어떤 기술적 해결책을 마련하기에 앞서 한 가지 질문이 떠올랐습니다. 에이전트는 자신이 무엇을 건드려도 되는지 어떻게 알았을까요? 답은 '몰랐다'는 것이었습니다. 아무도 명시적으로 말해주지 않았습니다. 그 범위는 제 머릿속의 가정으로만 존재했을 뿐, 에이전트가 참조할 수 있는 곳 어디에도 기록되지 않았습니다. 경계 문서 (boundary doc)도, 액세스 정책 (access policy)도, "이것들은 호출할 수 있는 시스템이고, 이것들은 확인 없이 건드려서는 안 되는 시스템이다"라는 명시적인 규칙도 없었습니다. 저는 주방을 만들고 불을 켰을 뿐입니다. 맛 평가단 (brigade de goût)은 제가 아직 미처 신경 쓰지 못한 의도에 불과했습니다. 😅

그 후 세 가지가 바뀌었습니다.

첫 번째 프로덕션 실행 전 경계 매핑 (Mapping the perimeter). 이는 설정 파일 (config file)의 문제가 아니라 결정의 문제입니다. 이제 파이프라인이 건드리는 각 외부 시스템에 대해 액세스 수준 (읽기 또는 쓰기), 기본 엔드포인트 (별도로 명시되지 않는 한 샌드박스 (sandbox)), 그리고 실행 전 확인이 필요한 작업인지 여부를 문서화합니다. 이 문서는 사후 고려 사항이 아니라 프로젝트 설정의 일부입니다. 이는 20분밖에 걸리지 않습니다. 의도치 않은 지원 티켓의 폭주와 부분적인 주문 데이터 유출을 되돌리는 데는 20분이 걸리지 않았습니다.

프로덕션 자격 증명(Production credentials)이 부여되기 전에 외부 효과를 수동으로 테스트하기입니다. 내부 로직(출력값)이 아니라, 실제 API 호출, 데이터 쓰기, 외부 요청 등 코드베이스 외부로 도달하는 모든 것을 의미합니다. 에이전트가 라이브 시스템에 접근하기 전에, 파이프라인을 격리된 상태로 실행하여 무엇을 건드리는지 관찰하십시오. 누군가 설명할 때는 매번 당연하게 들리지만, 배포를 서두르는 순간 더 이상 당연하게 느껴지지 않는 단계입니다.

에이전트가 가진 모든 기능에 대해 단 한 가지 질문을 던지십시오: "이것이 잘못되었을 때 내가 알 수 있는가?" 만약 스택(Stack) 내의 어떤 요소도 경계 위반(Boundary violation)에 대해 경고를 보내지 않는다면, 해당 에이전트는 감독 없이 그 기능을 가질 수 없습니다. 바로 이 지점에서 출시 전 프롬프트 계약(Prompt contracts)을 통해 에이전트 범위를 정의하는 것이 실제로 그 비용만큼의 가치를 발휘합니다. 첫 실행 전에 작성된 명세서(Spec)는 당신의 '부레 드 구토(Brigade de goût, 맛의 감별단)' 역할을 합니다. Vibe Coding, For Real 블루프린트는 이를 초기 단계로 구축합니다(에이전트가 라이브 자격 증명에 접근하기 전에 경계(Perimeter)를 정의하는 것, 특히 바로 그 순간이 대화가 이루어져야 하는 시점이기 때문입니다).

이 모든 것이 보편적인 체크리스트는 아닙니다. 이것은 파이프라인이 잘못된 주소로 데이터를 전달한 사건 이후에 바뀐 것들입니다.