AI Studio로 가장 빠르게 실험하기

코드를 쓰기 전에 먼저 실패해 보자

좋은 AI 애플리케이션은 대개 멋진 코드에서 시작하지 않는다. 더 정확히 말하면, 코드로 옮기기 전에 이미 여러 번 실패해 본 프롬프트에서 시작한다. 모델이 지시를 오해하는지, 출력 형식이 흔들리는지, 같은 질문에서도 답변이 얼마나 달라지는지, 안전 필터에 막히는 구간은 어디인지 먼저 확인해야 한다. 이 과정을 생략하고 곧장 API 코드부터 작성하면, 나중에는 "버그가 코드에 있는지, 프롬프트에 있는지, 모델 설정에 있는지" 구분하기 어려워진다.

Google AI Studio는 바로 이 초기 혼란을 줄여 주는 실험실이다. 브라우저에서 Gemini 모델을 고르고, 시스템 지시를 넣고, 온도와 출력 길이 같은 파라미터를 조정하고, 파일을 업로드하고, 결과가 괜찮으면 Python이나 JavaScript 코드로 이어 갈 수 있다. 공식 소개에서도 AI Studio는 Gemini API로 빌드하기 위한 가장 빠른 출발점으로 설명된다.¹

이 장의 목표는 "AI Studio 화면을 한번 둘러보기"가 아니다. 목표는 더 실용적이다. 첫 API 호출 전에 실패할 프롬프트와 비용 낭비를 줄이는 것이다. 실험실에서 할 일은 명확하다. 모델을 고르고, 프롬프트를 다듬고, 안전 설정과 파라미터를 바꿔 보며, 나중에 팀원이 같은 결과를 재현할 수 있도록 기록을 남긴다. 그 기록이 다음 장부터 작성할 코드의 기준선이 된다.

AI Studio, Gemini 앱, Gemini API를 헷갈리지 않기

처음 제미나이를 접한 독자가 가장 자주 묻는 질문은 이것이다. "그냥 gemini.google.com에서 대화하면 되는 것 아닌가요?" 개인적인 글쓰기, 일정 아이디어, 간단한 검색 보조라면 소비자용 Gemini 앱도 충분하다. 하지만 개발자나 기획자가 API 기반 서비스를 만들려면 다른 환경이 필요하다.

AI Studio는 모델의 동작을 실험하고 Gemini API로 옮기기 위한 개발자용 작업대에 가깝다. 같은 질문을 여러 모델에 던져 비교하고, 응답 형식을 JSON으로 제한하고, 멀티모달 입력을 넣어 보고, Get code 기능으로 호출 예제를 가져오는 흐름이 자연스럽다. 반면 Gemini API는 이 실험을 실제 애플리케이션 코드, 서버, 배포 환경으로 연결하는 인터페이스다. 공식 API 참조는 표준 생성, 스트리밍, 실시간 API를 포함해 HTTP 환경에서 Gemini 모델과 상호작용하는 방법을 설명한다.²

실무에서는 이렇게 구분하면 쉽다. Gemini 앱은 개인 생산성 도구, AI Studio는 실험실, Gemini API는 제품에 붙이는 엔진이다. 이 세 가지를 구분하는 순간, "왜 굳이 AI Studio를 거쳐야 하지?"라는 의문이 사라진다. 실험실에서 실패가 싸기 때문이다. 서버를 만들고, 로그를 붙이고, 프런트엔드까지 연결한 뒤 프롬프트가 틀렸다는 사실을 깨닫는 것보다, AI Studio에서 10분 만에 틀렸다는 사실을 확인하는 편이 훨씬 싸다.

첫 입장: 프로젝트, API 키, 비용 경계

AI Studio에 처음 들어가면 먼저 계정과 프로젝트의 관계를 확인해야 한다. Gemini API를 사용하려면 API 키가 필요하고, 이 키는 AI Studio의 API Keys 페이지에서 생성하고 관리할 수 있다.³ 여기서부터 이미 실무 습관이 갈린다. 빠르게 실험하려는 사람은 키 하나를 만들어 아무 곳에나 붙여 넣는다. 오래 가는 팀은 실험용 키와 운영용 키를 나누고, 어떤 프로젝트에 연결되어 있는지 기록한다.

API 키는 비밀번호와 비슷하다. 아니, 어떤 면에서는 더 위험하다. 비밀번호는 사람 계정에 들어가는 문이고, API 키는 비용이 발생하는 기계 문이다. 키가 노출되면 누군가가 여러분의 프로젝트로 요청을 보낼 수 있다. 그래서 AI Studio에서 키를 만들자마자 해야 할 일은 "잘 복사했는가"가 아니라 "어디에 두지 않을 것인가"를 정하는 것이다.

가장 기본적인 원칙은 단순하다. 키를 소스 코드에 직접 쓰지 않는다. 공개 Git 저장소에 올리지 않는다. 브라우저에서 실행되는 프런트엔드 코드에 넣지 않는다. 로컬 실습에서는 .env 파일이나 셸 환경변수를 쓰고, 운영 환경에서는 Secret Manager 같은 비밀 관리 도구를 쓴다. 이 책의 뒤쪽 배포 장에서는 이 원칙을 더 엄격하게 다루겠지만, 지금은 한 문장만 기억해도 된다. API 키는 코드가 아니라 환경에 둔다.

