[개발 이야기] 사이드 프로젝트 개발팀을 굴려보자

사이드 프로젝트 개발 팀 Atties를 만들고 작성한 회고록입니다. 

좌충우돌 8주간 9인의 여정이 끝났다.

이 프로젝트는 프로젝트를 시작하는 12월 19일로부터 약 3주 전인 11월 30일부터 기획되어 있던 프로젝트이다. 2학기에 처음으로 '벚꽃 오프닝' 팀 프로젝트를 진행하며 느낀, 부족한 점을 개선하고 배운 점을 적용하여 내가 직접 프로젝트를 움직여봐야겠다고 생각하여 시작하게 되었다.

 

🧑‍🤝‍🧑 우리 팀은요!

우리 팀을 간단하게 소개하자면 기획자 1, 디자이너 2, BE 3, FE 2, FE와 PM을 맡은 나까지 총 9명이서 진행했다. 팀 빌딩은 내가 전담했고, 아이디에이션은 Planner가 전담하였다. 이후 나는 매니징과, 프런트엔드 팀 리딩과 전체적인 팀의 소통을 전담하였다.

 

🗣️ 커뮤니케이션

1. 자유로운 커뮤니케이션

물론 수직관계의 조직은 아니지만, 서로 모르는 사람들이 있기 때문에 서로 질문하는 것에 대해 눈치를 볼 수 있을 것 같았다. 이러한 커뮤니케이션 방식 개선에 매우 많은 노력을 들였는데, 아주 성공적이었다. 우선 게더타운을 이용해해 각자의 아바타를 만들어, 실제로 옆에 있는 것처럼 느낄 수 있는 환경을 만들었다. 디자이너+기획자/백엔드/프런트엔드 이렇게 3개의 방으로 나누어 작업을 진행하였다. 가끔씩 다른 방을 돌아다니며 다른 팀원과 논의하고 싶은 것이 있는지, 진행하는데 차질이 있는지 물어보곤 했다. 서로 거리낌 없는 분위기를 만들기 위해, 질문이 있는 파트 사람들을 내가 직접 데리고 다른 파트 방으로 넘어가기도 했다. 그리고 질문을 중재해 주면서 '다음부터는 이렇게 하면 된다'라는 것을 전달해 주었다. 

프로젝트가 중반쯤에 왔을 때는, 나 없이도 게더타운에서 서로 잘 소통하는 모습을 보면서 참 뿌듯했다.

 

2. 효율적인 커뮤니케이션 

협업툴은 Notion, Slack, Gather town을 사용하였다. Slack에 Notion과 Github을 연결하여 Notion 변경 시에, 그리고 Github에 새로운 commit 혹은 PR이 생길 경우 알람이 뜨도록 설정하여 Github Actions를 구현하였다.

# Github Actions :코드 저장소(repository)로 유명한 GitHub에서 제공하는 CI(Continuous Integration, 지속 통합)와 CD(Continuous Deployment, 지속 배포)를 위한 비교적 최근에 추가된 서비스

작업 시간 내에는 주로 Gather Town에서 소통하였고, 사진이나 링크를 전송하거나, 비동기적인 논의가 필요한 부분이 있으면 Slack을 이용하였다. backend, frontend, developer, disgner-planner-pm 등의 채널이 있으며, 이렇게 채널을 분류한 덕분에 대화하는 데 있어서 더욱 체계적으로 할 수 있었다. 개발자와 소통하고 싶으면 developer채널에, 기획자, 디자이너와 논의해야 할 사항이면 designer-planner-pm채널에 이야기를 하였다. 댓글로 하나의 논의 사항, 이슈를 남기면 그 댓글의 스레드로 해당 사항에 대해 이야기하는 방식으로 진행하였다.

슬랙을 제대로 이용해 본 건 이번이 처음인데, 왜 다들 슬랙을 찾는지 알게 되었다. 슬랙 최고 👍

놀랍게도 처음에 비해 많이 발전했다고 느끼는 것이 커뮤니케이션의 방식이었다.

프로젝트 초반, 팀원들의 슬랙을 보면 다음과 같은 특징이 있었다.

