[도서리뷰] AI 시스템 설계 - 데모에서는 잘 되던 AI가 운영에서 흔들리는 이유

[전자책] AI 시스템 설계 - 불확실한 AI를 운영 가능한 시스템으로 만드는 구조와 원칙
이한울 지음 / 한빛미디어 / 2026년 9월

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

요즘 AI 기능을 붙이는 일은 예전보다 훨씬 쉬워졌습니다. API를 연결하고 문서를 검색해 답변에 넣으면 데모 화면은 금방 나옵니다. 몇 가지 질문을 던져 보고 그럴듯한 답이 돌아오면 일단 안심하게 됩니다. 그런데 운영에 들어가는 순간 질문이 달라집니다. 답변이 틀렸을 때 검색 결과가 문제인지, 프롬프트가 문제인지, 모델이 맥락을 놓친 건지 어디서부터 봐야 할까요?

 
백엔드 개발에서는 장애가 나면 로그와 지표를 따라 원인을 좁혀 갑니다. AI 기능 앞에서는 그 익숙한 감각이 자주 막힙니다. 요청은 성공했고 응답도 왔는데 내용만 틀릴 수 있기 때문입니다. 게다가 에이전트가 외부 도구까지 사용한다면 잘못된 답변이 실제 행동으로 이어질 수도 있습니다.
 
<AI 시스템 설계>는 바로 이 지점을 다룹니다. 432쪽, 5개 부, 15개 장에 걸쳐 데모와 운영의 간극부터 LLM 파이프라인, RAG와 에이전트, 평가 데이터, 가드레일과 관측 가능성까지 이어집니다. 기능을 하나 더 붙이는 방법보다 만든 기능의 동작을 어떻게 확인하고 고칠 것인가에 무게를 둔 구성입니다.

데모의 뒤에서 사람이 하던 일

1부에서 눈에 들어온 절 제목은 '사람의 개입이 만든 데모 성공'입니다. 데모에서는 개발자가 질문을 고르고, 어색한 답이 나오면 입력을 바꾸고, 결과를 보여주기 전에 한 번 더 확인합니다. 화면에는 AI가 혼자 잘한 것처럼 보이지만 실제로는 사람이 뒤에서 품질을 관리한 셈입니다.
 
운영에서는 모든 요청 옆에 개발자가 서 있을 수 없습니다. 책이 말하는 하네스(Harness)는 그때 사람이 하던 통제와 판단을 반복 가능한 시스템 구조로 옮기는 방법입니다. 잘못된 입력을 다루고, 출력 형태를 확인하고, 실패했을 때 다음 행동을 정하는 일까지 모델 바깥에 설계합니다. 모델을 더 좋게 만드는 것만큼, 모델 주변에 어떤 경계를 둘지 생각하게 하는 대목입니다.

파이프라인을 나눠야 실패도 보인다

4장은 LLM 호출을 한 덩어리로 두지 않습니다. 입력 처리기, 프롬프트 구성기, LLM 호출기, 출력 처리기로 흐름을 나누고 상태 관리자와 오류 처리기를 곁에 둡니다. 93~94쪽의 그림에는 이 구성 요소들이 하나의 파이프라인으로 그려져 있습니다. 바로 아래 절 제목이 '교체·테스트·진단을 가능하게 하는 경계'인 것도 좋았습니다.
 
구성 요소를 나누는 이유가 코드 정리만은 아닙니다. 답변이 틀렸을 때 입력이 잘못됐는지, 프롬프트에 들어간 문맥이 부족했는지, 모델 호출 뒤 출력 처리에서 문제가 생겼는지 확인할 수 있어야 합니다. 백엔드에서 계층별 로그를 남기는 이유와 닮았습니다. 실패가 어디서 시작됐는지 보이지 않으면 개선도 추측에 머무릅니다.

RAG와 에이전트를 기능보다 구조로 보다

RAG를 붙이고도 부정확한 답을 받으면 검색 모델이나 벡터 DB부터 바꾸고 싶어집니다. 하지만 필요한 문서를 아예 찾지 못한 것과, 올바른 문서를 찾아 놓고도 답변에 반영하지 못한 것은 서로 다른 문제입니다. 5장은 RAG를 단일 검색 기능이 아니라 정보가 흘러가는 아키텍처로 바라봅니다. 파이프라인을 단계별로 나누고 어느 지점에서 정보가 어긋났는지 진단하는 구성입니다.
 
에이전트로 가면 경계는 더 중요해집니다. 계획·기억·도구가 연결된 시스템에서는 잘못된 판단이 잘못된 행동으로 이어질 수 있으니까요. 메일을 보내거나 데이터를 수정하는 도구까지 붙였다면 무엇을 허용하고, 어느 단계에서 멈추고, 문제가 생겼을 때 어떻게 되돌릴지 먼저 정해야 합니다. 저자도 인터뷰에서 에이전트가 현실에 영향을 미칠 수 있는 범위를 어디까지 허용할지가 중요한 설계 경계라고 설명합니다.

assertEqual에서 멈추는 순간

가장 오래 눈길이 간 부분은 11장의 테스트와 평가 이야기입니다. 일반적인 API라면 예상한 상태 코드나 응답값을 비교할 수 있습니다. AI 답변은 같은 뜻을 다른 문장으로 표현하고, 핵심 단어가 들어 있어도 전체 내용은 틀릴 수 있습니다.
 
