클레임 검색 색인의 CDC 전환과 검증 기록

요약

커머스 클레임(취소·교환·반품) 검색 색인의 변경 수집 방식을 변경 알림 기반에서 데이터베이스 변경 로그 기반, 즉 CDC로 전환했습니다. 기존 구조에서는 알림이 발행되지 않은 변경이 색인에 반영되지 않았고, 건의 체류 시간을 계산하는 기준시각이 무관한 필드 수정에 갱신되는 문제가 있었습니다.

전환보다 어려웠던 작업은 새 색인이 맞다는 것을 보이는 일이었습니다. 누락·값·지연 세 축으로 대조한 결과, 보존 기간 시작점이 걸친 해를 제외한 연도별 건수 차이 0건과 새 색인에만 있는 문서 0건, 신규 변경 7일 연속 전수 약 4만 2천 건에서 필드 불일치 0건, 절대지연 중간값 14.3초에서 0.8초를 확인했습니다. 전수 대조 과정에서는 기존 색인이 동일 입력에 대해 서로 다른 값을 만들어 내던 결함이 드러났고, 전환 이후에는 전체 색인 배치가 원본 데이터베이스에 가하던 부하를 발견해 조치했습니다.

1. 배경과 문제 정의

1.1 대상 시스템

주문·취소·반품·교환이 발생하면 해당 건은 담당자가 찾아서 처리해야 합니다. 담당자는 이 화면에서 하루 수만 건을 조회하고 처리합니다. 처리가 밀린 건을 먼저 확인하는데, 반품 요청 상태로 사흘 넘게 멈춰 있는 건을 찾는 작업이 그 예입니다. 상태로 거르고 기간으로 좁힌 다음 한 건을 번호로 열어 보는 흐름이며, 문서 하나에 담기는 필드는 40개가 넘습니다.

검색은 원본을 직접 조회하지 않습니다. Elasticsearch에 먼저 질의하고, 색인에는 검색에 사용하는 필드와 번호만 담아 두었다가 반환된 번호로 원본에서 상세를 읽어 화면에 표시합니다. 원본에서 검색하려면 테이블을 여러 개 결합해야 하고 그 비용이 그대로 원본에 쌓이기 때문에, 2019년 if(kakao)에서 소개한 검색 시스템이 이 구조이며, 검색은 검색 엔진이, 상세 조회는 원본이 담당하도록 분리했습니다. 이 글에서 색인이라고 할 때는 검색용으로 따로 만든 이 사본을 가리키며, 문서 한 건은 취소·반품·교환 한 건에 해당합니다.

사본은 원본과 어긋날 수 있습니다. 색인이 어긋나면 화면이 어긋나고, 그 화면을 근거로 내리는 판단까지 어긋납니다. 화면이 느려지거나 값이 틀리는 일은 그 자체로 장애에 해당합니다.

그림 1. 전환 전 색인 구조. 원본 변경이 세 갈래 알림 경로를 거쳐 색인에 반영됩니다.

1.2 세 가지 실패와 그 원인

전환 전 구조는 원본에 변경이 생기면 알림이 발행되고, 그 알림을 받아 원본을 다시 읽어 문서를 만드는 방식이었습니다. 문서 하나를 구성하려면 17개가 넘는 테이블을 조회해야 합니다. 변경 알림 기반 구조에는 세 가지 문제가 있었습니다.

첫째는 누락입니다. 알림이 발행되지 않은 변경은 색인이 인지할 방법이 없어 그대로 반영되지 않았습니다.

둘째는 기준시각 오염입니다. 건이 특정 상태에 머문 기간을 계산하는 시각이 무관한 수정에 갱신되면서, 값이 비는 대신 실제보다 짧은 기간으로 계산되었습니다.

셋째는 전량 재구성입니다. 변경된 필드를 알 수 없으므로 알림마다 문서 전체를 다시 만들어야 했습니다.

