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

「개발한 회사가 이미 없다」, 「만든 담당자가 퇴사해서 연락이 되지 않는다」, 「서버 안에는 실행 파일과 데이터베이스가 있지만 소스 코드도 명세서도 찾을 수 없다」── 중소기업의 업무 시스템 상담에서 결코 드물지 않은 상황입니다. 그래도 시스템은 오늘도 돌아가고, 업무는 그 시스템에 의존합니다.

이 상태에서 최악의 선택은 「잘 모르니까」라는 이유로 감에 의존한 수정이나 즉흥적인 환경 변경을 시작하는 것입니다. 소스 코드가 없는 시스템은 고장 났을 때 고칠 수 있다는 보장이 없습니다. 한편 「할 수 있는 일이 없다, 전면 재구축뿐이다」라고 처음부터 단정하는 것도 이릅니다. 명세서가 없어도 명세를 복원하는 수단은 있고, 소스 코드가 없어도 내부를 읽을 수 있는 경우가 있습니다. 이 글에서는 아무 자료도 없는 상태에서 운영·유지보수가 성립하기까지의 절차를, 실무 순서대로 정리합니다.

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장의 인벤토리를 먼저 마치고 대상 개수를 세는 것입니다. 개수가 나오기 전에는 명세 복원 기간을 산정할 수 없습니다. 거꾸로 말하면 인벤토리는 짧은 기간에 끝마쳐야 할 공정이고, 여기를 끌면 이후 계획을 전혀 세울 수 없습니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 22건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

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. 가져올 볼륨을 고릅니다. 부팅된 시스템에서 도구를 실행하면 그 시스템의 볼륨 목록이 나옵니다. 여기서 고른 볼륨이 있는 디스크마다 VHD 1개가 만들어지고, 파티션 구성은 유지되는 반면 내용이 복사되는 것은 선택한 볼륨뿐입니다. 따라서 검증 부팅을 하려면 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. 명세서가 없어도 명세는 복원할 수 있다

인벤토리로 「무엇이 있는지」를 알았다면, 다음은 「무엇을 하는지」의 복원입니다. 재료는 갖춰져 있습니다.

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

여기서 중요한 것은 모든 기능을 균등하게 문서화하려 하지 않는 것입니다. 목적은 백과사전이 아니라 운영의 지속이므로, 「멈추면 업무가 멈추는 처리」, 「오류가 나고 있는 처리」, 「가까운 시일 내 변경이 필요해질 부분」부터 우선해, 조사한 범위를 목록에 쌓아 갑니다.

인터뷰 틀 ── 누구에게, 무엇을, 어떻게 기록하는가

「사용자에게 듣는다」는 말은 쉽지만, 상대와 질문을 정해 두지 않으면 잡담으로 끝납니다. 실무에서는 다음 세 층으로 나눠 각각 별도 시간을 잡는 것이 확실합니다.

질문은 매번 같은 항목을 재사용합니다. 다음 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# 코드는 처리를 이해하는 데 충분히 실용적입니다. 다만 공식 문서에도 명시되어 있듯이, 주석·지역 변수 이름·공백처럼 컴파일 때 불필요한 정보는 사라져 있으며, 원본 소스 코드의 대체가 아니라 「동작을 이해하기 위한 자료」로 자리매김해야 합니다.³ 예외도 있습니다. 난독화(obfuscation)가 걸려 있으면 해독 난이도가 크게 올라가고, Native AOT로 게시된 바이너리는 IL을 포함하지 않으므로 「.NET이니까 읽을 수 있다」는 기대는 성립하지 않습니다. Native AOT는 .NET 7에서 도입된 게시 방식이며, 공식 문서에도 「게시 시점에 사전 컴파일러가 IL을 네이티브 코드로 컴파일한다」, 「Native AOT 앱은 실행 시 JIT 컴파일러를 쓰지 않는다」고 명시되어 있습니다.⁷ 역컴파일러가 읽어 들일 대상 자체가 결과물에 남지 않는다는 뜻입니다. 기술 스택을 볼 때는 개발 언어뿐 아니라 배치 형식까지 포함해 확인하십시오.

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

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

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

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

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

6. 수명 연장인가, 래핑인가, 다시 만들 것인가

조사로 얻은 이해도와 업무 쪽 사정이 갖춰지면 방침을 정합니다. 여기에서도 「전면 재구축이 전제」도 「손대지 않는 것이 전제」도 아니고, 판단표로 정리합니다.

