처음 개발을 배울 때 가장 흔히 듣는 말 중에 하나는 "확장성 있는 설계" 입니다. 말 그대로 나중에 변경이 있을 때 코드를 최소한으로 변경하자! 라는 건데요.
이 말이 틀린 것은 아니지만, 지금 당장 살아남아야 하는 스타트업들에게 얼마나 도움이 되는 지 한 번 살펴보겠습니다.

100만명의 아키택쳐

많은 개발자들이 내가 만든 시스템이 수많은 사용자들에게 사용되기를 바랍니다.
"아, 내가 만든 시스템이 카카오톡만큼 놀라운 사용자를 모았으면 좋겠는걸."
특히 사용자수가 정해져 있는 B2B 사업에 비해 B2C 비즈니스 쪽은 소위 "트래픽이 몰리는"현상을 고려해서 개발을 하는 경향이 있죠.

이런 부푼 꿈을 안고 우리는 어마어마한 아키택쳐를 그립니다.

대세니까 프론트엔드와 백엔드를 구분하고, 각 요청은 큐를 사용하며, 자기완결성을 가지는 MSA로 설계한다. 효율성을 위해 도커와 쿠버네티스를 도입하고 빌드 자동화를 위해 CI/CD는 기본이며 캐시는 레디스를 쓰고....

그런데 우리 냉정하게 생각해 봅시다. 듣도 보도 못한 회사에서 생전 처음 내 놓는 첫번째 버전의 프로덕트가 카카오톡, 아니 네이트온, 아니 일반 기업의 사내 메신저만큼이라도 쓰일 가능성이 있을까요?
대부분은 아닐 겁니다. 부푼 마음을 안고 터무니없이 비싼 EC2를 결제했는데 돌아오는 것은 당일 접속자 3명. 그리고 그 접속자 세명의 정체는 바로 우리 스타트업 멤버 정도일 거에요.

이런 상황에서 백만명을 위한 아키택쳐는 무슨 소용이 있을까요? 사용자 피드백도 없는 상황에서 우리가 나아갈 방향이 어디인 줄 알고 아키택쳐를 설계할까요?

"멋진 아키택쳐"는 "모두가 당연하다고 생각하는 복잡한 시스템을 구축하는 것이 아닙니다. 현재 상황에 맞는 구조가 가장 멋져요.
하루 방문자가 백명도 안 되는 웹사이트는 그냥 구형 PHP에 MySQL을 제공하는 하루 백원짜리 공유 웹호스팅에 올려도 충분합니다. 만약에 방문자가 더 많아져서 동시접속자가 256명이 넘어가면 그 때 고민해도 안 늦어요.

프레임워크에 연연하지 말 것

많은 사람들이 개발 프레임워크에 열광하고, 모든 것을 이루어 줄 꿈의 마법의 도구처럼 생각합니다.
저 또한 그랬죠. 그래서 기술 스택을 선택하는 데 많은 공을 들이곤 했어요.
개발 프레임워크를 선택하는 건 생각보다 단순한 문제가 아닙니다. 프레임워크는 특정 개발 언어로 구현되어 있고, 그 언어를 둘러싼 환경과 프레임워크를 관통하는 철학과 방법론으로 무장되어 있거든요. 단순히 프로그래밍 언어를 바꾸는 것이 문제가 아니라 생태계를 이해하는 것이 중요하죠.

그럼에도 불구하고, 사실 개발 프레임워크는 그다지 중요하지 않습니다. 아니 정확히 말하면, 현재 상황에 맞는 개발 방법론을 선택하는 것은 아주아주 중요하지만, 먼 미래에 대비하기 위해 오버스펙으로 개발 프레임워크를 결정하는 것은 어리석다고 생각합니다.

아주 간단한 정적 페이지 하나를 만드는데 리액트와 웹팩을 써서 빌드한다고 생각해 보면 이게 얼마나 어처구니없는 일인지 알 수 있습니다. 그냥 HTML, CSS, JS 만 있어도 충분하거든요.
반면 훨씬 더 복잡한 웹 앱을 만들 때 Vanilla Stack을 쓴다는 것도 현명하진 않습니다. 개발 생산성이 떨어지니까요.