1. 상황 또는 주어 생략 : 사람은 종종 말할 때 자신이 알고 있는 것을 상대도 알고 있다고 가정한다. 그래서 많은 것을 생략하는데, 덕분에 내가 다시 구체적으로 어떤 질문인지 물어봐야 하는 상황이 많이 생겼는데, 스무고개를 하는 듯한 느낌을 받았다.

2. 장문의 정보 전달 : 구어체로 질문을 하게 되면 문장이 너무 길어지고, 가독성이 안 좋아진다. 심지어 글빨이 좀 별로인 사람은 문장 구조까지 뒤죽박죽이다.

3. 질문의 미종결 : 질문이 시작되었으면, 결론이 잘 정리되어 있어야 다른 팀원들도 큰 시간을 들이지 않고 해당 이슈에 대한 확인이 가능하다. 그렇지만 본인들끼리 대화하다가 해당 스레드가 마무리되는 일이 많았다.

 

그래서 나는 다음과 같은 커뮤니케이션 규칙들을 정했고, 굉장히 많은 부분들이 해소되었다.

1. 상황, 목적, 요점, 질문상대를 정확하게 기술

2. dot, 글머리를 반드시 활용

3. 질문이 해소되면 스레드의 마지막에 결론을 남기기

🙆‍♂️ Rules

Rule 1. 출퇴근제 : 10시~16시

우리의 작업 방식은 독특했다. 마치 학창 시절의 학교처럼 진행하였다. 오전 10시까지 출근하여 오후 4시에 퇴근하는 방식을 도입하였다. 이 방식은 매우 매우 대성공적이었다. 오전 10시까지 게더타운 회의 장소에 모여서 오전 회의를 진행하고, 오후 3시 40분까지 작업을 진행하여 오후 회의를 진행하며 마무리하는 방식으로 진행하였다. 점심시간은 12시부터 1시이다. 오전 회의에는 논의해야 할 사항들, 기획자+디자이너에게 전달받은 사항들, 오늘 오후 회의 때까지 논의해야 할 것들을 가볍게 브리핑하는 시간을 가졌다. 그리고 오후 회의에는 그날 작업했던 것들을 이야기하고, 논의할 사항에 대해 논의하며 마무리하였다.

매일매일 하루 6시간 이상씩 풀타임 투자를 하는 것은 매우 힘들었지만, 단 한 명도 빠짐없이 모두 잘 참여해 주었다. 페이를 받지 않는 팀을 이 정도로 이끌어 나온 것에 대해서 매우 뿌듯하다. 어디까지나 약한 규율 위에서 자유롭게 근무했다. 하지만 팀원들은 내가 기대했던 것 이상으로 많은 시간과 노력을 투자해 주었다. 근무 시간 동안 게더타운에 접속하는 것만으로도, 실제로 옆에 있는 것 같으면서도 관리가 잘 되었던 것 같다. 심지어 지각하는 인원이 있으면 내가 항상 모닝콜을 해줬다.

Rule 2. 일정은 유연하게 !

8주라는 긴 기간 동안 진행하다 보니 중간중간에 개인 일정으로 인해 빠져야 하거나, 늦게 참석하는 경우가 종종 생길 수밖에 없을 것이라 생각했다. 그런 경우에는 슬랙의 'schedule'채널에 전 날까지 작성을 하고, 저녁이나 주말에 빠진 만큼 작업을 하는 룰을 적용하였다. 이 허점을 악용하여 매일 빠지는 사람이 생기면 어떡하나 걱정을 했는데, 1주일에 1~2명만 정말 부득이한 사유가 있을 경우에만 빠지고 다들 거의 매일 출석해 주었다.

Rule 3. 예치금 3만 원

돈은 사람을 움직이게 만든다.

여러 스터디들을 운영하고, 진행하며 느낀 점이 '돈'이 걸려있어야 사람이 움직인다는 것이었다. 스터디를 진행하는데, 내 돈이 걸려 있지 않으면 우리는 아무런 관계를 맺지 않은 사이이다. 톡방, 혹은 슬랙을 나가면 그만인 관계이다. 그러나 내 돈이 상대에게 있다면 우리는 '돈'으로 엮인 관계이다. 채무 관계와 유사하다고 볼 수 있다. 내가 그 돈을 받기 위해서는 내가 약속한 스터디를 끝까지 완수를 해야 한다. 

