51 lines
2.4 KiB
Markdown
51 lines
2.4 KiB
Markdown
---
|
|
id: "유연한 단순함 20260318"
|
|
created: "2026-03-18 09:22"
|
|
tags:
|
|
aliases:
|
|
---
|
|
## 💡 생각
|
|
복잡하게 생각하지 말고 단순하게 개발하되 유연한 코드를 만들어야한다.
|
|
|
|
---
|
|
|
|
### 1. '미리 구현하는 것'과 '길을 열어두는 것'의 차이
|
|
|
|
업스케일링을 염두에 둔다는 것이 처음부터 복잡한 분산 처리 시스템이나 거대한 프레임워크를 도입하라는 뜻이 아닙니다.
|
|
|
|
- **나쁜 설계 (과잉 엔지니어링):** "나중에 사용자가 100만 명이 될지 모르니, 지금 당장 Redis 캐시를 붙이고 마이크로서비스로 쪼개자!" → **단순함 위반 (YAGNI)**
|
|
|
|
- **좋은 설계 (확장성 고려):** "지금은 로컬 DB를 쓰지만, 나중에 DB가 바뀌거나 서버가 늘어날 수 있으니 **로직과 데이터 접근 코드를 분리**해두자." → **유연한 단순함**
|
|
|
|
|
|
즉, **나중에 고치기 힘들게 코드를 꼬아놓지 않는 것** 자체가 업스케일링을 준비하는 가장 단순한 방법입니다.
|
|
|
|
### 2. 파레토 법칙의 재해석
|
|
|
|
데이터가 늘어날 때 문제가 생기는 지점은 대개 전체 코드의 20%도 안 됩니다.
|
|
|
|
- **단순화:** 80%의 일반적인 로직은 최대한 읽기 쉽고 단순하게 짭니다.
|
|
|
|
- **업스케일링 대비:** 나머지 20%의 핵심 로직(예: 데이터 조회, 대량 처리)에서 **확장 가능한 패턴(Interface 사용, 비동기 처리 등)**을 적용하는 것입니다.
|
|
|
|
|
|
이것은 모든 곳에 힘을 주는 것이 아니라, **성능의 급소가 될 만한 곳에만 최소한의 설계적 장치**를 해두는 전략입니다.
|
|
|
|
### 3. '버티는 코드'의 진짜 의미: 가독성
|
|
|
|
역설적이게도 데이터가 늘어나서 문제가 생겼을 때, 그 문제를 가장 빨리 해결할 수 있는 코드는 **단순한 코드**입니다.
|
|
|
|
- 코드가 단순하면 어디가 병목인지 금방 찾을 수 있습니다.
|
|
|
|
- 코드가 단순하면 최적화된 알고리즘으로 교체하기가 매우 쉽습니다.
|
|
|
|
- 반면, 미리 업스케일링을 한답시고 복잡하게 짜놓은 코드는 정작 문제가 터졌을 때 수정하기가 훨씬 어렵습니다.
|
|
|
|
## 📝 노트
|
|
> [!note]
|
|
>
|
|
> - **"추측에 근거해서 미리 복잡한 기능을 만들지 말되(단순함), 나중에 그 기능을 개선해야 할 때 코드 전체를 갈아엎지 않아도 되게끔 '벽'을 잘 세워두라(확장성)"**
|
|
>
|
|
|
|
---
|