[프로젝트 진행하기 #1] 프로젝트 시작 준비

 프로젝트 진행과정 1탄이다. 이번 포스팅에서는 본격적으로 서비스 기획 및 개발에 들어가기전에 프로젝트 시작 준비를 하는 과정에 대해서 간단히 다뤄보고자 한다. 초반 단계라서 내용은 별로 없지만, 나는 이 1단계가 잘못되면 결국 뒤에선 다 꼬인다고 생각한다. 따라서, 가볍게 생각하지말고 초반에는 좀 빡세게 준비하는 편이 좋다.

 

또한, 0번 글에서도 언급했다 싶이, 백엔드 개발자 + 팀장의 관점에서 작성한 글이다.

 

📝  초기 팀원 모집하기

일단 혼자하는 토이 프로젝트가 아닌 이상, 처음부터 혼자 시작하기에는 무리가 있다. 그래서 주변 지인 중에 아는 사람을 설득해서 진짜 아이디어를 같이 구상하고, 끝까지 갈 팀원을 골라야 한다. 그런데 여기서 중요한 점이 있다. 단지 나랑 친하다고 아무나 데려와서는 절대 안된다. 나는 초기 팀원은 아래 조건을 만족하면 좋다고 생각한다.

 

1. 나랑 마음이 잘 맞거나, 다른 프로젝트에서 합을 잘 맞추었던 사람

2. 어느정도 개발 경험이 있거나 능력이 있는 사람 (적어도 1인분은 할 수 있을 정도)

3. 프로젝트를 진행할 어느정도 여유가 되는 사람

4. 나와 기술스택이 유사한 사람

5. 개발에 대한 열정이 있는 사람

 

일단, 다른건 몰라도 2번과 3번과 5번은 반드시 만족해야된다고 생각한다.

 

1번같은 경우는, 당연히 다른 프로젝트에서 합을 잘 맞추었던 사람이면 어느정도 능력도 보장되있을 것이고, 어떻게 해야 소통이 잘 될지 빠르게 파악할 수 있을 것이다. 그러면, 합을 맞춰지는데 걸리는 시간 및 감정소모가 매우 줄어들 것이다.

 

2번같은 경우는, 개발 경험이 전혀 없어서 내가 사용할 기술스택의 언어 조차도 다룰줄 모르는 사람을 데려오면 진짜 망한다. 뿐만 아니라, 어느정도 CS 지식이 바탕이 반드시 되있어야 한다. 왜냐하면, 개발을 아예 처음해보는 사람들은 개발이 흘러가는 Flow를 따라오는데 굉장히 오래걸리기 때문이다. 또한, 언어 조차도 못다루면 엄청난 Learning Curve가 발생한다. 짧은 시간 내에 완성해야되는 학생들의 사이드 프로젝트 특성상, 이런 인원이 팀원으로 있다면 엄청나게 개발이 지연될 것이다. (Spring을 하던 사람이 Express로 처음 개발해본다 이런건 괜찮다. 백엔드 작동 흐름을 어느정도 알기 때문에 모르는 언어라도 충분히 빠르게 적응하고 따라온다. 내가 말하는건 진짜 Java의 기초도 못하는 사람이 Spring을 한다 이런 느낌이다. 어찌보면 당연한 것...)

 

CS지식을 어느정도 알고 있는 팀원도 굉장히 중요하다. 예시를 몇가지 들어보겠다.

 

1. 글을 클릭하면 조회수가 증가하는 기능을 구현했다. 하지만, 동시성을 고려하지 않아 Race Condition이 발생하여 기댓값에 한참 못미치는 조회수가 증가했다. 만약, 내가 운영체제를 몰랐다면 이 문제가 왜 발생하는지 원인을 못찾고 시간을 낭비할 것이다. 뿐만 아니라, 개발자들끼리 소통할 때도 "이렇게 구현하시면 Race Condition이 발생할 것 같에요. 트렌젝션 격리 수준을 엄격하게 관리하던가 아니면 Lock을 걸어보는 방법도 좋을 것 같네요!" 이런식으로 "Race Condtion", "Lock" 등 단어로 소통하는 경우가 많다. 만약, 내가 이 개념을 모른다면 대화의 흐름에 끼지 못할 것이다.

2. 회원가입 기능을 개발했다. User의 ID와 Password를 이제 DB에 저장해야되는데 암호화 하지 않고 절대 그대로 저장해서는 안된다. 일반적으로 Salt 문자열 + 비밀번호를 SHA256같은 Hash 함수를 돌려 암호화하여 저장한다. 만약, 내가 정보보안에 대한 CS적 지식이 없다면 이해하지 못할 것이다.

3. 서비스 아키텍처를 구상하고, React와 Spring을 Docker로 띄우고, 그 둘 사이에 Nginx로 Reverse Proxy 서버를 구축했다. 만약, 리버스 프록시 서버라는 개념을 알지 못하면, Nginx가 왜 필요한지 이해하지 못할 것이다.

 

이렇듯, CS 지식을 어느정도는 공부한 팀원이 중요하다. 그리고 무엇보다 가장 중요한 것은, Git을 다룰줄 알아야된다. 다같이 개발할 때 가장 필수적인 것이 Git인데, 쓸줄 모르는 사람은 절대 택하지 말자.

 

3번 같은 경우는, 알바를 여러개 한다던가, 이미 일하고 있는 사람인데 프로젝트 같이 하자고하면 시간 문제 때문에 잘 집중하지 못할 것이고, 그만큼 해당 개발자의 결과물도 퀄리티가 좋지 않아진다. 이것도 어찌보면 당연한 것이다.

 

4번 같은 경우는, 필수는 아니긴하다. 하지만, 내가 Spring을 쓸 줄 아는데 Spring을 쓸 줄 아는 백엔드 팀원을 모아오면 개발 시간이 많이 단축 될 것이다. 하지만, 우리가 개발할려는 프로젝트에 따라서 프레임워크는 충분히 변할 수 있기 때문에 이는 필수 사항은 아니다.

 

5번 같은 경우는, 개발이 재미없고 억지로 할려는 사람이랑은 절대 해서는 안된다. 아주 중요하다. 그 사람도 억지로 하는 것이다 보니, 개발 속도도 늦어지고, 결과물도 좋지 않고, 팀장은 이걸로 감정소모를 많이하게 된다. 열정이 없는 사람이랑은 절대로 하지 말자.

 

추가적으로, 처음부터 완벽한 팀원을 모을 필요는 없다. 예를 들어, 내가 아는 사람들이 다 백엔드이다? 그럼 일단 백엔드 2~3명이서 팀을 시작한다. 그리고, 디자이너, AI, 프론트엔드 등등 차차 모집을 하면 된다. 굳이 초기 팀원을 모으는 이유는, 아이디어를 구상하고 프로젝트의 기틀을 다잡기 위해서이다. 또한, 한 분야만 집중해서 팀원을 데려오면 안된다. 내가 아는 사람이 다 백엔드라고 백엔드 4명으로 초기 팀원을 잡으면 망한다. 백엔드만 모여서 서비스 개발을 한다는 것 자체가 말이 안된다.

 

🧠 아이디어 구상하기

이제, 초기 팀원들을 구성했으면 어떤 프로젝트를 진행할 것인지 아이디어를 떠올려야 된다.

솔직히 말하면, 이 과정이 정말 쉽지않다. 개발 시장이 워낙 레드오션이기 때문에, 새로운 것을 만드는 건 굉장히 힘들고 웬만한건 다 존재하기 때문이다. 그래서 혼자 생각하긴 더더욱 힘들기 때문에 그래서 이를 함께할 초기 팀원을 모집한 것이다.

 

아이디어 구상은 팀원들이 다같이 모여 브레인 스토밍으로 막 던지듯이 해보면 좋다. 브레인 스토밍을 어떻게 진행하면 좋은가? 몇가지 예시를 들어보겠다.

 

- 특정 키워드 중심으로

 

누가 추억이라는 키워드를 던졌다 → 나는 추억하면 케로로같은 추억의 애니메이션이 생각난다 → 이런 추억의 애니메이션 정보를 주고받는 플랫폼이 있었으면 좋겠다 → 나는 추억하면 옛날에 문방구에서 사먹던 추억의 과자들이 생각난다 → 그런데 추억의 과자들을 요즘 파는데가 없다 → 이런 추억의 과자를 사먹을 수 있는 장소를 알고 싶다 → 동네 주민들끼리 지도에 추억의 과자 판매점 위치를 표시할 수 있게해서 다같이 공유하면 좋지 않을까?

 

이런식으로 아무런 키워드나 일단 던져보고, 생각나는대로 의식의 흐름을 따라서 타고타고 들어가는 것이다. 이때, 팀장은 해당 키워드에서 벗어나는 주제가 나온다면 어느정도 제제를 해줘야 한다.

 

- 불편했던 경험을 중심으로

 

나는 에브리타임에서 교내 프로젝트 같이할 인원 찾는게 너무 힘들어 → 스타트업 구인 구직 중심이 아닌 개인 사이드 프로젝트를 같이할 인원을 찾는데 중점을 둔 플랫폼이 있으면 좋겠다!

 

알고리즘 문제를 푸는데 백준, 프로그래머스, CodeForce, 정올 등등 각각 좋은 문제가 많은데 플랫폼 통합이 안되있어 → 종만북같은 책에도 좋은 문제가 많은데 책의 문제는 공유하기 힘들어 → 알고리즘 스터디 할 때 이런 여러 플랫폼의 문제들을 한 플랫폼에서 다같이 공유하고 풀 수 있었으면 좋겠어

 

흡연 구역이 지도에 잘 나와있지 않아 → 흡연이 너무 급한데 주변 흡엽 구역을 찾을 수가 없어서 못피고 있어 → 흡연 구역을 공유할 수 있는 플랫폼이 있었으면 좋겠어

 

이런식으로, 자신이 불편했던 경험을 막 던지고 거기서 타고타고 들어가는 형식으로도 접근하면 좋다.

 

- 사람을 중심으로

 

국민대 유학생들이 한국 생활 적응을 힘들어 하는데 도울 방법이 없나? → 학교에서 친구 사귀는데 어려움을 느끼고 있네 → 학교 정보를 찾는데 너무 어려움을 느끼고 있네 → 유학생들의 학교 생활을 도울 수 있는 서비스가 있었으면 좋겠어

 

이런식으로, 특정 집단 또는 사람을 중심으로, 그들을 위한 서비스 쪽으로 접근해도 좋다.

 

- 특정 기술 사용을 중심으로

 

Azure에서 최근에 발음평가를 할 수 있는 SDK를 제공해주네? →  단지 발음평가만 하기 아쉬운데  다르게 활용할 방안이 없나? → 외국인 유학생들도 발표같은걸 많이 하는데 발표 스크립트를 읽는데 어려움을 겪고 있어 → 이 SDK를 활용하여 유학생들의 발표 스크립트 발음 체크같은 것을 도와주면 좋지 않을까?

 

특정 기술이 나온지 얼마 안되어서 경쟁력이 있는 경우, 이런식으로 이를 어떻게 활용할지 조금 더 크게 봐서 아이디어를 생각하면 좋다.

 

- 다른 프로젝트 개선을 중심으로

 

아니면 다른 사람들이 만든 프로젝트 주제들이 뭐가 있는지 참고해보면 좋다. 보다보면 뭔가 번뜩이는 아이디어가 떠오를 수도 있기 때문이다. 이미 있는 플랫폼들의 단점을 분석하고, 이를 개선해서 하는 것도 좋은 그림이기 때문이다. 그럼 이런 것들은 어디서 보면 좋냐? 그냥 Github 아무거나 추천 뜨는 거 무작위로 봐도 좋고, 컴퓨터공학과면 대부분 졸업작품으로 어떤 프로젝트 개발을 할텐데 이것들이 모아져 있는 사이트들을 봐도 좋고, 무작위 티스토리 블로그에서 진행했던 글들을 봐도 좋고, 구글 플레이스토어에 있는 무작위 앱들을 탐색해도 좋다. 몇가지 참고하면 좋은 곳들을 보여주겠다.

 

DevFoliOh! - 개발자 토이프로젝트 모아보기 서비스

자신이 만든 토이프로젝트들을 공유하는 사이트이다. 그런데 생각보다 글이 많진 않다.

 

woowacourse-teams

배달의 민족에서 운영하는 우아한 테크코스 Github이다. 여기서 여러가지 주제로 프로젝트를 개발한 것들이 있으니 참고해도 좋다.

 

KMUCS 캡스톤디자인

아마 학교마다 이렇게 졸업작품 사이트가 있을텐데, 이런데서 봐도 좋다.

 

UMC Times

이 곳에서도 꽤나 많은 프로젝트들이 있으니 참고해도 좋다.

 

 

아이디어를 구상할 수 있는 5가지 방향을 제시해줬지만... 그래도 아마 적절한 아이디어를 찾는 것은 굉장히 어려울 것이다. 따라서, 브레인스토밍은 꾸준히 점진적으로 하면 좋다. 더 좋은 아이디어가 갑자기 떠오르면, 갈아타는 것도 괜찮다. 또한, 브레인스토밍의 시간은 나는 2시간이 넘어가면 안된다 생각한다. 그정도로 진행되면, 그날 떠오르는 아이디어는 다 나왔다고 봐도 된다. 오히려 더 하는게 시간낭비이다.

 

우리도 아래 사진 처럼, 그냥 아무거나 생각나는대로 막 적고 거기서 베이스 아이디어를 선택했다.

😁 팀원간 소통

나같은 경우는 팀원과 소통을 위해서 Slack, Discord, 카카오톡을 사용한다. 각각 메신저를 어느 상황에서 사용하는지 얘기해보겠다.

 

Slack : 대부분의 개발 업무와 관련된 내용은 Slack을 사용한다.

Discord : 비대면 회의를 진행할 때 사용한다. Zoom 무료버전은 제한시간이 있기 때문에 부적합하다. 반면에 Discord는 통화하기도 좋고, 화면 공유도 있어서 내 진행상황을 공유하기도 꽤 좋다.

카카오톡 : 긴급하게 전달해야되는 공지사항, 비개발관련 공지사항(ex : 활동보고서 작성, 점심 메뉴 정하기 등?), 회의 날짜 및 시간 공지 → 즉, 급한 사항 또는 개발과 관련되지 않은 이야기는 카카오톡에서 진행한다.

 

그런데 그냥 전부 카카오톡 쓰면 되는거 아닌가 생각할 수도 있다. 하지만, 카카오톡은 우리 사적인 대화가 오가는 경우가 많다. 그렇다보니, 개발업무도 거기서 얘기하면 굉장히 지치고 잘 안보게 된다. 그리고 무엇보다 카카오톡의 치명적인 단점은 계속 대화가 쌓여서 밀린다는 것이다. 그래서 우리가 개발 안건을 빠르게 볼 수 없다.

 

 

우리 Slack은 위와 같이 채널을 나눠서 운영한다. 이렇게 하면, 특정 주제에 대해서 빠르게 접근하고 안건을 볼 수 있다. 카카오톡은 이를 구현하려면 채팅방을 여러개 만들어야 한다. 

 

 

또한 Slack의 최고 장점은 스레드 기능이다. 

 

하나의 안건에 대해서, 위처럼 대댓글 처럼 달 수 있다. 그러면 대화의 문맥이 하나의 안건에 대해서 집중 될 것이고, 카카오톡 처럼 엄청 메시지가 쌓이는 경우도 막을 수 있다. 그래서 아주 중요한 부분이 카카오톡처럼 메시지를 채널에 여러개 보내면 절대 안된다. 잘 정리해서 한눈에 볼 수 있게 답변을 달아줘야된다. 또한, 특정 안건에 대한 얘기는 그 안건의 스레드 내부에서만 진행되어야 한다.

 

 

이외에도 Github Repo란 연동해서 실시간으로 Issue 및 PR 올라오는 것들도 볼 수 있고

 

 

Git Actions과 연동해서 배포 결과도 받아볼 수 있다. 아주 가능성이 무궁무진한 업무용 메신저이다. 그래서 나는 Slack을 쓸 것을 권한다.

 

💾 기록

기록은 매우 중요하다. 특히, 내가 강조하고 싶은 것은 회의 내용에 대한 기록이다.

우리가 회의를 진행했고, 거기서 엄청나게 좋은 안건들이 여러개 나왔다. 하지만 우리가 기록을 안해두면 어떻게 될까? 100개 안건이 나왔으면 분명히 절반 이상은 까먹는다.

 

그래서 우리가 이 날 회의에 어떤 주제를 가지고 논의했는지 문서화를 하는 것이 중요하다. 문서화 도구는 여러가지 있겠지만 나는 Notion으로 설명해보겠다.

 

 

노션 템플릿 중에서 "캘린더" 템플릿이라고 있다. 위에처럼 날짜별로 문서를 만들어서 회의 내용을 기록하면 좋다.

그런데, 회의도 하면서 동시에 기록하는게 되나요라고 생각이 들 수도 있다.

 

그래서, 우리는 일단 회의록에 핵심 키워드만 적당히 몇개 적어두고, 회의가 다 끝난 다음에 자세히 정리하는 식으로 진행하고 있다.

 

 

또한, 회의록 템플릿은 계속 쓸 것이기 떄문에 만들어두면 좋다. 위에처럼, 글 쓰기에 들어가면 새 탬플릿이라고 있다. 이걸 눌러서 탬플릿을 만들고, 그뒤로는 가져다 쓰기만 하면 된다. 회의의 진행 방법에 대해서는 #4 회의 진행 글 작성할 때 더 자세히 다뤄보고자 한다.

 

이상, 프로젝트 시작하기를 위한 기초 다지기 단계에 대한 설명을 마치겠다.