소프트웨어 팩토리 패턴 시도하기
요약
본 글은 에이전트에게 개별 티켓을 처리하는 방식에서 벗어나, 프로젝트의 목표와 지표를 지속적으로 확인하며 필요한 작업을 스스로 찾아 수행하는 '소프트웨어 팩토리' 패턴을 소개합니다. 이 패턴은 단순히 작업 완료를 넘어, 목표 달성 여부와 누락된 작업을 판단하여 개발 프로세스 전체를 관리할 수 있게 합니다.
핵심 포인트
- 프로젝트 목표와 지표를 기반으로 에이전트가 자율적으로 작업을 수행하는 '소프트웨어 팩토리' 패턴을 실험 중입니다.
- 에이전트는 Notion RFC, Datadog 대시보드 등을 통해 프로젝트의 목표와 진척도를 확인합니다.
- 단순 티켓 처리를 넘어, 지표를 바탕으로 필요한 작업 추가 및 PR 작성/수정까지 수행할 수 있습니다.
- 이 시스템은 사람이 머릿속에만 갖고 있던 '목표'와 '측정 기준'을 에이전트에게 공유하는 것이 핵심입니다.
- 에이전트에게 개별 티켓을 맡기는 대신,
프로젝트 목표와 지표를 확인하며 필요한 작업을 찾아 수행하는 ‘소프트웨어 팩토리’ 를 실험 중임
/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을 도입함 -
다음 실험인
소프트웨어 팩토리 패턴은 큰 목표를 주고, 에이전트 실행 시스템이 목표를 향해 작업을 반복하도록 하는 방식임
목표를 확인하고 다음 작업을 수행하는 루프
- 첫 구현인
/linear-project-loop
는 Linear 프로젝트를 읽고 다음 두 가지부터 확인함
목표 정의: Notion RFC에 프로젝트 목표, 측정 방법과 전반적인 접근 방식이 있는지 확인함
진척 측정: Datadog 대시보드나 Snowflake 쿼리로 목표 대비 진척을 확인할 수 있는지 점검함
-
필요한 문서와 도구가 없거나 프로젝트 자체가 없으면 사용자와 함께 만듦
-
이어
지표와 이슈 상태를 검토함 -
새로 필요한 작업을 발견하면 프로젝트에 추가하고, 진행 상황이 바뀐 이슈의 상태를 갱신함
-
현재 상태를 바탕으로
진행 가능한 작업을 수행함 -
PR 작성·수정, 리뷰 요청과 확인 질문 등이 포함됨
-
작업을 끝내면 프로젝트 설명의 최신 여부에 따라 다음 단계를 정함
-
설명이 최신이면 다음 작업을 맡음
-
갱신된 지 오래됐다면 목표와 지표를 확인하는 첫 단계부터 다시 시작함
-
현재는 로컬에서 실행 중이며, 일회성 작업을 맡기는 기존
Agent Fleet으로 옮길 예정임
사람이 머릿속에만 갖고 있던 목표를 공유하기
-
이전에도 에이전트에게 특정 Linear 프로젝트를 계속 진행하도록 요청했지만,
목표에 관한 맥락 일부는 사람만 알고 있었음 -
에이전트는 티켓을 처리할 수 있어도 올바른 방향으로 가는지, 필요한 작업이 빠졌는지 평가할 수 없었음
-
목표와 측정 수단을 연결하면
작업 완료와 목표 달성을 구분할 수 있음 -
다음 티켓을 처리하는 데 그치지 않고, 현재 지표를 바탕으로 필요한 일을 다시 판단할 수 있게 됨
출시 후 점검에도 같은 방식을 활용할 수 있음
- 올해 초 출시한 패스키 기능은 몇 달 동안 상태를 확인하지 않는 경우가 있었음
- 낮은 빈도로 루프를 실행하면 도입률 급증이나 오류율 변화를 놓치지 않을 수 있음
측정 도구, 작업 상태와 실행 환경이 함께 필요함
-
각 구성 요소의 효과는
다른 기반이 함께 갖춰져 있을 때 쌓임
목표 측정: Datadog MCP와 Snowflake 접근 권한으로 지표를 확인함
공통 작업 상태: Linear를 회사 전체 작업 상태의 단일 기준으로 사용함
독립적인 실행 환경: 사용자의 노트북 없이도 작업을 수행할 에이전트 실행·조율 시스템을 갖춤 -
새로운 스킬 하나를 추가하는 것만으로 완성되는 방식은 아님
-
도구, 작업 관리와 실행 환경을 연결하기 위해 여러 마이그레이션을 연이어 수행해야 함
댓글과 토론
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기