AI 시대의 콘텐츠와 자동화 설계가 막히는 이유는 기술이 부족해서가 아니라, 그 끝에 있는 '사람'을 먼저 떠올리지 않기 때문이다.

한 기업 교육에서 이런 질문을 받은 적이 있다. "박사님, 저희도 GPT를 도입했는데 왜 직원들이 안 쓸까요?" 회사는 비싼 라이선스를 구매했고, 사내 가이드라인을 배포했으며, 사용법 강의까지 열었다. 그런데도 3개월 뒤 실제 사용률은 한 자릿수였다. 담당자는 도구의 성능을 의심했다. 나는 다른 질문을 던졌다.

"이 도구를 매일 켜야 하는 사람은 어떤 하루를 보내나요?"

답이 막혔다. 회사는 'AI 도입'은 설계했지만, 'AI를 쓰는 사람'은 설계하지 않았다.

이것은 특정 회사만의 문제가 아니다. 지금 거의 모든 조직이 같은 자리에 서 있다. 도구는 넘치는데 정착은 더디다. 자동화는 가능한데 실제로 돌아가는 워크플로는 드물다. 사람들은 기술의 한계를 탓하지만, 대부분의 실패는 기술 이전에 일어난다. 설계의 출발점이 잘못 놓였기 때문이다.

01측정 가능한 것에 매달리는 함정

기술은 측정하기 쉽다. 모델의 성능, 응답 속도, 토큰 비용, 정확도. 숫자로 떨어지는 것들은 의사결정을 편하게 만든다. 반대로 사람은 측정하기 어렵다. 그 사람이 하루 중 언제 가장 바쁜지, 어떤 작업을 귀찮아하는지, 새 도구 앞에서 무엇을 두려워하는지는 표에 들어가지 않는다.

그래서 조직은 측정 가능한 것에 매달린다. 어떤 모델을 쓸지, 어떤 솔루션을 도입할지를 몇 달간 논의한다. 정작 그 도구를 매일 마주할 사람의 동선은 한 시간도 들여다보지 않는다.

에디터를 꿈꾸는 사람들에게 글쓰기를 가르칠 때, 기능이 아니라 그 글을 읽을 사람을 먼저 떠올리라고 한다. '이 글을 읽는 사람은 어떤 하루를 보내고, 무엇에 지쳐 있고, 어떤 한 문장을 기다릴까.' 추상적인 주제 앞에서 막막하던 사람도, 독자 한 명을 구체적으로 그리는 순간 첫 문장이 나온다. AI 설계도 다르지 않다. 거창한 기술 개념의 진입 장벽을 걷어내면, 그 안에는 결국 일하는 사람이 있다.

02도구를 도입하지 말고, 사람의 하루를 재설계하라

대부분의 AI 도입은 '도구 중심'으로 시작한다. 좋은 도구를 고르면 좋은 결과가 나올 거라는 가정이다. 그러나 도구는 하루의 흐름 속에 자리를 잡지 못하면 쓰이지 않는다.

한 공공기관 PoC에서 민원 답변 초안을 AI가 작성하도록 설계한 적이 있다. 처음엔 별도 웹페이지에 접속해 질문을 입력하는 방식이었다. 사용률은 거의 0이었다. 담당자들이 이미 쓰던 업무 시스템을 벗어나 새 창을 여는 그 한 번의 행동이 장벽이었다. 설계를 바꿔, 기존 민원 시스템 안에서 버튼 하나로 초안이 뜨도록 했다. 사용률은 단숨에 60퍼센트를 넘었다.

바뀐 것은 모델이 아니었다. 사람의 동선이었다.

03사람은 정답보다 통제감을 원한다

AI가 완벽한 답을 주면 사람들이 좋아할 거라 생각하기 쉽다. 현실은 다르다. 완성된 결과물을 통째로 던지면, 사람들은 오히려 불안해한다. 자기가 검토할 수 없는 것을 신뢰하지 못하기 때문이다.

마케터를 대상으로 한 자동화 워크숍에서 흥미로운 장면을 봤다. AI가 카피 완성본 한 개를 주는 버전보다, 초안 세 개를 주고 고르게 하는 버전의 만족도가 훨씬 높았다. 결과물의 품질은 비슷했다. 차이는 '내가 골랐다'는 감각이었다.

사람은 자동화의 객체가 되는 순간 손을 뗀다. 반대로 마지막 판단권이 자기에게 있다고 느끼면 적극적으로 개입한다.

자동화를 설계할 때 '완전 자동' 대신 '사람이 마지막에 선택하는 구조'를 기본값으로 두라. AI는 선택지를 좁혀주는 역할, 결정은 사람의 몫. 통제감을 남겨두는 설계가 더 빨리 정착한다.

04신뢰는 성능이 아니라 예측 가능성에서 온다

직장인이 AI를 멀리하는 가장 큰 이유는 성능이 나빠서가 아니다. 언제 틀릴지 예측할 수 없어서다. 한 번 엉뚱한 답을 받으면, 그 도구는 '가끔 거짓말하는 동료'가 된다. 사람은 가끔 거짓말하는 동료에게 중요한 일을 맡기지 않는다.

개발자 팀에 코드 리뷰 보조 도구를 도입했을 때, 정확도 95퍼센트짜리 모델이 외면당하는 걸 봤다. 문제는 5퍼센트의 오류가 '아무 표시 없이' 섞여 있다는 점이었다. 설계를 바꿔, AI가 확신이 낮은 부분은 스스로 "이 부분은 확인이 필요합니다"라고 표시하게 했다. 정확도는 그대로였지만 사용률은 올라갔다. 사람은 틀리는 도구가 아니라, 자기가 틀릴 때를 모르는 도구를 싫어한다.

05가장 강한 자동화는 사람의 판단을 키운다

자동화의 목표를 '사람을 빼는 것'으로 잡으면, 단기 효율은 오르지만 조직의 역량은 줄어든다. 반대로 잘 설계된 자동화는 사람이 더 높은 판단에 집중하도록 시간을 돌려준다.

컨설팅을 하며 본 가장 좋은 사례는, 반복 보고서 작성을 자동화한 뒤 그 시간을 '보고서를 읽고 의사결정하는 회의'에 재투자한 팀이었다. 그들은 도구로 사람을 대체하지 않았다. 사람을 더 사람다운 일로 밀어 올렸다.

06현실에서 이것이 어떻게 작동하는가

새 AI 도구를 익히기 전에, 자신이 가장 많은 시간을 쓰는 반복 작업 하나를 종이에 적어보라. 도구를 찾는 일은 그다음이다. 문제를 먼저 정의한 사람만이 도구를 제대로 쓴다.

마케터라면 콘텐츠 자동화를 도입할 때 '완성본 생성'이 아니라 '초안 다양화'를 목표로 잡아라. 당신이 고를 여지가 남아 있을 때, 그 도구는 위협이 아니라 조수가 된다.

창업가라면 AI를 비용 절감 수단으로만 보면, 결국 경쟁사도 같은 도구를 쓰는 순간 차별점이 사라진다. 도구가 아니라, 그 도구를 누구의 어떤 경험을 위해 쓰는지가 해자가 된다.

정리하며기술의 끝에는 늘 사람이 있다

모델을 고르는 회의가 길어질 때, 솔루션 비교표가 복잡해질 때, 우리는 종종 그 사실을 잊는다. 그러나 도구를 켜는 것도, 결과를 믿는 것도, 끝내 책임을 지는 것도 사람이다.

오늘 당장 실행할 한 가지. 지금 도입했거나 도입하려는 AI 도구를 하나 떠올려라. 그리고 그것을 매일 써야 할 사람 한 명을 구체적으로 그려라. 이름, 직무, 가장 바쁜 시간, 가장 귀찮아하는 작업까지. 그 사람의 하루 안에 도구가 자연스럽게 얹히지 않는다면, 문제는 모델이 아니라 설계다.

거창한 개념의 진입 장벽을 걷어내면, 그 안에는 언제나 일하는 사람 한 명이 있다.

테슬라 전 AI 책임자 안드레이 카파시의 최근 인터뷰 여러 편을 엮었습니다. 소프트웨어 3.0, 들쭉날쭉한 지능, 유령이라는 비유, 바이브 코딩과 에이전틱 엔지니어링, 채용 방식의 전환, 싱킹과 이해의 구분, 오토 리서치, 그리고 지능이라는 기적까지 — 여덟 가지 통찰을 비전공자 어휘로 옮깁니다.

안드레이 카파시라는 이름을 처음 듣는 분도 계실 겁니다. 슬로바키아에서 태어나 캐나다에서 자랐고, 스탠퍼드에서 컴퓨터 비전으로 박사를 받았고, 오픈AI 초기 멤버로 GPT-2를 만들었고, 테슬라로 건너가 오토파일럿의 AI를 총괄했고, 다시 오픈AI로 돌아갔다가 2024년에 독립해 자신의 AI 교육 회사를 세운 사람입니다. AI를 직접 만들어 본 경험과, 그것을 누구에게나 알아듣게 설명하는 언어 감각을 동시에 가진 드문 사람이라고 할 수 있습니다. 최근 한 달 사이에 여러 편의 인터뷰와 강연이 쏟아졌는데, 거기서 반복적으로 등장하는 생각들이 눈에 들어왔습니다. 비전공자가 읽어도 남는 것이 있는 통찰이라 판단해 정리합니다.

012023년 12월, AI 코딩 능력이 급변했다

카파시는 AI 코딩 능력에 뚜렷한 분기점이 있었다고 말합니다. 2023년 12월입니다. 그 이전에는 AI가 생성한 코드를 사람이 직접 수정해야 하는 경우가 많았습니다. 코드의 70퍼센트를 AI가 쓰면 나머지 30퍼센트를 사람이 고치는 식이었습니다. 그런데 12월을 기점으로 AI가 완벽한 코드 뭉치를 통째로 생성하기 시작했고, 수정할 필요가 거의 사라졌습니다. 카파시 본인의 표현을 빌리면, 코드를 마지막으로 직접 수정한 게 언제인지 기억이 안 날 정도라고 합니다.

단순히 자동완성이 좋아진 수준이 아닙니다. 그 시점부터 AI는 리서치, 계획 수립, 코드 작성, 테스트, 디버깅이라는 일련의 과정을 하나의 일관된 흐름으로 처리하는 에이전트적 워크플로우가 가능해졌습니다. AI가 단순한 도우미에서 자율적인 작업 수행자로 올라선 겁니다.

이 이야기를 꺼내는 이유가 있습니다. 카파시는 2022년 ChatGPT 수준에서 AI 코딩을 경험하고 "별로"라고 결론 내린 사람들이 아직 많다고 봅니다. 그 결론은 2023년 12월 이전의 판단이고, 그 이후에 AI 코딩 능력이 근본적으로 달라졌으니 다시 확인해 봐야 한다는 것입니다.

02소프트웨어 3.0 — 프롬프트가 프로그래밍이 된다

카파시는 소프트웨어의 역사를 세 겹으로 나눕니다. 소프트웨어 1.0은 사람이 직접 규칙과 코드를 작성하는 전통적인 프로그래밍입니다. OS별 환경에 맞춰 복잡한 배시 스크립트를 짜는 것이 여기에 해당합니다. 소프트웨어 2.0은 데이터셋을 만들고 모델 아키텍처를 설계해서 신경망을 훈련시키는 것 자체가 프로그래밍이 되는 방식입니다. 사람이 코드를 일일이 짜는 대신, 방대한 데이터를 통해 신경망이 스스로 가중치를 학습합니다.

핵심은 세 번째입니다. 소프트웨어 3.0에서는 LLM 자체가 하나의 거대한 컴퓨터가 되고, 프롬프트를 작성하는 것이 곧 프로그래밍이 됩니다. 컨텍스트 윈도우에 무엇을 넣느냐가 이 거대한 컴퓨터를 조정하는 핵심 레버입니다.

그는 두 가지 사례를 듭니다. 첫째, OpenClaw 설치. OS별로 다른 복잡한 스크립트를 짜는 대신, 설치 안내 텍스트를 에이전트에 붙여 넣으면 AI가 현재 환경을 파악하고 스스로 디버깅하며 설치를 완료합니다. 둘째, 메뉴젠이라는 앱. 식당 메뉴판 사진을 찍으면 OCR로 항목을 추출하고 이미지 생성기로 음식 사진을 만들어 보여주는 앱인데, 이걸 만들기 위해 여러 API를 연동하고 후처리 코드를 짜느라 상당한 작업이 필요했습니다. 소프트웨어 3.0 방식으로는 메뉴 사진을 AI에 넘기면서 "음식 사진을 위에 얹어줘" 한 줄이면 끝납니다. 앱 자체가 불필요해집니다. 코드가 사라진 자리에 신경망이 직접 들어가는 겁니다.

소프트웨어 3.0은 기존 패러다임의 속도 향상이 아니라, 이전에는 불가능했던 것이 가능해진 것이다. 새로운 앱을 기획할 때 가장 먼저 던져야 할 질문이 있다. "이 앱이 신경망 한 번 호출로 되는 것은 아닌가?"

더 먼 미래에 대해서도 그림을 그립니다. 카파시는 이것을 신경 컴퓨터라 부릅니다. 극단적으로는 기기가 카메라와 마이크에서 들어오는 원시 신호를 신경망에 직접 넣고, 화면에 보여줄 UI까지도 그 순간에 디퓨전으로 렌더링하는 세계를 상상합니다. 1950~60년대에는 컴퓨터가 계산기형이 될지 신경망형이 될지 불분명했으나 결국 계산기 경로를 택했고, 현재 신경망은 계산기형 컴퓨터 위에서 가상화되어 돌아가고 있습니다. 카파시는 이 관계가 뒤집힐 수 있다고 봅니다. 신경망이 호스트 프로세스가 되고, CPU는 코프로세서로 격하되는 구조입니다. 물론 한꺼번에 일어날 변화는 아닙니다. 하지만 지금 짜는 코드의 상당 부분이 5년에서 10년 안에 신경망으로 흡수될 수 있다는 것이 그의 판단입니다.

03들쭉날쭉한 지능 — 수학과 코딩은 잘하는데 상식은 틀린다

카파시가 반복적으로 강조하는 개념이 있습니다. 들쭉날쭉한 지능, 영어로는 Jagged Intelligence. AI가 어떤 영역에서는 인간 천재 수준의 능력을 보여주다가, 바로 옆 영역에서는 초등학생도 안 할 실수를 저지르는 현상입니다.

왜 이런 일이 벌어지는지를 그는 훈련 방식으로 설명합니다. LLM은 강화 학습 환경에서 답이 맞으면 보상을 주고 틀리면 감점하는 방식으로 훈련됩니다. 그래서 답이 맞는지 채점할 수 있는 영역에서 강력한 성능을 발휘합니다. 수학은 답이 정해져 있으니 채점이 됩니다. 코딩도 컴파일 여부, 테스트 통과 여부로 채점이 됩니다. 문제는 채점이 안 되는 영역입니다.

황당한 사례들이 있습니다. 과거 GPT는 'strawberry'에 'r'이 몇 개 있는지 세지 못했습니다. 10만 줄짜리 코드를 리팩토링하고 제로데이 보안 취약점을 찾아내는 AI가, 50미터 거리의 드라이브스루 세차장에 "걸어서 가세요"라고 답합니다. ChatGPT에게 농담을 해달라고 하면 5년 전과 똑같은 농담 서너 개를 돌려쓰고, 아무리 다른 농담을 요청해도 레퍼토리가 늘지 않습니다. 농담의 재미를 자동으로 채점할 방법이 없으니, 강화 학습 환경 바깥에 놓인 영역인 겁니다.

AI의 능력은 훈련 데이터에 무엇을 넣고 어떤 강화 학습 환경을 만드느냐에 따라 크게 좌우됩니다. 예를 들어 GPT-3.5에서 GPT-4로 갈 때 체스 능력이 눈에 띄게 향상된 것은 체스 데이터가 프리트레이닝에 대량으로 추가되었기 때문입니다. 모델이 "똑똑해져서"가 아니라 데이터가 들어가서 그렇습니다. 따라서 AI 모델에는 매뉴얼이 없습니다. 사용자가 직접 탐험해서 이 AI가 어떤 회로 안에 들어와 있는지, 어디서 잘하고 어디서 못 하는지를 알아내야 합니다.

04AI는 동물이 아니라 유령이다

들쭉날쭉한 지능 이야기와 이어지는 비유가 있습니다. 카파시는 AI를 동물에 비유하는 습관을 버려야 한다고 말합니다. 우리가 흔히 생각하는 동물 지능 — 강아지, 고양이, 사람 — 은 진화의 산물입니다. 수억 년에 걸쳐 생존 본능, 호기심, 재미를 느끼는 능력이 DNA에 새겨진 존재들입니다. LLM은 그런 것이 전혀 없습니다. 진화의 산물이 아니라 데이터와 보상 함수로 빚어진 통계적 시뮬레이션입니다.

우리는 동물을 만드는 게 아닙니다. 유령 혹은 정령이라고 불러야 할 존재들을 만들고 있는 겁니다. 안드레이 카파시

동물은 생존 본능을 갖고 태어나지만, AI 유령들은 아무런 본능도 없는 백지 상태에서 시작합니다. 인터넷이라는 거대한 디지털 공간에 인간이 남긴 희미한 흔적들을 모방해서 훈련된 존재입니다. 그래서 AI에게 소리를 지르거나 사정해도 결과가 나아지지 않습니다. "제발 잘 좀 해줘"라고 쓴다고 정확도가 올라가지 않고, "화가 난다"고 쓴다고 주눅 들지 않습니다. 감정적 반응에 영향을 받는 존재가 아니기 때문입니다. 반면에 "하지 마"와 같은 명확한 금지 지시에는 잘 따르는 경향이 있다고 합니다.

이 구분을 받아들이면 AI를 다루는 태도가 달라집니다. 동물을 대하듯 감정으로 접근하는 대신, 어떤 회로가 작동하고 어떤 회로가 꺼져 있는지를 냉정하게 탐색하는 태도로 바뀝니다.

05바이브 코딩과 에이전틱 엔지니어링 — 누구나 만들 수 있게 되었지만, 잘 만드는 건 다른 문제다

카파시는 AI 시대의 코딩을 두 겹으로 나눕니다. 바이브 코딩과 에이전틱 엔지니어링입니다.

바이브 코딩은 모두를 위한 창작의 바닥을 높이는 것입니다. 코딩을 못 하던 사람도 AI에게 대략적인 느낌만 말해도 앱을 만들 수 있게 됩니다. 에이전틱 엔지니어링은 다릅니다. 기존 전문 소프트웨어의 품질 기준을 유지하면서 더 빠르게 개발하는 것을 목표로 합니다. 변덕스러운 AI 에이전트들을 통제하고, 보안 취약점 발생을 완벽하게 차단하고, 수많은 에이전트를 조율해서 기술의 천장을 높이는 것이 에이전틱 엔지니어의 역할입니다. 책임은 여전히 인간에게 있으며, 책임 있는 엔지니어링 절차를 따라야 합니다.

과거에는 10배의 생산성을 내는 '10배 엔지니어'라는 말이 있었는데, 카파시는 에이전트를 잘 다루는 사람이 1000배 엔지니어가 될 수 있다는 톤으로 이야기합니다.

채용 방식도 바뀌어야 한다고 봅니다. 대부분의 회사가 아직 에이전트 시대에 맞는 채용 방식을 리팩토링하지 못했다는 것이 그의 지적입니다. 알고리즘 문제 풀이 같은 옛날 패러다임의 퍼즐 풀기 인터뷰는 더 이상 유효하지 않습니다. 카파시가 제안하는 방식은 이렇습니다. 후보자에게 트위터 클론 같은 대규모 프로젝트를 안전하고 빠르게 구축하도록 시킵니다. 그 다음 구축된 시스템에 10개의 AI 에이전트를 공격수로 투입해서 해킹을 시도하게 하고, 이를 방어하는 능력을 평가합니다. 손으로 알고리즘을 푸는 능력보다, 에이전트와 협업해서 큰 시스템을 안전하게 빌드하는 능력이 중요해졌다는 뜻입니다.

평범한 사용자와 AI 네이티브 사용자의 격차도 커지고 있습니다. 과거에는 빔이나 VS 코드 단축키 활용 능력이 개발자의 생산성을 갈랐는데, 이제는 클로드 코드나 코덱스 같은 AI 도구의 활용 능력이 새로운 격차를 만들고 있습니다. AI 도구에서 최대한의 기능을 활용하고, 본인의 셋업에 투자하는 것이 차이를 만든다고 카파시는 강조합니다.

06싱킹은 외주할 수 있지만, 이해는 외주할 수 없다

카파시가 AI 시대의 인간 역할에 대해 가장 깊이 있는 이야기를 하는 부분입니다.

AI 에이전트를 그는 "기억력은 완벽하지만 취향과 센스는 제로인 강력한 인턴"에 비유합니다. 복잡한 라이브러리의 API 문법을 완벽하게 기억하지만, 효율적인 구조나 우아한 사용자 경험에 대한 판단력은 없습니다. 깐깐한 아키텍처 설계, 엄격한 감독, 디자인 감각, 논리 검증은 여전히 인간의 몫입니다. 인간이 상위 카테고리의 전체 감독을 맡고, 에이전트가 세부 사항을 채우는 구조가 되어야 합니다.

실제로 벌어진 사례가 있습니다. 메뉴젠이라는 앱의 결제 시스템을 AI 에이전트에게 맡겼더니, 결제 계정과 로그인 계정을 이메일 주소가 같다는 이유만으로 자동 연동해 버렸습니다. 보안상 위험한 실수입니다. AI는 논리적 고민 없이 표면적인 데이터만 엮는 경향을 보여줍니다. 올바른 뼈대를 잡고 논리를 검증하는 것은 인간만이 할 수 있습니다. 파이토치와 넘파이의 API 디테일은 AI가 기억할 수 있지만, 텐서의 스토리지 구조나 메모리 효율성 같은 시스템 모델에 대한 이해는 여전히 인간의 영역입니다.

그리고 여기서 카파시가 가장 중요한 구분을 제시합니다. 싱킹과 언더스탠딩의 차이입니다.

싱킹은 아웃소싱할 수 있지만, 언더스탠딩은 아웃소싱할 수 없다.

싱킹, 즉 사고는 정보를 분석하고 결론에 도달하는 처리 작업입니다. AI가 잘합니다. 언더스탠딩, 즉 이해는 정보가 뇌에 들어와서 이미 알고 있던 것들과 연결되고, 그 연결에서 깨달음이 생기는 과정입니다. 이것은 외주할 수 없습니다. AI가 아무리 기계적인 정보 처리를 대신해도, 무엇을 왜 만들고 있는지 그 본질을 이해하는 주체는 반드시 인간 자신이어야 합니다. 기술이 발전할수록 AI에게 올바른 지시를 내리기 위한 인간의 깊은 통찰력과 이해력이 전체 시스템의 질을 결정하는 가장 궁극적인 병목이 됩니다.

07AI가 스스로 진화하는 법 — 데이터 붕괴, 문화, 오토 리서치

카파시는 현재 LLM의 근본적인 한계를 두 갈래로 짚습니다.

첫째는 성찰의 부재입니다. 인간은 책을 읽을 때 단순히 정보를 받아들이는 것이 아니라, 읽으면서 동시에 성찰하고 되새김질하며 자기 안에서 새로운 생각을 합성합니다. 책이 지식을 나열한 설명서가 아니라 뇌를 자극해서 스스로 합성 데이터를 생성하는 프롬프트로 작동하는 겁니다. 현재 LLM에는 이 성찰과 통합 과정이 전무합니다. 실제로 생각을 하지 않습니다.

둘째는 데이터 붕괴 문제입니다. AI가 스스로 데이터를 생성해서 다시 훈련하면 모델 성능이 나빠집니다. 생성된 데이터는 겉보기엔 멀쩡해 보여도, 가능한 생각의 전체 공간에서 아주 좁은 영역만 차지하게 되어 다양성이 죽어버립니다. ChatGPT에게 농담을 해달라고 하면 고작 세 개 정도만 반복하는 것이 대표적 증상입니다. 인간은 풍요로운 다양성과 높은 엔트로피를 갖지만, AI는 그렇지 못합니다. 붕괴를 막으면서 인간 같은 엔트로피를 가진 합성 데이터를 만드는 방법을 찾는 것이 해결 과제입니다.

이 한계를 넘기 위해 카파시가 주목하는 방향이 세 가지 있습니다.

첫째, AI 간의 문화 형성입니다. 현재 LLM은 진정한 문화를 가지고 있지 않습니다. 미래에는 AI 에이전트들이 서로를 위해 책을 쓰고, 지식을 기록하고 공유하며, 집단적으로 지식 레퍼토리를 축적하는 문화가 형성될 수 있습니다. 단순히 혼자 배우는 것을 넘어, AI끼리 서로 영향을 주고받는 과정입니다.

둘째, 경쟁을 통한 자기 개선입니다. 알파고가 자기 자신과 끊임없이 대국하며 인간의 한계를 넘어선 것처럼, AI 간의 치열한 경쟁은 지능과 발전을 가속화하는 강력한 방법입니다. 현재 LLM에는 이 스스로 플레이하는 메커니즘이 없습니다. 미래에는 선생 LLM이 학생 LLM을 위해 점점 더 어려운 문제를 만들어 제공하는 자동 커리큘럼이 가능해질 것이라고 봅니다. 인간 데이터의 한계를 넘어서기 위한 필수적인 자기 개선 루프입니다.

셋째, 오토 리서치입니다. AI 에이전트의 능력을 AI 자기 자신에게 적용해서 스스로를 개선하게 만드는 방법입니다. 인간의 시간과 판단력이라는 병목을 시스템에서 제거하는 것이 목표입니다. 인간이 연구를 위한 판만 깔아주고 목표를 알려준 뒤 시작 버튼을 누르면, AI가 스스로 수만 가지 실험을 하며 더 나은 방법을 찾아냅니다. 카파시는 직접 실험한 결과를 밝힙니다. 하룻밤 만에 자신의 20년 경력으로도 놓쳤던 코드 최적화 방법을 AI가 찾아냈다고 합니다.

더 나아가 분산형 오토 리서치도 이야기합니다. 인터넷상의 신뢰할 수 없는 작업자 풀을 활용하는 방식입니다. SETI@Home이나 Folding@Home처럼, 비용이 많이 드는 생성 작업을 분산하고 저렴한 검증 작업으로 신뢰성을 확보하는 구조입니다. 궁극적으로 인터넷상의 에이전트 무리가 LLM을 개선하고 프론티어 연구소를 능가할 수도 있으며, 이런 시스템에서는 컴퓨팅 자원 자체가 부의 척도가 될 수 있다고 봅니다.

08고등 지능은 왜 희귀한가 — 박테리아 20억 년, 까마귀의 한계, 인간의 손과 불

마지막 풍경은 가장 넓은 시야에서 바라본 이야기입니다. 카파시는 고등 지능의 탄생이 매우 희귀한 사건이라고 생각합니다. 닉 레인의 분석을 인용하면서, 지구와 비슷한 환경의 행성 1000개가 있다면 대부분은 박테리아 같은 초기 생명체만 존재할 것이라고 말합니다. 단순 세포에서 복잡한 진핵 생물로 넘어가는 것 자체가 확률적으로 매우 어려운 일이었습니다.

박테리아는 20억 년 동안 존재했지만 아무 일도 없었습니다. 생화학적 다양성은 있었으나 동물로 성장하지 못하는 거대한 병목 현상이 있었습니다. 다세포 동물이 출현한 것도 지구 역사에서 짧은 기간이지만, 단순한 동물을 넘어 문화를 만들고 지식을 창조해 다음 세대로 축적하는 존재가 나타난 것은 여전히 놀랍습니다.

흥미로운 것은 지능이 한 번만 출현한 것이 아니라는 점입니다. 까마귀 같은 조류도 지능을 가지고 있으며, 뇌 구조가 인간과 뚜렷하게 다릅니다. 지능이 진화 과정에서 여러 번 독립적으로 출현했을 가능성을 시사합니다. 하지만 새들은 뇌를 키우면 비행에 불리해지는 물리적 한계에 부딪혔습니다. 하드웨어의 부재가 병목이었습니다.

인간의 지능 폭발에는 두 가지 우연이 겹쳤습니다. 도구 사용에 유리한 '손'이라는 하드웨어, 그리고 불을 이용한 소화의 외주화. 불로 음식을 익히면서 소화에 들어가는 에너지를 아끼고 그 에너지를 뇌로 보낼 수 있었습니다. 돌고래는 똑똑하지만 도구가 없어 문명을 만들기 어렵고, 물속에서는 불을 피우기 어려워 화학적으로 할 수 있는 일의 범위가 육지보다 좁습니다.

카파시는 이 모든 이야기를 한 문장으로 수렴시킵니다. 지능을 택한 진화 자체가 기적이며, 우리는 지금 그 기적의 두 번째 판을 인공적으로 만들고 있는 것이라고.

정리하며여덟 가지 통찰을 관통하는 하나의 메시지

카파시의 인터뷰를 관통하는 메시지는 결국 하나입니다. AI 시대에 가장 중요한 것은 도구를 잘 쓰는 기술이 아니라, 무엇을 왜 만들고 있는지에 대한 깊은 이해라는 것.

코드가 사라지는 자리에 신경망이 들어오고 있습니다. 하지만 그 신경망은 한쪽에서는 천재이면서 다른 쪽에서는 어처구니없는, 들쭉날쭉한 지능을 가지고 있습니다. 동물처럼 감정으로 다루면 안 되고, 회로를 냉정하게 탐색해야 합니다. 누구나 만들 수 있는 시대가 왔지만, 잘 만드는 것은 여전히 다른 문제이고, 채용 방식까지 이 변화를 따라가야 합니다. 정보 처리는 외주할 수 있지만 이해는 외주할 수 없으며, 기술이 강해질수록 오히려 인간의 이해력이 전체 시스템의 질을 결정하는 병목이 됩니다. AI가 스스로를 개선하는 오토 리서치가 현실이 되고 있고, 그 너머에서는 인류가 지능이라는 기적을 인공적으로 재현하려는 시도가 진행 중입니다.

AI가 검색 안에 들어 있던 시기에서, 검색 자체가 AI인 시기로. 노트북을 닫아도 24시간 일하는 비서까지 — 구글 I/O 2026 47분을 비개발자가 회사에서 그대로 옮길 수 있는 표현으로 정리합니다.

구글의 연례 개발자 행사 Google I/O 2026 키노트가 마무리됐습니다. 한 해 동안 가장 많은 새 용어가 쏟아진 자리였습니다. Gemini Omni, Gemini 3.5 Flash, Gemini Spark, Anti-Gravity, Universal Commerce Protocol, Agent Payments Protocol, Daily Brief, Google Pix, Google Flow, Gemini for Science. 영문 줄임말과 코드명이 빽빽이 박혀 있어서, 코드를 직접 짜지 않는 분들에게는 한 번 흘려듣고 끝나기 쉬운 발표였을 것입니다.

그래서 이번 글에서는 키노트 흐름을 여섯 개 화두로 추려, 각 화두에서 등장한 핵심 용어를 짧게 정의하고 그 의미를 평어로 풀어내겠습니다. 회사에서 임원이나 동료에게 "이번 구글 발표는 우리에게 뭘 바꾸느냐"고 질문받았을 때 그대로 옮겨 쓸 수 있는 표현을 찾는 것이 목적입니다. 끝에는 작년 I/O와 무엇이 달라졌는지 차별화 포인트만 모은 편집자 노트를 따로 붙였습니다.

01 / 큰 그림토큰과 사용자 숫자가 말하는 것

키노트는 구글이 처리하는 AI 사용량 숫자에서 시작했습니다. 핵심 메시지는 한 문장으로 요약됩니다. AI는 더 이상 "도입할까 말까"의 단계가 아니라, "어디까지 흘러가는가"의 단계라는 것입니다. 발표자가 같은 자리에서 1년 전 짚었던 숫자와 지금의 숫자를 나란히 펼쳐 놓았기 때문에 비교가 또렷합니다.

제품 단의 숫자도 함께 공개됐습니다. 구글이 보유한, 사용자가 10억 명을 넘은 제품은 13개이며, 그중 5개는 30억 명을 넘습니다. 새 모델은 그 모든 제품 안에 들어가고 있습니다.

특히 눈에 띄는 세 가지가 있습니다. 첫째, 검색 결과 위에 답을 얹어 주는 AI Overviews가 월간 25억 명을 넘었습니다. 둘째, 작년 I/O에서 베타로 공개됐던 AI 모드(AI Mode)는 출시 1년 만에 월간 10억 명을 돌파해, 구글 발표자가 "구글 검색 역사상 가장 큰 업그레이드"라고 부른 자리에 올랐습니다. 셋째, Gemini 앱은 작년 I/O 당시 월간 4억 명 수준에서 9억 명 이상으로 두 배 이상 늘었습니다.

1년 전 키노트는 "AI를 어디에 끼울까"가 화두였고, 올해는 "AI가 이미 들어와 있는 자리에서 무엇을 할까"가 화두였습니다. 사용자 숫자가 그 변화를 그대로 보여 줍니다.

인프라 측 발표도 짧게 짚었습니다. 구글은 자체 AI 칩(TPU)을 100만 개 이상 묶어 학습 자원을 분산시키는 Jackson Pathways라는 내부 시스템을 공개했습니다. 비개발자 표현으로 옮기면, "전 세계에 흩어진 100만 대의 슈퍼컴퓨터 부품을 한 덩어리처럼 다루는 배차 시스템"입니다. 새 모델이 더 크고 더 빨라질 수 있는 토대가 된다는 의미입니다.

02 / 모델 층Gemini Omni — 모든 입력에서 모든 출력으로

두 번째 블록은 새 모델 발표였습니다. 발표 순서는 Omni가 먼저, 그다음이 3.5 Flash, 마지막이 다음 달 공개될 3.5 Pro의 짧은 예고였습니다.

같은 자리에서 짧게 짚어 둔 안전 장치는 SynthID입니다. AI가 만들어 낸 이미지·영상·음성에 사람 눈에는 보이지 않는 워터마크를 새겨 두는 기술인데, 출시 이후 누적 1,000억 개 이상의 콘텐츠에 적용됐다고 합니다. 이번 발표에서는 SynthID와 콘텐츠 자격 증명 확인 기능을 구글 검색과 크롬 브라우저로 확장한다고 밝혔습니다. 사용자가 어떤 이미지를 마주쳤을 때 "이게 AI가 만든 것이냐"를 그 자리에서 확인할 수 있게 된다는 의미입니다. OpenAI, 카카오, ElevenLabs 같은 외부 회사들도 SynthID를 채택하기 시작했다는 점이 함께 소개됐습니다.

3.5 Flash가 가장 눈에 띄는 자리에 선 시연은 Anti-Gravity라는 개발 환경 위에서였습니다.

03 / 도구 층Anti-Gravity와 12배 빠른 에이전트 팀워크

Anti-Gravity는 작년 I/O에서 처음 공개된 구글의 에이전트 기반 개발 환경입니다. 이번 키노트에서 발표자가 직접 던진 도전 과제는 만만치 않았습니다. 운영체제를 처음부터 만들어 봐 달라는 한 줄짜리 지시였습니다.

여기에서 발표자가 한 번 더 강조한 대목이 있습니다. 만들어진 OS에서 둠(Doom) 게임을 돌리려고 보니 영상 출력과 키보드 입력을 처리할 드라이버가 빠져 있었습니다. Anti-Gravity는 이 문제를 사람 손을 빌리지 않고, 직접 자료를 찾아가며 100줄이 넘는 드라이버 코드를 새로 작성해 끼워 넣었습니다. 발표자는 이 장면을 가리키며 "Flash가 단순히 빠른 모델이 아니라, 빨라진 만큼 더 많이 시도하고 더 많이 실패하면서 더 빨리 좋아진다는 점이 핵심"이라고 표현했습니다. 같은 환경에서 Anti-Gravity 안의 Flash는 직전 대비 4배가 아니라 12배 빠르게 최적화됐다는 숫자가 함께 공개됐습니다.

작년까지 한 줄의 지시는 한 번의 응답으로 닫혔습니다. 올해는 한 줄의 지시가 93개의 하위 에이전트로 분해되어, 12시간 동안 깨어 있는 채로 운영체제를 만듭니다.

Gemini 3.5 Pro는 키노트 시점에 구글이 내부에서 사용 중이며, 다음 달 공개 예정이라고만 짧게 짚었습니다. Flash를 먼저 푼 뒤 Pro를 다음 달에 푸는 순서는, 작년처럼 큰 모델을 헤드라인에 세우던 발표 방식과 가장 다른 지점입니다.

04 / 에이전트 층Gemini Spark — 노트북을 닫아도 일하는 비서

이번 키노트에서 가장 길게 시연된 발표가 Gemini Spark입니다. 이름에서 짐작되는 인상과 다르게, 더 똑똑한 챗봇이 아닙니다. 발표 자료의 표현을 그대로 옮기면 "사용자의 디지털 생활을 탐색하고, 지시에 따라 행동하는 개인 AI 에이전트"입니다.

