프론트엔드 개발자에게도 필요한 클라우드 애플리케이션 아키텍처 패턴

클라우드 애플리케이션 아키텍처 패턴 - 레거시 현대화와 클라우드 네이티브 전환을 위한 70가지 실무 전략
카일 브라운.바비 울프.조셉 요더 지음, 박수현 옮김 / 한빛미디어 / 2026년 3월

한빛미디어 서평단 나는리뷰어다 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

1. 이 책을 선택한 동기

그동안 클라우드에 배포한 경험은 많지만, '클라우드 네이티브 애플리케이션'이라는 표현으로는 생각해본 적 없었어요. 가장 많이 사용하는 GCP부터 AWS, Docker 등 활용하는 것은 많았지만 사실상 아키텍처 패턴을 잘 활용하지는 못했죠. 사용법만 알고 있었을 뿐입니다.

클리우드 애플리케이션 아키텍처 패턴은 "클리우드 네이티브"라는 말을 패턴으로 풀어준다는 점에서 저에게 매력적인 책이었어요.

2. 어떤 책인지

725페이지 분량은 어찌보면 꽤나 버거워 보이는 장수였지만, 반드시 순차적으로 각 장을 읽을 필요 없다고 서문에서 저자는 말합니다. 필요한 부분을 독립적으로 읽어도 된다고 하니 마음이 놓였고, 사실 순차적으로 흐름을 따라가기도 좋은 책이었어요.

1장: 클라우드 애플리케이션 기초 (스테이트리스, 불변성, 폴리글랏)

2장: 애플리케이션 아키텍처 패턴 (진흙 덩어리 → 모듈러 모놀리식 → 분산)

3장: 클라우드 네이티브 (12-Factor App, 컨테이너, 쿠버네티스)

4장: 마이크로서비스 아키텍처 (도메인 마이크로서비스)

5장: 마이크로서비스 설계 — DDD (엔티티, 값 객체, 애그리거트)

6장: 이벤트 주도 아키텍처 (비동기 통신, 메시지 큐)

7장: 클라우드 네이티브 데이터 관리 (폴리글랏 퍼시스턴스)

8장: 클라우드 네이티브 보안

9장: 관측 가능성 (로깅/메트릭/트레이싱)

10장: 애플리케이션 이전 및 현대화

각 장마다 항공권 예약, 피자 주문, 전자상거래 같은 구체적인 예시가 있어서 의외로 빨리 읽혔어요. 패턴 중심이라 지루할 수도 있는데 예시가 적절히 섞여 있어서 좋았어요.

3. 특히 인상적이었던 점

"큰 진흙 덩어리가 항상 나쁜 건 아니다" (2장)

진흙 덩어리(Big Ball of Mud)는 안티 패턴으로 알고 있었습니다. 그런데 저자는 초기 스타트업이나 PoC 단계에서는 오히려 진흙 덩어리가 생산성이 높다고 말해요. 중요한 건 "언제 모듈러 모놀리식으로 넘어갈지 아는 것"이라고요.

이건 마치 TDD에서 "테스트를 먼저 쓰라"가 아니라 "언제 테스트를 써야 하는지 아는 것"과 같은 맥락이었어요. 지

12-Factor App은 체크리스트다 (3장)

12-Factor App이라는 개념은 처음 알았습니다. 이 책에서 "이건 철학이 아니라 체크리스트"라고 정의한 게 와닿았어요. '설정은 환경 변수로 분리했나?', '로그는 스트림으로 처리하나?', '프로세스는 무상태인가?' 이걸 하나씩 체크하면 클라우드 네이티브 앱의 최소 기준은 충족한다는 것이죠.

도메인 마이크로서비스는 기존 시스템 뜯어내기보다 새 기능부터 시작하라 (4~5장)

5장에서 가장 와닿은 조언이었어요. 기존 모놀리식을 리팩터링하는 건 학습 곡선이 너무 가파르다고요. 새로운 비즈니스 영역의 기능을 도메인 마이크로서비스로 만들면서 패턴을 익히는 게 훨씬 현명하다고 말해요.

DDD를 패턴과 연결해서 실용적으로 설명한 점 (5장)

DDD 책 따로 읽으면 '애그리거트는 무엇인지?'에서 끝나는 경우가 많은데, 이 책에서는 항공권 예약이나 피자 주문 예시로 "왜 애그리거트고, 왜 이렇게 나누는지"를 보여줘요. 도메인 서비스 vs 애그리거트 경계도 코드 수준에서 설명해서 이해가 빨랐어요.

특히 "요금 계산 서비스는 상태를 데이터스토어에 저장하는 대신 룰 엔진을 사용한다"는 부분이 인상적이었어요. 상태가 없는(stateless) 서비스의 좋은 예시라고 생각했어요.

"실금(Seam)을 찾아라" (10장)

모놀리식을 마이크로서비스로 나눌 때 "어디서 자를까?"보다 "이미 자연스러운 경계가 어딘가?"를 찾는 게 중요하다고 하였습니다. DDD의 경계 컨텍스트를 활용해서 실금을 찾고, 거기서부터 래퍼(Wrapper)를 씌워서 점진적으로 추출하는 전략이에요.

이 대목을 읽고 나니까 우리 프로젝트에서도 "실금"이 어디에 있는지 눈에 보이기 시작했어요. 인증 모듈, 결제 모듈, 알림 모듈... 이것들은 이미 자연스러운 경계가 있는 부분이더라고요.

관측 가능성은 선택이 아니라 필수 (9장)

로깅/메트릭/트레이싱을 "삼위일체"로 묶은 게 인상 깊었어요. 분산 아키텍처에서는 디버깅이 단일 프로세스 때보다 훨씬 어려워서, "어떻게 관찰할지"를 설계 단계부터 고민해야 한다는 거예요.

특히 "멀티 채널 로깅의 복잡성" 부분에서 공감했어요. 지금까지는 콘솔 로그에 찍히면 그만이라고 생각했는데, 프로덕션에서는 중앙 집중화된 로깅이 필수라는 걸 배웠어요.

