시리즈 C 이후와 엑싯: 기술 실사·상장 준비에서 QA가 내놓는 증거

개념

중고차를 살 때 보는 것은 설명이 아니라 정비 이력부다

중고차를 살 때 판매자의 설명은 참고 자료일 뿐이다. 값을 정하는 것은 정비 이력부와 사고 기록 이다. 그리고 그 이력부는 차를 팔기로 결심한 날에 만들 수 없다. 3년간 정비소에 들를 때마다 한 줄씩 쌓여 있어야 그날 꺼낼 것이 있다.

후기 라운드의 심사가 정확히 이 구조다. 회사의 설명(IR 자료, 아키텍처 다이어그램)은 출발점이고, 값과 조건을 움직이는 것은 기록 이다. 그래서 이 레슨의 결론은 앞선 레슨들보다 단순하다 — 평시의 기록이 그 시점에 자산이 된다.

후기 라운드의 심사는 "열어본다"

시리즈 C 이상과 M&A·IPO 구간의 심사는 설명을 듣는 데서 끝나지 않는다. 투자자·인수자는 기술 실사(Technical Due Diligence, Tech DD) 를 통해 아키텍처·코드·보안·개발 프로세스를 직접 확인한다. IT 인프라와 운영 프로세스를 보는 IT 실사(ITDD)가 함께 진행되기도 한다.

여기서 나온 리스크는 보고서로 끝나지 않는다. 가격과 조건을 바꾼다 — 밸류에이션 조정, 인수 후 통합(PMI) 비용 반영, 선행 조건(수정 후 클로징), 심하면 딜 중단이다.

레슨 1에서 "증명 대상이 가능성 → 반복 가능성 → 관리 가능성으로 옮겨간다" 고 했다. 실사는 그 마지막 단계를 외부인이 직접 채점하는 자리 다.

기술 실사가 보는 영역

표의 오른쪽 칸이 이 레슨의 핵심이다. 실사에서 QA 조직은 의견이 아니라 기록으로 답한다.

실사는 어떤 일정으로 흘러가는가

실사를 한 번도 겪지 않은 QA에게 가장 막막한 것은 "그래서 내가 언제 뭘 하느냐" 다. 전형적인 흐름은 이렇다.

기술 실사 진행 (전형적으로 4~8주)
  0주   NDA·텀시트/LOI        자료 요청 목록(RFI) 수령
  1주   데이터룸 개설          회사가 자료 업로드
  2주   1차 서면 검토          실사자가 읽고 질의 목록을 만든다
  3주   Q&A + 인터뷰           CTO·개발리드·QA리드 면담 (각 1~2시간)
  4주   원본 확인              저장소 열람, CI 기록, 접근 로그 표본
  5주   보고서 초안            발견 사항 + 리스크 등급 + 조치 비용 추정
  6주~  가격·조건 반영         밸류에이션 조정 / 선행 조건 / 에스크로 / 중단
 
        ↑ QA가 개입할 수 있는 구간은 1~4주 (대응)
        ↑ QA가 준비해야 하는 구간은 그 앞 2~3년 (기록)

마지막 두 줄이 이 레슨 전체의 요약이다. 대응에 쓸 수 있는 시간은 몇 주고, 그 몇 주에 할 수 있는 일은 이미 있는 것을 꺼내는 일 뿐이다.

레드 플래그 — 실사에서 값을 깎는 항목

자주 지적되는 것
  · 자동화 테스트가 거의 없고 릴리즈가 수동 검증에 의존
  · 결함 추적 시스템이 없거나 최근 6개월 기록이 비어 있음
  · 프로덕션 접근 권한이 다수에게 상시 부여
  · 취약점 스캔 결과는 있으나 조치 이력이 없음
  · 핵심 모듈을 아는 사람이 1명뿐
  · 오픈소스 라이선스 목록을 제시하지 못함
  · 장애 이력과 원인 분석 기록이 없음

