일을 끝내는 에이전트는 어디에서 배울까

ServiceNow-AI 팀이 Hugging Face 블로그에 공개한 글 AutoSynthData: Generating Training Data for Enterprise Agents는 기업 일을 대신 처리하는 에이전트를 가르칠 학습 데이터를 합성으로 만드는 흐름을 다룬다. 이 글이 내세우는 주장은 하나의 문장으로 정리된다, 기업 현장에서 일하는 에이전트에게는 한 번의 답이 아니라 도구 호출과 환경 반응이 얽힌 여러 단계의 궤적 데이터가 필요하고 그런 데이터는 합성 파이프라인으로 만들고 실행으로 걸러내야 한다는 것이다. 원문 링크는 제목 아래에 걸어두었다.

제가 이 글을 붙잡고 읽은 이유는 문제의식의 순서가 현장과 닮았기 때문이다. 모델이 똑똑해졌는데도 막상 기업 일을 맡기면 중간에 길을 잃는 장면을 여러 번 봤기 때문이다. 답은 잘하는데 결재는 못 올리고, 요약은 잘하는데 환불 처리는 끝내지 못하는 모습이죠. 그렇다면 무엇이 비어 있을까. 대답을 가르치는 데이터는 많은데 일을 끝내는 경험을 가르치는 데이터는 드물다는 것이 이 글의 출발점이다. 오늘은 그 진단을 따라가며 합성 데이터가 어떻게 만들어지고 어디에서 흔들리는지를 차례로 짚어본다.

왜 답을 잘하는데도 일은 끝내지 못할까

질문에 답하는 일과 기업에서 일을 끝내는 일은 다른 근육을 쓴다. 답은 한 번의 생성으로 끝나지만, 일은 여러 번의 선택으로 이어지기 때문이다. 파일을 열고, 기록을 조회하고, 도구를 부르고, 돌아온 반응을 읽고, 다음 행동을 고르는 순환이 반복되죠. 이 순환을 궤적이라고 부르면 이해가 쉬운데, 답이 점이라면 궤적은 선이기 때문이다. 점만 모아서는 선을 긋는 법을 가르칠 수 없다. 그렇다면 기업 에이전트에게 필요한 데이터는 무엇일까. 정답 문장이 아니라 선택과 반응이 번갈아 나타나는 기록이다.

생각해보면 사람도 비슷하게 배웁니다. 신입사원이 결재 절차를 익힐 때 매뉴얼 한 줄을 외워서 되는 것이 아니기 때문이다. 누구에게 먼저 올려야 하는지, 반려되면 어디를 고쳐야 하는지, 시스템에 오류가 뜨면 누구에게 물어봐야 하는지를 겪으면서 익히죠. 매뉴얼은 출발점일 뿐이고, 진짜 학습은 막힌 자리에서 생긴다. 에이전트도 마찬가지인데, 한 번의 질문과 답만 보여주면 막힌 자리에서 무엇을 해야 하는지를 배우지 못한다. 그래서 이 글은 처음부터 데이터의 단위를 다르게 잡는다. 주고받는 한 마디가 아니라 끝까지 간 발자취를 모아야 한다는 것이다.

저는 이 대목에서 고개를 끄덕였습니다. 오랫동안 우리는 답의 정확도로 모델을 재어 왔는데, 현장의 실패는 정확도가 아니라 중단에서 생기기 때문이다. 도구가 오류를 뱉었을 때 멈추지 않고 상태를 확인하는지, 잘못 누른 뒤에 되돌아가는지를 묻는 시험은 드물었다. 답을 맞히는 시험에서는 이런 복구의 흔적이 점수에 남지 않는다. 그런데 현장에서는 복구가 실력이다. 밤사이 돌아가는 정산 작업이 중간에 멈추면 아침에 사람이 뒤치다꺼리를 하게 되니까요. 이런 관점에서 보면 궤적 데이터는 점수 올리기가 아니라 밤의 운영을 지키는 일이다.

