Thinknote

jhshin@thinknote.co.kr

[태그:] Claude

Claude 활용법, Claude Code, 업무 자동화, AI 개발도구와 관련된 글을 모았습니다. Anthropic 생태계와 실무 적용 흐름을 확인할 수 있습니다.

  • Hermes Agent 데스크톱 앱: AI 에이전트 대중화의 다음 인터페이스

    Hermes Agent 데스크톱 앱: AI 에이전트 대중화의 다음 인터페이스

    AI 에이전트가 대중화되려면 모델 성능만 좋아져서는 부족합니다. 사람이 매일 쓰는 방식으로 다가와야 합니다. Alex Finn의 영상은 Hermes Agent 데스크톱 앱을 보여주면서 이 지점을 분명하게 드러냅니다.

    영상의 표현은 다소 과감합니다. CLI, Telegram, OpenClaw보다 Hermes 데스크톱 앱이 더 낫다고 말합니다. 하지만 블로그 관점에서 중요한 질문은 승패가 아닙니다. AI 에이전트가 챗봇을 넘어 실제 업무 도구가 되려면 어떤 인터페이스가 필요한가입니다.

    왜 데스크톱 앱이 중요한가

    AI 에이전트는 그냥 답변을 생성하는 도구가 아닙니다. 파일을 읽고, 명령을 실행하고, 이미지를 만들고, 예약 작업을 돌리고, 여러 세션의 맥락을 이어갑니다. 이런 도구를 명령줄이나 메신저 명령만으로 다루면 초보자에게는 진입 장벽이 큽니다.

    Hermes Agent 데스크톱 앱이 의미 있는 이유는 이 복잡한 구조를 눈에 보이는 작업 공간으로 바꾸기 때문입니다. 사용자는 세션, 아티팩트, 스킬, 툴셋, 크론잡, 프로필을 한곳에서 확인할 수 있습니다. 이는 AI 에이전트를 개발자 장난감에서 일상 업무 도구로 옮기는 핵심 변화입니다.

    Hermes Agent 데스크톱 앱의 첫 화면과 기존 CLI 한계 설명
    Hermes Agent 데스크톱 앱의 첫 화면. 영상은 CLI 중심 사용 경험의 한계를 지적하며 데스크톱 UI의 필요성을 강조한다.

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

    세션은 AI 에이전트의 업무 폴더가 된다

    영상 초반에서 진행자는 주제별 세션을 만드는 방식을 보입니다. 콘텐츠, 개발, 개인 프로젝트처럼 맥락이 다른 일을 각각의 세션으로 나누는 방식입니다. 이는 단순 채팅방 정리가 아니라 AI 에이전트에게 일을 맡기는 단위를 나누는 일에 가깝습니다.

    AI 에이전트는 맥락이 길수록 더 유용해집니다. 하지만 맥락이 섞이면 오히려 혼란이 생깁니다. 그래서 세션을 주제별로 나누고 중요한 세션을 고정하는 기능은 작아 보여도 더 봐야 합니다. 사람에게 프로젝트 폴더가 필요하듯, 에이전트에게도 맥락 폴더가 해야 합니다.

    세션을 주제별로 나누고 맥락을 관리하는 화면
    세션을 주제별로 나누는 화면. AI 에이전트 사용에서 맥락 분리는 생산성과 정확도를 좌우한다.

    아티팩트는 채팅 기록을 작업 자산으로 바꾼다

    영상에서 특히 흥미로운 부분은 아티팩트입니다. 링크, 파일, 이미지, 에이전트가 만든 결과물을 한곳에서 다시 찾을 수 있습니다. 진행자는 이를 북마크나 작업 자료 보관소처럼 활용할 수 있다고 설명합니다.

    이 기능은 AI 에이전트 경험의 방향을 잘 보입니다. 챗봇은 대화를 남깁니다. 에이전트는 산출물을 남겨야 합니다. 나중에 다시 찾고, 이어서 쓰고, 다른 세션에서 재사용할 수 있어야 합니다.

    아티팩트와 링크를 한곳에서 관리하는 화면
    아티팩트 화면. 링크와 파일, 이미지, 생성 결과물이 흩어지지 않고 작업 자산으로 쌓인다.

    스킬과 툴셋은 에이전트의 능력을 관리하는 패널이다

    Hermes Agent의 중요한 특징 중 하나는 스킬입니다. 반복 작업이나 특정 환경에서 배운 절차를 스킬로 저장해 다음 작업에 재사용합니다. 영상에서도 진행자는 자신이 Godot 게임을 만들며 생성된 커스텀 스킬을 확인하는 장면을 보입니다.

    툴셋도 더 봐야 합니다. 웹 검색, 터미널, 파일, 이미지 생성, 크론 같은 도구 묶음을 켜고 끄는 방식은 에이전트의 권한과 능력을 조절하는 일입니다. 데스크톱 UI는 이 설정을 명령어가 아니라 관리 화면으로 바꿉니다.

    크론잡은 AI 에이전트를 수동 비서에서 자동 운영자로 바꾼다

    영상 중반에서는 크론잡 관리 화면이 등장합니다. 매일 밤 앱을 만들게 하거나, 정해진 시간에 작업을 실행하게 하는 식의 예약 작업을 시각적으로 확인할 수 있습니다.

    크론잡은 AI 에이전트가 단발성 대답 도구에서 자동 운영 도구로 넘어가는 지점입니다. 한 가지 조심할 점은 예약 작업은 실패 여부, 실행 로그, 권한 범위가 함께 보여야 신뢰할 수 있습니다. 데스크톱 앱은 이 확인 과정을 더 쉽게 만들 수 있습니다.

    크론잡을 시각적으로 확인하고 예약하는 화면
    크론잡 관리 화면. 예약 작업은 AI 에이전트를 반복 업무 자동화 도구로 바꾸는 핵심 기능이다.

    여러 프로필은 역할별 AI 직원을 만드는 방식이다

    영상 후반에서 진행자는 여러 Hermes Agent를 서로 다른 장비와 역할에 나눠 운영한다고 말합니다. 어떤 에이전트는 특정 장비에서 살고, 어떤 에이전트는 다른 책임을 맡습니다. 데스크톱 앱은 이런 에이전트 프로필을 더 쉽게 관리하게 해줍니다.

    이 구조는 앞으로 중요한 의미를 가집니다. 한 명의 범용 챗봇보다, 역할과 권한이 다른 여러 AI 에이전트를 운영하는 방식이 늘어날 수 있습니다. 콘텐츠 에이전트, 개발 에이전트, 리서치 에이전트, 모니터링 에이전트가 서로 다른 스킬과 도구를 갖는 식입니다.

    실제 사용 예시는 산출물 중심 경험을 보여준다

    마지막 예시에서 진행자는 이 영상에 대한 스크립트와 썸네일을 생성해 달라고 요청합니다. 데스크톱 앱은 사용 중인 스킬과 도구를 보여주고, 결과물은 아티팩트에서 확인됩니다.

    이 장면은 AI 에이전트 UI의 핵심을 압축합니다. 사용자는 명령어를 외우지 않아도 됩니다. 에이전트가 어떤 도구를 쓰는지 볼 수 있습니다. 결과물은 파일이나 이미지로 남습니다. 이 세 가지가 합쳐져야 AI 에이전트는 실제 업무 흐름에 들어옵니다.

    스크립트와 썸네일을 생성하는 실제 사용 예시
    영상 스크립트와 썸네일을 생성하는 예시. 에이전트의 도구 사용 과정과 결과물이 함께 보인다.

    Hermes Agent 데스크톱 앱이 던지는 질문

    이 영상이 보여주는 먼저 볼 부분은 “Hermes가 이겼다”가 아닙니다. 더 중요한 질문은 AI 에이전트의 주 사용 인터페이스가 어디가 될 것인가입니다. CLI는 강력하지만 대중적이지 않습니다. 메신저는 편하지만 복잡한 설정과 검증에는 약합니다. 데스크톱 앱은 그 중간에서 작업 관리와 접근성을 동시에 제공합니다.

    물론 주의할 점도 있습니다. AI 에이전트는 파일, 브라우저, 터미널, 외부 API에 접근할 수 있습니다. 그래서 UI가 쉬워질수록 권한 관리와 로그 확인은 더 더 봐야 합니다. 좋은 데스크톱 앱은 버튼을 많이 제공하는 앱이 아니라, 무엇을 허용했고 무엇이 실행됐는지 사용자가 이해하게 해주는 앱이어야 합니다.

    함께 읽으면 좋은 글

    결론: AI 에이전트의 승부처는 모델 다음의 사용 경험이다

    Hermes Agent 데스크톱 앱은 AI 에이전트의 다음 과제를 잘 보입니다. 이제 문제는 “에이전트가 무엇을 할 수 있는가”만이 아닙니다. 사용자가 그 능력을 어떻게 이해하고, 관리하고, 반복해서 쓸 수 있는가입니다.

    세션은 맥락을 나눕니다. 아티팩트는 산출물을 보관합니다. 스킬은 경험을 축적합니다. 크론잡은 반복 작업을 자동화합니다. 프로필은 역할별 에이전트를 만듭니다. 이 요소들이 데스크톱 UI 안에서 연결될 때, AI 에이전트는 개발자용 실험 도구에서 실제 업무 운영체제에 가까워집니다.

    FAQ

    Hermes Agent 데스크톱 앱은 무엇을 쉽게 만들어 주나?

    세션, 아티팩트, 스킬, 툴셋, 크론잡, 프로필 관리를 시각적으로 확인하고 조작하게 해줍니다. CLI 명령을 몰라도 에이전트 운영 구조를 이해하기 쉬워집니다.

    CLI보다 데스크톱 앱이 항상 좋은가?

    항상 그렇지는 않습니다. 개발자나 자동화 고급 사용자는 CLI가 더 빠를 수 있습니다. 한 가지 조심할 점은 초보자와 비개발자에게는 데스크톱 UI가 진입 장벽을 낮춥니다.

    아티팩트 기능은 왜 중요한가?

    AI 에이전트가 만든 링크, 이미지, 파일, 결과물을 다시 찾고 재사용할 수 있게 해줍니다. 이는 단순 채팅 기록을 실제 작업 자산으로 바꾸는 기능입니다.

    크론잡은 어떤 업무에 쓸 수 있나?

    정기 리포트, 사이트 모니터링, 자료 수집, 블로그 성과 확인, 반복 개발 작업 같은 예약형 업무에 쓸 수 있습니다. 한 가지 조심할 점은 실패 로그와 권한 범위 확인이 더 봐야 합니다.

    AI 에이전트 데스크톱 앱을 쓸 때 주의할 점은 무엇인가?

    파일·터미널·브라우저·외부 API 접근 권한을 과하게 열지 않아야 합니다. 어떤 도구가 활성화되어 있고 어떤 작업이 실행됐는지 로그와 승인 흐름을 체크해 두세요.

    참고자료

  • M5 Pro Max 128GB 로컬 LLM 실사용: OMLX와 Hermes Agent가 보여준 가능성

    M5 Pro Max 128GB 로컬 LLM 실사용: OMLX와 Hermes Agent가 보여준 가능성

    로컬 LLM은 이제 “재미로 돌려보는 장난감”을 넘어 실제 업무 도구가 될 수 있을까요. 배움의 달인 영상은 M5 Pro Max 128GB 환경에서 OMLX 서버, Claude Code, Hermes Agent를 연결해 이 질문을 직접 테스트합니다.

    먼저 볼 부분은 단순합니다. 로컬 LLM이 모든 클라우드 모델을 대체한다는 이야기가 아닙니다. 반복 작업, 빠른 초안, 일부 코딩 보조, 개인 지식 기반 검색처럼 비용·속도·프라이버시가 중요한 영역부터 로컬로 옮길 수 있는지가 관건입니다.

    로컬 LLM 실사용 - 로컬 LLM 오케스트레이터와 모델 구성 화면
    영상은 여러 로컬 모델을 오케스트레이터에 연결해 실제 작업 흐름을 구성하는 장면에서 출발합니다. 출처: 배움의 달인 YouTube 영상 캡처.

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

    영상이 던진 핵심 질문: 로컬 LLM은 실무에 쓸 수 있나

    이 영상의 검색 의도는 “M5 Pro Max에서 로컬 LLM이 빠른가?”에만 머물지 않습니다. 더 중요한 질문은 세 가지입니다.

    • 로컬 모델을 Claude Code 같은 개발 도구와 연결할 수 있는가
    • OMLX 같은 서버가 체감 속도를 얼마나 끌어올리는가
    • Hermes Agent처럼 도구를 호출하는 에이전트에도 로컬 LLM을 붙일 수 있는가

    영상에서는 Qwen 계열 모델, NVIDIA Nemotron Nano 계열 모델, 임베딩 모델 등을 소개하며 로컬 환경을 하나의 작업 시스템처럼 구성합니다. 여기서 로컬 LLM은 단일 챗봇이 아니라 여러 도구와 연결되는 백엔드 모델에 가깝습니다.

    Thinknote의 세컨드 브레인과 LLM Wiki 글에서 다룬 것처럼, 앞으로의 AI 활용은 모델 성능만이 아니라 “어떤 맥락을 어떤 도구와 연결하느냐”가 더 더 봐야 합니다.

    OMLX가 중요한 이유: 모델보다 서버 체감이 먼저 보인다

    영상에서 가장 눈에 띄는 장면은 OMLX 대시보드입니다. 진행자는 OMLX를 통해 초당 117토큰 수준의 생성 속도를 확인했다고 설명합니다. 수치 자체보다 먼저 볼 부분은 로컬 LLM의 병목이 모델 파일 하나가 아니라 추론 서버, 캐싱, 배치 처리, 하드웨어 메모리 구성의 합으로 결정된다는 점입니다.

    로컬 LLM 실사용 - OMLX 대시보드에서 토큰 생성 속도를 확인하는 장면
    OMLX 대시보드에서 토큰 생성 속도와 모델 상태를 확인하는 장면입니다. 출처: 배움의 달인 YouTube 영상 캡처.

    OMLX GitHub README는 이 도구를 Apple Silicon에 최적화된 LLM inference 서버로 설명합니다. 핵심 표현은 continuous batching과 tiered KV caching입니다. 쉽게 말하면 여러 요청을 효율적으로 처리하고, 반복되는 문맥 계산 비용을 줄여 체감 속도를 높이는 구조입니다.

    로컬 LLM 실사용 - OMLX 서버 대시보드와 모델 운영 화면
    OMLX는 로컬 모델을 단순 실행하는 도구가 아니라, 대시보드로 모델 상태와 처리량을 확인하는 운영 환경에 가깝습니다. 출처: 배움의 달인 YouTube 영상 캡처.

    이 지점은 SGLang 로컬 LLM 서빙 엔진 글과도 이어집니다. 로컬 LLM을 제대로 쓰려면 모델 선택만큼이나 서빙 엔진, 컨텍스트 관리, 캐싱 전략이 더 봐야 합니다.

    Claude Code와 로컬 모델: 빠르지만 검증은 별도다

    영상 중반부에서는 omlx launch claude 흐름으로 Claude Code를 로컬 모델에 연결합니다. 이후 텍스트 작성과 테트리스 게임 생성 작업을 비교합니다. 진행자는 일부 작업에서 로컬 LLM이 더 빠르게 완료되는 모습을 보여주지만, 동시에 결과 품질은 별도로 확인해야 한다는 전제를 남깁니다.

    로컬 LLM 실사용 - OMLX로 Claude Code를 로컬 모델에 연결해 결과를 생성하는 장면
    Claude Code를 로컬 모델에 연결해 실제 산출물을 생성하는 장면입니다. 속도 비교와 품질 검증은 분리해서 봐야 합니다. 출처: 배움의 달인 YouTube 영상 캡처.

    이 대목에서 중요한 판단 기준은 “빠른가”보다 “어떤 작업을 맡겨도 되는가”입니다. 예를 들어 다음 작업은 로컬 모델에 먼저 맡겨볼 수 있습니다.

    작업 유형로컬 LLM 적합도확인해야 할 점
    초안 작성높음사실관계와 문체 검수 필요
    반복 코드 생성중간~높음테스트 실행과 보안 검토 필요
    개인 문서 요약높음민감정보 외부 전송을 줄일 수 있음
    최신 정보 검색중간검색 도구 연결과 출처 확인 필요
    복잡한 설계 판단중간클라우드 상위 모델과 교차 검토 권장

    AI 코딩 흐름은 Headroom 토큰 다이어트 글과도 연결됩니다. 비용을 줄이는 방법은 모델을 로컬로 돌리는 것만이 아닙니다. 에이전트가 읽는 로그, 파일, 검색 결과를 줄이고 검증 루프를 설계하는 것도 같은 문제의 다른 해법입니다.

    Hermes Agent와 로컬 LLM: 에이전트 운영의 다음 실험

    후반부에서 특히 흥미로운 부분은 Hermes Agent 연결입니다. 영상은 omlx launch hermes 흐름과 X Search 스킬 실행을 드러납니다. 로컬 모델이 단순 문장 생성기를 넘어 검색, 도구 호출, 요약, 산출물 생성을 담당하는 에이전트 런타임에 붙을 수 있음을 보여주는 장면입니다.

    로컬 LLM 실사용 - Hermes Agent에서 X Search 스킬로 로컬 LLM 검색을 실행하는 장면
    Hermes Agent에서 X Search 스킬을 호출해 최신 AI 소식을 검색하고 요약하는 장면입니다. 출처: 배움의 달인 YouTube 영상 캡처.

    Hermes Agent는 터미널, 메시징 플랫폼, IDE에서 실행되는 오픈소스 AI 에이전트 프레임워크입니다. 도구 호출, 스킬, 메모리, 크론잡, 멀티 플랫폼 게이트웨이를 통해 작업을 실행합니다. 로컬 LLM을 여기에 연결할 수 있다면 다음과 같은 장점이 생깁니다.

    • 개인 문서나 내부 로그를 외부 API로 덜 보내도 된다
    • 반복적인 요약·분류·초안 작업의 토큰 비용을 낮출 수 있다
    • 클라우드 모델 장애나 비용 제한이 있을 때 보조 경로가 생긴다
    • 에이전트 실험을 더 많이 돌려볼 수 있다

    주의할 점은 로컬 모델이 도구를 호출한다고 해서 곧바로 “믿고 맡길 수 있는 직원”이 되는 것은 아닙니다. AI 에이전트 시대의 개인 비서 글에서 다룬 것처럼, 실행형 AI일수록 권한, 검증, 로그, 되돌리기 설계가 더 봐야 합니다.

    도입 전 체크리스트: 로컬 LLM은 이렇게 판단하자

    로컬 LLM 도입 여부는 성능 수치 하나로 결정하면 위험합니다. 영상의 M5 Pro Max 128GB 환경은 강력한 상한선 사례에 가깝습니다. 일반적인 노트북이나 메모리가 작은 Mac에서는 같은 체감이 나오지 않을 수 있습니다.

    도입 전에는 아래 순서로 판단하는 편이 좋습니다.

    1. 먼저 반복 업무를 고른다. 초안, 요약, 태깅, 코드 스캐폴딩처럼 실패 비용이 낮은 작업부터 시작한다.
    2. 같은 프롬프트를 클라우드 모델과 로컬 모델에 넣고 속도·품질·비용을 비교한다.
    3. 로컬 모델 산출물은 테스트, 링크 확인, 사실 검증을 자동화한다.
    4. 민감정보가 있는 작업과 외부 검색이 필요한 작업을 분리한다.
    5. 최종 판단이나 고위험 실행은 클라우드 상위 모델 또는 사람 검토를 남긴다.

    이런 접근은 AI 네이티브 전환법 글에서 말한 “디지털 두뇌와 실행 에이전트의 분리”와도 맞닿아 있습니다. 로컬 LLM은 두뇌 전체를 대체하기보다, 자주 쓰는 일부 사고·실행 루프를 가까운 곳으로 가져오는 도구입니다.

    결론: 로컬 LLM의 승부처는 대체가 아니라 배치다

    이번 영상의 의미는 “로컬 LLM이 Claude나 GPT를 완전히 이겼다”가 아닙니다. 더 현실적인 결론은 로컬 LLM을 어디에 배치할지 정하는 단계가 왔다는 것입니다.

    고사양 Mac과 OMLX 같은 서버가 있다면 로컬 LLM은 초안, 요약, 코드 생성, 개인 지식 검색, 에이전트 실험에서 충분히 실무적 선택지가 될 수 있습니다. 반대로 최신 정보 판단, 복잡한 추론, 높은 신뢰도가 필요한 업무는 여전히 클라우드 모델과 병행하는 편이 안전합니다.

    결국 앞으로의 AI 업무 환경은 하나의 모델을 고르는 문제가 아닙니다. 로컬 모델, 클라우드 모델, 에이전트, 검색 도구, 지식 베이스를 어떤 기준으로 나눠 배치하느냐가 생산성을 가를 가능성이 높습니다.

    FAQ

    로컬 LLM이 Claude나 ChatGPT를 대체할 수 있나요?

    일부 반복 업무에서는 대체하거나 보조할 수 있습니다. 하지만 복잡한 판단, 최신 정보 검증, 고위험 코드 변경은 클라우드 상위 모델이나 사람 검토와 병행하는 것이 안전합니다.

    OMLX는 무엇인가요?

    OMLX는 Apple Silicon에 최적화된 LLM inference 서버입니다. GitHub README 기준으로 continuous batching과 tiered KV caching을 강조하. macOS 메뉴바와 대시보드를 통해 로컬 모델 운영을 쉽게 하는 방향의 도구입니다.

    M5 Pro Max 128GB가 아니어도 비슷한 결과가 나오나요?

    같은 수준의 속도를 보장하기는 어렵습니다. 영상 결과는 고사양 Mac과 큰 메모리 환경의 영향을 크게 받습니다. 자신의 장비에서는 작은 모델과 반복 작업부터 테스트하는 편이 좋습니다.

    Hermes Agent에 로컬 LLM을 연결하면 무엇이 좋아지나요?

    검색, 파일 처리, 요약, 자동화 작업을 로컬 모델로 실험할 수 있습니다. 비용과 프라이버시 측면에서 장점이 있지만, 도구 실행 권한과 결과 검증 체계는 반드시 따로 설계해야 합니다.

    로컬 LLM을 처음 도입한다면 어디서 시작해야 하나요?

    개인 문서 요약, 회의록 정리, 코드 초안, 간단한 분류 작업처럼 실패 비용이 낮은 작업부터 시작하는 것이 좋습니다. 이후 클라우드 모델 결과와 비교해 품질 기준을 정하면 됩니다.

    참고자료

  • AI 네이티브 전환법: 디지털 두뇌와 AI 에이전트로 일하는 방식 바꾸기

    AI 네이티브 전환법: 디지털 두뇌와 AI 에이전트로 일하는 방식 바꾸기

    AI 네이티브는 새로운 AI 도구를 많이 아는 상태가 아닙니다. 일하는 환경 자체를 AI가 함께 읽고, 판단하고, 실행할 수 있게 바꾸는 방식입니다. 커리어해커 알렉스의 영상은 이 전환을 “AI Native로 일하기”라는 관점에서 설명합니다. 먼저 볼 부분은 불안감을 줄이는 도구 목록이 아니라, 나의 지식과 업무 방식을 AI가 계속 활용할 수 있는 시스템으로 바꾸는 것입니다.

    Read in English: AI-Native Workflows: How to Rebuild Work Around a Digital Brain and AI Agents

    원본 영상: 지금 바뀌지 않으면 늦습니다. AI 네이티브가 되는 가장 빠른 방법 / 채널: 커리어해커 알렉스

    AI 네이티브는 도구 사용이 아니라 일하는 환경의 전환입니다

    AI 네이티브로 일해야 하는 이유를 설명하는 영상 도입 장면
    출처: 커리어해커 알렉스 YouTube 영상 캡처

    영상의 출발점은 “AI가 개발자만 바꾸는가?”라는 질문입니다. 답은 아니오에 가깝습니다. 발표자는 AI가 개발자뿐 아니라 비개발자에게도 더 큰 변화를 만들고 있다고 말합니다. 코딩을 직접 하느냐보다 먼저 볼 부분은 AI가 이해할 수 있는 방식으로 문제를 설명하고, 결과를 검증하고, 반복 가능한 작업 환경을 만드는 능력입니다.

    그래서 AI 네이티브는 ChatGPT, Claude, Gemini 같은 도구를 가끔 쓰는 사람이 아닙니다. 회의, 기획, 리서치, 글쓰기, 개발, 디자인, 운영 같은 일상 업무가 AI와 함께 돌아가도록 구조를 바꾸는 사람입니다. AI를 검색창처럼 쓰는 단계에서 벗어나, 내 업무 시스템의 일부로 넣는 것이 핵심입니다.

    왜 지금 전환해야 할까요?

    영상에서는 실리콘밸리의 베테랑들도 기존 공식이 무너지는 것을 체감하고 있다고 말합니다. 중요한 변화는 AI 성능이 좋아졌다는 사실 하나가 아닙니다. 1인 기업, 작은 팀, 비개발자도 이전보다 훨씬 큰 결과물을 만들 수 있는 환경이 생겼다는 점입니다.

    이 변화는 위협이면서 기회입니다. 기존 업무 방식에 머무르면 AI를 쓰는 사람과 격차가 빠르게 벌어집니다. 반대로 자신의 업무를 AI 네이티브 방식으로 재설계하면, 같은 시간 안에 더 많은 실험과 실행을 할 수 있습니다.

    디지털 두뇌는 AI 네이티브의 출발점입니다

    AI 네이티브 전환을 위한 디지털 두뇌 설명 장면
    출처: 커리어해커 알렉스 YouTube 영상 캡처

    영상에서 가장 인상적인 부분은 “내 두뇌가 들어있는 곳”이라는 표현입니다. 발표자는 자신의 글, 유튜브 콘텐츠, 생각, 믿음, 프로젝트 자료를 모아 디지털 두뇌를 만들고, 이를 에이전트에게 읽힌다고 설명합니다. 이렇게 하면 AI는 일반적인 조언이 아니라 사용자의 맥락을 반영한 제안을 만들 수 있습니다.

    이 방식은 세컨드 브레인과도 연결됩니다. 그냥 메모를 많이 저장하는 것이 아닙니다. 나의 자료를 AI가 찾고, 연결하고, 다시 사용할 수 있게 만드는 일입니다. LLM Wiki, Markdown 문서, 프로젝트 기록, 의사결정 기준은 모두 디지털 두뇌의 재료가 됩니다.

    챗봇보다 먼저 볼 부분은 에이전트 워크플로우입니다

    AI 네이티브 에이전트 워크플로우 활용 장면
    출처: 커리어해커 알렉스 YouTube 영상 캡처

    AI를 질문 답변용 챗봇으로만 쓰면 생산성 향상은 제한적입니다. AI 네이티브 방식에서는 에이전트가 자료를 읽고, 계획을 세우고, 파일을 만들고, 결과를 검토하는 흐름까지 맡습니다. 사람은 방향과 기준을 제시하고, 에이전트는 반복 가능한 실행을 담당합니다.

    여기서 중요한 것은 완전 자동화가 아닙니다. AI에게 모든 결정을 넘기는 것이 아니라, 사람이 목표와 평가 기준을 더 명확히 정하는 구조입니다. 좋은 에이전트 워크플로우는 “무엇을 할지”보다 “어떤 기준으로 성공을 판단할지”를 먼저 정합니다.

    코드 한 줄보다 먼저 볼 부분은 자동화 가능한 업무 구조입니다

    AI 네이티브 방식의 비즈니스 자동화 설명 장면
    출처: 커리어해커 알렉스 YouTube 영상 캡처

    영상은 코드 한 줄 없이도 웹사이트, 자료, 자동화 흐름을 만들 수 있다는 사례를 보입니다. 여기서 메시지는 “코딩을 몰라도 된다”가 아닙니다. 더 정확히는, 코딩 지식보다 문제를 분해하고 AI가 실행할 수 있는 단위로 바꾸는 능력이 중요해졌다는 뜻입니다.

    예전에는 아이디어가 있어도 개발자, 디자이너, 운영 인력이 필요했습니다. 이제는 한 사람이 AI와 함께 초안, 디자인, 코드, 자동화, 검토까지 빠르게 실험할 수 있습니다. 그래서 AI 네이티브 역량은 특정 직무의 기술이 아니라 모든 지식노동자의 기본 업무 능력에 가까워지고 있습니다.

    내일부터 시작할 수 있는 AI 네이티브 전환 순서

    AI 네이티브 생존력을 키워줄 도구 설명 장면
    출처: 커리어해커 알렉스 YouTube 영상 캡처

    처음부터 거대한 자동화 시스템을 만들 필요는 없습니다. 다음 순서로 시작하면 현실적입니다.

    1. 내 업무 자료를 한곳에 모으기

    회의록, 보고서, 블로그 초안, 고객 질문, 프로젝트 회고, 강의안처럼 반복해서 쓰는 자료를 모읍니다. AI가 나를 이해하려면 원본 맥락이 해야 합니다.

    2. 반복 업무를 문서화하기

    매번 비슷하게 하는 일을 절차로 적습니다. 예를 들어 “블로그 초안 작성”, “자료 조사”, “고객 답변”, “제안서 검토”처럼 작업 단위를 나눕니다.

    3. AI에게 역할과 기준을 함께 주기

    “이 일을 해줘”보다 “이 기준을 지키면서 이 결과물을 만들어줘”가 더 좋습니다. 톤, 형식, 금지사항, 검증 기준을 함께 줘야 결과가 안정됩니다.

    4. 결과를 저장하고 다시 쓰기

    잘 나온 프롬프트, 체크리스트, 템플릿, 실패 사례를 남깁니다. 이 기록이 쌓이면 디지털 두뇌가 됩니다.

    5. 작은 자동화부터 연결하기

    처음에는 파일 정리, 요약, 초안 생성, 표 변환처럼 작은 반복 작업부터 자동화합니다. 이후 여러 단계를 묶어 에이전트 워크플로우로 확장합니다.

    AI 네이티브의 먼저 볼 부분은 더 빠른 실행과 더 분명한 판단입니다

    AI 네이티브가 된다는 것은 사람이 덜 중요해진다는 뜻이 아닙니다. 오히려 사람의 판단 기준이 더 더 봐야 합니다. AI가 실행 속도를 높일수록, 무엇을 만들지, 어떤 기준으로 검토할지, 어떤 결과를 버릴지 결정하는 능력이 차이를 만듭니다.

    결국 AI 네이티브 전환은 도구 공부가 아니라 업무 운영체제의 교체입니다. 내 지식은 디지털 두뇌로 축적하고, 반복 실행은 에이전트에게 맡기고, 사람은 방향과 품질 기준을 책임지는 구조로 바꾸는 일입니다.

    함께 읽으면 좋은 글

    FAQ

    AI 네이티브는 AI 툴을 많이 쓰는 것과 무엇이 다른가요?

    AI 툴 사용은 개별 작업에 AI를 쓰는 것입니다. AI 네이티브는 자료, 절차, 검증 기준, 자동화 흐름까지 AI가 활용할 수 있게 업무 환경을 재설계하는 방식입니다.

    비개발자도 AI 네이티브로 일할 수 있나요?

    가능합니다. 먼저 볼 부분은 코딩 실력보다 문제를 분해하고, 원하는 결과를 명확히 설명하고, 결과를 검토하는 능력입니다. 문서화와 반복 업무 정리부터 시작하면 됩니다.

    디지털 두뇌를 만들 때 가장 먼저 모아야 할 자료는 무엇인가요?

    자주 반복해서 설명하는 자료가 우선입니다. 회의록, 프로젝트 회고, 고객 질문, 글쓰기 톤, 보고서 양식, 의사결정 기준을 모으면 AI가 더 일관된 결과를 만들 수 있습니다.

    에이전트 워크플로우를 만들 때 가장 조심할 점은 무엇인가요?

    검증 기준 없이 실행만 맡기는 것입니다. 목표, 금지사항, 출력 형식, 확인 절차를 함께 줘야 합니다. 중요한 결정은 사람이 최종 검토해야 합니다.

    AI 네이티브 전환은 어디서부터 시작하는 것이 좋나요?

    작은 반복 업무부터 시작하는 것이 좋습니다. 요약, 초안 작성, 자료 정리, 이메일 답변, 표 변환처럼 실패 비용이 낮은 작업부터 자동화하면 안전하게 확장할 수 있습니다.

  • 세컨드 브레인과 LLM Wiki: AI 에이전트 시대의 개인 지식 시스템

    세컨드 브레인과 LLM Wiki: AI 에이전트 시대의 개인 지식 시스템

    AI를 잘 쓰는 사람과 그렇지 않은 사람의 차이는 더 이상 “어떤 모델을 쓰느냐”만으로 갈리지 않습니다. GPT, Claude, Gemini처럼 강력한 모델이 빠르게 평준화되면, 진짜 차이는 그 모델에게 어떤 맥락을 지속적으로 먹이고 있느냐에서 생깁니다. 이 지점에서 세컨드 브레인은 단순 메모 앱이 아니라 AI 에이전트를 나답게 움직이게 하는 기반 시스템이 됩니다.

    원본 영상: 제 2의 두뇌로 나를 100배 스케일링하는 방법 / 채널: 커리어해커 알렉스

    세컨드 브레인은 메모장이 아니라 AI가 읽는 맥락 저장소입니다

    세컨드 브레인 개념 도입
    출처: 커리어해커 알렉스 YouTube 영상 캡처

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

    영상에서 세컨드 브레인은 “모든 지식의 집합체”이자 “AI 에이전트가 접근할 수 있는 지식 창고”로 설명됩니다. 먼저 볼 부분은 기록을 많이 모으는 것이 아닙니다. 내가 어떤 일을 해왔는지, 어떤 판단 기준을 갖고 있는지, 어떤 말투와 관점을 선호하는지를 AI가 다시 꺼내 쓸 수 있게 구조화하는 것입니다.

    일반 메모 앱은 사람이 다시 찾아 읽어야 가치가 살아납니다. 반면 세컨드 브레인은 에이전트가 스스로 탐색하고 연결하고 활용할 수 있어야 합니다. 그래서 영상에서는 노드와 엣지, 온톨로지, 그래프 같은 표현이 반복됩니다. 정보 조각을 따로 보관하는 데서 끝내지 않고, 서로 어떤 관계인지까지 남기는 방식입니다.

    모델보다 먼저 볼 부분은 “나만 가진 컨텍스트”입니다

    커스텀 시스템과 보이스 복제 설명
    출처: 커리어해커 알렉스 YouTube 영상 캡처

    영상의 가장 중요한 메시지는 “AI를 쓴다는 것 자체는 더 이상 차별점이 아니다”라는 말입니다. 모두가 비슷한 모델을 쓰는 상황에서는 같은 질문에 비슷한 답이 나옵니다. 이때 차이를 만드는 것은 개인이나 조직이 쌓아 온 경험, 실패, 관점, 취향, 문서, 대화 기록입니다.

    예를 들어 “마케팅 전략을 짜줘”라고만 하면 누구나 받을 수 있는 일반적인 답이 나옵니다. 하지만 지난 몇 년간의 프로젝트 기록, 고객 반응, 실패 사례, 콘텐츠 톤, 의사결정 기준을 함께 읽힌다면 결과는 달라집니다. 세컨드 브레인은 바로 이 독점적 맥락을 축적하고 재사용하기 위한 장치입니다.

    LLM Wiki와 Obsidian은 세컨드 브레인의 쉬운 출발점입니다

    LLM Wiki 아키텍처 설명
    출처: 커리어해커 알렉스 YouTube 영상 캡처

    영상 후반부에서는 실밸개발자의 유튜브 대본과 자료를 가져와 LLM Wiki 스타일로 정리하는 실습이 이어집니다. 여기서 중요한 구조는 세 가지입니다.

    1. Raw source: 원본 대본, 슬라이드, 문서처럼 가공 전 자료를 보존합니다.
    2. Wiki layer: 원본에서 핵심 개념과 주장, 관계를 뽑아 Markdown 위키로 정리합니다.
    3. Schema/Index: 에이전트가 어디서 무엇을 찾아야 하는지 알 수 있도록 지도와 규칙을 둡니다.

    이 접근은 전통적인 RAG와 조금 다릅니다. 매번 문서를 잘라 임베딩하고 검색하는 구조라기보다, 에이전트가 원본을 읽어 지속적으로 관리되는 위키를 만들어 두는 방식에 가깝습니다. Obsidian은 이 위키를 사람이 보기 좋은 그래프와 검색 UI로 보여주는 도구가 됩니다.

    Obsidian 그래프는 유용하지만, 끝은 아닙니다

    Obsidian은 세컨드 브레인과 자주 함께 언급됩니다. 그래프 뷰, 태그, 백링크, Markdown 기반 관리가 좋기 때문입니다. 특히 처음 시작할 때는 내가 어떤 주제를 많이 다루는지, 어떤 개념이 서로 연결되는지 한눈에 보기 쉽습니다.

    하지만 영상에서는 한계도 분명히 짚습니다. 자료가 수천 개, 수만 개로 늘어나면 사람이 그래프를 직접 둘러보는 방식만으로는 부족합니다. 결국 실전 활용은 에이전트에게 질문하고, 에이전트가 위키와 원본을 탐색해 답을 구성하는 방식으로 가야 합니다. Obsidian은 좋은 인터페이스지만, 세컨드 브레인의 본질은 에이전트가 쓸 수 있는 구조화된 맥락입니다.

    하네스 엔지니어링은 세컨드 브레인과 연결됩니다

    하네스 엔지니어링과 평가 관점
    출처: 커리어해커 알렉스 YouTube 영상 캡처

    하네스 엔지니어링은 모델이 원하는 방향으로 움직이도록 규칙, 컨텍스트, 도구, 검증 절차를 설계하는 일입니다. 세컨드 브레인은 이 하네스의 핵심 재료가 됩니다. 내가 어떤 답변을 좋은 답변으로 보는지, 어떤 스타일을 선호하는지, 어떤 원칙을 지켜야 하는지 저장해 두기 때문입니다.

    영상에서는 평가의 중요성도 강조됩니다. 세컨드 브레인을 만들었다고 끝나는 것이 아닙니다. 질문을 던져 보고, 답변이 내 생각과 맞는지 확인하고, 부족하면 위키 구조나 검색 방식, 규칙을 계속 고쳐야 합니다. 즉 세컨드 브레인은 한 번 만드는 저장소가 아니라 계속 테스트하고 개선하는 성장 시스템입니다.

    개인과 조직은 무엇부터 시작하면 좋을까요?

    AI 네이티브 로드맵 정리
    출처: 커리어해커 알렉스 YouTube 영상 캡처

    처음부터 거대한 지식 그래프나 복잡한 검색 시스템을 만들 필요는 없습니다. 다음 순서로 시작하면 현실적입니다.

    1. 원본을 버리지 말고 모으기

    회의록, 강의안, 블로그 초안, 프로젝트 회고, 고객 질문, 유튜브 대본처럼 나의 사고가 담긴 자료를 한곳에 모읍니다. 먼저 볼 부분은 원본을 보존하는 것입니다.

    2. 주제별로 작은 Markdown 문서 만들기

    한 문서에 모든 것을 넣기보다 개념 단위로 쪼갭니다. 예를 들어 “세컨드 브레인”, “AI 에이전트”, “하네스 엔지니어링”, “콘텐츠 톤”처럼 다시 활용할 수 있는 단위가 좋습니다.

    3. 링크와 태그로 관계를 남기기

    서로 관련된 문서를 연결합니다. 이 관계가 쌓이면 AI가 단편 정보가 아니라 맥락을 따라가며 답할 수 있습니다.

    4. 에이전트에게 읽히고 검증하기

    “내 글쓰기 스타일로 초안을 만들어줘”, “이 자료를 바탕으로 강의안을 구성해줘”, “내 기준에서 부족한 부분을 찾아줘”처럼 실제 작업에 써 봅니다. 결과가 어색하면 규칙과 자료를 다시 정리합니다.

    세컨드 브레인의 진짜 가치는 복리입니다

    세컨드 브레인은 오늘 하루 생산성을 조금 올리는 도구가 아닙니다. 시간이 지날수록 나의 판단, 취향, 지식, 실패 사례가 쌓이고 연결됩니다. 이 축적물이 AI 에이전트와 결합되면, 매번 처음부터 설명하지 않아도 더 나다운 결과를 만들 수 있습니다.

    결국 AI 네이티브가 된다는 것은 최신 도구를 많이 아는 상태가 아닙니다. 나와 조직의 맥락을 자산화하고, 그 맥락을 AI가 계속 활용할 수 있도록 만드는 상태에 가깝습니다. 모델은 바뀔 수 있지만, 잘 쌓은 세컨드 브레인은 다음 모델에도 가져갈 수 있는 나만의 운영체제가 됩니다.

    함께 읽으면 좋은 글

    FAQ

    세컨드 브레인은 Obsidian을 꼭 써야 만들 수 있나요?

    꼭 그렇지는 않습니다. Obsidian은 Markdown, 백링크, 그래프 뷰가 좋아서 시작하기 편한 도구입니다. 하지만 먼저 볼 부분은 도구가 아니라 AI가 읽고 활용할 수 있는 구조화된 맥락입니다.

    RAG와 LLM Wiki는 무엇이 다른가요?

    RAG는 보통 문서를 잘라 임베딩하고 질문 시점에 관련 조각을 검색해 답변에 넣습니다. LLM Wiki는 원본 자료를 에이전트가 지속적으로 읽고 정리해, 재사용 가능한 위키와 인덱스를 만들어 둔다는 점이 다릅니다.

    세컨드 브레인을 만들 때 가장 먼저 해야 할 일은 무엇인가요?

    원본 자료를 한곳에 모으는 일입니다. 그다음 주제별 Markdown 문서로 쪼개고, 문서 사이의 관계를 링크로 남기는 것이 좋습니다.

    개인 브랜딩에도 세컨드 브레인이 도움이 되나요?

    도움이 됩니다. 자신의 글쓰기 톤, 자주 쓰는 표현, 관점, 콘텐츠 주제를 축적하면 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는 만들어진 파일을 채팅방에 전달하는 기능입니다. 함께 쓰면 외부 데이터 수집부터 최종 파일 전달까지 하나의 자동화 흐름으로 만들 수 있습니다.

    참고자료

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

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

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

    Read in English: Claude Skills for Small Business: From Chatbot to Workflow Automation

    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가 반복해서 꺼내 쓸 수 있는 업무 매뉴얼과 자료 묶음을 만드는 일에 가깝습니다.

    Read in English: How to Create AI Skills: Turning Prompts Into Reusable Work Automation

    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가 만들어 준 스킬을 그대로 써도 되나요?

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

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

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

    참고자료

    함께 읽으면 좋은 글

  • Anthropic이 던진 질문: 당신의 개발 조직은 AI 에이전트를 운영할 준비가 됐나

    Anthropic이 던진 질문: 당신의 개발 조직은 AI 에이전트를 운영할 준비가 됐나

    Claude Code London 2026 오프닝 장면
    출처: Claude YouTube 공식 영상 캡처. 리뷰·해설 목적의 인용 이미지입니다.

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

    Claude Code London 2026 오프닝 키노트는 Anthropic이 지금 AI 개발 도구를 어떻게 바라보는지 보여주는 발표였다. 먼저 볼 부분은 단순하다. 과거에는 개발자가 아이디어를 코드로 옮기기까지 긴 설정과 검증 과정을 지나야 했다. 이제는 모델, 플랫폼, 개발 도구가 결합되면서 그 거리가 빠르게 짧아지고 있다.

    이번 발표는 “AI가 코드를 잘 쓴다”는 수준을 넘어선다. Anthropic은 Claude 모델의 판단력, Claude Platform의 에이전트 인프라, Claude Code의 비동기 자동화 기능을 하나의 흐름으로 묶었다. 개발자는 더 이상 한 번의 프롬프트만 잘 쓰는 사람이 아니라, AI가 반복적으로 일하고 검증하도록 작업 환경을 설계하는 사람이 되고 있다.

    Claude Code London 2026이 말한 변화의 핵심

    키노트의 첫 메시지는 개발 경험의 회귀였다. 발표자는 어린 시절 계산기와 HTML을 만지며 느꼈던 “만들면 바로 작동한다”는 감각을 이야기했다. 이후 개발은 빌드 시스템, 패키지 매니저, 설정 파일, 테스트 환경 때문에 복잡해졌다. 하지만 Claude Code London 2026은 AI 코딩 에이전트가 이 복잡성을 다시 낮추고 있다고 설명한다.

    아이디어에서 실행까지의 거리 단축

    발표에서 반복된 표현은 “gap”이다. 아이디어와 실행 사이의 간격, 모델 능력과 실제 업무 적용 사이의 간격, 개인 개발자의 작업과 조직 전체의 자동화 사이의 간격이 모두 줄어들고 있다는 뜻이다.

    Anthropic은 Spotify가 Claude Code를 활용해 대규모 저장소 마이그레이션을 처리하고, 매달 1,000개 이상의 PR을 병합하는 사례를 소개했다. 또한 Binti가 Claude API로 복지 현장의 행정 시간을 줄이고, 위탁가정 승인 과정에서 20일을 단축한 사례도 언급했다. 이 사례들은 AI 코딩 도구가 단순 생산성 도구를 넘어 실제 업무 병목을 줄이는 방향으로 이동하고 있음을 보여준다.

    선형 도입과 지수적 모델 발전의 충돌

    키노트는 모델 능력이 지수적으로 발전하지만, 조직의 AI 도입은 여전히 선형적으로 진행된다고 지적했다. 이 간격이 커질수록 개발자의 역할은 더 중요해진다. 모델이 할 수 있는 일과 실제 제품·업무 안에서 작동하는 일 사이를 연결하는 사람이 개발자이기 때문이다.

    Claude 모델 로드맵: 더 긴 작업, 더 높은 판단력

    Claude Code London 2026 Claude 모델 발전과 작업 지속 시간 설명 장면
    출처: Claude YouTube 공식 영상 캡처. 리뷰·해설 목적의 인용 이미지입니다.

    Anthropic은 Claude 모델의 발전 방향을 “더 좋은 벤치마크 점수”보다 “이전에는 못 하던 일을 할 수 있게 되는 변화”로 설명했다. 발표에서는 Opus 4.7과 Mythos preview가 언급됐고, Claude가 더 긴 작업을 유지하며 모호한 목표도 끝까지 처리하는 방향으로 이동하고 있다고 말했다.

    작업 지속 시간, 즉 task horizon의 확대

    중요한 개념은 task horizon이다. 이는 모델이 흐름을 잃지 않고 얼마나 오래 일할 수 있는지를 뜻한다. 과거 모델이 몇 분 단위 작업을 안정적으로 처리했다면, 현재는 몇 시간 동안 실행되는 에이전트가 보편화되고 있다. Anthropic은 향후 Claude가 지속적으로 실행되는 에이전트가 될 것으로 전망했다.

    예를 들어 “프로젝트 업데이트를 작성해줘”가 아니라 “이번 주 프로젝트가 계획대로 진행되게 관리해줘”라고 맡기는 식이다. “재무 전망을 만들어줘”가 아니라 “전망을 계속 갱신해서 정확하게 유지해줘”가 되는 변화다.

    스캐폴딩은 줄고, 일반 도구의 중요성은 커진다

    발표에서는 에이전트의 루프, 지시문, 도구 같은 모델 외부 구성요소를 scaffolding이라고 불렀다. 흥미로운 지점은 모델이 똑똑해질수록 과한 스캐폴딩이 오히려 방해가 될 수 있다는 설명이다. 더 강한 모델은 파일 시스템, 샌드박스 실행 환경처럼 범용적인 도구를 가지고도 더 멀리 갈 수 있다.

    개발팀 입장에서는 프롬프트를 늘리는 것보다 평가 체계와 제품 프로토타입을 더 어렵게 만드는 일이 중요해진다. 예전에는 실패하던 작업이 새 모델에서 통과되기 시작하면, 그때가 새 기능을 제품화할 신호다.

    Claude Platform: 에이전트를 제품 수준으로 운영하는 인프라

    Claude Code London 2026 Claude Managed Agents와 MCP 터널 설명 장면
    출처: Claude YouTube 공식 영상 캡처. 리뷰·해설 목적의 인용 이미지입니다.

    Claude Code London 2026의 중간 파트는 Claude Platform에 집중했다. 여기서 Anthropic은 기업이 에이전트를 실제 업무에 쓰기 어려운 이유를 두 가지로 정리했다. 첫째, 원하는 결과를 안정적으로 얻는 것이 어렵다. 둘째, 빠르게 출시하면서도 확장성과 품질을 함께 확보해야 한다.

    Advisor strategy: 고성능과 비용의 균형

    Anthropic은 advisor strategy를 소개했다. 실행은 작은 모델이 맡고, 어려운 순간에는 더 큰 모델이 조언하는 구조다. 발표에서는 Haiku 또는 Sonnet급 모델이 실행자로 일하고 Opus가 조언자로 참여하는 식의 패턴을 설명했다.

    이 구조는 고성능 모델만 계속 쓰는 방식보다 비용을 낮출 수 있다. 동시에 작은 모델이 막히는 지점에서 큰 모델의 판단을 빌릴 수 있다. 대량의 에이전트 워크로드를 운영하는 기업에게는 비용과 품질을 동시에 관리하는 현실적인 설계다.

    Claude Managed Agents, self-hosted sandbox, MCP tunnels

    또 다른 먼저 볼 부분은 Claude Managed Agents였다. Anthropic은 이를 에이전트 하네스와 운영 인프라가 결합된 형태로 설명했다. 발표에서는 self-hosted sandbox와 MCP tunnels가 새 기능으로 소개됐다.

    self-hosted sandbox는 에이전트가 코드를 실행할 때 Anthropic의 기본 샌드박스 대신 기업이 관리하는 서버나 클라우드 환경을 사용할 수 있게 한다. MCP tunnels는 내부 네트워크 뒤에 있는 MCP 서버를 외부에 직접 노출하지 않고 Claude Managed Agents가 접근할 수 있게 해준다. 보안과 내부 시스템 연동이 중요한 기업에게 특히 중요한 변화다.

    Claude Code: 프롬프트하는 개발자에서 자동화를 설계하는 개발자로

    Claude Code London 2026 Claude Code와 개발자 생산성 사례 설명 장면
    출처: Claude YouTube 공식 영상 캡처. 리뷰·해설 목적의 인용 이미지입니다.

    후반부는 Claude Code의 변화에 초점을 맞췄다. 발표자는 CLI, IDE, 데스크톱 앱, 클라우드 에이전트 뷰가 서로 다른 개발자 작업 방식을 지원한다고 설명했다. 특히 여러 Claude Code 세션을 동시에 운영하는 “multi-clauding” 흐름이 강조됐다.

    비동기 코딩과 검증의 중요성

    Claude Code가 그냥 코드를 작성하는 도구라면 개발자는 모든 변경을 실시간으로 감시해야 한다. 하지만 발표의 방향은 다르다. Claude가 테스트하고, 브라우저에서 동작을 확인하고, 실패 원인을 추적한 뒤 다시 수정하는 흐름을 보여줬다.

    이 지점에서 검증은 핵심 기능이 된다. AI가 스스로 작업을 확인할 수 있으면 개발자는 에이전트를 실행해 두고 다른 일을 할 수 있다. 결과적으로 동기식 페어 프로그래밍보다 비동기식 작업 위임의 비중이 커진다.

    Routines: Claude가 Claude Code를 프롬프트하는 구조

    Claude Code London 2026 Claude Code Routines와 자동화 설명 장면
    출처: Claude YouTube 공식 영상 캡처. 리뷰·해설 목적의 인용 이미지입니다.

    가장 상징적인 기능은 Routines였다. 발표자는 이를 “higher order prompt”라고 설명했다. 개발자가 매번 Claude Code에 작업을 지시하는 것이 아니라, 특정 조건이나 일정에 따라 Claude Code가 자동으로 실행되도록 루틴을 만든다는 뜻이다.

    예를 들어 GitHub 이슈가 새로 생기면 루틴이 이를 감지하고 작업 세션을 시작한다. CI가 실패하면 autofix가 원인을 분석하고 수정한다. 코드 리뷰나 보안 리뷰 코멘트도 자동으로 처리 대상이 된다. 발표자는 “기본값이 ‘내가 Claude Code를 프롬프트한다’에서 ‘Claude가 Claude Code를 프롬프트하게 한다’로 바뀌고 있다”고 정리했다.

    개발자와 기업이 지금 준비해야 할 것

    Claude Code London 2026의 메시지는 낙관적이지만, 무작정 AI 도구를 붙이라는 이야기는 아니다. 오히려 모델 업그레이드를 흡수할 수 있는 구조를 미리 만들어야 한다는 조언에 가깝다.

    평가와 아키텍처를 먼저 준비해야 한다

    모델 성능은 계속 바뀐다. 그래서 오늘 되는 작업만 기준으로 제품을 설계하면 다음 모델의 능력을 제대로 활용하기 어렵다. 개발팀은 평가 자동화, 회귀 테스트, 에이전트 권한 설계, 샌드박스 정책을 함께 준비해야 한다.

    특히 기업 환경에서는 내부 도구 접근 권한, 코드 실행 범위, 감사 로그, 보안 리뷰가 중요하다. Claude Managed Agents의 self-hosted sandbox와 MCP tunnels가 강조된 이유도 여기에 있다.

    AI 코딩 도구는 개인 생산성에서 조직 운영으로 이동한다

    발표에서 Shopify, Mercado Libre 같은 조직 사례가 언급된 것도 의미가 있다. AI 코딩은 개인 개발자의 자동완성 경험에서 출발했지만, 이제는 조직의 PR 처리, 기술부채 정리, CI 대응, 보안 점검까지 넓어지고 있다.

    국내 기업도 이 흐름을 그냥 “개발자가 편해지는 도구”로만 보면 부족하다. 실제 경쟁력은 에이전트가 안전하게 반복 작업을 맡고, 사람은 우선순위와 품질 판단에 집중하는 운영 구조에서 나온다.

    Claude Code London 2026 요약 체크리스트

    구분 발표 내용 실무적 의미
    모델 Claude의 작업 지속 시간과 판단력 확대 긴 업무를 맡길 수 있는 에이전트 설계 필요
    플랫폼 Managed Agents, advisor strategy, MCP tunnels 비용·보안·확장성을 고려한 운영 구조 필요
    개발 도구 Claude Code Desktop, Agent View, Routines 비동기 코딩과 다중 에이전트 관리가 중요
    조직 적용 PR 자동화, CI autofix, 기술부채 정리 개인 생산성을 넘어 엔지니어링 운영 자동화로 확장
    준비 과제 평가 자동화와 권한 설계 모델 업그레이드를 빠르게 흡수하는 아키텍처 필요

    결론: AI 개발 도구의 다음 단계는 ‘대화’보다 ‘운영’이다

    Claude Code London 2026 키노트의 먼저 볼 부분은 AI와 대화하는 경험이 끝났다는 뜻이 아니다. 대화는 여전히 시작점이다. 주의할 점은 다음 단계는 대화를 반복 가능한 운영 구조로 바꾸는 일이다.

    개발자는 좋은 프롬프트를 쓰는 사람에서 좋은 루틴, 평가, 권한, 샌드박스를 설계하는 사람으로 이동하고 있다. 기업은 AI 도구를 도입하는 수준을 넘어, 모델 능력이 올라갈 때마다 업무 방식도 함께 업데이트할 수 있는 구조를 만들어야 한다.

    이번 키노트는 Anthropic의 제품 발표이면서 동시에 개발 조직을 향한 질문이다. “모델은 이미 더 오래, 더 복잡한 일을 하기 시작했다. 당신의 개발 환경은 그 능력을 받아들일 준비가 되어 있는가?”

    FAQ

    Claude Code London 2026에서 가장 중요한 발표는 무엇인가요?

    가장 중요한 메시지는 Claude 모델, Claude Platform, Claude Code가 하나의 에이전트 실행 환경으로 연결되고 있다는 점입니다. 특히 Routines, Claude Managed Agents, MCP tunnels는 AI 코딩이 개인 도구에서 조직 운영 도구로 확장되고 있음을 보입니다.

    Routines는 일반 자동화와 무엇이 다른가요?

    일반 자동화는 정해진 스크립트를 반복 실행하는 경우가 많습니다. Routines는 Claude Code가 특정 이벤트나 일정에 따라 작업을 시작하고, 상황을 해석하며, 필요한 코딩 작업을 수행하도록 만드는 구조에 가깝습니다.

    국내 개발팀은 무엇부터 준비해야 하나요?

    먼저 AI가 작업해도 되는 범위, 코드 실행 환경, 검증 기준, 보안 정책을 정해야 합니다. 이후 반복적인 PR 처리, 테스트 실패 대응, 문서 업데이트, 기술부채 정리처럼 결과를 검증하기 쉬운 작업부터 적용하는 것이 현실적입니다.

    참고자료

    함께 읽으면 좋은 글

  • 클로드를 떠나는 개발자들: AI 무제한 구독 시대가 끝나고 있다

    클로드를 떠나는 개발자들: AI 무제한 구독 시대가 끝나고 있다

    AI 무제한 구독은 계속될 수 있을까요? 최근 클로드(Claude)를 둘러싼 개발자 이탈 논란이 커졌습니다. 이 논란은 한 서비스의 평판 문제로만 보기 어렵습니다.

    지금까지 우리는 월 구독료만 내면 AI를 꽤 넉넉하게 쓸 수 있다고 생각했습니다. 하지만 그 전제가 흔들리고 있습니다. 개발자에게 먼저 나타난 변화이지만, 일반 사용자도 곧 체감할 수 있습니다.

    AI는 채팅창에서는 가볍게 보입니다. 하지만 뒤에서는 서버, 전력, GPU 연산 비용이 계속 들어갑니다. 그래서 AI 가격은 결국 현실 비용을 따라갈 가능성이 높습니다.

    AI 무제한 구독 논란을 다룬 유튜브 영상 도입 장면
    손에잡히는경제 유튜브 영상 캡처. 클로드 개발자 이탈 논란을 소개하는 도입 장면입니다.

    클로드 이탈 논란, 먼저 볼 부분은 성능이 아니라 ‘의존성’이다

    클로드는 코딩 성능이 좋다는 평가를 받아왔습니다. 그래서 개발자 사이에서 인기가 높았습니다. 그런데 최근 일부 개발자가 클로드 대신 다른 도구를 찾고 있습니다.

    겉으로는 “클로드 인기가 식었다”는 이야기처럼 들립니다. 하지만 먼저 볼 부분은 성능 불만이 아닙니다. 가격 정책, 약관 변경, 외부 도구 제한에 대한 불안이 더 큽니다.

    개발자는 AI를 질문 답변용으로만 쓰지 않습니다. 코드 작성, 자동화, 테스트, 문서화에 깊게 연결합니다. 이런 상황에서 회사가 정책을 바꾸면 업무 흐름 전체가 흔들립니다.

    그래서 이번 이탈은 단순한 서비스 갈아타기가 아닙니다. “한 회사에 너무 묶이면 위험하다”는 신호에 가깝습니다.

    갑작스러운 과금과 외부 도구 제한이 불신을 키웠다

    논란의 도화선은 예상치 못한 과금 사례였습니다. 한 개발자는 이미 고가 구독을 쓰고 있었습니다. 그런데 작업 메모에 들어간 특정 파일명 때문에 추가 요금이 청구됐다는 사례가 소개됐습니다.

    문제는 금액만이 아니었습니다. 사용자가 왜 요금이 발생했는지 이해하기 어려웠습니다. 자신이 얼마나 썼는지도 명확히 파악하기 힘들었습니다.

    AI 무제한 구독과 클로드 과금 논란을 설명하는 장면
    예상치 못한 과금 사례를 설명하는 장면입니다. AI 무제한 구독의 비용 구조가 왜 불신을 만들었는지 보입니다.

    AI 요금이 ‘블랙박스’처럼 느껴지는 순간

    일반 구독 서비스는 비교적 단순합니다. 사용자는 이번 달에 얼마를 내는지 알고 씁니다. 하지만 AI 서비스는 비용 구조가 훨씬 복잡합니다.

    토큰, 호출량, 모델 종류, 외부 도구 연결 방식이 모두 영향을 줍니다. 개발자는 이 구조를 더 민감하게 느낍니다. 챗봇 화면이 아니라 자동화 도구가 AI를 반복 호출하기 때문입니다.

    사용량이 눈에 보이지 않으면 불안이 커집니다. 작은 설정 차이도 비용 문제로 이어질 수 있습니다.

    외부 도구 제한이 준 충격

    외부 도구 사용 제한도 큰 문제였습니다. 일부 개발자는 클로드를 오픈소스 에이전트나 자동화 도구에 연결해 사용했습니다. 그런데 이런 방식이 갑자기 막히면 업무 도구를 하루아침에 바꿔야 합니다.

    AI 도구 전환은 단순한 앱 교체가 아닙니다. 프롬프트 습관, 자동화 스크립트, 팀의 작업 방식이 함께 바뀝니다. 그래서 사용자는 더 강하게 반발합니다.

    구독과 API, 무엇이 다를까?

    이번 논란을 이해하려면 구독과 API의 차이를 알아야 합니다. 일반 사용자는 보통 월 구독료를 냅니다. 그리고 챗봇 화면에서 직접 질문합니다.

    반면 API는 다른 프로그램이 AI를 자동으로 부르는 통로입니다. 사용자는 직접 입력하지 않을 수 있습니다. 앱이나 자동화 도구가 대신 AI를 호출합니다.

    AI 무제한 구독과 API 사용 방식의 차이를 설명하는 장면
    구독 모델과 API 모델의 차이를 설명하는 장면입니다. AI 무제한 구독 논란을 이해하는 핵심 배경입니다.
    구분 일반 구독 API 사용
    사용 방식 사람이 직접 채팅창에서 사용 프로그램이 자동으로 AI 호출
    비용 감각 월정액 중심 사용량 기반 과금 중심
    주요 사용자 일반 사용자, 개인 업무 사용자 개발자, 서비스 운영자, 자동화 사용자
    위험 요소 사용량 제한 변경 호출량 증가에 따른 비용 급증

    문제는 일부 개발자의 사용 방식입니다. 저렴한 구독 계정을 외부 자동화 도구에 연결해 썼습니다. API로 계산하면 훨씬 비싼 사용량이 되는 경우도 있었습니다.

    이 구조가 커지면 AI 회사는 비용을 감당하기 어렵습니다. 결국 구독과 API의 경계가 다시 조정될 수밖에 없습니다.

    AI 무제한 구독은 왜 흔들리고 있나

    AI 무제한 구독이 흔들리는 가장 큰 이유는 비용입니다. 생성형 AI는 질문 하나에도 대규모 연산을 씁니다. 사용자가 많아질수록 회사의 부담도 커집니다.

    초기 AI 서비스는 이용자를 빠르게 모아야 했습니다. 그래서 저렴한 구독 모델을 제공했습니다. 사용자 입장에서는 월 2만~3만 원으로 강력한 AI를 쓸 수 있었습니다.

    하지만 기업 입장에서는 다른 계산이 해야 합니다. 투자금을 바탕으로 비용을 보조한 구조에 가까웠기 때문입니다. 이제는 그 비용을 누가 낼지가 중요한 문제가 됐습니다.

    ‘많이 쓰는 사람’과 ‘가볍게 쓰는 사람’의 가격이 갈라진다

    앞으로는 기본 구독료와 추가 사용량 과금이 더 분리될 가능성이 높습니다. 가볍게 쓰는 사용자는 기존 가격에 가까울 수 있습니다. 반면 장시간 코딩이나 자동화를 맡기는 사용자는 더 많이 낼 수 있습니다.

    이 변화는 통신비와 비슷합니다. 기본요금이 있고, 데이터를 많이 쓰면 높은 요금제를 선택합니다. AI도 비슷한 방향으로 이동하고 있습니다.

    클로드만의 문제가 아니다

    이번 논란을 클로드만의 문제로 보면 흐름을 놓치기 쉽습니다. Cursor 같은 AI 코딩 서비스도 비슷한 요금제 논란을 겪었습니다. 처음에는 무제한에 가까운 사용 경험을 제공했습니다.

    하지만 사용량이 늘자 요금제를 다시 설계해야 했습니다. 오픈AI도 예외는 아닙니다. 지금은 ChatGPT나 Codex가 대안처럼 보일 수 있습니다.

    하지만 AI 기업 전체가 막대한 인프라 비용을 안고 있습니다. 차이는 가격 전환을 얼마나 부드럽게 하느냐입니다. 또 사용자가 납득할 만큼 투명하게 설명하느냐도 더 봐야 합니다.

    결국 업계는 다음 단계로 넘어가고 있습니다. “싸게 많이 쓰게 해주던 단계”에서 “지속 가능한 가격을 찾는 단계”로 이동하는 중입니다.

    개발자들이 오픈소스를 찾는 이유

    개발자들이 오픈소스 도구를 찾는 이유는 그냥 무료라서가 아닙니다. 먼저 볼 부분은 선택권입니다. 특정 회사의 정책 변화에 덜 흔들리는 구조를 만들려는 것입니다.

    여기서 중요한 개념이 벤더 락인(vendor lock-in)입니다. 한 회사 서비스에 너무 깊게 의존하는 상태를 말합니다. 가격이 오르거나 정책이 바뀌어도 쉽게 빠져나오지 못합니다.

    AI 시대의 벤더 락인은 더 강해질 수 있다

    AI 도구는 업무 방식 안으로 깊게 들어옵니다. 어떤 AI에게 어떻게 지시해야 하는지 익혀야 합니다. 팀의 자동화도 특정 모델에 맞춰질 수 있습니다.

    프롬프트, 문서, 작업 결과가 한 서비스에 쌓이면 전환 비용은 더 커집니다. 그래서 여러 도구를 미리 시험하는 일이 더 봐야 합니다. 개발자에게는 이것이 일종의 보험입니다.

    클로드를 당장 버린다는 뜻은 아닙니다. 필요할 때 다른 도구로 옮겨갈 길을 만들어두는 것입니다.

    일반 사용자도 준비해야 할 변화

    이 이야기는 개발자에게서 시작됐습니다. 하지만 일반 사용자에게도 더 봐야 합니다. 앞으로는 사용량과 기능에 따라 요금 차이가 더 커질 수 있습니다.

    문서 작성, 이미지 생성, 코딩, 데이터 분석을 자주 맡기는 사람은 더 빨리 체감할 수 있습니다. AI를 많이 쓰는 사람일수록 요금제 변화를 체크해 두세요.

    AI 무제한 구독 변화가 일반 사용자에게 주는 의미를 정리하는 장면
    개발자 이슈가 일반 사용자에게도 영향을 줄 수 있다는 점을 정리하는 장면입니다.

    지금 해볼 만한 체크리스트

    • 주로 쓰는 AI 서비스의 요금제와 사용량 제한을 확인한다.
    • 중요한 업무는 한 서비스에만 묶어두지 않는다.
    • ChatGPT, Claude, Gemini 등 여러 도구의 장단점을 익혀둔다.
    • 프롬프트와 작업 결과물은 개인 저장소나 문서로 따로 보관한다.
    • 자동화 도구를 쓴다면 예상 비용과 호출량을 주기적으로 확인한다.

    AI는 전기나 통신비처럼 생각하면 이해가 쉽습니다. 편리하지만 공짜는 아닙니다. 많이 쓸수록 비용 구조를 알아야 합니다.

    결론: AI 가격의 ‘정상화’가 시작되고 있다

    클로드 이탈 논란은 일시적인 해프닝으로 끝나지 않을 가능성이 높습니다. 더 큰 흐름은 AI 가격의 정상화입니다. 서비스 가격이 실제 비용에 맞춰 조정되고 있습니다.

    AI 무제한 구독은 사용자에게 매력적입니다. 하지만 기업 입장에서는 지속 가능하지 않을 수 있습니다. 앞으로는 기본 구독, 크레딧, 사용량 기반 과금이 섞일 가능성이 높습니다.

    지금 필요한 태도는 특정 AI를 무조건 떠나는 것이 아닙니다. 내가 쓰는 AI의 비용 구조를 이해해야 합니다. 또 한 회사에 모든 업무를 묶어두지 않는 것이 좋습니다.

    AI 시대의 경쟁력은 좋은 도구를 쓰는 데서만 나오지 않습니다. 언제든 다른 도구로 옮겨갈 수 있는 유연성도 더 봐야 합니다.

    FAQ

    클로드를 지금 당장 그만 써야 하나요?

    그럴 필요는 없습니다. 클로드는 여전히 강력한 AI 도구입니다. 주의할 점은 중요한 업무를 한 서비스에만 의존하지 않는 편이 안전합니다.

    AI 무제한 구독은 완전히 사라질까요?

    완전히 사라진다기보다 제한이 더 명확해질 가능성이 높습니다. 기본 구독은 유지될 수 있습니다. 주의할 점은 고강도 사용, 자동화, 외부 도구 연결에는 추가 요금이 붙을 수 있습니다.

    일반 사용자는 무엇을 확인해야 하나요?

    자신이 쓰는 요금제의 사용량 제한을 체크해 두세요. 고급 모델 제공 범위도 봐야 합니다. 파일, 코딩, 이미지 기능 제한도 함께 확인하는 것이 좋습니다.

    오픈소스 AI 도구가 항상 더 좋은 선택인가요?

    항상 그렇지는 않습니다. 오픈소스는 선택권과 통제력을 줍니다. 하지만 설치와 운영 부담이 있을 수 있습니다. 일반 사용자는 상용 AI와 오픈소스 도구를 함께 비교하는 것이 현실적입니다.

    함께 보면 좋은 글

    참고자료

    함께 읽으면 좋은 글

    이 주제와 함께 읽으면 맥락을 넓히는 데 도움이 되는 thinknote.co.kr의 관련 글입니다.

    Read in English: The End of Unlimited AI Subscriptions: What Claude Pricing Teaches Developers

환영합니다!

서비스 이용을 위해 로그인해주세요.