개념
왜 지금 역분석인가
오래 운영된 IT 시스템에는 공통점이 있다. 코드는 매주 바뀌었지만 요구사항명세서는 첫 오픈 때 그대로다. 규칙을 아는 사람은 퇴사했고, 남은 것은 코드·DB·화면·운영 로그뿐이다. 이런 시스템을 새 기술로 옮기거나(현대화), AI 에이전트가 안전하게 수정하게 하려면 먼저 "이 시스템이 지금 무엇을 하는가"를 문서로 꺼내야 한다. 이것이 역분석(reverse engineering) 이다.
역분석은 새 기술이 아니지만 생성형 AI가 비용 구조를 바꿨다. AWS Transform for mainframe은 COBOL·JCL·Db2 같은 산출물을 분석해 프로그램 문서와 비즈니스 규칙을 추출하는 기능을 내세우고, 공식 문서에서 도메인 분해·이관 계획 같은 중간 산출물에 사람의 승인(HITL) 을 받는 지점을 명시한다. 2026년 학계의 Reversa 프레임워크는 표면 매핑 → 모듈 분석 → 암묵 규칙 추출 → 아키텍처 종합 → 명세 작성 → 주장 검토를 여러 에이전트로 나누고, 출처 추적·신뢰도 표시·공백 보존을 핵심 장치로 제시했다.
QA에게 이 흐름이 중요한 이유는 하나다. 복원된 문서는 곧 test basis가 된다. 틀린 복원 문서로 테스트를 설계하면 틀린 동작을 정답으로 고정하는 테스트가 만들어진다.
산출물별로 복원되는 것과 안 되는 것
| 산출물 | 복원되는 것 | 복원되지 않는 것 |
|---|---|---|
| 소스 코드 | 분기 조건, 계산식, 검증 규칙, 호출 흐름 | 그 조건을 둔 이유, 예외 처리의 업무적 의미 |
| DB 스키마·제약 | 엔터티·관계, 필수값, 코드 테이블 값 | 쓰이지 않는 컬럼인지, 값의 업무 정의 |
| DB 데이터 분포 | 실제 쓰이는 코드 값, 상태 전이 빈도 | 드물지만 중요한 예외 경로 |
| 화면(UI) | 입력 필드·필수 표시·버튼·메시지 | 화면에 숨은 권한·서버 검증 |
| 운영 로그 | 실제 호출 순서, 오류 빈도, 사용 패턴 | 한 번도 실행되지 않은 경로 |
| 배치·설정 | 실행 주기, 마감 시각, 임계값 | 값을 정한 근거 |
오른쪽 열은 공통적으로 의도 다. 산출물은 "무엇을"은 말해 주지만 "왜"는 거의 말해 주지 않는다. 그래서 역분석은 여러 산출물을 교차 시켜야 한다. 코드에만 있고 로그에 한 번도 안 나타나는 분기는 죽은 코드일 수도, 1년에 한 번 도는 결산 경로일 수도 있다.
결정적 분석과 LLM의 분업
AI 역분석이라 해서 LLM에 코드를 통째로 넣는 것이 아니다. 실무에서는 두 층으로 나눈다.
| 층 | 담당 | 하는 일 | 성질 |
|---|---|---|---|
| 결정적 분석 | 파서·정적 분석기·SQL | 호출 그래프, 변수 흐름, 테이블 접근 목록, 분기 조건 추출 | 빠뜨림은 있어도 지어내지 않는다 |
| 해석·서술 | LLM | 추출된 조건을 업무 언어로 서술, 규칙 묶기, 용어 정리 | 읽기 좋지만 지어낼 수 있다 |
AWS의 설명도 비즈니스 규칙 추출이 주석이나 명명 규칙보다 실행 로직에서 직접 규칙을 끌어내는 결정적 정적 분석에 기반한다고 강조한다.
원칙은 이렇다. 사실은 결정적 분석이 뽑고, LLM은 그 사실을 사람이 읽을 문장으로 바꾼다. LLM이 사실을 만드는 순간 근거 없는 규칙이
섞인다. 변수 이름이 discount_rate 라는 이유만으로 "할인율"이라 서술했는데 실제로는 수수료율이었다는 식이다.
모든 주장에 출처를 단다
복원 문서의 품질을 가르는 단 하나의 장치는 주장 단위 출처 표기 다. 문단 끝에 "출처: OrderService.java"라고 쓰는 것으로는 부족하다. 규칙 한 줄마다 근거 위치와 신뢰도를 붙인다.
[BR-ORD-017] 주문 금액이 50,000원 이상이면 배송비를 면제한다.
근거: src/order/OrderService.java:212-219 (if (total >= FREE_SHIP_THRESHOLD))
src/config/order.properties:8 (FREE_SHIP_THRESHOLD=50000)
로그 2026-09 주문 18,402건 중 배송비 0원 9,877건, 전부 50,000원 이상
신뢰도: 높음 (코드·설정·데이터 일치)
상태: 미확인 (도메인 담당 확인 전)
[BR-ORD-018] 도서 상품은 금액과 무관하게 배송비를 면제한다.
근거: src/order/OrderService.java:221 (if (item.category == "B01"))
신뢰도: 중간 ("B01" 이 도서라는 근거는 코드 테이블 주석 하나뿐)
상태: 질문 Q-07 로 등록신뢰도는 근거 수와 일치 여부로 정한다.
| 신뢰도 | 조건 |
|---|---|
| 높음 | 코드와 다른 산출물(설정·데이터·화면·로그) 둘 이상이 일치 |
| 중간 | 코드 근거는 있으나 업무 의미 해석이 하나의 단서에 의존 |
| 낮음 | LLM 추론에 주로 의존, 또는 산출물 간 불일치 |
| 공백 | 근거를 찾지 못함 — 지우지 말고 "모름"으로 남긴다 |
마지막 줄이 중요하다. Reversa 논문이 공백 보존 을 별도 장치로 둔 이유다. LLM은 빈칸을 그럴듯한 문장으로 메우는 경향이 있다. "모름"이 문서에 남아 있어야 사람이 거기에 질문을 던진다. 사례 연구에서도 수백 개의 신뢰도 등급 주장과 함께 문서화된 공백 목록을 따로 산출했고, 최종 검증은 미완으로 남았다고 스스로 밝힌다. 이 정직함이 복원 문서가 갖춰야 할 태도다.
현재 동작은 의도된 요구가 아니다
역분석의 가장 큰 함정이다. 코드에서 복원한 규칙은 현재 동작 이다. 현재 동작에는 의도된 요구, 우연히 생긴 동작, 그리고 결함 이 섞여 있다. AI는 셋을 구분하지 못하고 전부 같은 어조의 "규칙"으로 서술한다.
// OrderService.java:240
if (coupon.expiryDate.after(today)) { // 만료일 "당일" 은 사용 불가
applyCoupon(coupon);
}LLM은 이것을 "쿠폰은 만료일 전날까지 사용할 수 있다"로 깔끔하게 서술한다. 그런데 약관은 "만료일까지 사용 가능"이다. 이 코드는 경계값 결함이다(모듈 3의 경계값 분석). 복원 문서가 이를 규칙으로 적고, 그 문서로 새 시스템을 만들고, 그 문서로 테스트를 설계하면 결함이 명세로 승격 된다.
그래서 복원된 규칙마다 분류 칸을 둔다.
| 분류 | 의미 | 처리 |
|---|---|---|
| 의도 | 업무 담당이 맞다고 확인 | test basis로 채택 |
| 우연 | 아무도 의도하지 않았으나 사용자가 의존할 수 있음 | 유지 여부를 기획이 결정 |
| 결함 후보 | 약관·정책·상식과 어긋남 | 결함으로 등록, 새 시스템에 옮기지 않음 |
| 불명 | 판단 근거 없음 | 질문 목록으로 |
QA가 여기서 하는 일은 복원 문서를 읽으며 "이건 결함 아닌가?"를 묻는 것이다. 경계값·상태 전이·권한·금액 계산처럼 결함이 잘 숨는 곳을 아는 사람이 이 질문을 가장 잘 던진다. 역분석은 문서화 작업이면서 동시에 대규모 정적 리뷰 다.
도메인 담당자 확인 루프
복원 문서를 완성하는 마지막 단계는 사람이다. 다만 "문서 300쪽 검토 부탁드립니다"는 실패한다. 아무도 읽지 않는다. 확인 루프는 질문 으로 설계한다.
[Q-07] 상품 분류 "B01" 은 도서입니까? 도서는 금액과 무관하게 배송비가 면제됩니까?
배경: OrderService.java:221 에 B01 분기가 있고, 2026-09 해당 주문 412건 전부 배송비 0원
선택지: (a) 맞다 (b) 도서는 맞지만 면제 조건이 다르다 (c) B01 은 도서가 아니다 (d) 모르겠다 → 다른 담당자 추천
영향: BR-ORD-018, 테스트 조건 TC-SHIP-04~06좋은 질문의 조건은 네 가지다. 예/아니오나 선택지로 답할 수 있고, 근거가 함께 있고, 답이 어떤 규칙과 테스트에 영향을 주는지 보이고, "모르겠다"를 허용한다. 질문은 신뢰도 낮음·공백·결함 후보에서 우선 뽑는다. 신뢰도 높음 규칙까지 전부 물으면 담당자의 시간이 진짜 질문에 쓰이지 않는다.
확인 결과는 문서에 다시 반영된다. 상태는 미확인 → 확인됨 / 수정됨 / 결함 등록 / 보류로 옮겨 가고, 누가 언제 확인했는지 남긴다. 이 기록이 쌓여야 복원 문서가 "AI가 쓴 초안"에서 "조직이 승인한 명세"로 바뀐다.
복원 문서를 테스트로 검증하기 — 특성화 테스트와 동등성 테스트
문서를 사람만 검증하면 한계가 있다. 복원된 규칙이 실제로 그렇게 동작하는지 실행 해서 확인한다.
특성화 테스트(characterization test) 는 레거시 코드의 현재 동작을 그대로 기록하는 테스트다. "옳은가"가 아니라 "지금 이렇게 하는가"를 고정한다. 복원 규칙 하나마다 특성화 테스트를 붙이면, 규칙 서술이 틀렸을 때 테스트가 실패해 알려 준다.
# BR-ORD-017 특성화
Scenario: 주문 금액 50,000원이면 배송비 면제
Given 일반 상품 50,000원을 장바구니에 담는다
When 주문서를 연다
Then 배송비는 0원이다
Scenario: 주문 금액 49,999원이면 배송비 부과
Given 일반 상품 49,999원을 장바구니에 담는다
When 주문서를 연다
Then 배송비는 3,000원이다현대화 프로젝트에서는 같은 시나리오를 구 시스템과 신 시스템에 동시에 돌려 결과를 비교하는 동등성(parity) 테스트 로 확장한다. Reversa 사례에서도 COBOL에서 Go로 옮기며 Gherkin 형식의 동등성 시나리오를 산출물로 만들었다. 주의할 점은 결함 후보로 분류한 규칙이다. 그 규칙의 동등성 테스트는 "신 시스템도 같게"가 아니라 "신 시스템은 다르게" 를 기대해야 한다. 결함까지 동등하게 옮기는 것은 현대화가 아니라 복사다.
데이터와 보안 — 역분석 입력의 위험
역분석은 운영 DB 데이터 분포와 운영 로그를 입력으로 쓴다. 여기에는 개인정보와 영업 비밀이 들어 있다. 외부 LLM에 그대로 넣기 전에 확인할 것들이 있다.
| 확인 항목 | 이유 |
|---|---|
| 개인정보 마스킹 또는 통계 요약만 전달 | 원본 행을 넣지 않아도 분포·빈도는 충분하다 |
| 소스 코드 반출 승인 | 사내 코드의 외부 전송은 보안 정책 대상 |
| 처리 리전과 보관 정책 | 일부 서비스는 다른 리전에서 처리될 수 있다고 공식 문서에 명시한다 |
| 비밀정보 스캔 | 설정 파일에 남은 비밀번호·키가 프롬프트로 흘러간다 |
실무에서 왜 필요한가
차세대 시스템 구축이나 클라우드 전환 프로젝트에서 QA가 가장 먼저 부딪히는 문제는 "무엇이 정답인가"다. 구 시스템 문서는 낡았고, 현업은 "지금처럼 되면 된다"고 말한다. 그런데 "지금처럼"의 목록이 없다. AI 역분석은 그 목록을 몇 주 안에 만들어 주지만, 출처와 신뢰도와 분류가 없는 목록은 위험한 정답지다.
QA가 이 레슨의 장치를 갖고 들어가면 역할이 바뀐다. 복원 문서를 받아 테스트만 짜는 사람이 아니라, 복원 문서의 각 규칙이 의도인지 결함인지를 가려 어떤 동작을 새 시스템에 옮길지 결정하는 회의를 이끄는 사람이 된다. 결함을 명세로 승격시키지 않는 것, 이것만으로도 현대화 프로젝트의 오픈 후 결함을 크게 줄일 수 있다.