고객 데이터 분석 플랫폼 도입 제안요청서를 써 줘

## 역할과 목표

너는 공공 또는 기업 조달 문서 작성 담당자다. 사용자에게서 확인된 사실과 검증 가능한 자료만 사용해 **고객 데이터 분석 플랫폼 도입 제안요청서**의 작성용 초안을 만들어라. 문서는 잠재적 제안업체가 사업 목적, 과업 범위, 제출 방법, 평가 방식과 일정을 이해하고 제안서를 준비할 수 있도록 구성한다.

완료 기준은 다음과 같다.

1. 제안요청서의 필수 항목인 사업 개요, 과업 범위, 제출 서류, 평가 기준, 일정을 모두 포함한다.
2. 확정되지 않은 사업명·기관명·예산·기간·배점·계약 조건을 임의로 채우지 않는다.
3. 각 항목에 `CONFIRMED`, `PROVISIONAL`, `[입력 필요]` 중 하나를 표시한다.
4. 법률과 조달 절차는 적용 여부를 확인할 대상으로 제시하며, 확인하지 않은 조문 내용을 단정하지 않는다.

## 범위와 전제

사용자 원문에서 확인되는 사업은 **고객 데이터 분석 플랫폼 도입**이다. 따라서 문서에는 플랫폼 도입의 목적, 요구 기능, 데이터 연계, 분석 환경, 보안·개인정보 고려사항, 구축·전환·교육·유지관리 범위를 제안요청서 항목으로 배치하라. 다만 사용자 원문만으로는 발주기관, 대상 조직, 현재 시스템, 데이터 규모, 사용자 수, 예산, 기간, 운영 방식, 서비스형 또는 구축형 여부가 확인되지 않는다.

다음 값은 반드시 슬롯으로 남겨라.

- `[입력 필요: 발주기관명]`
- `[입력 필요: 사업명]`
- `[입력 필요: 사업 예산 및 부가세 포함 여부]`
- `[입력 필요: 사업 수행 기간]`
- `[입력 필요: 대상 부서·사용자·데이터 범위]`
- `[입력 필요: 기존 시스템과 연계 대상]`
- `[입력 필요: 계약 법령 및 계약 방식]`
- `[입력 필요: 평가 배점과 제출 일정]`

각 슬롯 옆에는 해당 값을 발주기관의 사업계획서, 예산서, 내부 시스템 현황, 입찰 공고 또는 담당 부서 확인으로 채워야 한다는 한 줄의 작성 안내를 붙여라. 특히 고객 데이터 분석 플랫폼의 예산·기간·사용자 수·데이터 건수·필요 성능을 업계 관행이나 임의의 예시값으로 채우지 마라.

문서에 포함할 범위와 제외 범위를 분리하라. 포함 범위는 플랫폼 도입을 위한 요구사항과 제안업체 선정에 필요한 정보다. 특정 제품명, 특정 공급업체, 미확인 기술 아키텍처, 검증되지 않은 법률 해석, 확정되지 않은 운영 성과는 제외하거나 `[입력 필요]`로 표시하라.

## 작업 규칙

다음 순서로 작성하라.

1. 원문에서 확정된 사실과 미확정 정보를 분리한다. 확인된 사실은 “고객 데이터 분석 플랫폼 도입”이라는 사업 주제뿐이므로, 그 밖의 핵심 값은 슬롯으로 관리한다.
2. 사업 목적을 작성할 때 플랫폼이 해결해야 할 업무 문제와 기대 활용을 `[입력 필요: 해결 대상 업무 문제]`, `[입력 필요: 기대 활용 및 성과 기준]`으로 구분한다. 구체적 효율 향상률, 비용 절감액, 처리 속도 같은 수치는 근거가 제공된 경우에만 적는다.
3. 요구사항은 기능, 데이터, 기술·연계, 보안·접근권한, 운영·유지관리, 교육·이관으로 나눈다. 각 요구사항에는 “요구 내용”, “검수 또는 확인 방법”, “확정 상태”를 함께 둔다.
4. 개인정보가 처리될 가능성이 있으면 개인정보 보호법 적용 여부와 처리 항목·보유 기간·파기 방법을 확인 항목으로 둔다. 법 적용 여부와 처리 범위가 확인되지 않았다면 단정하지 말고 각각 `[입력 필요: 개인정보 처리 여부]`, `[입력 필요: 개인정보 처리 항목·보유 기간·파기 방법]`으로 남긴다.
5. 계약·입찰 조건은 다음 분기로 처리한다.
   - 공공기관 발주로 확인되면 국가를 당사자로 하는 계약에 관한 법률 또는 지방계약법 중 어느 법령이 적용되는지 확인하도록 한다.
   - 국가계약법·지방계약법 적용 여부가 확인되지 않으면 `[입력 필요: 적용 계약 법령]`으로 표시한다.
   - 공공 발주이면 나라장터 공고 절차 대상인지, 적격심사인지 협상에 의한 계약인지 확인 항목으로 둔다.
   - 중소기업자간 경쟁제품 지정 여부, 지역제한, 지역의무공동도급 조건도 각각 확인 대상으로 둔다.
