요즘IT는 지난 10월 클로드 코드 세미나 ‘클코나잇’ 1회에 이어 11월 ‘클코나잇 2회 - 딥다이브’세션을 열고 개발자들이 클로드 코드를 현업에서 실제로 활용하는 다양한 사례를 공유했습니다. RSA 암호화 데스크톱 앱을 만들거나 AI 오케스트레이션을 실행한 사례, 3일 만에 위기를 해결한 사례 등을 공유했습니다. 참가자들에게 “명불허전” “안 들었으면 후회할 ” “아이디어 가득 얻고 가는 시간!”이라고 호평을 받았습니다. 아쉽게도 참석하지 못한 분들을 위해 그날의 핵심 내용을 정리해 콘텐츠로 다시 전해드립니다.

이번 글은 딥다이브 세미나 두 번째 주제였던 “[Orchestration] AI 에이전트끼리 소통하게 만들기”입니다. 발표자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다. 1월부터는 ‘AI 빌더스쿨’이라는 기획이 시작됩니다. 요즘 세미나 계정을 ‘최신 콘텐츠 알림받기’ 설정하시면 참가 페이지 오픈시 이메일로 알림 받으실 수 있습니다.

안녕하세요, 와탭랩스의 노성현입니다. 오늘은 'AI 에이전트 오케스트레이션 실전 가이드'라는 주제로 발표하게 됐습니다. 오늘 말씀드릴 내용은 AI들끼리 서로 대화하면서 일을 알아서 하게 만드는 방법입니다. 아주 디테일한 기술 공유보다는, 'AI들끼리 스스로 저렇게 일하게 만들 수도 있구나'라는 가능성을 편하게 보여드리는 시간이 될 겁니다.

메타버스 속 개발자들을 보며 떠올린 아이디어

올해 여름 무더위에 재택근무 가이드가 나오면서 팀 내에서 '게더타운'이라는 메타버스 도구를 며칠간 사용하게 됐습니다. 캐릭터들이 왔다 갔다 하면서 서로 말 걸고 대화하는 모습을 보면서 문득 생각이 들었습니다. '내 백그라운드에 떠 있는 이 터미널들이 각각의 역할인 것 같다'는 생각이었죠.

실제로 제가 업무하는 방식을 보면, 터미널 여러 개를 띄워서 에이전트 역할을 부여하고, 클로드 코드를 실행한 뒤 그 결과를 복사해서 옆 터미널로 옮기는 식이었습니다. 그런데 이렇게 복사-붙여넣기 작업을 반복하다 보니 '이게 맞나? 이게 자동화가 맞는가?'라는 고민이 들었습니다.

시간이 줄어들어야 했는데, 생각보다 그렇지 않았습니다. 그래서 어디서 시간을 많이 뺏기나 했더니, 프론트 코드가 실행되는 시간에 제가 대기하고 있는 시간이 너무 길었습니다. 그래서 게더타운의 캐릭터들처럼 AI가 스스로 대화하면서 일을 하게 해서, 제가 붙잡고 있지 않아도 진행할 수 있는 방법이 없을까 고민하게 됐습니다.

Stage 1: Tmux로 에이전트끼리 대화 시작하기

오늘 저의 목표는 AI들이 알아서 대화하면서 일하게 만든 방법에 대해 제가 해본 것을 공유하는 것입니다. 총 네 단계로 내용이 진화할 건데요, 특정 라이브러리 하나 하나보다 어떤 문제가 있었고 어떻게 해결했는지에 포커스를 맞춰주시면 좋겠습니다.

첫 번째 단계로 Tmux를 이용해서 에이전트끼리 대화하게 만드는 방식을 시도해봤습니다. Tmux는 터미널에서 여러 세션을 열어 백그라운드에서 관리할 수 있는 도구입니다. 실수로 터미널을 꺼도 백그라운드에 세션이 남아있어서 작업하던 그대로 다시 돌아올 수 있죠.

