대부분의 중소기업은 외주 개발자, 프리랜서, 에이전시를 고용해 무언가를 만듭니다 — 홈페이지, 사내 도구, 고객용 앱 등. 그리고 대부분 완성된 결과물에만 집중합니다. 이해는 되지만, 나중에 정말 중요해지는 것들을 놓치게 됩니다: 시스템에 수정이 필요할 때, 개발자와 연락이 끊겼을 때, 혹은 다른 사람에게 맡기고 싶어질 때요.
문제가 터지기 전에, 프로젝트를 시작하기 전이나 진행 중에 반드시 요청해야 할 것들을 정리했습니다.
1. 서면 사양서(요구사항 문서)
개발이 시작되기 전에, 무엇을 만드는지 — 기능, 사용자 흐름, "완료"의 기준 — 를 설명하는 문서가 있어야 합니다. 이게 없으면 실제로 무엇이 합의되었는지에 대한 공통 기준이 없어서, 범위에 대한 분쟁이 문서가 아니라 기억에 의존하게 됩니다.
2. 완성품이 아니라 전체 소스코드 접근 권한
컴파일된 애플리케이션이나 호스팅된 서비스 로그인이 아니라, 실제 소스코드 저장소(예: 고객사 소유이거나 협업자로 추가된 GitHub·GitLab repo)에 접근할 수 있어야 합니다. 개발자가 이걸 꺼린다면, 프로젝트를 더 진행하기 전에 이유를 물어보셔야 해요 — 중소기업이 한 벤더에 무기한 종속되는 가장 흔한 원인 중 하나입니다.
3. 데이터베이스 설계 문서
데이터베이스가 관련된 프로젝트라면, ERD(개체-관계 다이어그램)이나 최소한 테이블 목록·저장 데이터·테이블 간 관계에 대한 서면 설명을 받아두셔야 합니다. 이게 있어야 (아직 고용하지 않은 개발자를 포함해서) 누구든 데이터를 처음부터 역분석하지 않고도 이해할 수 있습니다.
4. 배포·인프라 접근 권한
호스팅 계정, 도메인 등록, 결제 처리사·이메일 서비스·클라우드 인프라 같은 제3자 서비스 계정의 소유자가 누구인지 확인하세요. 이런 것들은 계약자 개인 계정이 아니라 회사 명의로 등록되어 있어야 합니다 — 그렇지 않으면 분쟁 한 번으로 본인 시스템에 대한 접근권을 잃을 수 있습니다.
5. API가 있다면 API 문서
시스템이 다른 서비스와 통신하거나 모바일 앱·연동을 위한 엔드포인트를 제공한다면, 그 엔드포인트가 무엇을 하고 어떻게 인증되는지에 대한 문서를 받으세요. 문서화되지 않은 API는 나중에 역분석하는 데 가장 시간이 많이 드는 것 중 하나입니다.
6. 기본적인 운영 인수인계 문서
시스템이 어떻게 배포되는지, 어떤 의존성에 의존하는지, 어떤 정기 유지보수가 필요한지에 대한 짧은 서면 요약을 요청하세요. 거창할 필요 없습니다 — 한두 페이지만으로도 나중에 다른 개발자가 며칠씩 조사하는 시간을 아낄 수 있습니다.
이게 지금 당장은 별거 아닌 것처럼 보여도 중요한 이유
이 항목들이 완성품이 첫날 작동하는 방식을 바꾸지는 않습니다. 하지만 400일째 되는 날, 뭔가 고장 났는데 원래 개발자와 연락이 안 되고, 다른 누군가 — 어쩌면 저희 같은 — 가 고쳐야 할 때는 이야기가 달라집니다. 위 항목 하나하나가 "일주일 안에 고칠 수 있는 문제"와 "몇 주짜리 역분석 프로젝트"의 차이를 만듭니다.
실제로 이게 없으면 어떤 일이 벌어지는가
가정이 아닙니다. 저희가 나중에 투입됐을 때 반복적으로 보게 되는 패턴이에요. 시간이 지나면서 실제로 어떻게 흘러가는지 구체적으로 정리했습니다.
문서가 없는 경우
뭔가 처음 고장 났을 때, 이걸 들여다보는 사람은 고치기 시작하기도 전에 먼저 시스템을 역분석해야 합니다 — 코드를 한 줄씩 읽고, 의도를 추측하고, 뭐가 뭐에 의존하는지 아무도 모르니 조심스럽게 변경을 테스트해야 하죠. 문서가 있으면 1시간이면 될 수정이 문서가 없으면 며칠씩 걸리고, 청구서에도 그 차이가 그대로 반영됩니다. 시간이 지날수록 시스템을 담당하는 사람은 손대는 것 자체를 두려워하게 되고, 작은 버그들이 방치된 채 쌓이며 임시방편 위에 또 임시방편이 덧붙여집니다. 결국 시스템이 너무 불투명해져서 남은 현실적인 선택지가 전면 재구축뿐인 상황이 오는데 — 이게 바로 애초에 문서화가 막으려던 결과입니다.
소스코드 접근 권한도, 명확한 라이선스나 소유권도 없는 경우
이게 더 심각합니다. 코드도 없고, 소유권을 명시한 서면 계약도 없다면, 본인 소프트웨어인데도 오직 원래 개발자만 손댈 수 있는 상황이 됩니다 — 그리고 그 개발자는 그 사실을 알고 있습니다. 실제로는 이렇게 나타납니다:
- 앞으로의 모든 변경 작업이 "다른 선택지가 없는 고객"에게 매기는 가격으로 청구됩니다. 5분짜리 문구 수정이 갑자기 수백 달러가 될 수 있어요 — 경쟁 견적을 받을 방법 자체가 없으니까요.
- 개발자와 연락이 끊기면 — 이직하거나, 사업을 접거나, 이메일에 답이 없어지면 — 소프트웨어는 그 상태 그대로 멈춥니다. 의존하던 라이브러리에서 보안 취약점이 발견돼도 패치할 수 없습니다. 결제 처리사가 API를 바꿔서 결제가 깨져도 업데이트할 수 없습니다. 대상으로 하던 브라우저나 OS가 바뀌어도 조정할 수 없습니다. 통제할 수 없는 무언가가 망가뜨릴 때까지 있는 그대로 돌아가다가, 그다음엔 그냥 고장 난 채로 남습니다.
- 결국 다른 개발자로 바꾸려 해도, 새 개발자는 소스코드가 아니라 컴파일된 바이너리나 살아있는 웹사이트에서 시작해야 합니다. 그러면 보통 마이그레이션이나 수정이 아니라 전면 재구축 견적이 나옵니다 — 넘겨받을 게 없어서, 새 개발자가 손대기 전에 먼저 외부에서 본인 소프트웨어를 역분석해야 하니까요.
- 보안 사고가 터졌을 때, 아무도 소프트웨어가 실제로 무엇을 하는지 감사할 수 없습니다 — 원저작자 말고는 아무도 코드를 읽을 수 없으니까요. 하필 이걸 알게 되는 시점이 가장 나쁜 타이밍이죠.
- 투자 유치나 인수 과정에 들어가면, 기술 실사에서 이게 바로 드러납니다. 코드 소유권이 불명확하고, 문서도 없고, 무엇을 하는지 증명할 방법도 없는 소프트웨어는 딜이 지연되거나, 재협상되거나, 무산되는 흔한 (그리고 미리 막을 수 있었던) 이유입니다.
- 비용을 지불했더라도 소유권이 법적으로 불명확할 수 있습니다. "업무상 저작물(work made for hire)"이 모든 계약이나 관할권에서 자동으로 인정되는 건 아닙니다 — 서면으로 명시해두지 않으면, 몇 년이 지나도 본인이 비용을 지불해 만든 소프트웨어를 실제로 소유하고 있지 않을 수 있습니다.
이런 것들은 소프트웨어가 잘 돌아가고 모두가 만족하는 첫날에는 드러나지 않습니다. 빠르게 움직여야 하는 날 — 보안 패치가 필요하거나, 변경을 맡아야 할 신규 인력이 들어오거나, 투자자가 질문을 던지는 날 — 에 비로소 드러나고, 그제서야 할 수 없다는 걸 알게 됩니다.
지금 문서가 없거나, 코드 소유권이 불명확하거나, 더 이상 연락되지 않는 개발자가 있거나, 혹은 본인이 정확히 무엇을 갖고 있는지조차 잘 모르겠다면 — 문의해주세요. 정확히 무엇이 빠져있는지, 현실적인 선택지가 무엇인지 함께 파악해드리고, 기존 시스템의 문서를 재구성하는 게 나을지 새로 시작하는 게 나을지도 판단해드립니다. 새 계약서에 서명하기 전이라면, 서명 전에 검토도 도와드릴 수 있습니다.