회귀 테스트

고장은 대개 고친 자리에서 나지 않습니다. 건드리지 않은 자리에서 납니다. 한 곳을 고쳤는데 엉뚱한 곳이 조용히 멈추는 일이 반복되면서, 새 기능이 잘 되는지와 별도로 안 건드린 것이 안 깨졌는지를 묻는 확인이 따로 필요해졌습니다.

페이지덱에서 이런 일이 있었습니다. 태오가 문서 권한 로직을 고쳐 팀 문서를 외부에 공유할 때 한 단계를 줄였습니다. 고친 부분은 잘 돌았습니다. 그런데 링크로 문서를 열던 기능이 로그인 화면으로 튕기기 시작했고, 그 사실을 사흘 뒤 고객 문의로 알았습니다. 아무도 그 기능을 다시 눌러 보지 않았기 때문입니다.

사람이 매번 전부 확인하면 되는 일처럼 보이지만 규모가 그것을 막습니다. 기능이 200개인 제품을 한 바퀴 손으로 훑으면 이틀이 걸리고, 그 이틀을 배포마다 쓸 수는 없습니다. 게다가 손으로 훑는 사람은 지루한 부분을 건너뜁니다. 그래서 확인해야 할 것을 목록으로 고정하고 기계가 매번 같은 순서로 돌리게 만들었습니다.

원래 되던 것이 무엇인지 목록으로 못 박는 일부터 시작합니다. 다섯 단계입니다.

1. 깨지면 안 되는 흐름을 적습니다. 가입, 로그인, 문서 만들기, 공유 링크로 열기, 결제처럼 멈추면 고객이 바로 아는 것들입니다. 목록이 곧 이 테스트의 범위이므로, 적히지 않은 기능은 아무리 중요해도 확인되지 않습니다.
2. 목록을 자동 테스트로 옮깁니다. 층을 나눠 담는 것이 요령입니다. 값 하나하나의 계산은 단위 테스트, 곧 함수 하나에 값을 넣고 결과를 확인하는 빠른 검사로 수백 개 두고, 브라우저를 실제로 띄워 사람이 하는 대로 눌러 보는 E2E 테스트는 가입과 결제처럼 몇십 개만 둡니다. 한 건에 10초씩 걸리는 것을 500개 두면 한 바퀴가 두 시간이 됩니다.
3. 언제 돌릴지 정합니다. 보통 셋으로 나눕니다. 변경을 합치기 전에 빠른 묶음만, 배포 전에 전체를, 그리고 밤마다 시간이 오래 걸리는 것까지 한 번. 이 배치를 정해 두지 않으면 개발자가 결과를 기다리느라 멈춰 있게 됩니다.
4. 빨간불이 뜨면 원인을 먼저 가릅니다. 진짜로 기능이 깨진 경우와 플레이키 테스트, 곧 코드를 안 고쳤는데도 날에 따라 성공과 실패를 오가는 불안정한 테스트를 구분해야 합니다. 후자를 그대로 두면 팀이 빨간불을 보고도 다시 돌리고 넘어가게 되고, 그 순간부터 이 묶음은 경고 기능을 잃습니다.
5. 새로 잡힌 버그마다 그것을 재현하는 테스트를 목록에 더합니다. 한 번 난 고장이 두 번 나지 않게 하는 방법이고, 이렇게 붙여 나가면 목록이 실제 사고를 따라 자랍니다.

자주 배포하는 제품에서 값이 가장 큽니다. 주에 두세 번 나가는 제품은 손으로 확인할 시간이 없고, 그 대신 기계가 같은 목록을 매번 돌립니다. 오래돼서 어디가 어디에 연결됐는지 아무도 다 알지 못하는 코드, 그리고 구조만 바꾸는 작업을 앞둔 자리도 좋은 대상입니다. 화면이 그대로인지 확인할 수단이 이것이기 때문입니다.

한계는 셋입니다.

1. 목록에 없는 것은 보지 않습니다. 테스트 커버리지는 테스트가 훑고 지나간 코드의 비율인데, 1000줄 중 720줄이 실행됐으면 72퍼센트입니다. 이 값이 높아도 나머지 280줄에서 나는 고장은 그대로 지나갑니다.
2. 느려지면 아무도 안 돌립니다. 한 바퀴가 40분이면 개발자는 결과를 기다리지 않고 다음 일로 넘어가고, 두 시간이면 아예 건너뛰는 방법을 찾습니다. 속도가 이 테스트의 성능 문제가 아니라 신뢰 문제인 이유입니다.
3. 유지비가 듭니다. 화면 구조나 문구가 바뀌면 그것에 기대던 테스트가 같이 깨집니다. 기능은 멀쩡한데 테스트만 고치는 작업이 배포마다 붙고, 이 비용을 아무도 세지 않으면 팀은 조용히 테스트를 지우는 쪽으로 갑니다.

"이 변경은 권한 쪽을 건드리니까 회귀 테스트 전체를 한 번 돌리고 내보내죠."

영향 범위가 넓어 빠른 묶음만으로는 부족하다는 판단입니다.

"회귀에서 결제 두 건이 빨간불인데 어제부터인지 확인해 주세요."

지금 변경 때문인지 원래 불안정했던 것인지부터 가리자는 말입니다.

"이 버그는 고치고 나서 회귀 테스트에도 추가해 주세요."

같은 고장이 다시 나는 것을 막는 절차를 요청하는 말입니다.

태오는 공유 링크 사고 뒤에 그 흐름을 목록에 넣었습니다. 로그인하지 않은 사람이 링크로 문서를 여는 경로를 E2E 테스트 한 건으로 만들고, 권한을 계산하는 부분은 단위 테스트 열두 건으로 덮었습니다. 같은 실수는 그 뒤로 배포 전에 잡혔습니다.

지현은 배포 회의에서 이 묶음의 결과를 먼저 봅니다. 전부 초록이면 넘어가고, 빨간불이 하나라도 있으면 그것이 무엇인지 확인하기 전에는 배포하지 않기로 정해 뒀습니다. 예외를 한 번 만들면 그다음부터 기준이 없어지기 때문입니다.

회귀 테스트를 단위 테스트나 E2E 테스트와 나란히 놓인 별도의 종류로 아는 경우가 많습니다. 이름이 같은 층에 있는 말처럼 들리니 그렇게 읽힙니다. 하지만 이것은 범위를 가리키는 말이 아니라 목적을 가리키는 말입니다. 어제 쓴 단위 테스트 300개를 오늘 변경 뒤에 다시 돌리면 그 300개가 오늘의 회귀 테스트입니다. 이것을 별도 종류로 알면 팀은 회귀용 테스트를 따로 만들려 하고, 이미 있는 것과 겹치는 묶음이 둘 생겨 유지비만 두 배가 됩니다.

전부 초록이면 안전하다고 읽는 오해도 흔합니다. 매번 같은 결과가 나오니 그 초록이 제품 전체를 보증하는 것처럼 보입니다. 이 묶음이 보증하는 것은 목록에 적힌 것이 여전히 된다는 사실뿐입니다. 목록에 없는 기능, 처음 만든 기능, 목록에 있지만 조건이 다른 경우는 전부 밖에 있습니다. 초록을 통과 증명으로 읽으면 새 기능을 확인하지 않고 내보내는 습관이 생기고, 사고는 늘 목록 바깥에서 납니다.