그리고 사용자 입장에서 가장 중요한 두 가지 질문 — "어디에서 쓰느냐"와 "누가 먼저 받느냐"를 짚어 둘 필요가 있습니다.

먼저 어디에서 쓰는가입니다. Spark는 구글 AI 스튜디오 같은 개발자 도구 안에 들어가지 않습니다. 일반 사용자가 매일 켜는 Gemini 앱(웹·모바일) 안에 들어옵니다. 일하는 자리는 같고, 그 안에 백그라운드 에이전트 자리가 새로 생긴다고 이해하시면 정확합니다.

다음으로 누가 먼저 받는가입니다. 소비자용은 미국 지역의 Google AI Ultra 구독자를 대상으로 베타가 먼저 열리고, 여름 중 데스크톱 앱으로 확대됩니다. 업무용은 Gemini Enterprise 가입자와 구글 워크스페이스 사용자의 Gemini 앱에서 프리뷰 형태로 곧 제공된다는 일정이 발표됐습니다. 한국 사용자가 곧바로 받을 수 있는 것은 아니라는 점을 분명히 짚어 두는 것이 좋겠습니다.

Spark가 일을 받는 방식은 세 가지입니다.

한 줄로 묶으면, Spark는 Gemini 앱 안에서 구글 생태계와 외부 앱들을 엮어 내 비서처럼 부리는 백그라운드 자동화 에이전트입니다. 채팅창은 그대로 두되, 그 뒤에 24시간 깨어 있는 비서 한 명을 클라우드에 상주시켜 두는 것에 가깝습니다.

05 / 사용자 자리검색·쇼핑·창작이 에이전트의 자리가 되다

Spark가 새 자리를 만든다면, 같은 자리에서 기존 자리들도 다시 짜였습니다. 발표자가 가장 분명하게 짚은 표현이 인상적이었습니다. "AI가 검색 안에 있는 것이 아니라, 검색 자체가 AI가 된다."

같은 방향에서 시연된 또 하나의 변화는 맞춤형 도구 생성입니다. 사용자가 "이번 주말 계획 좀 짜 줘"라고만 입력하면, 검색이 선제적으로 "주말 계획기 도구를 만들어 볼까요?"라고 제안하고, 사용자가 지메일·포토·캘린더를 안전하게 연결하면 식당 예약·지도·일정이 한 화면 대시보드로 깔립니다. 검색 결과가 페이지가 아니라 도구로 떨어진다는 의미입니다.

쇼핑 자리는 한 단계 더 나아갔습니다. 구글에서 매일 발생하는 쇼핑 관련 검색이 10억 건을 넘는다는 숫자가 함께 공개됐는데, 이 자리에 세 가지 새 표준이 깔립니다.

창작 자리도 함께 짚어 둘 만합니다. 워크스페이스 안에는 Google Pix라는 새 이미지 생성·편집 도구가 들어왔습니다. 마우스를 올려 클릭만으로 요소를 지우고, 크기를 조정하고, 글씨를 바꾸고, 몇 번의 클릭으로 전체를 다른 언어로 옮길 수 있습니다. 작년 I/O에서 처음 공개됐던 Google Flow도 크게 진화했습니다. 작년에는 한 번에 하나의 프롬프트만 받았는데, 올해는 한 장의 이미지를 분석해 가장 매력적인 카메라 각도를 직접 찾아내고, 그 안에서 16개의 서로 다른 영상을 동시에 만들어 냅니다.

일상 자리에서 가장 작지만 또렷한 변화는 Daily Brief입니다. 아침마다 메일함·캘린더·작업 목록을 묶어 그날 중요한 것만 추려 알려 주는 하루치 요약 카드입니다. Spark가 던져 둔 작업의 진행 상태도 같은 자리에서 확인됩니다.

06 / 글라스·과학귀로 듣는 비서, 그리고 닫는 말

키노트 마지막 블록은 두 가지 자리로 나뉘었습니다. 한쪽은 몸에 가까이 오는 자리, 다른 한쪽은 가장 먼 자리입니다.

몸에 가까이 오는 자리는 오디오 글라스(audio glasses)입니다. 올 가을 출시 예정이며, 삼성이 하드웨어를 만들고, 안경 디자인은 젠틀몬스터와 워비파커가 맡았습니다. 이번 글라스는 시야에 정보를 띄우는 방향이 아닙니다. 화면이 없습니다. Gemini가 하루 종일 옆에 있다가, 필요한 순간에만 귀에 비공개로 음성을 전달합니다.

시연이 인상적이었습니다. 사용자가 "DoorDash로 동네 카페 라떼 한 잔 시켜 줘"라고 말하자, Gemini가 그 자리에서 DoorDash 앱을 직접 열고, 화면을 순서대로 눌러 가며 옵션을 골라 주문을 끝냈습니다. 사용자는 한 번도 화면을 보지 않습니다. 글라스가 한 일은 "사용자의 부탁을 자기 손으로 옮긴 것"뿐입니다. 시각 디스플레이가 사라진 자리에 음성과 손이 들어왔다는 표현이 정확합니다.

가장 먼 자리는 Gemini for Science입니다. 새로 발표된 연구실 프로토타입이 시연됐는데, 새로 공개된 논문을 자동으로 읽어 들이고, 연구 목표를 실행 가능한 코드로 옮기고, 새 가설까지 생성하는 일상적인 과학 작업의 흐름이 한 화면에서 굴러갔습니다. 발표자는 이 자리를 가리키며 "AI가 인류의 발견을 가속하는 궁극의 도구가 될 것"이라고 닫았고, 그 발언은 키노트의 마지막 슬라이드 — "인간의 창의성을 증폭시키는 도구로서의 AI" — 로 이어졌습니다.

글라스가 사라지는 디스플레이라면, Gemini for Science는 사라지지 않는 도전이고, Spark는 사라지지 않는 비서입니다. 세 자리가 한 방향을 가리킵니다 — AI가 도구가 아니라 자리로 바뀌는 1년이었습니다.

키노트 전체를 한 줄로 압축하면 이렇습니다. 1년 전 구글 I/O가 "AI를 어디에 끼울까"의 발표였다면, 2026 I/O는 "AI가 이미 들어와 있는 자리에서 어떤 일을 자리 그 자체로 만들까"의 발표였습니다. 검색은 페이지에서 도구로, 쇼핑은 카트에서 프로토콜로, 비서는 채팅 세션에서 클라우드 VM으로 옮겨갔습니다.

까만 창에 명령 한 줄을 쳐 본 적 없는 분을 가정하고 다시 쓴, Nous Research Hermes Agent 입문 가이드. 설치부터 첫 대화, 그리고 자동화로 키워 가는 다섯 갈래까지.

요즘 ChatGPT, Claude, Gemini 같은 AI 비서를 안 써본 사람은 거의 없다. 다들 웹브라우저에 들어가 입력창에 질문을 적는 방식이다. Hermes Agent는 그런 비서 중에서도 조금 다른 자리를 차지한다. 웹브라우저가 아니라 내 컴퓨터 안에서 직접 살면서, 내 파일을 들여다보고 내 폴더를 정리하고 내 메신저로 보고서를 보내주는 비서다.

Nous Research라는 미국 AI 회사가 만들었고, 무료로 공개되어 있다. 가장 큰 특징은 “쓸수록 자란다”는 점이다. 이번에 한 번 가르쳐 두면 다음번에는 알아서 같은 방식으로 일을 해낸다. 어제 나눈 대화도 기억하고, 내가 어떤 사람인지 점점 더 정확히 파악해 간다. 라이선스가 MIT라 회사 안에서도 자유롭게 쓸 수 있고, 2026년 5월 7일 공개된 최신 버전은 v0.13.0이다.

이 글은 “컴퓨터 화면에서 까만 창에 글자를 쳐 본 적이 한 번도 없다”는 분을 가정하고 썼다. 그러니 이상한 곳에서 막히면 그건 글이 친절하지 못한 탓이라고 보고 다음 단락으로 넘어가도 된다.

01 / 시작 전에먼저 ‘터미널’이 무엇인지부터

Hermes는 사진이나 메뉴가 떠 있는 보통의 프로그램과 다르다. 우리가 마우스로 클릭해 쓰는 카톡, 한글, 크롬 같은 것들이 아니라, 까만 창에 글자만 떠 있고 거기에 우리가 글을 적어 말을 거는 방식의 프로그램이다.

이 까만 창을 통틀어 “터미널”이라고 부른다. 윈도우에는 “Windows Terminal”이라는 이름의 앱이 들어 있고, 맥에는 “터미널”이라는 같은 이름의 앱이 기본으로 깔려 있다. 시작 메뉴나 런치패드에서 그 이름으로 검색하면 바로 나온다. 그 안에 한 줄을 적고 엔터를 누르면, 컴퓨터가 그 줄을 “명령”으로 받아들여 시키는 일을 한다. 이걸 “명령어를 친다”라고 한다. 처음에는 영화 속 해커 같지만, 사실은 검색창에 글을 적어 엔터를 누르는 것과 다르지 않다.

02 / 운영체제 준비맥은 그대로, 윈도우는 한 번만

Hermes가 잘 동작하는 운영체제는 맥(macOS), 리눅스, 그리고 윈도우 안에서 리눅스를 빌려 쓰는 “WSL2”라는 환경이다. 맥을 쓰는 분이라면 별다른 준비 없이 바로 다음 단계로 가도 된다.

윈도우를 쓰는 분이라면 한 번만 WSL2라는 기능을 켜 두는 작업이 필요하다. 윈도우 11에서는 시작 메뉴에서 “PowerShell”을 찾아 마우스 오른쪽 버튼으로 “관리자 권한으로 실행”을 누른 뒤 wsl --install이라는 한 줄을 적고 엔터를 친다. 자동으로 설치된다. 한 번 재부팅하고 나면 시작 메뉴에 “Ubuntu”라는 새 앱이 생긴다. 이 우분투 창이 앞으로 우리가 Hermes에게 말을 거는 까만 창이 된다. 윈도우 자체에서 바로 돌리는 버전도 있긴 하지만 아직 시험 단계라, 처음 써보는 분에게는 우분투 쪽을 권한다.

03 / 설치한 줄 복사·붙여넣기로 끝난다

이제 진짜 설치다. Hermes는 “설치 스크립트”라는 것을 제공한다. 스크립트라는 말이 어렵게 들리지만, “여러 단계의 설치 작업을 한 줄로 묶어 놓은 자동화 묶음”이라고 보면 된다. 우리는 그 한 줄만 복사해 까만 창에 붙여 넣으면, 나머지는 컴퓨터가 알아서 한다. 맥, 리눅스, 우분투(WSL2) 창에서는 다음 한 줄을 그대로 붙여넣고 엔터를 누른다.

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

화면에 글자들이 빠르게 흘러간다. 무언가 다운받고, 압축을 풀고, 설정을 잡는 과정이다. 길어야 몇 분이면 끝난다. 끝나면 마지막에 “이제 다음 줄을 한 번 더 쳐 달라”는 안내가 뜨는데, 보통은 다음 줄이다.

source ~/.bashrc

이 줄의 의미는 “방금 새로 깔린 hermes라는 명령을 컴퓨터에게 알려줘라”에 가깝다. 안 치면 다음에 hermes라고 적었을 때 “그런 명령 모릅니다”라는 말을 듣게 된다. 여기까지 했으면 Hermes 본체는 깔린 셈이다.

04 / 두뇌 연결어느 회사 AI를 빌려 쓸지 정한다

다음으로 할 일은 “이 비서가 어느 회사의 두뇌를 빌려 쓸지” 정하는 것이다. ChatGPT는 OpenAI가 만든 두뇌고, Claude는 Anthropic, Gemini는 구글이 만든 두뇌다. Hermes는 자체 두뇌가 없고, 위와 같은 외부 두뇌 중 하나를 빌려와 답을 만들어 낸다. 그러니 어느 회사 계정을 쓸지 한 번은 정해줘야 한다. 까만 창에 다음 줄을 친다.

hermes model

치면 메뉴가 뜨고, 위아래 화살표로 회사를 고른 뒤 엔터를 누른다. Anthropic의 Claude를 쓰겠다고 골랐다면 그다음에는 Anthropic 사이트에서 발급받은 “API 키”를 적어 달라는 화면이 나온다. API 키라는 건 그 회사가 “이 사람은 우리 두뇌를 써도 됩니다”라고 인증해 주는 길고 복잡한 비밀번호 같은 것이다. 미리 만들어 두지 않았다면 각 회사 사이트에 접속해 회원가입을 하고 “API key” 메뉴에서 발급받으면 된다.

한국 사용자가 가장 무난하게 시작할 수 있는 두 곳을 굳이 꼽자면 Anthropic의 Claude와 OpenRouter다. 후자는 한 계정으로 여러 회사 모델을 한꺼번에 쓸 수 있어 편하다. 회사 안에서 외부 인터넷을 못 쓰는 분이라면 “Custom Endpoint”라는 마지막 항목을 고르면, 회사 안에서 따로 돌리는 모델 서버 주소를 적어 그쪽으로 연결할 수도 있다.

05 / 첫 대화그냥 한국어로 말을 걸면 된다

준비가 끝나면 정말 끝이다. 이제 까만 창에 한 단어만 친다.

hermes

화면이 바뀌면서 입력창이 뜬다. 여기서부터는 ChatGPT 쓰던 것과 똑같다. 한국어로 그냥 말을 걸면 된다.

내 다운로드 폴더에서 가장 큰 파일 다섯 개를 알려줘.

Hermes는 답을 글로 적어줄 뿐 아니라, 필요하면 진짜로 내 컴퓨터 폴더를 열어 살펴보고 결과를 가져온다. 이게 일반 챗봇과 가장 큰 차이다. 처음에는 무서울 수 있어 “정리해줘”까지 시키지 말고, 일단 “알려줘”, “보여줘” 정도로 며칠 친해지는 것을 추천한다.

대화를 하다 보면 가끔 메시지 맨 앞에 빗금(/) 기호를 적는 특별한 명령들이 등장한다. 이걸 “슬래시 명령”이라고 부른다. 평범한 질문이 아니라 Hermes 자체에 내리는 지시다. /help는 쓸 수 있는 명령 전체 목록을, /tools는 지금 켜져 있는 기능들을, /model은 두뇌를 즉석에서 다른 회사로 바꾸는 메뉴를 띄워 준다. /save는 지금 나눈 대화를 파일로 저장한다.

메시지를 한 줄이 아니라 여러 줄로 길게 적고 싶을 때는 줄을 바꿀 자리에서 그냥 엔터를 누르면 메시지가 보내져 버리니, 대신 Shift 키를 누른 채로 엔터를 누른다. 그러면 줄만 바뀐다. 답이 엉뚱한 방향으로 가고 있으면 키보드의 Ctrl 키와 영문 C 키를 동시에 눌러 멈출 수 있다. 어제 하던 작업을 이어가고 싶다면 hermes 대신 hermes --continue라고 치면 마지막 대화가 그대로 이어진다.

06 / 막혔을 때의사한테 보내듯 doctor를 쓴다

쓰다 보면 어느 날 갑자기 답이 안 오거나, hermes를 쳤더니 “그런 명령 없습니다”라는 말이 나오는 일이 생긴다. 그럴 때 가장 먼저 칠 명령은 hermes doctor다. 의사가 진찰하듯 어디가 막혔는지 한 번에 검사해서, 어떤 곳을 손봐야 하는지 알려준다.

두뇌를 다른 회사로 바꾸고 싶으면 hermes model을 다시 치고, 처음부터 새로 잡고 싶으면 hermes setup을 친다. 새 버전이 나왔다는 안내가 보이면 hermes update 한 줄로 갱신된다. 어제 하던 대화가 어디 있는지 잘 모르겠을 땐 hermes sessions list를 치면 과거 대화 목록이 쭉 뜬다. 처음에는 이 다섯 줄만 외워 두면 충분하다.

07 / 자동화 활용그래서 실제로 뭘 시킬 수 있나

“쓸수록 자란다”는 말이 막연하게 들릴 수 있다. 그래서 처음 한 달 동안 실제로 시켜볼 만한 일들을 결이 다른 다섯 묶음으로 풀어 본다. 모두 이미 다른 분들이 같은 방식으로 굴리고 있는 일들이고, 어느 것 하나도 코드를 짤 줄 알아야 하는 일이 아니다. 한국어로 그냥 말로 부탁하면 된다.

책상 위 자료 정리

다운로드 폴더는 아무리 정리해도 며칠이면 다시 엉망이 된다. Hermes에게 “다운로드 폴더에 쌓인 파일들을 한 번 훑어보고, PDF는 ‘논문’ 폴더로, 강의자료(PPT, KEY)는 ‘강의자료’ 폴더로, 영수증으로 보이는 이미지는 ‘영수증’ 폴더로 옮겨줘. 잘 모르겠으면 옮기지 말고 목록으로만 보여줘”라고 부탁하면, 한 파일씩 열어 내용을 살펴보고 분류한다. 한 번 정해진 규칙은 자기 메모에 적어 두기 때문에, 다음번에 “지난번처럼 정리해줘” 한 마디면 같은 작업이 반복된다. 같은 결로 “지난주 받은 강의자료 30개의 표지에서 강의 제목과 강사명만 뽑아서 엑셀로 만들어줘” 같은 일도 한 번에 끝난다.

자동 모니터링

Hermes는 인터넷을 직접 들여다볼 수 있다. 그래서 “나라장터에 ‘AI 교육’이나 ‘바이브 코딩’ 같은 키워드가 들어간 새 공고가 뜨면 알려줘”, “과기정통부 보도자료 페이지를 매일 아침 9시에 확인하고 새로 올라온 게 있으면 제목과 한 줄 요약을 텔레그램으로 보내줘” 같은 부탁이 통한다. 한 번만 일러두면 매일 같은 시간에 알아서 돌아간다. 이메일을 살펴 “요청·문의가 들어온 메일만 골라 한 줄 요약과 함께 묶어서 보여줘”라고 하면 출근하자마자 오늘의 우선순위가 정리된 채 내 앞에 놓인다.

글쓰기 도우미

이건 ChatGPT와 비슷해 보이지만 결정적인 차이가 있다. Hermes는 내 컴퓨터 안의 파일과 과거 대화를 같이 본다. “지난달 강의 후기 다섯 개에서 공통적으로 나오는 칭찬과 아쉬움을 정리해서, 다음 강의 소개 카피 초안을 세 가지 톤으로 써줘”, “이 폴더 안의 회의록 12개를 다 읽고 이번 분기 협회 핵심 의사결정 다섯 개를 뽑아 임원회의용 한 장 보고서로 만들어줘” 같은 일을 시킬 수 있다. 매번 자료를 일일이 복사해 붙여 넣을 필요 없이, “이 폴더 안의 것들”이라고만 가리키면 된다.

메신저로 옮겨간 비서

hermes gateway setup으로 텔레그램이나 디스코드, 슬랙에 같은 비서를 붙여 두면, 외출 중에도 휴대폰에서 똑같이 일을 시킬 수 있다. “지금 노트북에 켜져 있는 한글 문서들 제목만 알려줘”, “책상 위 ‘이번주’ 폴더 안 PDF 제목들 한 줄로 요약해서 보내줘” 같은 부탁이 답으로 돌아온다. 출근길에 “오늘 저녁 7시에 강의 자료 마지막 페이지에 협회 로고와 연락처 한 줄 추가해 두라고 8시쯤 다시 알려줘” 식의 미래형 부탁도 가능하다.

정해진 시간 자동 실행

개발 쪽 용어로는 “크론”이라고 부르지만, Hermes에서는 그냥 “매주 금요일 오후 6시에”라는 말로 통한다. “매일 아침 7시에 오늘 일정과 어제 받은 미답신 이메일을 묶어 텔레그램으로 보내줘”, “매주 금요일 오후 6시에 한 주 동안 ‘바이브코딩’ 폴더 안에 새로 추가된 파일을 정리해 한 페이지 보고서로 만들어줘”, “매월 말일 23시에 협회 공식 메일함을 백업해줘”처럼 시켜두면, 그날부터는 잊고 살아도 정해진 시간에 알아서 결과물이 도착한다. 한 번 만들어 둔 자동 작업은 Hermes 안에서 언제든 켜고 끌 수 있어, 시즌이 끝나면 멈춰 두면 그만이다.

08 / 마무리한 번에 다 자동화하지 말 것

이 다섯 묶음을 가만 보면, 결국 Hermes는 “비서를 한 명 더 채용한 것”에 가깝다. 단순 검색은 ChatGPT도 잘하지만, “내 컴퓨터를 알고”, “내 메신저로 들어오고”, “정해진 시간에 알아서 움직이고”, “하면 할수록 내 일하는 방식을 외워 가는” 비서는 이쪽이 한 발 앞서 있다.

처음에는 부탁 한 가지로 시작해, 그게 손에 익으면 두 번째, 세 번째 자동화를 얹어 가는 식으로 키우는 것이 가장 안전하다. 한 번에 모든 것을 자동화하려 들면 결과를 검증하지 못한 채 일이 진행되어 도리어 신뢰가 깨지기 쉽다. 처음 며칠은 답이 시원찮아 보일 수 있다. 그래도 며칠만 같은 종류의 일을 함께 해보면, 어느 순간 “아, 이 친구가 내 폴더 구조와 내 일하는 방식을 외웠구나” 하는 순간이 온다. 그때부터가 진짜다. 너무 거창하게 시작하지 말고, 평소 답답하던 작은 일 하나, 예를 들어 “이 폴더 안 PDF들 제목만 모아서 표로 만들어줘” 같은 부탁부터 던져 보시면 좋다.

공문 초안, 민원 답변, 회의록 요약, 내부 규정 질의응답, 그리고 검색 기반 생성. 비개발자가 가장 먼저 시도해 볼 만한 다섯 가지를 한 호흡으로 풀어 둡니다.

1편에서 라이선스·모델명·instruct·한국어·크기 다섯 가지로 후보 모델을 추렸고, 2편에서 학습 데이터·튜닝·파라미터·파일 구성으로 모델 안쪽을 들여다보았다. 이제 마지막 편이다. 모델을 골랐다고 해도, 그것을 실제 업무 어디에 어떻게 끼워 넣어야 할지를 모르면 결국 책상 위의 신기한 장난감으로만 남는다. 이 글은 행정·교육·민원 현장에서 작은 AI 모델을 가장 먼저 적용해 볼 만한 다섯 가지 자리를 정리한다.

중요한 전제가 하나 있다. 여기서 다루는 활용은 모두 사람이 검토하고 책임지는 것을 전제로 한다. AI가 만든 결과를 그대로 결재 문서로 올리거나, 검토 없이 민원인에게 발송하는 일은 어떤 업무에서도 권장되지 않는다. 모델은 "초안을 빠르게 만들어 주는 보조"이지, "결재권을 가진 담당자"가 아니다. 이 전제를 잊지 않은 채 다섯 가지 활용을 차례로 살펴 본다.

01 / 행정 문서 작성공문·보도자료·보고서 초안

가장 먼저 시도해 볼 만한 자리는 행정 문서의 초안 작성이다. 공문이라면 제목, 본문, 협조 요청 문구를 만들어 주는 작업이고, 보도자료라면 제목과 리드문, 본문, 인용문을 잡아 주는 작업이다. 보고서라면 현황·문제점·개선방안·기대효과 같은 구조를 채워 주는 작업이고, 회의자료라면 안건·추진배경·세부과업·예산·일정의 골격을 짜 주는 작업이다.

이 자리에는 instruct 또는 chat이 붙은 한국어 모델이 잘 맞는다. 작은 모델(2B~7B)이라도 충분한 경우가 많고, 모델에게 "이 사업 개요를 가지고 보도자료 초안을 작성해 줘. 제목 한 줄, 리드문 두 줄, 본문 다섯 단락, 그리고 인용문 한 단락을 포함해 줘"처럼 형식과 분량을 함께 일러 주면 결과의 품질이 단번에 올라간다. 답변의 다양성을 결정하는 temperature 값은 정확성과 일관성이 중요한 행정 문서에서는 너무 높지 않게 두는 편이 좋다. 보통은 0.3~0.5 사이가 안전한 출발점이다.

이 자리의 가장 큰 효용은 "처음 한 단락"의 막막함을 없애는 데에 있다. 문서를 처음부터 쓰는 시간보다, 초안을 보고 고치는 시간이 압도적으로 짧다는 사실은 한 번이라도 직접 해보면 곧바로 체감된다. 담당자의 시간이 가장 비싼 자원이라는 점을 생각하면, 행정 문서 초안은 작은 AI 모델이 가장 먼저 자리 잡아야 할 영역이다.

02 / 민원 답변가장 신중하게, 가장 보조적으로

민원 답변은 행정에서 AI를 쓰는 가장 매력적인 자리이면서, 동시에 가장 신중해야 하는 자리다. 모델이 잘할 수 있는 일은 분명히 있다. 들어온 민원을 교통·복지·환경·세무 같은 분야로 분류하는 작업, 긴 민원의 핵심을 한 단락으로 줄이는 작업, 답변의 정중한 초안을 만드는 작업, 그리고 비슷한 민원이 과거에 어떻게 처리되었는지 검색해 보여 주는 작업이 그렇다.

대신 AI 답변을 그대로 발송하지 않는 원칙은 절대 흔들리지 않아야 한다. 법령 근거를 모델이 잘못 인용하는 일은 의외로 자주 일어나고, 기관마다 다른 처리 절차를 일반론으로 답하면 민원인에게 잘못된 신호를 줄 수 있다. 또 입력 단계에서 주민번호·주소·연락처 같은 개인정보가 포함되지 않도록 거르는 절차가 반드시 있어야 한다. 외부 클라우드 모델이 아니라, 우리 조직 안에서 돌아가는 작은 모델을 골라야 한다는 1·2편의 이야기가 가장 무거워지는 지점이 바로 여기다.

그래서 민원 자리에서는 모델 한 대로 끝내기보다 뒤이어 설명할 RAG 방식이 함께 쓰인다. 우리 부서의 과거 답변, 내부 지침, 관련 법령을 모델에게 함께 보여 주면서 "이 자료들 안에서만 답하라"고 시키는 방식이다. 이렇게 두면 사실에서 벗어나는 답변의 비율이 크게 줄어든다.

03 / 회의록·보고서 요약긴 문서를 읽는 시간을 돌려받기

회의가 끝난 뒤 한 시간짜리 녹취록을 마주한 경험, 백 페이지짜리 보고서를 읽고 한 페이지로 줄여야 했던 경험은 행정·기획 업무에서 흔하다. 이 자리는 작은 모델이 가장 명확한 가치를 만들어 내는 영역이다. 회의록이라면 주요 논의사항, 결정사항, 후속 조치(담당자·기한)를 뽑아 정리해 주고, 보고서라면 배경·문제점·대안·기대효과의 네 줄로 압축해 준다. 보도자료라면 핵심 메시지를 세 줄로 요약하고, 법령 문서라면 적용 대상·의무 사항·예외 사항을 골라 보여 준다.

요약 작업에서 가장 중요한 것은 두 가지다. 첫째, 중요한 내용을 빠뜨리지 않는 것. 둘째, 원문에 없는 내용을 만들어 내지 않는 것. 두 조건 모두 모델 입장에서는 어려운 일이고, 그래서 모델 카드의 평가 결과에 요약 점수가 적혀 있다면 한 번은 살펴 볼 가치가 있다. 다만 가장 좋은 검증은 우리 회의록·우리 보고서를 직접 한두 건 넣어 결과를 비교해 보는 것이다. 한국어 보고서 양식은 모델마다 처리 방식이 꽤 다르다.

요약 자리에서 또 하나 중요한 것이 컨텍스트 길이다. 2편에서 본 그 단어다. 회의록 한 시간 분량은 토큰으로 따지면 1만 개를 훌쩍 넘기기 쉽고, 보고서 백 페이지는 더 그렇다. 4k짜리 모델로는 한 번에 다 들어가지 않으니, 32k 이상의 컨텍스트를 가진 모델을 우선 후보로 두는 편이 편하다.

04 / 내부 규정 질의응답"이 지침에서 정산 기한이 언제인가요"

네 번째 자리는 내부 규정·매뉴얼·사업안내서·지침에 대한 질의응답이다. "이 지침에서 보조금 정산 기한은 언제인가요?", "이 사업의 신청 자격에 해당하는 기관 유형은 무엇인가요?", "이 지침의 평가 항목 중 가점이 부여되는 항목은 무엇인가요?" 같은 질문이 매일 부서로 들어온다. 담당자가 매번 같은 답을 찾아 주는 일에는 의외로 많은 시간이 든다.

이 자리에서 모델이 만들어 내는 가치는 단순하다. 우리 조직의 자료를 모델에게 보여 주고, 그 자료 안에서 답을 찾아 주도록 만든다. 모델 자체가 외워 둔 지식에 의존해 답하면 위험하다. 같은 보조금이라도 우리 부서 지침과 다른 부서 지침이 다르고, 작년 지침과 올해 지침이 다르기 때문이다. 그래서 이 자리에서도 자연스럽게 다음 절의 RAG가 등장한다.

한 가지 덧붙이자면, 내부 규정 질의응답 자리는 처음 작은 AI를 도입할 때 가장 빠르게 성과가 보이는 영역이다. 정답이 문서 안에 분명히 있고, 모델이 해야 할 일이 검색해서 옮겨 놓는 정도라 잘못될 여지가 적다. 첫 시범 사업의 자리로 권할 만한 곳이다.

05 / RAG"우리 문서 안에서만 답하라"

RAG는 Retrieval-Augmented Generation의 약자이고, 우리말로는 검색 증강 생성이다. 이름은 어렵지만 구조는 단순하다. 사용자의 질문이 들어오면, 시스템이 먼저 우리 조직의 문서 가운데 그 질문과 관련된 문단을 찾아 모델에게 함께 넘겨 준다. 모델은 자기 머릿속의 일반 지식이 아니라, 그 문단들에 적힌 내용을 근거로 답한다. 행정·법률·의료처럼 답이 우리 문서에 매여 있는 영역에서는 RAG가 사실상 표준이다.

구성 요소는 다섯 가지다. 첫째, 우리 조직의 문서들(공문·지침·매뉴얼·회의록 등). 둘째, 그 문서들을 검색에 적합한 작은 단위로 잘라 둔 청크(chunk). 셋째, 문장을 검색용 숫자 표현으로 바꾸는 임베딩 모델(embedding model). 넷째, 그 숫자 표현을 저장하고 빠르게 찾아 주는 벡터 데이터베이스(vector database). 다섯째, 사용자의 질문을 받아 답하는 생성 모델이다. 우리가 1편과 2편에서 고른 instruct 모델은 이 마지막 단계, 즉 답변 생성 자리에 들어간다.

RAG가 행정 업무에 잘 어울리는 이유는 분명하다. 모델이 우리 문서에 적힌 내용만으로 답하기 때문에, 사실에서 벗어나는 답변(이른바 할루시네이션, 환각)이 줄어든다. 답변과 함께 어떤 문서의 어느 문단을 근거로 했는지를 함께 보여 줄 수 있어, 담당자가 검증하기도 쉽다. 그리고 우리 조직의 문서가 바뀌면 검색 대상만 갱신하면 되므로, 모델 자체를 다시 학습시키지 않고도 최신 정보를 반영할 수 있다. 무엇보다 자료가 외부로 나가지 않는 구조로 만들기 쉬워, 행정망·폐쇄망 환경에서도 운영할 수 있다.

행정 업무에서 모델은 검색을 대신하는 도구가 아니라, 검색된 우리 문서를 함께 읽어 주고 정리해 주는 동료다.

06 / 마무리세 편의 시리즈가 도착하는 자리

세 편의 시리즈가 도착하는 자리는 결국 단순한 한 문장이다. 거대한 외부 모델 한 대에 모든 것을 의존하는 시대에서, 우리 조직 안에서 우리 자료에 맞춰 작게 도는 모델 한 대를 갖는 시대로 옮겨 가고 있다는 것. 그 작은 모델을 고르는 자리가 허깅페이스이고, 1편의 다섯 가지 판단축은 그 첫 문턱을, 2편의 안쪽 단어들은 그 두 번째 문턱을, 그리고 이번 3편의 다섯 가지 활용은 그 모델이 내려앉는 우리 책상 위의 자리를 보여 준다.

막막하게 느껴진다면 가장 작은 한 자리부터 시작하면 된다. 우리 부서 지침 한 권을 골라 모델에게 질문해 보는 일, 일주일치 회의록 다섯 건을 한 단락 요약으로 만들어 보는 일, 같은 사업의 공문 세 건을 가지고 보도자료 초안을 잡아 보는 일. 그 작은 시도가 쌓이면, 외부 클라우드의 큰 모델에 결재 문서를 통째로 던지지 않고도 우리 업무가 충분히 가벼워진다는 것을 직접 확인하게 된다.

한국데이터사이언티스트협회는 이 시리즈의 연장선에서 행정·공공·민간 폐쇄망 조직을 위한 바이브 코딩 교육과 자체 모델 도입 컨설팅을 이어 가고 있다. 시리즈를 읽고 막히는 지점이 생기면 언제든 이메일로 알려 주시면 좋겠다. 다음 시리즈는 직접 작은 모델을 우리 노트북·우리 서버에서 띄워 보는 실습편으로 이어질 예정이다.

SFT·RLHF·DPO·LoRA·QLoRA, 그리고 config.json·tokenizer·safetensors. 모델 카드 곳곳을 채우는 어려운 단어들을 일상 어휘로 한 번 옮겨 둡니다.

1편에서 라이선스, 모델명, instruct 여부, 한국어, 크기 다섯 가지로 후보 모델을 추렸다면, 이제 한 단계 더 들어갈 차례다. 모델 카드 본문과 Files and versions 탭에는 비개발자가 보면 막막한 단어가 잔뜩 등장한다. pretraining, SFT, RLHF, DPO, LoRA, QLoRA, hidden size, attention heads, safetensors. 하나하나 모두 알 필요는 없지만, 이름만 알아 두어도 모델 카드의 절반이 자연스럽게 읽힌다.

이 글은 그 단어들을 우리말 일상 어휘로 옮긴 두 번째 안내서다. 표나 정의 나열보다, 한 호흡으로 읽으며 "아, 이건 이런 뜻이구나"라고 기억에 남도록 풀어 두는 데 무게를 두었다.

01 / 사전학습 데이터모델은 무엇을 보고 자랐는가

모델 카드를 보면 거의 빠짐없이 pretraining data 또는 training data라는 항목이 등장한다. 우리말로는 사전학습 데이터다. 모델이 처음부터 언어 능력을 익히기 위해 사용한 대규모 데이터를 가리킨다. 사람으로 치자면 어릴 적에 본 책, 만난 사람, 들은 이야기 같은 것들이다. 이 단계에서 모델은 단어와 문장의 구조를 익히고, 역사·과학·사회·기술 같은 일반 지식을 흡수하고, 영어·한국어·중국어 같은 여러 언어의 패턴을 배우고, 보고서·기사·설명문 같은 문서 양식을 받아들인다.

자료는 보통 인터넷에 공개된 웹 문서, 위키피디아, 라이선스가 허용된 도서, 학술 논문, 깃허브 같은 공개 코드 저장소, 공개 뉴스, 그리고 질문과 답변 형식의 데이터가 섞인다. 모델 카드에는 이 사실이 다음과 같은 표현으로 등장한다. "trained on a mixture of public data"는 공개 데이터 여러 종류를 섞어 학습했다는 뜻이고, "web-scale dataset"은 인터넷 규모의 큰 데이터를 썼다는 의미다. "curated dataset"은 품질을 사람 손으로 거른 데이터를, "proprietary dataset"은 그 회사가 가지고 있는 비공개 데이터를 사용했다는 뜻이다. 최근에는 "synthetic data"라는 표현도 흔한데, 이는 사람이 만든 데이터가 아니라 AI가 생성한 데이터를 다시 학습 재료로 썼다는 의미다.

대부분의 큰 모델은 학습 데이터를 모두 공개하지는 않는다. 그래서 비개발자 입장에서는 "이 모델은 어디까지 보고 자랐는지를 회사가 얼마나 솔직히 적어 두었는가"를 보면 된다. 항목이 비어 있거나 한 줄만 적혀 있는 모델은 그만큼 검증하기도 어렵다는 뜻이다.

02 / 산업·언어 데이터"우리 업무에 어울리는 모델인가"

사전학습 데이터에는 일반 데이터 외에 도메인 데이터 또는 산업 데이터가 섞여 있을 수 있다. 행정 분야라면 공문, 민원, 정책자료, 법령, 회의록 같은 자료가 그 예다. 의료라면 진료 기록과 의학 논문, 금융이라면 공시자료와 재무제표, 법률이라면 판례와 계약서, 제조라면 설비 로그와 품질 데이터가 그렇다. 모든 모델이 이런 데이터를 본 것은 아니다. 일반 모델은 다양한 자료를 넓게 학습하고, 도메인 특화 모델은 특정 분야의 자료를 더 많이 학습하거나 그 위에 추가 튜닝을 한 모델이다.

행정 업무에 쓰려면 모델이 공문, 보도자료, 회의록, 민원 답변, 정책 보고서, 법령, 지침, 사업계획서, 예산 설명자료 같은 텍스트의 어투와 형식을 본 적이 있어야 한다. 본 적이 있다면 결재가 가능한 문장을 만들어 낼 가능성이 높고, 본 적이 없다면 "어색하게 정중한" 어투에 그칠 때가 많다.

