ChatGPT를 처음 접하면 대부분 하나의 채팅창을 떠올립니다. 질문을 입력하고, 답을 받고, 다시 물어보는 방식입니다. 이 방식은 여전히 중요합니다. 하지만 지금의 ChatGPT는 단순한 대화창을 넘어 작업 공간, 반복 가능한 보조자, 외부 도구 연결, 자동화 API로 이어지는 생태계에 가깝습니다.
이 장의 목표는 모든 기능을 외우는 것이 아닙니다. 중요한 것은 무엇을 언제 써야 하는지 구분하는 감각입니다. 같은 고객 문의 처리 업무라도 개인은 일반 채팅으로 충분할 수 있고, 팀은 custom GPT나 skill이 필요할 수 있으며, 개발 조직은 API와 업무 시스템 연동이 필요할 수 있습니다. 도구 선택을 잘못하면 간단한 일은 복잡해지고, 위험한 일은 통제 없이 자동화됩니다.
AI 생성 이미지
ChatGPT를 하나의 제품이 아니라 여러 층으로 보기
ChatGPT 생태계는 크게 여섯 층으로 볼 수 있습니다.
첫째, 일반 채팅입니다. 가장 기본적인 사용 방식입니다. 즉석 질문, 짧은 요약, 문장 다듬기, 아이디어 발상처럼 맥락이 오래 유지될 필요가 없는 일에 적합합니다.
둘째, Projects입니다. 특정 과업과 관련된 대화, 파일, 지침을 한곳에 모아두는 작업 공간입니다. 보고서 작성, 고객 제안, 수업 준비, 리서치처럼 며칠 또는 몇 주 동안 이어지는 일을 관리할 때 유용합니다.
셋째, custom GPTs입니다. 특정 목적에 맞게 지침, 지식, 기능을 구성한 재사용 가능한 보조자입니다. "이번 보고서를 계속 이어서 작성하자"가 아니라 "앞으로 모든 계약서 초안을 같은 기준으로 점검하자"에 가깝습니다.
넷째, skills입니다. 사용자가 매번 긴 프롬프트를 쓰지 않아도 특정 작업 절차, 문서 양식, 출력 규칙을 재사용하게 해주는 능력 단위로 이해하면 됩니다. 예를 들어 "회의록에서 결정 사항과 액션아이템만 뽑기", "고객 문의를 정해진 라벨로 분류하기", "업로드 문서를 임원 보고 형식으로 요약하기" 같은 반복 절차가 skill의 대상입니다.
다섯째, apps, connectors, MCP, agents입니다. 이 층부터 ChatGPT는 단순히 답을 쓰는 도구가 아니라 외부 서비스와 업무 시스템을 다루는 인터페이스가 됩니다. 캘린더, 문서 저장소, 이메일, CRM, 데이터베이스, 자동화 도구와 연결될 수 있습니다.
여섯째, API입니다. 사람이 ChatGPT 화면에서 대화하는 대신, 애플리케이션이나 데이터 파이프라인 안에서 모델을 호출하는 방식입니다. 고객 문의가 들어오면 자동으로 분류하고, 필요한 정보를 조회하고, 정해진 JSON 형식으로 저장하고, 평가 로그를 남기는 식의 반복 처리가 여기에 속합니다.
이 여섯 층을 한 문장으로 줄이면 다음과 같습니다.
일반 채팅은 빠른 대화, Projects는 지속되는 작업 공간, custom GPTs는 재사용 가능한 보조자, skills는 반복 가능한 작업 능력, 연결 계층은 외부 도구와 데이터 접근, API는 시스템 자동화입니다.
일반 채팅: 가장 빠르지만 가장 쉽게 흩어진다
일반 채팅은 시작 비용이 거의 없습니다. "이 문장을 더 자연스럽게 바꿔줘", "이 회의 메모를 정리해줘", "이 개념을 중학생도 이해하게 설명해줘"처럼 바로 물어보면 됩니다.
장점은 속도입니다. 별도 설정 없이 곧바로 쓸 수 있습니다. 그래서 개인 사용자의 첫 출발점으로 가장 좋습니다. 초안 작성, 간단한 번역, 이메일 답장, 문장 톤 조정, 짧은 코드 설명, 회의 전 질문 목록 만들기처럼 독립적인 작업에 잘 맞습니다.
하지만 일반 채팅은 쉽게 흩어집니다. 어제 만든 기준, 지난주에 올린 파일, 팀에서 합의한 문체, 고객사의 배경을 매번 다시 설명해야 합니다. 사용자가 설명을 빼먹으면 답변 품질도 흔들립니다. 채팅이 길어질수록 중요한 맥락이 묻히고, 여러 대화방에 자료가 흩어질 수도 있습니다.
따라서 일반 채팅은 이렇게 판단하면 됩니다.
한 번 묻고 끝나는가?
결과물을 내가 직접 읽고 바로 고칠 수 있는가?
민감한 데이터나 승인 절차가 필요 없는가?
같은 기준을 팀 전체가 반복해서 쓸 필요는 없는가?
네 가지 질문에 대부분 "그렇다"라고 답할 수 있다면 일반 채팅이면 충분합니다.
Projects: 오래 이어지는 일을 한곳에 묶는다
Projects는 관련 대화, 파일, 지침을 한 작업 공간에 모아두는 방식입니다. 한 자료에 따르면 Projects는 특정 작업이나 워크플로를 위해 관련 채팅, 파일, 지침을 정리하는 전용 작업 공간에 가깝습니다.1 핵심은 "정리"와 "연속성"입니다.
예를 들어 다음과 같은 일에는 Project가 잘 맞습니다.
3개월 동안 진행되는 시장 조사
한 고객사의 제안서 작성
한 학기 수업 설계
신제품 출시 캠페인 준비
책, 논문, 리포트처럼 긴 문서 집필
여러 파일을 계속 참고해야 하는 내부 분석
Project를 쓰면 매번 "우리 회사는 이런 상황이고, 이 보고서의 독자는 누구이며, 지난번에는 이런 결정을 했다"라고 반복 설명할 필요가 줄어듭니다. Project 안에 관련 파일과 지침을 넣고, 대화를 이어가면 됩니다.
다만 Project를 만능 지식창고로 쓰면 안 됩니다. 모든 자료를 한곳에 넣는다고 좋은 답이 나오지 않습니다. 오히려 오래된 파일, 확정 전 초안, 폐기된 기준이 섞이면 AI가 잘못된 맥락을 사용할 수 있습니다. Project에는 자료의 우선순위가 필요합니다.
좋은 Project 지침은 짧고 분명합니다.
이 Project의 목적은 2026년 상반기 B2B 마케팅 회고 보고서를 작성하는 것이다.
주 독자는 마케팅 임원과 영업 리더다.
답변은 한국어 임원 보고체로 작성한다.
업로드된 공식 성과표와 확정된 캠페인 브리프를 우선 근거로 사용한다.
문서에 없는 수치는 추정하지 말고 '추가 확인 필요'라고 표시한다.Project는 "이번 일"을 위한 공간입니다. 같은 유형의 일을 계속 반복하려면 다음 단계인 custom GPTs를 고려해야 합니다.
custom GPTs: 반복 호출할 수 있는 전문 보조자
custom GPTs는 특정 목적에 맞게 구성한 재사용 가능한 보조자입니다. Projects가 "한 과업의 작업실"이라면 custom GPTs는 "특정 업무를 수행하는 전담 보조자"에 가깝습니다. 같은 자료에서도 Projects는 작업 정리에, custom GPTs는 특정 업무를 수행하는 맞춤형 AI 보조자를 만드는 데 적합하다고 구분합니다.1
차이는 다음 예시에서 분명해집니다.
"이번 고객사 제안서를 계속 이어서 작성하기" → Project
"앞으로 모든 고객사 제안서를 우리 회사의 제안서 기준으로 점검하기" → custom GPT
"이번 리서치 자료를 한곳에 모아 관리하기" → Project
"항상 같은 방식으로 리서치 보고서의 근거 부족, 과장 표현, 빠진 쟁점을 검토하기" → custom GPT
"이번 계약서 검토 메모를 작성하기" → Project 또는 일반 채팅
"항상 같은 기준으로 계약서 위험 조항을 표시하기" → custom GPT
custom GPT의 장점은 행동 기준을 고정할 수 있다는 점입니다. 예를 들어 법무팀은 다음과 같은 보조자를 만들 수 있습니다.
역할: 계약서 1차 검토 보조자
목표: 계약서의 위험 조항 후보를 표시하고 변호사 검토 질문을 만든다.
금지: 법률 의견을 확정적으로 제시하지 않는다.
출력: 조항 위치 / 위험 유형 / 검토 이유 / 확인 질문 / 우선순위
기준: 비밀유지, 책임 제한, 해지, 개인정보, 지식재산권, 준거법을 반드시 확인한다.이 보조자는 한 프로젝트에만 묶이지 않습니다. 여러 계약, 여러 팀, 여러 시점에서 반복적으로 호출할 수 있습니다. 또한 custom GPTs는 특정 지침, 지식, 기능, 외부 도구 연결을 조합할 수 있는 방식으로 이해할 수 있습니다. OpenAI의 GPT Actions 문서도 custom GPT가 지침, 문서 지식, 외부 API 연결을 통해 특정 사용 사례에 맞게 구성될 수 있음을 설명합니다.2
주의할 점도 있습니다. custom GPT를 만들었다고 해서 품질이 자동으로 보장되지는 않습니다. 기준이 오래되면 오래된 판단을 반복하고, 잘못된 예시가 들어가면 잘못된 스타일을 확산합니다. custom GPT는 만든 뒤 방치하는 도구가 아니라 버전 관리가 필요한 팀 자산입니다.
skills: 반복 절차를 능력 단위로 만든다
skills는 Projects나 custom GPTs와 함께 이해하면 더 쉽습니다.
Projects: 이 일을 계속 이어가기 위한 공간
custom GPTs: 이 역할을 반복 호출하기 위한 보조자
skills: 이 작업 절차를 반복 실행하기 위한 능력
예를 들어 고객 서비스 팀이 있다고 합시다. Project는 "2026년 5월 결제 장애 대응" 같은 특정 사건의 자료와 대화를 담을 수 있습니다. custom GPT는 "우리 회사 고객 응대 기준을 따르는 CS 응대 보조자"가 될 수 있습니다. skill은 그 보조자가 수행하는 구체적 절차입니다.
예를 들면 다음과 같습니다.
Skill: 고객 문의 분류
입력: 고객 문의 원문
절차:
1. 개인정보와 주문번호를 마스킹한다.
2. 문의 주제를 결제/배송/계정/환불/장애/기타 중 하나로 분류한다.
3. 감정 강도를 낮음/보통/높음으로 표시한다.
4. SLA 위험 여부를 판단한다.
5. 상담원에게 필요한 다음 행동을 제안한다.
출력: 정해진 표 형식으로만 작성한다.사용자는 매번 이 긴 절차를 쓰지 않아도 됩니다. 잘 설계된 skill은 반복 업무의 품질을 안정시킵니다. 특히 팀에서는 skill이 중요합니다. 개인은 머릿속 기준으로 대충 고쳐 쓸 수 있지만, 팀은 같은 업무를 여러 사람이 같은 기준으로 처리해야 합니다. 그때 skill은 암묵지를 명시적인 절차로 바꾸는 역할을 합니다.
단, 모든 일을 skill로 만들 필요는 없습니다. 한 번만 할 일, 창의적 탐색이 중요한 일, 기준이 아직 정해지지 않은 일은 먼저 일반 채팅이나 Project에서 실험하는 편이 좋습니다. 반복이 확인되고 기준이 안정된 뒤 skill로 만들면 됩니다.
apps, connectors, MCP, agents: 말하는 도구에서 행동하는 도구로
ChatGPT가 외부 서비스와 연결되면 성격이 달라집니다. 단순히 답을 생성하는 수준을 넘어, 승인된 데이터에 접근하고 특정 행동을 수행할 수 있기 때문입니다.
apps는 ChatGPT 안에서 외부 서비스의 기능이나 화면을 사용할 수 있게 하는 연결 방식으로 이해할 수 있습니다. 텍스트 답변만으로 부족한 작업, 예를 들어 디자인 시안 확인, 문서 생성, 데이터 화면 조작, 특정 서비스의 기능 실행에 적합합니다.
connectors는 문서 저장소, 이메일, 캘린더, 협업 도구, CRM 같은 외부 데이터에 접근하는 통로입니다. 예를 들어 "지난달 A고객사와 주고받은 이메일과 회의록을 찾아 쟁점을 정리해줘" 같은 작업은 연결된 데이터 소스가 있어야 가능합니다.
MCP(Model Context Protocol)는 AI 애플리케이션과 외부 도구를 표준 방식으로 연결하기 위한 규약입니다. 쉽게 말해 여러 도구와 데이터베이스를 매번 다른 방식으로 붙이지 않고, 공통된 방식으로 연결하려는 시도입니다. OpenAI의 Apps SDK 문서도 MCP 서버의 구조화된 도구 결과를 ChatGPT 안의 사용자 인터페이스로 렌더링하는 방식을 설명합니다.3
agents는 목표를 달성하기 위해 여러 단계를 계획하고, 필요한 도구를 호출하고, 결과를 확인하며 다음 행동을 이어가는 실행 패턴입니다. 예를 들어 "신규 리드 목록을 검토하고, CRM 정보를 조회하고, 우선순위를 매긴 뒤, 영업 담당자에게 초안 메일을 작성하라"는 일은 단일 답변보다 agent형 흐름에 가깝습니다.
이 연결 계층에서는 편리함보다 통제가 먼저입니다. 외부 시스템에 연결된 ChatGPT는 더 많은 일을 할 수 있지만, 더 큰 사고도 만들 수 있습니다. 따라서 다음 네 가지를 반드시 설계해야 합니다.
권한: 어떤 데이터와 기능에 접근할 수 있는가?
데이터 범위: 전체 저장소를 볼 수 있는가, 특정 폴더만 볼 수 있는가?
승인 단계: 읽기만 가능한가, 쓰기·전송·수정은 사람 승인이 필요한가?
로그 관리: 누가, 언제, 어떤 요청으로, 어떤 결과를 만들었는가?
특히 쓰기 권한은 신중해야 합니다. 캘린더 일정 생성, CRM 필드 수정, 고객 메일 발송, 환불 처리, 데이터베이스 업데이트는 되돌리기 어렵거나 외부 영향을 만들 수 있습니다. 이런 작업은 AI가 "제안"하고 사람이 "승인"하는 구조가 기본입니다.
ChatGPT 제품 사용과 API 기반 구축의 차이
ChatGPT 화면에서 직접 사용하는 방식과 API로 시스템을 만드는 방식은 목적이 다릅니다.
ChatGPT 제품 사용은 상호작용형 사용에 강합니다. 사람이 맥락을 설명하고, 답변을 읽고, 다시 묻고, 수정 방향을 지시합니다. 보고서 초안, 수업안, 고객 응대 문안, 리서치 정리처럼 사람이 중간중간 판단해야 하는 일에 좋습니다.
반면 API 기반 구축은 자동화형 사용에 강합니다. 애플리케이션, RPA, 데이터 파이프라인, 고객센터 시스템 안에서 모델 호출이 반복됩니다. 개발자는 모델에게 자유로운 글을 쓰게 하는 데서 끝나지 않고, function calling, structured outputs, 평가, 모니터링, 실패 처리까지 설계해야 합니다.
예를 들어 고객 문의가 들어올 때마다 다음 절차를 자동으로 수행한다고 합시다.
문의 원문에서 개인정보를 마스킹한다.
주제와 긴급도를 분류한다.
주문 시스템에서 상태를 조회한다.
답변 초안을 만든다.
고위험 문의는 상담원에게 넘긴다.
결과를 티켓 시스템에 저장한다.
AI 출력과 상담원 수정 내역을 로그로 남긴다.
이런 흐름은 일반 채팅보다 API와 업무 시스템 연동이 적합합니다. 여기서 AI는 혼자 일하는 직원이 아니라 시스템 안의 하나의 처리 단계입니다. 언어 이해와 초안 작성은 AI가 맡고, 권한 확인, 데이터 조회, 저장, 승인, 감사는 애플리케이션이 맡아야 합니다.
같은 업무도 사용자 수준에 따라 도구가 달라진다
이제 같은 업무를 세 수준으로 비교해 보겠습니다. 업무는 "고객 문의를 분류하고 답변 초안을 작성하기"입니다.
개인 사용자
개인 사용자라면 일반 채팅으로 시작하면 됩니다.
아래 고객 문의를 읽고 다음 형식으로 정리해줘.
- 문의 주제
- 고객 감정
- 핵심 요청
- 답변 초안
- 내가 확인해야 할 정보
고객 문의:
[문의 내용]문의가 많지 않고, 사용자가 직접 검토해 보낼 수 있다면 이 정도로 충분합니다. 특정 고객이나 사건을 며칠 동안 계속 다뤄야 한다면 Project를 만들 수 있습니다. 그 Project 안에 제품 정책, 환불 기준, 장애 공지, 이전 답변을 넣고 이어서 작업하면 됩니다.
팀 관리자
팀 관리자는 개인 채팅만으로는 부족합니다. 상담원마다 다른 답변을 보내면 고객 경험이 흔들립니다. 이때는 custom GPT나 skill이 필요합니다.
custom GPT에는 다음 기준을 넣을 수 있습니다.
우리 회사의 응대 톤
환불·교환 정책
금지 표현
에스컬레이션 기준
답변 초안 형식
개인정보 처리 원칙
skill에는 반복 절차를 넣습니다.
문의 분류
SLA 위험 표시
감정 강도 판단
상담원 확인 정보 추출
답변 초안 작성
고위험 문의 이관 표시
이렇게 하면 팀 전체가 같은 기준으로 초안을 만들 수 있습니다. 중요한 것은 AI가 고객에게 바로 답하게 하는 것이 아니라, 상담원이 검토할 수 있는 표준 초안을 만들게 하는 것입니다.
개발자와 운영 조직
문의량이 많고, 티켓 시스템이나 CRM과 연결해야 한다면 API 기반 구축이 필요합니다.
이 경우 개발자는 다음을 설계합니다.
입력 데이터에서 개인정보를 제거하는 전처리
분류 결과를 담을 JSON 스키마
주문 상태나 장애 공지를 조회하는 도구 호출
상담원 승인 전에는 고객 발송을 막는 정책
AI 출력, 상담원 수정, 최종 발송문의 로그
분류 정확도, 재문의율, 응답 시간, 고객 만족도 평가
이 단계에서는 프롬프트만 잘 쓰는 것으로 부족합니다. 데이터 흐름, 권한, 실패 처리, 모니터링이 함께 필요합니다. 고객 문의 분류는 언뜻 간단해 보이지만, 자동 발송까지 연결되면 개인정보, 최신 정책, 고객 감정, 법적 표현, 브랜드 톤이 모두 얽히는 운영 문제가 됩니다.
선택 기준: 일회성인가, 반복인가, 연결되는가
도구 선택이 헷갈릴 때는 다음 질문을 순서대로 던지면 됩니다.
1. 한 번만 할 일인가?
그렇다면 일반 채팅으로 충분합니다. 빠르게 묻고, 결과를 직접 검토하면 됩니다.
2. 한 과업의 맥락이 오래 이어지는가?
그렇다면 Project가 적합합니다. 관련 파일, 대화, 지침을 한곳에 모아야 합니다.
3. 같은 역할과 기준을 여러 번 재사용해야 하는가?
그렇다면 custom GPT를 고려합니다. 보고서 검토자, 계약서 점검 보조자, 고객 응대 보조자처럼 반복 호출할 전문 보조자를 만들 수 있습니다.
4. 같은 절차와 출력 형식을 반복해야 하는가?
그렇다면 skill로 만들 수 있습니다. 분류, 요약, 점검, 변환, 보고서 양식화처럼 절차가 안정된 작업에 적합합니다.
5. 외부 데이터나 업무 시스템에 접근해야 하는가?
그렇다면 apps, connectors, MCP 같은 연결 계층을 검토합니다. 이때부터는 권한, 데이터 범위, 승인, 로그가 필수입니다.
6. 사람이 매번 대화하지 않아도 반복 처리되어야 하는가?
그렇다면 API 기반 구축이 필요합니다. 자동화, 대량 처리, 시스템 연동, 평가와 모니터링을 함께 설계해야 합니다.
작게 시작하고, 기준이 생기면 위로 올린다
처음부터 API나 agent를 도입할 필요는 없습니다. 좋은 순서는 대체로 반대입니다.
먼저 일반 채팅으로 업무 가능성을 확인합니다. 그다음 특정 과업이 길어지면 Project로 묶습니다. 같은 기준이 반복되면 custom GPT나 skill로 표준화합니다. 외부 데이터가 필요해지면 connectors나 MCP를 검토합니다. 처리량이 많고 반복성이 높아지면 API로 자동화합니다. 마지막으로 평가와 로그를 붙여 운영 체계로 만듭니다.
이 순서를 따르면 과도한 자동화를 피할 수 있습니다. 반대로 처음부터 복잡한 시스템을 만들면 실제 업무 기준이 정리되기 전에 기술만 커집니다. AI 도입의 핵심은 멋진 기능을 빨리 붙이는 것이 아니라, 업무의 반복성과 위험도를 정확히 읽고 알맞은 층을 선택하는 것입니다.
ChatGPT는 이제 하나의 채팅창이 아닙니다. 하지만 모든 기능을 써야 하는 것도 아닙니다. 일회성 작업은 가볍게, 지속되는 일은 Project로, 반복 기준은 custom GPT와 skill로, 외부 연결은 통제와 함께, 대량 자동화는 API와 평가 체계로 다루면 됩니다. 이 구분이 잡히면 개인 활용에서 팀 협업, 조직 도입까지 길을 잃지 않습니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.