4. 덕분에 무엇을 배웠는가

점진적 전환의 중요성. 커다란 진흙 덩어리 → 모듈러 모놀리식 → 분산 아키텍처 → 마이크로서비스. 한 번에 다 옮기려 하지 말고, 단계별로 가는 게 현명하다는 걸 배웠어요.

DDD는 기술이 아니라 비즈니스 설계다. 도메인 전문가와 함께 설계해야 하고, 애그리거트 경계 = 트랜잭션 경계 = 일관성 경비라는 관점이 인상적이었어요.

12-Factor App은 지금 당장 체크할 수 있다. 이론이 아니라 지금 프로젝트에 적용해볼 수 있는 실천법이라는 점이 좋았어요.

이벤트 기반 설계의 가치. 서비스 간 직접 호출이 아니라 이벤트 발행/구독으로 느슨한 결합을 달성하는 방법을 배웠어요.

"실금"을 찾는 눈. 모놀리식 현대화는 "어디서 자를까?"가 아니라 "이미 자연스러운 경계가 어딘가?"를 찾는 문제라는 걸 배웠어요.

폴리글랏은 선택지다. 하나의 DB/언어로 모든 걸 해결하려 하지 말고, 작업별로 최적화된 기술을 선택하는 게 클라우드 네이티브의 정신이라는 걸 배웠어요.

5. 좋았던 점

패턴 중심이라 나중에 찾아보기 좋아요

각 장이 독립적으로 읽을 수 있어서, "아, API 게이트웨이 패턴이 어디 있더라?" 할 때 바로 찾아볼 수 있어요. 패턴 사전처럼 쓸 수 있다는 게 장점이에요.

예시가 구체적이에요

항공권 예약 시스템, 피자 주문, 전자상거래... 실제로 겪을 법한 예시라 이해가 쉬웠어요. 특히 항공권 예약 시스템은 4장, 5장, 6장에 걸쳐 계속 나와서 흐름을 따라가기 좋았어요.

클라우드 전체를 아우르는 개념 지도를 그려줘요

12-Factor App, 컨테이너, 쿠버네티스, 이벤트 주도, 폴리글랏 퍼시스턴스, 관측 가능성까지 흩어진 개념들을 "클라우드 네이티브 앱을 어떻게 설계/운영하는가"라는 한 줄로 연결해줘요.

6. 아쉬운 점

코드 예제가 Java 중심이에요

Java/Spring 예제가 많아서 Node.js/TypeScript 개발자인 저는 번역해서 이해해야 하는 경우가 있었어요. 클라우드가 언어를 가리지 않는다는 책의 주장과 살짝 모순되는 느낌이 들었어요.

일부 패턴은 너무 짧게 다뤄요

Saga 패턴이나 CQRS 같은 중요한 패턴은 언급만 하고 넘어가는 경우가 있어서, "그래서 어떻게 구현하는데?" 하는 아쉬움이 남았어요.

7. 이 책을 읽은 덕분에 기대되는 변화

- 12-Factor App 체크리스트로 현재 프로젝트를 점검해볼 거예요. 특히 설정 분리와 로그 스트림 처리 부분을 중점적으로 볼 예정입니다.

- 코드 리뷰할 때 "이 의존성이 정말 필요한가?"를 먼저 물어보는 습관을 들이고 싶어요. 폴리글랏 퍼시스턴스 관점에서, 지금 쓰는 RDB가 모든 작업에 최적인지도 다시 검토해볼 계획이에요.

- 로깅/메트릭/트레이싱을 중앙 집중화하는 방안을 팀에 제안해볼 거예요. 현재는 콘솔 로그에만 의존하고 있거든요.

- "실금"을 찾는 관점으로, 기존 레거시 코드를 볼 때도 "여기서부터 분리하면 되겠다"는 감이 생길 것 같아요.

AI 시대, 복잡함을 줄이기 위한

미니멀리즘 프로그래머 - AI 시대, 복잡함을 줄이고 가치를 올리는 개발 원칙
데이비드 토머스 지음, 이민석 옮김 / 한빛미디어 / 2026년 2월

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

1. 이 책을 선택한 동기

에이전틱 코딩이 익숙해질수록 모든 코드를 일일이 검토하지 못하는 빈도가 높아졌어요. 병렬 에이전트를 동시다발적으로 지휘하다보면 한 사람 한 사람의 코드를 모두 세세히 파악하기는 쉽지 않죠. 점차 코드 하나하나에 대한 고민이 줄어들수록, 현 시대에 맞춘 개발 방법론에 대해 한번 짚고 가고 싶었습니다.

그러던 중에 미니멀리즘 프로그래머을 만났어요. 『실용주의 프로그래머』의 공동 저자 중 한명인, 데이비드 토머스가 AI 시대에 단순함을 이야기한다는 게 마침 타이밍이 맞았어요. 지금 이 시점에 읽어야 할 책이다 싶었습니다.

2. 어떤 책인지

192쪽이라는 얇은 분량에 29가지 실천법(Practice)을 담은 책이에요. 코드, 팀, 환경, 소통 — 개발자 삶의 전 영역에서 복잡함을 걷어내는 법을 이야기해요. 코드 기술서라기보다는 개발자의 태도와 습관에 대한 책에 가까워요.

크게 4개 파트로 나뉘는데 구성이 재밌었어요.

PART 1 하는 일 단순화: 의존성, 프레임워크, 기능 관리

PART 2 환경 단순화: 자동화, 터미널, 에디터

PART 3 상호작용 단순화: 팀 회의, 소프트 스킬, 공감

PART 4 코드 단순화: 데이터 주도 개발, 가독성

저자가 서문에서 던지는 질문이 인상적이었어요.

"슬픈 사실은 프로젝트를 복잡하게 만든 장본인이 대부분 우리 자신이라는 점입니다. 잠시 멈춰 서서 생각하지 않고, '이게 정말 맞나?'라고 묻는 내면의 작은 목소리를 외면하는 순간 복잡함이 싹틉니다." (p.16)

