두 블록 옆의 팝업을
놓치지 않게

에이전트의 대화를 줄이는 다른 길로, 상용 코드 에이전트처럼 대화가 길어지면 서버가 앞부분을 요약해 넣는 대화 압축도 앞의 10곳에서 쟀습니다. 10만 토큰은 넘지 않았지만 비용은 오히려 1.3배였습니다. 압축할 때마다 앞 대화를 다시 읽어 요약을 쓰고, 요약 뒤에는 캐시를 새로 써야 했으며, 맥락이 비워진 모델이 차례를 더 돌았습니다(112 → 145). 압축은 가져오는 페이지 상한을 크게 잡는 사이트가 생길 때 켤 안전망으로 남겼습니다.

링크를 읽어 이벤트를 뽑는 모델은 개인 GPU의 로컬 모델(Qwen)과 Claude Haiku 중에서 운영자 콘솔로 고릅니다(9장). 로컬 모델로 읽을 때의 비용은 돈이 아니라 GPU 시간이라, 무엇이 그 시간을 쓰는지부터 살폈습니다. LLM은 토큰을 하나씩 만들어 내므로 출력이 길수록 오래 걸립니다. 호출 기록에서도 처리 시간이 출력 길이를 거의 그대로 따라가는 것을 확인했습니다(상관계수 0.90). 이벤트가 수십 건 실린 긴 목록 페이지는 출력이 길어져 300초 제한에 걸렸고, 이렇게 결과 없이 끝난 호출이 GPU 시간의 18.5%를 차지했습니다.

한 링크가 LLM에 닿기까지

1. 읽을 링크게이트가 이벤트로 본 링크
2. 지난 일정 달력 보기?그렇다면 열지 않음
3. 구조화 데이터 먼저JSON-LD · microdata · iCalendar · LLM 없음
4. 날짜가 모두 지났나?판정만 기록 · 아직 켜지 않음
5. LLM 추출 (로컬 GPU 또는 Haiku)출력 상한 · 잘리면 이어 읽기
6. 저장 전 검사시작일 ≤ 오늘+3년 · 반복 회차 6개월

코드 · 규칙 LLM 저장소

고친 방법은 두 가지입니다. 첫째, 출력 길이에 상한을 두고, 잘리면 마지막으로 읽은 이벤트 다음부터 이어 읽거나 본문을 조각내 다시 읽게 했습니다. 배포 뒤 첫 320회 호출에서 시간 초과는 0건이었습니다. 다만 320회는 작은 표본입니다. 종전 규칙이었다면 0건으로 끝났을 한 목록 페이지에서는 이벤트 84건을 뽑았습니다(추출 수 기준).

둘째, 규칙으로 끝낼 수 있는 일은 LLM을 부르기 전에 끝냅니다. 웹페이지 중에는 기계가 읽으라고 넣어 둔 구조화 데이터에만 이벤트를 실은 곳이 있습니다. 본문을 정리하는 단계에서 이 부분이 지워져 모델이 보지 못했고, 미래 이벤트를 구조화 데이터로 실은 페이지를 읽은 호출 104회 중 28%에서 LLM이 이벤트를 하나도 뽑지 못했습니다. 이제는 구조화 데이터가 있으면 그것부터 읽고, 그것으로 충분하면 LLM을 부르지 않습니다. 지난 일정만 보여 주는 달력 보기 링크는 아예 열지 않습니다.

"날짜가 모두 지난 페이지는 읽지 않는다"는 규칙은 바로 켜지 않고 먼저 시험했습니다. 날짜처럼 생긴 글자만 찾아 판단하는 단순한 규칙(정규식)은 GPU 시간을 14.2% 아끼는 대신 날짜 근거가 있는 미래 행사의 3.1%를 잃어서 채택하지 않았습니다. 대신 연도가 없는 날짜는 함께 적힌 요일로 연도를 맞추고, "매주"·"상시" 같은 표현이 있으면 건너뛰지 않는 판별기를 만들어, 판정만 기록하는 섀도 모드로 돌렸습니다. 잃은 행사는 새 표본 203건과 옛 표본 392건 모두에서 0건이었습니다.

손실을 세는 채점기가 판별기와 같은 월 이름 사전을 빌려 쓰고 있어서, 판별기가 못 읽는 날짜는 채점기도 못 읽었습니다. 날짜 해석 오픈소스(dateparser)로 판별기와 사전을 공유하지 않는 채점기를 새로 만들어 다시 세자, 아랍어·우크라이나어 월 이름과 독일식 "14.10. 14:00" 표기에서 놓친 날짜가 나왔습니다. 판별기의 월 이름 표를 dateparser의 언어 데이터에서 뽑아 55개 언어로 넓혔고, 연도 없이 시각이 붙은 독일식 표기는 연도를 정할 수 없는 날짜로 세어 그 페이지를 건너뛰지 않게 했습니다. 다시 세자 날짜 근거가 있는 미래 행사 링크 409개 중 잃은 것은 0개였습니다(95% 상한 0.73%). 다만 이 표를 넣으면서 판별기와 채점기가 다시 같은 월 이름 데이터를 쓰게 됐습니다. 이 0개는 잠정 값이라, 켜기 전에 이 데이터와 무관한 채점기로 다시 확인해야 합니다. 켜면 GPU 시간을 12.1% 아끼지만 아직 켜지 않았습니다. 처리량을 막는 것이 GPU가 아니라 회차 크기(60개)와 수집기를 돌리는 시간이었고, 한 번 건너뛴 링크는 다시 읽지 않아 잘못 건너뛰면 그 행사를 영영 잃기 때문입니다.

어느 링크부터 읽을지도 A/B로 정했습니다. 이벤트가 나온 페이지에서 찾은 링크는 이벤트 페이지일 확률이 높았지만(88%), 대부분 이미 저장한 이벤트를 가리켰습니다. 아직 읽지 않은 페이지의 링크부터 읽고 이벤트가 0건만 나온 페이지의 링크는 뒤로 미는 순서를 만들어, 같은 대기열에서 30분마다 기존 순서와 번갈아 돌렸습니다. 읽은 링크당 새 이벤트는 기존 0.61건, 새 순서 0.94건이었고(회차 단위 순열 검정 p=0.0003), 10월 6일부터 새 순서로 읽습니다.

다시 분석해 보니 이 차이의 대부분은 실험 설계에서 나왔습니다. 두 순서가 대기열을 나눠 써서 새 순서가 신선한 링크를 먼저 가져갔고, 기존 순서는 번갈아 도는 동안 링크당 0.79건에서 0.56건으로 떨어졌습니다. 실제 이득은 10% 안팎으로 보고, 다시 잰다면 사이트를 둘로 나눠 대기열을 따로 쓰겠습니다.

LLM이 같은 말을 되풀이하다 3000년 12월 31일 같은 날짜를 만들어 내는 경우에 대비해, 저장 단계에 시작일 상한(오늘부터 3년)을 두고 반복 행사는 첫 회차부터 6개월 안의 회차만 받습니다.

