10인 AI 팀 구축과 세 가지 함정

오늘의 목표와 맥락

역할(Role)과 성향(Disposition)을 분리한 10인 가상 개발팀 구상을 메모 한 장에서 실제로 동작하는 시스템까지 끌고 갔다.

시작은 팀 구성 아이디어를 정리한 텍스트 한 장이었다. 목표는 각 역할이 자기 성향으로 판단하고 서로 견제하게 만드는 것이었다. 한 모델에게 "여러 관점에서 봐줘"라고 부탁하는 것으로는 안 되는 일이다.

결과물은 저장소에 정리했다 — al8bright/hermes-slack. 페르소나 정의, 구축 스크립트, 단계별 문서가 들어 있다.

구현한 내용

페르소나 정의

역할별 문서 10개를 만들었다. 각 문서에 역할·성향·말버릇·판단 기준·다른 멤버와의 관계를 넣었다.

원안은 11명이었는데 10명으로 줄였다. Product Designer를 Frontend에 통합했다. 둘 다 "사용자 경험"이라는 같은 관점을 공유하고 방향 설계에서 구현으로 이어지는 하나의 흐름이라, 통합해도 관점 손실이 가장 적다고 판단했다.

대신 반증 역할은 정식 멤버로 남겼다. AI 에이전트끼리는 서로 쉽게 동조하는 경향이 있어서, 만장일치를 깨는 역할이 실질적으로 가장 큰 값을 한다.

런타임 구축

각 역할을 독립 프로필로 세웠다. 프로필마다 자기 시스템 프롬프트, 자기 모델, 자기 메모리를 가진다.

반복 작업을 스크립트로 뺐다.

설계와 판단

프로필 하나가 에이전트 하나다

가장 오래 붙든 지점이었다. 처음에는 "프로필 하나 안에 페르소나 10개"를 전제로 설계했는데, 런타임이 지원하지 않는 구조였다. 프로필당 시스템 프롬프트 하나, 모델 하나가 고정이다.

그래서 역할 10개는 프로필 10개가 됐다. 역할별로 다른 모델을 쓰려면 이 방법밖에 없다.

배정은 이름이 아니라 설명이 정한다

태스크를 자동 분해하는 기능이 있는데, 처음 돌렸을 때 자식 4개가 전부 한 프로필로 몰렸다.

원인은 프로필 설명이 비어 있었던 것이었다. 분해기는 프로필 이름으로 추측하지 않고 설명을 읽어 담당자를 고른다. 설명을 채우자 역할별로 정확히 갈렸다.

설명을 쓸 때는 성격이 아니라 어떤 태스크를 맡아야 하는가를 적어야 한다.

나쁨: "보수적이고 리스크를 싫어한다"
좋음: "권한·인증·데이터 흐름·공급망 위험을 검토한다"

문제와 해결

세 가지에 시간을 많이 썼다. 셋 다 원인이 예상과 달랐다.

설정 키가 딕셔너리였다

모델 변경 명령을 문서 예시대로 썼더니 프로필이 죽었다.

해당 키는 스칼라가 아니라 {default, provider, base_url} 딕셔너리였다. 스칼라를 넣으니 딕셔너리 전체가 덮여 공급사 정보가 사라졌다. 하위 키를 지정해야 했다.

검증 경로를 잘못 골랐다

에이전트에게 특정 툴이 붙었는지 확인하려고 대화 모드에서 물었다. "없다"는 답을 받고 기능 자체가 동작하지 않는다고 결론 내려 아키텍처를 갈아엎었다.

나중에 실제 태스크를 돌려보니 툴은 처음부터 정상 작동하고 있었다. 대화 모드와 워커 spawn 경로의 툴 등록이 서로 다르다. 잘못된 검증 방법 하나로 방향 전환까지 갔다가 되돌렸다.

교훈은 검증 경로가 실제 실행 경로와 같아야 한다는 것이다. 편한 방법으로 대신 확인하면 그 차이가 그대로 오진이 된다.

이모지 하나가 페르소나를 통째로 지웠다

한 역할만 페르소나가 적용되지 않았다. 파일은 정상, 설정도 정상, 모델을 바꿔도 그대로였다.

로그에 답이 있었다.

Context file blocked: invisible_unicode_U+200D

시스템 프롬프트에 넣기 전 인젝션 스캔이 도는데, 패턴 하나만 걸려도 파일 전체를 버린다. 문제의 문자는 조합형 이모지에 들어 있는 ZERO WIDTH JOINER였다. 나머지 9명은 단일 코드포인트 이모지라 멀쩡했다.

설치 스크립트가 보이지 않는 유니코드 6종을 제거하도록 고쳤다.

검증한 내용

안건 한 줄을 던져 종합 결정까지 완주시켰다.

분해기가 역할별로 6개 태스크를 만들었고, 의존 관계가 순서를 만들었다. 반증 역할은 다른 넷이 끝난 뒤에 실행되어 그 결론들을 읽고 반박했다.

넷 다 "점진적 전환"으로 수렴한 상황에서 반증 역할이 개입했다.

네 검토가 모두 실제 코드와 트래픽을 확인하지 못한 채 점진 공존으로 수렴한 것은 관성에 가깝다.

조율자는 이를 반영해 결론을 갈랐다. 전환 자체는 No-Go, 측정과 비교 검증만 Go.

반증 역할이 없었다면 "전환 Go"로 끝났을 안건이다. 팀 구성의 의도가 실제 결정을 바꾼 것을 확인한 지점이다.

다음 단계

• 문서 도구 연동 검증 — 회의록 자동 기록과 일일 요약을 설계했으나 아직 실행 확인 전이다
• 대화 모드에서 특정 역할 지목 — 현재는 조율자에게만 말을 걸 수 있다
• 모델 공급사 추가 — 지금은 한 공급사의 세 모델로만 나뉜다
• 컨텍스트 파일 잘림 경고 해소

참고

문서는 구축 순서대로 번호를 붙여 정리했다. 필수 두 단계까지만 하면 터미널에서 팀이 완전히 돌아가고, 나머지는 선택이다.

런타임은 Hermes Agent를 썼다. 이 저장소에는 실행 코드가 없고 페르소나 정의와 구축 문서만 들어 있다.