좋은 코드에 대한 고찰: 보이스카웃 규칙을 중심으로

2024년 11월 6일

들어가며

1년차 프론트엔드 개발자로서 매일 코드를 작성하면서 항상 머릿속에 맴도는 질문이 있습니다. “이게 정말 좋은 코드일까?” 새로운 기능을 개발할 때마다, 버그를 수정할 때마다 이 질문은 계속해서 저를 따라다녔습니다.

처음 개발을 시작했을 때는 동작하는 코드가 곧 좋은 코드라고 생각했습니다. 하지만 시간이 지날수록 그것이 얼마나 순진한 생각이었는지 깨닫게 되었습니다. 코드가 동작하는 것은 기본이고, 그 이상의 무언가가 필요하다는 것을 알게 되었습니다.

제가 경험한 가장 충격적인 순간은 3개월 전에 작성했던 제 코드를 다시 봤을 때였습니다. 당시에는 자신있게 작성했던 코드였지만, 시간이 지나고 보니 이해하기 어렵고 유지보수하기 힘든 코드였습니다. 특히 다음과 같은 문제점들이 있었습니다

보이스카웃 규칙은 단순합니다. “캠핑장을 처음 왔을 때보다 더 깨끗하게 남겨놓고 떠나라”는 것입니다. 코드에 적용하면 “코드를 처음 봤을 때보다 더 깨끗하게 만들고 떠나라”가 됩니다.

1년차 개발자인 제가 이 규칙에 매료된 이유는 명확합니다. 이 규칙은 완벽한 코드를 요구하지 않습니다. 대신 점진적인 개선을 이야기합니다. 주니어 개발자인 저에게는 이 점이 큰 위안이 되었습니다.

제가 이해한 이 문구의 의미는 다음과 같습니다

리팩토링은 보이스카웃 규칙을 실천하는 가장 직접적인 방법입니다. 하지만 주니어인 저에게 리팩토링은 항상 두려움의 대상이었습니다. 다음과 같은 원칙을 세워서 실천하고 있습니다

주니어 개발자임에도 불구하고, 팀의 코드 품질 향상을 위해 적극적으로 제안하고 실천하고 있는 것들이 있습니다

코드 리뷰 문화 도입 제안
- PR 템플릿을 만들어 리뷰 포인트를 명확히 하기
- 작은 단위의 PR로 리뷰의 부담을 줄이기
- 긍정적이고 건설적인 피드백 주고받기
기술 공유 문화 만들기
- 매주 1회 팀 전체가 모여 새로운 기술과 트렌드 공유
- 실제 프로젝트에서 겪은 문제와 해결 방법 토론
- 각자의 코드 개선 사례 공유
팀 코드 컨벤션 정립
- ESLint, Prettier 설정 표준화
- 함수/변수 네이밍 규칙 합의
- 컴포넌트 구조화 방식 통일

스타트업에서 일하는 저에게 가장 큰 도전과제는 빠른 개발 속도와 코드 품질 사이의 균형을 맞추는 것입니다. 많은 개발 서적이나 아티클에서 이야기하는 “좋은 코드”의 기준들이 있지만, 실제 현장에서는 상황에 맞는 유연한 적용이 필요하다는 것을 깨달았습니다.

처음에는 “함수는 20줄을 넘기지 말자”와 같은 엄격한 기준을 세웠었습니다. 하지만 실제로 개발을 하다 보니, 때로는 비즈니스 로직의 특성상 불가피하게 긴 함수가 필요한 경우도 있다는 것을 알게 되었습니다. 대신 다음과 같은 실용적인 기준을 세웠습니다:

개발 과정에서 마주치는 다양한 상황에 따라 우선순위를 다르게 가져갑니다:

비즈니스 로직이 복잡한 경우
- 주석으로 로직의 흐름을 명확하게 설명
- 변수명을 통해 데이터의 의미를 명확하게 전달
- 테스트 코드 작성 필수
UI 컴포넌트의 경우
- 재사용성이 높은 컴포넌트는 문서화
- props의 역할을 명확하게 정의
- 스타일 관련 로직과 비즈니스 로직 분리
레거시 코드를 다룰 때
- 기존 코드의 의도를 최대한 파악
- 점진적인 개선 접근
- 변경사항에 대한 충분한 테스트

1년차 개발자로서 아직 많이 부족하지만, 보이스카웃 규칙은 제게 중요한 가이드라인이 되었습니다. 이 규칙은 완벽한 코드를 요구하지 않으면서도, 지속적인 개선을 추구하게 만듭니다.

처음에는 교과서적인 원칙들을 맹목적으로 따르려 했지만, 실제 개발 경험을 통해 상황에 맞는 유연한 적용이 더 중요하다는 것을 배웠습니다. 앞으로도 계속해서 고민하고 실천하면서 저만의 좋은 코드에 대한 기준을 만들어가려 합니다.

이 글을 쓰면서 다시 한 번 다짐해봅니다:

완벽하지 않아도 괜찮아, 그저 어제보다 나은 코드를 작성하자고.