사업 목적은 맞는데 담당자의 문제와는 어긋나는 제안

공공기관 대상 제안서를 보면 공고문에 나온 사업 목적과 추진 배경을 첫 장부터 충실하게 반복한 경우가 많다. 지역경제 활성화, 디지털 전환, 이용자 편의, 기업 경쟁력 같은 표현도 빠지지 않는다. 방향은 틀리지 않았지만 담당자가 제안서를 읽고도 ‘그래서 우리 업무의 무엇이 달라지는가’를 찾지 못하면 검토는 멈춘다.

공고문은 여러 이해관계자가 공유할 수 있도록 사업의 범위와 조건을 정리한 문서다. 담당자가 매일 겪는 자료 취합, 참여자 모집, 부서 협의, 민원 대응, 성과 보고와 사후 관리의 장면까지 모두 담기는 어렵다. 제안기업이 공고문만 읽고 문장을 확장하면 사업의 명분은 설명해도 현장의 마찰을 해결하지 못한다.

문제는 제안서의 분량이나 디자인이 아니다. 정책 목적, 담당자의 업무 문제, 최종 이용자의 불편을 한 덩어리로 다루는 데 있다. 세 층을 구분하지 않으면 이용자에게 필요한 변화와 담당자가 실행할 업무, 기관이 확인할 성과가 서로 엇갈린다. 실제 문제를 찾는 일은 공고문의 목적을 벗어나는 것이 아니라 목적이 실행되는 경로를 밝히는 일이다.

첫째, 공고문을 업무 장면과 질문으로 다시 읽는다

공고문을 읽을 때 과업명과 제출 항목만 표시하지 말자. 누가 언제 어떤 업무를 수행하고, 어디에서 지연되며, 어떤 자료와 승인에 의존하는지 질문으로 바꿔야 한다. 현재 사용 중인 방식, 담당 부서, 참여기관, 이용자 접점, 사업 전후의 운영 주체를 표로 놓으면 문서에 쓰이지 않은 확인 과제가 보인다.

담당자의 문제를 추측으로 채우는 것도 경계해야 한다. 이전 사업 자료, 공개된 성과보고, 설명회 질의, 현행 안내문과 업무 절차처럼 확인 가능한 흔적에서 가설을 만들고, 제안 전에 확인할 질문과 착수 후 진단할 질문을 구분한다. 답을 얻지 못한 내용은 사실이 아니라 검증할 가정으로 표시해야 한다.

좋은 질문은 ‘어려움이 무엇입니까’에서 끝나지 않는다. 참여자 모집이 늦어지는 시점은 언제인지, 자료가 몇 번 다시 작성되는지, 누가 최종 판단하는지, 사업 종료 뒤 문의와 데이터는 누가 관리하는지를 묻는다. 질문이 구체적일수록 제안 범위와 일정, 필요한 협조사항도 현실에 가까워진다.

둘째, 산출물보다 문제 해결의 연결 구조를 보여 준다

공공 제안은 교육 횟수, 콘텐츠 수, 행사 규모, 시스템 기능처럼 산출물 목록으로 흐르기 쉽다. 산출물은 계약과 검수에 필요하지만 그 자체가 문제 해결을 뜻하지는 않는다. 어떤 문제 때문에 이 산출물이 필요하고, 누가 사용하며, 사용 뒤 어떤 업무 변화와 이용자 반응을 확인할 것인지 연결해야 한다.

예를 들어 플랫폼을 제안한다면 개발 기능만 적기보다 기존 접수·선발·지원·보고 과정 중 어디를 바꾸는지 설명한다. 교육이라면 몇 회 운영하는지보다 참여자가 현장 과제를 어떻게 가져오고, 교육 뒤 무엇을 실행하며, 담당자가 어떤 방식으로 후속 상황을 확인하는지 보여 준다. 행사도 방문 인원뿐 아니라 지역 사업자와 이용자에게 남길 다음 행동이 있어야 한다.

여기에 기관의 제약을 함께 넣어야 한다. 예산 집행 시점, 부서 간 협의, 개인정보와 보안, 현장 인력, 기존 시스템, 보고 형식 중 제안 실행에 영향을 주는 조건을 구분한다. 모든 제약을 제안사가 해결할 수는 없다. 대신 기관이 준비할 일과 제안사가 책임질 일, 공동으로 결정할 일을 나누면 실행 가능성을 판단하기 쉬워진다.

셋째, 담당자가 내부에서 설명할 수 있는 제안으로 바꾼다

담당자는 제안서를 혼자 읽고 끝내지 않는다. 현업 부서, 결재자, 계약·예산 담당자, 협력기관과 내용을 공유해야 한다. 따라서 제안의 핵심은 전문용어보다 내부 설명 가능성에 있다. 왜 필요한지, 무엇이 바뀌는지, 어떤 위험이 있고, 누가 어떤 역할을 맡는지를 짧게 설명할 수 있어야 한다.

첫 검토용 한 장에는 공고 목적, 확인한 현장 문제, 대상 이용자, 해결 방식, 핵심 산출물, 일정과 역할, 검증 지표를 한 흐름으로 놓아 보자. 확인된 사실과 제안사의 가정도 구분한다. 담당자가 틀린 가정을 바로잡을 수 있어야 제안은 기관의 실제 조건에 맞게 조정된다.

공공기관 제안의 차별화는 거창한 아이디어보다 문제를 정확히 읽고 실행의 마찰을 줄이는 데서 나온다. 공고문을 요약하는 데서 멈추지 말고 담당자의 하루, 이용자의 접점, 기관의 승인과 협업 구조, 사업 종료 뒤 운영까지 따라가야 한다. 이 흐름이 보이면 제안서는 과업을 수주하기 위한 문서를 넘어 담당자가 함께 실행을 검토할 수 있는 설계도가 된다.