우당탕탕 Sparta 42 젠리 만들기 - 전반전

Sparta 42 결성 !

sparta42는 어떤 지식을 습득하는 데에 있어 검색하는 시간이 너무 길어지고 포트폴리오에 쓸만한 프로젝트가 없다는 공통적인 고민 속에서 시작했다. 이러한 고민을 하는 사람은 꽤나 많았고, 우리는 nakim, seolim, sujung 등 18명이라는 (나름) 대규모 인원으로 시작했다.

 

우리는 Zenly라는 서비스를 우리만의 방식으로, 실제 회사에서 개발하는 것처럼 해보자! 라고 결론을 내렸다. 그리고 아직까지도 우리를 지도해주고 계신 이호준 멘토님의 멘토링 아래 활동을 시작했다.

 

구성원들은 각자 잘할 수 있는 분야를 살려 web FrontEnd, BackEnd, iOS 그리고 Infra 라는 4개의 팀으로 나뉘었다. 나는 평소에 iOS 개발에 관심이 있었기 때문에 iOS 팀에 참여했다.

 

 

출처:구글플레이 "Zenly" 검색 시 제공되는 이미지

본격적인 활동 시작.

진행방식

sparta 42의 zenly 만들기는 다음과 같은 방식으로 진행됐다. 먼저 멘토님께서 현업에서는 이러이러한 방식으로 한다는 것을 설명해주신다. 그러면서 우리가 일주일 동안 해왔으면 좋겠다라고 기대하시는 부분들을 우리에게 전달하신다. 전달받은 사항에 대해 우리는 팀별로 문제를 해결하고 때로는 팀간 소통을 하며 최대한 해본다. 일주일이 지난 시점에서 멘토님께 팀별로 진행 상황을 보고하고 이를 반복한다.

 

[팀간 회의 모습. sujung님의 infra팀 진행상황 발표 중 사진.]

 

 

 

특히 같은 팀 뿐만 아니라 다른 팀과 소통을 할 때에는 소통을 위한 Tool 이 꼭 있어야 한다는 멘토님의 말을 듣고 우리는 jira + confluence 를 사용하기로 했다. jira는 여러 개의 팀의 일정을 칸반 보드 등 다양한 방식으로 관리할 수 있게 도와주는 툴이고 confluence는 notion처럼 jira에서 소통하며 조사했던 것들, 회의로 결정한 사항 등을 정리해놓는 공간이다. 추가로 설명하자면 아래 사진처럼 팀별로 해야할 일들을 잘게잘게 쪼개서 분할하고, 직접 만날 필요 없이 텍스트만으로 협업을 가능하게 해주는 강력한 툴이다. 정말 많은 기능을 제공하고 연동되는 서비스도 슬랙을 포함하여 정말 많지만 그만큼 초기 진입장벽이 높다는 단점이 있다.

 

jira 칸반보드 캡쳐.

 

 

결정해야 할 것이 너무 많다.

소통 툴을 정하고 소통 방식을 정하고 나니 이젠 실제 회사에서 하는 것처럼 협업을 할 준비가 된 느낌이 들었다. 그러나 그 다음에는 더 큰 난관이 기다리고 있었다.

 

화면에 hello world\n 를 찍기 위해서는 얼마 만큼의 시간이 걸릴까. 사람마다 그냥 write(1, "hello world\n", 12) 하면 되는 것 아니냐라고 생각할 수도 있을 것이고, 반대로 누군가는 규모에 따라 몇 개월이 걸릴 수도 있을 것이라고 생각할 것이다. 전자의 경우는 사실 sparta 42를 하기 이전의 내 생각이고 후자는 지금의 내 생각이다.

 

그렇게 생각한 이유는 간단하다. 바로 코드를 치기 전에 이것저것 정해야 할 것들이 너무너무 많다는 것 때문이다. 협업을 위해 환경을 맞추고 형상관리는 어떻게 할지, 또 테스트는 어떤 방식으로 할지 정하다 보면 이렇게 결정하는 일련의 과정들의 필요성은 몸소 느끼면서도 그 과정 자체는 정말 지루하고 고통스러웠다. 아래 사진은 iOS 팀에서 프로젝트 파일을 만들기도 전에 미리 결정했던 사항들이다. 개수가 많아 보이지만 지금 현재 코드를 치는 단계까지 진행한 나는 정해야 할 것들이 또 늘어나고 있어서 너무 고통스럽다. (살려줘)

 

너무 만화!!!

 

 

개발은 플로차트부터 그리고 시작.

혹시 회원가입을 하고 로그인을 하는 페이지를 만들어 본 적이 있는가. 있다면 대개 어떤 식으로 진행돼야 하는지를 즉흥적으로 생각해내면서 구현을 하거나 종이에 간단하게 써가는 정도로 진행했을 것이라고 생각한다.

 

그런데 이번에 내가 만든 서비스를 누군가가 쓸 거라고 생각하면서 사용자가 직면할 수 있는 각종 상황을 고려하고, 또 디자인 패턴을 적용하면서 구조가 바뀌어가는 상황에 직면하게 되니 도저히 플로우 차트를 그리지 않고서는 진행할 수 없다는 판단이 섰다.

 

그래서 이제는 플로우 차트를 그리지 않고서는 성급하게 코드를 치지 않는 버릇이 생기게 됐다. 뭐 얼마나 했다고 버릇이 생겼냐고 생각할 수 있겠지만 제대로 플로우 차트를 그리지 않고 날린 시간에서 오는 스트레스에 대한 공포가 그 버릇을 빨리 들도록 만들었다.

 

아래는 내가 회원가입/로그인 과정에서 마주칠 수 있는 여러 가지 요소들을 고려하며 만든 플로우 차트이다. 간단할 줄만 알았던 해당 구현 과정이 이처럼 복잡할 줄은 몰랐다. 현업에서는 더더더더 복잡하겠지...

 

 

로그인/회원가입 플로우 차트

 

 

배우고 깨달은 점.

글을 쓰는 이 시점은 이제서야 막 로그인/회원가입 과정을 구현하고 지도에 내 위치를 띄운 시점이다. 최종 구현까지는 아직 갈 길이 멀지만 여기까지 오면서도 굉장히 많은 것들을 배울 수 있었다.

 

먼저 팀 간 소통을 위한 도구로 jira를 사용하면서 협업을 해봤냐라고 하는 질문에 대한 기준을 세울 수 있었다. 텍스트 베이스의 소통 방식은 나중에 노마드 라이프를 즐길 수 있지 않을까라는 행복한 상상으로 이어지기도 했다. 또한 이러한 툴을 사용함으로써 평소에 궁금했던 Dev-ops 라고 하는 것이 무엇인지 감을 잡을 수 있어서 개인적으로는 굉장히 소중한 경험이었다.

 

또 하나 알게 된 게 있다면 규모가 있는 프로젝트에 참여하게 된다면 코드 치는 시간은 그렇게 많지 않을 것이라는 것. 결정해야 할 사항이 너무 많아서 거기에 시간을 다 쏟은 경험에서 나온 깨달음이었다. 사실 이러한 깨달음이 달갑지는 않았다. 많은 것을 결정하는 과정이 고통스럽고 지루했기 때문이다. 프로젝트 하나 하는 것을 일주일에 비유하자면 월화수목금은 무언가를 결정하고, 플로차트를 그려보는 과정이고 퇼은 코드를 치는 과정이라고 생각한다. 퇼은 즐겁지만, 짧다. ㅠ

 

백엔드 팀과 함께 소통하면서 하나씩 만들어본 API들. (feat Swagger)