6. 법률 조문 번호나 조문 내용을 기억에 의존해 작성하지 마라. 필요한 경우 공식 법령·공고·발주기관 지침에서 근거를 확인한 뒤에만 기재하고, 확인하지 못한 내용은 `[확인 필요]`로 표시한다.
7. 평가 기준은 가격, 기술, 수행역량, 보안·개인정보 대응, 유지관리 등으로 나눌 수 있으나 실제 항목과 배점은 제공되지 않았다. 따라서 항목명과 배점 입력란을 설계하고 `[입력 필요: 평가 항목별 배점]`을 남긴다.
8. 각 단계가 끝날 때 다음 완료 조건을 확인한다.
   - 사실 분류 완료: 확정 정보와 슬롯 정보가 분리되어 있다.
   - 요구사항 설계 완료: 기능·데이터·보안·운영 요구가 각각 검증 방법과 연결되어 있다.
   - 조달 조건 확인 완료: 계약 법령, 공고, 계약 방식, 경쟁제품·지역 조건이 확인 대상으로 표시되어 있다.
   - 문서 편집 완료: 모든 필수 항목과 표가 포함되어 있고 상태 라벨이 빠지지 않았다.

## 산출물 구조

다음 순서와 형식으로 제안요청서를 작성하라. 각 주요 항목 제목 뒤에 상태를 `CONFIRMED`, `PROVISIONAL`, `[입력 필요]` 중 하나로 표시하라.

1. **사업 개요**
   - 사업명, 발주기관, 추진 배경, 목적, 대상 조직, 사업 기간, 예산
   - 미확정 값은 슬롯으로 두고, 각 슬롯에 입력 방법을 한 줄로 덧붙인다.
2. **과업 범위**
   - 현황 분석
   - 플랫폼 설계·구축 또는 도입
   - 데이터 수집·정제·연계·이관
   - 분석·시각화·보고 기능
   - 권한·보안·감사
   - 테스트·검수·교육·운영 전환·유지관리
   - 각 과업은 요구 내용, 산출물, 검수 방법, 상태를 표로 제시한다.
3. **기술 및 운영 요구사항**
   - 사용자와 데이터 범위, 연계 시스템, 배포 환경, 접근권한, 장애 대응, 백업·복구, 성능 검증 기준
   - 확인되지 않은 수치와 환경은 슬롯으로 남긴다.
4. **보안·개인정보 및 준수사항**
   - 개인정보 처리 여부, 처리 항목, 보유 기간, 파기 방법, 접근통제, 로그 관리, 관련 법령 확인 사항
   - 법령의 적용 여부와 조문은 검증 전 단정하지 않는다.
5. **제출 서류**
   - 제안서, 가격 관련 서류, 사업자·수행실적·인력 증빙, 보안·개인정보 대응 자료 등 필요한 항목명을 제시한다.
   - 실제 제출 형식, 부수, 파일 형식, 마감 시각은 `[입력 필요: 제출 형식 및 마감 조건]`으로 남긴다.
6. **평가 기준**
   - 평가 항목, 세부 기준, 배점, 평가 방식, 동점 처리 기준을 표로 제시한다.
   - 배점은 제공되지 않았으므로 값을 만들지 말고 `[입력 필요: 배점]`으로 둔다.
7. **추진 일정**
   - 공고, 질의응답, 제안서 제출, 평가, 협상 또는 계약, 착수, 중간 검수, 최종 검수, 운영 전환의 일정표를 제시한다.
   - 모든 날짜와 기간은 `[입력 필요: 해당 일정]`으로 남긴다.
8. **확인 필요 사항**
   - 문서 확정 전 발주기관이 결정해야 할 슬롯과 법률·조달 검토 항목을 목록화한다.

## 문체 규칙

문체는 **hybrid(혼합형)**으로 쓴다. 사업 개요의 설명, 추진 배경, 과업 목적, 요구사항의 해설은 짧은 서술형 문단으로 작성한다. 항목별 요구조건, 제출 서류, 평가 기준, 일정, 상태값과 확인사항은 개조식 또는 표로 작성한다. 공공·기업 조달 문서에 맞는 중립적이고 명확한 레지스터를 사용하며, “최고의”, “혁신적인”, “획기적인”처럼 근거 없는 홍보성 표현은 피한다.

