How to Actually Choose the Right AI Agent

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

How to Actually Choose the Right AI Agent를 중심으로, 모델과 하네스의 역할을 구분하라. 모델은 추론하고 출력을 만들며, 하네스는 파일 접근·명령 실행·결과 관찰을 연결한다. HTML를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 모델과 하네스의 역할을 구분하라. 모델은 추론하고 출력을 만들며, 하네스는 파일 접근·명령 실행·결과 관찰을 연결한다. HTML 생성과 로컬 서버 실행 사이의 간극이 이 차이를 보여준다.
2. 도구의 우열보다 작업 단계별 적합성을 평가하라. 출연자는 Claude Code의 계획을 Codex가 검토하는 조합을 소개하지만, 이는 개인 경험이다. 같은 작업에서 도구 호출·재시도·검증 과정과 최종 산출물을 비교하는 것이 핵심이다.
3. 스킬·컨텍스트·플러그인을 이동 가능한 자산으로 관리하라. 공통 접근 지점을 마련하고 여러 모델에서 시험하되, 스킬 설명과 호출 조건은 환경에 맞게 조정해야 한다.
4. 모델이 발전하면 스킬의 필요성도 다시 시험하라. 월간 감사로 미사용·중복 스킬을 정리하고, 스킬을 적용한 경우와 제외한 경우의 결과를 비교한다. 정체성·규칙·훅은 변화 속도가 다르므로 갱신 주기도 구분한다.
5. 프로젝트별로 환경을 분리하고 사용자의 이해를 유지하라. 규칙은 프로젝트에서 검증한 뒤 필요한 것만 전역으로 올린다. 실패하면 모델·하네스·프로젝트 설정 중 원인을 격리하고, 사용자는 폴더 구조와 산출물 위치를 파악해야 한다.

🧩 배경과 문제 정의

• Claude Code, Codex, Hermes 등 도구가 빠르게 바뀌면서, 지금 만드는 AI 작업 환경과 자산을 이후에도 활용할 수 있는지가 핵심 문제다.
• 모델은 추론과 출력을 담당하지만, 파일 조작·명령 실행·결과 검증은 모델을 둘러싼 실행 환경인 하네스에 의존한다. 에이전트 선택에는 모델 성능뿐 아니라 이 실행 구조도 중요하다.
• 스킬·컨텍스트·플러그인에 담은 전문성을 특정 제공자에 종속시키지 않고, 작업에 맞춰 모델과 하네스를 교체할 수 있어야 한다.
• 모델이 발전하면 기존 스킬과 에이전트가 불필요해지거나 오히려 제약이 될 수 있으므로, 자산의 호환성과 필요성을 지속적으로 점검해야 한다.

🕒 시간순 섹션별 상세정리

1. 모델의 지능을 실제 행동으로 연결하는 하네스

• 읽기·쓰기·파일 편집·Bash 실행은 모델 자체에 내장된 능력이 아니다. 모델이 웹사이트 HTML을 생성하더라도, 컴퓨터와 상호작용할 도구가 없으면 로컬 서버를 실행할 수 없다 [02:24]
• 모델을 두뇌, 주변 실행 도구를 손발로 구분하면 개선 대상이 명확해진다. 주변 실행 환경을 강화할수록 특정 모델에 대한 의존도를 낮출 수 있다 [02:59]

2. 웹 채팅과 Claude Code의 차이는 접근 가능한 작업 환경이다

• 웹 채팅은 조사와 PDF 생성이 가능해도, 외부 플랫폼 호출이나 사용자 컴퓨터의 파일 접근에는 제약이 있을 수 있다. 직접 확인할 수 없는 작업 환경에 대해서는 가정에 의존하게 된다 [04:11]
• Claude Code 하네스는 로컬 컴퓨터와 클라우드 양쪽에 접근해 작업할 수 있다. 향후 Claude 웹 채팅이 사라지고 Claude Code 하네스의 경량 형태인 Cowork로 수렴할 수 있다는 개인적 전망도 드러난다 [04:38]

3. 스킬과 플러그인은 실행·관찰·재시도 능력을 확장한다

• Claude Code는 읽기와 편집 같은 기본 도구를 제공하고, Pi는 직접 하네스를 구성할 수 있는 기본적인 오픈소스 선택지다. 여기에 스킬과 플러그인을 추가하면 사용자의 전문성을 실행 환경에 반영할 수 있다 [05:53]
• 에이전트 루프는 요청을 실행하고, 성공이나 오류를 관찰한 뒤, 그 결과를 바탕으로 다음 행동을 이어가는 구조다. 루프를 안정적으로 지속하는 데는 하네스의 정교함이 중요하고, 모델의 지능은 도구를 적절히 선택하고 사용하는 데 영향을 준다 [06:28]

