에이전트

대규모 언어 모델은 아주 많은 텍스트를 미리 읽어 두고 앞의 말에 이어질 말을 골라 내놓는 프로그램입니다. 물어보면 답을 내놓지만 그게 전부입니다. 파일을 열어 보지 못하고, 검색하지 못하고, 어제 자기가 무슨 말을 했는지도 모릅니다. 질문 하나에 답 하나, 그러고 끝입니다.

그래서 조금이라도 여러 단계가 필요한 일은 사람이 중간에서 나르는 모양이 됐습니다. 페이지덱의 태오가 지난 분기 장애 보고서를 원인별로 묶으려 했을 때가 그랬습니다. 먼저 사내 문서함에서 보고서 열네 건을 찾아 복사해 넣고, 요약을 받고, 그 요약을 보고 다시 "이건 같은 원인 같은데 배포 이력 좀 확인해 줘" 라고 치고, 배포 기록을 또 찾아 붙여 넣었습니다. 모델이 한 일은 매번 한 문단을 쓰는 것뿐이었고, 무엇을 다음에 할지 정하고 자료를 날라다 준 것은 전부 태오였습니다. 두 시간 걸렸습니다.

그 왕복에서 태오가 한 판단은 대단한 게 아니었습니다. 자료가 모자라니 더 찾자, 찾았으니 다시 시키자 정도였습니다. 모델도 할 수 있는 판단인데 기회가 없었을 뿐입니다. 에이전트는 그 왕복을 모델 쪽으로 옮긴 구성입니다.

목표를 받은 모델이 다음에 무엇을 할지 스스로 정하고, 주어진 도구 중 하나를 골라 부르고, 돌아온 결과를 다시 읽고, 다 됐다고 판단할 때까지 같은 고리를 돕니다. 한 바퀴가 네 단계입니다.

1. 목표와 도구 목록을 함께 건넵니다. 여기서 도구란 모델이 이름을 부르면 프로그램이 대신 실행해 주는 기능입니다. 문서 검색, 일정 조회, 파일 수정처럼 각각 무엇을 하는지와 무엇을 넣어야 하는지가 설명으로 붙어 있습니다.
2. 모델이 한 걸음을 고릅니다. "장애 보고서를 검색한다" 처럼 도구 하나와 넣을 값을 정해 내놓습니다. 이 단계에서 모델이 실제로 무언가를 실행하지는 않습니다. 무엇을 하겠다고 말할 뿐입니다.
3. 프로그램이 그 도구를 실제로 실행하고 결과를 가져옵니다. 검색 결과 열네 건이든 오류 메시지든 그대로 받아 옵니다.
4. 결과를 모델에게 돌려주고 2번으로 돌아갑니다. 모델은 이번에 받은 것까지 보고 다음 걸음을 다시 정합니다. 목표가 채워졌다고 판단하면 도구 대신 최종 답을 내놓고 고리가 끝납니다.

이 고리가 힘이자 약점입니다. 한 걸음의 정확도가 95퍼센트라도 열 걸음을 이어 밟으면 끝까지 멀쩡할 확률은 60퍼센트로 떨어집니다. 게다가 세 번째 걸음에서 엉뚱한 문서를 집으면 그 뒤 일곱 걸음은 잘못된 자료 위에서 성실하게 진행됩니다. 도중에 환각이 한 번 섞이면, 즉 사실이 아닌 내용을 그럴듯한 문장으로 만들어 내면, 다음 걸음은 그것을 관찰된 사실로 받아 씁니다.

값도 걸립니다. 모델은 한 걸음마다 지금까지의 대화 전체를 다시 읽고 요금은 읽고 쓴 글자량에 매겨지므로, 스무 걸음짜리 작업은 한 번 묻는 것의 스무 배보다 훨씬 비쌉니다. 그래서 걸음 수와 비용에 상한을 걸어 두고 넘으면 사람을 부르게 만듭니다. 파일을 지우거나 메일을 보내는 것처럼 되돌릴 수 없는 도구에는 실행 전 사람 확인을 끼웁니다.

