소프트웨어 팩토리를 실제로 만드는 세 가지 원칙

URL: https://www.youtube.com/watch?v=cHsunDt0QUc 날짜: 2026-09-30 채널: Tech Bridge 원문 제목: [한영자막] 진짜 '소프트웨어 팩토리'를 만들려면 무엇이 필요할까요? — Factory Tereza 발표자: Tereza Tížková, Factory 발표 길이: 약 22분 49초 원문 자막: YouTube 멤버십 전용 제한으로 직접 추출할 수 없어, 동일 발표의 공개 전체 전사(532개 구간)를 대조해 번역·정리함

---

📌 핵심 질문 / 핵심 논점

==소프트웨어 팩토리는 코드를 만들어 주는 에이전트 여러 개가 아니라, 신호 수집부터 우선순위 결정·실행·검증·프로덕션 테스트·학습까지 소프트웨어 생명주기 전체를 자율적으로 순환시키는 조직형 시스템이다.==

• 무엇을 만들지 정하는 신호는 사용자 피드백과 로그에서 수집하고, 중요한 일을 우선순위화해야 한다.
• 모델·도구·기존 업무 방식에 종속되지 않으면서도 에이전트에게 충분한 권한과 거버넌스를 제공해야 한다.
• 완료 조건을 실제 결과로 검증하고, 작업을 만든 에이전트와 독립된 검증자가 코드와 사용자 경험을 모두 확인해야 한다.
• 코드베이스의 재현성·테스트·문서·관례를 정리하고, 팀의 암묵지를 재사용 가능한 스킬과 컨텍스트로 바꿔야 한다.
• 사람은 구현 방법보다 만들 가치가 있는 것을 결정하고, 에이전트 팀의 방향과 결과를 감독하는 쪽으로 올라가야 한다.

소프트웨어 팩토리를 도입할지, 직접 만들지 외주화할지, 이미 프로덕션에서 무엇이 작동하는지, 주요 난제와 비용이 무엇인지가 전체 질문이다. Factory가 EY와 Adobe 같은 엔터프라이즈에서 구축해 온 경험은 답을 모델 독립성, 자율 실행, 지속적 개선이라는 세 원칙으로 압축한다.

1. 소프트웨어 팩토리의 정의와 등장 배경

코드 생성은 소프트웨어를 전달하는 과정 중 상대적으로 쉬운 부분이며, 팩토리는 그 전후의 모든 일을 연결해야 한다.

1.1. 시작 질문과 Factory의 현장

1. 발표의 출발점

   1. Tereza Tížková는 가볍게 “안녕하세요, 잘 지내시죠?”라고 인사한 뒤 소프트웨어 팩토리를 이야기하겠다고 밝혔다.
   2. 모두가 소프트웨어 팩토리를 말하지만 실제로 만드는 사람은 적고, 무엇이 필요한지와 어떻게 정의해야 하는지 아는 사람은 더 적다고 지적했다.
   3. 핵심 질문은 직접 만들지 외주화할지, 이미 프로덕션에서 작동하는 것은 무엇인지, 주된 난제는 무엇인지, 비용이 얼마나 들지였다.

2. Factory의 위치

   1. Tížková는 Factory.com에서 일하며 오랫동안 소프트웨어 팩토리 개념을 만들어 왔다고 소개했다.
   2. 기술이 마침내 따라오면서 EY와 Adobe 같은 엔터프라이즈에서도 프로덕션용 시스템을 만들 수 있게 됐다고 말했다.
   3. 화면에 보이는 Factory 대시보드는 신호부터 반복 개선까지 이어지는 전체 사이클을 한눈에 보여 주는 운영 화면이다.

1.2. 팩토리가 자동화해야 하는 전체 생명주기

