시리즈 B: 개인기로 버티던 품질을 시스템으로 바꾸기

개념

지점을 세 개 더 여는 가게

단골 손님 얼굴을 다 아는 동네 가게는 재고 관리가 필요 없다. 사장 머릿속에 "무엇이 얼마나 남았는지" 가 들어 있고, 그게 실제로 잘 돌아간다. 그런데 같은 사장이 지점을 세 개 더 열면, 머릿속 재고는 그날부터 틀리기 시작한다. 사장이 게으르거나 능력이 떨어진 것이 아니다. 한 사람의 머릿속에 들어갈 수 있는 양에 한계가 있을 뿐이다.

시리즈 B의 품질 문제가 정확히 이 구조다. 지금까지 품질을 지탱한 것은 대개 "그 기능을 아는 사람" 의 개인기였다. 조직이 두 배가 되고 릴리즈가 네 배가 되면, 그 개인기는 사라지지 않지만 더는 전체를 덮지 못한다. 이 레슨의 핵심 논지는 하나다 — 개인기로 버티던 품질이 시스템 없이는 유지되지 않는 지점을 지난다.

중요한 점은 이 전환이 공지되지 않는다는 것이다. 어느 날 "이제 시스템으로 갑니다" 라고 선언되지 않고, 릴리즈가 밀리고 장애가 반복되는 증상으로 먼저 나타난다. 그래서 이 레슨은 전환 시점을 알려 주는 숫자를 먼저 다룬다.

시리즈 B에서 실제로 무엇이 변하는가

시리즈 B는 검증된 모델에 자금을 부어 점유율을 넓히는 단계다. 자금의 용처가 대부분 채용과 마케팅, 그리고 시장 확장이기 때문에 조직에 세 가지 변화가 동시에 온다.

세 가지가 겹치면 "아는 사람이 확인한다" 로 버티던 품질이 한 번에 무너진다. 이 붕괴는 보통 예고 없이 오지 않는다. 아래 신호가 먼저 나타난다.

붕괴 직전의 신호 (하나라도 2개월 이상 지속되면 시스템 전환 시점)
  · 릴리즈 전 회귀에 걸리는 시간이 매 릴리즈마다 늘어난다
  · "이 부분은 OO님만 안다" 는 영역이 3개 이상이다
  · 핫픽스 비율이 전체 배포의 20%를 넘는다
  · 같은 유형의 결함이 분기마다 재발한다
  · 장애 원인 분석이 "누가 실수했다" 로 끝난다

개인기와 시스템의 차이는 "사람이 바뀌어도 같은 결과가 나오는가"

"시스템을 갖추자" 는 말은 너무 추상적이라 아무 행동으로도 이어지지 않는다. 구체적인 판별 질문으로 바꾸면 바로 쓸 수 있다.

가장 날카로운 판별 질문은 네 번째다 — "그 사람이 2주 휴가를 가면 무엇이 멈추는가." 답이 길어질수록 그 조직은 개인기 쪽에 가깝다. 그리고 시리즈 B 구간에서는 그 사람이 휴가가 아니라 이직으로 사라질 확률도 같이 올라간다.

수동 회귀의 한계선 계산

전환 시점을 감이 아니라 숫자로 보여주는 계산이다. 모듈 11 레슨 3의 ROI 계산을 조직 성장률과 함께 돌리는 것이 이 단계의 차이점이다.

[현재]  수동 회귀 1회 = 32시간 (QA 2명 × 16시간), 릴리즈 월 2회
        → 월 64시간
 
[6개월 뒤 계획]  릴리즈 주 2회(월 8회), 기능 범위 1.4배
        → 필요 시간 = 32h × 1.4 × 8회 = 월 358시간
        → QA를 몇 명 더 뽑아도 따라잡지 못하는 구간에 진입
 
[의미] 자동화는 "비용 절감" 이 아니라 "계획된 릴리즈 빈도를 가능하게 하는 전제"

마지막 줄이 경영진 설득의 핵심 문장이다. 시리즈 B 기업의 경영진은 비용 절감보다 성장 계획의 실행 가능성에 반응한다. 모듈 26 레슨 3에서 CFO에게 쓰는 언어와 결이 다르다.

사람을 더 뽑아서 해결되는 것과 안 되는 것

시리즈 B에서 가장 자주 나오는 처방은 "QA를 더 뽑자" 다. 그 처방이 맞는 문제와 틀린 문제를 가르지 못하면, 인원이 늘어도 증상이 그대로 남는다.

