서론

지난 기사 「Claude Code 하네스 기능 상세 해설: CLAUDE.md・SKILLS・HOOK으로 개발을 제어한다」에서는 Claude Code의 하네스 기능 (Harness function) (CLAUDE.md, Memory, SKILLS, HOOK)을 활용한 개발 제어를 해설했습니다.

특히, 장기 세션에서의 컨텍스트 저하 (Context degradation) (우선순위 저하, Compaction)에 대해, HOOK과 SKILLS가 이벤트 주도 (Event-driven) 방식으로 매번 규칙을 환기하는 대항책으로서 유효함을 설명했습니다.

하지만 하네스 기능은 단일 Claude Code 세션 내에서의 제어에 특화되어 있어, 다음과 같은 케이스에는 대응할 수 없습니다:

복수 AI 프로바이더의 협조 동작: Claude (계획·설계) + Copilot (구현)의 역할 분담 -
멀티 스텝 워크플로우 자동화 (Multi-step workflow automation): 계획 → 구현 → 테스트 → 리뷰의 연쇄 실행 -
스텝 간의 컨텍스트 인계: 이전 스텝의 결과를 다음 스텝으로 전달하는 메커니즘 -
실패 시의 유연한 재시도 (Retry): 에러 발생 시 스텝 단위로 재실행·수정 지시

이러한 요구사항에는 **AI 오케스트레이션 도구 (AI Orchestration Tool)**가 필요합니다. 이 기사에서는 오케스트레이션 도구의 선정 프로세스와, TAKT를 채택한 이유를 해설합니다.

이 기사에서 알 수 있는 것

• AI 오케스트레이션 도구 선정의 3가지 관점
• TAKT의 특징과 채택 이유
• 다른 선택지와의 비교
• 실제 도입 시의 고려 사항

1. AI 오케스트레이션 도구 선정의 3가지 관점

Claude Code의 하네스 기능 (Harness function) (CLAUDE.md, Memory, SKILLS, HOOK)은 장기 세션에서의 컨텍스트 유지와 규칙 준수에 유효하지만, 복수 AI의 협조나 복잡한 워크플로우 자동화에는 대응하지 않습니다.

이러한 요구사항을 충족하는 오케스트레이션 도구 선정 시 중시한 3가지 관점을 소개합니다.

1.1 복수 AI 프로바이더 대응

배경: AI 프로바이더의 특기 영역

실제 개발에서는 각 AI 프로바이더의 특성을 살린 역할 분담이 효과적입니다:

선정 기준

프로바이더 전환이 용이: 스텝마다 다른 프로바이더를 지정 가능 -
인증 정보 관리: 각 프로바이더의 API/CLI를 통일적으로 관리 -
구독 활용: Claude Pro나 GitHub Copilot의 구독을 효과적으로 활용

1.2 워크플로우 정의의 유연성

필요한 기능

이상적인 워크플로우:

계획 (Claude) → 구현 (Copilot) → 테스트 (Copilot) → 리뷰 (Claude)

이 흐름을 정의할 때 필요한 요소:

스텝의 명확한 정의: 각 스텝의 역할・프로바이더・프롬프트를 기술 -
컨텍스트 인계: 이전 스텝의 결과를 다음 스텝으로 전달 -
조건 분기: 테스트 실패 시의 처리 등 -
가독성: 팀에서 공유・유지보수 가능한 형식

선정 기준

선언적 기술 (Declarative description): YAML이나 JSON 등 읽기 쉬운 형식 -
버전 관리 가능: Git으로 관리할 수 있음 -
프로젝트 고유 설정: 프로젝트마다 워크플로우를 커스텀

1.3 재시도・수정 기능

문제: 자동 실행에서의 실패

완전 자동화에서는 다음과 같은 실패가 발생합니다:

테스트 실패: 구현 실수로 인한 테스트 에러 -
Lint 에러: 코딩 규약 위반 -
빌드 에러: 의존성 문제

빌트인 기능으로는 이러한 실패 시에 인간이 개입하여 재지시해야 합니다.

선정 기준

스텝 단위의 재시도 (Retry): 실패한 스텝부터 재실행 -
수정 지시: 에러 내용을 확인하고, 추가 지시를 주어 재실행 -
이력 관리: 과거의 실행 결과를 확인 가능 -
인터랙티브성 (Interactivity): 완전 자동과 매뉴얼 개입의 균형

