기존 개발사가 만든 시스템, 이어받으려면 무엇이 손에 있어야 하는가

개발사와 연락이 어려워졌거나, 만든 사람이 회사를 떠났거나, 맡기는 곳을 바꾸기로 하셨을 때 가장 먼저 나오는 질문은 대개 하나입니다. 이걸 다른 팀이 이어받을 수 있나요.

이 질문에는 시스템을 직접 확인하기 전에는 답할 수 없습니다. 다만 그 답을 내기 위해 무엇을 확보해야 하는지는 미리 정리할 수 있고, 그 목록은 기술을 몰라도 확인하실 수 있습니다. 확인 항목은 여섯 가지이고, 항목마다 진행이 어려운 상태와 그때 먼저 할 일을 함께 정리했습니다.

이 글은 기존 개발사의 작업을 평가하지 않습니다. 어느 쪽이 잘했는가가 아니라 지금 무엇이 남아 있는가만 봅니다.

다루는 범위를 먼저 구분합니다. 클라우드 계정 자체를 넘겨받는 절차 — 계정 명의와 소유 구조, 권한 회수, 비용과 결제, 모니터링과 알림의 이관 — 는 AWS 운영을 넘겨받기 전, 무엇을 확인해야 하는가에서 다룹니다. 이 글은 그 위에서 운영되는 소프트웨어 자체를 다룹니다. 코드가 어디에 있는지, 수정할 수 있는지, 수정한 내용이 실제 서비스에 반영되는지입니다.

소스코드 접근 — 나머지 항목의 전제 조건

여섯 가지는 같은 무게의 항목이 아닙니다. 그중 하나가 나머지 전부보다 중요합니다. 소스코드 접근입니다.

이 항목이 비어 있으면 나머지 다섯 항목이 모두 갖춰져 있어도 이어받는 일 자체가 성립하지 않습니다. 서버에 접속할 수 있고, 데이터를 꺼낼 수 있고, 배포 절차가 기록으로 남아 있고, 명의도 전부 회사 것이고, 문서까지 최신으로 관리되고 있다고 해 봅시다. 그래도 수정할 대상 자체가 없습니다. 유지와 개선은 코드를 바꾸는 일이라, 코드가 없으면 그 일을 정의할 수가 없습니다.

그래서 확인의 순서가 여기서 정해집니다. 다른 다섯 가지는 비어 있으면 시간이 더 드는 문제이지만, 이 하나는 비어 있으면 경로가 달라지는 문제입니다. 소스가 없다면 이어받기는 어렵고, 그때는 운영 중인 환경과 데이터가 남아 있는지를 보고 거기서부터 확인할 수 있는 것을 찾는 쪽으로 방향이 바뀝니다.

이 순서가 바뀌면 불필요한 작업이 생깁니다. 문서를 먼저 요청하고, 계정 명의를 먼저 정리하고, 그러고 나서 소스가 없다는 사실을 알게 되는 경우입니다. 앞의 두 가지도 언젠가는 해야 할 일이지만, 가능 여부를 판단하는 항목을 먼저 확인하는 편이 시간을 줄입니다.

확인 항목 여섯 가지

여섯 항목은 중요도 순으로 정리했습니다. 앞쪽 항목이 비어 있을수록 뒤쪽 항목이 갖춰져 있어도 진행이 어렵습니다.

계정 명의와 기록·문서는 성격이 다릅니다. 이 둘이 비어 있으면 시간과 작업량이 늘어나지만 인계가 불가능해지지는 않습니다. 소스코드·실행 환경·데이터·배포 경로 네 항목은 비어 있는 정도에 따라 할 수 있는 일의 범위 자체가 달라집니다.

소스코드 접근 — 「갖고 있다」의 기준

소스를 갖고 있다는 말에는 단계가 있습니다. 없거나 모르는 상태, 일부만 있는 상태, 전부 갖고 있는 상태, 그리고 변경 이력까지 있는 상태가 각각 다릅니다.

