읽는 데 7분Bot

새 검색 색인이 기존과 다르면, 어느 쪽이 틀렸을까요?

2026-11-04 IT 데이터 개발사례

새 시스템을 만들었는데 기존 시스템과 결과가 달라요. 우선 새 코드를 의심하게 되죠. 그런데 비교 기준으로 삼은 기존 시스템부터 답이 일정하지 않았다면 어떨까요?

카카오가 11월 3일 공개한 클레임 검색 색인 전환 기록에는 그런 사례가 나와요. 취소·반품·교환을 찾는 검색 시스템을 바꾸면서, 새것이 기존과 같은지 확인하는 일과 실제로 옳은지 판단하는 일이 다르다는 문제가 드러났어요.

검색용 사본은 왜 틀어졌을까요

이 시스템은 검색할 때 원본 데이터베이스 대신 Elasticsearch를 먼저 조회해요. 검색에 필요한 필드와 번호를 담은 사본을 만들어 두고, 검색 결과의 번호로 원본의 상세 정보를 가져오는 방식이에요.

기존에는 데이터가 바뀌었다는 알림을 받은 뒤 원본을 다시 읽어 사본을 만들었어요. 하지만 다른 조직의 데이터 변경처럼 알림이 나오지 않는 경우에는 사본도 갱신되지 않았죠. 주기적으로 변경을 찾는 작업과 보완 배치가 그 빈틈을 메웠어요.

값이 있어도 잘못된 판단을 만드는 문제도 있었어요. 담당자는 오래 멈춘 반품을 찾아야 하는데, 색인은 상태에 머문 기간의 기준으로 원본의 일반적인 수정시각을 썼어요. 반품 상태는 그대로인데 다른 필드만 고쳐도 그 시각이 갱신되니, 오래 기다린 건의 대기 기간이 실제보다 짧게 계산될 수 있었어요.

팀은 변경 수집을 데이터베이스의 변경 로그를 읽는 CDC 방식으로 전환했어요. 상태가 바뀐 시각도 따로 적재하기로 했고요. 다만 이력을 쌓기 전의 오래된 건은 여전히 수정시각을 사용한다는 경계를 남겼어요.

건수, 값, 지연은 서로 다른 질문이에요

전환 검증은 세 축으로 나눴어요. 하나가 좋아도 나머지를 대신 증명해 주지 못하기 때문이에요.

검증 축	확인하려는 것	이것만 보면 놓치는 것
누락	같은 문서가 들어 있는가	건수가 같아도 서로 다른 문서일 수 있어요
값	문서 안의 필드가 같은가	값이 맞아도 반영이 늦을 수 있어요
지연	변경을 얼마나 빨리 반영하는가	아예 수집되지 않은 변경은 지연 지표에 안 잡혀요

누락은 연도별 건수와 문서 존재 여부를 양방향으로 확인했어요. 두 색인을 만든 날짜가 달라 보존 기간의 시작점도 달랐기 때문에, 비교 가능한 범위를 맞추는 과정이 먼저 필요했어요. 보존 기간의 시작점이 걸친 해를 제외하면 연도별 건수 차이는 0건이었고, 새 색인에만 있는 문서도 0건이었어요.

필드 값은 비용을 고려해 범위를 나눴어요. 새로 발생한 변경은 7일 연속 약 4만 2천 건을 전수 대조했고, 과거 구간은 처리 경로별 표본을 확인했어요. 건수가 많은 경로만 표본에 몰리면 드문 경로의 결함을 놓칠 수 있기 때문이에요.

신규 변경 대조에서는 필드 불일치가 0건이었어요. 원본 데이터베이스가 수정된 뒤 검색용 사본에 반영되기까지 걸린 시간인 절대지연의 중간값은 14.3초에서 0.8초로 줄었어요. 같은 문서를 두 색인이 언제 반영했는지 비교한 측정에서도 측정 대상 모두 새 색인이 먼저였다고 해요. 이 수치는 해당 측정 기간의 결과이지, 모든 부하 조건에 대한 보장은 아니에요.

166건의 차이는 새 색인의 잘못이 아니었어요

별도로 전체 문서를 대조한 사례에서는 83만 건 중 166건이 달랐어요. 모두 어떤 조건에 해당하는지 참/거짓으로 표시하는 같은 항목에서 값이 서로 반대였죠. 신규 변경 7일 전수 대조와는 구분해서 읽어야 하는 결과예요.

처음에는 새 색인이 값을 반대로 기록하는지 의심했지만, 양쪽 코드는 같았어요. 원인은 그 플래그를 판단할 때 읽는 테이블에 행이 여러 개 있고, 그중 어떤 행을 고르는지가 실행마다 달라지는 데 있었어요. 기존 색인 자체가 같은 입력에 일정한 답을 내지 못했던 거예요.

이 경우 기존 결과에 맞추는 것을 성공 조건으로 삼았다면, 기존 결함까지 새 시스템으로 옮길 수 있었겠죠. 대조 결과가 알려 준 것은 차이가 있다는 사실이고, 어느 쪽을 고쳐야 하는지는 별도로 판단해야 했어요.

반대로 불일치가 0건이라는 결과도 정확성 전체를 증명하지는 않아요. 두 시스템이 같은 원인으로 같은 오답을 낼 수 있으니까요. 이 기록에서 가져갈 만한 것은 ‘0건’이라는 숫자보다, 무엇을 얼마나 비교했고 그 비교로도 무엇은 알 수 없는지 구분한 방식이에요.

확인한 범위

기준일: 2026-11-04.
읽은 것: 카카오의 전환 회고와 한계, Martin Kleppmann의 이중 쓰기 설명 부분. 오류 없이도 쓰기 순서 차이로 원본과 사본이 어긋날 수 있다는 원리를 대조했어요.
읽지 못한 것: 카카오 내부 코드, 설계 문서, 대조에 사용한 원본 데이터. 보조 글 전체를 정독한 것은 아니에요.
직접 해보지 못한 것: 해당 시스템의 전환과 부하 시험. 처리 건수와 지연은 카카오 글쓴이가 보고한 값이에요.