GitHub 레퍼런스를 활용한 에이전트 설계와 개선 방법5 : AI 에이전트의 결과물 검수 시간을 줄이는 설계 방법

AI 에이전트를 만들고 활용할수록, 결과를 생성하는 시간보다 검수하고 수정하는 시간이 더 오래 걸린다는 사실을 체감하게 됩니다. 특히 문장은 그럴듯하지만 사실이 틀리거나, 요구사항을 놓치거나, 최신 정보가 아닌 내용을 단정하는 오류는 치명적인 문제로 이어질 수 있습니다.

그래서 이번에는 “AI가 더 많은 결과물을 만들게 하는 방법”이 아니라, 사람이 더 적은 시간으로 안전하게 검수할 수 있도록 AI 에이전트를 설계하는 방법을 정리해 보았습니다. NIST는 생성형 AI가 그럴듯하지만 잘못된 내용을 만들어 내는 현상을 confabulation 위험으로 분류하며, 자동 평가·인간 감독·입력 자료 검토 등을 조합해 신뢰성을 관리할 필요가 있다고 설명합니다.

1. 시도하고자 했던 것과 그 이유

이번에 시도하고자 한 것은 AI 에이전트의 결과물을 단순히 “생성 후 사람이 전수 검토하는 방식”에서 벗어나, 생성–검수–수정–승인의 단계로 관리하는 것입니다.

초기에는 AI가 초안 작성 시간을 크게 줄여 주면 업무 효율도 자연스럽게 높아질 것이라고 생각했습니다. 하지만 실제로는 다음과 같은 문제가 반복되었습니다.

• AI가 존재하지 않거나 오래된 사실을 그럴듯하게 제시한다.

• 수치·날짜·기관명·정책·제품 기능을 확실한 사실처럼 단정한다.

• 요청의 형식은 따르지만, 핵심 목적이나 대상 독자를 놓친다.

• 긴 문서에서는 앞부분에서 정한 기준과 뒷부분의 내용이 충돌한다.

• 잘못된 문장 하나를 찾기 위해 문서 전체를 사람이 다시 읽어야 한다.

결국 문제는 AI의 생성 능력이 부족해서만이 아니라, AI 결과물을 어떻게 검수하고 통과시킬 것인지에 대한 설계가 없었다는 점에 있었습니다.

이 관점은 앞서 살펴본 프레임워크와도 연결됩니다.

• Superpowers는 작성 전에 계획하고, 작성 후 리뷰하는 절차를 강조합니다.

• GSD Core는 긴 작업에서 컨텍스트가 흐트러지는 문제를 명세와 단계별 검증으로 관리합니다.

• GBrain은 자료를 쌓는 것에 그치지 않고, 검색·정제·인용·재활용할 수 있는 지식 구조를 지향합니다.

• Gptaku Plugins는 사용자가 실제로 막히는 문제를 작은 단위의 플러그인으로 해결하도록 돕습니다.

따라서 이번 글의 목적은 비전공 초보 개발자가 “AI 결과를 믿어도 될까?”라는 불안에 머무르지 않고, 어디를 어떻게 확인해야 하는지 AI와 사람이 나눠 일하는 구조를 만드는 데 있습니다.

2. 진행 방법

1) 검수 기준부터 먼저 정의하기

가장 먼저 바꾼 것은 프롬프트가 아니라 검수 기준입니다.

“정확하게 작성해 주세요”, “오류가 없게 해 주세요”라는 지시는 너무 모호합니다. AI도 사람도 무엇을 확인해야 하는지 알 수 없습니다. 그래서 결과물을 만들기 전에 통과 기준을 먼저 정리했습니다.

교육 콘텐츠나 업무 문서에 적용할 수 있는 최소 기준은 다음과 같습니다.

처음부터 20개 기준을 만들 필요는 없습니다. 초보자라면 특히 치명적 오류를 막는 5~7개 기준부터 시작하는 것이 좋습니다.

2) 생성 결과에 ‘검수 메모’를 붙이기

