QA·QC·테스터 — 역할·조직 구조·태도·커리어 전망

개념

이 모듈의 마지막 질문 — 그래서 이걸 누가 하는가

이 모듈에서 우리는 품질과 결함이 무엇인지(레슨 1), 검증과 확인이 어떻게 다른지(레슨 2), 테스트에 어떤 레벨과 유형이 있는지(레슨 3·4), 그리고 완전한 테스트가 왜 불가능한지(레슨 5)를 봤다. 전부 무엇을 하는가에 대한 이야기였다.

마지막으로 남은 질문은 누가, 어떤 자리에서, 어떤 권한으로 그것을 하는가다. 같은 "테스트 케이스 실행"이라도, 개발팀 안에 앉아 있는 사람이 하는 것과 별도 QA팀에서 넘겨받아 하는 것은 완전히 다른 일이 된다. 전자는 만들어지는 중에 끼어들 수 있고, 후자는 다 만들어진 뒤에야 검사한다. 레슨 1에서 배운 "결함은 늦게 발견할수록 비싸다"는 원리가, 조직도를 어떻게 그렸느냐에 따라 결과가 달라지는 것이다.

그래서 이 레슨은 "용어 정리 레슨"처럼 보이지만 실은 커리어 레슨이다. 직함의 뜻을 아는 게 목적이 아니라, 자기가 앉게 될 자리가 어떤 자리인지 알아보는 눈을 만드는 게 목적이다.

이 레슨을 마치면 채용공고 한 장을 보고 "이 자리는 QA인가 QC인가, 개입 시점은 언제인가, 나는 여기서 무엇을 배울 수 있는가"를 스스로 판정할 수 있게 된다.

QA와 QC는 이론적으로 다르다

• QA (Quality Assurance, 품질 보증): 프로세스에 초점. "품질 좋은 결과물이 나오도록 하는 절차를 우리가 따르고 있는가"를 관리한다. 예방적(preventive)이다 — 결함이 생기기 전에 막으려 한다. 요구사항 리뷰 프로세스 개선, 코드 리뷰 기준 수립, 테스트 전략 수립 같은 활동이 여기 속한다.
• QC (Quality Control, 품질 관리): 결과물에 초점. "이 특정 산출물이 품질 기준을 만족하는가"를 검사한다. 발견적(detective)이다 — 이미 만들어진 것에서 결함을 찾는다. 테스트 케이스 실행, 결함 리포팅이 여기 속한다.
• 테스터(Tester): 실제로 테스트 활동을 수행하는 사람. QC 활동의 실행 주체에 가깝지만, 테스트 설계·전략까지 관여하면 QA 활동도 함께 한다.

두 개념은 원래 소프트웨어가 아니라 제조업에서 나왔다. 공장에서 QC는 컨베이어 끝에 서서 완성된 제품을 집어 들고 불량을 골라내는 일이고, QA는 "애초에 왜 불량이 나오는가"를 따져 설비 점검 주기를 바꾸고 작업 표준서를 고치는 일이다. 두 사람 모두 품질을 위해 일하지만, 한 명은 물건을 보고 한 명은 공정을 본다. 소프트웨어에서도 뼈대는 같다.

마지막 줄이 중요하다. QA가 없으면 같은 버그가 매 릴리즈 반복되고, QC가 없으면 이번 릴리즈의 버그를 놓친다. 두 실패는 종류가 다르므로 둘 다 필요하다.

실무에서는 이 구분이 흐려진다 — 왜인가

이론은 이렇지만 실무에서는 구분이 거의 흐려진다. "QA 엔지니어"라는 직함을 가진 사람이 테스트 케이스도 실행하고(QC), 테스트 전략도 짜고(QA), 프로세스 개선도 제안한다.