3. 특히 인상적이었던 점

"복합적(complex)"과 "복잡한(complicated)"은 다르다 (p.16)

책 서문에 나오는 구분이 머릿속에 오래 남았어요. 눈송이 비유가 인상적이었어요.

"소프트웨어의 복합적인 면은 다루기 어렵지만, 그 안에는 분명한 규칙이 존재합니다. 하지만 그 규칙을 무시하면 '복잡함'이 찾아옵니다." (p.16)

눈송이는 복합적(complex)이지만, 날씨는 복잡(complicated)합니다. 소프트웨어도 마찬가지예요. 읽으면서 제가 만들어온 코드들이 떠올랐어요. "일단 돌아가면 됐지"로 넘어간 순간들이 쌓여서 결국 아무도 건드리기 싫은 파일이 되는 과정... 정확히 그 흐름이에요.

의존성을 추가하는 건 통제권을 넘기는 일 (p.31)

"저는 의존성이라면 단 하나의 예외도 없이 싫어합니다. 의존성을 추가하면 미래의 내가 가져야 할 통제권의 일부를 남에게 넘겨주는 것이나 다름없습니다." (p.31)

저자가 인용한 조 암스트롱의 말도 머릿속에 남아요.

"바나나 하나만 필요했을 뿐인데, 바나나를 든 고릴라와 정글 전체가 딸려온다." (p.35)

프레임워크에 대해서도 강하게 경계해요.

"프레임워크가 API를 쥐고 있을 뿐만 아니라, 애플리케이션 아키텍처를 어떻게 짤지까지 규정해 버리기 때문입니다." (p.39)

Next.js를 쓰면서 "왜 이렇게 해야 하지?"를 고민하기보다 프레임워크가 시키는 대로 따라가고 있던 제 모습이 보였어요.

'기능'은 미래의 부채 (p.43)

"'기능'은 '미래의 부채'를 그럴싸하게 포장한 마케팅 용어입니다." (p.43)

그리고 같은 챕터에 이런 말도 나와요.

"아무도 요청하지 않은 코드는 작성하지 마세요." (p.44)

읽으면서 찔렸어요. 요청도 안 받았는데 "이 기능 있으면 좋겠다"는 생각에 혼자 만들었다가 결국 유지보수만 늘어난 경험이 한두 번이 아니거든요.

"할 수 있다"와 "해야 한다"는 다르다 (p.100)

이 문장은 챕터 도입부에서 자신의 에디터 설정을 너무 과하게 꾸몄던 경험을 반성하며 나오는데, AI 시대에 더욱 날카롭게 읽혔어요.

"할 수 있다고 해서 좋은 생각인 건 아닙니다." (p.100)

AI가 뚝딱 코드를 만들어주는 시대에, 기술적으로 가능하다는 이유로 덥석 붙여넣는 게 얼마나 위험한 일인지 다시 생각하게 됐어요. 코드를 생성하는 능력은 평준화되지만, 그 코드가 지금 정말 필요한지 판단하는 능력은 여전히 사람의 몫이에요.

코드에도 공감이 필요하다 (p.133)

요트 스키퍼 이야기가 정말 좋았어요. 초보와 숙련자의 차이를 이렇게 설명해요.

"그는 배를 굴복시키려 들지 않았습니다. 대신 배의 움직임을 느끼고, 배와 '합의'를 이루려고 했습니다." (p.134)

코드도 마찬가지라고 저자는 말해요. 뭔가 저항감이 느껴지거나 평소보다 힘들다는 느낌이 들면, 그냥 억지로 밀어붙이지 말고 멈춰서 살펴보라고요. 그 감각이 잠재의식이 보내는 신호라고요. 개발하면서 "이건 뭔가 이상한데..."라고 느끼면서도 그냥 넘어간 적이 얼마나 많았는지 돌아봤어요.

회의는 원래 애자일하지 않다 (p.54)

코드 얘기가 아니라 조금 뜬금없을 수 있지만, 이 챕터도 제게 꽤 충격이었어요.

"회의는 비효율적이고 불공평하며 업무를 방해하고 비용도 많이 듭니다." (p.57)

저자는 10명 팀이 2주 스프린트 동안 회의에만 13시간 30분을 쓴다는 걸 계산으로 보여줘요. 더 인상적인 건 이 문제를 해결하기 위해 DWP(포트폴리오 없는 개발자)라는 새로운 역할을 제안한다는 거예요. 코드를 짜지 않고 팀이 원활하게 돌아가도록 돕는 역할이에요. "팀이 엔진이라면 DWP는 윤활유"라는 비유가 딱 맞아요. 이걸 읽으면서 팀에 이런 사람이 한 명 있고 없고가 얼마나 큰 차이인지 실감했어요.

상태 머신으로 로직 단순화하기 (p.163)

"저는 상태 머신을 자주 사용합니다. 상태 머신을 적용할 때마다 제가 작업하던 코드가 더 좋아졌습니다." (p.163)

"상태 머신 구현은 복잡한 라이브러리나 긴 패턴 기반 접근 방식이 없어도 충분합니다. 필요한 것은 룩업 테이블 하나뿐입니다." (p.164)

로그인 상태, 주문 상태, 결제 상태... 대부분의 UI 로직은 상태 변화인데, 이걸 명시적으로 모델링하지 않고 if/else로 땜빵해온 경우가 얼마나 많았는지 돌아보게 됐어요. 루비 코드로만 예시가 나와서 JavaScript에서는 어떻게 쓸지 직접 실험해봐야 했지만, 개념 자체가 강하게 남았어요.

4. 덕분에 무엇을 배웠는가

단순함은 기술이 아니라 태도다. 코드를 짧게 줄이는 테크닉이 아니라, 불필요한 것을 덜어내는 판단력의 문제예요. "단순함은 결코 단순하지 않습니다. 신중하게 의도되고 충분히 다듬어지며 실질적으로 효과적입니다." (p.191)

