제안서 작성 규칙

## 이 규칙을 쓰는 이유

제안서를 AI에게 맡기면 대개 **기대효과**만 나온다. "생산성이 향상되고 만족도가 높아질 것으로 기대됩니다" 같은 문장은 결정을 도와주지 않는다. 결정하는 사람이 알고 싶은 것은 세 가지다. 무엇을 왜 제안하는지, 도입하면 무엇이 좋아지는지, 그리고 무엇을 감수해야 하는지.

세 번째가 빠진 제안서는 나중에 문제가 생겼을 때 "왜 이 얘기는 없었냐"는 반응을 부른다. 아래 규칙은 그걸 막는 것이 목적이다.

## 섹션 순서

이 순서를 바꾸지 않는다.

1. **제안 요지** (무엇을, 왜)
2. **기대효과** (근거 포함)
3. **고려사항 / 리스크** (대응 방안 포함)
4. **실행 조건** (필요한 자원·시점·전제)

3번을 생략하지 않는다. 리스크가 정말 없는 제안은 드물다.

## 기대효과는 근거와 함께 쓴다

효과를 단정적으로 쓰지 않는다. **그렇게 판단한 근거**를 붙인다.

- 이렇게 쓰지 않는다: `업무 생산성이 크게 향상될 것으로 기대됩니다`
- 이렇게 쓴다: `동일 작업을 수행한 유사 팀 사례에서 처리 시간이 평균 30% 줄었다. 우리 팀 규모(5명)에서는 주당 약 4시간 절감으로 추정한다.`

근거가 없으면 "기대한다"가 아니라 "가정한다"로 쓰고, 검증 방법을 함께 밝힌다.

## 리스크는 대응 방안과 함께 쓴다

리스크를 나열만 하고 끝내지 않는다. **발생 시 어떻게 대응할지**를 붙인다.

- 이렇게 쓰지 않는다: `초기 도입 시 기존 프로세스와 충돌할 수 있음`
- 이렇게 쓴다: `초기 2주간 기존 프로세스와 병행 운영해 충돌 지점을 먼저 확인한다. 충돌이 크면 도입을 1개월 연기할 수 있다.`

대응 방안이 없는 리스크는 리스크가 아니라 경고문에 그친다.

## 대안과 비교해서 왜 이 방법인지 밝힌다

단일안만 제시하지 않는다. **고려했던 다른 방법과 왜 이걸 선택했는지**를 짧게 쓴다.

- 이렇게 쓰지 않는다: `아래와 같이 진행할 것을 제안합니다`
- 이렇게 쓴다: `외주 도입도 검토했으나 초기 비용이 3배 높고 내부 지식이 남지 않아, 자체 개발 쪽을 제안한다.`

비교 없는 제안은 "다른 선택지는 안 봤다"는 인상을 준다.

## 분량과 톤

- 확신을 과장하는 표현("반드시", "확실히")을 쓰지 않는다. 불확실한 부분은 불확실하다고 쓴다.
- 숫자를 쓸 때는 근거(사례·측정·가정)를 함께 밝힌다.
- 실행 조건(예산·인력·일정 전제)을 명시해, 조건이 바뀌면 제안도 바뀔 수 있음을 밝힌다.

## 쓰기 전에 확인할 것

- 1~4번 섹션이 모두 있는가
- 기대효과에 근거가 붙어 있는가
- 리스크마다 대응 방안이 붙어 있는가
- 대안과의 비교가 있는가
- 과장된 확신 표현이 없는가

흔히 나오는 실패 예시는 `bad-examples.md`에 정리해 두었다. 처음 몇 번은 그것과 비교해 보면 빠르다.

# 흔한 실패 예시와 교정

제안서에서 반복적으로 나오는 네 가지 패턴이다. 왼쪽이 자주 나오는 문장, 오른쪽이 교정이다.

## 1. 근거 없는 기대효과

**자주 나오는 것**

> 이 도구를 도입하면 팀 생산성이 크게 향상될 것으로 기대됩니다.

"크게"가 얼마나인지, 무엇을 근거로 한 판단인지 알 수 없다.

**교정**

> 유사 규모 팀 3곳의 도입 사례에서 반복 작업 시간이 평균 25% 줄었다. 우리 팀에 적용하면 주당 3~4시간 절감으로 추정하나, 실제 절감폭은 도입 후 1개월 측정으로 확인한다.

추정치와 검증 계획을 함께 쓰면 결정하는 사람이 리스크를 가늠할 수 있다.

## 2. 리스크 없이 장점만

**자주 나오는 것**

> 새 배포 파이프라인은 속도와 안정성을 모두 개선합니다.

장점만 있는 제안은 드물다. 리스크가 없다면 그 자체가 검토 부족의 신호다.

**교정**

> 배포 속도는 개선되나, 초기 1~2주는 새 파이프라인 학습으로 오히려 배포 빈도가 줄 수 있다. 기존 파이프라인을 2주간 백업으로 유지해 문제 시 즉시 되돌린다.

장점과 함께 불편해질 수 있는 구간과 대응책을 명시한다.

## 3. 대안 비교 없는 단일안

**자주 나오는 것**

> 아래와 같이 신규 모니터링 도구를 도입할 것을 제안합니다.

왜 이 도구인지, 다른 대안은 검토했는지가 없으면 선택의 타당성을 판단할 수 없다.

**교정**

> 기존 도구를 유지하는 안, 오픈소스 대체 도구로 바꾸는 안, 상용 도구를 도입하는 안을 비교했다. 오픈소스 대체 도구는 기능은 충분하나 유지보수 인력이 없어 제외했고, 상용 도구는 초기 비용은 있으나 운영 부담이 가장 낮아 제안한다.

비교 대상과 배제 이유를 남기면 제안의 근거가 명확해진다.

## 4. 실행 조건 불명확

**자주 나오는 것**

> 빠르게 도입이 가능하며 별도 준비 없이 시작할 수 있습니다.

"빠르게", "별도 준비 없이"는 확인되지 않은 낙관이다. 실제 실행 시 막힐 수 있다.

**교정**

> 도입에는 담당자 1명이 2주간 전담으로 필요하며, 기존 시스템 접근 권한 승인이 선행돼야 한다. 승인이 늦어지면 일정도 그만큼 밀린다.

필요한 자원과 전제조건을 구체적으로 쓰면 실행 가능성을 미리 검토할 수 있다.

## 확인 순서

작성 후 위에서부터 훑으며 네 가지를 본다.

1. 근거 없는 기대효과 문장이 있는가
2. 리스크 없이 장점만 있는가
3. 대안 비교 없이 단일안만 있는가
4. 실행 조건이 낙관적으로만 쓰였는가

하나라도 걸리면 그 문장만 고친다. 전체를 다시 쓸 필요는 없다.