좋은 소프트웨어는 서두를 수 없다: 시간이 필요한 이유

Flask가 1.0 버전에 도달하기까지는 8년이 걸렸습니다. SQLite는 2000년부터 꾸준히 개발되고 있고, 지금도 의미 있는 개선이 이어지고 있습니다. Linux 커널은 30년이 넘었지만 나이를 먹을수록 오히려 더 나아지고 있다고 해도 과언이 아닙니다. 반면 VC 투자를 받은 평균적인 스타트업은 18개월 안에 성과를 보여주거나, 못 보여준 이유를 설명해야 합니다.

좋은 소프트웨어를 만드는 데 실제로 걸리는 시간과 우리가 기대하는 시간 사이의 간극이 점점 벌어지고 있습니다. 빨리 출시하라는 압박 자체가 잘못된 것은 아닙니다. 하지만 그 압박은 인내를 야망 부족으로 보는 문화를 만들어냅니다. 결국 오래 살아남는 프로젝트들은, 조용히 본질을 다지는 몇 년 동안 ‘느리다’는 평가를 받게 됩니다.

‘하룻밤 사이의 성공’이라는 신화

소프트웨어에서 ‘하룻밤 사이의 성공’으로 보이는 사례 대부분은 긴 배경을 가지고 있습니다. React는 오픈소스로 공개되기 전에 Facebook 내부에서 1년 넘게 쓰였습니다. Rust는 1.0에 도달하기까지 7년 동안 개발되었습니다. PostgreSQL은 1986년 연구 프로젝트로 시작했고, 2010년대가 되어서야 실무에서 기본으로 선택되는 데이터베이스가 되었습니다. 거의 30년 동안 조용하고 꾸준하게 개선된 결과입니다.

갑자기 등장한 것처럼 보이는 것은 대개 개선이 누적되다가 사람들의 눈에 띄는 임계점을 넘은 결과입니다. 소프트웨어는 그동안 계속 좋아지고 있었습니다. 다만 부정할 수 없을 만큼 충분히 좋아지기 전까지 사람들이 주목하지 않았을 뿐입니다.

Flask의 창시자 Armin Ronacher도 이 점에 대해 직접 글을 쓴 적이 있습니다. Flask는 2010년 만우절 농담으로 시작되었습니다. 그런데 거의 우연처럼 진지한 프로젝트가 되었죠. 엣지 케이스를 고치고, 문서를 개선하고, API를 다시 생각하는 점진적인 작업이 수년간 이어졌고, 결국 가장 인기 있는 Python 웹 프레임워크 중 하나가 되었습니다. 그 어떤 해도 헛되지 않았습니다. 매년 쌓인 작업이 기반을 더 단단하게 만들었으니까요.

소프트웨어에 줄일 수 없는 시간 요소가 있는 이유

사람을 더 투입하거나 더 열심히 일한다고 해서 빨라지지 않는 문제들이 있습니다. Fred Brooks는 1975년 The Mythical Man-Month에서 이 점을 짚었고, 그 핵심 통찰은 지금도 유효합니다. 소프트웨어 개발의 특정 부분은 병렬화할 수 없고 순차적으로 진행될 수밖에 없습니다.

• 문제 도메인 이해하기. 어떤 문제 공간은 한동안 직접 부딪혀 보기 전까지는 완전히 이해할 수 없습니다. 어떤 소프트웨어든 첫 버전에는 처음의 가정이 그대로 담깁니다. 두 번째 버전에는 첫 번째에서 배운 것이 담기죠. 진짜 이해는 반복을 통해 얻어지고, 반복에는 시간이 걸립니다.
• API 설계와 안정성. 좋은 API는 실제 사용을 통해 만들어집니다. 진공 상태에서 완벽한 API를 설계할 수는 없습니다. 실제 사용자가 실제 엣지 케이스에 부딪혀 봐야 합니다. 서둘러 1.0을 내놓은 라이브러리들은 초기 설계 결정을 몇 년 동안 후회하곤 합니다.
• 엣지 케이스와 안정화. 기능의 앞 80%는 전체 시간의 20%면 만들 수 있습니다. 나머지 엣지 케이스, 에러 처리, 플랫폼별 문제들이 나머지 80%의 시간을 차지합니다. 이 비율은 게으름 때문이 아니라 소프트웨어를 안정적으로 만든다는 것의 본질적인 특성입니다.
• 커뮤니티와 생태계. 도구는 문서, 튜토리얼, 플러그인, 그리고 질문에 답해 주는 커뮤니티가 생기기 전까지는 진정으로 유용해지지 않습니다. 이런 생태계는 인위적으로 만들어낼 수 없고, 시간이 지나면서 자연스럽게 자랍니다.

인위적인 조급함이 낳는 피해

‘빠르게 움직이고 무엇이든 깨뜨려라’는 제품-시장 적합성을 찾던 소셜 네트워크에게는 합리적인 구호였을지 모릅니다. 하지만 인프라, 개발자 도구, 데이터베이스, 그리고 다른 사람들의 시스템이 의존하는 모든 것에는 끔찍한 철학입니다. 기반 소프트웨어를 서두르면 깨진 것들이 복리처럼 불어납니다.

기반이 감당할 수 있는 속도보다 빨리 성장하려다 무너지는 유망한 오픈소스 프로젝트를 여러 번 지켜봤습니다. 패턴은 예측 가능합니다. 프로젝트가 인기를 얻으면 메인테이너는 기능을 빨리 내놓으라는 압박을 받고, 품질이 떨어지고, 기여자들은 번아웃에 빠지고, 사용자들은 더 안정적인 대안으로 떠나죠. 아이러니하게도 속도를 늦췄다면 오히려 더 멀리 갔을 겁니다.

