구름톤 Web IDE 프로젝트에 대한 기획단계를 되돌아 보기
개요
이론기간이 끝난 후에 24.01.29 ~ 24.02.26(약 28일)간의 짧은 스프린트 프로젝트가 시작되었다. 구름톤에서 생각한 요구 사항은 아래와 같았다.
### 주요 목표와 하위 목표
- Web IDE의 기본적인 틀과 사용자 인터페이스(UI) 설계
- 복잡하지 않고 직관적인 레이아웃을 디자인하여 사용자가 각 기능을 빠르게 찾을 수 있도록 합니다.
- 다양한 디바이스 및 화면 크기에서 웹 IDE가 잘 작동하도록 반응형 디자인을 구현하여 일관된 사용자 경험을 제공합니다.
- 회원 가입 및 로그인 기능 구현
- 회원 가입, 로그인, 비밀번호 재설정 등의 기능을 포함하는 사용자 관리 시스템을 설계하고 구현합니다.
- 코드 편집기 기능 구현
- 사용자가 손쉽게 새 파일 및 폴더를 생성하고 프로젝트 구조를 조직할 수 있는 기능을 구현합니다.
- 파일 내 코드를 편집하고 저장할 수 있는 기능을 구현합니다.
- 채팅 기능 구현
- 다수의 사용자가 동시에 채팅할 수 있는 실시간 채팅 기능을 구현합니다.
- 채팅 내용을 효율적으로 검색하고 필요한 정보를 빠르게 찾을 수 있는 메시지 검색 기능을 추가합니다.
우리팀은 모두가 협업 개발 프로젝트를 경험해보지 못한 사람들로 이루어져 있었고, 팀장인 나도 협업 프로젝트를 시작하는 것이 처음이였다. 그래서 최대한 이전 기수에서 진행하고 남겨져 있던 블로그 포스트나 발표자료들을 모두 참고했다.
28일이라는 기간동안에 요구하는 기능들이 생각보다 많다고 생각했다. 제공해준 이론기간의 강의를 모두 풀로 들었다면 가능할 수 있었지만 정말 처음 개발에 들어가는 사람에게는 처음부터 힘든 프로젝트라는 생각이 들었다.
그래서 프로젝트 기획단계에서 가장 중요했던 부분은 협업툴을 선정하고 적용시키는 것이라고 생각했다. 팀원 모두가 자주 모여서 작업하는 상황이 아닌 온라인으로 협업을 하는 상황에서 서로의 의사소통을 원할하게 하도록 도움을 줄 수 있는 툴이 필요했다.
아이디어 기획
전에 만나려고 여러번 시도했지만 팀원 모두가 모이는 시간을 맞추기가 어려웠는데 새로운 프로젝트 들어가는 김에 아이디어 기획 겸 신촌쪽에서 모두 모여서 회의를 진행했다. 작은 스터디룸을 빌려서 사용했는데 생각보다 비좁아서 아쉬웠었다. 그럼에도 비대면으로 진행할때 보다는 많은 아이디어가 오갔고 확실히 비대면 보다는 나은 결과물이 나왔다.
약 6시간 가까이 회의한 끝에 여러가지 의견들이 나왔지만 구름톤을 진행하면서 느낀 아쉬운 점을 담아서 아이디어를 확정했다.
소규모 커뮤니티 IDE
블라인드, 에브리타임 등 익명 커뮤니티 같은 게시판을 통한 자유로운 질문 분위기 조성이 가장 큰 목적이였다.
그래서 우리는 컨셉에 필수적으로 들어가야 하는 기능들을 정리했다.
필수 기능
- 코드에디터 구현
- 로그인/회원가입 구현
- 익명 게시판 CRUD
- 프로젝트 참여인원간의 채팅 기능
협업 Tools
컨셉을 어느정도 잡고, 중간부터는 협업툴을 활용하기 시작했다. 아이디어 브레인스토밍은 만나서 진행했지만, 이후 프로젝트 진행에서는 90%이상이 비대면으로 이루어지기 때문에 프로젝트 진행을 원활하게 하기 위해서 여러가지 협업 툴이 필요했다.
Figma
먼저 ide 컨셉과 여러가지의 이야기들을 자유롭게 마인드 스토밍 할 수 있도록 하는 하나의 화이트 보드 처럼 상용할 수 있는 피그잼과 UI를 구성해볼 수 있는 Figma를 도입했다.
Figjam
개인적으로 처음 써보는 툴이였지만 사용경험이 너무 좋았다. 큰 화이트 보드를 같이 보면서 수정하는 느낌이 들었다. 정말 자유롭게 마인드 스토밍을 하는데 큰 도움이 됐다.
요구사항 정리와, 컨셉같은 아이디어들 부터 기능 우선 순위 기획, 가벼운 와이어프레임까지도 피그잼에서 모아서 볼 수 있었다. 기획단계뿐 아니라 개발 단계에서도 가끔 와이어 프레임을 확인하러 피그잼을 자주 접속해서 확인했다.
여기서 우리팀은 기능 기획과 페이지 주요 테마 색상까지도 선정했다.
Figma
어느 정도 컨셉을 구체화 하면서 피그마를 통해서 와이어 프레임을 구제적으로 적용하기 시작했다. 특히 유저 flow에 맞추어서 여러가지 버튼과 페이지들을 설계했다.
프론트 팀에서나 팀내에서 디자인적인 툴을 활용해본 사람이 없어서 초반에는 좀 어려웠지만 어느정도 틀을 잡는데에는 기본 기능을 활용하는 방식으로도 충분하다고 느꼈다.
그럼에도 디자이너의 부재는 너무 아쉽게 느껴졌다. 이번 프로젝트뿐 아니라 다음 프로젝트에서도 그렇게 느꼈다. 특히 프론트엔드 팀장을 맡게 되면서 개발적인 부분뿐만 아니라 유저 경험을 좋게 만드는데는 디자이너의 지분이 80%가 넘을 정도로 중요하다는 점을 깨달았다.
Notion
스터디때 사용해왔던 노션을 프로젝트에서도 사용했다. notion은 일단 UI가 깔끔하고 사용하기 편리하다는 장점이 무엇보다도 큰 것같다.
프로젝트에 관한 명세나 문서화가 필요한 부분들은 모두 노션에다 정리하는 방식으로 진행했다. 프로젝트 요구사항, R&R(팀원 역할), Commit convention(github), API 문서등을 노션을 통해 문서화 했고, 프로젝트 진행기간동안에 가장 많이 사용한 툴이라고 할 수 있다.
Jira
Jira는 이번 프로젝트를 시작하면서 처음 접한 툴이었다. 프로젝트를 시작하기 전에 전 기수분들이 적어주신 회고들에서 대다수가 사용한 이슈관리 툴로 개발간의 이슈들을 관리하는 툴이였다. 그래서 팀원들간의 이야기 끝에 쓰는 방향으로 자리잡았고, 처음 쓰는 툴인만큼 여러가지 시행착오를 거쳤다.
일정관리 툴을 적용시켰지만 프로젝트 일정을 어떤 방식으로 잡아야 할지에 대해 갈피를 못잡고 있었는데 기획 발표전에 구름측에서 진행하는 기획 멘토링을 통해 현업 기획자님의 조언을 듣고 정할 수 있었다.
기획자님께서는 마일스톤을 잡고가는 것이 좋을 것 같다고 이야기 해주셨고, 좋은 아이디어 구제화만 잘 시키면 완성도에 따라서 좋은 결과를 얻을 수 있을 꺼라고 말씀해주셨다.
그래서 우리팀은 2개의 스프린트로 마일스톤을 나눴다. 1차로 핵심기능 개발과 2차로 추가기능 개발로 나누었다. 이때 핵심기능개발은 이전에 컨셉을 정할떄 나왔던 필수적인 기능들을 개발하는 일정으로 잡고, 추후에 세부적인 기능을 구현하는 스프린트를 일정으로 잡았다.
위에 사진을 보면 기획당시에 계획했던 일정과 거의 맞추어졌지만 핵심기능 개발의 일정이 좀 더 늘어났음에도 우리는 완성도 있는 결과물을 얻을 수 있었다.
스프린트나 타임라인을 정리할 수 있다는 점에서 jira는 장점이 있지만 제대로 활용하지는 못했다. 그래서 타임라인 같은 이슈와 github issue를 나중에 활용해보는 것도 좋겠다는 생각이 들었다.
설계
아키텍처
아키텍처를 작성하고 확정하는 것은 기획단계에서 가장 어려웠던 부분 중에 하나였다. 일단 배포를 진행하는 방식에 대한 지식이 없었고, 하나의 ec2에 올리는 방식으로 배포할지, 프론트와 백엔드를 나누어서 배포를 할지에 대한 여러가지 생각이 겹쳐서 많은 혼란을 겪었다.
그래서 프론트와 백엔드 모두다 CI/CD를 구축해놓고, 아키텍처를 작성하는 것이 좋겠다는 의견이 나왔고, 그때부터 약 3일동안 프론트와 백엔드 팀장이 각각의 배포를 위한 CI/CD 구축을 진행했다.
정말 코어 타임인 10:00 ~ 19:00뿐 아니라 이후 시간까지도 스크립트 작성과 보안 설정등을 만지면서 여러 시도 끝에 프론트와 백엔드 모두 github action을 통해서 CI/CD를 구축했다.
ERD
CI/CD를 구축하고 난 이후부터는 우리팀의 프로젝트의 아키텍처가 어떻게 구성될지에 대한 청사진을 그릴 수 있었다. 프로젝트를 시작하면서 CI/CD를 구축하면서 이후 프로젝트 진행에 있어서 엄청난 도움이 되었다. 병합이나 배포 프로세스를 직접 하지 않아도 자동화 되어있다는게 개발 속도에 큰 도움이 되었다.
만약 프로젝트를 시작할때 CI/CD를 구축을 해보지 않았다면 한번쯤은 해보는 것을 추천한다. 정말 편리하고 팀원 모두에게 도움이 되는 길이라고 생각한다.
우리팀은 익명 게시판과 채팅 기능이 들어가는 web IDE이다 보니 DB 다이어그램 설계가 중요했다. 그래서 기획단계에서 모든 다이어그램을 상세하게 구성했고, 백엔드 팀장분이 많은 노력을 기울였다. 물론 중간에 변경되는 부분이 일부분 있었지만 기획단계에서 신경쓰다 보니 변경점이 줄어들었다.
참고로 DB 다이어그램과 아키텍처는 모두 Draw.io를 활용했다.
발표
모든 기획을 마쳐가면서 기획발표를 준비했다. 크게 발표 순서는 아래와 같이 구성했다.
- 개요
- 설계
- 구현
- 프로젝트 관리 문서화
개요에서는 이 프로젝트의 컨셉과 컨셉의 기대효과를 중점으로 발표했다.
설계에서는 사용자 flow에 대한 와이어 프레임과 ERD 다이어그램, 그리고 API 문서를 바탕으로 프로젝트 설계가 어떤 방식으로 되었는지를 설명했다.
구현에서는 Library와 프레임워크, 사용할 기술 스택등을 정리해서 발표했고, 가장 중요한 아키텍처에 대해 이야기했다.
마지막으로 프로젝트 관리 문서화에서는 앞에서 설명했던 협업툴이나 문서화에 사용할 툴, 그리고 가장 중요한 코드 관리 툴등을 어떻게 활용할 예정이고, 사용중인지에 대해 설명하는 방식으로 끝냈다.
다른 팀들보다 ppt에 기교나 이목을 집중시키는 부분은 부족했지만 기획단계에서 확정된 부분들을 상세하게 표현한 부분에 대해서 칭찬을 받았다.
이후 프로젝트가 어떻게 진행되었고 결과물이 어땠는지에 대한 이야기는 추후에 이어서 하도록 하겠다.
댓글남기기