챗GPT 맞춤 GPT 만들기: GPTs 빌더와 스킬 활용

챗GPT 맞춤 GPT는 웹에서 GPTs 영역을 열고 Create를 눌러 만들면 됩니다. 핵심은 예쁘게 꾸미는 것보다 무슨 일을 맡길지 1개로 좁히고, 그 역할에 맞게 Instructions, Knowledge, Capabilities, 공유 범위를 분리해서 설계하는 것입니다.

또 하나 많이 헷갈리는 점이 있습니다. GPT 빌더와 Skills는 같은 기능이 아닙니다. GPT 빌더는 특정 목적용 맞춤 GPT를 만드는 도구이고, Skills는 반복 작업을 재사용 가능한 워크플로로 묶어 팀 안에서 돌리기 좋은 별도 기능입니다.

이 글에서는 처음 만드는 사람 기준으로 빌더 화면에서 어디를 채워야 하는지, 스킬은 언제 같이 써야 하는지, 테스트와 팀 공유는 어떻게 이어지는지까지 한 번에 정리합니다.

지금 바로 이해해야 할 핵심: 맞춤 GPT는 이렇게 나뉩니다

처음부터 복잡하게 보일 필요는 없습니다. 맞춤 GPT를 만들 때는 먼저 전용 도우미를 만들지, 아니면 반복 작업 규칙을 스킬로 표준화할지를 나누면 대부분의 혼선이 줄어듭니다.

구분	GPTs 빌더	Skills
핵심 목적	특정 역할을 맡는 맞춤 GPT 만들기	반복 작업을 재사용 가능한 워크플로로 묶기
접근 위치	ChatGPT의 GPTs 영역에서 Create	프로필 메뉴의 Skills 페이지 또는 Skills 에디터
잘 맞는 예	문서 질의응답, 사내 안내, 고객 응대 초안, 규칙형 작성	회의 요약 규칙, 검토 체크리스트, 반복 보고서 작성 흐름
공유 방식	비공개, 링크 공유, 워크스페이스 공유, GPT Store 공개	워크스페이스 공유 또는 라이브러리 배포 중심
주의점	요금제, 권한, 공개 조건, Actions 정책 확인 필요	현재 일부 업무용 플랜 중심의 별도 기능이며 베타 성격이 남아 있음

정리하면 “하나의 전용 GPT를 만든다”면 빌더, “여러 사람이 같은 방식으로 반복 작업한다”면 스킬 쪽이 더 맞습니다.

GPTs 빌더에서 꼭 채워야 할 설정 항목

빌더에서 중요한 것은 많아 보이지만, 실제로는 이름/설명/대화 시작문, Instructions, Knowledge, Capabilities, Apps 또는 Actions만 제대로 나눠도 기본기가 잡힙니다.

1. 이름, 설명, 대화 시작문은 “찾기 쉬움”을 담당합니다

이름은 검색 결과, 공유 링크, GPT 목록에서 가장 먼저 보이는 정보입니다. 그래서 멋있는 이름보다 무슨 일을 하는지 바로 보이는 이름이 좋습니다.

설명은 누구를 위한 GPT인지와 어떤 작업을 돕는지 한 줄로 보여주는 영역입니다. 대화 시작문은 사용자가 처음 들어왔을 때 무엇을 물어볼 수 있는지 알려주는 예시이므로, 실제 사용 상황을 그대로 적는 편이 좋습니다.

2. Instructions는 행동 규칙, Knowledge는 참고 자료입니다

가장 흔한 실수는 규칙을 파일에 넣고, 참고 자료를 지시문에 길게 써버리는 것입니다. 행동 방식, 말투, 출력 형식, 예외 처리, 금지 기준은 Instructions에 넣고, 문서·매뉴얼·가이드·내부 자료는 Knowledge에 넣는 구조가 안정적입니다.

문서 파일은 많다고 좋은 것이 아닙니다. 파일이 늘수록 검색 범위가 넓어져 오히려 답이 흐릴 수 있습니다. 먼저 핵심 문서 몇 개로 시작하고, 실제 테스트에서 비는 부분만 추가하는 방식이 실전에서 더 잘 맞습니다.

3. Capabilities는 “무엇을 할 수 있는지”를 넓히는 영역입니다

웹 검색, 이미지 생성, Canvas, 데이터 분석 같은 기능은 문제 해결 범위를 넓혀 주지만, 기능을 켰다고 바로 좋은 GPT가 되는 것은 아닙니다. 보통은 도구를 더 붙이기 전에 Instructions와 예시를 다듬는 편이 품질을 더 빨리 올립니다.

특히 웹 검색은 최신 정보가 필요할 때, 데이터 분석은 표·수치·파일 작업이 필요할 때만 켜는 식으로 목적형으로 선택하는 것이 좋습니다.

