개념
레거시 시스템의 현실
문서가 없거나 오래되어 못 믿을 수준이고, 원래 만든 사람은 퇴사했고, "이게 왜 이렇게 동작하는지 아무도 모른다"는 시스템은 실무에서 드물지 않다. 그런데도 이런 시스템을 수정하거나 새 기능과 연동해야 하는 일은 계속 생긴다.
정찰 세션 (Reconnaissance Session)
레거시 시스템을 다룰 때 첫 번째로 여는 세션은 "결함을 찾는" 차터가 아니라 "시스템을 이해하는" 차터여야 한다. 이걸 정찰 세션이라 부른다.
차터 예시: "관리자 페이지 전체를, 화면과 메뉴를 하나씩 훑으며 탐험해서, 어떤 기능이 존재하는지 목록을 만든다."
정찰 세션의 산출물은 결함 리스트가 아니라 지식이다 — 화면·기능 인벤토리, 대략적인 상태 모델(레슨 8과 연결), "이건 왜 이런지 모르겠다"는 질문 목록.
이해관계자 인터뷰
문서보다 사람이 더 정확한 정보를 가진 경우가 많다. 그 시스템을 매일 쓰는 사람(고객지원팀, 운영팀, 실사용자)에게 직접 물어본다.
"이 화면에서 이렇게 하면 가끔 이상해지는데, 우리는 그냥 그렇게 안 써요"
이런 대답은 어떤 문서에도 안 적혀 있지만, 실제 시스템의 결함이나 위험 지점을 정확히 가리킨다. **"자주 겪는 불편함이나 우회 방법이 있나요?"**라고 묻는 것만으로도 정찰 세션 몇 시간보다 많은 정보를 얻을 때가 있다.
정찰과 인터뷰를 합친다
정찰 세션에서 발견한 것과 인터뷰에서 들은 것을 합치면, 문서는 없어도 "이 정도면 테스트할 수 있다"는 수준의 이해가 만들어진다. 이 결과물 (기능 목록, 대략적 상태 모델, 알려진 이상 동작 목록)을 팀에 남기면, 다음 사람이 이 시스템을 다룰 때 처음부터 다시 헤매지 않아도 된다.
실무에서 왜 필요한가
실무에서 다루는 소프트웨어 대부분은 신규 개발이 아니라 이미 존재하는 시스템이다. 이해 없이 테스트를 시작하면 엉뚱한 곳에 시간을 쓰거나, 정작 중요한 리스크를 놓친다. 정찰 세션 먼저, 그다음 실제 테스트라는 2단계 접근은 레거시 작업에서 가장 현실적이고 효율적인 전략이다. 또한 이렇게 만든 문서는 팀 전체의 자산이 되어, QA 한 사람이 바뀌어도 지식이 유실되지 않게 해준다.
실습 과제
과제 1 — 정찰 세션 차터 작성하기 (10분)
"아무도 정확히 이해하지 못하는 사내 재고 관리 시스템"에 대한 정찰 세션 차터를 작성한다. (레슨 2에서 배운 형식을 참고한다.)
과제 2 — 인터뷰 질문 만들기 (10분)
이 레거시 시스템을 매일 쓰는 담당자에게 물어볼 질문을 3개 만든다. (힌트: "자주 겪는 불편함", "우회해서 쓰는 방법이 있는지" 같은 방향으로 생각해본다.)
자가 체크리스트
- 정찰 세션이 왜 "결함 찾기"가 아니라 "이해하기"를 목표로 하는지 설명할 수 있다
- 정찰 세션의 산출물(기능 인벤토리, 상태 모델, 질문 목록)을 예시로 들 수 있다
- 이해관계자 인터뷰가 문서보다 유용한 정보를 줄 수 있는 이유를 설명할 수 있다
- 레거시 시스템 테스트에 왜 2단계(정찰→실제 테스트) 접근이 효율적인지 설명할 수 있다
흔한 실수
- 레거시 시스템에 바로 결함 찾기 세션을 시작한다. 이해 없이 시작하면 방향을 못 잡고 시간만 흘러간다. 정찰이 먼저다.
- 문서만 찾고 사람에게는 안 물어본다. 레거시 시스템일수록 문서보다 사람의 경험이 더 정확한 정보원이다.
- 정찰 세션의 결과물을 개인 메모로만 남기고 팀에 공유하지 않는다. 다음 사람이 또 처음부터 헤매지 않으려면 반드시 문서로 남겨 공유해야 한다.
참고 자료
- Elisabeth Hendrickson, Explore It! — 정찰 세션(Reconnaissance) 개념을 정리한 장
- Michael Feathers, Working Effectively with Legacy Code — 레거시 코드를 다루는 고전적 실무서 (테스트 관점 포함)