제목: 평가위원이 답을 찾고 메시지까지 읽게 한다

평가표에 항목이 25개 있고 금요일까지 읽어야 할 제안서가 여섯 권인 평가위원을 떠올려 보세요. 3.4 항목을 채점하려는 그에게는 질문이 두 개 있습니다. 답이 어디 있는가, 그리고 그 답이 좋은가. 제목은 본문을 한 문장도 읽기 전에 첫 번째 질문에 답합니다. 잘 쓴 제목은 두 번째 질문에도 답하기 시작합니다.

제안서 제목이 하는 일은 두 가지입니다. 평가위원이 답을 찾게 돕고 그 답이 왜 중요한지도 알려 줍니다. APMP Body of Knowledge는 제목을 신문이나 웹페이지의 헤드라인에 견줍니다. 제목만 훑어본 사람도 이야기의 골격을 알 수 있어야 하고 길을 찾기 쉬운 제안서가 점수를 매기기도 쉽습니다. 순서는 찾을 수 있는 것이 먼저입니다. 평가위원이 찾지 못한 답은 아무 점수도 얻지 못하기 때문입니다. 메시지는 그다음, 규칙이 여지를 남겨 둔 곳에 담습니다.

이 시리즈는 APMP Foundation Study Guide에 요약된 APMP Body of Knowledge를 하나씩 짚어봅니다. 17편은 평가위원이 한 번 읽고 이해하도록 쓰는 법을 다뤘습니다. 이번 편은 한 단계 위로 올라가 제목을 다룹니다. 읽는 사람이 어떤 문장보다 먼저 보는 줄입니다.

제목이 평가위원에게 해 주는 일

Study Guide는 설득력 있는 제목이 이루는 일을 다섯 가지로 듭니다. 제 말로 옮기면 이렇습니다.

Study Guide는 좋은 제목이 분명한 메시지를 전하고 눈길을 끌며 평가위원의 핫 버튼이나 특정 요구사항에 답한다고 덧붙입니다. 효과와 차별화 요소를 담기에도 가장 알맞은 자리입니다(9편 참고).

제목에 기대는 독자는 두 부류입니다. 공식 평가위원은 정해진 평가 기준에 따라 특정 응답에 점수를 매기므로 맞는 답에 빨리 닿아야 합니다. 비공식 평가자, 예컨대 제안서의 일부만 읽는 고위 관리자나 실사용자는 자기 관심 주제로 곧장 갑니다. 분명한 제목은 둘 다를 돕습니다. 평가 항목을 좇든 관심사를 좇든 제목을 따라가면 길이 나옵니다.

첫 번째 규칙: 제안요청서의 제목을 따른다

재치 있는 제목을 쓰기 전에 제안요청서가 무엇을 요구하는지부터 확인합니다. Study Guide의 첫 번째 모범 사례는 단순합니다. 제목의 문구, 번호 체계, 제목 단계까지 작성 지침을 정확히 따르라는 것입니다.

지침이 제목 형식을 정하지 않았다면 제안요청서 자체의 대제목과 소제목을 같은 순서로 씁니다. 평가위원이 보고 있는 주제와 순서를 우리 제목이 그대로 비추면 평가 질문마다 답을 찾는 데 몇 초면 됩니다. 합리적인 예외가 하나 있습니다. 제안요청서의 실수까지 베끼지는 않습니다. 오탈자가 있거나 번호가 빠졌다면 바로잡습니다.

왜 이렇게까지 고집할까요? 평가위원은 평가표를 우리 제안서가 아니라 제안요청서를 보고 만들었기 때문입니다. 우리 목차가 그들의 목차와 다를 때마다 평가위원은 머릿속으로 번역해야 하고 그 번역은 인내심을 깎아 먹습니다. 12편의 컴플라이언스 매트릭스와 같은 논리입니다. 요구사항마다 답할 자리는 한 곳이고 평가위원은 묻지 않아도 그곳을 알아야 합니다.

능동형 제목: 이름표는 지키고 메시지를 더한다

제안요청서의 제목을 따른다고 해서 거기서 멈춰야 하는 것은 아닙니다. 지침이 허락하는 곳에서는 제안요청서의 문구를 그대로 두고 효과를 말하는 설명을 덧붙일 수 있습니다. Study Guide는 이렇게 효과를 앞세운 제목을 능동형 제목(active heading)이라고 부릅니다. 읽는 사람을 뒤따르는 섹션 안으로 끌어들이려고 쓰는 제목입니다. 이 글을 위해 쓴 예시입니다.

