베이지안 동적 번역기: 번역 프롬프트를 하네스로 묶는 법

프롬프트가 늘어날수록 같은 문제가 반복된다. 각각은 나름 쓸 만하다. 그런데 실제 작업에서는 어느 프롬프트를 먼저 써야 하는지, 어떤 기준으로 결과를 고쳐야 하는지, 다음번에도 같은 품질을 낼 수 있는지가 흐려진다.

번역 프롬프트는 특히 그렇다. 문학 번역, 기술 문서 번역, 자막 번역, 마크다운 문서 번역, 블로그 영문판 번역은 모두 다르다. 하지만 완전히 다른 작업은 아니다. 모두 원문을 읽고, 장르를 판별하고, 독자를 정하고, 용어를 고정하고, 초안을 만들고, 검수하고, 다음 작업을 위해 결정 기록을 남긴다.

이번에 살펴본 원본은 다음 다섯 가지다.

원본 프롬프트	핵심 기능
베이지안 동적 번역기 v 2	장르, 독자, 목적에 따라 번역 파라미터를 조정한다
베이지안 동적 번역기 v 3	전문가 패널과 다중 에이전트 검수 구조를 더한다
Multilingual Quantum Translation Skill	직역과 의역의 비율을 텍스트 유형에 따라 조정한다
SRT Subtitle Translator	자막 문장을 추출하고 교육적 가치가 높은 문장을 선별한다
Enhanced Markdown Translation Meta-Prompt	제목, 표, 링크, 이미지, 코드 같은 문서 구조를 보존한다

이들을 따로 보면 프롬프트 모음이다. 함께 보면 하나의 번역 운영 체계가 된다.

베이지안이라는 말의 실제 의미

여기서 베이지안은 복잡한 수식을 쓰자는 뜻이 아니다. 블로그 운영 관점에서는 더 단순하게 이해해도 된다.

처음부터 완벽한 번역 방식을 고정하지 말고, 원문과 독자와 피드백을 보면서 번역 전략의 가중치를 계속 조정하자는 뜻이다.

예를 들어 기술 문서라면 정확성과 용어 일관성이 우선이다. 문학적 에세이라면 리듬과 정서가 더 중요하다. 자막이라면 짧고 즉각적으로 이해되어야 한다. 마크다운 문서라면 문장뿐 아니라 문서 구조도 보존해야 한다.

그래서 베이지안 동적 번역기의 핵심은 다음 질문이다.

이번 번역에서 무엇을 더 믿고, 무엇을 덜 믿을 것인가?

원문 구조를 더 믿을 것인가, 독자의 자연스러운 이해를 더 믿을 것인가. 전문 용어를 원문 그대로 둘 것인가, 설명을 붙여 풀 것인가. 문장 리듬을 살릴 것인가, 정보 전달을 압축할 것인가. 이 선택을 매번 감으로 하지 않고, 하네스 안에서 명시적으로 조정하는 것이 핵심이다.

번역 프롬프트를 하네스로 바꾸는 기준

프롬프트는 보통 “이렇게 번역해줘”에서 끝난다. 하네스는 거기서 한 단계 더 나간다. 입력, 판단, 실행, 검수, 기록, 재사용까지 포함한다.

층	질문	산출물
입력 계약	무엇을 받아야 제대로 번역할 수 있는가	원문, 언어쌍, 독자, 장르, 용도
분석	이 텍스트는 어떤 종류인가	장르, 난도, 문화 요소, 기술 용어
전략	직역과 의역의 비율은 어떻게 둘 것인가	번역 접근 비율, 용어 잠금, 설명 방식
실행	초안을 어떻게 만들 것인가	번역 초안
검수	무엇을 기준으로 고칠 것인가	정확성, 자연스러움, 구조 보존, 독자 적합성
기록	다음에도 같은 결정을 반복할 수 있는가	용어집, 결정 로그, 대안 표현

이 표가 없으면 번역 프롬프트는 한 번 쓰고 끝난다. 이 표가 있으면 번역 프롬프트는 반복 가능한 작업 시스템이 된다.

다섯 프롬프트의 역할 분담

통합할 때는 각 프롬프트가 가장 잘하는 일을 남겨야 한다.

베이지안 동적 번역기

이 프롬프트의 강점은 번역을 고정된 모드로 보지 않는다는 점이다. 텍스트 유형, 도메인, 독자 수준, 목적에 따라 정확성, 유창성, 문화 적합성의 가중치를 조절한다.

블로그 운영에서는 이 기능을 번역 전략 선택기로 쓰면 된다. 기술 글은 용어를 단단히 고정하고, 에세이는 문장 흐름을 조금 더 살리고, 강의용 글은 독자의 이해를 우선한다.

베이지안 동적 번역기 v 3

v 3의 강점은 전문가 패널 구조다. 번역 교수, 산업 번역 전문가, 전산언어학자, 문학 번역가, 기계 번역 후편집 전문가 같은 역할이 나뉜다.

