소프트웨어 팩토리 패턴 시도하기

요약

Imprint는 에이전트에게 개별 티켓 대신 프로젝트 목표와 지표를 공유하여 스스로 필요한 작업을 찾아 수행하게 하는 '소프트웨어 팩토리' 패턴을 실험하고 있습니다.
에이전트가 목표를 바탕으로 작업의 방향성을 판단하고 루프를 통해 업무를 완수하며, 이를 위해 통합된 작업 관리 시스템과 독립적인 실행 환경을 구축합니다.

에이전트에게 개별 티켓을 맡기는 대신, 프로젝트 목표와 지표를 확인하며 필요한 작업을 찾아 수행하는 ‘소프트웨어 팩토리’ 를 실험 중임
/linear-project-loop는 Linear 프로젝트를 읽고 목표·접근 방식이 담긴 문서와 진척을 측정할 대시보드·쿼리부터 확인함. 빠진 요소는 사용자와 함께 만듦
지표와 이슈 상태를 검토해 새로 필요한 작업을 추가하고, 진행 가능한 작업의 PR 작성·수정, 리뷰 요청과 확인 질문을 수행한 뒤 다음 작업으로 이어감
사람이 머릿속에만 갖고 있던 목표와 측정 기준을 공유하면, 에이전트도 올바른 방향으로 가는지와 빠진 작업이 있는지 판단할 수 있음
출시 뒤에도 낮은 빈도로 루프를 실행하면 도입률과 오류율 변화를 놓치지 않을 수 있음. 목표 측정 도구, 통합된 작업 관리와 노트북 없이 실행할 환경이 함께 필요함

AI 도구 도입에서 소프트웨어 팩토리까지

Imprint는 2026년 들어 AI 도구뿐 아니라 작업 방식과 관리 체계도 연이어 바꾸고 있음
- 1월·3월: 모든 엔지니어가 매일 Claude Code를 사용하도록 하고, 이후 나머지 구성원에게도 Claude Code 또는 Claude Cowork 사용을 확대함
- 4월: 체크아웃과 worktree 방식이 병목이 되면서, 모든 저장소를 각각 독립적으로 체크아웃한 로컬 작업 공간 약 10개를 구성함. 저장소가 아니라 작업 공간 단위로 프런트엔드·백엔드·인프라·데이터 저장소를 아우르는 PR을 만들게 함
- 6월: 에이전트가 전사 작업을 파악하기 쉽고 권한 관리도 단순한 공통 시스템이 필요해, Jira에서 Linear로 이전함
- 7월: 늘어난 티켓을 로컬 개발만으로 처리하기 어려워져, Stripe의 Minions와 유사한 에이전트 실행·조율 시스템 Agent Fleet을 도입함
다음 실험인 소프트웨어 팩토리 패턴은 큰 목표를 주고, 에이전트 실행 시스템이 목표를 향해 작업을 반복하도록 하는 방식임
- AI 분야에서 이 용어의 기원은 명확하지 않지만, 관련 글로 Justin McCarthy의 Software Factories And The Agentic Moment가 있음

목표를 확인하고 다음 작업을 수행하는 루프

첫 구현인 /linear-project-loop 는 Linear 프로젝트를 읽고 다음 두 가지부터 확인함
- 목표 정의: Notion RFC에 프로젝트 목표, 측정 방법과 전반적인 접근 방식이 있는지 확인함
- 진척 측정: Datadog 대시보드나 Snowflake 쿼리로 목표 대비 진척을 확인할 수 있는지 점검함
- 필요한 문서와 도구가 없거나 프로젝트 자체가 없으면 사용자와 함께 만듦
이어 지표와 이슈 상태를 검토함
- 새로 필요한 작업을 발견하면 프로젝트에 추가하고, 진행 상황이 바뀐 이슈의 상태를 갱신함
현재 상태를 바탕으로 진행 가능한 작업을 수행함
- PR 작성·수정, 리뷰 요청과 확인 질문 등이 포함됨
작업을 끝내면 프로젝트 설명의 최신 여부에 따라 다음 단계를 정함
- 설명이 최신이면 다음 작업을 맡음
- 갱신된 지 오래됐다면 목표와 지표를 확인하는 첫 단계부터 다시 시작함
현재는 로컬에서 실행 중이며, 일회성 작업을 맡기는 기존 Agent Fleet으로 옮길 예정임

사람이 머릿속에만 갖고 있던 목표를 공유하기

이전에도 에이전트에게 특정 Linear 프로젝트를 계속 진행하도록 요청했지만, 목표에 관한 맥락 일부는 사람만 알고 있었음
- 에이전트는 티켓을 처리할 수 있어도 올바른 방향으로 가는지, 필요한 작업이 빠졌는지 평가할 수 없었음
목표와 측정 수단을 연결하면 작업 완료와 목표 달성을 구분할 수 있음
- 다음 티켓을 처리하는 데 그치지 않고, 현재 지표를 바탕으로 필요한 일을 다시 판단할 수 있게 됨
출시 후 점검에도 같은 방식을 활용할 수 있음
- 올해 초 출시한 패스키 기능은 몇 달 동안 상태를 확인하지 않는 경우가 있었음
- 낮은 빈도로 루프를 실행하면 도입률 급증이나 오류율 변화를 놓치지 않을 수 있음

측정 도구, 작업 상태와 실행 환경이 함께 필요함

각 구성 요소의 효과는 다른 기반이 함께 갖춰져 있을 때 쌓임
- 목표 측정: Datadog MCP와 Snowflake 접근 권한으로 지표를 확인함
- 공통 작업 상태: Linear를 회사 전체 작업 상태의 단일 기준으로 사용함
- 독립적인 실행 환경: 사용자의 노트북 없이도 작업을 수행할 에이전트 실행·조율 시스템을 갖춤
새로운 스킬 하나를 추가하는 것만으로 완성되는 방식은 아님
- 도구, 작업 관리와 실행 환경을 연결하기 위해 여러 마이그레이션을 연이어 수행해야 함