외주 개발 중단·연락두절 시 소스코드 인수인계 기술 실사(Technical Due Diligence) 5대 체크리스트

[아키텍처 노트 안내]
본 문서는 제이앤코어 오픈 기술 Q&A 35번 문의(구축 및 운영 중이던 바코드·업무 시스템 개발 담당자와의 연락 두절 상황에서 타 개발사를 통한 소스코드 인수 및 유지보수 가능 여부)를 바탕으로, 중단된 프로젝트를 인계받을 때 수행하는 소프트웨어 자산 실사(Technical Due Diligence) 절차를 체계화한 가이드입니다.

1. “소스코드 압축파일은 받았는데, 이어서 개발할 수 있나요?”

외주 개발 프리랜서나 에이전시와 연락이 두절된 고객사가 가장 먼저 던지는 질문은 **“기존에 받은 소스코드 파일이 있는데, 이걸 이어받아 수정해 줄 수 있느냐”**는 것입니다.

안타깝게도 *“압축파일(source_final.zip) 하나를 보유하고 있다”*는 사실만으로는 인계 가능 여부를 판단할 수 없습니다. 공유 폴더 안에 최종, 최종수정, 진짜최종_백업 폴더가 뒤섞여 있고, 정작 현장에서 직원들이 접속해 쓰고 있는 실운영 서버에는 그중 어느 폴더에도 없는 코드가 돌아가고 있는 경우가 비일비재하기 때문입니다.

새로운 개발사를 급히 찾아 재계약을 맺기 전에, 먼저 현재 우리 회사가 확보하고 있는 기술 자산이 실제로 ‘작동 가능한 전체 세트’인지 점검하는 기술 실사가 선행되어야 합니다.

2. 소스코드 인수인계 5대 핵심 자산 점검표 (Handover Asset Matrix)

웹이나 사내 업무 시스템이 정상적으로 작동하고 수정·배포되기 위해서는 아래의 5가지 구성 요소가 하나의 퍼즐처럼 맞물려야 합니다. 제이앤코어 기술연구소는 인수 검토 시 각 항목을 단순 '보유/미보유'가 아니라 **자료 확보 → 범위 확인 → 독립 실행 검증**의 3단계로 실사합니다.

실사 영역	핵심 확인 항목 (Audit Checklist)	흔히 발생하는 누락 함정 (Common Pitfalls)
① 소스코드 (Source Code)	Git 저장소 이력 또는 압축본의 최종 수정일, 프론트엔드·백엔드·배치 스크립트 전체 포함 여부	화면(UI) 코드만 들어있고 핵심 계산을 수행하는 백엔드 API 서버 코드나 DB 프로시저가 통째로 빠진 경우
② 빌드·실행 환경 (Build & Env)	언어·프레임워크 버전, 패키지 설정 파일, 환경변수(`.env`) 및 외부 API 암호키	코드는 있으나 암호화 키·외부 연동 시크릿(`.env`)이 제외되어 로컬에서 서버 기동 자체가 불가능한 경우
③ 데이터 자산 (Database)	운영 DB 접속 권한(Root/Admin), 테이블 스키마 정의서(DDL), 백업 덤프 파일	애플리케이션 코드는 넘겨받았으나 실제 데이터가 담긴 클라우드 DB의 마스터 비밀번호를 모르는 경우
④ 운영 인프라 계정 (Infra & Auth)	클라우드/호스팅 서버 루트 계정, 도메인(DNS) 관리 계정, SSL 인증서, 알림톡·결제·바코드 장비 연동 계정	서버나 도메인이 개발자 개인 명의로 가입되어 있어 비용 결제 중단 시 서비스가 즉시 정지되는 경우
⑤ 버전 정합성 (Baseline Match)	현재 실무자가 접속 중인 운영 화면과 전달받은 소스코드의 일치 여부	전달받은 소스코드는 6개월 전 중간 작업본이고, 최근 6개월간의 패치는 운영 서버 안에만 존재하는 경우

3. 항목별 상세 검증 프로토콜

① 소스코드: 폴더 이름보다 ‘최종 변경 시점’과 ‘계층 구조’를 봅니다

최신 웹 시스템은 단일 폴더로 구성되지 않는 경우가 많습니다. 사용자 화면(Frontend), 데이터 처리 서버(Backend API), 그리고 야간 정산이나 알림을 돌리는 스케줄러(Batch Worker)가 분리되어 있다면 세 가지 코드가 모두 있어야 온전한 수정이 가능합니다. 또한 현장에서 마지막으로 기능이 수정된 날짜(예: 2026년 8월)보다 전달받은 코드의 파일 수정일이 이전(예: 2026년 3월)이라면 최신본이 누락된 상태입니다.

