[정리] KT AIVLE 8기 빅프로젝트 후기 (2) - 프로젝트 회의록 작성 및 문서화의 중요

이번 두번째 후기에서는 실제 프로젝트 진행 시 팀원들과 구체적으로 어떻게 프로젝트를 이어 나갔으며,
의견 전달 및 제안, 진행상황 보고 등을 어떤 방법으로 진행하였는지에 대해 회의록 작성 및 문서화와 관련하여 정리해보고자 한다. 

 

이번 KT AIVLE 8기 빅프로젝트는 4,5차 미니프로젝트 팀과 동일한 팀 구성으로 이루어졌다. (그 다음 기수는 어떨지 모르겠다)

4차 미니 프로젝트에서부터 나는 항상 팀 노션 페이지를 만들고 회의록 및 진행상황을 정리하는 역할을 맡았다.

말로만 이야기하다보면 나중에 구체적으로 어떻게 하기로 했는지 기억이 나지 않고,
서로 다르게 기억하면 그로 인한 불필요한 충돌이 발생할 가능성이 있다. 이런 점을 걱정하여 항상 회의록을 작성해왔다. 

 

하단에서 4차 미니프로젝트, 5차 미니프로젝트, 그리고 마지막 빅프로젝트까지 어떻게 문서화를 진행해왔는지 기록해보겠다. 먼저 첫번째로 노션 회의록을 만든, 4차 미니 프로젝트이다. 

 

(1) 4차 미니 프로젝트 회의록

4차 미니프로젝트 첫 노션 회의록

첫번째 회의록은 짧은 기간동안 진행되는 프로젝트였기 때문에, 위 이미지와 같이 토글로 회의록을 작성하였다. 단기  소규모 웹프로젝트였기 때문에 역할 분담, 프로젝트 진행 상황, 오늘 할 일을 매일매일 간단하게 작성하였다. 다만 우리 조는 '이슈 관리'라는 파트를 따로 만들어, 웹프로젝트를 진행하는 과정에서 만나는 오류를 기록해두는 습관을 가지기로 했다. 같은 환경, 같은 브랜치에서 작업하고, 또 브랜치를 머지하는 과정에서 팀원 a가 맞닥뜨린 오류를 팀원 b가 동일하게 경험하는 경우, 팀원 a가 미리 정리해둔 해결 방법이나 문제 원인 등을 팀원 b가 참고하여 빠르게 오류를 해결하고 불필요한 시간 소모를 막고자 하였다. 버그 픽스(bug - fix)는 언제나 많이 일어났기 때문에, 이슈 관리 파트는 항상 분량이 가득했던 것 같다. 

 

 

(2) 5차 미니 프로젝트 회의록

다음은 4차 미니프로젝트를 배포하고 고도화하는 5차 미니프로젝트의 회의록이다. 이번에는 좀 더 회의록을 가독성있게 만들고, 나중에 포트폴리오를 작성할 때 활용할 수 있도록 하기 위하여 조금 더 형식을 바꾸어 보았다. 아래는 5차 미니 프로젝트 회의록 화면이다. 페이지를 딱 봤을때 한눈에 들어올 수 있도록 만드는데에 집중했다. 

5차 미니프로젝트 두번째 노션 회의록

어떤 프로젝트인지 간략하게 정리하고, 역할을 좀 더 세분화하고, 깃허브 링크와 프로젝트 내용이 정리된 ppt 공유 링크를 통해 다시 회의록을 찾아볼 때 어떤 프로젝트였는지 더 잘 알아볼 수 있도록 하였다. 회의록의 경우 페이지 블록을 날짜마다 만들어 관리하였다. 이 또한 단기 프로젝트였기 때문에, 회의록 내용 자체는 4차 미니프로젝트와 비슷한 구조로 진행하였다. 오늘의 할 일(팀원별), 프로젝트 진행상황, 이슈 관리 파트를 나누어 작성하였다. 

 

 

(3) 빅 프로젝트 회의록

이제 마지막으로 대망의 빅프로젝트이다. 빅프로젝트는 대략 7~8주 정도의 기간을 두고 진행하는, 이전과는 다르게 규모가 큰 프로젝트 였기 때문에, 회의록 페이지를 보다 더 현명하게 만들어야겠다고 생각했다. 

