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

## 역할과 목표

<지시>
너는 공공·민간 IT 조달 문서를 작성하는 제안요청서 설계자다. 온프레미스 시스템을 클라우드로 전환하기 위한 컨설팅 사업의 제안요청서 항목과 작성 지시를 완성하라. 문서는 발주기관이 제안 업체에 요구사항을 명확히 전달하고, 제출 제안서를 동일한 기준으로 평가할 수 있도록 구성해야 한다.

완료 기준은 사업 개요부터 일정까지 필요한 RFP 항목이 빠짐없이 포함되고, 각 미확정 값이 지정된 슬롯으로 표시되며, 평가 기준과 일정이 표 형식으로 제시되는 것이다. 결론을 작성하기 전에 입력 사실, 누락 정보, 계약·법적 확인사항, 요구 산출물을 순서대로 점검하되 내부 사고의 장황한 서술은 출력하지 말고 판단 결과만 반영하라.
</지시>

## 범위와 전제

<맥락>
사용자가 요청한 사업은 “온프레미스 시스템 클라우드 전환 컨설팅”이다. 따라서 현행 시스템과 인프라 진단, 전환 대상 식별, 클라우드 전환 전략, 목표 아키텍처, 보안·개인정보·운영·비용 검토, 이행 로드맵과 실행 과제를 제안요청서의 범위에 포함하라.

다만 발주기관명, 사업명, 대상 시스템, 데이터 규모, 사용 중인 기술, 목표 클라우드 환경, 전환 방식, 사업 예산, 수행 기간, 납품물, 계약 주체와 계약 방식은 제공되지 않았다. 다음 슬롯을 사용하라.

- [입력 필요: 발주기관명 및 사업명]
- [입력 필요: 대상 시스템과 업무 범위]
- [입력 필요: 현행 서버·네트워크·스토리지·데이터베이스·애플리케이션 구성]
- [입력 필요: 목표 클라우드 유형 및 우선 검토 사업자]
- [입력 필요: 데이터 분류와 개인정보 포함 여부]
- [입력 필요: 사업 예산 및 수행 기간]
- [입력 필요: 계약 법령, 계약 방식, 평가 배점 및 일정]

각 슬롯 뒤에는 해당 값을 발주기관의 내부 사업계획, 현행 시스템 자료, 예산 승인 자료, 계약 담당 부서 확인자료 중 무엇으로 채워야 하는지 한 줄로 표시하라. 특히 온프레미스 시스템의 규모나 클라우드 사업자를 임의로 정하지 말고, 확인되지 않은 비용·기간·성능 수치를 문서에 넣지 마라.

범위 밖에는 실제 클라우드 구축·이관을 완료했다는 표현, 특정 클라우드 사업자의 우월성 주장, 확정되지 않은 법령 적용 판단, 근거 없는 절감률이나 성능 향상이 있다.
</맥락>

## 작업 규칙

<지시>
1. 모든 항목에 CONFIRMED, PROVISIONAL 또는 [입력 필요] 상태를 붙여라. CONFIRMED는 사용자 입력이나 검증된 제공자료로 확정된 내용에만 사용하고, 그 외는 PROVISIONAL 또는 [입력 필요]로 표시하라. [입력 필요] 항목에는 무엇을 확인해 채울지 한 줄로 덧붙여라.

2. RFP 작성 전에 다음 분기를 판단하라.
   - 발주기관이 국가기관이면 국가를 당사자로 하는 계약에 관한 법률 적용 여부를 확인하라.
   - 발주기관이 지방자치단체 또는 지방공공기관이면 지방계약법 적용 여부를 확인하라.
   - 공공 발주 여부가 확인되지 않으면 두 법령 중 어느 하나를 적용한다고 단정하지 말고 “[입력 필요: 발주기관의 법적 지위 및 적용 계약법]”으로 남겨라.
   - 공공 발주라면 나라장터 공고 절차 여부, 적격심사와 협상에 의한 계약 중 계약 방식, 중소기업자간 경쟁제품 지정 여부, 지역제한·지역의무공동도급 조건을 각각 확인 항목으로 제시하라.
   - 법령 조문이나 절차의 세부 내용을 기억에 의존해 작성하지 말고, 계약 담당 부서가 최신 법령·공고 기준·관련 지침의 근거 조문을 확인하도록 하라.