1. 자율적 개발의 범위

   1. 소프트웨어 팩토리는 자율성을 가진 소프트웨어 개발의 전체 루프다.
   2. 사용자 피드백과 로그에서 신호를 모은다.
   3. 중요한 일을 우선순위화한다.
   4. 우선순위에 따라 작업을 오케스트레이션한다.
   5. 구현하고 검증한다.
   6. 프로덕션에서 실제로 잘 작동하는지 테스트한다.
   7. 얻은 결과와 지식을 다음 반복에 반영하고 새로운 스킬을 축적한다.

2. 왜 지금 가능한가

   1. 2023년 무렵부터 AI에 연속 루프라는 발상이 널리 등장했다.
   2. ChatGPT의 초기 활용, AutoGPT, BabyAGI 같은 시도가 소프트웨어를 계속 반복하는 개념을 이미 제시했다.
   3. 당시에는 LLM이 환각을 일으키고, 컨텍스트 길이가 부족하고, 추론 품질이 낮고, 에이전트가 격리된 환경에서 일할 좋은 실행 공간도 부족했다.
   4. 모델의 추론·컨텍스트·실행 환경이 개선되면서 연속 루프가 실제로 유용한 소프트웨어 팩토리 패러다임으로 발전했다.

1.3. 소프트웨어 팩토리가 아닌 것

1. 코딩 에이전트와 에이전트 군집의 한계

   1. 코딩 에이전트 하나만으로는 소프트웨어 팩토리가 아니다.
   2. 수천 개의 코딩 에이전트를 군집으로 늘려도 소프트웨어 팩토리가 완성되지 않는다.
   3. 코드를 쓰는 일보다 우선순위 결정, 조정, 검증, 프로덕션 운영이 훨씬 어렵다.
   4. 실제 엔지니어도 업무 시간 대부분을 코드 타이핑에 쓰지 않고, 요구사항 정렬·조사·테스트·배포·협업에 쓴다.

2. 컨설팅 프로젝트 하나로 해결되지 않는 이유

   1. 팩토리는 조직 중간에 컨설팅 전략이나 추상적인 청사진을 던져 넣는 프로젝트가 아니다.
   2. 기존 조직을 처음부터 소프트웨어 팩토리를 운영할 수 있도록 다시 설계해야 한다.
   3. 에이전트가 테스트·검증·반복을 동시에 수행하면 쉽게 큰 혼란이 생기므로, 사람 팀을 설계하듯 역할과 경계를 세워야 한다.

2. 세 가지 설계 원칙: 모델·업무 독립성, 자율성, 지속적 개선

많은 에이전트가 오랫동안 일하는 조직에서는 기술 선택보다 역할·권한·공유 지식·판정 체계가 먼저 정리돼야 한다.

2.1. 원칙 1 — 기존 환경과 모델에 종속되지 않기

1. 기존 업무 흐름을 수용하는 팩토리

   1. 소프트웨어 팩토리를 만드는 사람은 조직이 이미 일하는 방식을 존중해야 한다.
   2. Slack, GitHub 등 기존 환경과 연결돼야 한다.
   3. 구성원이 이미 구독하는 서비스와 모델을 가져와 사용할 수 있어야 한다.
   4. 새로운 프런티어 모델과 벤치마크가 계속 등장하고 승자를 미리 예측하기 어렵기 때문에 특정 선택에 시스템 전체를 묶으면 안 된다.

2. 조직에 맞는 모델 독립성

   1. 모델 선택뿐 아니라 조직의 기존 업무 방식에서도 독립성을 유지해야 한다.
   2. 마케팅·영업·엔지니어링처럼 역할에 따라 권한과 기본 모델을 다르게 설정할 수 있어야 한다.
   3. 변화가 빠른 모델 시장에서는 특정 LLM을 영구적인 기본값으로 삼는 것보다 교체 가능한 라우팅 계층을 갖추는 편이 안전하다.

2.2. Coinbase 사례와 비용 구조

1. 토큰 사용량과 비용의 분리

   1. Coinbase CEO가 공유한 차트에서는 토큰 사용량을 나타내는 검은 선이 계속 올라갔지만 AI 비용은 내려갔다.
   2. 토큰을 덜 쓰는 방식이 아니라 같은 토큰을 더 경제적으로 쓰는 방식으로 절약했다.

