사내 QA 교육과정 — 대상별 트랙과 신규 입사자 커리큘럼

개념

이 레슨의 경계 — 설계자와 운영자의 자리

모듈 42 레슨 7 은 학습자 입장의 첫 90일 실습 이다. 입사했거나 전직을 준비하는 사람이 제품 하나를 골라 산출물 여섯 개를 스스로 이어 만드는 계획이었다. 이 레슨은 그 반대쪽에 선다 — 그 90일을 조직이 설계하고 운영하는 쪽 이다. 무엇을 몇 주차에 배치하고, 누가 붙고, 무엇으로 합격을 판정하고, 어떤 자산을 교재로 쓰는가. 학습자용 체크리스트가 필요하면 42-7 을 그대로 쓰면 되고, 여기서는 중복해서 쓰지 않는다.

전원 같은 과정이 실패하는 이유

사내 QA 교육을 처음 만들면 거의 예외 없이 "QA 입문 과정" 하나가 나온다. 신입도 듣고, 개발에서 넘어온 사람도 듣고, 다른 도메인에서 이직한 7년차도 듣는다. 결과는 정해져 있다.

• 신입은 "결함 유입 곡선" 같은 말이 나오는 지점에서 따라가지 못한다
• 경력 전입자는 앞의 2시간이 이미 아는 내용이라 뒤쪽 집중력이 없다
• 도메인 전환자는 테스트는 아는데 그 도메인의 규칙 을 모르는 것이 문제인데, 과정은 테스트 기법을 또 가르친다

같은 과정을 듣는 사람들의 출발점이 다르면 같은 목표를 줄 수 없다. 레슨 1 에서 목표의 구성 요소로 "조건"을 꼽은 이유가 여기서 드러난다. "템플릿 없이 작성할 수 있다"는 조건은 신입에게는 불가능하고 7년차에게는 당연하다. 조건이 달라야 하므로 과정이 갈려야 한다.

트랙을 가르는 기준 — 무엇이 없어서 못 하는가

대상을 나눌 때 연차나 직급으로 나누면 거의 틀린다. "지금 무엇이 없어서 일을 못 하는가" 로 나눠야 트랙이 갈린다. QA 조직에서 반복적으로 나타나는 네 묶음이다.

이 표에서 가장 자주 빠뜨리는 칸은 "이미 있는 것" 이다. 경력 전입자에게 "경계값 분석"을 가르치는 것은 시간 낭비일 뿐 아니라 모욕이다. 반대로 CS 에서 온 사람에게 제품 설명을 처음부터 하는 것도 같은 낭비다. 트랙 설계의 절반은 빼는 결정 이다.

네 트랙을 전부 만들 수는 없다. 우선순위는 인원 수 × 실패 비용 으로 정한다. 경력 입사만 있는 조직이 신입 과정을 공들여 만드는 일이 의외로 흔하다 — 교재가 만들기 쉬워서다.

공통 코어와 트랙별 분기

트랙을 넷으로 쪼개면 교재가 네 배가 된다. 유지할 수 없다. 그래서 공통 코어 + 분기 구조로 짠다.

[공통 코어] — 누구에게나 필요하고, 조직 바깥에서는 배울 수 없는 것
  · 제품 구조와 주요 사용자 흐름
  · 릴리스 절차와 품질 게이트(언제 무엇이 막히는가)
  · 결함 티켓 규칙·필수 필드·심각도 기준
  · 테스트 관리 도구 사용법과 환경 접근 권한
  · "누구에게 무엇을 물어보는가" 연락 지도
 
[분기]
  신입      → 테스트 기법 기초 + 산출물 형식 반복 + 짝 실행
  경력 전입 → 코어만 압축 + 자동화 코드베이스 투어 + 첫 과제 바로
  도메인 전환 → 결함 판정 훈련 + 리포트 작성 + 기법은 사례로 역산
  리드 후보 → 리뷰 실습 + 보고 한 장 + 기존 리드 섀도잉

공통 코어의 선정 기준은 하나다. 조직 바깥에서는 배울 수 없는 것. 경계값 분석은 책과 외부 강의로 배울 수 있지만 "우리 릴리스는 수요일 14시에 잠기고 그 전에 회귀가 초록이어야 한다"는 어디에도 없다. 일반 이론은 외부 자료·사내 커리큘럼 링크로 돌리고, 코어에는 우리 조직에만 있는 사실 을 넣는다.

신규 입사자 커리큘럼 — 주차 구성

신입 트랙을 12주로 짜는 예다. 핵심 설계 원칙은 첫 기여 시점을 앞당기는 것 이다.

주차표를 만들 때 반드시 지킬 두 가지.

