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


길벗 리뷰어 활동으로 도서를 제공받아 읽고 솔직하게 작성한 리뷰입니다. #협찬


『좋은 코드 리뷰 나쁜 코드 리뷰』 베타리딩 후기

  • 지은이: 토리이 유키, 쿠보 유코, 모로나가 아야카 (감수 시마다 고지 / 옮긴이 김성훈)
  • 펴낸곳: 길벗 | 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을 슬슬 피하는 것 같은 시니어
  • 리뷰 문화를 만들고 싶은데 "서로 배려합시다" 이상의 구체적인 규칙을 못 만들고 있는 팀 리더
  • 신규 입사자 온보딩 자료에 넣을 만한 짧고 실용적인 텍스트가 필요한 팀

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

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

한 줄 평

코드 리뷰가 어렵다면 문제는 당신의 실력이 아니라 문장일 수 있습니다. 두 시간이면 읽고, 그다음 몇 년을 두고 써먹을 수 있는 얇고 단단한 책.


아래는 베타리딩 참여 후 책에 실린 추천평입니다.

행간을 읽는 문화보다 행간을 읽지 않아도 되는 문화를 만들라, 도구의 지적은 상대의 감정을 헤아릴 필요도, 사과할 필요도 없다, 리뷰어는 리뷰이의 마음을 읽을 수 있는 초능력자가 아니다, 갈등 상황에서 '문제 vs 우리' 구도를 만들라는 조언 등 그대로 인용해 팀 위키에 올리고 싶은 문장이 많았습니다.

— 이석곤 (아이알컴퍼니 17년차 AI&빅데이터 개발자)



댓글(0) 먼댓글(0) 좋아요(0)
좋아요
l 공유하기 l 북마크하기찜하기 lthankstoThanksTo
 
 
 
클로드 역대급 활용법 with 코워크, 디자인, 코드, 스킬, 커넥터, 플러그인 - 자료 조사부터 PPT, 엑셀, 보고서, 대시보드, 디자인까지 클로드로 끝내는 AI 자동화
진한별 지음 / 영진.com(영진닷컴) / 2026년 8월
평점 :
장바구니담기




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

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



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

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

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

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

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

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

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

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

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



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

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

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



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

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

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




좋았던 점과 확인할 점

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

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

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

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

마무리

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

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


댓글(0) 먼댓글(0) 좋아요(0)
좋아요
l 공유하기 l 북마크하기찜하기 lthankstoThanksTo
 
 
 
원하는 대로 튜닝하는 나만의 sLLM - 비용은 낮게, 보안은 높게, 성능은 내 업무에 딱 맞게!
오지영 지음 / 길벗 / 2026년 7월
평점 :
장바구니담기


길벗 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)

구매 링크

#협찬 #길벗 #길벗출판사 #나만의sLLM #sLLM #LLM #파인튜닝 #LoRA #QLoRA #개발자책추천 #서평 #책리뷰


댓글(0) 먼댓글(0) 좋아요(0)
좋아요
l 공유하기 l 북마크하기찜하기 lthankstoThanksTo
 
 
 
몽고DB 8.0 인 액션 - 벡터 검색과 RAG를 포함한 몽고DB 아틀라스 데이터 플랫폼 완벽 가이드, 제3판
아레크 보루츠키 지음, 김인범 옮김 / 제이펍 / 2026년 7월
평점 :
장바구니담기


몽고DB를 JSON 형태의 데이터를 저장하는 NoSQL 데이터베이스 정도로만 생각했다면, 《몽고DB 8.0 인 액션》을 통해 몽고DB가 얼마나 넓은 데이터 플랫폼으로 발전했는지 확인할 수 있습니다.


책의 전반부에서는 도큐먼트 지향 데이터 모델과 CRUD 작업을 시작으로 스키마 설계, 집계 파이프라인, 인덱스, 다중 도큐먼트 트랜잭션, 복제와 샤딩까지 몽고DB의 핵심 기능을 체계적으로 설명합니다. 단순히 명령어를 나열하는 방식이 아니라 임베딩과 참조 중 어떤 구조를 선택해야 하는지, 인덱스와 샤드 키가 성능과 확장성에 어떤 영향을 미치는지 함께 설명한다는 점이 좋았습니다.


