---
id: "유연한 단순함 20260318"
created: "2026-03-18 09:22"
tags:
aliases:
---
## 💡 생각  
복잡하게 생각하지 말고 단순하게 개발하되 유연한 코드를 만들어야한다.

---

### 1. '미리 구현하는 것'과 '길을 열어두는 것'의 차이

업스케일링을 염두에 둔다는 것이 처음부터 복잡한 분산 처리 시스템이나 거대한 프레임워크를 도입하라는 뜻이 아닙니다.

- **나쁜 설계 (과잉 엔지니어링):** "나중에 사용자가 100만 명이 될지 모르니, 지금 당장 Redis 캐시를 붙이고 마이크로서비스로 쪼개자!" → **단순함 위반 (YAGNI)**
    
- **좋은 설계 (확장성 고려):** "지금은 로컬 DB를 쓰지만, 나중에 DB가 바뀌거나 서버가 늘어날 수 있으니 **로직과 데이터 접근 코드를 분리**해두자." → **유연한 단순함**
    

즉, **나중에 고치기 힘들게 코드를 꼬아놓지 않는 것** 자체가 업스케일링을 준비하는 가장 단순한 방법입니다.

### 2. 파레토 법칙의 재해석

데이터가 늘어날 때 문제가 생기는 지점은 대개 전체 코드의 20%도 안 됩니다.

- **단순화:** 80%의 일반적인 로직은 최대한 읽기 쉽고 단순하게 짭니다.
    
- **업스케일링 대비:** 나머지 20%의 핵심 로직(예: 데이터 조회, 대량 처리)에서 **확장 가능한 패턴(Interface 사용, 비동기 처리 등)**을 적용하는 것입니다.
    

이것은 모든 곳에 힘을 주는 것이 아니라, **성능의 급소가 될 만한 곳에만 최소한의 설계적 장치**를 해두는 전략입니다.

### 3. '버티는 코드'의 진짜 의미: 가독성

역설적이게도 데이터가 늘어나서 문제가 생겼을 때, 그 문제를 가장 빨리 해결할 수 있는 코드는 **단순한 코드**입니다.

- 코드가 단순하면 어디가 병목인지 금방 찾을 수 있습니다.
    
- 코드가 단순하면 최적화된 알고리즘으로 교체하기가 매우 쉽습니다.
    
- 반면, 미리 업스케일링을 한답시고 복잡하게 짜놓은 코드는 정작 문제가 터졌을 때 수정하기가 훨씬 어렵습니다.

## 📝 노트
> [!note]
> 
> - **"추측에 근거해서 미리 복잡한 기능을 만들지 말되(단순함), 나중에 그 기능을 개선해야 할 때 코드 전체를 갈아엎지 않아도 되게끔 '벽'을 잘 세워두라(확장성)"**
>

---