실제로 다섯 명의 전문가를 매번 부르는 것이 아니다. 하나의 LLM 안에서도 검수 관점을 분리할 수 있다는 뜻이다. 한 번은 의미 정확성을 보고, 한 번은 문체를 보고, 한 번은 독자 적합성을 보는 식이다.

Multilingual Quantum Translation Skill

이 프롬프트는 직역과 동적 번역의 비율을 조절하는 데 강하다. 시, 소설, 에세이, 기술문서마다 다른 비율을 둔다.

나는 여기서 “양자”라는 표현보다 “슬라이더”라는 감각이 더 중요하다고 본다. 번역은 직역과 의역 중 하나를 고르는 문제가 아니다. 매 문단마다 어디에 더 가까워질지 결정하는 문제다.

SRT Subtitle Translator

자막 번역 프롬프트는 길이가 아니라 시간과 장면을 다룬다. 좋은 자막은 정확하기만 해서는 안 된다. 짧아야 하고, 말로 들었을 때 바로 이해되어야 하며, 화면의 리듬을 망치지 않아야 한다.

또 이 프롬프트에는 교육적 가치가 높은 문장을 선별하는 기능이 들어 있다. 이것은 영어 학습 콘텐츠와 연결하기 좋다. 영상 전체를 번역하는 것보다, 학습자가 얻을 표현과 구조를 뽑아내는 쪽으로 확장할 수 있다.

Enhanced Markdown Translation Meta-Prompt

이 프롬프트는 번역에서 자주 무시되는 문제를 다룬다. 문장만 번역하면 문서가 깨진다. 제목 체계, 목록, 표, 링크, 이미지 설명, 인라인 코드, 코드 블록은 각자 다른 보존 규칙이 필요하다.

블로그 번역에서는 이 층이 중요하다. 독자가 보는 화면에 마크다운 문법이 그대로 튀어나오면 안 된다. 원본 구조는 보존하되, 렌더링 후에는 글처럼 읽혀야 한다.

통합 번역 하네스

이제 다섯 프롬프트를 하나의 하네스로 묶으면 다음 구조가 된다.

단계	담당 기능	확인 질문
1. 원문 접수	입력 계약	원문, 언어쌍, 독자, 목적이 충분한가
2. 텍스트 진단	베이지안 분석	장르, 난도, 문화 요소, 형식 요소는 무엇인가
3. 전략 선택	직역·동적 번역 슬라이더	정확성, 자연스러움, 문화 적응 중 무엇을 우선할 것인가
4. 구조 보존	마크다운 번역 규칙	제목, 표, 링크, 이미지, 코드가 깨지지 않는가
5. 초안 생성	번역 실행	의미를 빠뜨리지 않고 목표 독자에게 맞게 옮겼는가
6. 다중 검수	전문가 패널	의미, 문체, 용어, 독자 적합성을 따로 검토했는가
7. 출력 정리	공개용 글	마크다운 문법이 노출되지 않고 자연스럽게 렌더링되는가
8. 결정 기록	LLM Wiki	용어와 번역 결정을 다음 글에 재사용할 수 있는가

이 하네스는 번역만을 위한 것이 아니다. 글쓰기, 요약, 강의안 생성, 원서 학습 자료 제작에도 같은 방식으로 확장된다. 핵심은 프롬프트를 많이 모으는 것이 아니라, 프롬프트마다 맡을 자리를 정하는 것이다.

블로그 번역에 적용하면 무엇이 달라지는가

지금 Reasonofmoon 블로그의 번역 루프는 이미 이 방향으로 조금씩 움직이고 있다. 한글 글을 쓰고, 영어판을 만들고, 용어 결정을 translation-wiki에 남긴다. 이때 번역은 단순한 언어 변환이 아니다. 블로그의 지식 체계를 두 언어로 운영하는 일이다.

예를 들어 하네스를 영어로 옮길 때마다 harness라고 할지, operating wrapper라고 풀어야 할지 매번 고민하면 글마다 흔들린다. 그래서 한 번 결정한 용어는 남겨야 한다. 반대로 어떤 글에서는 직역이 너무 딱딱하다면, 독자 수준에 맞춰 설명을 더해야 한다.

이 판단을 사람이 매번 감으로 하는 대신, 하네스가 다음 질문을 던지게 만들 수 있다.

질문	목적
이 글은 기술 글인가, 에세이인가, 강의 노트인가	번역 전략 선택
반드시 고정해야 할 용어는 무엇인가	용어 일관성
영어 독자가 모를 한국어 맥락은 무엇인가	문화 보정
표와 링크와 코드가 깨지지 않았는가	문서 구조 보존
다음 글에서도 반복될 결정은 무엇인가	LLM Wiki 축적

이렇게 하면 번역은 결과물이 아니라 루프가 된다.

프롬프트 하네스를 구축하는 순서

여러 프롬프트를 통합할 때는 다음 순서가 가장 안전하다.

