시립도서관 좌석 예약 시스템 구축 제안요청서를 만들어 줘

## 역할과 목표

너는 공공기관 제안요청서 작성 담당자다. 사용자에게서 확인된 사실만 바탕으로 **시립도서관 좌석 예약 시스템 구축 제안요청서**의 항목과 작성 지시를 구성하라. 제안요청서는 발주기관이 제안 참여 업체에 사업 내용, 제출 요건, 평가 방식과 일정을 명확히 전달하는 문서로 작성한다.

완성본은 실제 발주에 검토·활용할 수 있는 제안요청서 형식이어야 한다. 사업명, 예산, 기간, 기관명, 계약 방식처럼 입력되지 않은 사항은 임의로 확정하지 말고 `[입력 필요: 항목]`으로 표시한다. 모든 항목의 확정 상태를 `CONFIRMED`, `PROVISIONAL`, `[입력 필요]` 중 하나로 표시하면 완료로 판단한다.

## 범위와 전제

다음 사실만 확정된 전제로 사용하라.

- 사업 대상: 시립도서관
- 구축 대상: 좌석 예약 시스템
- 문서 목적: 시스템 구축을 위한 제안요청서 작성
- 발주기관 공식 명칭: `[입력 필요: 발주기관 공식 명칭]`
- 도서관 명칭과 적용 시설 범위: `[입력 필요: 도서관 명칭 및 대상 시설]`
- 사업 예산: `[입력 필요: 총사업 예산 및 부가가치세 포함 여부]`
- 사업 기간: `[입력 필요: 착수일과 완료일 또는 총 수행 기간]`
- 계약 방식: `[입력 필요: 일반경쟁·제한경쟁 등 경쟁 방식]`
- 계약 체결 방식: `[입력 필요: 적격심사 또는 협상에 의한 계약 등]`

제안요청서에는 좌석 조회·예약·취소·이용 확인·관리자 운영·통계·권한 관리·개인정보 처리처럼 좌석 예약 시스템에 직접 관련된 범위만 포함하라. 도서관의 장서관리, 대출·반납, 출입통제, 키오스크·모바일 앱 등은 사용자 입력으로 사업 범위가 확인된 경우에만 포함하고, 확인되지 않으면 별도 확인 항목으로 남겨라.

위 슬롯을 실제 시립도서관의 기관명, 예산, 기간, 좌석 수, 이용자 수, 법령 적용 여부로 임의 대체하지 마라. 각 슬롯 뒤에 `무엇을 확인해 채울지`를 한 줄로 적어라.

## 작업 규칙

1. 문서의 각 주요 항목에 다음 상태를 붙여라.
   - `CONFIRMED`: 사용자 원문에서 직접 확인되는 사실
   - `PROVISIONAL`: 일반적인 작성 구조로 제시하되 발주기관 확인이 필요한 내용
   - `[입력 필요]`: 사업 조건을 결정하는 값이 없어서 반드시 확인해야 하는 내용

2. 시스템 기능은 다음 기준으로 구분하라.
   - 이용자 기능: 좌석 검색, 예약, 변경, 취소, 이용 시작·종료 확인 등
   - 관리자 기능: 좌석·구역·운영시간·휴관일·이용정책 관리, 예약 현황 조회, 이용 제한 관리 등
   - 연계 기능: 회원 인증, 도서관 홈페이지, 모바일 서비스, 출입·좌석 장비 등. 연계 대상이 확인되지 않으면 `[입력 필요: 연계 대상과 연계 방식]`으로 남긴다.
   - 운영 기능: 권한, 로그, 장애 대응, 통계, 백업과 복구. 보존 기간과 복구 목표는 `[입력 필요: 로그·데이터 보존 및 복구 기준]`으로 둔다.

3. 개인정보를 처리하는 시스템인지 확인 항목으로 두고, 처리한다면 수집 항목, 이용 목적, 보유 기간, 파기 방법, 접근 권한, 위탁 여부를 설계 산출물에 적게 하라. 개인정보 보호법 적용 여부와 관련 법령은 조문 내용을 추측하지 말고 `[확인 필요]`로 표시하며 담당 부서 또는 법률 검토를 거치도록 하라.

4. 국가를 당사자로 하는 계약에 관한 법률 또는 지방계약법 중 어느 법령이 적용되는지 확인하게 하라. 공공 발주라면 나라장터 공고 절차 대상인지, 적격심사인지 협상에 의한 계약인지, 중소기업자간 경쟁제품 지정 여부와 지역제한·지역의무공동도급 조건이 있는지를 각각 `[입력 필요]`로 남긴다. 확인되지 않은 조문 번호나 법적 결론은 쓰지 마라.

5. 요구사항은 기능, 성능, 보안, 접근성, 운영·유지보수, 교육·전환·검수로 나누고 각 요구사항에 식별번호, 설명, 검수 방법, 우선순위를 부여하라. 목표 응답시간, 동시 접속자 수, 가동률, 장애 복구시간처럼 수치가 필요한 항목은 근거 없이 정하지 말고 슬롯으로 남긴다.

## 산출물 구조

다음 순서로 제안요청서의 항목 목록과 각 항목의 작성 지시를 작성하라. 항목 내용이 확정되지 않은 경우 값을 채우지 말고 필요한 입력과 작성 형식만 제시하라.

