개리 탄이 말한 AI 에이전트 운영법: 같은 실수를 막는 스킬화 전략

한눈에 보기

• 원문 출처: 2026년 4월 22일 Garry Tan, 미국 스타트업 투자사 와이컴비네이터 대표가 X에 올린 장문 글
• 핵심 주장: AI 에이전트가 틀릴 때마다 프롬프트를 고치는 식으로는 한계, 스킬 문서와 짧은 코드, 테스트로 바꿔야 재발이 줄어듦
• 대표 사례 1: 오래된 출장 기록을 찾는 질문에서 실시간 API만 뒤지다 실패, 로컬 검색 스킬 calendar-recall로 교정
• 대표 사례 2: 다음 회의까지 남은 시간을 잘못 계산한 문제를 시간 확인 스킬 context-now로 교정
• 큰 흐름: AI 업계의 관심이 더 똑똑한 답변에서 같은 실패를 다시 막는 운영 구조로 옮겨가는 모습
• 실무 결론: 일정 검색, 시간 계산, 금액 계산처럼 답이 정해진 일은 모델에게 맡기기보다 코드로 고정하는 편이 안전

서론

2026년 4월 22일, Garry Tan은 X에 How to really stop your agents from making the same mistakes라는 장문 글을 올렸다. 제목을 우리말로 옮기면 "에이전트가 같은 실수를 반복하지 않게 하려면 어떻게 해야 하나" 정도가 된다.

이 글이 주목받은 이유는 최신 모델 자랑이 아니라 운영 원칙을 다뤘기 때문이다. 요즘 AI 업계에서는 에이전트가 얼마나 긴 일을 대신 해주느냐만큼, 그 에이전트를 얼마나 믿고 맡길 수 있느냐가 더 중요해지고 있다.

특히 AI 에이전트는 사람 대신 여러 단계를 이어서 처리하는 프로그램을 뜻한다. 질문을 받고, 자료를 찾고, 계산하고, 정리해서 답을 내놓는 흐름을 한 번에 맡는 경우가 많다. 그래서 한 번의 실수가 다음에도 반복되면 생산성보다 불신이 먼저 커진다.

이 글의 핵심도 바로 여기에 있다. 개리 탄은 에이전트가 틀릴 때마다 "다음에는 조심해"라고 말하는 식으로는 문제가 풀리지 않는다고 본다. 대신 실패를 작업 설명서, 짧은 스크립트, 테스트로 바꿔 시스템 안에 남겨야 한다고 주장한다.

1. 개리 탄이 먼저 짚은 문제

• 도구는 많음: LangChain, LangSmith처럼 AI 앱을 만들고 점검하는 도구는 이미 다양함
• 빠진 부분: 무엇을 어떤 순서로 고칠지 알려 주는 실전 루프는 생각보다 약함
• 흔한 대응: 프롬프트를 길게 쓰고, 시스템 메시지를 더 붙이고, "실수하지 말라"고 반복하는 방식
• 개리 탄의 판단: 이런 방식은 대화가 길어지고 예외가 늘어날수록 쉽게 흔들림

여기서 LangChain은 AI 앱 개발용 도구 묶음이고, LangSmith는 실행 기록과 평가를 보는 품질 점검 서비스에 가깝다. 개리 탄의 말은 이 도구들이 쓸모없다는 뜻이 아니다. 좋은 부품은 많지만, 그 부품을 어떤 순서로 써야 하는지까지 자동으로 정리해 주지는 않는다는 쪽에 가깝다.

그는 이 상황을 헬스장 회원권에 비유한다. 운동기구는 많아도, 무슨 운동을 언제 어떤 순서로 해야 하는지 계획이 없으면 몸이 좋아지기 어렵다는 뜻이다. AI 에이전트도 마찬가지라는 이야기다.

 

반응형

2. 첫 번째 사례: 데이터는 가까이에 있었는데 에이전트가 멀리 돌았다

• 질문: 거의 10년 전의 출장 기록을 찾아 달라는 요청
• 첫 반응: 실시간 캘린더 API 호출
• 첫 실패: 너무 오래된 일정이라 검색이 막힘
• 두 번째 시도: 이메일 검색으로 우회
• 두 번째 실패: 결과가 많기만 하고 결론이 흐림
• 실제 답: 이미 로컬 저장소에 정리된 캘린더 파일에서 바로 확인 가능

개리 탄이 강조한 포인트는 "정답을 못 찾았다"가 아니다. 문제는 정답을 찾는 경로를 잘못 골랐다는 데 있다. 오래된 일정 검색은 이미 저장된 파일을 찾으면 되는 일인데, 에이전트는 이를 실시간 API와 추론으로 처리하려 했다.

원문에 따르면 그의 로컬 저장소에는 2013년부터 2026년까지 이어지는 캘린더 파일 3,146개가 이미 정리돼 있었다. 다시 말해 답은 멀리 있지 않았다. 에이전트가 먼저 확인해야 할 곳을 건너뛴 것이다.