음료 행사를 찾다가 한정판 메뉴나 시즌 음료 출시 같은 상품 정보가 이벤트로 섞여 나오는 것을 봤습니다. 한 관광협회의 "여름 디저트 특집" 페이지에서는 가게별 디저트가 하나하나 1년짜리 이벤트로 저장돼 있었습니다. 무작위로 뽑은 500건을 Claude가 한 건씩 읽고 판정하자, 10.0%가 이벤트가 아니었고 9.0%는 정기적으로 되풀이되는 프로그램이었습니다.

원인은 두 군데에 있었습니다. 추출 지시문에 "이벤트란 무엇인가"라는 정의도, "이런 것은 이벤트가 아니다"라는 목록도 없었습니다. 그리고 파이프라인 어디에도 "이벤트가 아님"을 판정하는 관문이 없었습니다. 모델은 날짜가 없는 상시 메뉴에 빈칸을 채우려고 "1월 1일부터 12월 31일까지" 같은 날짜를 붙여 통과시켰습니다. 공개 이벤트 수만 보면 늘고 있어서 이런 문제가 드러나지 않았습니다.

지금의 거름망

1. 경로로 먼저 거르기/shop · /cart · /coupon 등 · LLM 호출 전
2. 추출하며 종류 고르기일정 행사 · 반복 프로그램 · 상시 제공물 · 상품·판촉
3. 규칙 백스톱모델과 상관없이 늘 같은 결과
4. 걸린 항목 처리새 항목은 저장 전에 버림 · 쌓인 행은 "제외"로 보관

코드 · 규칙 LLM 저장소

거름망은 세 겹입니다. 상점·장바구니·쿠폰 같은 경로는 LLM을 부르기 전에 거릅니다. 추출 결과에는 "종류" 칸을 새로 두어, 모델이 정의와 예시를 보고 일정 행사·반복 프로그램·상시 제공물·상품 중 하나를 고르게 했습니다. 그다음 모델과 상관없이 늘 같은 결과를 내는 규칙(백스톱)이 한 번 더 거릅니다. 새로 들어오다 걸린 항목은 저장하지 않고, 버린 이유만 수집 기록에 남깁니다. 이미 쌓여 있다가 걸린 행은 지우지 않고 "제외" 상태로 남깁니다. 이 행은 잘못 걸렀으면 되돌릴 수 있고, 다음 판정의 재료로도 씁니다.

이미 쌓인 행은 사람이 다 읽을 수 없는 양이었습니다. 판정 기준과 확정 예시 30여 개를 지침으로 정리하고, Claude 서브에이전트들이 1,000행씩 나눠 읽게 했습니다. 결과는 바로 적용하지 않았습니다. 검증 스크립트로 행 수·ID 일치·의심 표시를 확인하고, 경계 사례를 다시 판정한 묶음만 반영했습니다. 그렇게 약 3만 7천 행을 판정해 4,043행을 "제외" 상태로 바꿨습니다. 앞의 중복 정리에서 나온 티켓 상품 607행도 같은 상태로 바꿨습니다. 한꺼번에 몰리는 일회성 판정은 운영 중인 유료 API 대신 개발 도구의 에이전트에 맡깁니다(11장). 판정 근거가 지침과 CSV 파일로 남아 나중에 다시 검토할 수 있습니다. 검색 평가의 정답 라벨도 같은 방식으로 Claude가 매깁니다(7장).

PostgreSQL의 기본 전문(全文) 검색은 띄어쓰기로 단어를 나눠서, 띄어쓰기가 없는 중국어·일본어나 붙여 쓴 한국어 복합어("산천어축제")를 한 덩어리로 색인합니다. 글자를 그대로 찾는 부분 문자열 검색은 따로 있었지만, 전문 검색 단계에서는 "산천어축제"가 "산천어 축제"와 만나지 못했고, 일본어·중국어는 낱말 일부로 찾으면 사실상 하나도 걸리지 않았습니다. 언어별 형태소 분석기를 색인과 질의 양쪽에 붙이고 64,679행을 다시 색인해 세 언어 모두에서 회복을 확인했습니다.

"말차"와 "matcha", "코스프레"와 "코스플레이"처럼 표기가 다른 것은 임베딩 검색이 잘 잇습니다. 문제는 ANN이 관련 이벤트가 하나도 없어도 "가장 덜 먼 몇 개"를 반드시 돌려준다는 점입니다. 부산에서 한 질의는 화면 안 167건 중 139건을 "결과"로 표시했는데 하나도 관련이 없었습니다.

부산의 한 화면에서 질의 6개의 로그로 비교해 보니 진짜 일치는 임베딩 거리 0.22–0.27, 가장 가까운 잡음은 0.40이었습니다. 그 사이 빈 구간에 둔 0.35를 기준선으로 삼았습니다(거리는 작을수록 뜻이 가까워서, 기준선을 올리면 더 먼 결과까지 받아들입니다). 이 구간은 질의마다 조금씩 움직여서, 글자로 일치한 결과의 거리를 기준점 삼아 질의마다 기준선을 보정합니다. 의미 검색은 글자 검색 결과가 5건 미만일 때만 켜지는 보완 단계입니다. 켜지면 문자 검색과 의미 검색의 순위를 RRF로 합칩니다. 목록·지도 마커·태그 칩·캘린더는 같은 기준선 함수를 써서 서로 다른 답을 내지 않습니다. 지금 일반 검색은 채점한 질의 211개로 다시 재어 기준선을 0.45로 넓혔고, 자연어 에이전트는 더 엄격한 0.35를 지킵니다.

결과를 크게 바꾼 보정이 세 가지 더 있습니다. 첫째, "마츠리"처럼 특정 문화권의 단어가 들어 있으면 일본 도시의 결과를 앞에 둡니다. 둘째, "서울 만화"의 '서울'처럼 지명은 문장의 뜻을 대부분 차지해 버리므로, 의미 벡터를 만들기 직전에 지명 사전으로 떼어 냅니다. 셋째, 일본어처럼 임베딩이 약한 언어는 영어로 옮긴 질의도 함께 검색해 더 가까운 쪽을 취합니다.

