post: add

Author: chebread

content/독서/Chaos To Cosmos.md

@@ -0,0 +1,40 @@
+---
+desc: 해커와 화가 (폴 그레이엄)
+date: 2025-09-13
+category: [독서]
+published: true
+fixed: false
+---
+
+> 또 전체적인 프로그램을 미리 신중하게 적어서 생각하는 방향이 옳은지 여부를 확인하기 전에 조각난 코드부터 대책 없이 늘어놓은 다음 그것의 모양을 조금씩 잡아 나가는  방법으로 프로그래밍을 했다.  
+> 소설과, 화가, 그리고 건축가의 직업이 그런 것처럼 프로그램이란 전체 모습을 미리 알 수 있는 것이 아니라 작성해 나가면서 이해하게 되는 존재다.  
+> 프로그래밍 언어는 당신이 이미 머릿속으로 생각한 프로그램을 표현하는 도구가 아니라, 아직 존재하지 않는 프로그램을 생각해 내기 위한 도구다.  
+> 해커에게 필요한 언어는 마음껏 내갈기고, 더럽히고, 사방에 떡칠할 수 있는 언어다.  
+> — 해커와 화가
+
+그렇다. 코드는 더러워야 한다. 정결한 코드는 아무 의미가 없다. 코드는 더러움 속에서, 혼란 속에서 존재되어야만 한다. 코드에 아이디어를 떡칠해야 한다. 왜 코드 외적인 것에서 아이디어를 피력하고, 생산하는가? 항상 코드 자체에 아이디어를 적어 놓아야 한다. 프로그래머란, 오로지 코드에 어떤 것을 피력해야 한다. 코드 외적인 것에서 놀지 마라. 코드에서 놀아라. 코드는 깔끔해야 한다는 강박을 버려라. 코드는 더러워야 한다.
+
+```c
+// https://en.wikipedia.org/wiki/Fast_inverse_square_root
+float Q_rsqrt( float number )
+{
+	long i;
+	float x2, y;
+	const float threehalfs = 1.5F;
+
+	x2 = number * 0.5F;
+	y  = number;
+	i  = * ( long * ) &y;                       // evil floating point bit level hacking
+	i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
+	y  = * ( float * ) &i;
+	y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
+//	y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed
+
+	return y;
+}
+```
+
+오픈소스로 배포한다고 해도 그냥 더러운 코드를 공개하라. 왜 당신의 아이디어가 담긴 더러운 코드는 공개하기 싫은가?
+프로그래밍의 거장도 더럽게 코드를 짜고, 더러운 코드를 공개하는데 당신은 왜 깨끗하려 하는가?
+
+> Chaos to Cosmos.

content/독서/단일 책임 원칙이 무너지고 있다.md

@@ -0,0 +1,23 @@
+---
+desc: 실용주의 프로그래머 (데이비드 토머스 , 앤드류 헌트)
+date: 2025-09-13
+category: [독서]
+published: true
+fixed: false
+---
+
+> 단일 책임 원칙: 하나의 것은 하나의 일만 해야 한다.
+
+실용주의 프로그래머를 읽으며, 단일 책임 원칙을 알게 되었다.
+
+근래 단일 책임 원칙이 부서지고 있는 듯하다. AI가 각광받음에 따라, 개발자들이 모든 제품에 AI를 다 갖다 붙이는 중이다.
+
+Apple도 Xcode 26에 AI를 붙여놓았고, T월드에도 AI 추천이 있으며, 카카오 뱅크에도 AI 챗봇이 있고, 한컴에도 AI가 있고, JetBrains IDE에도 AI가 범벅되어 있다.
+
+나는 이렇게 생각한다. 모든 것은 '단일 책임 원칙'을 지켜야 한다. 도대체 왜 IDE에 AI 어시스트가 들어가야 하는가? 코드 작성에만 완전히 집중되어야 하는 것 아닌가? 개발 환경에만 완전히 집중되어야 하는 것 아닌가? 왜 굳이 쓸데없는, 이미 다른 환경을 통해 충분히 사용 가능한 AI를 거기에 굳이 붙여놓는 건가?
+
+나는 이해가 되지 않는다. 프로그램은 계속해서 가벼워지고, 빨라지고, 버그가 fix 되어야 하며, 기능은 더욱더 간단해져야 한다. 근데 왜 요즘의 프로그램들은 기능은 점점 불어나며, 이로 인해 버그는 계속해서 증가하고, 앱은 느려지며, 프로그램은 기하급수적으로 큰 용량을 차지하게 되는가? 이는 결국 기능 블로트로 이어진다.
+
+그리고 웃긴 것은, AI 랍시고 갖다 붙여 놓았으나, 막상 사용해 보면 LLM 모델에 대한 API 호출이다. 그냥 호출하고 필요에 맞게 조작해놓은 것을 AI랍시고 갖다 붙여놓은 거다. 자체 모델을 구축하려는 시도조차 하지 않는 데, 이게 뭔 AI 기능인가?
+
+시대가 아무리 봐도 역행하는 듯하다. 단일 책임 원칙은 아마 10년 전이 더 잘 지켜진 듯하다. 하나의 것은 하나의 일만 해야 한다. 하나의 것들이 모여 새로운 일을 해야 한다.

