완벽한 건 있을 수 없다지만
앱 서비스를 만들거나 기타 IT 소프트웨어 직종에 일하는 사람이라면, 배포 후에 예상치 못한 치명적인 결함으로 고통받은 경험이 한 번쯤은 있을 것이다. 만약 꽤 오랜 시간 일을 했음에도 그런 경험이 아직 없다면, 앞으로 일하면서 꼭 한 번은 겪을 테니 너무 걱정하지 않아도 된다. 아무리 대단한 QA 팀을 가졌다 할지라도 거의 불가능한 일이기 때문이다.
오늘 배포도 그랬다. 새로 앱 배포를 했고, 정말 많은 테스트를 진행했는데 로그인의 한 파트에서 치명적 결함이 있었다. 꽤 많은 리팩토링 작업이 있었던 배포이기에, 회원 가입 절차가 개발 범위는 아니었지만 혹시나 하는 마음에 테스트를 했지만, 설마 하고 하지 않았던 딱 그 파트에 버그가 숨어 있었을 줄이야. 정말 땅을 치고 후회할 일이었다. 이 오류를 대응하느라 중요한 회의는 미뤄졌고 약 3일 치의 일정이 꼬여버렸다. 막대한 피해라 할 수 있겠다.
테스트는 늘 귀찮고 고역스러운 작업이다. 아직 테스트 자동화를 제대로 해둔 큰 서비스를 경험해 본 적은 없다. 하지만 자동화를 한다고 해도 어딘가 찾지 못한 구멍은 생길 수 있다. 때문에 어느 정도 이상의 수작업은 불가피하고, 그 과정에서 인내심을 갖고 꼼꼼히 하나한의 기능을 빈틈없이 봐야 하는데, 정말 머피의 법칙처럼 한 두 개 안 봤던 그곳에 버그가 숨어있다.
일에 완벽함이란 추구하는 것이지 존재하기 어렵다고 생각한다. 그리고 그 완벽함을 제대로 추구하는 것도 정말 쉽지 않은 작업이다. 우리는 늘 200의 노력을 들여 90의 결과물을 만들지, 100의 노력을 들여 80의 결과물을 만들지 고민한다. 리소스가 한정된 스타트업에서는 굉장히 중요한 결정 사항이다. 이 과정에서도 정답은 없고, 완벽한 것이란 없다. 결국에는 어떤 결과가 나오느냐에 그 선택의 옳고 그름이 결정되기 때문에 의사결정의 순간에 최대한 경우의 수를 따져 예측하는 수 밖에 없다.
그리고 테스트할 때는 뭔가 찝찝한 부분이 생각날 땐 꼭 거기는 한 번 봐야 한다. 치명적인 버그 한 마리가 거기 숨어있기 때문이다.