팀 협업과 재사용 가능한 지식

개인의 요령을 팀의 자산으로 바꾸는 순간

한 사람이 ChatGPT를 잘 쓰기 시작하면 처음에는 작은 기적처럼 보입니다. 회의록이 빨라지고, 보고서 초안이 정돈되고, 이메일 문장이 매끄러워집니다. 그런데 팀 단위로 보면 곧 이상한 문제가 생깁니다. 어떤 사람은 매우 좋은 결과를 얻는데, 어떤 사람은 여전히 평범한 답을 받습니다. 한 직원의 채팅창에는 훌륭한 프롬프트와 노하우가 쌓이지만, 옆자리 동료는 같은 시행착오를 반복합니다. 팀장은 "우리 팀도 AI를 잘 쓰고 있다"고 생각하지만, 실제로는 개인별 요령이 각자의 대화 기록 속에 흩어져 있을 뿐입니다.

팀에서 AI를 잘 쓴다는 말은 팀원 모두가 매번 멋진 프롬프트를 즉흥적으로 쓴다는 뜻이 아닙니다. 오히려 반대에 가깝습니다. 좋은 팀은 즉흥성을 줄입니다. 반복되는 업무의 맥락, 참고 자료, 문체, 금지사항, 검토 기준을 한곳에 모아 두고, 누구나 비슷한 품질로 다시 사용할 수 있게 만듭니다. 다시 말해 팀의 AI 활용 능력은 "누가 질문을 잘하느냐"에서 "좋은 질문과 판단 기준을 어떻게 저장하고 공유하느냐"로 옮겨갑니다.

앞 장에서 우리는 개인 생산성 워크플로를 입력, 처리, 출력, 저장의 흐름으로 보았습니다. 팀 협업에서는 여기에 두 단어가 더 붙습니다. 공유와 운영입니다. 개인은 좋은 결과를 저장하면 충분할 수 있지만, 팀은 그 결과가 다른 사람에게도 보이고, 수정되고, 검토되고, 다음 버전으로 개선되어야 합니다. ChatGPT의 Projects, custom GPTs, skills는 이 전환을 돕는 대표적인 장치입니다. Projects는 장기 과업의 맥락을 모으는 작업 공간이고, custom GPTs와 skills는 반복되는 작업 규칙을 재사용 가능한 형태로 묶는 방법입니다. OpenAI Academy도 Projects를 맥락, 파일, 지시문을 모아 작업을 조직하는 공간으로 설명하고, 팀원이 같은 프로젝트에서 협업할 수 있다는 점을 강조합니다.¹

이 장의 핵심은 기능 사용법을 외우는 것이 아닙니다. 화면의 버튼 이름은 바뀔 수 있습니다. 플랜별 제공 범위도 바뀔 수 있습니다. 그러나 원리는 오래갑니다. 팀에서 AI를 잘 쓰려면 개인의 감각을 조직의 재사용 가능한 지식으로 바꾸어야 합니다.

Projects는 폴더가 아니라 장기 작업 공간이다

Projects를 처음 보면 폴더처럼 느껴집니다. 대화를 주제별로 묶고, 파일을 넣고, 지시문을 달 수 있으니 당연합니다. 하지만 팀에서 Projects를 단순 폴더로만 쓰면 금세 한계가 옵니다. 이름만 "마케팅"인 거대한 폴더 안에 캠페인 회의, 고객 인터뷰, 경쟁사 분석, 예산 검토, SNS 문안, 채용 공고까지 뒤섞이는 순간 AI도 사람도 맥락을 잃습니다.

Projects는 "관련 대화 보관함"이 아니라 하나의 장기 과업을 수행하기 위한 작업대로 설계해야 합니다. 여기서 장기 과업이란 한 번 묻고 끝나는 질문이 아니라 며칠, 몇 주, 몇 달 동안 맥락이 유지되어야 하는 일입니다. 고객사 제안, 분기 캠페인, 제품 릴리스, 연구 주제, 고객지원 FAQ 개편, 신규 입사자 온보딩 문서처럼 계속 참고해야 할 자료와 결정이 쌓이는 일이 여기에 해당합니다.

좋은 Project는 이름만 보아도 목적과 범위가 드러납니다. "마케팅"보다 "2026년 3분기 SMB 리드 확보 캠페인"이 낫고, "고객사"보다 "A사 ERP 전환 제안 1차 PoC"가 낫습니다. 이름이 구체적이면 팀원이 들어왔을 때 어떤 질문을 해야 할지, 어떤 자료를 넣어야 할지, 어떤 대화는 다른 프로젝트로 빼야 할지 판단할 수 있습니다.

Project를 만들 때는 먼저 짧은 헌장을 작성하는 습관이 좋습니다. 헌장이라고 해서 거창한 문서가 아닙니다. 이 공간이 왜 존재하는지, 어디까지 다룰지, 어떤 산출물을 만들지 적는 1페이지짜리 안내문이면 충분합니다.

프로젝트명: [구체적 과업명]

1. 목적
이 프로젝트는 [누구/무엇]을 위해 [어떤 산출물 또는 결정]을 만드는 작업 공간이다.

2. 범위
포함하는 작업:
- [작업 1]
- [작업 2]
- [작업 3]

포함하지 않는 작업:
- [제외 작업 1]
- [제외 작업 2]
- [제외 작업 3]