2. 절약을 만든 네 가지 조치

   1. 모든 작업의 기본값을 프런티어 모델로 두지 않고 사람과 역할에 따라 더 적합한 기본 모델을 설정했다.
   2. 이미 처리한 컨텍스트를 캐시해 매번 같은 내용을 다시 프리필하지 않았다.
   3. 지출 상한으로 사용량을 억누르기보다 큰 비용이 발생했을 때 실제 결과가 나왔는지 확인했다.
   4. 작업에 필요한 능력에 맞춰 LLM 사이를 라우팅하고 토큰을 최적화했다.

2.3. Factory의 자동 모델 라우팅

1. 라우팅의 기본 동작

   1. 시스템이 작업에 가장 적합한 모델을 먼저 선택한다.
   2. 선택한 모델이 작업에 실패하거나 제공자 장애가 발생하면 다른 모델로 전환한다.
   3. 라우팅은 비용만 줄이지 않고 신뢰성과 속도도 높인다.
   4. 오픈 모델이 더 빠른 경우가 있고, 한 LLM 제공자가 장애를 일으켜도 다른 제공자로 자동 전환할 수 있다.
   5. Factory의 보수적인 벤치마크에서는 약 25% 절감이 나타났으며, Tížková는 실제 절감 폭이 더 클 가능성도 언급했다.

2. 분류 후 최저가 모델 선택

   1. 사용자는 작업을 할당하고, 조직은 역할별 권한과 기본 모델을 미리 정한다.
   2. 분류기는 프롬프트 구조, 코드베이스, 작업 난도, 사용할 도구를 살핀다.
   3. 분류 결과로 작업을 끝내는 데 필요한 능력의 임계값을 정한다.
   4. 그 임계값을 넘을 것으로 예측되는 모델 중 가장 저렴한 모델을 선택한다.
   5. 판단 기준은 “가장 강력한 모델이 무엇인가”가 아니라 “이 특정 작업을 끝낼 수 있는 가장 저렴한 모델이 무엇인가”다.

3. 라우팅의 어려운 질문

   1. 처음 분류를 잘못하면 값싼 모델에서 시작했다가 반복 실패와 재작업으로 더 비싸질 수 있다.
   2. 따라서 모델을 너무 자주 바꾸지 않을 정도로 분류 품질을 높이는 일이 핵심이다.
   3. 중간에 더 어려운 모델로 승급하더라도 전체 작업은 오히려 빨라질 가능성이 있지만, 모든 작업에 보장되는 측정 결과로 제시되지는 않았다.
   4. 캐싱으로 생긴 비용 절감분을 사용자에게 얼마나 돌려줄지는 기술 문제가 아니라 가격 정책과 API 제공자와의 계약 문제다.
   5. 오픈 모델도 전용 컴퓨트에 호스팅하면 프리필 캐싱의 이점을 누릴 수 있다.

3. 자율성의 핵심: 루프가 언제 끝났는지 검증하기

에이전트가 오래 실행되는 사실만으로는 신뢰할 수 있는 자동화가 되지 않는다. 실제 결과에 맞는 완료 조건을 쓰고, 그 조건이 의도한 결과를 측정하는지 확인해야 한다.

3.1. 에이전트 루프와 Ralph식 작업 분해

1. 루프 자체는 새롭지 않다

   1. 루프는 여러 맥락에서 오래전부터 존재했고, 이제 에이전트의 실행 단위로 확장되고 있다.
   2. Ralph loop처럼 작업을 명세하고 하위 작업으로 나눠 에이전트에게 맡기는 방식이 널리 알려졌다.
   3. 어려운 질문은 루프를 어떻게 만들지가 아니라 루프에서 “완료”를 무엇으로 정의할지다.

