AI 에이전트로 반복 가능한 실험 루프 만들기

@givemethatsewon· May 24, 2026· 9 min read

AI 기능을 개선할 때 가장 위험한 흐름은 의외로 단순하다.

프롬프트를 고친다
결과가 좋아 보인다
채택한다
며칠 뒤 다시 고친다
왜 좋아졌는지 모른다

Place2Page에서도 비슷한 문제가 생길 수 있었다. 랜딩페이지 생성 결과는 이미 공개 가능한 수준이었지만, 장소마다 구조와 시각적 리듬이 비슷하게 모이는 경향이 있었다. 프롬프트를 몇 줄 고치면 당장은 더 좋아 보일 수 있다. 하지만 어떤 입력에서, 어떤 후보안이, 왜 더 나았는지 남지 않으면 다음 실험은 다시 감으로 돌아간다.

그래서 이번 작업의 핵심은 combined 프롬프트를 찾는 것이 아니었다. 진짜 목표는 사람이 문제를 정의하고, AI 에이전트가 같은 기준으로 반복 실험을 돌리고, 그 결과를 나중에 다시 설명할 수 있는 증거로 남기는 루프를 만드는 것이었다.

Agentic research loop diagram showing human framing, agent-run experiments, durable evidence artifacts, and a human promotion decision
Agentic research loop diagram showing human framing, agent-run experiments, durable evidence artifacts, and a human promotion decision

요약

  • 문제: Place2Page의 생성 결과는 공개 가능했지만, 프롬프트 실험이 기억과 스크린샷에만 남으면 나중에 왜 좋아졌는지 설명하기 어려웠다.
  • 판단: 중요한 것은 어떤 프롬프트가 이겼는가보다, 같은 입력에서 여러 가설을 반복 검증하고 증거를 남길 수 있는가였다.
  • 접근: 현재 기준선을 고정하고, 후보안을 같은 입력 세트에서 반복 생성한 뒤, 점수와 스크린샷, prompt diff, 통과 여부를 함께 남겼다.
  • 결과: combined 후보안이 가장 실용적인 방향으로 보였지만, 더 큰 결과는 실험 lineage와 판단 기록이 남는 연구 루프였다.
  • 배운 점: 내가 말하는 에이전틱 리서치는 AI에게 판단을 맡기는 것이 아니라, 사람이 기준을 세우고 AI 에이전트가 반복 가능한 실험과 기록을 빠르게 만들게 하는 방식이다.

상황

Place2Page는 Google Maps나 Naver Map URL을 넣으면 AI가 장소 기반 랜딩페이지를 생성한다. 장소명, 주소, 사진, 영업시간, 리뷰, 메뉴, 예약 링크 같은 데이터를 모아 HTML로 만든다.

이 기능은 이미 쓸 수 있는 수준이었다. 문제는 "동작하느냐"보다 "결과물이 장소마다 충분히 달라 보이느냐"에 가까웠다.

로컬 비즈니스 랜딩페이지는 쉽게 비슷한 구조로 모인다. 첫 화면, 사진 몇 장, 메뉴나 서비스 카드, 리뷰, 지도, CTA. 이 구성이 틀린 것은 아니지만, 매번 비슷하게 나오면 생성형 제품에 기대하는 적응력이 약해 보인다.

처음에는 자연스럽게 프롬프트를 더 잘 쓰는 쪽으로 생각이 갔다. 구조를 더 다양하게 만들고, AI식 마케팅 문구를 줄이고, 모바일 화면이 깨지지 않게 지시를 더 강하게 넣으면 될 것 같았다.

하지만 곧 질문이 바뀌었다.

이 프롬프트가 좋아 보인다는 판단을 나중에도 다시 설명할 수 있는가?

프롬프트 실험은 작은 변경이 자주 일어난다. 그래서 더 쉽게 흩어진다. 결과 페이지 몇 장만 보고 "이게 더 낫네"라고 끝내면, 며칠 뒤에는 어떤 문구가 어떤 결과를 만들었는지 복원하기 어렵다.

기존 방식이 실패하는 이유

프롬프트 실험을 가장 쉽게 하는 방법은 파일을 열고 문구를 바꾸는 것이다. 그 다음 몇 개 결과를 보고 마음에 들면 채택한다.