이 실수 뒤에 등장한 것이 calendar-recall이다. 이것은 과거 일정이나 오래된 이벤트를 찾을 때 먼저 로컬 자료를 뒤지게 만드는 스킬이다. 개리 탄은 여기에 아주 강한 규칙을 붙였다.

• 과거 일정 검색: 로컬 지식 저장소부터 확인
• 미래 일정과 최근 48시간: 실시간 캘린더 API 사용
• 에이전트 행동: 생각부터 하지 말고, 정해진 검색 스크립트를 먼저 실행

이때 중요한 개념이 결정형 코드다. 뜻은 어렵지 않다. 같은 입력을 넣으면 같은 결과가 나오는 짧은 코드다. 과거 일정 검색처럼 정답 경로가 분명한 일은 모델이 머리로 추정하는 것보다, 이런 코드가 훨씬 빠르고 흔들림이 적다.

3. 두 번째 사례: 28분이 아니라 88분이었다

• 문제 상황: 에이전트가 "다음 회의까지 28분 남았다"고 답변
• 실제 상황: 회의까지 남은 시간은 88분
• 오류 원인: 시간대 계산을 모델이 머리로 처리
• 이미 있던 도구: 현재 시각과 다음 일정을 계산하는 context-now 스크립트
• 교정 방식: 시간 관련 답변 전에는 이 스크립트를 무조건 먼저 실행

이 사례는 더 직관적이다. 시간 계산은 복잡한 창의 작업이 아니라 비교적 단순한 계산에 가깝다. 그런데 에이전트가 이를 코드 대신 추론으로 처리하면서 정확히 한 시간 차이를 냈다.

개리 탄은 이 장면을 두 영역으로 나눠 설명한다.

• 추론 영역: 문맥을 읽고 적당한 답을 만들어 내는 모델의 장점
• 확정 계산 영역: 검색, 시간 계산, 수치 계산처럼 코드가 더 안정적인 영역

시간 계산은 당연히 두 번째에 가깝다. 그래서 수정도 단순했다. "시간에 민감한 말을 할 때는 context-now를 먼저 실행한다"는 규칙을 스킬에 넣었다. 프롬프트를 더 길게 쓰는 대신, 잘못 계산할 기회 자체를 줄여 버린 셈이다.

위 그림은 원문 전체를 가장 짧게 정리한 흐름이다. 에이전트가 틀렸다면 그 장면을 그냥 넘기지 않고, 규칙 문서, 스크립트, 테스트, 정기 점검으로 이어야 다음 실패를 줄일 수 있다는 뜻이다.

https://www.gamsgo.com/partner/Z6TgE

GamsGo

 

4. Skillify를 쉬운 말로 풀면

• 이름 뜻: Skillify, 실패를 스킬로 바꾸는 습관
• 쉬운 정의: 같은 실수를 다시 하지 않도록 작업 설명서와 코드, 검사 규칙으로 남기는 방식
• 핵심 효과: "다음엔 잘해"가 아니라 "다음엔 같은 경로로 틀리기 어렵게" 만드는 것
• 왜 중요한가: 에이전트는 사과는 잘해도, 실수를 오래 기억하지는 못하기 때문

원문에서 스킬은 사람이 보는 매뉴얼과 비슷하다. 어떤 질문에서 이 규칙을 써야 하는지, 어떤 순서로 움직여야 하는지, 어떤 실수를 피해야 하는지가 적혀 있다. 말하자면 에이전트용 작업 설명서다.

여기에 짧은 스크립트가 붙으면 더 강해진다. 설명서가 "이럴 때는 이렇게 해"를 알려 준다면, 스크립트는 실제 계산과 검색을 대신 처리한다. 여기에 테스트가 더해지면, 시간이 지나도 그 규칙이 아직 살아 있는지 확인할 수 있다.

이 구조가 중요한 이유는 에이전트가 대개 이번 대화에서는 똑똑해 보여도 다음 상황에서 같은 실수를 반복할 수 있기 때문이다. Skillify는 그 실수를 일회성 해프닝으로 남기지 않고, 다음 버전의 운영 규칙으로 바꾸는 방식이다.

5. 어려운 용어는 이렇게 보면 된다

• Skill, 스킬: 에이전트가 읽는 작업 설명서
• calendar-recall: 예전 일정이나 오래된 기록을 찾는 검색 스킬
• context-now: 지금 시각과 곧 있을 일정을 확인하는 시간 점검 스킬
• Resolver, 리졸버: 어떤 질문에서 어떤 스킬을 꺼낼지 정한 연결 규칙
• LLM 평가: 모델 답이 기대한 기준에 맞는지 보는 시험
• 스모크 테스트: 처음 질문부터 마지막 결과까지 전체 흐름이 끊기지 않는지 보는 최종 확인
• DRY 점검: 비슷한 규칙이나 스킬이 겹치지 않는지 확인하는 검사

이 설명을 붙여서 다시 읽으면, 개리 탄의 글은 결코 어려운 구조론이 아니다. "에이전트를 더 영리하게 만드는 법"보다 "에이전트를 덜 틀리게 만드는 운영 방식"에 가깝다.

