181. 역공학을 통한 요구사항 추출

핵심 인사이트 (3줄 요약)

본질: 역공학을 통한 요구사항 추출은 문서가 없거나 신뢰할 수 없을 때, 기존 시스템의 코드·데이터·화면·인터페이스·운영 흔적을 분석해 현재 요구사항 AS-IS (현재 상태)를 복원하는 작업이다.

가치: 차세대 구축, 클라우드 전환, 패키지 교체 같은 프로젝트에서 숨은 비즈니스 규칙과 연계 조건을 놓치지 않게 해 마이그레이션 실패 위험을 크게 줄인다.

판단 포인트: 코드가 보여 주는 것은 "무엇을 하고 있는가"이지 "왜 계속 유지해야 하는가"가 아니므로, 정적 분석·동적 분석·현업 검증을 함께 사용해 유지/개선/폐기를 구분해야 한다.

Ⅰ. 개요 및 필요성

역공학을 통한 요구사항 추출은 완성된 시스템의 증거를 거꾸로 읽어 요구사항을 복원하는 기법이다. 일반적인 요구공학이 사람과 문서를 출발점으로 미래 시스템을 정의한다면, 이 방법은 이미 운영 중인 시스템을 출발점으로 현재 시스템의 규칙을 파헤친다. 그래서 특히 레거시 현대화, 벤더 교체, 소스 전환, 규제 대응 프로젝트에서 자주 등장한다.

이 기법이 필요한 가장 큰 이유는 현실에서 문서가 자주 사라지거나 낡기 때문이다. 요구사항 명세서는 초기 버전에서 멈춰 있고, 실제 비즈니스 규칙은 수년간 유지보수된 코드와 배치 스크립트 안에만 살아 있는 경우가 많다. 이때 인터뷰만 믿으면 현업도 잊어버린 예외 규칙을 놓치고, 코드만 믿으면 오래전에 사라진 업무 흔적까지 필수 요구로 오해할 수 있다. 그래서 역공학은 증거 기반 복원과 의도 검증이 함께 가야 한다.

아래 그림은 운영 중 시스템의 흔적이 어떻게 요구사항 후보로 수렴되는지를 보여 준다.

┌────────────────────────────────────────────────────────────────────┐
│ Evidence to requirement pipeline                                  │
├────────────────────────────────────────────────────────────────────┤
│ source code ─┐                                                     │
│ DB schema   ─┼─> static / dynamic / data analysis -> candidate req│
│ screens     ─┤                                                     │
│ logs/jobs   ─┘                                                     │
│                                        │                           │
│ stakeholder review <-------------------┘                           │
│                                        ▼                           │
│                                  AS-IS requirement baseline        │
└────────────────────────────────────────────────────────────────────┘

이 구조의 핵심은 산출물이 곧바로 최종 요구사항이 아니라는 점이다. 먼저 시스템에서 관찰된 행동을 모으고, 그다음 현업과 아키텍트가 그것이 여전히 필요한지 판단해 유효한 요구사항으로 정제해야 한다. 따라서 역공학은 단순 분석이 아니라, 증거를 요구사항 언어로 번역하는 작업이다.

📢 섹션 요약 비유: 역공학 기반 요구사항 추출은 설계도가 사라진 오래된 기계를 분해해, 어떤 부품이 왜 움직이는지 보고 원래 사용 설명서를 다시 써 내려가는 작업과 같다.

Ⅱ. 아키텍처 및 핵심 원리

역공학의 핵심 원리는 다양한 증거원을 겹쳐 읽어 현재 시스템의 계약을 추론하는 것이다. 코드만 보면 계산 로직은 보이지만 운영 제약은 약하고, 화면만 보면 사용자 흐름은 보이지만 숨은 배치나 인터페이스 조건은 잘 안 보인다. 따라서 요구사항 복원은 보통 정적 분석, 동적 분석, 데이터 분석, 운영 분석을 조합하는 다중 관점 접근이 된다.