평일마다 회의를 진행할 것이고, 관리해야 할 산출물들도 많았으며 계속해서 계획을 세워야 했다. 프로젝트가 커지고 맡는 역할이 많아지면서 다른 팀원 파트에 대한 이해도가 떨어지게 될 것이고, 버그는 더 많이 발생하게 될 것이라고 생각했다. 그랬기 때문에 빅프로젝트 노션 페이지를 크게 두 페이지로 나누었다. 

대망의 마지막 빅프로젝트 회의록!

첫번째 페이지는 회의록 페이지,

그리고 두번째 페이지는 이슈 트래킹 페이지이다.

(3) - (1) 회의록 페이지

먼저 첫번째 페이지인 회의록 페이지부터 살펴보자. 기존과는 다르게 중-장기 프로젝트였기 때문에 아래와 같이 데이터베이스에 회의록을 매일매일 작성하였다.  

 

 

제목과 카테고리 설정을 통해 나중에 특정 내용을 찾기 쉽도록 만들었다. 

회의록 내부에는 이번 주 목표, 공지사항 또는 코치님 피드백, 그리고 각자 팀원별 진행상황, 필요한 경우 추가 논의해야할 부분에 대해 자유롭게 작성하였고, 매우 중요한 공지사항이나 팀 전체가 필수적으로 알아야 하는 것은 회의록 최상단에 강조하여 작성하였다. 예시로 팀원들과 함께 작성한 몇개의 회의록을 가져와 보았다.

회의록 내 중요 공지 및 피드백, 계획 정리

 

 

각자 당일 개발 진행 상황 실시간 정리

 

 

(3) - (2) 이슈 트래킹 페이지

다음은 프로젝트를 진행하면서 정말 많이 도움되었던 이슈 트래킹 페이지이다. 

이슈 트래킹 페이지는 이전 미니프로젝트에서 이슈 관리 파트로부터 영감을 받아 작성한 이슈 관리 전문 페이지이다. 

해당 페이지에서는 발생한 버그/오류를 기록하고, 문제의 원인과 해결 방법을 문서화하여 정리해두는 용도로 사용하였다. 또한, 프로젝트의 규모가 커지면서 서로의 파트를 알기 어려워지면서, 구현한 기능을 다른 팀원이 테스트하거나 디버깅/버그 픽스하기 용이하도록 구현한 파트의 설명 - 즉, 주요 함수나 로직, 사용하는 api key, postman 테스트 방법, 주요 파이프라인 설명, 테스트 시 유의사항과 같은 것을 문서화하여 정리해두기로 하였다.

 

회의록 페이지는 그날 논의하였던 내용과 당일 진행상황을 함께 기록하고 논의하고, 나중에 어떤 내용을 논의하고 결정했었는지 확인할 수 있는 페이지였다면,  

 

이슈 트래킹 페이지는 각자 완성한 기능과 관련된 설명, 그리고 다른 팀원들과 공유하면 좋을 오류 해결 방법 및 주의사항을 문서화해둔 해설지같은 페이지였다.

 

실제로 모든 팀원들이 이슈 트래킹 페이지를 통해 오류를 빠르게 해결하고, 바쁜 팀원에게 질문하면서 불필요한 시간을 쓰기 보다 깔끔하게 문서화된 내용을 바탕으로 효율적인 프로젝트 진행이 가능했다. 

 

예시로 하단의 이미지를 보자. 

 

 

내가 구현한 기능을 문서화한 이슈 트래킹 페이지

 

이와 같이 다른 팀원이 내가 맡은 파트를 처음 봐도 이해할 수 있으면서, 갑작스런 오류를 고쳐야할때 참고할 수 있도록 기능에서 사용하는 dto, domain, 데이터, 테스트 방법, 전체 파이프라인 및 관련 파일 설명을 문서화하였다. 

 

이렇게 정리된 회의록 및 문서들을 기반으로 보다 정확하면서, 효율적인 팀 프로젝트가 가능했던 것 같다. 

이번 kt aivle 과정을 거치고 마지막 빅프로젝트를 진행하면서 팀원들과의 소통을 어떻게 하면 더 잘 할 수 있을지, 불필요한 시간 소비를 어떻게 줄일 수 있는지에 대해 많이 익힐 수 있었던 것 같다.