일부만 있는 경우가 가장 흔한 문제입니다

받은 파일이 있어도 그것이 현재 운영 중인 프로그램의 전부가 아닌 경우가 있습니다. 화면 쪽 코드는 있는데 서버 측 처리 부분이 빠져 있거나, 코드는 있는데 실행에 필요한 설정값이 함께 전달되지 않은 형태입니다. 설정값이 없으면 코드가 있어도 실행할 수 없습니다.

확인하는 방법은 하나뿐입니다. 받은 소스로 실제로 한 번 실행해 보는 것입니다. 목록으로 대조하는 것보다 이쪽이 확실합니다. 지금 서비스와 화면이 같은지까지 보면 받은 것이 현행인지도 함께 확인됩니다. 이 시험은 실제 서비스와 분리된 환경에서 하시는 편이 안전합니다.

변경 이력이 함께 오면 달라지는 것

변경 이력은 언제 무엇이 왜 바뀌었는지가 순서대로 남은 기록입니다. 흔히 쓰이는 형식이 Git이고, 변경 이력이 함께 전달되면 이어받는 쪽에 두 가지 이점이 있습니다.

하나는 최근에 변경된 부분을 파악할 수 있다는 점입니다. 최근 변경된 부분은 대개 아직 안정화되지 않았으므로, 인수 후 첫 수정 때 우선 검토할 대상이 됩니다. 다른 하나는 복원할 수 있다는 것입니다. 이력이 있으면 수정 후 문제가 생겼을 때 이전 상태로 되돌릴 수 있습니다. 이력 없이 파일만 받으면 이 변경 통제가 없어서, 초반의 작은 수정 하나하나가 신중해집니다.

이력이 없어도 이어받을 수는 있습니다. 다만 이 두 가지를 대신할 방법을 따로 만들어야 하므로 초반 속도가 달라집니다.

실행 환경 접근 — 업체를 거쳐야만 접근할 수 있는가

코드가 있어도 그것이 어디에서 어떤 설정으로 실행되고 있는지는 환경을 확인해야 파악됩니다. 같은 코드도 환경 설정에 따라 다르게 동작하기 때문입니다.

여기서도 단계가 나뉩니다. 접속 자체가 안 되는 상태, 요청하면 업체를 통해서 되는 상태, 계정을 직접 갖고 있는 상태, 그리고 명의와 결제까지 회사 것인 상태입니다.

가운데 두 단계 사이의 차이가 큽니다. 업체를 거쳐야만 접근할 수 있는 환경은 인계 시점에 작업이 중단됩니다. 평소에는 요청하면 처리되니 불편이 드러나지 않다가, 운영 주체를 바꾸는 시점에 모든 요청이 그 경로 하나에 의존하게 됩니다. 그래서 전환을 검토하기 시작했다면 직접 접근할 수 있는 경로를 먼저 확보합니다.

이 항목은 AWS를 전제하지 않습니다. 사내 서버실이든 다른 호스팅이든 임대한 서버든 질문은 같습니다. 지금 그것이 어디에서 운영되고 있고, 회사가 직접 접근할 수 있는가입니다. 클라우드 계정 자체의 명의와 권한 구조를 정리하는 절차는 성격이 조금 다르고, AWS 운영을 넘겨받기 전 확인할 항목에 계정 층위로 따로 정리해 두었습니다.

데이터 확보 — 꺼낼 수 있는가, 되돌릴 수 있는가

데이터는 코드보다 대체가 어렵습니다. 코드는 최악의 경우 다시 만들 수 있지만 그동안 축적된 거래 기록과 고객 정보는 다시 만들 수 없습니다.

여기서도 단계가 나뉩니다. 어떻게 되어 있는지 모르는 상태, 화면으로만 볼 수 있는 상태, 백업을 받을 수 있는 상태, 그리고 정기 백업이 실행되고 복구까지 확인해 본 상태입니다.