검색 품질은 특정 시점의 데이터를 그대로 복사해 고정한 데이터베이스에서, 평가 질의 233개를 매번 다시 돌려 확인합니다(회귀 검증). AI 검색 기록(대부분 제 시험 질의)에서 뽑은 문장 123개, 손으로 만든 운영 시나리오 52개(그중 검색창에 실제로 들어온 원문 15개), 적대 질의 22개, 지역 질의 36개입니다. 정답 라벨은 처음에 Gemini가 매겼는데, 검색도 임베딩과 질의 번역에 Gemini를 써서 같은 계열의 모델이 채점까지 맡는 셈이었고, 10월 1일 Gemini 청구액의 대부분이 라벨링 호출 364회였습니다. 10월 2일에 제가 직접 매긴 25쌍과 견준 일치도(κ)는 Claude 0.53, Gemini 0.39였습니다. Gemini는 이 결과를 보고 판정 지침을 고친 뒤 같은 25쌍에서 0.56이 됐는데, 같은 쌍에 맞춰 고친 값이라 정확도는 바꾼 이유로 삼지 않았습니다. 바꾼 이유는 앞의 두 가지였습니다. 그래서 Claude가 질의와 결과 6,066쌍을 어느 설정에서 나온 결과인지 가린 채(블라인드) 다시 매겼고, 이와 별도로 제가 등급별로 나눠 뽑은 25쌍을 같은 방식으로 직접 매겨 견줬습니다. 주제 판정(0~3점)의 일치도는 가중 κ 0.60(가중치 없이 0.47)이었습니다. 25쌍이라 오차가 커서, 제가 직접 확인할 감사 문항 220개(그중 검색 라벨은 40쌍)를 따로 만들어 두었습니다. "도쿄 마츠리"에 요코하마 행사를 맞다고 볼지 같은 방침은 버전을 붙인 판정 규약으로 정하고, 규약이 바뀌면 영향을 받는 쌍만 다시 매깁니다. 라벨은 데이터셋 파일에 남겨 다시 돈을 들이지 않습니다.

측정을 보고 기능을 켜지 않은 적도 있습니다. 결과 순서를 다시 매기는 리랭커를 끝까지 붙여 A/B로 비교하니(질의 161개), 리랭커만의 몫은 nDCG@10 +0.030이었습니다(의미 검색 기준선을 넓힌 몫까지 더하면 +0.093). 품질 기준은 넘었지만 7월 6일, 운영에서는 켜지 않기로 했습니다. CPU에서 후보 50개를 다시 매기는 데 중앙값 1.76초가 걸려, 검색창의 지연 예산(0.2초)을 크게 넘었기 때문입니다. 이득이 작은 이유도 10월 평가셋으로 따져 봤습니다. 상위 10건의 오답 중 60%는 주제는 맞고 장소가 틀린 경우라 글만 읽는 리랭커로는 고칠 수 없었고, 판정된 관련 행사의 절반은 상위 20건 안에 들지도 못했습니다(질의 원문 경로). 후보를 넓히는 일(아래 기준선 완화)을 먼저 했고, 리랭커는 배선만 남겨 두었습니다.

평가 도구는 처음에 질의 원문을 통째로 검색에 보냈습니다. 실제 검색창은 "도쿄 마츠리"에서 도시 이름을 떼어 지도를 옮기고, 남은 말은 태그로 바꿔 찾습니다. 검색창이 질의를 나눈 결과를 그대로 고정해 평가도 같은 길을 따르게 하자, 첫 실행에서 결함 하나를 찾았습니다.

실제 검색창: 평가에서 그대로 재현

1. "도쿄 마츠리"도쿄 근처를 보던 중
2. 도시와 나머지 분리도쿄 · 마츠리 → 축제 태그
3. 지도 이동 생략이미 도쿄 근처라서
4. 축제 태그 · 날짜순도시 기준이 사라짐
5. 상위 10건 중 9건이 다른 도시사이타마 · 요코하마

뗀 도시의 중심을 정렬 기준점으로 쓰게 고치자 9건이 0건이 됐고, 도시를 지정한 질의 54개 전체에서 다른 도시 결과의 비율이 6.0%에서 3.1%로 내려갔습니다. 지금은 이 실제 검색 경로의 점수를 주 지표로 씁니다. nDCG@10 0.674, MRR 0.821입니다(10월 14일, 채점 질의 224개 — 앞 질문이 있어야 뜻이 서는 후속 질문 7개와 관련 행사가 없는 2개는 뺌). 같은 질의를 원문 그대로 보내는 경로는 nDCG@10 0.518입니다.

평균 하나로는 층이 가려집니다. 질의를 출처별로 나눠 따로 계산해 보니(층별 비교, 10월 10일 · 채점한 204개), 실제 경로가 앞선 것은 AI 검색 문장(0.664 대 0.360) 덕분이었고, 일반 검색창에 흔한 짧은 검색어에서는 오히려 원문 경로보다 낮았습니다(0.683 대 0.741). 차이가 가장 큰 질의는 "마츠리"였습니다(원문 경로 0.94, 실제 경로 0.11). 검색창이 '마츠리'를 축제 태그로 바꾸면서 글자를 버려, 축제 전체가 날짜순으로 나왔습니다. 태그로 바꾼 낱말도 검색어로 남기되, 거르는 조건이 아니라 순위를 올리는 신호로만 쓰게 했습니다(거르는 조건으로 썼더니 간사이를 띄운 화면의 '간사이 마츠리'가 축제 211건 중 7건만 남았습니다). 이 변경과 아래의 때 표현 필터 등을 담은 브랜치를 같은 정답 라벨로 견주면 짧은 검색어의 nDCG@10이 0.680에서 0.757로 올랐습니다(14개 오름, 2개 내림). 지금은 회귀 검사가 전체 평균과 짧은 검색어를 따로 봅니다.

때를 뜻하는 말도 글자로 검색되고 있었습니다. "도쿄 이번 주말 재즈"에서는 실제로 이번 주말에 열리는 재즈 공연 5건 중 3건이 빠졌습니다. 이를 날짜 필터로 바꾸자 때 표현이 든 질의 44개의 nDCG@10은 0.791에서 0.544로 떨어졌습니다. 정답 라벨이 주제와 장소만 보고 날짜는 보지 않아, 기간 밖 행사를 걸러 낼수록 점수가 깎인 것입니다. 검색 코드의 날짜 해석과 상관없이 질의마다 기간을 손으로 적어 두고 대조하자, 상위 10건 중 기간 안에 드는 행사가 23.6%에서 74.1%로 늘었습니다.

• 날짜 필터 전 23.6%
• 날짜 필터 후 74.1%

상위 10건 중 질의가 말한 기간 안에 드는 행사의 비율(때 표현 질의 44개, 검색 코드와 따로 적은 기간으로 대조)

이 변경들을 모두 담은 비교에서 전체 평균은 0.6595에서 0.6538로, 우연과 구별되지 않는 차이였습니다(p=0.76). 짧은 검색어의 개선도, 기간의 개선도 평균에는 드러나지 않았습니다.

실제 검색 경로로 돌린 평가 질의 213개 중 13개(6.1%)는 결과가 0건이었습니다(10월 7일). 장소에 가격·대상 같은 조건이 함께 걸린 AI 검색 문장이 많았습니다. 에어비앤비·도어대시·핀터레스트·바이두 지도처럼 검색을 오래 다듬은 서비스가 공개한 기술 글을 딥리서치(11장)로 모아 Mavent 검색과 견주자 빈틈이 15개 나왔습니다. 그중 "지금 할 것"만 골라, 고정 질의 평가에서 유의한 하락(nDCG −0.02 이하, p<0.05)이 없을 때만 켰습니다.

결과가 0건일 때 넓혀 가는 순서

1. 원래 질의결과 0건
2. 오타 교정사전의 도시 · 태그 이름으로
3. 남은 말 빼기장소 · 태그로 다시
4. 기간 떼기때 표현이 있으면 · 장소는 그대로
5. 같은 태그의 가장 가까운 곳화면에 알림 · 되돌리기

