[프로젝트] Slack-attendance-bot

계기

오픈 채팅방에서 자율적으로 공부하고 매일 인증하는 자율 스터디 목적으로 Slack 워크스페이스가 개설되었습니다.

처음엔 리딩하는 사람이 수기로 확인하고 멘션을 해줬었는데, 개인 일정으로 빠지거나 채널이 여러개로 늘어날 경우 여러 어려움이 따를 것 같았습니다.

지인이 서버 헬스체크 알림을 슬랙을 이용해 받는다며 문서도 잘되어있고 구축도 금방 했다고 해서, 한번 시도해보기로 했습니다.

---

 

전체적인 기술스택과 흐름도

 

흐름

봇을 맨션(@TIL)하면 걸어놓은 봇 이벤트 콜백 주소로 요청이 가고,

서버에서 그 요청을 받아 관련 정보를 수집해 데이터베이스에 저장 후 완료됐다는 의미로 이모지로 체크표시!

이후에, DM으로 걸어놓은 웹 훅 요청을 통해 데이터베이스에서 관련 정보를 수집 및 정리 후 발신자에게 정보를 전달해줍니다.

 

기술 선택

사실 이전까진 노드를 http 요청 응답하는 서버로 후다닥 만들기위해서만(http.createServer) 사용했었지 실질적인 요청을 주고받는 용도로는 이번에 처음 도입해보았습니다. 사용해본 적 있는 백엔드 프레임워크가 스프링 레거시 뿐이었지만 지금과 같은 목적으로 빠르게 프로토타이핑 하기엔 환경구성부터 쉽지않을 것 같다는게 이유였습니다(부트를 배웠더라면..?!).

 

데이터베이스는 이전에 사용경험이 있는 MySQL을 사용하려 했는데, 라즈베리파이를 지원하는 이미지가 없었습니다. 당시 오라클에 인수된 후 유료로 전환된다는 이야기도 간간히 들려와서, 파이도 지원하고 MySQL과 높은 호환성을 가진 오픈소스 소프트웨어인 마리아디비를 사용하기로 했습니다.

 

환경구축 및 배포 관련해서는 도커와 도커 컴포즈를 이용하기로 했습니다. 배포 테스트를 할때마다 쌓여가는 캐시, 의존파일 등을 관리할 필요 없이 컨테이너 채로 날리고 다시 돌리기만 하면 된다는 점이 매력적이었습니다.

서버와 디비를 각각 돌릴 필요없이 한 번에 묶어서, 같은 네트워크상에 있게끔, 죽어도 다시 실행될 수 있게끔 오케스트레이션 툴로 도커 컴포즈를 사용했습니다.

 

구현

예상되는 요청들과 그에따른 응답이 그리 복잡하지 않았기에, 테이블 하나로 묶어 데이터를 관리하기로 하고 빠르게 프로토타이핑을 시작했습니다. 

최상위 스크립트에서 요청을 받으면, 슬랙 이벤트 콜백인지 토큰을 검증하고(바디와 헤더를 이용해 암호화된 토큰으로 검증한다는게 신기했습니다. 마치 JWT같은..?) 올바르다면 라우터로 바디를 넘겨 처리를 위임합니다.

라우터에서 DM, IM인지에 따라 구별하여 각 핸들러를 호출하여 관련 로직을 처리합니다.

이렇게 서버쪽 로직을 구성한 다음, 도커파일로 컨테이너 이미지를 구성하고 도커 컴포즈로 오케스트레이션 해줬습니다.

생각보다 이러한 구성이 빠르게 만들어져서 금방 도입할 수 있었습니다.

 

회고

해당 프로젝트를 진행하고 나서 돌아본 점이 여럿 있었습니다.

그중 하나는 구상 및 설계를 진행하지 못 한 것이었습니다.

배포 후 몇몇 기능을 추가하며, 버그를 고치며 프로그램의 전체적인 구성 설계와 테이블 정규화를 조금이라도 진행했더라면 하는 아쉬움이 있습니다. 추상적인 계획이 없다 보니 코드를 추가하면서 구조가 바뀌는 일도 여럿 있었습니다.

