14년차 개발사가 제안서 쓸 때 가장 신경 쓰는 3가지, 아토즈소프트 PM의 메모

안녕하세요! 아토즈소프트입니다.

​

아토즈소프트는 14년째 공공·협회·바우처 사업 중심으로

디지털 플랫폼을 만들고 있습니다.

​

• 관광혁신바우처로 진행한 여행·관광 플랫폼

• 의료협회·제약바이오 교육을 위한 온라인 학회·LMS

• 지자체·공공기관의 QR 패스·디지털 투어 서비스

같은 프로젝트를 제안 단계부터 끝까지 함께해 왔습니다.

​

아토즈소프트 공식 홈페이지에서 14년동안 아토즈소프트가 진행해온 여러 조달 프로젝트들을 한 눈에 확인하실 수 있습니다.

아토즈소프트 홈페이지 바우처 바로가기 링크

​

​

그 과정에서 제안서를 쓸 때마다

항상 다시 확인하게 되는 기준 세 가지가 있습니다.

오늘은 그 3가지를, 실제 PM 메모 형식으로 공유드리려고 합니다.

​

1. “평가표부터 본다” – 점수 구조를 먼저 이해하기

​

제안요청서( RFP )를 받으면

저는 늘 본문보다 먼저 ‘평가기준표’를 펼쳐놓습니다.

공공·바우처 사업 제안서를 같이 준비할 때도

우리가 제일 먼저 했던 일이 이거였습니다.

1) 분량은 ‘중요도’ 순서대로 쓴다

실제로 저희는 평가표를 보고

슬라이드/페이지 분량을 역산합니다.

예를 들어:

• 사업 이해도 10점 → 2~3페이지

• 구현·운영 방안 30점 → 10페이지 이상

• 수행 실적·역량 15점 → 핵심 포트폴리오 중심 4~5페이지

• 관리계획·리스크 관리 10점 → WBS + 리스크 표 3~4페이지

이렇게 점수 비율과 페이지 비율이 어느 정도 맞도록 구성합니다.

“중요도 5점짜리 항목이 10페이지를 차지하는” 구조는

아무리 내용을 잘 써도 평가위원 눈에는 비효율적으로 보입니다.

​

2) “멋진 문장”보다 “체크리스트를 채워주는 구조”

제안서를 같이 보완할 때도

우리가 자주 했던 대화가 있습니다.

그래서 아예 평가항목–제안서 목차 매핑 표를 만들어 놓습니다.

• 평가항목 A → 제안서 Ⅱ-3, Ⅱ-4 슬라이드

• 평가항목 B → 제안서 Ⅲ-2 ~ Ⅲ-6

• 평가항목 C → 제안서 Ⅳ-1, Ⅳ-2 …

나중에 “이 항목은 어디서 설명했나요?”라는 질문을 받더라도

이 표 하나로 깔끔히 설명할 수 있습니다.

정리하자면,

2. “요구사항을 전부 펼쳐본다” – 누락 없는 요구사항 맵

​

아토즈소프트가 제안서를 쓸 때 두 번째로 신경 쓰는 것은

요구사항 누락을 0에 가깝게 만드는 것입니다.

실제로 KPBMA 아카데미, 스마트 MICE, 교육통합플랫폼 등

여러 제안서를 준비하면서

• ECR / SFR / SIR / SER / PER / DAR / PMR / COR

• 등으로 나뉜 요구사항 100개+ 리스트

• “요구사항 수용 조견표”

• “제안서 페이지 매핑”

을 한 번에 정리하는 작업을 많이 했습니다.

​

1) “요구사항 맵”을 먼저 만든다

저희는 제안서 쓰기 전에

모든 요구사항을 한 장의 맵으로 정리합니다.

예시 형태:

이 표를 만들면서 동시에 확인합니다.

• 유사/중복 요구사항은 어떻게 묶을지

• 제안서 본문에서 어느 섹션에서 함께 설명할지

이걸 미리 정해두면, 작성 막판에

같은 상황을 최소화할 수 있습니다.

​

2) “제안요청서 페이지 vs 제안서 페이지” 매핑

우리가 함께 작업하면서 꽤 공들였던 부분이 바로 이거죠.

평가위원 입장에서는

• “이 요구사항에 대한 답을 어느 페이지에서 볼 수 있는지”

• “정말 다 수용한 것인지”

를 조견표 한 장만 보고도 파악하고 싶어 합니다.

​

그래서 저희는

• 요구사항 리스트 엑셀

• 제안서 PDF (페이지 넘버링)

• 수용 조견표

이 세 가지를 나란히 두고

페이지 번호를 다시 한번 전수 점검합니다.

​

조금 번거롭지만, 이 과정에서

• 빠진 요구사항

• 겹치는 설명

• 위치가 애매한 기능

이 자연스럽게 드러납니다.

