질문의 역사: 기업 현대화 이니셔티브에서, 비즈니스 분석가는 종종 지식 감소에 직면합니다. 이는 중요한 비즈니스 논리가 읽을 수 없는 레거시 코드에만 남아 있는 현상입니다. 이 질문은 원래의 설계자가 수십 년 전에 은퇴한 메인프레임-클라우드 마이그레이션에서 발생했습니다. 그들은 완벽하게 실행되지만 해석하기 힘든 COBOL 프로그램을 남겼습니다. 역사적인 맥락은 단일 배치 처리에서 분산 마이크로서비스로의 전환을 포함하며, 여기서 암묵적인 상태 관리는 명시적인 API 계약으로 변화해야 합니다.
문제는 인식의 불투명성에 중심을 두고 있습니다: 시스템이 작동하지만 이유는 아무도 모릅니다. COBOL 코드베이스에는 암묵적인 비즈니스 규칙 — 경계 사례, 규제 패치 및 수동 재저장 — 가 포함되어 있으며, 이는 원래 개발자들이 기억 속에 보유하고 있었기 때문에 문서화되지 않았습니다. 현재 운영 직원들은 입력과 출력을 이해하고 있지만 결정 논리는 이해하지 못합니다. 한편, 새로운 클라우드 네이티브 아키텍처는 이러한 규칙이 분리되어 문서화되고 실시간 소비를 위해 REST 엔드포인트를 통해 노출되어야 합니다. 고정된 규제 기한은 수년 간의 고고학적 발굴을 방지하지만, 규칙 추출의 오류는 GDPR 데이터 처리 규정이나 재무 보고 정확도를 위반할 수 있습니다.
해결책은 삼각 역설정 접근 방식을 사용합니다. 첫째, 운영 직원과 함께 이벤트 스토밍 워크숍을 수행하여 관찰 가능한 비즈니스 행동을 맵하고 "블랙 박스" 프로세스를 식별합니다. 둘째, 정적 코드 분석 도구를 사용하여 COBOL 프로그램의 제어 흐름 그래프를 생성하고 변수 변이를 비즈니스 결과와 대조합니다. 셋째, 병렬 실행 그림자 모드를 구현하여 새로운 마이크로서비스 프로세스가 레거시 시스템 대비 거래를 미러링하여 생산에 영향을 주지 않으면서 불일치를 조사하도록 플래그를 지정합니다. 이는 코드 고고학이 이해관계자의 기억을 검증하고 이해관계자 맥락이 코드 이상을 설명하는 피드백 루프를 생성합니다.
지역 보험회사는 1980년대 COBOL 정책 평가 엔진을 Python/FastAPI 마이크로서비스 세트로 교체해야 했습니다. 이는 실시간 모바일 견적을 가능하게 하기 위함입니다. 원래 계산 논리는 복잡한 영토 위험 가중치, 계절 조정 요소, 그리고 40년 이상 패치된 재보험 조항을 포함하고 있었습니다. 세 명의 남은 COBOL 개발자는 퇴직했으며, 현재 IT 직원들은 이 시스템을 "마법의 상자"로 간주하며 정확한 보험료를 산출하지만 특정 경계 사례에 대한 수학적 유도 과정을 설명할 수 없었습니다. 규제 기관은 지원되지 않는 인프라 과태료를 피하기 위해 8개월 이내에 마이그레이션 완료를 의무화했습니다.
요구 사항을 캡처하기 위해 여러 접근 방식이 평가되었습니다. 첫 번째 옵션은 개발자들이 COBOL 소스의 모든 IF 문과 MOVE 작업을 수동으로 문서화하는 코드-사양 필사를 제안했습니다. 장점은 이론적 완전성과 정확한 논리의 보존이었습니다. 단점은 심각했습니다: 코드베이스는 문서화되지 않은 전역 변수가 있는 200만 줄이 넘는 스파게티 코드로 구성되어 있어서 이 작업은 수년이 걸리고 기한을 놓치며 필사 오류가 발생할 가능성이 높았습니다.
두 번째 옵션은 입력(정책 속성)과 출력(보험료 금액)을 관찰하여 규칙을 통계적 회귀를 통해 유추하는 블랙 박스 요구 사항 파생을 제안했습니다. 장점은 속도와 현재 비즈니스 가치에 초점을 맞추는 것이었습니다. 단점은 드문 청구 시나리오의 비활성 코드 경로를 감지할 수 없으며, 버그를 기능으로 잘못 정의할 위험이 있다는 것입니다.
세 번째 옵션은 병행 검증을 통한 행동 고고학으로, 5년 간의 생산 로그에서 샘플 데이터를 추출하고 실제 거래로부터 결정 트리를 구축하며, 이를 자동화된 diff 도구를 사용하여 COBOL 소스와 비교하여 검증하는 것을 포함했습니다.
팀은 속도와 정확성을 균형 있게 유지하면서 포괄적인 문서화보다 작동 소프트웨어를 우선시하는 애자일 원칙을 준수했기 때문에 세 번째 솔루션을 선택했습니다. 그들은 실행된 코드 경로에 중점을 두어 비활성 기능을 줄이고, 활성 비즈니스 규칙이 정확하게 캡처되도록 보장했습니다. 그들은 익명화된 역사적 거래를 포함한 데이터 레이크를 구축하고, 이를 레거시 JCL 작업 및 새로운 FastAPI 서비스에 투입하여 0.01% 이상의 보험료 계산 불일치를 자동으로 조사했습니다. 이를 통해 세 가지 중요한 문서화되지 않은 조건이 드러났습니다: 1992년 이전에 발급된 플로리다 정책에 대한 허리케인 면책 조항, 퇴직 에이전트에 대한 특별 수수료 계산, 수십 년 동안 수동 스프레드시트 조정에 의해 "수정된" 분기별 세금 보고서의 반올림 오류. 마이크로서비스는 이러한 경계 사례를 하드코딩된 상수가 아닌 구성 가능한 비즈니스 규칙으로 명시적으로 처리하도록 다시 설계되었습니다.
레거시 코드를 역설계할 때, 마이그레이션 중에 안전하게 제거할 수 있는 기술적 우회와 중요한 비즈니스 제약 사항을 어떻게 구분하나요?
후보자들은 종종 모든 기존 논리가 현재의 비즈니스 목적을 위해 존재한다고 착각하며, 레거시 보존의 매몰 비용 오류에 빠집니다. 올바른 접근법은 시간적 맥락 분석입니다: 코드 변경의 날짜 스탬프를 검토하여 알려진 규제 변경, 합병, 또는 더 이상 존재하지 않는 기술적 제한과 연관시킵니다. 예를 들어, COBOL의 데이터 잘림 루틴은 원래 DB2 스키마가 고정 너비 필드를 사용했기 때문에 존재할 수 있지만, 현대의 PostgreSQL은 가변 길이 문자열을 지원하므로 잘림 규칙의 필요성이 완전히 제거됩니다. BAs는 비즈니스 이해관계자와 의도 검증 세션을 수행하여 의심되는 우회를 "X를 제거하여 간소화할 수 있습니다; 이것이 귀하의 컴플라이언스에 영향을 미치나요?"라기보다는 "X를 유지해야 할까요?"라고 제시해야 합니다. 이는 필요성보다 보존의 부담을 이전시킵니다.
새 시스템이 단지 기존의 COBOL 단일 실체에서 존재하기 때문에 비효율적인 배치 처리 워크플로우를 복제하는 "카고 컬트" 반패턴을 어떻게 방지하나요?
많은 후보자들은 기능적 동등성에만 집중하여 프로세스 재설계를 간과합니다. 실패는 BAs가 현재 상태(예: "시스템이 매일 새벽 2시에 배치를 실행합니다")를 미래 상태의 요구 사항으로 문서화할 때 발생하며, Apache Kafka 또는 RabbitMQ와 같은 이벤트 기반 아키텍처가 실시간 처리를 가능하게 한다는 사실을 무시합니다. 해결책은 능력 매핑입니다: "무엇"(위험 계산이 발생해야 함)과 "어떻게"(배치 대 스트리밍)를 분리합니다. BAs는 가치 흐름 맵핑을 수행하여 운영의 편의성을 위해 서비스된 비즈니스 규칙이 아닌 배치 일정의 대기 시간을 식별해야 합니다. REST 엔드포인트가 인수인계 발생 시간을 24시간에서 30초로 단축시킬 수 있음을 입증함으로써, 그들은 이전 시스템과 너무 다르다고 거부될 수 있는 아키텍처 변경을 정당화합니다.
"알 수 없는 알 수 없는 것들"의 위험을 정량화하고 전달하는 당신의 방법론은 무엇인가요? 즉, 샘플 데이터 관찰 기간 동안에는 발동되지 않았지만 마이그레이션 이후에 파국적으로 드러날 수 있는 암묵적 규칙들입니다.
후보자들은 종종 역사적 데이터에 대해 100% 테스트 통과율을 기반으로 이해관계자에게 잘못된 신뢰를 제공합니다. 정교한 답변은 레거시 데이터의 샘플링 편향을 인식하고 합성 시나리오에 대한 스트레스 테스트를 옹호합니다. 이는 생산 로그에서 보지 못한 경계 조건을 처리하는 퍼징된 입력 데이터를 생성하고, COBOL과 새로운 시스템 출력 결과를 비교하는 것을 포함합니다. 또한, BAs는 새로운 아키텍처에 서킷 브레이커 패턴을 설정해야 합니다: 마이크로서비스가 처리할 수 없는 거래 구조를 만날 경우(잠재적인 누락된 규칙을 나타냄), 이것은 원활하게 레거시 SOAP 래퍼를 호출하거나(가능한 경우) 사람의 검토를 위해 플래그를 지정해야 하며, 침묵 속에 실패하거나 널 값을 기본으로 설정해서는 안 됩니다. 커뮤니케이션 전략은 95%의 규칙이 검증되지만 5%의 잔여 불확실성이 필요하다는 것을 보여주는 확률적 위험 매트릭스를 포함하며, 이는 세 달의 하이퍼케어 기간과 두 배의 수동 재조정 검사를 필요로 합니다.