가장 인상 깊었던 부분은 몽고DB 아틀라스를 활용한 전문 검색과 벡터 검색, RAG 챗봇 구축입니다. 임베딩의 기본 개념부터 벡터 검색 인덱스 구성, 검색 쿼리 실행, 랭체인을 이용한 RAG 애플리케이션 구성까지 하나의 흐름으로 연결합니다. 최근 데이터 플랫폼과 생성형 AI를 함께 검토하는 실무자라면 특히 관심 있게 볼 만한 내용입니다.


후반부에서는 스트림 처리, 데이터 페더레이션, 온라인 아카이브, SQL 인터페이스, 차트와 트리거뿐 아니라 인증과 권한, 암호화, 백업, 성능 모니터링, 업그레이드까지 다룹니다. 개발 기능에서 끝나지 않고 실제 서비스 운영에 필요한 항목까지 포함한 점이 이 책의 큰 장점입니다.


628쪽의 적지 않은 분량이고 몽고DB 아틀라스 중심의 내용이 많아 모든 장을 한 번에 읽기보다는, 입문자는 앞부분부터 순서대로 읽고 경험자는 필요한 장을 참고서처럼 활용하는 방식이 잘 맞습니다.


몽고DB를 처음 배우는 개발자는 물론, 기존에 몽고DB를 사용했지만 최신 8.0 기능과 벡터 검색, RAG, 아틀라스 데이터 플랫폼까지 다시 정리하고 싶은 개발자와 데이터 엔지니어에게 추천합니다.


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


댓글(0) 먼댓글(0) 좋아요(0)
좋아요
l 공유하기 l 북마크하기찜하기 lthankstoThanksTo
 
 
 
바이브 엔지니어링 - 바이브 코딩을 넘어, AI를 무작정 믿지 않고 제대로 부려먹는 개발자 되는 법
제이 킴 지음 / 길벗 / 2026년 6월
평점 :
장바구니담기


길벗 35차 개발자 리뷰어 활동으로 도서를 제공받아 읽고 솔직하게 작성한 리뷰입니다. #협찬

코드가 너무 빨리 나올 때 드는 불안

요즘은 AI에게 기능을 설명하면 코드가 금방 나온다. 간단한 API나 테스트 초안 정도는 커피 한 잔 마시는 사이에 만들어질 때도 있다. 처음에는 마냥 신기했다. 그런데 이게 익숙해지니 다른 걱정이 생겼다.

“잘 돌아가긴 하는데, 이걸 그대로 운영에 올려도 되나?”

화면은 뜨고 응답도 온다. 그렇다고 좋은 코드라는 뜻은 아니다. 데이터가 많아졌을 때 느려지지 않을지, 동시에 요청이 몰리면 값이 꼬이지 않을지, 예외 상황에서 엉뚱한 데이터를 남기지는 않을지 확인할 게 한두 가지가 아니다. AI가 만들어 준 코드가 길수록 검토하는 쪽이 오히려 더 부담스러울 때도 있었다.

『바이브 엔지니어링』은 그 찜찜함을 그냥 넘기지 않는 책이다. AI를 쓰지 말자는 이야기는 전혀 아니다. 빨라진 만큼 개발자가 무엇을 더 꼼꼼히 봐야 하는지, 어디까지 맡기고 어디서부터 직접 판단해야 하는지를 다룬다.

도서 정보
제이 킴 지음 · 길벗 · 312쪽 · 2026년 6월 30일 출간

바이브 코딩 다음에 ‘엔지니어링’이 필요한 이유

책에서 말하는 바이브 코딩은 AI에게 원하는 기능을 이야기하고 빠르게 결과물을 얻는 단계다. 여기까지만 해도 생산성은 확실히 올라간다. 문제는 그다음이다. 요구사항이 모호하거나 전체 구조를 생각하지 않은 상태에서 코드를 계속 붙이면, 처음에는 빨랐던 프로젝트가 뒤로 갈수록 손대기 어려워진다.

