레거시 시스템 자동화의 특수성: 문서도 API도 없을 때

개념

정찰에서 자동화로

모듈 5(레슨 11)에서 배운 정찰 세션을 떠올려보자 — 문서가 없는 레거시 시스템을 다룰 때, 먼저 "결함을 찾기"가 아니라 "시스템을 이해하기"를 목표로 탐험한다고 배웠다. 이 레슨은 그다음 단계다 — 정찰을 통해 이해한 시스템 위에, 회귀 안전망으로서의 자동화를 어떻게 현실적으로 구축할지 다룬다.

레거시 자동화가 특히 어려운 이유

• API가 없다 — 모듈 12에서 배운 API 테스트를 아예 적용할 수 없다. 화면(UI)을 통하는 것 외에 다른 방법이 없는 경우가 많다
• 접근성 정보가 없다 — 레슨 3에서 배운 이미지·좌표 기반 자동화에 의존해야 할 수 있다
• 문서화된 요구사항이 없다 — 모듈 3에서 배운 명세 기반 테스트 설계를 적용할 근거 자체가 부족하다. "지금 동작이 의도인지 버그인지" 판단 근거가 사람의 기억뿐인 경우가 많다
• 원작자가 없다 — 왜 이렇게 만들어졌는지 물어볼 사람이 없다

현재 동작을 "명세"로 삼는다

문서화된 요구사항이 없을 때, 모듈 5(레슨 11)의 정찰 세션에서 파악한 **"현재 실제로 어떻게 동작하는가"**를 임시 명세로 삼아 회귀 테스트를 설계하는 접근이 현실적이다.

일반적인 테스트 설계: 요구사항 명세 → 테스트 케이스 도출 (모듈 2, 3)
레거시 시스템: 현재 동작 관찰 → "이게 지금 정상 동작이다"로 간주 → 회귀 테스트 케이스 도출

이 접근의 목적은 "이 동작이 옳다"고 주장하는 게 아니라, "앞으로 이 시스템을 건드릴 때, 지금과 다르게 동작하면 바로 알아챌 수 있게" 만드는 안전망을 세우는 것이다.

어디까지 자동화할 것인가 — 우선순위의 재조정

모듈 11(레슨 2)에서 배운 자동화 판단 기준(반복성·안정성·회귀 가치)은 레거시 환경에서 더 신중하게 적용해야 한다.

레거시 시스템에서 자동화 우선순위가 높은 경우:
- 곧 리팩터링하거나 새 시스템으로 교체할 예정인 핵심 흐름
  (교체 전후 동작이 같은지 비교하는 회귀 안전망으로 특히 중요)
- 변경 빈도는 낮지만 실패 시 파급력이 큰 흐름(정산, 결제)
 
레거시 시스템에서 자동화를 신중히 검토해야 하는 경우:
- 곧 폐기될 예정인 기능(투자 대비 회수 기간이 없음, 모듈 11 레슨 3)
- 이미지·좌표 기반(레슨 3)으로만 접근 가능해 유지보수 비용이
  극도로 높을 것으로 예상되는 영역

레거시 자동화는 리팩터링의 안전망이 된다

레거시 시스템을 현대화(API 추가, 새 프레임워크로 이전)하는 프로젝트에서, 이 레슨에서 만든 회귀 자동화가 "리팩터링 전후 동작이 같은지" 확인하는 핵심 도구가 된다. 이건 모듈 9(레슨 9)에서 배운 테스트 용이성 원칙이 결국 지향하는 목표 — 안심하고 코드를 바꿀 수 있게 하는 것 — 을 가장 어려운 환경에서 실현하는 사례다.

실무에서 왜 필요한가

"이 레거시 시스템은 문서도 없고 담당자도 퇴사해서 아무도 못 건드린다"는 상황은, 결국 그 시스템을 바꿔야 할 때 큰 리스크로 돌아온다. 정찰(모듈 5 레슨 11)과 현재 동작 기반 회귀 자동화(이 레슨)를 미리 갖춰두면, 나중에 그 시스템을 리팩터링하거나 교체할 때 "우리가 뭔가 망가뜨렸는지" 바로 확인할 수 있는 근거가 생긴다.

실습 과제

과제 1 — 임시 명세 만들기 (10분)

"입력값 검증 없이 어떤 숫자를 넣어도 받아들이는" 레거시 주문 시스템의 한 화면을 정찰했다고 하자. 이 동작을 "현재 명세"로 삼아 회귀 테스트 케이스를 하나 작성해본다(이게 옳은 동작인지 판단하지 않고, 있는 그대로 기록하는 것이 핵심이다).

과제 2 — 자동화 우선순위 판단하기 (10분)

레거시 시스템 안의 두 기능 — "6개월 내 폐기 예정인 부가 기능"과 "매일 쓰이지만 API가 없어 이미지 기반으로만 접근 가능한 핵심 정산 기능" — 중 어느 쪽에 자동화 리소스를 먼저 투자할지 판단하고 이유를 적는다.

자가 체크리스트

• 레거시 시스템 자동화가 어려운 네 가지 이유를 설명할 수 있다
• "현재 동작을 임시 명세로 삼는다"는 접근의 목적을 설명할 수 있다
• 레거시 환경에서 자동화 우선순위를 어떻게 재조정해야 하는지 설명할 수 있다
• 레거시 자동화가 리팩터링의 안전망이 되는 이유를 설명할 수 있다

흔한 실수

• 레거시 시스템의 모든 동작을 "옳다"고 전제하고 자동화한다. 현재 동작을 기록하는 것과 그것이 올바르다고 주장하는 것은 다르다 — 발견한 이상 동작은 별도로 결함 리포트(모듈 6)로 남겨야 한다.
• 곧 폐기될 기능에 큰 자동화 투자를 한다. 모듈 11(레슨 3)의 ROI 관점에서 손익분기점을 넘기지 못할 가능성이 크다.
• 정찰 없이 바로 자동화부터 시작한다. 시스템을 이해하지 못한 채 만든 자동화는 무엇을 검증하는지도 불분명해진다.

참고 자료

• Michael Feathers, Working Effectively with Legacy Code — 모듈 5 레슨 11과 동일한 참고 자료, 레거시 시스템에 안전망을 세우는 원칙
• ISTQB — Regression Testing 관련 개념의 공식 정의