[QA Asset]반복 QA 업무를 줄인 TL 생성 가이드 구축 사례

[QA Asset Story] QA는 테스트만 하는 직무일까요?

👩🏻‍💻반복 업무를 줄인 3년 차 QA 엔지니어 이야기

3년차 QA 엔지니어가 프로젝트에서 반복되던 TL(Tracking Link) 생성 업무를 표준화 한 사례를 소개합니다. QA 문서화, 업무 개선, 온보딩 효율 향상까지 실제 프로젝트 경험을 확인해 보세요.

QA는 테스트만 하는 직무일까요?

많은 분들은 외주 테스트 엔지니어를 테스트를 수행하고 결함을 찾는 역할로만 생각합니다. 하지만 실제 프로젝트에서는 반복 업무를 개선하고, 협업 프로세스를 표준화하며, 프로젝트 경험을 조직의 자산으로 만드는 일도 QA의 중요한 역할입니다. 이번 QA Asset Story에서는 3년차 QA 엔지니어 이은영 님이 반복적으로 발생하던 TL(Tracking Link) 생성 업무를 표준화해 팀의 업무 효율을 높인 사례를 소개합니다.

Interview

Q. 안녕하세요. 자기 소개 부탁드립니다.

안녕하세요. QA 엔지니어 3년 차 이은영입니다. 가장 최근 프로젝트는 모바일 서비스 테스트 담당하면서, 기능 테스트뿐 아니라 테스트 프로세스 개선과 프로젝트 문서화 업무도 함께 수행하였습니다.

Q. 이번 프로젝트에서는 어떤 업무를 담당하셨나요?

프로젝트에서는 기능 테스트와 회귀 테스트를 수행하면서 테스트 환경 관리, 테스트 데이터 관리, TL(Tracking Link) 검증 업무도 함께 담당했습니다. 기존에는 TL을 전달받아 검증만 진행했지만, 이번 프로젝트에서는 QA팀이 직접 TL을 생성해야 하는 상황이 발생했습니다. 이 경험이 이번 가이드를 만들게 된 계기가 되었습니다.

Q. TL(Tracking Link)은 무엇인가요?

TL(Tracking Link)은 사용자의 유입 경로나 행동을 추적하기 위해 사용하는 URL입니다.

예를 들어 광고를 통해 유입된 사용자인지, 특정 이벤트를 통해 접속했는지 등을 구분하기 위해 URL 뒤에 다양한 파라미터를 함께 전달합니다.

QA 관점에서는 단순히 링크가 열리는지 확인하는 것을 넘어 다음과 같은 검증을 수행하게 됩니다.

1. 의도한 화면으로 정상 이동하는지
2. 특정 캠페인 정보나 파라미터가 올바르게 전달되는지
3. 앱 설치 여부에 따라 올바른 분기 처리가 이루어지는지
4. STG 환경과 운영 환경에서 동일하게 동작하는지
5. 트래킹 데이터가 정상적으로 수집되는지

즉, TL은 단순한 URL이 아니라 서비스의 사용자 흐름과 데이터 수집을 연결하는 중요한 기능 요소라고 볼 수 있습니다.

Q. 왜 TL(트래킹 링크) 생성 가이드를 만들게 되었나요?

기존 프로젝트에서는 마케팅팀이나 개발팀에서 생성한 TL(Tracking Link)을 전달받아 테스트를 진행하는 방식이 일반적이었습니다. QA팀은 전달받은 링크를 기반으로 정상 동작 여부를 확인하는 역할에 집중했기 때문에, 실제 TL 생성 과정이나 설정 방법에 대해서는 깊게 관여하지 않는 경우가 많았습니다. 하지만 이번 프로젝트에서는 기존과 다른 상황이 발생했습니다. 테스트를 진행하기 위해 전달받은 링크가 실제 테스트를 진행하는 릴리즈 버전이 아닌 일반 STG(Staging)버전의 링크이었고, QA 진행을 위해서는 직접 TL 링크를 새롭게 생성해야 하는 상황이었습니다.

문제는 QA팀 내부에서도 TL 생성 방법이 명확하게 정리되어 있지 않았다는 점이었습니다.

