AI 시대, 기술과 사람을 연결합니다. 배움 옆에, 한빛+

나에게 필요한 지식과 기술을 검색해 보세요.

우수리뷰어, 설마 내 지인인가?

코딩과 글쓰기 능력은 서로 정비례한다?

AI 시대, 지금 필요한 공부

평생교육이용권으로 실무 강의를 더 가볍게

오픈클로 VS 클로드 코워크

나에게 더 어울리는 AI 에이전트는?

에이전트 도입을 고민한다면

오버 엔지니어링을 피하는 방법

0/0

새로나온책

클로드 올인원 with 코워크, 코드, 디자인

강민혁, 클리커

누구나 이해하는 클라우드 인프라 지식 사전

김완섭, 바바 도시아키

혼자 해도 프로 선생님처럼 잘 만드는 학교 수업 자료 with 제미나이

김태훈(날아라후니쌤), 손민지(레모니티처), 김한나(나콩쌤)

한 달만에 끝내는 재무제표분석

최원욱, 김고운

하네스 엔지니어링 with 클로드 코드

황민호

IT CookBook, 핵심이 보이는 제어공학(3판)

김성중

STEM CookBook, 에센셜 기계공작법

이건상

IT CookBook, AI 시대의 교양

이대령

이것이 멀티 에이전트다

서지영

7가지 생성 AI로 영상 제작 & 편집하기 with 챗GPT & 미드저니 & 런웨이(개정판)

홍순성

데이터 과학을 위한 기초수학 with 파이썬(2판)

이병준

요즘 교사를 위한 AI 바이브 코딩 활용 가이드 with 2022 개정 교육과정

공지훈, 곽수창, 박준효

LLMOps 완벽 가이드

박조은, 박주환, 아비 아리안

조코딩의 바이브 코딩 1인 창업 with 클로드 코드, 수파베이스, 스트라이프

조동근(조코딩)

트랜스포머 아키텍처로 배우는 AI 에이전트 with 랭체인 & 랭그래프

장철원

리더존망: 왜 조직의 속도는 리더에서 멈추는가

이용훈

코어 스테이블코인

박지수, 박재현

알고 나면 무조건 써먹는 실무 엑셀

정훈희

채널.H

바쁜 리더는 위임을 한다고 착각한다. (조직의 속도는 왜 리더에서 멈추는가 ➂)

리더는 위임을 한다고 말한다. 그런데 일은 여전히 리더에게 몰린다. 조직은 여전히 느리고, 구성원은 여전히 리더의 결정을 기다린다. 그렇다면 문제는 무엇일까. 문제는 위임이 아니다. 위임에 대한 착각이다. ※ 이 칼럼은 『리더존망』 이용훈 저자 링크드인 채널에 게재된 글을 일부 수정하였습니다. 바쁜 이유는 일이 많아서가 아니다 리더가 바쁜 표면적 이유는 명확하다. 위임에 실패했기 때문이다. 그러나 대부분의 바쁜 리더는 그렇게 생각하지 않는다. 오히려 이렇게 항변할 것이다. “나는 위임을 하고 있다. 팀장도 있고, 직책자도 많다. 문제는 그들의 역량이 부족해서 내가 할 수밖에 없다.” 정말 그럴까? 단순히 직책자가 많다고 해서 위임이 되는 것은 아니다. 바쁜 리더는 위임을 하고 있다고 생각하지만, 실제로는 전혀 다른 일을 하고 있는 경우가 많다. 가장 흔한 착각은 조직 구조를 위임으로 오해하는 것이다. 팀을 쪼개고, 팀장을 임명하고, 보고 체계를 촘촘히 만들면 일이 분산될 것이라고 믿는다. 피라미드형 수직 구조를 만들어 놓고 그것을 위임이라고 생각한다. 하지만 현실은 정반대다. 직책자가 많아질수록 조직은 더 느려진다. 정보와 의사결정은 조직도의 꼭지점에 있는 직책자에게 쏠린다. 그리고 최종적으로는 모든 판단이 보고라인을 타고 최상위 리더에게 올라간다. 결국 조직은 여러 층으로 나뉘었지만, 의사결정은 분산되지 않는다. 다단계 수직 구조와 직책자는 위임의 결과물이 아니다. 오히려 위임하지 못하는 조직이 통제를 구조로 포장한 결과에 가깝다. 위임을 못하니 직책자를 늘리고, 직책자가 늘어나니 다시 의사결정이 느려진다. 위임 실패가 구조가 되고, 그 구조가 다시 위임 실패를 만든다. 물론 최상위 리더의 통제권을 유지하기 위해 의도적으로 수직 구조를 강화하는 조직도 있다. 이런 경우라면 더 분명하다. 통제를 위해 만든 조직 구조는 위임과 멀어질 수밖에 없다. 반대로 위임을 잘하는 조직은 직책을 늘리지 않는다. 권한과 책임을 나눈다. 중간 리더든 개별 구성원이든, 맡은 일을 자기 완결적으로 판단하고 실행할 수 있어야 한다. 이런 조직에서는 과도하게 많은 직책자가 오히려 해가 된다. 불필요한 병목을 만들기 때문이다. 그래서 빠르게 움직이는 조직은 조직의 층위를 줄이고, 직책자의 수를 최소화하려 한다. 다시 말해 위임은 조직도로 하는 것이 아니다. 위임은 업무에 대한 자기 완결성으로 이루어진다. 팀장이든 실장이든 본부장이든 직책 자체는 중요하지 않다. 해당 구성원에게 실질적인 권한과 책임이 부여되지 않는다면 그것은 위임이 아니다. 냉정하게 말하면 이름뿐인 책임자에 가깝다. 위임은 내 일을 떼주는 것이 아니다 위임에 대한 또 다른 오해도 있다. 바쁜 리더들은 위임을 ‘내 일’을 떼주는 것이라고 생각한다. 그러나 위임은 내 일을 대신할 사람을 찾는 것이 아니다. 그 일을 믿고 맡길 사람을 세우는 것이다. 이 차이는 작아 보이지만 결정적이다. 만약 리더가 어떤 일을 여전히 ‘내 일’이라고 생각한 채 위임한다고 해보자. 누군가 그 업무를 수행하더라도 본질적으로 그 일은 여전히 리더의 것이다. 그러니 일이 자신의 마음에 들지 않는 방향으로 흘러가면 사사건건 간섭하게 된다. 이런 리더가 찾는 것은 책임자가 아니다. 자신의 수족이 될 사람이다. 귀찮고 품이 많이 드는 실행은 넘긴다. 그러나 본질적인 판단, 즉 의사결정 권한은 계속 자신이 쥐고 있다. 이건 위임이 아니다. 단순한 업무 배분일 뿐이다. 내 일을 떼주는 방식으로는 조직 구조를 3단으로 만들든 100단으로 만들든 위임은 이루어지지 않는다. 오히려 내 일의 일부를 남이 대신하는 것이기 때문에 리더는 계속 불안하고, 구성원은 계속 눈치를 본다. 맡기는 사람도 성가시고, 받는 사람도 힘들다. 결국 또 다른 병목만 생긴다. 더 큰 문제는 구성원이 단순 실행자로 전락할수록 책임감도 약해진다는 점이다. 어차피 최종 결정은 리더가 할 것이라는 무기력함이 조직 안에 자리 잡는다. 미리 고민할 이유도, 끝까지 책임질 이유도 줄어든다. 업무와 심리적 거리가 생길수록 구성원의 책임감과 판단력은 약해질 수밖에 없다. 결국 구성원은 문제를 해결하는 사람이 아니라 리더의 지시를 기다리는 사람이 된다. 리더에 대한 의사결정 의존은 리더가 없을 때 조직을 멈추게 만든다. 동시에 구성원의 판단 근육을 위축시킨다. 책임 있는 일을 맡아보고, 판단해보고, 실패를 통해 배우는 기회가 사라지기 때문이다. 구성원의 역량은 성장하지 못하고, 장기적으로 조직의 인재 밀도는 낮아진다. 바쁜 리더는 자신이 조직을 책임지고 있다고 생각한다. 그러나 실제로는 조직이 스스로 움직일 기회를 빼앗고 있을 수 있다. 문제는 하나의 머리로 모든 것을 통제하려 하면서, 손발만 계속 늘린다는 데 있다. 그래서 위임을 한다고 말할수록 리더는 더 바빠진다. 조직은 그만큼 더 느려진다. 그럼에도 바쁜 리더는 자신의 위임 방식을 고칠 생각보다 손발을 늘릴 생각부터 한다. 직책자를 더 만들고, 보고 체계를 더 촘촘히 짜고, 확인 절차를 더 늘린다. 그렇게 조직은 점점 더 무거워진다. 그렇다면 바쁜 리더는 왜 이런 잘못된 위임을 반복하는가?그리고 그 실수를 반복하지 않으려면 무엇이 달라져야 하는가? 이 질문에 답하지 못한다면, 리더는 계속 바쁘고 조직은 계속 느려질 것이다.AI와 협업 도구의 발전으로 개인의 생산성은 그 어느 때보다 높아졌습니다. 하지만 정작 조직은 여전히 느립니다. 왜 조직의 속도가 리더에서 멈출까요? 책 『리더존망』에서는 그 이유를 모든 결정이 리더에게 몰리는 ‘의사결정의 구조’에서 찾습니다. 저자는 리더의 바쁨을 성실함이 아니라 위임 실패와 조직 병목의 신호로 바라봅니다. 그리고 조직을 망치는 나쁜 리더의 뿌리를 ‘완벽하다는 착각’, ‘장기 방향성 부족’, ‘타인에 대한 신뢰 부족’ 세 가지로 나누어 설명합니다. 더 나아가 16가지 나쁜 리더 유형을 통해 우리 조직의 속도가 어디에서 멈추고 있는지 구체적으로 돌아보게 합니다. 좋은 리더가 되는 법을 배우기 전에, 먼저 나쁜 리더가 되지 않는 법을 알아야 합니다. 조직이 느려졌다고 느낀다면 구성원을 탓하기 전에 리더의 일하는 방식과 의사결정 구조를 점검해 보세요. 리더의 바쁨이 조직의 병목이 되는 순간을 발견하고, '조직의 진짜 속도를 되찾는 방법'을 지금 이 책에서 확인해 보시기 바랍니다.

지금 나에게 필요한 AI 에이전트 책은? | 랭체인부터 멀티 에이전트까지, 목적별 추천 도서 7권