우리는 예치금을 강하게 적용하여 3만 원을 하였다. 이 또한 프로젝트를 끝까지 끌고 가는데 있어서 한 힘을 발휘했을 것이라 생각한다. 오프라인 회의 때 한 팀원이 '이 예치금 보고 들어왔어요, 다들 열심히 할 것 같았어요.'라 이야기한 것이 기억난다.

Rule 4. 벌금제

10시 1분은 10시가 아니다.

1,2분씩 짧게 지각하는 팀원을 기다리며 회의 시작 시간이 늦어져 기다리는 팀원들의 시간이 아깝다고 생각하였다. 1명의 1분 지각으로 인해 6명이 기다리면 6*1=6, 팀원들의 귀중한 6분이라는 시간을 손해 보는 것이다. 이러한 것들이 쌓이고 쌓이다 보면 분명히 크나큰 시간이 될 것이다. 그래서 우리는 지각에 대한 규칙을 정하였다. 지각에 대한 기준이 모호할 때는 오전 정기 회의인 10시보다 3~5분 늦게 오는 팀원들이 종종 있었다.

지각 기준을 정확히 '10시'로 정한 이후부터는 애매하게 지각하는 팀원이 완전히 없어졌다. 이 룰을 적용한 덕분에 딱 10시 1분이 되면 바로 오전 회의를 진행하여 원활한 회의 진행을 할 수 있게 되었다.

하루는 내가 알람을 끄고 다시 잠들어서 지각을 해버렸다. 첫 스타트를 나부터 해서 그런지 팀원들에게 다른 말을 안 해도 다들 양심적으로, 자발적으로 작성해 주었다. 

프로젝트에 대한 전체적인 회고는 4L 회고 방식으로 진행하였다.

🧡 Liked : 이번 프로젝트를 진행하며 좋았던 점은?

1. 오프라인 회의를 중간중간에 진행한 점

 

몸이 멀어지면 마음도 멀어진다

3주 차와 6주 차에 한 번씩 오프라인으로 회의를 진행하였다. 더 자주 오프라인 회의를 진행하고 싶었으나, 팀원 대부분이 취준생이고 사는 곳이 같은 동네가 아니다 보니 자주 만나기에는 제약이 있었다.

 

팀원들과 온라인에서는 미처 털어놓지 못한 솔직한 이야기까지 전부 털어놓은 행복한 시간이었다. 얼굴도 몰랐던 팀원들인데, 오프라인으로 만난 이후로는 온라인에서 대화할 때 얼굴과 매칭이 되어 더 가깝게 느껴지고, 느낌이 새로웠다. 오프라인 회의를 조금 더 일찍 했어도 좋았을 것 같다. 다음부터는 오프라인 회의를 프로젝트 시작 전에 진행하여, 아이디에이션이나 친해지는 시간을 더욱 일찍 가져도 좋을 것 같다.

 

2 코드리뷰를 꼼꼼히 진행한 점

사이드 프로젝트와 개인 프로젝트의 차이점을 생각해 보았다. 사이드 프로젝트를 진행함으로써 개인 프로젝트와 다르게 얻어갈 수 있는 점이 어떤 점이 있을까? 일단 첫 번째로, 코드 리뷰를 통한 폭발적인 성장이다. 다른 팀원의 코드리뷰를 하며 코딩 노하우를 배울 수 있고, 다른 사람의 빠뜨린 부분을 찾으며 코딩스타일을 맞춰갈 수 있다. 그리고, 의문 사항이 생기면 함께 논의하며 한 번 더 생각해 볼 수 있다. 코드리뷰는 편협적인 사고와 지엽적인 스타일에서 벗어날 수 있게 해 준다.

코드리뷰를 하는 사람이 PR 올린 사람에게 일방적으로 알려주고, 지적하는 것이 아니라 함께 의논하고 이야기하며 코드를 한 층 갈고닦는 시간이 되기 위해 노력하였다.

