Armin Ronacher가 말하는 '시간이 걸리는 것들' — 소프트웨어 개발에서 인내의 가치

Flask 창시자의 새로운 에세이

Flask와 Jinja2, 그리고 최근에는 Rust 기반 도구들로 유명한 Armin Ronacher가 자신의 블로그에 "Some things just take time"이라는 제목의 에세이를 게시했다. 이 글은 소프트웨어 엔지니어링에서 빠른 결과를 요구하는 문화에 대한 반성이자, 정말 의미 있는 성과를 만들어내려면 시간이라는 자원이 필수적이라는 메시지를 담고 있다.

Armin Ronacher는 Python 생태계에서 매우 영향력 있는 개발자다. Flask는 Django와 함께 Python 웹 프레임워크의 양대 산맥이고, Jinja2는 거의 모든 Python 템플릿 엔진의 표준이 되었다. 최근에는 Sentry의 CTO로 활동하면서 Rust 기반의 다양한 오픈소스 도구(symbolic, relay 등)를 만들고 있다. 이런 배경을 가진 사람이 '시간'에 대해 이야기한다는 것 자체가 의미 있다.

에세이의 핵심 논점

이 에세이의 중심 주장은 명쾌하다. 소프트웨어 개발에서 일부 문제는 더 많은 사람을 투입하거나, 더 열심히 일하거나, 더 좋은 도구를 쓴다고 해서 빨라지지 않는다는 것이다. Frederick Brooks가 1975년에 「맨먼스 미신(The Mythical Man-Month)」에서 했던 이야기와 맥이 닿지만, Ronacher는 이를 현대적인 맥락에서 재해석한다.

그가 드는 예시 중 하나는 라이브러리나 프레임워크의 API 설계다. 좋은 API는 처음부터 완벽하게 설계되는 것이 아니라, 실제 사용자들이 다양한 방식으로 사용하면서 피드백이 쌓이고, 그 피드백을 반영해 점진적으로 개선되는 과정을 거친다. 이 과정은 본질적으로 시간이 걸린다. 아무리 뛰어난 설계자라도 모든 사용 패턴을 미리 예측할 수는 없기 때문이다.

또 다른 예시는 기술 부채의 해결이다. 레거시 시스템을 현대화하는 작업은 "빅뱅" 방식의 전면 재작성보다, 점진적인 마이그레이션이 훨씬 성공률이 높다는 것은 업계에서 널리 알려진 사실이다. 하지만 점진적 마이그레이션은 본질적으로 시간이 오래 걸린다. 기존 시스템과 새 시스템이 공존하는 과도기를 견뎌야 하고, 그 동안 두 시스템을 동시에 유지보수해야 하는 부담도 있다. 이런 상황에서 경영진이나 PM이 "왜 아직도 안 끝났냐"고 물을 때, 개발자가 "원래 시간이 걸리는 일"이라고 설명할 수 있어야 한다는 것이 Ronacher의 메시지다.

현대 개발 문화와의 충돌

이 에세이가 특히 공감을 얻는 이유는, 현재 소프트웨어 업계가 극단적인 속도를 추구하는 분위기이기 때문이다. 2주 스프린트, 빠른 이터레이션, "move fast and break things"라는 모토는 이미 업계 표준이 되었다. 최근에는 AI 코딩 도구(Copilot, Cursor 등)의 등장으로 "개발 속도가 10배 빨라진다"는 기대감까지 더해졌다.

하지만 Ronacher는 이런 도구들이 타이핑 속도는 빠르게 해줄 수 있어도, 문제를 깊이 이해하고 올바른 추상화를 찾아내는 과정까지 가속화해주지는 않는다고 지적한다. 오히려 빠르게 코드를 생성할 수 있게 되면서, 충분히 생각하지 않고 코드를 쏟아내는 경향이 생길 수 있다는 우려도 있다. 코드를 작성하는 것과 올바른 코드를 작성하는 것 사이에는 큰 차이가 있고, 후자는 경험과 시간이 필요한 영역이다.

이 관점은 최근 Rich Hickey(Clojure 창시자)의 "Hammock Driven Development" 철학과도 일맥상통한다. Hickey는 가장 어려운 프로그래밍 문제는 키보드 앞이 아니라 해먹에 누워서 생각할 때 풀린다고 말한 바 있다. 생각하는 시간, 숙성하는 시간이 소프트웨어 품질에 결정적이라는 주장이다.

오픈소스 메인테이너의 관점

이 에세이에는 오픈소스 메인테이너로서의 경험도 녹아 있다. Flask처럼 수백만 명이 사용하는 프로젝트를 유지보수하다 보면, 급하게 추가한 기능이 나중에 얼마나 큰 부담이 되는지를 체감하게 된다. API 하나를 잘못 노출하면 수년간 하위 호환성을 유지해야 하고, 그동안 내부 리팩토링의 자유도가 크게 줄어든다.

Ronacher가 Flask에서 Rust 생태계로 관심을 옮긴 것도 이런 맥락에서 이해할 수 있다. Rust의 타입 시스템과 소유권 모델은 컴파일 타임에 많은 오류를 잡아주기 때문에, 시간을 들여 설계한 것이 장기적으로 더 잘 보존된다. 즉, "시간을 들이는 것"이 보상받는 언어라고 할 수 있다.

한국 개발자에게 주는 시사점

한국 IT 업계는 특히 빠른 개발 속도를 요구하는 문화가 강하다. "빨리빨리" 문화가 긍정적으로 작용하는 경우도 있지만, 기술 부채가 빠르게 쌓이는 원인이 되기도 한다. 이 에세이는 기술 리더나 PM에게 "어떤 작업은 시간이 걸리는 게 정상"이라고 설득할 때 참고할 수 있는 좋은 논거를 제공한다.

특히 주니어 개발자들에게는, 빠르게 결과물을 내야 한다는 압박 속에서도 깊이 생각하는 시간의 가치를 잊지 말라는 메시지가 될 수 있다. 코드 리뷰에서 "왜 이렇게 오래 걸렸냐"는 질문을 받을 때, "충분히 고민해서 더 나은 설계를 찾았기 때문"이라고 자신 있게 답할 수 있는 환경이 필요하다.

마무리

빠르게 만드는 것과 잘 만드는 것 사이의 균형은 소프트웨어 엔지니어링의 영원한 과제다. Ronacher의 에세이는 그 균형추가 너무 "빠르게" 쪽으로 기울어진 현재에 대한 조용한 반론이다. 여러분의 팀에서는 "시간이 걸리는 일"에 대해 어떻게 커뮤니케이션하고 있나요? 충분히 생각할 시간이 주어지고 있다고 느끼시나요?