AI 투자 강의를 읽고

정지훈의 AI 투자 강의 - 실리콘·에너지·하이퍼스케일 데이터센터·스페이셜 컴퓨트·지능·디지털 AI·피지컬 AI·자본·지정학, 9개 키워드로 읽는 AI 투자 로드맵
정지훈 지음 / 한빛미디어 / 2026년 8월

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

AI 산업의 플라이휠을 찾아서

AI 투자를 생각하면 어떤 기업이 앞서갈지부터 궁금해집니다. 개발자로서 AI를 바라볼 때도 모델의 성능이나 그 모델로 만들 수 있는 제품에 먼저 눈길이 가고요. 그런데 AI 산업은 모델 하나만으로 움직이지 않죠. 반도체와 전력, 데이터센터처럼 제품 뒤에서 받쳐주는 조건도 함께 돌아갑니다. 한빛미디어 공개 미리보기에서 만난 플라이휠이라는 개념은 AI를 조금 더 바깥에서 바라보게 했어요.

성장은 어떤 고리로 이어질까?

미리보기의 아마존 사례가 기억에 남았습니다. 가격을 낮추면 고객이 늘고, 고객이 많아지면 판매자와 상품이 늘어납니다. 선택지가 넓어지면 이용 경험과 방문량이 좋아지고, 커진 규모는 다시 비용을 낮출 여지를 만들죠. 처음엔 그저 아마존이 성장한 과정을 설명하는 사례처럼 보였어요. 그런데 순서를 따라가다 보니 핵심은 성장 그 자체보다 한 요소가 다음 요소를 끌어당기고, 그 변화가 다시 앞의 요소를 강화하는 관계에 있었습니다. 제품을 만드는 관점으로 옮겨 생각해보면, 기능을 하나 잘 구현하는 것만큼 그 기능이 사용자의 다음 행동과 더 나은 경험으로 어떻게 이어지는지 보는 일도 중요하겠다는 생각이 들어요. 어느 한 지점의 개선이 다음 개선의 조건이 되어줄 때, 제품도 계속 앞으로 나아갈 수 있으니까요. 책은 PC와 인터넷, 스마트폰, 클라우드의 기술 흐름도 함께 보여줍니다. 시대마다 기술은 달랐지만, 새로운 가능성을 막던 제약이 풀리고 산업의 여러 요소가 서로를 밀어주는 순환이 생겼다는 점을 살펴보게 해요. 그 흐름을 AI에 가져오면 질문도 달라집니다. “어떤 기업이 이길까?”뿐 아니라, “지금 AI 산업의 성장을 막는 병목은 무엇일까? 그 병목이 풀리면 다음 제약은 어디에 생길까?”를 묻게 되죠.

AI를 모델 바깥에서 바라보기

공개 목차는 실리콘과 에너지, 데이터센터에서 공간 컴퓨팅, 지능, 디지털 AI와 피지컬 AI, 자본과 지정학까지 이어집니다. AI를 하나의 서비스나 소프트웨어가 아니라 서로 기대고 영향을 주는 산업의 구조로 보려는 것 같아요. 개발할 때는 사용자에게 보이는 기능과 경험에 집중하기 쉽습니다. 하지만 AI 제품이 어떤 속도와 규모로 성장할 수 있을지는 모델뿐 아니라 연산 자원과 인프라, 에너지 같은 조건에도 달려 있겠죠. AI 제품을 만드는 관점과 AI 산업을 이해하는 관점이 결국 만나게 되는 지점이라고 생각했어요. 미리보기에는 변수를 바꾸어 살펴보는 플라이휠 시뮬레이터도 소개되어 있습니다. 산업의 흐름을 눈으로 확인하고 여러 조건을 생각해보게 한다는 점은 흥미로워요. 다만 시뮬레이터의 결과가 미래를 그대로 예측해주는 것은 아닐 테니, 어떤 가정을 넣었는지와 그 가정이 바뀌었을 때 무엇이 달라지는지를 같이 보는 게 중요하겠다고 느꼈습니다.

마치며

AI를 제품으로 만들 때도, 산업의 변화를 읽을 때도 눈에 보이는 결과만으로는 충분하지 않을 수 있습니다. 지금의 성장을 가능하게 한 조건을 살피고, 그 조건이 달라지면 무엇이 다음 기회나 제약이 될지 생각해보는 것. 『정지훈의 AI 투자 강의』의 도입부는 AI 산업을 바라보는 시야를 그렇게 넓혀보자고 제안하는 듯했습니다.

개발자가 문서 작성도 잘해야 했어요

개발자가 문서 작성도 잘해야 하나요? - 글쓰기의 기본은 물론, AI와 함께 쓰는 법까지!
나카타 나오히로 지음, 김정민 옮김 / 길벗 / 2026년 8월

그동안 글쓰기가 기술 블로그의 출발점이 되고, 개발자의 생각을 정리하고, 질문하는 힘을 길러준다는 점을 직접 경험했어요.

개발자가 글을 쓸 일은 생각보다 많습니다. 코드뿐 아니라 커밋 메시지, PR, 코드 리뷰, 기능 명세서와 업무 문서도 다른 사람에게 생각을 전달하는 글입니다. 저는 이 점을 매일 글을 쓰며 조금씩 알아갔었어요.

그래서 『개발자가 문서 작성도 잘해야 하나요?』라는 제목은 제게 낯선 질문이 아니었습니다. 오히려 궁금했어요.

내가 그동안 글쓰기를 하며 어렴풋이 느껴왔던 것을 저자는 어떻게 정제해서 풀어냈을지 알고 싶었죠.

책을 읽으며 놀랐던 건, 제가 해오던 생각과 이 책의 관점이 많이 맞닿아 있었다는 점입니다. 제가 경험적으로 익힌 것을 더 정제되고, 근거와 논리를 갖춘 개념으로 만나는 과정이 무척 재미있었습니다.

문서 작성은 문장보다 먼저 설계하는 일

이 책은 글을 잘 쓰는 요령부터 이야기하기보다, 문서를 왜 쓰는지와 누가 읽을지를 먼저 생각하게 합니다.

공개 목차를 따라가면 문서의 목적을 설명형·보고형·설득형으로 나누고, 독자와 주제를 정한 뒤 내용을 세분화해 아웃라인을 만듭니다. 그다음 문단과 문장을 구성하고, 요구사항 정의서나 기능 명세서 같은 실무 문서에 적용합니다.

이 흐름에서 제가 특히 흥미롭게 본 것은 글쓰기와 프로그래밍을 연결하는 관점이었습니다.

프로그램을 만들 때 요구사항과 구조를 정리한 다음 코드를 작성하듯, 문서도 첫 문장부터 쓰기보다 독자와 주제를 정하고 구조를 설계한다는 거예요. 글쓰기와 프로그래밍 모두 처음의 설계가 뒤의 작업을 크게 좌우한다는 설명은 제가 글을 쓰며 느꼈던 점과 잘 맞았습니다.

매일 짧은 글을 쓸 때도 저는 소재를 정하고, 어떤 일이 있었는지 돌아보고, 그 경험에서 무엇을 느꼈는지 정리해야 했습니다. 글을 쓰려면 생각 정리가 먼저 필요했어요. 개발 구현 전에 요구사항을 분석하고 우선순위를 정하는 과정과 닮아 있었습니다.

저는 이 책에서 제가 해오던 방식을 새로 배운다기보다, 왜 그 방식이 글을 쓰고 전달하는 데 도움이 됐는지를 더 명확한 언어로 이해하는 재미를 느꼈습니다.

