QA 통합시스템 구축 도전기 (QA Hub)

---

안녕하세요 노머스 QA팀 구예성입니다.

QA 업무를 하면서 계속 걸리는 부분이 하나 있었습니다.

병목이 어디인지는 다들 알고 있는데, 정작 그 병목을 줄이는 일에는 아무도 시간을 쓰지 못한다는 점이었습니다. 당장 처리해야 할 검증이 밀려 있으니 이런 일은 늘 뒤로 밀리기 마련이었습니다.

그래서 QA 업무 전반을 효율화하고 그 기능들을 한곳에서 다룰 수 있는 시스템을 만들기로 했습니다. 이름은 QA Hub로 정했습니다.

단순히 도구 하나를 만드는 것이 목표는 아닙니다. QA와 관련된 기능을 한자리에 모으고, QA팀이 아니더라도 필요할 때 들어와서 사용할 수 있는 자리를 만드는 것이 목표입니다.

엔터 쪽 서비스는 트렌드와 유행에 민감하다 보니 갑자기 들어오는 대응 건이 생각보다 많았습니다. 그럴 때마다 “이건 누가 검증하지?”를 찾아다니지 않아도 되는 상태를 만들고 싶었습니다.

만드는 순서는 두 단계로 잡았습니다.

첫 번째는 프로젝트별 QA 진행 현황을 한 번에 보는 것. 비교적 만들기 쉽고 동시에 진행되는 프로젝트가 많아지면 유용할 것 같은 기능이라 시작점으로 적당했습니다.

두 번째는 TC 작성. 팀 내에서 공수가 가장 크게 들어가는 부분입니다. 기획서 하나가 나오면 TC를 작성하는 데만 며칠이 걸립니다. 그 시간이 통째로 빠지다 보니 정작 테스트할 시간이 부족해지고, 자동화는 늘 다음으로 밀립니다.

여기를 AI로 줄여보기로 했습니다. 지금 만들고 있는 부분도 바로 이쪽입니다.

1. 프로젝트별 QA 진행 현황

TC는 구글 시트에 있고, 이슈는 지라에 있습니다.

진행 상황을 보려면 탭을 여러 개 열어놓고 직접 눈으로 합산해야 합니다. 이걸 한 화면에 모았습니다.

드라이브 최상위 폴더 하나만 지정해두면 그 아래 프로젝트 폴더 → 스프레드시트 → 시트 탭 순서로 들어가면서 통계를 집계합니다.

탭마다 우선순위 부터 비고 사이의 컬럼을 플랫폼(iOS/AOS/Web 등)으로 보고, PASS / FAIL / N/T / N/A를 세서 진행률과 실패율을 계산합니다.

옆에는 지라에서 가져온 에픽 통계도 같이 붙였습니다.

만들고 나니 병목이 어디에 있는지가 오히려 더 선명하게 보였습니다.

TC 작성이었습니다.

2. TC 자동 생성

처음에는 단순하게 접근했습니다.

기획서를 통째로 넣고 “TC 만들어줘”라고 시켰습니다.

결과는 생각보다 좋지 않았습니다.

기획서가 길어지면 앞쪽 기능은 꼼꼼하게 쓰는데, 뒤로 갈수록 대충 넘어갔습니다. 화면 하나당 TC 두세 개 정도 쓰고 끝내는 식이었습니다.

사람이 해도 비슷할 것 같았습니다.

그래서 세 단계로 쪼갰습니다.

핵심은 2단계입니다.

기능 단위로 나눈 다음 기능 하나마다 AI를 따로 부릅니다.

“로그인 기능 하나만 봐라”라고 시키면 훨씬 집요하게 작성합니다.

정상 플로우뿐만 아니라 예외, 경계값, 권한, 상태 전이까지 관점별로 최소 하나씩 뽑아냅니다.

3단계 검토에서는 확인 필요 목록도 따로 나옵니다.

AI가 TC를 작성하다가 기획서만으로는 판단하기 어려운 부분, 예를 들어 우선순위를 정할 근거가 없거나 기획 의도가 불분명한 예외 케이스 같은 것들을 따로 모아줍니다.