content/에세이/방어 코드를 활용하라.md content/에세이/보호 구문을 활용하라.mdcontent/에세이/방어 코드를 활용하라.md renamed to content/에세이/보호 구문을 활용하라.md

@@ -5,9 +5,9 @@ published: true
 ---
 
 추석 때 켄트 벡의 Tidy First를 읽게 되었다.
-이 책에서 첫 번째로 나오는 개념인 '방어 코드'를 설명해 보도록 하겠다.
+이 책에서 첫 번째로 나오는 개념인 '보호 구문'를 설명해 보도록 하겠다.
 
-방어 코드란, 전제조건이라고 생각하면 된다.
+보호 구문란, 전제조건이라고 생각하면 된다.
 즉, 어떤 x 로직이 돌아가기 위해서 선재적으로 만족되어야 하는 조건들을 직관적으로 명시할 수 있는 방법이다.
 
 예제가 최고의 문서이므로, 나의 [github.com/chebread/cvtr](https://github.com/chebread/cvtr) 레거시 코드를 통해 설명해 보도록 하겠다.
@@ -31,7 +31,7 @@ if len(os.Args) >= 2 {
                 ... 코드 생략 ...
 ```
 
-먼저 방어 코드로 바꾸기 위해서는 전제조건을 찾아야 한다.
+먼저 보호 구문로 바꾸기 위해서는 전제조건을 찾아야 한다.
 
 위 코드에서 전제조건으로 사용되는 코드는
 - `if len(os.Args) >= 2 { ... }`
@@ -43,9 +43,9 @@ if len(os.Args) >= 2 {
 참고로 이게 왜 전제조건이냐 하면, 이 3가지가 만족되지 않으면 로직 실행 전에 프로그램을 종료해버리기 때문이다.
 즉, 이것은 로직 실행의 선재적인 조건에 해당된다.
 
-전제조건을 찾았으면 이제 방어 코드로 바꾸면 된다.
+전제조건을 찾았으면 이제 보호 구문로 바꾸면 된다.
 
-방어 코드는 무조건 단일 if 문을 사용하며, 로직 실행 부의 최상단에 위치한다.
+보호 구문는 무조건 단일 if 문을 사용하며, 로직 실행 부의 최상단에 위치한다.
 최상단에 위치해야 하는 까닭은, 최상단에 위치해야만 그 로직 전체에 '전제 조건'으로 비춰질 수 있기 때문이다.
 
 먼저 `if len(os.Args) >= 2 { ... }` 부터 바꿔보도록 하겠다.
@@ -76,7 +76,7 @@ switch os.Args[1] {
 		boldRed("error: Not enough arguments provided\n")
 		break
 	}
-    
+
     ... 코드 ...
 }
 ```
@@ -95,12 +95,12 @@ switch os.Args[1] {
 		boldRed("error: Not enough arguments provided\n")
 		break
 	}
-    
+
 	if keyword := os.Args[4]; keyword != "to" {
 		boldRed("error: Use 'to' keyword, instead of '%s' keyword\n", keyword)
 		break
 	}
-    
+
 	... 코드 ...
 }
 ```
@@ -127,7 +127,7 @@ if len(os.Args) >= 2 {
                 ... 코드 생략 ...
 ```
 
-이게 방어 코드로 바꾼 코드이다.
+이게 보호 구문로 바꾼 코드이다.
 ```go
 if len(os.Args) < 2 {
 	help()
@@ -139,18 +139,18 @@ switch os.Args[1] {
 		boldRed("error: Not enough arguments provided\n")
 		break
 	}
-    
+
 	if keyword := os.Args[4]; keyword != "to" {
 		boldRed("error: Use 'to' keyword, instead of '%s' keyword\n", keyword)
 		break
 	}
-    
+
 	amountStr := os.Args[2]
 	sourceCurrency := os.Args[3]
 	targetCurrency := os.Args[5]
 }
 ```
 
-방어 코드를 활용한 코드가 더 읽기 쉬울 것이다.
+보호 구문를 활용한 코드가 더 읽기 쉬울 것이다.
 
-이제부터 이렇게 전제 조건으로 if문을 사용하는 경우에는 방어 코드를 적극 활용 해보기 바란다.
+이제부터 이렇게 전제 조건으로 if문을 사용하는 경우에는 보호 구문를 적극 활용 해보기 바란다.

content/에세이/해커톤을 처음 나가는 개발자들을 위한 팁.md

@@ -1,23 +1,23 @@
 ---
-date: 2022-06-05
+date: 2022-12-10
 category: [에세이]
 published: true
 ---
 
-## 주어질 주제에 대해 지나치게 신경 쓰지 마라
-나는 해커톤을 하기 몇 주 전부터 뭐가 주제로 정해질 지 많이 걱정했다. 그렇지만, 해커톤이 시작한 후 주제를 알려주는데 16가지나 주어 저 그렇게 문제가 되지는 않았다. 그러니 해커톤은 그저 개발과 아이디어만 잘 짜면 된다.
+## 주어질 주제에 대해 지나치게 신경 쓰지 마라
+나는 해커톤을 하기 몇 주 전부터 뭐가 주제로 정해질 지 많이 걱정했다. 그렇지만, 해커톤이 시작한 후 주제를 알려주는데 16가지나 주어 저 그렇게 문제가 되지는 않았다. 그러니 해커톤은 그저 개발과 아이디어만 잘 짜면 된다.
 
 ## 많이 생각하라
-해커톤이 시작되자 마자 여러 주제들을 참여자에게 전달할 것이다. 나 같은 경우는 6시간이 제공되었는데, 나는 6시간 중에 2시간을 아이디어에 쓰고 말았다
-많이 긴장한 탓인데, 그래도 꽤 좋은 아이디어를 생각해 내어 값진 결과를 얻은 것 같다
-그러니 해커톤에서 수상을 원한다면 내가 개발하기 쉬운 아이디어가 아닌 사용자를 위한 아이디어를 생각해야 한다.
+해커톤이 시작되자 마자 여러 주제들을 참여자에게 전달할 것이다. 나 같은 경우는 6시간이 제공되었는데, 나는 6시간 중에 2시간을 아이디어에 쓰고 말았다
+많이 긴장한 탓인데, 그래도 꽤 좋은 아이디어를 생각해 내어 값진 결과를 얻은 것 같다
+그러니 해커톤에서 수상을 원한다면 내가 개발하기 쉬운 아이디어가 아닌 사용자를 위한 아이디어를 생각해야 한다.
 
-나는 이것이 개발자가 지녀야할 하나의 습관이라고 생각한다. 우리가 개발을 할 때는 항상 쉽게 개발할 수 있는 아이디어만 생각한다. 나 또한 그렇다.예시로는 굳이 슬라이드 방식으로 이미지는 넘기는 보다는 버튼을 두어 개발하는 것이 편하다. 그렇지만 사용자는 슬라이드 형식으로 넘기는 형식이 매우 편할 것이다.이처럼 개발자는 사용자가 쓰기 편한 앱을 만들어야 한다.
+나는 이것이 개발자가 지녀야할 하나의 습관이라고 생각한다. 우리가 개발을 할 때는 항상 쉽게 개발할 수 있는 아이디어만 생각한다. 나 또한 그렇다.예시로는 굳이 슬라이드 방식으로 이미지는 넘기는 보다는 버튼을 두어 개발하는 것이 편하다. 그렇지만 사용자는 슬라이드 형식으로 넘기는 형식이 매우 편할 것이다.이처럼 개발자는 사용자가 쓰기 편한 앱을 만들어야 한다.
 
 ## 일단 구현하라
-나는 개발을 클린코드를 하면서 하는 편이다. 코드를 분할하고, 나누고, 고친다. 그렇지만 내가 느낀 바로는 해커톤에서는 일단은 내가 제출한 코드가 아주 멍청한 코드여도 동작되기만 하면 일단은 해커톤에서는 좋은 성적을 거둔다는 것이다.일단은 내가 원하는 것이 구현만 된다면, 해커톤에서는 별 문제가 없을 것이다. 내가 해커톤에서 놀랐던 점은 거의 과반수 이상의 팀이 제대로 된 앱을 구현하지 않았다는 점이다.그저 구현하지 않은 상상의 앱을 그려 발표하는 것을 보고 나는 좋은 아이디어 보다 구현이 얼마나 중요한지 이번 해커톤을 계기로 깨달았다.
-그러니 일단은 기능을 구현해야 한다. 그렇지만, 버그 없이 구현되어야 한다. 버그가 있다면, 수상 하는 것은 힘들 수도 있을 것이다.
+나는 개발을 클린코드를 하면서 하는 편이다. 코드를 분할하고, 나누고, 고친다. 그렇지만 내가 느낀 바로는 해커톤에서는 일단은 내가 제출한 코드가 아주 멍청한 코드여도 동작되기만 하면 일단은 해커톤에서는 좋은 성적을 거둔다는 것이다.일단은 내가 원하는 것이 구현만 된다면, 해커톤에서는 별 문제가 없을 것이다. 내가 해커톤에서 놀랐던 점은 거의 과반수 이상의 팀이 제대로 된 앱을 구현하지 않았다는 점이다.그저 구현하지 않은 상상의 앱을 그려 발표하는 것을 보고 나는 좋은 아이디어 보다 구현이 얼마나 중요한지 이번 해커톤을 계기로 깨달았다.
+그러니 일단은 기능을 구현해야 한다. 그렇지만, 버그 없이 구현되어야 한다. 버그가 있다면, 수상 하는 것은 힘들 수도 있을 것이다.
 
 ## 발표 자료는 그렇게 중요하지 않다
-내가 생각하기로 해커톤에서 가장 까다로운 점은 개발도, 아이디어도 아닌 발표 같았다. 그렇지만 이번 해커톤으로 나는 깨달았다.해커톤에서 발표는 그저 힌 바탕의 발표 자료로도 이해만 편하다면, 결과물만 우수하다면 아무 상관은 없다는 것이다.
-발표 자료는 시간이 없다면, 그냥 Keynote로만 만들어서 발표해도 상관없다. 그러니 구현한 결과물에만 신경 쓰길 바란다.
+내가 생각하기로 해커톤에서 가장 까다로운 점은 개발도, 아이디어도 아닌 발표 같았다. 그렇지만 이번 해커톤으로 나는 깨달았다.해커톤에서 발표는 그저 힌 바탕의 발표 자료로도 이해만 편하다면, 결과물만 우수하다면 아무 상관은 없다는 것이다.
+발표 자료는 시간이 없다면, 그냥 Keynote로만 만들어서 발표해도 상관없다. 그러니 구현한 결과물에만 신경 쓰길 바란다.

content/에세이/힙하게 코딩하는 방법.md

@@ -1,5 +1,5 @@
 ---
-date: 2025-10-09
+date: 2022-06-05
 category: [에세이]
 published: true
 fixed: false
@@ -74,4 +74,4 @@ inputElement.addEventListener('keydown', e =>
 이 처럼 코드적인 값으로 많은 기능을 추가하고 선언하다 보다면 나도 헷갈릴 수도 있고, 협업의 과정에서도 어려움이 생길 수도 있다. 그러니 웬만하면 코드적인 값은 변수에 담아서 사용하는 것이 좋다.
 
 ## 최대한 사용자의 관점에서 바라보고 개발한다
-개발은 내가 구현하고 싶은 로직을 구현하고 싶어서 개발하는 것이 아니다. 또 내가 편하게 스타일 로직을 구현하고 싶어서 쉽게 마크업을 구성하는 것은 개발이 아니다. 그것은 그냥 내가 구현하고 싶은 기능과 레이아웃이며 사용자를 위한 로직과 레이아웃이 아니다. 모든 기능과 레이아웃 들은 사용자를 위해 개발되어야 한다. 만약, 사용자를 무시한 채로 개발된다면 그 프로덕트는 성공하지 못할 것이다. 만약 그 프로덕트가 성공하였다고 해도 그것과 기능적인 측면은 비슷하지만 사용자 친화적인 다른 프로덕트로 사용자들은 언젠가 넘어갈 것이다.
+개발은 내가 구현하고 싶은 로직을 구현하고 싶어서 개발하는 것이 아니다. 또 내가 편하게 스타일 로직을 구현하고 싶어서 쉽게 마크업을 구성하는 것은 개발이 아니다. 그것은 그냥 내가 구현하고 싶은 기능과 레이아웃이며 사용자를 위한 로직과 레이아웃이 아니다. 모든 기능과 레이아웃 들은 사용자를 위해 개발되어야 한다. 만약, 사용자를 무시한 채로 개발된다면 그 프로덕트는 성공하지 못할 것이다. 만약 그 프로덕트가 성공하였다고 해도 그것과 기능적인 측면은 비슷하지만 사용자 친화적인 다른 프로덕트로 사용자들은 언젠가 넘어갈 것이다.