모순된 AI with 민음사 사내 AI 교육 모순된 AI with 민음사 사내 AI 교육
민음사에서 AI 사용법 강의를 하게 되었을 때, 뻔한 실무 활용 이야기만 하고 싶지 않았다. Anthropic이 만든 Claude의 성능이 좋아진 건, 엄청나게 많은 수의 책을 절단하여 학습시켰기 때문이기도 한데, 그 책을 만드는 분들에게 ‘AI 좋아요~ 어서 써보세요~’ 라고만 하는 건 조금 그런 것 같아서. 첫 시작은 꼭 AI 기술이 품고 있는 윤리적 문제점에 대해 언급하고 싶었다. 그리고 그 강의 자료를 준비하기 위해 나는 또, Anthropic의 Claude에게 말을 걸었다. 나는 모순 속에 서 있었고, 그 사실을 꽤 오래전부터 알고 있었다. 그날 강의를 준비하면서 AI에게 물었다. 이 기술에 데이터 라벨링 노동, 데이터 센터가 빨아들이는 전기, 창작자 무단 취득 같은 문제가 있는데도 배우고 써야 하는 이유가 뭘까, 를 또 AI에게 물어보고 있다니. 돌아온 답 중 하나가 나를 붙잡았다. 기술 비판이 가장 설득력 있으려면, 그 기술을 깊이 아는 사람이 해야 한다고. 사용해보지 않으면서 AI가 나쁘다고 하는 것보다, 쓸 줄 알면서 그 그림자를 말하는 사람이 훨씬 세게 찌를 수 있다고. 월트 휘트먼이 160년 전에 썼다. “내가 모순된다고? 좋다, 그렇다면 나는 모순된다. 나는 크다, 나는 여럿을 품는다.” 아침에 이 문장을 발견한 건, 오늘 하루가 아주 좋을 거라는 예견이기도 했다.
강의장에서 나는 AI가 양파 같다는 이야기부터 꺼냈다. 인공지능, 머신러닝, 딥러닝, 거대 언어 모델. 네 겹의 껍질을 벗기면 우리가 매일 말을 거는 ChatGPT와 Claude가 나온다. 그런데 이 기계가 하는 일의 본질을 설명하려면 한 가지를 먼저 인정해야 한다. 이 안에 “진실”이라는 개념은 없다. 있는 것은 “그럴듯함”뿐이다. “오늘 날씨가 ___“라는 빈칸 뒤에 “맑다” 38%, “춥다” 22%, “흐리다” 17%를 놓고, 가장 그럴듯한 단어를 뽑아 이어붙이는 것. 숙련된 고스트라이터가 “이 작가라면 다음에 이런 문장을 쓰겠지”라고 추측하는 것에 가깝다. 이해하는 게 아니라 패턴을 매칭하는 거라고. 강의를 듣고 있는 분들의 표정이 미묘하게 바뀌는 게 보였다. (‘어라 이 강의는 그저 그런 AI 강의가 아닌 것 같은데?’ ..물론 아닐 수도 있다.)
다음으로는 프롬프트 엔지니어링 이야기를 했다. “보도자료 써줘”와 “민음사에서 출간하는 소설 OO의 보도자료를 A4 1장 분량, 격식체로, 첫 문장은 인용구로 시작해서 써줘”의 차이. 역할을 부여하고, 예시를 보여주고, 단계를 나누는 것. 하지만 나는 이 이야기를 하면서 동시에, 이것만으로는 부족한 시대가 이미 와 있다는 걸 말하고 싶었다. 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로, 다시 에이전트 엔지니어링으로. 이 흐름에서 정말 흥미로운 건 기술의 발전이 아니라 통제권의 이동이다. 프롬프트 시대에 인간은 단어 하나하나를 통제했다. 컨텍스트 시대에는 정보 환경을 설계했다. 에이전트 시대에는 목표만 주고 실행을 위임한다. “AI를 잘 쓰는 법”의 정의 자체가 바뀌고 있다. 말 잘하는 법에서, 정보를 설계하는 법으로, 다시 위임하고 감독하는 법으로. 그건 거의 매니지먼트에 가까운 일이다.
그런데 여기서 한 발 더 가면 불편한 질문이 기다린다. AI에게 더 많은 자율성을 줄수록, 책임은 어디로 가는가. 에이전트가 스스로 판단해서 검색하고, 코드를 쓰고, 파일을 만들고, 틀리면 다시 시도하는 세상에서, 그 결과물의 책임은 누구에게 있나. 강의에 참여한 분도 질문을 던졌다. ‘그럼 정말 인간이 판단하지 않아도 되는 거예요?’ 기술적으로 불가능한 것은 아니라고 답했다. 하지만 점점 더 중요해지는 건 인간의 ‘판단 능력’일 것이라고 생각했다. 그 한 끗의 차이를 발견해내는 것은 인간이 해야 하는 일이라고 생각했기 때문에.
강의를 마치고 참여하신 분들이 만족해 하시는 모습이 눈에 보여 기뻤다. AI에 대한 막연한 두려움이나 막막함 보다는 ‘이것도 그냥 기계일 뿐이네!’ 하고 생각할 수 있기를 바랐다. 그리고 본인이 하는 일에 가장 진심인 사람들이, 이 기술을 누구보다 더 빨리 익힐 수 있게 되기를 바라는 마음으로 준비한 것이 조금이나마 전달된 것 같아 기분이 좋았다.
나는 AI의 윤리적 문제를 알면서 AI를 쓰고, AI의 한계를 가르치면서 AI로 강의를 준비하고, AI를 비판하는 글을 AI와 함께 쓴다. 막연한 두려움이 아니라 비판적 사고를 기반으로 한 참여가 나에게는 중요하다. 기술이 발전하고 있고, 인간의 판단이 중요하다면, 그 판단을 위해서는 반드시 이 기술을 알아야 한다. 모순을 안고 가는 수밖에 없다. 휘트먼이 했던 것처럼 그 모순을 인정하고, 그 안에서 손을 내미는 것. 휘트먼의 시는 “나는 모순된다”로 끝나지 않는다. “누가 나와 함께 걷기를 원하는가? 내가 떠나기 전에 말할 것인가? 너무 늦어버릴 것인가?”로 이어진다. 모순을 인정한 사람은 고립되지 않는다. 오히려 그제서야 진짜 초대가 가능해진다.
아래에 덧붙이는 건 그날의 강의록!
여는 말
안녕하세요. 오늘 여러분과 _AI와 출판_이라는 주제로 이야기 나누게 된 김민석입니다. 지금 카카오임팩트라는 곳에서 기술 기획 일을 하고 있고, 학부에서는 컴퓨터공학과 철학을 함께 공부했어요. 기술을 만드는 일과, 기술을 어떻게 바라봐야 하는지를 생각하는 일, 이 두 가지를 계속 오가면서 지내고 있습니다.
오늘 이 자리는 단순히 “ChatGPT 잘 쓰는 법”을 알려드리는 자리가 아니에요. 물론 실용적인 이야기도 많이 합니다. 그런데 그보다 먼저, 우리가 이 기술을 어떻게 바라볼 것인가라는 질문을 같이 꺼내보고 싶었습니다. 출판은 언어를 다루는 일이고, AI도 언어를 다루는 기술이잖아요. 그래서 이 두 세계가 만나는 지점이 특히 더 중요하다고 생각했어요.
오늘 이야기는 크게 여섯 개의 섹션으로 구성했습니다. 먼저 오프닝에서 AI 기술의 윤리적 그림자를 짚고, 그다음엔 여러분이 미리 남겨주신 질문들을 함께 펼쳐봅니다. 이어서 LLM의 기본 특성, 그리고 오늘의 핵심인 프롬프트 → 컨텍스트 → 에이전트로 이어지는 세 단계, 마지막으로 바이브 코딩과 인쇄술 이야기와 Q&A로 마무리합니다. 대략 두 시간 정도 될 거예요.
오프닝 — AI는 무엇을 먹고 자라는가
먼저 조금 무거운 이야기로 시작해보려고 합니다. 요즘 AI 강의에 가면 보통 “이거 이렇게 쓰세요, 이렇게 하면 생산성 2배 됩니다” 하는 이야기로 시작하거든요. 저는 그 앞에 이 질문을 한 번 꺼내고 싶었어요. AI는 무엇을 먹고 자라고 있는가?
솔직하게 말씀드리면, 지금 우리가 쓰는 AI 기술에는 윤리적 문제가 많습니다. 숨겨진 데이터 라벨링 노동자들이 있고, 데이터센터가 어마어마한 물과 전기를 쓰고 있고, 무엇보다 — 여러분과 직접 관련 있는 이야기인데 — 저작권 있는 콘텐츠가 무단으로 학습에 쓰이는 사례가 계속 드러나고 있어요. Anthropic의 Claude, OpenAI의 ChatGPT, Google의 Gemini, 우리가 매일 쓰는 모든 서비스가 여기에서 자유롭지 않습니다.
마크 그레이엄과 동료들이 쓴 《AI는 인간을 먹고 자란다》라는 책이 흐름출판에서 나왔는데요, 이 책의 21쪽에 이런 문장이 있습니다. “인공지능은 흔히 인간지능을 비추는 거울이라고 불린다. 그러나 AI는 추출 기계에 가깝다. 데이터를 분류하고, 차별하며, 예측하는 모든 과정은 이를 만든 사람들의 이해관계와 권력 구조를 반영한다.” 저는 이 ‘거울이 아니라 추출 기계’라는 표현이 지금 상황을 정확하게 짚는다고 생각해요.
이 책은 AI가 세 가지 층위를 먹고 자란다고 말합니다. 첫째, 사람을 먹습니다. AI가 똑똑해 보이려면 누군가 수작업으로 데이터를 라벨링 해줘야 해요. 그 노동은 지금 인도, 케냐, 필리핀의 저임금 노동자들이 하고 있습니다. 영어가 가능하고, 임금이 낮고, 노동 규율이 엄격한 지역들이죠. 책 53쪽에 보면 그 노동자들이 “극도의 지루함과 불안감이 뒤섞인 기묘한 감정”을 느낀다는 묘사가 나옵니다. 우리가 챗봇과 편안하게 대화하고 있을 때, 그 뒤에는 이런 노동이 있어요.
둘째, 지구를 먹습니다. AI는 순수한 소프트웨어가 아니에요. 육중한 서버랙, 냉각 시스템, 해저 케이블. 우리가 ChatGPT에 질문 하나 던질 때마다 이 거대한 물리 인프라가 숨을 쉽니다. 물을 쓰고, 전기를 쓰고, 열을 뱉어내요.
셋째가 오늘 제일 중요한 이야기인데, 지식과 창작을 먹습니다. 책 147쪽에 이런 표현이 있어요. “AI 도구는 한 명의 사기꾼을 만드는 데 그치지 않는다. 수많은 창작자의 작업을 분석해, 그 속에서 창의적이고 가치 있는 아이디어를 대량으로 추출한다.” 여러분이 편집한 책, 여러분과 작업한 저자의 문장, 이미 학습 데이터로 들어갔을 가능성이 매우 높습니다.
두 가지 구체적인 사례만 짚겠습니다. 먼저 Claude를 만드는 Anthropic. 이 회사에는 Project Panama라는 내부 프로젝트가 있었어요. 중고책을 구해서 물리적으로 절단하고, 스캔해서 학습 데이터로 만드는 작업입니다. 2024년 10월에는 Hachette, HarperCollins, Penguin Random House 같은 대형 출판사와 저자 집단이 저작권 있는 수백만 권을 무단 학습에 사용했다는 이유로 집단소송을 걸었고, 2026년 2월에 미국 법원이 놀랍게도 “무단 스캔이 공정이용(fair use)에 해당한다”는 판결을 내렸습니다. 출판업계에 큰 충격이었죠. 경향신문 기사 한 번 찾아보시기를 권합니다.
OpenAI도 크게 다르지 않습니다. 2023년 9월에 존 그리샴, 조지 R.R. 마틴 같은 유명 작가 17명이 작가조합(Authors Guild)을 통해 소송을 걸었고, 12월에는 뉴욕타임스가 수십억 달러 손해배상 소송을 제기했어요. 2024년에는 Whisper라는 자체 음성인식 모델로 유튜브 영상 100만 시간 이상을 몰래 텍스트로 변환해서 GPT-4 학습에 썼다는 NYT 보도가 나옵니다. 유튜브 CEO도 공개적으로 “이건 약관 위반”이라고 언급했어요.
이 이야기를 첫 섹션에 배치한 이유가 있습니다. 저는 여러분이 그냥 좋아서 쓰는 기술이 아니라, 알고 쓰는 기술이 되셨으면 해서요. 오늘 이 강의를 준비하면서 제일 고민한 부분이에요. 윤리적 문제는 분명히 있습니다. 그럼에도 왜 잘 알아야 할까요? 저는 비판적 참여(Critical Participation)라는 말을 좋아합니다. 막연한 두려움으로 회피하는 것도 답이 아니고, 무비판적으로 받아들이는 것도 답이 아니에요. 기술이 발전하는 속도를 멈출 수는 없습니다. 그러니까 이 기술을 잘 이해하고, 어디까지 쓸지, 무엇을 지킬지 스스로 판단할 수 있어야 합니다. 오늘의 출발점이 여기예요.
LLM 기반 AI 서비스의 특성
이제 본격적인 이야기로 들어갑니다. 우리가 쓰는 도구가 어떻게 작동하는지 먼저 알아야, 그걸 잘 쓰는 법도 이해가 되거든요.
AI는 양파 같은 개념입니다. 하나의 단일한 기술이 아니라 네 겹으로 감싸여 있어요. 맨 바깥이 AI — 이건 우산 같은 용어입니다. 그 안에 머신러닝(ML)이 있고, 또 그 안에 딥러닝(DL)이 있어요. 딥러닝은 뇌의 뉴런 구조를 흉내 낸 머신러닝의 한 종류고요. 그리고 가장 안쪽에 LLM, 거대 언어 모델이 있습니다. 우리가 매일 쓰는 ChatGPT, Claude, Gemini는 전부 이 가장 안쪽의 LLM을 기반으로 만들어진 서비스예요.
이 LLM을 쓸 때 꼭 알아야 할 세 가지가 있습니다. 확률 기반이라는 것, 할루시네이션이라는 현상, 그리고 컨텍스트 윈도우라는 제약. 하나씩 볼게요.
첫째, LLM은 사실을 저장하지 않습니다. 다음에 올 단어의 확률을 예측해요. 예를 들어 “오늘 날씨가 ___”라는 문장이 주어지면, “맑다”가 38%, “춥다”가 22%, “흐리다”가 17%… 이런 식으로 확률을 계산해서 가장 그럴듯한 단어를 뽑아 이어 붙입니다. 비유하자면, 숙련된 고스트라이터가 “이 작가라면 다음에 이런 문장을 쓰겠지” 하고 추측하는 것과 비슷해요. 이해하는 게 아니라 패턴 매칭입니다. 그래서 이 과정에는 “진실”이라는 개념이 없습니다. “그럴듯함(plausibility)”만 있어요. 이 지점을 이해하는 게 오늘 강의의 출발점입니다.
둘째, 할루시네이션. 많이 들어보셨을 텐데요, 한국어로는 보통 ‘환각’이라고 번역합니다. AI가 자신만만하게 틀린 말을 하는 현상이에요. 여기서 꼭 기억하셔야 할 건, 이게 고장이 아니라는 점입니다. LLM이 원래 하는 일의 본질 때문에 생기는 현상이에요. 정확하게 작동할수록, 그럴듯하지만 틀린 답을 만들 수 있습니다.
왜 그런지 이유를 다섯 가지로 정리해봤어요. 첫째, 훈련 데이터 자체의 한계 — 인터넷에 있던 오정보가 섞여 들어옵니다. 둘째, “모른다”고 말하는 법을 못 배웠습니다. 2025년에 OpenAI가 낸 「Why Language Models Hallucinate」라는 논문이 있는데요, 훈련 방식 자체가 “모른다”에 애매한 보상을 주기 때문에 모델이 확신에 찬 틀린 답을 주는 쪽으로 편향됐다는 분석이에요. 셋째, 긴 맥락에서 앞쪽을 놓칩니다. 넷째, 토큰을 계속 뱉어내야 한다는 구조적 압력이 있어요. 한 번 답을 시작하면 문법적으로 완성된 문장을 만들려고 그럴듯한 이름이나 사실을 지어냅니다. 다섯째, 인지과학의 작화증(confabulation) 개념과 놀랍도록 비슷한 메커니즘이 있어요. 사람 뇌도 기억이 비어있으면 자기도 모르게 빈칸을 채워서 완성된 기억을 만들거든요.
그런데 사실 ‘할루시네이션’이라는 용어 자체가 논쟁적입니다. 이 단어는 환각이라는 뜻이잖아요. AI를 의인화한다는 비판이 있어요. 에밀리 벤더라는 언어학자는 이렇게 말합니다. “LLM은 환각을 보는 게 아니다. 그냥 확률적으로 단어를 이어 붙이는 것(stochastic parrot)이다.” 대안으로 제안되는 용어들이 있어요. Confabulation(작화), Bullshitting — 이건 철학자 해리 프랭크퍼트의 개념인데 “참과 거짓에 무관심하게 그럴듯한 말을 만드는 행위”라는 뜻이고, LLM에 정확히 맞아요. 그리고 Stochastic Parroting(확률적 앵무새). 어떤 용어를 쓰느냐가 이 기술을 어떻게 이해하느냐의 철학적 입장을 드러냅니다. 저는 오늘 편의상 할루시네이션이라고 쓰지만, ‘환각’이 아니라 ‘그럴듯한 짜깁기’라고 기억해 주세요.
셋째, 컨텍스트 윈도우. 이건 LLM이 한 번에 볼 수 있는 작업 메모리의 크기입니다. 사람으로 치면 워킹 메모리예요. 모델마다 크기가 다릅니다. GPT-3.5는 4K 정도로 아주 짧았고, 지금 Claude Sonnet이나 Opus는 200K에서 1M 정도, Gemini는 최대 2M까지 갑니다. 토큰 개념이 생소하실 텐데, 영어 1토큰이 단어 0.75개 정도, 한국어는 1글자가 1~3토큰이에요. 200K 토큰이면 대략 한국어 책 300~400페이지 정도 들어갑니다. 책 한 권 분량이에요.
그런데 여기서 흥미로운 건, “더 크면 더 좋다”가 꼭 맞는 말은 아니라는 점입니다. 이유가 세 가지 있어요. 첫째, Attention 계산량이 O(n²)입니다. 토큰이 2배가 되면 계산량은 4배, 10배면 100배 늘어납니다. 긴 컨텍스트는 본질적으로 비효율적이에요. 둘째, “Lost in the middle”이라는 현상이 있습니다. 긴 문서의 앞과 끝은 잘 기억하는데, 중간은 흐려져요. 사람이 긴 강의를 들을 때랑 비슷해요. 셋째, 정보가 많을수록 헷갈립니다. 관련 없는 정보까지 attention이 분산돼서 핵심 신호가 잡음에 묻혀요.
컨텍스트는 할루시네이션의 원인이기도 하고 해결책이기도 합니다. 짧아도 탈, 길어도 탈이에요. 컨텍스트가 부족하면 빈칸을 지어내고, 너무 많으면 중간을 놓치고, 대화가 길어지면 초기 설정이 흐려집니다. 초반에 “나는 민석이야”라고 했는데 100턴 뒤 “민수씨”라고 부르기 시작하는 식이죠.
이 섹션의 결론은 이겁니다. LLM의 능력은 단순한 “지능”이 아니라 매우 구체적인 계산 구조의 제약에 묶여 있어요. AI가 똑똑해져서 긴 컨텍스트를 처리하는 게 아니라, 수학적 연산의 제약을 어떻게 우회할 것인가의 엔지니어링 문제입니다. 그러니까 기술을 쓰되, 신화화하지는 맙시다.
그리고 하나 덧붙이면 — 과의존하지 않기. 최종 의사결정의 주체는 항상 사람이어야 합니다. AI를 쓰기 전에 먼저 생각을 정리하고, 결과물은 반드시 직접 검증하고, 의사결정은 언제나 본인이 내리세요.
프롬프트 → 컨텍스트 → 에이전트
이번 섹션이 오늘 강의의 중심 골격입니다. 지난 3년 동안 AI를 잘 쓰는 법이 프롬프트 → 컨텍스트 → 에이전트로 진화해 왔어요. 이 세 단계를 하나씩 짚겠습니다.
먼저 프롬프트 엔지니어링. 2022년 말 ChatGPT가 나오고 1~2년 동안 지배적이었던 패러다임이에요. 핵심 질문은 “AI한테 어떻게 말해야 원하는 답이 나올까?”입니다. 프롬프트의 기본 구조는 지시 · 입력 · 문맥 · 출력 형식이에요.
같은 요청이어도 프롬프트에 따라 결과가 완전히 달라집니다. 나쁜 예는 “보도자료 써줘”입니다. 무엇을? 누구에게? 어떤 톤으로? AI가 다 추측해야 해요. 좋은 예는 이렇게 쓰는 겁니다. “반비에서 출간하는 소설 OO의 보도자료를 써줘. 대상 독자는 20-30대 문학 독자. 분량은 A4 1장. 톤은 격식체. 첫 문장은 인용구로 시작.” 역할, 대상, 분량, 톤, 형식을 다 박아줬죠.
출판 업무의 구체적 예시를 두 개만 보여드릴게요. 하나는 원고 피드백 요약인데요, “이 원고 리뷰 메모 5개를 저자에게 전달할 수정 요청 메일로 바꿔줘. 톤은 존중하되 명확하게.” 이렇게 쓸 수 있습니다. 또 하나는 표지 시안 브리프. “이 소설의 분위기를 3줄로 요약하고, 표지 디자인 키워드 5개를 뽑아줘.” 이런 식이에요. ChatGPT, Claude, Gemini — 어떤 도구를 쓰든 상관없습니다. 도구의 차이보다 프롬프트의 구조가 결과를 결정합니다.
길은수 님 질문에 답하면서 기법 세 가지를 소개할게요. 세 기법 모두 핵심은 같습니다. AI에게 맥락을 좁혀주는 것이에요. 역할로 관점을 좁히고, 예시로 톤을 좁히고, 단계로 사고 순서를 좁힙니다.
첫 번째 기법, Role Prompting — 역할 부여. “너는 ~이야”라고 시작하는 거예요. 배우가 대본을 받으면 캐릭터에 맞게 말투가 바뀌듯, AI도 역할을 주면 어휘와 판단 기준과 톤이 그에 맞게 활성화됩니다. 중요한 건 구체성이에요. 그냥 “편집자”보다 _“10년차 문학 편집자로 번역소설을 주로 담당한”_이 훨씬 낫습니다. 출판 현장에선 이런 역할들을 활용해볼 수 있어요. “20대 여성 독자를 잘 아는 마케팅 카피라이터”로 띠지 문구를, “서평 전문 북칼럼니스트”로 서평 초안을, “베테랑 교정교열자”로 맞춤법 검수를, “해외 판권 에이전트”로 영문 시놉시스를.
두 번째, Few-shot — 예시 보여주기. 말로 길게 설명하는 것보다 예시를 2~3개 보여주는 게 빠르고 정확합니다. 출판은 톤과 문체가 핵심인 업종이라 특히 강력해요. 예시가 0개면 AI 재량에 맡기는 거고, 1개면 방향 제시, 2~3개면 패턴 학습이 됩니다. 단, 5개를 넘기면 오히려 창의성이 떨어지니 주의하세요. 실전에서는 이렇게 씁니다. “올해의 책”이라는 추상적 지시 대신, 기존에 잘 됐던 띠지 문구 2~3개를 붙여넣고 “이 톤으로 새 책 띠지를 써줘” 이렇게요.
세 번째, Chain of Thought — 단계적 사고. “한 번에 다 해줘”는 사람한테도 어려운 요청이잖아요. 단계를 나누면 각 단계에서 더 깊이 생각하고, 중간 결과로 방향을 수정할 수 있어요. 나쁜 예는 “이 원고 읽고 마케팅 메시지 만들어줘.” 좋은 예는 “1단계 — 이 원고의 핵심 주제 3가지를 뽑아줘. 2단계 — 주 타겟 독자가 누구일지 정의해줘. 3단계 — 그 독자에게 먹힐 보도자료 핵심 문장 3개를 써줘.” 이렇게 나누면 각 단계에서 개입도 가능합니다.
출판 업무별로 짧게 정리할게요. 보도자료는 “30대 직장인 대상 자기계발서의 보도자료를 A4 1장 분량, 습니다체로 써줘. 핵심 차별점 3가지를 포함해.” 서점 POP은 “서점 POP용 50자 추천문을 써줘. 비유 하나를 포함하고 물음표로 끝내줘.” 원고 피드백은 “이 소설 1장의 서사 흡인력을 평가해줘. 독자가 2장을 넘길 동기가 충분한지, 부족하다면 구체적 개선안을 제시해.” 번역 검수는 “영한 번역문에서 원문 뉘앙스가 왜곡된 부분, 번역투 표현, 용어 불일치를 표로 정리해줘.”
자, 이제 두 번째 단계 — 컨텍스트 엔지니어링. 2024~2025년의 패러다임입니다. 프롬프트가 1회성이라면 컨텍스트는 누적돼요. 지침(Instructions)과 파일(Knowledge)을 함께 세팅해서 나를 이해하는 AI를 만드는 거예요. 관점을 이렇게 바꿔보세요. AI는 바보가 아니라 정보가 없는 똑똑한 기계입니다. 작업 환경을 잘 세팅해주면 잘합니다.
두 가지 방법이 있어요. Google의 Gem과 Anthropic의 Claude 프로젝트. Gem은 시스템 프롬프트 프리셋이에요. 가볍고 빠르고, 구글 워크스페이스와 자연스럽게 연동됩니다. gemini.google.com에서 Gem manager 열고 새 Gem을 만들면 돼요. Claude 프로젝트는 시스템 프롬프트에 더해서 파일과 지식 업로드까지 가능합니다. 더 깊은 맥락을 유지할 수 있어요. Gem은 파일 업로드 기반 지식 관리가 약하기 때문에, 스타일 가이드 같은 문서를 넣어두고 싶으면 Claude 프로젝트가 더 적합합니다. 민음사 환경은 구글 워크스페이스이니 Gem으로 가볍게 시작하시고, 깊은 맥락이 필요하면 Claude 프로젝트도 써보세요.
세 번째 단계, 에이전트 엔지니어링. 2025년부터 지금(2026년)까지의 새로운 패러다임이에요. 여기서 AI가 직접 행동하기 시작합니다. 핵심 질문은 이거예요. “AI가 스스로 계획하고, 도구를 쓰고, 여러 단계를 거쳐 목표를 달성하게 하려면?”
프롬프트나 컨텍스트와 다른 점이 다섯 가지입니다. 첫째, 목표 지향적. “이 보고서 써줘”가 아니라 “이 회사를 분석해줘” 수준의 추상적인 목표를 줍니다. 둘째, 자율적 판단. 어떤 도구를 쓸지, 어떤 순서로 할지 AI가 결정해요. 셋째, 여러 턴에 걸친 작업. 검색 → 분석 → 재검색 → 정리 → 작성. 스스로 루프를 돕니다. 넷째, 환경과 상호작용. 파일 읽고 쓰고, 코드 실행하고, 웹 브라우징합니다. 다섯째, 스스로 오류 수정. 실패하면 다시 시도해요.
여기서 한 발짝 물러나서 전체 흐름을 봅시다. 프롬프트 → 컨텍스트 → 에이전트로 갈수록 인간이 AI에게 넘기는 결정권이 커집니다. 프롬프트 시대에는 인간이 단어 단위로 통제했고, 필요한 스킬은 말 잘하는 법, 즉 언어학적 능력이었어요. 컨텍스트 시대에는 인간이 정보 환경을 설계합니다. 스킬은 정보 아키텍처. 에이전트 시대에는 인간이 목표만 주고 실행은 AI에게 위임해요. 스킬은 위임과 감독 — 매니지먼트입니다. “AI를 잘 쓰는 법”의 정의 자체가 ‘말하기 → 설계하기 → 매니지먼트’로 이동 중이라는 거예요.
지금 우리는 2026년 봄입니다. 프롬프트와 컨텍스트 엔지니어링은 어느 정도 성숙했고, 에이전트 엔지니어링이 가장 뜨거운 영역이에요. 다만 아직 불안정하고 연구 중입니다. 2025년 중반부터 업계에서 자주 들리는 말이 _“We’re in the agent era now.”_예요. 다음은 뭘까요? 멀티 에이전트 오케스트레이션, 에이전트끼리 협력하는 사회. Embodied AI, AI가 로봇으로 물리 세계에 진출. Persistent agents, 24시간 내 비서처럼 돌아가는 AI. Agent-native 소프트웨어, 처음부터 에이전트를 위해 설계된 소프트웨어. “Agent Engineer”라는 직업이 “Agent Manager”로 바뀔 거라는 예측도 나옵니다. 솔직히 이 흐름이 어디까지 갈지, 어디서 한계에 부딪힐지는 아무도 모릅니다.
바이브 코딩과 인쇄술
이번 섹션에서는 비유를 하나 꺼내려고 합니다. 바이브 코딩과 인쇄술. 좀 거창해 보이지만, 저는 이 비유가 지금 상황을 가장 잘 설명한다고 생각해요.
1450년경 독일 마인츠. 구텐베르크가 활판 인쇄술을 발명합니다. 그 전에는 필경사가 손으로 한 권씩 베껴 써야 책이 나왔어요. 책은 소수의 전유물이었습니다. 인쇄술 이후에는 누구나 책을 만들 수 있게 됐어요. 지식의 민주화가 일어난 거죠. 그런데 그때도 반발이 있었다는 사실, 아세요? “필사가 더 아름답다”, “책의 가치가 떨어진다”, “신성함이 사라진다” — 지금 AI에 대해 우리가 하는 이야기와 놀랍도록 비슷합니다.
저는 바이브 코딩이 소프트웨어의 인쇄술이라고 봅니다. 이전에는 개발자만 소프트웨어를 만들 수 있었어요. 이제는 업무를 가장 잘 아는 사람이 직접 도구를 만들 수 있게 됐습니다. 여러분 같은 편집자가요. ‘바이브 코딩’이라는 말은 Andrej Karpathy — Tesla AI 디렉터였던 사람이 만든 말이에요. “분위기로 코딩한다”는 뜻입니다. 완벽한 코드가 아니라, “대충 이런 느낌”으로 시작해서 다듬어가는 거예요.
도구를 간단히 비교할게요. 채팅 AI vs 클로드 코드. 채팅 AI는 브라우저나 데스크톱 앱에서 대화하는 형태예요. 질문하면 답해줍니다. 하지만 파일을 직접 다룰 수는 없어요. 클로드 코드는 내 컴퓨터 환경 안에서 같이 일하는 동료에 가깝습니다. 파일을 읽고, 만들고, 실행합니다. VS Code 안에서 바로 작업할 수 있어요. 같은 Claude LLM을 쓰지만 접근하는 범위가 완전히 다릅니다.
바이브 코딩으로 한 발 더 나가면 — 비개발자도 가능한 것과 어려운 것이 있어요. 가능한 것은 간단한 웹페이지와 설문 폼, 데이터 정리·시각화 스크립트, 업무 자동화(슬랙봇·시트 연동), MVP와 프로토타입. 어려운 것은 복잡한 로그인과 결제, 대규모 트래픽 처리, 보안이 중요한 서비스, 장기 유지보수와 디버깅. 결론은 — 자기 업무의 작은 자동화와 1인용 도구 제작은 매우 강력하게 할 수 있다.
마무리 + Q&A
이제 마무리입니다. 오늘 이야기를 세 줄로 요약하면 이래요.
첫째, 내 일의 흐름을 먼저 생각해보세요. AI를 어떻게 쓸지 고민하기 전에, 내 전체 업무 흐름을 먼저 떠올려보고 AI와 함께할 일을 골라보세요. 기술이 먼저가 아니라 업무가 먼저입니다.
둘째, 한 번에 좋은 결과보다, 점진적으로 더 나은 결과를. 완벽한 프롬프트를 한 번에 쓰려고 하지 마세요. 맥락을 잘 주고, 일단 말 걸고, 대화하면서 다듬어가세요. AI는 반복 가능한 동료입니다.
셋째, 동료와 함께 나누세요. 혼자 해결하려고 하지 마시고, 옆자리 동료가 만든 작은 경험을 공유해보세요. 옆자리 동료가 만든 작은 경험이, 비싼 강의 10시간보다 낫습니다. 이건 진심이에요.
오늘 당장 해볼 수 있는 체크리스트 세 개 드릴게요. ① Gemini에서 Gem 하나 만들어보기 — 이름 짓는 것부터 시작하세요. ② 반복 업무 중에 “이건 AI한테 시켜볼까?” 하나 골라보기. ③ 동료와 함께 결과물 비교해보기.
여기까지가 오늘 제가 준비한 이야기입니다. 이제부터는 여러분의 시간이에요. 무엇이든 물어보세요. 오늘 이야기한 도구나 사례, 그리고 여러분의 업무에 적용할 수 있는 구체적인 질문을 가장 환영합니다. 감사합니다.