테스트와 개선: 내 AI 비서를 실전에 맞게 다듬기

AI 비서를 처음 만들면 대개 두 가지 착각에 빠지기 쉽습니다. 하나는 "오, 거의 다 됐다"는 착각이고, 다른 하나는 "왜 방금 저런 소리를 했지?"라는 당황입니다. 둘 다 정상입니다. AI 비서는 한 번에 완성되는 제품이 아니라, 실전에서 조금씩 조율되는 동료에 가깝습니다. 좋은 프롬프트와 도구 연결이 출발점이라면, 테스트와 개선은 그 비서가 진짜 일을 하게 만드는 훈련 과정입니다.¹²

사람 신입사원도 첫날부터 회사 스타일을 완벽히 알지 못합니다. 회의 메모는 요점을 놓치고, 보고서는 길어지고, 일정 잡기는 어설픕니다. 대신 몇 번 함께 일하면서 감을 익힙니다. AI 비서도 똑같습니다. 차이는 하나입니다. 사람은 실수한 이유를 대충 표정으로 보여주지만, AI는 멀쩡한 얼굴로 틀린 답을 내놓는다는 점입니다. 그래서 더더욱 테스트가 필요합니다.

이번 장의 목표는 분명합니다. 실제 업무 시나리오로 반복 테스트하면서 실패 사례를 모으고, 그 실패를 바탕으로 프롬프트와 자료 연결, 도구 흐름, 예외 처리 규칙을 다듬는 것입니다. 핵심은 "AI가 왜 자꾸 틀리지?"를 한탄하는 데서 멈추지 않고, "그 틀림을 다음 버전의 설계 재료로 바꾸자"로 넘어가는 데 있습니다.

AI 비서는 완성품이 아니라 수습 기간 중인 동료다

AI를 테스트할 때 가장 먼저 버려야 할 생각은 "정답 한 번만 나오면 성공"이라는 기대입니다. 언어모델은 확률적으로 움직이기 때문에, 같은 요청도 상황과 맥락에 따라 조금씩 다른 결과를 낼 수 있습니다. 그래서 한 번 잘 됐다는 사실은 품질 보증이 아니라, 그냥 한 번 잘 된 것입니다.¹

반대로 한 번 실패했다고 해서 설계 전체가 망한 것도 아닙니다. 중요한 것은 실패를 분류하는 태도입니다. 프롬프트가 모호했는지, 자료가 부족했는지, 연결된 도구가 잘못된 값을 넘겼는지, 예외 상황을 가정하지 않았는지 구분해야 합니다. 성급하게 "모델이 별로네"라고 결론 내리면, 정작 고칠 수 있는 부분을 놓치게 됩니다.

이 장에서 여러분은 AI 비서를 심판하는 사람이 아니라, 코치가 되어야 합니다. 코치는 한 번 실수한 선수에게 "너는 안 돼"라고 하지 않습니다. 어떤 상황에서 흔들렸는지 보고, 동작을 다시 쪼개고, 훈련 순서를 바꿉니다. AI 비서도 그렇게 다뤄야 합니다.

무엇을 테스트해야 할까

많은 초보자가 테스트를 "질문 몇 개 던져보기" 정도로 생각합니다. 하지만 실전 테스트는 더 구체적이어야 합니다. AI 비서가 하는 일은 보통 다섯 층으로 나뉩니다. 첫째, 요청을 제대로 이해하는가. 둘째, 필요한 자료를 적절히 끌어오는가. 셋째, 결과를 원하는 형식으로 내놓는가. 넷째, 외부 도구를 쓴다면 안전하고 정확하게 행동하는가. 다섯째, 애매한 상황에서 멈추거나 질문하는가.

아래 표처럼 보면 훨씬 선명해집니다.

여기서 중요한 포인트가 있습니다. 테스트는 "잘하는가"만 보는 일이 아닙니다. "어디서 무너지는가"를 보는 일입니다. 특히 AI 에이전트는 겉보기에는 성공처럼 보여도 내용이 틀릴 수 있습니다. API 호출은 멀쩡히 끝났는데, 정작 잘못된 수신자에게 메일을 준비하거나 엉뚱한 회의 문서를 끌어올 수도 있습니다. 이런 종류의 실패는 기술적으로는 성공, 업무적으로는 실패입니다.

좋은 테스트는 질문이 아니라 시나리오다

실전에서 쓸 비서라면, 테스트도 실전처럼 해야 합니다. "회의 요약해줘" 같은 짧은 문장 하나로는 부족합니다. 어떤 회의인지, 자료가 얼마나 지저분한지, 결정사항이 모호한지, 후속 작업이 많은지 같은 현실의 잡음을 함께 넣어야 합니다. 테스트의 품질은 시나리오의 현실감에서 나옵니다.

