leesk55님의 서재 (leesk55 서재)

[서평] 온톨로지 비법노트 — 벡터 검색이 못 하는 일을 온톨로지로 채우다 - [온톨로지 비법노트 - AI가 진짜 이해하는 지식 구조: AI가 데이터의 ‘의미’를 이해하고 RAG를 고도화하는 온톨로지 실전 가이드]

leesk55 — Sun, 25 Oct 2026 13:50:00 +0900

온톨로지 비법노트 - 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차시

leesk55 — Mon, 19 Oct 2026 21:55:00 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 강의를 협찬받아 작성된 후기입니다. 강의명: 클로드가 다 해줌 : 하루 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가 진짜 일하게 만드는 운영 전략]

leesk55 — Tue, 13 Oct 2026 20:34:00 +0900

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

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서
책을 협찬받아 작성된 서평입니다.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 코딩이 처음이어도 기획·개발·자동화·배포까지!]

leesk55 — Wed, 30 Sep 2026 00:09:00 +0900

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

📖 도서명: 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, 시계열, 지리 공간까지]

leesk55 — Fri, 11 Sep 2026 23:14:00 +0900

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

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

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

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

좋은 코드 리뷰 나쁜 코드 리뷰 베타리딩 후기 - [좋은 코드 리뷰 나쁜 코드 리뷰 - 19가지 사례와 33가지 팁으로 배우는 개발자 말하기와 글쓰기, 좋은 개발팀은 어떻게 리뷰하고 소통하는가?]

leesk55 — Thu, 27 Aug 2026 22:22:00 +0900

좋은 코드 리뷰 나쁜 코드 리뷰 - 19가지 사례와 33가지 팁으로 배우는 개발자 말하기와 글쓰기, 좋은 개발팀은 어떻게 리뷰하고 소통하는가?
토리이 유키 외 지음, 시마다 고지 감수, 김성훈 옮김 / 길벗 / 2026년 08월

길벗 리뷰어 활동으로 도서를 제공받아 읽고 솔직하게 작성한 리뷰입니다. #협찬
『좋은 코드 리뷰 나쁜 코드 리뷰』 베타리딩 후기지은이: 토리이 유키, 쿠보 유코, 모로나가 아야카 (감수 시마다 고지 / 옮긴이 김성훈)펴낸곳: 길벗 | 2026년 8월 25일 | 212쪽 | 22,000원원제: 伝わるコードレビュー — 개발팀의 생산성을 높이는 '잘 전달하는 법'의 교과서부제: 19가지 사례와 33가지 팁으로 배우는 개발자 말하기와 글쓰기

리뷰가 힘든 이유는 대개 코드가 아니었다

17년째 개발 현장에 있으면서 코드 리뷰 때문에 팀 분위기가 가라앉는 장면을 여러 번 봤습니다. 그런데 돌이켜보면 그 갈등의 원인이 '기술적으로 누가 맞느냐'였던 적은 거의 없습니다. 문제는 거의 항상 문장이었습니다. 리뷰어는 30초 만에 툭 던진 한 줄인데, 리뷰이는 그 한 줄을 열 번쯤 다시 읽으며 "이거 나 무시하는 건가?"를 고민합니다. 반대로 리뷰이가 아무 설명 없이 올린 500줄짜리 PR 앞에서 리뷰어는 "이걸 어디서부터 봐야 하지?" 하며 며칠을 미룹니다.이 책은 바로 그 지점만 팝니다. 코드 리뷰를 '버그를 찾는 절차'가 아니라 텍스트로 하는 협업으로 보고, 그 커뮤니케이션을 감각이나 인성의 문제가 아니라 배우고 훈련할 수 있는 기술로 다룹니다. 베타리딩을 하면서 가장 크게 끄덕인 부분이 이 관점이었습니다.

만요(万葉)라는 조직에서 나온 책