한 번의 답으로 끝나지 않고, 중간 결과를 보고 다음에 무엇을 할지 정해야 하는 일에 씁니다. 반대로 입력 하나를 결과 하나로 바꾸는 일에는 쓰지 않습니다.

개발 쪽이 가장 많이 씁니다. 이슈 하나를 주면 관련 파일을 찾아 읽고, 고치고, 테스트를 돌리고, 깨진 테스트를 보고 다시 고치는 도구가 이미 널리 쓰입니다. 테스트 결과라는 확실한 채점표가 매 걸음 돌아온다는 점이 이 영역과 잘 맞습니다.

고객 문의도 흔한 자리입니다. 챗봇은 원래 정해진 답을 골라 주는 창구였는데, 에이전트로 만들면 "지난달 결제 왜 두 번 됐죠" 라는 질문에 결제 내역을 조회하고 환불 규정을 확인한 뒤 답합니다. 정해 둔 답 목록에 없던 질문도 처리됩니다.

반대로 문서 하나를 요약하거나 문장을 다듬는 일에는 필요 없습니다. 지시문을 다듬는 프롬프트 엔지니어링이나, 사내 자료에서 관련 대목을 찾아 지시문에 붙여 주는 RAG로 충분합니다. 굳이 고리를 돌리면 값과 실패 확률만 늘어납니다.

"이건 한 번에 답할 수 있는 일이 아니라 에이전트로 돌려야 할 것 같은데요."

중간에 자료를 더 찾아야 해서 지시문 한 번으로는 안 된다는 뜻입니다.

"열두 번 돌고도 답을 못 내고 토큰만 먹었어요. 걸음 수 상한 걸죠."

고리가 끝나지 않고 같은 자리를 맴돌았으니 강제로 끊자는 제안입니다.

"쓰기 도구는 사람이 확인하고 나가게 막아 뒀어요."

읽기만 하는 도구는 자유롭게 부르되 무언가를 바꾸는 도구는 승인을 거치게 했다는 뜻입니다.

페이지덱에서는 태오가 사내 문의 응대에 이 구성을 처음 붙였습니다. 앞의 장애 보고서 정리를 두 시간 들여 손으로 해 본 뒤였습니다. 문서 검색과 배포 이력 조회를 도구로 붙이고 걸음 수를 여덟으로 묶었더니 같은 일이 4분에 끝났습니다. 대신 여덟 걸음 안에 못 끝낸 요청이 다섯 건에 한 건꼴로 나와 사람에게 넘어갔습니다.

지현은 그 한 건을 어떻게 다룰지부터 물었습니다. 못 끝냈다고 말하고 넘기는 것과 모른 채 그럴듯한 답을 내놓는 것은 사용자에게 전혀 다른 사고이기 때문입니다. 그래서 답을 내보내기 전에 근거 문서가 붙었는지 확인하는 검사를 더 걸었습니다.

에이전트를 붙이면 사람 손이 빠진다고 읽는 경우가 가장 많습니다. 시연 영상에서 목표 한 줄을 넣자 알아서 열 걸음을 밟고 결과를 내놓으니 그렇게 보입니다. 실제로는 손이 빠지는 게 아니라 옮겨 갑니다. 도구를 만들고 설명을 다듬는 일, 어디까지 자동으로 하고 어디서 사람을 부를지 정하는 일, 실패한 요청을 받아 처리하는 일이 새로 생깁니다. 이 옮겨 간 몫을 계산에 넣지 않으면 도입 후 두 달쯤에 "사람이 더 바빠졌다" 는 말이 나옵니다.

모델이 더 똑똑해진다고 읽는 것도 흔합니다. 여러 걸음을 밟으니 사고력이 붙은 것처럼 보입니다. 하지만 각 걸음을 판단하는 것은 같은 모델이고, 달라진 것은 자기가 만든 결과를 다시 볼 기회가 생겼다는 점뿐입니다. 이 차이를 놓치면 모델이 못 하던 판단을 고리만 더해서 시키게 되고, 틀린 판단이 여러 걸음에 걸쳐 증폭된 채로 나옵니다. 되는 일을 여러 번 시키는 게 에이전트이지, 안 되는 일이 되게 만드는 장치가 아닙니다.