이 방식은 빠르다. 하지만 운영 제품에서는 곧 한계가 온다.

  • 기준선이 무엇이었는지 흐려진다.
  • 어떤 입력에서 좋아졌는지 알기 어렵다.
  • 성공한 후보와 실패한 후보가 같이 사라진다.
  • "좋아 보였다"는 판단만 남고 근거가 남지 않는다.
  • 현재 기본값이 파일의 기본값과 달라져도 알아차리기 어렵다.

특히 파일 기본값과 제품에서 선택된 기본값이 따로 존재하는 구조에서는 repo만 봐서는 현재 기준선을 알 수 없다. 그래서 실험의 첫 단계는 프롬프트 수정이 아니라 기준선 고정이었다.

먼저 기준선을 맞췄다

가장 먼저 한 일은 현재 실제로 쓰이는 기준선을 확인하는 것이었다. repo의 프롬프트 파일만 보는 것으로는 부족했다. 제품에서 선택된 기본값은 파일에 남아 있는 기본 문구와 달라질 수 있기 때문이다.

그래서 실험은 로컬 파일 상태가 아니라, 현재 기준선을 맞춘 뒤 시작했다.

이 기준선은 나쁘지 않았다. 기본 정보가 들어가고, 사진도 쓰고, 리뷰와 지도까지 있었다. 다만 결과를 보면 여전히 안전한 음식점 랜딩페이지 형태에 가까웠다. 사진이 페이지 구조를 이끈다기보다 이미 정해진 틀 안에 들어간 느낌이었다.

여기서 중요한 기준이 생겼다.

실험은 "내 로컬 프롬프트가 좋아졌는가"가 아니라 "현재 기준선보다 좋아졌는가"를 봐야 한다.

가설은 압축하고, 반복 가능성을 더 봤다

초기 후보안은 여러 방향으로 나눴다.

  • 정보 구조를 먼저 잡는 방향
  • 과장된 문구를 제거하는 방향
  • 반응형 안정성을 강화하는 방향
  • 세 가지를 결합한 방향

각 후보안의 세부 문구보다 더 중요했던 것은 모든 가설을 같은 입력에서 반복 검증할 수 있는가였다.

실험은 네 개의 고정 장소에서 반복했다.

  • Google 음식점
  • Google 피트니스 스튜디오
  • Naver 공방
  • Naver 뷰티

고정 입력 세트를 둔 이유는 단순하다. 매번 다른 장소를 넣으면 결과가 좋아진 이유가 프롬프트 때문인지 장소 데이터 때문인지 구분하기 어렵다.

결과보다 증거가 더 중요했다

대표 실행 묶음의 자동 요약은 이랬다.

Candidate Results Passed Average score Judgment mix
control-baseline 4 4 100.0 4 pass
structure-first 4 4 100.0 4 pass
anti-slop 4 4 88.0 2 pass, 2 review
responsive-hardening 4 4 100.0 4 pass
combined 4 4 100.0 4 pass

여기서 control-baseline도 100점이고 combined도 100점이다. 그래서 "combined가 자동 점수에서 이겼다"고 말하면 틀리다.

더 정확한 해석은 이렇다.

  • 자동 점수는 공개 실패, 화면 깨짐, 명백한 품질 문제를 잡는 안전장치였다.
  • combined는 구조, 문구, 반응형 규칙을 함께 묶으면서 4/4 공개, 4/4 통과를 유지했다.
  • 사람이 봤을 때 기본값보다 정보 흐름과 시각적 다양성이 더 좋았다.
  • 하지만 최종 판단은 숫자 하나가 아니라 스크린샷, diff, 통과 여부, 사람의 리뷰를 같이 보고 내렸다.

좋은 실험은 좋은 결과만 남기지 않는다. 좋은 증거를 남긴다.

이번 실험에서 가장 가치 있었던 산출물은 새 프롬프트 자체가 아니라, 아래를 연결한 증거 체계였다.

  • 실험 lineage
  • 후보안별 점수와 통과 여부
  • prompt diff
  • 스크린샷과 리뷰 상태
  • 사람이 왜 통과 또는 보류로 봤는지 남긴 판단 기록

이 실험에서 남긴 자산은 페이지 스크린샷만이 아니었다. 실행 묶음별 후보안, 점수, 통과 여부, 프롬프트 계보를 한 화면에서 볼 수 있게 실험 대시보드와 variant graph도 같이 만들었다.

Prompt variant graph showing local experiment lineage, per-variant publish counts, and quality scores
Prompt variant graph showing local experiment lineage, per-variant publish counts, and quality scores