저자들은 일본의 개발회사 만요 소속이거나 그와 인연이 깊은 사람들입니다. 만요는 여러 고객사 현장에 투입되는 SES 형태로 일하면서, 기술만큼이나 텍스트 커뮤니케이션의 품질을 중요하게 여겨 왔다고 합니다. 15년 넘게 코드 리뷰를 개발 프로세스이자 사내 교육 수단으로 굴려 온 조직이라는 뜻입니다.그래서 책의 사례들이 만들어 낸 예시처럼 느껴지지 않습니다. "실제로 이런 코멘트가 오갔고, 이 문장 때문에 이런 오해가 생겼고, 그래서 우리는 이렇게 바꿨다"는 흔적이 남아 있습니다. 매끈한 원칙론이 아니라 시행착오의 기록에 가깝습니다.

3부 구성 — 원칙, 사례, 팁

PART 1 마음가짐: '전달력 있는 코드 리뷰'가 무엇인지 정의하고 5대 원칙을 세웁니다. 뒤에 나오는 모든 사례와 팁이 이 원칙 위에 얹힙니다.PART 2 실전: 19가지 사례. 긴장감 넘치는 리뷰 코멘트, 설명이 부족한 PR, 진행이 더딘 PR, 지나치게 자세한 코멘트, 방치된 논의, 감정적인 코멘트 등 제목만 봐도 "아, 이거 지난주에 우리 팀에서 있었던 일인데" 소리가 나옵니다.PART 3 TIPS: 33가지 팁. 퀴즈를 내지 않는다, 명령하지 않는다, 상대의 의도를 단정하지 않는다, 돌려 말하지 않는다, 기한을 명시한다, 리뷰어 지명 로직을 만든다처럼 한 줄로 요약되고 내일 바로 쓸 수 있는 것들입니다.212쪽으로 얇고, 사례 하나하나가 짧게 끊어져 있어서 앉은자리에서 두어 시간이면 완독됩니다. 대신 다 읽고 덮는 책이라기보다는 팀 위키에 옮겨 적고 두고두고 꺼내 보는 책에 가깝습니다.

밑줄을 그은 네 문장

베타리딩 중 특히 여러 번 되돌아간 대목들입니다.

1. 행간을 읽는 문화보다, 행간을 읽지 않아도 되는 문화를 만들라

"눈치껏 알아듣기"를 팀의 미덕으로 삼는 순간, 그 팀은 신입과 경력자 사이에 보이지 않는 진입장벽을 세우게 됩니다. 필요한 건 더 예민한 독해력이 아니라 더 명시적인 문장입니다.

2. 도구의 지적은 상대의 감정을 헤아릴 필요도, 사과할 필요도 없다

포맷·컨벤션 같은 기계적인 지적을 사람이 계속 하면 리뷰어는 잔소리꾼이 되고 리뷰이는 지적당하는 사람이 됩니다. Linter에 넘길 수 있는 건 전부 넘기고, 사람은 사람만 할 수 있는 논의(설계 의도, 대안, 트레이드오프)에 시간을 쓰자는 이야기입니다. 리뷰 문화 개선을 '말투 교정'으로만 접근하는 팀이 놓치기 쉬운 지점입니다.

3. 리뷰어는 리뷰이의 마음을 읽을 수 있는 초능력자가 아니다

리뷰가 지연되는 책임을 리뷰어에게만 묻는 팀이 많은데, 배경과 전제와 "어디를 봐 주면 좋겠는지"를 적어 주는 건 리뷰이의 몫입니다. 이 책이 리뷰어의 화법뿐 아니라 리뷰를 받는 쪽의 기술을 같은 비중으로 다룬다는 점이 좋았습니다.

4. 갈등 상황에서는 '문제 vs 우리' 구도를 만들라

'나 vs 너'로 놓이는 순간 그 스레드는 이기고 지는 게임이 됩니다. 목표는 상대를 이기는 게 아니라 납득시키는 것이라는 팁과도 이어집니다.

AI가 코드를 쓰는 시대에 오히려 더 필요한 책

