Claude Code 도입 다음 단계: "소프트웨어 팩토리(Software Factory)" 패턴 분석

사내에서 Claude Code를 도입하는 일정을 분기별로 되짚어보면, 어느 시점부터는 "사람이 작업을 하나씩 지시하는" 루프 자체가 병목이 되는 순간이 온다. 핀테크 회사 Imprint의 엔지니어링 블로그 Irrational Exuberance에 올라온 글이 바로 이 지점을 다룬다. 2026년 1월에는 전 엔지니어가 매일 Claude Code를 쓰게 만들었고, 3월에는 엔지니어가 아닌 팀까지 Claude Code·Claude Cowork를 매일 쓰도록 확장했다. 4월에는 로컬 개발 환경이 저장소 단위의 체크아웃(checkout, 원격 저장소 코드를 로컬로 내려받는 작업) 구조 때문에 병목이 걸려서, 리포지토리가 아니라 워크스페이스 단위로 작업하는 구조로 바꿨다. 각 워크스페이스는 프론트엔드·백엔드·인프라·데이터 모노레포 전체를 독립적으로 체크아웃해 두고 있어서, 리포지토리를 넘나드는 PR(Pull Request)을 한 번에 만들 수 있다. 6월에는 작업 관리 도구가 Jira에서 Linear로 완전히 이전됐다. 에이전트가 작업을 스스로 발견하고 처리하려면 가시성이 높고 권한 구조가 단순한 티켓 시스템이 필요했기 때문이다. 7월에는 Stripe의 사내 에이전트 오케스트레이션 사례인 "Minions"를 참고해 "Agent Fleet"이라는 자체 오케스트레이션 하네스(harness, 에이전트의 실행 환경과 작업 흐름을 감싸는 상위 제어 장치)를 만들었다.

이 글에서 저자가 최근 적용해본 것이 바로 "소프트웨어 팩토리(Software Factory)" 패턴이다. 이 용어의 AI 맥락에서의 정확한 기원은 다소 불분명하지만, 저자는 2026년 2월 Justin McCarthy가 쓴 "Software Factories And The Agentic Moment"라는 글에서 처음 등장했을 가능성이 크다고 언급한다.

기술 개요 & 등장 배경

기존의 에이전트 활용 방식은 사람이 작업 하나를 정의하고, 에이전트가 그 작업을 끝내면 사람이 다시 다음 작업을 정의하는 식이었다. 이 방식은 작업 단위가 작을 때는 괜찮지만, 처리해야 할 티켓이 수십 개로 늘어나면 "다음에 뭘 시킬지"를 사람이 계속 결정해야 하는 구조 자체가 한계가 된다. 소프트웨어 팩토리 패턴은 이 결정 지점을 없애는 접근이다. 사람은 더 이상 개별 작업을 지시하지 않고, 넓은 범위의 목표(goal) 하나만 던져준다. 그 다음부터는 하네스가 그 목표를 향해 계속 반복(loop)하면서 진행 상황을 스스로 판단하고 다음 작업을 골라 처리한다. 즉 작업 단위의 위임이 아니라 목표 단위의 위임으로 올라간 것이다.

핵심 개념 & 동작 원리

Imprint가 처음 구현한 버전은 /linear-project-loop라는 에이전트 스킬(skill, 특정 작업 절차를 정의해둔 재사용 가능한 명령 단위)이다. Linear(이슈 트래커)의 프로젝트 하나를 읽어들여서 아래 흐름으로 동작한다.

[1] 목표 정의 점검
    Linear 프로젝트 → RFC(Notion 문서: 목표/측정 방법/접근법) 있는가?
                    → Datadog 대시보드 또는 Snowflake 쿼리(진행률 측정) 있는가?
    없으면 → 사용자와 함께 채워 넣고 나서 진행

[2] 상태 동기화
    메트릭 + 이슈 현황 리뷰 → 새 작업 발견 시 이슈 추가
                            → 상태 바뀐 이슈 업데이트

[3] 작업 수행
    블로킹되지 않은 작업 선택 → PR 작성 / PR 업데이트
                              → 리뷰 요청 / 명확화 질문

[4] 완료 후 분기
    작업 완료 → 프로젝트 설명이 최신 상태면 → 다음 작업으로 [3] 재진입
             → 설명이 오래됐으면 → [1]로 되돌아가 전체 루프 재시작

핵심은 1단계의 "목표 정의 점검"이다. 목표가 측정 가능한 형태(RFC + 대시보드/쿼리)로 존재하지 않으면 에이전트가 바로 작업에 들어가지 않고, 먼저 그 토대를 사용자와 함께 만든다. 이 전제가 없으면 루프가 "뭘 향해 반복하는지" 자체를 잃어버리기 때문이다. 저자는 현재 이 루프를 로컬 하네스에서 직접 돌려보는 단계라고 밝혔고, 더 큰 규모의 운영 결과는 아직 공개하지 않았다.

Trade-off 분석

항목	작업 단위 위임	목표 단위 위임 (소프트웨어 팩토리)
사람의 개입 빈도	작업마다 지시 필요	목표 설정 시점에만 집중, 이후 저빈도
초기 준비 비용	낮음 (바로 지시 가능)	높음 (RFC, 대시보드/쿼리를 먼저 갖춰야 함)
운영 부담	작업 큐 관리는 사람이 계속 담당	작업 큐 관리는 하네스가 흡수, 다만 루프 감시 필요
조직 전제조건	기존 이슈 트래커로도 가능	가시성 높고 권한 구조가 단순한 트래커(Imprint는 Jira→Linear 전환) 필요
확장성	작업량 늘면 사람이 비례해서 늘어야 함	워크스페이스/플릿 단위로 수평 확장 가능 (Imprint의 로컬 워크스페이스·Agent Fleet)

