서론

지난 기사에서 자기 개선형 AI 에이전트인 「Hermes Agent」를 Mac에 상주시켜 Slack에서 사용할 수 있도록 만들었습니다.

그 후, Slack 상의 Hermes에게 다음과 같은 고민을 던졌습니다.

팀 개발에서 공통 리포지토리(Repository)의 설계 및 구현을 진행한다고 가정해 봅시다.

각 담당자에게 Claude Code를 배포하여 사용할 경우, 동일한 공정(API 설계나 UT 개발)에서 동일한 모델을 사용하더라도 팀 공통의 구조화된 컨텍스트(Context)를 사용하는 것이 아니기 때문에 결과물이 어긋나게 되지 않을까요?

이 과제를 해결하기 위해 Hermes를 여러 개 준비하거나 하나로 통합하면, 생성물의 편차를 최소화할 수 있지 않을까?

돌아온 답변이 실무적이고 흥미로웠기에, 대화를 통해 도달한 **「샌드위치 구성 (Sandwich Architecture)」**이라는 아키텍처를 정리하여 기사로 작성합니다.

참고로, 여기서 언급한 「각 담당자에게 AI를 배포하면 팀 전체의 결과물이 어긋난다」라는 문제 의식은, AI 에이전트를 전제로 한 개발 팀을 5개월간 운영하며 느낀 점을 쓴 별도의 기사를 바탕으로 한 실제 경험입니다. 함께 읽으시면 배경을 이해하기 쉬울 것입니다.

과제: 개별 배포 시 결과물이 어긋남

동일한 모델, 동일한 공정, 동일한 리포지토리라도 다음과 같은 요소가 다르면 출력 결과가 어긋납니다.

• 각 담당자가 제공하는 프롬프트(Prompt)와 보여주는 컨텍스트(Context)
• 로컬의 CLAUDE.md / skills / memory 상태 - 사양이 모호한 부분을 AI가 임의로 보완하는 내용
• 리뷰 관점과 「완료」의 정의
• 인간 측의 암묵지(Tacit Knowledge)

예를 들어, API 설계를 각자 Claude Code에 의뢰하면 에러 형식, pagination 작성 방식, 인가(Authorization) 및 멱등성(Idempotency) 고려 여부, OpenAPI의 세밀도, 명명 규칙(Naming Convention) 등이 제각각이 됩니다. UT(Unit Test) 개발이라면 정상계 중심인 사람, 경계값을 두텁게 하는 사람, mock을 다용하는 사람, fixture 설계 방식이 다른 사람…… 등의 차이가 발생합니다.

중요한 점은, 이것이 모델의 성능 부족이 아니라, 입력 컨텍스트와 평가 기준이 일치하지 않음으로써 발생하는 편차라는 점입니다.

편차의 원인은 4가지로 분류할 수 있습니다.

• 모델의 비결정성 (Non-determinism) — temperature를 낮춰도 완전히 일치하지 않음
• 컨텍스트 차이 — 누가, 어느 시점에, 어떤 파일을 읽게 했는가
• 사양의 모호함 — 모호하게 전달된 부분은 AI가 일반론으로 보완함
• 평가 기준의 부재 — 「좋은 API 설계란 무엇인가」가 구조화되어 있지 않음

즉, 목표는 「생성물을 완전히 고정하는 것」이 아니라, **「입력·절차·평가·개선 루프를 중앙 관리하여 편차를 계속해서 줄여나가는 것」**이 됩니다.

구성 패턴 비교

A. 각 엔지니어가 Claude Code를 개별 이용

Engineer A → Claude Code
Engineer B → Claude Code
Engineer C → Claude Code

도입은 간단하고 개인의 작업 속도는 올라가지만, 컨텍스트가 분산되고 암묵지가 개인에게 쌓이며, 결과물의 품질이 담당자에게 의존하게 됩니다.

개인용 부스터로서는 좋지만, 팀 개발의 표준화 기반으로서는 취약한 구성입니다.

B. 중앙 AI 기반으로 일원화

공통 skills, 공통 컨텍스트, 통일된 리뷰 관점을 가질 수 있는 반면, 권한 설계, 세션 혼선, 기반 유지보수의 부담이 발생합니다.

또한 모든 작업이 중앙을 거치게 되면 대기 시간, 병렬 작업, IDE 연동, 개인의 작업 스타일 문제 등이 발생합니다.

C. 샌드위치 구성 (채택안)

대화 속에서 도달한 형태입니다. ※ 아직 검증되지 않은 상태입니다. 향후 이 안의 워크플로우를 제안하고 검증을 진행하고자 합니다.

