25/01/02 - 세 번째 회의
깃허브 조직 생성
12월 29일에는 큰소리 깃허브 올가를 만들었다.
오늘 글쓰면서 구글에 검색해봤는데, 세번째로 보인다.
조직 메인화면 진짜 대충 작성했는데.. 부끄럽기도 하고 신기하기도 하다.
로고도 캡쳐해서 넣었는데 이렇게 보니까 뭔가 있어보여서 좋다 ㅎㅎ
디자인 작업 시작
두 번째 회의 이후, 12월 28일에 프론트 팀원들이 기획에 맞게 와이어프레임 작업을 추가로 진행했다.
이 무렵 회의하면서 디자인을 어떻게 할 지에 대해서도 이야기 했었는데, 마침 시디과에 아는 지인이 있는 친구가 있어서 컨택했으나, 아쉽게 같이 하기 힘들게 되어 우리끼리 디자인을 해보기로 했다.
12월 30일에 디자인을 시작했고, 2주 정도에 걸쳐서 페이지 디자인을 시작했다.
디자인을 하기에 앞서 먼저 키 컬러를 정해야 했는데, 아무래도 로고에 맞춰서 색상을 잡으면 좋을 것 같아서, 노란색을 키 컬러로 잡고 디자인을 시작했다.
세오스하면서 디자이너들이 디자인하는 페이지를 어깨너머로 본 것이 많이 도움되었다.
처음에는 이렇게 간단하게 와이어프레임만 잡는 느낌으로 했었다가
조금 조잡하지만.. 이렇게 색상 팔레트를 만들고
이렇게 기능별로 페이지를 나눠서 디자인을 시작했다.
여러가지 안을 고려하면서 후보군을 만들고, 투표로 뽑는 과정을 반복하면서 디자인했다.
소통 방법 논의 & 역할 분담
이렇게 팀으로 모여서 다같이 프로젝트를 하면서 느낀 점은 함께라서 좋지만, 함께라서 힘들다는 것..
먼저 함께라서 좋았던 점은, 나는 디자인에 감각이 전혀 없었고, 피그마를 사용하는 것도 어색했다
하지만 경험이 있는 팀원이 유명한 ui 템플릿에서 괜찮은 디자인을 가져와서 넣어주고, 디자인 감각이 좋은 팀원이 디테일을 잡아주면서 서로의 시너지를 통해 더 좋은 결과물이 나오는 것을 눈으로 볼 수 있었다.
하지만 함께라서 힘들었던 점은, 사람이 모였는데 사람들을 주도하는 역할을 하는 사람이 없어서 진행이 잘 되지 않았던 점이다.
일단 이 프로젝트를 위해 사람들을 모아준 동생이 암묵적으로 팀장 역할을 수행하고 있었지만, 명시적으로 '너가 팀장이다!' 라고 하지 않았어서 모두 누구에게 의지해야 할 지 잘 몰랐던 상황에서, 일단 와이어프레임은 만들었는데 카톡으로 소통이 잘 되지 않아서 의사 결정이 빠르게 이뤄지지 않아 디자인 진척이 잘 되지 않았다.
그래서 1월 2일 회의를 통해서 이런 부분에 대해 논의하고 해결책을 찾아갔다.
그래서 특정 기간마다 회고를 하면서 우리 팀 분위기에 대해 이야기 하는 시간을 가졌다.
또한 그라운드 룰로 바빠서 연락이 힘든 기간이 있다면 미리 공유하고, 카톡을 확인한 다음에는 꼭 반응을 남기는 것으로 이야기했다.
누군가가 보기엔 당연한 걸 왜 규칙으로 정하나 할 수도 있겠지만.. 명확한 목표나 주도자가 없는 상황에서 이런 규칙조차 없으면 프로젝트가 흐지부지되는 건 한 순간이라고 생각한다.
그래서 이런 점을 먼저 집어서 문제를 제기하고 해결책에 대한 의견을 제시해준 팀원한테 고마웠다.
그리고 역할을 확실하게 명시해서 분담하기로 했다.
이때까지의 프로젝트 진행 과정은 뭔가 진척은 조금씩 되고 있는데, 주도하는 사람이 없어서 '그래서 이제 뭘 해야하지?' 에 대한 답을 아무도 내리지 않다보니 명확한 방향이 존재하지 않았다.
그래서 서로 의사소통을 할 때는 당연히 수평적인 소통이 좋지만, 의사결정을 할 때는 어느 정도 수직적인 체계가 필요함을 느꼈다.이렇게 역할이 명시된 이후로 프로젝트가 더 체계적으로 진행되는 것을 느낄 수 있었다.
개발 일정 논의
프론트와 백엔드가 협업할 때 사전에 맞춰야 할 부분으로 로그인 구현 방식과 API 명세서 공유 방식을 논의했다.
일단 토큰(refresh token) 을 사용한 방법으로 로그인을 구현하고, API 명세서는 스웨거를 사용하기로 했다.
세오스에서는 spring doc 를 사용해서 명세서를 작성했는데, 테스트를 통과하면, 해당 테스트를 기반으로 명세서를 작성해주는 방법이다보니 안정성이 높다는 장점이 있었으나, 개발할 때 명세서에 대한 코드를 일일히 작성해야했어서 너무 불편했다. 그래서 이번엔 스웨거를 사용해서 명세서를 작성하고 공유해보는 것을 제안했다.
같이 프로젝트 하는 팀원들은 협업 경험이 많지 않아서 일단 어느 쪽이든 경험해보는 것을 원했어서 스웨거를 사용하는 것으로 결정되었다.
그리고 일단 목표 기한이 있어야 다같이 열심히 개발하는 동기가 될 것 같아서 1월 15일까지 어느 정도 개발해보기로 얘기를 나눴다.
25/01/09 ~ 25/01/24 : 네 번째 ~ 여섯 번째 회의
네 번째 회의는 오프라인으로 모여서 진행했다.
홍문관에도 스터디 룸이 있다는 것을 이때 처음 알았다ㅋㅋ
네 번째 회의에서는 기획과 디자인을 마무리 짓고, 개발할 때 디테일한 논의 사항을 이야기했다.
회의 후에는 다같이 모여서 저녁을 먹고 맥도날드에서 디저트와 버거를 하나씩 먹고 헤어졌다.
그리고 이 날부터 데일리스크럼을 하기로 했다.
데일리스크럼은 매일 밤 10시에 노션에 그때까지 자신이 진행한 작업을 공유하고, 지각/미제출 시 벌금을 제출하기로 했다.
그런데, 이렇게 일주일 정도 해보니 잘 되지 않아서, 그 다음 회의 때 데일리 스크럼 방식을 노션에서 카톡으로 바꾸자고 제안했다.
노션에 하려면 직접 내가 떠올려서 진행 과정을 남겨야 하다보니 까먹기 쉬웠지만, 카톡으로 하면 다른 사람이 올렸다는 것을 인지할 수 있으니, 그 날 데일리 스크럼에 뭐라도 쓰기 위해서 뭐라도 하게 되는 자극을 받았다.
그 다음 주에는 데일리 스크럼 자체는 매일매일 잘 올라왔으나, 서로가 어디까지 진행했는지 큰 진행상황이 잘 보이지 않는 문제가 있어서 칸반보드를 두기로 했다.
이렇게 큰 진행상황을 보면서 작업하니 확실히 현재 프로젝트의 진행 상황을 한 눈에 보기 좋아졌다.
벌써 프로젝트를 시작한 지도 1달이 넘었다.
1달 동안 개발 환경을 세팅하면서 기술적으로 성장할 수 있었지만, 그보다 오랜만에 팀 프로젝트에서 주도적인 역할을 맡아서 진행하다보니 협업하고 소통하는 방법에 대한 고민을 더 많이 하게 되는 계기가 되어서 좋았다.
다음 글에서는 백엔드 리드 역할로서 회의를 진행하고 개발하면서 얻은 것과 느낀 점들을 정리할 예정이다.
'팀 프로젝트 > [2025] 큰소리 웹 페이지' 카테고리의 다른 글
| [큰소리 프로젝트] 1. 팀 빌딩 & 기획 (2) | 2025.01.04 |
|---|