1. 1주차에 "읽기"만 배치하지 않는다. 위키 50쪽을 읽히는 1주차는 가장 흔하고 가장 나쁜 설계다. 읽은 것은 다음 주에 남지 않고, 본인은 아무것도 보탬이 안 된다고 느낀다. 1주차에도 아주 작은 산출물 을 준다 — 환경 문서의 틀린 부분 1건 고치기가 가장 좋다. 반드시 틀린 데가 있고, 고치면 바로 조직에 보탬이 되고, 문서를 정독하게 된다
2. "첫 기여"를 명시적으로 한 칸에 박아 둔다. 위 표의 3~4주차가 그 칸이다. 없으면 온보딩은 "준비가 끝나면 시작"이 되고, 준비는 영원히 안 끝난다

첫 기여 시점을 앞당기는 설계

첫 기여가 늦어지는 원인은 거의 항상 순서 에 있다. "다 배우고 나서 시작한다"는 순서가 기본값이기 때문이다. 이를 뒤집는 네 가지 장치가 있다.

• 역순 설계 — 12주차에 혼자 해야 하는 일을 먼저 적고, 그것을 쪼개 앞으로 당긴다. 주차표를 1주차부터 채우면 분량이 앞에 쏠린다
• 일부러 쉬운 실제 일 — 연습용 가짜 과제보다 실제이지만 위험이 낮은 일 이 낫다. 내부 관리 도구, 사내용 화면, 종료 예정 기능의 회귀가 좋은 후보다
• 짝으로 먼저, 혼자는 나중 — 혼자 할 수 있을 때까지 기다리지 말고, 짝으로 당장 실제 일을 한다. 2주차에 선임 옆에서 함께 실행한 경험이 4주치 강의보다 멀리 간다
• 권한을 미리 연다 — 첫 기여가 늦어지는 가장 어이없는 이유는 계정·권한이다. 입사 전에 신청해 1주차 1일에 다 열려 있어야 한다. 온보딩 체크리스트의 0번 항목이다

반대로 첫 기여를 너무 앞당기면 생기는 문제도 분명하다. 아직 결함 판정 기준을 모르는 사람이 티켓을 올리면 반려가 쌓이고, 반려는 자신감을 깎는다. 그래서 3~4주차의 첫 결함 리포트는 멘토 리뷰를 거쳐 등록 한다. 공개 공간에서 반려당하는 경험을 초기에 주지 않는 것이 이 설계의 요점이다.

사내 과정의 현실적 제약 세 가지

사내 교육이 외부 강의와 다른 점은 자원이 없다는 것이다. 설계할 때 이 셋을 처음부터 전제로 깔아야 과정이 살아남는다.

1. 시간 — 강사도 수강자도 본업이 있다. 4시간 집합 교육을 분기마다 돌리는 계획은 두 번째 분기에 깨진다. 현실적인 형태는 90분 이하 단위 와 비동기 선행 학습 + 짧은 실습 세션 이다. 그리고 과정 시간을 일정에 공식으로 넣어야 한다. "짬 날 때 들으세요"는 안 듣겠다는 말과 같다(레슨 1 의 다섯 질문 중 "하면 이득인가"가 여기 걸린다).

2. 강사 — 사내 강사는 시니어다. 시니어의 한 시간은 비싸고, 강의 준비에 실제 강의 시간의 3~5배가 든다. 그래서 강사가 준비 없이 진행할 수 있는 형태 로 설계한다. 강사 노트에 "이 슬라이드에서 이 질문을 던지고 5분 기다린다"까지 적어 두면 다음 기에 다른 사람이 진행할 수 있다. 강사 의존 과정은 그 사람이 바쁜 분기에 사라진다.

3. 교재 수명 — 제품 화면이 바뀌면 스크린샷이 전부 거짓이 된다. 사내 교재의 수명은 대개 2~3개 릴리스다. 대응은 두 가지다.

• 썩는 부분과 안 썩는 부분을 분리한다. 원칙·판단 기준·절차는 오래 가고, 스크린샷·메뉴 경로·도구 버전은 금방 썩는다. 썩는 것은 부록으로 빼고 본문에서는 링크한다
• 교재를 제품 쪽에 붙인다. 스크린샷 대신 "실제 제품을 열어서 ○○을 해 보라"로 쓰면 화면이 바뀌어도 과제는 유효하다

개정 책임자와 주기를 과정 문서 첫 장에 적어 둔다. 적지 않으면 3년 뒤 "이 자료 아직 맞나요?" 질문에 아무도 답하지 못한다.

이미 있는 자산을 교재로 바꾸기