흐려지는 이유는 두 가지다. 첫째, 소프트웨어는 제조업과 달리 같은 사람이 검사도 하고 공정도 고칠 수 있다. 컨베이어를 멈추지 않아도 테스트 케이스를 고칠 수 있으니 굳이 사람을 나눌 이유가 적다. 둘째, 애자일(한 번에 전부 만들지 않고 2주쯤씩 끊어 만들고 바로 보여 주며 고쳐 나가는 방식) 이후 팀이 작아지면서 역할을 잘게 쪼갤 인원 자체가 없다. 5명짜리 팀에 QA가 한 명이면 그 한 명이 전부 한다.

그래서 결론은 이것이다. 채용공고의 직함(QA Engineer, Test Engineer, QC Analyst, SDET)만으로 업무 범위를 단정하지 말고, 직무 설명(JD)의 실제 책임 항목을 봐야 한다. 직함은 회사가 정하고, 업무는 JD가 정한다.

같은 직함, 다른 일 — 공고 문구 해부

특히 헷갈리는 세 직함을 실제 공고 문구로 갈라보자.

SDET vs QA Automation Engineer. 둘 다 자동화를 다루지만 무게중심이 다르다.

즉 SDET 공고에 "자료구조·알고리즘 코딩테스트"가 붙어 있다면 오타가 아니다. 그 회사는 SDET을 테스트를 담당하는 개발자로 정의한 것이다.

"QA Lead"는 회사마다 완전히 다른 일이다. 같은 직함으로 최소 세 가지가 돌아다닌다.

세 번째가 주니어에게 가장 위험하다. "리드"라는 직함에 끌려 들어갔는데 가르쳐 줄 선배도, 물려받을 프로세스도 없는 경우다. 나쁜 자리라는 뜻은 아니다 — 다만 혼자 판단해야 하는 자리라는 걸 알고 들어가야 한다. 면접에서 "지금 QA 조직에 몇 분이 계시고, 제가 합류하면 누구에게 보고하나요?"를 물으면 세 유형이 바로 갈린다.

조직에 따라 QA가 배치되는 방식이 다르다

• 임베디드형: QA가 개발팀 안에 소속되어 스프린트마다 함께 일한다. 애자일 조직에서 흔하다. 빠른 피드백이 장점, 다른 팀과의 기준 통일이 어려울 수 있다.
• 독립 QA팀형: QA가 별도 팀으로 존재하며 여러 개발팀을 지원한다. 표준화된 프로세스와 전문성 확보가 장점, 개발과의 커뮤니케이션 오버헤드가 단점이 될 수 있다.
• QA 길드/커뮤니티형: 각 팀에 QA가 흩어져 있지만, 정기적으로 모여 기준과 도구를 맞춘다. 두 방식의 장점을 절충하려는 시도다.

세 방식은 당신이 언제 개입할 수 있는지를 결정한다.

레슨 1의 "결함은 늦게 발견할수록 비싸다"를 여기 겹쳐 보면, 임베디드형이 비용 면에서 유리하다는 게 보인다. 그런데도 독립 QA팀형이 사라지지 않는 이유는 규제 산업 때문이다. 의료기기·자동차·금융처럼 "검사한 사람이 만든 사람과 독립적이어야 한다"는 요구가 법·표준으로 걸려 있으면, 효율보다 독립성이 우선한다.

면접에서 "이 회사는 QA를 어떻게 조직하나요?"를 물어보면 실제 업무 범위를 가늠하는 데 도움이 된다. 한 걸음 더 나아간 질문은 "QA가 요구사항 리뷰에 들어가나요?" 다. 들어간다면 예방(QA)까지 하는 자리고, 안 들어간다면 사실상 QC 자리다.

QA의 태도 — 실제 말로 옮기면 이렇게 된다

기술보다 태도가 QA를 정의한다는 말이 있다. 그런데 "회의주의를 가져라" 같은 말은 실천으로 옮기기 어렵다. 각각이 실제로 어떤 문장으로 나오는지를 보자.

1. 호기심 있는 회의주의

"이게 정말 명세대로일까?"를 기본값으로 의심하되, 트집 잡기가 아니라 더 나은 제품을 만들기 위한 태도로 접근한다. 실제로는 질문의 형태로 나온다.