열정적인 토론 현장

 

3. 게더타운에서 프로젝트를 진행한 점

마지막 회고 때 진행한 4L의 Liked에서 가장 많이 나온 부분이 '게더타운에서 프로젝트를 진행한 점'이었다. 게더타운에서 진행함으로써 함께 있다는 기분을 느낄 수 있었고, 언제든지 방을 이동해서 회의를 진행할 수 있었던 점이 좋았다. 

확실히, 줌 혹은 디스코드로 '음성'으로만 만나는 것과 게더타운이라는 가상공간에서 '가상 캐릭터'로 만나는 것의 차이가 큰 것 같다. '음성'으로의 만남은 마치 상대가 컴퓨터 세상 속에 있는 것 같지만 '가상 캐릭터'로 만나게 되면 상대가 실제로 내 앞에 존재하는 것만 같다.

 

4. '코어 타임'을 정해두고, 모두가 잘 지킨 점

# 코어타임 ; 집중업무시간대 (의무근로시간대)를 의미하며, 해당 시간만큼은 전 직원이 업무 상태를 유지해야 함

개발자의 경우 평일 오전 10시~오후 4시에 게더타운에 모여 작업을 함께 진행하였다. 12시~13시는 점심시간을 가졌다. 하루 총 5시간의 코어 타임을 가지고, 그 이후로는 자유로운 작업시간을 가졌다. 이 코어 타임이 이 프로젝트를 끝까지 이끌었다고 해도 과언이 아니다. 이 '코어 타임'이 없었더라면 프로젝트가 굴러가다가 한쪽 바퀴가 빠지거나, 핸들이 돌아가는 등 실패에 이르렀을지 모른다. 코어 타임가 끝난, 이후의 자유시간에도 다들 꾸준히 PR을 올리고 작업을 진행하였다.

사실 나는 하루 중에 자유 시간보다도 이 '코어 타임'이 제일 기다려졌다. 모두가 같이 토론하고, 논의하고, 결정하고, 그것들을 바탕으로 개발하는 이 시간이 나는 너무 즐거웠다. 매일매일 새롭게 배우고 성장하고 있음을 느낄 수 있었다.

 

5. 매주 함께 한 주를 회고하는 시간을 가진 점

우리는 매주 금요일마다 모두가 피그잼에 모여서 회고를 진행했다. 4~7주 차는 KTP를, 8주 차 마지막에는 4L 방식으로 진행하였다. 팀원들의 깊이 있는 생각들을 알 수 있었고, 프로젝트를 앞으로 어떻게 개선하여 이끌어나갈 수 있는지 힌트를 얻을 수 있는 매우 매우 뜻깊은 시간이었다.

 

😅 Lacked : 이번 프로젝트에서 아쉬웠던 점은?

1. Jira 협업툴을 도입하지 못한 점

노션의 칸반 보드를 이용하였으나, Github에 연동이 되지 않고, BE와 FE, 기획자와 디자이너가 다른 칸반보드를 사용하여 통일화가 되지 않았다는 점이 아쉬웠다. 중간에 Jira를 도입하기에도, 이미 사용하는 칸반 보드가 있어서 옮기기가 쉽지 않았다.

=> 팀원들과 논의 후 Jira 등 도입할 협업툴을 프로젝트 '시작할 때' 도입하자. 중간에 도입은 쉽지가 않다.

 

2. 기획자와 디자이너에 대한 규칙이 모호했던 점

개발자들은 오전 10시부터 오후 4시까지 정해진 코어 타임이 있었다. 처음에는 기획자와 디자이너도 개발자와 동일하게 룰을 적용하여 진행하려 하였으나, 디자이너가 개발자만큼 시간 투자가 필요할 것 같지 않다고 생각을 하였다. 그래서 후에 디자이너와 기획자를 모집할 때는 출퇴근제 룰을 적용하지 않았다. 