검수 시간이 오래 걸리는 가장 큰 이유는 사람이 어디가 위험한지 모르는 상태에서 문서 전체를 읽기 때문입니다. 이를 줄이기 위해, 생성 에이전트가 결과물만 내는 것이 아니라 검수 메모도 함께 제출하도록 설계했습니다.

예를 들면 다음과 같습니다.

[검수 메모]

1. 사실 확인이 필요한 주장
- “해당 서비스는 2026년 현재 이 기능을 지원한다.”
- 확인 방법: 공식 제품 문서 또는 릴리즈 노트 확인

2. 출처가 필요한 수치
- “국내 대학의 다수가 활용하고 있다.”
- 조치: 공식 통계 또는 신뢰할 수 있는 조사 보고서 필요

3. 해석 또는 의견
- “초보자에게는 단계적 도입이 더 적합하다.”
- 주의: 보편적 사실이 아니라 작성자의 판단으로 표시

4. 불확실성
- 외부 서비스의 가격과 정책은 변경될 수 있음

이 방식의 핵심은 AI가 오류를 완벽히 잡아내는 데 있지 않습니다. 사람이 검수할 위치를 미리 표시하고, 우선순위를 정하도록 돕는 것에 있습니다.

3) 생성자와 검수자의 역할 분리하기

다음으로, 하나의 AI에게 작성과 검수를 모두 맡기는 방식에서 벗어나 역할을 분리했습니다.

이 구조는 생성 역할과 평가 역할을 분리해 반복 개선하는 Evaluator–Optimizer 패턴과 닿아 있습니다. Anthropic은 평가 기준이 명확하고, 피드백에 따라 결과를 반복적으로 개선할 가치가 있는 작업에 이 패턴을 활용할 수 있다고 제안합니다.

여기서 중요한 원칙은 검수 에이전트가 처음부터 글을 다시 쓰지 않게 하는 것입니다. 먼저 아래 세 가지에 집중하도록 해야 합니다.

• 무엇이 틀렸거나 확인되지 않았는가?

• 어떤 요구사항이 누락됐는가?

• 사람이 반드시 판단해야 하는 위험은 무엇인가?

4) 오류를 위험도에 따라 분류하기

모든 오류를 사람이 동일한 수준으로 검수하면 AI 활용의 이점이 사라집니다. 그래서 오류를 위험도별로 나누었습니다.

이 분류를 통해 사람은 치명적·중요 오류에 집중하고, AI는 형식·표현·구조를 우선 정리하도록 역할을 나눌 수 있습니다.

5) 오류 로그를 다음 개선의 재료로 만들기

마지막으로, 발견한 오류를 그때그때 고치고 끝내지 않고 오류 로그로 기록했습니다.

[AI 오류 로그]

작업: 교육용 블로그 초안 작성
오류 유형: 존재하지 않는 통계를 사실처럼 제시함
위험도: 치명적
원인: 수치와 기관명을 출처 없이 생성하도록 허용함
개선 규칙:
- 수치·날짜·기관명·정책은 공식 출처가 없으면
  사실로 단정하지 않는다.
- “확인 필요” 항목으로 분리한다.

재발 방지 테스트:
- 최신 통계, 제품 가격, 제도 변경을 묻는 질문 5개

이 로그가 쌓이면, 프롬프트를 감으로 수정하는 방식에서 벗어나 실제 실패 사례를 반영하는 에이전트 운영 매뉴얼을 만들 수 있습니다.

3. 결과와 배운 점

결과

이번 방식으로 정리하면서 얻은 가장 큰 변화는, AI 검수를 “사람이 마지막에 하는 귀찮은 일”이 아니라 에이전트 설계의 핵심 기능으로 보게 되었다는 점입니다.

좋은 AI 에이전트는 결과물을 많이 생성하는 에이전트가 아닙니다. 다음 질문에 답할 수 있는 에이전트입니다.

• 이 문서의 어떤 주장이 사실 확인이 필요한가?

• 이 결과에서 내가 놓친 요구사항은 무엇인가?

• 어떤 오류는 자동 수정해도 되고, 어떤 오류는 사람이 판단해야 하는가?

