소스 코드도 사양서도 없는 시스템을 인계받았다면 ── 멈추지 않고 운용·보수하기 위한 실무 절차

“개발한 회사가 이미 존재하지 않는다”, “만든 담당자가 퇴사해 연락이 닿지 않는다”, “서버 안에 실행 파일과 데이터베이스는 있지만 소스 코드도 사양서도 찾을 수 없다” ── 중소기업의 업무 시스템 상담에서 결코 드물지 않은 상황입니다. 그래도 시스템은 오늘도 동작하고 있고, 업무는 그것에 의존하고 있습니다.

이 상태에서 최악의 선택은 “잘 모르니까”라는 이유로 손으로 더듬듯 개수하거나 즉흥적인 환경 변경을 시작해 버리는 것입니다. 소스 코드가 없는 시스템은 고장 났을 때 고칠 수 있다는 보장이 없습니다. 한편 “아무것도 할 수 없다, 전면 재구축밖에 없다”라고 처음부터 결론을 내리는 것도 성급합니다. 사양서가 없어도 사양을 복원할 수단은 있고, 소스 코드가 없어도 내부를 읽을 수 있는 경우가 있습니다. 이 글에서는 아무것도 없는 상태에서 운용·보수를 성립시키기까지의 절차를, 실무의 순서대로 정리합니다.

1. 먼저 결론

• 가장 먼저 해야 할 일은 개수가 아니라 ‘현상 보전’입니다. 가동 중인 운영 환경 그 자체가 가장 중요한 자산입니다. 디스크 이미지 백업(Disk2vhd를 이용한 가상 머신화 등)과 데이터베이스 백업을 확보하고, 복원할 수 있는지까지 확인한 뒤 다음 단계로 넘어갑니다.¹
• 사양서가 없어도 사양은 복원할 수 있습니다. 업무 이용자 청취, 화면·장표, 데이터베이스 스키마, 로그, 그리고 Process Monitor를 이용한 실제 동작 관찰이 주된 재료입니다.²
• 소스 코드의 복원 가능성은 기술 스택에 따라 크게 다릅니다. .NET으로 만들어졌다면 ILSpy 등의 역컴파일러로 상당 부분 읽을 수 있는 반면, VB6나 C++ 등 네이티브 코드의 복원은 현실적으로 기대하기 어렵습니다.³⁴
• 역컴파일에는 법적인 쟁점이 있습니다. 저작권법 제30조의4에 따라 조사·해석 목적의 이용은 원칙적으로 허용된다고 정리되어 있지만, 계약(사용 허락 조항)의 확인은 필수입니다.⁵
• ‘완전히 이해한 뒤에’를 기다리지 않는 것입니다. 멈추면 업무가 멈추는 부분과 변경이 임박한 부분부터 우선적으로 파악하고, 변경은 작게 하나씩, 되돌릴 수 있는 형태로 진행합니다.
• 유지보수 계약은 준위임이 기본입니다. 내부를 알 수 없는 시스템의 조사에 완성 책임(도급)은 약속할 수 없습니다. 조사 단계와 개수 단계를 나누어 계약합니다.

이 글은 실무에서 밟는 순서대로 구성되어 있습니다. 전체 흐름은 다음과 같습니다.

flowchart TD
    A["제3장 보전<br/>변경 동결·디스크 이미지<br/>DB 백업과 복원 확인"] --> B["제3장 목록화<br/>실행 파일·자동 시작·작업<br/>설정·연계처·계정"]
    B --> C["제4장 사양 복원<br/>청취·화면과 장표<br/>DB 스키마·실제 동작 관찰"]
    C --> D["제5장 기술적 가능 여부<br/>기술 스택 판단<br/>역컴파일과 법적 확인"]
    D --> E["제6장 방침 결정<br/>연명·감싸기·부분 재구축·전면 재구축"]
    E --> F["제7장 운용 이관<br/>검증 환경·변경 대장·모니터링·계약"]
    C -.->|"복원한 사양 대장은<br/>어떤 방침을 택해도 자산이 된다"| E

그림 1: 인수인계 전체 흐름과 대응하는 장