AI가 짜준 코드도 검토할 줄 알아야 한다. AI가 코드를 생성해줄수록, 그 코드가 정말 필요한 건지 판단하는 능력이 더 중요해져요. "할 수 있다"와 "해야 한다"는 다릅니다.

자동화는 인지 부담을 줄인다. "자동화를 더 많이 할수록 기억해야 할 것이 줄어듭니다." (p.84) 배포 자동화, 환경 설정 자동화가 단순히 편리한 게 아니라 코드 품질과도 직결된다는 걸 배웠어요.

탐색은 미래에서, 일은 과거에서. "매일 의존하는 도구와 라이브러리의 경우, 화려하거나 새로운 것보다 지루하고 안정적인 것이 언제나 더 낫습니다." (p.116) 새로운 기술은 탐색 시간에 실험하고, 실제 프로젝트에는 검증된 것을 쓴다는 원칙이 납득됐어요.

공감이 코드 단순화에도 영향을 미친다. 코드에도 귀를 기울이고, 팀원과의 마찰을 줄이는 것이 결국 시스템 단순화로 이어진다는 연결이 인상적이었어요.

의존성 추가 전에 한 번 더 생각하자. 정말 이게 없으면 안 되는가? 직접 11줄로 짤 수 있는 건 아닌가?

5. 좋았던 점

코드만 이야기하지 않는다

기술 서적인데 회의 방식, 팀 커뮤니케이션, 소프트 스킬까지 다루는 게 오히려 좋았어요. 개발의 복잡함은 코드에서만 오는 게 아니니까요. "다양성은 회복력입니다"(p.73) — 동물 종과 팀 모두에 해당한다는 말이 오래 남았어요.

저자의 솔직함

저자는 자신이 소프트 스킬이 부족하다고 스스로 인정하면서 챕터를 시작해요. "저는 공감 능력 척도에서 4 정도 될 것 같습니다"라고요. 이런 솔직함 덕분에 '완벽한 개발자가 가르치는 이야기'가 아니라 '함께 개선해가는 과정'처럼 읽혔어요.

6. 아쉬운 점

29가지 원칙 중 일부는 너무 짧게 다루고 지나가서 "이건 더 파줬으면..." 싶은 챕터가 몇 개 있었어요. 특히 상태 머신 부분은 루비 코드 예시만 나와서, JavaScript/TypeScript 개발자는 직접 변환해서 써봐야 했어요. 가독성 챕터(CH.08)의 Practice들은 너무 실용적이고 좋았는데 후반부에 급히 달린 느낌이 들었고요.

7. 이 책을 읽은 덕분에 기대되는 변화

복직하면 코드 리뷰할 때 "이 의존성이 정말 필요한가?"를 먼저 물어볼 것 같아요. 그동안은 "동작하면 됐다"는 태도로 넘어갔던 순간들이 있었는데, 이제는 동작하는 가장 단순한 선택을 먼저 찾아보는 습관을 들이고 싶어요.

그리고 Practice 22에서 배운 상태 머신 패턴을 사이드 프로젝트인 북골라스에 바로 적용해볼 계획이에요. 독서 상태 관리(reading → paused → finished)를 명시적 상태 모델로 다시 짜보면 좋겠다 싶거든요. 라이브러리 없이 룩업 테이블 하나로.

자동화도 다시 점검하고 싶어요. "배포 체크리스트를 여기저기 찾아 헤맬 필요가 없다"(p.84)는 말처럼, 기억해야 할 것들을 자동화로 줄이는 작업을 미뤄왔는데 이 책을 읽고 다시 의욕이 생겼어요.

저자의 마지막 문장이 오래 남아요.

"코드와 코딩 방식, 그리고 나아가서는 삶 자체도 가능한 한 단순함을 추구하세요. 이 방법을 적용하면 생산성이 높아지고 스트레스가 줄고 업무에 즐거움과 재미를 다시 느낄 수 있을 겁니다. 여러분에겐 그럴 자격이 있습니다." (p.191)

데이터 엔지니어링 디자인 패턴 리뷰

데이터 엔지니어링 디자인 패턴 - 데이터 수집부터 품질, 오케스트레이션, 관찰 가능성까지 반복되는 문제를 해결하는 70가지 패턴 전략
바르토시 코니에치니 지음, 김인범 옮김 / 한빛미디어 / 2026년 1월

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

1. 이 책을 선택한 동기

실무에서 SQL을 다루는 기술을 읽은 이후로, 데이터를 "쓰는 것" 이상의 관점이 궁금해졌습니다. 데이터를 어떻게 수집하고, 어떻게 이동시키고, 어떻게 품질을 유지하는지— 백엔드 너머의 세계가 점점 궁금해지던 차였어요.

저는 프론트엔드 개발자지만, 사이드 프로젝트를 혼자 만들면서 Supabase, Neon DB 같은 도구를 직접 다루다 보면 자연스럽게 데이터 파이프라인이라는 개념을 마주하게 됩니다. 데이터를 어디서 가져와서, 어떻게 가공해서, 어디에 저장할지— 사실 지금까지는 그때그때 즉흥적으로 해결해왔어요. "이건 그냥 INSERT 하면 되겠지", "오류 나면 그때 가서 보면 되겠지" 하는 식으로요.

그런데 데이터 엔지니어링 디자인 패턴이라는 제목을 보는 순간 뭔가 꽂혔어요. 소프트웨어 엔지니어링의 디자인 패턴이라는 개념은 이미 익숙했으니까요. "GoF 패턴을 데이터 엔지니어링에 적용한다고? 그게 가능해?" 하는 호기심이 생겼습니다.

2. 어떤 책인지