이 그래프에서 더 중요한 기능은 프롬프트 diff였다. control에는 diff가 없고, 실험 후보안에서는 어떤 프롬프트 영역을 바꿨는지 바로 열어볼 수 있다. 변경 지점을 나눠 보여주면 나중에 "이 결과가 왜 나왔는가"를 사람이 다시 검토할 수 있다.

Prompt diff drawer showing changed prompt slots for the Korean few-shot copy editor variant
Prompt diff drawer showing changed prompt slots for the Korean few-shot copy editor variant

개별 실행 대시보드는 자동 점수와 사람이 봐야 하는 지점을 분리해준다. 첫 화면 문구 실험처럼 통과 여부, 점수, 스크린샷 상태가 한 화면에 있으면 "점수는 통과했지만 사람이 다시 봐야 하는 문구"를 빠르게 골라낼 수 있다.

English hero copy experiment dashboard showing pass counts, per-variant scores, and review states
English hero copy experiment dashboard showing pass counts, per-variant scores, and review states

실험 결과물은 실제 페이지 수준의 산출물까지 만들 수 있었다. 다만 이 글에서는 "기본값으로 확정된 최종안"이라기보다 프롬프트 실험이 어떤 품질의 페이지까지 이어질 수 있는지 보여주는 참고 산출물로 보는 편이 맞다.

기록이 사라지면 더 분명해진다

이 교훈은 실험 기록 일부를 다시 잇기 어려웠던 뒤 더 강해졌다.

결과 페이지나 스크린샷 일부는 남아 있어도, "왜 이 프롬프트를 채택했는가", "정확히 어떤 영역이 바뀌었는가", "그 후보가 어떤 입력에서 실패했는가"가 빠지면 실험을 복원하기 어렵다.

그때 분명해진 것이 있다.

실험은 기억에 의존하면 안 된다. 결과만 남겨도 부족하다. 결과가 나오기까지의 경로가 남아야 한다.

그래서 이후에는 단순히 프롬프트를 잘 쓰는 것보다, 실험 과정 자체를 남기는 시스템이 더 중요해졌다. 최소한 HTML 산출물, variant graph, prompt diff, 평가 기록으로 실험 흐름을 다시 추적할 수 있어야 했다.

이 경험 때문에 실험 대시보드와 variant graph는 부가 산출물이 아니라 핵심 산출물이 됐다.

내가 말하는 에이전틱 리서치

이번 작업을 나는 "에이전틱 리서치"라고 부르고 싶다.

여기서 말하는 에이전틱 리서치는 AI에게 "알아서 연구해줘"라고 던지는 것이 아니다. 사람이 문제와 판단 기준을 정하고 AI 에이전트가 반복 가능한 실험 루프를 빠르게 실행하게 만드는 방식에 가깝다.

이번 루프는 이렇게 생겼다.

1. 사람이 문제를 정의한다
   - 페이지는 공개 가능한 수준이지만, 장소별 다양성과 시각적 구체성이 약하다.

2. 현재 기준선을 고정한다
   - repo 파일이 아니라 실제 기본값을 확인한다.

3. 여러 가설을 만든다
   - 구조, 문구, 반응형 안정성 같은 방향을 나눠 본다.

4. 에이전트가 고정 입력 세트로 반복 생성한다
   - Google 음식점, Google 피트니스, Naver 공방, Naver 뷰티.

5. 자동 검사를 안전장치로 쓴다
   - 통과 여부, 점수, 화면 깨짐 여부, 통과/검토 판단.

6. 증거 artifact를 남긴다
   - 실험 대시보드, variant graph, prompt diff, 스크린샷, 판단 기록.

7. 사람이 결과를 본다
   - 100점이 "가장 좋다"는 뜻은 아니므로 사람이 제품 관점에서 다시 본다.

8. 좋은 방향과 위험한 방향을 나눈다
   - 기본값 후보와 다음 실험 후보를 분리한다.

이 방식의 핵심은 AI가 코드를 많이 쓴다는 점이 아니다. AI를 실험 실행자, 관찰 기록자, 반복 작업자로 써서 사람이 더 높은 수준의 판단에 집중하는 데 있다.

후속 실험도 같은 루프 위에서 봤다

실험 루프가 생기면 좋은 점은 다음 질문을 바로 던질 수 있다는 것이다.

combined가 안정적이라면, 큰 구조나 테마 다양화까지 더 밀어붙이면 어떨까?

