해커뉴스에서 302포인트. 수백 개의 댓글. 그리고 핵심 주장은 냅킨 한 장에 들어갈 만큼 간결하다: *좋은 소프트웨어는 필요한 만큼의 시간이 걸린다.*
Flask의 창시자이자 Sentry의 스태프 엔지니어인 아르민 로나허(Armin Ronacher)가 이번 주 자신의 블로그에 "어떤 일은 그냥 시간이 걸린다(Some Things Just Take Time)"라는 제목의 에세이를 발표했다. 몇 시간 만에 이 글은 해커뉴스 상단에 올랐고, 단순히 추천을 받는 것을 넘어 *공감*을 산 드문 게시물 중 하나가 되었다. 개발자들은 로나허의 말에 단순히 동의하는 것이 아니다. 그들은 안도의 숨을 내쉬고 있다.
로나허의 논지: 업계가 인내심에 대한 알레르기를 키워왔다
3월 20일 로나허의 오랜 블로그 lucumr.pocoo.org에 게시된 이 에세이는 소프트웨어 업계가 인내심에 대해 위험할 정도의 알레르기를 키워왔다고 주장한다. Flask, Jinja2, 그리고 최근의 Rye 파이썬 패키지 매니저 같은 오픈소스 프로젝트를 구축하고 유지해온 자신의 경험을 바탕으로, 그는 기만적으로 단순한 요점을 제시한다: 가장 중요한 엔지니어링 작업 중 일부는 스프린트 주기 안에 압축될 수 없다.
로나허는 매 문단마다 AI 코딩 도구를 언급하지는 않지만, 행간의 메시지는 분명하다. "바이브 코딩(vibe coding)"이 실제 마케팅 용어가 된 시대, 스타트업들이 Claude나 GPT를 사용해 주말 만에 MVP를 출시했다고 자랑하는 시대, 엔지니어링 매니저들이 하루당 풀 리퀘스트 수로 성과를 점점 더 측정하는 시대에, 그는 속도가 유일하게 중요한 지표라는 관념에 정면으로 반박하고 있다.
더 빨리 출시하라는 압박에는 실질적인 대가가 따른다고 에세이는 주장한다. 기술 부채가 쌓이는 것은 엔지니어들이 게으르기 때문이 아니라, 그들을 둘러싼 문화가 설계적 사고보다 반복 속도가 우선한다고 결정했기 때문이다. 로나허는 자신의 프로젝트를 증거로 제시한다. Flask가 가장 인기 있는 파이썬 웹 프레임워크가 된 것은 하루아침이 아니었다. 신중한 API 설계, 커뮤니티 피드백, 그리고 무엇을 *만들지 않을 것인가*에 대한 의도적 선택에 수년이 걸렸다.
"속도를 늦춰라"가 테크 역사상 가장 빠른 순간에 신경을 건드린 이유
타이밍이 중요하다. 이 에세이는 아마도 테크 역사상 가장 공격적인 "더 빨리 출시하라"의 한복판에 등장했다.
지금의 상황을 보자. 코그니션(Cognition)의 AI 소프트웨어 엔지니어 데빈(Devin)이 엄청난 화제 속에 출시되었다. Cursor, Windsurf, 그리고 수십 개의 다른 AI 보조 코딩 도구들이 키 입력당 가장 많은 코드를 생성하는 경쟁을 벌이고 있다. Y 콤비네이터 파트너들은 AI를 사용해 팀 전체의 일을 하는 1인 창업자에게 투자하겠다고 공공연히 밝혔다. 업계 정상에서 내려오는 메시지는 분명하다: 더 빨리 움직이지 않으면, 뒤처지는 것이다.
로나허의 에세이는 이에 대한 직접적인 대항 서사다. 그리고 해커뉴스의 반응은 이 말을 해줄 신뢰할 만한 누군가를 기다려온, 규모가 크지만 아마도 침묵해온 현직 엔지니어 다수가 존재함을 시사한다.
댓글 스레드는 시사하는 바가 크다. 개발자들이 잇달아 급하게 출시한 후 수년간 패치, 재작성, 또는 폐기하게 된 프로젝트의 경험담을 공유했다. 여러 댓글 작성자가 AI 코딩 도구 자체의 아이러니를 지적했다 — 기반이 되는 모델은 수년간의 인내심 있는 연구를 거쳐 만들어졌는데, 그 위에 쌓인 제품들은 지속성에 대한 고려 없이 출시되고 있다는 것이다.
높은 추천을 받은 한 댓글은 직설적으로 말했다: AI가 작성한 최고의 코드라 해도, 그것이 *왜* 그렇게 작성되었는지를 이해하는 사람이 여전히 필요하다.
서울 vs. 샌프란시스코: "빨리 출시하라" 문화는 보편적이지 않다
서울과 샌프란시스코 사이에 있는 내 위치에서 보면 여기서부터 흥미로워진다. 서로 다른 테크 생태계가 로나허의 주장에 반응하는 방식은 각 생태계가 어디로 향하고 있는지를 보여준다.
한국에서 AI 코딩을 둘러싼 대화는 다른 분위기를 띤다. 네이버와 카카오 같은 테크 대기업들이 AI 도구를 개발 워크플로우에 통합해왔지만, 엔지니어링 문화 — 특히 대기업에서 — 는 여전히 철저한 코드 리뷰와 신중한 아키텍처를 중시한다. 한 주요 한국 핀테크 기업의 시니어 엔지니어가 지난달 나에게 말했는데, 그들 팀은 Cursor를 평가한 후 보일러플레이트 생성에만 사용을 제한하기로 결정했다고 한다. "비즈니스 로직에는 손대지 못하게 합니다," 그가 말했다. "거기가 사고가 이루어지는 곳이니까요."
반면 실리콘밸리는 속도 자체를 미덕으로 전적으로 수용했다. 문화적 격차는 벌어지고 있다. 그리고 유럽 출신 개발자가 샌프란시스코 기업에서 일하며 쓴 로나허의 에세이는 바로 그 교차점에 있다.
Flask, Jinja2, Rye: 주장 뒤에 있는 증거들
이것은 익명 개발자의 그저 그런 블로그 글이 아니다. 로나허는 거의 20년간 파이썬 생태계에서 가장 영향력 있는 인물 중 하나였다. 2010년 그가 "자리를 잡아버린 만우절 농담"이라고 불렀던 Flask는 현재 전 세계 수많은 프로덕션 애플리케이션을 구동하고 있다. 그의 템플릿 엔진 Jinja2는 Ansible, Salt, 그리고 수십 개의 다른 주요 도구에서 사용된다.
최근에는 로나허가 의도적으로 느린 타임라인 위에 구축한 파이썬 프로젝트 관리 도구 Rye로 화제를 모았다. 그는 Rust의 Cargo에서 얻은 교훈을 반영하며 체계적으로 개발했고, 준비되지 않은 기능을 서두르지 않았다. 그 결과, 마침내 성숙 단계에 이르렀을 때 놀라울 정도로 잘 작동하는 도구가 탄생했다.
바로 그 실적이 이 에세이를 또 하나의 "속도를 늦춰라" 류의 칼럼과 다르게 만든 이유다. 로나허에게는 증거가 있다. 그는 시간을 *들였기 때문에* 오래 지속되는 것들을 만들었다.
불편한 진실: 인센티브 구조는 여전히 속도를 선호한다
솔직한 답은 업계가 아마 듣고 있지 않다는 것이다 — 적어도 경영진 차원에서는. 벤처 투자를 받는 테크 업계의 인센티브 구조는 여전히 거의 모든 것보다 속도를 보상한다. 18개월에 걸쳐 완성도 높은 제품을 출시하는 스타트업은 3개월 만에 거친 제품을 출시하고, 시장을 선점하고, 반복 개선하는 경쟁사에게 질 것이다. 이것은 로나허의 잘못이 아니다. 게임의 규칙이 그렇다.
하지만 반론도 주목할 가치가 있다. 여러 차례의 하이프 사이클을 거치고도 살아남은 기업들 — 지금까지 건재한 기업들 — 은 언제 속도를 늦춰야 하는지를 알았던 기업인 경우가 많다. 애플은 아이폰 출시 전 수년간 제품을 다듬었다. 구글은 수익화 전에 검색 품질에 시간을 들였다. 한국에서도 삼성의 반도체 사업부는 성과를 내기까지 수년이 걸리는 장기 R&D 투자로 유명하다.
로나허는 속도가 중요하지 않다고 말하는 것이 아니다. 속도가 *유일하게* 중요한 것은 아니라고 말하고 있는 것이다. 그리고 해커뉴스의 302포인트는 실제로 코드를 작성하는 사람들 다수가 이미 이 사실을 알고 있음을 시사한다.
"바이브 코딩" 제품이 프로덕션에 투입되면 무슨 일이 벌어지는가
진짜 시험은 앞으로 12개월에서 18개월 사이에 찾아온다. AI가 생성한 코드베이스가 점점 커지고 "바이브 코딩" 제품의 첫 번째 물결이 대규모로 프로덕션에 투입되면, 그 지름길이 버텨내는지 알게 될 것이다. 만약 버텨내지 못한다면, 로나허의 에세이는 단순한 카타르시스의 순간이 아니라 하나의 예언이 될 것이다.
지금으로서는 302개의 추천은 신호이지 혁명은 아니다. 하지만 최신 AI 데모의 속도로 돌아가는 문화에서, 인내에 대한 사려 깊은 에세이를 읽기 위해 잠시 멈추는 것조차 조용한 저항의 행위처럼 느껴진다.