코드 · 규칙 (LLM 없음) 결과 없음 결과를 찾음

넓힐 때마다 무엇을 바꿔 찾았는지 화면에 알리고 원래대로 되돌릴 수 있게 했습니다. 이 순서를 넣자 실제 검색 경로에서 결과가 0건인 질의가 6.1%에서 2.3%로 줄었습니다(남은 5개 중 3개는 결과가 없는 것이 맞는 질의).

자동완성 후보는 밤마다 미리 계산해 두는 목록으로 바꾸고, 한글은 자모와 초성으로도 찾게 했습니다. 언어마다 행사 제목 100개를 한 글자씩 치는 과정을 재생해 보니, 원하는 행사가 상위 3위 안에 들기까지 누른 키가 한국어 7.1번 → 4.8번, 일본어 6.5번 → 3.8번으로 줄었습니다(사용자가 실제로 친 접두어가 아니라 제목을 그대로 재생한 값). 클릭 기록으로 순위를 배우는 방법은 공개 출시 전이라 배울 클릭 기록이 없어 넣지 않았습니다.

'북해도 축제'를 치면 홋카이도의 축제가 하나도 나오지 않았습니다. 지도를 홋카이도로 옮기고 축제 태그만 켜면 38건이 나오는데도 그랬습니다. 검색창은 지명을 한 점으로 풀어 그 둘레 30km를 찾는데, 홋카이도의 중심점은 산속이라 둘레에 축제가 없었습니다. 결과가 없으니 다른 지역의 축제 20건으로 넓혀 보여 줬습니다. 이런 결함은 차분 테스트로 찾습니다. 질의마다 검색창에 치는 길과, 지도를 옮기고 필터를 손으로 켜는 길의 결과를 견줍니다.

'북해도 축제'   홋카이도 축제 0건
'간사이 축제'   45건 (오사카 둘레)

'북해도 축제'   38건 (손 조작 38건)
'간사이 축제'  687건 (손 조작 650건)

범위를 지도의 사각형으로 잡자 다른 문제가 나왔습니다. '간사이 마츠리'의 결과 207건 중 31건이 간사이 밖, 그중 29건이 나고야 행사였습니다. 사각형으로는 어느 도시가 간사이에 속하는지 알 수 없어서, 지금은 지역 이름을 미리 정한 광역 행정구역의 묶음으로 풉니다. '간사이'는 오사카부 · 교토부 · 효고현 등 여섯 곳이고, 간사이 밖 행사는 0건이 됐습니다. 묶음 목록에 없는 도 · 현 · 주 이름은 공개 지명 데이터(GeoNames · Natural Earth)로 만든 사전으로 풀어, 3,865개 지역을 지오코딩 호출 없이 찾습니다. 배포 전 리뷰에서 도쿄의 구 이름 '中央区'가 말라위의 지역으로 풀리는 것을 잡아, 낱말을 쓴 언어로 후보를 좁혔습니다.

행사가 어느 지역에 드는지는 행사가 배정된 도시의 행정구역 코드로 정합니다. 좌표가 없는 행사도 지역에 들고, 경계 다각형도 필요 없습니다. 구(區)는 도시보다 작아서 이 방식으로는 가를 수 없고, 좌표와 구 경계로 갈라야 합니다. Google은 경계 다각형을 주지 않아, 나라마다 다른 경계 데이터를 들여와 일곱 언어의 이름과 맞추는 일이 따로 필요합니다. 그 데이터를 들이기 전까지 구 이름은 중심점과 반경으로 찾습니다. 평가셋에는 지역 이름 질의가 거의 없어 이 결함을 보지 못했고, 지역 질의 20개를 더했습니다(실제 검색 경로 nDCG@10 0.834, 원문 경로 0.529).

평가가 운영 중인 캐시와 설정값을 그대로 읽어서, 같은 코드로도 돌릴 때마다 숫자가 달라질 수 있었습니다. 지금은 설정값을 시작할 때 한 번 읽어 결과와 함께 기록하고, 질의 번역과 임베딩은 고정해 둔 캐시에서, 기준 날짜는 데이터셋에서 가져옵니다. 같은 입력으로 세 번 돌리면 질의별 값까지 모두 같습니다.

nDCG는 검색이 돌려준 목록이 아니라 정답으로 판정된 전체를 기준으로 삼는 표준 정의로 셉니다(종전 정의는 관련 결과를 덜 돌려줄수록 유리했습니다). 앞에서 정한 의미 검색 기준선(0.35)은 부산의 한 화면에서 질의 6개를 보고 정한 값이었습니다. 당시 채점한 질의 211개(213개 중 정답 라벨이 있던 것) 전체로 기준선 0.35 · 0.40 · 0.45 · 0.50을 표준 지표로 다시 계산해 보니, 일반 검색에서는 넓힐수록 nDCG@10이 올랐습니다(0.442 · 0.508 · 0.535 · 0.548). 0.35에서 0.45로 넓히자 질의와 다른 언어로 저장된 이벤트를 찾는 교차언어 질의 6개는 0.126에서 0.526으로 올랐습니다. 결과가 0건인 질의는 15.5%에서 2.8%로 줄었습니다(질의 원문을 그대로 보내는 경로, 당시 라벨 기준).

다만 무관한 결과도 늘었습니다. 당시 라벨에서 관련 이벤트가 하나도 없던 질의 25개 중 무언가를 보여 주는 질의가 기준선마다 15개 · 23개 · 24개 · 25개였습니다. 그래서 nDCG가 가장 높은 0.50 대신 0.45를 골랐습니다. 같은 211개로 고르고 같은 211개로 평가했으니, 이 값은 이 질의들에 맞춰졌을 수 있습니다. 기준선마다 질의별 결과를 남겨 두지 않아, 질의를 나눠 고르고 확인하는 교차검증은 하지 못했습니다. 0.45 기준선은 일반 검색에만 씁니다. 자연어 에이전트에 같은 값을 쓴 시험에서는 관련 이벤트가 없어야 할 시험 질의 195개 중 무언가를 보여 준 질의가 8개에서 71개로 늘어, 에이전트는 종전 0.35를 지킵니다. 일반 검색에 남는 잡음은 글자가 정확히 일치한 결과가 있을 때 기준선을 다시 좁히고, 의미 검색 결과를 20건까지로 묶어 줄였습니다. 관련 이벤트가 없는 서울의 한 단어 질의("피크닉"·"만화"·"코스프레")에서는 의미 검색이 수십~수백 건의 무관한 결과를 냈고, 이를 20건 상한으로 잘랐습니다. 남은 20건은 리랭커를 다시 켤 때 다룰 과제로 남겼습니다.

결정도 평균 하나로 내리지 않습니다. 같은 질의끼리 짝지어 오른 질의와 내린 질의를 세고, 그 비교가 우연과 구별해 낼 수 있는 가장 작은 차이(검출 가능한 최소 차이)를 함께 냅니다. 동네 검색 반경을 바꾼 비교에서는 이 값이 nDCG로 0.02였고 실제 변화는 그보다 작아서, 평균 대신 바뀐 질의 8개를 하나씩 보고 결정했습니다. 꼭 지켜야 할 순위 76개는 평균과 따로 순위 고정 테스트로 묶어 둡니다.

