지난 5월 27일과 6월 10일, 요즘IT는 ‘클코나잇 2’ 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 “고수의 경험을 나눠 받을 수 있는 기회”, “찐 실무자의 현장감 넘치는 사례”, “다음에 또 오고 싶은 웨비나” 등의 반응을 보였습니다. 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

이 발표는 클코나잇 2 웨비나의 ‘클로드 코드, 채널 기반으로 쓰는 방법’으로 “6월 15일부터 Agent SDK와 헤드리스 모드가 별도 크레딧으로 전환된다”는 앤트로픽 공지를 전제로, 구독 사용량을 따라가는 라이브 세션을 우회 런타임으로 활용하는 방법을 다뤘습니다. 그런데 발표 다음 날인 6월 16일, 앤트로픽은 해당 전환을 철회하고 기존 정책을 유지한다고 안내했습니다.

따라서 지금은 이 글에 담긴 우회 구현을 직접 만들 이유가 없으며, Agent SDK를 그대로 가져다 쓰면 됩니다. 그럼에도 이 기록을 남기는 건, 리서치 프리뷰 기능인 Claude Channel을 실무자가 실제 자동화에 어디까지 활용했는지 보여주는 구현 사례이고, 여기 담긴 에이전트 간 대화 설계나 권한 분리 같은 접근은 이 정책 변경과 무관하게 참고할 만하다고 봤기 때문입니다.

클코나잇을 두 시즌 운영하며, 여기서 소개된 사례가 모델 개발사의 기능 추가로 금세 빛이 바래는 경우를 여러 번 지켜봤습니다. 믿었던 것과 공들여 만든 것이 하루아침에 무너지기도 하는 환경이지만, 그 속에서 현장 실무자가 쌓아온 시도를 기록하는 일에는 그 자체로 가치가 있다고 생각합니다.

발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요, 교보DTS 정보보안센터에서 일하는 이용학입니다. 오늘은 조금 교육적으로 가보려고 합니다. 제가 발표할 주제는 클로드 코드 자동화를 헤드리스 모드에서 채널 기반 세션으로 옮기게 된 이야기이고, 그 과정에서 클로드 코드의 기본적인 개념도 함께 다뤄볼 생각입니다.

아젠다는 총 5개입니다. claude -p 기반 자동화를 왜 채널 기반으로 바꿨는지, MCP와 채널의 기본 개념, 실제로 채널로 돌아가는 작업 한 바퀴, 채널을 이용해 코딩 에이전트를 오케스트레이션하는 방법, 그리고 스크린샷 데모로 진행하겠습니다.

헤드리스 모드(claude -p)는 왜 자동화에 좋았을까?

먼저 클로드 헤드리스 모드, 그러니까 claude -p가 어떤 건지부터 간단하게 짚고 넘어갈게요. 이 명령어는 한마디로 터미널에서 실행하는 명령어입니다. -p 플래그를 통해 뒤에 프롬프트를 입력하면, 사람 승인 없이 프롬프트가 전달돼 터미널의 표준 출력(standard output)으로 결과가 나오고, 그 세션은 종료됩니다.

이게 왜 자동화에 좋았냐면요.

스크립트로 만들 수 있습니다. 터미널에서 입력할 수 있는 명령어는 스크립트, 즉 명령어가 모인 파일로 만들 수 있거든요.
배치로 실행할 수 있습니다. 만든 스크립트를 cron 같은 스케줄러에 등록해 두면 매일 규칙적으로 도는 배치 작업으로 만들 수 있어요.
API처럼 호출할 수 있습니다. claude -p 명령어를 API 호출하듯 쓸 수 있었어요.

다만, 단점도 있습니다. 헤드리스 모드는 기본적으로 스테이트리스(stateless)합니다. 물론 이어가기 옵션이 있긴 하지만, 기본적으로 매 호출이 독립적이고 세션과 맥락이 초기화된다는 단점이 있었습니다.