누구에게 무엇을 전할지 정하면 문서의 모양도 달라진다

같은 내용도 누가 읽느냐에 따라 전달 방식이 달라집니다. 개발자가 볼 기능 명세서, 사용자가 볼 매뉴얼, 진행 상황을 공유하는 보고서는 목적도 읽는 방식도 같지 않습니다.

이 책은 독자와 주제를 좁히고, ‘왜·무엇을·어떻게’로 내용을 나누며, 필요한 정보를 어떤 순서로 보여줄지 구성하도록 안내합니다. 결국 문서의 구조를 정하는 일은 읽는 사람이 내용을 이해하고 필요한 정보를 찾아가도록 돕는 일과 이어집니다.

이 점은 제가 글쓰기와 개발 문서를 바라봐온 태도와도 맞닿아 있습니다. 공개 글을 쓸 때는 내 생각을 표현하는 데서 멈출 수 없었습니다. 읽는 사람이 어디에서 들어오고 무엇을 알아야 할지 생각해야 했어요. 개발 문서와 PR에서도 마찬가지였습니다. 내가 아는 내용을 적는 것과 상대가 이해할 수 있게 설명하는 것은 다른 일이니까요.

초기 글쓰기 현황판에 적어둔 원칙도 떠올랐습니다. 책 내용을 그대로 옮기기보다 책 3, 내 생각 7의 비율로 쓰고, 실제 일상에서 겪은 경험과 단상을 담자는 것이었어요. 책에서 얻은 생각을 내 경험과 연결해 다시 설명하려 했던 태도가 이 책의 구조적 접근과 잘 어울렸습니다.

챗GPT는 대신 쓰는 사람이 아니라 함께 다듬는 도구

책 후반부는 챗GPT로 문서의 구성과 초안을 만들고, 문장을 교정하는 방법을 다룹니다. 동시에 챗GPT에 모든 것을 맡기기보다 도움을 받는 도구로 활용한다는 방향도 제시합니다.

저도 AI와 대화하며 생각이 더 깊어진 경험이 있습니다. 질문을 입력하려다 상황을 정리하는 과정에서 스스로 답을 찾기도 했어요. AI가 글의 구조를 제안하거나 초안을 만드는 데 도움을 줄 수 있지만, 어떤 맥락을 담아야 하는지와 실제 내용이 맞는지까지 저절로 판단해주지는 않습니다.

문서를 작성하는 사람이 자신의 경험과 목적을 먼저 정리하고, AI가 만든 결과를 확인하고 고치는 과정이 필요합니다. AI가 문장을 만들어주는 속도와 사람이 책임져야 하는 판단은 구분해야 하니까요.

그래서 AI 활용 장도 제게는 글쓰기를 AI에게 넘기는 방법보다, 내 생각과 정보를 더 잘 정리하기 위해 AI를 어디에 참여시킬지 생각하는 부분으로 다가왔습니다.

글쓰기를 해온 사람에게도 새롭게 읽히는 이유

이 책의 내용은 독자와 주제를 정하고, 문서 구조를 만들고, 문단과 문장을 다듬는 과정으로 이어집니다. 마지막에는 요구사항 정의서, 기능 명세서, 사용자 매뉴얼, 보고서의 구성 예시를 다룹니다.

저는 개발자 글쓰기를 이미 중요하게 여겨왔습니다. 그러면서도 내가 알고 있는 내용을 다른 사람이 이해할 수 있게 쓰는 일은 매번 생각과 설계를 필요로 한다는 점도 경험했어요. 이 책이 재미있었던 이유는 글쓰기의 중요성을 다시 주장해서가 아니라, 제가 경험으로 붙잡아온 생각을 더 정제된 구조로 설명해주었기 때문입니다.

책을 읽는 동안 제 글쓰기 경험과 저자의 관점이 계속 겹쳐 보였습니다. 감각적으로 알고 있던 것에 개념과 근거가 붙으니, “내가 이래서 글을 쓰고 있었구나”를 더 선명하게 이해할 수 있었습니다.

마치며

짧은 글쓰기는 제게 경험과 생각을 밖으로 꺼내고 정리하는 연습이자 실전이었어요. 이 책은 그 생각을 독자와 목적에 맞게 구조화해 문서로 만드는 과정을 보여주었습니다.

글쓰기를 처음 시작하려는 개발자에게는 어디서부터 시작할지 알려주는 안내가 될 수 있고, 이미 문서를 써온 개발자에게는 자신의 방식을 다시 살펴보고 정리하는 계기가 될 수 있습니다. 특히 글쓰기의 필요성을 이미 알고 실천해온 사람이라면, 경험으로 익힌 감각을 개념과 구조로 다시 만나는 재미가 있을 거예요.

지금은 육아를 하다보니 글쓰기를 매일 같이 하고 있지는 못하지만, 그동안 쌓은 경험이 사라지진 않은 것 같아요. 다시 글을 쓰고 개발 문서나 PR을 작성할 때, 누구에게 무엇을 어떤 순서로 전할지 한 번 더 생각해보고 싶습니다. 이 책은 제가 해오던 글쓰기를 낯설게 바꾸기보다, 그 안에 있던 생각을 더 잘 보이게 해준 책이었습니다.

나만의 AI 팀 빌딩하기

7인의 AI 드림팀 만들기 - 내 일을 대신 해주는 최강 AI팀 세팅법, 기획·마케팅·세일즈·데이터 분석·디자인·업무 자동화·바이브 코딩까지 with 클로드·제미나이·챗GPT·노트북LM·나노 바나나·캔바·캡컷·플로우·타입캐스트·수노·매그니픽·n8n
이비호(AI코딩밸리) 지음 / 길벗 / 2026년 7월

1. 이 책을 선택한 동기

저는 GPT API나 랭체인처럼 AI를 애플리케이션에 연결하는 방법에 관심을 두고 관련 책들을 읽어 왔습니다. AI 모델을 서비스에 붙이는 방법을 알아갈수록, 모델을 잘 호출하는 것만으로는 서비스가 완성되지 않는다는 생각도 함께 커졌습니다.

무언가를 만들려면 먼저 기획해야 하고, 시장과 경쟁사를 조사해야 합니다. 데이터를 분석하고, 화면을 디자인하고, 실제로 사용할 수 있는 형태로 개발해야 합니다. 만든 뒤에는 사람들에게 알리고, 어떤 반응을 보이는지 확인해야 합니다.

결국 혼자서 하나의 서비스를 만들려고 하면 개발자 역할만으로는 부족합니다. 기획자, 마케터, 디자이너, 데이터 분석가의 역할까지 어느 정도는 함께 맡아야 합니다. 그렇다고 작은 프로젝트마다 모든 분야의 사람을 채용하기도 어렵습니다.

AI를 잘 활용하면 이런 부족한 역할들을 보완할 수 있다는 이야기는 많이 들었습니다. 하지만 실제로는 AI에게 모든 일을 한꺼번에 맡기고 결과를 기다리는 방식에 가까웠습니다. AI를 어떻게 팀처럼 구성하고, 각 역할을 나누어야 하는지는 여전히 막연했습니다.

그런 궁금증으로 『7인의 AI 드림팀 만들기』를 읽게 됐습니다.

2. 어떤 책인지

『7인의 AI 드림팀 만들기』는 AI를 하나의 만능 도구로 사용하는 방법보다, 여러 AI에게 서로 다른 역할을 맡겨 하나의 팀처럼 활용하는 방법을 설명하는 실무서입니다.

