스스로 작동하는 공장을 만든다면, 결과물이 덜 신뢰할 수 있게 되는 것이 아니라 더 신뢰할 수 있게 될 것이라고 기대할 것입니다. 하지만 소프트웨어 팩토리(Software factories)에서는 정반대의 일이 계속해서 발생하고 있습니다. 생산 라인이 더 빠르고 자율적(Autonomous)이 될수록, 실수는 더욱 처참해집니다. 왜냐하면 모호한 목표를 향해 빠르게 달리는 라인은 단지 잘못된 것을 대규모로 생산할 뿐이기 때문입니다.

그 이유는 별로 매력적이지 않습니다. 모든 소프트웨어 팩토리는 요구사항(Requirement)을 배포된 코드(Shipped code)로 전환하는 현장(Floor)을 자동화합니다. 대부분의 팀은 이 처리량(Throughput)을 최적화하며, 이는 제대로 구축할 가치가 있는 부분입니다. 하지만 더 빠른 라인이 더 신뢰할 수 있는 라인과 동일한 것은 아닙. 거의 어떤 팀도 모호한 아이디어를 정밀한 요구사항으로 전환하는 현장을 자동화하지 않습니다. 대부분의 설정에서 이 두 번째 현장은 거의 존재하지 않으며, 이 현장이 바로 하류(Downstream)의 모든 자율성이 당신을 돕게 될지, 아니면 조용히 당신에게 해가 되게 할지를 결정하는 곳입니다.

이를 기획 단계(Planning floor)라고 부릅시다. 이것은 아무도 구축하지 않는 공장의 부분이며, 동시에 가장 중요한 부분입니다.

잘못된 끝단부터 자동화된 공장

현재 이 용어가 어떻게 사용되고 있는지를 살펴보면, 그 격차가 실시간으로 형성되는 것을 목격할 수 있습니다. Factory.ai는 신호를 분류(Triage)하고, 계획하고, 코딩하고, 리뷰하고, 테스트하고, 배포하고, 모니터링하는 자율 드로이드(Autonomous Droids)를 내세우며 Factory 2.0을 막 출시했습니다. Chamath는 8090의 소프트웨어 팩토리를 설명하며, 어려운 부분이 어디에 있는지에 대해 이례적으로 솔직하게 말했습니다.

우리는 먼저 요구사항 작성을 돕고, 의존성(Dependencies)을 확장 및 프레임화(Frame)한 다음, 문제에 대한 더 글로벌한 지식을 바탕으로 실행합니다.

그 순서를 다시 읽어보십시오. 요구사항이 먼저이고, 의존성이 프레임화된 다음, 실행합니다. 실행은 자동화하기 쉬운 절반이며, 모두가 데모하는 부분입니다. 요구사항 정의와 프레임화 단계가 바로 기획 단계(Planning floor)이며, 문제에 대한 글로벌한 지식이 올바른지, 아니면 자신 있게 틀렸는지를 실제로 결정하는 부분입니다.

Simon Willison의 모델 조사 (survey of the model)는 대부분의 팀이 올라가는 자동화의 사다리를 제시합니다. AI가 영광스러운 자동 완성(autocomplete) 역할을 하는 '보조(assisted)' 단계, 에이전트(agent)가 주도하고 인간이 예외 상황을 관리하는 '감독(supervised)' 단계, 그리고 명세(specs)와 시나리오(scenarios)가 인간의 검토 없이 수렴하는 에이전트를 구동하는 '자율(autonomous)' 단계가 그것입니다. 사다리의 꼭대기가 명세와 시나리오에 의해 정의된다는 점에 주목하십시오. 자율화라는 꿈 전체는 입력값의 품질에 달려 있습니다. 좋은 입력을 만들어내는 바닥(floor)을 구축하지 않은 채 사다리를 올라간다면, 당신은 잘못된 명세에서 출시된 실수로 가는 여정을 자동화할 뿐입니다.

가설: 입력 품질이 새로운 병목 구간이다

이 글의 나머지 부분이 근거하고 있는 주장은 다음과 같습니다. 소프트웨어 팩토리가 더 자율적으로 변할수록, 출력 품질은 생산 라인에 들어가는 것의 품질에 의해 제한되며, 그 진입점을 지켜보는 사람은 점점 줄어듭니다. 실행 단계에서의 속도는 이 제약을 완화하지 않습니다. 오히려 이 제약을 더욱 조입니다. 왜냐하면 더 빠른 라인은 목표가 잘못되었다는 것을 누군가 알아차리기 전에, 당신의 모호한 요구사항을 더 빠르고 더 많은 곳에서 소진해 버리기 때문입니다.

