Claude Code, OpenCode, Codex CLI로 보는 LLM Agent 오케스트레이션

 

이전 글에서는 LLM Agent에서 오케스트레이션(Orchestration)이 무엇인지 정리했다.

짧게 말하자면, 오케스트레이션은 여러 작업, 도구, 에이전트를 하나의 목표를 향해 연결하고 조율하는 구조다.

단순히 LLM에게 질문하고 답변을 받는 것이 아니라, 다음과 같은 흐름을 설계하는 것이다.

이번 글에서는 이 개념을 실제 도구 관점에서 살펴보려고 한다.

비교할 도구는 다음 세 가지다.

 

Claude Code, OpenCode, Codex CLI

이 글의 목적은 단순히 “어떤 도구가 더 좋은가”를 고르는 것이 아니다.

그보다는 각 도구가 LLM Agent의 오케스트레이션을 어떤 방식으로 구현하고 있는지 보는 것이다.

즉, 비교의 중심은 모델 성능이 아니라 다음 질문들이다.

작업을 어떻게 나누는가?
도구를 어떻게 실행하는가?
권한을 어떻게 관리하는가?
상태와 세션을 어떻게 유지하는가?
반복 작업을 어떻게 구조화하는가?
병렬 작업은 어떻게 다룰 수 있는가?

 

1. 왜 AI 코딩 도구를 오케스트레이션 관점에서 봐야 할까?

AI 코딩 도구를 비교할 때 흔히 다음과 같은 기준을 먼저 본다.

어떤 모델을 쓰는가?
응답 속도가 빠른가?
코드를 잘 작성하는가?
가격은 어떤가?
IDE에서 쓸 수 있는가?

물론 이런 기준도 중요하다.

하지만 LLM Agent 도구를 실제 개발에 사용하다 보면 더 중요한 질문이 생긴다.

이 도구가 내 프로젝트를 어떻게 읽는가?
수정 가능한 범위를 어떻게 제한하는가?
테스트 실행과 실패 로그를 어떻게 다루는가?
작업 도중 맥락을 얼마나 잘 유지하는가?
반복되는 업무를 어떻게 재사용 가능한 흐름으로 만들 수 있는가?

예를 들어 “로그인 오류를 고쳐줘”라는 요청은 단순한 코드 생성 문제가 아니다.

실제로는 다음과 같은 작업 흐름이 필요하다.

관련 파일 찾기 ➡️ 로그인 흐름 이해 ➡️ 문제 원인 추론 ➡️ 코드 수정 ➡️ 테스트 실행 ➡️ 실패 시 재수정 ➡️ 변경 사항 보고

 

이 흐름을 안정적으로 처리하려면 단순히 모델이 똑똑한 것만으로는 부족하다.

도구가 파일 시스템, 터미널, 테스트 러너, 권한 관리, 상태 관리, 재시도 흐름을 어떻게 묶어주는지가 중요하다.

그래서 AI 코딩 에이전트 도구는 “모델 인터페이스”가 아니라 “오케스트레이션 환경”으로 보는 것이 더 적절하다.

2. 비교할 도구 간단 소개

이번 글에서 다룰 도구는 Claude Code, OpenCode, Codex CLI다.

세 도구 모두 코드를 읽고, 수정하고, 명령을 실행하는 AI 코딩 에이전트에 가깝다.

하지만 오케스트레이션 관점에서 보면 강조점이 조금씩 다르다.

Claude Code:
권한, hooks, subagent 등 구조화된 제어 흐름을 보기 좋다.

OpenCode:
오픈소스, multi-session, custom agent, provider 선택 자유도를 보기 좋다.

Codex CLI:
로컬 터미널에서 sandbox, approval, skills 기반 작업 흐름을 보기 좋다.

 

3. 비교 기준

이번 글에서는 다음 기준으로 세 도구를 비교한다.