관리자 페이지 위치부터 파라미터 입력 방식, 환경별 설정 방법, 검증 절차까지 담당자의 경험에 의존하고 있었기 때문에, 작업을 진행할 때마다 다른 부서에 문의해야 했습니다. 이 과정에서 QA 일정도 지연되는 경우가 많았습니다. 그래서 "이 업무는 QA가 계속 수행해야 하는 일이라면 팀의 자산으로 남겨야 한다"는 생각이 들었습니다.

Q. 가이드는 어떤 기준으로 작성하셨나요?

가장 중요하게 생각한 것은 "처음 보는 사람도 혼자 수행할 수 있어야 한다."였습니다. 단순히 TL 생성 방법만 정리하는 것이 아니라 실제 QA 업무 흐름에 맞춰 생성부터 검증까지 하나의 프로세스로 구성했습니다.

가이에는 다음과 같은 내용을 포함했습니다.

1. TL 생성이 필요한 상황과 사용 목적
2. 관리자 페이지 접근 방법
3. 필수 입력 파라미터 설명
4. 자주 발생하는 오류 사례
5. 생성된 링크 검증 방법
6. 실제 QA 시나리오에서의 활용 방법

또한 관리자 화면 캡처, 단계별 작업 순서, 주의사항까지 함께 정리해 신규 QA 엔지니어도 쉽게 따라올 수 있도록 구성했습니다. 특히 단순한 메뉴얼이 아니라 실제 프로젝트 경험을 바탕으로 작성했기 때문에 현업에서 바로 활용할 수 있는 실무 중심 문서가 될 수 있었습니다.

Q. 문서를 만든 이후 무엇이 달라졌나요?

가장 큰 변화는 QA팀의 업무 독립성이 높아졌다는 점입니다.

이전에는 TL 생성이 필요할 때마다 개발팀이나 마케팅팀에 요청하고 답변을 기다려야 했지만, 현재는 QA팀 내부에서 직접 생성하고 검증까지 수행할 수 있게 되었습니다.

이를 통해 얻은 효과는 다음과 같습니다.

그 결과,

1. 테스트 대기 시간이 줄어들었고
2. 반복적인 커뮤니케이션이 감소했으며
3. 신규 QA 온보딩이 훨씬 빨라졌습니다.

무엇보다 특정 담당자의 경험이 아닌 팀 전체가 활용하는 프로젝트 자산으로 남게 되었습니다.

Q. 이번 경험을 통해 가장 크게 느낀 점은 무엇인가요?

QA는 테스트만 수행하는 직무가 아니라고 생각합니다. 프로젝트를 진행하다 보면 반복적으로 발생하는 비효율을 발견하게 됩니다. 그 문제를 해결하고 다른 사람이 같은 문제를 반복하지 않도록 만드는 것도 QA의 중요한 역할이라고 생각합니다. 이번 TL 생성 가이드 역시 거창한 시스템을 만든 것은 아니었습니다. 하지만 작은 문서 하나가 프로젝트의 업무 속도를 높이고 신규 엔지니어의 적응 시간을 줄이며 팀 전체의 생산성을 높이는 결과로 이어졌습니다. 앞으로도 테스트 환경 세팅, 테스트 계정 관리, 테스트 데이터 생성처럼 반복되는 업무를 지속적으로 문서화해 프로젝트의 자산으로 만들어가고 싶습니다.

➡️[관련글] [QA Asset Story] QA 조직 없이 시작한 플랫폼, 어떻게 안정화 했을까?

Q-Meet Insight

이번 사례는 단순히 TL 생성 방법을 정리한 문서가 아닙니다. 프로젝트에서 반복되는 업무를 발견하고 이를 표준화해 팀 전체가 활용할 수 있는 자산으로 만든 사례입니다.

큐밋은 이러한 작은 개선이 팀의 생산성과 프로젝트 품질을 높이는 시작점이 됩니다.

QA의 역할은 버그를 찾는 것에서 끝나지 않습니다. 반복 업무를 개선하고, 협업 프로세스를 만들며, 프로젝트의 경험을 조직의 자산으로 축적하는 것 역시 중요한 QA의 역할입니다.

프로젝트에 필요한 QA, 인력을 넘어 '경험'을 연결합니다.

큐밋에는 다양한 산업과 프로젝트 경험을 가진 QA 엔지니어와 전문 QA 파트너가 함께합니다.

프로젝트에 적합한 QA 파트너를 찾고 계신다면, 큐밋에서 비교하고 상담받아 보세요.

➡️ QA 프로젝트 의뢰하기