2. 3D 프린터 로고 사례

   1. Tížková의 동료는 Factory 로고를 3D 프린터로 만드는 에이전트 루프를 만들었다.
   2. 전통적인 프로그래밍 루프는 종료 조건이 명확하지만, 물리적 결과를 포함하는 열린 세계의 작업은 비결정적이다.
   3. 로고 파일을 생성했는지, 실제로 출력됐는지, 출력물이 의도한 모양인지까지 확인해야 하므로 “루프가 끝났다”를 정의하기 어렵다.

3.2. 잘못된 테스트가 만드는 에이전트의 치팅

1. 실행 시간과 신뢰성은 다르다

   1. 에이전트가 자율적으로 처리할 수 있는 작업의 길이는 계속 늘고 있다.
   2. 에이전트가 오래 실행된다는 사실은 프로덕션 신뢰성을 증명하지 않는다.
   3. 여전히 반복 실행과 사람 또는 다른 에이전트의 피드백이 필요하다.

2. 완료 조건의 허점

   1. 완료 기준을 잘못 쓰면 에이전트는 사용자가 원한 결과가 아니라 테스트 통과만 최적화한다.
   2. 코드가 테스트를 통과해도 실제 기능을 수행하지 않는다면 에이전트가 목적을 달성한 것이 아니다.
   3. Tížková는 테스트의 조건과 사용자가 실제로 필요한 결과 사이의 틈을 에이전트의 “치팅”이라고 불렀다.
   4. 따라서 완료 조건은 구현 방법이 아니라 검증 가능한 의도된 결과를 명시해야 한다.

4. Factory Missions: 구현과 판정을 분리하는 장기 실행 구조

Factory Mission은 오케스트레이터가 목적과 검증 계약을 쓰고, 순차적인 워커가 구현하며, 독립 검증자가 결과를 되돌려 보내는 장기 실행 루프다.

4.1. 오케스트레이터·워커·검증자

1. 역할 분리

   1. 오케스트레이터는 해야 할 일을 결정하고 완료 조건을 작성한다.
   2. 워커 에이전트는 할당받은 작업을 구현한다.
   3. 검증자는 결과를 평가하고 피드백을 루프의 시작점으로 보낸다.
   4. Mission은 몇 주 동안 실행될 수 있으며, 실제 고객 사례 하나는 16시간 동안 실행됐다.
   5. 그 16시간 작업에서 검증이 전체 과정의 40%를 차지했다.

2. 순차 실행과 내부 병렬성

   1. 주된 워커들은 군집처럼 모두 동시에 일하지 않고 순서대로 일한다.
   2. 각 워커가 한 가지 결과를 완성해 다음 워커에게 넘긴다.
   3. 다음 워커는 앞 워커의 오래된 추론에 갇히지 않고 새로운 컨텍스트와 “새로운 머리”로 작업을 이어 간다.
   4. 인간 동료가 작성한 코드를 다른 동료가 새 관점에서 검토하는 방식과 비슷하다.
   5. 각 워커 내부에서는 하위 에이전트를 병렬로 실행할 수 있다.
   6. 하위 에이전트가 웹을 조사하거나 파일을 만드는 동안 주 워커는 자신의 순차 단계에 집중한다.

4.2. 검증 계약과 두 종류의 검증자

1. 검증 계약

   1. 오케스트레이터가 코드 작성 전에 검증 계약을 쓴다.
   2. 검증자는 코드를 만든 에이전트가 아니라 다른 에이전트의 결과를 판정한다.
   3. 요구사항, 구현, 완료 판정을 분리하면 작성자가 자기 결과를 무비판적으로 통과시키는 문제를 줄일 수 있다.

2. Scrutiny validator — 코드베이스 정밀 검증자

   1. 린터(linter), 타입 검사, 테스트를 통해 코드베이스를 엄격하게 확인한다.
   2. 코드가 구조적으로 건전한지와 자동화된 품질 기준을 충족하는지를 본다.

