볼륨 삭제
This commit is contained in:
@@ -1,50 +0,0 @@
|
||||
---
|
||||
id: 80대20 원칙(The Pareto Principle) 20260318
|
||||
created: 2026-03-18 10:08
|
||||
tags:
|
||||
- 클린코드
|
||||
aliases:
|
||||
---
|
||||
## 💡 생각
|
||||
코드를 단순화하는 것은 어려운 일이기 때문에 모든 코드를 단순화하는 것은 엄청난 낭비가 될 수 있다.
|
||||
그렇기 때문에 전체 가치의 80%를 창출해내는 20%의 자주 쓰이는 코드를 단순화하는 것에 집중해야 한다.
|
||||
|
||||
## 🔗 관련 노트
|
||||
- [[단순한 코드]], [[파레토의 법칙]](80:20의 법칙)
|
||||
|
||||
---
|
||||
|
||||
## 저자가 80:20의 법칙을 언급하는 이유
|
||||
### 1. 노력 대 결과의 불균형
|
||||
|
||||
프로그래밍에서 80%의 가치는 전체 노력의 20%만 들여도 달성할 수 있다는 점을 강조합니다.
|
||||
|
||||
- **핵심 기능 우선:** 사용자에게 진짜 필요한 핵심 기능(20%)을 먼저 완벽하게 만드는 것이, 나머지 잔기능(80%)에 매달리는 것보다 훨씬 가치 있습니다.
|
||||
|
||||
- **복잡성의 함정:** 나머지 20%의 가치(예외 케이스, 아주 희귀한 최적화 등)를 채우기 위해 전체 노력의 80%를 쏟아붓는 순간, 코드는 급격히 복잡해지고 유지보수가 불가능해집니다.
|
||||
|
||||
### 2. '충분히 좋은(Good Enough)' 코드
|
||||
|
||||
저자는 **완벽함은 단순함의 적**이라고 말합니다.
|
||||
|
||||
- [[파레토의 법칙]]에 따르면, 100% 완벽한 코드를 만들려는 노력은 비효율적입니다.
|
||||
|
||||
- 대신 **80%의 성능과 안정성**을 보장하는 [[단순한 코드]]를 빠르게 작성하고, 실제 문제가 발생하는 지점만 나중에 정밀하게 타격(최적화)하는 것이 훨씬 똑똑한 전략입니다.
|
||||
|
||||
### 3. 기능 구현에서의 80/20
|
||||
|
||||
새로운 기능을 추가할 때도 이 법칙이 적용됩니다.
|
||||
|
||||
- [[YAGNI(You Ain't Gonna Need It)]]와의 연결: "혹시 필요할지 모르는" 기능들을 다 넣으려 하지 마세요. 실제 사용자는 제공된 기능의 20%만 주로 사용합니다.
|
||||
|
||||
- 그 20%의 기능을 **가장 단순하고 견고하게** 만드는 데 집중하는 것이 이 장의 핵심 레슨입니다.
|
||||
|
||||
---
|
||||
|
||||
> [!note] 왜 자꾸 20%의 코드에 집중해야한다고 강조하느냐면 단순한 코드를 작성하는 것은 쉬운일이 아니기 떄문입니다.
|
||||
|
||||
- "모든 곳을 단순하게 만들려고 애쓰는 것 자체가 복잡함의 시작이다. 진짜 중요한 20%만 단순하게 유지하고 나머지는 최소한의 노력만 들여라."
|
||||
|
||||
- "단순함은 기술(Skill)이고, 파레토 법칙은 그 기술을 사용할 전략(Strategy)이다. 전략 없는 기술은 개발자를 지치게 만든다."
|
||||
|
||||
- "단순함은 복잡함보다 어렵다. 생각을 명확히 해서 단순하게 만들려면 정말 열심히 노력해야 한다." - 스티브잡스
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
id: 단순함의 노하우 20260317
|
||||
created: 2026-03-17 10:53
|
||||
tags:
|
||||
- 클린코드
|
||||
---
|
||||
## 💡 생각
|
||||
> [!note] 코드는 무조건 단순해야 한다. 단순한 코드란 읽기 쉽고 명확한(가독성이 좋은) 코드다.
|
||||
|
||||
[[단순한 코드]] ?
|
||||
[[파레토의 법칙]]을 프로그래밍에 응용
|
||||
|
||||
##### - 모든 코드를 100%의 노력으로 완벽하고 좋은 성능으로 만들려고 하면 많은 리소스 (인력이든 시간이든 뭐든..)를 필요로 하게 됨.
|
||||
프로그램 실행 시간의 80%는 단 20%의 코드(핵심 알고리즘, 반복문 등)에서 소비됩니다. 따라서 나머지 80%의 코드는 성능을 위해 복잡하게 짤 필요 없이, **최대한 단순하고 읽기 쉽게** 유지하는 것이 이득입니다.
|
||||
##### - 80% 의 자주 쓰지 않는 코드에 집중하고 자원을 낭비하지 말라.
|
||||
훌륭한 구조를 가지고 좋은 성능을 보이는 코드라고 하더라도 **자주 쓰이지 않고** **코드 작성에 너무 많은 시간을 들였다면** 그것은 과도한 낭비가 될 가능성이 높다.
|
||||
[[YAGNI(You Ain't Gonna Need It)]]
|
||||
- 지금 필요 없는 건 하지 마라.
|
||||
|
||||
### 선택과 집중이 필요하다.
|
||||
- **불필요한 최적화 거부:** 병목 지점이 아닌 나머지 80%의 코드를 최적화하느라 코드를 꼬아놓지 마세요. 그 부분은 그냥 **단순함** 그 자체로 두는 것이 유지보수에 훨씬 유리합니다.
|
||||
|
||||
- **복잡성 격리:** 정말 성능이 중요해서 복잡한 로직이 들어가야 한다면, 그 20%의 영역만 따로 분리(격리)하고 나머지는 깨끗하게 유지하세요.
|
||||
|
||||
> [!note] "80%의 효과를 내는 20%의 단순한 로직을 먼저 작성하라."
|
||||
|
||||
|
||||
### 결국 저자가 하고 싶은 말은
|
||||
1. 불필요한 단계를 최대한 제거하고
|
||||
2. 사람이 읽기 좋은 형태로 바꿔주고
|
||||
3. 알고리즘 최적화하는것
|
||||
|
||||
저자인 크리스티안 마이어가 경계하라고 강조하는 것
|
||||
> [!warning] "0.001초를 줄이려고 코드 10줄을 50줄로 늘리며 가독성을 해치는 행위"
|
||||
|
||||
이런 경우는 최적화가 단순화를 **방해**하는 상황이 됩니다. 반대로 **복잡한 계산식을 수학적으로 정리해 한 줄로 줄이는 것**은 최적화이자 동시에 완벽한 단순화가 되는 것이죠.
|
||||
|
||||
## 사람이 읽기 좋은 코드...? [[코드의 가독성]]
|
||||
> [!question]
|
||||
> Q. 사람이 읽기 좋은 형태의 코드라는건 어떤걸 의미하는거야?
|
||||
> A. 사람이 읽기 좋은 코드, 즉 **가독성이 높은 코드**는 단순히 "예쁜 코드"를 넘어 **코드를 읽는 사람의 뇌가 에너지를 최소한으로 쓰게 만드는 코드**를 의미합니다.
|
||||
|
||||
## 그리고 데이터가 늘어나도 잘 버티는 코드
|
||||
데이터가 늘어나도 잘 버티는 코드는 보통 **확장성(Scalability)** 이 좋은 코드라고 부릅니다.
|
||||
|
||||
데이터가 10건일 때는 0.001초 만에 끝나던 로직이, 데이터가 100만 건으로 늘어났을 때도 서비스가 죽지 않고 합리적인 시간 내에 결과를 내놓는 것을 의미합니다.
|
||||
|
||||
> [!question]
|
||||
> Q. 일단은 단순하게 만들고 나중에 문제가 생길경우에 집중해서 개선하라고 앞에서 계속 그러다가 갑자기 업스케일링을 염두해둬야한다는 말을 하면 앞뒤가 잘 안맞는거 아니야? 업스케일링에 유리한 코드를 미리 설계하고 개발하는거 자체도 일일텐데?
|
||||
> A. 정말 날카롭고 합리적인 지적입니다! "일단 단순하게 만들라"는 말과 "나중에 커질 것을 대비(확장성/업스케일링)하라"는 말이 얼핏 들으면 서로 충돌하는 것처럼 느껴질 수 있습니다.
|
||||
>
|
||||
> 하지만 이 책과 클린 코드의 철학이 말하는 핵심은 [[유연한 단순함]]에 있습니다.
|
||||
|
||||
"지금 당장 필요하지 않은 기능(Over-engineering)은 넣지 않되, 나중에 그 기능을 넣고 싶을 때 코드 전체를 부수지 않아도 되게 끔 '문(Interface/Module)'만 잘 만들어 두는 것"
|
||||
@@ -1,74 +0,0 @@
|
||||
---
|
||||
id: 유닉스 철학 (The Unix Philosophy) 20260330
|
||||
created: 2026-03-30 15:20
|
||||
tags:
|
||||
---
|
||||
# 개념
|
||||
[[유닉스(Unix)]] 개발자들 사이에서 내려오는 유명한 원칙이 있습니다. 바로 **작고 단순한 것이 아름답다**는 점입니다.
|
||||
|
||||
1. **각 프로그램은 한 가지 일만 잘해야 한다.**
|
||||
|
||||
2. **여러 프로그램을 조합해서 복잡한 문제를 해결한다.** (이때 사용하는 것이 **파이프(|)** 기능입니다.)
|
||||
|
||||
3. **모든 것은 파일이다.** (텍스트 파일로 설정을 관리하고 데이터를 주고받습니다.)
|
||||
|
||||
> [!note] 단순히 운영체제를 만드는 기술적 규칙이 아니라, 소프트웨어를 설계하고 문제를 해결하는 일종의 **미니멀리즘 예술**에 가깝습니다.
|
||||
|
||||
: 1970년대 벨 연구소의 더글러스 매킬로이(Douglas McIlroy)가 정립한 이 철학의 핵심은 **작고 단순하며, 서로 협력하는 도구**를 만드는 것입니다.
|
||||
|
||||
|
||||
## 1. 핵심 3원칙
|
||||
|
||||
더글러스 매킬로이는 유닉스 철학을 다음 세 문장으로 요약했습니다.
|
||||
|
||||
- **한 가지만 하되, 아주 잘하라 (Do One Thing and Do It Well):** 하나의 프로그램은 오직 하나의 기능에만 집중해야 합니다. 기능이 많아지면 복잡해지고 버그가 생기기 쉽기 때문입니다.
|
||||
|
||||
- **함께 작동하도록 만들어라 (Expect the output of every program to become the input to another):** 프로그램은 서로 연결될 것을 예상하고 만들어야 합니다.
|
||||
|
||||
- **텍스트 스트림을 표준 인터페이스로 사용하라:** 데이터는 가공하기 가장 쉬운 **텍스트** 형태로 주고받아야 합니다. 그래야 서로 다른 프로그램끼리 쉽게 대화할 수 있습니다.
|
||||
|
||||
|
||||
## 2. 파이프(Pipe)와 필터
|
||||
|
||||
유닉스 철학을 시각적으로 가장 잘 보여주는 것이 바로 **파이프(|)** 기호입니다. 작은 도구들을 파이프로 연결하여 복잡한 일을 수행하는 방식이죠.
|
||||
|
||||
> **예시:** `ls | grep "test" | sort`
|
||||
>
|
||||
> 1. `ls`: 파일 목록을 출력한다. (한 가지 일)
|
||||
>
|
||||
> 2. `grep`: 그중 "test"가 포함된 것만 골라낸다. (한 가지 일)
|
||||
>
|
||||
> 3. `sort`: 결과를 알파벳 순으로 정렬한다. (한 가지 일)
|
||||
>
|
||||
|
||||
각각은 단순한 도구일 뿐이지만, 연결하면 강력한 기능을 수행합니다. 이는 마치 레고 블록을 조립하는 것과 비슷합니다.
|
||||
|
||||
## 3. 에릭 레이먼드의 룰 (Rule of...)
|
||||
|
||||
오픈소스 전도사인 에릭 레이먼드는 그의 저서에서 유닉스 철학을 더 구체적인 규칙으로 확장했습니다.
|
||||
|
||||
- **단순함의 법칙 (Rule of Simplicity):** 복잡해지기 전까지 최대한 단순하게 설계하라.
|
||||
|
||||
- **명확함의 법칙 (Rule of Clarity):** 코드는 컴퓨터가 읽기 쉬운 것보다 사람이 읽기 쉬운 것이 더 중요하다.
|
||||
|
||||
위의 두 법칙을 지킴으로써 코드가 [[KISS (Keep It Simple, Stupid)]]해진다.
|
||||
|
||||
- **조합의 법칙 (Rule of Composition):** 프로그램이 다른 프로그램과 쉽게 연결될 수 있도록 설계하라.
|
||||
|
||||
조합의 법칙을 지키다 보면 코드가 [[DRY (Don't Repeat Yourself)]]해진다.
|
||||
|
||||
- **침묵의 법칙 (Rule of Silence):** 프로그램이 정말로 할 말이 없을 때는 아무것도 출력하지 마라. (그래야 다른 프로그램이 출력을 가공하기 좋습니다.)
|
||||
|
||||
유닉스 철학을 구체화 한 규칙들을 지킴으로써 [[클린코드의 기술]]들을 지키게 된다.
|
||||
|
||||
---
|
||||
|
||||
## 4. 왜 유닉스 철학이 중요한가요?
|
||||
|
||||
오늘날 현대적인 소프트웨어 개발 방법론인 **마이크로서비스 아키텍처(MSA)** 나 **함수형 프로그래밍**의 뿌리도 이 유닉스 철학에 닿아 있습니다.
|
||||
|
||||
- **유지보수 용이:** 작고 단순한 코드는 고치기 쉽습니다.
|
||||
|
||||
- **재사용성:** 잘 만들어진 작은 도구는 여기저기서 다시 쓰일 수 있습니다.
|
||||
|
||||
- **확장성:** 새로운 기능을 추가할 때 기존 프로그램을 수정하는 대신, 새로운 도구를 만들어 연결하면 됩니다.
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
id: 최소 기능 제품 (MVP) 20260320
|
||||
created: 2026-03-20 14:00
|
||||
tags:
|
||||
---
|
||||
**M**inimum **V**iable **P**roduct , 최소 기능 제품
|
||||
![[MVP(Minimum Viable Product)#📑 개념]]
|
||||
|
||||
### MVP의 핵심: "완벽함보다 실행"
|
||||
|
||||
저자는 개발자가 빠지기 쉬운 가장 큰 함정이 **모든 기능을 다 갖춰야 출시할 수 있다**는 생각이라고 지적합니다.
|
||||
|
||||
- **MVP의 정의:** 고객에게 가치를 전달할 수 있는 **최소한의 핵심 기능**만 담은 제품입니다.
|
||||
|
||||
- **개발자 버전 MVP:** 복잡한 아키텍처나 부가 기능(로깅, 화려한 UI, 상세 설정 등)을 다 붙이기 전에, **비즈니스 로직의 핵심**이 돌아가는 가장 단순한 형태의 코드를 먼저 완성하는 것입니다.
|
||||
|
||||
### 왜 MVP가 클린 코드와 연결될까요?
|
||||
|
||||
단순히 빨리 만드는 게 목적이 아닙니다. MVP 방식으로 개발하면 다음과 같은 이점이 있습니다.
|
||||
|
||||
- **복잡성 제어:** 처음부터 거대한 시스템을 설계하면 복잡도가 기하급수적으로 늘어납니다. 작은 단위(MVP)로 시작하면 코드가 단순하게 유지됩니다.
|
||||
|
||||
- **피드백 기반 개선:** 핵심 로직을 먼저 짜서 돌려봐야 어디가 진짜 병목인지, 어디에 스케일업이 필요한지 데이터로 확인할 수 있습니다. 추측에 근거한 과잉 엔지니어링을 막아줍니다.
|
||||
|
||||
- **YAGNI 실천:** "이 기능도 필요하겠지?"라는 가설을 버리고, "이게 없으면 프로그램이 안 돌아간다"는 기능만 넣게 됩니다.
|
||||
|
||||
### MVP를 만드는 3단계 사고법
|
||||
|
||||
책에서 제안하는 실천 방안은 다음과 같습니다.
|
||||
|
||||
1. **핵심 가치 식별:** 이 프로그램이 존재해야 하는 단 하나의 이유(20%의 핵심)는 무엇인가?
|
||||
|
||||
2. **군더더기 제거:** 그 가치를 구현하는 데 당장 필요 없는 모든 기능(80%)을 목록에서 지운다.
|
||||
|
||||
3. **반복 개선:** 최소한의 기능을 구현해 배포한 뒤, 실제 사용자나 시스템의 반응을 보고 살을 붙인다.
|
||||
|
||||
[[파레토의 법칙]], [[80대20 원칙(The Pareto Principle)]]
|
||||
|
||||
#### "MVP는 '덜 만든 제품'이 아니라, '가장 핵심적인 가치만 담은 가장 단순한 제품'이다."
|
||||
|
||||
> [!question]
|
||||
> Q. 왜 여기서 갑자기 MVP에 대한 설명이 나온거야?
|
||||
> A. 2장의 파레토 법칙이 어디에 집중할지 알려주는 **전략**이었다면, 3장은 그 전략을 실행하는 **전술**에 가깝습니다.
|
||||
|
||||
- 어떻게 20%에 집중할 것인가? 에 대한 해답이라는 것
|
||||
- 완벽하게 만들려다 복잡해지는 것보다, 단순하게 만들어 피드백을 받는 것이 더 빠르다.
|
||||
|
||||
|
||||
## MVP를 만드는 이유
|
||||
### 1. 피드백 루프의 단축
|
||||
MVP를 만드는 가장 큰 이유 중 하나는 **실제 데이터**를 빨리 얻기 위함입니다.
|
||||
- 머릿속으로 성능이나 확장성을 고민하기보다, 최소 기능을 배포해보고 **어디서 진짜 병목이 발생하는지** 확인하라는 것입니다.
|
||||
|
||||
- 추측에 근거한 설계보다 **측정된 데이터에 근거한 개선**이 훨씬 강력한 단순함을 만듭니다.
|
||||
|
||||
### 2. 기능의 범위를 제한하는 법 (Scope Creep 방지)
|
||||
프로젝트를 하다 보면 자꾸 기능이 추가되는 현상을 경계하라고 조언합니다.
|
||||
|
||||
- **우선순위 재정의:** 새로운 기능 요청이 들어올 때마다 **이 기능이 핵심 가치(20%)에 포함되는가?** 를 끊임없이 질문해야 합니다.
|
||||
|
||||
- **거절의 미학:** 단순함을 유지하기 위해 핵심이 아닌 기능은 과감히 목록에서 제외하거나 다음 버전으로 미루는 과정이 3장에서 중요하게 다뤄집니다.
|
||||
|
||||
> [!note] 요약
|
||||
> - **엄격한 MVP 유지:** "이 기능이 없으면 제품이 안 돌아가는가?"라는 질문에 '아니오'라면 다음 버전으로 미룹니다.
|
||||
>
|
||||
> - **20%에 집중:** 핵심 가치를 만드는 20%의 기능 외에는 모두 **잠재적인 소음**으로 간주하고 경계합니다.
|
||||
>
|
||||
> - **문서화와 소통:** 추가 요청이 들어오면 "좋은 아이디어지만, 이번 MVP 범위에는 포함되지 않습니다. 다음 단계에 검토합시다"라고 선을 긋는 것이 중요합니다.
|
||||
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
id: 코딩 원칙 (YAGNI, KISS, DRY) 20260330
|
||||
created: 2026-03-30 14:52
|
||||
tags:
|
||||
---
|
||||
코드의 단순함을 지키기 위해 필요한 원칙 3가지
|
||||
이 3가지를 지키다 보면 단순한 코드에 한걸음 더 다가갈 수 있게 된다.
|
||||
|
||||
1. [[YAGNI(You Ain't Gonna Need It)]]
|
||||
2. [[KISS (Keep It Simple, Stupid)]]
|
||||
3. [[DRY (Don't Repeat Yourself)]]
|
||||
|
||||
> [!warning] 위의 세 원칙을 지키는 것이 중요하긴 하지만
|
||||
|
||||
**가장 중요한 것은 하나의 원칙을 지키기 위해서 다른 원칙을 어기면 안된다.**
|
||||
|
||||
|
||||
## 💡 생각
|
||||
결국, 코드를 단순하게 작성하고 가독성을 중시해야 하며 코드를 최초로 작성하는 경우에는 꼭 필요한 기능이 아니라면 다음에 작성하는 게 좋고 코드의 반복이 3번이상 있을 경우에는 DRY의 원칙을 지키는 것을 고려해야 한다.
|
||||
|
||||
불필요한 작업을 줄여서 ([[YAGNI(You Ain't Gonna Need It)]]) 비용 절감을 중시하고,
|
||||
단순한 코드를 작성해서 ([[KISS (Keep It Simple, Stupid)]]) 가독성을 높이고,
|
||||
중복되는 코드를 줄여서 ([[DRY (Don't Repeat Yourself)]]) 유지보수성을 늘리자.
|
||||
|
||||
결국 세 원칙 모두 프로젝트 비용을 줄이는데에 초점이 맞춰져 있는 원칙들이다.
|
||||
|
||||
---
|
||||
|
||||
> [!note] YAGNI > KISS > DRY
|
||||
|
||||
: 지금 이 코드가 정말로 필요한가? [[YAGNI(You Ain't Gonna Need It)]] 원칙을 지키다 보면 대부분의 불필요한 복잡성이 걸러짐.
|
||||
: [[YAGNI(You Ain't Gonna Need It)]] 통과해서 작성이 필요하다고 판단되는 코드의 경우 [[KISS (Keep It Simple, Stupid)]]원칙을 지키면서 코드를 작성한다.
|
||||
: [[KISS (Keep It Simple, Stupid)]]한 코드를 작성하고 나서 [[DRY (Don't Repeat Yourself)]]한지 판단해본다. 여기서 중요한건 DRY한 코드를 만들기 위해 KISS하지 않은 코드를 작성하면 안된다는 것이다.
|
||||
|
||||
### 왜 이 순서가 최강의 전략일까요?
|
||||
|
||||
많은 개발자가 **DRY**를 1순위로 두는 실수를 범합니다. 중복을 없애려고 너무 일찍부터 복잡한 추상화를 시작하면, 결국 쓰지도 않을 기능(**YAGNI 위반**)을 위해 이해하기 힘든 코드(**KISS 위반**)를 만들게 되거든요.
|
||||
|
||||
정리하신 대로 **YAGNI → KISS → DRY** 순으로 사고하면, 자연스럽게 **비용은 낮고 가동성은 높은** 결과물이 나옵니다.
|
||||
|
||||
---
|
||||
### 비용(Cost) 중심의 사고방식
|
||||
|
||||
지적하신 대로 이 모든 원칙의 종착역은 **비용 절감**입니다.
|
||||
|
||||
- **YAGNI:** '만드느라 드는 시간'과 '유지보수하는 시간'의 낭비를 막아 **직접적인 비용**을 줄입니다.
|
||||
|
||||
- **KISS:** 코드를 읽고 이해하는 데 드는 '뇌의 연산 비용'을 줄여서 **커뮤니케이션 비용**을 낮춥니다.
|
||||
|
||||
- **DRY:** 수정할 때 여러 곳을 고치다 실수하는 '버그 수정 비용'을 줄여서 **운영 비용**을 아낍니다.
|
||||
Reference in New Issue
Block a user