넥스트유니콘 Slack봇 개발기
안녕하세요! 넥스트유니콘 개발팀 인턴 Ain입니다.
지난 9월에 팀에 합류해 벌써 4개월이나 지났습니다.
그동안 개발한 프로젝트와 넥스트유니콘에서 일하는 방식을 소개합니다.
“Bitbucket, Jira, Confluence, Figma with Slack App”
프로젝트 이름만 봐도 할 게 많아보이죠…? 현업에서 일하시는 분들이라면 다들 익숙한 도구들이지만, 실무 경험이 없던 저에게는 전부 신기해보였습니다. 그래서 실무에 들어가기 전에 이런 툴들을 단순히 사용하는 걸 넘어서, 응용해서 개발할 줄 안다면 도움이 될 것 같아서 프로젝트를 시작하게 됐습니다.
이미 다 잘되는데요?
회사에 들어오기 전, 프로젝트 계획서를 보며 제가 프로젝트를 완성할 수 있을까 걱정하며 들어왔습니다. 그런데 막상 제가 맡은 프로젝트는 이미 만들어져 있었고 기능도 정상적으로 동작했습니다. 하지만 팀원들의 편의성을 도와주는 앱이라 중요도가 낮았고, 빠르게 만든 탓에 유지보수는 크게 신경쓰지 못한 구조였습니다. 사용한 기술 스택들도 커스텀하기 쉽고 자유도가 높지만 다른 사람이 손 대면 금방 무너질 것 같아 조심조심 다뤄야했습니다. 마치 모래성처럼요. 그런 문제점을 파악하고 기존의 슬랙 앱을 사용하기 쉽게 수정하는 것이 제가 맡은 프로젝트였습니다. 미완성으로 끝나더라도 작업한 부분은 블록처럼 튼튼하게 만들어야지라고 생각했지만, 완성이 목표가 아닌 개선이 목표가 되었습니다.
팀원들을 위해서 이렇게까지 한다고요?
넥스트유니콘에서는 git 저장소로 Bitbucket을 사용하고 있습니다. 변경사항이 있는 경우 알려주는 Bitbucket 공식 슬랙앱이 있지만 문제점이 있습니다. 바로 repository 단위로 알림이 채널에 오기 때문에 본인에게 중요한 알림만 확인할 수 없습니다. 팀에서는 이 문제를 해결하기 위해 들어온 메시지들을 구분해서 연관된 개인들에게 DM으로 전송하고 있었습니다. 꼭 확인해야하는 메시지들을 개인적으로 받는 건 좋지만, 긴 과정을 거쳐야만 했습니다.
제가 맡은 부분은 위의 긴 과정을 webhook을 이용해서 간략하게 만드는 것이었습니다. 기존 Bitbucket 앱은 개인별로 슬랙과 계정을 연동해야 합니다. 새로운 방법은 과정 중에 Bitbucket 앱이 빠지다 보니 슬랙과 연동을 대신하는 기능을 만들었습니다. 하지만 실제로 사용하다 보니 연동하는 과정이 번거롭다는 의견이 있었습니다. 그래서 개개인별로 관리하는 대신 Bitbucket과 Slack admin 권한을 이용해 모든 유저들의 연동을 자동으로 관리해주는 방식으로 수정했습니다.
Bitbucket 기능을 마치고 다음으로 Confluence에 필요한 기능을 확인하는데 처음에는 요구 사항이 이해가 되지 않았습니다. 그러다가 개발된 기능에 대한 히스토리를 듣고서야 필요성을 깨달았습니다. Confluence는 부족한 기능들을 개발자들이 제작한 플러그인으로 채우고 있습니다. 그리고 보통 이런 플러그인들은 유료로 달마다 요금이 청구됩니다. 심지어 팀 인원 수에 비례해서 금액이 올라가는데 필요한 플러그인이 늘어나면 매달 고정으로 지출되는 비용이 부담될 수 밖에 없습니다.
넥스트유니콘 팀에서는 이런 비용을 줄이기 위해 공개된 API를 이용해 플러그인을 대신해주는 기능이 있었습니다. 기존 Bitbucket과 마찬가지로 공식 Confluence 앱에 들어온 메시지를 읽어서 처리했습니다. 이것 역시 Bitbucket처럼 간단하게 바꾸고 싶었지만 문제는 Confluence는 공식적으로 webhook을 지원하지 않습니다. 그렇다면 이벤트를 어떻게 받을까요?
다른 방법은 없을까요?
이 문제를 Slack 앱으로 어떻게 해결할까 고민하다가 근본적인 문제점을 찾았습니다. 플러그인 기능을 Slack 앱으로 대체하려는 점이었습니다. 플러그인들은 이벤트를 Confluence 측에서 제공받을 수 있는데 Slack 앱은 그렇지 못했습니다. 그래서 다다른 해결책입니다.
“슬랙앱을 거치지 말고 플러그인을 직접 만들면 어떨까?”
Atlassian에서는 여러 API를 비롯해 제품에 사용할 수 있는 앱을 만들 수 있는 SDK를 제공하고 있는데 그 중에 Forge를 찾았습니다. 팀원들이 쓸 수 있는 Javascript 기반이었고, 서버를 따로 관리할 필요없이 배포와 업데이트가 간단했습니다. 선택 조건들은 적합했지만 직접 만드는 경우가 별로 없는지 다른 개발자들이 기존에 개발했다는 경험을 공유한 글을 찾기가 힘들었습니다. 따라서 공식 문서만 열심히 참조해가며 여러 트러블 슈팅을 거치며 만들었습니다. 결과적으로 플러그인을 만들어 배포에 성공했고 이 기능을 Slack 앱에서 분리할 수 있었습니다.
만든 소스코드는 Github에서 보실 수 있습니다.
( Confluence를 쓰신다면 간단한 기능은 만드는 것도 추천드려요…! )
반복 또 반복
넥스트유니콘 팀에서는 이슈관리를 Jira로, 디자인 툴로는 Figma를 사용하고 있습니다. Jira도 마찬가지로 공식 슬랙앱에서 지원하는 기능들은 부족한 부분들이 있었습니다. 우선순위가 높은 이슈 티켓이나 마감기한 기준으로 이슈를 확인하는 것처럼 특정 조건들을 사용하려면 따로 만들어야 했습니다. Figma도 이벤트에 대해 개인 DM으로 받을 수는 있지만 특정 채널에 모든 메시지들을 받을 수 있는 기능은 제공되지 않습니다.
그래서 필요한 기능들을 팀원들의 의견을 받아 채널이나 DM으로 메시지를 보내는 기능을 개발했습니다. 구현 방식은 Bitbucket과 마찬가지로 필요한 경우 각 서비스들과 Slack을 연동하고 API를 호출하는 방식을 채택했습니다. 그러다 보니까 찾을 수 있는 패턴이 있었습니다.
이벤트를 받아서 중요한 정보들을 Block으로 만들고, 메시지로 보내지 않는 부가적인 정보들을 담아 만드는 과정을 반복했습니다. 이런 패턴이 이벤트 타입만 다를 뿐 같은 과정을 반복하는 팩토리 패턴과 비슷하다고 생각해서 이 방식으로 구현했습니다. 디자인 패턴을 도입할 때 개념적으로 부족한 부분들이 있었는데 팀원들의 코드 리뷰를 통해 해결할 수 있었습니다. 정리해보면 프로젝트 기간동안 만든 기능들은 다음과 같습니다.
자동화를 어디까지?
기능적인 부분은 완성됐지만 아직 프로젝트는 끝나지 않았습니다. 사용중인 Slack 앱은 CI/CD로 Bitbucket Pipeline을 이용하고 있었기 때문에 작업들을 코드만 수정하고 저장소에 올리면 변경사항이 적용됩니다. 하지만 아직도 변경사항이 생겼을 때, 코드 외에 바꿔줘야 하는 부분이 남았습니다. 바로 Slack 앱의 설정입니다. Slack 앱에 필요한 권한이 늘어나거나, 슬래시 명령어를 추가하고 싶은 경우 Slack 앱 관리 사이트에 들어가 설정을 변경해줘야 했습니다. 다른 부분들은 모두 자동으로 되기 때문에 이 과정도 자동으로 바꾸고 싶었습니다. 그래서 슬랙 앱 구성 토큰을 발급 받아 Slack앱이 켜질 때마다 변동 사항이 있으면 자동으로 앱 구성을 변경하게 만들었습니다.
이제 실제로 배포되는 앱은 모든 걸 소스 코드 안에서 관리할 수 있었습니다. 그런데 Slack 앱은 이벤트를 받기 위해 고정된 IP가 필요해서 로컬에서 테스트를 하는 경우 ngrok 같은 터널링 프로그램을 주로 이용합니다. 이런 주소가 바뀔때마다 적용되는 부분들을 다 바꿔주는 건 번거로웠습니다. 그래서 이런 부분을 IP 주소를 입력해 해당되는 부분을 전부 바꿔줄 수 있도록 수정했습니다. 이제 테스트 앱도 코드로만 관리할 수 있게 되었습니다.
적극적이고 빠른 피드백
저는 그동안 프로젝트를 완성했지만 사용하는 유저가 없어 피드백을 못 받고 그대로 끝나는 경우가 많았습니다. 하지만 넥스트유니콘 팀에서는 이런 작은 프로젝트도 많은 분들이 써주시면서 다양한 피드백을 받을 수 있었습니다. 그러면서 사용자들의 불편한 점을 직접 전달받고, 기능을 추가하고 개선할 수 있었습니다. 그 중 하나는 Slack 앱의 홈 화면입니다. 이전에 Slack을 자주 사용해도 메시지를 주고 받는데만 사용해서 메시지가 잘 전송되는지만 확인했습니다. 하지만 팀원 분이 홈 화면을 활용에 대한 피드백을 주셨습니다. 그래서 Slack앱이 하는 기능들을 개인마다 한 눈에 확인할 수 있는 홈화면을 만들 수 있었습니다.
얼마나 성장했나요?
인턴 프로젝트 특성상 어떤 성과를 보여주긴 어려웠습니다. 서비스에 들어가는 기능도 아니었고, 내부적으로는 많이 바뀌었지만 팀원들이 사용할 때는 크게 달라진 점이 없다고 느꼈을 수 있습니다. 그래서 외부에서 찾지 말고 스스로 비교해보기로 했습니다.
제가 보여줄 수 있는 건 인턴을 진행하면서 과거의 제 자신과 비교해보는 것이었습니다. 중간중간 정말 여러가지를 배웠지만 얼마나 성장했는지 지식을 보여주는 건 어려운 일이라고 생각합니다. 하지만 제가 성장의 척도 중 하나로 삼는 게 있는데, 같은 걸 다시 했을 때 얼마나 잘하느냐였습니다. 여러가지 기능을 추가했지만 실제로 주된 핵심 내용은 같았습니다.
- 팀원들의 Slack 계정과 다른 서비스 계정을 연동하고,
- 서비스에서 필요한 기능들에 대한 정보를 얻고,
- 중요한 정보를 Slack 으로 알림을 보내주는 일이었습니다.
이런 반복된 일을 한다고 했을 때 같은 실수를 반복하지 않고, 똑같은걸 얼마나 더 빨리 했는지 기준으로 얼마나 늘었는지 비교해봤습니다. 걸린 시간은 추가 기능을 제외한 기본 기능을 완성했을 때까지 걸린 시간이고, 버그는 에러 모니터링 도구로 사용한 sentry.io에 해당 기능 배포 이후 일주일동안 기록된 에러 수입니다.
오른쪽으로 갈수록 기존에 있던 기능에서 새로운 기능을 추가하고 피드백 받은 내용들을 리팩토링을 진행하면서 했음에도 점점 걸린 시간은 짧아지고 버그 수가 적어졌습니다. 이렇게 빠르게 달라질 수 있었던 건 주변에서 적극적으로 도와주시는 팀원분들의 도움과 피드백 없이는 불가능했습니다.
넥스트유니콘 팀에서 일하면서 가지고 있던 사고방식도 달라졌습니다. 제가 만든 코드나 결과물을 보여주는건 매번 부끄러운 일이었습니다. 그래서 깔끔한 코드에 관심이 많았고 간단한 기능도 더 좋은 방법은 없을까 고민하는 기간이 길었습니다. 그래서 주어진 기간이 일주일이라면, 그 시간을 꽉 채워서 혼자 계속 검토하는 시간을 가졌습니다. 그만큼 한 번에 꼼꼼하게 처리하는 것을 중요하게 생각했습니다. 지금 달라진 생각은 혼자 고민하는 시간이 긴 것보다 팀원과 빠르게 공유하는 게 좋고, 그것보다도 더 좋은 건 사용자들의 빠른 피드백이라는 점입니다. 최소한의 기능을 빨리 만들어서 사용자들이 빨리 접하고 부족한 점을 찾는게 성장에 더 도움이 됐습니다. 즉 논리적으로 문제가 없고, 사용하는데 문제가 없다면, 완벽함을 추구하기보다 빠르게 타협점을 찾았습니다. 인턴 과정이 없었다면 아직도 정답이 없는 고민을 하는데 시간을 더 쏟았을 겁니다.
마무리
인턴 기간 중 가장 기억에 남는 순간을 떠올리면, 처음으로 실수를 했을 때입니다. 처음 배포를 하면서 Slack 메시지가 잘못 전송되었고 그날 하루종일 안절부절 못했습니다. 서둘러 문제를 고쳤지만 한동안 겁이 났습니다. 업데이트할 때 다시 에러가 생기면 어쩌나 하는 걱정도 들고, 프로젝트의 모든 책임이 저한테 있다는 것이 부담이 됐습니다. 하지만 팀원들은 그런 실수를 해도 나무라는 사람이 단 한 명도 없었습니다. 오히려 더 격려해주고 해결할 수 있는 방법을 같이 고민해주셨습니다. 그래서 제가 맡은 일에 대해 더 책임감을 갖게 되고, 제가 하는 프로젝트에 애정을 갖게 됐습니다.
처음으로 사회에 나오는 분들이라면 저처럼 많은 것들이 걱정되실 거에요. 그런 점에서 인턴이라서 더 도전해볼 수 있고, 실수를 해도 팀원들이 부족한 점을 이해해줄 수 있다고 생각합니다. 저는 개발자로 서비스를 운영하는 것이 여행이랑 비슷하다고 생각합니다. 집처럼 아늑한 공간인 로컬 환경을 벗어나서, 실제 배포 환경은 외국에 온 것처럼 낯설기만 할 겁니다. 그런 불편함을 감수하더라도 여행처럼 실제 서비스를 운영하는 건 배울 점이 많고, 다양한 사용자들을 만나면서 성장할 수 있다고 생각합니다. 그 길을 혼자 가보는 것도 좋은 경험이지만, 짐을 나눌수 있는 팀원들과 먼저 가본 선배 개발자들의 가이드가 있다면 여행이 더 즐거워질 거에요.
아직 팀에서 만든 슬랙앱이 없다면 팀원과 함께 성장해가는 슬랙앱을 직접 만들어보는 건 어떨까요?
긴 글 읽어주셔서 감사합니다!