3. 주요 산출물
- [예: 캠페인 브리프]
- [예: 임원 보고용 요약]
- [예: 고객 발송용 제안서 초안]

4. 참고 자료 우선순위
1순위: 최신 승인 문서
2순위: 프로젝트 내부 회의록과 결정 사항
3순위: 과거 유사 프로젝트 자료

5. 기본 출력 기준
- 한국어 비즈니스 문체
- 근거가 불확실한 내용은 '확인 필요' 표시
- 외부 발송 전 인간 검토 필수

이런 헌장이 있으면 Project가 단순 대화 모음에서 팀의 작업 환경으로 바뀝니다. 새로운 팀원이 합류해도 "이 프로젝트에서는 무엇을 물어도 되고, 무엇은 물으면 안 되는지"를 빠르게 이해합니다. AI 역시 프로젝트 지시문과 파일을 통해 일관된 방향으로 답할 가능성이 높아집니다.

프로젝트를 나누는 기준: 조직도가 아니라 맥락의 수명

많은 팀이 프로젝트를 조직도 기준으로 나눕니다. 마케팅팀 프로젝트, 영업팀 프로젝트, 개발팀 프로젝트처럼 말입니다. 이 방식이 항상 나쁜 것은 아니지만, AI 작업 공간을 설계할 때는 조직도보다 맥락의 수명을 기준으로 나누는 편이 더 정확합니다.

맥락의 수명이란 그 정보가 얼마나 오래 함께 움직여야 하는지를 뜻합니다. 예를 들어 특정 고객사 제안은 영업, 제품, 법무, 기술지원이 함께 관여할 수 있습니다. 조직도 기준으로 나누면 관련 정보가 여러 프로젝트에 흩어집니다. 반면 "A사 제안"이라는 과업 기준으로 묶으면 고객 요구사항, 회의록, 기술 검토, 가격 논의, 리스크가 한곳에 모입니다. 팀원은 각자 다른 역할로 참여하더라도 같은 맥락을 보고 일할 수 있습니다.

Projects를 나눌 때는 다음 질문을 던지면 좋습니다.

• 이 작업은 앞으로 다시 돌아와 이어서 처리할 가능성이 있는가?

• 참고해야 할 파일과 결정 사항이 계속 누적되는가?

• 여러 사람이 같은 맥락을 보고 작업해야 하는가?

• 최종 산출물이 명확한가?

• 다른 업무와 섞였을 때 혼란이나 보안 문제가 생기는가?

이 질문에 대부분 "그렇다"고 답한다면 별도 Project를 만드는 편이 좋습니다. 반대로 단순한 일회성 질문, 짧은 문장 다듬기, 임시 아이디어 발상은 일반 채팅으로도 충분합니다. 모든 질문을 Project로 밀어 넣으면 정리는커녕 창고만 늘어납니다.

실무에서는 다음과 같은 단위가 특히 잘 맞습니다.

이 기준의 장점은 간단합니다. 팀원이 "어느 프로젝트에서 질문해야 하는가"를 덜 고민하게 됩니다. Project의 목적이 분명할수록 AI의 답변도 산만해지지 않습니다.

공동 프로젝트는 정보 사일로를 줄인다

개별 채팅 공유만으로는 팀 협업이 잘 되지 않습니다. 누군가 좋은 답변을 받으면 링크를 공유할 수는 있습니다. 하지만 그 링크 하나로는 충분하지 않습니다. 그 답변이 나오기까지 참고한 파일, 이전 대화, 프로젝트 지시문, 팀의 결정 사항이 함께 전달되지 않기 때문입니다. 그래서 팀은 같은 주제에 대해 서로 다른 채팅을 만들고, 비슷한 질문을 반복하고, 조금씩 다른 결론을 얻습니다. 이것이 AI 시대의 새로운 정보 사일로입니다.

공동 Project는 이 문제를 줄입니다. 팀원이 같은 파일, 같은 지시문, 같은 진행 맥락을 보며 작업할 수 있기 때문입니다. Project 공유 기능을 설명하는 실무 자료들은 개별 채팅 공유가 정보 사일로를 만들기 쉽고, 공유 프로젝트는 지시문·업로드 파일·대화 묶음을 함께 공유해 협업 환경을 만든다고 설명합니다.² 중요한 차이는 "답변 하나를 공유하느냐"와 "작업 공간을 공유하느냐"입니다.

하지만 공유는 무조건 좋은 것이 아닙니다. 공유 범위가 넓어질수록 혼란과 보안 위험도 커집니다. 따라서 공동 Project를 만들 때는 권한과 책임을 처음부터 정해야 합니다. 어떤 사람은 대화만 할 수 있고, 어떤 사람은 파일과 지시문을 바꿀 수 있으며, 어떤 사람은 프로젝트를 종료하거나 삭제할 수 있습니다. 기능 명칭은 서비스와 플랜에 따라 달라질 수 있지만, 운영 원칙은 같습니다. 질문 권한과 편집 권한을 구분해야 합니다.

공동 Project에서는 다음 기준을 문서화해 두는 편이 안전합니다.

• 누가 프로젝트에 접근할 수 있는가

• 누가 지시문과 파일을 수정할 수 있는가

• 어떤 자료는 업로드하면 안 되는가

