2020.03.15 ~ 2022.01.04

우선 본인이 취업생활을 시작했을때의 스펙이다

• 20대 중반까지 음악생활을 하다가 10년차 개발자인 매형의 권유로 개발을 시작하게됨
• 자바로 HELLO WORLD 출력하기까지 수시간이 걸림,
  계속 되는 에러메세지 때문에 컴퓨터에게 승부욕을 느끼게됨(??)
  이 길이 내길이다 라고 생각하고 본격적으로 개발을 시작함
• 최종 학력 고졸
• 6개월동안 국비학원에서 자바를 배웠음
• 학원에서 만든 프로그램 빼고 포폴 2개 소유하고 있음
• 독학으로 React 및 Express 가능

---

🤯 이것이 스타트업?...

무한 서류 광탈에서부터
충격과 공포의 첫 출근

다른사람들에 비해 약간은 늦은 나이라, 국비학원에서 개발공부를 할 동안
아침 9시 ~ 밤 11시 혹은 12시까지 코딩을 하는 스파르타식 스케쥴을 소화했었다.
(사실 국비충 소리가 너무 듣기 싫었다.)

대망의 학원 수료가 끝나고 취직시장에 돌입했다.
내 스펙으로 대기업은 힘들다고 판단하여서 중견~스타트업까지 수십개의 이력서를 넣었고,
코딩 테스트도 미친듯이 준비했지만

결과는 전부 서류심사에서 광탈

10년차 개발자인 매형이 있어서 이력서 피드백은 수도 없이 받았기 때문에
이력서 문제는 아니였던것 같고 자체적으로 내린 결론은 "학력" 문제였다고 판단.

당시에는 과제전형이나 코테전형 기회조차 주지않아서 너무 억울해, 눈물이 다 날 지경이었지만

서류 광탈에 굴하지않고, 계속해서 도전한 결과
팀원 9명정도(개발자는 3명)의 소규모 스포츠 관련 스타트업에 백엔드 개발자로 합격하게된다.

그때 당시 CTO 얘기로는 자기증명에 미친사람 같아보여서 뽑았다고...

돈받고 개발을 할 수 있다는 사실 하나만으로도 너무나 기뻤던 순간이었다, 드디어 대망의 첫 출근 날

제대로 된 소프트웨어가 단 1도 없었다.

그래도 MAU가 4~5만정도 되는 어플이여서 당연히 서버가 있다고 생각했었는데..

• 백엔드 서버 없음
• firestore를 DB로 사용하고 있음. 근데 매우 느림
• React로 구현된 버그 투성이 CMS

제일 중요한건

어플이 구동되는데 7초나 걸렸다.

심지어 CMS를 구축했던, 내가 입사했을 당시 퇴사한 이전 개발자는

"나는 최선을 다했지만 정말 바빠서 이렇게 만들었다는걸 이해해주게나"

라고하는 빡치지 아니할 수 없는 인수인계 페이퍼 단 1장과 함께
정상 구동하는 시간보다 죽어있는 시간이 더 많은 CMS를 남기고 떠났다.
(이후로 나는 절대 이런 개발자는 되지 말아야겠다고 다짐하게 해준 아주 좋은 경험이었다.)

개발 공부할때도 12시간 넘게 공부한적이 많아서 야근하는게 그렇게 힘들진 않았지만,
개판쳐놓은 코드를 보면서 화가 치밀었던 기억이 난다.
(30%쯤 코드를 뒤집어 놓았을때였던가.. 다시 만드는게 빠르다고 판단, 결국 새로운 시스템을 다시 구축했다.)

역시 신입은 CMS/어드민 패널 개발이 최고라고 했던 이유를 알것 같다.
서비스 전체적인 프로세스나, 데이터 구조부터 시스템 전반을 금방 습득하게되었다.

---

😱 큰 힘에는 큰 책임이 따른다

나는 큰 힘이 없었는데, 왜...
혼자서 맨땅에 서버만들고 DB 마이그레이션까지

나는 3주 정도 믹서기에 갈려가는 채소처럼 비즈니스 팀원들과 소통 및 개발,
이전보다 훨씬 안정적이고 사용하기 편한 CMS가 완성되었다. (그냥 내가 만든거라 그렇게 느껴졌을수도)

CMS가 완성되고 난 뒤에 한숨 놓는가 싶었지만, 계속해서 눈에 밟히는..
구동하는데만 7초가 걸리는 어플리케이션.

원인이야 당연했다. firestore는 index 기능이나 쿼리능력이 너무 부실하고,
백엔드 서버가 따로 없어서 데이터 처리를 전부다 React Native 사이드쪽에서 처리하고 있었다.

결국 내가 해야할일은...

하나, 4~5만건 정도의 데이터를 새로운 DB에 마이그레이션 하기