결국, 현재 프레임워크는 언제든지 상황에 따라 버릴 수 있다.. 라는 것을 가정하는 것이 좋습니다. 지금의 상황에 맞는 기술에 집중하되 결코 집착하지 않을 것, 이게 아마 스타트엄 프레임워크 선정의 첫번째 기준일 거에요.

데이터베이스에 집착할 것

데이터베이스는 이야기가 좀 다릅니다. RDBMS의 스키마는 한 번 만들면 바꾸기가 몹시 어렵습니다.
아 물론 alter문 사용법이 어렵다는 뜻은 아닙니다. 다만 RDBMS에 한 번 데이터가 쌓이기 시작하면, 각 데이터간의 관계성에 따라 스키마를 유연하게 늘리는 것이 굉장히 제약적이 된다는 의미입니다.

따라서 데이터베이스를 설계할 때는 가능한 현재 데이터 아키택쳐가 확장 가능한 지 설계할 줄 아는 것이 핵심입니다. 이는 단순히 개발 기술을 알아서 되는 문제는 아니고요. 당연히 DBA가 꼭 있어야 한다는 뜻도 아닙니다.

사실 데이터베이스 설계를 많이 해 보신 분들은 아시겠지만, 데이터베이스 설계의 스킬은 "도메인을 얼마나 이해하는가"에 달려있습니다. 즉, 내가 만들 시스템의 데이터 특성이 어떤가.. 를 가장 잘 이해하는 사람이 데이터베이스 설계를 가장 잘 합니다.

로직은 가장 약하게 커플링할 것

우리가 워터폴 방식으로 뭔가를 만든다는 의미는, 완성품의 모양이 다 결정되어 있다는 뜻입니다. 보통 대규모 시스템을 만들 때 많이 써요.

스타트업은 이야기가 다릅니다. 대형 선박을 건조해서 나가는 형태라기보다는 뗏목을 타고 나간 다음 구멍 나면 메꾸는 식으로 시스템이 만들어집니다. 여기 저기 땜질한 자국이 있고 볼품도 없어요. 여차하면 판자에 긁히기도 하고요.
대신 이렇게 힘겹게 돈을 벌어와서 조금 더 좋은 배를 만들어나가는 식으로 발전하는거죠.
요새 애자일은 "대충 한다"의 동의어처럼 들리는 경우가 많아서 이런 걸 애자일이라고 부르고 싶지는 않습니다.

간단하게 "쿠폰 할인 시스템"을 만든다고 생각해 보겠습니다. 처음에는 "모두에게 쿠폰" 이었다가 어느 순간 "일정 기간 쿠폰", "단골에게 쿠폰"이라는 개념으로 확장해 나갑니다.

대형 시스템에서는 이런 시스템의 변화를 관리하기 위해 "인터페이스와 구현체의 분리"라는 전략을 씁니다.
물론 이런 전략도 훌륭합니다만, 저는 스타트업은 더 땜질 식의 개발 방법론이 어울린다고 생각합니다. 왜냐면 인터페이스와 구현체를 분리하는 전략은 우선 약간의 번거로움, 그리고 구현체가 인터페이스 형태에 종속되어 버리는 단점이 있기 때문이에요.
실제로 개발을 해 보신 분은 아시겠지만, 이상적인 논의와 다르게 인터페이스 기반 개발 전략은 생각보다 현실에 잘 맞지 않습니다. 잘 생각해보면 각 쿠폰마다 필요한 매개변수가 다르거든요.
"모두에게 쿠폰"은 아무런 매개변수가 필요없지만 "일정 기간 쿠폰"은 "날짜"라는 매개변수가, "단골 쿠폰"은 사용자 정보라는 매개변수가 필요합니다.
하나의 인터페이스 안에서 이를 처리하면 "모두의 쿠폰"에는 전혀 필요없는 "날짜"와 "사용자 정보"도 알고 있어야 하고, 구현체는 전혀 쓰지 않는 매개변수를 들고 있어야 합니다. 뭔가 이상하지 않나요?

