AI에게 “제안서 목차를 작성해줘”라고 입력하면 답은 금방 나옵니다.

프로젝트 개요, 수행 전략, 일정과 인력 구성, 기대효과. 익숙한 항목들이 빠르게 정리됩니다. 문장도 자연스럽고, 구조도 그럴듯합니다. 처음 보면 꽤 쓸 만해 보입니다.

그런데 막상 들여다보면 조금 다릅니다.

틀렸다고 하기는 어렵습니다. 하지만 그대로 쓰기에는 비어 있는 부분이 있습니다. 고객사가 무엇을 중요하게 보고 있는지, 어떤 요구사항을 반드시 강조해야 하는지, 어떤 조건이 일정이나 범위의 리스크가 될 수 있는지는 여전히 사람이 다시 확인해야 합니다.

AI 결과물이 기대한 만큼 나오지 않을 때, 문제는 AI의 성능만이 아닐 수 있습니다. 같은 업무라도 한 번에 던지기보다 어디서 끊고, 어떤 단위로 나누어 맡기느냐에 따라 결과와 활용 방식이 달라질 수 있습니다.

AI를 잘 쓰는 일은 질문을 멋지게 쓰는 일만으로 끝나지 않습니다. 업무를 AI가 처리할 수 있는 크기로 나누는 일이 함께 필요합니다.

왜 AI가 준 답은 그럴듯한데 바로 쓰기 어려울까?

이런 경험은 제안서에만 한정되지 않습니다.

“테스트 시나리오를 만들어줘.”

“디자인 피드백 정리해줘.”

“이 문서 검토해줘.”

결과는 나옵니다. 빠르게 나옵니다. 다만 실제 업무에 바로 반영하려면 한 번 더 손이 갑니다. 다시 원문을 열고, 기존 문서를 확인하고, 빠진 조건을 찾고, 결국 사람의 판단으로 돌아옵니다.

AI가 일을 못해서라기보다, 업무를 너무 큰 덩어리로 받았기 때문입니다.

우리가 실제로 일할 때도 하나의 업무를 한 번에 끝내지는 않습니다. 문서를 읽고, 요구사항을 나누고, 기존 기준과 비교하고, 빠진 부분을 찾고, 다시 정리하고, 마지막에 판단합니다. 제안서든, 화면 정의서든, 디자인 피드백이든, 개발 명세든, 테스트 시나리오든 대부분의 업무 문서는 이런 과정을 거쳐 결과물로 이어집니다.

AI에게도 같은 방식이 필요합니다. 완성본을 한 번에 요구하기보다, 사람이 하던 일을 AI가 처리할 수 있는 작은 단위로 나누어 맡기는 편이 더 안정적입니다. 바로 결론을 쓰게 하기보다 먼저 읽게 하고, 나누게 하고, 비교하게 하고, 의심하게 만드는 방식입니다.

업무에서 AI는 최종 작성자보다 1차 분석자에 가까울 때 더 유용합니다.

그럼 AI에게 일을 어떻게 나눠 맡겨야 할까?

올해 상반기 한 모바일 앱 구축 제안 준비 과정에서도 비슷한 상황이 있었습니다.

RFP에는 구축 범위, 회원/인증 정책, 운영 요건, 외부 시스템 연동, 일정, 제출 방식, 평가 기준이 함께 들어 있었습니다. 문서 자체가 아주 길지는 않았지만, 바로 제안서 목차를 만들기에는 먼저 나눠야 할 내용이 많았습니다. 어떤 요구사항을 본문에서 강하게 다뤄야 하는지, 회원과 인증 정책에서 확인이 필요한 부분은 무엇인지, 외부 시스템 연동 범위가 어디까지인지, 일정상 위험한 조건은 없는지가 먼저 정리되어야 했습니다.

이때 AI에게 제안서를 바로 쓰게 하면 결과는 빠르게 나옵니다. 다만 그 결과는 대체로 평범한 목차에 가깝습니다. 프로젝트 개요, 수행 방안, 일정, 인력, 기대효과 같은 항목은 정리되지만, 앱 구축 제안에서 중요한 정책·연동·운영 기준은 충분히 드러나지 않습니다.

그래서 순서를 바꿨습니다.

제안서를 쓰게 하기 전에 먼저 RFP를 분해하게 했습니다. 목차를 만들기 전에 질문을 뽑게 했습니다. 프로젝트 목적, 핵심 요구사항, 회원/인증 정책, 외부 시스템 연동 범위, 일정과 범위의 리스크, 고객사에 다시 확인해야 할 질문, 평가 기준상 강조해야 할 포인트를 먼저 나누었습니다.

예를 들면 이런 식입니다.

이 RFP를 바로 제안서 목차로 만들지 말고, 먼저 아래 기준으로 나눠줘.

1. 핵심 요구사항

2. 제안서에 반드시 반영해야 할 항목

3. 회원/인증·권한 정책에서 확인이 필요한 항목