AI 에이전트를 공부하려고 책을 찾다 보면 비슷한 키워드가 반복됩니다. 랭체인, 랭그래프, RAG, MCP, A2A, 멀티 에이전트, 컨텍스트 엔지니어링까지 모두 중요하지만, 처음부터 모든 것을 한 번에 익힐 필요는 없습니다.중요한 것은 지금 내가 어떤 단계에 있고, 어떤 문제를 해결하고 싶은지를 먼저 정하는 일입니다. AI 서비스를 처음 만들어보고 싶은지, 에이전트 구조를 제대로 이해하고 싶은지, 운영 가능한 시스템으로 확장하고 싶은지에 따라 필요한 책은 달라집니다. 한빛미디어의 AI 에이전트 도서 7권을 개발 목적별로 정리했습니다. #난이도도서명주요 내용추천 독자1초·중급조코딩의 랭체인으로 AI 에이전트 서비스 만들기랭체인 기반 AI 서비스 구현과 수익화AI 서비스를 처음 만들어보는 분2초·중급만들면서 배우는 AI 에이전트 개발 입문+실전LLM 의사결정 원리부터 싱글·멀티 에이전트 설계까지에이전트 구조를 단계별로 배우고 싶은 개발자3중급AI 에이전트 마스터 클래스랭체인 기본기부터 ReAct, RAG, MCP까지랭체인 기반 실무 로드맵이 필요한 개발자4중급트랜스포머 아키텍처로 배우는 AI 에이전트 with 랭체인 & 랭그래프트랜스포머 이론, 파인튜닝, RAG, MCP 실전모델 원리까지 이해하고 싶은 개발자5중·고급컨텍스트 엔지니어링으로 구축하는 AI 에이전트RAG·CoT·ReAct·LLMOps 기반 컨텍스트 설계에이전트 품질과 신뢰성을 높이고 싶은 개발자6중급AI 에이전트 엔지니어링에이전트 시스템 설계, 운영, 보안, 거버넌스운영 가능한 시스템으로 확장하고 싶은 개발자7중급이것이 멀티 에이전트다MCP·A2A 기반 멀티 에이전트 시스템 구현멀티 에이전트 협업 구조를 구현하고 싶은 개발자 • AI 서비스를 처음 만들어본다면 AI 에이전트를 본격적으로 공부하기 전, 먼저 “내 손으로 돌아가는 AI 서비스”를 만들어보고 싶다면 좋은 출발점이 됩니다. 『조코딩의 랭체인으로 AI 에이전트 서비스 만들기』GPT·Llama 기반 RAG·에이전트·멀티모달 AI 서비스 구축 가이드우성우, 조동근(조코딩) 지음 ㅡ 파이썬만 알고 있다면 쉽게 따라 할 수 있도록 예제 중심으로 구성했습니다. GPT·LLaMA·RAG·멀티모달 등 최신 AI 기술을 랭체인으로 연결해 나만의 AI 서비스를 직접 만들어볼 수 있습니다. PDF 기반 챗봇, 인공지능 시인 등을 만들고 수익화 기능까지 구현하며, 랭그래프와 CrewAI를 활용한 멀티 에이전트 구성까지 단계적으로 다룹니다. Streamlit으로 서비스를 구현하고, 랭스미스 설정과 운영 흐름도 함께 익힐 수 있습니다. 구독자 66만 명 IT 유튜버 조코딩의 노하우가 담겼으며, LLM을 활용한 AI 서비스를 처음 만들어보고 싶은 개발자에게 잘 맞습니다. • 에이전트 구조를 단계별로 배우고 싶다면 간단한 챗봇을 넘어, LLM이 어떻게 판단하고 여러 도구와 흐름을 연결하는지 알고 싶다면 이 책이 적합합니다. 『만들면서 배우는 AI 에이전트 개발 입문+실전』랭그래프로 완성하는 단계별 싱글·멀티 에이전트 시스템, LLM 라우팅부터 MCP와 A2A 실전 구현까지 박나연(공원나연) 지음 ㅡ LLM의 의사결정 원리부터 싱글·멀티 에이전트 설계, RAG·MCP·A2A까지를 하나의 흐름으로 연결해 AI 에이전트를 처음 배우는 개발자도 단계별 구현을 완주할 수 있도록 안내합니다. 사내 FAQ 응답, 보고서 작성, 문서 검색, MCP 서버 연동, A2A 기반 오케스트레이터 등 현업에서 바로 활용할 수 있는 25가지 에이전트를 직접 구현합니다. 에이전트를 ‘만드는 수준’을 넘어 구조를 설명하고 설계할 수 있는 역량을 기르는 데 초점을 맞췄습니다. • 랭체인 기반 실무 로드맵이 필요하다면 랭체인으로 에이전트 서비스를 만들고 싶지만 어디서부터 시작해야 할지 막막하다면, 이 책이 좋은 길잡이가 됩니다. 『AI 에이전트 마스터 클래스』기획, 구현, 운영, 배포까지 현업에서 바로 적용하는 에이전트 개발 가이드김구현 지음 ㅡ 랭체인의 기초 문법인 LCEL부터 시작해 Streamlit을 활용한 웹 서비스 구현까지 단계적으로 다루며, 실무에 즉시 적용 가능한 기반 지식을 다집니다. LLM이 스스로 추론하고 도구를 선택하는 ReAct 패턴의 에이전트 설계, RAG를 활용한 내부 지식 확장, 랭그래프 기반 대화 상태 관리인 CheckPointer, 그리고 외부 시스템과 유기적으로 연결하는 MCP까지 체계적으로 다룹니다. 마지막에는 와인 추천 에이전트를 기획부터 구현, 웹 배포까지 직접 완성하는 실전 프로젝트가 수록되어 있습니다. 파이썬 기본 문법과 LLM API 호출 경험이 있는 개발자가 에이전트 서비스를 PoC 수준에서 운영 가능한 수준으로 확장할 때 참고하기 좋습니다 • 모델 원리까지 이해하고 싶다면 프레임워크 사용법만이 아니라 LLM과 트랜스포머가 어떻게 동작하는지 이해하고 싶다면, 이론과 구현을 함께 살펴볼 필요가 있습니다. 『트랜스포머 아키텍처로 배우는 AI 에이전트 with 랭체인 & 랭그래프』RAG부터 파인튜닝, 양자화, MCP까지장철원 지음 ㅡ 현대 인공지능의 뼈대인 트랜스포머 아키텍처를 원리부터 상세히 분석해, 모델이 어떻게 문맥을 이해하고 정교한 답변을 생성하는지 설명합니다. 자연어 처리와 기초 수학, 강화학습, 어텐션과 트랜스포머의 이론적 토대부터 랭체인과 랭그래프를 활용한 실전 에이전트 구축까지의 전 과정을 한 권에 담았습니다. Full fine-tuning, LoRA, QLoRA, 양자화로 이어지는 로컬 LLM 재학습 방법과 ChromaDB 기반 RAG, A2A·MCP를 통한 멀티 에이전트 구현, Streamlit 서비스 배포까지 폭넓게 다룹니다. 단순히 응용 코드를 따라 하는 수준을 넘어 모델 구조를 이해하고 나만의 AI 솔루션을 설계하고자 하는 개발자에게 적합합니다. • 에이전트 품질과 신뢰성을 높이고 싶다면 에이전트를 만들어봤지만 답변 품질, 환각, 기억 관리, 조직 데이터 활용이 고민이라면 컨텍스트 설계 관점이 필요합니다. 『컨텍스트 엔지니어링으로 구축하는 AI 에이전트』랭체인, RAG, CoT, ReAct, LLMOps로 구현하는 AI 서비스 실전 가이드박경민 지음 ㅡ 프롬프트 엔지니어링만으로는 해결하기 어려운 AI의 기억 상실과 환각 문제를 컨텍스트 엔지니어링 기법으로 다룹니다. AI의 작업 기억에 조직의 고유 데이터와 상황 정보를 체계적으로 주입해 AI가 더 정확한 판단을 내리도록 설계하는 방법을 설명합니다. RAG, CoT, ReAct, 메모리 관리, LLMOps는 물론 AI 보안 기술까지 다루며, 특정 LLM 버전에 종속되지 않는 일관된 패턴을 익힐 수 있습니다. 실습에서는 ‘주니어 개발자’, ‘CS 에이전트’, ‘의료 연구원’ 등 실제 업무를 수행하는 3가지 에이전트를 직접 구현합니다. GPT, Claude, Gemini 등 다양한 모델을 대상으로 실습할 수 있어 에이전트의 품질과 신뢰성을 끌어올리고 싶은 개발자에게 적합합니다. • 운영 가능한 시스템으로 확장하고 싶다면 프로토타입을 넘어 실제 서비스로 운영하려면 설계, 평가, 모니터링, 보안, 거버넌스까지 함께 고려해야 합니다. 『AI 에이전트 엔지니어링』단일 에이전트부터 멀티 에이전트 시스템까지, AI 앱 개발 올인원 가이드 마이클 알바다 지음, 강민혁 옮김 ㅡ 도구, 메모리, 오케스트레이션, 그리고 여러 에이전트가 역할을 나눠 협업하는 멀티 에이전트 아키텍처까지 단계적으로 살펴봅니다. 운영 환경에서 중요한 신뢰성, 보안, 거버넌스까지 포함해 ‘만드는 법’에서 ‘운영하는 법’으로 시야를 확장합니다. 마이크로소프트, 우버, 서비스나우에서 대규모 머신러닝 솔루션을 구축·배포한 저자의 경험이 담겨 있으며, 수백 편의 논문에 흩어진 에이전트 시스템 지식을 한 권으로 정리했다는 점이 강점입니다. • 멀티 에이전트 협업 구조를 구현하고 싶다면 여러 에이전트가 역할을 나눠 일하고, MCP와 A2A 기반으로 연결되는 구조를 직접 구현해야 한다면 가장 직접적인 선택이 될 수 있습니다. 『이것이 멀티 에이전트다』싱글 에이전트부터 멀티 에이전트까지, MCP와 A2A로 구현하는 에이전트 시스템 개발 서지영 지음 ㅡ 실제 서비스 단계에서 단일 LLM 호출만으로는 풀리지 않는 문제가 반복적으로 나타날 때 참고하기 좋습니다. 싱글 에이전트 구현에서 출발해 멀티 에이전트 협업 시스템으로 확장하며, MCP와 A2A 기반 협업 구조, 오케스트레이터 설계, 병렬 실행, 상태 관리, 반복 평가 루프까지 단계적으로 구현합니다. 영업 데이터 분석·시각화, 개인정보 탐지·마스킹, Whisper 음성 Q&A, 이상 거래 탐지, 맞춤형 여행 플래너 등 실제 업무 시나리오를 바탕으로 한 9가지 실전 프로젝트가 수록되어 있습니다. 협업형 AI 시스템을 직접 구현해야 하거나, MCP와 A2A 기반의 에이전트 구조를 실무 관점에서 익히고 싶은 개발자에게 잘 맞습니다. 에이전트 생태계는 빠르게 바뀌고, 새로운 프로토콜과 개발 방식도 계속 등장하고 있습니다. 그래서 중요한 것은 모든 기술을 한 번에 따라가는 것이 아니라, 지금 나에게 필요한 방향을 정하고 그에 맞는 한 권을 고르는 일입니다. AI 서비스를 처음 만들어보고 싶다면 입문형 실습서부터, 구조와 원리를 더 깊이 이해하고 싶다면 랭체인·랭그래프와 트랜스포머를 다루는 책부터 시작해보세요. 품질, 운영, 멀티 에이전트 협업 구조까지 고민해야 하는 단계라면 컨텍스트 설계와 엔지니어링, 멀티 에이전트 구현을 다루는 책이 다음 선택지가 될 수 있습니다.

[나는리뷰어다2025 우수리뷰어] 최우수상 진혜지 님 "모든 책들의 가장 중요한 우선 순위는 OOO이다"