다음 프로젝트에선 대략적인 기능들, 기한(중요!!), 디자인을 프로토타입 레벨으로라도 구상하고 진행해봐야 할 것 같습니다.

 

그리고 이따금 예상치못한 버그에 서버가 통째로 죽으며 이벤트를 놓치는 경우가 있었는데, 이때마다 직접 디비에 데이터를 넣어줬었습니다. ssh로 접속하고.. 컨테이너에 연결하고.. 마리아디비에 접속해서 INSERT 문을 직접 넣어야 했습니다.

관리자 페이지(또는 명령어)의 필요성을 상당히 강하게 느꼈습니다. 설계를 진행했다면 이런 부분도 처리하지 않았을까 하는 생각도 듭니다. 

 

또 다른 하나는 다른 프로젝트를 진행하고 느낀 점인데, 빠르게 프로토타이핑 한걸 테스트 없이 배포했기에 수정할 일이 잦고(특히 버그픽스), 일일이 손으로 테스트해봐야 했습니다.

멘션 및 조회 기능이 전부였기 때문에 당시엔 필요성을 많이 느끼지 못한 것 같습니다. 덕분에 잘 동작하던 기능이 안되는걸 뒤늦게 알고 부랴부랴 다시 수정 후 배포를 진행한다거나 하는 상황이 몇 있었습니다.

테스트 코드를 작성했다면 자연스레 귀찮아할 테니 CI/CD 도구도 알아보고 적용도 하지 않았을까 하는 아쉬움이 있습니다.

다음에 진행할 땐 테스트코드도 작성하고 싶은데, 얼마나 세세하게 나눠서 테스트해봐야 할지 고민 중입니다.

 

그리고 환경에 따른 아쉬운 점 중 하나인, '헬스체크를 못하는 환경' 도 있었습니다. 

'프로메테우스'라는 모니터링 도구였는데, 도커에 붙여 사용하기 좋아보였습니다. 하지만 구동 환경이 '라즈베리 파이 3 B+' 였던게 문제였는지, 이따금씩 보드 자체가 뻑나곤 했는데 해당 경우엔 ssh 접속도 불가능해 모니터링 정보를 얻을 수 없었습니다.

알아보던 도중 모든 로그를 메모리에 남겨 메모리부족으로 이어지는 것 같아 메모리에 남기는 로그의 크기를 제한하고, 컨테이너가 사용하는 메모리 양을 제한하려 했는데 OS 이미지 문제인지 도커에서 메모리 사용량을 가져오지 못했습니다. 때문에 삽질 구덩이만 덩그러니..

하지만 실 사용엔 그리 큰 문제가 되지않았고(죽더라도 도커-컴포즈가 다시 실행시켜줬습니다), 사용자 풀이 크지않아 죽는일이 정말 이따금 있었기에.. 큰 후회는 없습니다.

 

 

구현된 API를 이용해 실제 운영되는 서비스를 구축한 경험은 이번이 처음이었습니다.

..덕분에 잘 만들어진 문서와 정형화된 요청들이 얼마나 편리한지 알 수 있었습니다.

전에 스프링을 이용해 만들땐 일관성 있는 구조(DAO - Controller(+service) - View)로만 만들어서 느끼지 못했는데 자유로운 만큼 코드도 자유롭게 뛰어논다는 것을 느꼈습니다.

이것과 관련해서는 디자인 패턴 및 클린코드 관련 정보를 찾아봐 보완할 예정입니다.

 

그리고 완벽하게 만들어지지 않은 봇을 바로 투입해 사용하다보니, 빠르게 개발하게 된 원동력이 됐습니다.

일단 죽으면 다른분들이 연락을 주셔서...😅
덕분에 설계단계 없이도 여기까지 올 수 있지 않았나 싶습니다. 후에 다른 프로젝트를 진행할때 어느정도 모양이 잡히면 바로 배포해 스스로 압박감을 주는것도 괜찮을 것 같다는 생각이 드네요.

 

후에 시간이 난다면 리액트를 이용해 인증 현황을 보여주는 페이지도 한번 만들어보고 싶네요. 관리자 페이지도 같이!

 

 

깃헙 slack-attendance-bot 레포지토리