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

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

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

먼저 밝혀 둘 것이 있습니다. 이 글은 앞서 만든 곳을 평가하는 글이 아닙니다. 저희도 고객에게는 외주이고, 같은 질문을 저희가 만든 시스템에 대해서도 받습니다. 그래서 여기서는 어느 쪽이 잘했는가가 아니라 지금 무엇이 남아 있는가만 봅니다.

범위도 갈라 두겠습니다. 클라우드 계정 자체를 넘겨받는 절차 — 계정 명의와 소유 구조, 권한 회수, 비용과 결제, 감시와 알림의 이관 — 는 AWS 운영을 넘겨받기 전, 무엇을 확인해야 하는가가 다룹니다. 이 글은 그 위에서 도는 소프트웨어 자체를 봅니다. 코드가 어디 있는지, 고칠 수 있는지, 고친 것이 실제 서비스에 닿는지입니다.

소스코드에 닿을 수 있는가 — 나머지를 여는 문

여섯 가지는 나란한 항목이 아닙니다. 그중 하나가 나머지 전부보다 무겁습니다. 소스코드 접근입니다.

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

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

이 순서를 뒤집으면 흔한 헛수고가 생깁니다. 문서를 먼저 요청하고, 계정 명의를 먼저 정리하고, 그러고 나서 소스가 없다는 사실을 알게 되는 경우입니다. 앞의 두 가지도 언젠가는 해야 할 일이지만, 가능 여부를 가르는 질문을 먼저 던지는 편이 시간을 아낍니다.

확인 항목 여섯 가지

아래 표가 이 글의 뼈대입니다. 순서는 무게 순이고, 위쪽이 비어 있을수록 아래쪽이 갖춰져 있어도 진행이 막힙니다.

표의 아래 두 줄은 성격이 다릅니다. 명의와 문서가 비어 있으면 시간이 더 들고 손이 더 가지만, 길이 끊기지는 않습니다. 위의 네 줄은 비어 있는 정도에 따라 할 수 있는 일의 범위 자체가 달라집니다.

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

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

일부만 있는 경우가 가장 자주 걸립니다

받은 파일이 있어도 그것이 지금 돌아가는 그 프로그램의 전부가 아닌 경우가 있습니다. 화면 쪽 코드는 있는데 뒤에서 도는 부분이 빠져 있거나, 코드는 있는데 실행에 필요한 설정값이 함께 오지 않은 형태입니다. 설정값이 없으면 코드는 있어도 띄울 수가 없습니다.

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

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

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

하나는 최근에 손댄 자리를 알 수 있다는 점입니다. 최근에 바뀐 곳은 대개 아직 안정되지 않은 곳이라, 처음 손볼 때 먼저 봐야 할 자리가 됩니다. 다른 하나는 되돌릴 수 있다는 것입니다. 이력이 있으면 고쳤다가 문제가 생겼을 때 이전 상태로 돌아갈 수 있습니다. 이력 없이 파일만 받으면 이 안전장치가 없어서, 초반의 작은 수정 하나하나가 신중해집니다.

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

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

코드가 있어도 그것이 어디서 어떤 설정으로 돌고 있는지는 환경을 봐야 읽힙니다. 같은 코드도 환경 설정에 따라 다르게 동작하기 때문입니다.

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

가운데 두 층 사이의 간격이 생각보다 큽니다. 업체를 거쳐야만 닿는 환경은 인계 시점에 멈춥니다. 평소에는 요청하면 처리되니 불편이 드러나지 않다가, 주체를 바꾸는 시점에 그 통로 하나에 모든 것이 걸립니다. 그래서 전환을 검토하기 시작했다면 직접 닿는 경로를 확보하는 일이 목록의 앞쪽에 옵니다.

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

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

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

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