한 해 동안 수많은 책이 세상에 나오고, 그보다 더 많은 서평과 리뷰가 쏟아집니다. 그 방대한 활자의 바다 속에서 독자들의 마음을 단숨에 사로잡고 가장 빛나는 인사이트를 남긴 분은 과연 누구일까요?오늘은 그 치열하고도 열정적인 기록의 여정 끝에 ‘나는리뷰어다2025’에서 우수리뷰어 최우수상을 차지한 진혜지 님을 모셨습니다!인터뷰를 모두 읽고 난 뒤 게시물 하단을 확인해 보시면 진혜지 님이 강력하게 꼽은 ‘추천도서와 관련된 특별한 이벤트’가 여러분을 기다리고 있습니다. 그럼 진혜지 님의 진솔하고 열정 가득한 이야기 속으로 함께 들어가 보실까요? Part 1. 개발자와 리뷰어 사이 Q. 간단한 자기소개 부탁드립니다. 더불어 현재 주력으로 다루고 계신 기술 스택이나, 요즘 가장 흥미를 두고 지켜보는 분야는 무엇인가요? A.안녕하세요. 저는 14년차 웹디자이너이자, 현재 레브라는 디자인회사를 운영중인 진혜지라고 합니다. 주로 디자인과 관련된 툴인 포토샵, 일러스트레이터를 주로 사용하며 코딩도 직접하고 있어요.요즘 AI가 대중화되고 나서 디자인 쪽도 더욱 트렌드가 빨라진 것 같아요. 그래서 디자인과 협업 할 수 있는 분야에 대해 관심을 가지고 AI와 영상 분야도 함께 공부 중이에요. 최근에는 주로 AI를 활용하는 방법들을 공부중인데 간단한 코딩이나 아이디어를 찾을때 많이 활용하고 있는 편이에요. 예전부터 컴퓨터를 다루는 걸 좋아해서 다양한 자격증을 따거나 새로운 걸 배우거나 해보는 걸 좋아해서 여러가지에 두루두루 관심을 가지고 있어요 Q. 현업으로 바쁜 와중에도 <나는리뷰어다2025> 활동을 꾸준히 이어오신 특별한 동력이 있으신가요? 매달 마감을 지킬 수 있었던 원동력이 궁금합니다. A.어렸을 때부터 독서를 좋아하는 편이었어요. 혼자 상상하고, 또 그림을 그리는 걸 좋아했는데 독서를 할 때면 현실과는 다른 또 다른 세상의 주인공이 된 것 같아서 취미 생활이 된 것 같아요. 그러다 몇 년전 출판사의 서포터즈를 우연히 하게 되면서 다양한 독서 관련 서평단이나 서포터즈가 있다는 걸 알게 되었어요. '나는리뷰어다2025'도 그때 알게 되었는데 처음 2024때는 탈락했다가 두 번째 도전 만에 선정이 되어서 매우 기뻤어요.제가 원래 책편식이 조금 있었는데 서포터즈 활동을 하며 랜덤으로 책을 받다보니 편식이 조금 줄어들고 다양한 분야를 두루두루 볼수있어서 더 열심히 했던것 같아요. 매번 어떤 새로운 책이 도착할까 기대도 되었고, 특히 이번 '나는리뷰어다2025'는 주로 디자인이나 AI 같은 컴퓨터/IT 관련 분야의 책들을 많이 볼 수있어서 업무에도 많은 도움이 되었어요. 그래서 직접 따라해보기도 하고 디자인 아이디어를 구상할 때도 많이 활용할 수 있어서 더 열심히 읽었던 것 같아요. Q. 수많은 참여자 중 '우수 리뷰어'로 선정되셨습니다! 본인이 생각하시기에, 다른 리뷰들과 차별화된 나만의 선정 비결(꾸준함, 분석력, 솔직함 등)은 무엇이라고 생각하시나요? A. 저 같은 경우에는 최대한 꼼꼼하게, 자세히 리뷰를 남기는 편이에요. 주로 책이나 영화 등을 찾아볼 때 항상 후기나 리뷰를 꼭 읽어보는 편인데, 자칫 스포일러가 될 수도 있지만 오히려 어떤 부분이 재미있었는지, 어떤 내용이 감동적이었는지, 어떤 게 아쉬운지 등을 모두 확인해보고 흥미로운 책이나 영화를 고르다 보니 저도 책 서평을 쓸 때 최대한 자세히 쓰려고 했던 것 같아요. 제 글을 읽으시는 분들이 흥미를 가지거나 혹은 본인에게 더 잘 맞는 책을 찾을 수 있게 도와준다는 생각으로 조금 쉬운 문장이나 단어들로 쓰려고 했어요. 가장 중요했던 건 그 책을 읽을 때 제가 느꼈던 부분이나 감정 등을 하나도 빠짐없이 담고 싶었어요. 이 책을 읽고 이런 부분들을 배웠고, 이런 생각을 했다는 걸 자세히 써놓으면 나중에 제가 쓴 서평들을 다시 읽는 것만으로도 그때 읽었던 내용들이 대부분 다 기억이 나거든요. 그런 점들이 좋은 평가를 받았던 것 같아요.그리고 서평이나 독후감을 쓰다 보면 처음에는 내용을 빠트리거나, 너무 개인적인 '나' 위주로 쓰기도 하고, 지루하게 쓰기도 하는데 조금씩 쓰다 보면 점점 저만의 서평을 쓰는 방식이 생기더라구요. 저도 제일 처음에는 줄거리만 쓰다가 웹디자이너로서 책표지나 책의 폰트나 가독성, 재질 등도 눈에 띄어서 추가하기도 하고, 조금 더 자세히 리뷰를 쓰고 싶어서 목차도 추가하다보니 점점 서평의 퀄리티가 좋아진 것 같아요. 또 같은 책을 읽었던 다른 서평들도 한번씩 읽으면서 저랑 다르게 생각한 부분이 어떤 건지, 공감한 부분이 어떤 건지 살펴보면서 혼자만의 독서 토론을 하기도 해요. 그러다 보면 어느새 제 서평을 읽고 많은 분들이 좋아해주셔서 더욱 응원을 받아 더 열심히 쓰게 되는 것 같아요!Q. 매달 읽을 책을 고르실 때 어떤 점을 가장 중요하게 보시나요? '현재 업무에 당장 필요한 책'을 우선하시나요, 아니면 '새로운 분야에 대한 호기심'을 우선하시나요?A. 1차적으로는 새로운 분야에 대한 호기심이 가장 먼저 보는 것 같아요. 새로운 트렌드나 요즘 이슈가 되는 이야기들과 관련된 주제, 또는 제가 전부터 배워보고 싶거나 궁금했던 책들을 가장 먼저 고르는 편이에요. 그 후 머리를 식힐 수 있는 주제들에 대한 걸 선택하고, 마지막으로 현재 업무와 관련되거나 당장 필요한 책들을 고르는 편이에요. 사실 웹디자이너를 14년 동안 하다보니 포토샵과 일러스트에 대한 부분은 이미 알고 있는 내용들이 많은 편이에요. 그래서 업무보다는 조금 더 업무와 협업을 하거나 확장시킬 수 있는 분야를 더 우선적으로 선택했던 것 같아요. Part 2. 개발자의 독서법 Q. 코딩, 회의, 야근… 프로젝트 사이에서 독서 시간은 언제, 어떻게 확보하셨나요? (예: 출퇴근길 지하철, 주말 아침, 잠들기 전 등)A. 저는 주로 점심시간이나 주말을 많이 이용하는 편이에요. 다른 분들처럼 지하철 등에서 읽어보고 싶지만 멀미가 심해서 이동할 때는 최대한 피하고 있어요. 대신 점심시간을 이용하거나 주말 오후 등 느긋하게 시간을 보낼때 읽는 편이에요. 그리고 개인적으로는 종이책을 좋아하는데 요즘에는 전자책이 많이 보편화되어 있어서 헬스장 같은 곳에서도 읽을 때가 있어요. 런닝머신을 탈 때는 어렵지만 실내 자전거를 탈 때는 아주 시간이 잘 가는 편이라서 자주 활용해요. Q. 기술 서적을 읽으실 때의 스타일이 궁금합니다. 예제 코드를 하나하나 타이핑하며 꼼꼼히 정독하시나요, 아니면 전체적인 흐름과 개념 파악을 위해 빠르게 훑어보는 편이신가요? A. 우선 대략적인 방법을 훑어보는 편이에요. 어떤 식으로 활용하는지, 어떤 방법이 있는지 등 전체적인 부분을 살펴본 후 그중 가장 기억에 남거나 익히고 싶은 내용을 위주로 따라해보는 걸 좋아해요. 제가 평소에 책을 읽을 땐 조금 빠르게 읽는 속독을 많이 택하는 편이에요. 속독으로 전체적인 느낌과 책의 분위기 등을 살피며 가볍게 읽은 후, 꼼꼼하게 다시 정독하고 있어요. 그후 가장 기억에 남는 부분만 다시 한번 정독해서 보통 한 권의 책을 2~3번 읽는 편이에요. 그러다 보니 책을 읽고 예제를 따라하기에는 조금 시간이 부족해서 서평을 써놓고 다시 한번 느긋하게 읽으며 예제를 풀 때가 많았어요. Q. 서평 작성을 위해 따로 사용하는 정리 도구(Notion, Obsidian, 블로그 등)가 있나요? 혹은 책의 내용을 내 것으로 만들기 위한 나만의 정리 템플릿이 있다면 살짝 공개해 주세요. A. 주로 쓰는 템플릿은 따로 정해두고 있지는 않아요. 다만 블로그를 자주 쓰다보니 내용이 생각나거나 메모가 필요할 때마다 블로그에 비공개로 저장해놓거나 폰 자체 기능을 활용해서 메모를 해놓는 편이에요. 그러다 중요한 문구나 내용이 있다면 사진으로 찍어서 보관하고 나중에 서평을 쓸 때 정리해서 그 부분도 포함해서 작성하는 편이에요. Q. 가끔 내 기술 스택과 맞지 않거나 난이도가 너무 높은 책을 만날 때도 있습니다. 이럴 때 완독(혹은 리뷰 작성)을 위해 어떻게 대처하셨나요? A. 사실 이번 '나는리뷰어다2025' 때 1~2번 정도 그런 일이 있었던 것 같아요. 이미 알고 있는 주제나 난이도가 꽤 높았던 내용이 있어서 어떤 책을 골라야 할지 난감한 적이 있었어요. 그때는 난이도가 높은 책보다는 기술 스택과 맞지 않지만 도움이 되는 분야에 대한 책을 골랐어요. 그렇게 선택했던 이유는 난이도가 너무 높게 되면 자연스레 책 내용들이 모두 지루하게 느껴지고 책을 멀리하게 되어서 결과적으로는 기억에 남지도 않고 거의 다시 보지 않게 되더라구요. 반면에 내 기술 스택과는 맞지 않는 책이지만 최근 이슈가 포함되어 있거나 한 번쯤 읽으면 상식 면에서 도움되는 부분들이 꽤 많이 있어요. 그런 내용들이 한 두개 들어 있다면 새로운 것도 알게 되고 그러다 보면 관심이 생겨서 그 분야도 공부할 수 있는 계기가 되기도 해서 전 난이도가 너무 높은 책보다는 기술 스택 쪽으로 많이 선택하는 편이에요. Part 3. 책이 코드로 바뀌는 순간 Q. 리뷰했던 도서의 내용이 실제 업무에 도움 된 적이 있나요? 버그를 해결했거나, 아키텍처를 개선하는 등 책의 지식이 실무로 이어진 구체적인 사례가 있다면 들려주세요.A. 앞의 질문과 이어지는 부분이기도 한 것 같은데, 한번은 일러스트레이터 책을 고른 적이 있어요. 그때 당시 난이도가 굉장히 높아서 다른 책들은 선택하기 어려웠고, 일러스트레이터 책은 이미 제가 일러스트레이터를 항상 사용하고 있어서 조금은 식상해서 흥미가 가진 않았어요. 다만 제가 업무에 사용하는 것과 버전이 달라서 새로운 효과나 필터, 툴이 추가된게 있는지 궁금해서 선택했는데 생각보다 꽤 재미있었던 기억이 나네요. 내용 자체는 초보자 기준으로 제작되어 있어서 사실 저에게는 난이도가 굉장히 낮았는데 오히려 그래서 더 재미있었던 것 같아요. 예전 처음 일러스트를 배우던 때도 생각나기도 하고요. 제가 알고 있던 방법들과 또 다른 방법을 배우면서 둘 중 어떤 게 더 효과적인지 비교도 해보고, 가장 재미었던 예제는 블로그에 그 예제만 따로 영상과 포스팅을 만들어서 올린 적도 있었어요. 난이도가 높은 책을 선택했다면 지루했을텐데 오히려 난이도를 낮춰서 더 실무에 사용하기 좋았던 것 같아요. 현재 제가 웹디자이너 외에도 일러스트 작가로 등록되어 있는데 그때 일러스트레이터 책에서 봤던 내용들을 아이디어 삼아 여러 일러스트를 그려서 올리기도 했어요. Q. 작년 읽으신 책들을 통해 느낀 최근 IT 기술의 흐름이나 변화는 무엇이었나요? 개발자로서 체감하는 트렌드 키워드가 있다면요? A. 아무래도 AI/인공지능이 가장 큰 이슈이자 흐름인 것 같아요. 저도 몇 번 간단한 코딩들을 테스트 삼아 AI로 작업했는데 코드도 훨씬 깔끔하고 시간도 단축되서 업무 효율이 많이 높아졌어요. 관련 책들이 이미 수없이 많이 나온 상태인데 대부분의 내용들이 업무 효율을 가장 먼저 이야기할 정도로 실무에서는 많이 활용하고 있는 상태예요. Q. 개발자 입장에서 "이 책은 진짜 물건이다, 소장해야 한다"라고 느끼는 '좋은 기술 서적'의 기준은 무엇인가요? (예: 번역의 질, 예제의 정확성, 도식화 등) A. 저는 모든 책들의 가장 중요한 우선 순위는 어휘력, 즉 표현력이라고 생각해요. 아무리 좋은 내용을 담고 있어도 그걸 설명하고 독자를 빠져들게 만드는 어휘력이나 표현력이 없다면 금방 지루한 교과서가 된다고 생각해요. 수많은 책들이 같은 주제와 분야에 쏟아지는 상황에서 설명이 어렵거나 어휘력과 표현력이 너무 대충 나와 있거나 보기 불편하다면 굳이 그 책을 읽을 필요가 있을까요? 눈에 띄는 도식화나 예제도 물론 중요하다고 생각해요. 글만 써있는 설명문보다 그림이나 한번에 이해가 될 수 있는 또 다른 게 추가되어 있다면 훨씬 보기 좋고 독자로서 편하게 읽을 수 있을 거에요. 하지만 그림이나 도식화 등이 있다고 해도 책의 가장 기본은 글을 쓰는 저자가 얼마나 설명을 잘하는지, 독자와 얼마나 깊이 있게 호흡하는지가 가장 중요하다고 생각해요. 도식화나 예제를 넣어 놓아도 독자는 결국 혼자 독학으로 따라하기 때문에 그만큼 쉽게 설명하고 어휘력이 좋아야 한번에 이해하기도 쉽고 책을 따라갈 수 있다고 생각해요. Q. 활동 기간 중 만난 도서 중 "이 책만큼은 소장 가치가 200%다"라고 느꼈던 책을 딱 두 권만 꼽는다면 무엇인가요? 그리고 그 이유는 무엇인가요? A. <따라 하며 배우는 유니티 게임 개발>과 <AI로 하루 만에 영상 만들기 with 런웨이>예요. 우선 2권 모두 제가 예전부터 배워보고 싶었던 부분이라서 가장 읽고싶었던 책이었고 기대했던 만큼 눈에 띄는 내용들이 많았어요. 먼저, <따라 하며 배우는 유니티 게임 개발>은 제가 평소에도 게임을 무척 좋아해서 눈길이 갔어요. 특히 유니티로 게임 개발을 하고 싶었는데 거기에 딱 맞는 책이었어요. 간단한 모바일 게임은 혼자서도 만들수있다는 얘기를 예전부터 많이 들었던 터라 한 번쯤 제가 직접 디자인하고 만들고 싶다는 생각을 하고 있었는데 이 책은 가장 기본부터 게임을 만드는 원리와 방법이 쉽게 설명되어 있어서 가장 기억에 남는 책이에요. 서평 기간이 길었다면 제가 직접 만든 게임도 같이 리뷰로 올리고 싶다는 생각이 들 정도로 쉽게 설명되어 있어서 좋았어요. 그리고 두 번째로 <AI로 하루 만에 영상 만들기 with 런웨이> 책도 제가 최근 릴스와 영상 제작에 관심이 생겨서 공부 중일때 만난 책이었어요. 직접 동영상을 찍고 더빙 대신 배경음만 넣어서 간단히 만들었는데 이 책 덕분에 텍스트만으로 AI를 활용해서 동영상을 만들거나 제가 직접 목소리로 녹음하지 않아도 목소리를 삽입하는 등 다양한 영상 기술과 방법을 배울 수 있어서 활용도가 높았어요. 실제로 이 책을 읽은 이후에는 여러가지 시도를 하며 영상제작을 해서 조금더 퀄리티가 좋아졌어요. 다른 책들도 기억에 남지만 딱 2권만 꼽는다면 이 두 책을 추천합니다! Part 4. Outro: 리뷰어의 시선 Q. "코딩 잘하는 개발자가 글도 잘 쓴다"는 말에 동의하시나요? 꾸준한 리뷰 활동이 기술 문서 작성 능력이나 로직을 정리하는 데 실제로 도움이 되셨는지 궁금합니다. A. 많은 도움이 되었다고 생각해요. "코딩 잘하는 개발자가 글도 잘 쓴다" 이 말에는 절반 정도 동의해요. 코딩을 잘하면 이해도가 높아서 다양한 방법과 노하우를 알려줄 수 있어서 실제로 책을 쓸때 도움이 된다는 생각이 들어요. 하지만 잘 아는 것과 잘 설명하는 건 또 다른 문제로서 독자가 이해하기 쉽게 글을 쓰는 건 개발자마다 다를꺼라고 생각해요. 거기다 직접 1:1로 설명하는 게 아니라 책이라는 매개체를 통해서 설명하고 이해해야 하기 때문에 어휘력이나 표현력도 매우 중요한 부분이에요. 직접 말로 할 때는 잘하지만 요즘에는 글쓰기를 어려워하는 사람들이 꽤 많아서 특히 더 힘든 것 같아요. 하지만 기본적으로 코딩에 대한 이해도가 높아야하기 때문에 저는 절반만 동의할 수 있을 것 같아요. 그리고 책을 읽기만 하고 넘길 수도 있지만 리뷰 활동을 통해서 한번더 내용을 정리할수도 있고 복기하면서 스스로 공부도 되고, 또 남들에게 보여주는 글을 써야되기 때문에 더욱 집중해서 읽거나 이해하려고 노력하다보니 많은 도움이 되었던 것 같아요. Q. 앞으로 직접 기술 서적을 집필할 기회가 생긴다면, 어떤 주제로 책을 써보고 싶으신가요? A. 가장 먼저 쓰고 싶은 책은 웹디자인에 대한 책이에요. 기술적인 포토샵이나 일러스트에 대한 노하우와 스킬에 대한 것도 쓰면 좋겠지만 우선은 웹디자인에 대한 전반적인 경험담과 관련 주제에 대해 쓴 후 그 속에 있는 분야에 대해 집중적으로 책을 써보고 싶어요. 2024년부터 전자책을 쓰기 위해 글 쓰는 방법에 대해 많이 배우고 공부하고 있는데 언젠가 한빛미디어에서 제 책을 볼 수 있는 날이 있으면 더욱 기쁠 것 같아요. Q. 올해, 혹은 내년에 <나는리뷰어다>에 도전할 동료 개발자들에게 해주고 싶은 '완주 꿀팁' 한 마디 부탁드립니다.A. 한해 동안 즐겁게 보냈던 것 같아요. 매월 다양한 책들을 만나볼 수 있고 또 랜덤 형식으로 책이 발송되어 저처럼 책편식이 심한 분들에게 많은 도움이 될 수 있는 기회라고 생각해요. 마감일이나 독서 시간 등이 고민 될수도 있겠지만 스트레스보다는 오히려 즐거움이 더 컸던 시간들이라서 꼭 한번 도전해보길 추천드려요. 너무 부담갖지 말고 새로운 책들을 만나는 즐거움을 먼저 떠올리면 더욱 알차고 보람 있는 한해가 될 것 같아요. 화이팅! Q. 마지막 질문입니다. <나는리뷰어다>를 한 문장이나 키워드로 정의한다면 무엇인가요? A. 새로움의 대한 즐거움. 저는 '나는리뷰어다'를 떠올리면 늘 즐거웠던 것 같아요. 이번달 책은 어떤 것일지 두근두근 설레기도 하고 책을 읽으면서 몰랐던 부분을 많이 배우고 알게 되서 더욱 재미있게 활동했던 것 같아요. 그래서 아쉬움도 많이 남는 것 같아요. 다음에 또 참여할 수 있다면 도전해보고 싶어요. 오늘 준비한 진혜지 님과의 이야기는 여기까지입니다. 진혜지 님이 실무에 가장 도움 된다고 강력히 꼽은 <따라 하며 배우는 유니티 게임 개발>, <AI로 하루 만에 영상 만들기 with 런웨이>과 책의 가치를 200% 끌어올려 줄 한빛앤의 베스트 강좌를 엄선하여 ‘우수리뷰어 Pick’ 패키지로 구성했습니다. 독서의 깊이와 실무 강의의 시너지를 기간 한정 파격적인 가격으로 만나볼 수 있는 절호의 기회이니 절대 놓치지 마세요.2026년 상반기가 마무리되고 있는데요, 하반기에는 어떤 리뷰어의 가슴 뛰는 이야기와 역대급 혜택이 여러분을 찾아올지 많은 기대와 관심 부탁드립니다!

AI 에이전트의 시대에서 하네스 엔지니어링의 시대로

