앱 개발에서의 YAGNI: 개념, 원칙의 본질 및 실질적 이점

YAGNI란?

YAGNI(You Aren't Gonna Need It) — “그것은 필요하지 않을 것이다”라는 뜻의 익스트림 프로그래밍(XP) 원칙입니다. 규칙은 다음과 같습니다: 현재 사용자 스토리에서 요구하지 않는 기능은 절대 구현하지 마십시오. 오늘 필요하지 않은 기능은 “혹시 몰라”라도 만들지 마십시오.

이 용어는 XP 방법론의 공동 저자 중 한 명인 Ron Jeffries(Kent Beck과 함께)에 의해 만들어졌습니다. Jeffries는 말했습니다: “작동하는 가장 간단한 것을 구현하고 필요할 때까지 아무것도 추가하지 마십시오.” YAGNI는 계획의 금지가 아니라 조기 구현의 금지입니다.

Standish Group CHAOS Report(2023)에 따르면, 평균 소프트웨어 제품의 64% 기능은 거의 또는 전혀 사용되지 않습니다. 모바일 앱에 적용하면 — 작성된 코드의 절반 이상이 사용자에게 가치를 제공하지 않습니다. YAGNI는 이러한 자원 낭비를 방지합니다.

YAGNI를 엄격한 필터로 적용하십시오: 모든 기능은 “지금 어떤 특정 사용자 문제를 해결하는가?”라는 질문에 답해야 합니다. 답이 없다면 — 그 기능은 필요하지 않습니다.

YAGNI와 게으름 및 지름길의 차이

YAGNI는 품질 아키텍처의 거부가 아닙니다. YAGNI는 불필요한 코드 작성을 금지하지만 올바른 코드 작성을 금지하지 않습니다. 현재 기능에 깔끔한 추상화 레이어가 필요하다면 — 만드십시오. 레이어가 필요하지 않다면 — 만들지 마십시오. 핵심 차이: YAGNI는 기능에 관한 것이지 품질에 관한 것이 아닙니다.

개발자들은 종종 YAGNI를 의도적인 기술 부채 축적과 혼동합니다(기술 부채는 항상 타협이며, YAGNI는 효율성의 원칙입니다). 차이점은 기술 부채는 인식되고 문서화되는 반면, YAGNI 위반은 단순한 추가 작업이라는 점입니다.

자문해 보십시오: “지금 이 추상화를 만들지 않으면, 필요할 때 리팩토링에 얼마나 시간이 걸릴까?” 리팩토링 시간이 지금 작성 시간보다 짧다면 — 연기하십시오.

모바일 프로젝트에 YAGNI가 중요한 이유

모바일 개발은 세 가지 이유로 YAGNI 위반에 특히 민감합니다: APK/IPA 크기는 설치 전환율에 직접 영향을 미치고, 모바일 프로젝트의 컴파일 시간은 코드 볼륨에 따라 선형적으로 증가하며, 각 추가 기능은 실패 지점을 추가합니다. YAGNI는 게으름에 관한 것이 아니라 집중에 관한 것입니다.

Google Play Console Data(2023)의 연구에 따르면: APK 크기 10MB마다 설치 확률이 1.2% 감소합니다. 사용되지 않는 코드는 저장소의 쓰레기일 뿐만 아니라 — 직접적인 금전적 손실입니다. “나중에 추가할 수도 있는” 기능을 위한 추가 라이브러리는 APK 비대화의 가장 흔한 원인입니다.

Gradle Build Performance Report(2024)에 따르면, Android 프로젝트의 각 추가 모듈은 전체 빌드 시간을 3~7초 증가시킵니다. “혹시 몰라” 5개의 모듈을 추가하면 — 빌드 시간 증가는 빌드당 15~35초가 됩니다. 1년 동안 5명의 개발자 팀은 컴파일을 기다리며 최대 200인시를 잃습니다.

CI에서 바이너리 크기를 모니터링하십시오: 경고 한도를 설정하십시오(예: 커밋당 +500KB). 새 기능 없이 크기가 증가했다면 — 코드 리뷰에서 논의해야 할 YAGNI 위반입니다.

YAGNI와 골드 플레이팅: 실전 예제

골드 플레이팅: 조기 애니메이션

골드 플레이팅 — 제품을 “개선”하려는 시도로 요구 사항 이상의 기능을 추가하는 것입니다. 전형적인 예: 디자인이 단순한 페이드를 지정했음에도 불구하고 개발자가 화면 간 복잡한 전환 애니메이션을 추가합니다. 애니메이션에 2일이 걸리고 사용자는 알아채지 못하며, 다양한 기기에서의 버그가 수년간 프로젝트를 괴롭힙니다.

UX Collective Annual Report(2023)에 따르면, 사용자의 78%는 애니메이션이 아니라 속도와 안정성으로 앱을 평가합니다. YAGNI가 말합니다: 애니메이션이 요구 사항에 명시되지 않았다면 — 구현하지 마십시오. 디자이너는 UX 문제를 해결하기 위해 실제로 필요할 때 애니메이션을 추가할 것입니다.

목업에 있는 것만 구현하십시오. 디자이너가 애니메이션을 그리지 않았다면 — 존재해서는 안 됩니다. 목업에서의 이탈은 모두 YAGNI 위반입니다.

20개 언어로의 조기 현지화

스타트업의 흔한 실수: “미래의 국제 시장 진출을 위해” 즉시 20개 이상의 언어를 지원하는 것입니다. YAGNI는 권장합니다: 현재 시장의 언어로만 현지화하십시오. 새 언어를 추가할 때마다 번역가 시간, 문자열 잘림 테스트 및 RTL 레이아웃 디버깅이 필요합니다.

Deloitte Digital Globalization Survey(2022)에 따르면, 모바일 앱의 60%는 첫 시장을 벗어나지 못합니다. 그것이 귀하의 경우라면 — 다국어 지원에 사용된 자원은 낭비됩니다. YAGNI 접근법: 영어(기본) + 대상 시장 언어. 나머지는 — 실제로 지역에 진출할 때.

우선순위 설정에 YAGNI를 사용하십시오: 기능이 향후 두 분기의 로드맵에 없다면 — 시작하지 마십시오. 로드맵은 문서화되고 제품 관리자의 승인을 받아야 합니다.

Android 및 iOS에서 YAGNI 적용 방법

Android에서의 YAGNI: 불필요한 라이브러리 추가 금지

Android 프로젝트는 라이브러리 인플레이션으로 고통받습니다. 개발자들은 비즈니스 로직의 첫 줄을 작성하기도 전에 Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore를 추가합니다. YAGNI는 권장합니다: 예방적으로가 아니라 실제 필요에 따라 라이브러리를 추가하십시오.

// YAGNI 위반: 라이브러리의 예방적 포함
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// 그리고 앱은 지금 단순히 "Hello World"를 표시합니다

라이브러리는 자체 복잡성을 가진 종속성입니다. 각각은 버전 업데이트, 주요 변경 시 마이그레이션이 필요하며 APK 크기를 증가시킵니다. 추가하십시오 해당 라이브러리가 해결하는 특정 작업이 발생할 때 라이브러리를. OkHttp(최소 HTTP 클라이언트)로 시작하고, REST 클라이언트가 필요할 때 Retrofit을 추가하는 식으로 진행하십시오.

iOS에서의 YAGNI: SwiftUI 강제 금지

SwiftUI는 강력한 프레임워크이지만, 그 채택은 실제 필요에 의해 주도되어야 합니다. 프로젝트가 iOS 14+로 시작하고 맞춤 UI 구성 요소 요구 사항이 최소라면 — SwiftUI는 좋은 선택입니다. 프로젝트가 iOS 13을 지원해야 하거나 복잡한 맞춤 제스처가 필요하다면 — UIKit이 올바른 솔루션으로 남습니다. YAGNI는 “유행이니까”라는 이유로 SwiftUI로 마이그레이션하는 것에 반대합니다.

// YAGNI: SwiftUI에서 실제 이점이 없으면 UIKit 사용
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "프로필"
    }
}

