QA 엔지니어 커리어 로드맵 예시

🔍 커리어 돌아보기

루미헬스

• 수행 레벨은 운영을 넘어 개선 단계예요. 회귀 케이스 320개를 우선순위 3단계로 재분류했고, 로그인·건강 데이터 연동·리포트 조회를 자동화해 수동 확인 시간을 6시간에서 2시간 30분으로 줄였어요. 릴리스 검증이라는 반복 업무의 범위와 순서를 바꾼 기록이 있어 단순 실행자로 보기는 어렵습니다.
• 난이도는 중간 이상으로 판정할 수 있어요. 건강 데이터 연동과 기기별 화면 검증처럼 상태와 조합이 있는 흐름을 다뤘고, 문의가 많은 기기 8종을 검증 범위로 고정했어요. 다만 서비스 트래픽, 장애 영향도, 테스트 실행 환경의 규모는 기록에 없어 대규모 운영 난이도까지는 판정할 수 없습니다.
• 시장 동시대성은 양호해요. Playwright 기반 UI 자동화와 테스트 데이터 생성 스크립트를 사용했고, 데이터 준비 시간을 40분에서 5분으로 낮췄어요. 다만 CI 파이프라인, API 테스트, 병렬 실행, 코드 구조와 유지보수 기준은 기록에 없어 자동화 엔지니어로서의 기술 폭은 추가 확인이 필요합니다.

청솔정보시스템

• 수행 레벨은 인수 검증 중심의 운영에서 개선으로 이동한 단계예요. 요구사항에서 검증 항목을 뽑아 사업 3건의 인수 시험을 마쳤고, 엑셀 결함 목록을 이슈 트래커로 옮겼어요. 검증 결과를 관리하는 방식을 바꾼 점은 개선 신호지만, 자동화 설계나 품질 전략 결정까지 했다는 근거는 없습니다.
• 난이도는 업무 이해관계가 있는 프로젝트 검증 수준이에요. 업무 담당자 인터뷰로 실제 사용 순서를 확인하고 시나리오를 다시 썼으며, 개발 지연으로 줄어드는 검증 기간을 항목별 소요 시간으로 기록했어요. 발주처 확인 절차와 일정 제약은 있었지만 시스템 규모나 장애 리스크는 기록되지 않았습니다.
• 시장 동시대성은 기본기가 중심이에요. 동시 접속 시험 시나리오 작성과 조회 화면 병목 확인 경험은 현재도 유효하지만, 이 시기의 기록에는 자동화 도구나 코드 산출물이 없습니다. 현재의 Playwright와 스크립트 경험이 과거 수동 검증 경험에 최신 기술의 연결 고리를 만들고 있습니다.

사내 스터디 - 테스트 자동화 도구 비교

• 수행 레벨은 비교 실험과 표준 도구 선정까지 진행한 설계 초기 단계예요. 같은 시나리오 10개를 세 도구로 작성하고 작성 시간과 실행 실패율을 비교한 뒤, 개발팀과 검토해 한 도구를 선택했어요. 개인 테스트 작성이 아니라 팀의 도구 선택 기준을 만든 점이 시장에서 읽히는 신호입니다.
• 난이도는 제한된 범위의 의사결정 과제로 판정해요. 유지보수 부담과 실행 안정성을 비교했지만 시나리오 수가 10개이고 실제 제품 규모, CI 환경, 장기 유지 비용은 기록되지 않았어요. 따라서 프레임워크 아키텍처를 설계했다고 확대할 수는 없고, 선택 근거를 수치화한 경험으로 보는 것이 정확합니다.
• 시장 동시대성은 목표 직무와 직접 맞닿아 있어요. 자동화 도구별 실패율과 유지보수 부담을 비교하고 팀 표준으로 연결한 기록은 도구 사용을 넘어 운영 기준을 세운 사례입니다. 다만 코드 리뷰, 패키지 구조, 병렬 실행, 실패 분석 체계가 남아야 엔지니어링 깊이를 더 증명할 수 있습니다.

📍 현재 위치

현재는 QA 사다리에서 테스트 실행 담당을 넘어 회귀 자동화와 품질 기준을 설계하는 미들 단계에 가까워요. 2022년부터 현재까지 한 회사에서 릴리스 흐름을 이해하고 개선 결과를 수치로 남겼으며, 최근에는 코드 작성이 업무의 55%를 차지할 정도로 자동화 비중이 커졌어요. 다만 자동화 엔지니어의 다음 단계인 프레임워크 오너십과 개발 파이프라인 설계까지는 아직 기록이 부족합니다.

강점

