Read Original
#Mobile

코드 품질 개선 기법 30편: (투명한) 운명의 붉은 실

코드 품질 개선 기법 30편: (투명한) 운명의 붉은 실
01

Summary

함수 사이에 숨겨진 '운명의 실', 암묵적 의존성이 당신의 코드를 파괴한다

검증과 변환을 하나로 묶어 런타임 에러를 원천 차단하는 리팩터링 전략

이 아티클은 서로 다른 두 함수가 논리적으로는 강하게 결합되어 있음에도 불구하고 코드상으로는 독립적으로 존재하는 '암묵적 의존성'의 위험성을 경고합니다. 특히 UI 레이어에서 데이터 모델을 가공할 때 흔히 발생하는 오류 사례를 통해, 어떻게 로직을 통합하여 단일 진실 공급원을 구축할 수 있는지 구체적인 Kotlin 예제와 함께 제시합니다. 복잡한 비즈니스 로직 속에서도 실수를 유발하지 않는 견고한 API 설계 노하우를 담고 있습니다.

  • 01함수 간 암묵적인 연관성이 초래하는 런타임 에러와 유지보수의 어려움 분석
  • 02필터링과 변환 기능을 하나로 합쳐 코드의 일관성을 강제하는 기법 소개
  • 03Nullable 반환 타입을 활용해 데이터의 유효성 상태를 타입 시스템으로 명시화
  • 04기존 함수의 시그니처를 유지하면서도 내부 로직의 결합도를 높이는 점진적 개선 방법
  • 05라인(LINE)의 Review Committee가 제안하는 실무 중심의 코드 품질 개선 사례

RECOMMENDATION

함수가 특정 조건에서만 안전하게 동작한다면, 그 조건을 호출자에게 맡기기보다 함수의 반환 타입이나 구조 자체에 녹여내는 방식을 우선적으로 고려하십시오.

The Problem

유효성 검증 함수와 데이터 변환 함수가 논리적으로는 연결되어 있으나 코드상으로는 암묵적으로 분리되어 있어, 개발자가 이 연관성을 놓칠 경우 런타임 에러가 발생하거나 데이터 일관성이 깨질 위험이 있다.

The Solution

유효성 검사와 데이터 변환 로직을 하나의 함수로 통합하거나, 검증 함수가 변환 함수를 호출하는 방식으로 구조를 변경하여 두 기능 간의 연관성을 명시적으로 드러내고 일관성을 보장한다.

The Result

함수 간의 숨겨진 전제 조건을 제거함으로써 리팩터링이나 기능 확장 시 발생할 수 있는 실수를 방지하고, 런타임 안정성과 코드의 가독성을 동시에 확보하였다.

Trade-off

유효하지 않은 상태를 나타내기 위해 null을 반환하는 방식은 해당 함수가 광범위하게 사용될 경우 호출부에서 null 처리에 대한 혼란을 야기할 수 있다는 한계가 있다.

03

Key Concepts

Concept · 01

Implicit Dependency

코드상에서는 명확히 보이지 않지만, 한 함수의 성공적인 실행이 다른 함수의 선행 호출이나 특정 상태에 종속되어 있는 관계입니다.

  • isContentValid가 true를 반환해야만 getMessageText를 안전하게 호출할 수 있는 구조적 결합
  • 변경 시 두 함수를 동시에 수정해야 하므로 휴먼 에러 발생 가능성 높음
Concept · 02

Function Precondition

함수가 의도한 대로 동작하기 위해 호출 전 반드시 충족되어야 하는 논리적 제약 조건입니다.

  • 본문에서는 런타임 에러(error())를 통해 전제 조건 위반을 감지
  • 컴파일 타임에 검증할 수 없는 제약 조건이 늘어날수록 코드의 위험도 증가
Concept · 03

Single Source of Truth

동일한 논리나 데이터를 중복 없이 한 곳에서 관리하여 데이터 불일치를 방지하는 설계 원칙입니다.

  • 검증 로직을 변환 로직에 통합하여 유효성 판단의 기준을 일원화
  • 코드 수정 시 발생할 수 있는 영향 범위를 최소화하고 예측 가능성 향상