어느 AI 에이전트 엔지니어가 말하는, ‘세컨 브레인’부터 ‘티코로 운전하기’까지 — 도구가 아니라 사용법을 설계하는 사람의 이야기
한 AI 에이전트 엔지니어와의 대담을 정리한다. 그는 ‘세컨 브레인(Second Brain, 제2의 두뇌)’이라 불리는 조직 지식 시스템을 직접 만들어 운영하는 사람이다. 대담은 기술 자랑이 아니라 한 가지 질문으로 수렴한다. AI를 왜, 그리고 어떻게 써야 하는가. 그가 마지막에 남긴 비유가 글 전체를 묶는다. F1 영상을 본다고 운전 실력이 늘지 않으며, 공도는 트랙이 아니고, 내 차는 티코다. 그러니 “티코로 운전을 해 보라”는 것이다. 남의 사용법을 베끼지 말고 자기 차에 맞는 운전법을 찾으라는 뜻이다. 아래는 그가 던진 논점들을 주제별로 다시 묶고, 등장한 개념들을 사실관계 위에서 보강한 기록이다.
출발점은 거창한 이론이 아니라 불편함이었다. 이전 회사를 다닐 때, 회사의 지식은 여러 곳에 흩어져 있었다. 누군가는 슬랙(Slack)에 적어 두고, 누군가는 구글 드라이브(Google Drive)에 파일로 올리고, 결정적인 맥락은 전화 통화나 메일 속에 묻혀 있었다. 도구를 이어 주는 연결 서비스는 많았지만, 팀 단위로 그 지식을 투명하게 들여다볼 수 있는 시스템은 없었다.
이 공백이 가장 아프게 드러나는 순간이 신규 입사자의 온보딩(onboarding, 적응 과정)이다. “이 프로젝트는 왜 이렇게 굴러가지?”라는 질문에 답해 줄 문서가 없다. 검색해도 안 나오고, 잘 아는 동료에게 물어보는 건 확률 게임이다. 상대가 바쁘면 못 묻고, 기억은 왜곡될 수 있으며, 무엇보다 같은 질문을 반복해 묻기가 미안하다. 그는 이 반복되는 ‘다시 찾기’ 작업 자체를 손실로 본다.
검색이 안 되는 이유 중 하나는 단어 하나의 차이다. ‘RFP(Request for Proposal, 제안 요청서)’를 찾고 싶은데 어떤 문서에는 ‘요구사항’으로, 다른 문서에는 ‘제안서’로 적혀 있으면, 키워드 검색으로는 영영 만나지 못한다. 사람의 기억과 조직의 기록은 이렇게 어휘 단위에서 갈라진다.
회사를 한 사람이라고 치면, 슬랙·드라이브·메일·통화는 각각 다른 서랍에 넣어 둔 메모다. 정작 필요할 때는 “분명 어딘가 적어 뒀는데 어느 서랍인지 기억이 안 난다.” 세컨 브레인은 이 흩어진 서랍들을 하나의 ‘제2의 기억’으로 묶어, 평소에 물어보면 알아서 꺼내 주는 비서를 두는 일에 가깝다.
핵심 아이디어는 단순하다. 회사의 모든 지식을 한곳에 모아 두고, 물어보면 답하게 만든다. 기술적으로는 RAG(Retrieval-Augmented Generation, 검색 증강 생성)다. 슬랙·깃(Git)·구글 드라이브 등 어디에 있든 커넥터(connector, 연결기)만 붙이면 수집·검색이 된다.
다만 그는 사람이 이 검색을 직접 ‘호출’하지 않기를 바랐다. 사람이 매번 검색창에 들어가 단어를 고르는 대신, AI 에이전트(AI agent, 자율 행위 AI)가 알아서 이 지식 저장소를 불러 쓰도록, 그 위에 얇은 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜) 레이어를 둘렀다. MCP는 앤트로픽(Anthropic)이 공개한 개방형 규약으로, AI 모델이 외부 도구·데이터에 표준화된 방식으로 접근하게 해 주는 ‘공용 콘센트’ 같은 것이다. 그 결과 사람은 자연어로 묻기만 하고, 에이전트 런타임(runtime, 실행 환경)이 답을 종합해 돌려준다.
RAG의 가장 큰 약점은 데이터가 쌓일수록 드러난다. 정제(cleansing)되지 않은 채로 자료가 누적되면, 이상한 데이터가 섞여 들기 시작한다. 그는 이것이 많은 RAG 프로젝트가 오래 살아남지 못하는 이유라고 본다. 자료가 많아질수록 RAG가 더 정확해질 것이라는 통념에 그는 의문을 단다.
그의 해법은 LLM(Large Language Model, 대규모 언어 모델)을 검색과 답변 사이에 큐레이터(curator, 선별·편집자)로 끼워 넣는 것이다. 여러 출처에서 끌어온 조각들은 ‘연관성’은 비슷해도, 무엇이 핵심이고 무엇이 지금 필요한 정보인지는 다르다. AI가 그 핵심을 가려 다시 정렬해 주면, RAG의 ‘유통기한’이 길어진다. 흩어진 단서를 합쳐 하나의 답으로 만들되, 반드시 원본 출처를 함께 제시한다. 환각(hallucination, 사실과 다른 그럴듯한 생성)을 견제하기 위해서다.
검색해서 찾았으면, 사람도 결국 그 쓰레드를 직접 파고들어 확인한다. 그런데 왜 우리는 항상 모든 데이터가 RAG 안에 한 번 다 펼쳐져야 한다고 생각했을까. — 인터뷰 중, RAG 통념에 대한 문제 제기를 옮김
그가 RAG와 자신의 세컨 브레인을 가르는 한마디는 ‘살아 있는 답(living answer)’이다. 한 번 박제되어 시간이 지나면 틀려 버리는 ‘죽은 답’이 아니라, 원본이 바뀌면 결과도 함께 갱신되는 답을 지향한다. 정리되지 않은 지식, 즉 문서로 명문화되지 않은 관행과 맥락까지 포함해 정리하려는 것이 그가 말하는 큐레이션의 범위다. 같은 문장을 여러 사람이 동시에 만들기도 하므로, 맥락·이력·이유를 설명할 수 있어야 하고 출처는 당연히 따라붙어야 한다.
일반적인 RAG가 “관련 있어 보이는 책 30권을 책상에 쌓아 주는” 단계라면, 큐레이션을 얹은 세컨 브레인은 “당신이 지금 풀려는 문제에 맞춰 핵심 세 문단을 짚어 주고, 어느 책 몇 쪽에서 가져왔는지까지 알려 주는 사서”에 가깝다. 자료의 양이 같아도, 사서가 있고 없고에 따라 답의 수명이 달라진다.
그는 또 하나, 사람만이 쓰던 지식 저장소에 ‘AI 에이전트용 안내문’을 따로 둔다고 말한다. 데이터베이스(DB)를 올릴 때 사람용 설명만이 아니라, 에이전트가 읽고 스스로 구성·사용할 수 있게끔 별도의 마크다운(Markdown, 경량 서식 문서) 파일을 제공하는 식이다. 데이터의 주체가 사람에서 에이전트로 옮겨 가는 흐름을 설계에 미리 반영한 셈이다.
실제 쓰임은 평범하면서도 결정적이다. “재택근무 규정이 어떻게 되느냐”를 물었을 때, 문서가 없고 슬랙 공지로만 떠돌았다면 기존 검색으로는 출처조차 못 찾는다. 세컨 브레인은 슬랙 스레드를 끌어오거나, 깃 커밋(commit, 변경 기록)을 분석해 근거와 함께 답한다. “우리는 왜 이렇게 일하고 있지?”라는 관행·노하우의 출처를 되짚는 일, 반복되는 재작업을 피하도록 가이드하는 일 — 이런 것이 그가 보는 세컨 브레인의 역할이다. 슬랙이든 노션(Notion)이든 컨플루언스(Confluence)든, 사용자는 ‘어디에 있는지’를 따지지 말고 그냥 물어보면 된다는 것이다.
대담은 여기서 기술에서 태도로 넘어간다. 그가 AI를 쓰는 이유는 한 단어로 ‘인간의 레버리지(leverage, 지렛대 효과)’다. 여러 명이 해야 할 일을 혼자 쳐내는 것. 인터뷰 상대 역시 같은 결로 답한다 — AI는 특별한 무엇이 아니라 일을 편하게 해 주는 도구이고, 혼자 여러 사람 몫을 처리하려고 쓴다는 것이다.
다만 그는 도구를 늘리는 것 자체가 생산성이라는 통념엔 선을 긋는다. 도구가 많아지면 노이즈(noise, 잡음)도 심해진다. 한곳에서 작업할 때 인간의 효율이 가장 좋다고 보고, 그래서 그에게 ‘그 한곳’이 AI이며 구체적으로는 클로드(Claude)와 클로드 코드(Claude Code), 그리고 그것을 감싸는 터미널(terminal, 명령줄 환경)이다.
그런데 지렛대는 양쪽으로 작동한다. 장점이 열 배가 되면 단점도 열 배가 된다는 것이 그의 경계다. 가장 큰 함정은 게으름이다. AI가 만든 결과를 제대로 리뷰하지 않고 신뢰한 채 남에게 넘기면, 받는 쪽이 다시 검토해야 하는 악순환이 돈다. 속도는 늘었는데 정작 작업은 끝나지 않은 상태 — 리뷰에서 크게 깨지고 나서야 깨닫는 그 함정이다.
뛰고 있으면 걷고 싶고, 걷고 있으면 앉고 싶다. 사람에겐 늘 게으름이 있다. AI를 쓰면 시간이 남으니 “알아서 잘하겠지” 하고 확인을 건너뛰게 된다. 그게 가장 위험하다. — 인터뷰 중, 레버리지의 그늘에 대해 옮김
“던지면 다 된다”는 기대가 위험한 이유는, 가장 앞선 자율 코딩 에이전트조차 ‘명확히 정의된 작업’에서 강하고 ‘모호한 요구·중간 방향 전환’에서 약하다는 점이 공개적으로 인정되고 있기 때문이다. 코그니션(Cognition Labs)의 데빈(Devin)은 2024년 3월 “세계 최초의 완전 자율 AI 소프트웨어 엔지니어”를 표방하며 등장했고, 출시 당시 SWE-bench(실제 깃허브 이슈 해결 벤치마크)에서 약 13.9%를 풀어 종전 최고치를 크게 끌어올렸다.
이후 성능은 빠르게 올랐지만, 제작사 스스로 “주니어(junior, 신입) 개발자가 네다섯 시간에 끝낼 만한, 검증 가능한 작업에 맡기고 결과물(PR)을 사람이 반드시 검수하라”고 권한다. ‘던지기’가 아니라 ‘체크포인트에서 사람이 다시 들어오는’ 방식을 권장한다는 점은, 인터뷰 속 ‘게으름 경계’와 정확히 맞닿는다.
근거: Cognition “Introducing Devin”(2024.3) 및 후속 성능 공개 자료. 수치는 출시 시점 기준이며 이후 갱신됨.
그래서 그는 누군가 AI를 쓴다고 하면 늘 묻게 된다고 한다. “비전(vision, 목표)이 뭐냐. 왜 쓰느냐.” 도구를 쥐었다는 사실보다, 그 도구로 무엇을 더 하려는지가 결과를 가른다는 것이다.
문제를 정의하고 해결하는 일은 이제 AI도 잘한다. 그렇다면 사람은 무엇을 하는가. 그의 답은 ‘암묵지(暗默知, tacit knowledge)를 꺼내 쓰는 일’이다. 암묵지는 헝가리 출신 과학철학자 마이클 폴라니(Michael Polanyi)가 정식화한 개념으로, “우리는 말할 수 있는 것보다 더 많이 안다”는 명제로 요약된다. 요구사항 정의서에 적힌 글자 아래에는, 고객조차 말로 옮기지 못한 진짜 의도가 깔려 있다.
좋은 엔지니어는 그 의도를 먼저 읽어 낸 뒤, 인터뷰 질문으로 바꿔 “이게 맞습니까?”라고 되묻는다. 고객이 그 선택지 앞에서 비로소 진짜 원하는 바를 고른다. 전통적으로는 PM(Product Manager, 제품 관리자)이 이 역할을 잘했다. 그는 이제 개발자도 이 역량으로 평가받는 시대가 왔다고 본다. 2년 전만 해도 ‘개발만 잘하는 사람’이 최고였지만, 지금은 그 능력만으로는 부족하다는 것이다.
인터뷰에 등장하는 FD/FDE(Forward Deployed Engineer, 현장 배치 엔지니어)는 데이터 분석기업 팔란티어(Palantir)가 2000년대에 만든 직무다. 군사 용어 ‘전진 배치(forward deployed)’에서 따온 이름으로, 후방 본사가 아니라 ‘현장’에서 일한다는 뜻이다. 정보기관 같은 고객은 무엇이 필요한지 명확히 말해 주지 못했고, 사양서를 받아 본사에서 만들어 넘기는 전통적 방식이 통하지 않았다. 그래서 팔란티어는 엔지니어를 고객 환경 안으로 들여보내 함께 빌드하게 했다.
FDE의 정의는 ‘고객 팀에 직접 합류해 스탠드업에 참석하고, 고객 저장소에 커밋하며, 제품이 나갈 때까지 기술 전반을 책임지는 풀스택 제너럴리스트’다. 사양서를 던지고 떠나는 솔루션 아키텍트(SA)와의 결정적 차이는 “FDE는 코드를 쓰고 배포한다”는 점이다. 흥미롭게도 이 모델은 최근 OpenAI·램프(Ramp) 같은 AI 기업들이 다시 채택하고 있다. AI 에이전트 도입이 만들어 내는 통합 복잡성이, 바로 현장에서 디버깅할 사람을 요구하기 때문이다.
근거: Palantir FDE 모델 해설 다수(2025–2026), Pragmatic Engineer 뉴스레터 등.
인터뷰 상대인 1인 디자이너는 같은 통증을 다른 자리에서 겪는다. 프로덕트 디자인에 집중하려는데 카드뉴스·영상편집 업무가 끼어들면, 그 ‘본질적 문제를 파고드는 사고’가 매번 끊긴다. 여러 분야에 걸치면 한 분야의 깊이가 옅어진다. 그도 자동화를 시도했지만 API(Application Programming Interface, 응용 프로그램 인터페이스) 비용 문제로 다시 사람이 하는 쪽으로 돌아왔다고 말한다. 여기서 대담은 ‘아키텍처(architecture, 구조 설계)’ 이야기로 넘어간다.
그는 디자이너의 막힘이 결국 기술 아키텍처의 문제라고 본다. AI 비용을 얼마나 효율적으로 쓰는가, 기존 지식 베이스를 어떻게 가져가는가, 내 의도를 얼마나 명확히 전달하는가 — 이것은 기존 방식이 아니라 ‘AI 네이티브(AI-native, AI를 전제로 설계된) 시대의 새로운 아키텍처’라는 것이다. 그가 든 예가 인상적이다. 영어를 못하는 자신이 미국인 친구와 두 시간짜리 대화를, 좋은 품질로 600원 수준에 끊을 수 있다면 — 그 단가 설계 자체가 아키텍처에 대한 고민이라는 얘기다.
결론은 ‘제너럴리스트(generalist, 다방면 전문가)의 부상’이다. 과거의 제너럴리스트에는 허수가 많았다. 한 사람이 아는 분야는 좁을 수밖에 없었기 때문이다. 그러나 이제는 레버리지가 가능하다. 깊이가 부족한 영역을 AI로 메우는 ‘T자형 인재’가, 가로획의 폭을 진짜로 넓힐 수 있게 됐다는 것이다.
그가 여러 사례를 보며 내린 구분은 단순하다. AI를 쓰는 방식은 크게 두 가지다. 던진다, 그리고 코워크(cowork, 함께 일하기)한다. 둘은 전혀 다르다. 던지는 사람은 일이 끝나기만 바란다. 퇴근 시간 안에 PR(Pull Request, 코드 병합 요청)만 올리면 되는 사람에게 AI는 그저 기계다.
핵심은 ‘실력이 쌓이는 방식’이다. 던지는 사람의 AI 활용 실력은 단리(單利, 단순 누적)로 늘고, 묻고 함께 설계하는 사람의 실력은 복리(複利, 누적분에 다시 이자가 붙는 가속 성장)로 늘어난다. 시간이 갈수록 두 곡선의 간격은 벌어진다. 앞서 말한 FD나 제너럴리스트가 강해지는 시대가 이미 와 버린 이유도 여기에 있다.
작업이 끝나기만을 목표로 한다. 결과를 검수하지 않고 넘긴다. AI는 자판기처럼 소비되고, 사용자에겐 노하우가 거의 남지 않는다.
AI가 결과를 내는 도중에 개입해 의도한 방향으로 이끈다. 매 작업에서 ‘어떻게 써야 잘 되는가’가 누적되어, 다음 작업의 출발선이 올라간다.
대담에서 가장 논쟁적인 대목이다. 인터뷰 상대는 “사람은 AI에게 지식을 던져 주는 주체이니 한 단계 앞서 있지 않냐”고 묻는다. 그는 오히려 사람이 뒤처졌다고 본다. 한 사람이 아는 지식의 단편은, AI가 가진 지식 총합보다 작다는 것이다. 자신은 백엔드(back-end, 서버 측)와 프런트엔드(front-end, 화면 측)를 자유롭게 넘나들 수 없지만 AI는 가능하다는 예를 든다.
“AI는 학습된 데이터 안에서만 답한다”는 통념에도 그는 반론한다. 웹 검색(web fetch, 웹에서 끌어오기)이 가능하므로 학습 시점 이후의 자료로도 답하며, 사람이 놓친 부분을 잡아 주거나 가끔은 새로운 결합을 만들어 낸다는 것이다. 그가 드는 결정적 사례가 알파고(AlphaGo)다.
딥마인드(DeepMind)의 알파고 계열 중 ‘알파고 제로(AlphaGo Zero, 2017)’는 인간 기보 없이, 백지 상태에서 자기 자신과 두는 대국만으로 학습했다. 데이터가 부족하면 스스로 데이터를 만들어 학습한다는 발상은 이때 이미 증명됐다. 인터뷰의 “AI가 정보를 만들어 내지 못한다는 건 아니다”라는 주장은 이 사례에 기대고 있다.
맥락: 자가 대국 기반 강화학습은 알파고 제로의 핵심 설계로 널리 알려져 있다.
그는 한 걸음 더 나아가 “AGI(Artificial General Intelligence, 범용 인공지능)는 이미 반년 전에 왔다”고까지 말한다. 근거는 ‘인간과 다르지 않다’는 관찰이다. 팀장이 일을 시키는 워크플로우 — 무슨 일을 할지 정하고, 어떻게 분배할지 정하고, 누구에게 맡길지 결정해 지시·감독하는 과정 — 가 AI 에이전트를 잘 쓰는 방식과 다르지 않다는 것이다.
‘AGI가 반년 전에 왔다’는 인터뷰어 개인의 판단이며, 학계·산업계의 합의가 아니다. 애초에 AGI의 정의부터 갈린다. 인터뷰에서도 “한 회사를 대체할 수 있으면 AGI”라는 기준(일론 머스크가 제시했다고 소개된 정의)이 거론되지만, 이는 여러 정의 중 하나일 뿐이다. ‘인간 수준의 범용 인지’를 기준으로 삼는 전통적 정의에서 보면, 현재 시스템은 좁게 정의된 작업에서 강하고 장기 자율성·실세계 일반화에서 한계가 분명하다는 평가가 일반적이다.
따라서 이 대목은 ‘현재 에이전트가 팀 단위 업무 분해·위임 구조를 흉내 낼 만큼 실용적이다’라는 체감으로 읽는 편이 안전하다. 정의를 어디에 두느냐에 따라 “이미 왔다”와 “아직 멀었다”가 동시에 성립한다.
그는 ‘1인이 AI만으로 회사를 운영하는 것’과 ‘AI가 회사를 운영하는 것’을 구분하며, 인사·재무·마케팅 자동화 도구가 이미 시장에 다 나와 있어 조합하거나 스스로 만들어 낼 수 있는 시대라고 본다. 다만 ‘피지컬 AI(physical AI, 물리 세계를 다루는 AI)’가 물류·데이터센터 같은 물리 인프라까지 장악하는 단계는 위험하다고 덧붙인다. 여기서 그는 그 단계를 별도로 부르는데, 이는 정의 논쟁의 연장선일 뿐 본질은 ‘어디까지를 AGI로 부를 것인가’의 문제다.
인터뷰어는 사람의 감성을 건드려 폭발적으로 퍼지는 콘텐츠는 인간의 영역이 아니냐고 묻는다. 그는 자신도 ‘쇼츠(short-form video, 짧은 영상) 만들기’를 사이드 프로젝트로 먼저 시도했고, 학습된 데이터로 사람의 감정을 움직이는 일이 어렵다는 점을 인정한다. 다만 이미지 생성 모델이 광고에 쓰일 만큼 올라온 지금, ‘한 번에 터지는 대박’은 어렵더라도 지속적인 결과물을 뽑아내는 일은 이미 가능하다고 본다. ‘확 터뜨리는’ 마지막 한 끗은 여전히 사람의 영역으로 남겨 둔다.
그가 스스로를 ‘휴먼 인 더 루프(human-in-the-loop, 사람이 고리 안에 있는 방식)’의 신봉자라 부르는 이유가 여기서 분명해진다. 코워크의 핵심은 AI가 결과를 내거나 내는 도중에 사람이 개입해 의도한 방향으로 이끄는 것이다. 기획은 사람이 앞단(front-end)에서 하고, AI가 그 기획 의도에 맞게 움직이도록 조절하는 것 — 그것이 그가 말하는 AI 사용법이다.
사람은 AI보다 절대로 뒤처져선 안 된다. 항상 한 발이라도 앞에 나가 있어야 한다. 그렇지 않으면, 그 사람을 채용하거나 그 사람이 일할 이유 자체가 사라진다. — 인터뷰 중, 휴먼 인 더 루프의 원칙을 옮김
그는 채용에 빗댄다. 사람을 뽑을 때 우리는 면접으로 배경을 파악하고, 무슨 일을 할 수 있는지, 나아가 어떻게 그를 활용해 일을 시킬지까지 생각한다. AI도 같다. 어떤 데이터로 학습했는지(벤치마크), 무슨 스킬이 좋은지, 어떤 도구를 붙이면 무엇을 할 수 있는지를 알아 가야 한다. 그런데 많은 사람이 ‘어떻게 사용할 수 있는가’에는 의외로 무관심하다는 것이 그의 지적이다.
그가 던지는 가장 실용적인 조언은 의외로 평범하다. 공식 문서를 직접 읽어라. 클로드 코드를 쓰는 사람이라도 정작 공식 문서를 본 사람은 “100명을 만나도 한 번도 없었다”고 그는 말한다. 남이 정리해 준 글은 결국 그 사람의 ‘하네스(harness, 모델을 둘러싼 운용 장치·설정)’일 뿐, 참고는 되되 베이스(base, 기초)가 되진 못한다. 그 베이스가 바로 공식 문서라는 것이다.
그는 AI를 ‘척척박사’가 아니라 ‘척척학사’라고 부른다. 박사처럼 한 분야를 끝까지 파고드는 깊이가 아니라, 학사처럼 넓게 두루 아는 종류의 지능이라는 비유다. 그래서 잘 쓰려면 “얘가 왜 박사가 아니고 학사인지”를 이해해야 한다. 그 이해는 거창한 이론 공부가 아니라, 지금 쓰는 그 서비스의 기능과 본질을 하나씩 써 보는 일에서 나온다.
자동차를 운전하려고 내연기관 공학을 전공하지는 않는다. 면허만 따면 된다. 무엇이 액셀이고 브레이크인지, 사이드 브레이크는 무엇인지 — 그 ‘면허 책’이 곧 공식 문서다. 그래서 그는 “AI를 잘 쓰려면 LLM을 공부하라”는 흐름에 선을 긋는다. 운전을 위해 엔진을 분해할 필요는 없다는 것이다. 서브에이전트(sub-agent, 하위 에이전트), 룰(rule, 규칙), 라우팅(routing, 작업 분배) 같은 ‘하네스 엔지니어링’도 공식 문서를 보면 별것 아니라고 그는 말한다.
그는 이 변화를 과거 ERP(Enterprise Resource Planning, 전사적 자원 관리) 도입에 빗댄다. 그때 모두가 ERP를 공부하라 했고, 종이만 고집한 사람들은 대체로 사라졌다. AI도 하나의 전환이며, 디지털 전환(DX, Digital Transformation)을 넘어 ‘AI 전환(AX, AI Transformation)’이라고 그는 명명한다. 그러면서 “지금이 막차”라고 강조한다. 클로드 같은 서비스의 기능이 아직 적고 단순할 때, 즉 공부할 분량이 적을 때 익혀 두라는 뜻이다.
공식 문서를 베이스로 삼으라는 조언은 타당하다. 다만 ‘DX는 필요 없고 AX만 하면 된다’거나 ‘LLM 공부는 불필요하다’는 단정은 일반화하기 어렵다. 비용·보안·데이터 거버넌스(governance, 관리 체계)가 걸린 조직 도입에서는 모델의 작동 원리에 대한 최소한의 이해가 의사결정 품질을 가른다. 운전 비유로 돌아오면, 일반 운전자에겐 면허로 충분하지만 정비·튜닝을 책임지는 사람에겐 엔진 지식이 필요한 것과 같다. 역할에 따라 필요한 깊이가 다르다고 읽는 편이 정확하다.
대담은 처음 던진 비유로 되돌아와 닫힌다. 운전을 잘하고 싶다고 F1 영상을 본다 해서 실력이 늘지 않는다. 챔피언처럼 몰 수도 없고, 공도는 트랙이 아니며, 내 차는 티코다. 그러니 티코로 직접 운전을 해 보라는 것이다. 남이 정리해 준 사용법, 남의 하네스를 베끼는 대신 자기 차에 맞는 운전법을 찾으라는 말이다.
공부하는 과정에서 남을 따라가지 않았으면 좋겠다. 나에게 맞는 AI 사용법을 찾아야 한다. 본인을 기준으로 하나씩 직접 해 봐야 한다. — 인터뷰 마무리, 핵심 메시지를 옮김
이 대담을 관통하는 태도는 ‘도구 자랑’이 아니라 ‘사용법 설계’다. 어떤 모델이 더 세냐의 경쟁이 아니라, 같은 모델을 두고 누가 더 자기 문제에 맞게 길들이느냐의 경쟁으로 무게중심이 옮겨 가고 있다는 관찰이다. 등장한 개념들 — 세컨 브레인, MCP, FD, 암묵지, 휴먼 인 더 루프 — 은 서로 다른 자리에서 같은 한 가지를 가리킨다. 사람이 ‘무엇을·왜’를 쥐고 한 발 앞에 서 있을 때, AI는 비로소 지렛대가 된다.