능동형 제목도 모두 제안요청서의 번호와 이름표로 시작한다는 점을 보세요. 평가위원은 4.2를 있어야 할 자리에서 찾고 덧붙인 말에서 무엇을 얻는지 읽습니다. 지침이 정확한 제목을 정해 두었다면 제목은 그대로 쓰고 메시지는 제목 아래 첫 문장으로 옮깁니다.

제목에 효과와 차별화 요소를 담는다

Study Guide는 효과와 차별화 요소를 평가위원에게 전해야 할 가장 중요한 메시지로 꼽습니다. 많은 독자가 그 메시지를 처음 만나는 곳이 제목이고 훑어보기만 하는 독자에게는 유일하게 만나는 곳일 수도 있습니다. 그러니 제목으로 눈길을 끌고 우리가 남과 다른 점을 말하세요.

첫 제목에는 제품 이름과 버전 번호뿐이니 제안사 이야기입니다. 두 번째 제목은 점검원에게 무엇이 얼마나 빨리 바뀌는지 말하는 고객 이야기입니다. 둘 다 짧지만 평가위원에게 계속 읽을 이유와 평가 의견에 옮겨 적을 구절을 주는 쪽은 두 번째뿐입니다. 8편에서 테마 문장에 했던 일을 한 줄로 압축한 셈입니다.

정보형 제목과 표지형 제목

Study Guide는 두 가지 방식을 구별하고 각각의 자리를 정해 줍니다.

정보형 제목을 보면 평가위원은 섹션에 무엇이 있고 자기 기관이 무엇을 얻는지 한눈에 알 수 있어 계속 읽게 됩니다. 표지형 제목은 덜 끌리지만 부록을 열어 보라고 설득할 필요는 없습니다. 이름표면 충분한 곳에는 이름표를 씁니다.

행동에는 동사, 답에는 명사

제목의 문법도 신호를 보냅니다.

• 동사형 제목은 고객이 우리를 고르면 일어날 행동과 결과를 보여 줘 설득합니다. "서류 완결성 확인을 온라인으로 옮겨 인허가 대기 시간을 줄입니다"처럼 씁니다. 문서 전체에서 동사형 제목의 시제와 어미를 통일합니다.
• 명사형 제목은 직접적인 질문에 바로 답할 때 알맞습니다. 제안요청서가 하자보수 기간을 묻는다면 "3년 현장 방문 하자보수" 같은 제목이 본문을 읽기 전에 답을 줍니다.
• 질문형 제목은 되도록 줄이거나 피합니다. "일정을 맞출 수 있을까요?" 같은 제목은 읽는 사람이 정말 맞출 수 있을지 의심하게 만듭니다. 바라는 것과 정반대입니다.

핵심 질문에 제목에서 바로 답하는 것은 이 장에서 가장 쓸모 있는 습관 가운데 하나입니다. 평가위원은 사실 하나를 찾으려고 섹션 전체를 읽지 않아도 되고 우리 답은 가장 눈에 띄기 쉬운 자리에 놓입니다.

섹션 도입부: 비공식 목차

섹션마다 첫머리에 짧은 문단을 두면 평가위원은 이 섹션이 무엇에 관한 것이고 무엇이 나올지 미리 압니다. 제안 실무자들은 이를 섹션 도입부 또는 비공식 목차(informal table of contents)라고 부릅니다. 지도의 범례처럼 먼저 읽으면 뒤따르는 하위 제목이 곧바로 이해됩니다.

이것이 제대로 작동하게 하는 규칙은 단순합니다. 하위 제목이 도입부의 주제 목록과 글자 그대로 같은 말을 써야 합니다. 이 글을 위해 쓴 예시입니다.

5.0 교육

제안요청서는 14개 지역 사무소의 모든 민원 담당자가 개통 후 10주 안에 새 사건관리 시스템을 쓰도록 요구합니다. 저희 교육 계획은 다음을 다룹니다.

5.1 지역 사내강사 양성
5.2 민원 담당자 실습 워크숍 운영
5.3 첫 달 현장 지원
5.4 개통 전 준비도 측정

뒤로 가면 하위 제목은 같은 말을 지키면서 구체적인 내용을 덧붙입니다. "5.1 지역 사내강사 양성: 7명씩 두 그룹", "5.2 민원 담당자 실습 워크숍 운영: 모든 사무소에서" 하는 식입니다. 목록을 읽은 평가위원은 필요한 항목으로 곧장 건너뛸 수 있습니다.

약점은 관리입니다. 마감이 다가올 때 누군가 하위 섹션을 더하거나 빼거나 이름을 바꾸면 도입부는 소리 없이 낡아 버립니다. Study Guide는 섹션이나 그 제목 하나라도 바뀌면 도입부를 다시 확인해 목록과 제목이 늘 일치하게 하라고 조언합니다.