• 최근 업무에서 코드 작성이 55%, 검증이 45%로 바뀌었고 자동화 비중이 커졌어요. 시장에서는 검증 지식 위에 코드 산출물이 쌓이는 전환 신호로 읽힙니다. 목표 직무로 이동할 때 가장 중요한 기반은 이미 현업 안에서 확인되고 있어요.
• 테스트 실패율을 18%에서 3%로 낮추고 대기 조건이 부족한 구간을 수정했어요. 이는 자동화 테스트의 신뢰성을 수치로 관리한 사례라서 단순히 테스트를 작성한 것보다 강한 신호입니다. 목표 직무에서는 실행 안정성과 실패 원인 분리가 핵심이므로 이 경험을 프레임워크 운영으로 확장해야 합니다.
• 릴리스 허용 결함 기준과 탐색적 테스트 세션을 만들었고, 세션 3회에서 결함 12건을 발견했어요. 품질 판단과 자동화 범위를 함께 볼 수 있다는 점이 강점입니다. 테스트 자동화 엔지니어가 개발팀에 자동화 우선순위를 설명할 때 필요한 제품 판단의 근거가 됩니다.

공백

• Playwright UI 자동화와 데이터 생성 스크립트는 확인되지만 CI에서 자동 실행하고 결과를 배포 판단에 연결한 기록은 없어요. 시장에서는 코드 작성 자체보다 파이프라인 안에서 반복 실행되는 테스트 자산을 더 높은 단계로 봅니다. 목표 대비 CI 연동, 병렬화, 리포트 게시를 하나의 업무로 남겨야 해요.
• 자동화 코드의 모듈 구조, 리뷰 규칙, API·계약 테스트, 성능 테스트 설계는 기록이 얇아요. 도구를 사용할 수 있다는 신호와 자동화 시스템을 설계할 수 있다는 신호 사이에 차이가 있습니다. 개발 전환 여부를 판단하려면 함수·클래스 설계, 테스트 가능한 코드 작성, 변경 유지보수 기록을 별도로 확인해야 합니다.

🧭 목표 대비 격차

이미 준비된 것

• 회귀 케이스 320개를 우선순위로 분류하고 핵심 흐름을 자동화했어요. 목표 직무 가이드에서 말하는 자동화 구축과 품질 범위 설정의 출발점이 이미 현 직장 업무에 있습니다. 경로 A에서 자동화 범위를 API와 CI까지 확장하면 가장 빠르게 다음 증거를 만들 수 있어요.
• 테스트 실패율을 18%에서 3%로 줄이고 데이터 준비 시간을 40분에서 5분으로 낮췄어요. 자동화 도구의 실행 신뢰성과 테스트 전제조건을 개선한 결과가 수치로 남아 있어 시장에서 재현 가능한 사례로 제시할 수 있습니다. 경로 A의 프레임워크 운영이나 경로 B의 공개 프로젝트에서 이 수치를 설계 판단과 연결하면 됩니다.

비어 있는 것

• CI에서 자동화 테스트를 실행하고 결과를 릴리스 게이트로 연결한 경험이 비어 있어요. 테스트 자동화 엔지니어는 로컬 실행 가능한 스크립트보다 커밋, 배포, 결과 통지까지 이어지는 파이프라인을 설계해야 하므로 결정적인 공백입니다. 현재 팀의 저장소와 배포 흐름에 접근할 수 있으면 경로 A, 접근이 막히면 경로 B에서 작은 서비스로 증명해야 해요.
• UI 테스트 외 API·계약 테스트와 테스트 피라미드에 따른 투자 판단 기록이 부족해요. UI만 늘리면 실행 시간이 길고 실패 원인 분리가 어려워지므로 목표 직무에서는 계층별 테스트 설계가 중요합니다. 현 직장에서 핵심 API 일부를 자동화하고 전후 실행 시간과 결함 발견 위치를 기록하는 것이 우선이며, 개인 프로젝트는 보조 수단입니다.
• 자동화 코드의 구조 설계와 유지보수 기준이 비어 있어요. 도구 3종을 비교한 근거는 있지만 프레임워크 디렉터리 구조, 픽스처, 공통 함수, 데이터 격리, 리뷰 기준을 만든 기록은 없습니다. 경로 A에서 팀 표준으로 문서화하는 것이 가장 설득력 있고, 경로 B는 코드 공개와 테스트 결과로 개발 전환 가능성을 확인하는 데 적합해요.
• 대규모 테스트 병렬 실행과 실제 릴리스 리스크를 다룬 경험은 아직 확인되지 않아요. 개인 프로젝트로 병렬 실행 구조는 보여줄 수 있지만 조직 규모의 릴리스 판단과 운영 부담까지 증명할 수는 없습니다. 현재 회사에서 릴리스 기준과 자동화 결과를 실제 배포 의사결정에 연결하고, 규모가 구조적으로 작으면 이후 경로 C를 검토해야 합니다.

