AI가 만들어줬는데, 이대로 써도 될까? | 에이전틱 AI 결과 검증

AI에게 익숙하지 않은 일을 맡겨 보신 적 있으세요?

보고서를 부탁하면 보고서가 나옵니다. 기획안을 부탁하면 제목과 목차, 표까지 갖춘 문서가 나옵니다. 처음 받아 보면 놀라실 거예요. 생각보다 훨씬 그럴듯하거든요.

그런데 막상 그 문서를 고객에게 보내거나 업무에 쓰려고 하면, 손이 잠깐 멈춥니다.

“이제 된 건가?”

문장은 자연스럽고 모양도 갖춰져 있습니다. 그런데 중요한 내용이 빠진 건 아닌지 잘 모르겠습니다. 숫자는 맞는지, 근거가 정말 있는지, 그 분야를 잘 아는 분이 보면 바로 보이는 실수가 있는 건 아닌지 신경이 쓰입니다.

AI가 일을 못 한 걸까요? 아닙니다. 오히려 너무 그럴듯하게 해냈습니다. 어려운 점은 따로 있습니다. 내가 그 일을 잘 모르니, 어디까지 와야 끝난 건지 판단하기 어렵다는 것입니다.

그래서 답부터 말씀드리겠습니다.

AI가 결과를 만들었는데도 왜 불안할까?

늘 하던 일이라면 AI의 실수가 금방 눈에 들어옵니다.

매일 쓰시는 견적서를 떠올려 보세요. 빠진 항목, 이상한 계산, 고객에게 쓰면 안 되는 표현. 이런 것은 보자마자 아십니다. 머릿속에 ‘제대로 된 견적서’의 모습이 이미 있으니까요. AI가 만든 결과를 그 경험과 비교해 보면 됩니다.

처음 해보는 일은 다릅니다. 겉모습은 보이는데, 그 안의 빈칸은 잘 보이지 않습니다.

• 무엇이 꼭 들어가야 할까?
• 어떤 순서로 처리해야 할까?
• 어떤 숫자와 문서를 원본에서 다시 봐야 할까?
• 어떤 예외가 자주 생길까?
• 마지막 책임은 누가 질까?

이 질문에 답하기 어렵다면, 문서가 매끄럽다는 것만으로는 완성됐다고 말하기 어렵습니다. 자신 있게 쓴 문장과 확인된 문장은 같은 것이 아니니까요.

흔히 말하는 ‘AI 환각’도 여기서 문제가 됩니다. AI는 없는 자료나 틀린 내용을 사실처럼 말할 때가 있습니다. 그래서 중요한 주장과 숫자는 원문에서 다시 확인해야 합니다.

하지만 환각만 잡으면 일이 끝날까요? 그렇지는 않습니다. 모든 사실이 맞아도 고객이 원하는 내용이 빠졌거나 현장에서 쓸 수 없다면, 좋은 결과라고 하기 어렵습니다.

코딩에서는 왜 AI와 계속 고쳐 갈 수 있을까?

이 점을 이해하기 좋은 예가 코딩입니다.

핵심은 디버거라는 프로그램이 있다는 데 있지 않습니다. 코딩에는 만든 결과를 확인하고, 문제가 있으면 다시 고치는 과정이 일 안에 들어 있습니다.

대부분의 개발 환경은 실행 오류, 로그, 테스트 결과, 디버깅 도구처럼 코드 상태를 알려주는 기술적인 신호를 보여줍니다. 다만 모든 코딩 도구에 디버거가 있는 것은 아니고, 업무와 환경에 따라 쓸 수 있는 확인 수단은 달라집니다.

기술적인 신호만 있는 것도 아닙니다. 화면이 제대로 나오는지, 버튼을 누르면 약속한 대로 움직이는지, 값을 넣으면 기대한 결과가 나오는지처럼 눈으로 볼 수 있는 결과와 동작도 있습니다.

그래서 코딩 결과는 보통 두 가지 길로 확인할 수 있습니다.

1. 기술적인 확인 신호 — 실행 오류, 로그, 테스트, 디버깅 도구로 문제를 찾습니다.
2. 눈에 보이는 결과와 동작 — 화면, 버튼 동작, 입력과 출력이 기대한 대로 되는지 봅니다.

전문가는 여기에 더해 코드의 구조, 설계, 읽기 쉬운지, 나중에 고치기 쉬운지까지 판단할 수 있습니다. 전문가가 아니어도 코드 전체를 이해하지 못한 채 이 두 가지 길로 일부 실패는 찾아낼 수 있습니다.

