Gems에서 Skills로: Gemini 맞춤 설정이 재사용 가능한 작업 흐름으로 바뀐다

오리지널 편집용 일러스트입니다. 재사용 가능한 지침이라는 개념을 표현하며 Gemini 화면이나 내부 아키텍처를 보여주는 스크린샷이 아닙니다.

맞춤 설정은 소비자용 AI에서 가장 흥미로운 영역 중 하나가 되어가고 있습니다. 유용한 도우미는 많은 것을 아는 데 그치지 않고, 사람이 반복 작업을 어떤 방식으로 처리하고 싶은지 기억합니다. 리서치 브리핑, 편집 검토, 프로젝트 인수인계에는 각각 다른 기준이 필요합니다. 매 대화에서 그 기준을 되풀이하면 번거롭고, 암묵적으로만 두면 결과가 일관되지 않습니다.

Google이 Gems에서 Skills로 전환하는 것은 이 문제를 반영합니다. 맞춤형 도우미 하나하나를 완전히 별개의 공간으로 취급하는 대신, 재사용 가능한 지침을 이미 진행 중인 대화에 포함할 수 있습니다. 인터페이스 차원에서는 작아 보이지만 사람들이 작업 흐름을 구성하는 방식에는 더 큰 의미가 있습니다. 전환 작업도 생깁니다. 익숙한 지침 모음이 자동으로 명확하고 이식 가능하며 시험할 수 있는 스킬이 되는 것은 아닙니다.

계정 유형에 따라 배포 일정이 다르다

Google은 Gemini 앱의 Skills를 2026년 10월 13일부터 순차적으로 배포해 11월 중순까지 완료할 예정이며, Workspace용 Skills 배포는 10월 5일 시작합니다. 계정마다 제공 시점이 다를 수 있습니다. Google Workspace 공지

Google 도움말에 따르면 Gems 전환은 개인 계정은 2026년 11월, Workspace 비즈니스·엔터프라이즈·비영리 계정은 2027년 3월, Workspace 교육 계정은 2027년 6월에 예정되어 있습니다. 이 전환 일정은 Skills 기능 출시 일정과 별개입니다. 본인 계정에 해당하는 안내를 확인하고, 관리형 계정의 이용 가능 여부는 관리자에게 문의하세요. Gems에서 Skills로 전환하기 도움말

전환에 앞서 각 Gem의 이름, 지침, 참고 파일을 읽을 수 있는 형태로 보관하세요. 계정에서 Skills를 사용할 수 있게 되면 원래의 목적을 유지하고 새 작업 흐름과 비교하는 데 도움이 됩니다.

스킬은 반복 가능한 작업을 설명해야 한다

Google은 Skills를 여러 채팅에서 사용할 수 있고, 명시적으로 선택하거나 관련 있을 때 적용하며, 더 복잡한 작업을 위해 조합할 수 있는 재사용 가능한 지침으로 설명합니다. 현재 제작 가이드는 선택적으로 지원되는 참고 자료를 포함할 수 있는 루트 SKILL.md 파일을 지원하며 업로드 스크립트의 외부 동작에 제한을 둡니다. 이 내용은 지침 모음과 웹사이트를 조작할 권한을 가진 제한 없는 프로그램을 구분해야 한다는 점을 보여줍니다. Gemini 앱에서 Skills 만들기 및 관리하기

가장 흔한 실수는 긴 프롬프트마다 스킬을 만드는 것입니다. 길이가 핵심은 아닙니다. 유용한 스킬은 알아볼 수 있는 작업, 명확한 입력, 결과물의 기준, 행동하지 말아야 하는 조건을 갖춥니다. 이런 요소가 빠지면 자동 재사용이 시간을 절약하기보다 모호함을 반복할 수 있습니다.

가상의 “리서치 브리프” 맞춤 설정을 생각해 보세요. 단순히 “철저하게 조사하라”고 해서는 안 됩니다. 조사 질문, 기준일, 1차 출처 링크, 확인된 사실과 해석의 구분을 요구할 수 있습니다. 근거를 찾을 수 없을 때 출처를 지어내지 못하게 할 수도 있습니다. 이런 요구 사항이 있으면 결과를 검토하기도 작업을 알아보기도 쉬워집니다.