비용 경계도 함께 확인해야 한다. Gemini API와 AI Studio에는 무료 티어와 유료 티어가 있고, 더 높은 한도나 고급 사용을 위해 결제 계정을 연결할 수 있다. 공식 결제 문서는 사용량 모니터링, 선불·후불 결제 방식, 프로젝트 단위 지출 한도 같은 운영 장치를 설명한다.⁴ 무료로 시작할 수 있다는 사실은 매력적이지만, 무료라는 말이 "아무 데이터나 넣어도 된다"는 뜻은 아니다. Gemini API 추가 약관은 유료 서비스에서는 프롬프트, 시스템 지시, 캐시 콘텐츠, 이미지·동영상·문서 같은 파일과 응답을 제품 개선에 사용하지 않는다고 설명한다.⁵ 반대로 무료·무과금 사용량에서는 데이터 처리 조건이 달라질 수 있으므로, 고객 정보·계약서·소스 코드·개인정보를 넣기 전에 반드시 현재 약관과 조직 정책을 확인해야 한다.

실습을 시작하기 전, 다음 네 가지를 한 줄로 적어 두자.

이 표는 사소해 보이지만, 팀 실습에서는 매우 강력하다. 특히 워크숍이나 사내 데모에서는 개인 계정과 회사 계정, 실습용 프로젝트와 실제 프로젝트가 섞이기 쉽다. "나중에 정리하자"는 말은 대부분 정리되지 않는다. 처음부터 분리하는 편이 낫다.

빈 화면에서 시작하지 않기

AI Studio에 들어가 새 채팅을 열면, 커다란 입력창이 우리를 기다린다. 이때 많은 사람이 곧장 자기 업무를 적는다. "우리 회사 고객 문의를 분류해 줘." "이 이미지를 분석해 줘." "보고서를 써 줘." 물론 이렇게 시작해도 된다. 하지만 더 좋은 방법은 이미 잘 만들어진 예제를 출발점으로 삼는 것이다.

Google은 Gemini API용 Prompt Gallery를 제공한다. 이 갤러리는 AI Studio에서 시도해 볼 수 있는 프롬프트 아이디어를 모아 둔 공간이고, 더 많은 코드 예제는 Gemini API Cookbook으로 이어진다.⁶ 초보자에게 예제는 지름길이고, 개발자에게 예제는 기준선이다. 빈 화면에서 감으로 쓰는 프롬프트는 실패해도 원인을 찾기 어렵지만, 목적이 분명한 예제를 복제해 바꾸면 어느 수정이 결과를 바꿨는지 확인하기 쉽다.

예를 들어 고객지원 분류기를 만들고 싶다고 해 보자. 처음부터 "고객 문의를 잘 분류해 줘"라고 쓰지 말고, 먼저 구조화 출력 예제나 분류 예제를 찾는다. 그다음 예제의 주제만 바꾼다. 영화 리뷰 분류 예제가 있다면 고객 문의 분류로 바꾸고, 출력 필드를 category, priority, reason 정도로 조정한다. 이렇게 하면 프롬프트 작성이 창작이 아니라 리팩터링이 된다.

좋은 출발점은 대개 세 가지 특징을 갖는다.

• 작업 목적이 한 문장으로 분명하다.

• 입력 데이터와 지시문이 섞이지 않고 구분되어 있다.

• 출력 형식이 사람이 읽기 쉬운 문장인지, 기계가 파싱할 JSON인지 명확하다.

AI Studio의 Prompt Gallery와 Cookbook을 볼 때는 "멋진 답변"보다 이 구조를 보자. 예제의 소재는 바뀌어도 구조는 재사용된다. 그리고 실무에서 시간을 줄여 주는 것은 대부분 소재가 아니라 구조다.

첫 번째 실험: 같은 질문을 세 번 던져 보기

이제 간단한 실험을 해 보자. 아직 업무 데이터를 넣지 않는다. 먼저 안전한 합성 예시로 시작한다. 예를 들어 사내 지식검색 챗봇을 만들고 싶은 팀이라면 다음처럼 물어볼 수 있다.

신입사원이 사내 휴가 규정을 물어볼 때 사용할 수 있는 FAQ 답변 예시를 작성해 줘.

결과는 그럴듯할 것이다. 하지만 이 프롬프트는 실무용으로는 부족하다. 어느 회사 규정인지 알 수 없고, 답변 길이도 정해져 있지 않으며, 확실하지 않은 내용을 어떻게 처리해야 하는지도 없다. 이제 같은 목적을 더 구조적으로 바꿔 보자.

너는 사내 인사 규정 FAQ 답변을 작성하는 어시스턴트야.
아래 조건을 지켜 답변해 줘.

조건:
- 제공된 규정 정보에 있는 내용만 사용한다.
- 확실하지 않은 내용은 추측하지 말고 "인사팀 확인 필요"라고 쓴다.
- 답변은 5문장 이내로 작성한다.
- 마지막에 "관련 부서: 인사팀"을 붙인다.

