'스타트업 다운것' 이라는 편견 부수기, 서비스 기술 스택 전환기

개요

스타트업에 합류한 후 테크리드로써 최종 결정권자가 되어 많은 선택에 대한 고민을 했는데 그럴때마다 나의 머리속에 '스타트업 다운가?' 라는 필터가 하나 자리잡아 있었다. 스타트업은 큰 기업들이 못 하는것을 해내는 곳이다, 빠른 의사결정과 개발, 짧은 배포 주기등 결국 속도라는 장점을 가지는 조직이다. 그래서 스타트업이면 기술 스택을 최대한 단순하고 기술적으로는 안티 패턴 일지라도 빠른 개발을 위해 퀄리티를 포기해야 하는 그런 편견이 있는것 같다, 하지만 결국 편견이고 본질이 아니라는것을 깨닫았다, 스타트업에서도 모범사례를 추구해야한다.

 

하지만 내가 말하는것은 단순한 기술적 사치와 빅테크에 버금가는 기술 퀄리티가 아니다. 나 또한 아직 PMF를 찾지 못한 서비스가 미래를 내다보고 미리 대용량 트래픽을 위한 아키텍쳐를 설계하는것에 투자하는것은 미친짓이라고 생각한다. 하지만 주먹구구식으로 만들어진 코드와 아키텍쳐들이 조금씩 생산성을 갉아먹는다면 얘기는 달라진다.

 

대용량 트래픽, 성능에 대한 얘기를 하고자 하는것이 아니다, 생선성과 확장성을 대비한 설계에 대해서 말하고 싶다.

 스타트업의 성장 방식

린스타트업에서는 스타트업은 빠른 실험과 피드백, 지속적인 학습과 피벗을 통해서 성장한다고 말한다.

그리고 대부분 성장을 하기 위한 일들은 기획에서 담당한다, 그런데 개발팀에서 매번 '안돼요' 한다면? 또는 안된다고는 하지 않지만 무엇갈 변경하기 너무 어려운 구조에서 억지로 무엇가를 바꿔서 매 배포마다 알 수 없는 오류를 고치는것에 시간을 투자하고 새로운 기능 개발의 앞길을 막게 된다면? 이것은 스타트업의 성장에 도움이 되는 방식일까? 오히려 기획팀은 열심히 하는데 개발팀이 병목이 되는것이 아닌가?

 

단기적으로는 눈 앞의 기능을 개발하기 위해 최대한 빠르게 개발할 수 있는 방법을 찾고 마구잡이로 테이블에 DDL을 하고 비슷한 역할을 하는 데이터들을 마구잡이로 만들어내면서 하나의 기능을 개발하는것이 빠른 방법일 순 있다. 하지만 이것이 장기적으로 도움이 되는가?

 

언젠간 더 이상 확장할 수 없을만큼 기술부채가 커져있을것이고 기획팀에 '안돼요'를 말하는 횟수가 늘어나거나 치명적인 버그가 터지거나 별로 큰 트래픽이나 데이터도 아닌데 처리시간이 너무 높아져 3초에 유저가 이탈해버리는 UX를 제공하게 된다, 필연이다.

 그래서 나는 어떻게 했냐?

내가 합류했을때 상황은 어드민에서 특정 데이터 조회하는데 3분이 넘는 시간이 걸리고 있었고 자꾸 알 수 없는 버그들이 터지고 있었다.

그리고 테이블이 80개였다, 사실 다들 80개면 많은건가? 라고 반응하던데 난 과도하다고 생각한다. 소개팅 서비스라는게 그 정도의 비즈니스도 아니고 만약 맞다고 하더라도 분명 이 테이블의 80%는 RDB를 사용해야하는 이유가 없다고 생각했다.

누가 RDB에 때려넣으라고 칼 들고 협박함?

일단 난 팀의 히스토리를 잘 모르기 때문에 슬랙부터 뒤져봤다, 이미 이 팀은 현재의 문제에 대해서 충분히 인지하고 있고 많은 시도를 해 봤지만 실패를 했다는 사실을 알게 되었다. 그리고 이 사실은 내가 리팩토링을 해야겠다는 의사결정을 내리는것에 충분한 근거가 되었다.

 

CEO와도 정말 많은 얘기를 했다, 우리팀의 전체적인 생산성과 앞으로 하고 싶은 일들에 대한 확장을 위해서는 장기적으로 리팩토링이라는 선택지를 항상 고려해야한다고 설득했고 CEO도 충분히 이해했다.

 

