※ 부제 : 실전 프로젝트와 42학습의 갭을 극복하기 위한 연구

안녕하세요. 이번 프로젝트에 참여한 juchoi, kmin, sanam입니다. 부족한 실력이지만, 프로젝트 목표를 이루기 위해 열심히 참여하였습니다. 감사합니다.

웹 개발에 대한 갈망

저희는 웹 프로젝트를 진행해 보고 싶다는 생각을 하고 있었고 때마침 멘토님이 팀원을 모집한다는 이야기를 듣고 지원하게 되었습니다.

프로젝트의 시작

OpenCMS 프로젝트는 외부 기업인 씨네룩스와 협업으로 진행되었습니다. 씨네룩스는 뉴스 컨텐츠를 관리하고 axios.com 와 같은 형태로 일반 유저한테 보여줄 수 있는 시스템을 원했습니다. 그리고 저희는 5월 한달간 진행하는 관계로 모든 기능 보다는 최소한의 기능을 구현하는 MVP의 형태로 프로젝트에 대한 설계를 시작했습니다.

프로젝트를 통해서 얻고 싶었던 것

  • kmin: 오픈소스로 기획된 프로젝트에 대한 경험을 얻고 싶었고, 멘토님의 조언을 통해 협업을 더 잘 하는 방법을 느껴보고 싶었습니다.
  • juchoi: 주어진 과제를 해결하는 것이 아닌 팀원들과 함께 서비스를 만드는 과정에서 생기는 문제를 해결해 보고 싶었습니다.
  • sanam: node.js로 백엔드를 구성해보고 싶었습니다. 그리고 가장 크게 얻고 싶었던 것은 실제 운용되는 서비스를 만들어본다는 경험이었습니다.

짤막 정보!

CMS란

CMS란 Contents Management System 의 약자입니다. 42사람들에게 익숙한 워드프레스가 가장 성공한 CMS 의 예시 입니다.

MVP란

MVP란 Minimun Viable Product 의 약자입니다. 가장 기본적으로 있어야 하는 산출물이라고 할 수 있습니다.

Axios.com을 분석하자

씨네룩스가 원하는 바가 무엇인지 알기 어려웠습니다. 멘토님과 회의 후 axios.com 사이트를 참고하여 뉴스 사이트에서 필요한 MVP에 대해 분석했습니다. 그리고 기자, 유저의 관점에서 시나리오를 작성했습니다. MVP에 대한 시나리오를 작성한 이후에는 시나리오에 따라 사용자에게 보여져야하는 화면단을 figma 를 이용해서 그렸습니다. 아래의 사진이 미팅 전의 결과입니다.

씨네룩스와 미팅

화상회의를 통해 멘토님, 씨네룩스 팀장님과 함께 프로젝트의 진행 방향에 대해 논의를 나누었습니다. 이전에 구성한 시나리오는 실제 언론사의 작업 방식과는 거리가 있었다는 것을 알게 되었고, 프로젝트를 진행하기 위해서는 기자와 뉴스사이트에 대한 이해가 먼저 필요하다는 것을 알게 되었습니다.

씨네룩스 팀장님과 회의를 통해 기사가 작성되기 위해선 아래의 과정을 거쳐야함을 알 수 있었습니다.

  1. 기자의 기사 작성
  2. 해당 기자가 속한 부서의 데스크가 기사를 승인
  3. 편집장이 데스크에서 승인된 기사를 게재

저희는 MVP 라는 의미로 단순히 기자가 기사를 쓰고 유저가 기사를 보는 것만 생각하고 작업을 진행했었는데, 팀장님은 좀 더 구체적인 내용을 제시했습니다.

  1. 기자의 세분화. 기자 – 데스크 – 편집장에 이르는 3단계의 구성을 원했습니다.
  2. 회원가입 시 이메일을 통한 인증

역할에 따라 기능을 세분화해야 했고, 이에 따른 추가적인 기능이 더 필요했기 때문에 저희는 처음 생각과 달리 쉽지 않겠다는 생각을 하게 되었습니다.

천리길도 한걸음부터

처음 계획보다 더 복잡해진 이유로 처음엔 좀 막막했습니다.

