grep

Engineering

QA 티켓 280건, AI와 함께 처리한 기록

여기어때

2026년 9월 17일

원문에서 보기 ↗

글. 박수봉(Henby) / Experience Development팀

안녕하세요. **Experience Development팀 헨비(henby)**입니다.

9월 7일, 여기어때의 해외투어 서비스를 오픈했습니다~

그 동안 짧지만 밀도 높은 QA 기간을 보냈습니다.

프론트엔드 개발자는 총 두 명이었고, 저희는 웹과 웹뷰 모두를 처리하였고

저는 카테고리홈·상품 상세·주문서·예약내역·해외투어용 채팅을 맡았습니다.

또한 예약내역 탭·찜 탭·회원탈퇴처럼 여러 서비스가 함께 쓰는 공통 화면도 담당했습니다.

이 기간 동안 제게 배정된 QA 티켓은 총 280건이었습니다.

이 글에서는 이 280건을 AI 에이전트와 어떻게 처리했는지, 도움이 됐던 지점과 실패를 극복한 지점을 함께 정리해 보겠습니다.

1. 280건을 처리한 속도

이번 해외투어의 담당 QA티켓 280건은 전부 처리했습니다. 아주 빠르게요!

티켓이 들어온 날부터 처리될 때까지 걸린 시간을 재 보니, **절반 이상(56%)은 하루 만에 처리 됐고 10건 중 8건(81%)은 3일 안에 처리됐습니다.**하루에는 많게는 20건, 한 주에는 66건까지 티켓이 들어오기도 했습니다.

이 리드타임에는 QA와 PO의 검증 시간까지 들어 있습니다.

순수 개발 시간만 따로 보면 더 짧게 나올 겁니다. 다만 이번 QA에서 확인하고 싶었던 건 단순한 처리 속도 뿐만아니라

담당 범위의 정의 그리고 티켓 수가 늘어도 재요청 없이 재작업 없이 끝까지 처리할 수 있는 방식이 있는지를 회고 하고 싶습니다.

비교를 위해 티켓이 등록된 날부터 처리된 날까지를 같은 기준으로 계산했습니다.

제가 참여한 세 번의 대규모 QA를 놓고 봤습니다.

프로젝트 성격과 QA 인원, 검증 흐름이 매번 같았던 것은 아닙니다. 그래서 이 수치만으로 AI가 속도를 높였다고 단정할 수는 없습니다.

다만 담당 범위와 들어오는 티켓 수가 커진 상황에서도 해결까지 걸린 시간이 줄었다는 점은 분명했습니다. 이 글에서는 그 차이를 만든 작업 방식을 정리하려 합니다. 사람은 원인과 방향을 판단하고, 에이전트는 재현·조사·기록처럼 확인에 드는 시간을 줄였습니다.

2. QA 티켓의 파이프라인

티켓 하나는 다섯 단계를 거칩니다.

이 과정에서 저는 두 가지를 판단합니다. 에이전트가 짚은 원인이 맞는지, 그 수정안으로 반영할지, 재현·원인 추적·커밋은 에이전트가 맡습니다.

예를 들어 주문서 상세주소 칸에 한글이 입력되지 않는 티켓이 있었습니다. 재현 영상을 함께 전달하자, 에이전트는 입력 필터가 완성형 한글만 허용해 자모가 조합되는 중간 상태의 입력을 모두 막는다는 걸 찾아냈습니다. 완성형 검사 조건을 더 촘촘히 하자는 첫 제안은 IME 조합 자체를 무너뜨릴 수 있어 반려했습니다. 대신 자모까지 허용하도록 다시 제안받아 수락했고, 로컬에서 한글 조합이 정상적으로 되는 것을 확인한 뒤 배포했습니다.

이 과정에서 재작업을 가장 많이 줄인 규칙은 하나였습니다. 원인을 확정하기 전에는 절대 코드 수정은 안한다는 것입니다.

3. 고치기 전에 원인 파악부터

화면에서 보이는 증상과 실제 원인이 있는 곳은 다를 수 있습니다. QA 기간에는 이 둘을 먼저 구분하는 일이 생각보다 큰 비중을 차지했습니다.

