프리시드·시드: 무엇을 테스트하지 않을 것인가를 정하는 일

개념

이 단계의 제약을 먼저 인정한다

시드 단계의 제품은 양산차가 아니라 풍동 실험용 목형에 가깝다. 목형에 에어백과 열선 시트를 달지 않는다. 달아 봐야 다음 주에 차체 형상이 바뀌면 같이 버려진다. 그런데 그 목형을 사람이 타는 시험 주행에 쓰기로 했다면 브레이크는 있어야 한다. 이 레슨은 그 둘을 가르는 선을 어디에 긋는지를 다룬다.

프리시드·시드 기업의 개발 조직은 흔히 2~5명이다. 전담 QA는 없고, 테스트 환경도 하나뿐이거나 아예 로컬뿐이며, 제품 방향이 2주마다 바뀐다. 여기서 대기업식 테스트 프로세스를 제안하면 옳지만 채택되지 않는 제안이 된다.

이 구간의 진짜 질문은 "어떻게 잘 테스트할 것인가" 가 아니라 이것이다.

지금 가진 시간의 총량이 하루 2시간뿐이라면, 그 2시간을 어디에 쓰고 나머지를 의도적으로 포기할 것인가.

모듈 4에서 배운 리스크 기반 테스트가 가장 순수한 형태로 필요한 곳이 여기다. 차이는 하나뿐이다 — 여기서는 포기 목록을 문서로 남기는 것이 계획서를 쓰는 것보다 중요하다.

이 단계에서는 과잉 품질 투자가 실제로 해롭다

"품질에 더 쓰는 것이 나쁠 리 없다" 는 직관이 이 구간에서는 틀린다. 시드 단계의 품질 자산은 유지 비용을 동반한 자산이고, 그 비용이 제품을 바꾸는 비용에 그대로 더해지기 때문이다.

이 단계에서 지켜야 하는 것은 코드의 견고함이 아니라 버릴 수 있는 능력(throwaway) 이다. 폐기 비용이 큰 자산을 쌓으면 팀은 무의식적으로 바꾸지 않는 쪽을 고르고, 그 결과 틀린 가설을 더 오래 붙든다. 단, 이 논리는 다음 절의 네 가지에는 적용되지 않는다.

의도적 부채와 사고의 구분

시드 단계에서 "제대로 안 만든 것" 은 대부분 잘못이 아니다. 폐기될 수도 있는 기능에 견고한 구조를 미리 넣는 것이 오히려 낭비다. 문제는 의도한 부채와 모르고 생긴 구멍이 섞여 있을 때다.

QA가 없는 팀에서 이 목록을 만드는 것만으로도 역할이 성립한다. "무엇이 약한지 아는 팀" 과 "모르는 팀" 의 차이는 다음 라운드의 기술 실사에서 그대로 드러난다. (레슨 5)

단계와 무관한 최소선 네 가지

포기 목록을 쓰기 전에, 포기 목록에 들어갈 수 없는 것을 먼저 고정한다. 기준은 중요도가 아니라 되돌리는 비용이다.

네 영역의 공통점은 되돌리는 비용이 만드는 비용보다 크다는 것이다. 트래픽이 적다는 사실은 성능 테스트를 미룰 근거는 되어도 이 넷을 미룰 근거는 되지 않는다. 사용자가 10명인 서비스에서 결제 중복 청구가 나면 그 10명이 전부 초기 레퍼런스 고객이다.

실패 비용이 비대칭적으로 큰 두 지점

최소선이 "되돌릴 수 없어서" 지키는 것이라면, 아래 둘은 "틀렸을 때 회사가 흔들려서" 지킨다.

둘 다 사용자 수와 무관하게 위험하다. 트래픽이 적다는 사실이 성능 테스트를 미룰 근거는 되어도 이 둘을 미룰 근거는 되지 않는다.

"검증하지 않기로 한 목록" 을 쓰는 법

이 레슨의 핵심 산출물이다. 테스트 계획서가 아니라 한 장이고, 왼쪽보다 오른쪽이 중요하다.

검증 범위 합의서 (1장)                        작성 2026-10 / 작성자 ___
 