책에서는 AI 기획자, 마케터, 세일즈 전문가, 데이터 분석가, 디자이너, 자동화 전문가, 웹 개발자로 역할을 나눕니다. 그리고 클로드, 제미나이, 챗GPT, 노트북LM, 이미지·영상 생성 도구, n8n 등 여러 도구를 활용해 각각의 업무를 실습합니다. 총 14개의 AI 도구와 130개의 실전 프롬프트를 다룬다는 점도 이 책의 특징입니다. 

처음에는 AI 드림팀의 개념과 경제적 가치를 설명하고, 이후 기획·마케팅·세일즈·데이터 분석·디자인·자동화·웹 개발을 차례대로 다룹니다. 마지막에는 이렇게 구성한 AI 드림팀으로 비즈니스를 만드는 과정과 AI의 한계까지 이야기합니다. 

목차만 보면 여러 분야를 한 권에 담은 종합 실습서에 가깝습니다. 하지만 책을 읽으며 제가 주목하게 된 것은 각각의 도구 사용법보다, 일을 바라보는 방식의 변화였습니다.

3. 특히 인상적이었던 점

AI를 잘 쓰는 것보다 일을 나누는 법이 중요하다는 점

AI를 사용할 때 가장 먼저 떠올리는 질문은 보통 “어떤 프롬프트를 입력해야 좋은 결과가 나올까?”입니다. 저도 그동안은 더 좋은 질문을 만들고 더 정교한 프롬프트를 작성하는 데 관심이 많았습니다.

그런데 이 책을 읽으며 프롬프트보다 먼저 정해야 할 것이 있다는 생각이 들었습니다. 바로 AI에게 어떤 역할을 맡길 것인지, 그리고 그 역할의 결과물을 어디에 사용할 것인지입니다.

기획자에게 경쟁사 조사를 맡긴다면 무엇을 조사할지 먼저 정해야 합니다. 데이터 분석가에게 일을 맡긴다면 어떤 가설을 확인할지, 어떤 지표를 볼지 결정해야 합니다. 디자이너에게 이미지를 요청할 때도 단순히 예쁜 이미지를 만들어달라고 하는 것이 아니라, 누구에게 어떤 메시지를 전달할 것인지 정해야 합니다.

결국 AI의 성능만으로 좋은 결과가 나오는 것은 아니었습니다. 일을 잘게 나누고, 역할을 구분하고, 필요한 자료를 제공하고, 결과를 다음 단계로 넘기는 과정이 필요했습니다.

AI를 한 명의 만능 비서로 생각할 때는 모든 일을 한 대화창에 쏟아 넣게 됩니다. 반대로 AI를 여러 명의 팀원으로 생각하면 각자에게 맡길 일을 구분하게 됩니다. 이 차이가 생각보다 컸습니다.

프롬프트보다 먼저 결과물을 정해야 한다

데이터 분석 파트도 인상적이었습니다. 책에서는 곧바로 데이터를 분석하기보다 테스트 가설과 KPI, 페르소나를 먼저 정하고 퍼널이나 코호트 리텐션을 분석합니다.

이 과정을 보면서 AI에게 분석을 맡길 때 가장 중요한 것은 분석 기능이 아니라, 무엇을 알고 싶은지 명확히 하는 일이라는 생각이 들었습니다.

AI는 데이터를 빠르게 정리할 수 있지만, 어떤 데이터를 모아야 하는지와 어떤 결과를 중요한 것으로 볼지는 대신 정해주지 못합니다. 분석 결과가 그럴듯하게 나와도, 처음 세운 질문과 연결되지 않는다면 실제 의사결정에는 도움이 되지 않을 수 있습니다.

이 점은 데이터 분석뿐만 아니라 기획, 마케팅, 개발에도 그대로 적용됩니다. AI에게 무엇을 만들어달라고 하기 전에 누가 사용할 것인지, 어떤 문제를 해결하려는지, 결과물이 어떤 모습이어야 하는지 먼저 정해야 합니다.

AI는 사람을 대체하는 직원보다 부족한 역할을 보완하는 팀에 가깝다

책의 제목에는 ‘드림팀’이라는 표현이 들어갑니다. 처음에는 AI가 사람을 대신해 여러 직무를 수행한다는 의미로 받아들였습니다.

하지만 책을 읽고 나서는 조금 다르게 보게 됐습니다. AI가 사람을 완전히 대체하는 팀이라기보다, 혼자 일하는 사람이 부족한 역할을 보완하기 위해 구성하는 팀에 가깝다는 생각이 들었습니다.

기획을 잘하지만 디자인이 어려운 사람도 있고, 개발은 할 수 있지만 마케팅이나 세일즈가 낯선 사람도 있습니다. 모든 사람이 일곱 가지 역할을 똑같이 잘할 필요는 없습니다. 자신의 강점은 직접 가져가고, 부족한 부분을 AI에게 맡기는 방식으로 접근할 수 있습니다.

다만 AI가 팀원처럼 일한다고 해서 사람의 판단까지 사라지는 것은 아닙니다. AI가 만든 기획안이 실제 고객의 문제를 해결하는지, 분석 결과가 믿을 만한지, 만든 서비스가 정말 필요한지는 결국 사람이 확인해야 합니다.

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

이 책을 읽기 전에는 AI 시대에 필요한 능력이 좋은 프롬프트를 작성하는 능력이라고 생각했습니다. 지금은 조금 달라졌습니다.

AI를 잘 활용하는 사람은 일을 적절하게 나누고, 필요한 자료를 준비하고, 결과를 검토하며, 여러 결과물을 하나의 목표로 연결할 수 있는 사람에 더 가깝다고 생각합니다.

AI에게 업무를 맡기는 것은 단순히 일을 줄이는 것이 아니었습니다. 오히려 어떤 일을 맡길지, 어디까지 맡길지, 결과를 어떻게 검증할지 결정해야 했습니다.

특히 하나의 AI에게 처음부터 끝까지 모든 일을 맡기는 방식보다, 기획·조사·제작·분석·검토의 단계를 나누는 방식이 더 현실적으로 느껴졌습니다. AI가 만든 결과를 그대로 이어 붙이는 것이 아니라, 한 역할의 결과를 다음 역할의 입력으로 전달하는 구조를 만들어야 했습니다.

5. 좋았던 점

가장 좋았던 점은 설명이 추상적인 수준에 머물지 않는다는 것입니다. 경쟁사 분석, 시장조사, 사업 기획안, 광고 시안, 데이터 대시보드, 자동화 워크플로, 웹 서비스 제작처럼 실제로 시도해볼 수 있는 업무를 예시로 다룹니다.

특히 웹 개발 파트에서는 간단한 프로그램부터 MBTI 검사나 회사 자산관리 자가진단 서비스까지 만들어봅니다. AI가 코드를 작성할 수 있다는 사실보다, 어떤 문제를 정의하고 어떤 데이터를 연결해 실제로 사용할 수 있는 형태로 만드는지가 더 중요하다는 점이 잘 드러나는 부분이었습니다.

또 하나의 도구만 정답처럼 제시하지 않는 점도 좋았습니다. 업무에 따라 클로드, 제미나이, 챗GPT, 노트북LM, 이미지·영상 생성 도구를 다르게 활용합니다. AI 도구를 선택할 때도 특정 서비스에 익숙해지는 것보다, 업무의 성격에 맞게 도구를 조합하는 관점이 필요하다는 것을 보여줍니다.

6. 아쉬운 점

다만 일곱 가지 직무를 모두 다루다 보니 각각의 분야를 깊이 이해하고 싶은 사람에게는 설명이 부족하게 느껴질 수 있습니다.