실질적으로는 기획서 리뷰 결과에 가까운 셈입니다.

기존 프로젝트는 접근이 달라야 했다

신규 프로젝트보다 오히려 이쪽이 더 까다로웠습니다.

운영 중인 기능은 기획서가 한 장이 아닙니다. 컨플루언스에 1차, 2차, 개선안, 고도화 등 여러 문서가 전부 살아 있습니다.

여기서 제일 위험한 실패는 AI가 구버전 문서를 최신으로 착각하는 것입니다.

그러면 지금 서비스에는 없는 기능의 TC가 그럴듯하게 만들어집니다. 더 문제는 틀린 걸 알아채기도 어렵다는 것입니다.

그래서 사람이 반드시 거쳐야 하는 확인 단계를 일부러 넣었습니다.

AI가 1차로 분류해서 목록을 내놓으면 사람은 목록만 보고 체크합니다.

문서를 전부 읽을 필요는 없습니다. 이게 최신이 맞나? 만 판단하면 됩니다.

승인한 문서만 다음 단계로 넘어갑니다.

자동화를 만들면서 수동 단계를 넣는 게 이상해 보일 수도 있습니다.

그런데 틀린 TC를 나중에 찾아내는 비용이 체크박스 몇 개 누르는 것보다 훨씬 크다고 생각했습니다.

피그마 링크를 두 칸으로 나눴다

처음에는 피그마 링크를 한 칸만 받았습니다. 기획 피그마였습니다.

그런데 만들어진 TC를 보니 기대 결과에 실제로는 없는 문구가 들어가 있었습니다.

기획서 안에 그려둔 화면은 설명용이라 실제 디자인과 다른 경우가 있었던 것입니다.

그래서 입력을 기획 피그마 / 디자인 피그마 두 개로 나눴습니다.

그리고 AI에게 넘길 때도 두 자료를 섞지 않습니다. 디자인 쪽은 별도 구역으로 넣고 규칙을 명시했습니다.

화면에 보이는 문구는 디자인 시안 기준

기능 동작과 정책은 기획서 기준 (디자인은 문구의 근거일 뿐)

디자인 파일의 샘플·더미 값은 인용 금지

처음에는 한 덩어리로 합쳐 넣었는데, 그러다 보니 AI가 디자인 파일에 있는 예시 데이터를 실제 스펙으로 착각했습니다.

나눠서 넣으니 그 문제가 사라졌습니다.

3. LLM 토큰 비용과의 싸움

기능을 하나씩 붙이다 보니 실행 한 번에 나가는 비용이 눈에 띄게 늘었습니다.

특히 디자인 피그마 입력을 추가한 뒤부터 체감이 컸습니다.

이대로 팀 전체가 쓰기 시작하면 감당하기 어렵겠다 싶어서, 한 번 제대로 들여다봤습니다.

결론부터 말하면, 모델을 싼 걸로 바꾸거나 AI가 덜 생각하게 만드는 방법은 하나도 쓰지 않았습니다.

그건 결과물 품질을 깎는 거라 의미가 없다고 생각했습니다.

따라서 순서와 중복을 정리하여 입력 토큰 사용량을 줄였습니다.

토큰이 뭐고 돈이 어디서 나가나

LLM은 주고받은 글자 수(토큰)만큼 요금이 붙습니다.

여기서 중요한 건 두 가지입니다.

구분	상대 단가	비용 절감 수단
입력 토큰 — 우리가 보내는 글 (기획서, 피그마 문구)	1	프롬프트 캐싱 — 같은 내용 재전송 시 캐시가 적용되어 비용 1/10
출력 토큰 — AI가 써주는 글 (TC 본문 + 생각 과정)	5배	캐싱 불가

위 표는 Anthropic Claude API로 호출하는 Claude Opus 5(claude-opus-5)의 공식 가격표(2026년 9월 기준)를 바탕으로 했습니다. 100만 토큰당 입력 $5, 출력 $25이고, 캐시가 적용된 입력은 $0.50입니다.

TC 생성 한 번에 AI를 여러 번 호출합니다.

