모바일 개발에서의 KISS — 개념, 단순성 원칙 및 적용 방법

KISS란 무엇인가?

KISS(Keep It Simple, Stupid)는 시스템 복잡성을 최소화할 것을 요구하는 설계 원칙입니다. 1960년대 미 해군에서 엔지니어 켈리 존슨(Lockheed SR-71 Blackbird)에 의해 공식화되었습니다. 존슨은 항공기가 특별한 도구 없이 현장에서 정비사에 의해 수리 가능해야 한다고 주장했습니다. 이것이 KISS의 본질입니다.

소프트웨어 개발에서 KISS는 다음을 의미합니다. 해결책은 가능한 한 간단해야 하지만, 더 간단해서는 안 됩니다(문구의 후반부는 알베르트 아인슈타인에게 귀속됩니다). 단순성은 원시성의 동의어가 아닙니다. 간단한 해결책은 최소한의 중복성으로 작업을 수행합니다.

Google Research(2022)의 연구에 따르면, KISS를 준수하는 프로젝트에서 새로운 개발자의 평균 온보딩 시간은 3주인 반면, 과도한 아키텍처를 가진 프로젝트에서는 10주였습니다. 간단한 코드는 새로운 팀 구성원의 적응 속도에 대한 투자입니다.

KISS를 필터로 사용하십시오. 새로운 추상화를 추가하기 전에 스스로에게 물어보십시오. “이것이 오늘 존재하는 문제를 해결하는가, 아니면 1년 후에 발생할 수 있는 문제를 해결하는가?” 후자라면 실행하지 마십시오.

KISS와 오컴의 면도날

오컴의 면도날(14세기)은 철학적 원칙입니다. “필요 없이 존재를 늘려서는 안 된다.” 프로그래밍에서 이것은 다음을 의미합니다. 요구사항을 동등하게 충족하는 두 해결책 중에서 존재(클래스, 모듈, 의존성)가 더 적은 것을 선택하십시오. KISS는 코드에서 오컴의 면도날을 실용적으로 구현한 것입니다.

차이점은 오컴의 면도날이 인식의 일반 원칙인 반면, KISS는 측정 가능한 결과를 가진 구체적인 엔지니어링 관행이라는 점입니다. 순환 복잡도 감소, 코드 라인 수 감소, 코드 리뷰 시간 단축 등입니다. 메트릭을 통해 KISS 준수 여부를 객관적으로 평가할 수 있습니다.

다음 메트릭을 따르십시오. 새로운 개발자가 주석 없이 1분 이내에 코드 조각을 이해할 수 있으면 코드가 “충분히 간단한” 것으로 간주됩니다. 더 많은 시간이 필요하면 단순화하십시오.

모바일 개발에서 단순성이 중요한 이유는 무엇인가?

모바일 개발에는 KISS를 특히 중요하게 만드는 세 가지 특징이 있습니다. 제한된 장치 리소스(메모리, CPU), 빈번한 플랫폼 업데이트(iOS는 매년, Android는 분기별), CI/CD를 통한 빠른 기능 제공의 필요성입니다. 복잡한 코드는 이 속도를 따라갈 수 없습니다.

Apple WWDC 2023: “Embrace Swift Generics”의 분석에 따르면, 평균 iOS 프로젝트에는 40–60%의 “데드 코드”, 즉 “미래를 위해” 작성되었지만 전혀 사용되지 않는 추상화가 포함되어 있습니다. 이 코드는 바이너리 크기를 증가시킬 뿐만 아니라 컴파일을 늦추고 탐색을 복잡하게 만듭니다. KISS는 이를 방지합니다. 지금 필요한 것만 작성하십시오.

Android Developer Relations Report(2024)에 따르면, 코드 대 테스트 비율이 낮은(1:0.8 미만) 프로젝트는 프로덕션 버그가 67% 더 많습니다. 복잡한 코드는 테스트하기 어렵습니다. 이것은 품질에 대한 직접적인 위협입니다. 단순성은 높은 테스트 커버리지의 전제 조건입니다.

