API 사용자와 에러 발생 상황 공유를 위한 한걸음

나는 첫 회사에서 작업을 거진 홀로 진행하였다. 당시에는 임베디드 시스템 개발자였고 간간히 웹을 건드리기도 했지만 대부분 그 때도 전부 홀로 작업하는 경우가 대다수였다. 그 때문인지 웹 백엔드로 전향을 한 뒤 이직에 성공한 후, 협업을 하면서 에러 발생 상황을 빠르게 공유하는 방법에 대해 많은 고민을 했었다. 실무에서는 Swagger 문서를 최대한 상세히 적었었고 퇴사 이후 사이드 프로젝트를 진행하면서 개발 초기 단계에서 바로 ELK 스택을 적용시켜두고 TraceId를 발급하여 문제가 된 에러를 검색할 수 있게 하는 방법 등을 사용했다.

막상 이 방식을 사용해도, 이게 문제 해결을 위해 소통하는 절차가 짧아졌을 뿐 뭔가 부족하다는 느낌을 많이 받았다. 보통 문제가 발생하면 아래와 같은 상황이 펼쳐진다

API 사용자: API 사용했는데 에러가 발생해요
나: 어떤 Endpoint 말씀하시는 건가요? 
API 사용자: https://... 이거에요.
나: TraceId 어떻게 되나요?
API 사용자: 잠시만요, 다시 해보고 에러 발생하면 보내드릴게요.
... 한참 뒤
API 사용자: TraceId 전달드립니다. ...
나: (키바나에 접속해서 TraceId로 로그 전부 보고있기)

API에 에러가 발생했다는 로그를 기록은 해두지만, 결국 이를 확인하기 위해서는 추적을 위한 정보를 API 사용자에게 요구해야 했다. 방금 테스트를하고 에러가 발생해서 보낸 경우엔 엔드포인트만 보고 로그를 뒤지면 그나마 나은 수준이었다.

Slack이나 Discord로 에러 상황을 바로 리포팅하자

세부 로직에 문제가 있는 경우는 로그를 보면서 잘못된 부분을 캐치해야 하지만 에러 발생 상황에 대한 공유는 즉시 가능하다. 난 Azure CI/CD, 젠킨스를 쓰면서 이미 Slack이나 Discord로 웹훅을 보내 테스트 결과, 빌드 결과등을 받도록 해놓았는데 API 개발중에도 테스트 서버에서 에러가 발생하면 Endpoint, Method, Request Body, Response Body 등을 전부 보내면 되는 일이었다. 에러가 발생하면 알람이 울리고, API 사용자는 해당 메시지만 나에게 링크를 걸어 전달해주면 곧바로 로그 확인 작업을 효율적으로 진행할 수 있는 것인데 참 어렵게도 일을 한 것이다.

멍청하면 손발이 고생한다...