규정 정보:
연차 휴가는 입사 1년 미만 직원에게 월 1일씩 발생한다.
입사 1년 이상 직원은 회사 취업규칙에 따라 연차가 부여된다.
반차는 오전 또는 오후 단위로 신청할 수 있다.

질문:
입사한 지 6개월 된 직원도 휴가를 쓸 수 있나요?

이번에는 답변이 훨씬 업무에 가까워진다. 중요한 변화는 문장이 길어진 것이 아니다. 역할, 제약조건, 근거 데이터, 사용자 질문을 분리했다는 점이다. Google Skills의 AI Studio 프롬프트 설계 실습도 한 번에 하나의 작업에 집중하고, 간결하고 구체적이며 명확한 프롬프트를 작성하는 방식을 권장한다.⁷

세 번째로는 출력 형식을 고정해 보자.

다음 사용자 질문에 대해 FAQ 응답 초안을 만들어 줘.
제공된 규정 정보에 없는 내용은 추측하지 마.

출력 형식:
요약: 한 문장
답변: 5문장 이내
확인 필요 여부: 예 또는 아니오
담당 부서: 부서명

규정 정보:
연차 휴가는 입사 1년 미만 직원에게 월 1일씩 발생한다.
입사 1년 이상 직원은 회사 취업규칙에 따라 연차가 부여된다.
반차는 오전 또는 오후 단위로 신청할 수 있다.

사용자 질문:
입사한 지 6개월 된 직원도 휴가를 쓸 수 있나요?

이 세 번의 실험만으로도 많은 것을 배운다. 짧은 프롬프트는 빠르지만 흔들리고, 구조화된 프롬프트는 길지만 예측 가능하다. 사람에게 보여 줄 데모라면 자연스러운 문장이 중요하고, 시스템에 연결할 API라면 일정한 형식이 더 중요하다.

시스템 지시는 모델의 작업복이다

AI Studio에서 꼭 익혀야 할 기능 중 하나가 시스템 지시다. 시스템 지시는 매번 사용자 프롬프트에 반복해서 쓰지 않아도 되는 상위 규칙이다. 예를 들어 "너는 친절한 상담원이다", "법률 자문처럼 단정하지 말고 참고 정보로만 답하라", "모든 응답은 한국어로 작성하라" 같은 규칙을 시스템 지시에 넣을 수 있다.

시스템 지시는 모델에게 작업복을 입히는 일과 비슷하다. 같은 사람도 의사 가운을 입으면 진료실의 언어를 쓰고, 안전모를 쓰면 공사장의 언어를 쓴다. 모델도 마찬가지다. 시스템 지시가 없으면 매번 사용자의 말투와 입력 데이터에 쉽게 끌려간다. 시스템 지시가 있으면 세션 전체에서 역할과 제한을 더 일관되게 유지할 수 있다.

다만 시스템 지시는 마법의 봉인이 아니다. 사용자가 반대되는 지시를 넣거나, 입력 문서 안에 "이전 지시를 무시하라"는 문장이 들어 있으면 모델이 흔들릴 수 있다. 이를 프롬프트 인젝션이라고 부른다. 이 장에서는 깊게 들어가지 않지만, 지금부터 한 가지 습관을 들이자. 시스템 지시에는 변하지 않는 원칙을 쓰고, 사용자 프롬프트에는 매번 바뀌는 작업과 데이터를 쓴다.

예를 들어 보고서 요약 도구를 만든다면 시스템 지시는 이렇게 둘 수 있다.

너는 기업 내부 문서를 요약하는 분석 어시스턴트다.
제공된 문서에 없는 사실을 만들지 않는다.
불확실한 내용은 "문서에서 확인되지 않음"이라고 쓴다.
응답은 한국어로 작성한다.

그리고 사용자 입력에는 매번 다른 문서와 질문을 넣는다. 이렇게 분리하면 나중에 API 코드로 옮길 때도 구조가 자연스럽다. 시스템 지시는 system_instruction으로, 사용자 입력은 contents로 옮기면 된다. 지금은 코드를 외울 필요가 없다. 중요한 것은 화면에서 먼저 구조를 체득하는 것이다.

예시는 말보다 강하다

모델에게 "좋은 형식으로 답해 줘"라고 말하는 것보다 좋은 방법은 "이런 형식으로 답해 줘"라고 보여 주는 것이다. 이를 원샷 또는 퓨샷 예시라고 부른다. 원샷은 예시를 하나 주는 것이고, 퓨샷은 여러 개 주는 것이다. 낯선 용어처럼 보이지만, 사실 사람에게 일을 가르칠 때도 똑같이 한다. "보고서를 깔끔하게 써 와"라고 말하는 것보다 지난달 좋은 보고서를 보여 주는 편이 훨씬 빠르다.

고객 문의 분류 프롬프트를 예로 들어 보자.

너는 고객 문의를 분류하는 상담 운영 어시스턴트야.
아래 예시와 같은 형식으로 분류해 줘.

