프롬프트로 안 고쳐지는 건 재서 고쳤습니다

AI에게 글을 쓰게 하면서 문장 길이를 섞고, 80자를 넘는 문장도 넣고, 같은 종결을 줄이라고 적었더니 종결 어미처럼 눈에 보이는 지시는 어느 정도 지켜졌습니다. 그런데 문장 길이 분포와 리듬은 그대로였습니다.

처음에는 지시문이 부족한 줄 알았습니다. 수치를 더 넣고 표현도 바꿔 다시 생성한 다음 재보니 문장 길이 편차는 16에서 15가 됐고, 같은 종결 비율은 93%에서 93%로 남았습니다. 원인은 프롬프트가 아니라 검사 단계입니다.

먼저 결론부터

• 쓰지 말 단어, 종결 어미 형태, 출력 형식, 문단 구조는 생성 지시로 다룰 수 있었습니다.
• 문장 길이 분포, 짧은 문장 비율, 같은 종결 비율은 글을 다 쓴 뒤에 계산해야 하는 값이었습니다.
• 그래서 쓰는 단계와 재는 단계를 분리했습니다.
• 목표값은 감으로 정하지 않고 같은 장르의 실제 글을 세어 잡았습니다.
• 통계 검사를 통과해도 억지 비유나 문맥 오류는 남아서 별도 검수가 필요했습니다.

같은 종결이 30개인데 28개 이하여야 합니다.
3개만 바꿔야 합니다.

• 자동 수정 제안은 그대로 반영하지 않았습니다. 문체 지침과 충돌하는 경우가 있었기 때문입니다.
• 토큰 비용과 검사 결과는 호출 응답에서 받아 저장했습니다. 같은 글을 다시 검사하면 편당 20원이 또 나갔습니다.

지시를 더 써도 리듬은 바뀌지 않았습니다

처음에는 “문장 길이를 섞어라” 같은 지시가 너무 추상적이라서 실패한다고 보고, 짧은 문장 비율과 긴 문장, 종결 반복 비율까지 프롬프트에 적어 넣었습니다. 결과는 기대와 달랐습니다.

모델은 단어를 피하거나 지정한 형식을 맞출 때는 바로 반응합니다. 쓰는 순간 확인할 수 있는 조건이기 때문입니다. 반면 문장 길이 편차나 특정 종결의 비율은 글 전체가 나온 뒤에야 알 수 있으니, 생성 중인 모델에게 자기 출력의 통계는 보이지 않는 셈이었습니다.

수치를 더 구체적으로 적어도 같은 종결 비율은 93%였고 문장 끝이 계속 “습니다.”로 닫히니 내용이 달라도 읽는 속도가 평평해집니다. 프롬프트를 길게 쓰는 일로는 고쳐지지 않았습니다.

여기서 방향을 바꿨습니다.

쓰기와 측정을 나눴습니다

이후에는 초안을 받을 때 리듬 목표를 먼저 강제하지 않았습니다. 글을 만든 뒤 스크립트로 문장 길이 편차와 짧은 문장 비율, 같은 종결 비율을 계산하고 미달한 값만 다시 모델에 넘기는 방식입니다.

“리듬을 자연스럽게 바꿔 달라”는 요청은 결과를 확인하기 어려웠지만, 같은 종결이 30개이고 28개 이하여야 하며 3개만 바꾸라고 주면 수정 범위가 분명해집니다. 세는 일은 스크립트가, 문장을 바꾸는 일은 모델이 맡는 구조입니다.

이 방식은 수정 뒤에도 다시 측정합니다. 통과 여부를 느낌으로 판단하지 않기 위해서입니다. 글 전체를 다시 쓰게 하면 이미 괜찮은 문장까지 흔들렸고 필요한 자리만 고치게 하면 원문도 덜 망가졌습니다.

목표값도 실제 글에서 가져왔습니다

쇼츠 대본을 다듬을 때는 같은 분야 자막 33편과 문장 290개를 세었고 그 결과를 보기 전까지는 체언 종결이 거의 없다는 사실을 몰랐습니다.

합쇼체 -습니다        33.4%
체언 종결             17.2%
해요체                14.5%
-세요                 10.3%
질문                   6.9%
-죠 · -거든요 · -더라고요   4.4%
발화 속도             333 음절/분
전체 분량             208 음절

우리 대본의 체언 종결은 0개였습니다. 반대로 구어체를 만들 때 자주 추천받는 -죠, -거든요 같은 표현은 실제 자막에서 4.4%뿐이었습니다. 추천받은 장치를 많이 넣는다고 실제 말투에 가까워지는 것은 아닙니다.

발화 속도도 문제였습니다. 대본은 378 음절/분이었고 측정한 기준은 333 음절/분이었는데, “조금 느리게”라고 쓰는 대신 이 값을 보여 주자 고칠 자리가 선명해졌습니다. 목표는 취향이 아니라 관찰값에서 나와야 합니다.

통계가 통과해도 문장은 따로 읽혔습니다

지표를 맞춘 글에도 “뉴스를 다 삼켰습니다” 같은 비유가 남았는데, 문장 길이와 종결 비율은 이런 어색함을 판정하지 못합니다. 그래서 통계 검사와 의미 검사를 분리했습니다.

검수 프롬프트도 처음에는 글 전체를 통째로 넣고 어색한 곳을 찾게 했습니다. 돌아온 답은 “없음” 한 줄이었습니다. 실제로는 잡아야 할 문제가 있었는데 전부 놓쳤습니다.

문장에 번호를 붙이고 찾아야 할 유형 예시를 주고 JSON 출력까지 강제한 뒤에는 8/8을 검출했고 0/4의 오탐이 나왔습니다. 문장을 쪼개야 모델이 각각을 판단했고, 유형을 줘야 무엇을 찾아야 하는지 알았으며, JSON이 있어야 “전반적으로 괜찮습니다” 같은 답을 막을 수 있었습니다.

{
  "sentence": "문장 번호",
  "type": "문제 유형",
  "reason": "판단 근거"
}

자동 수정과 재검사는 따로 막았습니다

외부 모델이 “들어옵니다”를 “지급됩니다”로 바꾸라고 제안한 적이 있습니다. 의미만 보면 틀린 말은 아닙니다. 하지만 블로그 문체 지침에는 관공서 문체를 피하라는 조건이 있었고, 그대로 반영하면 다른 기준을 어기게 됩니다.

그래서 검수 단계에서는 지적만 받고 어떤 표현을 고를지는 사람이 결정했습니다. 자동 수정은 문체 규칙과 충돌할 때 더 위험합니다.

비용도 응답에서 기록했습니다. 추론 모델은 화면에 보이지 않는 생각 토큰까지 출력 요금에 포함할 수 있어서 미리 계산이 안 됩니다. 같은 글을 다시 검사했을 때 새 지적은 거의 없었지만 편당 20원이 들어서, 이후에는 검사 결과를 저장하고 같은 글이 들어오면 저장된 결과를 먼저 꺼냅니다.

프롬프트는 글을 만들 때 쓰고 측정은 글이 나온 뒤에 합니다. 이 순서를 나눈 뒤에야 “자연스럽게” 같은 말 대신 실제로 부족한 값을 고칠 수 있었습니다.