아래 네 줄이 이 레슨의 실질적 내용이다. 네 줄 모두 "사람" 이 아니라 "구조" 의 문제이고, 그래서 시리즈 B의 QA 리드가 해야 하는 일은 채용 요청서를 쓰는 것보다 어느 문제가 어느 칸에 있는지 가르는 일이 먼저다.

전환 시점을 알려주는 네 숫자

"무너지고 있다" 를 느낌으로 말하면 반박된다. 아래 네 숫자는 대부분의 조직이 이미 가진 데이터로 그 주에 계산할 수 있고, 둘 이상이 동시에 경고 구간에 들어가면 전환 시점이다.

네 번째가 이 단계에서 특히 중요하다. 인원이 두 배가 되는 조직에서 신규 입사자 적응 시간이 2주를 넘으면, 채용이 생산성을 즉시 깎는다 — 새로 온 사람이 기존 사람의 시간을 계속 쓰기 때문이다. 이 숫자는 경영진이 가장 빨리 이해하는 품질 지표이기도 하다. 모듈 6 레슨 5의 지표 설계와 같은 원칙으로, 이미 있는 데이터에서 뽑을 수 있는 것부터 고른다.

재오픈율과 반복 장애 비율은 같은 원인을 두 번 겪고 있다는 뜻이므로, 둘이 같이 오르면 문제는 테스트 양이 아니라 원인 분석과 재발 방지의 부재다.

무엇부터 자동화하는가 — 이 단계의 우선순위

4번을 우선순위 근거로 쓰려면 결함 데이터가 남아 있어야 한다. 모듈 6의 결함 관리가 여기서 자산으로 바뀐다. 기록이 없는 팀은 우선순위를 정치로 정하게 된다.

자동화보다 먼저 막히는 곳 — 환경과 테스트 데이터

시리즈 B에서 자동화 과제가 실패하는 가장 흔한 이유는 도구 선택이 아니다. 자동화가 붙을 바닥이 아직 없는 상태에서 시작하는 것이다.

두 번째 줄이 가장 자주 과소평가된다. 로그인 상태, 결제 수단, 권한 조합을 매번 손으로 만들어야 하는 조직에서는 스모크 30건을 자동화해도 실행에 사람이 붙는다. 그 상태의 자동화는 유지비만 남기고 회수가 없다.

릴리즈 게이트 — 사람의 판단을 규칙으로 옮기기

[배포 차단 조건] — 자동 판정, 예외는 기록을 남긴다
  · 핵심 시나리오 자동화 스위트 실패 1건 이상
  · 신규 심각도 S1·S2 결함 미해결
  · 오류율·응답시간 임계 초과 (스테이징 기준)
  · 보안 스캔 신규 Critical 취약점 (모듈 23)
 
[배포 후 관찰] — 롤백 판단 기준을 미리 정한다
  · 5분 내 오류율 x% 초과 → 자동 롤백
  · 핵심 지표(결제 성공률) 하락 → 수동 판단 + 온콜 호출

게이트의 목적은 막는 것이 아니라 같은 판단을 매번 반복하지 않는 것이다. 예외 승인 경로를 함께 설계해야 게이트가 오래 간다 — 예외가 불가능한 게이트는 결국 꺼진다.

게이트가 생기면 자연스럽게 따라오는 것이 릴리즈 열차다. 배포를 "준비되면 한다" 에서 "정해진 시각에 출발한다" 로 바꾸는 방식이다.

두 번째 줄이 전환점이다. "이 기능 때문에 릴리즈를 미루자" 가 사라지면 일정 압박이 QA에게 전가되는 경로도 같이 사라진다. 모듈 4 레슨 5의 릴리즈 판정과 모듈 14 레슨 4의 품질 게이트 설계를 조직 리듬에 올린 형태다.

장애 대응 체계 — 개인기가 가장 늦게까지 남는 곳

회귀와 릴리즈를 시스템으로 옮긴 조직에서도 장애 대응은 오랫동안 개인기로 남는다. 새벽에 누가 전화를 받고, 그 사람이 아는 범위에서 조치하는 형태다.

[장애 대응의 뼈대] — 각 칸에 "누가" 와 "얼마 안에" 가 적혀 있어야 한다
  감지  → 1차 응답 → 영향 범위 판정 → 완화 → 원인 분석 → 재발 방지
  (알람)  (온콜)      (QA·PO)          (롤백·  (개발·QA)   (테스트로 고정)
                                        피처플래그)

