6인 팀의 12개월간 SaaS AI 도입기: 우리의 설정과 여러분의 방식은 어떤가요?

1. 저도 이 부분이 궁금합니다. '단순 수정'보다 큰 작업은 어떻게 계획 모드에서 시작해 인간이 계획을 검토하고, AI가 빌드 및 검토한 뒤 병합하는 매끄러운 흐름을 만들 수 있을까요?

2. 지금까지는 스펙을 이슈/MR 설명에 올리고, 내부 개발 도구(workon <이슈 번호>로 MR과 워크트리를 생성하고 cd로 이동한 뒤 Claude에게 "자, 이거 해보자"라고 프롬프트 입력)를 통해 새로운 Claude 세션을 시작하는 방식으로 처리했습니다. 좀 투박하고 표준화된 팀 워크플로우로 만들기엔 공식적인 방법이 없네요.

3. 방금 CI에서 claude -p를 실행해 GitLab API(glab)로 MR에 직접 리뷰 코멘트를 다는 방식으로 전환했습니다. 현재 특화된 멀티 에이전트 역할을 수행하는 MVP를 운영 중입니다:

• Elephant: 전략적 게이트키퍼 (정말 이걸 해야 하나? 가치가 있나? 이미 해결된 문제인가, 아니면 바퀴를 재발명하는 건가?). MR을 즉시 거부하거나 하위 에이전트에게 작업을 분산함.
• Lean: 미니멀리즘에 집중 (코드를 더 줄일 수 있나?).
• Shape: 아키텍처와 스타일에 집중 (적절한가? 읽기 쉬운가? 외부 의존성을 표준 라이브러리로 대체할 수 있나?).
• Adversary: 실패 모드에 집중 (어떻게 고장 날까? 테스트가 현실적인 실패 시나리오와 예외 케이스를 잡아내는가?).
• Delivery: 배포 준비 상태에 집중 (배포를 위해 무엇이 더 바뀌어야 하나? 문서가 업데이트되었나?).
• Skeptic: 구현의 허점을 찾고 가정을 반박함.
• Arbiter: 하위 에이전트의 출력을 종합하고, 상충하는 권장 사항을 조정하며, 인간의 검토가 필요한 미해결 트레이드오프를 표시함.

4. 또한 diff 크기, 테스트 커버리지, MR 설명, Arbiter의 판정을 평가해 AI 승인만으로 병합이 가능한지 결정하는 CI 파이프라인 단계도 테스트 중입니다.

5. 도구라는 게 하네스를 의미하는 건가요? 저희는 아무것도 강제하지 않았지만, 약 1년 후 거의 모두가 Claude Code로 넘어왔습니다. 대부분 IDE 안에서 실행하고, 저는 개인적으로 터미널을 6개로 쪼개서 씁니다.

6. 다른 정보들은 다른 파일로 관리합니다:

• 조직 전체 CLAUDE.md: 꽤 간소한 기준 (claude.ai 조직 설정에 묻혀 있어 업데이트하기 귀찮음).
• 레포 수준 CLAUDE.md: 프로젝트 규칙, 도구, 사용 명령어. 지난 몇 년간 수천 개의 인간 리뷰 코멘트에서 추출한 보편적인 규칙들이 담겨 있음.
• 디렉토리 수준 설정: 언어별 주의사항과 선호 라이브러리를 다루는 하위 디렉토리 파일들.
• ~/.claude/CLAUDE.md: 제 개인적인 워크플로우 지침과 까다로운 요구사항.
• designing-with-types.md: CLAUDE.md에서 직접 참조함 (Scott Wlaschin의 F# 시리즈를 각색). 품질 면에서 정말 큰 도움이 됐습니다. 이게 없으면 모델들(특히 파이썬)은 처음부터 만들 때 def foo(bar: list[dict[str, Any]]) -> list[tuple[str, Any]] 같은 쓰레기 코드를 생산하곤 하니까요.

7. GitLab 기여 분석을 지켜보고 있고, 인간의 리뷰가 필요할 때 Slack으로 사람들을 호출하는 '리뷰 재촉' 봇 같은 자동화 워크플로우도 몇 개 있습니다. 그 외에는 딱히 없습니다. 코드 리뷰가 예전보다 훨씬 더 큰 병목 현상이 되었다는 건 확실히 확인했습니다.

8. 제한적인 테스트였고, 결과는 완전히 쓰레기였습니다. 물론 3번과 5번에서 설명한 설정 이전의 이야기지만요.

9. 그건 정말 좋은 질문인데 저도 답을 모르겠네요.

편집: 잘못된 위치에 있던 문장을 옮겼습니다.
편집: 번호 매기기가 엉망이네요, 레딧 에디터가 구려서요.

좋은 내용이네요! 멀티 에이전트 파이프라인은 어떻게 추적하시나요? 어떤 에이전트가 무엇을 작업 중인지, 언제 어떤 에이전트에게 작업을 보낼지 같은 것들을요... 시각화해서 보시나요?

저는 이런 방식에 대해 일종의 맞춤형 임시 접근 방식을 사용 중입니다(agents.md에 간단한 지침을 넣어 최종 변경 사항을 다양한 초점을 가진 리뷰 에이전트 시리즈에 통과시킴). 그 결과들을 github 이슈로 보내고, 오케스트레이터에게 보내서 이슈 해결을 위해 구현 에이전트를 소환하는 식이죠(결과물 문서와 스펙을 대조함). 하지만 여러 스레드/세션이 동시에 돌아가면서 서로의 오케스트레이터와 통신할 때, 시간이 지나면서 추적하기가 감당하기 어려워질 수 있더군요.

현재는 Claude 자체가 하위 에이전트를 생성하는 단일 CI 단계일 뿐이지만, 하위 에이전트에 needs: [review_elephant]를 추가하고 오케스트레이터에 <5개의 하위 에이전트 모두>를 추가한 뒤 출력을 CI 아티팩트로 전달하는 건 꽤 간단할 겁니다.

저는 일종의 브레인 덤프 문서를 따로 작업하는 걸 좋아합니다(가끔 VTT 사용). 제 비전, 할 수 있게 하고 싶은 것들, 지금 생각나는 제약 사항, 기능을 사용할 사람들의 유형, 비슷한 UI/UX나 앱에서 좋거나 싫은 점, 걱정되거나 확실하지 않은 부분(보통 보안, 아키텍처, API 형태), 그리고 모든 것의 의도(이 부분이 중요함)에 대해 그냥 떠드는 거죠. 그런 다음 Astra나 Fable 같은 똑똑한 모델에 돌려서 정보를 정리하고 명확하게 만듭니다(브레인 덤프를 바탕으로 최종 출력 문서를 두 번 독립적으로 검토하게 함). 관계와 참조가 명확한 섹션으로 나누는 거죠(예: 기능 A는 기능 B와 x, y, z 방식으로 상호작용함; 또는 (섹션 12c - RBAC 참조) 등).

그게 첫 번째 'grill with docs'나 wayfinder 프롬프트의 기초가 되고, 거기서부터 시작합니다. 아, 그리고 github 이슈에 별도의 '열린 질문'과 '확정된 결정' 레지스터를 만들라는 지침도 포함합니다(이동 중에도 쉽게 접근할 수 있게). 자동화된 작업 중에 에이전트가 궁금한 점이 생기면 거기에 덤프하게 해서, 저를 기다리느라 완전히 멈추지 않고 미해결 질문만 남을 때까지 계속 진행하게 합니다... 그럼 제가 가능한 한 많이 답해주고 다시 시작하는 거죠.

확실히 이 방법과 루프, 하위 에이전트, 특정 체크포인트를 위한 다중 생성 세션, 세션 간 통신/지침 등이 포함된 명확하게 정의된 운영 패턴으로 48시간 이상의 지독한 실행을 성공시킨 적이 있습니다. 최종 결과물은 보통 꽤 괜찮습니다. 프로덕션 등급은 아니지만, 작은 것들을 반복하고 테스터에게 넘기기에 아주 좋은 상태죠. 당연히 이건 더 큰 기능들을 위한 겁니다.

큰 기능의 경우, 며칠에서 몇 주까지 걸릴 수 있습니다. 초기 빌드 작업, 빌드/테스트/리뷰/수정/반복 루프가 돌아가는 동안 질문에 답하기, 출력이 테스트 가능해지면 선택적으로 수동 QA 하기 등이 포함되죠. 대부분의 작업은 결국 UI/UX 반복이 됩니다. 훌륭한 디자인 참조, 프로토타입, 명확한 지침에도 불구하고 아주 긴 다중 세션/다중 에이전트 실행에서는 그걸 정확하게 잡아내지 못하더군요. 하지만 핵심이 구축되고 테스트된 후에는 반복하기 가장 쉬운 부분 중 하나라고 생각합니다.