비록 클론 코딩이지만 처음으로 진행해보는 협업이라 전반적인 과정, 배운 내용들 그리고 회고를 작성하고자 한다. 이번에는 총 몇 파트로 나뉠지 모르겠지만 최대한 배운 내용들을 압축적으로 담아보고자 한다.
기획 및 사용자 정의서
클론코딩 프로젝트 자체는 이미 만들어진 사이트를 클론하는 것이기 때문에 기획이라 할 것은 없지만,그럼에도 수월한 개발을 하기 위해선 사용자 정의서를 명확히 작성한 후 구현해야 할 기능을 세분화하는 것이 중요한 것 같다. 처음에는 왜 이것을 해야 하는 것인지 와닿지 않았지만, 구체화 된 사용자 정의서가 전반적인 개발 과정을 얼마나 효율적이고 보다 정확하게 만들어주는지 이번 프로젝트를 하면서 깨달을 수 있었다.
사용자 정의서(개괄) : 링크
위 사진에서 보이는 것처럼 비록 전문성은 떨어질지라도 처음으로 팀과 함께 작성한 사용자 정의서의 일부분을 캡쳐한 것이다. 아무래도 웹사이트 구현이다 보니 페이지별로 기능들을 명시해놨다. 나아가, 우선순위에서도 확인할 수 있듯이 웹 사이트에서 필수적으로 있어야 할 기능들은 1순위로 그 후 순차적으로 있어야 할 기능들은 2 순위로 나눴다(3 순위도 넣을까 하다가 추후에 논의하면서 추가하기로 하고 일단 넘어갔다)
화면 정의서 (사용 툴: Figma) + API 명세서
위와 같은 형태로 Figma를 사용해 화면을 구상해놓고(사실 클론이라 그냥 실제 페이지 갭쳐하면 되지만, 피그마도 연습할 겸 (팀원들도 원하는 듯 해서) 프그마로 전반적인 웹 구조를 짜놨다. 실제 클론 코딩이 아닌 실제 서비스를 기획할 때 밑바닥부터 차근차근 다 만들어야 하기 때문에 미리 피그마를 연습해놓는 것도 좋은 생각인 것 같다.
화면 정의서와 사용자 정의를 일대일 대응 시켜 관련 페이지에서 필요한 기능에 따른 API호출 또한 명시해놨다. 위 과정들은 모두 벡엔드와 같이 작업한 것이기 때문에 기능 별로 분할하는 것이 중요했다. 실제로 프로젝트를 진행하면서 프론트는 페이지 단위 벡은 기능 단위로 생각하는 차이점이 있었다. 아주 초기에는 소통의 어려움이 조금 있었으나, 점차 절충점을 찾으면서 원할하게 프로젝트를 수행할 수 있었다 (이래서 개발자도 소프트 스킬이 중요하다고 하는구나.....만약 소통이 잘 안 됐으면 정말 어려웠을 것 같다.....)
비록 전반적으로 아직 보완할 부분들이 있지만 일단 기간도 매우 짧고해서 프로젝트를 진행하면서 보완하기로 합의를 보고 위의 내용들을 바탕으로 시작을 했다.
작업 관리
프로젝트를 하기 위해선 무엇보다 작업 관리가 매우 중요한 것 같다. 개발을 잘하면 당연히 좋지만, 전반적인 프로젝트의 흐름을 파악하지 못하면...조금 힘들지 않을까 생각이 든다. 다행히 Github에선 전반적인 프로젝트의 흐름을 잘 파악할 수 있도록 여러 기능들을 제공해주고 있다.(혼자 할 때는 사용할 일이 없어서 (사실 생각하지도 못 했지만))
issue:
Use GitHub Issues to track ideas, feedback, tasks, or bugs for work on GitHub.
GitHub Issue를 아이디어 공유, 피드백, 태스크, 버그 관리로 사용하세요. - GitHub
깃헙에선 위와 같이 issue의 사용 목적을 명시하고 있다. 우리 팀에선 issue에 자신이 달성할 목적,상세 내용, 참고 사항을 작성기로 정했다. 예를 들어 stackoverflow의 메인 페이지의 UI를 구현한다면 레이아웃 미디어 쿼리 등 완료하면 체크하는 형식으로 작성했다. 그리고 사진의 오른쪽을 보면 Assignees, Labels(벡엔드 팀장님이 커스텀해주셨다....!!!) Projects, 그리고 마일스톤까지 입력할 수 있어. 누가 어떤 파트를 어디까지 한 눈에 파악할 수 있게 해준다. issue는 매번 새로 작성할 필요 없이 custom 해서 사용할 수 있다
Project:
Project을 들어가보면 이렇게 칸반 형태로 나눠어져서 누가 무엇을 하고 있고 어디까지 완성됐는지 일목요연하고 확인할 수 있다.
Mileston:
Milestone의 경우 벡엔드와 프론트엔드 분리해서 프론트는 페이지별 벡은 기능별(우선순위별)로 진행했다. 아무래도 담당하는 역할이 다르다보니 이렇게 나눠서 진행해도 크게 문제되지는 않았던 것 같다. 잘 활용하면 프로젝트가 어느 단계까지 진행되고 있는지 파악할 수 있는 장점이 있다.
Wiki
Wiki에선 위와 같이 지켜야 할 커밋 컨벤션에 대해서 명시를 해놨다.
비록 처음이지만, 전반적으로 깃헙의 많은 기능들을 유용하게 활용하려고 팀원들과 함께 노력했다. 아무래도 여러 사람이 참여하는 프로젝트인 만큼, 개별적으로 진행하면 중구난방으로 갈 확률이 높다. 따라서, 이렇게 하나의 팀으로 잘 진행될 수 있게 프로젝트 시작 전 여러 규칙 + 위와 같이 전반적인 흐름을 파악할 수 있는 여러 기능들을 활용하면 좋을 것이다...(실제로도 많은 도움이 됐다...)
다음 글은 프로젝트 진행하면서 사용했던 git flow에 대해서 다루고자 한다.
