Thinknote

jhshin@thinknote.co.kr

[태그:] MCP

MCP와 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 에이전트를 제대로 일하게 만드는 법

    하네스 엔지니어링이 온다: 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가 제대로 해낼 수 있는 환경을 설계해야 합니다. 하네스 엔지니어링은 바로 그 환경을 만드는 일입니다.

    참고자료

    함께 읽으면 좋은 글

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

  • 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 agent 변화: OpenClaw가 보여주는 실행형 AI의 다음 단계

    AI agent 변화: OpenClaw가 보여주는 실행형 AI의 다음 단계

    AI agent 변화는 “질문에 잘 답하는 챗봇”에서 “실제 일을 처리하는 실행형 AI”로 이동하고 있습니다. 예전의 AI가 글을 요약하고 코드를 제안하는 데 강했다면, 이제 사용자는 메일을 정리하고, 일정을 확인하고, 브라우저에서 작업을 진행하고, 테스트 결과까지 보고하는 AI를 기대합니다.

    실행형 AI 에이전트와 OpenClaw 워크플로우를 표현한 기술 이미지
    AI 에이전트가 여러 도구와 작업 흐름을 연결해 실행하는 모습을 표현한 이미지

    Read in English: AI Agent Evolution: What OpenClaw Shows About the Next Step Beyond Chatbots

    OpenClaw는 이런 흐름을 이해하기 좋은 사례입니다. OpenClaw는 사용자가 직접 운영하는 오픈소스 개인 AI assistant이자 self-hosted gateway를 지향합니다. 여러 메신저 채널, 에이전트 세션, 브라우저 제어, 도구, 메모리, 백그라운드 작업을 묶어 “대화하는 AI”를 “움직이는 AI”에 가깝게 만듭니다.

    이 글은 OpenClaw를 중심으로 AI agent 변화가 어디로 향하는지 짚어봅니다. 먼저 볼 부분은 단순한 기능 추가가 아닙니다. AI가 어떤 채널에서 호출되고, 어떤 도구를 안전하게 사용하며, 어디까지 책임 있게 실행할 수 있는지가 앞으로의 경쟁 기준으로 떠오르고 있습니다.

    왜 지금 AI agent 변화가 중요한가

    챗봇형 AI는 지식 접근 방식을 크게 바꿨습니다. 검색어를 조합하지 않아도 질문하면 요약과 설명을 얻을 수 있고, 문서 초안이나 코드도 빠르게 만들 수 있습니다. 하지만 실제 업무에서는 자주 마지막 단계가 남습니다.

    예를 들어 “이번 주 회의 일정 정리해줘”라는 요청은 단순한 설명으로 끝나지 않습니다. 캘린더 확인, 참석자 파악, 충돌 일정 판단, 메시지 작성, 필요하면 발송까지 이어져야 합니다. 챗봇이 방법을 알려주는 것과 에이전트가 실제 흐름을 처리하는 것은 느낌부터 다릅니다.

    답변 품질보다 실행 품질이 중요해진다

    AI agent 변화가 중요한 이유는 경쟁 기준이 바뀌기 때문입니다. 과거에는 “어떤 모델이 더 정확하게 답하는가”가 중심이었다면, 이제는 “어떤 시스템이 안전하게 도구를 쓰고 작업을 완료하는가”가 중요해지고 있습니다.

    Anthropic의 computer use는 모델이 화면을 보고, 커서를 움직이고, 클릭하고, 입력하는 방향을 보여줬습니다. OpenAI Agents SDK는 에이전트, 도구, 세션, guardrails, human-in-the-loop 같은 실행 구조를 문서화하고 있습니다. MCP(Model Context Protocol)는 AI 애플리케이션이 파일, 데이터베이스, 업무 도구와 연결되는 표준 인터페이스로 주목받고 있습니다.

    이 흐름을 묶어 보면 방향은 분명합니다. AI는 더 이상 대화창 안에만 머물지 않습니다. 업무 시스템, 브라우저, 로컬 파일, 메신저, API와 연결되어 실행자로 확장되고 있습니다.

    OpenClaw는 AI agent 변화에서 무엇을 보여주는가

    OpenClaw는 공식적으로 개인 AI assistant와 gateway를 전면에 내세웁니다. 사용자는 하나의 Gateway를 실행하고 Telegram, Slack, Discord, WhatsApp 같은 여러 채널에서 AI assistant를 호출할 수 있습니다. 공식 문서 기준으로 OpenClaw는 self-hosted, multi-channel, agent-native, open source라는 특성을 강조합니다.

    이 구조가 흥미로운 이유는 OpenClaw가 단순한 “AI 앱”보다 “AI 운영 레이어”에 가깝기 때문입니다. 사용자는 특정 웹앱에 들어가 AI를 쓰는 것이 아니라, 이미 쓰는 커뮤니케이션 채널에서 AI를 호출합니다. 그 뒤에서는 세션, 도구, 브라우저, 파일, 플러그인, 메모리 같은 실행 환경이 연결됩니다.

    OpenClaw는 정답이 아니라 관찰 렌즈다

    OpenClaw가 모든 사용자에게 맞는 정답이라는 뜻은 아닙니다. self-hosted 방식은 자유도가 큰 대신 설치, 운영, 보안 설정의 책임도 사용자에게 있습니다. 개발자나 파워유저에게는 매력적인 선택지일 수 있지만, 비기술 사용자에게는 관리 부담이 클 수 있습니다.

    그래서 OpenClaw는 홍보 대상이라기보다 변화의 관찰 렌즈로 보는 것이 적절합니다. OpenClaw를 살펴보면 멀티채널, 도구 사용, 브라우저 제어, 지속 실행, 권한 관리, 오픈소스 생태계라는 AI agent 변화의 핵심 축이 한 번에 보입니다.

    AI agent 변화 1: AI는 채팅창 밖으로 나온다

    많은 AI 서비스는 여전히 별도 웹사이트나 앱에서 시작합니다. 사용자는 해당 서비스에 접속하고, 프롬프트를 입력하고, 결과를 복사해 다른 업무 도구로 옮깁니다. 이 방식은 지식 작업에는 유용하지만 실제 업무 흐름에서는 마찰이 생깁니다.

    OpenClaw식 접근은 다릅니다. 사용자는 자신이 이미 쓰는 채널에서 AI를 부릅니다. 메신저에서 지시하고, 에이전트는 뒤에서 필요한 세션과 도구를 사용합니다. 작은 차이처럼 보이지만, 실무에서는 AI를 사용하는 빈도와 맥락을 바꾸는 변화입니다.

    AI는 별도 앱보다 업무 채널에 가까워진다

    업무 도구의 성공은 기능만으로 결정되지 않습니다. 사용자가 자주 머무는 위치에 있어야 합니다. 이메일, 메신저, 이슈 트래커, 캘린더, 문서 도구는 이미 업무의 기본 동선입니다.

    AI agent가 이 동선 안으로 들어오면 사용자는 “AI 앱을 열어야 한다”는 부담 없이 필요한 순간에 호출할 수 있습니다. 이 점에서 OpenClaw의 멀티채널 구조는 AI assistant가 앞으로 어떤 모습으로 확장될지 보입니다.

    AI agent 변화 2: 답변형 AI에서 실행형 AI로 이동한다

    챗봇형 AI는 “무엇을 해야 하는지”를 잘 설명합니다. 실행형 AI agent는 “그 일을 실제로 처리하는 데” 초점을 둡니다. 이 차이는 브라우저, 파일, 외부 API, 개발 도구, 업무 SaaS와 연결될 때 분명해집니다.

    예를 들어 고객 문의 대응을 생각해볼 수 있습니다. 챗봇은 답변 문안을 작성합니다. 실행형 에이전트는 문의 내용을 읽고, 고객 정보를 조회하고, 환불 정책을 확인하고, 답변 초안을 만든 뒤, 사람이 승인하면 발송까지 이어갈 수 있습니다.

    개발 업무에서도 흐름은 비슷합니다. 에이전트는 오류 로그를 읽고, 테스트를 실행하고, 수정안을 만들고, PR 초안을 준비하는 식으로 역할을 넓힐 수 있습니다. 이때 먼저 볼 부분은 “한 번에 모든 일을 자동화하는 것”이 아니라, 사람이 검토할 수 있는 단위로 실행 범위를 설계하는 것입니다.

    브라우저와 컴퓨터 사용 능력이 중요해진다

    실제 업무의 상당 부분은 API만으로 끝나지 않습니다. 관리자 페이지에 로그인해야 하거나, 웹 폼을 작성해야 하거나, 특정 화면에서 정보를 체크해 두세요. 그래서 computer use와 browser control은 AI agent 변화에서 중요한 축입니다.

    OpenClaw의 브라우저 관련 문서는 에이전트가 별도의 Chrome, Brave, Edge, Chromium 프로필을 제어할 수 있는 구조를 설명합니다. 먼저 볼 부분은 개인 브라우저와 분리된 전용 프로필을 사용하고, 작은 로컬 제어 서비스를 통해 브라우저를 관리하는 방식입니다. 이는 실행 능력을 높이는 동시에 보안 경계도 세워야 한다는 점을 보입니다.

    AI agent 변화 3: 먼저 볼 부분은 모델보다 운영체계다

    AI agent를 도입할 때 흔히 모델부터 비교합니다. 어떤 모델이 더 똑똑한지, 코딩을 더 잘하는지, 추론이 더 좋은지가 중요해 보입니다. 물론 모델 성능은 여전히 더 봐야 합니다. 하지만 실행형 에이전트에서는 모델만으로 충분하지 않습니다.

    에이전트가 실제 일을 하려면 세션 관리, 메모리, 도구 권한, 작업 큐, 파일 접근 범위, 로그, 실패 복구, 승인 절차가 해야 합니다. 모델이 뛰어나도 이 운영체계가 약하면 업무 자동화는 위험하거나 불안정해집니다.

    OpenClaw의 gateway 관점이 주는 힌트

    OpenClaw의 gateway 구조는 AI assistant를 한 번의 대화가 아니라 계속 켜져 있는 운영 환경으로 다루게 합니다. 여러 채널에서 들어오는 요청을 받아 에이전트 세션으로 연결하고, 필요한 도구와 기능을 붙이는 방식입니다.

    이 구조는 기업 도입에도 중요한 힌트를 줍니다. 기업에서 AI agent를 쓰려면 “어떤 모델을 쓸 것인가”와 함께 “누가 어떤 채널에서 요청할 수 있는가”, “어떤 도구를 실행할 수 있는가”, “민감한 작업은 승인 단계를 거치는가”, “실패하면 누가 확인하는가”를 설계해야 합니다.

    챗봇형 AI와 실행형 AI agent 비교

    구분 챗봇형 AI 실행형 AI agent
    주된 역할 질문 답변, 요약, 초안 작성 업무 흐름 수행, 도구 실행, 결과 보고
    사용자 접점 AI 서비스 웹/앱 메신저, IDE, 브라우저, 업무 도구
    기억 방식 대화 세션 중심 지속 메모리, 작업 기록, 사용자 환경 맥락
    실행 방식 사용자가 결과를 복사해 직접 처리 에이전트가 도구·API·브라우저를 사용
    위험 요소 부정확한 답변, 환각 권한 오남용, 계정 접근, 데이터 유출, 자동 실행 실패
    필요한 통제 출처 확인, 프롬프트 개선 권한 분리, 로그, 승인, 샌드박스, 보안 정책

    이 표에서 보듯 AI agent 변화의 본질은 기능 추가가 아닙니다. 책임 범위의 변화입니다. 챗봇은 틀린 답을 할 수 있지만, 실행형 에이전트는 틀린 행동을 할 수 있습니다. 그래서 실행 능력과 통제 능력은 함께 발전해야 합니다.

    AI agent 변화 4: 개인 AI 비서와 업무 자동화의 경계가 흐려진다

    OpenClaw가 흥미로운 또 하나의 이유는 “개인 비서”와 “업무 자동화 도구”의 경계를 흐린다는 점입니다. 개인 AI assistant는 일정, 메일, 메시지, 파일, 브라우저 작업을 다룰 수 있습니다. 그런데 이 작업들은 개인 생산성에만 머물지 않습니다.

    예를 들어 개인 메신저에서 “오늘 회의 자료 정리해줘”라고 요청하면, 에이전트는 문서 폴더를 확인하고, 이전 회의록을 읽고, 캘린더 일정을 참고하고, 요약본을 만들어 팀 채널에 공유할 수 있습니다. 개인 비서처럼 시작했지만 결과는 팀 운영 자동화에 가까워집니다.

    AI 시대에 사람이 준비해야 할 역량도 이와 연결됩니다. 그냥 AI를 쓰는 법보다, 어떤 일을 AI에 맡기고 어떤 판단은 사람이 가져가야 하는지 구분하는 능력이 더 봐야 합니다. 관련 관점은 AI 시대 인간의 가치에서도 함께 살펴볼 수 있습니다.

    권한 경계가 흐려질 때 리스크도 커진다

    문제는 권한입니다. 개인 계정, 회사 계정, 고객 정보, 결제 정보, 관리자 페이지가 하나의 에이전트 환경에 섞이면 위험이 커집니다. 에이전트가 편리할수록 더 많은 권한을 주고 싶어지지만, 권한이 넓을수록 실수의 비용도 커집니다.

    그래서 개인용 에이전트와 업무용 에이전트는 원칙적으로 분리하는 것이 좋습니다. 브라우저 프로필, API 키, 파일 접근 범위, 채널 권한, 로그 보존 정책을 따로 설계해야 합니다. AI agent 변화는 생산성의 변화이면서 동시에 접근제어 설계의 변화입니다.

    AI agent 변화 5: 오픈소스 agent 생태계가 커지는 이유

    OpenClaw는 오픈소스라는 점에서도 의미가 있습니다. AI agent는 사용자의 파일, 계정, 브라우저, 업무 채널에 깊이 연결될 수 있습니다. 이런 도구일수록 사용자는 내부 구조를 확인하고, 필요한 기능을 직접 붙이고, 데이터가 어디로 가는지 통제하고 싶어합니다.

    오픈소스 agent 생태계는 빠른 실험에 유리합니다. 커뮤니티가 채널 플러그인, 스킬, 자동화 패턴, 보안 설정을 공유할 수 있습니다. 특정 벤더의 닫힌 제품에 종속되지 않고, 로컬 또는 자체 서버에서 운영할 수 있다는 점도 매력입니다.

    오픈소스는 안전을 자동 보장하지 않는다

    주의할 점은 오픈소스라는 사실만으로 안전해지는 것은 아닙니다. 오히려 에이전트 생태계에서는 커뮤니티 스킬과 플러그인을 설치할 때 공급망 리스크가 생깁니다. 잘못된 플러그인은 파일을 과도하게 읽거나, 외부 서버로 데이터를 전송하거나, 의도치 않은 명령을 실행할 수 있습니다.

    그래서 OpenClaw 같은 오픈소스 agent를 검토할 때는 기능보다 권한 모델을 먼저 봐야 합니다. 어떤 플러그인이 어떤 파일과 네트워크에 접근하는지, 브라우저 세션은 격리되는지, 토큰 인증과 로컬 바인딩은 설정되어 있는지 체크해 두세요.

    OpenClaw식 에이전트 도입 전 체크리스트

    실무에서 OpenClaw 또는 유사한 실행형 AI agent를 검토한다면 다음 질문부터 확인하는 것이 좋습니다.

    1. 이 에이전트가 반드시 처리해야 할 업무는 무엇인가?
    2. 단순 답변이 아니라 실제 실행이 필요한 단계는 어디인가?
    3. 연결할 채널은 Telegram, Slack, Discord, 이메일, 사내 메신저 중 무엇인가?
    4. 파일, 브라우저, 캘린더, 메일, 개발 도구 중 어떤 권한이 필요한가?
    5. 민감 정보가 포함된 작업은 사람 승인 후 실행되는가?
    6. 브라우저 프로필은 개인 브라우저와 분리되어 있는가?
    7. API 키와 토큰은 어디에 저장되고 누가 접근할 수 있는가?
    8. 에이전트가 수행한 작업 로그를 나중에 감사할 수 있는가?
    9. 실패하거나 잘못 실행했을 때 중단·복구 절차가 있는가?
    10. 개인용 에이전트와 회사 업무용 에이전트를 분리했는가?

    이 체크리스트의 먼저 볼 부분은 “얼마나 많은 일을 시킬 수 있는가”보다 “어디까지 맡겨도 되는가”입니다. 실행형 AI agent는 권한 설계가 곧 제품 설계입니다.

    AI agent 보안: 실행 능력만큼 통제 능력이 필요하다

    AI agent 변화에서 가장 중요한 주제는 보안입니다. 챗봇이 잘못된 답변을 하면 사용자가 검토하고 수정할 수 있습니다. 하지만 에이전트가 실제 계정으로 로그인하고, 파일을 읽고, 이메일을 보내고, 결제를 진행한다면 오류의 영향은 훨씬 커집니다.

    특히 브라우저를 사용하는 에이전트는 프롬프트 인젝션에 노출될 수 있습니다. 웹페이지의 악의적 문구가 에이전트에게 “이전 지시를 무시하고 데이터를 전송하라”고 유도할 수 있습니다. 사람이 보기에는 단순한 문장이어도, 에이전트에게는 지시처럼 작동할 수 있습니다.

    최소 권한과 격리가 기본이다

    실행형 AI agent를 안전하게 쓰려면 최소 권한 원칙이 해야 합니다. 에이전트에게 처음부터 모든 파일, 모든 계정, 모든 채널 접근을 주면 안 됩니다. 업무별로 별도 계정과 브라우저 프로필을 만들고, 필요한 폴더와 API만 허용하는 방식이 좋습니다.

    또한 중요한 작업에는 human-in-the-loop를 둬야 합니다. “초안 작성”과 “발송”은 다른 권한입니다. “견적서 분석”과 “계약서 제출”도 다른 권한입니다. AI agent가 제안하고 사람이 승인하는 단계가 있어야 기업 환경에서 신뢰를 얻을 수 있습니다.

    앞으로의 AI agent 경쟁은 어디서 갈릴까

    앞으로 AI agent 경쟁은 세 가지 축에서 갈릴 가능성이 높습니다. 첫째는 모델 성능입니다. 복잡한 지시를 이해하고, 긴 문맥을 유지하고, 도구 사용 중 오류를 회복하려면 강한 모델이 해야 합니다.

    둘째는 도구 생태계입니다. 에이전트는 혼자 일하지 않습니다. 캘린더, 메일, 문서, 데이터베이스, 브라우저, 개발 도구, 사내 시스템과 연결되어야 합니다. MCP 같은 표준화 흐름은 이 연결 비용을 낮추는 방향으로 중요해질 수 있습니다.

    셋째는 안전한 실행 환경입니다. 샌드박스, 권한 분리, 감사 로그, 승인 절차, 계정 격리, 비밀정보 관리가 약하면 기업 도입은 어렵습니다. 개인 사용자에게도 마찬가지입니다. AI가 할 수 있는 일이 늘어날수록 “하지 말아야 할 일”을 막는 설계가 더 봐야 합니다.

    한국 사용자와 기업에 주는 시사점

    한국 기업과 개인 사용자에게도 이 변화는 빠르게 다가올 수 있습니다. 카카오톡, Slack, Teams, 이메일, 그룹웨어, 전자결재, ERP, CRM 같은 업무 채널에 AI agent가 연결되는 순간 생산성 변화는 커집니다.

    하지만 국내 환경에서는 개인정보보호, 내부망, 문서 보안, 계정 권한, 전자결재 승인 체계가 더 봐야 합니다. 그래서 OpenClaw식 실험을 하더라도 처음부터 전사 자동화로 확장하기보다, 낮은 위험의 반복 업무부터 시작하는 것이 현실적입니다. 공개자료 요약, 회의록 정리, 테스트 실행, 초안 작성, 일정 후보 정리처럼 사람이 최종 승인하는 업무가 좋은 출발점입니다.

    결론: AI agent 변화의 본질은 책임 있는 실행이다

    AI agent 변화는 그냥 더 자연스러운 대화를 의미하지 않습니다. 먼저 볼 부분은 AI가 실제 업무 환경과 연결되어, 사용자를 대신해 제한된 범위의 행동을 수행한다는 점입니다. OpenClaw는 이 방향을 잘 보여주는 사례입니다. 여러 채널에서 호출되고, 도구와 브라우저를 사용하며, 지속 실행 환경을 갖춘 AI assistant는 챗봇과 다른 종류의 제품입니다.

    하지만 실행 능력은 책임을 동반합니다. 에이전트가 더 많은 일을 할수록 권한 설계, 브라우저 격리, 로그, 승인 절차, 플러그인 검증이 더 봐야 합니다. 앞으로 성공적인 AI agent는 단지 똑똑한 답변을 하는 시스템이 아니라, 안전하게 맡길 수 있는 실행 파트너가 될 것입니다.

    지금 시작한다면 거창한 자동화보다 작은 업무 하나를 고르는 것이 좋습니다. 반복적이고, 실패 비용이 낮고, 사람이 결과를 검토할 수 있는 작업부터 에이전트화해보세요. AI agent 변화의 가치는 한 번에 모든 일을 맡기는 데 있지 않습니다. 신뢰할 수 있는 실행 범위를 조금씩 넓혀가는 데 있습니다.

    FAQ

    OpenClaw는 일반 챗봇과 무엇이 다른가요?

    일반 챗봇은 주로 질문에 답하거나 문서를 작성합니다. OpenClaw는 여러 메시징 채널, 에이전트 세션, 도구, 브라우저 제어, 메모리 같은 실행 환경을 연결해 실제 작업 수행에 초점을 둡니다. 주의할 점은 설치와 운영 책임은 사용자에게 더 많이 있습니다.

    AI agent 변화에서 가장 중요한 기술은 무엇인가요?

    하나만 고르기는 어렵습니다. 모델 성능, 도구 호출, 브라우저/컴퓨터 사용, 메모리, MCP 같은 연결 표준, guardrails, 권한 관리가 함께 더 봐야 합니다. 실행형 에이전트는 단일 기능보다 전체 운영 구조가 더 봐야 합니다.

    기업이 바로 OpenClaw 같은 에이전트를 도입해도 될까요?

    바로 핵심 업무에 투입하기보다는 낮은 위험의 반복 업무부터 검증하는 것이 좋습니다. 파일 접근 범위, 브라우저 격리, API 권한, 로그, 승인 절차를 먼저 설계해야 합니다. 특히 고객정보, 결제, 계약, 인사정보처럼 민감한 업무는 human-in-the-loop가 해야 합니다.

    실행형 AI agent는 사람을 대체하나요?

    단기적으로는 사람의 반복 작업을 줄이고 업무 보조 역할을 강화할 가능성이 높습니다. 하지만 중요한 판단, 승인, 예외 처리, 책임 소재는 여전히 사람이 맡아야 합니다. 특히 보안과 권한이 얽힌 업무에서는 완전 자동화보다 책임 있는 반자동화가 현실적입니다.

    참고자료

    함께 읽으면 좋은 글

환영합니다!

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