#Mobile

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

Summary

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

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

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

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

RECOMMENDATION

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

The Problem

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

The Solution

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

The Result

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

Trade-off

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

Key Concepts

Concept · 01

Implicit Dependency

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

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

Concept · 02

Function Precondition

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

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

Concept · 03

Single Source of Truth

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

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

Continue reading · same source

More from 라인

View all posts from 라인

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

Summary