특히 Tmux의 'send-keys' 기능이 중요합니다. 터미널에 키보드를 치듯이 메시지를 날릴 수 있거든요. 예를 들어 A세션에서 B세션으로 send-keys를 날리면, 키보드를 치듯이 메시지를 전달하게 됩니다. 이걸 활용하면 클로드 코드끼리 결과를 주고받을 수 있습니다. 'capture-pane' 같은 기능으로 옆 터미널의 결과를 받아올 수도 있습니다.

예를 들어 Dev 에이전트에서 개발을 하고 결과가 끝나면, QA 에이전트한테 send-keys로 내용을 전송하고, QA 에이전트가 전달받은 결과를 가지고 자동으로 작업하는 식입니다.

물론 클로드 코드가 자동으로 다 되는 건 아니고 설정이 필요합니다. claude.md에 Tmux 세션 이름(예: qa-agent)이나 send-keys로 메시지를 전송하는 가이드 방법을 넣어주면, 클로드가 알아서 일을 하고 QA까지 해달라고 하면 QA 에이전트한테 명령을 전달합니다.

이 방식의 효과는 명확했습니다. send-keys로 클로드 코드끼리 메시지를 주고받게 만들면, 복사-붙여넣기를 기다릴 필요 없이 앞선 에이전트가 다음 에이전트한테 결과를 자동으로 입력해주니까요. 시간이 굉장히 절약됐습니다.

이 정도만 세팅해도 터미널을 여러 개 켜놓은 클로드 코드끼리 대화하면서 작업하는 걸 보실 수 있습니다.

Stage 2: LangGraph로 복잡한 조건 처리하기

하지만 문제가 있었습니다. 정상적으로 진행되면 아무 문제가 없는데, 만약 QA에서 실패하면 어떻게 할까요? 실패한 결과를 다시 개발 에이전트한테 전달해야 개발 에이전트가 추가 개발을 하겠죠. 이런 조건들이 자꾸 생기는데, send-keys만으로는 조건에 따른 분기 처리나 다른 작업 추가가 어려웠습니다.

이 문제를 해결하기 위해 LangGraph를 사용했습니다. LangGraph는 state 기반 워크플로우 엔진으로, '누구에게 언제 무엇을 할지를 결정만 하는' 도구라고 생각해주시면 됩니다. 여기서 포커스는 '결정만 하는 거지, 액션 수행은 아니다'라는 점입니다.

사실 랭그래프 사용법을 오늘 전부 말씀드리기에는 어렵고, 랭그래프라는 키워드와 이것이 어떤 역할을 수행하는지 정도만 얻어가시면 좋겠습니다.

먼저 LangGraph의 핵심 개념 세 가지를 알아야 합니다

State: 작업 실행 상태나 어떤 걸 실행하고 있는지 등 다양한 값을 저장하는 메모리 공간
Node: 하나의 작업 단위 (그 안에서 여러 스텝이 있을 수 있음)
Edge: 어디로 가야 할지 판단하는 분기 처리 (성공하면 어느 노드로, 실패하면 어느 노드로)

LangGraph의 동작 흐름은 이렇습니다. 초기 State를 가지고 첫 번째 노드를 실행하면, 그 결과를 가지고 Edge를 판단해서 다음 노드로 진행하는 식입니다.

예를 들어 재시도 카운트를 저장하고 관리하는 State를 만들고, 실행될 때마다 카운트를 올리는 로직, State 값을 판단해서 재시도할지 실패로 처리할지 결정하는 Edge 설정 등을 만들 수 있습니다. 이런 시스템을 우아하게 구성할 수 있는 거죠.

만약 LangGraph 없이 클로드 코드 자체만으로 이런 걸 만든다면 프롬프트가 많이 늘어나고, 컨텍스트를 줄이려고 고민하는 상황에서 쓸데없는 로직 조건들이 늘어나기 때문에, 이런 프레임워크를 사용하는 게 훨씬 우아합니다.

