[비사이드] 409기 포텐데이 참여 회고

안하려고 했는데, 또 했네

포텐데이 312기 수상작 발표날

나는 이전에 312기 포텐데이에 참여했던 경험이 있다. 당시에 '오때(Otte)'를 만들고 네이버 클라우드 수상까지 하면서 느낀 점이 많았었는데 회고를 쓰지 못했던 게 너무 아쉽다. 그 때도 좋은 팀원들과 함께 기획하며 짧은 시간 내 몰입해서 완성했기에 뜻 깊은 경험이었다. 좋았던 경험이었음에도 불구하고 10일이라는 짧았던 기간 탓에 사실 포텐데이에 또 참여하고 싶지 않았다. 단기가 아닌 장기적인 사이드 프로젝트를 하고 진행하고 싶었다. 10일 동안 간단한 MVP구현은 할 수 있었지만 코드 퀄리티가 매우 떨어졌었기 때문이다. 실제로 많은 팀들이 기한 내에 서비스 배포를 하지 못한 경우도 다수 존재한다. 나는 우리가 구성한 기능만큼은 완성하고 싶었고, (당시에는 이게 내 실력의 척도라고 생각했다) 함께 만든 결과물을 팀원들도 사용할 수 있도록 하고 싶었다. 또, 기한에 맞춰 제출해야 포텐데이의 모든 참가자들이 사용해볼 것이므로 완성에 더욱 초점을 맞췄다. 최종적으로 좋은 결과를 얻었으나 코드에 대해 신경쓰지 못했던 점이 마음 한 구석에 죄책감같이 남았었다. 최대한 리팩토링을 진행했으나 당시 회사에서 새로운 프로젝트에 투입되며 바쁜 나날들을 보내오다 추후에 리팩토링 하려니 더 힘들었다..

 

그래서 최소 2개월 이상 프로젝트를 진행하며 실제 서비스도 배포해보고 사용자도 만들고 싶었다. 특히, 나는 혼자 프론트 업무를 하는 것에 익숙했기 때문에 다른 프론트엔드와 협업을 진행하고 싶었다. 열심히 사이드 프로젝트 동아리들을 찾아봤지만 대부분 참가 신청을 받지 않는 기간이었다. 인프런에서는 프론트엔드보다 디자이너를 구하는 경우가 많았고, 겨우 한 군데 구해서 첫 기획 회의를 진행했으나 이후 한두사람씩 빠지더니 팀이 폭발해버렸다. 사이드 프로젝트 사이트에 올라온 프로젝트는 스터디라는 명목 하에 열정 페이를 강요하는 스타트업들이 많았다.

 

돌고 돌아 약 9개월 만에 두 번째 포텐데이 참여다. 직장인으로 참여했던 이전과는 다르게 취준생 신분으로 참여했기 때문에 여유롭게 작업할 수 있을 것이라 생각했다. 공식적인 시작일은 9월 27일부터였으나 채널이 만들어진 것은 9월 23일이다. 이 때부터 자기소개를 올리기 시작한다. 서로 마음에 드는 사람이 있다면 DM을 통해 컨택해서 미리 팀 빌딩을 진행할 수 있다. 하루라도 빠르게 팀 빌딩이 된다면 다른 팀에 비해 기획을 먼저 시작할 수 있으므로 훨씬 유리하다. 오때를 진행했을 때와 마찬가지로 기획자에게서 먼저 컨택이 왔다. 서로의 소개글을 읽고 핏이 맞는지 확인하는 절차를 거쳐 첫 번째로 팀에 합류하게 됐다.

 

 

'함께' 프로젝트를 만드는 과정

• 팀 빌딩 완료 및 아이디어 회의

기획자 2명, 디자이너 1명, 프론트엔드 1명, 백엔드 1명 이렇게 총 5명이서 하나의 프로젝트를 완성하기로 했다. 이번에 개발자 참여가 부족해 같은 직군과의 협업을 진행하지 못했다는 점이 아쉬웠다. 하지만 또 다르게 생각해 보면 짧은 시간 안에 서로 컨벤션을 맞추는 부분이  힘들었을 수도 있겠다 생각하며 넘어갔다.

 

'그돈이면' 서비스 소개

