05화. 데이터 포맷팅 실전. 오류 없는 CSV 구성

부제: 실무용 구글 시트 템플릿 제공 및 검증 규칙

Dec 19. 2025 brunch_membership's

1. 5분 투자 vs 3시간 낭비

4화에서 우리는 글로서리의 구조를 배웠습니다. IDX, Keyword, Type, Gender, 언어 컬럼들, Description, Directive. 7개의 필수 컬럼입니다. 이제 이 구조를 실제 구글 시트에 구현할 차례입니다.

많은 사람들이 "드롭다운 메뉴 만드는 게 귀찮다"고 말합니다. 직접 타이핑하면 안 되냐고 묻습니다. 물론 됩니다. 진짜입니다.

그럼에도 불구하고 드롭다운을 권하는 것은 처음 10개 키워드를 입력할 때까지는 아무 문제가 없습니다. 하지만 100개째 키워드를 입력하고 있을 때, 문제가 발생합니다. 27번째 행에 "Proper Nun"이라고 오타를 냈다는 것을 뒤늦게 발견합니다. AI는 이것을 "Proper Noun(고유명사)"으로 인식하지 못했고, 해당 단어는 글로서리 정책을 적용받지 못한 채 확률적으로 번역되었습니다. 이제 100개 행을 일일이 검수하며 오타를 찾아야 합니다. 3시간이 걸립니다.

드롭다운 메뉴를 만드는 데는 5분이 걸립니다.

데이터 입력 실수는 생각보다 심각한 결과를 만듭니다. 쉼표 하나가 잘못 배치되면 전체 컬럼이 뒤섞입니다. 인코딩이 UTF-8이 아닌 ANSI로 저장되면 한글이 전부 "??????"로 깨집니다. Type 컬럼에 오타가 있으면 AI는 그 단어를 제멋대로 해석합니다.

GIGO. Garbage In, Garbage Out. 쓰레기를 넣으면 쓰레기가 나옵니다. 제아무리 뛰어난 Gemini나 Claude도 엉망인 데이터를 받으면 엉망인 번역을 내놓습니다. 오늘 우리는 AI가 절대 오해할 수 없는, 사람도 실수할 수 없는 '강철 템플릿'을 만듭니다. 무엇보다 사람이 이런걸 하면서 하나씩 배워가는 것도 중요합니다.

2. 구글 시트 템플릿 설계: UI/UX 관점

4화에서 배운 구조를 단순히 열로 나열하면 될까요? 아닙니다. 템플릿 설계는 UI/UX입니다. 작업자가 데이터를 입력할 때 최소한의 인지 부하로, 최대한의 정확도를 달성하도록 만드는 것입니다. 엑셀이 아니라 도구입니다. 도구는 사용하는 사람을 배려해야 합니다.

틀 고정: 항상 보이는 나침반

데이터가 10개일 때는 문제없습니다. 하지만 100개, 500개, 1,000개로 늘어나면 스크롤을 내릴 때 헤더가 사라집니다. "이 컬럼이 뭐였지?" 위로 올라가서 확인하고 다시 내려옵니다. 이것을 100번 반복합니다.

구글 시트에는 '틀 고정' 기능이 있습니다. 보기 > 틀 고정 > 행 1개 및 열 2개. 이렇게 설정하면 첫 번째 행(헤더)과 처음 두 열(IDX, Keyword)이 항상 화면에 고정됩니다. 아무리 아래로 스크롤해도, 오른쪽으로 스크롤해도 나침반은 항상 보입니다. 길을 잃지 않게 만드십시오.

색상 코딩: 시각적 가이드

사람은 색으로 사고합니다. 흰색과 회색과 노란색이 섞여 있으면, 뇌는 자동으로 "이것은 다르다"고 인식합니다.

