채널톡 사내 AI 에이전트 채널랩스를 v1에서 v2로 개선한 기록이다. 에이전트는 본질적으로 비결정론적이라 같은 질문에도 매번 다른 도구를 다른 순서로 부르는데, 프로덕션 시스템은 비용이 예측 가능하고 잘못된 호출이 차단되며 토큰이 새지 않아야 한다. 자체 구현 agent loop를 OpenAI Agents SDK로 옮기고, 그 위에 컨텍스트 설계 패턴 세 가지를 얹었다.
핵심 포인트- v1은 스킬 문서 총 168KB(약 42,000 토큰)를 매 턴 다시 주입해, 5턴만 돌아도 누적 16만 토큰을 차지했다.
- 파일 첨부를 첫 메시지에 inline으로 박아 넣어 나중에 다시 조회할 방법이 없었다. 모델이 까먹으면 그걸로 끝이었다.
- 인증 토큰이 만료되면 사용자가 채팅창에 새 토큰을 직접 붙여 넣어야 했다. 보안과 사용성 양쪽에서 자연스럽지 않았다.
- v2는 위험한 호출을 프롬프트로 부탁하지 않고 실행 직전에 허용된 method와 path 조합인지 코드가 검사한다.
- SDK 전환만으로 문제가 사라지지 않았다. 매 턴 모델에게 무엇을 보여줄지는 여전히 애플리케이션이 결정해야 했다.
상세 정리- 제품 맥락: 채널랩스는 ALF 설정과 채널 운영 작업을 자연어로 다루는 사내 도구로, AX와 세일즈 인원 및 외부 고객사가 사용자다.
- 사용 패턴 1 진단: 채널 ID만 던지면 어떤 지식·규칙·태스크가 활성화돼 있고 무엇이 누락됐는지 API로 긁어와 정리한다. 평소엔 콘솔을 여기저기 클릭하며 확인하던 작업이다.
- 사용 패턴 2 일괄 등록: 문의 유형과 응대 분기, 안내 멘트, 상담사 연결 조건이 수십 행에 걸친 엑셀을 채팅창에 첨부하면 에이전트가 읽고 구조를 분석해 API로 한 번에 등록한다. 이전에는 파일을 보며 콘솔에서 한 항목씩 옮겨 적어야 했다.
- 사용 패턴 3 자연어 시나리오: 고객사는 분기 노드나 메모리 변수 같은 챗봇 내부 모델을 모르고 "어떨 때는 X, 어떨 때는 Y" 식으로 던지는데, 이를 분기 처리 노드와 정보 기억 노드, 외부 API 호출 노드, 상담사 연결 액션 노드로 분해한다.
- 한 세션에서 채널 설정 진단부터 파일 첨부, 자연어 시나리오, 추가 수정까지 이어져 콘솔에서 30분~1시간 걸리던 세팅이 채팅 몇 줄로 끝난다. 즉 단순 설정 챗봇이 아니라 수십 턴을 도는 작업 실행 에이전트다.
- v1의 구조적 문제 1: agent loop가 아니라 단발성 Message API의 반복 호출이었고, 토큰 잘라내기와 캐싱 마커 부착, 도구 호출 라우팅, 스트리밍, 사용량 집계를 전부 수작업으로 들고 있었다. 표준 세션·상태·에러 모델이 없어 스트리밍 중 취소나 도구 호출 실패 재시도, 병렬 호출 같은 코너 케이스마다 따로 막아야 했다.
- v1의 문제 2: "필요할 때 읽는 스킬"이 아니라 "처음부터 전부 들고 있는 스킬"이었다.
- v1의 문제 3: 파일 저장 모델이 임시 저장소와 세션 저장소로 이중화돼 있고 두 개의 업로드 엔드포인트가 있었다.
- v1의 문제 4: 한 사용자가 여러 채팅을 동시에 진행할 수 없는 구조였다.
- v2 route 분리: HTTP 처리와 실제 작업 로직을 나눠, route는 동시 실행 잠금과 SSE 스트림을 여는 일까지만 하고 그래프·세션·도구·실행 책임은 runtime 레이어로 넘긴다.
- v2 세션 처리: 메시지 저장과 불러오기를 agent loop 바깥의 세션 구현으로 분리해, v1에서 메인 로직 사이사이에 흩어져 있던 처리를 runtime이 세션 인터페이스로 일관되게 다룬다.
- v2 요청 컨텍스트: 세션 ID, 사용자 ID, 실행 환경, 취소 신호, 인증 토큰 공급자를 하나의 runtime context로 묶는다. 도구는 전역 상태나 사용자 메시지에 섞인 값에 의존하지 않아, 같은 사용자가 여러 채팅을 동시에 실행해도 도구 실행 상태가 섞이지 않는다.
- v2 guardrail: 모델이 채널 API를 호출하려 할 때 허용 목록 밖이면 모델이 요청해도 실행되지 않는다. 프롬프트에 조심하라고 부탁하는 것이 아니라 코드가 실행 경계를 강제한다.
- 역할 분담: SDK의 Runner가 모델 호출과 tool call, tool result 반영, 다음 턴 진행을 맡고, 애플리케이션 runtime의 allowlist와 validator가 실행 전 차단을 맡는다.
- 캐싱 효과: v2에서 동적 정보를 system prompt 밖으로 빼면서 공통 prefix를 안정적으로 유지할 수 있게 돼 prompt caching이 적용되기 쉬운 구조가 됐고, 반복되는 prefix는 cached token으로 처리된다.
- 그런데도 누적 토큰이 줄지 않은 이유는 매 턴 누적되는 tool output 때문이다. 입력이 커질수록 비용과 latency가 늘고 모델이 실제로 봐야 할 정보의 밀도도 낮아진다.
- 패턴 1 파일 lazy loading: 파일 업로드와 모델이 본문을 읽는 동작을 분리해 저장 계층과 모델 입력 계층 두 곳에 적용했다.
- 기존 방식의 문제 둘: DB에 큰 텍스트 본문이 누적돼 100KB 파일을 올리면 row가 그만큼 무거워지고, 사용자 질문이 "안녕"이어도 100KB가 매 요청에 따라간다.
- 새 구조: 본문은 S3에만 두고 서버는 필요할 때만 다운받으며 자주 호출되는 파일은 메모리 캐시에 둔다. LLM 컨텍스트에는 파일 이름과 ID만 들어가고 본문은 모델이 명시적으로 tool call 할 때만 들어간다.
- 여기에 "로드할 때도 범위 제한"을 추가했다. 모델이 큰 값을 요청해도 서버가 잘라낼 수 있도록 파라미터를 두고, 키워드와 주변 줄만 반환하는 grep 같은 도구도 만들어 100KB 로그에서 특정 단어가 있는 줄만 볼 수 있게 했다.
- 오버엔지니어링이 아니냐는 반문에 대한 답: 한 번 보고 답하면 되는 요약 작업이라면 직접 첨부가 가장 단순하다. 하지만 수십 턴을 도는 작업 실행 에이전트에서는 파일을 봐야 하는 턴이 일부뿐이라 매 턴 전체가 들어가면 비용이 계속 누적된다.
- Anthropic의 coding agent flow도 같은 방향을 보여준다며, 에이전트는 파일 본문을 항상 들고 있는 것이 아니라 environment에 질의하고 결과를 받아 다음 행동을 정한다고 인용한다. 파일은 컨텍스트 안의 덩어리가 아니라 필요할 때 도구로 조회하는 외부 데이터라는 관점이다.
- 자평: OpenAI가 제공한 모양 그대로 받아 쓰고 자사 에이전트의 동작 패턴에 맞춰 재설계하지 않은 것이 문제였다고 정리한다.
- 패턴 2 채널 컨텍스트: 사용자는 5개에서 50개까지 채널을 갖는데, 매 요청마다 접근 가능한 전체 목록을 모델 입력에 넣었다. 채널 10개만 있어도 턴당 약 2,000 토큰이 추가돼 10턴이면 목록에만 약 20,000 토큰이 누적된다.
- 더 큰 문제는 대부분의 세션이 실제로는 한 채널만 다룬다는 점이었다. 매 턴 전체 목록을 보여주는 것은 비용으로도 추론으로도 낭비라, 작업 대상만 전달하는 방향으로 바꿨다.
왜 읽나LLM 에이전트를 사내 운영 도구로 굴리며 토큰 누적과 권한 통제에 부딪힌 팀에게, 자체 루프에서 SDK로 옮길 때 무엇이 해결되고 무엇이 남는지 그리고 컨텍스트를 줄이는 구체적 패턴을 준다.
채널톡·
Stack Overflow Blog·
LINE Engineering·
AWS Korea Tech·