그러던 중 멘토님과의 점심 식사에서 조언해주시길 프로젝트의 진행을 가장 기본적인 것부터 구현하고 좀 더 구체적인 사안들은 다음 사이클을 돌려가며 진행하라는 말씀을 해주셨습니다.

다시 말해서 첫 단계에서는 가장 기본적인 최소 단위를 구현한 후 단계를 이어나가면서 기능에 살을 붙이고, 에러 처리등을 하라는 말씀이셨습니다.

멘토님의 조언을 참고하여 저희는 아래와 같은 방식으로 점점 프로젝트에 살을 붙여나갔습니다.

  1. 라우트와 페이지 구성하기
  2. DB 환경 구축
  3. 각 페이지 마다 가장 기본적인 기능 구현
  4. 각 페이지에 필요한 추가 기능 구현
  5. 페이지마다 에러 처리하기
  6. 각 페이지에 UI적용하기

필요한 기능들을 가장 먼저 구현해보고 그 다음 UI를 구현해보았습니다.

협업 방법

위의 방식으로 프로젝트를 진행하며 협업은 아래와 같은 방식으로 진행하였습니다.

매주 월, 목요일에 멘토님과의 회의를 통해 프로젝트의 진행상황을 공유하고 앞으로 어떤 일을 진행할지에 대해 방향을 잡았습니다.

멘토님과의 회의 후 바로 논의한 진행 방향을 좀 더 세분화하여 Github issue로 등록하여 차근차근 해결할 수 있도록 노력하였습니다.

매일 아침 11시에 10분 정도의 짧은 스탠딩 미팅을 하였습니다. 작업이 완료된 issue를 정리하고 해결할 issue를 누가 어떤 작업을 진행할지 서로가 알 수 있도록 확인하였습니다. 맡은 작업에 따라 Github branch를 만들어 작업하고 pull request를 통해 이를 확인하며 develop branch에 merge하는 방식으로 코드를 관리하였습니다.

소통, 소통, 소통

프로젝트를 진행하면서 가장 중요했던 부분은 소통이었습니다.

시작을 화상회의로 진행하면서 의사소통의 어려움을 느꼈고 제약사항이 많았습니다.

이후 클러스터에서 만남을 통해 소통이 원활해졌고 작업 효율이 증가함을 느낄 수 있었습니다. 그리고 팀에서의 소통 뿐 만 아니라 클라이언트와의 소통 역시 중요했습니다.

클라이언트의 요구 사항을 잘 이해하지 못했기 때문에 좀 더 적극적으로 작업을 하지 못했고, 이문제를 클라이언트와 소통을 통해 보완하였습니다.

그리고 한 가지 문제를 30분 이상 고민하지 않고, 답이 나오지 않는다면 즉각적으로 질문하는 것이 답을 얻어낼 수 있는 속도도 빠르고 답이 나오지 않는다 할지라도 같이 문제를 해결할 수 있다는 점에서 유용함을 느꼈습니다.

프로젝트를 마무리하며

kmin

저희는 MVP의 관점에서만 보면 90%를 달성했다고 생각합니다… 나머지 10%는 리팩토링을 하지 않아서 생긴 구멍이라고 생각됩니다. 하지만 전체적으로 봤을 때는 30%정도를 달성했다고 하니 바톤을 이어받아서 진행해주시는 다음 카뎃분들이 완성도를 높여가실 것이라고 생각합니다. 화이팅!!

juchoi

주어진 과제를 해결하는 것이 아닌 실제 클라이언트의 요구를 듣고 조율하며 이에 해당하는 서비스를 제공하는 과정을 경험할 수 있어서 매우 좋았다.

sanam

어떤 일이든 마무리가 중요하다고 생각합니다. 그런 의미에서 이번 프로젝트는 aws로 직접 배포하는 과정까지 있어서 너무 좋았습니다.

GitHub

사이트 주소: https://saver.42seoul.io

깃허브 주소: https://github.com/innovationacademy-kr/slaps-saver

위키주소: https://github.com/innovationacademy-kr/slaps-saver/wiki

페이지 목록

액터: 일반유저 / 기자(일반기자, 데스크, 편집장) / 관리자