공정별 소요 기간은 시스템의 규모(화면·장표·배치의 개수), 기술 스택, 업무 측에서 청취에 할애해 줄 수 있는 시간, 그리고 “어디까지 알면 충분한가”라는 목표 설정에 따라 크게 달라지기 때문에, 착수 전에 일률적인 기준을 정할 수는 없습니다. 견적의 정확도를 높이는 유일한 지름길은 제3장의 목록화를 먼저 끝내고 대상의 개수를 세는 것입니다. 개수가 나오기 전까지는 사양 복원 기간을 산정할 수 없습니다. 뒤집어 말하면 목록화는 단기간에 끝내야 할 공정이며, 이 부분을 질질 끌면 이후의 계획을 전혀 세울 수 없게 됩니다.

2. 왜 “아무것도 없는” 상태가 생기는가

대처를 생각하기 전에, 자사가 어떤 패턴에 해당하는지 확인해 두면 남아 있는 단서를 가늠할 수 있습니다.

마지막 패턴은 간과되기 쉽지만, 실질적으로는 “소스가 없다”는 것과 동일하게 취급할 필요가 있습니다. 오래된 소스를 정본으로 삼아 개수했더니, 실은 운영 환경의 실행 파일에는 수년분의 수정이 들어가 있었다는 사고는 전형적인 실패 사례입니다. 소스가 발견된 경우에도, 빌드해서 운영 환경의 실행 파일과 대조하기 전까지는 신뢰하지 마십시오.

어느 패턴이든, 우선 계약서·납품서·검수서를 찾아보는 것에는 가치가 있습니다. 저작권의 귀속이나 소스 코드의 납품 의무가 명시되어 있다면, 이후 협상이나 법적 정리의 토대가 됩니다.

3. 첫 한 주 동안 해야 할 일 ── 현상 보전과 목록화

3.1 변경 동결

조사가 끝날 때까지 대상 서버·단말에는 손을 대지 않는 것이 원칙입니다. “일단 OS를 업데이트하자”, “안 쓰는 것 같은 파일을 정리하자”가 치명타가 됩니다. 소스 코드가 없는 이상 고장 났을 때 ‘고친다’는 선택지가 없기 때문입니다. 자동 업데이트(Windows Update, 백신 소프트웨어의 동작 변경)가 임의로 환경을 바꾸지 않도록 업데이트 적용 시점을 관리 하에 두는 것도 검토합니다.

3.2 백업 ── 환경 자체를 자산으로 복제하기

파일 단위 백업만으로는 불충분합니다. 이런 종류의 시스템은 OS 설정·레지스트리·런타임·배치 위치 전부가 “동작하는 이유”의 일부일 가능성이 있으므로, 디스크 이미지 전체를 보전합니다.

실무에서 자주 쓰이는 것은 Sysinternals의 Disk2vhd입니다. 가동 중인 시스템을 온라인 상태 그대로, Windows의 볼륨 스냅숏 기능(VSS: Volume Shadow Copy Service, 볼륨 섀도 복사 서비스)으로 일관성 있는 시점의 VHD/VHDX로 변환할 수 있으며, Hyper-V 상의 가상 머신으로 기동하는 검증 환경의 토대가 됩니다.¹ 물리 서버의 노후화 대책과 검증 환경 확보를 동시에 진행할 수 있는 것이 장점입니다(단, OEM 라이선스의 Windows는 가상 환경으로의 이전이 라이선스상 허용되지 않는 경우가 있으므로, 라이선스 형태의 확인이 필요합니다¹).

Disk2vhd는 화면이 한 장뿐인 단순한 도구이지만, 선택을 잘못하면 “기동하지 않는 이미지”가 만들어집니다. 다음 순서로 진행하십시오.¹