기획, 마케팅, 세일즈, 데이터 분석, 디자인, 자동화, 웹 개발은 각각만으로도 한 권의 책이 될 수 있는 주제입니다. 이 책은 각 분야에 입문하고 전체 흐름을 경험하기에는 좋지만, 특정 분야의 전문적인 방법론까지 자세히 다루지는 않습니다.

또한 AI 도구는 기능과 요금제, 화면 구성이 빠르게 바뀝니다. 책에 나온 실습 과정을 그대로 따라 하더라도 시간이 지나면 메뉴나 기능이 달라질 수 있습니다. 그래서 이 책을 읽을 때는 개별 도구의 사용법을 그대로 외우기보다, 역할을 나누고 입력과 결과물을 연결하는 구조를 중심으로 보는 것이 좋다고 생각합니다.

AI가 만들어주는 결과가 항상 일정하지 않고, 그럴듯한 거짓말을 할 수 있으며, 대화가 길어질수록 처음 정한 규칙이 흐려질 수 있다는 한계도 책에서 다룹니다. 결국 AI 드림팀을 만든다고 해서 관리해야 할 일이 모두 사라지는 것은 아닙니다.

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

앞으로는 AI에게 일을 한 번에 맡기기보다, 하나의 프로젝트를 여러 역할로 나누어보려고 합니다.

기획 단계에서는 해결하려는 문제와 대상 사용자를 정하고, 조사 단계에서는 근거가 될 자료를 모으고, 제작 단계에서는 결과물의 형태를 구체적으로 정하려고 합니다. 이후에는 분석과 검토 역할을 따로 두어 AI가 만든 결과를 다시 확인할 생각입니다.

이 리뷰를 작성하는 과정에서도 마찬가지였습니다. AI에게 처음부터 완성된 글을 요청하면 문장은 빠르게 만들어지지만, 정작 제가 이 책을 읽으며 무엇을 인상 깊게 보았는지는 흐려질 수 있습니다. 그래서 책의 내용과 제 생각을 먼저 나누고, 그 사이에서 어떤 판단이 바뀌었는지를 확인하는 과정이 필요했습니다.

『7인의 AI 드림팀 만들기』는 AI가 모든 일을 대신해준다고 말하는 책은 아닙니다. 오히려 AI를 여러 역할로 나누어 활용하려면 사람이 먼저 문제를 정의하고, 업무를 설계하고, 결과에 책임져야 한다고 말하는 책에 가깝습니다.

AI를 많이 아는 것과 AI와 함께 일하는 것은 조금 다른 문제였습니다. 이 책을 읽은 뒤에는 어떤 도구를 더 배울지보다, 지금 하려는 일을 어떤 역할로 나누어볼 수 있을지를 먼저 생각하게 될 것 같습니다.

AI가 두려웠던 나

AI가 두려운 당신에게 - 배경훈 부총리가 보내는 14가지 답변
배경훈.과학기술정보통신부 지음 / 한빛미디어 / 2026년 7월

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

최근 AI에 관한 책을 읽을 때면 모델의 성능이나 API를 어떻게 활용할지에 관한 내용을 먼저 찾아보게 됩니다. 저 역시 GPT API나 랭체인처럼 AI를 애플리케이션에 연결하는 방법에 관심을 두고 관련 책들을 읽어 왔습니다.

그런데 AI를 잘 활용하는 방법을 공부한다고 해서 모든 불안이 사라지는 것은 아니었습니다.

아이들은 무엇을 배워야 할까요? 직장인은 자신의 일을 계속할 수 있을까요? 이제 창업을 시작하려는 사람에게도 기회가 남아 있을까요? 회사 자료를 AI에 넣어도 괜찮을까요? 그리고 우리는 언제까지 OpenAI, Anthropic, Google이나 중국의 거대 기업이 만든 모델에 의존하게 될까요?

『AI가 두려운 당신에게』는 이런 질문에서 시작하는 책입니다.

1. 이 책을 선택한 동기

AI를 공부할수록 오히려 더 큰 질문이 생겼습니다.

처음에는 좋은 모델을 선택하고, 프롬프트를 잘 작성하고, AI를 업무에 연결하면 된다고 생각했습니다. 하지만 AI가 일하는 방식과 사회에 미치는 영향을 살펴볼수록 개인의 활용 능력만으로는 해결할 수 없는 문제가 보이기 시작했습니다.

어떤 일을 AI에게 맡겨야 하는지, 결과가 틀렸을 때 누가 책임지는지, 회사 자료를 어디까지 입력해도 되는지, 특정 기업의 서비스에 얼마나 의존해도 되는지 같은 문제입니다.

이 책은 이런 막연한 불안을 기술 용어로 덮지 않고, 아이를 키우는 부모와 직장인, 창업가, 기업가, 정책 담당자가 실제로 던질 법한 질문으로 풀어냅니다. 그래서 지금의 저에게 필요한 책이라고 생각했습니다.

2. 어떤 책인지

이 책은 AI 사용법을 단계별로 알려 주는 실습서는 아닙니다. 연구자로 AI를 개발해 온 저자가 정책 책임자의 자리에서 바라본 AI 시대의 변화를 설명하는 안내서에 가깝습니다.

책은 교육·업무·창업에서 시작합니다. 그다음 회사의 데이터 활용과 AI 기본법, GPU와 데이터센터, 소버린 AI를 거쳐 불평등·딥페이크·정보 유출 문제로 확장됩니다. 마지막에는 공장과 병원, 공공서비스, 국방·농업·돌봄·교통·금융의 변화와 5년 뒤의 하루를 그려 봅니다.

각 장은 “우리 아이에게 AI를 어떻게 가르쳐야 할까요?”, “AI가 업무에 들어오면 나는 무엇을 배워야 할까요?”, “그냥 챗GPT를 쓰면 되는데 왜 우리만의 AI가 필요한가요?”처럼 질문으로 시작합니다. 그리고 본문 뒤에는 관련 정책을 설명하는 정책 노트가 이어집니다.

덕분에 이 책은 AI를 하나의 앱이나 기능으로만 보지 않습니다. 개인이 사용하는 도구에서 회사의 업무 방식, 국가의 인프라와 정책, 국민의 일상으로 시야를 넓혀 갑니다.

3. 특히 인상적이었던 점

AI 시대에 아이들을 어떻게 가르쳐야 하는가

가장 먼저 인상 깊었던 내용은 아이들을 위한 AI 교육에 관한 부분이었습니다.

AI 교육을 생각하면 코딩을 더 일찍 가르쳐야 하는지, 어떤 학원에 보내야 하는지를 먼저 떠올리기 쉽습니다. 하지만 책은 질문을 조금 다르게 바꿉니다.

아이에게 AI를 가르쳐야 하는지가 아니라, 이미 아이의 손에 들어온 AI를 제대로 다루도록 어떻게 도와야 하는지를 물어야 한다는 것입니다.

AI는 정답을 대신 외워 주는 도구가 아니라 질문을 던지고, 답을 확인하고, 다시 질문을 다듬는 과정에서 활용해야 합니다. 부모의 역할도 AI 사용을 막거나 무조건 맡기는 데 있지 않고, 아이가 AI의 답을 자신의 생각과 비교하도록 돕는 데 있습니다.

특히 “자기 분야에 AI를 더하는 아이가 강해진다”는 방향이 기억에 남았습니다. 모든 아이가 AI 개발자가 될 필요는 없지만, 자신이 관심을 가진 분야에 AI를 어떻게 연결할 수 있는지는 배워야 한다는 의미로 이해했습니다.