능동형 제목 아래의 짧은 도입부

질의서처럼 긴 문항에 답하는 형식의 입찰도 있습니다. 이런 입찰은 이야기를 펼칠 여지가 적습니다. Study Guide는 이런 경우에도 규칙 안에서 주요 섹션 첫머리에 짧은 도입부를 두고 앞으로 나올 요점을 정리하라고 권합니다. 힘 있는 제목 아래 몇 문장만 있어도 평가위원이 세부 답변에 들어가기 전에 인상을 만들 수 있습니다. 이 글을 위해 쓴 예시입니다.

이 섹션은 제안요청서의 보안 문항 42개에 하나씩 답합니다. 모든 답변은 귀 기관의 요구사항을 빠짐없이 충족합니다. 아울러 저희 보안 책임자가 귀 기관의 분기별 위험 검토 회의에 참석하는 방식도 보여 드립니다. 그래서 위험 요소를 연말 보고서가 아니라 드러나는 그때그때 확인하실 수 있습니다.

섹션에 무엇이 있는지, 요구사항을 충족하는지, 고객이 반길 차별화 요소 하나. 평가위원은 무엇을 봐야 할지 알고 세부 내용을 읽기 시작합니다.

위계를 분명하게 세운다

제목 단계는 생각들이 어떻게 연결되는지에 관한 약속입니다. 2단계 제목은 바로 위 1단계 제목에 분명히 속해야 하고 3단계 제목은 그 위 2단계 제목에 속해야 합니다. 어떤 섹션 아래에 두어도 어색하지 않은 하위 제목이 있다면 그 구조는 읽는 사람을 헷갈리게 합니다.

1. 긴 제안서에는 제목에 번호를 붙입니다. Study Guide는 대략 10쪽이 넘는 제안서에서 번호가 평가위원의 답 찾기를 돕는다고 말합니다.
2. 세 단계에서 멈춥니다. 그보다 깊어지면 읽는 사람은 자기가 어디 있는지 놓칩니다. 2.3.1은 괜찮지만 2.3.1.4는 경고 신호입니다.
3. 세 번째 단계 아래에는 런인 제목을 씁니다. 런인 제목(run-in heading)은 문단 첫머리에 굵게 또는 크게 쓴 짧은 구절에 마침표나 쌍점을 찍고 본문을 이어 쓰는 방식입니다. 단계를 늘리지 않고도 새 소제목과 비슷한 효과를 냅니다.

예를 들어 "2.3.1 이관 테스트" 아래에 이렇게 씁니다. 대용량 테스트. 지난해 기록 전체의 사본을 올리고 합계를 한 줄씩 대조합니다. 롤백 테스트. 테스트 환경에서 이관을 되돌려 기존 시스템이 문제없이 다시 켜지는지 확인합니다. 하위 주제는 둘이지만 4단계는 생기지 않습니다.

제목을 일관되게 유지한다

제목은 왼쪽, 오른쪽, 가운데 어디에 두어도 되고 들여 쓰거나 런인으로 써도 됩니다. 어느 방식이냐보다 일관성이 중요합니다. 같은 단계의 제목은 제안서 전체에서 같은 모양이어야 합니다. 어떤 제목 하나만 더 크거나 굵거나 색이 다르다면 이유가 있어야 합니다. 그렇지 않으면 읽는 사람은 있지도 않은 의미를 찾게 됩니다.

단계를 구별해야 할 때 무엇부터 바꿀지 Study Guide는 순서를 줍니다. 글자 크기, 굵기, 색, 기울임, 글꼴 변경, 전부 대문자, 마지막이 밑줄입니다. 한글에는 대문자가 없으니 실제로는 앞의 두세 가지면 대부분 충분합니다.

병렬 구조

제목은 문법적으로도 일관되어야 합니다. 병렬 구조란 비슷한 항목을 비슷한 형태로 표현하는 것입니다. 그래야 평가위원이 문형이 바뀔 때마다 걸려 넘어지지 않고 제안서를 훑어 나갈 수 있습니다. 기록관리 시스템 섹션을 예로 이 글을 위해 쓴 예시입니다.

왼쪽 열에는 질문, 명사구, 동사형, 이름표 두 개가 섞여 있습니다. 오른쪽 열은 모두 "무엇을 하는/무엇의 + 명사"라는 한 가지 틀을 써서 제목들이 한 묶음으로 읽힙니다. 어떤 틀이든 하나를 골라 끝까지 일관되게 지키기만 하면 됩니다.

