이번 글에서는 프로덕트 디자이너가 구글의 새로운 IDE, 안티그래비티로 왜 글로벌 유저 테스트 봇(이하 글로봉)을 제작하게 되었는지, 어떻게 만들었는지 제작 과정을 소개하려고 합니다. 글로봉(Globong AI)은 글로벌 유저 테스트 봇으로, 인프런의 글로벌 - 다국어 대응을 위해 제작되었는데요. 다국어가 적용된 페이지의 번역 품질을 평가하고, 만약 문제가 있을 경우 원어민의 시선에서 자연스러운 표현을 제안합니다.

글로봉, 왜 필요했나

인프런은 2024년 글로벌 진출을 선언했습니다. 한국어를 기준 언어로 영어, 일본어, 베트남어를 제공하는데요. 이때 다국어 번역은 번역봇 ‘석봉이’가 수행해주고 있습니다. 충분히 잘 수행해 주고 있지만, 번역된 결과물이 실제로 얼마나 자연스러운지 또, 현지 사용자 입장에서 어떻게 느껴지는지에 대해서는 검증이 어려웠습니다.

그나마 영어, 일본어의 경우 팀 내 글로벌 팀의 도움을 받아 일정 수준까지 품질을 검증할 수 있었지만, 페이지 수가 점점 늘어나면서, 사람이 검수하는 방식에는 점점 부담이 커졌습니다. 특히 베트남어처럼 익숙하지 않은 언어를 검증하는 것은 사실상 불가능에 가까웠습니다. 프로덕트 디자이너로서 UI Text의 표현, 다시 말해 UX 라이팅을 통제하는 것은 중요하다고 판단했습니다. 서비스 현지화에서 UI Text의 표현과 문맥은 사용자 경험에 매우 큰 역할을 하기 때문이죠. 따라서 다국어 검증 방식은 변화해야만 하는 시점이었습니다.

정리하면,

다국어 페이지가 많아지며 사람이 검수하는 방식에 한계
베트남어처럼 익숙하지 않은 언어의 검증에 한계
프로덕트 디자이너로서 글로벌 UX를 위해

초기 기획과 방향성

AI에게 번역 평가를 맡기는 일은 사실 지금도 충분히 가능합니다. GPT급 AI 모델에게 번역이 완료된 페이지를 캡처해서 평가를 부탁하면 곧 잘 해냈기 때문입니다. 하지만 다국어 검증 방식을 바꾸려면 더 높은 접근성이 요구됩니다.

접근성이 낮으면, 일부 사람만 가끔 쓰는 도구로 남을 가능성이 큽니다.
사람마다 프롬프트를 다르게 쓰면, 평가 기준이 들쭉날쭉해지기 쉽습니다.

그래서 AI 모델에게 잘 부탁하는 방법이 아니라, 팀원 누가 사용해도 통제된 평가를 받을 수 있는 제품으로 방향성을 잡았습니다. 그런 의미에서 크롬 익스텐션을 염두에 두게 됩니다.

방향성은 정해졌습니다. 하지만 실제로 도구를 개발하는 일은 결코 쉽지 않습니다. 개발자 리소스를 정식으로 투입하기도 불확실성이 높아 디자이너 혼자 건드려보는 사이드 프로젝트로 접근합니다. 그럼에도 Cursor AI를 활용해 Figma 플러그인을 제작했던 경험이 있기에, ‘작게 시작해서 동작 가능한 형태’까지 가보는 것을 목표로 합니다. 동작이 가능한 형태가 나오면 그때 개발자 리소스를 빌려도 늦지 않습니다.

제작: 안티그래비티와 함께

제작을 시작했던 11월 중순에 Google에서 AI 기반의 IDE ‘안티그래비티(Antigravity)’를 내놓습니다. Cursor와 매우 유사하면서 Gemini3가 장착된 제품이었습니다. 심지어 별도의 과금 없이 Pro 모델도 사용할 수 있었죠. 이번 프로젝트는 이 친구와 만들어보기로 합니다.

