개발자여, 제발 좀 느려지자 — 속도에 중독된 우리에게 필요한 이야기

빠르게, 더 빠르게… 정말 그래야 할까?

개발자 세계에는 속도에 대한 강박이 있어요. 새로운 프레임워크가 나오면 바로 배워야 할 것 같고, 사이드 프로젝트도 빨리 출시해야 할 것 같고, 코딩 속도도 남들보다 빨라야 할 것 같죠. 트위터(X)를 열면 누군가는 "주말에 SaaS를 만들어서 런칭했다"고 하고, 또 누군가는 "하루 만에 앱을 완성했다"고 해요. 그런 글을 보면 괜히 조급해지고, 내가 뒤처지는 것 같은 기분이 들기도 하고요.

오스트리아의 개발자 Mario Zechner가 최근 자신의 블로그에 올린 글이 바로 이 주제를 정면으로 다루고 있어요. 제목부터가 강렬한데요, "Thoughts on Slowing the Fuck Down" — 직역하면 "좀 느려지는 것에 대한 생각"이에요. 그가 이야기하는 핵심은 간단해요. 빠르게 하는 것보다 제대로 하는 게 더 중요하다는 거죠.

속도가 만들어내는 문제들

빠르게 일하는 게 무조건 나쁘다는 건 아니에요. 하지만 속도를 최우선 가치로 놓으면 여러 가지 부작용이 생기거든요.

첫 번째는 기술 부채예요. 이게 뭐냐면, 일단 돌아가게 만들어놓고 나중에 고치자고 하는 코드가 쌓이는 걸 말해요. 신용카드 빚이랑 비슷해요. 당장은 편하지만 이자가 계속 붙어서 나중에 훨씬 큰 비용을 치르게 되죠. 빠르게 기능을 쳐내다 보면 테스트도 대충 하고, 설계도 대충 하고, 문서도 안 쓰게 되는데, 이게 몇 달 쌓이면 프로젝트 전체가 뒤엉키게 돼요.

두 번째는 번아웃이에요. 개발자 번아웃은 이제 업계의 만성적인 문제가 됐죠. 특히 AI 시대가 되면서 "AI한테 뒤처지면 안 된다"는 불안감까지 더해져서, 쉬는 시간에도 뭔가를 배우고 만들어야 할 것 같은 압박을 느끼는 분들이 많아요. 하지만 사람은 기계가 아니라서, 계속 밀어붙이면 어느 순간 완전히 무너지게 돼요.

세 번째는 깊이의 부재예요. 빠르게 여러 기술을 훑고 지나가면 어떤 것도 제대로 이해하지 못하게 돼요. 리액트 좀 하다가 Svelte로 넘어가고, 또 얼마 안 돼서 Solid를 본다면, 결국 어느 것도 깊이 있게 모르는 상태가 되는 거죠. 이걸 "마일 와이드, 인치 딥(mile wide, inch deep)" — 폭은 넓지만 깊이는 얕다고 표현하기도 해요.

느리게 하면 뭐가 달라지나요?

여기서 말하는 "느리게"는 게으르게 하라는 뜻이 아니에요. 의도적으로 시간을 들여서 제대로 하라는 뜻이에요.

코드를 작성할 때 한 번 더 생각하고, 설계를 좀 더 고민하고, 작성한 코드를 다시 읽어보는 시간을 갖는 거예요. 새로운 기술을 배울 때도 튜토리얼을 빠르게 따라하는 것보다, 공식 문서를 천천히 읽으면서 "왜 이렇게 만들었을까"를 고민하는 게 훨씬 깊은 이해를 줘요.

실제로 경험 많은 시니어 개발자들을 보면, 코딩 속도 자체가 빠른 게 아니라 문제를 정의하고 방향을 잡는 속도가 빠른 경우가 많아요. 그건 오랜 시간 깊이 있게 고민했던 경험이 쌓여서 가능한 거거든요. 빠르게 보이는 사람이 사실은 가장 많이 느리게 고민했던 사람인 셈이죠.

업계 전체가 속도에 취해 있다

이건 개인의 문제만은 아니에요. 스타트업 문화 자체가 "빠르게 실패하고 빠르게 배워라(Fail fast, learn fast)"를 금과옥조처럼 여기잖아요. 물론 이 철학 자체가 나쁜 건 아닌데, 이게 극단으로 가면 "일단 출시하고 보자"가 되어버려요.

AI 도구의 발전도 이 추세를 가속화하고 있어요. GitHub Copilot이나 Cursor 같은 AI 코딩 도구를 쓰면 코드 작성 속도 자체는 확실히 빨라지거든요. 하지만 AI가 생성한 코드를 충분히 이해하지 않고 넘어가면, 결국 내가 이해하지 못하는 코드베이스 위에서 일하게 되는 상황이 벌어져요. 속도는 빨라졌는데 통제력은 잃어버리는 거죠.

한국 개발자에게 특히 와닿는 이야기

한국 IT 업계의 근무 문화를 생각하면 이 이야기가 더 와닿을 수 있어요. "빠른 실행력"을 중요시하는 문화, 촉박한 일정, "일단 해봐" 식의 업무 지시… 이런 환경에서 "좀 느리게 하자"고 말하기가 쉽지 않죠.

하지만 이건 조직 차원에서도 고민해볼 문제예요. 빠르게 만들어서 버그 투성이인 제품을 출시하고 나서 몇 달간 핫픽스에 시달리는 것보다, 처음에 2주를 더 써서 탄탄하게 만드는 게 전체 비용으로 보면 훨씬 저렴하거든요. 개인 차원에서도, 매일 12시간씩 코딩하다 6개월 만에 번아웃으로 퇴사하는 것보다, 적정 페이스를 유지하면서 2~3년간 꾸준히 성장하는 게 커리어에 훨씬 유리하고요.

구체적으로 실천할 수 있는 것들도 있어요. 코드 리뷰를 할 때 급하게 승인하지 않고 꼼꼼히 보는 것, 새로운 라이브러리를 도입하기 전에 정말 필요한지 한 번 더 생각해보는 것, 그리고 퇴근 후에는 코딩에서 완전히 손을 떼고 쉬는 것. 이런 작은 습관들이 모여서 지속 가능한 개발자 생활을 만들어줘요.