왜 문제였나 — 밖으로 나가는 한국어에 번역체가 섞여 나왔다
SGK 스튜디오는 AI 에이전트에게 문서 작성을 맡기고 그 결과를 고객과 거래처에 그대로 내보낸다. 제안서, 견적서, 블로그 글, 답변 메일처럼 회사 밖 사람이 읽는 문서 전부가 여기 해당한다. 문제는 이 문서 속 문장에 번역체(직역 문형)가 섞여 나온다는 데 있었다. 문장 구조 자체가 영어 문형을 그대로 옮긴 형태였고, 한국어를 쓰는 사람이 읽으면 어딘가 어색했다.
예를 들어 '경험을 가지고 있습니다'나 '승인을 필요로 합니다' 같은 문장은 문법은 틀리지 않았지만, 한국어를 모국어로 쓰는 사람은 이렇게 말하지 않는다. '경험이 있습니다', '승인이 필요합니다'라고 쓴다. 이런 문형이 낱개로 한두 번 섞이면 눈에 안 띄지만, 여러 번 쌓이면 문서 전체가 번역기로 돌린 글처럼 읽힌다.
발단은 회사를 운영하는 사람의 지적이었다. 산출물에 직역 용어와 문장이 그대로 섞여 밖으로 나갈 때 곤란하다는 지적이었고, 다만 에이전트와 회사 안에서 주고받는 대화까지 문체를 따질 필요는 없다는 단서가 붙었다. 문제로 삼을 자리는 밖으로 나가는 문서로 좁혀졌다.
이 문제가 가벼운 게 아니었던 이유는 분명했다. 산출물을 받는 쪽은 회사 안 사정을 모르는 고객이나 거래처다. 문장이 어색하면 내용보다 신뢰도부터 깎인다. 자동화로 만든 문서라는 사실이 드러나는 순간, 정성껏 검토해서 보냈다는 인상 자체가 사라진다.
처음 세운 가설 — 모델에게 자연스럽게 쓰라고 하면 되지 않을까?
가장 먼저 떠오른 방법은 단순했다. 프롬프트에 '한국어를 자연스럽게 써라'라는 지시를 한 줄 추가하면 되지 않을까 하는 생각이었다. 모델이 번역체를 쓰는 이유가 지시를 안 받아서라면, 지시를 넣는 순간 문제가 풀릴 듯 보였다.
이 방법은 비용도 거의 안 든다. 프롬프트 한 줄만 고치면 되고, 별도 검사 장치를 새로 만들 필요도 없다. 그래서 이 방법부터 먼저 검토했다. 검사기를 따로 만드는 쪽은 개발 공수가 들지만, 프롬프트 수정은 문장 한 줄이면 끝나기 때문에 우선순위에서 항상 앞자리를 차지했다.
확인 수단 — 프롬프트 조건별 번역체 비율을 잰 연구를 대조했다
느낌이 아니라 근거로 확인하려고, 2025년에 나온 번역체(translationese) 연구를 찾아 대조했다. 이 연구는 GPT-4에 서로 다른 프롬프트를 주고 결과물의 번역체 비율을 직접 측정했다. 그중 하나가 자연스러움을 명시한 프롬프트 조건이었다.
가설을 그대로 검증할 수 있는 조건이라 이 결과부터 확인했다. 여기서 번역체가 줄었다면 프롬프트 한 줄로 문제를 풀 수 있었고, 안 줄었다면 다른 원인을 찾아야 했다.
이 연구가 쓴 측정 방법은 단순했다. 같은 모델에 프롬프트만 바꿔 여러 조건으로 글을 쓰게 하고, 그 결과물 안에서 번역체로 분류되는 문장의 비율을 세는 방식이었다. 조건을 하나씩 바꿔 가며 비교하니, 어떤 지시가 실제로 효과가 있고 어떤 지시가 효과가 없는지 숫자로 갈렸다.
알리바이 — '자연스럽게 써라'는 왜 통하지 않았나
naturalness를 명시한 프롬프트에서 GPT-4의 번역체 오류는 줄지 않고 오히려 늘었다.
결과는 가설과 정반대였다. 자연스럽게 쓰라는 지시를 명시할수록 번역체가 줄지 않고 오히려 늘었다. 프롬프트 한 줄로 문제가 풀린다는 가설은 이 대조에서 반증됐다.
처음에는 이 결과를 믿기 어려웠다. 지시를 더 분명하게 줬는데 결과가 나빠진다는 건 상식과 어긋났다. 그래서 원인을 모델의 지시 이해력이 아니라 다른 곳에서 찾아야 했다.
진짜 원인 — 문제는 프롬프트가 아니라 학습 데이터에 있었다
원인을 다시 보면 프롬프트가 아니라 데이터에 있었다. 모델이 번역체를 쓰는 습관은 지금 대화에서 생기지 않았다. 모델을 학습시킨 데이터 자체에서 왔고, 그 데이터 중 34% 이상이 이미 번역체였다.
프롬프트 한 줄을 더 넣어도 이 습관은 그 자리에서 안 바뀐다. 모델은 자연스럽게 쓰라는 지시를 이해는 하지만, 자연스러움의 기준 자체를 이미 번역체가 섞인 데이터로 배웠다. 지시를 더 강하게 걸수록 모델이 자연스럽다고 착각한 번역체 문형을 오히려 더 자주 꺼내 쓴 셈이다.
사람으로 치면 오래된 말버릇과 비슷하다. '사투리 쓰지 말고 표준어로 말해라'라고 한 번 말한다고 억양이 그 자리에서 안 바뀐다. 오래 쓴 말버릇은 의식적인 지시 한 번으로 안 사라진다. 모델의 번역체도 같은 구조였다 — 지시가 아니라 습관이 문제였다.
그래서 생성 지시를 더 정교하게 다듬는 방향을 포기했다. 대신 생성은 손대지 않고, 다 쓴 결과만 따로 검사해서 고치는 별도 패스를 얹는 방향으로 설계를 바꿨다.
고친 방법 — 생성은 그대로 두고, 나간 결과만 따로 검사한다
이 판단이 맞는지는 같은 연구의 다른 조건에서 확인할 수 있었다. GPT-4에게 '쓴 다음 다시 한번 다듬어라'라고 시켰을 때, 번역체 비율이 43%에서 25%로 떨어졌다. 생성 지시가 아니라 생성 후 별도 패스가 실제로 통하는 레버였다.
이 결과를 바탕으로 검사기를 두 층으로 나눠 만들었다. 첫째는 자연스러운 한국어에 거의 안 나타나는 강한 번역체 16개 규칙이다. '결정되어진다'처럼 겹쳐 쓴 피동, '고객 관리에 있어서'처럼 in/for를 그대로 옮긴 표현, '경험을 가지고 있습니다'처럼 have를 그대로 옮긴 표현이 여기 속한다. 이 규칙은 한 번만 걸려도 그 자리에서 고친다.
둘째는 밀도 지표다. 피동, '-에 대한/관한', '-것' 명사화, '-을 통해', 관형격 '의' 연쇄, 이 다섯은 한 번 쓰면 정상이고 자주 쓰면 번역체가 된다. 그래서 100어절당 등장 횟수로 잰다.
배선은 어디에 걸어야 새 문서 종류가 늘어도 버티는가
검사기를 다 만들어도 어디서 돌릴지가 남는 문제였다. 문서를 만드는 경로마다 검사 호출을 하나씩 심으면, 새 문서 종류가 생길 때마다 또 심어야 한다. 그래서 검사 호출을 파이프라인 하나하나가 아니라, 쓰기 동작이 모이는 지점 두 곳에만 걸었다.
하나는 에이전트가 파일을 새로 쓰거나 고칠 때마다 자동으로 도는 훅이다. 강한 위반이 하나라도 걸리면 그 자리에서 되돌아와 고치게 막는다. 다른 하나는 매일 오전 8시 40분에 도는 사후 검사다. 자동화 스크립트가 사람 손을 거치지 않고 스스로 쓴 산출물은 훅이 볼 수 없는 경로라서, 이쪽은 하루가 지난 뒤 따로 훑는다.
이 두 층이 같은 대상을 놓고 다른 답을 내면 검사기 전체를 믿을 수 없다. 그래서 밖으로 나가는 문서인지 아닌지 가르는 판별 로직을 함수 하나에만 두고, 두 층 모두 그 함수를 그대로 불러 쓰게 만들었다.
이렇게 나누고 나니 배선 대상 자체가 줄었다. 새 문서 종류가 생겨도 그 종류를 만드는 파이프라인에 검사 호출을 따로 심을 필요가 없다. 훅과 사후 검사, 두 지점만 지키면 그 뒤로 생기는 모든 문서가 같은 기준을 자동으로 통과하거나 걸린다.
밀도는 왜 낱개로 안 잡고 쌓아서 재는가
강한 위반과 달리 밀도 지표는 한 번 등장한 걸로는 걸지 않는다. 처음에는 이 구분 없이 등장 횟수만으로 걸렀는데, 그러자 라이브로 이미 나간 발송물 12건 중 10건이 걸렸다. 열어 보니 대부분 해당 표현이 문서 하나에 1~2회만 등장한 경우였다. 한두 번은 자연스러운 한국어에서도 흔한 빈도이지, 문서 전체의 경향이 아니었다.
- 200어절 미만이거나 등장 횟수가 3회 이하인 문서는 밀도 판정에서 뺀다
- 200어절 이상이고 4회 이상 반복된 문서만 100어절당 비율로 잰다
- 한도는 사람 상한의 약 1.5배로 잡는다 — 2026년 8월 21일 코퍼스 4종 실측
한도 값도 감으로 정하지 않았다. 2026년 8월 21일에 사람이 쓴 글 코퍼스와 AI가 통제 없이 쓴 산출물 코퍼스를 나란히 대조해, 사람 쪽 상한의 약 1.5배로 한도를 잡았다. 같은 대조에서 직관으로 넣었던 지표 4종은 오히려 사람 원고 쪽이 AI보다 더 많이 써서 전부 뺐다 — 측정이 직관을 반증한 자리였다.
같은 실수를 막는 장치 — 검사기가 스스로 놓쳤던 파일을 찾아낸 순간
이 검사 체계에도 사각지대가 있었다. 한 문서 작업이 이 한국어 자연성 규칙을 지켰는지 확인해 달라는 요청을 받고 들여다봤더니, 두 가지가 한꺼번에 드러났다.
그 문서는 검사 훅이 생기기 전에 이미 다 만들어져 있었다. 작성은 오전 10시 33분부터 낮 12시 7분 사이에 끝났는데, 검사 훅은 그날 12시 42분에야 걸렸다. 순서가 거꾸로였다.
더 심각한 문제는 따로 있었다. 실제로 제출하는 최종 파일은 docx 형식이었는데, 검사기는 그 파일을 렌더링해 만든 중간 결과(.md 파일)만 읽고 있었다. '통과'라는 답이 정작 밖으로 나가는 원본 파일은 한 번도 열어 보지 않은 채 나온 셈이었다.
고치는 방법은 문단뿐 아니라 표 셀까지 함께 읽는 함수를 새로 만드는 일이었다. 이력서나 제안서는 본문 상당량이 표 안에 들어 있어서, 문단만 읽으면 내용 대부분을 놓친다. 이 함수 하나를 검사기 CLI, 훅, 사후 검사 세 호출부가 전부 같이 쓰도록 배선을 다시 걸었다.
고친 뒤 정본 docx 파일과 렌더링한 중간 결과를 대조했더니 두 값이 단어 수 기준으로 정확히 일치했다. 강한 위반이 15건 있는 검증용 문서를 넣었을 때는 훅이 그 자리에서 막았고, 밀도만 넘는 문서는 막지 않고 통과시켰다. 실제 그 이력서를 다시 판정한 결과는 강한 위반 0건, 밀도 초과는 '-것' 명사화 1종(4회)이었다.
이후 사후 검사를 처음 돌렸을 때도 같은 방식으로 오탐을 걸러 냈다. 유튜브 자막이나 대기 목록 같은 파일이 문서로 잘못 잡혀, 124건 중 실제 대상은 8건으로 정리됐다. 다음번 401건을 돌렸을 때는 계약서의 법률 관용구와, 번역체를 금지하는 문서 자신이 인용한 예시 두 종류가 새로운 오탐으로 또 걸러졌다.
검사기 하나로 문제가 다 사라지지는 않는다는 점도 이번에 다시 확인했다. 처음 세운 규칙과 처음 그은 경계는 항상 어딘가 빈틈을 남긴다. 그 빈틈은 실제로 문서를 흘려보내고, 사고가 나고, 그 사고를 파헤쳐야 드러난다. 그래서 이 검사 체계는 한 번 완성하고 손을 떼는 방식이 아니라, 계속 흘려보내며 경계를 넓혀 가는 방식으로 운영한다.
검사기 하나를 만든다고 끝나지 않는다. 밖으로 나가는 문서인지 가르는 기준, 어떤 파일 형식까지 봐야 하는지, 무엇을 인용으로 봐줘야 하는지 — 이 경계는 실제로 문서를 흘려보내면서 계속 넓혔다. 같은 방식으로 자동 검사 장치를 설계하고 싶다면 Claude Code hooks가 설명 요청을 작업 지시로 잘못 읽어 오탐을 냈던 사례에서 정규식 경계 하나가 오탐을 만드는 과정을 같이 볼 수 있다. 회사 업무 자동화에 이런 검사 체계를 얹고 싶다면 상담에서 구체적으로 논의할 수 있다.