나도 연차가 낮을 때는 완벽한 코드가 아니면 출시하면 안 되는 줄 알았어. 밤을 새워서라도 리팩토링을 끝내야 직성이 풀렸고, 조금이라도 지저분한 코드가 운영 서버에 올라가면 죄책감마저 들더라고. 하지만 15년 동안 수많은 서비스를 만들고 망가뜨려 보면서 깨달은 건, 세상에 부채 없는 서비스는 단 하나도 없다는 사실이야.
완벽주의라는 이름의 덫
내 주니어 시절은 정말 고집불통이었어. "이 구조는 나중에 확장성이 떨어집니다!"라며 기획서가 나올 때마다 아키텍처 설계에만 일주일을 매달렸지. 비즈니스는 당장 다음 주에 최소 기능 제품(MVP)을 뽑아서 시장 반응을 봐야 하는 급박한 상황인데, 나는 혼자서 10년 뒤에도 버틸 수 있는 거대한 성을 짓고 있었던 거야. 결국 일정은 계속 밀렸고, 팀장님께 한 소리 듣고 나서는 혼자 서러워서 회사 옥상에서 한참 동안 마음을 추스르곤 했어. 그때는 내 코드가 거부당한 것 같아 자존심도 상하고 무척 속상했거든. 그런데 시간이 지나고 보니 내가 비즈니스의 속도를 전혀 이해하지 못하고 있었더라고.
기술 부채는 '대출'과 같더라고
연차가 쌓이면서 깨달은 건, 기술 부채가 개발자의 도덕적 실패나 실력 부족이 아니라 비즈니스적인 '금융 대출'과 같다는 점이었어. 우리가 집을 살 때 대출을 받는 것처럼, 서비스 출시 속도를 앞당기기 위해 기술적인 빚을 지는 거지. 중요한 건 대출을 전혀 안 받는 게 아니라, 내가 감당할 수 있는 수준의 이자만 내면서 제때 갚아나가는 거야.
- 감당 가능한 부채: 나중에 고치기 쉽도록 인터페이스만 잘 격리해 둔 임시 코드
- 위험한 부채: 비즈니스 로직이 사방에 꼬여있어서 건드리면 어디가 터질지 모르는 스파게티 코드 이 차이를 알고 나서부터는 무조건 완벽한 코드를 고집하기보다, "이번 스프린트에서는 이만큼의 부채를 허용하고, 다음 배포 때 갚자"라는 합리적인 타협안을 스스로 내릴 수 있게 되었어.
빚을 숨기지 않고 드러내는 법
내가 15년 차가 된 지금도 실무에서 쓰는 방법인데, 기술 부채를 절대 개발자 머릿속에만 숨겨두지 마. 코드에 // TODO를 남기는 것도 좋지만, 진짜 중요한 건 이걸 '시각화'해서 비즈니스 부서와 공유하는 거야.
- 기술 부채 티켓 발행하기: 단순히 "코드 더러움"이 아니라, "이 코드가 유지보수 속도를 20% 지연시킴"처럼 비즈니스 임팩트를 적어서 백로그에 등록해 둬.
- 청소 시간 확보하기: 매 스프린트마다 전체 리소스의 20% 정도는 무조건 부채를 갚는 리팩토링 시간으로 합의를 보는 거야. 이렇게 하니까 기획자나 PM도 "아, 저 친구들이 지금 노는 게 아니라 나중에 더 빨리 달리려고 청소를 하고 있구나" 하고 이해해 주더라고. 늘 일정에 쫓겨 불안했던 내 마음도 한결 편안해졌고 말이지.
💬 현우의 한마디 완벽한 코드는 세상에 존재하지 않아. 진짜 실력 있는 풀스택 개발자는 백점짜리 코드를 짜는 사람이 아니라, 비즈니스의 타이밍에 맞춰 기꺼이 기술 부채를 짊어지고 이를 통제할 수 있는 사람이란다. 지금 당장 네 코드가 마음에 안 든다고 너무 자책하거나 괴로워하지 마. 그 코드가 지금 회사를 먹여 살리고 있는 소중한 첫걸음일 수 있으니까. 조금씩 갚아나가면 되니까, 오늘도 너무 조급해하지 말고 힘내자. 늘 응원할게.