코드에서 화면 지도를 그리고, AI와 함께 회귀 테스트의 빈 곳을 채우다

들어가며

안녕하세요. 컬리 프로덕트SQE Tribe에서 테스트 자동화를 담당하고 있는 신수진입니다. 저는 고객이 만나는 컬리 서비스의 웹과 앱(iOS·Android)이 업데이트 뒤에도 제대로 동작하는지, 사람 대신 코드가 확인하도록 자동화 테스트를 만들고 운영하고 있습니다.

컬리의 웹과 앱은 새 기능, 화면 개편, 기획전과 이벤트로 주기적으로 바뀝니다. 업데이트를 거듭할수록 새 기능이 기존 기능을 망가뜨리지 않았는지 확인하는 일이 중요해집니다. 개발자가 서비스를 만드는 코드를 쓴다면, 저는 그 서비스를 고객처럼 화면을 열고 버튼을 눌러 가며 써 보는 코드를 씁니다. 이렇게 쌓인 테스트는 배포 때마다 펼치는 그물과 같아서, 촘촘할수록 고객보다 먼저 문제를 잡을 수 있습니다.

이 글에서는 그중 웹 자동화의 범위를 AI와 함께 넓힌 경험을 나누려 합니다.

작업을 시작할 무렵 컬리 웹(PC·모바일웹)에는 전시·상품·주문·검색·회원·쿠폰 6개 서비스 영역(도메인)에 걸쳐 테스트 467개가 있었습니다(공교롭게도 부제의 화면 수와 같은 숫자지만, 둘은 전혀 관련이 없습니다. 글을 쓰다 보니 알게 됐는데 참 신기하네요). 이 테스트는 두 가지 방식으로 동작하고 있습니다. 배포 전 회귀 테스트는 로그인, 장바구니, 주문처럼 서비스의 핵심 기능을 기준으로 추린 테스트만 돌립니다. 배포 일정을 늦추지 않도록 짧은 시간 안에 주요 기능만 확인하는 것입니다. 데일리 회귀 테스트는 새벽에 수행되기 때문에 시간에 제약을 받지 않아, 전체 테스트를 빠짐없이 돌립니다. 핵심 흐름은 배포마다, 나머지는 매일 지켜 온 셈입니다. 그런데 어느 날 단순한 질문 하나에 답하지 못했습니다. “우리 테스트는 서비스 화면 중 어디까지 보고 있을까?”

이 질문이 중요한 이유는 간단합니다. 테스트가 확인하지 않는 화면은 그물에 난 구멍입니다. 배포로 깨져도 아무도 모르고, 고객이 먼저 겪고 나서야 알게 됩니다.

답하려면 먼저 서비스에 어떤 화면이 있는지 알아야 했습니다. 사용자가 각 화면에 어떻게 들어가는지도 알아야 했고요. 하지만 그런 목록은 어디에도 없었습니다. 기획서는 흩어져 있었고, 사람의 기억은 최신이 아니었습니다.

그래서 Claude Code와 함께 일을 세 단계로 나눴습니다. 먼저 서비스 전체의 화면 지도를 그리고, 담당자가 그 지도를 검증한 뒤, 비어 있는 곳을 자동화로 채웠습니다. 지도를 그리는 데 하루, 빈 곳을 채우는 데 3.5일로, 모두 합쳐 5일이 채 걸리지 않았습니다. 이 글은 그 과정에서 AI가 맡은 일, 사람이 맡은 일, 그리고 그 경계에서 배운 점을 정리한 기록입니다.

가운데 줄은 Claude Code가 한 일, 보라색 줄은 담당자가 정하고 승인한 일입니다.

먼저 알아 두면 좋은 용어

1단계: 문서 대신 코드에서 지도를 그리다

먼저 서비스의 모든 화면을 모았습니다. 웹 화면을 구성하는 레포 3개에서 화면 주소(라우트) 467개를 찾는 데는 2시간이 채 걸리지 않았습니다. 진입 경로 정리와 담당자 검토까지 마쳐 지도를 완성하기까지, 실제 작업 시간은 하루 정도였습니다. 기준은 사람이 쓴 문서가 아니라 실제 코드에 있는 라우트였습니다. 문서는 빠진 화면이 있을 수 있지만, 코드에 없는 화면은 서비스에도 없기 때문입니다.