• 완료된 산출물과 진행 중 대화를 어떻게 구분하는가

• 프로젝트 종료 후 무엇을 보관하고 무엇을 삭제하는가

특히 "완료된 산출물"과 "진행 중 대화"의 구분이 중요합니다. 대화 중에는 가정, 추측, 미완성 아이디어, 검토 전 문장이 섞입니다. 이것을 최종 결론처럼 재사용하면 사고가 납니다. 그래서 Project 안에는 "완료본", "검토 중", "아이디어", "폐기" 같은 상태 표시가 필요합니다. AI가 만든 초안은 초안입니다. 팀의 승인 절차를 통과한 문서만 기준 문서가 됩니다.

프로젝트 지시문은 팀의 기본 운영체제다

Project의 지시문은 팀원이 매번 반복해서 입력하지 않아도 되는 공통 규칙입니다. 여기에는 역할, 문체, 참고 기준, 금지사항, 출력 형식, 검토 기준이 들어갑니다. 계정 전체에 적용되는 개인 맞춤 지시문이 "나의 기본 취향"이라면, 프로젝트 지시문은 "이 과업의 업무 규칙"입니다.

좋은 프로젝트 지시문은 길수록 좋은 것이 아닙니다. 회사의 모든 규정을 통째로 넣으면 AI도 핵심을 잡기 어렵고, 팀원도 무엇이 중요한지 알기 어렵습니다. 프로젝트 지시문은 안정적으로 반복되어야 하는 규칙만 담고, 세부 자료는 파일이나 별도 지식 문서로 분리하는 편이 낫습니다.

다음은 팀용 Project 지시문 템플릿입니다.

당신은 [팀/프로젝트명]의 작업 보조자다.
목표는 [최종 산출물]을 더 빠르고 일관되게 만들도록 돕는 것이다.

## 작업 목적
- 이 프로젝트는 [목적]을 위해 운영된다.
- 답변은 [주요 독자/사용자]가 바로 검토할 수 있는 형태여야 한다.

## 기본 문체
- 한국어 비즈니스 문체를 사용한다.
- 과장된 표현보다 명확한 표현을 우선한다.
- 외부 발송용 문장은 정중하되 장황하지 않게 쓴다.

## 참고 기준
- 업로드된 최신 승인 문서를 우선한다.
- 서로 충돌하는 자료가 있으면 결론을 단정하지 말고 충돌 사실을 표시한다.
- 날짜, 가격, 법률, 정책, 수치 정보는 최신성 확인 필요 항목으로 표시한다.

## 금지사항
- 문서에 없는 성과 수치나 고객 발언을 만들어내지 않는다.
- 민감정보, 개인정보, 계약상 비밀로 보이는 내용은 외부 공유용 문안에 포함하지 않는다.
- 확정되지 않은 의사결정을 확정된 것처럼 쓰지 않는다.

## 기본 출력 형식
요청이 모호하면 먼저 필요한 추가 정보를 질문한다.
초안을 만들 때는 다음 순서로 출력한다.
1. 한 줄 결론
2. 초안
3. 근거 또는 참고한 자료
4. 확인 필요 사항
5. 인간 검토 체크리스트

이 템플릿은 단순히 예쁘게 답변받기 위한 장치가 아닙니다. 팀의 품질 기준을 AI 작업 공간에 새기는 일입니다. 특히 한국 조직에서는 보고 문체, 승인 단계, 외부 발송 표현, 책임 소재가 중요합니다. 같은 내용을 말하더라도 "검토 부탁드립니다"와 "확정했습니다"는 전혀 다른 의미를 가집니다. 프로젝트 지시문은 이런 차이를 반복해서 지키게 만드는 최소한의 안전장치입니다.

파일을 많이 넣는 것보다 찾기 쉽게 넣는 것이 중요하다

팀이 AI에 공통 자료를 넣을 때 가장 많이 하는 실수는 "일단 다 넣자"입니다. 브랜드 가이드, 서비스 소개서, 예전 제안서, 회의록, 제품 설명서, 가격표, FAQ, 법무 검토 의견, 고객 인터뷰를 한꺼번에 업로드합니다. 처음에는 든든해 보입니다. 하지만 곧 문제가 생깁니다. 오래된 가격표와 최신 가격표가 동시에 있고, 예전 브랜드 메시지와 새 메시지가 충돌하며, 폐기된 기능 설명이 남아 있습니다. AI는 이 중 무엇이 최신이고 무엇이 우선인지 자동으로 완벽히 판단하지 못합니다.

지식 기반의 품질은 양보다 정리 상태에 좌우됩니다. 팀의 공통 자료를 Project나 custom GPT에 넣기 전에는 최소한 다음 네 가지 표시를 해야 합니다. 최신본인지, 소유자가 누구인지, 적용 범위가 어디까지인지, 우선순위가 무엇인지입니다.

파일명도 중요합니다. "최종_진짜최종_v3.pdf"는 사람에게도 AI에게도 좋지 않습니다. "2026-05-01_제품FAQ_외부공유가능_승인본.pdf"처럼 날짜, 문서 종류, 공개 범위, 상태를 넣으면 훨씬 안전합니다.

Project 안에는 "자료 색인"을 하나 두는 것이 좋습니다. 자료 색인은 AI가 참고할 파일 목록이자 팀원이 문서를 이해하는 지도입니다.