공통점은 "안 했다" 가 아니라 "증명할 수 없다" 이다. 실제로 잘 돌아가는 조직도 기록이 없으면 실사에서 리스크로 계산된다. 이것이 앞선 레슨들이 계속 "기록을 남기라" 고 한 이유다.

그리고 한 가지 더 알아 둘 것이 있다. 실사자는 확인되지 않은 영역을 좋게 추정하지 않는다. 불확실한 항목은 보수적으로, 즉 나쁜 쪽으로 계산된다. 숨기는 것이 불리한 이유가 여기 있다.

자료 요청 목록(RFI)은 실제로 이렇게 생겼다

데이터룸에 뭘 올리라는 요청은 추상적인 문장으로 오지 않는다. 번호가 붙은 항목 수십 개로 오고, 기술 쪽 항목만 보면 대개 이런 형태다.

굵게 표시한 부분을 보라. 거의 모든 항목에 기간 또는 표본 이 붙는다. 이것이 실사 요청의 결정적 성질이다 — 요청받은 것은 문서가 아니라 과거의 시간 이다.

데이터룸에 들어가는 QA 산출물

실사는 자료를 모아둔 데이터룸 에 회사가 문서를 올리고 질의응답을 주고받는 방식으로 진행된다. QA 조직이 준비할 수 있는 항목은 대체로 다음과 같다.

숫자를 꾸미지 않는다. 실사에서 드러난 불일치는 해당 항목 하나가 아니라 회사가 제출한 자료 전체의 신뢰도 를 떨어뜨린다. 미해결 결함이 많다면 숨기는 대신 분류와 계획 을 함께 제시하는 편이 언제나 낫다.

미리 만들 수 있는 것과 급하게는 만들 수 없는 것

이 구분이 이 레슨에서 가장 실용적인 지식이다. 실사 통보를 받은 뒤 쓸 수 있는 시간은 2~4주인데, 그 안에 만들 수 있는 항목과 원리적으로 불가능한 항목 이 섞여 있다. 둘을 가르지 않으면 가능한 것에 쓸 시간을 불가능한 것에 쓴다.

불가능 칸이 더 길다. 그리고 불가능 칸은 전부 평소에 도구를 제대로 쓰고 있었다면 버튼 몇 번으로 나오는 것 들이다. 결함 추적 도구에 상태를 제때 옮기는 일(모듈 6·22), 릴리즈마다 기록을 남기는 일(모듈 7), 로그 보관 기간을 짧게 깎지 않는 일이 몇 년 뒤 딜의 조건을 바꾼다.

로그 보관 기간은 인프라 비용 절감 때 가장 먼저 깎이는 항목이다. 90일로 줄여 둔 조직은 "최근 24개월 접근 로그" 요청에 답할 방법이 없다. 깎을 때 실사·감사 요구 기간 을 같이 계산해야 한다.

인터뷰에서 드러나는 것은 지식이 아니라 일관성

서면 검토가 끝나면 인터뷰가 온다. 실사자는 같은 질문을 CTO·개발리드·QA리드에게 따로 한다. 답이 갈리면 그 불일치 자체가 발견 사항으로 적힌다.

두 번째 칸이 전부 "있다/없다" 가 아니라 "일치하는가" 를 묻는다는 점을 보라. 문서에 적힌 절차와 실제 운영이 어긋나면, 문서가 없는 것보다 나쁜 평가를 받는다. 없는 것은 미성숙이지만, 어긋난 것은 통제 불능 으로 읽힌다.

상장 준비 구간의 추가 요구

국내 기술 기업의 상장 경로에는 기술특례상장 이 있다. 전문 평가기관의 기술평가 등급이 기본 요건이고, 2026년 기준으로는 기준시가총액이 매우 큰 기업·딥테크 기업 등에 대해 평가 기관 수를 줄이거나 평가를 생략하는 간소화 절차가 적용된다. 2023년부터는 코스닥 표준기술평가모델로 기술 구분별 평가 체계가 세분화됐고, 2025년 말에는 AI·우주·에너지 산업에 대한 맞춤형 질적심사 기준이 시행됐다.

