넘겨받기 전 실사는 채점표가 아니라 받아야 할 것의 청구 목록으로 끝났다

넘겨받을 커머스 시스템의 실사는 인수가 공식으로 시작되기 석 달쯤 전에 있었다. 하루 저녁에 자료를 모으고 도구를 만들었고, 다음 날 현장에서 상대 쪽 기술 책임자를 인터뷰했다. 지금 인수 범위를 나눌 때 기준이 되는 목록이 그때 나왔으므로, 무엇을 준비했고 무엇이 남았는지 정리해 둔다.

Table of contents

배경 — 남의 시스템을 하루에 파악해야 하는 자리

실사에 쓸 수 있는 시간은 현장 하루였다. 그 안에 코드·인프라·운영 절차를 다 볼 수는 없으므로, 현장에 가기 전에 무엇을 묻고 무엇을 받아야 하는지를 먼저 정해야 했다.

미리 받은 자료는 다섯 건이었다. 석 달 치 결제 보고서 PDF 세 건, IT 기준 무형자산 정리 문서(docx), 그리고 API 와 데이터베이스 명세를 묶은 20MB ZIP 이다. ZIP 을 풀면 Client API·Cloud Functions·Database 세 갈래가 나오고, Database 명세는 대부분 화면 캡처 PNG 였다.

자료 수집에서 걸린 두 지점

자료는 팀 메신저 대화방에 첨부로 올라와 있었는데, 처음 검색은 헛돌았다. 회사 이름을 세 가지 표기로 넣어도 본문 매칭이 0건이었다. 메신저 API 의 list_messages 는 본문만 검색하고 첨부 파일명은 보지 않으며, 첨부는 본문이 (첨부파일) 로만 올라와 있었다. 결국 이름이 아니라 올라온 시각으로 범위를 잡아 받았다.

시각에도 함정이 있었다. 응답의 2026-04-28T15:26:51.000Z 는 끝에 Z 가 붙어 UTC 처럼 보이지만 실제로는 KST 였다. 그대로 UTC 로 읽고 변환하면 9시간이 어긋난다. ZIP 은 502 DOWNLOAD_FAILED 로 두 번 실패한 뒤 세 번째에 캐시에서 받았다. 앞선 시도가 뒤에서 이미 끝나 있었던 것이다.

실사 도구 — 청구 자료·판정표·인터뷰 순서

같은 날 저녁에 실사 도구 일습을 만들었다.

모두 Markdown 을 정본으로 두고 HTML 과 PDF 로 렌더했으며, 공통 CSS 하나로 모양을 맞췄다. 현장에서 종이로 넘기는 판과 나중에 grep 으로 찾는 판이 같은 원본에서 나와야 내용이 갈라지지 않는다.

코드는 GitHub 조직의 저장소 46개에 read 권한을 받아 자동으로 분석했다. 고객 웹은 Vue 2.7, iOS 는 Tuist, Android 는 Jetpack Compose, 백오피스는 PHP 였다. 공개된 노션 페이지도 함께 훑었다.

결과 — 채점표 대신 인계 청구 요청서

현장 인터뷰의 축은 넷이었다. GCP 이관, 암호화 키, 상품 등록의 수기 절차, 출고 처리다. 앞의 둘은 넘겨받는 순간 통제권이 걸린 것이고, 뒤의 둘은 넘겨받은 다음 날부터 사람이 손으로 돌려야 하는 것이다.

결과를 남기는 형식에는 후보가 둘이었다. 준비한 세 축 평가지를 채워 시스템을 점수로 판정하는 것, 그리고 무엇을 넘겨받아야 하는지를 항목으로 특정해 상대에게 청구하는 것이다. 실제로 나온 것은 뒤쪽이었다. 평가지는 채우지 않았고, 결과는 7쪽짜리 무형자산 인계 청구 요청서가 됐다.

청구서 쪽이 맞았다고 보는 이유는 인수 쪽에 필요한 것이 시스템의 점수가 아니라 받아야 할 목록이기 때문이다. 점수는 사고팔지를 판단하는 데 쓰이지만, 이미 넘겨받기로 한 쪽에는 빠뜨리면 운영이 멈추는 항목을 빠짐없이 적는 일이 더 급하다. 대가는 시스템의 상태를 축별로 비교할 수 있는 기록이 남지 않았다는 점이다. 청구 항목은 Tier 1 약 30, Tier 2 약 25, Tier 3 약 12 로 나눴고, 요청서는 인터뷰 자리에서 넘겼다. 닷새 뒤에 「대부분 확보했고 전달할 수 있다」는 회신이 왔다.

남은 의문 — 넘겨받기 전에 다시 볼 것

• 회신은 「대부분」이었다. 어느 항목이 빠졌는지는 실제로 넘겨받을 때 청구서와 한 줄씩 대조해야 드러난다
• 명세의 Database 갈래가 캡처 이미지라 검색이 되지 않는다. 실제 스키마와 맞는지는 원본을 열어야 안다
• 석 달 사이 시스템이 바뀌었을 수 있다. 5월에 특정한 값이 지금 콘솔 값과 같은지 다시 재야 한다

결과 — 실사가 남긴 청구 목록

• 인수 협상의 기준. 점수 대신 Tier 1 약 30·Tier 2 약 25·Tier 3 약 12 항목의 청구 목록이 남았고, 이후 인수 범위를 나눌 때 그 목록이 기준이 됐다
• 현장 하루의 배분. 인터뷰를 통제권 둘(GCP 이관·암호화 키)과 사람 손 운영 둘(상품 등록 수기 절차·출고 처리)로 나눠, 넘겨받는 날 멈출 수 있는 것부터 물었다
• 남긴 위험. 회신은 「대부분 확보」였다. 빠진 항목은 실제로 넘겨받을 때 청구서와 한 줄씩 대조해야 드러난다

정리

• 실사는 시간이 하루뿐이면 무엇을 받을지부터 정한다. 판정보다 청구 목록이 인수 뒤에 더 오래 쓰인다
• 실사 도구는 Markdown 하나를 정본으로 두고 렌더만 갈라야, 현장 종이와 나중의 검색이 같은 내용을 본다
• 남이 준 시각 값은 표기를 믿지 않는다. Z 가 붙어 있어도 실제 시간대를 먼저 확인한다
• 검색이 0건이면 대상이 없는 것이 아니라 검색이 그 필드를 보지 않는 것일 수 있다