2. TAKT의 특징과 채택 이유

위의 세 가지 관점에 따라, TAKT(AI orchestration tool)를 선정했습니다.

2.1 TAKT란

TAKT는 여러 AI 프로바이더(Provider)를 통합하고, YAML 기반의 워크플로(Workflow) 정의를 통해 단계적인 태스크(Task) 실행을 가능하게 하는 오케스트레이션(Orchestration) 도구입니다.

공식 리포지토리 (Official Repository): https://github.com/takt-ai/takt

2.2 TAKT의 주요 기능

1. YAML 기반의 워크플로 정의

가독성이 높고 Git으로 관리하기 쉽습니다:

# .takt/workflows/default.yaml
workflows:
  default:
    ...

2. 다중 프로바이더 대응

스텝(Step)마다 최적의 프로바이더를 지정할 수 있습니다:

providers:
  claude:
    type: claude
    ...

3. 스텝 단위의 재시도(Retry) 및 수정

실행 후 유연한 개입이 가능합니다:

# 워크플로 실행
takt run default "신기능 구현"
# 실행 상황 확인
...

4. 프로젝트 고유 설정

project/
├── .takt/
│ ├── config.yaml # 프로젝트 고유 설정
...

2.3 TAKT 채택 결정 이유

✅ 관점 1: 다중 AI 프로바이더 대응

• Claude, Copilot CLI 모두 대응
• 스텝마다 프로바이더 지정 가능
• 인증 정보는 글로벌 설정으로 일원 관리

✅ 관점 2: 워크플로 정의의 유연성

• YAML로 선언적(Declarative)으로 기술
• Git으로 버전 관리 가능
• 프롬프트 템플릿(Prompt Template), 변수 확장(Variable Expansion) 지원

✅ 관점 3: 재시도 및 수정 기능

• takt list로 실행 이력 확인
• takt retry로 스텝 단위의 재실행
• takt instruct로 추가 지시

기타 장점

• 로컬 실행 (Local Execution): 클라우드 불필요, 프라이버시 보호
• 오픈 소스 (Open Source): 커스터마이징 가능
• 경량 (Lightweight): 의존성이 적어 도입이 용이

3. 다른 선택지와의 비교

TAKT 이외에도 검토했던 선택지와 각각의 특징을 소개합니다.

3.1 파일 기반의 프롬프트 관리

개요

프롬프트를 파일에 저장하고, 수동으로 각 AI에 전달하는 방식입니다.

장점

• 심플함
• 태스크 정의의 재사용
• 별도의 도구 불필요

단점

• AI 간의 연계는 수동: 결과 전달을 사람이 직접 수행
• 자동화 불가: 스텝마다 수동으로 실행
• 재시도 기능 없음: 실패 시 처음부터 다시 시작

적합한 케이스

• 단발성 태스크
• AI를 하나만 사용하는 경우
• 완전히 수동으로 컨트롤하고 싶은 경우

3.2 GitHub MCP Server 연계

개요

Claude.ai에서 GitHub 리포지토리에 직접 접근 및 커밋합니다.

장점

• Claude.ai에서 직접 조작
• Web UI 내에서 완결
• MCP의 표준 기능

단점

• 로컬 환경과의 동기화 문제: 로컬 작업과 충돌 발생 가능
• Claude.ai 전용: 다른 AI 프로바이더와 조합하기 어려움
• 워크플로 정의가 어려움: 스텝 자동화에는 부적합

적합한 케이스

• 웹 브라우저 내에서 모든 것을 해결하고 싶은 경우
• 로컬 환경이 없는 경우
• Claude만으로 충분한 경우

3.3 커스텀 스크립트 (셸 스크립트 등)

개요

셸 스크립트나 Python 스크립트로 직접 제작합니다.

장점

• 완전한 유연성
• 프로젝트 고유의 요구사항 대응 가능
• 학습 비용 없음 (기존 지식으로 대응)

단점

• 개발 및 유지보수 비용: 직접 구현하고 관리해야 함
• 재사용성 낮음: 프로젝트마다 새로 만들어야 함
• 복잡한 에러 핸들링 (Error Handling): 재시도 및 수정 메커니즘을 직접 구현해야 함