1. AI가 코드를 만듭니다.
2. 기술적인 신호와 실제 동작을 확인합니다.
3. 기대한 결과와 실제 결과를 비교합니다.
4. 안 되는 부분을 찾습니다.
5. 고친 뒤 다시 실행합니다.

이렇게 확인하고 고치는 흐름이 비교적 분명하기 때문에, 코딩은 익숙하지 않은 분도 AI와 주고받으며 일하기에 상대적으로 유리한 업무라고 볼 수 있습니다.

Anthropic이 AI 에이전트 평가에 대해 쓴 글에서도 비슷한 이야기를 합니다. 코딩 과제는 해야 할 일을 비교적 분명하게 정하고 테스트 환경을 만들기 쉽다고 합니다. 그리고 AI가 무언가를 ‘했다’는 것과 그 결과가 ‘맞다’는 것은 따로 봐야 한다고 설명합니다.

그렇다고 "코딩은 AI에게만 맡겨도 완전히 안전하다"는 뜻은 아닙니다.
저의 현장 경험상으로는 결과를 다시 확인할 방법이 있으면, 사람과 AI가 주고받으며 결과를 다듬기 쉬워진다는 이야기입니다.

이것은 코딩 분야에서 AI 활용이 늘어난 원인을 증명한 것도, 코딩이 AI 활용 1위 분야라는 뜻도 아닙니다.

또 테스트를 통과했거나 화면이 잘 움직인다고 해서 결과가 완전해지는 것은 아닙니다. 보안, 나중에 고치기 쉬운지, 빠진 요구사항, 사용하는 분의 경험, 사업적인 가치까지 저절로 보장되지는 않습니다.

테스트를 통과하면 정말 좋은 결과일까?

여기서 한 가지는 꼭 짚고 가겠습니다.

테스트는 우리가 확인하도록 정해 둔 조건만 확인합니다. 테스트에 넣지 않은 고객의 요구, 예상하지 못한 예외, 보안 문제, 나중에 고치기 어려운 구조, 실제 사용하는 분의 불편까지 알아서 잡아 주지는 않습니다.

프로그램이 실행되는 것과 좋은 서비스인 것은 다릅니다. 숫자의 출처가 맞는 것과 좋은 보고서인 것도 다릅니다.

그래서 AI가 만든 결과를 볼 때는 질문을 두 가지로 나눠 보시면 좋습니다.

1. 틀린 것은 없을까? — 사실, 숫자, 인용, 계산, 출처를 확인합니다.
2. 필요한 결과가 되었을까? — 목적, 요구사항, 빠진 내용, 실제로 쓸 수 있는지, 책임 범위를 확인합니다.

AI 팩트체크는 첫 번째 질문에 가깝습니다. 일이 정말 끝났는지 알려면 두 번째 질문까지 확인해야 합니다.

보고서나 기획안에도 확인 과정을 만들 수 있을까?

네, 만들 수 있습니다. 코드처럼 실행 버튼이 없는 업무도 확인 과정을 만들 수 있습니다. 거창한 시스템은 필요 없습니다. 아래 다섯 가지를 먼저 적어 보시는 것부터 시작하면 됩니다.

1. 끝난 상태를 먼저 적어 둡니다

AI에게 맡기기 전에 “무엇이 나오면 끝인가”를 한 문장으로 적어 보세요.

“일본 시장 조사 보고서 작성”보다는 이렇게 구체적으로 적는 것이 좋습니다.

일본 진출 여부를 판단할 수 있도록 시장 규모의 원문, 주요 경쟁사, 규제상 확인할 사항, 아직 확인되지 않은 항목을 구분한 보고서를 만든다.

이렇게 정해 두면 문서가 길거나 표가 보기 좋다는 이유로 끝났다고 착각하지 않게 됩니다. 판단에 필요한 재료가 갖춰졌는지를 보게 됩니다.

2. 사실과 판단을 나눕니다

날짜, 수치, 법령, 회사 이름처럼 확인할 수 있는 사실과, 전망이나 추천 같은 판단을 나눠 보세요.

사실에는 출처가 필요합니다. 추천에는 어떤 전제에서 그렇게 판단했는지가 필요합니다. 개인의 경험이나 의견을 연구 결과처럼 쓰지 않고, 조사 자료의 주장을 회사가 확정한 판단처럼 바꾸지 않는 것도 중요합니다.

3. 출처와 숫자는 다른 경로로 확인합니다

AI가 알려준 링크를 그대로 믿지 마시고, 원문을 직접 열어 보세요. 그 자료가 정말 있는지, 그 문장이 실제로 적혀 있는지, 조사 시점과 대상이 지금 업무에 맞는지 확인합니다.

