2026년 4월 15일 기준 Google은 하루 전인 2026년 4월 14일 Skills in Chrome을 발표했고, Gemini in Chrome 안에서 저장한 프롬프트를 / 또는 +로 다시 실행하는 흐름을 내놨다.
공식 블로그 설명만 보면 꽤 솔깃하다.
자주 쓰는 프롬프트를 저장해두고, 현재 보고 있는 페이지나 선택한 탭들에 바로 적용한다.
문제는 여기서 거의 바로 생긴다.
반복 프롬프트를 다 저장해도 될 것 같고, 브라우저 안에서 다 끝낼 수 있을 것 같고, 심지어 어떤 사람은 이걸 바로 에이전트 자동화처럼 받아들이기 쉽다.
근데 공식 문서를 조금만 더 보면 레이어가 셋으로 갈라져 있다.
하나는 저장된 프롬프트 재사용이고,
하나는 탭 컨텍스트 공유고,
마지막 하나는 auto browse로 실제 행동까지 가는 흐름이다.
이 셋을 섞으면 원클릭 워크플로가 아니라 원클릭 혼선이 된다.
특히 TECHTAEK 관점에선 새 기능 소개보다 어떤 프롬프트를 진짜 workflow로 승격할지 판단 기준이 먼저다.
그래서 이 글은 “와 신기하다” 류의 출시 메모가 아니라, 반복 프롬프트를 Skills로 올릴지 말지 결정할 때 내가 먼저 보게 되는 기준을 정리한 운영 메모다.
참고로 이 글은 설치 후기보다 운영 기준에 가깝다.
이유는 단순하다.
2026-04-15 기준 공식 도움말만 봐도 Gemini in Chrome 자체가 점진 배포 중이고, Skills도 영어 환경과 데스크톱 조건이 걸려 있고, auto browse는 여기에 더해 개인 계정, AI Pro 또는 Ultra, Safe Browsing 설정까지 붙는다.
즉, 지금 이 기능의 핵심 질문은 되냐 보다 어디까지 workflow로 승격해도 되냐 에 더 가깝다.
한 줄로 먼저 적으면 이렇다.
입력 형태가 고정되고,탭 컨텍스트가 명확하고,결과가 초안 수준에서 닫히는 프롬프트만 Skills로 올리는 편이 낫다.
지금 결론
Skills는 브라우저 안의 저장된 프롬프트 레이어로 보면 편하다.Gemini in Chrome의 탭 공유 기능이 붙으면서, 비교·요약·추출 같은 반복 작업은 one-click으로 꽤 자연스럽게 바뀐다.- 하지만
auto browse는 다른 층위다. 계정, 권한, 데이터 공유, 확인 단계, 위험 부담이 한 번에 커진다. - 그래서 내 기준은 단순하다.
반복되지만 저위험인 프롬프트만 Skill로 올리고,민감하거나 가변적인 작업은 여전히 프롬프트 파일이나 문서형 SSOT에 남긴다.
2026년 4월 15일 기준 공식 문서가 말하는 구조
먼저 팩트부터 정리하자.
Google의 2026-04-14 공식 발표에 따르면 Skills in Chrome은 AI workflows를 발견하고, 저장하고, 다시 섞어서, 즉시 반복 실행하게 하려는 기능이다.
핵심 동작은 꽤 단순하다.
채팅 기록에서 다시 쓸 만한 프롬프트를 Skill로 저장하고, 다음에는 Gemini in Chrome 안에서 슬래시 /를 치거나 플러스 + 버튼을 눌러서 불러온다.
그리고 그 Skill은 지금 보고 있는 페이지와 선택한 다른 탭들에 적용된다.
Google은 동시에 ready-to-use Skills library도 같이 연다고 설명했다.
즉, 완전히 빈 상태에서 직접 만드는 흐름과 미리 만들어진 템플릿을 편집해서 쓰는 흐름을 둘 다 열어둔 셈이다.
여기까지만 보면 프롬프트 템플릿 기능 처럼 보인다.
근데 Gemini in Chrome 도움말을 보면 이 기능은 브라우저 맥락과 묶여 있다.
기본적으로 현재 탭의 페이지 내용이 공유되고, 추가로 최대 10개의 열려 있는 탭을 공유할 수 있다.
탭 추가는 버튼으로 고를 수도 있고, 프롬프트 안에서 @를 쳐서 넣을 수도 있다.
이건 생각보다 중요하다.
왜냐면 Skills가 단순한 저장 프롬프트를 넘어서 브라우저 문맥을 가진 저장 프롬프트 가 되기 때문이다.
게다가 Gemini in Chrome은 Connected Apps도 일부 붙는다.
공식 도움말 기준으로 Google Workspace 계열 중 Gmail, Google Calendar, Docs, Drive, Keep, Tasks와 연결될 수 있다.
여기서부터 프롬프트 저장 기능은 그냥 메모장이 아니라 실제 개인 작업 환경의 얇은 실행 레이어가 된다.
그리고 더 헷갈리게 만드는 게 auto browse다.
Google 도움말은 auto browse를 Gemini in Chrome이 웹에서 multi-step task를 수행하는 기능으로 설명한다.
상품 비교, 숙소 찾기, 예약, 기타 웹 작업처럼 실제 행동이 들어가는 층이다.
중요한 건 이게 Skills와 같은 급이 아니라는 점이다.
2026-04-15 기준 공식 조건은 꽤 빡빡하다.
- 미국 사용자
- 최신 Chrome
- 영어 기기 언어
- 개인 Google 계정
- Google AI Pro 또는 Ultra
- Safe Browsing Standard 또는 Enhanced
게다가 work or school 계정에선 auto browse가 안 된다고 적혀 있다.
일일 요청 한도도 있다.
공식 도움말 기준으로 AI Pro는 하루 20개, AI Ultra는 하루 200개다.
즉, Skills를 보고 오, 이제 브라우저 에이전트 끝났네 라고 생각하면 반쯤만 맞다.
저장 프롬프트와 브라우저 내 작업 실행은 같은 문 안에 있지만 운영 난이도는 전혀 다르다.
내가 먼저 분리하는 세 레이어
이 기능을 이해할 때 나는 보통 세 줄로 나눈다.
1. 저장된 프롬프트
가장 얇은 층이다.
문장을 매번 다시 안 쓰게 해주는 층이고, 반복 입력 비용을 줄여준다.
이 레이어에선 핵심이 프롬프트 본문 재사용이다.
2. 탭 컨텍스트
두 번째 층은 브라우저 상태를 같이 넘기는 층이다.
현재 탭, 선택한 다른 탭, 최대 10개까지의 비교 문맥이 붙는다.
이 레이어에선 어떤 페이지를 보고 있느냐 가 결과 품질에 직결된다.
3. 행동 자동화
세 번째 층이 auto browse다.
여기선 이미 단순 요약이나 비교를 넘어서 사이트 이동, 버튼 클릭, 양식 입력, 계정 로그인, 민감 정보 검토 같은 문제가 같이 올라온다.
이 셋을 구분하지 않으면 문제가 딱 두 가지로 터진다.
하나는 사소한 프롬프트까지 전부 Skill로 저장해서 목록이 쓰레기서랍이 되는 경우고,
다른 하나는 저장 프롬프트 하나에 행동 자동화 기대치를 실어버려서 과도한 신뢰를 주는 경우다.
그래서 오늘 글의 핵심 질문도 이걸로 잡는다.
이 프롬프트는 어느 층에 둬야 하나
이 질문부터 먼저 해야 one-click이 진짜 편해진다.
반복 프롬프트를 Skill로 올리기 전에 먼저 정할 5가지
이제 본론이다.
내 기준으로는 다섯 가지만 먼저 보면 대부분 빠르게 걸러진다.
1. 입력 형태가 매번 비슷한가
이게 제일 먼저다.
프롬프트를 Skill로 올릴지 말지는 기능의 화려함보다 입력 형태가 얼마나 고정돼 있는지가 더 중요하다.
예를 들면 이런 건 올리기 쉽다.
- 지금 읽는 글의 핵심 논점 3개 추출
- 여러 제품 탭을 비교해서 표로 정리
- 긴 문서에서 결정해야 할 포인트만 뽑기
- 문서 요약 후 후속 질문 5개 만들기
공통점이 있다.
입력 구조가 거의 매번 같다.
페이지가 달라져도 내가 원하는 출력 프레임은 거의 안 바뀐다.
반대로 이런 건 보통 Skill로 올리기 애매하다.
- 오늘 상황에 맞는 새로운 리서치 플랜 만들기
- 기획서 목적에 따라 출력 형식을 매번 바꾸기
- 상대방 성격, 톤, 맥락에 따라 답장을 완전히 새로 쓰기
- 지금 보는 페이지 외에 내 머릿속 히스토리가 많이 필요한 작업
이건 프롬프트 본문이 계속 바뀐다.
즉, 반복 실행보다 반복 수정이 더 많은 타입이다.
이런 프롬프트를 저장하면 처음 이틀은 편하다.
근데 곧 저장된 Skill을 열고, 문장을 절반 갈아엎고, 예외 조건을 다시 넣고, 결국 “원클릭”이 아니라 “열어서 고치기”가 된다.
내 기준은 이렇다.
프롬프트의 핵심 문장 70% 이상이 거의 그대로 유지되면 Skill 후보로 본다.
반대로 매번 본문을 크게 뜯어고친다면 그건 저장 프롬프트가 아니라 작업용 템플릿 문서에 더 가깝다.
그럴 땐 Obsidian 노트나 프롬프트 파일이 SSOT가 되는 편이 낫다.
2. 탭 컨텍스트가 1~10개 안에서 닫히는가
Google 도움말에서 가장 실무적인 숫자는 아마 최대 10개 탭일 거다.
이 숫자가 기능 한계를 알려주는 동시에, 오히려 좋은 설계 기준도 준다.
왜냐면 많은 반복 작업이 의외로 10개 안에서 닫히기 때문이다.
예를 들면 이런 작업이 그렇다.
- 3개 상품 탭 스펙 비교
- 4개 문서 탭 공통 주장 정리
- 2개 경쟁사 페이지 차이점 정리
- 지금 읽는 글 + 보조 자료 2개를 합쳐 요약
이런 건 브라우저 문맥과 잘 맞는다.
한 번의 Skill이 지금 보고 있는 맥락을 거의 다 설명해준다.
반대로 20개 사이트를 돌려봐야 하거나, 브라우저 밖 자료까지 섞어야 하거나, 이전 작업 히스토리와 결합해야 하면 Skills보다 큰 도구가 필요하다.
예를 들면 RAG, 노트 시스템, 스크립트, 에이전트 런북, 혹은 그냥 손으로 정리하는 문서다.
여기서 생기는 흔한 실수가 있다.
탭 2개 비교용으로 설계한 Skill을 나중에 8개 탭, 10개 탭, 그다음엔 Gmail 문맥까지 끌어와서 만능 비교기처럼 쓰려는 거다.
그러면 어느 순간 결과가 흐려진다.
프롬프트 문제 같지만 사실은 컨텍스트 스코프 문제가 더 크다.
그래서 Skill을 만들 때는 처음부터 이건 몇 개 탭짜리 작업인가 를 적어두는 편이 낫다.
나는 보통 이렇게 자른다.
- 1탭: 요약, 추출, 재작성
- 2~4탭: 비교, 공통점/차이점 정리
- 5~10탭: 조사 보조, 패턴 추출
- 10탭 초과: Skill보다 다른 워크플로 검토
이 기준만 있어도 Skill이 쓸 만한 범위와 아닌 범위가 빨리 보인다.
3. 결과가 초안이면 충분한가, 아니면 행동까지 가나
이건 신기능에 취할수록 제일 빨리 놓치는 포인트다.
Skill은 본질적으로 저장된 요청이다.
즉, 초안을 빨리 만들고, 비교를 빨리 하고, 요약을 빨리 하는 데 특히 잘 맞는다.
공식 발표문도 단백질 계산, 스펙 비교, 문서 스캔 같은 예시를 먼저 든다.
다시 말해 판단 보조 와 초안 생성 에 가깝다.
반면 이메일 보내기, 캘린더 이벤트 추가, 예약 진행 같은 건 행동이 개입된다.
Google은 Skills에도 일정 추가나 메일 전송처럼 특정 행동 전엔 확인을 묻는 safeguards가 있다고 설명한다.
여기서 읽어야 할 메시지는 하나다.
보내기 직전 단계와 실제 보내기는 같은 편의성 범주가 아니라는 뜻이다.
그래서 내 기준은 더 보수적이다.
Skill이 만들어주는 결과가 초안 이면 거의 괜찮다.
Skill이 곧바로 실행 으로 이어지면 한 번 더 생각한다.
예를 들면 이런 식이다.
- 초안 OK: 지금 글 요약하고 답장 초안 2개 써줘
- 경계: 지금 이 내용으로 바로 메일 보내줘
- 초안 OK: 3개 상품 비교표를 만들어줘
- 경계: 가장 싼 곳에서 바로 장바구니에 담아줘
이 차이를 안 두면 원클릭이 아니라 원클릭 사고 접수창이 된다.
특히 팀 환경에선 사람이 나중에 봐도 무슨 의사결정이 자동이었고 무엇이 검토 대상이었는지 헷갈리기 쉬워진다.
그래서 보내기, 결제, 가입, 약관 동의, 일정 확정처럼 되돌리기 번거로운 행동은 가능하면 Skill의 목표가 아니라 사람 검토 이후 단계로 남겨두는 편이 낫다.
4. Connected Apps와 개인정보를 섞을 건가
여기서부터는 편의성보다 경계가 중요하다.
Gemini in Chrome 도움말은 Connected Apps로 Gmail, Calendar, Docs, Drive, Keep, Tasks 등을 언급한다.
그리고 auto browse 도움말은 더 직접적으로 말한다.
Gemini in Chrome이 Connected Apps 정보나 개인 정보를 사용해서 작업을 더 정확하게 수행할 수 있고, 작업을 위해 방문한 사이트와 그 정보를 공유할 수 있다는 뜻이다.
이건 기능 소개 문장처럼 보이지만 운영자 입장에선 리스크 설명 문장에 더 가깝다.
예를 들어 이런 프롬프트를 생각해보자.
지금 보고 있는 채용 페이지를 읽고, 내 Gmail의 최근 면접 메일과 캘린더 일정을 참고해서 지원 우선순위를 정리해줘
기능적으로는 멋지다.
근데 브라우저 탭, 메일, 캘린더, 개인 일정, 외부 웹페이지가 한 프롬프트에 같이 들어온다.
이 상태에서 무엇이 어디로 흘렀는지 사람이 감각적으로 놓치기 쉽다.
그래서 나는 Connected Apps가 붙는 순간 Skill 후보를 다시 거른다.
이런 건 상대적으로 안전하다.
- 공개 문서 요약
- 제품 페이지 비교
- 기사 핵심 주장 추출
- 공개 정보 기반 초안 생성
이런 건 더 보수적으로 본다.
- 메일/캘린더와 웹페이지 결합
- 개인 일정이나 업무 문서와 외부 사이트 결합
- 로그인된 서비스 상태에서 auto browse까지 겹치는 흐름
- 민감한 금융, 법률, 의료 정보가 섞인 작업
특히 Google 도움말은 prompt injection 위험도 직접 설명한다.
악성 지시가 웹페이지 안에 숨어 있을 수 있고, AI agent가 그걸 읽고 의도치 않은 행동을 할 수 있다는 뜻이다.
즉, Connected Apps와 브라우저 문맥과 행동 자동화가 한 번에 겹치면 문제는 급격히 커진다.
이럴수록 Skill보다 명시적인 문서형 절차나 사람 확인 단계가 있는 자동화가 더 낫다.
5. 이 프롬프트를 버전 관리해야 하는가
이건 은근히 실무에서 제일 늦게 깨닫는 문제다.
Skill은 편하다.
브라우저 안에서 만들고, 바로 저장하고, 바로 다시 쓰면 된다.
게다가 공식 블로그는 저장한 Skills가 signed-in Chrome desktop device 전반에서 이용 가능하다고 설명한다.
근데 바로 여기서 장점이 단점으로도 바뀐다.
브라우저 안에서 편하게 바꿀 수 있다는 건 누가 언제 왜 바꿨는지 남기기 어렵다는 뜻이기도 하다.
개인용이면 대충 넘어갈 수 있다.
근데 팀용, 반복 운영용, 혹은 글쓰기/리서치 시스템처럼 prompt drift가 민감한 환경이면 이게 슬슬 문제 된다.
예를 들면 이번 주엔 잘 되던 Skill이 다음 주부터 좀 이상한데, 원인이 모델 탓인지, 탭 구성 탓인지, 누가 프롬프트를 조금 바꾼 탓인지 바로 알기 어려워진다.
그래서 팀 단위나 장기 운영에선 브라우저 안의 Skill을 SSOT로 두지 않는 편이 낫다.
내 기준은 보통 이렇게 간다.
- 개인용 단기 반복 작업: Skill 저장 OK
- 개인용이지만 오래 쓸 핵심 프롬프트: 노트나 저장소에 원본 유지
- 팀이 같이 쓰는 프롬프트: 문서형 SSOT 우선, Skill은 미러 레이어
- 변경 이력과 리뷰가 필요한 프롬프트: 브라우저 저장본 단독 사용 금지
이 기준이 있어야 편의성과 통제가 같이 간다.
안 그러면 어느 날 브라우저 안에만 사는 작은 자동화 유령들이 생긴다.
분명 잘 돌았는데 왜 잘 돌았는지 아무도 설명 못 하는 상태다.
그럼 어떤 프롬프트가 Skills에 잘 맞나
여기까지 읽고 나면 결국 이 질문이 남는다.
그래서 뭘 올리면 되는데
내가 지금 기준으로 잘 맞는 쪽은 이렇다.
잘 맞는 패턴 1. 비교형
여러 탭을 열어두고 공통 포맷으로 비교하는 작업이다.
예를 들면 스펙 비교, 가격 비교, 정책 차이 비교, 문서 버전 비교 같은 거다.
이건 탭 컨텍스트와 Skill 저장이 딱 맞물린다.
잘 맞는 패턴 2. 추출형
긴 문서에서 결정 포인트, 숫자, 위험, 후속 질문을 뽑는 작업이다.
이건 출력 구조가 잘 고정되기 때문에 반복 저장 가치가 높다.
잘 맞는 패턴 3. 재작성형
현재 페이지 내용을 내 톤이나 내 목적에 맞게 다시 바꾸는 작업이다.
예를 들면 블로그 초안 메모, 회의 메모 요약, 학습용 질문 변환 같은 흐름이다.
다만 이 경우도 보내기 직전 보다 초안 만들기 에 한정할수록 안전하다.
굳이 Skills로 안 올려도 되는 패턴
반대로 겉으론 멋져 보여도 굳이 Skills까지 안 가도 되는 것도 많다.
안 맞는 패턴 1. 매번 목적이 달라지는 리서치
오늘은 시장 조사, 내일은 경쟁사 분석, 모레는 인터뷰 질문 설계처럼 결과 구조가 계속 달라지는 작업이다.
이건 저장 프롬프트보다 작업 브리프 문서가 먼저다.
안 맞는 패턴 2. 민감 계정과 민감 정보가 섞이는 작업
메일, 캘린더, 문서, 금융, 개인 계정이 같이 들어가면 실수 비용이 커진다.
이건 편의성보다 분리 원칙이 먼저다.
안 맞는 패턴 3. 행동 자동화 기대가 큰 작업
상품 구매, 예약, 가입, 폼 제출, 실제 송신 같은 일은 한 번 더 레이어를 나눠야 한다.
Skill 저장 단계와 실행 자동화 단계를 같이 묶을수록 리스크가 커진다.
만약 여기서부터
세션을 이어가고,
권한 승인도 넣고,
MCP나 서브에이전트까지 조합하고 싶다
쪽으로 생각이 커진다면,
브라우저 Skill이 아니라
런타임 하네스 선택 문제로 넘어간다.
그 구간은
OpenHarness를 언제 도입하고 언제 과한가 2026 — 세션·도구구조·운영비용 체크리스트
쪽 판단이 더 맞다.
auto browse는 Skills의 강화판이 아니라 별도 판단 대상이다
이 부분은 따로 적어둘 필요가 있다.
많은 사람이 Skills를 보면 곧바로 auto browse까지 묶어서 생각한다.
근데 공식 도움말 기준으론 이 둘은 운영 판단이 완전히 다르다.
auto browse는 Gemini in Chrome이 웹에서 multi-step task를 수행하는 기능이고, 사용자는 계획을 검토하고, 필요하면 take over 해야 하고, 민감 단계에선 직접 개입해야 한다.
게다가 Google은 명시적으로 사용자가 작업 결과에 대한 책임을 진다고 적는다.
심지어 실수나 예상 밖 결과, 구매 같은 일도 포함된다고 설명한다.
이건 꽤 세다.
즉, auto browse는 편한 보조 기능 이 아니라 감독이 필요한 실험적 에이전트 에 더 가깝다.
공식 도움말이 적어놓은 위험도 그 톤에 가깝다.
- prompt injection 가능성
- 사이트에 개인 정보 공유 가능성
- 잘못된 링크나 버튼 클릭 가능성
- 잘못된 수량 추가나 구매 가능성
- 다 끝났다고 했는데 사실 덜 끝난 상태
이 정도면 Skills를 저장 프롬프트 레이어로 쓰는 것과 auto browse를 켜는 건 같은 체크박스가 아니다.
내 기준으로는 auto browse는 이런 경우에만 검토할 만하다.
- 저위험 소비자 웹 작업
- 사람이 옆에서 계속 볼 수 있는 작업
- 실패해도 쉽게 취소 가능한 작업
- 계정 권한과 데이터 범위가 명확한 작업
반대로 이런 경우엔 일단 보류한다.
- 금융
- 법률
- 의료
- 회사 계정
- 중요한 예약/결제
- Connected Apps와 민감 정보가 같이 얽힌 흐름
auto browse는 멋있어 보여도 보수적으로 다루는 편이 맞다.
지금은 특히 더 그렇다.
공식 문서도 실험적 기능이라고 적고, 모든 리스크를 막아주진 않는다고 써두고 있기 때문이다.
오늘 당장 써볼 만한 Skill 후보 3개
그래도 손에 잡히는 예시가 있어야 감이 빨리 온다.
내가 지금 브라우저에서 바로 만들어볼 만하다고 느끼는 건 이 정도다.
1. 문서 핵심만 뽑기
지금 보고 있는 페이지에서 결정에 필요한 숫자, 제약, 다음 질문만 5줄로 정리해줘. 마케팅 문구는 빼줘.
이건 1탭 추출형이고, 저위험이고, 출력도 고정되기 쉽다.
2. 여러 탭 비교표 만들기
공유한 탭들을 가격, 주요 기능, 제한사항, 내가 지금 확인해야 할 리스크 4열 표로 정리해줘.
이건 2~4탭 비교형으로 좋다.
브라우저 문맥 장점이 가장 잘 살아난다.
3. 긴 글을 내 작업용 메모로 재작성
지금 글을 블로그 글감 검토용 메모로 바꿔줘. 핵심 주장, 실무 영향, 과장된 문장, 내가 실제로 검증할 포인트를 분리해줘.
이건 TECHTAEK식 메모 작업에 잘 맞는다.
뉴스를 그대로 삼키지 않고 운영 판단으로 바꾸는 흐름에 가깝다.
실수 TOP 5
1. 저장 프롬프트와 행동 자동화를 같은 말로 보는 실수
Skills는 저장된 요청 레이어다.
auto browse는 행동과 권한이 붙는 다른 층이다.
이걸 한 덩어리로 보면 신뢰 수준이 과하게 올라간다.
2. 반복 프롬프트를 전부 저장하는 실수
반복된다고 다 같은 반복은 아니다.
입력 구조가 매번 바뀌는 작업은 Skill보다 문서 템플릿이 낫다.
3. 현재 탭이 기본 공유된다는 사실을 잊는 실수
Gemini in Chrome은 현재 탭을 기본으로 쓰는 흐름이 있다.
그래서 내가 어떤 페이지 위에서 Skill을 실행하는지가 생각보다 중요하다.
4. Connected Apps와 외부 웹 컨텍스트를 가볍게 섞는 실수
메일, 캘린더, 문서, 외부 사이트가 같이 붙으면 편해지는 만큼 경계도 같이 올라가야 한다.
5. 팀용 핵심 프롬프트를 브라우저 저장본에만 맡기는 실수
편하다고 해서 SSOT가 되면 안 되는 프롬프트가 있다.
바뀐 이유를 설명해야 하는 프롬프트라면 문서형 원본이 먼저다.
결국 판단은 이 질문 다섯 개로 줄어든다
길게 썼지만 실제로는 아래 다섯 줄이면 된다.
- 이 프롬프트는 입력 구조가 거의 고정돼 있나
- 이 작업은 1~10개 탭 안에서 설명되나
- 결과가 초안이면 충분한가
- 개인정보나 Connected Apps를 같이 쓰나
- 이 프롬프트는 버전 관리 대상인가
다섯 개 중 앞의 세 개가 예, 뒤의 두 개가 아니오 쪽이면 대체로 Skill 후보로 괜찮다.
반대로 앞의 세 개가 흔들리고, 뒤의 두 개가 예로 기울면 그건 Skills보다 다른 도구를 먼저 봐야 한다.
원클릭은 마법이 아니라 스코프를 줄이는 기술에 더 가깝다.
그래서 잘 쓰려면 더 많이 저장하는 것보다 덜 저장하되 더 또렷하게 저장하는 편이 낫다.
FAQ
Skills in Chrome은 그냥 저장된 프롬프트라고 보면 되나
거의 맞다.
다만 단순 저장 텍스트가 아니라 Gemini in Chrome의 탭 컨텍스트와 같이 작동하는 저장 프롬프트라고 보는 편이 더 정확하다.
2026년 4월 15일 기준 누구나 바로 쓸 수 있나
아직 그렇진 않다.
Google 공식 발표와 도움말 기준으로 Skills와 Gemini in Chrome은 점진 배포 중이고, 데스크톱 Chrome 환경과 영어 설정 같은 조건이 붙는다.
Skills 발표문은 Mac, Windows, ChromeOS, Chrome language English-US 조건을 적고 있다.
회사나 학교 계정에서도 쓸 수 있나
Gemini in Chrome 자체는 관리자 설정을 통해 work or school 계정에서 허용될 수 있다.
다만 Chrome Enterprise 도움말은 관리자 정책과 Gemini 설정이 둘 다 켜져야 한다고 설명하고, auto browse는 현재 managed users에서 제공되지 않는다고 적고 있다.
즉, 조직 계정에선 쓸 수 있는 범위와 못 쓰는 범위를 나눠서 봐야 한다.
auto browse까지 바로 켜서 쓰면 더 좋지 않나
항상 그렇진 않다.
auto browse는 개인 계정, AI Pro 또는 Ultra, Safe Browsing 설정, 민감 단계 확인, 리스크 모니터링까지 같이 들어간다.
저위험 반복 웹 작업엔 유용할 수 있지만, 민감한 계정이나 중요한 행동이 끼면 더 보수적으로 보는 편이 낫다.
팀에서 공용으로 쓰는 프롬프트도 Skills로만 관리해도 되나
비추천이다.
브라우저 저장본은 편하지만 버전 이력과 리뷰가 약하다.
팀 공용 프롬프트라면 문서나 저장소에 원본을 두고, Skills는 실행용 미러로 쓰는 편이 안정적이다.
공식 출처
- Google, Turn your best AI prompts into one-click tools in Chrome
- Google Gemini Apps Help, Use Gemini in Chrome
- Google Gemini Apps Help, Ask Gemini in Chrome to complete tasks for you with auto browse
- Chrome Enterprise and Education Help, Gemini in Chrome