여기에 더해 1편에서 짚은 한국어 데이터 포함 여부가 다시 중요해진다. 영어로 본 보고서 양식과 한국어로 본 보고서 양식은 모델 입장에서는 서로 다른 패턴이기 때문이다. Languages 항목에 ko가 있는지, KoBEST·KLUE 같은 한국어 평가 점수가 적혀 있는지, 그리고 카드 본문에 한국 공공·산업 데이터를 학습했다는 직접적인 언급이 있는지를 함께 본다.

03 / 튜닝 1Instruction Tuning과 SFT

사전학습이 끝난 모델은 글의 구조와 단어 사이의 관계는 잘 알지만, 사람이 부탁하는 방식의 문장을 명령으로 알아채는 데에는 약하다. 그래서 그 위에 추가 학습을 한다. 이를 튜닝(tuning)이라고 부른다. 모델 카드 본문에 가장 자주 등장하는 튜닝 단어 네 가지가 있다. Instruction Tuning, SFT, RLHF, DPO다.

먼저 Instruction Tuning은 사용자의 지시문을 잘 따르도록 학습시키는 방식이다. "다음 문서를 요약해줘", "이 내용을 표로 정리해줘", "민원 답변문 형식으로 작성해줘", "다음 코드의 오류를 찾아줘" 같은 요청을 이해하고 그에 맞게 답하는 능력을 추가로 익힌다. instruct, it, chat이 이름에 붙은 모델은 모두 이 단계를 거친 모델이다. 행정·문서·요약·질의응답에는 base 모델보다 instruct 모델이 훨씬 잘 맞는 이유가 여기에 있다.

SFT는 Supervised Fine-Tuning의 약자다. 우리말로 옮기면 지도 미세조정이다. 의미는 단순하다. 좋은 질문과 좋은 답변의 예시를 많이 보여 주면서 모델을 추가 학습시키는 방식이다. "이 문서를 요약해줘"라는 입력에 "핵심 내용은 다음과 같습니다…"라는 모범 답안을, "민원 답변문을 작성해줘"라는 입력에 "안녕하십니까. 귀하의 민원에 대해 답변드립니다…" 같은 모범 답안을 짝지어 보여 주는 식이다. 모델에게 "이런 질문이 오면 이런 식으로 답하라"를 가르치는 가장 기본적인 방식이다. Instruction Tuning은 사실 SFT를 통해 이뤄지는 경우가 많아, 두 단어가 거의 같은 맥락에서 쓰일 때도 있다.

04 / 튜닝 2RLHF와 DPO

RLHF는 Reinforcement Learning from Human Feedback의 약자로, 우리말로는 사람의 피드백 기반 강화학습이다. 이름은 거창하지만 과정은 직관적이다. 모델이 같은 질문에 여러 답변을 만들고, 사람이 그 가운데 더 좋은 답변을 골라 준다. 모델은 사람이 선호한 답변 쪽을 더 자주 만들도록 추가 학습된다. 이 과정을 거치면 답변이 자연스러워지고, 지시를 더 잘 따르고, 위험하거나 부적절한 표현이 줄어든다. ChatGPT가 처음 등장했을 때 사람들이 "왜 이렇게 말이 잘 통하지?"라고 느꼈던 이유의 상당 부분이 이 RLHF에 있다.

DPO는 Direct Preference Optimization의 약자다. 사람의 선호를 반영한다는 점은 RLHF와 같지만, 학습 구조가 더 단순하다. 좋은 답변과 나쁜 답변을 짝으로 묶어 주고, 모델이 좋은 답변 쪽을 더 선호하도록 직접 학습시키는 방식이다. 같은 민원 질문에 대해 정중하고 정확한 답변을 좋은 예로, 너무 캐주얼하거나 정확하지 않은 답변을 나쁜 예로 묶어 보여 주는 식이다. RLHF보다 학습 비용이 작고 결과도 비슷해, 최근 공개되는 오픈소스 모델은 SFT 다음 단계로 DPO를 쓰는 경우가 점점 늘고 있다.

모델 카드에서 "trained with SFT and DPO" 같은 문장을 보면, 그 모델은 모범 답안으로 한 번 다듬은 뒤 좋은 답·나쁜 답 비교로 한 번 더 다듬은 모델이라는 뜻이다. 이 단계까지 거친 모델은 곧바로 업무에 투입해도 비교적 안전한 출발점이 된다.

05 / 가벼운 추가 학습LoRA와 QLoRA

모델을 우리 조직에 맞게 추가 학습하고 싶다는 이야기가 나오면 빠지지 않고 등장하는 단어가 LoRA와 QLoRA다. LoRA는 Low-Rank Adaptation의 약자로, 모델 전체를 다시 학습하지 않고 작은 추가 학습 파일만 붙여서 모델의 행동을 바꾸는 방식이다. 모델 본체는 그대로 두고 옆에 작은 부속 부품을 하나 더 다는 그림에 가깝다. 전체를 다시 학습하는 방식에 비해 비용이 훨씬 작고, 학습한 결과 파일도 본체 모델보다 훨씬 작다. 우리 조직의 보도자료 문체, 우리 부서의 민원 답변 양식, 우리 사업의 회의록 형식 같은 좁은 목적의 학습에 잘 맞는다.

QLoRA는 Quantized LoRA의 약자로, LoRA보다 메모리를 더 적게 쓰도록 만든 방식이다. 모델을 더 작은 숫자 형식으로 줄여 메모리 사용량을 낮춘 다음, 그 상태에서 LoRA 학습을 진행한다. 같은 GPU로 더 큰 모델을 다룰 수 있게 해 주기 때문에, 개인 노트북이나 무료 클라우드 환경(예: Colab)에서 추가 학습을 시도할 때 가장 많이 쓰는 방법이다.

LoRA·QLoRA가 중요한 이유는 단순하다. 모델 전체를 다시 학습하려면 수천만 원에서 수억 원의 비용이 들지만, LoRA·QLoRA로 우리 조직 데이터를 가르치는 데에는 잘 짜면 수십만 원, 심지어 0원에 가까운 비용으로도 가능하기 때문이다. "우리 조직 데이터로 작은 모델을 한번 추가 학습해 보자"는 시도가 현실적인 선택지가 된 배경에는 이 두 가지 방식이 있다.

06 / 파라미터 구조크기, 컨텍스트, 그리고 내부 부품들

모델 카드의 오른쪽이나 본문 하단에는 모델 내부 구조에 관한 숫자들이 적혀 있다. 비개발자가 깊이 알 필요는 없지만, 단어의 뜻만 알아 두면 좋다. parameters는 모델 안에 저장된 학습된 숫자값의 총량이다. 1B는 10억, 7B는 70억, 70B는 700억 개의 숫자값이라는 뜻이다. 일반적으로 숫자가 많으면 더 복잡한 패턴을 다룰 수 있지만, 무조건 큰 모델이 좋은 것은 아니다. 작은 모델을 우리 데이터에 맞춰 가볍게 다듬으면 큰 모델보다 더 잘 답할 때가 자주 있다.

context length(컨텍스트 길이)는 모델이 한 번에 읽고 처리할 수 있는 입력의 길이다. 4k, 8k, 32k, 128k라는 표기를 보게 되는데, 단위는 토큰이다. 토큰은 모델이 텍스트를 잘게 나누어 처리하는 단위이고, 한국어는 글자·단어·조사가 여러 토큰으로 쪼개진다. 컨텍스트 길이가 길수록 긴 보고서를 한 번에 넣어 요약하거나, 회의록 전체를 한 번에 분석하거나, 검색된 여러 문단을 한꺼번에 모델에게 보여 주는 작업에 유리하다. 행정 문서 업무에는 최소 8k, 가능하다면 32k 이상이 편하다.

그 외에 자주 보이는 단어가 셋 더 있다. num_hidden_layers는 모델 내부의 처리 단계 수, num_attention_heads는 문장 안의 여러 관계를 동시에 살피는 부품의 수, hidden_size는 모델이 토큰 하나를 내부에서 표현할 때 쓰는 숫자 벡터의 크기다. 이 세 숫자는 모델이 클수록 함께 커진다. 비개발자 입장에서 깊이 들여다볼 필요는 없지만, 모델 카드에 등장하는 이 단어들이 "내부 부품의 수와 크기를 가리키는구나" 정도만 기억해 두면 충분하다.

07 / 파일 구성Files and versions 탭에 무엇이 있는가

모델 페이지 상단에는 Model card 옆에 Files and versions라는 탭이 있다. 누르면 모델을 실제로 돌리는 데 필요한 파일들이 줄지어 나타난다. 비개발자가 알아 두면 좋은 파일은 네 가지다.

첫째, config.json은 모델의 구조 설정 파일이다. 모델 종류, 레이어 수, hidden size, attention head 수, 토큰 사전 크기, 컨텍스트 길이 같은 정보가 이 안에 정리되어 있다. 6번 절에서 본 숫자들의 출처가 바로 이 파일이다. 사람이 직접 읽기보다는 모델을 불러오는 프로그램이 자동으로 참고한다.

둘째, tokenizer.json·tokenizer_config.json·special_tokens_map.json은 토크나이저(tokenizer) 관련 파일들이다. 토크나이저는 사용자가 입력한 문장을 모델이 처리할 수 있는 토큰 단위로 잘게 자르는 도구다. 같은 한국어 문장도 토크나이저에 따라 잘게 쪼개지는 방식이 다르고, 그래서 모델과 토크나이저는 항상 한 쌍으로 따라 다닌다. Llama 모델인데 다른 모델용 토크나이저를 쓰면 글자가 깨지거나 성능이 크게 떨어진다.

셋째, model.safetensors 또는 model-00001-of-00004.safetensors처럼 여러 개로 나뉜 파일이 모델의 실제 학습값(가중치)이 들어 있는 파일이다. 모델이 7B, 13B로 커질수록 한 파일에 다 담기지 않아 여러 조각으로 나뉘고, 그 조각들의 목록을 model.safetensors.index.json이 안내해 준다. safetensors라는 형식은 예전의 .bin보다 안전하고 빠르게 불러올 수 있도록 설계된 표준이다.

넷째, generation_config.json은 모델이 답변을 생성할 때의 기본 설정을 담은 파일이다. 답변의 최대 길이, 답변의 다양성 정도(temperature), 후보 단어를 고르는 범위(top_p), 같은 표현을 반복할 때 누르는 강도(repetition_penalty) 같은 값이 들어 있다. 행정 문서나 보고서처럼 정확성과 일관성이 중요한 작업에서는 temperature를 너무 높게 쓰지 않는 편이 좋다. 반대로 카피라이팅이나 아이디어 도출에는 살짝 높여 쓰는 것이 어울린다.

config.json은 설계도, tokenizer는 입구의 번역기, safetensors는 모델의 본체, generation_config는 출구의 손잡이. 네 종류만 기억해 두면 파일 목록이 더 이상 낯설지 않다.

08 / 마무리모델 카드를 끝까지 읽는 힘

여기까지가 두 번째 편이다. 학습 데이터가 무엇을 의미하는지, SFT와 RLHF와 DPO는 어떻게 다른지, LoRA와 QLoRA는 어떤 상황에 등장하는지, 파라미터·컨텍스트 길이가 우리 업무에 어떤 영향을 주는지, 그리고 Files and versions 탭에 보이는 네 종류의 파일이 무슨 일을 하는지를 같은 호흡으로 풀어 두었다. 한 번에 모두 외울 필요는 없다. 모델 카드를 다시 펼쳤을 때 이 단어들이 "어디서 들어 본 적이 있는 단어"로 다가오는 것만으로도 절반은 성공이다.

다음 편에서는 그렇게 고른 모델을 실제로 어디에 쓰는가를 다룬다. 행정 문서 작성, 민원 답변, 회의록과 보고서 요약, 그리고 우리 조직 내부 문서를 근거로 답하게 만드는 RAG(검색 기반 생성)까지 — 비개발자가 가장 먼저 시도해 볼 만한 다섯 가지 활용을 같은 산문 호흡으로 정리한다.

영어로 빼곡한 모델 카드 앞에서 한 발 물러서지 않아도 됩니다. 처음 볼 것은 라이선스·모델명·instruct 여부·한국어·크기, 다섯 가지뿐입니다.

요즘 행정·교육·민원 현장에서 "우리 조직 안에서 직접 돌리는 작은 AI를 한번 시험해보자"는 이야기가 부쩍 늘었다. 외부 클라우드에 자료를 보내지 않아도 되고, 우리 규정과 문서에 맞춰 답하는 모델을 갖고 싶다는 요구다. 그래서 검색 끝에 도착하는 곳이 허깅페이스(huggingface.co)다. 전 세계의 인공지능 모델이 모여 있는, 일종의 공개 도서관 같은 사이트다.

그런데 막상 모델 페이지를 열면 영어로 된 설명과 빼곡한 파일 목록 앞에서 한 발 물러서게 된다. 무엇을, 어떤 순서로 봐야 할지 모르기 때문이다. 이 글은 그런 분들을 위한 첫 안내서다. 깊게 들어가지 않고, 비개발자가 처음 모델을 고를 때 정말 봐야 할 다섯 가지만 짚는다. 학습 데이터·튜닝 방식·내부 구조 같은 더 깊은 이야기는 2편에서, 행정·민원·RAG 같은 실제 활용 이야기는 3편에서 이어 풀어 둘 예정이다.

01 / 라이선스"이 모델, 우리 회사에서 써도 되는가"

가장 먼저 보아야 할 것은 모델 성능이 아니라 라이선스다. 라이선스는 모델을 만든 측이 정해 둔 사용 규칙이다. 어떤 모델은 누구나 자유롭게 가져다 쓰고 회사 서비스에 넣어도 되지만, 어떤 모델은 연구 목적에만 쓸 수 있고 상업적으로는 쓰지 못한다. 허깅페이스 모델 페이지에 들어가면 오른쪽 사이드바, 또는 모델 카드 상단에 License라는 항목이 있다. 거기 적힌 한두 단어가 우리가 이 모델을 어디까지 쓸 수 있는지를 결정한다.

자주 보이는 표기를 풀어 두자면 Apache-2.0과 MIT는 비교적 자유로운 오픈소스 라이선스로, 회사 안에서 쓰거나 유료 교육 자료에 활용해도 대체로 문제가 없다. CC-BY는 출처만 표시하면 자유롭게 쓸 수 있다는 뜻이다. 반면 Meta가 만든 Llama 계열은 Llama License라는 별도 조건이 있고, Google의 Gemma 계열은 Gemma Terms를 따로 둔다. 두 라이선스 모두 대체로 상업 활용을 허용하지만, 사용자 수 상한이나 금지 분야 같은 단서 조항이 있어 한 번은 직접 읽어 보아야 한다. 카드에 "Research only" 또는 "Non-commercial"이 붙어 있다면 회사 서비스나 수익 활동에는 쓰지 못한다고 보면 된다.

오픈소스라는 단어가 들어 있다고 해서 무조건 마음대로 써도 되는 것은 아니다. 모델을 골랐을 때 가장 먼저 라이선스를 확인하는 습관만 들여도, 나중에 법무 검토 단계에서 모든 일이 뒤집히는 경험을 피할 수 있다. 특히 공공기관에서 시범 서비스를 만들 때, 라이선스 한 줄이 사업 연장 여부를 가르는 일이 실제로 자주 일어난다.

02 / 모델명이름 안에 이미 절반의 정보가 있다

허깅페이스의 모델 주소는 "만든 곳/모델이름"이라는 형식을 따른다. google/gemma-2-2b-it, microsoft/Phi-3-mini-4k-instruct, meta-llama/Llama-3.2-3B-Instruct 같은 식이다. 이 길어 보이는 이름이 사실은 모델의 핵심 정보를 압축해 담고 있다. 모델 카드 본문에 들어가지 않고도, 이름만 잘 읽어 두면 후보를 절반쯤 추릴 수 있다.

앞쪽의 google, microsoft, meta-llama는 모델을 만든 회사다. 같은 능력의 모델이라도 누가 만들었는지에 따라 문서의 친절함, 업데이트 주기, 라이선스 안정성이 크게 달라진다. 한 번 들어 본 회사의 모델을 우선 후보군에 두는 것은 보수적이지만 합리적인 선택이다. 그다음에 오는 gemma-2, Phi-3, Llama-3.2는 모델 계열과 세대다. 같은 가족 안에서 숫자가 클수록 더 최근 세대이고, 이전 세대보다 한국어와 추론 능력이 좋아져 있을 가능성이 높다.

이름 중간에 자주 등장하는 2b, 3b, 7b, 70b 같은 표기는 파라미터 수를 뜻한다. 파라미터는 모델 안에 저장된 학습된 숫자값이고, b는 billion 즉 10억이다. 7b라면 약 70억 개의 숫자값을 가진 모델이라는 의미다. 마지막에 붙는 it, instruct, chat은 사용자의 지시를 따르도록 추가 학습되었다는 표시이고, base가 붙어 있으면 아직 그 추가 학습이 되지 않은 기본 모델이라는 뜻이다. 이름에 mini, small이 보이면 같은 가족 안에서 작은 쪽, ko, korean이 보이면 한국어 데이터가 추가되었거나 한국어용으로 조정된 버전일 가능성이 높다.

03 / instruct 여부"지시를 따르는 모델인가"

업무용으로 쓸 모델이라면 거의 예외 없이 instruct 또는 chat이 붙은 모델을 골라야 한다. 차이를 짧게 풀자면, 기본(base) 모델은 인터넷에 있던 글, 책, 논문 같은 방대한 텍스트로 "다음 단어 맞히기"를 익혀 둔 상태다. 글의 구조와 단어 사이의 관계는 잘 알지만, 사용자가 "이 문서를 표로 정리해줘"라고 했을 때 그것이 명령이라는 사실을 잘 인식하지 못한다. 그래서 base 모델은 부탁을 하면 부탁의 뒷말을 이어 쓰거나 비슷한 문장을 변주하기도 한다.

이 위에 "이렇게 부탁하면 이렇게 답한다"는 모범 예시를 수십만 건 추가로 보여주는 학습 단계가 있다. 이를 instruction tuning(지시 학습)이라고 부르고, 이 과정을 거친 모델이 instruct 또는 chat이라는 이름표를 단다. 행정·문서 작업에 쓰는 모델은 거의 모두 instruct 계열이다. 모델 카드에 chat template이라는 표현이 보이면 더 안심해도 된다. system, user, assistant 같은 역할 표시를 이해하고 대화 형식으로 답할 줄 안다는 뜻이기 때문이다.

반대로 base 모델은 직접 추가 학습을 할 사람이 가져가는 재료에 가깝다. 비개발자가 곧바로 "민원 답변문 좀 써줘"를 시키기에는 적절하지 않다. 같은 가족 모델이라도 이름 끝에 instruct가 붙어 있는 쪽을 고르는 것이 첫 단계의 안전한 선택이다.

04 / 한국어한국어를 진짜로 다루는 모델인가

모델이 한국어를 어느 정도 다루는지는 의외로 빨리 확인할 수 있다. 첫째로 모델 카드 상단의 Languages 항목을 본다. ko, korean이 들어 있으면 학습 단계부터 한국어 데이터를 일정 비율 보았다는 뜻이다. 둘째로 카드 본문에 multilingual(다국어)이라는 표현이 있고 그 옆에 한국어가 명시되어 있는지를 본다. 셋째로 평가 결과 표에 KoBEST, KLUE, KoBBQ 같은 한국어 벤치마크 점수가 적혀 있는지 본다. 한국어 벤치마크가 아예 등장하지 않는 모델은, 만들 때 한국어를 일급 시민으로 다루지 않았다고 봐도 무방하다.

영어 중심으로 학습된 큰 모델도 한국어를 어느 정도 한다. 하지만 행정 문서처럼 문체와 형식이 정확해야 하는 영역에서는 "어느 정도"가 위험하다. 결재가 가능한 문장을 만들어 내는지, 존댓말과 공문 어투를 자연스럽게 쓰는지는 영어 성능과는 완전히 다른 문제다. 영어 시험은 100점인데 한국어 공문은 어색한 모델이 의외로 많다.

그래서 후보군에는 한국어 데이터로 추가 학습된 모델, 또는 한국 회사가 직접 만든 공개 모델을 함께 두는 편이 좋다. Upstage의 SOLAR 계열, EleutherAI의 한국어 변형 모델, LG·카카오·네이버 계열에서 공개한 모델, 그리고 국내 연구실이 한국어로 추가 튜닝해 올린 community 모델들이 그런 후보다. 이런 모델은 카드 첫 줄부터 한국어 설명이 등장하는 경우가 많아 알아보기도 쉽다.

05 / 크기우리 컴퓨터에서 돌릴 수 있는 모델인가

마지막 관문은 모델 크기다. 같은 가족이라도 2B, 3B, 7B, 13B, 70B처럼 여러 크기로 공개되는 경우가 많다. 단순하게 말하면 숫자가 클수록 똑똑할 가능성이 높지만, 돌리는 비용도 그만큼 커진다. 비개발자가 가늠해 두면 좋은 대략적인 기준은 이렇다. 2B에서 3B 사이의 모델은 상대적으로 작은 그래픽카드(예: RTX 4060급)나 노트북 GPU, 또는 기관에 흔히 있는 보조 서버에서도 돌아간다. 7B급은 본격적인 GPU(RTX 4090, A6000 등) 한 장이 있어야 안정적으로 돌고, 13B 이상은 더 좋은 GPU나 두 장 이상의 GPU가 필요해진다. 70B로 가면 일반 조직에서 자체적으로 돌리기는 어렵고, 클라우드를 빌리거나 양자화(모델을 더 작은 숫자 형식으로 줄이는 것) 버전을 써야 한다.

여기서 비개발자가 자주 빠지는 함정이 하나 있다. 큰 모델이 무조건 더 똑똑할 것이라는 직관이다. 행정·교육 현장의 골목길 문제 — 공문 요약, 민원 분류, 내부 규정 질의응답 같은 — 는 의외로 2B에서 7B급의 작은 모델로도 충분한 경우가 많다. 작은 모델을 우리 조직 데이터에 맞춰 가볍게 추가 학습하면, 큰 모델보다 더 빠르고 더 정확한 결과가 나오는 사례가 적지 않다. 더 중요한 것은, 큰 모델은 도입 비용과 운영 비용이 함께 커진다는 사실이다. 한 달 전기요금만 수백만 원씩 늘 수도 있다.

그래서 처음에는 가장 작은 instruct 모델부터 시작하는 것이 가장 보수적이면서도 가장 빠른 길이다.

06 / 마무리다섯 줄로 끝나는 첫 체크리스트

여기까지가 첫 편이다. 정리하자면 이렇다. 첫째, 라이선스를 보고 우리 조직이 이 모델을 써도 되는지 확인한다. 둘째, 모델명에 들어 있는 회사·세대·크기·instruct 표시를 읽는다. 셋째, instruct 또는 chat이 붙어 있는지 본다. 넷째, 한국어를 일급으로 다루었다는 단서가 있는지 본다. 다섯째, 우리 컴퓨터로 돌릴 수 있는 크기인지 가늠한다. 이 다섯 가지만 차례로 짚어 보아도, 허깅페이스에 올라온 수만 개 모델 가운데 우리 업무에 어울리는 후보 서너 개로 좁혀진다.

다음 편에서는 그렇게 추린 후보 모델의 안쪽을 들여다본다. 이 모델은 무슨 데이터를 보고 자랐는지, 어떤 식으로 다듬어졌는지, 모델 페이지의 Files and versions 탭에 줄지어 있는 config.json·tokenizer.json·model.safetensors 같은 파일은 각각 어떤 역할을 하는지를, 똑같이 비개발자 어휘로 풀어 둔다. 1편을 읽고 후보 모델 두세 개를 책갈피에 꽂아 두셨다면, 2편이 그 책갈피를 펼쳐 보는 시간이 될 것이다.

모델은 지수곡선으로 좋아지는데, 조직은 여전히 직선으로 움직입니다. 그 간격을 메우는 다섯 가지 무기를, 회사에서 동료에게 그대로 설명할 수 있는 표현으로 옮겨 놓습니다.

앤트로픽의 연례 개발자 행사 Code with Claude 2026 오프닝 키노트가 끝났습니다. 47분짜리 발표였고, 그 안에 새로 들어온 용어가 적지 않았습니다. Managed Agents, Multi-Agent Orchestration, Outcomes, Dreaming, Routines, CI Autofix, Advisor Strategy. 영문 약어와 신조어가 빽빽이 박혀 있어서, 평소 코드를 직접 짜지 않는 분들에게는 한 번 흘려듣고 끝나기 쉬운 자리였을 것입니다.

그래서 이 글에서는 키노트의 흐름을 다섯 가지 화두로 추려, 각 화두에서 등장한 핵심 용어를 짧게 정의하고 그 의미를 평어로 풀어내려고 합니다. 회사에서 임원이나 동료에게 "지금 AI 도구가 어디까지 와 있느냐"고 질문받았을 때, 그대로 옮겨 쓸 수 있는 표현을 찾는 것이 목적입니다.

01 / 큰 그림모델은 지수곡선, 조직은 직선

키노트는 앤트로픽의 최고제품책임자(CPO) 발언으로 열렸습니다. 핵심 메시지는 한 문장으로 요약됩니다. 모델 능력은 지수곡선으로 좋아지고 있는데, 대부분의 조직은 여전히 직선으로 도입하고 있다는 것입니다. 그래서 "AI가 할 수 있는 일"과 "사람들이 실제로 시키고 있는 일" 사이에 점점 큰 간격이 벌어지고 있고, 이 간격이 곧 비즈니스 기회라는 이야기입니다.

발표자는 1년 전 발표 자리에서는 "에이전트가 사람의 확인 없이 한 시간 정도 일하는 것"을 비현실적인 목표처럼 이야기했었는데, 지금은 "에이전트가 밤새 끝까지 작업해서 다음 날 아침에 결과물을 받는 일"이 일상이 됐다고 짚었습니다. 또 한 달 전에는 차세대 모델(Mythos·코드네임)이 OpenBSD 운영체제 전체 코드를 읽고, 27년 동안 어떤 사람·퍼저·정적분석기도 잡아내지 못했던 보안 취약점을 찾아냈다는 사례도 인용했습니다.

구체적인 사용량 숫자도 함께 공개됐습니다. 1년 전 대비 Claude 플랫폼의 API 호출량은 17배로 늘었고, Claude Code 평균 사용자는 일주일에 20시간을 그 안에서 보낸다고 합니다. 도구 하나를 일주일에 사흘 가까이 쓴다는 의미입니다. 또한 발표 시점에 Pro·Max·Team 등 유료 플랜의 5시간 단위 사용량 한도를 두 배로 늘리고, Opus 모델의 API 한도도 크게 올린다고 발표했습니다.

1년 전에는 "사람이 한 시간 자리를 비워도 AI가 알아서 일을 이어 가는 것"이 도전 과제였고, 지금은 밤새 일이 끝나 있는 게 일상입니다. 그 간격이 조직과 모델 사이에 그대로 쌓이고 있습니다.

02 / 모델 층업그레이드를 비즈니스 기회로 보는 자세

두 번째 발표자는 리서치 PM 팀의 다이앤이었습니다. 모델은 어디까지 왔고, 어디로 가고 있는지를 정리했습니다. 그가 던진 가장 실용적인 메시지는 "모델 업그레이드를 비즈니스 기회로 다루라"는 한 문장입니다.

실제 사례도 함께 인용됐습니다. 코딩 에이전트 회사 AMP는 자사 벤치마크에서 Opus 4.7이 가장 높은 점수를 내자, 똑똑이 모드를 통째로 그 모델로 옮기고 자체 스캐폴딩 일부를 제거했다고 합니다. 모델이 충분히 좋아져서 받쳐줄 사다리가 줄어들었다는 의미입니다. 라쿠텐은 같은 모델로 운영 환경에서 풀어낸 엔지니어링 작업의 양이 직전 대비 세 배가 됐고, 인튜이트는 Opus 4.7이 자기 추론의 결함을 스스로 짚어내고 다시 푸는 모습을 확인했다고 합니다.

03 / 플랫폼 층관리형 에이전트와 세 가지 신무기

세 번째 블록은 클라우드 플랫폼 팀의 케이틀린과 안젤라가 맡았습니다. "비즈니스에서 모델을 잘 쓰지 못하게 막는 두 가지 벽"을 짚는 데서 시작했습니다. 하나는 원하는 결과를 정확히 끌어내기가 여전히 어렵다는 점, 다른 하나는 빠르게 출시하면서도 운영 가능한 품질로 굴리기가 어렵다는 점입니다.

이 위에 새로 추가된 세 가지가 키노트의 발표 핵심입니다.

세 가지를 한 줄로 묶으면 다음과 같습니다. 멀티 에이전트는 일을 나누고, 아웃컴은 합격선을 정의하고, 드리밍은 시간이 지날수록 시스템 스스로 좋아지게 만듭니다. 비개발자에게 가장 와닿는 표현으로 옮기면, "한 번 잘 짜두면, 자고 일어나면 더 똑똑해져 있는 비서"를 쓰는 일이 가능해진다는 이야기입니다.

04 / 도구 층Claude Code, "코드를 시키는 코드"로

네 번째 블록은 Claude Code 책임자 안젤라와 보리스 셔니의 발표였습니다. 1년 전과 가장 많이 달라진 부분이라고 직접 짚었습니다. 1년 전에는 사용자가 한 줄 한 줄 모든 코드 변경을 직접 검토했고, "이 작업을 진행해도 됩니까" 식의 허락을 묻는 알림이 100~200번씩 떴습니다. 지금은 대부분의 사용자가 자동 모드로 두고, 작업이 끝났을 때 동료에게 검토 요청을 보내듯 결과물 단위로만 살펴봅니다. 개발 현장에서는 이 결과물 단위를 PR(풀 리퀘스트)이라 부릅니다 — "한 묶음의 변경 사항을 회사 본 코드에 합쳐 달라고 요청하는 단위"라고 이해하시면 됩니다.

도구 자체보다 더 의미 있는 것은 사용 규모의 사례였습니다. 쇼피파이는 엔지니어뿐 아니라 디자인·기획·데이터 직군까지 Claude Code를 일상 도구로 쓰고 있다고 소개됐고, 라틴아메리카 최대 e커머스 메르카도리브레는 엔지니어 23,000명 전원이 Claude Code 위에서 일하면서 50만 건이 넘는 PR을 사람 검수와 함께 검토했고, 9,000개 이상의 앱을 현대화했다고 합니다. 같은 회사의 기술 책임자 오스카 멀런은 올해 3분기까지 90% 자율 코딩과 완전 에이전트 주도 PR 루프를 목표로 잡고 있다고 합니다.

앤트로픽 자체도 같은 흐름입니다. Claude Code를 사내 전면 도입하고 나서 엔지니어 1인당 PR 생성량이 200% 증가했고, 그 와중에도 코드 품질 기준은 그대로 유지되고 있다는 발표가 있었습니다.

Claude Code를 잘 쓰는 회사들의 공통점은 한 가지입니다. 매니저와 임원이 다시 코드 베이스에 손을 대기 시작했다는 것. 로드맵과 리뷰만 보던 사람들이 다시 빌딩으로 돌아왔습니다.

05 / 자동화 층Routines — 깨어 있지 않아도 흐르는 일

마지막 블록은 보리스 셔니가 시연한 한 가지 개념에 모입니다. Routines. 발표자가 "내 코드의 상당량을 이제 내가 직접 지시문(프롬프트)을 입력해서 짜지 않는다. 내가 짜는 것은 그 지시문을 자동으로 던져 주는 루틴이다"라고 표현한 부분이 가장 정확한 정의입니다.

그리고 모바일도 함께 짚어둘 만합니다. iOS와 안드로이드 Claude 앱 안에 Claude Code 원격 제어가 들어왔습니다. 노트북을 열고 균형을 잡으며 거리를 걷지 않아도, 공원에서도 작업을 던질 수 있다는 것이 발표자의 표현이었습니다.

06 / 닫는 말비개발자에게 남는 한 가지

키노트 전체를 한 문장으로 압축하면 이렇습니다. 이제 기본값이 바뀌었습니다. 발표자 보리스의 표현을 그대로 옮기면, "기본값은 더 이상 '내가 Claude Code에 프롬프트를 넣는다'가 아니라, '내가 Claude로 하여금 Claude Code에 프롬프트를 넣게 한다'입니다."

코드를 직접 짜지 않는 분들에게 이 변화는 어떻게 닿을까요. 두 가지로 정리할 수 있습니다.

하나는 업무 위임의 단위가 바뀝니다. 어제까지는 동료에게 "이 보고서 좀 정리해 줘"라고 부탁했다면, 이제는 "이 일이 들어올 때마다 Claude가 자동으로 정리해서 내 메일함에 넣어두도록 하는 루틴 한 개"를 만드는 일이 비교 대상이 됩니다. 한 번의 부탁이 한 번의 결과를 만들던 패러다임이, 한 번의 설계가 무한히 반복되는 결과를 만드는 패러다임으로 옮겨가고 있습니다. 이 옮겨감을 이해하고 본인의 업무 흐름에 적용하는 것이, 향후 1~2년 가장 큰 차이를 만드는 변수가 됩니다.

다른 하나는 책임의 무게가 더 분명해집니다. 에이전트가 한 번에 끝까지 일을 처리할수록, 그 결과를 검수하고 승인하는 사람의 자리는 더 무거워집니다. AI가 99.9%를 잘 해내도 0.1%의 오류는 반드시 발생하고, 그 0.1%에 책임을 지는 일은 외주화되지 않습니다. 키노트의 안젤라·케이틀린 발표가 거듭 강조했듯이, 검수와 승인의 자리에 있는 사람의 역할이 오히려 더 커진다는 의미입니다.

요약하면, AI가 더 잘하게 됐다는 사실보다, 그 잘함을 일상 업무 흐름에 어떻게 끼워 넣는지가 새로운 격차의 원천이라는 것이 이번 키노트의 핵심입니다. 발표자들이 거듭 짚은 표현으로 닫겠습니다. 모델은 지수곡선으로 좋아집니다. 우리 조직이 직선에 머물러 있을지, 같은 곡선 위에 올라탈지를 결정하는 것은, 더 이상 모델이 아니라 우리입니다.

앤트로픽이 진행한 2026년 5월 Code with Claude 오프닝 키노트의 47분짜리 발화 전체를, 발표자별·타임스탬프별로 한국어로 옮긴 전사록입니다.

00 / 무대 인사오프닝Kat (사회 / 무대 인사)

01 / 오프닝왜 우리가 오늘 여기 있는가Anthropic CPO

02 / 모델지수곡선과 모델 인텔리전스Diane (Research PM Team Lead)

03 / 플랫폼Claude Managed Agents — Multi-Agent · Outcomes · DreamingCaitlin & Angela (Cloud Platform 팀)

04 / Claude Code도구의 진화와 새로운 사용 방식Angela (Claude Code)

05 / 시연AcmePay 데모와 RoutinesBoris Cherny (Head of Claude Code)

1839년, 사진기가 발명되었을 때 회화는 죽지 않았습니다. 천장이 더 높이 올라갔을 뿐입니다. AI 앞에 선 지금 우리에게도 같은 길이 열려 있습니다.

"사진기가 발명되었으니 이제 회화는 죽었다." 1839년, 프랑스 화가 폴 들라로슈가 다게레오타이프 사진을 처음 본 자리에서 남겼다고 전해지는 말입니다. 한 시대의 기술이 한 시대의 직업과 예술을 통째로 지워버릴 것이라는 단언. 그러나 우리가 알고 있듯이 회화는 죽지 않았습니다. 사진이 "현실을 모방하는" 일을 가져가자, 화가들은 인상주의를 열고, 무의식과 추상의 영역으로 들어가 새로운 천장을 끌어올렸습니다.

최근 한 글이 그 일화에서 출발해 우리에게 비슷한 질문을 던졌습니다. 구글의 테크 리드 매니저이자 W3C 오디오 워킹 그룹 의장으로 일하고 있는 최홍찬이 자신의 브런치에 올린 글입니다. 1990년 MIDI 시퀀서에 매료되어 음악과 코드의 경계를 20년 넘게 오갔고, 2009년 스탠퍼드 컴퓨터음악 연구소에서 박사를 받은 뒤 2014년 구글에 합류해 지금은 글로벌 웹 표준 제정을 주도하면서 동시에 스탠퍼드에서 차세대 뮤직 테크놀로지스트들을 가르치고 있는 사람입니다.

실리콘밸리의 가장 안쪽에서 AI를 매일 마주하는 그가, 같은 산업의 동료들과 나눈 대화 속에서 길어 올린 세 가지 화두를 정리했습니다. FOMO를 다스리는 법, 책임은 외주화할 수 없다는 사실, 그리고 점점 더 중요해지는 비판적 사고력. 한국 독자의 자리에서 다시 읽어볼 만한 통찰이라, CDSA 블로그에 옮겨 정리합니다.

01 / 첫 번째 화두FOMO — 두려움은 외부가 아니라 내면에 있다

