1,000개의 오류, 구글 시트 하나, 그리고 다시는 되돌릴 수 없는 5시간
모든 버그에는 이야기가 있습니다. 이 이야기는 "내 컴퓨터에서는 잘 되는데"라는 거짓말로 시작되었습니다.
우리는 리드 생성(lead generation) 기업을 위한 데이터 가져오기 기능을 테스트했습니다. 간단해 보였습니다. 버튼을 클릭하고, 파일을 업로드하면 데이터가 로드되는 방식이었죠.
대부분의 사람들은 이런 기능이 잘 작동할 것이라고 가정합니다. 테스터는 그 가정이 틀렸음을 증명하기 위해 존재합니다.
'해피 패스(happy path)'는 함정입니다.
깔끔한 엑셀 파일을 업로드하면 시스템은 통과합니다. 점심을 먹으러 가죠. 일이 끝났다고 생각합니다. 하지만 거기서 멈춘다면, 여러분은 결함이 있는 코드를 배포하게 됩니다. 고객은 월요일 아침 운영 환경(production)에서 그 오류를 발견하게 될 것입니다.
문제는 구글 시트였습니다.
실제 사용자들은 깔끔한 엑셀 파일을 사용하지 않습니다. 그들은 엉망진창인 구글 시트를 사용합니다. 스프레드시트에 혼돈을 만들어 놓고 시스템이 이를 처리해주길 기대하죠.
구글 시트를 업로드했을 때 시스템은 실패했습니다. 1,000개가 넘는 오류가 발생했습니다. 데이터와 버튼은 동일했지만, 형식이 바뀌었다는 이유만으로 시스템이 완전히 무너져 버린 것입니다.
그래서 우리는 데이터 품질을 테스트했습니다.
- 잘못된 행이 몇 개 있다면? 시스템은 이를 건너뛰고 계속 진행했습니다.
- 엉망인 행이 수백 개라면? 시스템이 망가졌습니다.
검증 로직은 사소한 오류에는 작동했습니다. 하지만 쓰레기 데이터가 산더미처럼 쌓이자 실패했습니다.
우리는 이 문제를 디버깅하는 데 5시간을 썼습니다. 파일 탓도 하고, 브라우저 탓도 하고, 데이터 탓도 했습니다. 심지어 커피 탓까지 했죠.
그 5시간은 저렴한 편이었습니다. 그 대안은 훨씬 더 컸을 테니까요. 고객이 이 버그를 발견하면 제품에 대한 신뢰를 잃게 됩니다. 테스트 단계의 버그는 시간으로 비용을 치르지만, 운영 단계의 버그는 고객으로 비용을 치르게 됩니다.
저는 차라리 시간으로 치르는 쪽을 택하겠습니다.
진짜 버그를 찾으려면 사고방식을 바꿔야 합니다. 소프트웨어가 작동하는지 묻지 마세요. 어떻게 하면 망가뜨릴 수 있을지를 물으세요.
개발자처럼 생각하는 것을 멈추고, 다음과 같이 생각하기 시작하십시오.
- 잘못된 파일 형식을 업로드하는 게으른 사용자.
- 병합된 셀과 빈 행이 가득한 혼란스러운 사용자.
- 깔끔한 데이터 10개 대신 지저분한 레코드 4,000개를 밀어 넣는 대량 사용자.
- 하지 말아야 할 행동만 골라서 하는 트러블메이커.
소프트웨어는 예상치 못한 입력값에서 망가집니다.
'단순한' 기능이 가장 위험합니다. 가져오기 버튼과 검색창은 무해해 보이지만, 그렇지 않습니다.
다음에 어떤 기능이 해피 패스를 통과한다면, 이렇게 질문하는 사람이 되십시오. "상상할 수 있는 최악의 파일을 업로드한다면 어떻게 될까?"
그러고 나서 실제로 해보십시오.