[SOPT] 29기 앱잼 후기 - PM으로서의 첫 프로젝트 ✨

지난 1월 2일부터 1월 22일까지 약 3주라는 시간동안 진행된 앱잼에 대한 회고를 써보려한다.

💡 앱잼 (AppJam)은 SOPT에서 가장 크고 중요한 행사로, 3주간 진행되는 장기 해커톤이다.
     이 기간 동안 서비스의 데모버전을 만들게 된다.
     모바일 서비스와 웹 서비스 팀이 존재하고, 나는 모바일 서비스를 기획하고 제작했다.

공식 앱잼 기간은 3주지만, 기획과 디자인 파트는 브랜딩 기간 2주를 더해 총 5주를 함께한다.

말이 5주지 이 기간에는 거의 이 서비스에만 몰두하기 때문에 개인적으로 연말 연시가 어떻게 지나갔는지도 모르겠다. 크리스마스 당일에도 만나 회의를 했던 기획 디자인 친구들에게 감사를 표하며...

크리스마스에는 회의를..

 

Team SeeMeet 의 시작

기획 배경

내가 기획한 SeeMeet은 약속과 만남에 관한 서비스다.

다음 두가지 문제의식에서 출발했다.

1. 친구들과 약속 잡을 때, 시간을 맞추는 과정이 불편하다. (사람이 늘 수록 더더욱)
2. 특정 친구와 어떤 만남들이 있었는지 추억이 휘발되기 쉽다.

사람들의 관계가 더 돈독해졌으면 좋겠다는 비전을 가지고,

서비스를 통해 약속 잡는 과정을 돕고, 만남을 쉽게 기록하고 돌아볼 수 있도록 하고 싶었다.

볼 때 마다 느끼지만 컬러 진짜 예쁘다

당시에는 기획에 대해 아는 것도 별로 없고, Main PM이 하고 싶다는 생각이 강해서 잘 몰랐는데, 지금 돌아보면 많이 부끄러운? 기획이다.

문제가 진짜 문제인지, 사람들이 해결하고 싶은 문제인지,
문제라면 기존에 어떤 수단으로 해결하고 있는지,
내가 생각한 솔루션이 먹힐 것인지,

진짜 PM으로서 해야하는 기획에 대한 고민이 부족했다고 생각한다.

분석이 아닌 감으로, 직관으로 기획했던 것 같은 아쉬움이 너무 많이 남는다.

그래도 3개월 동안 성장해서 이렇게 회고 할 수 있다는 것에 위안을 삼아야...지..

 

팀 빌딩 - 팀원을 모아보자

앱잼을 함께할 팀원을 모을 시간이다.

SeeMeet은 모바일 앱 서비스였기 때문에 기획자, 디자이너, iOS, 안드로이드, 서버 개발자를 뽑아야? 했다.

다른 파트 사람들은 팀빌딩 전에 각자 관심 있는 팀의 PM에게 미리 연락해서, 포트폴리오 같이 자신을 어필할 수 있는 자료를 보내곤 한다. (물론 다 그런 것은 아님!)

나름의 HR 업무라고도 할 수 있다.

팀빌딩을 하면서 기업의 입장을 조금은 알 수 있었다.

우리 팀에 왜 관심을 가졌을까?
어떤 걸 하고 싶을까?
우리 팀에서 어떤 퍼포먼스를 낼 수 있을까?
우리 팀의 분위기와 잘 맞을까?
다른 팀원들(이미 합류한 팀원들) 과 핏이 잘 맞을까?

생각해야할 부분이 정말 많았다.

PM으로서 팀의 결과물도 생각해야하고, 일하는 분위기도 생각해야하고,

팀을 책임져야 한다는 생각이 강하다보니 판단에 대한 부담감이 굉장히 컸다.

어쨌든... 감사하게도 좋은 팀원들과 좋은 팀 분위기를 만들어낼 수 있었다.

귀여운 씨밋 친구들 & 선인장!!

 

아쉬운 점을 정리해보자

솔직히 말하면, 이번 앱잼은 그냥 엉망이었다.

팀원들은 너무 좋았고, 3주라는 시간동안 다같이 고생하고 즐거운 시간을 보내면서 거의 가족같은 사람들이 되었다.

하지만 개인적으로 PM으로서의 역할을 잘 했는가를 돌아볼 때면 날카로운 것으로 찌르는 것같다.

솝트 하기 전부터 앱잼 만을 바라봤고, PM으로의 활동만을 기대했던 터라 그런지 실망감과 자괴감이 너무 컸다.

 

