해외 개발자가 정리한 '읽기 좋은 코드' 짜는 현실적인 원칙들

요약 소프트웨어 개발자 제레미 미콜라(Jeremy Mikkola)가 가독성 높은 코드를 작성하기 위해 평소 염두에 두는 실무 원칙들을 공유해 개발자 커뮤니티의 관심을 모았습니다. 작성자는 읽기 좋은 코드를 만드는 첫 단계로 '명확성(Clarity)'을 최우선 순위에 두어야 한다고 강조합니다. 모든 요소가 우선순위일 수는 없으므로, 명확성을 챙기려면 실행 속도나 메모리 절약 같은 다른 가치를 일부 후순위로 미루는 타협이 필요하다는 설명입니다. 또한 좋은 글을 많이 읽어야 글솜씨가 늘듯, 평판 좋은 코드를 자주 접하며 어떤 코드가 깔끔하고 어떤 코드에서 악취가 나는지 감각을 길러야 한다고 덧붙였습니다. 초안 작성과 리팩터링에 대해서는 '첫 아이디어는 대개 명확하지 않다'는 점을 짚었습니다. 일단 머릿속 논리를 코드로 쏟아낸 뒤 다시 읽으며 수정하는 편이 훨씬 쉬우며, 구조 잡기가 막막할 때는 다른 동료나 고무오리에게 말로 설명하듯 순서대로 적어본 뒤 코드로 옮길 것을 권했습니다. 기계적 추상화보다는 인간 간의 소통 방식을 기준으로 삼아야 한다는 취지입니다. 주석에 대해서는 '코드가 왜(Why) 이렇게 작성되었는지' 맥락을 남겨야 한다고 조언했습니다. 단순 로직만 봐서는 미국 외 주소 처리나 특정 데이터베이스 최적화 같은 비즈니스·기술적 사유를 알 수 없고, 삭제된 코드나 작성하지 않기로 한 결정은 주석이 없으면 의도를 파악하기 어렵기 때문입니다. 추상화 수준과 함수 분리에 대해서는 구체적인 코드 예시를 들었습니다. 한 메서드 안에서 '무엇을 하는지(What)'와 '어떻게 구현하는지(How)'를 뒤섞지 말고 단일 추상화 수준을 유지해야 한다고 설명했습니다. 예를 들어 환영 이메일 발송 메서드 안에 직접 DB 쿼리를 넣지 않고, 별도 판별 메서드로 분리하는 식입니다. 다만 함수를 잘게 쪼개는 것은 변수 스코프 축소나 테스트 용이성 측면에서 유용하지만, 무리하게 DRY(Don't Repeat Yourself) 원칙을 적용해 몇 줄 겹친다고 억지 추상화를 만들면 오히려 코드 수정이 극도로 어려워진다고 경고했습니다. 한쪽 변경 시 다른 쪽도 반드시 바뀌어야 하는 경우가 아니라면 중복을 억지로 줄이지 말라는 현실적인 가이드라인을 제시했습니다.