목표를 반복해서 하네스가 밀고 가게 한다, Will Larson이 Imprint에서 시도한 소프트웨어 팩토리 패턴

TL;DR

• Will Larson은 2026년 AI 생태계에서 효과적인 패턴이 도입 속도보다 빨리 나온다고 말하며, Imprint의 도입 순서를 1월부터 7월까지 다섯 단계로 적는다. 이번 글은 그 뒤에 온 소프트웨어 팩토리 패턴의 첫 구현이다.
• 그가 정의하는 패턴은 넓은 목표를 반복하고 하네스가 그 목표를 향한 진행을 이끄는 것이다. 구현은 /linear-project-loop라는 에이전트 스킬 하나이며 아직 기본적인 수준이라고 그가 밝힌다.
• 스킬은 Linear 프로젝트를 읽고 목표 정의를 점검하는 것으로 시작한다. RFC와 측정 수단(대시보드나 쿼리)이 없으면 사람과 함께 먼저 만든다. 그 뒤 지표와 이슈를 검토하고, 새 작업을 이슈로 추가하고, 막히지 않은 작업을 진행하는 순서를 반복한다.
• 그가 꼽은 장점은 프로젝트 목표에 관한 상태를 자기만 쥐고 있던 부분이 드러난다는 점, 그리고 출시 뒤 프로젝트를 느슨한 주기로 점검할 수 있다는 점이다. 이 글에는 성과 수치가 없다.

도입 순서와 글의 맥락

글은 짧다. 글쓴이는 새 패턴이 빨리 나와서 한 달 뒤 네댓 개를 놓쳤음을 깨닫곤 한다고 말한다. Imprint의 올해 도입 과정은 이렇게 적혀 있다. 1월에는 모든 엔지니어가 매일 Claude Code를 쓰게 했고 3월에는 엔지니어 아닌 사람들도 Claude Code나 Claude Cowork를 매일 쓰게 했다. 4월에는 로컬 개발이 체크아웃과 워크트리 모델에 묶이는 병목을 풀려고 모든 저장소의 독립 체크아웃을 가진 로컬 작업 공간 약 10개를 만들어 저장소 단위가 아니라 작업 공간 단위로 일하며 프런트엔드, 백엔드, 인프라, 데이터 모노레포를 가로지르는 PR을 만들게 했다.

6월에는 에이전트 주도 개발이 Jira보다 가시성이 높고 권한이 단순한 공통 작업 관리 시스템이 없어서 제약받는다고 보고 회사 전체를 Linear로 옮기고 Jira를 중단했다. 7월에는 이슈 가시성이 생기자 사소한 작업이 많다는 것, 그리고 이를 로컬 개발로 관리하는 방식이 확장되지 않는다는 것이 드러나 Stripe의 Minions와 비슷한 방향으로 오케스트레이션 하네스를 굴리기로 하고, 사내에서는 이를 Agent Fleet이라 부른다. 이 연표는 글쓴이가 한 줄씩 요약한 그의 회사 경험이다.

소프트웨어 팩토리라는 용어의 출처는 그도 확실히 짚지 못했다고 밝힌다. 가볍게 조사해 보니 AI 맥락의 기원이 모호하지만 Justin McCarthy의 2026년 2월 글 「Software Factories And The Agentic Moment」일 수 있다고 추정한다. 이 노트는 그 글을 읽지 않았고 추정 그대로 전한다.

패턴과 첫 구현

정의는 한 줄이다. 넓은 목표를 두고 루프를 돌리며 그 목표를 향한 진행을 하네스에게 맡기는 것이다. 첫 구현은 /linear-project-loop라는 에이전트 스킬이다. 이 스킬은 Linear 프로젝트를 읽고 목표 정의를 두 가지 기준으로 점검한다. 하나는 목표와 측정 방법, 접근 방식을 적은 Notion의 RFC이고 다른 하나는 목표 대비 진행을 재는 Datadog 대시보드나 Snowflake 쿼리다.

이 둘이 없거나 Linear 프로젝트 자체가 없으면 사용자와 함께 반복하며 빠진 도구를 만든다. 그다음 지표와 이슈의 상태를 검토하고 새 작업이 보이면 이슈를 프로젝트에 추가하고 움직인 이슈의 상태를 갱신한다. 막히지 않은 작업은 프로젝트의 현재 상태에 따라 진행하는데, 이는 흔히 PR을 쓰거나 고치거나 리뷰를 요청하거나 명확화 질문을 던지는 일이다. 작업 하나가 끝났을 때 프로젝트 설명이 최신이면 다음 작업을 맡고, 설명이 한동안 갱신되지 않았다면 첫 단계부터 루프를 다시 돈다. 지금은 로컬 하네스에서 실행하지만 일회성 작업을 맡기는 오케스트레이션 하네스가 이 동작을 구동하게 옮길 생각이라고 한다.

그가 꼽은 장점과 의존성

장점은 두 가지로 적혀 있다. 하나는 이 패턴이 자신이 로컬에서 일하던 방식과 매우 닮았으면서도, 프로젝트 목표에 관한 상태를 자기 혼자 쥐고 있던 부분을 깨닫게 한다는 점이다. 그는 이미 에이전트에게 특정 Linear 프로젝트를 반복시켰지만 에이전트는 올바른 방향으로 가는지, 빠진 작업이 있는지를 평가할 능력이 없었다. 이제는 있다는 것이다.

다른 하나는 출시 뒤 점검이다. 그는 올해 초 패스키 구현을 출시했고, 그 뒤 몇 달 동안 상황을 확인하지 않은 채 지나가기도 한다고 쓴다. 도입이 급증하거나 오류율이 나빠지기 시작해도 놓칠 수 있는데, 팩토리를 덜 자주 도는 출시 후 모드로 돌리면 즉시 잡힌다는 설명이다. 이는 가능성에 대한 그의 예상이며 실제로 문제를 잡아낸 사례는 글에 나오지 않는다.

마지막 생각은 조각들이 서로 맞물려야 복리로 작동한다는 것이다. 이 팩토리는 목표 추적을 위한 Datadog MCP와 Snowflake 접근, 회사 업무의 단일 상태 원천으로서의 Linear, 노트북 없이 독립적으로 일할 수 있는 오케스트레이션 하네스에 모두 기대고 있다. 그는 이렇게 많은 이전을 따라가는 것이 흥미로운 산업적 순간이라고 맺는다.

읽을 때 유의할 점

이 글은 실험 기록이며 결과 보고가 아니다. 성과 지표나 실패 사례, 비용은 나오지 않고 ‘잘 동작하는 정도’라는 그의 평가만 있다. 팩토리 패턴의 효과가 Linear 이전과 Agent Fleet 같은 선행 투자에 얼마나 기대는지도 글이 스스로 의존성이라고 인정한다. 그래서 다른 조직이 이 패턴을 따라 하려면 목표의 측정 수단이 이미 있는가가 먼저 확인할 점이다. 이 노트에서는 글이 링크한 Stripe Minions와 McCarthy의 글은 읽지 않았다.

참고 자료

Will Larson — Trying the Software Factory pattern. — 본문 전체를 읽고 정리했다. 글이 링크한 Stripe Minions와 McCarthy의 글은 읽지 않았다.