Agentic factory는 단순히 “코드를 잘 써주는 에이전트”가 아닙니다. 소프트웨어 생산 시스템 전체를 에이전트 중심으로 다시 설계한 공장에 가깝습니다. Ona는 소프트웨어 개발을 계획·조정·실행·검증·통합·릴리스가 이어지는 하나의 생산 시스템으로 봐야 한다고 말합니다.
이것이 더 이상 몇몇 과장된 비전 문서에만 머무는 이야기가 아니라는 것입니다. Spotify는 1,500개 이상의 AI 생성 PR을 병합했다고 공개했고, OpenAI는 사람이 직접 코드를 쓰지 않는 방식으로 약 100만 줄의 코드와 1,500개의 PR 규모를 다뤘다고 설명합니다. Cursor는 장시간 실행 에이전트와 다수의 에이전트를 조율하는 구조를 실험하고 있고, StrongDM은 인간 리뷰 없이 시나리오 기반 검증으로 수렴하는 factory를 공개적으로 소개했습니다. 즉, agentic factory는 아직 초기이지만, 이미 여러 회사가 각기 다른 형태로 실험을 시작한 상태입니다.
첫째, 무게중심이 foreground coding에서 background production으로 이동하고 있습니다. Ramp와 background-agents.com이 공통적으로 강조하는 것은, 에이전트가 충분히 유용해지는 순간 더 이상 로컬 IDE 보조 도구에 머물 수 없다는 점입니다. 샌드박스 실행, 거버넌스, 컨텍스트 연결성, agent fleet orchestration 같은 운영 인프라가 필요해집니다. Cursor는 장시간 실행 에이전트를 전제로 시스템을 설계하고 있고, OpenAI 역시 Codex가 여러 시간 동안 하나의 작업을 지속하는 사례를 설명합니다. 이제 에이전트는 “옆에서 도와주는 IDE 기능”이라기보다, 백그라운드에서 계속 일하는 작업자에 더 가까워지고 있습니다.
둘째, 생산 단위가 채팅 턴이 아니라 PR로 바뀌고 있습니다. Spotify의 시스템은 코드 변경을 자동으로 PR로 열고, Stripe의 Minions도 작업이 끝나면 브랜치를 만들고 CI를 거쳐 PR을 준비합니다. OpenAI 역시 사람이 프롬프트로 작업을 던지면 에이전트가 PR을 열고, 피드백을 반영해 머지까지 이어지는 흐름을 설명합니다. 다시 말해 agentic factory의 출력물은 답변 텍스트가 아니라, 검증 가능하고 통합 가능한 변경 단위인 PR입니다.
셋째, 컨텍스트는 더 이상 Slack이나 사람 머릿속에 머물러서는 안 되고, repo 안으로 들어와야 합니다. OpenAI는 거대한 단일 AGENTS.md보다, 짧은 목차 역할의 AGENTS.md와 구조화된 docs/ 디렉터리를 system of record로 두는 방식을 설명합니다. Spotify도 더 큰 정적 프롬프트를 선호하는 이유로 버전 관리, 테스트, 평가 가능성을 듭니다. Ona 역시 자율성이 커질수록 파일 단위 힌트만으로는 부족하고, 이슈·설계 문서·아키텍처 결정·요구사항 같은 상위 맥락이 필요하다고 봅니다. 결국 agentic factory의 본질은 “모델에 더 많은 토큰을 주는 것”이 아니라, 작업 맥락 자체를 기계가 읽을 수 있는 저장 형태로 바꾸는 것에 있습니다.
넷째, 자유로운 swarm보다 구조화된 orchestration이 훨씬 강합니다. Cursor는 공유 상태 파일을 통한 자율 조정 방식이 락, 경합, 혼란 때문에 빠르게 한계를 드러냈다고 설명하며, Planner–Executor–Workers–Judge 같은 역할 분리를 도입했습니다. Stripe는 blueprint를 코드로 정의된 workflow primitive로 설명하며, deterministic workflow와 agent의 유연성을 결합하려고 합니다. Spotify 역시 푸시, Slack 상호작용, 프롬프트 작성처럼 복잡한 일은 에이전트 바깥의 surrounding infrastructure가 맡도록 분리해 예측 가능성을 높였습니다. 핵심은 에이전트를 많이 돌리는 것이 아니라, 어디를 deterministic하게 고정하고 어디에만 agentic flexibility를 허용할지 설계하는 것입니다.
다섯째, 프롬프트보다 중요한 것은 검증입니다. Spotify는 가장 심각한 실패를 “CI는 통과했지만 기능적으로는 틀린 PR”로 보고 verifier loop와 LLM-as-a-judge를 도입했습니다. StrongDM은 scenario-based validation과 Digital Twin Universe를 중심에 두며 “validation replaces code review”라는 방향을 제시합니다. OpenAI도 UI, 로그, 메트릭, 트레이스를 에이전트가 직접 읽고 피드백 루프를 돌릴 수 있도록 만들어 검증 가능성을 시스템 안에 집어넣었습니다. 이 사례들을 종합하면, agentic factory의 진짜 해자는 “더 잘 코딩하는 모델”이 아니라, 더 잘 틀리게 만들고, 더 잘 잡아내는 검증 시스템입니다.
여섯째, 보안·거버넌스·에이전트 신원은 부가 기능이 아니라 코어 아키텍처입니다. background-agents.com은 agents를 시스템의 actor로 보고, 사람 기여자와 같은 수준의 identity, permissions, audit trail이 필요하다고 말합니다. Ona도 autonomy가 커질수록 zero-trust 실행 환경과 고유 agent identity, machine-to-machine authentication이 중요해진다고 설명합니다. LangChain은 샌드박스 통합에서 실행 환경을 어떻게 분리하느냐가 핵심 trade-off라고 짚습니다. 즉, 에이전트가 코드를 고치는 순간부터 문제의 성격은 개발도구가 아니라 운영체제와 보안 플랫폼의 문제로 확장됩니다.
일곱째, 이제 병목은 코드 생성이 아니라 flow efficiency입니다. Ona는 한 스테이션만 빨라져도 WIP가 쌓이고 전체 throughput이 악화된다고 설명합니다. Cursor는 중앙 integrator가 곧바로 병목이 되어 제거했다고 말하고, 100% 정확한 커밋만 매번 강제하면 전체 시스템이 직렬화되어 느려진다고 봅니다. OpenAI도 사람이 손으로 AI slop을 치우는 방식이 확장되지 않자, golden principles와 정기적인 background cleanup PR을 도입했습니다. 결국 agentic factory는 AI 문제가 아니라 산업공학 문제로 바뀝니다. WIP, 대기열, 재작업, 품질 편차, garbage collection 같은 개념이 점점 더 중요해집니다.
여덟째, 인간의 역할은 coder에서 conductor 혹은 harness engineer로 이동합니다. OpenAI는 엔지니어가 직접 코드를 쓰는 대신, 빠진 capability가 무엇인지 찾고 환경·도구·문서·가드레일을 repo 안에 계속 밀어 넣는 일을 하게 된다고 말합니다. Ona는 이를 “time between disengagements”라는 관점으로 설명하며, 인간 개입이 필요해질 때까지 에이전트가 독립적으로 일하는 시간이 길어지는 방향으로 발전한다고 봅니다. 그래서 앞으로의 좋은 엔지니어는 문법을 빨리 치는 사람이 아니라, 작업을 명세하고 acceptance criteria를 만들며, 검증 루프를 설계하고 병목을 제거하는 사람일 가능성이 큽니다.