이 때문에 프로젝트 초반에, 디자인 팀에 프로젝트에 열심히 참여하지 않는 팀원이 발생하였다. 연락을 계속 취하며 이야기를 나눠보고, 다른 디자이너 분과 이야기를 한 끝에 결국 잘 해결이 되었다. 그 팀원이 아예 프로젝트 진행에 대한 의지가 없었더라면 어떻게 해야 할지 곤란했을 것이다.

=> 퇴출에 대한, 그리고 새로운 팀원 영입에 대한 규칙을 미리 세워놓고 해야겠다.

 

3. 기획과 디자인, 개발을 동시에 시작한 점

기획과 디자인을 개발 1주일 전에 미리 진행하려 했으나, 구름톤에 4일간 다녀오는 바람에 이를 진행하지 못하였다. 그래서 프로젝트 시작 전 주말에 빠르게 진행하려 하였다. 프로젝트를 시작하게 되면 개발자들이 세팅을 마친 후 바로 프로젝트에 몰입할 수 있게 하기 위해서였다. 그러나 기획 방향, 콘셉트, 디자인 방향이 전혀 나오지 않은 상태에서 기획과 디자인을 재촉하는 데에는 크게 무리가 있었다. 1~2일 만에 기획과 디자인을 급하게라도 진행하면 무언가 나올 것이라 생각한 나의 실수였다.

결국 프로젝트 1주 차 3~4일은 기획자와 디자이너의 진행을 위해 개발자 휴무를 하였다. 그 이후로는 멈춤 없이 프로젝트를 원활하게 진행하였다. 어느새 개발이 기획과 디자인을 따라가는 구도가 되었다.

=> 기획과 디자인은 개발보다 세 발자국 먼저 Start 끊기

 

4 Type을 처음부터 제대로 설정하지 못한 점

Typescript를 본격적으로 도입하여 진행한 프로젝트는 이번이 처음이다. 그래서 Type 설정이 낯설었고, 기피했다. 그러나 결국에는 넘어야 했던 산이었던 것이다. Type을 설정한 코드도 있고, 안 한 코드도 있어서 나중 가서는 혼동이 왔다. 맨 처음부터 Type설정을 모두 했으면 모르겠는데, 안 하고 넘어간 부분도 있어서 귀찮으면 그냥 안하고 넘어가기도 했다.

=> 타입 설정은 기초부터 탄탄하게, 설정하지 않았다면 PR Merge 불가하도록

 

5. 폴더의 기준을 명확하게 나누지 못한 점

우리는 프로젝트를 시작하며 api들은 apis폴더 안에, 훅은 hooks 안에, 컴포넌트는 components 안에, 페이지 컴포넌트는 pages 안에 넣자는 규칙을 정했다. 하지만 그 안에서의 규칙을 정하지 않은 것이다. 어떤 api가 artwork폴더에 들어가고, 어떤 api가 auction폴더에 들어가는지에 대한 기준이 모호해진 것이다. 시작할 때는 '나중에 가서 수정하면 되겠지'라는 생각으로 일단 시작을 하였으나 나중에 가니 눈덩이가 점점 커져서 다시 눈사람을 만들기에는 번거로울 작업이라 수정하지 않게 되었다. 처음에는 그저 '귀찮음'이었지만, 나중 가서는 '불가, 너무 힘듦'이 되는 상황이 와버렸다.

=> 처음부터 모든 폴더에 들어가는 기준을 구분할 수는 없겠지만, 개발하다가 '어떤 폴더에 넣어야 하지?'라는 의문점이 생긴다면 그때 그 때 기준을 세우자

 

6. api에 사용하는 변수명, 어느 페이지에서 api를 전송하는지에 대한 기준을 명확히 정하지 못한 점

artwork vs artWork, user vs member 등 혼동해서 사용한 것들이 많다. 백엔드에서는 member를 사용하여 구현을 하고, 프런트에서는 user를 사용하여 구현을 하고 나중 가서 합을 맞춰보려니 그 점이 다르다는 것을 알게 되었다.

=> 백엔드 팀과, 그리고 프런트엔드 팀과 함께 변수명을 맞추고, 어느 페이지, 어느 시점에 어느 api를 전송할지 미리 정하고 시작하자. 시작하고 정하는 게 아니라 말이다.

 