변경을 알리는 경로는 세 갈래였습니다. 서비스가 상태를 변경할 때 직접 발행하는 알림이 첫 번째이지만, 다른 조직의 데이터가 변경되는 경우에는 알림이 발행되지 않습니다. 그래서 5초마다 해당 테이블의 변경 감지 컬럼(update_ts)을 읽어 알림을 대신 생성하는 잡을 두었습니다. 어느 필드가 변경되어도 데이터베이스가 자동으로 갱신하는 컬럼이며, 폴링을 위해 둔 장치입니다. 그럼에도 누락되는 구간이 남아 12시간마다 실행되는 보완 배치를 실시간 처리 과정 안에 함께 두었고, 필요하면 수동으로도 실행했습니다.

경로	주기	한계
서비스가 직접 발행하는 알림	상태 변경 시점	다른 조직의 데이터 변경은 발행되지 않음
update_ts 폴링 잡	5초	주기 사이의 중간 상태를 보지 못함
보완 배치	12시간 (수동 실행 가능)	실시간 처리 과정 안에 포함되어 있었음

표 1. 전환 전 변경 알림 경로

문제는 경로의 개수가 아니라 책임의 위치에 있었습니다. 원본을 변경하는 작업과 변경을 알리는 작업이 하나의 트랜잭션으로 묶여 있지 않으면 사본이 어긋나는 길이 두 가지 생깁니다. 하나는 둘 중 한쪽만 성공해서 알림이 유실되는 경우이고, 다른 하나는 둘 다 성공했는데도 어긋나는 경우입니다. 같은 데이터를 고치는 두 작업이 원본과 사본에 서로 다른 순서로 도착하면, 양쪽에 다른 값이 남고 누군가 그 값을 다시 덮어쓸 때까지 그대로 유지됩니다. Martin Kleppmann은 이러한 구조를 이중 쓰기(dual write)라고 부릅니다. 순서가 뒤집혀 어긋나는 쪽은 실패한 작업이 없어 오류도 기록되지 않기 때문에, 어긋났다는 사실 자체가 한동안 드러나지 않습니다 [1]. 직접 발행에서 누락된 변경을 폴링과 보완 배치로 보충하는 구조였습니다. 알림 경로를 늘리는 방식으로는 발행 자체가 일어나지 않는 경우를 막을 수 없습니다.

알림에는 시각과 번호만 담았습니다. 값을 함께 전달하면 원본을 다시 읽지 않아도 되지만, 알림 순서가 역전되면 과거 값이 최신 값을 덮을 수 있고 재처리 과정에서 일시적으로 과거 상태가 노출될 수 있습니다. 번호만 전달하면 도착 순서와 무관하게 마지막 상태가 남습니다. 값 없이 식별자만 전달하는 이 방식을 제로 페이로드라고 하며, 그 대가는 알림마다 17개가 넘는 테이블을 다시 조회하는 비용이었습니다.

기준시각 오염의 원인은 더 단순합니다. 기준시각을 원본의 수정시각(modified_at)에서 가져왔기 때문입니다. 반품 요청이 접수된 지 9일째인 건에서 귀책이 판매자인지 구매자인지만 변경해도 기준시각이 변경 시점으로 갱신되어 체류 기간이 하루로 계산되고, 사흘 넘게 멈춘 건을 거르는 목록에서 그 건은 제외됩니다. 클레임 서비스가 잘못 동작한 것은 아닙니다. 어느 필드가 변경되어도 갱신한다는 것이 해당 컬럼의 정의이고, 그 값을 아무 조건 없이 기준시각으로 사용한 색인 쪽에 결함이 있었습니다.

그림 2. 기준시각 오염. 접수 9일 차에 무관한 필드를 수정하면 체류 기간이 1일로 계산됩니다.

2. 설계

2.1 변경 수집 방식의 선택

설계를 변경하더라도 변경을 알리는 역할은 어딘가 남습니다. 일반적으로는 발행 경로를 보강하거나, 아웃박스처럼 변경과 이벤트를 같은 트랜잭션에 묶거나, 데이터베이스가 이미 기록하는 변경 로그를 직접 읽는 방법을 생각할 수 있습니다.

앞의 두 방법은 발행 책임을 서비스에 남깁니다. 반면 복제를 위해 데이터베이스가 원래부터 기록하는 로그를 읽으면 알림을 발행할 주체가 필요하지 않습니다. 커밋된 변경은 반드시 로그에 남으므로, 알림 누락으로 발생하는 반영 누락 경로가 사라집니다. CDC는 이 로그를 읽어 변경을 수집하는 방식입니다.

