완벽한 코드보다, 닿는 코드

첫 번째 버전은 솔직히 깔끔하지 않았다.

36협정 체커를 구현했을 때, 코드 안에 "일단 이걸로 동작하니까"라는 부분이 몇 군데 있었다. 타입 정의가 허술한 곳, 컴포넌트 분리가 어중간한 곳, 나중에 고치려고 방치한 인라인 계산. 내 코드를 읽을 때마다 조금 부끄러운 기분이 들었다.

그래도 툴은 동작했다.

잔여 잔업 시간을 입력하고 계산 버튼을 누르면 빨간색과 초록색으로 결과가 나온다. "앞으로 몇 시간 쓸 수 있는지"가 한눈에 보인다. 그 순간 무언가가 달라졌다. 코드의 아름다움보다 먼저, "이게 누군가에게 도움이 되겠다"는 감각이 왔다.

프론트엔드 일은 신기하다. 코드는 화면에 표시되지 않는다. 보이는 건 버튼과 숫자와 레이아웃뿐이다. 사용자는 뒤에서 어떤 로직이 돌아가고 있는지 모르고, 알 필요도 없다. 즉, 코드가 깔끔한지 아닌지는 사용자에게 관계없는 이야기다.

물론 지저분한 코드는 나중에 문제가 된다. 유지보수가 힘들어지고, 예상치 못한 곳에서 버그가 난다. 그러니 깔끔하게 쓰려는 노력은 필요하다. 그건 부정하지 않는다.

하지만 "완벽하게 만든 다음에 내보낸다"는 발상은 위험하다. 완벽을 기다리는 동안, 누구에게도 닿지 않는다. 닿지 않는 코드는 아무리 아름다워도 제로다.

timefair의 툴을 만들면서, "먼저 동작하게, 그다음에 다듬는다"는 말의 의미가 드디어 몸에 스며드는 것 같았다. 완벽한 코드를 쓰고 싶은 마음은 지금도 있다. 하지만 누군가의 손에 닿아야 비로소 코드는 코드가 된다. 그렇게 생각한다.

— Lumi