# 프로젝트 자료 색인

## 1. 기준 문서
- 파일명: 2026-05-01_제품FAQ_외부공유가능_승인본.pdf
- 소유자: 제품마케팅팀
- 적용 범위: 국내 B2B 고객 문의 응대
- 우선순위: 제품 관련 답변에서 1순위
- 비고: 가격 정보는 포함하지 않음

## 2. 참고 문서
- 파일명: 2026-Q2_고객인터뷰요약_내부용.docx
- 소유자: 리서치팀
- 적용 범위: 메시지 가설 수립용
- 우선순위: 고객 표현 참고용, 사실 단정 근거로 사용 금지
- 비고: 외부 인용 금지

## 3. 폐기 문서
- 파일명: 2025_서비스소개서_구버전.pdf
- 처리: 업로드하지 않음
- 사유: 기능명과 가격 정책이 변경됨

이 색인을 만들어 두면 AI에게도 다음처럼 지시할 수 있습니다. "자료 색인을 먼저 확인하고, 기준 문서와 참고 문서를 구분해 답하라." 이렇게 하면 파일을 많이 넣는 것이 아니라, 찾기 쉽고 충돌이 적게 넣는 방식으로 바뀝니다.

custom GPTs는 팀의 반복 역할을 만든다

Project가 특정 과업의 장기 맥락을 관리한다면, custom GPTs는 여러 과업에서 반복되는 역할을 재사용하게 해 줍니다. OpenAI Academy는 custom GPTs를 특정 형식이나 스타일로 글을 쓰고, 공통 데이터셋을 분석하고, 시각 자료를 만드는 등 반복 업무를 돕는 맞춤형 ChatGPT로 설명합니다.³ 쉽게 말해 Project가 "이번 캠페인의 작업실"이라면, custom GPT는 "항상 같은 기준으로 캠페인 문안을 검토하는 편집자"에 가깝습니다.

예를 들어 마케팅팀에는 여러 캠페인이 있습니다. 캠페인마다 Project는 다를 수 있습니다. 그러나 브랜드 톤을 점검하고, 금지 표현을 찾고, CTA를 다듬고, 채널별 문안을 변환하는 기준은 반복됩니다. 이 반복 기준을 매번 프로젝트 지시문에 길게 쓰는 대신 "브랜드 리뷰어 GPT"로 만들어 두면 여러 프로젝트에서 재사용할 수 있습니다.

custom GPT를 만들 만한 업무는 몇 가지 특징이 있습니다. 같은 유형의 요청이 자주 반복되고, 출력 형식이 비교적 안정적이며, 팀의 기준 문서나 예시를 참고해야 하고, 결과물의 품질 편차를 줄이는 것이 중요합니다. 이런 업무는 개인의 프롬프트 실력에 맡기기보다 custom GPT로 캡슐화하는 편이 좋습니다.

실무에서 유용한 custom GPT 예시는 다음과 같습니다.

custom GPT의 핵심은 "성격 있는 챗봇"을 만드는 데 있지 않습니다. 역할, 문체, 금지사항, 참고 기준, 출력 형식, 검토 체크리스트를 한 번에 묶어 팀의 반복 업무를 표준화하는 데 있습니다. 따라서 이름도 귀엽게 짓기보다 기능이 드러나게 짓는 편이 좋습니다. "마케팅 천재봇"보다 "브랜드 문안 리뷰어"가 낫습니다. "보고서 요정"보다 "임원 보고 1페이지 요약기"가 낫습니다.

custom GPT 설계 초안은 다음 형식으로 시작할 수 있습니다.

이름: [업무가 드러나는 이름]

한 줄 설명:
[누가 어떤 상황에서 이 GPT를 쓰는지]

사용자:
[주 사용자와 보조 사용자]

반복 업무:
- [업무 1]
- [업무 2]
- [업무 3]

참고 자료:
- [가이드 문서]
- [템플릿]
- [좋은 예시]
- [금지/주의 목록]

응답 규칙:
- 모르는 사실은 추정하지 않는다.
- 기준 문서와 충돌하면 충돌을 표시한다.
- 외부 발송물은 인간 검토 필요 표시를 붙인다.

기본 출력 형식:
1. 작업 이해
2. 결과물 초안
3. 검토 포인트
4. 확인 필요 사항
5. 다음 개선 제안

성공 기준:
- 팀원이 별도 설명 없이도 같은 형식의 결과를 얻는다.
- 검토자가 반복적으로 지적하던 오류가 줄어든다.
- 신규 팀원이 기존 기준을 빠르게 따라온다.

이 문서를 먼저 만든 뒤 custom GPT를 구성하면 시행착오가 줄어듭니다. 바로 만들기부터 시작하면 대개 멋진 설명은 있지만 실제 업무에서 잘 쓰이지 않는 GPT가 됩니다.

skills는 반복 절차를 짧게 호출하는 방법이다