어느 레포를 봐야 하나

첫 요청은 이랬습니다. “프론트 레포 하나면 충분한지, 컬리나우 같은 다른 레포도 봐야 하는지 검토해 달라.” Claude Code는 GitHub에서 회사 레포 목록을 불러와 최근에 수정된 레포만 추렸습니다. 그다음 README와 파일 구조를 읽어 고객이 보는 웹 화면을 가진 레포를 골랐습니다.

고른 레포는 3개입니다. 컬리몰 웹 화면을 담은 프론트 레포, 1시간 내외로 배송하는 즉시배송(퀵커머스) 서비스인 컬리나우 레포, 그리고 컬리에서 판매하는 상품으로 만든 요리 레시피를 공유하던 커뮤니티 서비스인 라운지 레포입니다. 라운지는 커뮤니티 운영을 종료했지만, 코드에는 화면이 남아 있어 함께 조사했습니다.

기획전 레포도 후보에 올랐습니다. 하지만 기획전은 정해진 기간에만 노출되고 화면도 매번 새로 만드는 구조라, 담당자 판단으로 검증 대상에서 뺐습니다.

규칙을 먼저 읽고, 일을 나눠 맡기다

라우트를 세기 전에 Claude Code가 먼저 한 일이 있습니다. 같은 주소로 들어와도 PC와 모바일에 다른 화면을 보여 주는 규칙을 코드에서 확인했습니다. 이 규칙을 모르면 같은 주소를 화면 하나로 세어, PC와 모바일웹 중 한쪽을 빠뜨리게 됩니다. 규칙을 정리한 뒤에는 읽을 코드 양이 많아 서브에이전트 4개에게 영역을 나눠 동시에 읽게 했습니다. 전시·상품, 회원·마이페이지, 장바구니·주문, 그리고 나머지 레포입니다.

코드를 직접 읽었기에 알게 된 사실도 있습니다. 컬리나우는 PC로 들어가면 “앱에서 이용할 수 있어요” 안내만 뜨는 구조였습니다. 담당자가 화면에서 느낀 것을 코드가 뒷받침했고, 컬리나우 화면은 모두 모바일웹 전용으로 분류했습니다.

진입 경로를 찾는 세 가지 방법

우리 웹 자동화 테스트는 E2E(End-to-End) 방식입니다. 실제 사용자처럼 브라우저를 열고 서비스 화면을 눌러 가며 확인합니다. 그래서 실제 서비스에서 들어갈 길, 즉 진입 경로가 있는 화면이라면 모두 테스트할 수 있습니다. 반대로 진입 경로를 모르면 테스트도 만들 수 없습니다. “메인에서 무엇을 눌러야 이 화면에 닿는가”를 알아야 하는 이유입니다. 이를 위해 화면마다 테스터가 따라갈 수 있는 진입 경로를 적었습니다. 모바일웹을 먼저 정리한 뒤, 진입 방식이 다른 PC는 따로 전수 조사했습니다.

1. 코드 역추적: 서브에이전트가 화면으로 향하는 링크, 버튼, 화면 이동 코드를 거꾸로 따라갔습니다. 모바일웹에 4개, PC에 4개를 돌렸습니다.
2. 크롤러 실측: Claude Code가 Playwright로 화면을 자동으로 돌아다니며 링크를 모으는 프로그램(크롤러)을 직접 만들었습니다. 메인에서 시작해 링크를 모으고, 링크가 없는 버튼은 눌러서 도착한 주소를 기록했습니다. 같은 형태의 주소는 한 번만 방문했고, 주문·삭제처럼 상태를 바꾸는 버튼은 누르지 않게 막았습니다.
3. 기존 자동화 활용: 이미 있는 회귀 테스트가 화면에 들어가는 단계를 코드에서 뽑아 진입 경로로 썼습니다.