4. Apps와 Actions는 동시에 쓰지 않는다고 생각하면 편합니다

실무에서 많이 막히는 부분입니다. Apps는 사용자가 연결해 둔 외부 도구를 활용하는 방식이고, Actions는 내가 정의한 외부 API를 붙이는 방식입니다.

중요한 점은 하나의 GPT에서 Apps와 Actions를 동시에 쓰는 구조로 잡지 않는 것입니다. 외부 시스템 연동이 필요한지, 아니면 사용자가 이미 연결한 도구를 쓰면 되는지 먼저 정한 뒤 한쪽으로 고르는 편이 설계가 깔끔합니다.

챗GPT 예약 작업 사용법: 반복 업무 자동화

설정 항목	무엇을 넣는가	자주 하는 실수
Instructions	역할, 톤, 우선순위, 출력 형식, 예외 처리	규칙 대신 소개 문장만 길게 적음
Knowledge	가이드, 매뉴얼, FAQ, 내부 문서	행동 규칙까지 파일에만 넣어 둠
Conversation starters	실제 사용자가 바로 던질 질문 예시	너무 추상적인 예시를 넣음
Capabilities	웹 검색, 이미지, Canvas, 데이터 분석 등	필요 없는 기능을 일단 다 켬
Apps / Actions	외부 서비스 연결 방식	둘을 같은 개념으로 생각함

핵심은 규칙은 Instructions, 근거 자료는 Knowledge, 도구는 Capabilities, 연동은 Apps 또는 Actions로 분리하는 것입니다.

안내: 이 글은 2026년 4월 기준 공개된 공식 도움말 구조를 바탕으로 정리했습니다. 실제 화면에서 보이는 메뉴는 요금제, 지역, 워크스페이스 권한, 관리자 정책에 따라 일부 다를 수 있습니다.

GPT 빌더와 Skills는 언제 같이 써야 하나

둘을 경쟁 관계로 볼 필요는 없습니다. 전용 GPT는 “역할 단위”, 스킬은 “작업 방식 단위”로 생각하면 조합이 쉬워집니다.

예를 들어 사내 문서 질문을 받는 전용 GPT를 만들고 싶다면 빌더로 GPT를 만드는 쪽이 맞습니다. 반대로 팀 전체가 같은 방식으로 회의록을 요약하거나, 같은 체크리스트로 문서를 검토해야 한다면 스킬로 공통 워크플로를 묶는 편이 관리가 쉽습니다.

GPT 빌더가 더 맞는 경우: 특정 주제의 도우미를 따로 만들고 싶을 때, 파일 지식을 붙여 질문 응답용으로 쓰고 싶을 때, 공유 링크나 GPT Store 공개까지 생각할 때
Skills가 더 맞는 경우: 여러 대화에서 반복되는 작업 규칙을 재사용하고 싶을 때, 팀원들이 같은 절차를 자동으로 따르게 만들고 싶을 때, 워크스페이스 안에서 공통 작업법을 퍼뜨리고 싶을 때
같이 쓰기 좋은 경우: 고객 응대용 GPT를 따로 두고, 내부 검토·요약·정리 방식은 스킬로 표준화할 때

스킬을 설계할 때는 이름보다 언제 쓰는지와 어떤 순서로 처리하는지가 중요합니다. 반복 작업을 잘게 쪼개서 “입력 형태 → 판단 기준 → 출력 형식”이 보이게 적으면 자동 활용성이 높아집니다.

챗GPT 딥리서치 사용법: 복잡한 연구를 돕는 도구

테스트, 공유, 공개까지 운영 흐름

대부분은 만드는 단계보다 테스트와 공유 단계에서 더 많이 막힙니다. 그래서 첫 버전은 완성도를 욕심내기보다 미리보기로 실제 질문을 넣어 보고, 답이 흔들리는 부분을 Instructions와 예시로 먼저 보정하는 흐름이 안전합니다.

1. 테스트는 “좋아 보이는지”보다 “같은 답을 반복해서 내는지”를 봅니다

미리보기에서는 최소한 아래 질문을 반복해 보는 것이 좋습니다.

정상 입력: 의도한 질문에 원하는 형식으로 답하는가
애매한 입력: 질문이 불완전해도 기준을 잡아 주는가
예외 입력: 모르는 내용은 모른다고 말하고 범위를 분리하는가
파일 기반 입력: Knowledge에 넣은 자료를 실제로 참고하는가

2. 공유 수준과 권한은 따로 생각해야 합니다

공유는 “누가 접근하느냐”이고, 권한은 “무엇까지 할 수 있느냐”입니다. 이 둘을 섞어 생각하면 배포 사고가 나기 쉽습니다.

