[🛠] AI Orchestration #3: Telegram으로 목표만 던져본 AI Orchestrator 도그푸딩

✨ GPT-5.6 Sol의 요약 　

프로젝트 경로도 Agent도 지정하지 않고 Telegram으로 결과만 요청해 PDF와 XLSX를 돌려받기까지, 직접 써보며 막힌 곳을 하나씩 고친 기록.

Telegram 자연어 목표 지시와 프로젝트 자동 탐색

Telegram에서 “이 결과를 만들어줘”라고 말하면 AI Orchestrator가 프로젝트를 찾아 작업을 나누고, 문제가 있는 결과는 다시 고쳐서 파일로 보내주길 바랐다. Codex 한 번 호출해 답변만 받는 수준이면 굳이 Orchestrator를 만들 이유가 없었다.

처음 걸린 건 권한이었다. 직원별 Cell 안에서도 시스템 전역 Codex 제한 때문에 처음 연 Workspace 밖의 프로젝트를 찾기 어려웠다. 같은 macOS 사용자가 소유한 프로젝트는 직접 탐색할 수 있게 이 제한을 걷어내고, push·배포·외부 발송처럼 밖으로 영향을 주는 작업만 실행 직전 승인을 남겼다.

Telethon CLI의 Topic별 응답·첨부파일 회수

Telethon 기반 CLI로 AI Orchestrator Bot에 명령을 보내고 응답과 첨부파일을 다시 받게 했다. 인증정보와 사용자 Session은 저장소 밖에 두고, 프로젝트별 Topic을 작업 단위로 사용했다.

그런데 처음 돌린 CLI는 메시지 전송만 끝내고도 성공처럼 종료될 수 있었다. 정작 Bot의 최종 응답이나 파일이 오지 않았는데 명령은 성공한 셈이었다.

완료 기준을 로컬 명령 종료가 아니라 실제 Telegram 응답과 첨부파일 수신으로 바꿨다. 서로 다른 Topic에서 작업을 동시에 보내도 각 OpenClaw Session은 문맥을 따로 유지했고, 결과도 원래 Topic으로 돌아왔다.

OpenClaw Session과 Codex 병렬 실행의 역할 분리

OpenClaw가 직접 만든 짧은 작업에서는 완료 이벤트가 유실됐지만, Codex native sub-agent는 병렬 작업의 결과를 안정적으로 모았다. 작업은 끝났는데 완료를 회수하지 못하는 구조를 Orchestrator의 실행 기준으로 쓸 수는 없었다.

OpenClaw의 Task Flow만으로는 하위 작업의 실행과 완료 상태를 하나의 기준 기록에 묶기 어려웠다. 그래서 Task Flow를 단일 기준으로 쓰지 않고, OpenClaw는 Telegram·Topic·Session·Memory를, Codex는 프로젝트 탐색·작업 분해·병렬 실행·통합·재검증을 맡겼다.

Telegram 진행 상태 스트리밍

긴 작업에서 아무 말이 없으면 멈춘 건지 알 수 없고, 내부 명령을 그대로 내보내면 Telegram이 터미널 덤프처럼 보였다. 진행 중에는 한국어 상태만 최대 네 줄로 갱신하고, 최종 결과가 오면 그 메시지를 지웠다.

이제 Telegram만 보고도 자료를 찾는 중인지 결과물을 만드는 중인지 구분할 수 있었다.

Agent·Skill·Tool 자동 선택과 산출물 재검증

개별 기능이 붙은 뒤에는 일부러 가장 귀찮은 방식으로 시험해봤다. 내가 최상위 결정권자 역할을 하고 Codex에는 CEO 대행 역할을 맡긴 뒤, AI Orchestrator에 결과만 지시했다. 프로젝트 경로, 모델, Agent, Skill, Tool과 실행 순서는 하나도 지정하지 않았다.

AI Orchestrator는 관련 프로젝트를 찾고 필요한 Skill과 Tool을 골라 기획·기술·검증 역할의 Codex native sub-agent를 병렬 실행했다. 내가 경로와 방법을 알려주지 않아도 누가 무엇을 할지 스스로 나눈 것이다.

돌아온 PDF와 XLSX도 한 번에 멀쩡하지는 않았다. PDF는 TTC 글꼴 때문에 깨진 한글을 TTF로 바꿔 다시 렌더했고, XLSX는 어긋난 날짜 표시와 열 구성을 고친 뒤 전체 시트의 수식과 표시를 다시 검사했다.

요청한 지 22분 6초 뒤, CEO Pilot 의사결정 PDF와 2주 실행관리 XLSX가 원래 Telegram Topic으로 돌아왔다. Telegram에서 다시 내려받은 파일의 SHA-256도 생성본과 같았다. 메시지만 완료라고 말한 것이 아니라 실제 파일이 왕복한 것이다.

단일 사용자 E2E 검증과 다중 사용자 격리 과제

단일 사용자 E2E는 끝까지 이어졌지만 22분은 일상적인 작은 업무를 맡기기에 아직 길다. 최종 산출물도 만든 Agent가 다시 검증했으니 독립 검증이라고 부를 수 없다. 모든 하위 작업 상태를 하나의 Task Graph에서 관리하고 최종 완료를 한 번만 확정하는 controller, 직원별 Session 격리도 아직 직접 시험하지 못했다.

다음 도그푸딩에서는 두 직원의 Session이 정말 섞이지 않는지부터 확인해야 한다. 그다음에는 22분 걸린 흐름에서 가장 오래 막힌 구간을 찾아야 한다. 이 두 가지를 통과해야 개인용 도그푸딩에서 직원이 함께 쓰는 시스템으로 넘어갈 수 있다.