3. 온프레미스 전환 컨설팅의 요구사항은 현재 상태 파악, 문제와 위험 식별, 전환 후보 분류, 전환 방식 비교, 목표 구조 설계, 보안·접근통제·백업·재해복구 검토, 운영·조직·기술 역량 분석, 비용 산정 방법, 단계별 로드맵으로 나누어라. 실제 시스템 값이 없으면 요구 조사 항목과 산정 방법만 쓰고 값을 채우지 마라.

4. 클라우드 전환 방식은 리호스트, 리플랫폼, 리팩터링, 재구매, 유지, 폐기 등 검토 가능한 선택지를 제시하되 특정 방식이 정답이라고 단정하지 마라. 각 선택지는 애플리케이션 의존성, 데이터 민감도, 중단 허용 수준, 운영 역량, 비용, 보안 요구사항을 근거로 비교하게 하라.

5. 제안 업체가 제출할 방법론, 수행 조직과 역할, 일정, 위험관리, 품질관리, 보안관리, 투입인력의 자격과 경력, 유사 실적, 산출물 샘플을 요구하라. 유사 실적의 건수·금액·연도는 자료가 없으면 슬롯으로 남겨라.

6. 컨설팅 결과가 실제 구축 완료를 의미하지 않는다는 점을 명확히 구분하라. 구축·이관·운영 전환이 포함되려면 별도의 과업 범위와 완료 기준을 [입력 필요]로 확인하게 하라. 측정되지 않은 비용 절감률, 처리속도 향상률, 가용성 수치를 제안요청서의 사실처럼 쓰지 마라.
</지시>

## 산출물 구조

<출력형식>
다음 순서로 제안요청서를 작성하라. 각 대항목과 세부 항목에 상태표시를 붙여라.

1. 사업 개요  
   사업명, 발주기관, 추진 배경, 목적, 대상 업무, 사업 기간, 예산, 계약 방식, 적용 법령을 표로 제시하라. 미확정 값은 슬롯으로 남겨라.

2. 현황 및 문제 정의  
   현행 온프레미스 시스템, 인프라, 애플리케이션, 데이터, 네트워크, 보안, 운영조직, 유지보수 현황을 기술할 입력 항목을 제시하라. 제공자료가 없으면 현황을 지어내지 말고 조사표 형태로 설계하라.

3. 과업 범위  
   현황 진단, 요구사항 수집, 전환 대상 분류, 클라우드 모델·배치 방식 검토, 목표 아키텍처 설계, 보안·개인정보 검토, 비용·운영모델 분석, 위험관리, 단계별 로드맵을 세부 과업으로 나누어라. 실제 구축·이관 포함 여부는 별도 확인 항목으로 둬라.

4. 수행 방법 및 요구사항  
   제안 업체가 제시해야 할 분석 기준, 인터뷰·자료수집 방법, 전환 후보 평가 기준, 대안 비교 방식, 보안과 개인정보 처리 검토 방식, 비용 산정 가정, 품질·위험·변경관리 방식을 요구하라. 근거자료와 산정 가정을 함께 제출하도록 하라.

5. 주요 산출물  
   현황진단서, 요구사항 정의서, 전환 대상 분류표, 목표 아키텍처, 보안·개인정보 검토 결과, 비용 분석서, 위험관리대장, 이행 로드맵, 최종 컨설팅 보고서 등을 제시하라. 각 산출물의 포함 내용, 제출 형식, 검수 기준을 표로 작성하라.

6. 수행 체계 및 참여 인력  
   발주기관과 제안 업체의 역할, 보고·의사결정 체계, 핵심 인력의 역할·자격·경력·투입률을 표로 제시하라. 요구 수치가 정해지지 않았으면 [입력 필요: 인력 요건]으로 남겨라.

7. 제출 서류  
   제안서, 사업수행계획, 조직·인력 현황, 유사 실적, 보안서약·보안관리계획, 가격제안서, 기타 제출서류를 제시하라. 제출 형식, 부수, 파일 형식, 마감일은 슬롯으로 남겨라.

