본문 바로가기
개발자/멘탈 라이프스타일

개발자가 독서를 시작한 이유와 추천 도서

by 나무011 2026. 9. 1.
개발자 현직자 솔직 경험담

개발자가 독서를 시작한 이유와 추천 도서

"기술 서적만 읽으면 되는 줄 알았다"는 착각이 깨진 순간, 그리고 실제로 도움이 된 책 다섯 권.

입사 2년 차까지는 책을 거의 안 읽었다. 정확히는 "읽긴 읽었는데" 전부 기술 서적이었다. Next.js 공식 문서, 클린 코드, 이펙티브 타입스크립트 같은 책들. 그것만으로도 충분히 성장한다고 생각했다. 근데 어느 날 팀 회고 시간에 받은 피드백 하나가 그 생각을 완전히 흔들었다.

개발자가 독서를 시작한 이유와 추천 도서
개발자가 독서를 시작한 이유와 추천 도서
0권입사 2년 차까지 읽은 비기술서
23권이후 1년간 읽은 책 수
5권실제로 업무에 도움된 책

1. 계기가 된 피드백 — "설명을 잘 못하시네요"

새 기능 스펙을 팀에 공유하는 자리였다. 나는 기술적으로는 완벽하게 이해하고 있었는데, 발표가 끝난 후 동료가 이런 말을 했다.

동료 내용은 이해했는데, 솔직히 설명 순서가 좀 헷갈렸어요. 결론부터 말씀하시고 근거를 붙이시면 훨씬 이해하기 쉬울 것 같아요.
아... 제가 아는 걸 그냥 순서대로 말한 것 같아요. 생각해볼게요.

이 피드백을 듣고 처음엔 "말하는 스타일 문제겠지"라고 넘겼다. 근데 비슷한 지적이 코드 리뷰 코멘트, 문서 작성, 심지어 슬랙 메시지에서도 반복됐다. 기술은 늘고 있는데, 그걸 전달하는 능력은 전혀 늘지 않고 있다는 걸 그제야 인정하게 됐다.

⚠ 그때 깨달은 것 개발자에게 필요한 건 기술 지식만이 아니라, 그 지식을 다른 사람이 이해할 수 있게 구조화해서 전달하는 능력이었다. 이건 기술 서적으로는 채워지지 않는 영역이었다.

2. 처음엔 억지로 시작했다 — 습관이 되기까지

처음엔 동기부여가 크지 않아서 작심삼일을 몇 번 반복했다. 그러다 방법을 바꿨다. 퇴근 후 거창하게 읽으려 하지 않고, 출퇴근 지하철에서 하루 딱 10페이지만 읽기로 규칙을 정했다.

1개월 차
첫 책을 완독하는 데 3주가 걸렸다. 속도보다 "완독 경험" 자체에 의미를 두기로 했다.
3개월 차
한 달에 2권 정도 페이스가 잡히면서, 지하철에서 스마트폰 대신 책을 펼치는 게 자연스러워졌다.
6개월 차
회의에서 의견을 낼 때 "결론-근거" 구조로 말하는 습관이 생겼다는 걸 스스로 느꼈다.
12개월 차
누적 23권. 기술서 5권, 커뮤니케이션·글쓰기 관련 책 9권, 그 외 인문/에세이 9권으로 자연스럽게 균형이 잡혔다.

3. 실제로 도움이 됐던 책 다섯 권

23권 중에서 업무에 실질적인 변화를 만들어준 책만 추려봤다. 개발 서적이 아니라, 오히려 생각을 정리하고 전달하는 능력에 초점을 맞춘 책들이 많았다.

01
글쓰기의 감각
앤 라모트
완벽한 첫 문장에 대한 강박을 내려놓게 해준 책. 기술 문서나 PR 설명을 쓸 때 "일단 초안부터 쓰고 다듬는다"는 태도로 바뀌었다.
02
바바라 민토, 논리의 기술
바바라 민토
동료가 지적했던 "결론부터 말하기"가 정확히 이 책의 핵심 내용이었다. 스펙 문서와 회의 발언 구조를 바꾸는 데 가장 직접적인 도움을 준 책.
03
비폭력대화
마셜 로젠버그
코드 리뷰 코멘트를 쓸 때 "이거 왜 이렇게 짜셨어요?" 대신 "이 부분이 이렇게 동작하는 이유가 궁금해요"로 표현을 바꾸게 된 계기.
04
생각에 관한 생각
대니얼 카너먼
기술적 의사결정에서도 직관에만 의존하지 않고, 스스로의 판단이 편향될 수 있다는 걸 자각하는 데 도움이 됐다.
05
인간 실격
다자이 오사무
업무와 직접 관련은 없지만, 매일 논리적인 코드만 다루다가 인간의 비합리성과 감정을 깊이 들여다보는 시간이 오히려 균형을 잡아줬다.