가장 흔히 놓치는 것이 마지막 단계입니다. 백업이 실행되는 것과 복구되는 것은 다릅니다. 백업 파일이 매일 생성되고 있어도 실제로 복구해 본 적이 없다면, 장애가 났을 때가 첫 시험이 됩니다. 이어받는 시점은 장애 대응 중이 아니므로 이 시험을 해 두기에 적당합니다.

형식도 함께 확인하셔야 합니다. 자료를 받았는데 사람이 열어 볼 수는 있지만 다른 시스템에 넣을 수는 없는 형태라면, 받은 자료를 활용할 수 없습니다. 실제로 한 번 꺼내서 열어 보는 것이 가장 확실한 확인 방법입니다.

한 가지 더 있습니다. 데이터에 고객이나 임직원의 개인정보가 들어 있다면, 그것을 다루는 주체가 바뀌는 일은 개인정보 보호법이 정한 업무 위탁의 문제와 맞물립니다. 이 법은 위탁을 문서로 하도록 하고, 누구에게 맡겼는지 공개하도록 하며, 맡긴 쪽이 받은 쪽을 교육하고 감독하도록 정하고 있습니다. 맡긴다고 해서 책임까지 넘어가지는 않는다는 뜻이고, 이어받는 쪽이 바뀔 때는 이 서류도 함께 갱신되어야 합니다.

배포 경로 — 수정 사항을 서비스에 반영하는 절차

소스가 있고 환경에도 접근할 수 있는데 진행이 어려워지는 지점이 배포 경로입니다. 수정한 내용을 실제 서비스에 반영하는 방법이 남아 있지 않으면, 수정할 수 있다는 것이 실질적인 의미를 갖지 못합니다.

단계는 이렇게 나뉩니다. 방법을 아무도 모르는 상태, 특정 담당자만 아는 상태, 절차가 기록으로 남아 있는 상태, 그리고 정해진 조작으로 자동 반영되는 상태입니다.

문제는 두 번째 단계입니다. 특정 담당자만 아는 절차는 그 담당자가 이동하거나 퇴사하는 순간 사라집니다. 그리고 사라졌다는 사실은 다음 수정이 필요해질 때까지 드러나지 않습니다. 그래서 이 항목의 먼저 할 일은 절차를 사람이 아니라 기록에 남기는 것입니다.

확인하는 방법은 데이터와 같습니다. 아주 작은 변경 하나를 실제로 반영해 보는 것입니다. 화면 문구 한 줄 정도면 충분합니다. 이 반영이 성공하면 소스·환경·배포 세 가지가 실제로 연결되어 있다는 뜻이고, 실패하면 어느 구간이 끊겨 있는지도 함께 드러납니다.

계정 명의 — 그리고 소유는 하나가 아니라 넷입니다

도메인, 인증서, 결제와 알림 같은 외부 서비스 계정이 회사 명의인지를 보는 항목입니다. 코드와 환경이 모두 정리돼 있어도 도메인이 외부 명의로 남아 있으면, 갱신 시점에 서비스 전체가 영향을 받습니다.

계정 명의를 확인하다 보면 함께 나오는 질문이 하나 더 있습니다. 그래서 이 시스템은 누구 것인가입니다.

소유는 네 가지로 나뉩니다

계약을 맺기 전이라면 이 넷을 계약서에 넣을 항목으로 다루게 되고, 그 관점은 AI 개발 업체를 선정할 때 확인해야 할 10가지에 정리돼 있습니다. 이미 만들어진 시스템을 이어받는 시점에는 질문의 방향이 반대입니다. 넣을 수 있는가가 아니라, 지금 문서에 무엇이라 적혀 있는가, 그리고 적혀 있지 않다면 무엇이 기본값인가를 확인하는 일이 됩니다.