이 질문으로 dynamic 후보안도 돌렸다. 이 방향은 확실히 구조적 다양성을 더 크게 만들었다. 하지만 바로 기본값으로 올리기에는 애매했다. Place2Page의 기본 약속은 안정적인 로컬 비즈니스 랜딩페이지 생성이다. dynamic 방향은 흥미롭지만 업종과 데이터 품질에 따라 정보 전달이 흔들릴 가능성이 있었다.

그래서 이 루프의 결론은 "가장 과감한 구조를 고르자"가 아니었다.

제품 기본값으로는 combined가 더 실용적이고, dynamic은 다음 실험 후보로 남긴다.

이후 한국어 첫 화면 문구도 같은 관점에서 봤다. 영어 문구의 어색함보다 한국어 문구의 어색함이 훨씬 크게 느껴졌다. "특별한 경험", "감각적인 공간", "미식의 정점" 같은 문구는 실제 장소의 증거보다 AI가 만든 분위기를 먼저 드러낸다.

그래서 기존 산출물에 남아 있던 한국어 첫 화면 문구 실험도 같이 봤다. 이번에는 새 실행을 만들지 않고 남아 있던 HTML과 결과 JSON을 기준으로 했다.

Korean hero copy experiment dashboard comparing control, evidence selector, few-shot editor, and combined variants
Korean hero copy experiment dashboard comparing control, evidence selector, few-shot editor, and combined variants

few-shot 문구 편집 후보안은 좋은 방향과 한계를 함께 보여줬다. control의 과한 수사보다 훨씬 담백해졌고, 실제 장소 데이터에 가까운 단어를 앞으로 가져왔다. 다만 H1이 너무 짧아지는 결과도 있었다. 기본값으로 올리려면 장소명만 두기보다 구체적인 약속을 같이 잡아야 한다.

Korean few-shot hero copy output showing a concise hero with source-grounded wording
Korean few-shot hero copy output showing a concise hero with source-grounded wording

배운 점

첫째, 프롬프트 실험은 기준선이 틀리면 의미가 없다.

기준선을 먼저 맞췄기 때문에 전후 비교를 설명할 수 있었다. repo 파일만 보고 시작했다면 이미 어긋난 기준을 놓고 실험했을 수 있다.

둘째, 자동 점수는 결론이 아니라 안전장치다.

100점이 가장 좋은 페이지라는 뜻은 아니다. 공개 실패, 화면 깨짐, 명백한 품질 문제를 걸러주는 최소한의 장치에 가깝다. 더 좋은 페이지인지는 여전히 사람이 제품과 디자인 관점에서 봐야 한다.

셋째, 좋은 실험은 증거를 남긴다.

실험 묶음, 후보안, 스크린샷, 점수, prompt diff, 사람의 판단 기록이 없으면 빠른 실험은 빠른 기억 손실이 된다. 이번에 의미 있었던 것은 AI가 빨리 많이 만든 것이 아니라, 반복 가능한 증거 체계를 만들었다는 점이다.

넷째, 좋은 실험은 다음 제품 질문을 만든다.

combined 실험의 다음 질문은 "사진을 더 잘 쓰도록 프롬프트를 조일까?"였다. 그런데 실제로는 프롬프트보다 더 나은 방향이 보였다. 사진 자체를 먼저 분석해서 생성 입력으로 넘기는 것이다. 이 다음 이야기는 별도 글인 photo intelligence pipeline 기록으로 이어진다.

다음에는 이렇게 판단한다

이번 실험의 결과는 combined가 아니었다.

combined는 언젠가 또 바뀔 수 있다. 제품 기본값은 더 나은 데이터 경로, 더 나은 사진 분석, 더 나은 품질 기준이 생기면 계속 바뀌어야 한다.

진짜 결과는 문제를 정의하고, 기준선을 고정하고, 가설을 만들고, 같은 입력에서 반복하고, 증거를 남기고, 채택 여부를 결정하는 연구 시스템이었다.

앞으로 프롬프트 실험을 다시 할 때도 문구가 마음에 드는지보다, 나중에 같은 결정을 재현할 수 있는지 먼저 본다. 기록되지 않은 prompt win은 운영 자산이 아니라 기억에 가깝다.

이후의 photo intelligence pipeline도, 다음 프롬프트 실험도, 같은 루프 위에서 진행될 것이다.

참고

givemethatsewon profile
@givemethatsewon
프로젝트를 만들고 운영하면서 배운 개발, 제품, 디버깅 기록을 남깁니다.