여기서는 조금 조심해서 읽을 필요가 있는데, 단일 응답 데이터가 쓸모없다는 뜻은 아니기 때문이다. 언어 이해와 요약 같은 기초 체력은 여전히 그런 데이터에서 온다. 다만 일을 맡기겠다고 마음을 먹은 뒤에는 가르칠 것이 달라진다. 무엇을 아는지를 넘어 막혔을 때 어떻게 움직이는지를 보여줘야 하기 때문이다. 저는 그래서 이 첫 번째 구분이 글 전체의 문턱이라고 봅니다. 궤적을 단위로 삼지 않으면 뒤에 나오는 합성과 검수의 이야기가 모두 헛돌기 때문이다.

기업 데이터는 왜 밖에 나오지 못할까

궤적이 필요하다는 데까지는 이견이 적다. 문제는 그다음인데, 기업 현장은 데이터를 밖으로 내보내기 어려운 구조이기 때문이다. 첫째로 개인정보와 권한이 걸린다. 고객 기록과 결제 내역과 인사 정보는 마구 복사해서 학습에 쓸 수 없죠. 둘째로 시스템이 흩어져 있다. 인사 도구는 따로, 재무 도구는 따로, 티켓 도구는 따로 놀면서 서로 말도 잘 통하지 않는다. 셋째로 가르칠 만한 표시가 없다. 계획이 좋았는지, 복구가 적절했는지를 적어둔 성적표가 현장에는 없기 때문이다.

이 세 가지가 겹치면 데이터는 있어도 쓸 수 없는 상태가 된다. 로그는 어딘가에 쌓이지만 누구의 무엇이 섞였는지 몰라서 손대기 어렵고, 화면 너머의 절차는 사람 머릿속에만 있고 문서에는 없다. 가령 월요일 아침 9시에 누군가 휴가를 신청했다고 해보자. 그 한 줄 뒤에는 잔여 연차 조회와 대결자 지정과 팀장 승인과 인사 반영이라는 여러 단계가 숨어 있다. 그런데 로그에는 클릭 몇 개만 남고, 왜 그렇게 눌렀는지는 남지 않는다. 이런 기록을 그대로 모으면 행동의 껍데기만 모인다. 속사정이 빠진 데이터로는 다음 사람을 가르치기 어렵죠.

식당 주방에 비유하면 이해가 쉬운데, 주문표만 모아서는 주방을 배울 수 없기 때문이다. 불 조절은 언제 했는지, 재료가 떨어졌을 때 무엇으로 바꿨는지, 손님이 갑자기 예민한 요청을 했을 때 순서를 어떻게 바꿨는지가 빠져 있기 때문이다. 기업 로그도 마찬가지다. 결과는 남아도 판단은 남지 않는다. 그래서 현장 데이터를 긁어모으는 것만으로는 궤적이 되지 않는다. 판단의 흔적까지 살려내야 하는데, 바로 그 흔적이 개인정보와 권한에 묶여 있다. 이 막힘을 어떻게 풀지가 다음 이야기로 이어진다.

흩어진 문서에서 일감을 꺼내는 일은 어떻게 시작될까

이 글이 그리는 파이프라인은 데이터를 캐는 일이 아니라 일을 만드는 일부터 시작한다. API 명세와 사용 문서와 익명화된 로그를 재료 삼아 에이전트가 풀 만한 과제를 먼저 빚는 것이다. 명세에는 도구가 무엇을 받고 무엇을 뱉는지가 적혀 있고, 문서에는 절차의 순서가 적혀 있으며, 로그에는 사람들이 자주 부딪히는 자리가 어렴풋이 남아 있다. 이 재료들을 엮으면 빈 종이가 아니라 일감이 나온다. 가령 비용 처리를 마감하는 과제라든가, 장애 티켓을 분류해 담당자에게 넘기는 과제 같은 것이다.

여기서 재미있는 질문이 생깁니다. 과제를 만드는 일부터 자동화해야 할까. 사람이 직접 과제를 적어주면 되지 않을까. 짧게 보면 그 말이 맞는데, 길게 보면 이야기가 달라진다. 기업 일은 한두 가지가 아니라 수백 가지이고, 각 일마다 쓰는 도구와 순서가 다르기 때문이다. 사람이 일일이 과제를 적으면 처음 몇 개는 정성스럽지만 뒤로 갈수록 힘이 빠진다. 그래서 과제를 빚는 기계를 먼저 만드는 선택이 나온다. 재료를 넣으면 일감이 나오는 틀을 만드는 것이죠. 이 틀이 좋아야 뒤의 학습이 산으로 가지 않는다.