custom GPT가 하나의 역할이나 도메인에 가까운 재사용 장치라면, skills는 특정 작업 절차를 더 작고 명확하게 묶는 방식으로 이해하면 쉽습니다. OpenAI의 skills 소개는 ChatGPT skills를 반복 가능한 워크플로를 만들고, 반복 업무를 자동화하며, 일관된 고품질 출력을 얻기 위한 방법으로 설명합니다.⁴ 공개된 실무 설명에서는 skills가 SKILL.md라는 평문 마크다운 파일, 즉 작업 절차를 담은 플레이북을 중심으로 구성되며, 반복되는 지시를 매번 다시 쓰지 않게 해 준다고 설명합니다.⁵

여기서 중요한 것은 제품명이 아니라 사고방식입니다. 사용 중인 워크스페이스에서 skills가 명시적 기능으로 보이지 않더라도 같은 원리를 쓸 수 있습니다. 반복 프롬프트 블록, 프로젝트 내부 템플릿, custom GPT 지시문 일부, 사내 위키의 작업 절차 문서가 모두 skill처럼 작동할 수 있습니다. 핵심은 반복되는 일을 "다음에 다시 쓸 수 있는 절차"로 저장하는 것입니다.

skill로 만들기 좋은 작업은 입력은 매번 달라지지만 처리 순서와 출력 형식은 거의 같은 일입니다. 예를 들어 회의 메모를 액션아이템으로 바꾸기, 고객 VOC를 분류하기, 초안을 브랜드 톤에 맞게 다듬기, 주간 업데이트를 임원 요약으로 바꾸기, 자료 묶음을 근거 기반 브리프로 정리하기가 그렇습니다.

반대로 아직 실험 중인 업무, 매번 요구사항이 크게 달라지는 업무, 한 번만 할 일은 skill로 만들 필요가 없습니다. 너무 많은 skill은 오히려 팀을 혼란스럽게 합니다. 팀원은 어떤 skill을 써야 하는지 찾다가 시간을 잃고, 비슷한 skill이 여러 개 생겨 기준이 갈라집니다.

좋은 skill은 이름만 봐도 언제 쓰는지 알 수 있어야 합니다.

skill의 기본 구조는 단순할수록 좋습니다.

Name: meeting-notes-to-actions-risks-owners

One-line job description:
회의 메모를 결정 사항, 액션아이템, 리스크, 확인 필요 항목으로 정리한다.

Inputs expected:
- 회의 메모 또는 전사 텍스트
- 회의 목적
- 참석자와 역할
- 외부 공유 여부

Output format:
1. 한 줄 결론
2. 결정 사항
3. 액션아이템 표
4. 리스크와 쟁점
5. 확인 필요 사항
6. 외부 공유 전 삭제해야 할 민감 정보

Rules:
- 메모에 없는 결정은 만들어내지 않는다.
- 담당자나 마감일이 없으면 '확인 필요'로 표시한다.
- 내부 발언과 외부 공유용 문장을 구분한다.
- 수치와 날짜는 원문 그대로 보존한다.

Failure conditions:
- 회의 메모가 너무 짧아 결정과 액션을 구분할 수 없는 경우
- 참석자나 맥락이 없어 책임자를 추정해야 하는 경우
- 민감정보 포함 여부를 판단하기 어려운 경우

이 구조는 간단하지만 강력합니다. 팀원은 더 이상 "회의록 정리 잘하는 프롬프트"를 기억할 필요가 없습니다. 정해진 skill을 호출하거나, 같은 템플릿을 Project 안에서 사용하면 됩니다.

Projects, custom GPTs, skills를 어떻게 구분할 것인가

세 도구를 헷갈리면 운영이 꼬입니다. 모든 일을 Project로 해결하려 하면 프로젝트가 비대해지고, 모든 일을 custom GPT로 만들려 하면 관리되지 않는 GPT가 늘어나며, 모든 프롬프트를 skill로 만들려 하면 재사용 체계가 복잡해집니다.

가장 쉬운 구분은 이렇습니다. Projects는 맥락을 담고, custom GPTs는 역할을 담고, skills는 절차를 담습니다.

예를 들어 "A사 제안서 작성"은 Project입니다. 그 안에는 A사의 요구사항, 회의록, 제안서 초안, 경쟁사 정보, 내부 가격 검토가 들어갑니다. 그런데 제안서 문체를 팀 기준에 맞게 다듬는 일은 여러 고객사 제안에서 반복됩니다. 이것은 "제안서 문체 리뷰어" custom GPT나 "proposal-draft-review" skill로 만들 수 있습니다. 또 제안서 안의 긴 회의 메모를 액션아이템으로 바꾸는 절차는 skill에 가깝습니다.

도구 선택의 기준은 다음처럼 정리할 수 있습니다.

다시는 돌아오지 않을 질문인가? → 일반 채팅
이번 주나 다음 달에도 이어질 과업인가? → Project
여러 과업에서 같은 역할이 반복되는가? → custom GPT
같은 입력을 같은 형식으로 바꾸는 절차가 반복되는가? → skill
팀원이 같은 맥락을 함께 봐야 하는가? → 공유 Project

이 구분이 자리 잡으면 팀의 AI 사용이 훨씬 덜 혼란스러워집니다. 누군가는 Project를 만들고, 누군가는 custom GPT를 만들고, 누군가는 skill을 만들더라도 서로 겹치는 일을 줄일 수 있습니다.

팀 지식 기반은 '정답 창고'가 아니라 '관리되는 정원'이다

