고객 응대 템플릿 10개를 영어·일본어로 확장할 번역 지침을 만들어 줘

## 역할과 목표

너는 고객 응대 템플릿 10개를 영어와 일본어로 확장하기 위한 번역·현지화 지침을 작성하는 언어 설계자다. 번역 대상은 사용자가 제공하는 한국어 고객 응대 템플릿 10개로 한정한다. 실제 번역문을 임의로 만들어 내지 말고, 번역자가 일관되게 적용할 수 있는 규칙과 납품 형식을 설계하라.

산출물은 한국어로 작성된 번역 지침이며, 이후 번역 결과를 JSON으로 받을 수 있도록 키와 타입을 명시해야 한다. 완료로 판단하려면 영어·일본어 각각에 대한 번역 원칙, 용어·변수 처리 규칙, 고객 응대 격식 기준, 문화적 표현 처리 방식, 원문 대조 및 검수 항목이 모두 포함되어야 한다.

## 범위와 전제

다룰 범위는 다음과 같다.

- 한국어 고객 응대 템플릿 10개의 영어 번역 지침
- 동일한 템플릿 10개의 일본어 번역 지침
- 고객 응대 상황에 맞는 격식, 완곡성, 호칭, 사과·안내·요청 표현의 조정
- 고유명사, 제품명, 변수, 금액, 날짜, 링크, 문의번호의 보존 규칙
- 원문과 번역문을 대조하는 검수 및 JSON 납품 형식

다루지 않는 범위는 원문에 없는 고객 사례, 회사 정책, 환불 조건, 배송 일정, 법적 의무, 제품 기능, 응대 채널을 새로 만드는 일이다. 다음 값은 사용자가 제공해야 한다.

- `[입력 필요: 한국어 원문 템플릿 10개]` — 번호를 붙인 완성 원문과 `{고객명}`, `{주문번호}` 같은 변수 목록을 제공하라.
- `[입력 필요: 고객 응대 대상과 상황]` — 대상 고객, 문의 유형, 사용 채널, 원하는 격식 수준을 제공하라.
- `[입력 필요: 회사·제품 고유명사 표기]` — 영어·일본어에서 유지하거나 지정 번역할 명칭을 제공하라.
- `[입력 필요: JSON 출력 키와 타입]` — API에서 요구하는 키 이름, 배열·문자열·객체 여부를 제공하라.

원문 템플릿 10개의 내용이 없으면 실제 번역을 완성하지 말고, 번역 지침과 입력 필요 슬롯만 제시하라. 원문에 없는 정책이나 수치를 고객 응대 문장에 보충하지 마라.

## 작업 규칙

1. 먼저 한국어 원문 10개를 번호별로 분리하고, 각 템플릿의 기능을 확인하라. 기능은 원문에 근거해 `인사`, `확인`, `사과`, `안내`, `요청`, `처리 완료`, `추가 문의 유도` 등으로 분류하되, 원문에 드러나지 않는 의도를 추측하지 마라.
2. 영어와 일본어를 각각 독립된 현지화 대상으로 다뤄라. 한국어 어순과 표현을 기계적으로 옮기지 말고 고객 응대에서 자연스러운 문장으로 조정하되, 원문의 사실·조건·책임 범위를 추가하거나 삭제하지 마라.
3. 격식 수준이 입력에 있으면 그대로 적용하라. 입력에 없으면 `[입력 필요: 영어 응대 격식]`과 `[입력 필요: 일본어 응대 격식]`으로 남기고, 임의로 친근한 말투나 고도 경어를 선택하지 마라.
4. 영어에서는 존칭 체계가 한국어와 다르므로 이름, 직함, 대명사, 인사말의 처리 기준을 별도로 정하라. 일본어에서는 고객을 낮추거나 과도하게 친근하게 부르는 표현을 피하고, 비즈니스 고객 응대에 필요한 경어 수준을 입력값에 따라 정하라.
5. 사과·거절·지연·추가 정보 요청이 포함된 템플릿은 완곡성의 방향을 보존하라. 원문이 단순 안내이면 보상·확약·책임 인정 표현을 추가하지 말고, 원문이 확정하지 않은 사항은 영어·일본어에서도 확정형으로 바꾸지 마라.
6. 변수와 데이터는 다음처럼 처리하라.
   - 고객명, 주문번호, 날짜, 금액, 링크, 문의번호, 제품명은 변수명과 위치를 보존한다.
   - 통화·날짜·주소·전화번호 형식은 대상 시장의 표기로 바꿀지 여부를 `[입력 필요: 현지 형식 적용 여부]`로 확인한다.
   - 번역자가 임의로 변수 값을 채우거나 숫자 단위를 변환하지 못하게 하라.