// SwiftUI가 필요하면 — UIHostingController를 통해 통합
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Point-Free: “SwiftUI vs UIKit Decision Guide”(2024)의 분석은 권장합니다: 명확한 비즈니스 이유(예: 디자이너를 위한 Live Preview 필요) 없이 기존 UIKit 화면을 SwiftUI로 마이그레이션하지 마십시오. 작동하는 코드를 다시 작성하는 것은 직접적인 YAGNI 위반입니다. SwiftUI — 새 화면용, UIKit — 기존 화면용.

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

나쁜 아키텍처의 변명으로서의 YAGNI

가장 위험한 실수는 나쁜 아키텍처의 변명으로 YAGNI를 사용하는 것입니다. “리포지토리 레이어를 만들지 않겠습니다. YAGNI니까 — ViewModel에 직접 쿼리를 작성하겠습니다.” 이것은 YAGNI가 아니라 기술 부채를 축적하는 것입니다. YAGNI는 불필요한 기능을 금지하지만 아키텍처 무결성을 금지하지는 않습니다.

아키텍처는 유지보수성에 대한 투자입니다. 3개 이상의 화면을 작성하고 있다면 — 기본 아키텍처 레이어(MVVM, 리포지토리)는 이미 정당화됩니다. 1개의 화면이라면 — 더 간단한 접근 방식을 취할 수 있습니다. 핵심: 현재 기능에 필요한 아키텍처 최소치를 결정하고 더 이상 추가하지 마십시오.

결정을 “아키텍처”와 “기능”으로 나누십시오. 아키텍처 결정(레이어, 탐색, DI)은 YAGNI의 적용을 받지 않습니다 — 유지보수성에 필요합니다. 기능 결정(기능, 스크린샷, 애니메이션)은 적용을 받습니다.

API 작업 시 YAGNI의 맹목적인 적용

또 다른 극단 — 미래 API 계약을 무시하는 것입니다. 개발자가 백엔드에서 5개 필드가 있는 JSON을 받고 “YAGNI에 따르면 나머지는 필요하지 않다”며 3개만 파싱합니다. 문제: 필드가 추가되면 응답이 변경된 경우 백엔드가 파싱을 깨뜨릴 수 있습니다. 해결책은 모든 응답 필드를 매핑하는 것입니다. 지금 모두 사용되지 않더라도 말입니다.

Meta API Design Guidelines(2023)에 따르면, 클라이언트는 서버가 반환하는 모든 필드를 파싱하고 사용되지 않는 것은 무시하지만 전체 구조를 폐기해서는 안 됩니다. YAGNI는 여기서 다른 것에 관한 것입니다: “백엔드가 반환할지도 모르니까” 아직 사양에 없는 필드의 처리를 추가하지 마십시오.

전체 응답 구조를 파싱하십시오(서버가 현재 반환하는 모든 필드). 현재 API 사양에 없는 필드의 처리는 추가하지 마십시오. 이것은 YAGNI와 변경에 대한 복원력 사이의 균형입니다.