7. 회의 내용을 그날 그 날 '한 곳에' 정리하지 않은 점

처음에는 노션에 회의 내용을 기록하였다. 노션에 적으니 아무도 읽지 않아 나중 가서는 슬랙에 작성하기 시작하였다. 회의 내용을 깜빡하고 안 적을 때가 있었는데, 그럴 때마다 같은 논의를 두 번씩하고 있는 우리를 발견할 수 있었다.

=> 노션이든, 슬랙이든 일관되게 '빠짐없이' 회의 내용을 적도록 해야겠다. 

 

8. 폰트 사이즈를 통일시 하지 못한 점

처음에는 tailwind config를 통해 단위를 정하고 시작하려 하였다. 그런데, 피그마의 폰트 사이즈를 그대로 적용하여 구현을 하면 이상하게 크기가 안 맞는 것이다. 그래서 중간부터는 눈대중으로 단위를 설정하기 시작하였다. 그때는 '나중에 가서 tailwind config로 설정해야지'생각하였다. 그러나, 팀원들 중에서도 px과 rem을 혼동하고 사용하고 있던 것이다. 결국은 끝내 이를 통일시키지 못하였다.

=> 처음부터 디자인팀과, 프런트엔드 팀과 단위를 맞추자 -> tailwind를 사용한다면 tsconfig에 설정하자

 

9. 각 페이지를 담당하는 인원을 정하지 못한 점

우리 FE는 페이지가 아니라, 기능 단위로 작업 분배를 하였다. 예를 들어 A가 home 페이지의 '캘린더 기능', B가 전시회 페이지의 '전시 기능', C가 api의 오류 수정. 이런 식으로 기능 단위로 분배를 하였다. 이런 식으로 작업을 진행하니 어느 순간 곂치는 작업들이 생기는 것이다. A의 작업이 B에, B의 작업이 C에 영향을 미치고 하는 것이다. 

=> 개발을 시작하기 전, 맡을 페이지를 분배하자

 

10. 중간부터는 PM보다는 FE에 치중을 쏟은 점

처음에는 BE, 디자이너, 기획자와 소통하며 서로의 진행 상황을 공유하며 시작을 했다. FE의 작업이 점차 늘어나며 PM으로써의 역할을 하기에 버거운 상황이 와버린 것이다. 그러면서 자연스레 PM보다는 FE의 역할에 시간을 할애하기 시작했다. 그리고, FE의 역할을 하다 보니 'PM으로써 다른 작업 진행 속도에 대해 내가 간섭해도 될까'라는 점이 우려되는 것이다. 그래서 조금 조심스러워진 부분이 있었던 것 같다.

=> FE만 수행하기도 벅차다. 따로 PM을 뽑아서 PM을 보조하던가, 아예 FE만 수행하자. 병행은 쉽지 않다. 두 마리의 토끼를 모두 잡으려다 두 마리를 모두 놓치는 수가 있다.

 

11. MVP를 한 번에 완성하려 한 점

8주를 목표로 MVP를 완성하고자 했다. 그래서 중간에 QA진행 없이 8주 차까지 앞만 보며 달려왔다. 8주차 때 QA를 진행하였는데, 상당히 많은 이슈들과 수정사항들이 나와 기간이 연장되었다.

=> 프로젝트를 절반, 혹은 1달 단위로 끊어서 중간 MVP를 완성하여 QA를 진행 후 다음 단계로 넘어가자

 

💡 Learned : 프로젝트를 진행하며 배운 점은?

1. 내 의견의 명확한 주장

다르게 생각하는 부분이 있다면, 내 속에서 삭히는 것이 아니라 내 의견을 명확히 주장하고, 다른 사람과 이야기하다 보면 의문이 풀리던, 합의를 하던 더 좋은 방향으로 나아갈 수 있다는 점을 배웠다.

2. 깊이 있는 학습은 깊이 있는 코드로 이어진다.