같은 AI에게 “다시 확인해 줘”라고 묻는 것도 도움은 됩니다. 다만 그것은 독립적인 확인이 아닙니다. 중요한 정보는 공식 문서, 원자료, 직접 해 본 계산처럼 다른 경로로 확인하시는 것이 안전합니다.

4. 빠진 요구사항과 예외를 확인합니다

맞는 문장만 모아 놓는다고 좋은 결과가 되지는 않습니다.

처음 요청한 내용이 모두 들어갔는지, 고객이 실제로 쓸 수 있는 형태인지, 반대 사례나 적용되지 않는 조건이 빠지지 않았는지 확인해 보세요. 가능하다면 예전에 잘 만든 결과물이나 체크리스트를 옆에 두고 비교해 보시면 좋습니다.

5. 판단할 수 없는 부분은 표시해 둡니다

모르는 부분을 억지로 통과시키지 않으셔도 됩니다.

확인 완료, 조건부 사용, 미확인, 전문가 확인 필요처럼 상태를 나눠 두면, 어디까지 써도 되는지가 보입니다. 판단하지 못한 부분을 숨기지 않고 적어 두는 것도 결과물의 일부입니다.

어디까지 직접 확인하고 언제 전문가에게 물어야 할까?

모든 일을 같은 깊이로 확인할 필요는 없습니다.

아이디어를 넓히기 위한 초안이라면 가볍게 검토해도 괜찮습니다. 하지만 법률, 세무, 의료, 계약, 안전, 큰 금액이 걸린 결정처럼 틀렸을 때 영향이 큰 일은 해당 분야 전문가의 확인을 받으시는 것이 좋습니다.

이때 기준은 “AI가 얼마나 자신 있게 말했는가”가 아닙니다. 아래 질문을 확인해 보세요.

• 틀렸을 때 손해가 큰가?
• 외부에 제출하거나 실제 행동에 쓸 것인가?
• 내가 틀린 곳과 빠진 곳을 찾아낼 수 있는가?
• 따로 확인할 원문, 계산, 테스트가 있는가?
• 최종 책임을 질 사람이 확인했는가?

답하기 어려운 질문이 있다면 범위를 줄여 보세요. 일 전체를 한 번에 맡기기보다, 확인할 수 있는 작은 단위에서 먼저 시험해 보는 것입니다.

이와 관련해 참고할 만한 연구가 있습니다. Anthropic이 Claude Code 사용 기록을 분석했더니, 사람이 주로 맡은 것은 무엇을 할지, 어떤 방법을 쓸지, 무엇을 완료로 볼지 같은 ‘계획 단계의 결정’이었습니다. 이와 별도로, 해당 업무를 잘 아는 사용자일수록 테스트 통과처럼 확인 가능한 성공 신호가 더 많이 관찰됐습니다. 이 결과는 AI에게 일을 맡기기 전에 완료 기준과 확인 방법을 정해 둘 필요성을 생각해 보는 참고 사례로 볼 수 있습니다.

체감과 실제 측정 결과가 다를 수 있다는 연구도 있습니다. METR의 2025년 연구에서는 숙련된 오픈소스 개발자 16명이 246개 과제를 수행했는데, AI를 사용했을 때 완료 시간이 오히려 19% 늘었습니다. 물론 특정 참가자와 과제에 한정된 결과라서 모든 개발자나 업무에 그대로 적용할 수는 없습니다. 2026년 후속 연구에서는 최신 도구로 빨라질 가능성이 보였지만, AI 없이 일하기를 꺼리는 참가자와 과제가 빠지는 선택 편향과 모집 문제 때문에 효과의 크기는 신뢰하기 어렵다고 밝혔습니다.

그래서 이 사례에서 드리고 싶은 말씀은, 사람이 혼자 할 때와 AI와 함께 할 때를 같은 완료 기준, 같은 품질, 같은 기간으로 비교해 봐야 한다는 것입니다.

오늘 무엇부터 시작하면 될까?

AI에게 맡기려는 일 하나를 골라, 두 문장을 적어 보세요.

그리고 한 문장을 더 적어 보세요.

AI를 잘 쓴다는 것은 프롬프트를 길게 쓰는 것만이 아닙니다. AI가 만든 결과를 어디까지 믿고, 무엇을 다시 확인하고, 언제 사람에게 넘길지를 정하는 일입니다.

그럴듯해 보이는 결과와 실제로 쓸 수 있는 결과 사이에는 확인하는 과정이 있습니다. 그 과정을 업무 안에 만들어 두면, AI는 문서를 대신 만들어 주는 도구에서 일을 함께 끝내는 도구에 조금 더 가까워집니다.