이것은 AI가 나쁜 코드를 작성한다는 익숙한 불평이 아닙니다. 모델들은 놀라울 정도이며 매달 더 좋아지고 있습니다. 바로 그 점 때문에 병목 구간이 이동한 것입니다. 생성(generation)이 귀했던 시절에는 출력 과정에서 인간이 모든 줄을 검토하고 흐름을 파악했기에 프롬프트(prompt)의 품질이 다소 떨어져도 용납될 수 있었습니다. 하지만 생성이 사실상 무료가 되고 검토(review) 단계마저 자동화하여 없애버리는 상황에서는, 정확성을 주입할 수 있는 유일한 지점은 에이전트가 실행되기 전뿐입니다. 계획(plan)은 더 이상 단순한 서류 작업이 아닙니다. 그것은 하중을 견디는 핵심 입력값(load-bearing input)이 됩니다.

기획 단계(Planning floor)에 존재하는 것들

기획 단계(Planning floor)는 좋은 의도만 가득한 Notion 문서가 아닙니다. 여기에는 기계 장치(machinery)가 있으며, 이 장치는 실행 계층(execution layer)이 스스로 할 수 없는 세 가지 일을 수행합니다.

이는 누군가 구축하기 전에 아이디어를 질문합니다. 진정한 기획 단계(Planning Floor)는 여러분이 답변할 것이라고 생각지 못한 질문들을 던집니다. 예를 들어, 인증되지 않은 사용자에게 무슨 일이 발생하는지, 취소된 결제가 플랜에 어떤 영향을 미치는지, 어떤 엣지 케이스(edge cases)가 범위 내에 있는지 등을 물어봅니다. 핵심은 알 수 없는 것들(unknowns)을 대화 비용으로 표면화하는 것이지, 재작성 비용으로 표면화하는 것이 아닙니다. 여러분이 높은 수준의 설명을 제공하면 시스템이 그것을 구축 가능한 무언가로 변환할 질문들을 던집니다.

이는 수용 기준(acceptance criteria)이라는 라인에 체크할 수 있게 작성하는 것입니다. 이것이

BrainGrid가 구축하고자 하는 지점이 바로 이곳입니다. Planning Agent는 아이디어를 명시적인 수락 기준 (Acceptance Criteria)을 갖춘 요구사항으로 변환하며, 모호한 의도에 이의를 제기하고 코드가 작성되기 전에 명확한 질문을 던집니다. 그다음 Builder Agent가 해당 명세 (Spec)에 따라 실행을 수행하는데, 이는 라이브 미리보기가 포함된 관리형 클라우드 샌드박스(Sandbox) 내에서 이루어지거나, MCP를 통해 Claude Code, Cursor 또는 Codex를 사용하여 사용자의 GitHub 리포지토리에서 직접 수행되므로 하단의 하네스 (Harness)를 교체 가능한 상태로 유지할 수 있습니다. 그런 다음 실행 우선형 팩토리들이 건너뛰는 단계가 이어집니다. 모든 기준이 증거와 함께 충족될 때까지 기능은 완료된 것이 아닙니다. 계획하고, 구축하고, 검증하고, 반복하십시오. 계획은 검증기 (Verifier)가 대조하여 확인하는 대상이며, 이것이 검증이 가능하게 만드는 근본적인 이유입니다. 계획이 없다면 검증할 수 없습니다.

이것이 월요일의 당신에게 바꾸어 놓을 것

만약 당신이 현재 팩토리와 유사한 어떤 것에 코딩 에이전트 (Coding Agent)를 연결하고 있다면, 실질적인 영향은 구체적입니다. 당신의 본능은 실행 계층 (Execution Layer)에 노력을 쏟아부어, 최적의 하네스를 선택하고, 에이전트 루프 (Agent Loop)를 튜닝하며, 라인에서 더 많은 속도를 짜내는 것입니다. 하지만 그러한 노력은 수익 체감의 법칙이 급격하게 적용됩니다. 왜냐냐하면 이번 달에 튜닝한 하네스는 다음 달이면 구식이 될 것이고, 당신이 얻은 속도는 당신이 지정한 무엇이든 만들어내는 속도일 뿐이기 때문입니다.

