“한빛미디어 <나는 리뷰어다> 활동을 위해 도서를 제공받아 작성된 서평입니다.”

인사이트 1: 비동기적인 삶

많은 팀이 이벤트 주도 시스템처럼 일한다는데 공감한다. 요즘에 B2B로 제품이 나가면서 이슈 해결을 빠르게 하려다 보니까 새로운 일이 터지면 온 신경이 거기다 쏠린다. 하지만 그 중에는 우선순위, 긴급도가 낮은 경우도 분명 있었을 것이다. 하지만 셀에서 비동기로 처리할 수 있는 일을 남겨놓는 프로세스가 부족하다는 생각이 들었다.

인사이트 2: 회의도 “복잡함”을 줄일 수 있다

코드 바깥에서 가장 인상 깊었던 부분이 여기였다. 책은 회의를 단순히 “시간 낭비”로 뭉뚱그리지 않는다. 회의는 여러 사람의 시간을 동시에 소모하는, 비용이 굉장히 큰 행위라는 시각으로 접근한다. 실제로 드는 비용을 계산해봤을 때 꽤나 컸다.

실무에서 회의 시간이 길어지는 경우가 많았다. 하지만 길어진다고 해서 회의를 마쳤을 때 상쾌한 기분이 들지도 않았다. 아무래도 셀에서 챙겨야 할 것들이 많았어서 이런저런 이야기를 하다가 흩어지는 회의들이 대부분이었다. 책을 읽고 나서는 회의 전에 “이 회의가 끝났을 때 무엇이 결정되어야 하는가”를 먼저 정의하고, 끝난 후에 실제로 그게 이뤄졌는지 확인해봐야겠다는 다짐을 하게 됐다. 코드를 단순하게 만드는 것처럼, 회의도 목적이 뚜렷할수록 비용 대비 가치가 올라간다.

또 한 가지 와닿은 포인트는, 회의는 강의 시간이 아니라는 것이다. 정보 전달을 회의 시간 안에 하려고 하면 그만큼 의사결정에 쓸 시간이 줄어든다. 읽어야 할 자료를 미리 공유하고, 회의 자리에서는 이미 자료를 읽은 사람들이 논의하고 결정하는 구조가 훨씬 효율적이다. 회의를 하기 전에 필요한 자료를 읽어보자는 요청을 해야겠다. 정보는 회의 밖에서도 자유롭게 흐를 수 있어야 한다.

인사이트 3: 주석도 관리 대상이다

요즘 코드 이해도를 높이겠다고 주석을 꽤 열심히 달고 있었다. 그런데 이 책을 읽으면서 불편한 진실 하나를 마주했다. 주석이 길어지는 순간, 그것도 코드처럼 관리해야 할 대상이 된다는 것이다. 아직까지는 기존 코드를 자주 건드리면서 주석도 함께 수정하는 경우가 많지 않았어서 이 부분은 크게 체감하지 못했다. 하지만 코드가 바뀌면 주석도 바꿔야 한다. 안 바꾸면 거짓말하는 주석이 된다. 코드는 최신인데 주석은 옛날 로직을 설명하고 있는 상황, 한 번쯤은 다들 겪어봤을 것이다. 결국 주석이 길수록 유지 비용도 그만큼 올라간다. 테스트 코드도 마찬가지라고 생각한다. 코드가 바뀌면 테스트 코드, 주석이 함께 바뀌어야 한다. 어떻게 효율적으로 관리할 수 있는지 고민이 필요하다.

책에서 강조하는 방향은 코드 자체가 의도를 드러내도록 짜는 것이다. 변수명, 함수명, 구조로 설명이 되어야 한다. 주석이 필요하다면 “왜(Why)“를 적는 것이지, “무엇을(What)“을 풀어 쓰는 게 아니다. 앞으로는 주석을 달기 전에 “이게 코드로 표현될 수 없는 내용인가”를 먼저 물어봐야겠다.

마무리

AI로 코드를 짜다보면 생각보다 복잡하고, 많은 양의 코드가 생성되는 일이 많다. 이 책을 읽고 나서 그런 복잡함을 경계하는 태도를 연습해야겠다는 생각이 들었다. 책의 분량이 많지도 않았지만 얻을 수 있는건 명확했다.

#한빛미디어 #나는리뷰어다 #미니멀리즘프로그래머

중니어 서버 개발자로서 '단순함'이라는 화두는 늘 고민거리였는데, 이 책은 그 고민에 꽤 날카로운 해답을 던져줬다. 단순히 코드를 줄이는 게 미니멀리즘이 아니다. 내가 완벽하게 통제할 수 있는 범위를 유지하고, 불필요한 복잡성을 제거하는 것이 핵심이다. Kotlin이나 Spring처럼 거대한 생태계 안에서 개발하며 K8s로 배포까지 신경 써야 하는 입장에서, '진짜 중요한 것'에 집중하는 법을 다시금 생각하게 됐다. 책의 여러 내용 중에서도 특히 팀 구성의 미니멀리즘에 대한 통찰이 가장 와닿았다.

팀 내 기술의 다양성이 왜 미니멀리즘인가

저자는 팀에 여러 가지 기술을 고루 갖추도록 구성하는 것이 조직의 복잡성을 줄이는 핵심이라고 강조한다. 언뜻 보면 '한 우물만 파는 전문가'들로만 모으는 게 효율적일 것 같지만, 실상은 그렇지 않다.

• 소통 비용의 절감: 특정 영역(예: 인프라, 보안, DB)에만 특화된 사람들로 팀이 쪼개져 있으면, 기능을 하나 배포할 때마다 '핸드오버(Hand-over)'가 발생한다. "이건 인프라 담당자에게 물어보세요"라는 말이 나오는 순간 프로젝트의 복잡도는 올라가고 속도는 떨어진다.
• 자기 완결적 팀(Self-contained Team): 팀원들이 백엔드뿐만 아니라 K8s, 네트워크, 기본적인 프론트엔드 지식까지 고루 갖추고 있을 때, 외부 의존성 없이 문제를 스스로 해결할 수 있다. 이것이 저자가 말하는 '조직적 미니멀리즘'의 완성이다.
• T자형 인재의 집합: 각자의 전문 분야(Deep Dive)는 확실히 하되, 팀 전체적으로는 넓은 기술 스펙트럼을 공유해야 한다. 그래야 예기치 못한 장애나 기술 변화에도 유연하게 대처할 수 있는 회복 탄력성이 생긴다.

실무에 던지는 메시지

평소 오픈소스 기여를 하면서 느꼈던 점과도 일맥상통한다. 잘 관리되는 프로젝트일수록 의존성은 간결하고, 기여자들이 다루는 기술의 폭은 넓다. 나 역시 그동안 Kotlin과 Spring이라는 틀 안에만 갇혀 있었던 건 아닌지 되돌아보게 됐다. Helm 차트를 만지거나 인프라 구조를 설계하는 일들을 '남의 일'이 아니라, 우리 팀의 복잡성을 낮추기 위한 '나의 일'로 받아들이는 태도가 필요하다.

결론

복잡한 세상에서 살아남는 유일한 방법은 본질만 남기고 덜어내는 것이다. 기술 스택뿐만 아니라 팀의 구성 방식에서도 '군더더기 없는 협업'을 고민해야 한다. 한국에 돌아가면 우리 팀원들과 각자의 기술적 영역을 어떻게 더 넓게 교차시킬지 이야기해 볼 생각이다. 기술적 파편화를 줄이는 것이 결국 가장 강력한 미니멀리즘 전략이니까.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

# 어떻게 일해야할까?
이 책에서 저자는 책에 정답이 없다고 말합니다. 옳은 표현이라고 생각해요. 개발업무를 하거나 학습을 하다보면, 결국 여러 방법론 속에서 우리는 상황과 최선의, 최적의 방법을 선택할 뿐이니까요. 결국 우리는 또 하나의 선택을 할 뿐이고, 아마도 좋은 개발자가 되기 위해서는 여러 방법을 알아두는게 여러모로 도움이 될거라고 생각합니다.

# 단순함을 이해하기
 우리는 복잡한 일들을 다루는 사람들이니까. 복잡하게 일하는 방법도 물론 필요하고, 어쩔 수 없는 상황 속에서 반드시 지켜져야할 일이기도 하다고 생각합니다. 다만, 단순한 방법으로 복잡한 것들을 유지할 수 있다면? 오히려 좋은 방법이 되겠죠. 당연하게도. 책에서는 여러 실천법을 알려줍니다. 저는 요즘 프로젝트를 진행하면서 의존성(Dependency)지옥에 빠져있어요. 그래서 그런지 '02 코드 다이어트' 목차의  건강하지 않은 의존성 줄이기 연습하는 부분에 눈이 갔습니다. 아주 피치못할 경우에는 저도 종종 의존성을 내려놓고 직접 코딩을 하거나 라이브러리를 까서 필요한 것들로 수정하거나 가져오는 경우가 있긴합니다. 안정성이 조금은 걱정될 때가 있긴 하지만, 하나의 방법이 되어주긴 할테니 이런 방법도 있다. 알아두는걸로 하겠습니다. 막상 업무 자체는 심플하지 않을 수 도있겠지만.. 뻘에 빠지듯 의존성 지옥에 빠지느니 이게 심플한 방법이 될 수도 있겠다고 생각해요. 이런 방법도 단순함이라고 생각하기로 합니다. 그 외에도 여러 단순한 실천법이 나와있는데, 간혹 답이 되어주는 방법일 것 같아요.
​
# 세상이 단순해지는 소프트 스킬
책에 개발에 적용하는 실천법만 나와있진 않아요. 변화를 어떻게 수용하고, 사람들과 어떻게 일을 해야할까. 이런 내용들이 나와있습니다. 소프트 스킬은 아시다시피 주로 다른 사람들과의 대인 관계를 위해 필요한 정성적 스킬입니다. 동료와의 완만한 업무를 진행하고, 프로젝트에서 좋은 성과를 얻어내기 위해서는 꼭 필요한 스킬이라고 생각해요. 저자는 다른 사람들에게 시간을 내어주고, 경청하고, 공감하는 방법에 대해서 풀어서 설명하고 있어요. 저는 효과적인 비유의 방법이나, 스토리텔링하는 방법에 대한 것들이 좋았습니다.

?미니멀리즘 프로그래머 - 데이비드 토머스 (한빛미디어)
열심히 일하고 있는 현업의 프로그래머분들에게 추천합니다. 경험이 지긋한 어떤 시니어분들께서는 이미 다 아는, 너무 당연한 이야기들이라고 생각하실 수도 있을테니, 아직 경험이 조금은 부족한 주니어 분들이나, 여러 사고를 간접경험 하는 것을 좋아하는 열린 마인드의 시니어 분들께 추천합니다!

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

나는 임베디드 프로그래머로 30년 이상 지내오고 있다. 그런데, 최근 프로젝트에는 revision 변경을 수행하고 있는데, 이전 코드상에 사용한 Middleware를 모두 걷어내고 새로운 Middleware로 변경하는 작업을 하고 있다.

​

7년전쯤 부터 진행해온 내가 작성한 코드이지만, 정말이지 상호 연관된 부분들이 꼬여 있어서 조금만 변경해도 어려움이 크게 작용하고 있다. 바로 의존성에 문제점이 많이 발생하고 있기 때문이다.

​

자료형, 상수, enum형 변수 등을 Middleware에서 지원한 것을 사용했는데, 변경되는 Middleware에는 없는 것들이다.

​

이 과정에서 너무나도 막막하고 내가 왜 이렇게 프로그래밍을 했지? 어떻게 하면 좋은 프로그래밍을 할 수 있을까? 이런 고민을 하고 있는데, 이 서적을 보게 되었다.

바로 찜하였는데, 다행이도 이번 한빛에서 제공하는 리뷰 도서에 포함되어서 바로 신청했다.

이 책에서 이야기하는 첫번째는 의존성으로 생각이 된다. 나보다는 웹기반 프로그래밍을하는 분들이 대부분 프레임워크 기반 or 제공되는 라이브러리 기반으로 프로그램을 작성하다보니, 난중에 유지 보수 및 기타 다양한 문제로 어려움을 겪을 수 있다는 것을 이야기하면서, 어떻게 하면 복잡함을 걷어낼 수 있는 방법을 제시하고 있다.

​

표지에서 언급한 29가지 개발 원칙이란, 각 실천 항목을 Practice 라고 표현하였으며 이게 목차에서 볼 수 있는 Practice 1 ~ 29 이다.

​

그리고 책에서 언급한 내용에 대해서 이해를 돕기 위해서 다양한 사이트 링크를 제공하고 있어서, 시청각 교육을 통해서 좀 더 이해도를 높여주는 계기를 제공하고 있다.

개발환경에서도 단순하게 작업하는 것 보다는 다양한 지원 툴들을 활용해서 개발 환경을 단순하면서도 활용도를 극대화 할 수 있는 솔루션들을 소개하는데, 이 부분에서도 단순한 언급 보다는 조금 더 구체적인 방법의 제시 or 참고할 영상 정보등을 제공해 주었으면 좀 더 도움이 되었을 듯 하다.

아쉬운 점

​

1) 전체적인 프로그래머 입장에서 개념 정리를 하고 생각을하게 하지만, 좀 구체적인 방법을 제시하고 있지는 않는 듯 하다.

​

2) 번역본에서 조금 오류라고 해야 할지?

예를 들어서 '6번 프랙티스에서 소개할 회의 지침' 이런 문장이 지속적으로 반복되는데, 뜬금없이 6번 프랙티스 가 뭐지? 이런 상황이 발생하고 했습니다.

뒤고 가서 보니, CHAPTER 03에 PRACTICE 06 을 의미하는 문장이었습니다.

(PRACTICE 06 : 굳이 회의를 해야 한다면 생산적으로 하자)

이 부분을 좀 더 매끄럽게 그냥 PRACTICE 06 참조

뭐, 이런 단순화 했으면 좀 더 좋았을 듯 합니다.

​

3) 용어에 대한 설명 부족

회의가 '애자일'하다는 착각

과 같은 문장에서 애자일이라는 용어를 사용하면서 이후 반복적으로 표현하는데, 애자일에 대한 명확한 의미가 좀 아쉬웠다고 해야 할지?

(민첨성 or 반복적인 개발 방법론 or 경량방법론 ... )

​

마지막으로 이책은 한마디로 개발자 / 프로그래머에게 있어서 명언집 같은 느낌을 많이 주는데, 조금은 설명이 난해해서 별도로 자료를 찾아보거나 용어를 이해하기 위해 부가 설명을 찾아보게 되는 부분이 많았다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다.

한빛미디어의 '나는 리뷰어다' 3월 서평단으로 '미니멀리즘 프로그래머' 책을 선택하여 전자책으로 받아 읽게 되었다. 

미니멀리즘이라고 하면 작게 그리고 적게 가져가는 것을 떠올릴 것이다.

프로그래밍에서도 마찬가지다.
켄트백의 아키텍처에서 다루는 내용이나, 개발자들이 정통적으로 따르기 위해 많은 고민을 하는 여러 프로그래밍 방법론에서 다루는 내용들과 밀접한 관계를 가진다.

코드는 짧게 쓸 수록 좋고, 관련된 내용은 모아두는게 좋고, 결합도 낮추고, 응집도 높이고 등등 개발에 관심을 가진 사람들이라면 어디선가 한 번쯤 들어봤을 내용들이다.
이런 내용들을 왜 그렇게 해야하는지에 대해 풀어서 설명해주고 있는 책이다.
실제로 업무를 하면서도 불필요하거나 불합리하다고 느끼는 것들에 대해서 공감을 하면서 읽을 수 있었다.

특히 "변화에는 유연하게 대응하고, 관습에 얽매이지 말아라"는 내용들이 참 공감이 되었다.
AI 시대로 되면서 실제 개발하는 시간이 확연히 줄어들었고, 개발 방법 역시 많이 바뀌게 되었다.

"개발자들은 계속하여 공부하고 학습하고 적용하기 위해 노력하지만, 그 안에 있는 관습들로 인해 변화에 거부감을 느끼기도 한다.
AI 시대에 AI가 생성해내는 코드들도 어찌보면 우리가 기존에 짜오던 관습과 다르기 때문에 거부감이 조금은 들 수 있다.
하지만, 이런 변화에 유연하게 대응하면서 관습을 피해가며 AI시대에 맞는 코드를 짜기 위한 노력이 필요해졌다."

이런 관점을 다시금 생각해볼 수 있었던 책이었다.
책 내용 자체는 굉장히 쉽게 술술 읽히기 때문에 개발을 하는 사람들이라면 한번쯤 읽어보기를 추천한다.

기존에 알고 있던 개발 방법론 및 개발 방식에 대해서 다시금 정리를 하면서 변화되는 상황에 맞춰 새로운 인사이트를 얻을 수 있게 해준 책이 될 것이다.

<한빛미디어 <나는 리뷰어다> 활동을 위해 책을 제공받아 작성된 서평입니다.>

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."
 

책 소개

해당 책은 제목과 같이 개발함에 있어서 무언가 더 기술적으로 더하는 느낌이 아닌 덜어내는데 집중하는 내용으로 구성되어 있다.

저자는 과거에는 신기술이 나올 때 마다 필요보다는 호기심 때문에 프로그램/프로젝트에 적용했었던 과거를 회상하며 현재는 그 반대의 삶을 살아가려고 노력하는 내용을 담고 있는 것 같았다.

책 목차

PART 01 / 하는 일을 단순화하라, 일하는 방식을 단순화하라.

PART 02 / 환경을 단순화하라.

PART 03 / 상호작용을 단순화하라.

PART 04 / 코드를 단순화하라.

책 목차를 보면 알 수 있듯이 주된 키워드는 "단순화"이다.

무소유라는 말을 들어봤을 것이다. 갖고 싶은 것들을 다 가지고 난 후 남는 건 공허함이다.

결국 필요한 것 하나만 남기고 다 정리하는 것이 미덕이 된다는 말이 있다.

저자는 이론 설명보다는 개발 현장에서 직접 체득한 것들과 습관들에 대해서 바로 실천할 수 있도록 안내하고 있다.

단순화하기 위한 29가지 실천법은 꽤나 공감가는 가는 부분도 있었고 그렇지 못한 것들도 있었다.

그럼 어떤 것들이 내가 공감했고 또 처음 알게 되었던 것들인지 몇 가지 책의 내용을 공유해본다.

CHAPTER 03 프로젝트 최적화 / 지긋지긋한 회의를 줄이기

아래 이미지의 내용을 보면 백프로 공감하게 된다.

회의가 너무 쉽게 지배당한다는 코멘트와 지식이 공유되는 것이 아니라 강요된다는 글을 읽고나서 내가 주최하는 회의에서는 어떤면이 더 클런지 반성하게 되었다.

CHAPTER 04 업무 자동화 / 그 외 모든 것 자동화하기

아래 이미지 내용은 업무 자동화 편에서 저자가 실천해보라고 남겨놓은 메시지다.

과거 유사한 글을 본적이 있었던 것 같은데 실천을 해보지는 못했었다.

글의 요지는 새로운 언어를 공부 또는 개발할 때 코드를 완성한 후 개발/배포 환경을 구축하기보다는 가장 단순한 코드를 가지고 배포 환경을 미리 구축하여 단일명령어 하나로 릴리즈까지 빠르게 한사이클을 끝내보라고 한다.

과거 경험상 이를 미루게 되면 한없이 밀려서 크나큰 고생을 한 경험을 이야기해주고 있었다.

또한 이 내용도 한번쯤 생각해볼 필요가 있다.

내 업무 PC가 갑자기 켜지지 않는다면? 내 개발 환경이 꼬여서 빌드 및 릴리즈를 할 수 없다면? 정말 아찔하다.

사실 그런 상황이 벌어지는 경우는 드물지만 일어나긴 한다.

상시 백업 또는 환경을 이미지화 해놓는 방안등을 고려하지 않았다면 머리가 아파올 것이다.

지금이라도 이런 문제를 방지하기 위해서 내가 할 수 있는 무엇일지 생각해보게 된다.

CHAPTER 05 변화의 수용 / 미래에서 놀고, 과거에서 일하기

이 내용은 항상 새로운 것이 좋은 것은 아니다라는 내용을 말해주고 있다.

누구나 새로운 아이디어가 있다면 다음 기능에 넣고 싶고, 사용하는 프레임워크에 신규 기능이 들어왔다면 사용해보고 적용해보고 싶을 것이다. 하지만 검증되지 않는 이런 기능들을 넣는다는 것은 위험성을 가지고 있다는 것을 인지하라는 내용이다.

사실 기존의 프로젝트에 새로운 것을 추가하거나 유지보수함에 있어 보수적으로 접근하는 편이다.

새로운 기능을 써보는 것도 좋지만 오류 없이 현상 유지를 하는 것도 무엇보다 중요한 부분이라 생각하기 때문이다.

저자의 이 내용은 실로 매우 공감가는 부분임이 틀림없었다.

CHAPTER08 가독성 높은 코드 / TODO를 쓰느냐 마느냐

코드를 유지보수하는 상황을 보면 다른 사람이 작성한 코드를 볼 때 고처야 할 부분이 있는 경우나 TODO를 통해 고쳐야 한다고 나열되어 있는 경우를 본적이 있을 것이다. 저자도 이러한 상황에서 아주 간단한 부분이 아니고서는 TODO를 달아놓고 향후에 처리한다고 한다. 그러는 과정에서 툴들을 활용해 TODO 항목을 놓치지 않는다고 한다.

마무리 하며

위 29가지 실천법들 중에 몇가지 공감가는 부분들을 발췌해서 소개했다.

저자도 이야기 하지만 모든 실천법을 적용할 필요는 없다. 그리고 그럴 수도 없다.

자신의 환경에 맞는 형태로 수정해서 사용하거나 발전시키면 될 일이다.

결국 책을 읽고 난 후 내 머리속에 남는 것은 "Simple is Best"이다. 

난 사실 물질적 욕구에 있어서는 맥시멀리즘을 추구한다.

하지만 개발에 있어서는 미니멀리즘을 추구하려고 노력하겠다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

올해부터 생산성 향상을 위해 Claude Code, Codex 등과 같은 Coding Agent 툴을 적극적으로 업무에 도입하면서 많은 시행착오를 거치고 있다. AI-assisted Coding을 거쳐 Agentic Coding으로 나아가며 개인적으로 가장 고민이 되었던 부분은 "딸깍"하면 어떻게든 동작하는 코드는 만들어지지만, 복잡한 코드가 중복으로 작성되는 경우가 잦다는 것이다.(물론 나의 프롬프팅 실력, 하네스 구축 능력 부족 등이 원인일 수 있다.)

"동작만 한다면 내부는 어떻든 상관없나?"하는 고민을 한참하던 찰나, 한빛미디어에서 <미니멀리즘 프로그래머>라는 책이 시기적절하게 번역되어 출판되었고, 서평단을 통해 책을 받아볼 수 있었다.

회의, 업무 자동화 등등 개발자와 관련된 많은 내용을 다루고 있지만, 나에게 와닿았던 부분은 코딩과 관련된 부분이었다.

(p30) 우리의 코드는 점점 비대해지고 있습니다. 그 결과 코드를 이해하기도, 유지보수하기도, (곧 보시겠지만) 배포도 더 어려워집니다.
(p43) 소프트웨어에 추가하는 모든 기능은 미래의 부채가 됩니다. ... '기능'은 '미래의 부채'를 그럴싸하게 포장한 마케팅 용어입니다.

이 책을 보고 모든 주도권을 AI에게 빼앗긴 채 모니터를 그저 바라만 보던 지난 몇 주간을 되돌아보게 되었다. Claude Code, Codex와 같은 AI Coding Tool을 이용해 코딩을 하고 있지만, AI가 작성한 코드를 보며 왠지 모를 답답함을 느꼈을 분들에게 이 책을 적극 추천한다.

출처: https://tigris-data-science.tistory.com/entry/서평-미니멀리즘-프로그래머 [묵묵히 걸어가기:티스토리]

※ 한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

​

이 책은 "미니멀"이라는 주제로 서비스를 개발하는 것 뿐만 아니라 조직의 상호작용 측면에서의 이점을 다룬다.

단순히 코드를 짧게 작성하는 내용을 다루는 것이 아니라 복잡한 서비스 환경을 만드는 전 과정에서 구체적인 단순화 원칙을 제시하여 발자가 프로그래밍의 즐거움을 찾을 수 있는 관점으로 내용을 다룬다.

