문서가 없는 시스템을 인수할 때
만든 사람은 이미 떠났고, 어디를 건드리면 무엇이 깨지는지 아무도 장담하지 못합니다. 감에 의존하기보다 먼저 한 번 스캔해서 무엇이 들어 있는지, 무엇이 무엇을 호출하는지, 위험이 어디에 있는지 펼쳐 놓고 보십시오.
네 가지 상황, 같은 문제
직접 만들었는데 담당자가 떠났습니다
정보시스템 부서가 직접 개발하고 유지해 온 시스템인데, 만든 담당자는 몇 해 전 퇴사했고 인수인계 자료는 문서 한 부뿐입니다. 이제는 항목 하나 바꾸는 것도 다른 데가 깨지지 않는다고 장담할 사람이 없습니다.
외주로 만들었고 업체와는 거래가 끊겼습니다
예전에 외주로 구축한 시스템이고 검수와 함께 종료되었습니다. 원래 업체는 담당자가 바뀌었거나 더는 맡지 않습니다. 손에 있는 것은 소스 한 벌뿐이고 안에 무엇이 있는지 모릅니다.
고객이 시스템 유지보수를 맡겼습니다
컨설팅사나 개발사가 고객의 기존 시스템을 인수하는 경우입니다. 견적 전에 "고칠 수 있는지, 얼마나 걸리는지"를 답해야 하는데 사람이 코드를 뒤져 추정하는 수밖에 없습니다.
입찰로 앞 업체의 시스템을 넘겨받았습니다
낙찰 후 앞 사업자가 만든 시스템을 이어받는 경우, 인수인계와 검수 모두 근거를 제시해야 합니다. 경험담만으로는 고객이 서명해 주지 않습니다.
스캔한 첫날 손에 남는 것
"위험이 높은 편입니다"라는 한마디가 아니라, 회의에 들고 가서 파일을 짚을 수 있는 자료입니다.
이 시스템의 전체 모습
클래스 다이어그램, 패키지 다이어그램, 컴포넌트 다이어그램, 호출 그래프, 의존 그래프, 데이터 흐름도, 시퀀스 다이어그램, 배포 다이어그램 등 모두 20종을 코드에서 바로 생성합니다. 역할별로 골라 볼 수 있어(시스템 분석, 시스템 설계, 개발, 데이터베이스 관리, 화면 설계, 프로젝트 관리, 규정 준수, 경영진 등 9종) 한 번에 다 볼 필요가 없습니다.
어디가 문제이고, 몇 번째 줄인지
31개 프레임워크를 동시에 대조하고, 결함마다 구체적인 파일과 줄 번호를 짚어 위험 순으로 정렬합니다. 이 목록이 공수 산정과 우선순위 결정의 근거가 됩니다.
어떤 패키지를 쓰고, 지뢰는 없는지
SBOM이 모든 의존 패키지와 라이선스 조건, 알려진 취약점을 정리해 줍니다(CycloneDX와 SPDX 두 형식). 라이선스 문제나 유지보수가 끝난 패키지를 인수 전에 확인할 수 있습니다.
전반적인 건전성, 그리고 어느 축이 추정값인지
8축 리스크 지문: 보안 태세는 스캔으로 실측한 값입니다. 문서, 테스트, 의존성, 기술 부채 네 축은 현재 시스템 기본 추정값이며, 그래프에 (추정)으로 표시하고 위험 발견 항목으로도 다루지 않습니다. 가려 두기보다 표시해 두는 편이 낫다고 봅니다.
사람이 걸린 부분
리스크 평가 설문이 스캔으로는 볼 수 없는 부분을 채웁니다. 시스템 인수인계, 요구사항 추적, 변경 예측, 검수 기준, 의사소통 비용 다섯 가지 측면이며, 점수는 응답에서 산출되고 코드 스캔에서 나오지 않습니다.
보고서와 산출물의 소유권은 고객에게 있습니다. 인수인계·검수·견적의 첨부 자료로 고객이나 상급자에게 그대로 제출하실 수 있습니다.
분석 가능한 범위
보통 가장 먼저 나오는 질문이라 분명히 적습니다. 분석은 두 계층입니다. .NET 계열은 구문 트리에 더해 컴플라이언스와 보안 규칙까지 실행합니다. 나머지 62개 기술 계열은 구문 분석과 호출 관계까지이며 그 규칙은 실행하지 않습니다.
심층 분석(구문 트리 수준)
C#, VB.NET, ASP.NET WebForms(.aspx와 코드비하인드). 클래스 상속과 의존 관계, API 엔드포인트, 데이터 흐름, 업무 로직, 오류 처리를 이 층에서 해석합니다.
규정 준수 규칙이 검사하는 파일
.cs, .vb, .aspx, .sql, .config, .json, .xml, .yml, .yaml, .ps1, .sh, .tf 그리고 .md와 .txt 문서. 기존 24개 프레임워크의 지적 목록은 이 파일들에서 나옵니다. AI 거버넌스 7개는 지원하는 모든 언어에서 AI를 쓰는 곳을 따로 봅니다. .cbl, .pas, .pbl, .prg, .abap 같은 확장자는 목록에 없으므로, 오래된 언어 소스에 하드코딩된 비밀번호나 SQL 인젝션 패턴은 지적 목록에 나타나지 않습니다. 그 계층은 구조와 호출 관계를 봅니다.
구문 분석과 호출 관계 (62개 기술 계열)
Java, Python 2／3, PHP 5／7／8, Go, Rust, C++, SAP ABAP, PowerBuilder, VB6, COBOL(85／2002／IBM／Micro Focus／GnuCOBOL), Delphi, FoxPro, Fortran, Pro*C, 클래식 ASP(VBScript／JScript), AngularJS, jQuery, Ember, TypeScript, CoffeeScript, Blazor, Flutter, MAUI, Xamarin, Flash／Flex, Silverlight, 그리고 소스가 없는 .NET DLL(역컴파일 후 목록화). 이 계층은 파일 수만 세지 않습니다. 프로그램, 클래스, 프로시저를 추출하고, 무엇이 무엇을 호출하는지 호출 그래프를 만들고, 각 루틴의 조건 분기·반복·예외 처리 개수를 기록하며, 동적 호출 지점 — 호출 대상이 실행 시점에야 정해지는 곳으로 마이그레이션에서 가장 놓치기 쉬운 부분 — 을 표시합니다. COBOL은 여기에 더해 copybook을 전개하고(REPLACING 포함) 방언을 식별합니다. 이 결과는 .NET 계층과 같은 목록으로 합쳐지므로 다이어그램과 영향 범위 분석에도 함께 반영됩니다.
코드를 어디서 가져오는가
Git 저장소 주소(GitHub, GitLab, Bitbucket, Azure DevOps, Gitea 등. 내부망에 직접 구축한 Git 서버는 설정에서 허용해야 합니다) 또는 ZIP 직접 업로드(1회 최대 2 GB). CI도 풀 리퀘스트 절차도 없어도 됩니다 — 폴더를 ZIP으로 묶으면 검사할 수 있습니다.
이 계층은 분석 엔진(Agent) 호스트에 Python이 필요하며, 기술 계열별로 개별 on／off가 가능합니다.
현재 지원하지 않는 것
TFVC와 SVN 직접 연결(대신 ZIP 업로드 가능), Oracle PL/SQL 패키지, Excel VBA 매크로, PLC와 OT 컨트롤러 프로그램입니다. 검사 도중에 알게 되는 것보다 미리 말씀드리는 편이 낫습니다.
오래된 기술을 바꾸려면
기술 스택 전환 모듈은 먼저 평가를 제시합니다. 이 시스템이 지금 무엇을 쓰고 있는지, 전환을 몇 단계로 나눌지, 각 단계에서 어떤 파일을 건드리는지입니다. 자동 변환(Codemod)은 현재 .NET 중심으로, WebForms → Razor, EF6 → EF Core, .NET Framework → .NET 9 등을 지원합니다. 다른 언어는 평가와 전환 전후 규정 준수 비교를 제공하며, 변환 자체는 고객 팀이 수행합니다.
- 전환 전후 규정 준수 상태를 나란히 비교 — 업그레이드 과정에서 보안이 낮아지지 않았음을 보여 줍니다
- 각 단계 산출물은 문서 센터에 남아 내려받고 되짚어 볼 수 있습니다
- 변환 결과는 바로 풀 리퀘스트로 열 수 있습니다(GitHub, GitLab, Bitbucket, Azure DevOps, Gitea)