최홍찬이 가장 먼저 짚은 것은 우리 모두가 느끼는 그 감정이었습니다. "뒤처질지도 모른다"는 두려움. 흔히 FOMO라 부르는 감정입니다. 그런데 그가 적어 내려간 풍경은 의외였습니다. 이 두려움은 일반인의 것이 아니라, AI 최전선에서 모델을 만들고 있는 엔지니어들 사이에서도 똑같이 흐르고 있다는 것입니다. 매주 새로운 논문이 쏟아지고, 어제까지 최첨단이었던 기술이 다음 주면 진부해지는 환경에서, 가장 빠른 사람들조차 "내가 따라가고 있는 것이 맞나"를 묻는다고 합니다.

그래서 그는 한 가지 사실을 강조합니다. 이 감정은 외부의 위협에서 오는 것이 아니라, 우리 내면에서 만들어지는 것이라는 점. 다시 말해 외부 환경을 통제할 수는 없어도, 우리가 그것을 받아들이는 방식은 바꿀 수 있다는 이야기입니다.

같은 강도의 정보 폭우 앞에서도, 누군가는 익사하고 누군가는 수영을 배웁니다. 차이는 정보의 양이 아니라 그것을 마주하는 자세에 있습니다.

그가 권하는 첫 번째 자세는 혼자 따라가지 않는 것입니다. 소셜 피드와 논문을 혼자 헤쳐 나갈 때 느끼는 압박감과, 팀원이나 스터디 그룹에서 함께 읽고 토론할 때 느끼는 안도감은 강도가 전혀 다르다고 말합니다. 학습은 본질적으로 사회적 행위인데, 우리는 너무 자주 그것을 고독한 사투처럼 만든다는 것입니다.

두 번째 자세는 모든 트렌드를 다 잡으려 하지 않는 분별입니다. 프롬프트 엔지니어링, MCP, 새로운 프레임워크 — 이런 최신 기술들의 상당수는 불완전한 AI를 임시로 제어하기 위한 일종의 보조 장치이며, 모델이 발전하면 자연스럽게 사라질 것이라고 그는 봅니다. 그래서 모든 것을 깊게 파고들 필요는 없고, 어떤 흐름이 일시적이고 어떤 흐름이 구조적인지를 분간하는 안목이 더 중요해진다는 이야기입니다.

세 번째는 자극적인 콘텐츠에 반응 본능을 빼앗기지 않는 일입니다. "이거 모르시나요?"로 시작하는 피드는 우리의 불안을 연료 삼아 클릭을 끌어내도록 설계되어 있습니다. 거기에 휩쓸리지 않으려면, 지금 내 손에 놓인 문제를 해결하는 데 필요한 만큼만 취사선택하는 냉정함이 있어야 한다는 것입니다.

02 / 두 번째 화두커리어 — AI가 바닥을 올려도, 천장은 사람의 영역이다

두 번째로 그가 던진 질문은 더 묵직합니다. AI가 점점 잘하게 되는 영역에서 우리가 어떻게 살아남을 것인가. 그가 내놓은 답은 단순하지만 깊은 표현이었습니다. AI는 바닥을 올리고, 인간은 천장을 책임져야 한다는 것.

지난 몇 년간 우리가 본 변화는 분명합니다. 코드 자동완성, 문서 요약, 이미지 생성, 1차 분석. 예전이라면 신입사원이 오래 시간을 들여야 했던 작업들의 평균 품질이 가파르게 올라갔습니다. 그런데 그가 짚은 지점은 다음 단계입니다. 바닥이 올라온 만큼, 그 위에 사람만이 도달할 수 있는 영역과의 간격이 더 의미 있어진다는 것입니다.

여기서 그는 오랫동안 거론되어 온 T자형 인재의 가치를 다시 호명합니다. 깊은 도메인 전문성으로 AI가 내놓은 결과를 검증할 수 있고, 동시에 넓은 시야로 전체 시스템을 이해해 AI를 어디에 어떻게 쓸지 기획할 수 있는 사람. 양쪽이 모두 사라지지 않은 상태에서, 한쪽 깊이가 깊어질수록 위로 올라갈 수 있는 천장이 높아진다고 봅니다.

AI가 99.9%를 완벽하게 수행해도, 0.1%의 오류는 반드시 발생합니다. 그 결과에 대한 최종 책임은 인간이 집니다.

그가 가장 길게 강조한 것은 책임의 문제였습니다. AI는 결과물을 생산할 수 있지만, 결과에 대한 책임을 외주화할 수는 없다는 사실. 의료 현장에서 AI가 진단을 보조하더라도 최종 서명은 의사의 몫이고, 법률 문서를 AI가 초안하더라도 그 문서의 무게는 결국 변호사가 짊어집니다. 기업 안에서도 마찬가지입니다. 보고서가 AI로부터 출발했어도, 그것을 임원에게 들이밀고 결재 라인을 통과시키는 사람의 이름이 거기에 적힙니다.

그래서 그는 한 가지 전략적 권고로 옮겨갑니다. 바닥이 올라올수록, 실행을 지도하고 결과를 승인하는 책임자의 위치에 있는 사람의 가치는 오히려 더 높아집니다. 이 자리에서 오너십을 차곡차곡 쌓아가는 일이, 길게 보면 AI 시대를 사는 가장 견실한 커리어 전략이 됩니다.

03 / 세 번째 화두비판적 사고력 — 좋은 질문, 그리고 인지 부채

세 번째 화두는 어쩌면 가장 익숙하지만, 가장 자주 빠뜨리는 것입니다. 비판적 사고력. 너무 많이 들어 진부해진 단어이지만, 최홍찬은 이것을 AI 시대의 가장 핵심적인 역량으로 지목합니다.

그는 먼저 좋은 답은 좋은 질문에서 나온다는, 어쩌면 너무 당연한 사실을 다시 꺼냅니다. 그러나 이때 좋은 질문이라는 것은 단순히 똑똑해 보이는 질문이 아닙니다. 주제에 대한 이해도, 무엇을 원하는지에 대한 의지, 그리고 맥락을 파악하는 감각이 모두 결합되어 만들어지는 것입니다. 의도성 없는 질문은 그저 검색창을 한 번 더 두드리는 행위에 머물고 맙니다.

표면이 매끈할수록 더 의심해야 합니다. AI의 결과물은 종종 그 매끈함 자체로 비판적 시선을 마비시킵니다.

그가 더 무겁게 짚은 것은 인지 부채(cognitive debt)라는 개념이었습니다. 자신이 제대로 이해하지 못한 결과물을 그대로 가져다 쓰기 시작하면, 당장은 일이 빨리 끝나는 것처럼 보입니다. 그러나 시간이 지날수록 자신의 자산이라고 부를 만한 것이 비어가는 상태에 도달합니다. 코드를 짰는데 그 코드를 설명할 수 없고, 보고서를 냈는데 그 안의 숫자가 어디서 왔는지 모르는 상태. 이 부채는 어느 날 한 번에 청구되며, 그때는 회복이 어렵습니다.

이 위험을 막기 위해 그는 한 가지 원칙을 권합니다. 자신이 만들어 낸 AI 산출물을 온전히 이해할 책임을 끝까지 놓지 않는 것. AI에게 작업을 맡기더라도, 결과물을 자기 언어로 다시 한번 풀어 설명할 수 있을 때까지 들여다본다는 자세입니다. 빠른 사고는 AI의 몫이지만, 사유의 마찰은 사람이 일부러 보존해야 합니다. 깊이 있는 사고는 마찰 안에서만 자라기 때문입니다.

04 / 닫는 말인상주의가 열린 자리에서

글의 마지막에서 최홍찬은 다시 1839년의 풍경으로 돌아옵니다. 사진기가 회화의 기초적 기능을 가져갔을 때, 화가들에게 닥친 첫 감정도 우리와 비슷했을 것입니다. 두려움, 자조, 그리고 자기 직업에 대한 회의. 그러나 시간이 지난 뒤 우리가 미술사에서 만나는 풍경은 다릅니다. 모네, 세잔, 고흐는 사진기가 모방할 수 없는 자리에서 새로운 미술을 열었습니다. 회화의 천장이 한 단계 위로 올라간 것입니다.

AI 앞에 선 우리에게도 같은 가능성이 열려 있다는 것이 그의 결론이었습니다. AI는 패턴에 최적화된 결과를 빠르게 내놓습니다. 그러나 전례가 없는 상황에서 어느 방향으로 나아가야 할지를 판단하고, 무엇이 진정으로 가치 있는지 결정하는 일은 여전히 인간의 몫입니다. 변화의 속도에 패닉하기보다, 자기 분야에서만 닿을 수 있는 천장이 어디인지를 분명히 하고, 그 영역을 끊임없이 넓혀 가는 자세가 답이라는 이야기입니다.

한 가지 덧붙일 만한 것이 있다면, 오랫동안 변두리로 밀려나 있던 인문학적 사고와 비판적 역량이 다시금 무대 중앙으로 돌아오고 있다는 점입니다. 도구가 강해질수록, 도구를 부리는 사람의 분별이 더 중요해집니다. AI 시대에 가장 빨리 진부해질 자세는 모든 트렌드를 따라잡는 자세이고, 가장 늦게 진부해질 자세는 자기 분야의 천장을 견고히 지키며 그 위로 한 발 더 올라가려는 자세입니다.

실리콘밸리의 한가운데에서 일하면서, 음악에서 기술로의 큰 전환을 직접 통과해 본 사람이 우리에게 들려준 이 세 가지 화두는, 한국에서 AI를 도구로 받아들이는 사람들에게도 그대로 닿습니다. 바닥이 어디까지 올라왔는지를 살피는 일은 이미 충분히 많이 했습니다. 이제 천장을 다시 그릴 차례입니다.

지능보다 빠른 것은 에너지, 인터페이스, 그리고 몸이었다. 네 거인은 이제 같은 전쟁을 다른 무기로 치르는 것이 아니라, 네 개의 전혀 다른 전쟁을 동시에 치르고 있다.

안녕하세요. AX 전문교수 김태유입니다.

한때 AI 경쟁의 풍경은 단순했습니다. 누가 더 큰 모델을 만들었느냐. 누구의 벤치마크 점수가 더 높으냐. MMLU 몇 점, HumanEval 통과율, 추론 능력 비교표. 매주 새로 갱신되는 숫자들 위에서 사람들은 순위를 매기고, 그 순위로 한 회사의 미래를 점쳤습니다. 그런데 2026년에 들어서면서 이 게임의 규칙이 빠르게 바뀌고 있습니다.

이제 경쟁의 전선은 "누구의 모델이 더 똑똑한가"가 아니라, "누가 더 많은 와트를, 더 많은 사람의 손에, 실제 몸으로 닿게 하는가"로 이동하고 있습니다. 오픈AI, 구글, 메타, xAI — 네 거인은 이제 서로 다른 지형에서, 서로 다른 무기로 싸우고 있습니다. 겉으로는 같은 전쟁처럼 보이지만, 사실은 네 개의 전혀 다른 전쟁이 동시에 펼쳐지고 있는 것입니다.

오늘은 그 전선의 모양을 세 갈래로 나누어 정리해 보겠습니다. 에너지, 인터페이스, 그리고 몸. 이 세 영역에서 일어나고 있는 변화를 읽어내지 못하면, 앞으로 1~2년의 AI 흐름을 정확히 이해하기 어렵습니다.

지금 AI 경쟁은 두 갈래로 갈라지고 있습니다. 하나는 컴퓨트·전력·데이터센터처럼 물리적 기반을 누가 선점하느냐이고, 다른 하나는 사용자 의도를 누가 가장 정확하게 실행해 실제 경제의 흐름을 통제하느냐입니다. @choi.openai · Threads

01 / 첫 번째 전선에너지 — 모델이 아니라 발전소가 병목이다

메타가 원자력 20년 장기 계약을 체결하고 수백 기가와트급 인프라 조직을 공식화했을 때, 이것은 단순한 전력 확보 소식이 아니었습니다. AI 경쟁의 병목이 반도체에서 에너지로 완전히 옮겨갔다는 패러다임 전환의 선언이었습니다.

2024년까지만 해도 업계의 시선은 GPU에 집중되어 있었습니다. NVIDIA H100과 H200 물량을 누가 더 확보하느냐, TSMC 4나노 공정 캐파를 누가 가져가느냐. 그런데 1년이 채 지나지 않아 이야기가 바뀌었습니다. 칩이 부족한 게 아니라, 그 칩을 돌릴 전기가 부족하다는 사실이 드러난 것입니다.

대형 데이터센터 한 곳이 도시 몇 개 분량의 전력을 먹습니다. 미국에서는 새 AI 데이터센터의 변전 설비 승인이 5년 이상 걸리는 지역도 있고, 송전망 자체가 한계에 부딪힌 주가 늘고 있습니다. 그래서 거인들이 직접 전력 사업에 뛰어들기 시작했습니다. 마이크로소프트는 스리마일섬 원전을 재가동하기로 했고, 구글은 소형모듈원자로(SMR) 회사와 장기 계약을 맺었으며, 메타는 한 발 더 나아가 원자력 20년 계약과 수백 기가와트급 인프라 조직을 직접 만들었습니다.

AI 시대의 진짜 인프라는 GPU가 아니라 발전소다. 도시 몇 개를 먹여 살릴 전력을 안정적으로 확보할 수 있는 기업이, 그 다음 시대의 통제권을 손에 쥔다.

이 변화는 지정학적 의미도 큽니다. 전력 인프라는 하루아침에 짓지 못합니다. 부지 확보, 환경 영향 평가, 송전망 연결, 발전 설비 건설까지 최소 3~7년이 필요한 영역입니다. 지금 계약을 맺은 기업은 2030년대 초반까지의 AI 인프라 우위를 미리 사두는 셈입니다. 한국과 같이 전력망이 이미 빠듯한 국가에서는 이 격차가 더 크게 벌어질 가능성이 있습니다.

02 / 두 번째 전선인터페이스의 소멸 — 사람을 위한 화면이 사라진다

오픈AI의 에이전트 "Operator"가 사용자 대신 항공권을 예약하고, 음식을 주문하고, 일정을 잡기 시작하면 어떤 일이 벌어질까요. 그동안 우리가 당연하게 여겼던 한 가지가 사라집니다. 사용자가 화면을 보며 직접 결정하는 행위 자체가 생략되는 것입니다.

이 변화의 무게는 처음에는 잘 가늠되지 않습니다. 그저 "AI가 대신 클릭해주는 거 아닌가" 정도로 보일 수 있습니다. 그런데 이 단순한 변화 뒤에는 디지털 경제의 토대가 흔들리는 큰 함의가 있습니다.

지난 25년 동안 인터넷 산업은 사람의 눈을 잡아두는 게임이었습니다. SEO로 검색 트래픽을 끌어오고, 광고로 클릭을 유도하고, 정성 들여 다듬은 상품 상세 페이지로 구매를 만들어내는. 그런데 에이전트가 사람 대신 결정한다면, 이 모든 장치는 의미를 잃습니다. 에이전트의 관점에서 우리가 다듬은 카피와 컬러풀한 이미지는 파싱되지 않는 노이즈일 뿐입니다.

마케팅의 대상이 인간에서 AI로 바뀌는 순간, 게임의 룰 전체가 다시 쓰입니다.

이미 일부 영역에서는 변화의 신호가 보입니다. "AI를 위한 SEO"라는 새 카테고리가 등장했고, 상품 데이터를 사람이 아니라 에이전트가 읽도록 구조화하는 방법론이 논의되기 시작했습니다. e커머스 업체들은 자사 카탈로그를 어떻게 노출시킬지 고민하던 자리에, "어떻게 AI 에이전트가 우리 상품을 추천하게 만들 것인가"라는 새로운 질문을 추가했습니다. 검색의 시대가 지나가고, 위임의 시대가 자리를 잡으면, 클릭과 노출 중심의 디지털 경제 모델은 근본부터 재설계되어야 합니다.

03 / 세 번째 전선몸 — 화면 밖으로 나오는 AI

1X의 NEO 로봇이 2만 달러($20,000)에 예약 판매를 시작했습니다. 숫자만 보면 아직 비쌉니다. 그러나 의미를 생각하면, 이것은 휴머노이드 로봇이 처음으로 소비자 가격대로 내려왔다는 신호입니다. Tesla Optimus, Figure, Apptronik 같은 회사들도 비슷한 가격대를 노리며 빠르게 따라오고 있습니다.

"몸을 가진 AI" — 영어로 Embodied AI라 부르는 이 영역은, 챗봇과는 전혀 다른 종류의 도전입니다. LLM은 텍스트라는 매끈한 세계 안에서 작동합니다. 그러나 거실 바닥의 카펫, 식탁 위의 컵, 옷가지가 흩어진 의자 — 이런 무한히 복잡한 물리적 환경에서 손을 움직이고, 균형을 잡고, 사물을 인식하는 일은 차원이 다른 문제입니다. 이 문제를 푸는 데 자연계의 진화가 수억 년을 썼습니다.

최근 몇 년간 두 흐름이 동시에 진전했습니다. 하나는 시뮬레이션을 통한 학습. 가상 환경에서 수백만 번 넘어지고 일어서면서 익히는 방식입니다. 다른 하나는 자연을 모방한 하드웨어 — 인공 근육, 가변 강성 관절, 부드러운 손가락 같은 생체모방(biomimicry) 설계. 두 흐름이 합쳐지면서 휴머노이드는 데모 영상의 눈속임을 넘어, 실제 환경에서 의미 있는 작업을 수행하는 단계로 들어섰습니다.

AI는 화면 속 텍스트에서 거실 안의 물리적 존재로 빠르게 변신하고 있습니다.

현대차 그룹이 CES 2026에서 "더 이상 자동차 제조사가 아닌 AI 플랫폼 기업"임을 선언하고, Atlas 휴머노이드를 2030년까지 조립 라인에 배치하겠다고 발표한 맥락도 같은 흐름입니다. 산업 자동화 → 가정용 로봇 → 일상 동반자로 이어지는 사다리가, 우리가 막연히 미래라고 부르던 시점보다 훨씬 빨리 펼쳐지고 있습니다.

04 / 한 줄로 보기세 전선이 가리키는 한 방향

세 가지 전선을 한 표 안에 정리해 보면, 변화의 방향이 더 분명해집니다.

세 전선은 따로 흐르는 듯 보이지만, 사실 같은 한 방향을 가리킵니다. AI는 더 이상 도구가 아니라 인프라입니다. 전기처럼, 도로처럼, 누군가 깔아놓은 인프라 위에서 모두가 살아가게 될 기반으로 자리잡고 있습니다. 그리고 그 인프라를 누가 장악하느냐의 싸움이 바로 2026년의 진짜 AI 전쟁입니다.

05 / 수렴점포스트 스마트폰, 그리고 커즈와일의 무릎

이 모든 전선을 하나로 수렴시키는 상징적 사건이 가까이 와 있습니다. 오픈AI와 조니 아이브의 협업이 예고하는 "포스트 스마트폰" 디바이스. 스크린이 사라진 자리에 어떤 형태가 들어설지는 아직 정해지지 않았지만, 한 가지는 분명합니다. "기계가 인간을 이해하는 첫 번째 도구"가 진짜로 만들어진다면, 우리가 지금 상상하는 AI의 모습은 또 한 번 근본적으로 바뀌게 됩니다.

20년 전 아이폰이 나왔을 때, 사람들은 그것을 "전화기와 인터넷이 합쳐진 기기"로 이해했습니다. 그러나 시간이 흐른 뒤 우리는 알게 됐습니다. 그것은 단순한 기기가 아니라 디지털 경제의 새 좌표축이었다는 것을. 지금 우리가 기다리는 그 디바이스도, 비슷한 자리에 놓이게 될 가능성이 큽니다.

2026년은 기술 발전 그래프가 수직으로 솟구치는 무릎이 될 것이다. 레이 커즈와일

커즈와일이 이 표현을 처음 썼을 때만 해도 많은 이들이 은유로 받아들였습니다. 그러나 에너지·인터페이스·몸이라는 세 전선에서 동시에 일어나고 있는 일들을 옆에 놓고 보면, 이 문장은 점점 은유가 아니라 실제 기술 지형도의 묘사처럼 느껴집니다.

지금 우리가 목격하고 있는 것은 단순한 AI 경쟁이 아닙니다. 더 좋은 모델이 다른 모델을 추월하는 그런 종류의 일이 아닙니다. 새로운 문명 인프라의 초기 설계전입니다. 누가 그 인프라의 표준이 될 것인지, 누가 그 위에서 살아가는 사람들의 일상을 정의할 것인지를 결정하는 싸움이 지금 막 시작된 것입니다.

이 변화 앞에서 한 가지 자세가 점점 더 중요해집니다. 모델 벤치마크 한두 개의 상승보다, 인프라의 어느 층이 누구의 손에 쥐어지고 있는지를 읽는 일. 그리고 그 인프라 위에 우리 조직과 우리 일이 어떻게 얹힐지를 미리 그려보는 일. 2026년은 그 그림을 다시 그릴 마지막 좋은 기회일지도 모릅니다.

맥킨지·PwC·BCG·가트너가 2026년 1분기에 쏟아낸 리서치는 같은 결론으로 수렴한다. 실험의 해는 끝났고, 결산이 시작됐다. 누가 이기고 누가 비용만 치르는가.

AI를 도입하지 않은 기업을 찾기가 오히려 어려워졌다. 그런데 AI로 이익을 본 기업을 찾기는 여전히 어렵다. 이 두 문장이 2026년의 기업 AI 현황을 가장 짧게 요약한다. 맥킨지가 2025년 11월 발표한 『2025 AI 현황』(105개국 1,993명 조사)에 따르면 기업의 88%가 최소 하나의 사업 부문에서 AI를 쓰고 있다. 그런데 AI가 영업이익(EBIT)의 5% 이상을 만들어낸 "AI 고성과 기업"은 6%에 불과하다. PwC가 2026년 1월 발표한 제29차 글로벌 CEO 서베이(4,454명)는 이 격차를 더 날카롭게 잘라 보여준다.

PwC 조사에서 비용 절감과 매출 증대 양쪽 모두에서 AI 효과를 봤다고 답한 CEO는 12%에 불과했다. 반면 56%는 AI에서 어떤 재무 효과도 보지 못했다고 답했다. 제품과 고객 경험에 AI를 폭넓게 적용한 기업은 동종 업계 대비 이익률이 약 4%p 높았다. 이 4%p가 지금의 승자와 패자를 가르는 경계다. 그리고 그 경계가 2026년 1~4월 90일 동안 컨설팅 보고서와 실적 발표, 그리고 한국 기업의 공시를 통해 뚜렷해졌다.

01 / 전환점2026년은 결산의 해 — 전문가들이 한목소리로 말한 것

1분기에 주요 리서치 기관들은 거의 같은 문장을 내놓았다. 실험의 시간이 끝났다는 것이다. 가트너의 크리스 반 리퍼는 2026 CIO 서베이를 발표하며 이렇게 말했다.

2025년은 AI 파일럿과 탐색, 실험의 해였다. 2026년은 에이전틱 AI의 ROI를 실제로 만들어내는 해가 될 것이다. Kris van Riper, Gartner · 2026 CIO Survey

전 세계 CIO의 89%가 2026년 AI 지출을 늘릴 계획이고, 글로벌 AI 지출은 2026년 2조 달러를 돌파해 전체 IT 지출의 약 3분의 1을 차지할 전망이다. 반대 방향의 경고도 있다. 포레스터의 2026 예측은 "AI의 과열이 식으면서 기업들이 계획된 AI 지출의 25%를 2027년으로 미룰 것"이라며, "의사결정자 중 AI 가치를 조직의 재무 성장과 연결할 수 있는 사람은 3분의 1도 안 된다"고 지적했다. MIT Sloan의 Thomas Davenport와 Randy Bean이 이 분위기를 가장 간결하게 정리했다.

2025년이 생성형 AI의 가치 실현 문제를 깨달은 해였다면, 2026년은 그 문제에 대해 뭔가를 하는 해가 될 것이다. Thomas Davenport & Randy Bean, MIT Sloan

경고에도 불구하고 투자는 오히려 가속된다. BCG AI Radar 2026(임원 2,360명·CEO 640명 조사)에 따르면 기업들은 2026년 AI 지출을 두 배로 늘려 매출의 약 1.7% 수준으로 끌어올리고, CEO의 94%는 1년 내 투자 회수가 되지 않더라도 AI 투자를 계속하겠다고 답했다. Stanford HAI의 『2026 AI Index』는 2025년 글로벌 기업 AI 투자가 5,817억 달러로 전년 대비 130% 증가했다고 기록했다.

02 / 결정적 증거이번 분기, 가장 강력한 증거는 월스트리트에서 나왔다

컨설팅 보고서는 흔히 수사로 흐른다. 그런데 2026년 1분기는 달랐다. 수사가 아니라 실적 발표에서 증거가 나왔다. 뉴욕타임스 Rob Copeland 기자가 4월 21일 보도한 바에 따르면, JPMorgan·Citi·Bank of America·Goldman Sachs·Morgan Stanley·Wells Fargo 등 월스트리트 6대 은행은 2026년 1분기에 합계 470억 달러 이익을 냈고(전년 대비 18% 증가), 동시에 1만 5천 명을 감원했다. 여섯 은행 모두 인력 감축의 근거로 AI를 들었다.

특히 주목할 발언은 Bank of America의 Brian Moynihan CEO다. 2025년 12월까지만 해도 그는 "AI로 감원할 걱정은 없다"는 입장이었다. 그런데 2026년 1분기 실적 발표 후 태도가 완전히 바뀌었다.

업무를 없애는 것과 기술을 적용하는 것. 그것이 이번 분기 개선의 원인이다. AI는 우리가 가본 적 없는 곳까지 데려가 준다. Brian Moynihan, Bank of America CEO

기업이 "AI로 일자리 줄일 계획 없다"에서 "AI로 여기까지 왔다"로 공개적으로 선회하는 데 넉 달이 걸렸다는 뜻이다. 이 속도가 지금의 분위기다.

03 / 비용 절감10~30%라는 구간의 비밀

이번 분기 가장 많이 인용된 비용 절감 벤치마크는 좁은 구간에 몰려 있다. 맥킨지의 『State of AI 2025』는 소프트웨어 엔지니어링과 IT 부문에서 10~20% 비용 감소를 보고한다. 그런데 여기에 베인의 Chuck Whitten이 결정적인 뉘앙스를 덧붙였다. 같은 AI를 써도 결과는 두 배 차이가 난다는 것이다.

같은 기술을 썼는데 왜 두 배 차이가 날까. Whitten의 답이 이번 분기에 가장 인용 가치가 높다.

우리 고객 성공 사례에서, 데이터·프로세스·변화관리가 아마 3분의 2이고, 기술이 3분의 1이다. Chuck Whitten, Bain & Company

이 공식은 AI 프로젝트 예산을 짜는 기업에게 그대로 뒤집힌 시사점을 준다. 대부분 기업은 정확히 반대로 예산을 편성한다. 기술에 3분의 2, 데이터·프로세스·변화관리에 3분의 1. 같은 기술을 써도 결과가 두 배 차이 나는 이유가 여기에 있다.

은행 바깥에서도 구체적인 숫자가 쏟아졌다. Snap은 약 1,000명 감원을 통해 2026년 하반기까지 5억 달러 이상 절감을 전망했다. Evan Spiegel CEO는 "AI 발전으로 반복 작업의 자동화가 가능해졌다"고 설명했다. Angi Inc.는 350명 감원으로 연 7,000만~8,000만 달러 절감을 발표했다. P&G의 Andre Schulten CFO는 Morgan Stanley 컨퍼런스에서 공급망 AI가 "당분간 20억 달러 생산성 향상의 여지"를 만들어냈다고 말했다. Nestlé의 AI 기반 컨셉 생성기는 1,300개 제품을 만들어내며 신제품 개발 기간을 3개월에서 3주로 단축했다. 디지털 트윈 마케팅은 비용 55%, 시간 65%를 줄였다.

04 / 매출의 벽매출 증가는 왜 이렇게 어려운가

Deloitte가 1월 다보스에서 발표한 『State of AI in the Enterprise』(24개국 3,235명 조사)는 가장 중요한 비대칭을 드러냈다.

74%가 매출 증가를 목표로 삼았는데 실제로 달성한 곳은 20%밖에 안 된다. 이 3배의 격차가 바로 이번 분기 모든 CEO가 몰래 들여다보는 숫자다. 왜 매출은 비용보다 어려울까. 비용 절감은 내부 프로세스 개선으로 끝나지만, 매출 증가는 고객 경험·상품 설계·영업 모델 전체가 함께 움직여야 하기 때문이다. 운영 모델과 상업적 역량을 훨씬 더 깊게 건드린다.

그래서 매출 성과를 내는 곳은 소수지만, 그 소수는 수치가 매우 뚜렷하다. 맥킨지는 마케팅과 제품 개발에서 10% 이상의 매출 상승이 나타났다고 보고한다. Stanford HAI 2026 AI Index는 매출 증대 상위 기능으로 마케팅·세일즈(67%), 전략·기업재무(65%), 제품 개발(62%)을 꼽았다.

가장 명확한 엔터프라이즈 소프트웨어 증거는 ServiceNow의 1분기 실적에서 나왔다. Bill McDermott CEO는 2026년 AI 매출 목표를 상향하며 이렇게 말했다.

15억 달러를 훌쩍 넘길 것이다. 5억 달러 이상을 추가로 올려야 한다. 비현실적일 정도다. Bill McDermott, ServiceNow CEO

Now Assist의 연간 계약액 100만 달러 이상 고객이 전년 대비 130% 이상 증가했고, 500만 달러 이상 대형 딜만 16건이 체결됐다. Accenture의 1분기 실적에서는 고급 AI 수주가 1년 만에 12억 달러에서 22억 달러로 거의 두 배가 됐다. Julie Sweet CEO는 "고급 AI가 우리가 하는 거의 모든 일에 내재화되는 지점에 도달했다"고 선언했다.

소비자 서비스에서는 Duolingo의 스토리가 가장 선명하다. Luis von Ahn CEO의 말이다.

같은 인원으로 같은 시간에 4~5배의 콘텐츠를 만들 수 있다. 목표는 돈을 아끼는 것이 아니다. 사람을 대체하는 것도 아니다. 훨씬 더 많은 일을 하는 것이다. Luis von Ahn, Duolingo CEO

Duolingo는 AI로 1년 만에 148개 언어 코스를 만들었다. 지난 12년간 만든 것보다 많은 수다. 2025년 매출 가이던스는 10억 2천만 달러로 상향 조정됐다. 핵심은 "같은 인원으로 더 많이"다. 감원이 아니라 증폭이다.

05 / 생산성시간 단위로 측정되는 증폭 효과

생산성 증거는 구체적이고 인용 가능한 수치로 굳어졌다. Stanford HAI 2026 AI Index는 분야별로 이렇게 정리한다. 고객 지원 14~15%, 소프트웨어 개발 26%, 마케팅 산출물 73% 증가. 그러나 "깊은 추론을 요하는 업무에서는 증가폭이 작으며, 과도한 AI 의존이 장기적 학습 페널티를 동반할 수 있다"는 경고도 함께 붙였다.

Microsoft의 1분기 실적 발표(2025년 10월 29일)는 가장 많이 인용되는 구체 사례를 쏟아냈다. Satya Nadella CEO는 Microsoft AI 기능 월간 활성 사용자 9억 명과 1st-party Copilot 월간 활성 사용자 1억 5천만 명 이상을 공개했다.

직원 수준에서도 시간이 선명하게 측정된다. BCG의 AI at Work 2025 연구(11개국 10,635명 조사)는 생성형 AI 정기 사용자의 58%가 주당 5시간 이상 절감을 보고한다고 밝혔다. 핵심 조건은 교육이었다. 최소 5시간의 AI 교육을 받은 직원의 정기 사용률이 유의미하게 높았다. 이 숫자가 의미하는 바는 뚜렷하다. 라이선스만 뿌리고 교육을 건너뛰면 ROI는 오지 않는다.

Anthropic의 Economic Index(2026년 1월·3월 리포트)는 200만 건 대화 분석을 통해 약 49%의 직업에서 최소 4분의 1의 업무가 Claude로 수행된 적이 있다고 결론지었다. 엔터프라이즈 API 사용은 75%가 자동화(사람이 시키고 AI가 실행)인 반면, Claude.ai 일반 사용은 52%가 증강(사람이 AI와 함께 작업)이었다. 기업용 환경에서는 AI가 대신 해주는 비중이 더 크고, 개인용 환경에서는 함께 하는 비중이 더 크다는 뜻이다.

06 / 한국의 기울기도입은 세계 최고 속도, 실행은 고르지 않다

한국의 헤드라인 수치는 세계에서 가장 빠른 도입 속도를 시사한다. 한국은행의 2025년 8월 이슈노트 2025-22(올해의 기준 보고서)는 이렇게 밝혔다.

한국 헤비 유저(하루 60분 이상)는 일일 사용자의 78.6%로, 미국의 31.8%를 압도한다. 한국은행의 거시 시뮬레이션은 "AI 도입이 한국 생산성을 1.1~3.2%, GDP를 4.2~12.6% 끌어올려 고령화와 노동 공급 감소에서 오는 성장 둔화를 상당 부분 상쇄할 수 있다"는 결론이었다.

개인 확산과 기업 확산이 다른 속도로 움직이는 것도 특징이다. 과기정통부의 2025 인터넷이용실태조사(2026년 3월 발표, 50,750명 대상)는 전체 인구의 44.5%가 생성형 AI를 사용해봤고, 사무직은 71.9%에 달한다고 밝혔다. 1년 전 33.3%에서 11.2%p 상승이다. 기업 쪽은 메가존클라우드·IDG 조사(749명)에서 확인된다. 한국 기업의 55.7%가 생성형 AI를 사용 중이며(전사 22.4% + 일부 부서 33.2%), 2026년에는 85%를 돌파할 전망이다. 대기업 전사 도입률은 35.1%로 중소기업의 두 배 이상이다.

실제 사례도 이번 분기에 가시화됐다. 한국은행의 BOKI(2026년 1월 21일 론칭)는 중앙은행 최초의 소버린 AI로, 네이버 HyperClova X 위에서 140만 건의 내부 문서를 학습했다. 이창용 총재의 발언이 협회 리포트에 인용하기 좋다.

한국은행이 소버린 AI 구축과 망 개선을 동시에 추진하는 최초 기관이자, 망분리 정책 변화를 시도하는 첫 번째 공공기관이 됐다. 업무 효율성이 제고될 뿐 아니라, 조직 문화 전반에도 상당한 변화가 뒤따를 것이다. 이창용, 한국은행 총재

기업 쪽에서는 LG전자 한국영업본부가 가장 날카로운 국내 수치를 내놓았다. ChatInsight라는 에이전틱 AI 시스템이 데이터 분석 업무를 3일에서 30분으로, 288배 단축했다. 선형적·반응적 워크플로를 병렬적·능동적 전략 수립으로 전환한 사례다. 삼성SDS는 4월 컨퍼런스에서 80분 업무를 10분으로 단축(8배), 한 은행 레거시 현대화 프로젝트에서 코드 변환 성공률 98.8%, 개발 비용 68% 감소를 발표했다. 2031년까지 AI 및 관련 M&A에 10조 원 투자 계획도 공개했다.

조직 문화 관점에서 주목할 곳은 현대카드다. 정태영 부회장이 직접 LLM 교육에 참석했고, 드물게도 실무자보다 리더를 먼저 LLM 실습에 투입하기로 결정했다. "생성형 AI는 도입 여부가 아니라 조직에 얼마나 깊게 뿌리 내리느냐가 경쟁력을 좌우한다"는 것이 회사 내부 입장이다. KB금융은 3년간 39개 업무영역에 AI 에이전트 250개 이상을 단계 배치하고, 8개 계열사를 KB GenAI 포털로 통합한다. LG CNS AI센터장 진요한이 한 문장을 남겼다.

지난 1년의 변화가 그 이전 20년보다 더 컸다. 진요한, LG CNS AI센터장

07 / 교훈경영진을 위한 다섯 가지 교훈

2026년 1분기부터 4월까지의 90일. 이 창구에서 나온 다섯 가지 교훈을 정리하면 이렇다.