계측된 이벤트 값이 화면과 다르게 적재되는 티켓이 있었습니다. 웹과 앱 두 컨테이너의 설정을 나란히 비교하면서 어느 지점에서 값이 바뀌는지 확인했습니다. 이전 화면의 값이 다음 이벤트에 남는 경우에는 프론트에 초기화 코드 한 줄을 추가해 막고, 근본 원인은 따로 공유했습니다. 또한 주문서에서는 여러 상품 속성이 하나의 코드로 묶여 내려오는 바람에 필수값 오류가 났습니다. 실제 응답을 확인한 뒤 스펙을 함께 논의했습니다.

저와 에이전트 모두 증거를 찾은 후 대화합니다. 그렇게하면 쓰레드의 길이가 짧아집니다. 어느 부분을 수정 할지 근거가 생기기 때문입니다. 이 과정에서 에이전트가 큰 도움이 됐던 지점도 이 부분입니다.

4. 같은 코드, 다른 기기

코드만 들여다봐서는 잡지 못하는 버그가 있습니다. 이번 QA에서 가장 오래 매달렸던 티켓은!

세 건을 증상·원인·수정 순으로 적어 봅니다.

① 리뷰 모달이 너무 길게 스크롤되던 문제 (iOS 16 이하)

② 뒤로가기 뒤에 흰 화면이 남던 문제 (Android)

③ 앱 구버전에서 최근 본 상품이 안 뜨던 문제

에이전트가 시뮬레이터를 띄워 비교하는 방법은 단순합니다. 터미널에서 xcrun simctl로 원하는 iOS 버전의 시뮬레이터를 부팅하고, 시뮬레이터의 Safari에서 로컬 개발 서버를 엽니다. 이후 스크린샷을 찍어 비교합니다. 터치 드래그처럼 손으로 재현하기 어려운 동작은 Playwright의 WebKit 엔진에서 터치 이벤트를 직접 넣어 확인했습니다. Android도 에뮬레이터를 부팅한 뒤 adb로 같은 방식으로 확인했습니다.

에이전트가 코드만 읽지 않고 시뮬레이터를 직접 띄워 두 버전을 비교하면서, 이런 유형의 티켓은 처리 시간이 눈에 띄게 줄었습니다.

5. Claude 메모리 파일이 중요했던 이유

우리 모두 MEMORY.md 파일이 중요하다는 사실은 알고있습니다. 하지만 상상보다 더욱더 중요했습니다.

QA 기간에 속도가 붙은 건 에이전트가 빨라서가 아니라, 에이전트가 참고할 메모리를 쌓아 뒀기 때문입니다. Claude는 세션이 끝나면 대화 맥락을 잊어먹습니다. 그래서 알게 된 사실을 작은 Markdown 파일로 하나씩 남기고, 에이전트가 세션을 시작할 때마다 그 목록을 담은 MEMORY.md를 읽게 했습니다. 이 메모리가 쌓일수록 같은 일을 다시 확인하는 시간이 줄었습니다.

API 문서가 대표적입니다. 에이전트가 명세 문서 위치, 서버 문서를 직접 조회해 타입과 대조하는 방법, 게이트웨이 프리픽스 규칙, 우리 API 계층 구조를 매번 참고할 수 있게 했습니다. 더 쓸모 있었던 건 문서와 실제 응답이 어긋난 지점을 기록해 둔 일이었습니다. 문서에는 취소 정책 코드가 세 개뿐이었지만, 실제 응답에는 다섯 개가 담겨 있었습니다. 문자열이라고 적힌 라벨은 null로 오기도 했고, 문서에는 있지만 서버 응답에는 없는 필드도 있었습니다. 이런 차이를 기록해 두니 같은 API를 다시 만지는 티켓은 훨씬 빨리 끝났습니다.

