GPT Actions와 Skill의 차이

어떤 팀은 에이전트에게 일을 시키다가 어느 순간 이런 유혹에 빠진다. "어차피 API도 붙일 수 있는데, 절차 설명까지 전부 GPT 안에 몰아넣으면 더 간단하지 않을까?" 처음에는 그 말이 맞아 보인다. 하나의 Custom GPT 안에 지식도 넣고, 액션도 붙이고, 지침도 길게 써 두면 마치 만능 비서를 만든 것처럼 느껴진다.

하지만 실무에서는 여기서부터 자주 꼬인다. 왜냐하면 무엇을 해야 하는지, 어떻게 판단해야 하는지, 어느 시스템에 어떤 형식으로 요청해야 하는지가 서로 다른 층위의 문제이기 때문이다. 이 셋을 한 덩어리로 묶으면 처음에는 편하지만, 수정과 디버깅이 갑자기 어려워진다.

이번 장에서 다룰 핵심은 단순하다. Action을 잘 쓰려면, 먼저 무엇을 Action 밖에 둘지 결정해야 한다. 이 기준이 서면 설계가 훨씬 또렷해진다.

GPT Actions는 무엇을 담당하는가

OpenAI의 GPT Actions는 Custom GPT가 외부 애플리케이션과 API에 연결되어 실제 요청을 수행하게 만드는 구조다. 개발자는 OpenAPI 스키마와 인증 방식을 설정하고, GPT는 그 스키마를 바탕으로 어떤 API를 호출할지 판단한다.¹²

여기서 중요한 점은 Actions가 본질적으로 실행 인터페이스라는 사실이다. 다시 말해, Action은 에이전트에게 "이런 형식의 요청을 보내면 이런 응답을 받을 수 있다"는 계약을 제공한다. 사용자는 자연어로 말하지만, 에이전트는 내부적으로 스키마에 맞는 구조화된 입력을 만들어 API를 호출한다.¹

이 구조를 사람으로 비유하면 이렇다. Skill이 업무 매뉴얼이라면, Action은 회사 전산 시스템의 입력 화면이다. 매뉴얼은 "출장비 정산은 영수증을 확인하고, 규정 위반 항목을 제외하고, 합계가 맞는지 검산한 뒤 제출하라"를 가르친다. 반면 입력 화면은 "날짜, 금액, 항목, 첨부파일"을 정확히 넣게 만든다.

둘 다 필요하지만, 같은 것이 아니다.

Skill은 절차 문서이고, Action은 호출 계약이다

이 책에서 계속 강조해 온 Skill은 에이전트가 일을 어떤 순서와 기준으로 수행할지를 담은 절차 패키지다. ChatGPT의 Skills 역시 특정 작업에서 자동으로, 때로는 여러 개가 함께 사용될 수 있는 지침과 지원 리소스를 담는다.³ 반면 Action은 외부 API를 호출하는 기능층이다.¹

이 차이를 한 문장으로 줄이면 다음과 같다.

Skill은 일을 잘하는 방법을 가르치고, Action은 일을 실제 시스템에 반영하는 통로를 제공한다.

둘을 비교하면 더 선명해진다.

• Skill은 판단 기준, 체크리스트, 예외 처리, 출력 형식을 다룬다.

• Action은 엔드포인트, 파라미터, 인증, 응답 구조를 다룬다.

• Skill은 자연어 중심의 절차 설계에 가깝고, Action은 스키마 중심의 실행 설계에 가깝다.

실무에서 문제가 생기는 지점도 여기다. 절차를 Action 스키마에 우겨 넣으려 하면 API 설명이 비대해지고, 반대로 실행을 전부 자연어 지침에 맡기면 에이전트는 "할 수 있을 것 같은 말"만 하고 실제 시스템 변경은 못 한다.

왜 Custom GPT에 지식과 Action을 함께 붙이면 강력하면서도 위험한가

Custom GPT는 원래부터 "지식 + 지침 + 기능"을 하나로 묶기 쉬운 제품이다. GPT 안에 설명 문서도 넣고, 말투도 정하고, 액션도 연결할 수 있다. 이 방식은 빠르게 시제품을 만드는 데 매우 유리하다. 실제로 OpenAI도 GPT와 에이전트 계열 제품을 점점 더 작업 수행형 구조로 확장하고 있다.⁴⁵