• 교훈 1도구 배포가 아니라 워크플로 재설계가 결정적 레버다. 맥킨지는 25개 조직 속성 중 워크플로 재설계가 EBIT 임팩트에 가장 큰 영향을 준다고 밝혔지만, 실제로 근본적 재설계를 한 기업은 21%에 불과하다. Bain의 공식 — 기술 3분의 1, 데이터·프로세스·변화관리 3분의 2 — 이 예산 편성의 기준점이 되어야 한다.
• 교훈 2비용-매출 격차는 경고음이다. 생산성 66% vs 매출 20%(Deloitte), 양방향 혜택 CEO 12% vs 무혜택 56%(PwC), AI가 유의미한 성과를 낸다는 응답 64% vs ROI를 확립한 8%(KPMG). 세 기관이 같은 메시지를 보낸다. 비용 이익은 빨리 쌓이지만 성장 이익은 운영 모델과 상업적 작업을 훨씬 더 많이 요구한다.
• 교훈 3에이전틱 AI는 2026년의 격전지이지만 거버넌스가 배치를 따라잡지 못하고 있다. 에이전트 배치율은 기업의 33~52%, 기술 임원 64%가 24개월 내 배치 예정이지만, 성숙한 거버넌스 모델을 가진 조직은 21%에 불과하다. KPMG는 63%가 AI 에이전트 출력에 인간 검증을 요구한다고 보고했다. 1년 전 22%에서 세 배 가까이 올랐다. 배치를 앞지른 기업은 섀도우 AI 데이터 유출 문제를 겪고 있다.
• 교훈 4한국의 도입 심도는 독특한 경쟁 창구다. 근로자 63.5% 침투율(미국의 약 2배), 기업 79%가 예산 증액 계획. 운영 모델 재설계 단계를 먼저 완료한 한국 기업이 큰 이득을 포착할 가능성이 높다. LG전자의 288배 분석 가속화와 삼성SDS의 8배 업무 압축이 초기 증거다. 구광모 회장의 "완벽한 계획보다 빠른 실행이 중요하다"는 지침이 올바른 자세다.
• 교훈 5전략과 무관하게 문화 전환은 이미 도착하고 있다. Microsoft가 명명한 Frontier Firm, HBR의 "AI는 업무를 강화한다"는 반론, Walmart 대 Salesforce의 인력 처우 분기점. 모두 일하는 방식의 진짜 재조직화를 가리키는 표지다. AI를 문화 변화로 다루는 임원들(리더 직접 교육, 인력 교육 투자, 워크플로 오너십 명확화)이 고성과자 집단에 남는다.

08 / 맺으며결산은 이미 진행 중이다

이번 90일의 리서치가 일관되게 보내는 메시지는 하나다. 질문이 바뀌었다는 것이다. 2024~2025년까지 CEO들은 "AI가 진짜 되는가"를 물었다. 2026년 1분기부터는 "누가 가치를 포착하고 있는가"를 묻는다. 전자는 기술에 대한 질문이었고, 후자는 경영에 대한 질문이다.

88%의 기업이 AI를 쓰는데 6%만 이익을 본다는 사실을 경영 격차로 읽어야 한다. 그 격차는 모델의 성능이나 예산의 크기가 아니라, 일을 설계하는 방식, 데이터를 다루는 습관, 그리고 조직이 변화에 얼마나 열려 있는가에서 갈린다. 베인의 Whitten이 말한 "기술은 3분의 1, 나머지는 데이터·프로세스·변화관리"는 2026년 내내 인용될 문장이다. MIT Sloan이 말한 "뭔가를 하는 해"가 시작됐다.

월스트리트 6대 은행이 넉 달 사이 입장을 바꾼 것, 맥킨지·Deloitte·BCG·KPMG가 같은 결론으로 수렴한 것, 한국은행과 LG전자·삼성SDS가 나란히 구체 수치를 공개한 것. 이 모든 장면이 한 방향을 가리킨다. 결산은 2027년에 오는 것이 아니다. 이미 2026년 4월의 실적 발표장에서 진행되고 있다.

의견·자문 문의 sjshin@cdsa.or.kr

AI를 '네이버'나 '구글'처럼 다루고 있다면, 지금부터 접근 방식을 완전히 바꿔야 한다. 검색이 아니라 위임이다.

1986년 4월, 미국 사우스캐롤라이나주 섬터(Sumter)에서 흥미로운 사건이 벌어졌다. 초등학교 수학 교사들이 피켓을 들고 거리로 나선 것이다. 그들의 주장은 이랬다. "계산기를 너무 일찍 쓰게 하면, 아이들이 수학 개념을 배우지 못한다." 피켓에는 "OFF UNTIL UPPER GRADES"라고 적혀 있었다. 고학년이 될 때까지는 계산기를 꺼 두라는 요구였다.

지금 돌이켜보면 어떤가. 그 우려는 기우였다. 덧셈, 뺄셈, 곱셈, 나눗셈을 손으로 계산하는 것 자체가 수학의 목적은 아니었다. 처음 개념을 익힐 때야 필요하겠지만, 그것은 수단이지 목적이 아니다. 오히려 단순 계산을 계산기에 맡기면서 사람은 더 복잡한 수학적 사고에 집중할 수 있게 되었다. 계산기 도입 이후 수학 교육의 수준은 낮아지기는커녕 올라갔다.

지금 AI 앞에서 우리가 서 있는 자리가 바로 그때 그 교사들이 서 있던 자리다.

01 / 사라진 기술들주산반, 타자연습, 그리고 지금 우리의 업무

기억을 조금 더 거슬러 올라가 보자. 한때 학교마다 주산반이 있었다. 주판 위에서 구슬을 튕기며 암산 속도를 겨루던 시절이다. 주산 자격증은 취업에도 쓸모가 있었다. 지금 주산을 가르치는 학교는 없다. 계산기가, 그리고 스프레드시트가 그 자리를 대신했기 때문이다.

한컴 타자연습의 추억도 떠오른다. 그 산성비 게임을 하며 자판 위치를 외우던 시절. 타자 속도가 곧 업무 능력이라 여겨지던 때가 있었다. 지금 타자연습을 하는 사람은 없다. 타자는 누구나 일정 수준 이상 치게 되었고, 타자 속도가 업무의 병목이 되는 경우는 사라졌다.

이 사례들이 말해 주는 것은 단순하다. 도구가 바뀌면, 사람이 직접 해야 할 일의 범위가 바뀐다. 더 잘하는 존재에게 넘길 수 있는 일은 넘기고, 사람은 사람만이 할 수 있는 영역으로 이동한다. 이것이 도구의 역사이고, 일의 역사다.

지금 우리가 책상 위에서 하는 일들 중 상당수가, 2~3년 뒤에는 주산이나 타자연습과 같은 위치에 놓이게 될 것이다. 문제는 우리가 그 사실을 아직 체감하지 못하고 있다는 것이다.

02 / 검색의 한계AI를 검색 엔진처럼 쓰고 있지 않은가

많은 분들이 AI를 도입하고 나서 이렇게 말씀하신다. "써 보긴 했는데, 기대만큼 빨라지진 않더라고요." ChatGPT나 Claude를 열어 보지만, 결과를 받아들고 나면 결국 다시 직접 고치고, 다시 정리하고, 다시 검색한다.

원인은 간단하다. AI를 검색 엔진처럼 쓰고 있기 때문이다.

검색 엔진은 30년간 우리의 정보 습득 방식을 지배해 온 도구다. 키워드를 넣고, 링크를 받고, 직접 읽고, 직접 요약한다. 이 패턴이 너무 익숙한 나머지 AI 앞에서도 같은 행동을 반복하게 된다. "이거 알려줘", "저거 찾아줘", "요약해 줘." 이렇게 쓰면 AI는 조금 빠른 검색 엔진, 조금 깔끔한 요약기에 그칠 뿐이다.

하지만 AI는 검색 엔진이 아니다. AI는 일을 맡길 수 있는 존재다. 검색이 아니라 위임이다. 이 구분을 이해하는 순간, 모든 것이 달라진다.

03 / 검색 vs 위임질문 한 줄이 만드는 결정적 차이

같은 업무를 두고 검색하는 사람과 위임하는 사람의 차이를 보자.

검색하는 사람은 AI에게 "뭘 알고 싶어?"라고 묻는다. 위임하는 사람은 "뭘 해야 해?"라고 묻는다. 전자는 정보의 위치를 물어보는 것이고, 후자는 일을 맡기는 것이다. 질문 한 줄의 차이지만, 그 뒤에 이어지는 업무 흐름은 완전히 다르다.

위로 갈수록 AI는 "검색 도구"에서 "업무를 위임받는 파트너"에 가까워진다. 핵심은 단순하다. 내가 최종적으로 원하는 결과물의 형태를 처음부터 말해 주는 것. 그것이 위임이다.

04 / 실전 패턴검색하는 습관을 위임하는 습관으로

원리를 알았으니 실전으로 옮겨 보자. 일상 업무에서 자주 마주치는 네 가지 상황을 나란히 놓아 본다.

상황 1: 회의 준비

상황 2: 데이터 분석

상황 3: 문서 작성

상황 4: 민원 응대

패턴이 보이실 것이다. 위임형 질문에는 세 가지 요소가 들어간다. 맥락(어떤 상황인지), 관점(어떤 기준으로 판단할지), 그리고 결과물의 형태(어떤 모양으로 받고 싶은지). 이 세 가지를 넣어 주는 순간, AI의 출력은 극적으로 달라진다. 그리고 이 세 가지를 설정할 수 있는 건 오직 그 업무를 아는 사람뿐이다.

05 / 어리석은 경쟁AI가 더 잘하는 일에서 겨루지 마라

여기서 한 걸음 더 나아가 보자. 검색을 위임으로 바꾸는 것은 AI를 잘 쓰는 기법의 문제처럼 보이지만, 사실은 훨씬 깊은 질문과 맞닿아 있다. 지금 내가 하고 있는 일이, 앞으로도 내가 해야 할 일인가?

혹시 지금 우리가 2년 뒤에는 사라질 업무, 사라질 기능에 대해 AI와 경쟁하고 있지는 않은가. 없어질 일을 더 잘하려고 매달리고 있지는 않은가. 역사는 이런 어리석은 경쟁의 사례로 가득하다. 자동 직조기가 등장한 뒤에도 수직 기술의 우수성을 주장하며 버텼던 장인들, 자동차가 나온 뒤에도 마차의 효율을 논하던 마부들. 그들의 기술이 나빴던 게 아니다. 경쟁하는 전장 자체가 바뀌고 있었는데, 같은 전장에 서 있으려 했던 것이 문제였다.

나보다 더 잘하는 존재가 나타났는데 그 일을 계속 내가 하겠다고 고집하는 것은 어리석다. 과감히 위임하고, 내가 더 잘하는 영역으로 옮겨 가야 한다. 그것이 AI와 더불어 살아가야 할 세상을 준비하는 자세다.

AI가 더 잘하는 일에서 경쟁하면 결과는 뻔하다. 전장을 바꿔야 한다. AI에게 위임하고, 인간은 설계하고 판단하는 역할로 이동해야 한다.

06 / 설계와 위임AI 시대에 사람이 해야 할 진짜 일

그렇다면 위임하고 난 뒤, 사람의 자리는 어디인가. 답은 명확하다. 설계하고, 위임하고, 판단하는 자리다.

AI가 아무리 강력해져도 스스로 할 수 없는 일이 있다. 무엇을 해야 할지 결정하는 일이다. 어떤 문제가 중요한지 판단하고, 어떤 관점에서 접근할지 결정하고, 결과물이 충분한 수준인지 평가하고, 이 결과를 어떤 맥락으로 누구에게 전달할지 설계하는 일. 이 모든 것은 사람의 고유 영역이다.

• 업무 설계내가 하는 일의 전체 구조를 파악한다. 어떤 부분이 반복적이고, 어떤 부분이 판단을 요하는지를 구분한다. 반복적인 것은 위임 대상이다.
• 위임 결정AI에게 맡길 수 있는 일을 식별한다. 정보 수집, 초안 작성, 데이터 정리, 양식 변환 — 이런 일들은 과감히 넘긴다.
• 맥락 설정같은 데이터도 어떤 맥락에서 보느냐에 따라 전혀 다른 결론이 나온다. 맥락을 설정하는 일은 현장을 아는 사람만이 할 수 있다.
• 품질 판단AI의 결과물이 "충분히 좋은지"를 판단하는 기준은 사람이 정한다. 이 기준은 해당 업무에 대한 깊은 이해에서 나온다.
• 연결과 소통결과물을 조직 안에서 전달하고, 피드백을 받고, 다음 행동으로 이어가는 일. 업무의 마지막 1마일은 늘 사람의 판단과 소통으로 완성된다.

내 일을 설계할 수 있어야 한다. 그리고 위임할 것을 찾아야 한다. 이것이 AI를 잘 쓰는 방식이다. 이것이 생존법이자, 나와 내가 속한 조직의 경쟁력을 높이는 지름길이다.

07 / 마무리검색을 멈추고, 위임을 시작하기

다시 1986년의 섬터로 돌아가 보자. 피켓을 든 수학 교사들은 진심이었다. 아이들이 수학적 사고를 잃을까 봐 걱정했던 것이다. 하지만 결과는 정반대였다. 단순 계산을 계산기에 위임한 뒤, 사람은 수학의 더 깊은 곳으로 들어갈 수 있었다. 주산이 사라진 자리에 통계학과 데이터 과학이 들어섰다. 타자연습이 사라진 자리에 문서 설계와 콘텐츠 기획이 들어섰다.

AI 앞에서도 같은 일이 벌어지고 있다. 정보를 찾고, 문서를 정리하고, 데이터를 요약하고, 양식을 맞추는 일 — 이 모든 것은 위임의 대상이다. 이것들을 직접 하겠다고 버티는 것은 계산기 앞에서 손으로 곱셈하겠다고 고집하는 것과 다르지 않다.

검색이 아니라 위임이다. AI 앞에서 키워드를 던지는 대신, 맥락을 설명하고, 관점을 지정하고, 원하는 결과물의 형태를 말해 주는 것. 그 전환이 일어나는 순간 AI는 조금 빠른 검색 도구에서 업무를 함께 굴리는 파트너로 바뀐다. 그리고 사람은 실행자에서 설계자로 이동한다.

명심하라. 생각보다 더 빨리 움직여야 한다. 지금 우리가 매일 반복하는 업무 중 상당수가, 몇 년 뒤에는 타자연습만큼이나 낯선 것이 될 수 있다. 그때 가서 움직이면 이미 늦다. 지금 당장, 내 업무를 펼쳐 놓고 자문해 보시라. "이 중에서 AI에게 위임할 수 있는 것은 무엇인가? 그리고 위임한 뒤, 나는 무엇에 집중해야 하는가?"

그 질문이 AI 시대를 살아가는 출발점이다. 그리고 그 출발이 빠른 사람과 느린 사람의 차이는, 생각보다 훨씬 빠르게 벌어지고 있다.

"한 번에 답하라"는 습관이 사람에게도 모델에게도 가장 큰 병목이다. 문제를 쪼개고, 순서를 밟고, 중간 결과를 점검하는 일 — 그 평범한 절차가 결과의 질을 결정적으로 바꾼다.

누군가에게 복잡한 질문을 던졌을 때, "잠깐만, 정리해 볼게"라고 말하는 사람과 곧바로 답부터 내뱉는 사람 중 누구의 답이 더 신뢰가 갈까. 대부분은 전자를 고를 것이다. 한 박자 멈추고, 머릿속에서 순서를 세우고, 빠진 조건이 없는지 되짚은 뒤에 나오는 답은 직감적인 답과 질적으로 다르다. 이건 경험이지, 이론이 아니다.

흥미로운 사실은 대형 언어 모델(LLM)에게도 정확히 같은 원리가 작동한다는 것이다. 2022년, 도쿄대학교의 Kojima 등은 프롬프트 끝에 딱 한 문장을 덧붙였다. "Let's think step by step." 그 한 문장만으로 산술 문제의 정답률이 17.7%에서 78.7%로 뛰었다. 모델이 달라진 것이 아니다. 같은 모델에게 "천천히 단계를 밟으라"고 말해 줬을 뿐이다.

이 글은 그 현상을 좀 더 깊이 들여다보려는 기록이다. 단계별 사고가 왜 사람에게 효과적인지, AI에게는 어떤 메커니즘으로 작동하는지, 그리고 실무에서 이 원리를 어떻게 설계에 녹여야 하는지를 풀어 보려 한다.

01 / 인간의 뇌쪼개야 풀린다 — 인지과학이 말하는 것

MIT의 인지과학 연구팀은 인간이 복잡한 문제를 푸는 방식을 오랫동안 관찰해 왔다. 결론은 의외로 단순하다. 사람은 문제를 관리 가능한 하위 과제로 쪼갤 때 가장 잘 푼다. 커피 한 잔을 사러 가는 일조차 우리 뇌는 세 단계로 나눈다. 건물 밖으로 나가기, 카페까지 이동하기, 카페에서 커피 받기. 만약 엘리베이터가 고장 났다면? 첫 번째 단계만 수정하면 된다. 나머지 두 단계는 건드릴 필요가 없다.

이 전략이 강력한 이유는 작업 기억(working memory)의 한계와 관련이 있다. 인간의 작업 기억은 한 번에 7±2개의 항목만 다룰 수 있다는 것이 정설이다. 열 가지 조건을 동시에 고려해야 하는 문제를 한꺼번에 풀려고 하면 뇌는 과부하에 빠진다. 하지만 같은 문제를 세 단계로 쪼개면, 각 단계에서 고려해야 할 조건은 서너 개로 줄어든다. 작업 기억의 한계 안에 들어오는 것이다.

인지심리학에서는 이를 위계적 추론(hierarchical reasoning)이라 부른다. 큰 목표를 상위 층에 두고, 그 아래에 중간 목표, 가장 아래에 구체적 행동을 배치하는 구조다. 학생들이 큰 과제를 끝낼 때 가장 효과적인 전략이 "단계로 나누어 하나씩 해치우기"라는 건 누구나 경험적으로 안다. 인지과학은 그 경험을 실험실에서 확인해 주었을 뿐이다.

사람의 뇌는 계산 자원이 유한한 환경에서 합리적으로 행동하도록 진화했다. 문제를 쪼개는 것은 제한된 자원 안에서 최선의 결과를 내기 위한 전략이지, 게으름이 아니다.

02 / AI의 추론"천천히 생각해 봐" — 한 문장이 바꾼 것

2022년, 구글 리서치의 Jason Wei 등이 발표한 Chain-of-Thought(CoT) 프롬프팅 논문은 AI 연구의 흐름을 바꿨다. 핵심 아이디어는 놀라울 만큼 단순하다. 모델에게 최종 답만 내라고 하지 말고, 중간 추론 과정을 함께 출력하게 하라는 것이다.

같은 해 Kojima 등은 한 걸음 더 나아갔다. 몇 가지 예시를 보여줄 필요도 없이, "Let's think step by step"이라는 단 한 문장만 프롬프트 끝에 붙여도 비슷한 효과가 난다는 것을 보여 주었다. 이것이 Zero-shot CoT다.

숫자로 보면 효과는 극적이다.

같은 모델, 같은 파라미터, 같은 데이터. 달라진 것은 오직 "단계를 밟으라"는 지시 한 줄이다. 왜 이런 일이 벌어지는 걸까?

원리를 짧게 풀어 보면 이렇다. LLM은 다음 토큰을 예측하는 함수다. "답은 42입니다"를 바로 생성하라고 하면, 모델은 입력에서 답까지의 거리를 한 번의 점프로 건너야 한다. 중간 과정을 출력하게 하면, 모델은 "먼저 A를 구하고 → A에서 B를 유도하고 → B에서 최종 답을 내는" 경로를 밟게 된다. 각 점프의 거리가 짧아지니 오류가 줄어드는 것이다. 인간의 작업 기억 제한과 놀라울 만큼 닮은 구조다.

03 / 추론 모델생각하는 시간을 사는 새로운 패러다임

CoT 프롬프팅은 사용자가 모델에게 "단계별로 생각하라"고 요청하는 방식이었다. 2024년부터 등장한 추론 모델(reasoning model)은 한 차원 다르다. 모델 자체가 답을 내기 전에 스스로 길게 생각하도록 훈련되었다.

OpenAI의 o1이 그 시작이었고, o3에 이르러 성능은 놀라운 수준에 도달했다. Anthropic의 Claude도 Extended Thinking이라는 이름으로 같은 방향을 걷고 있다. 핵심 아이디어는 동일하다. 모델에게 "생각하는 시간"을 더 주면, 결과가 더 좋아진다.

여기서 주목할 패턴이 있다. Anthropic의 연구에 따르면, Extended Thinking의 성능은 "사고 토큰" 수에 따라 로그 함수적으로 향상된다. 즉, 생각을 10배 더 하면 정답률이 일정량 올라가고, 또 10배를 더 써야 같은 폭만큼 다시 올라간다. 인간이 난제 앞에서 겪는 수확 체감의 법칙과 정확히 같은 곡선이다.

추론 모델의 등장은 AI 업계에 새로운 스케일링 축을 열었다. 훈련 데이터를 더 모으거나 파라미터를 더 늘리는 대신, 추론 시간에 더 오래 생각하게 하는 것 — 이것을 test-time compute 스케일링이라 부른다. 생각하는 시간 자체가 자원이 된 셈이다.

04 / 공통 구조사람과 AI의 단계별 사고는 왜 닮았는가

사람의 위계적 추론과 AI의 Chain-of-Thought가 비슷한 효과를 내는 것은 우연이 아니다. 둘 다 같은 문제를 풀고 있기 때문이다. 유한한 처리 자원으로 복잡한 추론을 수행하는 문제.

MIT 연구팀의 최근 발견이 이 대칭을 뒷받침한다. 인공신경망에 인간과 유사한 계산 제약을 부과하면, 그 네트워크는 인간과 놀라울 만큼 비슷한 행동 패턴을 보였다. 이는 인간의 단계별 사고 전략이 "제한된 자원 아래에서의 합리적 행동"이라는 점을 시사한다. AI의 CoT도 본질적으로 같은 전략의 다른 구현인 셈이다.

05 / 실무 적용단계별 사고를 "설계"한다는 것

원리를 아는 것과 실무에 적용하는 것 사이에는 늘 간극이 있다. 단계별 사고의 원리를 실제 업무와 AI 활용에 녹이는 방법을 세 가지 층위로 나누어 보자.

층위 1: 프롬프트에 단계를 심기

가장 단순한 적용이다. AI에게 작업을 시킬 때, "보고서 써줘"라고 던지는 대신 단계를 명시한다.

# 단계를 명시하지 않은 프롬프트
"이 데이터를 분석해서 보고서를 작성해줘."

# 단계를 명시한 프롬프트
"이 데이터를 아래 단계에 따라 분석해줘:
 1단계: 데이터의 전체 구조를 파악하고 누락값을 확인한다.
 2단계: 주요 변수의 분포와 이상치를 탐색한다.
 3단계: 핵심 인사이트 3가지를 도출한다.
 4단계: 인사이트를 기반으로 보고서 초안을 작성한다.
 5단계: 초안을 검토하고 논리적 비약이 없는지 확인한다."

차이는 극적이다. 첫 번째 프롬프트는 모델에게 입력에서 최종 결과까지 한 번에 점프하라고 요구한다. 두 번째 프롬프트는 다섯 번의 짧은 점프를 밟게 한다. 각 점프의 난이도가 낮아지니, 전체 결과의 품질이 올라간다.

층위 2: 에이전트 설계에 단계를 내장하기

프롬프트 수준을 넘어서면, 작업 흐름 자체에 단계를 구조화할 수 있다. AI 에이전트를 설계할 때 하나의 거대한 프롬프트로 모든 걸 처리하는 대신, 각 단계를 별도의 호출로 분리하는 것이다.

# 단일 호출: 모든 걸 한 번에
response = model.generate("시장 조사를 해서 보고서를 만들어줘")

# 다단계 파이프라인: 각 단계를 분리
step1 = model.generate("조사 목적과 핵심 질문 3가지를 정리해줘")
step2 = model.generate(f"다음 질문에 대해 조사해줘: {step1}")
step3 = model.generate(f"조사 결과를 표로 구조화해줘: {step2}")
step4 = model.generate(f"이 표를 바탕으로 보고서 초안을 써줘: {step3}")
step5 = model.generate(f"초안을 검토하고 빠진 부분을 보완해줘: {step4}")

이 방식은 단순히 프롬프트를 잘 쓰는 것을 넘어, 일을 어떻게 분해할 것인가를 설계하는 일이다. 그리고 이 설계 능력은 AI가 대신해 주지 않는다. 일의 구조를 가장 잘 아는 사람이 해야 하는 일이다.

층위 3: 사람의 사고 습관 자체를 바꾸기

가장 깊은 적용은 AI와 무관하게 작동한다. 복잡한 의사결정 앞에서 "일단 해보자" 대신 "잠깐, 이걸 세 단계로 나누면 뭐가 되지?"라고 스스로에게 묻는 습관이다.

• 기획 회의"이 프로젝트의 성공 조건이 뭔지 먼저 정의하고, 그 다음에 방법론을 논의합시다" — 목표 → 방법 → 실행 순서를 강제하는 것만으로 회의의 질이 달라진다.
• 문서 작성곧바로 본문을 쓰지 않고, 목차부터 잡는다. 목차는 문제를 분해한 결과물이다. 목차가 탄탄하면 본문은 각 항목을 채우는 일이 된다.
• 디버깅"왜 안 되지?"에서 "어디까지 되는지 먼저 확인하자"로 질문을 바꾼다. 작동하는 마지막 지점을 찾으면, 문제의 범위가 좁아진다.
• 의사결정"이게 맞을까?"보다 "이 결정에 영향을 미치는 요인이 뭐가 있지?"를 먼저 나열한다. 요인을 펼쳐 놓으면 판단이 투명해진다.

이 세 층위는 서로 독립적이지 않다. 사람이 일을 잘 쪼개는 습관을 가지면 AI에게 주는 지시도 자연스럽게 단계적이 된다. AI의 결과물이 좋아지면 사람은 더 복잡한 작업을 맡기게 되고, 그러면 더 정교한 분해가 필요해진다. 선순환이 생기는 것이다.

06 / 주의사항단계별 사고가 만능은 아니다

여기까지 읽으면 "모든 문제에 단계를 밟으면 되겠구나"라는 결론에 이를 수 있다. 하지만 최근 연구는 좀 더 복잡한 그림을 보여준다.

2025년 Wharton의 Generative AI Lab에서 발표한 보고서는 흥미로운 발견을 담고 있다. 최신 추론 모델(o3, Claude 등)에서는 CoT 프롬프팅의 추가 효과가 줄어들고 있다는 것이다. 이유는 간단하다. 이 모델들은 이미 내부적으로 단계별 사고를 수행하도록 훈련되어 있기 때문에, 사용자가 밖에서 한 번 더 "단계별로 생각해"라고 말하는 것이 중복이 되는 것이다.

이 발견이 단계별 사고의 가치를 부정하는 것은 아니다. 오히려 반대다. 추론 모델이 내부적으로 CoT를 수행한다는 것은, 단계별 사고가 너무 효과적이어서 모델 자체에 내장되었다는 뜻이다. 차의 엔진에 이미 변속기가 달려 있으니, 운전자가 수동으로 기어를 바꿀 필요가 줄었을 뿐이다. 변속의 원리가 사라진 것이 아니라, 자동화된 것이다.

그래서 진짜 중요한 질문은 이것이다. "언제 AI의 자동 추론에 맡기고, 언제 사람이 직접 단계를 설계해야 하는가?"

경험칙은 이렇다. 작업이 정형적이고 모델이 유사한 문제를 많이 학습했다면, 모델의 자동 추론이 충분하다. 작업이 비정형적이고, 도메인 지식이 필요하고, 실패의 비용이 높다면 — 그때는 사람이 단계를 설계해야 한다. AI가 아무리 똑똑해져도, 일의 구조를 결정하는 일은 그 일을 가장 잘 아는 사람의 몫으로 남는다.

07 / 마무리멈추고, 쪼개고, 밟아 나가기

다시 처음으로 돌아가 보자. 복잡한 질문 앞에서 "잠깐만, 정리해 볼게"라고 말하는 사람의 이야기. 그 한 박자의 멈춤이 결과를 바꾸는 이유를 이제 우리는 두 방향에서 이해할 수 있다.

인간의 뇌는 작업 기억의 한계 안에서 최선의 결과를 내기 위해 문제를 쪼갠다. AI의 언어 모델은 한 번의 점프 거리를 줄이기 위해 중간 추론 단계를 밟는다. 표면은 다르지만 구조는 같다. 유한한 자원으로 복잡한 문제를 풀 때, 단계를 밟는 것이 단계를 생략하는 것보다 낫다.

이 원리는 프롬프트 한 줄에도, 에이전트 아키텍처에도, 회의실의 화이트보드에도 똑같이 적용된다. "Let's think step by step"이 AI의 정답률을 네 배로 올린 것과, 좋은 기획자가 프로젝트를 마일스톤으로 쪼개는 것과, 숙련된 개발자가 큰 풀 리퀘스트를 작은 단위로 나누는 것은 — 전부 같은 전략의 서로 다른 표현이다.

결국 단계별 사고는 기술이 아니라 태도다. 복잡함 앞에서 한 발 물러나 "이걸 세 조각으로 나누면 뭐가 되지?"라고 스스로에게 묻는 태도. 그 질문이 습관이 되면, 사람의 판단도, AI의 출력도, 그 둘이 합쳐진 결과물도 — 모두 한 단계 위의 수준에서 시작하게 된다.

급할수록 돌아가라는 옛말은, 2026년의 AI 시대에도 여전히 유효한 전략이다.

문제는 기술이 아니다. AI를 '도구'로 보는 순간, 우리는 가장 중요한 질문을 놓친다. 어떤 문제를, 어떤 순서로, 어떻게 쪼갤 것인가.

조직마다 AI를 도입하고 있다. 챗GPT 라이선스를 배포하고, 프롬프트 교육을 열고, 생성형 AI 활용 사례집을 돌린다. 그런데 석 달 뒤에 물어보면 대부분 같은 말을 한다. "처음엔 신기했는데, 지금은 잘 안 쓰게 됐어요." 왜일까. 도구가 나쁜 것이 아니다. 도구를 쓰는 방식이 바뀌지 않았기 때문이다. 우리는 AI에게 "이거 해줘"라고 말하는 데는 능숙해졌지만, "내가 지금 풀어야 하는 문제가 뭔지"를 먼저 정리하는 데는 여전히 서툴다.

AI를 활용한다는 것은 새로운 기술을 쓰는 것이 아니다. 문제 해결 프로세스를 바꾸는 것이다. 이 차이를 이해하지 못하면, 어떤 모델이 나와도 업무는 바뀌지 않는다.

01 / 오해AI 기술이 문제를 해결해 줄 거라는 착각

가장 흔한 오해부터 짚어야 한다. "AI 기술이 우리의 문제를 해결하고 업무를 수월하게 해 줄 것이다." 많은 조직이 이 전제 위에서 출발한다. 그리고 이 전제가 틀렸다.

AI는 혼자서 일을 하지 않는다. 절대로. AI가 하는 일은 사람이 구조화한 질문에 대해 결과를 내놓는 것이다. 질문이 구조화되지 않으면 결과도 구조화되지 않는다. "보고서 써줘"라고 던지면 그럴듯한 문장이 돌아오지만, 그 문장이 지금 내가 풀어야 하는 문제를 정확히 겨냥하고 있을 확률은 낮다.

실제 업무에서 중요한 건 AI 기술 자체가 아니다. 문제를 어떻게 구조화하고, 어떤 질문을 던지는가가 중요하다. 같은 AI를 쓰더라도, 문제를 잘 쪼개는 사람의 결과물과 그렇지 않은 사람의 결과물 사이에는 하늘과 땅만큼의 차이가 난다. 이건 프롬프트를 잘 쓰느냐의 문제가 아니다. 자기 업무를 얼마나 명확하게 이해하고 있느냐의 문제다.

AI가 대신해 주는 건 실행이다. 하지만 "무엇을 실행할지"를 정하는 건 여전히 사람의 몫이다. 그리고 대부분의 조직에서 병목은 실행이 아니라 정의에 있다.

02 / 구조문서, 데이터, 코딩 — 세 개의 톱니바퀴

그렇다면 AI를 활용한 문제 해결은 실제로 어떤 모양일까. 나는 이것을 세 개의 톱니바퀴로 설명한다. 하나가 돌아야 다음이 돌고, 세 개가 맞물려야 비로소 조직이 움직인다.

이 세 단계는 순서가 있다. 사고가 정리되지 않으면 분석할 방향을 모르고, 분석 없이 만든 도구는 엉뚱한 문제를 푼다. 반대로, 세 개가 맞물리면 한 사람이 낼 수 있는 결과물의 규모가 극적으로 달라진다.

03 / 분석"분석이 부족해서" 문제가 생긴 게 아니다

여기서 데이터 분석에 대해 조금 더 들어가 보자. 이 영역에 대한 오해가 특히 깊기 때문이다.

데이터 분석이 부족해서 문제가 생긴 조직은 사실 많지 않다. 대부분의 조직은 이미 충분히 분석하고 있다. 월간 보고서에 그래프가 빠지지 않고, 분기마다 트렌드 리포트를 만들고, 대시보드에는 숫자가 실시간으로 올라간다. 문제는 그 분석을 '판단의 언어'로 바꾸지 못한다는 데 있다.

AI가 데이터 분석에서 진짜 힘을 발휘하는 건, 숫자를 예쁘게 정리해 주는 것이 아니라, 사람이 "이 두 가지 옵션 중 뭐가 나아?"라고 물을 수 있게 데이터를 재구성해 주는 것이다. 이를 위해 사람이 알아야 할 건 네 가지다.

• 역할 인식AI가 어떤 분석을 대신할 수 있는지 이해한다. 단순 집계는 AI가 하고, 맥락 해석은 사람이 한다.
• 결과 해석AI가 내놓은 결과를 어떻게 읽어야 하는지 안다. 숫자 뒤에 숨은 전제와 한계를 파악한다.
• 질문 설계어떤 질문을 던져야 의사결정에 도움이 되는지 안다. "매출이 얼마야?"가 아니라 "매출 하락의 주 원인 세 가지를 영향도 순으로 보여줘".
• 신뢰 판단이 분석을 믿어도 되는지, 언제 멈춰야 하는지 판단한다. 데이터가 불충분하면 분석을 중단하는 것도 역량이다.

이 네 가지는 전부 AI의 능력이 아니라 사람의 역량이다. AI는 분석을 자동화해 주지만, 분석의 방향을 정하고 결과를 판단에 연결하는 건 사람의 몫이다. 이 역량이 없으면 AI가 아무리 정교한 분석을 내놓아도 보고서 안에서 잠을 잔다.

04 / 연결세 톱니바퀴가 맞물리는 순간

다시 전체 그림으로 돌아오자. 문서, 데이터, 바이브 코딩 — 이 세 영역이 따로 도는 것이 아니라 하나의 흐름으로 연결될 때, AI 활용은 비로소 '문제 해결'의 형태를 갖추게 된다.

구체적인 예를 하나 들어보겠다. 공공기관에서 민원 데이터를 분석하는 업무를 상상해 보자.

차이가 보이는가. 기존 방식은 "설명"에서 끝난다. 바뀐 방식은 "가설 → 근거 → 실행"으로 이어진다. AI가 달라진 게 아니다. 문제를 대하는 프로세스가 달라진 것이다.

05 / 전환질문을 바꾸면 결과가 바뀐다

이 글에서 전하고 싶은 핵심을 한 문장으로 압축하면 이렇다.

AI를 활용한다는 것은 "문제 해결 프로세스"를 바꾸는 것이다.

더 좋은 모델이 나오기를 기다리는 것이 아니다. 더 그럴듯한 프롬프트를 외우는 것이 아니다. 내가 지금 풀어야 하는 문제를 명확하게 정의하고, 그 문제를 단계로 쪼개고, 각 단계에서 AI에게 적절한 역할을 맡기는 것이다.

생각이 정리되지 않으면 판단도 없다. 판단 근거가 없으면 결정은 감에 의존한다. 결정이 실체로 연결되지 않으면 조직은 변하지 않는다. 이 세 문장이 AI 활용의 전부다. 세 문장 안에 기술 이야기는 단 한 글자도 없다. 있는 건 오직 문제를 대하는 태도뿐이다.

AI를 쓰는 사람은 많아졌다. 하지만 AI로 문제를 푸는 사람은 아직 드물다. 그 차이는 도구의 숙련도에서 오지 않는다. "지금 내가 풀어야 하는 문제가 뭔지"를 먼저 묻는 습관에서 온다.

오늘 업무를 시작하기 전에, AI에게 물어보기 전에, 먼저 스스로에게 물어보자. 내가 지금 정리해야 하는 생각은 무엇인가. 판단에 필요한 근거는 무엇인가. 이 결정을 실행으로 옮기려면 무엇이 필요한가. 이 질문에 답할 수 있다면, AI는 그때부터 진짜로 일하기 시작한다.

챗봇은 "뭘 알고 싶어?"에 답하지만, 에이전트는 "뭘 해야 해?"에 답한다. 모델의 문제가 아니라 구조의 문제다.

안녕하세요. AX 전문교수 김태유입니다.

AI를 처음 접하는 분들은 대개 챗봇부터 떠올리실 겁니다. 질문을 던지면 답을 받고, 그 답을 복사해 문서에 붙이고, 가끔은 요약이나 번역을 시키는 방식이죠. 이 사용법은 익숙하고 편합니다. 진입 장벽도 낮고, 당장 눈에 띄는 효과도 있습니다.

하지만 여기서 멈추면 AI는 늘 '도움은 되지만 결정적이진 않은 도구'로 남게 됩니다. 반대로 AI Agent를 이해하기 시작하면 이야기가 완전히 달라집니다. 에이전트는 단순히 질문에 답하는 존재가 아니라, 일을 쪼개고, 순서를 정하고, 도구를 호출하고, 중간 결과를 기록하고, 다음 행동으로 자연스럽게 이어 주는 하나의 운영 단위입니다.