요즘 팀에서 올라오는 PR 중 상당수는 사람이 처음부터 손으로 친 코드가 아닙니다. AI가 초안을 만들고 사람이 다듬어 올립니다. 코드를 만들어 내는 비용이 급격히 싸지면서 병목은 검토와 합의 쪽으로 옮겨 왔습니다. PR은 더 자주, 더 크게 올라오는데 그걸 읽고 판단하고 동료를 납득시키는 일은 여전히 사람의 몫입니다.그래서 이 책의 주제는 유행이 아니라 오히려 시의성이 있습니다. AI에게 리뷰를 시킬 수는 있어도, 리뷰 코멘트 하나 때문에 상한 동료의 마음을 AI가 대신 풀어 주지는 못합니다.

참고할 점 (모두에게 만능은 아닙니다)

솔직하게 적자면, 이 책은 리뷰의 기술적 기준을 알려 주는 책이 아닙니다. 무엇을 리뷰해야 하는지 — 설계 냄새, 성능, 보안, 테스트 커버리지 같은 판단 기준 — 를 기대하고 집으면 얇다고 느낄 수 있습니다. 그건 다른 책의 몫이고, 이 책은 "전달하는 방식"이라는 좁은 주제를 끝까지 파고듭니다.또 배경이 GitHub 스타일의 PR 리뷰와 일본 SES 조직 문화라서, 사내 규칙이나 조직 구조에 관한 조언은 각자 환경에 맞게 번역해서 읽어야 합니다. 다만 사례 자체는 도구나 언어를 가리지 않아서, Rails를 쓰든 Java를 쓰든 그대로 통합니다.

이런 분께 권합니다

리뷰 코멘트를 쓸 때마다 문장을 세 번씩 고쳐 쓰는 주니어지적은 정확한데 팀원들이 자기 PR을 슬슬 피하는 것 같은 시니어리뷰 문화를 만들고 싶은데 "서로 배려합시다" 이상의 구체적인 규칙을 못 만들고 있는 팀 리더신규 입사자 온보딩 자료에 넣을 만한 짧고 실용적인 텍스트가 필요한 팀

읽고 나서 팀에 적용해 볼 것들

리뷰 코멘트에 태그 붙이기 — 반드시 고쳐야 하는 것, 제안, 단순 질문, 취향 문제를 접두어로 구분해 라벨링합니다.Linter/포매터로 넘길 수 있는 지적은 전부 자동화합니다.PR 템플릿에 '배경', '중점적으로 봐 주었으면 하는 곳', '하지 않은 것'을 항목으로 넣습니다.리뷰어 지명 규칙을 정해 둡니다 — 아무도 자기 일이라고 느끼지 않아서 방치되는 PR을 막습니다.스레드가 3회 이상 왕복하면 채팅이나 대화로 전환합니다.

한 줄 평

코드 리뷰가 어렵다면 문제는 당신의 실력이 아니라 문장일 수 있습니다. 두 시간이면 읽고, 그다음 몇 년을 두고 써먹을 수 있는 얇고 단단한 책.
아래는 베타리딩 참여 후 책에 실린 추천평입니다.행간을 읽는 문화보다 행간을 읽지 않아도 되는 문화를 만들라, 도구의 지적은 상대의 감정을 헤아릴 필요도, 사과할 필요도 없다, 리뷰어는 리뷰이의 마음을 읽을 수 있는 초능력자가 아니다, 갈등 상황에서 '문제 vs 우리' 구도를 만들라는 조언 등 그대로 인용해 팀 위키에 올리고 싶은 문장이 많았습니다.— 이석곤 (아이알컴퍼니 17년차 AI&빅데이터 개발자)

『클로드 역대급 활용법』 리뷰 — 대화형 AI를 넘어 실제 업무를 맡기는 방법 - [클로드 역대급 활용법 with 코워크, 디자인, 코드, 스킬, 커넥터, 플러그인 - 자료 조사부터 PPT, 엑셀, 보고서, 대시보드, 디자인까지 클로드로 끝내는 AI 자동화]

leesk55 — Fri, 21 Aug 2026 22:57:00 +0900