라이브러리가 내가 알고 있는 것보다 기능이 다양하고, 깊게 공부해야 그만큼 더 깊이 있는 코드를 작성할 수 있다는 점을 배웠다. 프로젝트 작업이 끝나면 다른 것이 아니라, 지금 하고 있는 프로젝트에서 사용하는 기술 스택을 심화공부하면 배워가는 것이 더욱더 많아질 것이다. 세상엔 다양한 라이브러리가 있고, 어떠한 라이브러리가 있는지 ‘미리' 알고 있어야 사용할 수 있다고 느꼈다.

3. 사용한 기술스택에 대한 정리

프로젝트 내 코드를 이용하여 내가 사용할 기술스택에 대한 글을 직접 작성하면 머릿속에 차곡차곡 정리가 됨 + 기록으로 남음

4. 프로젝트 시작할 때 미리 정하고 가야 할 것들이 생각보다 많고, 이것의 중요성을 느낌

> 중간중간에 ‘이거 정했나, 다른 프로젝트는 어떻게 하지’ 찾아보며 미리 정하기
> 코딩 컨벤션, 폴더 구조, css 단위 나중에 절대 못 바꿈

5. CI/CD를 통해 PR 올리는 즉시 내 코드가 서버에서 오류가 발생하지 않는지 알 수 있게 됨

> 우리는 Netlify를 통해 배포를 진행했다. Github에 연결만 해두면 자동으로 CD를 해준다. Netlify 연결을 일찍하면 일찍 할수록 오류들을 일찍 잡을 수 있기에 일찍 연결하는 것이 유리하다.

 

6. 확실히 웹과 앱이 차이가 있다는 점을 느낌. 휴대폰에는 웹보다는 앱이 예쁨

> PC의 개발자 모드를 켜고 'iPhone 12'화면에 맞게 구현을 했다. 그러나, 폰으로 실제로 접속해보면 구현한 화면과 달리 실행되는 부분이 상당수 있었다. 그리고, 앱이 아니기에 '팝업 알림' 등 구현 불가능한 기능들이 많았다. 다음부터는 되도록이면 웹앱을 피하고 피치 못할 사정으로 웹앱을 구현하게 된다면 리액트의 한정된 기능에 구애받지 않도록 구현을 해야 겠다.

 

🤔 Longed for : 프로젝트를 진행하며 갈망했던 것은?

1. 기획자와 팀원들 간의 의사소통 방식

기획자 > 팀원 일방적인 방식 : 개발자들이 기획에 불만 혹은 의문을 가질 수 있음 vs 모든 기획을 기획자 + 팀원이 의논해 가며 진행 : 토의하느라 시간이 오래 걸림(사공이 많으면 배가 산으로 감)

=> 이 두 부분을 어떻게 해결해야 할 지 고민을 해보고, 다른 사람의 글도 다양하게 읽어보며 배워야 겠다.

 

2. 백엔드 api 명세서에 대한 고민

노션 ; 누구든 코멘트를 남길 수 있음 vs Swagger ; 가시성이 좋음

=> 이 둘을 취합할 수 있는 어떤 방법이 있을까 ?

 

📈 나와 팀원 개개인의 성장

원하는 만큼 기여하고 원하는 만큼 성장하세요

8주라는 긴긴 시간을 투자했는데, 과연 팀원들은 얼마나 성장했을까. 과인 이번 프로젝트에 만족했을까. 솔직한 후기를 듣고 싶었다. 그래서 개인적으로 편하게 얘기를 하면서 이번 프로젝트에서 좋았던 것, 아쉬웠던 것, 총평을 개인적으로 은근슬쩍 물어보고 다녔다. 결론은 아주아주 좋았다!

• 본인의 기술 스택을 최대한 활용
• 실제로 서비스를 만들면서 많은 고민
• 꽤나 체계적인 협업
• 본인이 모른다는 것을 알게 됨

다들 매우 만족스러웠고, 다음 프로젝트 때도 함께 하고 싶다고 말을 하는 것을 보면 내가 원하는 바는 모두 이룬 것 같다는 생각이 들었다. 그렇다면 나 개인의 성장은 어땠을까 생각해 보자.