비교 기준	설명
실행 환경	어디에서 실행되는가
작업 분해	큰 요청을 작은 단계로 나누는 방식이 있는가
도구 사용	파일 읽기, 수정, 명령 실행을 어떻게 처리하는가
권한 관리	위험한 작업을 어떻게 제한하는가
상태 관리	세션과 작업 맥락을 어떻게 유지하는가
확장성	custom agent, hooks, skills, MCP 등을 지원하는가
병렬 작업	여러 작업을 동시에 진행하기 쉬운가
적합한 사용 사례	어떤 개발 흐름에 잘 맞는가

 

4. Claude Code: 구조화된 에이전트 작업 흐름

Claude Code는 오케스트레이션을 설명할 때 가장 직관적인 예시 중 하나다.

Claude Code의 특징은 단순히 “Claude가 코드를 잘 쓴다”가 아니다. (근데 이 것도 맞다.. 잘 쓰고 비싸고.. 똑똑하지만 토큰 소모율 너무 빠른)

더 중요한 점은 Claude가 실제 개발 환경 안에서 다음과 같은 작업을 수행할 수 있다는 것이다.

파일 읽기
코드 수정
명령 실행
테스트 결과 확인
작업 내용 요약

그리고 이 과정에서 권한과 실행 흐름을 제어할 수 있다.

4.1 권한 관리

AI 코딩 에이전트에서 권한 관리는 매우 중요하다.

에이전트가 코드를 수정하거나 명령어를 실행할 수 있다면, 어떤 작업은 허용하고 어떤 작업은 막아야 한다.

예를 들어 다음과 같은 차이가 필요하다.

파일 읽기: 비교적 안전
파일 수정: 확인 필요
bash 명령 실행: 명령 종류에 따라 확인 필요
위험한 삭제 명령: 차단 필요

Claude Code는 이런 권한 관리를 명확히 다룰 수 있다는 점에서 하네스와 오케스트레이션의 연결을 이해하기 좋다.

사용자는 에이전트가 어떤 도구를 사용할 수 있는지, 어떤 명령은 승인받아야 하는지, 어떤 작업은 금지해야 하는지를 설정할 수 있다.

오케스트레이션 관점에서 보면 이 부분은 “실행 단계의 안전장치”에 해당한다.

에이전트가 다음 작업을 결정한다.
  ↓
도구 실행 전에 권한을 확인한다.
  ↓
허용되면 실행한다.
  ↓
제한된 작업이면 사용자 승인 또는 차단이 발생한다.

즉, Claude Code는 모델이 직접 모든 것을 하는 것이 아니라, 실행 환경이 모델의 행동을 감싸고 통제하는 구조를 보여준다.

4.2 Hooks

Hooks는 특정 이벤트가 발생했을 때 자동으로 실행되는 동작이다.

예를 들어 다음과 같은 흐름을 만들 수 있다.

파일이 수정됨
  ↓
자동으로 formatter 실행
  ↓
테스트 실행
  ↓
결과를 다시 에이전트에게 전달

또는 다음과 같은 흐름도 가능하다.

에이전트가 특정 명령을 실행하려고 함
  ↓
hook이 명령 내용을 검사
  ↓
위험한 명령이면 차단
  ↓
안전한 명령이면 허용

이런 구조는 오케스트레이션에서 매우 중요하다.

사용자가 매번 직접 지시하지 않아도, 특정 단계에서 자동으로 실행되어야 하는 작업을 흐름 안에 넣을 수 있기 때문이다.

즉, hooks는 에이전트 작업 흐름에 자동화된 제어점을 추가하는 방식이라고 볼 수 있다.

4.3 Subagent

Claude Code에서는 특정 역할을 가진 subagent를 구성할 수 있다.

예를 들어 다음과 같은 역할 분리가 가능하다.

Code Reviewer Agent
Test Runner Agent
Documentation Agent
Refactoring Agent

이것은 오케스트레이션에서 말하는 “역할 분리”와 연결된다.

하나의 에이전트가 모든 일을 처리할 수도 있지만, 작업이 복잡해질수록 역할을 나누는 편이 더 명확하다.

예를 들어 코드 수정 작업을 다음처럼 나눌 수 있다.

Main Agent: 사용자 요청 이해 및 전체 계획 수립
  ↓
Refactoring Agent: 코드 구조 개선
  ↓