팀빌딩 완료 후, 바로 그날 밤 온라인으로 아이디어 회의를 진행했으나 시간만 흐를 뿐 적당한 아이디어가 없었다. 평소 만들어보고 싶은 아이디어를 하나씩 말했지만 서로의 목표와 방향성에 따라 원하는 서비스가 달랐던 점, 짧은 시간 내에 완성해야 하는 서비스를 만들어야 한다는 점 등 여러 의견들이 오가며 쉽게 맞춰지지 않았다. 결국 시간이 늦어져 다들 생각해본 후 다음 날 밤 다시 온라인 회의를 진행하기로 했다. 다행히 다음 날은 많은 아이디어들이 나왔다. 불가능한 것들은 걸러내고 투표를 통해 최종적으로 탄생한 서비스가 바로 '그돈이면'이다.

아이디어가 나오니 이에 맞춰 각자 기능들을 덧붙이며 순조롭게 진행되었다.

 

• 일정 관리

협업을 위해 노션을 사용했다. 이곳에서 프로젝트와 관련된 링크들과 정보를 공유하고 회의록을 작성했다. 특히, 짧은 기간 내에 완성해서 제출해야 하는 프로젝트인만큼 일정 관리가 가장 중요하다고 생각한다. 팀원들끼리도 서로 어떤 작업을 진행중인지 알아야 하고, 진행 상황에 따라 본인이 할 수 있는 작업이 정해지므로 변경된다면 바꿔주고 바로 알려주는 것이 좋다. 일정은 각자 역할에 맞춰 본인이 가능한 기간을 산정 후에 캘린더에 작성했다.

 

나는 기획된 문서나 피그마의 와이어프레임을 보며 가장 먼저 서비스 기획을 이해하는 것이 중요하다고 생각했다. 그래서 궁금한 점이 있으면 기획자에게 바로 물어보고, 또 어떻게 하는 것이 더 좋을지에 대한 피드백을 주고 받기도 했다. 디자인이 나오기 전까지 프론트엔드 개발자는 조금 여유롭기 때문에 개발 환경을 세팅하며 동시에 와이어 프레임이 작성되고 있는 피그마를 자주 확인했다. 개발 환경 세팅 후에는 바로 배포를 진행했다. 내가 하는 작업을 팀원들도 함께 확인할 수 있으면 더 좋을 것 같다고 생각했다. 또, 마지막에 배포를 했을 때 예상치 못한 이슈가 발생해 프로젝트를 제출하지 못할 수도 있으므로 미리 해두는 것이 좋을 것이라 생각했다. 배포는 간단히 vercel을 사용했지만 정책이 바뀐 탓에 애 좀 먹었다. 이와 관련된 글도 작성했다.

 

• 진행 상황 공유

퍼블리싱 작업이 들어가면서 디자이너와는 DM을 통해 종종 소통했다. 하지만 타 직군은 내가 어떤 작업을 하고 있는지 알지 못할테니 단체 채널에서 대화해야 하는지, 아니면 중간에 자주 상황을 공유하는 것으로 그쳐도 될 지 모르겠다. 아직 이런 부분이 미숙하다. 이전 회사에서는 모든 직원들이 서로 DM으로 소통하는 경우가 많았었는데 이 때문에 서로 다르게 이해하고 있는 경우도 발생했었다. 하지만 또, 디자이너의 아주 사소한 실수들(예를 들면 1px 차이나 미세한 컬러 차이 같은)을 공식적으로 알리는 것 같다는 생각에 DM을 통해 물어보는 것도 나쁘지 않다고 생각한다. 늘 좋은 소통이 어떤 것인지 고민해야겠다고 느꼈다.

 

• 오프라인 모임 및 QA진행

사당역 스터디룸

우리의 목표는 원픽(1pick)🥇이었기 때문에 완벽한 서비스를 만들고자 마감 하루 전 날인 토요일에 서비스를 최종적으로 완성하기로 결정했다. 그래서 그 날 함께 오프라인으로 모여 QA를 진행했다. 또, 함께 저녁을 먹으며 서로에 대해 더 알아가는 시간을 가졌고 프로젝트가 끝나갈 즈음이지만 덕분에 친밀도는 더욱 높아졌다. 그리고 모여서 진행하니 피드백을 빠르게 주고 받을 수 있어 작업을 평소보다 더 빠르게 진행할 수 있었다.

사당에서 21시쯤 헤어졌지만 나는 집이 멀기도 하고, 이 날 여의도 불꽃 축제 이슈로 지하철이 많이 연착됐다.. QA를 진행하며 발견한 이슈 중 고치지 못한 부분이 있어 늦은 시간에 도착해서 새벽까지 모두 수정 후에 마음 편히 잠들었다.

 

• 최종 서비스 제출. 결과는?