공통 형태가 보인다. "틀렸다"가 아니라 "이 경우는 어떻게 되나요"다. 회의주의는 반박이 아니라 아직 정해지지 않은 것을 찾아내는 질문이다. 레슨 5에서 배운 "완전한 테스트는 불가능하다"를 떠올리면 이 태도의 의미가 분명해진다 — 전부 확인할 수 없으니, 아무도 생각 안 한 곳을 골라 묻는 능력이 곧 실력이다.

2. 사용자 대변

개발팀 내부에서 유일하게 "실제로 이걸 쓰는 사람 입장"을 계속 상기시키는 역할을 자처한다. 이건 취향 주장과 구분해야 한다.

• 취향 주장: "이 버튼 위치 마음에 안 들어요."
• 사용자 대변: "이 버튼이 스크롤 아래에 있어서, 모바일에서는 결제 단계에서 한 번 더 스크롤해야 보입니다. 고객센터 문의 중 '결제 버튼이 없다'는 문의가 지난달 12건 있었습니다."

차이는 근거가 사용자에게 있는가다. 데이터가 없으면 "제가 처음 보는 사람이라 가정하고 따라가 봤는데 여기서 멈췄습니다"처럼 관찰 사실로 말한다.

3. 비난 없는 커뮤니케이션

결함을 "누가 잘못했나"가 아니라 "무엇이 어떻게 다른가"로 전달한다. 같은 버그를 두 가지로 써 보면 차이가 분명하다.

오른쪽 문장들의 공통점은 주어가 사람이 아니라 현상이라는 것이고, 끝이 요청이나 제안으로 열려 있다는 것이다. 이건 모듈 6(결함 관리와 보고)에서 리포트 양식 수준으로 구체적으로 다룬다.

QA가 '품질 경찰'로 오해받을 때

주니어 QA가 가장 자주 부딪히는 조직적 갈등이다. 증상은 이렇게 나타난다 — QA가 회의에 들어가면 분위기가 굳는다, 개발자가 "이거 QA한테 걸리겠는데"라고 말한다, 결함을 등록하면 먼저 방어부터 돌아온다.

원인은 대개 QA 개인의 인성이 아니라 구조다. QA가 마지막에만 등장해서 "안 된다"만 말하는 자리에 놓이면, 아무리 좋은 사람이 앉아도 경찰처럼 보인다. 그래서 해법도 개인의 말투 교정보다 등장 시점을 앞당기는 것에 있다.

주니어가 오늘부터 할 수 있는 것 세 가지다.

1. 좋은 소식도 전한다. 결함만 보고하면 QA의 발언은 전부 나쁜 소식이 된다. "이번 수정으로 지난번 이슈 세 건이 같이 해결된 걸 확인했습니다" 같은 확인도 보고한다.
2. 막지 말고 판단 재료를 준다. "출시하면 안 됩니다"보다 "이대로 나가면 결제 중복 청구 가능성이 있고, 영향 범위는 카드 결제 사용자 전체입니다"가 훨씬 강하다. 결정은 조직이 하지만, 근거는 QA가 만든다.
3. 개발자가 재현하기 쉽게 만든다. 반송의 대부분은 재현 실패에서 온다. 환경·계정·시각·로그를 붙이는 것만으로 관계가 눈에 띄게 좋아진다.

주니어의 역할 혼란 — "저는 QA로 뽑혔는데 왜 자동화까지 하나요"

입사하고 몇 주가 지나면 이런 순간이 온다. 전형적인 상황 세 가지와, 그걸 어떻게 이해하면 좋은지 보자.