[보는 것] 배포 직전 15분
  1. 로그인 → 핵심 작업 1건 완료        2분   깨지면: 제품을 쓸 수 없다
  2. 결제 성공 1건 + 실패 1건           4분   깨지면: 돈이 틀린다
  3. 신규 가입 계정으로 첫 화면          2분   깨지면: 신규 유입이 빈 화면을 본다
  4. 저장 후 재접속 시 데이터 유지       3분   깨지면: 사용자 입력이 사라진다
  5. 관리자 삭제의 확인 단계            2분   깨지면: 되돌릴 수 없다
 
[보지 않는 것 — 합의 사항]
  · 크롬 외 브라우저 호환        사유: 사용자 94%가 크롬
  · 모바일 웹 레이아웃           사유: 이번 분기 타깃 아님
  · 동시 접속 100명 이상 성능     사유: 현재 DAU 40
  · 관리자 조회·수정 화면        사유: 내부 2명만 사용, 수동 복구 가능
  · 다국어·시간대                사유: 국내 단일 시장
 
[재검토 시점] 유료 고객 10곳 돌파 / 다음 라운드 준비 착수 / 피벗 확정
[읽고 동의한 사람] 대표 ___   개발 ___   (날짜 ___)

이 문서가 생기면 세 가지가 함께 생긴다.

• 장애가 났을 때 "몰랐다" 가 아니라 "그때 그 사유로 안 보기로 했다" 가 된다
• 사유가 숫자라서 사유가 깨지는 시점이 자동으로 재검토 시점이 된다. "사용자 94%가 크롬" 이 70%로 내려가면 그 줄은 스스로 다시 열린다
• 다음 라운드 기술 실사에서 관리된 리스크의 증거가 된다 (레슨 5)

분량은 한 장을 넘기지 않는다. 두 장이 되면 아무도 읽지 않고, 읽히지 않는 합의서는 합의가 아니라 메모다.

개발자가 자기 코드를 검증할 때의 한계

1인 다역 팀에서 "개발자가 테스트한다" 는 조직 구조가 아니라 동일 인물의 자기 검증이다. 한계는 능력이 아니라 구조에서 온다.

보완의 방향이 "사람을 늘리기" 가 아니라 "시선을 바꾸는 장치" 라는 점이 중요하다. 셋 다 인건비가 들지 않는다. 모듈 5 레슨 13의 짝 탐험이 이 단계에서 비용 대비 효과가 가장 큰 기법인 이유다.

지금 쌓으면 자산이 되는 것과 짐이 되는 것

시드 단계에서 만든 산출물의 상당수는 다음 단계에 부채로 넘어간다. 무엇이 넘어가고 무엇이 남는지는 미리 갈라진다.

가르는 기준은 하나다 — 제품이 바뀌어도 살아남는가. 기록(일어난 일)은 살아남고 명세(그때의 모습)는 살아남지 못한다. 쌓을 것은 문서가 아니라 이력이다.

데모 경로 테스트 — 이 단계에만 있는 QA 업무

시드 기업에서는 투자 심사역·심사위원 앞에서 도는 시연이 그 분기의 가장 중요한 실행 경로다. 일반 사용자 시나리오와 다른 점이 많아 따로 설계해야 한다.

데모 경로 점검 목록 (실제로 자주 터지는 순서)
  1. 네트워크        행사장 와이파이·핫스팟, 프록시 차단 환경에서 동작하는가
  2. 계정·데이터     데모 계정의 데이터가 초기화됐거나 만료되지 않았는가
  3. 외부 연동       결제 샌드박스·지도·소셜 로그인의 쿼터와 토큰 만료
  4. 화면            노트북 → 빔프로젝터 해상도, 확대 표시, 다크모드
  5. 시간 의존       "오늘" 기준 데이터가 행사 당일에도 비어 있지 않은가
  6. 복구 계획       실패 시 무엇을 보여줄 것인가 (녹화본·스크린샷 백업)

6번이 빠진 데모 준비가 가장 흔하다. 복구 계획이 있는 팀은 장애가 나도 침착해 보이고, 없는 팀은 무너진다.

첫 QA를 언제 뽑는가 — 일반적인 논의

업계의 조언은 대체로 "PMF 신호와 제품 방향의 안정성이 생긴 뒤" 로 모인다. 너무 이른 채용의 위험으로 자주 지적되는 것은 비용이 아니라 심리적 효과다. QA가 "품질 담당자" 가 되는 순간 개발자들이 테스트에서 손을 떼는 현상이 관찰된다는 것이다.