안티그래비티의 첫인상은 새로웠습니다. 기존 IDE, 가령 VS Code나 Cursor의 레이아웃은 좌측 파일트리 패널, 중앙 코드 패널, 우측 프로퍼티 패널로 구성된 것과 달리, 마치 GPT, Gemini와 같은 대화형 인터페이스에 가까웠기 때문입니다. 마치 대화하듯 제품 개발을 하라는 의도로 보였습니다.

아무튼 본격적인 제작에 앞서, 안티그래비티 에이전트에게 어떤 제품을 만들고 싶은지 기본적인 명세와 사용자 스토리를 러프하게 작성해 전달했습니다.

안녕, 나는 디자이너야. 개발에 대한 지식이 거의 없다고 생각하면 돼. 
그래서 어떤 설명을 할 때에는 중학생에게 설명하듯 충분히 설명해 줘.
너와 함께 만들고 싶은 제품이 있어.
웹 페이지에서 번역된 텍스트를 원어민의 시선에서 검증하고 만약 어색하거나 잘못된 표현이 있으면
하이라이팅 해주고 더 나은 표현으로 변경할 제안 값을 주는 제품을 만들고 싶어.

(...중략)

사용자는 다음과 같은 스토리를 경험할 수 있어.

1. 사용자는 페이지에 접근한다.
2. 사용자는 검사 버튼을 누른다.
3. 평가 AI는 페이지에 번역된 텍스트를 검사한다.
4. 평가 AI는 어색한 표현이나 잘못된 표현에 하이라이팅 한다.
5. 평가 AI는 어색한 표현이나 잘못된 표현 대신 알맞은 제안 값을 제안한다.
6. 사용자는 하이라이팅 영역을 확인하고 제안되는 값을 확인할 수 있다.

사용자인 나는 얼마나 제품 개발에 이해가 있는지, 어떤 제품을 만들고 싶은지 혹은 어떤 과정으로 제품이 동작할지 초기에는 비록 추상적이지만 기획안을 안티그래비티에게 제공했는데요.

그 결과 안티그래비티의 다음 동작은 놀라웠습니다.

기획안을 받고는 마치 사람처럼 계획을 세웠습니다. 계획은 Tasks라는 파일을 생성하여 기록해 두었는데요. 그 덕에 사용자가 명시적으로 확인할 수 있습니다. 프로젝트 셋업부터 리팩토링까지 투두리스트처럼 단계별로 완수하겠다는 계획입니다.

이 방식이 왜 좋다고 느꼈냐면, 간혹 바이브 코딩을 진행할 때 에이전트 혼자 신나서(?) 개발을 치고 나가는 경우가 더러 있습니다. 원하는 방향이 아닐 경우 토큰만 태우게 됩니다. 반면, Tasks 파일이 명시적이니까 사용자가 계획을 확인하고 도중에 수정할 수도 있었습니다. 가령, Advanced Features에 JSON report를 다운로드하겠다는 계획을 확인하고 클립보드 복사로 변경할 수도 있겠죠.

안티그래비티는 자신이 세운 계획을 착실하게 수행해 나갔습니다. 이때 사용자는 사실 크게 할 일은 있진 않습니다. 슬롯머신을 돌려 결과물을 기다리듯, 중간중간 권한에 대한 요청을 수락하고 기다렸습니다. [Accept], [Accept].. 그리고 제품의 특성상 Google AI Studio의 API키가 필요해 해당 키값을 넘겨주었습니다. (여담이지만, AP I키 같은 보안이 필요한 정보는 대화창에 넣지 말라고 하더군요.)

어느 정도 작업이 진행된 이후 안내에 따라 크롬 익스텐션 - 개발자 모드에서 제품을 실행시켜 보았습니다. 무수한 에러가 발생했고, 이때부터 계속해서 에러를 픽스하는 과정을 거쳤습니다.

에러가 발생하면, 해당 에러코드 혹은 화면을 캡처해 에이전트에게 물어가며 수정해 나갔습니다. 이후 몇 시간의 대화와 수정을 통해 글로봉의 첫 번째 동작을 확인합니다.