클로드 역대급 활용법 with 코워크, 디자인, 코드, 스킬, 커넥터, 플러그인 - 자료 조사부터 PPT, 엑셀, 보고서, 대시보드, 디자인까지 클로드로 끝내는 AI 자동화
진한별 지음 / 영진.com(영진닷컴) / 2026년 08월

영진닷컴 서평 이벤트를 통해 도서를 제공받아 작성하는 리뷰입니다. #협찬

『클로드 역대급 활용법』 — 진한별 지음 / 영진닷컴 / 368쪽

클로드를 어디까지 활용하고 있는가

생성형 AI를 사용한다고 하면 아직도 질문을 입력하고 답변을 받는 장면부터 떠올리기 쉽다. 보고서 초안을 부탁하거나 긴 문서를 요약하고, 이메일 문장을 다듬는 정도만으로도 업무시간을 줄일 수 있다. 하지만 최근의 클로드는 단순한 대화형 도구에서 벗어나 파일을 읽고, 외부 서비스와 연결하고, 문서와 발표자료를 만들며, 정해진 작업을 직접 수행하는 방향으로 빠르게 확장되고 있다.

『클로드 역대급 활용법』은 이러한 변화를 한 권으로 따라갈 수 있도록 구성한 실무 활용서다. 클로드의 기본 사용법에서 시작해 아티팩트, 프로젝트, 커넥터, 스킬, 코워크, 플러그인, 디자인, 클로드 코드까지 현재의 클로드 생태계를 폭넓게 다룬다. 책의 부제에 코워크·디자인·코드·스킬·커넥터·플러그인이 모두 들어간 이유도 여기에 있다.

기능 설명보다 업무 흐름에 가까운 구성

이 책의 장점은 기능의 이름과 메뉴 위치만 나열하지 않는다는 점이다. 보고서와 이메일 작성, 긴 문서 분석, 표와 데이터 해석처럼 바로 활용할 수 있는 업무에서 출발한다. 이후 아티팩트로 대시보드와 간단한 앱을 만들고, 프로젝트에 자료와 지침을 넣어 특정 목적의 도우미를 구성하는 단계로 발전한다.

특히 프로젝트 기능은 반복 업무에 클로드를 적용하려는 사람에게 유용해 보인다. 매번 같은 배경과 작성 기준을 설명하는 대신 관련 자료와 지침을 하나의 프로젝트에 모아두면, 대화가 바뀌어도 일정한 업무 맥락을 유지할 수 있다. 고객 응대, 보고서 작성, 자료 검토처럼 기준과 참고자료가 반복되는 작업에 적용하기 좋은 방식이다.

커넥터와 스킬이 바꾸는 활용 범위

커넥터 부분에서는 구글 드라이브, Gmail, 노션, 슬랙 등 외부 서비스를 클로드와 연결하는 방법을 다룬다. 필요한 파일을 찾고 분석하거나, 메일을 기준에 따라 정리하고, 여러 채널의 대화를 모아 요약하는 식이다. 클로드가 단순히 사용자가 붙여 넣은 자료만 처리하는 것이 아니라 실제 업무 도구 안의 정보를 찾아 활용하는 단계로 넘어가는 것이다.

스킬은 반복해서 수행하는 작업 방법을 재사용할 수 있게 만든다. 책에서는 자료 조사와 PPT 제작을 각각의 스킬로 만들고 두 작업을 연결하는 과정까지 소개한다. 좋은 프롬프트 한 번을 만드는 데서 끝나는 것이 아니라, 잘 작동한 절차를 저장하고 반복 실행할 수 있는 형태로 발전시키는 흐름이다. 생성형 AI를 개인의 요령이 아닌 업무 프로세스로 정착시키려는 조직이라면 눈여겨볼 부분이다.

코워크로 파일 작업을 맡기다

가장 관심이 가는 부분은 클로드 코워크다. 일반 채팅이 질문과 답변을 중심으로 움직인다면 코워크는 작업 폴더를 기준으로 여러 파일을 읽고 결과물을 만드는 데 초점이 맞춰져 있다. 흩어진 자료를 모아 워드 보고서를 만들고, 신입사원 온보딩용 PPT와 발표자 노트를 작성하며, 엑셀 주문 데이터를 정리하고 수식과 차트를 추가하는 실습이 포함된다. PDF 생성과 병합, 분할까지 다뤄 실제 사무 업무와의 연결성이 높다.