메트릭을 통해 코드의 복잡성을 측정하십시오. 순환 복잡도는 각 메서드를 10 미만으로 유지하고, 이상적으로는 5 미만으로 유지하십시오. 자동 검사에는 Detekt(Android) 또는 SwiftLint(iOS)를 사용하십시오.

KISS 대 오버엔지니어링: 실제 사례

과도한 아키텍처: 너무 많은 계층

일반적인 오버엔지니어링은 단일 데이터 소스를 가진 프로젝트에서 추상 리포지토리 팩토리를 만드는 것입니다. 간단한 Repository 클래스 대신 개발자는 RepositoryFactory → IRepository → BaseRepository → RepositoryImpl의 체인을 구축합니다. 이는 API를 GraphQL로 변경할 가상적인 가능성을 위한 것입니다.

JetBrains Developer Survey(2023)에 따르면, 43%의 Android 개발자가 리팩토링 중에 아키텍처 계층을 제거했다고 인정했습니다. 그것이 전혀 사용되지 않았기 때문입니다. KISS는 말합니다. 추상화는 구현의 두 번째 옵션이 등장할 때 만들어야 하지, 미리 만들어서는 안 됩니다.

인터페이스 없이 구체적인 구현부터 시작하십시오. 두 번째 데이터 소스가 등장하면 리팩토링을 통해 인터페이스를 추출하십시오(IDE가 자동으로 수행합니다). 이것은 미리 인터페이스를 작성하는 것보다 빠릅니다.

과도하게 복잡한 의존성 주입 그래프

DI 프레임워크(Dagger, Hilt, Swinject)는 강력한 도구이지만 종종 복잡성을 유발합니다. 개발자는 한 곳에서만 사용되더라도 각 엔티티에 대해 별도의 모듈을 만듭니다. KISS 대안: 간단한 경우에는 생성자를 통한 수동 주입입니다.

// 오버엔지니어링: 단일 리포지토리를 위한 모듈
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS: 리포지토리가 하나인 경우 수동 주입
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

생성자에서의 수동 주입은 가장 간단한 DI 패턴입니다. 코드 생성, 애노테이션 또는 모듈이 필요하지 않습니다. 프로젝트가 5개 이상의 화면에 도달하고 수동 주입 유지보수가 어려워질 때만 전환하십시오.

Android 및 iOS에서 KISS를 적용하는 방법

Android에서의 KISS: 간단한 ViewModel과 LiveData

Android ViewModel은 과도한 복잡성의 빈번한 원천입니다. 개발자는 간단한 MutableLiveData와 postValue로 충분한 곳에 StateFlow, combine, flatMapLatest 및 변환 체인을 추가합니다. KISS는 권장합니다. 가장 간단한 해결책(LiveData)부터 시작하고, 특정 필요(상태 재설정, 디바운스)를 위해서만 복잡하게 만드십시오.

// KISS: 반응형 체인 없는 간단한 ViewModel
class ProfileViewModel : ViewModel() {
    private val _name = MutableLiveData<String>()
    val name: LiveData<String> = _name

    fun loadUser(id: String) {
        viewModelScope.launch {
            _name.postValue(repo.getUser(id).name)
        }
    }
}

이 예제에서 ViewModel은 비동기 요청에 코루틴을 사용하고 결과 게시에 LiveData를 사용합니다. StateFlow도 combine도 없이 실제로 필요한 것만 있습니다. 명시적 상태를 가진 단방향 데이터 흐름(UDF)이 필요할 때 추가하십시오.

iOS에서의 KISS: 클래스 대신 간단한 구조체

iOS에서 KISS 원칙은 데이터 모델에 클래스보다 구조체를 선호함으로써 나타납니다. 구조체는 값 유형이며 ARC를 통한 메모리 관리가 필요하지 않고 기본적으로 불변입니다. 클래스는 동일성(동일한 객체에 대한 두 참조)이나 상속이 필요할 때만 정당화됩니다.

