개념
정찰에서 자동화로
모듈 5(레슨 11)에서 배운 정찰 세션을 떠올려보자 — 문서가 없는 레거시 시스템을 다룰 때, 먼저 "결함을 찾기"가 아니라 "시스템을 이해하기"를 목표로 탐험한다고 배웠다. 이 레슨은 그다음 단계다 — 정찰을 통해 이해한 시스템 위에, 회귀 안전망으로서의 자동화를 어떻게 현실적으로 구축할지 다룬다.
레거시 자동화가 특히 어려운 이유
- API가 없다 — 모듈 12에서 배운 API 테스트를 아예 적용할 수 없다. 화면(UI)을 통하는 것 외에 다른 방법이 없는 경우가 많다
- 접근성 정보가 없다 — 레슨 3에서 배운 이미지·좌표 기반 자동화에 의존해야 할 수 있다
- 문서화된 요구사항이 없다 — 모듈 3에서 배운 명세 기반 테스트 설계를 적용할 근거 자체가 부족하다. "지금 동작이 의도인지 버그인지" 판단 근거가 사람의 기억뿐인 경우가 많다
- 원작자가 없다 — 왜 이렇게 만들어졌는지 물어볼 사람이 없다
현재 동작을 "명세"로 삼는다
문서화된 요구사항이 없을 때, 모듈 5(레슨 11)의 정찰 세션에서 파악한 "현재 실제로 어떻게 동작하는가" 를 임시 명세로 삼아 회귀 테스트를 설계하는 접근이 현실적이다.
일반적인 테스트 설계: 요구사항 명세 → 테스트 케이스 도출 (모듈 2, 3)
레거시 시스템: 현재 동작 관찰 → "이게 지금 정상 동작이다"로 간주 → 회귀 테스트 케이스 도출이 접근의 목적은 "이 동작이 옳다"고 주장하는 게 아니라, "앞으로 이 시스템을 건드릴 때, 지금과 다르게 동작하면 바로 알아챌 수 있게" 만드는 안전망을 세우는 것이다.
어디까지 자동화할 것인가 — 우선순위의 재조정
모듈 11(레슨 2)에서 배운 자동화 판단 기준(반복성·안정성·회귀 가치)은 레거시 환경에서 더 신중하게 적용해야 한다.
레거시 시스템에서 자동화 우선순위가 높은 경우:
- 곧 리팩터링하거나 새 시스템으로 교체할 예정인 핵심 흐름
(교체 전후 동작이 같은지 비교하는 회귀 안전망으로 특히 중요)
- 변경 빈도는 낮지만 실패 시 파급력이 큰 흐름(정산, 결제)
레거시 시스템에서 자동화를 신중히 검토해야 하는 경우:
- 곧 폐기될 예정인 기능(투자 대비 회수 기간이 없음, 모듈 11 레슨 3)
- 이미지·좌표 기반(레슨 3)으로만 접근 가능해 유지보수 비용이
극도로 높을 것으로 예상되는 영역레거시 자동화는 리팩터링의 안전망이 된다
레거시 시스템을 현대화(API 추가, 새 프레임워크로 이전)하는 프로젝트에서, 이 레슨에서 만든 회귀 자동화가 "리팩터링 전후 동작이 같은지" 확인하는 핵심 도구가 된다. 이건 모듈 9(레슨 9)에서 배운 테스트 용이성 원칙이 결국 지향하는 목표 — 안심하고 코드를 바꿀 수 있게 하는 것 — 을 가장 어려운 환경에서 실현하는 사례다.
실무에서 왜 필요한가
"이 레거시 시스템은 문서도 없고 담당자도 퇴사해서 아무도 못 건드린다"는 상황은, 결국 그 시스템을 바꿔야 할 때 큰 리스크로 돌아온다. 정찰(모듈 5 레슨 11)과 현재 동작 기반 회귀 자동화(이 레슨)를 미리 갖춰두면, 나중에 그 시스템을 리팩터링하거나 교체할 때 "우리가 뭔가 망가뜨렸는지" 바로 확인할 수 있는 근거가 생긴다.