당신이 의존하는 대부분의 소프트웨어는 급하게 대충 만들어진 것들이다
Most of the software you rely on was hacked together fast
핵심 요약
성공한 거대 IT 기업들도 초기에는 급하게 만든 조잡한 코드로 시작해 나중에 규모에 맞춰 재설계했다는 내용입니다.
- 초기 개발 속도 — 성공한 서비스들도 처음엔 조잡하게 시작함
- 기술적 부채 해결 — 수요가 폭증한 뒤에야 제대로 된 아키텍처로 재설계함
- 성공의 핵심 요인 — 코드 품질보다는 타이밍, 마케팅, 투자가 더 중요했음
- 엔지니어의 역할 — 완벽한 코드보다 제품의 시장 적합성이 우선시됨
일단 보기 흉하게 출시하고, 실제로 중요해졌을 때 제대로 다시 만들었다.
트위터는 작은 팀이 빠르게 움직일 수 있었기 때문에 루비 온 레일즈(Ruby on Rails)로 시작했다. 그러다 1년 만에 사용자가 약 1,450% 증가했고(닐슨 조사 결과 120만 명에서 1,820만 명으로 증가), 레일즈는 무너졌다. 그게 바로 "실패의 고래(fail whale)"가 탄생한 배경이다. 수요가 확실해지자 그들은 핵심 기능을 스칼라(Scala)를 사용하는 JVM으로 옮겼다.
인스타그램은 2010년 2인 팀이 파이썬/장고(Python/Django)로 시작했으며, 맥북 프로보다 성능이 낮은 단일 머신에서 돌아갔다. 첫날 25,000명이 가입했고 서버는 몇 시간 만에 다운되었다. 그 후 3명의 엔지니어만으로 하부 구조를 재설계(Postgres 샤딩, 캐싱, 스테이트리스 서버)하여 1년 만에 1,400만 명의 사용자로 확장했다.
페이스북은 PHP로 운영되었다. 출시하기엔 좋았지만 규모가 커지자 CPU에 엄청난 부담을 줬다. 그래서 그들은 PHP를 C++로 컴파일하는 힙합(HipHop)을 만들었고, 이후 구형 PHP보다 9배 이상의 요청 처리량을 제공하는 JIT 엔진인 HHVM으로 대체했다. 그들은 코드베이스를 버리는 대신 언어 자체를 확장 가능하게 만들었다.
아마존은 2002년경까지 모놀리식 구조였으나, 베조스가 모든 팀에게 서비스 인터페이스를 통해 데이터를 노출하도록 지시했다. 예외도, 뒷문도 없었다. 그 고통스러운 재구축 과정이 AWS의 기반이 되었다.
넷플릭스는 2008년 데이터베이스 손상으로 3일 동안 DVD를 배송할 수 없게 되기 전까지 자체 데이터 센터에서 운영되었다. 그들은 약 7년을 재구축에 쏟았다.
이 글이 즐거웠고 AI 코딩에 대한 최신 정보를 얻고 싶다면, 가장 큰 무료 AI 코딩 뉴스레터인 ijustvibecodedthis.com에 가입하세요. 매주 글을 씁니다 :)