하지만 전체 리브랜딩을 진행하면서 한달만에 배포까지 마쳤고 앞으로 더 많은것들을 개발해야하는 상황이 되어 버린 나는 리팩토링을 미룬다는 의사결정을 해버렸다, 막상 나도 본격적으로 개발에 참여하고 눈 앞의 태스크를 쳐내기 바쁘다보니 조금은 더 버틸 수 있지 않을까라는 초심을 잃은 생각들을 했다. 그리고 요상한 디비구조를 어떻게든 녹여내서 Spring으로 새롭게 코드를 다 짜고 안정화를 시켜놓은 상태여서 더 그런것 같다. 다행히도 이때 CEO가 리팩토링을 하자고 말해주었다, CEO는 리팩토링 하자 테크리드는 하지 말자 라는 반대의? 상황이 되어버렸다. 많은 대화를 하고 혼자 생각하면서 마음을 다 잡았다, 내가 생각한 리팩토링은 스프린트 하나(2주) 이상을 투자하면 안된다고 생각했다. 하지만 2주안에 모든것을 끝내기엔 너무 스케일이 크고 마무리 할 자신이 없어서 망설였던것 같다.

 

결국 리팩토링을 하자는 의사결정을 하게 되었다, 의사결정에 대한 근거는 다소 경영적인 내용이 포함되어 따로 작성하지는 않겠다.

기술 스택 전환하기

기존의 Django, Python, Celery, MySQl, Redis 스택에서 Spring, Kotlin, MySQL, MongoDB, Redis 스택으로 변경하였다, 기존에 메세지 큐로 사용하던 Celery가 있었는데 당장은 메세지 큐를 사용하지 않기로 하였다. 충분히 멀티 스레드를 이용한 비동기 처리로도 가능한 작업들을 수행하고 있기 때문이였다.

 

기술 스택을 전환하는 이유의 시작이자 마지막은 바로 데이터베이스 리팩토링하기이다, 정규화가 필요없는 데이터들을 N:M 관계로 풀어내고 있었고 기획이 바뀌면서 사용하지 않는 컬럼들과 테이블, 연관관계가 너무 많았다. 그래서 NoSQL을 도입하기로 했다.

 

간단하게 예를 들자면 유저의 성별, 전화번호, 실명, 나이 같은 기본 정보 같은것은 기획에 따라 변하지 않는다, 이런것들은 RDB에 저장하기로 한다. 그리고 유저의 MBTI등의 정보 또는 이상형 정보 같은것들은 기획에 따라 항상 변한다, 트렌드에 따라 소개팅 서비스에 입력하는 정보는 언제가 바뀔 수 있고 유저 피드백을 통해서도 바뀔 수 있다, 이런 데이터들은 NoSQL에 저장하기로 하였다.

 

언어와 프레임워크는 일단 나는 Spring을 좋아하고 익숙하다, 그리고 약타입 언어는 절대 강타입 언어을 이기지 못한다고 생각한다.

또한 엔터프라이즈적으로 필요한 많은 기능을 제공하는 강력한 생태계가 있고 무엇보다 ORM이 장고와는 비교가 안된다.

 

하지만 스프링은 스타트업에 적합하지 않다는 편견을 가진 사람도 많았다. 이런 의사결정을 위해 개발바닥의 영상을 많이 참고하였다, '어떤 언어는 상관없는데 그 팀의 기술리더가 익숙한 기술을 쓰는것', '스타트업이 도대체 뭐길래, 그렇게 제품을 빨리 찍어내야돼? 4드론 러쉬도 아니고',  '스프링 느려가지고 제품이 늦게 나오나? 그러면 5분 일찍 일어나세요' 한마디로 그저 편견이라는 인사이트를 얻게 되었다.

 

아 그리고 Java가 아니고 왜 Kotlin이냐? 나는 자바를 좋아한다, 매우 익숙하다. 하지만 우리팀의 주니어들이 자바를 싫어한다, 이유는 아마 내가 옛날에 자바를 싫어하던 이유와 비슷하지 않나 생각이 든다. 그래서 그런 소소한 니즈를 충족시켜주기 위해 코틀린을 선택하게 되었다.

마무리하며

살짝 내가 하고 싶던 말을 다 못하고 글을 마무리하는것 같은데 자세한 내용은 2024년 회고때 쓰도록 하겠다, 벌써 이 글 쓰는데 1시간이나 투자했는데 얼른 데이터베이스 마이그레이션 코드 짜러 가야한다.

 

데이터베이스 마이그레이션까지 마무리하면 거의 새로운 프로덕트를 만든셈이 된다, 다음글은 성공적으로 많은 데이터들을 마이그레이션한 경험으로 돌아오겠다