QA·품질보증

실제로 하는 일

• 기획서·개발 명세서를 읽고 빠진 예외 상황(엣지 케이스)을 미리 질문한다
• 기능 단위 테스트 케이스를 작성하고 테스트 관리 도구에 정리한다
• 신규 배포 전 회귀 테스트 스위트를 실행해 기존 기능이 깨졌는지 확인한다
• 발견한 버그를 Jira 등 이슈 트래커에 재현 절차·심각도와 함께 등록한다
• 개발자가 수정한 빌드를 다시 검증하고 재현 여부를 회신한다
• API 요청·응답 값을 Postman이나 스크립트로 검증해 명세와 실제 동작의 차이를 찾는다
• 배포 직전 체크리스트를 점검하고 릴리즈를 진행할지 보류할지 의견을 낸다

필요한 역량

• Jira
• TestRail 등 테스트 케이스 관리 도구
• Postman
• Selenium/Playwright
• SQL
• Charles/Fiddler 같은 네트워크 프록시 도구
• Git 기본 사용법
• CI/CD 파이프라인(Jenkins 등)

들어가는 경로

• 비전공자가 사용자 관점의 꼼꼼함을 살려 게임·커머스 등에서 수동 테스트 인력으로 입사한 뒤 범위를 넓혀간다
• 개발자로 일하다 코드 이해도를 살려 자동화 중심 QA 엔지니어로 전환한다
• 컴퓨터공학·정보통신 전공자가 국가직무능력표준(NCS) 기반 직업훈련으로 테스트 설계·자동화를 익힌 뒤 지원한다
• 고객지원(CS)이나 운영 직무에서 제품 이해도를 쌓은 뒤 사내에서 QA로 전환한다
• 산업공학·품질경영 전공자가 제조업 품질관리 경험을 소프트웨어 품질로 옮긴다

성장 단계

1. 주니어1~3년정해진 테스트 케이스를 빠짐없이 정확하게 실행하고, 버그를 재현 가능한 형태로 기록하는 꼼꼼함으로 평가받는다
2. 미들3~6년테스트 케이스를 스스로 설계하고, 반복 작업을 자동화 스크립트로 줄여 팀 전체의 테스트 속도를 개선하는 능력으로 평가받는다
3. 시니어6~10년테스트 전략과 품질 지표를 정의하고, 릴리즈 리스크를 판단해 배포 여부에 영향을 미치는 결정으로 평가받는다
4. 리드/매니저10년 이상QA 조직 구조와 개발 프로세스 내 QA 개입 시점을 설계하고, 품질 이슈에 대한 조직 차원의 책임을 진다

오해와 실제

• “QA는 코드를 몰라도 되는, 진입장벽이 낮은 직무다.”

  수동 테스트만 맡기는 조직은 실제로 존재하지만, 자동화·API 테스트를 요구하는 조직이 늘면서 코드를 못 읽으면 맡을 수 있는 업무 범위가 금방 막힌다. 채용 시장은 '수동 QA'와 '자동화까지 가능한 QA'를 사실상 다른 직무처럼 취급하는 경우가 많다.

• “버그를 많이 찾을수록 좋은 QA다.”

  실제로는 릴리즈를 막을 만큼 심각한 버그와 무시해도 되는 버그를 구분하는 판단력이 더 중요하다. 사소한 버그를 무분별하게 등록만 하면 오히려 개발팀과의 신뢰가 떨어지고 협업이 어려워진다.

• “QA는 개발팀보다 책임이 가벼운 보조 업무다.”

  많은 조직에서 QA가 배포 직전 승인·보류를 판단하는 마지막 관문 역할을 맡는다. 출시 후 장애가 발생하면 '왜 걸러내지 못했냐'는 책임을 QA가 먼저 받는 경우도 적지 않다.

보상은 무엇으로 갈리는가

보상은 이 직무를 '지시받은 시나리오를 확인하는 수동 테스트'로 보는 조직인지, '자동화 코드를 짜는 엔지니어'로 보는 조직인지에 따라 크게 갈린다. 장애가 곧바로 매출 손실이나 신뢰 문제로 이어지는 산업(게임, 금융, 커머스 등)일수록 QA의 위상과 대우가 높아지는 경향이 있고, 조직 규모가 작을수록 QA가 기획·CS 업무를 겸하며 전문성이 희석되기 쉽다. 정규직이 아니라 프로젝트 단위 계약직·파견으로 QA 인력을 운영하는 조직도 있어, 고용 형태 자체가 보상 구조에 영향을 준다.

여기서 갈 수 있는 직무

• 기획·PM3~7년차

  준비 기간이 짧다

  QA 과정에서 쌓은 제품 이해도와 버그 리포트 작성 경험을 바탕으로, 테스트케이스 설계 단계에서부터 기획자와 밀접하게 협업하며 기능 정의에 의견을 내는 역할을 자청하는 경우가 많다. 이후 소규모 기능의 기획을 직접 맡아보며 전환하는 경로가 일반적이다.

  그대로 쓰는 것 · 제품 전체 흐름과 엣지케이스 이해, 요구사항 명세 분석력, 개발자·기획자와의 협업 커뮤니케이션, 이슈 우선순위 판단

  새로 채울 것 · 기획서·정책 문서 작성, 일정·리소스 관리, 데이터 기반 의사결정 및 지표 설계

• 백엔드2~5년차

  1~2년 준비가 필요하다

  테스트 자동화 스크립트를 작성하며 코딩에 익숙해진 QA 엔지니어(SDET)가 별도로 백엔드 언어를 학습해 사이드 프로젝트나 사내 툴 개발로 실력을 증명한 뒤 전환하는 경우가 흔하다. 다만 실무 개발 경험 공백을 메우기 위한 준비 기간이 필요하다.

  그대로 쓰는 것 · 시스템 동작 원리와 API 구조 이해, 버그 재현 및 원인 분석력, SQL·로그 분석 경험

  새로 채울 것 · 프로덕션 코드 작성 및 설계 역량, 언어·프레임워크 심화 학습, 자료구조·알고리즘 기초

• 인프라·DevOps3~6년차

  1~2년 준비가 필요하다

  QA 자동화 파이프라인을 직접 구축하고 CI/CD에 테스트를 통합하는 업무를 맡으면서 인프라 쪽 업무 범위를 넓혀가는 경우가 있다. 이 경험을 발판 삼아 배포 자동화나 환경 구성 업무로 역할을 확장하며 DevOps로 넘어간다.

  그대로 쓰는 것 · CI/CD 파이프라인에 대한 이해, 테스트 자동화 및 배포 프로세스 경험, 장애·이슈 트래킹 툴 활용 능력

  새로 채울 것 · 인프라·클라우드(AWS 등) 운영 지식, 컨테이너·오케스트레이션(Docker, Kubernetes), 모니터링·알림 시스템 구축 경험

• 보안3~6년차

  1~2년 준비가 필요하다

  QA 업무 중 보안 테스트(취약점 점검, 침투 테스트 보조)를 겸하게 된 인력이 별도로 보안 스터디와 자격증 준비를 병행해 전환하는 경로가 있다. 다만 QA와 보안은 요구 지식 체계가 달라 상당한 추가 학습이 필요하다.

  그대로 쓰는 것 · 취약점·엣지케이스를 찾는 테스트 마인드, 버그 리포트 및 재현 절차 작성 능력, 시스템 동작 흐름 이해

  새로 채울 것 · 보안 취약점 진단 및 모의해킹 기법, 네트워크·인증 보안 지식, 관련 보안 인증(자격증) 취득