미국 증시 브리핑을 자동화했더니 생긴 문제

예시를 하나 들자면, 제가 요즘 투자에 관심이 많아서 미국 증시 브리핑 같은 걸 만들었었어요. 미국 증시의 현재 지수와 여러 지표, 핵심 테마와 해석, 그리고 제가 관심 있어 하는 개별 종목까지 클로드 헤드리스 모드 하나로 다 자동화를 해놨었습니다.

그런데 문제가 생겼습니다.

첫 번째 문제는 상당히 비효율적인 토큰 소모량이었습니다. 한 번 돌릴 때마다 맥스 5x 플랜 기준 23% 정도를 사용했어요.

두 번째는 제가 발표 자료를 준비하면서 알게 된 건데, 헤드리스 모드가 별도 크레딧으로 분리된다*는 점입니다. 이전에는 구독 사용량에서 차감이 됐다면, 6월 15일부터는 별도 크레딧으로 전환돼요. 크레딧이 플랜에 따라 지급될 거고요. 첫 번째 단점과도 굉장히 연관되는 게, 한 번 돌릴 때마다 꽤 먹는 작업이 크레딧을 소모하게 된다면 그렇게 많이 돌릴 수가 없겠죠.

*발표자 주: 지난 6월 16일, 앤트로픽에서 “Agent SDK와 헤드리스 모드는 크레딧 사용으로 전환되는 것이 아닌, 기존 정책(클로드 구독 사용량을 따라가는 방식)을 유지한다”라는 메일을 보냈습니다. 해당 정책 변경이 철회됨에 따라, 이 문제는 유효하지 않습니다. 따라서 Claude Agent SDK, 혹은 헤드리스 모드를 사용하면 발표 자료와 같이 복잡한 구현을 진행하지 않아도 됩니다. 추상화가 잘 되어 있어 사용자들은 가져다 쓰기만 하면 되니까요. 다만, “리서치 프리뷰 기능인 클로드 채널을 이렇게도 쓸 수 있구나”하는 관점에서 좋은 활용사례 자료로 볼 수 있다고 생각합니다.

이 문제를 풀어보려다 클로드 채널이라는 것을 발견하게 됩니다. 그 전에 핵심을 말씀드리면, 대화형 세션( CMD나 파워셸에서claude를 입력해 접속한 세션)은 구독 사용량을 따라가지, 크레딧이 별도로 차감되는 형태가 아닙니다. 기본적으로 추가 사용량을 과금하지 않는 선에서요. 이게 이번 구조의 핵심적인 통찰이자 가정입니다.

MCP는 풀(Pull), 채널은 푸시(Push)

본격적으로 채널 활용을 설명하기 전, 알아야 할 기본 개념이 있습니다.

바로 MCP입니다. MCP는 모델 컨텍스트 프로토콜(Model Context Protocol)이라고 하는데, 말 그대로 표준이에요. 프로토콜은 규약, 약속, 규칙을 의미하거든요. 클로드에 MCP 서버를 갖다 물리면, MCP 서버가 도구나 리소스를 가지고 있습니다. 여기서 데이터는 그 MCP 서버만 바라보고 있는 외부 URL이 될 수도 있고, 정적인 데이터가 될 수도 있겠죠. 핵심은 기본적으로 풀(Pull), 당기는 구조라는 겁니다. 클로드가 필요에 따라 MCP 서버를 호출하는 구조예요.

클로드 채널은 MCP를 뒤집은 거예요. MCP는 기본적으로 풀하는 구조라고 했잖아요. 그런데 채널은 클로드 세션에 푸시(Push)를 할 수 있습니다. 클로드가 풀하는 게 아니라, 외부 이벤트나 작업과 같은 것들을 클로드 코드 세션에 푸시를 하는 구조입니다. 클로드로 푸시를 하는 구조입니다.

