실제로 작동하는 소프트웨어 팩토리를 구축했습니다. 그 과정에서 배운 점들을 공유합니다.

소프트웨어 팩토리가 지난 몇 주 동안 엄청난 인기를 끌고 있습니다. 그래서 저도 하나 만들어 봤습니다.

여기에서 제가 배운 점, 작동 방식, 그리고 오후 한나절에 하나를 구축하는 방법을 소개합니다.

나의 목표

정말 간단하고, 그냥 작동하기만 하면서 많은 관리가 필요하지 않아야 했습니다. 이상적으로는 기존 Claude 구독으로 완전히 실행될 수 있어야 했습니다.

순진하게 들릴 수 있지만, 기본적으로 기존 워크플로우에 쉽게 통합되지 않으면 오래 사용하지 않게 될 것입니다. 이 새로운 시스템을 사용하기 위해 모든 기존 습관을 바꿔야 하는 것을 원하지 않습니다. 경험상 그렇게 되면 장기적으로 작동하지 않아 무의미해질 것입니다.

그래서 하나의 큰 작업으로 접근하는 대신, 두 가지 별개의 단계로 나누었습니다.

1. 사전 분류 - 할 일을 파악하기
2. 구현 - 실제로 일을 수행하기

중심에는 Linear가 있으며, 수행해야 할 작업의 진실 공급원 역할을 합니다.

모든 소프트웨어 팩토리는 GitHub Issues, Linear 또는 다른 것이든 수행할 작업의 중앙 집중식 저장소가 필요합니다. 이미 사용 중인 것이어야 어떤 시스템이든 에이전트나 인간이 나중에 가져가서 완료할 작업을 쉽게 추가할 수 있습니다.

시스템 상태 확인 루프를 통해 자동 생성된 이슈가 있는 Linear

파이프라인에는 소프트웨어 팩토리 구축 과정을 실제로 관리 가능하게 만드는 의도적으로 정의된 분할 지점이 있습니다.

1. 작업 생성 (MCP를 사용한 루프)
2. 작업 저장 (Linear)
3. 작업 완료 (SDLC 에이전트)

분할함으로써 사전 분류와 구현 측면을 한 번에 구축할 필요가 없습니다 (실제로 과도한 엔지니어링을 피하기 위해 권장하지 않습니다). Linear는 '할 일'과 현재 '하고 있는 일' 사이의 인터페이스를 잘 정의하고 확장하기 쉽게 만듭니다.

사전 분류 단계

위 다이어그램에서 작업은 왼쪽에서 오른쪽으로 진행됩니다. 왼쪽은 작업이 생성되는 곳이며, 수행해야 할 작업에 추가하는 여러 시스템(인간, 에이전트 또는 API)이 포함됩니다. 이 사전 분류 단계에서 생성된 모든 출력은 Linear에 저장됩니다.

Claude 클라우드 환경에서 실행되는 몇 가지 루프

이 단계에는 세 가지 주요 루프가 있습니다.

1. 시스템 상태 확인 루프 (버그 파인더) - 이 루프는 매일 오전 5시에 실행되며 여러 MCP 서버에 연결됩니다: 오류 추적을 위한 Posthog, 시스템 진단을 위한 Vercel, 이슈 생성을 위한 Linear.
2. UX 개선 및 고객 피드백 루프 - 이 루프는 매주 월요일 오전 9시에 실행되며, 모든 새로운 피드백, Intercom/Fin의 모든 고객 지원 채팅, 그리고 모든 Posthog 세션 재생을 스캔합니다. 세션 재생은 금광입니다. 분노 클릭이 발생하는 곳이나 사용자가 어려움을 겪고 혼란스러워하는 곳을 볼 수 있습니다.
3. 이탈 분석 루프 - 매일 오전 6시에 실행되며 지난 24시간 동안 취소를 클릭한 모든 고객을 조사합니다. Stripe에서 결제 및 사용자 데이터(이메일/위치 포함)를 가져온 다음, Posthog에서 해당 고객의 세션 재생을 확인하여 취소 전에 무엇을 하고 있었는지 봅니다. Supabase에서 사용량을 가져와 잘못된 ICP였는지, '와우' 순간을 경험하지 못했는지, 또는 버그를 만났는지 확인합니다. 보고서는 Slack에 전송되며, 에이전트는 고객 이탈과 관련된 이슈가 있으면 이슈를 생성하거나 댓글을 달아 우선순위를 높입니다.