채용한다면 수동 테스터가 아니라 테스트 기반을 만들 수 있는 사람이어야 한다는 조언도 함께 나온다. 이 단계의 QA 1호는 혼자서 프로세스·환경·자동화의 최소 집합을 세우는 자리이기 때문이다.

사례 — 중복 청구 87만 원이 파일럿 계약을 멈춘 일

시드 단계 B2B SaaS였다. 개발 3명, QA 없음, 유료 고객 7곳, 월 구독료 29만 원. 배포 전 확인은 만든 사람이 자기 화면에서 한 번 눌러보는 것이 전부였다.

결제 모듈을 손댄 배포 다음 날, 고객 3곳에서 같은 달 구독료가 두 번 청구됐다. 합쳐 87만 원으로 크지 않았다. 문제는 금액이 아니었다.

원인은 둘이었다. 재시도 로직을 추가하면서 멱등 키(같은 요청을 두 번 보내도 한 번만 처리되게 하는 장치)를 넣지 않았다. 그리고 그 변경을 만든 개발자가 자기 테스트 계정에서 확인했는데, 그 계정은 이미 당월 결제가 완료된 상태라 중복이 애초에 재현되지 않았다.

바꾼 것은 프로세스가 아니라 한 장과 네 줄이었다.

결과는 이랬다. 결제 경로 사고는 이후 6개월간 0건, 배포 속도는 주 2회 유지 (12분이라 아무도 생략하지 않았다), 보류됐던 파일럿은 4개월 뒤 재개됐고 그때 제출한 자료가 바로 그 한 장이었다. 시리즈 A 기술 실사에서는 이 합의서의 갱신 이력이 쓰였다.

여기서 남는 교훈이 셋이다.

• 품질 투자의 총량이 아니라 배치가 문제였다. 이 팀은 그 뒤에도 전 기능 회귀를 돌리지 않았고 자동화도 하지 않았다. 바뀐 것은 12분을 어디에 썼는가뿐이다
• 최소선은 단계와 무관하다. 유료 고객 7곳, 월 29만 원 규모에서도 돈의 경로 사고는 계약과 투자자 대화까지 올라갔다
• 한 장의 합의서가 두 번 일했다 — 사고 당시에는 책임 논의를 재발 방지로 바꾸고, 넉 달 뒤에는 고객과 투자자에게 내는 증거가 됐다

실무에서 왜 필요한가

"테스트할 시간이 없다" 에 대응하는 유일한 방법

시드 단계에서 품질 제안이 거절되는 이유는 반대해서가 아니라 시간이 실제로 없어서다. 그래서 이 단계의 제안은 언제나 총량이 고정된 형태여야 한다.

거절되는 제안: "릴리즈 전에 회귀 테스트를 돌리자"
채택되는 제안: "배포 직전 15분, 다섯 개만 본다. 목록은 이것이고,
               여기서 걸리면 배포를 멈춘다. 나머지는 안 본다고 합의한다."

두 번째 제안의 핵심은 "나머지는 안 본다" 를 명시한 것이다. 그래야 팀이 그 15분을 비용으로 받아들이고, 통과했을 때의 의미도 분명해진다.

범위를 적어두면 사고 후의 대화가 달라진다

사고 직후 팀에서 나오는 첫 질문은 거의 항상 "이걸 왜 아무도 못 봤나" 다. 이 질문에는 답이 없다. 아무도 안 보기로 한 적이 없으니 누군가 안 본 것이 되고, 논의는 곧 사람 쪽으로 간다.

검증 범위가 한 장 적혀 있으면 질문이 바뀐다 — "이것은 안 보기로 한 영역인가, 보기로 했는데 빠진 것인가." 전자면 사유가 틀렸으므로 합의를 갱신하는 일이고, 후자면 점검 목록을 고치는 일이다. 둘 다 다음 행동이 있는 질문이다. 모듈 6 레슨 3의 비난 없는 결함 커뮤니케이션이 초기 기업에서 실제로 작동하려면 이 문서가 먼저 있어야 한다.

창업자와 대화가 가능해진다

