181. 역공학을 통한 요구사항 추출 (Requirements Extraction via Reverse Engineering)
핵심 인사이트: 오래된 시스템을 재구축(차세대 프로젝트)해야 하는데 설계도는 없고, 담당자는 퇴사했다. 이때 남은 건 오직 '돌아가고 있는 소스 코드'와 '화면'뿐이다. 결과물(코드)을 뜯어내어 거꾸로 원본 설계(요구사항)를 복원해 내는 마법이 역공학이다.
Ⅰ. 역공학(Reverse Engineering)을 통한 요구사항 추출의 개념
역공학 기반 요구사항 추출은 기존에 운영 중인 레거시(Legacy) 시스템의 소스 코드, 데이터베이스 스키마, 사용자 인터페이스(UI) 등을 분석하여, 시스템이 현재 수행하고 있는 비즈니스 로직과 기능적/비기능적 요구사항을 거꾸로 도출해 내는 기법입니다.
Ⅱ. 역공학이 필요한 상황 (Why?)
- 문서화 부재: 과거 프로젝트의 요구사항 명세서나 설계 문서가 유실되었거나, 잦은 유지보수로 인해 코드와 문서가 불일치할 때.
- 현업의 지식 부족: 업무 담당자가 시스템의 모든 세부 비즈니스 룰(예: 복잡한 이자율 계산 공식)을 알지 못할 때.
- 마이그레이션 / 고도화: 레거시 시스템을 클라우드 네이티브(MSA)로 전환하거나 완전히 새로운 언어(예: C -> Java/Spring)로 재구축할 때 현행 기능(AS-IS)의 100% 이관을 보장하기 위해.
Ⅲ. 역공학을 통한 추출 절차
[ 역공학 요구사항 추출 라이프사이클 ]
(산출물) (역공학 과정) (목표 도출물)
1. Source Code ──▶ 코드 구조 및 제어 흐름 분석 ──▶ 비즈니스 로직 / 알고리즘
2. DB Schema ──▶ 스키마 및 외래키(FK) 분석 ──▶ 데이터 모델 / ERD 복원
3. User Interface──▶ 화면 조작 및 입출력 분석 ──▶ 유스케이스 / UI 요구사항
4. Log / Batch ──▶ 시스템 운영 로그 분석 ──▶ 성능 / 연계 인터페이스 요구사항
Ⅳ. 역공학의 장단점 및 한계점
| 구분 | 설명 |
|---|---|
| 장점 | - 실제 동작하는 시스템을 기반으로 하므로 요구사항 도출의 누락(Omission) 을 최소화할 수 있습니다. - 구두 인터뷰로 알아낼 수 없는 숨겨진 예외 처리나 하드코딩된 정책을 찾아낼 수 있습니다. |
| 단점 및 한계 | - "코드의 의도(Why)"를 알 수 없습니다. 코드가 '어떻게' 동작하는지는 보이지만, 왜 그렇게 만들었는지는 현업 인터뷰(Forward Engineering)와 반드시 교차 검증해야 합니다. - 불필요하게 남아있는 데드 코드(Dead Code)나 오류 로직까지 요구사항으로 잘못 추출될 위험이 있습니다. |
📢 섹션 요약 비유: 유명한 맛집의 비법 레시피(문서)가 불타 없어졌을 때, 요리사가 만든 완성된 찌개(코드)를 맛보고 분해해서 소금 몇 스푼, 고춧가루 몇 스푼 들어갔는지(요구사항)를 거꾸로 역추적해 내는 미식가의 작업과 같습니다.