277~278쪽에서는 정확한 문자열 비교를 넘어 의미 유사도와 키워드 포함 여부로 비교하는 예를 보여줍니다. 세 방법 모두 그럴듯해 보이지만 한 번 더 들여다보면 빈틈이 있습니다. 표현이 달라서 실패하는 테스트, 의미는 비슷해도 중요한 사실이 틀린 답변, 키워드만 들어 있고 엉뚱한 결론을 내린 답변을 생각해 보면 됩니다. 더 영리한 비교 함수 하나가 답변의 품질 판단을 대신해 주지는 않습니다.

실패한 질문을 다음 평가에 남기기

책의 중심축인 평가 주도 개발(EDD)도 이 문제에서 출발합니다. 서비스를 만들기 전에 무엇을 좋은 결과로 볼지 정하고, 그 기준을 평가 데이터와 운영 과정에 연결합니다. 챗봇이라면 답변의 정확성과 안전성이 중요할 수 있고, 다른 시스템을 직접 바꾸는 에이전트라면 중단과 복구 가능성이 더 큰 기준이 될 수 있습니다.
 
특히 운영에서 발견한 실패를 다시 평가 데이터에 넣는 흐름이 실무적으로 와닿습니다. 시연 때 준비한 질문에 계속 잘 답하는 것보다, 지난주에 틀렸던 질문을 이번 변경 뒤에는 어떻게 처리하는지 확인할 수 있어야 하니까요. 후반부에서 다루는 실패 신호와 트레이스, 체크포인트도 같은 방향을 향합니다. 최종 답변 하나만 남기지 말고 중간에 무슨 일이 있었는지 볼 수 있게 만들자는 것입니다.

---

총평 및 추천 대상

<AI 시스템 설계>는 AI 기능을 운영하는 개발자가 마주칠 질문들을 한 흐름으로 묶어 놓은 책입니다. 답변이 틀렸을 때 원인을 어떻게 찾을지, 무엇을 기준으로 개선됐다고 말할지, 에이전트에게 어디까지 맡길지. 모델을 선택한 뒤에 남는 일들입니다.
 
432쪽에 15개 장을 담은 만큼 한 가지 RAG 기법이나 특정 에이전트 프레임워크의 구현법만 깊게 파고들려는 분과는 기대가 다를 수 있습니다. 대신 여러 기술을 하나의 운영 가능한 시스템으로 연결하는 기준이 필요한 분에게 잘 맞겠습니다. 데모를 서비스로 옮겨야 하는 팀이라면, 책의 각 장을 설계 점검표처럼 따라가 볼 만합니다.

---

✅ 이런 분들에게 강력 추천합니다:

• LLM이나 RAG 데모는 만들었지만 운영 중 답변 품질을 어떻게 확인할지 막막한 개발자
• 모델을 바꿀 때마다 '전보다 좋아졌다'는 말을 근거 있게 하고 싶은 AI·백엔드 엔지니어
• 외부 도구를 쓰는 에이전트의 권한과 실패 범위를 설계해야 하는 팀 리드
• AI 기능의 로그·평가·복구 절차를 하나의 운영 흐름으로 묶고 싶은 분

데모가 한 번 성공한 것은 좋은 출발입니다. 다음에 같은 질문이 왔을 때도 믿을 수 있는지, 실패하면 어디서 고칠 수 있는지까지 설명할 수 있어야 비로소 서비스가 됩니다. AI를 실제 업무에 붙여야 하는 개발자라면 곁에 두고 돌아볼 만한 질문이 많은 책입니다.

AI가 답을 만드는 일과
그 답을 믿고 운영할 수 있게 만드는 일은 다르다.

[도서리뷰] 실전 AX 리포트 - AI는 도입했는데, 왜 아무도 쓰지 않을까?

실전 AX 리포트 - 1개에서 52개 계열사로, 국내 대기업 AX 팀의 AI 확산 실전 기록
박주혜.오현식.공득조 지음 / 한빛미디어 / 2026년 8월

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

요즘 저는 코드를 짤 때 AI 도구부터 켭니다. 개인 차원에서는 이미 AI 없이 일하던 시절로 돌아가기 어렵습니다. 그런데 시선을 회사 단위로 올리면 풍경이 달라집니다. 도입 공지가 올라오고 교육이 한 번 돌고 나면 그걸로 끝. 석 달 뒤 사용 현황을 열어 보면 숫자가 처참한 경우가 많습니다.

SI 업계에 있다 보니 이런 장면을 회사 안팎에서 봅니다. 고객사 제안요청서에는 어느새 AI 활용이 기본 항목으로 들어와 있는데 정작 도입 이후의 이야기를 해 주는 자료는 드뭅니다. 컨설팅 보고서는 너무 높이 날고 유튜브 후기들은 개인기에 가깝습니다. 조직 단위로 AI가 자리 잡는 과정을 처음부터 끝까지 보여주는 기록이 늘 아쉬웠습니다.

한빛미디어의 신간 <실전 AX 리포트>는 그 빈자리에 도착한 책입니다. 쓴 이들은 국내 한 대기업 AX 팀의 세 실무자, 박주혜·오현식·공득조 님입니다. 부서 하나에서 시작한 AI 활용이 52개 계열사, 3만 5천 명 규모까지 퍼져 나간 과정을 340쪽에 담았습니다. 7개 부, 22개 장. 전략과 예산에서 시작해 플랫폼 아키텍처와 에이전트, 보안을 지나 조직과 문화에서 끝나는 구성입니다.