이 뼈대에서 QA의 자리는 세 번째와 여섯 번째다. 영향 범위 판정은 "무엇이 망가졌고 무엇은 괜찮은가" 를 가리는 일이고, 재발 방지는 그 원인을 테스트로 고정해 다시 못 돌아오게 만드는 일이다. 포스트모템이 "누가 실수했다" 로 끝나면 여섯 번째 칸이 비고, 반복 장애 비율이 올라간다(모듈 6 레슨 3의 비난 없는 결함 커뮤니케이션이 여기서 그대로 쓰인다).

온보딩을 품질 장치로 설계한다

6개월에 개발자가 두 배가 되는 조직에서 온보딩은 인사 업무가 아니라 품질 장치다. 새로 온 사람이 혼자 안전하게 배포할 수 있게 만드는 산출물은 다섯 개로 충분하고, 각각 측정 가능하다.

세 번째 줄의 측정값이 앞서 본 "신규 입사자 적응 시간" 과 같은 숫자다. 온보딩 산출물을 만드는 일이 지표를 직접 움직이기 때문에, 이 단계에서 가장 투자 회수가 빠른 작업에 속한다.

팀이 커질 때의 QA 조직 형태

시리즈 B 구간의 흔한 실패는 인원만 늘리고 형태를 바꾸지 않는 것이다. 중앙집중 구조에서 QA를 6명까지 늘리면 병목이 6배로 커지는 것이 아니라, 병목이 그대로 유지되면서 대기열만 길어진다.

전환 순서에도 정석이 있다. 임베디드로 먼저 쪼개고, 쪼개진 뒤에 생기는 중복과 편차를 플랫폼 역할로 모으는 순서다.

중앙집중 (QA 3명, 스쿼드 2개)
   │  스쿼드가 4개를 넘고 대기열이 생기기 시작
   ▼
임베디드 (스쿼드마다 QA 1명)
   │  스쿼드마다 도구·환경·기준이 갈라지기 시작
   ▼
혼합 (임베디드 + 플랫폼 1~2명)   ← 시리즈 B의 현실적 도착점
   │  자동화가 정착하고 개발이 직접 실행하기 시작
   ▼
QE 중심

순서를 뒤집는 것이 대표적인 실수다. 플랫폼 팀을 먼저 만들면, 쓰는 사람이 아직 없는 도구를 만들게 된다. 모듈 55 레슨 1의 자동화 아키텍처 논의도 같은 결론으로 간다 — 사용자가 생긴 뒤에 공통화한다.

품질 편차 — 스쿼드마다 품질이 달라지는 문제

임베디드로 쪼개면 대기열은 풀리지만 새 문제가 온다. 스쿼드 6개가 각자 기준을 만들면 기준이 6개가 된다. 이것은 사고가 아니라 구조의 자연스러운 결과다.

대응의 핵심은 기준을 통일하는 것이 아니라 최소 공통 기준을 세 개로 줄이는 것이다. 예를 들어 "돈의 경로 스모크 통과", "S1·S2 미해결 없음", "결함 등록 템플릿 준수" 세 개만 전사 공통으로 두고, 나머지는 스쿼드 재량으로 남긴다. 모듈 7 레슨 6의 성숙도 모델에서 말하는 "한 번에 하나" 의 속도와 같은 원칙이고, 전부 통일하려는 시도가 실패하는 이유도 같다.

성장 중인 조직에서 쓰는 공통 지표

DORA 4개 지표(배포 빈도, 리드타임, 변경 실패율, 복구 시간)는 QA 단독 지표가 아니라 엔지니어링 전체의 공통 언어라서 이 단계에서 특히 쓸모가 있다. 모듈 14 레슨 7의 SLO·에러 버짓과 함께 "품질 vs 속도" 논쟁을 하나의 숫자 위에서 하게 만든다.

네 지표를 같이 보는 이유는 한 지표만 올리면 다른 지표가 망가지는 것을 바로 보여주기 때문이다. 게이트를 과하게 걸면 배포 빈도와 리드타임이 나빠지고, 게이트를 꺼 버리면 변경 실패율이 올라간다. "품질이냐 속도냐" 를 감정으로 다투지 않게 만드는 장치가 이 네 칸이다.

