한빛미디어

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

​

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

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

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

​

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

​

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

​

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

​

인상 깊은 포인트

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

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

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

​

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

​

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

​

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