Test Agent: 테스트 실행 및 실패 로그 분석
  ↓
Reviewer Agent: 변경 사항 검토

물론 실제 사용에서는 모든 작업을 이렇게 나눌 필요는 없다.

하지만 subagent 개념은 LLM Agent 오케스트레이션이 단일 답변 생성에서 벗어나, 여러 역할을 조율하는 방향으로 발전하고 있음을 보여준다.

5. OpenCode: 오픈소스 기반의 병렬 세션과 커스텀 Agent

OpenCode는 오픈소스 기반의 AI 코딩 에이전트다. 터미널 중심으로 사용할 수 있고, IDE나 데스크톱 환경과 연결되는 방향도 제공한다.

OpenCode를 오케스트레이션 관점에서 볼 때 핵심은 다음 세 가지다.

오픈소스
custom agent
multi-session

5.1 오픈소스라는 장점

OpenCode의 가장 큰 장점 중 하나는 오픈소스라는 점이다.

오픈소스 도구는 단순히 무료라는 의미만 있는 것이 아니다. 오케스트레이션을 공부하는 입장에서는 내부 구조와 설정 방식을 더 직접적으로 확인할 수 있다는 장점이 있다.

예를 들어 다음과 같은 것들을 살펴보기 좋다.

에이전트 설정 방식
도구 사용 방식
권한 설정 방식
프로바이더 설정 방식
custom agent 구성 방식

즉, OpenCode는 “AI 코딩 에이전트가 내부적으로 어떻게 구성되는지”를 학습하기 좋은 도구다.

5.2 Custom Agent

OpenCode에서는 특정 작업에 맞는 agent를 구성할 수 있다.

예를 들어 다음과 같은 역할을 만들 수 있다.

plan agent
review agent
test agent
docs agent
refactor agent

각 agent는 서로 다른 프롬프트, 모델, 도구 접근 권한을 가질 수 있다.

이 구조는 오케스트레이션에서 말하는 “역할 기반 작업 분해”와 잘 맞는다.

예를 들어 코드 수정 전에는 plan agent가 먼저 전체 구조를 분석하게 할 수 있다.

사용자 요청
  ↓
Plan Agent: 변경 방향 분석
  ↓
Coding Agent: 코드 수정
  ↓
Review Agent: 변경사항 검토

이렇게 하면 에이전트가 바로 코드를 수정하는 대신, 먼저 계획을 세우고 검토하는 흐름을 만들 수 있다.

5.3 Multi-session

OpenCode에서 특히 오케스트레이션과 연결하기 좋은 기능은 multi-session이다.

같은 프로젝트에서 여러 에이전트 세션을 병렬로 실행할 수 있다면, 작업을 나누어 동시에 진행하는 구조를 만들 수 있다.

예를 들어 다음과 같은 작업을 동시에 진행할 수 있다.

세션 A: 로그인 버그 수정
세션 B: 테스트 코드 작성
세션 C: 문서 업데이트
세션 D: 리팩토링 후보 분석

이 방식은 이전 글에서 다룬 병렬 실행 패턴과 연결된다.

작업 A
작업 B
작업 C
작업 D
  ↓
결과 통합

다만 병렬 작업에는 주의점도 있다.

여러 에이전트가 같은 파일을 동시에 수정하면 충돌이 생길 수 있다. 그래서 병렬 작업을 할 때는 다음과 같은 기준이 필요하다.

작업 범위를 명확히 나눈다.
가능하면 파일 단위를 분리한다.
각 세션의 목표를 작게 설정한다.
마지막에는 사람이 결과를 통합하고 검토한다.

OpenCode는 이런 병렬 작업 흐름을 실험하기 좋은 도구로 볼 수 있다.

6. Codex CLI: 로컬 터미널 기반의 OpenAI 코딩 에이전트

이번 글에서는 Codex를 Codex CLI 기준으로 본다.

Codex CLI는 OpenAI의 코딩 에이전트를 로컬 터미널에서 사용하는 방식이다. 즉, 웹 기반 Codex나 앱 중심의 Codex가 아니라, 개발자가 터미널에서 직접 실행하는 도구로 보는 것이다.