사례 — 개발 12명이 38명이 된 6개월

B2B SaaS 기업이 시리즈 B를 조달하고 6개월 만에 개발 인원을 12명에서 38명으로 늘렸다. 스쿼드는 2개에서 6개가 됐고, 릴리즈 목표는 월 2회에서 주 1회로 올라갔다. QA는 3명 중앙집중 구조를 그대로 유지했다. 채용 계획에는 QA 3명 추가가 잡혀 있었지만 시장에서 사람을 못 구하고 있었다.

반년 뒤 숫자는 이렇게 변했다.

원인 분석 결과 QA 인원 부족은 네 가지 원인 중 하나일 뿐이었다.

바꾼 것은 네 가지이고, 순서가 결과를 갈랐다.

4개월 뒤 결과다.

마지막 줄이 이 사례의 요점이다. 처음 계획했던 QA 6명은 끝까지 채우지 않았다. 남는 교훈이 셋이다.

• 환경과 데이터가 막혀 있으면 자동화는 붙지 않는다. 1번을 2번보다 먼저 한 것이 성패를 갈랐다. 순서를 뒤집은 팀은 자동화에 돈을 쓰고 플레이키만 얻는다
• 대기열 문제는 인원으로 풀리지 않는다. 중앙집중 게이트를 유지한 채 QA를 6명으로 늘렸다면 대기열이 길어졌을 뿐이다. 해결한 것은 형태 전환과 플랫폼 역할 1명이었다
• 숫자를 먼저 재 두었기 때문에 전환을 설득할 수 있었다. 재오픈율과 적응 시간을 기록해 둔 덕에 "QA가 힘들다" 가 아니라 "구조가 이 숫자를 만든다" 로 말할 수 있었다

실무에서 왜 필요한가

이 구간의 결정은 되돌리기 비싸다

시리즈 B에서 고른 자동화 프레임워크, 테스트 환경 구조, 테스트 데이터 전략은 이후 몇 년간 조직 전체가 얹혀 사는 기반이 된다. 잘못 고르면 시리즈 C 시점에 마이그레이션 비용이 신규 구축보다 커진다(모듈 22 레슨 12의 교체 비용 계산).

속도와 품질이 처음으로 같은 표에서 논의된다

시드·시리즈 A에서는 "빠르게" 가 거의 항상 이긴다. 시리즈 B에서는 다르다. 배포가 잦아지면 사고의 빈도도 같이 올라가고, 엔터프라이즈 고객이 들어오면 사고의 비용이 계약 단위로 커진다. 그 시점에 경영진은 처음으로 "얼마나 빠르게" 와 "얼마나 안전하게" 를 함께 보려 한다.

이때 QA가 DORA 네 지표와 SLO를 들고 들어가면 논의가 취향 다툼에서 숫자 위의 트레이드오프로 옮겨간다. 모듈 26 레슨 7의 경영진 보고 형식이 이 구간에서 실제로 쓰이기 시작하는 이유다.

사람이 빠르게 들어온다 — 온보딩이 품질 장치가 된다

6개월에 개발자가 두 배가 되는 조직에서는 새로 온 사람이 실수하지 않게 만드는 구조가 테스트만큼 중요하다. 실행 가능한 테스트 스위트, 로컬 환경 구축 스크립트, 릴리즈 절차 문서는 모두 품질 장치다.

반대 방향도 성립한다. 온보딩이 느린 조직은 기존 인원의 시간을 신규 인원이 계속 가져간다. 그래서 채용을 늘리는 그 분기에 오히려 산출이 떨어지는 현상이 나타나고, 경영진은 그것을 "품질 문제" 로 읽는다.

릴리즈 프로세스가 없으면 사람이 먼저 떠난다

이 구간에서 가장 비싼 손실은 결함이 아니라 퇴사다. 매주 배포하는 조직에서 절차와 온콜 체계가 없으면, 밤과 주말을 특정 몇 명이 계속 떠안는다. 그 몇 명이 대개 "OO님만 아는 영역" 의 그 사람이고, 그 사람이 떠나면 조직은 지식과 대응 능력을 동시에 잃는다.

릴리즈 열차와 온콜 로테이션은 복지 정책이 아니라 지식 분산 장치다. 절차대로 돌아가는 배포는 누구나 할 수 있는 배포라는 뜻이고, 그것이 곧 이탈 위험을 줄인다.

기술 실사가 다음 라운드에서 기다린다