그렇기 때문에 AI가 도입된, 특히나 지금처럼 AI가 개발환경에 많은 영향을 주는 현 시점에서 정말 중요한 것에만 집중하고 더 큰 성과를 내기 위한 철학을 중심으로 내용을 소개한다.

​

"모든 것을 다 하지 말라"라는 이 책의 가장 큰 메시지처럼 다양한 요청과 업무를 경험하면서 개발자 본인이 효율적인 사람이라고 생각할 수 있만 실제로 중요한 일에 쏟아야할 에너지를 분산시키고 있을 뿐이라서 진정한 성과는 선택에서 시작되기 떄문에 무엇을 할지보다는 무엇을 하지 않을지를 결정하는 것이 중요함을 강조한다.

이 책을 읽으면서 개인적으로 인상깊었던 부분은 "거절"을 하는 기술인데, 불필요한 회의나 의미 없는 협업 또한 우선수위가 낮은 업무를 거절하는 것이야말로 생산성을 높이는 핵심이기 때문에 이를 개발하는 환경에도 그대로 적용할 것을 말한다.

즉, 프로젝트를 진행할 때 요구사항이 계속 추가되고 이로 인한 여러 기술 스택도 복잡해지지만 이를 모두 수용하기 보다는 핵심 기능과 가치에 집중한다면 더 완성도 있는 완성도를 높이는 결과를 만든다고 말한다.

시간을 관리하고 생산성을 향상시키기 위한 다양한 도구나 방법론을 찾지 중요한 것은 결국 복잡한 것을 제거하고 기존의 것을 덜아내어 개발자가 그 기술의 주인이 되어 지속 가능한 소프트웨어를 만드는 즐거움을 되찾기를 제안한다.

결국 이 책의 내용들이 실무에서는 어려울 수 있지만 결국 바라보는 관점을 어떻게 하느냐 그리고 이 책의 내용처럼 모든 것을 다 바꿀수는 없더라도 최소한 어떤 기준으로 선택해야 하는지 분명하게 설명한다.

이를 통해 단순하게 코드를 짧게 줄이는 것 넘어 무거운 라이브러리의 의존성을 과감히 제거하는 코드 다이어트와 소모적인 회의를 줄이고 효율적으로 프로젝트를 관리하는 방법, 그리고 업무를 함에 있어 자동화를 도입하여 생산성을 향상 시키고, DDD를 통한 명료한 로직을 만드는 방법까지, 실무에서 즉시 적용 가능한 조언을 얻을 수 있다.

이를 통해 복잡한 AI 시대에 이 책의 말처럼 미니멀리즘 프로그래머가 될 수 있지 않을까 싶다.

​

AI 시대에, 그리고 복잡해진 개발환경에서 진정한 미니멀리즘의 의미를 알고 싶어 개발자분들께 추천한다.



※ 한빛미디어 ‘나는 리뷰어다’ 활동을 통해 도서를 제공받아 작성한 리뷰입니다.

요즘 내 브라우저 탭에는 항상 뭔가 열려 있다. 

Zustand 마이그레이션 문서, tRPC 튜토리얼, 새로운 번들러 비교 글, “풀스택 개발자 로드맵 2026”

프론트엔드 개발을 3년 정도 하다 보니 자연스럽게 다음 단계가 보인다.

백엔드, 데이터베이스, 인프라까지 확장해야 한다는 압박이다.

그런데 어느 순간 이상한 느낌이 들었다.

나는 점점 더 많은 기술을 배우고 있는데,

내가 만드는 프로젝트는 왜 점점 더 복잡해지고 있을까?

『미니멀리즘 프로그래머』는 바로 그 질문을 던지는 책이다.

책소개

이 책의 저자는 『실용주의 프로그래머(The Pragmatic Programmer)』로 유명한 데이비드 토머스다.

원제는 Simplicity.

제목 그대로 이 책은 단 하나의 주제를 이야기한다.

단순함.

책의 핵심은 소프트웨어의 복잡함을 두 가지로 나누는 것이다.

Complex: 시스템이 본질적으로 가질 수밖에 없는 복잡성

Complicated: 개발자가 판단을 미루거나 습관적으로 만들어낸 복잡함

첫 번째는 피할 수 없다.

하지만 두 번째는 충분히 줄일 수 있다.

이 책은 특정 기술이나 언어를 설명하지 않는다.

대신 어떤 기술을 선택하든 적용할 수 있는 사고 방식을 이야기한다.

3년차 프론트엔드 개발자가 느낀 가장 큰 깨달음

이 책을 읽으면서 가장 뜨끔했던 부분이 있다.

나는 사이드 프로젝트를 시작할 때 이런 순서를 밟는다.

상태 관리 라이브러리 선택

API 레이어 설계

폴더 구조 설계

코드 스타일 설정

테스트 환경 설정

그리고 나서야

첫 번째 기능을 만든다.

문득 생각해보니

기능보다 인프라를 먼저 만드는 습관이 생겨 있었다.

이게 실력이라고 생각했는데

사실은 그냥 습관적인 복잡함이었다.

잼 실험 — 선택지가 많을수록 아무것도 선택하지 않는다

책에서 등장하는 유명한 실험이 있다.

슈퍼마켓에서 잼을 진열했을 때

- 24가지 잼을 놓았을 때보다

- 6가지 잼만 놓았을 때

구매율이 훨씬 높았다.

선택지가 많아질수록 사람은 더 많은 판단을 해야 하고

결국 선택 자체를 포기하게 된다.

소프트웨어도 마찬가지다.

옵션이 많은 API,

설정이 복잡한 프레임워크,

유연하지만 이해하기 어려운 구조.

이런 것들이 항상 좋은 설계는 아니다.

오히려 선택지를 줄여주는 설계가 더 좋은 설계일 수도 있다.

풀스택으로 갈수록 더 중요해지는 “단순함”

프론트엔드만 할 때는 복잡해도 어느 정도 통제가 가능하다.

하지만 시스템이 이렇게 확장되면 이야기가 달라진다.

- 프론트엔드

- 백엔드

- 데이터베이스

- 캐싱

- 인프라

각 레이어에서 조금씩 쌓인 복잡함이

결국 아무도 전체를 이해하지 못하는 시스템을 만든다.

그래서 풀스택 개발로 확장할수록

새로운 기술보다 더 중요한 것이 생긴다.

단순하게 만드는 능력

기억에 남는 이야기들

하드웨어가 좋아질수록 코드도 커진다

컴퓨터 성능이 좋아질수록 개발자는 더 많은 것을 사용한다.

- 더 많은 메모리

- 더 많은 라이브러리

- 더 많은 추상화

문제는 이것이 결국

유지보수하기 어려운 코드로 돌아온다는 점이다.

단순함은 “덜 만드는 것”이 아니다

단순함은 단순히 기능을 줄이는 것이 아니다.

불필요한 것을 찾아서 제거하는 과정이다.

코드를 추가하는 건 쉽다.

코드를 줄이는 건 어렵다.

그래서 단순한 시스템은

대부분 많은 고민 끝에 만들어진 결과물이다.

아쉬운 점

이 책은 코드 예제가 거의 없다.

개념과 사고 방식 중심이라

그래서 실제로 어떻게 적용하지? 라는 생각이 드는 순간도 있다.

그리고 초판이라 그런지

오탈자가 꽤 보이는 점도 아쉽다.

이런 개발자에게 추천

이 책은 이런 사람에게 특히 맞는다.

- 프로젝트가 점점 복잡해지고 있다고 느끼는 개발자

- 새로운 기술을 계속 배우는데도 코드가 좋아지지 않는다고 느끼는 개발자

- 풀스택 개발을 고민하고 있는 개발자

- AI 시대에 더 빠르게 만드는 것보다 더 잘 만드는 것을 고민하는 개발자

마무리

개발자는 보통 이런 질문을 많이 한다. 

다음에는 어떤 기술을 배워야 할까?

이 책은 조금 다른 질문을 던진다.

지금 내가 만드는 건 정말 필요한 만큼만 복잡한가?

새로운 도구를 배우기 전에

한 번쯤 읽어볼 만한 책이었다.



"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

이 책을 펼치기 전까지 나는 '단순함'을 일종의 타협이라고 생각했다. 기능이 많아야 좋은 소프트웨어고, 라이브러리를 잘 활용할수록 숙련된 개발자라는 믿음. 무언가를 더 얹을수록 더 전문적으로 보인다는 착각. 아마 개발을 처음 배울 때부터 나도 모르게 내면화한 편견이었을 것이다. 그 편견을 정면으로 깨부수는 책이 왔다. 『실용주의 프로그래머』의 저자 데이비드 토머스의 신작 『미니멀리즘 프로그래머』다.

저자는 이렇게 묻는다. 11줄짜리 코드를 짜면 끝날 일을 왜 거대한 라이브러리를 설치해서 처리하려 하냐고. 읽는 순간 뜨끔했다. 나 역시 npm install을 입력하는 데 망설임이 없었고, 프레임워크 없이 무언가를 만드는 일을 오히려 비효율이라 여겼으니까. 저자가 진짜 비효율이라고 말하는 건 그 태도 자체다. 필요하지도 않은 복잡함을 끌어안고, 그것을 유지하느라 정작 본질을 잃어버리는 것.

단순함은 기교가 아니라 태도다

책의 핵심 주장은 명확하다. 미니멀리즘은 코드를 짧게 줄이는 기술이 아니라는 것. 저자가 말하는 단순함은 훨씬 더 근본적인 곳에 있다. 프로젝트의 군더더기를 걷어내고 핵심 가치에 집중하는 태도, 변화를 두려워하지 않고 받아들이는 용기다.

책은 네 개의 파트로 나뉜다. 하는 일, 환경, 상호작용, 코드 자체를 각각 단순화하는 방법을 다룬다. 이 구조 자체가 이미 저자의 철학을 반영한다. 단순함은 코드 수준에서만 이루어지는 게 아니라, 개발자의 일하는 방식 전반에 걸쳐 실천되어야 한다는 것이다.

29가지 실천 원칙으로 이루어진 이 책은 읽는 내내 '맞아, 이게 문제였어'라는 감탄과 '이렇게까지 해야 해?'라는 의심이 교차하게 만든다. 그 긴장감이 이 책의 매력이다.

코드 다이어트: 덜어내는 용기

1부의 '코드 다이어트' 챕터는 가장 직접적인 도발로 시작된다. 의존성을 줄이라는 것, 프레임워크를 맹신하지 말라는 것, 기능은 적을수록 좋다는 것.

저자는 라이브러리를 도입하기 전에 마치 '성분표를 꼼꼼히 확인하듯' 점검하라고 말한다. 이 라이브러리가 지금 나에게 정말 필요한가, 유지보수 비용은 얼마나 되는가, 직접 구현하는 게 더 단순하지는 않은가. 질문은 단순하지만 대답하는 과정에서 스스로의 습관을 돌아보게 된다.

'혹시 나중에 필요할지 모른다'는 이유로 추가되는 기능들을 저자는 '미래의 부채'라 부른다. 당장은 자산처럼 보이지만, 결국 유지보수 비용이라는 이자를 영원히 지불해야 한다는 것이다. 얼마나 정확한 비유인지는, 과거에 내가 '언젠가 쓰겠지' 하며 남겨두었다가 결국 아무도 건드리지 않은 코드들을 떠올리면 바로 알 수 있다.

프로젝트 최적화: 회의를 줄이는 것도 개발이다

2장에서 책은 코드를 벗어나 팀과 조직의 단순함을 이야기한다. 팀의 결합도를 낮추고, 회의를 줄이고, 정보가 자유롭게 흐르는 구조를 만들라는 것이다. 처음엔 이 부분이 개발 서적과 어울리지 않는다고 생각했다. 읽다 보면 저자의 의도가 분명히 보인다. 코드의 복잡함과 조직의 복잡함은 본질적으로 같은 문제라는 것. 지나치게 결합된 모듈이 시스템을 취약하게 만들듯, 지나치게 의존적인 팀 구조는 조직을 느리고 경직되게 만든다.

'지긋지긋한 회의 줄이기'라는 소제목은 유독 공감이 갔다. 저자는 회의 자체를 악으로 규정하지 않는다. 목적 없이 반복되는 회의, 결론 없이 끝나는 회의가 팀의 에너지를 어떻게 소진시키는지를 짚는다. 그리고 회의를 줄이는 구체적인 방법 대신, 왜 회의가 많아지는지를 먼저 들여다보게 한다. 증상이 아니라 원인을 다루라는 것, 이 역시 미니멀리즘의 철학과 맞닿아 있다.

환경 자동화: 단순함을 위한 준비

역설적이게도 단순함을 위해서는 처음에 한 번 공을 들여야 한다. 2부는 그 이야기다. 터미널 환경 최적화, 에디터 설정, 개발 장비 세팅 자동화까지. 반복되는 귀찮은 작업들을 자동화해 두면 이후엔 본질적인 일에 집중할 수 있다. '명령어 하나로 배포가 가능한 시스템'이라는 표현이 인상적이었다. 저자는 이를 단순함을 유지하기 위한 최소한의 기반으로 이야기한다. 복잡한 배포 절차, 매번 다른 환경 설정, 누군가의 머릿속에만 있는 암묵지. 이 모든 것이 복잡함의 씨앗이다. 자동화는 그 씨앗이 자라기 전에 뿌리째 뽑는 일이다.

'미래에서 놀고, 과거에서 일하기'라는 챕터 제목은 처음엔 의아했다. 새로운 기술과 도구는 가볍게 실험하되, 실제 업무에서는 검증된 안정적인 도구를 쓰라는 뜻이다. 유행을 쫓는 것과 변화를 받아들이는 것은 다르다. 저자는 그 경계를 '실용성과 기발함을 섞는' 균형감각으로 설명한다.

소프트 스킬: 공감도 단순화할 수 있다

3부는 상호작용의 단순화를 다룬다. 의견 충돌을 제로섬 게임으로 보지 않기, 공감 능력 기르기, 이야기로 설명하기. 얼핏 보면 자기계발서처럼 보이지만, 저자는 이를 철저히 개발자의 언어로 풀어낸다. '사물에도 공감하기'라는 원칙이 흥미로웠다. 코드를 작성할 때 그 코드를 읽을 사람의 입장이 되어보는 것, 시스템을 설계할 때 그 시스템을 사용하는 사람의 맥락을 상상하는 것. 공감은 팀원과의 관계를 부드럽게 만드는 기술이기도 하지만, 더 단순하고 더 올바른 코드를 만드는 기반이기도 하다는 점에서 설득력이 있다.

'이야기 엮기' 원칙도 실용적이다. 복잡한 기술적 내용을 이해관계자에게 설명할 때, 데이터와 논리보다 이야기가 더 강하게 전달된다는 것. 커뮤니케이션 비용을 줄이는 가장 단순한 방법은 결국 상대방이 쉽게 이해할 수 있는 언어로 말하는 것이다.

데이터 주도 개발과 가독성: 코드 단순화의 정수

4부는 가장 기술적이면서도 통쾌한 챕터들로 이루어져 있다. 데이터에 주도권을 넘기고, 테이블로 테스트를 단순화하고, 상태 머신으로 로직을 정리하는 방법들이 나온다. '데이터에 운전대 맡기기'는 특히 공감이 갔다. 복잡한 if-else의 숲을 헤매던 경험은 누구나 한 번쯤 있을 것이다. 조건 분기를 코드로 직접 표현하는 대신 데이터 구조로 끌어내면, 로직은 단순해지고 변경도 쉬워진다. 코드보다 데이터가 다루기 쉽다는 주장은 실제로 해본 사람이라면 고개를 끄덕일 수밖에 없다.

가독성 챕터에서 '주석 달지 않기'는 도발적으로 들릴 수 있다. 주장은 명확하다. 주석이 필요하다는 것은 코드 자체가 의도를 설명하지 못하고 있다는 신호라는 것. 좋은 이름, 좋은 구조, 좋은 흐름이 주석보다 훨씬 강한 가독성을 만든다. '옆으로 긴 코드보다 아래로 긴 코드가 낫다', '관련된 코드는 한곳에 모으기', '마지막에 쉼표 남겨두기' 같은 원칙들은 작고 구체적이지만, 코드 리뷰 현장에서 바로 써먹을 수 있는 것들이다. 이런 디테일에서 저자의 현장 경험이 느껴진다.

AI 시대일수록 단순함이 무기다

마지막 챕터에 이르면 왜 이 책이 지금 나왔는지가 분명해진다. AI가 코드를 생성하는 시대일수록, 개발자의 진짜 가치는 더 많이 만드는 것이 아니라 불필요한 것을 걷어내는 판단력에 있다. AI는 코드를 빠르게 만들어준다. 그런데 그 코드가 정말 필요한지, 이 복잡함이 감당할 만한지를 판단하는 것은 여전히 개발자의 몫이다. AI가 쏟아내는 코드 속에서 방향을 잃지 않으려면 단순함이라는 나침반이 필요하다는 저자의 주장이 공허하게 들리지 않는 것은, 책 전체가 그 나침반을 구체적인 방법으로 제시하고 있기 때문이다.

이 책을 추천하는 사람들

모든 개발자에게 권하고 싶지만, 특히 이런 분들에게 강하게 추천한다.

복잡해진 코드베이스 앞에서 무력함을 느끼는 개발자. 기능을 추가할수록 프로젝트가 무거워진다는 걸 알면서도 멈추지 못하는 개발자. AI 도구를 쓰기 시작하면서 코드의 방향을 잃은 기분이 드는 개발자. 개발이 언제부터인가 즐겁지 않아진 개발자.

이 책은 답을 주기보다 질문을 던진다. 지금 이 코드가 정말 필요한가, 이 복잡함은 가치가 있는가, 나는 지금 무엇을 위해 개발하고 있는가. 그 질문들이 불편하게 느껴진다면, 이 책이 가장 필요한 시점이라는 뜻일 것이다. 단순함은 쉬운 길이 아니다. 더 많은 사고와 용기를 요구한다. 하지만 그 끝에는 저자가 말하는 '프로그래밍의 즐거움'이 다시 기다리고 있을지 모른다.

오늘도 찾아주셔서 감사합니다.

출처: https://patiencelee.tistory.com/1273 [PatienceLee:티스토리]

개발자로 일하다 보면 어느 순간 코드가 스스로를 설명하지 못하는 덩어리가 되어 있습니다. 새 기능을 붙일 때마다 뭔가 찜찜하고, 테스트는 점점 무거워지고, 주석은 코드와 조금씩 어긋납니다. 복잡함은 서서히, 그리고 조용히 찾아옵니다.

이 책은 새로운 기술을 알려주는 책이 아닙니다. 이미 알고 있으면서도 외면해온 것들을 다시 마주하게 하는 책입니다. 데이터로 코드를 대체하는 방법, 테이블로 테스트를 단순화하는 방법, 라이브러리 없이 상태 머신을 구현하는 방법 — 모두 지금 당장 꺼내 쓸 수 있는 실천들입니다.

읽는 내내 고개를 끄덕이다가, 책을 덮고 나서 내 코드를 다시 열어보게 됩니다.

"프로젝트를 복잡하게 만든 장본인은 대부분 우리 자신이다."

단순함은 기술이 아니라 용기의 문제라는 것, 이 책이 조용히 증명합니다.

『미니멀리즘 프로그래머』는 단순히 코드를 줄이거나 기능을 최소화하는 방법을 이야기하는 책이 아닙니다. 오히려 시스템이 자연스럽게 복잡해지는 과정 속에서, 그 복잡성을 어떻게 통제할 것인지에 대한 설계 관점을 제시합니다.

책에서는 YAGNI, DRY, KISS 같은 익숙한 원칙을 다시 가져오지만, 단순 개념 설명에 머무르지 않고 “왜 과도한 추상화와 미리 설계하는 습관이 문제를 만드는지”를 개발자의 선택 관점에서 풀어냅니다. 특히 필요해지기 전까지 만들지 말고, 추상화는 늦게 도입하라는 메시지는 실무에서 바로 적용 가능한 기준으로 느껴졌습니다.

단순한 개발 습관을 넘어, 유지보수와 변경 비용을 줄이기 위한 설계 기준을 고민하는 개발자라면 한 번쯤 읽어볼 만한 책입니다.



한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

"단순함을 추구하면 프로그래밍이 다시 즐거워질 겁니다."

- 데이비드 토머스

이 책, 왜 화제가 됐을까요?

프로그래밍 책을 잘 모르는 분들도 한 번쯤 들어보셨을 이름이 있습니다.

바로 《실용주의 프로그래머(The Pragmatic Programmer)》!

전 세계 20만 부 이상 팔린 개발자 필독서의 저자 데이비드 토머스(Dave Thomas)가

무려 수십 년 만에 신작을 들고 나타났습니다.

원서 제목은 《Simplicity》, 한국어판 제목은 《미니멀리즘 프로그래머》.

번역은 국내 개발자 교육계에서 잘 알려진 이민석 교수님이 맡아주셨습니다.

출간 즉시 개발자들 사이에서 화제가 됐는데요...

얼마나 대단한 책인지, 같이 살펴볼게요!

먼저, 저자가 어떤 분인지 알아볼게요

데이비드 토머스는 단순한 책 저자가 아닙니다.

- 애자일 소프트웨어 선언문(Agile Manifesto)** 공동 저자

- Ruby 언어를 서양 개발자들에게 처음 소개한 장본인

- Rails, Elixir 초기 보급에 기여

- Pragmatic Bookshelf 출판사 창립자

- 코딩 경력 50년 이상 (!)

한 마디로, 현대 소프트웨어 개발 문화를 만들어 온 전설적인 인물입니다.

그런 분이 "이게 지금 개발자들에게 가장 필요한 이야기"라며 쓴 책이 바로 이 책이에요.

이 책이 말하는 핵심은 딱 하나!

"더하지 말고, 비워라."

요즘 개발 현장을 보면 이상한 일이 벌어지고 있습니다.

AI가 코드를 대신 짜주는 시대인데...

정작 소프트웨어는 갈수록 더 무겁고 복잡해지고 있거든요!

11줄이면 끝날 기능을 거대한 라이브러리를 설치해서 구현하고,

기능을 추가할수록 유지보수는 더 어려워지고,

회의는 늘어나는데 생산성은 오히려 떨어지고...

혹시 이런 상황, 공감되시나요?

저자는 이 현상의 원인이 바로 "인위적으로 쌓아온 복잡함" 이라고 콕 집어 말합니다.

그리고 그 해답으로 '단순함(Simplicity)' 을 제시하죠.

책의 구성 - 4가지 영역에서 단순함을 찾다

이 책은 29가지 개발 원칙을 담고 있는데, 크게 4개 파트로 나뉩니다.

1) 하는 일과 방식을 단순하게

무작정 새 기술, 새 프레임워크를 도입하기 전에 "정말 필요한가?"를 먼저 묻는 습관.

저자는 Orient-Step-Learn(방향 설정 → 한 발짝 → 배움) 이라는 세 단어로

개발의 본질적인 흐름을 설명합니다.

2) 개발 환경을 단순하게

명령어 하나로 빌드-테스트-배포가 가능한 환경을 갖춰야 한다는 이야기.

복잡한 환경 세팅에 에너지를 낭비하지 말라는 조언입니다.

3) 소통 방식을 단순하게

저자는 회의에 대해 아주 직접적으로 말합니다.

"회의는 비효율적이고, 불공평하고, 방해가 되고, 비용도 많이 든다."

정말 공감되는 말이죠 ㅎㅎ

그렇다고 회의를 없애라는 게 아니라, 목적이 명확한 회의만 하라는 거예요.

팀 리더라면 특히 귀담아 들을 만한 내용입니다.

4) 코드를 단순하게

이 파트가 프로그래머들이 가장 흥미롭게 읽는 부분!

특히 "코드보다 데이터에 주도권을 넘겨라" 는 조언이 인상적입니다.

복잡하게 얽힌 로직을 데이터 기반으로 재설계하면 훨씬 명료해진다는 이야기입니다.

상태 머신(State Machine) 활용법도 실전적으로 소개되어 있어요.

코딩과 실생활에 적용하면!

책의 내용을 읽고 코딩과 실생활에 어떻게 적용할지 생각해 보았습니다.

1) Orient-Step-Learn

<실생활 적용>

운동을 시작할 때 '하루 1시간 매일'이 아니라 '일단 운동복만 입기' 부터 시작해보자.

작은 첫 발이 습관을 만든다.

2) 개발 환경을 단순하게

명령어 하나로 모든 것이 돌아가게 하자.