데이터 엔지니어링 디자인 패턴은 소프트웨어 엔지니어링의 디자인 패턴 개념을 데이터 엔지니어링 분야에 본격적으로 적용한 실무 가이드입니다. 저자 바르토시 코니에치니는 다양한 비즈니스 도메인과 클라우드 환경을 경험하면서 프로젝트마다 반복적으로 등장하는 공통적인 지점들을 패턴화해냈고, 그 결과물이 바로 이 책이에요.

책의 구성은 실제 데이터 엔지니어링 프로젝트의 워크플로를 그대로 따릅니다.

CHAPTER 2: 데이터 수집 디자인 패턴 (전체 적재, 증분 적재, 복제, 이벤트 주도)

CHAPTER 3: 오류 관리 디자인 패턴

CHAPTER 4: 멱등성 디자인 패턴

CHAPTER 5: 데이터 가치 디자인 패턴

CHAPTER 6: 데이터 흐름 디자인 패턴

CHAPTER 7: 데이터 보안 디자인 패턴

CHAPTER 8: 데이터 스토리지 디자인 패턴

CHAPTER 9: 데이터 품질 디자인 패턴

CHAPTER 10: 데이터 관찰 가능성 디자인 패턴

각 패턴은 문제 → 해결책 → 결과 라는 일관된 구조로 서술됩니다. 패턴의 이름을 붙이고, 어떤 상황에서 필요한지, 어떻게 적용하는지, 그리고 적용 후 어떤 트레이드오프가 따르는지까지 체계적으로 다뤄요.

3. 특히 인상적이었던 점

1. "데이터 엔지니어링에도 이름이 있다"

가장 충격적이었던 건 그동안 제가 아무렇게나 해왔던 작업들에 다 이름이 있다는 사실이에요. 전체 데이터를 통째로 다시 가져오는 방식은 전체 로더(Full Loader) 패턴, 바뀐 것만 가져오는 방식은 증분 적재(Incremental Load) 패턴, 파이프라인 중간에 오류가 난 데이터를 따로 보관하는 건 데드 레터링(Dead Lettering) 패턴이라고 불린다는 걸 이 책을 통해 처음 알았어요.

이름이 있다는 건 단순히 용어 문제가 아닙니다. "아, 이게 왜 이렇게 돼있지?"라는 상황에서 문제를 정확히 진단하고 팀원과 공유할 수 있는 언어가 생긴다는 뜻이거든요.

2. 패턴 구조의 일관성

각 패턴이 문제 → 해결책 → 결과 라는 일관된 포맷으로 서술된다는 점이 좋았어요. 단순히 "이렇게 하면 돼"가 아니라, "이런 상황에서 이런 이유로 이 패턴이 필요하고, 적용하면 이런 장단점이 생긴다"까지 설명해줍니다.

예를 들어 전체 로더 패턴을 설명할 때, EL(Extract-Load) 방식이 이상적인 경우와 이종 데이터베이스 간에는 ETL(Extract-Transform-Load)이 필요한 이유까지 친절하게 짚어줘요. 덕분에 "언제 이 패턴을 쓰면 되는지"가 명확하게 느껴졌습니다.

3. 멱등성(Idempotency)이라는 개념

솔직히 말하면 멱등성이라는 단어 자체는 알고 있었어요. "같은 연산을 여러 번 해도 결과가 같아야 한다"는 거잖아요. 그런데 이게 데이터 파이프라인에서 왜 그렇게 중요한지, 어떻게 설계에 반영하는지는 이 책을 읽고 나서야 피부로 느꼈어요. 파이프라인이 도중에 실패해서 재실행될 때 중복 데이터가 쌓이는 문제— 멱등성을 고려하지 않으면 데이터가 조용히 오염될 수 있다는 걸 그때서야 깨달았어요.

4. 덕분에 무엇을 배웠는가

데이터 파이프라인을 설계하는 눈이 생겼어요. 사이드 프로젝트에서 데이터를 다룰 때 "이걸 전체 로더로 할지, 증분 적재로 할지"를 의식적으로 선택할 수 있게 되었습니다. 작은 프로젝트에서도 선택의 근거가 생기니 훨씬 자신있게 결정할 수 있어요.

오류 처리를 미리 설계해야 한다는 것을 배웠어요. 예전에는 오류가 나면 그냥 로그 찍고 넘어갔는데, 데드 레터링 패턴처럼 오류 데이터를 별도로 격리해서 분석하고 재처리하는 구조를 미리 설계해야 한다는 걸 이제는 알아요.

데이터 품질은 파이프라인 밖에서 보장할 수 없다는 것도요. 입력이 잘못됐을 때 그걸 어디서 잡을지, 품질 검사를 어느 시점에 끼워넣을지— 이게 CHAPTER 9에서 다루는 데이터 품질 패턴의 핵심이었습니다.

데이터 관찰 가능성(Observability)이라는 개념을 제대로 이해했어요. 단순히 모니터링이 아니라, 파이프라인 전체의 상태를 추적하고 이상 신호를 감지하는 시스템을 설계하는 방법— 이게 프론트엔드 개발자인 저에게도 적용 가능한 사고방식이라는 걸 깨달았어요.

5. 좋았던 점

1. 데이터 엔지니어링 전 단계를 망라한 구성

데이터 수집에서 시작해서 오류 처리, 멱등성, 품질 검증, 모니터링으로 이어지는 흐름이 실제 데이터 파이프라인의 생애주기와 정확히 일치해요. 덕분에 "지금 제가 어느 단계의 문제를 다루고 있는가"를 항상 인식하면서 읽을 수 있었습니다.

2. 패턴에 이름을 붙여준다는 것

이 책의 가장 큰 가치는 이름 붙이기라고 생각해요. 전체 로더, 증분 적재, 데드 레터링, 멱등성 설계— 이름이 생기면 팀 내 커뮤니케이션이 달라집니다. 백엔드·데이터 엔지니어 동료와 대화할 때 같은 언어로 이야기할 수 있게 되는 거니까요.

3. 마지막에 있는 "디자인 패턴 요약" 섹션

책 전체 패턴을 한눈에 볼 수 있는 요약 챕터가 있어요. 나중에 어떤 패턴이 있었는지 찾고 싶을 때 인덱스처럼 활용하기 딱 좋았습니다.

6. 아쉬운 점

데이터 엔지니어링을 처음 접하는 독자에게는 진입장벽이 있어요. 분산 시스템, 클라우드 서비스, 데이터 웨어하우스 등의 배경 지식을 어느 정도 갖추고 있어야 내용이 잘 소화됩니다. "데이터 수집이 뭔지"부터 설명해주는 책은 아니에요.

각 패턴에 대한 코드 예제가 있으면 더 좋았을 것 같아요. 어떤 패턴인지 개념은 이해했는데, "그래서 실제로 Python이나 Spark로 어떻게 구현하는 거야?"가 궁금한 순간들이 있었거든요.

7. 이 책을 읽은 덕분에 기대되는 변화

사이드 프로젝트에서 데이터를 다룰 때, 이제는 단순히 동작하는 코드가 아니라 재실행에 안전한 파이프라인을 만들 수 있을 것 같아요. 멱등성을 고려한 UPSERT 쿼리를 쓴다든지, 오류가 난 데이터를 조용히 버리지 않고 별도 테이블에 기록해두는 습관이 생겼거든요.

무엇보다 "이 파이프라인이 잘못됐을 때 어떻게 알 수 있지?"라는 질문을 미리 던질 수 있게 된 것 같아요. 데이터가 조용히 오염되는 건, 파이프라인이 아예 멈추는 것보다 훨씬 위험하다는 걸 이 책을 읽고 나서야 실감했습니다.

프론트엔드 개발자가 데이터 엔지니어링 책을 읽는다는 게 뜬금없어 보일 수 있지만, 풀스택으로 뭔가를 만들고 싶은 사람이라면 꼭 한 번 읽어보길 추천해요. 데이터를 다루는 방식이 달라집니다!

스프링부트 개발자 온보딩 가이드

스프링 부트 개발자 온보딩 가이드 : 스프링 부트로 시작하는 첫 실무 프로젝트 ㅣ 온보딩 가이드 2
박상현 지음 / 한빛미디어 / 2025년 12월

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

1. 이 책을 선택한 동기

그동안 조금씩 공부해온 덕분에 백엔드에 대한 이해도가 작년에 비해서는 조금 생겼습니다. Node.js로 간단한 서버를 만들어본 적도 있고, NestJS로 사이드 프로젝트 백엔드를 구축해본 경험도 있었죠.

하지만 여전히 자바 진영은 완전히 미지의 영역이었습니다. 채용 공고를 보면 백엔드 포지션의 대다수가 "Java/Spring" 또는 "Kotlin/Spring"을 요구하더라고요. 개발 커뮤니티에서도 스프링 관련 이야기가 정말 많이 오가는데, 사실 저는 자바와 스프링의 차이가 뭔지도 명확하게 몰랐습니다. 또한 스프링이 프레임워크라는 건 알겠는데, 스프링 부트는 또 무엇인지 감을 잡을 수 없었죠.

이런 궁금증이 쌓여가던 차에 스프링 부트 개발자 온보딩 가이드를 발견했어요.

2. 어떤 책인지

스프링 부트 개발자 온보딩 가이드는 제목 그대로 '온보딩 문서'처럼 구성된 스프링 부트 실무 입문서예요. 개발 환경 구축부터 AWS 배포까지, 하나의 프로젝트를 처음부터 끝까지 만들어가는 과정을 따라가며 배우는 구조입니다.

책의 흐름은 이렇습니다. 먼저 개발 환경(WSL2, Docker, IntelliJ, JDK 21, Gradle)을 세팅하고, 가장 단순한 인메모리 To-Do API부터 시작해요. 이후 JPA와 MySQL을 연동하고, 마이크로블로그라는 좀 더 복잡한 프로젝트로 확장합니다. 여기에 JWT 인증(스프링 시큐리티), GraphQL 지원을 추가하고, 마지막에는 Docker로 패키징해서 AWS에 배포하는 것까지 다룹니다.

3. 특히 인상적이었던 점

자바/스프링 생태계만의 특징

NestJS에서는 데코레이터(@Controller, @Get 등)를 사용하는데, 스프링 부트에서도 비슷하게 애노테이션(@RestController, @GetMapping 등)을 사용하더라고요. 문법은 비슷해 보이는데, 내부 동작 방식이나 철학은 꽤 다르다는 걸 느꼈어요. 특히 스프링의 의존성 주입(DI)과 IoC 컨테이너 개념이 NestJS보다 더 명시적이고 체계적으로 다뤄진다는 인상을 받았습니다.

JPA

NestJS에서는 TypeORM이나 Prisma를 주로 사용했는데, JPA는 접근 방식이 꽤 달랐습니다. 엔티티 클래스에 @Entity, @Id, @GeneratedValue 같은 애노테이션을 붙이고, 리포지토리 인터페이스만 정의하면 기본 CRUD가 자동으로 생성되는 게 신기했어요. "인터페이스만 만들면 구현체가 알아서 생긴다고?" 하는 느낌이었죠.

스프링 시큐리티

NestJS에서 Passport.js로 인증을 구현해본 적 있는데, 스프링 시큐리티는 훨씬 더 정교하고 체계적이었어요. 필터 체인, UserDetails, GrantedAuthority 같은 개념들이 처음엔 복잡하게 느껴졌지만, 이 구조 덕분에 세밀한 권한 제어가 가능하다는 걸 이해하게 됐습니다.

고민상담소

"자바 개발자가 배워야 할 프레임워크", "스프링 부트의 데이터베이스 연동", "GraphQL 도입 시점" 같은 실무적인 고민들을 다뤄주었어요.

4. 덕분에 무엇을 배웠는가

1. 자바와 스프링, 스프링 부트의 관계에 대한 이해

자바는 언어, 스프링은 프레임워크, 스프링 부트는 스프링을 더 쉽게 사용하게 해주는 도구라는 걸 알게 됐습니다. 스프링 부트가 자동 설정(Auto Configuration)과 내장 서버를 제공해서 복잡한 XML 설정 없이 빠르게 시작할 수 있다는 것도요.

2. 자바 진영의 프로젝트 구조와 컨벤션

패키지 구조(entity, dto, repository, service, controller), build.gradle 설정, application.properties 활용법 등 자바/스프링 프로젝트에서 당연하게 여기는 것들을 배웠습니다. NestJS의 모듈 구조와 비교해보면서 이해하니까 더 와닿았어요.

3. JPA의 동작 방식을 이해

영속성 컨텍스트, 엔티티 생명주기, 연관관계 매핑 같은 개념들이 TypeORM과 어떻게 다른지 비교하며 배울 수 있었어요. 특히 DTO 패턴을 왜 사용하는지, 엔티티를 직접 노출하면 안 되는 이유를 명확하게 알게 됐습니다.

4. Gradle 빌드 시스템

Node.js의 npm/yarn에 익숙했는데, Gradle은 빌드 스크립트 자체가 코드(Groovy/Kotlin DSL)라는 점이 달랐어요. 의존성 관리 방식도 다르고, 빌드 태스크 개념도 새로웠습니다.

5. 좋았던 점

1) 점진적으로 기능을 확장하는 구조

인메모리 → JPA → 인증 → GraphQL → 배포로 하나의 프로젝트를 점진적으로 확장하는 구조가 좋았어요. 새로운 개념을 배울 때마다 이전 코드 위에 쌓아가니까, 변경점이 명확하게 보이고 이해가 쉬웠습니다. NestJS에서 비슷한 패턴을 경험해봤기 때문에, "아 스프링에서는 이렇게 하는구나" 하고 비교하며 배울 수 있었어요.

2) 실무 환경 그대로의 개발 환경 구성

WSL2, Docker, IntelliJ, JDK 21이라는 조합은 실제 자바 개발 현장에서 많이 사용하는 환경이라 합니다. 특히 Docker로 MySQL을 띄우는 방식은 Node.js 개발할 때도 비슷하게 했던 거라 익숙했고, 자바 진영에서도 동일한 방식을 사용한다는 걸 확인할 수 있었어요.

3) GraphQL까지 다루는 폭넓은 범위

REST API만 다루는 게 아니라 GraphQL까지 다뤄요. NestJS에서도 GraphQL을 사용해봤는데, 스프링에서는 어떻게 구현하는지 비교해볼 수 있었어요. 스키마 정의 방식이나 리졸버 구현 방식이 꽤 달라서 흥미로웠습니다.

6. 아쉬웠던 점

1) 자바 기초 문법에 대한 설명 부족

저처럼 자바 경험이 없는 개발자에게는 진입 장벽이 있었어요. 람다 표현식, 스트림 API, Optional 같은 문법이 당연하다는 듯이 사용되는데, 간단한 자바 문법 부록이 있었으면 좋았을 것 같아요.

2) 스프링과 스프링 부트의 차이에 대한 설명 부족

책 초반에 스프링 부트를 소개하긴 하지만, "스프링 부트가 없던 시절에는 어떻게 했는지", "스프링 부트가 정확히 무엇을 자동화해주는지"에 대한 깊이 있는 설명은 부족했어요. 자바 진영이 처음인 저로서는 이 맥락이 더 궁금했거든요.

7. 이 책을 읽은 덕분에 기대되는 변화

이 책을 읽고 나서 자바/스프링 진영에 대한 막연함이 많이 걷혔어요. 개발 커뮤니티에서 "스프링 시큐리티가...", "JPA N+1 문제가..." 하는 대화가 나와도 이제는 무슨 맥락인지 이해할 수 있게 됐습니다.

NestJS와 비교하면서 배우니까, 각 프레임워크의 장단점도 더 명확하게 보이기 시작했어요. NestJS의 모듈 시스템이 더 직관적인 부분도 있고, 스프링의 생태계와 성숙도가 더 탄탄한 부분도 있다는 걸 느꼈습니다.

결과적으로 자바 백엔드 개발자와 협업할 때 더 깊이 있는 소통이 가능해질 것 같습니다.

전략적으로 접근하는 개발자의 취업/이직

개발자 기술 면접 노트 - 20년 차 카카오 면접관의 빅테크 기업 취업/이직 가이드, 개정판
이남희 지음 / 한빛미디어 / 2025년 4월

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

1. 이 책을 선택한 동기

경력 기술 면접이란 저에게 아직 막연한 분야입니다. 인터넷 상에서 서류 준비, 이력서 작성 꿀팁, 특정 언어의 예상 면접 질문은 쉽게 찾아볼 수 있습니다. 하지만 실제로 이런 내용이 실전에서 먹히는지 궁금했어요. 지원자들을 선별하는 내부자들의 시선이 궁금했죠. 이 책, 개발자 기술면접 노트는 합격률이 높은 '지원자'가 아니라 '18년 차 카카오 면접관'으로서 알려주는 가이드는 이 궁금증을 해소하고 싶은 저에게 너무나 혹하는 표지였습니다.

2. 어떤 책인지

취업/이직을 준비하기 위해 준비해야하는 모든 것을 상세히 다룬 가이드입니다. 특히, 실제 저자의 면접관으로서 지원자를 바라보는 관점과 선별하는 과정에 대한 이야기를 알 수 있었다는 것이 좋았습니다.

초반부에서는 채용의 첫 단계인 서류 준비에 대해 다룹니다.

- 막연히 '채용이란 어떤 과정을 거치니 단계적으로 준비해야한다'라는 내용이 아니라, 어떤 식으로 전략적으로 접근해야하는지

- 목표로 하는 회사에 비해 자신의 상태가 조금 아쉬울 때, 어떻게 강점을 키울 수 있는지

- 면접관으로서 어떤 이력서가 매력적으로 다가오는지

서류 이후 다음 단계인 기술 면접과 코딩 테스트를 준비하는 전략, 이어서 2차 혹은 최종 단계에서 어떻게 쐐기를 박을 수 있을지 상세하게 다루었습니다. 마지막으로 개정판에 추가된 내용으로 'AI 도구 활용으로 업무 능력을 향상할 수 있는 조언'이 담겨있습니다.

3. 무엇을 배웠는가

서류란 단순히 '내가 뭘 했다'를 나열하는 게 아니라는 걸 배웠어요. 트러블 슈팅 경험을 중심으로, 어떤 문제를 마주했고 어떻게 해결했는지, 그 과정에서 어떤 기술적 의사결정을 내렸는지를 보여줘야 한다는 거죠. 면접관은 지원자의 문제해결 능력과 기술적 사고방식을 보고 싶어한다는 점을 명확히 알게 되었어요.

커리어 관리는 이직 시즌에만 하는 게 아니라는 걸 깨달았어요. Git 잔디 관리, 스터디 참여, 개인 프로젝트, 오픈소스 기여 등을 평소에 꾸준히 해야 한다는 거죠. 특히 경력직 채용에서는 "지금 보유한 실력"보다 "적극적으로 자기계발을 해왔는지"를 더 중요하게 본다는 점이 인상적이었어요.

기술 면접은 정답 맞히기가 아니라 대화라는 걸 배웠어요. 모르는 질문이 나와도 아는 선에서 논리적으로 접근하는 모습을 보여주는 것이 중요하다는 거죠. 또한 면접 중 질문의 난이도가 점점 낮아진다면 탈락 가능성이 높다는 팁도 유용했어요.

3. 좋았던 점

3.1. 지원자에서 면접관으로 성장한 저자의 실제 경험

저자는 SI 업체에서 시작해 쿠팡, 카카오로 이직하며 커리어를 쌓아온 분이에요. 단순히 면접관 입장에서만 이야기하는 게 아니라, 본인도 계단식 이직을 통해 성장해온 경험을 솔직하게 공유해요. 특히 스타트업을 거쳐 빅테크로 가는 전략적 이직 경로에 대한 조언이 현실적이었어요.

3.2. 면접관 관점의 실제 합격/탈락 사례

책 곳곳에 실제 합격 사례와 탈락 사례가 등장해요. "두 번 이상 동일 부서에 지원", "성의 없는 이력서", "눈에 띄는 이력사항이 전혀 없는 경우" 같은 탈락 케이스를 보면서 내가 무심코 할 수 있는 실수들을 미리 체크할 수 있었어요. 반대로 "핸디캡을 극복한 합격 사례"를 통해 어떤 강점을 어필해야 하는지도 구체적으로 알 수 있었죠. 특히 면접관이 이력서를 검토하는 시간이 1분 정도라는 사실을 알게 되면서, 첫 페이지에 핵심 경력과 기술 스택을 명확히 보여줘야겠다고 생각했어요.

3.3 기술 면접, 코딩 테스트에서의 필수 개념과 스킬의 구체적인 제시

단순히 "자료구조와 알고리즘을 공부하세요"가 아니라, 스택, 큐, 우선순위 큐, 연결 리스트 같은 구체적인 자료구조와 정렬, 검색, LRU, LFU 같이 필수적으로 익혀야하는 알고리즘을 명시해줘요. 또한 웹 아키텍처, 성능 최적화, 대용량 데이터 처리, CI/CD 같은 실무 개념도 면접 질문과 함께 정리되어 있어서 체계적으로 준비할 수 있었어요. 특히 연차별로 기대되는 답변 수준을 구분해준 점이 정말 유용했습니다. 주니어에게는 기본 개념 이해를, 시니어에게는 실제 적용 경험과 트레이드오프 고민을 기대한다는 점을 명확히 알 수 있었죠.

4. 아쉬운 점

4.1. 백엔드 중심의 내용 구성

익혀야하는 지식도, 프론트엔드 지원자의 사례도, 알고리즘이나 기술 면접 대비 지식도 역시 백엔드에 특화되어있어요. 예를 들어 데이터베이스 파티셔닝, MSA 분리, 대용량 트래픽 처리 같은 백엔드 주제는 상세하게 다뤄지지만, React Server Components, SSR vs CSR, 브라우저 렌더링 최적화 같은 프론트엔드 특화 주제는 상대적으로 적었어요. 프론트엔드 개발자로서는 이 부분을 별도로 보충해서 준비해야 할 것 같습니다.

4.2. 실전 면접 시뮬레이션 예시의 부족

질문과 모범 답변은 잘 정리되어 있지만, 실제 면접처럼 꼬리질문이 이어지는 상황에 대한 예시가 조금 부족했어요. 예를 들어 "Zustand를 사용한 이유가 뭔가요?" → "Context API와 비교했을 때 어떤 점이 좋았나요?" → "성능 이슈는 없었나요?" 같은 연속적인 질문 흐름을 보여줬다면 더 실전적이었을 것 같아요. 단편적인 Q&A보다는 실제 면접 대화처럼 이어지는 예시가 더 많았으면 좋았을 거예요.

5. 이 책을 읽은 덕분에 기대되는 변화

이력서란 그저 내가 해왔던 업무와 장점을 나열하는 것이라 생각했어요. 이 책을 읽고, 면접관으로서 매력적으로 다가오는 이력서란 어떤 것인지, 어떻게 전략적으로 준비를 할 수 있는지를 알게되었습니다.

사실 저에게는 서류부터가 막막한 주제였는데 그 다음 단계인 기술 면접 혹은 코딩 테스트, 그리고 최종까지 어떻게 대비해야하는지 모두 막막했었는데 체증이 풀리는 기분이었습니다. 먹힐지 안먹힐지 불안한 마음으로 대비하고 임한다면 태도에서부터 이미 매력을 잃었을 것입니다. 이제는 자신감을 갖고 체계적으로 준비할 수 있을 것 같아요.