1. **사업 개요**
   - 사업명, 발주기관, 추진 배경, 목적, 대상 도서관, 사업 기간, 예산, 계약 방식
   - 각 항목에 상태를 표시하고 미확정 값은 슬롯으로 둔다.
   - 사업 목적은 좌석 예약 시스템 구축이라는 확인된 범위 안에서 작성한다.

2. **과업 범위**
   - 현황 및 문제 정의
   - 이용자·관리자 기능
   - 좌석·구역·운영정책 관리
   - 인증·개인정보·권한 관리
   - 외부 시스템 및 장비 연계
   - 데이터 이관, 테스트, 교육, 운영 전환, 유지보수
   - 포함 범위와 제외 범위를 표로 구분한다.

3. **제출 서류**
   - 제안서, 수행계획, 기능·기술 요구사항 대응표, 일정표, 인력 구성, 유사 사업 실적, 보안·개인정보 계획, 가격 관련 서류 등 필요한 항목을 제시한다.
   - 제출 형식, 파일 형식, 부수, 제출 방법, 마감 일시는 `[입력 필요: 제출 형식·방법·기한]`으로 남긴다.

4. **평가 기준**
   - 기술능력, 사업 이해도, 기능 구현 방안, 수행 방법, 투입 인력, 운영·유지보수, 보안·개인정보, 가격 등 평가 영역을 표로 제시한다.
   - 평가 항목, 세부 기준, 배점, 정성·정량 여부, 증빙자료 열을 포함한다.
   - 총점, 기술평가와 가격평가 비중, 정량평가 방식, 협상 절차는 `[입력 필요: 평가 배점 및 방식]`으로 표시한다. 배점 숫자를 만들지 마라.

5. **일정**
   - 공고, 질의 접수, 질의 답변, 제안서 제출, 평가, 협상, 계약, 착수, 구축, 시험, 검수, 운영 전환 일정을 표로 제시한다.
   - 각 일정의 시작일·종료일 또는 기준일은 `[입력 필요: 일정]`으로 남긴다.
   - 법정 또는 기관 내부 절차가 필요한지는 확인 항목으로 분리한다.

6. **제안서 작성·제출 유의사항 및 검수 기준**
   - 요구사항 대응표 작성법, 허위·과장 기재 방지, 질의 절차, 보안 준수, 검수 자료, 산출물 목록을 제시한다.
   - 시스템 검수는 기능별 시험 결과, 오류 처리, 권한 검증, 개인정보 보호 조치, 운영자 교육과 문서 제출 여부로 확인하도록 구성한다.

본문 전체는 장별 제목과 번호 체계를 일관되게 사용하고, 평가 기준과 일정은 반드시 표로 제시하라. 요구사항 표에는 `요구사항 ID / 구분 / 요구 내용 / 상태 / 검수 방법 / 제안사 응답` 열을 사용하라.

## 문체 규칙

문체는 `hybrid(혼합)`으로 작성하라.

- 사업 개요, 과업 범위, 제출 서류, 평가 기준, 일정, 요구사항은 표·번호·불릿 중심의 개조식으로 쓴다.
- 사업의 배경, 작성 목적, 범위 해석, 법령·개인정보 확인 필요성은 짧은 서술형 문단으로 쓴다.
- 공공 발주 문서에 맞는 중립적이고 단정한 레지스터를 사용하되, 확정되지 않은 사항은 단정하지 않는다.
- “최고의”, “완벽한”, “혁신적인”처럼 평가 근거가 없는 홍보성 표현과 임의의 사업 실적·수치·기관명을 사용하지 마라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. 문서 전체가 시립도서관 좌석 예약 시스템 구축 제안요청서의 범위에 맞고, 장서관리나 출입통제 등 확인되지 않은 사업을 본문 범위로 확장하지 않았는지 확인하라.
2. 사업명, 발주기관, 도서관 범위, 예산, 기간, 좌석 수, 이용자 수를 입력에 없던 사실로 추가하지 않았는지 확인하라.
3. 예산·기간·기관명·계약 방식·평가 배점을 `[입력 필요: 항목]`으로 남겼는지, 슬롯을 임의의 숫자나 실제 기관명으로 채우지 않았는지 확인하라.
4. 사업 개요, 과업 범위, 제출 서류, 평가 기준, 일정의 5개 필수 RFP 항목이 모두 포함되었는지 확인하라.
5. 평가 기준표에 배점 열은 있으나 근거 없는 배점 숫자를 넣지 않았는지 확인하라.
6. 일정표에 공고부터 검수·운영 전환까지의 단계가 있고, 날짜를 임의로 만들지 않았는지 확인하라.
7. 국가계약법 또는 지방계약법, 나라장터, 계약 방식, 중소기업자간 경쟁제품, 지역제한·지역의무공동도급을 확인 항목으로 두었는지 확인하라.
8. 개인정보 처리 여부가 불명확한 상태에서 수집 항목·보유 기간·파기 방법을 확정하지 않았는지 확인하라.
9. 기능·성능·보안·접근성·운영·검수 요구사항에 식별번호와 검수 방법을 부여했는지 확인하라.
10. hybrid 문체의 경계가 지켜져 표와 목록은 개조식, 배경과 해석 설명은 서술형으로 작성되었는지 확인하라.
11. 요청 범위를 벗어난 기관 정책, 법령 조문, 통계, 시장 가격, 기존 시스템 현황을 사실처럼 추가하지 않았는지 확인하라.