AI 에이전트와 함께 일하는 법

AI 에이전트를 새로운 팀원에 비유한 점도 인상적이었습니다.

기존의 AI가 질문에 답하거나 문장을 보완하는 도구였다면, 에이전트는 목표를 전달받고 자료 조사, 정리, 실행, 결과 점검까지 하나의 업무 단위로 수행합니다.

이 설명을 읽으며 AI를 단순한 검색 도구로만 사용해서는 안 된다는 생각이 들었습니다. 중요한 것은 AI가 얼마나 많은 일을 대신할 수 있는지가 아니라, 어떤 일을 맡기고 어떤 결과를 사람이 검토할지 정하는 능력이기 때문입니다.

책은 동시에 AI가 책임을 질 수 없다는 사실도 분명히 합니다. 보고서가 틀려도 AI가 책임을 지지 않고, 의료·법률·세금·투자처럼 결과의 무게가 큰 영역에서는 사람이 반드시 결과를 확인해야 합니다.

AI를 팀원처럼 대하되, 사람처럼 믿어서는 안 된다는 점이 현실적으로 다가왔습니다.

거대 기업이 다루지 못하는 곳에 기회가 있다는 관점

AI 시대에는 이미 너무 늦은 것은 아닐까 하는 불안도 있습니다. 거대 기업들이 막대한 자본과 데이터를 가지고 경쟁하고 있으니, 이제 막 사업을 시작하는 사람에게는 기회가 남아 있지 않은 것처럼 보입니다.

책은 이 질문에 AI 산업을 하나의 나무에 비유해 답합니다. 거대 기업들이 경쟁하는 곳은 굵은 줄기이지만, AI라는 나무에는 아직 수많은 가지가 남아 있다는 것입니다.

범용 모델은 많은 사람이 공통적으로 사용할 수 있는 문제를 해결하는 데 강합니다. 반면 특정 산업의 복잡한 업무, 한 국가의 제도와 문화, 공개되지 않은 현장 데이터처럼 작고 깊은 문제는 거대 기업이 모두 다루기 어렵습니다.

그래서 한국어의 미묘한 맥락, 한국의 의료·금융·교육 제도, 특정 공장의 데이터처럼 우리 환경에 특화된 문제를 해결하는 Vertical AI에 기회가 있을 수 있다고 설명합니다.

이 부분을 읽으며 “이미 늦었다”는 말의 의미를 다시 생각하게 되었습니다. 거대 기업과 같은 범용 모델을 만드는 것이 유일한 경쟁 방식이라면 늦었을 수 있습니다. 하지만 자신이 잘 아는 현장의 문제를 AI로 해결하는 일까지 늦은 것은 아닙니다.

다만 아무 분야나 Vertical AI가 되는 것은 아닙니다. 도메인 지식과 실제 데이터, 고객의 구체적인 문제, 서비스를 전달할 방법이 함께 있어야 합니다. 그럼에도 거대 기업과 똑같은 것을 만들 필요는 없다는 관점은 창업을 고민하는 사람에게 중요한 출발점이 될 것 같습니다.

왜 한국만의 AI 모델이 필요한가

또 하나 인상 깊었던 부분은 OpenAI·Anthropic·Google이나 중국의 거대 기업이 만든 모델에 전적으로 의존하지 않고, 한국만의 AI 역량을 가져야 하는 이유에 관한 설명입니다.

처음에는 이런 의문이 생길 수 있습니다.

“이미 좋은 해외 모델이 있는데 굳이 한국형 모델이 필요한가?”

책은 이 문제를 단순한 성능 경쟁으로 설명하지 않습니다. 한국어의 맥락과 문화, 한국의 법과 제도, 의료보험과 금융 시스템, 공공 데이터와 국방 환경은 글로벌 범용 모델만으로 충분히 이해하기 어렵습니다.

또 지금은 편리하고 저렴하게 쓸 수 있는 서비스라도 가격과 정책이 바뀔 수 있습니다. 서비스 제공 기업의 결정이나 국제 정세에 따라 사용 조건이 달라졌을 때, 우리에게 대체할 수 있는 기술과 인프라가 없다면 편리함은 곧 의존이 될 수 있습니다.

그렇다고 해외 기술을 사용하지 말고 모든 것을 한국에서만 만들자는 뜻은 아닙니다. 글로벌 기술과 협력하면서도 중요한 데이터와 인프라, 운영 역량, 선택권을 스스로 확보해야 한다는 의미에 가깝습니다.

AI를 선택하는 기준에 성능과 가격만 있는 것이 아니라, 우리 사회의 맥락을 이해하는지, 데이터와 판단을 얼마나 통제할 수 있는지, 필요할 때 다른 모델로 바꿀 수 있는지도 포함된다는 사실을 이해하게 되었습니다.

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

이 책을 읽기 전에는 AI 시대를 모두가 같은 기술 경쟁에 참여해야 하는 시대로 생각했던 것 같습니다.

하지만 책을 읽고 나니 각자의 위치에 따라 준비해야 할 것이 다르다는 생각이 들었습니다.

아이에게 필요한 것은 코딩 기술만이 아니라 질문하고 검증하는 능력입니다. 직장인에게 필요한 것은 모든 AI 기술을 공부하는 일이 아니라, 자신의 업무에서 어떤 일을 AI에게 맡기고 어떤 판단을 직접 해야 하는지 구분하는 능력입니다.

창업가에게 필요한 것은 거대 기업과 같은 범용 모델이 아니라, 자신이 잘 아는 분야의 문제를 구체적으로 발견하는 일일 수 있습니다. 국가에는 국민 모두가 AI를 사용할 수 있는 접근성과 함께, 외부 기술을 주체적으로 선택할 수 있는 인프라가 필요합니다.

결국 AI를 잘 활용한다는 말은 프롬프트를 잘 작성하는 데서 끝나지 않습니다. 일을 나누고, 결과를 검토하고, 책임의 경계를 정하고, 필요한 기반을 요구하는 일까지 포함합니다.

AI가 자주 틀릴 수 있다는 사실도 다시 확인했습니다. 유창한 답변과 올바른 답변은 다릅니다. 앞으로 AI를 사용할수록 답변의 문장보다 근거와 출처를 확인하는 습관이 더 중요해질 것 같습니다.

5. 좋았던 점

가장 좋았던 점은 어려운 AI 정책과 인프라 이야기를 사람들의 생활 속 질문으로 바꿔 설명한다는 점입니다.

GPU와 데이터센터 이야기도 단순히 국가 경쟁력의 숫자로만 설명하지 않습니다. 그 자원이 연구자와 스타트업, 병원과 학교에 어떻게 연결되는지를 보여 줍니다.

AI 기본법과 보안 이야기도 법 조항의 나열로 끝내지 않고, 회사 자료를 챗봇에 입력해도 되는지, AI가 만든 결과물을 어떻게 표시해야 하는지처럼 실제 책상에서 생기는 고민으로 풀어냅니다.

또 공장·병원·공공서비스의 사례를 통해 AI의 성능보다 사람의 하루가 어떻게 바뀌는지가 더 중요하다고 말합니다. 공장에서 사람이 위험한 일을 덜 하게 되는지, 병원에서 환자의 불확실성이 줄어드는지, 공공서비스에서 기다리는 시간이 짧아지는지를 기준으로 AI의 가치를 바라봅니다.