다음 날인 일요일 오후 3시에 제출이 마감되었고, 화요일에 발표가 났는데 아쉽게도 1등은 달성하지 못했다. 그래도 13팀 중에 2등이나 했으니 이것만으로도 만족했다. 게다가 우리 서비스에 달린 코멘트 중에 완성도가 높다는 평이 있어서 열심히 QA를 진행한 보람이 있었다. 또, 실생활에 사용할 수 있을 것 같다는 평들로 보아 수요가 있을 수도 있겠다는 생각이 들었다. 이렇게 투표한 팀에게 코멘트를 남겨 피드백을 받을 수 있는 부분은 좋았다.

 

향후 팀원들과 함께 서비스 고도화 작업을 진행할지에 대해 논의해보려 한다.

 

 

좋았던 점

• 몰입 최고

포텐데이에 참여하면서 가장 좋았던 점은 짧은 시간 내에 완성해야 하니 그 만큼 몰입도가 높다는 점이었다. 몰입하게 된다는 것은, 프로젝트에 대한 책임감을 가지고 있기 때문이다. 따라서 몰입과 동시에 책임감을 기르는 연습을 하고 있다는 생각이 들었다. 나는 제 역할을 해내고 팀원들에게 피해를 끼치지 않기 위해서는 포기가 아닌 몰입을 선택하는 편이다. 물론 완성하지 못한다 해도 이것이 책임을 다하지 못했다는 것은 아니다. 그건 어쩌면 본인의 역량보다 무리해서 기능을 구현하려 했기 때문일 수 있다. 따라서, 주니어라면 본인이 처음 MVP 때부터 가능한 부분과 불가능한 부분을 미리 팀원들과 공유하고 의견을 나누는 것이 좋다.

 

• 새로운 도전

지난 오때 서비스를 만들 당시에 NextJS를 처음 사용해봤다. 짧은 시간 내에 새로운 기술스택을 사용해 프로젝트를 완성한다는 것은 나에겐 큰 도전이었고 모험이었다. 왜냐하면 내가 완성해내지 못하면 팀원들에게 큰 피해를 끼친다고 생각했고 이 부분이 조금 두려웠다. 지금 생각하면 잘못된 생각이었던 것 같지만 당시에는 그랬다. 하지만 덕분에 빠르게 문서를 정독했고, 계속 되는 hydration오류를 맞닥뜨려도 열심히 구글링을 통해 해결하고 다음으로 넘어갔다.(이 때도 마주친 오류들을 적어뒀으면 좋았을텐데 말이다.) 어찌됐든 프로젝트는 완성했고, 좋은 결과도 얻었다.

이번 프로젝트에서는 퇴사 후 진행한 NextJS스터디로 기술 스택은 어느 정도 익숙해진 상태였으나, 카카오톡 공유 서비스와 이미지 다운로드 기능이 문제였다. 전부 처음 해보는 것들이었다. MVP가 작성되면서 빠르게 구글링을 통해 두 가지 기능을 검색했다. 카카오톡 공유 서비스는 카카오 API를 사용해서 적용하면 됐고, 이미지 다운로드는 HTML 자체를 다운로드하는 라이브러리가 있던 덕분에 둘 다 구현이 가능할 것 같았다. 하지만 만약을 위해 초기 기획 회의에서 팀원 분들에게 처음 해본 기능들이라는 것을 미리 공유드렸다. 그리고 머릿속으로 대충 계획을 구상했다. 퍼블리싱을 빠르게 작업하고 최대한 처음 해보는 기능을 구현하는 데 시간을 쏟기로 했다. 다행히 프로젝트에 제때 적용할 수 있었다.

나는 이렇게 불가능할 것만 같은 것들도 해내면서 계속 성장하고 있다는 느낌을 받았다. 내 연차에 비해 늘 실력이 모자르다고 생각하지만 결국에는 해낸다. 만약 실패한다 했더라도 그것을 통해 배운 점이 있다면 그것으로 충분하다고 생각한다.

 

• 미니 애자일 프로세스