목표 단위 위임은 사람의 반복적 개입을 줄이는 대신, 그 개입을 "목표를 측정 가능하게 정의하는 작업"으로 앞당긴다. RFC와 대시보드를 미리 갖추지 않은 조직이라면, 루프를 돌리기 전에 그 준비 과정 자체가 새로운 작업량이 된다는 점을 감안해야 한다.

백엔드/AI 에이전트 시스템 적용 시 고려사항

이 패턴을 자체 시스템에 적용하려면 몇 가지 지점을 먼저 점검해야 한다.

• "프로젝트 설명이 최신인가"를 판단하는 기준. 글에 나온 루프는 완료 후 분기 지점에서 이 판단에 따라 다음 작업을 바로 잡을지, 1단계부터 다시 돌지를 정한다. 이 판단 로직이 불명확하면 루프가 불필요하게 전체를 재시작하거나, 반대로 목표가 바뀐 걸 못 감지하고 낡은 목표를 계속 향해 작업하게 된다.
• 목표 측정 인프라에 대한 의존. 루프 1단계는 Notion RFC와 Datadog/Snowflake 측정 체계가 이미 연결돼 있다는 전제로 설계됐다. 사내에 해당 도구 조합이 없거나 접근 권한이 분산돼 있다면, 이 전제를 그대로 옮겨 쓸 수 없고 자체 측정 체계부터 맞춰야 한다.
• 이슈 트래커의 권한 복잡도. Imprint가 6월에 Jira를 접고 Linear로 전면 이전한 이유가 바로 "권한 복잡도가 낮고 가시성이 높은" 트래커가 필요했기 때문이다. 에이전트가 이슈를 스스로 만들고 상태를 바꾸는 구조에서는, 세분화된 권한 체계가 오히려 에이전트의 작업 범위를 예측 불가능하게 만들 수 있다.
• 크로스 리포지토리 작업 범위. 워크스페이스 단위로 프론트엔드·백엔드·인프라·데이터 모노레포를 동시에 열어두는 구조는, 저장소 하나만 보던 기존 CI/리뷰 프로세스와 충돌할 수 있다. 크로스 레포 PR을 리뷰하고 머지하는 책임 소재를 먼저 정리해야 한다.
• 루프의 자기 증식 위험. 2단계에서 "새 작업이 발견되면 이슈를 추가"하는 구조는, 목표 정의가 느슨하면 불필요한 이슈가 계속 늘어나는 쪽으로도 작동할 수 있다. 저자도 이 구현을 아직 로컬 하네스에서 검증하는 초기 단계라고 밝힌 만큼, 운영 규모로 확장하기 전에 이슈 생성 빈도와 품질을 사람이 주기적으로 샘플링해 확인하는 절차가 필요하다.

---

개인 고찰 & 엔지니어링 관점의 시사점

AI 코딩 도구를 서비스 개발에 도입해 본 개발자라면 누구나 "결국 인간이 Next Action을 계속 지시해야 하는 병목"을 경험해 보았을 것이다. 프롬프트를 정교하게 짜서 하나의 PR을 생성하는 것까지는 쉽지만, 프로젝트 전체의 완료까지 수십 개의 티켓을 매번 사람이 분개하고 지시하는 구조는 사람의 정신적 피로도(Cognitive Load)를 높인다.

Imprint의 '소프트웨어 팩토리' 실험은 이 병목을 풀기 위해 인간의 역할을 'Task 관리자'에서 'System Goal & Spec 정의자'로 올리는 접근을 보여준다. 이 시도에서 얻을 수 있는 주요 엔지니어링 시사점은 다음과 같다.

• 에이전트 성능의 선결 조건은 '측정 가능한 목표(Measurable Goal)': 에이전트가 인간의 개입 없이 자율 루프를 돌려면, "어디까지 구현했는가"를 측정할 수 있는 수치적/문서적 기준(RFC, Datadog Metric, DB Query)이 먼저 갖춰져야 한다. 측정 체계가 부실한 상태에서 목표 단위 위임을 시도하면 에이전트는 무한 환각 루프에 빠진다.
• 에이전트 친화적 인프라(Agent-Native Infrastructure)로의 전환: 에이전트가 효과적으로 작동하려면 코드베이스와 개발 도구 자체도 에이전트 친화적으로 개편되어야 한다. 복잡한 권한 구조의 Jira 대신 가시성이 높은 Linear로 옮기고, 단일 레포 체크아웃에서 크로스 레포 작업이 가능한 독립 워크스페이스(Workspace) 구조로 전환한 것이 대표적이다.
• 하네스(Harness)단에서의 루프 제어 및 가드레일: 목표 단위 자율 루프는 에이전트가 스스로 새로운 이슈를 생성하고 수정하는 '자기 증식' 특성을 가진다. 따라서 하네스 단에서 루프 재시작 조건, 이슈 생성 권한 범위, PR 단위 테스트 자동화 등의 가드레일을 철저히 설계해야만 가짜 작업이 불어나는 현상을 막을 수 있다.

---

참고 자료

• 원문: Trying the Software Factory pattern – Irrational Exuberance
• Claude Code 공식 문서 개요 — 글에서 반복적으로 언급되는 로컬 에이전트 하네스의 기반 도구
• Linear Docs: Projects — Imprint가 작업 가시성 확보를 위해 전면 이전한 이슈 트래커의 프로젝트 기능 문서