사내 교재를 새로 쓰려 하면 분량에 압도돼 시작하지 못한다. 그런데 교재의 재료는 이미 조직 안에 다 있다. 없는 것은 문제로 바꾸는 작업 뿐이다.

이 표의 공통 원리는 하나다. 자료를 주는 것이 아니라 자료로 답해야 하는 질문을 준다. 준비 비용이 놀랍도록 낮고(질문 10개를 만드는 데 한 시간), 효과는 슬라이드보다 크다.

과거 결함 티켓을 쓸 때는 익명화 를 확인한다. 반려된 리포트를 교재로 쓰면 작성자가 조직 안에서 바로 드러난다. 작성자 필드를 지우고 당사자 동의를 받거나, 아예 직접 만든 나쁜 예를 쓰는 편이 안전하다.

과정 한 벌의 산출물 목록

과정을 "만들었다"고 말할 수 있는 최소 구성이다. 레슨 1 의 ADDIE 개발·실행 단계 산출물을 사내 과정 형태로 구체화한 것이다.

1. 과정 개요 1쪽   — 대상·선수 조건·학습 목표 목록·분량·전달 방식·개정 책임자와 주기
2. 주차(차시) 구성표 — 목표 ↔ 차시 ↔ 평가 과제 대응. 빈칸이 없어야 한다
3. 강사 노트       — 진행 순서, 던질 질문, 예상 오답, 시간 배분
4. 실습 자료       — 과제 지시문, 실습 데이터, 샘플 결함, 깨진 브랜치
5. 평가 과제·루브릭 — 레슨 3 에서 다룬다
6. 수강자 안내     — 사전 준비물, 권한 신청 목록, 제출 기한

6번을 빠뜨리면 1주차 1일이 권한 신청으로 날아간다. 가장 싸고 가장 효과가 큰 문서다.

실무에서 왜 필요한가

QA 채용이 한 해에 몇 명이라도 있는 조직이면 온보딩은 즉흥으로 진행되거나 과정으로 존재하거나 둘 중 하나다. 즉흥인 조직에서는 입사 시점 운이 성장 속도를 결정한다. 한가한 분기에 들어온 사람은 선임이 붙어 주고, 릴리스 직전에 들어온 사람은 두 달을 혼자 위키만 읽는다. 같은 직무로 입사한 두 사람의 6개월 뒤가 본인 역량이 아니라 타이밍 때문에 갈린다.

과정으로 존재하면 세 가지가 달라진다. 첫째, 첫 기여까지의 기간이 짧아진다 — 조직이 체감하는 가장 큰 효과다. 둘째, 온보딩 품질이 담당자의 성실성에 덜 의존한다. 셋째, 온보딩이 조직 진단 도구가 된다. 신입이 1주차에 막히는 지점은 거의 항상 조직의 실제 문제다 — 환경 문서가 썩었거나, 권한 체계가 복잡하거나, 제품 구조를 설명할 수 있는 사람이 한 명뿐이거나. 신입은 조직의 가장 정직한 감사인이다.

트랙을 가르는 일은 교육을 넘어 투자 배분 결정 이다. 경력 전입자에게 신입 과정을 들려주는 조직은 비싼 인력의 2주를 버리고, 도메인 전환자에게 기법만 가르치면 6개월 뒤에도 "이게 결함인지"를 매번 물어본다.

채용시장에서의 위치

공고에서 이 영역은 "신규 입사자 온보딩 프로그램 설계·운영", "QA 교육과정 개설", "주니어 육성" 같은 문구로 나타난다. 조직 규모가 커질 때(QA 인원 10명 전후를 넘길 때) 갑자기 필요해지는 역량이라, 성장 중인 플랫폼·게임·금융 IT 조직의 QA 리드 공고에서 자주 보인다.

면접에서는 숫자가 결정적이다. "온보딩을 12주 커리큘럼으로 재설계해 첫 결함 리포트 등록 시점을 평균 7주에서 3주로 당겼고, 1주차 권한 미비로 날아가던 하루를 입사 전 신청 절차로 없앴습니다" 같은 답은 설계 능력과 운영 능력을 동시에 보여 준다. "온보딩 문서를 정리했습니다"는 같은 일을 했어도 절반만 전달된다.

실습 과제

과제 1 — 대상 트랙 분기표 (25분)

자기 조직(또는 가상의 QA 팀 8명 규모)을 기준으로 트랙 분기표를 만든다. 네 트랙 중 실제로 만들 두 개를 고르고 나머지는 "안 만든다"고 명시 하며, 근거는 인원 수 × 실패 비용으로 적는다. 고른 두 트랙에 ① 결핍된 것 ② 이미 있는 것 ③ 공통 코어에서 빼는 항목 을 각각 3개 이상 적는다. 빼는 항목을 못 적으면 트랙이 갈리지 않은 것이다.