4. 외부 시스템 연동 범위와 전제 조건

5. 일정·범위·운영 리스크

6. 고객사에 다시 확인해야 할 질문

7. 평가 기준상 강조해야 할 포인트

각 항목은 원문 근거와 함께 정리하고, 문서에 명확히 없는 내용은 ’확인 필요’로 분리해줘.

이렇게 정리하자 처음에는 지나치기 쉬웠던 확인 질문이 먼저 보였습니다. 회원 상태별 처리 기준, 인증 방식, 외부 시스템 연동 범위, 운영 알림 기준처럼 제안서에 쓰기 전에 고객사에 다시 물어봐야 할 항목들이 분리됐습니다. 목차를 먼저 만들었다면 뒤늦게 발견했을 내용들이었습니다.

이렇게 남은 것은 완성된 제안서가 아니라, 제안서를 쓰기 위한 1차 분석 자료였습니다. 사람은 이 자료를 보고 무엇을 강조할지, 무엇을 확인할지, 어떤 리스크를 먼저 막을지 판단할 수 있습니다. 기존 제안서 목차나 유사 프로젝트 자료와 비교해 빠진 항목을 찾는 데도 도움이 됩니다.

마지막으로 평가자 관점에서 다시 볼 수도 있습니다.

이 방향이 고객사 입장에서 설득력 있는가. 요구사항 대비 답변이 추상적이지 않은가. 차별점이 실제 근거와 연결되어 있는가. 리스크를 회피하는 것처럼 보이지는 않는가.

이 과정에서 AI가 먼저 만들어준 것은 제안서라기보다 질문 목록에 가까웠습니다. 무엇을 강조할지, 무엇을 확인할지, 무엇을 의심할지. 제안의 방향은 그다음에 사람이 정합니다.

문서를 요약하는 것만으로는 왜 부족할까?

문서를 AI에게 줄 때 가장 많이 하는 요청은 “요약해줘”입니다. 요약은 유용합니다. 긴 문서를 빠르게 파악하거나 주요 내용을 확인할 때 도움이 됩니다.

하지만 실무에서 필요한 것은 단순 요약이 아닐 때가 많습니다. 다음 업무로 이어질 수 있는 형태가 필요합니다.

요약은 문서를 짧게 만드는 일입니다.

변환은 문서를 다음 업무에 쓸 수 있게 바꾸는 일입니다.

RFP는 제안 준비 자료로 변환되어야 합니다. 회의록은 실행 항목과 확인 필요 사항으로 변환되어야 합니다. 변경 요청은 영향 범위와 수정 대상 목록으로, 화면 정의서는 테스트 기준과 예외 케이스로 바뀌어야 다음 업무로 이어질 수 있습니다.

AI를 업무에 활용할 때 “이 문서를 줄여줘”에서 멈추면 결과는 참고 자료에 머무릅니다. 반대로 “이 문서를 다음 업무에 쓸 수 있는 형태로 바꿔보자”는 관점으로 접근하면 AI의 결과물은 실제 판단과 실행에 더 가까워집니다.

읽는 시간을 줄이는 것과, 다음 일을 시작할 수 있게 되는 것은 다릅니다. 실무에서 더 큰 차이를 만드는 것은 대체로 후자입니다.

RFP만 특별한 것은 아닙니다. 업무에서 다루는 대부분의 문서는 비슷한 방식으로 활용할 수 있습니다. 중요한 것은 문서마다 먼저 나눠야 할 단위가 다르다는 점입니다.

회의록이라면 요약보다 구분이 먼저입니다. 확정된 것, 논의 중인 것, 누가 해야 할 것, 다시 확인해야 할 것이 나뉘어야 회의가 다음 업무로 넘어갑니다.

변경 요청이라면 반영보다 영향 범위가 먼저입니다. 버튼 하나가 바뀌어도 화면만 바뀌는 것은 아닙니다. 관련 문서가 바뀌고, 테스트 항목이 늘어나고, 운영 정책까지 함께 움직일 수 있습니다. 작아 보이는 변경일수록 그 영향이 어디까지 번지는지를 먼저 봐야 합니다.

테스트 시나리오라면 케이스 작성보다 조건 분리가 먼저입니다. 로그인 여부, 권한, 빈 데이터, API 실패, 버튼 활성화 조건처럼 확인해야 할 조건이 먼저 정리되어야 이후 케이스도 흔들리지 않습니다.

피드백 정리도 같은 원리입니다. 보기 좋게 정리하는 것보다 먼저 봐야 할 것이 있습니다. 취향에 가까운 의견인지, 기존 가이드와 충돌하는 요청인지, 정책 확인이 필요한 항목인지, 실제 구조 변경이 필요한 항목인지 구분하는 일입니다.

직군이 달라도 원리는 크게 다르지 않습니다. AI에게 맡길 일은 최종 산출물보다, 판단 전에 필요한 비교와 분류, 누락 확인에 가깝습니다. 결국 AI를 잘 쓰는 일은 결과물을 대신 받는 일이 아니라, 사람이 판단할 수 있는 상태로 일을 정돈하는 일입니다.