증거원	무엇을 알 수 있는가	주의점
소스 코드	조건 분기, 계산식, 예외 처리, 인터페이스 호출	데드 코드와 임시 우회 로직 구분 필요
데이터베이스 스키마	엔터티, 제약조건, 관계, 보존 기간	스키마만으로 업무 의미는 부족
UI (User Interface) / 화면	사용자 입력 항목, 승인 흐름, 필수 검증	숨은 백엔드 규칙 누락 가능
로그·배치·운영 이력	실행 주기, 성능 한계, 실패 패턴, 연계 시간	로그 보존 범위와 표본 편향 주의
API (Application Programming Interface) / 파일 인터페이스	외부 시스템 계약, 포맷, 순서, 응답 규칙	문서와 실제 구현 불일치 가능

실무에서는 이 증거를 세 단계로 다루면 구조가 선명해진다. 첫째, 정적 분석으로 코드 구조와 데이터 구조를 읽어 후보 규칙을 찾는다. 둘째, 동적 분석으로 실제 실행 경로와 사용 빈도를 확인한다. 셋째, 현업 검증으로 그 규칙이 현재도 필요한지, 법규나 정책상 유지해야 하는지 확인한다. 이 셋이 맞물려야 "구현 흔적"이 "요구사항"으로 승격된다.

다음 그림은 역공학의 핵심이 단순 추출이 아니라, 추출 후 분류와 검증까지 포함한다는 점을 보여 준다.

┌────────────────────────────────────────────────────────────────────┐
│ Reverse engineering core loop                                     │
├────────────────────────────────────────────────────────────────────┤
│ observe implementation -> infer rule -> validate intent            │
│          ▲                    │                 │                  │
│          │                    ▼                 ▼                  │
│   logs / traces       candidate requirement   keep / change / drop│
│                                                                    │
│ code shows "what exists"; stakeholders confirm "why it matters"   │
└────────────────────────────────────────────────────────────────────┘

여기서 가장 중요한 문장은 이것이다. 현재 구현은 요구사항의 흔적이지, 요구사항 그 자체와 항상 동일하지는 않다. 오래된 우회 로직, 특정 고객만을 위한 예외, 이미 폐기된 정책이 코드에 남아 있을 수 있기 때문이다. 그래서 역공학은 복원 작업인 동시에, 불필요한 것을 걸러내는 정제 작업이기도 하다.

📢 섹션 요약 비유: 오래된 식당 주방을 보고 레시피를 복원할 때, 냄비에 남아 있는 재료만 보는 것이 아니라 실제 손님이 무엇을 주문하는지와 셰프가 왜 그렇게 조리하는지까지 함께 확인해야 진짜 레시피가 나온다.

Ⅲ. 비교 및 연결

역공학을 통한 요구사항 추출은 다른 요구공학 기법과 경쟁 관계라기보다 출발점이 다른 보완 기법이다. 순방향 공학 (Forward Engineering)은 요구사항에서 설계와 구현으로 내려가고, 역공학은 구현에서 요구사항으로 올라온다. 재공학 (Re-engineering)은 이 둘을 연결해 기존 시스템을 분석한 뒤 구조나 기술을 개선해 다시 구현하는 큰 흐름이라고 볼 수 있다.

구분	출발점	주된 질문	강점	한계
순방향 공학	비즈니스 목표, 인터뷰, 정책	무엇을 새로 만들 것인가?	미래 지향 설계에 강함	현행 누락 위험
역공학	코드, DB, 화면, 로그	현재는 실제로 무엇을 하는가?	숨은 규칙 발견에 강함	의도와 우선순위는 약함
재공학	기존 시스템 + 목표 상태	무엇을 유지·개선·대체할 것인가?	현대화 로드맵에 강함	분석과 설계 비용 큼