이 단계의 의사결정권자는 대개 창업자 본인이다. 모듈 26에서 배운 C레벨 커뮤니케이션이 가장 짧은 경로로 작동하는 환경이면서, 동시에 가장 급한 판단이 오가는 환경이기도 하다. "이 결함은 데모 전까지 못 고치면 시연 순서를 바꿔야 합니다" 같은 문장이 통하는 이유는 QA가 회사의 일정(라운드 일정)을 알고 말하기 때문이다.

채용시장에서의 위치

"QA 1호" 공고는 경력 3~7년 구간에서 자주 열린다. 요구사항이 길고 모호한 것이 특징인데, 실제로 평가되는 것은 도구 숙련도보다 없는 상태에서 순서를 정하는 능력이다.

질문은 대개 "없는 상태에서 무엇부터 하겠는가" 를 돌려 묻는 형태로 온다. 답이 갈리는 지점은 이렇다.

두 번째와 다섯 번째가 변별력이 가장 크다. 둘 다 "무엇을 하겠다" 가 아니라 무엇을 안 하겠다 를 말한다. 초기 기업 면접관(대개 대표나 CTO)이 경계하는 지원자는 능력이 부족한 사람이 아니라 큰 조직의 프로세스를 그대로 들고 오는 사람이다. 들고 오면 2주 뒤 아무도 쓰지 않고, 그 2주가 런웨이다.

다섯 번째 답의 구조도 볼 만하다. 사수 목록과 포기 목록을 같은 호흡으로 말한다. 포기만 말하면 품질 기준이 없는 사람으로 읽히고, 사수만 말하면 단계를 모르는 사람으로 읽힌다. 둘을 같이 말할 때 비로소 "제약 안에서 선을 그을 수 있는 사람" 이 된다.

세 번째는 조건과 타이밍이 붙어 있다는 점에서 강하다. 역질문으로도 쓸 수 있다 — "현재 런웨이에서 품질에 쓸 수 있는 시간이 주당 몇 시간인가요" 는 지원자가 이 단계의 언어를 안다는 신호가 된다. (레슨 7)

실습 과제

과제 1 — 15분 스모크 목록 만들기

임의의 서비스(또는 본인이 다루는 제품) 하나를 정해 배포 직전 15분 안에 끝나는 점검 목록을 만든다. 조건은 다음 세 가지다.

1. 항목은 5개 이하, 각 항목은 3분 이내
2. 각 항목에 "이게 깨지면 회사에 무슨 일이 생기는가" 를 한 줄로 적는다
3. 의도적으로 보지 않기로 한 영역을 별도 목록으로 함께 적는다

3번이 없으면 과제 미완성이다.

[15분 / 5줄]
1. 로그인 → 주문 1건 완료          2분  깨지면: 제품을 쓸 수 없다
2. 카드 결제 성공 + 잔액부족 실패    4분  깨지면: 돈이 틀린다 (환불에 대표가 붙는다)
3. 신규 가입 계정의 첫 화면         2분  깨지면: 신규 유입이 빈 화면을 본다
4. 작성 후 새로고침 시 데이터 유지   3분  깨지면: 사용자 입력이 사라진다
5. 관리자 삭제 시 확인 단계         2분  깨지면: 되돌릴 수 없다
 
[보지 않음] 사파리·엣지(사용자 94% 크롬) / 모바일 웹(타깃 아님) /
            동시 100명 성능(DAU 40) / 다국어(국내 단일 시장)

과제 2 — 데모 경로 리허설

앞의 데모 점검 목록 6개 항목을 실제 제품 하나에 적용해 본다. 특히 "네트워크" 항목은 휴대폰 테더링으로 바꿔 실행하고, "시간 의존" 항목은 시스템 날짜를 바꾸거나 데이터가 없는 신규 계정으로 시연 경로를 그대로 따라가 본다.

발견한 것을 다음 형식으로 정리한다.

[데모 리스크] 신규 계정에서 대시보드가 빈 화면으로 시작
  발생 조건 : 가입 직후 데이터 0건
  시연 영향 : 첫 화면이 빈 화면 → 제품이 비어 보임
  조치      : 데모 계정 사전 시딩 / 빈 상태 문구 추가
  복구 계획 : 시딩된 백업 계정으로 전환

과제 3 — 의도적 부채 목록 만들기

팀이 "지금은 이렇게 두기로 한" 것 5가지를 찾아 아래 표로 정리하고, 각 항목에 회수 조건을 붙인다.