바이브 엔지니어링은 한 걸음 더 간다. 무엇을 만들지 먼저 정리하고, 구조를 그리고, 필요한 맥락을 AI에게 전달하고, 작업을 작게 나눠 요청한다. 나온 결과는 테스트와 코드 리뷰로 확인한다. 말만 놓고 보면 기존 개발 방식과 크게 다르지 않다. 오히려 그게 이 책의 중요한 지점이라고 느꼈다. AI가 들어왔다고 소프트웨어를 만드는 기본 원칙까지 사라진 것은 아니기 때문이다.

솔직히 초반에는 “결국 요구사항 잘 쓰고 테스트하라는 말 아닌가?” 싶기도 했다. 그런데 읽다 보니 익숙한 원칙을 AI와 일하는 순서에 맞춰 다시 정리해 둔 데 이 책의 쓸모가 있었다. 알고 있는 것과 실제 작업에서 매번 지키는 것은 다른 문제니까.

목차에서 먼저 눈이 간 건 ‘조용한 버그’였다

문법 오류는 그나마 친절하다. 빨간 줄이 생기고 빌드가 실패한다. 반면 논리 오류는 아무 일도 없는 척 숨어 있다. 날짜 경계, 반올림, 빈 값, 중복 처리, 권한 조건처럼 실제 업무 규칙과 맞닿은 곳에서 이런 문제가 잘 생긴다.

AI가 만든 코드는 문법적으로 꽤 그럴듯해서 더 쉽게 안심하게 된다. 책은 “실행되는가?”에서 멈추지 말고 왜 이 로직이 맞는지, 반례는 없는지, 경계값에서도 같은 결과가 나오는지를 계속 확인하라고 말한다. 당연한 이야기인데, AI가 코드를 순식간에 쏟아내는 상황에서는 이 당연한 절차가 자주 생략된다.

비기능 요구사항을 다루는 부분도 비슷했다. 응답 시간, 보안, 동시성, 장애 복구 같은 조건은 프롬프트에 적지 않으면 빠지기 쉽다. AI가 알아서 못 챙겼다고 탓하기 전에 개발자가 먼저 기준을 세웠는지 돌아보게 됐다.

프롬프트를 잘 쓴다는 말이 조금 다르게 들렸다

프롬프트 관련 책이나 글을 보다 보면 특별한 문장 공식이 있을 것처럼 느껴질 때가 있다. 이 책은 그보다 훨씬 현실적으로 접근한다. 프롬프트는 멋진 질문이 아니라 작은 요구사항 문서에 가깝다는 것이다.

무엇을 만들지, 입력과 출력은 무엇인지, 지켜야 할 제약은 무엇인지, 예외는 어떻게 처리할지, 완료됐다고 판단할 기준은 무엇인지 적어야 한다. 막상 써보면 모델을 위한 기술이라기보다 개발자 스스로 문제를 제대로 이해했는지 확인하는 과정에 가깝다.

큰 작업을 한 번에 던지지 말고 설계, 인터페이스, 구현, 테스트처럼 나눠서 요청하라는 조언도 실용적이었다. 중간 결과를 보면서 방향을 고칠 수 있고, 문제가 생겨도 어느 단계에서 잘못됐는지 찾기 쉬워진다. “한 번에 완성해 줘”가 편해 보이지만 실제로는 수정할 때 더 오래 걸린다는 걸 몇 번 겪어본 사람이라면 바로 공감할 부분이다.

테스트는 AI를 못 믿어서 쓰는 게 아니었다

책을 읽으며 가장 오래 남은 부분은 테스트 코드였다. AI의 결과를 의심해서 테스트하는 것이 아니라, 사람과 AI가 같은 완료 기준을 보게 하려고 테스트를 만든다는 설명이 좋았다.

