Claude 작업 결과를 Telegram 봇 하나로 모으려면 모델 호출 경로뿐 아니라 답이 돌아갈 대화와 최종 전달 책임을 정해야 합니다. 이 글은 복사해서 실행하는 연동 설정이 아니라, 2026년 4월 12일의 통합 설계와 구현 전에 결정할 전달 상태 기준을 다룹니다.
원하는 동작은 간단했습니다. Telegram에서 작업을 요청하면 Claude가 처리하고, 결과는 정해진 봇 하나를 통해 돌아오는 것. 사용자가 내부 에이전트의 실행 경로까지 알 필요는 없었습니다.
하지만 2026년 4월 12일의 작업 기록에는 응답 경로를 비교하고 통합 방향을 정하는 과정이 남아 있습니다. 작업을 실행하는 경로와 사용자에게 결과를 전달하는 경로가 같은 문제가 아니었기 때문입니다.
이 글은 구현 완료 보고가 아니라 당시의 설계 판단을 정리한 글입니다. 원문에도 실제 통합은 다음 작업으로 남아 있습니다. 확인하지 않은 설정이나 성공 로그를 보태기보다, 어떤 책임을 먼저 나눠야 하는지와 구현 전에 확인할 항목을 설명하겠습니다.
결과가 생성되어도 전달이 끝난 것은 아닙니다
모델이 답을 생성했다는 사실만으로 Telegram 사용자의 요청이 완료되지는 않습니다. 결과가 다른 대화방으로 가거나, 어느 요청의 답인지 알아보기 어렵다면 사용자는 다시 물어봐야 합니다.
당시 기록에서는 bridge escalation 경로와 ACP/session-direct 경로를 비교했습니다. 이 이름들은 원문에서 구분한 내부 경로의 명칭입니다. 특정 버전의 공통 설정 키나 그대로 복사해 쓸 API 이름을 뜻하지는 않습니다.
기록에 남은 결정은 요청 처리를 한 경로로 모으고, 조정 역할과 전달 역할을 분리하는 것이었습니다. 이를 독자 관점에서 풀면 다음 세 가지 질문으로 정리할 수 있습니다.
| 역할 | 먼저 답해야 할 질문 |
|---|---|
| 요청 접수 | 어느 대화에서 시작된 무슨 작업인가요? |
| 작업 실행 | 누가 처리하며, 결과와 실패를 어디에 돌려주나요? |
| 사용자 전달 | 어느 봇이 어느 대화에 최종 결과를 보내나요? |
각 단계가 끝났다는 기준이 다릅니다. 실행자는 결과를 만들고, 전달자는 사용자가 받을 수 있는 위치에 결과를 보내야 합니다.
한 봇으로 모으자는 결정의 의미
아래는 당시 결정을 설명하기 위한 개념도입니다. 실제 배포 설정을 추출한 그림은 아닙니다.
Telegram 요청
-> 조정자: 요청과 돌아갈 대화 식별
-> 실행자: Claude 작업 수행
-> 조정자: 결과 또는 실패 상태 확인
-> 지정된 전달 봇: 원래 대화로 응답
이 구조에서 사용자에게 답을 보내는 책임은 한곳에 있습니다. 실행자가 직접 사용자에게 응답하는 우회 경로를 함께 열어두면, 통합한 경로와 어떤 관계인지 다시 정의해야 합니다.
그렇다고 모든 시스템에서 단일 전달자가 정답이라는 뜻은 아닙니다. 한곳으로 모으면 흐름을 설명하기 쉬워지는 대신, 그 지점이 막힐 때 결과 전달도 함께 지연될 수 있습니다. 처리량과 장애 대응이 더 중요한 환경이라면 다른 설계가 필요할 수 있습니다.
이번 목표는 여러 실행 경로를 사용자에게 노출하지 않고 하나의 대화 흐름을 유지하는 것이었습니다. 그 목적에 맞춰 책임을 먼저 좁혔습니다.
구현 전에 정해둘 성공 기준
다음은 이 설계를 실제로 적용할 때 사용할 수 있는 테스트 목록입니다. 당시 통과한 테스트 결과가 아니라, 앞으로 확인해야 할 조건입니다.
| 시험 상황 | 확인할 결과 |
|---|---|
| 일반 요청 하나 | 지정한 봇이 원래 대화에 최종 응답을 보냄 |
| 같은 대화에서 연속 요청 | 각 응답이 어느 요청에 대한 것인지 구분됨 |
| 실행 실패 | 성공한 것처럼 답하지 않고 실패 상태가 전달됨 |
| 처리가 오래 걸리는 요청 | 진행 안내와 최종 결과를 구분할 수 있음 |
| 전송 응답을 받지 못한 경우 | 실제 전송 여부를 확인하기 전 무조건 재전송하지 않음 |
| 작업 취소 | 취소 이후의 결과를 어떻게 처리할지 규칙이 있음 |
특히 재시도는 “한 번 더 보내면 된다”로 끝나지 않습니다. 전송은 성공했는데 확인 응답만 놓쳤을 수도 있기 때문입니다. 요청을 구분할 식별자와 전송 상태를 어디에 남길지 함께 설계해야 합니다. 이 표가 중복 없는 전달을 보장해 주는 것은 아닙니다.
재시도는 실패한 단계만 대상으로 정합니다
이 설계에서 특히 먼저 정하고 싶은 것은 실행을 다시 할지, 이미 만든 결과를 전달할지만 다시 확인할지입니다. 둘을 한꺼번에 재시도하는 대신 다음처럼 판단 지점을 나누겠습니다. 아래는 제안하는 운영 규칙이며 구현된 동작은 아닙니다.
- 실행 실패, 결과 없음
- 실패 이유와 재실행 허용 범위를 확인합니다. 사용자에게 보낼 실패 안내도 최종 전달자가 맡도록 책임을 정합니다.
- 실행 완료, 아직 미전송
- 보관한 결과와 원래 요청의 연결을 확인하고 전달 단계부터 검토합니다. 모델 작업을 다시 해야 하는 이유가 있는지 먼저 묻습니다.
- 전송 결과 확인 불가
- 성공 또는 실패로 임의 확정하지 않고 확인 대기로 남깁니다. 중복 전달 가능성을 검토한 사람이 다음 조치를 정하도록 합니다.
- 취소 후 결과 도착
- 최종 결과를 그대로 보낼지, 취소 상태만 알릴지 사전에 정한 규칙을 적용할 대상으로 구분합니다.
요청을 받는 역할과 무거운 작업을 수행하는 역할의 분리는 AI 에이전트 오케스트레이션 운영 기록으로 이어집니다. 이번 글의 초점은 그 이후, 누가 사용자에게 마지막 답을 책임지는가에 있습니다.
기록은 사람이 경로를 따라갈 수 있을 만큼만
디버깅 기록에는 적어도 요청 식별자, 실행 상태, 전달 상태가 서로 연결되어 있어야 합니다. 반대로 봇 토큰, 개인 대화 ID, 대화 전문을 공개 문서에 남길 이유는 없습니다.
아래는 기록 항목을 논의하기 위한 예시입니다. 설치 파일이나 실행 가능한 설정이 아닙니다.
요청 식별자: 임의의 내부 참조값
요청 접수: 확인됨 / 미확인
작업 실행: 대기 / 진행 / 완료 / 실패 / 취소
결과 전달: 미전송 / 전송 확인 / 확인 불가
다음 조치: 담당자가 확인할 항목
“모델이 끝났으니 작업도 끝났다”는 보고보다, 실행은 끝났지만 전달 확인은 남아 있다는 보고가 더 유용합니다. 다음 사람이 어디서부터 확인해야 할지 알 수 있기 때문입니다.
이 사례에서 정리한 것은 복잡한 에이전트 기능이 아니라 답변의 출구였습니다. 비슷한 구성을 만들고 있다면, 모델을 추가하기 전에 누가 최종 응답을 책임지는지부터 적어두는 편이 좋겠습니다.
사례 기준일: 2026-04-12. 기존 설계 기록을 2026-09-03에 재구성했습니다. 통합 구현과 전달 안정성은 이 글에서 검증 완료로 주장하지 않습니다.
편집 보완: 2026-09-10. 당시 경험과 기록은 유지하고 읽기 흐름과 판단 기준을 보강했습니다. 이번 편집을 위해 새로운 실행·측정·복구 시험을 수행하지 않았습니다.