1. 출력 위치를 준비한다. VHD/VHDX는 변환 대상 볼륨 위에도 만들 수 있지만, 대상과는 다른 디스크(외장 드라이브나 NAS 등)에 출력하는 편이 성능이 좋다고 공식 문서에도 명시되어 있습니다. 여유 공간은 선택할 볼륨의 사용 영역 합계 이상을 확보해 둡니다.
2. BitLocker를 확인한다. Disk2vhd는 BitLocker가 활성화된 볼륨의 변환을 지원하지 않습니다. 대상이 되는 경우에는 사전에 BitLocker를 해제하고, 복호화가 완료될 때까지 기다린 뒤 실행합니다.
3. 가져올 볼륨을 선택한다. 기동한 상태 그대로의 시스템에서 도구를 실행하면 해당 시스템의 볼륨 목록이 표시됩니다. 여기서 선택한 볼륨이 존재하는 디스크마다 1개의 VHD가 만들어지며, 파티션 구성은 유지되는 반면 내용이 복사되는 것은 선택한 볼륨뿐입니다. 따라서 검증용으로 기동하고 싶다면 Windows가 들어 있는 볼륨(보통 C:)과 기동에 필요한 시스템 파티션(시스템 예약/EFI 시스템 파티션) 양쪽을 선택합니다. 순수한 데이터용 볼륨을 제외하면 그만큼 용량과 시간을 절약할 수 있습니다.
4. 필요하면 명령줄로 실행한다. 야간에 돌리고 싶은 경우 등에는 disk2vhd <드라이브:> [드라이브:] ... <출력 파일> 형태로 스크립트화할 수 있습니다. 전체 볼륨을 대상으로 하려면 disk2vhd * e:\backup\snapshot.vhdx 처럼 *를 지정합니다.
5. 검증 기동은 Hyper-V에서 수행한다. Hyper-V 관리자에서 가상 머신을 만들고, 완성된 VHD를 IDE 디스크로 구성에 추가합니다. 최초 기동 시 Windows가 가상 머신의 하드웨어를 감지하고, 이미지 안에 드라이버가 있으면 자동으로 설치합니다. 없으면 Hyper-V 통합 구성 요소를 설치합니다.
6. 생성 원본 머신에 연결해 기동하지 않는다. 같은 시스템에서 VHD를 연결(attach)하면, Windows는 원래 디스크와의 서명 충돌을 피하기 위해 VHD에 새로운 디스크 서명을 할당합니다. 부팅 구성 데이터(BCD)는 디스크 서명으로 디스크를 참조하기 때문에, 이 상태에서 가상 머신을 기동하면 부팅 디스크를 찾지 못해 실패합니다. 검증 기동은 반드시 다른 머신(Hyper-V 호스트)에서 수행하십시오.

아울러 데이터베이스는 DBMS 표준 수단으로 백업을 확보합니다. 그리고 가장 중요한 것은 백업으로부터 실제로 복원해서 기동되는지 확인하는 것입니다. 복원 테스트를 하지 않은 백업은 있는 셈 치는 보험일 뿐입니다. 다만 복원한 이미지에는 운영 환경의 접속 설정이나 예약 작업이 그대로 남아 있기 때문에, 기동 확인은 반드시 네트워크에서 격리된 상태로 수행하십시오(자세한 내용은 제7장 참고). 무심코 연결한 채로 기동하면, 검증하려던 환경이 운영 데이터베이스나 연계처를 갱신해 버립니다.

3.3 목록화 ── 무엇이 동작하고 있는지 리스트로 만들기

다음으로 시스템의 구성 요소를 기계적으로 빠짐없이 찾아냅니다. 여기서는 센스가 아니라 망라성이 중요한 작업입니다.

설정 파일이나 출력 위치가 “어디에 있는지 알 수 없는” 경우에는, Process Monitor로 프로세스의 파일·레지스트리 접근을 관찰하는 것이 지름길입니다. 애플리케이션이 실제로 읽고 쓰는 경로가 그대로 목록이 됩니다.²

4. 사양서가 없어도 사양은 복원할 수 있다

목록화로 “무엇이 있는지”를 알았다면, 다음은 “무엇을 하고 있는지”의 복원입니다. 재료는 갖춰져 있습니다.

• 업무 이용자 청취 ── 최대의 사양서는 매일 그 시스템을 사용하는 사람의 머릿속입니다. 일일·월간·연간 업무 흐름에 따라 어느 화면에서 무엇을 입력하고 무엇이 나오는지 청취합니다. 특히 연간 처리(결산, 재고 조사, 연도 갱신)는 담당자도 잊고 있는 경우가 있어, 인수인계 후 처음 맞이할 때 사고가 일어나기 쉬운 지점입니다.
• 화면과 장표 ── 모든 화면·모든 장표를 스크린샷과 실물 샘플로 대장화합니다. 입력 항목과 출력 항목의 대응 관계만으로도 처리의 골격이 상당히 보이기 시작합니다.
• 데이터베이스 스키마와 데이터 ── 테이블 정의, 제약 조건, 코드값의 실제 데이터는 업무 규칙의 화석입니다. “이 플래그 값은 3종류밖에 쓰이지 않는다” 같은 관찰이 화면에서는 보이지 않는 사양을 알려줍니다.
• 로그와 이벤트 로그 ── 애플리케이션 고유의 로그가 있다면 처리 흐름을, Windows 이벤트 로그에서는 과거 오류 경향을 파악할 수 있습니다.
• 실제 동작 관찰 ── Process Monitor로 파일·레지스트리·네트워크 접근을 기록하면, “월말의 이 처리는 이 공유 폴더의 CSV를 읽고, 이 데이터베이스 서버와 통신하고 있다”라는 입출력 대응 관계를 소스 코드 없이도 뒷받침할 수 있습니다.² 다만 Process Monitor로 알 수 있는 것은 통신 상대까지이며, 어느 테이블이 어떻게 갱신되었는지까지는 보이지 않습니다. 그 이후는 DBMS 쪽의 추적·감사 기능(SQL Server의 확장 이벤트 등)이나, 처리 전후로 데이터베이스 내용을 대조하는 방법으로 특정합니다.