장점부터 보자. 하나의 GPT 안에 회사 문체, FAQ, API 실행 기능을 묶어 두면 사용자는 별도 시스템을 배울 필요 없이 자연어로 요청만 하면 된다. 예를 들어 "지난주 고객 문의 중 환불 건만 요약해서 팀장에게 보낼 메일 초안 만들어 줘" 같은 요청이 가능해진다. 내부 문서를 참고해 답하고, 액션으로 티켓 시스템을 조회하고, 최종 메일 초안까지 이어질 수 있다.

하지만 장점이 곧 함정이 되기도 한다. 모든 것을 한 GPT 안에 넣으면 다음 문제가 생긴다.

• 절차 수정과 API 수정이 함께 얽힌다.

• 어떤 실패가 지침 문제인지, 어떤 실패가 스키마 문제인지 분리하기 어렵다.

• 특정 GPT 안에 노하우가 갇혀 재사용성이 떨어진다.

• 비슷한 작업이 늘어날수록 GPT가 비대해지고, 설명이 서로 충돌한다.

쉽게 말해 작은 가게에서는 만능 서랍이 편하다. 하지만 조직이 커지면 계산대, 레시피북, 재고 시스템을 분리해야 운영이 된다. Custom GPT도 마찬가지다.

절차는 Skill, 실행은 Action으로 나누면 왜 쉬워지는가

가장 안정적인 설계 원칙은 이것이다.

절차는 Skill, 실행은 Action

이 문장을 실무 언어로 바꿔 보자.

Skill에는 이런 것을 넣는다.

• 어떤 입력이 충분한지 판단하는 기준

• 어떤 순서로 정보를 확인할지

• 예외 상황에서 무엇을 먼저 의심할지

• 사용자 확인이 필요한 순간

• 최종 출력 형식과 품질 체크 기준

Action에는 이런 것을 넣는다.

• 어떤 API를 호출할지

• 어떤 파라미터가 필요한지

• 어떤 인증이 필요한지

• 어떤 응답이 돌아오는지

• 실패 시 어떤 오류 코드가 발생하는지

예를 들어 "채용 후보자 평가" 업무를 생각해 보자. 이 업무에는 지원서 읽기, 평가 기준 적용, 금지 질문 회피, 채용 단계별 코멘트 작성, 최종 평가 기록 저장이 있다. 여기서 평가 기준과 금지 규칙은 Skill에 가깝다. 반면 ATS에 후보자 상태를 저장하거나 인터뷰 일정을 생성하는 일은 Action에 가깝다.

이렇게 나누면 좋은 점이 크다. 평가 기준이 바뀌어도 Action 스키마는 건드리지 않아도 된다. 반대로 ATS 공급사가 바뀌어 API가 바뀌어도 평가 절차는 그대로 살릴 수 있다. 즉, 업무 지식과 시스템 연결의 변경 주기가 다르기 때문에 분리하는 것이 맞다.

Action 밖에 두어야 하는 것부터 먼저 정하라

많은 팀이 "어떤 Action을 만들까?"부터 생각한다. 하지만 더 좋은 질문은 "무엇을 Action에 넣지 말아야 할까?"다.

Action 밖에 두는 것이 좋은 대표 항목은 다음과 같다.

• 판단 기준이 자주 바뀌는 정책

• 회사 문체, 리뷰 스타일, 보고 형식 같은 조직 규칙

• 승인 조건, 금지사항, 예외 처리 로직

• 실패 시 대체 경로와 재시도 원칙

• 출력 품질을 검토하는 체크리스트

이런 것은 스키마보다 문서가 더 잘 다룬다. API는 엄격해야 하지만, 절차는 설명 가능해야 한다. API는 "값"을 받지만, Skill은 "맥락"을 다룬다.

실제로 Action 안에 너무 많은 정책을 밀어 넣으면 이상한 일이 벌어진다. 스키마는 분명 멀쩡한데, 현업은 "이 GPT는 우리 팀 방식대로 일하지 않는다"고 말한다. 반대로 Skill에 절차가 잘 정리되어 있으면 액션은 상대적으로 단순해도 충분히 쓸 만해진다.

스키마가 좋다고 자동으로 좋은 실행이 되지는 않는다

OpenAPI 스키마는 Action의 뼈대다. 이름, 설명, 파라미터, enum, 응답 구조 같은 요소가 에이전트가 API를 선택하고 값을 채우는 데 큰 영향을 준다.¹ 그래서 스키마 설계는 중요하다.

하지만 좋은 스키마가 곧 좋은 업무 수행을 보장하지는 않는다. 이유는 간단하다. 스키마는 "무슨 버튼이 있는지"를 알려 주지만, "언제 어떤 버튼을 눌러야 하는지"까지는 충분히 가르치지 못하기 때문이다.