판단 축은 잔여 이용 연수, 변경 요청의 빈도와 편중, 멈췄을 때의 업무 영향, 그리고 조사로 복원한 이해도 네 가지입니다. 이해도가 낮은 채로 전면 재구축에 들어가면, 구시스템의 「아무도 설명하지 못하지만 업무상으로는 올바른 동작」을 놓칩니다. 재구축을 고르더라도 제4장에서 복원한 명세 목록이 그대로 요구사항 정의의 밑바탕이 되므로, 조사에 들인 투자는 헛되지 않습니다. 이전 때에는 신구 시스템을 일정 기간 병행 가동하고, 같은 입력에 대한 출력(장표·집계·파일)을 기계적으로 대조하는 것이 정석입니다.

또한 VB6나 Access처럼 기술별 수명 연장·이전 판단은 「VB6 / Access 업무 앱의 수명 연장과 이전」에서, 사내 웹 시스템의 IE 모드 의존은 「IE 모드 의존 시스템 탈피 가이드」에서 자세히 다룹니다.

7. 인수인계 후의 운영·유지보수 체제

방침이 「당분간은 운영을 계속한다」인 경우(실제로는 대부분이 그렇습니다), 다음 틀을 지키면 사고가 줄어듭니다.

• 검증 환경을 둔다 ── 다만 첫 부팅은 반드시 네트워크에서 격리한다 ── 3.2에서 만든 디스크 이미지를 가상 머신으로 부팅하면, 운영과 같은 구성의 검증 환경이 됩니다. 다만 이 이미지에는 운영의 연결 문자열·인증 정보·예약 작업·자동 시작 서비스가 그대로 남아 있습니다. 네트워크에 연결한 채로 부팅하면, 야간 배치가 이중으로 돌아 운영 데이터베이스를 갱신하거나, 메일이 재발송되거나, 외부 API를 호출할 수 있습니다. 첫 부팅은 반드시 가상 NIC를 빼거나 격리 네트워크에서 하고, 예약 작업과 자동 시작 서비스를 멈춘 뒤, 접속 대상을 검증용으로 바꾼 다음, 필요한 범위만 접속을 허용합니다.
• 변경은 하나씩, 되돌릴 수 있는 형태로 ── 설정 변경도 Windows Update 적용도 한 번에 하나. 변경 전 이미지를 남기고, 문제가 나면 되돌립니다. 무엇을 바꿨는지의 기록(변경 대장)을 세트로 둡니다.
• 문서는 「조사한 일의 부산물」로 키운다 ── 완벽한 명세서를 쓰는 프로젝트를 세우는 것이 아니라, 장애 대응이나 수정을 할 때마다 알게 된 것을 목록에 덧붙입니다. 1년만 운영해도 업무상 중요한 부분부터 문서가 갖춰져 갑니다.
• 모니터링을 넣는다 ── 생존 감시, 디스크 여유, 오류 로그, 그리고 「늘 나와야 할 파일이 나오지 않음」의 감지. 블랙박스 내부는 보이지 않아도 입구와 출구는 모니터링할 수 있습니다.
• 계약은 조사와 수정을 나눈다 ── 외부에 유지보수를 맡기는 경우, 내부를 모르는 시스템의 조사에 완성 책임을 약속할 수 없으므로, 조사·유지보수는 준위임, 명세가 굳은 개별 수정은 도급(또는 성과 완성형 준위임)으로, 단계별로 계약을 나누는 것이 건전합니다.

8. 정리

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

관련 글

• PDB(프로그램 데이터베이스)란 무엇인가 ── 디버그 정보·심볼·Source Link 이해하기
• Process Monitor 실전 가이드
• VB6 / Access 업무 앱의 수명 연장과 이전 ── 남기기·래핑·교체의 판단표
• IE 모드 의존 시스템 탈피 가이드
• 수탁 개발·운영 유지보수의 계약은 어떻게 맺을 것인가 ── IPA 「모델 거래·계약서」에서 배우는 준위임과 도급의 구분
• Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리하고 싶은 것

관련 상담 영역

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

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

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

소스 코드가 없는 시스템도 유지보수나 수정을 의뢰할 수 있습니까?

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

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

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

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

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

명세서가 없는 시스템은 무엇부터 손대면 좋습니까?

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

저자 프로필

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

Go Komura

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

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