소프트웨어 팩토리는 소프트웨어 작업을 중심으로 한 반복 가능한 루프입니다. 소프트웨어 팩토리를 구축하는 경우, 출시할 수 있을 만큼 괜찮은 코드에도 여전히 사람의 취향과 소유권이 필요합니다. 여기에는 팩토리가 지금 꼭 필요한지에 대한 논의도 포함됩니다.
그렇다면:
- 제품 의도, 시스템 설계(중요하게 생각한다면), 품질 기준을 결정하기 위해 초기 단계에는 사람이 개입해야 할 가능성이 높습니다.
- 코드 리뷰는 수행하되(조명이 켜진 팩토리), 가장 필요한 곳에 집중적으로 적용하세요. 자동화된 역압력이 깨지는 지점이나 유지보수성 트레이드오프가 필요한 지점을 주의 깊게 살펴보는 것이 좋습니다.
- 품질 검사는 가능한 한 빠르고 지속적으로 이루어지도록 목표를 세우세요. 모든 검사가 그럴 필요는 없지만, 여기에는 타입 시스템, 자동화된 테스트, 변이 테스트, 보안 스캐너, 아키텍처 규칙을 위한 린팅이 포함됩니다.
- 검사 횟수 != 품질입니다. 어떤 검사가 최상의 신호 대 잡음비를 제공하는지 실험해 봐야 할 가능성이 높습니다. 의도적으로 제약 조건을 강화하거나 완화할 준비를 하세요.
팩토리를 구축할 때는 인간의 취향 중 일부가 환경에 인코딩되고, 에이전트가 작업의 정확성에 대한 증거를 제공하며, 프로덕션에 출시되는 것을 여전히 사람이 "소유"하도록 해야 합니다.
소프트웨어 팩토리가 정말 필요할까요?
제 경험상, 기본 코딩 도구만으로도 놀라울 정도로 많은 것을 해낼 수 있습니다! 즉, Claude Code나 Codex, 여러 세션, 검증이 내장된 좋은 명세, 제약 조건만으로도 충분합니다. GitHub 이슈 배치에 구현 및 인간 개입 기준을 함께 던져넣을 수도 있습니다. Claude Code 루틴과 Copilot/Codex 클라우드 에이전트는 이미 커스텀 인프라 없이도 예약 기반 또는 이벤트 기반 루프를 제공합니다.
팩토리는 반복 가능하고 일관된 실행, 에이전트 간 작업 인계, 두 세션이 동일한 이슈를 처리하는 것을 방지, 증거 보관, 리뷰가 밀릴 때 프로덕션 중단이 필요할 때 가치가 있습니다.
그래서 저는 소프트웨어 팩토리는 소프트웨어 작업을 중심으로 한 반복 가능한 루프라고 말씀드렸습니다. 여기서 아주 작은 팩토리 루프를 보여주는 프롬프트를 실제로 살펴볼 수 있습니다.
코드를 변경하기 전에 GitHub 이슈 #123과 저장소 지침을 읽으세요.
명시된 승인 기준만 구현하세요. 인증, 결제, 마이그레이션 또는 기존 테스트 어설션은 수정하지 마세요. 브랜치에서 작업하고 diff를 검토 가능한 상태로 유지하세요.
npm run lint, npm test, npm run build를 실행하세요. 필요한 검사를 실행할 수 없으면 중단하고 그 이유를 설명하세요. 실행한 검사, 남은 위험, 사람이 여전히 결정해야 할 사항을 포함하여 드래프트 풀 리퀘스트를 여세요. 병합하지 마세요.
목표는 검사가 통과할 때까지 이 과정을 계속 진행하고, 매일 아침 특정 레이블이 있는 GitHub 이슈를 폴링하거나 열려 있는 풀 리퀘스트를 검토하도록 할 수 있습니다. 브랜치 보호를 통해 병합 경계를 강제할 수 있으며, 사람은 무엇을 준비할지 선택하고, 리뷰하고, 최종 병합 결정을 내리는 등의 방식으로 루프에 계속 참여할 수 있습니다.
일부 명시적인 인간 감독 하에 트라이지, 구현 및 테스트를 처리하기 위해 격리된 클라우드 환경에서 실행되는 이벤트 기반 작업 큐(예: Slack 트리거, GitHub 이슈, Linear, 백로그)가 필요할 때 소프트웨어 팩토리를 추가하세요. 일부는 프로덕션을 모니터링하고 이슈를 제기하여 다시 트라이지하는 모니터 에이전트로 루프를 종료합니다.
제 경험상, 팩토리는 다양한 실행을 일관되게 유지하고, 에이전트 간 작업을 인계하고, 다른 세션이 동일한 이슈를 처리하는 것을 방지하고, 증거를 보존하고, 인간 리뷰가 뒤처질 때 프로덕션을 중단하는 것이 어려운 부분일 때 유용해집니다.
이를 해결하는 방법은 다소 지루하게 들릴 수 있습니다. 예를 들어, Warp는 들어오는 모든 이슈를 구현 준비 완료, 명세 준비 완료, 정보 필요, 구현 대기의 네 가지 상태 중 하나로 트라이징하며, 이 레이블이 다음 에이전트를 실행한다고 언급합니다.
이 레이블은 한 번에 여러 작업을 수행합니다. 큐 역할, 잠금 역할을 하며, 세션이 준비된 것으로 표시된 것만 선택하기 때문에 사람이 영구적으로 거절하지 않고 작업을 보류할 수 있는 곳이기도 합니다.
워크플로우 측면에서 Claude/Codex만 사용하는 것과 몇 가지 유사점과 차이점이 있습니다.
- 방향 제시: 에이전트가 방향 수정이 필요할 때 입력을 제공하고 리디렉션할 수 있습니다.
- 알림: 팩토리가 차단되었음을 알리는 방식입니다. 요구 사항이 모호했거나, 위험한 작업을 시작했거나, 사람의 입력(방향 제시)이 필요하기 때문일 수 있습니다.
- 인계: 작업, 상태 및 컨텍스트를 클라우드 팩토리/다른 에이전트/인간 리뷰어에게 전송합니다. 좋은 인계는 무슨 일이 있었는지, 무엇이 남았는지, 왜 인계가 필요한지 추적합니다.
좋은 팩토리에서 사람은 단순히 최종 diff를 맨 마지막에 검토하고 승인하는 데 국한되지 않습니다. 초기 단계에서 작업을 구체화하고, 구현 중에 방향을 제시하고, 인계를 통해 진행하거나, 프로덕션 출시를 중단할 수 있습니다.
검증은 책임 있는 팩토리가 많은 시간을 할애하는 부분입니다. 이에 대해서는 나중에 더 자세히 다루겠습니다.
소프트웨어 팩토리가 필요하다고 결정했다면, 직접 구축하는 것만이 유일한 옵션은 아닙니다. 팩토리를 확장하기 위한 인프라를 구축하는 것은 많은 작업이 될 수 있으며, 구매 대 구축을 고려해야 할 수도 있습니다. Factory.ai, Devin, Warp, HumanLayer 모두 이 루프의 일부를 판매하고 있습니다.
내가 실제로 집중하는 부분
지난 1년 동안 소프트웨어 개발에 대한 나의 일상적인 경험은 많이 바뀌었습니다. 저는 점점 더 에이전트와 병렬 작업을 많이 수행하고, 조명이 켜진 소프트웨어 팩토리로 나아가는 것에 대해 이야기해 왔습니다. 그리고 많은 사람들이 저에게 묻습니다. 이것들이 실제로 무엇을 의미하는지? 무엇을 만들고 있는지? 이런 것들을 어떤 종류의 프로젝트에 사용하고 있는지? 대부분은 이렇습니다:
평범한 하루에 저는 더 간단한 조명이 켜진 소프트웨어 팩토리를 가지고 있습니다. 클라우드에서 실행되는 작업들이 있을 수 있습니다. 이 작업들의 절반은 제가 함께 일하는 소규모 회사의 프로덕션 클라이언트 애플리케이션에서 작업하는 것일 수 있습니다. 실제 사용자가 있을 것입니다. 실제 인증, 결제, 구독, 주의해야 할 실질적인 위험이 있을 것입니다. 테스트와 제약 조건, 품질 검사 없이 에이전트에게 그냥 가서 하라고 말할 수는 없습니다.
오픈 소스 프로젝트에서 작업할 수도 있습니다. 제 책의 동반 사이트를 구축할 수도 있습니다. 도구를 만들 수도 있습니다. 제 자신의 앱을 구축할 수도 있습니다. 그리고 이것들은 모두 제가 작업하는 매우, 매우 다른 종류의 애플리케이션입니다. 때로는 이들의 공통점은 작업하는 데 사용하는 도구뿐입니다. 마이그레이션 작업을 할 수도 있습니다. 다른 때는 실제로 중요한 기능 작업을 할 수도 있습니다. 작업의 영향 범위도 매우, 매우 다를 수 있습니다.
따라서 점점 더 많은 병렬 작업을 수행하고, 속도를 높이고, 생산성을 향상시키고, 자율성을 높이는 방향으로 나아가기 시작하려면(즉, 시스템을 더 신뢰할 수 있는 상태로 만드는 것), 반드시 인간의 코드 리뷰와 입력이 절대적으로 필요한 부분이 무엇인지 생각해야 합니다.
그리고 그 중 많은 부분이 초기에 필요할 것입니다. 명세, 요구 사항을 정의할 때, 제품 디자인은 어떻게 될지? 제품의 의도는 무엇인지? 그리고 에이전트가 작업을 제대로 완료했는지 어떻게 확인할 것인지? 기존 시스템을 망가뜨리지 않았는지 어떻게 확인할 것인지? 품질 기준을 충족하는지 어떻게 확인할 것인지?
따라서 코드를 생성하는 것이 반드시 가장 걱정해야 할 부분은 아닙니다. 충분한 컨텍스트가 주어지면 에이전트는 구현을 작성하고, 테스트를 실행하고, 실패를 검사하고, 코드를 수정할 수 있습니다. 우리는 환경에 인간의 취향이 충분히 인코딩되어 구축되는 것을 신뢰할 수 있는 상태에 도달해야 하며, 그래야 인간의 주의력이 가장 필요한 곳에 집중될 수 있습니다.
물론, 이런 것들을 모두 자동화할 수 있다는 데 동의하지 않는 사람들도 있습니다. 모든 것을 자동화한다는 의미는 아닙니다. 하지만 생성되는 코드의 양을 고려할 때, 인간이 모든 코드를 읽는 것은 현실적이지 않다고 생각합니다. 특히 우리가 항상 로켓을 만드는 것은 아니기 때문입니다. 우리는 UI를 만들고, 풀스택 애플리케이션을 만듭니다.
우리의 판단력과 취향은 가장 필요한 곳에 집중하는 것이 가장 좋습니다. 시스템에서 가장 위험한 부분은 무엇인가? 인간의 취향을 어디에 적용해야 하는가? 그것은 프론트엔드일 수도 있고, 시스템 작동 방식일 수도 있습니다. 모든 부분일 필요는 없습니다.
내 인지 대역폭은 에이전트를 따라가지 못한다
현실은, 우리는 이제 수십, 수백, 수천 개의 에이전트를 병렬로 실행할 수 있지만, 우리 자신의 인지 대역폭은 같은 방식으로 확장되지 않습니다. 이는 제가 이전에 이야기한 인지 또는 이해 부채로 이어질 수 있습니다.
불과 5년, 10년 전만 해도 엔지니어링 커뮤니티에서는 컨텍스트 스위칭과 그 비용에 대한 논의가 많았습니다. 우리는 동료나 누군가가 작업 중일 때 책상으로 걸어오는 것을 싫어한다고 이야기하곤 했습니다. 그러면 다시 몰입 상태로 돌아가는 데 오랜 시간이 걸렸습니다. 어디까지 했는지, 무엇을 하고 있었는지 다시 파악해야 했기 때문입니다. 약간의 잔여물이 남아 있더라도 여전히 시간이 걸렸습니다.
우리는 이제 이전보다 훨씬 더 많은 컨텍스트 스위칭을 하고 있습니다. 어느 날이든, 소프트웨어 팩토리 외부에서 작업하는 경우, 한 번에 에이전트와 함께 5~10개의 다른 프로젝트에서 작업하거나, 단일 프로젝트에서 5~10개의 다른 기능을 동시에 작업할 수 있습니다. 효과적으로 5~10개의 다른 세션을 가질 수 있습니다.
즉, 그중 적어도 몇 가지는 계속 파악하고 있어야 합니다. 작업을 충분히 잘 정의하고, 결과물과 작업 완료 확인 방법을 충분히 잘 정의했다는 신뢰가 있다면 일부 작업에 더 많은 자율성을 부여할 수 있습니다. 하지만 그렇지 않다고 느끼거나 더 많은 위험이나 미묘한 차이가 있는 작업도 있을 것입니다. 그런 작업에는 주의를 기울여야 합니다.
리뷰어를 위해 소프트웨어 팩토리를 최적화하는 것을 고려해 보세요. 이러한 모든 접근 방식이 여전히 그 출력을 한 사람의 주의로 보낸다는 점을 감안할 때, 팩토리가 당신이 여전히 내려야 할 결정을 얼마나 더 저렴하게 만드는지 물어봐야 합니다.
잘못된 프로젝트 실수
에이전트와 함께 여러 병렬 프로젝트에서 작업할 때, 의도치 않게 실수를 한 적이 있습니다. 예를 들어, 다크 모드를 추가하려는 웹 앱에서 작업하고 있었는데, 머릿속에는 이것이 어떻게 생겨야 하는지에 대한 구상이 있었습니다. 하지만 실수로 다른 프로젝트의 세션으로 가서 동일한 프롬프트를 입력하기 시작했습니다.
그래서 전혀 필요하지 않은 무언가에 다크 모드를 구현하기 시작했습니다. 이런 실수를 할 수 있습니다. 제 소프트웨어 팩토리가 이런 실수를 하는 것을 원하지 않습니다.
이것을 시스템의 관점에서 생각해야 합니다. 효과적으로 소프트웨어 엔지니어링 문화, 팀 문화를 시스템에 인코딩하여 동일한 종류의 행동을 갖도록 하고, 어딘가에 소유권이 존재하도록 하고, 무슨 일이 일어나든 누군가 여전히 책임을 지도록 하고, 이러한 것들에 대해 매우 명시적으로 생각하는 것입니다.
초록색이 오해를 불러일으킬 때
이러한 시스템에서도 매우 주의해야 합니다. AI에게 테스트 통과를 도와달라고 요청했을 때, 프로그래밍 테스트, 단위 테스트를 말할 때, AI가 해당 조건을 충족시키기 위해 단위 테스트를 변경하거나 코드의 로직을 변경할 수 있다는 것을 많은 사람들이 보았을 것입니다. 이것이 기능적 동작과 테스트가 테스트해야 했던 것을 모두 정렬하기 위해 당신의 의도를 실제로 따랐다는 것을 의미하지는 않습니다.
소프트웨어 팩토리가 모든 것이 초록색이라고 표시한다고 해서 실제로 초록색이라는 의미는 아닙니다. 특히 이러한 것들을 설정하는 초기 단계에서는 더욱 그렇습니다. 검사, 확인 등이 올바르게 구성되었는지 확인하는 데 많은 주의를 기울여야 합니다. 예상대로 작동하고 있는지 확인해야 합니다. 오해의 소지가 있어서는 안 됩니다.
테스트에서 "지원되는 인증 제공자를 변경했습니다. 예를 들어 GitHub를 인증 제공자로 추가하라고 요청했지만, 제 UI에는 공간이 세 개밖에 없어서 다른 제공자 중 하나를 제거했습니다. 그런데 그게 고객이 원했던 제공자였습니다."와 같은 상황을 원하지 않을 것입니다. 따라서 이러한 시스템이 어떻게 작동하기를 원하는지 매우 명시적으로 설명해야 합니다.
그건 그렇고, 보안도 매우 중요합니다. 팩토리가 GitHub 이슈/Slack 메시지와 같은 신뢰할 수 없는 입력을 읽는 경우, 적대적일 수 있으며 공급망 공격과 같은 문제를 포함할 수 있습니다. Vercel Sandbox/AI ADK Factory와 같은 소프트웨어 팩토리 관련 일부 제품은 작업에 필요한 비밀만 보유한 격리된 샌드박스에서 에이전트를 실행합니다. 이렇게 하면 손상된 실행이 작업에 필요하지 않은 것에 도달할 수 없습니다. 방어는 계층화됩니다.
어떤 오래된 프로젝트에 두 번째 기회를 줄 것인가?
또한 요즘 우리가 일하는 방식의 큰 부분은 무엇이 존재해야 하는지 결정하는 것이라고 생각합니다. AI 이전의 수년 전을 기억해 보면, 너무나 많은 버려진 소프트웨어 엔지니어링 프로젝트, 너무나 많은 버려진 주말 프로젝트, 개인 프로젝트가 있었습니다. 그것들을 완료할 시간이 없었기 때문에 출시되지 못했습니다. 그것들을 완료하는 데 우선순위를 둘 여유가 없었습니다. 우리에게 그렇게 중요하지 않았거나 시간을 낼 수 없었기 때문입니다.
이제 그러한 프로젝트를 완료하는 것은 상당히 쉬워졌지만, 동일한 인간의 판단 문제가 제기됩니다. 그러한 프로젝트가 존재할 가치가 있는가? 출시되어야 하는가? 세상에 내놓으면 사용자가 5명뿐이더라도 유지 관리해야 할 수도 있습니다. 유지하고 싶은 품질 기준이 생길 수도 있습니다.
수년 동안 GitHub 프로젝트가 너무 많았는데, 이제 에이전트가 생겼으니 가장 먼저 하는 일은 빌드가 되도록 만드는 것입니다. 물론, 클론을 하면 모든 의존성이 변경되어 빌드가 되지 않기 때문입니다. 절반은 구식이거나 보안 취약점이 가득하므로 업데이트해야 합니다.
그런 다음 테스트가 없다면 테스트를 추가하여 프로젝트를 업그레이드하거나 최신 언어나 프레임워크 등으로 마이그레이션할 때 해당 동작이 적어도 유지되도록 해야 합니다.
그런 다음 스스로에게 묻기 시작합니다. 어리석은 예일 수 있지만, 예전에는 Twitter Bootstrap을 사용했지만 지금은 모두 Tailwind와 shadcn을 사용하므로 UI를 다시 구현해야 합니다. 그러면 갑자기 시간이 더 걸린다는 것을 알게 될 것입니다. 에이전트가 많은 것을 더 빨리 처리할 수 있지만, 이제 제품 감각, 취향 등 모든 요소를 고려해야 합니다.
여전히 질문하게 됩니다. 이것이 누구를 위한 것인가? 시장이 있는가? 나 자신을 위한 것인가? 다른 사람을 위한 것인가? 세상에 내놓았을 때, 이제 누구나 이것을 빠르게 만들 수 있다는 점을 감안할 때 여전히 흥미로울 것인가?
따라서 이러한 것들이 존재할 가치가 있는지에 대한 인간의 질문, 우리의 취향과 판단을 어떻게 고려할 것인지? 이러한 것들이 계속해서 매우 중요하다고 생각합니다. 바로 그 희소한 자원인 인간의 주의력이 실제로 필요한 곳입니다. 예전에는 하루에 정해진 시간만 있었습니다. 회의가 있었고, 디자인과 코딩 등을 위한 시간을 계획해야 했습니다.
이제 우리를 도와줄 에이전트가 생겼으므로, 시간을 어디에, 왜 쓰는지에 대해 매우 명시적으로 설명해야 한다고 생각합니다.
샘플 팩토리를 구축했을 때 일어난 일
이제 82분 팩토리 실행에 대해 이야기하겠습니다. 사람들은 꽤 오랫동안 저에게 "소프트웨어 팩토리를 어떻게 구축하나요?" 또는 "Claude Code나 Codex를 사용하는 데 익숙한데, 어떻게 설정을 소프트웨어 팩토리로 발전시키나요?"라고 물어왔습니다.
그래서 제가 가장 먼저 말하는 것은 "괜찮을 수도 있습니다. 팩토리가 없어도 작업이 완전히 괜찮을 수 있습니다."입니다. 하지만 사람들이 확인해 볼 수 있는 참조 설정을 제공하고 싶었습니다. 그래서 제가 만든 것은 Factory라는 저장소로, 가서 확인해 볼 수 있습니다. 또한 데모 애플리케이션과 워크숍도 만들었습니다.
지난 몇 년 동안 많은 것에 대한 제 대표 데모 애플리케이션은 영화 앱이었습니다. 저는 영화를 아주 좋아합니다. 영화 보는 것을 좋아하고 항상 영화를 봅니다. 그래서 아주 간단한 영화 앱으로 시작하는 데모 애플리케이션이 있습니다. 그리고 팩토리가 할 수 있기를 바라는 것은 여러 기능을 구현하는 것입니다. 몇 가지 다른 기능이 있습니다. 즐겨찾기 기능을 원하고, 검색 기능을 원하고, 다크 테마도 원할 수 있습니다. 그런 것들입니다.
그래서 제 팩토리가 이것들로 작업을 시작합니다. 구현을 확인할 수 있습니다. 그 이점 중 하나는 실제 문제를 발견하는 것이었습니다. 이러한 문제는 한 번에 구현하도록 요청했다면 발견하지 못했을 수도 있는 문제들입니다.
약 60분쯤 되었을 때, "와, 이거 유난히 느리게 진행되는데?"라고 느꼈습니다. 팩토리를 사용하여 제 도구에 "왜 느리게 진행되나요?"라고 물었습니다. "괜찮습니다. 모든 검증기가 아직 실행 중입니다."라고 대답했습니다.
개별 작업이 10분, 15분, 20분이 걸릴 것으로 예상했을 수도 있지만, 검증, 재시도, 브라우저 검사, 인간 리뷰 등 추가 지연이 포함되면 2~4배 더 오래 걸릴 수 있습니다.
이러한 것들이 더 나은 품질과 시스템에 대한 더 나은 신뢰로 이어질 수 있다고 생각합니다. 측정 관점에서 병합된 PR당 비용과 코드 수명을 이해 부채 지표로 볼 수 있습니다.
또한 유용한 지연과 팩토리 오버헤드를 구분해야 합니다. 제 경우 검증기가 몇 가지 실제 문제를 발견했습니다. 약간의 시간은 제가 원하는 증거를 생성하는 데 사용되었을 수 있습니다. 일부는 팩토리 실행의 오버헤드였습니다. 최적화하는 데 시간을 전혀 들이지 않았지만, 가치를 찾지 못하는 많은 검사만 실행하는 팩토리가 고품질 팩토리를 의미하지는 않습니다.
반복되는 검사가 관련 없는지, 잡음이 있는지, 실제로 시스템을 더 안전하게 만드는지 연구해야 합니다.
검증에는 예산이 필요하다
제가 검증 예산에 대해 생각하는 방식은 기본적으로 우리가 이야기하는 것입니다. 검증 예산에 대해 이야기하는 것입니다. 예전에 성능 예산에 대해 생각했던 것과 같은 방식으로 생각합니다.
소프트웨어 개발 수명 주기 초기에 실행할 수 있는 특정 종류의 검사가 있고, 매우 무겁지만 많은 가치를 제공하기 때문에 나중에 실행하고 싶은 것들도 있습니다. 린팅, 타입 검사와 같은 빠른 검사들이 있습니다. 이것들은 초기에 실행할 수 있는 비교적 빠른 검사입니다.
전체 테스트 스위트는 드래프트 PR을 작성하기 직전이나 그 이후에 실행할 수 있습니다. 여기에는 변이 테스트, 브라우저 테스트, 보안 검사 등이 포함될 수 있습니다.
이러한 검사를 요약으로 대체하고 싶지는 않을 것입니다. 실제 테스트가 필요하지만, 개발 루프를 느리게 하고 싶지 않기 때문에 올바른 위치에 예산을 책정해야 합니다. 저는 확실히 개발 루프를 느리게 하고 싶지 않습니다. 빠른 반복 루프를 갖는 것은 저에게 중요하지만, 여전히 이러한 견제와 균형을 원합니다.
출시되지 않는 실행
위에서 제가 쓴 내용의 대부분은 검사에 관한 것입니다.
Vercel은 소프트웨어 팩토리에서 모든 에이전트 실행을 "성공", "결함 있음", "차단됨" 또는 "수동"으로 표시하고 "성공"만 프로덕션에 출시합니다. 나머지는 시스템에 다시 들어갑니다. 저도 비슷한 용어로 실행에 대해 생각해 왔습니다.
여기서 "결함 있음"은 잘못된 것이 구현되었거나 전체 컨텍스트가 없었을 수 있음을 의미하므로 수정해야 합니다. "차단됨"은 환경에 자격 증명이 없어서 제공해야 함을 의미할 수 있습니다. "수동"은 팩토리가 아직 넘을 수 없는 경계입니다.
여기 세 가지 중 두 가지는 기계적인 수정이 가능할 수 있으며, 마지막 하나는 신뢰에 관한 것입니다.
이 분류는 훌륭하지만 비용을 보여주지 않습니다. TMDB 앱을 사용한 제 팩토리 구현으로 돌아가서, 거부 없이 빠른 찾기는 7분이 걸렸습니다. 두 번의 거부와 중간에 인간의 결정이 있었던 즐겨찾기는 56분이 걸렸습니다. 동일한 팩토리입니다. 따라서 분류와 함께 단계별 타이밍을配对해야 합니다. 그렇지 않으면 실행이 결함이 있는 것으로 돌아왔다는 것을 알지만, 그 사실을 알아내는 데 드는 비용은 알 수 없습니다. 제가 수정하고 싶은 또 다른 것은 경계에서의 인계입니다. 제 샘플 팩토리는 첫 번째 이슈를 중단하고 factory:needs-info로 이동시켰는데, 이는 옳았지만 제 답변을 어디에 넣어야 할지 몰랐습니다. 수동 실행은 팩토리가 중단될 때 끝나는 것이 아니라 사람이 다음에 무엇을 해야 할지 알 때 끝납니다.
자율성은 단일 설정이 아니다
몇 주 전에 저는 에이전트 자율성과 자율성에 대해 생각하는 방법에 대한 기사를 썼습니다. 자율성은 모든 프로젝트에 대한 단일 설정이 될 수 없기 때문입니다.
검증은 신뢰를 얻고 에이전트에게 더 많은 자율성을 부여할 수 있는 능력을 얻습니다. 예를 들어, 중요하지 않은 변경 작업을 하고 있지만 여러 검사가 마련되어 있고 모든 것이 올바르게 검증되었으며 직접 수동으로 확인했을 수도 있습니다. 다음에 동일한 프로젝트에서 그와 같은 작업을 수행할 때는 에이전트에게 약간 더 많은 자율성을 부여해도 괜찮다고 느낄 수 있습니다.
이것이 소프트웨어 팩토리를 구축할 때 생각해야 할 것입니다. 검증은 위험에 따라 달라집니다. 목표는 최상의 신호 대 잡음비입니다. 실행 중인 거대한 체크리스트만 가지고 있어서는 안 됩니다.
다시 배워야 했던 기능
Claude로 여러 세션을 사용하던 어느 날, 미루고 있던 기능이 있었습니다. 한 번에 여러 프로젝트, 프로젝트당 여러 기능을 작업하고 있었습니다. Claude가 제가 작업 중이던 기능을 구현했습니다. 테스트가 통과하는 것처럼 보였습니다. 검증에 대해 많이 생각하지 않았지만 테스트가 통과했기 때문에 작동한다고 생각하고 병합했습니다.
즐겨찾기 기능이었습니다. 꽤 괜찮다고 생각했습니다. 브라우저에서 확인해 보니 괜찮아 보였습니다. 하지만 며칠 후, 몇 가지 수정을 하고 싶어서 코드로 돌아갔습니다.
단순히 에이전트에게 변경을 요청하고 싶지 않았어요. 왜냐하면 그것이 작동하는 방식이 미묘했거든요. 아이콘을 탭해도 탭할 때 올바른 효과가 표시되지 않아서, 그냥 약간 수정하고 싶었습니다. 어떻게 작동하는지 이해해야 에이전트를 올바르게 안내할 수 있을 것 같았어요.
코드로 돌아갔지만, 그 기능이 어떻게 작동하는지 설명할 수 없었습니다. 이 저장소는 제 것이었죠? 변경 사항을 승인했습니다. 저장소의 많은 부분이 어떻게 작동하는지 이해했지만, 제 이해가 쌓여가는 모든 코드를 따라잡지 못하고 있었습니다.
제가 제대로 파악하지 못한 것은 추가된 이 기능이 실제로 어떻게 작동하는지, UI 가 어떻게 작동하는지, 그 효과가 어떻게 작동하는지였습니다. 이 기능을 다시 구현하면서 단계별로 "이게 어떻게 작동하지? 어떻게 이해할 수 있을까?"라고 생각해야 했습니다.
병렬 작업이 이해에 미치는 영향
병렬 작업을 수행하면 이 전반적인 문제가 증폭되고, 소프트웨어 팩토리에서 작업할 때는 더욱 심해집니다. 5~10개의 세션을 동시에 진행하면 단순한 리뷰 볼륨 문제 이상을 만들어냅니다. 다른 곳에서 작업하는 동안 상당히 식어버릴 수 있는 여러 개의 멘탈 모델을 생성합니다.
우리는 historically 컨텍스트 스위칭의 어려움에 대해 이야기해 왔습니다. 채팅이 압축되자마자 일부 접근 방식을 거부하고, 다른 것들을 시도해 보고, 에이전트와 페어링하면서 세션에서 일어난 모든 일을 기억하기 어려워집니다.
위로 스크롤할 수 있지만, 압축이 진행되면서 모든 내용이 거기에 있지 않을 것이고, 모든 것을 머릿속에 저장할 수도 없습니다. 코드는 종종 내려진 결정을 보존하지만, 결정이 내려진 이유는 보존하지 않습니다.
이것은 여러분에게 유용한 학습이 될 수 있다고 생각합니다. 에이전트에게 궤적에 대한 정보나 문제에 접근한 방식에 대한 흥미로운 교훈을 실제로 저장하도록 요청하는 것을 고려하는 것이 중요합니다. 나중에 다시 참조할 수 있도록 말이죠.
이것은 저장소에 커밋하기로 결정할 수도 있고 아닐 수도 있습니다. 원한다면 로컬에 보관할 수도 있고, 원한다면 팀과 공유할 수도 있습니다. 하지만 이것은 나중에 참조할 수 있는 자료가 될 수 있습니다. 세션에 있을 수도 있고 나중에 기억할 수도 있다는 것에 의존하는 것보다는 말이죠.
실제로 무엇을 만드는가?
@threepointone 과 @bentlegen 이 소프트웨어 팩토리에 대한 의견 을 게시했는데, 저는 이에 크게 동의합니다:
작업을 수행하는 메커니즘에 매료되어 이를 최적화하고, 그것이 무엇을 생산해야 하는지 잊어버리기 쉽습니다. 공장이 주로 더 나은 공장을 생산한다면, 당신은 그 제품이 자신인 소프트웨어를 구축한 것입니다.
루프에 투자하는 것은 괜찮고 복리 효과가 있다고 생각합니다. 실패는 루프가 닫힐 때, 즉 공장이 생산하는 모든 것이 공장 자체에 의해 소비되고 외부에서는 아무도 그것을 꺼도 눈치채지 못할 때 발생합니다. 제가 적용할 테스트는 풀(Pull)입니다. 외부에서 개선을 요구하는 무언가가 있어야 합니다. 누가 당기는지 이름을 댈 수 없다면, 당신은 광택을 내고 있는 것입니다.
소유권은 사라지지 않는다
이 모든 것의 밑바탕에는 더 넓은 원칙이 있습니다.
인간이 물리적으로 입력하는 코드의 비율은 급격히 떨어질 수 있습니다. 하지만 인간의 소유권이 그와 함께 떨어질 필요는 없다고 생각합니다.
- 누군가는 여전히 문제를 선택합니다.
- 누군가는 여전히 아키텍처를 선택합니다.
- 누군가는 여전히 품질 기준을 설정합니다.
- 누군가는 어떤 검증 신호가 신뢰할 가치가 있는지 결정합니다.
- 누군가는 증거가 출시하기에 충분한 시점을 결정합니다.
그리고 결과 시스템이 실패했을 때, "에이전트가 작성했습니다"라는 말은 통하지 않습니다. 이것이 제가 소프트웨어 엔지니어링의 미래가 인간이 루프에서 벗어나는 것으로 가장 잘 설명되지 않는다고 생각하는 이유입니다. 대신, 인간의 판단이 재배치되고 있습니다.
우리는 기계가 더 강력하고, 빠르며, 더 결정론적인 신호를 생성할 수 있는 루프의 부분에서 사람들을 제거해야 합니다. 동시에, 컨텍스트, 취향, 위험 및 장기적 소유권이 가장 중요한 곳에 사람들을 집중시켜야 합니다.
최고의 소프트웨어 팩토리는 인간의 개입을 얼마나 완전히 제거하는지로 정의되지 않을 것입니다.
그것들은 얼마나 지능적으로 인간의 개입을 배치하는지로 정의될 것입니다.
의도, 시스템 형태 및 품질 기준에 대한 인간의 판단을 상류에 유지하십시오. 자동화된 역압력이 약해지거나 결과가 주관적이 되는 곳에서 코드를 검토하십시오. 모든 결정론적 신호를 가능한 한 빠르고 지속적으로 루프에 밀어 넣으십시오. 시스템이 신뢰를 얻거나 잃음에 따라 제약 조건을 의도적으로 강화하거나 완화하십시오.
인간은 여전히 최종적으로 출시되는 코드를 소유해야 합니다. 출시할 수 있을 만큼 좋은 코드는 여전히 그것이 존재해야 하는지 신경 쓰는 누군가로부터 시작됩니다.