시리즈 C와 엑싯 구간에서 실사가 보는 것은 결과물뿐 아니라 프로세스의 흔적이다. 시리즈 B 시기에 남긴 자동화 이력·결함 추적·릴리즈 기록이 그때 증거가 된다. (레슨 5)

채용시장에서의 위치

시리즈 B 기업의 QA 채용은 두 갈래로 갈린다.

이 구간의 면접에서는 "도구를 써봤는가" 보다 "무너지는 시점을 예측하고 무엇을 먼저 바꿨는가" 를 묻는다. 앞의 한계선 계산을 자기 경험의 숫자로 말할 수 있으면 그 자체가 답변이 된다.

질문별로 답이 갈리는 지점

가장 변별력이 큰 질문

두 번째와 세 번째가 가장 크게 갈린다. 둘 다 면접관이 이미 답을 정해 놓고 묻는 질문이기 때문이다. 시리즈 B 기업의 채용 담당자는 대개 "QA를 더 뽑아도 나아지지 않았다" 는 경험을 막 통과한 사람이다. 그 앞에서 "3명 필요합니다" 라고 답하면, 지원자가 방금 실패한 처방을 다시 제안한 사람이 된다.

세 번째 질문의 변별력은 조금 다른 데서 온다. "핵심 기능부터" 는 틀린 답이 아니라 누구나 하는 답이다. 환경과 데이터를 먼저 말하는 지원자는 자동화를 해 본 사람이라는 신호를 준다 — 실제로 해 보면 거기서 먼저 막히기 때문이다. 이 한 문장이 "도구 이름을 아는 사람" 과 "스위트를 운영해 본 사람" 을 가른다.

네 번째는 조직 안에서 제도가 살아남게 만들어 본 사람인지를 본다. 게이트를 설계하는 것은 쉽고, 6개월 뒤에도 켜져 있게 만드는 것이 어렵다. 예외 경로를 먼저 말하는 지원자는 그 어려움을 통과해 본 사람으로 읽힌다.

공고에서 읽어야 하는 두 줄

이 단계 공고에서 실제 업무를 가장 잘 알려 주는 것은 직함이 아니라 "현재 상태" 를 적은 한 줄이다.

면접에서 역질문의 재료로도 쓰인다. "지금 릴리즈 지연과 핫픽스 비율이 어느 정도인가요" 는 지원자가 이 단계의 언어를 안다는 신호가 된다.

실습 과제

과제 1 — 한계선 계산하기

현재 조직(또는 가상의 조직)의 숫자로 앞의 계산을 채운다.

수동 회귀 1회 소요 시간      = ___ 시간
현재 릴리즈 빈도             = 월 ___ 회
6~12개월 뒤 목표 릴리즈 빈도 = 월 ___ 회
기능 범위 증가 계수          = ___ 배
→ 미래 필요 시간 = ___ 시간/월
→ 현재 가용 시간 = ___ 시간/월
→ 격차를 메우는 방법 3가지와 각각의 비용

"사람을 더 뽑는다" 도 반드시 선택지에 넣고 비용을 계산한다. 자동화가 항상 정답은 아니며, 비교를 거친 자동화 제안만 설득력을 갖는다.

회귀 1회 20시간, 현재 월 2회 → 월 40시간
목표 월 8회, 범위 1.3배 → 20 × 1.3 × 8 = 월 208시간
QA 2명 가용(실제 테스트 시간 60% 가정) → 월 약 192시간
격차 ≈ 월 16시간... 처럼 보이지만 이 계산은 틀렸다

과제 2 — 릴리즈 게이트 초안 설계

배포 차단 조건 4개와 배포 후 롤백 기준 2개를 정하고, 각각에 대해 다음을 적는다.

조건 | 판정 방법(자동/수동) | 예외 승인자 | 예외 시 남기는 기록

예외 승인자를 정하지 못하는 조건은 현실에서 운영되지 않는다. 그 조건은 지우거나 기준을 낮춘다.

과제 3 — 조직 형태 전환 제안서 한 장

지금 조직이 어느 형태인지 진단하고, 다음 6개월의 성장 계획에 맞는 형태를 제안한다. 포함할 항목은 네 가지다 — 현재 병목의 증거(숫자), 제안 형태, 전환 중 위험, 첫 30일 계획.

과제 4 — 전환 신호 네 숫자 측정하기

