AI가 쓴 초안을 내 문장으로 고치는 기준, 기획 문서에서 배운 것

 

기획서, 정책 문서, 블로그 글까지 요즘은 AI가 쓴 초안을 다루는 일이 많아졌습니다.
읽어 보면 어색한 데가 없어요.
문법도 맞고 구조도 깔끔합니다.
그런데 다 읽고 나면 이상하게 내 문장이 아니라는 느낌이 남습니다.
글이 매끄러울수록 빈틈을 찾기가 오히려 어려워요.

이 느낌과 닿아 있는 연구 소식을 GeekNews에서 봤어요.
그 소식을 계기로 제가 AI 초안을 고치는 기준을 한 번 정리해 보려고 합니다.
연구 부분은 논문 원문이 아니라 GeekNews 요약을 기준으로 썼습니다.

 

요약에 따르면 연구진은 AI가 쓴 영어 대화, 코딩 설명, 에세이를 분석했습니다.
대상은 상위권 모델 9개와 작은 공개 모델 5개였어요.
AI의 글에는 무생물이 사람처럼 행동하는 주어 구조, 명사를 길게 이어 붙인 표현, 관계절을 줄여 압축한 구조가 사람의 글보다 자주 나타났다고 합니다.
영어를 일본어로 번역했다가 다시 영어로 되돌리면 이런 특징이 줄었다고 해요.
그래서 어려움의 원인이 내용보다 표현 선택에 있다고 본 것 같습니다.
원인은 확정이 아닌 가설이고, 적은 토큰에 정보를 압축하려는 학습 압력이 문장 습관으로 굳었을 수 있다는 내용이에요.

댓글은 3개였고 의견이 갈렸습니다.
하나는 목록과 제목처럼 평가하기 쉬운 모양으로 응답이 강화됐다는 의견이었어요.
다른 하나는 사전학습만 거친 기본 모델이 사람 문체를 더 잘 재현했다는 경험담입니다.
마지막은 특정 구문이 과도하게 반복되는 게 문제이지, 용법 자체는 오래된 언어 변화라는 반론이었어요.
이 연구는 영어 글이 대상이고, 한국어에서도 같은 현상이 있는지는 확인된 바가 없습니다.
그래서 이 아래는 모두 제 일과 제 체감으로 읽어 주세요.

 

예약 시스템을 기획하면서 문서가 개발자에게 어떻게 읽히는지가 늘 중요한 문제였습니다.
AI가 써 준 정책 문장에서 제가 특히 조심하는 유형이 세 가지 있어요.
아래 예시는 설명을 위해 가정해서 만든 문장입니다.

첫째는 주어가 모호한 문장입니다.
가정해 보면 "승인되면 처리되고 알림이 전송됩니다" 같은 문장이에요.
누가 승인하는지, 무엇이 처리되는지, 누가 알림을 받는지가 모두 비어 있습니다.
읽는 사람은 자기 머릿속 주어를 채워서 구현하게 돼요.

둘째는 조건이 문장 속에 묻힌 정책입니다.
가정해 보면 "예약은 24시간 전까지 취소할 수 있으나 노쇼 이력이 있는 고객은 수수료가 부과되며 테넌트 설정에 따라 면제될 수 있습니다" 같은 문장이에요.
규칙 하나에 예외 둘이 한 문장에 들어 있어서, 개발자가 앞부분만 구현하고 지나갈 수 있습니다.

셋째는 명사가 길게 이어진 문장입니다.
가정해 보면 "예약 취소 수수료 환불 처리 상태 변경 로직을 정의한다" 같은 문장이에요.
수수료를 환불하는 건지, 환불 처리 상태를 바꾸는 건지 끊어 읽을 자리가 보이지 않습니다.

 

세 유형의 공통점은 읽을 때는 쉬운데 구현하려고 하면 질문이 쏟아진다는 점이에요.
읽기 쉬운 것과 오해 없이 읽히는 것은 다른 문제라고 생각합니다.

 