오래가는 프로젝트는 가장 빨리 출시한 프로젝트가 아닙니다. 초기에 좋은 결정을 충분히 내려서 나중에 모든 걸 다시 쓸 필요가 없었던 프로젝트입니다.

기술 부채는 지저분한 코드만을 뜻하지 않습니다. 시간에 쫓기며 내린 결정이 앞으로의 가능성을 제약하는 것을 말합니다. 빨리 출시하려고 택한 지름길마다 앞으로의 모든 변경에 세금이 붙습니다. 어떤 지름길은 택할 가치가 있습니다. 다만 누군가 데드라인을 임의로 다음 주 화요일로 정했다는 이유가 아니라, 의도적으로 택해야 합니다.

실무에서 인내는 어떤 모습인가

소프트웨어 개발에서의 인내가 그냥 느리게 움직이는 것을 뜻하지는 않습니다. 무엇을 만들지 신중해지고, 일이 실제로 얼마나 걸리는지 솔직해지는 것을 뜻합니다. 제가 보기에 잘 통했던 방법이 몇 가지 있습니다.

• 일찍 출시하되, 약속은 천천히. 피드백을 받을 수 있도록 소프트웨어를 빨리 사용자에게 내놓으세요. 다만 안정적인 API로 무엇을 약속할지는 아주 보수적으로 정하세요. 0.x 버전을 넉넉하게 쓰고, 언제든 바뀔 수 있다는 점을 분명히 하세요.
• 기능에 ‘아니오’라고 말하기. 추가하는 모든 기능은 영원히 유지보수해야 할 대상입니다. 가장 좋은 프로젝트들은 범위에 대해 확고한 입장을 가지고 있습니다. SQLite는 하지 않을 일을 명시적으로 나열해 두는데, 그런 절제 덕분에 세계에서 가장 많이 배포된 데이터베이스가 되었습니다.
• 기반에 투자하기. 문서화, 테스트, 에러 메시지, 성능은 화려하지 않지만 복리로 쌓입니다. 문서가 잘 정리되어 있고 테스트 스위트가 탄탄한 프로젝트는, 문서가 엉성한 프로젝트가 1년 차에 낼 수 있는 속도보다 3년 차에 더 빠르게 움직일 수 있습니다.
• 메인테이너의 에너지 지키기. 번아웃은 오픈소스 프로젝트를 죽이는 1순위 원인입니다. 지속 가능한 페이스가 스프린트 속도보다 중요합니다. 일주일에 20시간 집중해서 5년 동안 일하는 메인테이너가, 6개월 동안 주당 80시간씩 일하다가 사라지는 사람보다 훨씬 많은 것을 만들어냅니다.

스타트업 속도의 함정

스타트업은 피할 수 없는 긴장에 직면합니다. 살아남으려면 빨라야 하지만, 너무 빠르게 움직이면 규모가 커질수록 부담이 되는 취약한 시스템이 만들어집니다. 이 균형을 잘 잡는 회사들은 두 종류의 속도를 구분하는 경향이 있습니다.

반복의 속도 — 아이디어를 얼마나 빨리 검증하고, 사용자 피드백을 받고, 방향을 바꿀 수 있는지. 이것은 최대화해야 합니다. 짧은 사이클, 빠른 프로토타이핑, 기꺼이 버리는 자세가 필요합니다.

약속의 속도 — 아키텍처 결정, 공개 API, 데이터 모델을 얼마나 빨리 확정하는지. 이것은 최소화해야 합니다. 가능한 한 되돌릴 수 있는 상태를 유지하세요. 되돌릴 수 없는 결정을 미룰수록, 마침내 결정할 때 더 많은 정보를 갖게 됩니다.

대부분의 스타트업이 저지르는 실수는 이 둘을 혼동하는 것입니다. 기능을 반복하는 속도만큼 빠르게 아키텍처에 약속해 버리고, 그다음 2년 동안 성급한 결정의 대가를 치르죠.

살아남은 프로젝트에서 배우기

우리가 가장 많이 의존하는 소프트웨어 프로젝트들에는 공통점이 있습니다. 모두 한때 ‘느리다’는 평가를 받았다는 것입니다. PostgreSQL은 MySQL이 빠르고 거칠게 가던 시절 지루한 선택지였습니다. Python은 ‘너무 느리다’는 말을 들었고, Perl이 실용적인 선택이었습니다. Git은 일반 사용자가 쓸 만해지기까지 몇 년이 걸렸습니다.

이 프로젝트들이 가졌던 것은 시간이었습니다. 실수하고, 그로부터 배우고, 단단한 무언가를 쌓을 시간이요. 이들은 1년 차부터 모든 사람에게 모든 것이 되려고 하지 않았습니다. 자기 핵심 목적에서 탁월해지는 데 집중했고, 그 탁월함에 필요한 만큼의 시간을 기꺼이 들였습니다.

다음에 어떤 프로젝트가 ‘너무 오래 걸린다’며 답답하게 느껴진다면, 여러분이 가장 의존하는 것들을 떠올려 보세요. 운영체제, 데이터베이스, language runtime, 버전 관리 시스템 모두 누구의 예상보다 오래 걸렸습니다. 바로 그래서 지금 잘 작동하는 것입니다.

어떤 것들은 그냥 시간이 필요합니다. 가장 좋은 대응은 그 현실과 싸우는 것이 아니라, 이를 전제로 한 시스템, 팀, 기대치를 만드는 것입니다.