내 코드가 불안한 개발자를 위한 좋은 코드의 기준

코딩의 시대는 가고, 코드 관리의 시대가 왔다!
AI가 코드를 대신 작성해 주는 시대. 이제 개발자의 경쟁력은 '얼마나 빨리 짜느냐'가 아니라 '어떤 코드를 선택하느냐'에 달려 있습니다. 기능은 돌아가지만 어딘가 불안한 코드, 조금만 수정해도 버그가 터지고 점점 고치기 어려워지는 코드. 결국 문제는 '구현'이 아니라 '기준'입니다.
이 책은 단순히 '클린 코드' 작성법을 나열하지 않습니다. 대신 AI 시대에도 변하지 않는 좋은 코드의 기준을 세워줍니다. 가독성과 유지보수성, 설계, 협업까지, 어떤 언어를 쓰든 통용되는 원칙을 통해 내일도 고칠 수 있는 코드를 만드는 방법을 알려줍니다.

★ AI 시대에도 변치 않는 '유지보수성'의 핵심 원칙
트렌드가 바뀌어도 변하지 않는 소프트웨어 개발의 '기본'에 집중합니다. 특정 기술의 사용법을 나열하는 것이 아니라, 왜 좋은 코드를 작성해야 하는지, 어떻게 하면 변경에 유연한 구조를 만들 수 있는지에 대한 근본적인 해답을 제시합니다.

★ 나쁜 코드 vs 좋은 코드, 명확한 비교를 통한 실전 가이드
추상적인 이론 설명에 그치지 않고, 구체적인 예제 코드를 통해 '읽기 어려운 코드'와 '의도가 명확한 코드'를 직접 비교합니다. 코틀린(Kotlin)으로 작성된 예제를 사용하지만, 자바나 파이썬 등 다른 언어를 사용하는 개발자도 충분히 이해하고 적용할 수 있도록 '코드의 의도와 구조'에 집중하여 설명합니다.

★ 코드 한 줄부터 팀 문화까지, 개발 전 과정을 커버
변수 명명법과 주석 작성 같은 미시적인 영역부터 클래스와 모듈 분할, 아키텍처 설계, 테스트 자동화 그리고 코드 리뷰와 Git을 활용한 협업까지, 소프트웨어 품질을 높이기 위해 필요한 모든 단계를 폭넓게 다룹니다.

★ [스페셜] 예제 파일을 통해 생성형 AI와 함께하는 인터랙티브 학습
이 책의 예제는 단순히 따라 치고 실행하는 코드가 아닙니다. 나쁜 코드와 좋은 코드를 비교하며 스스로 생각하는 힘을 기르기 위한 재료입니다. 코드를 직접 다루며 깊이 있게 학습하고 싶은 독자분들을 위해 책에 수록된 코드를 한곳에 모아 노트북 파일(good_codes.ipynb)로 제공합니다.
챗GPT나 제미나이(Gemini)와 같은 생성형 AI에게 "이 코드는 왜 읽기 어려운가?", "더 나은 구조는 무엇인가?"라고 질문을 던져보세요. AI의 답변을 책의 원칙과 비교·분석하는 과정에서 '코드 선별력'을 기를 수 있습니다. AI를 쓸수록 실력이 약해지는 개발자가 아니라, AI를 쓸수록 판단력이 단단해지는 개발자로 성장하세요.

- 이 책의 구성 -
이 책은 총 11장으로 구성되어 있으며, 좋은 코드를 작성하기 위한 여정을 단계별로 안내합니다.

ㆍ 1장: 왜 좋은 코드를 작성해야 할까? - 유지보수성의 가치와 기술 부채의 위험성을 이해하고, 좋은 코드가 왜 개발 속도를 높이는지 설명합니다.

ㆍ 2장~4장: 읽기 쉽고 명확한 코드 만들기 - 의도를 드러내는 이름 짓기, 도메인 지식 표현, 그리고 함수와 클래스를 적절히 나누어 복잡도를 낮추는 방법을 배웁니다.

ㆍ 5장~6장: 유연한 구조와 핵심 원칙 - 얽혀 있는 의존 관계를 풀고 결합도를 낮추는 기법과 KISS, YAGNI, DRY 등 개발자가 반드시 알아야 할 프로그래밍 원칙을 다룹니다.

ㆍ 7장~8장: 견고한 코드와 리팩터링 - 매직 넘버 피하기, 불변성 활용 등 실수를 방지하는 테크닉과 기존 코드를 안전하게 변경하는 리팩터링 노하우를 소개합니다.

