데모는 완벽한데 실전은 왜 자꾸 깨질까 — 믿고 쓰는 AI 에이전트 만드는 법

데모에서는 천재, 실전에서는 사고뭉치

요즘 AI 에이전트 데모 영상 보면 진짜 멋지잖아요. 명령 한 줄 던지면 알아서 검색하고, 코드 짜고, 메일까지 보내고. 그런데 막상 회사 업무에 붙여보면 이상하게 자꾸 삐끗하거든요. 어제는 잘 되던 게 오늘은 엉뚱한 답을 내놓고, 똑같은 질문을 두 번 했는데 결과가 다르고요. 마틴 파울러 블로그에 올라온 이 글은 바로 그 간극을 다뤄요. 제약회사 바이엘(Bayer)이 실제 현업에서 LLM 기반 에이전트를 운영하면서, '어떻게 해야 사람이 믿고 맡길 수 있는 시스템이 되는가'를 정리한 경험담이에요.

왜 지금 이게 중요하냐면요, 대부분의 팀이 지금 '데모는 됐는데 그 다음을 모르겠다'는 벽에 부딪혀 있거든요. 화려한 프로토타입과 실제로 돈 받고 굴리는 제품 사이의 거리가 생각보다 어마어마하게 멀어요.

근본 원인: AI는 '결정적'이지 않다

핵심부터 짚을게요. 우리가 평소 짜는 소프트웨어는 결정적(deterministic) 이에요. 이게 뭐냐면, 같은 입력을 넣으면 항상 같은 결과가 나온다는 뜻이에요. 2 + 2는 백 번을 돌려도 4죠. 그런데 LLM은 달라요. 같은 질문을 줘도 매번 조금씩 다른 답을 내놓는 비결정적(non-deterministic) 존재거든요. 확률적으로 다음 단어를 고르기 때문이에요.

그리고 '에이전트'라는 게 여기에 기름을 부어요. 에이전트가 뭐냐면, LLM이 단순히 답만 하는 게 아니라 스스로 '도구'를 골라 쓰면서 여러 단계를 거쳐 일을 처리하는 구조예요. 검색 도구 호출 → 결과 읽기 → 다시 판단 → DB 조회 → 최종 답변, 이런 식이죠. 그런데 각 단계마다 살짝씩 어긋날 확률이 있으니, 10단계를 거치면 그 오차가 곱해지면서 마지막엔 완전히 산으로 가버려요.

그래서 글이 제안하는 해법들을 풀어보면 이래요.

• 평가(Evals)를 테스트처럼 만들어라. 이게 핵심이에요. 일반 코드에 유닛 테스트가 있듯이, LLM 출력에도 '얼마나 정답에 가까운지'를 자동으로 채점하는 장치를 만드는 거예요. 프롬프트를 한 줄 고쳤을 때 좋아졌는지 나빠졌는지를 감으로 판단하면 안 되고, 수십~수백 개의 케이스로 점수를 내야 한다는 거죠.
• 자율성을 줄이고 작게 쪼개라. 에이전트한테 '알아서 다 해'라고 맡기는 대신, 가능한 부분은 정해진 순서의 워크플로우로 고정하는 거예요. AI가 자유롭게 판단하는 구간을 최소한으로 줄이면 그만큼 사고 칠 여지도 줄어들거든요.
• 출력을 구조화하고 검증(가드레일)하라. 자유 문장 대신 정해진 JSON 형식으로 답하게 하고, 그 값이 규칙에 맞는지 코드로 한 번 더 걸러내요. 이상한 값이면 다시 시키거나 사람에게 넘기고요.
• 관찰 가능성(Observability)을 확보하라. 에이전트가 중간에 무슨 도구를 어떤 순서로 불렀는지 전 과정을 기록(트레이싱)해둬야, 문제가 터졌을 때 어디서 꼬였는지 추적할 수 있어요.
• 사람을 루프에 넣어라. 위험한 작업(결제, 외부 발송 등)은 AI가 제안만 하고 최종 승인은 사람이 누르게 하는 거죠.

업계는 지금 '에이전트 vs 워크플로우' 논쟁 중

이 글의 결이 흥미로운 건, 요즘 업계 흐름과 정확히 맞물려 있어서예요. 앤트로픽이 쓴 'Building Effective Agents' 글에서도 비슷하게 '풀스택 자율 에이전트보다, 잘 설계된 워크플로우가 대부분의 경우엔 더 낫다'고 강조하거든요. LangGraph나 DSPy 같은 프레임워크들도 결국 '자유분방한 에이전트'를 어떻게 길들여서 예측 가능하게 만들 것이냐에 초점을 맞추고 있고요. eval 쪽도 Braintrust, LangSmith, promptfoo 같은 도구들이 우후죽순 나오는 중이에요.

한마디로 업계 분위기가 '더 똑똑한 모델'에서 '더 믿을 수 있는 시스템'으로 옮겨가는 변곡점에 있어요. 모델 성능은 어느 정도 상향 평준화됐으니, 이제 승부처는 그 모델을 감싸는 엔지니어링이라는 거죠.

한국 개발자에게 주는 시사점

실무에 바로 적용할 포인트는 명확해요. 프롬프트 만지기 전에 eval부터 만드세요. 우리나라 팀들이 LLM 도입할 때 가장 흔히 하는 실수가, 채점 기준 없이 프롬프트만 며칠씩 붙들고 있는 거예요. '이렇게 바꾸니까 좀 나아진 것 같은데?' 하는 느낌만으로요. 정답 케이스 30개만 정리해서 자동 채점 스크립트를 짜두면, 그 다음부터는 개선이 데이터로 보이기 시작해요.

또 하나, '풀 자율 에이전트'에 너무 욕심내지 마세요. 사이드 프로젝트나 사내 도구라면 더더욱, AI가 판단하는 구간을 한두 개로 좁히고 나머지는 평범한 코드로 고정하는 게 훨씬 안정적이에요. 이건 영어를 잘하든 못하든, 모델이 GPT든 클로드든 상관없이 통하는 설계 원칙이라 배워둘 가치가 충분해요.

마무리

결국 신뢰성 있는 에이전트의 비결은 '더 좋은 프롬프트'가 아니라 '평가·가드레일·사람 개입으로 비결정성을 길들이는 엔지니어링'이에요. 여러분은 LLM 기능을 붙일 때 eval(자동 채점)을 먼저 만드는 편인가요, 아니면 일단 프롬프트부터 돌려보는 편인가요? 자율 에이전트와 고정 워크플로우 사이에서 어디까지 AI에게 맡기는 게 적당하다고 보시나요?