2025년 7월, SaaStr 창업자 제이슨 렘킨 Jason Lemkin 은 리플릿 Replit 의 AI 에이전트에게 한 줄짜리 지시를 내렸습니다. “freeze all changes(아무것도 변경하지 말 것).” 명령을 받아들인 에이전트는 8일 동안 주어진 백그라운드 태스크만 수행했는데, 9일째 되던 날 갑자기 프로덕션 데이터베이스가 사라졌습니다. 에이전트가 스스로 판단해 DELETE를 실행한 것입니다. 임원 레코드 1,206명분과 작업 레코드 1,196개가 순식간에 지워졌습니다. 에이전트는 직후 “데이터 복구가 불가능합니다”라고 보고했습니다. 하지만 렘킨이 수동으로 확인해 보니 복구가 가능했죠. 거짓 보고였던 것입니다. 에이전트 스스로도 뒤늦게 이 사건을 ‘catastrophic error in judgment (심각한 판단 착오)’라고 표현했습니다. 그런데 데이터 삭제보다 더 무거운 사실은 이 거짓 보고가 몇 시간 동안 사실로 받아들여졌다는 점입니다.이 이야기를 들은 이들의 반응은 대개 둘 중 하나일 것입니다. “리플릿이 문제다” 또는 “모델이 멍청한 거 아냐?”라고 말이죠. 저는 두 반응 모두 틀렸다고 봅니다. 플랫폼의 문제라면 다른 플랫폼을 쓰면 그만이고, 모델의 문제라면 기다리면 그만입니다. 두 가설 모두 설득력이 약합니다. 같은 모델이 다른 환경에서는 다른 결과를 내고, 다른 플랫폼도 비슷한 사고를 반복하고 있기 때문입니다.이런 일은 사실 낯설지 않습니다. 각자 터미널 로그를 떠올려 봅시다. 같은 파일을 열 번 수정하고 같은 grep을 반복하다가 컨텍스트 윈도가 모두 차서 처음부터 다시 시작한 적이 있었을 것입니다. 이런 상황도 규모만 다르지, 리플릿의 실수와 같은 패턴입니다. 드문 사고가 아니라 우리 터미널에서 이미 겪는 문제가 커진 모습입니다. 이 문제의 원인은 모델의 지능이 아니라 모델을 둘러싼 구조입니다. 혼자 일하는 AI는 자기 실수를 못 본다 리플릿 사건의 원인을 한 문장으로 요약하면 다음과 같습니다. 단일 에이전트는 자신의 실수를 잘 보지 못한다. 구조를 보면 이유가 명확합니다. 하나의 에이전트가 계획을 세우고, 코드를 쓰고, 그 결과를 검증하고, 오류가 있으면 스스로 수정합니다. plan → code → verify → self-revise (계획 → 코드 작성 → 검증 → 자기 수정)라는 네 단계가 같은 박스 안에서 차례로 실행됩니다. 그러나 이러한 효율성 이면에는 구조적인 부작용이 따릅니다. 같은 모델, 같은 컨텍스트, 같은 가정으로 네 단계를 수행하기 때문에, 처음에 놓친 가정을 검증 단계에서도 다시 놓치기 쉽습니다. 계획 단계에서 빠진 가정은 구현 단계에서도 반복되고, 검증 단계에서도 같은 논리로 통과됩니다. 자기 수정 단계에 들어가서도 그 수정이 옳은지를 판정하는 주체가 결국 자신이라는 한계가 남습니다. 이 상황을 짧게 요약하면 다음과 같습니다. “자기 출력물을 자기가 검토하는 것은, 자신이 쓴 글을 자신이 교정하는 것과 같습니다.” 개발자 언어로 바꾸면 더 와닿을 것입니다. 혼자 쓴 PR을 혼자 머지 merge 하는 구조입니다. 리뷰어가 없으면 오탈자가 남습니다. 다른 검토자가 없으면 설계 결함이 그대로 남습니다. 여기서 중요한 건, AI 에이전트는 이런 구조가 기본이라는 사실입니다. 출처: <하네스 엔지니어링 with 클로드 코드> p.28 모델의 환경을 바꿨을 때 일어난 일들 2025년 하반기부터 2026년 초 사이, 전혀 다른 세 팀이 같은 질문을 던졌습니다. “모델을 고정하고, 모델을 둘러싼 환경만 바꾸면 결과가 얼마나 달라질까.” 이 팀들은 거의 같은 결론을 냈습니다. 서로 벤치마크도, 측정 방식도 달랐지만 말하는 방향은 같았죠. 첫째, 저자가 실행한 내부 실험. claude-code-harness라는 A/B 테스트 프로젝트에서 동일한 Sonnet 모델에 동일한 15개 실무 코딩 태스크를 두 번 풀게 했습니다. 한 번은 .claude/ 구성이 없는 레포, 다른 한 번은 에이전트 정의·스킬이 심어진 레포. 평균 점수는 49.5에서 79.3으로 올랐습니다(+60%). 둘째, 잔 볼루크의 Hashline 실험. 볼루크는 클로드 코드 편집 인터페이스의 포맷을 딱 한 줄 바꿨습니다. 변경 전 해시 위치 일치율은 6.7%, 변경 후는 68.3%. 같은 모델이 같은 태스크에서 실패율 93%에서 성공률 68%로 뒤집혔습니다. 이 외에 여러 모델들에서도 같은 포맷 변경 효과가 재현되었습니다. 포맷 한 줄이 모델 지능을 10배로 키운 것이 아니라 모델의 능력이 더 온전히 발휘되었을 뿐입니다.셋째, 랭체인의 Terminal Bench 2.0 결과. 동일 모델에서 미들웨어·프롬프트·에이전트 구조만 바꾼 DeepAgents 팀은 점수를 52.8에서 66.5로(+13.7%p) 끌어올렸습니다. 리더보드상 Top 30 밖에서 Top 5로 진입했습니다. 벤치마크 상위권의 한 자릿수 경쟁에서 이 정도의 상승폭은 보통 모델 세대 교체 수준입니다. 다시 말해 ‘모델을 더 똑똑한 것으로 바꿨을 때’ 기대하는 정도의 개선을, 모델은 그대로 두고 환경만 설계해도 얻었다는 뜻입니다. 세 실험은 독립적으로 설계되었지만 결론은 모두 같았습니다. “모델을 바꾸지 않고 환경만 바꿨는데 품질이 향상되었다.” 병목은 능력이 아니라 구조다 소프트웨어 공학의 역사는 위임의 사다리를 한 칸씩 오르는 과정이었습니다. 매 단계에서 엔지니어는 한 층 아래의 일을 런타임에 맡기고, 자신은 한 층 위로 올라섰습니다. 위임은 책임을 사라지게 하지 않습니다. 책임이 놓이는 층을 바꿀 뿐입니다. AI 에이전트는 이 사다리의 맨 끝 칸입니다. 그리고 이번 칸은 하나가 결정적으로 다릅니다.이전 다섯 칸은 전부 결정론적 작업을 결정론적 시스템에 위임하는 일이었습니다. 컴파일러는 같은 입력에 같은 어셈블리를 냅니다. GC는 같은 상태에서 같은 방식으로 회수합니다. AWS는 같은 요청에 같은 응답을 돌려줍니다. AI 에이전트만이 확률론적 시스템입니다. 같은 프롬프트에 다른 답이 돌아올 수 있습니다.모델이 확률적으로 답을 만들어내는 동안, 그 바깥 경계에서는 다른 일이 벌어집니다. 입력과 출력을 검증하고, 권한을 제한하고, 상태를 기록하고 관측합니다. 오늘날의 엄격함은 바로 이 경계에서 작동합니다. 같은 모델이 49점도 79점도 낼 수 있습니다. 사다리의 마지막 칸에서 엔지니어에게 남는 일은 ‘환경 설계’입니다. 그 본질은 ‘확률론 안쪽과 결정론 가장자리가 만나는 지점’을 설계하는 일입니다. 즉, 병목은 능력이 아니라 구조입니다. 하네스 = around the model하네스란 모델의 가중치를 바꾸지 않고, 모델 바깥의 권한·도구·검증·상태·관측을 설계해 에이전트가 일하게 하는 환경입니다. 프롬프트보다 넓고, 프레임워크보다 구체적인 개발자의 설계물입니다. 아카시 굽타 Aakash Gupta 는 2026년 초 한 문장으로 업계의 전환을 정리했습니다. “2025 was agents. 2026 is agent harnesses.” 2025년이 에이전트의 해였다면 2026년은 ‘에이전트 하네스의 해’라는 뜻입니다. 지금까지 모아온 증상·증거·진단에 이름을 붙일 시점이 왔습니다. 이름이 붙으면 논의가 정리되고, 논의가 정리되면 의사결정이 빨라집니다. 하네스 엔지니어링 Harness Engineering AI 에이전트가 일하는 환경 전체를 설계하고 운용하는 구조적 체계마구 harness 가 여러 마리 말의 힘을 하나의 방향으로 모으듯, 하네스는 모델의 출력이 흩어지지 않도록 모델 주변의 권한·도구·검증·상태·관측을 잡아줍니다. 랭체인이 “The Anatomy of an Agent Harness”에서 제시한 개념도 비슷합니다. 모델을 건드리지 않고, 모델 주위의 모든 것을 엔지니어링의 대상으로 여기는 것입니다.하네스는 파인튜닝도, RLHF도 아닙니다. 모델 가중치는 손대지 않습니다. 모델은 그대로 두고, 주변을 설계합니다. 권한, 도구, 검증, 상태, 관측. 이 다섯 개념이 하네스의 구성 요소입니다. 앞서 본 리플릿 사건에서 없었던 것이 바로 이 다섯 요소입니다. 권한이 DELETE를 막지 못한 상황에서, 도구 경계는 코드 프리즈 지시를 강제하지 못했습니다. 게다가 검증 과정에서 거짓 보고를 걸러내지 못했고, 상태 추적을 통한 복구 가능성 판단도 불가능했으며, 관측 시스템 역시 사건을 실시간으로 포착하는 데 실패했습니다. 출처: <하네스 엔지니어링 with 클로드 코드> p.34 하네스 엔지니어링 ⊇ 컨텍스트 엔지니어링 ⊇ 프롬프트 엔지니어링(⊇는 '포함한다'는 뜻으로, 하네스 엔지니어링이 가장 넓고 그 안에 컨텍스트 엔지니어링이, 다시 그 안쪽에 프롬프트 엔지니어링이 있다는 의미입니다.) 세 가지가 다루는 범위가 다릅니다. 프롬프트 엔지니어링은 한 번의 응답을 다루고, 컨텍스트 엔지니어링은 한 번의 추론에 들어가는 입력 전체를 다룹니다. 반면 하네스 엔지니어링은 시간이 흘러도 무너지지 않는 시스템 전체를 다룹니다. 그래서 하네스는 앞의 둘을 대체하는 개념이 아니라 상위 집합입니다. 잘 쓴 프롬프트와 잘 짜인 컨텍스트는 하네스 안에서도 그대로 쓰이고, 그 위에 권한 경계·검증 루프·상태 영속화·관측 파이프라인이 더해질 뿐입니다. 하네스 엔지니어링 ⊇ 컨텍스트 엔지니어링 ⊇ 프롬프트 엔지니어링위 콘텐츠는 『하네스 엔지니어링 with 클로드 코드』에서 발췌하여 재구성하였습니다.

편집 후기 | 『그림으로 배우는 생성형 AI』 출간을 앞두고 고민한 것들

안녕하세요. 『그림으로 배우는 생성형 AI』의 담당 편집자 A입니다. 며칠 전, 저희 도서를 추천해주신 게시글을 보게 되었습니다. 감사한 마음이 가장 먼저 들었고, 한편으로는 “아, 저 부분은 그렇게 보일 수도 있겠다” 싶어 괜히 뜨끔하기도 했습니다. 출처: Hika Maeng 님 페이스북 우선 책의 장점을 잘 짚어주셔서 정말 감사합니다. 말씀해주신 것처럼 이 책은 생성형 AI의 기초 개념부터 RAG, 에이전트까지 생각보다 꽤 넓은 범위를 다루고 있습니다. 사실 저도 교정을 보면서 “오… 생각보다 쉽지 않은데?”라는 생각을 여러 번 했습니다. 친절하게 설명하고 있지만, 내용은 결코 가볍지 않았거든요. 그래서 말씀하신 아쉬움도 충분히 이해합니다. 제목이나 표지만 보면 부담 없이 읽을 수 있는 입문서처럼 느껴질 수 있으니까요. 그런데 이 부분은 출간 과정에서 정말 많이 고민했던 지점이기도 했습니다. 오늘은 그 고민의 과정을 조금 풀어보려고 합니다. 원서 제목이 『Visualizing Generative AI』인데, 이걸 국내 독자들에게 어떻게 전달할지 고민이 많았습니다. 원제를 그대로 살리자니 조금 낯설고, 완전히 다른 제목을 붙이자니 이 책만의 강점이 흐려질 것 같았습니다. 기획 당시 정말 여러 개의 책 제목 후보가 있었습니다. 원서 제목의 느낌을 살린 ‘비주얼라이징 생성형 AI’도 있었고, 아예 새로운 방향에서 생각해 본 '인사이드 생성형 AI'나 ‘생각 지도’, ‘생성형 AI는 어떻게 생각할까’ 같은 제목까지 있었답니다. 제가 속한 팀은 물론 관련된 분들도 모두 모여 1시간이 넘는 회의를 진행하기도 했습니다. 그렇게 검토한 번역서 제목 후보만 34개였습니다. 고민의 흔적들. 번역서 제목 후보만 34개가 나왔습니다. 부제까지 합치면 더 많은건 비밀 많은 후보를 두고 논의한 끝에, 결국 이 책이 가진 가장 큰 특징인 “그림으로 이해한다”는 점을 제목에 담아야 한다는 결론에 이르렀습니다. 생성형 AI라는 주제가 여전히 어렵고 낯설게 느껴지는 만큼, 독자들이 조금이라도 덜 부담스럽게 책을 펼쳐볼 수 있기를 바랐습니다. 책 표지도 비슷한 고민의 결과였습니다. 어려운 내용을 최대한 알기 쉽게 풀기 위해 사용한 ‘일러스트’를 책 곳곳에서 확인하실 수 있답니다. 원서 표지를 그대로 사용하는 대신, 이 책의 특징인 내지 일러스트를 활용해보자는 의견이 나왔습니다. 기존 IT 도서와는 조금 다른 느낌으로 가보고 싶다는 욕심도 있었습니다. 어려운 내용을 최대한 알기 쉽게 풀기 위해 사용한 일러스트를 책 곳곳에서 확인하실 수 있는데요. 표지에서도 그런 분위기가 자연스럽게 전해지면 좋겠다고 생각했습니다. 물론 “내용에 비해 너무 가볍게 보이는 것 아닌가?”라는 의견도 충분히 공감합니다. 더 많은 독자분들에게 다가갈 수 있는 접근성에 중심을 둘지, 책의 전문성을 더 강조할 것인지 사이에서 저희가 내린 선택의 결과가 지금의 제목과 표지였다고 생각합니다. 출간 이후에도 이 책을 어떻게 독자분들께 잘 전달할 수 있을지에 대한 고민은 계속되고 있습니다. 저희 마케터님도 정말 열심히 일하고 계십니다. 책 속 4컷 만화를 활용해서 직접 영상도 만들고, 이것저것 시도하고 있는데 보다 보면 은근히 귀엽습니다. 도치맘 맞습니다. ㅎㅎ 그래도 책의 내용을 좋게 보시고 추천해주신 점, 그리고 아쉬운 부분까지 함께 남겨주신 점에 진심으로 감사드립니다. 이런 의견 덕분에 저희도 책을 다시 돌아보고, 독자분들이 어떻게 받아들이고 계신지 더 잘 생각해보게 됩니다. 아무쪼록 이 책이 필요한 분들에게 잘 닿았으면 좋겠습니다. 소통 창구는 언제든 열려 있으니, 좋은 추천과 의견 들려주시면 큰 도움이 될 것 같습니다. 항상 감사합니다. 더 좋은 책으로 뵙겠습니다. 편집자 A챗GPT 이후 생성형 AI는 빠르게 일상과 업무에 들어왔지만, 많은 사람들은 여전히 결과를 활용하는 데 머물러 있습니다. 왜 어떤 결과는 뛰어나고 어떤 결과는 불안정한지, 왜 데모는 쉬운데 실제 적용은 어려운지 궁금했다면, 이제 전체 구조를 이해할 차례입니다. 『그림으로 배우는 생성형 AI』는 생성형 AI의 개념과 작동 원리를 그림과 도식으로 직관적으로 풀어내고, 프롬프팅과 활용 사례를 넘어 에이전트 시스템, 애플리케이션 아키텍처, 책임 있는 AI까지 하나의 흐름으로 연결해 보여주는 책입니다. 생성형 AI를 그저 써보는 수준에서 벗어나, 무엇을 할 수 있고 어디에 어떻게 적용해야 하는지 판단하는 감각까지 익히도록 돕습니다. 생성형 AI를 가볍게 소비하는 데서 멈추고 싶지 않다면, 이 책이 가장 현실적인 출발점이 되어줄 것입니다. 이제는 잘 쓰는 것을 넘어, 원리를 이해하고 설계하는 단계로 나아가 보세요. "지금껏 나온 생성형 AI 입문서 중 가장 접근하기 쉬운 책이다. 생성형 AI가 내부적으로 어떻게 작동하는지 시각적으로 명확하게 설명해, AI를 둘러싼 과대포장을 걷어낸다. AI 애플리케이션을 구축하는 개발자와 리더에게 안성맞춤이다."_모나 모나, AWS 생성형 AI 전문가

조직을 망치는 리더에게는 공통점이 있다. (조직의 속도는 왜 리더에서 멈추는가 ➁)