인터페이스는 다소 엉성하지만 기능 명세의 지침에 따라 제품이 동작합니다. [Start Analysis] 버튼을 누르면 검사가 시작됩니다. 약 20초간 로딩이 진행되고, 리포트를 만들어주었습니다. 변경이 필요한 원본 텍스트는 무엇이고, 이를 어떻게 변경하면 좋을지, Popover UI를 통해 보여주었네요. 글로봉의 첫발을 내딛는 순간입니다.

두 가지 핵심 개선

첫발을 내디뎠지만, 여전히 개선할 부분들이 많습니다. 번역된 페이지 여러 곳에서 테스트를 돌려보니 아쉬움이 컸는데요. 크게 두 가지의 핵심 개선을 목표로 합니다.

검증 품질 개선
사용자 경험(UX) 개선

번역 검증에 대한 품질이 개선되어야 했습니다. 이러한 테스트 도구는 사실상 검증 품질이 9할입니다. 아무리 유려해도 가치가 없으면 쓸모가 없습니다.

두 번째 핵심은 사용자 경험입니다. 몇 군데 페이지에서 테스트해 보니 불편하더라고요. 어떤 부분이 이슈가 있는지 확인하기 어렵고, 결과 리포트의 가독성이 좋지 않았습니다. 검증 품질을 충분히 높이고, 유려한 사용성이 뒷받침되어야 많은 팀원이 사용할 겁니다.

1.1 검증 품질 개선

우선 품질을 개선하기 위해서는 글로봉의 동작 방식을 이해할 필요가 있었습니다. 글로봉은 크게 다음과 같이 동작합니다.

페이지의 텍스트를 추출한다.
추출된 텍스트를 평가 에이전트에게 보낸다.
평가 에이전트는 프롬프트 지침을 통해 텍스트를 평가한다.
이슈가 있는 텍스트를 프롬프트 지침에 따라 분류한다.
이슈가 있는 텍스트를 사용자 화면에 뿌려 준다.

이 과정에서 품질을 개선하려면 평가하는 단계 즉, 1~3번까지 과정이 중요하다고 판단했습니다.

페이지에서 텍스트를 잘 추출할수록
평가 에이전트가 똑똑할수록
프롬프트 지침이 구체적이고 명확할수록

검증 품질이 향상될 것입니다. 평가 에이전트로 텍스트를 보내기 전에 어떤 텍스트가 추출되는지 확인했습니다. 안티그래비티에 추출된 텍스트를 확인할 방법을 문의했고, 곧바로 콘솔 창에서 확인할 수 있는 코드를 추가했습니다. 그 결과 다음과 같이 전송되고 있었습니다.

문제: 벌크한 텍스트 덩어리

Extracted Text라 부르는 텍스트 덩어리를 평가 에이전트에 전달했습니다. 이 텍스트에는 페이지 맥락이 없고, 확인이 불필요한 내용도 포함되어 있어 평가 품질이 낮을 수밖에 없습니다.

해결책

텍스트 구조화 - [H1], [BUTTON], [LINK], [LABEL], [PLACEHOLDER], [TEXT]
레이아웃 맥락 - 구조화된 텍스트를 DOM 순서대로 자연스럽게 정렬
노이즈 요소 필터링 - iframe, svg, path, script, style 등

어떤가요? 사람이 보아도 구조화된 텍스트로 보이지 않나요? 추출된 텍스트에 태그를 붙여 구조화하고, DOM 순서를 따랐습니다. 평가해야 할 텍스트양도 줄었습니다. 그 결과 검증 품질이 크게 향상되었습니다.

두 번째는 에이전트를 더 똑똑하게 만드는 것입니다. 최초 Google AI Studio에서 API 키로 설정한 에이전트는 Gemini 무료 버전이었습니다. 성능은 괜찮았으나 최신 모델을 사용하면 평가 능력이 향상될 것으로 판단했습니다. 이를 업그레이드하는 작업과, 글로봉 크롬 익스텐션 사용 시 개인 로컬 서버를 실행해야 했습니다.

이를 n8n에 위임해 로컬 서버 없이 언제든 사용할 수 있도록 수정했습니다. 이 과정에는 사내 개발자의 도움과 아이디어가 반영되었습니다. (비개발자 바이브 코딩의 한계가 분명 존재합니다.)