여기서 중요한 것은 모든 기능을 균등하게 문서화하려 하지 않는 것입니다. 목적은 백과사전이 아니라 운용의 지속이므로, “멈추면 업무가 멈추는 처리”, “오류가 발생하는 처리”, “조만간 변경이 필요해질 부분”부터 우선하여, 조사한 범위를 대장에 쌓아 나갑니다.

청취의 형식 ── 누구에게, 무엇을, 어떻게 기록할 것인가

“이용자에게 물어본다”는 말은 쉽지만, 물어볼 상대와 질문을 정해 두지 않으면 잡담으로 끝나 버립니다. 실무에서는 다음 3계층으로 나누어 각각 별도의 시간을 잡는 것이 확실합니다.

질문은 매번 같은 항목을 재사용합니다. 다음 10가지 질문을 토대로 하면 시스템이 달라져도 사용할 수 있습니다.

1. 이 시스템에서 매일 반드시 하는 조작은 무엇입니까. 몇 시쯤, 몇 건 정도입니까.
2. 월간·연간에만 하는 조작이 있습니까(마감 처리, 결산, 재고 조사, 연도 갱신 등). 지난번은 언제, 누가 했습니까.
3. 입력의 바탕이 되는 종이·파일·메일은 무엇입니까. 어디에서 옵니까.
4. 이 시스템이 출력하는 것(장표, CSV, 외부로의 송신)은 무엇이며, 그 후 어디로 전달됩니까.
5. 시스템이 멈추면 업무는 몇 시간까지 버틸 수 있습니까. 그때 수작업으로 대체할 수 있습니까.
6. “이 조작만은 해서는 안 된다“라는 이야기가 전해지고 있습니까. 이유를 알고 있습니까.
7. 현재 수작업으로 보충하고 있는 것이 있습니까(옮겨 적기, Excel로 재집계, 육안 점검 등).
8. 최근 1년 사이에 오류나 트러블이 있었습니까. 어떻게 대처했습니까.
9. 사용하지 않는 화면·기능은 어느 것입니까. 언제부터 사용하지 않았습니까.
10. 만약 고칠 수 있다면 가장 곤란한 점은 무엇입니까.

기록 방식도 정해 둡니다. 답변은 화면명·장표명·테이블명 같은 고유 명사에 연결지어 남기는 것이 요점으로, “월말에 집계한다”가 아니라 “월간 매출 집계 화면(F050)에서 매출 월보를 인쇄한다”는 정도의 세밀함까지 낮추면, 제3장의 목록화 표나 이후의 데이터베이스 조사와 대조할 수 있습니다. 가능하면 녹음하고, 현장에서는 고유 명사와 조작 순서 메모에 집중하십시오. 5번 답변은 제6장의 방침 판단에, 6번과 7번 답변은 숨겨진 사양의 소재를 알려 주는 단서가 됩니다.

5. 소스 코드가 없는 경우, 기술적으로 무엇을 할 수 있는가

“내부를 읽는” 것을 어디까지 기대할 수 있는지는 시스템이 무엇으로 만들어졌는가에 따라 거의 결정됩니다. 실행 파일의 속성이나 DLL 구성으로부터 기술 스택을 추정한 뒤, 기대치를 설정하십시오.

먼저 이 장에서 사용하는 용어를 간단히 정의해 둡니다.