기능이 6개면 최소 8번입니다.

그리고 매번 같은 기획서를 다시 보냅니다.

그러니까 프롬프트 캐싱이 실제로 걸리느냐가 비용의 대부분을 결정합니다.

캐싱은 코드에 이미 걸어뒀는데, 문제는 그게 제대로 걸리지 않고 있었다는 것입니다.

발견 1 — 동시에 보내면 캐싱이 안 걸린다

가장 크게 새고 있던 지점은 의외로 단순했습니다.

기능이 6개면 AI를 6번 부르는데, 속도를 위해 4개를 한꺼번에 동시에 보내고 있었습니다.

그런데 프롬프트 캐싱은 첫 번째 요청의 응답이 시작된 뒤에야 캐시가 만들어지고, 그 뒤의 요청부터 재사용할 수 있는 구조입니다. (Claude 공식 문서: https://platform.claude.com/docs/en/build-with-claude/prompt-caching)

동시에 출발하면 아직 만들어진 캐시가 없습니다.

그래서 4건 모두 캐시가 적용되지 않은 채 토큰 비용이 그대로 발생하고 있었습니다.

동작	요금
고치기 전	1·2·3·4번을 동시 발사 → 4건 모두 캐시 미적용
고친 뒤	1번만 먼저 보내 등록 → 나머지 발사 → 1건만 캐시 미적용, 나머지는 캐시 적용으로 1/10

바꾼 건 보내는 순서뿐입니다.

프롬프트도, 모델도, 결과물도 그대로입니다.

대신 코드를 단순하게 구현하기 위해 첫 번째 호출이 끝날 때까지 기다리도록 했으므로 전체 시간은 AI 호출 1회분만큼 늘어납니다.

발견 2 — 쓰라고 한 적 없는 자료를 계속 보내고 있었다

디자인 피그마 문구(최대 2만 자)가 1·2·3단계 전부에 들어가고 있었습니다.

그런데 1단계(기능 나누기) 프롬프트에는 이 자료로 기능을 판단하지 마라고 명시되어 있었습니다.

쓰지 말라고 지시한 자료를 매번 최대 2만 자씩 보내고 있었던 셈입니다.

그래서 1단계에서만 뺐습니다.

문구가 실제로 필요한 2·3단계는 그대로 둡니다.

발견 3 — 같은 기획서를 두 번 사고 있었다

1단계(나누기)와 3단계(검토)가 각각 기획서 전문을 캐시 없이 보내고 있었습니다.

두 단계는 조건이 맞아서, 기획서를 똑같은 형태로 요청 맨 앞에 두기만 하면 3단계가 1단계의 것을 재사용할 수 있었습니다.

프롬프트 캐싱은 앞부분부터 글자 단위로 같아야 걸리기 때문에 위치가 중요합니다.

재사용하도록 바꿨더니 두 번째 호출에는 캐시가 적용되어 토큰 비용이 1/10로 줄었습니다.

다만 캐시에는 5분 유효시간이 있습니다.

그 사이 2단계가 통째로 끼어드는데, 아래의 Batch 모드로 돌리면 시간이 훨씬 길어져 유효시간을 넘깁니다.

그 경우에는 이 기능이 자동으로 꺼지도록 해뒀습니다.

발견 4 — Batch API, 출력 토큰까지 깎는 유일한 수단

위 세 가지는 전부 입력 토큰만 건드리는 방법입니다.

그런데 앞의 표에서 봤듯 출력 토큰이 5배 비싸고, 캐싱이 원천적으로 불가능합니다.

여기에 쓸 수 있는 게 Batch API입니다.

언제 답을 줄지 약속하지 않는 대신 토큰 비용을 절반으로 줄여주는 옵션입니다.

서버가 한가할 때 처리하는 대신 입력·출력 모든 토큰이 절반이 됩니다. 심야 전기 요금과 같은 원리입니다.

모델도 프롬프트도 결과물 품질도 완전히 동일합니다.

바뀌는 건 언제 오냐 하나뿐입니다.

웹 화면 — 사람이 화면 앞에서 기다리는 구조라 적용 불가. 즉시 응답 유지

터미널 실행 — 적용. 기본으로 켜져 있음

최대 24시간까지 걸릴 수 있는데, 이건 마감 기한이지 예상 시간은 아닙니다.

서버가 한가하면 몇 분 만에 끝나기도 합니다.

다만 언제 끝날지는 알 수 없다는 게 유일한 단점입니다.

작업이 클수록(TC가 많이 나올수록) 출력 토큰의 비중이 커지므로, Batch 모드의 절감액은 작업 규모에 비례해서 커집니다.

정리

바꾼 것	바꾸지 않은 것
요청을 보내는 순서	AI 모델
자료의 위치	AI가 생각하는 깊이
불필요한 중복 제거	프롬프트 내용 (발견 2 제외)
요금제 (Batch API)	출력 형식과 품질

토큰 절감이라고 하면 보통 모델을 낮추거나 프롬프트를 줄이는 것부터 떠올리기 쉽습니다.

그런데 그 전에 구조에서 새는 것부터 막는 게 순서였습니다.

캐싱이 걸려 있다고 생각했는데 실제로는 안 걸리고 있었다는 게 가장 근본적인 문제였습니다.

남은 과제: 위 수치들은 아직 코드 기준 계산값이고 실측이 아닙니다. 실행할 때마다 주고받은 토큰 수가 기록되도록 해뒀으니, 실제 데이터가 쌓이면 다시 정리해보려 합니다.

4. 아직 부족한 것들

“도전기”라고 제목을 붙인 이유가 있습니다.

아직 완성이 아닙니다.

TC 품질을 채점할 방법이 없습니다. 그래서 “이렇게 바꾸면 더 좋아지나?”를 감으로 판단하고 있습니다. 비용을 더 줄일 방법도 몇 개 알고 있는데, 품질이 떨어지는지 확인할 수가 없어서 손대지 않고 남겨뒀습니다. 다음에 만들어야 할 것이 이것 같습니다.

용어집이 비어 있습니다. 도메인 용어를 넣으면 TC 품질이 올라갈 텐데 아직 채우는 중입니다.

만들다 보면 “일단 돌아가게”와 “제대로” 사이에서 계속 저울질하게 됩니다.

지금은 전자 쪽에 가깝고 인정하고 가는 중입니다.

5. 다음 병목은 이미 보인다

TC 작성이 빨라지면 끝일까요.

그렇지는 않을 것 같습니다.

지금:   TC 작성 ← 병목       →  리뷰  →  테스트 실행

앞으로: TC 자동 생성 (빠름)  →  리뷰 ← 새 병목  →  테스트 실행

AI가 TC를 100개 뽑아주면, 이번에는 그 100개를 사람이 검토하는 게 새로운 병목이 됩니다.

그래서 다음 목표는 여기입니다.

몇 가지 방향을 생각하고 있습니다.

전부 똑같이 보지 않게 하기 — AI가 스스로 확신이 낮은 항목, 판단 근거가 약한 항목을 먼저 올려서 거기부터 보게 하기

중복 먼저 걸러내기 — 사실상 같은 걸 검증하는 TC를 미리 묶어주기

리뷰 결과를 다시 먹이기 — 사람이 고친 내용을 다음 생성에 반영해서 같은 실수를 반복하지 않게 하기

세 번째가 가장 효과가 클 것 같지만, 난이도도 가장 높아 보입니다.

마치며

TC 작성 시간이 줄면 그 시간에 자동화를 짜거나, QA 기간에 평소 못 하던 여러 테스트를 해볼 수 있습니다.

결국 품질로 돌아온다고 생각합니다.

그리고 이 도구를 QA팀만 쓰는 게 아니라, 기획자든 개발자든 필요하면 들어와서 버튼을 누르고 쓸 수 있게 만드는 것.

그게 Hub라는 이름에 담고 싶었던 부분입니다.

지금은 CLI로만 돌아가는 자동화들도 웹으로 옮겨 쉽게 사용 가능하게 만들고 싶은 계획도 있습니다.

아직 갈 길이 멀지만 계속해서 도전 해보려고 합니다.

감사합니다.