마지막은 프롬프트 개선입니다. 아무리 똑똑한 에이전트라도 지침이 명확하지 않으면 좋은 평가 품질을 내기 어렵습니다. 최초 프롬프트는 최소한의 역할과 규칙만 부여되어, 세밀한 문제를 지적하는 데 한계가 있었습니다.

예를 들어, 상태를 나타내는 Draft를 Drafted로 제안하거나, ' ' 빈 값을 계속 감지하거나, 일본어 번역 페이지에서 일본어 번역 여부를 문제 삼는 경우가 있었습니다. 이는 에이전트 지침이 불분명했기 때문으로 보였습니다.

AS-IS

## Role
You are a native English speaker from the United States, working as a software developer in the tech industry.
You're reviewing this English content as if you're a potential user of this educational platform.
→ 역할이 명확하지 않았다. 영어 원어민으로만 한정하니 일본어와 베트남어에서 오류가 발생했다.

## CORE PRINCIPLES (MOST IMPORTANT):
1. **Focus on awkwardness**: Only flag text that sounds UNNATURAL or AWKWARD to native speakers
2. **If it's fine, don't flag it**: Don't create issues just to find something - if the text is acceptable, skip it
3. **Minimal changes preferred**: Suggest changing just 1-2 words rather than rewriting entire sentences (cost-effectiveness matters!)
→ 어색함(awkwardness)의 범위가 명확하지 않았다. 어디까지를 어색하다고 정의할 수 있는지.

TO-BE

## Role
You are a native English speaker from the United States, working as a software developer in the tech industry.
You're reviewing this English content as if you're a potential user of this educational platform.
→ 역할에 원어민 정보를 {{$json.lang}} 변수값으로 받도록 했습니다. 영문 페이지는 영미권 사용자의 입장, 일본어 페이지는 일본인, 베트남어 페이지는 베트남 원어민 입장에서 역할을 수행하도록.

## Evaluation Method
You will be given a batch of UI texts extracted from the service interface.  
This text follows the actual DOM order of the page, and each line consists of one UI element and its corresponding text.
For example, an English page might look like this:

Content: [H1] Figma Master Course #1  
[TEXT] Draft  
[LINK] View Course Page  
[BUTTON] Save  
(중략..)

→  평가 방법에 대해 기술했는데요. 앞서 구조화되어 추출되는 텍스트의 예시를 넣어주고 이 텍스트는 페이지의 어떤 맥락(페이지에서 DOM 순서로 추출되었고 [BUTTON]과 같은 컴포넌트 맥락)으로 제공되는지 명시했습니다.

Do NOT create an issue in the following cases:
  - Example:
    - Original: `View Course Page`
    - Suggestion: `Go to course page`
    → Both are acceptable. Do NOT report this as an issue.

- **Standard UI terms are acceptable**: Common UI terms like `Next`, `Back`, `Save`, `Cancel`, `Draft`, `Submit`, `Delete`, `Edit`, `Close`, etc. are widely used and acceptable. Do NOT suggest alternatives like "Continue" for "Next" or "Remove" for "Delete" unless there is a clear context-specific reason.
(중략..)

→ 어색함(awkwardness)의 모호함을 예시로 설명했습니다. 프롬프트 작성 시 (Do)와 (Do Not)를 활용하면 높은 확률로 통제할 수 있었습니다.

이외에도

Core Evaluation Principles (Most Important)
Perspective When Evaluating Awkwardness
When to create an issue (and when NOT to)
Issue Report Classification Rules
Target Text and Output Format
Content to analyze
JSON Format
etc..

390줄 정도의 프롬프트 지침을 깎고 깎았습니다. 초반 글로봉과 비교해 평가 품질이 상당히 개선됨을 체감했습니다.

1.2 사용자 경험(UX) 개선

검증 품질 개선과 함께 사용자 경험도 병렬적으로 개선해 나갔습니다.

검증 결과 판독성
검증 결과 가독성
검증부터 결과 공유까지 원활한 흐름
1. 검증 결과 공유를 위한 Export 기능
2. 지루함을 덜할 ‘로딩 오로라’ 애니메이션