생성형 AI의 효과는 답변의 문장이 얼마나 자연스러운가보다 업무의 시작부터 결과물 완성까지 얼마나 많은 단계를 맡길 수 있는가에서 결정된다. 그런 관점에서 코워크는 클로드의 변화를 가장 잘 보여주는 기능이다. 다만 실제 업무자료를 다룰 때는 접근 권한, 개인정보, 외부 전송 가능 여부와 결과 검수가 반드시 함께 고려되어야 한다.

디자인과 코드까지 이어지는 확장

후반부에서는 클로드 디자인을 활용한 슬라이드와 프로토타입 제작, 클로드 코드로 간단한 도구와 웹페이지를 만드는 방법을 다룬다. 개발 경험이 많지 않은 독자도 단위 변환기, 이미지 변환 도구, 뉴스 수집 도구 등을 직접 만들어보며 클로드가 코드를 어떻게 작성하고 수정하는지 경험할 수 있는 구성이다.

엑셀과 파워포인트, 크롬에서 클로드를 활용하는 방법도 별도로 소개한다. 데이터 정리와 슬라이드 제작, 현재 보고 있는 웹페이지 요약과 정보 수집 등 사용자가 기존에 일하던 화면 안으로 AI가 들어오는 흐름을 보여준다. 모바일 앱과 디스패치를 이용해 PC 작업을 요청하는 내용까지 포함되어 있어 클로드의 주요 기능을 전체적으로 훑어보기에 적합하다.

좋았던 점과 확인할 점

공개된 구성에서 가장 돋보이는 부분은 기초와 최신 기능 사이의 간격을 한 권에서 연결했다는 점이다. 클로드를 처음 접하는 독자는 요금제, 모델, 토큰과 사용량부터 시작할 수 있고, 이미 채팅 기능을 사용하던 독자는 프로젝트·커넥터·스킬·코워크처럼 한 단계 확장된 기능으로 바로 넘어갈 수 있다. 예제가 보고서, 이메일, PPT, 엑셀, PDF 등 실제 업무 산출물 중심이라는 점도 장점이다.

반면 클로드는 기능과 화면이 빠르게 바뀌는 서비스다. 책에 소개된 메뉴나 제공 범위가 이후 변경될 가능성은 감안해야 한다. 일부 기능은 요금제나 계정, 지역, 지원 환경에 따라 사용할 수 있는 범위가 달라질 수도 있다. 또한 커넥터와 자동 작업은 편리한 만큼 권한 설정과 정보보호 원칙을 먼저 정해야 한다.

이런 독자에게 잘 맞을 것 같다

이 책은 클로드를 처음 사용하는 사람뿐 아니라, 채팅과 문서 요약 정도로만 활용해 온 실무자에게 잘 맞을 것 같다. 보고서·PPT·엑셀 작업을 줄이고 싶은 직장인, 반복 업무를 프로젝트와 스킬로 표준화하려는 사람, 코워크와 클로드 코드를 통해 AI에게 더 긴 작업을 맡겨보고 싶은 개발자와 기획자에게 유용한 출발점이 될 수 있다.

마무리

『클로드 역대급 활용법』의 핵심은 클로드에게 좋은 답변을 받는 방법을 넘어, 하나의 업무를 어떻게 맡기고 결과물까지 완성하게 할 것인가에 있다. 대화, 문서 분석, 외부 서비스 연결, 반복 절차의 재사용, 파일 작업과 코드 작성이 하나의 흐름으로 이어진다.

클로드의 기능이 빠르게 늘어나 무엇부터 배워야 할지 막막했다면, 전체 지형을 파악하고 필요한 기능부터 직접 따라 해보는 안내서로 활용하기 좋다. 책을 읽은 뒤에는 모든 기능을 한꺼번에 적용하기보다 자신의 반복 업무 하나를 정해 프로젝트나 스킬, 코워크로 옮겨보는 것이 가장 현실적인 시작이 될 것이다.