항목 | 현재 상태 | 이대로 두면 위험해지는 시점 | 회수 조건
정산 | 수동 엑셀  | 거래 하루 100건 초과        | 시리즈 A 자금 집행 시 자동화

"회수 조건" 칸이 비어 있는 항목은 부채가 아니라 방치다.

과제 4 — "검증하지 않기로 한 목록" 한 장 쓰고 합의받기

본문의 템플릿을 그대로 써서 자기 제품(또는 가상 제품)의 한 장을 완성한다. 조건은 넷이다.

1. 한 장을 넘기지 않는다
2. "보지 않는 것" 의 모든 줄에 숫자나 사실이 들어간 사유가 붙는다
3. 최소선 네 가지(돈·데이터 손실·개인정보·불가역) 중 보지 않는 것 칸에 숨어든 항목이 없는지 확인한다
4. 재검토 시점이 날짜가 아니라 조건으로 적힌다

(수정 전) 관리자 화면 전반    — 미검증 (사유: 내부 2명만 사용)
 
(수정 후) 관리자 조회·수정    — 미검증 (사유: 내부 2명, 수동 복구 가능)
         관리자 일괄 삭제    — 검증 대상 (사유: 되돌릴 수 없음 → 확인 단계 1줄)

자가 체크리스트

• 시드 단계에서 테스트 계획보다 "포기 목록" 이 먼저인 이유를 설명할 수 있다
• 이 단계의 과잉 품질 투자가 피벗을 막는 방식을 구체적인 예로 설명할 수 있다
• 의도적 기술 부채와 모르고 생긴 구멍을 구분해 목록으로 관리할 수 있다
• 단계와 무관한 최소선 네 가지(돈·데이터 손실·개인정보·불가역)를 외워서 말할 수 있다
• 실패 비용이 비대칭적으로 큰 두 지점을 자기 제품에서 지목할 수 있다
• 투자 데모 경로를 일반 사용자 시나리오와 다르게 설계할 수 있다
• 15분 안에 끝나고 "보지 않는 범위" 가 명시된 스모크 목록을 만들 수 있다
• "검증하지 않기로 한 목록" 을 한 장으로 쓰고 모든 줄에 사유를 붙일 수 있다
• 그 목록의 재검토 시점을 날짜가 아니라 조건으로 적을 수 있다
• 개발자 자기 검증의 한계 세 가지와 비용 0의 보완책을 댈 수 있다
• 지금 쌓으면 자산이 되는 기록과 짐이 되는 문서를 구분할 수 있다
• 사고 후 "왜 못 봤나" 를 "안 보기로 한 것인가, 빠진 것인가" 로 바꿔 물을 수 있다
• 첫 QA 채용을 미뤄도 되는 신호와 지금 필요한 신호를 구분할 수 있다
• 면접에서 "무엇을 포기하겠는가" 에 사수 목록과 포기 목록을 함께 답할 수 있다

흔한 실수

초기 기업에 완성된 프로세스를 이식하려 한다. 테스트 계획서·추적 매트릭스·결함 등급 체계를 한 번에 도입하면 2주 뒤 아무도 쓰지 않는다. 이 단계에서는 한 장짜리 목록 하나가 문서 열 개보다 오래 살아남는다.

회귀 스위트를 먼저 만든다. 시드 단계의 전 기능 회귀 자동화는 품질 자산이 아니라 피벗 저항체다. 흐름이 바뀌면 절반이 깨지고, 복구 비용이 커지면 팀은 무의식적으로 바꾸지 않는 쪽을 고른다. 품질 활동이 가설 검증을 늦추고 있다면 그 활동은 이 단계에서 틀렸다.

"트래픽이 적으니 괜찮다" 를 결제·개인정보까지 확장한다. 성능은 미뤄도 되지만 돈과 개인정보는 사용자 수와 무관하게 사고가 된다. 초기 기업의 유출 사고는 회사 자체를 끝낼 수 있다.

최소선을 "큰 기능" 안에서만 찾는다. 되돌릴 수 없는 것은 결제 화면보다 전체 발송 버튼·일괄 삭제·외부 연동 웹훅 같은 조용한 자리에 많다. 관리자 화면이 "내부 2명만 쓴다" 는 이유로 통째로 제외되는 것이 가장 흔한 사고 경로다.