Stage 3: PM 에이전트로 LangGraph 관리 자동화

이 정도만 해도 에이전트들끼리 대화하면서 요구사항을 잘 처리할 것 같았습니다. 하지만 또 문제가 있었습니다.

LangGraph는 정의만 하는 것이지 액션은 없다고 했죠? 그러니까 누군가는 LangGraph 내용을 읽어서 실행도 시켜주고, 성공/실패 결과를 LangGraph한테 전달해줘야 합니다. 그런데 그걸 만드는 비용이 자꾸 생깁니다. 데이터 인터페이스 포맷이나 판단 로직을 직접 고민해야 하는 거죠.

'이렇게 어렵게 할 거면 그냥 클로드 코드를 잘 써도 될 것 같은데...' 싶었습니다. 저는 LangGraph를 너무 깊게 공부할 생각은 없는데, 복잡한 비즈니스 로직은 수용하고 싶었습니다.

그래서 LangGraph 자체를 관리하는 PM 역할을 만들었습니다. 'PM 에이전트'라는 걸 만들어서, claude.md에 "너는 LangGraph 관련된 것만 처리할 거고, LangGraph 실행시키거나 내용 전달하거나 받아오는 것만 해"라고 정의했습니다.

이렇게 하니 기존의 복잡한 코드를 생성하지 않고, PM 에이전트가 대신 처리해주는 걸 볼 수 있었습니다. 예를 들어 'send_to_agent'라는 기능을 정의해서 send-keys로 보내는 것만 만들어 놓으면, 어떤 업무 에이전트가 어떤 작업을 하든 간에 통신의 발신 부분은 무조건 이걸로 통합됩니다. 복잡하게 뭘 더 만들 필요가 없었죠.

마찬가지로 'receive_response'도 하나 만들어서 capture 로직을 한 번만 정의하면, 개발도 제가 직접 하기보다는 클로드가 다 해줬습니다.

PM 에이전트를 만들어보니 LangGraph의 기능을 클로드 코드한테 다 넘긴 셈이었습니다. 특히 LangGraph를 직접 코딩하면 State 관리 전략이 중요한데, 저는 PM 에이전트한테 맡겨서 개가 알아서 타입들을 관리하고 만들어주고 고민하게 했습니다.

LangGraph에 대한 지식이 많지 않아도 PM이 스스로 LangGraph를 학습하고 계속 확장해나가는 걸 볼 수 있었습니다. PM 에이전트가 어쨌든 클로드 코드니까, 자연어로 LangGraph 관련된 명령를 해도 다 처리해줬습니다.

PM 에이전트를 파인튜닝만 잘 해도 더욱더 비즈니스를 풍성하게 진행시키는 것들을 만들어낼 수 있었습니다.

Stage 4: 99% 자동화를 향해

이 정도만 해도 충분할 것 같지만, 저는 모든 걸 자동화하고 싶은 귀차니즘 개발자입니다. 저는 AI가 정말 제가 아무것도 안 해도 잘 해주길 원하거든요.

그래서 여기까지 오면서 자동화 안 된 부분을 체크해봤습니다.

업무가 진행되는 에이전트들을 폴더로 구분하고 claude.md 만드는 작업
LangGraph 워크플로우를 상황에 따라 수동으로 처리하는 부분
Tmux 세션 띄우기
그 세션에서 클로드 실행시키기

이런 작업들은 어려운 게 아니었습니다. claude.md에 "이런 작업 받으면 이렇게 세팅해서 클로드 실행해라"라고 적어놓으면 자동으로 다 해주거든요. 어려운 스크립트를 만들 것 없이 PM 에이전트 claude.md에 이것까지 다 해달라고 작성했더니 실제로 다 해줬습니다.