Codex CLI의 핵심은 다음과 같다.

로컬 터미널에서 실행
선택한 작업 디렉터리 기준으로 코드 읽기
코드 수정
명령 실행
sandbox와 approval 설정
skills 기반 반복 작업 구조화

6.1 로컬 터미널 중심의 작업 흐름

Codex CLI는 터미널에서 실행된다. 개발자는 프로젝트 디렉터리에서 Codex를 실행하고, 자연어로 작업을 요청할 수 있다.

예를 들어 다음과 같은 요청이 가능하다.

이 프로젝트 구조를 설명해줘.

로그인 실패 원인을 찾아서 수정해줘.

테스트를 실행하고 실패 원인을 분석해줘.

오케스트레이션 관점에서 보면 Codex CLI는 “터미널 기반 에이전트 루프”를 제공한다고 볼 수 있다.

사용자 요청
  ↓
파일 읽기
  ↓
분석
  ↓
수정 제안 또는 코드 수정
  ↓
명령 실행
  ↓
결과 확인
  ↓
최종 보고

터미널에서 바로 실행되기 때문에 개발자가 작업 과정을 확인하면서 이어갈 수 있다는 장점이 있다.

6.2 Sandbox와 Approval

Codex CLI에서 중요한 개념은 sandbox와 approval이다.

AI 코딩 에이전트가 로컬 컴퓨터에서 명령을 실행한다면, 실행 범위를 제한하는 것이 중요하다.

예를 들어 다음과 같은 구분이 필요하다.

읽기만 허용
작업 디렉터리 안에서만 쓰기 허용
네트워크 접근 제한
위험한 명령 실행 전 승인 요청

이것은 이전 글에서 다룬 하네스 엔지니어링과도 연결된다. 오케스트레이션은 전체 흐름을 관리하지만, 각 실행 단계에서는 하네스처럼 권한과 안전장치가 필요하다.

Codex가 명령 실행을 제안한다.
  ↓
sandbox 설정이 실행 범위를 제한한다.
  ↓
approval 정책에 따라 사용자 확인을 요청한다.
  ↓
허용되면 실행한다.

즉, Codex CLI는 로컬 개발 환경에서 “어디까지 에이전트에게 맡길 것인가”를 설정하면서 사용할 수 있는 도구라고 볼 수 있다.

6.3 Skills 기반 반복 작업 구조화

Codex CLI에서 눈여겨볼 부분은 skills다.

반복적으로 수행하는 작업을 매번 긴 프롬프트로 지시하는 대신, skill로 묶어둘 수 있다. 예를 들어 다음과 같은 반복 작업이 있다고 해보자.

PR 리뷰 체크리스트
릴리즈 전 점검
테스트 실패 분석
문서 작성 규칙
블로그 글 작성 규칙

이런 작업은 매번 설명하기보다 skill로 만들어두는 편이 더 안정적이다. 오케스트레이션 관점에서 skill은 “반복 가능한 작업 흐름 패키지”에 가깝다.

사용자 요청
  ↓
관련 skill 호출
  ↓
정해진 절차와 규칙에 따라 작업 수행
  ↓
결과 생성

즉, Codex CLI는 단발성 코딩 요청뿐 아니라 반복되는 개발 작업을 구조화하는 방식으로도 활용할 수 있다.

7. 병렬 작업으로 보는 오케스트레이션의 차이

오케스트레이션의 특성을 가장 잘 보여주는 주제 중 하나가 병렬 작업이다.

단순한 작업은 순차적으로 처리해도 된다.

파일 읽기 → 코드 수정 → 테스트 실행 → 결과 보고

하지만 실제 개발에서는 여러 작업을 동시에 진행하고 싶을 때가 많다.

예를 들어 다음과 같은 요청이 있다고 해보자.

이번 릴리즈 전에 로그인 버그 수정, 테스트 보강, 문서 업데이트를 같이 진행해줘.

이 작업은 하나의 에이전트가 순서대로 처리할 수도 있다.

로그인 버그 수정
  ↓
테스트 보강
  ↓