일반적인 IL 형식으로 배치된 .NET 앱의 경우는 상황이 상당히 좋아서, 역컴파일로 얻어지는 C# 코드는 처리를 이해하는 데 충분히 실용적입니다. 다만 공식 문서에도 명시되어 있듯이, 주석·지역 변수명·공백 등 컴파일 시 불필요한 정보는 소실되어 있으며, 원본 소스 코드의 대체가 아니라 ‘동작을 이해하기 위한 자료’로 자리매김해야 합니다.³ 예외도 있습니다. 난독화(옵퍼스케이션)가 적용되어 있는 경우 해독 난이도가 크게 올라가며, Native AOT로 배포된 바이너리는 IL을 포함하지 않기 때문에 “.NET으로 만들어졌으니 읽을 수 있다”는 기대는 성립하지 않습니다. Native AOT는 .NET 7에서 도입된 배포 방식으로, 공식 문서에도 “배포 시점에 사전 컴파일러가 IL을 네이티브 코드로 컴파일한다”, “Native AOT 앱은 실행 시 JIT 컴파일러를 사용하지 않는다”라고 명시되어 있습니다.⁷ 역컴파일러가 읽어 들일 대상 자체가 결과물에 남지 않는다는 뜻입니다. 기술 스택을 판단할 때는 개발 언어뿐 아니라 배포 형식까지 포함하여 확인하십시오.

실행 파일과 함께 PDB(심볼 파일)가 남아 있다면, 함수명이나(임베디드 소스가 있으면) 소스 자체까지 복원할 수 있는 경우가 있습니다. 무엇이 들어 있고 무엇을 기대할 수 있는지는 PDB(프로그램 데이터베이스)란 무엇인가에서 정리하고 있습니다.

법적 유의점 ── 역컴파일은 “조사한 뒤에”

기술적으로 할 수 있는 것과 해도 되는 것은 별개입니다. 역컴파일을 포함한 리버스 엔지니어링에는 저작권법상의 쟁점이 있으며, 헤이세이 30년(2018년) 개정으로 신설된 저작권법 제30조의4(저작물에 표현된 사상 또는 감정의 향유를 목적으로 하지 않는 이용)에 따라, 프로그램의 조사·해석을 목적으로 하는 복제·번안은 필요하다고 인정되는 한도 내에서 원칙적으로 허용된다고 정리되어 있습니다. 다만 조문에는 “저작권자의 이익을 부당하게 해치게 되는 경우는 그러하지 아니하다”라는 단서 조항이 있어, 예를 들어 해석 결과를 이용해 경쟁 제품을 만드는 경우 등은 다른 평가를 받을 수 있습니다.⁵

또한 패키지 소프트웨어나 납품물의 사용 허락 계약에 해석 금지 조항이 포함되어 있는 경우, 그 효력을 어떻게 볼 것인가 하는 계약상의 쟁점도 남아 있습니다. 실시하기 전에 대상 소프트웨어의 라이선스 조항과 당시의 개발 위탁 계약(저작권 귀속 조항)을 확인하고, 판단이 어려운 경우에는 변호사와 상담하십시오. 자사에 저작권이 귀속된 납품물이라면 이 문제는 크게 단순해집니다. 계약서를 읽는 방법에 대해서는 수탁 개발·운용 보수의 계약은 어떻게 맺어야 하는가도 참고하십시오.

법률론 자체는 전문가의 영역이지만, 상담을 요청하기 전에 사내에서 미리 모아 두어야 할 자료는 정해져 있습니다. 다음 항목을 미리 채워 두면 판단이 빨라집니다.

6. 연명할 것인가, 감쌀 것인가, 다시 만들 것인가

조사로 얻은 이해도와 업무 측 사정이 갖춰지면 방침을 결정합니다. 여기서도 “전면 재구축이 우선”도 “방치가 우선”도 아니라, 판단표로 정리합니다.

판단 축은 잔여 이용 연수, 변경 요망의 빈도와 편중, 멈췄을 때의 업무 영향, 그리고 조사로 복원할 수 있었던 이해도의 4가지입니다. 이해도가 낮은 채로 전면 재구축을 진행하면, 구 시스템의 “아무도 설명할 수 없지만 업무상으로는 올바른 동작”을 놓치게 됩니다. 재구축을 선택하는 경우에도 제4장에서 복원한 사양 대장이 그대로 요구사항 정의의 밑바탕이 되므로, 조사에 대한 투자는 헛되지 않습니다. 이전 시에는 신구 시스템을 일정 기간 병행 가동시켜, 같은 입력에 대한 출력(장표·집계·파일)을 기계적으로 대조하는 것이 정석입니다.