예를 들어 다음과 같은 액션이 있다고 하자.

operationId: createExpenseReport
summary: Create an expense report
parameters:
  - employee_id
  - amount
  - category
  - attachment_url

이 스키마만 보면 에이전트는 보고서를 만들 수는 있다. 하지만 아래 질문에는 답해 주지 못한다.

영수증이 없으면 보류해야 하나? 교통비와 식비를 한 보고서에 합쳐도 되나? 금액이 규정 한도를 넘으면 먼저 사용자 확인을 받아야 하나? 첨부파일이 흐리면 재업로드를 요청해야 하나?

이런 것은 Action 설명문보다 Skill의 절차로 풀어야 한다. 즉, 스키마는 문을 열어 주지만, Skill이 길을 안내한다.

자연어 지시와 Action 스키마가 충돌할 때

실전에서는 꽤 자주 이런 장면이 나온다. 사용자는 "급하니까 바로 발송해 줘"라고 말한다. 그런데 Skill에는 "외부 발송 전에는 반드시 승인받는다"가 적혀 있다. 혹은 자연어 지시에는 "최근 3개월 데이터만"이라고 적혀 있는데, Action 스키마는 기본값으로 최근 12개월을 조회하도록 되어 있다.

이때 중요한 것은 우선순위를 미리 설계하는 것이다. 충돌을 런타임에서 감으로 해결하게 두면 결과가 흔들린다.

가장 실용적인 우선순위는 다음과 같다.

첫째, 보안·승인·규정 관련 Skill 지침이 우선한다. 사용자가 서둘러도 승인 없는 발송은 막아야 한다.

둘째, Action 스키마의 필수 제약은 존중한다. 필수 필드가 없으면 먼저 보충 질문을 해야 한다.

셋째, 기본값은 Skill의 맥락 규칙으로 덮어쓴다. 예를 들어 보고서는 항상 최근 4주 기준이라는 팀 규칙이 있다면, 액션 기본값보다 Skill 규칙이 먼저다.

넷째, 애매하면 실행보다 확인을 택한다. 이 원칙 하나만 지켜도 사고가 크게 줄어든다.

이 우선순위를 문장으로 적어 두면 충돌이 줄어든다. 예를 들면 이렇게 쓸 수 있다.

## Action Use Policy
- 사용자의 요청이 발송·삭제·상태 변경을 포함하더라도, 승인 규칙이 있으면 승인 규칙을 우선한다.
- Action 스키마의 필수 필드가 비어 있으면 추정하지 말고 사용자에게 확인한다.
- 스키마 기본값이 Skill의 업무 기준과 다르면 Skill 기준을 우선한다.
- 규정 위반 가능성이 있으면 실행하지 말고 사유를 설명한다.

이 네 줄은 짧지만, 실제로는 에이전트의 사고방식을 꽤 많이 안정시킨다.

Skill이 Action을 잘 쓰게 만드는 문장들

많은 사람이 Action 설명에만 신경 쓰고 Skill 쪽 문장을 대충 적는다. 그러나 Action 활용 품질은 대체로 Skill 지침에서 갈린다. 특히 다음과 같은 문장은 매우 유용하다.

1. 호출 전 확인 조건

Action을 쓰기 전에 무엇을 점검해야 하는지 적는다.

예를 들면 "이메일 발송 Action 호출 전, 수신자·제목·첨부 여부·민감정보 포함 여부를 점검한다" 같은 문장이다.

2. 호출 후 검증 조건

Action이 성공했다고 끝내지 않는다. 응답이 돌아온 뒤 무엇을 검토할지 적는다.

예를 들면 "회의 생성 Action 호출 후 시간대, 참석자 수, 중복 일정 여부를 다시 확인한다"가 있다.

3. 실패 분류 규칙

모든 실패를 한 덩어리로 보면 안 된다. 인증 실패인지, 입력 누락인지, 일시적 타임아웃인지, 비즈니스 규칙 위반인지 구분해야 한다.

4. 사용자 확인 문구

확인이 필요한 상황에서 어떤 톤으로 물을지도 정해 두면 좋다. 이 문장이 없으면 에이전트는 지나치게 두루뭉술하거나, 반대로 너무 기계적으로 묻는다.

결국 Skill은 Action을 감싸는 사용 설명서이자 안전 가드레일이다.

Action 실패를 Skill 안에 어떻게 녹여야 하나

API는 실패한다. 네트워크가 흔들리고, 인증이 만료되고, 파라미터가 빠지고, 외부 서비스가 잠깐 멈춘다. 문제는 많은 설계가 성공 경로만 적고 끝난다는 점이다.