『원하는 대로 튜닝하는 나만의 sLLM』 리뷰 — 내 업무에 맞는 작은 모델 - [원하는 대로 튜닝하는 나만의 sLLM - 비용은 낮게, 보안은 높게, 성능은 내 업무에 딱 맞게!]

leesk55 — Thu, 20 Aug 2026 22:36:00 +0900

원하는 대로 튜닝하는 나만의 sLLM - 비용은 낮게, 보안은 높게, 성능은 내 업무에 딱 맞게!
오지영 지음 / 길벗 / 2026년 07월

길벗 36차 개발자 리뷰어 활동으로 도서를 제공받아 읽고 솔직하게 작성한 리뷰입니다. #협찬
『원하는 대로 튜닝하는 나만의 sLLM』 — 오지영 지음 / 길벗 / 2026년 7월 / 372쪽

API 청구서와 보안 검토 사이에서

LLM을 업무에 붙여보려고 할 때마다 멈추는 지점이 있다. 프로토타입까지는 쉽다. API 키 하나 받고 몇 줄 붙이면 그럴듯한 데모가 나온다. 문제는 그다음이다. 호출량이 늘면 비용이 눈에 들어오기 시작하고, "사내 데이터를 외부 API로 보내도 되나요?"라는 보안 검토 앞에서는 데모가 아무리 좋아도 소용이 없다. 폐쇄망 환경이라면 애초에 선택지 자체가 없다.이 책의 부제가 "비용은 낮게, 보안은 높게, 성능은 내 업무에 딱 맞게!"다. 위의 세 가지 벽을 정확히 겨냥하고 있어서 책을 받고 목차부터 확인했다. 결론부터 말하면, sLLM이라는 주제를 개념 → 사례 → 학습 환경 → 파인튜닝 → 최적화 → 배포 → 트러블슈팅까지 한 권의 흐름으로 끌고 가는 책이다. 출판사 소개로는 국내 첫 sLLM 실전 가이드라고 하는데, 적어도 '파인튜닝 기법 소개'에서 끝나지 않고 서비스 적용까지 이어지는 구성이 흔치 않은 건 맞다.

'작아서 더 똑똑하다'는 말

sLLM은 말 그대로 작은 언어 모델이다. 초거대 모델 API를 호출하는 대신, 수십억 파라미터급 오픈소스 모델을 내 데이터로 튜닝해서 쓰는 접근이다. 범용 지식으로는 큰 모델을 이길 수 없지만, 좁은 도메인에서는 이야기가 달라진다. 우리 회사의 용어, 내 업무의 문서 형식, 우리 고객의 질문 패턴 — 이런 건 범용 모델이 아니라 내 데이터가 결정하는 영역이고, 여기서는 작게 튜닝한 모델이 충분히, 때로는 더 잘 싸운다.
1~3장은 이 지형을 그려주는 부분이다. LLM과 sLLM의 차이, 산업별 활용 사례, 지금 나와 있는 모델들의 트렌드. 개인적으로는 2장 산업별 사례 분석이 예상보다 쓸모 있었다. 기술서에서 사례 장은 건너뛰기 쉬운데, 사내에서 "이걸 왜 우리가 직접 해야 하는데? API 쓰면 되잖아"라는 질문에 답해야 하는 입장이 되면 결국 꺼내 쓰게 되는 재료가 이런 부분이다.

코랩 무료 환경 기준이라는 설계

실습이 구글 코랩 무료 환경 기준으로 구성되어 있다. 사소해 보이지만 이 책에서 가장 마음에 든 설계 중 하나다. 파인튜닝 자료들은 흔히 "고사양 GPU가 있다고 가정합니다"로 시작하는데, 그 문장 하나에서 상당수 독자가 따라 하기를 포기한다. 무료 코랩에서 돌아가게 만들었다는 건 저자가 독자의 GPU를 전제 조건이 아니라 제약 조건으로 놓고 책을 설계했다는 뜻이다.모델 선택도 실무적이다. LLaMA, Gemma, Phi 같은 오픈소스 모델을 다루되 한국어에 최적화된 모델을 우선 사용한다. 영어 벤치마크에서 점수 좋은 모델이 한국어 업무 문서 앞에서 무너지는 걸 겪어본 적이 있다면, 이 선택이 왜 중요한지 바로 이해될 것이다.

