품질 보증

만든 사람이 자기 코드를 확인하고 바로 배포하던 시절이 있었습니다. 작은 팀에서는 이 방식으로 돌아갑니다. 무엇을 건드렸는지 본인이 알고 있고, 문제가 생기면 그 자리에서 고칩니다.

사람이 늘고 기능이 얽히면서 이 방식이 깨졌습니다. 만든 사람은 자기가 의도한 경로로만 눌러 보게 됩니다. 파일을 올리다가 중간에 취소하는 경우, 권한이 없는 계정으로 링크를 여는 경우, 브라우저를 두 개 띄워 같은 문서를 동시에 고치는 경우는 만든 사람의 머릿속에 없던 경로입니다. 더 큰 문제는 이번에 건드리지 않은 곳이 함께 깨지는 일입니다. 공유 기능을 고쳤는데 댓글 알림이 멈추는 식인데, 이것은 만든 사람이 확인할 목록에 애초에 들어 있지 않습니다.

품질 보증은 그 확인을 만드는 일과 분리해 별도의 활동으로 세운 것입니다. 만든 사람이 아닌 눈으로, 정해진 목록에 따라, 내보내도 되는지를 판정합니다. 테스트를 한 번 더 돌리는 일이 아니라 배포 결정을 떠받치는 절차라는 점이 이 활동의 성격입니다.

무엇을 확인할지 목록으로 만들고, 그 목록을 따라 눌러 보고, 발견한 것을 등록해 고쳐진 것을 다시 확인하는 순서로 돌아갑니다.

1. 확인할 것을 목록으로 적습니다. 이번에 바뀐 기능의 정상 경로와 실패 경로, 그리고 이번에 건드린 코드가 닿는 다른 기능을 적습니다. 요구를 적은 문서에 이 스토리가 끝났다고 인정받기 위한 조건인 인수 조건이 적혀 있으면, 그 문장이 그대로 목록의 첫 칸이 됩니다.
2. 기계가 볼 것과 사람이 볼 것을 나눕니다. 함수 하나를 떼어 보는 단위 테스트와 브라우저를 띄워 흐름 전체를 밟는 E2E 테스트는 자동으로 돕니다. 사람은 기계가 판정하기 어려운 것을 봅니다. 문구가 상황에 맞는지, 오류 안내가 다음에 무엇을 하라고 알려 주는지, 화면이 어색하지 않은지 같은 것입니다.
3. 안 건드린 곳을 확인합니다. 고친 뒤에 원래 되던 것이 그대로 되는지 보는 회귀 테스트가 이 자리입니다. 목록이 쌓일수록 시간이 늘어나므로 자주 깨지는 것부터 자동으로 옮깁니다. 손으로 도는 목록이 200개를 넘기면 배포마다 이틀이 들고, 그때부터는 목록을 줄이는 쪽으로 사람이 움직입니다.
4. 발견한 것을 등록합니다. 재현 절차와 기대한 동작과 실제 동작을 적고, 서비스에 끼치는 영향의 크기인 심각도를 붙입니다.
5. 고쳐진 것을 다시 확인하고 판정합니다. 남은 결함의 심각도를 놓고 내보낼지 미룰지를 정합니다. 배포 직후에는 핵심만 빠르게 보는 스모크 테스트로 되돌릴지를 몇 분 안에 판단합니다.

전담하는 사람이 있는 조직에서는 그 사람이 목록을 만들고 판정을 주도합니다. 전담이 없는 팀에서는 만든 사람이 아닌 다른 개발자가 그 역할을 맡습니다. 어느 쪽이든 원칙은 하나입니다. 만든 사람이 자기 것의 마지막 판정자가 되지 않게 합니다.

들어오는 사람은 셋 더 있습니다. 화면을 그린 디자이너는 구현이 시안과 맞는지 보고, 요구를 적은 프로덕트 매니저는 이번에 하기로 한 범위가 다 들어왔는지 봅니다. 고객 지원은 지난 분기에 문의가 많았던 자리를 목록에 넣어 달라고 요청합니다. 사용자가 실제로 걸린 곳을 아는 쪽이 여기라 목록의 품질이 이 요청에서 올라갑니다.

시점은 배포 주기에 붙습니다. 페이지덱은 주 두 번 배포하고, 배포 전날 오후를 이 활동에 씁니다. 여기에 더해 두 번의 시점이 더 있습니다. 하나는 기능을 만드는 중간입니다. 다 만든 뒤에 목록을 받으면 고치는 값이 커지므로, 목록을 개발 시작 전에 공유해 만드는 사람이 그 경로를 먼저 밟아 보게 합니다. 다른 하나는 사고가 난 뒤입니다. 놓친 경로를 목록에 더해 같은 종류가 다시 나가지 않게 합니다.

"이번 배포에 남은 결함이 셋인데 전부 심각도 낮음이에요. 나가도 됩니다."

판정의 근거를 심각도로 정리한 말입니다.

"이 기능 목록을 개발 시작 전에 주세요."

확인할 경로를 미리 알고 만들겠다는 요청입니다.

"공유는 고쳤는데 알림이 멈췄어요. 회귀에서 잡혔습니다."

건드리지 않은 곳이 깨진 사례를 보고하는 말입니다.

페이지덱에서 문서 공유 권한을 고친 배포가 이 절차에서 멈춘 적이 있습니다. 태오가 만든 것은 정상 경로에서 잘 돌았는데, 목록에 있던 실패 경로 하나에서 권한이 없는 계정도 링크를 열 수 있었습니다.

발견한 쪽은 그것을 심각도 높음으로 등록했고 배포는 하루 미뤄졌습니다. 그 하루가 아까워 보일 수 있지만, 같은 결함이 나간 뒤에 발견됐다면 이미 만들어진 링크 전부를 점검해야 했습니다. 이 활동이 사는 자리가 그 차이입니다. 하루를 쓸지 이미 나간 링크를 전부 점검할지의 선택입니다.

테스트와 같은 말로 아는 경우가 가장 많습니다. 실제로 하는 일의 대부분이 테스트이니 자연스러운 오해입니다. 하지만 테스트는 코드가 의도대로 도는지 확인하는 수단이고, 품질 보증은 그 수단들을 언제 무엇에 쓸지 정하고 결과로 배포를 판정하는 활동입니다. 테스트를 아무리 많이 두어도 무엇을 확인하지 않기로 했는지가 정해져 있지 않으면 매번 다른 것을 놓칩니다.

품질을 이 활동이 만든다고 보는 것도 흔합니다. 이름에 보증이 붙어 있으니 여기서 품질이 결정되는 것처럼 보입니다. 그런데 이 자리에서 할 수 있는 일은 이미 만들어진 것 안에서 어긋난 것을 찾는 것까지입니다. 설계가 잘못됐거나 요구가 애매하게 적힌 것은 여기서 고칠 수 없고, 발견해 되돌려 보내는 것이 전부입니다. 그래서 이 활동만 강화하면 배포 직전에 되돌아가는 일이 늘어납니다. 목록을 개발 앞쪽으로 옮기는 것이 이 오해에 대한 실무적 답입니다.