AI 에이전트 군단을 만들기 전에, ‘검사관’부터 고용해봤습니다

Antigravity + NotebookLM으로 시도한 블로그 QA 실험 회고

요즘 AI 흐름을 보면 OpenClaw, Claude Computer Use처럼 강한 실행권을 가진 에이전트 도구가 빠르게 늘어나고 있습니다.
이 흐름을 보다 보면 PM 입장에서는 자연스럽게 이런 질문이 생깁니다.

“지금 당장 멀티 에이전트 팀을 꾸려봐야 하나?”
“트렌드를 따라가려면 일단 화려한 데모부터 만들어야 하는 것 아닐까?”

저도 비슷한 고민을 했으나, 결론은 조금 달랐습니다.
지금 PM이 먼저 챙겨야 할 것은 여러 에이전트를 멋지게 붙이는 기술이 아니라, 에이전트를 제품처럼 안전하고 검증 가능하게 다루는 감각이었습니다.
어떤 문제에 붙일 것인지, 어디까지 맡길 것인지, 결과를 어떻게 확인할 것인지가 먼저였습니다.

그래서 이번에는 범위를 크게 잡지 않았습니다.
멀티 에이전트 팀 대신,
제가 쓴 글을 근거 기준으로 까다롭게 검토해주는 작은 AI 검사관을 먼저 만들어보기로 했습니다.

 

1. 실험 설계: 글을 써주는 AI가 아니라, 근거를 따지는 AI

이번 실험의 핵심은 창작이 아니라 QA였습니다.
AI가 제 글을 대신 써주는지보다, 제가 정해둔 근거 안에서 제 글의 비약과 근거 부족을 잡아낼 수 있는지를 보고 싶었습니다.

구성은 단순했습니다.

  • 상위 실행자: Antigravity
  • 근거 저장소: NotebookLM
  • 연결 방식: MCP
  • 목표: 블로그 초안 1개를 근거 기반으로 검토

실제로 붙여보니 중요한 점이 바로 드러났습니다.
단순히 툴을 연결하는 것만으로는 충분하지 않았습니다. QA의 품질은 결국 무엇을 근거로 삼느냐에 더 크게 좌우됐습니다.

그래서 공식 문서, 배포/채널 관련 자료, 그리고 제 개인 회고 메모를 묶어 작은 근거팩을 만들고, 그 노트북만을 기준으로 QA를 돌렸습니다.

이 과정 자체가 꽤 중요했습니다.
에이전트의 성능보다 먼저, 근거 체계를 어떻게 설계할 것인가가 품질을 결정한다는 점을 바로 확인할 수 있었기 때문입니다.

 

2. 결과: PASS_WITH_FIXES, 그리고 생각보다 유효했던 지적들

결과는 PASS_WITH_FIXES였습니다.
메시지의 큰 방향은 맞지만, 몇몇 문장은 수정이 필요하다는 평가였습니다.

가장 유효했던 지점은 두 가지였습니다.

첫째, 근거 체계 밖의 문장을 정확히 잡아냈습니다.
초안에는 전통적인 4P 프레임워크를 인용한 부분이 있었는데, 이번 QA는 NotebookLM 안에 넣어둔 소스만 기준으로 삼도록 했기 때문에 이 문장을 unsupported로 판정했습니다.

문장이 틀렸다는 뜻은 아닙니다.
다만 이번 글의 근거 구조 안에는 없는 내용이라는 뜻입니다.
이 지적은 단순한 팩트체크를 넘어, “이 글이 지금 어떤 근거 위에 서 있는가”를 다시 보게 만들었습니다.

둘째, 개인 경험과 일반론이 섞인 문장을 잘 잡아냈습니다.
예를 들어 “공을 많이 들인 프로젝트보다 가볍게 만든 프로젝트가 더 잘 먹힌 경우도 있었다”는 문장은 제 경험으로는 사실이지만, 그대로 두면 일반론처럼 읽힐 수 있습니다.

QA는 이 부분을 과장 또는 해석 혼합으로 지적했습니다.
덕분에 경험은 경험으로, 해석은 해석으로 분리해서 쓰는 편이 훨씬 정확하다는 점을 다시 확인했습니다.

결국 이 실험에서 AI가 잘한 일은 “정답 쓰기”가 아니라, 문장의 근거 수준을 구분하고 비약을 드러내는 것이었습니다.

 

3. 해보니 보였습니다: 지금 PM에게 중요한 것은 ‘화려함’보다 ‘통제력’

이번 실험을 통해 얻은 인사이트는 생각보다 명확했습니다.

먼저, 지금 단계에서 AI는 작가보다 편집자에 더 가깝다고 느꼈습니다.
글을 통째로 대신 쓰게 하는 것보다, 제가 쓴 글을 검토하게 하는 쪽이 훨씬 실용적이었습니다.
근거 부족, 논리 비약, 경험과 일반론의 혼재 같은 부분을 걸러내는 데는 꽤 유효했습니다.

또 하나는, 툴보다 문제 정의가 먼저라는 점입니다.
처음 질문은 “멀티 에이전트를 해봐야 하나?”였지만, 실제로 더 중요했던 것은 “어떤 문제를 가장 작고 검증 가능하게 실험할 수 있나?”였습니다.
이번처럼 범위를 줄인 QA 실험은 비용도 작고, 결과도 명확했습니다.

물론 한계도 있었습니다.
소스를 넣고 정리하는 일은 여전히 수동적이고, 회고나 관점 중심 글은 원래부터 해석의 비중이 커서 source-grounded QA가 완벽하게 들어맞는 영역은 아닙니다.
그리고 AI의 지적을 어디까지 수용할지는 결국 사람이 판단해야 했습니다.

그럼에도 이번 실험은 충분히 의미가 있었습니다.
거창한 에이전트 팀을 만들지 않아도, 작고 명확한 문제를 하나 잡고 실제로 돌려보는 것만으로도 배울 수 있는 것이 많다는 점을 확인했기 때문입니다.

 

마치며

에이전트 시대에 PM이 먼저 익혀야 할 것은 “여러 에이전트를 멋지게 이어 붙이는 법”이 아니라,
“어떤 문제에, 어느 수준까지, 어떻게 검증 가능한 형태로 붙일 것인가”를 판단하는 감각입니다.

이번 작은 QA 실험은 그 감각을 확인해보기에 꽤 괜찮은 출발점이었습니다.
기술 자체를 크게 벌려 보기보다, 어디에 붙였을 때 가장 현실적이고 반복 가능한 결과가 나오는지를 살펴보는 쪽이 더 의미 있었습니다.

적어도 이번 실험에서는,
AI가 글을 처음부터 대신 써주는 역할보다
이미 작성한 글을 한 번 더 점검하고 다듬는 역할에서
조금 더 실용적인 가능성을 확인할 수 있었습니다.

한 줄 요약
에이전트 시대에 PM이 먼저 해야 할 일은 멀티 에이전트 데모가 아니라, 목적에 맞는 작고 검증 가능한 문제에 AI를 붙여보며 통제력을 익히는 것입니다.

 

Similar Posts

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다