공공기관 대국민 서비스 고도화 사업의 RFP를 펼치면, 늘 보던 문장이 하나 있습니다.
"시스템 안정성 확보 및 장애 대응 체계 강화"
대부분의 제안사는 이 줄을 요구사항 표의 한 칸으로 처리합니다. 이중화 구성도 넣고 모니터링 도구도 넣어서, 빠진 데 없이 채웁니다.
그런데 이런 사업을 자주 가져가는 팀은 문서를 잠시 덮고 다른 걸 먼저 찾아봅니다. 같은 이름의 사업이 몇 년 전에도 나왔는지, 그사이 예산은 왜 늘었는지 확인하고, 기관 이름으로 뉴스도 한 번 검색해 봅니다. 사업설명회에서 담당자가 같은 질문을 두 번 했다면 그것도 메모해 둡니다.
"장애가 나면, 저희한테는 언제 어떻게 보고가 됩니까?"
알고 보니 지난해 서비스가 몇 시간 멈춰서 기관이 감사에서 지적을 받았고, 이번 사업은 그 뒤 처음 나온 사업이었습니다. 담당자 입장에서 제일 급한 건 대응 체계를 갖추는 일보다, 같은 일로 다시 불려 나가지 않는 거였을 겁니다.
그래서 이 팀은 똑같이 이중화를 제안하면서도 첫 장을 이렇게 씁니다.
"장애를 막는 것보다 먼저, 장애가 났을 때담당자가 가장먼저 알게합니다."
다른 제안서들이 시스템 얘기로 시작할 때 이 제안서만 담당자 얘기로 시작하니, 읽는 쪽에서는 '이 회사는 우리 사정을 좀 아네' 싶을 수밖에 없습니다.
문서에 적힌 것, 문서 아래 깔린 것
RFP에 적힌 건 빙산의 윗부분입니다.
공식 문서에는 쓸 수 있는 것만 들어갑니다. 지난 사업이 잘 안 됐다거나 예산이 빠듯해서 부담스럽다는 얘기를 RFP에 적는 기관은 없습니다. 그런데 제안서를 읽으며 고개를 끄덕이게 만드는 건 대개 그런 부분입니다.
같은 RFP를 받은 회사가 다섯 곳이면, 다섯 곳 모두 같은 요구사항 표를 채웁니다. 문서만 보고 쓰면 결과물이 비슷해지는 게 당연합니다. 평가가 끝난 뒤 '그 회사는 우리 고민을 알더라'는 말을 듣는 제안서는 보통 문서 밖에서 뭔가를 더 찾아온 경우입니다.
그래서 이기는 팀은 RFP를 읽을 때부터 적힌 요구와 적히지 않은 고민을 따로 정리합니다.
분석은 거기서 시작합니다.
행간을 읽는다고 하면 감이나 눈치를 떠올리기 쉬운데, 실제로 해보면 단서를 모으는 일에 가깝습니다.
과거 공고를 나란히 놓고 보거나 기관 관련 기사를 몇 개 찾아보는 것부터 시작하면 됩니다. 단서 하나로는 확신하기 어렵지만, 두 개가 같은 쪽을 가리키면 꽤 믿을 만합니다.
물론 늘 이렇게 깔끔하게 맞아떨어지지는 않습니다. 과거 공고를 다 뒤져도 별게 안 나올 때가 있고, 설명회가 십 분 만에 끝나 버릴 때도 있습니다. 그럴 땐 질의 기간에 해석이 애매한 조항 한두 개를 골라 정식으로 물어보는 것도 방법입니다. 회신 문구 몇 줄에서 의외로 많은 게 보이기도 합니다.
찾은 고민은 가장 무거운 몇 가지만 추려서 평가 항목과 맞춰 봅니다. 고민도 크고 배점도 큰 항목이 있다면, 분량과 공을 그쪽에 더 들이는 게 맞습니다.
우리 제안서에 바로 적용해볼 것
다음 RFP를 받으면 목차 잡기 전에 이것부터 해보시길 권합니다.
- 같은이름(또는 연도·차수만바뀐 이름)의 과거공고를 찾아, 예산과 과업범위가 어떻게 변했는지 나란히 놓고 본다.
- 발주처이름과 사업 키워드로 최근 뉴스와 감사지적을 검색해, 이 기관을 '아프게한' 일이 있었는지 확인한다.
- 설명회와 질의응답에서 담당자가 되묻거나 유난히 신경 쓴대목을 적어 두고, 어느평가 항목과 연결되는지 표시한다.
RFP에는 발주처가 쓸 수 있었던 것만 들어 있습니다. 나머지는 직접 찾아야 합니다.
다음 회차 예고
6화. 평가 배점표에서이기는 전략이 나온다
배점표는 누구나 봅니다. 그런데 정작 쓰는 순간에는 잊힙니다. 왜 그런지, 다음 주에 이어집니다.
필립이 RFP 행간을 읽어 전략을 다시 짠 제안 중 하나는, 초기 예상 배점과 전혀 다른 곳에서 승부가 갈렸습니다.