여기서 한 가지 장치를 더했습니다. 진입 경로마다 근거가 무엇인지 표시해 둔 것입니다. 실제 화면에서 들어가 본 경로(실측), 코드로만 확인한 경로(코드 기준), 특정 조건에서만 보이는 경로(조건부 진입), 기존 테스트가 이미 지나는 경로(자동화 확인)로 나눴습니다. 검토하는 사람이 AI가 찾은 경로를 어디까지 믿어도 되는지 바로 알 수 있게 하려는 것이었습니다.

결과물은 세 가지였습니다

• 화면 목록 CSV: 467행에 화면명, 플랫폼, 진입 경로, 확인 근거를 담았습니다.
• 마인드맵: 메인에서 뻗어 나가는 화면 트리를 Claude로 만든 웹 페이지(아티팩트)로 공유했습니다. 검색과 근거 배지가 있고, 검토가 진행되는 동안 28번째 버전까지 고쳐 올렸습니다.
• 검토 시트: 모바일웹과 PC 탭으로 나눈 Google Sheets입니다. Claude Code가 시트 연동 도구로 직접 기록했습니다. 한 번에 수백 행을 쓸 때는 시트에 제대로 들어갔는지 수식으로 합계를 내 원본과 맞춰 봤습니다.

2단계: 사람이 지도를 검증하다

AI가 그린 지도를 그대로 쓰지는 않았습니다. 자동화 담당자가 467개 화면과 진입 경로를 직접 검토했고, 화면마다 자동화 구현 여부를 확정했습니다. 이 검토가 있었기에 지도를 작업 계획의 근거로 쓸 수 있었습니다.

함께 화면을 눌러 보며 확인하다

코드만으로 판단하기 어려운 화면은 Playwright MCP로 브라우저를 열고 함께 확인했습니다. 담당자가 “버튼이 보여요, 눌러서 확인해 주세요”라고 하면, Claude Code가 클릭하고 도착한 화면과 주소를 기록했습니다. 약관이 팝업으로만 뜨는지, 주소가 바뀌지 않고 화면 위에 겹쳐 뜨는지, 새 창으로 열리는지 같은 사실이 이렇게 하나씩 확인됐습니다.

조사 도중에 메인 화면 개편이 배포되기도 했습니다. 담당자가 “조사하는 사이에 주소가 바뀐 건 아닐까?”라고 물었습니다. Claude Code는 조사 기준 코드와 배포된 코드를 비교했고, 페이지 하나가 새 주소로 옮겨 간 것 말고는 영향이 없다는 것을 확인했습니다.

AI가 틀렸던 장면들

AI의 판단이 틀린 곳도 분명히 있었습니다. 대부분 코드나 화면에 드러나지 않는 조건을 모르는 데서 생겼습니다.

• “컬리나우 진입은 퀵메뉴에 있잖아요”: 크롤러가 컬리나우 진입점을 찾지 못해 “없음”으로 판정했습니다. 알고 보니 테스트 계정의 배송지가 컬리나우 배송 지역 밖이라 메뉴가 숨겨져 있었습니다. 담당자가 배송지를 바꾼 뒤에야 메뉴가 보였습니다.
• 빠진 추가 인증: 배송지 추가 화면은 로그인 후 추가 인증을 거쳐야 들어갈 수 있습니다. AI가 쓴 경로에는 이 단계가 빠져 있었고, 담당자가 짚어냈습니다.
• 확인하지 않은 예시: 카테고리 경로에 확인하지 않은 메뉴 이름을 예시로 적어 둔 곳이 있었습니다. 검토 때 발견해 “카테고리 선택”으로 고쳤습니다.

사람만 아는 것들

코드에는 남아 있지만 실제로는 쓰지 않는 화면도 많았습니다. 다른 멤버십으로 대체돼 폐지된 서비스, 더는 쓰지 않는 예전 소개 페이지, 앱에만 있는 메뉴 같은 것들입니다. 이런 사실은 담당자가 알려 주었고, AI는 그 판단을 사유와 함께 지도에 반영했습니다.