초기 Popover UI를 우측 Drawer UI로 변경했습니다. 드로어는 접고 펼칠 수 있으며, 많은 이슈 리포트도 스크롤로 쉽게 확인할 수 있습니다. 그리고 하이라이팅 영역을 강화했습니다. 백그라운드 컬러와 언더라인 스타일을 적용하고, 이슈 번호를 병기했습니다. 클릭 시 이슈 리포트로 연결됩니다. 이슈 텍스트와 리포트의 판독성이 향상되었습니다.

이슈 리포트의 카드 UI도 레이아웃을 정돈했습니다. 구성을 다음과 같이 정리했는데요.

Type은 Critical - Medium - Minor로 구분해 이슈의 정도를 표기합니다.
Category는 Grammar - Naturalness - Terminology - Clarity로 구분해 이슈의 성격을 표기합니다.
다음 줄에는 Original - Suggestion이 표기됩니다. 무엇을 수정해야 하고, 무엇으로 수정해야 하는지
그 다음에는 Description, Reason, Why, Better가 표기되는데요. 이게 매우 중요하다고 생각했습니다.
1. 제안된 값을 수정하는 주체는 결국 '사람'입니다. 제안된 값을 수정할 때는 납득할 만한 사유를 제시해야 변경합니다. 사유가 불명확하면 제안된 값을 선택하지 않고 글로봉을 사용할 이유가 사라집니다.

이슈와 이슈 리포트가 납득된다면, 실제 수정 단계로 넘어가야 합니다. 다국어 언어셋은 다양한 도구로 관리하므로 여러 Export 수단을 제공합니다. Markdown 형식으로 내보낼 수 있으며, JSON 형식(예: {key} : {value})으로도 추출할 수 있습니다. 또한 클립보드 복사를 제공해 슬랙 등 소통 채널로 공유할 수 있습니다. 사람이 관리하는 만큼 소통 채널 공유는 필수입니다.

클립보드 복사 시 아래 형식으로 추출됩니다.

Page: https://www.inflearn.com/ja/users/***/@***
Analyzed: 2025-12-35 오후 11:00
Total Issues: 2