“정상적으로 동작하게 만들어 줘”는 사람마다 해석이 다르다. 반면 어떤 입력에서 어떤 결과가 나와야 하는지 테스트로 적어두면 훨씬 분명해진다. 기존 코드에 기능을 추가할 때도 먼저 테스트를 보강해 두면 AI가 건드려서는 안 될 범위를 알려줄 수 있다. 테스트가 검증 도구이면서 동시에 지시서가 되는 셈이다.

마지막에 컴퓨터 공학 기초와 도메인 지식을 강조하는 것도 인상적이었다. 기술적으로 말이 되는 코드라도 회사의 정산 규칙이나 권한 체계를 잘못 이해하면 결과는 틀린다. 결국 AI의 답이 맞는지 판단하려면 사람이 알고 있어야 한다. 도구가 좋아질수록 기초 공부가 덜 필요할 거라 생각하기 쉬운데, 오히려 반대에 가까웠다.

읽고 나서 작업 방식을 조금 바꿔봤다

거창한 변화는 아니다. AI에게 코드를 요청하기 전에 아래 정도는 먼저 적어두려고 한다.

  • 이 기능을 왜 만드는지 한 문장으로 써보기
  • 입력, 출력, 예외 상황을 빠뜨리지 않기
  • 성능이나 보안처럼 기능 밖의 조건도 같이 적기
  • 한 번에 맡기지 않고 리뷰할 수 있는 크기로 나누기
  • 완료 기준을 테스트나 체크리스트로 남기기

결과를 받은 뒤에는 설명을 읽고 끝내지 않고, 내가 이 코드를 다른 사람에게 설명할 수 있는지 확인한다. 설명이 안 되면 아직 내 코드가 아니다. 이 기준 하나만 있어도 AI가 만든 코드를 무심코 붙여 넣는 일이 꽤 줄어든다.

좋았던 점과 아쉬웠던 점

특정 도구의 화면이나 명령어에 매달리지 않는 점이 좋았다. Cursor나 Claude Code가 업데이트돼도 요구사항, 설계, 테스트, 검증이라는 뼈대는 남는다. 주니어 개발자 용이와 시니어 개발자 제이가 함께 문제를 풀어가는 구성도 딱딱한 내용을 읽기 편하게 만든다. 각 장 끝의 프롬프트와 체크리스트는 팀에서 그대로 고쳐 써도 괜찮아 보였다.

반대로 AI 코딩 도구를 처음 켜는 단계부터 따라 하는 실습서를 기대했다면 조금 다를 수 있다. 경험이 있는 개발자에게는 이미 아는 이야기처럼 느껴지는 부분도 있다. 다만 머리로 알고 있던 원칙을 실제 AI 협업 과정에 맞춰 한 줄로 세워주는 책은 생각보다 드물다.

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

  • AI가 만든 코드를 쓰고 있지만 어디까지 검토해야 할지 막막한 개발자
  • 빠르게 만든 결과물이 나중에 기술 부채로 돌아온 경험이 있는 분
  • AI 시대에 무엇을 공부해야 할지 고민하는 주니어 개발자
  • 팀의 AI 코딩 규칙이나 리뷰 기준을 만들려는 리더

마무리 ⭐️⭐️⭐️⭐️☆ (4.5/5)

이 책은 AI에게 코드를 덜 맡기라고 하지 않는다. 대신 더 잘 맡기고, 나온 결과를 제대로 책임지는 방법을 이야기한다. 읽고 나니 “AI를 잘 쓰는 개발자”의 의미가 조금 달라졌다. 프롬프트를 빨리 입력하는 사람이 아니라, 문제를 분명히 설명하고 결과가 맞는지 끝까지 확인할 수 있는 사람에 가깝다.

한 줄 평: AI가 짜준 코드 앞에서 ‘잘 돌아가네’로 끝내지 않게 해주는 책.

도서 링크

#협찬 #길벗 #길벗출판사 #바이브엔지니어링 #바이브코딩 #AI코딩 #생성형AI #개발자책추천 #서평 #책리뷰


댓글(0) 먼댓글(0) 좋아요(0)
좋아요
l 공유하기 l 북마크하기찜하기 lthankstoThanksTo