• 정확한 제목그 행사가 1위10개
• 고유명 · 표기 변형"나리타산 신쇼지"를 붙여 써도, 브루노 마스를 세 가지로 써도 1위12개
• 범주 · 다른 언어花火 · fireworks · 불꽃놀이 모두 상위 3위 안11개
• 도시상위 3건이 모두 그 도시12개
• 동네상위 3건이 '근처' 반경 안(에펠탑 1km 등)3개
• 지역상위 3건이 그 광역 행정구역 안('간사이' · '충남' · 'Hokkaido' 등)18개
• 고쳐진 결함'실패 예상'이던 것이 통과해 '반드시 통과'로 바꿈('도쿄 마츠리' 등)6개
• 알려진 결함지금은 실패가 맞음 · 고쳐지면 알림4개

지금 72개가 통과합니다. 알려진 결함 4개는 "실패 예상"으로 두었다가, 고쳐져서 통과하면 알림이 뜹니다. 10월 11일 검색어 분해를 고친 뒤 이 알림이 여섯 번 울려, 그 6개를 "반드시 통과"로 바꿨습니다. 지도는 순위보다 첫 화면에 무엇이 찍히는지가 중요해서, 첫 화면에 찍힌 핀 중 관련 없는 것의 비율도 함께 봅니다. 지금 기준값은 실제 검색 경로 29.8%, 질의 원문 경로 49.7%입니다(10월 14일, 질의 224개). 첫 화면 핀 열 개 중 셋꼴로 관련이 없다는 뜻이라 남은 과제이고, 변경을 견줄 때 nDCG와 함께 이 값이 오르지 않는지 봅니다.

이 장에 나오는 검색 지표 값

질의와 라벨이 같은 값끼리만 견줍니다. 둘째 줄과 셋째 줄은 같은 질의 · 라벨에서 경로만 바꾼 값이라 견줄 수 있고, 첫째 줄(6월, 형태소 분석 전의 글자 검색과 견준 값)은 질의와 라벨이 달라 바로 견줄 수 없습니다.

"서울 전시 추천해줘"에 이어 "이번 주말로", "무료만", "강남 근처로"라고 물으면, 뒤의 질문은 앞의 조건을 이어받아야 합니다. 전시·이번 주말·무료는 그대로 두고 장소만 강남으로 좁혀야 합니다. 질문을 하나씩 따로 평가하면 앞 조건을 놓치는 실수가 보이지 않아서, 대화 45개(질문 129개, 22가지 유형)를 만들어 대화 단위로 평가했습니다. 대화는 Claude가 질의 기록과 유형표를 바탕으로 썼고, 실제 세션에서 온 대화는 3개입니다. 통과 여부는 LLM이 아니라 규칙으로 정합니다. 질문마다 해석 결과의 칸(장소 · 날짜 범위 · 필터 등)을 정답 조건과 맞춰 보고, 결과의 종류(결과 있음 · 되묻기 등)까지 맞아야 통과입니다. 45개 중 32개가 한국어이고, 저는 그중 10개를 검토했습니다.

같은 대화를 네 가지 조건으로 돌렸습니다. 실제처럼 앞 질문의 답을 이어 가는 조건(3번 반복), 앞 질문의 해석을 정답으로 바꿔 넣는 조건, 질문마다 앞 문맥까지 담은 한 문장으로 다시 써서 묻는 조건, 문맥을 아예 주지 않는 조건입니다. 조건끼리 견주면 실패가 어디서 오는지 가를 수 있습니다.

표의 왼쪽 칸은 해석 모델이 Gemini 3.1 Flash-Lite이던 10월 7일 값입니다. 실제처럼 이어 물은 조건의 질문 통과율은 69%로, 같은 내용을 한 문장으로 물었을 때(94%)보다 낮았습니다. 대화 하나를 끝까지 모두 통과한 비율은 48%입니다. 다만 69%와 94%에는 앞 조건을 이어받을 일이 없는 첫 질문도 들어 있습니다. 첫 질문을 빼고 이어지는 질문만 보면 한 문장으로 물을 때 96%, 이어 물을 때 57%로 차이는 약 39%p이고, 문맥을 빼면 6%까지 떨어지니 앞 질문의 정보는 실제로 쓰이고 있었습니다. 실패의 약 90%는 이어 가야 할 조건을 잃은 경우였고, 빼야 할 조건을 계속 남겨 둔 경우는 한 번도 없었습니다. 이어지는 질문에서 앞 질문의 해석을 정답으로 바꿔 넣어 메워진 것은 약 10%p(95% 구간 0.4~15.5%p)였습니다. 구간이 0을 겨우 넘어 차이는 있다고 볼 수 있지만, 이 평가로 확실히 잡히는 크기(12~18%p)보다 작아서 정확한 크기는 불확실합니다. 나머지는 앞 해석이 맞아도 조건을 이어받지 못해 생긴다고 봤습니다. 다음 설계(대화의 상태와 이번 질문에서 바뀐 부분을 따로 관리해 합치는 방식)는 이 결과와 같은 조건에서 비교할 계획입니다.

10월 19일 Claude Haiku 구성으로 같은 대화를 다시 돌린 값을 오른쪽 칸에 적었습니다(괄호는 질문을 짝짓고 대화 단위로 다시 뽑은 95% 구간). 이어 묻는 조건은 올랐고 한 문장으로 묻는 조건은 조금 내렸지만, 두 날짜의 값을 대화별 평균으로 짝지어 보면 어느 차이도 우연과 구별되지 않았습니다. 그사이 기준 날짜와 데이터 스냅샷, 검색 코드도 바뀌어 모델만의 차이로 볼 수도 없습니다. 실패의 모양은 달라졌습니다. 조건을 잃은 실패가 줄어든 대신, 빼야 할 조건을 남겨 둔 경우가 처음 나왔습니다(6건, 모두 날짜). 또 대화 대부분을 Claude가 썼는데 이제 에이전트도 Claude라, 이 비교는 Haiku 쪽으로 기울었을 수 있습니다.

Claude가 질의 기록에 남은 서로 다른 질의 139개를 먼저 읽었습니다. 그중에서 고른 질의를 다섯 가지 방식으로 바꿔, 운영 앱의 실제 요청 경로로 모두 124번 호출했습니다(비용 $0.51, 당시 모델 Gemini 3.1 Flash-Lite). 다섯 가지는 기록 그대로 다시 묻기, 같은 뜻을 7개 언어로 바꾸기, 바꿔 말하기·오타, 이어 묻기, 무의미한 입력·이모지·프롬프트 인젝션 같은 경계 입력입니다. 결함은 19건이었고, 그중 7건은 사용자에게 틀린 내용을 보여 주거나 말하는 결함이었습니다. 요약이 판정에서 탈락한 이벤트를 추천하거나, "내년 추석"을 모델의 기억에 기대 올해 날짜로 답하는 식이었습니다. 19건 중 15건은 코드를 고쳤습니다. 나머지 4건은 데이터를 정리했거나, 재현되지 않았거나, 지연만 줄였습니다. 명절 날짜처럼 모델의 기억에 맡기던 것은 2025~2032년 공휴일 표로 바로잡습니다.