개인 AI는 유지하면서, 그 앞뒤에 표준화 레이어를 끼워 넣습니다.

• 전단의 Hermes가 개인 AI에 전달할 입력 컨텍스트(필독 자료, 설계 원칙, 출력 형식, 금지 사항, 완료 조건)를 표준화합니다.
• 중단의 개인 AI는 각자 익숙한 도구를 그대로 사용하여 구현 및 생성에 집중합니다.
• 후단의 Hermes가 결과물을 팀 표준에 비추어 리뷰합니다.

전단에서 맞추고 후단에서 검사한다. 개인의 자유도와 팀의 표준화를 양립할 수 있는 것이 포인트입니다. Hermes는 개인 AI를 대체하는 것이 아니라, 「각 개인 AI에 전달하기 전의 공통 컨텍스트 생성기」이자 「품질 기준 관리자」 —— 즉, **AI 개발 거버넌스 계층 (AI Development Governance Layer)**으로서 배치됩니다.

운용 플로우의 구체적인 예

실제 1개 태스크는 다음과 같이 흐릅니다.

Step 1: 엔지니어가 issue / task를 읽음
Step 2: Hermes의 공정별 profile에 질문
"이 issue를 API 설계하기 전에, Claude Code에 전달해야 할 표준 컨텍스트를 만들어줘"
...

전단(前段)에서 생성하는 표준 프롬프트 예시 (API 설계)

당신은 이 리포지토리의 API 설계 담당자입니다.
다음 문서를 반드시 읽은 후 설계해 주세요.
필독:
...

모두가 동일한 profile로부터 이를 가져와 개인 AI에 전달하므로, 초기 입력 컨텍스트가 통일되어 출력의 편차가 구조적으로 줄어듭니다.

개선 루프 (이것이 핵심)

팀 표준화에서 가장 중요한 것은 초기 템플릿이 아니라 개선 루프입니다.

결과물이 어긋남
↓
왜 어긋났는지 분석함 (prompt 부족? skill 부족? guideline 부족?)
...

skills는 "AI용 표준 작업 절차서 + 리뷰 관점 + 팀의 암묵지"이며, 한 번 만들고 끝나는 것이 아니라 팀의 개발 표준을 육성하는 문서입니다.

이 유지보수를 중앙화할 수 있다는 점이 개별적으로 배포하는 방식과의 결정적인 차이점입니다.

Hermes가 아니어도 대체 가능하지 않을까?

대화 도중 저도 질문을 던졌습니다. "샌드위치 구성은 좋지만, Hermes가 아니어도 대체 가능하지 않을까?"라고 말이죠.

돌아온 답변은 명쾌했습니다.

"표준 프롬프트를 만들어 전달하는 것뿐"이라면 Hermes가 아니어도 대체 가능합니다.

하지만, 팀 개발의 "표준화 레이어(Standardization Layer)"를

지속적으로 운용하는 기반으로 본다면 차이가 발생합니다.

비교 기준은 모델 성능이 아니라 레이어의 차이입니다.

Claude Code / Codex = 개인이 작업하기 위한 구현 에이전트 (Implementation Agent)
Hermes = 팀이 AI 이용을 운용하기 위한 오케스트레이션 기반 (Orchestration Infrastructure)

Hermes가 우위에 서기 쉬운 포인트:

• 모델 비의존성 (Model Agnostic) — 표준화 로직을 Hermes에 두면, "API 설계는 Claude, 테스트 생성은 Codex, 대량 리뷰는 저렴한 모델, 기밀 사항은 로컬 LLM"과 같이 용도별로 전환하더라도 표준화 레이어를 다시 만들 필요가 없음
• profile 분리 — 공정·역할별로 model / skills / memory / 권한을 나눈 운용 단위를 만들 수 있음 (api-standardizer, ut-standardizer, reviewer, security-reviewer…)
• 팀 지식의 축적 — skills(절차·평가 기준), memory(안정적인 전제), session_search(과거 의사결정의 전문 검색), curator(skills의 자동 유지보수)가 개선 루프로 직결됨
• 팀 접점의 중앙화 — Slack 상주 + cron을 통해 "매일 아침 미리뷰 PR의 표준 위반 리스크를 목록화", "주간 단위로 리뷰 지적 사항을 집약하여 skill 개선 후보 도출"과 같은 자동화를 구성할 수 있음
• 전단·후단의 공통화 — 개인별로 전단 프롬프트를 만들면 그 부분에서 다시 편차가 발생함. 중앙의 profile을 사용하면 모두가 동일한 입구를 통과함
• multi-agent 리뷰 — API 호환성·보안·테스트 부족·퍼포먼스 등 다각도 리뷰를 workflow로서 고정할 수 있음
• 비용·인증·권한의 중앙 관리 — 누가 어떤 모델을 어떤 비용으로 사용하고 무엇을 던지고 있는지가 가시화(Observability)됨