3. User-testing validator — 사용자 테스트 검증자

   1. 가상 컴퓨터를 직접 조작하며 애플리케이션을 클릭한다.
   2. 코드가 어떻게 만들어졌는지는 신경 쓰지 않고 실제 동작이 되는지만 확인한다.
   3. 코드가 그럴듯해 보이는 것과 사용자가 실제로 기능을 사용할 수 있는 것을 분리한다.

4.3. 마이그레이션에서 드러난 “더미 결과” 문제

1. 겉보기와 상호작용의 차이

   1. 한 엔지니어가 Factory의 Droid 에이전트로 코드베이스를 마이그레이션했다.
   2. 다른 제품들은 애플리케이션처럼 보이는 결과물을 생성했지만 클릭할 수 없고 실제로 작동하지 않는 더미 결과를 만들었다.
   3. 마이그레이션 마지막에 에이전트가 가상 컴퓨터에서 화면을 실제로 클릭해야만 결과가 기능하는지 확인할 수 있었다.
   4. 코드만 읽을 때는 보이지 않던 인터랙션 실패가 사용자 테스트에서 드러났다.

2. 컴퓨터 사용과 지속형 환경

   1. 컴퓨터 사용 능력과 에이전트용 영속 가상 머신이 발전하면서 에이전트가 실제 실행 공간에 들어가 검증할 수 있게 됐다.
   2. Mission은 큰 루프 안에 작은 루프가 겹친 구조다.
   3. 각 에이전트는 자기 작업을 반복하고, 전체 Mission은 구현과 검증 사이를 반복한다.
   4. Tížková는 “루프 안에 더 작은 루프가 있는” 모양이 조금 이상하게 보일 수 있지만 마음에 든다고 농담하듯 말했다.

5. 지속적 개선: 컨텍스트·코드베이스·팀 지식

오랫동안 실행되는 Mission일수록 무엇을 컨텍스트에 넣고 무엇을 나중으로 미룰지, 에이전트가 물려받는 코드베이스와 조직 지식을 어떻게 정리할지가 중요하다.

5.1. 엔터프라이즈 컨텍스트 폭발

1. 도구가 많아질수록 생기는 문제

   1. 엔터프라이즈는 Figma, Notion, Gmail, Drive, Slack을 비롯해 평균적으로 수백 개의 도구를 사용한다.
   2. 각 도구에는 스키마, 파라미터, 사용 설명이 있고, 이를 모두 컨텍스트에 넣으면 긴 Mission의 컨텍스트가 부풀어 오른다.
   3. 이름이 비슷한 도구가 있으면 에이전트가 잘못된 도구를 고를 수 있다.
   4. 컨텍스트 창이 꽉 차면 압축이 일어나며, 중요한 정보가 사라지거나 흐려질 수 있다.

2. Deferred context engine

   1. Factory는 처음부터 모든 도구의 전체 명세를 넣지 않고 짧은 도구 목록과 짧은 설명만 제공한다.
   2. 작업이 특정 도구를 실제로 필요로 할 때 해당 도구의 전체 정보를 불러온다.
   3. 사용하지 않는 정보는 삭제되지 않고, 필요할 때까지 활성 컨텍스트 밖에 숨겨진다.
   4. 이 점진적 공개 방식은 에이전트가 필요한 도구를 발견한 뒤에만 세부 명세를 읽게 한다.
   5. 도구 수가 늘어날수록 토큰 절약 효과가 커지며, Tížková는 50% 이상 절약할 수 있다고 말했다.

5.2. AI 도입의 파워 법칙과 Agent Readiness

1. 준비된 조직과 준비되지 않은 조직의 격차

   1. AI 도입은 파워 법칙처럼 크게 성공하거나 크게 실패할 수 있다.
   2. 코드베이스가 구조화되지 않고 필요한 정보가 없으면 소프트웨어 팩토리가 생산성을 높이기보다 코드를 더 나쁘게 만들 수 있다.
   3. AI를 단순히 도입한 조직과 도입 조건을 깊이 고민한 조직 사이의 생산성 격차가 점점 커진다.
   4. Tížková는 Stanford의 자료를 언급하며 구조화·준비·문서화가 부족하면 AI가 코드를 악화시킬 수 있다고 말했다.
   5. 엔지니어라면 AI가 때때로 코드를 엉망으로 만들고, 그 문제가 반복되며 누적돼 되돌리기 어려워지는 경험에 공감할 수 있다고 덧붙였다.

