개발 서적 10권을 읽고
현실에서 달라진 것
6개월, 4,200페이지. 읽으면 코딩이 늘 줄 알았다. 실제로 달라진 건 코딩 방식이 아니었다
개발을 시작하고 한 1년쯤 지났을 때, 이상하게 막막한 시기가 왔다. 코드는 쓸 줄 아는데 뭔가 허술한 느낌. 기능은 되는데 뭔가 부끄러운 코드를 짜고 있다는 느낌. 그때 시작한 게 개발 서적 읽기였다.
6개월 동안 10권을 읽었다. 읽기 전 기대는 "읽고 나면 코드 실력이 확 늘겠지"였다. 실제로는 달랐다. 코드가 갑자기 좋아진 게 아니라, 왜 내 코드가 별로였는지를 언어로 설명할 수 있게 됐다. 그게 더 무서운 변화였다.
10권
6개월간 읽은 개발 서적
4,200p
총 페이지 수
평균 420p/권
평균 420p/권
3권
두 번 이상 읽은 책
2권
솔직히 별로였던 책
(이유도 씀)
(이유도 씀)
읽은 책 10권 — 솔직한 한 줄 평
추천 리스트가 아니다. 내가 실제로 읽고 느낀 것을 가능한 그대로 썼다. 별점은 "이 시기의 나에게 얼마나 도움이 됐나" 기준이다.
BOOK 01
클린 코드
★★★★★
가장 먼저 읽었고, 가장 많이 밑줄을 그었다. "좋은 코드"가 추상적인 개념이 아니라 명명법, 함수 크기, 주석 사용 기준 같은 구체적인 것들로 정의된다는 걸 처음으로 이해했다. 읽고 나서 두 달간 변수명을 짤 때마다 이 책이 생각났다. 단점은 예제 코드가 Java 기반이라 JavaScript 개발자는 살짝 거리감이 있다.
"나쁜 코드는 결국 시스템을 무너뜨린다. 좋은 코드는 사람이 읽을 수 있는 코드다."
BOOK 02
실용주의 프로그래머
★★★★★
클린 코드가 "코드를 어떻게 쓰냐"라면, 이 책은 "개발자로 어떻게 살아가냐"를 다룬다. DRY 원칙, 깨진 창문 이론, 지식 포트폴리오. 기술보다 태도에 관한 책이다. 취업 준비 중에 읽었는데, 개발자라는 직업에 대한 마인드셋이 바뀌었다. 10년 뒤에 다시 읽으면 또 다른 의미로 다가올 것 같다.
"지식 포트폴리오에 정기적으로 투자하라. 모르는 언어를 배우고, 기술 서적을 읽고, 커뮤니티에 참여하라."
BOOK 03
리팩터링 2판
★★★★★
2판은 JavaScript 예제라 읽기 편했다. "리팩터링"이 막연히 "코드 개선"이 아니라 구체적인 기법들의 모음이라는 걸 알게 됐다. 함수 추출, 변수 인라인, 조건부 로직 분해 같은 것들. 전부 읽지 않아도 된다. 카탈로그처럼 쓰면서 필요할 때 찾아보는 방식이 더 실용적이다. 처음부터 끝까지 독파하려다 지쳐서 중간에 포기한 경험도 있다. 솔직 고백
"일단 돌아가게 만들고, 올바르게 만들고, 그 다음 빠르게 만들어라."
BOOK 04
소프트웨어 장인
★★★★★
"나는 단순히 코드를 짜는 사람인가, 아니면 장인인가"라는 질문을 던지는 책이다. 클린 코드와 비슷해 보이지만 결이 다르다. 이 책은 커리어와 태도에 더 집중한다. 특히 "프로페셔널리즘"을 코드 품질과 연결하는 방식이 인상적이었다. 번역이 조금 어색한 부분이 있지만 내용 자체는 값지다.
"진정한 소프트웨어 장인은 고객의 비즈니스를 이해하고, 기술적 탁월함을 통해 그것을 돕는 사람이다."
BOOK 05
함께 자라기
★★★★★
유일한 한국 저자 책이고, 10권 중 가장 빠르게 읽혔다. 혼자 잘하는 것과 팀에서 잘하는 것의 차이, 애자일이 도구가 아니라 마인드셋이라는 것, 피드백 루프의 중요성. 팀 협업에 막 뛰어든 시점에 읽어서 특히 공감이 됐다. 두께도 얇아서 부담 없이 읽기 좋다. 개발 서적 읽기 처음이라면 이것부터 권하고 싶다.
"실력은 혼자 쌓는 게 아니라 함께 쌓는 것이다. 팀의 학습 속도가 개인의 학습 속도를 결정한다."
BOOK 06
도메인 주도 설계 (DDD)
★★★★★
솔직히 말하면 절반도 이해 못 했다. 개념은 알겠는데 내 코드에 어떻게 적용하는지가 안 보였다. 시니어한테 물어봤더니 "실무에서 DDD를 직접 써보지 않으면 책만 읽어서는 이해하기 어렵다"고 했다. 나중에 더 경험이 쌓이면 다시 읽을 생각이다. 지금 읽기엔 시기상조였다. 별점 2점은 내 수준의 문제지 책이 나빠서가 아니다.
읽다가 막혔다면 당신의 문제가 아니라 시점의 문제다. 일단 덮어라.
BOOK 07
테스트 주도 개발 (TDD)
★★★★★
TDD를 쓰지 않는 지금도 이 책에서 얻은 게 크다. "작게 쪼개고, 빠르게 검증하고, 리팩터링하라"는 사이클 자체가 개발 방식을 바꿔놨다. 테스트 코드 자체보다 그 뒤에 있는 설계 철학이 핵심이다. 팀에서 테스트 문화가 없어서 직접 적용은 못 했지만, 함수 설계가 단순해지는 데 영향을 줬다.
"빨간 불, 초록 불, 리팩터링. 이 세 단계가 전부다."
BOOK 08
읽기 좋은 코드가 좋은 코드다
★★★★★
클린 코드의 가벼운 버전 같은 느낌이다. 얇고 예제가 많아서 읽기 편하다. 변수명, 주석, 함수 구조를 구체적인 예시로 설명해준다. 클린 코드가 무겁게 느껴진다면 이것부터 읽기를 권한다. 이미 클린 코드를 읽었다면 비슷한 내용이라 새로운 게 많지 않을 수 있다.
"코드는 다른 사람이 이해하기 쉽도록 작성되어야 한다. 그 사람이 6개월 뒤의 나일 수도 있다."
BOOK 09
개발자의 글쓰기
★★★★★
10권 중 유일하게 "코딩"이 아닌 "글쓰기"에 관한 책인데 여기 넣은 이유가 있다. 기술 문서, README, PR 설명, 커밋 메시지를 잘 쓰는 것이 개발자의 핵심 역량이라는 걸 이 책이 설득력 있게 말해줬다. 기술 블로그를 시작한 계기가 됐다. 코딩 실력과 글쓰기 실력은 별개가 아니다.
"코드 자체가 문서다. 하지만 코드가 설명할 수 없는 '왜'는 글이 해야 한다."
BOOK 10
The Pragmatic Programmer (원서)
★★★★★
한국어판 "실용주의 프로그래머"를 이미 읽었는데, 원서로 다시 읽었다. 번역본에서 뉘앙스가 달라지는 부분들이 있었다. 원서를 읽을 수 있는 수준이라면 원서를 권한다. 20주년 기념 2판은 클라우드, 함수형 프로그래밍 등 현대적인 내용이 추가됐다. 동일 저자의 책을 두 번 다 별점 5점 준 건 이 책뿐이다.
"Provide Options, Don't Make Lame Excuses. 변명 대신 대안을 제시하라."
읽고 나서 실제로 달라진 것들
10권을 읽고 나서 "이제 코드를 잘 짜겠다"는 기대는 반쯤 맞고 반쯤 틀렸다. 코딩 속도가 갑자기 빨라진 건 아니었다. 대신 이런 것들이 달라졌다.
CHANGE 01
나쁜 코드를 볼 때 말로 설명할 수 있게 됐다
전에는 "이 코드 왠지 별로"였다면, 이제는 "함수가 두 가지 일을 하고 있어서 단일 책임 원칙에 어긋난다"고 말할 수 있다. 코드 리뷰에서 말문이 트였다.
CHANGE 02
변수명과 함수명에 시간을 더 쓰게 됐다
클린 코드를 읽은 후 가장 바뀐 행동이다.
data, res, tmp 대신 의도가 드러나는 이름을 고민하는 데 2~3분을 쓴다. 처음엔 느렸는데 지금은 습관이 됐다.CHANGE 03
기술 부채를 감지하는 감각이 생겼다
레거시 코드를 볼 때 "이 코드가 왜 이렇게 됐는지"를 추측할 수 있게 됐다. 리팩터링 책이 가장 큰 기여를 했다. 고치기 전에 이해가 먼저라는 것도 여기서 배웠다.
CHANGE 04
기술 선택에 근거가 생겼다
"이게 있어 보여서"가 아니라 "이 문제에는 이 접근이 맞는 이유"를 말할 수 있게 됐다. 면접에서 기술 선택 이유를 물을 때 막히지 않게 된 것도 이 덕분이다.
"책을 읽는다고 코드가 바로 좋아지지는 않는다. 그런데 나쁜 코드를 보는 눈이 생기면, 자기 코드도 다르게 보이기 시작한다."
— 10권 독파 후 메모연차별 추천 독서 순서
개발 서적을 읽고 싶은데 어디서 시작해야 하는지 모르는 분들을 위해 내 경험을 바탕으로 순서를 정리했다. 이건 정답이 아니라 내가 다시 시작한다면 선택했을 순서다.
| 시점 | 추천 책 | 이유 | 난이도 |
|---|---|---|---|
| 취준 / 입사 직전 | 함께 자라기 → 실용주의 프로그래머 | 마인드셋 먼저. 기술보다 태도가 첫 직장 적응에 더 영향을 준다 | 쉬움 |
| 입사 후 1년 차 | 클린 코드 → 읽기 좋은 코드가 좋은 코드다 | 코드 리뷰를 받기 시작하는 시점. 지적받는 것들의 언어가 여기 있다 | 보통 |
| 2~3년 차 | 리팩터링 2판 → TDD → 소프트웨어 장인 | 기술 부채를 처음 실감하는 시기. 개선 방법과 커리어 방향을 같이 고민할 때 | 어려움 |
| 3년차 이상 | DDD → 원서로 다시 읽기 | 설계와 도메인 이해가 필요한 시점. 실무 경험이 쌓인 후 읽어야 흡수된다 | 매우 어려움 |
책만 읽어서는 안 되는 이유
10권을 읽으면서 가장 크게 깨달은 것 중 하나가 아이러니하게도 이것이었다.
⚠️
책 읽기의 함정 — 나도 빠졌다
읽는 동안은 "이해했다"는 느낌이 든다. 그런데 책을 덮으면 코드는 그대로다. 리팩터링 책을 다 읽고 나서 실제로 레거시 코드를 리팩터링해보기 전까지, 아는 것과 할 수 있는 것이 달랐다. 책은 지도다. 지도를 읽는다고 여행을 한 게 아니다.
읽는 동안은 "이해했다"는 느낌이 든다. 그런데 책을 덮으면 코드는 그대로다. 리팩터링 책을 다 읽고 나서 실제로 레거시 코드를 리팩터링해보기 전까지, 아는 것과 할 수 있는 것이 달랐다. 책은 지도다. 지도를 읽는다고 여행을 한 게 아니다.
✅
책을 200% 활용하는 방법 — 내가 지금 하는 것
① 챕터를 읽은 직후, 지금 내 코드에서 해당 내용이 적용된 부분과 안 된 부분을 찾는다
② 인상적인 개념을 블로그나 노션에 내 말로 다시 쓴다 (쓰면서 빈 곳이 드러난다)
③ 팀원에게 "이 책에서 이런 내용을 읽었는데 우리 코드에선 어떻게 생각해요?" 를 물어본다
④ 한 권 다 읽고 3개월 후에 다시 훑는다. 처음엔 몰랐던 게 보인다
① 챕터를 읽은 직후, 지금 내 코드에서 해당 내용이 적용된 부분과 안 된 부분을 찾는다
② 인상적인 개념을 블로그나 노션에 내 말로 다시 쓴다 (쓰면서 빈 곳이 드러난다)
③ 팀원에게 "이 책에서 이런 내용을 읽었는데 우리 코드에선 어떻게 생각해요?" 를 물어본다
④ 한 권 다 읽고 3개월 후에 다시 훑는다. 처음엔 몰랐던 게 보인다
6개월, 10권. 생각보다 많이 바뀌었다. 코드 실력이 확 오른 게 아니라, 코드를 바라보는 관점이 생겼다. 그게 더 오래가는 변화인 것 같다. 11번째 책은 이미 사놨다. 이번엔 조금 더 천천히 읽을 생각이다.
📚 여러분이 가장 도움 받은 개발 서적은 뭔가요?
10권 목록에서 이미 읽은 책이 있다면 어떠셨는지, 혹은 "이건 왜 목록에 없냐"는 책이 있다면 댓글로 알려주세요. 특히 프론트엔드 개발자에게 특화된 책 추천도 반깁니다. 다음 읽을 책 후보로 진지하게 고려할게요. 🙏
'개발자 > 성장 학습' 카테고리의 다른 글
| 1년간 기술 블로그가 내게 한 것, 조회수 34에서 68,000으로 (0) | 2026.06.23 |
|---|---|
| 사이드 프로젝트가 내 개발자 커리어를 바꾼 이야기 (1) | 2026.06.16 |
| 개발자 1년차와 3년차, 달라진 것들 — 솔직하게 써봤습니다 (0) | 2026.06.09 |
