KIM
DONGSUN

미션은 네이버에서 검색하기, 유튜브 채널 구독하기처럼 우리 앱 밖에서 일어납니다. 그런데 포인트를 주려면 실제로 했는지 판정해야 합니다. 판정 코드는 우리가 한 줄도 통제할 수 없는 남의 사이트 안에서 돌아야 했고, 그 사이트는 예고 없이 바뀝니다.

앱 전체와 판정 스크립트, 그리고 미션 유형을 늘리는 작업을 맡았습니다. 8개월 동안 7개 서비스 · 41개 미션 유형까지 넓혔습니다.

• class 대신 aria 속성으로 요소를 찾습니다. class 는 배포마다 난독화돼 이름이 바뀝니다. 접근성 속성은 화면 리더가 읽어야 해서 의미를 유지할 수밖에 없고, 실제로 훨씬 오래 살아남았습니다.
• 클릭이 아니라 상태 변화로 완료를 판정합니다. 클릭을 믿으면 눌렸지만 반영되지 않은 경우까지 지급됩니다. 구독 버튼이 "구독중"으로 바뀌는 것처럼 결과가 화면에 남는 지점을 기준으로 삼았습니다.
• 스토어 심사를 기다리지 않는 배포 경로를 따로 뒀습니다. 외부 사이트가 바뀌면 판정이 그날 깨지는데 심사는 며칠이 걸립니다. CodePush 서버를 직접 구성해 당일 배포하고, 문제가 생기면 이전 번들로 되돌립니다.

• 스크립트 예외가 호스트 페이지로 번지면 사용자는 남의 사이트가 고장 난 것으로 봅니다. 예외를 격리해 브릿지로 앱에만 전달하고, 화면에는 우리 안내만 남깁니다.
• 같은 미션도 대상 앱 설치 여부에 따라 앱으로 열지 웹으로 열지가 갈려, 분기 규칙을 URL Builder 로 추상화했습니다.
• PASS 본인인증은 앱이 imp_uid 만 서버로 넘겨, 주민번호·이름이 앱과 로그를 거치지 않습니다. ATT 를 거부해도 매체사 정산이 끊기지 않도록 식별 경로를 따로 뒀습니다.
• Jest 테스트 72개 — 미션 URL 판정, 유튜브 ID 추출, 가이드 HTML 정제. 마지막 변환기는 테스트와 함께 공개했습니다.

외부 사이트는 우리가 바꿀 수 없으니 판정이 깨지는 것 자체는 막을 수 없습니다. 할 수 있는 건 빨리 아는 것과 빨리 되돌리는 것뿐이라, 우리 쪽 로직은 Jest 72개로 고정하고 깨진 판정은 CodePush 로 당일 되돌립니다.

미션 유형이 41개까지 늘면서 판정 규칙이 스크립트 코드 안에 흩어졌습니다. 같은 문제를 오퍼월에서는 설정으로 분리해 풀었는데, 숏캐시 스크립트도 처음부터 그 구조였다면 새 유형을 붙이는 데 배포 자체가 필요 없었을 것입니다.

광고사마다 요구하는 미션 로직이 달랐습니다. 새 요청이 올 때마다 지면 코드에 분기를 더해 배포했고, 매체가 늘수록 분기도 같이 늘었습니다. 한 매체를 위한 수정이 다른 매체까지 위험하게 만드는 구조였습니다.

지면 프론트엔드 전부와 설정 스키마 설계, 전환 퍼널 집계를 맡았습니다.

• 매체별 코드 분기 대신 설정 기반으로 갈랐습니다. 분기를 유지하면 매체 수만큼 경우의 수가 곱해지고 매번 배포가 필요합니다. 바뀌는 것(미션 로직)과 고정된 것(화면 동작)을 나눠, 이후 미션 유형은 배포 없이 어드민에서 추가·변경합니다.
• 서버 상태 도구를 화면 수명에 맞춰 골랐습니다. 오퍼월은 WebView 로 열렸다 닫히는 단발성 세션이라 캐시를 길게 들고 있을 이유가 없어 SWR 을 썼고, 운영자가 종일 띄워 두는 어드민·마케팅몰에는 무효화 제어가 세밀한 TanStack Query 를 썼습니다.

