채택 제안 — 설득이 목적이다

읽는 사람은 결정권자다. 이 문서의 성공은 "잘 썼다"가 아니라
결정을 내릴 수 있게 됐는가로 판정된다.

[[result-record]] 와 목적이 다르다. 저쪽은 우리가 나중에 다시 보려고 남기는 기록이고,
이쪽은 남에게 판단을 요청하는 문서다. 그래서 요구되는 것도 다르다.

1. 필수 논거 3종 — 하나라도 빠지면 결정이 안 된다

① 역할 규명 — 이게 정확히 무엇인가

가장 자주 빠지고, 빠지면 가장 큰 오해를 만든다.

그것이 부품(백본·라이브러리) 인가 완성품(프레임워크·제품) 인가.
단독으로 쓰는가, 무엇과 함께 써야 하는가. 무엇을 대체하고 무엇은 대체하지 않는가.

이걸 안 밝히면 결정권자가 "그거 하나 넣으면 끝나는 것" 으로 이해한다.

② 비교표 — 대안 대비 강·약점

대안 없이 하나만 제시하면 그건 제안이 아니라 통보다.
성능 수치는 출처에 적힌 값만 쓰고 어디서 봤는지 함께 적는다.

③ 한계·리스크 솔직 고지

좋은 점만 쓰면 보고서가 아니라 홍보물이다. 우리 환경의 제약
(하드웨어·데이터·라이선스·운영 부담)과 매칭해서 적는다.

반대 근거가 있으면 "제약 및 위험요인" 절에 병기한다. 결정권자의 방향과
정합시키되, 불리한 사실을 감추지 않는다 — 나중에 드러나면 그때는 제안 전체의
신뢰가 무너진다.

2. ⚠️ 예비 실행 결과를 성능 근거로 쓰지 않는다

파이프라인이 도는지 확인하려고 소량으로 돌린 결과(smoke) 는 성능이 낮게 나온다.
이걸 보고서에 실으면 그 기술이 나쁜 것처럼 읽힌다.

• 보고서에는 정식 규모로 돌린 결과만 싣는다.
• 예비 실행은 필요하면 "사전 점검" 으로만 언급하고 수치는 넣지 않는다.
• 축소 규모로 측정할 수밖에 없었다면 "데모 규모, 통계적 신뢰도 낮음" 을 각주로 명시한다.

3. 근거 자료 읽기 — 함정

논문·백서 PDF에서 텍스트를 뽑을 때 흔히 막힌다.

# 콘솔로 바로 출력하면 인코딩이 맞지 않는 환경에서 특수문자·비ASCII가 깨진다.
# 반드시 UTF-8 파일로 저장한 뒤 읽는다.
python -c "from pypdf import PdfReader; import io; \
r=PdfReader(r'<입력.pdf>'); f=io.open(r'<출력.txt>','w',encoding='utf-8'); \
[f.write('\n=== PAGE %d ===\n'%(i+1) + (p.extract_text() or '')) for i,p in enumerate(r.pages)]; \
f.close()"

렌더러가 필요하면 pymupdf 로 페이지 이미지를 뽑아 눈으로 확인한다 —
표·그림은 텍스트 추출로 안 나온다.

4. 문체 — 사내 공식 문서

결정권자가 그대로 회람할 수 있어야 한다.

• 개조식 명사형 종결 (~함 / ~임 / ~필요함 / ~판단됨), 중립적 존칭
• 절 번호 체계(1. / 2. / …), 말미 "이상."
• 금지: 이모지, 구어체, 감탄사("게임체인저" 류), 특정인을 지목하는 표현, 장식 기호
• 표는 비교·목록에 한해 사용. 남발하지 않는다
• 결론(제안사항)은 번호 목록으로 명확히

수치·주장은 근거로만 쓰고, 근거 없는 판단은 "추정" 이라고 밝힌다.

4-1. 짧은 메시지로 결정을 요청할 때 — 문단마다 목적·근거·제안

메신저·메일로 결정권자에게 판단을 요청하는 경우다. 목적은 §1과 같지만 형식이 다르다 —
절 번호와 개조식이 아니라 평이한 문장체이고, 스크롤 없이 읽혀야 한다.