좋은 Skill은 실패를 이미 예상하고 있다. 특히 다음 다섯 가지를 포함하면 훨씬 안정적이다.

• 어떤 실패는 자동 재시도할지

• 몇 번까지 재시도할지

• 어떤 실패는 즉시 사용자에게 확인할지

• 대체 경로가 있는지

• 실패한 뒤 결과물을 어느 수준까지라도 남길지

예를 들어 "고객 응대 메일 초안 작성 후 CRM에 저장"하는 Skill이라면 다음처럼 적을 수 있다.

## Failure Handling
1. CRM 저장 Action이 타임아웃되면 1회 재시도한다.
2. 인증 오류가 발생하면 재시도하지 말고 사용자에게 연결 갱신이 필요하다고 안내한다.
3. 필수 필드 누락 오류가 발생하면 누락 항목을 목록으로 정리해 사용자에게 묻는다.
4. 저장에 실패하더라도 작성한 메일 초안은 본문에 유지한다.
5. 외부 발송 Action은 실패 시 자동 재시도하지 않는다. 중복 발송 위험이 있기 때문이다.

이런 문장은 화려하지 않다. 하지만 실전에서는 바로 이런 평범한 문장이 사고를 막는다.

재시도는 만능이 아니라 성격 구분이 핵심이다

실패 처리에서 가장 흔한 실수는 "안 되면 다시 해 봐"를 자동화하는 것이다. 어떤 실패는 재시도에 강하지만, 어떤 실패는 재시도할수록 더 위험해진다.

읽기 작업은 비교적 재시도에 안전하다. 검색, 조회, 목록 가져오기 같은 작업은 일시적인 타임아웃이면 한 번 더 시도해 볼 수 있다. 반면 쓰기 작업은 조심해야 한다. 발송, 결제, 생성, 삭제는 중복 실행이 큰 사고가 될 수 있다.

그래서 Skill 지침에는 이런 구분이 필요하다.

• 조회형 Action: 짧은 간격으로 제한적 재시도 가능

• 생성형 Action: 중복 생성 위험 확인 후 재시도

• 발송형 Action: 자동 재시도 금지, 사용자 확인 우선

• 삭제형 Action: 재시도보다 승인과 로그 확인 우선

이 분류가 있으면 에이전트는 실패를 단순한 기술 오류가 아니라 업무 위험도로 해석하게 된다.

사용자 확인은 귀찮은 단계가 아니라 신뢰를 만드는 장치다

ChatGPT 계열 에이전트는 점점 더 실제 작업을 수행하는 방향으로 발전하고 있다. 웹 상호작용, 문서 생성, 메시지 처리 같은 흐름이 한 제품 안에서 이어지기 시작했다.⁴⁵ 이럴수록 중요한 것은 "얼마나 많이 자동화했는가"보다 "어디서 멈출 줄 아는가"다.

사용자 확인이 특히 필요한 순간은 분명하다.

• 외부 발송이나 제출 직전

• 금전, 일정, 계정 상태가 바뀌는 순간

• 민감정보가 포함된 출력물을 다룰 때

• 추정값으로 실행할 가능성이 있을 때

좋은 Skill은 확인을 막연하게 요청하지 않는다. 확인의 근거를 함께 제시한다. 예를 들어 이렇게 말하게 할 수 있다.

현재 3명의 수신자와 PDF 첨부 1건이 포함된 메일 초안을 준비했습니다. 고객 이름과 계약 금액이 포함되어 있어 발송 전 확인이 필요합니다. 승인하면 발송하고, 승인하지 않으면 초안만 유지합니다.

이 문장은 단순한 "보내도 될까요?"보다 훨씬 낫다. 무엇을 하려는지, 왜 확인이 필요한지, 승인하지 않으면 어떻게 되는지가 모두 담겨 있기 때문이다.

Custom GPT에서 자주 통하는 설계 패턴

이제 전체 구조를 한 번 묶어 보자. 실무에서 자주 잘 작동하는 패턴은 대체로 세 가지다.

첫 번째는 지식형 GPT + 제한된 Actions 패턴이다. 이 방식은 사내 문서나 정책을 많이 참고하지만, 외부 변경은 제한적으로만 하게 한다. 예를 들어 HR 안내 GPT, 제품 FAQ GPT, 영업 자료 정리 GPT에 잘 맞는다.

두 번째는 절차 Skill + 실행 Action 패턴이다. 업무 절차가 명확하고, API 호출이 몇 개 안 되는 경우 특히 강력하다. 리드 정리, 회의 일정 생성, 고객 응대 초안 작성, 재무 보고 입력 같은 반복 업무가 여기에 해당한다.