역할 분배의 아쉬움

역할 및 리소스 분배는 PM에게 있어서 중요한 역량 중 하나이다.

하지만 이번 앱잼에서 기획자끼리의 역할 분배가 아쉬웠다.

일단 나부터가 기획자로서의 역할 이해가 부족했기 때문에 팀원들에게 분배를 제대로 하지 못했다.

 

명령인가 역할 분배인가?

명령과 역할분배의 차이를 인지하지 못한 것도 원인이었다.

역할을 나누고 협업하는 것은 명령이 아닌데, 그 차이를 인식하지 못해서 그냥 내가 다 하려고 했던 것이다.

그러다보니 팀원들은 자신이 무얼 하고 있는지 모르고, 의욕이 저하되게 된다는 문제가 발생한다.

나는 또 내심 팀원들이 능동적으로 자신이 할 것을 찾기를 바랬지만 리더로서, PM으로서 정말 못난 생각이었다.

능동적으로 해줬으면 한다는 것을 제대로 얘기라도 하든가...

결국 소통의 부재가 가장 큰 문제였다고 생각한다.

팀원들은 답답해하고, 나는 혼자 하려고 하다보니 어느 순간부터 지치고 팀의 결과에 악영향을 미쳤다.

돌아보니 참 아쉬운 부분이다.

 

사실은 제대로된 협업을 해보지 않았다?!

앱잼이 끝나고 찬찬히 돌아보니, 나는 지금까지 협업을 경험하지 않았다.

엥? 분명 학교 다니면서 팀플이고 프로젝트고 졸업 논문이고 이것저것 많이 했는데?

정확히는 리더로서의 협업을 경험하지 못했다.

지금까지 내가 경험했던 협업이라 함은, 팀원으로 속해 내가 맡은 부분만을 열심히 했거나, 혹은 허울뿐인 팀플이라 사실상 내가 모두 했던, 내가 하는게 편했던 경험 뿐이었다.

그러다보니 앱잼에서 모든 부분을 내가 해야된다고 여긴 것이다.

리더로서 필요한게 그 역할을 분배하고 조율하는 능력인데, 처음 겪는 일이다보니 그 부분이 많이 부족했다.

이전의 소규모 팀플의 경우는 이런 마인드를 가지고 나 혼자서도 커버가 가능했다.

하지만 팀원이 15명이나 되는 앱잼 정도의 대규모 프로젝트에서는 결국 문제가 발생한 것이다.

앱잼에서 가장 아쉬운 부분이 바로 이 리소스 분배 이다.

 

워터폴 방식?

현재 솝트 앱잼은 워터폴 방식으로 돌아간다.

프로젝트 방법론 - 애자일 vs 워터폴

앱잼 이전에 기획 경선이 있는데, Main PM으로서 팀원들을 이끌고 자신의 아이디어를 구현하고 싶은 사람들이 각자의 기획을 발표하고, 나머지 앱잼 참여자들이 투표하게 된다.

경선에서 뽑힌 Main PM의 아이디어는 기획자 & 디자이너 팀빌딩과 브랜딩 기간을 거쳐 디자인 결과물이 만들어진다.

그 후 개발자까지 팀에 합류하여 해당 아이디어를 구현한다.

프로세스가 단계별로 나눠져있고, 단계별 역할과 기한이 명확하고, 메이커들의 의견이 기획에 반영되기 어려운, 워터폴 방식이라고 볼 수 있다.

 

워터폴이냐 애자일이냐 뭐가 맞냐를 따지는 것은 무의미하다.

상황에 따라 환경에 따라 팀에 맞는 방법론을 채택해서 좋은 결과를 내면 될 일이다.

다만 이러한 배경지식을 조금 일찍 인지했다면 어땠을까 하는 아쉬움이 남는다.

워터폴의 장점은 단계별 구분이 명확하여 진행상황을 파악하기 용이하고 프로젝트의 기술적 리스크를 줄인다는 것이다.

워터폴 방식에서 유의할 것은, Plan-Based Methodology기 때문에 계획한 일정 중간에 프로젝트 변경사항이 생기지 않는다 (웬만하면!).

요구사항 수정보다는 계획이 중요하다는 관점이다. 일단 기획된 대로 가는거다.

 

우리 팀의 아이디어는 브랜딩 기간에 기획의 방향이 많이 바뀌었다.

기존의 아이디어로는 브랜딩의 방향을 명확히 정하기가 어려울 것 같다는 의견이 있었고, 나 또한 동의했다.