AI에 넣는 팀 지식은 정답 창고가 아니라 정원에 가깝습니다. 심고, 솎아 내고, 물을 주고, 계절이 바뀌면 갈아엎어야 합니다. 한 번 넣어 두면 영원히 정확한 자료는 거의 없습니다. 제품 기능은 바뀌고, 가격 정책은 조정되고, 브랜드 메시지는 새로워지고, 법무 검토 의견도 상황에 따라 달라집니다.

그래서 팀 지식 기반에는 소유자가 있어야 합니다. "모두가 관리한다"는 말은 실제로는 아무도 관리하지 않는다는 뜻이 되기 쉽습니다. 브랜드 가이드는 브랜드팀, 제품 FAQ는 제품마케팅팀, 보안 안내는 보안팀, 고객 응대 정책은 CX팀처럼 소유자를 정해야 합니다. Project나 custom GPT에 들어가는 핵심 문서도 누가 최신성을 책임지는지 표시해야 합니다.

문서마다 갱신 주기도 다르게 잡아야 합니다. 법률·정책·가격처럼 변동의 영향이 큰 문서는 자주 점검해야 하고, 문체 가이드나 보고서 템플릿은 상대적으로 천천히 바뀔 수 있습니다. 중요한 것은 "언젠가 업데이트"가 아니라 "언제 누가 확인"을 정하는 것입니다.

팀 지식 기반 점검표는 다음과 같이 만들 수 있습니다.

이 표 하나만 있어도 AI 활용의 신뢰도가 올라갑니다. AI가 틀리는 이유 중 상당수는 모델이 똑똑하지 않아서가 아니라, 사람이 모순된 자료를 넣어 놓고 "알아서 잘 판단하라"고 기대하기 때문입니다.

승인 절차가 없으면 AI는 품질을 확장하지 못한다

AI는 초안을 빠르게 확장합니다. 하지만 승인 절차가 없으면 오류도 빠르게 확장합니다. 특히 외부 고객에게 나가는 문서, 법률·금융·의료·교육처럼 영향이 큰 문서, 브랜드 평판에 영향을 주는 콘텐츠는 반드시 인간 검토 단계를 둬야 합니다.

팀 차원의 품질 관리는 세 단계로 생각하면 쉽습니다. 첫째, AI가 초안을 만듭니다. 둘째, 담당자가 사실과 맥락을 검토합니다. 셋째, 책임자가 외부 발송 또는 공식 반영을 승인합니다. 간단하지만 이 흐름을 명시하지 않으면 AI 결과물이 "누가 봤는지 모르는 문서"로 떠돌게 됩니다.

중요한 산출물에는 다음 상태 표시를 붙이는 것이 좋습니다.

• 초안: AI 또는 작성자가 만든 1차 결과물

• 검토 중: 담당자가 사실, 톤, 정책 적합성을 확인하는 문서

• 승인본: 책임자가 공식 사용을 허가한 문서

• 폐기: 더 이상 사용하면 안 되는 문서

• 보관: 참고는 가능하지만 최신 기준으로 쓰면 안 되는 문서

이 상태 표시는 Project 안의 파일명, 문서 첫머리, 지식 색인에 모두 반영되어야 합니다. "승인본"이라는 단어를 쉽게 쓰면 안 됩니다. 승인본은 실제 승인 절차를 통과한 문서여야 합니다.

외부 발송 전 검토 체크리스트도 Project 지시문이나 skill에 포함해 두면 좋습니다.

외부 발송 전 검토 체크리스트

1. 사실성
- 수치, 날짜, 가격, 인명, 회사명이 원문과 일치하는가?
- 최신 자료를 기준으로 작성했는가?
- 추정한 내용을 사실처럼 쓰지 않았는가?

2. 보안과 개인정보
- 개인정보나 민감정보가 포함되어 있지 않은가?
- 계약상 비밀 또는 내부 전략이 드러나지 않는가?
- 외부 공유가 허용된 자료만 사용했는가?

3. 책임과 표현
- 확정되지 않은 내용을 약속하지 않았는가?
- 법률·의료·금융 판단처럼 전문가 책임이 필요한 내용을 단정하지 않았는가?
- 고객에게 오해를 줄 수 있는 과장 표현이 없는가?

4. 문체와 브랜드
- 브랜드 톤과 맞는가?
- 불필요하게 공격적이거나 방어적인 표현은 없는가?
- 한국어 문장이 자연스럽고 명확한가?

이 체크리스트는 AI에게만 맡길 것이 아니라 사람이 함께 써야 합니다. AI는 체크리스트를 적용해 위험 신호를 잘 찾아낼 수 있지만, 최종 책임은 조직에 있습니다.

버전 관리는 프롬프트에도 필요하다

팀은 코드와 문서에는 버전 관리를 하면서, AI 지시문에는 버전 관리를 하지 않는 경우가 많습니다. 하지만 프로젝트 지시문, custom GPT 설정, skill 템플릿도 업무 기준입니다. 바뀌면 결과물이 달라집니다. 누가 언제 무엇을 바꿨는지 모르면 품질 문제가 생겼을 때 원인을 찾기 어렵습니다.

버전 관리는 복잡할 필요가 없습니다. 처음에는 변경 이력 표 하나면 충분합니다.

