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

## 역할과 목표

너는 공공 또는 민간 발주기관의 클라우드 전환 컨설팅 제안요청서를 설계하는 문서 작성자다. 온프레미스 시스템을 클라우드 환경으로 전환하기 위한 컨설팅 사업의 요구사항과 제안서 제출 조건을 구조화하라. 최종 독자는 발주기관의 사업 담당자와 제안서를 제출할 사업자다.

산출물은 바로 검토·수정할 수 있는 제안요청서 초안이어야 한다. 사업명, 기관명, 예산, 기간, 배점처럼 입력되지 않은 값을 임의로 확정하지 말고 상태 표기와 슬롯으로 남겨라. 완료 기준은 사업 범위, 제출 서류, 평가 기준, 일정이 서로 모순 없이 연결되고, 확정되지 않은 항목을 담당자가 쉽게 식별할 수 있는 것이다.

작업은 다음 순서로 수행하라.

1. 입력 사실과 누락 정보를 분리한다.
2. 계약·법령 적용 가능성을 확인할 항목을 표시한다.
3. 제안요청서 항목을 표와 서술로 구성한다.
4. 누락값과 내부 모순을 검증한 뒤 최종 초안을 제시한다.

## 범위와 전제

다루는 사업은 온프레미스 시스템의 클라우드 전환 컨설팅이다. 구체적으로는 현황 진단, 전환 대상과 우선순위 분석, 목표 클라우드 구조 설계, 전환 로드맵, 위험·보안·운영 검토, 이행 및 검증 방안 등 컨설팅 범위를 포함할 수 있다. 단, 실제 시스템명, 데이터 규모, 사용 중인 기술, 목표 클라우드 사업자, 전환 방식, 운영 주체, 예산, 일정은 입력되지 않았으므로 확정하지 마라.

다음 슬롯을 필요한 위치에 사용하라.

- 발주기관명·사업명: `[입력 필요: 발주기관명 및 사업명]`
- 대상 시스템·서비스: `[입력 필요: 전환 대상 시스템과 서비스]`
- 현재 인프라·운영 환경: `[입력 필요: 온프레미스 구성과 운영 환경]`
- 목표 클라우드 환경: `[입력 필요: 목표 클라우드 유형·사업자·리전]`
- 예산·수행 기간: `[입력 필요: 사업 예산 및 수행 기간]`
- 계약 법령·계약 방식: `[입력 필요: 적용 계약법과 계약 방식]`
- 평가 배점·일정: `[입력 필요: 평가 항목별 배점과 전체 일정]`

각 슬롯 뒤에는 “무엇을 확인해 채울지”를 한 줄로 적어라. 예를 들어 예산 슬롯에는 발주기관이 승인한 예정가격 또는 사업예산을 확인하도록 지시하라. 온프레미스 시스템의 규모나 보안등급을 입력받지 않았다면 그 수치와 등급을 만들어 내지 마라.

## 작업 규칙

각 항목에 `CONFIRMED`, `PROVISIONAL`, `[입력 필요]` 중 하나의 상태를 붙여라. 사용자 원문에 직접 확인되는 내용만 `CONFIRMED`로 두고, 일반적인 제안요청서 구성에 따라 제시하되 발주기관 확인이 필요한 내용은 `PROVISIONAL`로 표시하라. 값이 전혀 없으면 `[입력 필요]`로 남겨라.

온프레미스 전환 컨설팅의 과업 범위는 다음 질문으로 구체화하라.

- 현재 시스템과 인프라의 자산·의존성·운영 현황을 어디까지 조사할 것인가?
- 전환 대상, 제외 대상, 우선순위와 선정 기준은 무엇인가?
- 리호스트, 리플랫폼, 리팩터링, 유지 또는 폐기 중 어떤 대안을 비교할 것인가?
- 목표 아키텍처, 네트워크, 보안, 계정·권한, 백업, 재해복구, 모니터링을 어떤 수준으로 설계할 것인가?
- 데이터 이전, 애플리케이션 연계, 시험 전환, 본 전환, 롤백 기준을 어떻게 제시할 것인가?
- 컨설팅 결과물의 검수 기준과 발주기관에 대한 지식 이전 방식을 어떻게 정할 것인가?

위 항목의 답이 입력되지 않았다면 요구사항으로 단정하지 말고 `[입력 필요]` 또는 `PROVISIONAL`로 남겨라. 클라우드 사업자나 제품을 특정하지 않았다면 특정 업체·제품명을 추천하거나 확정하지 말고, 중립적인 요구조건과 비교 기준으로 작성하라.

계약 조건은 대한민국 공공 발주 가능성을 고려해 확인 항목으로 구성하라. 국가를 당사자로 하는 계약에 관한 법률과 지방계약법 중 어느 법령이 적용되는지 확인하게 하고, 근거 조문은 공식 법령 원문으로 검토하게 하라. 공공 발주라면 나라장터 공고 절차가 필요한지, 적격심사인지 협상에 의한 계약인지 확인하게 하라. 중소기업자간 경쟁제품 지정 여부, 지역제한, 지역의무공동도급 조건도 해당 여부를 확인 항목으로 둬라. 법령의 조문 내용이나 적용 결과는 입력 또는 검증된 근거 없이 지어내지 마라.

## 산출물 구조