분류 기준도 사람이 정했습니다. 1차로 ‘제외’한 화면 가운데 대표적인 것은 두 종류입니다.

• 조건부 노출: 특정 조건에서만 열리는 화면입니다. 컬리나우는 오전 9시부터 오후 10시까지만 운영되고, 라운지는 앱 전용인 데다 커뮤니티 운영도 종료됐으며, 기획전은 정해진 기간에만 노출됩니다. 이 중 컬리나우는 진입 경로까지 확인해 두었지만, 정해진 시간에 도는 데일리 회귀 테스트와 운영 시간이 맞지 않아 1차 제외로 분류했습니다.
• 진입점 없음: 예전에 쓰다가 지금은 쓰지 않아, 코드에는 남아 있지만 서비스에서 들어갈 길이 없는 페이지입니다.

운영 환경에서 테스트할 수 없는 화면은 ‘제약’으로 따로 두고, 담당자가 직접 판단했습니다. PC는 모바일웹 판단을 그대로 옮기지 않았습니다. 진입점이 같고 로그인만 하면 볼 수 있는 화면일 때만 옮겼고, 조건이 다르면 다시 검토 대상으로 남겼습니다.

467개가 104개가 되기까지

위 표는 모바일웹 화면의 1차 분류로, 이때 처음으로 빈 곳이 숫자로 보였습니다. ‘기구현’을 판단할 때는 테스트가 화면에 들어가기만 하는지, 화면 내용까지 검증하는지도 구분했습니다.

AI를 활용해 1차로 분류한 자동화 후보 104개는 담당자가 한 번 더 검토했습니다. 모바일웹 기준으로 38개는 ‘제약’으로 옮겼습니다. 회원 탈퇴·멤버십 해지·반품 접수처럼 운영에서 실행하면 계정이나 주문 상태가 실제로 바뀌는 화면, 메일로 받은 인증 링크나 실제 송장 번호처럼 테스트 계정으로는 준비할 수 없는 데이터가 필요한 화면입니다. 30개는 진입점이 없거나 노출 조건이 있는 것으로 확인돼 ‘제외’로, 1개는 ‘기구현’으로 옮겼습니다. 남은 35개가 모바일웹 구현 대상이 됐고, PC는 같은 기준으로 34개를 확정했습니다. 이 결과를 플랫폼과 도메인 단위의 작업 9개로 나눴고, Jira 티켓은 Claude Code가 시트를 읽어 만들었습니다.

검토가 끝난 인벤토리 시트의 일부입니다(주소와 내부 메모는 가렸습니다). 화면마다 진입 경로, 자동화 검토 결과, 우선순위, 담당 도메인이 한 줄에 담겨 있고, 이 표가 그대로 작업 티켓의 입력이 됐습니다.

3단계: 빈 곳을 채우다

작업 9개를 3.5일 만에 마쳐 신규 테스트 114개를 추가했습니다. 이렇게 빠르게 늘릴 수 있었던 데는 바탕이 있었습니다. Playwright로 화면을 다루는 공통 유틸 함수를 이미 갖춰 두었기 때문에, 처음부터 새로 만드는 것보다 훨씬 쉽게 확장할 수 있었습니다. 새 테스트는 공통 함수를 조합해 화면 동작과 판정을 쓰는 데 집중하면 됐습니다.

무엇을 검증할지부터 화면에서 찾다

지도에는 진입 경로까지만 있었고, 화면에서 무엇을 확인할지는 비어 있었습니다. 그래서 Claude Code가 먼저 화면을 직접 열어 보고 검증 시나리오를 제안했습니다. 예를 들어 목록 화면이라면 ‘목록이 보이는가’, ‘항목을 누르면 상세 화면으로 가는가’처럼, 고객이 그 화면에서 실제로 하는 일을 기준으로 삼았습니다. 담당자가 제안을 검토해 범위를 정했고, 티켓을 하나씩 구현했습니다.

추측 대신 실측과 코드