이러한 에이전트를 일관되게 실행하기 위해, 간단하게 유지하고 Claude Code Cloud Routines를 사용했습니다.

Hetzner VPS나 카페인이 든 Mac mini 등으로 과도하게 엔지니어링하지 않았습니다. 기존 Claude Code 구독을 활용하고, 일정 또는 웹훅 이벤트를 통해 트리거할 수 있는 항상 켜져 있는 에이전트를 만드는 가장 쉬운 방법입니다. '벤더 종속은 어쩌고!'라고 말하는 사람들에게 - 이것은 말 그대로 텍스트일 뿐입니다. 프롬프트를 원하는 곳에 자유롭게 복사하세요. 저는 설정하기 가장 쉽고 저렴하면서 신뢰할 수 있게 작동하는 것을 원했을 뿐입니다.

Claude Code Cloud Routines를 사용하는 또 다른 이유는 Anthropic의 클라우드 환경이 로컬에서 실행되는 Claude와 거의 동등하기 때문입니다.

Cloud Claude Routines

물론 환경 변수는 포함되어 있지 않지만(필요하면 클라우드 환경 설정에 추가할 수 있음), Desktop App의 커넥터를 통해 MCP 연결을 설정하면 Codex와 달리 로컬 Claude CLI와 원격 Claude 모두 사용할 수 있습니다. 이것이 저에게 가장 중요한 기능이었으며, 이러한 사전 분류 에이전트 루프가 잘 작동하는 이유입니다. 또한 노트북 메모리를 걱정하지 않고 여러 세션을 병렬로 실행할 수 있습니다.

이 사전 분류 단계만 구현해도, 작업이 완료되는 다음 단계를 구축하지 않더라도 많은 이점을 얻을 수 있습니다.

단일 루프로 작게 시작하고, 시도해보고, 개선한 다음, 더 추가하세요. 오늘 만들 수 있는 루틴이 무엇인지 파악하여 기존 이슈 트래커에 새롭고 고품질의 작업을 넣은 다음, 현재 구현을 위해 하고 있는 일을 그대로 수행하세요.

구현 단계

2단계의 가장 기본적인 버전은 에이전트에 이슈 ID를 제공하고 완료하라고 말하는 것입니다. 이것이 대부분의 사람들이 에이전트와 작업할 때 이미 하는 일이지만, 이 글을 읽고 있다면 원하는 것이 아닐 가능성이 높습니다. 왜냐하면 이제 루프의 병목이 되어 세션에서 직접 에이전트를 시작하기 때문입니다.

대신 제가 한 것은 Linear에서 직접 원격 Claude Code 세션을 트리거하는 방법을 구축한 것입니다.

Linear 이슈에서 Claude로 이동

작동 방식은 다음과 같습니다.

1. 먼저, 새 Claude 세션을 트리거하는 방법을 결정합니다. 저희의 경우, 새 작업을 시작하는 Linear 이슈에 'auto' 레이블을 추가합니다.
2. 그런 다음, Linear는 내부 웹훅 API 서비스(새로 생성된 내부 Hono 앱)로 웹훅 이벤트를 보내고, 이 서비스는 이벤트를 파싱한 후 올바른 정보를 Claude Routine으로 전달합니다.
3. 마지막으로, 이 경량 API 서비스는 Anthropic에 POST 요청을 보내 초기 프롬프트로 Claude Routine을 트리거합니다.

트리거로 'auto' 레이블을 사용하면 새 Claude 세션의 자동 실행을 제어할 수 있습니다.

