테스트

코드를 고친 다음에는 잘 돌아가는지 확인해야 합니다. 화면이 다섯 장이던 시절에는 그 확인이 어렵지 않았습니다. 고친 사람이 브라우저를 열고 다섯 장을 차례로 눌러 보면 끝났고, 10분이면 됐습니다.

화면이 백 장이 되자 이 방식이 조용히 무너졌습니다. 한 군데를 고칠 때마다 백 장을 다 눌러 보는 사람은 없습니다. 대신 자기가 고친 자리 주변만 봅니다. 문제는 코드가 눈에 보이는 대로 이어져 있지 않다는 데 있습니다. 결제 화면을 고쳤는데 알림 메일이 깨지는 일이 생기는 것은, 두 화면이 같은 함수 하나를 함께 쓰고 있어서입니다.

페이지덱에서 이 문제가 드러난 건 문서 공유 링크에 만료일을 붙이던 때였습니다. 태오가 링크를 만들고 여는 흐름을 직접 눌러 확인하고 금요일에 내보냈습니다. 이틀 뒤 수아가 고객 데모 도중에 연락을 해 왔습니다. 초대받은 사람이 문서를 못 연다는 것이었습니다. 만료일을 검사하려고 손댄 권한 확인 코드가 공유 링크만이 아니라 초대 흐름에도 걸려 있었는데, 태오는 초대 화면을 열어 보지 않았습니다. 열어 볼 이유가 없었기 때문입니다. 그 화면은 이번에 고친 파일에 나오지도 않았습니다.

문제는 누가 게을렀다는 데 있지 않습니다. 무엇을 다시 확인해야 하는지를 사람의 기억으로 정한다는 구조 자체에 있습니다. 파일 열 개짜리 제품에서는 기억이 따라가지만, 파일 이천 개짜리 제품에서는 따라가지 못합니다. 게다가 손으로 하는 확인은 매번 새로 비용이 듭니다. 어제 30분을 들여 확인한 흐름도 오늘 한 줄을 고치면 다시 30분이 듭니다.

테스트는 그 확인을 사람의 기억에서 꺼내 글로 적어 두는 장치입니다. "포인트 3, 5, 2 를 넣으면 합계가 10 으로 나와야 한다" 처럼 넣을 값과 나와야 할 값을 코드로 적어 둡니다. 한 번 적어 두면 그다음부터는 누가 어디를 고치든 적어 둔 것 전부가 자동으로 다시 돌아가고, 깨진 자리가 있으면 이름을 대며 빨간불로 알립니다. 사람이 하던 확인을 없앤 것이 아니라, 한 번 한 확인을 다시 쓸 수 있게 저장해 둔 것입니다.

엔지니어링 축에서 테스트는 품질 갈래에 놓입니다. 같은 갈래의 코드 품질이 반년 뒤에 깨질 확률을 낮추는 일이라면, 테스트는 지금 이미 깨진 자리를 오늘 찾아내는 일입니다.

테스트 아래 묶인 용어는 여덟 갈래입니다. 네 질문으로 묶으면 지형이 한눈에 들어옵니다. 얼마나 넓게 보는가(범위), 무엇을 막으려고 도는가(목적), 어떻게 쓰고 무엇으로 받치는가(방법·도구), 무엇으로 재고 무엇이 잘못되는가(지표·문제·활동·결함)입니다.

범위는 한 번에 얼마나 큰 덩어리를 확인하느냐로 갈리는 갈래이고 네 종류가 있습니다.

1. 단위 테스트 — 함수나 모듈 하나만 떼어 확인합니다. 금액 계산 함수에 값을 넣고 결과만 봅니다. 한 건이 1000분의 1초 안에 끝나서 이천 개를 모아 돌려도 1분이 안 걸립니다.
2. 통합 테스트 — 여러 요소를 이어 붙인 상태로 확인합니다. 계산 함수와 데이터베이스와 결제 모듈을 실제로 연결해 놓고 돌립니다. 각각은 멀쩡한데 이어 붙이면 깨지는 일이 흔해서 따로 둡니다.
3. E2E 테스트 — E2E 테스트는 브라우저를 진짜로 띄워 사용자가 하는 대로 로그인부터 결제까지 눌러 봅니다. 가장 현실에 가깝지만 한 건에 10초씩 걸리고, 화면 문구 하나만 바뀌어도 깨집니다.
4. 스모크 테스트 — 배포 직후에 핵심 몇 가지만 빠르게 봅니다. 로그인이 되는지, 첫 화면이 뜨는지, 문서가 열리는지 정도입니다. 전부를 보려는 게 아니라 되돌릴지 말지를 2분 안에 정하려는 것입니다.