회색 (#F0F0F0) - 메타데이터 영역 (Type, Gender): 직접 타이핑하지 않고 선택만 하는 곳입니다. "건드리지 말고 선택하라"는 뜻입니다.

흰색 - 입력 영역 (Keyword, Description, Directive): 자유롭게 입력하는 곳입니다. 여러분의 창의성이 발휘됩니다.

옅은 노란색 (#FFFACD) - 출력 영역 (언어 컬럼들): AI가 채울 곳입니다. 지금은 비워둡니다. 나중에 필요한 언어만 AI가 채워줄 것입니다.

가독성 최적화

글꼴은 Noto Sans를 권장합니다. 한글과 영어 모두 깔끔하게 보이는 산세리프 서체입니다. 줄바꿈 설정을 해야 합니다(서식 > 줄바꿈 > 줄바꿈). Description이나 Directive는 문장이 길어질 수 있는데, 줄바꿈 설정을 하지 않으면 셀에서 내용이 잘려서 안 보입니다. 보이지 않는 데이터는 없는 데이터나 마찬가지입니다.

3. 컬럼 배치 순서의 논리

4화에서는 7개 컬럼을 배웠지만, 실제로는 8개입니다. Type을 두 개로 나눴기 때문입니다.

IDX, Keyword, Type_Grammar, Type_Semantic, Gender, Description, Directive, ko, en, ja,

왜 이 순서일까요?

작업 흐름을 따릅니다. 왼쪽부터 설명하겠습니다. IDX와 Keyword는 가장 자주 참조하는 정보이므로 맨 왼쪽에 두고 고정합니다. 그 다음 Type과 Gender는 단어의 성격을 정의하는 메타데이터입니다.

Description과 Directive입니다. 이것은 AI에게 주는 컨텍스트이자 조리법입니다.

그 다음은 언어 코드입니다. ko, en, ja, es... 필요한만큼의 39개 언어 컬럼이 오른쪽으로 쭉 이어집니다.

업계 사례로 보는 신뢰성

넷플릭스는 드라마를 번역하기 전에 KNP(Key Names and Phrases)라는 리스트를 먼저 확정합니다. 주요 인명, 지명, 핵심 대사를 정리한 문서입니다. 우리의 Glossary 시트가 바로 이 역할을 합니다. "번역하기 전에 명사부터 확정한다"는 것은 글로벌 표준입니다.

게임 업계에서는 모든 텍스트에 고유 ID를 부여합니다. 우리의 IDX 컬럼이 이것입니다. 데이터가 뒤섞여도 ID만 있으면 원래 위치로 복구할 수 있습니다.

우리는 수백만 원짜리 전문 툴(Trados, MemoQ) 대신 구글 시트를 씁니다. 하지만 그 안에 담긴 철학은 똑같습니다.

39개 언어? 실제로는 3~5개면 충분

여기서 중요한 사실 하나. 컬럼은 39개를 만들어두지만, 실제로 채우는 것은 여러분이 필요한 언어만입니다.

대부분의 프로젝트는 이렇게 시작합니다. 한글(ko) - 필수. 영어(en) - 필수, 글로벌 Pivot 언어. 일본어(ja) - 선택, 문법 구조가 한국어와 유사해 번역 효율이 높고, 한자 표기로 중국어 등 한자문화권 확장 시 참고 가능. 총 3개 언어입니다.

나머지 36개 언어 컬럼은 미래를 위한 여유 공간입니다. 작품이 성공해서 스페인어판이 필요하면 그때 es 컬럼을 채우면 됩니다. 프랑스어판이 필요하면 fr 컬럼을 채우면 됩니다.

처음부터 39개를 채우려고 하지 마십시오. 그것은 시간 낭비입니다. 필요한 언어만 채우고, 나머지는 빈칸으로 남겨둡니다.

원칙: 컬럼은 확장성을 위해 많이 만들되, 실제 작업은 필요한 만큼만.

4. Type의 이중 분류 체계

4화에서 배운 Type은 실제로 두 개로 나뉩니다.

Type_Grammar (문법적 타입): AI에게 "이 단어를 문법적으로 어떻게 다룰지" 알려줍니다. Proper Noun(고유명사), Common Noun(일반명사), Verb(동사), Adjective(형용사), Phrase(구문). 대소문자 표기와 관사 사용을 결정합니다.

Type_Semantic (의미적 타입): AI에게 "이 단어가 의미적으로 무엇인지" 알려줍니다. MEJE Works는 4대 기본 분류를 사용합니다. 인물(Person), 사건(Event), 사물(Object), 장소(Location). 그리고 각 분류 아래 세부 분류가 있습니다. 인물이라면 캐릭터인지, 집단인지, 직업인지. 사물이라면 아이템인지, 기술인지, 능력인지. 장소라면 시설인지, 자연인지, 지역인지.

왜 이렇게 복잡하게 나누냐고요? 같은 단어라도 문맥에 따라 의미가 달라지기 때문입니다.

"학교"라는 단어를 봅시다. 이것은 최소 4가지 의미를 가집니다.

학교 (장소) - "학교에 갔다" -> 물리적 위치 (Type: 장소 > 시설) -> School

학교 (집단) - "학교가 징계했다" -> 구성원 전체 (Type: 인물 > 집단) -> The Administration

이 구분이 없으면 AI는 "The school building disciplined him(학교 건물이 그를 징계했다)" 같은 엉뚱한 번역을 내놓습니다. 마이크로소프트가 'Save'를 '저장'과 '구조'로 구분하는 이유도 바로 이 의미적 타입 때문입니다.

Before & After를 봅시다.

변경 전: "애플을 먹었다" -> Type_Grammar 없음 -> AI: "Apple... 회사? 과일?" -> 결과: "He ate Apple" (관사 누락, 대문자)

변경 후: Type_Grammar: Common Noun -> 결과: "He ate an apple" = O

또 다른 예시입니다.

변경 전: "학교가 그를 징계했다" -> Type_Semantic 없음 -> AI: "학교가... building이 사람을 징계?" -> 결과: "The school building disciplined him" (어색함)

변경 후: Type_Semantic: 인물 > 집단 -> AI: "아, 집단 의미구나" -> 결과: "The school administration disciplined him" = O

Directive의 문화적·정치적 역할

Directive는 단순히 "음역하라", "의역하라"만 지시하는 것이 아닙니다. 때로는 문화적, 정치적 선택을 강제해야 할 때도 있습니다.

예를 들어 "라면"을 영어로 번역한다고 가정합시다. 과거에는 모두 'Ramen'(일본식 표기)으로 통칭되었습니다. 하지만 K-콘텐츠의 부상으로 한국식 매운 라면을 'Ramyun'으로 독자 표기하는 것이 국제 표준이 되어가고 있습니다. 이것은 단순한 철자 문제가 아닙니다. 문화적 정체성의 문제입니다.

더 민감한 경우도 있습니다. 우크라이나 수도를 'Kiev'(러시아어 발음)로 쓸 것인가, 'Kyiv'(우크라이나어 발음)로 쓸 것인가? 한국과 일본 사이 바다를 'East Sea'로 쓸 것인가 'Sea of Japan'으로 쓸 것인가? 이것은 지정학적 입장 표명입니다.