한국어로 만든 앱을 이틀 만에 영어 제품으로 바꾼 방법
코딩은 AI에게 맡겼습니다 · 시즌 1 / 3
첫 커밋 이틀 뒤에는 화면과 확장 프로그램 설명을 한국어에서 영어로 바꿨습니다. 기록상 네 개 파일에서 27줄을 추가하고 30줄을 삭제했습니다. AI가 가장 빠르게 처리하는 작업 중 하나가 이런 반복적인 문구 변경입니다.
먼저 보는 핵심
영어 문구로 바꾸는 것은 번역이고, 언어를 나중에도 추가할 수 있게 만드는 것은 국제화입니다. 첫 버전에서는 빠른 시장 확인을 위해 영어로 전환했지만, 화면 문구를 코드에서 분리하지 않으면 다음 언어에서 같은 비용을 다시 냅니다.
왜 영어부터 선택했나
Chrome Web Store는 한국 밖의 사용자도 접근합니다. 기능이 단순한 메모장이라면 사용법을 길게 설명하지 않아도 되므로, 초기부터 영어 화면으로 두는 것이 사용자 범위를 넓히는 가장 작은 변화였습니다.
이 단계에서 AI에게 맡기기 좋은 일은 다음과 같습니다.
- 버튼과 안내 문구 후보 만들기
- 같은 동작에 다른 용어가 섞였는지 찾기
- Manifest의 이름과 설명을 화면 문구와 맞추기
- 지나치게 긴 문구를 좁은 Side Panel에 맞게 줄이기
하지만 자연스러운 번역과 제품에서 일관된 용어는 다릅니다. Save, Saved, Keep, Pin은 모두 익숙한 단어지만 제품 안에서 서로 다른 행동을 뜻할 수 있습니다. AI가 제안한 문구도 실제 버튼이 하는 일과 대조해야 합니다.
문자열을 바꾸는 것보다 먼저 할 일
언어를 바꾸기 전에 화면에 노출되는 문구를 목록으로 만들면 누락을 줄일 수 있습니다.
| 위치 | 확인할 문구 |
|---|---|
| Manifest | 앱 이름, 짧은 설명, 툴바 제목 |
| Side Panel | 탭, 버튼, 빈 화면 안내 |
| 오류 | 저장 실패, 잘못된 파일, 용량 초과 |
| 데이터 | 기본 메모 제목, 내보내기 파일 이름 |
| 스토어 | 상세 설명, 개인정보처리방침, 업데이트 내역 |
화면에서 보이는 버튼만 번역하면 오류 메시지나 다운로드 파일 이름에 이전 언어가 남기 쉽습니다. AI에게는 “모든 한국어를 영어로 바꿔줘”보다 “사용자에게 노출되는 문자열의 위치를 먼저 찾아 표로 보여줘”라고 요청하는 편이 안전합니다.
빠른 전환 뒤에 남은 빚
초기에는 문자열을 각 HTML과 JavaScript 파일에서 직접 바꾸는 방법이 빠릅니다. 하지만 언어가 두 개를 넘어가면 같은 문장을 여러 파일에서 관리하게 됩니다.
다음과 같은 신호가 보이면 문자열 분리가 필요합니다.
- 같은 버튼 문구가 두 곳 이상에 나타난다.
- JavaScript에서 오류 메시지를 직접 만든다.
- 언어별로 문장 길이가 달라 레이아웃이 깨진다.
- 스토어 설명과 앱 내부 용어가 자꾸 달라진다.
실제로 Simple Side Note는 이후 여러 언어를 지원하는 구조로 발전했습니다. 처음부터 완벽한 국제화 구조를 만들 필요는 없지만, 빠른 번역이 영구 구조라고 생각해서도 안 됩니다.
AI에게 맡길 때 사용한 검토 방식
번역 결과는 단어별로 읽기보다 실제 행동 순서로 확인했습니다.
- 앱을 처음 열었을 때 무엇을 해야 하는지 이해되는가
- 메모를 저장한 뒤 어디에서 다시 찾는지 알 수 있는가
- 삭제나 복원처럼 위험한 버튼은 결과가 분명한가
- 오류 메시지가 사용자가 다음에 할 일을 알려주는가
- 좁은 패널에서 문구가 잘리거나 두 줄로 어색하게 갈라지지 않는가
AI는 번역 속도를 높였지만, 어떤 표현이 제품의 행동을 가장 정확하게 설명하는지는 화면을 직접 사용하면서 결정해야 했습니다.
다음 편
영어 화면을 만든 다음에는 테마와 드래그앤드롭을 손봤습니다. 다음 편에서는 AI가 멀쩡히 구현한 기능을 왜 닷새 만에 삭제했는지 다룹니다.
댓글
댓글 쓰기