방향 비교

• 테스트 자동화 엔지니어는 현재 경험과 거리가 가장 짧아요. Playwright, 데이터 생성, 실패율 개선, 릴리스 기준이 바로 연결되지만 CI와 코드 구조가 다음 관문입니다.
• 개발 전환은 가능하지만 현재 기록만으로는 QA 자동화 개발자에 가까워요. API 서버나 제품 기능을 설계·구현한 증거가 없으므로 90일 동안 작은 서비스의 백엔드 코드와 테스트를 직접 만들어 적합성을 확인해야 합니다.
• 자동화 전문성을 먼저 확보한 뒤 개발로 확장하는 순서가 리스크가 낮아요. 코드 작성이 이미 업무의 55%로 늘었으므로 현 직장의 자동화 범위를 넓히면서 개인 프로젝트에서 개발 축을 시험하는 방식이 맞습니다.

🔀 경로 선택

🏢 경로 A · 현 직장 안에서

CI 실행 범위 확보

당장 저장소와 배포 담당자에게 Playwright 핵심 스위트를 CI의 검증 단계에서 실행하는 업무를 제안하세요. 현재 자동화는 수동 확인 시간을 6시간에서 2시간 30분으로 줄였지만, CI 연결 기록이 없어 테스트 자산의 운영 범위를 증명하지 못하므로 이 공백을 먼저 메워야 해요. 90일 안에 실행 횟수, 전체 소요 시간, 실패율 18%에서 3%로 낮춘 기준, 실패 원인별 분류, 결과 게시 위치를 기록하세요.

API 테스트 우선순위

핵심 흐름의 로그인, 건강 데이터 연동, 리포트 조회 API를 찾아 UI 테스트와 겹치는 검증을 API 단계로 옮기는 제안을 하세요. 현재 자동화가 UI 핵심 흐름에 집중되어 있어 실행 시간이 길어질 수 있고, 테스트 계층을 설계했다는 증거가 부족하므로 API 자동화가 다음 단계에 필요합니다. 대상 API 수, 시나리오 수, UI 테스트에서 제거한 중복, 실행 시간 변화, 발견 결함을 테스트 기록에 남기세요.

프레임워크 구조 표준화

Playwright 코드의 픽스처, 테스트 데이터, 공통 동작, 환경 설정, 리포트 영역을 나누고 리뷰 기준을 문서로 제안하세요. 테스트 데이터 생성 시간을 40분에서 5분으로 줄인 스크립트는 기반이 있지만, 유지보수 가능한 구조를 설계했다는 기록은 아직 없어요. 변경 전후 디렉터리 구조, 공통 코드 재사용 수, 리뷰 PR 수, flaky 테스트 재발 건수를 저장하세요.

릴리스 게이트 운영

기존 치명도별 결함 허용 기준에 자동화 결과를 넣어 배포 전 판단 문서로 운영하세요. 현재 기준은 문서 합의까지 갔지만 자동화 통과율, 실패 원인, 보류 조건의 연결이 기록되지 않아 품질 전략의 끝단이 비어 있습니다. 릴리스별 자동화 실행 수, 통과율, 결함 발견 수, 보류 또는 승인 사유, 배포 후 유출 결함을 3회 이상 기록하세요.

🧪 경로 B · 개인 프로젝트로

실배포 테스트 서비스

건강 기록 조회나 일정 관리처럼 도메인 하나를 정해 백엔드 API, 데이터베이스, Playwright UI 테스트를 포함한 작은 서비스를 만드세요. 시장 신호가 되려면 실제 배포, 테스트 데이터 격리, API와 UI 계층 분리, CI 실행 결과가 있어야 하며 화면 몇 개와 단순 스크립트만 있으면 목표 수준에 통하지 않습니다. 6주 동안 저장소, 설계 문서, 테스트 코드, CI 실행 화면, 실패 수정 기록을 산출물로 남기세요.

테스트 프레임워크 패키지

Playwright 공통 픽스처와 데이터 생성기를 별도 패키지 형태로 정리하고 예제 서비스에 적용하세요. 설정 분리, 재사용 가능한 fixture, 병렬 실행, 실패 시 trace와 리포트 생성까지 포함해야 자동화 엔지니어링 신호가 되며 단순 테스트 파일 모음은 부족합니다. 4주 동안 패키지 구조 문서, 사용 예제, 실행 시간과 실패율 비교, 변경 이력과 테스트를 결과물로 남기세요.

API 계약 검증 도구