AI를 처음 접하는 사람뿐 아니라, 이미 AI 도구를 사용하고 있지만 개인의 활용을 넘어 사회와 국가의 변화까지 이해하고 싶은 사람에게 잘 맞는 책이라고 생각합니다.

6. 아쉬운 점

14가지 질문을 폭넓게 다루는 만큼, 각각의 주제를 깊게 파고드는 책은 아닙니다.

예를 들어 Vertical AI가 기회가 될 수 있다는 설명은 설득력 있지만, 실제로 어떤 데이터와 기술 구조가 필요하고 시장에 진입하기 위해 무엇을 검증해야 하는지까지 자세히 다루지는 않습니다. AI를 활용해 창업을 시작하려는 사람이라면 추가로 더 구체적인 자료를 찾아봐야 합니다.

소버린 AI 역시 필요성은 이해할 수 있었지만, 한국형 모델을 지속적으로 개발하고 운영하는 데 필요한 비용과 해외 모델 대비 성능, 중복 투자 가능성 같은 현실적인 반론까지 충분히 다뤄졌는지는 아쉬웠습니다.

또 5년 뒤의 하루를 그린 부분은 AI가 사람의 시간을 돌려주고 생활을 편리하게 만드는 모습을 보여 주지만, 그 시간이 정말 개인에게 돌아오려면 회사와 사회가 어떤 규칙을 만들어야 하는지도 함께 논의되어야 한다고 느꼈습니다. AI가 줄여 준 시간이 또 다른 업무로 채워질 수도 있기 때문입니다.

다만 이런 아쉬움은 이 책이 정책 보고서나 실무 매뉴얼이 아니라, AI 시대를 처음 이해하기 위한 안내서라는 점을 고려하면 자연스러운 한계이기도 합니다.

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

이 책을 덮은 뒤 가장 먼저 해 보고 싶은 일은 익숙한 업무 하나를 AI에게 맡겨 보는 것입니다.

다만 리뷰 전체를 대신 쓰게 하는 방식은 아닐 것 같습니다. 책의 원문과 페이지, 제 메모를 먼저 분리해 정리하고, AI에게는 자료를 구조화하고 빠진 질문을 찾는 일을 맡기려고 합니다. 그다음 책의 주장과 제 해석이 섞이지 않았는지 확인하고, 최종적인 평가와 문장은 직접 책임지는 방식입니다.

이 과정은 책에서 말한 AI 에이전트와 함께 일하는 방법을 직접 연습하는 일이기도 합니다.

이제 AI를 사용할 때는 “AI가 내 자리를 빼앗을까?”라는 질문만 반복하지 않으려고 합니다.

대신 이렇게 질문해 보려 합니다.

어떤 일을 AI에게 맡길 것인가?
어떤 판단은 사람이 계속 책임져야 하는가?
그리고 이 기술을 특정 기업에 의존하지 않고도 선택할 수 있는가?

AI가 두려운 이유는 기술이 너무 강력해서이기도 하지만, 무엇을 해야 할지 아직 구체적으로 알지 못하기 때문일지도 모릅니다.

『AI가 두려운 당신에게』는 그 막연한 두려움을 단번에 없애 주는 책은 아닙니다. 대신 아이의 교육, 나의 일, 작은 사업, 국가의 기술 기반, 우리가 살아갈 일상을 차례로 바라보게 합니다.

그리고 AI 시대를 준비한다는 것은 모두가 AI 전문가가 되는 일이 아니라, 각자의 자리에서 AI에게 무엇을 맡기고 무엇을 직접 판단할지 알아 가는 일이라고 말합니다.

하네스 엔지니어링의 실체를 파악하다

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

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

하네스 엔지니어링의 중요성에 대해 줄곧 들어왔지만, 실체를 정확히 알고 있었다고 말하기는 어려웠습니다.

대략적인 감각은 있었어요. “AI가 일하기 좋은 환경을 만들어야 한다”, “에이전트를 잘 나눠야 한다”, “검증 루프가 필요하다” 정도의 문장들은 익숙했습니다. 하지만 그것이 실제로 어떤 파일로 남아야 하는지, 어떤 역할로 쪼개져야 하는지, 어떤 기준으로 스킬과 에이전트와 오케스트레이터를 분리해야 하는지까지는 선명하지 않았습니다.

『하네스 엔지니어링 with 클로드 코드』는 그 흐릿했던 감각에 구체적인 형태를 부여해준 책이었습니다.

이 책을 읽고 나서야 하네스 엔지니어링이 단순히 “AI를 더 잘 쓰는 요령”이 아니라는 점을 이해하게 되었습니다. 하네스는 모델 바깥에 역할, 권한, 도구, 검증, 관측, 협업 구조를 설계하는 일입니다. 다시 말해 AI에게 일을 시키는 기술이라기보다, AI가 일할 수 있는 환경을 만드는 기술에 가까웠습니다.

왜 모델보다 환경이 중요해지는가

책의 시작은 단일 에이전트의 한계에서 출발합니다. 이 점이 좋았습니다. 보통 AI 도구를 다루는 글은 “어디까지 할 수 있는가”를 먼저 보여주기 쉽습니다. 그런데 이 책은 오히려 혼자 일하는 AI가 왜 위험한지, 왜 자기 실수를 잘 보지 못하는지, 왜 권한이 넓을수록 문제가 커질 수 있는지를 먼저 이야기합니다.

이 문제의식은 실제 개발 업무와도 닮아 있습니다. 좋은 개발자 한 명이 모든 일을 다 할 수 있다고 해서, 모든 권한과 책임을 한 사람에게 몰아주는 조직이 좋은 조직은 아닙니다. 요구사항을 정리하는 사람, 구현하는 사람, 리뷰하는 사람, 배포를 검증하는 사람이 나뉘어 있을 때 실수를 발견할 가능성이 높아집니다. AI 에이전트도 마찬가지였습니다.

결국 문제는 모델의 지능만이 아니었습니다. 어떤 구조 안에서 일하게 할 것인가의 문제였습니다.

이 지점에서 책의 핵심 문장인 “모델이 아니라 하네스가 결과를 결정한다”는 말이 이해되었습니다. 이전에는 이 문장이 조금 선언처럼 느껴졌다면, 책을 읽고 나서는 실제 작업 구조에 관한 말로 받아들여졌습니다. 같은 모델이라도 어떤 역할을 부여받았는지, 어떤 도구를 쓸 수 있는지, 어떤 결과 기준을 따라야 하는지, 누가 검증하는지에 따라 전혀 다른 결과를 낼 수 있다는 뜻이었습니다.

에이전트, 스킬, 오케스트레이터를 분리해서 보기

책의 Part 02는 하네스를 이루는 핵심 요소를 에이전트, 스킬, 오케스트레이터로 나누어 설명합니다. 저는 이 구분이 하네스 엔지니어링의 실체를 이해하는 데 가장 중요하다고 느꼈습니다.

에이전트는 역할을 맡습니다. 단순히 “AI 하나”가 아니라, 특정한 책임 범위를 가진 작업자에 가깝습니다. 스킬은 반복 가능한 절차와 지식을 담습니다. 매번 대화로 설명할 필요 없이, 특정 상황에서 다시 꺼내 쓸 수 있는 작업 단위입니다. 오케스트레이터는 여러 에이전트와 스킬이 함께 움직일 때 전체 흐름을 조율합니다.

이렇게 나누고 나니, 제가 그동안 막연하게 “AI 워크플로우”라고 부르던 것들이 더 선명하게 보였습니다.