• 팀 리딩에 대한 확신 : 항상 팀플레이를 하면 리더를 했다. 그동안 상처받는 일도 많았지만, ‘아 이럴 때는 이렇게 하는 게 좋겠구나’ 하는 노하우가 생겼었다. 그래서 사실 이번 프로젝트는 나의 가정들을 시험해 볼 수 있는 기회였고, 꽤 많은 것들이 들어맞았다.
• 협업과 의사소통 스킬 : 나도 협업이나 의사소통에 대한 경험이 많다고는 못하겠던 처지였지만, 이번에 팀을 관리하는 입장에서 많은 공부를 하고 적용했다. 덕분에 글을 쓰는 실력도 꽤 좋아졌고, 어떻게 내 의견을 상대에게 전달하는지에 대해서도 깨달았다.

그래도 나는 개발자니까, 개발자로서의 성장

• 실제로 코드를 짜보면서 어떤 부분이 더 세밀하게 공부가 필요한지 알게 되었다.
• 요즘 핫 키워드인 React Query, NextJS, Vite 등등등.. 이것저것 기술스택을 늘리는 게 중요한 게 아니었다. Javascript, React, CSS 기본기만 해도 벅차다.
• 처음으로 Typescript로 프로젝트를 진행하고, React Query의 다양한 기능을 사용해 봤는데, 많이 배웠다.

앞으로 어떤 개발자가 되어야 할지 나 스스로의 생각을 많이 하게 되었고, 개발에 대한 재미를 더더욱 느끼게 한 프로젝트였다. 각자 1인분을 해야 하는 팀이 아닌 팀원 전체가 모여서 1인분이 되는 것. 바로 '팀'이라는 것도 무엇인지 알게 되었다. 아직 서툰 실력이지만 PM을 맡게 되면서 내가 성장하기 위한 큰 경험이 되었고, 팀원들에겐 PM보다는 좋은 팀원이었다는 것이 남았으면 좋겠다는 생각도 한다. 

거칠게 달려왔던 2주였지만, 너무 재미있었고 이러한 팀을 다시 또 만날 수 있을까?
초반부터 큰 열정으로 시작했던 우리 팀 '아띠즈'

팀명을 정할 때가 엊그제 같은데 벌써 시간이 8주가 훌쩍 지나 이제 헤어지게 되었지만 잊지 못할 것 같다. 팀원 분들 덕분에 개발자라는 것에 큰 한걸음을 내딛고 방향성을 알게 되었다. 기능구현의 문제가 아니라 서로를 믿고 사소한 의견충돌이나 잡음 하나 없이 8주의 시간 동안 이 모든 것을 다 해내서 너무 대단하다고 느꼈다. 

수시로 서버 열어달라고 학, 맨날 key 값이 무엇이냐고 물어봐도 불평이 없으셨던 백엔드의 Carrick, Choo, Poo.

저 스스로의 압박감과 조급함에 옆에서 같이 분위기에 짓눌려 힘들어하셨을 프런트의 Jacob, Max.

서로서로 많이 의지가 되고 많이 가르쳐주고 희생해 주셔서 너무너무 감사하게 생각합니다.

우리 모두 훌륭한 개발자가 될 것이고 어디 가서도 잘하실 거라 믿어 의심치 않습니다.

 

✍🏻 마무리 : 서비스 소개

꽤 만족스러운 결과

우리 서비스의 링크 주소이다 https://attiess.netlify.app/

2월 20일부터 정식 배포 예정이다. 이제부터 진짜 시작이다. 다음번에는 서비스 운영하며 느낀 점들을 가지고 찾아뵙겠습니다.

 

우리 프로젝트의 Github 링크와 프런트엔드 Github 링크를 첨부하며 이 글을 마무리하겠습니다. 긴 글 읽어주셔서 감사합니다.

https://github.com/Att-ies

Att-ies

https://github.com/Att-ies/frontend

GitHub - Att-ies/frontend: 예비작가들의 예술작품을 저렴하게’ 라는 슬로건 아래 웹사이트 개발 프로

다음 글에서는, Atties 서비스를 운영한 경험들을 바탕으로 찾아뵙겠습니다.

서비스 구현 화면