다중 코딩 에이전트를 활용한 소프트웨어 엔지니어링 프로세스 구축 방법이 궁금합니다.

에이전트는 티켓 저장소(Jira, beads 등)와 위키에 접근할 수 있음.

모든 팀 회의와 채팅은 에이전트가 기록하고 처리함. 자동으로 작업, 결정 사항 등을 추출해 위키에 정리하고 Jira 티켓을 생성함 -> 회의 후 연구/개선 에이전트가 실행되어 회의에서 나온 정보 수집 및 미해결 질문(예: 입력 데이터 관련 우려 등)을 해결함: 연구 계획 생성 -> 검토 루프 -> 연구 실행, PDF 보고서 생성 -> 검토 루프 -> 결과를 위키와 티켓에 반영함.

티켓 보드를 정리(재구성, 종료 등)하는 에이전트 스킬이 자동으로 실행됨.

티켓에 깔끔한 태그를 달아 에이전트가 작업을 섞지 않도록 함: 앱 A, 앱 B, 컴포넌트 A, 리팩토링 등. 이렇게 하면 에이전트가 더 잘 집중함.

커스텀 스킬이 에이전트를 오케스트레이션함: 각 티켓마다 사양을 만들고, 구현자(Haiku)에게 지시하는 법, 하위 에이전트의 결과물 형식을 지정함. Opus High/XHigh가 1차 검토하고, Opus Medium이 승인될 때까지 재검토함. 메타 에이전트가 이 세션을 관찰하며 오케스트레이터를 비판하고, 필요시 지시하고 수정함. 관찰 내용을 보고서로 작성 -> 그 보고서를 바탕으로 스킬을 조정할 수 있음.

메타 에이전트는 내 주의가 필요한 사항을 감지하면 나에게 연락함.

훅(Hook)은 하위 에이전트가 작업을 반환하기 전에 모든 관문을 통과했는지 확인함(막히지 않도록 강제 반환 기능도 있음): 빌드가 깔끔한지, 테스트를 통과했는지, 반환 형식이 맞는지(사실 이건 툴을 써야 할 듯 - lol), 모든 내용이 있는지 등.

테스트는 광범위하며 많은 엔드투엔드 테스트를 포함함. 웹 앱의 경우(웹 개발은 거의 안 해서 내 방식은 조잡할 수 있음), 실제 DB(물론 개발 DB지만 실제 데이터는 포함)에 배포된 라이브 웹 앱에서 기능을 시연해야 함.

가능한 곳에는 뮤테이션 테스트를 적용함.

아마 최적은 아니겠지만, 나는 실험하는 것을 좋아하고 내 작업의 99%를 자동화하려고 함. 내 목표는 동료 및 에이전트와 제품에 대해 이야기하고 결과물을 전달받는 것임. 하지만 비결은 지속적이고 엄격한 평가/검토 루프임. 여러 에이전트가 코드를 검토하면 버그가 빠져나갈 확률이 크게 줄어듦(물론 여전히 존재함). 또한 컨텍스트, 컨텍스트, 컨텍스트가 중요함. 팀과 고객의 모든 소통 내용을 에이전트에 입력해야 함. 그러면 갑자기 지시할 일이 거의 없어짐, 에이전트가 이미 대화에서 내용을 추출하기 때문임.

다들 구독 플랜이 어떻게 되는지, 아니면 API 비용이 대략 얼마 나오는지 궁금함.

Teams 플랜 쓰고 있음. 6.25배 정도 더 쓸 수 있을 것 같은데 생산성도 그만큼 늘어날 듯. 그래도 Haiku 덕분에 비용 관리가 됨. 퇴근하면 에이전트 실행을 멈추거든. 안 그러면 밤새고 주말 내내 돌아갈 수도 있을 듯.

내가 본 성공적인 설정들은 다이어그램보다 덜 화려함. 하나의 오케스트레이터 세션이 이슈를 읽고 짧은 작업 사양을 작성함: 목표, 관련 파일, 검증 방법. 각 코딩 세션은 자체 git 워크트리나 브랜치에서 사양 하나를 처리하므로 병렬 작업이 충돌할 수 없음. 별도의 검토 단계(이상적으로는 diff와 사양만 보는 새로운 세션)에서 테스트를 실행하고 검증 가능한 것과 없는 것을 보고함. 병합은 사람이 함.

에이전트 수보다 중요한 부분: 작업당 명확한 완료 확인(테스트나 명령, '보기 좋음'이 아님), 작은 작업 단위, 그리고 작성자와 컨텍스트를 공유하지 않는 리뷰어(이유를 본 리뷰어는 동의하는 경향이 있기 때문). 나는 코더 1명과 리뷰어 1명으로 시작해서, 새로운 역할이 필요한 반복적인 실패가 보일 때만 역할을 추가하는 것을 추천함.