이번에는 별도의 “편집 스타일” 맞춤 설정을 생각해 보세요. 짧은 문단, 쉬운 표현, 일관된 제목을 지정할 수 있습니다. 이를 근거 요건과 분리하면 재사용이 유연해집니다. 사용자는 기술 조사와 뉴스 브리프에 같은 근거 기준을 적용하면서 문체는 다르게 선택할 수 있습니다. 지침끼리 충돌하지 않는다면 이것이 조합의 장점입니다.

문구를 복사하기 전에 의도를 정리하라

Gem을 옮기기 전에 무엇을 잘하는지 적어보세요. 어떤 작업에 사용하나요? 보통 어떤 정보를 제공하나요? 결과의 어느 부분을 늘 고치나요? 어떤 참고 파일이 꼭 필요하고, 몇 달 전에 한 번 쓰려고 추가한 파일은 무엇인가요? 이 목록을 작성하는 편이 누구도 이해하지 못하는 우연한 복잡성을 담은 프롬프트를 보존하는 것보다 가치 있습니다.

지속적으로 적용할 규칙과 일시적인 맥락을 분리하세요. “회사의 주장을 독립적인 측정 결과와 구분한다”는 지속적인 조사 규칙입니다. “우리 출시일은 다음 주 목요일이다”는 달력이 바뀌는 순간 틀릴 수 있는 일시적 맥락입니다. 한 번 유용했다는 이유만으로 재사용 지침이 오래된 사실을 새 작업에 조용히 가져오게 해서는 안 됩니다.

예시 안에 사적인 정보가 들어 있지 않은지 확인하세요. 실제 고객 이름, 내부 주소, 아직 공개되지 않은 사업 계획이 편리한 예시로 원래 프롬프트에 들어갔을 수 있습니다. 그렇다고 재사용 설정에 꼭 포함해야 하는 것은 아닙니다. 불필요하게 구체적인 내용은 중립적인 예시로 바꾸고, 필요한 민감 정보는 적절한 계정 및 접근 통제 아래 두세요.

정리 과정에서 문서로 남기지 않았던 가정도 찾아야 합니다. 동료가 항상 최종 수치를 확인했거나, 시작하기 전에 늘 원본 문서를 제공했을 수도 있습니다. 새 작업 흐름에서 스킬을 여러 대화에 사용할 수 있게 되면 그런 가정이 더는 성립하지 않을 수 있습니다. 주변 맥락이 그대로일 것이라고 기대하지 말고 요구 사항을 명시적으로 바꾸세요.

다른 곳에서도 읽을 수 있는 사본을 보관하라

오리지널 전환 체크리스트입니다. 비교는 제안된 검토 과정이지 Google이 보고한 계정 이전 결과가 아닙니다.

이식 가능한 사본이 있으면 인터페이스가 바뀌어도 설정을 살펴볼 수 있습니다. 이름, 목적, 지침, 참고 파일 목록, 작업 예시 몇 가지를 담을 수 있습니다. 특정 제품에 의존하지 않고 읽을 수 있는 일반적인 형식을 사용하세요. 어떤 제품으로든 가져올 수 있다는 약속은 아닙니다. 가져오기 방식이 달라져도 맞춤 설정의 의미를 보존하는 방법입니다.

참고 파일마다 왜 포함했는지, 마지막으로 언제 검토했는지 기록하세요. 정책 문서는 한 조직에는 권위 있는 자료지만 다른 곳에는 무관할 수 있습니다. 스타일 가이드는 오래될 수 있습니다. 표에는 팀 밖으로 공유하면 안 되는 정보가 담겨 있을 수도 있습니다. 파일 이름만으로는 이런 제약이 드러나지 않는 경우가 많습니다.

후보 설정을 평가하는 동안 원래 설정을 유지하세요. 문구를 그대로 보존하고도 주변 모델·도구·대화 맥락이 달라 동작이 바뀔 수 있습니다. 되돌릴 수 있는 참고본이 있으면 지침 문제와 플랫폼 변화를 구별하기 쉽습니다. 성급하게 다시 쓴 내용이 유일하게 남은 버전이 되는 일도 막아줍니다.

이식성을 제한 없는 배포와 혼동하지 마세요. 설정에 라이선스가 있는 참고 자료나 사적인 정보가 포함될 수 있습니다. 텍스트 파일로 만들 수 있다는 이유만으로 게시하거나 다른 서비스에 보내도 되는 것은 아닙니다. 동료와 공유하거나 출처가 낯선 사람이 만든 스킬을 가져오기 전에 내용과 목적지를 검토하세요.

간결한 템플릿은 작업 규칙을 명확히 보여준다

