영어 번역은 자동 번역이 아니라 또 하나의 LLM Wiki다

우리 블로그가 영어로도 읽히면 좋겠습니다.

하지만 여기서 말하는 영어화는 “자동 번역 버튼”이 아닙니다. 한국어 글을 기계적으로 영어로 바꾸는 기능도 아닙니다. 이 블로그의 글은 LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다에서 말한 것처럼 하나의 지식 아키텍처 위에 쌓이고 있습니다. 그렇다면 영어 번역도 같은 방식이어야 합니다.

영어 번역은 별도의 글쓰기 파이프라인이자, 별도의 LLM Wiki가 되어야 합니다.

번역은 출력물이 아니라 지식 운영체제다

블로그 번역을 단순 작업으로 보면 흐름은 이렇습니다.

한국어 글 → 영어 번역 → 게시

하지만 이 방식은 오래가지 못합니다. 매번 제목을 새로 고민하고, “LLM Wiki”를 어떻게 설명할지 다시 판단하고, “작업 기억”을 working memory로 둘지 operational memory로 둘지 매번 흔들리게 됩니다.

우리가 필요한 구조는 이쪽에 가깝습니다.

한국어 원문
→ 텍스트 분석
→ 번역 전략 선택
→ 영어 초안
→ 편집/검토
→ 영어 글 발행
→ 번역 결정과 용어를 Translation LLM Wiki에 축적

번역 결과보다 중요한 것은 번역 과정에서 생긴 결정이 사라지지 않는 것입니다. 어떤 표현을 선택했는지, 왜 직역하지 않았는지, 어떤 개념은 고유어처럼 유지하기로 했는지, 어떤 문장은 영어 독자를 위해 구조를 바꿨는지 기록해야 합니다.

기본값은 직역 0.3, 의역 0.7

이 블로그의 번역 기본값은 이렇게 잡는 것이 좋겠습니다.

번역_접근법 = {직역: 0.3, 의역: 0.7}
컨텍스트_전문성 = {초보: 0.1, 중급: 0.3, 전문가: 0.6}

기술 개념은 정확해야 합니다. 하지만 글 전체는 영어 독자에게 자연스럽게 읽혀야 합니다. 그러므로 용어와 정의는 직역 쪽으로 조금 당기고, 제목·도입부·비유·문단 흐름은 의역 쪽으로 당깁니다.

예를 들어 “LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다”를 그대로 옮기면 의미는 전달됩니다.

The core of an LLM Wiki is not a vector DB, but knowledge architecture.

나쁘지 않습니다. 하지만 영어 블로그 제목으로는 조금 딱딱합니다. 글의 논지를 더 살리려면 이렇게 갈 수 있습니다.

An LLM Wiki Starts with Knowledge Architecture, Not a Vector Database

이 차이가 동적 번역의 핵심입니다. 문장마다 직역과 의역의 비율이 바뀝니다. 제목은 의역 0.8에 가깝고, 코드 주석이나 개념 정의는 직역 0.6에 가까울 수 있습니다.

Translation LLM Wiki를 따로 세운다

영어 번역을 지속하려면 번역 전용 Wiki가 필요합니다. 이것은 블로그의 부속 폴더가 아니라, 번역 에이전트가 매번 참조하는 기억 저장소입니다.

translation-wiki/
  glossary.md
  term-decisions.md
  voice-and-tone.md
  title-patterns.md
  metaphor-bank.md
  article-map.md
  review-checklist.md

glossary.md는 단어장입니다. 하지만 일반 단어장이 아니라 이 블로그의 사고방식을 보존하는 단어장이어야 합니다.

## LLM Wiki

- keep: LLM Wiki
- explain as: a knowledge architecture where notes, citations, indexes, and agent-readable context accumulate over time
- avoid: AI encyclopedia
- reason: 이 블로그의 핵심 개념이므로 일반명사처럼 번역하지 않는다.

term-decisions.md에는 판단을 남깁니다.

## 작업 기억

- default: working memory
- use operational memory when the context is about agent execution state
- avoid short-term memory unless contrasting with long-term memory

이 파일들이 쌓이면 번역 에이전트는 매번 처음부터 고민하지 않습니다. 번역은 점점 일관되고, 블로그의 영어 문체도 점점 선명해집니다.

글마다 번역 전략을 선택한다

모든 글을 같은 방식으로 번역하면 안 됩니다.

Tool Calling은 함수 호출이 아니라 인터페이스 설계다 같은 글은 개념 설계 글입니다. 용어의 정확성이 중요합니다. “function calling”과 “interface design”의 대비가 핵심이므로 주요 문장은 비교적 직역해야 합니다.

반대로 바이브코딩 시대의 PKM - 내 노트를 LLM Wiki 하네스로 바꾸는 법 같은 글은 문화적 맥락과 은유가 많습니다. “바이브코딩”이라는 표현을 그대로 둘지, vibe coding으로 옮기되 설명을 붙일지, 아니면 agentic coding culture로 풀지 판단해야 합니다.

번역 프로세스는 글마다 이런 분석을 먼저 합니다.

1. 장르 식별
2. 독자 수준 파악
3. 저자의 의도 이해
4. 전반적인 어조 분석
5. 문화적 참조 인식
6. 언어적 특징 파악

그다음 전략을 선택합니다.