예시 1
문의: 결제했는데 영수증을 어디서 받나요?
분류: 결제/영수증
긴급도: 낮음
이유: 결제 후 증빙 문서 확인 문의이기 때문

예시 2
문의: 어제부터 서비스가 접속되지 않습니다. 업무가 멈췄어요.
분류: 장애/접속
긴급도: 높음
이유: 서비스 이용 불가와 업무 중단이 언급되었기 때문

분류할 문의:
문의: 비밀번호를 여러 번 틀렸더니 계정이 잠겼습니다.

이런 예시는 특히 분류, 추출, 품질 점검, 문체 변환에 강하다. 모델은 긴 설명보다 패턴을 잘 따라간다. 다만 예시가 잘못되면 잘못된 패턴도 따라간다. 그래서 예시는 많을수록 좋은 것이 아니라, 대표적이고 일관적일수록 좋다.

실험할 때는 예시 수를 바꿔 보자. 예시가 없을 때, 하나일 때, 세 개일 때 결과가 어떻게 달라지는지 비교한다. 이때 입력 문의는 그대로 유지해야 한다. 한 번에 여러 요소를 바꾸면 무엇이 결과를 바꿨는지 알 수 없다.

파라미터는 모델의 성격을 바꾸는 손잡이

AI Studio 오른쪽 설정 패널에는 모델, 온도, 출력 길이, 안전 설정 같은 손잡이가 있다. 초보자는 이 설정을 "고급 옵션"으로 여기고 그냥 지나치기 쉽다. 하지만 실무에서는 프롬프트만큼 중요하다. 같은 프롬프트라도 설정에 따라 답변의 속도, 다양성, 길이, 차단 여부가 달라진다.

온도는 가장 먼저 만져 볼 만한 값이다. 온도가 낮으면 모델은 더 예측 가능한 답을 내는 경향이 있다. 추출, 분류, 규정 요약, 코드 수정처럼 일관성이 중요한 작업에 어울린다. 온도가 높으면 더 다양한 표현과 아이디어가 나온다. 광고 문구, 브레인스토밍, 소설 아이디어처럼 창의성이 필요한 작업에 어울린다. Google Skills 실습도 AI Studio에서 모델을 바꾸고 온도를 조정하며 출력 변화를 비교하는 흐름을 다룬다.⁷

다만 온도를 "정확도 다이얼"로 오해하면 안 된다. 온도를 낮춘다고 항상 사실성이 보장되는 것은 아니다. 근거 없는 질문에는 낮은 온도에서도 그럴듯한 오답이 나올 수 있다. 정확성이 필요하면 온도만 낮출 것이 아니라, 근거 문서 제공, 검색 그라운딩, 구조화 출력, 검증 로직을 함께 설계해야 한다.

다음 표는 AI Studio에서 첫 실험을 할 때 참고할 수 있는 출발점이다.

출력 길이도 중요하다. 출력 길이를 너무 짧게 잡으면 답변이 중간에 끊기거나 설명이 빈약해진다. 너무 길게 잡으면 비용과 지연시간이 늘고, 사용자가 읽기 어려운 장황한 답변이 나온다. AI Studio에서 토큰 수를 확인하며 "우리 서비스에서 실제로 필요한 답변 길이"를 감으로 익혀 두자. 이 감각은 다음 장의 비용·지연시간 설계에서 매우 중요해진다.

모델 선택은 성능 자랑이 아니라 목적 선택이다

AI Studio의 모델 선택 드롭다운을 열면 여러 모델이 보인다. 어떤 모델은 복잡한 추론에 강하고, 어떤 모델은 빠른 응답과 비용 효율에 강하다. 이 책은 본문 실습의 안정적인 중심축을 Gemini 2.5 계열에 둔다. 다만 AI Studio에는 시점에 따라 미리보기 모델이나 차세대 모델이 함께 표시될 수 있다. 이런 모델은 새 기능을 탐색하기에는 좋지만, 팀의 기준선을 만들 때는 더 신중해야 한다.

모델 선택에서 흔한 실수는 "가장 강한 모델 하나로 모든 것을 해결하자"는 생각이다. 실제 서비스에서는 그렇게 하지 않는다. 복잡한 계약서 검토, 코드베이스 분석, 긴 문맥 추론에는 더 강한 모델이 필요할 수 있다. 반면 FAQ 초안, 간단한 분류, 짧은 요약은 빠르고 저렴한 모델로 충분할 수 있다. AI Studio에서는 같은 프롬프트를 여러 모델에 던져 응답 품질과 속도를 나란히 비교할 수 있다. 이것이 모델 선택의 첫 단계다.

이 장에서는 모델별 세부 벤치마크를 깊게 다루지 않는다. 다음 장에서 비용, 지연시간, 품질의 균형을 본격적으로 설계한다. 지금은 한 가지만 기억하자. 모델은 등급이 아니라 역할이다. AI Studio에서 역할별 후보를 좁혀 두면, API 구현 단계에서 시행착오가 줄어든다.

안전 설정은 귀찮은 장애물이 아니라 제품 조건이다

AI Studio에서 안전 설정을 조정할 수 있다. 공식 안전 설정 문서는 AI Studio의 실행 설정 패널에서 Safety settings를 열어 콘텐츠 필터 수준을 조정할 수 있다고 설명한다.⁸ 여기서 중요한 태도는 "어떻게 하면 덜 막히게 할까?"가 아니다. 실무 질문은 "우리 제품에서 어떤 응답을 허용해야 하는가?"이다.

예를 들어 게임 캐릭터 대사 생성 도구와 초등학생용 학습 튜터는 안전 기준이 같을 수 없다. 고객센터 상담봇과 내부 보안 분석 도구도 다르다. 같은 모델이라도 사용자가 누구인지, 실패했을 때 피해가 무엇인지, 사람이 검수하는지에 따라 안전 설정과 후처리 정책이 달라진다.

안전 필터는 모델의 성격을 완전히 바꾸는 장치가 아니라, 위험한 입력이나 출력을 제한하는 보호막에 가깝다. 일부 핵심 위해는 사용자가 임의로 허용할 수 없고, 응답이 차단되면 API에서는 차단 사유나 종료 사유를 확인해야 한다. Vertex AI 쪽 안전 필터 문서는 안전하지 않은 프롬프트의 차단 사유와 응답 종료 사유 예시를 설명하며, SAFETY, RECITATION, SPII, PROHIBITED_CONTENT 같은 이유가 응답 중단과 관련될 수 있음을 보여 준다.⁹

AI Studio에서 실험할 때는 안전 설정도 프롬프트와 함께 기록해야 한다. 나중에 API로 옮겼는데 결과가 다르다면, 프롬프트가 아니라 안전 설정 차이 때문일 수 있다. 특히 콘텐츠 생성, 상담, 교육, 의료·금융 안내처럼 민감한 영역에서는 안전 설정을 "마지막에 대충 맞추는 옵션"으로 두면 안 된다. 처음부터 제품 요구사항의 일부로 다뤄야 한다.

구조화 출력으로 "그럴듯한 답변"을 데이터로 바꾸기

사람이 읽을 답변과 프로그램이 읽을 답변은 다르다. 사람은 문장이 조금 달라도 이해할 수 있지만, 프로그램은 쉼표 하나, 필드명 하나가 달라져도 실패할 수 있다. 그래서 추출·분류·자동화 작업에서는 구조화 출력이 중요하다.

AI Studio에서는 구조화 출력 기능을 이용해 모델 응답을 JSON 같은 일정한 형식으로 유도할 수 있다. Google Skills 실습에서도 구조화된 출력을 사용해 JSON을 얻는 흐름을 다룬다.⁷ 단순히 프롬프트에 "JSON으로 답해 줘"라고 쓰는 것보다, 스키마를 명확히 지정하는 편이 훨씬 안정적이다.

고객 문의 분류를 JSON으로 받고 싶다면 다음처럼 시작할 수 있다.

다음 고객 문의를 분류해 줘.
반드시 JSON 객체 하나만 반환해.

필드:
- category: 문의 분류
- priority: 낮음, 보통, 높음 중 하나
- summary: 한 문장 요약
- reason: 분류 이유

문의:
어제 결제했는데 아직 서비스가 활성화되지 않았습니다. 오늘 안에 사용해야 합니다.

AI Studio에서 이 프롬프트를 실행한 뒤 구조화 출력 설정을 켜고, 필드 타입과 필수 여부를 지정해 보자. 그러면 모델은 자유로운 문장보다 정해진 구조에 맞추려 한다. 이때 관찰할 것은 답변의 아름다움이 아니라 파싱 가능성이다. 필드가 빠지지 않는가? priority 값이 지정한 셋 중 하나인가? summary가 너무 길어지지 않는가? 이런 질문이 API 구현의 품질을 좌우한다.

구조화 출력 실험에서 흔한 실패는 두 가지다. 첫째, 하나의 JSON에 너무 많은 책임을 넣는 것이다. 분류, 감정 분석, 답변 생성, 법적 리스크 판단, 후속 액션 추천을 한 번에 넣으면 필드가 흔들린다. 둘째, 설명 문장과 JSON을 섞는 것이다. API가 읽어야 한다면 "아래는 JSON입니다" 같은 문장도 방해가 될 수 있다. 필요하면 사람용 답변과 기계용 JSON을 분리해 두 번 호출하는 편이 낫다.

검색 그라운딩은 최신성의 도구이지 만능 검증기가 아니다

AI Studio에서는 Google 검색을 사용한 그라운딩도 실험할 수 있다. 그라운딩은 모델이 외부 근거를 참고해 답변하도록 돕는 방식이다. 최신 뉴스, 최근 제품 정보, 현재 공개 문서처럼 모델 학습 시점 이후의 정보가 필요한 작업에서 특히 유용하다. Google Skills 실습도 Google 검색 그라운딩을 켜고 최신 사실 정보를 활용한 뒤 창의적인 글쓰기로 이어지는 예를 보여 준다.⁷

하지만 그라운딩을 켰다고 해서 모든 답변이 자동으로 참이 되는 것은 아니다. 검색 결과를 어떻게 해석했는지, 어떤 출처를 우선했는지, 최신 정보가 서로 충돌할 때 어떻게 처리했는지는 여전히 확인해야 한다. 실무에서는 그라운딩 결과에 출처를 요구하고, 중요한 의사결정에는 사람이 검토하는 절차를 둬야 한다.

예를 들어 사내 기술 블로그 초안을 만들 때는 이렇게 실험할 수 있다.

Google 검색을 사용해 2026년 현재 생성형 AI 고객지원 자동화의 주요 흐름을 조사해 줘.
그다음 B2B SaaS 기업의 고객지원 리더를 대상으로 한 블로그 개요를 작성해 줘.
각 핵심 주장에는 참고한 출처를 함께 표시해 줘.

이 실험의 목적은 멋진 블로그를 한 번에 얻는 것이 아니다. 검색을 켰을 때와 껐을 때 차이를 보는 것이다. 최신 통계가 필요한 부분에서 응답이 어떻게 달라지는지, 출처가 충분히 구체적인지, 창의적인 제안과 사실 설명이 섞일 때 환각이 늘어나는지 확인한다. AI Studio에서 이 차이를 눈으로 봐 두면, API 단계에서 검색 그라운딩을 어디에 붙일지 판단하기 쉬워진다.

멀티모달 프롬프트: 설명하지 말고 보여 주기

Gemini의 강점 중 하나는 텍스트만이 아니라 이미지, 문서, 오디오, 비디오 같은 다양한 입력을 함께 다룰 수 있다는 점이다. AI Studio는 이 멀티모달 능력을 가장 빨리 체감할 수 있는 장소다. 긴 설명을 쓰기보다 파일을 올리고 묻는 편이 빠를 때가 많다.

간단한 실험부터 해 보자. 제품 상세 페이지의 스크린샷을 하나 준비한다. 실제 고객 정보나 내부 매출 수치가 들어간 이미지는 쓰지 말고, 공개 페이지나 직접 만든 샘플 이미지를 사용한다. 그런 다음 이렇게 묻는다.

이 이미지는 온라인 쇼핑몰의 상품 상세 페이지 스크린샷이야.
다음 관점에서 개선점을 찾아줘.

1. 사용자가 구매 결정을 내리는 데 부족한 정보
2. 시각적으로 혼란스러운 부분
3. 모바일 화면에서 문제가 될 수 있는 요소
4. 바로 수정할 수 있는 문구 개선안 3개

이번에는 같은 내용을 이미지 없이 텍스트로 설명해 보자. "상품 사진이 위에 있고, 가격이 있고, 버튼이 있습니다…"라고 적은 뒤 질문한다. 두 결과를 비교하면 멀티모달 입력의 장점이 바로 드러난다. 모델은 사용자가 말로 설명하지 않은 배치, 대비, 정보의 밀도, 시각적 우선순위를 어느 정도 읽어 낸다. 물론 완벽하지는 않다. 그래서 중요한 UI·의료·제조 이미지는 사람이 검수해야 한다. 하지만 초기 진단과 아이디어 발상에는 매우 빠르다.

문서도 마찬가지다. PDF나 긴 텍스트를 넣고 요약을 요청하면, 단순 복사 붙여넣기보다 실제 업무 흐름에 가까운 실험을 할 수 있다. 이때 AI Studio 화면에서 토큰 수와 응답 길이를 함께 확인하자. 긴 컨텍스트는 강력하지만 공짜가 아니다. 입력이 길어질수록 비용과 지연시간이 늘 수 있고, 모델이 긴 문서의 모든 부분을 균일하게 잘 반영한다고 가정해서도 안 된다. 8장에서 파일 처리와 긴 컨텍스트 전략을 깊게 다루겠지만, 지금은 "파일을 올릴 수 있다"보다 "파일을 올렸을 때 무엇을 관찰해야 하는가"에 집중하자.

Get code는 복사 버튼이 아니라 전환점이다

AI Studio에서 마음에 드는 결과를 얻었다면 Get code를 눌러 Python, JavaScript, cURL 같은 형태로 예제 코드를 가져올 수 있다. 2025년 AI Studio 업데이트에서는 개발자 중심 UI, Starter Apps, API 키와 변경 로그에 접근하는 Dashboard, 기본 제공 코드 편집 기능 등이 강화되었다고 소개되었다.¹⁰ 즉 AI Studio는 단순한 채팅 화면을 넘어, 프롬프트 실험에서 프로토타입 코드로 넘어가는 다리 역할을 한다.

하지만 Get code를 누른 뒤 그대로 붙여 넣는 것으로 끝내면 안 된다. 생성된 코드는 "지금 화면의 실험을 코드로 옮기는 출발점"이지, 곧장 운영에 넣을 완성품이 아니다. 특히 API 키 처리, 예외 처리, 로그, 재시도, 사용량 제한, 입력 검증은 대부분 별도로 설계해야 한다.

예를 들어 Python에서는 대략 다음과 같은 형태로 환경변수를 사용한다.

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="고객 문의를 한 문장으로 요약해 줘: 결제했는데 서비스가 활성화되지 않았습니다."
)

print(response.text)

JavaScript에서는 다음처럼 시작할 수 있다.

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({
  apiKey: process.env.GEMINI_API_KEY,
});

const response = await ai.models.generateContent({
  model: "gemini-2.5-flash",
  contents: "고객 문의를 한 문장으로 요약해 줘: 결제했는데 서비스가 활성화되지 않았습니다.",
});

console.log(response.text);

지금은 이 코드를 완전히 이해하지 않아도 괜찮다. 중요한 것은 AI Studio의 실험 요소가 코드의 어디로 이동하는지 보는 것이다. 모델명은 model로, 사용자 입력은 contents로, 시스템 지시와 파라미터는 설정 객체로 옮겨 간다. 이 대응 관계를 이해하면 다음 장 이후의 SDK 실습이 훨씬 쉬워진다.

실험 로그를 남겨야 팀의 자산이 된다

AI Studio에서 멋진 결과가 한 번 나왔다고 해서 실험이 끝난 것은 아니다. 한 번 나온 결과는 운일 수 있다. 팀에서 재현할 수 있어야 자산이 된다. 특히 워크숍, 사내 데모, PoC에서는 "어제는 잘 됐는데 오늘은 왜 다르지?"라는 말이 자주 나온다. 모델명, 파라미터, 안전 설정, 입력 파일이 하나라도 달라지면 결과가 바뀔 수 있다.

그래서 AI Studio 실험에는 로그가 필요하다. 거창한 시스템이 아니어도 된다. 처음에는 스프레드시트나 마크다운 문서면 충분하다. 중요한 것은 무엇을 기록할지 정하는 것이다.

이 표는 번거로워 보이지만, 실제로는 시간을 아껴 준다. 팀원이 같은 프롬프트를 다시 열어 볼 수 있고, 모델을 바꿨을 때 품질 차이를 비교할 수 있으며, 나중에 API 구현자가 어떤 설정을 코드에 넣어야 하는지 알 수 있다. AI Studio의 저장된 프롬프트와 기록 기능도 이런 반복 실험을 돕는다. Google Skills 실습은 저장된 프롬프트를 기록에서 다시 확인하는 흐름을 포함한다.⁷

30분 실습 루틴: 하나의 프롬프트를 제품 후보로 만들기

이제 지금까지의 내용을 30분짜리 루틴으로 묶어 보자. 주제는 "고객 문의를 분류하고 답변 초안을 만드는 도구"다. 실제 고객 데이터 대신 아래 합성 문의를 사용한다.

문의:
어제 연간 요금제를 결제했는데 아직 프리미엄 기능이 열리지 않았습니다.
오늘 오후에 고객사 발표가 있어서 빨리 해결해야 합니다.

처음 5분은 기준 프롬프트를 만든다. 단순히 "이 문의에 답해 줘"라고 묻고 결과를 본다. 이 결과는 일부러 부족한 기준선이다. 다음 10분은 시스템 지시와 출력 형식을 추가한다.

시스템 지시:
너는 B2B SaaS 고객지원팀의 상담 초안을 작성하는 어시스턴트다.
고객에게 책임을 돌리는 표현을 쓰지 않는다.
확인되지 않은 보상이나 환불을 약속하지 않는다.
긴급도가 높으면 내부 확인 필요라고 표시한다.

사용자 프롬프트:
아래 고객 문의를 분석해 상담원이 검토할 초안을 작성해 줘.

출력 형식:
분류:
긴급도:
고객 감정:
상담 초안:
내부 확인 사항:

문의:
어제 연간 요금제를 결제했는데 아직 프리미엄 기능이 열리지 않았습니다.
오늘 오후에 고객사 발표가 있어서 빨리 해결해야 합니다.

다음 5분은 온도를 낮게 설정해 보고, 다시 중간 정도로 올려 본다. 낮은 온도에서는 더 안정적인 문구가 나올 가능성이 크고, 중간 온도에서는 더 부드러운 상담 문장이 나올 수 있다. 어느 쪽이 우리 제품에 맞는지 기록한다.

다음 5분은 구조화 출력으로 바꿔 본다. 상담원이 읽을 문장형 출력이 좋은지, CRM 시스템에 넣을 JSON 출력이 좋은지 비교한다. 예를 들어 category, priority, customer_sentiment, draft_reply, internal_action 필드를 가진 JSON으로 바꿔 본다.

마지막 5분은 Get code를 눌러 Python 또는 JavaScript 예제를 확인한다. 이때 코드를 실행하지 않아도 된다. 대신 AI Studio의 설정이 코드의 어느 부분으로 이동하는지 표시한다. 모델명, 프롬프트, 시스템 지시, 파라미터, 안전 설정을 찾아 메모한다. 이 메모가 다음 장 이후 구현의 출발점이다.

이 루틴을 마치면 단순한 프롬프트 하나가 작은 제품 후보가 된다. 아직 서버도 없고 데이터베이스도 없지만, 이미 중요한 결정을 했다. 어떤 입력을 받을지, 어떤 출력을 낼지, 어느 정도의 창의성을 허용할지, 어떤 안전 조건을 둘지 정했다. 코드는 그다음이다.

워크숍과 PoC에서 AI Studio를 쓰는 법

AI Studio는 개인 실험뿐 아니라 팀 워크숍에도 잘 맞는다. 특히 비개발자와 개발자가 함께 있는 자리에서 효과적이다. 기획자는 화면에서 결과를 보며 요구사항을 말할 수 있고, 개발자는 Get code와 설정값을 보며 구현 난도를 가늠할 수 있다. "AI가 이런 것도 해요"라는 추상적인 데모보다 "이 입력이 들어오면 이 JSON이 나와야 합니다"라는 데모가 훨씬 생산적이다.

워크숍에서는 역할을 나누면 좋다. 한 사람은 프롬프트를 수정하고, 한 사람은 결과를 평가하고, 한 사람은 실험 로그를 남긴다. 모두가 동시에 프롬프트를 고치면 금방 혼란스러워진다. 20분 단위로 하나의 작업만 다루고, 작업이 끝나면 성공 기준을 적는다. 예를 들어 "문의 분류 정확도는 샘플 20개 중 18개 이상", "JSON 파싱 실패 0회", "상담 초안은 700자 이하"처럼 측정 가능한 기준이 좋다.

PoC에서는 더 엄격해야 한다. PoC는 "가능해 보인다"를 증명하는 자리가 아니라 "어떤 조건에서 가능하고, 어떤 조건에서 실패하는지"를 확인하는 자리다. AI Studio 실험 로그에는 성공 사례뿐 아니라 실패 사례도 남겨야 한다. 안전 필터에 막힌 입력, 모델이 근거 없이 추측한 응답, JSON 형식이 깨진 응답, 너무 긴 문서에서 핵심을 놓친 응답이 모두 중요하다. 실패를 숨긴 PoC는 제품화 단계에서 더 큰 비용으로 돌아온다.

AI Studio에서 API 구현으로 넘어가기 전 체크리스트

AI Studio 실험을 마치고 코드로 넘어가기 전에 잠깐 멈추자. 이 멈춤이 중요하다. 실험실에서 괜찮아 보였던 것이 서비스에서도 괜찮으리라는 보장은 없다. 다음 질문에 답할 수 있어야 API 구현으로 넘어갈 준비가 된 것이다.

• 실험에 사용한 모델명과 검증일을 기록했는가?

• 시스템 지시, 사용자 프롬프트, 예시, 제약조건을 분리했는가?

• 온도, 출력 길이, 안전 설정을 바꿨을 때 결과 차이를 확인했는가?

• 무료·유료 사용 경계와 데이터 처리 조건을 확인했는가?

• API 키를 실습용과 운영용으로 분리하고 노출 방지 방법을 정했는가?

• 구조화 출력이 필요한 작업이라면 JSON 스키마 또는 필드 규칙을 정했는가?

• 멀티모달 입력을 쓴다면 파일 종류, 크기, 민감정보 제거 기준을 정했는가?

• Get code 결과를 그대로 쓰지 않고, 환경변수·예외 처리·로그·재시도 설계를 추가할 계획이 있는가?

이 질문에 대부분 답할 수 있다면, 이제 코드를 쓸 준비가 된 것이다. 답하지 못한 항목이 많다면 아직 AI Studio에 더 머무르는 편이 낫다. 실험실에서 하루 더 보내는 것이 운영 장애 한 번보다 싸다.

작은 실험이 큰 설계를 이긴다

AI Studio의 가치는 화려한 화면에 있지 않다. 가치는 빠른 반복에 있다. 같은 프롬프트를 낮은 온도와 높은 온도로 비교하고, 모델을 바꾸고, 안전 설정을 조정하고, 구조화 출력을 켜고, 이미지를 추가하고, 검색 그라운딩을 붙여 보는 동안 우리는 모델의 성격을 배운다. 이 배움은 문서만 읽어서는 얻기 어렵다.

처음부터 완벽한 프롬프트를 쓰려고 하지 말자. 대신 작고 재현 가능한 실험을 하자. 입력 하나, 목적 하나, 설정 하나를 바꾸고 결과를 기록하자. 그렇게 만든 실험 로그는 개발자의 구현 명세가 되고, 기획자의 요구사항 문서가 되고, 나중에는 운영 품질을 비교하는 기준선이 된다.

다음 장에서는 이 기준선을 바탕으로 모델 선택을 더 깊게 다룬다. 어떤 모델이 빠른지, 어떤 모델이 복잡한 추론에 적합한지, 비용과 지연시간을 어떻게 함께 설계해야 하는지 살펴볼 것이다. AI Studio에서 만든 작은 실험이 이제 실제 시스템 설계의 첫 번째 숫자로 바뀐다.

참고

¹Google AI Studio

²Gemini API reference - Google AI for Developers

³Using Gemini API keys - Google AI for Developers

⁴Billing - Gemini API - Google AI for Developers

⁵Gemini API Additional Terms of Service

⁶Google AI Gemini API Prompt Gallery

⁷Google AI Studio: 프롬프트 설계 - Google Skills

⁸Safety settings - Gemini API

⁹안전 및 콘텐츠 필터 - Vertex AI 문서

¹⁰Google AI Studio에서 Gemini API로 더 쉽게 개발하기