AI 에이전트 팀과 스킬 아키텍처를 어떻게 나눌까

AI 에이전트 팀과 스킬 아키텍처를 어떻게 나눌까

AI 자동화를 처음 붙일 때는 보통 모델 하나만 잘 붙이면 될 것처럼 느껴진다. 실제로 작은 작업은 그렇게도 된다. 하지만 조금만 범위가 커지면 금방 문제가 생긴다. 리뷰, 구현, 문서화, 조사, 운영 점검 같은 성격이 다른 작업이 한 세션 안에 다 섞이기 시작하면, 답변 품질보다 먼저 작업 흐름이 흐려진다.

이 시점부터는 “어떤 모델을 붙일까?”보다 어떤 역할을 누구에게 맡길까, 스킬은 어떤 단위로 쪼갤까, 실패와 검증을 어떤 구조로 감쌀까가 더 중요해진다. 결국 중요한 건 모델이 아니라 하네스다.

여기서 말하는 하네스 엔지니어링은 프롬프트 문장 몇 줄을 예쁘게 쓰는 일이 아니다. 실제 작업 성능에 직접 영향을 주는 아래 요소를 설계하는 일에 가깝다.

• 입력 구조
• 역할 분리
• 권한 경계
• 검증 루프
• 실패 복구
• 상태 관리
• 결과 보고 형식

왜 모델 하나로 다 처리하면 금방 꼬이나

작업 성격이 다른데도 한 에이전트에게 계속 맡기면 아래 문제가 생기기 쉽다.

• 구현과 리뷰 기준이 섞인다
• 조사와 수정이 한 흐름 안에서 충돌한다
• 같은 맥락을 계속 끌고 가다 보니 세션이 무거워진다
• 재사용 가능한 작업 규칙이 남지 않는다
• 실패했을 때 어디서 다시 시작해야 할지 불명확해진다

즉, 모델이 충분히 좋아도 역할 분리 없는 자동화는 운영 피로가 빠르게 쌓인다.

에이전트 팀을 나눌 때 먼저 보는 기준

내 기준으로는 아래 세 축이 중요하다.

1. 작업 종류

• 구현
• 리뷰
• 조사
• 문서화
• 운영 점검

2. 출력물 종류

• 코드 변경
• 요약
• 체크리스트
• 보고서
• 초안

3. 검증 방식

• 테스트 실행
• diff 검토
• 링크/사실 확인
• 사람 승인

이 세 가지가 다르면, 같은 에이전트보다 역할을 나눈 쪽이 더 안정적일 때가 많다.

스킬은 언제 분리할 가치가 생기나

스킬은 정보 묶음이라기보다 반복 작업을 안정적으로 수행하는 작은 프로토콜에 가깝다.

예를 들어 아래는 스킬로 분리할 가치가 높다.

• 얇은 기술 글을 중장문으로 확장
• 특정 형식의 리뷰 체크 수행
• 운영 장애 점검 순서 정리
• 릴리즈 노트 초안 생성
• PR 리뷰 코멘트를 후속 작업으로 바꾸기

반대로 매번 방식이 크게 달라지는 일이나 일회성 작업은 굳이 스킬로 만들지 않아도 된다.

좋은 구조는 보통 이렇게 나뉜다

메인 허브

• 요청 해석
• 작업 분배
• 결과 종합

구현 에이전트

• 코드 수정
• 테스트
• 리팩터링

리뷰 에이전트

• 위험 요소 확인
• 누락 점검
• 결과 검토

조사 에이전트

• 외부 자료 확인
• 링크/사실 조사
• 비교 정리

스킬

• 반복되는 작업 규칙
• 체크리스트
• 템플릿
• 참고 문서 연결

이렇게 나누면 모델보다 작업 구조가 정리된 효과가 더 크게 난다.

CLI별 하네스 엔지니어링 비교

아래 표는 같은 “AI 코딩 CLI”라도 어디에 강점이 있고, 하네스를 어떻게 설계해야 하는지가 꽤 다르다는 걸 보여준다.

CLI	기본 성격	하네스에서 가장 중요한 것	잘 맞는 역할	주의할 점
Claude Code	긴 문맥, 계획, 리뷰, 작업 분배	rules / skills / role separation	메인 허브, 계획, 리뷰, 장기 작업	한 세션에 너무 많은 역할을 몰아넣기 쉬움
Codex	작업 단위 실행, 수정, 검증 루프	task framing / repo isolation / validation	구현, 버그 수정, 작은 리팩터링	검증 없이 결과만 믿으면 품질이 흔들림
Gemini Code	요약, 계획, 구조화된 출력	input restructuring / fixed output format	요약, 계획서, 리뷰 체크리스트	긴 맥락을 그대로 던지면 장점이 줄어듦
Qwen Code	CLI 반복 흐름, 입력/완성, 짧은 왕복	prompt shape / input history / completion flow	빠른 탐색, 짧은 반복, 간단 정리	shortcut 자체보다 CLI 흐름 최적화가 더 중요함