Stage 3에서 PM 에이전트가 LangGraph만 처리했다면, Stage 4에서는 자동화할 수 있는 프로세스 전체를 관리하면서 99% 에이전트 대화 시스템을 자동화할 수 있었습니다.

마무리하며

오늘 네 가지 스테이지를 나눠서 에이전트끼리 대화하면서 일하도록 만든 사례를 소개했습니다. 다시 한번 말씀드리지만, 제 방식을 무조건 쓰시라는 게 아닙니다.

제 이야기에서 'LangGraph'라는 단어 하나만 알고 가셔도 굉장히 좋을 것 같습니다. AI로 복잡한 조건이나 분기 처리가 필요한 파이프라인을 만들어야 한다면, LangGraph가 하나의 방법이 있구나 정도만 알고 가셔도 충분합니다.

MS의 경우 코드의 60%가 AI가 생산했다는 기사를 보곤 하는데요, 저는 'AI와 함께 일하는 방법'뿐만 아니라 '나도 옆에서 일하고 있는데 AI도 옆에서 같이 일하고 있는 것'을 원했던 것 같습니다.

‘비싼 클로드값을 냈으면 한 100~200배는 뽑아야 하지 않나요?’ 이런 욕심으로 시작했고, 실제로 작업의 병렬화가 강력해서 많은 시간을 절약했습니다.

여러분도 내일 아침에 클로드 코드를 에이전트 여러 개 띄워서 대화하게 만드는 걸 한번 해보시면 어떨까요?

감사합니다.

Q&A

Q. stage1 수준에 대해서 사용방법을 자세히 보고 싶은데 확인할 수 있는 자료가 있을까요?

질문 감사드립니다. stage1은 어렵지 않기 때문에 claude 에게 tmux 설치 와 sendkey로 전송해보라고 하면 잘 만들어줄 것 같습니다.

Q. LangGraph가 sendkeys를 보내는 방식이 subAgent를 선언해서 하나의 세션에서 multi agent를 활용하는 방법과는 어떤 차이가 있을까요? (결과물, 토큰소모, 작업시간 관점에서요)

꼭 나왔으면 하는 질문인데 감사드립니다. 사실 이 발표를 신청 하고 난 후에 subagent가 나와서, 발표를 준비하면서 고민을 많이 했는데요. 저같은 경우 업무의 파이프라인은 langGraph로 쓰고, 개발을 하는 작은 단위에서 다양한 subagent, mcp로 연결해 문제를 해결하게 했습니다. subAgent가 점점 더 좋아져서서요. 토큰, 시간 등등으로 판단은 비교를 안해봐서 잘 모르곘습니다.

Q. LangGraph가 supervisor 역할을 하는 것 같네요. 지금 구조는 절차적으로 오케스트레이션하는 것 같은데요. 좀 더 발전시키면 병렬로 작업 후 병합하는 구조로도 할 수 있을 것 같아요. 혹시 관련해서 생각해두신 아키텍쳐가 있을까요?

실제로 병렬로 진행하는 것도 하고 있습니다. 오늘 발표했던 버전이 저에겐 두 달 전 버전인 것 같아요. 병렬을 처리하는 건 어렵지 않습니다. PM agent에게 병렬요청을 하면 적절하게 처리줍니다. 다만 아키텍처 레벨은 아니지만, 우아한 처리를 위해 앤트로픽 블로그 에 나온 방향을 참고해 고민하고 있습니다. 동작은 병렬로 잘 되긴 하는데 우아하게 만들고 싶어서요.

Q. 잘만 쓰면 생산성이 극대화될 것 같아요. 그런데 토큰이 상당히 많이 들 것 같은데, 100달러짜리 Max 유저도 할만 할까요? 저는 sub agent랑 hooks 정도만 쓰는데 일주일에 60퍼센트 정도 쓰더라고요.