01 / 정의챗봇과 에이전트, 무엇이 다른가요?

이 차이는 생각보다 훨씬 큽니다.

챗봇은 구조적으로 하나의 입력에 하나의 응답을 돌려줍니다. 그 응답이 아무리 훌륭하더라도, 다음 단계로 넘어가는 건 결국 사람의 몫입니다. 반면 에이전트는 여러 단계의 작업을 스스로 묶어서 처리합니다.

시장조사를 예로 들어볼까요. 챗봇에게 "이 시장의 규모가 어떻게 돼?"라고 물으면 그럴듯한 답을 돌려줄 수 있습니다. 하지만 에이전트는 다르게 작동합니다. 먼저 조사의 목적을 정리하고, 비교해야 할 항목을 추출하고, 검색 범위를 나누어 단계적으로 정보를 수집하고, 결과를 표 형태로 구조화하고, 빠진 출처가 있는지 확인하고, 마지막에는 보고서 문장까지 정리해 냅니다. 즉, 하나의 답변이 아니라 하나의 작업 흐름을 만들어 내는 것입니다.

챗봇은 "뭘 알고 싶어?"에 답하지만, 에이전트는 "뭘 해야 해?"에 답합니다.

02 / 오해더 똑똑한 모델의 문제가 아닙니다

많은 분들이 AI Agent를 더 강력한 모델의 문제로 이해하곤 합니다. GPT-4보다 더 좋은 모델, Claude보다 더 뛰어난 모델이 나오면 자연스럽게 에이전트처럼 작동할 거라고 기대하는 것이죠. 하지만 실제로는 그렇지 않습니다. 이건 모델의 문제가 아니라 구조의 문제입니다.

같은 모델이라도 어떤 순서로 일을 맡기느냐, 어떤 도구를 연결하느냐, 어느 단계에서 사람이 개입해 검수하느냐에 따라 결과는 완전히 달라집니다. 예를 들어 동일한 Claude를 사용하더라도, 단순히 "보고서 써줘"라고 던지는 것과, 단계별로 역할을 나누어 리서치 → 구조화 → 초안 → 검수의 흐름으로 작업을 설계하는 것 사이에는 결과물의 질에서 엄청난 차이가 납니다.

그래서 AI Agent를 잘 활용하려면 프롬프트를 잘 쓰는 것만으로는 부족합니다. 일을 어떻게 분해할 것인지, 각 단계를 어떤 기준으로 넘길 것인지, 실패했을 때 어떻게 되돌릴 것인지에 대한 설계가 필요합니다. 이건 개발자만의 영역이 아닙니다. 일을 설계하는 능력, 즉 업무 기획력이 AI를 운영하는 핵심 역량이 되는 시대가 오고 있습니다.

03 / 도구OpenClaw가 흥미로운 이유

이 맥락에서 OpenClaw는 특히 주목할 만한 도구입니다.

OpenClaw는 AI를 단발성 질문 응답 도구로 두지 않고, 세션, 메모리, 툴, 서브에이전트, 크론과 같은 운영 요소로 연결해 실제 업무 시스템처럼 작동하게 해 줍니다. 오늘 한 번 쓴 프롬프트가 내일도 재사용되고, 반복되는 업무가 정해진 흐름으로 자동 처리되고, 주기적으로 점검해야 하는 작업이 스케줄에 맞춰 실행되도록 설계할 수 있습니다.

이건 단순한 편의 기능이 아닙니다. 대화형 AI를 업무 인프라로 바꾸는 시도입니다. AI와 나눈 대화가 일회성 상호작용으로 사라지지 않고, 맥락이 축적되고, 작업 흐름에 녹아들고, 팀 전체가 공유할 수 있는 운영 자산이 되는 것입니다. 이 방향이 개인 생산성 도구와 조직 운영 시스템의 경계를 허무는 지점이기도 합니다.

04 / 실무실무에서의 차이는 더 선명합니다

이메일 작성 하나만 봐도 차이가 분명하게 드러납니다.

챗봇은 메일 한 통을 잘 써 주는 데 강합니다. 어투도 자연스럽고, 구성도 매끄럽습니다. 하지만 에이전트는 그 전 단계부터 시작합니다. 수신자를 분류하고, 메일의 목적을 명확히 하고, 상황에 맞는 어투를 결정하고, 필요한 경우 이전 회의록이나 대화 맥락을 참고해 내용을 구성하고, 마지막으로 발송 전 검수까지 이어갑니다. 그 결과 "문장을 잘 써 주는 도구"가 아니라 "문서 작업을 처음부터 끝까지 굴려 주는 도구"가 됩니다.

보고서 작성, 데이터 정리, 고객 응대 초안, 콘텐츠 제작 등 반복적인 업무가 많은 분들일수록 이 차이를 더 크게 체감하실 겁니다. 매번 새로 시작하는 것과, 한번 잘 설계된 흐름 위에서 실행하는 것의 차이는 시간이 지날수록 누적됩니다.

05 / 역할에이전트가 강해질수록, 사람의 역할도 커집니다

이 지점에서 많은 분들이 오해를 하십니다. 에이전트를 쓰면 사람이 필요 없어질 것 같다는 걱정이죠. 하지만 실제로는 정반대입니다.

에이전트가 강해질수록 사람의 역할은 오히려 더 중요해집니다. 무엇을 자동화할지 결정하는 것, 어떤 결과를 합격으로 볼지 기준을 정하는 것, 어떤 오류는 허용하고 어떤 오류는 반드시 막아야 하는지 판단하는 것, 이 모든 일은 여전히 사람의 몫입니다. AI는 일의 실행을 담당하지만, 일의 기준을 대신 정해 주지는 않습니다.

달리 말하면, 에이전트를 잘 운영하는 사람은 '더 좋은 프롬프트를 쓰는 사람'이 아니라 '일을 더 잘 설계하는 사람'입니다. AI가 확장시켜 주는 건 실행 능력이고, 그 실행을 어디에, 어떻게 쓸지는 사람의 판단에 달려 있습니다.

06 / 출발질문을 바꾸는 것이 시작입니다

AI Agent를 이해하는 가장 쉬운 방법은 스스로에게 던지는 질문을 바꾸는 것입니다.

"AI에게 무엇을 물을까?"가 아니라 "AI에게 어떤 일을 맡길까?"로 생각을 옮기는 것. 이 질문 하나가 바뀌면 뒤따르는 것들이 연쇄적으로 달라집니다. 프롬프트의 구조가 바뀌고, 연결하는 도구가 달라지고, 결과를 기록하고 재사용하는 방식이 바뀝니다. AI를 쓰는 방식이 아니라 일하는 방식 자체가 변하는 것입니다.

결국 AI Agent는 더 좋은 답변을 얻기 위한 기술이 아닙니다. 일을 더 잘 굴리기 위한 운영 방식입니다.

앞으로 이 시리즈에서는 그 운영 방식을 OpenClaw를 기준으로 구체적으로 풀어갈 예정입니다. 챗봇처럼 쓰는 단계에서 끝나지 않고, 실제 업무에 붙여서 반복 작업을 줄이고, 결과물의 품질을 일정하게 유지하고, 혼자서도 작은 자동화 시스템을 운영할 수 있는 방법까지 다룰 생각입니다.

AI를 써 본 사람과 AI를 운영하는 사람의 차이는 바로 여기서 생깁니다. 그리고 그 차이는 생각보다 훨씬 빠르게 벌어지고 있습니다.

생성형 AI 시대, 기획·디자인·개발의 경계가 '묽어지고' 있다. 자신의 도메인을 바탕으로 DX·AX를 스스로 주도하는 새 인재상에 대한 연재의 첫 편.

빛의 속도로 진화하는 생성형 AI 시대다. ChatGPT, Gemini, Claude와 같은 거대언어모델(LLM)이 일상과 산업 전반으로 깊숙이 스며들면서, 산업혁명 이후 수백 년간 견고하게 유지되었던 직무의 경계가 뿌리째 흔들리고 있다. 과거에는 기획, 디자인, 개발이 각각 독립된 섬처럼 존재했다면, 이제는 개발자가 비즈니스 모델을 기획하고, 기획자가 AI를 활용해 시안을 디자인하며, 디자이너가 코드의 구조를 이해하며 개발을 고민하는 시대가 왔다.

나는 이 현상을 경계가 무너진다는 말보다 '묽어진다'고 표현하고 싶다. 서로 다른 색의 물감이 캔버스 위에서 섞이듯, 우리의 역량도 고유의 색을 유지한 채 서로의 영역으로 유연하게 스며들고 있기 때문이다.

01 / 이전 시대뱀처럼 정복하기 힘들었던 데이터의 시대

인공지능을 향한 사회적 열망은 2016년 알파고 쇼크로부터 본격화되었다. 그때부터 세상에는 인공지능에 대한 요구가 마치 안개처럼 스멀스멀 피어올랐다. 주요 대학에는 인공지능 학과와 대학원이 우후죽순 생겨났고, 기업들은 생존을 위해 인공지능 도입에 사활을 걸었다. 업계는 입을 모아 '데이터가 곧 석유'라고 강조했으며, 정부는 이에 응답하듯 AI 허브(aihub.or.kr)와 같은 대규모 데이터 구축 사업을 공격적으로 수행했다. 당시 정부 과제에서 '인공지능'이라는 키워드가 빠지면 선정조차 기대하기 어려울 정도였다.

이러한 격변 속에서 데이터 사이언티스트는 모든 직장인의 선망 대상이 되었다. 소프트웨어 개발자의 가치는 천정부지로 솟았고, "초봉 1억은 줘야 인재를 모셔온다"는 이야기가 심심치 않게 들려왔다. 그들의 핵심 무기인 'Python'은 성공을 보장하는 필수 언어로 추앙받았다. 모든 교육 과정에 Python이 포함되었고(심지어 모 학교는 무용과 학생들에게도 필수교과목으로 정했다), 수많은 이들이 데이터 사이언티스트라는 꿈을 품고 코딩에 뛰어들었다. 하지만 Python은 그 이름(비단뱀)처럼 결코 호락호락하게 길들여지는 언어가 아니었다. 단순한 문법 습득을 넘어 복잡한 라이브러리와 알고리즘을 이해해야 하는 과정에서 많은 이들이 좌절의 쓴맛을 보아야 했다.

02 / 전환시민 데이터 과학자에서 LLM의 시대로

높은 코딩의 벽을 넘기 위해 Orange3 같은 노코드(No-code) 도구나 Power BI 같은 데이터 시각화 도구가 대안으로 떠올랐다. 전문 개발자가 아니더라도 스스로 데이터를 분석해 문제를 해결하려는 '시민 데이터 과학자(Citizen Data Scientist)'들의 등장이었다. 그러나 기술의 발전은 이들에게 머무를 시간을 길게 허용하지 않았다.

2022년 11월, OpenAI의 ChatGPT 출시는 판도를 완전히 뒤흔들었다. 과거의 데이터 분석 도구가 기업 내 소수의 분석가(10~20%)를 위한 전문 도구였다면, 이제 LLM은 조직 구성원 99%가 매일 사용해야 하는 '보편-필수적' 도구가 되었다.

데이터과학은 노코드 도구로 장벽의 높이를 어느 정도 낮출 수 있었으나 완전히 허물기는 역부족이었고, 프로그래밍 영역은 여전히 일반인에게 높은 성벽과 같았다. 하지만 LLM은 이 높은 장벽을 낮추는 것이 아니라 허물어뜨렸다. 초기에 언급되었던 고질적 문제인 할루시네이션(환각 현상)은 모델 업데이트마다 눈에 띄게 줄어들고 있으며, 텍스트를 넘어 이미지와 영상 생성, 그리고 고도화된 코딩 실력까지 갖추게 되었다. 이제는 복잡한 코딩 언어를 마스터하지 않아도 통합개발환경(IDE)의 흐름만 이해한다면, 자신의 도메인 지식을 바탕으로 개발자의 손을 빌리지 않고도 문제를 직접 해결할 수 있는 환경이 우리 의지와 상관없이 눈앞에 펼쳐졌다.

03 / 인재상새로운 인재상: Domain-DAXist의 등장

하지만 어떤 기술이 세상에 선보일 때 있었던 현상처럼, ChatGPT를 검색 수준에서 사용하는 사람이 대다수이고, 자신의 주요 시간을 잡아먹는 수작업 위주의 반복 업무(일명 NGD 스타일)는 여전히 과거의 익숙함에 의존해 처리하고 있다.

지금의 세상은 우리에게 단순히 도구를 다루는 기술과 익숙함을 넘어서는 기술, 그리고 현업을 완전히 결합하는 새로운 존재감을 요구한다.

나는 이를 'Domain-DAXist'라고 정의한다. 자신의 전문 분야에 대한 깊은 이해를 바탕으로 디지털 전환(DX)은 물론, 인공지능 전환(AX)까지 스스로 주도하여 결과물을 만들어내는 사람.

그렇다면 이 격동의 시대가 요구하는 Domain-DAXist의 핵심 자질은 무엇일까? 나는 다음의 네 가지를 그 본질로 꼽는다.

01자신의 도메인에 대한 깊은 전문성

AI가 '방법(How)'을 제시한다면, 무엇이 '문제(Problem)'인지를 정의하는 것은 여전히 인간의 몫이다. 자신의 분야에서 뼈가 굵은 전문가만이 AI에게 날카로운 질문을 던질 수 있다.

02새로운 시각의 마인드세트

"원래 그렇게 해왔다"는 관성을 버려야 한다. 아날로그적인 업무 방식이나 익숙함으로 견뎌온 반복 업무를 AI의 시각으로 재해석하고, 이를 자동화·효율화하려는 혁신적 사고가 필수적이다.

03이론보다 실천하는 습관

거창한 이론 학습에 매몰되어 시간을 허비하기보다, 일단 프롬프트를 입력하고 작은 결과물이라도 직접 만들어보는 '실행력'이 곧 실력이 되는 시대다. 실패하더라도 즉각적으로 수정하는 민첩함이 중요하다.

04주변을 변화시키는 인간적인 매력

기술이 고도화될수록 기계가 대체할 수 없는 '공감'과 '설득'의 가치는 더욱 커진다. 혼자만의 성과에 그치지 않고 자신의 혁신 사례를 동료들과 공유하며, 조직 전체의 변화를 전염시키는 따뜻한 리더십이야말로 Domain-DAXist를 완성하는 진정한 핵심 역량이다.

앞으로 이어질 글들을 통해 이 네 가지 요건에 담긴 나의 구체적인 경험과 생각을 하나씩 풀어보고자 한다. 변화의 거대한 파도 위에서 휩쓸리지 않고, 파도를 타는 Domain-DAXist로 거듭나는 여정을 독자들과 함께 시작해보고 싶다.

직접 생산하는 사람에서 설계하고 검수하는 사람으로. 회의·이메일·보고서가 재배치되는 자리, 그리고 Gemini가 업무 흐름 속으로 들어오는 방법.

직장인의 일은 예전보다 훨씬 빨라졌지만, 아이러니하게도 여전히 많은 시간이 반복 작업에 쓰입니다. 하루를 돌아보면 중요한 의사결정이나 창의적 기획보다 이메일을 읽고, 회의 내용을 정리하고, 보고서 초안을 만들고, 여러 자료를 찾아 요약하는 데 시간을 더 많이 쓰는 경우가 적지 않습니다. 겉으로 보기에는 모두 다른 일처럼 보이지만, 실제로는 '읽기-정리하기-요약하기-초안 만들기-다듬기'라는 비슷한 패턴이 반복됩니다. AI가 직장인의 업무를 바꾸는 지점은 바로 여기에 있습니다.

많은 사람이 AI를 처음 접할 때 '질문을 하면 답을 해주는 똑똑한 챗봇' 정도로 이해합니다. 물론 그것도 맞는 설명입니다. 하지만 업무 현장에서 중요한 것은 단순한 질의응답 기능이 아닙니다. 진짜 변화는 AI가 직장인의 반복적인 인지 노동을 대신해 주기 시작했다는 점에서 나옵니다. 이제 직장인은 모든 문장을 처음부터 직접 쓰는 사람이 아니라, AI가 만든 초안을 검토하고 다듬고 판단하는 사람으로 바뀌고 있습니다. 다시 말해, 일의 중심이 '직접 생산'에서 '설계와 검수'로 이동하는 것입니다.

01 / 이동회의·이메일·보고서의 자리 바꾸기

예를 들어 회의가 끝난 뒤 해야 하는 일을 떠올려 보겠습니다. 예전에는 녹취나 메모를 바탕으로 회의 내용을 다시 읽고, 핵심 논점을 추리고, 담당자별 액션아이템을 정리한 뒤, 필요한 경우 팀에 공유할 문장으로 다듬어야 했습니다. 이 과정은 단순해 보이지만 의외로 많은 집중력을 요구합니다. 하지만 이제는 회의 기록을 Gemini에 넣고 원하는 형식을 명확히 지시하면 핵심 요약, 결정사항, 후속 조치 항목까지 훨씬 빠르게 정리할 수 있습니다. 직장인의 역할은 이 결과가 실제 맥락에 맞는지 확인하고, 빠진 맥락이나 민감한 표현을 수정하는 쪽으로 이동합니다.

이 변화는 이메일 업무에서도 뚜렷하게 나타납니다. 많은 직장인은 하루 중 상당한 시간을 받은 메일을 읽고, 중요도를 판단하고, 관련 자료를 확인하고, 회신 초안을 작성하는 데 씁니다. 특히 여러 이해관계자가 얽힌 메일일수록 문장을 조심스럽게 다듬어야 하므로 시간이 오래 걸립니다. AI는 이런 작업에서 큰 힘을 발휘합니다. 긴 메일 스레드를 요약하고, 핵심 질문을 추려 주고, 상황에 맞는 회신 초안을 제시할 수 있기 때문입니다. 덕분에 직장인은 '무엇을 써야 할지' 고민하는 데 에너지를 모두 쓰기보다 '이 답장이 적절한가, 빠진 이해관계는 없는가, 톤은 맞는가'를 판단하는 데 더 집중할 수 있습니다.

보고서와 자료조사 업무도 마찬가지입니다. 예전에는 자료를 찾고, 내용을 읽고, 중요한 부분을 표시하고, 다시 정리해 구조를 잡는 데 많은 시간이 들었습니다. 이제는 AI를 통해 자료를 빠르게 요약하고, 여러 문서를 비교하고, 보고서의 개요를 먼저 세울 수 있습니다. 여기서 중요한 점은 AI가 최종 판단까지 대신하지는 않는다는 사실입니다. AI는 초안을 빠르게 만들고 다양한 가능성을 제시하지만, 무엇을 강조할지, 어떤 근거를 채택할지, 어떤 표현이 조직 문화에 맞는지는 여전히 사람이 결정해야 합니다. 결국 AI가 들어온 뒤에도 사람의 역할은 사라지지 않습니다. 다만 역할의 무게중심이 바뀔 뿐입니다.

02 / 감각일을 잘게 나누는 새 경쟁력

그래서 AI 시대에 직장인에게 가장 필요한 능력은 '모든 것을 직접 해내는 능력'이 아니라 '업무를 구조화하고 AI에게 적절히 맡길 부분을 구분하는 능력'입니다. 예전에는 부지런함이 곧 경쟁력이 되는 경우가 많았다면, 이제는 무엇을 직접 하고 무엇을 자동화할지 판단하는 능력이 더 중요해지고 있습니다. 같은 한 시간을 써도 모든 자료를 직접 읽고 정리하는 사람보다, AI를 활용해 초안을 빠르게 만들고 핵심 판단에 시간을 집중하는 사람이 더 높은 생산성을 낼 가능성이 큽니다.

AI를 잘 쓴다는 것은 복잡한 프롬프트를 외우는 것이 아니라, 자신의 업무를 반복 가능한 단위로 나눠 보는 습관이다.

이때 많은 직장인이 오해하는 부분이 있습니다. AI를 잘 쓴다는 것은 특별히 복잡한 프롬프트를 외우거나 최신 기능을 누구보다 빨리 익히는 것이 아니라는 점입니다. 진짜 중요한 것은 자신의 업무를 반복 가능한 단위로 나눠 보는 습관입니다. 예를 들어 '보고서를 써야 한다'는 막연한 과제를 그대로 붙잡으면 AI도 제대로 활용하기 어렵습니다. 대신 이를 '배경 자료 정리', '핵심 메시지 3개 도출', '목차 초안 만들기', '문체 다듬기', '상사 보고용 한 장 요약 만들기'처럼 쪼개면 어떤 부분을 Gemini에게 맡기고 어떤 부분을 직접 해야 할지가 훨씬 선명해집니다. AI 시대에 강한 직장인은 일을 더 잘게 보고, 더 명확하게 지시하고, 더 빠르게 검수하는 사람입니다.

03 / 자리왜 하필 Gemini인가

특히 Gemini가 직장인에게 의미 있는 이유는 단순히 글을 생성하는 도구를 넘어 문서와 정보 흐름 속에 자연스럽게 들어올 수 있기 때문입니다. 직장인의 일은 대개 메일, 문서, 스프레드시트, 메모, 회의 기록처럼 여러 형태의 정보가 이어지는 과정으로 이루어집니다. 따라서 업무용 AI의 가치는 '얼마나 그럴듯한 문장을 쓰는가'보다 '이 흐름 속에서 얼마나 자연스럽게 연결되는가'에 달려 있습니다. Gemini를 Google Workspace와 함께 활용하면 메일을 읽고, 문서를 정리하고, 자료를 표 형태로 다듬는 식의 실제 업무 흐름에 AI를 붙이기가 쉬워집니다. 이 책이 Gemini를 중심에 놓는 이유도 여기에 있습니다.

물론 AI가 도입된다고 해서 모든 업무가 자동으로 쉬워지는 것은 아닙니다. 오히려 잘못 쓰면 더 많은 시간이 들 수도 있습니다. 모호한 지시를 하면 엉뚱한 답을 받고, 검수 없이 복사해 쓰면 부정확한 문장이 들어가며, 민감한 정보를 무심코 입력하면 보안 문제가 생길 수 있습니다. 그래서 AI 시대의 생산성은 'AI를 쓰느냐 안 쓰느냐'보다 '어떻게 쓰느냐'에서 갈립니다. 무턱대고 맡기는 것이 아니라 초안을 맡기고 사람이 검수하는 구조를 만드는 것이 핵심입니다. 이 원칙을 이해하면 AI는 불안한 기술이 아니라 든든한 업무 보조 도구가 됩니다.

04 / 방향두 갈래로 갈라지는 일

결국 AI 시대에 직장인의 일은 두 방향으로 바뀝니다. 첫째, 반복적이고 정형적인 작업은 점점 더 AI가 맡게 됩니다. 둘째, 사람은 판단, 맥락 이해, 우선순위 조정, 대인 커뮤니케이션, 최종 책임 같은 영역에 더 집중하게 됩니다. 즉 AI는 직장인을 대체하는 존재라기보다, 직장인의 일에서 '시간을 많이 먹지만 꼭 직접 할 필요는 없는 부분'을 흡수하는 존재에 가깝습니다. 이 변화에 적응하는 사람은 더 적은 시간으로 더 나은 결과를 만들 수 있고, 적응하지 못하는 사람은 여전히 많은 시간을 들이고도 속도와 품질에서 밀리게 됩니다.

이 책은 바로 그 변화에 적응하는 방법을 다룹니다. Gemini를 단순히 신기한 기능으로 소비하는 것이 아니라, 매일 반복되는 실무 흐름 속에 넣어 실제로 시간을 줄이고 결과물의 품질을 높이는 방법을 함께 살펴볼 것입니다. 중요한 것은 AI를 잘 아는 사람이 되는 것이 아니라, AI를 이용해 더 잘 일하는 사람이 되는 것입니다. 그리고 그 변화는 거창한 혁신보다 오늘 내가 쓰는 이메일 한 통, 회의록 한 장, 보고서 초안 하나를 더 빠르고 정확하게 만드는 데서 시작됩니다.

막는 정책에서 작동하는 거버넌스로. 폐쇄망에서 실제로 돌아가는 여덟 가지 증거와 함께.

한국의 공공 AX 논의에서 오랫동안 놓쳐 온 질문이 있다. 거시적 AX의 큰 물결 — 소버린 AI, K-AI 파운데이션 모델, GPU 확보, 인공지능위원회 — 그 흐름 속에서 정작 소외되고 있는 작은 현장의 문제들을 어떻게 풀 것인가 하는 질문이다. 이 글의 메시지는 하나로 모아진다.

01 / 두 축AX 대전환의 거시와 미시

AX 대전환에는 두 개의 축이 있다. 하나는 거시적 축이다. 소버린 AI, K-AI 파운데이션 모델, GPU 확보, 인공지능위원회 — 국가 차원의 전략적 흐름이다.

또 하나는 미시적 축이다. 직원 한 사람, 실무자 한 사람이 AX를 통해 자신의 일과 삶을 어떻게 바꿀 것인가 하는 문제다. 이 글이 집중하는 쪽은 두 번째 축 — 바닥에서 올라오는 AX다. 거시적 축만으로는 결코 닿을 수 없는 골목길의 문제가 이 나라에 너무 많이 남아 있기 때문이다.

02 / 소버린모델이 아니라 '꽂히는 자리'다

거시적 축을 짧게 짚고 가자. '소버린 AI'라는 말이 유행처럼 번지고 있다. 그런데 소버린 AI는 GPU를 사 모으고 파운데이션 모델을 하나 만드는 것으로 끝나지 않는다.

진짜 소버린 AI는 우리가 이미 세계 최고 수준으로 가지고 있는 자산 — 조선·제조·방산·식량 보안·공공 행정 데이터 — 이 자산들과 AI가 결합될 때 비로소 완성된다. 모델 자체가 아니라, 그 모델이 어디에 꽂히느냐가 소버린 AI의 본질이다. 그리고 그 '어디'의 가장 밑바닥은 결국 현장 실무자의 책상이다.

03 / VIBE이제는 스스로 만드는 시대다

그러면 미시적 축은 어떻게 이루어지는가. 불과 1~2년 전만 해도 실무자 AI 교육의 초점은 "ChatGPT를 얼마나 잘 쓰는가"였다. 보고서 초안을 뽑고, 문장을 다듬고, 아이디어를 정리하는 수준이었다.

지금은 완전히 다른 시대가 열렸다. 그 이름이 VIBE 코딩이다. OpenAI 공동 창립자이자 Y Combinator에서 오랫동안 활약한 안드레이 카파시가 붙인 이름이다.

내가 겪는 문제를 안다. 풀렸을 때의 모습을 상상할 수 있다. '어떻게' 푸는지는 — AI와 함께 찾는다.

이 말의 무게를 다시 한번 생각해 볼 필요가 있다. 이제는 현장 실무자 한 사람이 자기가 필요한 소프트웨어를, 자기가 필요한 업무 자동화 도구를, 스스로 만들어 쓸 수 있는 시대가 왔다는 뜻이다. 에이전트가 뭔지·하네스가 뭔지에 대한 기본 어휘는 이 블로그의 앞선 글에서 정리해 두었으니 필요하면 참고하기 바란다.

04 / 증거폐쇄망에서도 돌아가는 여덟 가지

"보안이 중요한 환경에서는 이 모든 것이 꿈 같은 이야기 아닌가"라는 질문이 자연스럽게 따라온다. 답은 "아니다"이다. 폐쇄망·행정망에서 오늘 당장 돌아가는 여덟 가지 방법을 정리해 본다. 모두 현장에서 검증된 것들이다.

05 / 골목길큰 예산이 결코 돌보지 않는 것들

여기까지의 여덟 가지는, 거대한 시스템이 해결해 주지 못하는 작은 골목길의 문제들을 푸는 방법이다. 내가 지금 목마르고, 내가 지금 배고프고, 내가 지금 손을 쓰고 싶은 그 작은 문제 — 큰 예산 사업·큰 벤더·큰 컨설팅이 결코 돌봐 주지 않는 바로 그 문제들이다.

거시적 AX와 미시적 AX가 만나는 순간, 그때 비로소 AX의 'X' — Transformation을 당당히 말할 수 있게 된다. 모델의 크기가 아니라 닿는 깊이가 진짜 혁신의 지표다.

06 / 거버넌스다섯 층위 — 3·4·5층이 비어 있다

마지막으로 거버넌스 이야기다. '혁신과 규제'라는 시소가 있다. 지금 우리의 시소는 너무 규제 쪽으로 기울어져 있지 않은가 — 감히 던지고 싶은 질문이다.

많은 공무원들이 AI 교육을 받을 때, 머릿속에 계속 맴도는 질문이 있다고 한다. "내가 이걸 배운들, 우리 기관에서 과연 쓸 수 있을까?" 이 막막함, 이 병목 — 역량 강화가 실무로 이어지지 못하게 만드는 이 벽. 이것을 걷어내는 것이 거버넌스의 실체다.

1층과 2층 — 법·제도와 원칙·윤리 — 은 한국 공공기관에 '있다.' 3·4·5층 — 정책·절차, 기술적 통제, 조직문화·역량 — 이 '비어 있다.' 그래서 거버넌스가 문서 속에만 머문다. 3·4·5층을 채우는 일, 그것이 이 글의 제언이다.

07 / 맺음막는 정책에서 작동하는 거버넌스로

공공을 진심으로 아끼는 사람들이 모여 있다면, 이 여덟 가지 증거는 여덟 가지 현장이 되고, 여덟 가지 현장은 수백 개의 일상이 된다. 아주 먼 이야기가 아니다. 이 글에 담긴 여덟 가지는 지금 당장, 오늘 오후에라도, 한 실무자의 책상에서 시작될 수 있는 것들이다.

거버넌스는 이 시작을 가로막지 않는 것에서 출발한다. 막는 정책이 아니라 작동하는 거버넌스. 위에서 내려오는 선언이 아니라 바닥에서 올라오는 실천. 이 두 방향이 만나는 어딘가에서, 우리는 비로소 한국형 AX의 첫 모양을 잡을 수 있다.

모델의 크기가 아니라 닿는 깊이가 혁신의 진짜 지표다. 그리고 그 깊이는 늘 작은 책상에서부터 시작한다.

이 글은 2026년 4월 14일 공공 정책·보안 실무자·위원 대상으로 발표한 키노트의 내용을 블로그 형태로 정리한 것이다. 함께 고민할 분들이 많아지기를 바란다.

SNS 타임라인에 자주 도는 "멀티 에이전트 7가지 패턴". 이름만 다르고 본질은 겹치는 것들이 많다. 실무에 쓸 수 있게 풀어 본다.

SNS에서 "멀티 에이전트 7가지 유형" 같은 카드가 심심하면 한 번씩 돕니다. 이름은 제각각이지만 한 걸음 뒤에서 보면 많은 유형이 겹쳐 있습니다. 이 글의 목적은 두 가지입니다. 첫째, 일곱 가지 이름을 한 번에 정리해서 다시는 단어만 보고 헷갈리지 않게 만드는 것. 둘째, 각 유형이 언제 쓸모 있고 언제 오히려 해가 되는지까지 풀어 두어서 실제로 프로젝트에 적용할 때 참고 가능한 지도가 되는 것입니다.

이 분류가 다루는 것은 "어떻게 여러 AI 에이전트를 하나의 일에 묶을 것인가"입니다. 하나의 에이전트로 다 하면 되는 경우도 많지만, 작업이 커지거나 품질 요구가 높아지면 에이전트를 여러 대 엮어 쓰는 순간이 옵니다. 그때 어떻게 엮느냐가 이 일곱 가지입니다.

01 / 뼈대본질은 두 축이다

본격적인 유형 설명에 들어가기 전에 뼈대부터 짚고 가는 편이 낫습니다. 일곱 가지라는 수에 속지 않으려면 이 두 축을 먼저 머리에 그려 두세요.

일곱 가지 유형은 실제로는 이 두 축의 조합과 변형입니다. 오케스트레이터형은 "위계 + 병렬", 파이프라인형은 "위계 + 순차", 피어 협업형은 "수평 + 병렬"에 가깝습니다. 나머지(토론, 라우팅, 계층, 자기성찰)는 이 조합을 약간 비튼 것이거나 특수 목적으로 특화한 변형입니다. 그래서 새 카드가 떠도 당황하지 말고 이게 어느 축의 조합인가만 물어보면 대부분의 안개가 걷힙니다.

02 / 유형 1오케스트레이터형 — 팀장이 일을 쪼개서 나눠 준다

한 에이전트가 "대장" 역할을 맡고, 작업을 잘게 쪼개서 여러 서브 에이전트에게 병렬로 분배합니다. 대장은 지시와 취합만 하고, 실제 수행은 서브들이 동시에 진행합니다.

오케스트레이터
  ├── 서브A: "1장을 써"
  ├── 서브B: "2장을 써"
  └── 서브C: "3장을 써"
           ↓
       결과 취합

직장 비유는 팀장이 회의록을 보면서 "너는 현황, 너는 문제점, 너는 제안"이라고 동료들에게 분배한 뒤 각자가 써 온 것을 합치는 모습입니다. 각자의 일이 서로 독립적이라면 병렬로 진행할 수 있어 시간이 크게 단축됩니다.

02 / 유형 2파이프라인형 — 공정 라인처럼 한 단계씩

A 에이전트의 출력이 B 에이전트의 입력이 되고, B의 출력이 C의 입력이 되는 순차 구조입니다. 각 단계는 앞 단계의 결과를 받아 다음 단계로 넘깁니다.

리서처 → 요약 → 작성 → 검토 → 최종 출력

직장 비유는 제조 공장의 컨베이어 벨트입니다. 조립 → 검사 → 포장 → 출하. 각 공정은 앞 공정의 결과물 위에서만 일을 합니다. 오케스트레이터형과의 결정적 차이는 동시에 일하느냐(오케스트레이터) 순서대로 일하느냐(파이프라인)입니다.

03 / 유형 3피어 협업형 — 동등한 전문가들의 회의

서로 다른 전문성을 가진 동등한 에이전트들이 같은 문제에 대해 각자 의견을 내고 교환하며 결론으로 수렴합니다. 대장 없이 수평 관계로 진행됩니다.

법무 에이전트 ↔ 기술 에이전트 ↔ 마케팅 에이전트
        (서로 의견 교환 → 충돌 → 수렴 → 결론)

직장 비유는 부서 간 협의회입니다. 새 제품 출시를 앞두고 법무팀·기술팀·마케팅팀이 한 자리에 모여 각자 관점에서 검토 의견을 내고 그것들을 엮어 통합 결론을 만듭니다. 한 사람이 혼자 쓴 보고서보다 각 관점이 충돌하고 수렴한 결과가 품질이 높을 때가 있습니다.

04 / 유형 4토론·검증형 — 변호사 vs 변호사 vs 판사

피어 협업의 특수 변형입니다. 한 에이전트가 초안이나 주장을 내면, 다른 에이전트가 그것을 공격합니다. 반론이 돌아오고, 또 재반론이 이어집니다. 마지막에 심판 역할의 에이전트가 양쪽을 보고 최종 결론을 내립니다.

에이전트A: 초안 작성
에이전트B: "이 부분은 틀렸어, 왜냐면..."
에이전트A: "그 반론에 대한 재반박은..."
에이전트C (심판): 최종 판단

직장 비유는 법정의 변호사·검사·판사 구도, 또는 학술 논문의 동료 심사(peer review) 과정입니다. 일부러 의견을 맞세워서 약점을 찾아내는 구조입니다. 피어 협업형과의 차이는 "협력적 토론"이 아니라 "적대적 검증"이라는 점입니다.

05 / 유형 5전문가 라우팅형 — 콜센터 교환원

한 라우터 에이전트가 먼저 입력을 분석해 적합한 전문 에이전트에게 전달합니다. 각 전문 에이전트는 자기 영역만 다루고, 서로 상호작용하지 않습니다.

라우터 에이전트
  ├── "법무 질문"  → 법무 전문 에이전트
  ├── "코드 질문"  → 코딩 전문 에이전트
  └── "디자인 질문" → 디자인 전문 에이전트

직장 비유는 콜센터 교환원입니다. 고객이 전화를 걸면 교환원이 "아 이건 기술 지원 건이네요, 2번 누르시면 연결됩니다"라고 담당 부서로 연결해 줍니다. 교환원 자신은 기술 지원을 하지 않습니다. 연결만 합니다. 재밌는 점은 이 구조가 대형 LLM 내부의 MoE(Mixture of Experts) 아키텍처와 개념이 같다는 것입니다. 거대 모델이 내부적으로 하는 일을 에이전트 레벨에서 재현한 셈입니다.

06 / 유형 6계층형 — 조직도를 그대로 AI로 옮기다

오케스트레이터 위에 또 오케스트레이터가 있는 구조입니다. 최상위가 중간 오케스트레이터들에게 대분류 작업을 맡기고, 중간들이 다시 각자의 서브 에이전트들에게 세부 작업을 분배합니다.

최상위 오케스트레이터
  ├── 중간 오케스트레이터 A
  │     ├── 서브 A1
  │     └── 서브 A2
  └── 중간 오케스트레이터 B
        ├── 서브 B1
        └── 서브 B2