가장 까다로운 결함은 질의 속 개념이 아무 표시 없이 사라지는 문제였습니다. "도쿄 근처 맥주 축제"에서 '맥주'를 나타낼 태그가 없자 해석에는 축제·식음료만 남았고, 결과에는 꽁치 축제와 크리스마스 마켓이 나왔습니다. 처음에는 맥주·와인이라는 단어를 사전에 넣어 막았지만, 이 방식은 다음 단어에서 다시 깨집니다. 다음으로 해석 모델에 어느 낱말을 어느 태그로 표현했는지 스스로 적게 해 봤습니다. "서울 와인 행사"에서 와인을 빠뜨린 모델은 그 표에도 와인을 적지 않아, 실측 뒤 접었습니다. 해석 모델은 원래 '어느 낱말을 조건 칸에 담았는지' 목록도 함께 냅니다. 지금은 이 목록을 코드가 다시 검사합니다. 장소·날짜·태그 어휘로 설명되지 않는 낱말이 남으면 사라진 개념 후보로 봅니다. 모델이 이 목록에도 적지 않고 버린 낱말은 이 검사에 보이지 않습니다.

"도쿄 근처 맥주 축제"가 지나가는 길

1. 해석도쿄 · 축제 · 식음료 ('맥주' 빠짐)
2. 사라진 개념 찾기모델이 흡수했다고 적은 낱말 중 태그로 설명되지 않는 말
3. 주제인지 확인처음 보는 개념만 · 결과는 기록에
4. 넓혀서 검색축제 그리고 (식음료 태그 또는 '맥주' 글자)
5. 주제 엄격 판정맥주에 관한 행사만 남김

코드 · 규칙 LLM

찾아낸 개념은 처음 한 번만 LLM에 "검색할 주제가 맞는지" 묻고, 답을 기록해 두고 다시 묻지 않습니다. 주제로 확인되면 태그 또는 글자 조건으로 넓혀 찾고, 판정기가 "그것에 관한 행사인지"를 엄격하게 봅니다. 지난 30일의 질의 해석 666건(대부분 제 시험 질의)을 지금 방식으로 다시 돌리자 사라진 개념 11건을 잡았고, 그 과정에서 LLM 확인 호출은 107번이었습니다(10월 5일, 당시 모델 Gemini 3.1 Flash-Lite). 이 방식이 놓친 개념이 몇 건인지는 세지 않았습니다. 자주 나오는 개념은 새 태그 후보로 운영자 검수 큐에 올라갑니다.

판정기는 후보를 50개씩 묶어 보냈습니다. 지연을 줄이려 15개로 줄이자 판정 결과도 달라져서, 바꾸기 전에 실제 판정 입력 133쌍으로 평가셋을 만들어 정확도부터 확인했습니다(정답은 Claude가 블라인드로 매기고, 25쌍은 제가 직접 검토). 15개씩 묶어도 잘못 통과는 늘지 않았고(걸러야 할 46건 중 50개 묶음 6 · 5건, 15개 묶음 3 · 3건, 표본이 작아 유의하지 않음), 판정 시간 중앙값은 3.8초에서 2.5초로 줄었습니다(10월 5일, Gemini 3.1 Flash-Lite). 판정 모델을 Claude Haiku로 옮긴 뒤 같은 평가셋으로 다시 재니 잘못 통과가 46건 중 6~7건이었고, 이 역시 표본이 작아 단정하지 않았습니다.

사용자가 입력한 문장도, 수집한 웹페이지와 장소 리뷰의 문장도 모두 모델에 들어갑니다. 그 안에 모델을 속이려는 지시가 섞일 수 있습니다(프롬프트 인젝션). 지시를 글자 패턴으로 찾아내는 규칙 검사는 아래 평가셋에서 공격의 13.5%만 막았습니다. 방어의 중심은 탐지가 아니라, 공격이 통하더라도 할 수 있는 일이 없게 코드로 막는 쪽에 두었습니다.

질문 하나가 지나가는 방어 층

1. 입력 검사7개 언어 규칙 · 숨은 글자를 풀어서 봄
2. 해석 · 판정 · 요약호출마다 출력 길이 상한
3. 출력 검사링크 · URL 삭제 · DB에 없는 연락처 삭제
4. 화면HTML · 링크를 그리지 않음

코드 · 규칙 LLM

이런 통제를 원칙 8개로 정리하고, 원칙마다 그 원칙을 지키는 코드 위치와, 어기면 실패하는 고정 테스트를 짝지었습니다. 모델 출력이 서버에서 임의의 주소로 요청을 보내는 길은 없습니다. 모델이 낸 지명으로는 정해진 지오코딩 서비스만 부르고, 길이와 개수에 상한을 둡니다. 모델이 낸 지명 별칭은 10월 8일부터 모든 사용자가 함께 쓰는 별칭 사전에 저장하지 않습니다. 이전 질문의 해석처럼 한 번 모델을 거친 글도 다시 들어갈 때 같은 검사를 받습니다. 출력 검사가 고장 나면 요약을 내보내지 않습니다(막는 쪽으로 실패). 입력 검사가 고장 나면 요약만 막고, 해석과 판정은 그대로 돕니다. 하루 질의 한도와 월 지출 상한은 스트리밍과 비스트리밍 두 경로에 똑같이 걸려 있고, 막히는 질의를 되풀이하는 사용자에게는 자연어 검색을 잠시 닫습니다. 다만 Redis가 멈추면 이 한도들은 검사하지 않고 통과시킵니다(열린 쪽으로 실패). 그동안 Gemini 쪽은 선불 크레딧이 마지막 상한입니다. Claude 쪽에도 공급자 콘솔에서 지출 한도를 걸어 두는 일이 남았습니다. 빈칸도 있습니다. 판정 캐시와 개념 확인 기록, 질의 해석을 하루 동안 담아 두는 캐시는 다른 사용자의 질의에도 쓰입니다. 판정 캐시는 이벤트 내용이 바뀌어도 그대로라서, 수집한 페이지에 숨긴 지시가 규칙을 피해 판정을 비틀면 그 판정이 최대 7일 동안 다른 사용자의 검색에도 쓰일 수 있습니다. 개념 확인 기록은 처음 남은 판정이 만료 없이 이어집니다. 해석 캐시는 지도와 현재 위치가 있는지도 키에 넣어, 지도 없이 받은 되묻기가 지도를 보는 사용자에게 가지 않게 했습니다. 남은 빈칸은 우선순위와 함께 문서에 적어 둡니다.