상장 준비 기업의 QA에게 실제로 늘어나는 일은 증적(evidence) 이다.

상장 준비 구간에서 늘어나는 요구
  · 변경관리 증적       누가 승인하고 무엇을 배포했는지 추적 가능한가
  · 권한 분리           개발자가 프로덕션 데이터를 직접 수정할 수 있는가
  · 접근 통제 기록      운영 접근 로그가 남고 정기적으로 검토되는가
  · 보안 체계 증명      ISMS-P·ISO/IEC 27001·SOC 2 같은 제3자 인증
  · 장애·사고 대응 절차 문서화된 절차와 실제 수행 기록의 일치

인증은 그 자체가 목적이 아니라 외부에 체계를 증명하는 수단 이다. 어떤 인증이 필요한지는 업종·고객·상장 시장에 따라 다르므로 법무·재무·보안 조직과 함께 판단한다. 표준 지형 전체는 모듈 25에서 다뤘다.

실무적으로 QA가 먼저 손댈 수 있는 지점은 변경관리 증적 이다. 별도 시스템을 사는 일이 아니라, 이미 쓰는 이슈 추적·배포 파이프라인에 승인자·사유·대상 버전 필드를 필수로 만드는 일 이기 때문이다. 필드가 없으면 절차는 문서에만 있고, 필드가 있으면 절차는 데이터가 된다.

M&A로 인수되는 경우 — 통합이 곧 테스트 과제

인수 후 통합(PMI) 구간에서는 계정 체계 통합, 데이터 이관, 결제·정산 통합, 브랜드 전환이 한꺼번에 온다. 모듈 4 레슨 6에서 다룬 마이그레이션·전환 검증 이 이때 회사 규모로 수행된다. 인수 협상 단계에서 QA가 통합 난이도를 현실적으로 추정해 주면, 그 자체가 협상 자료가 된다.

PMI에서 QA에게 내려오는 일
  계정·인증 통합      SSO 전환, 중복 계정 병합, 권한 매핑
  데이터 이관         스키마 차이, 중복·유실 검증, 건수·금액 합 대조
  결제·정산 통합      과금 주체 변경, 세금계산, 환불 경로 재설계
  브랜드·도메인 전환   리다이렉트, 발송 도메인 평판, 딥링크
  프로세스 합치기      결함 등급 기준, 릴리즈 게이트, 도구 통합

마지막 줄이 가장 늦게 끝난다. 두 회사의 "심각도 1" 이 같은 뜻이 아니기 때문이다. 통합 직후 품질 지표가 흔들리는 가장 큰 원인은 장애가 늘어난 것이 아니라 세는 기준이 섞인 것 인 경우가 많다.

사례 — 자동화 "70%" 가 밸류에이션 조정 근거가 된 경위

시리즈 C 실사였다. 회사가 데이터룸에 올린 기술 자료에 "회귀 테스트 자동화 70% 달성" 이라는 한 줄이 있었다. 실사자가 요청한 것은 두 가지였다 — 그 수치의 산출 근거, 그리고 최근 90일 CI 실행 로그 다.

대조해 보니 이렇게 갈렸다.

실사 보고서에는 두 항목이 적혔다 — "품질 지표의 신뢰도 낮음", "변경관리 통제 미비" 다. PMI 비용 추정에 QA 기반 재구축 비용이 반영되고, 거래 금액 조정과 선행 조건이 붙었다.

원인은 거짓말이 아니었다. 70%는 누가 꾸며낸 숫자가 아니라, 분모가 정의된 적이 없는 숫자 였다. 그리고 실패한 야간 빌드를 아무도 안 보고 있었다. 팀은 그 사실을 알고 있었지만 기록으로 남겨 두지 않았다 — 즉 "관리되지 않는 상태" 로만 보였다.

실사 이후 팀이 바꾼 것은 셋이다.