• 다음번에 같은 오류가 나오지 않으려면 무엇을 바꿔야 하는가?

NIST의 생성형 AI 위험 관리 관점에서도, 오류 가능성을 없다고 가정하기보다 위험을 식별하고, 측정하며, 관리하는 구조가 중요합니다.

배운 점과 나만의 꿀팁

첫째, 생성 프롬프트보다 검수 루브릭이 더 중요할 때가 많습니다.

처음에는 좋은 결과를 만들기 위해 생성 프롬프트를 계속 길게 만드는 데 집중했습니다. 그러나 결과가 복잡해질수록 “잘 작성해 달라”는 지시보다 “무엇을 통과로 볼 것인가”를 명확히 정하는 편이 훨씬 효과적이었습니다.

꿀팁: 생성 프롬프트와 검수 프롬프트를 분리하십시오.

• 생성 프롬프트: 무엇을 만들지, 누구에게 보여 줄지, 어떤 형식으로 쓸지

• 검수 프롬프트: 무엇이 틀렸는지, 무엇이 빠졌는지, 무엇을 사람이 확인해야 하는지

둘째, AI에게 확신이 아니라 불확실성을 표현하게 해야 합니다.

AI는 모르는 내용도 자연스럽고 단정적인 문장으로 만들어 낼 수 있습니다. 그래서 “정답을 말해 달라”는 요청만 하기보다, 아래 항목을 함께 출력하게 해야 합니다.

• 확인된 사실

• 확인이 필요한 주장

• 작성자의 해석 또는 의견

• 참고한 출처

• 답변의 한계

꿀팁: 최신성에 민감한 정보에는 다음 규칙을 넣으면 좋습니다.

수치, 날짜, 기관명, 제품 기능, 가격, 정책, 법령을 언급할 때는
출처와 기준일을 함께 제시하라.
출처를 확인할 수 없다면 사실처럼 단정하지 말고
“확인 필요”로 표시하라.

셋째, 사람은 ‘전수 검수자’가 아니라 ‘최종 책임자’여야 합니다.

AI가 만든 모든 문장을 사람이 다시 읽고 고치는 구조라면, AI는 초안 작성 도구에 머무릅니다. 사람은 AI가 판단하기 어려운 영역에 집중해야 합니다.

• 조직 맥락에 맞는가?

• 학습자에게 오해를 줄 표현은 없는가?

• 공식적으로 책임질 수 있는 내용인가?

• 배포해도 되는 수준인가?

반면 형식 통일, 문장 다듬기, 누락된 목차 찾기, 요구사항 대조 등은 AI의 1차 검수 영역으로 넘길 수 있습니다.

과정 중에 어떤 시행착오를 겪었나요?

첫 번째 시행착오는 “AI에게 다시 검토하라고 하면 오류가 사라질 것”이라고 생각한 점입니다. 실제로는 검수 기준이 없으면 AI도 무엇을 점검해야 하는지 알지 못합니다. “다시 확인해 주세요” 대신 “출처 없는 수치, 최신성 미확인 정보, 요구사항 누락, 논리 모순을 표로 정리해 주세요”처럼 구체화해야 했습니다.

두 번째 시행착오는 검수 기준을 너무 많이 만든 점입니다. 기준이 과도하면 검수 에이전트도 장황해지고, 사람도 보고서를 읽는 데 시간이 걸립니다. 따라서 초반에는 치명적 오류 중심의 최소 기준을 적용하고, 실제 오류가 반복될 때만 기준을 추가하는 방식이 효율적입니다.

세 번째 시행착오는 모든 결과물에 같은 수준의 검수를 적용한 점입니다. 맞춤법 수정, SNS 문구, 교육 콘텐츠, 정책 안내문은 위험도가 다릅니다. 특히 법률·의료·재무·개인정보·공식 정책처럼 고위험 영역은 자동 배포를 금지하고 사람의 최종 승인을 필수로 해야 합니다.

도움이 필요한 부분이 있나요?

앞으로 더 보완하고 싶은 부분은 다음과 같습니다.