과제 2 — 12주 커리큘럼과 첫 기여 칸 (30분)

신입 또는 도메인 전환 트랙 하나를 골라 12주 주차표를 작성한다. 각 주차에 ① 할 수 있게 되는 것(레슨 1 의 행동·조건·기준 형식) ② 그 주의 기여 산출물 ③ 붙는 사람을 적는다.

제약: 첫 기여 산출물이 4주차 안에 들어가야 하고, 1주차에도 산출물이 하나 있어야 한다. 1주차에 "위키 읽기"만 있으면 실패다. 마지막으로 역순 점검을 한다 — 12주차 목표를 12주 동안 쪼갠 결과로 읽히는가, 아니면 앞에 분량이 쏠렸는가.

과제 3 — 있는 자산을 문제로 바꾸기 (20분)

조직에 이미 있는 자산 하나를 고른다(위키 문서, 과거 결함 티켓 20건, 지난 장애 보고서, 자동화 코드베이스 중 하나). 그것으로 실습 과제 하나 를 설계한다.

• 지시문 10줄 이내
• 학습자가 제출할 산출물
• 합격 판정 기준 3개
• 준비에 든(들) 시간 추정

준비 시간이 2시간을 넘으면 설계가 과하다. 다시 줄인다. 결함 티켓을 쓴다면 익명화 처리를 어떻게 할지도 한 줄 적는다.

자가 체크리스트

• 전원 같은 과정이 실패하는 이유를 출발점(조건)의 차이로 설명할 수 있다
• 트랙을 연차가 아니라 "무엇이 없어서 못 하는가"로 가를 수 있다
• 트랙 설계에서 "이미 있는 것"과 "빼는 항목"을 적을 수 있다
• 공통 코어의 선정 기준이 "조직 바깥에서 배울 수 없는 것"임을 설명할 수 있다
• 1주차에도 작은 산출물을 배치하고, 첫 기여 칸을 주차표에 명시할 수 있다
• 첫 기여를 앞당기는 네 가지 장치와 너무 앞당길 때의 부작용을 함께 말할 수 있다
• 시간·강사·교재 수명 제약을 전제로 과정 형태를 선택할 수 있다
• 위키·결함 티켓·실제 제품을 "답해야 하는 질문"으로 바꿀 수 있다
• 과정 한 벌의 산출물 여섯 가지를 열거하고, 개정 책임자·주기를 문서에 남긴다

흔한 실수

• 1주차를 읽기로 채운다. 위키 50쪽은 다음 주에 남지 않는다. 틀린 문서 1건 고치기가 읽기보다 많이 남는다.
• 연차로 트랙을 나눈다. 7년차 도메인 전환자와 7년차 QA 경력자의 결핍은 정반대다.
• "준비가 끝나면 투입"으로 운영한다. 첫 기여 주차를 날짜로 박고 거기에 맞춰 준비를 쪼갠다.
• 권한·계정을 입사 후에 신청한다. 체크리스트 0번을 비워 두면 1주차가 날아간다.
• 일반 이론을 사내 교재로 다시 쓴다. 경계값 분석을 새로 쓸 시간에 "우리 릴리스 게이트"를 쓴다.
• 교재에 스크린샷을 가득 넣는다. 두 번째 릴리스에 전부 거짓이 된다.
• 강사 노트 없이 운영한다. 설계자가 바쁜 분기에 과정이 사라진다.
• 반려된 결함 티켓을 익명화 없이 쓴다. 작성자가 드러나고 교재는 신뢰를 잃는다.

참고 자료

• 모듈 42 레슨 7(첫 90일 온보딩 실습) — 학습자 입장 의 90일 계획과 산출물 여섯 개. 이 레슨은 그 90일을 조직이 설계·운영하는 쪽이므로 두 레슨을 짝으로 쓴다
• 모듈 60 레슨 1(학습 목표와 ADDIE) — 주차별 "할 수 있게 되는 것"을 행동·조건·기준으로 쓰는 방법, 그리고 과정 산출물 목록의 출처
• 모듈 60 레슨 3(실습과 평가 설계) — 주차표의 평가 과제와 루브릭을 만드는 방법
• 모듈 43(테스트 리드 실무) — 리드 후보 트랙의 내용은 이 모듈을 과정으로 재구성한 것이다
• 모듈 44 레슨 2(QMO) — 역할별 학습 경로를 조직 운영 모델에 올리는 자리
• Michael D. Watkins, The First 90 Days — 전환기 90일 설계의 일반 틀