[책리뷰] 프로그램을 읽는 기술

 

AI가 코드를 쓰는 시대, 개발자의 경쟁력은 ‘읽기’다

요즘은 “코드를 어떻게 쓰지?”보다 “이 코드가 정확히 뭘 하고, 어디까지 영향을 미치지?”가 더 무서운 질문이 됐다.
AI가 코드 생산량을 폭발적으로 늘려준 덕분에, 역설적으로 우리가 마주하는 현실은 이거다:

• 작성 속도는 빨라졌는데
• 검증·이해·책임의 속도는 그대로다
• 그래서 병목은 결국 ‘읽기’에서 터진다

『프로그램을 읽는 기술』은 바로 이 병목을 정면으로 다루는 책이다. 책 소개 문구 자체가 요즘 개발자 마음을 찌른다. “AI가 코드를 대신 쓰는 시대, 개발자의 경쟁력은 읽기”라는 메시지를 전면에 내세운다.

 

이 책이 말하는 ‘읽기’는 “한 줄 해석”이 아니다

많은 사람이 코드 리딩을 “남이 짜놓은 코드를 한 줄씩 따라가는 일”로 오해한다.
그런데 실무에서 진짜 필요한 건 한 줄 해석이 아니라:

• 프로그램의 목적
• 구조(큰 흐름)
• 입력→처리→출력
• 변경 영향 범위
• 리스크(버그/성능/보안/운영)

이 책은 그걸 ‘기술’로 다룬다. 특히 “버그 수정, 사양 변경, 코드 리뷰” 같은 실무의 대부분이 결국 읽기에서 시작된다는 점을 강조한다.

 

핵심 프레임: 입력 → 처리 → 출력으로 “전체를 먼저” 잡는다

책에서 반복적으로 나오는 축은 단순하다.

프로그램은 결국 입력을 받아 처리하고 출력한다.

그리고 이 프레임을 “전체 프로그램”에도 적용하고, “함수/모듈/클래스” 같은 더 작은 단위에도 반복 적용하면서 읽어 들어간다. 한 번에 디테일로 뛰어들지 말고, 큰 지도를 먼저 만든 뒤 확대하라는 접근이다.

이 방식이 좋은 이유는 딱 하나다.
코드 이해에서 가장 흔한 실패는 “디테일은 봤는데, 전체 의도를 놓치는 것”이기 때문이다.

AI가 생성해준 코드가 특히 그렇다. 그럴듯한 디테일은 촘촘한데, 맥락이 비거나(요구사항 누락), 설계 의도가 엇나가거나(경계조건/에러처리), 팀 규칙을 어기거나(레이어링/의존성) 하는 경우가 많다.
결국 사람은 다시 ‘전체→세부’로 읽으며 판단해야 한다.

 

“남의 코드가 어려운 이유”를 원인부터 정리해준다

이 책이 유용한 지점 중 하나는, 남의 코드가 어려운 이유를 감각적인 하소연으로 끝내지 않고 요인으로 분해한다는 점이다.
설계 사고 방식, 언어, 함수 구성 방식, 네이밍, 주석, 입력/출력 관점 등… “읽기 어려워지는 지점”을 꽤 현실적으로 짚는다.

이게 왜 중요하냐면, 원인을 알면 대처가 바뀌기 때문이다.

• 네이밍/주석 문제면 “추적(tracing)”보다 “의미 복원(meaning reconstruction)”이 먼저고
• 설계 사고방식 차이면 “한 줄 독해”보다 “모듈 경계와 책임”부터 다시 잡아야 한다

읽기는 감이 아니라 전략이 된다.

 

읽기 전에 해야 할 일: 문서/사양/실행/질문하기

책 목차를 보면, “읽기 전에 해야 할 일”을 꽤 크게 다룬다.
문서 찾기, 외부 사양/상세 설계 읽기, 작성자에게 묻기, 실제로 실행해 보기 같은 것들.

이 부분이 특히 AI 시대에 더 중요해졌다고 느낀다.

AI가 만들어준 코드는 “동작하는 코드”일 수는 있어도, “요구사항에 맞는 코드”인지는 별개의 문제다.
그래서 코드 리딩을 시작하기 전에 반드시 확인해야 한다:

• 이 코드는 무엇을 만족시켜야 하지? (요구사항/사양)
• 무엇을 절대 깨면 안 되지? (불변조건/계약)
• 어디에 붙는 코드지? (시스템 경계)

읽기는 파일을 여는 순간 시작되는 게 아니라, 맥락을 확보하는 순간 시작된다.

 

예제로 ‘독해 훈련’을 시킨다: 쉬운 것부터 실무까지

출판사/판매 페이지 소개를 보면, 간단한 게임 예제에서 시작해 점점 더 실무에 가까운 예제로 확장하는 구성이라고 한다.
이런 구성의 장점은 명확하다.

• “아~ 이론은 알겠는데…”에서 끝나는 게 아니라
• “그래서 실제 코드를 어떤 순서로 보라고?”를 손으로 따라가게 만든다