실패담을 앞자리에 놓은 책

이 책의 첫인상은 목차에서 정해졌습니다. 1부 제목이 'AX, 왜 대부분 실패하는가'입니다. 성과 자랑으로 문을 여는 대신 상용 솔루션을 들여놓고 사용률 10%에 멈췄던 경험, 파일럿만 반복하다 시간이 흘러간 구간, 플랫폼을 세 번 갈아엎은 과정을 먼저 꺼냅니다. 저자들 표현으로는 '실패를 감추지 않는 것이 실패를 줄이는 가장 빠른 방법'이라서요.

출판사 소개에 나오는 문장 하나가 이 책의 태도를 요약합니다. 지금까지의 AX 이야기는 손에 잡히지 않는 무지개 같았다는 것. 그래서 저자들은 결론 대신 판단 과정을 남기기로 했습니다. 모델과 도구는 금방 낡지만 단계마다 무엇을 놓고 고민했고 어떤 기준으로 결정했는지는 오래 남는다는 이야기인데, 책 전체가 실제로 그 원칙대로 쓰였습니다.

---

PoC 지옥이라는 정확한 이름

1장에 'PoC 지옥'이라는 표현이 나옵니다. 파일럿은 성공하는데 전사 확산으로는 넘어가지 못하는 상태. 이 단어를 보는 순간 떠오르는 프로젝트가 몇 개 있었습니다. 시연회에서 박수를 받고 보고서가 한 바퀴 돌고 나면 그다음이 없습니다. 책은 이 현상의 원인을 프레임에서 찾습니다. 기술 도입과 AX를 같은 것으로 보는 착각, 킬러 유스케이스 하나만 찾으면 된다는 집착, 조직이 AI를 거부하는 진짜 이유까지 2장에서 하나씩 짚습니다.

2부는 실무자가 경영진을 설득하는 방법입니다. 눈에 들어온 건 4장 제목인데요. 'ROI 없이 시작하고, ROI로 증명하기'. 도입 초기에 ROI부터 요구하면 왜 일이 꼬이는지, 그 대신 어느 시점에 어떤 지표로 성과를 보여야 하는지를 정량 측정 프레임워크와 '숫자를 이야기로 만드는 법'으로 풀어 줍니다. 체험, 내재화, 혁신으로 이어지는 3단계 로드맵과 예산 제안서 구조까지 붙어 있어서 이 부만 떼어 읽어도 보고 자료 한 벌이 나올 것 같았습니다.

---

백엔드 엔지니어의 눈으로 읽은 플랫폼 파트

본업 관점에서는 3부가 가장 밀도 높게 읽혔습니다. 6장 첫 절 제목이 '왜 챗봇이 아니라 플랫폼이어야 하는가'인데, 여러 계열사를 하나의 플랫폼에 태우는 멀티 테넌시 설계, LLM 게이트웨이와 RAG 파이프라인, 권한 체계까지 전사 AI 인프라의 뼈대를 차례로 보여줍니다. 아키텍처가 1.0에서 4.0까지 진화해 온 과정을 버전별로 따라가는 절이 특히 좋았습니다. 처음부터 완성형 설계였을 리 없다는 당연한 사실이 오히려 위로가 되더군요.

7장은 모델 운영입니다. 상용과 오픈 소스 사이의 선택, 업무별·비용별 라우팅, 토큰 사용량 모니터링. 평소 관측 대시보드 들여다보는 일을 좋아하는 저는 비용 최적화 절에서 오래 멈춰 있었습니다. LLM 비용도 결국 운영 지표의 문제라 서버 모니터링과 같은 감각이 통합니다. 8장 멀티 에이전트 장은 Tool Use와 Function Calling, MCP 같은 요소 기술이 사내 시스템에서 어떻게 조립되는지 다루고 9장은 프롬프트 인젝션 방어, 계열사별 데이터 격리, 접근 제어 같은 보안·거버넌스로 이어집니다. 금융 전산을 거쳐 온 입장에서는 15장의 금융권 보안 기준을 충족한 구축형 플랫폼 사례와 함께 가장 현실적으로 읽힌 대목입니다.

확산의 병목은 결국 사람이었다

4부와 7부는 기술 밖의 이야기입니다. 파일럿 대상 선정에서 52개 계열사 롤아웃까지의 단계별 확산 전략, 3만 5천 명을 대상으로 한 온보딩 설계, 프롬프트 템플릿 라이브러리, AI 챔피언 프로그램. 도구를 깔아 주는 일과 쓰게 만드는 일 사이의 간극을 메우는 장치들이 구체적으로 나옵니다. '저항을 협력으로 바꾸는 일'이라는 절 제목처럼 현업의 반발을 신호로 읽는 관점도 인상에 남았습니다.

읽는 내내 우리 회사 생각을 했습니다. 계열사 52개는커녕 법인이 하나뿐인 작은 회사지만 가져올 만한 아이디어가 적지 않습니다. 전 직원 교육보다 챔피언 한두 명을 먼저 세우는 순서, 우수 사례를 모아 돌려 보는 체계 같은 것들은 규모와 무관하게 통할 테니까요.

---

마트 육류 판별부터 전자결재 연동까지