진정한 수익은 상류 (Upstream)에 있습니다. 요구사항을 정밀하게 만들고, 의존성을 프레이밍하며, "완료"가 무엇을 의미하는지 기록하는 데 쓰는 한 시간은, 다음 50개의 자동화된 단계가 올바른 방향으로 수렴할지를 결정하는 시간입니다. 수동 팀에서는 그 한 시간이 선택 사항이었을 것입니다. 루프 안에 있는 인간 (Human in the loop)이 지속적으로 편차를 수정했기 때문입니다. 하지만 자율적인 라인에는 지속적인 인간의 수정이 없으므로, 수정은 계획 단계에 미리 반영되어야 합니다. 기획 단계 (Planning Floor)를 먼저 구축하십시오. 그러면 그 위의 팩토리는 신뢰할 수 있게 됩니다. 이를 건너뛴다면, 당신은 아주 빠르게 틀린 결과를 만들어내는 방법을 구축한 셈이 됩니다.

솔직한 트레이드오프 (Trade-off)

기획 단계 (Planning Floor)를 두는 데는 모든 기능 개발의 첫 한 시간이 소요되며, 에이전트(Agent)가 바로 옆에서 생성할 준비를 마친 상태에서는 그 한 시간이 마찰 (Friction)처럼 느껴질 수 있습니다. 한 번 쓰고 버릴 프로토타입 (Prototype)이라면 그것은 마찰이며, 건너뛰어도 좋습니다. 사용자도, 결제도, 당신의 이름도 붙지 않을 것이라면, 목표를 느슨하게 잡고 그냥 실행하십시오. 소프트웨어 팩토리 (Software Factory)의 순수 속도 모드 (Pure-speed mode)가 그 상황에서는 진정으로 올바른 선택입니다.

하지만 그 대상이 실체가 되는 순간, 계산법은 반전됩니다. 누군가가 의존하는 그 어떤 것이라도 존재하지 않는 기획 단계를 감당할 수 없습니다. 왜냐하면 기획 단계를 건너뛰어 아낀 시간은, 자율적인 라인 (Autonomous line)이 당신이 읽지도 않은 20개의 파일에 걸쳐 확신에 차 있고 그럴듯하지만 틀린 구현 (Implementation)을 처음으로 배포하는 순간 이자를 붙여 되돌아오기 때문입니다. 리스크 (Stakes)에 맞춰 엄격함 (Rigor)을 조절하십시오. 데모를 위한 것이라면 기획 단계는 필요 없습니다. 제품을 위한 것이라면, 기획 단계가 하중을 견디는 핵심 부분 (Load-bearing part)입니다.

회의론자들의 주장도 진지하게 고려할 가치가 있습니다. 최근 The Register는 루프 엔지니어링 (Loop engineering)을 "최신 AI 유행어"라고 불렀으며, 이 문제를 실제로 종결짓는 Addy Osmani의 말을 인용했습니다:

루프는 업무를 변화시키지만, 당신을 업무에서 삭제하지는 않습니다.

이것은 정확히 맞으며, 이것이 바로 기획 단계가 필요한 전체 논거입니다. 자동화 (Automation)가 인간을 제거한 것이 아닙니다. 자동화는 인간의 업무를 줄의 맨 앞, 즉 의도 (Intent)가 정교해지는 단계로 옮겨 놓았습니다. 팩토리는 라인을 가동할 수 있습니다. 하지만 무엇이 라인에서 나와야 할지는 결정할 수 없습니다. 그 결정은 당신의 몫이며, 기획 단계는 바로 당신이 그 결정을 내리는 곳입니다.

라인을 원하는 만큼 자동화하십시오. 다만 무엇을 만들지 라인에 알려주는 기획 단계를 구축하십시오.

FAQ

소프트웨어 팩토리 (Software factory)란 무엇인가요?

소프트웨어 팩토리 (Software factory)는 소프트웨어를 생산하기 위한 구조화되고 반복 가능한 접근 방식입니다. 즉, 표준화된 파이프라인 (pipelines), 재사용 가능한 컴포넌트 (reusable components), 그리고 매 사이클마다 수동 작업의 노력을 줄이면서 요구사항을 배포 가능한 코드 (shipped code)로 전환하는 자동화 (automation)를 의미합니다. 이 비유는 개발을 단순히 개별 제품을 만드는 과정이 아니라, 프로세스 자체가 설계된 조립 라인 (assembly line)으로 정의합니다. 이 개념은 AI가 등장하기 수십 년 전부터 존재해 왔으나, 최근 팀들이 코딩 에이전트 (coding agents)를 라인에 연결하여 인간이 아닌 에이전트가 작성, 리뷰, 테스트의 대부분을 수행하게 되면서 다시금 급부상하고 있습니다.