시나리오를 구현하기 전에 Playwright MCP로 실제 화면을 이루는 코드 구조(DOM)를 먼저 확인했습니다. 이 과정에서 눈으로는 보이지 않는 함정을 여럿 찾았습니다.

• 열리기만 해서는 알 수 없는 배너: 페이지가 열렸는지만 봐서는 내용이 없는 배너를 구분할 수 없었습니다. 그래서 화면이 실제로 불러오는 내용(데이터)을 확인하는 방식으로 바꿨습니다.
• 미리 받아 두는 목록: 공지사항 목록은 처음 열 때 다음 페이지까지 미리 받아 둡니다. 그래서 “스크롤하면 새 항목이 보인다”만으로는 목록을 더 불러오는지 검증할 수 없었습니다. 대신 미리 받아 둔 범위 밖의 항목이 스크롤한 뒤에 나타나는지를 기준으로 삼았습니다.
• 화면 밖에 숨은 제목: DOM에서 제목처럼 보이는 요소가 실제로는 시각장애인용 화면 낭독기만 읽도록 화면 밖에 놓인 경우가 있었습니다. 이 요소를 기준으로 판정하면, 화면에 제목이 보이지 않아도 테스트가 통과해 버립니다.

화면이 뜨는 조건은 프론트 코드에서 근거를 찾았습니다. 예를 들어 상품 상세의 후기 모아보기는 특정 상품 유형에 후기가 일정 수 이상일 때만 나타납니다. 이 조건을 모르고 아무 상품으로나 테스트하면 “섹션이 없다”는 실패가 납니다. 1단계에서 프론트 레포를 읽어 둔 것이 여기서도 그대로 도움이 됐습니다.

”통과”가 아니라 “실패할 수 있음”을 증명하다

가장 공을 들인 부분입니다. 항상 통과하는 테스트는 없느니만 못합니다. 그래서 판정마다 일부러 화면을 고장 내고, 테스트가 정말 실패하는지 확인했습니다. 화재경보기를 단 뒤 일부러 연기를 피워 정말 울리는지 시험해 보는 것과 같은 원리입니다.

• 확인할 요소를 숨기거나 문구를 지우기
• 클릭을 가로채거나 버튼 동작을 없애기
• 응답을 늦추거나 중간에 끊기

큰 작업에는 이런 고장을 많게는 30여 가지까지 넣었습니다. 고장을 넣었는데도 통과하는 판정은 고쳐서 다시 확인했습니다.

다른 시각의 AI 리뷰어

코드를 반영하기 전에는 매번 Claude Code의 리뷰 스킬을 돌렸습니다. 서로 다른 관점을 맡은 에이전트 3개가 변경분을 봅니다. 규칙·품질, 리스크, 그리고 실패할 만한 상황을 직접 만들어 돌려 보는 실측 검증입니다. 변경이 크면 이 라운드를 3번 반복해, 9번 연속 문제가 없어야 통과로 봤습니다. 매 라운드는 새 에이전트가 맡아, 앞선 판단에 끌려가지 않도록 했습니다.

9개 작업에서 코드에 반영하기 전에 고친 실제 문제는 최소 33건입니다. 대표적인 사례는 이렇습니다.

• 마우스가 만든 착시: PC 메뉴의 활성 상태를 글자색으로 판정했습니다. 그런데 마우스를 올린 메뉴의 색이 활성 색과 같아서, 클릭 후 포인터가 메뉴 위에 남아 있으면 활성이 아니어도 통과했습니다.
• 같은 문구, 다른 자리: 장바구니 쿠폰 화면의 섹션 제목과 같은 문구가 담은 상품 행 안에도 있었습니다. 그래서 제목이 사라져도 판정이 통과했습니다.
• 사진인 줄 알았던 동영상: 사진 후기 목록의 첫 썸네일이 동영상 커버일 수 있다는 것을 프론트 코드에서 찾아냈습니다.

PC와 모바일웹은 한 쌍으로