정리하면,

3. “실제 운영 장면까지 그려본다” – 그림과 시나리오로 설득하기

​

세 번째는 “실제로 운영하는 장면까지 상상하며 쓰는 것”입니다.

​

아토즈소프트가 제안서를 쓸 때는

• IA(Information Architecture)

• 화면 흐름도

• 시스템 아키텍처

• 장애·보안·모니터링 방안

같은 항목을 그림과 시나리오로 설명하는 데 많이 공을 들입니다.

​

1) “사용자 기준 시나리오”를 먼저 그린다

예를 들어,

• 교육 통합 플랫폼이라면 → 제약바이오 협회 교육 담당자 / 회원사 / 수강생 하루 흐름

• 관광 패스 서비스라면 → 여행자가 QR 패스를 구매하고 이용하고 리뷰 남기는 흐름

• 스마트 MICE 플랫폼이라면 → 참관객·부스 담당자·운영자 각자의 하루 동선

이렇게 역할별 하루 시나리오를 정리합니다.

​

실제 제안서에서도

“로그인 – 탐색 – 신청/구매 – 참여 – 이수/정산”

흐름을 그림으로 보여드렸고,

평가하시는 분들이

“아, 이 플랫폼이 실제로 이렇게 돌아가는구나”

를 한눈에 이해하실 수 있도록 구성했습니다.

​

2) “그럴싸한 기술 나열” 대신 “현실적인 아키텍처”

우리가 제안서 기술 파트에서 자주 다뤘던 내용입니다.

​

• AWS / KT Cloud / LG CNS 같은 실제 인프라 환경

• 장애 시 모니터링 & 알림 구조

• 메시지 발송/연동 실패 시

• 재시도(예: 3회)

• 그래도 실패하면 Fail Table(DLQ 성격의 테이블)에 적재

• 관리자 화면에서 재처리(Replay) 가능

이런 부분을 “그럴 듯한 유행어”가 아니라

까지 적어두면, 평가위원 입장에서는

• “이 팀은 실제 장애 상황까지 상상해보고 설계했구나”

• “운영 이후에 생길 이슈까지 고려했구나”

라는 신뢰를 갖게 됩니다.

​

3) “운영자 화면”까지 보여주는 것

우리가 제안서에서 늘 강조했던 또 하나의 포인트는

운영자·관리자 화면입니다.

​

• 교육 담당자가 쉽게 강좌를 등록·복사·마감할 수 있는 화면

• 관광상품·패스 이용 내역을 한 번에 볼 수 있는 정산 화면

• 온라인 학회에서 세션/부스를 편하게 관리하는 CMS 화면

​

운영자 입장에서 “내가 이걸 실제로 쓴다면…”을

한 번만 상상해 보면,

• 버튼 위치

• 필요한 필터/검색 항목

• 통계/다운로드 기능

같은 것들이 자연스럽게 드러납니다.

이걸 제안서에 미리 녹여두면,

발주처 실무자는 그 자리에서 “아, 이거 내가 쓰기 편하겠다”를 느끼게 됩니다.

정리하며 – “평가표, 요구사항, 실제 운영” 세 축

​

아토즈소프트가 제안서를 쓸 때

계속해서 다시 돌아가는 기준은 이 세 가지입니다.

​

1. 평가표부터 본다 → 점수 구조에 맞춰 목차·분량·강조 포인트를 설계합니다.

2. 요구사항을 전부 펼쳐본다 → 요구사항 맵 + 수용 조견표 + 페이지 매핑으로 누락을 없앱니다.

3. 실제 운영 장면까지 그려본다 → IA·화면 흐름·아키텍처·장애 대응·운영자 화면을 구체적으로 보여줍니다.

제안서는 결국 “우리가 어떤 방식으로 일하는 팀인지 보여주는 문서”라고 생각합니다.

아토즈소프트는 규모가 아주 크진 않지만, 그만큼 프로젝트마다 PM·기획·디자인·개발이 끝까지 붙어서 책임 있게 진행해 왔습니다.

​

관광·여행, 교육, 의료·제약, 공공·협회까지

여러 분야의 디지털 플랫폼을 14년 동안 쌓아오면서,

언제나

• 평가 구조를 이해하고,

• 요구사항을 끝까지 책임지고,

• 실제 운영까지 상상하는 팀으로 일해 왔습니다.

​

앞으로도 “작지만 단단한 팀”으로,

제안서를 함께 준비하는 순간부터 런칭 이후 운영까지

조용히, 그러나 꾸준히 옆에서 힘이 되는 파트너가 되겠습니다.

Total solution from A to Z

Atozsoft Corp’

(주)아토즈소프트

​

서울 성동구 광나루로 240-30 아토즈빌딩

Office : 02-1644-2460

Email : atozsoft@atozsoft.co.kr

Web : www.atozsoft.co.kr