예시를 들면, 외부에서 이벤트가 발생한 거예요. 채팅을 입력할 수도 있고, CI/CD 과정에서 CI가 실패해 웹훅으로 연동됐다거나, 모니터링 서비스에서 알림이 발생했을 때, 이걸 채널로 보내면 실행 중인 클로드 세션에 알림(notification) 형태로 푸시가 되는 구조예요. 단방향도 지원하고 양방향도 지원합니다. 단방향은 말 그대로 푸시만 하고 클로드가 받아들이기만 하는 거고, 양방향은 클로드가 푸시된 알림을 받았을 때 다시 되돌려줄 수 있는 방법이 있어요. 뒤에서 ‘리플라이 툴(reply tool)’이라고 언급할 겁니다.

최종적으로 비교 아닌 비교를 해보자면 이렇습니다.

MCP는 프로토콜이고, 채널은 그 프로토콜을 구현한 기능
MCP는 풀 구조로 동작하고, 채널은 푸시이지만 양방향도 가능
서로 대립 관계가 아니며, MCP가 조금 더 상위 개념

헤드리스 모드와도 한 번 더 비교해 보면, 클로드 헤드리스 모드는 이어가기 옵션은 있으나 일회성 세션이고, 표면은 에이전트 SDK 쪽으로 병합되면서 별도 크레딧이 부과될 거고요. 채널은 터미널에서 claude를 입력하는 방식으로 동작하는 인터랙티브 클로드 세션이기 때문에 구독풀로 추정되지만, 확정은 아닙니다. 채널이라는 기능 자체가 리서치 프리뷰, 그러니까 실험실 기능 같은 맥락이거든요.

전체 구조: 컨트롤러 → 세션 런처 → MCP 서버 → 클로드 코드 세션

이제 제가 이걸 어떻게 구현했는지, 인터페이스 관점에서 말씀드릴게요. 총 4개의 계층이 있어요. 컨트롤러, 세션 런처, MCP 서버, 그리고 클로드 코드 세션입니다.

처음에는 작업을 만드는 과정이 필요합니다. 이 작업은 정말 뭐든 될 수 있어요. 미국 증시를 분석한다든가, 클로드 코드를 코덱스(Codex)와 대화시킨다든가, 알림 이벤트를 읽게 한다든가 하는 작업이 있겠죠. 이 작업에 채팅 ID를 붙여서 만들고, 세션 런처가 클로드 코드를 PTY 형태로 실행합니다.

PTY는 의사 터미널(pseudo-terminal)인데요. ‘슈도 터미널(의사 터미널)’라고, 가짜 터미널을 실행해서 그 위에 클로드 코드 세션을 띄우는 겁니다. 그리고 그 가짜 터미널 안에 띄워진 세션 안에 브릿지를 통해 알림 형태로 작업을 넣고, 클로드 코드가 그걸 읽고 리플라이 툴로 다시 컨트롤러에게 반환하는 과정이에요.

조금 더 디테일하게 보겠습니다. 컨트롤러의 ‘작업’은 거창한 오케스트레이터 같은 게 아니에요. 그냥 작업입니다. 말 그대로 “오늘 6월 10일 미국 증시 브리핑을 할 거고, 분석 항목은 이런 것들이고, 산출물은 한국어로 핵심 소식 4가지, 그리고 불장·베어장인 이유를 담고, 리플라이 툴을 호출해라”라고 지시하는 거고, 이게 진입점입니다.

세션 런처는 MCP Config를 넘겨서 채널을 실행하게 합니다.

이때 ‘--dangerously-load-development-channels’ 플래그를 쓰는데요. 채널 기능 자체가 리서치 프리뷰 기능이다 보니 외부 MCP 채널을 기본적으로 허용하지 않아요. 지금 허용하는 게 아마 텔레그램이나 슬랙, 디스코드 이런 쪽일 텐데, 저는 자체적으로 개발한 서버를 열고 싶기 때문에 이 플래그를 사용해 주는 거고요. 네임은 세션 네임이라고 보시면 됩니다.