문서 업데이트

하지만 병렬로 나누면 더 효율적일 수 있다.

이때 중요한 것은 “동시에 많이 돌리는 것”이 아니다.

진짜 핵심은 작업 간 충돌을 줄이고, 결과를 다시 하나로 합치는 구조다.

7.1 병렬 작업에 적합한 작업

병렬 작업은 다음과 같은 경우에 적합하다.

서로 다른 파일 영역을 수정하는 작업
조사와 구현이 분리되는 작업
테스트 작성과 문서 작성이 분리되는 작업
리팩토링 후보 분석처럼 read-only로 가능한 작업

예를 들어 다음과 같이 나눌 수 있다.

Agent A:
인증 관련 코드 수정

Agent B:
인증 관련 테스트 케이스 작성

Agent C:
README와 사용 가이드 업데이트

Agent D:
변경사항 리뷰

이 구조는 오케스트레이션의 병렬 실행 패턴과 잘 맞는다.

7.2 병렬 작업에서 조심해야 할 점

병렬 작업은 좋아 보이지만, 잘못 사용하면 오히려 복잡해진다.

대표적인 문제는 다음과 같다.

두 에이전트가 같은 파일을 동시에 수정한다.
작업 간 의존성이 있는데 독립적으로 처리한다.
결과를 통합하는 단계가 없다.
각 에이전트가 서로 다른 기준으로 코드를 작성한다.
테스트 기준이 통일되지 않는다.

그래서 병렬 작업에는 반드시 통합 단계가 필요하다.

작업 분리
  ↓
병렬 실행
  ↓
결과 수집
  ↓
충돌 확인
  ↓
테스트 실행
  ↓
최종 리뷰

이 통합 단계가 없으면 병렬 실행은 오케스트레이션이 아니라 단순한 동시 실행에 그치게 된다.

7.3 세 도구에서 병렬 작업을 바라보는 방식

세 도구를 병렬 작업 관점에서 보면 다음과 같이 볼 수 있다.

 

즉, 병렬 작업에서 중요한 것은 도구가 자동으로 모든 것을 해결해주는지가 아니다.

더 중요한 것은 사람이 작업을 어떻게 나누고, 에이전트에게 어떤 범위를 맡기고, 마지막에 어떻게 통합할 것인지다.

8. 비교표

세 도구를 오케스트레이션 관점에서 비교하면 다음과 같다.

기준	Claude Code	OpenCode	Codex CLI
기본 성격	Claude 기반 코딩 에이전트	오픈소스 AI 코딩 에이전트	OpenAI의 로컬 터미널 코딩 에이전트
실행 환경	CLI 중심	터미널, IDE, 데스크톱	로컬 터미널
작업 분해	Claude가 계획·탐색·수정 흐름 수행	agent 구성과 세션 분리로 작업 분해 가능	사용자 요청 기반으로 단계적 작업 진행
역할 분리	subagent 구성 가능	primary agent, subagent 구성 가능	skills로 반복 작업 구조화 가능
도구 사용	파일 읽기, 수정, bash 등	read, write, bash, custom tools, MCP 등	코드 읽기, 수정, 명령 실행
권한 관리	permissions, permission mode	permission 설정, agent별 permission	sandbox, approval, permission profile
자동화 확장	hooks, MCP, skills	custom tools, MCP, skills, agents	skills, config, sandbox/approval
병렬 작업	역할 분리 중심으로 접근	multi-session에 강점	여러 터미널/작업 디렉터리로 수동 분리하는 방식이 현실적
장점	구조화된 제어와 안전장치 이해에 좋음	오픈소스와 병렬 실험에 좋음	로컬 터미널에서 OpenAI 모델 기반 작업에 좋음
주의점	설정을 잘못하면 복잡해질 수 있음	자유도가 높은 만큼 설계 기준 필요	병렬·역할 분리는 사용자가 직접 구조화해야 함

 

9. 어떤 도구가 어떤 상황에 적합할까?

도구 선택은 “무조건 무엇이 최고다”로 정리하기 어렵다.

사용 목적에 따라 적합한 도구가 다르다.