자율형 소프트웨어 팩토리에서 입력 품질이 왜 더 중요한가요?

기존에 실수를 잡아내던 인간의 리뷰 (human review) 단계가 자율화(autonomy) 과정에서 제거되기 때문입니다. 수동으로 운영되는 팀에서는 사람이 출고 과정에서 각 변경 사항을 검토하고 지속적으로 편차 (drift)를 수정하므로, 모호한 요구사항이라도 후속 단계에서 수정될 수 있습니다. 하지만 자율형 라인에는 지속적인 인간의 수정이 없으므로, 정확성을 주입할 수 있는 유일한 지점은 에이전트가 실행되기 전뿐입니다. 이로 인해 계획 (plan)의 정밀도가 출력 품질을 결정짓는 구속 조건 (binding constraint)이 됩니다. 라인이 빨라진다는 것은 단지 모호한 요구사항을 더 빠르게 소모한다는 의미일 뿐입니다.

소프트웨어 팩토리에서 계획 (planning)과 실행 (execution)의 차이는 무엇인가요?

실행 (Execution)은 대부분의 팩토리가 자동화하는 부분으로, 작성된 요구사항을 배포되고 테스트된 코드로 전환하는 과정입니다. 계획 (Planning)은 모호한 아이디어를 프레임화된 의존성 (dependencies)과 명시적인 수락 기준 (acceptance criteria)을 갖춘 정밀한 요구사항으로 전환하는 과정입니다. 실행은 비교적 쉽게 자동화될 수 있으며 대부분의 데모가 보여주는 것이기도 합니다. 계획은 실행이 올바른 목표를 향하고 있는지를 결정하며, 이는 대부분의 팩토리가 구축하지 못하는 기반 (floor)입니다.

AI 에이전트를 사용하여 소프트웨어를 구축하는 단계는 무엇인가요?

신뢰할 수 있는 루프(loop)에는 네 가지 단계가 있습니다: 의도(intent)가 수락 기준(acceptance criteria)을 포함한 요구사항이 되는 계획(plan) 단계, 에이전트가 해당 명세(spec)에 따라 구현하는 구축(build) 단계, 결과물이 증거와 함께 각 기준에 부합하는지 확인하는 검증(verify) 단계, 그리고 학습 및 검증된 내용이 제품 기록에 축적되어 다음 기능이 더 앞선 상태에서 시작될 수 있도록 하는 반복(repeat) 단계입니다. 계획 단계는 팀들이 투자를 소홀히 하는 단계이며, 그 이후의 모든 품질을 결정짓는 단계입니다.

기획 단계(planning floor)를 구축하는 것이 속도를 늦추나요?

각 기능의 시작 단계에서는 그렇습니다. 에이전트가 실행되기 전에 수락 기준(acceptance criteria)을 작성하고 의존성(dependencies)을 설정하는 것은, 생성(generation)이 즉각적으로 이루어지는 상황에서 오버헤드(overhead)처럼 느껴지는 한 시간을 소모하게 합니다. 한 번 쓰고 버릴 프로토타입(prototype)이라면 이는 오버헤드이며 건너뛰어도 좋습니다. 하지만 실제적인 무엇인가를 만든다면, 그 한 시간은 자율적인 라인(autonomous line)이 잘못된 구현으로 자신 있게 수렴하는 것을 막아주는 역할을 하며, 읽어본 적도 없는 20개의 파일을 디버깅해야 했을 상황을 방지함으로써 그 가치를 즉시 보상받게 됩니다.

만약 당신이 실제적인 무언가를 구축하고 있으며, 에이전트가 타격할 수 있고 당신이 검증할 수 있는 목표를 향해 라인을 맞추고 싶다면, 프롬프트 대신 계획부터 시작하세요.

BrainGrid는 에이전트가 실행되기 전에 의도를 정밀하게 만들고, 설정한 기준에 따라 모든 기능을 증명하는 계획 우선(plan-first) 앱 구축 플랫폼입니다. braingrid.ai에서 체험해 보세요.

원문은 BrainGrid 블로그에 게시되었습니다.