대신 저는 "모두에게 쿠폰", "일정 기간 쿠폰", "단골 쿠폰" 기능은 간단한 클래스나 함수 기반으로 작성하는 것을 추천합니다. 그냥 if로 막 분기하는거죠.
지저분하다고요? 뭐 어떻습니까? 잘 돌아가는걸요. 쿠폰의 종류가 늘어나면 if나 switch가 하나 늘어나는 것 뿐이고, 쿠폰이 없어지면 해당 구문을 주석 처리해 버리면 그만입니다. 언제나 넣었다 뺐다 할 수 있게요.

이런 구현의 가장 큰 단점은 "로직이 분산"된다는 겁니다. "단골"의 개념을 놓고 봤을 때 "단골 쿠폰"에서도 "단골"이라고 부르고, "자주 접속하는 회원"에 대한 추가 포인트 헤택에서도 "단골"이라고 부르는데 두 "단골"의 개념이 다르다면 곤란하다는 뜻이죠.
그래서 저는 이런 식으로 함수 기반으로 개발을 할 때 "도메인"만 정하자..라는 규칙을 보통 씁니다. 하나의 개념은 한군데 모여있도록 말입니다. 이런걸 고급진 용어로 DDD라고 부릅니다.

최선은, 그냥 개발하지 않는 것

무언가 기능이 필요할 때 무작정 코드를 짜는 건 하수입니다. 고수는 코드 대신 다른 서비스를 쓸 수 있는 지 먼저 확인해야 합니다.
굳이 설문조사 기능을 또 만들어야 할까요? 구글 폼이나 네이버 폼이면 충분하지 않나요?
로그인은 어떤가요? 우선 구글 로그인으로만 대체하는 건 어때요? 나중에 네이버든 카카오든 늘려가는거죠.
이런 식으로 Sass를 쓰면 좋은 점이 많습니다. 서비스 자체는 서비스 프로바이더가 관리하기 때문에 우리가 내부적으로 뭔가 번거로운 서버 관리나 로직 변경 등을 신경 쓸 필요가 없어요. 게다가 우리에게 가장 소중한 것, "시간"을 아낄 수 있게 되죠.

기술 부채 메모장

이부분이 어찌보면 가장 중요할 지도 모르겠습니다. 제가 위에서 나열한 내용들을 가만히 보면, 소프트웨어 공학에서 하지마! 라고 한 것들만 잔뜩 써 있다고 느끼실 수도 있습니다.
맞습니다. 저는 개발을 할 때는 늘 기술부채와 비즈니스의 트레이드오프를 계산해야 한다고 생각하기 때문에, '초창기에는 기술 부채를 짊어지더라도 비즈니스 스피드를 올린다' 라는 점에 포커스를 두고 말씀드리는 겁니다.
반면 시장과 시스템이 성숙도가 높아지면 당연히 이렇게 개발하면 안되겠죠. 속도보다 안정성이 중요한 시기가 왔을 때는 방법론을 바꿔야 합니다.
그 때를 위해서 우리가 준비해야 할 것은 바로 "기술 부채 메모장" 입니다. 기술 부채라는 건 "지금의 속도를 위해서 희생한 품질"을 말합니다. 이를 꼼꼼하게 어딘가에 기재해 두지 않으면, 나중에 안정성이 필요한 시기가 왔을 때 와르르 무너지게 됩니다.
해결방법까지는 안 써놔도 좋습니다. 지금의 해결책은 미래에는 쓸모없어질 가능성도 많으니까요. 다만 "어떤 상황에서는 어떤 이슈가 있는데 이 부분은 추후 어떤 조건이 만족되었을 때는 개선해야 한다."라는 것을 반드시 적어두세요.
테크 리드 혹은 CTO라면 반드시 하셔야 하고, 만약 일반 개발자라도 자신이 하나의 시스템을 맡고 있다면 반드시 해야 합니다.
당연히 퇴사하면 그만이지만 남겨진 사람을 위해서라도요.