넷은 우열이 아니라 층입니다. 아래로 갈수록 빠르고 싸고 고장 원인을 정확히 짚어 주지만 실제 사용자와 멀고, 위로 갈수록 현실에 가깝지만 느리고 잘 깨집니다. 그래서 대개 단위 테스트를 수천 개 두고 E2E 는 가입·결제 같은 몇십 개만 둡니다. 비율을 뒤집어 E2E 를 500개 두면 전체 한 바퀴에 두 시간이 걸리고, 그렇게 되면 아무도 돌리지 않게 됩니다.

목적은 무엇을 막으려고 도느냐로 갈리는 갈래이고 둘이 있습니다.

1. 회귀 테스트 — 고친 뒤에 원래 되던 것이 그대로 되는지 봅니다. 앞의 공유 링크 사고가 정확히 이 자리에서 잡히는 종류입니다. 새 기능이 잘 되는지가 아니라 안 건드린 곳이 안 깨졌는지를 묻습니다.
2. 부하 테스트 — 사람이 몰렸을 때 버티는지 봅니다. 동시 접속 500명에서 응답이 0.3초인 서비스가 2000명에서 8초로 늘어난다면, 기능은 멀쩡해도 사용자에게는 고장 난 것과 같습니다. 이 숫자는 몰려 보기 전에는 알 수 없어서 일부러 몰아 봅니다.

방법과 도구는 테스트를 어떻게 쓰고 무엇으로 받치는지를 다루는 갈래입니다. 셋이 있습니다.

1. 테스트 주도 개발 — 구현보다 테스트를 먼저 씁니다. 아직 없는 기능의 기댓값부터 적고, 빨간불을 초록불로 바꾸는 방향으로 코드를 채웁니다. 순서를 뒤집으면 만들기 전에 무엇이 완성인지를 정하게 되어서, 나중에 테스트를 붙일 때 생기는 "이미 돌아가니까 대충 맞춰 적는" 문제가 줄어듭니다.
2. 목 — 진짜 대신 흉내만 내는 가짜입니다. 결제 테스트를 돌릴 때마다 카드사에 실제로 요청을 보낼 수는 없으니, 성공이라고만 답하는 가짜 결제사를 놓고 돌립니다. 느리거나 돈이 들거나 남의 서버에 기대는 부분을 잘라 내는 용도입니다.
3. 픽스처 — 테스트를 돌리기 전에 미리 깔아 두는 상태와 데이터입니다. "문서 세 건과 사용자 두 명이 이미 있는 상태" 를 매번 손으로 만들지 않고 한 번 적어 두고 불러 씁니다.

마지막 묶음은 재는 것과 잘못되는 것, 그리고 사람이 하는 일입니다. 네 갈래가 여기 들어갑니다.

1. 테스트 커버리지 — 테스트가 훑고 지나간 코드의 비율입니다. 전체 1000줄 중 720줄이 한 번이라도 실행됐으면 72퍼센트입니다. 낮으면 확실히 위험하지만 높다고 안전하지는 않다는 점 때문에 다루기가 까다로운 숫자입니다.
2. 플레이키 테스트 — 코드를 하나도 안 고쳤는데 어떤 날은 통과하고 어떤 날은 실패하는 테스트입니다. 대개 시간이나 순서에 기대는 코드가 원인입니다. 이게 늘어나면 팀이 빨간불을 보고도 "또 걔네" 하며 그냥 다시 돌리게 되고, 그 순간부터 테스트는 경고 기능을 잃습니다.
3. 품질 보증 — 나가기 전에 품질을 점검하고 보장하는 활동 전체입니다. 자동으로 도는 테스트도 여기 들어가지만, 사람이 직접 써 보며 어색한 데를 찾는 일과 무엇까지 확인하고 내보낼지 기준을 정하는 일도 함께 들어갑니다.
4. 결함 쪽은 찾아낸 뒤를 다룹니다. 버그는 의도와 다르게 도는 결함 자체이고, 심각도는 그 결함이 서비스에 끼치는 영향의 크기라 결제가 막히는 것과 글자가 어긋나는 것을 같은 줄에 두지 않게 해 줍니다. 재현 절차는 그 결함을 다시 일으키는 순서를 적은 기록이고, 이게 없으면 고치는 사람이 먼저 한 시간을 들여 상황을 되살려야 합니다.