ㆍ 9장: 아키텍처 고민하기 - 계층화 아키텍처, 클린 아키텍처 등 전체적인 구조를 설계하는 방법과 모듈 분할 전략을 살펴봅니다.

ㆍ 10장~11장: 품질을 지키는 안전장치 - 자동화 테스트 작성법과 Git 버전 관리, 코드 리뷰 등 팀 단위로 품질을 유지하는 방법을 안내합니다.

이런 분께 추천!
● AI가 짜준 코드를 그대로 써도 될지 항상 불안한 개발자
● 일단 돌아가게는 만들었는데, 올바른 피드백과 성장에 목마른 홀로서기 개발자
● 유지보수하기 좋은 구조를 처음부터 제대로 설계하고 싶은 예비 아키텍트
● 팀 코드의 기준을 맞추고 생산성을 끌어올리고 싶은 리더급 개발자
● 레거시 코드를 보며 한숨 쉬기보다 개선할 방법을 찾고 싶은 모든 엔지니어

들어가며
1장 왜 좋은 코드를 작성해야 할까?
__1.1 소프트웨어의 가치
__1.2 유지보수성과 속도
__1.3 기술 부채 발생과 소멸
__1.4 좋은 코드를 작성하려면

2장 움직이는 코드에서 뜻을 전하는 코드로
__2.1 의도 표현하기
__2.2 이름으로 전하기
__2.3 주석으로 보충하기
__2.4 코드로 도메인 지식 표현하기

3장 큰 문제는 나누어 생각하기
__3.1 함수와 클래스 나누기
__3.2 자세히 읽지 않아도 사용할 수 있게
__3.3 코드 복잡도 계산하기
__3.4 응집도 높이기

4장 코드 정리하기
__4.1 디렉터리 단위로 정리하기
__4.2 모듈 단위로 정리하기

5장 얽힌 의존 관계 풀기
__5.1 의존 관계 의식하기
__5.2 의존 방향 검토하기
__5.3 추상에 의존하도록 하기
__5.4 결합도 낮추기

6장 좋은 코드 작성 원칙과 교훈
__6.1 KISS 원칙: 간단하게 유지하기
__6.2 YAGNI 원칙: 필요할 때 비로소 구현하기
__6.3 DRY 원칙: 중복 지식 줄이기
__6.4 바퀴 재발명: 같은 것 만들지 않기
__6.5 망치를 든 사람에게는 모든 것이 못처럼 보인다
__6.6 은 탄환은 없다

7장 어이없는 실수를 안 하려면
__7.1 매직 넘버 피하기
__7.2 자료형 제한 활용하기
__7.3 변경할 수 없는 데이터 사용하기
__7.4 데이터는 한곳에서 관리하기
__7.5 상태 변경과 정보 조회 분리하기

8장 코드는 작성보다 변경이 더 어렵다
__8.1 보이 스카우트 규칙: 왔을 때보다 더 깨끗하게
__8.2 백지상태에서 코드 바라보기
__8.3 조금씩 수정하기
__8.4 필요 없어진 코드 삭제하기

9장 아키텍처 고민하기
__9.1 계층 정리하기
__9.2 계층 구성 아이디어
__9.3 기능을 바탕으로 나누기
__9.4 아키텍처를 생각한다는 것

10장 파괴를 막는 자동화 테스트
__10.1 수동 테스트의 한계와 자동화
__10.2 자동화 테스트의 종류
__10.3 단위 테스트 만들기
__10.4 의존 코드를 테스트 대역으로 바꾸기
__10.5 테스트 커버리지 측정하기
__10.6 통합 테스트/E2E 테스트

11장 팀이 만드는 좋은 코드
__11.1 Git으로 버전 관리하기
__11.2 코드 리뷰하기
__11.3 코딩 규약 정하기
__11.4 자동으로 확인하기
__11.5 설계서 만들기

마치며
참고 문헌
찾아보기

모리 아츠시 야마구치현에서 태어나 효고현에서 유년 시절을 보냈습니다. 아카시 공업고등전문학교에 입학하여 프로그래밍을 배웠으며, 다수의 프로그래밍 콘테스트에서 입상하는 과정에서 지속적인 개발의 어려움과 그 소중함을 깨달았습니다. 현재는 LY Corporation 소속의 안드로이드 앱 엔지니어로, 커뮤니케이션 앱 LINE의 안드로이드 버전 개발에 참여하고 있습니다. 2019년도 미토 IT 인재 발굴·육성 사업(MITOU)의 슈퍼 크리에이터로 선정된 바 있습니다.