코드는 쓰는 시간보다 읽히는 시간이 더 길다

코드는 쓰는 시간보다 읽히는 시간이 더 길다

코드를 작성할 때 우리는 종종 “얼마나 빠르게 구현했는가”에 집중한다. 요구사항을 만족시키고, 동작하는 결과를 만들어내는 것이 우선이기 때문이다. 하지만 코드의 생애 주기를 조금만 길게 바라보면, 이 관점은 금방 한계를 드러낸다. 코드는 작성되는 시간보다, 읽히고 수정되는 시간이 훨씬 더 길다.

한 번 작성된 코드는 이후에 여러 번 읽힌다. 버그를 수정할 때, 기능을 추가할 때, 성능을 개선할 때, 혹은 단순히 동작을 이해하기 위해서도 다시 들여다보게 된다. 이 과정은 작성자 본인뿐 아니라, 다른 개발자들에 의해서도 반복된다. 결국 코드의 가치는 “얼마나 빠르게 작성되었는가”보다 “얼마나 쉽게 이해되는가”에 더 크게 좌우된다.

가독성은 단순한 미적 요소가 아니다. 이해 속도와 직결되는 요소다. 함수 이름 하나, 변수 이름 하나가 코드의 의미를 얼마나 명확하게 전달하느냐에 따라, 읽는 사람이 들여야 하는 인지 비용이 달라진다. data, result, temp 같은 모호한 이름은 맥락을 계속 추적하게 만들고, 이는 곧 피로로 이어진다.

반대로 의도가 드러나는 네이밍은 코드 자체를 설명으로 바꿔준다. calculateDiscountedPrice, fetchActiveUsers, validatePaymentRequest 같은 이름은 추가 설명 없이도 역할을 이해할 수 있게 만든다. 이런 작은 차이들이 쌓이면, 코드 전체의 읽기 경험이 크게 달라진다.

구조 또한 중요하다. 하나의 함수가 여러 가지 일을 동시에 처리하거나, 깊게 중첩된 로직이 계속 이어지면 코드를 따라가는 것 자체가 어려워진다. 반대로 역할이 잘 나뉘고, 흐름이 명확하게 드러나는 구조는 처음 보는 코드라도 빠르게 파악할 수 있게 해준다. 이는 유지보수 속도와 직결된다.

협업 환경에서는 이 차이가 더욱 크게 드러난다. 혼자 작성하고 혼자 유지하는 코드라면 어느 정도의 복잡성을 감당할 수 있을지 모른다. 하지만 여러 사람이 함께 작업하는 환경에서는, 코드가 하나의 커뮤니케이션 수단이 된다. 코드가 이해되지 않는다는 것은 곧 의사소통이 실패했다는 의미에 가깝다.

이때 가독성이 떨어지는 코드는 팀 전체의 속도를 늦춘다. 새로운 사람이 합류했을 때 온보딩 시간이 길어지고, 변경 사항을 리뷰하는 데도 더 많은 시간이 필요하다. 작은 수정 하나를 위해 전체 흐름을 이해해야 하는 상황이 반복되면, 자연스럽게 생산성은 떨어진다.

또한 가독성이 좋은 코드는 변경에 강하다. 구조와 의도가 명확하게 드러나 있기 때문에, 어떤 부분을 수정해야 하는지 쉽게 파악할 수 있고, 예상치 못한 사이드 이펙트도 줄어든다. 이는 장기적으로 코드의 안정성과 직결된다.

흥미로운 점은 가독성을 높이는 방법이 대부분 복잡하지 않다는 것이다. 명확한 이름을 짓고, 함수를 작게 나누고, 중복을 줄이고, 일관된 스타일을 유지하는 것. 기본적인 원칙들을 지키는 것만으로도 코드의 품질은 크게 개선된다.

결국 코드는 단순히 동작하는 결과물이 아니라, 계속해서 읽히고 이해되어야 하는 문서다. 그리고 이 문서는 시간이 지날수록 더 많은 사람에게 영향을 준다.

그래서 코드를 작성할 때 한 번쯤은 이렇게 생각해볼 필요가 있다.
이 코드는 6개월 뒤의 내가, 혹은 전혀 다른 사람이 읽어도 이해할 수 있을까.
그 질문에 자신 있게 답할 수 있을 때, 비로소 코드는 좋은 상태에 가까워진다.