코드 리딩은 근력운동에 가깝다.
방법을 아는 것과, 실제로 눈이 그 순서를 따라가는 건 다른 얘기다.

 

이 책의 메시지: “많이 읽으면, 더 잘 쓰게 된다”

내가 이 책을 리뷰에서 꼭 강조하고 싶은 문장이 있다.
요지는 이거다:

• 프로그램을 많이 읽으면 전체를 더 효율적으로 보게 되고
• 그 과정이 결국 작성 실력도 끌어올린다
• 특히 공개된 좋은 코드(예: 라이브러리/모듈)를 읽는 경험이 큰 자산이 된다

이건 AI 시대에도 그대로다. 아니, 더 강해졌다.

AI가 초안을 써주면 개발자는 “작가”가 아니라 “편집자/감수자/아키텍트/심사위원” 역할을 더 많이 하게 된다.
그 역할의 핵심은 결국 읽고 판단하는 능력이다.

 

개발자 입장에서 정리한 “AI 시대 코드 리딩 체크리스트”

책의 프레임(전체→세부, 입력→처리→출력)을 개발자 언어로 바꾸면 이렇게 정리된다.

1) 5분: 지도 만들기 (전체 구조)

• 이 코드의 입력은 무엇인가? (API request, 이벤트, 파일, DB row…)
• 최종 출력은 무엇인가? (응답, 상태 변경, 메시지 발행…)
• 핵심 처리 단계는 어디에 나뉘어 있나?
• 부작용(side effect)은 어디서 발생하나? (DB/캐시/외부 API/파일)

2) 15분: 데이터 흐름 추적 (중간 단위)

• 핵심 데이터가 어떤 형태로 들어와서 어떤 형태로 나가는가?
• 검증/정규화는 어디서 하는가?
• 에러는 어디서 발생하고, 어디서 잡히는가?
• 경계조건(빈 값/최대값/타임아웃/중복 요청)을 어떻게 처리하는가?

3) 10분: 변경 영향 범위 찾기 (실무 단위)

• 이 코드를 바꾸면 영향받는 호출부/저장소/스키마는?
• 테스트는 무엇이 있고, 무엇이 비어 있나?
• 로그/메트릭/트레이싱은 충분한가?
• 운영 사고 시 “어디를 보면” 원인을 찾을 수 있나?

AI가 생성한 코드일수록 3번이 진짜 중요하다.
왜냐하면 “동작”은 해도 “운영 가능한 형태”가 아닐 때가 많기 때문이다.

 

AI를 쓰되, ‘읽기’를 대체시키진 말자

AI는 코드 리딩을 도와주는 훌륭한 보조자다. 하지만 대체자는 아니다.
내가 요즘 가장 자주 쓰는 패턴은 이런 프롬프트들이다(그 다음은 반드시 내가 직접 확인).

• “이 함수의 입력/출력/부작용을 5줄로 요약해줘”
• “이 로직에서 깨지기 쉬운 경계조건을 뽑아줘”
• “이 변경이 시스템에 줄 수 있는 영향 범위를 추정해줘”
• “테스트 케이스를 설계해줘(정상/실패/경계)”
• “이 코드가 지키는 불변조건을 문장으로 써줘”

책이 말하는 메시지와도 정확히 맞물린다.
AI가 코드를 만들어주는 시대에도 최종 판단과 책임은 사람에게 있다.

 

추천 대상

이 책은 난이도를 “관계없음”으로 표기하고 있고, 분량도 192쪽으로 부담이 크지 않은 편이다.
그래서 추천 범위가 넓다.

• 신입/주니어: “코드가 왜 이렇게 읽기 어렵지?”에 대한 정리된 관점이 필요할 때
• 실무 개발자: 버그 수정/사양 변경/리뷰를 하면서 “읽는 시간이 너무 길다”고 느낄 때
• AI 코딩을 적극적으로 쓰는 팀: 생성된 코드를 빠르게 판독하고 책임 있게 머지해야 할 때

 

마무리: 앞으로 더 중요한 건 ‘쓰는 손’보다 ‘읽는 눈’

AI 덕분에 우리는 더 많은 코드를 더 빠르게 만들 수 있게 됐다.
그런데 그 말은 곧, 우리가 읽고 판단해야 할 코드도 더 많아졌다는 뜻이다.

『프로그램을 읽는 기술』이 좋은 점은, 이 현실을 정신론으로 끝내지 않고 “그럼 어떻게 읽을 건데?”라는 질문에 절차와 프레임으로 답해준다는 데 있다. 특히 입력→처리→출력이라는 단순한 틀로 전체와 세부를 오가며 독해하는 접근은, AI 시대에 더 강력한 기본기가 된다.

결국 개발자의 경쟁력은 점점 이렇게 재정의되는 것 같다.

코드를 잘 쓰는 사람 → 코드를 잘 읽고, 잘 판단하고, 잘 책임지는 사람