이런 문장을 보고 나서 문서 규칙을 정했어요.
규칙이 많으면 지키기 어려워서 네 가지로만 줄였습니다.

• 첫째, 한 문장에는 판단을 하나만 담고 한 줄로 씁니다.
• 둘째, 조건은 문장에 풀어 쓰지 않고 목록으로 나눕니다.
• 셋째, 예외는 본 규칙과 떼어서 별도 항목으로 씁니다.
• 넷째, "충분히 일찍" 대신 "24시간 전"처럼 숫자와 예시를 넣습니다.

앞의 둘째 예시를 이 규칙으로 고치면 이렇게 됩니다. (가정한 예시입니다)

• 규칙: 예약 시작 24시간 전까지는 무료로 취소할 수 있습니다.
• 규칙: 24시간 이내 취소에는 수수료가 부과됩니다.
• 예외 1: 노쇼 이력이 있는 고객은 24시간 전에 취소해도 수수료가 부과됩니다.
• 예외 2: 테넌트 설정에서 면제를 켜면 수수료를 받지 않습니다.
• 예시: 14시 예약을 전날 13시에 취소하면 무료입니다.

목록으로 나누고 나니 예외 1과 예외 2가 부딪힐 때 어느 쪽이 먼저인지가 비어 있다는 게 보입니다.
문장 속에 묻혀 있을 때는 아무도 몰랐던 빈칸이에요.
규칙을 지키면 읽기 쉬워지는 것에 더해 기획의 구멍까지 드러난다고 생각합니다.

 

AI에게 초안을 맡길 때는 문체 가이드를 먼저 줍니다.
앞의 네 가지 규칙에, 명사를 세 개 이상 잇지 않기와 주어를 생략하지 않기를 더해서 건네요.
이 문서를 읽는 사람이 개발자라는 점도 함께 적어 둡니다.
가이드를 먼저 주면 나중에 고칠 양이 줄어든다고 보고 있습니다.

그래도 최종 문장은 반드시 제 말로 고칩니다.
먼저 소리 내어 읽어 보고 숨이 차는 문장을 둘로 나눕니다.
그다음 "이", "그", "해당" 같은 모호한 대명사를 지우고 구체적인 대상으로 바꿔요.
이 두 단계를 거치면 AI가 압축해 둔 문장이 풀리면서 제가 하려던 말이 드러납니다.

 

스팩브릿지는 화면 위에 정책, 데이터, API 스펙을 연결해서 보여 주는 협업 도구입니다.
지금 개발 중이고, 곧 GitHub에 공개할 계획이에요.
출발점은 Claude 등으로 목업을 만들었을 때, 설명이 없는 목업 때문에 개발자와 소통이 어긋났던 경험이었습니다.

이런 도구에서는 문장이 화면의 특정 요소에 붙어서 읽힙니다.
좁은 자리에서 읽히니 문장이 길면 어느 요소에 대한 말인지부터 흐려져요.
화면만 있고 말이 없어도 해석이 갈리고, 말이 있어도 읽기 어려우면 똑같이 갈립니다.
그래서 요소 하나에는 규칙 하나, 문장 하나라는 원칙이 기획 문서에서보다 더 엄격하게 필요하다고 생각해요.
문장이 짧고 형식이 일정하면 정책을 화면에 연결하는 작업도 훨씬 수월해질 거라고 기대합니다.

 

연구가 말한 압축 압력이 한국어에서도 같은 모양으로 나타나는지는 저도 모릅니다.
제가 느낀 불편함이 그 현상과 같은 것인지도 아직은 알 수 없어요.
그리고 가이드를 먼저 주는 방법이 얼마나 효과가 있는지는 제 작업을 더 쌓아서 확인해 보려고 합니다.

그 답이 나오기 전까지는 AI가 쓴 문장을 읽는 사람의 입장에서 한 번 더 풀어 주는 일이 사람 몫이라고 생각합니다.

 

기획자가 그 일을 잘 해낼 수 있다면, AI 시대에도 해야 할 일이 분명히 남아 있는 거겠죠.