예를 들어 Bookgolas 작업을 할 때도, 그냥 “이슈 구현해줘”라고 말하는 것과 구조를 나누어 맡기는 것은 다릅니다. 요구사항을 정리하는 역할, 구현하는 역할, CodeRabbit 리뷰를 반영하는 역할, PR 설명을 작성하는 역할, daily ship까지 연결하는 역할은 서로 다릅니다. 이 역할들을 매번 즉흥적으로 설명하면 흐름이 흔들리지만, 파일과 스킬로 남기면 반복 가능한 작업 방식이 됩니다.

하네스 엔지니어링은 바로 이 지점을 다루고 있었습니다. AI에게 명령을 잘 내리는 것이 아니라, AI가 맡을 수 있는 역할과 재사용 가능한 절차를 설계하는 일이었습니다.

역할은 대화가 아니라 파일로 남아야 한다

Chapter 04의 에이전트 정의 파일 이야기는 이 책 전체의 핵심을 가장 선명하게 보여주는 부분이었습니다. 책에서는 에이전트 정의 파일을 단순한 설명서가 아니라 역할 계약서처럼 다룹니다.

이 표현이 인상 깊었습니다. 에이전트를 대화 중에만 정의하면, 그 역할은 세션이 끝나는 순간 사라집니다. 어제는 잘 굴러가던 팀이 오늘은 사라지는 이유가 여기에 있습니다. 어제의 대화 맥락 안에서는 역할과 기대치가 살아 있었지만, 파일로 남아 있지 않으면 오늘 다시 같은 팀을 재현하기 어렵습니다.

저도 비슷한 경험을 자주 했습니다. 어떤 날은 Hermes가 제가 원하는 방식으로 독서 기록을 정리하고, 어떤 날은 개발 채널의 맥락을 잘 이해하고, 어떤 날은 글쓰기 톤을 잘 맞춥니다. 그런데 그 맥락이 명시적인 skill이나 routing 문서로 남아 있지 않으면 다음 세션에서 다시 설명해야 합니다. 결국 좋은 결과를 만드는 것은 그날그날의 대화 감각이 아니라, 역할을 지속 가능한 파일로 남기는 구조였습니다.

이 책을 읽으며 제가 만들고 있던 channel routing, trigger map, skill 체계가 단순한 메모가 아니라 하네스의 일부라는 점을 더 분명히 이해하게 되었습니다.

스킬은 ‘알고 있는 것’이 아니라 ‘호출되는 것’이다

스킬 설계에 대한 설명도 좋았습니다. 예전에는 스킬을 “특정 작업을 잘하기 위한 지식 묶음” 정도로 생각했습니다. 하지만 책을 읽고 나니, 스킬에서 중요한 것은 지식을 얼마나 많이 담았는가가 아니라 적절한 순간에 호출되도록 설계되었는가였습니다.

Description이 호출을 결정한다는 설명이 특히 와닿았습니다. 아무리 좋은 절차와 규칙을 담고 있어도, 필요한 순간에 호출되지 않으면 없는 것과 다르지 않습니다. 반대로 모든 문서를 항상 들고 있으면 맥락이 무거워지고 판단이 흐려집니다. 필요한 순간에 필요한 만큼 펼쳐지는 구조가 중요합니다.

이 부분은 제가 Hermes를 쓰며 계속 부딪히는 문제와도 연결됩니다. 독서 리뷰를 쓸 때는 book-review skill이 필요하고, Notion에 작성할 때는 Notion API 방식이 필요하고, 개발 작업에서는 daily-ship이나 work-build 같은 skill이 필요합니다. 중요한 것은 이 모든 지식을 한꺼번에 들고 있는 것이 아니라, 상황에 맞게 정확히 불러오는 일입니다.

스킬은 저장된 문서가 아니라 실행되는 작업 기억에 가까웠습니다.

오케스트레이터는 병렬 작업의 안전장치다

오케스트레이터 장에서는 하네스가 개인 생산성을 넘어 팀 구조로 확장됩니다. 에이전트가 한두 명일 때는 단순히 역할을 나누는 것만으로도 충분할 수 있습니다. 하지만 여러 에이전트가 동시에 움직이고, 작업 사이에 의존성이 생기고, 결과를 모아 판단해야 하는 순간부터는 전체 흐름을 조율하는 구조가 필요합니다.

이 부분을 읽으며 병렬 에이전틱 코딩을 떠올렸습니다. 여러 worktree에서 Claude Code나 OpenCode를 동시에 돌리면 속도는 빨라질 수 있습니다. 하지만 역할과 경계가 명확하지 않으면 서로 다른 방향으로 구현하거나, 같은 파일을 건드리거나, 마지막에 합치기 어려운 결과가 나오기 쉽습니다.

오케스트레이션은 단순히 여러 에이전트를 띄우는 기술이 아니었습니다. 누가 어떤 작업을 맡고, 어떤 순서로 진행하고, 어떤 결과물을 서로 전달하고, 어디서 검증하고, 언제 종료할지를 정하는 안전장치였습니다. 병렬화가 생산성이 되려면, 그 전에 조율 구조가 있어야 했습니다.

메타스킬과 아키텍처 패턴이 보여준 것

Part 03에서 다루는 메타스킬과 아키텍처 패턴은 하네스 엔지니어링을 한 단계 더 추상화합니다. 처음에는 에이전트와 스킬을 직접 만듭니다. 그런데 이런 팀을 반복해서 만들다 보면, 팀을 만드는 과정 자체도 하나의 스킬이 될 수 있습니다.

도메인을 분석하고, 팀 아키텍처를 설계하고, 에이전트와 스킬을 만들고, 오케스트레이션을 구성하고, 검증하는 과정은 반복됩니다. 그렇다면 이 반복 자체를 하네스로 만들 수 있습니다. 이 발상이 재미있었습니다. 자동화의 대상이 단순 작업에서 “작업 구조를 만드는 일”로 올라가는 느낌이었습니다.

여섯 가지 아키텍처 패턴도 실용적으로 느껴졌습니다. 파이프라인, 팬아웃·팬인, 전문가 풀, 생성-검증, 감독자, 계층적 위임 같은 패턴은 AI만의 특별한 개념이라기보다 조직 설계나 분산 시스템에서 익숙한 사고방식과 닮아 있었습니다. 그래서 더 설득력 있었습니다.

특히 생성-검증 패턴과 팬아웃·팬인 패턴이 기억에 남았습니다. AI가 만든 결과를 다른 AI가 검증하거나, 하나의 문제를 여러 관점에서 본 뒤 다시 합치는 방식은 실제 개발 업무에서 바로 써볼 수 있는 구조입니다. AI에게 일을 맡길수록, 잘 만드는 역할만큼 잘 의심하는 역할도 중요해진다는 생각이 들었습니다.

하네스는 한 번 만들고 끝나는 것이 아니다

Chapter 10의 하네스 등록과 진화는 제가 실제로 가장 오래 가져가야 할 부분처럼 느껴졌습니다. 하네스는 한 번 만들어두는 설정 파일이 아니라, 계속 운영하며 진화시키는 작업 환경입니다.

처음 만든 규칙은 언제든 틀릴 수 있습니다. 실제로 써보면 호출 조건이 애매하거나, 역할이 겹치거나, 검증 단계가 부족하거나, 너무 무거워서 잘 쓰이지 않는 절차가 드러납니다. 그러면 다시 고쳐야 합니다. 변경 이력을 남기고, drift를 감지하고, 피드백을 반영하고, 필요하면 부분 재실행해야 합니다.

