이 장에서는 앞으로 만들 시스템의 전체 그림부터 확인한다.
절 9개 보기
- 1.1 이 장의 목표
- 1.2 완성 모습
- 1.3 처음부터 서비스 하나로 만들지 않는 이유
- 1.4 REST란
- 1.5 gRPC란
- 1.6 이 책에서의 역할 분담
- 1.7 curl의 역할
- 1.8 Claude Code는 어디에 들어가는가
- 1.9 이 장의 정리
첫 Spring Boot 애플리케이션을 띄우고 curl로 Hello World를 확인하는 데까지 간다.
절 11개 보기
- 2.1 이 장의 목표
- 2.2 Java 17 확인하기
- 2.3 Maven이란
- 2.4 Spring Initializr로 프로젝트 만들기
- 2.5 Spring Boot 띄우기
- 2.6 Hello World Controller 만들기
- 2.7 curl로 호출하기
- 2.8 JSON 반환해 보기
- 2.9 Controller / Service / Repository
- 2.10 Claude Code는 어디를 지원할 수 있나
- 2.11 이 장의 정리
사용자 정보를 다루는 REST API를 만든다.
절 12개 보기
- 3.1 이 장의 목표
- 3.2 User를 record로 표현하기
- 3.3 Service 만들기
- 3.4 GET /users
- 3.5 GET /users/{id}
- 3.6 POST /users
- 3.7 HTTP 상태 코드
- 3.8 Validation
- 3.9 예외 처리를 한곳에 모으기
- 3.10 REST API의 계약
- 3.11 Claude Code 포인트
- 3.12 이 장의 정리
지금까지 하나였던 애플리케이션을 api-service와 user-service 두 개로 나눈다.
절 11개 보기
- 4.1 이 장의 목표
- 4.2 왜 나누는가
- 4.3 디렉터리 구성
- 4.4 포트 나누기
- 4.5 user-service 만들기
- 4.6 api-service 만들기
- 4.7 서비스마다 DB를 갖는다는 발상
- 4.8 서비스 경계는 업무 기준으로 생각한다
- 4.9 나누면 새로운 문제가 생긴다
- 4.10 Claude Code 포인트
- 4.11 이 장의 정리
api-service에서 user-service를 REST로 호출한다.
절 11개 보기
- 5.1 이 장의 목표
- 5.2 user-service의 API
- 5.3 RestClient 쓰기
- 5.4 UserServiceClient 만들기
- 5.5 api-service에서 호출하기
- 5.6 상대가 죽어 있으면 어떻게 되나
- 5.7 타임아웃
- 5.8 재시도
- 5.9 REST의 장점
- 5.10 Claude Code 포인트
- 5.11 이 장의 정리
지금까지 REST로 하던 api-service -> user-service 통신을 gRPC로도 구현한다.
절 13개 보기
- 6.1 이 장의 목표
- 6.2 gRPC의 기본
- 6.3 .proto 작성하기
- 6.4 코드 생성
- 6.5 gRPC Server
- 6.6 gRPC Client
- 6.7 grpcurl로 확인하기
- 6.8 gRPC도 네트워크 통신이다
- 6.9 데드라인
- 6.10 스트리밍
- 6.11 REST와 gRPC 비교
- 6.12 Claude Code 포인트
- 6.13 이 장의 정리
외부용 REST와 내부용 gRPC를 조합한다.
절 9개 보기
- 7.1 이 장의 목표
- 7.2 왜 입구를 REST로 하는가
- 7.3 왜 내부를 gRPC로 하는가
- 7.4 Facade란
- 7.5 REST DTO와 gRPC Message는 분리한다
- 7.6 내부 변경으로부터 외부 계약 지키기
- 7.7 API Gateway와 Facade
- 7.8 Claude Code 포인트
- 7.9 이 장의 정리
"두 서비스가 통신했다"에서 끝내지 않고 분산 시스템 특유의 문제를 이해한다.
절 12개 보기
- 8.1 이 장의 목표
- 8.2 부분 장애
- 8.3 타임아웃
- 8.4 재시도
- 8.5 서킷 브레이커
- 8.6 멱등성
- 8.7 분산 트랜잭션
- 8.8 사가
- 8.9 트랜잭셔널 아웃박스
- 8.10 관측 가능성
- 8.11 Claude Code 포인트
- 8.12 이 장의 정리
REST / gRPC / 서비스 간 통신을 안전하게 변경할 수 있도록 테스트를 정리한다.
절 12개 보기
- 9.1 이 장의 목표
- 9.2 단위 테스트
- 9.3 Mockito
- 9.4 Controller 테스트
- 9.5 gRPC 테스트
- 9.6 통합 테스트
- 9.7 계약 테스트
- 9.8 OpenAPI
- 9.9 Protobuf
- 9.10 E2E 테스트
- 9.11 Claude Code 포인트
- 9.12 이 장의 정리
지금까지 로컬 PC에서 돌리던 api-service와 user-service를 Docker 컨테이너로 실행한다.
절 8개 보기
- 10.1 이 장의 목표
- 10.2 왜 Docker를 쓰는가
- 10.3 Dockerfile 만들기
- 10.4 컨테이너 안의 localhost에 주의하기
- 10.5 이미지와 컨테이너
- 10.6 Artifact Registry
- 10.7 Claude Code 포인트
- 10.8 이 장의 정리
Docker화한 api-service와 user-service를 Google Kubernetes Engine(GKE)에 배포한다.
절 19개 보기
- 11.1 이 장의 목표
- 11.2 Kubernetes와 GKE
- 11.3 Pod란
- 11.4 Deployment
- 11.5 Kubernetes Service
- 11.6 외부 공개
- 11.7 GKE 클러스터에 접속하기
- 11.8 매니페스트 적용하기
- 11.9 GKE 위의 API를 curl로 호출하기
- 11.10 수평 확장
- 11.11 HPA
- 11.12 Resource Requests / Limits
- 11.13 Readiness / Liveness
- 11.14 Config / Secret
- 11.15 롤링 업데이트
- 11.16 gRPC와 로드 밸런싱
- 11.17 관측 가능성
- 11.18 Claude Code 포인트
- 11.19 이 장의 정리
지금까지 사람 손으로 만들어 온 개발 흐름에 Claude Code를 도입한다.
절 11개 보기
- 12.1 이 장의 목표
- 12.2 Claude Code가 지원할 수 있는 공정
- 12.3 처음에는 기존 코드부터 읽힌다
- 12.4 구현 계획 만들게 하기
- 12.5 작은 단위로 구현하기
- 12.6 Claude Code에 테스트 실행시키기
- 12.7 리뷰에도 쓴다
- 12.8 AI에 맡기기 쉬운 일
- 12.9 사람이 강하게 관여해야 하는 일
- 12.10 Claude Code 활용을 재현 가능하게 만들기
- 12.11 이 장의 정리
Claude Code가 매번 프로젝트의 기본 방침을 추측하지 않아도 되도록 CLAUDE.md를 정비한다.
절 10개 보기
- 13.1 이 장의 목표
- 13.2 CLAUDE.md의 역할
- 13.3 CLAUDE.md에 뭐든 쓰지 않는다
- 13.4 아키텍처 쓰기
- 13.5 빌드/테스트 명령 쓰기
- 13.6 금지 사항
- 13.7 업무 용어
- 13.8 좋은 CLAUDE.md의 기준
- 13.9 Claude Code 포인트
- 13.10 이 장의 정리
CLAUDE.md만으로는 부족한 세세한 규칙과 작업 절차를 규칙 파일과 스킬로 분리한다.
절 12개 보기
- 14.1 이 장의 목표
- 14.2 규칙이란
- 14.3 Spring Boot 규칙
- 14.4 gRPC 규칙
- 14.5 Database 규칙
- 14.6 스킬이란
- 14.7 create-rest-api 스킬
- 14.8 create-grpc-service 스킬
- 14.9 spanner-schema-change 스킬
- 14.10 스킬을 Git으로 관리하기
- 14.11 Claude Code 포인트
- 14.12 이 장의 정리
"Claude에게 테스트해 달라고 부탁하는" 단계에서
절 12개 보기
- 15.1 이 장의 목표
- 15.2 왜 자동 검사가 필요한가
- 15.3 포매터
- 15.4 단위 테스트
- 15.5 빌드
- 15.6 proto 검사
- 15.7 CI 예시
- 15.8 AI 리뷰도 CI에 넣는다
- 15.9 권한
- 15.10 프롬프트는 보안 경계가 아니다
- 15.11 Claude Code 포인트
- 15.12 이 장의 정리
여러 서비스에 걸친 변경에서 다짜고짜 코드부터 쓰게 하지 않는 방법을 배운다.
절 10개 보기
- 16.1 이 장의 목표
- 16.2 예: currency 추가하기
- 16.3 먼저 조사
- 16.4 계획 만들기
- 16.5 사람이 계획을 리뷰한다
- 16.6 작게 구현하기
- 16.7 여러 에이전트를 쓰는 경우
- 16.8 계획을 기록으로 남기기
- 16.9 Claude Code 포인트
- 16.10 이 장의 정리
Claude Code를 "쓸 줄 아는 사람만 빠른" 상태에서 팀 전체가 같은 품질로 쓸 수 있는 상태로 끌어올린다.
절 11개 보기
- 17.1 이 장의 목표
- 17.2 개인 활용의 문제
- 17.3 공통 하네스(Harness)
- 17.4 CoE라는 발상
- 17.5 현장에서 CoE로 피드백
- 17.6 실패를 자산화한다
- 17.7 성공도 자산화한다
- 17.8 지표
- 17.9 교육
- 17.10 Claude Code 포인트
- 17.11 이 장의 정리
지금까지 배운 내용을 전부 써서 사용자의 계좌 잔액을 조회하는 API를 추가한다.
절 15개 보기
- 18.1 이 장의 목표
- 18.2 요구 사항
- 18.3 Step 1: Claude에게 조사시키기
- 18.4 Step 2: 계획
- 18.5 Step 3: proto
- 18.6 Step 4: Server
- 18.7 Step 5: Client
- 18.8 Step 6: REST Controller
- 18.9 Step 7: curl
- 18.10 Step 8: Test
- 18.11 Step 9: Claude 리뷰
- 18.12 Step 10: CI
- 18.13 Step 11: 스킬로 환원
- 18.14 최종적으로 지향하는 모습
- 18.15 이 책의 정리
이 부록 전체는 보완 내용이다. 앞에서는 규칙·스킬·훅·권한을 개념 수준으로 설명하므로, 2026년 11월 기준 Claude Code 공식 문서의 형식에 맞춰 바로 붙여 넣을 수 있는 최소 예시를 모았다. 버전에 따라 세부 동작이 바뀔 수 있으니 적용 전에 공식 문서를 한 번 확인하자.
절 4개 보기
- A.1 경로 한정 규칙과 스킬 (14장)
- A.2 권한 설정 (15.9)
- A.3 포매터·테스트 훅 (15.3·15.4)
- A.4 CI의 proto 호환성 검사 (9.9·15.6)