그렇게 해서 가치관이나 큰 틀에서의 아이디어만 동일하다 뿐이지 아예 새로운 제품이라고 봐도 무방할 정도로 변경되었다.

물론 그 판단으로 기획과 디자인이 명확해졌다는 장점은 있었다. 하지만 이로 인해 뒤에 있을 모든 일정이 꼬였다.

결과론적인 얘기지만, 앱잼을 돌아봤을 때 개인적으로 가장 아쉬운 판단이었다.

이로 인해 개발자 네트워킹, 개발자 온보딩, 기획 문서 작성 등 모든 일들이 밀리고, UI 디자인이 늦게 나오고, 개발도 늦게 들어갔기 때문에 많은 팀원 들이 고생했다 ㅠㅠ 미안..

 

팀원들의 의견을 수용해야 하는게 맞지만, 어느정도를 수용할 것인지는 전적으로 PM의 판단에 달려있고 PM의 책임이라고 생각한다.

앱잼의 목표에는 프로덕트의 성공도 있지만 팀원들의 성장, 즐거운 프로젝트 경험과 추억도 있었다.

앱 서비스가 하나의 프로덕트지만 나에겐 앱잼 자체가 하나의 프로덕트라고도 볼 수 있었다. (기업이 아니니까)

그런 측면에서 판단을 내릴 때 목표와 기준이 명확하지 않았다는 아쉬움이 많이 남는다.

앞으로 PM으로서 커리어를 쌓아가다보면 정말 많은 의사결정의 순간이 있을 텐데, 나 한 사람의 판단이 얼마나 중요한지 몸소 체험하는 경험이었다.

이래서 원칙과 우선순위가 중요하다는 거구나...

 

커뮤니케이션은 어려워

앱잼 기간 동안 기획, 디자인, 개발 할 것 없이 여기저기 논의사항이 튀어나왔다.

정책 상에 구멍이 너무 많았는데, 특히 캘린더, 시간 선택 이라는 것이 따져봐야할게 너무 많았다.

캘린더에서 오늘 날짜를 선택했을 때는 어떤 색으로 마킹할지, 시간을 선택하는 피처의 디폴트 시간은 뭘로 설정할 것인지, 타임 피커의 간격은 몇분으로 할 것인지, 24시간과 오전/오후 표기 법 중 뭐가 좋을지, 유저가 종료 시간을 시작 시간보다 앞서게 설정하면 어떻게 처리할지 등등 여기저기에서 판단이 필요했다.

그럴 때마다 담당 메이커들과 함께 논의를 진행했는데, 결정이 나지 않은 문제에 대해 각자 생각해보고 다음에 다시 논의하자 식으로 넘겨버린게 나중에 문제가 되는 경우가 있었다.

논의 사항이 한두개면 커버가 되지만, 앱잼에서와 같이 논의할 게 많아지다 보니 어떤게 있었고 어디까지 논의했는지 관리가 잘 안됐다.

후에는 논의 사항에 대한 보드를 따로 만들어서 왜 생겼고, 어떻게 진행되고 있고, 결론이 뭔지 정리해뒀다.

보드를 만든 후에는 나름 원활하게 처리가 됐지만, 그 이전의 것들에 대해 고생한 부분이 좀 아쉬웠다.

 

또 다른 문제로 UI / 와이어프레임에 관련된 커뮤니케이션도 아쉬웠다.

우리 팀은 디자인 협업 툴로 피그마를 사용했다.

처음에는 크게 와이어프레임 페이지와 UI View 페이지를 만들어서 개발자들에게 전달했고 기능 명세는 노션에 작성했다.

이렇게 일하다 보니 와이어프레임에 수정사항이 생겼을 때 정확히 어떤 부분이 바뀌었는지 한 눈에 확인하기 어려웠고 개발자들에게 명확히 전달이 안되다보니 구현해야할 방향에 대해 얼라인이 제대로 안됐다.

그래서 와이어프레임 페이지를 하나 더 만들고 회의용과 현재 확정 버전으로 구분해서 사용했다.

나름 문제가 해결됐지만 완전하진 않았다.

지금 돌아보면 깃 버전관리 하듯 피그마에서도 페이지를 버전 별로 생성해서 관리했으면 더 좋았을 것 같다는 생각이 든다.

버전 관리하고 버전별 수정사항을 슬랙으로 공지했다면 개발자들과 더 명확하게 소통했을 것 같다.

피그마 같은 클라우드 타입의 협업툴은 장점이 많지만, 잘 관리 하지 못하면 엉망이 된다는 것을 느꼈다.

 

이런 건 좋았다

회고에 관하여