변경 이력을 남기면 두 가지 장점이 있습니다. 첫째, 팀원이 왜 규칙이 바뀌었는지 이해합니다. 둘째, 좋은 변경과 나쁜 변경을 되돌아볼 수 있습니다. AI 운영도 결국 실험입니다. 어떤 지시문이 결과를 좋아지게 했고, 어떤 지시문이 오히려 답변을 장황하게 만들었는지 기록해야 합니다.

custom GPT나 skill도 마찬가지입니다. "브랜드 문안 리뷰어 v1.0"이 너무 보수적으로 모든 문장을 고치려 한다면, v1.1에서는 "수정이 필요한 문장만 고치고, 좋은 문장은 유지한다"는 규칙을 추가할 수 있습니다. "회의록 정리 skill"이 결정 사항을 과도하게 추정한다면, "결정이라는 단어가 명시되었거나 참석자 합의가 분명한 경우만 결정 사항으로 분류한다"는 규칙을 넣을 수 있습니다.

좋은 응답과 실패 사례를 모아야 다음 버전이 좋아진다

팀의 AI 활용이 성숙해지는 속도는 프롬프트를 얼마나 많이 만들었느냐보다 피드백을 얼마나 잘 모았느냐에 달려 있습니다. 좋은 응답은 왜 좋았는지 남겨야 하고, 실패한 응답은 왜 실패했는지 기록해야 합니다. 그래야 다음 버전의 Project 지시문, custom GPT, skill이 개선됩니다.

실패 사례는 비난용 자료가 아닙니다. 팀의 기준을 더 선명하게 만드는 학습 자료입니다. 예를 들어 AI가 고객 응대 초안에서 너무 사과를 많이 해 법적 책임을 인정하는 듯한 문장을 만들었다면, 이것은 중요한 실패 사례입니다. "사과와 책임 인정 표현을 구분하라"는 규칙을 추가해야 합니다. AI가 보고서에 없는 수치를 만들어 넣었다면, "수치가 없으면 정성 판단으로 표시하라"는 규칙을 강화해야 합니다.

피드백 수집 양식은 간단하면 됩니다.

AI 응답 피드백 기록

1. 사용한 Project/custom GPT/skill:
[이름과 버전]

2. 업무 유형:
[예: 고객 응대, 보고서 요약, 캠페인 문안]

3. 결과 평가:
- 좋았던 점:
- 부족했던 점:
- 위험했던 점:

4. 수정이 필요한 규칙:
[추가/수정/삭제할 지시문]

5. 재사용할 좋은 예시:
[있으면 붙여넣기]

6. 다음 버전 반영 여부:
[반영 / 보류 / 폐기]

이렇게 모은 피드백은 팀의 AI 운영 회의에서 다룹니다. 거창한 회의가 아니어도 됩니다. 2주에 한 번 30분만 써도 충분합니다. 가장 자주 쓰는 Project 1개, custom GPT 1개, skill 1개를 골라 실패 사례와 개선안을 확인하면 됩니다. AI 도구는 한 번 만들어 배포하는 제품이 아니라 계속 다듬는 업무 인프라입니다.

팀별 적용 예시: 캠페인 운영팀의 한 달

조금 더 구체적으로 보겠습니다. 한 마케팅 캠페인 운영팀이 "2026년 여름 신규 고객 확보 캠페인" Project를 만든다고 해 봅시다. 이 Project에는 캠페인 목표, 타깃 페르소나, 제품 소개서, 브랜드 가이드, 이전 캠페인 회고, 채널별 성과 자료가 들어갑니다. 프로젝트 지시문에는 "모든 문안은 과장 없이 실무적 혜택을 중심으로 작성하고, 성과 수치는 제공된 자료에 있는 것만 사용한다"고 적습니다.

이 팀은 동시에 "브랜드 문안 리뷰어" custom GPT를 운영합니다. 이 GPT는 캠페인이 바뀌어도 계속 쓰입니다. SNS 문안, 랜딩페이지 헤드라인, 이메일 제목을 넣으면 브랜드 톤과 금지 표현을 점검하고 수정안을 제안합니다. 또한 "campaign-brief-from-notes" skill을 만들어 회의 메모를 캠페인 브리프로 바꾸는 절차를 표준화합니다.

한 달 동안의 흐름은 이렇습니다. 첫째 주에는 Project에 자료를 넣고 캠페인 브리프 초안을 만듭니다. 둘째 주에는 팀 회의 메모를 skill로 정리해 타깃, 메시지, 채널 가설을 확정합니다. 셋째 주에는 custom GPT로 채널별 문안을 검토하고, Project 안에 승인본과 폐기안을 구분해 저장합니다. 넷째 주에는 성과 자료를 넣고 회고 보고서를 작성합니다. 이때 좋은 문안과 실패한 문안은 다음 캠페인의 참고 자료가 됩니다.

이 팀이 얻는 것은 단순한 시간 절약이 아닙니다. 더 중요한 변화는 기억의 위치가 바뀐다는 점입니다. 예전에는 캠페인 노하우가 담당자의 머릿속과 개인 채팅창에 있었습니다. 이제는 Project, custom GPT, skill, 피드백 기록에 나뉘어 저장됩니다. 담당자가 바뀌어도 팀의 기준이 남습니다. 신규 팀원이 들어와도 과거의 시행착오를 다시 반복할 가능성이 줄어듭니다.

팀 협업에서 가장 흔한 실패 패턴