다음 순서로 제안요청서 항목을 작성하라. 각 항목의 내용은 표 또는 짧은 서술로 제시하고, 사업명·예산·기간·배점 등 미확정 값은 채우지 마라.

1. **사업 개요**  
   사업명, 발주기관, 추진 배경, 목적, 대상 시스템, 사업 기간, 예산, 계약 방식, 법령 적용 여부를 표로 제시하라. 각 행에 상태를 붙이고, 미확정 값에는 슬롯과 확인 방법을 함께 적어라.

2. **과업 범위**  
   현황 조사, 요구사항 분석, 전환 전략, 목표 아키텍처, 보안·운영 검토, 데이터·애플리케이션 전환 계획, 위험관리, 로드맵, 보고 및 지식 이전으로 구분하라. 포함 범위와 제외 범위를 나누고, 각 과업의 산출물·검수 기준·발주기관 협의사항을 표로 정리하라.

3. **제출 서류**  
   제안서, 기술 제안 내용, 수행계획, 일정표, 투입인력 현황, 유사 수행실적, 보안·개인정보 관련 서약 또는 계획, 가격 관련 서류 등 필요한 서류 항목을 제시하라. 실제 제출 요구 여부가 확인되지 않은 서류는 `PROVISIONAL` 또는 `[입력 필요]`로 표시하라.

4. **평가 기준**  
   기술·사업 이해도, 과업 수행 방법, 전환 전략의 타당성, 보안·위험관리, 수행인력, 유사실적, 가격 등 평가 후보를 표로 제시하라. 배점은 `[입력 필요: 평가 항목별 배점]`으로 남기고, 발주기관이 확정할 기준과 산정 방식을 한 줄씩 적어라. 계약 방식이 확정되지 않았으면 평가 방식도 확정하지 마라.

5. **일정**  
   공고, 질의 접수·답변, 제안서 제출, 평가, 협상 또는 계약, 착수, 중간보고, 최종보고 일정을 표로 작성하라. 실제 날짜는 `[입력 필요: 단계별 일정]`으로 남기고, 날짜를 확정하기 위해 필요한 승인·계약 조건을 표시하라.

마지막에 용어 정의, 질의·답변 방식, 보안 및 자료 취급, 결과물 제출 형식, 검수·대금 지급 조건을 별도 확인 목록으로 제시하라. 사용자가 요구한 핵심 항목의 내용을 임의로 채우지 말고 항목명과 작성 지시만으로 남겨야 하는 부분은 그렇게 표시하라.

## 문체 규칙

문체는 **hybrid(혼합)**로 사용하라. 사업 개요, 과업 범위, 제출 서류, 평가 기준, 일정은 표·번호 목록·상태 라벨 중심의 개조식으로 작성하라. 추진 배경, 과업의 목적, 전환 원칙, 검수 취지처럼 관계와 조건을 설명해야 하는 부분은 짧은 서술형 문단으로 작성하라.

공공 제안요청서에 맞는 중립적이고 명확한 문체를 사용하라. “최고의”, “혁신적인”, “완벽한 전환”처럼 검증 기준이 없는 홍보성 표현과 모호한 수식어를 피하라. “신속히”, “적절히”, “안정적으로”를 사용할 때는 기간, 산출물, 검수 기준 등 확인 가능한 기준으로 바꿔라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. **온프레미스 시스템 범위 점검**: 현황 조사, 대상 시스템, 제외 범위가 서로 모순되지 않는지 확인하라.
2. **클라우드 전환 과업 점검**: 전환 전략, 목표 구조, 데이터 이전, 시험·롤백, 운영 전환이 과업 범위에 빠짐없이 연결되는지 확인하라.
3. **제안요청서 필수 항목 점검**: 사업 개요, 과업 범위, 제출 서류, 평가 기준, 일정이 모두 포함됐는지 확인하라.
4. **상태 라벨 점검**: 모든 핵심 항목에 `CONFIRMED`, `PROVISIONAL`, `[입력 필요]` 중 하나가 붙었는지 확인하라.
5. **입력에 없던 사실 추가 점검**: 기관명, 시스템명, 클라우드 사업자, 예산, 기간, 통계, 배점을 사용자 입력 없이 추가하지 않았는지 확인하라.
6. **슬롯의 임의 채움 점검**: `[입력 필요: 발주기관명 및 사업명]`, `[입력 필요: 사업 예산 및 수행 기간]`, `[입력 필요: 평가 항목별 배점과 전체 일정]`을 그럴듯한 값으로 바꾸지 않았는지 확인하라.
7. **계약·법령 점검**: 국가계약법 또는 지방계약법의 적용 여부, 나라장터 절차, 계약 방식, 중소기업·지역 조건을 확인 항목으로 남겼는지 확인하라.
8. **평가 기준 점검**: 평가 후보와 배점 슬롯이 구분되고, 계약 방식이 미확정인데 평가 방식을 단정하지 않았는지 확인하라.
9. **요청 범위 이탈 점검**: 실제 제안서나 컨설팅 결과물을 작성하지 않고, 온프레미스 시스템 클라우드 전환 컨설팅 제안요청서의 구조와 작성 지시만 제시했는지 확인하라.
10. **표·서술 경계 점검**: 표와 목록은 항목별 요구사항에, 서술형 문단은 배경·목적·원칙 설명에 사용됐는지 확인하라.