LLM에게 "이 글 자연스럽게 고쳐줘"라고 한 번 시키면, 결과가 좋을 때도 있고 내용이 어긋나거나 밋밋하게 뭉개질 때도 있습니다. 문제는 그 편차를 통제할 수 없다는 점입니다. 한글 AI 티 제거 하네스는 이 편차를 줄이려고 윤문을 하나의 프롬프트가 아니라 역할이 나뉜 에이전트들의 파이프라인으로 설계했습니다.
왜 한 번에 끝내지 않았나
탐지와 윤문과 검증을 한 프롬프트에 몰아넣으면 서로 간섭합니다. 티를 찾는 데 집중하다 보면 윤문이 거칠어집니다. 자연스럽게 다듬는 데 집중하면 원문 내용이 슬그머니 바뀝니다. 스스로 고친 글을 스스로 검증하면, 자기가 놓친 것은 여전히 놓칩니다.
그래서 역할을 분리했습니다. 탐지 담당은 신호를 찾아 심각도와 함께 목록으로만 내놓고, 윤문 담당은 그 목록에 근거해서만 문장을 고치며, 감사 담당은 내용이 훼손됐는지 원문과 대조하고, 자연도 담당은 윤문 뒤 글에 티가 남았는지 다시 탐지합니다. 각 단계가 다른 관점을 가지므로 한 단계가 놓친 문제를 다음 단계가 잡습니다.
이 분리에는 대가가 있습니다. 에이전트를 여러 번 호출하니 느리고 비용도 더 듭니다. 짧은 메모 한 편을 고치자고 다섯 단계를 돌리는 건 과합니다. 그래서 하나의 파이프라인이 아니라 두 개의 모드를 두었습니다.
Fast 모드: 짧은 글은 한 번에
일정 길이 이하의 글은 Fast 모드로 처리합니다. 단일 에이전트가 한 호출 안에서 탐지, 윤문, 자체검증을 순서대로 끝냅니다. 역할을 물리적으로 나누지는 않지만 같은 에이전트가 단계를 의식하며 진행하도록 지시가 짜여 있습니다.
Fast 모드의 핵심은 예측 가능성입니다. 도구 호출 횟수에 상한을 걸어 무한정 늘어지지 않게 하고 대체로 몇 분 안에 결과가 나옵니다. 대부분의 블로그 글이나 이메일, 소개 문구는 이 모드로 충분합니다. 결과물로는 원문과 윤문본, 그리고 무엇이 왜 바뀌었는지 담은 요약이 남습니다.
strict 모드: 긴 글과 정밀 검증은 다단계로
길이가 임계치를 넘거나 사용자가 정밀 검증을 요청하면 strict 모드로 자동 승급합니다. 여기서는 앞서 말한 역할 분리가 실제 별개 에이전트로 구현됩니다.
먼저 탐지 에이전트가 신호를 span 단위로 찾아 위치, 종류, 심각도를 구조화된 리포트로 냅니다. 윤문 에이전트가 그 리포트에 연결된 부분만 수술적으로 고칩니다. 그다음 감사 에이전트와 자연도 에이전트가 병렬로 붙습니다. 감사는 사실과 수치와 인용이 그대로인지 체크리스트로 확인합니다. 자연도는 탐지를 다시 돌려 티가 남았는지와 과하게 고쳐지지 않았는지를 봅니다.
마지막으로 오케스트레이터가 이 결과들을 종합해 판정합니다. 문제가 없으면 채택하고, 티가 남았으면 윤문을 한 번 더 돌리고, 내용이 훼손됐으면 문제 수정을 롤백하고, 자동으로 처리하기엔 위험하면 사람 검토로 넘깁니다. 재윤문에는 횟수 상한을 두어 무한 루프를 막습니다. 이 단계별 산출물은 각각 파일로 남아 어느 단계에서 무슨 판단이 있었는지 추적할 수 있습니다.
모드를 나눈 것 자체가 설계다
두 모드를 둔 결정은 단순히 성능 최적화가 아니라 "정밀도와 비용은 맞바꾸는 것"이라는 인정입니다. 모든 글에 최고 정밀도를 강요하면 아무도 안 씁니다. 모든 글을 대충 처리하면 신뢰를 잃습니다. 입력 길이라는 관측 가능한 신호로 두 모드를 자동으로 가르니 사용자는 모드를 의식하지 않고도 글에 맞는 처리를 받습니다.
이 파이프라인이 참조하는 탐지 기준은 AI 티 탐지 분류 체계 설계에서, 내용을 지키는 감사 단계의 상세는 내용을 지키는 윤문 가드레일에서 다룹니다. 전체 도구의 설계는 한글 AI 티 탐지·윤문 오픈소스 툴 사례에 있습니다.
자주 묻는 질문
왜 윤문을 여러 에이전트로 나눴나요?
한 프롬프트가 탐지와 윤문과 검증을 동시에 하면 서로 간섭합니다. 자기가 고친 글을 자기가 검증하면 놓친 것을 계속 놓칩니다. 역할을 나누면 각 단계가 다른 관점을 가져 앞 단계의 사각지대를 뒤 단계가 잡습니다. 대신 속도와 비용을 내주므로 짧은 글에는 단일 호출 모드를 따로 두었습니다.
Fast 모드와 strict 모드는 어떻게 갈리나요?
기본적으로 입력 글의 길이로 자동 판정합니다. 짧은 글은 단일 에이전트가 한 번에 처리하는 Fast 모드로, 임계치를 넘는 긴 글이나 정밀 검증이 필요한 경우는 다단계 strict 모드로 승급합니다. 사용자가 명시적으로 정밀 모드를 요청할 수도 있습니다.
윤문이 무한정 반복되지는 않나요?
strict 모드의 재윤문에는 횟수 상한이 걸려 있습니다. 티가 남으면 다시 윤문하되 정해진 횟수를 넘으면 멈추고 자동으로 해결이 안 되면 사람 검토로 넘깁니다. 자동 처리와 사람 판단의 경계를 분명히 두어 도구가 스스로 판단을 유보할 줄 알게 설계했습니다.