가장 쉬운 방법은 시나리오를 세 종류로 나누는 것입니다.

• 기본 시나리오: 평범한 요청입니다. AI가 정상 흐름을 수행하는지 봅니다.

• 경계 시나리오: 애매하거나 복잡한 요청입니다. 누락, 중복, 긴 입력, 상충하는 조건을 넣어 봅니다.

• 실패 시나리오: 자료 부족, 잘못된 형식, 연결 오류, 금지된 요청처럼 일부러 흔들리는 상황을 만듭니다.

예를 들어 여러분이 만든 AI 동료가 "회의 후속정리 비서"라고 해봅시다. 기본 시나리오는 이렇습니다. 회의록을 주고, 결정사항 3개와 담당자 2명을 추려 달라고 요청합니다. 여기서는 형식과 요약 품질을 봅니다.

경계 시나리오는 조금 더 짓궂습니다. 회의록 안에 잡담이 많고, 담당자가 이름 대신 "제가 할게요"처럼 모호하게 말한 부분이 섞여 있습니다. 일정은 나오지만 마감일은 불명확합니다. 여기서는 AI가 확실한 사실과 추정 내용을 구분하는지 봅니다.

실패 시나리오는 더 현실적입니다. 회의록 파일이 비어 있거나, 이전 회의 자료와 현재 회의 자료가 섞여 있거나, 담당자 이름이 서로 다르게 표기되어 있습니다. 이때 AI가 억지로 그럴듯한 정리를 만드는지, 아니면 "자료가 부족하다"고 말하며 확인을 요청하는지가 중요합니다.

좋은 비서는 모를 때 질문합니다. 나쁜 비서는 모를 때 자신감이 넘칩니다.

실패 로그가 쌓여야 진짜 개선이 시작된다

테스트를 몇 번 해보고 감으로 고치기 시작하면 금방 길을 잃습니다. 어제는 말투를 고쳤고, 오늘은 도구 연결을 바꿨고, 내일은 기억 규칙을 손보았는데 왜 좋아졌는지 알 수 없게 됩니다. 그래서 실패를 기록해야 합니다. 문서화는 귀찮아 보여도, AI 비서를 키우는 데 가장 값싼 보험입니다.

기록은 거창할 필요가 없습니다. 스프레드시트 하나면 충분합니다. 다만 항목은 분명해야 합니다.

여기서 핵심은 "AI가 이상했다"라고 적지 않는 것입니다. 그건 감상문이지 로그가 아닙니다. 대신 "요약에서 담당자 항목이 반복 누락됨", "메일 초안은 적절했으나 첨부 파일 이름을 잘못 참조함", "자료 부족 상황에서도 확인 질문 없이 단정적으로 답함"처럼 관찰 가능한 문장으로 적어야 합니다.

로그가 중요한 이유는 또 있습니다. 나중에 비서가 이상하게 행동했을 때, 그 문제를 재현할 수 있게 해 줍니다. 운영 단계에서는 어떤 요청이 들어왔고, 어떤 자료를 참고했고, 어떤 도구를 호출했고, 어디서 실패했는지 남겨야 합니다. 그래야 "왜 이 버전에서 갑자기 성능이 떨어졌지?"를 추리 소설처럼 풀지 않아도 됩니다.

실패를 고치는 순서는 따로 있다

AI 비서가 틀리면 많은 사람이 곧바로 프롬프트를 길게 늘입니다. 물론 프롬프트는 중요합니다. 하지만 모든 문제를 프롬프트로 해결하려 들면 지시문만 비대해지고, 진짜 원인은 그대로 남습니다. 개선은 보통 아래 순서로 보는 편이 효율적입니다.

첫째는 입력과 목표가 분명한가입니다. 지시가 뭉뚱그려져 있으면 AI도 흔들립니다. "요약해줘"보다 "결정사항, 담당자, 마감일, 보류 이슈를 구분해 6줄 이내로 정리해줘"가 훨씬 안정적입니다. 테스트 결과가 들쑥날쑥하다면, 먼저 과업 정의와 출력 형식을 더 선명하게 만들어야 합니다.

둘째는 맥락이 깨끗한가입니다. AI가 참고하는 자료가 많다고 무조건 좋아지지 않습니다. 오래된 규칙 문서, 중복 파일, 다른 프로젝트 자료가 섞여 있으면 오히려 헷갈립니다. 답이 자꾸 옆길로 새면 프롬프트보다 먼저 자료 범위를 줄여야 할 때가 많습니다. "무엇을 추가할까?"보다 "무엇을 빼야 할까?"가 더 중요한 순간이 있습니다.