저는 이 순서를 현장의 눈으로 읽었다. 저희가 새로운 AI 구조를 볼 때도 숫자보다 먼저 묻는 것이 재료와 순서이기 때문이다. 무엇을 넣었길래 저런 결과가 나왔는지를 먼저 따지죠. 명세만 넣었는지, 문서까지 넣었는지, 로그의 냄새까지 살렸는지가 과제 냄새를 바꾼다. 명세만 쓰면 깔끔하지만 현장감이 떨어지고, 로그를 섞으면 현장감이 살지만 노이즈도 함께 들어온다. 재료를 어떻게 섞느냐가 파이프라인의 성격을 정한다. 그렇다면 빚어낸 과제를 누가 풀어줄까. 그 자리에 선생 모델이 등장한다.

선생에게 먼저 풀게 하면 무엇이 남을까

과제가 준비되면 선생 역할을 맡은 모델이 여러 번 풀어보며 궤적을 뽑아낸다. 한 번 풀고 끝내는 것이 아니라 여러 풀이를 뽑아내서 고를 거리를 만드는 것이다. 어떤 풀이는 곧장 가고, 어떤 풀이는 돌아가고, 어떤 풀이는 중간에 미끄러진다. 이 갈림길이 있어야 가르칠 이야기가 생긴다. 곧장 간 길만 모으면 잘된 자랑만 모은 셈이 되기 때문이다. 돌아갔던 길과 미끄러졌던 길까지 함께 있어야 복구의 맛이 산다.

그런데 여기서 바로 다음 질문이 따라붙는다. 선생이 틀리면 그 틀린 길까지 데이터가 되지 않을까. 맞는 걱정이다. 선생도 헛짚을 때가 있고, 도구를 잘못 부를 때가 있으며, 그럴듯한 말로 빈 구멍을 메울 때가 있기 때문이다. 그래서 뽑아낸 궤적을 그대로 쓰지 않고 걸러내는 장치가 뒤에 붙는다. 만들기가 절반이라면 가리기가 나머지 절반이다. 저는 이 균형 감각이 파이프라인 글의 미덕이라고 봤다. 생성만 외치는 글이 아니라 생성 뒤의 뒷수습까지 함께 그리기 때문이다.

개인적으로 인상 깊었던 점은 풀이를 여러 개 뽑는다는 선택이다. 답 하나만 뽑으면 운이 실력이 되는데, 여러 개를 뽑으면 분포가 보이기 때문이다. 늘 같은 자리에서 미끄러진다면 그 과제가 가르치는 바가 또렷하고, 매번 다른 자리에서 미끄러진다면 과제가 아직 덜 익었다는 신호가 된다. 분포를 보면 과제의 얼굴이 보인다. 이 얼굴을 보고 남길 것과 버릴 것을 가르는 일이 다음 단계의 몫이다.

실행으로 걸러내지 않으면 무엇이 섞일까

걸러내는 일의 기준은 생각보다 단단하다. 말솜씨가 아니라 실행이기 때문이다. 도구를 실제로 부려서 돌아온 반응이 맞는지, 정해진 시험을 통과하는지, 심사 역할을 맡은 모델의 눈에도 어긋나지 않는지를 본다. 말로만 그럴듯한 궤적은 여기서 떨어진다. 도구를 불러 확인했더니 없는 고객 번호를 지어낸 것이라면 탈락이고, 순서를 바꿔 눌렀더니 처리가 꼬였다면 탈락이다. 실행은 거짓말을 잘 잡아낸다. 종이 위에서는 번듯하던 계획이 현장 문 앞에서 무너지는 법이니까요.

