Files
document-haness/docs/TechLog/tech-log-studio/one-thing-many-names/reference/reference-ask-which-words-to-use.md
T
DongHyeonkaandClaude Opus 5 193da20d09 docs(TechLog): Reference 15편의 규칙 표기를 게시된 기록에 맞추고 주제 6 을 다시 쓴다
게시된 Reference 15편이 전부 규칙을 `### N. 제목` 으로 쓰고 적용 조건·예외·예시를 항목으로
쓴다. 내 15편은 규칙을 `**굵게**` 로, 나머지 셋을 문단으로 쓰고 있었다 — Studio 의
rules[]·applyWhen[]·exceptions[]·examples[] 는 배열이라 문단으로 두면 항목이 하나로 접힌다.

  규칙 68개를 `### N. 제목` 으로 바꿨다 (편당 3~7개, 게시된 것은 4~10개)
  적용 조건·예외·예시를 항목으로 갈랐다. 한 항목뿐이던 아홉 편은 조건을 나눠 적었다

주제 6 은 본문을 다시 썼다 — location = 이 정확히 일치하는 경로만 잡아 27개가 얼어붙은
구조, 여덟 곳이 우는 시점을 셋으로 가른 표, digest 를 다시 계산할 때 옛 값을 먼저
재현하는 이유.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 19:01:44 +09:00

3.3 KiB

kind, slug, title, topic, topicName, project, status, verifiedOn, sourceRevision, source
kind slug title topic topicName project status verifiedOn sourceRevision source
REFERENCE ask-which-words-to-use 톤을 지적받으면 고쳐 쓰지 말고 어떤 말을 쓸지 묻는다 one-thing-many-names 같은 것이 화면마다 다른 이름 TechLog 게시 전 2026-09-04 tech-log@2026-09-02
final/document.md#§13.3

톤을 지적받으면 고쳐 쓰지 말고 어떤 말을 쓸지 묻는다

사용자가 프로필의 문구가 AI 스럽다고 지적했다. 고쳐 쓴 첫 번째 안도 거절당했고, 결국 사용자가 직접 쓴 텍스트를 그대로 실었다. 이 사이트의 글은 작성자가 자기 말로 쓴다.

관계

  • 종류 이름을 두 번 바꿨다 — 화면의 이름과 계약의 kind 를 갈랐다 두 번째 안을 문어체로 세울 때 이 기준을 썼다.
  • 서버는 하나를 답했는데 화면은 추측 셋을 출력했다 그 문구는 목소리가 아니라 서버가 답한 사실을 실어야 한다.
  • 한 화면에 종류 이름이 아홉 개 떠 있었다 — 표가 여섯 벌이었다 같은 시기에 종류 이름을 표 하나로 모았다.

목적

작성자의 목소리로 쓰인 글을 고쳐 쓰다 두 번 거절당하는 것을 막는다.

규칙

1. 톤을 지적받으면 고쳐 쓰기 전에 어떤 말을 쓸지 묻는다

「더 나은 문장」을 제안하는 것과 그 사람의 말투로 쓰는 것은 다른 일이고, 후자는 제안하는 쪽이 잘하지 못한다.

2. 무엇이 AI 스러운지 구체적으로 받아 적는다

무엇을 하는지 말하지 않는 동사로 끝나는 것과 번역투가 실제로 지적된 두 가지였다.

3. 작성자가 이미 쓰는 말투를 따른다

Case 소제목에 쓰는 말이 「~한 것」 명사형이면 새 제목도 그 형태로 맞춘다. 의문형 꼬리와 이 기록에서 쓰지 않는 낱말은 쓰지 않는다.

적용 조건

  • 공개 화면의 글이 작성자의 목소리인 곳 — 프로필, 프로젝트 소개, 구역 제목, 기록의 소제목
  • 톤이 어색하다는 지적을 받았을 때
  • 기존 글에 없던 낱말이나 어미를 새로 넣으려 할 때

예외

  • 오류 문구처럼 서버가 답한 사실을 그대로 실어야 하는 곳에서는 말투를 묻지 않는다. 무엇을 실을지를 먼저 정한다.

  • 계약이나 코드가 정한 이름은 이 규칙에서 뺀다. 표시 이름만 바꾸고 계약 값은 건드리지 않는다.

예시

  • 「섞는다」·「함께 기록한다」·「흩어지지 않게」가 무엇을 하는지 말하지 않는 동사로 끝난다고 지적받았다.

  • 「결론이 서는 조건」·「프로젝트를 답니다」·「접근을 나눠 견주고」가 번역투로 지적받았다.

  • 「무엇을 견줬나」는 의문형 꼬리에 이 기록에서 쓰지 않는 낱말이었다. 작성자가 Case 소제목에 쓰는 말은 「이 구조에서 감수한 것」처럼 「~한 것」 명사형이라 그쪽에 맞췄다.

  • 「이 프로젝트가 밝힌 것」은 「프로젝트를 통해 확인한 결과」로, 「운영 가능한 설계로 연결합니다」는 「실제 운영에 적용할 수 있는 형태로 정리합니다」로 바꿨다.

  • 고쳐 쓴 첫 번째 안이 거절당한 뒤 사용자가 직접 쓴 텍스트를 실었다.