간단한 REST 서비스 두 개를 만들고 OpenAPI 계약과 요청·응답 검증 테스트를 연결하세요. 정상 흐름뿐 아니라 인증 실패, 필수 필드 누락, 스키마 변경 감지와 CI 실패까지 보여줘야 API 자동화와 개발 전환 가능성을 함께 판단할 수 있습니다. 5주 동안 API 명세, 테스트 코드, 고장 주입 사례, CI 로그, 기술 회고 문서를 산출하세요.

개인 프로젝트로는 안 되는 것

개인 프로젝트로 실제 조직의 릴리스 리스크 판단, 여러 개발자 사이의 리뷰 규칙, 운영 중 장애 대응을 완전히 증명할 수는 없어요. 현 직장에서 릴리스 게이트와 자동화 결과를 실제 배포 판단에 연결하고, 이후에도 트래픽과 배포 규모가 작아 경험이 생기지 않으면 이직으로 보완해야 합니다.

🧳 경로 C · 이직 관점

현 시점에는 이직이 필요하지 않아요. QA 2명인 현재 회사에서도 CI 실행, API 테스트, 릴리스 게이트, 프레임워크 구조를 만들 여지가 있고, 최근 코드 작성이 업무의 55%까지 늘었기 때문입니다. 다만 2개 분기 안에 저장소·배포 접근 권한이 없거나 자동화 결과를 릴리스에 연결할 수 없고 수동 회귀만 반복된다면 이직을 재검토하세요.

성장 중인 제품 조직

커머스, 핀테크, 헬스케어 SaaS처럼 웹 제품을 직접 운영하고 QA 자동화와 개발 협업이 분리되지 않은 중간 규모 회사를 우선 보세요. 현 직장에서 CI 스위트, API 테스트, 릴리스 게이트를 만들고 그 결과를 기록한 뒤 지원해야 현재의 수동 회귀 경험과 자동화 설계 신호를 구분해 보여줄 수 있어요. 현재는 Playwright와 수치화된 개선이 통하지만 CI 운영과 코드 구조가 없으면 테스트 작성자로만 읽힐 가능성이 있습니다.

자동화 전담 QA팀

QA 자동화 전담자가 있고 개발 파이프라인에 테스트가 포함된 제품 조직을 보세요. 90일 목표에서 프레임워크 구조와 API 테스트를 완성한 뒤, 코드 리뷰와 CI 실패 처리 기록을 갖고 면접에 들어가는 시점이 적절합니다. 현재의 실패율 18%에서 3% 개선과 데이터 준비 40분에서 5분 단축은 강하지만 팀 단위 표준 운영 근거가 더 필요합니다.

개발 전환형 조직

개발 전환을 선택한다면 테스트 인프라, 개발자 생산성, 백엔드 품질 도구를 다루는 작은 플랫폼 또는 제품 팀을 우선 탐색하세요. 개인 프로젝트에서 API 서버와 데이터베이스를 만들고 코드 리뷰 가능한 저장소를 완성한 뒤 지원하면 QA 도메인 지식이 전이 경험으로 설명됩니다. 반대로 제품 기능 개발 경력과 서버 설계 기록이 없는 상태에서 일반 백엔드 포지션만 지원하면 현재 증거로는 경쟁력이 약합니다.

🎯 단기 목표 (분기)

• CI 자동화 스위트 연결경로 A · 현 직장

  달성 판정: Playwright 핵심 스위트를 CI에서 3회 이상 실행하고, 실행 시간·통과율·실패 원인·결과 게시 위치를 기록하면 달성으로 봅니다.

• API 테스트 계층 구축경로 A · 현 직장

  달성 판정: 로그인·건강 데이터 연동·리포트 조회 중 최소 2개 흐름에 API 테스트를 추가하고 UI 중복 제거와 실행 시간 변화를 기록하면 달성입니다.

• 자동화 구조 문서화경로 A · 현 직장

  달성 판정: 픽스처·데이터·공통 동작·환경 설정의 구조 문서 1건과 리뷰 PR 2건, 변경 전후 flaky 테스트 기록을 남기면 달성입니다.

⚠️ 리스크·막힘 지점

• 현재 QA 인원이 2명이라 릴리스 수동 검증이 급증하면 자동화 구조 개선 시간이 사라질 수 있어요.

  대안핵심 흐름 1개와 API 테스트 1개만 먼저 CI에 연결하고, 나머지는 개인 프로젝트의 동일 구조로 증명합니다.

• 저장소나 배포 파이프라인 접근 권한을 받을 수 없어 CI 실행과 릴리스 게이트를 현 직장에서 만들 수 없을 수 있어요.

  대안접근이 가능한 테스트 저장소를 별도로 만들고 실배포 개인 서비스에서 CI 로그와 실패 수정 기록을 남긴 뒤, 2개 분기 시점에 이직을 재검토합니다.