또한 VB6나 Access처럼 구체적인 기술별 연명·이전 판단은 VB6 / Access 업무 애플리케이션의 연명과 이전에서, 사내 웹 시스템의 IE 모드 의존에 대해서는 IE 모드 의존 시스템 탈피 가이드에서 자세히 다루고 있습니다.

7. 인계 후의 운용·보수 체제

방침이 “당분간은 운용을 계속한다”인 경우(실제로는 대부분이 이 경우입니다), 다음 형식을 지키면 사고가 줄어듭니다.

• 검증 환경을 갖는다 ── 단, 최초 기동은 반드시 네트워크에서 격리한다 ── 3.2에서 만든 디스크 이미지를 가상 머신으로 기동하면, 운영 환경과 동일한 구성의 검증 환경이 됩니다. 다만 이 이미지에는 운영 환경의 연결 문자열·인증 정보·예약 작업·자동 시작 서비스가 그대로 남아 있습니다. 네트워크에 연결된 채로 기동하면, 야간 배치가 이중으로 돌아 운영 데이터베이스를 갱신하거나, 메일이 재발송되거나, 외부 API를 호출해 버릴 수 있습니다. 최초 기동은 반드시 가상 NIC를 제거하거나 격리 네트워크에서 수행하고, 예약 작업과 자동 시작 서비스를 정지시킨 뒤, 접속 대상을 검증용으로 다시 써서, 필요한 범위만 접속을 허용합니다.
• 변경은 하나씩, 되돌릴 수 있는 형태로 ── 설정 변경도 Windows Update 적용도 한 번에 하나씩. 변경 전 이미지를 남겨 두고, 문제가 생기면 되돌립니다. 무엇을 바꿨는지 기록(변경 대장)을 함께 남깁니다.
• 문서는 “조사한 것의 부산물”로 키운다 ── 완벽한 사양서를 작성하는 프로젝트를 세우는 것이 아니라, 장애 대응이나 개수를 할 때마다 알게 된 것을 대장에 추가합니다. 1년 정도 운영하면 업무상 중요한 부분부터 순서대로 문서가 갖춰져 갑니다.
• 모니터링을 심어 둔다 ── 생사 확인(heartbeat) 모니터링, 디스크 여유 공간, 오류 로그, 그리고 “평소 출력되어야 할 파일이 나오지 않는다”의 탐지. 블랙박스의 내부는 보이지 않아도 입구와 출구는 모니터링할 수 있습니다.
• 계약은 조사와 개수를 나눈다 ── 외부에 유지보수를 의뢰하는 경우, 내부를 알 수 없는 시스템의 조사에 완성 책임은 약속할 수 없으므로, 조사·유지보수는 준위임, 사양이 확정된 개별 개수는 도급(또는 성과 완성형 준위임)으로 단계별로 계약을 나누는 것이 건전합니다.

8. 정리

• 소스 코드도 사양서도 없는 시스템을 인계받았다면, 개수보다 먼저 현상 보전입니다. 디스크 이미지(Disk2vhd 등)와 DB 백업을 확보하고, 복원할 수 있는지까지 확인합니다.
• 실행 파일·자동 시작·예약 작업·설정·연계처·계정을 목록화하여, 시스템의 전체 모습을 리스트로 만듭니다.
• 사양은 이용자 청취·화면·장표·DB 스키마·로그·Process Monitor를 통한 실제 동작 관찰로부터 복원할 수 있습니다. 모든 기능이 아니라 업무 영향이 큰 부분부터 우선합니다.
• 내부 복원 가능성은 기술 스택에 달려 있습니다. .NET은 역컴파일로 상당 부분 읽을 수 있지만 원본 소스의 대체는 아닙니다. 실시 전에 저작권법 제30조의4의 취지와 라이선스 조항·계약서를 확인합니다.
• 방침은 “연명·감싸기·부분 재구축·전면 재구축”을, 잔여 이용 연수·변경 빈도·업무 영향·이해도로 판단합니다. 조사로 복원한 사양은 어떤 길을 선택하든 자산이 됩니다.
• 운용 단계에서는 검증 환경·하나씩의 변경·변경 대장·입구와 출구의 모니터링·준위임 계약이 기본 형식입니다.

