외주로 만든 서비스를 넘겨받고 한 달쯤 지나면, 의외로 자주 듣는 말이 있어요. "기능은 다 되는데, 뭐 하나 고치면 다른 데가 터져요." 코드는 인계받았는데 테스트가 없어서 손을 못 대는 상황이죠. 2026년엔 이 문제가 더 심해졌어요. AI 코딩으로 PR이 2~3배 쏟아지는데, 그걸 받쳐줄 테스트·회귀 스위트가 빈약하면 인계 직후부터 품질이 무너집니다.
포텐랩이 인수인계받은 30곳 넘는 프로젝트에서, 인계 사고의 단골 1순위가 "백업이 없었다"라면 2순위는 단연 "테스트가 없어서 아무도 못 고친다"였어요. 계약서가 '개발 완료'만 정의하고 '품질을 검증·유지할 수 있는 상태로 인계'는 빠뜨린 탓이 큽니다. 그래서 오늘은 QA·테스트 자동화 인계를 위해 계약에 못 박아야 할 8가지를 정리했어요.
테스트가 없는 코드는 "지금은 되는 것처럼 보이는" 코드예요. 인계 후 첫 수정, 첫 의존성 업데이트, 첫 마이그레이션에서 숨어 있던 결함이 터지는데, 그때 회귀 테스트가 없으면 원인을 찾는 데만 며칠이 걸려요. 2026년 한국 스타트업이 AI 코딩으로 속도를 30~50% 끌어올리는 만큼, 그 속도를 안전하게 만드는 건 결국 테스트 스위트예요. 테스트는 비용이 아니라 인계 후 수정 가능성 그 자체입니다.
"테스트 작성"이 아니라 핵심 도메인 라인 커버리지 70% 이상, 결제·인증·정산 등 크리티컬 경로 90% 이상처럼 숫자로 박으세요. 측정 도구(Jest/Vitest/pytest-cov 등)와 리포트 산출물도 함께요.
유닛 70 / 통합 20 / E2E 10 같은 비율을 정해 두세요. E2E(Playwright/Cypress)만 잔뜩 있고 유닛이 없으면 느리고 깨지기 쉬워요. 반대로 유닛만 있으면 실제 사용자 흐름을 못 잡고요.
main 머지 전 테스트 통과를 CI 필수 게이트로 두고, 발견된 버그는 "재현 테스트 1건 추가 후 수정"을 PR 규칙으로 만드세요. 이게 있으면 인계 후에도 회귀가 자동으로 쌓입니다.
AI가 만든 PR엔 ai-generated 라벨과 함께 테스트를 더 빡빡하게 거세요. 그럴듯하지만 틀린 코드, 가짜 라이브러리, 엣지 케이스 누락이 여기서 자주 걸립니다.
테스트가 의존하는 시드 데이터, 픽스처, 외부 API 목 서버까지 인계 대상이에요. 이게 빠지면 "로컬에선 통과하는데 우리 환경에선 안 도는" 테스트가 됩니다.
가끔 깨지는 테스트는 신뢰를 무너뜨려요. 플레이키 비율 2% 이하, 격리/수정 SOP, 재시도 정책을 합의하세요. "그냥 재시도하면 됨"으로 넘어간 테스트는 사실상 없는 테스트예요.
로그인, 결제, 핵심 전환 흐름 등 E2E 시나리오 12~30개를 문서로 인계받으세요. 여기에 axe-core 접근성 점검, p95 응답시간 같은 비기능 기준을 묶으면 품질 게이트가 입체적으로 됩니다.
커버리지 리포트·테스트 피라미드·CI 설정·회귀 규칙·테스트 데이터/픽스처·목 서버·E2E 시나리오 문서·플레이키 SOP·접근성/성능 기준·로컬+CI 실행 README·30일 hot-patch SLA·테스트 작성 가이드. 이 12개를 잔금 조건으로 묶으면 인계 품질이 확 올라갑니다.
정리하면, 좋은 인계는 "기능이 동작하는 코드"가 아니라 "고쳐도 안전한 코드"를 넘기는 것이에요. 그 차이를 만드는 게 테스트 스위트입니다. 포텐랩은 30곳 넘는 프로젝트를 인수인계하며 이 12자산을 잔금 조건 표준으로 묶어 왔고, 97% 수행완수율과 Notion 기반 투명한 소통으로 인계 후 품질 분쟁을 거의 0에 가깝게 줄여 왔어요.
지금 외주를 맡기려 하거나, 이미 받은 코드에 테스트가 없어 손대기 무섭다면 포텐랩에 상담을 남겨 주세요. 인계 품질 점검부터 같이 시작할게요. 실제 사례는 포텐랩 포트폴리오에서 확인하실 수 있어요.