NOTES · 2026-08-18
한글 패치 작업의 실제 대화
Conversations from Korean patch projects
AI와 한글 패치를 만들 때 사람이 하는 일
The human work in making a Korean patch with AI
옛날 게임을 한국어로 옮기는 일에는 프로그램을 뜯어고치는 작업이 들어갑니다. 그래서 코드를 모르면 못 한다고 생각하기 쉽습니다. 지금은 그 부분을 AI 에이전트가 합니다.
사람은 게임 내용을 확인하고, 번역을 읽고, 화면에서 어색한 곳을 짚습니다. 2026년 2월부터 8월까지 실제로 보낸 프롬프트 35개를 모았습니다. 어떤 일을 맡게 되는지 보고 시작할지 판단해 보세요.
수작업과 도구의 변화
Manual work and tools
처음에는 사람이 화면과 메모리 값을 확인해 에이전트에게 전달했습니다. 반년 동안 에이전트의 지침 이해, 관찰 도구, 공용 작업 지침이 함께 달라졌습니다.
- 에이전트가 지침을 더 잘 이해하게 됐습니다. 같은 주장을 3월엔 열흘 걸려 관철했고 8월엔 반나절 만에 릴리스 후보가 나왔습니다.
- 관측과 검사를 도구에 맡기게 됐습니다. 실행 중인 게임을 읽는 일, 원본과 패치판을 맞춰 비교하는 일, 쓰기 범위를 검사하는 일이 도구로 처리하게 됐습니다.
- 반복된 판단이 스킬로 성문화됐습니다. 3월에 즉흥적으로 던진 원칙이 6월에 이름을 얻고 7월엔 커밋 메시지에 인용되고 8월엔 다른 프로젝트의 판정 근거가 됐습니다.
프롬프트에도 그 변화가 드러납니다.
| 초기Early | 후반Later | |
|---|---|---|
| 프롬프트의 대다수Most prompts were | 기술 보고 — VRAM 몇 번지에 뭐가 들어갔고 타일이 어떻게 쪼개져 있는지technical reports — which VRAM address holds what, how the tiles are split | 판단 — 무엇을 완성으로 볼지, 무엇을 버릴지, 누가 무엇을 결정할지judgement — what counts as done, what to drop, who decides what |
| 게임당 프롬프트Prompts per game | 520 | 106 |
지금은 이 도구와 스킬을 이용해 시작할 수 있습니다. 사람이 화면을 보고 기술적인 내용을 일일이 옮겨 적던 작업을 도구에 맡길 수 있어서, 코드를 모르는 사람도 참여할 수 있게 됐습니다.
실제 대화 사례
Conversation examples
아래는 실제 프롬프트 서른다섯 개입니다. 오타와 말투를 그대로 두고, 상황에 따라 아홉 묶음으로 나눴습니다. 인용 바로 위에 당시 상황을 짧게 적었습니다.
인용에는 작업하며 쓰던 말이 그대로 들어 있습니다. 자주 나오는 셋만 알면 됩니다. ROM은 게임 한 편이 통째로 담긴 파일, 글리프는 화면에 찍히는 글자 하나하나의 그림, HITL은 사람이 직접 게임을 켜서 눈으로 확인하는 단계입니다. 낯선 용어를 전부 이해할 필요는 없습니다. 점선이 그어진 낱말은 눌러 보면 뜻이 뜹니다.
대사와 화면의 누락
추출 결과에 빠진 부분은 게임을 해 본 사람이 알아차리기도 합니다.
자동 추출이 5층 부근까지만 설명하고 있을 때
뭔가 한가지 이상한게 있거든? 이 게임은 1~5층짜리 게임이 아니라, 11층까지 + 지하 4층까지 있는 게임이야. 혹시 뭐 텍스트 뱅크 누락된거있나?
추출 결과가 세 편짜리 RPG의 이야기를 460개로 정리해 왔을 때
이 게임이 스토리가 460밖에 안될리는 없지 않을까? 상식적으로?
대사는 전부 한글로 빌드됐고 첫 메뉴에서 그래픽 글자 세 개를 찾아냈을 때
이 "글자"가 3개로 끝나는게 아니라, "옵션"이나 각 서브메뉴로도 더 많이 있거든. 체크해봐
한 번에 등록할 수 있는 외자 188칸이 게임 전체의 한계처럼 보였을 때
그런데 원래 일본어 게임은 그러면 저 188자리가 아니라 다른 공간에서부터 글리프를 읽어온다는거지?
게임의 진행 순서
캐릭터를 바꾸거나 다음 퍼즐로 넘어가는 순서가 조사에 필요했습니다.
퍼즐 조건 글자를 화면에 한 번 넣어 첫 화면을 맞췄을 때
다른게 계속 덮어씌우는거아니야? 이건 한번 깨고 끝이 아니라 각각 조건을 가진 2~6개의 퍼즐을 풀어야하는건데, 조건은 계속 바뀔테니까 또. 그때그때 계속 넣고 있어? 한번만 우리가 덮어씌우려고 하는게 실수일 수 있을거고
캐릭터마다 필요한 글자가 달라 ROM을 세 개 만드는 우회가 구현됐을 때
우선 지금 bin/cue들 out쪽에 있는거 다 날려줘. 저 3ROM 방식은 진짜 말도 안되는 짓거리야. 이건 소프트웨어가 아니라 게임이라고. 실기 패치를 하는 사람도 있는데 3ROM 배포같은 짓을 한다고? 캐시 구조를 애초에 파악해야하는 이유가 뭐지? 첫 로드는 지금 나만 해보고 있는거 아니야? 그냥 내가 에뮬레이터 캐시 날리면 끝 아닌가?
파일을 세 벌 만드는 대신 실제 적재 시점을 찾기로 한 뒤
재로드를 하는게 맞는지가 문제거든. VRAM? 같은곳에 올라가는거 확실해?
캐릭터 선택 화면에서는 글자를 불러오는 지점이 잡히지 않았을 때
이게 히트하는 순간은 던전 진입 시점이네. 전체 플로우 떠올려. 내가 플레이하는 캐릭터가 아르르기때문에 이런 로드가 일어난 기분이라고 보면 되겠네.
게임 내용과 오역
아이템 효과나 퍼즐의 답을 알면 자연스러워 보이는 오역도 찾을 수 있습니다.
영어판이 비슷한 절임 둘을 한 단어로 뭉개 놓은 것을 따라가려 할 때
후쿠진즈케는 락교가 아니거든. 좀 심각한 차이인데? 락교는 그냥 일본어로도 락교라 되있지않아? 굳이 따지면 한국에서는 "행운절임"으로 번역됬던건데, 후쿠진즈케를 그대로 쓰기로 하지 않았어? 이 게임에는 락교라는 아이템도 (체력 최소회복), 후쿠진즈케라는 아이템도 (체력 중 회복) 둘 다 존재해. 아이템 혼동이 나면 큰일나.
화면의 한국어 문장 자체는 자연스러웠을 때
또한 "정말 미안하구나 하지만" 이쪽은 센세와 쟌넨데시타 뭐 이런 JP 음성이 들리는데, 선생님은 정말 아쉽구나 이런거 아니야?
퍼즐 힌트가 문장으로는 지나치게 축약된 것처럼 보였을 때
왼오오오왼 그 자체는 가능성은 있어. 이유는 저 힌트가 맞긴하거든 (왼-오-오-오-왼으로 배치해야한다는거)
어색한 번역문
읽고도 뜻을 알기 어렵거나 평소 쓰지 않는 표현을 짚었습니다.
번역된 문장을 차례로 읽어 내려가다가
"가쵸"라는 표현이 뭔지 모르겠음, "내장을 토할것같다" 표현 어색, "경험의 이불" 표현 알수없음
번역문에 「장난만 치면」이라는 표현이 들어갔을 때
나는 아르르{NL}장난만 치면{NL}절대 용서 안 해 <- 여기서 "장난만 치면"이라는 표현을 한국에서도 쓰나?
문법은 맞는데 읽고도 뜻이 잡히지 않았을 때
손을 뻗자, 물방울이 막대 모양으로 변형 그리고 실체화했다 이거는 사람이 알아보기 너무 힘들어보이는데?
글꼴과 화면 배치
실제 게임 화면에서 크기, 정렬, 글자의 모양을 확인했습니다.
메뉴가 어딘가 어긋나 보였을 때
지금 내가 보니까 "게임하기 / 데이터 삭제 ..." 이 메뉴가, 미묘하게 커서가 아래에 있거든? 정렬이 좀 안맞는듯하고, 조금 더 깔끔한 글꼴을 쓰고싶은데 galmuri14 14px로 한번 해볼래?
글꼴 교체가 의도하지 않은 다른 화면까지 번졌을 때
지금 "저장" "아이템"이 글꼴이 바뀐거지? 이건 기존 글꼴 (neodgm?)을 갔으면 하는데
크기와 여백을 조정한 새 후보를 실제 화면에서 봤을 때
글리프가 좀 맛이 없어졌네. 그냥 롤백하는게 나을듯
레벨업 글자가 원본 배경 위에서 획이 묻혔을 때
만든게 전반적으로 윤곽선 개념 (스프라이트와 유사한 색으로 가독성 나오는) 이 빠졌네. 글꼴 크기는 12-16으로 가자
의성어 「짝」의 첫 후보가 화면에 올라갔을 때
사실 지금 문제가 "짝"이 짝처럼 안보이거든. ㅉ 글자가 그냥 붙어서 거의 그래픽 글리치 덩어리처럼 보이는 수준이라서. 짝은 사이즈 더 키워야할듯 (애초에 일본어로도 2글자였고)
화면 요소의 교체와 보존
의성어의 움직임이나 장식의 역할을 보고 바꿀 범위를 골랐습니다.
대사 데이터가 아니라 그림으로 그려진 일본어 의성어 「ガッ」를 만났을 때
덥석으로 하자. 우선은 분석을 해둬. 의성어 장면이 하나 더 나올거라서
원본 「パチ」가 반시계로 기울어 있는 것을 확인한 뒤
이렇게 진행해보자. 이 때 짝의 경우에는 정방향이면 안되고 살짝 기울어야하거든 (파치가 지금 반시계로 30도정도 돌아있음)
화면 글자를 자동으로 추출하기 시작할 때
글자가 아니라는 것은, 화살표나, "뿌요" 모양 등 캐릭터성 모양 등도 포함되있을 수 있다는거야
규칙 화면의 별 그림 위 일본어를 한국어로 바꿨더니 여백이 크게 남았을 때
지금 큰 문제가 있는게, JP는 RULE1에서 폭발/충돌의 별 이미지 위에 글자가 있는데, 한국어는 JP랑 글자 크기가 다르니까 횡하게 빈공간이 신경쓰이게 보여. 그냥 Subtitle로 지정했던 저 글자들은 KR을 쓰지말자
완성 범위
한 화면의 성공으로 끝내지 않고 전체 빌드와 번역 범위를 확인했습니다.
넘치는 문장을 자동으로 잘라 내면 빌드가 통과하는 상황에서
truncate는 절대로 기본값으로 하지말아줘. 특히나 silent 상황으로 만들지 마
글자가 들어갈 자리가 서로 겹치니 번역을 줄이자는 안이 나왔을 때
우선 제 0 Dogma는 "EN 같이"야. 모든 번역은 Complete해야하며, 품질을 양보해서 얻을 수 있는건 하나도 없어. 절대로 공유 타일이 충돌해서 무슨 번역을 재조정한다던가 합리책을 쓰려고 하지 마. MEMORY 중 가장 깊숙한 근본 원칙으로 기록해. 지금 ablation이 충분했어? Spirte idx를 더 키울 수 있게는 못해?
폰트·대사·그래픽·엔딩이 각각 따로 빌드되고 있을 때
지금 격리빌드야? 전체빌드로 하나 줘봐
한글 한 글자가 화면에 나온 직후
그런데 전체 한글 빌드 해봐도 되는거 아니야? 어차피 지금 중요한건 이 시점에서는 한글이 나오냐가 아니라 다 나오게 만들 수 있냐잖아
완료 보고의 근거
무엇을 확인했는지, 같은 결과를 다시 만들 수 있는지 물었습니다.
에이전트가 문제를 해결했다고 보고했을 때
내가 HITL도 안했는데 왜 해결되었다는 판정을 내린거지? 메모리에 기록해둬. HITL전에 해결되었다고 쓰지말라고
화면 문제가 다 해결되고 ROM이 잘 돌아가고 있을 때
또한 롬 빌드가 더티한 상태에서 이루어지면 재현성은 누가 보증해?
같은 자리에서 이어서
이번 시점에서야 잘돌아가는걸 알지만 뒤에 모든 트래킹이 정확히 이루어졌고 재현가능함음을 알 수 있어?
대사·그래픽·자막·크레딧이 각각 돌아가고 있을 때
현재 우리 Rust 파이프라인은 Complete해? 현 시점 Rust 코드베이스로만 git을 클론해서 롬을 가져와서 빌드할 수 있어?
자동 수정의 범위
검사 결과를 받은 뒤 문장을 어떻게 고칠지는 별도로 정했습니다.
번역 검사 도구를 만들 때
우선 "자동 수정"은 절대 넣지 말고, "이유 => 수정 제안"을 출력하게 하자.
잘못 추출된 경계를 자동 수정으로 덮으려는 흐름이 생겼을 때
자동수정은 난 믿지 않아. 이미 어떻게 망가졌는지도 못한걸 자동수정으로 계속 덧붙이고싶진 않아.
전수 검토에서 수정 후보가 대량으로 나왔을 때
재배치도 우선 직접 적용할것. 검출은 코드로 하더라도 번역이 코드로 수정되는건 허가못함. 손질은 우선 대기
자동화 범위를 방법론에 못박을 때
난 자동화가 될때 좋은 부분도 있고 나쁜 부분도 있다고 보거든? 이 스킬의 철학에서부터 결국 가야하는데, 기본적으로 반드시 실패해야만 하는 것인것만 자동으로 되야하고, 선택의 요소는 자동이 되서는 안된다는 철학을 가졌다는것
최근 프롬프트에서도 폰트·그래픽·레이아웃이 8.1%, 증상 보고가 6.9%, 게임 사양 설명이 3.9%를 차지합니다. 합치면 약 다섯 개 중 하나가 화면과 게임 내용을 확인한 이야기입니다.
에이전트의 작업
Agent tasks
이런 피드백을 받은 에이전트는 게임 내부를 조사하고 코드를 수정합니다.
- 게임 파일에서 문장이 어디 있는지 찾고 어떤 형식으로 저장돼 있는지 알아냅니다.
- 한글을 넣을 자리가 있는지, 없으면 어디를 늘릴 수 있는지 조사합니다.
- 바꾼 내용이 원본의 다른 부분을 망가뜨리지 않는지 전수로 검사합니다.
- 실행 중인 게임의 화면과 메모리를 읽어, 넣은 것이 실제로 쓰이는지 확인합니다.
- 같은 원본에서 같은 결과가 다시 나오는지 빌드로 보장합니다.
이 다섯 가지가 어떤 실패를 거쳐 지금 형태가 됐는지는 한글 패치를 만들며 바꾼 작업 방식에 적혀 있습니다.
평소의 작업 시간
Time spent on the work
앞에서는 판단이 필요했던 사례를 골랐습니다. 전체 대화에서 자주 쓴 말은 훨씬 짧습니다. 반년 치를 세면 다음과 같습니다.
| 프롬프트Prompt | 횟수Count |
|---|---|
| 계속 | 111 |
| 진행해봐 | 99 |
| 진행해 | 51 |
| 진행하자 | 45 |
| 그렇게 하자 | 28 |
| 커밋 푸시 | 27 |
| 상태? | 27 |
가장 많이 쓴 계속은 작업 방향을 바꾸는 지시가 아니었습니다. 앞의 서른다섯 사례는 반년에 걸쳐 나왔습니다. 평소에는 보고를 읽고 기다리다가 작업을 이어 가거나 다시 해 보라고 말하는 시간이 많습니다.
시작 전 고려 사항
Getting started
필요한 경험과 태도
- 한글로 하고 싶은 게임이 이미 정해져 있고, 그 게임을 여러 번 해 봤다.
- 화면이 조금 이상할 때 무엇이 이상한지 말로 설명할 수 있다.
- “대충 이 정도면 됐다”에서 멈추는 걸 못 견딘다.
- 몇 달 걸려도 상관없다.
현실적인 기대
- 어떤 게임이든 상관없이 결과물만 빨리 갖고 싶다.
- 번역기를 한 번 돌려 끼워 넣는 수준을 생각하고 있다.
- 번역이나 화면에 관한 최종 판단까지 다른 사람이 맡아 주길 기대한다.
관련 자료
Related resources
해 보기로 했다면 여기서 시작합니다.
- github.com/mcpads — 방법론 스킬과 도구가 공개돼 있습니다.
- 한글 패치를 만들며 바꾼 작업 방식 — 각 판단이 어떤 실패에서 나왔는지의 기록입니다.
용어
- 빌드
- 번역문과 글꼴, 그래픽을 모아 실제로 돌아가는 게임 파일을 만들어 내는 과정.
- 패치
- 원본 게임 파일을 고치는 변경분. 한글 패치는 원본은 그대로 두고 이 변경분만 따로 배포합니다.
- 스킬
- AI 에이전트에게 미리 정해 준 작업 규칙 묶음. 프로젝트마다 되풀이된 판단을 한곳에 모아 둔 것입니다.
- 커밋
- 작업 이력에 남긴 변경 한 묶음. 언제 무엇을 왜 바꿨는지가 여기에 남습니다.