핵심은 문단 구조다. 각 문단을 서론(목적) → 본론(근거) → 결론(제안) 순으로 짧게 쓴다.
문단 하나가 논점 하나를 담고, 그 안에서 세 부분이 순서대로 나온다. 논점이 여럿이면
번호로 나누고 번호마다 이 구조를 반복한다.

2. 어디까지 할지 확인 부탁드립니다.                    ← 목적 (무엇을 묻는가)
   A 방식은 라벨된 데이터가 있어야 하고, B 방식은        ← 근거 (왜 묻는가)
   정상 데이터만으로 지표 0.99가 나왔습니다('○○' 탭).
   - 여기까지면 정상 데이터만 모으면 됩니다.            ← 제안 (무엇을 고르면 되는가)
   - 더 필요하시면 예정대로 라벨 데이터를 찾겠습니다.

• 근거는 상대가 이미 본 자료를 가리킨다. 새로 설득하지 말고 상기시킨다.
  문서·탭·파일 이름을 특정해서 적는다
• 수치 하나는 남긴다. "충분히 높습니다"보다 "0.998이 나왔습니다"가 짧고 강하다
• 제안은 상대가 고를 수 있는 형태로. 선택지마다 우리가 무엇을 할지까지 적으면
  결정이 곧 지시가 되어 왕복이 한 번 줄어든다
• 상대의 기존 지시를 부정하지 않는다. 뒤집자는 것이 아니라 범위를 확인하는 형태로
  쓴다. 기존 지시가 유효한 경우를 선택지에 남겨 두면("그러면 예정대로 …") 그 자체로
  존중이 된다

함정 둘 — 둘 다 실제로 겪은 것이다.

1. 한계 설명으로 열지 마라. "이 방식은 ~를 못 합니다"로 시작하면 안 되는 이유를 듣는
   모양이 되어 방어적으로 읽힌다. "요구가 다르다 → 목표를 정해달라" 로 여는 편이
   같은 내용을 전달하면서 결정을 재촉하지 않는다.
2. 모호한 수식어가 앞뒤 모순을 만든다. "지난 회의에 결정한 대로 A는 X가 필요하고"라고
   쓰면 A를 쓰기로 결정했다로 읽혀, 바로 아래에서 "X가 정말 필요한지" 묻는 것과 충돌한다.
   수식어가 무엇을 꾸미는지 다시 읽어본다.

받는 사람의 문체를 흉내 내야 한다면 그 사람이 쓴 과거 메시지를 실제로 모아 보고
쓴다. 어투·길이·종결어미는 기억이 아니라 표본에서 나온다.

5. 이해를 돕는 질문은 본문에 넣지 않는다

읽다 보면 "그건 어떻게 돌리나", "데이터는 어디서 오나" 같은 질문이 따라온다.
본문에 다 넣으면 결정에 필요한 논지가 묻힌다.

→ 별도 Q&A 해설 문서로 빼고 본문 참고 절에서 링크한다.

6. 로컬 먼저, 외부 반영은 별도 승인

로컬에 작성하는 것까지가 기본이다. 외부 문서·공유 채널 반영은 명시적 지시가
있을 때만 별도로 진행한다(→ [[docs-append]]).

연계

• 실험 결과 기록은 [[result-record]]
• 내용 검증은 [[work-review]]

이력 (필수 기록)

• 생성일: 2026-08-27
• 업데이트 횟수: 1
• 최근 업데이트: 2026-08-28
• 사용 이력:
  • 2026-08-28 — §4-1(짧은 메시지) 신설. 사용자 지시로 확정: 본문 문단도
    서론(목적)-본론(근거)-결론(제안) 구조로 짧게 쓴다. 이 스킬이 문서 형식(§4)만
    다루고 있어, 같은 목적을 메신저로 전달할 때의 형식이 비어 있었다.
    함정 2건은 초안을 실제로 주고받으며 드러난 것이다 — 한계 설명으로 열어
    방어적으로 읽힌 것, "지난 회의에 결정한 대로"라는 수식어가 앞뒤 모순을 만든 것.
  • 2026-08-27 — 프로젝트 전용 스킬을 일반화해 이관. 목적을 "모델 보고서 작성"이 아니라
    채택 요청(설득) 으로 다시 세웠다. 대상이 모델에 한정되지 않으므로 기술·도구
    일반으로 넓혔다. §2(예비 실행 결과 금지)와 §3(PDF 추출 함정)은 실제로 겪은 사고다.