5부의 산업별 사례는 이 책에서 가장 재미있게 읽히는 대목입니다. 문화센터 강좌 추천이나 회의록 자동화처럼 예상 범위의 과제 사이에 마트 육류의 지방 비율을 판별하는 AI, 건설 현장의 실시간 번역, 지하철 혼잡도 분석, 수영장 안전 모니터링 같은 사례가 섞여 있습니다. 화려한 데모용 과제보다는 현장 부서의 골칫거리에서 출발한 과제들이라는 게 목록만 봐도 느껴집니다.

6부 기간계 연동은 SI 개발자에게 기시감이 드는 파트입니다. 그룹웨어와 전자결재, ERP와 CRM에 AI를 붙일 때 필요한 오케스트레이션 레이어, 그리고 '레거시 시스템 연동의 현실적 제약과 우회'라는 절 제목. 이 일을 해 본 사람이라면 제목만 봐도 어떤 밤들이 있었을지 짐작이 갑니다. 오픈AI 앱스 SDK로 챗GPT 안에 들어간 사례, 코파일럿·워크스페이스 AI와의 공존 전략, n8n 같은 자동화 도구와 MCP 기반 통합까지 2026년 시점의 선택지들이 정리되어 있습니다.

총평 및 추천 대상

덮고 나니 이 책의 정체는 세 권이 겹쳐진 물건에 가깝습니다. 경영진을 설득하는 전략서, 플랫폼 아키텍처 기술서, 조직 변화 관리서. 보통은 서로 다른 저자가 서로 다른 독자를 향해 쓰는 주제들이 한 조직의 실제 시간 순서로 묶여 있다는 점이 이 책의 희소성입니다.

물론 어디까지나 한 그룹의 기록이라는 점은 감안해야 하고요. 계열사 구조나 예산 규모가 다른 조직이라면 그대로 가져다 쓰기 어려운 대목도 있고 RAG나 에이전트 같은 각론의 깊이가 전문서 한 권을 대신하지도 못합니다. 다만 이 책의 쓸모는 판단의 순서와 기준을 보여주는 데 있으니 큰 흠으로 느껴지지는 않았습니다.

사용자 입장에서 생각하세요

[전자책] 사용자 입장에서 생각하세요 - 서비스를 살리는 15명의 까다로운 사용자
정그린 지음 / 한빛미디어 / 2026년 8월

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

백엔드 개발자로 일하다 보면 사용자를 만날 일이 거의 없습니다. 제가 매일 마주하는 것은 사용자가 아니라 요청 로그와 응답 코드, 대시보드의 그래프입니다. 그런데 장애 알림도 없고 에러율도 낮은데 이탈 지표가 슬금슬금 올라갈 때가 있습니다. 이럴 때는 어디서부터 봐야 할지 막막해집니다. 로그에는 찍히지 않는 문제이기 때문입니다.

그러면서도 회의실에서는 "사용자 입장에서는 이게 낫지 않을까요?"라는 말을 참 쉽게 씁니다. 이 책은 바로 그 지점을 찌릅니다. 우리가 말하는 '사용자 입장'이 사실은 서비스 구조를 다 꿰고 있는 설계자의 시선에 갇힌 상상 아니냐고요. 첫 장을 넘기기도 전에 뜨끔했습니다.

한빛미디어의 신간 <사용자 입장에서 생각하세요>는 제13회 브런치북 대상 수상작을 바탕으로 출간된 책입니다. 저자 정그린 님은 삼성전자에서 일하는 현직 UX 디자이너로, 브런치에서 'UX 사용자 도감' 연재를 통해 사용자 경험에 대한 인사이트를 공유해 온 분입니다. 그 연재의 콘셉트 그대로, 뭉뚱그려진 '사용자'라는 단어를 15명의 구체적인 인물로 쪼개서 400쪽 15개 장에 담았습니다.

사용자는 '한 명'이 아니라 15명이었다

목차를 보면 이 책의 성격이 한눈에 들어옵니다. 읽는 사용자, 똑똑하지 않은 사용자, 서두르는 사용자, 즐거운 사용자, 들어주는 사용자, 예쁜 게 좋은 사용자, 시작하는 사용자, 유혹되는 사용자, 불안한 사용자, 소통하는 사용자, 기다리는 사용자, 감성적인 사용자, 보수적인 사용자, 소외되는 사용자, 그리고 먼 나라의 사용자까지. 15명의 까다로운 사용자가 차례로 등장합니다.

'퍼소나'라는 단어는 실무에서 너무 많이 소비되어서 오히려 식상하게 느껴질 때가 있는데, 이 책의 인물들은 문서 속 가상 인물이 아니라 어제의 나, 오늘 아침의 우리 부모님처럼 읽힙니다. 저부터가 급할 때는 '서두르는 사용자'였다가, 결제 직전에는 '불안한 사용자'가 되니까요. 사용자는 고정된 집단이 아니라 상황과 맥락에 따라 얼굴을 바꾸는 존재라는 것이 이 책의 출발점입니다.

---

유형 분석 → 사례 탐구 → 디자인 가이드, 반복되는 3단 리듬

15개 장은 모두 같은 리듬으로 진행됩니다. 먼저 해당 사용자의 심리와 행동을 분석하고, 실제 서비스 사례를 탐구한 뒤, 마지막에 디자인 가이드로 정리해 주는 3단 구성입니다. 이 반복 구조가 주는 안정감이 꽤 큽니다. 어떤 장을 펼쳐도 "이 사람은 왜 이렇게 행동하는가 → 다른 서비스들은 어떻게 대응했는가 → 그래서 우리는 무엇을 해야 하는가"의 흐름으로 읽히기 때문입니다.