4. 로컬 랜딩 페이지 실험이 보여주는 생성과 실행의 간극

• LM Studio에서 Qwen 27B에 ‘Prompt Advisors’라는 AI 컨설팅 랜딩 페이지를 만들고 로컬에서 실행하라는 요청을 입력한다. 이 실험 환경에는 컴퓨터를 조작하는 하네스가 없어 서버 실행까지 수행할 수 없다는 설명이다 [07:31]
• 모델은 HTML을 출력할 수 있지만, 같은 요청을 실제 로컬 실행까지 연결하려면 Codex나 Claude Code처럼 실행 도구를 갖춘 환경이 필요하다. 하네스의 역할은 지능적인 텍스트 출력을 사용자가 직접 활용할 결과물로 바꾸는 것이다 [08:24]

5. Clay의 데이터 보강과 반복 가능한 잠재고객 조사

• 협찬 서비스인 Clay는 잠재고객의 이름뿐 아니라 의사결정 권한·연락처·관심사를 파악하기 위한 데이터 보강 및 오케스트레이션 플랫폼으로 묶인다. 250개 이상의 데이터 제공자와 AI 조사 도구에 접근할 수 있다는 설명이다 [09:29]
• 연락할 담당자·업무 이메일·회사 규모를 목록 단위로 조사하고, 한 제공자에서 결과가 없으면 다음 제공자를 조회한다. 조사 로직을 새 잠재고객에도 재사용하면서 각 값의 출처와 비용을 확인할 수 있고, Clay CLI를 통해 Claude Code에서 구성할 수 있다 [09:55]

6. 제공자보다 재사용 가능한 핵심 자산을 우선한다

• 스킬·컨텍스트 파일·플러그인에 축적한 전문성은 다른 하네스와 모델에서도 활용할 수 있다. 특정 제공자에 충성하기보다 자신의 하네스와 자산을 유지하면서 모델을 교체하는 것이 기본 원칙이다 [10:31]
• 스킬을 공개·비공개 모델 모두에서 사용할 수 있도록 시험하고, /poly 스킬로 Claude Code용 스킬을 Codex에 맞게 최적화한다. 모든 모델이 같은 핵심 자산을 찾도록 공통 접근 지점을 두어 전환 비용을 줄인다 [11:30]

7. Claude Code와 Codex는 작업 단계에 따라 조합한다

• 최근 사용 시간의 60%를 Codex에 배분했다는 개인 사례가 나온다. Claude Code는 아이디어와 계획 수립에 강하지만, 지시한 방식 그대로 따르지 않을 때가 있다는 평가다 [12:03]
• Claude Code를 창의적인 예술가, Codex를 외과의사에 비유한다. Claude Code의 계획을 Codex가 검토하고 10차례 상호 검토를 반복하게 해 누락된 조건과 예상하지 못한 문제를 보완하는 방식이다 [12:30]

8. 실행 기록을 활용해 자신만의 하네스를 개선한다

• Hermes는 원하는 모델을 연결하는 하네스이며, 기본 상태에서 Codex와 결과가 다를 수 있다. 원하는 검증 루프를 구현하려면 스킬 파일 추가뿐 아니라 하네스 자체의 조정이 필요하다는 주장이다 [13:51]
• Pi 문서를 에이전트가 읽게 하고, Codex와 Claude Code의 로컬 JSONL 대화 기록에서 도구 호출·검증 방식·실행 순서를 분석하게 한다. 이를 바탕으로 비슷한 작업에서 선호하는 실행 방식을 재현하는 개인 하네스를 만들 수 있다는 접근이다 [14:39]

9. 스킬 이식성은 설명과 호출 조건을 조정해 확보한다

• 스킬은 대체로 YAML에 이름과 설명을 두고, 어떤 사용자 요청에서 호출할지를 명시하는 유사한 구조를 갖는다. 각 제공자의 문서를 비교하면 공통으로 작동하는 스킬을 설계할 수 있다 [17:26]
• Python 코드 자체보다 차이가 생기기 쉬운 부분은 스크립트를 언제, 어떻게 호출할지에 대한 지침이다. 모델마다 놓칠 수 있는 호출 조건을 보완하고 설명을 구체화해 스킬이 선택될 가능성을 높인다 [18:04]

10. 월간 감사로 스킬을 줄이되 사용자의 이해는 유지한다