PC와 모바일웹은 같은 서비스의 두 화면이라 결함도 대개 같이 있습니다. 그래서 한쪽을 고치면 반대편도 반드시 확인하도록 Claude Code의 규칙으로 정해 두었습니다. 두 화면의 구조가 같은 주문 화면들은 판정 코드를 하나로 합쳤습니다. 실제 주문을 만드는 테스트는 끝나면 주문을 자동으로 취소하는데, 이 기능도 PC까지 넓혔습니다.

판정 기준을 정하는 것은 끝까지 사람의 몫이었습니다. 링크 이름과 화면 제목이 이모지 하나만 다를 때 같은 것으로 볼지, 테스트 계정 데이터로는 검증할 수 없는 금액 판정을 뺄지 같은 문제입니다. AI는 선택지와 근거를 제시했고, 결정은 담당자가 했습니다.

코드 반영 절차는 단순합니다. 도메인별로 로컬에서 전체 테스트를 돌려 문제가 없으면, CI 환경에서 한 번 더 검증한 뒤 코드에 반영했습니다. 반영을 마치면 Claude Code가 팀에서 직접 만든 테스트 관리 도구 Kase에 테스트 케이스를 등록하고, Jira 티켓에 종료 코멘트를 남겼습니다. 종료 코멘트에는 작업 범위, 판정 근거, 검증 결과, 검증하지 못한 범위를 적었습니다.

예상하지 못한 수확

테스트를 늘리다 보니 실제 결함도 나왔습니다. 배너를 눌렀을 때 도착 화면을 확인하는 새 테스트가 서비스에 노출 중인 빈 배너 여러 건을 찾아냈습니다. 누르면 상품이 없거나 페이지가 없는 배너였습니다. 운영팀에 공유했고, 배너를 정비하기로 했습니다.

기존 테스트가 잘못 통과하던 곳도 찾았습니다. PC 공지사항을 구현하다가, 본문이 비어 있어도 여백 때문에 테스트가 ‘화면에 보인다’고 판단한다는 것을 알게 됐습니다. 같은 구조인 모바일웹 테스트도 같은 이유로 통과하고 있었고, 함께 고쳤습니다. 장바구니 쿠폰 판정도 PC 리뷰에서 문제가 드러났는데, 모바일웹에도 같은 문제가 있어 같이 고쳤습니다. ‘PC와 모바일웹은 한 쌍’이라는 규칙이 제 역할을 한 장면입니다.

숫자로 보면

수작업이었다면 구현에만 약 23영업일이 걸렸을 테스트 114개를 3.5일 만에 마쳤습니다. 수작업 시간은 자동화 담당자의 하루 평균 구현량(5개)을 기준으로 잡았습니다(114개 ÷ 하루 5개 ≈ 23영업일).

테스트가 예상보다 46개 늘어난 것은 계획에 없던 일을 더 해서가 아닙니다. 화면 하나를 들어가기, 화면 구성, 기능 동작으로 나눠 검증하고, 한쪽에만 있던 시나리오를 PC와 모바일웹에 맞춘 결과입니다.

새로 더한 114개는 모두 데일리 회귀 테스트에서 돌고, 그중 핵심 기능을 다루는 35개는 배포 전 테스트에도 들어갔습니다.

회원 도메인은 작업 전 36개로 규모가 작았는데, 이번에 가장 많이 늘어 주문과 같은 91개가 됐습니다. 마이페이지와 고객센터처럼 테스트가 닿지 않던 화면이 많았기 때문입니다. 신규 114개에는 기존 테스트를 다른 도메인으로 옮기거나 확장한 2개가 들어 있고, 진행할 수 없는 테스트 1개는 정리했습니다. 그래서 전체 테스트 수는 실제로 111개 늘었습니다.

이번에 확장한 테스트를 포함한 578개는 지금 매일 운영 환경에서 돌고 있습니다. 위 화면은 Kase에 기록된 11월 3일 정기 실행 결과입니다. 실행된 568개가 모두 통과했고, 전체 수행에는 13분 44초가 걸렸습니다. 568개를 하나씩 차례로 돌린 시간은 아닙니다. PC와 모바일웹의 도메인마다 실행 서버(러너)를 하나씩 배정해, 12개 러너가 동시에 나눠 돌리도록 구성해 수행 시간을 줄여 두었습니다. 도메인과 플랫폼별 결과가 한 화면에 나뉘어 보여서, 어디가 깨졌는지 바로 찾을 수 있습니다.

