[태그:] AI 에이전트

AI 에이전트의 구조, 실행형 자동화, 개발 생산성, 업무 적용 사례를 다룬 글 모음입니다. 에이전트 기반 도구와 운영 관점을 함께 정리합니다.

  • 소형 언어 모델과 오픈소스 AI, 승자독식 구조를 깰 수 있을까

    소형 언어 모델과 오픈소스 AI, 승자독식 구조를 깰 수 있을까

    AI 경쟁을 이야기할 때 가장 먼저 떠오르는 단어는 GPU, 초거대 모델, 빅테크입니다. 하지만 스탠포드대 최예진 교수는 조금 다른 질문을 던집니다. “더 크게 만드는 것”만으로 충분한가, 그리고 AI는 정말 더 많은 사람과 조직이 만들고 통제할 수 있는 기술이 되고 있는가라는 질문입니다.

    PLUS TV 인터뷰에서 최예진 교수는 대형 언어 모델 중심의 승자독식 구도, 소형 언어 모델의 가능성, 한국의 피지컬 AI 전략. 그리고 AI 시대 개인에게 필요한 역량을 폭넓게 설명했습니다. 이 글은 영상을 단순 요약하기보다, 한국 기업과 개인이 실제로 가져가야 할 판단 기준으로 묶어 봤습니다.

    최예진 교수를 소개하는 PLUS TV 인터뷰 장면
    최예진 교수를 소개하는 PLUS TV 인터뷰 장면

    출처 영상

    AI 업계는 하이프에서 현실 점검으로 이동했다

    최예진 교수는 지난 1년 사이 AI 업계의 분위기가 바뀌었다고 말합니다. 이전에는 “AI가 곧 모든 것을 바꿀 것”이라는 기대가 컸습니다. 지금은 산업 현장에서 실제 이익이 얼마나 빠르게 확산되는지, 현재 AI가 무엇을 잘 못하는지, 어떤 방식으로 부족한 부분을 보완해야 하는지에 대한 대화가 많아졌습니다.

    먼저 볼 부분은 학습 방식입니다. 지금의 생성형 AI는 방대한 데이터를 수동적으로 읽고 패턴을 익히는 방식에 많이 의존합니다. 최 교수는 이를 “문제집을 많이 풀어 성적을 올리는 학생”에 비유합니다. 문제집을 많이 푼다고 창의력이 반드시 좋아지는 것은 아닙니다.

    사람은 모르는 것을 다시 묻고, 이해가 안 되는 부분을 되짚고, 자기 방식으로 공부합니다. 반면 현재 AI는 주어진 문장과 문서를 그대로 받아들이는 경우가 많습니다. 앞으로의 중요한 연구 방향은 AI가 더 능동적으로 배우고 추론하도록 만드는 데 있습니다.

    왜 ‘남들이 안 하는 선택’이 중요했나

    최예진 교수의 커리어에서 흥미로운 지점은 안정적인 길보다 어려운 길을 선택했다는 점입니다. 그는 마이크로소프트에서 소프트웨어 개발자로 일하다가 AI 연구로 방향을 바꿨습니다. 당시 AI는 지금처럼 각광받는 분야가 아니었습니다. 오히려 “AI의 겨울” 이후 전망이 불확실한 비주류 분야에 가까웠습니다.

    그럼에도 그는 어렵고 도전적인 분야에 먼저 뛰어드는 것이 장기적으로 의미 있다고 판단했습니다. 특히 자연어 처리 분야에서도 문법 분석보다 ‘상식’과 ‘맥락’을 이해하는 문제에 집중했습니다. 당시에는 상식 연구가 낮게 평가받기도 했지만, 언어를 진짜로 이해하려면 문법만으로는 부족합니다.

    문장이 맞아도 맥락을 모르면 의미를 놓칩니다. 사람은 말을 생략하고, 암시하고, 당연한 배경지식을 전제로 대화합니다. AI가 인간 언어를 제대로 이해하려면 이런 상식과 맥락을 다룰 수 있어야 합니다.

    대형 모델 경쟁만으로는 부족하다

    스케일링 법칙과 대형 모델 중심 경쟁을 설명하는 인터뷰 장면
    스케일링 법칙과 대형 모델 중심 경쟁을 설명하는 인터뷰 장면

    최 교수는 스케일링 자체를 부정하지 않습니다. 모델을 크게 만들고 데이터를 많이 넣으면 성능이 좋아지는 것은 사실입니다. 문제는 모두가 같은 방향으로만 달릴 때 생깁니다. 초대형 모델 경쟁은 막대한 자본과 GPU를 가진 기업과 국가에 유리합니다.

    그렇다면 자본이 상대적으로 작은 국가는 영원히 뒤처질까요? 최 교수는 그렇지 않다고 봅니다. 알고리즘, 데이터 품질, 학습 방식의 개선으로 더 작고 효율적인 모델을 만들 수 있기 때문입니다.

    그 근거로 그는 인간의 두뇌를 듭니다. 인간의 뇌는 LED 전구 하나보다 적은 전력을 쓰면서도 복합적 사고를 하고, 적은 데이터로도 많은 것을 배웁니다. 자연이 이미 효율적인 지능 시스템을 보여주고 있다면, AI 연구도 언젠가는 더 작은 자원으로 강력한 성능을 내는 방향을 찾을 수 있습니다.

    한국 AI 전략의 먼저 볼 부분은 GPU만이 아니다

    한국이 AI 경쟁에서 살아남기 위해 GPU를 확보하는 일은 더 봐야 합니다. 하지만 그것만으로는 충분하지 않습니다. 최예진 교수는 한국이 미국·중국과 같은 자본 규모로만 경쟁하기 어렵다면, 인재와 아이디어, 협력 문화에서 승부해야 한다고 말합니다.

    특히 인재 육성은 장기 전략으로 볼 수 있습니다. 중국 AI 생태계가 빠르게 성장한 배경에는 미국에서 공부하고 돌아간 연구자들이 수년간 학생을 길러낸 구조가 있습니다. 단기간의 장비 투자도 필요하지만, 더 멀리 보면 훌륭한 연구자와 엔지니어를 계속 배출하는 시스템이 더 봐야 합니다.

    또 하나의 조건은 협력 문화입니다. 조직 내부 정치와 중복 경쟁은 시간과 자원의 낭비입니다. 같은 문제를 각자 따로 풀기보다, 지식과 데이터를 공유하고 서로의 성과를 연결하는 방식이 해야 합니다. AI 경쟁은 개인 천재 한 명의 승부가 아니라 생태계의 승부에 가깝습니다.

    피지컬 AI는 한국이 노릴 수 있는 전략적 영역이다

    피지컬 AI와 제조 기반 전략을 설명하는 인터뷰 장면
    피지컬 AI와 제조 기반 전략을 설명하는 인터뷰 장면

    최 교수는 한국의 제조 기반 피지컬 AI 전략을 긍정적으로 봅니다. 피지컬 AI는 로봇, 제조, 물류, 현실 세계의 행동과 관련된 AI를 뜻합니다. 텍스트나 이미지처럼 인터넷에 풍부하게 쌓인 데이터와 달리, 제조 현장과 로봇 행동 데이터는 쉽게 구하기 어렵습니다.

    이 점이 오히려 기회입니다. 피지컬 AI는 자본만 투입한다고 빠르게 풀리는 문제가 아닙니다. 현장 지식, 숙련된 인력, 제조 데이터, 실제 문제를 이해하는 역량이 함께 해야 합니다. 한국은 제조업 기반과 현장 운영 경험이 강하기 때문에 이 영역에서 차별화할 수 있습니다.

    피지컬 AI가 발전하면 기존 제품을 자동화하는 데 그치지 않습니다. 이전에는 불가능하다고 여겼던 가전, 로봇, 산업 장비, 서비스가 새로 나올 수 있습니다. 이는 새로운 브랜드와 일자리로 이어질 가능성도 있습니다.

    관련 흐름은 이전에 정리한 AI 에이전트와 피지컬 AI 글과 함께 보면 더 입체적으로 이해할 수 있습니다.

    AI 민주화는 ‘사용 가능’보다 ‘제작 가능’에 가깝다

    AI 민주화의 의미를 설명하는 인터뷰 장면
    AI 민주화의 의미를 설명하는 인터뷰 장면

    많은 사람이 이미 ChatGPT 같은 AI 서비스를 쓰고 있습니다. 그래서 “AI는 이미 민주화된 것 아닌가?”라고 생각할 수 있습니다. 하지만 최예진 교수가 말하는 AI 민주화는 그냥 AI를 소비하는 상태와 다릅니다.

    그는 링컨의 민주주의 정의를 AI에 빗대어 설명합니다. 생성형 AI는 인간의 지식과 가치를 반영해야 하고, 인간이 만들 수 있어야 하며, 인간 전체에게 도움이 되어야 합니다. 즉 AI 민주화는 “누구나 쓸 수 있다”를 넘어 “다양한 나라와 조직이 만들고 개선하고 통제할 수 있다”에 가깝습니다.

    여기서 소형 언어 모델과 오픈소스가 더 봐야 합니다. 모든 조직이 초대형 모델을 만들 만큼의 GPU를 살 수는 없습니다. 하지만 소형 모델이 충분히 좋아지고, 학습 데이터와 훈련 방법이 공유된다면 더 많은 주체가 자기 목적에 맞는 AI를 만들 수 있습니다.

    오픈소스는 단순한 무료 공개가 아닙니다. 좋은 연구를 공개하면 전 세계 개발자와 연구자가 모이고, 인재 유입이 생기며, 생태계의 신뢰도 높아집니다. 중국의 일부 AI 기업들이 오픈소스를 통해 인재와 관심을 끌어모은 사례도 이 맥락에서 이해할 수 있습니다.

    소형 언어 모델은 어디서 강점을 가질까

    대형 언어 모델은 큰 신경망과 막대한 데이터, 대규모 자본을 바탕으로 만들어집니다. 반면 소형 언어 모델은 크기가 작기 때문에 부족한 부분을 다른 방식으로 채워야 합니다. 최 교수는 그 핵심을 데이터 품질에서 찾습니다.

    이미 인터넷 데이터는 대형 모델이 대부분 학습했습니다. 같은 데이터를 다시 많이 넣는다고 작은 모델이 큰 모델을 쉽게 따라잡기는 어렵습니다. 대신 인터넷에 없는 고품질 데이터, 특정 분야에 맞춘 데이터, 알고리즘으로 선별된 데이터가 더 봐야 합니다.

    소형 모델이 모든 면에서 초대형 모델을 이길 필요는 없습니다. 특정 업무나 기관, 산업 현장에서는 충분히 잘 작동하면서 비용이 훨씬 낮은 모델이 더 현실적인 선택일 수 있습니다. 예를 들어 내부 문서 검색, 고객 응대, 공공기관의 제한된 업무, 제조 현장의 특화 작업에서는 “가장 큰 모델”보다 “충분히 좋고 통제 가능한 모델”이 더 유리할 수 있습니다.

    로컬 LLM과 경량 서빙 흐름은 SGLang 로컬 LLM 서빙 엔진 글에서 다룬 흐름과도 연결됩니다.

    AI 시대 리더에게 필요한 능력

    AI 시대 리더십과 창의적 사고를 설명하는 인터뷰 장면
    AI 시대 리더십과 창의적 사고를 설명하는 인터뷰 장면

    AI가 많은 지식을 제공하는 시대에는 단순 암기형 전문성이 약해질 수 있습니다. 전문 지식을 많이 외우는 것만으로는 AI와 차별화되기 어렵습니다. 대신 먼저 볼 부분은 AI가 제시한 정보를 바탕으로 다음 질문을 만들고, 자기 관점으로 추론하며, 새로운 가치를 만드는 능력입니다.

    최예진 교수는 AI 시대의 리더에게 독창적 사고와 창의력이 필요하다고 말합니다. AI는 거대한 라이브러리처럼 지식을 꺼내 줄 수 있지만, 그 지식을 어디에 연결하고 무엇을 만들지는 사람이 결정해야 합니다.

    또 하나의 중요한 능력은 개별성입니다. 최 교수는 인간만이 가진 다양성과 고유한 특징을 AI가 쉽게 대체하기 어렵다고 봅니다. 모두가 같은 답을 빠르게 얻는 시대일수록, 각자가 가진 문제의식과 경험, 질문의 방향이 더 더 봐야 합니다.

    이 관점은 AI 시대 필수 역량AI 시대 인간의 가치를 다룬 글과도 함께 읽을 만합니다.

    개인과 조직을 위한 체크리스트

    이 인터뷰를 개인과 조직의 전략으로 바꾸면 다음 다섯 가지 질문이 남습니다.

    1. 우리는 AI를 그냥 사용하는가, 아니면 우리 문제에 맞게 만들고 개선할 역량을 갖추고 있는가?
    2. GPU와 모델 크기 외에 데이터 품질, 알고리즘, 업무 맥락을 어떻게 축적하고 있는가?
    3. 우리 산업의 현장 데이터는 무엇이며, 그것을 피지컬 AI나 특화 모델로 연결할 수 있는가?
    4. 내부 경쟁과 정치보다 협력과 공유가 잘 작동하는 구조를 만들고 있는가?
    5. 구성원들이 AI 답변을 소비하는 데 그치지 않고, 스스로 질문하고 추론하는 훈련을 하고 있는가?

    이 질문에 답하지 못하면 AI 도입은 도구 사용에 머물 수 있습니다. 반대로 이 질문을 조직적으로 다루면 AI는 비용 절감 도구를 넘어 새로운 제품, 서비스, 학습 방식으로 확장될 수 있습니다.

    결론: 한국 AI의 승부처는 ‘크기’가 아니라 ‘방향’이다

    AI 경쟁에서 큰 모델과 많은 GPU는 분명 더 봐야 합니다. 하지만 그것이 전부라면 승자는 이미 정해져 있을지도 모릅니다. 최예진 교수의 메시지는 여기서 출발합니다. 모두가 같은 방향으로 달릴 때, 다른 질문을 던지는 것이 더 큰 기회가 될 수 있습니다.

    한국은 제조 현장, 인재, 빠른 실행력, 협력 구조를 묶어 피지컬 AI와 특화 모델에서 강점을 만들 수 있습니다. 개인은 AI를 잘 쓰는 사람을 넘어, AI와 함께 더 좋은 질문을 만드는 사람이 되어야 합니다.

    결국 AI 민주화의 먼저 볼 부분은 더 많은 사람이 버튼을 누르는 것이 아닙니다. 더 많은 사람과 조직이 AI를 이해하고, 만들고, 통제하며, 인간에게 도움이 되는 방향으로 발전시키는 것입니다.

    FAQ

    AI 민주화란 무엇인가요?

    AI 민주화는 그냥 많은 사람이 AI 서비스를 쓰는 상태를 뜻하지 않습니다. 다양한 나라, 조직, 개인이 AI를 만들고 개선하고 통제할 수 있으며, 그 혜택이 특정 기업이나 국가에만 집중되지 않는 상태에 가깝습니다.

    소형 언어 모델은 대형 언어 모델을 대체할 수 있나요?

    모든 영역에서 완전히 대체하기는 어렵습니다. 주의할 점은 특정 업무, 특정 산업, 제한된 예산의 조직에서는 충분히 좋은 성능과 낮은 비용, 높은 통제 가능성을 제공할 수 있습니다.

    한국이 AI 경쟁에서 노릴 수 있는 분야는 무엇인가요?

    영상에서 강조된 분야는 피지컬 AI입니다. 제조, 로봇, 물류, 현실 세계의 행동 데이터가 필요한 영역은 인터넷 데이터만으로 해결하기 어렵기 때문에 한국의 제조 역량이 강점이 될 수 있습니다.

    AI 시대 개인에게 가장 중요한 역량은 무엇인가요?

    AI가 제공한 지식을 그대로 받아들이는 능력보다, 스스로 질문하고 추론하며 새로운 관점을 만드는 능력이 더 봐야 합니다. 최예진 교수는 독창적 사고와 창의력을 핵심 역량으로 강조합니다.

    참고자료

  • Hermes Agent Deliverable Mode: AI 산출물을 채팅에서 바로 받는 방법

    Hermes Agent Deliverable Mode: AI 산출물을 채팅에서 바로 받는 방법

    AI 에이전트를 업무에 써 보면 금방 이런 불편을 만납니다. 답변은 채팅창에 잘 나오는데, 실제로 필요한 결과물은 파일입니다. 보고서 PDF, 엑셀 표, 회의 요약 문서, 차트 이미지, 발표 자료처럼 말입니다. 사용자가 파일 경로를 복사하고, 서버에 접속하고, 다시 다운로드해야 한다면 자동화의 장점이 줄어듭니다.

    AI 에이전트 산출물이 채팅 화면으로 전달되는 워크플로우 이미지
    AI 에이전트가 문서, 이미지, 코드 등 산출물을 채팅으로 전달하는 과정을 시각화한 이미지

    Read in English: This article is also available in English for global readers.

    Hermes Agent의 Deliverable Mode는 이 문제를 해결하는 기능입니다. AI가 만든 산출물을 채팅방 안에서 바로 첨부파일로 받을 수 있게 해 줍니다. Slack, Discord, Telegram, WhatsApp, Signal 같은 메시징 환경에서 특히 유용합니다.

    Deliverable Mode란 무엇인가

    Deliverable Mode는 Hermes Agent가 생성한 파일을 사용자가 있는 채팅방으로 직접 보내는 방식입니다. 공식 문서에서는 이를 “Artifacts in Chat”, 즉 채팅 안의 산출물이라고 설명합니다.

    예를 들어 AI에게 “이번 달 매출 데이터를 차트로 만들어 보내 줘”라고 요청했다고 가정해 보겠습니다. 일반적인 자동화라면 AI가 sales-chart.png 같은 임시 파일명를 알려줄 수 있습니다. 사용자는 그 경로를 찾아 파일을 직접 열어야 합니다.

    Deliverable Mode에서는 다릅니다. Hermes Agent가 차트 이미지를 만들고 응답에 파일 경로를 언급하면, 메시징 게이트웨이가 그 경로를 감지합니다. 그리고 화면에는 복잡한 경로를 보여주지 않고, 실제 이미지를 채팅방에 첨부합니다. 사용자는 평소 메신저에서 사진이나 문서를 받듯이 결과물을 확인하면 됩니다.

    초보자를 위한 핵심 개념 세 가지

    Deliverable Mode를 이해하려면 세 가지 개념만 알면 됩니다.

    1. 산출물은 “AI가 만든 파일”이다

    여기서 산출물은 단순 텍스트 답변이 아닙니다. AI가 도구를 사용해 만든 실제 파일입니다. 예를 들면 이렇게 볼 수 있습니다.

    • 매출 추이를 보여주는 PNG 차트
    • 분석 결과를 정리한 PDF 보고서
    • 원자료를 정리한 CSV 또는 XLSX 파일
    • 회의 내용을 요약한 Markdown 문서
    • 발표용 PPTX 파일
    • 음성 안내용 MP3 파일

    Claude의 Artifacts 기능도 비슷한 문제의식에서 출발합니다. 아이디어를 앱, 시각화, 문서 같은 독립 콘텐츠로 만들고 별도 공간에서 다룰 수 있게 합니다. Hermes Agent의 Deliverable Mode는 여기에 “메신저 첨부파일 전달”이라는 실무 흐름을 더한 형태로 이해하면 쉽습니다.

    2. 게이트웨이는 “메신저와 AI 사이의 배달원”이다

    Hermes Agent는 CLI에서도 쓸 수 있지만, Telegram이나 Slack 같은 메신저에서도 사용할 수 있습니다. 이때 중간에서 메시지를 주고받는 구성요소가 게이트웨이입니다.

    게이트웨이는 AI의 응답을 읽고, 그 안에 지원되는 파일 경로가 있는지 확인합니다. report.pdf 또는 result.png 같은 파일명 예시가 여기에 해당합니다. 조건에 맞는 파일이면 게이트웨이가 해당 파일을 채팅방에 업로드합니다.

    중요한 점은 코드 예시는 보호된다는 것입니다. 공식 문서에 따르면 코드 블록이나 인라인 코드 안의 경로는 무시됩니다. 그래서 설명용 코드가 실수로 첨부파일 처리되는 일을 줄일 수 있습니다.

    3. 플랫폼별로 파일 표시 방식이 다르다

    이미지는 보통 채팅창 안에 바로 보입니다. 동영상도 플랫폼이 지원하면 인라인으로 표시됩니다. 오디오는 음성 또는 오디오 첨부로 전달됩니다. PDF, 워드, 엑셀, CSV, ZIP 같은 파일은 다운로드 가능한 첨부파일로 올라갑니다.

    Slack 개발 문서에서도 파일은 단순 메시지보다 더 복잡한 정보를 담는 메시지의 확장 형태로 설명됩니다. Telegram Bot API 역시 문서, 사진, 오디오 등 파일 유형별 전송 메서드를 제공합니다. Deliverable Mode는 이런 플랫폼의 파일 전송 능력을 Hermes Agent의 작업 결과와 연결해 주는 기능입니다.

    어떤 파일을 보낼 수 있나

    공식 문서 기준으로 Deliverable Mode는 다음 파일 유형을 지원합니다.

    유형확장자 예시전달 방식
    이미지.png, .jpg, .jpeg, .gif, .webp, .bmp, .tiff, .svg인라인 이미지
    동영상.mp4, .mov, .avi, .mkv, .webm인라인 또는 첨부
    오디오.mp3, .wav, .ogg, .m4a, .flac음성/오디오 첨부
    문서.pdf, .docx, .doc, .odt, .rtf, .txt, .md파일 첨부
    데이터.xlsx, .xls, .csv, .tsv, .json, .xml, .yaml, .yml파일 첨부
    발표자료.pptx, .ppt, .odp파일 첨부
    압축파일.zip, .tar, .gz, .tgz, .bz2, .7z파일 첨부
    웹 문서.html, .htm파일 첨부

    반대로 .py, .log 같은 소스 코드나 로그 파일은 의도적으로 제외됩니다. AI가 실수로 내부 코드나 로그를 자동 전송하지 않게 하기 위한 안전장치로 볼 수 있습니다. 코드를 보내야 한다면 파일 경로가 아니라 코드 블록으로 전달하는 편이 안전합니다.

    실제로 어떻게 작동하나

    작동 과정은 생각보다 단순합니다.

    1. Hermes Agent가 도구를 사용해 파일을 생성합니다. 2. 응답 문장 안에 생성된 파일의 절대 경로를 plain text로 언급합니다. 3. 게이트웨이가 그 경로와 확장자를 스캔합니다. 4. 지원되는 파일이면 경로 문구를 사용자 화면에서 제거합니다. 5. 해당 파일을 Slack, Telegram, Discord 같은 플랫폼의 기본 첨부파일로 업로드합니다.

    이 구조의 장점은 사용자가 별도 명령을 몰라도 된다는 점입니다. AI가 파일을 만들고 경로를 응답에 포함하기만 하면 됩니다. 공식 문서도 별도의 MEDIA: 태그를 쓰지 않아도 된다고 설명합니다.

    언제 특히 유용한가

    Deliverable Mode는 “답변”보다 “결과물”이 중요한 업무에서 빛을 발합니다.

    데이터 분석 결과 공유

    팀장이 Telegram에서 “지난주 판매 데이터를 정리해서 차트와 엑셀로 보내 줘”라고 요청할 수 있습니다. Hermes Agent는 Python으로 차트를 만들고, CSV나 XLSX 파일을 생성한 뒤, 채팅방에 이미지와 스프레드시트를 바로 보낼 수 있습니다.

    보고서 자동 생성

    주간 업무 보고, 서버 점검 결과, SEO 감사 결과처럼 일정한 형식의 문서를 PDF로 만들 수 있습니다. 사용자는 채팅방에서 바로 다운로드해 공유하면 됩니다.

    발표자료와 문서 초안 전달

    PowerPoint 스킬이나 문서 생성 도구와 연결하면 PPTX, DOCX, Markdown 초안을 받을 수 있습니다. 특히 모바일에서 지시하고 PC에서 파일을 내려받아 이어 작업하는 흐름에 잘 맞습니다.

    백그라운드 작업 완료 알림

    Hermes의 Kanban 멀티 에이전트 워크플로에서도 산출물이 완료 알림과 함께 전달될 수 있습니다. 작업자가 차트와 보고서를 만들고 kanban_complete 호출에 파일 경로를 포함하면, 완료 메시지와 산출물이 같은 채팅방에 도착합니다.

    설정할 때 기억할 점

    Deliverable Mode는 AI가 자동으로 항상 파일을 만들도록 강제하는 기능은 아닙니다. AI에게 산출물을 만들도록 요청해야 합니다.

    예를 들면 다음처럼 지시할 수 있습니다.

    • “결과를 표로 정리하고 CSV 파일도 함께 보내 줘.”
    • “분석 내용을 PDF 보고서로 만들어 Telegram에 첨부해 줘.”
    • “비교 결과를 차트 이미지로 렌더링해서 보내 줘.”
    • “회의록을 Markdown 파일로 저장하고 첨부해 줘.”

    프로젝트 단위로 자주 쓰려면 AGENTS.md, CLAUDE.md, .cursorrules 같은 프로젝트 지침에 “메시징 플랫폼에서는 가능한 경우 차트, 표, 보고서를 파일 산출물로 제공하라”는 식의 규칙을 넣을 수 있습니다. 전역 지침을 쓰는 경우에는 Hermes 설정의 agent.custom_instructions에 반영할 수도 있습니다.

    MCP와 함께 쓰면 확장성이 커진다

    공식 문서는 Deliverable Mode와 함께 MCP도 언급합니다. MCP는 Model Context Protocol의 약자입니다. 쉽게 말하면 AI 앱이 외부 도구와 데이터를 연결하기 위한 표준 인터페이스입니다.

    예를 들어 Notion, GitHub, Linear, Slack, Gmail, Salesforce, BigQuery, Google Drive 같은 서비스와 연결할 수 있습니다. Deliverable Mode가 “완성된 파일을 사용자에게 전달하는 출구”라면, MCP는 “작업에 필요한 데이터와 서비스에 접근하는 입구”에 가깝습니다.

    두 기능을 함께 쓰면 흐름이 자연스러워집니다. AI가 Google Drive에서 자료를 찾고, BigQuery에서 데이터를 조회하고, Python으로 차트를 만들고, 최종 보고서를 Slack에 첨부하는 식입니다.

    보안과 실무 주의사항

    파일을 자동으로 보내는 기능은 편리하지만, 몇 가지 주의점이 있습니다.

    첫째, 민감한 파일 경로를 응답에 노출하지 않도록 해야 합니다. 게이트웨이가 경로를 제거해 첨부파일로 바꾸더라도, 파일 이름과 내용은 사용자에게 전달됩니다. 고객 정보, API 키, 내부 로그가 포함된 파일은 만들지 않는 것이 기본입니다.

    둘째, 소스 코드나 로그 파일이 기본 지원 대상에서 제외된 이유를 이해해야 합니다. 모든 파일을 자동 전송하면 편리해 보이지만, 실수로 민감한 개발 자료가 전달될 수 있습니다. 필요한 경우에는 의도적으로 안전한 문서 형식으로 정리해서 보내는 편이 좋습니다.

    셋째, 파일이 실제로 존재해야 합니다. Kanban 완료 알림의 경우 파일이 디스크에 없으면 조용히 건너뛰어진다고 공식 문서가 설명합니다. 자동화 워크플로를 만들 때는 파일 생성 위치와 권한을 체크해 두세요.

    초보자를 위한 활용 체크리스트

    Deliverable Mode를 처음 쓴다면 아래 순서로 점검하면 됩니다.

    1. Hermes Agent를 메신저 게이트웨이에서 사용하고 있는가? 2. AI에게 텍스트 답변이 아니라 파일 산출물을 명시적으로 요청했는가? 3. 생성할 파일 형식이 지원 확장자 목록에 있는가? 4. 파일 경로가 코드 블록 안이 아니라 일반 응답 문장에 들어가는가? 5. 파일 내용에 개인정보, API 키, 내부 로그가 섞이지 않았는가? 6. Slack, Telegram, Discord 등 사용하는 플랫폼이 해당 파일 유형 업로드를 지원하는가? 7. 반복 업무라면 프로젝트 지침이나 커스텀 인스트럭션에 산출물 선호를 적었는가?

    기존 AI 도구의 Artifacts와 무엇이 다른가

    Claude Artifacts는 독립적인 콘텐츠를 별도 창에서 보고 수정하는 경험에 가깝습니다. 앱, 문서, 시각화, 코드 결과물을 대화 옆에서 다루게 해 줍니다.

    Hermes Agent의 Deliverable Mode는 채팅 기반 운영에 더 가깝습니다. 파일을 만든 뒤 사용자가 실제로 일하는 Slack, Telegram, Discord 스레드에 첨부합니다. 그래서 “AI와 같이 편집한다”보다 “AI가 작업을 끝내고 결과물을 납품한다”는 표현이 더 잘 맞습니다.

    Perplexity Computer의 Slack 통합도 비슷한 사용자 경험을 제공합니다. Hermes Agent 공식 문서는 차트, PDF, 슬라이드 같은 결과물을 Slack 스레드에 첨부하는 패턴을 비교 대상으로 설명합니다. 차이는 Hermes Agent가 사용자의 로컬 가상환경이나 샌드박스에서 파일을 만들고, 토큰은 사용자의 환경에 보관한다는 점입니다.

    정리: Deliverable Mode는 AI 자동화의 마지막 1미터를 줄인다

    AI 자동화에서 중요한 것은 답을 생성하는 능력만이 아닙니다. 사람이 실제로 사용할 수 있는 형태로 결과물을 전달하는 능력도 더 봐야 합니다. Deliverable Mode는 이 마지막 단계를 줄여 줍니다.

    차트는 이미지로, 보고서는 PDF로, 데이터는 엑셀이나 CSV로, 발표자료는 PPTX로 채팅방에 바로 도착합니다. 사용자는 서버 경로나 임시 폴더를 몰라도 됩니다. 업무 지시는 채팅으로 하고, 결과물도 채팅에서 받는 구조가 됩니다.

    AI 에이전트를 개인 비서나 업무 자동화 도구로 쓰고 싶다면 Deliverable Mode를 꼭 이해해 두는 것이 좋습니다. 특히 Slack, Telegram, Discord를 업무 허브로 쓰는 팀이라면 작은 자동화부터 적용해 볼 만합니다.

    함께 읽으면 좋은 글

    FAQ

    Deliverable Mode를 쓰려면 코딩을 알아야 하나요?

    기본 사용에는 코딩 지식이 많이 필요하지 않습니다. “차트 이미지로 보내 줘”, “PDF 보고서로 만들어 줘”처럼 원하는 산출물을 명확히 요청하면 됩니다. 주의할 점은 반복 자동화를 만들거나 특정 파일 형식을 고정하려면 프로젝트 지침을 다루는 정도의 이해가 도움이 됩니다.

    모든 채팅 플랫폼에서 똑같이 보이나요?

    아닙니다. Slack, Telegram, Discord, WhatsApp, Signal은 파일 업로드와 미리보기 방식이 다릅니다. Hermes Agent는 파일 유형에 맞춰 첨부를 시도하지만, 실제 표시 방식은 플랫폼 기능에 따라 달라질 수 있습니다.

    파일 경로가 사용자에게 그대로 보이나요?

    공식 문서 기준으로 게이트웨이는 지원되는 파일 경로를 감지한 뒤 visible message에서 제거하고 파일을 업로드합니다. 그래서 사용자는 보통 경로 대신 첨부파일을 보게 됩니다. 단, 코드 블록이나 인라인 코드 안의 경로는 무시됩니다.

    .py.log 파일은 자동 첨부 대상이 아닌가요?

    소스 코드와 로그에는 민감한 정보가 들어갈 수 있습니다. Hermes Agent는 이런 파일이 의도치 않게 전송되는 위험을 줄이기 위해 일부 확장자를 제외합니다. 코드는 코드 블록으로 공유하고, 로그는 필요한 부분만 정리한 문서로 만드는 편이 안전합니다.

    MCP와 Deliverable Mode는 같은 기능인가요?

    아닙니다. MCP는 AI가 외부 서비스와 데이터를 연결하는 표준에 가깝습니다. Deliverable Mode는 만들어진 파일을 채팅방에 전달하는 기능입니다. 함께 쓰면 외부 데이터 수집부터 최종 파일 전달까지 하나의 자동화 흐름으로 만들 수 있습니다.

    참고자료

  • AI 도구를 하나로 묶는 Agent OS 구축법: 7단계 블루프린트

    AI 도구를 하나로 묶는 Agent OS 구축법: 7단계 블루프린트

    AI 도구를 많이 쓰는데도 생산성이 크게 오르지 않는다면, 문제는 모델 성능이 아닐 수 있습니다. ChatGPT, Claude, Gemini, Hermes, Codex 같은 도구를 각각 열어 쓰면서 매번 같은 맥락을 설명하고, 결과물은 폴더와 채팅창 사이에 흩어지기 때문입니다.

    Julian Goldie의 영상 How to Build Your Own Agent Operating System은 이 문제를 “AI 문제가 아니라 시스템 문제”로 봅니다. 먼저 볼 부분은 개별 도구를 더 많이 구독하는 것이 아니라, AI 에이전트가 공통 메모리와 작업공간을 공유하는 개인용 Agent OS를 만드는 것입니다.

    여러 AI 에이전트를 한 화면에서 관리하는 Mission Control 예시
    여러 AI 에이전트를 한 화면에서 관리하는 Mission Control 예시

    Read in English: This article is also available in English for global readers.

    Agent OS란 무엇인가?

    Agent OS는 여러 AI 도구를 하나의 작업 운영체제처럼 묶는 구조입니다. 여기서 운영체제라는 말은 Windows나 macOS 같은 전통적 OS를 뜻하기보다, AI가 일하는 데 필요한 공통 기반을 뜻합니다.

    예를 들면 다음 요소가 한 시스템 안에 들어갑니다.

    • 사용자의 목표, 브랜드 보이스, 프로젝트 정보를 저장하는 메모리
    • 여러 모델과 에이전트를 호출하는 실행 계층
    • 작업 현황과 결과물을 볼 수 있는 대시보드
    • 블로그, 이미지, 영상, 리서치 등 실제 결과물을 만드는 생산 공간
    • 결과물을 다시 메모리에 저장하는 피드백 루프

    이 구조가 없으면 AI 도구를 많이 써도 매번 새 채팅에서 다시 시작합니다. 반대로 Agent OS가 있으면 에이전트가 이전 작업과 저장된 지식을 읽고 다음 작업에 이어 붙일 수 있습니다.

    왜 개별 AI 도구만으로는 부족한가?

    영상의 첫 문제 제기는 명확합니다. 많은 사용자가 10개 안팎의 AI 도구를 오가지만, 정작 결과물은 잃어버리고 컨텍스트는 반복 입력합니다. 좋은 모델을 쓰고 있어도 작업 시스템이 없으면 사용자가 병목이 됩니다.

    개별 도구 중심의 방식에는 네 가지 한계가 있습니다.

    • 도구마다 기록과 결과물이 분리됩니다.
    • 새 채팅을 열 때마다 프로젝트 설명을 반복해야 합니다.
    • 이미지, 글, 코드, 요약 파일이 한곳에 모이지 않습니다.
    • 새로운 AI 도구가 나올 때마다 워크플로가 다시 흔들립니다.

    그래서 영상은 “AI를 기존의 망가진 워크플로에 붙이면 더 복잡해진다”고 설명합니다. 먼저 작업 시스템을 만들고, 그 안에 AI 도구를 끼워 넣어야 한다는 뜻입니다.

    관련해서 AI 에이전트가 실제 업무 방식에 미치는 변화는 AI 에이전트와 피지컬 AI, 이제 ‘행동하는 AI’가 온다에서도 함께 볼 수 있습니다.

    Agent OS의 7개 레이어

    영상은 Agent OS를 일곱 개 레이어로 설명합니다. 아래에서 위로 쌓는 구조이며, 앞단을 건너뛰면 뒤의 자동화가 불안정해집니다.

    Agent OS의 7단계 구조: Foundation부터 Loop까지
    Agent OS의 7단계 구조: Foundation부터 Loop까지

    1. Foundation: 하드웨어와 기본 환경

    첫 레이어는 노트북, 운영체제, 로컬 작업공간입니다. 영상은 고급 장비가 필수는 아니라고 말합니다. 먼저 볼 부분은 AI 결과물이 저장되고 실행될 안정적인 기본 환경입니다.

    2. Memory: 장기 기억 저장소

    두 번째 레이어가 가장 더 봐야 합니다. Obsidian 같은 로컬 Markdown 기반 도구를 AI의 Second Brain으로 쓰면, 여러 에이전트가 같은 지식 저장소를 읽고 업데이트할 수 있습니다.

    Agent OS의 핵심인 Obsidian 기반 메모리 레이어
    Agent OS의 핵심인 Obsidian 기반 메모리 레이어

    한 가지 조심할 점은 Obsidian은 “완전한 오픈소스”라기보다 개인 사용자가 무료로 시작할 수 있는 로컬 Markdown 노트 도구로 이해하는 편이 안전합니다. 여러 에이전트가 같은 vault를 수정할 때는 파일 충돌과 동기화 규칙도 해야 합니다.

    3. Brain: 모델 라우팅 계층

    Brain 레이어는 Grok, Gemini, Claude, OpenRouter 같은 모델을 상황에 맞게 고르는 계층입니다. 영상은 모델을 엔진에 비유합니다. 엔진이 좋아도 차체와 운전 시스템이 없으면 성능을 제대로 쓰기 어렵다는 뜻입니다.

    4. Agents: 실제 작업자

    Agents 레이어는 Hermes, Claude Code, Codex 같은 실행형 에이전트를 배치하는 부분입니다. 단순 챗봇이 아니라 파일을 읽고, 코드를 수정하고, 문서를 만들고, 작업 결과를 저장하는 단위입니다.

    이 흐름은 하네스 엔지니어링이 온다: AI 에이전트를 제대로 일하게 만드는 법과도 연결됩니다. 에이전트의 성능은 프롬프트만이 아니라 실행 환경, 검증 루프, 작업 지시 구조에 의해 결정됩니다.

    5. Command Center: 통합 대시보드

    Command Center는 여러 CLI, 에이전트, 결과물을 한 화면에서 관리하는 미션 컨트롤입니다. 영상에서는 Next.js 기반 대시보드 예시를 보여주며, 작업 결과물을 미리 보고 검색할 수 있는 구조를 강조합니다.

    6. Production Services: 실제 생산 공간

    여섯 번째 레이어는 SEO 글쓰기, 이미지 생성, 영상 제작, Kanban, NotebookLM 요약처럼 실제 결과물이 만들어지는 서비스 영역입니다. 블로거라면 키워드 리서치, 초안 작성, 이미지 정리, 발행 기록까지 이 레이어에 넣을 수 있습니다.

    SEO 콘텐츠 제작을 Agent OS 안에서 처리하는 예시
    SEO 콘텐츠 제작을 Agent OS 안에서 처리하는 예시

    7. Loop: 결과를 다시 기억으로 돌려보내기

    마지막 레이어는 피드백 루프입니다. AI가 만든 글, 코드, 이미지, 요약, 발행 기록을 다시 메모리에 저장해야 다음 작업이 더 똑똑해집니다. 단발성 프롬프트가 아니라 누적되는 작업 시스템이 되는 지점입니다.

    Agent OS 구축에서 피해야 할 5가지 실수

    영상은 여러 번의 실패 끝에 얻은 교훈을 소개합니다. 실무적으로는 다음 다섯 가지를 조심하면 됩니다.

    1. AI를 시스템이 아니라 도구로만 보는 것

    ChatGPT, Claude, Gemini 중 무엇이 더 좋은지만 비교하면 구조가 남지 않습니다. 먼저 “내 작업은 어디에 저장되고, 누가 읽고, 어떤 기준으로 검증되는가”를 정해야 합니다.

    2. 무료 구조를 검토하기 전에 구독부터 늘리는 것

    유료 도구가 필요할 수는 있습니다. 하지만 메모리, 파일 정리, 대시보드, 자동화 규칙 없이 구독만 늘리면 비용과 복잡도만 증가합니다.

    3. 앱 내부 메모리에만 의존하는 것

    각 AI 서비스의 메모리는 편리하지만, 다른 에이전트가 공유하기 어렵습니다. 브랜드 보이스, 고객 정보, 프로젝트 목표처럼 반복 사용되는 정보는 별도 지식 저장소에 두는 편이 안정적입니다.

    4. 모든 자동화를 n8n이나 Zapier로만 만들려는 것

    n8n과 Zapier는 API 연결과 정형 자동화에 강합니다. 한 가지 조심할 점은 모든 것을 webhook과 OAuth 흐름으로 엮으면 유지보수 부담이 커질 수 있습니다. Agent OS는 에이전트가 같은 작업공간 안에서 직접 파일을 읽고 쓰는 구조를 더 강조합니다.

    5. 생성물을 랜덤 폴더에 방치하는 것

    AI가 만든 앱, 이미지, 영상, 블로그 초안이 흩어지면 재사용할 수 없습니다. 결과물에는 반드시 “집”이 있어야 합니다.

    AI가 만든 앱, 이미지, 영상 등을 다시 찾을 수 있는 작업공간
    AI가 만든 앱, 이미지, 영상 등을 다시 찾을 수 있는 작업공간

    블로거와 SEO 실무자는 어떻게 적용할 수 있나?

    Agent OS의 가치는 개발자에게만 있지 않습니다. 블로그와 SEO 운영에서는 오히려 더 직접적입니다.

    먼저 키워드 리서치 결과, 발행 URL, 타깃 독자, 내부 링크 후보, 성과 메모를 Obsidian이나 LLM Wiki 같은 저장소에 누적합니다. 다음 글을 쓸 때 AI가 이 정보를 읽으면 주제 중복을 줄이고 내부 링크를 더 정확하게 제안할 수 있습니다.

    두 번째로 글 작성 과정을 서비스화합니다. 예를 들어 “유튜브 자막 아카이브 → 대표 프레임 캡처 → SEO 초안 → WordPress 업로드 → Yoast 검증 → 28일 후 성과 점검”을 하나의 반복 가능한 파이프라인으로 만들 수 있습니다.

    세 번째로 발행 후 결과를 다시 저장합니다. 어떤 제목이 클릭을 만들었는지, 어떤 FAQ가 검색 유입에 도움이 됐는지, 어떤 내부 링크가 효과적이었는지를 남겨야 다음 글의 품질이 올라갑니다.

    AI 기반 콘텐츠 제작의 개발 방식 변화는 에이전틱 엔지니어링: 안드레이 카파시가 말한 바이브 코딩 이후의 개발 방식과 함께 보면 이해가 쉽습니다. Obsidian을 자동화 허브로 쓰는 사례는 Antigravity CLI Obsidian 자동화 글도 참고할 만합니다.

    개인용 Agent OS 시작 체크리스트

    처음부터 거대한 대시보드를 만들 필요는 없습니다. 작은 루프부터 시작하는 것이 안전합니다.

    • 현재 쓰는 AI 도구 목록을 적습니다.
    • 반복 작업을 세 가지로 줄입니다. 예: 블로그 작성, 리서치 요약, 이미지 정리.
    • 공통 메모리 저장소를 하나 정합니다.
    • 프로젝트 목표, 독자, 브랜드 톤, 자주 쓰는 프롬프트를 문서화합니다.
    • 결과물 폴더 규칙을 정합니다.
    • AI 에이전트가 읽어도 되는 파일과 안 되는 파일을 구분합니다.
    • 작업이 끝날 때마다 요약과 산출물 링크를 메모리에 남깁니다.
    • 자동화는 한 번에 하나씩 붙입니다.

    가장 먼저 만들 것은 “완전 자동화”가 아니라 “잃어버리지 않는 작업 시스템”입니다. 기억하고, 찾고, 이어서 할 수 있는 구조가 생긴 뒤에 자동화의 효과가 커집니다.

    주의할 점: Agent OS가 만능은 아니다

    영상에는 유료 커뮤니티와 교육 프로그램 소개도 포함되어 있습니다. 그래서 “주말 안에 누구나 완성한다”거나 “모델이 10배 유용해진다”는 식의 표현은 화자의 주장으로 이해해야 합니다.

    또한 화면과 음성을 기록하는 도구를 메모리 레이어에 연결할 때는 개인정보와 보안 이슈를 먼저 체크해 두세요. 회사 자료, 고객 정보, 미공개 기획이 AI 메모리에 들어간다면 접근 권한과 저장 위치를 명확히 정해야 합니다.

    Agent OS의 먼저 볼 부분은 도구를 많이 붙이는 것이 아닙니다. 어떤 정보를 기억할지, 어떤 작업을 자동화할지, 어떤 결과를 다시 학습 자산으로 남길지 정하는 운영 원칙입니다.

    FAQ

    Agent OS는 개발자만 만들 수 있나요?

    개발자가 아니어도 작은 형태로 시작할 수 있습니다. 한 가지 조심할 점은 터미널, 로컬 파일, API, Markdown 기반 노트에 대한 기본 이해가 있으면 훨씬 수월합니다.

    Agent OS 구축에 꼭 유료 AI 도구가 필요한가요?

    반드시 그렇지는 않습니다. 영상도 무료 도구를 먼저 검토하라고 강조합니다. Obsidian, 무료 모델, 오픈소스 에이전트, 로컬 폴더 규칙만으로도 기본 구조를 만들 수 있습니다.

    Obsidian을 메모리 레이어로 쓰는 이유는 무엇인가요?

    Obsidian은 로컬 Markdown 파일을 기반으로 하기 때문에 사람이 읽기 쉽고, 여러 에이전트가 파일 단위로 접근하기 쉽습니다. AI가 이전 작업과 프로젝트 맥락을 다시 읽게 만드는 데 유리합니다.

    n8n 자동화와 Agent OS는 어떻게 다른가요?

    n8n은 도구와 API를 연결하는 자동화 플랫폼에 가깝습니다. Agent OS는 메모리, 에이전트, 대시보드, 결과물 저장, 피드백 루프를 하나의 작업 시스템으로 묶는 개념입니다. 둘은 경쟁 관계라기보다 역할이 다릅니다.

    여러 AI 에이전트가 같은 메모리를 공유해도 되나요?

    가능하지만 규칙이 해야 합니다. 같은 vault나 작업 폴더를 동시에 수정하면 충돌이 생길 수 있습니다. 쓰기 권한, 파일명 규칙, 백업, 동기화 방식을 먼저 정해야 합니다.

    마무리

    AI 생산성을 높이는 다음 단계는 더 많은 도구를 구독하는 것이 아닙니다. 흩어진 도구를 하나의 메모리와 작업공간, 검증 루프로 묶는 것입니다.

    Agent OS는 거창한 개발 프로젝트로 시작하지 않아도 됩니다. 먼저 반복 작업 하나를 고르고, 그 작업의 입력·메모리·결과물·피드백을 한 폴더와 한 규칙으로 묶어 보세요. 그 작은 루프가 개인용 AI 운영체제의 출발점입니다.

    참고자료

  • AI 시대 필수 역량, 데미스 하사비스 인터뷰로 정리한 공부의 방향

    AI 시대 필수 역량, 데미스 하사비스 인터뷰로 정리한 공부의 방향

    알파고 이후 10년, 인공지능은 바둑판을 넘어 과학 연구와 일상 업무 속으로 들어왔다. Google DeepMind의 데미스 하사비스는 조승연의 탐구생활 인터뷰에서 알파고, 알파폴드, Gemini, AI 시대 교육에 대해 이야기했다. 먼저 볼 부분은 분명하다. AI 시대의 경쟁력은 그냥 도구 이름을 많이 아는 것이 아니라, 좋은 질문을 만들고 문제를 나누며 AI를 제대로 부리는 능력이다.

    데미스 하사비스 인터뷰 도입 장면

    이 글은 해당 인터뷰를 바탕으로 “AI 시대에 무엇을 배워야 하는가”라는 질문에 맞춰 핵심 내용을 정리한 글이다. 영상은 Google의 지원을 받아 제작된 콘텐츠이며, 아래 정리는 영어 자동자막과 영상 맥락을 바탕으로 작성했다.

    알파고의 의미는 ‘바둑 승리’보다 컸다

    알파고가 이세돌 9단과의 대국에서 승리했을 때 많은 사람은 “AI가 인간을 이겼다”는 장면에 주목했다. 하지만 하사비스가 강조하는 지점은 조금 다르다. 알파고의 진짜 의미는 사람이 모든 정답을 입력한 프로그램이 아니라는 점에 있습니다. 스스로 학습한 시스템이 복잡한 문제를 풀 수 있음을 보여줬습니다.

    바둑은 경우의 수가 매우 많고 직관, 패턴 인식, 장기 전략이 모두 필요한 게임이다. 체스보다 훨씬 열린 공간에서 판단해야 하므로 오랫동안 AI 연구의 어려운 과제로 여겨졌다. 알파고는 그 난제를 강화학습과 딥러닝으로 돌파했다. 이 점에서 알파고는 오늘날 생성형 AI와 AI 에이전트 시대를 예고한 초기 사례로 볼 수 있다.

    알파고와 이세돌 대국을 회고하는 장면

    게임은 장난이 아니라 AI의 훈련장이었다

    딥마인드는 아타리 게임, 바둑, 스타크래프트 같은 게임을 AI 연구의 실험장으로 활용해 왔다. 게임은 규칙이 명확하고 결과를 측정하기 쉬우며, 현실보다 안전하게 실패를 반복할 수 있다. 그래서 AI가 학습, 추론, 전략 수립을 연습하기 좋은 환경이다.

    특히 스타크래프트는 바둑과 다른 종류의 지능을 요구한다. 바둑은 모든 정보가 공개된 완전정보 게임이지만, 스타크래프트는 상대의 상황을 완전히 알 수 없는 불완전정보 게임이다. 자원 관리, 유닛 조합, 장기 전략, 다중 의사결정이 필요하다. 현실의 업무와 경영도 이와 비슷하다. 모든 정보가 주어지지 않은 상태에서 판단하고, 여러 선택지를 조율해야 한다.

    이 흐름을 보면 “AI가 게임을 잘한다”는 말은 가벼운 이야기가 아니다. 게임은 현실 문제를 풀기 전, AI가 복잡한 의사결정을 배우는 훈련장이었다.

    알파폴드는 AI가 과학의 도구가 될 수 있음을 보여줬다

    하사비스가 말한 또 하나의 중요한 사례는 알파폴드다. 알파폴드는 단백질의 3차원 구조를 예측하는 AI 시스템이다. 단백질 구조를 알면 그 단백질이 어떤 기능을 하는지 이해할 수 있습니다. 질병과 어떤 관련이 있는지, 신약 개발에서 어디를 공략해야 하는지 파악하는 데도 도움이 됩니다.

    과거에는 단백질 하나의 구조를 밝히는 데 매우 오랜 시간이 걸렸다. 그런데 알파폴드는 방대한 단백질 구조 예측을 가능하게 했고, 그 결과는 연구자들에게 공개됐다. 즉 AI는 그냥 글을 쓰거나 이미지를 만드는 도구를 넘어섰습니다. 과학자가 더 빠르게 가설을 세우고 실험 방향을 잡도록 돕는 도구가 되고 있습니다.

    알파폴드와 과학 응용을 설명하는 장면

    이 지점은 AI 시대 교육에도 중요한 힌트를 준다. 앞으로 중요한 사람은 AI 결과물을 그대로 받아쓰는 사람이 아닙니다. AI가 제시한 가능성을 해석하고 검증하며 다음 질문으로 이어갈 수 있는 사람입니다.

    AI 시대에도 수학과 과학은 여전히 중요하다

    AI가 계산하고 요약하고 코드를 짜주는 시대라면, 수학과 과학을 덜 배워도 될까? 하사비스의 답은 반대에 가깝다. AI 도구가 강력해질수록, 그 도구가 무엇을 하고 있는지 이해할 수 있는 기초 지식이 더 중요해진다.

    수학과 과학은 단순 암기 과목이 아니다. 세상을 모델로 바라보고, 가설을 세우고, 증거로 확인하는 사고방식의 훈련이다. AI가 답을 빠르게 제시해도, 그 답이 맞는지 판단하려면 원리를 이해해야 한다. 학생에게 필요한 관점은 “AI가 대신해주니 공부하지 않아도 된다”가 아닙니다. “AI를 더 잘 쓰기 위해 기본 원리를 배운다”는 관점입니다.

    아이들은 AI를 ‘공부’만 하지 말고 직접 써봐야 한다

    하사비스는 1980~90년대 개인용 컴퓨터를 가지고 놀던 세대가 디지털 시대를 이끌었다는 점을 떠올리게 한다. 당시 아이들은 컴퓨터를 교과서로만 배우지 않았다. 직접 만지고, 코드를 써보고, 게임을 만들고, 시행착오를 겪었다. 오늘날 AI도 비슷하다.

    AI 시대 교육과 직접 사용 경험을 이야기하는 장면

    아이들이 AI를 제대로 배우려면 그냥 “프롬프트 작성법”을 외우는 데서 멈추면 안 된다. 글쓰기, 발표 준비, 과학 탐구부터 AI를 직접 적용해 봐야 합니다. 웹사이트 제작, 앱 기획, 데이터 분석처럼 자신이 관심 있는 문제에도 연결해 볼 수 있습니다. 그 과정에서 AI가 잘하는 일과 못하는 일, 질문을 바꿨을 때 결과가 어떻게 달라지는지 체감하게 된다.

    부모와 교사에게 필요한 질문도 바뀐다. “AI를 쓰면 안 된다”가 아니라 “어떤 문제에, 어떤 방식으로, 어느 정도까지 AI를 쓰게 할 것인가”를 설계해야 한다.

    앞으로 중요한 능력은 ‘CEO처럼 생각하는 능력’이다

    인터뷰에서 가장 실용적인 메시지는 AI 에이전트 시대의 역량이다. 하사비스는 앞으로 한 사람이 여러 AI 에이전트를 활용하게 될 가능성을 말한다. 어떤 에이전트는 자료를 조사하고, 어떤 에이전트는 아이디어를 정리하고, 어떤 에이전트는 코드를 작성하고, 또 다른 에이전트는 결과를 검토할 수 있다.

    이때 사람의 역할은 줄어드는 것이 아니라 바뀐다. 모든 일을 직접 하는 사람이 아니라, 큰 문제를 작은 단위로 나누고 적절한 AI에게 맡기며 결과를 판단하는 사람이 중요해진다. 말하자면 작은 조직의 CEO처럼 생각하는 능력이다.

    AI 에이전트 활용과 질문력을 설명하는 장면

    여기서 먼저 볼 부분은 질문력이다. 좋은 질문은 그냥 문장을 예쁘게 쓰는 기술이 아니다. 무엇이 중요한 문제인지 정하고, 어떤 정보가 필요하며, 어떤 기준으로 결과를 평가할지 정하는 능력이다. 그래서 AI 시대의 공부는 암기량 경쟁보다 문제 정의 능력으로 이동한다.

    AI 시대 필수 역량 체크리스트

    AI 시대를 준비하는 학생, 부모, 직장인이라면 다음 다섯 가지를 점검해 볼 필요가 있다.

    1. STEM 기초: 수학, 과학, 컴퓨팅의 기본 원리를 이해하고 있는가?
    2. AI 도구 사용 경험: ChatGPT, Gemini 같은 도구를 실제 프로젝트에 써봤는가?
    3. 질문력: 막연한 호기심을 구체적인 질문과 과제로 바꿀 수 있는가?
    4. 문제 분해 능력: 큰 목표를 작은 작업 단위로 나눌 수 있는가?
    5. 검증 능력: AI가 낸 결과를 사실, 논리, 목적 기준으로 확인할 수 있는가?

    이 다섯 가지는 서로 연결된다. 기초 지식이 있어야 AI 답변을 검증할 수 있습니다. 질문력이 있어야 AI를 단순 검색 도구가 아니라 사고 파트너로 활용할 수 있습니다. 문제를 잘 나눌 수 있어야 여러 AI 에이전트를 조율할 수 있다.

    함께 읽어볼 글

    FAQ

    AI 시대에는 수학과 과학을 덜 배워도 되나요?

    아닙니다. AI가 계산과 요약을 도와주더라도, 결과가 맞는지 판단하고 더 좋은 질문을 하려면 수학과 과학의 기본 원리가 해야 합니다. 기초 지식은 AI를 대체하는 것이 아니라 AI를 더 잘 쓰게 만드는 기반입니다.

    아이에게 가장 먼저 가르쳐야 할 AI 역량은 무엇인가요?

    도구 이름보다 먼저 문제를 구체화하는 습관이 더 봐야 합니다. “무엇을 알고 싶은가”, “어떤 결과물이 필요한가”, “어떤 기준으로 좋은 답을 판단할 것인가”를 생각하게 해야 합니다. 그다음 AI 도구를 직접 사용해 작은 프로젝트를 만들어 보는 경험이 해야 합니다.

    AI 에이전트 시대에는 어떤 사람이 유리할까요?

    여러 작업을 작은 단위로 나누고, 적절한 AI 도구에 맡기고, 결과를 검토할 수 있는 사람이 유리합니다. 그냥 프롬프트를 잘 쓰는 사람보다 문제를 정의하고 작업을 조직하는 사람이 더 큰 가치를 만들 가능성이 높습니다.

    알파고와 알파폴드는 왜 함께 이야기되나요?

    알파고는 학습 기반 AI가 복잡한 전략 문제를 해결할 수 있음을 보여줬습니다. 알파폴드는 그런 AI 접근이 과학 문제에도 적용될 수 있음을 보여줬습니다. 두 사례 모두 AI가 단순 자동화를 넘어 발견과 연구의 도구가 될 수 있다는 점을 보입니다.

    직장인은 지금 무엇부터 시작하면 좋을까요?

    자신의 업무 중 반복되는 조사, 정리, 초안 작성, 비교 분석 작업을 하나 고른 뒤 AI 도구로 처리해 보세요. 먼저 볼 부분은 한 번 써보는 데서 끝내지 않고, 질문을 바꾸고 결과를 검토하며 자신만의 작업 흐름을 만드는 것입니다.

    결론: AI 시대의 공부는 문제 정의로 이동한다

    데미스 하사비스의 인터뷰를 교육과 역량 관점에서 보면 메시지는 명확하다. AI 시대에도 기초 지식은 중요하다. 하지만 지식을 많이 외우는 것만으로는 충분하지 않다. 앞으로 더 중요한 것은 좋은 질문을 만들고, 문제를 나누고, AI가 낸 결과를 검증하며, 여러 도구를 조율하는 능력이다.

    AI를 두려워하거나 무작정 따라가는 태도만으로는 부족하다. 직접 써보고, 실패해 보고, 자신의 문제에 적용해 보는 사람이 AI 시대의 감각을 더 빨리 익힌다. 결국 AI 시대의 핵심 공부는 “정답을 외우는 공부”에서 “문제를 정의하는 공부”로 이동하고 있다.

    참고자료

  • AI 에이전트와 피지컬 AI, 이제 ‘행동하는 AI’가 온다

    AI 에이전트와 피지컬 AI, 이제 ‘행동하는 AI’가 온다

    AI가 빨라졌다는 말은 이제 너무 익숙합니다. 하지만 최근 변화의 먼저 볼 부분은 “더 똑똑한 답변을 한다”가 아닙니다. AI가 스마트폰, 노트북, 로봇, 안경, 주방 기계, 콘텐츠 편집 도구 안으로 들어가 실제 행동을 대신하기 시작했다는 점입니다.

    와이스트릿 영상에서 김은석 작가는 이 변화를 여러 사례로 설명합니다. Figure 휴머노이드, 구글 AI 에이전트, 중국 영상 AI, 로봇 마라톤이 대표 사례입니다. AI 의료 보조, Canva 매직 레이어, 스마트 글래스도 함께 다룹니다. 여러 사례가 흩어져 보이지만, 한 문장으로 정리하면 이렇습니다.

    AI는 이제 ‘말하는 도구’에서 ‘상황을 보고, 판단하고, 실행하는 도구’로 이동하고 있습니다.

    이 변화는 개인의 생산성뿐 아니라 일자리, 콘텐츠 제작, 교육, 자영업, 제조업까지 연결됩니다.

    AI 에이전트와 피지컬 AI 변화를 설명하는 와이스트릿 영상 도입 장면

    Read in English: This article is also available in English for global readers.

    출처: 와이스트릿 유튜브 화면 캡처. 원본 영상은 「AI 한 달 만에 또 말도 안 되는 발전 속도 벌써 현실이 됐습니다 / 김은석 작가 풀버전」입니다. 리뷰와 설명 목적으로 사용했습니다.

    AI 에이전트는 앱을 대신 열어 주는 비서가 된다

    영상에서 가장 먼저 눈에 띄는 흐름은 구글 AI 에이전트입니다. 예전에는 사용자가 직접 앱을 열고 검색하고 결제하고 일정을 등록해야 했습니다. 콘서트에 가려면 포스터를 보고, 검색창에 공연 정보를 찾고, 예매 사이트에 들어가 좌석을 고르고, 결제까지 해야 했습니다.

    하지만 구글이 보여 준 방향은 다릅니다. AI가 대화의 맥락을 이해합니다. 친구와 “이 콘서트 같이 갈래?”라고 이야기하면, AI가 공연 일정과 티켓 예매 가능성을 확인하고, 결제 단계까지 연결해 줍니다. 데이트 약속 중 “언제 도착해?”라는 메시지가 오면 지도와 현재 이동 상황을 연결해 예상 도착 시간을 제안합니다.

    구글 AI 에이전트와 개인 비서 기능을 설명하는 장면

    먼저 볼 부분은 AI가 그냥 질문에 답하는 것이 아니입니다. 사용자가 하려는 일을 추론하고, 필요한 앱과 서비스를 묶어 다음 행동을 제안합니다.

    이런 변화가 본격화되면 스마트폰 사용 방식도 달라집니다. 지금은 사람이 앱을 찾아 들어갑니다. 앞으로는 AI가 상황을 읽고 필요한 기능을 앞으로 가져올 가능성이 높습니다.

    비슷한 흐름은 이전에 정리한 AI agent 변화: OpenClaw가 보여주는 실행형 AI의 다음 단계에서도 확인할 수 있습니다. 챗봇이 답변하는 단계를 넘어 브라우저, 도구, 메모리, 보안까지 연결되는 실행형 AI 구조가 중요해지고 있습니다.

    피지컬 AI는 로봇을 ‘깡통 기계’에서 ‘판단하는 노동자’로 바꾼다

    영상 초반에 소개된 Figure 휴머노이드 사례는 피지컬 AI의 방향을 잘 보여 줍니다. 피지컬 AI는 말 그대로 물리적 세계에서 움직이는 AI입니다. 챗봇이 텍스트 안에서 답을 만든다면, 피지컬 AI는 로봇 몸을 통해 물건을 집고, 분류하고, 청소하고, 이동합니다.

    Figure 로봇은 택배 분류 작업을 수행합니다. 그냥 팔을 반복해서 움직이는 수준이 아니라, 송장의 방향과 물건의 위치를 인식하고 분류 작업을 이어 갑니다. 더 먼저 볼 부분은 교대 구조입니다. 한 로봇이 충전하러 가면 다른 로봇이 이어받아 24시간 운영될 수 있습니다.

    사람이 더 빠를 수 있는 순간은 있습니다. 하지만 장시간 반복 업무에서는 휴식, 식사, 피로, 교대 비용이 발생합니다. 로봇은 속도가 조금 느려도 지속 시간이 길어지면 효율성이 달라집니다.

    또 하나 중요한 점은 로봇 두뇌입니다. 영상에서는 Figure의 Helix, 구글 딥마인드가 결합된 보스턴다이내믹스 Spot 사례도 언급됩니다. 로봇이 문을 보고 “문이 열려 있다”는 상황을 이해하고, 계기판을 읽고, 화이트보드에 적힌 할 일을 수행하는 방향으로 볼 수 있습니다.

    이제 경쟁은 로봇의 팔과 다리만이 아닙니다. 하드웨어, 배터리, 센서, 로봇 두뇌, 부품 생태계가 함께 경쟁합니다.

    중국의 로봇·영상 AI 생태계는 속도로 압박한다

    영상 중반부에서는 중국 AI와 로봇 생태계가 여러 번 등장합니다. 비두의 영상 생성 모델, 바이트댄스 계열 영상 AI, 유니트리 로봇, 로봇 마라톤, 로봇 손 부품 시장 등이 사례입니다.

    중국 영상 생성 AI와 로봇 생태계 경쟁을 설명하는 장면

    여기서 주목할 점은 “중국 기술이 좋다”는 단순 평가가 아닙니다. 더 먼저 볼 부분은 속도와 생태계입니다. 영상에서는 로봇 마라톤에서 넘어지고 부서지는 장면까지 공개하는 문화가 언급됩니다. 실패를 숨기기보다 드러내고, 다음 버전에서 얼마나 개선됐는지 보여 주는 방식입니다.

    로봇 손 전문 기업만 수십 개가 있습니다. 관절·손·센서 같은 부품을 모듈처럼 조달할 수 있는 시장이 만들어지면 개발 속도는 빨라집니다. 휴머노이드 전체를 한 회사가 모두 만들지 않아도, 부품 생태계가 성장하면 조립과 커스터마이징이 쉬워집니다.

    한국 제조업에도 시사점이 있습니다. 완제품 로봇만 바라볼 필요는 없습니다. 로봇 손, 관절, 센서, 배터리, 정밀 가공, 산업용 소프트웨어처럼 특정 부품과 공정에서 기회가 생길 수 있습니다.

    콘텐츠 제작은 ‘기술자’보다 ‘아이디어를 가진 사람’에게 유리해진다

    영상 후반부는 콘텐츠와 디자인 도구의 변화를 다룹니다. AI가 영상 후킹을 예측하고, 영화 명장면에 새로운 인물을 합성하고, 김홍도 그림을 영상처럼 움직이게 만드는 사례가 나옵니다.

    과거에는 이런 작업에 촬영팀, 배우, 세트, CG, 편집 인력이 필요했습니다. 이제는 기존 영상과 몇 줄의 프롬프트만으로 비슷한 결과를 만들 수 있는 방향으로 가고 있습니다.

    그렇다고 인간의 역할이 사라지는 것은 아닙니다. 영상에서도 강조되듯 아직 먼저 볼 부분은 기획입니다. 어떤 장면을 고를지, 어떤 문화적 맥락을 붙일지, 무엇을 웃음 포인트로 만들지, 어떤 메시지를 전달할지는 여전히 사람의 판단이 해야 합니다.

    주의할 점은 실행 비용은 급격히 낮아집니다. 그래서 앞으로 콘텐츠 경쟁력은 “툴을 다룰 줄 아는가”보다 “어떤 관점과 아이디어를 갖고 있는가”로 더 이동할 가능성이 높습니다.

    이 지점은 AI 시대의 승자는 무엇을 준비할까?에서 다룬 변화 대응력과도 연결됩니다. 도구 자체보다 문제를 정의하고, 판단하고, 실행으로 옮기는 역량이 더 중요해지고 있습니다.

    의료·디자인·주방 업무에서도 AI는 보조자 역할을 넓힌다

    의료 영역에서는 AI 코클리니션이 소개됩니다. 여기서 중요한 표현은 ‘코(co)’입니다. 의사를 대체한다기보다 환자와 의사 사이에서 정보를 정리하는 보조자에 가깝습니다.

    의료와 디자인 영역으로 확장되는 AI 활용 사례 설명 장면

    환자는 병원에 가기 전 증상과 질문을 정리할 수 있고, 진료 후에는 의사의 설명을 다시 확인할 수 있습니다. 실제 의료 판단은 전문가가 하더라도, AI가 정보 정리와 기억 보조를 맡으면 환자의 이해도는 높아질 수 있습니다.

    디자인에서는 Canva의 매직 레이어 같은 기능이 언급됩니다. 복잡한 이미지에서 요소를 분리해 텍스트, 인물, 배경을 따로 편집할 수 있다면 비전문가도 디자인 수정이 쉬워집니다.

    주방 자동화도 흥미롭습니다. 웍질, 고기 굽기, 마이야르 반응처럼 숙련자의 감에 의존하던 부분이 데이터화되고 있습니다. 로봇이 표면 온도와 색을 보고 적절한 시점에 고기를 뒤집는다면, 일정한 맛을 반복 생산할 수 있습니다. 자영업자 입장에서는 인건비와 품질 균일성 측면에서 새로운 선택지가 생깁니다.

    스마트 글래스와 AI 시험 부정행위는 교육의 변화를 요구한다

    마지막 사례는 스마트 글래스입니다. 메타 스마트 글래스처럼 카메라와 AI가 결합된 장치는 사용자가 보는 것을 AI가 함께 인식하게 만듭니다. 음식 사진을 보고 칼로리를 추정하거나, 손동작을 인식해 입력을 보조하는 식입니다.

    스마트 글래스와 AI 글래스 활용 사례를 설명하는 장면

    하지만 중국에서 AI 글래스를 이용한 시험 부정행위 논란도 소개됩니다. 문제를 보면 AI가 답을 알려 줄 수 있는 환경에서는, 단순 암기형 시험의 신뢰성이 흔들립니다.

    이 문제는 “기술을 금지하자”만으로 해결하기 어렵습니다. 계산기, 인터넷, 검색, 챗GPT가 그랬듯 도구는 계속 들어옵니다. 그렇다면 교육은 암기 확인에서 토론, 발표, 적용, 구현, 비판적 사고 평가로 이동해야 합니다. AI를 못 쓰게 하는 시험과 AI를 잘 쓰게 하는 교육 사이에서 균형을 찾아야 합니다.

    지금 확인해야 할 세 가지 변화

    첫째, AI 에이전트는 앱 사용 방식을 바꿉니다. 검색·예약·결제·일정·지도 같은 기능이 대화 속에서 연결됩니다.

    둘째, 피지컬 AI는 로봇 산업을 다시 보게 만듭니다. 로봇은 더 이상 정해진 동작만 반복하는 장비가 아니라, 주변을 보고 판단하는 노동·돌봄·보조 인프라가 될 수 있습니다.

    셋째, AI 도구는 콘텐츠와 업무의 실행 비용을 낮춥니다. 하지만 그만큼 기획력, 윤리 기준, 교육 방식, 일자리 전환 논의가 더 더 봐야 합니다.

    관련해서 AI와 일의 미래는 일자리 대체보다 먼저 봐야 할 일의 의미와 커리어 전략을 다룹니다. 개발·업무 자동화 관점에서는 에이전틱 엔지니어링 글도 함께 보면 흐름을 이해하기 쉽습니다.

    마무리: 놀라움은 곧 일상이 된다

    영상의 마지막 메시지는 분명합니다. 지금은 놀라운 기술처럼 보이지만, 시간이 지나면 당연한 일상이 됩니다. 로봇 커피가 처음에는 신기했지만 이제는 크게 놀라지 않는 것처럼, AI 에이전트와 피지컬 AI도 비슷한 과정을 거칠 가능성이 높습니다.

    중요한 것은 모든 신기술을 무조건 따라가는 것이 아닙니다. 내 일과 생활에서 어떤 부분이 자동화될 수 있는지 미리 생각해야 합니다. 어떤 역량을 더 키워야 하는지, 어떤 윤리적 기준을 세워야 하는지도 함께 봐야 합니다.

    AI가 답을 잘하는 시대는 이미 시작됐습니다. 이제는 AI가 행동하는 시대를 준비해야 합니다.

    원본 영상은 와이스트릿에서 확인할 수 있습니다. 영상 링크: 김은석 작가 풀버전.

    FAQ

    AI 에이전트는 기존 챗봇과 무엇이 다른가요?

    챗봇은 주로 질문에 답합니다. AI 에이전트는 사용자의 의도를 파악하고 검색, 예약, 결제, 일정 등록처럼 여러 행동을 연결해 수행하거나 제안하는 방향으로 발전하고 있습니다.

    피지컬 AI란 무엇인가요?

    피지컬 AI는 물리적 세계에서 작동하는 AI를 말합니다. 로봇이 카메라와 센서로 주변을 인식하고, 물건을 집거나 이동하거나 작업을 수행하는 형태가 예로 들 수 있습니다.

    휴머노이드 로봇은 바로 일자리를 대체할까요?

    모든 일자리를 단기간에 대체한다고 보기는 어렵습니다. 주의할 점은 반복 작업, 위험 작업, 장시간 운영이 필요한 업무에서는 로봇 도입 압력이 커질 수 있습니다.

    AI 영상 제작 도구가 많아지면 사람 크리에이터의 역할은 줄어드나요?

    실행 비용은 줄어들지만 기획, 맥락, 취향, 편집 판단의 중요성은 더 커질 수 있습니다. 도구를 잘 쓰는 사람보다 좋은 아이디어를 빠르게 구현하는 사람이 유리해질 가능성이 높습니다.

    AI 글래스가 보급되면 교육은 어떻게 바뀌어야 하나요?

    단순 암기형 평가는 점점 취약해질 수 있습니다. 토론, 발표, 문제 해결 과정, 실제 구현, AI 도구 활용 능력을 함께 평가하는 방식으로 이동할 필요가 있습니다.

  • Claude 소상공인 Skill, 챗봇을 넘어 업무 자동화 도구가 되다

    Claude 소상공인 Skill, 챗봇을 넘어 업무 자동화 도구가 되다

    Claude가 그냥 질문에 답하는 도구에서 벗어나고 있습니다. Anthropic이 공개한 소상공인용 Small Business 플러그인은 그 변화를 꽤 선명하게 보입니다. 영상에서 소개된 31개 Skill은 회계, 이메일, 일정, 채용, 고객관리처럼 작은 조직이 매일 처리해야 하는 일을 하나의 실행 흐름으로 묶습니다.

    Claude 소상공인 Skill 플러그인 개요
    영상 캡처: Brock Mesarich | AI for Non Techies YouTube 영상, 소상공인용 Skill 플러그인 소개 장면.

    Claude 소상공인 Skill이 중요한 이유

    Claude 소상공인 Skill의 먼저 볼 부분은 “프롬프트를 잘 쓰는 법”이 아니라 “업무 절차를 저장해 반복 실행하는 법”입니다. 진행자 Brock Mesarich는 Skill을 이름, 설명, 세부 지시문이 들어 있는 워크플로우 패키지로 설명합니다. 사용자는 매번 긴 지시문을 다시 쓰지 않고, 정해 둔 Skill 이름만 불러 업무를 시작할 수 있습니다.

    이 구조는 소상공인에게 특히 더 봐야 합니다. 작은 조직은 회계 담당자, 영업 담당자, 채용 담당자가 분리되어 있지 않은 경우가 많습니다. 대표나 실무자가 QuickBooks, Stripe, Gmail, Slack, Google Calendar 같은 도구를 오가며 하루를 시작합니다. Claude Skill은 이 흩어진 확인 작업을 하나의 브리핑이나 문서 생성 흐름으로 압축합니다.

    Claude 소상공인 Skill - Claude Skill 구조 설명
    영상 캡처: Skill은 이름, 설명, 지시문으로 구성된 반복 업무 실행 단위로 설명됩니다.

    Business Pulse: 하루 업무를 한 장의 브리핑으로 묶다

    영상에서 가장 먼저 강조한 사례는 Business Pulse입니다. 이 Skill은 QuickBooks, Stripe, PayPal, Square, HubSpot, Google Calendar, Gmail, Slack, Microsoft Teams 같은 연결 앱에서 정보를 동시에 가져옵니다. 그리고 오늘의 일정, 이메일 우선순위, 현금 흐름, 매출 신호, 팀 커뮤니케이션 상황을 하나의 사업 현황 요약으로 바꿉니다.

    작은 조직의 아침 점검을 줄이는 방식

    소상공인 입장에서 이 기능은 단순한 요약보다 더 큽니다. 매일 아침 “입금은 되었나”, “오늘 미팅은 무엇인가”, “급한 고객 메일은 있는가”, “팀 메시지에서 놓친 건 없는가”를 따로 확인하는 시간을 줄일 수 있기 때문입니다. AI가 모든 결정을 대신한다기보다, 사람이 판단해야 할 우선순위를 먼저 정리해 주는 비서에 가깝습니다.

    Claude 소상공인 Skill - Business Pulse 실행 예시
    영상 캡처: 여러 업무 앱의 정보를 모아 사업 현황과 우선순위를 요약하는 Business Pulse 예시.

    Invoice Chase: 미수금 관리가 자동화되는 지점

    두 번째로 실용적인 예시는 Invoice Chase입니다. 이 Skill은 QuickBooks나 Stripe에서 연체 인보이스를 확인하고, 고객별 결제 이력과 미수금 상태를 정리합니다. 이후 Gmail에 독촉 메일 초안을 만들 수 있습니다.

    자동 메일보다 중요한 것은 데이터 연결

    여기서 중요한 점은 “AI가 메일 문구를 예쁘게 쓴다”가 아닙니다. 실제 결제 데이터와 고객 이력을 참고해 어떤 고객에게 어떤 톤으로 후속 조치를 할지 판단하도록 돕는다는 점입니다. 미수금은 작은 회사의 현금 흐름에 직접 영향을 주기 때문에, 이 흐름이 안정되면 운영 리스크를 줄이는 효과가 있습니다.

    Claude 소상공인 Skill - Invoice Chase 실행 예시
    영상 캡처: Stripe와 QuickBooks 데이터를 바탕으로 미수금과 후속 메일 초안을 정리하는 장면.

    Job Post Builder: 채용 업무도 패킷으로 만든다

    세 번째 사례는 Job Post Builder입니다. 사용자가 역할명, 근무 방식, 보상, 후보자 조건 같은 정보를 입력하면 Claude가 채용 공고, 인터뷰 가이드, 평가 루브릭, 제안서 또는 계약서 초안을 만들어 줍니다.

    채용 문서의 일관성을 확보하는 효과

    소규모 조직은 채용 공고와 면접 기준이 즉흥적으로 만들어지는 경우가 많습니다. Job Post Builder는 채용의 각 단계를 문서화해 팀원이 같은 기준으로 후보자를 볼 수 있게 합니다. 특히 인터뷰 가이드와 평가 루브릭은 단순한 문서 생성보다 의사결정 품질을 높이는 데 도움이 됩니다.

    앱 커넥터와 MCP가 만드는 실행형 AI

    영상 후반부는 커넥터 연결에 초점을 둡니다. Claude Co-work에서 Gmail, Slack, Notion, DocuSign, QuickBooks, Stripe 같은 앱을 연결하고, Zapier MCP를 통해 Claude가 직접 지원하지 않는 앱까지 확장하는 방식입니다.

    Claude 소상공인 Skill - 앱 커넥터 연결
    영상 캡처: Claude Co-work에서 커넥터와 Zapier MCP를 통해 외부 앱을 연결하는 흐름.

    이 장면은 AI 도입의 방향을 잘 보입니다. 앞으로의 AI는 “답변을 잘하는 챗봇”만으로 평가되지 않습니다. 어떤 앱에 접근할 수 있는지, 어떤 권한으로 자료를 읽고 쓸 수 있는지, 반복 업무를 얼마나 안전하게 실행할 수 있는지가 더 더 봐야 합니다.

    도입 전에 확인해야 할 보안과 권한 문제

    Claude 소상공인 Skill은 매력적이지만, 무작정 연결하면 안 됩니다. QuickBooks, Stripe, Gmail, Slack에는 재무 정보, 고객 정보, 계약 정보, 내부 대화가 들어 있습니다. Skill을 쓰기 전에는 연결 앱의 권한 범위, 자동 생성 문서의 승인 절차, 민감 정보 처리 기준을 먼저 정해야 합니다.

    사람의 검토를 남겨야 하는 업무

    특히 결제 독촉 메일, 계약서, 채용 제안서처럼 외부로 나가는 문서는 사람이 최종 체크해 두세요. AI가 초안을 만들고 데이터를 정리하는 것은 유용하지만, 법적 책임과 고객 관계는 여전히 사업자의 영역입니다.

    소상공인이 얻을 수 있는 실제 효과

    Claude 소상공인 Skill이 보여주는 가치는 세 가지입니다. 첫째, 반복 확인 업무를 줄입니다. 둘째, 흩어진 앱의 데이터를 하나의 업무 맥락으로 묶습니다. 셋째, 업무 매뉴얼을 Skill 형태로 저장해 같은 품질로 반복 실행할 수 있게 합니다.

    작은 회사에 필요한 것은 거대한 AI 프로젝트가 아닐 수 있습니다. 매일 아침 확인해야 하는 것, 매주 반복되는 청구와 채용 문서, 고객 응대 초안처럼 작지만 자주 발생하는 업무부터 Skill로 바꾸는 것이 현실적인 출발점입니다.

    FAQ

    Claude 소상공인 Skill은 무엇인가요?

    Claude 소상공인 Skill은 Claude Co-work에서 반복 업무를 실행하기 위한 업무 자동화 지시문 묶음입니다. 회계, 일정, 이메일, 채용, 고객관리 같은 앱과 연결하면 실제 업무 흐름을 더 빠르게 처리할 수 있습니다.

    일반 프롬프트와 Skill은 어떻게 다른가요?

    일반 프롬프트는 매번 사용자가 직접 지시를 작성해야 합니다. Skill은 이름, 설명, 실행 절차가 저장되어 있어 같은 업무를 반복적으로 호출할 수 있습니다.

    소상공인이 바로 도입해도 괜찮을까요?

    도입 자체는 가능하지만, 연결 앱의 권한 범위와 검토 절차를 먼저 정해야 합니다. 특히 결제, 계약, 채용, 고객 메일처럼 외부 이해관계자에게 영향을 주는 업무는 사람의 최종 확인이 해야 합니다.

    참고자료

    함께 읽으면 좋은 글

  • AI 스킬 만들기, 파일 3개로 시작하는 Claude·GPT 업무 자동화

    AI 스킬 만들기, 파일 3개로 시작하는 Claude·GPT 업무 자동화

    반복 업무를 AI에게 맡길 때마다 같은 설명을 다시 쓰고 있다면, 문제는 프롬프트 길이가 아니라 업무 구조일 수 있습니다. AI 스킬 만들기는 “좋은 문장 하나”를 찾는 일이 아니라, AI가 반복해서 꺼내 쓸 수 있는 업무 매뉴얼과 자료 묶음을 만드는 일에 가깝습니다.

    AI 스킬 만들기 핵심 질문: 프롬프트와 스킬은 무엇이 다른가
    출처: SURVIVAL AI 유튜브 영상 캡처. 프롬프트와 스킬의 차이를 설명하는 도입 장면입니다.

    AI 스킬 만들기는 프롬프트를 ‘업무 패키지’로 바꾸는 과정입니다

    영상의 핵심 비유는 명확합니다. 프로젝트 지시문은 레시피이고, 스킬은 밀키트입니다. 레시피만 있으면 요리 순서는 알 수 있지만 재료, 도구, 계량 기준은 따로 준비해야 합니다. 밀키트는 레시피와 재료, 필요한 도구와 기준이 한 묶음으로 들어 있습니다.

    AI 업무에서도 같은 차이가 생깁니다. 프로젝트 지시문은 특정 프로젝트 안에서 반복 지시를 적용하는 방식입니다. 반면 스킬은 대화창에서 해당 업무를 요청했을 때 AI가 알아서 관련 절차와 참고자료를 불러와 실행하도록 만드는 패키지입니다.

    프로젝트 지시문과 스킬의 차이

    프로젝트 지시문은 “이 프로젝트에서는 이렇게 일해”라는 텍스트 규칙에 가깝습니다. 회의록 정리 방식, 컨설팅 PPT 작성 방식, 보고서 구조를 프로젝트 안에 넣어두면 그 공간에서는 반복적으로 작동합니다.

    스킬은 범위가 다릅니다. 핵심 지시문뿐 아니라 참고자료, 템플릿, 검증 스크립트까지 함께 묶을 수 있습니다. 그래서 “이렇게 써라”가에 그치지 않고 “이 자료를 참고하고, 이 순서로 처리하고, 마지막에 이 기준으로 점검하라”까지 포함할 수 있습니다.

    AI 스킬 만들기 비유: 프로젝트 지시문은 레시피, 스킬은 밀키트
    프로젝트 지시문과 스킬의 차이를 레시피와 밀키트로 설명하는 장면입니다.

    왜 지금 AI 스킬이 중요해졌을까

    초기 AI는 질문 하나에 답 하나를 주는 챗봇에 가까웠습니다. 이메일 문장을 다듬거나 번역하거나 아이디어를 묻는 방식이 중심이었습니다.

    지금의 AI는 다릅니다. 여러 단계를 연결하고, 외부 시스템과 연동하고, 중간 판단을 하며, 사용자가 자리를 비운 동안에도 작업 흐름을 이어갈 수 있습니다. 이 변화 때문에 “질문을 예쁘게 쓰는 능력”만으로는 부족해졌습니다.

    프롬프트 엔지니어링의 역할도 바뀌었습니다

    AI의 언어 이해력이 좋아지면서 어설픈 표현도 어느 정도는 AI가 보정합니다. 하지만 좋은 결과가 자동으로 보장되는 것은 아닙니다. 먼저 볼 부분은 AI가 어떤 목표와 기준으로 판단해야 하는지 구조화하는 능력입니다.

    예를 들어 “이 주식 오를까?”라고 묻는 것과 “손실을 최소화하는 진입 전략을 세우고, 위험 신호와 분할 매수 기준을 제시하라”고 지시하는 것은 완전히 다른 결과를 만듭니다. 스킬은 이런 구조화된 판단 기준을 반복 가능한 형태로 저장하는 장치입니다.

    좋은 AI 스킬의 기본 구조

    영상에서 소개한 기본 구조는 단순합니다. 최상위 폴더 안에 핵심 파일인 SKILL.md가 있고, 필요에 따라 references/scripts/ 폴더를 둡니다. 파일이 3개 또는 3개 영역으로 정리된다는 설명은 바로 이 구조를 말합니다.

    AI 스킬 만들기 기본 구조: SKILL.md, references, scripts
    스킬 폴더와 핵심 파일 구조를 설명하는 장면입니다.

    SKILL.md는 스킬의 실행 설명서입니다

    SKILL.md는 스킬의 중심입니다. 언제 이 스킬을 써야 하는지, 어떤 순서로 작업해야 하는지, 어떤 결과물을 만들어야 하는지, 마지막에 무엇을 검증해야 하는지가 들어갑니다.

    이 파일 하나만 있어도 스킬은 작동할 수 있습니다. 주의할 점은 모든 내용을 한 파일에 몰아넣으면 AI가 중요한 지시를 놓칠 수 있습니다. 그래서 핵심 절차는 SKILL.md에 두고, 길고 세부적인 자료는 별도 폴더로 분리하는 것이 좋습니다.

    references는 필요할 때 꺼내 읽는 지식 창고입니다

    references/는 매번 읽을 필요는 없지만 특정 단계에서 참고해야 하는 문서를 보관하는 곳입니다. 예를 들어 도메인별 작성 패턴, 검토 기준, 예시 문서, 설치 가이드 등을 넣을 수 있습니다.

    먼저 볼 부분은 “필요할 때만 읽게 만드는 것”입니다. AI에게 항상 모든 자료를 읽게 하면 지시가 길어지고 집중도가 떨어질 수 있습니다. 반대로 필요한 순간에 정확한 참고자료를 열게 하면 결과의 일관성이 높아집니다.

    scripts는 반복 결과를 고정하는 자동화 도구입니다

    scripts/는 말로 지시하면 매번 달라지는 작업을 코드로 고정하는 영역입니다. 영상에서는 라면 끓이는 기계를 예로 듭니다. 사람이 말로만 지시하면 매번 조금씩 다르게 만들지만, 기계에 순서와 시간을 입력하면 결과가 일정해집니다.

    업무에서도 마찬가지입니다. PPT 색상과 위치, 파일 변환, 데이터 검증, 표준 포맷 검사처럼 결과가 일정해야 하는 작업은 스크립트로 고정하는 편이 좋습니다.

    스킬 생성기는 질문부터 시작해야 합니다

    좋은 스킬은 사용자의 요구를 먼저 확인합니다. AI가 성능이 좋아질수록 애매한 요청도 알아서 처리하려고 하지만, 업무 스킬은 오히려 단계별 확인이 더 봐야 합니다.

    영상의 예시인 스킬 생성기는 6단계 인터뷰로 시작합니다. 도메인을 확인하고, 세부 도메인을 분류하고, 고위험 영역인지 판단한 뒤, 스킬 이름과 설명, 워크플로우, 검토 기준을 차례로 정리합니다.

    AI 스킬 만들기 절차: 인터뷰 기반 스킬 생성 워크플로우
    스킬 생성기가 요구사항을 단계별로 확인하는 흐름을 설명하는 장면입니다.

    고위험 도메인은 사람 검토를 포함해야 합니다

    법무, 계약, 채용, 보안처럼 실수의 비용이 큰 영역은 AI가 그럴듯한 결과를 만들더라도 최종 검토가 해야 합니다. 좋은 스킬은 이런 위험을 숨기지 않습니다.

    오히려 “이 단계에서는 사람 검토가 필요하다”, “이 결과는 참고용이며 최종 판단은 담당자가 해야 한다”처럼 책임 경계를 명시해야 합니다. 그래야 스킬이 업무 효율을 높이면서도 위험을 키우지 않습니다.

    Claude와 GPT/Codex에서 스킬을 만드는 방법

    영상에서는 Claude와 GPT/Codex 양쪽의 실전 생성 방법도 소개합니다. Claude에서는 사용자 지정 메뉴의 스킬 영역에서 업로드하거나, Claude와 대화하며 스킬을 만들 수 있습니다. GPT/Codex에서는 스킬 및 앱 메뉴, 또는 스킬 크리에이터 흐름을 사용할 수 있습니다.

    Claude와 GPT Codex에서 AI 스킬 만들기 실전 메뉴
    Claude와 GPT/Codex에서 스킬을 생성하거나 업로드하는 방법을 안내하는 장면입니다.

    업로드보다 먼저 볼 부분은 검토입니다

    AI가 만들어 준 스킬이 보기에는 그럴듯해도, 그 분야를 전혀 모르면 좋은 스킬인지 판단하기 어렵습니다. 그래서 최소한 해당 업무의 기본 언어와 흐름은 알아야 합니다.

    좋은 방법은 이미 공개된 우수한 스킬이나 워크플로우를 참고하는 것입니다. GitHub나 공식 예시에서 비슷한 분야의 구조를 살펴보고, 내 업무에 맞게 변형하면 시행착오를 줄일 수 있습니다.

    AI 스킬 만들기 체크리스트

    점검 항목 확인 질문 실무 포인트
    목적 이 스킬이 해결할 반복 업무는 무엇인가? 한 문장으로 설명되지 않으면 범위가 넓을 수 있습니다.
    발동 조건 언제 이 스킬을 사용해야 하는가? “이런 요청이 오면 사용” 조건을 명확히 적습니다.
    입력 정보 사용자가 무엇을 제공해야 하는가? 누락 시 질문해야 할 항목을 정리합니다.
    실행 절차 어떤 순서로 처리해야 하는가? 단계별 워크플로우를 번호로 씁니다.
    참고자료 항상 필요한 자료와 가끔 필요한 자료는 무엇인가? 긴 자료는 references로 분리합니다.
    자동화 매번 같은 결과가 필요한 부분은 무엇인가? 변환·검증·생성은 scripts 후보입니다.
    검증 완료 전에 무엇을 확인해야 하는가? 결과물 품질 기준과 오류 대응을 넣습니다.
    위험 사람 검토가 필요한 영역은 어디인가? 법무·보안·채용·재무 등은 경고를 명시합니다.

    결론: 스킬은 AI 시대의 업무 자산입니다

    AI 스킬 만들기의 본질은 “내가 일하는 방식을 AI가 반복 실행할 수 있는 구조로 바꾸는 것”입니다. 남이 만든 스킬을 가져다 쓰는 것도 도움이 되지만, 직접 만들고 써 보고 고치면서 축적한 스킬은 쉽게 대체되지 않는 업무 자산이 됩니다.

    처음부터 완벽한 스킬을 만들 필요는 없습니다. 작은 반복 업무 하나를 고르고, SKILL.md로 핵심 절차를 정리하고, 필요한 자료를 references/로 분리하고, 반복 검증이 필요한 부분을 scripts/로 옮기면 됩니다. 먼저 볼 부분은 한 번에 끝내는 것이 아니라 실제 사용 후 수정하고 보완하는 반복입니다.

    FAQ

    AI 스킬 만들기와 프롬프트 작성은 무엇이 다른가요?

    프롬프트 작성은 한 번의 요청을 잘 쓰는 데 초점이 있습니다. AI 스킬 만들기는 반복 업무에 필요한 절차, 참고자료, 템플릿, 검증 기준을 묶어 AI가 계속 재사용하도록 만드는 데 초점이 있습니다.

    SKILL.md 하나만 있어도 스킬이 되나요?

    가능합니다. 주의할 점은 업무가 복잡해지면 참고자료와 스크립트를 분리하는 편이 좋습니다. 그래야 AI가 핵심 지시와 부가 자료를 구분하고 필요한 순간에만 추가 정보를 읽을 수 있습니다.

    AI가 만들어 준 스킬을 그대로 써도 되나요?

    간단한 개인 업무라면 바로 시험해 볼 수 있습니다. 하지만 법무, 보안, 채용, 재무처럼 위험이 큰 업무라면 반드시 사람 검토 단계를 넣어야 합니다. 또한 실제 사용 후 결과를 보며 계속 수정해야 합니다.

    어떤 업무부터 스킬로 만들면 좋을까요?

    반복 빈도가 높고 결과 형식이 비교적 일정한 업무가 좋습니다. 회의록 정리, 보고서 초안, 블로그 검수, 자료 변환, 체크리스트 기반 리뷰처럼 절차와 기준을 정의하기 쉬운 업무부터 시작하면 됩니다.

    참고자료

    함께 읽으면 좋은 글

  • 하네스 엔지니어링이 온다: AI 에이전트를 제대로 일하게 만드는 법

    하네스 엔지니어링이 온다: AI 에이전트를 제대로 일하게 만드는 법

    하네스 엔지니어링은 앞으로 AI 에이전트와 함께 일하는 사람에게 중요한 개념이 될 가능성이 높습니다. 지금까지 많은 사람은 “AI에게 어떻게 더 잘 말할 것인가”에 집중했습니다. 하지만 AI가 실제 코드를 만들고, 테스트하고, 수정하고, 보고하는 단계로 들어오면 질문이 달라집니다.

    이제 중요한 것은 “AI에게 무엇을 말할 것인가”만이 아닙니다. AI가 제대로 일할 수밖에 없는 환경을 어떻게 만들 것인가입니다.

    하네스 엔지니어링 도입부: 바이브 코딩에서 에이전틱 코딩으로
    출처: Jay Choi | 인디해커 라이프 유튜브 영상 캡처

    Read in English: This article is also available in English for global readers.

    이 글은 Jay Choi | 인디해커 라이프의 영상 「하네스 엔지니어링: 바이브 코딩에서 에이전틱 코딩으로」를 바탕으로, 바이브 코딩 이후 개발자가 어떤 방식으로 AI 에이전트를 다뤄야 하는지 정리한 글입니다. 관련 흐름은 이전 글 「에이전틱 엔지니어링: 안드레이 카파시가 말한 바이브 코딩 이후의 개발 방식」과 함께 읽으면 더 잘 연결됩니다.

    하네스 엔지니어링이란 무엇인가

    하네스 엔지니어링은 AI 모델이나 에이전트가 움직이는 작업 환경 전체를 설계하는 일입니다. 여기서 말하는 환경은 단순한 채팅창이 아닙니다. 프로젝트 폴더 구조, 규칙 문서, 테스트 명령, 도구 목록, MCP, 스킬, 훅, 리뷰 절차, 자동 검증 흐름까지 포함합니다.

    프롬프트 엔지니어링이 “모델에게 잘해 달라고 말하는 기술”에 가깝다면, 하네스 엔지니어링은 “모델이 잘할 수밖에 없는 구조를 만드는 기술”에 가깝습니다.

    부탁이 아니라 구조를 만드는 일

    AI에게 “테스트까지 확인해 줘”라고 말할 수는 있습니다. 하지만 에이전트가 실제로 테스트를 실행했는지, 실패를 어떻게 해석했는지, 결과를 기준에 맞게 보고했는지는 별개의 문제입니다.

    하네스 엔지니어링은 이 지점을 구조로 해결하려고 합니다. 예를 들면 이렇게 볼 수 있습니다.

    • 작업이 끝나면 반드시 테스트 명령을 실행하게 한다.
    • 변경된 파일과 테스트 결과를 보고 양식에 맞춰 남기게 한다.
    • 위험한 명령은 실행 전 확인 절차를 거치게 한다.
    • 너무 많은 도구를 주지 않고, 작업 목적에 맞는 도구만 제공한다.
    • 프로젝트 규칙을 문서화해 에이전트가 항상 읽을 수 있게 한다.

    이런 구조가 있으면 매번 사람이 프롬프트로 잔소리하지 않아도 됩니다. 에이전트가 그 환경 안에서 자연스럽게 올바른 절차를 따르게 됩니다.

    바이브 코딩은 바닥을 올리고, 하네스 엔지니어링은 천장을 올린다

    영상의 핵심 표현 중 하나는 “바이브 코딩은 바닥을 올리고, 에이전틱 엔지니어링은 천장을 올린다”는 말입니다.

    바이브 코딩은 개발 경험이 적은 사람도 앱을 만들 수 있게 해 주었습니다. 자연어로 요구사항을 말하면 AI가 코드를 제안하고, 화면을 만들고, 오류를 고쳐 줍니다. 이 변화는 분명히 진입 장벽을 낮췄습니다.

    하지만 진입 장벽이 낮아졌다고 해서 좋은 소프트웨어가 자동으로 만들어지는 것은 아닙니다. 실제 서비스에서는 보안, 결제, 예외 처리, 유지보수, 테스트, 배포, 사용자 경험이 모두 더 봐야 합니다.

    하네스 엔지니어링이 중요한 이유와 2026년 AI 에이전트 흐름
    출처: Jay Choi | 인디해커 라이프 유튜브 영상 캡처

    코드 생성보다 검증이 더 어려워진다

    AI가 코드를 빠르게 만드는 시대에는 “코드를 작성하는 능력”보다 “코드가 쓸 만한지 판단하는 능력”이 더 더 봐야 합니다. AI가 그럴듯한 코드를 만들 수는 있지만, 그 코드가 실제 요구사항을 만족하는지 확인하는 책임은 여전히 사람과 시스템에 남습니다.

    하네스 엔지니어링은 바로 이 검증 문제를 다룹니다. 에이전트가 작업을 완료했다고 말할 때, 그 말만 믿지 않고 실제 실행 결과와 테스트 결과를 확인하게 만드는 것입니다.

    프롬프트를 더 길게 쓰는 것으로는 부족하다

    많은 사용자는 AI 결과가 마음에 들지 않으면 프롬프트를 더 자세히 씁니다. 역할을 부여하고, 예시를 넣고, “실수하지 말라”고 지시합니다. 물론 이런 방식도 도움이 됩니다.

    하지만 매번 사람이 개입해야 한다면 한계가 있습니다. 같은 유형의 실수를 반복해서 고쳐야 하고, 작업이 길어질수록 맥락이 흐려지며, 에이전트가 실제로 무엇을 했는지 확인하기 어렵습니다.

    하네스 엔지니어링은 프롬프트보다 실행 환경을 설계하는 접근
    출처: Jay Choi | 인디해커 라이프 유튜브 영상 캡처

    좋은 프롬프트보다 좋은 작업장

    영상에서는 프로젝트 전체가 하나의 거대한 프롬프트가 된다고 설명합니다. 에이전트는 채팅창의 문장만 읽는 것이 아닙니다. 폴더 구조, 파일 이름, README, 규칙 문서, 기존 코드 스타일, 테스트 파일, 설정 파일을 모두 참고합니다.

    정리된 프로젝트에서는 에이전트도 정리된 방식으로 일할 가능성이 높습니다. 반대로 프로젝트가 어지럽고 규칙이 없으면, 에이전트도 어지러운 결과를 만들기 쉽습니다.

    그래서 하네스 엔지니어링의 첫걸음은 거창한 자동화가 아닐 수 있습니다. 오히려 프로젝트를 정리하고, 규칙을 문서화하고, 반복 작업을 스크립트로 만들고, 검증 절차를 명확히 하는 것에서 시작됩니다.

    도구는 많을수록 좋은 것이 아니다

    AI 에이전트에게 많은 도구를 연결하면 더 강력해 보입니다. 검색, 터미널, 브라우저, 파일 편집, 배포, 데이터베이스, 메신저까지 모두 붙이면 무엇이든 할 수 있을 것처럼 느껴집니다.

    하지만 실제로는 도구가 너무 많으면 에이전트가 어떤 도구를 써야 할지 판단하는 데 에너지를 씁니다. 사람도 선택지가 많을수록 결정을 미루듯, AI도 불필요한 선택지 앞에서 흔들릴 수 있습니다.

    하네스 엔지니어링에서 도구 선택과 검증 구조의 중요성
    출처: Jay Choi | 인디해커 라이프 유튜브 영상 캡처

    작업별로 좁고 정확한 도구를 준다

    좋은 하네스는 모든 도구를 한꺼번에 열어 주지 않습니다. 작업 목적에 맞춰 필요한 도구만 제공합니다.

    예를 들어 코드 리뷰 에이전트라면 파일 읽기, diff 확인, 테스트 로그 분석이 더 봐야 합니다. 반면 배포 권한이나 외부 메시지 전송 권한은 필요하지 않을 수 있습니다. 데이터 수집 에이전트라면 웹 검색과 저장 도구는 필요하지만, 운영 서버 명령 권한은 제한하는 편이 안전합니다.

    도구를 줄이는 것은 성능을 낮추는 일이 아닙니다. 오히려 에이전트가 더 빠르게 판단하고, 실수할 표면을 줄이며, 사람이 신뢰할 수 있는 결과를 만드는 방법입니다.

    하네스 엔지니어링의 실무 체크리스트

    개발자는 AI 팀 리더가 된다

    하네스 엔지니어링을 실제 업무에 적용하려면 다음 항목부터 점검해 볼 수 있습니다.

    점검 항목 질문 예시
    목표 정의 에이전트가 끝내야 할 작업이 명확한가? “로그인 오류 수정”보다 “재현 절차 확인 후 테스트 통과까지”
    도구 제한 이 작업에 꼭 필요한 도구만 열려 있는가? 코드 수정 에이전트에 배포 권한 제외
    규칙 문서 프로젝트 규칙을 에이전트가 읽을 수 있는가? README, AGENTS.md, CLAUDE.md, 테스트 가이드
    검증 루프 작업 후 자동으로 확인하는 절차가 있는가? lint, unit test, build, smoke test
    보고 형식 결과를 사람이 판단하기 쉽게 남기는가? 변경 파일, 실행 명령, 실패/성공 로그 요약
    인간 판단 AI가 결정하면 안 되는 영역이 분리되어 있는가? 결제 정책, 환불 기준, 보안 예외, UX 우선순위

    이 표에서 중요한 것은 자동화 자체가 아닙니다. AI에게 맡길 일과 사람이 판단할 일을 분리하는 것입니다.

    영상의 마지막 메시지는 강합니다. 생각은 AI에게 아웃소싱할 수 있지만, 이해는 아웃소싱할 수 없다는 것입니다.

    코드 작성, 분석, 리뷰 초안 작성은 AI가 점점 더 잘하게 됩니다. 하지만 왜 이 기능이 필요한지, 어떤 예외를 고려해야 하는지, 어떤 구조가 장기적으로 유지보수에 유리한지는 사람이 이해해야 합니다.

    하네스 엔지니어링 시대 개발자는 AI 팀 리더가 된다
    출처: Jay Choi | 인디해커 라이프 유튜브 영상 캡처

    직접 코딩하는 사람에서 작업 환경을 설계하는 사람으로

    앞으로 개발자의 역할은 “모든 코드를 직접 치는 사람”에서 “AI 에이전트 팀이 제대로 일하도록 환경을 만드는 사람”으로 이동할 가능성이 높습니다.

    이 변화는 개발자에게만 해당하지 않습니다. 기획자, 창업자, PM, 데이터 분석가도 마찬가지입니다. AI에게 일을 맡기려면 작업 기준, 검증 방법, 보고 방식, 권한 범위를 설계해야 합니다.

    결국 하네스 엔지니어링은 AI 시대의 협업 설계입니다. AI가 잘하는 실행은 AI에게 맡기되, 사람이 이해하고 책임져야 할 부분은 구조 안에 남겨 두는 방식입니다.

    결론: AI에게 “해줘”라고 말하는 시대의 다음 단계

    바이브 코딩은 많은 사람에게 만들기의 문을 열었습니다. 하지만 실제 결과물을 안정적으로 운영하려면 다음 단계가 해야 합니다. 그 단계가 하네스 엔지니어링입니다.

    좋은 하네스는 에이전트에게 자유를 주되, 방향과 경계를 함께 제공합니다. 필요한 도구만 주고, 프로젝트 규칙을 읽게 하며, 작업 후에는 테스트와 리뷰를 통과하게 만듭니다. 사람은 모든 중간 과정을 붙잡는 대신 최종 판단과 중요한 설계에 집중합니다.

    AI에게 “해줘”라고 말하는 것만으로는 충분하지 않습니다. 이제는 AI가 제대로 해낼 수 있는 환경을 설계해야 합니다. 하네스 엔지니어링은 바로 그 환경을 만드는 일입니다.

    참고자료

  • SGLang 로컬 LLM 서빙 엔진, Ollama·vLLM 다음 선택지가 될까?

    SGLang 로컬 LLM 서빙 엔진, Ollama·vLLM 다음 선택지가 될까?

    로컬 LLM 서빙 엔진을 고를 때 이제 선택지는 Ollama와 vLLM만이 아닙니다. 괴발자 채널의 영상 「Ollama 보다 빠르다는 vLLM을 뛰어넘었습니다! 로컬 LLM 서빙 엔진 SGLang 소개」는 SGLang이 왜 주목받는지, 그리고 어떤 상황에서 검토할 만한지 쉽게 보입니다.

    SGLang 로컬 LLM 서빙 엔진 프로젝트 소개
    출처: 괴발자 YouTube 영상 캡처. SGLang 로컬 LLM 서빙 엔진 소개 장면입니다.

    SGLang 로컬 LLM 서빙 엔진이 주목받는 이유

    영상의 출발점은 간단합니다. vLLM이 Ollama보다 빠르다고 알려졌지만, SGLang은 특정 조건에서 vLLM보다 더 높은 처리량과 낮은 지연시간을 목표로 합니다.

    단순 실행 도구가 아니라 서비스용 엔진에 가깝다

    Ollama는 로컬에서 모델을 빠르게 실행하고 테스트하기에 편합니다. 반면 SGLang과 vLLM은 여러 요청을 동시에 처리하는 서빙 상황을 더 강하게 의식합니다. 그래서 개인 실험보다 기업 내부 챗봇, RAG, AI 에이전트, API 서비스처럼 동시 요청이 생기는 환경에서 차이가 커집니다.

    생태계 신호도 무시하기 어렵다

    영상은 SGLang이 LMSYS 팀에서 시작했고, Grok, NVIDIA 지원, 글로벌 기업 채택 사례와 연결된다고 설명합니다. 오픈소스 LLM 인프라에서는 성능뿐 아니라 생태계 신뢰가 더 봐야 합니다. 문서, GPU 지원, 운영 사례가 늘어날수록 실무 도입 장벽이 낮아지기 때문입니다.

    핵심 원리: RadixAttention은 무엇을 줄이나

    SGLang을 이해할 때 가장 중요한 키워드는 RadixAttention입니다. 영상에서는 여러 요청이 완전히 달라 보이더라도 앞부분의 시스템 프롬프트나 공통 지시문은 반복되는 경우가 많다고 설명합니다.

    공통 프롬프트를 다시 계산하지 않는다

    예를 들어 기업 챗봇은 매 요청마다 “당신은 회사 내부 문서를 바탕으로 답변하는 AI입니다” 같은 시스템 지시문을 붙일 수 있습니다. 사용자의 질문은 달라도 앞부분은 같습니다. RadixAttention은 이런 공통 접두부를 재사용해 불필요한 계산을 줄이는 방식으로 이해하면 쉽습니다.

    SGLang 로컬 LLM 서빙 엔진 병렬 처리 설명
    출처: 괴발자 YouTube 영상 캡처. SGLang의 병렬 처리 맥락을 설명하는 장면입니다.

    RAG와 에이전트 서비스에서 의미가 커진다

    RAG 서비스나 AI 에이전트는 공통 지시문, 도구 사용 규칙, 출력 형식이 반복되는 경우가 많습니다. 이때 같은 문맥을 계속 계산하면 GPU 시간과 응답 지연이 늘어납니다. SGLang은 이런 반복 구조가 많은 서비스에서 장점을 낼 가능성이 높습니다.

    Ollama·vLLM·SGLang 비교 결과를 어떻게 볼까

    영상에서는 같은 모델을 기준으로 Ollama, vLLM, SGLang을 비교합니다. 결과만 보면 SGLang이 가장 빠르고, vLLM이 그다음이며, Ollama는 상대적으로 느리게 나타납니다.

    숫자는 강하지만 조건을 함께 봐야 한다

    성능 비교는 항상 환경 의존적입니다. GPU 종류, 모델 크기, 동시 요청 수, 프롬프트 길이, 배치 방식에 따라 결과가 달라질 수 있습니다. 그래서 영상의 결과는 “모든 경우에 SGLang이 정답”이라는 뜻이 아닙니다. 대신 동시 요청과 반복 문맥이 많은 환경에서는 SGLang을 벤치마크 후보에 넣어야 한다는 신호로 보는 편이 안전합니다.

    SGLang 로컬 LLM 서빙 엔진 성능 비교 결과
    출처: 괴발자 YouTube 영상 캡처. Ollama, vLLM, SGLang 비교 결과를 보여주는 장면입니다.

    vLLM의 장점도 여전히 크다

    vLLM은 이미 널리 쓰이는 고성능 LLM 서빙 엔진입니다. 문서와 사례가 풍부하고, 범용적인 배치 처리 성능도 강합니다. SGLang이 흥미로운 선택지라고 해서 vLLM의 가치가 사라지는 것은 아닙니다. 실무에서는 두 엔진을 같은 요청 패턴으로 테스트해 보는 것이 더 합리적입니다.

    상황별 선택 기준: 무엇을 쓰면 좋을까

    SGLang을 도입할지 판단하려면 “내가 어떤 문제를 풀고 있는가”를 먼저 봐야 합니다. 개인 실험, 사내 PoC, 실제 서비스는 요구 조건이 다릅니다.

    개인 테스트라면 Ollama가 여전히 편하다

    로컬에서 모델을 설치하고 간단히 프롬프트를 테스트하는 목적이라면 Ollama의 편의성이 큽니다. 설치와 실행이 단순하고, 개발자가 빠르게 모델을 바꿔볼 수 있습니다. 성능보다 접근성과 반복 실험 속도가 중요할 때 적합합니다.

    일반 서비스 서빙은 vLLM부터 검토할 수 있다

    이미 vLLM을 쓰고 있거나 범용적인 고성능 API 서버가 필요하다면 vLLM은 여전히 좋은 출발점입니다. 운영 자료와 커뮤니티 경험이 많기 때문에 장애 대응과 튜닝 정보를 찾기 쉽습니다.

    반복 문맥이 많은 대량 요청은 SGLang을 검토하자

    SGLang은 공통 프롬프트가 반복되는 챗봇, RAG, 에이전트, 다중 사용자 서비스에서 매력적입니다. 요청마다 비슷한 시스템 지시문과 출력 규칙이 들어간다면 RadixAttention의 이점이 커질 수 있습니다.

    SGLang 로컬 LLM 서빙 엔진 활용 판단
    출처: 괴발자 YouTube 영상 캡처. 상황별 선택 기준을 설명하는 마무리 장면입니다.

    도입 전 체크리스트

    SGLang을 바로 운영 환경에 넣기보다는 작은 PoC로 검증하는 편이 좋습니다.

    • 같은 모델과 같은 프롬프트 세트로 vLLM과 SGLang을 비교한다.
    • 단일 요청 속도뿐 아니라 동시 요청 처리량을 함께 측정한다.
    • 공통 시스템 프롬프트가 많은 실제 요청 로그를 샘플링한다.
    • GPU 메모리 사용량과 장애 복구 방식을 확인한다.
    • 운영팀이 설치, 배포, 모니터링을 감당할 수 있는지 점검한다.

    벤치마크는 평균보다 꼬리 지연시간을 보자

    서비스에서는 평균 응답 시간보다 p95, p99 같은 꼬리 지연시간이 중요할 때가 많습니다. 일부 요청이 지나치게 늦어지면 사용자는 전체 서비스가 느리다고 느낍니다. SGLang을 테스트할 때도 처리량, 평균 지연시간, 꼬리 지연시간을 함께 봐야 합니다.

    결론: SGLang은 ‘서비스형 로컬 LLM’의 후보군이다

    SGLang 로컬 LLM 서빙 엔진은 Ollama의 편의성과 vLLM의 범용 성능 사이에서, 반복 문맥과 대량 요청 처리에 초점을 둔 선택지로 볼 수 있습니다. 모든 팀에 정답은 아니지만, RAG나 AI 에이전트처럼 비슷한 프롬프트 구조가 반복되는 서비스라면 충분히 테스트해 볼 가치가 있습니다.

    원본 영상은 괴발자 채널의 「Ollama 보다 빠르다는 vLLM을 뛰어넘었습니다! 로컬 LLM 서빙 엔진 SGLang 소개」입니다. AI 인프라와 로컬 LLM 관련 글은 ThinkNote AI 카테고리에서도 함께 확인할 수 있습니다.

    FAQ

    SGLang은 Ollama를 대체하나요?

    완전한 대체라기보다 목적이 다릅니다. Ollama는 로컬 실행과 실험이 쉽고, SGLang은 여러 요청을 처리하는 서빙 환경에 더 초점을 둡니다.

    vLLM을 이미 쓰고 있어도 SGLang을 봐야 하나요?

    동시 요청이 많고 공통 프롬프트가 반복된다면 비교 테스트를 해볼 만합니다. 주의할 점은 기존 vLLM 운영이 안정적이라면 실제 요청 로그 기반으로 이득을 확인한 뒤 전환하는 것이 좋습니다.

    SGLang은 어떤 서비스에 잘 맞나요?

    기업 내부 챗봇, RAG, AI 에이전트, 반복 지시문이 많은 API 서비스에 잘 맞을 수 있습니다. 반대로 단순 개인 실험이라면 Ollama가 더 편할 수 있습니다.

    참고자료

    함께 읽으면 좋은 글

  • 에이전틱 엔지니어링: 안드레이 카파시가 말한 바이브 코딩 이후의 개발 방식

    에이전틱 엔지니어링: 안드레이 카파시가 말한 바이브 코딩 이후의 개발 방식

    에이전틱 엔지니어링은 바이브 코딩의 다음 단계입니다. 안드레이 카파시는 Sequoia Capital의 AI Ascent 2026 대담에서, 최신 AI 코딩 도구가 단순한 자동완성 수준을 넘어 개발자의 역할 자체를 바꾸고 있다고 설명합니다. 이제 중요한 질문은 “AI가 코드를 얼마나 빨리 쓰는가”가 아니라, “사람이 에이전트를 어떻게 지휘하고 검증할 것인가”입니다.

    에이전틱 엔지니어링 - 안드레이 카파시 대담 소개
    출처: 스테이지5 유튜브 「안드레이 카파시: 바이브 코딩에서 에이전틱 엔지니어링으로」 화면 캡처. 안드레이 카파시가 대담을 시작하는 장면입니다.

    왜 에이전틱 엔지니어링이 중요해졌나

    카파시는 자신이 “프로그래머로서 가장 뒤처진 느낌을 받았다”고 말합니다. 놀라운 말입니다. 그는 OpenAI 공동창업자였고, Tesla Autopilot 개발에도 참여한 인물입니다. 그런 개발자조차 최신 AI 코딩 도구의 변화 속도 앞에서 기존 감각이 흔들렸다고 말한 것입니다.

    2025년 말 이후의 전환점

    그가 짚은 전환점은 2025년 말입니다. 이전의 에이전트 도구는 코드 조각을 제안해 주는 보조 도구에 가까웠습니다. 사람이 자주 고쳐야 했고, 결과를 완전히 믿기는 어려웠습니다.

    하지만 어느 순간부터 최신 모델은 더 긴 코드 덩어리도 꽤 안정적으로 만들기 시작했습니다. 개발자는 직접 타이핑하는 시간을 줄이고, 요구사항을 설명하고, 결과를 검토하는 쪽으로 이동합니다. 이것이 바이브 코딩의 출발점입니다.

    Software 3.0은 무엇인가

    카파시는 이 변화를 Software 3.0이라는 개념으로 설명합니다. Software 1.0은 사람이 직접 작성한 코드입니다. Software 2.0은 데이터셋과 신경망 학습으로 만들어진 모델입니다. Software 3.0은 LLM이라는 인터프리터를 프롬프트와 컨텍스트로 조종하는 방식입니다.

    에이전틱 엔지니어링 - Software 3.0 설명
    출처: 스테이지5 유튜브 화면 캡처. Software 3.0과 프롬프트 기반 프로그래밍을 설명하는 구간입니다.

    코드는 파일에만 있지 않다

    Software 3.0에서는 코드만이 프로그램이 아닙니다. 프롬프트, 문서, 테스트, 예시, 오류 로그, 저장소 구조, 컨텍스트 윈도우까지 모두 프로그램의 일부가 됩니다. 개발자는 LLM이 해석할 수 있는 환경을 설계해야 합니다.

    이 관점에서는 “좋은 프롬프트”보다 “좋은 작업 맥락”이 더 더 봐야 합니다. 에이전트가 문제를 이해하고, 스스로 탐색하고, 실행 결과를 확인할 수 있어야 하기 때문입니다.

    바이브 코딩은 누구나 만들게 하지만, 실무는 다르다

    바이브 코딩은 아이디어를 빠르게 제품 형태로 바꾸는 방식입니다. 말로 요구사항을 설명하고, AI가 코드를 작성하게 하며, 결과물을 보면서 계속 수정합니다. 이 방식은 진입 장벽을 크게 낮춥니다.

    MenuGen 사례가 보여준 것

    카파시는 메뉴판 사진을 찍으면 음식 이미지를 붙여 보여주는 MenuGen 앱을 바이브 코딩으로 만들었습니다. 그런데 나중에는 Gemini와 이미지 생성 모델에 메뉴판 사진을 주고 바로 오버레이를 요청하는 방식이 더 자연스럽다는 점을 깨달았다고 말합니다.

    에이전틱 엔지니어링 - MenuGen 사례
    출처: 스테이지5 유튜브 화면 캡처. MenuGen 사례를 통해 기존 앱 구조가 Software 3.0 방식으로 바뀔 수 있음을 설명하는 장면입니다.

    이 사례는 중요한 질문을 던집니다. 앞으로 어떤 앱은 더 잘 만들어지는 것이 아니라, 아예 필요 없어질 수 있습니다. 사용자가 원하는 결과를 LLM과 생성 모델이 직접 만들어낸다면, 중간에 있던 많은 소프트웨어 계층이 사라질 수 있습니다.

    에이전틱 엔지니어링은 스펙과 검증의 기술이다

    카파시는 바이브 코딩과 에이전틱 엔지니어링을 구분합니다. 바이브 코딩이 빠른 구현의 감각이라면, 에이전틱 엔지니어링은 실무 시스템을 안전하게 만들기 위한 설계 방식입니다.

    사람이 여전히 책임져야 하는 영역

    AI 에이전트는 놀라운 속도로 코드를 작성하지만, 이상한 설계 실수도 합니다. 카파시는 결제 크레딧을 사용자 계정과 연결하는 예시를 듭니다. 에이전트가 Stripe 이메일과 Google 이메일을 그냥 맞춰 자금을 연결하려 했다는 것입니다.

    겉보기에는 그럴듯하지만, 실제 서비스에서는 치명적인 설계입니다. 사용자는 결제 이메일과 로그인 이메일을 다르게 쓸 수 있습니다. 이런 문제는 코드 문법이 아니라 도메인 이해, 데이터 모델, 보안, 제품 판단의 문제입니다.

    에이전틱 엔지니어링 - 바이브 코딩 이후의 실무 전환
    출처: 스테이지5 유튜브 화면 캡처. 바이브 코딩에서 에이전틱 엔지니어링으로 넘어가는 차이를 설명하는 구간입니다.

    그래서 사람은 스펙, 계획, 판단 기준, 테스트 전략을 책임져야 합니다. 에이전트는 구현을 많이 맡을 수 있지만, 무엇을 만들지와 왜 그렇게 만들어야 하는지는 사람이 설계해야 합니다.

    검증 가능한 환경이 AI 제품의 핵심 기회다

    카파시는 검증 가능성을 매우 중요하게 봅니다. 코드가 AI에 잘 맞는 이유도 여기에 있습니다. 실행해 볼 수 있고, 테스트할 수 있고, 오류 메시지를 받을 수 있습니다. 즉, 모델이 스스로 개선할 수 있는 피드백 루프가 있습니다.

    창업자는 무엇을 봐야 할까

    창업자에게 중요한 질문은 “AI로 무엇을 자동화할 수 있나”보다 더 구체적이어야 합니다. “검증 가능한 환경을 어떻게 만들 수 있나”가 핵심입니다. 정답 여부를 측정할 수 있고, 실패를 감지할 수 있으며, 개선 데이터를 쌓을 수 있는 영역이 강력한 기회가 됩니다.

    예를 들어 테스트 자동화, 보안 점검, 문서 검증, 데이터 정합성 검사, 운영 절차 자동화 같은 영역은 에이전트와 잘 맞습니다. 반대로 결과가 맞는지 판단하기 어렵고, 책임 소재가 불분명한 영역은 더 조심해야 합니다.

    AI 네이티브 개발자의 차이는 어디서 생기나

    AI 네이티브 개발자는 그냥 ChatGPT를 자주 쓰는 사람이 아닙니다. Claude Code, Codex, OpenClaw 같은 도구를 자기 작업 흐름에 맞게 세팅하고, 에이전트가 읽을 수 있는 문서와 구조를 준비합니다.

    생산성 차이는 타이핑 속도가 아니다

    이제 생산성 차이는 코드를 빨리 치는 능력에서만 나오지 않습니다. 문제를 잘게 나누는 능력, 좋은 스펙을 쓰는 능력, 테스트를 설계하는 능력, 결과물을 검증하는 능력에서 차이가 커집니다.

    카파시는 뛰어난 개발자가 AI 도구를 잡으면 10배를 넘어서는 생산성 차이가 날 수 있다고 봅니다. 이유는 간단합니다. 좋은 개발자는 에이전트가 놓치기 쉬운 맥락을 알고, 잘못된 방향을 빠르게 감지하며, 더 좋은 작업 환경을 설계할 수 있기 때문입니다.

    에이전트 퍼스트 인프라가 필요하다

    현재 많은 에이전트는 사람용 웹페이지와 설정 화면을 억지로 조작합니다. 버튼을 누르고, URL을 열고, 메뉴를 찾아갑니다. 카파시는 이런 방식이 비효율적이라고 지적합니다.

    에이전틱 엔지니어링 - 에이전트 퍼스트 인프라
    출처: 스테이지5 유튜브 화면 캡처. 에이전트가 사용하기 쉬운 인프라와 데이터 구조의 필요성을 설명하는 장면입니다.

    사람용 UI와 에이전트용 인터페이스는 다르다

    앞으로 서비스는 사람에게 보기 좋은 UI뿐 아니라, 에이전트가 이해하고 실행하기 쉬운 인터페이스를 제공해야 합니다. 명확한 API, 기계가 읽기 쉬운 문서, 구조화된 설정, 자동 검증 가능한 작업 단위가 더 봐야 합니다.

    이 변화는 개발 도구에만 국한되지 않습니다. 클라우드, 결제, 데이터베이스, 배포, 보안, 고객지원 도구까지 모두 에이전트 친화적으로 재설계될 가능성이 높습니다.

    결론: 개발자는 사라지는 것이 아니라 역할이 올라간다

    카파시의 메시지는 개발자의 종말론과 다릅니다. 그는 사람이 여전히 이해와 판단을 담당한다고 봅니다. 주의할 점은 직접 코드를 쓰는 비중은 줄고, 에이전트를 지휘하고 검증하는 비중이 커집니다.

    에이전틱 엔지니어링 시대의 개발자는 구현자이면서 동시에 감독자입니다. 좋은 개발자는 코드를 많이 쓰는 사람에서, 좋은 문제 정의와 검증 가능한 환경을 설계하는 사람으로 이동합니다.

    지금 필요한 준비는 거창하지 않습니다. 작은 프로젝트부터 에이전트에게 맡길 수 있는 작업과 사람이 직접 판단해야 하는 작업을 구분해 보아야 합니다. 그리고 문서, 테스트, 스펙, 배포 절차를 에이전트가 이해할 수 있게 정리해야 합니다. 그것이 바이브 코딩 이후의 실무 경쟁력입니다.

    FAQ

    에이전틱 엔지니어링은 바이브 코딩과 무엇이 다른가요?

    바이브 코딩은 AI와 대화하며 빠르게 구현하는 방식에 가깝습니다. 에이전틱 엔지니어링은 실무 시스템을 만들기 위해 스펙, 테스트, 보안, 검증, 운영까지 포함해 에이전트를 지휘하는 방식입니다.

    Software 3.0은 코딩을 대체한다는 뜻인가요?

    완전한 대체라기보다 코딩의 단위가 바뀐다는 뜻에 가깝습니다. 코드뿐 아니라 프롬프트, 문서, 컨텍스트, 테스트가 개발의 핵심 재료가 됩니다.

    개발자는 무엇을 준비해야 하나요?

    AI 도구 사용법만 익히는 것으로는 부족합니다. 요구사항을 명확히 쓰는 능력, 테스트를 설계하는 능력, 결과를 검증하는 능력, 에이전트가 이해하기 쉬운 문서를 만드는 능력을 함께 길러야 합니다.

    참고자료

    함께 읽으면 좋은 글

  • AI와 일의 미래: 사라지는 직업보다 먼저 봐야 할 ‘일의 의미’

    AI와 일의 미래: 사라지는 직업보다 먼저 봐야 할 ‘일의 의미’

    AI와 일의 미래를 이야기할 때 많은 사람은 먼저 “내 직업이 사라질까?”를 떠올립니다. 하지만 SK 유튜브 시리즈 [AI 이후 우리는] EP.1 “AI와 일”은 질문을 조금 다르게 던집니다. 중요한 것은 어떤 직업이 남고 사라지는가만이 아닙니다. 인간에게 일이 어떤 의미였고, AI 이후 그 의미가 어떻게 바뀌는지가 더 큰 질문입니다.

    AI와 일의 미래를 다루는 SK [AI 이후 우리는] EP.1 주제 소개 장면
    영상은 직업 대체를 넘어 인간에게 일이 어떤 의미인지 묻는다.

    이 영상에는 출판 마케터, HR 전문가, 작가, 청소와 그림을 함께 하는 창작자가 등장합니다. 각자의 경험은 다르지만 공통된 메시지는 분명합니다. AI 시대의 변화는 단순한 직업 대체가 아니라 일하는 방식, 조직의 구조, 커리어의 기준을 동시에 흔들고 있습니다.

    이 글에서 다룰 내용

    • AI가 바꾸는 것은 직업 목록이 아니라 ‘일의 구조’라는 점
    • 관리자와 팀장의 역할이 왜 달라지는지
    • 앞으로 필요한 인재상과 커리어 전략
    • 인간이 AI와 다르게 가질 수 있는 강점
    • 개인과 조직이 지금 점검해야 할 체크리스트

    AI와 일의 미래는 ‘대체’보다 ‘재정의’에 가깝다

    영상 초반에서 패널들은 “어떤 일자리가 사라질까”보다 “일이란 무엇인가”를 먼저 묻습니다. HR 전문가 황성현 교수는 일을 “각자의 자리에서 특정한 문제를 해결하는 것”으로 설명합니다. 이 관점은 AI 시대에 특히 더 봐야 합니다.

    직업명은 변할 수 있습니다. 부장, 팀장, 마케터, 개발자, 작가 같은 이름도 달라질 수 있습니다. 하지만 조직과 시장에는 여전히 해결해야 할 문제가 남습니다. 결국 AI와 일의 미래에서 먼저 볼 부분은 “나는 어떤 문제를 해결할 수 있는가”로 이동합니다.

    논리력과 분석력은 더 이상 인간만의 영역이 아니다

    기존 회사는 논리력, 분석력, 성실성을 기준으로 사람을 뽑고 길러 왔습니다. 그런데 영상에서는 논리와 분석의 앞단을 AI가 매우 빠르게 대체하고 있다고 지적합니다. 보고서 초안, 시장 조사, 코딩 피드백, 자료 요약은 이미 AI가 상당 부분 처리합니다.

    AI와 일의 미래에서 일은 문제 해결이라는 관점을 설명하는 대담 장면
    일은 직함이 아니라 해결해야 할 문제를 중심으로 재정의된다.

    그렇다고 인간의 역할이 없어지는 것은 아닙니다. 오히려 질문은 더 어려워집니다. AI가 분석한 결과를 어떤 목표와 맥락에 연결할 것인지, 어떤 선택에 책임질 것인지, 어떤 방식으로 새로운 가치를 만들 것인지가 더 봐야 합니다.

    AI가 일을 줄이는 것이 아니라 일을 늘릴 수도 있다

    흥미로운 대목은 AI가 도입되면 일이 줄어들 것 같지만, 실제로는 일이 늘어나는 경험도 많다는 점입니다. 영상 속 출판 마케터는 AI를 개인 비서처럼 쓰면서도 “못 한다고 미뤄두던 일까지 다 하게 되어 일이 무한 증식한다”고 말합니다.

    예전에는 비용, 인력, 기술 부족을 이유로 포기하던 일이 많았습니다. 이제는 AI 도구를 이용하면 비개발자도 간단한 자동화나 기획 실험을 해볼 수 있습니다. 마케터가 데이터 분석을 하고, 기획자가 프로토타입을 만들고, 1인 팀이 여러 에이전트와 일하는 장면이 현실이 되고 있습니다.

    생산성 향상 뒤에 숨은 새 부담

    AI는 시간을 줄여 주지만 기대치도 함께 올립니다. “이제 그 정도는 AI로 할 수 있지 않나?”라는 말이 생기면 개인의 업무 범위는 넓어집니다. 그래서 AI와 일의 미래를 준비한다는 것은 도구 사용법만 배우는 일이 아닙니다. 내가 해야 할 일과 하지 않아도 되는 일을 다시 정하는 능력이 해야 합니다.

    조직은 더 평평해지고, 관리자의 역할은 흔들린다

    영상에서 가장 인상적인 주제 중 하나는 조직 구조의 변화입니다. 과거 조직은 실무자가 자료를 만들고, 중간관리자가 검토하고, 임원이 의사결정하는 방식으로 움직였습니다. 하지만 AI가 자료 조사와 정리, 피드백, 목표 수립의 일부까지 맡게 되면 중간 단계의 의미가 약해집니다.

    AI와 일의 미래 속 관리자 역할 변화와 조직 플래트닝 논의 장면
    AI가 목표 수립·피드백·검토 업무에 들어오면 리더십의 기준도 달라진다.

    이 변화는 그냥 “팀장이 줄어든다”는 이야기가 아닙니다. 관리자의 역할이 전달자와 검토자에서 가치 설계자, 맥락 제공자, 책임 있는 의사결정자로 바뀐다는 뜻입니다.

    팀원이 없는 팀장, 부가 없는 부장

    영상에서는 “혼자 있는 팀장”, “부가 없는 부장” 같은 표현이 나옵니다. 조직의 규모가 줄어들고, AI 에이전트와 함께 일하는 구조가 늘어나면 사람을 많이 거느리는 것이 더 이상 리더십의 핵심 지표가 아닐 수 있습니다.

    앞으로의 리더는 몇 명을 관리하느냐보다 어떤 문제를 정의하고, 어떤 AI·사람·프로세스를 조합해 결과를 만드는지가 더 봐야 합니다. 직책의 무게보다 실제로 더하는 가치가 드러나는 시대가 오는 것입니다.

    AI 시대의 일 잘하는 사람은 무엇이 다른가

    과거에는 성실하게 주어진 일을 처리하는 사람이 좋은 평가를 받았습니다. 물론 성실성은 여전히 더 봐야 합니다. 하지만 영상에서는 성실성만으로 버티기 어려운 시대가 왔다고 말합니다.

    AI와 일의 미래에서 필요한 사람은 정답이 없는 상황에서도 호기심을 잃지 않고, 자신의 방식으로 매뉴얼을 만들어 가. 프로젝트를 처음부터 끝까지 책임지는 사람입니다. 쉽게 말해 ‘주인의식’이 다시 중요해지고 있습니다.

    떠날 수 있는 사람이 오히려 남는다

    영상 속 표현 중 강하게 남는 말이 있습니다. “항상 떠날 수 있는 사람은 남을 것 같고, 남길 원하는 사람은 쉽지 않을 것 같다.” 여기서 떠날 수 있다는 말은 회사를 가볍게 여긴다는 뜻이 아닙니다. 시장에서 통하는 문제 해결 능력과 자기만의 업을 갖고 있다는 뜻입니다.

    AI와 일의 미래에서 시장 가치와 미래 인재를 말하는 장면
    떠날 수 있을 만큼의 힘, 즉 시장 가치가 새로운 안정성이 된다.

    조직의 보호에만 기대는 안정성은 약해질 수 있습니다. 반대로 어디서든 가치를 만들 수 있는 사람은 조직 안에서도 더 오래 필요해질 가능성이 높습니다.

    커리어 전략은 ‘창업’보다 ‘창직’으로 이동한다

    영상에서는 “업을 찾아야겠다”는 말에서 한 걸음 더 나아가 “창업을 넘어 창직을 해야 한다”는 표현이 나옵니다. 창직은 내가 할 수 있는 고유한 일을 새롭게 정의한다는 뜻입니다.

    예를 들어 그냥 “나는 마케터입니다”라고 말하는 대신, “AI 도구를 활용해 작은 브랜드의 콘텐츠 실험과 고객 반응 분석을 빠르게 설계하는 사람”이라고 정의할 수 있습니다. “나는 HR 담당자입니다” 대신 “AI 시대 조직의 역할 재설계와 인재 성장 시스템을 만드는 사람”이라고 말할 수도 있습니다.

    회사는 ‘이용할 수 있는 학습장’이 된다

    영상 속 출판 마케터는 회사를 개인이 작은 프로젝트를 실험해 볼 수 있는 장으로 설명합니다. 회사의 리소스를 활용해 새로운 일을 시도하고, 그 경험이 다시 개인의 역량이 되는 구조입니다.

    이 관점은 더 봐야 합니다. AI 시대의 직장은 평생 머무는 울타리라기보다 더 큰 문제를 함께 풀어보는 프로젝트 공간에 가까워질 수 있습니다. 조직도 개인에게 “우리 회사에 계속 있어라”보다 “여기서 성장하고, 나갈 수 있을 만큼 강해져라”라고 말할 수 있어야 합니다.

    인간이 AI보다 잘할 수 있는 일은 무엇인가

    마지막 부분에서 김예지 작가는 인간의 강점을 “주인의식”과 “프롬프트 밖으로 벗어나는 능력”으로 설명합니다. AI는 입력된 요청을 잘 수행합니다. 하지만 인간은 요청받지 않은 문제도 발견할 수 있습니다. 청소를 하다가 고객이 말하지 않은 거미줄을 보고 치우는 행동이 그런 예입니다.

    AI와 일의 미래에서 인간의 주인의식과 프롬프트 밖 행동을 말하는 장면
    AI 시대에도 인간의 강점은 주인의식과 맥락을 넘겨 보는 능력에 있다.

    이 말은 AI 시대의 인간 역할을 잘 보여 줍니다. 앞으로 사람은 단순 실행자가 아니라 맥락을 읽고, 요청의 바깥을 보고, 책임 있게 더 나은 결과를 제안하는 존재가 되어야 합니다.

    ‘AI가 못 하는 일’보다 ‘내가 책임질 일’을 묻자

    많은 사람이 AI가 절대 못 하는 일을 찾으려 합니다. 하지만 영상의 흐름을 따라가 보면 그 질문은 오래가지 못할 수 있습니다. 오늘은 창작이 안전해 보이다가 내일은 그림 생성 AI가 등장합니다. 블루칼라가 안전해 보이다가 휴머노이드 로봇이 등장합니다.

    그래서 더 현실적인 질문은 이것입니다. “AI가 하는 일 위에서 나는 무엇을 책임질 것인가?” 이 질문에 답할 수 있는 사람이 AI와 일의 미래를 더 잘 준비할 수 있습니다.

    개인과 조직을 위한 체크리스트

    AI와 일의 미래를 막연한 불안으로만 받아들이면 대응이 늦어집니다. 다음 체크리스트를 기준으로 현재의 일과 조직을 점검해 볼 수 있습니다.

    구분점검 질문실천 방향
    개인 역량내가 해결하는 핵심 문제는 무엇인가?직무명이 아니라 문제 해결 능력으로 자기소개를 바꾼다.
    AI 활용반복 업무를 AI로 줄이고 있는가?조사, 요약, 초안, 검토 업무부터 자동화한다.
    업무 범위AI 때문에 일이 무한히 늘고 있지는 않은가?해야 할 일과 하지 않을 일을 명확히 정한다.
    리더십나는 전달자인가, 가치 설계자인가?목표·맥락·책임 중심으로 역할을 재정의한다.
    커리어조직 밖에서도 통하는 시장 가치가 있는가?포트폴리오, 실험, 프로젝트 단위 성과를 쌓는다.
    조직문화직원이 나갈 수 있을 만큼 성장하도록 돕는가?교육보다 실험 기회와 권한 위임을 늘린다.

    FAQ: AI와 일의 미래에 대한 자주 묻는 질문

    AI가 정말 모든 직업을 대체할까요?

    모든 직업이 한꺼번에 사라진다고 보기는 어렵습니다. 주의할 점은 직업 안에 포함된 반복 업무, 분석 업무, 검토 업무는 빠르게 바뀔 가능성이 높습니다. 직업명보다 업무 단위로 변화를 보는 것이 현실적입니다.

    AI 시대에도 회사에 들어가는 것이 의미가 있을까요?

    의미가 있습니다. 주의할 점은 회사의 의미가 평생 안정성에서 프로젝트 경험, 리소스 활용, 협업 학습으로 이동할 수 있습니다. 좋은 회사는 개인이 더 큰 문제를 풀어보고 성장할 수 있는 장이 되어야 합니다.

    앞으로 가장 중요한 역량은 무엇인가요?

    영상의 핵심을 기준으로 보면 문제 정의, 주인의식, 호기심, 책임 있는 의사결정, AI 활용 능력이 더 봐야 합니다. 특히 정답이 없는 상황에서 스스로 기준을 만들고 결과까지 책임지는 태도가 해야 합니다.

    관리자는 사라질까요?

    관리자라는 직책이 모두 사라진다기보다 역할이 바뀔 가능성이 높습니다. 자료 전달, 단순 검토, 일정 관리 중심의 관리자는 약해지고, 목표를 설계하고 사람과 AI를 조합해 결과를 만드는 리더가 중요해질 것입니다.

    결론: AI와 일의 미래는 ‘덜 일하기’보다 ‘다르게 일하기’의 문제다

    영상의 마지막 메시지는 단순한 낙관도, 공포도 아닙니다. AI는 분명 많은 일을 바꿉니다. 하지만 인간에게 일이 완전히 사라진다기보다 일의 형태와 의미가 달라질 가능성이 높습니다.

    AI와 일의 미래를 준비하는 가장 좋은 방법은 “AI가 내 일을 빼앗을까?”에만 머무르지 않는 것입니다. 내가 해결하는 문제를 다시 정의하고, AI를 도구로 받아들이며, 조직 안팎에서 통하는 나만의 가치를 만들어야 합니다.

    결국 중요한 질문은 이것입니다.

    나는 AI가 만든 결과 위에서 어떤 판단과 책임을 더할 수 있는가?

    이 질문에 답을 만들어 가는 사람이 앞으로의 일터에서도, 조직 밖의 시장에서도 더 오래 살아남을 것입니다.

    참고자료

    • [SK 유튜브 – “월급은 AI가 벌어올게, 넌 놀기만 해” 5년 뒤, 진짜 출근 안 해도 먹고사는 세상이 온다면? | [AI 이후 우리는] EP.1 “AI와 일”](https://youtu.be/H7Trml7qb5w)