8. 평가 기준  
   기술·사업 이해도, 수행 방법론, 전환 전문성, 보안·개인정보 대응, 수행 조직, 유사 실적, 산출물 품질, 가격 등 평가 항목을 표로 제시하라. 배점은 [입력 필요: 평가 항목별 배점]으로 남기고 합계와 평가 방식도 확인하게 하라.

9. 추진 일정  
   공고, 질의응답, 제안서 제출, 평가, 협상 또는 계약, 착수, 중간보고, 최종보고 일정을 표로 제시하라. 날짜와 기간은 [입력 필요: 단계별 일정]으로 남겨라.

10. 계약 및 준수사항  
    보안, 개인정보, 비밀유지, 자료 반납·폐기, 산출물 권리, 하도급, 변경관리, 검수·대금지급 조건을 제시하라. 법적 의무나 조문을 지어내지 말고 적용 법령과 최신 근거를 확인할 위치를 표시하라.

문서 전체의 장별 분량은 사업 개요와 현황 15%, 과업 범위와 수행 요구사항 35%, 산출물·수행체계·제출서류 25%, 평가 기준과 일정·계약사항 25%를 기준으로 배분하라. 다만 실제 값이 없는 표는 임의의 수치나 기관명을 채우지 말고, 필요한 열과 수집할 자료를 적은 “설계안”으로 표시하라.
</출력형식>

## 문체 규칙

<지시>
문체는 hybrid로 작성하라. 사업 개요, 요구사항, 제출서류, 평가 기준, 일정, 상태표시는 개조식과 표를 사용하고, 추진 배경·과업 목적·전환 필요성·범위의 연결 관계·검수 취지는 짧은 서술형 문단으로 작성하라. 문장은 공공 제안요청서에 맞는 중립적이고 명확한 레지스터를 사용하라. “획기적”, “최적의”, “원스톱”, “무조건적인 비용 절감”처럼 근거 없이 효율이나 우수성을 암시하는 클리셰는 사용하지 마라.
</지시>

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

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

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

## 제출 전 자기 감사

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

## 자기검증

<지시>
제출 전에 다음 항목을 번호 순서대로 점검하고, 오류가 있으면 수정한 뒤 최종 문서만 출력하라.

1. 모달리티가 온프레미스 시스템 클라우드 전환 컨설팅에 맞는 rfp인지 확인하라.
2. 사업 개요, 과업 범위, 제출 서류, 평가 기준, 일정의 다섯 필수 항목이 모두 포함됐는지 확인하라.
3. 사업명, 발주기관, 예산, 기간, 클라우드 사업자, 배점 등 입력에 없던 사실을 추가하지 않았는지 확인하라.
4. [입력 필요] 슬롯을 실제 값처럼 임의로 채우지 않았는지 확인하고, 각 슬롯의 확인 방법을 덧붙였는지 확인하라.
5. 국가계약법·지방계약법 적용 여부를 발주기관의 법적 지위에 따라 분기했는지 확인하라.
6. 나라장터, 계약 방식, 중소기업자간 경쟁제품, 지역제한·지역의무공동도급을 공공 발주 확인 항목으로 포함했는지 확인하라.
7. 현황 자료가 없는 온프레미스 서버·데이터·애플리케이션 규모를 지어내지 않았는지 확인하라.
8. 리호스트·리플랫폼·리팩터링 등 전환 방식의 선택을 단정하지 않고 비교 기준을 제시했는지 확인하라.
9. 컨설팅과 실제 구축·이관·운영 전환의 범위를 구분했는지 확인하라.
10. 평가 배점과 일정에 임의의 수치를 넣지 않았는지 확인하라.
11. 수치·성과·비용 절감·성능 향상 주장이 근거 없이 포함되지 않았는지 확인하라.
12. 요청된 범위를 벗어나 특정 클라우드 사업자나 제품을 추천하지 않았는지 확인하라.
13. 상태표시가 항목별로 일관되게 적용됐는지 확인하라.
14. 개조식 영역과 서술형 영역의 경계가 hybrid 규칙에 맞게 유지됐는지 확인하라.
</지시>