brunch

You can make anything
by writing

C.S.Lewis

by 쿠우보이 Feb 26. 2017

프로그래밍 부트캠프

첫 번째 프로젝트

SW로 사업을 해 보고 싶다. 내가 개발의 '개'자도 모르면서 개발자들과 함께 일할 수는 없다. 아니 적어도, 프로토타입은 내가 만들 수 있어야 한다는 말에 프로그래밍 부트캠프 과정을 듣기 시작한지 2개월이 지났다. 학습과정이 끝난 후, 3주 동안 팀 프로젝트를 하게 되었다. 각자 하고 싶은 서비스의 아이디어를 기획, 제작, 발표하는 단계로 진행이 되었다. 아이디어를 낼 수 있는 좋은 기회다. 나는 평소에 넣어놓았던 여러 가지 아이디어 중, 바로 배운 기술을 연습해보기 좋은 아이디어로 내놓기로 했다.


비록 연습 삼아 해 보는 프로젝트였지만, 나는 가능하면 실제로 사람들의 불편함을 해결할 수 있는 pain killer 서비스를 만들고 싶었다. 그래서 전부터 나 스스로 불편함을 느꼈던 식사 후, 정산 프로그램을 만들기로 했다.


구내식당이 없는, 그리고 식권을 사용하지 않는 많은 직장인들은 대게 팀 단위로 식사를 하게 된다. 식사를 마친 후, 계산을 하게 되는데, 우리는 보통 한 명이 카드로 계산을 하고, 나머지 사람들이 현금을 정산자에게 주는 방식으로 해결하고 있다.  문제는 계산 이후, 정산이 바로바로 이루어지면 좋겠지만 줘야 할 채무자도, 받아야 할 채권자도 잊어버리거나 정확히 기억이 나지 않을 경우가 흔하다. 보통 아래 직급의 사람이 돈을 내고 정산을 하기 마련인데, 위 직급의 사람이 자꾸 돈을 빨리빨리 주지 않으면 은근히 6,7천 원 때문에 의가 상하기까지 하는 경우도 봤다.

이대리: 김 과장님 저번에 7천 원 주셔야 하는데..
김 과장: 7천 원? 그때 주지 않았나? 줬던 것 같은데...
이대리: 아뇨 받지 못해서요.
김 과장: 그래? 이상하다 그때 다음날 줬던 걸로 기억해서.. 뭐 암튼 알았어 이따 사무실 가서 줄게

이쯤 되면 돈을 주고받아 정산이 완료되어도 서로 찝찝하게 된다.



이 문제를 해결하기 위해, 우리는, 매일의 기록을 입력해만 해 두면, 이후 개인 간 채무관계만 간단하게 보여주는 채무관계 history tracking 및 net calculation을 보여주기로 했다.

그간 회식이나 식사를 하면 매 번 이런 엑셀작업으로 정산을 했었다.

엑셀은 정산용으로 쓰기에 참 좋은 무궁무진한 툴이지만 정산 템플릿의 재사용성이 굉장히 떨어지고 식사 데이터의 장기간 보관이 용이하지 않다. 따라서 우리 서비스를 아래와 같이 정리하기로 했다.


잠재 고객

- 팀 단위로 매일 함께 식사하는 직장인들

문제

- 함께 식사 시, 정산이 여러모로 불편하다

해결책

- 식사 이벤트가 있을 때마다, 정산자는 입력만 하고, 채무관계는 서비스가 자동으로 계산해 준다.

핵심 필요 기능

- 간편한 이벤트 정보 입력

- 단순 N빵 (균등 나눔) 및  개별 입력 기능

- 회원 가입 및 로그인 로그아웃

- 이벤트별 정산 기록 및 개인 간 채무관계 실시간 보여주기

- 정산 요청 / 수락 / 거절

- email / SNS 알림 및 공유


기술 스택

두 명은 node.js / express / mySQL로 DB 및 server를 맡기로 했고 (Backend) 나와 다른 한 명은 React.js 와 bootstrap으로 보이는 홈페이지를 만들고 기능 구현 및 디자인을 하기로 했다. (Frontend)

facebook에서 만들고 밀고 있는 React js
javascript 실행 환경인 node.js, js 로 server를 만들 수 있다.

나는 프런트를 맡기로 했는데, 전에 React를 배울 때, 이해 못했던 부분이 많아서 좀 겁이 나긴 했다. '과연 내가 잘할 수 있을까? 처음인데 공부만 하고 프로젝트 진행이 안돼서 백엔드 사람들에게 민폐가 되진 않을까?'

이런 걱정이 있었기에, 더 열심히, 뒤처지지 않게 작업을 진행하고 싶었다. 이전 과제에서는 React로 Todo List도 겨우 겨우 만들었기에 자신감이 굉장히 부족한 상태였다.



우리는 짝 코딩을 하기로 했다. (pair programming) 한 명이 키보드를 잡고, 다른 한 명은 내비게이터가 되어 키보드 잡은 사람에게 잔소리를 하는 방향을 알려주는 코딩 방법론이다. 각자 기능 맡아서 하면 되지, 왜 비효율적으로 두 명이 같이 붙어서 코딩을 하냐고 물을 수 있겠지만, 이게 장단점이 있다. 서로 논의하면서 방향을 정하기 때문에 속도는 느려도 결국 디버깅이 줄어드는 이유로 전체 속도는 별반 차이가 나지 않고, 코드 퀄리티가 높아진다고 생각된다. 물론 대부분의 틀이 잡힌 이후에는 속도를 높이기 위해 기능별로 나눠 각자 코딩을 하기도 했다.