Claude Code는 왜 하네스가 중요하냐

Claude Code는 긴 문맥을 잘 다루고 계획을 세우는 능력이 강해서, 겉으로 보면 하나의 세션에서 다 해결하고 싶어지기 쉽다. 하지만 실제로는 아래처럼 쪼개는 편이 낫다.

• 메인 세션: 요청 해석, 계획, 역할 분배
• 구현 세션: 수정과 테스트
• 리뷰 세션: 리스크 점검
• 조사 세션: 외부 근거 확인

여기서 핵심은 프롬프트보다 rules, skills, 프로젝트 규칙 파일이다. 반복 규칙과 작업 스타일을 파일로 고정하면 매번 같은 지시를 길게 반복하지 않아도 된다.

즉, Claude Code에서의 하네스 엔지니어링은 문맥 운영 설계에 가깝다.

Codex는 왜 검증 루프가 중심이 되나

Codex는 실제 구현 실행기처럼 쓸 때 체감이 좋다. 그래서 하네스도 자연스럽게 다음 질문으로 옮겨간다.

• 범위를 얼마나 선명하게 잘랐나
• 어떤 저장소와 브랜치에서 돌리나
• 실패하면 어디서 멈추게 할 건가
• 무엇으로 검증할 건가

Codex는 프롬프트를 잘 쓰는 것보다 작업 단위를 잘 설계하는 것이 훨씬 중요하다.

좋은 입력은 보통 아래 요소를 같이 갖는다.

• 수정 범위
• 목표
• 검증 명령
• 출력 형식
• 실패 시 보고 방식

즉, Codex에서의 하네스 엔지니어링은 작업 단위 설계와 검증 자동화에 가깝다.

Gemini Code는 왜 출력 형식이 중요하냐

Gemini Code는 실행기보다는 정리기, 계획기, 리뷰어로 둘 때 효율이 잘 나온다. 특히 긴 입력을 그대로 던지기보다 아래처럼 재구성하는 하네스가 중요하다.

• 파일
• 로그
• 제약
• 질문

그리고 출력도 미리 정해두는 편이 좋다.

• 위험 3개
• 단계별 계획
• 체크리스트
• 5줄 요약

즉, Gemini Code에서의 하네스 엔지니어링은 입력 재구성과 출력 표준화에 가깝다.

Qwen Code는 왜 CLI 흐름 최적화가 핵심이냐

Qwen Code는 공개적으로 보이는 특성상 keyboard shortcut보다 입력, completion, history, 짧은 왕복 작업이 더 중요하다. 그래서 이 도구를 잘 쓰는 하네스는 대규모 멀티에이전트 설계보다, CLI 반복 흐름을 얼마나 빠르게 만드느냐에 더 가깝다.

• 짧은 프롬프트 템플릿
• 히스토리 재사용
• completion 친화적인 작업 방식
• 빠른 질문과 수정 반복

즉, Qwen Code에서의 하네스 엔지니어링은 입력 루프 최적화에 가깝다.

결국 중요한 건 도구가 아니라 역할 배치다

실무에서는 하나만 고집하기보다 다음처럼 역할을 나누는 게 더 현실적이다.

• Claude Code: 메인 허브, 계획, 장기 문맥
• Codex: 구현, 수정, 검증
• Gemini Code: 요약, 계획 정리, 리뷰 체크리스트
• Qwen Code: 빠른 CLI 반복, 탐색 보조

이 조합이 중요한 이유는 모델 서열 때문이 아니라, 각 도구가 어떤 하네스 안에서 가장 효율적으로 작동하는지가 다르기 때문이다.

마무리

에이전트 자동화가 커질수록 중요한 건 모델 하나의 똑똑함보다, 역할 분리와 스킬 구조다.

정리하면:

• 작업 종류가 다르면 역할을 나누는 게 좋다
• 반복되는 흐름은 스킬로 묶는 게 좋다
• 구현 / 리뷰 / 조사 / 운영은 분리할수록 안정적이다
• CLI마다 강점이 다르니 하네스도 다르게 설계해야 한다

결국 에이전트 팀 설계는 성능 최적화라기보다 운영 가능성을 높이는 구조 설계에 가깝다. 그리고 그 차이를 만드는 건 모델 스펙보다, 하네스를 설계하는 사람의 감각일 때가 많다.