다른 기업들은 QA조직을 이렇게 성장 시켰어요!

QA 조직 없이 시작한 플랫폼, 5년간 어떻게 안정화했을까?

커머스 플랫폼 Y사 QA 아웃소싱 리더 엔지니어, 신정현 책임의 실전 인터뷰

본 인터뷰는 실제 QA 아웃소싱 운영 경험을 바탕으로 작성되었습니다. 고객사명은 익명 처리되었습니다.

"테스트는 해야 하는데, QA 팀을 꾸릴 여력은 없어요"

많은 기업이 이런 순간을 겪습니다. Y사도 마찬가지였습니다. 오랫동안 운영해온 커머스 플랫폼 서비스가 있었고, 테스트는 유관부서 관리자 1명이 본업과 병행하며 맡고 있었습니다. 소규모일 땐 유지가 됐지만, 신규 플랫폼 서비스가 추가되면서 이슈가 생기기 시작했습니다.

1. 각 부서가 자체적으로 테스트를 나눠 맡기엔 부담이 너무 컸고
2. 내부 QA 인력을 채용하자니, 비용과 관리 리소스가 걱정됐으며
3. 그렇다고 테스트를 줄이자니, 품질 리스크가 눈에 밟혔습니다

결국 Y사가 선택한 건 "내부 조직은 없지만, 조직처럼 운영되는 QA" 였습니다.

5년간 단계별 QA 조직 성장 과정

Q. 처음 Y사에 투입됐을 때 상황이 어땠나요?

QA가 '업무'로 존재하는 상태였습니다. 조직이나 체계가 있는 게 아니라, 필요한 사람이 그때그때 테스트를 하는 구조였어요.

1. 기획자가 체크리스트 기반으로 테스트
2. 부서별로 나눠서 검증
3. 테스트 기준이나 문서 체계는 없음

그래서 가장 큰 문제는 "테스트가 되고는 있지만, 검증은 안 되는 상태" 였습니다. 특히 세부 시나리오나 예외 케이스는 거의 커버되지 않았고, 배포 이후 이슈가 반복되는 상황이었습니다.

Q. 가장 먼저 했던 작업은 무엇인가요?

테스트를 시작한 게 아니라, '기준'을 먼저 만들었습니다. 많은 경우 바로 테스트를 시작하려고 하는데, 그 상태에서는 인력을 투입해도 결과가 크게 달라지지 않습니다. 그래서 초반에는 "어떻게 테스트할 것인가"를 정의하는 데 집중했습니다.

1. 테스트 케이스 작성 기준 정의
2. 결함 리포트 양식 및 우선순위 기준 수립
3. 릴리즈 사이클에 맞춘 QA 프로세스 설계

이 작업이 끝나야 QA가 사람에 의존하는 게 아닌 구조와 프로세스로 구축될 수 있습니다.

Q. 초기에 엔지니어 4명이 투입된 이유도 그 때문인가요?

네, 구축기에서는 속도가 중요합니다. 이 단계는 테스트도 하지만 동시에 "QA 프로세스(시스템) 만드는 시기" 입니다.

1. 서비스 전체 기능 분석
2. 테스트 시나리오 정의
3. 문서 체계 구축
4. 조직 내 커뮤니케이션 정리

이걸 동시에 진행해야 하기 때문에, 초기에는 인력이 충분히 들어가야 합니다. 결과적으로 짧은 기간 안에 QA 구조를 안정적으로 만들 수 있었습니다.

(사진: 리드워크 신정현 책임, 정향은 선임 엔지니어)

Q. 3년차에 인력을 줄였는데, 품질은 유지됐나요?

이후에도 안정적으로 운영됐습니다. 이 시점에서는 이미 테스트 기준, 프로세스, 역할 구조가 모두 정립된 상태였습니다. 서비스 규모는 크지만, 인력을 최소로 유지하면서 안정화까지 5년이라는 시간이 걸렸습니다. 인력 4명 → 2명으로 축소되었음에도 기존 테스트 커버리지 90% 이상을 유지했습니다. 인력을 줄였지만 역할이 명확해지면서 집중도가 높아져 효율화가 이루어진 결과였습니다

Q. 고객사에서 자동화를 고려하고 있다고요?

아직 자동화를 도입한 상태는 아닙니다. 다만, 도입 시점과 범위는 검토하고 있습니다. 현재 전체 기능을 자동화하는 건 효율적이지 않다고 생각합니다. 특히 이커머스는 프로모션·UI·정책이 자주 변경되고, 신규 배포마다 기능 수정이 빈번하기 때문에 자동화 유지 비용이 더 커질 수 있습니다. 결제 부분과 결제 이후 동작들에 한정해서 자동화를 적용해도 충분하다고 판단됐습니다. 장시간 해당 플랫폼의 QA를 진행하면서 전반적인 데이터가 쌓였고, 이커머스의 핵심인 결제 영역에 자동화를 도입할 경우 더 효율적으로 QA를 진행할 수 있다고 보고 있습니다.

Q. 5년 동안 안정적으로 운영된 이유는 무엇이라고 보시나요?

초기에 방향을 잘 잡은 덕분에 안정적으로 운영한 것이 가장 컸습니다.

1. 구조 중심으로 설계했고
2. 기준을 먼저 만들었고
3. 이후에 효율화를 진행했기 때문에

운영이 흔들리지 않았습니다. 시간이 지나면서 QA가 특정 팀이나 프로젝트만 하는 역할이 아니라, 타 프로젝트에서도 협업하는 구조로 확장됐습니다.

Q. 다른 프로젝트에도 해당 프로세스를 동일 적용이 가능한가요?

네, 현재 진행 예정인 A사 프로젝트에도 같은 방식으로 적용할 예정입니다. A사는 장비 관리·운영 사내 솔루션을 운영하는 곳으로, Y사 초기 상황과 거의 동일합니다.

1. QA 전담 조직이 없는 상태
2. 기존 기능에 대한 전수 테스트가 필요
3. 신규 기능이 계속 추가되는 상황

적용할 단계별 QA 로드맵

1. 1단계 (초기 구축) 에서는, QA 프로세스 설계, 테스트 기준 및 문서 체계 구축, 전수 테스트 기반 확보
2. 2단계 (정착 및 효율화) 에서는, 프로세스 안정화, 역할 분리 및 운영 효율화, 테스트 커버리지 유지 구조 확립
3. 3단계 (자동화 도입)은 Y사에서는 충분한 데이터 축적 이후 자동화를 검토했다면, A사에서는 초기부터 자동화 대상 영역을 염두에 두고 프로세스를 설계할 계획입니다. 리드워크의 QA 엔지니어들은 자동화 역량까지 보유하고 있어, 고객사 프로젝트에 단계별 자동화를 적용해볼 예정입니다.

어떻게 도입하면 좋을까요? 3줄 요약

1. QA는 인력이 아니라 구조와 프로세스가 먼저입니다. 기준 없이 사람을 늘려도 품질은 나아지지 않습니다.
2. 초기에 제대로 구축하면 인력은 줄어도 품질은 유지됩니다. Y사는 4명→2명으로 줄이고도 커버리지 90% 이상을 유지했습니다.
3. 현재, 자동화는 처음부터 도입하는 것 보다는 데이터가 쌓인 후 핵심 영역부터 적용하는 것이 효율적입니다.

우리 서비스에도 같은 방식을 적용할 수 있는지 궁금하다면, 큐밋 매니저에게 문의해보세요.

👉️ 큐밋 매니저 무료 상담 받기 →