[인턴] Slack 봇, 운세구르미 – 3일간의 이슈 해결 (2편)

들어가기 전에

테스트 워크스페이스에서 수많은 테스트를 거쳤기에, 런칭 후에도 문제가 없을 것이라 생각했습니다 (희망편) ^_^ 그러나 실제 배포 환경인 사내 Slack 워크스페이스에는 약 150명의 직원이 있어, 테스트 단계에서 경험하지 못한 다양한 이슈가 발생했어요. 특히 사용자들에게 매일 운세 메시지를 전송해야 했기에, 즉각적인 원인 파악과 대응이 필수였습니다. 결국 3일에 걸쳐 매일 다른 이슈를 만나며 문제를 해결해 나갔고, 이후 일주일 이상 운영한 결과 다행히도 추가적인 문제는 발생하지 않았다고 해요. 휴-

---

첫 날 이슈

1. 메시지를 받지 못한 사람이 있었다.

   몇몇 팀원들이 Slack 프로필에 생년월일을 등록했음에도 불구하고 메시지를 받지 못했습니다. 나 역시 메시지를 받지 못해 운세 메시지 전송이 실패한 줄 알고 서버를 재실행했는데, 알고 보니 일부에게만 메시지가 전송되고 일부는 받지 못한 상황이었어요. 결국 어떤 사람은 메시지를 두 번 받거나, 아예 받지 못했던 것 🥲

   • 원인: 별도의 설정이 없을 경우, Slack 데이터는 한 번에 최대 100건까지만 조회할 수 있으며, 기본적으로 메시지도 100건씩 발송된다. 이로 인해 일부 메시지가 누락되는 문제가 발생했습니다.
   • 해결: 캐시를 활용하여 추가적으로 약 50건의 메시지를 발송하도록 개선했어요.

둘째 날 이슈

1. 생년월일을 등록하지 않은 경우, 관련 메시지는 한 번만 발송되어야 합니다.

   • 원인: 원래는 캐시 기능을 활용하여 생년월일 등록 안내 메시지가 중복 발송되지 않도록 처리했으나, 서버 재실행 시 캐시가 초기화되면서 예상치 않게 메시지가 여러 번 발송되는 문제가 발생한 것으로 보였어요.
   • 임시 조치: 이미 많은 사용자가 생년월일을 등록해야 운세 메시지를 받을 수 있다는 점을 인지한 상황이었고, 서버 재실행 시 캐시가 초기화되는 이슈가 지속될 가능성이 있어, 생년월일이 미등록된 경우에는 메시지를 아예 발송하지 않도록 수정했어요.

   

2. 생년월일 입력이 없는데, 운세 메시지가 발송되는 오류

   생년월일을 등록하지 않았는데도 메시지를 받았다는 CS 문의를 접수했어요. 제보를 통해 확인해 보니, 해당 사용자가 생년월일이 아닌 시작날짜(=입사날짜)만 등록해둔 상태였습니다.

   • 원인: 입력된 날짜가 있으면 생일로 인식하는 로직 때문에, 시작 날짜가 생년월일로 잘못 해석되어 메시지가 발송된 이슈
   • 해결: 생년월일과 시작 날짜 필드를 구분하여, 생년월일 입력이 된 경우에만 메시지가 발송되도록 수정

3. 약 9 ~10개 메시지를 반복적으로 보내는 오류

   • 원인: 컨테이너 내 코드 저장 버튼을 여러 차례 눌러 중복 실행이 발생

   • 해결1: 컨테이너를 새로 시작

   • 해결2: Slack API 공식문서 확인한 결과, 기본적으로 100건씩 사용자 정보 조회가 가능하며, 최대 1,000건까지 한 번에 가져올 수 있다는 것을 알게 되었어요. 그래서 코드상에 limit을 500으로 상향 조정하고, 캐시 없이도 하루 한 번 메시지를 발송하도록 변경했습니다..

     현재 직원 수가 약 150명 정도이고, 캐시 없이도 메시지가 정상적으로 한 번씩 발송될 것이 보장되므로 불필요한 캐시 관련 코드는 삭제했습니다.

     

4. 예외처리 (추가 구현)

   특정 대상자를 제외하고 메시지를 발송할 수 있도록 기능을 추가 구현하였습니다.

셋째날 이슈 (마지막)

1. 사용자의 생년월일 조회가 되지 않는 문제가 발생했어요.

   전날 테스트 워크스페이스에서 생년월일과 시작날짜를 구분하여 조회하도록 설정하였지만, 실시간 로그를 확인해 보니 생년월일 조회가 아예 안되고 있었던 것…!

   • 원인: 워크스페이스마다 생년월일 필드값이 달랐어요.
   • 해결: 로그를 통해 정확한 생년월일 필드값을 확인하고 수정한 후, 정상적으로 메시지가 발송되었어요. ✨ (로그 확인이 어렵다면 Slack API Test 에서 Slack Bot Token과 멤버ID를 입력하고 API 응답값을 통해 조회가 가능)

   

---

회고

테스트를 많이 하더라도 실전 환경과 완전히 동일하게 재현할 수는 없기 때문에, 실제 배포는 항상 어렵게 느껴지는 것 같습니다. 이슈가 발생했던 3일 동안은 물론이고, 이후 며칠간도 초긴장 상태였어요. 혹시 또 예상치 못한 문제가 생기지는 않을까 걱정되기도 했지만, 그래도 조금이나마 재미를 줄 수 있는 서비스를 구현했다는 점에서 뿌듯함이 더 컸습니다.

특히 실제 운세가 잘 맞는다는 이야기를 해주신 분도 있었어요 😁

다음번에 비슷한 기능을 구현할 기회가 온다면, 로그를 기록하는 코드도 추가해야겠다고 느꼈습니다. 이번에는 console.log를 활용해 실시간으로 로그를 확인하는 방식으로 구현했지만, 많은 사람에게 메시지가 전송되는 만큼, 이슈 해결을 위해 로그를 남기는 시스템이 꼭 필요하다는 걸 깨달았어요. 이렇게 생각했던 것도, 결국 서버 운영이 처음이라 겪은 시행착오였던 것 같아요.

그래도 이번 미션도 무사히 끝-

에필로그

아무런 이슈없이 운세봇을 운영한지 3주가 넘었을 무렵.. 다른 스쿼드의 리더분이 Slack에 이런 글을 남겨주셨어요 🥺

이렇게 먼저 잘 쓰고 있다고 말씀해주시니 무한 감동이였다. 요새 업무로 많이 정신없고 바쁘던 때에 단비같아 기분 좋은 하루가 되었어요 ^_^

그렇게 또 한 달 뒤..

이제 더 이상의 문제는 없다고 안심할 때 즈음, 이런 메시지가 나오면서 나를 또 한번 놀랐어요... 전사에 배포된 서비스이기 때문.. 다른 분들도 영문도 모르고 이 메세지를 받았을 생각에 또 한번 아찔했는데요,

원인 파악을 위해 cat /var/log/nohup.log 명령어로, 내가 console.log로 남겨둔 메시지를 확인해 보았어요. 로그를 살펴보니 429번 에러가 발생했고, 이는 요청이 너무 많아 OpenAI 사용 쿼터를 초과했음을 의미하더라고요. 또한 요금제와 사용량을 확인하라는 안내와 함께, 관련 DOCS 링크 (공식문서) 까지 친절하게 알려주었어요.

API Key balance 충전 하니 바로 해결~~