기본적으로 사전 분류 단계에는 이러한 'auto' 레이블이 포함되지 않으며, 인간이 에이전트가 작업을 시작하도록 트리거하는 레이블을 추가해야 합니다(인간-인-더-루프 유지). 이것이 1단계를 사전 분류 단계라고 부르는 이유입니다. 인간의 개입이나 에이전트가 루프를 돌며 새 이슈가 추가되는 것을 감시하고 새 구현 세션을 시작하는 등 어떤 것이 실제로 작업할 내용을 여전히 파악하고 있기 때문입니다.

그러나 레이블 추가는 에이전트도 쉽게 할 수 있기 때문에, 사전 분류 루프가 기본적으로 'auto' 레이블이 있는 새 이슈를 생성하도록 할 수 있으며, 그러면 새 Claude 세션이 시작됩니다. 레이블을 사용하는 것은 에이전트나 인간이 자동으로 새 구현 작업을 시작하는 매우 유연한 방법이 됩니다.

Claude 세션을 시작하는 경량 라우팅 서비스

Linear가 웹훅을 지원하기 때문에 '레이블이 추가되면 푸시' 방식이 작동합니다. 유일한 단점은 이러한 웹훅을 수락하고 이벤트와 페이로드 데이터를 형식화하여 Claude Code를 트리거하는 라우팅 API가 필요하다는 것입니다. 이 새 서비스는 올바른 인증 헤더도 추가하므로 Linear가 직접 루틴을 트리거할 수 없습니다.

또는 일정한 간격으로 시작하여 'auto' 레이블이 있지만 진행 중이 아닌 새 이슈를 구현하려고 시도하는 예약된 루틴을 가질 수도 있습니다.

실제 루틴 프롬프트의 경우, 전체 SDLC를 안내하는 재사용 가능한 스킬을 구축하는 것을 권장합니다. 이름은 /implement 또는 /do와 같은 것으로, "/do ISSUE-NNN"이라고만 말하면 되도록 만듭니다. 이 스킬은 이슈 컨텍스트 가져오기, 작업 구현, 브라우저에서 확인, PR 생성, 댓글 모니터링의 단계를 올바르게 수행하는 방법을 문서화합니다.

그러면 Linear 이벤트에 의해 트리거되는 Claude 루틴 프롬프트는 매우 간단한 프롬프트만 있으면 됩니다. 제 것은 다음과 같습니다.

제공된 이슈를 검색하고 /do 스킬을 사용하여 요청된 변경 사항을 구현하고 풀 리퀘스트를 생성하세요. 정확히 제공된 이슈만 가져오세요. 이미 완료되었거나 진행 중이면 중단하세요.

이슈 참조는 이 메시지에 나타나지 않습니다. 이 메시지 바로 다음에 같은 세션에서 전송되는 \<routine-fire-payload>\ 태그로 감싸진 별도의 후속 메시지로 도착합니다. 이슈가 제공되었는지 결정하기 전에 해당 메시지를 기다리세요. \<routine-fire-payload>\ 메시지에서 확인한 후 참조된 이슈가 실제로 존재하지 않음을 확인한 경우에만 이슈가 존재하지 않거나 제공되지 않았다고 결론 내리세요.

작업을 시작할 때 이슈에 댓글을 달고, 상태를 'In Progress'로 설정하고, 진행하면서 의미 있는 내용으로 이슈를 업데이트하세요. 항상 Linear 이슈 댓글 앞에 [Claude]를 접두사로 붙이세요.

따라서 이 시점에서 API를 통해 트리거된 병렬 Claude Remotion 세션이 있으며, 이슈를 구현하고, PR을 열고 (바라건대 Playwright 또는 Agent Browser를 통해 작업을 확인합니다).

본질적으로 완전히 관찰 가능하고, 사용자가 자는 동안 실행되며, 전적으로 Claude Code 구독으로 작동하는 완전한 소프트웨어 팩토리입니다.