결국 핵심은 '효율적인' 파인튜닝

5~7장이 이 책의 중심축이다. 파인튜닝이 무엇인지에서 시작해 LoRA와 QLoRA 같은 효율적 파인튜닝 기법, 그리고 양자화를 포함한 최적화 기법으로 이어진다.이 부분에서 좋았던 건 전개 순서다. 기법을 카탈로그처럼 나열하는 게 아니라 "전체 파인튜닝은 왜 비싼가 → 그래서 어댑터만 학습하는 LoRA가 나왔다 → 메모리를 더 줄여야 해서 QLoRA까지 왔다"는 문제 → 해법의 흐름으로 읽힌다. 이렇게 이해해두면 내년에 새로운 기법이 나와도 그게 이 지도의 어디에 놓이는 기술인지 감을 잡을 수 있다. 유행이 빠른 분야일수록 오래 남는 건 이런 '왜'의 흐름이다.

튜닝하고 끝이 아니라 서비스까지

8장부터는 만든 모델을 밖으로 꺼내는 이야기다. FastAPI와 Gradio로 모델을 API와 데모 서비스로 만들고, RAG를 붙여 모델이 모르는 정보를 검색으로 보강하는 구성까지 다룬다.
목차에서 가장 반가웠던 건 마지막 10장 '실무에서 발생하는 문제 해결'이다. 튜토리얼은 언제나 성공하는 경로만 보여주지만 실제 작업은 실패 경로의 연속이다. 메모리가 터지고, 학습이 산으로 가고, 분명 따라 했는데 결과가 다르다. 이런 장이 별도로 있다는 건 저자가 강의실이 아니라 현장에서 이 과정을 여러 번 겪어봤다는 신호로 읽혔고, 입문자가 혼자 실습하다 좌절하는 지점을 꽤 정확히 짚는다.

좋았던 점과 아쉬웠던 점

좋았던 점.개념부터 배포, 트러블슈팅까지 한 권으로 이어지는 완결된 흐름. '파인튜닝 해봤다'가 아니라 '서비스로 만들어봤다'까지 데려간다.무료 코랩 기준 실습과 한국어 최적화 모델 중심이라는, 국내 독자에게 대단히 현실적인 선택.산업별 사례(2장)와 실무 문제 해결(10장)처럼 기술 바깥의 '설득'과 '운영'까지 커버하는 구성.아쉬웠던 점.모델 트렌드를 다루는 부분은 이 분야의 속도상 유효기간이 짧을 수밖에 없다. 다만 기법과 문제 해결 흐름 중심으로 읽으면 책의 수명은 훨씬 길다.372쪽에 10개 장이라 각 주제를 논문 수준으로 파고들지는 않는다. 이 책은 백과사전이 아니라 지도에 가깝다. 대신 지도로서는 좋은 지도다.배포가 FastAPI·Gradio 기반이라, 대규모 트래픽을 받는 프로덕션 서빙 인프라 수준은 이 책 다음 단계의 숙제로 남는다.

이런 분이라면 잘 맞을 것 같다

파이썬 기초는 있는데 LLM 파인튜닝은 처음인 개발자API 비용이나 보안 검토 때문에 사내 LLM 도입이 번번이 막혔던 실무자, 특히 폐쇄망·온프레미스 환경졸업 프로젝트나 사이드 프로젝트로 '나만의 모델'을 만들어보고 싶은 학생반대로 이미 PEFT 계열 논문을 챙겨 읽고 커스텀 학습 파이프라인을 운영 중이라면 아는 내용의 비중이 꽤 높을 것이다.

마무리

