# 번역투와 상투 표현 편집 기준 이 문서는 오류 목록이 아니라 점검 목록이다. 표현 하나만 보고 고치지 않는다. 반복 여부, 문맥, 장르, 의미 변화 가능성을 함께 본다. ## 판단 순서 1. 문법적으로 틀린가? 2. 뜻이 모호하거나 사실관계가 달라지는가? 3. 원래 문맥보다 불필요하게 장황한가? 4. 영어·일본어 구조를 따라 한국어 동작과 관계가 흐려졌는가? 5. 글 전체에서 같은 패턴이 반복되는가? 6. 더 자연스러운 표현으로 바꿔도 정보 손실이 없는가? 1~2번이면 교정하고, 3~6번은 장르와 작성자 목소리를 고려해 윤문한다. ## 1. 소유 구문과 `가지다` ### 점검 대상 - 높은 확장성을 가지고 있다 - 아름다운 목소리를 가지고 있다 - 문제 해결 능력을 가지고 있다 - 세 개의 서버를 가지고 있다 ### 편집 방법 실제 의미가 속성인지, 소유인지, 구성인지, 동작인지 찾는다. - 높은 확장성을 가지고 있다 → 확장성이 높다 - 아름다운 목소리를 가지고 있다 → 목소리가 아름답다 - 문제 해결 능력을 가지고 있다 → 문제를 해결할 수 있다 / 문제 해결 능력이 있다 - 세 개의 서버를 가지고 있다 → 서버 세 대를 운영한다 / 보유한다 ### 유지할 때 실제 소유, 보유, 자격, 관계를 뜻하고 `가지다`가 문맥에 자연스러우면 유지한다. ## 2. 피동과 `~에 의해` ### 점검 대상 - 시스템에 의해 자동으로 생성된다 - 담당자에 의해 검토되었다 - 변경이 적용되어진다 - 노력이 기울여졌다 ### 편집 방법 행위자가 중요하고 분명하면 능동문으로 바꾼다. - 시스템에 의해 자동으로 생성된다 → 시스템이 자동으로 생성한다 - 담당자에 의해 검토되었다 → 담당자가 검토했다 - 변경이 적용되어진다 → 변경이 적용된다 - 노력이 기울여졌다 → 노력했다 / 노력이 들어갔다 ### 유지할 때 행위자가 중요하지 않거나 알 수 없고 결과 상태가 중심이면 자연스러운 피동문을 유지한다. - 계정이 잠겼습니다. - 데이터가 삭제되었습니다. - 요청이 거부되었습니다. 피동문을 모두 능동문으로 바꾸지 않는다. 행위자를 새로 만들어 넣지도 않는다. ## 3. 전치사구 직역 ### 점검 대상과 대안 | 점검 표현 | 가능한 대안 | |---|---| | `~로부터` | `~에게서`, `~에서`, 문장 구조 변경 | | `~에 의해` | `~이/가`, `~으로`, 자연스러운 피동 | | `~를 통해` | `~로`, `~에서`, `~하면서`, 실제 동작 | | `~에 대한` | 목적격 조사, 관형절, 직접 서술 | | `~에 있어서` | `~에서`, `~할 때`, 삭제 | | `~에서의` | 동사나 관형절로 풀어 씀 | | `~으로의` | 이동·변화 동사를 직접 씀 | 예: - 이번 기회를 통해 개선안을 공유한다 → 이번 기회에 개선안을 공유한다 - 인증에 대한 검증을 수행한다 → 인증을 검증한다 - 운영 환경에서의 장애 대응 → 운영 환경에서 장애에 대응하는 방법 - 새 구조로의 전환 → 새 구조로 전환 ### 유지할 때 수단, 경로, 대상이라는 의미를 정확히 구분해야 하고 해당 표현이 가장 분명하면 유지한다. - 프록시를 통해서만 외부에 접속한다. - 설문을 통해 의견을 수집했다. - 장애에 대한 책임 범위를 정한다. ## 4. 대명사와 주어 반복 ### 점검 대상 - 그는 서버를 확인했다. 그는 로그를 읽었다. 그는 원인을 찾았다. - 이것은 중요한 문제다. 이것은 배포를 막는다. - 사용자는 버튼을 누른다. 사용자는 다음 화면으로 이동한다. ### 편집 방법 문맥상 주체가 유지되면 생략하거나 문장을 합친다. - 서버를 확인하고 로그를 읽어 원인을 찾았다. - 이 문제 때문에 배포할 수 없다. - 버튼을 누르면 다음 화면으로 이동한다. ### 유지할 때 주체가 바뀌거나 책임 주체를 분명히 해야 하는 기술·법률 문서에서는 주어를 유지한다. ## 5. 불필요한 복수 표시 ### 점검 대상 - 여러 기능들 - 다양한 사용자들 - 새로운 아이디어들과 방법들 - 서버들의 상태 ### 편집 방법 수량이 이미 드러나거나 집합 의미가 분명하면 `들`을 줄인다. - 여러 기능 - 다양한 사용자 - 새로운 아이디어와 방법 - 각 서버의 상태 / 서버 상태 ### 유지할 때 개별 구성원이나 종류의 다양성을 특별히 강조할 때는 유지할 수 있다. ## 6. `의`의 연쇄 ### 점검 대상 - 시스템의 장애의 원인의 분석 - 사용자의 요청의 처리 상태 - 운영 환경의 데이터의 보존 정책 ### 편집 방법 명사 관계를 동사나 조사로 풀어 쓴다. - 시스템 장애 원인 분석 - 사용자 요청 처리 상태 - 운영 데이터 보존 정책 - 시스템에 장애가 난 원인을 분석한다 명사를 무조건 붙여 쓰지 않는다. 관계가 모호하면 문장으로 푼다. ## 7. 명사화와 관공서식 표현 ### 점검 대상 - 검토를 진행한다 - 적용을 수행한다 - 확인이 필요하다 - 개선의 추진을 실시한다 - 문제의 해결을 위한 방안의 마련 ### 편집 방법 실제 동작을 하는 동사로 바꾼다. - 검토한다 - 적용한다 - 확인해야 한다 / 확인할 필요가 있다 - 개선을 추진한다 - 문제를 해결할 방안을 마련한다 `진행하다`, `수행하다`, `실시하다`가 업무 단계나 책임 범위를 구분하는 데 필요하면 유지한다. ## 8. 과도한 명시적 접속 ### 점검 대상 - 그러나, 하지만, 반면에가 연속됨 - 매 문장이 `따라서`, `또한`, `즉`으로 시작함 - 인과가 분명한데 `왜냐하면`을 반복함 - 조건문마다 `만약`을 붙임 ### 편집 방법 문맥으로 관계가 드러나면 접속어를 생략한다. 필요한 경우 관계에 맞는 어미와 문장 순서를 쓴다. - 만약 서버가 종료된다면 요청은 실패한다 → 서버가 종료되면 요청은 실패한다 - 오류가 발생했다. 따라서 배포를 중단했다 → 오류가 발생해 배포를 중단했다 - 그러나 이 방식에는 문제가 있다 → 이 방식에도 문제가 있다 / 문맥상 필요하면 유지 접속어를 없애 문장 관계가 모호해지면 유지한다. ## 9. 긴 관형절과 뒤늦은 서술어 ### 점검 대상 > 운영 환경에서 대량의 요청이 동시에 유입될 때 데이터베이스 연결 수가 급격히 증가하면서 발생할 수 있는 장애를 방지하기 위해 적용한 설정을 설명한다. ### 편집 방법 행위와 목적을 나눈다. > 운영 환경에서는 요청이 한꺼번에 들어오면 데이터베이스 연결 수가 급격히 늘 수 있다. 이 장애를 막기 위해 적용한 설정을 설명한다. 긴 문장이 전문적이라는 이유로 유지하지 않는다. 다만 법률 조항이나 정확한 조건식처럼 한 문장 안의 결합이 의미상 중요하면 함부로 나누지 않는다. ## 10. 형식 명사와 완곡 표현 ### 점검 대상 - ~하는 것이 중요하다 - ~할 수 있다 - ~할 필요가 있다 - ~라는 점을 확인할 수 있다 - ~일 것으로 보인다 ### 편집 방법 실제 판단 강도에 맞게 직접 쓴다. - 로그를 확인하는 것이 중요하다 → 먼저 로그를 확인한다 / 로그를 확인해야 한다 - 성능을 개선할 수 있다 → 성능이 개선된다 / 개선 가능성이 있다 - 검토할 필요가 있다 → 검토해야 한다 / 검토한다 - 실패했다는 점을 확인할 수 있다 → 실패했다 가능성, 의무, 불확실성이 실제 의미라면 유지한다. 직접적인 표현으로 바꾸면서 확신을 높이지 않는다. ## 11. `단순히 A를 넘어 B`와 대비 공식 ### 점검 대상 - 단순한 도구를 넘어 핵심 플랫폼이다 - 단순히 속도뿐만 아니라 안정성도 제공한다 - A가 아니라 B다 ### 문제 대비가 실제 논리를 설명하지 않고 대상을 과장하는 데 쓰이면 문장만 커지고 정보는 늘지 않는다. ### 편집 방법 A와 B가 무엇인지 실제 기능이나 차이로 쓴다. - 단순한 캐시를 넘어 핵심 플랫폼이다 → 캐시 외에도 세션 저장과 요청 제한에 사용한다 - 속도뿐만 아니라 안정성도 제공한다 → 조회 시간을 줄이고 데이터베이스 장애 시 읽기 요청 일부를 유지한다 대비 자체가 논증에 필요하면 유지한다. ## 12. 추상적인 가치 선언 ### 점검 대상 - 중요한 역할을 한다 - 혁신적인 변화를 가져온다 - 효율성을 극대화한다 - 강력한 기능을 제공한다 - 다양한 이점을 제공한다 ### 편집 방법 측정 가능한 변화, 구체적인 동작, 적용 범위를 쓴다. - 중요한 역할을 한다 → 인증 요청을 검증하고 사용자 세션을 만든다 - 효율성을 높인다 → 중복 조회를 줄여 데이터베이스 요청 수를 낮춘다 - 다양한 기능을 제공한다 → 백업, 복원, 만료 정책을 지원한다 근거가 없으면 삭제한다. 광고나 홍보 글에서 의도적으로 가치 표현을 쓰더라도 사실로 뒷받침한다. ## 13. 강제된 삼단 구성 ### 점검 대상 - 내용상 두 항목인데 세 항목으로 늘림 - 모든 문단을 `첫째, 둘째, 셋째`로 구성 - 결론을 세 문장으로 대칭적으로 마무리 ### 편집 방법 실제 논리 단위만 남긴다. 두 개면 두 개, 네 개면 네 개를 쓴다. 순서가 중요하지 않으면 번호 대신 문단이나 표를 쓴다. ## 14. 반복되는 문단 결론 ### 점검 대상 각 문단이 다음과 같은 문장으로 끝남. - 이를 통해 안정성을 확보할 수 있다. - 이는 매우 중요한 의미를 가진다. - 결과적으로 효율적인 운영이 가능하다. ### 편집 방법 앞 문장의 내용을 되풀이하면 삭제한다. 독자에게 필요한 다음 판단, 예외, 조건이 있으면 그것을 쓴다. ## 15. 문장 리듬의 기계적 반복 ### 점검 대상 - 모든 문장이 비슷한 길이 - 모든 문장이 `~합니다`로 끝남 - 매 문단이 정의 → 장점 → 요약 순서 - 짧은 문장을 의도 없이 연속해 단절감이 큼 ### 편집 방법 내용 관계에 따라 문장을 합치거나 나눈다. 문장 길이를 일부러 무작위로 만들지 않는다. 같은 종결어미가 자연스러운 공식 문서에서는 억지로 변형하지 않는다. ## 16. 과도한 제목·목록·강조 ### 점검 대상 - 두 문장마다 소제목 - 설명할 내용을 전부 불릿으로 분해 - 거의 모든 문장에 굵은 글씨 - 결론 한 줄을 여러 번 박스 처리 ### 편집 방법 정보 구조가 바뀌는 곳에만 제목을 둔다. 병렬 항목은 목록, 인과와 설명은 문단으로 쓴다. 강조는 독자가 놓치면 안 되는 소수의 정보에만 사용한다. ## 17. 사용자 목소리 훼손 ### 점검 대상 - 편한 메시지를 공식 보고서 문체로 변경 - 사용자의 직설적인 판단을 과도하게 완곡하게 변경 - 기술자가 쓰던 실제 용어를 일반적인 홍보 용어로 교체 - 원문의 의문과 망설임을 확정적인 결론으로 변경 ### 편집 방법 원문의 높임 수준, 단어 선택, 확신 정도를 먼저 파악한다. 규범 오류와 이해를 막는 부분만 고친 뒤, 장르에 필요한 수준에서만 조정한다. ## 18. 과윤문 방지 다음 조건이면 원문을 유지하거나 최소한만 고친다. - 규범상 맞고 문맥에서도 자연스럽다. - 사용자의 개성이 드러나는 표현이며 이해에 문제가 없다. - 짧고 직접적인 문장을 더 세련되게 보이려고 길게 만들게 된다. - 기술적 의미가 미세하게 달라질 수 있다. - 인용, 법률 문구, 표준 명칭, 코드와 맞닿아 있다. - 구어체나 발표 대본에서 의도한 호흡이다. 좋은 윤문은 문장을 전부 바꾸는 작업이 아니다. 바꿀 이유가 없는 문장은 남긴다.