AI 코딩 에이전트(AI Coding Agent)를 진지하게 활용하다 보면, 단발적인 채팅으로 다룰 것인지 아니면 일종의 생산 라인으로 설계할 것인지에 따라 얻을 수 있는 성과가 크게 달라진다. 개발자 Benedict Brady가 공개한 「Notes on the software factory」는 후자의 입장에 선 실천 메모다. 원래는 투자 회사 Ellipsis Labs의 사무실에서 진행한 「vibe coding(감각에 맡기는 AI 코딩)」에 관한 강연을 문장화한 것으로, 에이전트에게 무엇을 부여하고, 어디를 빠르게 하며, 무엇이 아직 취약한지를 현장의 체감도를 담아 불렛 포인트로 정리하고 있다.

「소프트웨어 공장(Software Factory)」이라는 비유가 적절하게 느껴지는 이유는, 이 기사가 개별적인 프롬프트 기술이 아니라 인간과 에이전트가 함께 돌리는 워크플로우(Workflow) 전체를 어떻게 구축할지를 다루고 있기 때문이다. 이미 에이전트를 일상적으로 사용하고 있는 엔지니어나 테크 리드(Tech Lead)에게 다음 단계의 수를 고민하기 위한 설계도가 될 것이다.

원문은 여기: https://www.benedict.dev/software-factory

기사의 출발점은 심플하다. 엔지니어가 사용하는 것과 동일한 도구 세트를 에이전트에게 부여하라는 것이다. 배포를 실행하는 CLI, 프런트엔드를 확인하기 위한 브라우저, 테스트나 시뮬레이션을 돌리는 고성능 머신(저자는 Modal을 언급함) 등이 그 예다. 긴 공정을 마지막까지 완수하게 하려면, 인간 개발자가 가진 인프라(Infrastructure)에 대한 액세스 권한을 에이전트에게도 부여할 필요가 있다는 논리다.

흥미로운 점은, 이러한 셋업은 「팀에 한 명, 제대로 구축할 수 있는 사람이 있어서 그 환경을 다른 멤버들에게 배포할 수 있는」 형태가 되기 쉽다는 지적이다. 이는 병목 현상(Bottleneck)이 발생하는 부분에 바로 사업 기회가 있다는 관점으로도 이어진다.

다음 테마는 느린 공정을 찾아 빠르게 만드는 것이다. 여기서 저자가 강조하는 것은 사고 단계(Thinking step)의 주변, 즉 실행이나 체크에 해당하는 부분을 모두 고속화하고 병렬화해 두어야 한다는 생각이다. 목표는 병목을 「실행」이 아닌 「사고」 그 자체로 옮기는 것이다. 실행이 발목을 잡지 않게 되면, 모델이 생각하는 시간이 전체의 제약 요인(Rate-limiting factor)이 된다. 실행 상황을 모니터링하는 루프(Loop)를 돌려두는 구체적인 방안도 덧붙여져 있다.

품질을 높이기 위한 고안으로서 두 가지 점이 인상적이었다. 하나는 「비평가(Critic)」를 별도의 에이전트로 세우는 것이다. 작업 중인 에이전트와는 분리된, 백지 상태의 문맥(Context)을 가진 에이전트에게 결과물을 평가하게 하고 개선안을 내놓게 한다. 루브릭(Rubric, 평가 기준)을 텍스트로 정의하고, 그 기준에 도달할 때까지 반복시키는 /goal과 같은 패턴이 긴 공정의 일관성을 유지하는 데 효과적이라고 한다.

또 다른 하나는 품질이 사고량에 비례한다는 관찰이다. 「벤치마크 스코어는 사고 시간과 함께 향상된다」ため, 어려운 문제일수록 사고의 정도를 높이라는 솔직한 제안이 된다. 과거에는 문맥 길이(Context length)의 제약 때문에 명시적인 플랜(Plan) 작성 공정을 거쳤으나, 제약이 완화되고 있는 지금은 형식적인 플랜 모드는 생략하되 「먼저 측정하고 나서 자른다」는 원칙만 남기면 된다는 방침의 변화도 솔직하게 기술되어 있다.