직장 비유는 대기업 본사·지사·팀 체계를 그대로 옮긴 모습입니다. 복잡해 보이지만 실체는 "본사가 지사에게 지시 → 지사가 팀에 지시 → 팀원이 실제 작업"이라는 익숙한 보고 체계입니다.

07 / 유형 7자기성찰형 — 작가의 퇴고 루프

엄밀히 말하면 "멀티 에이전트"가 아니라 단일 에이전트의 반복 루프이지만, SNS에서는 보통 함께 묶입니다. 한 에이전트가 초안을 만들고, 같은 에이전트(혹은 비평 모드로 전환된 동일 에이전트)가 자기 작업을 비판한 뒤, 그 피드백을 반영해 다시 개선합니다.

에이전트 → 초안 생성
       ↓
에이전트 (비평 모드) → "이 초안의 문제점:"
       ↓
에이전트 (개선 모드) → 수정본
       ↓ (n회 반복)
최종 결과물

직장 비유는 작가의 퇴고 과정입니다. 쓰고 → 다시 읽고 → 고치기를 반복합니다. 혹은 코드 리뷰 문화 중 "셀프 리뷰"가 여기에 해당합니다. 개념적 뿌리는 2023년의 Reflexion 논문과 Self-Refine 기법입니다.

08 / 고르기어떤 때 어떤 유형을 쓰나

실무에서 유형 선택은 "있어 보이는 걸 쓰고 싶다"로 가서는 안 됩니다. 문제의 모양이 먼저고, 유형은 그 모양을 담는 그릇입니다. 다음 질문을 차례로 던져 보면 대체로 답이 나옵니다.

• 작업이 서로 독립적으로 쪼개지는가? → 오케스트레이터형
• 앞 단계 결과가 다음 단계 입력으로 반드시 필요한가? → 파이프라인형
• 정답이 없고 다관점 검토가 필요한가? → 피어 협업형
• 환각 방지와 팩트체크가 절대적으로 중요한가? → 토론·검증형
• 입력의 종류가 다양하고 각각 전문 처리가 필요한가? → 전문가 라우팅형
• 프로젝트가 초대형이고 조직 구조를 반영해야 하는가? → 계층형
• 단일 에이전트의 품질을 한 단계 더 올리고 싶은가? → 자기성찰형

처음 시작하는 분께 권하는 것은 오케스트레이터형과 파이프라인형입니다. 구조가 단순해서 실패 지점이 명확하고, 디버깅이 쉽습니다. 나머지는 이 두 가지로 해결되지 않는 고유한 문제가 있을 때 선택하는 특수 도구에 가깝습니다.

09 / 프레임워크어떤 프레임워크가 어떤 유형에 강한가

유형을 고르고 나면 어떤 프레임워크로 만들지 결정하게 됩니다. 각 프레임워크는 특정 유형에 자연스럽게 맞도록 설계되어 있어서, 강점을 알고 고르는 편이 편합니다.

주의할 점 하나. 프레임워크에 매몰되지 마세요. 문제의 모양에 맞는 유형을 먼저 고르고, 그에 자연스러운 프레임워크를 따라가는 순서가 맞습니다. 유행하는 프레임워크로 시작해 억지로 유형을 맞추면 비용만 늘고 품질은 안 오릅니다.

10 / 맺음결국 본질은 두 축이다

정리하면, 일곱 개 유형은 "있어 보이게" 세분한 측면이 있습니다. 본질은 두 축, 통제 구조(위계 vs 수평)와 실행 순서(병렬 vs 순차)로 충분히 설명됩니다. 나머지는 이 두 축의 변형과 조합입니다.

유형이 먼저가 아니라 문제가 먼저다. 패턴은 이름이 아니라 그릇일 뿐이고, 그릇은 담을 것이 있어야 의미가 있다.

CDSA 전문인재 과정에서도 이 분류를 가르칠 때 우리는 늘 두 축으로 먼저 내립니다. 그다음에 일곱 가지 이름을 붙여 주면 수강생들이 훨씬 덜 헷갈립니다. 현장에서 에이전트 아키텍처를 설계할 때도 같은 순서입니다. 문제의 모양부터 보고, 축을 정하고, 유형을 고르고, 프레임워크를 따라갑니다. 그 반대로 하면 대개 비용만 늘어납니다.

다음 글에서는 이 일곱 가지 중 가장 기본인 오케스트레이터형과 파이프라인형을 Claude Code와 파이썬 수준에서 아주 작게 만들어 보는 실습 루틴을 정리해 보겠습니다. 읽는 것만으로는 한계가 있으니, 한 번쯤 직접 돌려 보는 경험이 필요합니다.

도구라는 말은 편하지만 손에 잘 잡히지 않는다. 채팅창 뒤에 무엇이 있어야 MCP 클라이언트가 제대로 작동하는가.

도구라는 표현은 편하지만 초보자에게는 너무 뭉뚱그려져 있어서 손에 잘 안 잡힙니다. 그래서 여기서는 도구라는 말을 가능한 한 기능 단위로 풀어서 설명하겠습니다. MCP를 이해할 때 중요한 것은 추상적인 도구 개념이 아니라, 실제로 어떤 입력이 들어가고 어떤 처리가 일어나며 어떤 결과가 돌아오는지입니다.

예를 들어 사용자가 "김민수 과장 이메일 알려줘"라고 물었다고 하겠습니다. 이때 시스템 안에서 일어나는 일은 막연한 도구 사용이 아닙니다. 실제로는 다음 같은 처리가 일어납니다.

• 직원정보 테이블에서 이름이 김민수인 행을 찾습니다.
• 그 행의 직급이 과장인지 확인합니다.
• 이메일 컬럼 값을 꺼냅니다.
• 찾은 값을 모델에게 다시 넘깁니다.

즉, 여기서 말하는 기능은 "주소록 검색"이라는 추상 단어가 아니라, 더 구체적으로는 employee_name="김민수"를 입력으로 받아 직원 DB를 조회하고, 결과로 email="..." 값을 돌려주는 실행 단위입니다.

사용자가 "지난달 매출 감소 원인을 요약해줘"라고 물으면 마찬가지입니다. 여기서도 실제 내부 동작은 막연한 도구 호출이 아닙니다.

• 매출 테이블에서 지난달 데이터를 조회합니다.
• 전달 데이터와 비교합니다.
• 감소한 항목을 정렬합니다.
• 관련 회의록이나 메모를 찾습니다.
• 그 결과를 바탕으로 요약 문장을 생성합니다.

이처럼 MCP에서 말하는 것은 사실상 작은 기능 API들의 묶음이라고 보는 편이 더 정확합니다. 파일 목록 가져오기, 특정 문서 본문 읽기, 특정 기간의 매출 데이터 조회, 고객 ID로 주문 내역 조회, 노션 페이지 새로 생성하기, 이메일 초안 저장하기 같은 것들이 전부 여기에 들어갑니다.

따라서 MCP 서버를 만든다는 말은 거창한 무언가를 만든다는 뜻이 아니라, 이런 실행 가능한 기능들을 모델이 일정한 방식으로 호출할 수 있게 정리해 놓는다는 뜻입니다.

01 / 기능의 네 가지 유형직접 보이는 형태로 다시 설명하면

직접 만드는 MCP 시스템에서 모델이 사용할 수 있는 것은 대개 아래처럼 생긴 기능들입니다. 뭉뚱그린 "도구"가 아니라, 입력과 처리와 출력이 분명한 네 가지 결의 실행 단위로 나누어 보면 훨씬 또렷하게 보입니다.

1. 조회형 기능

이 종류는 어딘가에 이미 들어 있는 값을 읽어오는 기능입니다. 예를 들면 이런 것들입니다.

• get_employee_email(name)
• find_sales_data(month)
• read_file(path)
• search_notion(keyword)
• get_customer_orders(customer_id)

이 기능들은 입력값이 들어오면 저장소나 외부 시스템에서 값을 읽어서 반환합니다. 예를 들어 read_file(path)는 입력이 파일 경로이고, 출력은 파일 본문입니다. get_customer_orders(customer_id)는 입력이 고객번호이고, 출력은 주문 목록입니다.

2. 생성형 기능

이 종류는 새로운 결과물을 만드는 기능입니다. 예를 들면 이런 것들입니다.

• create_notion_page(title, content)
• draft_email(to, subject, body)
• generate_report(data)
• summarize_meeting_notes(text)

이 기능들은 단순 조회가 아니라 새 문서나 새 텍스트를 만듭니다. 예를 들어 create_notion_page는 제목과 본문을 입력받아 노션에 새 페이지를 생성합니다. draft_email은 받는 사람, 제목, 본문을 받아 이메일 초안을 저장합니다.

3. 실행형 기능

이 종류는 실제로 어떤 행동을 일으키는 기능입니다. 예를 들면 이런 것들입니다.

• send_email(draft_id)
• create_calendar_event(date, title)
• approve_request(id)
• run_python_code(code)
• start_batch_job(job_name)

이 기능들은 결과를 읽어오는 수준이 아니라 시스템 상태를 바꿉니다. 그래서 권한과 승인 통제가 중요합니다.

4. 변환형 기능

이 종류는 입력 데이터를 다른 형태로 바꾸는 기능입니다. 예를 들면 이런 것들입니다.

• extract_text_from_pdf(file)
• convert_excel_to_json(file)
• translate_text(text, lang)
• classify_document(text)
• extract_table_from_image(image)

이 기능들은 입력을 받아 가공한 뒤 새로운 구조의 결과를 돌려줍니다.

즉, MCP에서 모델이 다루는 것은 추상적인 마법 상자가 아니라, 실제로는 이런 개별 기능들입니다. 입력이 있고, 내부 처리 로직이 있고, 출력이 있는 아주 구체적인 실행 단위들입니다.

02 / 핵심그러면 왜 에이전트 서버가 핵심인가

이제 여기서 핵심이 보입니다. 사용자가 직접 MCP 클라이언트를 만든다고 했을 때, 실제 어려운 부분은 이 기능들을 화면에 예쁘게 보여주는 것이 아닙니다. 더 중요한 것은 사용자의 질문을 보고 어떤 기능을 언제 어떤 순서로 호출할지 결정하고, 그 결과를 다시 모델에게 넣어 최종 답을 완성하는 흐름을 통제하는 것입니다.

예를 들어 사용자가 "지난달 매출 감소 원인 정리해서 노션에 회의자료 초안까지 만들어줘"라고 말하면, 실제 내부 흐름은 대략 이렇게 됩니다.

• find_sales_data("지난달") 실행
• 전달 비교 데이터 조회 실행
• 감소 폭 큰 항목 정리
• 관련 회의록 검색 실행
• 검색 결과와 매출 결과를 합쳐 요약 생성
• create_notion_page(title, content) 실행
• 생성된 페이지 주소를 사용자에게 반환

여기서 중요한 것은 어느 한 기능이 아니라 이 전체 호출 흐름입니다. 이 흐름을 누가 관리하느냐가 핵심인데, 그 역할을 맡는 것이 에이전트 서버입니다.

즉, 직접 만드는 MCP 클라이언트에서 본질은 채팅창이 아니라 다음을 처리하는 서버입니다.

• 어떤 기능 목록을 현재 사용할 수 있는지 알고 있습니다.
• 사용자의 질문을 보고 필요한 기능 후보를 좁힙니다.
• 기능 호출에 필요한 입력값을 정리합니다.
• 여러 기능을 순서대로 실행합니다.
• 실패 시 재시도하거나 다른 경로로 우회합니다.
• 민감한 기능은 차단하거나 승인 절차를 거치게 합니다.
• 최종 결과를 사용자 문장으로 정리합니다.

이것이 없으면 화면은 있어도 제대로 동작하는 MCP 클라이언트가 되지 않습니다.

03 / 착시유명한 MCP 클라이언트가 왜 쉬워 보이는가

Claude Desktop이나 Cursor 같은 이미 완성된 제품은 이 중간 조정 계층이 이미 안에 들어 있습니다. 그래서 사용자는 마치 모델이 바로 MCP 기능을 쓰는 것처럼 느낍니다.

하지만 직접 만들 때는 다릅니다. 브라우저에 채팅창을 하나 띄운다고 끝나지 않습니다. 채팅창 뒤에서 다음을 담당하는 서버가 반드시 있어야 합니다.

• 연결된 MCP 서버 목록 관리
• 각 기능의 이름, 설명, 입력 형식 관리
• 모델 호출과 기능 호출 사이의 왕복 처리
• 대화 세션 저장
• 사용자별 권한 확인
• 호출 로그 저장
• 실패 상황 대응

이 계층이 바로 에이전트 서버입니다. 그래서 직접 만드는 MCP 클라이언트는 정확히 말하면 클라이언트를 만드는 작업이 아니라, MCP 기능들을 안전하고 순서 있게 실행시키는 에이전트 서버를 만들고 그 위에 화면을 얹는 작업에 가깝습니다.

04 / 정리아주 현실적인 기준으로 다시

직접 만드는 MCP 시스템에서 모델이 쓰는 것은 추상적인 도구가 아니라 아래 같은 실행 함수들입니다.

• 직원 이름으로 이메일 찾기
• 특정 월 매출 데이터 가져오기
• 파일 경로로 문서 본문 읽기
• 고객번호로 주문내역 조회하기
• 회의록 본문 요약하기
• 노션 페이지 만들기
• 이메일 초안 저장하기
• 일정 등록하기

그리고 에이전트 서버는 이 함수들을 적절한 순서로 조합해서 하나의 업무 흐름으로 만드는 계층입니다.

즉, 직접 만드는 MCP 클라이언트의 핵심은 채팅창이 아니라 함수 호출 흐름 제어기라고 이해하는 편이 훨씬 손에 잡힙니다.

05 / 한 줄 결론흐름 제어기가 먼저다

유명한 MCP 클라이언트는 이미 내부에 함수 호출 흐름 제어기가 들어 있어서 편해 보이는 것이고, 사용자가 생짜로 직접 만들 MCP 클라이언트는 결국 그 함수 호출 흐름 제어기 — 즉 에이전트 서버를 먼저 만들어야 제대로 작동합니다.

화면은 그다음입니다.

용어를 아는 것은 좋은 출발점이다. 다만 그 자리에서 한 걸음만 더 들어가면, 훨씬 또렷하게 보이는 풍경이 있다.

최근 AI 실무 커뮤니티에서 "하네스(harness)"라는 단어가 부쩍 자주 들린다. 에이전트 아키텍처를 말할 때, 프롬프트 엔지니어링의 한계를 지적할 때, 그리고 자연스럽게 — 모델의 바깥 껍데기를 이야기할 때. 새 용어가 생기고 유통되는 것 자체는 반가운 일이다. 현업에서 어떤 현상이 충분히 자주 반복되면 그것에 이름을 붙이는 것이 생산적인 대화를 가능하게 한다.

다만 이름을 얻은 뒤에는 한 걸음 더 들어갈 차례가 온다. 용어만 주고받는 대화는 어느 지점에서부터 실체로부터 멀어지기 때문이다. 나 역시 이 단어를 한참 흘려 듣다가, 어느 날 문득 질문이 막혔다. "그래서 하네스라는 게 내 컴퓨터 어디에 있는 건데?" 개념으로는 얼핏 알 것 같은데, 손으로 가리킬 수가 없었다.

이 글은 그 질문에 답해 보려는 기록이다. 비슷한 지점에서 막혀 있을지 모르는 분들을 염두에 두고, 가능한 한 구체적인 파일과 폴더 단위까지 내려가 정리해 보려 한다. 개념과 실체 사이의 거리를 좁히는 일은 생각보다 짧은 산책이다.

01 / 정의하네스는 "모델을 실제로 돌리는 바깥 껍데기"다

대형 언어 모델 자체는 함수 하나에 가깝다. 텍스트가 들어오면 텍스트를 뱉는다. 그 이상도 이하도 아니다. 파일을 읽지 못하고, 이전 대화를 기억하지 못하고, 웹을 검색하지도 못한다. 우리가 Claude Code나 Cursor에서 목격하는 "지능적인 행동"은 모델 자체의 속성이 아니라, 그 모델을 감싸고 있는 외부 프로그램이 매 턴마다 열심히 부리는 일이다.

그 외부 프로그램이 하네스다. 조금 더 풀어 쓰면, 사용자 입력을 받아 모델에 넘기고, 모델이 "이 툴 써줘"라고 요청하면 진짜로 그 툴을 실행해 결과를 다시 모델에게 돌려주고, 대화 히스토리를 관리하며 이 과정을 반복하는 — 루프 한 덩어리다. 파이썬 파일 하나로도 쓸 수 있다. while 문이 두 개 겹쳐 있으면 된다.

단어의 내력을 짧게 덧붙여 두고 싶다. 영어 harness는 원래 말의 몸에 씌워 고삐를 잡는 마구(馬具)를 뜻한다. 말을 직접 움직이는 건 말 자신이지만, 마구가 없으면 사람이 그 힘을 원하는 방향으로 쓸 수 없다. 머신러닝 연구 쪽에서는 이 비유를 가져와 EleutherAI의 lm-evaluation-harness처럼 모델의 성능을 평가하기 위해 바깥에서 씌우는 프로그램을 하네스라 부르기 시작했고, 최근 에이전트 도구들이 유행하면서 의미가 확장되어 "모델을 감싸 실제로 돌리는 바깥 프로그램" 전반을 가리키게 되었다. 그래서 문맥에 따라 뉘앙스가 조금씩 다를 수 있다는 점만 알아 두면 충분하다.

그러므로 우리가 에이전트 도구를 "만든다"고 할 때 그것은 곧 하네스를 만드는 일이고, 이미 만들어진 에이전트 도구 — Claude Code나 Cursor 같은 것들 — 를 "쓴다"는 것은 곧 남이 만든 하네스 안에서 대화가 돌아간다는 뜻이다.

02 / 구분프롬프트, 컨텍스트, 하네스는 서로 다른 층위다

한 가지 먼저 짚고 가면 좋을 구분이 있다. 세 단어는 비슷해 보이지만 층위가 서로 다르다.

프롬프트가 한 장의 종이라면, 컨텍스트는 그 종이가 담긴 서류철이고, 하네스는 매일 아침 어떤 서류를 꺼내 철할지 결정하는 비서다. 세 층위가 뭉개진 채 대화가 흐를 때 우리가 느끼는 안개는 대개 이 구분이 흐려져서다.

03 / 실체60줄이면 하네스 한 대가 완성된다

말만으로는 부족하니 코드를 보자. 아래는 실제로 돌아가는 파이썬 하네스의 전체다. 저장한 뒤 python my_harness.py를 치면, 그 순간부터 여러분의 손으로 만든 작은 에이전트가 돌아간다. bash 툴 하나만 물려 있어도 "내 다운로드 폴더에 뭐 있어?"라고 물으면 진짜로 ls를 실행해 답한다.

# my_harness.py
import anthropic, subprocess

client = anthropic.Anthropic()

tools = [{
    "name": "run_bash",
    "description": "쉘 명령어 실행",
    "input_schema": {
        "type": "object",
        "properties": {"cmd": {"type": "string"}},
        "required": ["cmd"]
    }
}]

def run_tool(name, args):
    if name == "run_bash":
        return subprocess.run(
            args["cmd"], shell=True,
            capture_output=True, text=True
        ).stdout

messages = []

while True:
    user_input = input("나: ")
    if not user_input: break
    messages.append({"role": "user", "content": user_input})

    while True:
        resp = client.messages.create(
            model="claude-opus-4-6",
            max_tokens=4096,
            tools=tools,
            messages=messages,
        )
        messages.append({"role": "assistant", "content": resp.content})

        if resp.stop_reason != "tool_use":
            print("클로드:", resp.content[-1].text)
            break

        tool_results = []
        for block in resp.content:
            if block.type == "tool_use":
                result = run_tool(block.name, block.input)
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": result,
                })
        messages.append({"role": "user", "content": tool_results})

이것이 하네스의 뼈대다. 바깥 루프는 사람과의 턴을 굴리고, 안쪽 루프는 모델이 툴을 그만 쓸 때까지 모델과 툴 사이를 왕복한다. Claude Code나 Cursor 같은 프로덕션 도구들이 본질적으로 하는 일도 여기서 크게 벗어나지 않는다. 다만 그들은 이 뼈대 주변에 수천, 수만 줄의 관리 레이어를 덧대 놓았을 뿐이다.

04 / 지도그 많은 설정 파일들은 대체 어디에 있는가

여기서 잠깐 궤도를 낮추고 싶다. 개발자가 아닌 분들이 Claude Code를 설치한 뒤 가장 당혹스러워하는 지점이, "분명히 뭔가 설정을 하라는데 그 파일이 어디 있는지 모르겠다"는 것이다. 실은 어려운 이야기가 아니다. 파일과 폴더의 주소만 알면 된다.

핵심 규칙은 단 하나다. Claude Code의 설정 파일은 두 곳에 나뉘어 산다. 하나는 집(컴퓨터 전체)에 있고, 다른 하나는 사무실(지금 작업 중인 프로젝트 폴더)에 있다. 집에 둔 물건은 어느 프로젝트를 열든 따라오고, 사무실에 둔 물건은 그 프로젝트 안에서만 쓰인다.

정리하면 이렇다. 홈 폴더의 ~/.claude/는 "어디서든 적용되는 내 취향"을 담는 서랍이고, 프로젝트 폴더의 ./.claude/와 ./CLAUDE.md는 "이 작업에서만 쓸 규칙"을 담는 서랍이다. 이 두 서랍의 차이를 구분하는 순간, 문서에 등장하는 경로 이름들이 훨씬 덜 무서워진다.

05 / 관리 레이어프로덕션 하네스에 실제로 붙어 있는 것들

다시 하네스의 몸통으로 돌아가자. 60줄짜리 뼈대 주변에 실제로 어떤 살이 붙어 있는지, 하나씩 뜯어 보면 각각은 의외로 소박하다. 다만 소박한 것들이 모이면 꽤 두툼해진다.

컨텍스트 윈도우 관리

모델은 한 번에 200K 토큰 정도밖에 받을 수 없다. 실제 세션은 몇 시간씩 가고, 파일 수십 개를 읽고, 명령어 결과가 수백 줄씩 쌓인다. 그래서 하네스는 매 턴마다 토큰 수를 재고, 한계의 80% 즈음이 되면 옛 메시지를 모델에게 다시 넘겨 요약시킨 뒤 원본을 요약본으로 교체한다. Claude Code의 /compact가 이 동작이다. 마법이 아니라 "요약해줘"를 자동으로 한 번 더 호출하는 것이다.

다만 이 요약 과정이 생각보다 섬세하다. 대화 도중에 모델이 어떤 툴을 호출했다면, 그 '호출(tool_use)'과 '결과(tool_result)'는 반드시 쌍으로 붙어 있어야 한다. 한쪽만 잘라내면 API가 "호출에 대응하는 결과가 없다"며 통째로 거절해 버리기 때문이다. 그래서 요약을 할 때 하네스는 이런 쌍을 건드리지 않도록 조심해야 하고, 어떤 메시지는 요약하고 어떤 메시지는 원본 그대로 남길지 나름의 규칙을 갖는다. "옛 메시지 요약해서 교체"라는 한 줄이 실제로는 이런 자잘한 판단들의 연쇄다.

프롬프트 캐싱

한 가지 더 챙겨 두면 좋은 개념이 있다. Claude API에는 프롬프트 캐싱이라는 기능이 있다. 매 호출마다 앞부분 — 시스템 메시지, 긴 문서, 툴 정의 같은 것 — 이 거의 동일하다면, 그 부분을 서버 쪽에 캐시해 두고 다음 호출에서는 "그 부분은 다시 계산하지 말고 캐시에서 꺼내"라고 지시할 수 있다. 잘 쓰면 속도가 빨라지고 비용이 상당히 줄어든다.

다만 캐시 표시를 어디에 붙이느냐에 따라 효과가 천차만별이다. 변하지 않는 부분의 끝 지점에 정확히 걸어 두어야 하는데, 경계를 잘못 잡으면 캐시가 매 호출마다 깨져서 오히려 느려지고 비싸진다. 프로덕션 하네스의 숨은 노력 중 상당 부분이 "어디에서 잘라야 캐시가 최대한 살아남을까"를 고민하는 일이다.

장기기억

모델은 대화가 끝나면 전부 잊는다. 그래서 "기억"은 전적으로 하네스가 디스크에 파일로 저장하는 방식으로 구현된다. 앞서 본 CLAUDE.md, ~/.claude/CLAUDE.md, 세션 JSON 파일이 모두 그 구체물이다. 하네스는 세션을 시작할 때 이런 파일을 읽어 시스템 프롬프트 앞에 붙인다. claude.ai의 메모리 기능도 기본 원리는 같다. 별도 저장소에 사용자별 사실 목록을 두고, 대화 시작 시 관련된 것만 골라 컨텍스트에 주입한다. 기본형의 장기기억은 결국 파일을 읽어 프롬프트 앞에 붙이는 일이다.

다만 이 방식은 장기기억의 가장 단순한 형태라는 점을 덧붙여 두고 싶다. 반복 작업이 많아지고 누적된 지식의 양이 커지면, 파일 한 덩어리를 통째로 붙이는 방식만으로는 버티기 어려운 순간이 온다. 파일이 수만 자를 넘기면 매 호출마다 그 전체를 컨텍스트에 붙이기엔 너무 무겁고, 정작 지금 필요한 정보는 그 안의 몇 줄뿐이기 때문이다.

그래서 요즘 나오는 에이전트 도구들은 한 단계 더 들어간 방식을 함께 쓴다. 기억을 파일 한 덩어리로 두지 않고, 로컬 스토리지나 외부 메모리 서비스 — Mem0, Zep, Letta, Graphiti 같은 것들 — 에 지식 그래프(knowledge graph) 형태로 쪼개 저장하는 것이다. 사람과 프로젝트, 개념과 마감일, 사건과 결론 사이의 관계를 노드와 엣지로 구조화해 두고, 대화 중에는 그 그래프를 탐색해 관련된 노드만 골라 꺼낸다. 벡터 임베딩 기반의 검색(RAG)도 같은 계열의 접근이다. 긴 문서를 토막 내 임베딩해 저장해 두고, 현재 질문과 의미적으로 가까운 조각만 골라 맥락에 주입한다.

앞서 본 CLAUDE.md 방식과 이 방식의 결정적인 차이는 선택적 회상의 유무다. 파일 방식은 전체를 통째로 읽어 붙이기 때문에 "모든 것을 기억하되 매번 전부 꺼낸다." 반면 지식 그래프 방식은 엄청나게 많은 정보를 저장해 두고도, 매 턴마다 꼭 필요한 조각만 꺼내 붙인다. 후자가 훨씬 많은 양을 "기억"할 수 있는 이유가 여기에 있다. 개인이 오랜 기간 쌓은 작업 히스토리나 조직의 지식 자산처럼 규모가 큰 기억을 다룰 때, 파일 방식으로는 한계가 분명하기에 사람들은 이 구조화된 저장소 쪽으로 옮겨 간다.

다만 한 가지는 바뀌지 않는다. 지식 그래프든 벡터 검색이든, 꺼낸 결과는 결국 텍스트로 변환되어 컨텍스트 창에 주입된다는 점이다. 모델은 여전히 "한 번에 입력받는 텍스트"밖에 참조할 수 없기 때문이다. 그래서 장기기억의 진짜 싸움은 "어떻게 저장하느냐"보다 "매 순간 무엇을 골라 꺼내느냐"에 있다. 저장은 하네스 바깥의 데이터베이스나 메모리 서비스가 맡더라도, 꺼낸 결과를 어떻게 추려 프롬프트에 얹을지 결정하는 것은 다시 하네스의 일이다. 바깥 저장소는 도서관이고, 하네스는 그 도서관에서 오늘 필요한 몇 페이지만 골라 책상 위에 올려 주는 사서인 셈이다.

슬래시 명령어

/compact, /clear, /model 같은 명령어는 모델에게 가지 않는다. 하네스가 사용자 입력을 모델로 보내기 직전에 가로채서 자체적으로 처리한다. 루프 안의 간단한 if 분기 하나다. 사용자 정의 슬래시 명령어(.claude/commands/ 폴더의 md 파일)도 마찬가지다. 해당 파일 내용을 읽어 유저 메시지처럼 꾸며 모델에 전달하는 매크로에 가깝다.

MCP (Model Context Protocol)

툴을 하네스 코드에 하드코딩해 두면, 새 툴을 추가할 때마다 프로그램 자체를 고쳐야 한다. 이 문제를 해결하기 위해 툴 목록을 외부 프로세스(MCP 서버)에게 동적으로 물어오는 규격이 만들어졌다. 하네스는 시작할 때 설정된 MCP 서버들을 자식 프로세스로 띄우고, "너 무슨 툴 갖고 있어?"를 물어 받은 목록을 자신의 기존 툴 배열에 합쳐 모델에게 제공한다. 모델 입장에서는 네이티브 툴인지 MCP 툴인지 구분할 수 없다. 그저 툴 이름이 늘어났을 뿐이다.

Skills

MCP가 "새로운 툴"을 꽂는 방식이라면, Skills는 "기존 툴로 어떻게 작업할지에 대한 레시피"를 모델에게 건네는 방식이다. 구현은 훨씬 가볍다. 특정 폴더에 SKILL.md라는 마크다운 매뉴얼을 깔아두면, 하네스는 세션 시작 시 그 이름과 설명만 시스템 프롬프트에 주입한다. 사용자가 "워드 문서 만들어줘"라고 하면 모델이 "아, docx 스킬이 있었지" 하고 스스로 그 SKILL.md를 view 툴로 읽어 지침을 따른다. 별도 프로세스도, 특별한 프로토콜도 없다. 그저 마크다운 파일이다.

스트리밍과 복구

stream=True로 호출하면 모델의 응답이 완성되기를 기다리지 않고, 토큰이 만들어지는 대로 화면에 흘려 보낸다. 터미널에서 답변이 한 글자씩 찍히는 그 연출이 이것이다. 다만 스트리밍은 중간에 끊길 수 있다. 네트워크가 불안정하거나, 툴 호출이 도중에 잘리거나, API가 속도 제한(rate limit)을 걸거나. 이럴 때 하네스는 그냥 에러를 띄우고 끝내지 않는다. 몇 초 기다렸다가 다시 시도하고(재시도 로직), 툴 호출이 중간에 끊겼으면 완결된 지점까지 되돌린다. 사용자 눈에는 보이지 않지만, 루프의 안쪽에는 이런 복구 코드가 꽤 두툼하게 깔려 있다.

그 외 자잘하지만 중요한 일들

• 권한 게이트위험한 명령어를 모델이 호출하면 실행 직전에 가로채 사용자에게 승인을 요청.
• Diff 렌더링파일 편집 결과를 색이 입혀진 diff로 터미널에 그려주기.
• 비용 추적매 호출의 usage를 누적해 세션별 토큰과 비용을 계산.
• 서브에이전트긴 작업은 별도 messages 배열로 새 루프를 띄워 컨텍스트를 격리. 부모 루프는 최종 결과만 받음.
• 체크포인트편집 전 파일 상태를 저장해 /undo가 가능하도록.

이 레이어들 중 어느 하나도 "개념적인" 것이 없다. 모두 코드로 구현되어 디스크 어딘가에 파일로 존재하는 구체물이다. 그리고 각각은 놀라울 만큼 소박한 아이디어에서 출발한다. 뼈대가 60줄이라는 말은 "60줄로 프로덕션 품질을 낼 수 있다"는 뜻은 아니다. Claude Code나 Cursor 같은 도구가 몇 시간짜리 세션을 버티게 만드는 힘은 결국 이런 관리 레이어 하나하나를 튼튼하게 만든 엔지니어링의 누적이다. 다만 그 누적이 어떤 신비로운 비법에서 오는 것이 아니라, 이해할 수 있는 작은 조각들의 합이라는 점이 이 글에서 전하고 싶은 이야기다.

06 / 오해"하네스 프롬프트"라는 말을 들었다면

이 글을 쓰던 중 주변에서 한 가지 질문을 받았다. "하네스 프롬프트라는 말을 어디서 들었는데, 이미 만들어진 에이전트 도구에 내가 만든 하네스를 프롬프트로 주입하면 그 도구가 내 하네스를 참고해서 작동한다는 뜻인가?" 실은 나도 이 말을 들을 때마다 조금씩 걸려 있었기에, 이번 기회에 정리해 두려 한다.

먼저 단호하게 말해 두면, "하네스 프롬프트"는 업계 표준 용어가 아니다. 현장에서 간혹 쓰이기는 하지만 화자마다 가리키는 바가 다르고, 대개는 서로 다른 세 가지를 뭉뚱그린 채 말하는 경우다. 세 가지를 구분해 두면 그 말이 들려올 때 곧바로 초점을 맞출 수 있다.

첫 번째 해석은 하네스 제작자가 도구 내부에 박아 둔 시스템 프롬프트를 가리키는 쓰임이다. Claude Code나 Cursor는 각자 수천 줄짜리 내부 지시문을 갖고 있고, 그것이 모델의 기본 성격과 행동 양식을 결정한다. 이걸 두고 "Claude Code의 하네스 프롬프트"라 부른다면 말은 된다. 다만 이건 사용자가 건드릴 수 있는 것이 아니라 도구 쪽에 박혀 있는 것이다.

두 번째 해석은 사용자가 일반 모델에게 "너는 이제부터 계획을 세우고, 툴을 호출하고, 결과를 보고 다시 계획하라"고 지시하는 프롬프트를 가리키는 쓰임이다. ReAct 패턴이라 부르는 기법이 대표적이다. 이것도 누군가는 "하네스 프롬프트"라 부를 수 있지만, 엄밀히는 하네스를 흉내 내게 만드는 프롬프트 기법에 가깝다. 외부에서 실제로 툴을 실행시키는 주체가 없기 때문에, 루프처럼 보여도 진짜 루프가 돌지는 않는다.

세 번째 해석은 앞선 질문자의 해석이다. "내가 만든 하네스를 기존 도구에 프롬프트로 주입해서 그 도구가 내 하네스를 참고해 작동하게 한다." 기술적으로 말하면 이 구도는 성립하지 않는다. 프롬프트는 텍스트이고, 하네스는 프로그램이다. 두 가지는 서로 다른 층위에 산다. Claude Code에게 "내가 만든 파이썬 하네스 코드를 보고 그 방식대로 작동해 줘"라고 아무리 텍스트를 넣어도, Claude Code는 여전히 자신의 while 루프를 돌린다. 그 텍스트는 그저 참고 자료로만 읽힐 뿐, 실행 구조 자체는 바뀌지 않는다.

그래서 "하네스 프롬프트"라는 말을 들었을 때 화자를 나무라기보다는, 조용히 한 가지만 되물어 보면 좋다. "지금 말씀하시는 게 도구 내부에 박힌 시스템 프롬프트를 뜻하시는 건가요, 아니면 모델에게 에이전트처럼 행동하라고 지시하는 ReAct 스타일 프롬프트를 뜻하시는 건가요?" 대개는 이 질문만으로 대화의 해상도가 한 단계 올라간다. 그리고 대답이 막힌다면, 그건 말하는 사람도 아직 정리가 끝나지 않은 상태라는 뜻이다.

07 / 확장내 손으로 하네스를 짓는다면

이 글을 여기까지 읽었다면, 자연스럽게 반대 방향의 질문이 떠오를 수 있다. "그러면 나는 Claude Code나 Cursor를 쓰지 않고, 내 용도에 맞는 내 하네스를 직접 만들 수도 있는가?" 결론부터 말하면 가능하다. 그리고 생각보다 가깝게 있다.

앞서 본 60줄짜리 파이썬 루프가 가장 짧은 출발점이다. 여기에 파일 편집 툴 몇 개, 히스토리 저장, 간단한 권한 확인 정도를 덧붙이면 500줄 안쪽에서 "내 컴퓨터에서 실제로 돌아가는 CLI 하네스"가 완성된다. 이미 이 방향으로 만들어진 오픈소스가 여럿 있다. Aider는 파이썬 CLI 하네스고, Open Interpreter는 로컬 코드 실행에 특화된 하네스고, Cline과 Continue는 VSCode 확장 형태의 하네스다. 전부 개인 혹은 소규모 팀이 만들었다. "개인이 만들기에는 너무 거대한 일"이 결코 아니라는 뜻이다.

현실적인 선택지를 정리하면 대체로 다섯 갈래다.

• CLI (파이썬)Most direct
  앞서 본 60줄이 출발점. Anthropic SDK와 subprocess만 있으면 된다. 터미널에서 돌아가는 가벼운 하네스가 목표라면 가장 짧은 길이다. 참고: Aider.
• Streamlit / GradioFastest UI
  하루 안에 챗봇 UI가 붙은 하네스가 완성된다. 파이썬 한 파일로 웹 화면까지 나오기 때문에, 비개발자가 "내 전용 AI 작업 공간"을 만들어 보기에 제일 진입 장벽이 낮은 길이다.
• Next.js + VercelWeb-native
  Node나 파이썬 백엔드에 React 프런트를 얹고 Vercel에 배포하는 방식. 이미 웹 SaaS를 만들어 본 경험이 있다면 가장 익숙한 스택이다. 세션 저장은 Supabase, 인증은 기존 방식 그대로 가져갈 수 있다.