구분	의미	언제 쓰면 좋은가
비공개	나만 사용	아직 검수 중이거나 초안 단계일 때
워크스페이스 공유	팀 또는 조직 안에서 사용	사내 표준 도구로 배포할 때
링크 공유	링크를 아는 사람에게 접근 허용	외부 공개 전 제한적으로 써 볼 때
GPT Store 공개	공개 배포	불특정 다수가 쓰는 공개형 GPT일 때
권한: Can chat / Can view settings / Can edit	사용만 할지, 설정을 볼지, 직접 수정할지 결정	협업 범위를 세밀하게 나눌 때

특히 팀 운영에서는 사용 권한과 편집 권한을 분리해 두는 것이 중요합니다. 그래야 실수로 규칙이 바뀌거나 버전이 흔들리는 일을 줄일 수 있습니다.

3. 팀 공유를 생각하면 Business/Enterprise/Edu 흐름을 먼저 봐야 합니다

개인 계정과 관리형 워크스페이스는 공유 옵션이 다르게 보일 수 있습니다. 팀 단위 운영이라면 워크스페이스 공유, 특정 사용자 또는 그룹 공유, 관리자 권한 제한이 함께 걸릴 수 있으니, 개인용 GPT를 만들 때와 같은 기준으로 보면 안 됩니다.

또 스킬은 팀 공유와 라이브러리 활용에 강점이 있으므로, 전용 GPT는 빌더, 반복 프로세스는 스킬로 나누면 운영이 훨씬 단순해집니다.

4. 공개 배포 전에는 정책 조건을 먼저 봐야 합니다

공개 링크나 GPT Store를 생각한다면 기능이 잘 돌아가는지만 보면 부족합니다. Apps를 쓰는 GPT는 공개 제한이 생길 수 있고, Actions를 붙인 GPT를 공개하려면 개인정보처리방침 URL 같은 조건이 필요할 수 있습니다.

한 번에 공개까지 가려고 하기보다, 비공개 → 팀 공유 → 제한 링크 → 공개 검토 순서로 올리는 편이 실수와 수정 비용을 줄이기 쉽습니다.

실수 줄이는 체크리스트와 상황별 판단

맞춤 GPT가 금방 흐려지는 이유는 대부분 비슷합니다. 역할이 넓거나, 규칙과 자료가 섞였거나, 공유 범위와 편집 권한을 동시에 열어 둔 경우가 많습니다.

한 GPT에 역할을 너무 많이 넣지 않았는가
행동 규칙을 Instructions에, 참고 자료를 Knowledge에 분리했는가
대화 시작문이 실제 질문 예시로 작성되었는가
Capabilities를 목적형으로만 켰는가
Apps와 Actions를 같은 개념으로 설계하지 않았는가
미리보기에서 정상/애매/예외 입력을 모두 테스트했는가
공유 수준과 편집 권한을 따로 정했는가
공개 배포 전 정책 조건과 개인정보 처리 요건을 다시 확인했는가

처음 버전에서 가장 중요한 것은 완벽함보다 예측 가능성입니다. 사용자가 어떤 질문을 해도 비슷한 기준으로 답하게 만드는 것이 먼저이고, 그다음에 도구와 기능을 넓혀 가는 것이 좋습니다.

간단 결론: 맞춤 GPT를 빨리 잘 만들고 싶다면 전용 역할은 GPT 빌더로, 반복 작업 규칙은 Skills로 나누세요. 그리고 Instructions와 Knowledge를 섞지 않는 것, 공유 전 Preview로 실제 질문을 검증하는 것, 팀 배포 시 권한을 세분화하는 것 이 세 가지를 먼저 지키면 품질이 안정됩니다.

HOW TO: 처음부터 팀 공유까지

작업 범위를 1개로 정합니다.
문서 답변용인지, 초안 작성용인지, 사내 안내용인지부터 좁혀야 Instructions가 흔들리지 않습니다.
ChatGPT의 GPTs 영역에서 Create를 엽니다.
빌더 대화형으로 초안을 만들 수도 있고, 설정 화면에서 직접 구성할 수도 있습니다.
이름, 설명, 대화 시작문, Instructions를 먼저 채웁니다.
사용자가 무엇을 기대해야 하는지와 GPT가 어떤 형식으로 답해야 하는지를 이 단계에서 잠급니다.
Knowledge와 Capabilities를 목적에 맞게 추가합니다.
참고 문서는 Knowledge에 넣고, 웹 검색·데이터 분석 같은 기능은 필요한 것만 켭니다. 외부 연동은 Apps 또는 Actions 중 하나로 정리합니다.
Preview로 실제 질문을 넣어 테스트합니다.
정상 질문, 애매한 질문, 예외 질문을 각각 넣어 보고 답변 형식과 기준이 유지되는지 확인합니다.
저장한 뒤 공유 수준과 권한을 결정합니다.
비공개로 둘지, 워크스페이스에 공유할지, 링크 또는 공개 배포로 갈지 정하고 Can chat, Can view settings, Can edit 범위를 나눕니다.