상황 1 — "자동화 스크립트를 짜라고 합니다." 공고에는 "테스트 케이스 작성 및 실행"만 있었는데 Playwright 코드를 맡긴다. 당황스럽지만, 이건 대개 회사가 속인 게 아니라 QA 직무의 기본선이 지난 몇 년간 올라간 결과다. 회귀 테스트가 매 스프린트 쌓이는데 손으로만 하면 어느 시점부터 물리적으로 불가능해진다. 대응은 이렇게 한다 — 거부하거나 전부 떠안는 대신, "이번 분기에는 회귀 스위트 중 상위 20건만 자동화하고, 그동안 수동 회귀 범위는 이렇게 줄이겠습니다"처럼 범위를 문서로 만든다. 스테이지 4가 이 능력을 다룬다.

상황 2 — "개발자가 짠 단위 테스트(부품 하나만 따로 돌려 보는 시험)가 있으니 저는 뭘 하죠?" 레슨 3의 테스트 레벨을 떠올리면 답이 나온다. 단위 테스트는 부품 하나가 설계대로 도는지를 본다. 부품 여러 개를 이어 붙였을 때, 실제 데이터로, 실제 사용자 흐름으로 무너지는 지점은 단위 테스트가 못 본다. 역할이 겹치는 게 아니라 레벨이 다른 것이다.

상황 3 — "요구사항이 애매한데 이걸 정하는 게 제 일인가요?" 정하는 건 QA의 일이 아니지만, 애매하다는 사실을 드러내는 건 QA의 일이다. 레슨 2의 확인(validation) — 맞는 것을 만들고 있는가 — 이 여기서 작동한다. "이 문장은 두 가지로 읽힙니다. A로 읽으면 이렇게, B로 읽으면 이렇게 테스트가 달라집니다. 어느 쪽인가요?"까지가 QA의 몫이고, 결정은 기획·개발과 함께한다.

세 상황을 관통하는 원칙은 하나다. 직함이 아니라 팀이 지금 못 하고 있는 일이 당신의 일이다. 다만 무한정 떠안으라는 뜻은 아니다 — 늘어난 범위는 반드시 말로 하지 말고 문서로 합의해 둔다. 평가 시즌에 "그건 원래 네 일이 아니었지"가 되지 않게.

QA 커리어는 한 방향만 있지 않다

• 관리 트랙: 주니어 테스터 → QA 엔지니어 → 시니어/리드 QA → QA 매니저
• 기술 트랙: QA 엔지니어 → 자동화 엔지니어(SDET) → 테스트 아키텍트
• 인접 분야로 이동: DevOps/플랫폼 엔지니어링, 프로덕트 매니저, 그리고 최근엔 AI QA(스테이지 6에서 다룬다) 같은 새 전문 분야로도 이동한다

"관리자가 되는 것"만이 성장이 아니다 — 자동화·성능·보안·AI 검증처럼 깊이 파고드는 기술 전문성도 동등한 성장 경로다. 이 커리큘럼의 스테이지 4(자동화), 5(비기능), 6(AI)이 각각 이런 전문화 방향과 맞닿아 있다.

아직 방향을 못 정했다면 — 몰입으로 가늠하는 자가진단

주니어에게 "관리와 기술 중 뭐가 좋냐"고 물으면 대개 답할 수 없다. 둘 다 해본 적이 없기 때문이다. 그래서 하고 싶은 일이 아니라 이미 해본 일 중 시간 가는 줄 몰랐던 것으로 가늠한다. 아래 항목에 정직하게 답해보자.

A가 많으면 기술 트랙, B가 많으면 관리 트랙 쪽 성향이다. 다만 이건 진로 판정이 아니라 다음 3개월에 무엇을 시도해볼지에 대한 힌트다. 섞여 나왔다면 아주 정상이고, 실제로 시니어 QA 상당수는 두 쪽을 오간다. 그리고 순서에는 정답이 없지만, 기술 트랙을 먼저 밟은 뒤 관리로 가는 경로가 되돌아오기 쉽다 — 관리로 먼저 가면 기술 감각이 유지되기 어렵다.

실무에서 왜 필요한가