• 소스 코드의 저작권 — 코드는 저작물이라 「비용을 냈으니 당연히 우리 것」이 자동으로 성립하지는 않습니다. 계약서에 어떻게 적혀 있는지가 먼저입니다.
• 계약 종료 후 제3자가 이어받아 수정할 권리 — 이어받기와 가장 직접적으로 관련되는 항목이라, 「넘겨받았다」와 「고쳐도 된다」의 차이로 따로 다룹니다.
• 환경과 계정의 명의 — 서버, 도메인, 인증서, 외부 서비스 계정이 각각 누구 이름으로 되어 있는지입니다.
• 넘겨받는 산출물의 목록 — 무엇을 어떤 형식으로 받기로 되어 있는지가 문서에 있는지입니다.

네 가지는 서로 다른 문제인데 계약서에 한 문장으로 묶여 적히는 경우가 있습니다. 이 구분은 맞춤형 업무 시스템과 SaaS, 무엇을 선택해야 하는가에서도 같은 형태로 다뤘습니다.

「넘겨받았다」와 「고쳐도 된다」는 다른 문제입니다

저작권법 제45조 제2항은 저작재산권의 전부를 양도하는 경우 특약이 없으면 원저작물을 고쳐 새로 만들어 이용할 권리(2차적저작물작성권)는 넘어가지 않은 것으로 추정하되, 프로그램은 예외로 특약이 없으면 그 권리도 함께 양도된 것으로 추정합니다. 그래서 소프트웨어를 이어받을 때 먼저 확인할 것은 수정 조항의 유무보다 계약이 권리를 양도한 것인지 이용만 허락한 것인지, 그리고 전부인지 일부인지입니다. 이 추정은 저작재산권 전부를 양도받은 경우의 이야기이고, 이용 허락만 받았거나 일부만 양도받았다면 고칠 수 있는 범위는 그 계약이 정한 만큼입니다. 추정이므로 계약서에 다른 정함이 있으면 그 정함이 앞섭니다.

그리고 담당했던 개발자가 퇴사한 경우, 권리 관계로는 개인을 찾는 것이 순서가 아닙니다. 같은 법이 법인 등의 명의로 공표되는 업무상저작물의 저작자를 그 법인 등으로 정하고 있어, 계약에 다른 정함이 없다면 권리는 개인이 아니라 그 회사에 남기 때문입니다. 개인을 찾아야 하는 이유가 있다면 그것은 권리가 아니라 설명입니다.

여기까지는 조항 전체를 법률적으로 검토하는 일이 아니라, 필요한 항목이 문서에 있는지 없는지만 보는 일입니다. 그 정도는 기술이나 법률 지식 없이도 확인하실 수 있습니다. 금액이 크거나 개인정보가 포함된 계약이라면, 빠진 항목을 먼저 추린 뒤에 외부 자문을 받으시는 편이 비용과 시간 모두 절약됩니다.

기록·문서 — 없어도 됩니다. 다만 시간이 듭니다

여섯 가지 중 가장 자주 비어 있는 칸이면서, 비어 있어도 길이 끊기지는 않는 칸입니다.

단계는 이렇습니다. 아무것도 없는 상태, 단편적인 메모 정도가 있는 상태, 주요 부분은 문서가 있는 상태, 그리고 문서가 현행으로 관리되는 상태입니다. 마지막 단계에서 중요한 것은 문서의 존재가 아니라 최신 여부입니다. 실제와 어긋난 문서는 없는 것보다 나쁠 때가 있습니다. 그래서 문서를 받으시면 지금 동작과 대조해 보는 절차가 한 번은 필요합니다.

문서가 하나도 없어도 이어받을 수 있습니다. 남아 있는 코드와 설정에서 구조를 읽어 정리하는 방식으로 접근하고, 그 정리 결과를 문서로 남기는 것이 초반 작업의 일부가 됩니다.

다만 이 방식으로 복원되지 않는 것이 하나 있습니다. 왜 그렇게 만들었는가라는 의도입니다. 특정 거래처에만 적용되는 분기, 설명 없이 코드에 고정된 값, 겉보기에 불필요해 보이는 처리 같은 것들은 무엇을 하는지는 읽히지만 왜 있는지는 읽히지 않습니다. 그리고 이런 부분은 대개 임의로 삭제하면 안 되는 부분입니다. 그래서 문서가 없는 환경에서는 수정해도 되는 부분과 변경하면 안 되는 부분을 구분하는 작업이 초반의 상당 부분을 차지합니다.