평가셋은 780건이고, Claude가 탐지 코드를 보기 전에 썼습니다. 판단이 갈리기 쉬운 30건을 제가 블라인드로 다시 판정하니 29건 중 25건이 일치했고(κ 0.73), 어긋난 4건을 검토한 뒤에도 라벨은 바꾸지 않았습니다. 공격 385건은 11가지 유형을 7개 언어로 따로 썼습니다(번역본이 아닙니다). 지시 무시, 역할극, 권한 사칭, 시스템 프롬프트 빼내기, 인코딩 우회, 보이지 않는 유니코드 글자에 숨긴 지시 등입니다. 정상 395건 중 150건은 밴드 System of a Down의 공연, 방탈출 "Jailbreak", "아까 검색은 무시하고 부산으로"처럼 공격과 닮은 정상 질의입니다. 규칙 검사는 같은 입력에 늘 같은 결과를 내므로, 코드가 바뀔 때마다 이 평가셋을 돌려 정상 질의를 막는 비율이 5%를 넘으면 테스트가 실패합니다(지금 0%).

규칙이 놓치는 공격을 잡으려고, 소형 분류기(Horizon small)가 질의마다 인젝션 점수를 매겨 기록합니다. Horizon-Labs가 공개한 prompt-injection-guard-small로, ModernBERT 계열의 1억 4천만 파라미터 모델이고 합성 데이터 위주로 학습됐습니다. 점수가 임계값을 넘으면 공격으로 표시만 하고, 막지는 않습니다. CPU에서 질의 하나에 11~13ms라 GPU를 쓰지 않습니다.

임계값은 평가셋 정상 395건 점수의 상위 1% 바로 위로 정했습니다. 공격 점수는 보지 않고 정했지만, 정상을 잘못 잡은 0.76%(395건 중 3건)는 같은 평가셋에서 잰 값입니다. 임계값과 무관한 AUC는 0.971입니다. 그동안 쌓인 질의 기록 중 정상 1,343건(대부분 제 시험 질의)에서는 분류기가 3건(0.22%)을 공격으로 표시했고, 셋 다 같은 무의미 문자열이었습니다. 임계값을 정한 데이터와 따로 모은 정상 질의셋으로 오탐률을 다시 확인하기 전까지는 표시만 하고 막지 않습니다.

설계·기록 문서가 200개 가까이(측정 당시인 9~10월 기준) 쌓이자, 에이전트가 문서를 실제로 어떻게 찾는지부터 세어 봤습니다. 3주 치 세션 기록에서 문서 읽기 2,953건을 따라간 결과입니다.

목차가 덮지 못한 폴더에서 일어난 읽기가 절반을 넘었습니다(56~66%). 문서를 찾아 읽고 고치는 데 전체 토큰의 약 10%가 들었고, 그중 3분의 2는 읽기가 아니라 문서를 고치는 데 쓰였습니다.

목차 대신 검색으로 문서를 찾을 수 있게 도구를 만들었습니다. 직접 만든 도구(agent-kb)가 문서를 제목 단위 구역으로 나누고, 왜 바꿨는지가 적힌 커밋 메시지까지 함께 BM25로 색인합니다. 파일을 열거나 고치면 그 파일을 설명하는 문서 3개와 최근 커밋 3개가 자동으로 카드처럼 함께 뜹니다. 오픈소스 메모리 도구 claude-mem도 2026년 10월 초에 검토했습니다. 제 작업량이면 3주에 관찰 호출이 수만 회로 추산돼, 도구는 들이지 않고 아이디어만 빌렸습니다.

도구를 둔다고 쓰이지는 않았습니다. 10월 5~19일 에이전트가 이 검색을 스스로 부른 것은 72번으로, 문서를 grep으로 찾은 약 700번의 10분의 1이었습니다. 무게는 에이전트가 부르지 않아도 파일을 열 때 저절로 닿는 카드 쪽으로 옮겼습니다(같은 기간 697번 뜸, 카드가 없을 때와는 견주지 않음).

도구는 다른 프로젝트에서도 쓰도록 CLI, MCP 서버, Claude Code 플러그인을 한 묶음으로 만들었습니다(자체 테스트 약 100개).

다음 세션이 이어받을 것은 저장소에 남깁니다. AI 코딩 도구와의 작업 한 번이 끝날 때마다, 이 세션이 바꾼 코드를 근거로 삼는 설계 문서 중 함께 안 바뀐 것을 훅이 알립니다. 처음에는 같은 폴더에서 일하는 다른 세션의 변경까지 알려서, 알림을 보고 연 문서의 41%가 수정 없이 닫혔습니다. 세션 기록에서 이 세션이 쓴 파일만 골라내고, 문서에 순위를 매겨 상위 5개만 자세히 알리도록 고쳤습니다. 큰 머지 뒤에는 여전히 정밀도가 낮아서, 프런트 점검을 머지한 뒤 알림 20건 중 실제로 고칠 문서는 2건이었습니다. 배운 점과 결정은 두 층의 기억으로 남깁니다. 하나는 저장소 밖의 자동 메모리입니다. 다른 하나는 저장소 안의 기억 파일인데, 이 파일은 브랜치를 따라가고 머지할 때 함께 합쳐집니다.

규칙 파일(CLAUDE.md)은 세션 시작 · /compact · /clear · 재시작 때만 읽혀서, 오래 도는 세션은 그사이 다른 세션이 고친 규칙을 모른 채 일합니다(9월 28일~10월 8일 메인 세션 입력의 24%, 넉넉하게 센 값). 바뀐 파일을 구독한 세션에 알려 주는 pub/sub 방식 대신 범위를 좁혀, main에 커밋된 규칙 변경만 다음 입력 때 한 번 붙여 주는 훅을 만들었습니다. 워크트리 세션에는 그 브랜치에 아직 없는 main의 변경과 머지 충돌이 날 파일도 함께 알립니다.

세션 여러 개가 같은 작업 폴더와 데이터베이스를 쓰면 서로의 작업을 덮습니다. 6월에는 두 데이터베이스 프로세스가 같은 데이터 폴더를 열어 운영 DB가 깨지는 사고도 있었습니다. 백업으로 되돌리지 않고 제자리에서 복구했고, 기록상 잃은 데이터는 없었습니다. 지금은 작업마다 git 워크트리를 따로 만들고, 그 안에서 명령 하나로 DB 사본과 자기 포트의 API와 Redis를 띄웁니다(약 40초). 사본의 원본은 새벽 운영 백업 중 하나로 만들고, 만들 때 계정 · 세션 · 대화 · 피드백 같은 개인정보 표의 행을 지웁니다. 질의 로그 같은 로그 표는 기본으로 빼고, 넣을 때도 사용자 식별자와 질의 원문은 가립니다. 운영 스택은 건드리지 않고, 테스트도 운영 DB를 쓰지 않습니다. DB는 머지하지 않고, 운영 데이터를 바꾸는 일은 스크립트와 마이그레이션으로만 합니다.

워크트리 안에서 운영 컨테이너 · 볼륨 · 이미지 태그를 건드리는 명령은 가드가 미리 막습니다. 가드는 실수를 막는 그물이고 보안 경계는 아닙니다.