이 부분에서 하네스 엔지니어링은 단순 자동화와 다르다고 느꼈습니다. 자동화는 정해진 절차를 반복하는 느낌이 강하지만, 하네스는 반복을 통해 더 나은 작업 방식으로 진화해야 합니다. AI를 위한 환경을 만드는 동시에, 내가 일하는 방식을 관찰하고 개선하는 시스템이기도 했습니다.

실전 팀 사례가 개념을 현실로 끌고 온다

Part 04의 코드 리뷰 자동화 팀, 풀스택 기능 구현 팀, 레거시 마이그레이션 팀, 디버깅/RCA 팀은 앞에서 설명한 개념을 현실적인 개발 장면으로 옮겨줍니다.

코드 리뷰 자동화 팀은 생성과 검증을 분리하는 구조를 보여줍니다. 풀스택 기능 구현 팀은 하나의 기능도 여러 역할로 나눌 수 있음을 보여줍니다. 레거시 마이그레이션 팀은 반복적이고 규모가 큰 작업에서 하네스가 왜 필요한지 보여줍니다. 디버깅/RCA 팀은 단순히 문제를 고치는 것을 넘어, 원인을 추적하고 재발 방지까지 연결하는 구조를 보여줍니다.

이 사례들이 좋았던 이유는, 하네스 엔지니어링이 멋진 개념에서 끝나지 않고 실제 개발자가 마주치는 문제로 내려오기 때문입니다. “로컬에선 잘 되는데요” 같은 문제는 너무 익숙한 장면입니다. 이런 문제를 AI에게 맡길 때도 관측, 역할 분리, 검증, 책임 경계가 필요하다는 점이 자연스럽게 이해되었습니다.

좋았던 점

첫째, 이 책은 AI 도구를 낙관적으로만 다루지 않습니다. 단일 에이전트의 위험과 구조적 한계를 먼저 짚고, 그 한계를 다루기 위한 방식으로 하네스를 제안합니다. 생산성보다 신뢰성을 먼저 이야기하기 때문에 오히려 실무적으로 느껴졌습니다.

둘째, 추상적인 개념이 파일 구조로 내려옵니다. 에이전트 정의 파일, 스킬 파일, 오케스트레이터, CLAUDE.md 포인터, 변경 이력 같은 구체적인 단위가 계속 등장합니다. 덕분에 읽는 동안 “내 환경에서는 이걸 어떤 파일로 만들 수 있을까?”를 자연스럽게 떠올리게 됩니다.

셋째, 개인 생산성에서 조직 운영까지 이어지는 확장성이 있습니다. 혼자 Claude Code를 잘 쓰는 팁에서 멈추지 않고, 여러 에이전트가 협업하는 팀, 그 팀을 만드는 메타스킬, 시간이 지나며 진화하는 하네스까지 다룹니다. 그래서 개인 프로젝트에도 적용할 수 있고, 팀 단위 개발 문화에도 연결해볼 수 있습니다.

아쉬운 점

아쉬운 점도 있습니다. 우선 초급이라고 보기에는 개념의 밀도가 꽤 높습니다. Claude Code나 AI 코딩 도구를 거의 써보지 않은 독자라면 에이전트, 스킬, 오케스트레이터, 메타스킬, 실행 모드 같은 용어가 한 번에 몰려와 조금 벅찰 수 있을 것 같습니다.

또 하나는 독자의 환경에 따라 실습 체감이 다를 수 있다는 점입니다. 회사 보안 정책, 로컬 개발 환경, 사용하는 AI 도구, 모델 비용 구조에 따라 책의 패턴을 그대로 적용하기 어려운 경우도 있을 것입니다. 그래서 이 책은 정답 구조를 그대로 복사하기보다, 자기 작업 환경에 맞게 작게 실험하며 읽는 편이 좋아 보였습니다.

마지막으로, 이 분야 자체가 너무 빠르게 변하고 있습니다. Claude Code와 에이전트 생태계가 계속 바뀌는 만큼 구체적인 명령어나 도구 사용 방식은 시간이 지나며 달라질 수 있습니다. 다만 책의 핵심 메시지, 즉 모델 자체보다 모델을 둘러싼 환경과 구조가 중요하다는 관점은 꽤 오래 남을 것 같습니다.

이 책을 읽고 바꾸고 싶은 것

이 책을 읽고 나서 가장 먼저 하고 싶은 것은, 제가 이미 쓰고 있는 AI 작업 흐름을 더 명시적인 하네스로 정리하는 일입니다.

사이드 프로젝트에서는 Bookgolas, Baroguni, byungskerlog 같은 프로젝트마다 반복되는 작업이 있습니다. 이슈를 만들고, 구현 계획을 세우고, 브랜치를 나누고, PR을 만들고, 리뷰를 받고, daily ship을 하는 흐름이죠. 지금도 어느 정도 skill과 문서로 남기고 있지만, 더 엄밀하게 보면 각 단계마다 필요한 에이전트 역할과 검증 기준을 분리할 수 있을 것 같습니다.

회사 일에서도 비슷합니다. AI에게 단순히 “이거 구현해줘”라고 맡기기보다, 요구사항 정리자, 구현자, 리뷰어, 테스트 관찰자 같은 역할을 나누면 더 안전하게 쓸 수 있을 것입니다. 특히 프론트엔드 개발에서는 UI 구현 결과를 보는 눈, 제품 요구사항을 해석하는 눈, 코드 품질을 보는 눈이 모두 필요하기 때문에 단일 에이전트에게 전부 맡기기보다 역할을 분리하는 편이 더 자연스러워 보입니다.

개인적으로는 Hermes와 Obsidian, Discord, Notion을 더 잘 연결하고 싶어졌습니다. 책을 읽고, 글을 쓰고, 개발을 하고, 회고를 남기는 모든 흐름에서 “이 작업은 어떤 하네스로 반복될 수 있을까?”를 묻게 되었습니다. 단순 자동화가 아니라, 나의 일하는 방식을 파일과 규칙으로 축적하는 일에 가까워졌습니다.

마치며

『하네스 엔지니어링 with 클로드 코드』는 Claude Code 사용법 책처럼 보이지만, 실제로는 AI 시대의 작업 설계에 관한 책에 가깝다고 느꼈습니다.

저는 하네스 엔지니어링이라는 말이 중요하다는 것은 알고 있었습니다. 하지만 이 책을 읽기 전까지는 그것이 정확히 무엇으로 구성되는지, 어디서부터 설계해야 하는지, 왜 파일과 역할과 검증 루프가 중요한지까지는 선명하게 이해하지 못했습니다.

이제는 조금 더 분명해졌습니다. 하네스 엔지니어링은 AI를 똑똑하게 만드는 일이 아니라, AI가 믿고 맡길 수 있는 방식으로 일하게 만드는 환경 설계입니다. 좋은 모델을 고르는 일도 중요하고, 좋은 프롬프트를 쓰는 일도 중요하지만, 앞으로 더 중요해질 것은 그 모델이 어떤 구조 안에서 일하는가일지도 모르겠습니다.

에이전틱 코딩이 점점 더 자연스러워질수록 개발자의 역할은 사라진다기보다 조금 다른 곳으로 이동하는 것 같습니다. 코드를 직접 치는 시간은 줄어들 수 있지만, 무엇을 만들지 정하고, 어떤 구조로 맡길지 설계하고, 결과를 판단하는 책임은 더 커질 테니까요.

이 책은 그 변화의 한가운데에서 꽤 실용적인 언어를 건네줍니다.

“모델이 아니라 하네스가 결과를 결정한다.”

이 문장을 이제는 조금 더 구체적으로 이해하게 되었습니다.