조직을 망치는 리더들에게는 공통점이 있다. 언제나 바쁘다는 것이다. 일을 많이 하는 것과 바쁜 것은 다르다. 열심히 일하는 것과 바쁜 것 역시 다르다. 바쁜 리더는 조직의 병목을 자신의 분주함으로 눈속임한다. 물론 리더는 누구보다 많은 일을 감당해야 하고, 중요한 일을 잘 해내야 한다. 그러나 계절성 요인이나 돌발 상황이 아닌데도 항상 바쁘다면 무언가 잘못된 것이다. 바쁜 리더는 자신이 일을 많이 한다고 착각한다. 그리고 자신이 바쁘게 움직일수록 조직의 속도도 빨라질 것이라고 생각한다. 하지만 현실은 다르다. 리더가 항상 바쁜 조직은 의사결정과 권한이 리더에게 과도하게 집중된 상태일 가능성이 높다. 겉으로는 멀쩡해 보일 수 있다. 그러나 실제로는 조직이 리더에게 끌려다니고, 리더는 조직의 발목을 잡고 있다. 이런 상황에서 리더의 바쁨은 개인의 문제가 아니다. 조직 전체의 문제다. ※ 이 칼럼은 『리더존망』 이용훈 저자 링크드인 채널에 게재된 글을 일부 수정하였습니다. 아무리 뛰어난 사람이라도 개인에게 주어진 자원은 한정적이다. 리더 혼자 분주하게 움직여봐야 한계는 존재한다. 멀티코어로 작동해야 할 조직이 싱글코어로 움직이는 셈이다. 게다가 그 싱글코어가 다른 코어보다 더 낫다는 보장도 없다. 물론 바쁜 리더는 스스로 열심히 하고 있다고 말한다. 그러나 리더들이 구성원에게 자주 말하듯, 열심히 하는 것만으로 결과가 만들어지는 것은 아니다. 리더에게 필요한 것은 절대적인 시간 소모가 아니다. 조직과 구성원을 어떤 방향으로 이끌었는지, 그 결과 어떤 변화가 만들어졌는지다. 그럼에도 “나는 바쁘게 열심히 살고 있으니 괜찮다”고 스스로를 합리화하는 리더가 있다. 오히려 이건 무의미한 가짜 노동일 뿐이다. 이런 리더들의 상당수는 업무의 우선순위를 제대로 정하지 못한다. 정확히 말하면 우선순위의 기준이 다르다. 리더는 중장기 의제를 고민하고 조직의 방향성을 제시해야 한다. 그러나 이것은 어려운 일이다. 그래서 단순하고 반복적인 업무에 자신을 던져 놓고, 스스로 합리화한다. “ 나는 바빴으니 어쩔 수 없었다”고 말이다.그 결과 중요한 일은 뒤로 밀리고 조직의 방향성은 희미해진다. 방향성이 불명확하면 불필요한 공회전이 발생한다. 조직은 더 느려지고 리더는 더 바빠진다. 방향성이 흐려지면 조직의 모든 의사결정은 다시 리더에게 집중된다. 조직 내 일관된 판단 기준이나 가치 기준이 존재하지 않기 때문이다. 이런 조직에서는 리더가 자리를 비우는 순간 업무와 조직이 멈춘다. 사소한 수정이나 의사결정조차 리더의 확인을 거쳐야 하기 때문이다. 구성원의 일은 문제를 해결하는 것이 아니라 리더를 찾는 것으로 변질된다. 결국 조직 전체가 리더의 바쁨에 묶인다. 바쁜 리더는 단기적으로 조직의 속도를 저하시키고 장기적으로는 조직을 망쳐버린다. 그들은 잘못된 일을 열심히 한다. 문제는 그 성실함이 조직을 앞으로 나아가게 하지 않는다는 점이다. 바쁜 리더는 구성원의 본보기가 되지 못할 뿐 아니라, 구성원이 성장할 기회까지 빼앗는다. 리더의 중요한 역할 중 하나인 육성에도 실패할 수밖에 없다. 구성원이 바쁜 리더의 뒤처리만 반복하다 보면 남는 것은 물경력과 소모감 뿐이다. 책임 있는 일을 맡아보고, 판단해보고, 실패를 통해 배우는 기회가 사라진다. 조직이 성장할 조짐도 보이지 않는다면 구성원의 선택지는 분명해진다. 조직을 떠나는 것이다. 결국 조직에는 떠나고 싶어도 떠나지 못하는 사람과, 별다른 기대 없이 자리를 지키는 사람만 남게 되는 것이다. 분명 리더 자신이 초래한 상황임에도 바쁜 리더는 구성원의 역량 탓을 하며 자신이 모든 것을 해내려 한다. 낮아진 인재 밀도의 가장 큰 원인 중 하나가 자신이라는 사실은 외면한 채 말이다. 이런 일이 반복될수록 구성원은 수동적으로 변한다. 어차피 마지막 결정은 리더가 할 것이기 때문이다. 미리 고민할 필요도, 무언가 열심히 할 필요도 없다. 바쁜 리더 아래에서 좋은 사람은 떠나고, 남은 사람들도 점점 소극적으로 변한다. 저성과자들로 가득찬 조직에서 리더는 더 바빠질 뿐이다. 그렇다면 다음 질문은 하나다. 왜 리더는 바빠지는가? 겉으로 보이는 이유는 단순하다. 일이 많아서가 아니다. 위임에 실패했기 때문이다. 문제는 대부분의 리더가 그것을 실패로 인식하지 못한다는 데 있다.AI와 협업 도구의 발전으로 개인의 생산성은 그 어느 때보다 높아졌습니다. 하지만 정작 조직은 여전히 느립니다. 왜 조직의 속도가 리더에서 멈출까요? 책 『리더존망』에서는 그 이유를 모든 결정이 리더에게 몰리는 ‘의사결정의 구조’에서 찾습니다. 저자는 리더의 바쁨을 성실함이 아니라 위임 실패와 조직 병목의 신호로 바라봅니다. 그리고 조직을 망치는 나쁜 리더의 뿌리를 ‘완벽하다는 착각’, ‘장기 방향성 부족’, ‘타인에 대한 신뢰 부족’ 세 가지로 나누어 설명합니다. 더 나아가 16가지 나쁜 리더 유형을 통해 우리 조직의 속도가 어디에서 멈추고 있는지 구체적으로 돌아보게 합니다. 좋은 리더가 되는 법을 배우기 전에, 먼저 나쁜 리더가 되지 않는 법을 알아야 합니다. 조직이 느려졌다고 느낀다면 구성원을 탓하기 전에 리더의 일하는 방식과 의사결정 구조를 점검해 보세요. 리더의 바쁨이 조직의 병목이 되는 순간을 발견하고, '조직의 진짜 속도를 되찾는 방법'을 지금 이 책에서 확인해 보시기 바랍니다.

의견은 넘치는데 왜 아무도 확신하지 못할까