격일로 작업 브리핑과 KPT 회고를 진행했다.

진지한 회고보단 약간 노는 분위기가 된 감이 없지 않지만 ㅋㅋㅋ 팀 분위기에는 긍정적 영향이 있었다는 장점이 있었다.

그래도 현재 각 파트 별로 어떤 작업이 진행 중인지, 계획이 어떻게 되는지, 문제는 없는지 공유할 수 있었다.

 

개발에 대한 지식

음...사실 엄청 큰 도움이 되었는지는 잘 모르겠다.

진로를 바꾸면서 내심 내 전공이 아깝기도? 하고 어떻게든 도움이 되었으면 하는 마음이 강해서 그런가,

나도 모르게 기대를 하면서 합리화를 했던게 있던 것 같다.

개발 지식이 없는 것 보단 낫겠지만, PM은 PM으로서의 역량이 더 중요하다.

그렇지만 개발에 대해 알고 있었던 덕에 개발자들의 대화에 낄 수 있었고, 개발 방향이나 우선순위를 정할 때 개발자들과 소통이 원활했던 것은 있다.

 

이런 걸 배웠다

문서는 간결하게

슬프지만 냉정하게, 나 외의 다른 사람들은 문서를 잘 안본다 (기능명세 등)

누군가를 원망하고 서운해할 문제가 아니다. 입장 바꿔놔도, 나같아도 잘 안 볼듯 ㅋㅋ

그러니 쓰지 말자, 어짜피 안보니까 대충 쓰자는게 아니고,

슥 봐도 이해되도록, 머리에 남도록 최대한 간결하게, 명확하게, 핵심 위주로 쓰도록 하자.

 

기획에 있어서 CRUD 의 중요성

개발자라면 잘 알고 있을 CRUD, 기획에도 써먹기 좋다.

CRUD란, Create, Read, Update, Delete를 말하는데, 소프트웨어가 가져야할 기본적인 정보처리 기능을 나타낸다.

이 CRUD를 서비스 기획할 때 적용하면 보다 체계적으로 기능을 설계할 수 있고 빠뜨리는 부분을 줄일 수 있다.

예를 들어 캘린더에 일정을 보여주는 기능이 있다고 하면, 유저는 일정을 생성할 수 있어야하고 (Create), 존재하는 일정 정보를 볼 수 있어야하고 (Read), 생성된 일정을 수정할 수 있어야하고 (Update), 일정을 삭제할 수 있어야한다 (Delete).

물론 서비스 특성 상 특정 기능을 제공하지 않을 수는 있지만 기본은 이렇다.

일정 같이 명확한 오브젝트 외에도, 어떤 값을 선택하는 기능이 있다고 하면 선택하기(Create), 선택 값 확인하기 (Read), 선택 해제하기 (Update), 아예 뒤로 가기 (Delete) 식으로 적용하면 정책 설계할 때 도움이 된다.

기획을 처음할 때는 CRUD를 생각하지 않고 주먹구구 식으로 정책을 설계했고, 구멍이 많이 생겨 후에 메이커들에게 질문을 많이 받았다.

다음 번에 기획할 때는 꼭 CRUD를 적용해서 체계적으로 정책을 설계해봐야겠다.

 

기획은 설득의 연속이다

새로운 기능을 추가하거나 혹은 기존 기능에 수정사항이 생길 경우,

개발자들에게 단순 사실을 전달하는게 아니라 그 사항을 설득해야한다.

개발자들은 용병이 아니고 같이 일하는 팀원이다.

이 기능이 왜 필요하고, 그 근거는 어떻게 되고, 그렇기 때문에 이렇게 개발할 것을 제안한다 라고 얘기해야한다.

 

---

 

 

기획 경선 준비하던 12월 초부터 데모데이 1월 22일까지, 8주 동안은 시간이 어떻게 지나갔는지 모르겠다.

살면서 가장 연말연시를 느끼지 못했던 해였다.

몸도 힘들었지만, 여러가지 정신적 부담감이 더 힘들었다.

책임감, 판단에 대한 피로, 자괴감 등 도트 데미지 마냥 지속적으로 딜이 들어온 느낌..

하지만 회고를 쓰며 돌아보니 정말 짧은 시간에 응축해서 많은 것을 몸소 배웠다고 생각한다.

대학생의 신분으로 어디가서도 해보지 못할 좋은 경험을 할 수 있었음에 가장 감사했다.

나의 미성숙함을 견뎌준 팀원들에게 감사하며,,, 릴리즈까지 다시 달려봐야지 :)

팀 씨밋 체고