이번 생에 PM은 처음이라: 수학 콘텐츠용 CMS 제작기
DDD(Developer Driven Development)를 통해 수학 콘텐츠용 CMS를 만들었던 경험에 대해 공유합니다.
안녕하세요. Turing 백엔드팀의 Aaron입니다.
이번에 사내에서 약 4개월간 기존의 CMS를 개편해, 수학 콘텐츠에 최적화된 CMS를 다시 만드는 프로젝트가 있었습니다.
교육 전문 스타트업 답게, 사내 내부 인력의 경험과 학습에는 아낌없는 지원이 뒤따른다는 철학을 바탕으로 PM으로 전격 승격
백엔드 개발과 동시에 PM을 맡게 된 뜻깊은 프로젝트였습니다.
이번 글에서는 해당 프로젝트를 회고해 보고, 배우고 느낀점에 대해 공유합니다.
어떻게 시작 되었나요?
프로젝트를 시작하기 전부터, 기존에 활용하던 CMS가 있었습니다.
수학 콘텐츠팀에서 기존 CMS를 활용해 수학문제를 만들고 계셨지만, 서비스를 운영/고도화 함에 따라 여러가지 문제들이 생기기 시작했습니다.
문제점 1) 장애 전파
CMS와 서비스가 같은 데이터베이스를 쓰고 있었기 때문에, 서비스와 CMS의 변경사항이 각각 서로에게 영향을 주고 있었습니다.
일주일에 3–4회 배포를 진행할 정도로 기능 개발이 자주 이루어지고, DB가 굉장히 빠르게 변하고 있는 상황에서 보통 아래 그림과 같이 하나의 DB 수정이 두 서비스 모두에 영향을 줬습니다.
가장 큰 문제는, 수학대왕 서비스를 위해 데이터베이스를 변경하게 되면, 해당 DB에 의존적인 CMS 서비스에서는 에러가 발생했고, 반대도 마찬가지였기에 콘텐츠팀에서 사용하다가 에러 제보를 해 주시는 일이 잦았습니다.
문제점 2) 데이터에 접근하는 방식이 다양해졌다.
튜링에서는 데이터가 필요한 사람들이 직접 쿼리를 날려 데이터를 조회하고,
상황에 따라 필요한 대시보드를 직접 만들수 있도록 도와주는 Retool이라는 SAAS를 적극 활용하고 있습니다.
이렇게 데이터베이스에 접근하는 경로가 다양해지다보니, 많은 사람이 데이터 구조를 쉽게 이해할 수 있도록 서비스용 데이터베이스를 깔끔하게 관리할 필요가 생겼고
서비스 측면에서 불필요한 데이터와 레거시들을 따로 분리해서 관리할 필요성을 느끼고 있었습니다.
문제점 3) 수명이 굉장히 긴 데이터를 관리하기에 부족한 기능
수학 교육용 데이터는 만들어내는 과정에서 다양한 창의력을 필요로 하고, 여러 사람의 의견을 모아 의논하기 때문에 데이터를 생산하는 주기가 긴 편입니다.
최종적으로 만들어진 문제도 여러 유저에게 반복되어 노출되고, 교육과정이 변경되지 않는 한 문제의 수명이 굉장히 길기 때문에, 기존에 만들어진 문제를 지속적으로 관리하기 위해 오래된 데이터를 필요한 사람이 잘 찾을 수 있도록 제공하는 것이 중요합니다.
시간이 지날수록 기존에 만들어둔 문제에 대한 접근성이 떨어져 지속적인 개선 요청을 받아왔고, 새로운 기능에 대한 요청사항과 함께 대대적인 개편을 준비하고 있던 상황이었습니다.
어떻게 만들었나요?
기술적으로 기존에 있었던 문제를 해결하고, 서비스와 CMS의 결합도를 낮추면서, 추후에 준비될 다양한 다른 서비스와의 호환성을 고려해 데이터베이스를 분리하기로 결정했습니다.
그리고 데이터베이스를 분리하게 되면서, 프로젝트를 새롭게 만들기로 결정합니다.
새로운 프로젝트에 시작하기 앞서 프로젝트의 특성에 따라 참여하는 모두가 아래와 같은 생각으로 개발할 수 있도록 이야기를 많이 나눴습니다.
- 완성도 < 속도
- 이해하기 쉽고 일관된 UX
- 가능한 많은 데이터를 노출해 수요자가 직접 결정할수 있게 하자.
- 행위의 단축 보다는 기능의 다양성에 초점을 맞추자.
결국 필요할때, 빠르게 개발해 쓰는게 가장 중요하다고 생각했습니다. 스타트업은 굉장히 빠르게 변하고, 버스는 금방 떠나 버리니까요.
프로젝트를 시작하려면 아무래도, 디자인이 있어야합니다.
하마터면 제가 디자인한 해당 시안으로 진행되는 불상사가 일어날 뻔 했지만, 다행히 저와 함께 프로젝트를 진행하기로 하신 FE개발자님의 추천으로 기존에 만들어진 Primer 디자인 시스템을 활용하기로 결정 했고, 해당 디자인 시스템을 잘 활용해 안정적이고 빠르게 개발을 진행하기 시작합니다.
기존에는 RestAPI를 통해 서비스용 API를 구현하고 있었는데요, 본격적으로 개발을 시작하면서 이번에는 BFF(Backend For Frontend)와 클라이언트의 통신을 Graphql을 이용 하기로 했습니다.
기존의 방식과는 다른 통신 방식을 택하게 된 이유는 Graphql의 철학에 근거
“Client에서 원하는 데이터를 Client 가 직접 선택해서 가져올 수 있도록 하자”
수명 주기가 긴 데이터를 사용자의 필요에 따라 다양한 방식(UX)으로 빠르게 제공해 줄 수 있겠다는 생각이 들었기 때문입니다.
또한 이전에 Graphql을 이용해 서버를 만들어본 경험이 있기 때문에 Graphql Client로 React Relay를 활용해 개발을 진행했습니다.
어떤 점들이 개선 되었나요?
디자이너분들도 본격 합류 하시게 되면서 개발자의 머릿속을 그대로 옮겨둔것같았던 프로젝트가 많은 부분 개선되어 출시될 수 있었습니다.
그리고 현재는 수학콘텐츠팀뿐만 아니라 모든 팀에서 전사적으로 새로운 CMS를 활용해 효율적으로 일하고 있습니다.
개발자들은 서비스와 CMS의 결합도가 떨어지면서 필요한 비즈니스 로직에만 집중, 장애가 격리 되었기 때문에 안정적으로 서비스를 운영할 수 있게 되었고
서비스에 필요한 데이터는 서비스 DB에서만 관리할 수 있게 되면서 데이터베이스 접근시 커뮤니케이션 비용이 많이 절감되었습니다.
또한 배송, 재고 등 수학대왕 서비스와는 무관하지만, 사내에서 일어나는 다양한 일을 확장성 있게 자동화할수 있게 되었습니다.
무엇을 느끼고 배웠나요?
개발만 할 때는 몰랐지만, 막상 프로젝트 기획을 해 보고, 프로젝트 관리, 매니징을 해 보니 PM의 입장을 조금 더 깊게 이해할 수 있었습니다.
설득과 동기부여
우아한 PM의 밤 - 영한님의 강연을 보고 난 뒤, 단순히 기획안에 따른 개발 요청만 할 것이 아니라 프로젝트에 참여하는 구성원들에게 우리는 왜 이 프로젝트를 해야하고, 어떤 부분을 중점적으로 생각해야하는지 설득하는 과정이 꼭 필요하다고 생각했습니다.
물론 그 과정이 참 어려운 일이고 제가 그 과정을 완벽하게 해내지는 못했겠지만, 직접 해 보니 제가 혼자 머릿속으로 생각한 내용보다 훨씬 다채롭고 좋은 방향의 아이디어들이 많이 나왔고 성공적으로 프로젝트를 마무리하는데 도움이 많이 되었다고 느꼈습니다.
먼저 공유하고, 정리하면 아낄수 있는 시간이 더 크다.
구현 내용과 기획에 대해 상세히 기술한 문서와 피그마 화면은 백번의 회의보다 더 강력하다고 느꼈고,
그 과정에서 예상되는 병목 지점이 어디인지, 예상되는 병목지점을 피할수 없다면 각자가 생각하는 해결방안이 무엇인지를 먼저 공유하고 의논하면 소요되는 시간 대비, 모두의 시간을 크게 아껴줄 수 있다고 느꼈습니다.
프로젝트에 참여하는 모두가 같은 방향성을 가지고 달릴수 있도록 하기
기획을 진행하면서 여러가지 피드백을 듣다보면 지금 당장 개선해야 하는 기능과, 당장 개선하지 않아도 사용할수는 있지만, 만드는 사람이 조금만 더 수고로우면 쓰는사람이 굉장히 편해지는 기능이 있습니다.
개발에 참여하는 각자가 생각하는 기능의 중요도가 조금씩 다르기에, 가끔 기획에 대한 개발을 진행할 때 예상치 못한 부분에서 병목이 생긴 적이 있었습니다.
만드는 사람이 수고로운 방식이 사용성 측면에서는 가장 좋겠지만, 모든 프로젝트의 특성과 시기에 맞추어 적용될 수는 없다고 생각하기에 모두가 비슷한 생각을 가지고 프로젝트에 참여할 수 있도록 방향성에 대한 동기화가 자주 필요하다는 생각을 했습니다.
묻지 않아도 먼저 이야기 해 줬으면 하는 것들
매니저 입장에서는 새로운 기획과 동시에 기존 기획에 대한 기한과 진행도를 상시 파악하고 병목이 생기는 부분을 해결해야 하기 때문에
- 어디까지 진행중인지
- 예상 기한은 언제까지 인지
- 어떤 방식으로 구현할 것인지
- 생각하는 예상 병목 지점은 어디인지
정도의 정보를 항상 알고싶다는 생각이 들었습니다. 그래서 앞으로는 PM이랑 일을 하게 되면 해당 부분은 따로 여쭤보시지 않아도 먼저 말씀드려야겠다는 생각을 했습니다.
이상으로 글을 마칩니다.
긴 글 읽어주셔서 감사합니다.