1년 뒤 다른 인수자와의 실사에서 같은 영역은 지적 없이 통과했다. 제출한 숫자는 여전히 70%가 아니었다.

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

• 정의 없는 지표는 자산이 아니라 부채다. 검증되면 41%보다 나쁘게 읽히는 70%가 있다.
• 실사가 보는 것은 수치의 높이가 아니라 수치와 원본 기록의 일치 여부다.
• 낮은 숫자를 그대로 내고 개선 기록을 함께 내는 쪽이 항상 유리하다. 숫자는 비교되지만 추세와 통제는 신뢰로 계산된다.

실무에서 왜 필요한가

실사는 갑자기 시작되고 짧게 끝난다

실사 요청은 대개 몇 주 단위로 진행된다. 그 기간에 없는 기록을 만들어낼 수는 없다. 평소 운영이 그대로 제출물이 되는 구조 여야 대응이 가능하다. 결함 추적 도구를 제대로 쓰는 일(모듈 6·22)이 몇 년 뒤 딜의 조건을 바꾼다.

같은 기록의 값이 시점에 따라 달라진다

QA가 남기는 기록은 평시에는 운영 도구 이고, 실사 시점에는 자산 이다. 같은 데이터인데 값이 달라진다.

이 표가 QA에게 주는 실용적 의미는 하나다 — 평소 기록을 "나중에 누가 읽을 수 있게" 남겨 두면 비용이 거의 추가되지 않는다. 티켓에 한 줄 쓰는 일과 2년 뒤 그 2년을 복원하는 일은 비용이 비교되지 않는다.

QA가 회사의 리스크를 가장 먼저 아는 자리다

미해결 결함, 반복 장애, 취약한 영역은 QA 조직이 가장 먼저 안다. 실사 전에 회사 내부에서 먼저 정리해 두는 것 이 훨씬 유리하다. 내부에서 드러난 문제는 계획과 함께 제시할 수 있지만, 외부가 먼저 찾은 문제는 협상 카드가 된다.

실사 구간은 QA 제안이 통과되는 드문 창이다

레슨 1·7에서 "제안의 타이밍" 을 다뤘다. 실사 준비 구간은 그 타이밍 중 가장 강한 쪽이다. 평소에는 "나중에 하자" 로 밀리던 항목이, 실사 보고서에 리스크로 적히면 클로징 조건 이 된다.

다만 조건이 있다. 실사가 시작된 뒤에 꺼내면 늦다. 라운드 준비가 논의되기 시작할 때 (보통 현금 바닥 12개월 전) 소급 불가 항목 목록을 들고 가야, 그때부터 쌓을 수 있다.

상장 이후에는 규칙이 바뀐다

상장사가 되면 공시·내부통제·감사 요구가 붙고, "빠르게 고치고 나중에 기록하자" 가 통하지 않는다. 이 전환을 미리 준비한 조직과 그렇지 않은 조직의 차이는 상장 직후 6개월에 크게 드러난다.

채용시장에서의 위치

Pre-IPO·후기 라운드 기업의 QA 공고에는 다른 단계에 없는 표현이 등장한다.

이 구간의 QA 리드 자리는 기술 역량보다 증거를 만드는 설계 능력 으로 평가되는 경우가 많다. 모듈 8(ISO 29119)·모듈 25(표준)·모듈 7(테스트 관리)이 직접 연결되는 직무다.

질문별로 갈리는 지점

가장 변별력이 큰 질문은 세 번째다. 숫자를 물었을 때 숫자 하나로 답하는 사람과 분모·기간·산출 방법까지 함께 답하는 사람 이 갈린다. 후자는 그 지표를 직접 정의하고 방어해 본 사람만 할 수 있는 답이다. 실사에서 깨지는 지점이 정확히 여기라서, 이 질문 하나로 "실사를 겪어 봤는지" 가 거의 드러난다.

