개념
레거시 시스템의 현실
문서가 없거나 오래되어 못 믿을 수준이고, 원래 만든 사람은 퇴사했고, "이게 왜 이렇게 동작하는지 아무도 모른다"는 시스템은 실무에서 드물지 않다. 그런데도 이런 시스템을 수정하거나 새 기능과 연동해야 하는 일은 계속 생긴다.
그리고 대부분의 QA 가 실제로 보내는 시간이 여기다. 이 모듈의 앞 레슨들은 "새 기능이 나왔을 때" 를 전제했지만, 현실에서는 이미 있는 것을 맡는 일이 훨씬 많다.
먼저 말을 정리하자. 레거시는 "오래된 코드" 가 아니라 "지금 돌아가고 있는데 손대기 무서운 것" 이다. 작년에 만든 것도 레거시가 될 수 있고, 10년 된 것도 문서와 시험이 잘 갖춰져 있으면 레거시가 아니다.
손대기 무서운 이유는 셋이다.
- 무엇이 깨질지 모른다 — 어디까지 영향이 가는지 아무도 모른다
- 깨졌는지 알 방법이 없다 — 시험이 없으니 확인할 길이 없다
- 원래 맞는 동작이 뭔지 모른다 — 지금 동작이 의도인지 결함인지 모른다
세 번째가 QA 에게 가장 어려운 지점이다. 기대 결과가 없는 상태에서 시험해야 한다. 그래서 레거시 탐험은 "맞는지 보는 일" 이 아니라 "지금 어떤지 적어 두는 일" 로 시작한다.
지금 동작이 기준이 된다
기대 결과가 없을 때 쓰는 가장 현실적인 방법은 현재 동작을 기준으로 삼는 것이다. 모듈 4 레슨 6에서 본 전환 검증과 같은 발상이다 — 성공 기준이 "아무것도 달라지지 않았다" 인 경우다.
| 보통의 시험 | 레거시 시험 |
|---|---|
| 명세와 비교한다 | 지금 동작과 비교한다 |
| 다르면 결함 | 다르면 변경(의도인지 확인 필요) |
| 기대 결과를 먼저 적는다 | 현재 결과를 먼저 적어 둔다 |
그래서 레거시를 손대기 전에 지금 동작을 기록해 두는 것이 사실상 첫 번째 시험이다. 화면 캡처, 응답 본문, 저장된 값, 계산 결과 — "고치기 전에는 이랬다" 를 남겨 두면 그것이 비교 기준이 된다.
다만 주의할 것이 있다. 지금 동작이 틀렸을 수도 있다. 그래서 기록과 함께 "이게 맞는 건가요" 목록도 만든다. 둘을 같이 들고 가는 것이 레거시 작업의 기본 자세다.
정찰 세션 (Reconnaissance Session)
레거시 시스템을 다룰 때 첫 번째로 여는 세션은 "결함을 찾는" 차터가 아니라 "시스템을 이해하는" 차터여야 한다. 이걸 정찰 세션이라 부른다.
차터 예시: "관리자 페이지 전체를, 화면과 메뉴를 하나씩 훑으며 탐험해서, 어떤 기능이 존재하는지 목록을 만든다."
목적을 바꾸면 성공 기준도 바뀐다. 결함을 못 찾아도 성공이고, "무엇이 있는지 알게 됐다" 가 산출이다. 이 합의를 세션 시작 전에 해 두지 않으면 "두 시간 동안 뭐 했냐" 는 말을 듣게 된다.
정찰 세션의 산출물은 결함 리스트가 아니라 지식이다 — 화면·기능 인벤토리, 대략적인 상태 모델(레슨 8과 연결), "이건 왜 이런지 모르겠다"는 질문 목록.
정찰 세션은 보통 세 바퀴로 돈다. 한 바퀴에 60~90분씩, 세 번이면 대부분의 시스템이 손에 잡힌다.
1바퀴 — 넓게 훑는다. 메뉴를 하나씩 열어 무엇이 있는지만 적는다. 깊이 들어가지 않는다. 산출물은 기능 목록이다. 이 단계에서 "이 메뉴는 뭐 하는 건지 모르겠다" 가 잔뜩 나오는 것이 정상이다.
2바퀴 — 데이터를 따라간다. 가장 중요해 보이는 흐름 하나를 처음부터 끝까지 해 본다(레슨 7의 데이터 따라가기). 어떤 개체가 있고 어디서 어디로 가는지 그린다. 산출물은 개체 지도다.
3바퀴 — 상태를 캔다. 중심 개체 하나를 골라 상태와 전이를 그린다 (레슨 8). 산출물은 상태 지도다.
세 바퀴를 돌면 레슨 7·8·9에서 만든 세 방향 지도가 전부 생긴다. 그다음부터야 "결함을 찾는" 차터를 쓸 수 있다.
정찰에서 특히 눈여겨볼 것
레거시에는 보통 제품에 없는 종류의 흔적이 남아 있다. 이런 것들이 보이면 멈춰서 적어 둔다.
| 흔적 | 무엇을 뜻하나 |
|---|---|
| 안 쓰는 메뉴·버튼 | 죽은 기능인가, 쓰는 사람이 따로 있나 |
| 이름이 안 맞는 화면 | "임시" 가 붙은 채 5년째 쓰이는 것들 |
| 비슷한 기능이 두 개 | 하나는 옛것. 어느 쪽이 진짜인지 확인 필요 |
| 엑셀로 내려받아 손으로 고친다 | 그 자리가 결함 또는 공백이다 |
| "그건 건드리면 안 돼요" | 가장 중요한 정보. 왜인지 끝까지 묻는다 |
마지막 줄이 가장 값지다. 누군가 "건드리면 안 된다" 고 말하는 곳에는 이유가 있고, 그 이유가 적혀 있는 경우는 거의 없다. 이유를 캐내는 것만으로 팀의 지식이 하나 늘어난다.
네 번째 줄도 놓치지 않는다. 사람이 손으로 메우고 있는 곳은 시스템이 못 하는 일이라는 뜻이고, 레슨 7에서 본 "운영팀이 매달 손으로 고치는 것" 과 같은 신호다.
로그와 데이터도 정찰 대상이다
화면과 코드만이 아니다. 지금까지 쌓인 것을 보면 그 시스템이 실제로 어떻게 쓰였는지 드러난다.
| 어디 | 무엇이 보이나 |
|---|---|
| 오류 기록 | 매일 나는 오류 목록. 아무도 안 보고 있던 것들 |
| 사용 통계 | 어느 기능이 실제로 쓰이는가. 안 쓰는 메뉴가 가려진다 |
| 데이터 분포 | 값이 비어 있는 열, 이상한 값, 쓰다 만 흔적 |
| 고객 문의 이력 | 사용자가 실제로 겪는 문제. 빈도순으로 정렬해 본다 |
첫 줄이 거의 항상 수확이 있다. 오래된 시스템은 매일 조용히 오류를 뱉고 있는 경우가 많고, 아무도 안 보기 때문에 그대로 쌓여 있다. 그중 일부는 실제 결함이고, 일부는 "원래 저래요" 로 굳어진 것이다.
네 번째도 값싸다. 문의를 유형별로 세어 보면 가장 아픈 곳이 숫자로 나온다. 탐험할 영역을 고르는 근거가 되고, 모듈 45에서 다루는 품질 데이터 읽기와 같은 발상이다.
이해관계자 인터뷰
문서보다 사람이 더 정확한 정보를 가진 경우가 많다. 그 시스템을 매일 쓰는 사람(고객지원팀, 운영팀, 실사용자)에게 직접 물어본다.
"이 화면에서 이렇게 하면 가끔 이상해지는데, 우리는 그냥 그렇게 안 써요"
이 한 문장에 결함과 우회 방법과 재현 조건이 다 들어 있다. 그런데 아무 데도 안 적혀 있고, 묻지 않으면 영영 안 나온다. 그 사람에게는 이미 해결된 문제이기 때문이다.
이런 대답은 어떤 문서에도 안 적혀 있지만, 실제 시스템의 결함이나 위험 지점을 정확히 가리킨다. "자주 겪는 불편함이나 우회 방법이 있나요?" 라고 묻는 것만으로도 정찰 세션 몇 시간보다 많은 정보를 얻을 때가 있다.
누구에게 묻느냐에 따라 나오는 것이 다르다. 세 쪽을 다 만나는 것이 좋고, 셋이 서로 다른 이야기를 하는 지점이 특히 중요하다. 운영팀은 "그건 안 써요" 라는데 고객 지원에는 그 기능 문의가 들어온다면, 둘 중 하나는 사실이 아니다.
| 누구 | 여기서만 나오는 것 |
|---|---|
| 매일 쓰는 사람 | 우회 방법, 자주 나는 오류, "그건 원래 그래요" |
| 고객 지원 | 사용자가 실제로 문의하는 것. 빈도를 안다 |
| 오래 있은 개발자 | 왜 그렇게 만들었는지. 건드리면 안 되는 곳 |
질문은 "문제가 있나요" 로 묻지 않는다. 그렇게 물으면 "별일 없어요" 가 돌아온다. 행동을 묻는 쪽이 훨씬 잘 나온다.
- "하루에 이 화면을 몇 번 여세요?" → 중요한 화면이 드러난다
- "여기서 제일 손이 많이 가는 일이 뭐예요?" → 비효율이 드러난다
- "혹시 따로 엑셀로 관리하시는 게 있나요?" → 시스템이 못 하는 일
- "최근에 '어 이상한데' 했던 적 있으세요?" → 재현 안 되는 결함의 단서
- "새로 온 사람한테 꼭 알려 주는 게 있나요?" → 암묵적 규칙
세 번째 질문이 가장 많이 건진다. 엑셀로 따로 관리한다는 것은 시스템이 그 일을 못 하거나, 믿을 수 없다는 뜻이다. 어느 쪽이든 중요한 발견이다.
인터뷰에서 지킬 것
사람에게 묻는 일이라 태도가 결과를 바꾼다. 셋만 지킨다.
- 비판처럼 들리지 않게 한다. "왜 이렇게 쓰세요" 가 아니라 "어떻게 쓰시는지 보여 주실 수 있나요". 그 사람이 만든 방식일 수도 있다
- 시간을 적게 쓴다. 15~20분이면 충분하고, 길어지면 다음에 안 만나 준다
- 들은 것을 돌려준다. 정리한 문서를 보내 주면 틀린 곳을 고쳐 준다. 그리고 다음에 또 물어볼 수 있는 관계가 된다
세 번째가 특히 값을 한다. 내가 이해한 것을 글로 보여 주면 사람들은 고쳐 주고 싶어 한다 — 레슨 7에서 개체 지도를 추측해 그린 뒤 확인받는 것과 같은 원리다.
정찰과 인터뷰를 합친다
정찰 세션에서 발견한 것과 인터뷰에서 들은 것을 합치면, 문서는 없어도 "이 정도면 테스트할 수 있다"는 수준의 이해가 만들어진다. 이 결과물 (기능 목록, 대략적 상태 모델, 알려진 이상 동작 목록)을 팀에 남기면, 다음 사람이 이 시스템을 다룰 때 처음부터 다시 헤매지 않아도 된다.
코드가 있으면 더 빠르다
코드를 볼 수 있으면 정찰이 훨씬 빨라진다. 읽을 줄 몰라도 쓸 수 있는 방법이 몇 가지 있다.
| 방법 | 무엇을 알 수 있나 |
|---|---|
| 파일·폴더 이름 훑기 | 어떤 기능들이 있는지. 화면 목록과 대조된다 |
| 최근 변경 기록 | 어디가 자주 바뀌는가 = 어디가 불안정한가 |
| 오래 안 바뀐 곳 | 안정적이거나, 아무도 못 건드리는 곳 |
| 설정 파일 | 외부 연동 목록(레슨 9의 생태계 지도) |
| 주석의 "임시"·"나중에" | 미완성인 채 남은 자리 |
두 번째가 가장 쓸모 있다. 최근 석 달 동안 가장 많이 바뀐 파일 몇 개를 뽑으면, 그곳이 이번 릴리즈에서 가장 위험한 영역이다. 코드를 읽지 않아도 파일 이름만으로 어느 기능인지 대개 짐작된다.
구체적인 방법은 모듈 9 레슨 7·11에서 다룬다. 여기서는 "코드를 못 읽어도 변경 이력은 읽을 수 있다" 는 것만 알아 두면 된다.
남길 문서 — 네 장이면 된다
정찰이 끝나면 네 장짜리 묶음을 남긴다. 길게 쓰지 않는다. 다음 사람이 30분 안에 읽을 수 있어야 한다.
| 문서 | 내용 |
|---|---|
| 기능 목록 | 어떤 화면·기능이 있고 누가 쓰는가 |
| 지도 세 장 | 개체·상태·생태계(레슨 7·8·9) |
| 알려진 이상 동작 | "이건 원래 이래요" 목록. 우회 방법 포함 |
| 모르는 것 목록 | 답을 못 찾은 질문들. 지우지 않는다 |
네 번째가 가장 자주 빠지는데 가장 정직한 문서다. "여기까지는 알아냈고 여기부터는 모른다" 를 적어 두면, 다음 사람이 거기서부터 시작한다. 모르는 것을 숨기면 다음 사람은 그 영역이 확인된 줄 안다.
문서는 찾을 수 있는 곳에 둔다. 개인 메모나 채팅 기록에 남기면 없는 것과 같다. 팀이 쓰는 문서 도구에 두고, 그 시스템 이름으로 검색되게 한다(모듈 7·22).
사례 — 첫 2주에 한 일
경력 QA 가 20년 된 사내 정산 시스템을 맡았을 때의 기록이다. 결함을 찾기 전에 2주를 썼고, 그 2주가 이후를 바꿨다.
1주차 — 정찰.
| 바퀴 | 한 일 | 나온 것 |
|---|---|---|
| 1 | 메뉴 47개를 하나씩 열어 봤다 | 기능 목록. 쓰지 않는 메뉴가 11개 |
| 2 | 정산 한 건을 끝까지 따라갔다 | 개체 지도. 외부 연동 3곳 발견 |
| 3 | 정산 건의 상태를 캤다 | 상태 9개. 문서에는 5개 |
2주차 — 인터뷰. 운영 담당자 두 명, 고객 지원 한 명, 10년차 개발자 한 명. 각각 20분씩.
여기서 나온 것이 정찰 전체보다 많았다.
- "매달 말에 엑셀로 받아서 손으로 고쳐요" → 시스템이 못 하는 계산이 있다
- "그 버튼은 안 눌러요. 누르면 다시 못 돌려요" → 되돌릴 수 없는 동작
- "가끔 금액이 1원씩 안 맞는데 그냥 맞춰요" → 반올림 문제로 추정
- "신입한테 꼭 말해 줘요, 5시 넘어서 마감 돌리면 안 된다고" → 배치 충돌
산출물. 문서 네 장과 질문 23개. 결함 리포트는 2건뿐이었다.
그런데 그 23개 질문에서 그 뒤 석 달 동안 결함 14건이 나왔다. 1원씩 안 맞는다는 말은 실제로 반올림 결함이었고, 5시 이후 마감 금지는 아무 데도 안 적힌 제약이었다.
2주 동안 결함을 2건밖에 못 찾았다 고 평가하면 이 작업은 실패로 보인다. 그래서 정찰 세션은 시작할 때 목적을 합의해 두는 것이 중요하다 — "이번 주 산출물은 결함이 아니라 지도입니다" 라고 먼저 말해 둔다.
레거시에서 특히 조심할 것
보통 제품보다 위험한 지점이 있다.
- 시험 환경이 없을 수 있다. 운영에서 직접 봐야 하는 경우가 실제로 있고, 그때는 조회만 한다. 데이터를 바꾸는 동작은 합의 없이 하지 않는다
- 시험 데이터가 실제 데이터일 수 있다. 오래된 시스템일수록 운영 데이터가 복사돼 있는 경우가 많다. 개인정보가 들어 있는지 먼저 확인한다
- 되돌릴 수 없는 동작이 섞여 있다. 일괄 처리, 정산 마감, 외부 전송이 버튼 하나에 걸려 있기도 하다. 처음 보는 버튼은 누르기 전에 묻는다
- 다른 시스템이 몰래 의존한다. 우리가 아는 것 말고 다른 팀이 그 데이터를 읽어 가고 있을 수 있다(레슨 9의 "바깥")
세 번째가 사고로 이어지기 쉽다. 탐험은 눌러 보는 활동인데, 레거시에는 누르면 끝인 버튼이 있다. 정찰 1바퀴에서 "이 버튼은 뭘 하나요" 를 미리 물어 두는 이유다.
정찰은 언제 끝내나
끝이 없는 작업처럼 느껴질 수 있다. 세 가지 중 하나가 되면 멈춘다.
- 새로 나오는 것이 줄었다 — 한 바퀴 더 돌았는데 모르는 것이 두어 개 밖에 안 늘면 충분히 돈 것이다
- 차터를 쓸 수 있게 됐다 — "어디가 위험한지" 가 말로 나오면 정찰의 목적은 달성됐다
- 시간이 다 됐다 — 2주든 3일이든 미리 정해 둔 양을 다 쓰면 멈춘다. 남은 것은 모르는 것 목록에 적는다
세 번째가 현실적으로 가장 자주 쓰인다. 그리고 그래도 괜찮다 — 완전한 이해는 목표가 아니다. 목표는 "무엇을 모르는지 아는 상태" 이고, 거기까지만 가도 결함 찾기를 시작할 수 있다.
반대로 정찰을 아예 건너뛰면 어떻게 되는지도 분명하다. 눈에 띄는 화면 몇 개만 반복해서 보게 되고, 시스템의 절반을 끝까지 안 보게 된다. 그 절반에 위험이 몰려 있는 경우가 많다.
실무에서 왜 필요한가
실무에서 다루는 소프트웨어 대부분은 신규 개발이 아니라 이미 존재하는 시스템이다. 그리고 이직할 때마다 이 작업을 처음부터 다시 한다. 새 회사의 시스템은 전부 레거시이고, 문서가 있어도 믿을 수 없는 상태인 경우가 많다. 그래서 이 레슨의 방법은 커리어 전체에 걸쳐 반복해서 쓰이는 몇 안 되는 기술이다. 이해 없이 테스트를 시작하면 엉뚱한 곳에 시간을 쓰거나, 정작 중요한 리스크를 놓친다. 정찰 세션 먼저, 그다음 실제 테스트라는 2단계 접근은 레거시 작업에서 가장 현실적이고 효율적인 전략이다. 또한 이렇게 만든 문서는 팀 전체의 자산이 되어, QA 한 사람이 바뀌어도 지식이 유실되지 않게 해준다.
마지막 효과가 특히 크다. 레거시 시스템의 지식은 보통 몇 사람의 머릿속에만 있고, 그 사람이 떠나면 통째로 사라진다. 정찰 문서를 남기는 QA 는 그 지식이 사라지는 속도를 늦추는 역할을 한다 — 결함을 찾는 것과는 다른 종류의 기여이고, 조직에서 더 오래 남는 쪽이기도 하다.
채용시장에서의 위치
이 역량은 공고에 거의 안 적히는데 실제로는 가장 많이 쓰인다. 새 제품을 맡는 일보다 이미 있는 것을 맡는 일이 훨씬 많기 때문이다. 이직하면 첫 달이 통째로 이 레슨의 내용이다.
면접에서는 이렇게 들어온다.
- "인수인계 없이 시스템을 맡게 되면 어떻게 하시겠어요?" — 정찰 세 바퀴를 말할 수 있으면 체계가 있는 사람으로 읽힌다
- "문서가 없는데 테스트 기준은 어떻게 잡으셨나요?" — "현재 동작을 기록해 기준으로 삼고, 이상한 줄은 질문 목록으로 올렸다"
- "들어온 지 얼마 안 돼서 뭘 할 수 있나요?" — 새로 온 사람만 할 수 있는 일이 있다. "왜 이렇게 되어 있나요" 를 물을 수 있는 것이 그것이고, 오래 있은 사람은 그 질문을 못 한다
마지막이 신입·경력 전환자에게 특히 중요하다. 모르는 것이 약점이 아니라 도구가 되는 유일한 구간이다. 몇 달 지나면 익숙해져서 못 묻게 된다 — 첫 달에 적어 둔 "이상한 것" 목록이 그래서 값지다.