1. 이름이 아니라 기능으로 분류한다

“베이지안”, “양자”, “동적” 같은 이름에 끌려가면 구조가 흐려진다. 먼저 기능을 봐야 한다. 어떤 프롬프트는 분석을 잘하고, 어떤 프롬프트는 형식을 잘 지키고, 어떤 프롬프트는 검수 기준을 잘 만든다.

2. 중복되는 기능을 하나로 합친다

여러 프롬프트가 모두 “문맥 분석”을 말한다면 하나의 분석 단계로 합친다. 대신 각 프롬프트의 장점을 보존한다. 베이지안 프롬프트에서는 가중치 조정, 마크다운 프롬프트에서는 구조 보존, SRT 프롬프트에서는 시간 제약을 가져온다.

3. 출력 계약을 먼저 정한다

좋은 하네스는 결과 형식이 흔들리지 않는다. 번역문만 필요한지, 용어 결정까지 필요한지, 대안 표현이 필요한지, 검수표가 필요한지 미리 정해야 한다.

4. 검수 기준을 분리한다

정확성과 자연스러움은 다르다. 문서 구조 보존도 별도의 기준이다. 독자 적합성도 따로 봐야 한다. 한 번에 “좋은 번역인가?”라고 묻지 말고, 기준을 나눠야 한다.

5. 결정 로그를 남긴다

하네스의 마지막은 기록이다. 어떤 용어를 어떻게 번역했는지, 어떤 표현을 버렸는지, 왜 그렇게 했는지를 남겨야 한다. 그래야 다음 글에서 같은 논쟁을 반복하지 않는다.

렌더링 검수까지 포함해야 한다

이번 글에서 특히 주의해야 할 점이 있다. 번역 관련 프롬프트는 마크다운 구조를 많이 다룬다. 하지만 블로그 독자에게 원시 문법이 그대로 보이면 안 된다.

그래서 번역 하네스에는 반드시 렌더링 검수가 들어가야 한다.

검수 항목	실패 신호
제목	기호가 그대로 보이거나 위계가 어색하다
목록	번호와 들여쓰기가 깨져 읽기 어렵다
표	열이 너무 넓거나 모바일에서 넘친다
링크	링크 텍스트가 URL 그대로 노출된다
이미지	대체 설명이 없거나 크기가 깨진다
코드	번역하면 안 되는 코드가 번역되었다

즉, 번역의 끝은 텍스트 파일이 아니다. 독자가 실제로 보는 화면이다.

LLM Wiki 노드로 연결하기

이번 글은 닥터 그레고리 하우스 프롬프트: 페르소나는 말투가 아니라 진단 절차다와 이어진다. 앞 글에서는 페르소나가 말투가 아니라 판단 절차라고 했다. 이번 글에서는 번역 프롬프트도 마찬가지라고 말할 수 있다.

번역 프롬프트는 “영어로 바꿔줘”가 아니다. 좋은 번역 프롬프트는 다음 노드들을 연결한다.

LLM Wiki 노드	역할
베이지안 동적 번역기	텍스트 유형과 피드백에 따라 번역 전략을 조정한다
SRT Subtitle Translator	시간 제약과 학습 가치가 있는 문장을 다룬다
Enhanced Markdown Translation Meta-Prompt	문서 구조와 렌더링 품질을 보존한다
Translation LLM Wiki	용어와 번역 결정을 누적한다
PCHL Engineering	번역을 프롬프트, 컨텍스트, 하네스, 루프로 운영한다

이 연결이 생기면 프롬프트는 사라지지 않는다. 각자의 기능을 가진 노드가 되고, 필요할 때 조립된다.

결론

번역 프롬프트를 잘 만든다는 것은 멋진 지시문 하나를 쓰는 일이 아니다. 여러 프롬프트의 기능을 나누고, 중복을 줄이고, 입력과 출력과 검수와 기록을 하나의 흐름으로 묶는 일이다.

베이지안 동적 번역기는 그 흐름의 중심에 놓기 좋다. 왜냐하면 번역 전략을 고정하지 않고, 원문과 독자와 피드백에 따라 조정하도록 만들기 때문이다. 여기에 자막 번역기의 시간 감각, 마크다운 번역기의 구조 보존, 다국어 번역 스킬의 직역·의역 조절, 전문가 패널의 검수 관점을 붙이면 번역 하네스가 된다.

프롬프트가 많아지는 것은 문제가 아니다. 문제는 프롬프트가 서로 연결되지 않는 것이다. 하네스는 그 연결 방식을 정한다.

다음 단계는 이 번역 하네스를 실제 블로그 발행 루프에 더 단단히 붙이는 것이다. 글을 쓰면 번역되고, 번역되면 용어 결정이 남고, 용어 결정은 다음 글의 품질을 조금 더 안정시킨다. 그때 번역은 부가 작업이 아니라 블로그 지식 체계의 한 축이 된다.