제15화. 오픈 전의 공포, 통합 테스트에서 모든 독을 빼내야 한다
아들아, 프로젝트의 종착역이 보일 때쯤 '통합 테스트'라는 거대한 장벽이 나타난단다. 단위 테스트가 개별 부품의 성능을 확인하는 것이라면, 통합 테스트는 그 부품들이 모여 전체 시스템으로 작동하는지 확인하는 마지막 관문이지. 여기서 모든 '독(결함)'을 걸러내지 못하면, 그 독은 오픈 날 시스템(서비스)의 심장을 겨누게 된단다.
개발자가 만든 가짜 데이터로 하는 테스트는 테스트가 아니야. 실제 사용자가 입력할 법한 엉뚱한 값, 상상 이상의 대량 데이터, 그리고 절대로 일어나지 않을 것 같은 예외 상황까지 모두 시나리오에 담아야 한단다.
연습에서 흘린 땀 한 방울이 실전에서의 피 한 방울을 대신한다는 사실을 잊지 마라.
아빠의 노하우: 아빠는 현업 사용자들을 테스트에 깊숙이 참여시켰단다. 그들이 평소 업무 하던 방식 그대로 시스템을 헤집어 놓게 두었지. 기획서에는 없던 '사용자의 습관'에서 터져 나오는 결함이야말로 오픈 전에 반드시 잡아야 할 치명적인 독이란다.
통합 테스트 초기에는 결함이 쏟아지는 게 당연해. 오히려 결함이 발견되지 않는 것을 더 경계해야 하지. 중요한 건 발견된 결함이 얼마나 빨리 수정되고, 전체 결함 발생 그래프가 완만하게 꺾이고 있느냐를 판단하는 데이터적 안목이란다.
결함 발생 건수가 줄어들지 않는다면, 오픈 날짜를 미루는 용기도 PM의 실력이란다.
아빠의 노하우: 아빠는 매일 아침 '결함 관리 보드'를 보며 추이를 분석했어. 새로 발생하는 결함보다 '재발하는 결함'이 많다면 로직 자체가 꼬였다는 신호지. 숫자가 주는 경고를 무시하고 감으로 "어떻게든 되겠지"라며 오픈을 강행하는 것만큼 위험한 도박은 없단다. 만약 오픈을 강행하게 되면 그때부터는 여기저기에서 불나는 VOC 관련 내용과 실제 개발 로직의 변경을 병행해서 처리를 해야 해… 그렇게 되면 처리할 수 있는 시간도 확보가 어렵고, 개발 내용에 대한 안정성도 장담을 못하는 경우가 많단다.
바쁘다 보니 개발자들이 에러가 안 나게끔만 살짝 코드를 우회해서 고치는 경우가 있단다. 이건 독을 뺀 게 아니라 잠시 가려둔 것에 불과해. 통합 테스트 기간에는 눈앞의 현상만 고치는 것이 아니라, 그 오류가 왜 발생했는지 뿌리를 캐내야 한단다.
보이는 구멍만 메운 배는 큰 바다에 나가면 반드시 가장 약한 곳부터 터지게 되어 있단다.
아빠의 노하우: 아빠는 중요한 결함이 고쳐졌다고 하면 "왜 이런 일이 생겼고, 다른 곳엔 영향이 없느냐"를 집요하게 물었어. 한 곳을 고쳤을 때 다른 열 곳이 망가지는 '회귀 결함'을 막는 것이 통합 테스트의 핵심 중 핵심이란다. 예를 들어 풍선의 한쪽을 누르면 다른 쪽이 툭 튀어나오듯, 로직 하나를 건드리면 전혀 상관없어 보이는 곳에서 사고가 터지곤 한단다. 그게 바로 무서운 회귀 결함이지.
이 시기 팀원들은 극도의 피로와 불안감을 느낀단다. "정말 오픈할 수 있을까?" 하는 의구심이 팀 전체를 지배하기 쉽지. 이때 PM이 중심을 잡지 못하고 흔들리면 배는 산으로 가버린단다.
팀원들이 끝까지 집중력을 잃지 않도록, 네가 가장 든든한 방파제가 되어주어야 한단다.
아빠의 노하우: 결함이 쏟아져 분위기가 가라앉을 때, 아빠는 오히려 "지금 다 발견되어서 정말 다행이다. 오픈 후에 터졌으면 어쩔 뻔했느냐"며 격려했어. 결함을 찾아낸 사람을 칭찬하고 고치는 사람을 지원하며, 우리가 지금 독을 성공적으로 빼내고 있다는 확신을 주는 것이 PM의 역할이란다.
한 마디
"통합 테스트는 시스템의 완성도를 검증하는 시간이기도 하지만, 너와 네 팀의 인내심을 증명하는 시간이기도 하단다. 여기서 꼼꼼하게 걸러낸 독만큼, 오픈 날 너는 편안하게 웃을 수 있을 거란다."
오픈 전, 다음 5가지 질문에 자신 있게 "예"라고 답할 수 있는지 확인해 보렴.
[결함 종결] 업무에 치명적인 영향을 주는 'Critical' 등급의 결함이 모두 해결되었는가?
[데이터 정합성] 테스트를 거친 데이터들이 DB에 설계된 규칙대로 정확하게 저장되었는가?
[인터페이스 확인] 외부 시스템(결제, 인증, 메일 등)과의 연동이 실제 환경에서 정상 작동하는가?
[성능 및 부하] 예상되는 최대 동시 접속자가 몰려도 시스템이 멈추지 않고 견디는가?
[복구 플랜] 만에 하나 오픈 시 문제가 생겼을 때, 이전 상태로 되돌릴 '롤백(Rollback)' 계획이 완벽한가? 특히 데이터 이관이 있는 경우, 데이터의 원복에 대한 부분과 잠깐이라도 생긴 증감분에 대한 처리까지 꼼꼼하게 챙겼는가?