자동화를 하는 하는순간 토큰은 엄청 먹습니다. 저같은경우 cluade 뿐만아니라 codex cli, cursor cli, gemini, 그리고 다양하게 파인튜닝한 local llm을 섞어서 쓰게 했습니다.

Q. 에이전트끼리 소통하는 pipeline에 대해 궁금한데요. 데이터가 어떤 형태로 오고가는 건가요?

클로드 코드가 결과 메세지를 직접 보내도 되고, 그게 너무 큰경우가 있기 때문에 파일로 저장한 후 경로를 메세지로 전달하는 방식도 많이 쓰기도 합니다. 위에 파인튜닝된 llm중에는 내용을 다시한번 정리해주거나 내용을 요약해주는 것도 있어서 적절하게 섞어서 씁니다.

Q. 메모리 공유는 어떻게 하셧나요? PM 에이전트는 모든 에이전트들과의 상호작용 메모리를 다 가지고 있나요? (+ 최근 업무만 기억하나요?)

맞습니다. 메모리 공유가 어려운 부분인데요. 우선 에이전트들끼리 메모리를 공유해야 한다는점은 업무 프로세스상 분리가 안됬다고 볼수도 있습니다. 최대한 공유가 안되는 단위로 업무 agent들을 나눠야 하고요, 만약 공유해야 하는 경우에는 말씀주신대로, 공유할 수 있는 메모리가 필요하긴 합니다만 케이스에 따라 달랐습니다.

Jira에 댓글로 agent들이 남기는 식으로도 했고, 특정 txt파일을 공유하면서 해당 txt에 공유하는 식으로도 합니다. 하지만 궁극적으로는 agent끼리 굳이 메모리 공유를 안 해도 되는 전략으로 짜시는게 좋습니다. PM Agent는 추상적인 업무내용과 ochestration만 해야 하기 때문에 업무를 분석하는 agent라든지, job 실행계획을 짜는 agent들을 앞에 끼워서 쓰기도 합니다.

Q. 완전 자동화를 시키게되면 내가 원하지 않는 코드를 생성하거나 지울수도 있을 텐데 그런 제어 부분은 어떻게 하셨나요?

당연히 그런케이스가 발생하기 때문에 절대 바로 서비스에 적용하지 않았습니다. 최종 코드는 PR을 날리게 해서 코드 리뷰 받듯이 확인하는 절차를 거칩니다. 작은 단위로 작업을 나누면 PR도 꽤 퀄리티 있게 보내더라구요. (큰 작업은 PR 보는데 시간 단위로 보는 경우도 있었어요)

Q. agent의 세션마다 컨텍스트가 가득 차게되면 auto-compact를 시키며 계속 진행을 시키는지? 혹은 다른 방법이 있는지 궁금합니다.

저같은경우 물론 컨텍스트가 가득 차는 경우도 당연히 있지만, 작업을 잘게잘게 쪼개기 위해 작업을 분석하는 agent, 실행계획을 짜는 agent를 만들었습니다. 예컨데 작업을 분석하는 agent는 codex cli를 이용해서 gpt5를 쓰기도 합니다. 이런 식으로 다른 ai를 쓰기도 합니다.

Q. 하나의 작업을 여러 에이전트가 처리하고, 그 작업이 완료되면 세션을 종료하는 방식인가요? 다음 작업을 시작할 때는 모든 에이전트가 새로운 세션에서 깨어나는(시작하는) 것인지 궁금합니다.

작업이 최종적으로 완료됬다고 판단하면 종료합니다. 아마 하나의 작업이 너무 큰 부분은 지금 프로세스가 아니였더라도 찼을거 같은데요. 여러 retry count limit을 주기도 하고, 작업을 분석할 때 최대한 작게 작업들을 쪼개고, 쪼개진 작업들을 병렬로 다른 세션으로 실행시켜서 작업을 시키기도 합니다. 말씀하신대로 다음 작업 할땐 깨우긴 했습니다.