코드스테이츠 플랫폼에서 코드스테이츠 색깔 빼기
부제 : 유어클래스 이벤트 훅 인터페이스
서론
19년 3분기 현재, 개발하고 있는 프로젝트는 유어클래스라는 LMS(Learning Management System)이다. 간단하게 소개하자면, 코드스테이츠에서 진행 중인 학습 컨텐츠 들을 관리하고, 수강생들 에게는 컨텐츠를 열람 하며 학습할 수 있는 플랫폼을, 코드스테이츠 크루들 에게는 그런 수강생과 교육 컨텐츠를 관리할 수 있는 대쉬보드를 제공한다. 부트캠프에서 이러한 서비스를 자체 개발 하고 있는 것만으로도 자랑스럽고 뿌듯한 일인가!
그런데,
코드스테이츠 플랫폼 에서 코드스테이츠 색깔 빼기라니 이는 도대체 무슨 아이러니한 말인가?
이유는 이렇다. 유어클래스라는 플랫폼은 코드스테이츠 수강생들을 위한 플랫폼이 맞다. 하지만 코드스테이츠 수강생 만을 위한 플랫폼은 아니다. 이것이 무슨말인고 하니, 코드스테이츠 크루 들을 위해 플랫폼을 개발 했지만, 코드스테이츠 뿐만 아니라, 세상에 다양한 교육 컨텐츠를 가지고 있는 사람과 기관을 위한 독자적인 SaaS로 발전하기 위한 목적을 가지고 있다.
그래서 그 목적이 색깔 빼는거랑 무슨 연관이 있는 건가?
요약 하자면, 유어클래스 개발코드에는 코드스테이츠를 위한 코드가 들어가서는 안된다! 라는말이다. 우리 개발팀은 이 원칙을 지키기 위해서 다음과 같은 갈등에 봉착했다.
- 취지는 알겠어. 그런데 당장 코스 운영을 효율화 해야 하잖아? 언제 까지 지지부진 할꺼야? 나중에 빼면되지!
- 유어클래스는 향후 SaaS로 성장 해야해! 프로덕션 코드에 기업 커스텀을 넣을꺼야? 처음부터 막아야돼!
사실 두 가지 주장 모두 합리적인 주장이다. 하지만 우리는 유어클래스의 개발자이기 이전에 코드스테이츠의 크루였고, 우리의 업무는 코드스테이츠의 방향성에 부합 해야만 했다. 그럼에도 불구, 유어클래스 코드에는 코드스테이츠를 위한 코드를 넣을 수는 없었다. 플랫폼 개발자의 자존심(?) 뭐 그런 것 이었다.
당장에 우리가 직면한 요청은 이러한 것 들이 있었다.
- 신규 수강생 들어올때마다 깃허브 초대 해야되는데요.. 너무 힘드네요 ㅠㅠ
- 수강생 들어오면 코스 정보에 맞게 팀 초대도 따로 해야되는데요. 100명 넘어가니까 힘들어요….
- 프리코스가 구독모델로 전환 했네요. 이제 코스 개강도 너무 수시로 해요. 2주마다 개강하는데 저 어쩌죠? ㅠㅠ.
사실 이전의 LMS(런코)에는 이런 코드들이 조금씩 녹아 들어가 있었다. 하지만 그런 실수를 다시 반복할 수는 없었다. 우리는 두 가지 주장을 모두 충족 시켜야 했다.
본론
불현듯 머릿속에 Github가 스쳐 지나갔다.
깃허브는 WebHook 이라는 시스템을 지원한다. 깃허브의 훅이 뭔고 하니, 깃허브에서 어떠한 액션이 실행 되었을 때, 그 액션에 따른 메타데이터를 사용자 지정 엔드포인트에 보내주는 그런 기능 이었다. 대략 이런 정보를 보내준다.
지난 몇 개월 동안, 깃허브 웹훅 혹은 슬랙 웹훅과 클라우드 펑션(람다 gcf 등)을 이용해서 이것 저것 MSA(Micro Service Architecture) 랍시고 만들어 본 것들이 몇개 있었기에 컨셉 증명을 위해서 간단한 스키마와 코드를 만들어 보았다.
각 column의 의도는 다음과 같다
- id : primary key
- type : 이벤트 종류(코스,오가니제이션, 컨텐츠 등등 일반적인 Entity)
- eventName : 어떤 이벤트(등록, 삭제, 생성, 만료 등 구체적 액션)
- endPoint : 이벤트 발생에 따른 메타데이터를 실어서 보내 줄 엔드포인트.
- pubEntityUuid : 아마도 type이 발생한 entity row의 Uuid
- isActive : 훅의 활성화 여부
스키마와 컨셉 코드를 간단히 요약 해보면 다음과 같다.
지정한 entity에서 어떠한 이벤트가 실행 되면, 코스에서, 특정 type과 eventName을 가진 특정 someEntityUuid 에 걸려있는 활성화된 훅이 있는지 파악해서, 해당 엔드포인트에 메타데이터를 발송한다.
이러한 인터페이스를 구현함 으로 인해서 우리는 다음과 같은 일을 할 수 있었다.
위 두가지 상황에 따른 function 구축으로 인해서, 우리는 다음과 같은 운영 효율화를 효과를 누릴 수 있었다.
- 유어클래스에 가입하면 자동으로 코드스테이츠 깃허브에 초대되어, 따로 초대장을 보낼 필요가 없다.
- 특정 코스에 등록 하기만 하면 자동으로 코드스테이츠 깃허브 특정 팀에 초대되어, 따로 초대장을 보낼 필요가 없다.
간단한 컨셉증명을 위한 스키마와 코드 만으로도 훅 인터페이스를 만들어서 우리는 이러한 운영 효율화를 하면서, 더 이상 우리 팀의중요한 리소스를 노가다(?) 하는데 사용하지 않도록 할 수 있었다.또한 유어클래스 코드는 훅만 전달 하기 때문에 코드스테이츠 커스텀 코드가 프로덕션에 녹아 있지 않았다. 더 중요 한것은! 이러한 훅은 유어클래스에서 발생 할 수 있는 모든 액션에 붙일 수 있기 때문에, ~하면, ~해주세요! 라는 비 개발자 크루의 간단한 요청만 있으면 운영을 효율적으로 만들 수 있는 수 많은 함수들을 만들어 낼 수 있다!
현재는 두개의 function을 만들어 봤지만, 얼마나 더 효율적으로 만들 수 있을까 기대가 된다.
마무리하며
훅 인터페이스를 만들어 내면서 과정을 돌이켜 보았을 때, 과연 이러한 인터페이스를 나 혼자 생각 해냈을까? 라고한다면. 대답은 No인것 같다. 이러한 아키텍쳐를 이끌어 낼 수 있었던 가장 중요한 배경은 팀원과 활발한 커뮤니케이션 그리고 제안에 대한 활발한 피드백 이 있었기에 가능했다. 이번 경우를 돌이켜 보면서 확실한 교훈을 얻은 것이 있다.
고인물은 썩기마련이다. 그리고 대화하지 않는 개발자는 도태 되기 마련이지.
그 동안 일이 바빠서 또는 체력이 부족해서(?) 라는 변명 아래에 참가 하지 않았던 여러 컨퍼런스와 세미나에 다시금 참가 해야겠다는 욕구과 솟아 오름과 동시에 이렇게 블로그를 계속 해서 작성 해야겠다는 다짐을 하게되는 일이었다.
개발자라면 이야기 많이 하세요.. 끝!
