[API backend] server 기획부터 배포까지 (1) - 준비

backend, api server, golang  · 

시리즈 기획 배경

5년만에 이런저런 이유로 (반)자발적 백수가 되었다. 원하는 일을 할 수 있을 것 같아 보이는 회사들에 틈틈이 지원서를 넣고 인터뷰를 진행하고 있기는 하지만, 확실히 시간이 여유로운 편이라, 이왕 이렇게 된 거 간접 경험이나마 조금이라도 늘려 둘 겸 토이프로젝트를 진행하면서 그 처음부터의 과정들을 하나의 시리즈로 남겨 보고 싶어졌다. 비록 삽질일지언정, 여유가 생겼다고 늘어지기 시작하면 관성이 되어 아무 것도 안하고 시간만 흘려보내게 될 테니까.

Project 구상

올해 초 3월, COVID-19 유행으로 전세계의 주식 시장이 나락으로 곤두박질 치던 때가 있었다. 너나할것 없이 영끌·빚투한다고 난리였고… 나도 평소에 주식에 관심이 아예 없었던 건 아니었던 지라, 빚투 까지는 아니지만 여윳자금을 안정적인 주식에 넣어 두면 최소한 10년 정도는 예적금 금리보다는 그래도 눈꼽만큼이라도 더 이익이 생기지 않을까 하는 생각에, 그리고 에이 뭐 들고있다가 영 아닐거 같으면 2세한테 물려주지 뭐 가난의 대물림 하는 생각으로 소액 투자를 해놓았었다.

처음엔 어차피 10년이상 장투할거 없던 돈인 셈 치고 잊어버리자 했는데, 어디 사람 마음이 뜻대로 되는 거 봤나… 킹갓새가슴소심대마왕이라 단타는 못치지만 그래도 자꾸 올랐나? 내렸나? 지금까지 얼마 벌었지? 얼마 날렸나? 하는 궁금증이 치고올라온다. 그래서! 매번 증권사 application 에 로그인하기도 귀찮고… 어차피 주가 정보는 공개되어 있는 것. 간단히 공인인증서 로그인 없이도 내 주식 거래 내역을 등록만 해 두면 손익현황을 내려주는 API server 를 만들어보기로 했다. 공부도 할 겸…

큰그림

일단 그래도 할 줄 아는건 backend 인지라… frontend 는 과감하게 포기. 나중에 백수생활이 길어져서 할 일이 다 떨어지게 되면 도전해볼까 한다. JSON 으로 내주식현황을 내려주는 API 서버를 구상해본다. 이름은… 음… 누구나 들으면 뭐하는 서버인지 알수있어야 해… 1분1초 시시각각 오르락내리락 차트화면 붙들고 있는, 비트코인 광풍 때부터 우리 입에 아주 친숙하게 찰싹 달라붙던 그 이름. “Gazua” 서버는 이렇게 시작했다.

무체계, 무논리

사실, 대강 원하는 기능은 한 번 다 만들었었다. golang application 으로 만들어 GCP 에 배포하고, MongoDB Atlas 를 이용해서 user db 도 구현했었고… 근데 원하는 기능 만으로 구상을 시작하고, 그 기능들을 구현하기 위한 기법(혹은 방법) 만으로 구현을 하다 보니, package 는 의미가 불분명한 채 여기저기 흩어져 있고, struct 를 사용만 했을 뿐 전혀 golang 의 특성을 살리지 못하고 있는 코드들.. (문법만 go 였지 완전 C 나 다름없었다) 그냥저냥 예제 서치해서 이해만 하고 사용했던 코드 등등 거슬리는 점이 한두 가지가 아니더라. 그래서 좀 더 체계적으로 기획부터 설계, 구현, 배포까지 해 보고 싶어졌고, 다양한 설계 접근법, 개발 방법론 등을 찾아보게 되었다.
그런데 이론적인 방법론들을 너무 많이 찾아봐서 그런가, 어느 순간 음 이거 완전 조선시대 가난한 집 선비가 딱 이꼴이었겠구나 싶더라. 허구헌날 방에서 책상펴고 앉아서 밥 먹여주지도 않는 공자왈 맹자왈 따지고 있기보다는, 일단 몸으로 움직여봐야겠다는 생각이 들었다.

