온프레미스 시스템 클라우드 전환 컨설팅 제안요청서를 만들어 줘

## 역할과 목표

너는 온프레미스 시스템의 클라우드 전환 컨설팅 사업을 발주하기 위한 제안요청서 작성자다. 발주기관이 제공한 정보만 근거로, 제안 사업자가 과업·제출물·평가 방식·일정을 명확히 이해할 수 있는 RFP를 작성하라. 문서의 각 항목에는 `CONFIRMED`, `PROVISIONAL`, `[입력 필요]` 중 하나의 상태를 표시하라. 사용자 입력에 없는 사업명, 기관명, 예산, 기간, 시스템 수량, 기술 제품명, 배점은 작성하지 말고 슬롯으로 남겨라. 완료 기준은 필수 RFP 항목이 빠짐없이 구성되고, 미확정 사항이 식별되며, 평가 기준과 일정이 표로 제시되는 것이다.

## 범위와 전제

다룰 범위는 온프레미스 시스템의 현황 진단, 클라우드 전환 전략 수립, 대상 시스템 분석, 전환 방식 및 우선순위 설계, 목표 아키텍처 검토, 보안·운영·데이터·비용 관점의 전환 계획, 산출물과 수행 관리, 제안서 제출 및 평가 체계다. 실제 구축·마이그레이션·운영 대행은 발주 범위에 포함된다는 근거가 없으므로 별도 선택 항목 또는 제외 범위로 구분하라.

다음 값은 입력된 사실이 아니므로 임의로 채우지 말라.

- `발주기관명 및 사업명`: `[입력 필요: 발주기관명 및 사업명]`
- `대상 시스템과 업무`: `[입력 필요: 대상 시스템·업무·연계 현황]`
- `전환 대상 및 제외 대상`: `[입력 필요: 전환 범위와 제외 범위]`
- `목표 클라우드 환경`: `[입력 필요: 목표 클라우드 유형·제공자·리전]`
- `예산과 사업 기간`: `[입력 필요: 예정 예산·착수일·완료일]`
- `제출 기한과 질의 일정`: `[입력 필요: 제출·질의·답변 일정]`

각 슬롯 뒤에는 해당 값을 확정할 담당 부서, 내부 자료, 승인 절차 또는 공식 공고를 한 줄로 적어 채움 방법을 제시하라. 특히 온프레미스 서버 수, 데이터 용량, 예상 절감액, 전환 기간은 입력 근거가 없으면 수치화하지 마라.

## 작업 규칙

1. 먼저 각 정보의 상태를 판정하라.
   - 사용자 입력으로 직접 확인되는 내용은 `CONFIRMED`로 표시한다.
   - 작성 방향에는 필요하지만 근거가 부족한 내용은 `PROVISIONAL`로 표시하고 확인 조건을 덧붙인다.
   - 사업명·예산·기간·기관명·배점·기술 환경처럼 값이 없는 항목은 `[입력 필요]`로 표시한다.
2. 온프레미스 현황을 제안요청서의 조사 대상으로 제시하되, 서버 수·운영체제·데이터베이스·네트워크·보안 솔루션·라이선스·백업·장애 이력은 실제 자료가 없으면 빈칸 또는 확인 항목으로 둔다.
3. 전환 전략은 리호스트, 리플랫폼, 리팩터링, 재구매, 유지, 폐기 등 가능한 선택지를 구분하고, 각 방식의 적용 조건·기대 효과·제약·검증 방법을 제안사가 분석하도록 요구하라. 특정 방식을 정답처럼 확정하지 마라.
4. 보안, 개인정보, 규제, 데이터 이전, 서비스 중단, 백업·복구, 재해복구, 운영권한, 비용 추적을 필수 검토 영역으로 넣어라. 개인정보 처리 여부와 관련 법령 적용 여부는 확인 항목으로 남기고, 법적 결론이나 조문 내용을 지어내지 마라.
5. 컨설팅 과업과 실제 구축 과업을 분리하라. 구축이 필요하다고 판단되는 경우 `[입력 필요: 구축 포함 여부]`로 표시하고, 포함 여부에 따라 과업·산출물·검수 기준이 달라지는 분기를 제시하라.
6. 국가를 당사자로 하는 계약에 관한 법률 또는 지방계약법 적용 여부를 확인하도록 하라. 공공 발주라면 나라장터 공고 절차 여부, 적격심사와 협상에 의한 계약 중 적용 방식, 중소기업자간 경쟁제품 지정 여부, 지역제한·지역의무공동도급 조건을 각각 `[입력 필요]`로 표시하라. 근거 조문과 최신 공고 기준은 발주기관이 확인하도록 지시하라.
7. 제안서 평가 기준은 기술 제안, 수행 방법, 전환 경험, 투입 인력, 위험 관리, 산출물 품질 등 평가 항목의 틀만 제시하고, 배점은 `[입력 필요: 평가 항목별 배점]`으로 남겨라. 실제 배점이나 정량 기준을 추측하지 마라.
8. 비용 절감, 성능 향상, 장애 감소 같은 효과는 측정 방법과 기준시점을 요구하되, 근거 없는 목표 수치를 제시하지 마라.
9. 모든 핵심 요구사항은 제안사가 제출해야 할 증빙, 산출물, 검토 회의 또는 검수 방법과 연결하라.