② 실행 환경: `.env` 파일 한 장이 없으면 수만 줄의 코드가 멈춥니다

보안상 Git 저장소에는 데이터베이스 접속 주소, JWT 인증 비밀키, 외부 서비스 연동 키를 기록한 환경설정 파일(.env 등)을 올리지 않는 것이 원칙입니다. 문제는 인수인계 시 개발자가 이 환경설정 값들을 별도로 전달하지 않고 연락이 끊기는 경우입니다. 운영 서버에 SSH(터미널) 접속 권한이라도 살아있다면 서버 내부에서 설정값을 추출해 복구할 수 있으므로, 운영 서버 접속 키(PEM 키 또는 비밀번호) 확보가 최우선입니다.

③ 데이터베이스: 코드는 다시 짜도 데이터는 다시 만들 수 없습니다

가장 치명적인 시나리오는 소스코드가 없는 것이 아니라 운영 데이터베이스(DB) 접근 권한을 상실하는 것입니다. 설령 소스코드를 100% 폐기하고 새로 개발하더라도, 그동안 쌓인 거래처 마스터, 바코드 입출고 이력, 정산 데이터를 덤프(Dump)로 추출할 수 있다면 업무 연속성은 유지됩니다. 따라서 연락 두절 징후가 보일 때 가장 먼저 확보해야 할 것은 DB 백업본과 접속 계정입니다.

④ 운영 계정 소유권: 누구의 카드로 서버비가 결제되고 있는가?

서버 호스팅, 도메인(DNS), 카카오 알림톡, 문자 발송 서비스가 외주 개발사나 프리랜서 개인 계정으로 등록되어 있다면 시한폭탄과 같습니다. 당장 화면이 잘 열린다고 안심할 수 없으며, 계정 명의 이관이나 자사 명의의 신규 인프라로 마이그레이션(이사)하는 계획을 즉시 세워야 합니다.

⑤ 마지막 동작 버전 대조 (Clean-Room Reproduction Test)

위 자료들을 모았다면, 기존 운영 서버를 건드리지 않고 독립된 격리 테스트 환경(Clean-Room)에서 전달받은 코드만으로 똑같은 화면이 빌드되고 실행되는지 검증합니다. 이 테스트를 통과해야만 비로소 *“코드를 성공적으로 인수받았다”*고 말할 수 있습니다.

4. 실사 결과에 따른 현실적 의사결정: ‘유지보수 이관’ vs ‘코어 재구축’

기술 실사를 마치면 막연한 불안감 대신 데이터에 기반한 두 가지 선택지가 도출됩니다.

[인수 실사 결과에 따른 의사결정 분기]
 ├── Case 1. [5대 자산 확보 및 격리 실행 성공]
 │     └─> 기존 아키텍처 유지 + 배포 파이프라인 복구 후 기능 수정/유지보수 진행
 │
 └── Case 2. [최신 소스 유실 / 스파게티 코드로 수정 시 연쇄 오류 발생 / 진행률 50% 미만 중단]
       └─> 억지 수선 중단 → 기존 DB 데이터와 화면 업무 흐름만 추출하여 2~4주 스프린트로 깔끔하게 재구축

현장에서 실제로 많이 겪는 함정은 진행률 60~70% 상태에서 멈춘 불완전한 타인의 코드를 살려보겠다고 수개월간 분석 비용만 태우는 것입니다. 남이 짜다 만 복잡한 코드를 해독하고 숨은 버그를 잡는 비용이, 검증된 아키텍처 위에서 핵심 업무만 2~4주 만에 새로 구축하는 비용보다 더 크게 나오는 경우가 많기 때문입니다.

💡 중단된 외주 프로젝트 및 레거시 시스템 인수 진단 상담

개발 담당자와 연락이 끊겨 현재 돌아가는 시스템에 작은 기능 하나도 추가하지 못하고 계십니까?
넘겨받은 소스코드 폴더가 실제로 쓸 수 있는 상태인지, 아니면 데이터만 살려 새로 만드는 것이 나은지 객관적인 엔지니어링 판단이 필요하십니까?

현재 보유하고 계신 파일 목록(폴더 구조 캡처)과 접속 중인 화면 정보만 알려주시면, 제이앤코어 기술연구소가 무엇을 살릴 수 있고 어떤 순서로 복구해야 하는지 명확히 짚어드립니다.