Locale: ko
※ 이 글은 2026년 10월 4일 기준 공개 제품 정보와 실제 사용 체감을 구분한다. Astra, Codex, Claude Opus 5.5의 공개 사양은 공식 자료를 확인했다. “Astra는 탐색 범위가 넓어지기 쉽다”, “Dot은 감독 역할에 잘 맞았다”는 표현은 특정 운용에서의 체감이지 보편적인 벤치마크 결과가 아니다. 여기서 Dot은 감독 역할로 쓰는 AI의 호칭이다.
1. 결론: 만능 AI 한 명보다 역할을 나누면 일이 닫히기 쉽다
강한 AI를 보면 전부 맡기고 싶어진다.
조사, 설계, 코드 수정, 테스트, 실패 복구, 진행 관리, 설명까지 한 번에 맡긴다.
사실 한 문장 안에 여러 직무가 들어 있다.
운영에서는 다음처럼 나누면 단순해진다.
- 탐색: Astra — 원인 후보, 대안, 빠진 전제, 설계 위험을 넓게 찾는다
- 감독: Dot — 범위를 줄이고 상태를 추적하며 막힘을 발견하고 다음 행동을 정한다
- 실행: Codex — 코드, 파일, 조사, 테스트 같은 구체 작업을 수행한다
반대로 한 모델이 처음부터 끝까지 안정적으로 끝낼 수 있다면 굳이 팀을 만들 필요도 없다. Anthropic은 Claude Opus 5.5를 에이전트형 코딩, 복잡한 멀티툴 작업, 장시간 업무에 적합한 모델로 설명한다.[5]
핵심은 이것이다.
한 명으로 끝나면 한 명. 일이 퍼지면 역할 분리.
2. 탐색 능력이 강할수록 범위도 커질 수 있다
문제가 정말 모호할 때 탐색형 AI는 매우 강하다.
숨은 의존성을 찾고, 전제를 의심하고, 다른 설계를 제안한다.
하지만 평범한 수정에도 같은 모드가 켜지면 일이 커진다.
“버튼 하나 고쳐줘”가 “컴포넌트 구조부터 다시 보자” “관련 서비스도 확인하자” “확장성도 개선하자” “오래된 의존성도 치우자” 가 된다.
버튼은 아직 고장 난 상태다.
OpenAI Agents SDK도 여러 에이전트의 실행 순서와 다음 행동을 결정하는 문제를 오케스트레이션으로 설명하고, LLM이 결정하는 방식과 코드가 결정하는 방식을 나눈다.[1]
탐색은 강점이다. 완료와 같은 역할로 묶을 필요는 없다.
3. Dot은 천재보다 현장 감독으로 쓰는 편이 좋다
감독에게 필요한 것은 가장 깊은 아이디어가 아니다.
- 지금 무슨 일을 하는가
- 어디까지 끝났는가
- 무엇이 실패했는가
- 다음 담당자는 누구인가
- 몇 번 실패하면 상위 모델로 올릴 것인가
를 관리하는 능력이다.
Astra가 “전체 재설계안이 있습니다”라고 하면 Dot은 “좋다. 별도 작업으로 저장. 지금은 장애 복구”라고 자른다.
Codex 테스트가 실패하면 로그와 함께 다시 보낸다.
같은 실패가 세 번 반복되면 Astra로 올린다.
화려하지 않지만, 공장은 이런 역할이 있어야 멈추지 않는다.
4. Codex는 경계가 명확한 실행 작업에서 다루기 쉽다
Codex에 다음을 정해서 넘긴다.
- 저장소
- 대상 파일
- 증상
- 수정 허용 범위
- 성공 조건
- 실행할 테스트
- 결과 형식
회사 전략을 물을 필요가 없다. 실제 목표가 PR 통과라면 PR 통과에 집중시키면 된다.
OpenAI의 Symphony도 세션보다 issue와 task를 지속되는 작업 단위로 보는 방향을 제시한다.[2]
대화가 일이 아니다. task가 일이다.
모델이 바뀌어도 task 상태가 남아야 한다.
5. thread_id만으로는 부족하다
원래 질문이 있던 곳으로 답을 돌려보내려면 source_thread_id가 유용하다.
하지만 같은 스레드에 질문이 여러 개 있을 수 있다.
그래서 최소한 다음을 나눈다.
- task_id: 어떤 일인가
- source_thread_id: 어디로 답할까
- source_message_id: 어떤 메시지에서 시작됐나
- manager / executor / advisor
- status
- attempt
- next_action
상태는 pending, working, blocked, review, done, delivered, failed 정도만 있어도 크다.
“아마 끝났음”은 상태가 아니다.
6. 평소에는 Dot↔Codex, 어려울 때만 Astra
기본 루프:
Dot → Codex → Dot → Codex
막힐 때:
Dot → Astra → Dot → Codex
Astra를 매번 넣지 않는다.
예를 들어 다음 조건에서만 에스컬레이션한다.
- 같은 실패 3회
- 원인 후보가 여러 개인데 구분할 방법이 없음
- 구조 변경 필요
- 여러 저장소에 걸침
- 요구와 기존 사양이 충돌
그러면 Astra는 상시 회의 참석자가 아니라 난제 전문 담당자가 된다.
7. 잠깐 쓰는 상위 요금제를 영구 인프라로 만들지 않는다
지금 쓸 수 있는 기능이 나중에도 계속 있다는 보장은 없다.
따라서 남겨야 하는 것은 모델 자체가 아니라 운영 지식이다.
- task 상태
- 프롬프트
- 성공 조건
- 테스트
- 재시도 횟수
- 에스컬레이션 규칙
- 실패 로그
요금제를 바꿨더니 업무 프로세스까지 기억을 잃으면 곤란하다.
8. Opus 5.5가 0→10까지 스스로 간다면 그냥 맡겨도 된다
멀티 에이전트 조직도는 재미있다.
감독, 연구원, 실행자, 검토자를 만들 수 있다.
그런데 결국 사람이 봇 회사의 인사총무가 되면 실패다.
Anthropic은 Opus 5.5를 장시간 코딩, 에이전트, 복잡한 멀티툴 작업용으로 설명한다.[5]
실제로 목표만 주면 조사→구현→테스트→수정→완료보고까지 안정적으로 간다면 그쪽이 더 단순하다.
한 명이 티켓을 닫는데 AI 회사를 만들 필요는 없다.
9. 최소 구조는 공유 큐 + 감독 + 실행 + 비상구
- 질문과 장애를 task_id와 함께 큐에 넣는다.
- Dot이 우선순위와 다음 행동을 정한다.
- Codex가 실행한다.
- Dot이 결과를 확인한다.
- 규칙에 걸릴 때만 Astra로 올린다.
- source_thread_id로 답을 돌린다.
- delivered 확인 후 닫는다.
- 처음부터 끝까지 한 번에 가능한 일은 Opus 5.5에 바로 맡긴다.
인프라에는 모델명이 아니라 역할을 저장한다.
manager executor advisor
나중에 모델을 바꿔도 구조는 남는다.
10. 정리: AI를 늘리는 게 자동화가 아니다
AI 운영에서 어려운 것은 생각을 더 하는 일이 아니다.
언제 생각을 멈추고 실행으로 넘어갈지를 정하는 일이다.
탐색은 지도를 넓힌다. 감독은 일을 닫는다. 실행은 손을 움직인다.
잘 나누면 대화가 이렇게 짧아진다.
Astra: “대안 7개 찾음.” Dot: “2번만 검증.” Codex: “수정, 테스트 통과.” Dot: “종료.”
갑자기 회사가 됐다.
Keep the loop tight.
AI 숫자가 많다고 자동화가 아니다.
사람이 계속 구조하러 들어가지 않아도 검증된 종료 상태까지 가는 것이 자동화다.
