개발자 라면 한번쯤은 내가 배포한 코드로 인해서 장애가 나지 않길, 간절히 기도해 본적이 있을 것이다. 왜 기도를 하게 될까? 아마도 통제할 수 없는 예상치 못한 결과가 발생할 수도 있을 것 같다 라는 불안감 때문일 것 같다.
어떻게 해결 할 수 있을까? 나는 주로 다음과 같이 한다.
- 내가 통제할 수 있는 범위로 좁힌다.
- 예상할 수 있는 결과(Expected Behavior)에 대한 모든 경우의 수를 대비한다.
- 예상할 수 없는 결과(Unexpected Behavior)가 발생한다면, 예상할 수 있는 결과로 만든다.
- 1, 2, 3 을 계속 반복한다
1. 내가 통제할 수 있는 범위로 좁힌다
통제할 수 있는 범위로 좁히는 것은 2, 3번을 수행하기 위해서 반드시 선행 되어야 한다. 범위가 너무 크게 되면, 2, 3번을 하는 과정에서 빈틈이 생길 수 있기 때문이다. 개인적으로 개발 작업을 할 때, 티켓(일감)을 잘게 쪼개는 것을 선호한다. 하나의 티켓에서는 내가 통제할 수 있는 수준의 범위에서, 특성별로 잘게 나눈다. 이 범위는 내 코드를 리뷰 해주는 사람을 배려하는 차원에서도 너무 넓히지 않도록 해야한다
2. 예상할 수 있는 결과에 대한 모든 경우의 수를 대비한다
내가 현재 개발하는 서비스 도메인의 인수 조건을 생각 해보자. 인수 조건은 일종의 체크 리스트 이다. 체크 리스트가 모두 통과 되어야 만 내가 개발하고 있는 제품이 고객에게 릴리즈 될 수 있다.
코드 작성을 하기 전에, 내가 예상 할 수 있는 모든 경우의 수를 먼저 생각을 하고 체크리스트를 작성 해보자. 이것을 사용자향으로 작성한다면, E2E 테스트로 치환될 수 있는 인수 테스트가 된다. 인수 테스트의 하위레벨 기준으로, 작성한다면, 통합 테스트 혹은 단위 테스트가 될 수 있다. 이제 작성한 리스트는 테스트 코드로 직접 구현하고, 확인이 된 것들은 체크 표시를 한다. 여기까지 완료된다면, 시스템적으로는 회귀테스트가 가능한 상태이면서, 내가 예상할 수 있는 경우의 수는 모두 커버가 된 상황으로 볼 수 있다.
3. 예상 할 수 없는 결과가 발생한다면, 예상할 수 있는 결과로 만든다.
예상할 수 있는 모든 것을 커버했기 때문에 이제는 예상할 수 없는 요소에 대해서만 신경쓰면 된다. 이 예상할 수 없는 요소들은 말 그대로 예상치 못하게 발생할 수 있기 때문에, QA 과정에서 탐색적 테스팅을 통해 사전에 발견하거나, 코드 배포 이후에 모니터링 통해서도 인지 할 수 있다. 이때는 빠르게 디버깅을 하여서 원인을 찾고 고치는 것이 중요하다. 원인을 찾고 고치는 과정에서 테스트 코드를 작성하자. 테스트 코드를 통해서 예상하지 못했던 버그는 내 통제하에서 예상할 수 있는 것이 될 수 있다. 이것을 차곡차곡 쌓아서, 예상할 수 없는 결과가 모두 예상할 수 있는 결과로 바뀐다면, 더이상 불안할 이유가 없다.
위 과정을 거쳤음에도, 커버하지 못한 케이스는 정말로 엣지 케이스일 가능성이 높다. 이것은 내가 통제할 수 있는 수준의 범위를 넘어서는 외부 요인이기 때문에, 너무 고통받을 필요는 없을 것 같다. 그저 내가 예상할 수 있는 것으로 만들기 만 하면 된다.
불안할 수록 내가 예상할 수 있는 범위를 넓히도록 노력하자. 그 범위가 높아질 수록 불안은 사라질 것이다.
