프로젝트별 AI 에이전트 하네스: 사이드와 프로덕션

나는 사이드 프로젝트와 프로덕션 프로젝트를 동시에 굴린다. 한쪽에서는 작은 로그 도구를 짜고, 다른 쪽에서는 상용화를 준비하는 제품을 개발한다. 둘 다 AI 에이전트를 팀처럼 쓴다. 그런데 둘에 같은 셋업을 쓰려고 하면 매번 뭔가 어긋났다.

고정된 하네스의 문제

공개된 AI 코딩 하네스는 대부분 고정이다. 하네스도 고정이고 워크플로도 고정이다. 어떤 레포에든 같은 리뷰어, 같은 게이트, 같은 흐름이 붙는다. 잘 만든 셋업 하나를 모두에게 주는 방식이다. 한 종류의 프로젝트만 한다면 그걸로 충분하다.

문제는 성격이 다른 프로젝트를 여러 개 들고 있을 때 드러난다. 주말에 로그 파서를 빠르게 짜는데 커밋마다 다섯 리뷰어가 붙고 SPEC을 요구하면 손이 멈춘다. 반대로 펌웨어 제품에 리뷰어 하나만 걸려 있으면, 놓친 것이 배포된 뒤에야 보인다. 어느 쪽이든 하네스가 프로젝트와 싸운다.

사이드와 프로덕션은 워크플로가 다르다

어느 순간 내 워크플로가 사이드일 때와 프로덕션일 때 달라야 한다는 걸 알았다.

사이드 프로젝트에서 가장 중요한 건 빠른 개발이다. 품질은 그다음이다. 아이디어를 빨리 굴려 보는 게 목적이라, 두꺼운 리뷰 파이프라인은 여기서 그냥 발목을 잡는다. 리뷰어 다섯의 합의를 기다리고 있을 이유가 없다.

프로덕션 프로젝트는 반대다. 빠른 개발보다 신뢰할 수 있는 고품질 개발이 먼저다. 출시된 제품은 되돌리기 어렵다. 여기서는 게이트가 안전장치로 일한다. 나는 그 게이트를 원한다.

고정된 하네스 하나로는 이 둘을 동시에 만족시킬 수 없다. 사이드에 맞추면 프로덕션이 헐거워지고, 프로덕션에 맞추면 사이드가 과하게 잠긴다.

두 단계로도 부족하다

사실 사이드 대 프로덕션이라는 구분마저 너무 거칠다. 프로젝트마다 원하는 수준과 취향이 다르다.

어떤 프로젝트는 작업 노트를 Obsidian에 자동으로 쌓고 싶다. 어떤 프로젝트는 추가 리뷰를 codex나 antigravity 둘 중 하나에게만 맡기고 싶다. 둘 다 붙일 필요는 없다. 어떤 프로젝트는 worktree 격리를 쓰고 싶고, 어떤 프로젝트는 기본을 feature branch로 두고 싶다.

이런 선택에는 하나의 정답이 없다. 프로젝트의 리스크와 팀 모양에 따라 답이 달라진다. 고정된 번들은 이 결정을 나 대신 미리 내려 버린다. 대부분 내 프로젝트에 맞지 않는 쪽으로.

하나의 흐름, 여섯 단계

harness-maker가 표방하는 개발 흐름은 여섯 단계다. 연구에서 시작해 계획, 실행, 리뷰, 검증을 거쳐 마무리로 닫는다. 각 단계는 자기 게이트를 통과해야 다음으로 넘어간다.

프리셋이 정하는 건 이 흐름의 어디에 게이트를 얼마나 세게 거는가다. 프로덕션은 계획 앞에 SPEC 게이트가 하나 더 끼어들고 여섯 단계를 다 밟는다. 임베디드 작업에서 돌리는 스펙 기반 루프가 그것이다. 사이드는 그 게이트를 건너뛰고 가볍게 지나간다.

같은 도구, 다른 하네스

내 프로젝트 두 개가 그림을 보여 준다. log_agent는 혼자 짜는 작은 Python 로그 도구라 Side 프리셋을, spoton은 상용화를 고려하는 프로젝트라 Production 프리셋을 골랐다. 같은 나, 같은 스택인데 harness.yaml이 다른 질문에 답했더니 워크플로가 이렇게 갈린다.

차원	Side · log_agent	Production · spoton
dev_mode	task-driven	spec-driven
에이전트 모델	sonnet	opus + sonnet
활성 리뷰어	1개	5개
리뷰 grade 임계	B	A
리뷰 라운드	2회	3회
worktree scope	[execute]	[execute, plan]
교차 모델 리뷰	없음	있음 (codex 등)

어느 것도 손으로 튜닝한 값이 아니다. 각 프로젝트에서 한 번 답한 인터뷰에서 나왔고, 다시 렌더해도 재현된다. 로그 도구는 리뷰어 하나에 sonnet 하나로 빠르게 굴러간다. 상용 프로젝트는 추론 에이전트를 opus로 올리고, code·security·performance·ux·concurrency 다섯 리뷰어에 feature branch worktree, 그리고 codex·antigravity 교차 모델 리뷰까지 붙여 grade A로 잠근다.

레포를 읽고, 그 모양을 지킨다

도구는 프로젝트를 먼저 읽는다. 스택과 CI 신호를 12가지 이상 보고 10차원 인터뷰로 나머지를 잠근 뒤, 그 프로젝트에 맞는 하네스를 낸다. 제네릭 기본값을 조용히 깔지 않는다. 프로덕션 쪽에서는 리뷰어가 읽기 전용이라 코드를 직접 못 고치고, lint와 테스트 같은 기계 검사가 LLM 리뷰어 앞에서 토큰을 쓰기 전에 먼저 거른다. AI가 쓴 펌웨어 앞에 세웠던 검증 게이트와 같은 장치다. 사이드에서는 이 게이트를 얇게 깎으면 그만이다.

그리고 하네스는 프로젝트가 움직여도 그 모양을 유지한다. 에이전트든 CLAUDE.md든 손으로 고치면 @hm:user:* 마커가 그 수정을 재생성 너머로 보존한다. 메모리는 프로젝트별 패턴을 쌓고 반복되는 실패에 새 가드레일을 제안한다. 이 전부가 하나의 harness.yaml에서 Claude Code, Cursor, Codex로 각각 렌더된다.

복사가 아니라 생성

정적 템플릿은 출발점을 준다. harness-maker는 자기가 누구를 위해 만들어졌는지 아는 출발점을, 그리고 내 수정을 잃지 않고 업데이트되는 출발점을 준다. 좋은 하네스는 모두에게 같은 출발점을 주는 게 아니라 각자의 프로젝트에서 자라는 것이다.

나는 개인 마스터 셋업 하나를 유지하는 걸 그만뒀다. 사이드 프로젝트는 사이드답게 빠르게, 프로덕션 프로젝트는 프로덕션답게 단단하게 굴러간다. 사라진 건 새 레포마다 반복하던 작업이다. 지난 프로젝트의 CLAUDE.md를 복사하고, 안 맞는 리뷰어와 게이트를 쳐내던 일. 이제 인터뷰가 대신한다.

도구는 github.com/Ecro/harness-maker에 있다. 렌더 증거 전체와 재현 방법은 showcase diff에 있다.