비어 있는 칸이 많을 때 — 무엇부터

여섯 칸 중 여러 개가 비어 있는 상태에서 시작하는 경우도 있습니다. 그때 먼저 정리해 둘 것이 하나 있습니다.

비어 있는 칸이 많다는 것은 먼저 확보할 것이 있다는 뜻이지, 새로 만들어야 한다는 뜻이 아닙니다. 이 둘은 자주 혼동되지만 같은 말이 아닙니다. 확보는 요청과 확인으로 채워지는 일이고, 운영 중인 시스템은 그동안에도 계속 운영됩니다.

채우는 순서는 표의 순서를 그대로 따르시면 됩니다.

1. 소스코드 — 현재 운영 중인 프로그램의 소스와 변경 이력을 확보합니다. 이 항목에서 진행 방향이 정해집니다.
2. 실행 환경 — 직접 접근할 수 있는 경로를 확보합니다. 코드가 어떤 설정으로 실행되는지는 실행 환경에서만 파악됩니다.
3. 데이터 — 꺼낼 수 있는지 확인하고, 복구할 수 있는지까지 한 번 시험합니다.
4. 배포 경로 — 아주 작은 변경 하나를 실제로 반영해 봅니다. 앞의 세 항목이 연결되어 있는지가 이 한 번으로 확인됩니다.
5. 계정 명의 — 도메인·인증서·외부 서비스의 명의와 결제 주체를 회사로 정리합니다.
6. 기록·문서 — 확인하면서 정리한 것을 그대로 문서로 남깁니다.

첫 칸이 아예 비어 있다면, 즉 소스가 없거나 어디 있는지 모른다면 순서가 달라집니다. 그때는 남아 있는 환경과 데이터에서 확인할 수 있는 것을 먼저 모으고, 그 목록을 놓고 무엇이 가능한지를 다시 봅니다. 가능 여부를 미리 단정하지 않고 확인한 뒤에 답하는 것이 이 판단에서 지켜야 할 순서입니다.

기존 개발사에 알리는 시점도 이 확인이 끝난 뒤에 정하는 편이 안전합니다. 무엇을 확보했는지 모르는 상태에서 먼저 통보하면, 정작 요청할 목록이 준비되지 않은 채로 이야기가 시작됩니다.

그리고 이 확인의 결론이 늘 한 방향인 것은 아닙니다. 유지가 적합하면 유지하고, 필요한 부분만 개선하며, 다른 판단이 더 합리적인 경우에는 그 이유부터 설명드립니다. 판단은 근거와 함께 말씀드리고, 결정은 고객사에서 내리십니다.

다음 단계

지금 여섯 칸 중 무엇이 차 있고 무엇이 비어 있는지부터 확인해 보고 싶으시면 이어받기 진단을 이용하실 수 있습니다. 여섯 가지 선택만으로 현재 상태와 먼저 확보할 것을 바로 보여드립니다. AWS를 쓰지 않으셔도 되고, 계정 권한도 연락처도 필요하지 않습니다.

이어받는 일을 실제로 어떻게 진행하는지는 소프트웨어 관리·개선에 적혀 있습니다. 지금 상황이 어느 쪽에 가까운지부터 정리하고 싶으시면 기존 시스템을 계속 잘 쓰고 싶습니다에서 상황별로 무엇부터 확인하면 되는지 정리해 두었습니다.

운영 중인 시스템에 무엇이 남아 있는지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오. 확인 결과 빌드업웍스가 맡는 것이 적절하지 않다면, 그 판단도 근거와 함께 말씀드립니다.

참고 자료

• 저작권법 (국가법령정보센터) — 업무상저작물의 저작자, 저작재산권 양도
• 개인정보 보호법 (국가법령정보센터) — 업무 위탁에 따른 개인정보의 처리 제한