전형적인 짝 코딩 모습...농담이다
보통은 이렇다


기본적으로 백엔드 쪽에서 API라고 해서 DB query를 통해 어떠 어떠한 data format으로 프런트 쪽과 data를 주고받을 것인지 정하게 된다. 우리는 백엔드에서 정해주는 API 형태를 보고 data를 받고 또 보내게 된다.

멋지게 API 를 정리해서 공유할 수 있는 swaggerhub!!! 이건 진짜 끝내준다

위에 있는 SWAGGER를 사용하기 전까지 종이 쪼가리에 data 어떻게 보내줄지, 끄적이곤 했었는데 정말 SAWGGER를 사용하고 나니 얼마나 우리의 협업 퀄리티가 높아졌는지 감동이었다.


협업

협업은 Trello를 이용해서 애자일 스크럼 (Agile scrum)을 흉내 내보기로 했다. 매일 아침 10여분의 스탠드업을 통해 어제 한 일, 그리고 오늘 한 일을 나누었다. 스프린트는 3일 정도로 나누어서 우린 총 5번의 스프린트를 가질 수 있었다. 버전 관리는 github를 이용했으며, 정말 열심히 commit 하는 습관을 가졌다.

338번의 commit! 커밋 많이 한다고 좋은 건 아니지만 꽤 뿌듯했다. 그런데 그렇다고 실제로 커밋을 제대로 활용은 잘 못했다. (roll back이라든지)



2주가 지나자, 백엔드의 API는 거의 다 정리가 됐고, 앞단에서는 뼈대의 기능 페이지 등이 완성되었다. React를 잘 다루지 못해 정말 삽질에 삽질을 연속했다. 코딩을 하는 건지 노동을 하는 건지 헷갈릴 정도로 엄청 데이터를 가지고 와서 우리 맘대로 가공해서 그림을 그리곤 했다. 이게 다 조금 더 스마트하게 생각했으면, 코드를 충분히 줄일 수 있는 것인데, 막상 할 때는 생각이 나질 않았다. 결국 이후 리팩터링을 하면서 반복되는 코드들을 함수로 만들어 재사용성을 높였고, 이것이 버그를 줄이는데 큰 역할을 했다.


초기 버전 (뼈대) - 아무 디자인이 없다. --

이후 수강생 파트너가 노오력을 해서 bootstrap/css를 이용, 아래와 같은 디자인을 입히게 되었다.


프로젝트 발표 때까지, 우리는 치명적인 버그들이 발견되어 긴장을 멈출 수 없었다. 마지막에는 서버에 직접 들어가 vim으로 코드를 긴급 변경하기도 했다. 그러나 시연 때 결국 하나의 버그가 발견되어 당황할 수밖에 없었다. 그래도 만족...


우리 제품의 버전은 v0.5이다. 기능으로 보나 퀄리티로 보나 그렇다. 도메인을 사서 올려놨지만, 실제로 사람들이, 팀이 쓰기엔 아직 역부족이다. 버그들이 있기 때문이다. 일단 자잘한 버그를 좀 더 잡고 사람들에게 사용을 권장하고 싶다. Messenger 공유 기능, 및 홈페이지 결재를 통해 정산을 플랫폼에서 바로 할 수 있게 만들어야지. 이건 v2.0에서 가능할 것 같다. 일단 freemium 모델로 사람들에게 사용하게 한 다음에, 우리 서비스를 사랑하는 충성된 고객층을 만들어야겠다. 이후 사람들의 정산 내역이 쌓이게 되면 이 data를 이용하여 식당 업주에게 data를 파는 비즈니스 모델을 생각하기는 개뿔, 그냥 많은 사람들이 편하게 사용하기만 해도 더 이상 바랄 게 없다.



후기

3주간 정말 열심히 달렸다. 내가 고집이 세고 독단적이어서 내 수강생 파트너는 나를 일통령이라고 불렀다. 적어도 현재 파란 집에서 먹고 자고 하시는 분 보다는 대화와 타협을 배우도록 해야겠다.

- 앞으로 코딩할 때는 기능은 최대한 분리해서 짜기, 스파게티 코드가 만들어짐

- React에서 자료를 삽질해서 그리고 있었는데 좀 더 스마트하게 함수화할 수 있는지, 아니면 Redux를 배워볼지

- 지금의 UI는 나름 이쁘다고 생각하지만, 실제 주변 사용자들에게 사용케 한 후 피드백을 들어서 개선해야 함(이건 정말 지속적으로 개선이 필요)

- 개발 과정 중 한 번씩 막혔다가 풀리는 경우가 있었는데, 여기서 배운 점들을 짧게나마 기록을 해 둬야겠음. 반복적인 막힘이 있을 수 있으므로...


앞으로 4주의 프로젝트가 한번 더 남았다. 이번엔 백엔드 쪽으로 공부해보고 싶다. 개인적으론 JS + Electron을 이용하여 desktop App을 만들어보고 싶다. 힘들지만 재밌으면 된 거다. 또 기대가 된다.



매거진의 이전글 사람들은 SW를 사용하고 싶어 하지 않는다
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari