[서평] 온톨로지 비법노트 — 벡터 검색이 못 하는 일을 온톨로지로 채우다

온톨로지 비법노트 - AI가 진짜 이해하는 지식 구조: AI가 데이터의 ‘의미’를 이해하고 RAG를 고도화하는 온톨로지 실전 가이드 ㅣ 비법노트 시리즈 (리코멘드)
김정석 지음 / 리코멘드 / 2026년 10월

본 서평은 출판사로부터 도서를 제공받아 작성했습니다.

"검색은 잘 되는데, 답이 자꾸 틀려요"

RAG를 한 번이라도 운영 환경에 올려본 사람이라면 이 문장에 바로 고개를 끄덕일 것이다. 임베딩 모델을 바꿔 보고, 청크 크기를 조정하고, 리랭커를 붙여도 어느 지점부터는 정확도가 더 오르지 않는다. 검색 결과를 열어 보면 분명 질문과 "비슷한" 문서가 올라와 있는데, 그 문서가 질문에 대한 원인인지, 전제 조건인지, 예외 조항인지는 아무도 구분해 주지 않는다. 벡터 검색은 유사도를 계산할 뿐, 의미 관계를 모른다.

『온톨로지 비법노트』는 바로 그 빈자리를 다루는 책이다. RAG 비법노트 기본편·심화편·랭그래프편에 이은 비법노트 시리즈의 네 번째 책으로, 저자 김정석(㈜클레버플랜트 대표)이 "AI가 데이터의 의미를 이해하게 만드는" 도구로 온톨로지를 꺼내 든다. 284쪽, 2026년 10월 출간.

책의 구조 — 이론 절반, 손으로 만들기 절반

목차는 크게 두 덩어리로 나뉜다.

전반부(1~4장)는 "왜 온톨로지인가"에 대한 답이다. LLM 단독 답변, RAG, Graph RAG를 나란히 놓고 각각이 어디서 무너지는지를 보여주고, 데이터가 의미를 가져야 하는 이유를 1차 논리(FOL)와 ASP(Answer Set Programming)까지 내려가서 설명한다. 비정형 데이터를 추론 기반으로 온톨로지화하는 장과 시맨틱 웹의 역사까지 짚고 넘어가는데, 이 부분은 RDF·OWL을 처음 접하는 독자에게 특히 필요한 배경이다.

후반부(5~8장)는 실습이다. 서울시 실시간 도시 데이터(인구, 교통, 주차, CCTV, 전기차 충전소)를 재료로 온톨로지를 직접 설계하고, Protégé로 모델링 → SHACL로 제약 검증 → Fuseki에 적재 → SPARQL로 질의하는 흐름을 하나로 이어 간다. 그리고 7장에서 이것을 LangChain과 연동해 OAG(Ontology Augmented Generation)를 구현하고, 8장에서 전기차 충전소 추천·인력 배치 추천이라는 추천 시스템으로 확장한다.

도구 네 개(Protégé·SHACL·Fuseki·SPARQL)가 각각 따로 소개되는 책은 많지만, 설계부터 질의, LLM 연동까지 하나의 데이터셋으로 끝까지 끌고 가는 책은 국내에 거의 없었다. 이 책의 가장 큰 가치는 거기에 있다.

인상 깊었던 지점

1. 온톨로지 설계를 4단계 절차로 고정해 준다.
WHY(왜 이 개념이 필요한가) → WHAT(무엇을 개념·관계로 정의할 것인가) → HOW(어떻게 제약과 규칙을 표현할 것인가) → RESULT(어떤 질의가 가능해지는가). 온톨로지는 "어디서부터 시작해야 할지 모르는" 것이 가장 큰 진입 장벽인데, 이 절차 덕분에 서울시 데이터가 아닌 자기 도메인에도 바로 옮겨 적용할 수 있다. 주차장·충전소·교통 상황처럼 장소와 시간, 현재 상태가 얽힌 개념을 클래스와 관계로 정리해 가는 과정을 따라가다 보면, 온톨로지가 추상적인 이론이 아니라 질문을 설계하는 작업이라는 것이 체감된다.

2. SHACL을 "검증" 도구로 제대로 다룬다.
RAG 파이프라인에서 데이터 품질 문제는 보통 답이 틀린 뒤에야 발견된다. SHACL로 그래프에 들어가는 데이터의 형식과 관계를 사전에 검증하는 흐름은, 데이터 거버넌스 관점에서 봐도 RAG보다 한 단계 앞선 접근이다.

3. Graph RAG와 OAG의 차이를 명확히 한다.
최근 Graph RAG(LightRAG, GraphRAG 등)를 써 본 입장에서 가장 궁금했던 부분이다. LLM이 자동 추출한 엔티티·관계 그래프와, 사람이 규칙과 제약을 명시한 온톨로지는 생김새는 비슷해도 성격이 다르다. 전자는 "있는 것을 찍어낸 그래프"이고 후자는 "있어야 할 것을 선언한 스키마"다. 이 책은 그 차이에서 출발해, 왜 규칙 기반 추론이 필요한 질문(조건·예외·현재 상태가 얽힌 질문)에서는 온톨로지가 답이 되는지를 설명한다. 7장의 OAG 구현은 SPARQL 질의 결과를 LangChain 체인에 컨텍스트로 넣는 구조라, 기존 RAG 코드를 크게 뜯어내지 않고도 붙여 볼 수 있다는 점이 실무자 입장에서 반갑다.

실무자 시점에서의 생각

데이터 가상화와 데이터 플랫폼 구축을 주로 하는 입장에서, 온톨로지는 늘 "좋은 건 알지만 비용이 큰" 기술이었다. 이 책을 읽으면서 든 생각은, LLM이 그 비용 구조를 바꿨다는 것이다. 과거엔 온톨로지를 만드는 데 사람 손이 너무 많이 들었지만, 이제는 비정형 데이터에서 개념 후보를 LLM으로 뽑고(3장), 사람은 규칙과 제약만 확정하는 식으로 역할을 나눌 수 있다. 책이 이 분업을 명시적으로 주장하는 것은 아니지만, 전반부와 후반부를 이어 읽으면 자연스럽게 그 그림이 그려진다.

공공·스마트시티 데이터 서비스를 대상 독자로 명시한 점도 눈에 띈다. 서울시 실시간 데이터는 API가 공개되어 있어 따라 하기 쉽고, 지자체·공공기관 과제에서 바로 레퍼런스로 쓸 수 있는 예제다.

아쉬운 점

284쪽에 이론·역사·도구 네 개·RAG·추천 시스템까지 담았으니 각 장이 깊이 들어가기엔 분량이 빠듯한 것은 사실이다. FOL·ASP 같은 이론은 한 권으로 따로 다뤄도 모자란 주제라 개론 수준에서 멈추고, Fuseki를 대규모 데이터에서 운영할 때의 성능이나 OAG 결과를 정량적으로 평가하는 방법은 독자의 몫으로 남는다. 이 책은 "온톨로지 전문서"가 아니라 "RAG 개발자가 온톨로지로 넘어가는 다리"로 읽는 것이 맞다.

누구에게 권하는가

RAG를 구축해 봤고 벡터 검색의 한계를 몸으로 느낀 AI·백엔드 개발자에게 가장 잘 맞는다. Graph RAG를 써 봤지만 "그래프를 만들었는데 그래서 뭐가 달라졌는지" 설명이 안 되던 사람에게도 좋다. 반대로 파이썬·LangChain·SQL을 전혀 모르면 후반부 실습을 따라가기 어려우니, 시리즈 앞권(RAG 비법노트 기본편)을 먼저 보는 것을 권한다.

한 줄 평: 벡터 검색이 "비슷한 것"을 찾는 데서 멈춘다면, 이 책은 "맞는 것"을 찾게 만드는 방법을 서울시 데이터로 끝까지 구현해 보여준다.

본 서평은 출판사로부터 도서를 제공받아 작성했습니다.

[강의 리뷰] 클로드가 다 해줌 : 하루 1시간 6일 완성 — 채팅만 하던 Claude를 ‘일하는 도구‘로 바꾸는 18차시

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

강의명: 클로드가 다 해줌 : 하루 1시간 6일 완성
강사: 임정
플랫폼: 한빛+ (한빛플러스)
강의 링크: https://www.hanbit.co.kr/viewer/products/4187570/lessons/8544
구성: 총 18차시, 차시당 16분~45분 (전체 약 8시간)

한 줄 요약 — "AI를 쓰는 것"과 "AI가 일하게 하는 것"의 차이를 18개의 업무 결과물로 체감시키는 강의. 채팅 이상으로 넘어가지 못한 직장인에게 가장 먼저 권하고 싶다.

■ 왜 이 강의를 들었나

회사에서 Claude를 쓴 지는 꽤 됐지만, 솔직히 대부분 "질문하고 답 받기" 수준이었습니다. 프로젝트, 코워크, 클로드 코드, 클로드 디자인, 스킬, 서브에이전트… 제품과 기능은 계속 늘어나는데, 이걸 어떤 순서로 익혀서 실제 업무에 붙여야 하는지 한 줄로 정리된 자료를 찾기 어려웠습니다. 『n8n이 다 해줌』으로 알게 된 임정 강사님이 이번에는 Claude를 주제로 강의를 냈다고 해서, 흩어진 기능을 하나의 흐름으로 꿰어 볼 생각으로 수강을 시작했습니다.

■ 18차시, 이렇게 구성되어 있다

"하루 1시간 6일"이라는 제목은 광고 문구가 아니라 실제 설계입니다. 18차시를 하루 3차시씩 묶으면 정확히 6일이고, 각 차시가 "하나의 업무 결과물"로 끝나기 때문에 중간에 끊어도 손에 남는 게 있습니다. 흐름은 크게 네 단계로 올라갑니다.

1단계 · 채팅과 프로젝트 (1~2차시) — 클로드 4개 제품(채팅, 코워크, 클로드 코드, 클로드 디자인)을 비교하고 실습 환경을 준비한 뒤, 프로젝트 지침으로 회의 아젠다를 만듭니다. "지침을 한 번 써 두면 매번 같은 품질이 나온다"는 원리를 여기서 잡아 주고, 이 원리가 뒤의 모든 차시에 이어집니다.

2단계 · 코워크와 자동화 (3~5차시) — 채팅과 코워크의 차이(내 폴더에서 직접 일한다는 것), 코워크에 리서치를 맡기고 매일 아침 자동으로 받는 법, 내 컴퓨터를 꺼도 돌아가는 주가 수집기를 Apps Script와 구글 시트로 만드는 실습이 이어집니다.

3단계 · 클로드 코드와 디자인 (6~10차시) — CLAUDE.md로 폴더 규칙을 정하고, 아파트 실거래가 대시보드를 만들어 GitHub Pages로 공개합니다. 그 대시보드를 클로드 디자인으로 발표 자료로 바꾸고, DESIGN.md에 디자인 기준을 정해 모든 자료에 똑같은 룩을 입힙니다. 터미널에 클로드를 설치하고 공개된 스킬을 가져다 쓰는 법까지 다룹니다.

4단계 · 에이전트와 실전 프로젝트 (11~18차시) — 서브에이전트 조사팀에게 연말정산 조사를 맡기고, 훅으로 업무 일지가 저절로 쌓이게 만든 다음, 공공데이터 출점 후보지 비교, DART 공시로 공급사 검증 후 도입 제안서 작성, 주간 뉴스레터 발송, 상품 리뷰 주간 리포트, 메일로 온 계약서 검토와 회신 초안, 그리고 근태·연차 관리 웹앱을 만들어 인터넷에 올리는 것으로 끝납니다.

■ 가장 인상 깊었던 차시

4차시 "코워크에 리서치 맡기고 매일 아침 자동으로 받기"가 제게는 가장 바로 쓸 수 있는 내용이었습니다. 리서치 자체를 Claude에게 시키는 건 누구나 하지만, 이걸 스케줄 작업으로 걸어 두고 매일 아침 정해진 시간에 결과를 받는 구조는 "AI를 쓰는 것"과 "AI가 일하게 하는 것"의 차이를 체감하게 합니다. 수강 후 관심 기술 뉴스를 매일 아침 정리해 받아 보는 루틴을 똑같은 방식으로 만들었습니다.

6차시 CLAUDE.md와 9차시 DESIGN.md는 한 쌍으로 기억에 남습니다. 폴더 규칙과 디자인 기준을 파일 하나에 적어 두면, 그 다음부터 만들어지는 모든 결과물이 그 기준을 따릅니다. 스킬을 "한 번 쓰고 버리는 프롬프트"가 아니라 "쌓아 두는 업무 자산"으로 보는 관점이 여기서 잡힙니다. 팀 단위로 Claude를 도입할 때 사람마다 결과 품질이 들쭉날쭉한 문제를 줄이는 데 이 두 차시가 핵심이라고 생각합니다.

14차시 DART 공시로 공급사 검증하기는 IT 컨설팅과 SI 쪽에서 일하는 입장에서 "이걸 이렇게 쓸 수 있구나" 싶었던 차시입니다. 공시 데이터를 근거로 공급사를 검증하고 도입 제안서 초안까지 뽑는 흐름은 실제 제안 업무에 거의 그대로 가져다 쓸 수 있습니다.

■ 새롭게 알게 된 점

첫째, 클로드 4개 제품의 역할 분담이 명확해졌습니다. 채팅은 생각 정리, 코워크는 내 폴더에서 하는 실제 업무, 클로드 코드는 자동화와 배포, 클로드 디자인은 결과물의 외형. 이 네 가지를 언제 어떤 것으로 할지 감이 잡히니 이후 기능이 추가되어도 어디에 들어갈지 보입니다.

둘째, 비개발자도 "배포"까지 갈 수 있다는 것. GitHub Pages로 대시보드를 공개하고, 마지막에 근태 관리 웹앱을 인터넷에 올리는 과정이 터미널을 처음 보는 사람 기준으로 설계되어 있습니다.

셋째, 훅과 서브에이전트처럼 개발자 영역으로 보이던 기능이 "업무 일지 자동 작성", "조사팀 운영" 같은 사무 업무 언어로 번역되어 있다는 점. 이 번역이 이 강의의 가장 큰 가치입니다.

■ 아쉬운 점

Claude의 기능 변화 속도가 워낙 빨라서, 강의 화면과 현재 메뉴 구성이 다른 곳이 수강 중에도 눈에 띕니다. 변경 사항을 안내하는 업데이트 노트가 강의 페이지에 꾸준히 붙으면 훨씬 안심이 될 것 같습니다. 또 후반부 15~18차시는 각각 30분~45분으로 길어지는데, 비개발자에게는 호흡이 다소 빠르게 느껴질 수 있어 터미널 기초를 짚어 주는 짧은 보조 영상이 하나 더 있으면 완성도가 높아질 것 같습니다.

■ 이런 분께 추천

Claude를 이미 쓰고 있는데 채팅 이상으로 넘어가지 못한 직장인에게 가장 잘 맞습니다. 코딩 경험이 없어도 후반부 클로드 코드 차시까지 따라갈 수 있도록 단계가 설계되어 있고, 반대로 개발자라면 비개발 동료에게 Claude 활용법을 설명할 때 이 강의의 18차시 구성을 그대로 빌려 쓸 수 있습니다. "AI한테 시켜 봤는데 결과가 매번 달라서 못 믿겠다"는 분이라면 2·6·9차시만으로도 수강료 값을 합니다.

■ 수강 전과 후

수강 전에는 매번 새 대화창을 열어 처음부터 상황을 설명하던 반복 업무(주간 보고 정리, 자료 조사 요약)를, 지금은 프로젝트 지침과 CLAUDE.md로 고정해 두고 씁니다. 리서치 루틴은 스케줄 작업으로 돌려 매일 아침 받아 보고 있고, 동료에게 Claude를 설명할 때도 "채팅·코워크·코드·디자인" 네 가지 역할 분담부터 이야기하게 되었습니다. 6시간짜리 강의가 업무 습관 하나를 바꿔 놓았다면 충분히 남는 투자였다고 생각합니다.

강의 링크: https://www.hanbit.co.kr/viewer/products/4187570/lessons/8544
18차시 로드맵 이미지가 포함된 전체 리뷰: https://hadesyi.tistory.com/424

#클로드가다해줌 #클로드 #업무자동화 #임정 #한빛플러스 #AI업무자동화

일하는 AI 에이전트, 설계하는 사람 — 코드 없이 AI 에이전트 ‘맡기는 법‘을 배우

일하는 AI 에이전트, 설계하는 사람 - 도입을 넘어 AI가 진짜 일하게 만드는 운영 전략
최윤석 지음 / 한빛미디어 / 2026년 9월

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

BOOK REVIEW

데모 다음 날을 위한 책

『일하는 AI 에이전트, 설계하는 사람』 · 최윤석 · 한빛미디어

AI 에이전트 책인데 코드가 한 줄도 없다.
처음 목차를 훑고 든 생각은 "이게 되나?"였고, 다 읽고 난 지금의 생각은 "오히려 그래서 된다"이다. 시중의 에이전트 책 대부분은 LangGraph나 CrewAI로 '만드는 법'을 다룬다. 이 책은 만드는 법이 아니라 맡기는 법을 다룬다. 어떤 일을 맡길지, 어디까지 자율에 두고 어디서 사람이 승인할지, 결과를 무엇으로 검증하고 한 달에 비용은 얼마나 나올지. 즉, 도입을 결정하고 운영 책임을 지는 사람이 벤더 미팅 전에 읽어야 할 책이다.

왜 이 책을 집었나

SI 현장에서 AX 플랫폼 제안과 구축을 하다 보면 늘 같은 장면을 만난다. 멋진 에이전트 데모로 PoC는 통과하는데, 실제 업무에 붙이는 단계에서 멈춘다. 고객이 던지는 질문은 기술 질문이 아니다.

"오류 나면 책임은 누가 지죠?"
"토큰 비용 통제는 어떻게 하죠?"
"사람이 승인하는 지점은 어디죠?"

이 질문에 답하려면 모델 성능 표가 아니라 판단의 구조가 필요한데, 그걸 정리해 둔 자료가 없었다. 이 책의 부제 '도입을 넘어 AI가 진짜 일하게 만드는 운영 전략'이 정확히 그 빈자리를 겨냥한다.

책의 구조: 작동 원리 → 운영 현실 → 조직 변화

3부 12장, 464쪽으로 두껍지만 흐름이 명확하다.

PART 1 · 1~4장

에이전트는 어떻게 일하는가

목표 해석–계획–실행–검증–재계획으로 이어지는 루프, 도구 호출과 최소 권한 설계, 작업 메모리와 장기 메모리, 멀티에이전트 조정까지. 개발자가 아니어도 '에이전트가 지금 무엇을 하고 있는지'를 그림으로 그릴 수 있을 만큼만 설명한다. 특히 2장의 '검증: 자체 점검과 독립 검증자' 구분은 실무에서 바로 쓸 수 있는 프레임이다. 에이전트가 스스로 "잘했다"고 하는 것과 별도의 검증자가 확인하는 것은 완전히 다른 신뢰 수준이라는 점을 분명히 짚는다.

PART 2 · 5~8장

무엇으로, 어떻게 돌릴 것인가

이 책의 가장 밀도 높은 부분이다. 6장에서 MCP와 A2A를 '왜 프로토콜이 필요한가'부터 풀어주는데, 제안서나 RFP에 이 용어를 쓰면서도 정확히 설명하지 못하던 분들에게 특히 유용하다. 7장 '비용, 속도, 품질의 운영 현실'은 멱등성, 지수 백오프 재시도, 프롬프트 캐싱 같은 개념을 "그래서 한 달에 얼마 나오는데요?"라는 질문에 답하는 도구로 재배치한다. 8장은 환각, 프롬프트 인젝션, 권한·비밀정보 관리, 사고 대응까지 — 금융·공공처럼 보안 심사가 엄격한 환경에서 도입을 준비하는 분이라면 이 장만으로도 책값을 한다.

PART 3 · 9~12장

사람과 조직은 무엇을 바꿔야 하는가

지시자·검토자·의사결정자로 나뉘는 사람의 역할, 인간 승인(HITL)과 감독(HOTL)의 설계, 첫 프로젝트 선정 기준, MVP에서 프로덕션으로 넘어가는 전환 설계, 거버넌스. 11장은 고객지원·문서/지식·내부 운영·전자상거래·연구/분석 다섯 영역의 적용 사례를 같은 분석 프레임으로 정리해서, 우리 조직의 업무를 어디에 대입하면 되는지 지도처럼 볼 수 있다.

인상 깊었던 세 가지

① '에이전트를 이해하는 것'과 '에이전트에게 일을 맡길 줄 아는 것'은 다른 능력이다.
책 전체를 관통하는 메시지다. 프롬프트를 잘 쓰는 것과, 업무를 구조화된 요청으로 쪼개고 승인 지점을 정하고 실패 시 멈추는 조건을 설계하는 것은 전혀 다른 역량이다. 9장에서 이를 'AI 플루언시'라는 이름으로 진단 가능한 역량으로 풀어낸 점이 좋았다.

② 분량의 절반 이상이 '도입 이후'에 할애되어 있다.
비용, 지연 시간, 품질 지표, 관측 가능성, 사고 대응, 변화 관리. 대부분의 AI 책이 '도입하면 좋다'에서 끝나는데, 이 책은 도입한 다음 날부터 생기는 일을 다룬다. 운영을 해본 사람이 쓴 책이라는 게 느껴진다.

③ 저자의 30년 전환기 경험.
한국오라클 21년, 한국마이크로소프트 DX Lead를 거친 저자는 PC→웹→모바일→클라우드→AI의 전환기를 매번 현장에서 건넜다. 그래서인지 "이번에도 데모만 화려하고 현장은 멈추는 패턴"을 정확히 알고 있고, 유행을 좇는 사람과 기준을 세우는 조직을 가르는 질문이 무엇인지를 담담하게 짚는다. 마지막 '일곱 가지 질문'은 팀 워크숍 안건으로 그대로 써도 될 만하다.

아쉬운 점

코드가 없다는 것이 장점이자 한계다. 손으로 에이전트를 짜보고 싶은 개발자에게는 맞지 않는 책이고, 구현 디테일은 다른 책으로 보완해야 한다. 또 에이전트 생태계가 워낙 빠르게 변해서 5장의 도구·플랫폼 비교와 12장의 시장·규제 전망은 1년 뒤에 다시 읽으면 낡은 부분이 생길 것이다. 다만 그 장들을 제외한 '판단의 구조'는 기술이 바뀌어도 오래 남을 내용이다.

누구에게 권하나

✅ 이런 분께 권합니다

▪ 에이전트 도입을 결정하거나 제안해야 하는 기획자, PM, AX 담당자, 임원
▪ 벤더 미팅에서 MCP·A2A·HITL 같은 용어를 듣고 되묻지 못했던 분
▪ PoC는 성공했는데 프로덕션 전환에서 멈춰 있는 팀
▪ 금융·공공처럼 책임 경계와 보안 심사가 엄격한 환경에서 AI를 준비하는 분

⚠️ 이런 분은 다른 책을

▪ "에이전트 프레임워크로 뭔가 만들어보고 싶다"는 개발자 — 첫 책으로는 권하지 않는다

총평

AI 에이전트 데모를 본 다음 날, 회사 책상 앞에서 "그래서 어떤 일부터 맡기지?"라는 질문이 남는 사람을 위한 책이다. 464쪽을 읽고 나면 그 질문이 "어떤 일을, 어디까지, 무엇으로 검증하며, 실패하면 어디서 멈추게 맡길 것인가"로 바뀐다. 질문이 구체화된다는 것, 그게 이 책이 주는 가장 큰 변화다.

★★★★★

5 / 5  ·  질문을 구체화시켜 주는 책

도서명	일하는 AI 에이전트, 설계하는 사람 — 도입을 넘어 AI가 진짜 일하게 만드는 운영 전략
저자	최윤석
출판사	한빛미디어 · 2026년 9월 30일 · 464쪽
구매	예스24 상품 페이지

#한빛미디어 #나는리뷰어다 #AI에이전트 #일하는AI에이전트설계하는사람 #최윤석 #MCP #A2A #AX #서평

《Do it! 바이브 코딩 + 클로드 코드》 — AI에게 코드를 받는 법이 아니라, 서

Do it! 바이브 코딩 + 클로드 코드 - AI 코딩이 처음이어도 기획·개발·자동화·배포까지!
고경희 지음 / 이지스퍼블리싱 / 2026년 9월

📖 도서명: Do it! 바이브 코딩 + 클로드 코드 / 저자: 고경희 / 출판사: 이지스퍼블리싱

■ 이 책을 펼친 이유

AI에게 "이런 기능 만들어 줘"라고 요청하면 그럴듯한 코드가 금방 나온다. 문제는 그다음이다. 받은 코드를 어디에 붙이고, 오류가 나면 어떻게 고치고, 완성된 결과물을 어떻게 배포하고 관리할지까지 이어지지 않으면 결국 데모에서 멈춘다. AI·데이터 플랫폼 구축 일을 하면서 AI 코딩 도구를 실제 업무에 어떻게 녹여낼지 고민하던 차에, 클로드 코드를 처음부터 끝까지 다룬 입문서라는 점이 눈에 들어왔다.

■ 하나의 앱을 끝까지 키워 가는 구성

이 책의 가장 큰 특징은 AI 뉴스 앱 하나를 처음부터 끝까지 완성한다는 점이다. 어떤 앱을 만들지 아이디어를 정리하는 기획에서 출발해 개발 환경을 준비하고, 뉴스 자동 수집, API 활용, 노션 MCP 연동 같은 기능을 하나씩 붙여 나간다. 예제가 끊기지 않고 이어지다 보니 기획 → 개발 → 기능 추가 → 관리라는 흐름이 자연스럽게 익혀진다. 실제 프로젝트가 굴러가는 방식과 닮아 있어 더 설득력 있게 다가왔다.

■ 새롭게 알게 된 점

첫째, 클로드 코드는 단순히 대화로 코드를 받아 내는 도구가 아니었다. 커스텀 명령, 스킬, 훅, 서브에이전트와 에이전트 팀, 플러그인을 보면서, 반복 작업을 정의해 두고 필요한 시점에 자동으로 검사를 걸고 작업을 여러 에이전트에게 나눠 맡기는 '일을 맡기는 체계'에 가깝다는 생각이 들었다.

둘째, 배포와 자동화까지 다룬다. 완성한 앱을 Vercel에 올리고 깃허브 액션으로 개발 과정을 자동화하는 부분은 입문서에서 흔히 생략되는 영역인데, 이 책은 거기까지 안내한다.

셋째, 비용 관리와 결과 검증이다. AI 코딩 도구를 도입할 때 늘 나오는 질문이 "비용은 얼마나 드는가"와 "AI가 만든 결과를 믿어도 되는가"인데, 입문서에서 이 두 가지를 따로 짚어 준다는 점이 반가웠다.

■ 읽고 나서

웹 개발 입문서를 여러 권 써 온 저자답게 설명이 친절하다. 필요한 기초 개념과 클로드 코드 사용법을 함께 익히면서 AI에게 무엇을 어떻게 요청해야 원하는 결과가 나오는지를 배울 수 있도록 구성되어 있다.

[직접 따라 해 본 실습 소감 1~2문장 — 예: 어느 부분이 특히 유용했는지, 어디서 막혔고 어떻게 풀었는지]

바이브 코딩이라는 말은 "대충 AI에게 맡긴다"는 뜻으로 오해받기 쉽지만, 책을 덮고 나니 오히려 반대라는 생각이 든다. 무엇을 만들지 분명히 정의하고, AI가 만든 결과를 검증하고, 반복되는 일은 체계로 만들어 두는 것. AI와 잘 일하는 사람은 결국 일을 잘 설계하는 사람이라는 점을 다시 확인한 책이었다.

■ 이런 분께 추천

아이디어는 있지만 코딩이 막막해 시작하지 못했던 분, AI로 코드를 받아 써 봤지만 완성까지 가 본 적은 없는 분, 클로드 코드를 설치만 해 두고 스킬·훅·서브에이전트를 어떻게 써야 할지 모르는 분, 그리고 팀에 AI 코딩 도구를 도입하기 전에 전체 흐름을 먼저 파악하고 싶은 실무자에게 권한다.

※ 이 글은 이지스퍼블리싱 서평단으로 도서를 제공받아 직접 읽고 작성한 서평입니다.

#바이브코딩 #클로드코드 #ClaudeCode #Doit #이지스퍼블리싱 #고경희 #AI코딩 #IT도서 #서

그냥 Postgres를 쓰세요! 리뷰 데이터베이스를 하나 더 붙이기 전에 던져야 할 질

그냥 Postgres를 쓰세요! - 관계형 데이터베이스를 넘어 AI, 검색, JSON, 시계열, 지리 공간까지
데니스 마그다 지음, 윤명식 옮김 / 제이펍 / 2026년 9월

※ 이 글은 제이펍 서평단 활동을 통해 도서를 제공받아 읽고 작성한 리뷰입니다.

아키텍처 그림에 박스가 하나씩 늘어날 때

시스템 구축 프로젝트를 하다 보면 아키텍처 그림에 박스가 하나씩 늘어나는 순간이 있습니다. 업무 데이터는 관계형 데이터베이스에, 검색은 검색 엔진에, 임베딩은 벡터 데이터베이스에, 비동기 처리는 메시지 브로커에, 센서나 로그 데이터는 시계열 데이터베이스에 넣는 식입니다. 각각의 선택에는 이유가 있지만, 박스가 하나 늘 때마다 설치와 이중화, 백업, 모니터링, 계정과 권한 관리, 보안 점검, 데이터 동기화, 그리고 그것을 운영할 사람까지 함께 늘어납니다. 특히 망 분리가 적용된 공공·금융 환경에서는 새로운 제품 하나를 반입하고 검토받는 과정 자체가 일정에 영향을 줍니다.

『그냥 Postgres를 쓰세요!』는 바로 이 지점에서 질문을 던지는 책입니다. 새로운 데이터 요구가 생겼을 때 전용 데이터베이스를 추가하기 전에, 이미 쓰고 있는 Postgres로 해결할 수 있는지부터 확인해 보자는 것입니다. 제목은 도발적이지만, 저자는 책 앞부분에서 Postgres가 모든 문제의 정답이라는 뜻은 아니라고 분명히 선을 긋습니다. 그래서 이 책은 무조건 Postgres를 쓰라고 외치는 책이라기보다, 기술 스택을 늘리기 전에 한 번 더 따져 보게 만드는 실무 판단의 책에 가깝습니다.

책 정보

원제	Just Use Postgres!
저자	데니스 마그다(Denis Magda)
역자	윤명식
출판사	제이펍
출간일	2026년 9월 10일
분량	468쪽

저자는 썬 마이크로시스템즈와 오라클에서 자바 플랫폼 업무를 하다가 데이터베이스와 대규모 분산 시스템 분야로 옮겨 온 엔지니어입니다. 역자 윤명식 님은 25년 넘게 금융, 게임, 광고, 클라우드 현장에서 데이터베이스 엔지니어이자 아키텍트로 일했고, 은행과 제조 대기업의 PostgreSQL 전환 프로젝트를 여러 차례 수행한 분입니다. 현장에서 Postgres 전환을 직접 해 온 분이 옮겼다는 점은 번역서를 고를 때 적지 않은 신뢰 요소가 됩니다.

구성 — 기본기에서 확장 생태계까지

책은 3부 11장과 부록 2개로 구성됩니다.

• 1부 관계형 데이터베이스로서의 Postgres(1~4장): 도커로 Postgres를 띄우고 psql로 접속하는 것부터 시작해 테이블 설계, 데이터 무결성, 트랜잭션, 조인, 함수와 트리거, 뷰, 역할 기반 접근 제어를 다룹니다. 이어서 CTE, 재귀 쿼리, 윈도 함수 같은 현대적인 SQL과 EXPLAIN을 활용한 인덱스 설계로 넘어갑니다.
• 2부 관계형 모델을 넘어선 핵심 Postgres(5~6장): 별도의 확장 기능 없이 기본으로 제공되는 JSON 처리와 전문 검색을 다룹니다.
• 3부 확장 기능 및 광범위한 생태계(7~11장): 확장 기능의 개념을 짚은 뒤 pgvector를 이용한 벡터 검색과 RAG, TimescaleDB를 이용한 시계열 데이터, PostGIS를 이용한 지리 공간 데이터, LISTEN/NOTIFY와 pgmq를 이용한 메시지 큐까지 살펴봅니다.
• 부록: 다섯 가지 최적화 팁과 ‘Postgres를 사용하지 말아야 할 때’를 담았습니다.

각 장은 음악 서비스, 멀티플레이어 게임, 피자 주문, OpenStreetMap 같은 예제 데이터 세트를 불러와 직접 쿼리를 실행해 보는 흐름으로 진행됩니다. 개념 설명만 읽고 넘어가는 것이 아니라 손으로 확인하면서 읽을 수 있도록 짜여 있습니다.

실무 관점에서 눈여겨본 대목

1. 성능 이슈는 결국 인덱스에서 만난다 — 4장

다른 데이터베이스에서 Postgres로 옮기는 프로젝트든 새로 구축하는 프로젝트든, 오픈 직전에 가장 많이 부딪히는 문제는 느린 쿼리입니다. 4장은 EXPLAIN으로 실행 계획을 읽는 방법부터 단일 칼럼, 복합, 커버링, 부분, 함수 및 표현식 인덱스까지 같은 데이터 세트로 비교해 가며 설명합니다. 특히 조건에 맞는 일부 행에만 인덱스를 만드는 부분 인덱스는, 처리 상태 값이 있는 대용량 업무 테이블에서 바로 활용처가 떠오르는 내용이었습니다. 부록 A의 최적화 팁도 EXPLAIN 익히기, 인덱스 사용 시점 파악, 커넥션 풀링, 필요한 데이터만 조회하기, 데이터베이스의 연산 능력 활용하기로 정리되어 있어 성능 점검 체크리스트로 쓰기 좋습니다.

2. 반정형 데이터와 검색, 전용 제품을 붙이기 전에 — 5~6장

연계 시스템에서 받은 데이터나 설정 정보처럼 구조가 자주 바뀌는 데이터를 JSON으로 저장하고, 자주 조회하는 필드만 인덱스로 받쳐 주는 방식은 실제 설계에서 자주 쓰는 절충안입니다. 5장은 관계형 칼럼과 JSON 사이의 균형을 어떻게 잡을지, 그리고 JSON 데이터를 어떻게 인덱싱할지를 예제로 보여 줍니다. 6장의 전문 검색은 텍스트를 어휘소로 바꾸고, 검색 결과의 순위를 매기고, 결과를 강조하고, 인덱스로 성능을 확보하는 과정까지 다룹니다. 게시판이나 문서 목록 수준의 검색이라면 검색 엔진을 따로 운영하기 전에 충분히 검토해 볼 만한 선택지입니다.

다만 국내 프로젝트에 적용할 때는 따로 챙겨야 할 부분이 있습니다. Postgres의 기본 전문 검색은 한국어 형태소 분석을 기본으로 제공하지 않기 때문에, 한국어 검색 품질이 중요하다면 pg_bigm이나 PGroonga 같은 확장 기능, 또는 별도의 형태소 분석기 연동을 함께 검토해야 합니다.

3. 업무 데이터 옆에 임베딩을 두는 선택 — 8장

생성형 AI 플랫폼을 구축할 때 가장 먼저 나오는 질문 중 하나가 벡터 데이터베이스를 따로 둘 것인가입니다. 8장은 pgvector로 임베딩을 저장하고, 코사인 거리 같은 연산자로 유사도 검색을 수행하고, 임베딩 인덱스로 검색 속도를 확보한 뒤, RAG까지 구현하는 과정을 보여 줍니다.

실무 관점에서 크게 와닿은 부분은 성능보다 관리 측면이었습니다. 원본 업무 데이터와 임베딩이 같은 데이터베이스에 있으면, 문서가 수정되거나 삭제될 때 임베딩도 같은 트랜잭션 안에서 함께 처리할 수 있고, 2장에서 다룬 역할과 접근 제어 체계를 그대로 활용할 수 있습니다. 부서나 등급에 따라 볼 수 있는 문서가 다른 조직에서 RAG를 구축할 때, 권한이 없는 문서가 검색 결과에 섞이지 않도록 하는 일은 생각보다 까다롭습니다. 별도의 벡터 저장소와 원본 데이터베이스 사이의 동기화와 권한을 따로 맞추는 것보다 구조를 단순하게 가져갈 여지가 있다는 점에서 의미 있는 장이었습니다.

4. 메시지 브로커 없이 큐를 만든다면 — 11장

모든 비동기 처리에 전용 메시지 브로커가 필요한 것은 아닙니다. 처리량이 크지 않은 배치 작업이나 알림 발송이라면 테이블 기반 큐로 충분한 경우도 많습니다. 11장은 언제 Postgres를 메시지 큐로 쓰는 것이 적절한지부터 짚고, 커스텀 큐를 직접 구현한 뒤 LISTEN/NOTIFY를 활용하고, pgmq로 넘어가는 순서로 구성됩니다. 워커가 메시지를 가져간 뒤 장애가 나서 처리 중 상태에 멈춰 버린 메시지를 pg_cron으로 주기적으로 복구하는 방법처럼, 실제 운영에서 마주칠 상황까지 짚어 준다는 점이 좋았습니다.

5. 이 책의 균형 감각 — 부록 B

가장 인상적이었던 부분은 부록 B ‘Postgres를 사용하지 말아야 할 때’입니다. 한 가지 기술을 전면에 내세운 책이 스스로 한계를 정리해 두었다는 점에서 책 전체의 신뢰도가 올라갑니다. 기능적으로 가능하다는 것과 그 선택이 해당 조직과 시스템에 맞다는 것은 별개의 문제입니다. 고객에게 아키텍처를 제안하는 입장에서는 이 구분을 분명히 해 두는 것이 무엇보다 중요하기 때문에, 부록 B는 따로 표시해 두고 다시 볼 생각입니다.

참고할 점

• 주제별 깊이: 3부의 벡터 검색, 시계열, 지리 공간, 메시지 큐는 각각 책 한 권이 나올 만한 주제입니다. 이 책은 각 주제를 어디서부터 시작하면 되는지에 초점을 맞추고 있으므로, 대규모 운영이나 세부 튜닝은 공식 문서나 전문 서적으로 이어서 보는 편이 좋습니다.
• 확장 기능 사용 가능 여부: 3부의 내용은 pgvector, TimescaleDB, PostGIS, pgmq 같은 확장 기능을 전제로 합니다. 클라우드 관리형 서비스는 지원하는 확장 기능이 제한될 수 있고, 폐쇄망 환경에서는 확장 기능 패키지를 반입해 설치해야 합니다. 확장 기능마다 라이선스 조건도 다르므로 도입 전에 확인이 필요합니다.
• 분석 플랫폼과는 구분: 이 책이 주로 다루는 범위는 애플리케이션 워크로드입니다. 대용량 데이터를 모아 분석하는 데이터 웨어하우스나 빅데이터 플랫폼까지 Postgres 하나로 대체할 수 있는지는 데이터 규모와 분석 요구에 따라 별도로 판단해야 합니다.
• 실습 환경: 예제는 도커를 기반으로 진행되므로, 사내 PC에서 도커 사용이 제한된다면 실습 환경을 미리 준비해 두는 것이 좋습니다.

이런 분께 권합니다

• Postgres를 관계형 데이터베이스로만 써 왔고, 그 이상을 활용해 보고 싶은 개발자
• 새 요구사항이 생길 때마다 기술 스택이 늘어나는 것이 부담스러운 아키텍트와 PM
• 상용 데이터베이스에서 PostgreSQL로의 전환을 검토하고 있는 팀
• RAG를 구축하면서 벡터 데이터베이스를 따로 도입해야 할지 고민하는 AI 플랫폼 담당자

읽는 순서 제안

• Postgres 입문자: 1부부터 순서대로
• 백엔드 개발자: 3장(현대적인 SQL), 4장(인덱스), 부록 A 중심
• AI·검색 담당자: 5장(JSON), 6장(전문 검색), 8장(생성형 AI) 중심
• 아키텍트: 1장, 7장(확장 기능), 부록 B를 먼저 읽고 필요한 장으로 이동

한 줄 평

데이터베이스를 하나 더 붙이기 전에, 지금 쓰고 있는 Postgres로 되는지부터 확인하게 만드는 책입니다.