6. 원문의 10단계 점검표, 실무에서는 이렇게 읽으면 된다

• 문서화: 언제 어떤 스킬을 켤지 적어 두기
• 코드화: 검색, 시간 계산, 수치 계산은 스크립트로 고정
• 검사화: 단위 테스트와 통합 테스트로 실제 동작 확인
• 연결화: 질문이 들어왔을 때 올바른 스킬로 연결되는지 점검
• 운영화: 결과 저장 위치와 정기 점검 규칙까지 정해 두기

개리 탄은 원문에서 이를 10개 항목으로 더 잘게 나눈다. 스킬 문서, 결정형 코드, 단위 테스트, 통합 테스트, 모델 평가, 리졸버 연결, 리졸버 평가, 도달 가능성 검사, 스모크 테스트, 파일링 규칙이 그것이다.

중요한 것은 숫자 10 자체가 아니다. 스킬을 하나 만들었다고 끝나는 게 아니라, 그 스킬이 실제로 호출되는지, 같은 영역의 다른 스킬과 겹치지 않는지, 전체 흐름이 중간에서 끊기지 않는지까지 봐야 한다는 점이 핵심이다.

7. 왜 Hermes Agent와 GBrain이 같이 나왔나

• Hermes Agent: 경험에서 스킬을 만들어 내는 자기 개선 구조를 가진 에이전트
• GBrain: 개리 탄이 소개한 오픈소스 지식 엔진
• 원문 의도: 스킬을 만드는 능력만으로는 부족하고, 그 스킬을 꾸준히 점검하는 운영 구조까지 필요하다는 주장

이 대목은 조금 거리를 두고 읽을 필요가 있다. 글 후반부는 중립적인 비교표라기보다, 개리 탄이 선호하는 설계 철학을 설명하는 부분에 가깝다. 그래서 LangChain, Hermes Agent, GBrain을 둘러싼 평가는 사실 판정보다 운영 방식의 차이로 읽는 편이 더 정확하다.

그럼에도 실무에 남는 메시지는 분명하다. 스킬을 자동으로 만드는 기능이 있어도, 그 스킬을 읽기 쉽게 유지하고, 테스트로 검증하고, 중복과 충돌을 주기적으로 걷어내는 과정이 없으면 시간이 갈수록 품질이 무너질 수 있다는 이야기다.

8. 왜 지금 중요한가

• 업계 흐름 변화: 프롬프트 요령보다 운영 구조가 더 중요한 단계로 이동
• 품질 기준 변화: 더 화려한 답변보다 같은 실패를 줄이는 체계가 중요
• 실무 기준 변화: 모델 성능만 볼 것이 아니라, 계산과 검색을 어떻게 코드로 빼낼지까지 봐야 함
• 팀 운영 변화: 에이전트를 똑똑하게 쓰는 일과 안전하게 믿는 일을 분리해서 관리하는 흐름

이 변화는 생각보다 크다. 예전에는 "프롬프트를 잘 쓰면 된다"는 이야기가 중심이었지만, 지금은 그것만으로는 부족하다는 공감대가 커지고 있다. 일정 검색, 시간 계산, 금액 계산처럼 틀리면 바로 문제 되는 일은 점점 더 모델 밖으로 빼서 코드와 규칙으로 처리하는 쪽으로 가고 있다.

개리 탄의 글이 화제가 된 이유도 여기 있다. 최신 모델 발표문이 아닌데도 업계가 반응한 것은, 많은 팀이 이미 비슷한 문제를 겪고 있기 때문이다. 에이전트는 분명 빨라졌지만, 그 속도를 믿을 수 있는 구조는 아직 덜 갖춰진 경우가 많다.

결론

개리 탄의 2026년 4월 22일 X 글은 한 문장으로 정리된다. AI 에이전트에게 같은 실수를 반복하지 말라고 부탁하지 말고, 다시 반복하기 어려운 구조를 만들어 두라는 말이다.

그 구조를 그는 Skillify라고 불렀다. 이름은 낯설 수 있지만 뜻은 분명하다. 실패를 스킬 문서로 남기고, 계산과 검색은 짧은 코드로 고정하고, 테스트로 살아 있는지 계속 확인하자는 것이다.

AI 에이전트를 실제 업무에 붙이려는 팀이라면 이 글의 가치는 크다. 더 똑똑한 모델을 찾는 일만큼, 지금 쓰는 모델이 같은 실수를 다시 하지 않게 만드는 운영법이 중요해졌다는 점을 아주 선명하게 보여 주기 때문이다.

참고 자료

• How to really stop your agents from making the same mistakes - Garry Tan, X, 2026년 4월 22일
• Garry Tan의 GBrain 저장소 - GitHub, 2026년 4월 22일 확인
• Nous Research의 Hermes Agent - GitHub, 2026년 4월 22일 확인
• LangSmith 공식 문서 - LangChain, 2026년 4월 22일 확인