새로운 선택지는 아니었습니다. 2019년 발표에도 검토 기록이 남아 있으나, 당시에는 새로운 기술 스택과 전담 지원이 필요해 운영 부담이 크다고 판단해 보류했습니다. 6년이 지나 그 부담을 감당할 수 있게 된 시점에 실행했습니다.

2.2 네 갈래 처리 경로

검색용 색인의 형태는 유지하면서 변경 수집만 CDC로 바꾸었고, 처리 과정은 넷으로 다시 구성했습니다. 실시간 처리는 둘로 나뉩니다. 클레임이 새로 생성될 때 문서 전체를 만드는 생성 파이프라인과, 이후 변경에서 변경된 필드만 수정하는 갱신 파이프라인입니다. 생성은 드물고 변경은 잦아 비용 구조가 다르기 때문입니다. 세 번째로 보완 배치를 실시간 처리에서 분리해 누락 구간을 메우는 용도로만 두었고, 네 번째로 전체 색인 배치를 최초 구축과 재구축에 사용합니다. 네 경로의 처리 로직은 다르지만 문서를 구성하는 코드는 Spark 위에서 공유합니다.

경로	계기	문서 처리 범위	용도
생성 파이프라인	클레임 생성	문서 전체	신규 건 색인
갱신 파이프라인	이후 변경	변경된 필드	잦은 변경의 반영
보완 배치	주기 실행	문서 전체	실시간에서 누락된 구간 보충
전체 색인 배치	수동·정기 실행	문서 전체	최초 구축과 재구축

표 2. 전환 후 네 갈래 처리 경로

전체 색인 배치를 따로 두어야 하는 이유는 CDC의 성질에서 나옵니다. Netflix의 DBLog 논문은 트랜잭션 로그가 변경의 전체 이력을 담고 있지 않으므로 로그만으로는 데이터베이스의 전체 상태를 복제할 수 없고, 전체 상태를 가져오는 경로가 별도로 필요하다고 설명합니다. DBLog는 테이블을 청크로 나누어 읽으면서 그 구간을 워터마크로 감싸 로그 이벤트와 겹치는 행을 제거하는 방식으로, 잠금 없이 두 경로를 동시에 진행합니다 [2]. Debezium의 증분 스냅샷도 같은 기법을 사용합니다.

그림 3. 전환 후 색인 구조. 변경 로그를 읽는 CDC가 알림 경로를 대체하고, 처리가 네 갈래로 나뉩니다.

2.3 기준시각과 도착 순서의 처리

색인은 해당 건이 특정 상태에 머문 기간을 알아야 합니다. 담당자가 그 값으로 거르기 때문입니다. 원본에는 현재 상태만 있고 상태가 변경된 시점에 대한 이력이 없어, 상태 변경 시점만 따로 적재하기로 했습니다.

상태 변경 기록이 있는 구간에서는 기준시각을 해당 기록에서만 산정합니다. 다른 필드가 변경되어도 기준시각은 영향을 받지 않습니다. 기록 적재를 시작한 시점보다 오래된 건에는 이력이 없어 수정시각을 그대로 사용하되, 정확한 구간과 그렇지 않은 구간의 경계를 설계 문서에 남겼습니다.

로그 자체는 커밋 순서대로 기록되고 CDC가 읽는 순서도 같습니다. 다만 로그는 소스별로 여러 토픽에 실리고 토픽은 다시 여러 파티션으로 나뉘므로, 순서가 보장되는 범위는 파티션 하나입니다.

파티션 키는 원본 행이고 색인 문서는 클레임 단위여서, 한 문서를 구성하는 변경들이 여러 파티션에 분산됩니다. 분산된 변경 사이에는 순서가 없습니다. 처리에 실패한 건은 10초 간격으로 재시도하므로, 그 사이에 이후 변경이 먼저 반영되기도 합니다.