여덟 갈래는 한 줄로 이어집니다. 범위가 무엇을 얼마나 넓게 볼지 정하고, 목적이 그것을 언제 돌릴지 정하고, 방법과 도구가 실제로 쓸 수 있게 만들고, 지표가 얼마나 덮였는지 보여 주고, 문제 갈래가 그 신호를 믿을 수 있는지 감시하고, 활동과 결함이 걸린 것을 사람 손으로 넘깁니다.

"이 PR 빨간불인데요. 머지 전에 한번 보고 가시죠."

합치려는 코드에서 실패한 테스트가 있으니 원인을 확인하고 나서 합치자는 말입니다.

"급하면 E2E 는 빼고 나가죠. 대신 배포 직후 스모크는 꼭 돌리고요."

전체 확인에 드는 시간이 없으니 느린 쪽을 건너뛰되, 나간 직후 핵심이 살아 있는지는 반드시 보자는 절충안입니다.

"그거 테스트에 없던 경우라 그냥 통과한 거예요. 케이스부터 추가하고 고칠게요."

테스트가 틀린 게 아니라 그 상황이 애초에 적혀 있지 않았다는 뜻이고, 고치기 전에 그 상황을 먼저 적어 두겠다는 말입니다.

앞의 공유 링크 사고 뒤에 페이지덱은 한 가지를 바꿨습니다. 태오가 권한 확인 코드에 대해 "초대받은 사람은 만료된 링크와 무관하게 문서를 열 수 있어야 한다" 를 테스트로 적어 두었습니다. 같은 사고가 다시 나려면 이제 그 테스트가 먼저 빨간불이 되어야 합니다.

지현은 이 흐름을 기획 쪽에서 씁니다. 새 기능 문서를 넘길 때 "이건 꼭 확인되어야 하는 경우" 를 서너 줄 적어 두고, 태오가 그 줄을 그대로 테스트 이름으로 옮깁니다. 기능이 나간 뒤에 수아가 고객에게서 받은 문제도 같은 자리로 들어갑니다. 한 번 겪은 일은 사람이 기억하는 대신 테스트가 기억하는 쪽으로 옮겨 둡니다.

테스트가 전부 통과하면 버그가 없다고 읽는 것이 가장 흔한 오해입니다. 초록불이 화면 가득 뜨니 그렇게 보이는 것도 무리가 아닙니다. 하지만 테스트는 누군가 미리 적어 둔 경우만 확인합니다. 적히지 않은 상황은 확인 대상이 아니라 아예 존재하지 않는 것으로 취급됩니다. 이름이 200자인 파일을 올리는 경우를 아무도 적어 두지 않았다면 그 경우는 영원히 초록불 안에 들어오지 않습니다. 이 오해를 그대로 두면 팀은 초록불을 출시 허가로 읽기 시작하고, 커버리지 90퍼센트짜리 제품에서 장애가 난 날 "테스트가 다 통과했는데 왜" 라는 말부터 나옵니다. 통과는 적어 둔 것이 안 깨졌다는 뜻이지 안 적은 것이 멀쩡하다는 뜻이 아닙니다.

두 번째는 테스트를 기능 개발에 덧붙는 추가 작업으로 읽는 것입니다. 기능 하나에 코드를 두 벌 쓰는 것처럼 보이니 급할 때 가장 먼저 빼고 싶어집니다. 실제로는 이미 하고 있던 확인을 앞으로 당겨 한 번만 쓰는 일에 가깝습니다. 손으로 확인하는 팀도 배포마다 같은 화면을 다시 눌러 보고 있고, 그 시간은 테스트를 쓰지 않아도 매번 나갑니다. 계속 빼기로 하면 배포 전 손 확인이 반나절짜리 일이 되고, 반나절이 부담스러워지면 배포를 주 1회에서 격주 1회로 미루게 됩니다. 그러면 한 번에 나가는 변경이 커지고, 커진 만큼 사고가 났을 때 원인을 찾기 어려워집니다.