반대로 Hermes가 과잉인 경우

솔직하게 정리하자면, 다음과 같은 경우에는 불필요합니다.

• 2~3명의 소규모 팀이며, 문서화와 리뷰 문화가 이미 강력함 → AGENTS.md + CI + PR 템플릿만으로 충분
• 전원이 Claude Code로 완전히 통일하는 방침임 → CLAUDE.md + slash commands + CI hooks로 상당 부분 가능
• 표준화 대상이 "프롬프트 템플릿 배포"뿐임 → Notion이나 GitHub docs로 충분

Hermes를 도입할 가치가 생기는 것은, 단순 템플릿 배포가 아니라 문맥 생성·리뷰·이력 검색·개선·profile 분리·자동화·다모델화·팀 상주까지 수행할 경우입니다.

운용상의 주의점

샌드위치 구성에도 부작용은 있습니다.

• 표준 프롬프트가 너무 길어짐 — 프롬프트가 너무 방대해지면 중요한 정보가 묻힐 수 있다. -
• 표준이 부패함 — 제대로 작동할 때까지 정기적인 유지보수가 필요하지만, 이를 수행할 여력이 있는지가 관건이다. -
• 개인 AI가 표준을 무시함 — 후속 리뷰를 수행하고 개선을 반복하지만, 이를 실행하지 않는(무시하는) 엔지니어에 대한 강제 수단이 없다. -
• 의식화되면 사용되지 않음 — '매번 10분이 걸리는 의식'이 된다면 실패다. 가벼운 템플릿 생성 수준에 머물게 해야 한다. -
• 최종적인 품질 담보는 CI와 인간 리뷰 — Hermes는 표준화를 돕지만, 최종 보증은 사람(엔지니어)에 의한 리뷰를 거쳐 보증하도록 해야 한다.

요약

• 팀 개발에서 AI의 결과물이 어긋나는 원인은 모델 성능이 아니라 입력 컨텍스트와 평가 기준의 불일치 — 해결책은 완전한 중앙집권도 개별 최적화도 아닌, 전단(표준화) → 중단(개인 AI) → 후단(리뷰)의 샌드위치 구성 — 개인 AI는 '구현·탐색의 가속', Hermes는 '표준화·문맥 통제·평가 기준·개선 루프'라는 역할 분담
• Hermes의 우위성은 생성 성능이 아니라, 팀 전체가 AI를 사용할 때의 문맥·절차·평가·개선·자동화를 하나로 묶을 수 있다는 점에 있다

지금까지 암묵지에 의해 제각각이었던 결과물을, 개인의 자유도를 해치지 않으면서 통일된 방향으로 끌어간다. AI 에이전트가 1인 1대를 보유하는 시대가 되었기에, 'AI를 어떻게 사용할 것인가' 자체를 팀 프로세스로 설계할 필요가 생겼다고 생각합니다.

다음을 위한 숙제

본 기사는 Hermes와의 대화를 통해 설계한 가설 단계이며, 실제 운용에서의 검증은 이제부터입니다. 기사에서 언급한 과제와 숙제를 정리하면 다음 세 가지로 집약됩니다.

① 실증 태스크 (다음 기사의 스코프)

• 공정별 profile (api-standardizer / ut-standardizer / reviewer / security-reviewer 등)과 그에 연결된 skills를 정비한다 - 작은 팀에서 실제로 샌드위치 구성을 운용하고 그 결과를 리포트한다

② 검증해야 할 가설

• 중앙 관리가 그 자체로 병목 현상이 되지 않는가
• 로컬(개인 AI)의 자유도를 어디까지 남겨두어야 하는가
• 표준이 형식화(형해화)되지 않는가

③ 운용상의 부작용에 대한 대책

• 표준 프롬프트의 비대화, 표준의 부패(유지보수 owner), 표준 무시에 대한 담보, 의식화 회피, CI·인간 리뷰와의 연결

다음 기사에서는 실제로 공정별 profile과 skills를 정비하고, 작은 팀에서 이 구성을 운용한 결과를 리포트할 예정입니다.

Discussion