AI Studio로 10분 만에 ‘직장인 멘탈 서바이벌’ 게임 만들기

최근 여러 바이브코딩 툴을 익히는 과정에서,
Google AI Studio로 가볍게 미니게임을 하나 만들어봤습니다.
코딩 없이 프롬프트만으로
직장인 멘탈 생존 게임 “운명의 데스크탑”을 프로토타이핑한 실험입니다.

총 2시간 정도 소요되었고, 대략적인 타임라인은 아래와 같습니다.

    • 최초 구축: 프롬프트 설계 약 20분 + 프롬프트 전송/구축 약 10분 → 프로토타이핑 완성
    • 상세 튜닝: 약 90분
    • 총 소요: 약 2시간

즉, “10분”은 프롬프트를 통해 프로토타이핑이 최초로 완성된 시간이고,
프롬프트 설계와 완성도 튜닝까지 포함하면 별도 시간이 꽤 들어갔습니다.
아마 다른 프로젝트들도 유사하지 않을까 싶습니다.
(실행 비용은 낮고, 판단/검증 비용은 높음)

 

👉 [ ‘운명의 데스크탑’ 게임 플레이 ]

 

🤔 무엇을 만들었나: 텍스트 대시보드형 미니게임

<운명의 데스크탑>은 한 주를 버티는 구조의 선택형 게임입니다. 화면은 “시스템 진단 대시보드”처럼 고정된 UI로 보여주고, 각 단계에서 A/B 선택을 하면 멘탈 지수가 변합니다.

    • 목표: 월요일부터 금요일 18:00까지 멘탈 0% 초과로 버티기
    • 진행: 월~금 흐름 + 중간에 보너스(회복) 구간 1회
    • 출력 규칙: 스크롤을 줄이기 위해 3~5줄 중심, 대시보드 포맷 유지
    • 엔딩: 멘탈이 0%가 되면 즉시 [사직서 제출] 엔딩으로 종료
      • 참고로 현재 캡처는 lose 엔딩 흐름입니다. (win/lose 모두 “월요일 엔딩”으로 수렴하게 설계해 둔 건… 현실 반영입니다.)

1️⃣ 최초 구축(약 30분): 뼈대는 정말 빨리 나온다

AI Studio에서 가장 인상적이었던 지점은, “게임이 돌아가는 형태”까지 도달하는 속도였습니다.
역할/목표/턴/출력 포맷 같은 핵심 규칙을 프롬프트로 고정해 주면, 짧은 시간 안에 기본 흐름이 바로 작동합니다.

제가 처음 고정한 요소는 단순했습니다.

    • 역할: “운명의 데스크탑” (상황을 제시하고 결과를 출력하는 시스템)
    • 목표: 금요일 18:00까지 멘탈 유지
    • 입력: A/B 선택
    • 출력: 대시보드 형태 고정 + 짧은 문장 + 다음 단계 진행 안내

이 단계까지는 “정말 빠르게” 나옵니다. 문제는 그다음이었습니다.

2️⃣ 상세 튜닝(약 90분): ‘돌아감’과 ‘재밌음/읽힘’은 다르다

프로토타입이 돌아간다고 해서, 곧바로 “게임처럼 느껴지진” 않습니다. 제가 시간을 쓴 지점은 대부분 여기였습니다.

    1. 템포 조정: 길면 피로해진다
      초기 버전은 단계가 길어지면서 금방 읽기 부담이 생겼습니다.
      그래서 한 주 시나리오를 핵심 국면 중심으로 압축하고, 각 단계에서 “즉시 선택하고 넘어갈 수 있게” 문장을 줄였습니다.
    2. 콘텐츠 범위: 특정 직군 밈에 치우치지 않기
      처음엔 IT/개발자 맥락에 치우친 표현이 섞여 있었습니다.
      일반 직장인도 공감할 수 있도록 보고/급한 수정/회의/런치/퇴근 직전 이벤트처럼 범용적인 상황을 섞어 톤을 정리했습니다.
    3. 진행감: 텍스트지만 ‘UI처럼’ 보이게
      텍스트 게임이라도 “진행 중”이라는 느낌이 있어야 합니다.
      아이콘, 상태 라벨(STRESSED 등), 경고 문구, 멘탈 바(게이지)처럼 시각적 힌트가 되는 요소를 넣어 대시보드 감도를 올렸습니다.
    4. 밸런스: 회복 구간 하나로 난이도가 급변한다
      보너스(회복) 스테이지를 넣으면 난이도가 확 바뀝니다.
      그래서 멘탈 감소/회복 폭을 다시 맞추며 “너무 쉽지도, 너무 불가능하지도 않게” 조정했습니다.

✅ AI Studio가 특히 좋았던 지점

정리하면, AI Studio는 “프로토타이핑” 관점에서 강점이 뚜렷했습니다.

    1. 초안 품질이 안정적
      문장/구조가 비교적 정돈되어 나와서, 초반 QA 부담이 낮았습니다.
    2. 튜닝 루프가 빠름
      제약(포맷 고정, 출력 길이 제한, A/B 규격)을 걸어도 수정-재실행이 매끄러웠습니다.
    3. 배포까지 원스톱으로 이어지기 쉬움
      비개발자에게 가장 부담되는 구간이 보통 백엔드/배포인데, 이 부분을 크게 신경 쓰지 않아도 끝까지 가져갈 수 있다는 점이 인상적이었습니다.

⚠️ 아쉬운 점: 디테일 튜닝은 생각보다 어렵다

다만 한계도 분명했습니다.
프롬프트만으로도 형태는 빠르게 만들 수 있지만, 의도한 결과물을 100% 재현하는 디테일 튜닝에는 한계가 있었습니다. 특히 인터랙션, 밸런스, 예외 케이스까지 정밀하게 잡으려면 프롬프트만으로는 어렵습니다.

그래서 최종 완성도를 목표로 할 때는 Cursor나 Claude Code처럼 코드 수정이 가능한 도구가 필요하다고 느꼈고, 저도 현재는 Cursor AI로 다른 프로젝트를 병행하며 “프로토타입 → 코드 기반 완성” 흐름을 함께 가져가고 있습니다.

🧾마치며…

이번 실험으로 확실히 느낀 건 하나입니다.
AI Studio는 ‘퀄리티 있는 프로토타입을 빠르게 만들고, 배포까지 한 번에 처리’하는 데 강합니다.
반면, 완성도를 끝까지 밀어붙여 원하는 결과물을 정확히 구현하려면 코딩 기반 도구가 더 적합합니다.

저는 이번엔 AI Studio의 강점을 확인하는 목적이었기 때문에, 이 정도 결과물만으로도 충분히 의미가 있었습니다.

👉 [ ‘운명의 데스크탑’ 게임 플레이 ]

 

LLM 대규모 자동 평가에서 Gold–Silver–Bronze 라벨 체계가 필요한 이유

부제: 대규모 AI 평가를 가능하게 만드는 신뢰도 등급 시스템

 

AI 모델을 평가(Evaluation)할 때 가장 본질적인 질문은 단순합니다.

“이 평가 결과를 얼마나 믿을 수 있는가?”

정확한 평가를 위해서는 정답 기준이 필요하지만, 모든 데이터를 사람이 직접 라벨링하기에는 비용과 시간이 현실적인 제약이 됩니다. 반대로 모델이 자동으로 생성한 라벨은 빠르지만, 그 자체로는 신뢰하기 어렵습니다.

이러한 현실적인 문제를 해결하기 위해, AI 평가 및 데이터 라벨링 업계에서는 Gold–Silver–Bronze 라벨 체계를 널리 사용합니다. 이 체계는 라벨의 정확도·신뢰도·생산 비용을 기준으로 품질을 구분하는 실무적 분류 방식입니다.

Gold–Silver–Bronze 라벨 체계 개요

Gold–Silver–Bronze 체계는 단순한 등급 분류가 아니라, 대규모 AI Evaluation을 현실적으로 가능하게 만드는 운영 프레임워크에 가깝습니다.

등급핵심 의미
Gold사람이 검증한 정답 기준(Ground Truth)
Silver자동 라벨 중, 근거/정책에 따라 “사용 가능”으로 판정된 라벨
Bronze검증 전(또는 검증 수준이 낮은) 자동 라벨 / 관측용 라벨

각 단계는 서로 대체 관계가 아니라, 서로를 보완하는 역할을 수행합니다.

🥇Gold Label — 정답 기준(Ground Truth)

Gold Label은 AI Evaluation의 기준점이 되는 정답 데이터입니다.

정의

사람이 명확한 기준에 따라 직접 라벨링한 데이터로, 모델 성능을 평가하거나 다른 라벨의 신뢰도를 판단할 때 기준으로 사용됩니다.

특징

    • 가장 높은 신뢰도
    • 모델 평가의 기준선(Baseline)
    • 비용과 시간이 많이 소요됨
    • 평가, 벤치마크, 품질 검증에 필수

중요한 점

Gold는 “정답”이지만 무조건적인 진리는 아닙니다. 실무에서는 Gold 라벨 자체도 일정 수준 이상의 합의도와 일관성이 확보되어야만 기준으로 사용할 수 있습니다.

즉,
Gold를 만들었다는 것보다
Gold의 품질이 충분히 검증되었다는 것이 더 중요합니다.

이 기준선이 확보되지 않으면 이후의 모든 Evaluation 결과 역시 신뢰하기 어려워집니다.

🥈Silver Label — 운영/학습에 “사용 가능”으로 판정된 자동 라벨(Semi-Ground Truth)

현실적으로 모든 데이터를 Gold로 만들 수는 없습니다. 이때 Gold와 Bronze 사이의 간극을 메우는 역할을 하는 것이 Silver Label입니다.

정의

Silver Label은 “자동 라벨의 품질이 실제로 개선되었다”기보다, 아래와 같은 근거를 바탕으로 해당 자동 라벨을 ‘사용 가능’하다고 판정한 상태를 의미합니다.

    • Confidence(모델 확신도) 구간
    • Gold에서 관측된 오류 패턴/일치 패턴
    • 최소 샘플 검증(QC) 결과
    • Debate 등 보조 절차의 결과(적용하는 경우)

즉, Silver는 완벽한 정답이 아니라, “이 정도 리스크는 감수하고 사용한다”는 운영 의사결정의 결과물에 가깝습니다.

특징

    • 대량 데이터에 적용 가능
    • Gold 대비 비용 효율적
    • 학습 및 운영 데이터로 활용 가능
    • Evaluation의 보조 지표/보조 데이터로 사용 가능

Silver는 “완벽한 정답”은 아니지만, 실무에서 규모를 감당하면서 품질을 관리하기 위해 필요한 현실적 중간 지점이라는 점에서 중요한 위치를 차지합니다.

🥉Bronze Label — 검증 전(또는 검증 수준이 낮은) 자동 라벨

정의

Bronze Label은 모델이 자동으로 생성했지만, 사람의 검증이 전혀 개입되지 않았거나 검증이 매우 제한적으로만 이루어진 라벨입니다. 따라서 정답(Ground Truth)로 간주할 수 없으며, 평가 결과를 확정하는 기준으로 사용하기에는 위험합니다.

특징

    • 생성 속도 빠름
    • 비용 최소
    • 오류 가능성 높음
    • 평가 기준(Ground Truth)으로는 사용 불가

Bronze의 핵심 가치(오해 방지)

Bronze의 주된 가치는 “승격”이 아니라, 모델이 어디서 흔들리는지(불확실·실패 패턴)를 관측하고 진단하는 데 있습니다. 즉 Bronze는 단독으로 KPI에 바로 쓰기보다는, 다음과 같은 목적에 더 적합합니다.

    • 실패/불확실 영역의 분포 확인(리스크 지도)
    • 오류 패턴 탐지 및 개선 우선순위 설정
    • Confidence 기준선/정책 분기(가드레일) 설계 근거 확보

물론 일부 케이스는 추가 절차를 통해 Silver로 “흡수”될 수 있지만, Bronze 전체를 승격하는 것이 목표가 되는 경우는 드뭅니다.

왜 Gold–Silver–Bronze 체계가 필요한가

1. 대규모 Evaluation을 현실적으로 만들기 위해

모든 데이터를 Gold로 평가하는 것은 이상적이지만 현실적으로는 불가능합니다. Gold–Silver–Bronze 체계는 정확도와 효율 사이의 균형점을 제공합니다.

2. 비용·속도·정확도의 균형

    • Gold: 정확도는 높지만 비용과 시간이 큼
    • Bronze: 빠르지만 신뢰도가 낮고, 관측·진단 중심
    • Silver: 실무적으로 가장 많이 쓰는 “사용 가능” 중간 지점

3. 평가 자동화를 가능하게 함

Confidence, Debate, 샘플링 검증과 같은 기법을 통해 사람이 직접 개입해야 하는 영역을 최소화할 수 있습니다.

Trust Bucket과 Model Confidence의 역할 분리

AI Evaluation에서는 종종 Trust Bucket과 Model Confidence가 혼용되어 설명되곤 합니다. 그러나 두 개념은 역할이 명확히 다릅니다.

구분Trust BucketModel Confidence
기준수동 라벨(Gold)모델 내부 판단
관점사용자/프로덕션 품질모델 예측 품질
목적운영 품질 측정·개선자동화·스케일링 판단
책임 영역서비스/운영모델/평가
    • Trust Bucket은 “사람 기준에서 이 답변을 믿을 수 있는가”를 다룹니다.
    • Model Confidence는 “모델이 이 판단을 얼마나 확신하고 있는가”를 다룹니다.

Gold–Silver–Bronze 체계는 이 두 기준을 연결하여, Evaluation과 운영을 함께 설계할 수 있게 해주는 구조입니다.

정리하며

Gold–Silver–Bronze 라벨 체계는 단순한 분류가 아니라, AI Evaluation을 실제 서비스 환경에서 운영 가능하게 만드는 핵심 프레임워크입니다.

    • Gold는 정답 기준을 제공하고
    • Silver는 “사용 가능” 범위를 정의해 규모와 효율을 가능하게 하며
    • Bronze는 불확실/실패 패턴을 관측해 개선의 근거를 제공합니다.

이 글에서 설명한 구조는 실제 대규모 AI 평가 환경에서도 반복적으로 사용되는 방식이며, 구체적인 적용 사례는 별도의 글에서 다룰 예정입니다.

감사합니다.

AI 제품 워크플로우의 표준: Assistant → Agent → Gate

요즘 AI를 붙인 제품은 많습니다. 그런데 “대화는 그럴듯한데, 실제로 일은 안 끝나는” 경우도 흔합니다. 반대로 “일은 끝나는데, 사고 나면 누가 책임지지?”라는 질문도 따라옵니다.

이 둘을 동시에 만족시키는 구조가 점점 표준처럼 자리 잡는 분위기입니다.

보편 패턴: 대화(Assistant) → 실행(Agent) → 승인(Gate/Confirm)

제가 보는 가장 보편적인 구조는 이렇습니다.

    • Assistant(대화 흐름): 사용자의 의도/맥락/제약을 정리해서 “무엇을 할지”를 확정합니다.
    • Agent(실행 흐름): 툴 호출, 워크플로우 오케스트레이션, 재시도/오류 처리로 “어떻게 끝낼지”를 수행합니다.
    • Gate(승인/정책): 돈·권한·대외 발신·개인정보·운영 변경 같은 고위험 구간에서 Confirm(확인 창) 또는 승인 단계를 둡니다.

겉으로는 “대화형 어시스턴트”인데, 속으로는 “업무 실행 엔진(에이전트)”이 돌고, 중요한 순간에는 “사람의 도장(게이트)”이 찍히는 구조입니다.

왜 이 조합이 강한가

    • UX: 사람은 말로 목표를 던지는 게 쉽고, 시스템은 워크플로우로 실행하는 게 안전합니다.
    • 운영: 재시도/분기/예외 처리를 대화로만 풀면 길어지기 쉽고, 품질 관리가 어려워집니다.
    • 조직: 사고 비용이 큰 순간에는 “승인 로그”가 있어야 살아남습니다. (AI가 아니라 사람이요)

단점도 분명합니다

    • 게이트가 많아지면 자동화 체감이 떨어집니다. “AI가 해준다”가 아니라 “AI가 물어본다”가 됩니다.
    • 게이트가 없으면 언젠가 한 번 터질 확률이 높습니다. 그리고 그 ‘한 번’은 보통 제일 바쁠 때 옵니다. (법칙입니다)

(사례) 실제 구축한 하이브리드 챗봇

제가 운영한 하이브리드 챗봇은 한 줄로 말하면 이런 형태였습니다.

CS 실시간 처리(정형) + AI 게임 가이드(비정형) 를 한 경험 안에서 연결한 구조

그리고 이 구조를 굴리면서 “대화–실행–승인”을 분리해 설계하는 것이 운영 안정성과 확장성에 꽤 크게 기여했습니다.

    • 2025년 기준, 연간 약 55만 명 이상 사용
    • CS 티켓 중 챗봇 자동 처리율 약 41%
    • 응답 품질: Good 87% 이상, 속도: p50 1초 미만(대략)
      – (참고) ‘Good’은 내부 기준의 Human Evaluation 라벨 기반 지표로 응답 일치를 뜻함

1) Assistant(대화) — “질문을 실행 가능한 형태로 압축”

유저는 보통 이렇게 들어옵니다.

    • “결제했는데 아이템이 안 들어왔어요.”
    • “퀘스트가 막혔어요. 어디로 가야 해요?”
    • “접속이 안 돼요. 보안 문제 같아요.”

Assistant는 여기서 정답을 장황하게 설명하기보다, 실행에 필요한 최소 정보만 수집합니다.

    • 결제/지급: 서버/캐릭터/대략 시간/상품명
    • 진행 막힘: 현재 퀘스트 단계/지역/진행 맥락
    • 보안: 로그인 방식/오류 메시지/최근 접속 변화

핵심은 하나입니다.

질문을 길게 받지 말고, 실행 가능한 형태로 “압축”해서 넘기기
(사용자는 상담원이 아니라 플레이어니까요.)

2) Agent(실행) — “툴과 룰로 일을 끝내기”

Agent는 그 다음을 담당합니다.

    • 로그/상태 조회(결제·지급·계정 등)
    • 정책/조건 매칭(가능/불가/예외)
    • 자동 처리(가능하면 즉시 해결)
    • 자동 티켓 생성(불가하거나 예외면 담당자에게 넘김)
    • 결과 메시지/ETA 생성(유저에게 안내)

여기서 중요한 포인트는 “LLM이 알아서 다 한다”가 아니라,

LLM은 의도 파악·요약·정책/문서 탐색에 강하고,
실제 실행은 결국 워크플로우(툴/룰/권한)로 굴러가야 안정적인 점 입니다.

3) Gate(승인) — “통제”가 아니라 “신뢰(Trust) 장치”

사례에서도 Gate는 빠질 수 없습니다. 다만 Gate를 “승인 단계”라고만 보면 흔한 이야기입니다. 현장에서 더 중요한 관점은 Gate가 신뢰를 만드는 장치라는 점입니다.

    • Transparency(투명성): “왜 이 선택을 했는지”를 짧게 보여주기
      • 근거/정책 매칭 결과, 영향 범위(대상·수량·금액), 대안(있다면)
    • Safety(안전): 고위험 액션은 Confirm(확인 창)과 승인 정책으로 제한하기
      • 2FA/2인 승인/쿨다운/롤백(Undo) 같은 제어 장치 포함

장문의 설명은 읽히지 않습니다. 3줄 요약이 더 강합니다.

Gate 정책 + Confirm UX

위 원칙을 실제 제품에서 굴리려면, 결국 “정책(레벨)”과 “화면(Confirm)”이 필요합니다.
아래는 하이브리드 챗봇에서 바로 쓰기 좋은 실무형 템플릿입니다.

1) 리스크 레벨(정책)

    • Low: 자동 실행 + 로그 기록 + 결과만 안내
      • 예: 가이드/FAQ 응답, 경량 조회, 문서 요약
    • Mid: 실행 요약 제시 → 1회 Confirm → 실행
      • 예: 티켓 생성, 소액/소량 보상 발급, 되돌리기 가능한 설정 변경
    • High: 2FA/2인 승인(필요 시) + 영향 범위 표시 + 롤백/Undo 강제
      • 예: 환불, 대량 지급, 계정 제재/복구, 개인정보 내보내기, 프로덕션 설정 변경

한 줄 원칙: 되돌릴 수 있으면 자동화, 되돌릴 수 없으면 Gate 강화

2) Confirm(확인 창)에는 3가지만 넣기

Confirm 화면에서 가장 흔한 실패는 “설명 장문”입니다. 아래 3가지만 있으면 됩니다.

    1. 무엇이 바뀌나(변경 요약 1~2줄)
    2. 영향 범위(대상/수량·금액/리스크 포인트)
    3. 되돌리기/복구(가능 여부 + 방법)

3) 컨펌 문구 템플릿(대표 1개)

    • “아래 작업을 실행합니다. 대상: {대상} / 변화: {변경} / 영향: {범위} / 되돌리기: {가능/불가}. 진행할까요?”

예상되는 대표 워크플로우 4가지

“Assistant → Agent → Gate”가 보편 패턴이라면, 실제 제품에서는 아래 변형들이 함께 공존할 가능성이 큽니다(= 패턴 카탈로그). 여기서 중요한 건, 각 패턴은 장점만큼 비용(지연/운영 복잡도/비용)도 동반한다는 점입니다.

1) Auto + Undo 패턴 (저위험·고빈도)

자동 실행 → 되돌리기(Undo) 제공

    • 장점: 마찰이 적고 “AI가 일한다” 체감이 큽니다.
    • 단점: Undo가 설계/권한/로그까지 포함해 안전하지 않으면 “자동화”가 아니라 “자동사고”가 됩니다.

2) Plan-First 패턴 (실행 전 계획 제출)

계획 제출 → 승인 → 실행

    • 예: 대량 발송, 운영정책 변경, 이벤트성 보상 배포
    • 장점: 승인자가 “무엇을 할지”를 이해하고 책임질 수 있습니다.
    • 단점: 계획서가 길어지면 아무도 안 읽습니다.
      • 현실적으로는 3줄 요약 + 영향 범위 + 롤백이 가장 효율적입니다.

3) Agent-in-the-Loop 패턴 (부분 자동화)

중요 단계만 사람 참여(예외 처리/최종 결정)

    • 예: 가능한 옵션은 자동 제시, 최종 보상안/예외 승인은 상담원이 선택
    • 장점: 생산성과 품질을 동시에 노릴 수 있습니다.
    • 단점: 역할 경계가 애매하면 “AI도 사람도 서로 떠넘기는 상태”가 됩니다. (가장 흔한 실패)

4) Multi-Agent 패턴 (분업형 협업)

리서치/실행/검수/감사를 에이전트로 분리

    • 장점: 복잡한 업무에서 안정성이 올라갑니다.
    • 단점: 비용과 지연이 증가합니다. 에이전트끼리 회의하다가 퇴근할 수 있습니다. (사람이 아니라 에이전트가요)

정리: AI 제품은 ‘말 잘하는 챗봇’이 아니라 ‘업무 시스템’이 됩니다

앞으로는 “AI가 답변을 잘한다”보다,
“AI가 업무를 끝내고, 그 과정이 통제 가능한가?”가 더 중요해질 것입니다.

그래서 저는 워크플로우를 이렇게 정리합니다.

대화(Assistant) → 실행(Agent) → 승인(Gate/Confirm)

그리고 상황에 따라 Auto+Undo, Plan-First, Agent-in-the-Loop, Multi-Agent 같은 변형 패턴이 공존합니다. 결국 차이를 만드는 건, Gate를 통해 신뢰를 설계할 수 있느냐입니다.