4. 독서가 실제 코드 리뷰 방식을 바꾼 순간

가장 체감이 컸던 변화는 코드 리뷰 코멘트를 쓰는 방식이었다. 예전에는 지적할 부분만 나열했는데, 논리 구조와 커뮤니케이션 관련 책을 읽고 나서는 순서 자체를 바꾸게 됐다.

// Before: 지적만 나열 // "이 함수 너무 길어요. 분리하세요. 네이밍도 애매해요." // After: 결론 → 근거 → 제안 순서로 재구성 function writeReviewComment() { return { conclusion: "이 함수를 두 개로 나누면 좋을 것 같아요.", reason: "현재 데이터 fetch와 렌더링 로직이 섞여 있어서, 테스트하기 어려워 보여요.", suggestion: "useProductList 훅으로 분리하면 재사용도 가능할 것 같아요.", }; }

같은 지적이라도 구조를 바꾸니 상대방이 방어적으로 받아들이지 않는다는 걸 확실히 느꼈다. 기술 실력은 그대로였지만, 전달 방식이 바뀌자 협업의 질 자체가 달라졌다.

독서 시작 전
지적 나열형
코드 리뷰가 자주 논쟁으로 번짐
1년 후
결론-근거-제안 구조
같은 지적도 훨씬 부드럽게 전달됨
독서 시작 전 — 의사 전달 자신감4 / 10
 
6개월 후 — 의사 전달 자신감6.5 / 10
 
1년 후 — 의사 전달 자신감8 / 10
 
1년 후 결론

기술 서적만으로는 채워지지 않는 영역이 분명히 있었다. 코드를 잘 짜는 것과, 그 코드에 대해 잘 설명하는 것은 완전히 다른 능력이었고, 후자는 오히려 비기술 서적을 통해 훨씬 빠르게 성장했다.

💡 시작하려는 분들에게 처음부터 어려운 고전이나 두꺼운 책으로 시작하면 금방 지친다. 가볍게 읽을 수 있는 커뮤니케이션·글쓰기 책부터 시작해서 완독 경험을 쌓은 다음, 조금씩 범위를 넓혀가는 게 훨씬 오래 갔다.
"좋은 코드를 짜는 것과, 그 코드를 설명하는 것은 완전히 다른 근육이었다."
2026년 현재 사내 스터디나 개발자 커뮤니티에서도 기술 서적 외에 논리적 글쓰기, 커뮤니케이션 관련 책을 함께 다루는 북클럽이 늘고 있다는 이야기를 자주 듣는다. 다만 독서 취향과 필요한 영역은 사람마다 다르니, 위 목록은 참고 자료로만 활용하고 본인 상황에 맞는 책을 찾아가는 걸 추천한다.

결론

기술 서적만 읽으면 충분하다고 생각했던 게 가장 큰 착각이었다. 실제로 커리어에 변화를 만든 건 논리적으로 생각을 정리하고 전달하는 능력이었고, 그건 기술이 아닌 다른 종류의 책들에서 채워졌다. 지금 비슷한 벽을 느끼고 있는 개발자가 있다면, 다음 기술 서적 대신 커뮤니케이션이나 글쓰기 관련 책 한 권을 먼저 집어보길 권하고 싶다.

여러분에게 도움이 된 책이 있나요?

개발자로 일하면서 읽고 실제로 도움이 됐던 책이나, 독서를 시작하게 된 계기가 있다면 댓글로 공유해주세요. 지금 막 독서 습관을 만들어가는 다른 개발자분들께 큰 도움이 될 것 같습니다.


소개 및 문의 · 개인정보처리방침 · 면책조항

© 2026 나무핀