<코딩>

- Before : 매번 이 과정을 손으로 반복(사실 이런 분은 없겠죠? 예를 들어본 것 입니다.^^)

# cd /project
# npm install
# npm run lint
# npm test
# npm run build
# scp dist/* server:/var/www/
// 뭔가 빠뜨리면 처음부터 다시... ㅠㅠ

- After (단순화)

makefile

deploy:
npm install && npm run lint && 
npm test && npm run build && 
scp dist/* server:/var/www/
@echo "배포 완료!"

# make deploy   // 이제 터미널에서 딱 한 줄로 끝!

<실생활 적용>

매일 반복하는 일상 루틴(아침 준비, 주간 정리 등)을

체크리스트로 만들어두면 생각하는 에너지를 아낄 수 있습니다.

3) 단순하게 설명하기

<실생활 적용>

이메일이나 보고서를 쓸 때 '결론을 맨 앞에' 원칙을 적용해보자.

바쁜 상대방이 첫 문장만 읽어도 핵심을 알 수 있어야 한다.

4) 회의 최소화

<실생활 적용>

목적 없는 회의는 하지 마라

Before

- 진행 상황 공유 (문서로 대체 가능)

- 아이디어 브레인스토밍 (개인 작성 후 취합이 더 효율적)

- "어떻게 생각하세요?" 확인용 (슬랙 메시지로 충분)

- 정기 주간 회의 (안건 없으면 취소)

After (단순화)

회의 전 체크리스트:

- 이 회의의 명확한 목적이 있는가?

- 문서/메시지로 대체 불가능한가?

- 참석자 모두가 필수인가?

- 30분 이내로 끝낼 수 있는가?

→ 하나라도 NO면 회의 취소 or 리스케줄

5) 상태 머신 (State Machine) 활용

복잡한 상태 변화를 명확하게 표현하라

<코딩>

Before

let isLoading = false;
let hasError = false;
let isSubmitted = false;
// 이 조합이 8가지나 됨. 어떤 게 유효한지 모름

After (단순화)

const STATES = {
IDLE: 'idle',
LOADING: 'loading',
SUCCESS: 'success',
ERROR: 'error',
};

const TRANSITIONS = {
[STATES.IDLE]: { submit: STATES.LOADING },
[STATES.LOADING]: { ok: STATES.SUCCESS, fail: STATES.ERROR },
[STATES.ERROR]: { retry: STATES.LOADING },
[STATES.SUCCESS]: { reset: STATES.IDLE },
};

function transition(current, event) {
return TRANSITIONS[current]?.[event] ?? current;
}
// 현재 상태가 어디인지 항상 명확!

<실생활 적용>

프로젝트 진행 상황도 상태 머신처럼 관리해보세요.

'준비 → 진행 중 → 검토 중 → 완료'처럼 명확한 단계를 정해두면

현황 파악이 쉬워집니다.

비개발자도 이해할 수 있는 핵심 메시지

이 책의 핵심을 일상적인 말로 표현하면 이렇습니다.

집 안에 물건이 너무 많으면 청소하기 힘들고, 필요한 물건도 못 찾죠?

코드도 마찬가지입니다.

쓸데없는 기능, 불필요한 라이브러리, 복잡한 구조...

이런 것들이 쌓이면 나중에 고치거나 발전시키기가 엄청 힘들어져요.

처음부터 꼭 필요한 것만 만들고, 단순하게 유지하는 것이 결국 더 빠르고 오래갑니다.

출처 입력

AI가 코드를 자동으로 만들어주는 시대에,

정말 중요한 개발자의 경쟁력은 "무엇을 만들지 판단하는 능력" 이라는 메시지,

참 묵직하게 다가오지 않나요?

이런 분들께 강력 추천!

- "코드가 점점 복잡해지는데 어떻게 해야 할지 모르겠다"는 개발자

- 《실용주의 프로그래머》를 인상 깊게 읽었던 분

- 주니어를 넘어 시니어 개발자로 성장하고 싶은 분

- 팀을 이끌면서 회의와 소통 문제로 고민하는 팀 리더

- AI 시대에 개발자로서 나아갈 방향이 궁금한 모든 분

마무리하며...

얇지만 가볍지 않은 책.

코딩 기술을 가르쳐주는 책이 아니라,

개발자로서 어떤 태도로 살아야 하는지를 다시 생각하게 해주는 책입니다.

50년 넘게 코드를 써온 대가가 전하는 조언,

한 번쯤 귀 기울여 볼 가치가 충분하지 않을까요?

미니멀리즘 프로그래머

- 저자: 데이비드 토머스 / 번역: 이민석

- 출판사: 한빛미디어 / 192쪽 / 20,000원

- 원서: Simplicity: Sustainable, Humane, and Effective Software Development

#미니멀리즘프로그래머 #데이비드토머스 #한빛미디어 #개발자책추천 #실용주의프로그래머 #프로그래밍 #소프트웨어개발 #AI시대개발자 #단순함 #Simplicity #개발서적 #코딩



"실용주의"를 넘어 "미니멀리즘"으로 

《미니멀리즘 프로그래머》는 《실용주의 프로그래머》의 공동 저자인 데이비드 토머스(David Thomas)의 신작입니다.

원제는 Simplicity: Sustainable, Humane, and Effective Software Development이며, 제목 그대로 소프트웨어 개발을

어떻게 더 단순하고 지속 가능하게 만들 수 있을지에 대해 이야기하는 책입니다.

책의 전체적인 흐름은 《실용주의 프로그래머》와 어느 정도 닮아 있습니다.

거창한 이론을 전면에 내세우기보다는, 저자의 오랜 경험을 바탕으로 실제 현장에서 적용할 수 있는 방식들을

풀어내는 형태입니다. 어떤 방법이 효과적이었는지, 그리고 문제가 생겼을 때 왜 그런 선택을 했는지를 차분히

설명해주기 때문에 실무를 해본 개발자라면 더 공감하면서 읽을 수 있습니다.

두 책은 공통점도 분명합니다.

   - 둘 다 단순히 코드를 잘 짜는 것만을 이야기하지 않습니다.

   - 도구 활용, 자동화, 협업, 변화 대응, 유지보수성까지 함께 보아야 한다고 말합니다.
하지만 두 책이 던지는 질문은 다릅니다.

《실용주의 프로그래머》가 “좋은 개발자는 무엇을 익혀야 하는가?”를 묻는 책이라면,

《미니멀리즘 프로그래머》는 “왜 개발은 자꾸 복잡해지는가, 그리고 무엇을 덜어내야 하는가?”를 묻는 책에 더 가깝습니다.

그래서 개인적으로는

《실용주의 프로그래머》가 개발자의 기본기를 다지는 교본 같은 책이라면,

《미니멀리즘 프로그래머》는 어느 정도 경험을 쌓은 개발자가 자신의 일하는 방식과 코드를 다시 돌아보게 만드는 교정서에 가깝다고 느꼈습니다.

“따라 하지 마세요”라는 말이 인상적이었습니다.

이 책에서 특히 인상 깊었던 부분 중 하나는, 저자가 책의 내용을 그대로 따라 하지 말라고 이야기하는 대목이었습니다.

저자는 자신의 경험 속에서 어떤 문제가 있었고, 왜 복잡함을 줄이기 위해 그런 선택을 했는지를 보여줍니다. 하지만 그것을 정답처럼 강요하지는 않습니다. 오히려 독자가 자신의 환경과 상황 속에서 각자의 답을 찾는 데 도움이 되기를 바라는 태도가 느껴졌습니다.

실제로 책을 읽으면서도 “무조건 이렇게 해야 한다”는 느낌보다는, “이렇게 접근할 수도 있겠구나”, “아, 이런 관점으로 볼 수도 있겠네”라는 생각이 더 많이 들었습니다. 그 점이 오히려 더 좋았습니다. 부담 없이 읽히면서도, 내가 진행했던 프로젝트들을 떠올리게 만들었기 때문입니다.

읽다 보면 자연스럽게 “아, 예전에 이런 경우가 있었지”, “그때 나는 어떻게 했었지?” 하고 스스로를 돌아보게 됩니다. 그런 점에서 이 책은 단순히 지식을 전달하는 책이라기보다, 경험 있는 개발자에게 생각할 거리를 던져주는 책이라는 느낌이 들었습니다.

특히 PART 01의 ‘코드 다이어트’는 실무와 맞닿아 있어 더 인상적이었습니다. 실제 프로젝트를 진행하다 보면 필요 이상으로 코드가 무거워지거나, 꼭 필요하지 않은 것까지 얹게 되는 경우가 많습니다. 그런 부분을 다시 생각하게 해주는 내용이었습니다.

물론 책의 내용 중에는 내가 진행하는 프로젝트와 그대로 맞지 않는 부분도 있었습니다. 하지만 그것은 구현 방식과 프로젝트 환경이 다르기 때문이지, 책의 내용이 틀렸기 때문은 아니라고 생각합니다. 이 책은 “무조건 이렇게 해야 한다”는 식의 정답을 주는 책이 아니라, 복잡성을 줄이는 방향을 제시하는 책이기 때문에 자신의 상황에 맞게 받아들이는 것이 중요하다고 느꼈습니다.

변화는 불편하지만, 받아들여야 한다

또 하나 인상 깊었던 점은 변화에 대한 태도였습니다.

개발을 오래 하다 보면 익숙한 기술과 익숙한 방식에 머무르고 싶어질 때가 많습니다. 특히 시니어 개발자가 될수록 자신의 경험이 강한 무기가 되는 동시에, 새로운 것을 받아들이는 데 조심스러워질 수도 있습니다. 그것이 쉽지 않다는 점도 충분히 공감됩니다.

하지만 소프트웨어 개발은 변화가 매우 빠른 분야입니다. 최근에는 AI 기술의 발전으로 그 변화의 속도가 더 빨라졌습니다. 새로운 도구와 방식이 계속 등장하고, 예전에는 중요하게 여겼던 기준이 달라지기도 합니다.

이런 시점에서 변화를 무조건 두려워하기보다, 조금 느리더라도 받아들이고 따라가려는 태도가 결국 오래 살아남는 힘이 된다고 생각합니다. 책을 읽으며 특히 공감했던 것은, 저자가 배우는 일을 부담이 아니라 즐거움으로 바라보려 한다는 점이었습니다.
나 역시 그런 태도를 잃지 않도록 노력해야겠다는 생각이 들었습니다.

마무리 ....

《미니멀리즘 프로그래머》는 단순히 “덜 만들자”는 책이 아닙니다.
오히려 “복잡성을 통제할 수 있는 방식으로 만들자”는 책에 가깝습니다.

무언가를 더 추가하는 능력보다, 무엇을 줄이고 어떻게 단순하게 유지할 것인가를 고민하게 만든다는 점에서 의미가 컸습니다.

특히 요즘처럼 AI가 구현 속도를 높여주는 대신 설계 부채를 더 빨리 키울 수도 있는 시점에는 더욱 시의적절한 책이라고 생각합니다.

실무를 어느 정도 경험한 개발자라면, 자신의 코드와 일하는 방식을 다시 돌아보게 만드는 계기가 될 만한 책입니다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

1. 이 책을 선택한 동기

에이전틱 코딩이 익숙해질수록 모든 코드를 일일이 검토하지 못하는 빈도가 높아졌어요. 병렬 에이전트를 동시다발적으로 지휘하다보면 한 사람 한 사람의 코드를 모두 세세히 파악하기는 쉽지 않죠. 점차 코드 하나하나에 대한 고민이 줄어들수록, 현 시대에 맞춘 개발 방법론에 대해 한번 짚고 가고 싶었습니다.

그러던 중에 미니멀리즘 프로그래머을 만났어요. 『실용주의 프로그래머』의 공동 저자 중 한명인, 데이비드 토머스가 AI 시대에 단순함을 이야기한다는 게 마침 타이밍이 맞았어요. 지금 이 시점에 읽어야 할 책이다 싶었습니다.

2. 어떤 책인지

192쪽이라는 얇은 분량에 29가지 실천법(Practice)을 담은 책이에요. 코드, 팀, 환경, 소통 — 개발자 삶의 전 영역에서 복잡함을 걷어내는 법을 이야기해요. 코드 기술서라기보다는 개발자의 태도와 습관에 대한 책에 가까워요.

크게 4개 파트로 나뉘는데 구성이 재밌었어요.

PART 1 하는 일 단순화: 의존성, 프레임워크, 기능 관리

PART 2 환경 단순화: 자동화, 터미널, 에디터

PART 3 상호작용 단순화: 팀 회의, 소프트 스킬, 공감

PART 4 코드 단순화: 데이터 주도 개발, 가독성

저자가 서문에서 던지는 질문이 인상적이었어요.

"슬픈 사실은 프로젝트를 복잡하게 만든 장본인이 대부분 우리 자신이라는 점입니다. 잠시 멈춰 서서 생각하지 않고, '이게 정말 맞나?'라고 묻는 내면의 작은 목소리를 외면하는 순간 복잡함이 싹틉니다." (p.16)

3. 특히 인상적이었던 점

"복합적(complex)"과 "복잡한(complicated)"은 다르다 (p.16)

책 서문에 나오는 구분이 머릿속에 오래 남았어요. 눈송이 비유가 인상적이었어요.

"소프트웨어의 복합적인 면은 다루기 어렵지만, 그 안에는 분명한 규칙이 존재합니다. 하지만 그 규칙을 무시하면 '복잡함'이 찾아옵니다." (p.16)

눈송이는 복합적(complex)이지만, 날씨는 복잡(complicated)합니다. 소프트웨어도 마찬가지예요. 읽으면서 제가 만들어온 코드들이 떠올랐어요. "일단 돌아가면 됐지"로 넘어간 순간들이 쌓여서 결국 아무도 건드리기 싫은 파일이 되는 과정... 정확히 그 흐름이에요.

의존성을 추가하는 건 통제권을 넘기는 일 (p.31)

"저는 의존성이라면 단 하나의 예외도 없이 싫어합니다. 의존성을 추가하면 미래의 내가 가져야 할 통제권의 일부를 남에게 넘겨주는 것이나 다름없습니다." (p.31)

 

저자가 인용한 조 암스트롱의 말도 머릿속에 남아요.

"바나나 하나만 필요했을 뿐인데, 바나나를 든 고릴라와 정글 전체가 딸려온다." (p.35)

프레임워크에 대해서도 강하게 경계해요.

"프레임워크가 API를 쥐고 있을 뿐만 아니라, 애플리케이션 아키텍처를 어떻게 짤지까지 규정해 버리기 때문입니다." (p.39)

 

Next.js를 쓰면서 "왜 이렇게 해야 하지?"를 고민하기보다 프레임워크가 시키는 대로 따라가고 있던 제 모습이 보였어요.

'기능'은 미래의 부채 (p.43)

"'기능'은 '미래의 부채'를 그럴싸하게 포장한 마케팅 용어입니다." (p.43)

 

그리고 같은 챕터에 이런 말도 나와요.

"아무도 요청하지 않은 코드는 작성하지 마세요." (p.44)

읽으면서 찔렸어요. 요청도 안 받았는데 "이 기능 있으면 좋겠다"는 생각에 혼자 만들었다가 결국 유지보수만 늘어난 경험이 한두 번이 아니거든요.

"할 수 있다"와 "해야 한다"는 다르다 (p.100)

이 문장은 챕터 도입부에서 자신의 에디터 설정을 너무 과하게 꾸몄던 경험을 반성하며 나오는데, AI 시대에 더욱 날카롭게 읽혔어요.

"할 수 있다고 해서 좋은 생각인 건 아닙니다." (p.100)

AI가 뚝딱 코드를 만들어주는 시대에, 기술적으로 가능하다는 이유로 덥석 붙여넣는 게 얼마나 위험한 일인지 다시 생각하게 됐어요. 코드를 생성하는 능력은 평준화되지만, 그 코드가 지금 정말 필요한지 판단하는 능력은 여전히 사람의 몫이에요.

코드에도 공감이 필요하다 (p.133)

요트 스키퍼 이야기가 정말 좋았어요. 초보와 숙련자의 차이를 이렇게 설명해요.

"그는 배를 굴복시키려 들지 않았습니다. 대신 배의 움직임을 느끼고, 배와 '합의'를 이루려고 했습니다." (p.134)

코드도 마찬가지라고 저자는 말해요. 뭔가 저항감이 느껴지거나 평소보다 힘들다는 느낌이 들면, 그냥 억지로 밀어붙이지 말고 멈춰서 살펴보라고요. 그 감각이 잠재의식이 보내는 신호라고요. 개발하면서 "이건 뭔가 이상한데..."라고 느끼면서도 그냥 넘어간 적이 얼마나 많았는지 돌아봤어요.

회의는 원래 애자일하지 않다 (p.54)

코드 얘기가 아니라 조금 뜬금없을 수 있지만, 이 챕터도 제게 꽤 충격이었어요.

"회의는 비효율적이고 불공평하며 업무를 방해하고 비용도 많이 듭니다." (p.57)

저자는 10명 팀이 2주 스프린트 동안 회의에만 13시간 30분을 쓴다는 걸 계산으로 보여줘요. 더 인상적인 건 이 문제를 해결하기 위해 DWP(포트폴리오 없는 개발자)라는 새로운 역할을 제안한다는 거예요. 코드를 짜지 않고 팀이 원활하게 돌아가도록 돕는 역할이에요. "팀이 엔진이라면 DWP는 윤활유"라는 비유가 딱 맞아요. 이걸 읽으면서 팀에 이런 사람이 한 명 있고 없고가 얼마나 큰 차이인지 실감했어요.

상태 머신으로 로직 단순화하기 (p.163)

"저는 상태 머신을 자주 사용합니다. 상태 머신을 적용할 때마다 제가 작업하던 코드가 더 좋아졌습니다." (p.163)

"상태 머신 구현은 복잡한 라이브러리나 긴 패턴 기반 접근 방식이 없어도 충분합니다. 필요한 것은 룩업 테이블 하나뿐입니다." (p.164)

 

로그인 상태, 주문 상태, 결제 상태... 대부분의 UI 로직은 상태 변화인데, 이걸 명시적으로 모델링하지 않고 if/else로 땜빵해온 경우가 얼마나 많았는지 돌아보게 됐어요. 루비 코드로만 예시가 나와서 JavaScript에서는 어떻게 쓸지 직접 실험해봐야 했지만, 개념 자체가 강하게 남았어요.

4. 덕분에 무엇을 배웠는가

단순함은 기술이 아니라 태도다. 코드를 짧게 줄이는 테크닉이 아니라, 불필요한 것을 덜어내는 판단력의 문제예요. "단순함은 결코 단순하지 않습니다. 신중하게 의도되고 충분히 다듬어지며 실질적으로 효과적입니다." (p.191)

AI가 짜준 코드도 검토할 줄 알아야 한다. AI가 코드를 생성해줄수록, 그 코드가 정말 필요한 건지 판단하는 능력이 더 중요해져요. "할 수 있다"와 "해야 한다"는 다릅니다.

자동화는 인지 부담을 줄인다. "자동화를 더 많이 할수록 기억해야 할 것이 줄어듭니다." (p.84) 배포 자동화, 환경 설정 자동화가 단순히 편리한 게 아니라 코드 품질과도 직결된다는 걸 배웠어요.

탐색은 미래에서, 일은 과거에서. "매일 의존하는 도구와 라이브러리의 경우, 화려하거나 새로운 것보다 지루하고 안정적인 것이 언제나 더 낫습니다." (p.116) 새로운 기술은 탐색 시간에 실험하고, 실제 프로젝트에는 검증된 것을 쓴다는 원칙이 납득됐어요.

공감이 코드 단순화에도 영향을 미친다. 코드에도 귀를 기울이고, 팀원과의 마찰을 줄이는 것이 결국 시스템 단순화로 이어진다는 연결이 인상적이었어요.

의존성 추가 전에 한 번 더 생각하자. 정말 이게 없으면 안 되는가? 직접 11줄로 짤 수 있는 건 아닌가?

5. 좋았던 점

코드만 이야기하지 않는다

기술 서적인데 회의 방식, 팀 커뮤니케이션, 소프트 스킬까지 다루는 게 오히려 좋았어요. 개발의 복잡함은 코드에서만 오는 게 아니니까요. "다양성은 회복력입니다"(p.73) — 동물 종과 팀 모두에 해당한다는 말이 오래 남았어요.

저자의 솔직함

저자는 자신이 소프트 스킬이 부족하다고 스스로 인정하면서 챕터를 시작해요. "저는 공감 능력 척도에서 4 정도 될 것 같습니다"라고요. 이런 솔직함 덕분에 '완벽한 개발자가 가르치는 이야기'가 아니라 '함께 개선해가는 과정'처럼 읽혔어요.

6. 아쉬운 점

29가지 원칙 중 일부는 너무 짧게 다루고 지나가서 "이건 더 파줬으면..." 싶은 챕터가 몇 개 있었어요. 특히 상태 머신 부분은 루비 코드 예시만 나와서, JavaScript/TypeScript 개발자는 직접 변환해서 써봐야 했어요. 가독성 챕터(CH.08)의 Practice들은 너무 실용적이고 좋았는데 후반부에 급히 달린 느낌이 들었고요.

7. 이 책을 읽은 덕분에 기대되는 변화

복직하면 코드 리뷰할 때 "이 의존성이 정말 필요한가?"를 먼저 물어볼 것 같아요. 그동안은 "동작하면 됐다"는 태도로 넘어갔던 순간들이 있었는데, 이제는 동작하는 가장 단순한 선택을 먼저 찾아보는 습관을 들이고 싶어요.

그리고 Practice 22에서 배운 상태 머신 패턴을 사이드 프로젝트인 북골라스에 바로 적용해볼 계획이에요. 독서 상태 관리(reading → paused → finished)를 명시적 상태 모델로 다시 짜보면 좋겠다 싶거든요. 라이브러리 없이 룩업 테이블 하나로.

자동화도 다시 점검하고 싶어요. "배포 체크리스트를 여기저기 찾아 헤맬 필요가 없다"(p.84)는 말처럼, 기억해야 할 것들을 자동화로 줄이는 작업을 미뤄왔는데 이 책을 읽고 다시 의욕이 생겼어요.

저자의 마지막 문장이 오래 남아요.

"코드와 코딩 방식, 그리고 나아가서는 삶 자체도 가능한 한 단순함을 추구하세요. 이 방법을 적용하면 생산성이 높아지고 스트레스가 줄고 업무에 즐거움과 재미를 다시 느낄 수 있을 겁니다. 여러분에겐 그럴 자격이 있습니다." (p.191)

안녕하세요, WMS와 HR 시스템을 개발하고 있는 5년 차 개발자입니다. 요즘 프로젝트를 하면서 느끼는 건 하나였어요. "왜 이렇게 점점 복잡해지지…?" 오히려 올바른 프로그래밍을 하고 있는 건가라는 고민에 빠지게 되는 것 같습니다.

기능은 늘어나고, 코드도 늘어나고, 의존성도 계속 붙고… 어느 순간부터는 '개발'이 아니라 '복잡함 관리'가 일이 되어버린 느낌이었습니다. 그러던 와중에 [미니멀리즘 프로그래머]를 읽게 됐습니다.

결론부터 말하면, 이건 그냥 책이 아니라 개발 방식 자체를 다시 생각하게 만드는 트리거였습니다.

"코드를 더 잘 짜는 법이 아니라, 복잡함을 줄이는 사고방식 자체를 바꿔준다." 코드를 더 건강하게 만들 때입니다. 코드를 다이어트할 때입니다.

솔직히 찔렸습니다. 저 포함 대부분의 프로젝트가 "살찌는 방향"으로 가고 있거든요. 필요 이상으로 붙는 라이브러리, 점점 늘어나는 의존성, 수정하면 어디 터질지 모르는 구조. 특히 Phoenix 예시에서 "기본 프로젝트인데 의존성 40개 이상"이라는 부분 보고 우리 프로젝트 떠올라서 웃음이 나왔습니다. package.json 열어봤거든요. 세어봤습니다. 57개였습니다. 그 중에 지금 실제로 쓰고 있는 게 몇 개인지 추적해보니까, 절반은 "언젠가 쓰겠지" 하고 설치해 놓은 것들이더라고요. 언젠가는 아직 안 왔는데, 용량은 이미 왔습니다.

책에서 말하는 게 결국 이거예요.

"더하는 건 쉽다. 빼는 게 실력이다."

5년 차 되면 뭔가 더 많이 알아야 한다는 압박에 자꾸 도구를 쌓게 되는데, 이 책은 반대로 "덜어내는 훈련"을 시켜줍니다. 읽고 나서 저 한 가지 바로 실천했어요. 안 쓰는 패키지 정리하고, 의존성 12개 제거했습니다. 빌드 타임 줄었고, 번들 사이즈도 같이 줄었고, 무엇보다 npm install 할 때 덜 불안해졌습니다.

현황 파악 → 실행 → 학습

이건 거의 개발판 PDCA인데, 훨씬 현실적입니다. 복잡한 부분을 먼저 인정하고, 완벽한 설계보다 "작은 실행"을 먼저 치고, 결과 보고 계속 개선하는 흐름이에요. 말로 쓰면 당연한 것 같은데, 실제로 팀에서 이걸 못 하는 경우가 엄청 많거든요. 저희도 그랬어요. 설계 회의가 2주 넘게 가는데, 정작 코드 한 줄 안 나오는 스프린트가 있었거든요.

책 읽고 나서 팀한테 제안했습니다. "일단 작게 만들고 보자. 완벽한 설계는 두 번째다." 처음엔 반신반의했는데, 한 스프린트 돌아보니까 차이가 눈에 띄더라고요. 설계 회의 시간은 줄었고, 실제 구현 속도는 올라갔고, 무엇보다 팀 피로도가 확 내려갔습니다. 회의실에서 화이트보드 앞에 서서 "이 구조가 맞냐 틀리냐" 토론하던 시간을, 그냥 만들면서 확인하는 시간으로 바꿨을 뿐인데요. 특히 "완벽한 설계 먼저 하지 말라"는 부분, 팀 슬랙에 캡처해서 공유했는데 반응이 제일 좋았습니다. 시니어 개발자분이 "이거 진작에 알았으면..." 하셨을 때, 저도 같은 생각이었어요.

이 챕터는 그냥 실무 필살기입니다. 책에서 말하는 핵심은 단순해요. 결합도가 높으면 변경이 지옥이 된다. 그리고 결국엔 아무도 건드리기 싫은 코드가 된다.

읽으면서 손이 떨렸습니다. 우리 팀 얘기를 어떻게 알았지 싶어서요. 저희가 정확히 그 상태였거든요. A 건드리면 B 터지고, B 고치면 C 영향 가고, 결국 rollback. 몇 번 반복되니까 팀 내에 불문율이 생겼어요. "그 모듈은 건들지 말자." 아무도 말 안 했는데, 다들 알고 있는 그 분위기요.

책에서 나온 Hassan과 Jan 예시 보면서 웃음이 나왔습니다. Jan이 휴가 중이라 Hassan이 일을 못 한다는 그 장면, 코드 얘기인 줄 알았는데 팀 구조 얘기더라고요. 결합은 코드만의 문제가 아니라는 거, 그게 제일 인상 깊었어요.

책 읽고 나서 바로 세 가지 바꿨습니다. 공통 로직 분리하고, 의존성 줄이고, 서비스 레이어 역할을 명확하게 다시 정의했어요. 거창한 리팩토링이 아니었어요. 그냥 "이 함수가 여기 있어야 하나?" 질문 하나씩 던지면서 옮긴 거였는데, 결과가 체감될 정도로 달랐습니다. 수정 속도가 확실히 빨라졌고, 코드 리뷰할 때 "이거 바꾸면 어디 터지냐"는 질문이 줄었어요. 그 질문이 줄었다는 게, 사실 제일 큰 변화였습니다. 리뷰 스트레스가 그 질문에서 제일 많이 왔거든요.

책에서 이런 말이 나와요. 100% 정확한 기술적 답변이라도, 상대방이 세부 사항을 잘 모르는 이상 오히려 혼란을 일으킬 수 있다고. 즉, 설명의 혼란을 줄이기 위해 현실과 다소 차이가 나는 부분을 감수해야 할 때가 있다는 거예요.

읽으면서 뜨끔했습니다. 저 맨날 정확하게 설명하려다가 팀원들 눈 풀리게 만들었거든요.

특히 도메인 선택하기 부분이 인상적이었어요. 아무리 좋은 비유도, 상대방이 그 배경을 모르면 소용없다는 거예요. 책에서 명확하게 피하라고 하는 도메인이 있어요. 한 사람만이 깊이 있는 전문 지식을 보유한 도메인, 구축에 오랜 시간이 걸리는 환경, 정치·종교·사회적 이슈. 당연한 것 같은데, 저 세 번째 많이 어겼습니다. 회의 중에 괜히 사회 이슈 비유 들었다가 분위기 이상해진 적 한두 번이 아니에요.

이게 코드 얘기가 아니에요. 팀 안에서 소통하는 방식 얘기입니다. 코드 리뷰할 때도, 신입한테 설명할 때도, 기획자랑 회의할 때도 결국 이 원칙 하나로 수렴하더라고요.

그래서 요즘은 코드 구조 정리랑 팀 커뮤니케이션 개선을 같이 진행 중입니다. 어느 한쪽만 건드리면 결국 원래대로 돌아오거든요. 코드만 깔끔하게 정리해봤자, 팀 소통이 그대로면 한 달 뒤에 다시 엉킵니다. 이 챕터 하나가, 저한테는 기술서라기보다 팀 운영 가이드처럼 읽혔어요.

5년 차 개발자로서 솔직히 말할게요. 이 책은 기술서를 기대하면 안 됩니다. 알고리즘 설명 없고, 프레임워크 비교 없고, 최신 트렌드도 없어요. 그런 걸 기대하고 펼치면 실망할 수 있습니다.

대신 이 책이 주는 건 하나예요. "개발을 어떻게 해야 하는지." 기술이 아니라 방향. 코드가 아니라 사고방식. 읽고 나서 코딩 실력이 느는 게 아니라, 코딩하기 전에 먼저 멈추게 됩니다. "이거 꼭 필요한가?", "더 단순하게 할 수 있는가?" 이 질문이 자동으로 나오기 시작해요. 5년 차라면 설계의 영역에 도전하게 되고, 더 좋은 코드를 위해 노력해야 합니다. 그렇기 때문에 이 책을 추천합니다.

"잘 만드는 것보다, 덜 복잡하게 만드는 게 더 중요하다."

읽고 나서 달라진 게 있다면, 코드 짜기 전에 구조부터 고민하게 됐고, 복잡하다는 느낌이 들면 방향이 잘못됐다는 신호로 받아들이게 됐어요.

[미니멀리즘 프로그래머]는 "한 번 읽고 끝"이 아닙니다. 꽂아두고 가끔 꺼내보는 기준서 같은 느낌이에요. 실무에서 뭔가 꼬인다 싶을 때 펼쳐보면 답이 거기 있더라고요. 부담 없이 한 번 읽어보세요. 읽고 나서 분명 package.json 한 번 다시 열게 될 겁니다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다.

#한빛미디어 #나는리뷰어다 #미니멀리즘 프로그래머

『실용주의 프로그래머』로 수많은 개발자의 나침반이 되어주었던 데이비드 토머스가 이번에는 '복잡함'이라는 괴물을 잡기 위해 돌아왔습니다.

최근 AI가 코드를 대신 짜주고 온갖 편리한 프레임워크가 넘쳐나면서, 우리는 10줄이면 끝날 일에 거대한 라이브러리를 끌고 오는 '오버엔지니어링'의 유혹에 쉽게 빠집니다. 이 책은 바로 그 지점을 날카롭게 찌릅니다. 저자는 소프트웨어의 '복합적(complex)'인 구조 자체는 인정하되, 그것이 통제 불능의 '난해함(complicated)'으로 변질되는 것을 경계해야 한다고 말합니다.

책을 읽으며 가장 크게 와닿았던 점은, 미니멀리즘이 단순히 '코드를 짧게 치는 기술'이 아니라 프로젝트의 핵심 가치에 집중하는 '태도'라는 사실입니다. 무거워진 시스템과 유지보수의 늪에서 고민하는 개발자라면 반드시 읽어보시길 권합니다. 주니어에게는 올바른 설계 습관을, 시니어에게는 본질을 되돌아보는 환기의 시간을 제공해 줄 것입니다. 코드를 덜어낼 줄 아는 감각이야말로 진정한 실력임을 깨닫게 해주는 좋은 책이었습니다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다."

안녕하세요. 한빛미디어 서평단 2번째 리뷰할 책은 미니멀리즘 프로그래머 - 데이비드토머스(역.이민석)입니다.
도서링크: https://www.hanbit.co.kr/store/books/look.php?p_code=B1991210307

https://www.hanbit.co.kr/store/books/look.php?p_code=B1991210307

www.hanbit.co.kr

도구의 화려함 뒤에 숨겨진 함정

저는 지금 주니어개발자이지만, 가끔 개발을 하기위해 여러 라이브러리, 개발 편의성을 위한 툴들을 사용하다보면 의존성이 더 복잡해지고 배보다 배꼽이 커지는 경우도 많습니다.

지금도 물론 그런 경향이 남아있습니다만, 개발을 처음 접했을 때는 더 멋있고, 세련되고 최신 기술을 탐구하는게 fancy한 기술을 사용하는게 실력이라 생각했습니다.
하지만 실무에서 매번 새로운 라이브러리를 도입하기도 쉽지않고 의존성이 고여 배보다 배꼽이 커지는 상황을 겪어보며 고민해보았습니다.
이 책은 저에게 단순함(Simplicity)라는 개발의 본질을 알려주었습니다.

원제 'Simplicity'기 담고 있는 지속 가능한 개발

영어 원문 제목은 simplicty - sustainable, humane, and effective software development 인데요, 국내 출시판은 미니멀리즘 프로그래머 - AI시대, 복잡함을 줄이고 가치를 올리는 개발원칙이라는 제목과 부제로 이루어져있습니다.

부제만 보면 AI시대에 대응하기위한 책으로 보일 수도 있는데요. 책에는 AI에 대한 내용은 따로 언급되진않고 소프트웨어 개발을 대하는 본질로서 'simplicity' 즉, 단순함, 간단함을 본질로서 내용을 전개합니다. 특히 회의에 대한 챕터는 너무 공감이 되었고, 책에서 제안한 내용을 바탕으로 개선버전을 제안해봐야겠다고 생각했습니다.

장인은 도구를 탓하지 않는다.

취업을 하고 다양한 코드를 보고 많은 개념들을 접하고 고연차의 선배님들을 보다보면 단순함의 미학이라는 의미가 더 와닿곤 합니다.

'장인은 도구를 탓하지 않는다.' 많은 분들이 들어보신 말들일텐데요. 가끔 회사의 고연차 선배님들을 보면 정말 bash shell만큼은 기가 막히게 다룹니다. 저는 IDE가 어떻고 이런 것도 지원을 안해주고 뭔가 항상 도구를 탓하기 바빴는데 진정한 고수분들은 터미널로 뚝딱 해내십니다.

그런 의미에서 이 책이 관통하는 주제가 단순함 즉, 덜어냄의 미학을 얘기합니다.

도구 뿐만 아니라, 소프트웨어 개발, 의사소통 등등 일을 할 때 발생하는 대부분의 상황에 대해서 'simplicity'라는 원칙을 갖고 접근을 합니다. 주로 저자의 경험을 나누는 형식으로 말이죠.

물론 좋은 도구는 개발시간을 단축하고 생산성을 올리긴 합니다만, 뭔가 선후관계가 뒤바뀐 것 같다고 느끼는 주니어 개발자분들이 읽어보시면 인사이트를 얻을 것 같습니다.

꿀팁

매 챕터마다 저자의 관점과 사례를 소개하고 '이렇게 해보세요', '도전해보세요'라는 미니 코너가 있습니다. 여기서는 독자들이 실제 본인의 상황에 대입해보고 생각하게끔 구체적으로 도와줍니다.

이 책은 시대에 상관없이 읽을 수 있는 책입니다. 직접 실습을 해보는 구간은 없지만 볼륨이 작아서(약200 페이지) 조금씩 자주 읽기 좋은 책인 것 같습니다.

추천대상

기술의 홍수 속에서 공부할 리스트가 늘어나는 '주니어 개발자', 시스템의 복잡도 때문에 고민이 깊어지는 '시니어 개발자' 모두에게 시대가 변해도 변하지 않는 '단순함'의 가치를 느껴보기 위해 이 책을 추천드립니다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

우리는 왜 11줄짜리 코드를 위해 무거운 라이브러리를 설치하는가?

웹사이트 유지보수를 5년째 해오면서, 프로젝트에 새로운 요구사항이 생길 때마다 습관적으로 거대한 라이브러리를 추가하곤 했습니다. 최근 파이썬으로 AI 관련 토이 프로젝트를 진행할 때도 마찬가지였습니다. 일단 남들이 다 쓴다는 무거운 프레임워크부터 깔고 시작하다 보니, 어느새 프로젝트는 비대해지고 에러가 터지면 어디서부터 손대야 할지 막막해지는 이른바 '복잡함의 늪'에 빠졌죠.

이러한 정보 과잉과 기술의 홍수 속에서 번아웃을 느끼던 찰나, 『실용주의 프로그래머』의 저자 데이비드 토머스의 신작 <미니멀리즘 프로그래머>를 집어 들게 되었습니다. 이 책은 "기술의 속도가 빨라질수록 왜 우리는 다시 '단순함'으로 돌아가야 하는가?"라는 묵직한 질문을 던집니다.

복잡한 의존성 코드와 '단순함'을 말하는 책이 대조를 이룬다.

미니멀리즘은 코드 길이를 줄이는 '기술'이 아니라 '태도'다

가장 뼈를 때렸던 부분은 "미니멀리즘은 단순히 코드를 짧게 짜는 것이 아니다"라는 대목이었습니다.

• 나의 뼈아픈 경험: 과거에 저는 중복 코드를 없애겠다고 지나치게 추상화된 만능 공통 클래스를 만든 적이 있습니다. 당시에는 "나 좀 코드 잘 짜는데?"라고 뿌듯해했지만, 결국 나중에 합류한 동료들이 그 코드를 이해하지 못해 유지보수성이 바닥을 치는 흑역사를 남겼죠.
• 책에서의 깨달음: 책에서는 이처럼 '과도한 엔지니어링'이 오히려 시스템을 짓누르는 무게가 된다고 지적합니다. 진짜 미니멀리즘은 코드가 짧은 것이 아니라, 동작하는 가장 단순한 선택을 통해 '지속 가능성'을 확보하고 동료와 명확히 소통하는 태도라는 것을 깨달았습니다.

AI가 코드를 짜주는 시대일수록, 시스템의 복잡도를 제어하는 것은 결국 인간의 몫이다.

AI 시대, '더 단순하게 만들 시간'이 필요하다

저자는 이 얇은 책을 통해 익스트림 프로그래밍(XP)의 핵심 가치(의사소통, 단순함, 피드백, 용기, 존중)를 우리 삶 전반에 적용해 보라고 권유합니다. 특히 AI 도구들이 순식간에 엄청난 양의 코드를 찍어내는 요즘, 아키텍처의 복잡도를 제어하지 못하면 결국 개발자가 유지보수라는 지옥불에 떨어지게 됩니다.

책을 읽고 나서 큰 용기를 얻어, 최근 진행하던 개인 프로젝트에서 굳이 필요 없던 서드파티 라이브러리 2개를 과감히 걷어냈습니다. 라이브러리가 해주던 핵심 기능만 바닐라 코드로 직접 구현했더니, 오히려 디버깅이 명확해지고 프로젝트가 한결 가벼워졌습니다. 무조건 최신, 최고 용량의 기술을 붙이는 것이 정답은 아니라는 책의 메시지를 직접 체험한 순간이었습니다.

192쪽의 얇은 분량. 주말 동안 가볍게 읽었지만, 남는 여운은 무겁다.

- 총평 및 추천 대상

<미니멀리즘 프로그래머>는 코드 한 줄 없는 철학책에 가깝지만, 그 어떤 튜토리얼 서적보다 개발자의 일상을 날카롭게 파고듭니다.

✅ 이런 분들에게 추천합니다:

• "이것도 배워야 하고 저것도 도입해야 해!"라며 끊임없는 기술 트렌드에 지친 주니어~중니어 개발자
• 방대한 레거시 시스템과 거미줄 같은 의존성에 매일 고통받고 있는 유지보수 담당자
• 명저 『실용주의 프로그래머』를 감명 깊게 읽고, 저자의 최신 인사이트가 궁금한 분

화려한 프레임워크와 넘쳐나는 정보에 치여 '내가 왜 이렇게 코드를 짜고 있지?'라는 회의감이 들 때, 나침반처럼 꺼내 읽고 싶은 책입니다. 복잡함을 덜어내고 프로그래밍의 진짜 즐거움을 되찾아보세요.

 기능을 더하는 기술보다,
불필요한 것을 덜어내는 용기를 가르쳐주는 책.

최근 논문 수정 무한루프에 빠져 있어서 책을 읽을 여유가 거의 없었다. 이 책도 계속 미루다가 거의 마지막 날이 되어서야 펼쳤고, 속으로 ‘큰일났다’라는 생각이 먼저 들었다. 그런데 막상 읽기 시작하니 예상보다 훨씬 빠르게 읽혔다. 분량이 짧은 것도 있지만, 무엇보다 내용이 재미있고 유익했기 때문이다. 저자 개인의 경험을 바탕으로 짧은 호흡으로 툭툭 던지듯 전하는 조언들이 하나같이 인상 깊었고, 그래서 더 잘 와닿았다.

이 책이 특히 흥미로운 이유는 화려한 기술이나 새로운 프레임워크를 소개하기보다는, 어떻게 하면 덜어낼 수 있는지, 어떻게 하면 더 단순하게 만들 수 있는지, 그리고 그 단순함이 왜 중요한지를 담담하게 풀어내고 있다는 점이다. 누군가를 설득하려 애쓰기보다는 자신의 경험을 조용히 꺼내놓는 방식인데, 오히려 그 점이 더 강한 설득력을 만든다. 코드 다이어트를 하고 의존성을 줄이고 가독성을 높이라는 이야기는 누구나 한 번쯤 들어봤을 것이다. 하지만 이 책은 그런 원칙을 구호처럼 던지는 것이 아니라, 실제 작업과 팀 단위 협업 속에서 어떻게 작동하는지를 구체적으로 보여준다. 그래서 읽는 내내 단순히 이해하는 데서 그치지 않고, 자연스럽게 손이 움직여 내용을 받아적게 되는 경험을 하게 된다.

개인적으로 가장 재미있게 읽었던 부분은 회의에 대한 이야기였다. 회사에 있을 때나 사이드 프로젝트를 진행할 때나 여러 사람이 함께 일하기 위해서는 회의가 필수라고 자연스럽게 받아들여 왔다. 애자일 방법론에서도 서로의 이해를 맞추는 과정을 강조하니 더더욱 그랬다. 하지만 실제로는 회의를 하면서 묘하게 불편함을 느끼거나, 끝나고 나면 시간만 흘러간 것 같은 느낌을 받을 때가 많았다. 이 책은 그런 막연한 불편함의 원인을 정확히 짚어주고, 어떻게 줄일 수 있는지를 현실적인 방식으로 제시한다. 특히 DWP라는 개념을 통해 역할을 단순화하고 의사결정 구조를 명확히 하는 접근은, 회의 자체에 대한 인식을 다시 생각하게 만들었다.

이외에도 자동화를 다루는 부분이나, 기술서에서는 상대적으로 덜 다뤄지는 소프트 스킬에 대한 내용도 인상 깊었다. 반복 작업을 줄이고 환경을 정리하는 방법부터, 사람 사이의 상호작용을 어떻게 단순화할 것인지까지 폭넓게 다루면서도 전체 흐름은 일관되게 유지된다. 결국 이 책이 전달하는 메시지는 하나로 모인다. 복잡함은 피할 수 없는 것이 아니라 선택의 결과이며, 그 선택을 바꾸는 것이 개발자의 실력이라는 점이다.

현업 개발자는 물론이고, 팀을 운영하는 사람이나 앞으로 실무를 경험하게 될 학생들에게도 충분히 의미 있는 책이라고 생각한다. 당장 모든 내용을 그대로 적용하기는 어렵더라도, 어떤 기준으로 판단하고 어떤 방향을 지향해야 하는지에 대한 감각을 잡는 데 큰 도움이 된다. 개인적으로도 앞으로 작업을 할 때 기준점처럼 자주 꺼내보게 될 것 같다. 단순함을 유지하는 것이 얼마나 어려운 일인지 알기에, 그 방향을 잃지 않도록 계속 상기시켜주는 책이었다.

** 한빛미디어 서평단 <나는 리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다.

미니멀 라이프가 유행인 때가 있었다.

물론 지금도 그 유행이 끝난 것은 아니다.

꾸준히 하고 있는 사람들 사이에서는 여전히 유효하다.

그것을 추구한 것은 결국 불필요한 것들을 제거하여 좀 더 풍성한 삶을 누릴 수 있도록 하게 하려 하는 것이었다.

불필요한 수많은 물건으로 인해 나의 동선과 신경이 분산되고 낭비되는 것이 많기 때문이다.

프로그래밍을 하는 것도 마찬가지이다.

이것이 좋다고 생각해서 버리지 못하고, 저것이 좋다고 해서 버리지 못하고 남겨둔 것이 많다.

그것이 남아서 레거시 코드가 되고, 그 레거시 코드를 잊든, 사람이 바뀌든 결국 불필요한 존재가 되어, 이것이 복잡도만 증가시키고 나의 필요와는 상관없이 그 자리에 남아있는 것을 보게 되는 경우가 많다.

그래서 코드 분석에도 시간이 오래 걸리고, 코드 수정에 영향을 주는 부분은 없는지 파악하는 데에도 많은 시간이 걸린다.

이렇듯 프로그래밍의 영역에서 어떤 방법으로 미니멀리즘을 구현해 나갈 것인지 생각해본 부분은 많기 때문에, 이것을 정리해 줄 좋은 계기가 될 것이라고 생각한 책이 나왔다.

책 정보

표지가 신뢰를 준다.

표지가 매우 미니멀리즘 하기 때문이다.

미니멀리즘을 지향하는 내요을 담은 책의 표지가 덕지덕지 홍보문구와 키워드로 가득차 있다면 이율배반적인 느낌이 들었을 것인데, 그렇지 않아서 다행이었다.

- 정가: 16,000원(전자책)

- 분량: 191쪽

- 저자: 데이비드 토머스

- 역자: 이민석

이 책의 챕터가 중요해 보여서 좀 더 언급해 본다.

단순함의 미학, 코드 다이어트, 프로젝트 최적화, 업무 자동화, 변화의 수용, 소프트 스킬, 데이터 주도 개발, 가독성 높은 코드.

이것들이 이 책에서 말하고자 하는 주요 키워드이다.

내용 특성상 실무에서 바로 적용을 해야 가치가 올라가는데, 이런 키워드를 익힘으로써 조금은 업무에도 도움이 되길 바라는 마음이다.

특징

(1) 건강하지 않은 의존성 줄이기

우선 건강하지 않은 의존성을 줄이기를 강조한다.

이는 내가 직접 컨트롤 가능하지 않은 부분에 대한 이야기를 내포하고 있다. 사실 이것은 처음에는 동의하기 어려웠다. 미니멀리즘한 개발을 위해서는 라이브러리를 잘 활용해야 나의 코드에 집중하기 좋지 않을까 하는 생각이다.

하지만, 이것은 그 부분을 뛰어넘어 이야기를 하고 있다. 마치 내 코드의 일부를 외주를 주는 것과 같은 효과를 말하는 부분 때문이다. 내 코드를 남에게 맡겨주는 것과 다름 없는 행동을 한다는 것은 결국 그것에 대한 책임을 져야 하기 때문에, 그 코드의 작동 매커니즘도 이해하고 있어야 문제가 생겨도 내가 핸들링이 가능하기 때문이다.

특히 무분별한 라이브러리 사용은 더 문제가 되는데, 함수 하나를 가져다 쓰기 위해 수많은 용량을 가져와야만 하는 의존성이 얽힌 상황이 문제가 되는 것 때문이다. 내가 막상 사용하는 것은 10KB정도인데, 가져다 놓으면 10MB를 넘게 추가되는 경우가 많기 때문이다. 이렇다는 것은 최소한 1000배는 불필요한 파일이 추가된다는 의미도 포함하는 것이다. 정말 내 의도대로 작동되는 코드를 원한다면 상황에 따라서는 내가 작성한 작은 코드만으로도 의도한 목적을 달성할 수 있는지 확인하는것이 필요하다.

(2) 기술을 공유하면 역량이 배가 된다

내 평소 지론과 일치하는 부분이어서 인상적이었다.

내가 담당하고 있는 전문 기술인 안드로이드 기술은 매 해가 지날 때마다 빠르게 기술이 발전하고 있다. 이것은 개발자 커뮤니티와 서로간에 공유하려는 문화가 만들었다고 생각한다. 기술을 공유하는 사람과 공유받는 사람 모두 윈윈인 상황이라는 것을 말해준다. 개인의 바쁜 삶에 치여서 해야만 하지만 하지 못하고 있는 부분이 있다면 이런 영역이 아닐까.

배우기 위해 가르치세요
 

(3) 자동화 먼저, 코드는 나중에

프로젝트를 처음 빌딩하는 과정에 있어서, 이것 저것 할 것들이 많다. 그래서 대강 빌드 한 번만 되면 바로 작업에 돌입하는 경우도 흔하게 경험한다. 하지만 이 책에서는 자동화를 강조하고 있다. 작업 중간에 불편함을 느끼고 자동화를 해야겠다고 생각할 수 있지만, 그 때에는 이미 작업의 우선순위에 밀리고, 결국 그 불편함을 감수하고 코드작업을 진행하게 된다. 그것이 결국 하나의 기술부채가 된다는 것을 강조한다. 나도 작업하다보면 로깅을 쉽게 할 수 있도록 만들면 좋겠다고 생각은 하지만, 한 번 작업을 시작한 이후에는 전체를 고치기 싫어서 그대로 두어버린다. 이 또한 환경 구성의 일부로 볼 수 있는데, 최대한 자동화를 할 수 있도록 만들어놓는 것이 좋겠다는 생각을 했다.

(4) 의견 다른 상대방과 이야기 하기

앞에서 이야기 했던 것들이 작업 내용과 관련된 미니멀리즘을 향한 일이었다면, 이제는 주제를 좀 돌려서 의견 교환에 대한 이야기를 다룬다. 의견 교환은 좀 더 순화한 말이고, 대부분은 의견 대립으로 말할 수 있다. 의견 대립이 발생하면, 그것을 회피하든, 내 의견을 강하게 피력하는 것이 일반적인데, 이 책에서는 변증법적 사고 훈련에 대해 이야기 하는 부분이 인상적이었다.

다른 사람과 의견이 다를 때 그것을 반박하기는 매우 쉽다. 내 생각이 옳았음을 꺾는 과정이 쉽지 않기 때문이다. 하지만, 그것보다는 상대방의 관점에서 보는 훈련이 필요하다. 상대방의 관점에서 보면 결국 건전한 의견 교환으로 가는 길이 된다.

(5) 코드 미니멀리즘

데이터를 바꾸는 것이 코드를 바꾸는 것보다 훨씬 간편하다는 점을 강조한다.

가끔 보면 별도의 클래스를 정의하기 귀찮아서 primitive type을 이용하는 경우가 많은데, 그럴 경우 이걸 처리하기 위한 코드가 많아진다. 처음에는 그것이 편해서 그대로 활요하게 되는데, 점점 요구사항은 늘어나고, 변경되며 결국은 그것을 만족하기 위한 방법으로 모델을 다시 만드는 경우에 대해서 떠올리게 되었다. 결국 데이터 중심으로 처리하는 것이 훨씬 편하다는 점에 대해 공감하게 되는 영역에 이른다.

개발할 때 로직을 줄일 수 있는 또 다른 방법은, 상태머신 관리 방법이다. 안드로이드 개발을 하다보면 자연스레 여기까지 이르게 되는데, 컴포즈를 다룰 때 정점에 이른다. 화면을 구성할 때 그 화면의 상태를 변경해줌으로써 정확하게 필요한 부분을 일일히 로직으로 구성하지 않고, 정확하게 나눈 파일이나 컴포저블 함수를 호출하는 방향으로 흐르게 된다. 이것의 출발점은 바로 상태머신이다. 그리고 이렇게 작성할 경우 가독성이 올라가는 것은 당연하다. 코드가 명확하게 블럭화되어 나뉘기 때문이다.

관련된 코드를 한 곳으로 모으는 것도 쉽게 간과하는 부분일 수 있으나, 잘 지켜야 코드 추적이 편해진다. 오랫동안 유지보수한 코드일수록 내가 추적해야 하는 코드량이 많을 수 밖에 없는데, 불필요하게 코드가 이리 뛰고 저리 뛰면 논리적 흐름도 자주 끊어져서 잇기가 쉽지 않다. 그래서 머릿속에 그림을 쉽게 그리기 위해서라도 관련된 코드를 잘 모아놓기만 해도 바로 이해할 수 있기 때문에 미니멀리즘한 코드를 구현하게 된다.

(6) 간단함이 복잡성보다 나은 점

사실 이 책에 나온 부분은 실제 프로젝트를 진행하는 입장에 비춰보면 일부라고 느낄 정도로 매우 적은 부분에 해당한다. 실제 현장에서는 이 책의 내용에서 찾을 수 없는 것이 대부분이다. 그렇다면 어떤 것이 간담함이라고 볼 수 있을까에 대한 기준점을 마지막에 제시해준다.

- 이해하기 더 쉽다

- 구성요소의 수가 더 적다

- 문제의 본질을 더 직접적으로 반영한다

이런 것을 회피하고 있다면, C를 그대로 둔 상태일 가능성이 높다. S를 올릴수록 결국 내 프로젝트가 훨씬 유지보수성이 올라가기 때문에 틈날때마다 이 점들을 체크하는 것이 좋다.

이 책을 추천하고 싶은 독자

- 현직 개발자

- 컴퓨터 공학 전공자

- 개발에 관심이 있는 사람 및 관련 조직의 장

총평

방정리를 잘하고 싶은데 방정리를 어떻게 하는 것이 효과적이고 대중적으로 좋은 방법인지 몰라서 한번 쯤은 책이나 영상을 찾아본 경험이 있을 것이다. 이 책도 마찬가지이다. (가만히만 두어도) 한 스프린트가 지날 때마다 내 프로젝트가 점점 복잡도가 올라가는 것을 경험한 적이 있을 것이다. 이제는 한번 쯤 프로젝트를 돌아볼 때 어떻게 어떤 관점에서 봐야 하는지, 좋은 가이드가 된다고 생각한다.

물론 나처럼 적지 않은 실무 경력을 가진 사람이라면 자신만의 방법은 분명 존재할 것이다. 하지만, 내 방법을 좀 더 체계적으로 만들거나, 머릿속에만 존재하고 실재하지 않는 영역이라면 이것을 실체화 시켜주는 역할을 해줄 것이라고 생각한다. 그래서 이 책을 읽고 실천까지 이르기를 바란다. 결국 이것을 수행함으로써 이득보는 것은 이 프로젝트를 수행하고 있는 나 자신이기 때문이다.

대부분 봄이 오면 옷 정리도 할 겸, 집 정리를 한 번씩은 한다. 이처럼 이 책을 읽고난 뒤 프로젝트 정리를 해보는 것은 어떨까.

봄에 집 정리를 하듯. 프로젝트에 쌓인 먼지를 털자고 말해주는 책
 

덜어내는 사고방식을 배울 수 있는 책이다. 단순히 코드를 짧게 쓰는 기술을 말하는 게 아니라, 문제를 바라보고 해결하는 전반적인 과정에서 어떻게 더 효율적으로 일할 수 있는지에 대한 기준을 잡아준다. 무엇을 더 추가할지가 아니라, 무엇을 굳이 하지 않아도 되는지 판단하는 힘을 키워준다는 점이 인상적이다.
 

특히 AI로 대부분의 작업을 쉽게 만들어낼 수 있는 요즘 같은 환경에서는 오히려 과해지기 쉬운데, 이 책은 그런 흐름 속에서 불필요한 요소를 줄이고 본질에 집중하는 감각을 길러준다. 결국 중요한 것만 남기고 나머지를 덜어내는 선택이 얼마나 큰 차이를 만드는지 다시 생각하게 된다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

일을 하다 보면 흔히 '쉽게 하자' 라는 말을 많이 한다. 
'쉽게 하자' 혹은 '단순하게 가자' 라는 말은 대충 일하고 넘어가자는 뜻이 아니라
복잡한 문제를 가능한 한 명쾌하고 군더더기 없이 풀어내자는 이야기이다.

책에서 저자가 말하는 단순함이란 완벽한 규칙이나 기술적 정확성에 얽매이는 대신,
불필요한 것을 덜어내어 본질에 집중하고 변화에 유연하게 대처하려는 '마음가짐' 에 가깝다.
'복합적 복잡성'을 인식하고 제거할 수 있어야 단순함을 실행 할 수 있는데 
이를 위해서 아래의 3단계의 접근 방식을 적용 하라고 말한다.

현황파악 -> 실행 -> 학습

그리고 책의 각 섹션을 이를 위한 '실천법'이라고 말하며 
이 과정을 자주 반복하여 몸에 배도록 연습하여 
무의식적으로 자연스럽게 할 수 있어야 한다고 한다.
모든 것은 단순함을 추구하기 위한 수행의 연속이다.

하지만 말머리에 저자가 말했듯이 단순히 따라하라는 건 아니다. 
따라 하기 쉬운 체계회된 규칙 같은 것도 없다.
모든 것은 자신만의 길을 찾아가는 과정의 하나의 예시일 뿐이다.

여러 실천법들 중 가장 공감하며 봤던 부분은 '챕터5 변화의 수용' 이다.

"우리는 나이가 들어서 놀이를 멈추는 것이 아니다. 놀이를 멈추기 때문에 나이가 드는 것이다."
책에 인용된 조지 보나드 쇼의 이 문장은 깊은 울림을 준다. 
현재 나는 코드를 짜는것과는 멀어진 일을 하고 있긴 하지만, 
AI 같은 새로운 기술의 흐름을 꾸준히 들여다 보며 '탐색'을 게을리 하지 않고 있다.
종종 바쁜 본업 중에 이런저런 낯선 기술들을 기웃거리는 것이
혹시 한눈을 파는 것은 아닐까
스스로 의심할 떄도 있었다. (대표님은 싫어하실거 같다.)

하지만 저자는 단호하게 말한다. "탐색은 정당한 업무다."
기하급수적으로 변하는 IT 세상의 쓰나미 속에서 질식하지 않으려면, 
이 탐색을 여가 시간에 쫓기듯 하는 것이 아니라 
'어른들의 놀이'이자 필수적인 생존 전략으로 삼아야 한다는 것이다.

하루 20분이든 30분이든 시간을 떼어두고 실용성과 기발함을 섞어가며 낯선 기술을 맛보는 것. 
그리고 이 놀이를 죄책감 없이 즐기기 위해서라도, 
우리의 일상적인 업무 프로세스와 시스템 뼈대는 최대한 '단순해야'만 한다.

바야흐로 개발의 대항해 시대이다. 사람대신 AI가 배의 키를 잡고 돛을 조정하여 배를 움직이지만,
결국 가야할 방향을 정해 주는 것은 언제나 한곳만을 가르키는 나침반이다.

복잡한 시스템의 무게에 짓눌려 '쉽게 가자'는 실무의 본질을 잊어버린 이들에게, 
저자는 가장 날카롭고 우아한 무기인 '단순함'을 가지게 하는 방법을 알려 준다.
기술적 기교를 넘어, 변화를 포용하고 일의 주도권을 되찾게 만드는 생존 가이드다.

작가의 이전 작들도 그랬던 것처럼 10년, 20년 후에도 변함없는 가치를 가지는 
그런 책으로 기억될것이다.
한 권쯤 소장해서 책꽂이에 꽂아둘만 하다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

과한 것은 없느니만 못하다: 기능의 최적화

책의 제목 (미니멀리즘)처럼, 제품에 여러 기능들이 추가되면 좋을 것 같은 현상은 결국 미래의 기술 부채가 된다는 사실을 명확히 알려주고 있습니다.

1인 개발자라면 MVP 를 만드는 과정에서 AI 챗봇, OAuth 로그인 등이 그 예가 될 수 있을 것이고, 회사에서도 실제 고객이 사용할 기능에 비해 과다하게 기능을 적용해보자고 논의가 나올 수도 있겠죠.

그러지 않는 것이 가장 좋겠지만, 꼭 이 기능을 만들고자 한다면 적어도 "고객에게 어떤 가치를 주기 위해" 필요한 기능이었다는 사실을 반드시 기억하는 게 맞겠다라는 생각이 들었습니다.

일례로, 회사에서 특정 기능을 리팩터링하려고 했을 때 이 함수를 어떠한 요구사항이 있어 만들게 되었는지 기억하는 데 오래 걸렸던 부분이 있었습니다. 요구사항을 제대로 기억하지 못하니 어떤 부분을 제거해도 괜찮을 지 파악하기 어려웠고, 그에 따른 시간적 비용을 치르게 된 적이 있었습니다.

비단 개발자로서 리팩터링 비용을 최적화하기 위해서 뿐만 아니라, 고객이 겪고 있는 핵심 문제를 풀기 위해서라도 가치 전달 중심의 사고법 (책에서의 "필요 주도 개발")을 훈련해야겠다는 생각이 들었습니다. 100가지 기능이 존재하는 제품을 만들더라도 고객이 겪고 있는 핵심 문제 하나를 풀지 못한다면 고객이 우리의 제품을 사용할 이유가 없을테니까요.

회의를 어떻게 더 유의미하게 이용할 수 있을까: 회의 최적화

회사에서 간혹 회의가 매우 많이 몰려 있는 날에는 정규 시간 (퇴근 시간 전까지)에 회의만 하고, 그 후에야 본연의 업무를 할 수 있었던 적도 있었습니다. 그래서 그런지 팀 내에서도 회의에 대한 의견 공유가 많이 있었고, 여러 합의를 했던 적이 있었습니다.

책을 읽으면서 팀에서 한 합의와 비슷한 실천법이 많이 나와서 신기하기도 하고, 한편으로는 여느 회사/팀이나 모두 비슷한 문제를 겪고 있구나라는 생각도 들었습니다.

대표적으로는 회의의 주제에 따라 반드시 참석해야 할 사람이 아니면 회의에는 참석하지 않되, 반드시 "공유"를 통해 팀의 전체적인 방향성을 맞추는 게 효율성과 회의를 함께 챙길 수 있는 방법이라고 생각합니다.

소프트 스킬을 단련하는 법: 대인 관계의 최적화

저는 만 1년차 주니어 개발자이기도 하고 요즘 회사 차원의 단체 집중 프로젝트를 하면서 불편함을 느꼈을 때 그걸 숨기지 못하고 가끔씩 드러내는 편이었는데, 아무리 "기분이 태도가 되지 말자" 고 스스로 되뇌어도 잘 고쳐지지 않았습니다.

이 책에서는 다른 사람들과 갈등이 있을 때 원만하게 해결할 수 있는 방법과 미리 갈등을 차단할 수 있는 방법에 대해 알려주고 있습니다.

그 중 가장 적용하기 쉬웠던 건 상대방의 입장에서 대화를 할 수 있도록 미리 생각해 두는 것인데, 대표적으로 비개발 직군들과 진행 상황에 대해 짧게 공유할 때 (또는 문제 상황 공유) 기술적인 내용보다는 비유를 통해 쉽게 알려주어야겠다고 연습하는 것 입니다.

회사에 입사한 지 얼마 되지 않았을 때는 그동안 개발자들끼리만 사이드 프로젝트를 했어서 비유의 중요성을 몰랐는데, 실전에서 매우 효과가 좋은 방법을 알게 되어 유익했습니다.

결론

생각보다 너무 좋은 내용에 앉은 자리에서 한번에 바로 끝까지 읽었습니다. 그동안 한빛미디어의 책을 읽으면서 여러 날에 걸쳐 책들을 읽곤 했는데, 이 책은 내용이 그리 길지 않기도 하고 글의 구성도 실전 적용법 형태로 간략하게 여러 개가 묶여있는 구조라 읽기 쉬웠습니다.

끊임없는 회의의 연속으로 업무를 진행하는 데 어려움을 겪고 있거나, 회사 동료를 대하는 데 어려움이 있어 소프트 스킬을 늘리고 싶으신 분들에게 본 책을 추천합니다. 또한, 책을 읽고 나서 두고 두고 시간이 날 때 마다 이 책의 내용을 잘 실천하고 있는 것이 맞는지 꼭 회고해보는 시간을 가지면 좋겠습니다.

(전체 사진이 포함된 원문: https://velog.io/@broccolism/미니멀리즘-프로그래머-소프트-스킬-향상을-위한-액션-아이템-정리해보기-웹-개발자-독서-후기)

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

현실에서 온 책

실제 개발 업무와 맞닿아 있는 생생한 이야기가 담겨있다. 챕터 2. 코드 다이어트 장에 나온 이 내용이 특히나 공감되었다. 대학교 3, 4학년 때 학생 창업팀에서 개발하던 시절이 떠올랐기 때문이다. 당시 이 책에서 말하는 ‘고객’은 바로 디자인팀과 기획팀이었다. 스타트업 특성상 방향성, 기능, 디자인의 변경이 아주 유연한 편이었기 때문이다. 문서로만 봤을 때는 드러나지 않던 여러 사항을 갑자기 깨닫고 원래의 요청과 크게 달라질 수 있는 아이디어와 제안을 갖고 다시 찾아오기 는 일상적인 일이었다. 비슷한 규모나 분위기의 팀에서 일하고 있다면 크게 공감이 될 것 같다. (오히려 그래서 더 재밌었던걸지도..!!)

지금 하고있는 업무에 바로 써먹을만한 것, 어렵겠지만 도전해볼 만한 것도 많이 찾았다. 그만큼 개발자로 일하면서 배울만한 유용한 소프트스킬이 많이 담겨있는 책이다. 몇 가지 액션 아이템을 아래에 적어놓았으니 이제 막 개발자가 되었거나 새로운 업무 스타일을 찾고 있다면 참고해도 좋을 것 같다.

코드 다이어트: 적을수록 좋다

프레임워크도 결국엔 코드다

책을 다 읽고 보니 챕터 2에 북마크를 제일 많이 달았다. 마치 애자일 선언의 일부처럼 심플함을 추구하는 이 책의 성격이 가장 잘 드러나는 챕터였다.

어느 정도로 심플함을 추구하냐면, 프레임워크도 신중하게 사용하라는 내용이 나온다. 프레임워크도 결국에는 코드이며, 특히나 계속 새로운 기능이 붙는 코드이기 때문에 너무 방대해질 수 있다는 것이다. 스프링을 쓰는 입장에서 꽤 공감이 가는 내용이었다. 당장 ‘스프링 프레임워크로 웹 서버 개발하기’ 같은걸 검색해보면 수많은 모듈이 나온다. 스프링 부트, 스프링 데이터, 스프링 세션, 스프링 시큐리티, 스프링 배치, 스프링 클라우드, … 사용하지도 않을 기능을 import 하는걸 막기 위해 잘 골라서 사용해야한다. 스프링이라는 이름이 붙었다고 해서 그냥 갖다 쓰면 곤란하다. 반대로, 저렇게 많은 기능이 필요 없는 작고 간단한 서버라면 다른 방식으로 구현하는 게 오히려 좋다는 게 이 책의 방향성이다. 이미 스프링을 사용하고 있더라도 프레임워크의 도움이 필요한 건지, 직접 코드를 적는 게 유지보수에 유리할지 판단하는 과정이 필요하다는 걸 느꼈다.

내 코드는 정말 '사용'되고 있었을까

결국에는 제품을 만들어야 한다. 우리는 코드를 짜는게 목적이 아니라 동작하는 소프트웨어를 만드는 게 목적이다. 챕터 2.3 기능은 적을수록 좋다 에서는 이런 구절도 나온다. 복잡함을 걷어내고 빨리 출시하는 게 목표라면 이렇게 하는 게 합당하다.

그런데, 단순함만이 답은 아니다

하지만 그저 빨리 출시하는 게 목표가 아니라면? 너무 심플함만 추구하다가는 예기치 못한 사고를 당할 수도 있다. 충분한 예외 처리가 되어있지 않아 데이터 정합성이 깨지거나, 갑자기 튀어 오르는 트래픽 앞에서 서버가 무너진다거나, … 상상력을 발휘하여 매일 사용되지 않는 코드를 작성해야 할 때도 있다.

이 책에 나오는 내용은 아직 MVP 제작 전이거나, 소규모 테스트를 먼저 돌려보는 팀에 적용하면 좋은 내용이었다. 일간 방문자 수가 100만이 넘거나, 피크 타임에 평상시의 3배가 넘는 트래픽을 받아야 하는 서버라면 이야기가 좀 달라진다.

회의 다이어트: 의사소통도 심플하게

회의가 많은 편이라면 아래 내용을 읽어보자. 너무나도 현실적인 상황에 절로 웃음이 나올 것이다.

책에서는 회의는 원래 애자일하지 않습니다 라고 한다. 생각해 보면 그렇다. 비동기적인 소통을 통해 해결할 수 있는 일이 있고, 아닌 일이 있다. 만약 깃헙 코멘트나 슬랙 메세지, 이메일 등 글을 통해 해결하는 게 더 효율적인 일이라면 굳이 회의를 잡을 필요가 없다.

반대로 회의를 잡았다면 예정 시간을 최대한 준수할 수 있도록 미리 안건을 준비해가고, 이 내용을 공유하여 모두가 같은 눈높이에서 출발할 수 있는 장치를 만들자. 미리 회의 안건을 적어놓는 스레드를 만들면 유용할 것이다. 우리 팀에서도 매주 화요일 회의 전까지 각자 이야기하고 싶은 내용을 달아놓고, 회의 시간 때 하나씩 함께 논의하는 시간을 갖는다. 예전에 제안한 방식인데 회의가 늦어지는 경우가 훨씬 줄어들었다. 안건을 미리 볼 수 있으니 가볍게 해결할 수 있는 일은 코멘트나 메신저로 해결하고, 회의 전에 필요한 히스토리를 파악하고 공유하여 회의 시간을 줄일 수 있었다.

직접 해볼만한 일들

이제 책에 나온 내용을 바탕으로 액션 아이템을 하나씩 정리해 보자.

나도 이미 하고 있는 일

TODO 강조 표시하기

책에 나온 내용 중, 작년부터 필요성을 느끼고 설정해 놓았던 게 있다. 바로 코드 에디터에서 TODO 라고 적힌 게 있으면 강조해 주는 기능이다. (IntelliJ를 쓰고 있다면 Settings > Editor > TODO 메뉴에 원하는 키워드를 추가해서 자동 하이라이팅을 설정할 수 있고, VSCode 사용 중이라면 별도 익스텐션을 설치해서 설정할 수 있다.)

나는 메인 브랜치에 달린 TODO와 이번 브랜치에서 당장 해결해야 할 작업을 구분하기 위해 @@ TODO: 라는 커스텀 패턴을 등록해서 쓰고 있다. 이렇게 하면 당장 해야 할 일과 언젠가 해도 되는 일이 한눈에 구분되고, PR 올리기 전에 전체 검색으로 내 작업을 모두 완료했는지 확인하는 데에도 편하다.

당장 실천해볼 일: 시간에 이름표를 붙이자

탐색 시간을 확보하라는 내용이 크게 와닿았다. 늘 내가 해야 할 일만 쳐내다보면 새로운 정보를 접할 기회가 현저히 줄어든다. 본업은 결국 개발이기에 최신 뉴스만 계속 찾아다닐수는 없는 노릇이다. 하지만 이런 생각 때문에 최신 기술 탐색뿐만 아니라 내가 몰랐던 부분에 대한 탐색은 뒷순위로 밀리는 경우가 많고, 내 개인 스케줄 관리 어플에는 항상 백로그라 쌓여있었다.

마침 3월 말이다. 다음 달부터는 정기적으로 탐색을 위한 시간을 따로 확보해 놓아야겠다. 특히 올해부터 매주 금~일 중 하루 30분 주간 업무 보고 작성, 매달 마지막 워킹데이에는 그달 업무 회고하기, 매달 마지막 주 토요일은 월간 가계부 결산 과 같은 규칙을 만들어서 실천하고 있었다. 이런 식으로 시간에 이름표를 붙여서 관리하면 보다 알차게 시간을 보낼 수 있고 할 일도 놓치지 않을 수 있다. 그 할 일 중에 탐색의 시간도 추가해 볼 예정이다.

해보고 싶지만 쉽지 않을 일: 개발자 셔플

다양한 도메인을 경험할 수 있고, 새로운 시각이 들어오면서 코드가 한 단계 진화할 수 있다는 장점이 매력적이다. 다만 팀 회식 때 옆 팀 사례를 들어보니 인수인계나 운영 안정성 면에서 꽤 많은 준비가 필요한 일 같았다. 언젠가 팀 내의 좀 더 복잡한 도메인도 한번 맡아보고 싶지만 아직까진 때가 아닌 것 같다. 대신 그쪽 도메인에서 올라오는 PR과 이슈를 구경하면서 파악하는 시간을 가져야겠다.

생각해볼 일

이것도 역시 앞에서 나왔던 ‘시간에 이름표 붙이기’와 비슷한 맥락으로, 의식적으로 생각이 필요한 일이다. 매일 하던 업무만 하기보다는 앞으로 어떤 방향으로 나아가야할 지 항상 고민하다보면 언젠가 좋은 기회가 찾아오지않을까 싶다.

결국에는 사람이 하는 일이다

일을 하면 할수록 들었던 생각이 마침 이 책에서도 등장했다. 결국 우리는 모두 공동의 목표를 갖고 프로그램을 만들기 위해 모인 팀이다. 팀 내에서 의견 차이가 있을 때 우리가 해야 하는건 스스로 옳다는걸 증명하거나 상대방의 잘못을 집어내는게 아니라, 의견 차이를 좁히고 일이 되게 하기 위해서 무엇을 어떻게 할지를 결정하는 일이다. 애자일 선언문의 4가지 핵심 가치 중 하나가 떠오르는 구절이다: 프로세스와 도구보다는 사람과의 상호작용.

챕터 6.17 공감 능력 기르기에서는 공감은 미리 받는 피드백입니다라는 소제목도 나온다. 미리 합의한 방식대로 코드를 짜서 PR을 올리는게 그렇지 않았을 때보다 훨씬 더 빠르게 리뷰되고 머지되었다. 혹은, 코드를 직접 보면서 논의하기 위해 미리 PR을 만드는 방식도 괜찮았다. 결론은 우리 모두가 이 코드에 대한 합의가 이루어지면 된다는 것이다.

조금 갸우뚱했던 표현: 포트폴리오 없는 개발자

책을 읽다보면 챕터 3에서 생소한 용어가 등장한다.

각주에도 딱히 설명이 없고 구글링해봐도 결과가 나오지 않아서 클로드에게 물어봤다. 원문인 Developer Without Portfolio 는 특정 담당 영역 없는 개발자 정도로 생각하면 될 것 같다.

기억에 남(기고 싶)은 내용

• 프레임워크도 결국 기능이자 코드다. 기능과 코드는 적을수록 좋다.
• 자동화의 장점: 기억해야 할 것을 줄여주고, 필수 스텝을 빼먹지 않게 도와준다.
• 우선순위에 밀리는 일을 하기 위해 시간에 이름표를 붙여주자.
• 경력 개발에 도움이 되는 기술 분야, 개인적으로 흥미롭게 보이는 분야는 무엇일까? 탐색해보자.
• 공감은 미리 받는 피드백이다.

추천 대상

• 빠르게 MVP를 제작할 일이 많은 1인 개발자
• 스타트업에 근무하면서 업무 팁을 얻고 싶은 개발자
• 직장 생활 전반적인 소프트스킬을 향상시키고 싶은 개발자

✅ 액션 아이템 정리

지금까지 나온 액션 아이템을 정리해보았다. 각자 하고 있는 일은 무엇인지, 당장 실천해 볼 일과 언젠가 해볼만한 일은 무엇인지 분류 해보자. 그리고 책에 훨씬 많은 액션 아이템이 담겨있으니 소프트스킬 지침서가 필요하다면 꼭 읽어보자!

이미 하고 있는 일

• 에디터에서 TODO 키워드 강조 설정
  • PR 올리기 전 @@ TODO: 전체 검색으로 작업 완료 확인
• 시간에 이름표 붙이기
  • 매주 금~일 중 하루 30분 주간 업무 보고 작성
  • 매달 마지막 워킹데이 월간 회고
  • 매달 마지막 주 토요일 월간 가계부 결산
• 회의 전 안건 스레드 미리 작성
  • 회의를 잡기 전에 글(코멘트, 메신저, 이메일)로 해결 가능한 일인지 먼저 판단하기
• PR을 올리기 전에 리뷰어와 방향을 미리 합의하기

당장 실천해 볼 일

• 탐색을 위한 시간 확보하기
  • 언제 할 지, 이름표를 붙여주기
  • 경력 개발에 도움이 되는 기술 분야 탐색해 보기
  • 업무 맥락을 벗어나 개인적으로 흥미로운 기술 분야 찾아보기
• 새 의존성이나 프레임워크 모듈을 추가할 때, 정말 필요한지 한 번 더 따져보기
• 반복적으로 수동으로 하고 있는 작업이 있다면 자동화 검토하기

해보고 싶지만 당장은 아닌 일

• 팀 내 다른 도메인 맡아보기 (개발자 셔플) → 관심을 갖고 지켜보기.

#한빛미디어 #나는리뷰어다 #미니멀리즘프로그래머

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

요즘 개발은 “더 잘 만들기”와 “지금 필요한 것만 만들기” 사이에서 계속 줄타기한다. 기능이 늘어나면 코드는 자연스럽게 비대해진다. 이 책은 새로운 걸 알려주기보다 이미 알고 있지만 미뤄두고 있던 기준을 다시 꺼내게 만든다.

* 필요 없는 추상화

* 과한 의존성

* 반복되는 작업

돌아보면 대부분 몰라서가 아니라 그냥 두고 있었던 것들이다. 나도 예전에 확장성 고려해서 구조를 크게 잡았다가

오히려 이해하기 더 어려운 코드 만든 적이 있다. 결국 좋은 코드는 “많이 고민한 코드”가 아니라 “덜 고민해도 이해되는 코드”라는 것을 깨달았다.

AI가 코드를 빠르게 만들어주는 시대일수록 더 중요한 건 구현 능력이 아니라 무엇을 덜어낼지 판단하는 감각이 필요하다는 것을 몸소 다시 상기 시키게 되었다. 결국, 단순함은 결과가 아니라 나의 선택이다.

#미니멀리즘프로그래머 #한빛리뷰어 #나는리뷰어다

이 책의 마지막 장에서 S와 C가 등장한다.

​

S는 C보다 이해하기 쉽다.

S는 C보다 구성 요소의 수가 적다.

S는 C보다 문제의 본질을 더 직접적으로 반영한다.

​

S는 단순함(Simplicity), C는 복잡함(Complexity)이다.

​

많은 개발자가 프로그래밍이라고 하면 복잡함에 먼저 익숙해진다. 개발환경 하나를 구성하는 데만 버전 호환성, 의존 라이브러리 등 셀 수 없는 문제가 쏟아지고, 간단한 프로젝트에도 무거운 프레임워크를 도입하거나, 새로운 도구가 나올 때마다 일단 써보는 경험은 누구에게나 있을 것이다. 이 책이 말하는 "단순함"과는 거리가 먼 풍경이다.

​

AI가 수백 줄의 코드를 순식간에 생성하고 프레임워크가 점점 거대해지는 시대에 "정말 이렇게까지 복잡해야 할까?"라는 질문을 정면으로 던진다. 저자는 소프트웨어의 '복합적인(complex)' 측면과 우리가 인위적으로 '복잡하게(complicated)' 꼬아버린 것을 구분한다. 전자는 피할 수 없지만, 후자는 우리가 잠시 멈춰 서서 "이게 정말 맞나?"라고 묻는 내면의 목소리를 외면하는 순간 싹튼다.

​

인상 깊은 포인트

잼 실험의 교훈. 24가지 잼보다 6가지 잼을 진열했을 때 구매율이 높았다. 옵션이 많을수록 인지적 부담이 커진다. 프레임워크가 수십 개의 옵션을 제공한다고 해서 좋은 설계인 것은 아니다.

유발 수요. 기가헤르츠와 기가바이트가 늘어날수록 코드도 그만큼 비대해진다. "마음껏 써라"는 말은 함정이다.

단순함의 측정 기준. 9장에서 제시하는 S 대 C 비교 프레임워크는 실무에서 바로 적용할 수 있는 체크리스트다.

​

프로젝트가 점점 복잡해져서 손을 못 대겠다고 느끼는 개발자, 의존성 지옥에 빠져본 경험이 있는 개발자, 회의가 너무 많다고 느끼는 팀 리더, AI 시대에 "더 많이, 더 빠르게"가 아닌 "더 적게, 더 단순하게"의 가치를 고민하는 개발자에게 권한다.

​

192페이지라는 얇은 분량 자체가 이 책의 철학을 증명한다. "더 작고 단순하게 만드는 것은 그냥 만드는 것보다 훨씬 어렵다." 데이비드 토머스는 코딩 기법에만 머무르지 않고, 자동화, 협업, 소프트 스킬, 자기계발까지 개발자 활동 전반을 '단순함'이라는 렌즈로 관통한다. 정답을 제시하기보다 "이게 정말 맞나?"라고 스스로 질문하는 습관을 심어주는 책이다.

​

"한빛미디어의 나는 리뷰어다 활동을 위하여 책만을 제공 받았습니다."

이번에 리뷰할 책은 미니멀리즘 프로그래머입니다 (원서 Simplicity: Sustainable, Humane, and Effective Software Development by Dave Thomas)

ChatGPT 가 처음 나오고, 3일정도 지나서 당시 같이 박사과정을 하던 친구들과 같이 사용해보고 충격을 받았던 기억이 아직도 생생합니다. LLM 및 생성형 AI는 문서, 코드, 글을 넘어서 영상이나 음악에도 창작 (혹은 생성) 이라는 행위는 점점 더 가속화되고 있습니다. 적어도 글에서의 소비는 LLM의 도움으로 쉬워진점을 감안하면, 어떤 글 기반의 컨텐츠의 생산/소비는 그 사이클이 가속화되고 그 안에서 피로감 역시 무시할수 없다는 생각이 드는 요즘입니다.

그런면에서 이 책은, 요즘의 이런 끊임없이 생성하고 더하고 더하는 행위가 가속화 되는 시대에, 덜어냄의 미학을 개발자의 입장에서 정리한, 어떻게 보면 개발 교양서 (?) 라고 볼 수 있습니다. 현재, 우리는 그 어느 때보다 빠르게 결과물을 만들어내고 있습니다. 하지만 역설적으로 내가 짠 코드를 완벽히 장악하고 있다는 감각은 점점 흐릿해지고 있습니다. 미니멀리즘 프로그래머는 저자의 개인적인 취향과 선호가 강하게 투영된 책이지만, 코드를 직접 설계하며 한땀 한땀 쌓아 올리던 시대의 감각과 현대의 폭발적인 효율성 사이에서 우리가 놓치고 있는 본질이 무엇인지 되묻게 합니다. 단순히 코드를 적게 쓰는 기술이 아니라, 복잡성이라는 파도 속에서 개발자가 중심을 잡는 태도에 관한 기록입니다.

코드 다이어트와 AI가 남긴 과제

저자는 건강하지 않은 의존성을 줄이고 프레임워크의 성분표를 꼼꼼히 확인하며 기능을 최소화하라고 조언합니다. 이는 기술적 결벽주의가 아니라 생존 전략에 가깝습니다. 최근 생성형 AI를 통해 만들어진 코드들은 당장 구동에는 문제가 없으나, 정작 그것을 승인한 사람조차 내부 로직을 온전히 이해하지 못하는 경우가 비일비재합니다. 이러한 상태로 쌓여가는 코드는 보이지 않는 기술 부채가 되어 시스템의 유연성을 갉아먹습니다. 오버엔지니어링을 경계하고 최대한 린하게 코드를 유지하려는 노력은, AI가 코드를 대신 짜주는 시대에 오히려 인간 개발자가 가져야 할 가장 차별화된 경쟁력이 됩니다. 내가 이해하지 못하는 코드는 결국 내가 통제할 수 없는 부채일 뿐이기 때문입니다.

과거, 같이 일을하던 동료가 제 github PR을 보고, 무의미한 diff를 만든다고 쓴소리를 한 적이 있습니다. white space trailing을 제대로 하지 않아 생긴 수많은 diff들은, 다른 동료들이 코드를 리뷰할때 로직이 어떻게 변했는지에 집중하는 것을 방해하고, 코드의 구현이 이상적인 구현으로 잘 되었는지 파악하는데 피로감을 더하고 있었습니다. 그 이후로 항상 코드에 변화는 불필요함과 장황함을 걷어내고, 매우 명료하고 간결하게 유지하려 노력하고 있는데, 최근에 시니어로 일을 하면서, AI도움받은 무분별하고 무의미한 코드 변화나, 기존의 코드 활용대신 누더기처럼 덕지덕지 더해가며 구현된 코드들이 PR로 날라오면.. 정말 스트레스를 받습니다. 그런 측면에서, 주니어들이나 인턴들에게도 추천할만한 조언들이 정말 많은 책입니다.

가독성 높은 코드와 데이터 주도 개발에 대한 책에서의 논의는 AI 에이전트가 개발의 주도권을 가져오려는 현시점에 시사하는 바가 큽니다. 주석을 최소화하고 구조적 정렬을 강조하는 저자의 원칙은 코드를 단순화하여 직관적인 이해를 돕기 위함입니다. 앞서 말했듯, 생성된 코드의 내부를 모른 채 구동만 시키는 행위는 당장의 속도를 대가로 계속 기술부채를 쌓아가는 행위입니다. 설령 미래의 어느 지점에서 AI 에이전트가 이 부채를 대신 청산해 줄 수 있게 되더라도, 아직 그 단계에 도달하지 못한 현재의 우리에게는 이러한 노력은 여전히 유효하다고 생각합니다..



업무 자동화, 사용하는 도구의 완전한 이해, 그리고 사람들과의 협업

이 책의 2부에서 다루는 업무 자동화 파트는 저자의 개인적인 덕질에 가까운 선호가 가장 짙게 묻어나는 구간입니다. 데스크톱 환경부터 터미널, 에디터 설정까지 세세하게 파고드는 모습은 효율성이라는 명분 아래 숨겨진 저자만의 유희처럼 보이기도 합니다. 하지만 이를 단순히 툴 세팅에 대한 집착으로 치부할 수는 없습니다. 핵심은 변화를 수용할 수 있는 유연한 환경을 스스로 구축하는 기초 체력에 있습니다. 도구에 끌려다니지 않고 자신만의 작업 환경을 완전히 장악하려는 시도는, 기술의 유행이 빠르게 변하는 환경에서 개발자가 스스로의 생산성을 보호하는 가장 적극적인 행위라고 볼 수 있습니다.

그리고, 저도 개인적으로 제 개인 리눅스 터미널 세팅 + Neovim & 플러그인들을 활용해서 C++, Python, C# 기반 프로젝트들을 Local/Cloud 환경에서 개발하고 있는데, 의외로 이것이 또 프로젝트 구조 및 의존성 이해에 도움이 됩니다 -- 예를들어, 의존성 라이브러리에 린팅이 제대로 동작하지 않을때 컴파일 플래그 설정이 잘 되어있는지, 그리고 시스템 전체/각 유저별로 설치된 의존성에 충돌 해결이나 적절한 설정은, 단순히 간단한 프로그램을 넘어, 프로덕션 레벨의 프로젝트를 세팅하고 이해하는데에 기초 체력이 되어주는 부분이라. 개발인생에 한번쯤은 이것 관련으로 삽질을 해보시는것을 추천드립니다.

* 리눅스/맥 환경에서 Terminal 사용하시면 Byobu (터미널 창 분할 및 세션유지) 와 Neovim 조합으로 한번 개발환경을 구성해보시는것 추천드립니다. 사진은 제 개발환경입니다.

2부에서는 저자는 결국 개발은 혼자 하는 일이 아니기때문에, 소프트 스킬에서의 중요성도 같이 강조합니다. 최근에 회사 프로젝트들에서 다른 부서 및 동료들과 계속 엮여가는 상황이 빈번한 저에게도 꽤 도움이 되었던 부분입니다. 저자가 이야기하는 협업에서의 소프트 스킬들에 대한 핵심은, 결국 개발자 스스로가 미니멀한 철학을 기반으로 자신의 작업 환경 및 일에서의 결과물들을 매우 깔끔하게 잘 정돈하는 것이 기본으로 요구된다는 것입니다. 빨라진 변화 사이클, 그리고 새롭게 나오는 가십들에 휘둘려서 정돈이 안된상태로 계속 뭔가 하는데 남는것이 없는, 그런 정돈이 안된 상태를 최대한 억제하고, 미니멀함이 가져다준 이점으로 잘 정돈된 상태로 일의 본질을 꿰뚫어 보면, 타인과의 의사소통에서도 프로젝트 진행에서 엇나감이 줄어들지 않을까 생각이 듭니다. 저자가 책에서 쭉 가져오는 흐름으로 미루어 보았을때, 가끔 방황하게 되거나 엇나가게 될수도 있지만, 결국 개발자의 일에 본질, 개발에서의 단단힘이 유지되는한 결국 가야할 길로 돌아오게 된다는 메세지를 전한다고 생각합니다.

마치며 - 이해할 수 있는 범위를 지키는 태도

미니멀리즘 프로그래머는 화려한 기술적 성취보다 명확한 단순함을 기반으로한 단단함을 우선시하라고 조언합니다. AI가 쏟아내는 정보량에 압도되기 쉬운 환경일수록 저자가 던지는 메시지는 명확해집니다. 개발 속도를 무작정 높이는 것보다 중요한 것은 우리가 무엇을 통제하고 있는지 정확히 아는 것입니다. 기술 부채가 도처에 널린 개발 생태계에서 스스로를 지키는 방법은 결국 덜어내는 일이며, 그 덜어냄 끝에 남은 핵심/본질을 꾸준히 지켜나가는 태도입니다. 생각보다 개발에 대해 깊게 다루는 내용이 없이 자기계발서/교양서 처럼 편하게 읽을 수 있는 책이라, 최근에 FOMO를 가지고 뭔가 바쁘게바쁘게, 빠르게빠르게 뭔가 계속 해나가는데 남는게 없다고 느껴지시거나, 점점 늘어가는 복잡도에 피로감을 느끼신 분들이라면, 주말에 한번 카페가서 쭉 읽어보시면서 본인의 방향을 생각해보시는데에 도움이 될 것 같습니다.

--

*한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.



한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

무작정 기능을 추가하다가 꼬여버린 코드 때문에 고민이 많았는데, 이 책을 통해 '단순함'의 진짜 의미를 배웠습니다. 무언가를 더하는 것보다 '안 해도 되는 걸 걷어내는 선택'이 더 중요하다는 걸 깨닫게 해주네요.

<실용주의 프로그래머> 저자의 통찰은 시대가 변해도 여전합니다. 코드가 점점 무거워지는 게 느껴지거나, AI 시대에 개발자로서 어떤 태도를 가져야 할지 힌트를 얻고 싶다면 강력 추천합니다! 

이 책의 정말 좋은 부분은 소스코드를 단순화하는 기술적인 면만 이야기 하는게 아니라 원활한 소통과 마인드셋이 단순화를 궁극적으로 이룰 수 있다고 말한다. 사실 소스코드 단순화는 능력/기술의 부분이다. 즉, 한마디로 '공부할 마음만 있다면 충분히 얻을 수 있는 능력'이다. 하지만 환경, 소통의 개념은 더 이상 공부가 아니다. 사람의 개인적인 성격과 마인드가 전체적인 일의 효율에 영향을 미칠 수 있다는 점을 문제로 제시한 점이 이 책의 가장 좋은 부분이 아닐까 싶다. 꼭 개발자가 아니더라도 회사에서 협업하는 사람이라면 한번 쯤은 이 책을 읽어보면 정말 좋을 것 같다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다."

미니멀리즘 프로그래머

"이 책에 정답은 없습니다. 사람마다 상황이 다르니까요. 대신 저는 단순함이 간절히 필요했던 여러 상황을 설명하고, 그 상황을 단순하게 만들기 위해 제가 어떤 조치를 취했는지 이야기하겠습니다."

매번 느끼지만, 누군가의 이런 실무적인 경험을 듣는 것은 어렵습니다.

작가는 복잡성에도 과학적 방법론을 적용하고자 합니다.

현황파악, 실행, 학습

작가는 모든 섹션을 Practice(실천법)이라고 합니다. 몸에 배도록 반드시 연습해야하기 때문입니다.

이 실천방법에는 현황파악(복합적 복잡성 인지하기), 실행(시도하기), 학습(행동 조정하기)을 자주 반복하여 자연스럽게 할 수 있데 되도록 하고자 합니다.

PRACTICE 1. 코드 다이어트하기

세상이 너무 발전해서 메모리가 커지고, 클럭도 커졌습니다. 마찬가지로 코드도 점점 비대해지고 있습니다.

그 결과 코드를 이해하기도, 유지보수하기도, 배포도 어려워집니다.

이번에 해커톤에 참여하면서 AI 를 활용했었는데,

코드가 너무 빨리 작성되다보니 이제 코드를 읽고 이해하는 것 자체가 어려워졌습니다.

그러니 이제는 코드를 줄여가야합니다.

아래는 작가가 표현한 의존성 그래프입니다.

npx create-react-app my-app 명령어로 기본 리액트 앱을 만들면 874개의 모듈이 다운로드합니다.

(단순히 기본 설정만 이정도 인데, 코드를 작성하면 더 많은 의존성이 생깁니다.)

의존성이라는 것은 미래의 통제권을 남에게 넘겨주는 것이라고 볼 수도 있습니다..

그래서 수 많은 의존성에서 한명이라도 나쁜 맘을 가지면 나의 앱이 무너질 수 있습니다. + 보안상의 문제도 있습니다.

의존성 결정 체인

PRACTICE. 프레임워크: 성분표 꼼꼼히 확인하기

요즘에는 대부분의 프로젝트가 프레임워크 위에서 돌아갑니다.

프레임워크를 사용하면 편리합니다. 

대신에 안전성이 입증된 프레임워크를 선택하고, 필요한 기능을 갖추되 가장 가벼운 것이 좋습니다.

이해할만큼 작다면 유지보수하기도, 새로운 개발자가 투입되기도, 다루기 쉬워집니다.

저는 예전에 딥러닝을 배울 때, Tensorflow 를 썻었는데 버전업이 되면서 많은 코드를 수정해야했습니다.

플러터가 활발히 개발중일 때도 진입했었는데, 이후에 많은 부분이 바뀌었습니다.  

그 이후부터는 새로 급부상하는 프레임워크는 안정화되기를 기다리게 되었습니다.

최근에는 AI 관련된 라이브러리들도 많이 나오는데,

다음날 되면 또 새로운 라이브러리의 인기가 급부상합니다.

트렌드를 타는 라이브러리나 프레임워크는 자제하는게 좋습니다.

PRACTICE3. 기능은 적을수록 좋다.

회사에서도 기능을 있으면 좋을거 같다고 많이 추가합니다. 이런걸 골드 플레이팅이라고 하죠.

하지만 단순히 좋다고 생각해서 소프트웨어에 기능을 추가하면 미래의 부채로 돌아옵니다.

책에서는 소프트웨어 개발을 할 때 필요할지도 모르는 기능을 모두 요구사항에 집어넣고 계획서를 작성하는 방식을 활용하는 것을 많이 본다고 합니다. 나중에 필요 기능을 추가할 예산을 못받을수도 있으니까요.

하지만 작가는 더 애자일하게 접근하는 방식을 제안합니다.

"무엇이 필요한지 묻는 대신 "이 프로젝트에서 어떤 가치를 기대하세요? 그리고 그 가치들의 우선순위는 어떻게 되나요?"

필요 주도 개발

그 우선순위를 통해 단계적 소프트웨어 개발을 제안합니다.

예전에 사수분한테도 비슷하게 들었는데,

고객에게 이렇게 선택지를 제안하면, 이를 받아들이는 고객도 이 상황을 인지하고 결정할 수 있어서 나중의 충돌을 피할 수 있다고 했었습니다.

PRACTICE 4 팀의 결합도 낮추기

코드를 단순화하는 방법을 프로젝트에, 팀에 적용하면 좋은 효과를 얻을 수 있지 않을까? 라는 생각에서 시작됩니다.

시간적 결합(커플링)을 줄여야합니다.

예를 들어, 다른 사람이 검토를 해야지만 다음 단계로 넘어간다던가.

어떤 것을 고쳐야하는데 관련 코드의 담당자가 휴가중이라던가.

담당자가 회의에 참석하여 대화를 할 수 없다던가.

그리고 이벤트 주도 시스템 같은 방식을 줄여야합니다.

먼가 문제가 터지면 일을 중단하고 문제를 처리합니다.

그리고 다른 사람들을 끌어들이게 되고, 집중이 꺠지는 균열이 퍼져나가게 됩니다.

이런 것을 해결하기 위해서 특별한 방법이 있는게 아니다.

왜냐하면 코드 리뷰의 피드백이 어떤 형태인지 등 상황에 따라 다르게 적용해야하는 부분들이 있기 떄문이다.

그러니 아래의 사진에 나온것처럼 자신의 상황을 검토하고 방법을 찾아보는 것을 추천한다.

결합도 낮춰보기

PRACTICE 6. 굳이 회의를 해야 한다면 생산적으로 하자

생산적으로 회의하기

가장 기본적인 부분들을 제안한다.

하지만 기본을 제일 지키기 어렵다. 기본적인 사항들만 잘 지켜도 단순함이 올라간다.

- 명확한 목표 설정 : "이 회의를 왜 하는가?" 

- 회의가 필요한지 확인하기 : 일보다 회의가 쉽기 떄문에 자주 열린다.

- 준비 : 참석자에게 자료를 전달하고, 설명이 아닌 논의를 할 수 있도록 만듭니다.

- 참석자 선택 : 결과를 도출하는데 실질적으로 필요한 사람을 선정합니다.

- 회의 일정 : 회의에 적절한 시간대는 없다. 일을 중단시키지 않는 구간에 일정을 잡는다. 아예 회의를 안하는게 제일 좋다.

- 진행 방식 : 회의의 측정가능한 결과를 이해해야합니다. 모든 살마이 의견을 낼 수 있어야합니다. 속도를 조절하여 시간안에 끝내야합니다. 종료 이후의 여유시간을 확보해놓아야합니다.

- 정리 및 후속 조치: 합의 내용을 정리하여 모두에게 보내야합니다.

PRACTICE 7. 보유한 기술 널리 퍼뜨리기

가르치다보면 새로운 인사이트를 많이 얻습니다.

지식의 저주라고 아시나요?

내가 아는 것을 남도 당연히 알 것이라고 착가하는 상태입니다.

이는 나 스스로도 왜 그런지(원리)를 잊어버리는 상태에 빠지게 만듭니다.

그래서 다양한 사람과 의견을 나누는 것이 중요합니다.

책에서는 다양한 분야의 역량을 가진 사람으로 팀을 구성하라고 하지만,

동일한 분야이더라도 충분히 얻는것이 많은 것 같습니다.

PRACTICE 8. 정보를 자유롭게 흐르게 하기

구성원은 정보에 자유롭게 접근할 수 있어야하고, 질문하기 쉬워야합니다.

정보가 너무 자연스럽게 존재해서 인지하지도 못하고 흡수하는 환경을 조성해야합니다.

무엇을 하든 정보의 흐름을 보장하려면 의사소통을 적극적으로 관리해야합니다.

사적으로 축적한 지식은 썩습니다. 예를 들면, 팀 내부에서만 쓰는 용어 같은게 있습니다.

공유된 지식은 누군가의 아이디어를 확장시킵니다.

지식 공유를 중요하게 여기는 팀은 모든 구성원이 누구나 남을 가르칠 수 있고 배울 것도 있다는 사실을 분명히 합니다.

질문을 제기하고 이슈를 논의하도록 권장합니다.

이러한 문화를 위한 방식으로 추천하는 방식입니다.

정보를 공유하도록 개선하는 방법

하지만 이런 방식들은 경영진의 확실한 동의와 지원이 필요합니다.

이런 활동들은 단기 성과를 내야하는 관리자의 인센티브에 역행하기 때문입니다.

이 외에도 다양한 PRACTICE 들이 많이 나옵니다.

코드 작성시에도 적용하면 좋을 만한 내용들이 많이 나옵니다.

(저는 이미 거의 아는 부분이라 패스했지만요.)

마지막에 가장 중요한 질문이 나옵니다..

"어떤 방식이 다른 방식보다 더 단순하다는 걸 어떻게 판단할 수있을까?"

단순하다고 말할 수 있을려면

위 이미지를 첨부하며 이 책의 리뷰를 마치겠습니다.

책이 두껍지도 않고 약간의 시간을 내면 금방 읽을 수 있습니다.

짧은 책이지만 좋은 내용들이 많이 포함되어 있습니다. 읽어보시길 추천드립니다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

필요한 선수 지식
요구 학력 : 주니어 → 미드레벨로 올라가는 개발자
예제 코드 : JavaScript
난이도 : ★★☆☆☆

책의 구성 중 마음에 들었던 주제
PART 02 환경을 단순화하라
Chapter 04 업무 자동화
이 장에서는 개발자의 생산성을 높이기 위해 반복되는 작업을 자동화하고 터미널, 에디터, 개발환경을 효율적으로 사용하는 방법을 설명한다. 특히 두 번 이상 반복하는 작업은 스크립트로 만들고, 개발 환경 역시 재현 가능하도록 관리해야 한다는 점이 핵심 내용이었다.

이를 통해 실제 개발 시간보다 준비 작업에 더 많은 시간이 소모되고 있었다는 점을 돌아보게 되었다. 앞으로는 기능 구현뿐 아니라 반복 작업을 줄이고 개발 환경 자체를 단순화하는 것도 중요한 개발 역량이라고 느꼈다.

PART 04 코드를 단순화하라
Chapter 08 가독성 높은 코드
이 장에서는 코드를 단순화하는 핵심 방법으로, 다른 사람이 빠르게 이해할 수 있는 가독성 높은 코드 작성 원칙을 설명한다. 변수명, 함수명, 코드 배치, 조건문과 로직의 표현 방식을 명확하게 만들어 읽는 사람이 의도를 바로 파악할 수 있어야 한다는 점이 객관적인 핵심 내용이었다.

이를 통해 좋은 코드는 단순히 동작하는 코드가 아니라, 수정과 검토 과정에서 이해 비용이 낮은 코드라는 점을 다시 생각하게 되었다. 앞으로는 기능 구현 자체보다도 읽는 사람이 쉽게 이해할 수 있는 구조와 표현으로 작성하는 습관이 더 중요하다고 느꼈다.

읽고 난 후

레거시 시스템을 유지보수하면서 그동안 좋은 설계라고 믿었던 많은 선택들이 실제로는 복잡도를 높이는 방향이었을 수도 있다는 점을 돌아보게 되었다. 확장성과 재사용성을 위해 추가했던 추상화와 구조들이 시간이 지나면서 오히려 이해 비용과 수정 난이도를 높이는 경우도 많았다는 점이 특히 공감되었다. 결국 좋은 설계란 얼마나 구조가 정교한가가 아니라, 얼마나 쉽게 이해되고 안전하게 수정할 수 있는가라는 관점이 더 중요하다는 것을 다시 생각하게 되었다.

또한 중복 제거 자체보다 변경 영향 범위를 줄이는 것이 더 중요할 수 있다는 점도 인상 깊었다. 앞으로는 새로운 구조를 추가하는 것보다 현재 구조를 더 단순하게 만들 수 있는지 먼저 고민하는 방향으로 설계를 접근해야겠다고 느꼈다. 결국 좋은 설계란 복잡한 문제를 해결하기 위해 복잡한 구조를 만드는 것이 아니라, 복잡해질 수밖에 없는 문제를 가능한 단순하게 유지하는 것이라는 인사이트를 얻었다.

https://syudal.kr/post/미니멀리즘-프로그래머/

우리는 소프트웨어 개발하는 다양한 과정을 거치고, 다양한 언어 및 패러다임이 변경되는 것을 경험하고 있습니다.

최근 AI를 활용한 개발의 속도가 매우 빠르게 진행되면서, 이 시점에 우리는 어떠한 원칙을 가지고

개발자의 성장 및 원칙을 가지고 있어야 하는지 다시한번 생각해볼 시점이 되었습니다.

■ 단순함에 대해서

SW를 개발을 하게 되면, 개발자마다 다양한 시각과 관점을 가지게 됩니다.

그것도 경험이 많은 시니어 개발자 입장에서는 더 다양한 고민들이 생기게 됩니다.

이것도 해야 하고, 저것도 해야 하고, 이건 외부 솔류션을 사용할지 정해야 하고, 정말 다양합니다.

우리는 이런 다양한 것을 다 구현하고 진행하는것보다 더 큰 그림 및 프로그래머로써 단순함이라는 개발 원칙이 필요합니다.

책에서는 지속적으로 다양한 관점으로 단순함을 설명하고 있습니다.

PART 1 하는 일을 단순화하라, 일하는 방식을 단순화하라

PART 2 환경을 단순화하라

PART 3 상호작용을 단순화하라

PART 4 코드를 단순화하라

개발자 입장에서 우리는 새로운 언어나 기술을 채우는것도 보다, 비우는 단숨함을 어떠한 원리와 기준을 잡을수 있을까요?

■ 하는 일에 대해서 단순화 하기

소스 코드에 대해서 우리는 어떻게 단순화를 할수 있을지 고민해야 합니다.

1만줄 되는 코드를 라인수만 줄인다고 그 단순화하는 목표를 달성하는 것일까요?

우리는 라이브러리를 많이 사용하는데, 특정 라이브러리에 대해서 더이상 영속적으로 버전업그레이드가 되지 않는다면, 

추후 지속적인 유지보수 시점에 문제가 되는 경험을 하게 됩니다. 그러한 관점에서 어떠한 방향으로 접근을 해야 할지에 대해서

다룹니다. 프레임워크에 대해서도 사용에 대한 범위를 생각해보고, 외부에서 제공되는 것들에 대해서 보안 취약점에 대해서

어떻게 체크하고 검증할수 있을지도 중요 사항입니다.

· 프로젝트 최적화에 대해서도 다루는데, 가장 인상깊은 사항은 회의에 대한 부분이였습니다.

회의는 2명 이상 인원이 모여서, 함께 모여서 논의를 하는것이고, 스탠딩미팅등등 모두다 긍정적인 부분도 있지만, 

전세계 50개의 팀을 대상으로 의견을 취합하고 의견을 모아본 사항은 저에게 새롭게 다가왔습니다.

각자의 위치에서 회의를 바라보는 관점이 많이 달랐습니다.

■ 환경을 단순하게~

환경에는 물리적인 환경도 있고, 업무 및 논리적인 업무 환경도 있을것입니다.

터미널을 통해서, 매일 사용하는 도구, 일반적으로 자동화 할수 있는 것들

개발장비 구성이 어떻게 하는 것이 좋을지 도구의 필요성과, 어떠한 것을 사용하는지

기존에 익숙한 패턴 및 도구가 있지만, 지속적으로 발전하는 사항을 흡수해서 변화가 필요한 부분등

실제 이러한 것들을 하나씩 적용해가면서, 단순화를 하나하나 해볼수 있습니다.

■ 상호작용에 대한 단순화

함께 일하는 동료들에 대한 소프트 스킬에 대한 부분입니다.

혼자 개발을 다 할수 없고, 각자의 입장이 있으니, 우리는 어떠한 부분을 신경써야 할까요?

이러한 것은 개발적인 업무 보다 더 중요하고 효율을 높이고 좋은 방향으로 가기 위한 좋은 단순화 입니다.

Practice 16 의견 대립은 제로섬 게임이 아닙니다

Practice 17 공감 능력 기르기

Practice 18 사물에도 공감하기

Practice 19 이야기 엮기

사람들에게 시간을 내여주고, 나를 어떻게 바라볼지 고민해보고, 영향력도 체크해보고,

공감을 통해서 사전 피드백도 받는 관계를 구성합니다.

■ 코드르 단순화 하기

방향성을 제시하고, 저자분의 경험이 잘 적용되어 있습니다.

요구사항을 개발하기 위한 방향은 많지만, 데이터 주도 개발을 강조하고 그 이유에 대해서 설명합니다.

데이터 주도의 형태로 진행했을때 테스트 및 코드적인 방향, 상태 처리등 어떠한 장점이 있는지 이해할수 있습니다.

 

· 코드적으로도 어떻게 단순화 할지는 매번 고민이 있을수 있는 사항인데 이 책을 통해서 정리하는 기회가 될수 있습니다.

Practice 23 주석 달지 않기

Practice 24 TODO를 쓰느냐 마느냐

Practice 25 줄을 맞춰 정렬하세요

Practice 26 마지막에 쉼표 남겨두기

Practice 27 순서대로 정렬하기

Practice 28 옆으로 긴 코드보다 아래로 긴 코드가 낫다

Practice 29 관련된 코드는 한곳에 모으기

평소 주석 및 TODO에 대해서도 고민을 하였지만, 그 답을 찾지 못한 분들은 많은 도움이 되실것이라고 생각합니다.

오래동안 사용한 방식에 대해서도 다시 한번 살펴볼수 있고, 내가 지금까지 지키지 못하고 준수하지 못했던 사항들은

무엇이 있을지, 조금 더 나은 방향은 무엇이고, 함께 일하는 동료분들과 무엇을 해보고 싶은지 많은 생각이 들게 하고

도움이 되는 책입니다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다."

미니멀리즘이 한창 트렌드로 떠올라 <나는 단순하게 살기로 했다>의 저자 사사키 후미호처럼 이불과 책상만 있는 극단적인 미니멀리즘을 추구하기도 하고, 정리의 기술을 전파한 곤도 마리에처럼 불필요한 것들을 아낌없이 정리하자는 주의도 있었고, 내 삶을 채울 수 있는 것이 소비만이 정답은 아니라는 조슈아 필즈 밀번와 라이언 니커디머스의 자기 계발적인 스타일의 미니멀리즘도 있었다. 추구미는 다양하지만 미니멀리즘의 공통적인 핵심은 비우고 단순하게 살자인데 프로그램에서 미니멀리즘이라니? 책 제목 자체가 상당히 신선하게 다가왔다.

“단순함은 일을 처리하는 ‘방법’이라기보다는 일을 대하는 ‘마음가짐’에 가깝다.”

저자는 일단 한 마디 던지고 시작한다. 그런데 이 한 마디가 다음에 나올 모든 이야기에 대한 함축적인 의미를 담고 있다. 저자의 직업이 프로그래머이기 때문에 중간중간 외계어 같은 프로그램 코드가 나와서 개발자가 아닌 사람 입장에서는 다소 낯설음이 있을 수 있지만 개발자가 아니라서 개발 언어를 모르기 때문에 이 책을 읽지 못하고 이해하지 못할 부분은 없다. 오히려 저자의 마음가짐을 프로그래머가 아닌 관점에서 해석하면서 나의 마음가짐을 살펴보고 정리할 수 있는 시간을 가지게 되는 것 같아 독자 입장에서는 개발자가 아닌 게 장점이라는 생각도 들었다.

단순, 비움, 여백처럼 채워지지 않은 것들에 대해 왠지 불편함과 어색함을 가지고 있다. 내 업인 디자인에 있어서도 건축가 루드비히 미스 반 데어 로에(Ludwig Mies van der Rohe)의 “Less is More” 정신이나 디더 람스의 좋은 디자인의 10 계명을 머리로는 이해하며 불필요한 것들을 할 수 있는 한 최소한으로 디자인을 하려고 노력은 하지만 작업을 하다 보면 이런저런 이유로 늘상 계속 복잡해져만 가는 딜레마에 빠지게 된다. 디더 람스의 “Less, but Better.”에서 Less보다는 Better에 더 신경 쓰기 때문일 수도 있고, 여러 이해관계자들의 요구사항들을 정리에 정리에 정리는 하지만 차마 무시할 수는 없다 보니 ‘바나나 하나만 필요했을 뿐인데, 바나나를 든 고릴라와 정글 전체가 딸려온다(조 암스트롱).’는 말이 우리가 처한 현실인 것 같다. 그래서 덜어냄에도 용기가 필요하다는 정답을 알고 있음에도 불구하고 어디서 무엇부터 용기를 내야 할지를 고민하다가 이미 지쳐버린다. 그럼 기본은 단순하게 하고 옵션을 추가하면 어떨까도 고민하지만 옵션도 많아지면 큰 화를 불러올 수도 있다.

비워야 채울 수 있다는 말처럼 채울 공간이 없어서 더 넓은 집으로 이사 갈 수는 없고, 채울 마음의 여유가 없어서 번아웃에 직면할 수는 없지 않은가. 일도 삶도 가끔은 한 발짝 멀찍이 떨어져도 제 3자의 관점에서 볼 필요는 있을 것 같다. 그러면 좀 더 객관적이 입장에서 비워도 될 부분이 보이지 않을까?

비움을 강요하는 것도 충분히 스트레스가 될 수 있다. 그렇다면 채우기 위해 비우는 것도 하나의 전략이 될 수는 있으니 무작정 비우는 용기를 내기 힘들다면 채우고 싶은 것을 위해 비워보는 것도 나름 비움에 대한 연습이 될 수도 있을 것 같다. 그런 의미에서 4월에 봄맞이 비워내기 한 번 해 볼까요?

#한빛미디어 #나는리뷰어다 #미니멀리스트프로그래머

미니멀리즘 프로그래머 : 코드부터 협업까지, 단순함으로 생산성을 높이는 법

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

들어가며.

AI 모델들의 성능이 상향평준화되면서, 엄청나게 많은 '그럴싸한 코드'들이 짧은 시간 내에 마법처럼 뚝-딱 만들어진다. 그러나, 대부분의 사람들이 공감하는 이른바 '바이브 코딩'의 문제점은, 불필요하게 많은 코드들이 양산되어 전체 파악이 어렵다거나, 숨겨진 버그를 양산할 수 있다거나, 코드에 문제가 없더라도 애초에 그 많은 코드들을 전부 살펴보며 모든 맥락을 이해하기 어렵다는 점이다.

요즘 같은 AI 시대에 최종 결과물(작성된 코드)의 책임은 사람에게 있다는 이야기가 자주 들린다. 즉, 사람이 최종적으로 코드를 리뷰하여 이해하고, 그 코드로 인해 발생하는 문제를 책임져야 하며, 더 나은 방향으로 가이드를 할 수 있어야 한다는 것이다. 코드의 결과물 자체는 궁극적으로 사람이 읽기에 좋아야 한다는 점은 AI 이전에도 중요했지만, AI 시대에도 여전히 중요한 가치로 평가받는다.

결국 '코드의 가독성'에 초점이 맞춰진다. 어떻게 하면 가독성 높은 코드를 만들 수 있을 것인가? 아마도 개발자들이 평생하는 고민 중 하나가 아닐까 싶다. 이번에 [미니멀리즘 프로그래머]을 통해 내가 모르는 방법론들을 알아보고자 했다.

책의 주요 내용.

책의 분량 자체는 많지 않다. 그러나 그 안에 담겨있는 내용의 범위가 꽤나 방대하다. 단순히 코드의 작성법에 대한 내용이었다면 제목이 아마 [미니멀리즘 프로그래밍]이 되었겠지만, [미니멀리즘 프로그래머]인 이유가 있었다.

이 책에서는 협업 시 필요한 소프트 스킬에 대한 이야기부터, 팀 생산성을 높일 수 있는 '불필요한 회의를 줄이는 방법' 등 업무 전반에 걸쳐 많은 범주의 이야기들이 담겨있기 때문이다. 말 그대로 현업에서 일하고 있는 '프로그래머'를 위한 내용들이었다.

Part1에서는 일을 단순화하는 방법에 대해 소개한다.  특히 눈길을 끌었던 건 '코드 다이어트'였다. 불필요하게 많은 라이브러리 등을 설치해서 의존성을 높이지 말고, 때로는 직접 같은 기능을 하는 함수를 구현한다던가 하여 의존성을 줄이는 방법에 대한 이야기였다.

Part2에서는 '환경을 단순화하라'라는 표현이 나온다. 이는 사실 '개발 환경'에 대한 이야기임을 프로그래머라면 유추할 수 있을 것이다. 실제로 개발환경이나 터미널 환경, 에디터 등에 대한 이야기가 주를 이룬다. 여기서의 키워드는 '자동화'이다. 자동화를 통해 신경써야 할 것들을 줄이고 '단순화'하라는 의미다.

Part3는 소프트 스킬에 대한 내용을 다룬다. 소프트 스킬은 직군과 직무를 막론하고 협업을 하는 거의 모든 사람들에게 필수적인 스킬이면서도, 동시에 갖추기 꽤나 어려운 것이다. 오죽하면 '스킬'이라는 말이 붙을 정도이니까. 반면에, '스킬'이라는 것은 얼마든지 연습과 노력을 통해 어느 정도 수준까지 '연마'할 수 있다는 뜻이기도 하다. 이 책에서는 프로그래머에게 필요한 몇 가지의 소프트 스킬을 소개하고, 이를 발전시킬 수 있는 간단한 실천법을 제시한다.

Part4가 아마 필자를 포함해 많은 프로그래머들이 기대했던 내용이라고 생각한다. 바로 실제 코드 작성법 및 개발 방법론에 대한 이야기이다. 특히 가독성 높은 코드를 작성하기 위해 어떤 점들을 신경써야 하고, 어떤 것들을 수행해야 하는 지 설명하고 있다.

책을 읽으며 인상깊었던 점은.

이 책에서 좋았던 점은, 독자가 이미 알고 있었거나 모르고 있었거나 상관없이, 직접 스스로 생각하며 환기해볼 수 있는 장치를 만들어주었다는 점이다. 독자에게 던지는 질문들이 책 곳곳에 존재하는데, 이 장치 덕분에 스스로를 되돌아보며 일종의 '반성'을 하는 계기를 만들어주었다. 이미 아는 내용이 잘 체득 되어서 실제 현업에서도 잘 적용했던 경우도 있었고, 아는 내용이었지만 막상 현업에서 적용하지 못하고 있는 부분들을 다시 되돌아보게 되었다.

또, DWP(Developer without Portfolio)라는 새로운 개념도 배울 수 있었다. 직접 기능을 개발하는 대신, 팀원들의 병목과 고충을 파악하고 협업이 원활히 돌아가도록 돕는 일종의 '팀 서포터' 역할이다. 신선한 개념이었지만, _PM이나 테크 리드가 이미 이 역할을 하고 있는 것 아닌가?_ 하는 의문도 들었다. 흥미로운 건 책이 그 의문을 인식하고, '이렇게 해보세요' 섹션을 통해 직접 실험해볼 수 있는 가이드라인까지 제시한다는 점이었다.

마치며.

[미니멀리즘 프로그래머]를 읽고, 갑자기 한 문장이 떠올랐다. 'Simple is the best.'
단순함의 가치를 다시금 되새겨 볼 수 있었다. 필자 스스로도 코드를 작성할 때, 단순함을 추구하는 편이다. 항상 불필요하게 복잡한 코드를 보면 '더 단순할 수는 없나?'를 생각한다. 하지만 내 바람과는 달리 실제로 복잡한 요구사항들이 포함된 코드를 단순하게 만드는 작업은 무척 어렵다.

책에서 소개한 실천적 방법론들을 차근차근 코드에 도입해보면서 가독성 좋은 코드를 작성하기 위한 노력을 다시 꾸준히 이어가야겠다는 생각이 들었다. 코드 퀄리티에 대해 막연하게 고민하고 있는 개발자, 또는 팀 생산성에 관심 있는 개발자라면 한 번쯤 읽어볼 만한 책이라고 생각한다.
 

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다."

처음 이 책 제목을 봤을 때 솔직히 의아했습니다.

미니멀리즘 프로그래머? 코드는 많을수록, 기능은 복잡할수록 실력 있는 개발자처럼 느껴지는 세상에서, 오히려 '줄이기'를 이야기한다니.

하지만 몇 페이지를 넘기자마자 고개가 끄덕여졌습니다.

이 책은 단순히 코드를 짧게 쓰라는 이야기가 아니었습니다.

저자 데이비드 토머스는 『실용주의 프로그래머』를 쓴 전설적인 개발자입니다.

그가 이 책에서 꺼내드는 화두는 하나입니다. AI가 코드를 대신 써주는 지금, 진짜 개발자의 실력은 무엇인가?

그의 대답은 명확합니다. '무엇을 덜어낼지 판단하는 능력'입니다.

책은 총 29가지 실천법으로 구성되어 있는데, 크게 네 가지 영역으로 나뉩니다.

PART 1 하는 일을 단순화하라, 일하는 방식을 단순화하라
PART 2 환경을 단순화하라
PART 3 상호작용을 단순화하라
PART 4 코드를 단순화하라

특히 인상 깊었던 것은 "코드 11줄을 작성하는 대신 라이브러리를 선택한 이유를 생각할 필요는 있습니다."라는 질문이었습니다. 

생각해 보면 저도 그랬습니다. 

익숙한 도구를, 아무 의심 없이 가져다 쓴 적이 얼마나 많았는지. 저자는 이 습관이 어떻게 프로젝트를 조용히 망가뜨리는지 차분하게 짚어줍니다.

회의를 줄이라는 챕터는 흥미로웠습니다.

'지긋지긋한 회의 줄이기'라는 소제목부터 공감이 갔습니다.

많은 팀이 소통한다는 명목 아래 오히려 더 복잡한 구조를 만들어가는데, 저자는 정보가 자유롭게 흐르는 구조를 설계하는 것이 진짜 소통이라고 말합니다.

코드 가독성을 다루는 8 챕터도 흥미로웠습니다.

'주석 달지 않기', '옆으로 긴 코드보다 아래로 긴 코드', '관련된 코드는 한곳에' 같은 원칙들은 단순해 보이지만, 이를 실천하는 것이 얼마나 어려운지는 조금이라도 코드를 써본 분이라면 잘 아실 겁니다.

책의 두께는 192쪽으로 얇습니다. 책이 얇다고 그 지식까지 얕은 건 아닙니다

얇음 자체가 이미 메시지입니다.

저자는 군더더기 없이 핵심만 담았습니다. 읽는 내내 '이 책 자체가 미니멀리즘의 실천이구나' 싶었습니다.

AI가 수백 줄의 코드를 순식간에 생성해 주는 시대입니다. 

그럴수록 소프트웨어는 오히려 더 비대해지고, 아무도 전체를 이해하지 못하는 덩치만 큰 괴물이 되어가고 있습니다.

이 책은 그 흐름에 조용하지만 단호하게 저항합니다.

빠르게 만드는 법은 AI가 가르쳐 줄 수 있습니다. 하지만 단순하게 만드는 법은 여전히 사람이 배워야 합니다.

복잡함이 당연해진 시대에, 이 책은 한 가지를 조용히 일깨워 줍니다. 단순함은 게으름이 아니라, 판단력이고 용기이며 실력이라고.

이 책은 프로그래밍을 공부하는 모든 분들에게 추천드리고 특히 프로젝트를 업데이트하면서 비대해진 자신의 코드들을 어떻게 효율적으로 업데이트 할 수 있을지 고민하는 분들에게 적극 권합니다
 

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

이 책은 업계 선배에게 현실적인 조언을 듣는 듯한 느낌을 주는 책이었습니다. 추상적인 원칙만 말하는 것이 아니라, 실제 도구와 코드 예시를 함께 보여줘서 이해하기 쉽고 실천해보기에도 좋았습니다.

주니어 개발자인 제 입장에서는 공감되는 내용도 많았고, 새롭게 생각해보게 되는 부분도 있었습니다. 또 단순히 정보만 전달하는 것이 아니라 저자의 경험과 태도까지 함께 느껴져 더 생생하게 읽혔습니다.

물론 모든 조언이 제 상황에 그대로 맞지는 않았습니다. 직접 적용해보다가 보류한 내용도 있었지만, 그런 과정 자체가 제 개발 습관과 작업 방식을 돌아보게 했습니다. 정답을 알려주는 책이라기보다, 개발자로서 고민해볼 질문과 기준을 던져주는 책에 가까웠고, 그래서 더 의미 있게 읽었습니다.

개발자로 일하면서 필요한 다양한 기준과 습관을 함께 고민해보고 싶은 분들에게 특히 추천하고 싶습니다. 코드 이야기뿐 아니라 소프트 스킬과 실무적인 태도까지 폭넓게 다루고 있어, 한 번쯤 자신의 방식을 점검해보고 싶은 개발자라면 흥미롭게 읽을 수 있을 것 같습니다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

짧은 책이라 쉽고 빠르게 읽을 수 있으면서도 동시에 개발에 필요한 핵심에 해당하는 정신, 자세, 규칙 등을 담고 있다. AI가 코드를 작성하는 시대가 됐지만, 아직은 결국 사람이 개입해야 한다. 사람이 개입하는 순간 사람이기 때문에 발생할 수밖에 없는 많은 부분이 성공과 실패, 수준 차이를 만들게 된다. 이때 유념하고 적용할 원칙이 저자가 말하는 단순함, 미니멀리즘이다.
저자가 말하는 단순함은 코드에만 국한되지 않는다. 프로젝트 구조, 프로세스, 팀원과의 관계까지 개발의 거의 모든 측면을 관통하는 원칙이다. 나는 야구를 좋아해서 종종 개발에 비유하는데, 프로세스를 예로 들면 과정의 단순함이 프로젝트의 성패뿐만 아니라 수준을 결정하는 경우가 많다. 때로는 복잡한 프로세스로도 뛰어난 성과를 만드는 경우를 볼 수 있으나 지속성이 떨어진다. 팀 린스컴은 짧은 기간이었지만 MLB를 호령하던 뛰어난 투수였다. 한국 야구 기준으로 봐도 작은 체격이었지만, 이 단점을 보완하기 위해 만든 역동적인 딜리버리로 100마일이 넘는 강속구를 던지던 엘리트 투수로 전성기에는 2년 연속 사이영상을 수상하기도 했다. 그러나 체격의 약점을 메우기 위한 복잡한 딜리버리는 몸에 과도한 부하가 되었고, 부상을 당하면 딜리버리 과정에서 하나라도 어긋나면 원하는 수준의 투구가 나오지 않았기에 자신의 투구폼을 다시 찾는 데 큰 걸림돌이 되었다. 결국 약 6년의 전성기 후에는 하락세에 접어들었고 10시즌을 보내고 은퇴했다(물론 그 전성기가 굉장히 빛났기에 아직도 많은 팬들이 기억하는 선수다).
반면 그렉 매덕스는 린스컴과 비슷하게 체격이 크지 않은 선발 투수였지만 반대로 접근했다. 단순하고 반복 가능한 딜리버리로 평균 90마일이 안 되는 빠르지 않은 속구를 던졌지만 '마스터'라는 별명, '모든 구종'을 '원하는 곳'에 '원하는 속도'로 던진다는 평을 들었다. 경기당 평균 78구의 효율적인 피칭으로 23시즌 동안 심각한 팔 부상 없이 355승을 쌓았고 5000이닝을 넘게 던졌으며(전성기 중 2년은 파업으로 단축 시즌이었다), 말년에 구속이 86마일 이하로 떨어져도 여전히 통했다.
단순하기에 갖는 유지 보수와 운영의 장점이 좋은 성과를 지속할 수 있는 힘이 된다. 단순함을 실천하는 게 쉽지 않다는 걸 아는 사람일수록, 이 책에서 얻을 게 있을 거란 생각이 든다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

미니멀한 가치를 좋아한다. 디터 람스의 디자인에 매료되었던 것처럼, 덜어내는 것에 더 흥미를 느낀다. 사실 흥미를 느끼는 것과 실제로 삶에 녹여내는 것과는 다른 이야기이기도 하다. 짐을 버리지 못해 방에 한껏 짐을 쌓아두기도 하고, 유지보수를 위해 간소한 코드를 짜야 함을 알면서도 여러 가지 사정으로 비대해지는 경험을 하기도 한다.

AI-Native 시대에 와서는 코드 작성을 위임할 수 있게 되었고, 대체로 효율적인 코드를 뱉어주기 때문에 전보다 간소한 코드 베이스를 갖게 되기도 한다. 때로는 오버엔지니어링을 하기도 하지만, 적당히 방향성을 잡고 길 안내만 잘해주면 ‘알잘딱깔센’으로 최적화까지 깔끔하게 처리한 코드를 내어놓는다.

요즘은 개발 자체의 가치보다 AI에 관한 이야기가 훨씬 많은 시대다. ‘이 AI는 미쳤습니다’, ‘딸깍 하나로 모든 게 만들어졌습니다’ 같은 AI에 대한 청사진만 가득한 시점에 개발 본연의 가치를 이야기한들 사실 큰 관심을 받기 어렵다. 개발자를 포함해 모든 사람이 AI에 대한 포모(FOMO: Fear Of Missing Out)에 시달리는 시대라, 그에 걸맞은 ‘마음 편한 행동’을 하고 있을 뿐이라고 생각한다. 나라고 뭐 특별히 다르지도 않다. 오늘만해도 하네스 관련 아티클을 읽다가 퇴근할 것 같다.

개발 경력이 그렇게 길진 않지만, AI 기반 개발이 없던 시절부터 개발해 왔다. 그 무렵에는 본연의 가치를 많이 강조해 왔다. 의존성을 줄여라, 최적화해라, 개발하기 좋은 환경 만들어라, 소프트스킬 길러라, 코드 가독성을 높여라 등등. 흔하게 들어왔던 이 모든 가치가 이 책에 함축적으로 들어 있다. 물론 200페이지 정도 분량이기에 상세하게 다루고 있지는 않지만, 목차만 보고도 다시금 이런 글을 접하는 건 가치 있는 일이라고 느꼈다.

이 책은 그저 추상적으로 말하지 않는다. 오히려 개발 과정에서 복잡함이 어떻게 생겨나는지를 현실적으로 짚는다. 의존성을 늘리는 일, 과한 추상화, 반복되는 수작업, 비효율적인 협업과 설명되지 않은 맥락까지, 결국 복잡함은 코드 몇 줄의 문제가 아니라 개발자의 환경과 습관, 팀의 소통 방식 전반에서 만들어진다고 이야기하고 있다.

예컨대 ‘지긋지긋한 회의 줄이기’, ‘이야기 엮기’와 같은 내용은 코드와는 크게 관련이 없다. 이건 팀 단위가 어떻게 소통해야 하는지, 어떤 효율적인 방식을 취해야 하는지, 또 비개발자와의 소통에서는 어떤 태도로 이야기를 나눠야 하는지에 대한 이야기이다. 영화에서 보듯 막연하게 개발자를 떠올리면 화면에 알 수 없는 코드들이 날아다니고 천재 개발자처럼 코드만 짤 것 같지만, 사실 현업에서 일하다 보면 코딩보다 협업을 위한 소통의 비중이 높은 하루도 꽤 많다는 걸 알게 된다.

그래서 볼륨은 작지만 다루는 범위는 생각보다 넓다. 코드 정리법을 넘어 의존성을 줄이고, 자동화의 영역을 다루고, 개발 환경을 정비하고, 협업에서의 소통 비용을 낮추는 방향까지 함께 다룬다. 마지막에는 다시 데이터와 흐름이나 가독성 높은 코드에 관한 이야기로 돌아오는데, 미니멀한 가치를 코드 스타일에 머무는 것이 아니라 개발자가 일하는 방식 전체의 원칙으로 확장해서 보여준다는 점이 좋았다.

단순함은 늘 중요하지만 미뤄지는 가치가 되기 쉽다. 책에서는 그런 현실을 외면하지 않고, 지금 줄일 수 있는 복잡함이 무엇인지부터 묻게 만든다. 읽으면서 새로운 걸 배운다기보다, 이미 알고 있었지만 흐릿해졌던 기준을 다시 꺼내 보는 느낌에 가까웠다. 저연차의 개발자가 읽더라도 한 번쯤은 들어봤을 내용일 가능성이 높고, 그 내용을 다분히 쉽게 설명해 내고 있다.

그렇기 때문에 지금 같은 AI 시대에 가치 있는 책일지도 모른다. 코드를 빠르게 쳐내는 능력보다도, 오버엔지니어링과 아키텍처를 파악해 무엇을 덜어낼지 판단하는 감각이 더 중요해졌기 때문이다. 어디까지 추상화할지, 감수해야 할 복잡함과 줄여나갈 수 있는 복잡함이 무엇인지 판단하는 건 여전히 사람의 몫이다. 그런 면에서 이 책은 시대와 동떨어진 책이 아니라, 오히려 지금일수록 다시 읽어볼 만한 개발의 기준을 담고 있는 책처럼 느껴졌다.

결국 이 책은 덜 만들자는 선언이 아니라, 더 중요한 것을 남기기 위해 덜어내자는 제안이다. 결코 새로운 이야기는 아니다. 더 단순하게, 더 이해할 수 있게, 더 오래 유지할 수 있는 방향으로 나아가는 것, 어쩌면 지금 필요한 건 새로운 것을 더 익히는 일보다 무엇을 버릴지를 판단하는 감각을 회복하는 일인지도 모르겠다.

#AI에이전트엔지니어링 #나는리뷰어다 #한빛미디어

    "한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

처음 이 책을 펼쳤을 때는 솔직히 '또 클린 코드 책이겠지' 싶었다. 그런데 읽다 보니 방향이 달랐다. 더 잘 짜는 법이 아니라, 덜 짜는 법을 이야기하고 있었다.

가장 기억에 남는 부분은 의존성 챕터였다. leftpad 얘기가 나오는데, 11줄짜리 코드를 직접 쓰는 대신 라이브러리를 찾아 설치했던 나의 비슷한 경험이 거기 있었다. 나도 별 생각 없이 npm install을 치면서 '검증된 거 쓰는 게 낫지'라고 합리화했던 기억이 났다. 책은 그걸 틀렸다고 하지 않는다. 다만 멈춰서 한 번 물어보라고 한다. "이 의존성이 내 미래의 나에게 짐이 되지는 않을까?"

프레임워크 챕터도 비슷하게 와닿았다. 빠르게 달리는 열차에 올라탄 느낌, 근데 내릴 수 없는 느낌. 예전에 특정 프레임워크에 코드베이스를 깊이 묶어놨다가 API가 바뀌면서 수십 개 파일을 손댄 경험이 있었는데, 그게 바로 책에서 말하는 '한번 들어오면 빠져나가기 어려운 덫'이었다. 

회의 챕터도 인상 깊었다. "굳이 회의가 필요한가요?"라는 질문이 당연한 듯 나오는데, 내가 요새 그런말을 많이 하는것 같기도 하다. 그냥 캘린더에 잡히면 들어갔고, 끝나면 뭘 결정했는지 모호한 채로 자리로 돌아왔다. 책을 읽고 나서 다음 번 회의 초대를 받았을 때 처음으로 "이 회의의 목표가 뭔가요?"를 물어보는 자세를 가져야겠다.

결국 이 책이 말하는 미니멀리즘은 미학이 아니라 태도다. 코드를 덜 쓰고, 의존성을 덜 추가하고, 회의를 덜 하고, 자동화할 수 있는 건 자동화하는 것. 그게 게으름이 아니라 더 중요한 것에 집중하기 위한 선택이라는 것. 읽는 내내 머릿속에서 내 코드베이스와 내 하루 일과가 겹쳐 보였다.

​단순히 코드를 짧게 만드는 기술을 기대했다면 이 책은 반전으로 다가올 것입니다. 데이비드 토머스의 『미니멀리즘 프로그래머』는 물리적인 코드의 양을 줄이는 법이 아니라, 프로그래밍 과정에서 발생하는 불필요한 복잡성을 걷어내고 '의미 있는 변화'에 집중하는 법을 다룹니다.

​저자는 서론에서 "불필요한 것을 덜어내는 과정을 즐기길 바란다"고 말합니다. 실제로 책은 기술적인 강요보다는 독자가 직접 고민하게 만듭니다. 각 챕터 끝에 배치된 질문들에 스스로 답변하고 작은 실행안을 실천하다 보면, 모호했던 개념들이 실제 나의 실력으로 치환되는 유익한 경험을 할 수 있었습니다.

​가장 인상 깊었던 대목은 'Practice 15. 미래에서 놀고, 과거에서 일하기'였습니다. 이 챕터를 읽으며 과거 실무에서 겪었던 뼈아픈 경험들이 떠올랐습니다. 과거 재직했던 곳에서 기술 환경이 급격히 변하며 전체 시스템을 재구축해야 했던 프로젝트부터, 최근 조직 내에서 최신 트렌드만을 쫓아 기존의 안정적인 기술 스택을 완전히 교체하려 했던 시도까지 말입니다.

​변화를 받아들이는 유연함은 필수적이지만, 서비스의 규모와 비즈니스 안정성을 도외시한 채 '새로운 것'만을 추구하는 것이 얼마나 위험한지 이 책은 차분하게 일깨워줍니다. 이미 안정적으로 운영 중인 서비스를 다른 언어나 프레임워크로 옮기는 결정에는 기술적 열망보다 훨씬 더 무거운 책임감과 리스크 관리가 필요하다는 점을 다시금 절감했습니다.

​이 책은 주니어 개발자에게는 좋은 습관을, 시니어 개발자에게는 본질을 되찾는 성찰의 기회를 제공합니다. 복잡한 세상 속에서 명쾌한 코드를 짜고 싶은 모든 프로그래머에게 일독을 권합니다.

이 책에 정답은 없습니다. 사람마다 상황이 다르니까요

이 책은 위 문장으로 시작된다. 책의 내용을 읽어보다면 책 내용은 정답이 아니다.

정답을 얻기 보다는 다양한 관점에서 생각 해볼 수 있는 기회를 주는 책이라고 보는게 낫다.

책에서는 간단한 함수는 직접 작성하는게 좋다고 말한다. 라이브러리에 의해 버그가 발생할 수 있기 때문이고 의존성이 생기기 때문이다.

그렇다고 프레임워크를 사용하지 말라는 말은 아니다. 프레임워크를 사용하기 전에 잘 이해하고 써야 한다는 말로 해석된다.

몇 줄 안되는 코드를 짜기 싫어서 라이브러리의 함수를 사용하지 말라는 이야기 이다.

​

최근에 AI가 도입되면서 업무가 줄어야 하는데 업무가 늘어난 것 같은 기분이 든다.

그러면서 같이 회의도 늘어나고 있다. 회의가 많아지면 많아질수록 업무시간이 줄어든다. AI에게 업무를 맡긴다고 하더라도 업무에 집중하는 시간이 더욱 줄어드는 격이다.

책을 읽다보니 미니멀리즘 프로그래머는 얼마나 미니멀해져야하는 것일까? 라는 생각이 들었다. 마우스를 사용하지 않으려고 노력할 정도로

그렇게 미니멀해져야할까? 앞서 언급했듯 이 책은 정답이 아니다. 그저 사람마다 다르기 때문에 책에서 마음에 드는 내용만 읽어도 될 정도로 가벼운 책이다. 그래서인지 읽기 어렵지 않았고 재미있었다. 다양한 관점에서 고민해볼수 있는 계기가 되었고, 개발자가 어느정도까지 미니멀해질 수 있는지 궁금한 개발자에 추천하고 싶다.

​

그렇다고 개발자만 볼만한 책은 아니다. 내용 전반적으로 업무, 사람과 사람에 관계에서 나타날 수 있는 내용들을 다루고 있어서 모두가 보기 좋은 책이다. 뜬금없지만 공감에 대한 내용도 나온다. 이후에는 '사물에도 공감하기'라는 내용도 나오는데 개발자들이 공감능력이 얼마나 없으면 책에 그렇게까지 서술했을까 생각도 했다.

​

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

    "한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

개발을 하다 보면 어려운 문제를 푸는 것보다, 불필요하게 복잡해진 환경을 정리하는 데 더 많은 에너지를 쓰게 되는 순간이 많습니다.

기능은 계속 늘어나고, 협업 구조는 복잡해지고, 회의는 많아지고, 반복 업무는 줄지 않다 보니 정작 중요한 문제 해결에 집중하기가 점점 어려워집니다. 저 역시 현업에서 AI 엔지니어로 일하면서 이런 문제를 자주 체감하고 있는데, 《미니멀리즘 프로그래머》는 단순히 코드를 간결하게 작성하는 법을 넘어, 개발자가 일하는 방식 자체를 어떻게 더 단순하고 건강하게 만들 수 있을지 생각하게 해준 책이었습니다.

이 책을 읽으며 특히 공감됐던 부분은 회의에 대한 내용이었습니다.

실제로 팀에서 일하다 보면 회의가 많다고 해서 협업이 잘되는 것은 아니고, 오히려 많은 회의가 집중력을 끊고 실행 시간을 빼앗는 경우도 많습니다. 책에서 말하는 ‘지긋지긋한 회의 줄이기’ 같은 내용은 정말 실무와 맞닿아 있다고 느꼈습니다. AI 프로젝트도 비슷합니다. 모델 실험, 데이터 검토, 결과 공유를 위해 회의가 계속 생기는데, 그중에는 꼭 필요한 논의도 있지만 단순 현황 공유 수준의 회의도 적지 않습니다. 그런 점에서 이 책은 “회의를 많이 하는 팀”보다 “정말 필요한 소통만 남기는 팀”이 더 효율적일 수 있다는 점을 다시 생각하게 만들었습니다.

또 인상 깊었던 부분은 업무 자동화였습니다.

AI 엔지니어 업무는 겉으로 보기에는 모델 개발이 중심처럼 보이지만, 실제로는 반복적인 작업이 굉장히 많습니다. 데이터 전처리, 실험 실행, 결과 정리, 평가 리포트 작성, 모델 성능 비교, 배포 체크, 로그 확인처럼 자잘하지만 계속 반복되는 일이 쌓이기 쉽습니다. 책의 업무 자동화 파트를 보면서, 이런 반복 업무야말로 가장 먼저 정리하고 자동화해야 할 대상이라는 생각이 들었습니다. 결국 자동화는 “편해지기 위한 장식”이 아니라, 사람이 더 중요한 판단과 설계에 집중하기 위해 반드시 필요한 과정이라는 점에서 크게 공감했습니다.

저는 특히 이 책이 기술 자체보다 일하는 구조를 단순화하라는 메시지를 준다는 점이 좋았습니다.

AI 분야는 새로운 모델, 프레임워크, 평가 방식이 계속 쏟아지기 때문에 자칫하면 팀 안에 정보가 파편화되기 쉽습니다. 누가 어떤 실험을 했는지, 어떤 방식이 실패했는지, 왜 특정 선택을 했는지가 제대로 공유되지 않으면 같은 시행착오를 반복하게 됩니다. 그래서 책에서 말하는 기술 공유의 중요성도 크게 와닿았습니다. 좋은 기술 문화는 거창한 발표보다도, 팀원들이 이해할 수 있는 형태로 지식을 정리하고 나누는 데서 시작된다고 생각합니다. 저도 이 책을 읽으면서, 개인적으로만 공감하고 끝낼 내용이 아니라 우리 팀원들과도 꼭 같이 공유해보고 싶다는 생각이 들었습니다.

개발자는 흔히 더 많은 기능, 더 많은 도구, 더 많은 회의, 더 많은 문서를 통해 문제를 해결하려고 하지만, 실제로는 그 반대가 답일 때도 많습니다. 불필요한 것을 덜어내고, 반복 업무를 자동화하고, 꼭 필요한 소통만 남기고, 팀 안에서 지식을 잘 공유하는 것. 이 책은 그런 기본 원칙을 다시 점검하게 해주는 책이었습니다.

그래서 이 책은 저처럼 개발 실무를 하면서 복잡함에 지쳤던 사람, 그리고 팀의 일하는 방식을 더 효율적으로 만들고 싶은 사람에게 특히 추천하고 싶습니다.

《미니멀리즘 프로그래머》는 코드를 줄이는 책이라기보다, 개발자의 일과 협업을 더 본질적으로 만드는 책에 가까웠습니다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

실용주의 프로그래머 저자중 한명인 데이비드 토마스의 신작이라는 걸 모르고 읽다가 기시감이 들어 찾아보니 같은 저자였습니다. AI 시대에 구현 비용이 낮아지면서 복잡성을 쉽게 마주하게 됐는데, 이 책은 그 복잡성을 어떻게 다룰지에 대한 실전 가이드입니다. 워드 커닝엄의 "동작하기만 한다면 가장 단순하게 만들어라"가 핵심 메시지이며, 불필요한 의존성 제거, 필요 주도 개발, 비동기적 삶, 기술 공유의 중요성까지 폭넓게 다룹니다. 미니멀리즘 프로그래머가 되고 싶은 사람은 많아도 되기는 엄청 힘들다고 생각합니다. 분량도 많지 않아 리프레시하기 좋은 도서입니다.

자세한 리뷰는: https://sonim1.com/ko/blog/minimalist-programmer-review