FAQ

1. 챗GPT 맞춤 GPT는 어디서 만드나요?

맞춤 GPT는 ChatGPT 웹의 GPTs 영역에서 Create를 눌러 만들 수 있습니다. 모바일 앱에서는 GPT를 사용할 수는 있지만, 만드는 작업은 보통 웹 기준으로 보는 편이 맞습니다.

2. GPT 빌더와 Skills는 같은 기능인가요?

아니요. GPT 빌더는 특정 목적의 맞춤 GPT를 만드는 기능이고, Skills는 반복 작업을 재사용 가능한 워크플로로 묶는 별도 기능입니다. 전용 도우미를 만들면 빌더가 맞고, 팀 공통 작업법을 표준화하려면 Skills가 더 잘 맞습니다.

3. Instructions와 Knowledge는 어떻게 나눠야 하나요?

행동 규칙, 말투, 출력 형식, 예외 처리 기준은 Instructions에 넣고, 매뉴얼·가이드·문서 같은 참고 자료는 Knowledge에 넣는 방식이 기본입니다. 두 영역을 섞으면 답변 품질이 흔들리기 쉽습니다.

4. Apps와 Actions를 같이 사용할 수 있나요?

한 GPT에서 외부 연동을 설계할 때는 Apps와 Actions를 동시에 쓰는 방향으로 잡지 않는 편이 맞습니다. 사용자가 연결한 도구를 활용할지, 내가 정의한 외부 API를 붙일지 먼저 정한 뒤 한쪽으로 고르는 것이 좋습니다.

5. 개인 계정도 팀원에게 바로 공유할 수 있나요?

팀 공유 방식은 계정과 워크스페이스 구조에 따라 달라집니다. 개인 계정은 보통 링크 공유나 공개 배포 흐름을 먼저 보게 되고, 특정 사용자나 그룹에 직접 공유하는 방식은 관리형 워크스페이스에서 더 자연스럽게 쓰입니다.

6. GPT를 만든 사람이 사용자 대화를 직접 볼 수 있나요?

일반적으로 GPT를 만든 사람이 그 GPT를 사용하는 다른 사람의 개별 대화를 직접 보는 구조로 이해하면 안 됩니다. 다만 외부 앱이나 API를 연결한 경우에는 해당 서비스로 전달되는 입력 범위를 따로 확인해야 합니다.

7. GPT는 내 메모리나 맞춤 지시를 그대로 이어받나요?

맞춤 GPT는 저장된 메모리나 개인 맞춤 지시를 그대로 이어받는 방식으로 이해하면 안 됩니다. 그래서 같은 작업을 안정적으로 하게 만들고 싶다면 GPT 안의 Instructions를 더 구체적으로 적는 편이 중요합니다.

8. 공개 전에 꼭 확인해야 할 것은 무엇인가요?

Preview 테스트, 공유 범위, 편집 권한, 외부 연동 여부, 공개 정책 조건을 먼저 확인해야 합니다. 특히 Actions를 공개로 운영할 계획이라면 개인정보 처리와 공개 요건을 별도로 다시 보는 것이 안전합니다.

참고자료 범주형

공식 도움말: GPT 생성 및 편집 가이드
공식 도움말: GPTs 개요, 공유 및 공개 정책
공식 도움말: 워크스페이스 권한 및 관리자 제어
공식 도움말: Skills 기능, 생성 방식, 워크스페이스 공유
공식 도움말: 외부 연동 및 공개 운영 시 주의사항

원문고지: 이 글은 2026년 4월 기준 공개된 OpenAI Help Center의 GPTs 관련 안내 문서를 바탕으로 핵심 설정, 공유 흐름, 스킬 활용 포인트를 이해하기 쉽게 재구성한 정보형 콘텐츠입니다. 직접 사용 후기를 꾸며 넣지 않았으며, 화면 구성과 정책 조건은 이후 변경될 수 있습니다.

작성 및 검토: 자동화 허브 편집팀

사이트 운영 목적: AI 기능을 실제 업무 흐름에 연결할 때 필요한 설정 기준, 판단 기준, 실수 방지 포인트를 빠르게 이해할 수 있도록 정리합니다.

직접 경험·테스트·검토 과정 표시

이 글은 체험담 중심 글이 아니라 공식 문서 검토형 가이드입니다. 작성 과정에서 GPT 생성, 공유, 권한, 스킬 관련 공식 문서를 교차 확인하고, 실제 사용자가 가장 많이 막히는 빌더 항목·공유 단계·공개 조건 중심으로 구조를 재정리했습니다.

작성 기준·검토 기준