일반적인 해법은 순서를 복원하는 것이지만, 설계에서는 도착 순서를 맞추는 대신 순서가 달라도 같은 결과로 수렴하도록 처리했습니다. 생성보다 갱신이 먼저 도착하면 대상 문서가 색인에 없으므로 갱신은 아무 작업도 수행하지 않고 종료합니다. 이후 도착한 생성이 원본에서 문서 전체를 읽으면서 최신 값이 반영됩니다. 갱신끼리 역전된 경우에는 색인에 기록해 둔 반영 기준 시각과 이번 이벤트의 시각을 비교해, 기록된 쪽이 더 나중이면 해당 갱신을 건너뜁니다. 1.2의 체류 기간 기준시각과는 다른 값으로, 이벤트의 선후를 가리기 위해 색인에 함께 저장하는 값입니다.

그림 4. 역전된 이벤트의 처리. 생성보다 빠른 갱신과 갱신 간 역전이 각각 어떻게 수렴하는지 나타냅니다.

3. 검증 방법

3.1 검증 축과 대조 범위

설계가 맞다고 해서 설계대로 동작한다는 보장은 없고, 한 가지 지표만으로는 판단할 수 없습니다. 검증 대상을 누락, 값, 지연 세 축으로 나눈 것은 각 지표의 검증 범위가 서로 다르기 때문입니다. 문서 수가 같아도 내부 값이 다를 수 있고, 값이 같아도 반영이 늦으면 화면은 과거 상태를 보여 줍니다. 반대로 지연이 짧아도 애초에 수집되지 않은 변경은 지연 지표에 나타나지 않습니다.

세 지표는 서로의 사각을 보완하는 관계이므로 하나라도 빠지면 나머지 둘의 결론이 약해집니다. 전환 여부는 세 축을 함께 보고 판단했습니다.

수천만 건의 값을 매일 대조하기는 어렵기 때문에 대상에 따라 범위를 달리 잡았습니다. 모든 확인이 같은 비용으로 수행되지는 않기 때문입니다. 문서 건수는 집계로 전체를 확인했습니다. 문서를 열지 않으므로 문서별 필드 대조보다 비용이 낮아 범위를 좁힐 이유가 없었습니다. 반면 값 대조는 양쪽에서 문서를 꺼내 필드 단위로 비교해야 하므로 건당 비용이 큽니다.

그래서 비용이 낮은 축은 전수로, 비용이 높은 축은 대상을 나누어 확인했습니다. 더 이상 변경이 발생하지 않는 과거 구간은 경로별 표본으로, 관측 기간에 새로 발생하는 변경은 전수로 대조했습니다. 과거 구간은 상태가 고정되어 있고, 새로 발생하는 변경은 코드가 동작하는 동안 계속 만들어지는 결과이기 때문입니다.

대조	대상과 범위	방식
문서 건수	전체	연도별 집계 비교
문서 존재 여부	비교 가능한 공통 범위	양방향 확인
신규 변경의 값	7일간 약 4만 2천 건	전수 필드 대조
과거 구간의 값	유입 경로별 표본	필드 대조

표 3. 대조 대상과 범위

과거 구간의 표본은 유입 경로별로 나누어 추출했습니다. 생성과 갱신, 보완 배치, 전체 색인 배치는 처리 로직이 다르고 결함이 생기는 방식도 다르기 때문입니다. 경로를 구분하지 않으면 건수가 많은 경로가 표본을 차지하고 건수가 적은 경로는 포함되지 않을 수 있습니다.

신규 변경은 7일 연속으로 매일 전수 대조했습니다. 하루치 대조로는 그날 발생한 상태 전이와 유입 경로의 조합만 확인할 수 있고, 관측 기간에 한 번도 나타나지 않은 상태 전이는 어느 쪽에도 포함되지 않습니다.

누락은 건수로 먼저 확인했습니다. 다만 건수가 같아도 구성하는 문서가 다를 수 있으므로, 건수 비교만으로는 누락이 없다고 말할 수 없습니다.

그래서 연도별로 나누어 확인하고, 방향도 양쪽으로 확인했습니다. 기존 색인에 있고 새 색인에 없는 문서뿐 아니라 새 색인에 있고 기존 색인에 없는 문서까지 확인해야 두 색인이 같은 문서를 담고 있다고 말할 수 있습니다.

