다시 보기: 이 7가지 규칙을 적용해 코드를 정리하세요

Source: Dev.to

약 5년 전, 나는 “Clean Up Your Code by Applying These 7 Rules”라는 제목의 글을 썼습니다. 그때 나는 더 명확하고 읽기 쉬운 코드를 작성하는 데 집중했고, 일상 업무를 개선하는 데 도움이 된 실용적인 기술들을 공유했습니다.

돌이켜 보면, 그 집중은 타당했습니다. 클린 코드는 명확성, 유지보수성, 그리고 복잡해지는 시스템을 통제할 수 있는 감각을 약속합니다. 당시 나는 주로 더 나은 소프트웨어를 작성하려는 개인 기여자의 관점에서 이 주제에 접근했습니다.

5년이 지난 지금도 나는 그 글의 의도에 여전히 동의하지만, 그 아이디어들을 언제 그리고 어떻게 적용해야 하는지에 대한 나의 이해는 발전했습니다.

원본 버전을 먼저 읽고 싶다면, 여기에서 확인할 수 있습니다:
이 7가지 규칙을 적용해 코드를 정리하기

아직도 유효한 것

원본 글의 여러 아이디어는 커뮤니케이션에 기반을 두고 있어 시간이 지나도 여전히 유효합니다.

• Readable code는 여전히 가장 좋은 투자 중 하나입니다. 명확한 네이밍, 단순한 제어 흐름, 작고 집중된 로직 단위는 다른 사람(그리고 미래의 자신)이 코드가 무엇을 하려는지 이해하기 쉽게 합니다.
• Boy Scout Rule—코드를 찾은 그대로보다 조금 더 나은 상태로 남겨두는 것—은 여전히 공감을 얻습니다. 작은 개선이 시간이 지날수록 누적되고, 코드베이스는 방치보다 관리와 관심을 받을 때 혜택을 봅니다.
• 이러한 원칙이 효과적인 이유는 tool‑agnostic이기 때문입니다. 코드를 읽는 다음 사람이 여러분의 미래 자신이 되거나, 여러분의 코드를 기반으로 읽기 쉬운 코드를 생성하려는 LLM이 될 수도 있습니다.

오늘 느끼는 미완성감

The original assumption that cleanup is always the obvious next step no longer holds.

• 경력 초기에 나는 정리를 지역 활동으로 여겼다: 마음에 들지 않는 것을 보고 규칙을 적용하고 넘어갔다. 시간이 지나면서 정리는 단순히 코드만을 의미하는 것이 아니라 맥락, 소유권, 시기, 의도와 관련된 것임을 알게 되었다.
• 코드 조각이 존재하는 이유를 이해하지 못한 채 리팩터링을 하는 것은 위험할 수 있다. 중복되거나 과도하게 방어적인 것으로 보이는 것이 실제로는 당신이 모르는 제약을 방어하고 있을 수도 있다. 이를 제거하면 미묘한 버그가 생기거나 의도된 결정을 되돌릴 수 있다.
• 기술적 결정은 종종 제품 요구사항, 마감일, 조직적 제약에 의해 좌우된다. 이런 경우 “깨끗함”이 주요 목표가 아니라 작동하는 것을 출시하는 것이 목표다.
• 규칙 자체가 틀린 것은 아니었지만 맥락 없이는 불완전했다.

정리 작업에 대한 관점 변화

큰 규모와 오래된 시스템을 작업하면서 속도를 늦추고 접근 방식을 재고하게 되었습니다.

• Inheritance of code I didn’t write highlighted that understanding usually creates more value than immediately improving aesthetics.
  • 제가 작성하지 않은 코드의 상속은 이해가 즉각적인 미관 개선보다 더 큰 가치를 창출한다는 점을 강조했습니다.
• I began to see cleanup as a shared responsibility rather than an individual one. In a team, even well‑intended refactoring can have side effects; small local changes can ripple outward and affect others in unexpected ways.
  • 저는 정리를 공유된 책임으로 보기 시작했습니다. 팀에서는 의도가 좋은 리팩터링이라도 부작용이 있을 수 있으며, 작은 로컬 변경이 외부로 퍼져 예상치 못한 방식으로 다른 사람에게 영향을 줄 수 있습니다.
• Knowing why something exists matters more than knowing how to improve it.
  • 무언가가 존재하는 이유를 아는 것이 그것을 어떻게 개선할지 아는 것보다 더 중요합니다.

Clean code is not a checklist; it is a byproduct of understanding.
깨끗한 코드는 체크리스트가 아니라 이해의 부산물입니다.

Rules are helpful starting points, but judgment is what makes them useful. Sometimes the right choice is to refactor; sometimes it is to document intent; sometimes it is to leave things as they are and revisit them later.
규칙은 도움이 되는 출발점이지만, 판단이 그것을 유용하게 만듭니다. 때로는 올바른 선택이 리팩터링이고, 때로는 의도를 문서화하는 것이며, 때로는 현재 상태를 유지하고 나중에 다시 검토하는 것이 맞습니다.

목표

목표는 완벽함이 아니다. 목표는 청지기 정신이며 고객에게 가치를 제공하는 것이다.

나는 여전히 깨끗한 코드를 작성하는 것을 믿으며, 이전의 코드를 존중하는 것이 그 책임의 일부라고 생각한다. 코드는 압박 속에서, 당시 이용 가능한 정보를 바탕으로, 종종 지금은 보이지 않는 제약 하에서 내린 결정들의 기록이다.

오래된 글을 다시 보니 학습이 항상 새로운 아이디어에 관한 것은 아니라는 것을 깨달았다. 때때로 기존 아이디어를 재구성하는 것이 더 큰 가치를 가질 수 있다.

일반적으로, 이 규칙들은 지난 5년 동안 더 나은 코드를 작성하는 데 도움이 되었지만, 경험을 통해 언제 적용해야 하는지를 배웠다.