QA와 QC, 테스터의 차이를 알고 있으면 채용공고를 읽을 때 실제로 어떤 일을 하게 될지 가늠할 수 있다. "QC 엔지니어"로 채용됐는데 막상 테스트 전략 수립까지 요구받거나, 반대로 "QA 리드"로 뽑혔는데 실행 업무만 반복해야 한다면 기대와 실제가 어긋난다. 조직 구조를 이해하면 입사 후 "내가 릴리즈를 막을 권한이 있는지, 있다면 어느 선까지인지"도 미리 가늠할 수 있다.

사례 연구 — 입사 3개월 차 주니어의 한 주

지현은 이커머스 회사에 QA 엔지니어로 입사했다. 공고에는 "테스트 케이스 작성·실행, 결함 리포팅"이라고 적혀 있었다.

월요일. 스프린트 계획 회의에 불려간다. 기획자가 "쿠폰 중복 사용 허용"이라고 말한다. 지현은 아무 말도 못 하고 받아 적는다. — 여기서 놓친 것: "중복이 같은 쿠폰 두 장인가요, 다른 종류 두 장인가요?" 이 질문 하나면 나중에 이틀 걸릴 재작업이 사라졌다. 이건 QC가 아니라 QA 활동이고, 임베디드형 조직이라 가능한 개입이다.

수요일. 개발이 끝나고 테스트를 시작한다. 쿠폰 두 장을 겹쳐 쓰니 할인이 원금보다 커져 결제 금액이 음수가 된다. 지현은 티켓에 "쿠폰 중복 시 오류"라고 쓴다. — 여기서 놓친 것: 재현 계정, 쿠폰 코드, 스크린샷, 그리고 "명세 어느 항목과 다른가". 개발자는 다음 날 "재현 안 됩니다"로 반송한다.

목요일. 반송된 티켓을 두고 감정이 상한다. "제대로 안 보신 것 같은데요"라고 쓰려다 멈추고, 대신 자기 계정·쿠폰 코드·시각·네트워크 로그를 붙여 다시 올린다. 30분 만에 원인이 나온다. 특정 프로모션 쿠폰만 금액 검증을 건너뛰고 있었다.

금요일. 팀장이 "이런 게 또 있을 것 같은데 전수로 볼 방법 없냐"고 묻는다. 지현은 쿠폰 종류별 조합표를 만들어 어떤 조합이 검증을 안 거치는지 정리한다. — 이 순간 지현이 한 일은 QC가 아니라 QA다. 개별 버그를 잡은 게 아니라 버그가 새어 나오는 구멍의 모양을 그렸기 때문이다.

한 주 안에 지현은 QC(실행·리포팅), QA(전략·프로세스), 커뮤니케이션(반송 대응)을 전부 했다. 직함은 하나였지만 활동은 세 종류였다. 이 레슨의 용어들은 시험 문제가 아니라, 자기가 방금 한 일이 어느 쪽이었는지 알아보고 이력서에 쓸 수 있게 하는 도구다.

채용시장에서의 위치

한국 채용시장에서도 "QA 엔지니어", "테스트 엔지니어", "SDET(Software Development Engineer in Test)", "QA 매니저" 같은 직함이 회사마다 다른 범위로 쓰인다. 스타트업은 한 사람이 QA·QC·자동화를 전부 겸하는 경우가 많고, 대기업·제조업(특히 의료기기·자동차 같은 규제 산업)은 QA와 QC가 조직적으로 분리되어 있는 경우가 흔하다.

공고 문구를 신호로 읽는 법

공고에는 회사가 의도하지 않은 정보가 자주 새어 나온다.

면접에서 실제로 이렇게 물어본다

역할 구분은 신입·주니어 면접의 단골 주제다. 예상 질문과 답의 방향이다.

첫 질문에서 정의만 외워 말하고 끝내는 지원자가 매우 많다. 정의 → 실무에서 흐려짐 → 내 경험은 어느 쪽 3단으로 답하면 그 자리에서 구분된다.

이력서에 쓸 때