가장 흔히 놓치는 것이 마지막 한 칸입니다. 백업이 도는 것과 복구되는 것은 다릅니다. 백업 파일이 매일 생기고 있어도 그것을 실제로 되돌려 본 적이 없다면, 사고가 났을 때가 첫 시험이 됩니다. 이어받는 시점은 조용한 시점이라 이 시험을 해 두기에 적당합니다.

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

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

배포 경로 — 고친 것이 서비스에 닿는 길

소스가 있고 환경에도 닿는데 진행이 막히는 자리가 여기입니다. 고친 것을 실제 서비스에 반영하는 방법이 남아 있지 않으면, 고칠 수 있다는 말이 실질적인 의미를 갖지 못합니다.

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

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

확인하는 방법은 데이터와 같습니다. 아주 작은 변경 하나를 실제로 반영해 보는 것입니다. 화면 문구 한 줄 정도면 충분합니다. 이 한 번이 되면 소스·환경·배포 세 갈래가 실제로 이어져 있다는 뜻이고, 여기서 막히면 어디가 끊겨 있는지도 함께 드러납니다.

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

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

그런데 이 자리에서 함께 나오는 질문이 하나 더 있습니다. 그래서 이 시스템은 누구 것인가입니다.

소유는 네 갈래로 갈립니다

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

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

네 가지는 서로 다른 문제인데 한 문장으로 뭉뚱그려 적히는 일이 흔합니다. 이 구분은 맞춤형 업무 시스템과 SaaS, 무엇을 선택해야 하는가에서도 같은 형태로 다뤘습니다.

넘겨받았다와 고쳐도 된다는 다른 말입니다

저작권법은 저작재산권의 전부를 양도하는 경우에도 특약이 없으면 원저작물을 고쳐 새로 만들어 이용할 권리까지는 넘어가지 않은 것으로 추정한다고 정하고 있습니다. 이어받기의 맥락으로 옮기면 이렇습니다. 소유권 조항이 있다는 사실만으로 수정과 개작이 당연히 허용된다고 읽을 수는 없고, 그 권리가 별도로 적혀 있는지를 따로 봐야 합니다.

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

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

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

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

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

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

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

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

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

비어 있는 칸이 많다는 것은 먼저 확보할 것이 있다는 뜻이지, 새로 만들어야 한다는 뜻이 아닙니다. 이 둘은 자주 붙어 다니지만 같은 말이 아닙니다. 확보는 요청과 확인으로 채워지는 일이고, 지금 돌아가고 있는 시스템은 그 사이에도 계속 돌아갑니다.

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

1. 소스코드 — 지금 돌아가는 그것의 소스와 변경 이력을 확보합니다. 여기서 갈 수 있는 길이 정해집니다.
2. 실행 환경 — 직접 닿는 접근 경로를 확보합니다. 코드가 어떤 설정으로 도는지는 여기서만 읽힙니다.
3. 데이터 — 꺼낼 수 있는지 확인하고, 되돌릴 수 있는지까지 한 번 시험합니다.
4. 배포 경로 — 아주 작은 변경 하나를 실제로 반영해 봅니다. 앞의 셋이 이어져 있는지가 이 한 번으로 확인됩니다.
5. 계정 명의 — 도메인·인증서·외부 서비스의 명의와 결제 주체를 회사로 정리합니다.
6. 기록·문서 — 확인하면서 정리한 것을 그대로 문서로 남깁니다.

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

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

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

다음 단계

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

이어받는 일을 실제로 어떻게 진행하는지는 AI · 앱 개발 — 만드는 일과 이어받는 일에 적혀 있습니다. 지금 상황이 어느 쪽에 가까운지부터 정리하고 싶으시면 기존 시스템을 계속 잘 쓰고 싶습니다에서 상황별로 무엇부터 보면 되는지 갈라 두었습니다.

우리 시스템에서 무엇이 남아 있는지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오. 확인 결과 저희가 맡는 것이 맞는 자리가 아니라면, 그 판단도 근거와 함께 말씀드립니다.

참고 자료

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