LLMOps 09
Workflow Spec: 시스템의 흐름을 계약처럼 고정하기
Agent를 연결하면 흐름은 코드가 알아서 정한다고 생각하기 쉽다.
근거 · 교안 p27
1장: Agent, 정말 코드가 알아서 해줄까요?
솔라가 노트북 화면의 한 문장에 시선을 고정한 채 미동도 하지 않았다. 화면에는 짧은 문장이 떠 있었다.
Workflow Spec은 Agent들이 어떤 순서와 조건으로 동작하는지, 분기와 반복과 종료 조건을 정의한다.
솔라는 고개를 갸웃거렸다. ‘Agent들을 여러 개 만들어서 연결하면, 알아서 착착 진행되는 거 아니었어? 똑똑한 AI들인데. 굳이 사람이 미리 순서랑 조건을 다 정해줘야 한다고? 마치 코드가 알아서 할 일을 못 믿는다는 것처럼 들리네.’
생각이 꼬리에 꼬리를 물자, 솔라는 결국 거실 소파에 앉아 책을 읽고 있는 언니 루나에게 노트북을 들고 다가갔다.
“언니, 나 이거 좀 이상해. 여러 AI Agent를 쓰는 시스템을 만든다고 생각해봐. 각자 역할 주고 잘 연결하면 시스템이 알아서 돌아가는 거 아니야? 그런데 왜 ‘워크플로우 스펙’이라는 걸로 동작 순서나 조건을 미리 다 정의해야 한다는 거지? 그냥 코드가 흐름을 잘 제어하게 만들면 될 것 같은데.”
루나는 솔라의 질문을 듣고 책갈피를 꽂으며 잠시 생각에 잠겼다. 이내 고개를 끄덕이며 옆에 있던 빈 노트를 가져와 펼쳤다.
“그렇게 생각하기 쉽지. 그럼 우리 간단한 상상 실험 하나 해볼까?”
루나는 노트 중앙에 ‘AI 면접관 시스템’이라고 적었다.
“만약 우리가 AI 면접관을 만든다고 해보자. 어떤 역할을 하는 Agent들이 필요할까?”
질문이 떨어지자마자 솔라는 기다렸다는 듯 대답했다.
“음, 일단 지원자 이력서를 분석하는 ‘이력서 분석 Agent’가 있어야 하고! 분석 결과를 바탕으로 뭘 물어볼지 전략을 짜는 ‘질문 전략 Agent’, 그리고 실제로 질문 문장을 만드는 ‘질문 생성 Agent’도 필요하지. 아, 지원자 답변을 평가하는 ‘답변 평가 Agent’랑 마지막으로 전체 내용을 정리해서 보고서를 쓰는 ‘보고서 작성 Agent’까지! 다섯 개면 되겠다!”
루나는 솔라가 말한 다섯 Agent를 노트에 동그라미로 그리며 나열했다.
“완벽하네. 자, 이제 이 다섯 명의 유능한 전문가들을 한 방에 모아놓고 ‘자, 이제 면접을 시작하세요!’라고만 했다고 상상해봐. 솔라 네가 말한 대로, 코드로 똑똑하게 구현된 Agent들을 그냥 연결만 한 거야. ‘워크플로우 스펙’ 같은 사전 약속은 전혀 없는 상태로. 맨 처음 무슨 일이 벌어질까?”
솔라는 눈을 감고 그 장면을 그려보았다. 똑똑한 Agent들이 각자의 자리에서 의욕에 넘쳐 일을 시작하는 모습. 하지만 잠시 후, 솔라의 미간이 좁혀졌다.
“음… 어? 잠깐만.”
솔라의 표정이 금세 심각해졌다.
“보고서 작성 Agent가 제일 먼저 ‘보고서를 시작하겠습니다!’ 하고 일을 시작할 수도 있겠네. 면접은 시작도 안 했는데. 아니면 질문 생성 Agent가 이력서 분석이 끝나기도 전에 아무 질문이나 막 던져버릴 수도 있고. 답변 평가 Agent는 지원자가 대답도 안 했는데 ‘답변 내용이 부족합니다’라고 평가해버릴지도 몰라! …완전 난장판이잖아.”
상상만으로도 머리가 어지러워진 솔라가 말했다.
“바로 그거야. 난장판이 되지.”
루나가 조용히 말했다.
“각 Agent가 아무리 똑똑하고 유능해도, ‘언제’ 자기 일을 시작하고, ‘누구의’ 일이 끝난 다음에 자기 일을 해야 하는지, ‘어떤 조건’에서 행동을 바꿔야 하는지에 대한 공통의 약속이 없으면 시스템 전체가 우왕좌왕하게 돼. 각자는 최선을 다하지만, 전체적으로는 아무것도 이루지 못하는 거지.”
그 순간 솔라는 무릎을 탁 쳤다.
“아! 알겠다. 이건 개별 Agent의 능력이나 코딩 실력의 문제가 아니구나. 코드를 한 줄 짜기 전에, 이 똑똑한 Agent들이 함께 일하기 위한 ‘규칙’이나 ‘계약’을 먼저 정하는 거네! 마치 팀 프로젝트 할 때 역할만 나누는 게 아니라, 누가 먼저 자료 조사를 하고, 그걸 언제까지 누구한테 전달해서 발표 자료를 만들지 미리 약속하는 것처럼!”
솔라는 아까 자신이 이상하게 여겼던 문장을 다시 떠올렸다. ‘Workflow Spec은 Agent들이 어떤 순서와 조건으로 동작하는지 정의한다.’ 이제 그 문장이 전혀 다른 의미로 다가왔다.
“이제야 이해가 돼. ‘정의한다’는 건, 코드로 구현하기 전에 시스템 전체의 흐름을 하나의 ‘계약서’처럼 미리 고정해서, 모두가 그 계약을 따르게 만드는 거구나. 그래야만 예측 가능하고 안정적인 시스템이 되는 거였어.”
스스로 내린 결론에 고개를 끄덕이던 솔라의 눈이 다시 반짝였다. 새로운 궁금증이 떠오른 것이다.
“언니, 그럼 그 ‘계약서’에는 정확히 어떤 내용이 들어가? 순서 말고 또 뭘 정해줘야 이런 혼란을 완벽하게 막을 수 있는 거지? 그냥 ‘A 다음에 B가 일한다’고 순서만 적는 걸로는 부족할 것 같은데….”
2장: 흐름 고정의 ‘목적’: 시스템의 청사진 그리기
솔라의 질문이 채 끝나기도 전에, 루나는 소파 옆 테이블에 놓여있던 노트를 다시 집어 들었다. 어지러운 난장판을 상상하게 했던, 다섯 개의 동그라미가 그려진 바로 그 노트였다. 솔라는 언니가 무엇을 하려는지 지켜보았다.
루나는 말없이 펜을 들어, ‘이력서 분석 Agent’ 동그라미에서 ‘질문 전략 Agent’ 동그라미로 화살표를 그었다. 그리고 다시 ‘질문 전략’에서 ‘질문 생성’으로, ‘질문 생성’에서 ‘답변 평가’로, 마지막으로 ‘답변 평가’에서 ‘보고서 작성’으로 이어지는 화살표들을 차례로 그려 넣었다. 단순한 역할 목록이었던 그림이 이제 막 하나의 흐름을 가진 것처럼 보였다.
“아, 이런 식으로.”
솔라가 화살표의 흐름을 눈으로 따라가며 말했다.
“순서를 정한다는 게 바로 이거구나. 이력서 분석이 끝나면 그 결과를 질문 전략 Agent에게 넘기고, 전략이 나오면 질문을 만들고… 이렇게 순서대로 일이 진행되게 길을 터주는 거네. 이제 보고서 Agent가 면접도 시작 안 했는데 보고서를 쓰는 일은 없겠어.”
단순하고 명쾌한 해결책이라고 생각하며 솔라는 만족스럽게 고개를 끄덕였다. 하지만 루나는 펜을 내려놓지 않았다.
“그럼 이건 어때?”
루나는 ‘이력서 분석 Agent’와 ‘질문 전략 Agent’를 잇는 화살표를 펜 끝으로 톡톡 건드렸다.
“이 화살표를 타고 넘어가는 건 뭘까? ‘이력서 분석’ Agent가 일을 끝내고 ‘질문 전략’ Agent에게 뭘 건네주지?”
“음… 이력서를 요약한 내용? resume_summary 같은 데이터겠지.”
솔라가 즉시 대답했다.
“맞아. 그럼 질문 하나 더. 만약 지원자가 낸 이력서가 너무 부실해서, ‘이력서 분석’ Agent가 아무리 노력해도 의미 있는 요약을 만들지 못했다면? resume_summary가 거의 텅 비어있다면? 그때도 ‘질문 전략’ Agent는 평소처럼 복잡한 전략을 짤까?”
순간 솔라의 머릿속이 멈칫했다. 그냥 순서대로 가면 된다고 생각했는데, 아니었다.
“아니, 당연히 안 되지! 요약본이 없는데 무슨 전략을 짜. 그럴 땐… 아마 경력이나 프로젝트 경험이 아니라 아주 기본적인 인성 질문 같은 걸 물어보는 쪽으로 방향을 틀어야 할 거야. 아니면, 아예 이력서 분석이 실패했으니 면접을 중단해야 할지도 모르고.”
“바로 그거야.”
루나는 솔라의 대답을 듣고는, 두 Agent를 잇던 화살표 중간에 작은 마름모(◇)를 그렸다. 그리고 그 마름모에서 두 갈래의 새로운 화살표를 뽑아냈다. 하나는 기존처럼 ‘질문 전략 Agent’로 향했고, 다른 하나는 ‘기본 질문 생성’이라는 새로운 상자로 향했다.
“Workflow Spec이 정의하는 건 단순히 Agent들의 실행 순서만이 아니야. 이 마름모처럼, 시스템의 흐름 속에서 마주치는 모든 의사결정 지점과 데이터의 흐름까지 모두 포함해. 이력서 요약 데이터가 ‘충분한가?’라는 조건에 따라 시스템이 완전히 다른 길로 가도록 미리 약속해두는 거지.”
루나가 그린 마름모와 두 갈래의 길을 보자 솔라는 눈이 번쩍 뜨였다. 이것은 단순한 순서도가 아니었다.
“아…! 이건 그냥 일의 순서를 적은 목록이 아니라… 집을 짓기 전에 그리는 청사진 같은 거구나!”
솔라가 외쳤다.
“어떤 Agent(방)가 있고, 그 방들을 어떻게 연결할지(복도)뿐만 아니라, 어떤 문으로 들어가고 나갈지, 비상 상황일 땐 어떤 계단으로 가야 할지까지 전부 그려놓은 설계도 말이야! 순서만 정하는 계약이 아니라, 시스템이 움직일 수 있는 모든 경우의 수와 그때마다 따라야 할 규칙을 담은 종합적인 청사진!”
이제 솔라에게 ‘정의한다’는 말은 더 이상 모호하게 들리지 않았다. 그것은 시스템의 뼈대와 혈관, 신경망까지 모두 설계하는 구체적인 행위였다. Workflow Spec은 코딩이라는 벽돌을 쌓기 전에, 어떤 구조의 건물을 지을지 확정하는 가장 중요한 ‘구현 전 계약’이었다.
솔라는 마름모와 여러 갈래의 화살표로 복잡해진 노트를 들여다보았다. 처음에는 그저 난장판이 될까 봐 걱정했지만, 이제는 이 복잡함이 오히려 시스템을 예측 가능하게 만드는 힘이라는 것을 깨달았다.
“알겠어, 언니. Workflow Spec은 시스템의 청사진이야. Agent들이 따라야 할 모든 길과 갈림길을 미리 다 정해두는 거지. 그런데 궁금한 게 생겼어.”
솔라가 펜을 들어 루나가 그린 마름모를 가리켰다.
“이런 청사진을 그릴 때, 건축가들이 기둥, 벽, 창문처럼 꼭 넣어야 하는 기본 요소가 있잖아. 그럼 우리도 이런 시스템 청사진을 그릴 때 반드시 정의해야 하는 핵심적인 ‘구성 요소’들이 정해져 있는 거야? 지금 우리가 그린 이 화살표나 마름모 같은 것들이 그런 요소들에 포함되는 건가?”
3장: 실행 순서, 분기, 반복, 종료: 계약의 5가지 핵심 항목
솔라의 질문에 루나는 대답 대신, 복잡한 화살표와 마름모가 그려진 노트를 다시 자신 쪽으로 끌어당겼다. 솔라는 언니가 펜을 들어, 건축물의 기본 골조를 그리듯 무언가를 추가하기 시작하는 것을 지켜보았다.
루나는 ‘질문 생성 Agent’와 ‘답변 평가 Agent’를 잇는 화살표를 잠시 바라보더니, 그 두 지점을 잇는 새로운 기호를 그려 넣었다. 마치 꼬리를 문 뱀처럼, ‘답변 평가’에서 다시 ‘질문 생성’으로 되돌아가는 둥근 화살표(↺)였다. 이 기호 하나가 추가되자, 일직선으로 흐르던 청사진은 이제 특정 구간을 맴돌 수 있는 구조를 갖게 되었다. 건축 도면에 없던 ‘회전 계단’이 생긴 것 같았다.
“아까 솔라 네가 건축물의 기둥, 벽, 창문 같은 기본 요소가 있냐고 물었지.”
루나는 펜 끝으로 방금 그린 둥근 화살표와, 이전에 그렸던 직선 화살표(→), 그리고 갈림길을 만들었던 마름모(◇)를 차례로 가리켰다.
“이 기호들이 바로 그 핵심 구성 요소에 해당해. 이 약속들이 없다면, 우리가 애써 그린 청사진은 제 역할을 하지 못하고 무너져 내릴 거야.”
솔라는 고개를 갸웃했다. 기호들의 의미는 대충 짐작이 갔지만, ‘무너져 내린다’는 말은 너무 강하게 들렸다.
“무너진다고? 그냥 좀 불편한 정도가 아니라? 예를 들어 저 마름모, 그러니까 분기 조건이 없으면 아까처럼 이력서가 부실해도 그냥 다음 단계로 넘어가는 정도의 문제 아니야?”
“그럼 한번 시뮬레이션해볼까?”
루나가 노트를 솔라 쪽으로 밀었다.
“우리가 만든 AI 면접관 시스템 청사진에서, 딱 이 마름모(◇) 하나만 지워보자. 이력서 요약이 부실한지 아닌지 판단하는 ‘조건’이 사라진 거야. 자, 이제 면접관이 지원자에게 심층 경력 질문을 던졌는데, 지원자가 ‘잘 모르겠습니다’라고 딱 한마디만 했어. 그럼 다음은 어떻게 될까?”
솔라는 눈을 감고 상상했다. ‘답변 평가 Agent’는 답변을 받았다. 하지만 답변이 충분한지 아닌지 판단해서 다른 행동을 하라는 ‘분기 조건’, 즉 마름모가 없다.
“음… ‘답변 평가 Agent’는 일단 할 일을 했으니까… 그냥 다음 순서인 ‘보고서 작성 Agent’에게 신호를 보내겠지. ‘평가 끝났음’ 하고. 그럼 면접은 그걸로 끝나버리네? 질문 하나 던지고 ‘모르겠다’는 답변 듣고 끝난 면접이라니… 이건 그냥 불편한 게 아니라 시스템 자체가 고장 난 거나 마찬가지야!”
“정확해. 그럼 이번엔 방금 내가 그린 이 둥근 화살표, ‘반복 구조’를 지워보자.”
루나가 말했다.
“첫 번째 질문을 하고, 지원자가 훌륭한 답변을 했어. ‘답변 평가 Agent’도 아주 좋게 평가했지. 자, 그다음은?”
솔라는 잠시 생각할 필요도 없었다. 반복 구조가 없다면 흐름은 다시 일직선이 된다.
“똑같네. ‘답변 평가’ 다음은 ‘보고서 작성’이니까. 질문 딱 하나 하고 면접이 끝나버려. 여러 개의 질문을 주고받으며 심층적인 평가를 한다는 시스템의 핵심 목적 자체가 실패하는구나.”
이제 솔라는 이 기호들이 단순한 그림이 아니라는 것을 깨달았다. 이것들은 시스템의 목적을 지키기 위한 최소한의 안전장치이자, 반드시 지켜야 할 계약의 핵심 조항들이었다.
“마지막으로 하나만 더. 반복 구조는 있는데, 언제 이 반복을 멈춰야 하는지에 대한 규칙, 즉 ‘종료 조건’이 없다면?”
“그건… 상상하기도 싫다. 면접관이 영원히 질문을 던지겠지! 지원자가 도망갈 때까지.”
솔라는 웃음을 터뜨렸지만, 등골이 서늘해지는 기분이었다. 똑똑한 Agent들이 모여 만든 지옥의 무한 면접이라니. 처음 상상했던 ‘난장판’과는 또 다른 종류의 재앙이었다.
루나는 솔라의 깨달음을 지켜보며 조용히 말했다. “이제 보이지? Workflow Spec을 구성하는 핵심 항목들이 왜 ‘계약’인지. 이 항목들은 선택 사항이 아니야. 예측 가능한 시스템을 만들기 위한 필수 조건이지.”
루나는 펜을 들어 노트의 빈 공간에 방금 시뮬레이션했던 개념들을 정리하기 시작했다.
- 실행 순서 (Execution Order): 어떤 Agent가 다음 차례인지 정하는 길. (→)
- 상태 흐름 (State Flow): 그 길을 따라 어떤 데이터가 전달되는지. (
resume_summary) - 분기 조건 (Branching Condition): 특정 조건에 따라 흐름이 나뉘는 갈림길. (◇)
- 반복 구조 (Loop Structure): 특정 구간을 다시 실행하는 순환선. (↺)
- 종료 조건 (Termination Condition): 반복을 언제 멈출지 정하는 마침표. (
5개 질문 완료 시)
“이 다섯 가지가 바로 우리 시스템 청사진의 기둥, 벽, 창문, 계단, 그리고 비상구야. 이 중 하나라도 빠지면 시스템은 의도대로 작동하지 않아.”
솔라는 루나가 정리한 5가지 핵심 항목을 가만히 들여다보았다. 처음에는 그저 ‘코드가 알아서 할 것’이라고 막연하게 생각했던 시스템의 흐름이, 이제는 너무나 명확하고 구체적인 ‘계약서’의 조항들로 보였다. 모호했던 ‘정의한다’는 단어의 의미가 비로소 손에 잡혔다.
스스로 무언가를 확인해보고 싶어진 솔라는 새로운 노트를 펼쳤다. 그리고 맨 위에 ‘나만의 아침 루틴 자동화 시스템’이라고 적었다.
“언니, 그럼 내가 한번 이 계약서 초안을 만들어 볼게.”
솔라는 망설임 없이 그리기 시작했다.
“‘기상 Agent’가 시작. 여기서 ‘오늘 날짜’라는 상태를 ‘날씨 확인 Agent’에게 넘겨. 그다음!”
솔라는 펜에 힘을 주어 마름모를 그렸다.
“분기 조건이야. ‘예보에 비가 오는가?’라는 조건에 따라, ‘예’라면 ‘우산 챙기기 알림 Agent’로 가고, ‘아니오’라면 바로 ‘옷 추천 Agent’로 가는 거지.”
흐름을 그리던 솔라의 손이 잠시 멈췄다.
“아, 여기서는 반복이나 복잡한 종료 조건은 필요 없겠다. 옷 추천이 끝나면 그냥 종료하면 되니까. 모든 시스템에 5가지가 다 들어가야 하는 건 아니구나. 필요한 항목을 골라 명확히 정의하는 게 중요한 거였어.”
자신이 직접 그린 간단한 흐름도. 하지만 이제 솔라에게 그것은 단순한 그림이 아니었다. Agent들이 따라야 할 명백한 규칙과 책임이 담긴, 구현을 위한 단단한 약속, 첫 번째 ‘Workflow Spec’ 초안이었다.