"보지 않는 것" 에 사유를 적지 않는다. 사유 없는 포기는 다시 열릴 조건이 없다. "모바일 미검증" 은 1년 뒤에도 미검증이고, 그 사이 사용자 절반이 모바일로 넘어와 있어도 아무 일이 일어나지 않는다.

합의서를 QA 혼자 쓰고 서명을 받지 않는다. 읽은 사람이 없는 문서는 사고 당시에 꺼내도 "그건 네 메모" 가 된다. 대표와 개발자의 이름·날짜가 들어가야 메모가 합의가 된다.

개발자의 자기 확인을 "테스트했다" 로 집계한다. 만든 사람의 확인은 구현 확인이지 검증이 아니다. 같은 가정을 두 번 쓰기 때문이다. 데모 리허설도 같다 — 만들지 않은 사람이 처음 보는 계정으로 따라가야 의미가 있다.

부채 목록을 만들고 회수 조건을 안 적는다. "나중에 고친다" 는 목록은 다음 라운드까지 그대로 남고, 실사에서 관리되지 않은 리스크로 읽힌다.

QA가 생겼다는 이유로 개발자 테스트가 사라진다. 첫 QA가 들어온 뒤 오히려 품질이 나빠지는 흔한 경로다. 첫 달에 "테스트는 여전히 팀 전체의 일" 이라는 합의를 명시적으로 만들어 두어야 한다.

참고 자료

• When Should a Startup Hire QA? (TestDevLab)
• First QA Engineer in a Startup (Codacy)
• Should You Hire a QA Engineer? A Decision Framework for Startups (Autonoma) — 조기 채용의 심리적 위험 논의
• 스타트업 초기 투자 라운드 — 프리시드부터 시리즈 A까지 (Eagler Lab)

이 커리큘럼 안에서

• 모듈 27 레슨 1 — 투자 라운드 지도. 이 단계가 무엇을 증명하는 구간인지
• 모듈 27 레슨 3 — 시리즈 A. 여기서 남긴 결함 기록이 지표 정합성 작업의 기준선이 된다
• 모듈 27 레슨 4 — 시리즈 B. 회귀 자동화가 "과잉" 에서 "지각" 으로 뒤집히는 지점
• 모듈 27 레슨 5 — 실사와 엑싯. 검증 범위 합의서가 증거로 제출되는 자리
• 모듈 27 레슨 7 — 런웨이와 QA 예산. "주당 몇 시간" 의 상한이 어디서 나오는지
• 모듈 4 레슨 2 — 리스크 기반 테스트. 포기 목록의 원형
• 모듈 4 레슨 5 — Go/No-Go. 15분 점검에서 걸렸을 때 배포를 멈추는 근거
• 모듈 5 레슨 3 — 악몽의 머리기사. 최소선 네 가지를 자기 제품에서 찾아내는 방법
• 모듈 5 레슨 13 — 짝 탐험. 이 단계에서 비용 대비 효과가 가장 큰 기법
• 모듈 6 레슨 2 — 결함 리포트. 기록을 자산으로 만드는 최소 형식
• 모듈 6 레슨 3 — 비난 없는 커뮤니케이션. 합의서가 먼저 있어야 작동한다
• 모듈 6 레슨 5 — 품질 지표. 지금 남긴 기록이 기준선이 되는 곳
• 모듈 7 레슨 2 — 테스트 데이터. 고정 계정 3종을 만드는 법
• 모듈 7 레슨 3 — 테스트 환경. 환경 분리를 "언제" 제안할지
• 모듈 26 레슨 7 — 경영진 보고. 창업자에게 한 장으로 말하는 형식

한 줄 정리 — 프리시드·시드에서 QA가 없는 것은 문제가 아니다. 문제는 무엇을 검증하지 않기로 했는지 아무도 모르는 것이다. 이 단계의 품질 투자는 총량이 아니라 배치이고, 과잉 투자는 폐기 비용을 키워 피벗 자체를 막는다. 그래서 산출물은 테스트 계획서가 아니라 사유와 재검토 조건이 붙은 한 장의 검증 범위 합의서다. 단, 그 한 장 안에서 돈·데이터 손실·개인정보·되돌릴 수 없는 것 네 가지는 단계와 무관하게 사수 목록에 남는다.