이력서에 "QA"라고 쓰기 전에, 실제로 자신이 한 일이 프로세스 개선(QA)에 가까운지 테스트 실행(QC)에 가까운지 구분해서 적으면 채용 담당자에게 더 명확하게 전달된다.

• 약한 표현: "테스트 케이스를 작성하고 실행했습니다."
• 강한 표현(QC): "결제 모듈 회귀 스위트 120건을 유지하며 릴리즈당 평균 8건의 결함을 릴리즈 전에 발견했습니다."
• 강한 표현(QA): "쿠폰 조합 검증 누락 패턴을 정리해 요구사항 리뷰 체크리스트에 반영했고, 이후 동일 유형 결함이 재발하지 않았습니다."

두 번째와 세 번째는 같은 사람이 같은 분기에 한 일일 수 있다. 구분해 적으면 "실행도 하고 개선도 하는 사람"으로 읽힌다.

실습 과제

과제 1 — 공고 분석하기 (10분)

아래 두 가상의 채용공고 설명을 읽고, 이론적 정의에 따라 QA에 가까운지 QC에 가까운지, 그리고 왜 그렇게 판단했는지 적는다.

공고 A: "테스트 케이스를 작성·실행하고 결함을 리포팅합니다. 릴리즈 전 회귀 테스트 스위트를 수행합니다."

공고 B: "테스트 전략을 수립하고, 팀의 테스트 프로세스를 개선하며, 품질 지표를 정의하고 추적합니다."

과제 2 — 직함 뒤의 실제 업무 추측하기 (10분)

아래 세 공고 조각을 읽고, 각각 SDET / QA Automation Engineer / 1인 QA 중 무엇에 가까운지 고르고 근거를 한 줄로 적는다.

① "사내 테스트 프레임워크를 설계하고, 제품 코드의 테스트 용이성 개선에 참여합니다. 채용 절차에 코딩 테스트가 포함됩니다."

② "QA 프로세스가 아직 없습니다. 테스트 기준 수립부터 실행, 릴리즈 판단까지 주도하실 분을 찾습니다."

③ "Playwright 기반 회귀 테스트 스위트를 확장하고, 실패 케이스를 분석해 개발팀에 전달합니다."

과제 3 — 문장 고쳐 쓰기 (10분)

아래 세 문장을 비난 없는 커뮤니케이션으로 고쳐 쓴다. 규칙은 두 가지 — 주어를 사람이 아니라 현상으로, 끝을 요청이나 제안으로.

1. "이거 테스트 안 해보고 올리신 거죠?"
2. "명세대로 안 만드셨네요."
3. "이 상태로는 절대 릴리즈 못 합니다."

과제 4 — 역할 혼란 상황 대처하기 (10분)

당신은 "테스트 케이스 작성·실행"으로 입사했는데, 팀장이 자동화 스크립트 작성을 맡겼다. 어떻게 반응할지 세 문장으로 적어본다. 거절도, 무조건 수용도 아닌 답을 목표로 한다.

과제 5 — 나의 방향 그려보기 (10분)

앞의 자가진단 표 6문항에 답해보고, A와 B 중 어느 쪽이 많았는지 센다. 그 결과가 지금 자신의 느낌과 맞는지, 다르다면 왜 다른지 2~3문장으로 적는다. 아직 잘 모르겠다면 "왜 아직 판단하기 이른지"를 적어도 된다 — 이 커리큘럼을 끝까지 밟아가며 다시 답해봐도 좋다.

여유가 있다면 한 가지를 더 한다. 실제 채용 사이트에서 QA 공고 다섯 개를 열어, 각각을 QA 성격 / QC 성격 / SDET 성격으로 분류해본다. 다섯 개만 봐도 "시장이 지금 어느 쪽 사람을 더 찾는지"가 보인다.

자가 체크리스트