전혀 알지 못하는 사람들과 처음 만나자마자 프로젝트를 진행해야 했기에 굉장히 빠른 템포로 진행이 된다. 아이디어 회의에서부터 빠르게 진행하는데 어쩔 수 없이 이것저것 막 던지게 된다. 근데 이게 또 생각보다 재미있다. 나는 보통 한국인들이 남 눈치를 보느라(특히 저요..) 브레인 스토밍이 잘 안된다고 생각하는 편이다. 하지마 빠르게 진행해야 되는 상황에서는 이것 저것 던지면서 뭐라도 해야할 것 같은 생각이 든다. 그렇게 많은 아이디어가 모이고, 10일이라는 시간 내에 가능한 것과 불가능한 것을 나눈다. 가능성은 대부분 개발에 초점이 맞춰져 있다. 초기 기획 단계에서부터 개발자가 참여하여 어떤 정책이 필요한지, 이런 기능을  구현할 때 고려사항은 무엇인지 등 회의를 통해 의견을 나누고, 이를 바탕으로 기획서가 작성된다. 짧은 시간에 만들어진 기획이기에 당연히 실수가 있을 수 있다. 따라서 개발 중에도 기획이 변경 되면 이를 빠르게 반영할 수 있어야 한다.

또, 포텐데이에는 매일 본인이 무엇을 했는지 작성해야 하는 체크인 시스템이 있다. 이런 점이 마치 스프린트 회고와 비슷하다고 생각했다.

 

• 칭찬과 응원, 그리고 피드백

나는 칭찬을 받으면 더 잘하려고 노력하는 편이다. 포텐데이에서는 프로젝트 기간 동안 매일 익명으로 하루에 한 번씩 팀원 중에 한 명에게 박수와 함께 멘트를 남기는 시스템이 있다. 팀원에게 박수를 보낼지 말지, 멘트를 남길지 말지는 본인이 자유롭게 선택할 수 있다. 박수와 멘트를 받으면 더 힘이 나고 열심히 해야겠다는 생각이 든다. 나도 매일 팀원에게 박수와 멘트를 남겼는데, 아마 받았던 팀원도 보면서 더 힘이 나지 않았을까? 익명이기 때문에 자유롭게 피드백을 주고 싶은 경우에도 좋을 것이라 생각한다.

프로젝트 끝난 후에도 서로에게 피드백을 주고 받기도 한다. 팀원 중 한 분은 프로젝트가 끝난 후 피드백을 받기 위해 구글 폼을 만들어서 공유했는데 좋은 아이디어였다. 누구나 실수할 수 있지만 그 실수를 두 번 반복하지 않기 위해서는 아는 것부터가 중요한데, 이를 위해서는 타인의 도움이 필요하기 때문이다.

 

 

아쉬웠던 점

• 짧은 기간

기간이 짧아 몰입도가 높다는 장점이 있는 반면에, 초반에 말했듯이 완성에만 급급해 내 코드가 어떻게 보일지 신경쓸 수가 없다. 주어진 10일이라는 기간은 오직 개발에만 소요할 수 있는 기간이 아니다. 기획과 디자인 그리고 개발, 배포 모든 것을 포함하여 10일이다. 팀이 미리 결성된다면 3~4일 정도는 늘어나겠지만 이것도 짧다고 생각한다. 또, 프로젝트가 끝나고 나면 나 뿐만 아니라 모든 팀원들이 늘어지게 된다. 의견을 조율하여 고도화 과정을 거칠 수도 있겠지만 이마저도 제대로 진행되지 않을 확률이 높다. 더 이상 정해진 기간이 없기 때문이다. 포텐데이 내에서 자체적으로 고도화 과정을 필수적으로 넣어 진짜 1등을 뽑는 것도 좋은 방안이 될 수도 있을거라 생각한다.

 

 

그래서 추천? 비추천?

나는 운이 좋게 늘 좋은 팀원들을 만났다. 그리고 그들과 하나의 목표를 가지고 함께 해서 재미있고 좋은 경험이었다. 한 번쯤 경험해보는 것을 추천한다. 다만, 내가 회사를 다니면서 참여했을 당시에는 칼퇴하고 집 도착해서 새벽까지 작업하고, 다시 아침 일찍 일어나서 출근하는 등 피로가 많이 쌓였다. 게다가 장거리 출퇴근자여서 더 힘들었다. 따라서 나처럼 회사와 집까지의 거리가 멀다면 비추천한다.

 

추천해요👍

• 취업준비생 (best)
• 직장인이지만 야근이 거의 없고, 집과 회사와의 거리가 멀지 않다.
• 빠르게 만드는 것에 자신 있다.
• 사이드 프로젝트 하고 싶은데 팀원이 잘 구해지지 않는다.
• 만들어 보고 싶은 재미있고 간단한 아이디어가 있다.
• 네이버 클라우드 플랫폼 사용해보고 싶다. (100만원 상당 크레딧 지원)

 

비추천해요👎

• 야근이 많다
• 집과 회사와의 거리가 멀다.
• 빠른 속도보다 코드 퀄리티가 중요하다.
• 완성하지 못할 것 같아 중도에 포기해버린다.