셋째는 도구 연결이 정확한가입니다. 캘린더 생성, 메일 초안, 태그 분류 같은 자동화는 AI의 말보다 데이터 필드가 더 중요합니다. 제목과 날짜 필드가 뒤바뀌었거나, 수신자 확인 단계가 빠져 있거나, 빈 값 처리 규칙이 없으면 AI가 아무리 말을 잘해도 실제 업무는 망가집니다. 이때는 프롬프트 수정보다 워크플로 분기와 입력 검증이 먼저입니다.

넷째는 예외 상황에서 멈추는가입니다. 좋은 비서는 막힐 때 질문하거나 중단합니다. 나쁜 비서는 모르는 상태로 끝까지 달립니다. 따라서 자료 부족, 형식 오류, 시간 초과, API 실패, 잘못된 값 같은 상황에서 어떻게 반응할지 별도 규칙이 필요합니다. 실전 에이전트는 재시도, 대체 경로, 출력 검증, 사람에게 넘기기 같은 회복 전략을 함께 가져야 훨씬 안정적입니다.

아래 표는 자주 나오는 실패와 우선 고칠 자리를 묶어 놓은 것입니다.

한 번에 다 고치지 말고, 한 번에 하나만 바꿔라

이건 생각보다 중요합니다. 테스트 후 흥분해서 프롬프트도 바꾸고, 문서도 갈아끼우고, 도구 연결도 손보고, 모델도 바꾸면 결과가 좋아져도 왜 좋아졌는지 알 수 없습니다. 반대로 나빠져도 원인을 못 찾습니다.

그래서 개선은 작은 실험이어야 합니다. 예를 들어 오늘은 출력 형식만 바꿉니다. 내일은 회의록 자료 범위만 줄입니다. 그다음에는 일정 생성 전에 날짜 검증 규칙만 추가합니다. 이렇게 해야 어떤 변경이 실제 효과를 냈는지 보입니다.¹

이 방식은 참가자 워크숍에도 잘 맞습니다. 각자 만든 AI 역할이 달라도, 개선 단위는 작을수록 좋습니다. "이번 라운드에서는 말투가 아니라 누락 방지에만 집중하자." "이번에는 정확도보다 예외 처리만 보자." 이런 식으로 목표를 좁히면 훨씬 빨리 좋아집니다.

프롬프트도 버전 관리해야 한다

프롬프트는 그냥 대화창에 넣는 문장이 아니라, 업무 규칙이 담긴 설계 자산입니다. 그래서 버전을 붙여 관리하는 습관이 필요합니다. v1은 초안, v1.1은 출력 형식 보강, v1.2는 예외 처리 추가, v1.3은 승인 문구 개선처럼 이름을 붙여 두면 나중에 돌아가기 쉽습니다.

특히 중요한 것은 같은 테스트 세트로 다시 돌려보는 것입니다. 새로운 프롬프트가 지금 문제를 해결했다고 해서, 예전의 잘 되던 기능까지 유지된다는 보장은 없습니다. 이걸 확인하는 과정이 회귀 테스트입니다. 소프트웨어에서 기능이 깨졌는지 다시 확인하듯, AI 비서도 기존 시나리오를 반복 점검해야 합니다.²

초보자라면 어렵게 생각할 필요 없습니다. 아래처럼만 해도 충분합니다.

• 자주 쓰는 테스트 시나리오 10개를 고정한다.

• 프롬프트 버전을 바꿀 때마다 같은 10개를 다시 돌린다.

• 통과, 실패, 애매함을 표시한다.

• 좋아진 것과 나빠진 것을 나란히 비교한다.

이렇게 하면 감으로 "이번 버전이 더 좋은 것 같은데?"라고 말하지 않게 됩니다. 실제로 어떤 부분이 나아졌고, 어떤 부분이 후퇴했는지 보이기 시작합니다.

도구를 써보고 싶은 사람은 promptfoo 같은 평가 도구를 참고해도 좋습니다. 프롬프트와 모델을 비교하고, 반복 평가와 회귀 테스트를 도와주기 때문입니다.² 물론 이 책의 흐름에서는 이런 도구를 몰라도 됩니다. 중요한 것은 도구 이름보다 태도입니다. "프롬프트도 테스트 대상이다"라는 감각만 생겨도 절반은 성공입니다.

실패하는 방식까지 설계해야 한다

실전에서 정말 무서운 건 대놓고 터지는 실패보다, 조용히 틀리는 실패입니다. 멀쩡해 보이는 답을 냈지만 사실은 잘못된 고객명을 붙였거나, 완료했다고 했지만 실제로는 캘린더에 저장되지 않았거나, 비슷한 문서를 가져와서 그럴듯하게 요약한 경우가 그렇습니다.

그래서 AI 비서는 성공 조건뿐 아니라 실패 조건도 가져야 합니다. 예를 들어 이런 식입니다.

• 자료가 부족하면 추정하지 말고 확인 질문을 한다.