앞의 신호 표를 자기 조직(또는 공개된 오픈소스 프로젝트의 저장소·이슈 기록)에 적용해 실제로 계산해 본다. 추정값이어도 괜찮다 — 중요한 것은 데이터를 어디서 꺼냈는지 적는 것이다.

신호            | 값 | 어느 데이터에서 | 안정/경고/위험
릴리즈 지연      |    |                 |
핫픽스 비율      |    |                 |
결함 재오픈율    |    |                 |
적응 시간        |    |                 |
반복 장애 비율   |    |                 |

자가 체크리스트

• 수동 회귀가 무너지기 전의 신호 다섯 가지를 자기 조직에서 점검할 수 있다
• 릴리즈 빈도 계획을 근거로 자동화 필요성을 숫자로 제시할 수 있다
• 자동화 우선순위를 돈의 경로 → 스모크 → API → 재발 영역 순으로 설명할 수 있다
• 배포 차단 조건과 예외 승인 경로를 함께 설계할 수 있다
• 중앙집중·임베디드·혼합·QE 중심 조직의 차이와 적용 시점을 구분할 수 있다
• DORA 지표를 품질과 속도의 공통 언어로 사용할 수 있다
• 개인기와 시스템의 차이를 "그 사람이 2주 휴가를 가면 무엇이 멈추는가" 로 판별할 수 있다
• 인원 증가로 풀리는 문제와 풀리지 않는 문제를 각각 두 개 이상 들 수 있다
• 전환 신호 네 숫자를 자기 조직 데이터에서 직접 계산할 수 있다
• 자동화 전에 환경·테스트 데이터가 먼저 막히는 이유를 설명할 수 있다
• 릴리즈 열차가 일정 압박을 QA에게서 떼어 내는 구조를 설명할 수 있다
• 장애 대응 뼈대에서 QA가 맡는 두 칸(영향 범위 판정·재발 방지)을 말할 수 있다
• 온보딩 산출물 다섯 개와 각각의 측정 방법을 댈 수 있다
• 조직 형태 전환 순서(임베디드 → 혼합)를 뒤집으면 안 되는 이유를 설명할 수 있다
• 품질 편차를 스쿼드별 지표로 측정하고 최소 공통 기준을 세 개로 줄일 수 있다

흔한 실수

자동화를 "비용 절감" 으로만 제안한다. 시리즈 B 경영진의 관심은 절감이 아니라 성장 계획의 실행 가능성이다. 같은 내용도 "주 2회 배포를 가능하게 하는 전제" 로 프레이밍할 때 통과한다.

UI E2E부터 대규모로 만든다. 가장 눈에 보이지만 가장 비싼 층이다. 6개월 뒤 유지보수가 팀을 잡아먹고, 그 경험이 조직에 "자동화는 실패한다" 는 기억으로 남는다.

인원만 늘리고 조직 형태를 그대로 둔다. 중앙집중 QA에 사람을 더 넣으면 병목이 길어질 뿐이다. 형태 전환 없이 규모만 키우는 것이 이 구간의 대표적 실패다.

예외가 불가능한 게이트를 만든다. 급한 핫픽스가 게이트에 막히는 일이 두어 번 반복되면 팀은 게이트를 끈다. 예외 경로와 기록이 게이트를 살린다.

기술 부채 회수를 로드맵에 넣지 않는다. 시리즈 B의 속도로 6개월을 달리면 부채가 반드시 쌓인다. 분기마다 일정 비율을 회수 작업에 배정하지 않으면, 시리즈 C 실사에서 한꺼번에 청구서가 온다.

환경·테스트 데이터를 정리하지 않고 자동화를 시작한다. 공유 환경 하나와 손으로 만드는 데이터 위에 스위트를 올리면 플레이키가 먼저 쌓인다. 빨간 불을 무시하는 습관이 생기면 그 뒤에 만든 좋은 테스트도 함께 무력해진다. 순서는 환경·데이터 → 스모크 → 확장이다.

측정 없이 전환한다. 전환 전 숫자를 기록하지 않으면 전환 뒤에 나아졌는지 말할 수 없고, 첫 달의 사고가 그대로 "전환 실패" 로 해석된다. 기준선을 1주차에 만든다.

플랫폼 팀을 먼저 만든다. 쓰는 사람이 아직 없을 때 공통 도구를 만들면, 아무도 안 쓰는 프레임워크가 남는다. 임베디드로 쪼개 중복이 눈에 보인 뒤에 공통화한다.

