AI에게 초안을 건네고 “더 자연스럽게 고쳐줘”라고 하면, 문장이 매끈해지는 대신 내가 쓰지 않을 표현까지 따라온다. 기획서와 공지에서 더 급한 문제는 따로 있다. 누가 일을 하는지 빠졌거나, 앞에서 설명해야 할 조건이 뒤에 있거나, 같은 말을 두 번 하는 경우다. 이런 결함을 찾는 일과 새 문장을 쓰는 일을 나누면 AI에게 맡길 범위도 달라진다.
토머스 프타첵은 2026년 9월 17일 공개한 글에서 AI를 대필자가 아닌 교정자로 쓰는 방법을 제안했다. 먼저 사람이 글을 쓰고, 모델에는 결함을 찾게 한다. 수정도 사람이 한다. 이후 원문과 수정문 중 어느 쪽이 나은지 물을 때는 편집 과정을 모르는 새 대화로 옮긴다. 여러 번 고친 문장을 모델이 칭찬해 주는 것과 독자에게 더 잘 읽히는 것은 다를 수 있기 때문이다.
칭찬을 빼야 초안을 다시 쓸 수 있다
프타첵의 첫 번째 규칙은 단호하다. 모델이 제안한 표현을 한 단어도 가져오지 말라는 것이다. 그가 우려하는 것은 눈에 띄는 오탈자가 아니다. 듣기 좋은 표현을 계속 받아들이다 보면 문장마다 잡지 제목처럼 힘이 들어가고, 글쓴이의 어투가 사라진다는 문제다. 그는 자신의 문체를 지키기 위한 작업 규칙으로 이를 제시한다.
두 번째 규칙은 격려를 피하라는 것이다. 모델이 첫 초안의 구성과 비유를 칭찬하면, 작성자는 버리거나 다시 생각했을 대목을 붙들기 쉽다. 프타첵은 한동안 자신을 저자가 아닌 매체 편집자라고 소개하며 검토를 요청했지만, 모델이 가상의 매체 목표에 지나치게 맞추는 문제가 있었다고 썼다. 지금 권하는 방법은 더 간단하다. 칭찬을 금지하고, 답변에 칭찬이 섞이는지도 살피는 것이다.
실무에 옮기면 요청부터 바꿀 수 있다. “문장을 다시 쓰지 말고, 문제가 있는 구절과 읽기 어려운 이유를 짚어라. 칭찬과 대체 문장은 넣지 마라.” 이렇게 받으면 작성자는 제안 문장을 복사하는 대신 지적이 맞는지부터 판단하게 된다.
한 번에 잘 써 달라고 하지 말고, 한 종류의 결함을 찾게 한다
원문은 반복되는 표현, 동작을 감추는 명사화, 불필요한 수식어, 문단 순서를 점검 대상으로 든다. 프타첵은 글쓰기 책 Style: Lessons in Clarity and Grace 등을 읽으며 점검 항목을 모으고, 항목별로 원고를 여러 차례 검토하라고 제안한다. 맞춤법 검사처럼 정답 하나를 받는 과정은 아니다. 문장의 주체가 흐려졌다는 지적을 받더라도 무엇을 주어로 삼을지는 글쓴이가 정한다.
그가 직접 만든 글쓰기 도구 화면에도 이런 구분이 보인다. ‘군더더기 표현 다듬기’ 검토가 선택돼 있고, 본문에는 ‘in order to’ 같은 구절이 표시돼 있다. 화면의 ‘열린 항목 19개, 수락 1개’는 해당 원고의 처리 상태다. 모델의 정확도나 글쓰기 성능을 나타내는 수치는 아니다.
이 방식을 한국어 공지에 적용한다면, 처음에는 책임 주체가 빠진 문장만 찾아보게 해도 된다. 그다음 불필요한 수식어를 살피고, 마지막에 문단 순서를 검토한다. 모든 기준을 한꺼번에 던져 긴 평가서를 받기보다, 지금 고칠 문제를 좁히는 편이 지적을 원문과 대조하기 쉽다. 아래는 그 차이를 보여 주기 위해 만든 편집 예시다.
예문의 ‘총무팀 박서연’은 AI가 문맥만 보고 채워 넣어서는 안 되는 정보다. 담당자가 실제 담당자를 확인한 뒤 적어야 한다. 결함 진단을 잘 받았어도 수정에 필요한 사실까지 확보한 것은 아니다. 기획서에서 일정의 책임자를 쓰거나, 고객 공지에서 환불 조건을 풀어 쓸 때도 같은 구분이 필요하다.
수정안 비교에서는 편집 이력만 지운다
문제를 찾아 직접 고쳤다면 원문과 수정문을 비교할 차례다. 여기서 같은 대화를 계속 쓰면 모델은 사용자가 방금 수정했다는 사실을 안다. 프타첵은 모델이 사용자가 듣고 싶어 하는 “새 버전이 더 낫다”는 답으로 기울 수 있다고 지적한다. 그래서 수정 과정을 모르는 모델에 두 문안을 주라고 권한다.
업무에서는 두 문안을 A와 B로 표시하고 어느 것이 수정본인지 밝히지 않는 방식으로 적용할 수 있다. “내가 열심히 고친 버전” 같은 설명은 빼되, 누구에게 보내는 공지인지와 독자가 무엇을 해야 하는지는 두 문안의 공통 조건으로 준다. 맥락을 지운다는 말을 문서의 목적까지 없애라는 뜻으로 받아들이면 비교 기준도 함께 사라진다.
비교 요청도 “어느 쪽이 더 좋아?”에서 멈추지 않는 편이 낫다. “독자가 담당자와 다음 행동을 찾기 쉬운 쪽을 고르고, 판단 근거가 된 구절을 짚어라”라고 물으면 선택 이유를 확인할 수 있다. 모델의 선택을 최종 승인으로 삼지 않고, 사람이 놓친 차이를 찾는 데 쓰는 것이다. A·B 표기와 업무별 비교 기준은 원문의 원칙을 공지 작성에 옮긴 적용안이다.
도구를 만들기 전에 짧은 문서 하나로 시작한다
프타첵은 여러 탭을 오가며 검토하는 일이 번거로워져 전용 도구를 만들었다. 원문에 제시한 요구사항은 구절 강조, 옆면 코멘트, 제안 사이 이동, 문서별 수정 이력 관리다. PM이나 운영자가 같은 원칙을 시험하기 위해 도구부터 개발할 필요는 없다.
다음 공지 한 편을 직접 쓴 뒤 결함 진단을 받고, 납득한 지적만 반영해 새 대화에서 두 문안을 비교하면 된다. 프타첵 자신도 이 글이 20% 길다는 모델의 지적을 받고 줄이지 않았다고 썼다. 팀에서도 모든 지적을 반영할 필요는 없다. 검토를 마친 뒤에는 바꾼 구절과 이유, 받아들이지 않은 지적을 짧게 남기면 다음 공지를 편집할 때 참고할 수 있다.
출처: A Final Ward, How To Write With An LLM (2026년 9월 17일)