첫 번째 질문은 우선순위 감각 을 본다. 실사 대응에서 가장 흔한 실패는 열심히 일했는데 엉뚱한 데 시간을 쓴 경우다. 소급 불가 항목에 매달려 2주를 쓰면, 만들 수 있었던 항목까지 비어서 제출된다. "가린다" 는 단어가 답에 들어오는지를 보면 된다.

네 번째는 문서와 통제를 구분하는지 를 본다. 내부통제 경험을 말하면서 산출물 이름만 나열하는 답은 실제로 설계해 본 사람의 답이 아니다. 통제는 사람이 지키겠다고 약속한 절차가 아니라 지키지 않으면 진행되지 않는 구조 이고, 그 구조는 대개 필드·게이트·권한의 형태로 존재한다.

실습 과제

과제 1 — 자체 실사 리허설

현재(또는 과거) 소속 조직을 대상으로 앞의 데이터룸 항목 7개를 오늘 당장 제출할 수 있는가 로 채점한다.

항목 | 제출 가능(O/△/X) | 근거가 있는 위치 | X라면 만드는 데 걸릴 시간

X가 세 개 이상이면 실사 대응이 아니라 일상 운영의 문제 다. 그 세 개를 만드는 계획을 세운다.

1순위  지금부터 쌓기 시작해야 하는 것 (소급 불가 + 현재 미기록)
       예: CI 실행 결과 보존, 장애 타임스탬프, 배포 승인 기록
2순위  이미 데이터는 있는데 꺼내는 법이 없는 것
       예: 결함 추이 — 추출 쿼리를 만들어 저장해 둔다
3순위  언제든 쓸 수 있는 문서
       예: 테스트 전략서 — 실사 통보 후에 써도 늦지 않다

과제 2 — 레드 플래그 자가 점검

앞의 레드 플래그 7개를 하나씩 확인하고, 해당하는 항목에 대해 다음 세 줄을 적는다.

[레드 플래그] 프로덕션 접근 권한이 개발자 전원에게 상시 부여
  현재 상태 : 12명 상시, 로그 보관 30일
  실사 해석 : 권한 분리 미흡 — 데이터 무결성 보증 불가
  개선안    : 상시 권한 회수 + 승인 기반 임시 권한(만료 4시간) + 접근 로그 분기 검토

과제 3 — 미해결 결함 보고서 만들기

현재 미해결 결함을 실사용 자료 형식으로 정리한다. 숨기는 것이 목적이 아니라 관리되고 있음을 보여주는 것 이 목적이다.

심각도별 건수 / 최장 미해결 기간 / 해결 계획이 잡힌 비율
반복 재발 영역 Top 3와 각각의 근본 원인 조치
"수용된 리스크" 로 분류한 항목과 그 승인자

마지막 줄이 있는 자료와 없는 자료는 실사에서 완전히 다르게 읽힌다.

같은 "P2 결함 34건 미해결" 이 이렇게 갈린다
 
승인자 없음  → 방치 34건.  "이 조직은 미해결을 추적하지 않는다"
승인자 있음  → 수용 21건 + 처리 대기 13건.
               "이 조직은 무엇을 포기했는지 알고, 누가 결정했는지도 안다"

과제 4 — 자료 요청 한 줄에 답하는 초안 쓰기

앞의 RFI 표에서 TDD-10 한 줄만 골라 실제 제출 초안을 만든다.

요청: "최근 24개월 P1·P2 장애 목록, 영향 범위, 복구 시간, 재발 방지 조치"
 
1) 제출 범위    : 어느 기간·어느 시스템까지 답할 수 있는가
2) 원본 위치    : 그 데이터가 어느 도구의 어느 필드에서 나오는가
3) 누락과 사유  : 답할 수 없는 구간과 그 이유(도구 도입 시점, 보관 기간 등)
4) 산출 기준    : "복구 시간" 을 무엇부터 무엇까지로 세는가
5) 함께 내는 것 : 재발 방지 조치의 완료 증빙은 무엇인가