AI 결과를 그대로 믿지 않으려면 어떻게 받아야 할까?

AI가 만든 문장은 자연스럽습니다. 그래서 더 조심해야 합니다. 자연스럽다는 것과 사실이라는 것은 다릅니다.

회의록에서 논의 중이던 내용이 확정 사항처럼 정리될 수 있습니다. RFP에 명시되지 않은 범위가 당연한 요구사항처럼 보일 수도 있습니다. 문서에 없는 예외 케이스를 AI가 임의로 보완하면서 실제 정책처럼 보이게 만들 수도 있습니다.

그래서 AI 결과물은 확정, 추정, 확인 필요로 나뉘어야 합니다. 이 구분은 AI를 믿기 위한 절차라기보다, 사람이 어디까지 확인해야 하는지 드러내기 위한 안전장치에 가깝습니다.

로이터 통신은 2026년 6월 9일 미국 미시시피주의 한 연방법원에서 양측 변호인단이 검증되지 않은 AI 생성 법률 자료를 제출했고, 그 안에 존재하지 않는 판례 인용이 포함되어 제재를 받은 사례를 보도했습니다. 법률 문서처럼 책임이 큰 영역의 사례이지만, 본질은 우리의 업무에도 적용됩니다.

AI가 만든 결과가 자연스럽다고 해서 곧바로 업무 기준이 되는 것은 아닙니다. 중요한 것은 속도가 아니라, 검토 가능한 구조입니다. 무엇이 원문에 있는 내용인지, 무엇이 AI의 추론인지, 무엇이 사람의 확인을 거쳐야 하는지가 구분되어야 합니다.

이때 보안 기준도 함께 필요합니다. 업무 문서에는 고객사 정보, 내부 전략, 개인정보, 계약 조건, 계정 정보, 금액 등 외부에 노출되면 안 되는 내용이 포함될 수 있습니다. 무엇을 넣을지, 무엇을 가릴지, 어디까지 맡길지, 누가 다시 검토할지에 대한 기준이 있어야 AI를 안전하게 활용할 수 있습니다.

내가 쓴 문서를 AI에게 다시 보여주는 이유는 무엇일까?

AI를 초안 작성 도구로만 생각하면 활용 범위가 좁아집니다. 실제 업무에서는 초안을 작성하게 하는 것보다, 이미 작성한 내용을 검토하게 할 때 더 유용한 경우도 많습니다.

작성자는 자신이 쓴 문서의 빈틈을 잘 보지 못할 때가 있습니다. 정책 흐름을 중심으로 보면 구현상의 모호함을 놓칠 수 있고, 화면 완성도를 중심으로 보면 운영 정책의 예외를 놓칠 수 있습니다. 구현 가능성을 중심으로 보면 고객사 커뮤니케이션 관점의 표현을 놓칠 수 있고, 화면 구조를 중심으로 보면 콘텐츠 운영 흐름을 놓칠 수 있습니다.

이때 AI에게 보는 기준을 바꿔 문서를 검토하게 하면 도움이 됩니다. 개발자 관점, 디자이너 관점, QA 관점, 고객사 담당자 관점, 평가자 관점처럼 관점을 바꿔보는 방식입니다.

관점을 바꾸면 질문도 바뀝니다.

“이 부분은 구현 범위가 모호하지 않은가?”

“이 예외 케이스는 누락되지 않았는가?”

“이 표현은 고객사가 다르게 받아들일 수 있지 않은가?”

이런 질문이 먼저 나오면 문서의 빈틈을 한 번 더 확인할 수 있습니다. AI에게 다른 관점으로 검토하게 하는 목적은 해당 직군을 대체하는 것이 아닙니다. 작성자가 놓친 질문을 미리 발견하는 것입니다.

결국 AI에게 맡겨야 하는 일은 무엇일까?

LLM을 잘 활용하는 사람은 단순히 질문을 잘 쓰는 사람이 아닐 수 있습니다. 오히려 업무를 AI가 처리할 수 있는 구조로 나누어 맡길 줄 아는 사람에 가깝습니다.

작성은 마지막 단계입니다. 그 전에 읽고, 나누고, 비교하고, 의심하는 단계가 있습니다. AI는 바로 그 중간 단계를 맡길 때 가장 쓸모가 큽니다.

AI가 모든 판단을 대신해주지는 않습니다. 오히려 AI를 잘 활용할수록 사람이 판단해야 할 지점은 더 분명해집니다. AI가 정리한 결과를 바탕으로 무엇을 확정할지, 무엇을 다시 확인할지, 어떤 방향으로 조정할지는 결국 사람이 결정해야 합니다.

AI를 잘 활용한다는 것은 답을 더 많이 얻는 일이 아닙니다. 무엇을 결정해야 하는지, 무엇을 다시 확인해야 하는지 더 선명하게 드러내는 일입니다.

0