3.2 지연 측정의 정의

절대지연은 원본 데이터베이스의 수정시각부터 색인에 반영된 시각까지입니다. 검색 결과가 원본의 변경을 반영하기까지 걸리는 시간에 해당합니다.

상대지연은 같은 문서를 두 색인이 각각 언제 반영했는지를 비교한 값입니다. 절대지연만 보면 해당 기간의 트래픽 조건이 수치에 영향을 주었을 가능성을 배제하기 어렵습니다. 같은 문서를 두 색인이 각각 언제 반영했는지를 비교하면 두 색인 사이의 선후를 직접 확인할 수 있습니다.

3.3 차이의 해석과 자동화 범위

대조에서 차이가 나왔다고 해서 새 색인이 틀렸다고 볼 수는 없습니다. 차이는 대조 방법에서 생길 수도, 기존 색인에서 생길 수도, 새 색인에서 생길 수도 있기 때문입니다.

대조 방법이 잘못된 상태에서 새 색인을 수정하면 정상 코드를 잘못 고치게 되고, 기존 색인을 정답으로 전제하면 기존 결함을 그대로 복제하게 됩니다. 4장에서 다루는 두 건의 차이가 각각 앞의 두 경우에 해당했습니다.

7일 연속 전수 대조는 사람이 매일 수행하지 않았습니다. 반복되는 대조 실행과 집계 결과 정리는 에이전트가 수행했고, 어느 쪽이 맞는지 판정하는 작업과 무엇을 포기할지 결정하는 작업은 사람이 수행했습니다. 이 경계를 어떤 기준으로 그었는지는 6장에서 다룹니다.

4. 결과

4.1 누락과 값

문서 수를 비교한 결과 두 색인의 숫자는 비슷했으나 같지는 않았습니다. 차이의 원인은 전체 색인이 보존하는 기간에 있었습니다. 전체 색인은 실행 시점을 기준으로 최근 몇 년 치만 보존하는데, 두 색인을 서로 다른 날에 생성했기 때문에 보존 기간의 시작점이 달랐습니다. 비교 범위를 맞추지 않으면 이 차이는 계속 남습니다.

연도별로 나누어 다시 집계한 결과, 차이는 보존 기간의 시작점이 걸친 해에만 나타났고 이후 연도는 전부 0이었습니다. 반대 방향으로 확인한 결과, 새 색인에만 있고 기존 색인에 없는 문서도 0건이었습니다.

관측 기간에 새로 발생한 변경은 7일 연속으로 전수 대조했습니다. 약 4만 2천 건이었고 필드 단위 불일치는 0건이었습니다. 과거 구간은 경로별 표본으로 확인했습니다.

이 대조가 확인해 주는 범위는 다음으로 한정됩니다. 7일 동안 신규로 발생한 변경에 대해서는 두 색인이 필드 단위로 같은 값을 산출했고, 전수였기 때문에 추출되지 않아 확인하지 못한 건은 이 구간에 없습니다. 다만 두 색인이 일치한다는 것이 두 색인이 모두 옳다는 뜻은 아닙니다. 양쪽이 같은 원인으로 같은 잘못된 값을 산출할 가능성은 이 대조로 배제되지 않습니다.

4.2 지연과 전환 판정

절대지연 중간값은 14.3초에서 0.8초로 약 18배 줄었습니다. 상대지연 비교에서도 측정 대상 전체에서 새 색인이 먼저 반영되었습니다. 두 지표가 같은 방향을 가리킨 결과입니다.

세 축의 결과를 모으면 다음과 같습니다.

검증 축	확인 범위	결과
누락	연도별 건수 + 양방향 확인	보존 기간 시작점이 걸친 해를 제외하고 차이 0, 역방향 0건
값	신규 변경 7일 연속 전수 약 4.2만 건, 과거 구간은 경로별 표본	불일치 0건
지연	절대지연 중간값, 상대지연 측정 대상 비교	14.3초 → 0.8초(약 18배), 상대지연은 측정 대상 전부에서 새 색인 선행

표 4. 전환 판정 결과

세 축 모두 기준을 충족해 전환을 결정했습니다.

4.3 전수 대조에서 드러난 기존 색인의 결함