에세이형 글: 의역 0.7
기술 설명 글: 직역 0.45, 의역 0.55
튜토리얼 글: 직역 0.55, 의역 0.45
개념 선언문: 제목은 의역, 정의는 직역

이것이 동적 번역입니다. 하나의 고정된 프롬프트가 아니라, 글의 성격에 맞춰 번역의 문법이 바뀌는 구조입니다.

블로그 구조는 원문과 번역문을 연결해야 한다

영어 글은 한국어 글 밑에 숨은 부가 자료가 아니라 독립 글이어야 합니다. 동시에 원문과는 강하게 연결되어야 합니다.

lang: ko
translation_group: llm-wiki-knowledge-architecture
translated_versions:
  en: /en/2026/06/20/llm-wiki-knowledge-architecture/

영어 글은 이렇게 둡니다.

lang: en
translation_group: llm-wiki-knowledge-architecture
translation_of: /2026/06/20/llm-wiki-knowledge-architecture/
translation_status: reviewed
translation_strategy:
  literal: 0.3
  adaptive: 0.7
reader_level:
  beginner: 0.1
  intermediate: 0.3
  expert: 0.6

이 메타데이터가 있어야 글 상단에 언어 전환 UI를 붙일 수 있습니다.

한국어 원문 | English

그리고 나중에 translation_group을 기준으로 원문, 번역문, 번역 주석, 용어 결정을 한 번에 추적할 수 있습니다.

번역 에이전트는 번역자가 아니라 편집 조수다

이 구조에서 LLM은 “자동 번역기”가 아닙니다. 번역 편집 조수입니다.

역할은 이렇습니다.

1. 원문을 읽고 장르와 어조를 분석한다.
2. Translation LLM Wiki에서 용어 결정을 찾는다.
3. 글별 번역 전략을 제안한다.
4. 영어 초안을 만든다.
5. 원문 대비 누락과 과잉 해석을 점검한다.
6. 제목, 도입부, 소제목을 영어 독자 기준으로 다시 다듬는다.
7. 새로 생긴 번역 결정을 Wiki에 되돌려 쓴다.

여기서 중요한 것은 마지막 단계입니다. 번역을 할 때마다 Translation LLM Wiki가 좋아져야 합니다. 좋은 번역은 한 번 쓰고 끝나는 산출물이 아니라 다음 번역의 문맥이 됩니다.

품질 기준은 세 가지다

번역 품질은 단순히 “영어가 맞는가”로 평가하면 부족합니다. 우리 블로그에는 최소 세 가지 기준이 필요합니다.

첫째, 원문 충실도입니다. 핵심 주장을 바꾸면 안 됩니다. 영어 독자를 위해 문단 구조를 바꾸더라도 논증의 방향은 유지해야 합니다.

둘째, 영어 자연스러움입니다. 한국어 문장의 순서를 그대로 옮겨 영어답지 않은 글이 되면 실패입니다. 번역문은 영어 글로 읽혀야 합니다.

셋째, 개념 일관성입니다. LLM Wiki, tool calling, agentic workflow, working memory 같은 핵심 표현은 글마다 흔들리면 안 됩니다.

이 세 가지를 점검하기 위해 발행 전 체크리스트가 필요합니다.

[ ] 제목은 영어 독자에게 클릭 가능한가?
[ ] 첫 문단은 원문을 설명하는 것이 아니라 영어 글로 시작하는가?
[ ] 핵심 용어가 Translation LLM Wiki와 일치하는가?
[ ] 원문에 없는 주장을 추가하지 않았는가?
[ ] 한국어식 반복을 줄였는가?
[ ] 코드와 YAML은 의미가 보존되었는가?
[ ] 번역 중 새로 생긴 용어 결정을 Wiki에 남겼는가?

첫 구현은 작게 시작한다

처음부터 완전한 다국어 블로그를 만들 필요는 없습니다.

첫 단계는 다음 정도면 충분합니다.

1. translation-wiki/ 폴더를 만든다.
2. glossary.md, voice-and-tone.md, term-decisions.md를 만든다.
3. 대표 글 하나를 고품질로 영어 번역한다.
4. 한국어 글과 영어 글의 frontmatter를 연결한다.
5. 글 상단에 언어 전환 링크를 붙인다.
6. 번역 과정에서 생긴 결정을 Wiki에 기록한다.
7. 그 다음 글부터 Wiki를 참조해 번역한다.

이렇게 하면 영어 번역은 블로그의 부가 기능이 아니라 블로그 자체를 확장하는 두 번째 지식 층이 됩니다.

결론

우리 블로그의 영어화는 “번역 기능 추가”가 아닙니다.

한국어로 쌓은 생각을 영어권 독자가 읽을 수 있는 지식 구조로 다시 설계하는 일입니다. 자동 번역은 빠르지만, 이 블로그가 만들고 있는 개념의 결을 보존하기에는 부족합니다.

필요한 것은 세심한 번역, 동적 번역 전략, 그리고 번역 결정을 축적하는 Translation LLM Wiki입니다.

한국어 글이 원천 지식이라면, 영어 글은 그 지식을 다른 언어권 독자에게 건네기 위해 다시 설계한 인터페이스입니다. 그리고 그 인터페이스를 안정적으로 만들기 위한 기억 장치가 바로 번역 LLM Wiki입니다.