모든 스쿼드의 기준을 전사로 통일하려 한다. 전부 맞추려는 시도는 거의 항상 중단된다. 최소 공통 기준을 세 개로 줄이고 나머지는 스쿼드 재량으로 남기는 쪽이 실제로 유지된다.

장애 포스트모템을 "누가 실수했다" 로 끝낸다. 재발 방지 항목이 테스트로 고정되지 않으면 같은 장애가 분기마다 돌아온다. 반복 장애 비율이 그 누락을 그대로 보여준다.

개인기를 가진 사람의 번아웃을 품질 문제와 따로 본다. 밤과 주말을 특정 몇 명이 떠안는 구조에서 그 사람이 떠나면, 조직은 지식과 대응 능력을 한꺼번에 잃는다. 온콜 로테이션은 복지가 아니라 지식 분산 장치다.

참고 자료

• Engineering Hiring at Series A: The Complete Guide (2026) — 성장 구간 엔지니어링 조직 확장 논의
• Why Your First QA Hire Isn't Working (Autonoma) — 범위 과부하와 유지보수 트레드밀
• 시드에서 시리즈 B까지 — 투자유치 전략
• 스타트업 투자 라운드 정리 (eopla)

이 커리큘럼 안에서

• 모듈 27 레슨 1 — 투자 라운드 지도. 단계마다 품질의 정의가 바뀌는 큰 그림
• 모듈 27 레슨 3 — 시리즈 A. 지표 데이터 정합성이 먼저 오는 구간
• 모듈 27 레슨 5 — 실사와 엑싯. 이 단계에서 남긴 기록이 자료로 제출되는 자리
• 모듈 27 레슨 7 — 런웨이와 QA 예산. 전환 제안을 언제 올릴지의 타이밍
• 모듈 4 레슨 2 — 리스크 기반 테스트. 비용 0으로 회귀 범위를 줄이는 첫 수단
• 모듈 4 레슨 5 — 릴리즈 판정. 게이트 조건의 원형
• 모듈 6 레슨 3 — 비난 없는 결함 커뮤니케이션. 포스트모템이 재발 방지로 가게 하는 태도
• 모듈 6 레슨 5 — 품질 지표. 전환 신호 네 숫자를 만드는 기록 체계
• 모듈 7 레슨 2 — 테스트 데이터 관리. 자동화가 멈추는 첫 지점
• 모듈 7 레슨 6 — 성숙도 모델. "한 번에 하나" 의 속도
• 모듈 7 레슨 9 — 테스트 조직. 중앙집중·임베디드·혼합 구조의 상세
• 모듈 11 레슨 3 — 자동화 ROI. 한계선 계산의 원본 틀
• 모듈 12 레슨 5 — 소비자 주도 계약 테스트. 외부 연동 플레이키의 대안
• 모듈 14 레슨 4 — 품질 게이트 설계. 차단 조건을 파이프라인에 올리는 방법
• 모듈 14 레슨 7 — SLO·에러 버짓. 속도와 품질을 한 숫자에서 다루기
• 모듈 22 레슨 12 — 도구 선택과 교체 비용. 되돌리기 비싼 결정의 계산
• 모듈 26 레슨 7 — 경영진 보고. 전환 제안의 형식
• 모듈 43 레슨 7 — 의사결정용 상태 보고. 기준선과 추세를 적는 법
• 모듈 55 레슨 1 — 자동화 아키텍처. 공통화를 언제 하는가
• 모듈 59 레슨 3·4 — 테스트 환경·데이터 운영과 플레이키 격리. 자동화의 바닥

한 줄 정리 — 시리즈 B는 개인기로 버티던 품질이 시스템 없이는 유지되지 않는 지점을 지나는 구간이다. 그 전환은 공지되지 않고 릴리즈 지연·핫픽스 비율·재오픈율·신규 입사자 적응 시간이라는 숫자로 먼저 나타난다. 그리고 그 숫자가 가리키는 문제는 대부분 사람을 더 뽑아서 풀리지 않는다 — 대기열, 공유 환경, 반복되는 범위 판단은 전부 구조의 문제이기 때문이다. 순서는 환경·데이터 → 돈의 경로 스모크 → 조직 형태 전환 → 릴리즈 열차와 게이트 → 온보딩 산출물이고, 그 전에 기준선 숫자를 먼저 재 둔다.