다음 예시는 의도적으로 최소화한 오리지널 리서치 템플릿입니다. 셸에서 실행할 명령이 아니라 로컬 편집기에서 수정할 내용입니다. Google이 이 제목을 정확히 요구한다는 뜻이 아니며, 가져오기 전에 현재 플랫폼 가이드와 대조해야 합니다.

---
name: source-linked-research
description: Draft a research brief that separates evidence from interpretation.
---

# 입력
- 조사 질문과 대상 독자.
- 기준일과 승인된 출처 또는 검색 범위.

# 방법
- 제품에 관한 사실 주장은 1차 출처를 우선합니다.
- 공지, 측정 결과, 개인 분석을 구분해 표시합니다.
- 근거나 인용을 지어내지 말고 확인할 수 없는 부분을 표시합니다.

# 출력
- 핵심 결과, 근거 링크, 미해결 질문.
- 별도 승인 없이 외부에 제출하거나 게시하지 않습니다.

가치는 특정 문구에 있지 않습니다. 작업 계약을 눈에 보이게 한다는 점에 있습니다. 독자는 입력을 파악하고, 근거가 부족할 때 적용할 규칙을 살펴보고, 게시가 별도의 행동임을 알 수 있습니다. 다음 편집자는 관련 없는 페르소나 지침이 가득한 페이지를 풀어헤치지 않고 요구 하나를 바꿀 수 있습니다.

실패를 드러낼 수 있도록 예시를 작게 유지하세요. 출처를 연결하는 조사라면 날짜가 서로 충돌하는 사례와 주장에 1차 출처가 없는 사례를 넣으세요. 문서 검토 작업이라면 요구 사항이 모호한 파일을 예시로 사용하세요. 쉽고 완전한 입력에서만 성공하는 템플릿으로는 일상 작업을 잘 처리하는지 거의 알 수 없습니다.

스킬 파일에 비밀, 인증 토큰, 제한 없는 도구 지침을 넣지 마세요. 재사용 지침은 작업을 설명해야지 자격 증명 저장소가 되어서는 안 됩니다. 비공개 정보 접근이 필요한 작업이라면 플랫폼의 적절한 권한과 계정 통제를 사용해야 합니다. 편리함 때문에 민감한 자료가 설정 안에 숨겨져서는 안 됩니다.

스킬을 조합하면 충돌도 함께 조합될 수 있다

실제 작업은 여러 차원을 가지므로 조합은 매력적입니다. 보고서에 조사 기준, 조직의 문체, 대상 독자에 맞춘 설명이 모두 필요할 수 있습니다. 하지만 지침끼리 충돌할 수 있습니다. 하나는 짧은 답변을 요구하고 다른 하나는 포괄적인 감사를 요구하거나, 하나는 단호한 권고를 권하면서 다른 하나는 미해결 불확실성을 두드러지게 남기라고 할 수 있습니다. 유용한 작업 흐름은 임의로 절충하지 않고 충돌을 알아차립니다.

많은 지침을 한꺼번에 추가하기 전에 서로 보완하는 스킬 두 개부터 시작하세요. 근거 기준이 문체 지침을 적용한 뒤에도 유지되는지, 결과가 대상 독자에게 계속 적합한지 살펴보세요. 결과가 예상과 다르게 바뀌면 각 스킬을 따로 시험하세요. 그러지 않으면 실수의 원인을 찾기 어려워지고, 사용자는 늘어나는 지침 더미에 더 많은 지침을 보탤 수 있습니다.

평가할 때는 명시적으로 활성화하는 것이 도움이 될 수 있습니다. 관련성이 높을 때 자동으로 선택되는 기능은 편리하지만 어떤 지침이 적용됐는지 불분명해질 수 있습니다. 중요한 작업이라면 사용할 스킬을 기록하고 결과가 그 지침을 따르는지 확인하세요. 이는 검토 권고이지 특정 인터페이스가 완전한 지침 이력을 제공한다는 주장이 아닙니다.

스킬이 무관한 작업에 적용되지 않도록 범위를 좁히세요. “금융 조사” 규칙이 창작 글쓰기 대화의 방향을 조용히 바꿔서는 안 됩니다. 고객 지원 템플릿이 개인적인 질문을 공식 문의로 바꿔서도 안 됩니다. 좋은 개인화에는 맞춤 설정이 무관한 때를 아는 일도 포함됩니다.

이전 작업 흐름을 버리기 전에 비교 작업을 하라