일관성은 처음부터 장치로 만들어 두면 지키기 쉽습니다. Study Guide는 제안팀이 자체 제목 스타일 라이브러리를 갖춰 모든 작성자와 모든 제안서가 같은 템플릿에서 출발하게 하라고 권합니다.

흔한 실수

1. 제안요청서의 섹션 이름을 바꾼다. 제안요청서보다 세련됐지만 더는 일치하지 않는 제목은 평가위원을 헤매게 합니다. 제안요청서의 이름표는 지키고 거기에 덧붙이세요.
2. 우리 이야기를 제목에 쓴다. 제품 이름, 버전 번호, "추진 방안"은 평가위원이 점수로 옮길 것을 하나도 주지 않습니다. 고객이 얻는 것을 말하세요.
3. 섹션 도입부를 방치한다. 하위 제목과 맞지 않는 주제 목록은 없느니만 못합니다. 존재하지 않는 섹션으로 읽는 사람을 보내기 때문입니다.
4. 단계가 너무 많다. 4단계에 이르렀다면 런인 제목을 쓰거나 섹션을 나누세요.
5. 문형이 뒤섞인다. 같은 단계에 질문, 이름표, 문장이 나란히 있으면 구조가 잘 보이지 않습니다. 단계마다 틀을 하나 정하세요.

다음 제안서를 위한 체크리스트

1. 제안요청서의 제목 관련 지침을 읽습니다. 문구, 번호, 단계. 정해져 있다면 정확히 따릅니다.
2. 정해져 있지 않다면 제안요청서의 제목과 순서를 그대로 목차에 옮기고, 명백한 오류만 바로잡습니다.
3. 허락되는 곳에서는 내용 제목을 능동형 제목으로 바꿉니다. 제안요청서의 이름표는 지키고 효과나 차별화 요소를 하나 덧붙입니다.
4. 직접적인 질문에는 명사형 제목으로 답하고, 동사형 제목의 시제와 어미를 통일하며, 질문형 제목은 없앱니다.
5. 표지형 제목은 부록 같은 정형 섹션에만 씁니다.
6. 주요 섹션마다 짧은 도입부를 씁니다. 주제 목록은 하위 제목과 글자 그대로 같게 하고, 고칠 때마다 다시 확인합니다.
7. 제목에 번호를 붙이고 세 단계에서 멈춥니다. 그 아래는 런인 제목을 씁니다.
8. 단계마다 모양과 문형이 일관된지 확인하고, 제목 스타일을 공유 라이브러리에 저장합니다.
9. 제목만 위에서 아래로 읽어 봅니다. 우리 이야기가 전해지나요? 평가위원이 제목만 보고 채점할 수 있나요?

Contrl에서는

좋은 제목은 찾을 수 있으면서 의미도 있어야 합니다. Contrl은 이 두 가지 일을 따로 맡겨 어느 쪽도 놓치지 않게 합니다. 장 번호와 제목은 제안요청서에서 옵니다. 제안요청서를 올리면 Contrl이 제안서 목차와 평가 기준을 추출하고 요구사항마다 그 목차의 섹션에 연결합니다. 그래서 평가위원은 제안요청서가 질문한 자리에서 답을 찾습니다. 덕분에 슬라이드 헤드라인에는 그 섹션에 고른 윈 테마와 핵심 문장에서 나온 메시지를 실을 수 있습니다. 각 페이지에는 대응하는 제안요청서 요구사항도 표시되므로 헤드라인이 제안요청서 문구를 벗어나도 어느 평가 항목에 답하는지 추적할 수 있습니다.

다음 편 예고

제목으로 평가위원에게 어디를 볼지 알려 줬다면 이제 그래픽 차례입니다. 그래픽은 글을 읽기 전에 생각을 먼저 보여 줍니다. 19편은 Graphics, 그래픽을 다룹니다. 제안서의 시각 자료가 마지막에 덧붙이는 장식이 아니라 먼저 그려 보는 설계 도구인 이유를 살펴봅니다.

이 글은 APMP Body of Knowledge를 요약한 APMP Foundation Study Guide 4.2판(© 2025 APMP)을 바탕으로 한 독립적인 학습용 해설입니다. 원문을 풀어 쓰고 해설한 것으로, APMP의 승인을 받은 글이 아닙니다. 첫머리의 평가위원 장면, 모든 제목 예시(서비스 데스크, FieldTrack, 병렬 제목 등), 교육 섹션 도입부, 보안 질의서 도입부, 런인 제목 예시, 목차가 고정된 제안요청서에 관한 메모는 모두 이 글을 위해 쓴 것이며, 수치는 예시이고 고객사 이름은 밝히지 않았습니다. 공식 원문과 자격 정보는 apmp.org에서 확인하세요.