전환 판정에 사용한 값 대조는 신규 변경 7일 전수와 과거 구간의 경로별 표본이었습니다. 두 색인의 전체 문서를 대조한 사례에서는 83만 건 중 166건이 달랐습니다. 불일치는 모두 동일한 플래그의 값이 반대인 경우였습니다. 차이가 한 항목에 모여 있다는 점에서 우연한 불일치가 아니라 특정 로직의 문제로 보였습니다.

처음에는 새 색인이 값을 반대로 기록하는 것은 아닌지 의심해 코드를 확인했습니다. 그러나 양쪽 코드가 같았습니다.

설계를 확인한 결과, 해당 플래그를 판정할 때 읽는 테이블에 행이 여러 개 있었고 그중 어느 행이 선택되는지가 실행마다 달라졌습니다. 새 색인과의 불일치에 그치지 않고, 기존 색인 자체가 같은 입력에서 일관된 값을 내지 못하는 상태였습니다.

전수 대조에서 확인한 불일치 166건은 전체 83만 건의 0.02%에 해당합니다.

5. 전환 후 운영 관찰

5.1 원본 데이터베이스 부하

전체 색인은 서비스 트래픽에 영향을 주지 않도록 매일 복사하는 HDFS 사본을 읽되, 사본에 포함되지 않는 개인정보만 원본 데이터베이스에서 조회합니다. 전환 이후 이 조회가 원본 데이터베이스에 한계 수준의 부하를 발생시켰습니다.

조회 과정이 단순하다고 이해하고 있었던 탓에 원인을 확인하기까지 시간이 걸렸습니다. DBA 확인 결과 초당 질의수 자체는 감당할 수 있는 수준이었고, 문제는 배치 한 회에 발생하는 질의 총량이었습니다. 고정비용이 약 8만 번 발생하고 있었습니다.

5.2 조치와 효과

첫째, 묶음 크기가 약 200건이었고 이 값이 코드에 고정되어 있어 운영 중에 변경할 수 없었습니다. 설정으로 분리하고 5,000으로 조정했습니다.

둘째, 조회 대상의 규모가 가장 큰 요인이었습니다. 원본에서 읽어 오는 개인정보의 단위와 실제 처리 단위가 달랐기 때문입니다. 상자 하나에 상품이 다섯 개 포함되어 있으면 그 상자의 수령인을 다섯 번 조회하는 구조였고, 중복 조회는 평균 45회였습니다. 1,643만 건을 조회했으나 실제 대상은 36만 6천 건이었습니다. 배송 단위로 묶어 한 번만 조회하도록 수정했습니다.

그림 5. 조회 단위와 처리 단위의 불일치. 상자 한 건의 수령인을 상품 수만큼 반복 조회하던 구조입니다.

묶음 크기 25배와 중복 제거 45배가 함께 적용되어 질의 수가 약 1,100배 감소했습니다. 약 8만 2천 번이던 질의가 74회로 줄었습니다.

셋째, 조회 속도 제한은 일부 단계에만 적용되어 있었고 실행 단위마다 개별로 걸려 있어 병렬도를 올리면 부하도 함께 증가했습니다. 초당 읽을 수 있는 행 수를 배치 전체의 총량으로 정하고 실행 단위들이 그 안에서 나누어 쓰도록 변경했습니다.

조치 이후 배치 처리의 CPU 사용량은 45% 감소했고, 소요시간은 12.9분에서 11.6분으로 단축되었습니다.

항목	조치 전	조치 후
묶음 크기	200건 (코드에 고정)	5,000건 (설정)
조회 대상	1,643만 건	36만 6천 건
질의 수	82,171회	74회
속도 제한	일부 단계, 실행 단위별	배치 전체 총량 기준
CPU 사용량	기준	45% 감소
소요시간	12.9분	11.6분

표 5. 전체 색인 배치 조치 전후

6. 자동화 범위와 판단 책임

6.1 검증 가능성에 따른 위임 범위

위임 기준은 작업의 난이도가 아니라 검증 가능성이었습니다. 어려운 작업과 쉬운 작업으로 나누는 대신, 결과가 틀렸을 때 그 사실을 확인할 수 있는 작업과 확인할 수 없는 작업으로 나누었습니다.

