소개
AI에게 검색을 잘 시키는 것과, 검색을 잘하는 에이전트를 만드는 것은 어떻게 다를까?
지난 실습에서 AI에게 전국의 축제와 팝업스토어를 조사해 달라고 요청했다. 결과는 제법 그럴듯했다. 전국에서 진행되는 행사 45개를 찾아냈고, 행사명과 장소, 일정도 정리되어 있었다.
그런데 목록을 살펴보다 이상한 점을 발견했다.
성수동 팝업스토어가 거의 없었다.
서울에서 팝업스토어가 활발하게 열리는 지역 중 하나인데도, 결과에는 해당 지역의 행사들이 충분히 반영되지 않았다.
이때 깨달은 건 AI가 많은 정보를 찾았다고 해서, 중요한 정보를 빠짐없이 찾았다는 뜻은 아니라는 것이었다.
1주차에는 프롬프트를 수정해서 이 문제를 개선했다. 이번 2주차에는 한 단계 더 나아가 보기로 했다.
매번 사람이 빠진 곳을 찾아 지적하는 대신, AI가 스스로 누락과 출처 편향을 점검하게 만들 수 없을까? 이 질문에서 이번 Aside 실습을 시작했다.
진행 방법
① USER.md — 사용자가 어떤 결과를 원하는가?
USER.md에는 리서치 목적과 작업 선호를 정리했다.
내가 원하는 것은 단순히 검색 결과를 많이 수집하는 AI가 아니었다.
중요한 정보를 골라내고, 놓친 정보가 있다면 먼저 알려주며, 판단할 수 있는 근거까지 제공하는 AI였다.
그래서 다음과 같은 기준을 정했다.
기본 조사 범위는 대한민국. 해외 사례는 별도 요청이 있을 때 조사한다.
보고할 때는 핵심 요약을 먼저 보여주되 출처와 검증 상태를 함께 제공한다.
누락, 편향, 근거 부족이 발견되면 사용자가 먼저 묻지 않아도 알려준다.
그렇다고 사용자가 요청하지 않은 추가 작업까지 마음대로 실행하지는 않는다.
여기서 중요하게 생각한 건 능동성과 자율 실행을 구분하는 것이었다.
나는 AI가 문제를 발견했을 때 적극적으로 지적해주길 원하지만, 새로운 업무를 스스로 벌이는 것까지 원하는 건 아니다.
② SOUL.md — 어떤 판단 기준을 가진 에이전트인가?
SOUL.md에는 에이전트의 정체성을 검증형 리서처로 설정했다.
AI에게 정보를 많이 찾는 조사원보다, 정보의 신뢰성과 의미를 평가할 줄 아는 리서처 역할을 주고 싶었다.
가장 중요하게 설정한 원칙은 다음과 같다.
많이 모으는 것보다 확인 가능한 사실을 우선한다.
예를 들어 어떤 큐레이션 사이트에서 팝업 일정을 발견했다고 해보자.
그 정보가 흥미롭다는 이유만으 로 확정된 사실처럼 보고하지 않고, 주최 측의 공식 안내나 다른 근거로 추가 확인하도록 했다.
확인되지 않으면 미확인이나 확인 필요라고 표시한다.
또 하나 강조한 것은 결과의 해석이다.
행사명과 날짜를 나열하는 데 그치는 대신, 해당 현상이 왜 주목할 만한지, 무엇이 흥미로운지, 어떤 맥락에서 활용할 가치가 있는지도 설명하도록 설정했다.
자료를 수집하는 AI에서, 근거를 가지고 정보를 해석하는 AI로 바꾸고 싶었던 것이다.
③ AGENTS.md — 실제 작업을 어떤 순서와 규칙으로 수행할까?
세 문서 중 가장 구체적으로 설계한 것이 AGENTS.md였다.
1주차에 발견한 문제를 실제 업무 규칙으로 옮겼기 때문이다.
가장 중요한 규칙은 다음과 같다.
첫째, 요청한 수량을 채웠다고 조사를 끝내지 않는다.
가령 팝업스토어 30개를 찾았다고 해도 조사 대상에 포함된 핵심 상권이나 장소 유형이 빠져 있다면 누락 가능성을 점검한다.
이는 처음 45개를 찾고도 성수 지역이 거의 빠졌던 문제를 예방하기 위한 규칙이다.
둘째, 공식 출처를 우선하고 검증 상태를 기록한다.
행사명, 날짜, 장소처럼 중요한 정보는 가능하면 주최자나 브랜드의 공식 자료로 확인한다.
출처가 충돌할 때는 무리해서 하나를 정답으로 선택하지 않는다.
각 항목에 출처 URL, 출처 유형, 확인 날짜, 검증 상태를 남기도록 했다.
셋째, 새로운 결과를 단순히 덧붙이지 않고 변경 이력까지 관리한다.
장기적으로 반복 조사한 데이터를 Google Sheets에 누적할 계획이기 때문에 같은 행사 중복 등록이나 일정 변경을 관리하는 방식도 정했다.
예를 들어 팝업 종료일이 변경됐다면 기존 값을 무조건 덮어쓰는 게 아니라, 이전 값과 새로운 값, 변경 시점, 확인 출처를 따로 기록하도록 했다.
다만 이 부분은 현재 운영 설계 단계다. 실제 Google Sheets 연결이나 자동 업데이트까지 완료한 것은 아니다.
3. 운영 기준을 만드는 데 무려 20개의 질문이 필요했다
세 문서를 처음부터 직접 작성하기보다는, AI와 대화하면서 선택지를 하나씩 결정하는 방식으로 진행했다.
처음에는 간단하게 끝날 줄 알았다.
그런데 막상 설정을 정하기 시작하니 생각보다 고려할 것이 많았다.
예를 들어 리서치 결과가 부족할 때 AI가 추가 조사를 자동으로 수행해도 될까? 서로 다른 출처의 날짜가 다르면 어떤 값을 저장해야 할까? Google Sheets 데이터는 어디까지 수정할 수 있을까?
검색만 생각할 때는 떠오르지 않았던 문제들이었다.
결국 다음 네 가지 영역을 중심으로 총 20개의 질문에 답했다.
설계 영역
핵심 결정
리서치 성향
검증 우선, 출처 다양성, 누락 가능성 점검
보고 방식
핵심 요약 + 근거 + 불확실성
데이터 관리
지정된 Google Sheets 내 누적 관리, 변경 이력 보존
실행 권한
승인된 범위에서만 작업, 위험한 행동은 사전 승인
특히 인상적이었던 것은 AI의 판단 능력을 높이는 설정과 AI의 권한을 넓히는 설정은 다르다는 점이었다.
예를 들어 에이전트가 데이터 오류를 발견했다고 해서 기존 데이터를 마음대로 삭제해도 되는 것은 아니다.
우리는 지정된 시트 안에서 신규 데이터를 추가하거나 검증된 정보를 갱신하는 것은 허용하되, 삭제나 외부 공개, 권한 변경 같은 작업은 별도 승인을 받도록 설정했다.
웹 수집 과정에서도 자동 수집 전 robots.txt 확인, 위험도가 높은 수집 작업의 이용약관과 API 정책 확인 등 운영 기준을 구분해서 정했다.
물론 20개 질문을 하나씩 답하는 과정은 꽤 길었다. 마지막에는 여러 권한 관련 질문을 묶어서 결정하는 편이 더 효율적이라는 생각도 들었다.
하지만 그 과정 덕분에 기존에는 막연하게 생각하던 'AI가 알아서 잘해주면 좋겠 다'는 기대가 구체적인 업무 규칙으로 바뀌었다.
결과와 배운 점
1주차에는 AI가 성수 팝업을 놓쳤으니 프롬프트에 성수를 추가했다.
이는 당장 결과를 개선하는 데 효과적이었다.
하지만 모든 중요한 지역과 검색 사이트를 프롬프트에 하나씩 추가하는 방식에는 한계가 있다.
새로운 상권이나 행사 유형이 등장할 때마다 사용자가 직접 검색 범위를 수정해야 하기 때문이다.
이번에는 같은 문제를 다르게 정의했다.
'성수를 반드시 검색해'에서 **'핵심 지역과 출처 유형의 누락을 스스로 점검해'**로 바꾼 것이다.
또 하나의 변화는 결과의 평가 기준이다.
처음에는 AI가 얼마나 많은 행사 정보를 찾았는지가 중요했다.
지금은 다음을 더 중요하게 보게 됐다.
중요한 지역이 빠지지 않았는가?
출처가 특정 플랫폼에 편중되지 않았는가?
공식 검증된 정보와 미확인 정보가 구분되는가?
사용자가 지적하기 전에 AI가 스스로 한계를 보고하는가?
물론 이런 규칙을 파일에 작성했다고 해서 AI가 항상 완벽하게 따를 것이라고 기대하지는 않는다.
그러나 적어도 어떤 결과를 좋은 리서치라고 판단할지에 대한 기준은 명확해졌다.
도움 받은 글 (옵션)
참고한 지피터스 글이나 외부 사례를 알려주세요.
(내용 입력)