'거대 모델의 시대에 왜 작은 모델인가'라는 질문에 이 책은 이론이 아니라 실습으로 답한다. 코랩을 열고, 한국어 모델을 받아, 내 데이터로 튜닝하고, API로 만들어보는 과정을 한 바퀴 돌고 나면 sLLM이라는 선택지가 관념이 아니라 손에 잡히는 옵션이 된다. "API 말고 다른 선택지가 필요하다"는 생각을 한 번이라도 해봤다면 좋은 출발점이 될 책이다.⭐️⭐️⭐️⭐️☆ (4.5/5)구매 링크YES24: https://www.yes24.com/product/goods/193160264교보문고: https://product.kyobobook.co.kr/detail/S000220453121알라딘: https://aladin.kr/p/DCJsb#협찬 #길벗 #길벗출판사 #나만의sLLM #sLLM #LLM #파인튜닝 #LoRA #QLoRA #개발자책추천 #서평 #책리뷰

NoSQL을 넘어 AI 데이터 플랫폼까지 다루는 몽고DB 실전 안내서 - [몽고DB 8.0 인 액션 - 벡터 검색과 RAG를 포함한 몽고DB 아틀라스 데이터 플랫폼 완벽 가이드, 제3판]

leesk55 — Tue, 11 Aug 2026 21:52:00 +0900

몽고DB 8.0 인 액션 - 벡터 검색과 RAG를 포함한 몽고DB 아틀라스 데이터 플랫폼 완벽 가이드, 제3판
아레크 보루츠키 지음, 김인범 옮김 / 제이펍 / 2026년 07월

몽고DB를 JSON 형태의 데이터를 저장하는 NoSQL 데이터베이스 정도로만 생각했다면, 《몽고DB 8.0 인 액션》을 통해 몽고DB가 얼마나 넓은 데이터 플랫폼으로 발전했는지 확인할 수 있습니다.
책의 전반부에서는 도큐먼트 지향 데이터 모델과 CRUD 작업을 시작으로 스키마 설계, 집계 파이프라인, 인덱스, 다중 도큐먼트 트랜잭션, 복제와 샤딩까지 몽고DB의 핵심 기능을 체계적으로 설명합니다. 단순히 명령어를 나열하는 방식이 아니라 임베딩과 참조 중 어떤 구조를 선택해야 하는지, 인덱스와 샤드 키가 성능과 확장성에 어떤 영향을 미치는지 함께 설명한다는 점이 좋았습니다.
가장 인상 깊었던 부분은 몽고DB 아틀라스를 활용한 전문 검색과 벡터 검색, RAG 챗봇 구축입니다. 임베딩의 기본 개념부터 벡터 검색 인덱스 구성, 검색 쿼리 실행, 랭체인을 이용한 RAG 애플리케이션 구성까지 하나의 흐름으로 연결합니다. 최근 데이터 플랫폼과 생성형 AI를 함께 검토하는 실무자라면 특히 관심 있게 볼 만한 내용입니다.
후반부에서는 스트림 처리, 데이터 페더레이션, 온라인 아카이브, SQL 인터페이스, 차트와 트리거뿐 아니라 인증과 권한, 암호화, 백업, 성능 모니터링, 업그레이드까지 다룹니다. 개발 기능에서 끝나지 않고 실제 서비스 운영에 필요한 항목까지 포함한 점이 이 책의 큰 장점입니다.
628쪽의 적지 않은 분량이고 몽고DB 아틀라스 중심의 내용이 많아 모든 장을 한 번에 읽기보다는, 입문자는 앞부분부터 순서대로 읽고 경험자는 필요한 장을 참고서처럼 활용하는 방식이 잘 맞습니다.
몽고DB를 처음 배우는 개발자는 물론, 기존에 몽고DB를 사용했지만 최신 8.0 기능과 벡터 검색, RAG, 아틀라스 데이터 플랫폼까지 다시 정리하고 싶은 개발자와 데이터 엔지니어에게 추천합니다.
※ 제이펍 서평단 활동을 통해 도서를 제공받아 읽고 작성한 리뷰입니다.