이 기법은 AS-IS (현재 상태) / TO-BE (목표 상태) 분석과도 긴밀하게 연결된다. 역공학은 우선 AS-IS를 복원하는 데 탁월하고, 그 결과를 바탕으로 어느 규칙은 유지하고 어느 기능은 버릴지 TO-BE 설계를 진행할 수 있다. 또한 산출물은 SRS (Software Requirements Specification)나 RTM (Requirements Traceability Matrix)으로 연결되어야 이후 설계·테스트·이관 검증이 가능해진다.

따라서 좋은 프로젝트는 "역공학만" 하지 않는다. 역공학으로 현행을 복원하고, 인터뷰와 워크숍으로 의도를 확인하고, TO-BE 설계에서 변화 목표를 명확히 한다. 이 세 단계가 이어질 때 비로소 차세대 프로젝트가 현행 복제도 아니고 공상 설계도 아닌 실질적 개선으로 이어진다.

📢 섹션 요약 비유: 역공학은 현재 집 구조를 실측하는 일이고, 순방향 공학은 새 집 설계도를 그리는 일이며, 재공학은 실측 결과를 보고 어디를 허물고 어디를 살릴지 정하는 리모델링 계획과 같다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 역공학 기반 요구사항 추출은 보통 차세대 전환의 첫 관문이다. 예를 들어 노후 금융 시스템을 웹 기반 플랫폼으로 바꾸는 프로젝트라면, 화면 흐름만 보고 이관하면 정산 기준시각, 예외 이자 계산, 배치 마감 순서, 연계 파일 포맷 같은 핵심 규칙을 놓치기 쉽다. 반대로 코드만 그대로 베껴 오면 이미 사라진 업무를 쓸데없이 복제할 수 있다. 따라서 실무 판단은 "무엇을 발견했는가"보다 그것을 유지·개선·폐기 중 어디에 놓을 것인가에 있다.

실무 절차

핵심 업무 흐름과 인터페이스를 우선순위로 정한다.
코드·DB·화면·배치·로그를 교차 분석해 요구사항 후보를 만든다.
후보를 기능 요구사항과 비기능 요구사항으로 구분한다.
현업과 검증해 유지/개선/폐기 여부를 확정한다.
결과를 SRS, 유스케이스, RTM, 테스트 케이스로 연결한다.

아래 결정 흐름은 관찰된 동작을 그대로 요구사항으로 채택하지 않고, 사업적 의미를 다시 묻는 과정을 보여 준다.

┌────────────────────────────────────────────────────────────────────┐
│ Classifying observed behavior                                     │
├────────────────────────────────────────────────────────────────────┤
│ observed rule from code/logs                                      │
│   ├─ still required by business or regulation? -> retain          │
│   ├─ workaround for old platform? -> redesign                     │
│   ├─ unused path / dead code / obsolete data? -> retire           │
│   └─ uncertain? -> validate with SME and production evidence      │
└────────────────────────────────────────────────────────────────────┘

실무 판단 기준

기능 요구사항만 보지 않았는가? 응답 시간, 배치 마감 시간, 감사 로그 보존 같은 비기능 요구도 복원해야 한다.
실제 사용 빈도를 봤는가? 코드에 있어도 아무도 쓰지 않는 기능은 후보에서 제외될 수 있다.
연계 계약을 확인했는가? 외부 기관·타 시스템 인터페이스는 작은 포맷 차이도 큰 장애로 이어진다.
추적성을 만들었는가? 복원된 요구가 어느 코드, 어느 로그, 어느 인터뷰에서 나왔는지 남겨야 검증 가능하다.

안티패턴

"현재 구현 = 반드시 유지해야 할 요구사항"이라고 단정하는 것
코드 분석만 하고 운영 로그와 사용자 우회 절차를 보지 않는 것
배치 시간, 처리량, 보존 기간 같은 비기능 요구사항을 놓치는 것
추출된 요구사항을 문서화하지 않아 차세대 설계와 테스트로 연결하지 못하는 것