• QA(프로세스)와 QC(결과물)의 이론적 차이를 설명할 수 있다
• QA가 없을 때와 QC가 없을 때 각각 어떤 실패가 생기는지 구분할 수 있다
• 실무에서 이 구분이 왜 자주 흐려지는지 두 가지 이유로 설명할 수 있다
• SDET과 QA Automation Engineer의 차이를 산출물 기준으로 설명할 수 있다
• "QA Lead" 공고를 보고 세 유형 중 어느 쪽인지 물어볼 질문을 만들 수 있다
• 조직에 QA가 배치되는 세 가지 방식(임베디드/독립팀/길드)을 구분할 수 있다
• 조직 구조가 개입 시점과 릴리즈 권한을 어떻게 바꾸는지 설명할 수 있다
• QA의 태도 세 가지를 실제 문장 형태의 예로 들 수 있다
• 비난 있는 표현을 현상 중심 표현으로 고쳐 쓸 수 있다
• QA가 품질 경찰로 오해받는 원인이 구조에 있다는 것을 설명할 수 있다
• 공고에 없던 업무를 맡았을 때 범위를 합의하는 방식으로 대응할 수 있다
• QA 커리어가 관리 트랙 외에 기술 트랙으로도 뻗어간다는 것을 안다
• 면접에서 QA/QC 차이를 물었을 때 자기 경험까지 연결해 답할 수 있다

흔한 실수

• QA와 QC를 완전히 같은 말로 취급한다. 실무에서 섞여 쓰이는 건 맞지만, 이력서나 면접에서 "내가 한 일이 정확히 무엇이었는가"를 설명할 때는 구분할 수 있어야 설득력이 생긴다.
• 직함만 보고 업무를 단정한다. 같은 "QA Lead"가 회사마다 팀 관리, 기술 리딩, 1인 QA로 갈린다. 판단은 JD의 책임 항목과 면접 질문으로 한다.
• QA를 "릴리즈를 막는 사람"으로만 정의한다. 막는 것 자체가 목적이 아니라, 리스크를 근거로 판단을 돕는 역할이다(모듈 4에서 Go/No-Go 판단을 다룬다).
• 결함만 보고하고 확인 결과는 보고하지 않는다. QA의 발언이 전부 나쁜 소식이 되면, 사람이 아니라 역할 자체가 경계 대상이 된다.
• 개발자와의 갈등을 말투 문제로만 본다. 원인은 대개 QA가 마지막에만 등장하는 구조에 있다. 개입 시점을 앞당기는 게 근본 해법이다.
• 재현 정보 없이 티켓을 던진다. 반송의 대부분은 재현 실패에서 온다. 환경·계정·시각·로그를 붙이는 것만으로 신뢰가 달라진다.
• 공고에 없던 업무를 말로만 떠안는다. 늘어난 범위는 문서로 합의해야 평가에 반영된다. 거절도 무조건 수용도 아닌 범위 협상이 답이다.
• 성장을 관리자가 되는 것으로만 생각한다. 기술 트랙(자동화, 성능, AI 검증 전문가)도 관리 트랙 못지않게, 때로는 더 높은 시장 가치를 가진 경로다.
• 트랙을 지금 확정해야 한다고 압박받는다. 주니어 시점의 선택은 되돌릴 수 있다. 다만 기술 → 관리 순서가 되돌아오기 더 쉽다는 점은 알아둘 만하다.

참고 자료

• ISTQB Glossary — Quality Assurance / Quality Control — 두 용어의 공식 정의
• ASQ — What is Quality Assurance vs Quality Control? — 제조업 기원의 QA/QC 개념을 소프트웨어에 적용한 설명
• ISTQB Certified Tester Foundation Level 실러버스 — 1장에 테스터의 역할과 팀 내 위치가 정리되어 있다
• Google — How Google Tests Software 개요 — SET/TE 같은 역할 분화를 실제로 시도한 조직의 기록. 직함 분화가 왜 생겼는지 이해에 도움이 된다
• Ministry of Testing — The Testing Community — 역할·커리어 관련 실무자 글과 토론이 많은 커뮤니티