이 부분이 개인적으로 가장 납득이 가는 대목이다. 이상적인 것은 배후에서 조용히 사용자의 취향을 학습해 주는 기억 기능이지만, 현실은 아직 그 단계에 이르지 못했다. 모델은 기억 파일에 대한 쓰기나 삭제는 할 수 있지만, 다양한 인간의 취향에 맞춰 행동하도록 충분히 훈련되지 않았다. 향후에는 「꿈을 꾸며 성찰하는」 듯한 메커니즘이 신뢰성을 높일지도 모른다는 전망이 언급되어 있다.

현시점에서 어렵다고 꼽힌 것은 극단적으로 오래 지속되는 워크플로우 관리, 사업 컨텍스트(Business Context) 추출, 지속적 학습과 샘플 효율성, 그리고 상시 가동되는 에이전트다. 이는 보충 설명하자면, 많은 팀이 「에이전트는 단거리 달리기는 빠르지만 장거리 달리기는 서툴다」고 느끼는 실감과 잘 맞닿아 있다.

기사의 후반부는 보다 깊이 있는 미래상으로 향한다. 저자는 「스킬(Skill)」을 워크플로우나 환경 특유의 습관을 기록한 문서로 정의한다. 모델은 매 세션마다 처음부터 다시 배우기 때문에, 미리 스킬을 읽게 하면 시작 단계를 단축할 수 있다. 다만 모델이 똑똑해짐에 따라 이러한 종류의 스킬은 필요 없게 될 것이라고 보고 있다. 이는 범용적인 계산과 학습이 특화된 기교를 압도한다는 「쓰라린 교훈(The Bitter Lesson)」을 염두에 둔 것이다.

더욱 대담한 예측은 GitHub가 역할을 다할 것이라는 점이다. 에이전트(Agent)가 모든 풀 리퀘스트(Pull Request, PR)를 리뷰하고 통합 테스트(Integration Test) 세트가 갖춰진다면, 인간 중심의 리뷰 기반은 의미가 퇴색된다. 애초에 코드는 고도로 압축된 출력물이며, 에이전트끼리는 트레이스(Trace), 스킬(Skill), 문맥(Context)과 같이 훨씬 더 대역폭(Bandwidth)이 넓은 정보로 상호작용해야 한다는 주장이다. 그렇기에 AWS부터 IDE에 이르기까지 인간이 아닌 에이전트를 위해 수직적으로 재설계된 '에이전트 네이티브 스택(Agent-native stack)'이 필요하다. 빠른 배포 루프(Deployment loop), 에이전트용 트레이스, 용이한 테스트와 롤백(Rollback), 단계적인 권한 관리, 에이전트에 대한 알림(Alert) 통지 등이 요구사항으로 나열된다.

그러한 맥락에서 "End-to-End로 테스트할 수 없는 것은 시스템에 있어 거대한 부채다"라는 구절은 강렬하다. 통합 테스트가 충실하다면 에이전트에게 대규모 재설계를 맡길 수 있다는 인과관계다. 입력 수단으로서의 타이핑(Typing) 또한 대역폭이 좁다고 간주하며, 음성 입력을 거쳐 결국 대화나 환경음, 영상과 같은 문맥을 받아들이는 단계로 나아갈 것이라고 전망하고 있다. 로컬(Local)과 클라우드(Cloud)의 활용 방식이 현재는 어중간하다는 현상 인식으로 마무리된다.

개별적인 주장들이 모두 아주 새로운 것만은 아니지만, '공장(Factory)'이라는 일관된 관점으로 에이전트 활용을 재정렬했다는 점이 이 기사의 가치라고 느꼈다. 도구를 건네고, 병목(Bottleneck)을 옮기며, 비평가로서 품질을 보증하고, 테스트 기반 위에서 재설계를 맡긴다. 이 순서대로 자신들의 개발 플로우(Development flow)를 점검해 보면, 어디가 여전히 인간에게 의존한 채 멈춰 있는지 보일 것이다. 아직 취약하다고 명시된 기억(Memory)과 장시간 운용에 대해서는 과도한 기대를 하지 않고 설계한다는 현실적인 태도의 참고가 되기도 한다 🛠️.

출처: Benedict Brady 「Notes on the software factory」(2026년 7월 8일). 뉴스레터 『Leadership in Tech』에서 소개. 원문: https://www.benedict.dev/software-factory