공항 검색대에 비유하면 감이 오는데, 말로 소지품을 설명하는 것만으로는 통과가 안 되기 때문이다. 가방을 열고 엑스레이를 통과해야 한다. 궤적 검수도 마찬가지다. 어떤 도구를 어떤 값으로 불렀고, 환경이 무엇이라고 답했고, 그 답을 보고 다음에 무엇을 했는지가 줄줄이 맞아야 통과다. 이 줄줄이라는 말이 부담스럽지만, 바로 그 부담이 품질을 지킨다. 한 칸만 어긋나도 전체가 흔들리는 게 기업 일이기 때문에, 검수는 깐깐할수록 좋다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이렇게 깐깐하게 걸러내면 남는 게 너무 적어지지 않을까. 맞는 걱정인데, 답은 두 갈래다. 기준을 낮춰서 양을 늘리면 쓰레기가 섞이고, 기준을 높여서 질을 지키면 양이 준다. 이 글의 태도는 후자에 가깝다. 틀린 궤적을 넣느니 적은 궤적으로 가르치는 편이 낫다는 것이다. 틀린 경험은 가르침이 아니라 오염이기 때문이다. 저는 이 태도가 운영자의 언어와 닿아 있다고 봅니다. 밤에 멈추지 않는 라인을 만들려면 양보다 탈락의 이유가 또렷해야 하니까요. 그렇다면 통과한 궤적만 모으면 끝일까. 아직 한 가지가 더 남는다.

흔한 일만 모으면 무엇이 비어 보일까

통과한 궤적을 쌓다 보면 어느새 흔한 일이 산더미가 된다. 비밀번호를 초기화하거나 문서를 요약하거나 티켓을 분류하는 일 같은 것이다. 이런 일만 잔뜩 넣고 학습하면 모델은 흔한 일에는 능숙해지지만 드문 일 앞에서는 얼어붙는다. 그런데 현장의 아픔은 대개 드문 일에서 터진다. 분기 마감일에 겹친 환율 오류라든가, 권한이 꼬인 채로 들어온 긴급 승인 같은 것이다. 자주 일어나지 않지만 일어나면 큰 일들이죠. 그래서 분포를 고르게 손질하는 손길이 필요하다. 흔한 일을 덜어내고, 드문 일을 챙기고, 난이도를 섞는 일이다.

꼬리가 긴 분포를 떠올리면 이해가 쉬운데, 머리에는 몇 가지 흔한 일이 몰려 있고 꼬리에는 수많은 드문 일이 길게 늘어져 있기 때문이다. 머리로만 가르치면 꼬리는 텅 빈다. 이 글은 그래서 양보다 결을 본다. 같은 유형만 열 번 반복하는 대신 다른 유형을 한 번씩 맛보게 하자는 것이다. 가령 다섯 번의 쉬운 조회 뒤에 한 번의 꼬인 승인을 섞는 식이다. 이렇게 섞어야 모델이 낯선 자리에서도 손이 멈추지 않는다.

저는 여기서 현장의 오래된 고민을 떠올렸다. 교육을 할 때도 쉬운 일만 반복하면 사람은 편해지지만 실력은 안 는다. 적당히 어려운 일을 섞어야 등줄기에 땀이 나면서 감이 생기기 때문이다. 데이터도 마찬가지인데, 너무 쉬운 궤적만 주면 모델은 흉내만 늘고, 너무 어려운 것만 주면 포기부터 배운다. 난이도의 결을 맞추는 일이 그래서 가르치는 일의 본질에 가깝다. 문제는 이 손질이 끝이 아니라는 데 있다. 잘 빚고 잘 걸러도 다른 구멍이 남기 때문이다.

선생의 버릇까지 베끼게 되면 어떻게 될까

합성 데이터의 그림자 이야기로 넘어가보자. 선생 모델로 궤적을 뽑으면 선생의 버릇까지 함께 들어오기 때문이다. 선생이 즐겨 쓰는 표현, 자주 고르는 순서, 잘 모를 때 얼버무리는 방식이 데이터에 스며든다. 제자는 답만 배우는 것이 아니라 말버릇까지 배운다. 더구나 선생이 머뭇거리는 틀림이 아니라 확신에 찬 틀림을 보이면 제자는 그것을 정답인 줄 알고 외운다. 겉으로는 매끈한데 속으로는 비뚤어진 데이터가 쌓이는 것이다.