사례도 멀리 있지 않습니다. 카카오톡 개편이나 숙박 예약 서비스처럼 누구나 써 본 서비스들이 등장해서, 읽다가 "아, 그거!" 하고 무릎을 치게 됩니다. 다루는 주제의 폭도 넓습니다. UI 텍스트의 리듬감과 타이포그래피(1장), 온보딩 설계(7장), 게이미피케이션(4장), 다크패턴(8장), 웹 접근성(14장), 글로벌 서비스 설계(15장)까지, UX라는 큰 우산 아래 흩어져 있던 키워드들이 15명의 인물에게 하나씩 배정되어 있습니다.

개인적으로는 이 구조 덕분에 완독용 책이면서 동시에 레퍼런스용 책이 된다고 느꼈습니다. 온보딩 화면을 만들 일이 생기면 7장을, 리디자인 반발이 걱정되면 13장 '보수적인 사용자'를 다시 펼치면 되니까요.

백엔드 개발자를 뜨끔하게 한 두 사람, '기다리는 사용자'와 '불안한 사용자'

디자이너가 쓴 UX 책인데, 정작 가장 뜨끔했던 사람은 화면 한 장 만들지 않는 저였습니다. 특히 두 챕터가 그랬습니다.

먼저 11장 '기다리는 사용자'. 저는 대기 시간을 p95 레이턴시 같은 숫자로만 봐 왔습니다. 응답이 3초 걸리면 "느리네, 쿼리 좀 봐야겠다"라고 생각할 뿐, 그 3초 동안 화면 앞의 사람이 무엇을 보고 무슨 생각을 하는지는 제 관심사가 아니었습니다. 하지만 같은 3초라도 어떻게 보여주고 어떻게 기다리게 하느냐에 따라 사용자가 느끼는 시간은 전혀 달라집니다. 백엔드가 줄일 수 있는 건 물리적 시간이지만, 서비스가 줄여야 하는 건 체감 시간이라는 걸 새삼 배웠습니다.

그리고 9장 '불안한 사용자'. 오류를 어떻게 예방하고, 이미 발생한 오류에서 사용자를 어떻게 복구시킬 것인가를 다룹니다. 저는 에러 응답을 설계할 때 상태 코드와 에러 코드 체계까지는 고민해도, 그 에러가 사용자에게 어떤 문장으로 보이는지는 프론트엔드의 일로 미뤄 왔습니다. 제가 던진 500 에러가 사용자 화면에서 "알 수 없는 오류가 발생했습니다"라는 막막한 한 문장이 되는 순간, 사용자의 불안은 오롯이 사용자 몫이 됩니다. 결제 버튼 앞에서 머뭇거리는 사용자의 마음을 따라가다 보면, 에러 메시지 한 줄도 결국 시스템 설계의 일부라는 결론에 도달하게 됩니다.

'유혹되는 사용자'와 다크패턴, 되게 만드는 것과 옳게 만드는 것 사이

8장 '유혹되는 사용자'는 이 책에서 가장 논쟁적인 주제를 다룹니다. 사용자의 행동을 유도하는 설계와, 사용자를 속이는 다크패턴 사이의 경계입니다. 해지 버튼을 꼭꼭 숨겨 놓은 구독 서비스, 타이머를 돌려 조급함을 자극하는 마감 임박 표시 같은 것들을 우리는 매일 만나고, 어쩌면 만들고 있습니다.

이 책이 좋았던 건 "그러니 유도하지 말자"가 아니라 건강한 행동 유도의 원칙을 이야기한다는 점입니다. 4장 '즐거운 사용자'의 게이미피케이션과 나란히 읽으면 메시지가 더 선명해집니다. 사용자를 움직이게 만드는 기술 자체는 죄가 없고, 그 기술이 사용자의 이익과 같은 방향을 보고 있느냐가 문제라는 것. 전환율 지표 앞에서 흔들릴 때 꺼내 볼 만한 기준선을 하나 얻었습니다.

---

'소외되는 사용자'와 '먼 나라의 사용자', 배려가 아니라 설계 항목이다

책의 마지막 두 장은 웹 접근성(14장)과 글로벌 UX(15장)입니다. 이 배치가 의미심장합니다. 실무에서도 늘 우선순위의 마지막으로 밀리는 주제들이기 때문입니다.

접근성은 "여유 되면 챙기는 배려"가 아니라 처음부터 설계에 포함되어야 하는 항목이라는 걸, '소외되는 사용자'라는 인물의 눈으로 다시 보게 됩니다. 글로벌 서비스 설계도 마찬가지입니다. 저는 다국어 지원을 리소스 파일의 문자열 치환 문제 정도로 생각해 왔는데, 먼 나라의 사용자에게는 언어보다 훨씬 많은 것들, 문화와 맥락과 읽는 방향까지가 전부 경험의 일부더군요. 두 장 모두 "우리 서비스의 사용자 정의에서 조용히 지워진 사람들"을 다시 명단에 올려 주는 챕터였습니다.

---

총평 및 추천 대상