Claude Code가 잘 맞는 경우

권한 관리와 승인 흐름을 명확히 두고 싶을 때
subagent로 역할을 나누어보고 싶을 때
hooks를 통해 자동화 흐름을 만들고 싶을 때
Claude 모델 중심으로 개발 작업을 진행하고 싶을 때

특히 에이전트가 어떤 도구를 사용할 수 있고, 어떤 단계에서 자동화가 실행되는지 이해하기 좋다.

그래서 Claude Code는 “구조화된 AI 코딩 에이전트가 어떻게 동작하는지”를 공부하기 좋은 도구라고 볼 수 있다.

OpenCode가 잘 맞는 경우

오픈소스 기반 도구를 사용하고 싶을 때
터미널 중심으로 AI 코딩 에이전트를 쓰고 싶을 때
여러 모델 provider를 비교하고 싶을 때
custom agent와 multi-session을 실험하고 싶을 때
병렬 작업 흐름을 직접 구성해보고 싶을 때

특히 오케스트레이션을 학습하는 입장에서는 OpenCode의 자유도가 장점이 될 수 있다. (실제로도 git hub PR 병렬 작업 할 때 opencode 를 사용해봤는데 꽤 만족했던 경험이 있다.)

내가 원하는 방식으로 agent를 구성하고, 여러 세션을 나누어 작업하면서 병렬 작업 구조를 실험해볼 수 있기 때문이다.

Codex CLI가 잘 맞는 경우

OpenAI 모델 기반으로 로컬 터미널에서 코딩 작업을 하고 싶을 때
sandbox와 approval을 설정하며 안전하게 작업하고 싶을 때
반복되는 개발 작업을 skills로 구조화하고 싶을 때
CLI 중심의 단순하고 직접적인 workflow를 선호할 때

Codex CLI는 특히 “로컬 개발 환경에서 AI 에이전트와 함께 작업하는 방식”을 이해하기 좋다.

또한 skills를 활용하면 자주 반복하는 작업을 일정한 절차로 묶을 수 있다.

예를 들어 다음과 같은 작업을 skills로 만들 수 있다.

PR 리뷰
릴리즈 체크리스트
테스트 실패 분석
블로그 초안 작성
프로젝트 문서화

이렇게 보면 Codex CLI는 단순한 코드 생성 도구가 아니라, 반복되는 개발 작업을 구조화하는 터미널 기반 에이전트 환경으로 볼 수 있다.

10. 정리

이번 글에서는 Claude Code, OpenCode, Codex CLI를 오케스트레이션 관점에서 비교해봤다.

핵심은 다음과 같다.

Claude Code:
permissions, hooks, subagent를 통해 구조화된 작업 흐름과 제어를 이해하기 좋다.

OpenCode:
오픈소스, custom agent, multi-session을 통해 병렬 작업과 역할 분리를 실험하기 좋다.

Codex CLI:
로컬 터미널에서 sandbox, approval, skills를 활용해 안전하고 반복 가능한 작업 흐름을 만들기 좋다.

AI 코딩 에이전트를 비교할 때 중요한 것은 단순히 “어떤 모델이 더 똑똑한가”가 아니다.

더 중요한 질문은 다음과 같다.

작업을 어떻게 나누는가?
도구 실행을 어떻게 관리하는가?
권한과 안전장치는 어떻게 구성되는가?
반복 작업을 어떻게 재사용 가능한 흐름으로 만드는가?
여러 작업을 동시에 진행할 때 어떻게 통합하는가?

이 질문들이 바로 LLM Agent 오케스트레이션의 핵심이다.

앞선 글에서 오케스트레이션을 개념적으로 정리했다면, 이번 글에서는 그 개념이 실제 AI 코딩 에이전트 도구에서 어떻게 나타나는지 살펴봤다.

결국 좋은 AI 코딩 도구를 고른다는 것은 단순히 좋은 모델을 고르는 것이 아니다.

내가 원하는 개발 흐름에 맞게 작업을 나누고, 실행하고, 검증하고, 반복할 수 있는 오케스트레이션 환경을 고르는 일에 가깝다.