2. Agent Readiness는 코드베이스 위생 점검

   1. Factory는 이를 거창한 프레임워크라 부르는 것을 좋아하지 않지만, Agent Readiness라는 코드베이스 위생 점검을 운영한다.
   2. 개발 환경을 같은 방식으로 재현할 수 있는지 확인한다.
   3. 유용한 테스트와 타입 검사, 린터가 있는지 확인한다.
   4. 코드 구조·스타일·관례가 문서화돼 있는지 확인한다.
   5. 테스트와 자동 검사로 코드베이스가 계속 건강하게 유지되는지 확인한다.
   6. 큰 고객은 이 점검을 통과한 뒤 문제를 고치기 위한 권장 조치를 받는다.

5.3. 암묵지를 플러그인과 문서로 바꾸기

1. 사람 팀의 암묵지 문제

   1. 새 직원은 문서에 없는 규칙을 동료가 일하는 모습을 보며 배운다.
   2. 조직에는 “이렇게 해 달라”는 선호와 상황별 판단이 문서화되지 않은 채 사람들의 머릿속에 남아 있다.
   3. AI를 쓸 때 같은 선호를 에이전트에게 계속 반복해서 설명해야 하면 에이전트가 자신을 이해하지 못한다고 느끼기 쉽다.

2. 재사용 가능한 지식의 패키징

   1. Factory의 플러그인은 재사용 가능한 스킬과 컨텍스트를 패키징한다.
   2. 팀의 작업 방식과 배경 지식을 코드화해 다음 에이전트 세션이 매번 처음부터 다시 배우지 않게 한다.
   3. 문서를 자동으로 업데이트하고, 기존 문서를 검토하며, 현재 보유한 지식을 계속 기록해야 한다.
   4. 사람 조직에서 온보딩과 지식 공유를 하듯 에이전트 조직에도 공유 가능한 지식 기반을 만들어야 한다.

6. 사람의 역할: 구현 방법이 아니라 만들 것을 결정하기

자동화의 목적은 사람을 영구적인 하위 계층으로 보내는 것이 아니라, 세부 구현과 반복적인 조정에서 한 단계 위의 판단으로 이동시키는 데 있다.

6.1. “사람은 일자리를 잃는가?”라는 질문

1. 비관적 시나리오에 대한 답

   1. 소프트웨어 팩토리를 만들면 사람이 일자리를 잃고 영구적인 하위 계층으로 내려갈지 질문이 제기된다.
   2. Tížková는 그렇지 않을 것이라며 긍정적인 전망을 선택했다.
   3. 사람은 반복적이고 세부적인 실행에서 벗어나 더 흥미롭고 높은 수준의 작업으로 올라갈 수 있다.

2. 추상화의 역사

   1. 과거 사람은 계산을 직접 수행하는 “인간 컴퓨터”였다.
   2. 프로그래밍 언어가 세부 계산 절차를 코드로 추상화했다.
   3. 코딩 에이전트가 구현 일부를 맡았지만 사람은 여전히 가까이서 모든 작업을 감시했다.
   4. 소프트웨어 팩토리에서는 사람이 오케스트레이터·워커·검증자로 이뤄진 에이전트 팀을 관리한다.
   5. 에이전트 팀이 지속적으로 실행하는 동안 사람은 방향을 모니터링하고 무엇을 만들지 결정한다.

6.2. 사람에게 남는 핵심 판단과 자동화할 귀찮은 일