• 교육자료, 강의안, 행정 문서, 컨설팅 보고서, 웹페이지별로 다른 검수 루브릭 템플릿

• 결과물의 위험도를 자동 분류하는 사전 필터

• 출처를 직접 확인하고, 인용 위치를 표시하는 근거 검증 워크플로우

• 오류 로그를 축적해 반복 실수를 줄이는 에이전트 품질 대시보드

• 비전공자가 쉽게 활용할 수 있는 생성–검수–승인 프롬프트 세트

특히 실제 워크숍에서는 참가자가 자기 업무에서 자주 쓰는 문서 하나를 정한 뒤, 그 문서의 치명적 오류 세 가지를 먼저 정의하는 활동이 필요하다고 생각합니다.

앞으로의 계획이 있다면 들려주세요.

다음 단계에서는 이번 내용을 바탕으로 ‘검수 가능한 LLM-wiki 에이전트’를 설계해 보고자 합니다.

첫 버전은 복잡한 멀티에이전트 시스템보다 아래 흐름을 목표로 합니다.

사용자 요청
→ 생성 에이전트의 초안 작성
→ 근거·불확실성·검수 메모 표시
→ 검수 에이전트의 통과·보완·반려 판정
→ 치명적·중요 항목만 사람 확인
→ 수정 또는 최종 배포

워크숍에서는 참가자가 다음 네 가지 산출물을 직접 만들 수 있도록 구성할 계획입니다.

1. 자신이 만들 에이전트의 결과물 정의

2. 결과물별 검수 루브릭 5개

3. 검수 전용 프롬프트

4. 실제 오류 사례를 기록하는 오류 로그

궁극적으로는 “AI가 만든 결과를 모두 믿지 말라”는 경고를 넘어서, 믿을 수 있도록 설계하고 검증하는 방법을 비전공자도 실습할 수 있게 돕고 싶습니다.

4. 도움 받은 글

1) NIST Generative AI Profile

• 요약: NIST의 생성형 AI 프로파일은 생성형 AI의 주요 위험 가운데 하나로 confabulation을 다루며, 알려진 정답과의 비교, 인간 감독, 자동 평가, 입력 자료 검토 등을 조합해 정확성·품질·신뢰성을 관리할 필요성을 제시합니다.

• 참고한 점: AI 오류를 “가끔 생기는 예외”가 아니라, 사전에 분류하고 관리해야 할 운영 위험으로 보는 관점을 얻었습니다.

• 링크: NIST AI 600-1: Generative AI Profile

2) Anthropic, Building Effective AI Agents

• 요약: AI 에이전트의 신뢰성을 높이는 워크플로우와 패턴을 다루며, 명확한 평가 기준과 반복 개선이 필요한 작업에서 생성 역할과 평가 역할을 분리하는 Evaluator–Optimizer 방식을 설명합니다.

• 참고한 점: 생성 에이전트와 검수 에이전트를 분리하고, 평가 결과를 다음 생성에 반영하는 구조를 설계하는 데 참고했습니다.

• 링크: Building Effective AI Agents Evaluator–Optimizer 워크플로우 자료

3) Superpowers 공식 README

• 요약: AI 코딩 에이전트가 브레인스토밍, 설계, 계획, 테스트 주도 개발, 코드 리뷰, 작업 마무리의 체계적 워크플로우를 따르도록 돕는 스킬 프레임워크입니다.

• 참고한 점: 결과물을 생성한 뒤 반드시 리뷰와 검증 단계를 두어야 한다는 절차 중심의 관점을 참고했습니다.

• 링크: Superpowers GitHub

4) GSD Core 공식 문서

• 요약: GSD Core는 컨텍스트 엔지니어링과 명세 기반 개발 프레임워크로, 긴 AI 작업에서 컨텍스트 품질이 저하되는 문제를 다루며 논의·계획·실행·검증의 단계 루프를 제공합니다.

• 참고한 점: 검수 결과와 현재 작업 상태를 별도 문서로 남기고, 단계별로 통과 여부를 관리하는 구조를 설계하는 데 활용했습니다.

• 링크: GSD Core GitHub GSD Core 문서