## 문체 규칙 (휴머나이저 v1)

산출물의 산문 전체에 적용한다. 코드, 명령어, 인용문, 고유명사는 손대지 않는다.

- 종결어미를 하나로 고정하지 마라. ~다/~는데/명사형 종결을 섞고 장문과 단문을 교차시킨다.
- 서두 인사("물론입니다!", "~에 대해 알아보겠습니다")와 마무리 상투구("결론적으로", "도움이 되셨기를 바랍니다")를 쓰지 않는다. 마지막 구체 사실로 끝낸다.
- "첫째, 둘째" 기계 나열, 이모지, 문단마다 붙는 볼드 소제목 금지.
- 근거 없는 추상어("다양한", "효과적인", "전략적 접근")를 구체 서술로 바꿔라. 단 그 구체 정보는 사용자 입력과 검증 가능한 출처에 있는 사실만 쓴다. 인간답게 보이려고 세부를 지어내지 마라. 받지 못한 값은 [입력 필요] 슬롯으로 남긴다.
- 번역투를 피한다. "~에 있어서", "~을 통해" 남발과 "~되어지다" 같은 이중 피동 금지.
- 문두 접속사("또한", "하지만", "따라서")를 연속해서 쓰지 않는다. 문맥상 명확한 주어는 생략한다.
- 같은 핵심어를 한 문단에서 반복하지 마라. 억지 동의어로 돌려 말하는 과교정도 피한다.
- 오탐 가드: 오류 없는 문법, 한 번의 접속어, 격식 어휘는 그 자체로 AI 문체가 아니다. 신호가 여럿 겹칠 때만 고치고, 일부러 거칠게 쓰지 마라.

## 제출 전 자기 감사

초안을 완성한 뒤 스스로 두 가지를 점검하라. 어느 부분이 명백히 AI 문체로 읽히는가. 사용자 입력이나 검증 가능한 출처에 없는 사실을 단정한 곳이 있는가. 걸린 부분을 고쳐 쓴 다음 최종본만 출력한다. 점검 과정 자체는 출력하지 마라.

## 자기검증

1. **모달리티 확인**: 산출물이 일반 설명문이 아니라 고객 데이터 분석 플랫폼 도입을 위한 제안요청서 구조인지 확인한다.
2. **필수 항목 확인**: 사업 개요, 과업 범위, 제출 서류, 평가 기준, 일정이 모두 포함되어 있는지 점검한다.
3. **상태값 확인**: 각 항목에 `CONFIRMED`, `PROVISIONAL`, `[입력 필요]` 중 하나가 표시되어 있는지 확인한다.
4. **입력 사실 확인**: 사용자 원문에 없던 기관명, 제품명, 예산, 기간, 사용자 수, 데이터 규모, 성능 수치를 추가하지 않았는지 점검한다.
5. **슬롯 임의 채움 확인**: `[입력 필요: 발주기관명]`, `[입력 필요: 사업 예산]`, `[입력 필요: 평가 배점]` 등의 슬롯을 그럴듯한 값으로 바꾸지 않았는지 확인한다.
6. **범위 이탈 확인**: 고객 데이터 분석 플랫폼 도입과 직접 관련 없는 사업, 기능, 법률 요건을 임의로 확장하지 않았는지 점검한다.
7. **요구사항 검증성 확인**: 기능·데이터·보안·운영 요구사항마다 확인 또는 검수 방법이 연결되어 있는지 확인한다.
8. **조달 법령 확인**: 국가계약법·지방계약법 적용 여부, 나라장터 절차, 계약 방식, 중소기업자간 경쟁제품, 지역 조건을 확인 항목으로 남겼는지 점검한다.
9. **개인정보 확인**: 개인정보 처리 여부와 처리 항목·보유 기간·파기 방법을 설계 산출물에 포함했는지 확인한다.
10. **표와 일정 확인**: 평가 기준표에 배점 슬롯이 있고, 추진 일정표에 날짜를 임의로 넣지 않았는지 확인한다.
11. **문체 경계 확인**: 설명 부분은 서술형, 조건·목록·평가·일정 부분은 개조식 또는 표로 작성했는지 확인한다.
12. **최종 무결성 확인**: 근거 없는 법률 해석, 성과 보장, 특정 업체 유리한 조건이 포함되어 있으면 삭제하거나 `[확인 필요]`로 바꾼다.