실용적인 이전 검토에서는 변경 전후에 작고 같은 입력 집합을 사용합니다. 일반 사례 하나, 불완전한 입력 하나, 예전에 수정이 필요했던 경계 사례 하나를 포함하세요. 형식만이 아니라 내용을 비교합니다. 새 버전이 필요한 주의 사항을 보존했나요? 빠진 내용을 지어냈나요? 외부 행동에 관한 경계를 유지했나요?

조사 작업 흐름에서는 결과물의 핵심 근거가 되는 링크를 하나씩 살펴보세요. 편집 작업에서는 바꿔 쓴 뒤에도 의도한 의미가 유지되는지 확인하세요. 내부 인수인계에서는 책임과 미해결 질문이 완료된 업무로 바뀌지 않았는지 확인하세요. 이런 검사는 일반적인 “품질” 점수 하나에 기대지 말고 작업에 맞춰야 합니다.

비교에 사용한 날짜, 계정 유형, 설정 버전을 기록하세요. 그러면 나중에 변화를 조사하기 쉽습니다. 업데이트 후 결과가 나빠졌다면 지침이 바뀌었는지, 원본 자료가 바뀌었는지, 플랫폼이 바뀌었는지 물을 수 있습니다. 기준점이 없으면 매번 예전 동작을 불확실한 기억에서부터 되짚게 됩니다.

개인이 쓸 때 대규모 평가 시스템이 필요한 것은 아닙니다. 짧은 체크리스트와 저장된 예시 몇 개만으로도 명백한 퇴행을 잡을 수 있습니다. 중요한 작업 흐름을 가진 팀에는 더 공식적인 검토가 필요할 수 있지만 원칙은 같습니다. 파일을 가져온 순간이 아니라 의도한 동작을 확인한 때에 이전이 완료됩니다.

개인화에는 편의뿐 아니라 관리 책임도 필요하다

이 전환은 매번 빈 프롬프트에서 시작하는 대신 여러 작업에 걸쳐 재사용 가능한 작업 방식을 가져가는 미래를 가리킵니다. 유용할 수 있습니다. 동시에 전통적인 애플리케이션처럼 보이지 않으면서 중요한 결정에 영향을 미치는 지침과 참고 자료 모음이라는 새로운 축적형 소프트웨어를 만들 수도 있습니다.

누군가는 그 모음을 관리해야 합니다. 참고 파일은 누가 업데이트하나요? 정책이 바뀌면 공유 스킬을 누가 검토하나요? 가져온 지침이 적절한지는 누가 판단하나요? 맞춤 설정을 가벼운 프롬프팅으로 여길 때는 이런 질문을 미루기 쉽습니다. 같은 설정이 팀의 일상 업무에서 반복 사용되면 더는 외면하기 어렵습니다.

개인에게 필요한 책임은 크지 않을 수 있습니다. 읽을 수 있는 사본을 보관하고, 오래된 가정을 지우고, 중요한 결과를 검증하면 됩니다. 조직에는 승인된 설정, 접근 규칙, 검토 절차가 필요할 수 있습니다. 어느 쪽이든 개인화를 정확성 보장으로 취급해서는 안 됩니다. 익숙한 도우미도 낯선 실수를 할 수 있습니다.

이름만 옮기지 말고 작업 흐름을 옮겨라

가장 유용한 준비는 Gem이 수행하는 작업을 보존하고 요구 사항을 명시하는 것입니다. 참고본을 보관하고, 의존하는 파일을 확인하고, 안정적인 규칙과 일시적인 사실을 분리하고, 대표 입력으로 후보를 시험하세요. 그다음 단일한 전 세계 일정이 있다고 가정하지 말고 실제 계정에 해당하는 배포 정보를 확인하세요.

Skills를 사용하면 맞춤 설정을 더 재사용하고 조합하기 쉬워질 수 있습니다. 이점은 “skill”이라는 단어 자체가 아니라 명확한 작업 계약과 세심한 검토에서 나옵니다. AI 도구가 개인화될수록 이해하고 관리하고 검증할 수 있는 설정이 중요합니다. 새 화면에 프롬프트를 복사하는 것보다 그 안에 담긴 이해를 옮기는 편이 중요합니다.

전환 결정을 한곳에 모아두세요

리서치·설정 메모·검토 결정을 정리하는 독자라면 Telli.sh를 선택적 작업 공간으로 활용할 수 있습니다. 검토 노트 만들기.