AI를 업무에 활용하다 보면 생각보다 당황스러운 순간을 만나게 됩니다.
AI가 너무 자연스럽게 설명하고 있어서 당연히 맞는 내용이라고 생각했는데, 다시 확인해보니 일부 내용이 틀려 있는 경우입니다.
문제는 단순한 오타가 아닙니다.
존재하지 않는 정보를 실제 정보처럼 설명하거나, 출처가 없는 내용을 사실처럼 이야기하거나, 서로 다른 정보를 그럴듯하게 조합해서 답변하는 경우도 있습니다.
실제로 자동화를 구축하면서 잘못된 안내를 그대로 믿으면 어떤 문제가 생기는지 경험한 적이 있습니다.
Make에서 AI를 활용한 자동화 시나리오를 만들면서 Web Search에서 얻은 여러 결과를 Iterator로 하나씩 처리한 다음, 그 데이터를 다음 단계로 전달하는 구조를 만들어본 적이 있습니다.
처음에는 제가 AI의 안내를 따라 별도로 Iterator를 만든 뒤 Web Search에서 나온 데이터를 연결하려고 했습니다.
그런데 실제 화면에서는 예상했던 방식으로 연결되지 않았습니다.
처음 안내받은 방법 자체가 Make의 실제 모듈 연결 방식과 맞지 않았던 것입니다.
이 과정에서 또 다른 잘못된 방법도 안내받았습니다.
우클릭 메뉴에서 연결할 수 있다는 안내를 받았지만 실제 화면에는 그런 연결 기능이 없었습니다.
결국 기존 방법을 그대로 따라가는 대신 실제 Make 화면을 다시 확인하고, Web Search 모듈에서 제공하는 연결 방식을 이용해 Add a module을 통해 Iterator를 추가하는 방식으로 수정했습니다.
그 결과 최종적으로
Web Search
→ Iterator
→ Add a Row
형태의 자동화 구조를 만들 수 있었습니다.
그런데 여기서 또 하나 중요한 문제가 발견됐습니다.
자동화가 정상적으로 만들어졌다고 해서 바로 전체 실행을 해서는 안 된다는 점입니다.
당시 실행 과정에서 AI Web Search 사용량과 관련된 경고가 표시됐고, 전체 데이터를 대상으로 Run once를 실행할 경우 약 25개의 AI Web Search 크레딧이 사용될 수 있는 상황이었습니다.
즉, 자동화 구조 자체를 만드는 것과 실제 데이터를 이용해 전체 실행하는 것은 별개의 문제였습니다.
이 경험을 통해 AI의 안내를 확인하는 방법을 조금 바꾸게 되었습니다.
처음에는
AI가 방법을 알려준다
→ 그대로 따라 한다
라고 생각했습니다.
하지만 실제 자동화를 만들면서는
AI가 방법을 제시한다
→ 실제 프로그램 화면에서 가능한지 확인한다
→ 작은 범위에서 테스트한다
→ 사용량과 비용을 확인한다
→ 문제가 없을 때 전체 실행한다
라는 순서가 훨씬 안전하다는 것을 알게 되었습니다.
특히 자동화 도구는 버전이나 화면 구성, 모듈의 연결 방식에 따라 실제 사용 방법이 달라질 수 있기 때문에 AI가 설명한 방법이 그럴듯하다는 이유만으로 바로 실행해서는 안 된다는 것도 경험했습니다.
이 사례에서 중요한 것은 AI가 한 번 틀렸다는 사실 자체가 아닙니다.
더 중요한 것은 잘못된 답변을 발견했을 때 어떻게 수정했느냐입니다.
실제 화면에서 결과를 확인하고,
잘못된 방법을 제거하고,
공식적인 연결 방식을 다시 확인하고,
작은 범위에서 테스트하고,
실행 전에 비용과 크레딧까지 확인하는 과정이 필요했습니다.
결국 AI를 업무 자동화에 사용할 때 가장 중요한 능력 중 하나는 AI의 답변을 무조건 믿는 것이 아니라, 실제 환경에서 그 답변이 맞는지 검증하는 것이라고 생각합니다.
이른바 AI 환각이라고 부르는 현상입니다.
AI를 처음 사용할 때는 이런 문제를 발견하면 “AI가 아직 완벽하지 않구나”라고 생각하고 넘어가기 쉽습니다.
하지만 AI를 업무 자동화에 연결하면 이야기가 달라집니다.
사람이 채팅창에서 잘못된 답변을 발견하는 것과, AI가 잘못된 정보를 자동으로 다음 작업에 전달하는 것은 위험도가 다르기 때문입니다.
예를 들어 AI가 잘못된 정보를 분류해서 다른 시스템에 저장하거나, 잘못된 내용을 바탕으로 문서를 작성하거나, 확인되지 않은 내용을 고객에게 전달한다면 단순한 답변 오류가 아니라 업무 오류가 될 수 있습니다.
그래서 AI 업무 자동화를 공부하면서 중요하다고 느낀 것이 있습니다.
AI가 절대 틀리지 않도록 만드는 것보다 AI가 틀렸을 때 발견할 수 있는 구조를 만드는 것이 현실적이라는 점입니다.
이번 글에서는 AI가 생성한 결과를 그대로 믿지 않고, 업무에 사용하기 전에 검증할 수 있는 5단계 구조를 정리해보겠습니다.
- AI가 틀릴 수 있다는 전제부터 가져야 한다
AI를 업무에 연결할 때 가장 먼저 바꿔야 하는 생각은 “AI가 답을 알고 있다”는 전제입니다.
AI는 상당히 자연스러운 문장을 만들 수 있습니다.
그래서 답변이 구체적이고 자신감 있게 작성되어 있으면 실제 사실처럼 느껴질 수 있습니다.
하지만 문장이 자연스럽다는 것과 내용이 사실이라는 것은 완전히 다른 문제입니다.
특히 날짜, 숫자, 제품 사양, 법률이나 정책, 가격, 인물 정보처럼 정확성이 중요한 내용은 별도의 확인 과정이 필요합니다.
따라서 AI 업무 자동화를 설계할 때는 처음부터 다음과 같은 구조로 생각하는 것이 좋습니다.
AI가 답변한다
→ 사람이 그대로 사용한다
보다는
AI가 답변한다
→ 결과를 검증한다
→ 문제가 없을 때 사용한다
라는 구조입니다.
이 작은 차이가 자동화 시스템의 신뢰성을 크게 바꿀 수 있습니다.
- 첫 번째 검증 방법은 ‘출처 확인’이다
가장 기본적인 방법은 AI에게 출처를 요구하는 것입니다.
예를 들어 AI에게 특정 정보를 조사하게 했다면 다음과 같이 요청할 수 있습니다.
“이 내용을 뒷받침하는 공식 출처를 함께 제시해줘.”
이렇게 하면 최소한 정보의 근거가 무엇인지 확인할 수 있습니다.
다만 여기서도 주의할 점이 있습니다.
AI가 출처처럼 보이는 내용을 만들어낼 가능성을 완전히 배제할 수는 없습니다.
따라서 출처가 표시되었다는 이유만으로 바로 신뢰해서는 안 됩니다.
실제 출처에 들어가서 해당 내용이 정말 존재하는지 확인해야 합니다.
예를 들어 AI가 어떤 공식 문서를 근거로 제시했다면
AI 답변
→ 출처 확인
→ 원문 확인
→ AI의 설명과 원문의 내용 비교
순서로 확인하는 것이 좋습니다.
특히 업무에 중요한 정보를 사용하는 경우에는 AI의 설명보다 원본 자료를 우선하는 습관이 필요합니다.
- 두 번째는 AI에게 ‘모르면 모른다고 말하게 하는 것’이다
AI를 사용할 때 흔히 발생하는 문제 중 하나는 정보가 부족한 상황에서도 답변을 만들어내려고 한다는 것입니다.
그래서 업무 자동화를 설계할 때는 무조건 답변하도록 만드는 것보다 불확실한 상황에서 멈출 수 있도록 만드는 것이 중요합니다.
예를 들어 다음과 같은 규칙을 추가할 수 있습니다.
“확실한 근거가 없는 경우 추측하지 말고 정보가 부족하다고 표시한다.”
또는
“제공된 자료에서 확인할 수 없는 내용은 사실처럼 작성하지 않는다.”
이렇게 하면 AI가 모든 질문에 반드시 답해야 한다는 부담을 줄일 수 있습니다.
결과적으로 답변이 조금 덜 완벽해 보이더라도 잘못된 정보를 자신 있게 만들어내는 상황을 줄이는 데 도움이 됩니다.
업무 자동화에서는 정답을 하나 더 만들어내는 것보다 잘못된 답변을 하나 차단하는 것이 더 중요할 때가 있습니다.
- 세 번째는 ‘원본 자료와 비교’하는 것이다
AI가 어떤 내용을 정리했다면 그 결과가 원본 자료와 일치하는지 확인할 수 있습니다.
예를 들어 10페이지짜리 문서를 AI에게 요약하도록 했다고 생각해보겠습니다.
AI가 다음과 같이 요약했습니다.
“이 문서에서는 A, B, C 세 가지 내용을 중요하게 설명하고 있습니다.”
이때 단순히 요약 결과만 보는 것이 아니라 원본 문서에서 실제로 A, B, C가 핵심 내용인지 확인하는 것입니다.
특히 숫자와 조건이 포함된 정보는 반드시 원본과 비교하는 것이 좋습니다.
예를 들어
원본:
“신청 기간은 9월 1일부터 9월 15일까지입니다.”
AI:
“신청 기간은 9월 1일부터 9월 20일까지입니다.”
문장 자체만 보면 AI의 답변도 상당히 자연스럽습니다.
하지만 실제 업무에서는 완전히 다른 결과를 만들 수 있습니다.
이런 이유로 AI가 정보를 요약하거나 변환하는 업무에서는 원본과 결과를 비교할 수 있는 구조가 중요합니다.
- 네 번째는 ‘검증 AI’를 별도로 사용하는 방법이다
조금 더 복잡한 자동화에서는 하나의 AI에게 모든 역할을 맡기지 않는 방법도 사용할 수 있습니다.
예를 들어
AI 1
→ 자료 조사 및 초안 작성
AI 2
→ 결과 검토
와 같은 구조입니다.
첫 번째 AI가 내용을 작성하면 두 번째 AI에게 다음과 같이 요청할 수 있습니다.
“아래 답변에서 사실관계가 의심되는 부분을 찾아줘.”
또는
“제시된 자료만 근거로 했을 때 확인되지 않는 주장을 찾아줘.”
이렇게 하면 첫 번째 AI가 만든 결과를 다른 관점에서 다시 확인할 수 있습니다.
다만 여기에도 한계는 있습니다.
검증 역할을 맡은 AI 역시 완벽하지 않기 때문입니다.
따라서 AI가 검증했다고 해서 무조건 사실이라고 판단하기보다는, 중요한 정보는 사람이 원본을 확인하는 구조가 더 안전합니다.
AI를 두 번 사용했다고 해서 자동으로 사실이 되는 것은 아닙니다.
- 다섯 번째는 최종 승인 단계를 만드는 것이다
AI 자동화에서 가장 현실적인 방법 중 하나는 중요한 업무에 사람의 승인을 넣는 것입니다.
예를 들어 다음과 같은 구조입니다.
자료 수집
↓
AI 분석
↓
AI 초안 작성
↓
검증
↓
사람 확인
↓
최종 실행
이 구조의 장점은 AI의 속도를 활용하면서도 마지막 책임 있는 판단은 사람이 할 수 있다는 것입니다.
특히 외부에 정보를 전달하거나 데이터를 변경하는 업무라면 더욱 중요합니다.
예를 들어 단순한 문서 초안 작성은 자동으로 처리해도 문제가 적을 수 있습니다.
하지만 고객에게 이메일을 발송하거나, 중요한 데이터를 삭제하거나, 계약이나 결제와 관련된 행동을 실행하는 경우에는 별도의 승인 절차를 두는 것이 더 안전합니다.
AI 에이전트는 여러 단계에서 도구를 호출하고 중간 결과를 바탕으로 다음 행동을 결정할 수 있기 때문에, 이런 시스템에서는 결과 자체뿐 아니라 행동 과정도 평가할 필요가 있습니다. Anthropic 역시 AI 에이전트는 여러 단계의 도구 사용과 상태 변경을 수행하기 때문에 평가가 더 어려워진다고 설명하고 있습니다.
- 실제 업무에서는 5단계를 하나의 흐름으로 만들 수 있다
앞에서 설명한 방법을 하나로 합치면 다음과 같은 구조가 됩니다.
1단계
AI가 자료를 수집한다.
2단계
AI가 내용을 분석하고 초안을 만든다.
3단계
출처와 원본 자료를 확인한다.
4단계
불확실하거나 오류가 의심되는 내용을 표시한다.
5단계
중요한 결과는 사람이 최종 승인한다.
이를 조금 더 간단하게 표현하면
AI 생성
→ 출처 확인
→ 원본 비교
→ 오류 탐지
→ 사람 승인
입니다.
이 구조를 모든 업무에 똑같이 적용할 필요는 없습니다.
단순한 작업이라면 검증 단계를 줄일 수도 있습니다.
반대로 잘못된 결과가 큰 피해로 이어질 수 있는 업무라면 검증 단계를 더 강화해야 합니다.
- AI의 정확도를 감으로 판단하지 않는 것도 중요하다
AI를 사용하다 보면 어느 순간 이런 생각이 들 수 있습니다.
“이번에는 잘했으니까 이제 믿어도 되겠지.”
하지만 몇 번의 성공만으로 AI의 신뢰성을 판단하는 것은 위험할 수 있습니다.
오히려 같은 종류의 업무를 여러 번 테스트하고 결과를 기록하는 것이 좋습니다.
예를 들어 20개의 테스트 자료를 준비한 다음
정확하게 처리한 개수
오류가 발생한 개수
사람이 수정한 개수
처리하지 못한 개수
를 기록할 수 있습니다.
예를 들어 20건 중 18건을 정확하게 처리했다면 단순히 “잘한다”고 평가하는 대신 90%의 테스트 성공률이라고 기록할 수 있습니다.
물론 이 숫자가 실제 업무에서의 정확도를 그대로 의미하는 것은 아닙니다.
테스트 데이터가 실제 업무를 얼마나 잘 대표하는지, 무엇을 정답으로 정의했는지에 따라 결과가 달라지기 때문입니다.
그래도 감으로 판단하는 것보다는 훨씬 나은 방법입니다.
AI 시스템의 성능을 평가할 때도 테스트 데이터와 명확한 평가 기준을 사용하는 방식이 활용됩니다. OpenAI의 Evals 역시 특정 업무에 대한 테스트 데이터와 평가 기준을 만들어 모델이나 AI 시스템의 결과를 평가하는 구조를 제공하고 있습니다.
- 오히려 실패한 결과가 더 중요한 자료가 될 수 있다
AI 자동화를 테스트하면서 좋은 결과만 기록하면 실제 성능을 제대로 알기 어렵습니다.
오류가 발생한 사례를 따로 모아보는 것이 중요합니다.
예를 들어
왜 AI가 틀렸는가?
자료가 부족했는가?
질문이 모호했는가?
원본 자료를 제대로 읽지 못했는가?
출처를 잘못 해석했는가?
사람이 확인했어야 했는가?
이런 질문을 통해 오류의 원인을 찾아볼 수 있습니다.
그리고 같은 오류가 반복되지 않도록 자동화 구조를 수정합니다.
예를 들어 자료가 부족해서 문제가 발생했다면 필요한 정보를 먼저 수집하도록 단계를 추가할 수 있습니다.
숫자 오류가 자주 발생한다면 원본 자료와 숫자를 비교하는 검증 단계를 추가할 수 있습니다.
사람이 판단해야 하는 문제가 자주 발생한다면 승인 단계를 추가할 수 있습니다.
이렇게 보면 AI의 실패는 단순한 문제가 아니라 자동화 시스템을 개선하기 위한 테스트 자료가 됩니다.
- 완벽한 AI보다 ‘틀렸을 때 멈추는 AI’가 더 중요할 수 있다
AI 자동화를 처음 공부할 때는 AI가 얼마나 똑똑한지가 가장 중요하다고 생각하기 쉽습니다.
하지만 실제 업무에서는 조금 다른 기준이 필요하다고 생각합니다.
AI가 얼마나 많은 일을 할 수 있는가?
도 중요하지만
AI가 자신이 확실하지 않은 상황을 얼마나 잘 구분하는가?
도 중요합니다.
특히 업무 자동화에서는 잘못된 결과를 빠르게 만드는 것보다 불확실한 상황에서 사람에게 넘기는 것이 더 좋은 경우가 많습니다.
예를 들어
확실함 → 자동 처리
불확실함 → 검토 요청
중요한 결정 → 사람 승인
이라는 구조를 만들 수 있습니다.
이렇게 하면 AI에게 모든 판단을 맡기지 않으면서도 자동화의 장점을 활용할 수 있습니다.
- 내가 생각하는 가장 현실적인 검증 기준
AI 업무 자동화를 시작한다면 저는 다음 다섯 가지 질문부터 확인하는 것이 좋다고 생각합니다.
첫째, 이 정보의 출처는 무엇인가?
둘째, 원본 자료에서도 실제로 확인되는 내용인가?
셋째, AI가 추측해서 만든 내용은 없는가?
넷째, 오류가 발생했을 때 사람이 발견할 수 있는가?
다섯째, 중요한 결과를 실행하기 전에 사람이 승인할 수 있는가?
이 다섯 가지 질문에 답할 수 있다면 AI 자동화를 훨씬 안정적으로 설계할 수 있습니다.
마무리
AI는 매우 빠르게 정보를 정리하고 문서를 만들고 여러 업무를 처리할 수 있습니다.
하지만 빠르게 처리한다는 것과 항상 정확하다는 것은 같은 의미가 아닙니다.
특히 AI 에이전트처럼 여러 도구를 연결하고 스스로 다음 작업을 결정하는 시스템에서는 AI의 결과뿐 아니라 중간 과정과 최종 행동까지 확인할 필요가 있습니다.
그래서 AI 업무 자동화를 만들 때는
AI가 틀리지 않게 만드는 것
만을 목표로 하기보다
AI가 틀렸을 때 발견할 수 있는 구조를 만드는 것이 현실적인 방법이라고 생각합니다.
제가 생각하는 가장 기본적인 구조는 다음과 같습니다.
AI 생성
→ 출처 확인
→ 원본 비교
→ 오류 및 불확실성 확인
→ 사람 승인
→ 최종 실행
물론 모든 업무에 이렇게 복잡한 검증 절차가 필요한 것은 아닙니다.
단순한 반복 업무라면 간단한 확인만으로 충분할 수 있습니다.
반대로 금전, 고객 정보, 계약, 외부 발송처럼 실수가 중요한 결과로 이어지는 업무라면 더욱 신중한 검증이 필요합니다.
결국 좋은 AI 자동화는 AI에게 최대한 많은 권한을 주는 시스템이 아니라, AI가 잘하는 일은 맡기면서 사람이 반드시 확인해야 하는 지점을 명확하게 만들어 놓은 시스템이라고 생각합니다.
그리고 AI를 업무에 사용하는 사람이라면 “AI가 얼마나 똑똑한가?”라는 질문만큼 “AI가 틀렸을 때 나는 그것을 어떻게 발견할 것인가?”라는 질문도 함께 생각해볼 필요가 있습니다.
참고 자료
Google Search Central, Creating helpful, reliable, people-first content
Google Search Central, Google Search’s guidance about AI-generated content
Anthropic, Demystifying evals for AI agents
OpenAI Evals, AI 시스템 평가 프레임워크
이 글은 위 자료의 내용을 단순히 번역하거나 요약하는 것이 아니라, AI 업무 자동화에 적용할 때 사용할 수 있는 검증 절차와 판단 기준을 중심으로 정리한 글입니다.