새출발

우선 기존의 github repository 에서 develop branch 를 ‘v1’ branch 로 ref 만 따 두고, repository 처음 생성한 커밋으로 reset 하였다. ‘v1’ branch 는 ‘이렇게 하면 망해요’ 의 반면교사로 남겨 둘 셈이다.

어떤 접근법을 쓰던, 어떤 프로세스로 개발을 하던 일단 선택의 기준이나 정당성은 중요치 않다. 하지만 이 프로젝트를 진행하면서 반드시 지켜야 할 대전제를 정했다.

무엇을 선택하던지는 자유지만, 선택을 했으면 반드시 그 rule 을 지킨다.

내가 개발하려는 결과물이 그 방법론과 어울리지 않는 것이었다고 나중에 밝혀진다 해도, 일단 그런 접근법과 방법론을 사용하여 프로젝트를 처음부터 끝까지 진행해 보는 것이 목표이기 때문에 중간에 현실과 타협하여 rule 을 흐리는 일이 없도록 한다. 그래야 나중에 그것이 좋은 선택이었는지 혹은 miss-matching 이었는지 객관적인 평가가 가능할 것이기 때문이다.

그래서 이제부터

새로 해야 할 일을 정했다.

Project hub 및 기술 스택

보통, repository 를 어디에 둘 것인가 결정하는 데서부터 시작한다. 기존 개발했던 결과물도 다 github 에 있고, 1인 프로젝트에 issue tracking 등을 위하여 별도의 외부 도구들을 사용하기엔 또 project 진행 자체보다 도구 학습에 들이는 burden 이 커질 것 같아서 가능한 모든 것들은 github 이 제공하는 서비스 내에서 끝내려 한다. 그래서 결론은, Git + github hosting + Github project (milestone / issue) 를 사용해서 project hub 를 구성하기로 결정.

Programming 언어, Service infra (public cloud 등), Authorization, Database 등 우선 예상되는 기술스택 의사결정 사항은 Project Wiki 에 기록해 두었다. 추후 변경사항 발생시 해당 페이지에 지속적으로 업데이트할 예정.

외부 API 사전조사

기존 구현에서는 외부 API 를 좀 어거지로 끌어다 사용했었다. 일례로, 종목코드 전체를 제공하는 excel 파일을 받아 서버에서 파싱, JSON 구조로 변환하여 서버의 로컬에 저장하고 이를 daily cron job을 이용하여 업데이트하는 식. 이런 식의 임기응변 코드가 초래하는 risk 에 대해선 굳이 언급하면 입만 아프므로… 이번엔 철저히 사용가능한 공공정보 API 를 위주로 하여 원하는 데이터를 효율적으로 사용할 수 있도록 설계할 예정이다. 역시 마찬가지로 Github 의 Project wiki 에 별도의 문서로 업데이트할 예정.

HTTP API 정의, 문서화

이 부분은 Github 의 내부 문서도구만 가지고는 효율적이고 알아보기 쉽게 관리하기가 힘들다고 판단했다. 그래서 Gitbook 의 API 문서화 기능을 이용하기로 했다.

이제 시작

프로젝트는 이제 시작하는 단계로, 내가 어디까지 얼마나 이걸 기록하며 해나갈 수 있을지는 모르겠지만. 최선을 다해 보자는 의미에서 굳이 공개된 블로그에 싸지른다. 안했을때 쪽팔리기 위해서 프로젝트 자체도 진행하면서 프로젝트 일기 형식으로 남기게 될 예정이라 포스팅의 텀이 생각보다 길어지게 되겠지만, 일단 끝까지 가는 것에 의미를 두고자 한다.

Special thanks to…