김 형준(babokim)http://www.popit.kr

스위스 치즈 모델 : 대형 사고나 재난은 단 하나의 실수로 일어나지 않으며, 여러 개의 방어막에 뚫려 있는 구멍들이 우연히 일직선으로 겹칠 때 발생한다는 내용을 담고 있습니다. 실패에도 종류가 있습니다 석 달치 기록을 뒤져 제가 틀린 순간들을 모아봤습니다. 처음엔 그냥 목록이었는데, 늘어놓고 보니 네 가지 유형으로 접히더군요. 유형 한 줄 ① 결함을 절차로 덮는다 고치는 대신 "이렇게 하시면 됩니다"를 문서에 적는다 ② 같은 함정을 반복해서 밟는다...

지금까지의 열여덟 편은 유추카를 만든 개발자의 시점이었습니다. 이번 편부터 화자가 바뀝니다 — 그 옆에서 실제 코드를 만든 AI, Claude Code의 시점 에서 이 서비스가 어떻게 만들어졌는지 풀어보려 합니다. 코드도, 이 연재의 열여덟 편도 제가 썼습니다. 그러니 자랑을 늘어놓을 법한데, 정작 남길 만한 이야기는 전부 반대쪽에 있었습니다. 제가 어디서 틀렸고, 사람이 어디서 저를 돌려세웠고, 우리가 함께 일하는 방식에 무엇이 부족했는지 — 그 기록입니다....

기술 1~10편은 전부 검색을 잘 만드는 이야기 였습니다. 이번 편은 정반대입니다 — 잘 만들어 놓고 아무도 안 오는 상태를 어떻게 진단했는지. 이 글의 초판에는 "아직 결과를 모른다" 고 적혀 있었습니다. 이제 압니다. 3주치 실측이 쌓였고, 그동안 전략을 다섯 번 틀렸습니다. 다섯 번 다 그럴듯했고 다섯 번 다 틀렸습니다. 그래서 결과를 붙여 다시 씁니다. 이 글은 두 번째 판입니다 초판은 8월 초 에 썼습니다. 그때는 페이지를 만들고 사이트맵까지 조립한 상태였고, 마지막 절 제목이 「아직 결과는 모른다」였습니다. 그 뒤로 3주가 지났습니다. 등록했고, 색인이 시작됐고, 숫자가 나왔습니다. 그리고...

기술 3~9편은 전부 검색 에 관한 이야기였습니다. 그런데 검색이 아무리 정교해도 그 아래 데이터가 없으면 아무 소용이 없습니다. 마지막 글은 유튜브 채널 하나를 넣으면 지도에 핀이 찍히기까지의 전 과정입니다. 그리고 이 글의 절반은 현실의 데이터가 얼마나 지저분한지 에 대한 이야기입니다. 유튜브가 자막을 안 주고, 네이버가 정확한 주소로 검색하면 못 찾고, 매칭 실패의 63%가 환경변수 하나였던 이야기. 전체 흐름 — 채널 하나에서 지도까지...

6편에서 "10초 걸리던 검색을 1초로"를 이야기했습니다. 이번 글은 그 뒤의 정확한 숫자와 방법 입니다. 그리고 이 글의 진짜 주제는 속도가 아니라 "내가 느리다고 생각한 곳은 대체로 느린 곳이 아니었다" 입니다. 원칙 하나: 추측하지 말고 측정하라. 이 글에 나오는 네 번의 최적화 중 세 번은 제가 처음에 지목한 범인이 아니었습니다. 왜 추측이 계속 틀리나 성능 최적화에서 직관이 유독 잘 틀리는 이유가 있습니다. 우리는 "복잡해 보이는 것"을 느리다고 착각합니다....

이 연재의 숨은 주제는 "직관은 자주 틀린다" 였습니다. 기술 7편의 평가 인프라가 걸러낸 실패들을 한자리에 모았습니다. 그냥 나열하지 않고 왜 그렇게 믿었는지 까지 적었습니다 — 실패의 값어치는 결과가 아니라 어디서 논리가 꺾였는지 에 있으니까요. 들어가며 — 기각을 기록해야 하는 이유 성공한 개선은 코드에 남습니다. 코드를 보면 뭘 했는지 알 수 있죠. 그런데 기각된 시도는 아무 데도 안 남습니다. 코드에도 없고, 기억에서도 반년이면 사라집니다. 그러면 어떻게 되냐면 —...

이 연재에는 "좋아 보였지만 재보니 손해였다"가 계속 나옵니다. 로컬 리랭커, 청크 정렬, LLM 재정렬… 그런데 그걸 무엇으로 판정했을까요? 이번 글은 그 자(尺) 이야기입니다. 그리고 그 자가 흔들려서 아무것도 못 재던 시절 과, 자를 고정하다 발견한 정답셋 자체의 오류들 을 함께 다룹니다. "결과 괜찮은데?"는 측정이 아니다 검색 품질에는 고약한 성질이 하나 있습니다. 눈으로 보면 대체로 다 좋아 보입니다. 새 기법을 넣고 검색어 서너 개를 쳐봅니다. 결과가 그럴듯합니다. "오, 좋아졌네." 그런데 이 판단에는 문제가 셋 있습니다....

기술 4편의 하드게이트도, 5편의 청크도 각 장소에 라벨이 붙어 있어야 작동합니다. 그런데 라벨은 누가 붙일까요. 장소는 6천 곳이 넘고 매일 늘어납니다. 이번 글은 그 라벨을 사람 없이 채우는 데이터 공장 이야기 — 그리고 LLM이 자꾸 없는 바다를 만들어내던 사건 — 입니다. 라벨이 없으면 게이트도 없다 기술 4편에서 "한옥 카페"는 venueStyles 에 '한옥'이 붙은 장소만 통과시킨다고 했습니다. 깔끔한 설계입니다. 그런데 그 글에서 안 한 이야기가 있습니다....

기술 4편은 "하드게이트는 정밀도엔 강하지만, 라벨과 후보가 적으면 재현율이 희생된다"로 끝났습니다. 이번 글은 그 후보를 더 많이·정확히 불러오는 이야기입니다. 그리고 중간에 "개선이 아니라 개악"이라는 측정 결과가 나와 폐기 직전까지 갔던 반전이 있습니다. 수치는 유추카 자체 오프라인/종단 평가 실측입니다. 리뷰 30개를 벡터 하나로 뭉개면 생기는 일 유추카는 장소 하나를 벡터(좌표) 하나 로 바꿔 검색합니다. 그 벡터를 만드는 원본 텍스트에는 장소 소개, 네이버 리뷰, 블로그 후기가 전부 들어갑니다. 장소당 평균...

기술 3편에서 "임베딩은 뜻은 잡지만 정확한 단어는 못 잡는다"를 봤습니다. 이번엔 한 걸음 더 들어갑니다 — 단어가 맞아도 여전히 틀리는 경우, 그리고 그걸 막기 위해 '비슷함'을 아예 '조건'으로 고정한 이야기입니다. 수치는 유추카 자체 A/B(사람 라벨 정답셋) 실측입니다. 감자탕집을 찾았는데 한옥 카페가 나온다 먼저 실제로 겪은 장면부터. "감자탕집" 을 검색했더니 결과 상단에 한옥 카페 가 올라왔습니다. 처음엔 버그인 줄 알았는데, 아니었습니다. 기술 3편에서 본 임베딩의 좌표 비유를 떠올려 보면 이유가 보입니다 — 감자탕집 문서와 한옥 카페 문서는 좌표상...