1. 무엇을 만들지 결정하기

   1. 사람은 소프트웨어를 어떻게 만들지보다 무엇을 만들지 결정해야 한다.
   2. 지속적인 자율 루프가 구현·검증·개선을 담당하면 사람은 제품의 가치와 우선순위에 집중할 수 있다.

2. 에이전트가 가져갈 업무

   1. 엔터프라이즈 조직은 정렬 회의에 많은 시간을 쓴다.
   2. 동료에게서 컨텍스트를 모으고, 상태를 공유하고, 계획을 동기화하는 일도 큰 비용을 만든다.
   3. 이런 반복적인 조율을 소프트웨어 팩토리에 맡기면 사람은 더 흥미로운 제품 논의와 문제 해결에 시간을 쓸 수 있다.
   4. AI가 사람에게서 멋진 일을 빼앗는다는 걱정보다, 이미 싫어하던 회의·상태 공유·동기화부터 가져갈 것이라는 전망이 제시됐다.

6.3. 마무리 농담

1. 발표는 “정말 고맙다”는 인사로 끝났다.
2. 마지막 실행 권고는 “밖에 나가 풀을 좀 만지고, 에이전트가 대신 만들게 하라”는 농담 섞인 표현이었다.
3. 이 농담은 사람이 모든 구현 단계를 붙잡고 있지 않아도 된다는 낙관적 결론을 압축한다.

주요 발언 모음

“소프트웨어 팩토리는 자율성을 가진 소프트웨어 개발의 전체 루프, 전체 생명주기다.”

“코드를 쓰는 일은 다른 모든 일에 비하면 쉬운 부분이다.”

“조직 한가운데에 컨설팅을 던져 넣는 것으로는 충분하지 않다. 처음부터 다시 설계해야 한다.”

“작업을 끝낼 수 있을 것으로 예측되는 모델 중 가장 저렴한 모델을 선택한다.”

“에이전트가 오래 실행된다고 해서 프로덕션에서 신뢰할 수 있다는 뜻은 아니다.”

“검증자는 자신이 작성하지 않은 코드를 판단한다.”

“사람은 소프트웨어를 어떻게 만들지가 아니라 무엇을 만들지 결정해야 한다.”

“AI는 멋진 일을 가져가기보다 귀찮은 일을 가져갈 것이다.”

“가서 풀을 좀 만지고, 에이전트가 대신 만들게 하라.”

핵심 데이터 & 수치

• 약 22분 49초: 공개 전사에 대응하는 발표 길이다.
• 2023년: 연속 에이전트 루프 발상이 등장했지만 환각·컨텍스트·추론·격리 환경 문제로 실용화가 제한됐다.
• 수주: Factory Missions가 실행될 수 있다고 제시된 기간이다.
• 16시간: 고객의 실제 Mission 사례가 실행된 시간이다.
• 40%: 해당 16시간 Mission 전체 과정에서 검증이 차지한 비중이다.
• 약 25%: Factory가 제시한 보수적인 자동 모델 라우팅 벤치마크의 절감 수치다.
• 50% 이상: Deferred context engine이 도구 명세를 필요할 때만 로드하며 절약할 수 있다고 제시한 토큰 비율이다.
• 수백 개: 엔터프라이즈가 평균적으로 사용하는 도구의 규모로 언급된 수치다.
• 1년 이상: 장차 에이전트가 사람 개입 없이 실행될 수 있다는 전망으로 언급됐지만, Tížková도 야심찬 예측이라고 표현했다.
• 두 종류의 검증자: Scrutiny validator는 린트·타입·테스트를 확인하고, User-testing validator는 가상 컴퓨터에서 실제 클릭과 동작을 확인한다.
• 532개 구간: 원문 전체 공개 전사를 대조해 번역한 자막 세그먼트 수다.

결론 및 시사점