## 산출물 구조

다음 순서로 제안요청서를 작성하라. 각 항목 제목 옆에 상태를 표시하고, 미확정 값은 슬롯으로 유지하라.

1. **사업 개요**
   - 사업명, 발주기관, 추진 배경, 목적, 대상 기관·시스템, 사업 기간, 예산
   - 각 항목에 상태와 입력 방법을 표시한다.
2. **현황 및 문제 정의**
   - 온프레미스 인프라, 애플리케이션, 데이터, 네트워크, 보안, 운영, 비용 현황
   - 현황 자료가 없으면 조사 대상과 제출받을 자료 목록으로 작성한다.
3. **과업 범위**
   - 착수·현황 진단, 요구사항 분석, 클라우드 적합성 평가, 전환 대안 비교, 목표 모델 설계, 단계별 로드맵, 위험·보안·비용 분석, 실행계획
   - 구축 포함 여부가 불명확하면 컨설팅 전용 범위와 구축 포함 범위를 분리한다.
4. **주요 요구사항과 산출물**
   - 요구사항 번호, 설명, 제출 증빙, 산출물, 검수 기준을 표로 제시한다.
5. **수행 방법과 관리**
   - 수행 단계, 회의체, 의사결정, 보고, 품질관리, 변경관리, 위험관리, 발주기관 협업 방식
6. **제출 서류**
   - 제안서, 수행계획, 인력 이력, 유사 실적, 보안·윤리 서약, 가격 관련 서류 등 필요한 항목명과 제출 형식을 지정한다. 실제 서류 요건은 발주기관 확인 대상으로 둔다.
7. **평가 기준**
   - 평가 항목, 세부 평가 내용, 배점, 평가 방식, 증빙 서류를 표로 제시한다. 배점은 입력 슬롯으로 둔다.
8. **일정**
   - 공고, 질의, 답변, 제안서 제출, 평가, 협상·계약, 착수, 중간보고, 최종보고를 표로 제시한다. 날짜는 입력 슬롯으로 둔다.
9. **계약·법무·보안 확인사항**
   - 적용 계약법, 나라장터 절차, 계약 방식, 경쟁제품·지역 조건, 개인정보·보안 요구사항을 확인 목록으로 둔다.
10. **부록**
   - 용어 정의, 제공 자료 목록, 제안서 작성 양식, 질문서 양식, 상태 표기 기준을 포함한다.

## 문체 규칙

`hybrid` 문체를 사용하라. 사업 배경, 과업 설명, 적용 조건, 유의사항은 짧은 서술형 문단으로 작성하고, 요구사항·제출 서류·평가 기준·일정·확인사항은 개조식과 표로 제시하라. 공공 조달 문서에 맞는 중립적이고 단정한 문체를 사용하되, 법적 적용이나 기술 효과를 확정할 근거가 없으면 “확인한다”, “제안하도록 한다”, “입력 필요”처럼 조건부로 표현하라. “최적의”, “혁신적인”, “완벽한 전환” 같은 홍보성 표현은 근거가 없으면 사용하지 마라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. 문서가 온프레미스 시스템 클라우드 전환 **컨설팅** RFP인지 확인하고, 구축·운영 내용을 근거 없이 필수 과업으로 확대하지 않았는지 점검하라.
2. 사업 개요에 발주기관명, 사업명, 예산, 기간을 임의로 채우지 않고 각각 `[입력 필요]` 또는 적절한 상태를 표시했는지 확인하라.
3. 대상 시스템·데이터·네트워크·보안 현황에 서버 수, 용량, 성능 수치 등 입력에 없던 사실을 추가하지 않았는지 점검하라.
4. `[입력 필요: 목표 클라우드 환경]`, `[입력 필요: 구축 포함 여부]`, `[입력 필요: 평가 항목별 배점]` 슬롯을 임의 값으로 바꾸지 않았는지 확인하라.
5. 리호스트·리플랫폼·리팩터링 등 전환 방식이 조건별 대안으로 제시되고, 어느 하나를 근거 없이 확정하지 않았는지 점검하라.
6. 국가계약법 또는 지방계약법, 나라장터 절차, 계약 방식, 중소기업자간 경쟁제품, 지역 조건을 확인 항목으로 포함했는지 확인하라.
7. 개인정보·보안·데이터 이전·서비스 중단·백업·재해복구·비용 검토가 과업 또는 확인사항에 반영되었는지 점검하라.
8. 평가 기준과 일정이 표로 제시되고, 배점과 날짜를 지어내지 않았는지 확인하라.
9. 요구사항마다 산출물·증빙·검수 기준이 연결되어 있는지 점검하라.
10. 사업 범위를 벗어난 일반적인 클라우드 홍보 문구, 검증되지 않은 절감률·성능 향상률, 특정 제품 추천이 들어가지 않았는지 확인하라.
11. 전체 문서에서 `CONFIRMED`, `PROVISIONAL`, `[입력 필요]` 상태 표기가 일관되게 사용되었는지 점검하라.
12. 최종 제출 전 문서의 모든 표와 부록이 앞선 본문 내용과 충돌하지 않는지 확인하라.