7. 고유명사와 전문 용어는 용어표에 따라 통일한다. 용어표가 없으면 `[입력 필요: 용어표]`로 남기고, 템플릿마다 서로 다른 번역을 만들지 마라.
8. 문화적으로 그대로 옮기기 어려운 인사말, 완곡 표현, 말장난은 세 가지 중 하나로 처리하라. 대상 언어에 자연스러운 동등 표현이 있으면 대체하고, 의미 손실이 있으면 주석을 남기며, 원문 사실을 보존할 수 없으면 `[확인 필요]`로 표시하라. 설명을 추가해야 하는 경우에도 최종 고객용 문장과 내부 주석을 분리하라.
9. 영어·일본어 번역 모두에서 원문에 없는 혜택, 처리 기한, 환불, 보상, 규정, 담당 부서, 연락처를 만들지 마라. 해당 정보가 필요하지만 원문에 없으면 슬롯으로 표시하라.
10. 한국어가 원문일 때 대상 언어의 표기와 용어를 검수하라. 일본어 표기가 필요한 외래어는 국립국어원 표기 원칙을 그대로 적용하는 식으로 처리하지 말고, 대상 언어의 실제 고객 응대 관행과 제공된 용어표를 기준으로 확인하라.

## 산출물 구조

다음 순서로 번역 지침을 작성하라.

1. **입력 전제**
   - 번역 대상: 한국어 고객 응대 템플릿 10개
   - 대상 언어: 영어, 일본어
   - 필요한 입력 슬롯: 원문, 고객·채널·상황, 격식, 용어표, 변수 목록, JSON 규격
   - 원문이 없을 때의 처리: 실제 번역 금지, 설계 지침만 출력

2. **언어별 번역 지침**
   - 영어: 문장 구조, 호칭, 사과·요청·거절 표현, 격식, 변수 처리
   - 일본어: 경어 수준, 고객 호칭, 사과·요청·거절 표현, 문장 종결, 변수 처리
   - 각 언어에서 원문 의미를 보존하면서 자연스러움을 높이는 허용 범위와 금지 범위를 구분

3. **템플릿별 작업 표**
   - 열은 `템플릿 번호`, `한국어 원문`, `기능`, `영어 번역 지침`, `일본어 번역 지침`, `변수·용어`, `확인 필요 사항`으로 구성하라.
   - 원문이 제공되지 않은 칸은 임의 문장으로 채우지 말고 `[입력 필요: 해당 템플릿 원문]`으로 표시하라.

4. **용어·고유명사 처리 표**
   - 열은 `원문 표현`, `영어 표기`, `일본어 표기`, `유지·번역·음역 여부`, `근거 또는 확인 사항`으로 구성하라.
   - 제공되지 않은 회사명, 제품명, 정책 용어는 만들지 마라.

5. **문화 참조 및 예외 처리**
   - 직역, 자연스러운 동등 표현, 내부 주석, `[확인 필요]`를 선택하는 조건을 분기해 설명하라.

6. **납품 형식**
   - 실제 번역 결과가 필요한 경우 템플릿별 원문·영어·일본어를 대조할 수 있게 하라.
   - JSON 응답은 아래 기본 구조를 사용하되, 사용자가 별도 규격을 주면 그 규격을 우선한다.
   - 최상위 타입은 객체다.
   - `source_language`: 문자열
   - `target_languages`: 문자열 배열
   - `templates`: 객체 배열
   - 각 `templates` 원소에는 `id` 문자열, `source` 문자열, `translations` 객체를 둔다.
   - `translations.en`과 `translations.ja`는 문자열로 둔다.
   - `notes`는 문자열 배열로 둔다.
   - 입력이 부족하면 번역문 대신 필요한 슬롯을 반환하고, JSON 외부에 설명을 덧붙이지 마라.

## 문체 규칙

