사이드 프로젝트를 4개 시작해서 0개를 완성한 적이 있다. 한 해 동안. 다 이유가 있었다. 디자인이 마음에 안 들어서, 폴더 구조를 다시 잡고 싶어서, 상태 관리를 Zustand에서 Jotai로 바꾸고 싶어서, 아니 그것보다 전역 상태가 이렇게 많을 필요가 있나 싶어서. 이유는 항상 달랐는데 패턴은 같았다. 시작은 열정적으로, 중간에 "이건 아닌데" 하면서 멈추고, 결국 방치. 깃허브에 4개의 레포가 마지막 커밋 날짜 3개월 전인 상태로 남아 있다.

완벽주의라고 하면 좀 거창하다. 그냥 "내가 만족 못 하면 공개 안 해"라는 마인드였다. 근데 이게 결과적으로는 아무것도 공개 안 하는 거랑 같았다. 만족의 기준이 끝없이 올라가니까. 90%에서 "여기가 좀 아쉬운데" 하면서 95%를 만들면, 95%에서 또 "저기가 눈에 밟힌다" 하면서 97%를 향해 간다. 100%는 영원히 오지 않는다.

80%의 발견#

회사에서 일할 때는 다르다. 데드라인이 있으니까. 스프린트가 끝나면 뭐라도 나가야 한다. 그래서 "일단 동작하는 것"을 만든다. 완벽하지 않아도.

처음에는 이게 불편했다. 이 코드가 프로덕션에 이대로 나간다고? 에러 핸들링도 제대로 안 했는데? 로딩 상태도 스켈레톤으로 안 바꿨는데? 빈 화면에 스피너만 도는 건 2024년 기준으로 좀 그런데? 근데 나가고 나면 재밌는 일이 생긴다. 유저가 생각지도 못한 방식으로 쓴다. 내가 고민했던 부분은 아무도 신경 안 쓰고, 신경도 안 쓴 부분에서 버그 리포트가 온다.

한번은 검색 필터 기능을 만들었는데, 필터 조합이 복잡해질 때의 UX를 엄청 고민했다. 3개 이상 필터가 걸리면 태그 형태로 보여줄지, 드롭다운으로 접을지, 초기화 버튼 위치는 어디가 좋을지. Figma에서 세 가지 시안을 직접 그려봤다. 디자이너도 아닌데. 일주일을 고민했다. 결국 출시하고 한 달 후 어드민에서 데이터를 봤더니, 필터 3개 이상 쓰는 유저가 전체의 2%였다. 98%의 유저한테는 필요 없는 고민을 일주일 동안 한 거다.

그때부터 "일단 출시하고 보자"가 조금 편해졌다. 유저가 실제로 뭘 쓰는지는 출시 전에는 알 수 없다. 내 머릿속의 유저와 실제 유저는 거의 항상 다르다.

완벽주의자의 하루#

내 완벽주의는 코드에만 있는 게 아니었다. 블로그 글 하나 쓰는 데도 그랬다.

글을 쓰기 시작하면 구조부터 잡는다. 서론, 본론, 마무리. 각 섹션에 뭘 쓸지 메모한다. 그리고 쓰기 시작하면 첫 문장에서 막힌다. "이 첫 문장이 사람을 끌어당겨야 하는데." 한 시간 동안 첫 문장만 고치다가 지쳐서 창을 닫는다. 초안도 완성 못 한 글이 노션에 12개 있다. 제목만 쓰고 방치된 것까지 합치면 20개가 넘을 것 같다.

커밋 메시지도 그렇다. conventional commit을 쓰는데, feat인지 fix인지 refactor인지 고민하다가 시간을 쓴다. 기존 함수를 수정해서 새 기능을 추가한 건 feat인가 refactor인가? 이걸 3분 동안 생각한다. 3분이 뭐 대수냐 싶지만, 하루에 커밋을 10번 하면 30분이다. 한번은 커밋 메시지에 오타가 있어서 git rebase -i로 메시지를 고친 적도 있다. 그것도 개인 프로젝트에서. 아무도 안 볼 메시지를.

코드 리뷰를 올릴 때도 마찬가지다. PR 올리기 전에 내 코드를 세 번은 본다. "이 변수명이 좀 애매한데", "이 함수 길이가 좀 긴데", "이 로직을 커스텀 훅으로 빼야 하나?" 고민하다 보면 간단한 피처인데 PR 올리는 데 반나절이 걸린다. PR 설명도 장문으로 쓴다. 변경 사항, 이유, 스크린샷, 관련 이슈. 꼼꼼한 건 좋은데, 30분짜리 작업에 PR 설명 쓰는 데 1시간 걸리면 본말전도다.

팀 리드가 해준 말#

분기 회고 때 팀 리드가 피드백을 줬다. "코드 퀄리티는 좋은데, 속도가 좀 아쉽다." 직접적이었다. 나는 퀄리티를 위해 속도를 희생한다고 생각했는데, 팀 리드 입장에서는 그냥 느린 거였다.

