글은 화자를 연기하지 않고 독자 쪽에서 쓴다

제품 화면 문구, README, 팀에게 보이는 글(PR·이슈·코멘트·채팅), 기술 자료는 독자 쪽에서 쓴다. 각 줄은 독자가 보는 것·얻는 것·해야 할 일을 전하는 이름·지시·사실·결과 중 하나다. 글쓴이나 제품이 친구·판매원·작가를 연기하지 않는다.

왜 반복되는가

언어 모델은 누군가로서 글을 쓴다. 그래서 AI가 쓴 글에는 화자가 생긴다. 위로하고 호의를 베푸는 친구, 표어와 형용사로 파는 판매원, 이미지를 실은 동사를 고르는 작가다. 매체마다 겉모습이 달라서 사례별로 고치면 다른 매체에서 같은 편향이 다시 나온다. 조작 가이드 덱에서 교정한 광고 톤이 기술 레퍼런스 웹페이지에서 반복되는 식이다.

판별 질문 두 개

• 누가 누구에게 말하는가. 친구·고객·산문 독자에게 말하는 줄이면 이름·지시·사실·결과로 다시 쓴다. 인사와 감사, 위로, “천천히 보셔도 됩니다”, “문제 있으면 말씀해 주세요” 같은 되묻기, 표어, 근거 없는 형용사, 필요로 부풀린 동기, 작성자를 내세우는 “제가”가 여기서 걸린다.
• 독자가 이 단어를 스스로 쓰는가. 설정 키·프로세스 이름·상태 기계 용어, 작업 중에 생긴 대비어, 무엇의 번호인지 없는 축약은 독자의 말이 아니다. 단위, 독자가 일하는 분야의 용어, 제품명은 독자의 말이다.

고치는 방법

• 형용사는 그것을 뒷받침하는 사실로 바꾸거나 지운다. 구체화는 설명을 덧붙이는 것이 아니라 두루뭉술한 말을 사실로 바꾸는 것이다.
• 같은 화면이 이미 보여 주는 것(상태 표시, 도구가 표시하는 담당·검사 결과)은 본문에서 다시 말하지 않는다.
• 오류는 원문을 로그·상세 보기로 보내되, 구체적인 원인과 다음 행동은 독자의 말로 전한다.

적용하지 않는 곳

• 허구 안의 캐릭터 대사, 발표 자체가 목적인 자료.
• 어체는 이 판단과 별개로 매체와 팀 관례에 따라 정한다. 제품 UI의 합니다체·명사구, 팀 채팅의 해요체, 에이전트 지침의 -한다가 함께 쓰일 수 있다. 화자를 연기하지 않는 것과 어체를 하나로 통일하는 것은 다른 문제다.

근거

• 제품 문구의 화자와 독자 어휘 - make-interfaces-feel-better: 생성 문구의 네 가지 실패, 친구·판매원·작가의 세 형태, 내부 어휘 판별 질문, 오류의 두 방향. 팀용 글·기술 자료로 넓힌 범위와 어체 경계는 같은 Source의 2026-10-10 대조 절에서 DanzzaN이 채택한 해석이다.
• 인터페이스 판단과 검토 기준 - Jakub Krehel: write.md 일부의 원천인 better-writing.

연결

• UI 문구는 사용자가 행동과 결과를 예측하게 한다: 문구가 행동과 결과를 예측하게 하는 기준. 이 노트는 그 문구를 누구의 목소리와 어떤 어휘로 쓰는지를 다룬다.
• UI 디자인
• Atomic Notes