새벽의 전화 한 통

새벽 1시쯤 운영팀 근무자에게 전화가 걸려왔다. 지난주에 구축한 시스템에서 신규로 OO 정보 등록이 안된다는 것이다. 아차! 그러고 보니 새로운 시스템을 구축하고 기존의 OO 정보를 그대로 덤프해서 DB에 등록하고 UI에서는 등록하는 테스트를 한 번도 안했다.

부리나케 노트북을 열고

부리나케 노트북을 열고 로그를 확인해 본다. 최근에 UI에서 불필요한 항목을 제거하면서 API 코드는 호환성을 위해 그대로 남겨두는 결정을 했는데, 그러려면 UI에서 사용되지 않는 데이터의 디폴트 값을 내부적으로 입력해서 API에 요청을 해야했다. API 등록 요청 시 디폴트 값 입력이 빠져있어서 문제가 발생했다.

사람에게서 문제 찾기

새벽에 다행히 해당 파트 개발자 분께서 깨어 있어 간단히 수정해서 배포하고 문제를 일단락 할 수 있었지만 왜 이런 문제가 발생했는지 회고해 보았다. 첫 번째는 프론트엔드 개발자도, 나도 해당 기능 테스트를 하지 않았다. 테스트를 하지 않은 우리 두 사람에게 책임이 있다.

시스템에서 문제 찾기

어느 글에서 장애의 원인을 사람에게서 찾지 말고, 시스템에서 찾고 시스템을 개선하라는 글을 본적이 있다. 코드의 문제점을 테스트하지 않고 배포한 것을 문제로 볼 것이 아니라 왜 테스트하지 않았는데 배포가 될 수 있게 시스템이 허용하고 있는지 찾고 개선하라는 것이다. 배운걸 적용해 볼 기회다. 우리 개발 시스템을 돌아보니 우리 회사는 백엔드 파트만 자동화된 테스트 케이스를 작성하고 있고 프론트엔드 쪽은 전적으로 사람의 테스트에 의존하고 있다. 그리고 백엔드 역시 아직 제대로 된 CI/CD 환경이 구성되어 있지 않아 사람의 손을 많이 거친다. 백엔드 테스트케이스 역시 배포 시 자동으로 전체를 검증하게 되어 있지 않다. 이것이 진짜 문제인 것이다.

결정 과정에서의 문제 찾기

시스템의 문제 뿐만은 아니다. 우리의 의사결정 과정에도 문제는 있었다. 사실 앞에서 호환성이라는 핑계를 대었지만 사실은 API 쪽에서도 모두 삭제해 줄 수 있는 일이었다. 다만 API 담당자가 정말 너무 바빠서 손 안대고 일단 넘어가기 위해 일종의 부채를 쌓아둔 것이었다. 이 부분은 이미 인지하고 의사결정한 부분이라 문제라고 보지 않기로 한다.

진짜 해결책

이제 정리가 좀 된다. 문제의 재발 방지를 위해서는 프론트엔드 코드 그리고 통합된 제품에 대한 자동화된 테스트 시스템이 필요한 것 같다. 그리고 배포 시에 백엔드도 프론트엔드도 전체 테스트 케이스를 통과한 경우에만 배포가 가능하도록 시스템이 개선되어야 겠다. 곧 프론트엔드 파트에 새로운 분이 입사하시는데 그 분이 오시면 기존 시스템 파악도 하시고 회사에 적응도 하실 겸 프론트엔드 코드 테스트 프레임워크를 스터디하고 환경 구축을 해보면 어떨지 생각해 본다. 좀 찾아보니 Jest, TestCafe 같은 프레임워크가 눈에 띄지만 뭘 사용하면 좋을지는 아직 잘 모르겠다. 구글 트렌드 검색을 해보니 Jest가 압도적으로 검색량이 많은 걸로 봐서 많이 쓰이는 것 같기는 하다. 다른 회사에서는 프론트엔드 테스트 코드나 e2e 테스트 자동화 시스템은 어떻게 구축되어 있는지 궁금해진다.