문서 없는 레거시 시스템,
개선 전에 확인할 8가지

01소스만 받지 말고, 실제 운영 경로를 확인합니다

저장소에 있는 코드가 현재 운영 버전과 같은지부터 확인합니다. 소스가 있어도 빌드 도구, 외부 라이브러리, 배포 설정이나 담당자가 없으면 변경을 재현하기 어렵습니다.

• 자산: 저장소·브랜치, 배포 버전, 서버·DB·배치·외부 API 목록
• 권한: 자산 소유자, 접근 승인자, 변경 승인자, 운영 반영 담당자
• 재현: 격리된 환경에서 빌드하고 시작할 수 있는지, 필요한 설정은 무엇인지
• 제약: 지원 종료 여부를 확인할 제품·버전, 라이선스, 외부 업체의 유지보수 범위

남길 것 자산 목록에 운영 근거와 담당자를 함께 적습니다. 비밀번호·토큰은 목록에 넣지 않고 승인된 보관·접근 절차를 따릅니다.

02업무 하나를 끝까지 따라가며 근거를 모읍니다

‘주문 확정’처럼 시작과 끝이 분명한 업무를 골라 입력 → 권한 검사 → 계산 → DB 변경 → 외부 호출까지 따라갑니다. 화면 설명, 코드, 마스킹한 로그, 저장 프로시저와 담당자 설명이 맞는지 대조합니다.

예를 들어 화면에서는 완료로 보이는데 야간 배치가 정산 상태를 다시 바꿀 수 있습니다. 평일 낮의 관찰만으로 월말·연말·장애 복구 작업이 없다고 판단하지 않습니다.

남길 것 각 동작을 ‘실행으로 확인’, ‘코드에서 확인’, ‘담당자 설명’, ‘미확인 가설’로 구분합니다. AI가 추정한 연결 관계도 확인되기 전에는 가설로 남깁니다.

03현재 동작과 지켜야 할 업무 규칙을 구분합니다

기존 시스템과 결과가 같다고 해서 그 결과가 올바른 것은 아닙니다. 오래된 오류를 그대로 복제하지 않도록 현행 동작과 업무 담당자가 승인한 기대 결과를 따로 기록합니다.

남길 것 ‘유지할 규칙 / 바로잡을 오류 / 아직 결정하지 않은 항목’을 분리하고 업무 확인자를 정합니다.

04읽는 작업과 바꾸는 작업의 경계를 그립니다

조회 화면도 접근 기록을 쓰거나 외부 서비스를 호출할 수 있습니다. API 이름이나 화면의 버튼 이름만 보고 읽기 전용이라고 가정하지 않습니다. 공유 테이블, 트리거, 저장 프로시저, 배치와 외부 연동이 어디서 데이터를 바꾸는지 확인합니다.

• 같은 데이터를 쓰는 시스템과 최종 기준이 되는 시스템을 구분합니다.
• 실패한 작업의 재시도 방식과 중복을 판별하는 기준을 확인합니다.
• 신·구 시스템 비교 실행 중 결제·이메일·문자·재고 반영이 두 번 실행되지 않게 시험 환경과 외부 전송을 분리합니다.

남길 것 읽기·쓰기 경로, 데이터 소유 시스템, 외부 부작용, 재처리 담당자가 표시된 간단한 흐름도입니다.

05AI에 맡길 일과 공유할 자료의 범위를 정합니다

AI는 코드 흐름 설명, 의존 관계 후보 정리, 테스트 초안과 변경안 작성에 활용할 수 있습니다. 결과를 업무 규칙의 정답으로 채택하거나 바로 운영에 반영하지 않고, 코드·실행 결과·담당자 검토와 대조합니다.

• 자료: 필요한 코드·스키마·로그 구간만 선별하고 개인정보·고객 식별값·기밀 업무 내용을 확인합니다.
• 비밀정보: 비밀번호, 토큰, 키, 연결 문자열을 제거합니다. 마스킹 후에도 식별이나 추론이 가능한지 검토합니다.
• 도구 조건: 사용할 제품·계정의 데이터 보존, 학습 사용, 처리 위치, 접근 권한과 계약 조건을 확인합니다.
• 승인: 고객 보안 기준에서 자료 반출과 도구 사용이 허용되는지 확인하고, 허용 범위가 불명확하면 공유 전에 정합니다.

