코드 품질 개선 기법 10편: 적절한 거리 유지에 신경 쓰자 (새 탭에서 열림)
코드 품질을 높이기 위해서는 각 레이어나 컴포넌트가 서로의 세부 구현을 알지 못하도록 적절한 거리를 유지하는 것이 중요합니다. 특히 UI와 데이터 레이어가 암묵적인 규칙을 공유하며 의존할 경우, 사양 변경 시 예측하지 못한 버그가 발생하기 쉬우므로 명확한 상태 값과 인터페이스를 통해 책임을 분리해야 합니다. **암묵적 정보 공유의 문제점** * 리포지터리 레이어에서 UI의 표시 형식을 고려해 '최대 개수 + 1'의 데이터를 조회하는 식의 구현은 레이어 간의 경계를 무너뜨립니다. * UI 레이어가 리포지터리의 특정 동작(예: 100개 초과 시 리스트 크기가 101임)에 의존해 비즈니스 로직을 판단하면 코드의 가독성과 유지보수성이 떨어집니다. * 이러한 방식은 주석으로만 의도를 설명할 수 있을 뿐, 코드 구조 자체로는 데이터의 의미를 명확히 전달하지 못하는 한계가 있습니다. **명시적인 속성을 활용한 책임 분리** * 모델 클래스에 `hasMoreItems`와 같은 명시적인 불리언 속성을 추가하여 데이터의 상태를 직접적으로 표현하는 것이 좋습니다. * 리포지터리는 모델 인스턴스를 생성할 때 추가 데이터 존재 여부를 판단하는 로직을 수행하고, UI에는 정제된 데이터만 전달합니다. * UI 레이어는 더 이상 특정 상수값이나 리포지터리의 조회 규칙을 알 필요 없이, 모델이 제공하는 속성에만 기반하여 화면을 구성할 수 있게 됩니다. **로직과 상수의 적절한 위치 선정** * 데이터 개수를 제한하는 상수(`ITEM_LIST_MAX_COUNT`)는 서비스의 성격에 따라 비즈니스 로직 레이어(도메인, 유스 케이스 등)에서 정의하는 것이 이상적입니다. * 비즈니스 레이어를 별도로 두기 어려운 규모라면 모델 클래스 내부에 정의할 수도 있으나, 이때는 데이터 구조와 알고리즘 간의 의존 방향이 모호해지지 않도록 주의해야 합니다. * 특정 기능에 국한된 로직이 범용적인 데이터 모델에 포함되어 재사용성을 해치지 않는지 검토하는 과정이 필요합니다. **실용적인 제언** 코드 작성 시 "이 컴포넌트가 다른 컴포넌트의 내부 사정을 너무 자세히 알고 있지는 않은가?"를 자문해 보시기 바랍니다. 다른 레이어의 세부 동작에 암묵적으로 의존하는 코드를 피하고, 인터페이스를 통해 명확한 정보를 주고받도록 설계하는 것이 변경에 유연한 소프트웨어를 만드는 핵심입니다.