세 번째는 초안 자동화 + 마지막 승인 패턴이다. 수집, 정리, 변환, 초안 작성은 자동화하고, 발송이나 상태 변경만 사람 확인을 거친다. 대부분의 조직에서는 이 패턴이 가장 현실적이다.

이 셋의 공통점은 하나다. 에이전트에게 전권을 주지 않고, 잘할 수 있는 부분과 멈춰야 하는 부분을 구분한다. 바로 이 구분이 설계를 성숙하게 만든다.

나쁜 설계와 좋은 설계

차이를 더 또렷하게 보기 위해 같은 업무를 두 방식으로 비교해 보자. 업무는 "고객 문의를 분류하고, 답변 초안을 만들고, 필요하면 티켓 상태를 변경하는 것"이다.

나쁜 설계는 이렇다. Custom GPT instructions에 모든 정책을 길게 넣고, Action에는 티켓 생성·수정·발송 API를 한꺼번에 붙인다. 그리고 "적절히 판단해서 처리하라"고 적는다. 이런 구조에서는 에이전트가 언제 상태를 바꿔도 되는지, 언제 사람 확인을 받아야 하는지 흔들리기 쉽다.

좋은 설계는 다르다. Skill에는 문의 분류 기준, 금지 표현, 답변 톤, escalation 조건, 승인 규칙을 적는다. Action에는 getTicket, updateTicketStatus, draftReply 같은 좁고 분명한 기능만 둔다. 그리고 Skill에서 "불만 강도 높음 + 환불 요청 + 법적 표현 포함"이면 상태 변경 전에 사용자 확인을 받도록 적는다.

차이는 명확하다. 전자는 만능처럼 보이지만 예측이 어렵고, 후자는 구조가 분리되어 디버깅이 쉽다.

Action 중심 사고에서 Skill 중심 사고로 옮겨가야 한다

에이전트를 처음 설계할 때는 누구나 실행 기능에 먼저 눈이 간다. API를 붙이면 뭔가 갑자기 살아 움직이는 느낌이 나기 때문이다. 하지만 오래 운영할수록 진짜 차이는 Action 개수보다 Skill 품질에서 난다.

Action은 손이다. Skill은 일하는 습관이다. 손이 아무리 많아도 습관이 엉망이면 결과는 흔들린다. 반대로 손이 몇 개 안 되어도 절차가 좋으면 꽤 많은 일을 안정적으로 처리한다.

그래서 설계 순서는 이렇게 가는 편이 좋다.

먼저 업무 절차를 쓴다. 그다음 승인과 실패 규칙을 쓴다. 그 뒤에 필요한 Action만 최소 단위로 붙인다. 마지막으로 자연어 지시와 스키마 제약이 충돌할 때의 우선순위를 정한다.

이 순서를 지키면 에이전트는 "API를 많이 아는 모델"이 아니라 "조직의 방식대로 실행하는 시스템"에 가까워진다.

결국 좋은 Action 설계는 잘 만든 비실행 영역에서 시작된다

이번 장의 핵심을 다시 정리해 보자. GPT Actions는 외부 시스템과 연결되는 강력한 실행 메커니즘이다. 하지만 그 힘은 단독으로 쓰일 때보다, 잘 설계된 절차 지식과 함께 쓰일 때 비로소 실무 품질을 만든다.¹²³

Custom GPT에 지식과 액션을 함께 넣는 방식은 빠르고 편리하다. 그러나 모든 것을 한 상자에 몰아넣으면 금세 비대해지고, 충돌과 디버깅 비용이 커진다. 그래서 더 좋은 기준이 필요하다. 그 기준이 바로 이것이다.

절차는 Skill에 두고, 실행은 Action에 둔다.

그리고 한 줄 더 붙이면 완성된다.

실패, 재시도, 승인 규칙도 Action이 아니라 Skill 지침에서 먼저 설계한다.

이렇게 하면 Action은 얌전해지고, Skill은 똑똑해진다. 그리고 에이전트는 그 둘 사이에서 훨씬 덜 흔들린다. 바로 그 안정감이, 질문에 답하는 AI와 실제로 일을 끝내는 AI를 가르는 차이다.

참고

¹GPT Actions - OpenAI

²Configuring actions in GPTs - OpenAI Help Center

³Skills in ChatGPT - OpenAI Help Center

⁴Introducing workspace agents in ChatGPT - OpenAI

⁵Introducing ChatGPT agent: bridging research and action