브런치 연재 출신답게 문장이 쉽고 사례가 가까워서, 400쪽인데도 에세이처럼 술술 읽힙니다. 그런데 덮고 나면 에세이가 아니라 체크리스트가 남습니다. 15명의 사용자 이름이 그대로 리뷰 관점이 되기 때문입니다. 실제로 저는 읽고 나서 지금 맡고 있는 서비스 화면을 열어 놓고 "서두르는 사용자라면? 불안한 사용자라면?" 하고 한 명씩 대입해 봤는데, 그동안 안 보이던 구멍이 몇 개 보였습니다.

아쉬운 점을 하나 꼽자면, 난이도가 초급으로 설계된 책이라 UX 실무 경력이 긴 분들에게는 이미 아는 이야기가 섞여 있을 수 있습니다. 다만 그런 분들에게도 흩어진 지식을 15명의 인물로 재정리하는 프레임 자체는 값어치를 한다고 생각합니다.

[도서리뷰] 누구나 이해하는 클라우드 인프라 지식 사전

누구나 이해하는 클라우드 인프라 지식 사전 - 개발자가 알아야 할 신뢰성, 성능, 보안, 운영의 핵심 원리 ㅣ 누구나 프로처럼 실전 AI
바바 도시아키 지음, 김완섭 옮김 / 한빛미디어 / 2026년 6월

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

AI가 코드를 대신 짜주는 시대에, 왜 장애는 여전히 사람의 몫일까?

2026년의 개발 환경은 몇 년 전과 완전히 달라졌습니다. AI 코딩 도구가 기능 구현의 속도를 몇 배로 끌어올렸고, 이제 "이 기능을 어떻게 만들지"는 예전만큼 어려운 질문이 아닙니다. 그런데 이상하게도, 새벽에 울리는 알람의 개수는 줄지 않았습니다.

응답 속도가 슬금슬금 느려지고, 트래픽이 조금 늘었을 뿐인데 어딘가에서 병목이 생기고, 배포한 뒤 장애가 났는데 원인을 짚지 못합니다. 이건 코드 품질의 문제가 아닙니다. 서비스는 서버, 네트워크, OS, 컨테이너, 클라우드, 모니터링, 보안, 운영 체계가 유기적으로 맞물려 돌아가는 물건이기 때문입니다. AI는 코드를 대신 써줄 수 있어도, 내가 모르는 계층의 문제를 대신 진단해주지는 않습니다.

한빛미디어의 신간 <누구나 이해하는 클라우드 인프라 지식 사전>은 바로 이 빈틈을 겨냥한 책입니다. 특정 벤더의 콘솔 사용법을 알려주는 매뉴얼이 아니라, 도구가 아무리 바뀌어도 변하지 않는 시스템의 기본 원리를 576쪽 23개 장에 한 흐름으로 정리한 책입니다.

---

인프라는 결국 '계층'을 보는 눈이다

이 책에서 가장 먼저 꺼내는 이야기는 클라우드 서비스가 아니라 계층 구조입니다. 시스템은 층으로 쌓여 있고, 계층화는 호환성과 분담을 위해 존재한다는 것. 너무 당연한 이야기 같지만, 실무에서 우리가 헤매는 대부분의 순간은 "지금 이 문제가 어느 층에서 벌어지고 있는지"를 특정하지 못할 때 발생합니다.

응답이 느리다는 신고 하나를 받았을 때, 그게 애플리케이션 코드인지, DB 커넥션 풀인지, 컨테이너 리소스 리밋인지, 아니면 그냥 DNS인지 구분하지 못하면 우리는 감으로 로그를 뒤지게 됩니다. 저는 이전에 서버리스 DB의 커넥션 풀이 고갈되는 문제를 잡느라 며칠을 태운 적이 있는데, 돌이켜보면 그건 어려운 문제였다기보다 어느 계층을 봐야 하는지 몰랐던 문제에 가까웠습니다.

1장이 마지막에 던지는 키워드가 인상적입니다. "You build it, you run it." 만든 사람이 운영한다는 원칙은 이제 슬로건이 아니라 기본값이고, 이 책 전체는 그 기본값을 감당할 수 있는 지식의 목록이라고 봐도 무방합니다.

---

가용성·용량·성능, 숫자로 말하는 법을 배우다

2장부터 4장까지가 이 책의 첫 번째 절정입니다. 가용성과 신뢰성을 측정하고, 용량과 부하를 관리하고, 성능을 튜닝하는 흐름이 순서대로 이어집니다.

특히 3장의 구성이 좋았습니다. 병목 지점의 처리량을 조절하는 기법에서 시작해 수평 확장(스케일 아웃/인), 수직 확장(스케일 업/다운), 그리고 확장의 한계를 뛰어넘는 분할까지 단계적으로 올라갑니다. "일단 인스턴스를 늘린다"는 반사적인 대응이 왜 어느 지점부터는 통하지 않는지, 그 한계선이 어디인지를 구조적으로 설명해 줍니다.

4장의 성능 튜닝은 더 실전적입니다. 성능 튜닝의 기본 흐름 → 부하 테스트 → 성능 개선 기술 → 용량 부족에 대처하는 기술 순서로 진행되는데, 측정 없는 튜닝은 그냥 추측이라는 당연한 원칙을 다시 확인하게 됩니다. 부하 테스트를 제대로 설계해 본 적 없이 "최적화했습니다"라고 말해왔던 스스로를 반성하게 만드는 챕터였습니다.

---

관찰 가능성, 이 책에서 가장 두꺼운 챕터

개인적으로 가장 오래 붙들고 읽은 곳은 14장 감시, 모니터링, 관찰 가능성(Observability)입니다. 무려 10개 절로 구성된, 이 책에서 가장 공들인 장 중 하나입니다.