// KISS: 모델에 클래스 대신 구조체
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// 오버엔지니어링: 수동 init 및 deinit이 있는 클래스
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

User 구조체는 자동으로 멤버와이즈 init, Equatable 및 Hashable 준수(모든 필드별), 불변성 및 멀티스레드 환경에서의 안전성을 얻습니다. 클래스는 수동 init, NSObject 구현이 필요하며 공유 상태를 통한 경쟁 조건에 취약합니다.

네트워크 계층의 단순성

네트워크 계층은 KISS가 자주 위반되는 또 다른 영역입니다. 개발자는 5개 이상의 요소로 구성된 Interceptor 체인, 추상 팩토리를 통한 직렬화 및 각 엔드포인트에 대한 매퍼를 추가합니다. KISS 해결책: 설정이 있는 하나의 URLSession과 Codable/JSON을 통한 하나의 디코딩입니다.

Apple URLSession Programming Guide(2023)에 따르면, URLSession과 Codable을 사용한 간단한 네트워크 계층은 모바일 앱 시나리오의 95%를 커버합니다. 복잡한 Interceptor 체인은 토큰 갱신, 로깅, 암호화와 같은 특정 경우에만 필요합니다.

URLSession + Codable 기반의 간단한 네트워크 계층부터 시작하십시오. “만일을 대비해”가 아니라 실제 필요가 발생할 때 Interceptor를 추가하십시오. 이렇게 하면 네트워크 계층 코드가 2–3배 줄어듭니다.

KISS를 따를 때의 일반적인 실수

단순성과 원시성의 혼동

단순성은 원시성과 같지 않습니다. 간단한 해결책은 중복성 없이 작업을 해결하는 간결하고 명확한 해결책입니다. 원시적인 해결책은 모범 사례와 건전한 아키텍처를 무시합니다. 차이점은 간단한 해결책은 확장이 쉬운 반면, 원시적인 해결책은 그렇지 않다는 점입니다.

예: 모든 화면의 유일한 엔티티로 Activity를 사용하는 것은 단순성이 아니라 원시성입니다. 단순성이란 불필요한 추상화 없이 다른 화면에 다른 Fragment를 사용하여 Navigation Component를 사용하는 것입니다. KISS는 나쁜 아키텍처를 정당화하지 않습니다.

스스로 확인하십시오. 새로운 기능을 추가할 때 코드가 변경될 수 있습니까? 그렇다면 단순성이 올바른 것입니다. 모든 기능에 모든 것을 다시 작성해야 한다면 그것은 원시성이며 즉시 리팩토링하십시오.

KISS라는 이름으로 패턴 무시하기

패턴(MVVM, MVI, Coordinator)은 복잡화가 아니라 구조화입니다. KISS는 입증된 아키텍처 패턴의 사용을 금지하지 않습니다. 금지하는 것은 과도한 사용입니다. 하나로 충분한 곳에 세 개의 패턴을 사용하는 것입니다. 황금 중용은 프로젝트당 하나의 아키텍처 패턴과 2–3개 이하의 보조 패턴(DI, Navigation)입니다.

State of Mobile Architecture Report(2024)에 따르면, 정확히 하나의 아키텍처 패턴을 사용하는 프로젝트는 3개 이상의 패턴을 혼합한 “프랑켄슈타인” 프로젝트보다 개발 첫해에 버그가 34% 적습니다. 모바일 프로젝트에는 MVVM 또는 MVI를 선택하고 모든 화면에서 일관되게 사용하십시오.

동일한 프로젝트에서 MVVM과 MVI를 혼합하지 마십시오. 팀이 MVVM을 선택했다면 전체 프로젝트가 MVVM을 따라야 합니다. 예외는 자체 아키텍처 결정을 가진 개별 기능 모듈이지만 이것은 의식적인 선택이어야 합니다.