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