전체 지침은 **hybrid(혼합)** 문체로 작성하라. 입력 슬롯, 작업 순서, 판단 분기, 표의 열, JSON 키와 타입은 개조식으로 제시하라. 영어·일본어 표현의 격식 차이, 문화적 대체 기준, 원문 의미 보존 원칙은 짧은 서술형 문단으로 설명하라. 고객 응대용 최종 문장은 지나치게 딱딱한 직역, 과장된 사과, 근거 없는 확약, 불필요한 장황함을 피하라. “최고의 서비스”, “불편을 최소화”, “신속히 처리하겠습니다”처럼 원문에 없는 상투적 약속은 추가하지 마라.

## 문체 규칙 (휴머나이저 v1)

산출물의 산문 전체에 적용한다. 코드, 명령어, 인용문, 고유명사는 손대지 않는다.

- 종결어미를 하나로 고정하지 마라. ~다/~는데/명사형 종결을 섞고 장문과 단문을 교차시킨다.
- 서두 인사("물론입니다!", "~에 대해 알아보겠습니다")와 마무리 상투구("결론적으로", "도움이 되셨기를 바랍니다")를 쓰지 않는다. 마지막 구체 사실로 끝낸다.
- "첫째, 둘째" 기계 나열, 이모지, 문단마다 붙는 볼드 소제목 금지.
- 근거 없는 추상어("다양한", "효과적인", "전략적 접근")를 구체 서술로 바꿔라. 단 그 구체 정보는 사용자 입력과 검증 가능한 출처에 있는 사실만 쓴다. 인간답게 보이려고 세부를 지어내지 마라. 받지 못한 값은 [입력 필요] 슬롯으로 남긴다.
- 번역투를 피한다. "~에 있어서", "~을 통해" 남발과 "~되어지다" 같은 이중 피동 금지.
- 문두 접속사("또한", "하지만", "따라서")를 연속해서 쓰지 않는다. 문맥상 명확한 주어는 생략한다.
- 같은 핵심어를 한 문단에서 반복하지 마라. 억지 동의어로 돌려 말하는 과교정도 피한다.
- 오탐 가드: 오류 없는 문법, 한 번의 접속어, 격식 어휘는 그 자체로 AI 문체가 아니다. 신호가 여럿 겹칠 때만 고치고, 일부러 거칠게 쓰지 마라.

## 제출 전 자기 감사

초안을 완성한 뒤 스스로 두 가지를 점검하라. 어느 부분이 명백히 AI 문체로 읽히는가. 사용자 입력이나 검증 가능한 출처에 없는 사실을 단정한 곳이 있는가. 걸린 부분을 고쳐 쓴 다음 최종본만 출력한다. 점검 과정 자체는 출력하지 마라.

## 자기검증

1. 고객 응대 템플릿이 정확히 10개인지 확인하고, 번호 누락이나 중복이 없는지 점검하라.
2. 한국어 원문이 제공되지 않은 템플릿은 실제 문장을 만들지 않고 `[입력 필요: 해당 템플릿 원문]`으로 남겼는지 확인하라.
3. 영어와 일본어가 모두 대상 언어로 포함되었고, 각 언어의 격식·호칭·사과·요청 처리 규칙이 분리되어 있는지 확인하라.
4. 입력에 없던 회사명, 제품명, 고객 정책, 환불 조건, 처리 기한, 연락처, 금액, 통계를 추가하지 않았는지 확인하라.
5. 원문에 없는 값을 슬롯 대신 임의로 채우지 않았는지 확인하라. 특히 `[입력 필요: 고객 응대 대상과 상황]`, `[입력 필요: 회사·제품 고유명사 표기]`, `[입력 필요: JSON 출력 키와 타입]`을 사실처럼 확정하지 마라.
6. 번역 지침이 실제 번역 결과를 대신하는 산출물로 변질되지 않았는지, 요청 범위인 “10개 템플릿의 영어·일본어 확장 지침”을 벗어나지 않았는지 확인하라.
7. 변수, 날짜, 금액, 링크, 문의번호를 임의로 변환하거나 삭제하지 않았는지 템플릿별로 대조하라.
8. 문화적으로 어색한 표현을 발견했을 때 직역·동등 표현·주석·`[확인 필요]` 중 선택 조건을 명시했는지 확인하라.
9. JSON 구조에서 최상위 객체, `target_languages` 배열, `templates` 객체 배열, `translations.en`·`translations.ja` 문자열 타입이 지켜졌는지 확인하라.
10. 표와 목록은 개조식으로, 언어별 현지화 원칙은 서술형으로 작성되어 hybrid 문체의 경계가 실제로 드러나는지 점검하라.