그 밖에도 정의서와 정책서는 구글 시트와 컨플루언스에서, 적재 로그는 키바나에서 직접 확인하도록 했습니다. 프로젝트 상태와 피드백은 세션이 바뀌어도 이어서 참고할 수 있게 했고, 커밋·투두·문서 작성 같은 반복 작업은 스킬로 만들었습니다. 티켓 여러 건은 세션을 나눠 병렬로 처리하기도 했습니다.

가장 크게 줄어든 건 "확인하러 가는 시간"이었습니다.

클로드/프로젝트 폴더에만 작성된 메모리MD 파일들과 MEMORY.md 가 하는일

실제 모습은 위 캡처와 같습니다. MEMORY.md는 목차 역할만 합니다. 파일 하나에 한 줄씩, 무엇을 알아냈고 무엇이 남았는지만 적습니다. 상세는 그 줄이 가리키는 개별 파일에 있습니다. 개별 파일 맨 위에는 이름과 한 줄 설명, 종류(project·reference·feedback)를 적고, 본문에는 사실과 함께 "왜 그런지"와 "다음에 어떻게 적용할지"를 남깁니다. 에이전트는 세션을 시작할 때 목차 한 장만 읽고, 티켓과 관련된 파일만 골라서 엽니다.

6. 세 사례의 공통점

AI 에이전트를 쓰면서 생긴 문제도 있었습니다. 그중 기억에 남는 건 두 가지입니다.

첫 번째는 병렬 작업 중 변경 사항이 섞인 일입니다. 두 세션이 같은 Git 스테이징 영역을 쓰던 중, 세션 A의 커밋에 세션 B의 변경 일부가 섞였습니다. 커밋을 다시 만들고 변경 내역도 다시 확인해야 했습니다.

두 번째는 방향을 충분히 확인하지 않은 채 구현을 진행한 일입니다. 실환경에서 검증한 코드를 코드만 보고 제거하려 했습니다. 브라우저 뒤로가기 계측은 전제가 틀린 상태에서 구현해 전부 롤백했습니다. 권종 순서 확장은 구현과 실측까지 마쳤지만, 정의서에서 허용하지 않는 범위라 커밋을 취소했습니다.

세 사례의 공통점은 코드를 쓰기 전에 방향을 확인하지 않았다는 것입니다. 구현이 맞더라도 풀 문제를 잘못 잡으면 결과는 쓸 수 없습니다. 이 판단은 사람이 해야 합니다.

7. 실패는 2번 하지 않는다

실패 시 규칙을 하나씩 붙였습니다.

세션 경합이 있었던 뒤에는 커밋 프로토콜을 만들었습니다. 커밋 직전에 git status를 확인하고, 파일 경로를 지정해서만 git add하며, git reset할 때는 전체 커밋 해시를 씁니다.

검증한 코드를 걷어내려 했던 일 뒤에는 실환경에서 검증한 코드는 코드만 보고 제거하지 않는다는 규칙을 세웠습니다. origin push 문제에는 push 직전 재확인을, 무관한 명령 실행에는 모든 셸 명령을 리뷰하는 훅을 붙였습니다. 구현 뒤 롤백한 일에는 단계마다 확인하고 다음으로 넘어가는 습관을 붙였습니다.

이 규칙은 쓰레드가 아니라 Memory.md파일에 남습니다. 그래야 다음 세션이 같은 실수를 안 합니다.

돌아보면 티켓을 빨리 처리하는 것보다 에이전트에게 나의 담당과 내가 수정할 수 있는 범위, 사전 지식을 먼저 최우선으로 학습 시키는 것이 중요하다고 생각합니다. 의외로 정형화된 정답이 아닌 아이가 잘 클 수 있도록 교육 시키 듯 저와 에이전트 모두 차근차근 같이 단계를 밟아 나갔다면, 프로젝트 막바자의 QA에서 빛을 발하게 된 것 같습니다.

읽어주셔서 감사합니다. 에이전트에게 티켓을 맡겨 보고 싶다면 크게 시작할 필요는 없습니다.

티켓 한 건만 골라, 원인을 확정하기 전에는 고치지 않는다는 하네스 하나부터 정해 보세요!

QA 티켓 280건, AI와 함께 처리한 기록 was originally published in 여기어때 기술블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.