• 어디서 이탈하는지 알 수 없어 상세보기 → 복사 → 시작 → 제출 → 완료 이벤트로 매체·카테고리별 퍼널을 집계했습니다. 아래 확인의 전환율 급감도 이 지표에서 찾았습니다.
• 이미 한 번 터졌던 검색어 인코딩, 지도 앱 미설치, 인덱스 범위 문제를 재현 테스트로 고정했습니다 — Vitest + RTL 49개.

설정으로 옮긴 뒤 무엇이 달라졌는지는 코드가 아니라 퍼널로 봤습니다. 그리고 그 퍼널을 붙이기 전에는 전환율이 떨어져도 떨어진 줄 몰랐습니다.

전체 전환율이 45%에서 15%까지 떨어진 구간이 있었는데, 매체별로 나누니 한 매체만 68%에서 7%였고 나머지는 그대로였습니다. 같은 기간 그 매체의 상세보기는 12배 늘었는데 완료는 그대로여서, 유입이 는 게 아니라 참여가 막혀 같은 목록을 반복 조회하는 상태로 봤습니다. 원인은 소진 여부를 판단하는 캐시를 자사 미션 조회 판정보다 먼저 확인하는 순서였습니다 — 노출돼야 할 미션이 차단되면서 재조회가 반복됐습니다. 판정 순서를 바꾸고 전체 조회가 비었을 때만 소진으로 기록하게 고쳐 66%로 회복, 3주간 유지됐습니다.

콜백 실패도 전환 실패로 세고 있었는데, 매체사 응답 코드로 나눠 보니 78.5%가 중복 참여였고 추적 ID 관련은 0건이었습니다. 실패로 세던 대부분이 정상 동작이었습니다 — 사유별 카운터로 갈라 적재해 진짜 장애와 섞이지 않게 했습니다.

퍼널 지표는 전환율이 깨진 뒤에 붙였습니다. 지금 새 지면을 붙인다면 지표를 먼저 붙이고 시작합니다. 매체사 연동의 preflight 건에서도 같은 걸 다시 배웠습니다 — 고치고 나서야 "before" 가 없다는 걸 알았습니다.

버즈빌은 매체사가 우리 API 를 호출해 캠페인을 가져가고, 퍼플페퍼는 우리가 상대 API 를 호출해 캠페인을 보냅니다. 방향이 반대라 실패의 모양도 반대였습니다. 그리고 어느 쪽이든 응답 필드 하나를 바꾸려면 상대 회사 개발자와 먼저 합의해야 했습니다 — 내 저장소만 고쳐서 끝나는 코드가 아니었습니다.

양쪽 방향의 API 스펙을 직접 정의하고, 연동 서버와 운영을 맡았습니다. 외부 개발자가 물고 있는 계약이라 하위호환을 기준으로 삼았습니다.

• 내보내는 쪽은 전량 재전송 대신 해시 비교로 갈랐습니다. 전량을 다시 보내면 상대 API 에 부하가 가고 중복 등록 위험이 생깁니다. 우리 상태와 상대의 전송 상태를 주기적으로 해시로 비교해 달라진 것만 보내, 중복과 누락을 동시에 막았습니다.
• 캐시 TTL 을 늘리는 대신 중복 요청 자체를 없앴습니다. TTL 을 늘리면 캠페인 소진 반영이 늦어져 이미 끝난 미션이 노출됩니다. 같은 요청이 동시에 오면 DB 호출은 하나만 실행하고 결과를 나눠 주는 방식으로 바꿨습니다 — 신선도를 포기하지 않고 부하만 줄이는 쪽입니다.
• 새 매체는 지우기 쉬운 형태로 붙였습니다. 한 매체로 먼저 파일럿하고, 문제가 생기면 연동 코드를 걷어내는 게 아니라 대상 목록에서 빼는 것으로 롤백됩니다.