기술사 답안에서는 반드시 이 점을 강조해야 한다. 역공학의 목적은 현행 시스템을 맹목적으로 복제하는 것이 아니라, 현재 계약을 정확히 복원한 뒤 변화 가능성을 판단하는 데 있다.

📢 섹션 요약 비유: 오래된 가게를 새로 꾸밀 때 진열대 배치와 인기 메뉴는 살리고, 낡은 수기 장부와 임시 박스는 버려야 하듯 역공학도 발견한 것을 모두 가져오는 작업이 아니다.

Ⅴ. 기대효과 및 결론

역공학을 통한 요구사항 추출의 가장 큰 효과는 현행 지식의 증발을 막고 현대화 실패 확률을 낮춘다는 점이다. 문서가 부실한 시스템도 코드와 데이터, 운영 흔적을 근거로 현재 계약을 재구성할 수 있으므로, 기능 누락과 인터페이스 장애를 크게 줄일 수 있다. 또한 복원된 요구사항은 테스트 기준과 이행 검증 기준이 되어, 차세대 시스템이 "비슷해 보이는 새 시스템"이 아니라 의도적으로 설계된 후속 시스템이 되게 한다.

하지만 역공학만으로는 충분하지 않다. 현재 구현은 과거의 제약과 타협이 누적된 결과이므로, 그것을 그대로 미래 상태로 옮기면 기술 부채까지 함께 복제하게 된다. 그래서 좋은 프로젝트는 역공학으로 AS-IS를 정확히 복원한 뒤, 비즈니스 목표와 아키텍처 원칙을 반영해 TO-BE를 다시 설계한다.

정리하면 역공학 기반 요구사항 추출은 **"돌아가는 시스템에서 현재 계약을 복원하는 기술"**이다. 기억할 핵심은 하나다. 보이는 동작을 증거로 수집하되, 유지할 것과 버릴 것을 분리할 때 비로소 진짜 요구사항 공학이 된다.

📢 섹션 요약 비유: 좋은 복원가는 오래된 건물의 벽돌을 하나하나 조사하지만, 금이 간 벽까지 그대로 복제하지는 않는다. 튼튼한 구조는 살리고 낡은 부분은 새롭게 고쳐야 한다.

📌 관련 개념 맵

개념	연결 포인트
레거시 시스템 (Legacy System)	역공학의 대표 출발점이다
AS-IS 분석	현재 상태 복원의 직접 산출물이다
TO-BE 설계	복원된 요구를 바탕으로 미래 상태를 정의한다
정적 분석 (Static Analysis)	코드와 구조에서 규칙 후보를 추출한다
동적 분석 (Dynamic Analysis)	실제 실행 경로와 사용 패턴을 검증한다
RTM (Requirements Traceability Matrix)	복원된 요구사항의 근거와 후속 설계를 연결한다
재공학 (Re-engineering)	역공학 결과를 개선 구현으로 이어 주는 상위 흐름이다

📈 관련 키워드 및 발전 흐름도

문서 부재 또는 문서-구현 불일치
        │
        ▼
코드 · DB · 화면 · 로그 증거 수집
        │
        ▼
정적 분석 · 동적 분석 · 현업 검증
        │
        ▼
AS-IS 요구사항 복원
        │
        ▼
유지 · 개선 · 폐기 분류
        │
        ▼
TO-BE 설계 · SRS · RTM · 차세대 구축

이 흐름도는 역공학이 단순한 코드 읽기가 아니라, 현행 계약 복원에서 미래 설계 입력으로 이어지는 요구공학 프로세스임을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

역공학은 설명서가 없는 장난감을 보고 어떻게 움직이는지 거꾸로 알아내는 일이에요.
하지만 장난감에 붙은 낡은 테이프까지 꼭 필요하진 않은지 다시 생각해 봐야 해요.
그래서 컴퓨터도 옛날 시스템을 살펴본 뒤, 꼭 필요한 규칙만 골라 새 시스템을 만들어요.