• 월간 cron 작업으로 전체 환경을 감사하고, 쓰지 않는 스킬을 제거하거나 겹치는 스킬을 통합하며 모델 호환성을 점검한다. 300개를 내려받아 매번 불러오지만 실제로는 5개만 사용하는 식의 비대화를 줄이는 것이 목적이다 [18:40]
• 문서 조사와 정리를 AI에 맡겨도 사용자가 통제권과 이해를 유지해야 한다. 어떤 문서를 제공하고 그 지식을 어떻게 활용할지 판단하면서 AI를 사고 파트너로 사용하는 태도가 중요하다 [19:17]

11. 벤치마크보다 하네스와 결합한 실제 수행을 평가한다

• 같은 작업을 개인 Pi 하네스와 다른 제공자의 환경에서 실행하고, 도구 사용 과정과 최종 결과를 비교하면 자신의 환경에서 빠진 동작을 찾아 개선할 수 있다 [20:05]
• 출연자는 2026년 3월 유출됐다는 Claude Code 하네스의 맵 파일을 4~5일간 살펴본 경험을 근거로, 욕설 감지 정규식과 반응 지침 등 모델을 보조하는 장치가 많았다고 보여준다 [20:29]

12. rot.md로 구성 요소마다 다른 노후화 속도를 관리한다

• rot.md는 정체성·핵심 컨텍스트·스킬·규칙·훅·에이전트 등이 서로 다른 속도로 낡는다는 전제에서 관리한다. 정체성과 목표는 비교적 천천히 변하며, 1~3개월 또는 기업 환경에서는 그 이상 유지될 수 있다는 예시다 [22:41]
• 스킬은 매달 갱신하고, 규칙은 새로운 작업의 한계와 예외를 발견할 때마다 수정한다. 개인 운영 사례에서는 규칙이 매일 바뀌기도 하고, 약 일주일 만에 낡을 수 있다고 본다 [23:25]

13. 모델이 발전하면 기존 스킬의 필요성부터 재검증한다

• Boris Cherny가 모든 스킬을 6개월마다 삭제하라고 했다는 트윗을 출연자가 인용한다. 그 근거는 모델이 발전하면 기존 스킬 없이도 간단한 요청만으로 같은 목표를 달성할 수 있어, 과거의 보조 지침이 오히려 제약이 될 수 있다는 것이다 [24:12]
• 에이전트도 같은 재검토 대상이다. 모델과 메모리가 충분히 발전하면 별도 회계 에이전트 없이 필요한 18~20개 하위 작업을 파악할 수도 있으며, 장기적으로는 단계별 지시보다 모델이 스스로 알 수 없는 특수한 암묵지가 스킬의 핵심으로 남을 수 있다는 전망이다 [25:14]

14. 대화 기록 분석은 상세 스킬에서 한 문장 요청으로 단순화됐다

• 과거에는 대화 파일의 위치와 분석 방법을 스킬로 상세히 알려줘야 했다. 특히 5만 토큰 분량의 기록을 100개씩 한꺼번에 처리해 컨텍스트 창을 넘기지 않도록 분할 방법을 지정했다 [27:02]
• 현재는 대화 기록을 읽고 개선점 15개를 찾으라는 기본 요청만으로도 컨텍스트 사용을 고려해 처리한다는 개인 사례다. 모델이 스스로 수행할 수 있게 된 절차는 상세 스킬에서 제거할 여지가 있다 [27:23]

15. 스킬 축소에는 규칙 강화와 더 큰 과제의 시험이 뒤따른다

• 스킬이 줄면 모델의 문제 해결 자유도는 커지지만, 목표에 도달할 방법을 스스로 찾다가 시스템에 해로운 행동을 할 가능성도 있다는 우려가 나온다 [27:39]
• 이에 대한 대안은 AI 작업 환경의 규칙과 다른 통제 계층이다. 더 적은 스킬과 더 엄격한 규칙만으로 충분해지거나 고정된 에이전트 구성이 불필요해질 가능성은 있지만, 현재 이미 그렇다고 단정하지는 않는다 [28:14]

16. 기존 규칙의 한계를 점검하고 업무별 환경을 분리한다

• 모델의 한계를 충분히 시험하지 못하고 있다는 가능성에서, 목표를 주고 “무엇을 할 수 있는지 보여 달라”는 개방적인 실험을 시작했다. 익숙한 스킬을 무비판적으로 재사용하면 정해진 경로가 모델의 역량을 제한할 수 있다는 문제의식이다. [29:17]
• 하나의 거대한 업무 시스템 대신 약 25개의 독립적인 시스템을 두고 세무·재무, 컨설팅, 교육 콘텐츠 등을 분리한다. 유지 관리 부담은 늘지만, 각 시스템을 감사하는 상위 시스템으로 개별 개선 사항과 공통 개선 사항을 도출한다. [30:19]