여기서는 조금 조심해서 읽을 필요가 있다. 선생이 나쁘다는 이야기가 아니기 때문이다. 선생 없이 궤적을 뽑을 방법이 마땅치 않은 것도 사실이다. 다만 선생의 눈높이가 데이터의 천장이 된다는 것을 알아야 한다. 선생이 못 보는 노이즈는 데이터에도 없고, 선생이 싫어하는 복구 방식은 데이터에도 없다. 현장의 지저분함이 선생의 깔끔함으로 다림질되는 셈이죠. 실제 기업 현장은 시끄럽다. 권한은 중간에 막히고, 문서는 서로 어긋나고, 담당자는 자리를 비운다. 이런 소음이 선생의 풀이에는 없다. 조용한 방에서 푼 풀이만 모으면 시끄러운 현장에서는 바로 흔들린다.

생각해보면 사람도 비슷하게 배웁니다. 모범 답안만 보고 자란 신입은 모범적인 상황에서만 일하고, 예외가 터지면 선배를 찾는다. 예외를 겪어본 신입은 조금 느려도 혼자 버틴다. 합성 데이터도 마찬가지인데, 매끈한 성공담만 모으면 예외 앞에서 무너진다. 저는 이 대목이 글의 정직한 자리라고 봅니다. 합성을 칭찬만 하지 않고 그림자까지 함께 적었기 때문이다. 이런 솔직함이 있어야 독자는 기술을 사는 게 아니라 빌려 쓰는 법을 배운다. 그렇다면 이 그림자를 알면서도 합성을 쓰는 이유는 무엇일까. 대안이 마땅치 않기 때문이 아니라, 고칠 길이 보이기 때문이다.

화면이 바뀌는 월요일 아침을 어떻게 따라갈까

마지막으로 남은 숙제는 시간이다. 기업 현장은 가만히 있지 않기 때문이다. API는 버전을 올리고, 화면은 위치를 바꾸고, 규정은 문구를 고치고, 조직은 이름을 바꾼다. 오늘이 통하던 궤적이 다음 달에는 어긋난다. 가령 환불 버튼이 화면 왼쪽에서 오른쪽으로 옮겨갔다고 해보자. 사람은 두리번거리다 찾지만, 버튼 위치를 외워버린 에이전트는 엉뚱한 곳을 누른다. 규정이 바뀌어 승인 한도가 달라졌는데 옛날 한도로 결재를 올리면 반려된다. 데이터는 과거의 사진이고 현장은 오늘의 날씨인데, 사진만 보고 날씨를 맞히라는 셈이 된다.

이 간격을 좁히려면 합성 파이프라인도 살아 있어야 한다. 명세가 바뀌면 과제도 바뀌고, 검수 기준도 바뀌고, 분포 손질도 다시 해야 한다. 한 번 만들어 쌓아두는 창고가 아니라 계절마다 다시 짓는 텃밭에 가깝다. 저는 이 비유가 글의 여운과 잘 맞는다고 봅니다. 데이터는 모으는 것이 아니라 기르는 것이라는 말이 현장에서는 더 정확하기 때문이다. 가꾸지 않으면 잡초가 나고, 잡초는 늘 예외라는 이름으로 난다.

그렇다면 이 흐름을 어디에서 끊지 않고 이어갈 수 있을까. 답은 거창하지 않다. 바뀐 것을 빨리 알아채는 눈과 버릴 것을 빨리 버리는 손이다. 새로 바뀐 명세를 파이프라인에 빨리 먹이고, 옛날 궤적은 미련 없이 덜어내는 것이다. 말은 쉬운데 손은 바쁘다. 그래도 이 바쁨을 피하면 대가가 따른다. 어제의 정답으로 오늘의 일을 가르치게 되니까요. 이 대목에서 저는 운영자의 어깨가 무거워지는 것을 느꼈다. 모델을 키우는 일보다 파이프라인을 살려두는 일이 더 오래가는 숙제이기 때문이다.

숫자가 아니라 운영으로 보면 무엇이 달라질까