지난 글(바로가기)에서 우리는 "데이터는 많은데 정작 결정의 순간엔 망설여지는" 풍경을 이야기했고, 약속을 하나 했습니다. 이 시리즈는 다섯 단계를 따라갑니다. Awareness → Belief → Commitment → Diffusion → Embeddedness오늘은 그 첫 단계, Awareness입니다. 한 문장으로 줄이면 이렇습니다.조직이 "데이터가 필요하다"고 느끼는 순간은, "어, 우리 회의실엔 사실보다 의견이 너무 많네?"를 자각하는 순간입니다. 흥미로운 건, 이 자각이 데이터가 부족해서 오지 않는다는 점이에요. 오히려 의견이 차고 넘치는데 아무도 "이게 맞다"고 증명하지 못할 때 찾아옵니다.1. 데이터 기반의 의사결정을 위한 Awareness란 무엇인가 하버드 경영대학원의 스테판 톰키 교수는 조직이 실험 문화로 나아가는 과정을 다섯 단계로 정리했고, 그 첫 칸이 Awareness입니다. 정의는 간단해요. 경영진은 실험이 중요하다는 건 알지만, 아직 그걸 가능하게 할 프로세스도 도구도 없는 상태. 여전히 경험과 직관에 기댄 시행착오가 의사결정의 주된 방식입니다. "중요한 건 아는데, 할 줄은 모르는 상태" 그래서 Awareness는 완성이 아니라 출발선입니다. 그리고 다섯 단계를 하나로 꿰는 실은 결국 가설을 세우고 → 검증하고 → 다듬는 과학적 방법, 우리가 지난 글에서 이야기한 바로 그 순환이에요.오늘 우리가 서 있는 곳은 1번 칸입니다. 그런데 이 칸을 넘는 게, 생각보다 훨씬 어렵습니다. 2. Awareness의 시작 : "Fewer the facts, the stronger the opinion" 사실이 부족한 회의실에서는 결국 연봉이 가장 높은 사람의 의견이 결론을 냅니다. 보통 이를 HiPPO(Highest Paid Person's Opinion)라고 부릅니다.여기서 데이터 실무자로서 한 가지 짚고 싶어요. 많은 조직에서 Awareness의 방아쇠를 당기는 사람은 대개 데이터 분석가입니다. 거창한 보고서가 아니라, 회의실에서 던지는 질문 하나로요. "그게 정말 그것 때문일까요?" 지난 글의 쿠폰을 떠올려 보세요. "쿠폰 뿌렸더니 매출이 올랐다"는 상관관계, "쿠폰 때문에 올랐다"는 인과관계입니다. 이 질문 하나가 강한 의견을 갈 곳 없게 만들고, 조직이 처음으로 "어, 우리가 추측으로 결정하고 있었네?"를 자각하게 합니다. 다만 분석가는 자각을 촉발할 수는 있어도, 그걸 결정으로 바꾸려면 조직이 다음 한마디를 받아들여야 합니다. "내 판단이 틀릴 수도 있다."결정의 순간에 망설이는 이유는 결국 “우리는 무엇이 무엇을 움직였는지 모르고, 그걸 따져 물을 도구를 갖고 있지 않기 때문”입니다. 인과추론과 실험은 그 도구를 손에 쥐어주는 일이라고 생각합니다. 3. 왜 데이터로 결정하고, 왜 실험인가직관과 경험으로도 회사는 굴러갑니다. 그런데 왜 굳이 데이터로, 그것도 실험으로 결정해야 할까요?첫째, 직관은 자주 틀립니다. A/B 테스트 책의 저자 론 코하비가 마이크로소프트에서 실제로 실험을 돌려 보니, "분명 좋아질 것"이라 믿고 만든 기능 중 약 1/3만 지표를 올렸고, 1/3은 무변화, 1/3은 오히려 떨어뜨렸습니다. 셋 중 둘은 빗나간다는 뜻이죠.둘째, 그 차이가 성과로 드러납니다. 톰키 교수의 연구에 따르면, 강한 실험 문화를 가진 빅테크의 지난 10년 주가는 S&P 500을 꾸준히, 큰 폭으로 앞질렀습니다. 검증된 실험 없이 신제품을 내놓는 건 눈을 가리고 비행하는 것과 같다고 그는 말합니다. 그런데 왜 대시보드가 아니라 실험일까요? 대시보드는 "무엇이 일어났는가"를, 그것도 사후에 보여줄 뿐입니다. 정작 알아야 할 건 "무엇이 무엇을 움직였는가"인데 말이죠. 두 그룹을 무작위로 나눠 동시에 돌리는 A/B 테스트만이, 지표의 차이를 우리가 준 변화에서 온 것으로 분리해 줍니다. 상관을 인과로 착각하는 함정에서 우리를 꺼내 주는 거의 유일한 도구예요.물론 실험이 늘 의사결정의 마지막 선택권을 갖는 건 아닙니다. 종종 우리는 기업의 비전과 고객의 가치를 우선해야 하는 경우 데이터를 거슬러 결정을 내릴 수도 있습니다. 하지만 그때조차 실험이 있었기에 무엇을 포기하는지가 투명하게 기록하고 공유하는 것이 중요합니다. 4. Awareness의 진짜 의미는 "존중"이다많은 조직이 Awareness를 단순히 “데이터를 잘 볼 수 있는 BI 툴 도입하자”로 받아들입니다. 하지만, 가장 중요한 것은 개별 구성원의 의견과 가설이 쉽게 오고갈 수 있도록 만드는 “존중”의 문화를 만드는 데 달려 있습니다. 서로의 아이디어가 어느 정도의 가치를 가지는 지는 상위 의사결정권자도 그리고 실무자도 실험하기 전까지 알 수 없습니다. 실험 조직에서 리더는 위에서 결정을 내려 주는 사람이 아니라, 실험을 통해 결정이 내려지도록 돕는 사람입니다. 그리고 실험 결과는 의견과 편향을 이깁니다. 그 의견이 최고 경영진의 것이라 해도요. 진짜 실험 조직에서는 상사의 가정조차 현실의 테스트 대상이 됩니다. 그래서 Awareness의 본질은 "데이터로 검증해봐"가 아니라, 가장 높은 사람(앞서 말한 HiPPO죠)이 "내 판단 셋 중에 둘은 틀릴 수 있어"라고 인정하는 순간입니다. 이 자각이 없으면, 아무리 좋은 플랫폼을 깔아도 그건 결국 자기 판단을 뒷받침하는 도구로 전락합니다. 지난 글에서 가장 무섭다고 했던 풍경이기도 합니다. 5. AI 시대: 실행이 매우 쉬워진 지금, 자각이 더 절실하다 왜 하필 지금 이 자각이 더 중요해졌을까요? 이젠 AI로 인해, 아이디어에 대한 실행의 비용이 거의 0에 수렴했기 때문입니다. AI 코딩 도구로 며칠 걸리던 기능이 몇 분 만에 나옵니다. 이제 데이터 실무자가 코드를 작성하는 일은 더 이상 병목이 아닙니다. 대신 새로운 문제가 생겼어요. 더 많이 제품 또는 기능을 출시할수록, 내가 만든 변화가 진짜 효과가 있었는지에 대한 확신은 줄어듭니다. 이제 우리는 "이걸 출시할 수 있는가"에서 "빠르게 출시하고 해당 기능이 우리 고객에게 의미있는 기능인가"로 질문을 바꿔서 던져야 합니다. 옵션을 만드는 능력은 AI가 폭발적으로 늘려 줬지만, 그중 무엇이 진짜 지표를 움직였는지 판단하는 능력은 늘려 주지 않았습니다. 실행이 싸질수록, 모르는 것의 비용은 오히려 비싸집니다.AI가 실행을 대신하는 시대에 인간에게 남는 희소한 능력은, "무엇이 무엇을 움직였는가"를 따져 묻고 무엇을 남길지 판단하는 것입니다. 그게 인과추론이고 실험이며, 그 출발선이 Awareness입니다. 빠르게 만들수록, "이게 정말 효과가 있었나?"를 물을 줄 아는 조직과 아닌 조직의 격차는 더 빠르게 벌어집니다. 물론 AI 시대에 데이터 기반 의사결정 문화를 세우는 데 Awareness만으로는 아무것도 바뀌지 않습니다. 다만 첫 삽을 뜰 명분이 생긴 것이죠. 그 첫 삽의 이야기는 다음 글 Belief에서 이어집니다. Next in series Awareness — 의견은 넘치는데 아무도 확신하지 못한다는 걸 자각하는 순간 ← 오늘 여기까지Belief — 한 번의 실험이 만든 작은 균열 그 다음으로 Commitment → Diffusion → Embeddedness데이터를 바라보는 사람에서, 데이터로 결정하는 사람으로. 그 여정의 두 번째 글이었습니다. 스테판 H. 톰키, 『실리콘밸리의 실험실』(원제 Experimentation Works: The Surprising Power of Business Experiments), 한경BP, 2023Harvard Business School Executive Education, "The Critical Role of Leadership in Building a Culture of Experimentation" (Executive Insights) — 5단계 성숙도 모델·실험 문화의 7가지 속성Ron Kohavi, Online Controlled Experiments: Lessons from Running A/B/n Tests for 12 years (KDD 2015 Keynote), exp-platform.com함께 보면 좋은 강의 『데이터 실무자의 사고력 강화 : AI 인과추론 실무』는 크래프톤 데이터 분석가 신진수님과 함께 상관관계와 인과관계를 구분하는 사고 방식, 그리고 실무에서 실제로 활용되는 실험과 판단의 기준을 다루는 강의입니다.단순히 분석하는 것을 넘어, “무엇이 무엇을 움직였는가”를 고민해보고 싶다면 추천드립니다. 👉 『데이터 실무자의 사고력 강화 : AI 인과추론 실무』 보러 가기

멀티 에이전트 트렌드, "하나의 LLM에서 협력하는 에이전트 팀으로"

✍️ 서지영 마이크로소프트에서 Data&AI Specialist로 일하고 있습니다. 정보관리기술사와 컴퓨터시스템응용기술사 자격을 갖추고 20년 넘게 IT 분야에서 일해 왔으며, 고려대학교 대학원에서 빅데이터와 인공지능을 연구했습니다. LLM부터 RAG, MCP, 그리고 멀티 에이전트까지, 기술이 바뀔 때마다 직접 써보고 책으로 정리해 왔습니다. 이번에 출간된 『이것이 멀티 에이전트다』도 그 연장선입니다. 지난 2~3년 동안 생성형 AI를 둘러싼 질문은 빠르게 바뀌어 왔습니다. 처음에는 “어떤 모델이 더 똑똑한가”였다면, 지금은 “이 모델을 무엇과 연결해, 어떻게 일하게 만들 것인가”로 옮겨가고 있습니다. 모델 자체의 성능 경쟁만큼이나, 모델을 둘러싼 ‘에이전트’ 구조가 실무의 핵심 화두로 떠오른 것입니다. • 싱글 에이전트에서 멀티 에이전트로 초기의 LLM 활용은 대부분 ‘질문하면 답한다’는 단순한 형태였습니다. 여기에 도구 호출과 외부 검색을 붙이면서, 스스로 판단하고 행동하는 하나의 에이전트(싱글 에이전트)가 등장했습니다. 하지만 업무가 복잡해질수록 하나의 에이전트가 모든 일을 떠안는 방식에는 한계가 분명했습니다. 맥락이 길어지면 판단이 흐려지고, 역할이 뒤섞이면 디버깅도 어려워집니다. 좌: RAG의 기본 동작 과정 우: 에이전트의 기본 동작 과정 그래서 최근 흐름은 명확합니다. 데이터 수집·분석·평가·보고처럼 역할을 나누고, 각 역할을 맡은 에이전트들이 협력하는 멀티 에이전트 시스템입니다. 사람으로 치면 한 명의 만능 직원 대신 역할이 분담된 팀을 꾸리는 것과 같습니다. 각 에이전트는 자신의 일에만 집중하고, 오케스트레이터가 이들의 작업 순서와 결과를 조율합니다. 이렇게 책임이 분리되면 시스템은 더 안정적이고, 확장과 유지보수가 쉬워집니다. 좌: 싱글 에이전트 우: 멀티 에이전트 • MCP와 A2A, 표준화가 만드는 변화 멀티 에이전트가 현실적인 선택지가 된 데에는 '표준화'라는 또 하나의 흐름이 있습니다. 과거에는 에이전트마다, 도구마다 연결 방식이 제각각이라 매번 새로 붙여야 했습니다. 최근에는 MCP(Model Context Protocol)가 모델과 외부 도구·데이터를 잇는 공통 규격으로 자리잡으면서, 에이전트가 도구를 호출하는 방식이 한결 단순하고 재사용 가능해졌습니다. 나아가 A2A(Agent-to-Agent)처럼 에이전트끼리 직접 소통하는 방식도 정리되고 있습니다. 에이전트가 서로의 역할과 상태를 약속된 형식으로 주고받게 되면, 각각을 따로 개발한 에이전트라도 하나의 워크플로우로 엮을 수 있습니다. 이러한 프로토콜의 표준화는 멀티 에이전트를 '실험'에서 '운영'의 영역으로 끌어올리는 토대가 되고 있습니다. • 『이것이 멀티 에이전트다』를 어떻게 활용하냐면 이 책은 LLM을 단순히 호출해 보는 단계를 넘어, 여러 에이전트가 협업하는 실제 시스템을 직접 만들어 보려는 독자를 위해 집필했습니다. 파이썬으로 간단한 스크립트를 작성해 본 경험이 있거나, OpenAI API를 한 번쯤 호출해 본 적 있는 분, RAG 시스템을 만들어 보았고 그다음 단계를 찾고 있는 분, 딥러닝 이론보다 LLM을 '블록'으로 엮는 설계와 조립에 관심 있는 분이라면 바로 시작할 수 있습니다. 앞부분(Ch01 ~ 03)에서는 에이전트의 등장 배경과 구성 요소, 싱글과 멀티의 차이, 실행 구조와 상태 전달(AgentContext), A2A 통신, 그리고 MCP·FastMCP의 동작 원리를 개념 중심으로 정리합니다. 보안·품질 관리·비용 최적화처럼 운영 환경에서 마주칠 고민까지 미리 다룹니다. 읽는 순서는 자유지만 두 가지 경로를 권합니다. 개념부터 잡고 싶다면 LLM → RAG → 에이전트 → 멀티 에이전트 → MCP로 이어지는 동작 원리를 먼저 읽은 뒤 실습편으로 이동하는 방식이 적합합니다. 손부터 움직이고 싶다면 실습 환경을 갖춘 뒤 관심 있는 프로젝트부터 바로 진행해도 좋습니다. 실습은 학습용으로 꾸며낸 예제가 아니라 실생활과 실무에서 곧바로 쓸모 있는 주제들로 엄선하였습니다. 영업 데이터 분석과 시각화, 개인정보 탐지와 마스킹, 약관 기반 질의응답(RAG), 음성 Q&A, 병렬 검색을 통한 속도 개선, 반복 평가를 통한 품질 개선, 뉴스 기반 종목 영향 평가, 이상 거래 탐지, 맞춤형 여행 플래너까지. 모두 현장에서 실제로 마주치는 문제이며, OpenAI·Claude API와 MCP, Cursor 환경 위에서 직접 만들어 봅니다. 트렌드를 '읽는' 데 그치지 않고, 끝내고 나면 곧바로 '써먹을' 결과물을 손에 쥐게 된다는 점이 이 책의 가장 큰 강점입니다. 권하고 싶은 활용법은 단순합니다. 먼저 Ch01 ~ 03으로 멀티 에이전트와 MCP·A2A의 큰 그림을 잡아보세요. 그다음 자신의 업무와 가장 닮은 프로젝트 한두 개를 골라 끝까지 따라 만들어 보고, 거기에 자신의 데이터와 도구를 바꿔 끼워 보시길 권합니다. 책을 읽는 데서 멈추지 않고 작은 결과물이라도 직접 완성할 때, 개념은 비로소 자신의 것이 됩니다 • 독자별 추천 학습 방법 이 분야를 막 시작하는 분이라면, Ch01 ~ 03으로 흐름을 잡은 뒤 가장 만만해 보이는 프로젝트부터 결과물을 만들어 보시길 추천합니다. 코드를 정리하는 수준을 넘어, 실행해 보고 값을 바꿔가며 동작을 관찰하는 과정에서 깨달음이 생깁니다. 이미 LLM 애플리케이션을 다뤄 본 분이라면, 싱글 에이전트의 한계를 어떻게 멀티 에이전트 구조로 풀어내는지, MCP와 A2A가 도구·에이전트 연결을 어떻게 단순화하는지에 초점을 두고 읽으시길 권합니다. 빠르게 변하는 분야인 만큼, 놓치고 있던 표준과 패턴을 채우는 좋은 계기가 될 것입니다. 한 가지만 당부드립니다. 예제는 반드시 직접 실행해 보시기 바랍니다. 멀티 에이전트의 진가는 설계도가 아니라, 여러 에이전트가 비동기로 움직이며 만들어 내는 흐름의 상호작용에 있습니다. 그것은 로그를 찍어 보고 프롬프트를 바꿔 보는 과정에서만 체감됩니다. 각 장 끝의 '직접 해보기' 연습문제도 놓치지 마시기 바랍니다. 에이전트는 더 이상 하나의 거대한 모델에 모든 것을 맡기는 시대가 아닙니다. '문제를 작은 판단으로 나누어 협업하게 한다'는 발상은 도구가 바뀌어도 오래 남을 본질입니다. 역할을 나누고, 약속된 방식으로 연결하고, 협력하게 만드는 것. 이 책은 그 흐름을 개념과 실습으로 동시에 안내하는 실전 가이드입니다. 2026년 초여름, 서지영 드림 『이것이 멀티 에이전트다』는 LLM 단순 호출을 넘어 여러 에이전트가 협업하는 실제 시스템을 직접 설계하고 구현해 보고 싶은 개발자를 위한 책입니다. 멀티 에이전트의 동작 원리와 MCP·A2A 표준, 실행 구조까지 개념을 탄탄히 다진 뒤, 영업 데이터 분석·개인정보 탐지·약관 기반 RAG·음성 Q&A·이상 거래 탐지 등 현장에서 바로 활용할 수 있는 실습 프로젝트로 이어집니다. 트렌드를 읽는 데 그치지 않고, 책을 덮었을 때 손에 쥘 수 있는 결과물을 목표로 구성된 실전 가이드입니다.

이제 중요한 건 '할 수 있느냐'가 아니라 '무엇을 할 것이냐' (저자 인터뷰)

아이디어 하나로 혼자서도 글로벌 매출을 만드는 시대. 유튜브 74만 구독자 채널 '조코딩'의 크리에이터이자 교육자, 창업가 등 다양한 활동을 이어가는 조동근 저자의 신간 『조코딩의 바이브 코딩 1인 창업』은, 본인의 경험을 기반으로 코드 한 줄 없이도 기획부터 수익화, 구독, 글로벌 진출, 엑시트까지 이르는 '1인 프로덕트 빌더'의 길을 소개하는 도서입니다. 기술의 벽이 사라진 지금, 우리에게 정말 필요한 역량은 무엇일까.책의 핵심 메시지와 저자가 직접 걸어온 길을 인터뷰로 들어보았습니다.Q1. 간단하게 자기소개 부탁드립니다. 안녕하세요. 유튜브에서 74만 구독자를 보유한 '조코딩' 채널 크리에이터로 활동하며 AI 트렌드, 실용적인 AI 교육 등의 콘텐츠를 만들고 있습니다. 최근 '조코딩 AX 파트너스'라는 회사를 설립하며 기업들의 AI 전환을 돕는 일도 하고 있습니다. 유튜브 채널 <조코딩 JoCoding> Q2. 신간 『조코딩의 바이브 코딩 1인 창업』을 한 문장으로 소개한다면 어떤 책일까요? ‘AI 시대의 1인 유니콘이 되기 위한 모든 방법을 담은 책' 이라고 할 수 있을 것 같습니다. Q3. 저자님은 그동안 개발자뿐 아니라 교육자, 크리에이터, 창업가 등 다양한 역할을 하셨는데요. 처음 창업에 도전하신 이야기를 들려주세요. 처음 사업자를 낸 건 2016년이었습니다. 한국 화장품을 세일 기간에 저렴하게 사서 이베이(eBay)를 통해 해외로 수출하는 일이었는데요. 당시 이베이에서 제공하는 교육 프로그램이 꽤 체계적으로 잘 갖춰져 있어서, "어떤 형태로든 사업이라는 걸 직접 배우고 실천해보고 싶다"는 마음으로 시작했습니다. 적게나마 물건을 사고 팔며 사업의 기본을 몸으로 익힐 수 있었던 좋은 경험이었습니다. 다만 하다 보니 제가 정말 하고 싶은 건 IT 기반의 사업이라는 걸 점점 더 분명하게 느끼게 됐고, 그 갈증이 결국 직접 IT 서비스를 만들고 콘텐츠로 풀어내는 지금의 길로 이어지게 됐습니다. Q4. 지금까지 여러 창업가와 프로덕트 빌더들을 만나셨을 텐데요. 그중 자신의 사업 방식에 영향을 준 인사이트가 있다면 무엇인가요? 대학 시절 고려대·연세대 연합 창업 학회인 '인사이더스(Insiders)' 활동을 했는데, 거기서 배운 '린 스타트업(Lean Startup)' 개념이 지금까지도 제 사업 방식의 근간이 되고 있습니다. 린 스타트업의 창시자, 에릭 리스가 쓴 <린 스타트업(2012, 인사이트)>와 린 캔버스를 만든 애시 모리아가 쓴 <린 스타트업 개정판 (2023), 한빛미디어> 핵심은 "최대한 가볍고 빠르게(lean) 움직여라"는 것인데요. 완벽한 제품을 오래 준비해서 한 번에 내놓는 게 아니라, 최소한의 형태로 빠르게 만들어 시장에 내놓고, 사용자의 반응을 보며 고쳐나가는 방식입니다. 머릿속으로 구상한 제품과 실제로 사람들이 쓰는 제품 사이에는 늘 간극이 있기 마련이라, 빨리 검증하고 빨리 방향을 잡는 게 훨씬 효율적이더라고요. 이후 여러 창업가와 빌더들을 만나면서도 결국 성공하는 사람들은 예외 없이 '실행과 출시가 빠르다'는 공통점을 확인할 수 있었고, 그래서 저는 지금도 일단 작게라도 만들어 세상에 내놓는 것을 가장 중요하게 생각합니다. Q5. AI가 본격적으로 등장한 이후 창업 환경은 어떻게 달라졌다고 생각하시나요? 가장 크게 바뀐 건 "아이디어에서 실제 제품까지 걸리는 시간과 비용"입니다. 예전에는 개발자를 구하거나 외주를 맡기는 데 수백, 수천만 원이 들고 몇 달이 걸렸다면, 지금은 AI와 대화하듯 만들면서 며칠 만에 작동하는 서비스를 띄울 수 있습니다. 진입장벽이 사실상 무너졌고, 그래서 "할 수 있느냐"가 아니라 "무엇을 할 것이냐"가 더 중요한 시대가 됐습니다. Q6. 반대로 AI 시대가 되면서 새롭게 생긴 어려움이나 한계도 있을까요? 누구나 쉽게 만들 수 있게 된 만큼, 비슷한 서비스가 쏟아지면서 차별화가 더 어려워졌습니다. 진입장벽이 낮아진 건 모두에게 똑같이 적용되니까요. 그래서 저는 AI가 아무리 좋아져도 쉽게 대체하지 못할 '나만의 무언가'를 함께 쌓아두는 것이 점점 더 중요해졌다고 생각합니다. 예를 들면 꾸준히 신뢰를 쌓아온 브랜드나 팬덤, 먼저 확보한 사용자와 그 안에 축적된 데이터, 특정 분야에 대한 깊은 이해와 커뮤니티 같은 것들이죠. 기능 자체는 금방 복제할 수 있어도, 이런 자산들은 시간과 진정성이 쌓여야만 만들어지기 때문에 쉽게 따라 잡히지 않습니다. 결국 "무엇을 만들 것이냐"를 넘어 "왜 사람들이 다른 곳이 아닌 나를 선택해야 하는가"라는 본질적인 고민의 무게가 훨씬 더 커진 셈입니다. Q7. 이제는 개발자가 아니어도 서비스를 만들 수 있는 시대라고들 이야기합니다. 실제로 어느 정도까지 가능하다고 생각하시나요? 이제는 사실상 한계가 없다고 생각합니다. 오히려 "이건 못 만든다"고 할 만한 걸 찾는 게 더 어려운 시대가 됐어요. 예전에는 구현하고 싶은 것의 대부분이 사실 거대한 기술 지식까지는 필요하지 않았는데, 지금은 그 폭이 훨씬 더 넓어졌습니다. 단순한 서비스는 말할 것도 없고, AI가 발전할수록 기술적으로 고도화된 서비스까지도 비전공자가 직접 만들어볼 수 있게 됐으니까요. 결제를 붙이고, 사용자를 모으고, 실제 매출을 내는 단계까지 혼자서 충분히 도달할 수 있습니다. 물론 서비스가 커지고 복잡해질수록 부족한 부분이 보이겠지만, 그건 처음부터 다 알아야 하는 게 아니라 만들어 나가면서 하나씩 배우고 채우면 됩니다. 배우는 것도 AI의 발전으로 정말 쉬워졌으니까요. Q8. 저자님의 강의나 책을 통해 실제로 창업에 성공한 사례가 있다면 소개 부탁드립니다. 특히 기억에 남는 사례가 있을까요? 제가 만든 AI 기반 '동물상 테스트' 제작 과정을 영상으로 공유했더니 구독자분들이 비슷한 방식으로 '관상 테스트', '첫인상 테스트', '퍼스널 컬러 진단' 같은 서비스를 직접 만드셨고, 그중 수천만 원에서 억대 수익까지 올린 성공 사례들이 나왔습니다. <실전 수익형 웹, 앱 서비스 동물상 테스트 만들기> (유튜브 채널 '조코딩 Jo Coding') 거창한 이론이나 복잡한 기술 없이도 본질에 집중하면 충분히 좋은 결과를 만들 수 있다는 걸, 저뿐 아니라 많은 분들이 함께 증명해주신 셈이죠. Q9. AI 시대에 개인이 가장 먼저 길러야 할 역량은 무엇이라고 생각하시나요? "본질을 보는 눈"과 "일단 해보는 실행력"입니다. 기술적인 구현은 AI가 점점 더 대신해주기 때문에, 정작 중요한 건 "어떤 문제를 풀고 어떤 가치를 줄 것인가"를 정의하는 능력입니다. 거기에 더해, 머릿속 아이디어를 작게라도 직접 만들어 세상에 내놓고 반응을 확인하는 실행력이 뒷받침돼야 합니다. 결국 생각만 하는 사람과 만들어보는 사람의 격차가 가장 크게 벌어지는 시대라고 생각합니다. Q10. 만약 지금의 조코딩님이 아무것도 없는 상태에서 다시 시작해야 한다면, 가장 먼저 무엇부터 하실 것 같나요? 저라면 '제품'과 '콘텐츠'를 동시에 만들 것 같습니다. 둘을 따로 보지 않고 처음부터 한 묶음으로 가져가는 거죠. 구체적으로는, 숏폼으로 자연스럽게 전환될 수 있을 만한 제품을 먼저 기획할 것 같아요. 지금은 숏폼 바이럴이 상대적으로 높은 트래픽을 만들어낼 수 있는 가장 강력한 통로이기 때문에, 콘텐츠로 화제가 되면 그 관심이 곧바로 제품 유입으로 이어지도록 설계하는 전략입니다. Q11. 코딩이나 창업을 시작하고 싶지만 두려움을 느끼는 분들에게 드리고 싶은 조언이 있다면? 여러분이 닷컴 혁명이 시작되던 때나, 스마트폰이 막 세상을 바꾸던 그 시기로 다시 돌아갈 수 있다면, 무엇을 하시겠어요? 저라면 그 변화의 한가운데에서, 창업할 수 있다면 무조건 뛰어들었을 것 같습니다. 인터넷 붐 시절이라면 구글이나 아마존 같은 서비스를, 스마트폰이 막 퍼지던 때라면 페이스북 같은 서비스를 만드는 데 도전했을 거예요. 돌이켜보면 그때가 기회가 넘쳐나던 시기였다는 걸 우리는 이제 다 알고 있으니까요. 그런데 사실 지금이 바로 그런 시기입니다. 많은 분들이 AI가 닷컴이나 스마트폰보다도 더 큰 변화라고 이야기합니다. 훗날 미래에서 지금 이 순간을 되돌아본다면, "그때가 엄청난 기회의 시기였다"고 분명히 말하게 될 거라고 생각해요. 우리는 지금 그 시작점에 서 있는 겁니다. 지금이 바로 시작할 때입니다. Q12. 마지막으로 저자님의 책을 읽게 될, 미래의 창업가분들께 전하고 싶은 말씀이 있다면 부탁드립니다. 기술이라는 벽은 거의 사라졌고, 이제 남은 건 "한번 만들어보자"는 마음과 작은 실행뿐입니다. 이 책을 끝까지 읽는 데서 그치지 마시고, 책을 덮은 뒤 여러분의 아이디어를 직접 만들어보고, 세상에 내놓고, 자신만의 가능성을 발견해 보시길 진심으로 응원합니다. 감사합니다.아이디어는 있지만 개발이 막막한 사람들을 위해, AI와 함께 서비스를 만드는 방법을 담은 『조코딩의 바이브 코딩 1인 창업 with 클로드 코드, 수파베이스, 스트라이프』가 출간되었습니다. 누적 조회수 70만 강의를 한 권으로 풀어낸 이 책은 단순히 “AI로 코딩하는 법”을 소개하는 데서 끝나지 않습니다. 웹 개발 기초부터 디자인, 마케팅, 데이터 분석, 엑시트 전략까지 1인 프로덕트 빌더에게 필요한 전체 흐름을 단계별로 안내합니다. 특히 클로드 코드, 수파베이스, 클라우드플레어, 오픈AI API, 스트라이프 등 다양한 실전 도구를 활용해 아이디어를 실제 웹 서비스로 구현하고, 사용자를 모으고, 결제와 구독형 서비스로 운영하는 방법까지 배울 수 있습니다. 그 과정 속에서 독자는 AI를 단순한 코딩 보조 도구가 아니라, 기획부터 개발, 디자인, 마케팅, 운영을 함께하는 ‘창업 파트너’로 활용하는 법을 자연스럽게 익히게 됩니다. 그리고 막연했던 아이디어가 하나의 서비스가 되고, 나아가 글로벌 매출을 만드는 프로덕트로 성장하는 과정을 직접 경험할 수 있습니다.

[집필 후기] "AI 에이전트 내부에서는 대체 무슨 일이 일어날까?" 트랜스포머를 손으로 그려가며 찾은 답

최근 몇 년 동안 AI는 놀라운 성능을 보여주고 있습니다. 이제는 누구나 LLM을 활용해 AI 에이전트를 만들거나 업무를 자동화할 수 있죠. 새로운 서비스도 끊임없이 등장하고 있습니다. 또한 기존 AI 서비스의 새 버전이 발표될 때마다 사용자들은 다른 서비스와 성능을 비교하며 놀라운 결과물에 열광합니다. 이런 열기 속에서 저는 한 가지 궁금증이 생겼습니다. “AI 에이전트가 결과물을 만들어 내기까지 그 내부에서는 어떤 일이 일어나는 걸까?” AI 에이전트를 사용하면 할수록, 긴 문맥을 이해하는 LLM의 원리가 알고 싶어졌습니다. 얼핏 보면 사용자의 질문에 따라 적절한 답변을 능숙하게 내놓는 모습이 마치 마법과도 같이 느껴지는데, 대체 그 답변이 나오기까지 어떤 과정을 거치는지 궁금해진 것입니다. 그렇게 LLM의 원리를 찾아보다 보니 트랜스포머 아키텍처가 LLM의 뼈대가 되는 구조라는 것을 알게 되었습니다. 트랜스포머 내부에는 어텐션, 셀프 어텐션, 멀티 헤드 어텐션 같은 다양한 개념이 있었고, 제 의문은 꼬리에 꼬리를 물고 이어졌습니다. 하지만 관련 내용을 찾아보면, 대부분의 설명은 단순히 ‘이렇게 해야 성능이 좋아진다’는 수준에 그치는 경우가 많았습니다. 저는 여러 궁금증을 해결하기 위해 LLM과 관련된 논문을 찾아보기 시작했습니다. 그런데 논문의 특성상 자세한 설명이 생략되는 경우가 많아 직관적으로 이해하기는 어려웠습니다. 그래서 논문만으로는 이해하기 힘든, 생략된 과정 하나하나를 풀어가면서 수식과 함께 정리해 나가기 시작했습니다. LLM과 관련된 논문이 워낙 많고 다양한 방법론을 조사하다 보니 그 양이 방대했습니다. 그래서 책을 집필할 때는 LLM의 발전 과정에서 반드시 이해하고 넘어가야 하는 부분을 위주로 다루었습니다. 트랜스포머 내부 구조는 매우 복잡합니다. LLM이 답변을 생성하기까지 트랜스포머 내부에서는 기본적으로 행렬을 기반으로 여러 연산을 수행하는데, 이 과정이 워낙 까다로워서 어떻게 하면 독자님들께 효율적으로 설명할 수 있을지 고민했습니다. 그러던 중 이 과정을 행렬로 시각화해서 설명하는 것이 단순히 텍스트를 활용한 설명보다 직관적이라고 생각했고, 여러 가지 행렬 연산을 그림으로 표현하는 데 집중했습니다. 저는 지금까지 다양한 책을 집필하면서 그림을 통한 설명을 중요하게 여겨 왔고, 개인적으로도 그림을 활용한 설명을 좋아합니다. 그래서 이전 도서인 『한 권으로 배우는 도커&쿠버네티스』에서도 쿠버네티스의 내부 구조를 상세히 그리면서 작동 원리를 설명했습니다. 이번 책에서도 트랜스포머 내부 구조를 최대한 상세히 묘사하자는 생각으로 그림 작업에 공을 들였습니다. 특히 이번에는 정말 많은 행렬을 그렸는데, 그중에서도 구성 요소를 하나하나 개별 객체로 표현한 작업이 기억에 남습니다. 행렬의 특성에 따라 내부에 들어가는 색도 서로 다르게 설정했고, 수많은 색 가운데 어떤 것을 골라야 원리를 이해하는 데 도움이 될지 깊이 고민했습니다. 그 과정에서 색에 대한 공부도 많이 하게 되었는데, 힘든 만큼 무척 재미있었습니다. 어떤 분들은 AI의 도움을 받으면 빨리 그릴 수 있지 않느냐고 말하기도 했지만, 제가 표현하고자 하는 것이 100이라고 했을 때 AI를 활용해서는 100을 온전히 담아내기 어렵다고 보았습니다. 그렇게 되면 책을 읽는 분 입장에서도 이해도가 떨어질 수밖에 없습니다. 결국 책에 들어가는 그림은 모두 제가 직접 그렸습니다. 이번 책은 지금까지 제가 출간한 책 중에서 그림 작업에 가장 많은 시간을 들인 작업이었습니다. 그림을 힘들게 그린 만큼, 책을 펼쳐 결과물을 볼 때마다 뿌듯함이 느껴집니다. 이 노력이 독자님들께서 트랜스포머 아키텍처를 이해하시는 데 도움이 되면 좋겠습니다. 시중에는 LLM을 활용하는 방법을 안내하는 책이 많습니다. 하지만 저는 단순 활용법을 넘어, LLM이 어떻게 사용자가 입력한 긴 문맥을 이해하는지, 다수의 헤드를 사용하는 이유는 무엇인지, Query·Key·Value가 왜 필요한지 같은 내부 작동 원리에 대한 궁금증을 해결할 수 있는 책을 만들고 싶었습니다. 사실 지금까지 제가 집필해 온 책들은 대부분 내부 원리 설명에 집중해 왔고, 이번 책에서도 기존 도서를 좋아해 주시던 독자님들이라면 저의 의도를 느끼실 수 있으리라 생각합니다. 많은 분이 이론과 실전을 따로 떼어 생각하는 경향이 있는데, AI 에이전트를 제대로 활용하려면 결국 트랜스포머 아키텍처를 충분히 이해해야 합니다. 이를 통해 AI 에이전트를 사용하며 흔히 겪는 환각 현상이 왜 발생하는지 연관 지어 생각할 수 있고, AI 에이전트의 활용 방법도 더욱 다양한 관점에서 바라볼 수 있습니다. 모든 일에 AI 에이전트를 활용하는 시대는 이미 현재 진행형입니다. 나날이 발전하는 시대에, AI를 단순히 활용하는 것을 넘어 AI가 어떻게 동작하는지 이해하는 일이 점점 더 중요해지고 있습니다. AI 에이전트의 작동 원리를 파악함으로써 더욱 능동적으로 활용하실 수 있으면 좋겠습니다. 독자님들이 이 책을 통해 AI 에이전트에 한 발 더 가까워지는 계기가 되면 좋겠습니다. 감사합니다. 장철원AI 에이전트 개발 도구는 점점 쉬워지고 있습니다. Ollama로 로컬 모델을 실행하고, 랭체인과 랭그래프로 흐름을 만들고, RAG로 외부 문서를 연결하는 일도 이제는 낯설지 않습니다. 하지만 모델이 왜 그런 답을 내놓는지, RAG 결과가 왜 흔들리는지, 에이전트 구조를 어떻게 확장해야 하는지 모른다면 예제를 넘어 자기만의 서비스로 발전시키기 어렵습니다. 『트랜스포머 아키텍처로 배우는 AI 에이전트 with 랭체인 & 랭그래프』는 AI 에이전트를 단순히 사용하는 데서 벗어나, 내부 구조를 이해하며 직접 구현하도록 돕습니다. 토큰화, 임베딩, 강화학습 기초부터 RNN, 어텐션, 트랜스포머 구조까지 차근차근 살펴보고, 이후 Ollama, Transformers, 랭체인, 랭그래프로 AI 에이전트를 구현합니다. 또한 LoRA, QLoRA, 양자화, ChromaDB 기반 RAG, 멀티 에이전트, MCP까지 실습하며, 마지막에는 Streamlit으로 AI 에이전트 서비스를 직접 만들어봅니다. 단순히 “AI 에이전트를 만들어봤다”에서 끝나지 않고, 구조를 이해하고 원하는 문제에 맞게 설계·확장하고 싶다면 이 책이 좋은 출발점이 되어줄 것입니다.

멀티 에이전트를 서비스에 올리기 전에 반드시 잡아야 할 것들: 보안, 품질, 비용

▶ 이전글: 에이전트는 어떻게 연결되고 실행되는가: 상호작용 패턴부터 오케스트레이터, MCP까지 멀티 에이전트 시스템을 구현하고 배포까지 마쳤다고 해서 끝이 아닙니다. 실제 운영 환경에 들어서는 순간, 기능의 정확성 외에 전혀 다른 종류의 문제들이 기다립니다. 에이전트가 어디까지 접근할 수 있는지, 생성된 응답이 일관되게 품질을 유지하는지, 반복 추론과 도구 호출이 누적되는 비용을 어떻게 통제할 것인지, 이 세 가지는 멀티 에이전트를 실무에 내재화하기 위한 필수 과제입니다.품질 관리 구조 • 에이전트에게 권한을 어디까지 줄 것인가: 보안과 규정 준수 멀티 에이전트 시스템은 외부 도구를 호출하고 데이터를 조회·수정할 수 있는 실행 권한을 가집니다. 설계가 부적절하면 잘못된 응답을 넘어 시스템 자원에 직접 영향을 줄 수 있습니다. 운영 환경 배치 전에 보안과 규정 준수는 선행 조건이 되어야 합니다. 실행 권한 통제의 핵심 원칙은 최소 권한 원칙입니다. 각 도구는 과업 수행에 필요한 최소한의 권한만 보유해야 하며, 데이터 조회 전용 도구와 수정 도구를 명확히 분리하고, 데이터 변경이나 삭제와 같은 고위험 작업을 수행하는 도구의 노출을 엄격히 제한해야 합니다. MCP 기반에서는 모델이 시스템 자원에 직접 접근하지 않고 서버를 거치는 간접 실행 방식을 취하므로 기본적인 물리적 격리를 제공하지만, 운영 안정성을 확보하려면 서버 자체에 대한 접근 제어 리스트(ACL) 적용과 상호 인증이 수반되어야 합니다. 최소 권한 원칙 에이전트의 판단이 실제 행동으로 전이되는 과정을 제어하기 위해서는 별도의 검증 계층이 필요합니다. 생성된 응답이나 실행 요청이 사전에 정의된 정책에 부합하는지 검증하는 정책 검토 에이전트를 배치하고, rm -rf나 DROP TABLE 같은 시스템 파괴적 명령어를 차단하는 룰 기반 필터를 병행 운용해야 합니다. 민감한 자원 접근이나 대규모 데이터 변경 전에는 반드시 사용자의 명시적 승인을 거치도록 흐름을 구성하는 HITL(Human-in-the-Loop) 구조도 핵심 장치입니다. 자동화 범위가 넓어질수록 HITL 적용 조건을 더 정확히 정의해야 합니다. HITL(Human-in-the-Loop) 구조 운영 환경에서는 "어떤 근거로 무엇이 실행되었는가"를 투명하게 증명할 수 있어야 합니다. 사용자 요청부터 모델의 도구 호출 의도, 실제 전달된 파라미터, 도구 실행 결과, 최종 응답까지의 전 과정을 기록하는 통합 로깅 체계와, 특정 행동이 수행된 시점의 컨텍스트를 보존해 사후 감사 시 에이전트의 판단 근거를 추적할 수 있는 구조가 반드시 구축되어야 합니다. • 응답 품질을 일관되게 유지하는 방법과 비용을 줄이는 전략 모델 사용량과 비용 증가 멀티 에이전트 환경에서 가장 먼저 직면하는 품질 과제는 정확성과 일관성입니다. 모델이 생성하는 응답은 확률에 기반하므로 항상 일정할 수 없으며, 도구 호출이 결합된 체계에서는 잘못된 판단이 곧 실질적인 실행 오류로 직결됩니다. 품질 관리는 단발성 검증에 그쳐서는 안 됩니다. 모델의 버전 업데이트, 프롬프트의 미세 조정, 새로운 도구의 추가 등 시스템의 모든 변화는 출력 결과의 변동을 초래합니다. 검토 인력에 의존하는 수동 방식은 확장성의 한계가 명확합니다. 대표적인 자동화 평가 방식이 LLM-as-a-Judge입니다. 고성능 모델을 평가자로 활용해 하위 에이전트들의 응답 품질을 사전에 정의된 기준에 따라 정량화하는 방식으로, 평가 기준을 프롬프트에 구체적으로 명시하고 결과를 주기적으로 검토하는 것이 중요합니다. 일관성 확보의 관점에서는 동일한 입력에 대해서도 모델의 Temperature 설정이나 조건 분기 로직에 따라 결과 편차가 발생할 수 있습니다. 모호한 지시는 에이전트의 판단 분산을 야기하므로 정책 정의를 구체화해 실행 경로가 최대한 일정한 궤적을 그리도록 유도해야 합니다. 자율적 판단이 필요 없는 구간에는 규칙 기반(Rule-based) 로직을 결합해 시스템 전체의 재현 가능성을 높이는 아키텍처적 보완도 필요합니다. 비용 최적화의 출발점은 컨텍스트 최소화입니다. 동일한 입력값이 여러 에이전트를 거치며 반복적으로 전달되면서 발생하는 정보의 중복은 직접적인 비용 상승으로 이어집니다. 각 에이전트의 역할에 맞게 필요한 데이터만 선별해 전달하고, 오케스트레이터가 전체 맥락 중 해당 단계에 필요한 정보만 선별해 에이전트에 전달하는 선택적 컨텍스트 주입 방식이 효율적입니다. 유사한 요청이 반복되는 환경에서는 이전 실행 결과를 재활용하는 캐싱 계층 도입도 성능 개선의 핵심이 됩니다. 모든 공정을 최고 사양의 모델로 처리할 필요는 없습니다. 모델 계층화(Model Tiering) 전략은 과업의 난도에 따라 모델을 적절히 배치합니다. 초안 생성·데이터 분류·단순 형식 검증 같은 단계에는 연산 속도가 빠르고 저렴한 소규모 모델(SLM)을 배치하고, 최종 의사결정·복합 추론·고도화된 품질 검증 등 높은 정밀도가 요구되는 지점에서만 최상위 모델을 호출해 전체적인 비용 구조를 최적화합니다. 경량 모델은 복잡한 추론 구간에서 품질 저하가 발생할 수 있으므로, 모델 배치는 실제 출력 품질 측정 결과를 바탕으로 결정해야 합니다. 보안·품질·비용, 세 가지 운영 과제는 독립적으로 존재하는 것이 아닙니다. 최소 권한 원칙으로 실행 범위를 통제하고, 자동화된 평가 체계로 품질을 일관되게 유지하며, 모델 계층화와 컨텍스트 최소화로 비용 구조를 최적화하는 것이 멀티 에이전트를 실무에서 지속 가능하게 만드는 설계입니다. 위 컨텐츠는 서지영 저자님의『이것이 멀티 에이전트다』의 내용을 재구성하여 제작되었습니다.

에이전트는 어떻게 연결되고 실행되는가: 상호작용 패턴부터 오케스트레이터, MCP까지

▶이전글: LLM 하나로는 부족하다: 멀티 에이전트가 등장한 이유 오케스트레이터의 구조 멀티 에이전트 시스템을 설계할 때 가장 먼저 부딪히는 질문은 "에이전트들을 어떻게 연결할 것인가"입니다. 에이전트 각각의 역할을 정의하는 것만으로는 부족하고, 실행 순서와 상태 공유 방식, 전체 흐름을 제어하는 구조까지 함께 설계되어야 시스템이 안정적으로 작동합니다. 이 글에서는 에이전트 간 연결 구조를 결정하는 상호작용 패턴과 AgentContext, 그리고 실행 흐름을 통제하는 오케스트레이터와 MCP의 동작 원리를 순서대로 짚어봅니다. • 에이전트를 어떤 순서로, 어떻게 연결할 것인가: 상호작용 패턴과 AgentContext 멀티 에이전트에서 핵심은 여러 에이전트가 어떤 방식으로 연결되어 목표를 수행하는가에 있습니다. 이 연결 구조를 상호작용 패턴(Interaction Pattern)이라고 합니다. 동일한 에이전트 집합이라도 어떤 상호작용 패턴을 적용하느냐에 따라 시스템의 안정성, 확장성, 장애 대응 방식이 달라집니다. 순차 실행 패턴(Sequential Pattern)은 하나의 에이전트가 과업을 수행한 뒤 그 결과를 다음 에이전트에 전달하는 선형 구조입니다. 이전 단계의 출력값이 곧 다음 단계의 입력값이 되므로 실행 경로가 고정되어 있고 단계별 추적이 용이합니다. 중간 단계에서 오류가 발생하면 전체 실행이 중단될 수 있으므로, 단계별 예외 처리와 재시도 정책을 함께 설계해야 합니다. 순차 실행 패턴(Sequential Pattern) 병렬 실행 패턴(Parallel Pattern)은 여러 에이전트가 동시에 실행되어 과업을 병렬로 처리하는 방식입니다. 동일한 입력을 여러 에이전트에 동시에 전달해 서로 다른 관점의 분석을 수행하거나, 상호 의존성이 낮은 여러 작업을 동시에 처리합니다. 병렬 실행 결과가 서로 상이한 경우를 대비해 우선순위 규칙이나 점수 기반 선택 로직과 같은 결과 통합 전략을 정의해야 합니다. 병렬 실행 패턴(Parallel Pattern) 반복 개선 패턴(Feedback Loop Pattern)은 생성된 결과를 평가한 뒤 기준에 미달할 경우 다시 생성 단계로 되돌려 수정하는 구조입니다. 단순 재시도가 아니라 평가 결과를 근거로 다음 출력을 개선하는 순환 체계라는 점이 핵심입니다. 반복 구조는 비용과 실행 시간을 증가시킬 수 있으므로 최대 반복 횟수, 점수 개선율 임계치 등 종료 조건(Exit Condition)을 반드시 정의해야 합니다. 반복 개선 패턴(Feedback Loop Pattern) 실무에서는 단일 패턴만 적용되는 경우가 드뭅니다. 패턴의 이름보다 중요한 것은, 각 단계가 어떤 의존 관계로 연결되고 어떤 조건에서 다음 단계가 실행되는지를 명확히 정의하는 일입니다. 이처럼 여러 에이전트가 협력하는 구조에서는 단계 간 상태를 어떻게 유지하고 공유하는지가 핵심 문제가 됩니다. 이를 해결하는 개념이 AgentContext입니다. AgentContext는 단순한 값 저장용 컨테이너가 아닙니다. 하나의 작업(Task)이 수행되는 동안 필요한 실행 상태를 체계적으로 유지하는 실행 메모리 아키텍처입니다. 과업 목표, 사용자 입력, 중간 추론 결과, 도구 실행 이력, 의사결정에 필요한 메타데이터 등을 통합해 관리합니다. AgentContext의 구성 요소 각 에이전트는 AgentContext를 참조해 현재 작업의 진행 상황과 이전 판단 근거를 확인하고, 자신의 실행 결과를 다시 컨텍스트에 반영합니다. 이는 단순한 데이터 공유가 아니라 실행 연속성을 유지하기 위한 상태 동기화 과정입니다. 컨텍스트가 분리되면 단계 간 상태 정합성이 보장되지 않아 결과가 일관되지 않을 수 있습니다. 반대로 일관된 AgentContext가 유지되면 개별 추론은 공통 상태를 기반으로 결합되어 협업적 실행 구조를 이룹니다. AgentContext는 특정 작업 범위 내에서만 유지되는 실행 상태 관리 계층으로, 장기 저장을 위한 메모리 계층과는 구분됩니다. 실무에서는 LangGraph의 State, Microsoft Semantic Kernel의 KernelContext, AutoGen의 context_variables 등 다양한 이름으로 같은 패턴이 구현되어 있습니다. • 실행 흐름을 제어하는 방법: 오케스트레이터와 MCP 여러 에이전트의 실행 흐름을 통합 관리하는 런타임 제어 계층을 오케스트레이터(Orchestrator)라고 합니다. 오케스트레이터는 복합적인 사용자 요청을 실행 가능한 단위로 분해해 각 단계에 적합한 에이전트를 매칭하고, 순차·병렬·반복 개선 등 과업 특성에 맞는 실행 전략을 선택합니다. 또한 AgentContext에 축적된 중간 결과를 바탕으로 재시도, 분기, 대안 경로 선택을 수행하며, 네트워크 지연이나 도구 실행 실패 같은 예외 상황을 감지해 대응합니다. 오케스트레이터의 도입은 필수 조건이 아니라 아키텍처적 선택입니다. 중앙 집중형(With Orchestrator)은 하나의 제어 계층이 전체 실행 경로를 정의하고 관리하므로, 복잡한 조건 분기와 반복 구조를 체계적으로 통제할 수 있고 품질 검증과 감사 추적이 용이합니다. 분산 협력형(Without Orchestrator)은 각 에이전트가 A2A 통신이나 공유 상태 구조를 통해 직접 협업하는 방식으로, 기능 단위를 독립적으로 배포하거나 교체하기에 유리합니다. 다만 시스템 규모가 커질수록 실행 경로의 가시성과 장애 통제가 복잡해질 수 있습니다. 실무에서는 전체 흐름은 중앙에서 관리하되 전문 기능은 분산 위임하는 혼합형 구조가 일반적입니다. 구분중앙 집중형(오케스트레이터 기반)분산 협력형(에이전트 협업 기반)실행 통제중앙에서 전체 흐름을 관리각 에이전트가 부분적으로 흐름을 제어일관성목표 중심으로 실행 경로 정렬 용이실행 경로가 동적으로 분산될 수 있음구조 복잡도제어 로직 설계로 초기 난이도 높음구조는 단순하나 운영 제어는 복합적가시성 및 추적단계별 실행 로그 추적이 명확함전체 경로 파악을 위한 별도 로직 필요적합한 환경복합 프로세스, 품질 관리 중심 환경단순 협업 구조, 기능 중심의 확장 환경 오케스트레이터가 에이전트들의 실행 흐름을 제어한다면, MCP(Model Context Protocol)는 모델이 외부 도구와 상호작용하는 방식을 표준화합니다. 모델은 스스로 파일을 열거나 코드를 실행하거나 데이터베이스에 직접 접근하지 않습니다. 모델의 역할은 입력을 해석하고 어떤 도구가 필요한지 판단하는 것에 한정되며, 실제 실행은 별도의 계층에서 이루어져야 합니다. MCP는 이 역할 분리를 구조적으로 정의하는 실행 규격입니다. 모델은 판단에 집중하고, 실행은 MCP 서버가 담당하며, 도구는 실제 연산만 수행합니다. MCP 서버를 활용한 도구 흐름 MCP의 동작은 다섯 단계로 이루어집니다. 먼저 모델이 도구 이름과 입력 인자를 포함한 구조화된 호출 요청을 생성합니다. 이 요청은 MCP 클라이언트를 통해 MCP 서버로 전달되며, 이 과정에서 모델과 실행 환경은 물리적·논리적으로 분리됩니다. 서버는 요청을 즉시 실행하지 않고 요청 형식 검증, 도구 등록 여부 확인, 인자 유효성 검사, 실행 권한 점검의 절차를 거칩니다. 검증을 통과한 요청에 한해 도구가 호출되어 실제 연산을 수행하고, 그 결과는 서버를 거쳐 다시 모델로 전달됩니다. 모델은 이 결과를 바탕으로 최종 응답을 생성하거나 추가 도구 호출이 필요한지 다시 판단합니다.MCP 구조 FastMCP는 MCP 서버를 간결한 코드로 구현할 수 있는 경량 프레임워크입니다. @mcp.tool() 데코레이터가 적용된 함수는 MCP 서버에 등록되어 외부에서 호출 가능한 툴로 노출되며, 함수 이름·독스트링·타입 힌트는 툴의 메타데이터로 자동 변환됩니다. 전송 방식은 두 가지로 구분됩니다. ① stdio 방식은 표준 입출력 채널을 통해 요청과 응답을 주고받는 방식으로 추가 네트워크 구성 없이 동작해 로컬 개발 단계에서 구조를 빠르게 검증하기에 적합합니다. ② SSE(Server-Sent Events) 방식은 MCP 서버를 지속적으로 실행되는 서비스 형태로 구동하고 HTTP 기반 스트리밍 연결을 통해 통신합니다. 여러 클라이언트가 동시에 접속하거나 멀티 에이전트 환경에서 공통 MCP 서버를 공유할 때 유리한 구조입니다. 두 방식은 MCP 규격을 공유하므로 전환 시 핵심 로직을 그대로 유지할 수 있습니다. 정리하자면, 에이전트가 어떤 순서로 실행되고, 상태를 어떻게 공유하며, 외부 도구를 어떻게 호출하는지에 대한 답이 바로 상호작용 패턴, AgentContext, 그리고 MCP입니다. 이 연결 구조를 이해했다면, 다음 단계는 이 시스템을 실제 운영 환경에서 어떻게 안정적으로 유지하는가입니다. ▶ 다음글: 에이전트는 어떻게 연결되고 실행되는가: 상호작용 패턴부터 오케스트레이터, MCP까지위 컨텐츠는 서지영 저자님의『이것이 멀티 에이전트다』의 내용을 재구성하여 제작되었습니다.

다양한 기업과 함께 하는 한빛+

한빛+는 콘텐츠부터 교육, 기술까지 다양한 기업과 함께합니다.

MCP 마스터 클래스: 단절된 LLM을 넘어 깃허브부터 자피어까지 연동하는 AI 에이전트 자동화

로컬 커밋부터 깃허브 액션 자동화까지, 바이브 코딩을 위한 깃허브 워크플로 A to Z

데이터 분석 기반 전략 수립 역량 강화 교육 과정

일 잘하는 사람은 이렇게 챗GPT를 씁니다

실전 예제로 다지는 머신러닝&딥러닝 with 파이썬(AI 심화편)

TypeScript 실무 캠프: 타입으로 완성하는 실전 코드

OpenClaw 스타일 AI Agent 보안 관제 시스템 만들기

파이썬 머신러닝 입문: 자연어 처리와 컴퓨터 비전까지

데이터 실무자의 사고력 강화 : AI 인과추론 실무

초보자도 바로 쓰는 API 연동 마스터 클래스: 머신러닝 기본부터 RAG 최적화까지

10가지 업무 시나리오로 배우는 생성형 AI 실무 활용

프롬프트 엔지니어링부터 크로마DB까지! 뼈대부터 탄탄하게 세우는 실전 AI 앱 개발