LLMOps 14
AI Agent 시스템: Planner, Executor, Critic으로 복잡한 문제 정복하기
역할 이름은 알지만 실제로 어떤 책임 차이가 있는지 섞인다.
근거 · 교안 p37-p40
1장: 역할 분리, 왜 필요할까요? 복잡한 문제의 시작점
솔라의 시선이 어지럽게 흩어졌다. 조리대 위에는 손질하다 만 채소, 계량하다 흘린 밀가루, 그리고 스마트폰의 작은 화면에 뜬 레시피가 뒤엉켜 있었다. ‘버섯 크림 파스타’. 분명 간단해 보였는데, 지금 부엌은 전쟁터 같았다. 소스를 만들기 위해 우유를 끓이면서 동시에 면을 삶을 타이밍을 재고, 다른 한편으로는 마늘과 양파를 볶아야 했다. 머릿속에서 세 가지 작업이 서로 먼저 처리해달라며 아우성이었다.
“아, 진짜! 이걸 한 번에 어떻게 해?”
결국 솔라는 모든 걸 멈추고 의자에 털썩 주저앉았다. 실패한 요리보다 더 답답한 것은 이 상황이 낯설지 않다는 점이었다. 얼마 전 AI 에이전트 관련 글에서 봤던 한 문장이 머릿속을 맴돌았다. ‘복잡한 문제를 신뢰성 있게 해결하려면, 단일 응답이 아니라 문제 분해, 실행, 검증으로 역할을 분리해야 한다.’
그럴듯한 말이었다. Planner, Executor, Critic. 이름도 멋졌다. 하지만 솔라에게는 그저 뜬구름 잡는 소리처럼 들렸다. ‘역할을 나눈다고? 그냥 똑똑한 애 하나가 알아서 다 하면 되는 거 아닌가? 계획하면서 실행하고, 중간중간 확인하면 되잖아. 나처럼.’ 솔라는 생각했다. 하지만 바로 그 ‘나처럼’ 하는 방식이 지금의 난장판을 만들었다. 역할들이 섞여도 큰 문제는 없을 거라는 생각은 명백한 착각이었다.
“요리가 아니라 거의 재난 복구 현장인데.”
어느새 다가온 언니 루나가 어질러진 조리대를 보며 나지막이 말했다. 솔라는 변명할 기력도 없이 고개를 저었다.
“언니, 복잡한 일을 하려면 역할을 나눠야 한대. 그런데 그게 무슨 뜻인지 하나도 모르겠어. 계획, 실행, 검증? 그냥 한 사람이 다 하면 되는 거 아니야?”
루나는 솔라의 스마트폰 화면을 슬쩍 들여다봤다. 빼곡한 텍스트로 가득한 레시피였다. 루나는 대답 대신, 조리대 한편에 놓인 하얀 접시 세 개를 가져와 나란히 놓았다.
“솔라, 이 파스타를 만드는 과정을 딱 세 단계의 질문으로 바꿔보자.”
루나는 첫 번째 접시를 가리켰다. “여기는 ‘무엇을 할 것인가?’의 접시야. 레시피 전체를 보고, 우리가 해야 할 일의 목록과 순서만 정하는 거지. 다른 건 아무것도 생각하지 말고.”
솔라는 반신반의하며 레시피를 다시 훑었다. 끓이고 볶고 삶는 과정들이 머릿속에서 뒤섞여 아우성치던 아까와 달리, ‘순서 정하기’라는 단 하나의 목표에 집중하니 길이 보이기 시작했다.
“음… 먼저 재료를 다듬고, 다음엔 소스를 만들고, 그 다음에 면을 삶아서 소스랑 볶고, 마지막으로 접시에 담기. 이렇게 네 단계네.”
“좋아.”
루나는 두 번째 접시를 가리켰다. “이건 ‘어떻게 할 것인가?’의 접시. 방금 정한 첫 번째 단계, ‘재료 다듬기’만 여기 올려봐. 다른 단계는 전부 잊어버리고. 오직 마늘은 어떻게 다지고, 버섯은 어떻게 썰지, 그 실행 방법만 생각하는 거야.”
솔라는 루나의 말에 따라 마늘과 버섯을 가져왔다. 신기하게도 마음이 한결 가벼워졌다. 소스가 끓어 넘칠까, 면이 불어 터질까 걱정할 필요가 없었다. 오직 눈앞의 칼과 도마, 재료에만 집중하면 되었다. 작업은 금세 끝났고, 깔끔하게 손질된 재료가 두 번째 접시에 담겼다.
“자, 마지막 접시.”
루나가 세 번째 접시를 톡톡 건드렸다. “여긴 ‘잘 되었는가?’의 접시야. 실행한 결과가 우리가 원했던 게 맞는지 확인하는 거지. 버섯 두께는 적당한지, 마늘은 너무 곱게 다져지지 않았는지.”
솔라는 손질된 재료를 보며 고개를 끄덕였다. “응. 이 정도면 괜찮아.”
“만약 여기서 뭔가 잘못됐다면? 예를 들어 버섯을 너무 얇게 썰어서 볶으면 다 뭉개질 것 같다면?”
“다시 썰어야지. 아니면 볶는 시간을 조절하라고 다음 단계에 미리 알려줘야 할 거야.”
그 순간, 솔라의 머릿속에서 무언가 ‘탁’ 하고 제자리를 찾는 소리가 났다. 계획하고, 실행하고, 평가하는 것은 단순히 세 개의 다른 단어가 아니었다. 완전히 다른 종류의 집중력을 요구하는, 서로 다른 정체성이었다. 혼자 요리할 때 실패했던 이유는 능력이 부족해서가 아니었다. 머릿속에서 ‘계획가’와 ‘실행가’, 그리고 ‘평론가’의 역할을 쉴 새 없이 오가느라 정신적 에너지를 전부 소진해버렸기 때문이었다.
역할을 분리한다는 것은 한 사람이 여러 개의 가면을 바꿔 쓰는 게 아니었다. 아예 각기 다른 책임을 지닌 전문가에게 일을 맡기는 것에 가까웠다. 계획가는 전체 그림을 보며 길을 잃지 않게 하고, 실행가는 눈앞의 과제에만 몰두해 효율을 높이며, 비평가는 한발짝 떨어져서 결과물의 신뢰성을 보장한다.
“알겠다….” 솔라가 나지막이 중얼거렸다. “AI 에이전트한테 복잡한 일을 시킬 때, 그냥 ‘알아서 잘 해봐’라고 던져주는 게 아니라, 계획하고 실행하고 검증하는 책임을 명확히 나눠줘야 엉뚱한 결과를 내지 않고 일을 제대로 처리할 수 있다는 뜻이었구나.”
어지럽던 부엌이 아니라, 뒤엉켜 있던 솔라의 머릿속이 정리되고 있었다. 문제를 해결하려면 단순히 일을 나누는 것을 넘어, 책임의 종류에 따라 역할을 분리해야 한다는 통찰. 그것이 신뢰성 있는 문제 해결 시스템의 진짜 시작점이었다.
하지만 새로운 질문이 고개를 들었다. 역할 분리의 필요성은 이제 알겠다. 하지만 그 역할들은 서로 어떻게 소통할까? 계획가인 Planner는 어디까지 계획을 세워야 실행가인 Executor에게 넘겨줄 수 있을까? 그 둘 사이의 경계는 누가, 어떻게 정하는 걸까?
2장: 무엇을 할 것인가? Planner의 ‘계획 수립’ 능력
어지러웠던 부엌은 말끔히 정리되었고, 파스타의 흔적은 사라졌다. 하지만 솔라의 머릿속에 남은 질문은 그대로였다. 어젯밤, 역할 분리의 필요성을 어렴풋이 깨달은 솔라는 오늘 아예 자리를 잡고 앉았다. 식탁 위에는 깨끗한 A4 용지와 펜 하나가 놓여 있었다. ‘역할 분담, 직접 해보면 알겠지.’
솔라는 종이 맨 위에 큰 글씨로 목표를 썼다. <친구들과 부산 1박 2일 여행 가기>
그리고 그 아래에 생각나는 것들을 쭉 나열하기 시작했다.
- KTX 예매하기
- 광안리 밤바다 보기
- 예산은 1인당 20만원 안으로
- 해운대 근처 숙소 잡기
- 맛있는 돼지국밥집 찾아가기
- 날짜는 다음 달 주말 중에
- 재미있게 놀기!
목록을 채워갈수록 솔라의 얼굴에 뿌듯함이 번졌다. ‘이 정도면 제법 구체적인데? 이걸 그대로 AI 에이전트한테 주면 알아서 착착 진행할 수 있지 않을까?’ 그녀는 이 목록이 바로 ‘계획’이라고 생각했다. 어제 루나가 말한 ‘무엇을 할 것인가?’에 대한 답이라고 믿었다.
“다 됐어?”
어느새 다가온 루나가 솔라의 종이를 들여다보았다. 솔라는 자신만만하게 고개를 끄덕였다.
“응. 이게 바로 Planner의 역할 아니야? 해야 할 일을 이렇게 쫙 분해해서 알려주는 거지. ‘문제 분해’라는 게 이런 거잖아.”
솔라는 ‘문제 분해’라는 용어를 쓰며 어깨를 으쓱했다. 하지만 루나는 고개를 저었다.
“이건 계획이라기보다… ‘희망 사항 목록’에 가까운데.”
“뭐? 이게 왜?”
솔라의 목소리가 발끈 튀어나왔다. 루나는 펜을 들어 솔라가 쓴 목록의 첫 번째 항목 ‘KTX 예매하기’와 마지막에서 두 번째 항목 ‘날짜는 다음 달 주말 중에’를 동그라미 쳤다.
“솔라, 날짜를 정하지 않고 KTX를 예매할 수 있어?”
“아니, 그건 당연히…”
“예산을 정하지 않고 숙소를 잡을 수 있을까? ‘해운대 근처’라는 조건만으로? 5성급 호텔일 수도 있고, 게스트하우스일 수도 있는데.”
“그것도 그렇네…”
솔라는 자신의 목록이 뒤죽박죽이라는 것을 깨달았다. 순서도 없고, 서로 의존하는 작업들이 제멋대로 흩어져 있었다. ‘재미있게 놀기!’ 같은 항목은 지시라고 하기도 애매했다. 이걸 받은 실행 담당자는 무엇부터 해야 할지 몰라 우왕좌왕할 게 뻔했다. 문제를 단순히 작게 나눈다고 해서 해결되지 않는다는 걸 직감했다.
루나는 새 종이를 꺼내 솔라 앞에 놓았다.
“Planner의 가장 중요한 책임은 ‘전략’을 세우는 거야. 단순히 할 일을 나열하는 게 아니라, 어떤 순서로, 어떤 단계를 밟아야 최종 목표에 도달할 수 있는지, 그 길을 설계하는 역할이지. 이정표 없는 지도가 아니라, 명확한 경로가 그려진 내비게이션을 만드는 사람이야.”
루나는 덧붙였다. “Planner가 답해야 할 질문은 ‘무엇을 할 것인가?’가 맞아. 하지만 더 정확히 말하면, ‘그 다음엔 무엇을 할 것인가?’라는 질문에 막힘없이 대답할 수 있는 목록을 만드는 거지.”
그 말에 솔라의 머릿속이 환해졌다. 순서. 전략. 그게 빠져 있었다. 그녀는 다시 펜을 잡았다. 이번에는 ‘희망 사항’이 아니라, 실행 가능한 ‘단계’를 고민했다.
- 참여 인원 및 여행 날짜 확정하기. (이게 정해져야 모든 게 시작된다.)
- 전체 예산 설정 및 1인당 비용 분배하기. (예산이 없으면 교통과 숙소를 정할 수 없다.)
- 결정된 예산과 날짜에 맞춰 교통편 조회 및 예매하기.
- 결정된 예산과 날짜에 맞춰 숙소 조회 및 예약하기.
- 주요 동선과 방문할 장소 목록 만들기.
- 장소별 세부 활동(식사, 체험 등) 계획하기.
두 번째 목록은 첫 번째와 완전히 달랐다. 각 단계는 다음 단계의 입력값이 되었다. 1번이 없으면 3, 4번을 진행할 수 없고, 2번이 없으면 3, 4, 6번의 선택지가 무한대가 되어버린다. 이것이야말로 누군가에게 그대로 전달해도 좋을 명확한 ‘단계별 실행 계획’이었다.
“아… 알겠다. Planner는 그냥 일을 쪼개는 게 아니었어. 작업들 사이의 의존성을 파악해서, 실행 가능한 순서로 재배열하는 ‘설계자’였구나. ‘무엇을 할 것인가’라는 질문의 진짜 의미는 전체 전략을 짜라는 뜻이었어.”
솔라는 스스로 만든 계획서를 보며 감탄했다. 이 계획서는 누가 보더라도 길을 잃지 않을 것이다. 이것이 바로 Planner가 제공하는 가치, ‘계획 수립의 틀’이었다.
그런데 문득 새로운 의문이 들었다. 솔라는 세 번째 단계 ‘교통편 조회 및 예매하기’를 손가락으로 가리켰다.
“언니, 그럼 이 계획서를 받은 실행 담당자, Executor는 이 3번 단계를 보고 KTX 사이트에 들어가서 표를 예매하겠지? 그런데 만약… 원하는 날짜에 표가 다 매진되고 없으면 어떡해? 계획에는 KTX를 예매하라고 되어 있는데.”
계획은 완벽해 보였다. 하지만 현실은 계획대로만 움직여주지 않는다. 완벽한 계획이 현실의 벽에 부딪혔을 때, 그 책임은 다시 계획을 세운 Planner에게 돌아오는 걸까, 아니면 실행하는 Executor가 알아서 해결해야 하는 걸까? 명확해졌다고 생각했던 역할의 경계가 다시 희미해지기 시작했다.
3장: 어떻게 할 것인가? Executor의 ‘실행 전환’ 기술
솔라의 손가락이 노트북 트랙패드 위에서 멈칫했다. 어제 완성한 완벽한 여행 계획서가 모니터 옆에 붙어 있었다. <친구들과 부산 1박 2일 여행 가기>. 그중 세 번째 단계, ‘교통편 조회 및 예매하기’를 실행할 차례였다. 어제까지만 해도 이 계획은 흔들림 없는 등대처럼 보였다. 하지만 지금, 현실의 파도가 그 빛을 위협하고 있었다.
코레일 웹사이트에 접속해 어제 계획서에 명시한 날짜와 인원을 입력했다. ‘조회하기’ 버튼을 누르자, 익숙한 로딩 아이콘이 화면 중앙에서 빙글빙글 돌았다. 짧은 기다림 끝에 나타난 화면. 솔라의 어깨가 축 처졌다. 원하는 시간대의 KTX 좌석 목록 옆에, 선명한 붉은색 글씨가 떠 있었다. [매진].
솔라는 한숨을 쉬며 스크롤을 내렸다. 다음 시간도, 그 다음 시간도 온통 붉은색의 향연이었다. 계획은 ‘KTX를 예매하라’고 명확히 지시하고 있다. 하지만 KTX 표가 없다. 이 상황에서 ‘실행’을 맡은 역할은 무엇을 해야 할까? 마음대로 버스표를 알아봐야 하나? 아니면 날짜를 바꿔서 다시 시도해야 하나? 하지만 그건 계획을 수정하는 행위다. 그건 분명 계획가, Planner의 영역이었는데.
“이거 뭐야… 실행가의 책임은 어디까지지?”
솔라는 혼잣말을 중얼거리며 노트북을 덮었다. 계획을 따르자니 행동할 수가 없고, 행동을 하자니 계획을 벗어난다. 명확하게 분리되었다고 생각했던 역할의 경계가 순식간에 무너져 내리는 기분이었다. ‘계획을 받는다는 점에서 Planner와 책임이 겹치는 거 아니야?’라는 의심이 다시 고개를 들었다.
“막혔구나.”
부엌에서 물을 마시고 나온 루나가 덮인 노트북과 그 옆의 계획서를 번갈아 보며 말했다. 솔라는 고개를 끄덕였다.
“언니, 계획서 3번 단계, ‘KTX 예매하기’를 실행하려고 했는데 표가 없어. 그럼 이제 Executor는 뭘 해야 해? 버스를 알아보는 건 계획에 없는 행동이고, 가만히 있자니 아무것도 진행이 안 되잖아. 이거, 결국 실행가가 알아서 계획을 바꿔야 하는 거 아니야? 그럼 Planner랑 뭐가 달라?”
루나는 솔라의 맞은편에 앉았다. 그리고는 어제 솔라가 썼던 계획서를 가져와 ‘3. 교통편 조회 및 예매하기’ 부분을 펜으로 가리켰다.
“솔라, 네가 지금 Executor라고 생각해 봐. 너한테 주어진 임무는 오직 이 3번 문장 하나뿐이야. 다른 단계는 보이지도 들리지도 않는다고 상상해 봐.”
“응. ‘교통편 조회 및 예매하기’.”
“좋아. 그럼 그 임무를 수행하기 위해 어떤 ‘도구’를 사용했지?”
“도구? 음… 내 노트북으로 코레일 웹사이트에 접속했지.”
“맞아. 그리고 그 도구를 사용해서 임무를 수행한 ‘결과’는 뭐였지?”
루나의 질문에 솔라는 잠시 망설였다. 결과는 ‘실패’였다. 하지만 실패라고만 말하기에는 정보가 너무 부족했다.
“결과는… ‘원하는 날짜와 시간의 KTX 표가 매진되었다’는 것.”
“바로 그거야.”
루나는 펜으로 계획서의 빈 여백에 네모난 상자를 그리고, 그 안에 솔라의 대답을 요약해 적었다.
출력: { "도구": "코레일 웹사이트 조회", "상태": "실패", "사유": "요청된 날짜의 KTX 좌석 매진" }
“Executor의 핵심 책임은 Planner가 준 계획을 자기 마음대로 해석하거나 수정하는 게 아니야. 주어진 단계를 수행하기 위해 적절한 ‘도구’를 사용하고, 그 실행 결과를 왜곡 없이, 있는 그대로 ‘반환’하는 역할이야. 계획을 현실 세계의 행동으로 옮기고, 그 결과를 다시 시스템이 이해할 수 있는 데이터로 바꿔주는 ‘전환 장치’인 셈이지.”
솔라는 루나가 그린 상자를 멍하니 바라보았다. ‘전환 장치’. 머리를 한 대 맞은 것 같았다. Executor는 단순히 시키는 일을 하는 수동적인 존재가 아니었다. 추상적인 계획(Plan)과 구체적인 현실(Tool) 사이를 잇는, 가장 중요한 다리였다. KTX 예매라는 계획을 ‘웹사이트 접속’이라는 실제 행동으로 바꾸고, ‘매진’이라는 현실의 결과를 ‘실패: 좌석 없음’이라는 정제된 정보로 되돌려주는 역할.
“아… 그럼 Executor는 ‘KTX 표가 없으니 버스를 예매해야겠다’라고 스스로 판단하면 안 되는 거였구나.”
“그렇지. 그건 Executor의 책임을 넘어서는 일이야. 만약 Executor가 임의로 버스를 예매했다고 생각해 봐. 다른 친구들은 버스를 오래 타기 싫어할 수도 있고, Planner가 세워둔 전체 예산을 초과할 수도 있어. 시스템 전체가 엉망이 될 수 있지.”
솔라는 고개를 끄덕였다. Executor의 책임이 명확해졌다. 그것은 ‘어떻게 할 것인가?’라는 질문에 대한 답이었다. 하지만 그 답은 ‘어떻게든 문제를 해결할 것인가?’가 아니라, ‘주어진 계획 단계를 어떻게 실제 도구를 써서 실행하고, 그 결과를 어떻게 보고할 것인가?’에 대한 것이었다. 충실한 실행과 정직한 보고. 그것이 전부였다. Executor가 “좌석이 매진되었습니다”라는 명확한 결과만 반환해준다면, 그 다음은 다른 역할이 이어받아 처리할 수 있다.
“알겠다. Executor는 계획을 실행으로 전환하는 전문가였어. 계획 수정은 자기 일이 아니고, 그냥 주어진 임무를 수행하고 그 결과를 정확하게 물어다 주는 역할인 거야.”
스스로 내린 결론에 속이 시원해졌다. 이제는 Planner와 Executor의 책임이 섞인다고 느껴지지 않았다. Planner는 ‘무엇을’ 할지 지도를 그리고, Executor는 그 지도 한 조각을 들고 ‘어떻게든’ 길을 찾아가서, 그곳의 풍경을 사진으로 찍어 돌아오는 탐험가였다.
솔라는 루나가 그려준 출력 상자를 손가락으로 톡톡 건드렸다.
“언니, 그럼 이 ‘매진’이라는 실행 결과를 받았어. 이걸로 끝이야? 이건 분명히 실패인데, 그럼 이걸 누가 보고 ‘이건 잘못됐으니 다른 날짜로 다시 계획해’라고 말해주는 거야? 실행가 자신은 아니잖아.”
새로운 보고서를 손에 들었지만, 그 보고서를 읽고 다음 행동을 결정할 책임자는 아직 보이지 않았다.
4장: 잘 되었는가? Critic의 ‘독립 검증’과 ‘피드백 루프’
솔라의 책상 위에는 어제와 다른 결과물이 놓여 있었다. ‘KTX 매진’이라는 실패 보고서 대신, 오늘은 성공적으로 예매가 완료된 항공권 예약 확인서 프린트물이었다. Executor가 Planner의 계획을 받아, 우여곡절 끝에 다른 날짜의 항공권을 예매하는 데 성공한 것이다.
[출력: { "도구": "항공사 웹사이트", "상태": "성공", "결과": "부산행 항공권 예매 완료 (1인 8만원)" }]
솔라는 이 깔끔한 성공 보고서를 보며 만족스러운 미소를 지었다. “봐, 이제 됐지? 계획대로 실행했고, 성공했잖아. 이걸로 끝 아니야?” 하지만 어딘가 개운치 않았다. 마치 중요한 확인 절차 하나를 건너뛴 듯한 찝찝함. 솔라는 프린트물을 들고 부엌으로 나갔다.
“언니, Executor가 일 끝내고 보고서 올렸어. 부산 가는 비행기 표 예매했대.”
차를 준비하던 루나는 솔라가 건넨 프린트물을 받아 들었다. 그러나 “잘했네”라는 칭찬 대신, 루나는 엉뚱한 질문을 던졌다.
“내가 이 여행의 경비를 전부 책임지는 회계팀장이라고 상상해 봐. 나는 이 여행 계획을 세우지도 않았고, 직접 항공권을 예매하지도 않았어. 그냥 이 결과 보고서만 받았지. 내가 제일 먼저 뭘 확인할 것 같아?”
“음… 돈이 맞게 나갔는지?”
“그렇지.” 루나는 프린트물의 ‘1인 8만원’ 부분에 펜으로 동그라미를 쳤다. “원래 우리가 세웠던 전체 예산 범위 안에 이 금액이 들어오나? 이걸 확인해야겠지. 또 뭐가 있을까?”
루나의 말에 솔라는 ‘제3자’의 눈으로 프린트물을 다시 보기 시작했다. 실행가였을 때는 보이지 않던 것들이 보이기 시작했다.
“아! 탑승자 이름이 정확한지 확인해야 해. 내 이름 영문 철자가 가끔 헷갈리니까. 그리고 날짜랑 시간이 우리가 가려던 게 맞는지도. 만약 새벽 비행기면 숙소 체크인 시간까지 밖에서 기다려야 할 수도 있잖아.”
“훌륭한 지적이야. 거기서 한 걸음만 더 나아가 볼까?” 루나는 프린트물의 아주 작은 글씨 부분을 가리켰다. ‘환불 불가’ 규정이었다. “만약 우리 팀의 여행 정책에 ‘환불 불가능한 예약은 금지한다’는 조항이 있다면 어때? 이 예약은 성공한 걸까, 실패한 걸까?”
솔라는 말문이 막혔다. Executor는 분명 ‘항공권 예매’라는 임무를 성공적으로 완수했다. 하지만 ‘정책 준수’라는 더 높은 차원의 기준에서는 명백한 실패였다. Executor는 자신이 사용한 도구(항공사 웹사이트)가 보여주는 결과만 알 뿐, 회사의 전체 정책까지는 알지 못한다. Planner 역시 세부적인 ‘환불 규정’까지 계획에 명시하지 않았을 수 있다.
바로 그 지점에서 솔라는 깨달았다. 실행의 성공 여부를 판단하는 것은 Planner도, Executor도 아닌, 완전히 독립된 제3의 역할이어야만 한다는 것을. 계획과 실행 과정에 전혀 관여하지 않았기에, 오직 주어진 결과와 객관적인 기준만을 놓고 ‘잘 되었는가?’를 냉정하게 물을 수 있는 존재. 바로 Critic(비평가)이었다.
“알겠다… Critic은 단순히 에러 메시지를 찾는 역할이 아니었어. 실행 결과를 놓고, 원래 계획, 전체 예산, 숨겨진 정책, 품질 기준까지… 온갖 잣대를 다 가져와서 독립적으로 검증하는 ‘최종 관문’ 같은 거구나.”
“맞아. 그리고 Critic의 진짜 힘은 ‘판단’에서 끝나지 않아.”
루나는 프린트물 뒷면에 두 개의 단어를 적었다. [재시도], [재계획]
“만약 탑승자 이름에 오타가 있다면? 그건 Executor가 다시 한번 주의 깊게 시도하면 해결될 문제야. Critic은 ‘이름 오류. 재시도 요청’이라는 피드백을 Executor에게 보내지.”
“하지만 환불 불가 항공권처럼 계획 자체에 없던 문제가 생겼다면? Executor가 아무리 재시도해도 해결할 수 없잖아.”
“바로 그때 ‘재계획 요청’이 나가는 거야. Critic은 ‘정책 위반. 재계획 요청. 사유: 환불 불가 조건’이라는 피드백을 Planner에게 보내. 이 문제를 해결하려면 버스를 알아보거나, 예산을 늘리는 등 전체 전략을 수정해야 하니까.”
그림이 완성되는 느낌이었다. Critic은 단순한 심판이 아니었다. 문제의 성격을 정확히 진단하고, 해결할 수 있는 올바른 담당자(Executor 또는 Planner)에게 돌려보내는 똑똑한 교통정리 담당자였다. 이 ‘순환적 피드백 루프’가 없다면, 시스템은 한번 잘못된 길로 들어섰을 때 되돌아오지 못하고 그대로 멈춰버릴 것이다. Critic의 독립적인 검증과 정확한 피드백이야말로 전체 시스템의 신뢰성을 떠받치는 기둥이었다.
솔라는 이제 ‘잘 되었는가?’라는 질문의 무게를 이해했다. 그것은 단순한 확인이 아니라, 시스템이 길을 잃지 않도록 지켜주는 가장 중요한 안전장치, ‘결과 검증 체계’의 작동 스위치였다.
이제 솔라의 머릿속에는 Planner, Executor, Critic 세 명의 전문가가 각자의 책상에 앉아 있는 모습이 선명하게 그려졌다. Planner는 지도를 그리고, Executor는 그 지도를 보고 탐험에 나선다. 그리고 Critic은 탐험가가 가져온 결과물이 지도와 맞는지, 그리고 탐험의 규칙을 어기지는 않았는지 꼼꼼히 살핀다.
하지만 문득 궁금해졌다. 이 세 명의 전문가가 서로 보고서를 주고받고, 재시도와 재계획을 요청하는 이 모든 과정은 누가 통제하는 걸까? 마치 오케스트라의 지휘자처럼, 이들의 작업을 조율하고 전체 흐름을 관리하는 또 다른 존재가 필요한 것은 아닐까?
5장: 세 역할의 합체: 신뢰성 있는 문제 해결 시스템
솔라의 책상 위에는 이제 제법 익숙해진 세 개의 이름이 적힌 메모지들이 놓여 있었다. [Planner], [Executor] 그리고 [Critic]. 그녀는 펜을 들어 각 메모지 주위에 네모 상자를 그렸다. 계획가, 실행가, 비평가. 각자의 책상에 앉아 있는 전문가들의 모습은 이제 선명했다.
하지만 그 다음이 문제였다. 솔라는 세 개의 상자 사이를 오가며 펜촉을 허공에 맴돌게 했다. 서로 보고서를 주고받고, 재시도와 재계획을 요청하는 이 복잡한 정보의 흐름을 어떻게 그려야 할까? 그녀의 머릿속에는 여전히 지휘봉을 든 ‘지휘자’의 이미지가 떠나지 않았다. 결국 솔라는 세 개의 상자 위에 커다란 상자를 하나 더 그리고 ‘조율자(Coordinator)’라고 적었다. 모든 화살표는 이 ‘조율자’를 향했다가 다시 뻗어나갔다. 그럴듯해 보였지만, 동시에 무언가 잘못되었다는 느낌을 지울 수 없었다. 시스템 위에 또 다른 시스템을 얹은 것처럼 거추장스러웠다.
“결국 이 모든 걸 감시하는 또 다른 역할이 필요한 거 아닐까?”
솔라의 혼잣말에, 어느새 다가온 루나가 그녀의 그림을 들여다보았다. 루나는 ‘조율자’라고 쓰인 상자를 가만히 보더니, 말없이 새 종이 한 장을 가져왔다. 그리고는 솔라가 처음 이 모든 고민을 시작하게 했던 바로 그 문제를 종이 맨 위에 적었다.
“‘버섯 크림 파스타 만들기’.”
루나가 말했다. “솔라, 우리 새로운 역할을 발명하지 말고, 정보가 어떻게 흘러가는지 그냥 따라가 보자. 이 오케스트라에는 지휘자가 없어. 대신 악보가 연주자들 사이를 날아다니는 거야.”
루나는 ‘버섯 크림 파스타 만들기’라는 목표 아래에 화살표를 그리고, 그 끝에 [Planner] 상자를 놓았다.
“자, 맨 처음, 요리라는 목표가 누구에게 전달되지?”
“계획가, Planner에게.” 솔라가 답했다.
“그래. 그럼 Planner는 뭘 내놓지? ‘단계별 요리 계획서’. 그 계획서의 첫 번째 단계, ‘재료 손질하기’는 누구에게 갈까?”
루나는 Planner 상자에서 나온 화살표를 다음 상자로 이었다. 솔라는 자연스럽게 그 상자에 **[Executor]**라고 적었다. 역할별 개별 지식만으로는 보이지 않던 흐름이 눈앞에 그려지기 시작했다.
“Executor는 ‘재료 손질하기’라는 임무를 받고, 칼과 도마라는 ‘도구’를 사용해서 결과를 내놓겠지. 예를 들어 ‘마늘과 버섯 손질 완료’라는 성공 보고서를.”
“만약 성공했다면, 그 다음 단계인 ‘소스 만들기’가 다시 Executor에게 전달되면 되겠네.” 솔라가 말했다. “하지만 실패했다면? 아까처럼 우유를 끓이다가 태웠다면?”
“좋은 질문이야. ‘우유 태움’이라는 실패 보고서는 누가 받아서 평가해야 할까?” 루나가 물었다.
솔라는 망설임 없이 [Critic] 상자를 가리켰다. 계획에도, 실행에도 참여하지 않은 독립적인 평가자.
“Critic은 ‘우유 태움’이라는 결과를 보고 판단하겠지.” 솔라가 빠르게 말을 이었다. “이건 단순한 실수니까, Executor에게 ‘온도에 주의해서 재시도 요청’이라고 피드백을 보낼 거야.”
솔라는 스스로 말하면서 놀라 손으로 입을 가렸다. 그리고는 Critic 상자에서 나와 Executor 상자로 되돌아가는 화살표를 그렸다. 작은 순환 고리, 피드백 루프가 만들어졌다.
“만약 재시도했는데도 계속 우유를 태운다면? 레시피 자체가 잘못됐을 수도 있잖아. ‘중불’이라고 쓰여있지만 사실은 ‘약불’이어야 하는 거지.”
“그때는… Critic이 문제의 종류가 다르다고 판단해야 해!” 솔라의 목소리가 높아졌다. “이건 실행가의 실수가 아니라 계획의 오류야. 그러니까 Critic은 Planner에게 ‘레시피 오류 가능성. 재계획 요청’이라는 피드백을 보내야 해!”
솔라는 이번에는 Critic 상자에서 나와 Planner 상자로 향하는 거대한 화살표를 그렸다. 시스템 전체를 가로지르는 더 큰 순환 고리였다. Planner는 이 피드백을 받아 계획을 수정하고, 수정된 계획은 다시 Executor에게 전달된다.
그 순간, 어지럽던 그림이 하나의 완벽한 흐름도로 완성되었다. 거기에는 ‘조율자’가 들어설 자리가 없었다. 지휘자는 필요 없었다. Planner가 만든 계획이 아래로 흐르고, Executor의 실행 결과가 옆으로 흐르며, Critic의 피드백이 다시 위로 거슬러 올라가는, 스스로 순환하며 문제를 해결하는 시스템이었다. 각 역할은 그저 자신의 책임에 충실하고, 정해진 경로로 정보를 전달할 뿐이었다. 신뢰성은 바로 이 끊임없는 순환적 피드백 루프에서 나왔다.
“아….”
솔라는 처음 AI 에이전트에 대해 읽었던 문장을 떠올렸다. ‘복잡한 문제를 신뢰성 있게 해결하려면, 단일 응답이 아니라 문제 분해, 실행, 검증으로 역할을 분리해야 한다.’ 이제야 그 문장의 진짜 의미가 가슴에 와 닿았다. 역할을 나누는 것은 단순히 업무를 분담하는 차원이 아니었다. 문제 분해(Planner)에서 실행(Executor)으로, 그리고 검증(Critic)을 거쳐 다시 문제 분해로 되돌아오는 견고한 피드백 흐름을 만들기 위한 필연적인 설계였던 것이다.
솔라는 스스로 완성한 흐름도를 보며 만족스러운 미소를 지었다. 역할을 섞어서 혼자 모든 걸 해결하려던 처음의 생각은 얼마나 순진했던가. 책임이 섞이면 피드백 루프가 망가지고, 시스템은 길을 잃게 된다.
그녀는 책상 한편에 있던 새 노트를 펼쳤다. 그리고 맨 위에 새로운 문제 하나를 적었다.
<신뢰성 있는 문제 해결 시스템 설계 제안서: 내 방 청소 자동화 로봇>
솔라는 망설임 없이 그 아래에 세 개의 상자를 그리고, 그 사이를 잇는 두 개의 피드백 화살표를 그려 넣었다. 재시도를 위한 작은 루프와 재계획을 위한 큰 루프. 이제 그녀에게 Planner, Executor, Critic은 단순한 역할 이름이 아니었다. 어떤 복잡한 문제든 신뢰성 있는 해결의 길로 이끌어 줄, 머릿속의 든든한 ‘신뢰성 문제 해결 흐름도’였다. 각 상자 옆에 무엇을 적어 넣어야 할지, 그녀는 이미 알고 있었다.