"복구 시간" 의 가능한 정의
  탐지 시각 → 정상 복구          (MTTR, 가장 흔함)
  발생 시각 → 정상 복구          (탐지 지연이 포함돼 더 길다)
  첫 보고   → 임시 조치          (짧게 나오지만 근본 조치는 빠진다)

자가 체크리스트

• 기술 실사가 보는 7개 영역과 각 영역에서 QA가 낼 수 있는 증거를 연결할 수 있다
• 실사 레드 플래그가 대부분 "증명 불가" 에서 나온다는 점을 설명할 수 있다
• 데이터룸에 제출할 QA 산출물 목록을 만들고 현재 준비 상태를 점검할 수 있다
• 상장 준비 구간에서 늘어나는 증적 요구(변경관리·권한 분리·접근 기록)를 설명할 수 있다
• 기술특례상장의 기술평가 요건이 최근 어떻게 바뀌었는지 개략적으로 안다
• M&A 통합(PMI)에서 마이그레이션 검증이 왜 핵심 과제인지 설명할 수 있다
• 자료 요청 목록(RFI) 항목에 기간·표본이 붙는 이유와 그 함의를 설명할 수 있다
• 실사 통보 후 소급 생성이 가능한 항목과 불가능한 항목을 구분해 열거할 수 있다
• 자동화 커버리지 같은 지표의 분모·분자 정의를 적어 두고 방어할 수 있다
• 제출 숫자와 원본 도구의 숫자가 일치하는지 확인하는 절차를 갖고 있다
• 실사 인터뷰에서 같은 질문이 여러 사람에게 간다는 점을 알고 답을 맞출 준비가 되어 있다
• 미해결 결함을 "수용된 리스크" 와 "방치" 로 갈라 설명할 수 있다
• 로그·기록 보관 기간이 실사 대응력에 직접 영향을 준다는 점을 설명할 수 있다
• 실사 4~8주 일정의 각 구간에서 QA가 할 일을 말할 수 있다
• PMI에서 QA에게 내려오는 다섯 가지 통합 과제를 열거할 수 있다

흔한 실수

실사 통보를 받고 나서 기록을 만들기 시작한다. 급조한 문서는 질의응답 두세 번이면 드러난다. 평소 운영 산출물이 곧 제출물이 되도록 설계하는 것이 유일한 대비다.

소급 불가 항목에 대응 시간을 쓴다. 24개월 결함 추이를 만들어내려고 2주를 쓰면, 그 2주에 만들 수 있었던 지표 정의서와 추출 쿼리까지 비어서 제출된다. 가능/불가를 먼저 가르는 일 이 대응의 첫 단계다.

미해결 결함을 축소해서 보고한다. 실사자는 숫자보다 숫자의 일관성 을 본다. 결함 추적 도구의 원본과 제출 자료가 다르면 그 순간부터 모든 자료가 검증 대상이 된다.

지표를 정의 없이 보고한다. "자동화 70%", "커버리지 80%" 는 분모가 없으면 숫자가 아니다. 정의 없는 높은 숫자는 검증되는 순간 낮은 숫자보다 더 나쁜 평가 를 받는다. 분모·기간·산출 방법을 함께 낸다.

보안 인증을 받으면 보안이 끝났다고 여긴다. 인증은 특정 시점의 체계를 증명할 뿐이다. 실사는 인증 이후의 실제 운영 기록 을 함께 본다.

로그 보관 기간을 인프라 비용으로만 본다. 보관 기간을 90일로 깎는 결정은 비용 절감이지만, 동시에 2년 뒤 답할 수 없는 질문을 만드는 결정 이다. 깎을 때 실사·감사 요구 기간을 같이 계산한다.

"그건 개발팀 소관" 으로 답한다. 실사에서는 조직도가 아니라 질문의 답이 필요하다. QA가 가진 기록으로 답할 수 있는 부분을 미리 정리해 두면 회사 전체의 대응 속도가 달라진다.

