douinc 정부·지자체 발주 문서 작성
Overview
정부·지자체·공공기관이 사업자를 모집하고 과업을 통제하기 위해 작성하는 한국어 입찰공고서, 제안요청서, 과업내용서, 시스템 구축 RFP를 발주기관 관점에서 작성한다. 목표는 사업자의 홍보성 제안서가 아니라, 입찰자가 동일한 조건에서 범위·요건·제출물·평가·계약조건을 이해하고 발주기관이 제안서를 공정하게 비교할 수 있는 문서를 만드는 것이다.
이 스킬은 /home/dou/procurement_research_2023_2026의 응급의료 관련 공고서·제안요청서·시스템 구축 RFP를 분석해 정리한 패턴을 따른다. 기관별 서식과 최신 법령·예규가 우선하며, 아래 구조는 초안 작성용 기준으로 사용한다.
When to Use
- 정부·지자체·공공기관 명의의 입찰공고서 작성 또는 개정
- 협상에 의한 계약 방식의 제안요청서 작성
- 용역 과업내용서, 연구용역 RFP, 홍보대행 RFP, 정보화·시스템 구축 RFP 작성
- 기존 발주 문서의 목차·문체·요구사항 구조 분석
- 민간 제안서가 아닌 발주기관의 요구사항 문서를 작성해야 하는 경우
Do not use this as the primary skill for:
- 사업자 측 제안서의 설득 논리나 컨소시엄 구성만 설계하는 작업
- 법률 판단이나 최신 계약법령의 확정적 해석
- 실제 평가위원의 점수 예측
Core Principle
공고는 참가·제출·계약 절차를 확정하고, 제안요청서는 평가 가능한 요구사항을 제시하며, 과업내용서는 수행 범위와 산출물을 확정한다. 세 문서의 역할을 섞지 않는다.
작성 순서는 다음과 같다.
- 사업의 행정적 사실을 확정한다.
- 발주기관이 해결하려는 문제와 기대 결과를 정리한다.
- 과업을 업무·기능·산출물 단위로 쪼갠다.
- 수행 조건·보안·품질·보고·검수 기준을 붙인다.
- 평가항목과 요구사항이 일대일로 연결되는지 확인한다.
- 참가자격·제출서류·일정·예산·계약조건을 공고문과 대조한다.
Document Types and Boundaries
1. 입찰공고서
입찰에 참여할 수 있는 사람, 입찰 방법, 기간, 예산, 제출 장소, 낙찰자 결정방법 등 절차와 법적 고지를 담는다. 상세 기능·업무 방법은 “제안요청서 참조”로 연결한다.
권장 목차:
- 입찰에 부치는 사항
- 입찰참가자격
- 입찰보증금 납부 및 귀속
- 입찰 및 개찰
- 공동계약 또는 공동수급
- 낙찰자 결정방법
- 제출서류 및 접수처
- 입찰의 무효
- 청렴계약 및 계약조건
- 기타 유의사항
- 문의처
필수 사실:
- 공고번호, 공고일, 기관명·담당자
- 입찰건명, 사업기간, 사업예산 및 부가가치세 포함 여부
- 입찰·계약 방식: 제한/일반경쟁, 총액/협상에 의한 계약 등
- 나라장터 업종·세부품명·등록기한 등 참가 요건
- 중소기업·소상공인 확인서 등 적용 요건
- 공동수급·하도급 허용 여부
- 제안서·가격입찰서·산출내역서의 제출 방식과 수량
- 접수 마감 시각과 우편 도착 기준
- 기술평가/가격평가 비율, 협상적격자 기준, 동점 처리
- 예산 초과 제안의 처리
2. 제안요청서
입찰자가 제안서를 작성할 수 있도록 사업 배경, 목적, 범위, 요구사항, 제안서 작성·평가 기준을 제시한다.
권장 목차:
- 사업 개요
- 사업명, 기간, 예산, 추진방식
- 추진 배경 및 필요성
- 사업 목적 및 목표
- 현황 및 문제점
- 제안 요청 내역
- 전체 과업
- 세부 과업/기능
- 추진 방법
- 수행 체계 및 역할
- 추진 일정 및 단계별 계획
- 산출물 및 보고·검수
- 품질·성과·KPI 관리
- 보안·개인정보·저작권·안전 요구사항
- 제안서 작성 지침
- 제안서 제출 방법 및 서식
- 제안서 평가 기준
- 계약 및 기타 유의사항
- 붙임 서식
3. 과업내용서
제안요청서보다 수행 내용에 집중한다. “무엇을 언제까지 어떤 수준으로 납품해야 하는가”가 중심이다. 연구용역이면 조사설계·분석·자문·보고서·발표를, 홍보용역이면 채널·콘텐츠·캠페인·행사·성과보고를, 시스템 구축이면 업무·기능·기술·운영·보안 요구사항을 명확히 한다.
4. 시스템 구축 RFP
일반 용역보다 구조화 수준을 높인다.
권장 목차:
- 사업 개요
- 업무 및 시스템 현황
- 사업 추진 방안
- 목표 시스템 및 서비스 구성
- 기능 요구사항
- 데이터 요구사항
- 인터페이스·연계 요구사항
- 성능·품질 요구사항
- 보안·개인정보·접근권한·감사로그 요구사항
- 프로젝트 관리 요구사항
- 교육·기술이전·유지관리·하자보수
- 시험·검수·전환·운영지원
- 산출물 목록 및 제출 형식
- 제안서 평가 기준
기능 요구사항은 가능하면 요구사항 ID / 요구사항명 / 요구사항 설명 / 우선순위 / 검수기준 / 산출물로 관리한다.
Government-Agency Viewpoint
문서 전체에서 주어는 대체로 “발주기관”, “우리 원”, “본 사업”, “수행기관”으로 통일한다. 사업자를 칭찬하거나 시장을 설득하지 말고, 공익과 행정 목적을 먼저 제시한다.
배경 서술 순서
- 정책·제도·사회적 변화
- 현장 문제 또는 서비스 공백
- 현재 운영체계의 한계
- 발주기관이 추진하는 개선 방향
- 이번 사업이 해결해야 할 구체적 과업
- 기대되는 공공서비스 개선
시스템 구축 RFP의 전형적인 논리는 다음과 같다.
국민 안전·필수서비스의 중요성 → 현장 지연·분절·정보 부족 → 기존 체계의 기능적 한계 → 정책에 따른 신규 체계 필요 → 시스템 구축 과업 → 신속성·연계성·환자/국민 안전 향상
목적과 목표 구분
- 목적: 왜 이 사업을 추진하는지. 정책·공공서비스 차원의 상태 변화로 쓴다.
- 목표: 계약기간 안에 무엇을 구축·수행·제출할지. 측정 가능하거나 검수 가능한 문장으로 쓴다.
나쁜 예: “혁신적인 시스템을 구축한다.”
좋은 예: “다기관 간 접수·배정·이송 정보를 단일 화면에서 조회·관리할 수 있는 운영체계를 구축하고, 단계별 시험과 사용자 검수를 거쳐 운영에 적용한다.”
Outline and Requirement Design
Requirement decomposition
각 과업을 다음 순서로 분해한다.
- 대상 사용자 또는 수혜자
- 업무 상황과 시작 조건
- 입력 정보
- 수행 기능/서비스
- 연계기관·담당자
- 출력물·처리 결과
- 처리 주기와 기한
- 예외·장애·민원 상황
- 성과 또는 검수 기준
“지원한다”, “강화한다”, “효율화한다”처럼 검증 불가능한 동사만 남기지 않는다. 필요한 경우 아래처럼 바꾼다.
- “관리 강화” → “월 1회 운영현황을 집계하고, 이슈·조치상태·담당자·기한을 포함한 보고서를 제출한다.”
- “사용자 편의 개선” → “주요 사용자 시나리오 5종에 대해 사용성 점검을 실시하고 개선 결과를 반영한다.”
- “신속한 연계” → “접수 후 담당기관 통보, 처리상태 갱신, 완료 확인의 각 단계와 기록 항목을 정의하고 이력을 저장한다.”
Scope boundary
반드시 포함할 것:
- 수행기관이 직접 해야 하는 일
- 발주기관이 제공하는 자료·권한·환경
- 제3자·연계기관 협조가 필요한 사항
- 제외 범위 또는 별도 협의 범위
- 변경·추가 요구의 처리 방식
특히 시스템 사업에서는 개발 범위와 운영·인프라·장비·EMR/HIS·통신·라이선스 책임을 분리해 적는다. “필요 장비 일체” 같은 포괄 문구는 책임 분쟁을 만들므로 장비 목록, 수량, 설치 위치, 유지관리 주체를 별도로 기재한다.
Deliverables
산출물은 산출물명 / 제출시기 / 수량·형식 / 주요 내용 / 검수 주체로 작성한다. 예:
- 착수계획서: 계약 후 10일 이내, PDF 및 원본, 추진체계·일정·위험관리 포함
- 중간보고서: 중간점검 전, 수행현황·이슈·보완계획 포함
- 시범운영 결과보고서: 시범운영 종료 후, 사용현황·오류·개선결과 포함
- 최종보고서: 종료 10일 전 초안, 검수 후 최종본
- 교육자료·매뉴얼: 운영 개시 전, 사용자·관리자용 분리
- 소스·설계·데이터 사전·시험성적서: 검수 시, 발주기관이 정한 원본 형식
날짜는 다른 본문과 충돌하지 않도록 상대기한 또는 절대기한 중 한 방식을 선택해 통일한다.
Korean Public-Sector Style
문체
- 객관적·행정적·명령형에 가까운 건조한 문체
- “
한다”, “하여야 한다”, “을 원칙으로 한다”, “을 준수하여야 한다”를 요구사항에 사용 - “
하고자 함”, “필요”, “참조”, “에 따른다”를 고지·설명에 사용 - 한 문장에 한 요구사항을 담고, 긴 문장은 항목·하위항목으로 분리
- 용어는 최초에 정의하고 이후 동일한 표현을 사용
- 기관명·법령명·시스템명·약어의 띄어쓰기와 표기를 고정
표기와 번호
문서 유형에 따라 다음 계층을 사용한다.
- 큰 장:
Ⅰ.,Ⅱ.,Ⅲ.또는1.,2.,3. - 중간 항목:
가.,나.,다. - 하위 항목:
1),2),3)또는○ - 세부 불릿:
- - 주의·예외:
※
한 문서 안에서 번호 체계를 혼합할 수 있지만, 같은 수준의 항목에는 동일한 기호를 사용한다. 표는 설명보다 우선하여 구분 / 내용 / 비고 또는 요구사항 ID 중심으로 작성한다.
자주 쓰는 문장 패턴
- “본 사업은 ○○을 위하여 추진한다.”
- “수행기관은 계약체결 후 ○일 이내에 착수계획서를 제출하여야 한다.”
- “세부 수행방법은 발주기관과 협의하여 확정하되, 제안서에 제시한 내용은 계약조건과 동일한 효력을 가진다.”
- “발주기관은 사업 수행에 필요한 자료를 제공할 수 있으며, 수행기관은 제공자료의 정확성·보안성을 확인하여야 한다.”
- “사업 수행 과정에서 발생하는 변경사항은 사전 협의 및 승인 절차에 따른다.”
- “제안서 제출기간 이후의 추가 제출 및 수정은 인정하지 않는다. 다만, 발주기관의 요청이 있는 경우에는 예외로 한다.”
- “사업 수행 중 취득한 개인정보 및 업무자료는 목적 외로 이용하거나 제3자에게 제공하여서는 안 된다.”
- “최종 산출물은 발주기관의 검수·승인을 받아야 하며, 보완 요구가 있는 경우 수행기관은 지체 없이 보완하여야 한다.”
피해야 할 문체
- 사업자의 마케팅 문구를 발주기관 문서에 삽입
- “최고”, “세계 최초”, “획기적”, “완벽한” 등 근거 없는 수식어
- “적극 검토”, “가능하면”, “필요시”만으로 의무를 표시하는 표현
- 동일한 대상을 “수요기관/발주기관/우리 원”으로 번갈아 부르는 방식
- 평가 기준에는 없는 요구사항을 과업 본문에 불명확하게 추가
- “등”을 남발해 범위를 무한히 넓히는 방식
Evaluation and Fairness
제안요청서의 요구사항과 평가표는 서로 역방향으로 검증한다.
- 모든 고배점 평가항목이 본문 요구사항·제출서류에 대응하는가?
- 요구했지만 평가하지 않는 핵심 요소가 있는가?
- 특정 업체의 제품명·기술명·실적만 사실상 요구하고 있지 않은가?
- 정량평가의 분모·기간·증빙자료·상한을 정의했는가?
- “적정성”, “우수성” 같은 정성 기준에 평가자가 볼 증거가 있는가?
- 참가자격과 평가기준이 불필요하게 중복·충돌하지 않는가?
- 공동수급·하도급 허용 여부와 실제 과업 책임이 일치하는가?
- 기술평가 배점, 가격평가 비중, 협상적격자 기준, 동점 처리 규칙이 공고문과 일치하는가?
평가항목 예시:
- 사업 이해도 및 추진전략
- 과업 수행방법의 구체성·현실성
- 수행조직·전문인력·유사실적
- 일정·위험관리·품질관리
- 시스템·데이터·보안·연계 기술
- 산출물·교육·유지관리 계획
- 기대효과·성과관리
- 가격제안의 합리성
평가 문장은 “좋은 제안”이 아니라 관찰 가능한 근거를 가리켜야 한다. 예를 들어 “수행방법의 우수성”은 “단계별 활동, 담당자, 투입자원, 산출물, 위험 대응방안을 제시했는지”로 풀어 쓴다.
Security, Privacy, and Public Accountability
개인정보·의료정보·행정정보가 포함될 가능성이 있으면 보안은 별도 장이 아니라 요구사항·운영·검수에 반복 연결한다.
최소 포함 항목:
- 접근권한 부여·변경·회수
- 계정·비밀번호·다중인증 또는 조직 인증 연계
- 최소권한·기관/테넌트별 데이터 격리
- 전송·저장 구간 암호화
- 접속·조회·변경·다운로드·반출 감사로그
- 개인정보 처리 목적·보유기간·파기
- 위탁·재위탁·제3자 제공·국외 이전 여부
- 장애·침해사고·개인정보 유출 대응 및 보고기한
- 백업·복구·재해복구·가용성
- 테스트 데이터의 비식별·가명처리
- 외부 AI/클라우드 사용 시 승인된 환경과 원문정보 전송 제한
- 산출물·소스·데이터의 소유권과 반환·삭제
AI가 포함된 공공·의료 사업은 다음 원칙을 기본 문구로 둔다.
- AI 산출물은 검토·수정·승인 전제의 초안 또는 지원정보로 제공한다.
- 자동 확정·자동 처분·자동 진단·자동 처방으로 오해될 수 있는 표현을 피한다.
- 모델 버전, 입력·출력, 프롬프트/규칙, 사용자 검토, 예외처리를 기록할 수 있어야 한다.
- 원문 개인정보를 외부 상용 API에 직접 전송하는 구조는 기본안으로 제시하지 않는다.
Drafting Workflow
Step 1. Source and fact inventory
기존 공고·제안요청서·법령·예산자료·내부 업무자료를 읽고 다음을 표로 만든다.
항목 / 확인된 사실 / 출처 / 확정 여부 / 문서 삽입 위치
확정되지 않은 예산·기간·담당자·법령 조문·평가 배점은 임의로 채우지 말고 〔확인 필요〕로 표시한다. 완료 기준은 핵심 행정 사실마다 출처와 확정 여부가 붙어 있는 것이다.
Step 2. Document map
이번 작업이 공고인지 제안요청서인지 과업내용서인지 먼저 확정하고, 필요한 경우 2~3개 문서로 분리한다. 공고문의 날짜·예산·제출방식과 RFP의 사업 개요가 일치하는지 확인한다.
Step 3. Problem-to-scope chain
정책/현황 → 문제 → 목적 → 세부목표 → 과업 → 산출물 → 검수 → 평가의 연결표를 만든다. 연결되지 않는 과업이나 산출물은 삭제·통합·근거 보완 중 하나를 한다.
Step 4. Requirements and boundaries
과업을 업무·기능·데이터·보안·운영·보고·교육·유지관리로 분류하고, 각 항목에 책임주체·시기·증빙·검수기준을 붙인다.
Step 5. Write from general to specific
권장 순서:
- 사업 개요
- 배경·필요성
- 목적·목표
- 현황·문제점
- 추진방향
- 과업 범위
- 세부 요구사항
- 수행체계·일정
- 산출물·검수
- 보안·법적 조건
- 제안서 작성·평가
- 붙임 서식
Step 6. Cross-document audit
다음 항목을 공고서·RFP·과업내용서·서식 사이에서 비교한다.
- 사업명
- 사업기간
- 예산·부가세
- 입찰·계약방식
- 참가자격
- 공동수급·하도급
- 제출기한·장소·수량
- 기술/가격 평가 비율
- 협상적격자 기준
- 산출물 기한
- 담당자·문의처
Step 7. Legal and operational confirmation
최신 국가계약법·지방계약법·계약예규·조달청 기준·개인정보보호 관련 기준을 공식 원문으로 확인한다. 확인하지 못한 조문 번호나 기준일은 사실처럼 쓰지 않는다. 법령 문구의 초안은 법무·계약 담당자의 최종 확인 대상으로 표시한다.
Templates
One-page procurement brief
# [사업명]
## 1. 입찰 개요
- 발주기관:
- 사업기간:
- 사업예산:
- 계약방법:
- 입찰방법:
- 공동수급/하도급:
## 2. 추진 배경 및 필요성
- 정책·현황:
- 현장 문제:
- 기존 체계의 한계:
## 3. 사업 목적 및 목표
- 목적:
- 목표 1:
- 목표 2:
- 목표 3:
## 4. 주요 과업
- 과업 1 — 산출물 / 기한 / 검수
- 과업 2 — 산출물 / 기한 / 검수
## 5. 수행 조건
- 발주기관 제공사항:
- 수행기관 책임:
- 연계기관 협조:
- 제외·별도협의:
## 6. 제안서 평가
- 기술능력:
- 가격:
- 협상적격자 기준:
Requirement row
| ID | 구분 | 요구사항명 | 요구사항 | 책임주체 | 시기 | 산출물/증빙 | 검수기준 |
|---|---|---|---|---|---|---|---|
| FR-001 | 기능 | [명칭] | [수행해야 할 동작·처리·예외] | 수행기관 | [기한] | [증빙] | [판정기준] |
Bid notice opening
[기관명] 공고 제[번호]호
아래와 같이 입찰에 부치고자 공고합니다.
[연. 월. 일.]
[기관명] 계약담당
「[사업명]」입찰공고
## 1. 입찰에 부치는 사항
가. 입찰건명: ...
나. 사업내용: 제안요청서 참조
다. 사업기간: ...
라. 입찰방법: ...
마. 계약방법: ...
바. 사업예산: ... (부가가치세 포함)
Common Pitfalls
- 공고서와 제안요청서의 역할 혼동 — 공고서에는 절차·자격·일정, RFP에는 사업·요구사항·평가를 둔다.
- 목표는 크고 검수 기준은 없음 — 모든 핵심 과업에 산출물과 합격 기준을 붙인다.
- 범위가 “등”으로 계속 확장됨 — 포함·제외·별도협의를 명시한다.
- 서로 다른 날짜·예산·평가점수 — 최종본 전 교차검증표를 돌린다.
- 법령 조문을 기억에 의존 — 공식 원문과 기준일을 확인한다.
- 특정 업체에 유리한 요구사항 — 제품명이 아니라 기능·성능·산출물·검수기준으로 쓴다.
- 보안이 선언에 그침 — 권한, 로그, 암호화, 사고보고, 삭제·반환을 운영 요구사항으로 쓴다.
- 수행기관의 제안서 문체로 작성 — “우수한”, “혁신적인”, “최적의” 대신 발주기관의 필요·의무·판정기준을 쓴다.
- 평가표가 본문을 따라가지 못함 — 고배점 항목마다 제안서가 제출해야 할 증거를 지정한다.
- 연구·홍보·시스템 사업을 같은 목차로 처리 — 공통 행정 장은 유지하되 세부 과업 장은 사업 유형에 맞게 바꾼다.
- 기존 자료를 그대로 복사 — 연도, 기관명, 예산, 담당자, 법령 기준일, 평가점수를 전부 갱신한다.
- 개인정보·AI 사용 조건을 별도 각주로만 처리 — 데이터 흐름·외부 전송·검토자·로그·사고대응을 요구사항에 넣는다.
Verification Checklist
- 문서 유형과 발주기관 관점이 명확하다.
- 공고서의 행정 사실과 RFP의 사업 개요가 일치한다.
- 배경 → 문제 → 목적 → 과업 → 산출물 → 검수 → 평가가 연결된다.
- 모든 핵심 요구사항에 책임주체, 기한, 증빙, 검수기준이 있다.
- 포함 범위, 제외 범위, 발주기관 제공사항, 제3자 협조사항이 구분되어 있다.
- 사업명·기간·예산·부가세·계약방법·제출기한·평가배점이 교차검증되었다.
- 참가자격·공동수급·하도급·장비·인프라 책임이 명시되었다.
- 평가항목은 제안서에서 확인 가능한 증거와 연결된다.
- 개인정보·보안·감사로그·사고대응·산출물 소유권 조건이 포함되었다.
- 최신 법령·예규·조달 기준의 확인 필요 항목을 표시했다.
- 문체가 객관적·행정적이며 홍보성 수식어가 없다.
- 표·번호·용어·약어 표기가 문서 전체에서 일관된다.
- 제출서류와 붙임 서식이 본문 요구사항을 빠짐없이 반영한다.
- 최종본에서
〔확인 필요〕, 이전 연도, 이전 기관명, 임시 예산값이 남아 있지 않다.