이 기준에서 위임 범위를 정하는 것은 모델의 성능보다 우리가 가진 검증 수단입니다. 검증 수단이 없는 영역은 위임 대상에서 제외했습니다.

같은 관점이 최근 하네스 엔지니어링이라는 이름으로 정리되고 있습니다. 모델을 제외한 나머지 전부, 즉 에이전트의 행동을 미리 제약하는 장치와 결과를 되돌려 주는 장치가 결과를 좌우한다는 논의입니다 [3]. 이 작업에서 그 역할을 한 것은 테스트, 사실과 일치하는 설계서, 그리고 대조 스크립트였습니다.

테스트로 결과를 확인할 수 있는 범위에서 코드 작성을 위임했습니다. 검증을 진행하는 동안 테스트는 19건에서 32건으로 늘었습니다. 검증 환경에서 문제를 발견할 때마다 하나씩 추가한 결과입니다.

설계서는 교차 검증으로 확인했습니다. 설계서에 적혀 있으나 실제로는 존재하지 않는 설정이 확인되면 설계서를 수정하며 진행했습니다. 설계서를 검증 기준으로 사용하려면 설계서부터 사실과 일치해야 하기 때문입니다.

다만 테스트를 작성하게 한다고 해서 품질이 보장되지는 않습니다. 실제 코드에서 추출한 함수 3,909개로 구성한 벤치마크에서, 모델이 생성한 테스트가 주입된 결함을 잡아낸 비율은 평균 40.21%에 머물렀습니다 [4]. 실행에 성공한 테스트도 틀린 동작을 놓칠 수 있습니다. 에이전트에게 TDD를 지시한 경우와 지시하지 않은 경우를 나누어 비교한 실험 보고에서도, 지시만으로 결과가 개선되지는 않았습니다 [5]. 이 작업에서 작동한 것은 테스트의 존재 자체가 아니라, 테스트로 결과를 확인할 수 있는 작업에 한해 위임한다는 기준이었습니다.

6.2 검사 가능한 지시로의 재정의

“정리해 줘”와 같은 지시는 결과를 그대로 신뢰하는 것 외에 확인할 방법이 마땅치 않습니다. 같은 작업을 “이 기준으로 집계해 연도별로 나누고 0이 아닌 행만 남겨라”로 바꾸면 결과를 검사하고 수정할 수 있습니다.

이는 프롬프트 작성 기법보다 위임하려는 작업을 검사 가능한 형태로 다시 정의하는 데 달려 있습니다. 3장에서 정한 대조 설계가 이미 그 형태였습니다. 무엇을 집계하고 어떻게 나누며 어떤 행이 남아야 하는지가 정의되어 있으면, 그 작업은 위임 대상이 됩니다.

Simon Willison은 에이전트를 활용하는 작업을 도구와 루프를 설계하는 작업으로 규정합니다 [6]. 이 관점에서 지시를 다시 정의하는 일은 요령이라기보다 설계에 가깝고, 반복 가능한 형태로 정의한 대조 작업이 그 루프에 해당합니다.

6.3 위임하지 않은 판단과 성과 지표

4.3의 166건이 그 경계를 보여 줍니다. 전수 대조를 위임해 얻은 결과는 83만 건 중 166건이 다르고 불일치가 모두 같은 플래그에 몰려 있다는 사실이었습니다.

대조 결과를 두고 어느 쪽에 결함이 있는지 판단한 것은 사람이었습니다. 코드를 의심할지 설계를 의심할지, 무엇을 포기할지도 같습니다. 결론은 기존 색인의 로직에 문제가 있다는 것이었고, 반대로 판단했다면 그 로직을 새 색인에 그대로 옮겼을 것입니다.

결과를 검증할 수 없는 작업을 위임하면 부담은 사라지지 않고 검토 단계로 이동합니다. 구글의 Addy Osmani는 AI로 속도를 올린 결과 더 많은 코드가 리뷰로 넘어오면서 코드 리뷰가 새로운 병목이 되고 있고, 그 리뷰를 맡을 선임 엔지니어의 수는 한정되어 있다고 지적합니다 [7]. 위임 경계를 어디에 둘지는 결국 검토 비용으로 결정됩니다.