• Electron 데스크톱Native feel
  Cursor가 사용하는 계열(정확히는 VSCode fork). 네이티브 앱처럼 설치되고 키보드 단축키와 파일 접근이 자유롭다. 대신 JavaScript/TypeScript 생태계에 어느 정도 익숙해야 한다.
• TauriLightweight alternative
  Electron보다 가벼운 Rust 기반의 데스크톱 앱 프레임워크. 최근 주목받는 선택지이지만 진입 장벽은 Electron과 비슷하거나 약간 더 높다.

여기서 중요한 관점 하나를 덧붙이고 싶다. 하네스를 직접 만든다는 말은 "Claude Code를 완전히 대체할 무언가를 만든다"는 뜻이 아니다. 프로덕션 품질로 가려면 앞서 본 관리 레이어들 — 컨텍스트 압축, 프롬프트 캐싱, 스트리밍 복구, 권한 게이트, 서브에이전트 — 을 모두 직접 구현해야 하는데, 이건 개인이 단기간에 따라잡을 수 있는 수준이 아니다. 그럴 필요도 없다.

대신 현실적인 길은 "내 반복 작업에 꼭 맞는 작은 전용 하네스"를 만드는 것이다. 공공기관 보고서 자동화 전용, 강의 슬라이드 생성 전용, 견적서/제안서 초안 전용 — 이런 식으로 도메인이 좁고 분명한 하네스는 일반 도구보다 오히려 더 잘 돌아간다. 일반 도구는 모든 작업을 조금씩 할 줄 알아야 하지만, 전용 하네스는 내 한 가지 작업만 아주 잘하면 되기 때문이다. 필요한 툴만 정확히 달아 두고, 그 작업에만 해당하는 규칙을 시스템 프롬프트에 박고, 완성된 결과를 내 폴더 구조 그대로 떨어뜨리면 된다.

이 관점에서 보면 하네스는 멀리 있는 엔지니어링이 아니라 가까운 생산 수단이다. 이미 내가 하고 있는 반복 작업이 있고, 그 작업의 모양을 가장 잘 아는 사람이 나라면, 그 작업에 꼭 맞는 루프를 씌울 권리도 결국 내게 있다. 남이 만든 일반 도구에 내 작업을 맞추는 것이 아니라, 내 작업에 맞는 작은 도구를 내 손으로 짓는 것 — 그 방향의 문은 지금도 열려 있다.

08 / 마무리용어에서 한 걸음, 실체로

다시 처음으로 돌아가 보자. 하네스라는 단어를 아는 것은 좋다. 새로운 어휘는 언제나 우리 사고의 해상도를 높인다. 다만 용어에서 멈추면 보이지 않는 것들이 있다. 그것이 어떤 파일로 내 컴퓨터 어느 폴더에 살고 있는지, 어떤 루프가 매 초 무엇을 반복하고 있는지, 어떤 부분이 진짜 어렵고 어떤 부분이 생각보다 소박한지, 그리고 내가 직접 만든다면 어디서부터 시작해야 하는지 — 이런 것들은 한 걸음 더 들어가야만 보인다.

이 글이 그 한 걸음의 지도가 되었으면 한다. 다음에 누군가 "하네스가 어쩌고"를 이야기할 때, 우리는 이제 머릿속에 구체적인 while 루프 하나를 그릴 수 있다. ~/.claude/CLAUDE.md와 ./.claude/settings.json이 어디 있는 어떤 파일인지 알고, 요약 압축이 어떤 순간에 트리거되는지 알며, 프롬프트 캐싱이 왜 경계선을 잘 잡아야 하는지 알고, MCP가 왜 별도 프로세스인지 알며, Skills가 그저 마크다운 파일임을 안다. "하네스 프롬프트"라는 말을 들으면 어느 층위를 묻고 있는지 되물을 줄 알고, 나아가 내 용도에 맞는 작은 하네스 하나를 내 손으로 시작해 볼 마음까지 낼 수 있다. 그 정도면 충분하다.

용어를 아는 것은 출발점이고, 실체를 아는 것은 산책의 끝이 아니라 그다음 질문으로 넘어갈 자격이다. 부디 함께 그다음 질문으로 가 보자.

어렵게 말하면 모델이 외부 기능을 표준 방식으로 발견하고 호출할 수 있게 해 주는 인터페이스 계층이다. 눈에 보이는 실행 흐름 기준으로 풀어 보자.

MCP 서버의 원리를 어렵게 말하면, 모델이 외부 기능을 표준 방식으로 발견하고 호출할 수 있게 해 주는 인터페이스 계층입니다. 그런데 이렇게 말하면 초보자에게는 거의 안 와닿습니다. 그래서 여기서는 눈에 보이는 실행 흐름 기준으로 설명하겠습니다.

핵심부터 말하면, MCP 서버는 AI가 어떤 기능을 쓸 수 있는지 목록으로 보여 주고, 그 기능을 어떤 형식으로 호출해야 하는지 알려 주고, 실제 호출이 들어오면 대신 실행해서 결과를 돌려주는 프로그램입니다. 즉, MCP 서버가 하는 일은 세 가지입니다.

• 사용할 수 있는 기능 목록을 공개한다.
• 각 기능의 입력 형식을 설명한다.
• 호출이 들어오면 실제 처리를 하고 결과를 반환한다.

이 세 가지가 MCP 서버의 원리입니다. 이제 하나씩 풀어 보겠습니다.

01 / 차이그냥 API 서버와 뭐가 다른가

보통 API 서버는 사람이 문서를 읽고 직접 붙입니다. 개발자가 API 문서를 보고 URL, 파라미터, 인증 방식, 응답 형식을 맞춰서 코드를 짭니다. 반면 MCP 서버는 모델이 읽고 쓰기 좋은 방식으로 기능을 정리해 둡니다. 즉, 사람이 API 문서를 해석하는 대신 모델이 기능 설명을 읽고 어떤 기능을 쓸지 판단할 수 있게 구조를 맞춰 둔 것입니다.

예를 들어 일반 API 서버라면 개발자가 이런 것을 직접 알아야 합니다.

• 어느 URL로 요청해야 하는지
• GET인지 POST인지
• 헤더에 무엇을 넣어야 하는지
• 응답 JSON에서 어떤 필드를 읽어야 하는지

그런데 MCP 서버를 붙여 놓으면 모델 입장에서는 훨씬 단순해집니다. 모델은 그냥 이런 식으로 이해합니다.

• 직원 이메일 찾기 기능 있음
• 입력값은 이름 문자열 하나
• 결과는 이메일 문자열

즉, 복잡한 API 구조를 모델이 바로 다루는 대신, MCP 서버가 그 복잡함을 감춥니다.

02 / 내부MCP 서버 안에는 실제로 뭐가 들어 있나

MCP 서버 안에는 거창한 마법이 있는 것이 아닙니다. 보통은 아래 네 가지가 들어 있습니다.

기능 목록

MCP 서버는 내가 제공할 수 있는 기능이 무엇인지 들고 있습니다. 예를 들면 이런 목록입니다.

• 직원 이메일 찾기
• 파일 본문 읽기
• 특정 월 매출 조회
• 노션 페이지 생성
• 회의록 요약

이 목록은 그냥 제목만 있는 것이 아니라, 각각의 기능이 무슨 용도인지 설명도 같이 붙습니다.

입력 형식 정의

각 기능은 아무렇게나 호출되는 것이 아니라, 어떤 값을 받아야 하는지 정해져 있습니다. 예를 들어 직원 이메일 찾기 기능은 이런 입력 형식을 가질 수 있습니다 — name: 문자열. 특정 월 매출 조회 기능은 month: 문자열, region: 문자열(선택값)처럼 될 수 있습니다. 즉, MCP 서버는 이 기능이 무엇을 입력으로 받아야 정상 동작하는지 미리 정의해 둡니다.

실제 실행 코드

이 부분이 본체입니다. 기능 설명만 있으면 아무 일도 안 일어납니다. 실제로는 뒤에서 코드가 돌아야 합니다. 예를 들어 직원 이메일 찾기 기능의 실행 코드는 이런 작업을 할 수 있습니다 — 데이터베이스 연결 → employees 테이블 조회 → 이름이 일치하는 행 찾기 → 이메일 반환. 파일 읽기 기능은 지정 폴더 접근 → 파일 존재 여부 확인 → 파일 열기 → 본문 읽기 → 텍스트 반환으로 동작할 수 있습니다. 즉, MCP 서버는 겉으로는 깔끔한 기능 하나처럼 보이지만, 안에서는 평범한 코드가 실제 작업을 수행합니다.

결과 반환 형식

실행이 끝나면 결과를 다시 돌려줘야 합니다. 이 결과도 모델이 읽기 좋게 정리되어야 합니다. 예를 들어 결과는 email: kim@company.com, found: true처럼 올 수 있습니다. 혹은 파일 읽기 결과라면 filename: report.txt, content: 본문 전체 텍스트처럼 올 수 있습니다. 즉, MCP 서버는 단순히 일을 하는 것에서 끝나는 것이 아니라, 그 결과를 다시 모델이 쓸 수 있는 구조로 정리해서 반환합니다.

03 / 흐름실제로는 어떻게 돌아가는가

사용자가 "김민수 과장 이메일 알려 줘"라고 입력했다고 가정하겠습니다. 그때 내부에서는 대략 이런 순서로 흐릅니다.

1. 모델이 현재 사용할 수 있는 기능 목록을 본다.
2. 그중에서 직원 이메일 찾기 기능이 적절하다고 판단한다.
3. 이 기능의 입력 형식을 확인한다. name이라는 문자열이 필요하다는 것을 안다.
4. name에 "김민수"를 넣어 호출한다.
5. MCP 서버는 실제 코드로 직원정보 저장소를 조회한다.
6. 찾은 이메일 값을 구조화해서 반환한다.
7. 모델은 그 값을 이용해 자연어 답변을 만든다.

여기서 중요한 점은 모델이 DB에 직접 붙은 것이 아니라는 점입니다. 모델은 직원 DB의 테이블 구조도 모르고, SQL도 직접 실행하지 않습니다. 대신 MCP 서버가 중간에서 실제 실행을 담당합니다.

모델은 기능 이름과 입력 형식만 보고 요청하고, 실제 시스템 접근과 실행은 MCP 서버가 대신 처리한다.

04 / 필요성왜 MCP 서버가 필요한가

이 질문이 중요합니다. "그냥 모델이 API 직접 호출하면 되지 않나"라고 생각할 수 있습니다. 그런데 실제로는 그렇게 하면 복잡도가 바로 올라갑니다.

첫째, 외부 시스템마다 형식이 다릅니다. 어떤 것은 REST API이고, 어떤 것은 DB이고, 어떤 것은 로컬 파일이고, 어떤 것은 사내 그룹웨어입니다.

둘째, 인증 방식도 다릅니다. API 키, 세션, OAuth, 내부망 접근 권한 등 제각각입니다.

셋째, 응답 형식도 제각각입니다. 어떤 것은 JSON이 복잡하고, 어떤 것은 HTML이고, 어떤 것은 CSV일 수 있습니다.

넷째, 모델이 그런 차이를 전부 직접 다루게 하면 안정성이 떨어집니다.

그래서 MCP 서버가 중간에서 이질적인 시스템들을 일정한 형태의 기능 목록으로 정리합니다. 그러면 모델은 각각의 시스템 차이를 몰라도 됩니다.

05 / 구조기술적으로 보자면

조금만 더 기술적으로 말하면, MCP 서버는 기능 레지스트리와 실행 엔진을 함께 가진 프로그램입니다.

기능 레지스트리라는 말은 서버가 제공 가능한 기능들의 이름·설명·입력 형식을 보관하고 있다는 뜻입니다. 실행 엔진이라는 말은 실제 호출이 왔을 때, 그 기능에 연결된 코드를 실행해서 결과를 만드는 부분이 있다는 뜻입니다. 즉, MCP 서버는 단순 문서가 아니라 살아 있는 실행 서버입니다.

정리하면 내부 구조는 이렇게 생각하면 됩니다.

• 기능 목록 보관
• 기능별 입력 형식 정의
• 기능별 실행 코드 연결
• 실행 결과 반환

06 / 정리가장 손에 잡히는 방식으로 다시

MCP 서버를 이해할 때는 이렇게 생각하는 것이 가장 손에 잡힙니다.

MCP 서버는 AI에게 "네가 쓸 수 있는 기능은 이것들이고, 이 기능을 쓰려면 이런 값을 넣으면 되고, 실제 실행은 내가 대신 해 줄게"라고 말하는 프로그램이다.

예를 들어 MCP 서버 안에는 이런 실행 가능한 기능들이 있을 수 있습니다.

• get_employee_email(name)
• read_file(path)
• get_sales_data(month)
• create_notion_page(title, content)
• draft_email(to, subject, body)

이 함수들은 전부 입력이 있고, 실제 실행 코드가 있고, 결과가 있습니다. MCP 서버는 이 함수들을 모델이 일정한 규칙으로 사용할 수 있게 정리해 놓은 서버입니다.

07 / 핵심실무에서 기억해야 할 네 줄

MCP 서버는 새로운 인공지능 두뇌가 아닙니다. 스스로 생각하는 존재도 아닙니다. 실제 역할은 실행 대행자에 가깝습니다.

• 무엇을 할 수 있는지 알려 준다
• 어떤 값을 넣어야 하는지 알려 준다
• 실제 처리는 대신 해 준다
• 결과를 다시 넘겨 준다

이 네 줄이 MCP 서버의 원리입니다. 한 줄로 더 줄이면, MCP 서버의 원리는 복잡한 외부 시스템을 모델이 이해할 수 있는 기능 목록으로 정리하고, 모델이 요청하면 그 기능을 대신 실행한 뒤 결과를 다시 돌려주는 것입니다.

MCP는 한 마디로 무엇인가. 서버와 클라이언트와 에이전트 서버는 어떻게 다른가. 식당 비유로 풀어 본 입문 지도.

MCP를 처음 접하면 이름부터 헷갈립니다. 서버도 있고, 에이전트 서버도 있고, 클라이언트도 있고, 어떤 사람은 MCP를 API wrapper 정도로만 설명합니다. 그런데 실제로는 그것보다 훨씬 넓은 개념입니다. 초보자 기준으로 가장 중요한 것은 누가 무엇을 연결하고, 누가 도구를 제공하고, 누가 그 도구를 실제로 호출하느냐를 분리해서 이해하는 것입니다.

이 글은 그 구조를 처음부터 끝까지 풀어 설명합니다. MCP 서버는 무엇인가, MCP 클라이언트는 무엇인가, MCP 에이전트 서버는 무엇인가, 셋의 차이는 무엇인가, 실제로 만들려면 어떤 순서로 해야 하는가 — 이 질문들에 차례로 답하도록 구성했습니다.

01 / 정의MCP를 한 문장으로 이해하기

MCP는 모델이 외부 도구를 일정한 방식으로 발견하고, 설명을 읽고, 호출하고, 결과를 돌려받을 수 있게 해 주는 연결 규약이라고 이해하면 됩니다. 쉽게 말하면 이렇습니다. AI 모델은 원래 말만 잘합니다. 그런데 실제 업무를 하려면 검색도 하고, 파일도 읽고, DB도 조회하고, API도 호출하고, 계산도 하고, 메일도 보내야 합니다. MCP는 이런 외부 기능을 도구라는 형태로 AI에게 붙이는 표준 통로입니다.

즉, MCP는 단순히 API를 감싸는 기술이 아니라, 모델이 현실 세계의 기능을 안전하고 구조적으로 쓰게 만드는 인터페이스 계층입니다.

02 / 구분가장 먼저 나누어야 하는 세 가지

MCP 서버를 좀 더

예를 들어 법령정보 MCP 서버라면 search_law, get_law_text, search_precedents 같은 도구를 외부에 제공할 수 있습니다. 이때 중요한 것은 AI가 법제처 API 구조를 직접 알 필요가 없다는 점입니다. MCP 서버가 복잡한 API 구조를 숨기고, AI가 쓰기 쉬운 도구 인터페이스로 바꿔 줍니다. 즉, MCP 서버는 도구 판매대에 가깝습니다.

MCP 에이전트 서버가 가장 헷갈리는 이유

에이전트 서버는 MCP 표준 그 자체의 필수 요소는 아닙니다. 하지만 실무에서는 매우 자주 등장합니다. 이유는 모델 단독 호출만으로는 실제 서비스 구성이 불편하기 때문입니다. 에이전트 서버는 모델과 도구 사용 흐름 전체를 지휘하는 오케스트라 지휘자에 가깝습니다.

03 / 비유식당으로 이해하기

식당으로 비유하면 이해가 쉽습니다.

이 구조를 보면 왜 MCP가 단순 API wrapper보다 넓은 개념인지 보입니다. 요리 하나만 감싸는 것이 아니라, 주문 체계 전체를 표준화하는 셈이기 때문입니다.

04 / 확장MCP는 API만 감싸는 것인가

부분적으로는 맞지만 그것만으로 설명하면 부족합니다. 많은 MCP 서버가 실제로는 외부 API를 감쌉니다. 날씨 API, 법령 API, 금융 시세 API, 지도 API, 사내 그룹웨어 API 같은 것들입니다. 하지만 MCP로 감쌀 수 있는 것은 API만이 아닙니다.

• 로컬 파일 시스템
• 데이터베이스
• 사내 프로그램 기능
• 운영체제 기능
• 생산성 도구
• OCR·요약·분류 같은 AI 보조 기능
• 사람 승인 단계가 필요한 워크플로우

즉, MCP는 AI가 쓸 수 있는 기능을 표준 도구 형태로 외부에 노출하는 방식이라고 보면 됩니다.

05 / 구조실제 아키텍처는 어떻게 생기는가

가장 단순한 구조는 다음과 같습니다.

사용자 → MCP 클라이언트 → MCP 서버

예를 들어 Claude Desktop이 어떤 로컬 MCP 서버에 연결해서 파일 검색 도구를 쓰는 구조입니다.

조금 더 실무형 구조는 이렇게 됩니다.

• 사용자 → 웹앱 또는 챗봇 UI
• 웹앱 → 에이전트 서버 → 모델 호출
• 에이전트 서버 → MCP 서버 1 (예: 매출 DB 조회)
• 에이전트 서버 → MCP 서버 2 (예: 회의록 파일 검색)
• 에이전트 서버 → MCP 서버 3 (예: 노션 페이지 작성)

이 구조에서는 에이전트 서버가 핵심입니다. 사용자는 웹앱만 보고 있지만, 뒤에서는 에이전트 서버가 여러 MCP 서버와 대화하며 필요한 도구를 고릅니다. 사용자가 "지난달 매출 감소 원인 요약하고 관련 회의록 찾아 줘"라고 말하면, DB 조회용 MCP 서버로 매출 데이터 조회 → 파일 검색 MCP 서버로 회의록 검색 → 노션 MCP 서버로 관련 문서 작성 → 최종적으로 모델이 종합 답변 생성 — 이런 흐름이 가능합니다.

06 / 순서초보자가 직접 만들 때 추천하는 학습 단계

처음부터 에이전트 서버까지 다 만들면 어렵습니다. 순서를 나누는 것이 좋습니다.

1. MCP 서버 하나만 먼저 만든다. 가장 쉬운 시작은 도구 1~2개짜리 MCP 서버다. 날씨 조회, 환율 조회, 로컬 파일 목록 보기, 특정 폴더 텍스트 검색, 샘플 DB 조회 정도가 좋다. 목표는 딱 하나. 도구를 어떻게 정의하고, 입력 스키마를 어떻게 만들고, 결과를 어떻게 반환하는지 익히는 것.
2. MCP 클라이언트에 연결해 본다. 직접 만든 MCP 서버를 Claude Desktop 같은 기존 클라이언트에 연결해 실제로 동작시키는 단계.
3. 에이전트 서버를 만든다. 웹앱이나 챗봇을 직접 만들고, 그 뒤에서 모델과 여러 MCP 서버를 연결하는 에이전트 서버를 붙인다.
4. 여러 MCP 서버를 조합한다. 검색 MCP, DB MCP, 문서작성 MCP, 이메일 MCP, 사내 승인 시스템 MCP를 조합해 하나의 업무 자동화 에이전트를 만든다.

07 / 만들기구성요소별 사고방식

MCP 서버 만들기 개념

MCP 서버를 만들 때 필요한 사고방식은 다음 순서입니다. 첫째, 도구를 먼저 고른다. 예를 들어 "특정 도시의 날씨를 조회한다"는 기능 하나를 정합니다. 둘째, 도구의 입력을 정한다. 예를 들어 city라는 문자열. 셋째, 도구의 출력을 정한다. 도시명·현재 온도·날씨 설명·측정 시각. 넷째, 실제 내부 로직을 연결한다. 이 내부 로직은 외부 API 호출일 수도, 로컬 파일 읽기일 수도, DB 쿼리일 수도, 파이썬 함수 실행일 수도 있습니다. 다섯째, 모델이 이해하기 쉬운 설명을 쓴다. 이 부분이 매우 중요합니다. 모델은 설명을 보고 어떤 도구를 쓸지 추론하기 때문입니다.

MCP 클라이언트 만들기 개념

MCP 클라이언트의 핵심은 두 가지입니다. 서버에 연결해서 tool list를 가져오고, 모델이 필요할 때 tool call을 중계하는 것. 실제로는 이미 만들어진 MCP 클라이언트를 먼저 써 보는 것이 좋습니다. 직접 구현보다 먼저 경험하는 편이 이해가 빠릅니다.

에이전트 서버 만들기 개념

에이전트 서버는 보통 Node.js나 Python으로 많이 만듭니다. 구성은 대개 /chat 같은 API 엔드포인트 → 사용자 질문 수신 → 시스템 프롬프트와 함께 모델에 전달 → 모델이 도구 호출을 원하면 MCP 서버에 요청 → 결과를 다시 모델에 넣음 → 최종 답변 반환 — 이 흐름입니다. 초보자 입장에서는 에이전트 서버를 대화 조정기라고 보면 됩니다.

08 / 시나리오회사 주소록 검색 챗봇 만들기

아주 단순한 예시 시나리오입니다. 구성은 이렇습니다.

• MCP 서버: 사내 주소록 검색 도구 제공
• 에이전트 서버: 사용자 질문을 받아 모델과 MCP 도구 호출 조정
• 클라이언트: 사내 웹 채팅 화면

사용자가 "김민수 과장 이메일 알려 줘"라고 물으면 내부 흐름은 다음과 같이 전개됩니다.

1. 웹 채팅창에서 질문 입력
2. 웹앱이 에이전트 서버에 질문 전송
3. 에이전트 서버가 모델에게 질문 전달
4. 모델이 search_employee_directory 도구가 필요하다고 판단
5. 에이전트 서버가 MCP 서버에 도구 호출
6. MCP 서버가 사내 DB 또는 API에서 결과 조회
7. 결과를 에이전트 서버로 반환
8. 에이전트 서버가 결과를 모델에 다시 전달
9. 모델이 자연어 답변 생성
10. 웹앱에 답변 표시

09 / 착각초보자가 자주 헷갈리는 포인트

MCP 서버와 일반 백엔드 서버는 완전히 같지는 않다. MCP 서버는 백엔드일 수 있지만 목적이 일반 웹서비스 전체가 아니라 도구 제공 인터페이스에 더 가깝습니다.

에이전트 서버 없이도 동작은 가능하다. Claude Desktop처럼 이미 MCP 클라이언트 역할을 하는 환경에서는 MCP 서버만 붙여도 도구 사용이 가능합니다. 하지만 웹 서비스나 사내 시스템으로 확장하려면 에이전트 서버가 거의 필요해집니다.

MCP는 함수 호출과 닮았지만 완전히 같지는 않다. 함수 호출은 모델 API 내부의 도구 정의에 가깝고, MCP는 외부 시스템과 도구를 표준 방식으로 연결하는 더 넓은 규약 계층입니다.

모든 API를 MCP로 바꿀 필요는 없다. 여러 도구를 표준 방식으로 붙이고 싶을 때, 재사용성을 높이고 싶을 때, 여러 AI 클라이언트에서 공통으로 쓰고 싶을 때 특히 유리합니다.

10 / 스택어떻게 시작할까

초보자 기준으로는 Python 경로와 Node.js 경로가 있습니다. Python은 데이터 처리, 파일 처리, 자동화, 문서 분석, DB 조회 쪽에 강합니다. Jupyter나 Colab 경험이 있다면 진입 장벽이 낮습니다. Node.js는 웹앱, 프론트엔드, API 서버, SaaS 연동, 실시간 상호작용형 앱 쪽에 더 잘 맞습니다. 처음에는 둘 다 하려 하지 말고 하나만 먼저 잡는 편이 좋습니다.

첫 실습 주제로는 다음 셋이 무난합니다. 로컬 폴더 파일 검색 MCP 서버, 날씨 조회 MCP 서버, 노션 페이지 작성 MCP 활용. 이 중 로컬 폴더 파일 검색이 가장 쉽습니다. 외부 API 키가 필요 없고 결과가 바로 눈에 보이기 때문입니다.

11 / 설계실무에서 정말 중요한 것

초보자는 종종 코드부터 짜려고 합니다. 그런데 실제로는 설계가 더 중요합니다.

도구 단위를 너무 크게 만들지 않는 것이 좋습니다. do_everything 같은 식의 거대한 도구보다 get_sales_data, summarize_sales_change, find_related_meeting_notes, create_notion_report처럼 나누는 편이 좋습니다.

입력 스키마를 모호하게 만들지 말아야 합니다. query 하나에 모든 걸 넣는 방식은 편해 보이지만 모델이 실수하기 쉽습니다.

결과도 모델이 읽기 좋게 반환해야 합니다. 사람이 보기 좋은 JSON과 모델이 추론하기 좋은 JSON은 다를 수 있습니다.

12 / 보안권한 설계는 왜 중요한가

MCP는 도구를 모델에게 열어 주는 구조이기 때문에, 잘못 설계하면 위험합니다. 파일 삭제, 메일 발송, 결재 요청, DB 수정 같은 도구는 특히 조심해야 합니다. 안전하게 만들려면 최소한 다음이 필요합니다.

• 읽기 전용 도구와 쓰기 도구 분리
• 사용자 권한별 접근 통제
• 위험 액션은 사람 승인 필요
• 로그 기록
• 입력값 검증
• 허용된 폴더나 테이블만 접근 가능하도록 제한

초보자일수록 처음에는 조회 전용 MCP만 만드는 것이 안전합니다.

13 / 로드맵추천 학습 경로

초보자 기준으로는 다음 흐름이 가장 현실적입니다.

1. MCP 개념 이해
2. 아주 작은 MCP 서버 1개 만들기
3. Claude Desktop 같은 클라이언트에 연결
4. 도구 설명과 입력 스키마 다듬기
5. 두세 개 도구로 확장
6. 간단한 에이전트 서버 만들기
7. 웹앱과 연결
8. 권한·로그·승인 흐름 추가

14 / 정리다섯 가지 질문

처음에는 MCP가 거창하고 추상적으로 느껴지지만, 실제로는 다음 다섯 질문만 붙잡으면 됩니다.

• 어떤 기능을 도구로 만들 것인가
• 그 도구는 어떤 입력을 받을 것인가
• 어떤 결과를 반환할 것인가
• 누가 그 도구를 호출할 것인가
• 모델이 써도 안전한가

이 다섯 가지가 정리되면 MCP 서버 설계의 절반은 끝난 것입니다.

초보자에게 가장 좋은 출발은 거대한 플랫폼을 한 번에 만드는 것이 아니라, 작고 분명한 도구 하나를 MCP 서버로 감싸서 실제로 연결해 보는 것이다. 그 다음에야 에이전트 서버와 웹앱으로 넓혀 가는 것이 맞다.

MCP 서버는 기능을 제공하는 곳이고, MCP 클라이언트는 그 기능을 쓰는 쪽이며, 에이전트 서버는 모델과 도구 사용 전체를 조정하는 서비스 레이어입니다. 그리고 MCP는 단순 API wrapper가 아니라, AI가 다양한 외부 기능을 표준 방식으로 사용할 수 있게 해 주는 도구 연결 구조입니다. 따라서 실무에서는 "어떤 API를 감쌀까"만 생각하지 말고 "어떤 업무 기능을 도구로 쪼개서 모델이 안전하게 사용할 수 있게 만들까"를 고민하는 것이 더 중요합니다.

프롬프팅, 워크플로우, 에이전트, 에이전틱 AI, 하네스 — 섞여 쓰이는 이 단어들을 운전 비유 하나로 한 번에 정리해 본다.

요즘 AI 관련 뉴스를 보면 "AI 에이전트", "에이전틱 AI"라는 말이 빠지지 않습니다. 그런데 이 단어들이 정확히 뭘 뜻하는지, 서로 어떻게 다른지 명확하게 설명해 주는 곳은 의외로 드뭅니다. 심지어 전문가들 사이에서도 용어가 혼용되고 있어서, 일반인이 혼란스러운 건 당연합니다.

이 글에서는 AI를 활용하는 네 가지 방식을 운전에 비유해서 구분해 보겠습니다. 이 구분을 알고 나면, 지금 내가 AI를 어떤 수준으로 쓰고 있는지, 그리고 다음 단계는 뭔지가 보이기 시작합니다.

01 / 시나리오하나의 장면으로 시작해 보자

여러분이 간단한 웹페이지를 만들고 싶다고 가정해 보겠습니다. ChatGPT에게 이렇게 묻습니다.

ChatGPT가 코드를 줍니다. 여러분은 그 코드를 복사해서 메모장에 붙여 넣고, index.html로 저장하고, 브라우저에서 열어 보고, 잘 나오면 Netlify에 드래그앤드롭으로 올려서 배포합니다.

이게 AI 에이전트일까요?

아닙니다. 이건 프롬프팅입니다. 이유는 지금부터 풀어 보겠습니다.

02 / 프롬프팅길을 물어보는 것

"강남역 어떻게 가요?" 물어보고, 답을 듣고, 운전은 내가 합니다. AI는 조언자일 뿐입니다.

앞의 ChatGPT 시나리오가 바로 여기에 해당합니다. AI에게 코드를 받았지만, 그 코드를 복사하고, 저장하고, 브라우저에서 확인하고, Netlify에 업로드하는 모든 행동은 사람이 직접 합니다. AI는 한 번 대답하고 끝입니다. 내 코드가 어디로 갔는지, 제대로 배포됐는지 AI는 알지 못합니다.

03 / 워크플로우내비게이션을 따라 운전하는 것

경로는 사람이 미리 정해 놨습니다. AI는 그 정해진 자리에서 정해진 일만 합니다.

예를 들어, Zapier나 Make 같은 자동화 도구로 이런 흐름을 만들 수 있습니다.

여기서 AI가 "오늘은 Slack 말고 이메일로 보내는 게 낫겠다"고 판단하지 못합니다. 길이 고정돼 있으니까요. AI가 일은 하지만, 어떤 일을 할지는 사람이 미리 결정해 둔 것입니다.

04 / 에이전트자율주행차

목적지만 말하면, 차가 알아서 경로를 정하고, 공사 구간을 만나면 돌아가고, 주유가 필요하면 주유소에 들르고, 실패하면 다시 시도합니다.

같은 웹사이트 배포를 예로 들면, Claude Code에 이렇게 말합니다.

그러면 AI가 스스로 다음 과정을 진행합니다.

• 파일 구조를 설계한다
• HTML, CSS, JavaScript 코드를 작성한다
• 파일을 저장한다
• 브라우저에서 확인한다
• 에러가 나면 원인을 분석하고 수정한다
• Netlify CLI를 이용해 배포한다
• 배포된 URL을 확인하고 보고한다

이 전 과정을 AI가 판단하면서 진행합니다. 사람은 "해 줘" 한마디만 하면 됩니다. 프롬프팅에서 사람이 하던 복사, 붙여 넣기, 저장, 업로드를 전부 AI가 대신하는 셈입니다.

05 / 하네스자율주행을 가능하게 하는 자동차

자율주행차에는 LiDAR, 카메라, 브레이크, 핸들, 제어 컴퓨터가 필요합니다. 아무리 똑똑한 AI 운전자라도 이것들 없이는 도로에 나갈 수 없습니다.

마찬가지로, ChatGPT든 Claude든 LLM(대규모 언어모델) 자체는 텍스트를 생성하는 능력만 가지고 있습니다. 여기에 도구 인터페이스(파일 저장, 웹 검색, 코드 실행 등), 루프 제어(언제 다시 시도할지), 컨텍스트 관리(뭘 기억하고 뭘 버릴지) 같은 바깥 인프라를 씌워야 비로소 에이전트처럼 움직일 수 있습니다. 이 바깥 인프라를 하네스(harness)라고 부릅니다.

LLM(운전자) + 하네스(자동차) = 에이전틱 시스템(자율주행차)

Claude Code, Cursor, Devin 같은 서비스들은 각자 다른 "자동차"를 만든 것입니다. 운전자(LLM)는 비슷할 수 있지만, 차가 다르면 성능이 달라집니다. 같은 Claude 모델이라도 Cursor 위에서 쓸 때와 Claude Code에서 쓸 때 체감이 다른 이유가 바로 여기에 있습니다. 하네스의 내부 구조를 더 자세히 보고 싶다면 별도 글 하네스라는 단어, 한 걸음 더 들어가 보기에서 파일과 폴더 단위로 내려가 두었습니다.

06 / 분류그래서 Manus, Genspark 같은 건 뭔가요

최근 주목받는 서비스들을 위의 기준으로 분류해 보겠습니다.

Manus — "이 회사 조사해서 보고서 만들어 줘" 한마디 던지면, 스스로 검색 계획을 세우고, 웹사이트를 돌아다니고, 데이터를 정리하고, 문서를 만듭니다. 심지어 백그라운드에서 알아서 돌아가게 두고 다른 일을 할 수도 있습니다. 전형적인 에이전틱 서비스입니다.

Genspark — AI 검색엔진으로 시작했지만, 지금은 Super Agent 기능을 통해 여행 일정을 짜고 예약까지 시도하는 수준으로 확장됐습니다. 이것도 에이전틱에 해당합니다.

ChatGPT 기본 채팅 — 질문에 대답하는 수준입니다. 프롬프팅입니다.

사실 현실은 칼로 자르듯 나뉘지 않습니다. 스펙트럼에 가깝습니다.

프롬프팅 ─── 워크플로우 ─── 반자율 에이전트 ─── 완전자율 에이전틱
ChatGPT      Zapier+AI       ChatGPT Agent 모드     Manus, Claude Code
(질문→답변)  (정해진 길)     (확인받으며 진행)       (알아서 끝까지)

07 / 판별가장 많이 하는 오해

"ChatGPT 쓰는 것도 에이전트 아닌가요?"

아닙니다. 진짜 구분선은 이 질문 하나로 판별됩니다.

AI가 다음에 뭘 할지 스스로 정하는가, 내가 정해 주는가?

• 내가 정해 주면 → 프롬프팅 또는 워크플로우
• AI가 정하면 → 에이전틱

ChatGPT에 코드를 물어보고 Netlify에 올리는 그 시나리오에서, "이제 Netlify에 올려야지"라고 결정한 건 여러분이었습니다. ChatGPT는 그 결정에 관여하지 않았습니다. 그래서 에이전트가 아닙니다.

08 / 혼용전문가마다 정의가 다른 이유

뉴스나 강연에서 "AI Agent와 Agentic AI는 다른 개념"이라는 설명을 들으셨을 수도 있습니다. 틀린 말은 아닙니다. 학술적 프레이밍에서는 이렇게 나눕니다.

• AI Agent: 단일 LLM이 하나의 과제를 수행하는 시스템
• Agentic AI: 여러 에이전트가 협업하며 복합 목표를 달성하는 시스템

반면 Anthropic, OpenAI 같은 실무 프레이밍에서는 다음처럼 나눕니다.

• Workflow: 사람이 경로를 고정한 자동화
• Agentic: LLM이 자율적으로 판단·실행·수정 루프를 도는 시스템

이 두 프레이밍은 같은 코끼리의 다른 부위를 만지고 있는 것과 같습니다. 업계에 아직 합의된 단일 정의가 없기 때문에 여러 관점이 공존하는 상태입니다. 어떤 프레임을 쓰든, 핵심은 "AI가 얼마나 자율적으로 판단하고 행동하느냐"입니다.

09 / 요약한 줄로 네 개

지금 여러분이 AI를 쓰는 방식은 이 중 어디에 해당하나요? 그리고 다음 단계로 올라가려면 무엇이 필요할까요?

AI 시대에 중요한 질문은 더 이상 "프롬프트를 어떻게 잘 쓸까"가 아니다. "어떤 목표를 AI에게 위임할 것인가"로 바뀌고 있다.

다음 글부터는 이 지도를 전제로 한 걸음씩 더 들어갑니다. MCP가 무엇이고 왜 등장했는지, 하네스는 실제로 어떤 파일과 폴더로 구성되어 있는지, 여러 에이전트를 묶는 패턴에는 어떤 것들이 있는지를 차례로 다룰 예정입니다. 첫 출발점인 이 글에서는 용어의 안개만 걷어 두면 충분합니다.