건너뛴 10개(N/A)는 메인의 스페셜 딜 모듈이 테스트 시점에 노출되지 않아 검증할 수 없었던 경우입니다. 평소에는 메인에 노출되고 미노출 비율도 낮은 모듈이라, 노출되지 않은 날에만 건너뛰도록 구현했습니다.

AI와 일하며 배운 것

기준은 코드에서 가져옵니다. 문서나 기억으로 목록을 만들었다면 467개를 빠짐없이 모으지 못했을 것입니다. AI가 방대한 코드를 빠르게 읽을 수 있었기에 가능한 방식이었습니다.

AI 결과에는 근거를 붙입니다. ‘실측’인지 ‘코드 기준’인지가 보이면, 검토하는 사람은 어디부터 확인할지 알 수 있습니다. 467개를 사람이 다시 검토할 수 있었던 것도 이 표시 덕분입니다.

“통과한다”보다 “실패할 수 있다”를 먼저 확인합니다. AI가 쓴 테스트는 그럴듯하게 통과합니다. 고장을 넣어 보기 전까지는 그 통과가 진짜인지 알 수 없습니다.

판단은 사람이 합니다. 폐지된 서비스, 앱 전용 메뉴, 운영에서 테스트할 수 없는 화면은 코드에 나오지 않습니다. AI는 근거를 모으고 반복 작업을 맡았고, 범위·판정 기준·코드 반영·티켓 종료는 모두 담당자가 승인했습니다.

같은 실수는 규칙으로 남깁니다. 지적받은 내용은 Claude Code가 매번 읽는 규칙 파일(CLAUDE.md), 작업 절차서(스킬), 메모리(다음 대화에도 이어지는 기록)에 남겼습니다. 예를 들어 리뷰가 작업보다 길어지자 반복 횟수에 상한을 두었습니다. 고장 주입 스크립트는 첫 라운드에서만 만들고 이후에는 다시 실행하도록 리뷰 스킬도 바꿨습니다. 신규 시나리오 티켓에는 결함용 ‘원인·조치’ 형식이 맞지 않아, 종료 코멘트 형식을 따로 만들었습니다. 다음 작업에서는 같은 설명을 반복하지 않아도 됩니다.

긴 작업은 결과물을 원본으로 삼습니다. 1단계 대화는 여러 날에 걸쳐 이어졌고, 그사이 내용이 너무 길어져 AI가 앞부분을 요약하고 이어 간 것만 여섯 번이었습니다. 요약 과정에서는 세부 내용이 빠질 수 있습니다. 그래도 끊김 없이 이어 갈 수 있었던 것은 CSV와 시트를 기준으로 삼고 매번 대조했기 때문입니다.

마치며

저는 이번 작업으로 “우리 테스트는 어디까지 보고 있을까?”에 숫자로 답할 수 있게 됐습니다. 화면이 몇 개인지, 그중 무엇을 왜 뺐는지, 어디가 아직 비어 있는지가 한 장의 지도에 남아 있습니다.

남은 과제는 이 지도를 최신으로 유지하는 것입니다. 서비스는 계속 바뀌고, 지도는 그만큼 낡습니다. 다행히 지도를 만드는 방법이 이제 코드와 절차로 남아 있습니다. 그래서 다시 그리는 비용은 처음보다 훨씬 작을 것입니다. 앞으로는 분기마다 코드에서 새로 생기거나 사라진 화면 주소(라우트)만 확인해도, 지도를 새로 고치며 회귀 테스트가 닿는 범위를 꾸준히 지켜 갈 수 있을 것으로 기대합니다.

우리 테스트가 서비스의 어디까지 보고 있는지 궁금했던 분께 이 기록이 작은 지도가 되었으면 합니다. 긴 글 끝까지 읽어 주셔서 감사합니다.