이렇게 띄운 클로드 코드 세션 안에 채팅 ID와 함께 알림을 넘기게 됩니다. 채팅 ID를 왜 넘기냐면, 이것도 앤트로픽이 정의한 하나의 인터페이스이고, 여러 개의 작업을 병렬로 돌릴 때 채팅 ID로 구분하기 위해서라고 합니다. 채팅 ID와 완료 규칙(리플라이 툴을 통해 답을 회수해야 하니까 적은 규칙), 그리고 지시가 들어가게 됩니다.

이런 알림이 클로드 세션에 들어가면, 클로드 세션은 작업을 이어받아 시작합니다. ‘미국 증시 분석할 건데, 시장 데이터 수집하고, 매크로 뉴스 확인.’ 그리고 끝나면 리플라이 툴을 호출합니다. 리플라이 툴도 기본적으로 답변에 채팅 ID를 물고, 텍스트에 결과(result) 형태로 반환하게 됩니다.

컨트롤러는 그걸 보고 채팅 ID를 한 번 더 확인하고, 뭔가 깨지진 않았는지, 파싱이 잘 되는지, 필수 키가 들어있는지 검사하는 과정을 거치게 했어요.

채널로 클로드와 코덱스 대화시키기

저는 클로드와 코덱스를 둘 다 결제하고 있고, 개발할 때 두 개를 같이 많이 사용해요. 둘 다 강점이 달라서 서로의 강점을 살리게 되는데요. 이 둘을 실제로 대화할 수 있는 브릿지로 이어서 자동화할 수 없을까 하는 니즈가 있었습니다. 개발뿐만 아니라, 미국 증시 같은 제 관심사도 AI끼리 토론시키는 경우가 많거든요. 그래서 클로드 채널을 활용하면 되겠다는 생각으로 구현을 시작했습니다.

핵심부터 말씀드리면, 직접 대화를 하는 게 아니에요. 클로드와 코덱스는 컨트롤러 계층을 라우터 삼아, 매개로 대화를 하는 겁니다. 클로드 코드가 메시지를 컨트롤러에 넣어주면 컨트롤러가 그걸 받아 코덱스에 넣어주고, 코덱스가 그걸 다시 컨트롤러에 넣고, 클로드에는 채널을 통해 브릿지 형태로 넣어주는 구조예요. 각자는 컨트롤러만 바라보는 형태고, 컨트롤러가 중앙에 있습니다.

그리고 각각 대화가 언제 끝났는지 알아야 하기 때문에 ‘turn complete’ 신호를 받아야 합니다. 메시지를 넣고, 청크로 답 조각을 받은 다음, 턴 끝 신호를 받으면 종료하는 구조입니다.

핵심은 답변 수신과 완료 신호, 이 두 가지만 거의 보시면 되는데요. 클로드 코드를 가짜 터미널 안에 라이브 세션 형태로 띄우니까, 답변 수신과 완료 신호를 리플라이 툴 호출로 구현했고요. 코덱스는 방법이 두 가지가 있는데, 저처럼 codex exec 명령어를 사용하는 방법도 있고, 코덱스 앱 서버(라이브 서버)를 이용하는 방식도 있습니다. 저는 codex exec을 --json 옵션으로 실해해서 결과를 JSON 라인으로 받았어요. 그래서 답변 수신은 JSON으로 받고, 완료 신호는 턴 컴플리트라는 이벤트로 받습니다.

세 가지 대화 모드와 토큰 폭증을 막는 장치

대화에는 모드가 있습니다.

릴레이(Relay): 그냥 서로 건조하게 대화가 오고 가는 모드입니다.
콜라보레이티브(Collaborative): 클로드가 말한 내용이 ‘클로드’라는 태그로 묶인 텍스트로 상대에게 들어가는 모드입니다.
디베이트(Debate): 콜라보레이티브 뒤에 “이 주장에 반박을 해보세요”라는 신규 프롬프트 인자가 넘어가는 모드입니다.