OWASP는 로그에 비밀번호·토큰·연결 문자열 등을 그대로 남기지 않도록 권고하며, LLM의 기밀정보 노출 위험에는 데이터 최소화와 접근 통제를 함께 다룹니다. ‘비밀을 공개하지 말라’는 프롬프트만으로 보호를 보장할 수는 없습니다. [1] [2]

남길 것 자료별 공유 가능 범위, 사용할 도구·환경, 검토 담당자와 결과물 보관 기준입니다.

06성능 수치와 함께 결과의 정확성을 검증합니다

‘더 빨라졌다’는 비교에는 조건이 필요합니다. 입력, 데이터 규모, 권한, 동시 요청, 캐시 상태를 기록하고 같은 조건에서 전후를 비교합니다. 평균 응답시간만 보지 말고 합계·건수·정렬·조회 범위와 예외 처리도 확인합니다.

테스트는 현행 오류까지 고정하지 않도록 앞서 합의한 업무 규칙을 기준으로 검토합니다. AI가 만든 코드와 테스트도 같은 검토 대상입니다. NIST SSDF v1.1은 코드 검토·분석과 실행 테스트, 결과 및 발견 사항의 문서화를 다룹니다. [3]

남길 것 정상·예외·권한 시나리오와 기대 결과, 비교 조건, 미해결 차이 목록입니다.

07백업 파일이 아니라 복구 가능한 상태를 확인합니다

애플리케이션을 이전 버전으로 되돌려도 이미 변경된 데이터나 전송된 외부 요청은 남을 수 있습니다. 코드 복귀, 데이터 복원, 외부 처리의 취소·보정 방법을 각각 정합니다.

• 격리 환경에서 백업을 복원하고 핵심 조회·계산·연동 상태를 확인합니다.
• 허용할 중단 시간과 데이터 손실 범위를 업무 담당자와 정하고 복구에 필요한 실제 시간을 확인합니다.
• 전환 중 새로 들어온 데이터의 보존·재처리 방법을 정합니다. 과거 백업 복원이 최근 정상 거래를 지울 가능성도 검토합니다.
• 전환 중단 기준, 판단권자, 복구 실행자와 연락 경로를 명시합니다.

남길 것 복구 리허설 결과와 전환 점검표입니다. 복구가 확인되지 않은 변경은 운영 반영의 선행 과제로 남깁니다.

08첫 변경은 효과와 검증 범위를 함께 좁힙니다

영향을 설명할 수 있고 전후 결과를 비교할 수 있는 업무부터 범위를 정합니다. 조회 성능 개선, 특정 배치의 오류 처리처럼 경계가 분명한 후보를 검토하되, 숨은 쓰기 작업과 공통 DB 의존성을 먼저 확인합니다.

기능을 나눠 신·구 시스템을 공존시키는 Strangler Fig 패턴은 점진적 교체의 한 방법입니다. 다만 요청 경로를 분리할 수 없거나 필요한 기존 기능을 수정할 수 없는 경우, 또는 구 시스템을 빨리 폐기해야 하는 경우에는 적합하지 않을 수 있습니다. 별도 운영 비용과 공통 데이터의 일관성도 함께 검토해야 합니다. [4]

남길 것 이번에 바꿀 것·바꾸지 않을 것, 선행 확인 사항, 완료 기준, 전환·복구 범위입니다. 전면 재구축 여부도 이 근거를 보고 결정합니다.

착수 회의에서 바로 쓰는 정리 양식

모르는 항목은 빈칸으로 두지 말고 ‘미확인’이라고 적습니다. 특히 결과의 정확성, 쓰기 경로, 복구 절차에 영향을 주는 미확인 항목은 일정과 범위에 반영합니다.

대상 업무와 문제

누가 어떤 조건에서 불편을 겪는가? 재현 가능한 입력은 무엇인가?

현재 확인한 근거

화면·코드 위치·마스킹한 로그·시험 결과 중 무엇이 있는가?

바뀌면 안 되는 규칙

계산, 권한, 데이터 상태, 외부 전달 중 어떤 결과를 유지해야 하는가?

미확인 항목

영향받는 업무 / 확인 담당자 / 다음 확인 방법 / 확인 전 보류할 변경

첫 변경과 완료 기준

이번 범위, 제외 범위, 검증 조건, 승인 담당자는 누구인가?

전환과 복구

반영 가능 시간, 중단 조건, 복구 방법, 데이터 보정 책임자는 누구인가?

이 정도가 정리되면 개발 범위와 불확실성을 나눠 이야기할 수 있습니다. 자료가 부족하다면 자료 확보와 현행 분석부터 별도 범위로 정하는 편이 명확합니다.