좀 충격이었다. 나는 "꼼꼼한 개발자"라고 생각했는데, 팀에서는 "느린 개발자"로 보고 있었던 거다. 물론 팀 리드가 그렇게 직접적으로 말한 건 아니지만, 뉘앙스가 그랬다.

그때 팀 리드가 이런 말을 했다. "완벽한 코드는 없어. 지금 좋은 코드도 6개월 후에 보면 고치고 싶어져. 그러니까 지금 시점에서 적당한 걸 빠르게 내고, 문제 생기면 그때 고치는 게 낫다." 머리로는 알겠는데 손이 안 따라갔다. 적당한 게 뭔지를 모르겠는 거다. "적당히"라는 말이 제일 어렵다. 기준이 없으니까.

나중에 생각해보니까, 팀 리드가 올리는 PR은 간결했다. 설명도 핵심만 쓰고, 코드도 필요한 것만 담겨 있었다. 그런데 퀄리티가 떨어지는 건 아니었다. 불필요한 게 없을 뿐이었다. "이게 적당함이구나" 하는 걸 코드로 보여준 셈이었다.

적당함을 배우는 중#

요즘은 규칙을 하나 만들어서 쓴다. "이 고민이 1시간 넘어가면 일단 현재 상태로 간다." 타이머를 쓰는 건 아니고, 체감으로. 변수명 고민이 길어지면 일단 지금 이름으로 커밋한다. 나중에 더 좋은 이름이 떠오르면 그때 바꾸면 된다. 보통은 안 떠오르고, 안 떠오르면 지금 이름도 괜찮았다는 뜻이다.

PR 설명도 줄였다. "뭘 했는지"와 "왜 했는지"만 쓴다. 스크린샷은 UI 변경이 있을 때만. 이전에는 콘솔 로그 하나 추가해도 스크린샷을 찍었는데, 이제는 안 한다.

사이드 프로젝트에도 적용 중이다. 최근에 만든 건 작은 크롬 익스텐션인데, CSS가 좀 구린 상태로 크롬 웹 스토어에 올렸다. 버튼 호버 효과도 없고, 반응형도 안 된다. 근데 기능은 동작한다. 탭에서 중복된 URL을 찾아서 닫아주는 기능. 다운로드 수는 6이다. 6명 중 4명이 나와 내 지인이다. 근데 괜찮다. "완성해서 배포한" 프로젝트가 생긴 거니까. 4개를 시작하고 0개를 완성한 것보다 낫다.

블로그도 마찬가지다. 이 글도 사실 구조가 좀 들쭉날쭉하다. 예전 같으면 "흐름이 자연스럽지 않아"라면서 발행을 미뤘을 텐데, 지금은 그냥 올린다. 발행 버튼 누르는 게 고치는 것보다 중요하다. 드래프트 상태로 영원히 남는 것보다 구린 글이라도 나간 게 낫다.

이상한 역설#

재미있는 건, 적당함을 추구하기 시작하니까 오히려 결과물이 많아졌다는 거다. 예전에는 한 달에 블로그 0개, 사이드 프로젝트 진행도 0%였는데, 요즘은 한 달에 글 2-3개, 사이드 프로젝트도 조금씩 나간다. 퀄리티는? 솔직히 예전에 공들여서 쓴 글과 비교하면 좀 떨어질 수 있다. 근데 예전 글은 세상에 나오지 않았으니까 비교 자체가 불가능하다. 서랍 속 명작보다 세상에 나온 졸작이 100배 낫다는 건 과장이 아니다.

완벽한 0개보다 적당한 10개가 낫다. 이건 틀린 말이 아닌데, 체화하는 건 진짜 어렵다.

아직도 PR 올리기 전에 코드를 두 번은 본다. 세 번에서 두 번으로 줄인 거다. 미세한 발전. 커밋 메시지 오타도 이제는 그냥 둔다. 대부분은. 가끔은 아직도 고치지만. 뇌의 어딘가에서 "고쳐야 해"라는 알람이 울리는 걸 무시하는 연습을 하고 있다.

적당함도 연습이 필요한 기술인 것 같다. 아이러니하게도 그 연습을 완벽하게 하려는 나를 발견할 때가 있다. "오늘은 적당함 연습을 제대로 했나?" 하고 되돌아보는 순간, 이게 또 완벽주의의 변형이라는 걸 깨닫는다.

최근에 읽은 글에서 "done is better than perfect"라는 말이 있었다. 실리콘밸리에서 자주 쓰는 말이라고. 끝내는 게 완벽한 것보다 낫다. 머리로는 백 번 동의하는데, 키보드 위에서는 아직 자주 잊어버린다. 어제도 컴포넌트 이름을 15분 동안 고민하다가 "아 그냥 이거로 하자" 하고 넘겼다. 15분이 짧아 보이지만, 그 15분 동안 다른 일을 할 수 있었다는 걸 생각하면 아깝다. 근데 예전에는 30분이었으니까, 절반으로 줄인 거다.

어쩌면 완전히 고쳐지는 건 아닌지도 모르겠다. 그냥 같이 가는 거다.