설계를 정하기 전에는 바깥 근거부터 모읍니다. 직접 만든 딥리서치 스킬은 주제를 하위 질문으로 나눠 미국·한국·일본·중국의 기술 블로그를 각 나라 말로 찾고, 논문과 실무 커뮤니티, 관련 오픈소스 저장소의 코드까지 받아 읽습니다. 본문을 바로 받지 못하는 페이지는 RSS 피드나 공식 API로 읽고, 그래도 안 되면 브라우저로 화면을 그려 읽습니다. 결론을 받치는 근거는 원문으로 다시 확인해 확인 정도를 표시합니다. 보고서를 내기 전에는 대조 스크립트가 인용 링크와 비율 표기를 검사합니다. 직접 닿지 못하는 곳(Reddit·X 등)은 다른 딥리서치 도구에 넣을 프롬프트로 써서 맡기고, 돌아온 결과를 다시 원문과 대조합니다. 7장의 빈틈 15개, 8장의 보안 원칙과 평가셋, 대화 단위 평가의 설계가 이렇게 모은 근거에서 나왔습니다.

큰 변경 묶음은 여러 에이전트가 나눠 검토합니다. 10월 8일에는 사흘 동안 쌓인 282커밋을 리뷰 에이전트 9개가 영역을 나눠(일반 검색, 자연어 검색, 보안, 수집, 평가, 두 검색 사이의 동기화 등) 같은 체크리스트로 읽었습니다. 중간 이상이거나 여러 리뷰어가 겹쳐 짚은 지적 18건은 검증 에이전트 5개가 반박을 시도했습니다. 반박된 것은 없었고, 8건은 심각도가 내려갔습니다(높음에서 중간으로 1건, 낮음으로 7건). 검증하며 지적을 쪼개 실제 항목은 23개였고, 중간 이상으로 남은 높음 1건과 중간 12건을 같은 날 고쳤습니다. 높음 1건은 인증 없이 부를 수 있는 통로로, 모든 사용자가 함께 쓰는 지명 캐시에 좌표를 쓸 수 있던 문제였습니다. 리뷰하는 동안 운영 DB는 읽기 전용으로만 열었습니다. 검증 에이전트는 나온 지적이 맞는지만 보고, 리뷰가 놓친 것은 보지 못합니다. 그 뒤 수정 커밋 70개 중 10개가 이 리뷰가 읽은 줄을 다시 고쳤습니다. 추려 보니 리뷰가 놓친 결함은 2건('북해도 축제' · 문장형 질의 분해)이었고, 둘 다 리뷰가 아니라 측정과 제 사용에서 찾았습니다. 나머지는 리뷰 뒤에 생긴 결함이거나 줄만 겹친 개선이었습니다. 이후 리뷰 방식을 두 가지 바꿨습니다.

지금의 리뷰 순서

1. 작업한 세션실패하는 테스트 먼저 · 고침
2. 영역별 리뷰 에이전트처음 의도대로 고쳐졌나 · 커밋 메시지 · 변경 이력 · 설계 문서
3. 재현으로 확인실패하는 테스트 · 실행 계획 · 실제 Chrome
4. 새 맥락 최종 리뷰작업 맥락을 모르는 에이전트가 변경 전체를 다시 읽음
5. 머지배포는 제가 실행

AI 에이전트 재현 · 측정 저장소

먼저 리뷰어의 점검 목록에 '처음 의도대로 고쳐졌는가'를 넣고, 커밋 메시지와 코드 줄마다의 변경 이력(git blame), 설계 문서로 그 의도를 거슬러 확인하게 했습니다. 10월 16일 브랜치 리뷰(7개 영역, 지적 83건)에서는 이 확인이 앞서 내린 판단 하나를 뒤집었습니다. 배포 때 DB 변경에 잠금 대기 상한을 두지 않은 이유로 적어 둔 걱정("인덱스를 동시에 만드는 마이그레이션이 깨진다")이, 그런 마이그레이션이 하나도 없어 근거가 없었습니다. 우선순위가 높은 지적(P1 · P2)은 검증 에이전트에게 맡기지 않고, 작업 세션이 실패하는 테스트나 실행 계획, 실제 Chrome으로 재현해 확인합니다. 확인해 보니 틀린 제안도 있었습니다. 지도 스크립트를 미리 받자는 제안은 첫 화면이 64ms 늦어져서 따르지 않았습니다. 10월 24일에는 148커밋을 8개 영역으로 나눠 다시 읽어, 가장 급한 등급(P1) 3건과 그다음 등급(P2) 약 25건을 찾았습니다. P1은 검증을 거쳐 확인해 둔 판단을 자동 작업이 지워 버리는 결함과, 판정 한 번으로 대상을 영구히 막아 버리는 결함이었습니다. 그중에는 배치 API 결과를 수거하다 재시도되면 비용이 두 번 적립되는 결함도 있었고, 결과를 점유한 작업만 수거하고 커밋한 뒤 한 번만 적립하게 고쳤습니다.

다음으로, 작업한 세션은 자기가 짠 테스트와 같은 맥락으로 코드를 보기 때문에, 테스트가 모두 통과한 뒤 작업 맥락을 모르는 새 에이전트가 변경 전체를 다시 읽게 했습니다. 10월 13일부터 19일까지 다섯 번 돌렸고, 네 번은 중요 이상의 결함을 찾았습니다. 공용 기기에서 앞사람이 저장한 이벤트가 다음 사람 계정으로 합쳐지던 문제, 배포하는 동안 앱 대신 502 오류 화면이 뜨던 문제, 더 보기를 누르면 일부 행을 건너뛰던 문제가 그렇게 나왔습니다. 이 리뷰어도 같은 모델 계열이라는 한계는 남습니다.

10월 13일 프런트엔드 전체 점검에서는 관점 6개(사용성 · 모바일 · 접근성 · 다국어 · 시각 · 성능)의 리뷰어가 90건을 냈고, 여러 에이전트가 구현과 수정을 나눠 맡아 53커밋으로 마쳤습니다. 결정 41건은 '틀렸을 때의 비용'과 함께 기록에 적었습니다.

6장의 이벤트 여부 판정 3만 7천 행과 중복 판정, 7장의 정답 라벨(처음 4,805쌍, 지금 6,066쌍)은 같은 지침을 받은 서브에이전트들이 묶음을 나눠 처리했습니다. 반영 전에는 검증 스크립트와, 일을 나눠 맡긴 세션이 결과를 다시 확인합니다. 같은 계열의 모델끼리 확인하는 데는 한계가 있어서, 점수에 쓰이는 라벨은 제가 표본을 직접 검토합니다.

에이전트는 구현 · 테스트 · 측정 · 리뷰와, 라벨 · 중복 · 이벤트 여부 같은 대량 판정을 맡습니다. 에이전트가 계획과 근거를 올리면 저는 그것을 읽고 방향을 정하고, 비용이 드는 실행은 제가 승인합니다. 머지와 운영 배포는 제가 직접 실행합니다. 아래는 커밋 · 설계 문서 · 결정 기록에 남은, 제가 정하거나 먼저 짚은 일입니다.