17. 실패 원인을 격리하고 전체 구조에 대한 이해를 유지한다

• 프로젝트별 분리는 실험의 영향 범위를 좁히고, 모델·하네스·프로젝트 구성 중 어디에 문제가 있는지 더 빠르게 찾도록 돕는다. 같은 모델이 세무에서는 잘 작동하고 컨설팅에서는 부진하더라도, 원인은 모델이나 스킬이 아니라 해당 프로젝트의 구성일 수 있다. [31:46]
• 실패를 일으킨 실제 변수를 찾아야 학습과 개선이 가능하다. 에이전트가 원인 분석을 도울 수 있어도 사용자는 폴더 구조와 산출물 위치를 알아야 하며, 모든 것을 찾아줄 것이라고 맹신하거나 자신의 이해까지 위임해서는 안 된다. [32:48]

🧾 결론

• 에이전트 선택의 평가 단위는 모델과 실행 환경의 조합이다. 실제 업무를 끝까지 수행하고 검증하는지 확인해야 한다.
• 오래 유지할 자산은 사용자의 전문성과 맥락이다. 이를 특정 제공자와 분리해 관리하면 모델과 하네스를 바꿀 여지가 커진다.
• 환경 개선에는 추가뿐 아니라 제거도 필요하다. 모델이 이미 수행하는 절차를 지침으로 고정하면 역량을 제한할 수 있다.
• 스킬을 줄이는 실험에는 규칙과 통제 계층의 점검이 함께 필요하며, 원인 분석과 전체 구조에 대한 이해는 사용자에게 남아 있어야 한다.

📈 투자·시사 포인트

• AI 도구 도입을 판단할 때 모델 벤치마크와 함께 파일·외부 도구 접근, 검증 루프, 실제 산출물을 평가할 필요가 있다.
• 공통 자산과 스킬의 이식성은 제공자 전환 비용을 줄이는 운영 요소다. 가격과 성능이 바뀔 때 환경 전체를 다시 구성해야 하는지 점검할 수 있다.
• 로컬 모델과 강력한 모델을 업무 난도에 따라 배분하는 방식은 비용·속도 측면의 검토 대상이다. 다만 영상의 로컬 처리 비중은 일반화된 성능 수치로 볼 수 없다.
• 업무별 시스템 분리는 실패 원인을 찾기 쉽게 하지만 유지 관리 부담을 늘린다. 도입 규모를 정할 때 분리의 효과와 감사 비용을 함께 살펴야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• Claude Code의 창의성, Codex의 지시 준수·검증 능력, 사용 시간 배분은 출연자의 체감과 개인 사례다. 모델 버전과 프로젝트 설정이 다른 환경에서도 재현되는지 확인해야 한다.
• 로컬 모델이 일상 업무의 약 80%를 처리한다는 평가와 향후 70~80%를 로컬에서 처리할 수 있다는 전망에는 하드웨어·업무 범위·성공 기준이 충분히 제시되지 않았다.
• Claude 웹 채팅의 Cowork 수렴, 별도 에이전트의 필요성 감소는 전망이다. 현재 확정된 제품 방향이나 보편적인 운영 원칙으로 받아들이기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복 업무 하나와 완료 기준을 정하고, 후보 에이전트에 같은 입력을 제공해 산출물·도구 사용·오류 복구·검증 과정을 비교한다.
• 현재 환경의 모델, 하네스, 스킬, 컨텍스트, 규칙, 훅을 목록화하고 각 요소의 역할과 저장 위치를 기록한다.
• 핵심 스킬을 다른 모델이나 하네스에서 실행해 보고, 누락되는 호출 조건과 설명을 조정한다.
• 새 모델에서는 기존 스킬을 적용한 실행과 제외한 실행을 비교해 유지·수정·제거 여부를 판단한다.

❓ 열린 질문

• 내 업무의 실패는 모델의 추론 한계, 하네스의 도구·검증 부족, 프로젝트 설정 중 어디에서 주로 발생하는가?
• 모델과 하네스를 바꿔도 반드시 보존해야 할 전문성은 무엇이며, 이를 어떤 공통 자산으로 표현할 수 있는가?
• 기존 스킬을 제거해도 성과가 유지되는 기준은 무엇이며, 자유도가 커진 모델을 어떤 규칙으로 통제할 것인가?