이 장이 좋은 이유는 도구부터 소개하지 않는다는 점입니다. "관찰 가능성이라는 개념이 왜 등장했는가"를 먼저 묻고, 시계열 데이터와 데이터 가시화라는 기초를 깔아준 다음에야 실무 적용과 툴 이야기로 넘어갑니다. 요즘 옵저버빌리티 이야기가 곧바로 스택 이름 나열로 흘러가는 경우가 많은데, 이 책은 왜 그 스택이 필요해졌는지를 먼저 이해시킵니다.

그리고 장애 대응의 기본 원칙과 사후 분석(포스트모템)까지 같은 장 안에 넣어둔 구성이 마음에 들었습니다. 관측은 대시보드를 예쁘게 만드는 일이 아니라, 장애가 났을 때 원인에 도달하고 다음에 같은 일이 반복되지 않게 만드는 일이라는 걸 구조로 보여주기 때문입니다.

15장의 데브옵스와 SRE가 바로 뒤에 이어지는 것도 자연스럽습니다. 사용자 가치를 기준으로 신뢰성을 제어한다는 SRE의 사고방식, 그리고 플랫폼 엔지니어링까지, 조직이 이 지식을 어떻게 굴러가게 만드는지가 이어집니다.

---

배포와 릴리스는 다른 말이다

19장 릴리스 엔지니어링의 첫 절 제목이 "배포와 릴리스 구분"인데, 이 책의 성격을 잘 보여줍니다.

우리는 두 단어를 습관적으로 섞어 씁니다. 하지만 코드를 서버에 올리는 행위(배포)와 그 기능을 사용자에게 노출하는 행위(릴리스)를 분리해서 생각하는 순간, 블루-그린이나 카나리, 피처 플래그 같은 기법들이 왜 존재하는지가 한 번에 정리됩니다. 책은 대표적인 배포 기법과 릴리스 기법을 각각 정리한 뒤, CI/CD와 이들을 어떻게 조합할지, 그리고 릴리스 전 리뷰와 체크리스트까지 이어갑니다.

그 밖에도 실무에서 반드시 마주치지만 아무도 체계적으로 가르쳐주지 않는 주제들이 촘촘합니다. 7장의 HTTPS와 TLS 인증서, 9장의 가상화·컨테이너·도커·쿠버네티스, 11장의 프로덕션/스테이징/개발 환경과 멀티 테넌시 분리 기법, 17장의 구조화 로그와 로그 저장 기간, 18장 백업의 3-2-1 전략, 21장의 메일 전송, 22장의 컴플라이언스까지. 심지어 23장은 '취업'입니다. 이 지식들이 현장에서 어떤 기대치로 환산되는지를 마지막에 짚어주는 구성이 인상적이었습니다.

---

'사전(事典)'이라는 형식에 대하여

제목에 붙은 '지식 사전'은 마케팅 수사가 아니라 이 책의 실제 사용법입니다. 부록에 용어집과 찾아보기가 따로 붙어 있고, 각 장이 독립적으로 완결되어 있어서 순서대로 읽지 않아도 됩니다.

물론 단점도 있습니다. 넓게 다루는 만큼 각 주제의 깊이는 전문서 한 권을 대체하지 못합니다. 쿠버네티스를 제대로 파려면 쿠버네티스 책이 따로 필요하고, 보안도 마찬가지입니다. 하지만 이 책의 목적은 애초에 그게 아닙니다. 흩어져 있던 기술 키워드들을 하나의 서비스 구조 위에 배치해서, 내가 지금 무엇을 모르는지 알게 해주는 것. 저는 이걸 지도라고 부르고 싶습니다. 지도가 있어야 어디를 깊게 파야 할지도 정할 수 있으니까요.

번역도 깔끔합니다. 역자가 40여 종의 역서를 낸 현직 솔루션 아키텍트라서인지, 일본어 기술서 특유의 어색함 없이 용어가 자연스럽게 읽혔습니다.

---

총평 및 추천 대상

<누구나 이해하는 클라우드 인프라 지식 사전>은 당장 내일 복붙할 코드를 주는 책이 아닙니다. 대신 장애가 났을 때 어디를 봐야 할지 아는 개발자로 만들어주는 책입니다.

---

✅ 이런 분들에게 강력 추천합니다:

• 기능 구현은 자신 있지만, 장애·성능·운영 앞에서는 매번 검색부터 시작하는 개발자
• 쿠버네티스, 옵저버빌리티, CI/CD 같은 키워드를 따로따로 알고는 있지만 하나로 꿰어지지 않는 백엔드 엔지니어
• 주니어에게 인프라 기본기를 가르쳐야 하는데 마땅한 공통 교재가 없어서 곤란했던 팀 리드
• 클라우드를 쓰고는 있지만 그 아래에서 무슨 일이 벌어지는지 궁금했던 모든 개발자

도구는 계속 바뀝니다. AI는 앞으로 더 많은 코드를 대신 써줄 겁니다. 그래도 시스템을 지탱하는 원리는 그대로이고, 그 원리를 아는 사람과 모르는 사람의 차이는 장애가 났을 때 가장 선명하게 드러납니다. 책상 옆에 꽂아두고 필요할 때마다 펼쳐볼 한 권으로 권합니다.