적합한 케이스

• 특수한 요구사항이 있는 경우
• 기존 도구로 대응할 수 없는 경우
• 스크립팅에 능숙한 경우

3.4 비교 요약

4. TAKT 도입 시 고려사항

실제로 TAKT를 도입할 때 고려해야 할 포인트를 소개합니다.

4.1 프로젝트 고유 설정

Flutter Web + Cloudflare Workers 프로젝트 (weather_outfit_app)에서의 초기 설정 예시:

# .takt/config.yaml
project:
name: weather_outfit_app
...

4.2 개발 환경 정리

• Ubuntu (WSL): TAKT를 로컬에 설치
• Claude Pro: 구독을 통한 정액 이용
• GitHub Copilot: CLI를 통한 구현 지원
• 통합: TAKT를 통해 두 가지를 통합적으로 조작

4.3 단계적 도입

한 번에 모든 태스크를 TAKT로 이전하는 것이 아니라, 단계적으로 도입합니다:

• Phase 1: 심플한 워크플로 (2~3단계)로 테스트
• Phase 2: 실제 프로젝트에서 작은 기능 추가에 적용
• Phase 3: 복잡한 워크플로 (분기, 재시도) 추가
• Phase 4: 팀 전체에서 활용

4.4 지속적인 개선

TAKT의 워크플로 정의는 프로젝트의 진화에 맞춰 업데이트합니다:

• 프롬프트 (Prompt) 조정: 더 나은 결과를 얻기 위해 개선
• 단계 추가 및 삭제: 필요에 따라 워크플로를 변경
• 프로바이더 (Provider) 재검토: 새로운 AI 프로바이더의 등장에 대응

5. 요약

도구 선정은 요구사항에 따라

AI 오케스트레이션 도구의 선정은 프로젝트의 요구사항에 따라 이루어져야 합니다. 반드시 도구가 필요한 것은 아닙니다.

하네스 (Harness) 기능으로 충분한 케이스

단일 Claude Code 세션 내에서의 제어

• 장기 세션에서의 규칙 준수 (HOOK/SKILLS로 대응)
• 컨텍스트 (Context) 관리 (CLAUDE.md/Memory)
• 정형 태스크의 커맨드화 (SKILLS)

대응 가능한 것:

• 이벤트 드리븐 (Event-driven) 방식의 자동 호출 (HOOK)
• 표준 절차의 고정화 (SKILLS)
• 프로젝트 컨텍스트 유지 (CLAUDE.md)

대응 불가능한 것:

• 다중 AI 프로바이더의 구분 사용
• 멀티 스텝 (Multi-step) 자동 실행
• 단계 간의 컨텍스트 인계

오케스트레이션 도구가 필요한 케이스

• 다중 AI 프로바이더의 협업 동작 (Claude + Copilot 등)
• 멀티 스텝 워크플로 자동화 (계획 → 구현 → 테스트 → 리뷰)
• 단계 단위의 재시도 및 수정
• 실행 이력 관리

TAKT가 적합한 케이스

TAKT는 다음과 같은 프로젝트에 적합합니다:

✅ 다중 AI 프로바이더를 구분해서 사용하고 싶을 때

• Claude (계획·설계) + Copilot (구현) 등

✅ 워크플로를 명시적으로 정의하고 싶을 때

• YAML로 선언적 기술
• Git으로 버전 관리

✅ 유연한 재시도 및 수정이 필요할 때

• 완전 자동화가 아닌, 적절한 인간의 개입

✅ 로컬 실행이 전제될 때

• 클라우드 불필요, 프라이버시 보호

단계적 도입 권장

갑자기 복잡한 워크플로를 만들기보다, 심플한 것부터 시작하여 점진적으로 확장해 나가는 것을 추천합니다.

1. 하네스 기능 (CLAUDE.md, SKILLS, HOOK)으로 개발
- 장기 세션에서의 컨텍스트 유지
- 정형 태스크의 커맨드화
...

시리즈 기사

• Claude Code 입문 - 빌트인 기능의 전체상
• Claude Code 하네스 기능 상세 해설: CLAUDE.md·SKILLS·HOOK으로 개발을 제어하기 ← 이전 글
• AI 오케스트레이션 도구 선택 방법: TAKT 채택까지의 검토 프로세스 ← 이번 글