PR을 올리기 전에 한 번 더 본다. 변수명이 마음에 안 든다. 바꾼다. 다시 본다. 이 함수를 분리하는 게 나을 것 같다. 분리한다. 테스트도 수정한다. 한 시간이 지났다.

기능은 이미 동작한다. 코드도 나쁘지 않다. 그런데 "더 좋을 수 있다"는 생각이 머리를 떠나지 않는다.

이걸 꼼꼼함이라고 포장할 수도 있지만, 완벽주의다. 그리고 이 완벽주의가 나를 느리게 만들고 있다는 걸 인정하는 데 시간이 걸렸다.

완벽주의의 진짜 비용#

완벽주의의 비용은 시간만이 아니다.

의사결정 마비. 기술 스택을 고를 때, A와 B를 비교하는 시간이 너무 길다. "최적의 선택"을 하려다 보니 시작 자체가 늦어진다. 사이드 프로젝트가 기술 조사 단계에서 멈추는 경우가 얼마나 많았나.

배포 공포. "혹시 빠진 게 있지 않을까?" 배포 버튼을 누르기 전에 한 번 더, 또 한 번 더 확인한다. 완벽하게 확인하고 배포하고 싶지만, 완벽한 확인이란 존재하지 않는다.

에너지 소진. 80%에서 100%로 가는 데 드는 에너지가, 0%에서 80%까지의 에너지보다 크다. 그리고 그 20%의 차이를 사용자는 대부분 느끼지 못한다.

코드에서의 "충분히 좋은"#

"Good Enough"라는 개념을 처음에는 타협이라고 생각했다. 좋은 개발자는 완벽한 코드를 쓰는 사람이라고 믿었으니까.

그런데 실제로 좋은 개발자들을 관찰해보면, 그 사람들은 완벽한 코드를 쓰는 게 아니라 적절한 품질의 코드를 빠르게 쓴다. 핵심 로직은 견고하게, 나머지는 적당히. 리팩토링이 필요하면 나중에 한다. "지금 이 코드가 프로덕션에 나가도 문제없는가?"가 기준이지, "이 코드가 교과서에 실려도 되는가?"가 기준이 아니다.

코드의 수명을 생각하면 더 명확해진다. 스타트업에서 만드는 기능의 상당수는 3개월 뒤에 바뀌거나 사라진다. 3개월 뒤에 사라질 코드를 일주일 걸려서 완벽하게 만드는 게 합리적인가?

블로그 글에서도 마찬가지#

이 블로그를 운영하면서도 완벽주의와 싸운다. 글을 쓰고, 퇴고하고, 또 퇴고하고, 그래도 마음에 안 들어서 임시 저장에 묻어두는 글이 쌓였다.

어느 순간 깨달았다. 임시 저장에 잠자는 70점짜리 글 10개보다, 발행된 70점짜리 글 1개가 가치가 있다. 세상에 나가지 않은 글은 0점이나 마찬가지다.

완벽주의를 완화하는 방법#

완벽주의를 "고치려고" 하면 또 다른 완벽주의에 빠진다. "완벽하게 완벽주의를 극복하겠다"는 모순. 완화하는 것, 조절하는 것이 현실적이다.

시간 제한을 건다. "이 PR은 1시간 안에 올린다." 시간이 정해지면 우선순위가 생긴다. 중요한 것부터 하고, 덜 중요한 건 다음으로 미룬다. 타이머가 울리면 올린다. 지금 상태 그대로.

"이걸 안 고치면 뭐가 문제인가?"를 묻는다. 변수명이 마음에 안 드는데, 안 바꾸면 뭐가 문제인가? 읽기 어려운가? 아니면 그냥 내 취향이 아닌 건가? 실질적 문제가 아니면 넘어간다.

첫 번째 버전을 쓰레기통에 버릴 각오로 만든다. 어차피 고칠 거다. 첫 버전이 완벽할 필요가 없다. 빠르게 만들고, 피드백 받고, 개선하는 사이클이 완벽한 첫 버전보다 결과물이 좋다.

완벽주의는 책임감에서 온다. "내가 만든 것이 문제를 일으키면 안 된다"는 책임감. 이건 좋은 특성이다. 그런데 그 책임감이 과도해지면 아무것도 내보내지 못하는 마비 상태가 된다.

"이 정도면 충분하다"고 말할 수 있는 용기. 완벽주의자에게는 이게 가장 어려운 일이다.