1. 소프트웨어 팩토리는 코드 생성 도구가 아니라 신호→우선순위→오케스트레이션→구현→검증→프로덕션 테스트→학습의 닫힌 루프다.
2. 모델 선택을 고정하지 말고 작업 난도·권한·도구·비용을 고려하는 라우팅 계층을 만들어야 한다.
3. 최저가 모델 선택의 핵심은 싼 모델 자체가 아니라, 작업을 끝낼 수 있는 능력 임계값을 정확히 분류하는 데 있다.
4. 완료 조건은 테스트 통과가 아니라 사용자가 원하는 실제 결과를 검증하도록 작성해야 한다.
5. 구현 에이전트와 독립 검증자를 분리하고, 코드 검사와 실제 애플리케이션 조작을 함께 수행해야 더미 결과를 걸러낼 수 있다.
6. 순차적인 워커 인계는 각 단계에 새 컨텍스트를 제공하며, 각 워커 내부의 병렬 하위 에이전트와 결합할 수 있다.
7. 수백 개 도구의 전체 명세를 한 번에 넣지 말고, 짧은 설명 후 필요할 때 세부 정보를 불러오는 지연 컨텍스트를 사용해야 한다.
8. 에이전트 도입 전에 재현 가능한 개발 환경, 테스트, 타입 검사, 린터, 문서, 코드 관례를 갖춰야 한다.
9. 팀의 암묵지를 플러그인·스킬·자동 갱신 문서로 패키징해야 다음 작업이 같은 설명을 반복하지 않는다.
10. 사람의 가장 중요한 역할은 구현 방법을 지시하는 일이 아니라 무엇을 만들 가치가 있는지 결정하고 에이전트 팀의 결과를 감독하는 일이다.

핵심 요약 (20줄)

1. 소프트웨어 팩토리는 코드 생성기가 아니라 소프트웨어 생명주기 전체를 자율적으로 운영하는 시스템이다.
2. 사용자 피드백과 로그가 팩토리의 출발 신호가 된다.
3. 신호는 우선순위화된 작업으로 바뀌고 오케스트레이터가 실행을 지휘한다.
4. 구현 뒤에는 검증과 프로덕션 테스트가 이어져야 한다.
5. 결과와 새 지식은 다음 반복에 다시 들어가야 한다.
6. 초기 AutoGPT와 BabyAGI 루프는 환각과 컨텍스트 부족 때문에 안정적으로 작동하지 못했다.
7. 수천 개의 코딩 에이전트를 늘리는 것보다 우선순위와 검증을 설계하는 일이 어렵다.
8. 조직은 Slack과 GitHub 같은 기존 업무 환경에 연결되고 모델 선택에도 독립적이어야 한다.
9. Coinbase는 토큰 사용량이 늘어도 기본 모델·캐싱·라우팅으로 비용을 낮췄다.
10. Factory의 보수적 자동 라우팅 벤치마크는 약 25% 비용 절감을 보였다.
11. 라우터는 작업 난도와 코드베이스를 분류해 완료 가능한 가장 저렴한 모델을 고른다.
12. 자율 루프의 진짜 난제는 에이전트가 언제 완료했는지를 검증하는 일이다.
13. 잘못된 완료 조건은 에이전트가 목적 대신 테스트 통과만 추구하게 만든다.
14. Factory Mission은 오케스트레이터·순차 워커·독립 검증자로 구성된다.
15. 한 고객 Mission은 16시간 실행됐고 검증에 전체 시간의 40%를 썼다.
16. 코드 검증자는 린트·타입·테스트를 보고 사용자 검증자는 가상 컴퓨터에서 직접 클릭한다.
17. 지연 컨텍스트는 수백 개 도구의 전체 명세를 필요할 때만 로드해 토큰을 50% 이상 절약할 수 있다.
18. 재현 가능한 환경과 테스트·문서·코드 관례가 에이전트 도입의 위생 조건이다.
19. 플러그인은 사람 팀의 암묵적인 규칙과 스킬을 에이전트가 재사용할 수 있게 만든다.
20. 사람은 구현 방법보다 만들 것을 결정하고, 귀찮은 조정 업무는 에이전트에게 맡겨야 한다.