• 중복 요청 제거 · 동시 실행 제한 · 짧은 캐시로 평균 응답 160ms → 9ms.
• 잔여 수량 계산 방식을 바꿔 동시 참여 경합을 줄였습니다.
• 콜백 실패를 사유별 카운터로 나눠 적재해, 정상 중복과 진짜 장애가 한 숫자에 섞이지 않게 했습니다.

고트래픽 파트너의 미션 재오픈 조건을 바꾼 배포 뒤 전체 API 응답이 12ms 에서 160ms 로 늘고 일부는 60초까지 밀렸습니다. 요청량은 평소와 같았고 DB CPU 만 보면 정상이었습니다(30% 수준) — 실제로 차 있던 건 connection pool 이었습니다. 중복 요청 제어가 없어 한 파트너의 반복 요청이 connection 을 계속 물고 있었습니다.

장애 전 12ms 보다도 빨라졌습니다 — 중복 요청을 없애면서 원래 매번 하던 DB 조회까지 줄었기 때문입니다. 그래서 배포 검증 기준에 DB CPU 만이 아니라 응답 시간과 connection 사용량을 같이 넣었습니다.

실사용자 성능을 매체별로 보려고 계측을 직접 붙였습니다. 지면에서 Core Web Vitals 를 표본 추출해 보내고 서버가 매체별 p75 로 집계하는데, 수집이 지면을 느리게 만들면 재려던 값이 나빠지므로 수집 코드는 지연 로드했습니다.

그 김에 하루치 ALB 액세스 로그 227만 요청을 열어 보니 제휴사 요청의 31%(하루 40,668건)가 preflight 였습니다. 액세스 로그에는 요청 헤더가 없어 원인을 알 수 없었고, 헤더 이름만 세는 계측을 잠깐 붙여 확정했습니다 — 모든 요청에 붙던 Content-Type 하나였습니다. GET 은 본문이 없어 의미가 없는데, 붙는 순간 단순요청 조건이 깨져 왕복이 하나씩 더 생깁니다. GET 에서 걷어내고 POST 는 Access-Control-Max-Age 로 캐시해 94% 감소(40,668 → 2,265건), GET preflight 는 0건.

고치고 나서야 실사용자 기준 "before" 가 없다는 걸 알았습니다. 그래서 API 응답 시간도 같은 파이프라인으로 재기 시작했습니다.

피크 1,900 RPS 구간을 2년 넘게 운영 중이고, 그사이 스펙을 깨서 상대 매체 연동을 멈추게 한 적은 없습니다.

응답 스펙에 버전을 두지 않아, 필드를 더할 수는 있어도 뺄 수는 없었습니다. 2년 넘게 유지될 계약이라는 걸 알았다면 경로에 버전을 먼저 넣고 시작했을 것입니다.

구현입니다. 작업마다 독립된 git worktree 에 에이전트를 띄워 병렬로 돌리고, 작업이 서로의 파일을 건드리지 않게 분리합니다.

무엇을 만들지와 그 결과를 받아들일지는 제가 정합니다. 특히 매체사와 주고받는 API 스펙처럼 상대 회사 개발자와 합의해야 하는 결정은 코드 문제가 아니라 합의 문제라 넘기지 않습니다. 지표를 어떻게 읽을지도 마찬가지입니다 — 오퍼월의 콜백 실패 78.5%처럼, 숫자가 맞아도 해석이 틀리면 엉뚱한 곳을 고치게 됩니다.

구현 에이전트와 리뷰 에이전트를 분리하고, lint · test · typecheck · build 를 통과해야만 커밋되도록 훅으로 묶었습니다. 급할 때 빠져나가지 못하게 --no-verify 도 훅에서 막습니다.

AI 가 낸 결과를 받아들일지는 운영에서 실제로 겪은 문제로 판단합니다. 이 문서의 사례들이 그 기준입니다 — 한 번 터진 방식은 다시 통과시키지 않습니다.