둘, 백엔드 서버 구축하고 배포하기

제일 먼저 해야할일이 DB 선정이었는데,

• 스타트업이다보니 데이터 구조가 빈번하게 바뀜
• 트래픽이 폭발할때를 대비(희망회로) 확장이 쉬운 DB
• 위치 인덱스(Geo Location Index)가 필요함
• NoSql중에서는 Mongodb가 레퍼런스 및 접근성이 좋아서 결정

DB 선정 후에는 바로 Express로 서버 구축 후에 MongoDB와 연결시키고,
어플에서 사용해야할 API 구축 등등 다시 믹서기에 몸이 갈리는 나날이 계속 되었다.

마지막에는 firestore에서 Mongodb로 마이그레이션하는 일이 남았었는데,
서비스 특성상 데이터 하나하나가 엄청나게 중요한 회사 자산이었다.

그래서 마이그레이션 중 일어나는 데이터 유실은

절대로 절대로 일어나서는 안되는 일! 하지만

이 시기에 겨우 실무 경력 단 3개월차였던 나...

사실 일하면서 몸이 갈리는것보다, 매일매일 데이터가 몇개라도 날아가면 어떻게하지,
아니 수십개, 수백개가 날아가서 서비스에 장애가 생기면 어떡하지 이런 부담감 때문에 잠들기가 힘들었던 기억이 난다.

제일 먼저 구글링해본것이 firestore를 마이그레이션하는 툴의 존재 유무였고(하지만 있을리가 없지 ㄹㅇㅋㅋ)

그 다음부터는 if문과 try/catch문이 엄청나게 많은 자작 DB 마이그레이션 모듈 그리고
firestore의 데이터와 Mongodb의 데이터가 완벽하게 일치하는지 검사해주는 API를 만들기 시작했다.

그리고 대망의 DB 이사하는날

마이그레이션 도중에 결제나 다른 유저 데이터가 생성되면, DB간 동기가 깨질것 같아서
(지금이라면 조금 더 센스있게 처리했을수도 있겠지만, 실무 3개월따리에게는 이것이 최선이였다.)
정확히 3시간정도 유저가 어플을 사용하지 못하도록 막아놓고, 마이그레이션을 시작했다.

마이그레이션 모듈과 데이터 체크해주는 API를 개발하면서,
계속해서 예외 케이스나 예상치 못한 이슈들이 튀어나왔기 때문에
수십수백번 마이그레이션을 테스트 했음에도 불구하고 불안하기는 매한가지였다.

다들 평온한데 나만 벌벌 떨고있었던 사무실 분위기가 아직도 생각난다.
(아마 개발자가 많지않았기 때문일것..)

그렇게 엄청난 부담감에 정신이 나갈것같았던 DB 마이그레이션건은
5~6건의 데이터 유실과 함께 성공적(?)으로 마무리되었고,
백엔드 서버의 탄생으로 인해 어플 초기 구동속도는 7초에서 0.7~1초로 줄어들게되었다! 😇
(유실된 데이터는 다행히 수작업으로 복구 가능했다.)

7초 걸리던 로딩이 1초로 변모했을때의 그 짜릿함은 아직도 잊을 수 가 없다.
마이그레이션도 성공적으로 마무리했고, 백엔드 서버도 배포완료. 그렇게 앞으로는 평화로운 개발 라이프일줄 알았지만....

---

🔥 개발팀의 진화 그리고 트래픽 폭주

애자일을 통한 팀원간 개발 프로세스의 진화
그리고 마케팅 팀원의 영입으로 인한 서버 폭발

이후에 개발팀에 프론트엔드 신입 개발자 1명이 새로 들어오게 되었고,
나는 주로 백엔드 개발을하면서 남는 시간이 있으면
새로운 개발자와 페이지를 나누어서 협업하는 형태로 작업을하게 되었다.

문제는 팀원은 늘어나는데 예전처럼 데드라인만 보고
급급하게 개발하는 습관 때문에 팀원간 협업 문제가 아주 많았다.

간단한 예를 들면

기획자 : 디자이너님 "물고기"를 디자인해주세요.
디자이너 : 상어를 디자인함
나(백엔드 개발자) : 고래를 개발함(이건 물고기도 아닌데?)

이렇게 각자 생각한게 다른 상태에서 개발 및 디자인이 이뤄지고,
배포전 테스트단계에 들어서면, 결국 다시 기획부터 뒤집어엎는 상황이 발생된다.
그러면 배포날짜는 미뤄지고, 일하는 사람들은 더 갈려가고...

팀원들 모두 스트레스는 받고있으면서, 개선을 외치는 사람이 없었기 때문에
평소 관심 있었던 애자일에 대해서 겉핥기말고 깊숙이 공부한뒤에
PPT로 준비해서 애자일이란 어떤 "생각"을 뜻하는것인가를 팀원들에게 발표했다.
이후에 협업프로세스는 이렇게 바뀌었다.