인터뷰 답을 조직 안에서 맞춰 보지 않는다. 같은 질문이 CTO·개발리드·QA리드에게 따로 간다. "릴리즈 승인은 누가 하나" 에 세 사람이 다르게 답하면, 그 불일치가 통제 미비로 적힌다. 사전에 사실을 맞추는 것 이지 말을 맞추는 것이 아니다.

실사자를 설득할 상대로 본다. 실사자는 심판이 아니라 리스크를 계량하는 사람이다. 확인되지 않은 영역은 나쁜 쪽으로 추정 되므로, 불리한 사실도 범위와 조치 계획을 붙여 먼저 내는 편이 결과가 좋다.

상장 준비를 프로세스 문서 작성으로만 이해한다. 문서와 실제 수행이 다르면 오히려 더 나쁜 결과가 된다. 지킬 수 있는 절차만 문서화한다.

딜이 끝나면 QA의 일도 끝난다고 본다. M&A는 클로징이 아니라 PMI에서 실제 품질 문제가 나온다. 계정·데이터·정산 통합과 지표 기준 통합이 그다음 1~2년의 과제다.

참고 자료

• Technical Due Diligence Checklist (2026): What Investors Actually Examine
• Technical Due Diligence for Startups: The Checklist (Sphere Inc.)
• 기술 실사 (Technology Due Diligence) — 쿠키딜
• IT 실사 (ITDD) — 쿠키딜
• 기업실사 체크리스트 양식 — 쿼타북
• 2026 코스닥 상장심사 이해와 실무 (한국거래소 KIND, PDF)
• 기술특례상장 평가 — 기술보증기금
• 2026 기술특례상장, 기술력만으로는 부족합니다 (파인패트)

이 커리큘럼 안에서

• 모듈 27 레슨 1 — 투자 라운드 지도. 증명 대상이 "관리 가능성" 으로 옮겨가는 지점이 여기다
• 모듈 27 레슨 3 — 시리즈 A. 지표 데이터 정합성. 그 지표가 실사에서 다시 검증된다
• 모듈 27 레슨 4 — 시리즈 B. 개인기를 시스템으로 바꾸는 일이 곧 실사 대비였다
• 모듈 27 레슨 6 — 국내 생태계. 투자계약 용어와 선행 조건·에스크로의 맥락
• 모듈 27 레슨 7 — 런웨이와 QA 예산. 실사 준비 구간이 제안의 창이 되는 이유
• 모듈 4 레슨 6 — 마이그레이션·전환 검증. PMI에서 회사 규모로 수행되는 바로 그 일
• 모듈 6 레슨 1 — 결함 생명주기. "수용된 리스크" 분류의 출발점
• 모듈 6 레슨 5 — 품질 지표. 분모를 정의하는 법. 이 레슨 사례의 핵심
• 모듈 7 레슨 6 — 프로세스 개선 모델. 성숙도를 외부에 증명하는 틀
• 모듈 8 레슨 1·6 — ISO 29119 산출물. 형식을 나중에 맞추는 비용이 몇 배인 이유
• 모듈 22 — 결함·테스트 관리 도구 실전. 소급 불가 기록이 실제로 쌓이는 곳
• 모듈 23 — 보안 테스트 도구. 스캔 결과와 조치 증빙 을 함께 남기는 법
• 모듈 25 — 품질·안전 표준 지도. 어떤 인증이 어느 시장에서 요구되는가
• 모듈 26 레슨 3·7 — CFO·경영진 보고. 리스크를 금액과 조건의 언어로 번역하기

한 줄 정리 — 실사는 설명이 아니라 기록을 열어보는 자리 이고, 요청받는 것은 문서가 아니라 과거의 시간 이다. 그래서 대응은 "가능/불가를 가르는 일" 에서 시작하고, 불가 항목은 평시의 기록으로만 채워진다. 지표는 분모와 산출 기준을 함께 낼 때만 자산이 되며, 정의 없는 높은 숫자는 검증되는 순간 낮은 숫자보다 나쁘다. 낮은 숫자를 그대로 내고 추세와 통제를 함께 보여주는 쪽이 언제나 유리하다.