그리고 이런 브릿지 형태를 구현하다 보면 토큰 폭증이 정말 많아요. 턴이 무한정 이어지면서 서로 무한정 대화를 한다든가, 답변 길이가 어마무시하게 길어진다든가 하는 문제가 있어서, 턴에 대한 제한이나 핸드오프 문자 수 제한, 그리고 인간이 개입할 수 있는 장치를 만드는 게 좋습니다.

또한 보안이나 권한 측면에서도, 둘 다 대화를 하는 만큼 쓰기 권한은 아무에게도 안 주거나 한 에이전트에만 주는 식으로 권장을 드리고 싶어요.

스크린샷으로 보는 작업 한 바퀴

이제 스크린샷으로 실제 동작을 보여드리겠습니다. 시작점은 클로드가 될 수도 있고 코덱스가 될 수도 있는데, 이건 클코나잇 세션이기도 하니까 클로드 코드 기준으로 말씀드릴게요.

처음에 클로드 코드 세션을 켜서, 제가 만든 채널 MCP인 ‘AI 다이얼로그 MCP’를 사용해 특정 피처에 대해 리뷰를 해달라고 하면, 선택지를 줍니다. 첫 번째로는 앞서 말씀드렸던 콜라보레이티브·릴레이·디베이트 모드, 두 번째는 최대 대화 턴 수와 핸드오프 문자 제한, 그리고 쓰기 권한을 묻게끔 했고요. 이걸 다 선택하면 대화가 시작됩니다.

저는 웹으로 연동해서 클로드와 코덱스의 턴을 동시에 볼 수 있는 화면도 만들어놨어요. 이게 필수는 아닙니다. 다만 클로드 내부에서 서브 프로세스로 스폰되는 구조다 보니 가시적이지가 않아서, 가시성을 위해 만든 거라고 보면 됩니다.

실제로 이렇게 서로 대화를 진행합니다. 특정 기능에 대해 코덱스가 리뷰를 해주면, 클로드가 그걸 실제 디스크에 있는 코드와 대조해서 확인해 주고, 추가로 보완도 해줍니다. 서로가 서로를 보완해 주는 구조죠.

이런 대화는 특정 기능에 대해 최소한의 합의가 되었다는 결론으로 도출되고, 대화가 종료되면 최초의 대화를 시작했던 부모 클로드 세션으로 전달됩니다. “레이어 1 계층에는 이런 확실한 버그가 존재하고, 잠재적인 버그는 이게 있고, 설계 취약점은 이런 게 있다”라고 띄워주고, 이 내용을 토대로 리팩토링을 한다든가 새로운 기능을 개발한다든가 하고 있습니다.

마치며: 살아 있는 세션을 자동화 런타임으로

정리하면, 저는 살아 있는 라이브 클로드 세션을 PTY로 띄워서 자동화 런타임으로 사용한 겁니다. 채널 MCP를 이용해 메시지를 밀어 넣고, 리플라이 툴로 답을 회수하는 구조라고 보면 될 것 같아요. 사실 앤트로픽 API를 사용해도 정말 쉽게 구현되는 구조이지만, 그런 래퍼를 사용한 게 아니라 채널이라는 리서치 프리뷰 기능을 사용해서 구현했다고 보시면 됩니다.

개인적으로 말씀드리고 싶은 건, 이런 작업을 할 때는 앤트로픽 공식 문서를 많이 보시는 걸 추천합니다. 앤트로픽 공식 문서나 오픈AI 공식 문서, 더 나아가면 중국 개발자들이 만든 오픈소스도 많거든요. 그런 걸 보면서 아이디어를 얻었던 것 같습니다.

이상 발표를 마치겠습니다. 감사합니다.

▶ 발표 영상 유튜브에서 보기