[#1] Medium | Terminology

Original: 保管箱
Suggestion: 保存済み

Issue: 웹 서비스 UI 용어로 부자연스럽습니다.
Why: '보관함(保管箱)'은 물리적인 상자나 은행 금고 등을 연상시킵니다. 
디지털 콘텐츠(스크랩, 저장된 글 등)를 모아두는 곳이라면 '保存済み', 'コレクション', 'ブックマーク' 등이 훨씬 자연스럽습니다. 
문맥상 '스크랩'이나 '저장' 기능을 의미하는 것으로 보입니다.
Better: 디지털 UI에서 사용자가 저장한 콘텐츠를 모아두는 메뉴는 '보관 상자'라는 직역투 표현보다,
'보존됨(保存済み)' 혹은 '북마크(ブックマーク)'가 더 널리 쓰입니다.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[#2] Minor | Naturalness

Original: 作成した投稿
Suggestion: 投稿

Issue: 문법적으로 맞으나 UI 라벨로는 다소 깁니다.
Why: 의미는 명확하지만, 보통 프로필 메뉴 등에서는 명사형으로 간결하게 '投稿' 혹은 '自分の投稿'라고 표현하는 것이 일반적입니다. 
바로 위에 '작성한...'이라는 수식어가 붙는 것이 UI상 군더더기처럼 느껴질 수 있습니다.
Better: 메뉴명은 간결할수록 좋습니다. 본인의 프로필 하위 메뉴라면 단순히 '투고(게시글)'라고만 해도 자신이 쓴 글임을 알 수 있으며, 
필요하다면 '自分の投稿'가 더 자연스럽습니다. 여기서는 다른 메뉴와의 통일성을 고려해 간결하게 제안합니다.

작은 변화지만 '로딩 오로라' 애니메이션을 추가했습니다. 평가 에이전트가 평가하는 시간이 길어질 때가 있습니다. (1분 타임아웃을 넘긴 경우도 있었습니다.) 이때 에이전트가 판단 중임을 보여주기 위해 페이지를 감싸는 오로라 애니메이션을 적용했습니다. 지루함을 줄이고, 최근 AI 애니메이션 스타일을 반영했습니다.

결과

결과적으로 글로봉은 이러한 형태로 평가 - 이슈 리포팅 - 이슈 공유가 이루어집니다.

어떤가요, 생각보다 쓸만한가요? 저는 꽤나 만족스러운 프로젝트였습니다. 마침 11월, 실무에 적용시켜볼 기회가 생겼습니다. ‘지식공유자의 강의 만들기 플로우’에 다국어 진행을 저희 팀이 담당했는데요. 해당 강의 만들기 플로우를 영문, 일본어, 베트남어로 다국어를 번역한 후 해당 글로봉을 이용해 QA를 진행했습니다.

글로봉은 수정이 필요한 텍스트를 파악하고, 처음 번역본과 비교해 각 언어별로 약 50개씩, 총 150개 언어 값을 변경했습니다. 이후 검수를 거쳐 12월 8일경 ‘강의 만들기’ 플로우에 다국어가 적용되어 공개됩니다.

다음날인 12월 9일 한 일본인 지식공유자가 강의를 제출해 주십니다. 처음 [강의 제작] 버튼부터 [강의 제출]까지 소요된 시간은 단 60분이었습니다. 짧은 시간입니다. 이분은 이미 제작된 강의가 있으신 분이었다는 점, 다른 플랫폼에서 강의를 올려본 경험이 있는 점을 감안해도 꽤나 빠르게 제작해 주셨습니다. 제출 이후 인터뷰를 통해 ‘강의를 만드시며 UI에 어색한 표현’이 있는지 여쭤보았습니다. 전혀 어색하지 않고 제작 과정이 어렵지 않다고 답변해 주셨습니다.

글로봉이 어느 정도 동작한 결과라고 보입니다. 결국 글로봉의 사용법을 정리하고 사내에 공유했습니다. 동작한 결과가 있으니, 다국어를 진행할 다른 팀원들도 무리 없이 사용할 것이라 기대하고 있습니다.

마치며

이번 글에서는 프로덕트 디자이너가 왜 글로벌 유저 테스트 봇(글로봉)을 제작했는지, 그리고 어떻게 만들었는지 제작 과정을 살펴봤습니다. 앞서 배경에서도 언급했지만, 다국어가 적용된 UI 텍스트는 글로벌 사용자 경험(UX)에 지대한 영향을 줍니다. 그런 면에서 검증된 다국어 표현을 서비스 전역에 적용시키고 싶었고요. 그리고 이를 가능케 한 것은 역시 AI였습니다. Cursor, Antigravity 등과 함께 아이디어만 있다면, 무엇이든 만들어 볼 수 있습니다.

다만 글로봉은 바이브 코딩으로 만들기에 유리한 제품이었습니다.

현재 돌아가는 서비스에 덧붙임 없이, 그러니까 레거시 없이 만들 수 있었습니다.
API가 필요하거나 어떤 동적인 데이터가 필요하지 않았기에 유리했습니다. (평가 에이전트가 필요하긴 했지만)
마침 팀 내 개발자분들의 도움을 받을 수 있는 환경이었습니다.
- 같은 의미로 고도화의 영역으로 갈수록 코드는 스파게티가 됩니다. 비개발자는 분명 여기서 막히게 되죠.

그럼에도 비개발자는 반드시 이 경험을 해야 한다고 생각합니다. 특히 디자이너의 문제 해결 능력은 단순히 피그마에 머무르지 않고, 실제 제품 구현과 관리 단계를 거쳐 사용자에게 전달되는 경험까지 포함되어야 합니다. 이는 앞으로 디자이너가 반드시 거쳐야 할 과정입니다.

이제 여러분도 망설이지 말고, 작은 아이디어라도 직접 실현해 보세요. 그 과정에서 얻는 인사이트는 곧 다가올 AI + 디자이너의 큰 자산이 되어줄 겁니다.