• 날짜나 금액이 모호하면 실행하지 않고 초안만 만든다.

• 도구 호출이 실패하면 1~2회만 재시도하고, 계속 실패하면 사람에게 넘긴다.

• 출력 형식이 깨지면 그대로 보내지 말고 다시 정리하거나 중단한다.

이건 8장에서 다룬 안전장치와 닿아 있지만, 여기서의 초점은 "막기"보다 "개선 가능하게 실패하기"입니다. 실패는 어차피 생깁니다. 중요한 것은 실패가 관찰 가능하고, 수정 가능하고, 다음 테스트의 재료가 되도록 만드는 것입니다.

노코드로도 충분히 할 수 있는 테스트 루프

코딩을 하지 않아도 테스트는 체계적으로 할 수 있습니다. 오히려 노코드 환경에서는 흐름이 눈에 보여서 수정 포인트를 찾기 쉽습니다. 추천하는 방식은 간단합니다.

먼저, 여러분 AI 비서가 실제로 맡을 업무 5개를 고릅니다. 그다음 각 업무마다 기본 시나리오 1개, 경계 시나리오 1개, 실패 시나리오 1개를 만듭니다. 그러면 금방 15개의 테스트 세트가 생깁니다.

그 후에는 다음 순서로 반복하면 됩니다.

이 루프를 두세 번만 돌아도 놀랍도록 많이 보입니다. 처음에는 "왜 이렇게 허술하지?" 싶었던 비서가, 어느 순간 특정 업무에서는 꽤 믿을 만한 동료처럼 느껴지기 시작합니다. 바로 그 순간이 중요합니다. AI 비서가 멋진 장난감에서 실무 도구로 넘어가는 순간이기 때문입니다.

데모데이 직전, 가장 좋은 테스트는 남이 해보는 것이다

혼자 만든 AI는 혼자 보면 다 괜찮아 보입니다. 내가 왜 이런 프롬프트를 썼는지 알고 있고, 어떤 파일을 넣었는지도 알고 있고, 어디가 약한지도 이미 감으로 메우고 있기 때문입니다. 하지만 데모데이는 다릅니다. 다른 사람이 써보면 친절하다고 믿었던 설명이 불친절하고, 당연하다고 생각했던 흐름이 낯설게 느껴집니다.

그래서 마지막 리허설에서는 꼭 다른 사람에게 써보게 해야 합니다. 가장 좋은 방법은 두 가지입니다. 하나는 "원래 의도한 방식대로 한번 써보세요"라고 부탁하는 것입니다. 다른 하나는 "일부러 망가뜨려 보세요"라고 부탁하는 것입니다. 두 번째가 특히 중요합니다. 사용자는 생각보다 창의적으로 시스템을 흔듭니다.

데모데이 전날에는 아래 세 가지만 확인하면 좋습니다.

• 이 비서가 무엇을 잘하는지 한 문장으로 설명할 수 있는가.

• 이 비서가 어디서 멈추는지 분명히 보여줄 수 있는가.

• 지난 테스트를 통해 어떻게 더 나아졌는지 전후 비교를 보여줄 수 있는가.

데모는 완벽함 자랑이 아닙니다. 튜닝의 흔적을 보여주는 자리입니다. "처음에는 회의록에서 담당자를 자꾸 헷갈렸는데, 역할 구분 규칙과 출력 형식을 고정한 뒤 정확도가 올라갔어요." 이런 설명이 훨씬 설득력 있습니다. AI 동료를 만들었다는 말은, 결국 함께 일하면서 다듬었다는 뜻이기 때문입니다.

내 AI 비서를 키우는 가장 현실적인 마음가짐

AI 비서는 한 번에 완성되지 않습니다. 이 사실을 빨리 받아들일수록 오히려 빨리 좋아집니다. 처음부터 완벽한 자동화를 꿈꾸기보다, 잘하는 일 하나를 만들고, 그 일을 반복 테스트하고, 실패를 수집하고, 그 실패를 설계로 되돌려 보내야 합니다.

처음에는 초안만 잘 쓰는 비서일 수 있습니다. 그다음에는 일정 정리까지 합니다. 그다음에는 자료가 부족할 때 스스로 질문하는 비서가 됩니다. 그렇게 조금씩 실전에 맞게 조율되면서, 여러분의 AI는 도구를 넘어 동료가 됩니다.

다음 장에서는 이렇게 다듬어진 AI 동료를 무대 위로 올릴 차례입니다. 각자 만든 비서를 직접 시연하고, 어디까지 확장할지 함께 상상해 봅시다. 데모데이는 평가의 끝이 아니라, 여러분 AI 동료의 첫 출근 날입니다.

참고

¹OpenAI Prompt Engineering Guide

²promptfoo: Test your prompts, agents, and RAGs