• 애자일을 적용해도 팀원간 미스 커뮤니케이션은 존재할 수 있음.
  그럴때 빨리 수습하려면 애초에 한번 업데이트할때 작업량이 너무 크면 안됨.
• 1주일에 핫픽스를 제외한 정식 배포를 최소한 2번,
  작업량이 클 수 밖에 없는 업데이트는 작은 업데이트하고 남는 시간을 활용하여 개발,
  배포 날짜를 멀리봄
• 미스 커뮤니케이션 최소화를 위해서 플로우차트를 활용,
  기획자 디자이너 개발자가 플로우차트를 보고 서로 생각이 일치하는지 확인

이렇게 우리 팀에도 애자일 프로세스가 확립하게 되는 순간이었고,
이전보다 훨씬 빠르고 정확한 서비스 업데이트가 이루어졌다. (스스로 엄청나게 뿌듯했었다.)

---

한편 최초의 백엔드 서버 배포는 우리가 흔히아는 EC2(인스턴스 컴퓨터)를 사용해서,
깃으로 코드를 업데이트하고 PM2라는 Nodejs 프로세스 관리툴로 실행시켜놨었다.

근데 PM2 자체에 자잘한 이슈도 많고, 깃허브로 pull받고 다시 배포하는게 번거로웠고,
오토스케일링이 되지않는 문제도 있어서

서버를 컨테이너 기반 end to end로 관리해주는 구글 AppEngine으로 갈아타게 되었다.
(AWS의 Elastic Beanstalk와 비슷함)

AppEngine으로 서버를 교체한 이후로는 배포주기도 훨씬 빨라졌고, 버그 핫픽스도 훨씬 수월하게 이뤄지게 되었다. 그런데..

실무 7~8개월차정도 되는 어느날이었다. 퇴근길 지하철에서 우리 어플을 보고있었는데,
갑자기 하얀화면이 뜨는게 아니던가? 일시적인 현상이라고 생각했지만,
아무리 앱을 리로드해도 정상작동을 하지 않았다. 그리고 날아오는 슬랙 메세지 하나.

애널리틱스를 봤는데 갑자기 사용자가 폭주하고있다. 그래서 서버에 문제가 있는것같다.

우리팀에 마케팅 팀원이 합류하게되었고, 처음으로 온라인 마케팅에 힘을 쓰던 시기였는데 그 때문이었을것이다.

Auto Scaling을 걸어놨음에도 불구하고, 트래픽에 반응해서 계속해서 늘어나다가 max sacling에 막혀
더 이상 Scaling 될 수 없었던것이 원인이었다. 현재 큰 기업에서 일하고 있는 개발자에게는 너무나 커여운 수치겠지만,
당시 1주일 사용자가 10만명이었던걸로 기억한다 (평소에는 1만).

당장 퇴근길 지하철에 내려서 회사로 향했고, 어떻게든 서비스는 실행되어야했기 때문에,
급한 불 끄는 느낌으로 사용하고있는 서버tier를 몇단계 올려놓고 퇴근을 했었다.
문제는 사용자 빅웨이브가 지나간 뒤에 서버비용이었다.

무려 평소 서버비용의 10배 가까이 나와있던것이 아닌가!

외제차랑 교통사고나면 이런느낌인가? 싶었음

원인을 알아보니

• AppEngine은 애시당초 Sass라 Tier가 올라가면 올라갈수록, 트래픽이 많으면 많을수록 기하급수적으로 비용이 상승함
• Scaling 되었다가, 트래픽이 잦아들면 자동으로 죽어야하는데,
  생각보다 그렇게 센시티브하게 반응하지 않아서 한번 ScaleUp 되었다가 ScaleDown이 잘 안됨

회사 수익규모를 봤을때 AppEngine을 계속 사용하기에는 무리가 있었기 때문에,

App Engine을 직접 흉내내서 사용하면 어떨까?라는 생각이 들었다.

App Engine에 대한 설명을보니 결국 컨테이너라는 사실을 확인한 후 나는
Docker 더 나아가서 쿠버네티스에 관심을 가지게되는데...

저의 기구한 개발인생을 공유하면 많은 사람들이 참고했을때
도움이 되지않을까라는 지인의 권유로 시작해 작성한 글입니다.
굉장히 미숙한 글이지만, 도움이 되었다면 2편도 열심히 작성해보겠습니다. 다들 새해복 많이받으세요 😇

다음편 2년동안 스타트업에서 구른 백엔드 개발자 2탄

• 절대 죽지않는 좀비 서버를 만들자
• TDD를 통한 심리적 안정감
• 개발팀의 데이터로 비즈니스팀에게 도움을 ^DevOps