코드를 잘 짜는 것과 서비스를 잘 굴리는 것은 다른 능력이다.
그리고 후자는 여전히, 사람이 알아야 한다.

혼자 코딩하고 혼자 Merge하는 AI의 폭주를 막다

[전자책] 하네스 엔지니어링 with 클로드 코드 - AI 에이전트 팀을 설계·운영하는 개발자의 실전 가이드, 누구나 프로처럼 실전 AI ㅣ 누구나 프로처럼 실전 AI
황민호 지음 / 한빛미디어 / 2026년 6월

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

2026년 현재, Claude Code나 Cursor 같은 AI 코딩 도구는 개발자의 일상이 되었습니다. 프롬프트 하나면 순식간에 코드를 뱉어내는 시대지만, 실무에 이를 적용하다 보면 곧 거대한 벽에 부딪히게 됩니다. 바로 단일 에이전트의 구조적 한계입니다.

가장 치명적인 문제는 AI가 '자신의 실수를 스스로 보지 못한다'는 점입니다. 혼자 PR을 작성하고 스스로 Merge해버리는 구조가 AI 에이전트의 기본값이기 때문입니다. 실제로 2025년 7월에는 한 기업에서 에이전트가 프로덕션 데이터를 삭제하고 "복구 불가"라고 거짓 보고를 했던 끔찍한 사고도 있었습니다.

이러한 통제 불능의 AI를 어떻게 시스템 안으로 안전하게 편입시킬 수 있을까요? 카카오 FDE팀의 황민호(로빈 황) 수석이 집필한 신간 <하네스 엔지니어링>은 이 질문에 대한 가장 완벽하고 체계적인 해답을 제시하는 최초의 실전서입니다.

책에서 말하는 '하네스'란 모델 내부의 가중치를 건드리는 것이 아닙니다. 대신 모델 바깥에 권한, 도구, 검증, 관측을 설계하여 에이전트가 통제된 환경 속에서 스스로 일하게 만드는 구조를 뜻합니다.

가장 충격적이었던 것은 저자가 직접 수행한 A/B 테스트 결과였습니다. 동일한 클로드 모델을 사용했음에도, 단순히 .claude/ 디렉토리의 환경 구성(하네스)을 바꾼 것만으로 성능이 49.5점에서 79.3점으로 수직 상승했다는 기록은 엔지니어로서 엄청난 인사이트를 주었습니다. '프롬프트 엔지니어링'이라는 주술적 영역에서 벗어나, 철저한 '시스템 아키텍처'의 영역으로 AI를 끌어올린 것입니다.

이 책은 하네스 시스템을 에이전트, 스킬, 오케스트레이터라는 세 가지 핵심 기둥으로 분해하여 설명합니다.

• 에이전트(Agent): 가드레일을 통해 에이전트가 '할 수 없는 것'을 파일로 명확히 정의합니다.
• 스킬(Skill): 'Description' 한 줄이 모델의 호출 여부를 결정한다는 원리(Why-First 원칙 등)를 통해, 도구를 정교하게 설계하는 법을 다룹니다.
• 오케스트레이터(Orchestrator): 이 책의 백미입니다. 3인 이상의 에이전트가 모였을 때 리더에게 병목이 생기는 현상을 막기 위해, 오케스트레이터를 이벤트 루프와 피어(Peer) 통신(TeamCreate, TaskCreate, SendMessage)으로 풀어내는 과정은 기존 분산 시스템 설계와 완벽하게 맞닿아 있습니다.

개발자로서 당장 실무에 적용해 보고 싶었던 파트는 후반부의 6가지 아키텍처 패턴이었습니다. 파이프라인, 팬아웃/팬인, 전문가 풀, 생성-검증, 감독자, 계층적 위임 등 상황에 맞는 패턴을 플로우차트를 통해 선택하는 기준을 제시합니다.

특히 코드 리뷰 자동화, 풀스택 기능 구현, 그리고 자그마치 3,500개의 레거시 테스트 파일을 마이그레이션한 시나리오 등은 현업에서 마주하는 골칫거리들을 AI 팀이 어떻게 해결할 수 있는지 완벽한 청사진을 제공합니다. 복잡한 파이썬 프레임워크 지식 없이, Git과 마크다운 파일만 다룰 줄 안다면 이 모든 파이프라인을 구축할 수 있다는 점이 이 책의 가장 큰 무기입니다.

---

- 총평 및 추천 대상

<하네스 엔지니어링>은 단순히 AI에게 일을 시키는 '사용자'를 넘어, AI가 일하는 '시스템'을 설계하려는 아키텍트를 위한 책입니다.

---

✅ 이런 분들에게 강력 추천합니다:

• 클로드 코드 등 AI 도구를 쓰고 있지만, 단일 에이전트의 잦은 실수와 한계에 부딪힌 개발자
• 하네스라는 개념을 들어봤으나, 실제 마크다운과 Git으로 어떻게 구현하는지 막막했던 분
• AI를 개인의 도구로 쓰는 단계를 넘어, 조직의 워크플로(코드 리뷰, 레거시 마이그레이션 등)에 도입하려는 리드 개발자

AI가 작성한 코드를 불안한 눈으로 지켜보는 대신, 견고한 하네스를 입혀 완벽하게 통제된 'AI 개발 팀'을 당신의 서버에 구축해 보시길 바랍니다.

AI를 통제하는 것은 마법 같은 프롬프트가 아니라,
견고하게 설계된 시스템 아키텍처다.