여기까지 오면 관점을 바꿔볼 차례이다. 합성 데이터를 점수로만 보면 절반만 본 셈이기 때문이다. 운영으로 보면 질문이 달라진다. 얼마나 맞았느냐가 아니라 밤사이 얼마나 버텼느냐를 묻게 되죠. 실패했을 때 멈추지 않고 다음 행동을 골랐는지, 권한이 막혔을 때 우회하지 않고 정석대로 물었는지, 애매할 때 독단으로 처리하지 않고 사람에게 넘겼는지를 본다. 점수표에는 없는 장면들이지만 현장에서는 이 장면들이 돈을 가른다.

예를 들어 늦은 밤 정산 배치를 떠올려보자. 백 건 가운데 아흔아홉 건을 척척 처리해도 한 건에서 엉뚱한 환불을 쏘면 아침이 시끄러워진다. 아흔아홉 개의 성공보다 한 개의 실패가 더 크다. 그래서 운영자는 평균을 묻지 않고 최악을 묻는다. 가장 아픈 실패가 무엇이었고, 그 실패를 어떻게 막았는지를 묻죠. 합성 데이터도 같은 눈으로 봐야 한다. 통과율이 얼마인지보다 어떤 실패를 덜어냈는지가 더 말을 한다. 탈락의 이유가 또렷한 파이프라인이 좋은 파이프라인이다.

저희가 새로운 AI 구조를 볼 때도 점수만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 합성 파이프라인도 마찬가지인데, 과제를 빚는 데 든 손과 검수에 든 손과 다시 기르는 데 든 손을 함께 쳐야 한다. 한 번 잘 뽑고 끝나는 장사가 아니라 계속 돌려야 하는 맷돌이기 때문이다. 이런 눈으로 보면 이 글은 점수 자랑이 아니라 일하는 방식의 제안으로 읽힌다. 데이터를 쌓는 법이 아니라 일을 기르는 법을 말하기 때문이다.

그래서 다음에는 무엇을 지켜봐야 할까

이제 남은 빈칸을 모아보려 한다. 이 글이 그린 파이프라인은 뼈대가 또렷하지만 살이 붙을 자리가 많다. 제가 앞으로 보고 싶은 것은 세 가지인데, 첫째는 소음이다. 실제 현장의 지저분함을 데이터에 어떻게 담을지가 궁금하기 때문이다. 권한 막힘과 문서 어긋남과 중간 변경 같은 소음을 일부러 넣고 가르칠 수 있을까. 조용한 방에서만 연습한 선수가 시끄러운 경기장에서 뛰게 하려면 연습장에 소음을 틀어줘야 하지 않을까.

둘째로 보고 싶은 것은 선생 넘기다. 선생의 천장을 어떻게 뚫을지가 궁금하기 때문이다. 선생끼리 서로 검수하게 할 수도 있고, 사람 손으로 고친 궤적을 조금 섞을 수도 있으며, 실행이라는 빳빳한 자로 선생의 말버릇을 깎을 수도 있다. 어떤 손질이 버릇을 걷어내고 실력만 남기는지가 궁금하죠. 셋째로 보는 것은 가꾸는 속도인데, 명세와 규정이 바뀔 때 파이프라인이 얼마나 빨리 따라오는지를 보고 싶기 때문이다. 한 달 늦게 따라오는 파이프라인과 다음 날 따라오는 파이프라인은 다른 기계다. 이 속도가 운영의 아침을 가른다.

돌아보면 처음 질문은 단순했다. 일을 끝내는 에이전트는 어디에서 배울까. 답도 단순해졌다. 답안지가 아니라 발자취에서 배운다는 것이다. 발자취는 캐는 것이 아니라 빚고, 걸러내고, 손질하고, 계속 가꾸는 것이다. 저는 이 말이 글의 가장 실용적인 선물이라고 봅니다. 거창한 구호 없이 재료와 순서와 뒷수습으로 말하는 방식이기 때문이다. 앞으로 에이전트가 더 오래 일하고 더 많은 도구를 만질수록, 이런 식의 기르기는 선택이 아니라 습관이 되어야 할 것 같다. 여러분 팀의 일 가운데 가장 가르치기 어려운 예외 하나를 떠올려보자. 그 예외를 담은 궤적 하나가 열 개의 모범 답안보다 아침을 더 잘 지키지 않을까.