팀 AI 협업은 도구를 도입했다고 저절로 되지 않습니다. 오히려 팀 단위에서는 개인 사용보다 실패 패턴이 더 선명하게 드러납니다.

첫 번째 실패는 "모든 것을 하나의 Project에 넣는 것"입니다. 처음에는 편합니다. 하지만 곧 자료가 섞이고, AI가 엉뚱한 맥락을 끌어오며, 팀원이 어떤 대화가 최신인지 알 수 없게 됩니다. 이 경우 Project를 과업 기준으로 쪼개고, 공통 규칙은 custom GPT나 skill로 빼야 합니다.

두 번째 실패는 "custom GPT를 너무 많이 만드는 것"입니다. 누구나 만들 수 있다는 장점은 누구나 중복된 것을 만들 수 있다는 뜻이기도 합니다. 브랜드 리뷰 GPT가 세 개, 회의록 GPT가 네 개 생기면 팀은 어느 것을 써야 할지 모릅니다. 팀용 custom GPT는 목록을 관리하고, 소유자와 상태를 표시해야 합니다.

세 번째 실패는 "자료를 넣기만 하고 정리하지 않는 것"입니다. 오래된 문서, 모순된 가이드, 임시 초안이 기준 자료처럼 남으면 AI는 그럴듯하지만 잘못된 답을 냅니다. 지식 기반에는 소유자, 최신본, 적용 범위, 폐기 기준이 필요합니다.

네 번째 실패는 "AI 결과물을 승인본처럼 쓰는 것"입니다. 특히 고객 발송문, 계약 관련 문서, 정책 설명, 가격 안내는 위험합니다. AI 초안은 검토 전까지 초안일 뿐입니다. 팀은 상태 표시와 승인 절차를 운영해야 합니다.

다섯 번째 실패는 "좋은 답변을 저장하지 않는 것"입니다. 팀원이 우연히 좋은 프롬프트와 답변을 얻었는데 그대로 지나가면, 다음 사람은 다시 같은 시행착오를 합니다. 좋은 응답은 예시 자료로 저장하고, 실패 사례는 금지 규칙으로 바꾸어야 합니다.

팀 운영표 만들기

이제 자신의 팀에 맞게 운영표를 만들어 봅시다. 아래 표는 Projects, custom GPTs, skills를 함께 관리하기 위한 기본 양식입니다.

이 표를 만들면 팀의 AI 자산이 보이기 시작합니다. 지금 어떤 Project가 살아 있는지, 어떤 custom GPT가 공식 도구인지, 어떤 skill이 반복 업무에 쓰이는지 한눈에 알 수 있습니다. 또한 오래 쓰지 않는 도구를 폐기하고, 중복된 도구를 합치고, 소유자가 없는 도구를 정리할 수 있습니다.

시작은 작게, 기준은 분명하게

팀 단위 AI 협업을 시작할 때 가장 좋은 방법은 모든 업무를 한꺼번에 바꾸는 것이 아닙니다. 가장 반복적이고, 품질 편차가 크고, 검토 기준이 비교적 분명한 업무 하나를 고르는 것입니다. 예를 들어 회의록 정리, 고객 문의 답변 초안, 주간 보고 요약, 캠페인 문안 리뷰가 좋습니다.

첫 2주 동안은 하나의 Project와 하나의 reusable rule만 운영해 보십시오. reusable rule은 custom GPT일 수도 있고, skill일 수도 있고, 단순한 프로젝트 내부 템플릿일 수도 있습니다. 중요한 것은 이름을 붙이고, 소유자를 정하고, 좋은 예시와 실패 사례를 모으는 것입니다.

작게 시작하되 기준은 분명해야 합니다. 어떤 자료를 넣을 수 있는지, 누가 수정할 수 있는지, 어떤 결과물은 반드시 사람이 검토해야 하는지, 변경 이력은 어디에 남길지 정해야 합니다. 이 기준 없이 도구만 열어 주면 팀은 빠르게 움직이는 것처럼 보이지만, 실제로는 서로 다른 기준으로 AI를 쓰게 됩니다.

팀에서 AI를 잘 쓰는 길은 화려한 자동화에서 시작하지 않습니다. 같은 자료를 보고, 같은 기준으로 묻고, 같은 형식으로 저장하고, 같은 방식으로 검토하는 데서 시작합니다. Projects는 그 맥락을 담는 그릇이고, custom GPTs와 skills는 반복되는 기준을 재사용하는 장치입니다. 여기에 권한, 승인, 버전 관리, 피드백이 붙을 때 개인의 요령은 비로소 팀의 자산이 됩니다.

다음 장에서는 이 팀 작업 공간이 외부 도구와 연결될 때 어떤 변화가 생기는지 살펴봅니다. 과거의 플러그인에서 오늘의 앱, 커넥터, MCP로 이어지는 흐름을 이해하면 ChatGPT는 더 이상 채팅창 안의 도우미가 아니라 업무 시스템과 연결되는 작업 허브로 보이기 시작합니다.

참고

¹Projects - Resource | OpenAI Academy

²How to Share ChatGPT Projects for Team Collaboration

³Custom GPTs - Resource | OpenAI Academy

⁴Using skills - OpenAI

⁵How to Use ChatGPT Projects and Skills for Recurring Work in 2026