관련 글

• PDB(프로그램 데이터베이스)란 무엇인가 - 디버그 정보·심볼·Source Link 이해하기
• Process Monitor(ProcMon) 실전 가이드 ── 「설정이 반영되지 않는다」「ACCESS DENIED」를 10분 만에 특정하기
• VB6 / Access 업무 애플리케이션의 연명과 이전 ── 남기다·감싸다·교체하다 판단표
• IE 모드 의존 시스템 탈피 가이드
• 수탁 개발·운용 보수의 계약은 어떻게 맺어야 하는가 ── IPA 「모델 거래·계약서」에서 배우는 준위임과 도급의 구분
• Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리해야 할 것

관련 상담 영역

합동회사 코무라소프트에서는 소스 코드나 사양서가 남아 있지 않은 업무 시스템의 현상 조사(실행 파일·데이터베이스·실제 동작의 해석), 동작으로부터의 사양 복원, 연명·이전 방침 정리, 그 이후의 운용·보수까지 다루고 있습니다. “무엇부터 손을 대야 할지 모르겠다”는 단계에서의 상담도 환영합니다.

• 기존 자산 활용·이전 지원
• 기존 Windows 소프트웨어의 개수·유지보수
• 불량 조사·원인 분석
• 기술 상담·설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

소스 코드가 없는 시스템도 유지보수나 개수를 의뢰할 수 있나요?

의뢰할 수 있습니다. 다만 일반적인 유지보수와는 진행 방식이 달라집니다. 먼저 가동 중인 환경의 보전과 백업을 실시한 뒤, 화면·장표·데이터베이스·로그·실행 파일의 해석으로부터 사양을 복원하는 조사 단계를 두고, 거기서 얻은 이해의 범위 안에서 개수나 주변 기능 개발로 나아가는 것이 현실적입니다. 조사는 성과를 사전에 약속할 수 없는 성질의 작업이므로, 완성 책임을 지는 도급이 아니라 준위임 계약으로 진행하는 것이 일반적입니다.

실행 파일의 역컴파일(리버스 엔지니어링)은 위법이 아닌가요?

일률적으로 위법인 것은 아닙니다. 헤이세이 30년(2018년) 개정 저작권법으로 신설된 제30조의4에 따라, 프로그램의 조사·해석과 같은 '저작물에 표현된 사상 또는 감정의 향유를 목적으로 하지 않는 이용'은 필요하다고 인정되는 한도에서 원칙적으로 허용된다고 정리되어 있습니다. 다만 '저작권자의 이익을 부당하게 해치게 되는 경우'는 제외되는 것 외에도, 사용 허락 계약에서 해석이 금지되어 있는 경우의 취급이라는 쟁점도 남아 있습니다. 실시하기 전에 라이선스 조항과 개발 위탁 당시의 계약서를 확인하고, 판단이 어려운 경우에는 변호사 등 전문가와 상담하십시오.

개발사가 도산해서 소스 코드를 입수할 수 없습니다. 어떻게 하면 좋을까요?

먼저 과거의 계약서와 납품물을 확인하십시오. 개발 위탁 계약에서 저작권이나 소스 코드의 귀속·납품이 정해져 있다면 입수나 이용의 근거가 됩니다. 연락이 닿는 관계자가 있다면 입수 협상의 여지도 찾아볼 가치가 있습니다. 다만 실무에서는 '결국 입수하지 못했다'에서 멈추지 않는 것이 중요하며, 입수할 수 없다는 전제로 가동 중인 환경의 보전·백업과, 동작이나 데이터베이스로부터의 사양 복원을 병행하여 시작할 것을 권장합니다.

사양서가 없는 시스템은 무엇부터 손을 대면 좋을까요?

개수보다 먼저, 우선 현상 보전입니다. 가동 중인 운영 환경의 디스크 이미지와 데이터베이스 백업을 확보하고, 복원할 수 있는지 확인합니다. 다음으로 실행 파일·자동 시작·예약 작업·설정·연계처·계정의 목록화를 실시하여 시스템의 전체 모습을 리스트로 만듭니다. 그런 다음 업무 이용자 청취와 화면·장표·데이터베이스 스키마 관찰을 통해, 업무상 중요한 부분으로 좁혀 사양을 문서화해 나가는 것이 정석입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.