작업이 얼마나 빨라졌는지는 성과 지표로 사용하지 않았습니다. 검증되는 작업에만 위임했기 때문에 되짚는 비용이 늘지 않았다는 점을 성과로 봅니다.

속도를 성과로 기록할 때의 위험을 보여 주는 보고도 있습니다. METR이 숙련 오픈소스 개발자를 대상으로 수행한 무작위 대조 실험에서, 참가자들은 AI 도구로 20% 빨라졌다고 응답했으나 실제 수행 시간은 19% 증가했습니다 [8]. 이 실험은 2025년 초의 도구를 대상으로 한 것이고, METR은 2026년 2월에 개발자들이 그때보다 더 빨라졌을 것으로 본다는 후속 보고를 냈습니다. 다만 같은 후속 보고에서도 개발자의 자기 보고 속도향상은 신뢰하기 어렵다는 관찰은 유지됩니다. 이 절에서 참고한 것은 속도의 크기가 아니라 체감과 실측이 어긋날 수 있다는 점입니다.

7. 한계

값 대조에서 신규 변경은 7일 연속 전수로, 과거 구간은 경로별 표본으로 확인했습니다. 과거의 비표본 구간과 관측 기간에 나타나지 않은 상태 전이는 확인하지 못했습니다.

두 색인의 값이 일치한다는 결과는 양쪽이 같은 원인으로 같은 잘못된 값을 산출할 가능성까지 배제하지 않습니다.

기준시각은 상태 변경 이력을 적재하기 시작한 시점 이후 구간에서만 이력을 근거로 산정됩니다. 그 이전 구간은 수정시각을 사용합니다.

지연 수치는 측정 기간의 조건에서 얻은 값입니다.

6장의 논의는 하나의 사례에서 얻은 관찰이며 통제된 비교가 아닙니다.

8. 결론

변경 수집을 CDC로 전환하고 보완 배치를 실시간 처리에서 분리했습니다. 알림이 발행되지 않아 반영되지 않는 경로가 사라졌고, 누락을 메우기 위해 운영하던 장치들의 역할은 실시간 경로 밖으로 옮겨졌습니다.

상태 변경 이력이 있는 구간에서는 기준시각을 해당 이력으로 산정하도록 변경했습니다. 그 구간에서는 상태별 체류 기간 집계를 근거로 사용할 수 있습니다.

옮기는 작업보다 증명하는 작업이 어려웠습니다. 그 과정에서 색인과 함께 검증 절차가 남았습니다. 신뢰는 옳다는 선언이 아니라 틀렸을 때 그것을 확인할 수 있는 절차에서 나옵니다.

참고 문헌

[1] Using logs to build a solid data infrastructure (or: why dual writes are a bad idea) / Martin Kleppmann / https://martin.kleppmann.com/2015/05/27/logs-for-data-infrastructure.html

[2] DBLog: A Watermark Based Change-Data-Capture Framework / Andreas Andreakis, Ioannis Papapanagiotou (Netflix) / https://arxiv.org/abs/2010.12597

[3] Harness engineering for coding agent users / Birgitta Böckeler / https://martinfowler.com/articles/harness-engineering.html

[4] Benchmarking LLMs for Unit Test Generation from Real-World Functions / Dong Huang, Jie M. Zhang, Mark Harman 외 / https://arxiv.org/abs/2508.00408

[5] TDD inside the agent loop - theater or actual value? / Birgitta Böckeler / https://martinfowler.com/articles/exploring-gen-ai/tdd-in-the-agent-loop.html

[6] Designing agentic loops / Simon Willison / https://simonwillison.net/2025/Sep/30/designing-agentic-loops/

[7] Is AI Creating a New Code Review Bottleneck for Senior Engineers? / The New Stack / https://thenewstack.io/is-ai-creating-a-new-code-review-bottleneck-for-senior-engineers/

[8] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity / METR / https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ (후속: We are Changing our Developer Productivity Experiment Design / METR / 2026-02-24 / https://metr.org/blog/2026-02-24-uplift-update/)

옮기는 것보다 증명이 어렵다