AI 프로젝트 기획서, 경영진 설득에 실패했던 이유

AI 도입 기획서를 처음 올렸을 때, 결과는 반려였다. 기술적으로 틀린 부분은 하나도 없었는데도 그랬다. 결재 창구에서 보류 도장을 받고 돌아오던 그 오후를 아직도 또렷하게 기억한다. 23년째 이 일을 해오며 기획서를 수십 번은 써봤다고 생각했는데, 이번엔 뭐가 문제였는지 한동안 스스로도 납득이 안 됐다. 이 글은 그 기획서가 왜 반려됐는지, 3주 뒤 다시 올린 버전은 왜 통과됐는지를 그대로 복기한 기록이다.

처음 올린 기획서의 구성 (기술 중심)

1차 기획서는 시작부터 끝까지 기술 설명에 편중돼 있었다. 총 47장 중 32장이 다음 세 가지를 다뤘다.

• 모델 선택
• 온프레미스 vs API 연동
• RAG(검색증강생성) 구조 설계

아키텍처 다이어그램만 해도 처음엔 파워포인트 스마트아트로 그리다 화살표가 자꾸 꼬여서 결국 draw.io로 옮겨 다시 그렸는데, 도구를 바꾸고 나서야 다이어그램 관리가 한결 수월해졌다. 파워포인트는 도형 몇 개 정도의 단순한 그림엔 충분하지만, 요소가 늘어나고 연결 관계가 복잡해질수록 draw.io처럼 다이어그램 전용으로 만들어진 도구가 확실히 편했다 — 버전 관리도 쉽고, 나중에 요소를 추가하거나 구조를 바꿀 때도 레이아웃이 덜 깨졌다.

돌아보면 그게 첫 번째 신호였다. 다이어그램의 완성도에만 신경 쓰고 있었지, 그걸 누가 왜 보는지는 정작 생각하지 않았다는 신호. 나로서는 이 32장이 가장 자신 있는 부분이었고, 최신 아키텍처 사례까지 인용해가며 왜 이 구조가 맞는지 설명하는 데 공을 들였다. 정작 “이걸 왜 하는가”에 해당하는 페이지는 마지막 3장, 그것도 목표를 뭉뚱그린 문장 몇 줄이 전부였다.

경영진 반응과 반려 사유

결과부터 말하면, 반려 사유는 “기대효과 정량화 필요” 한 줄이었다. 아키텍처 설명에 발표 시간 대부분을 쓰고 나니, 정작 나온 질문은 예상 밖이었다 — 이 도입으로 실제로 얼마나 아낄 수 있는지를 구체적인 수치로 알고 싶어 했다. 다음 장을 넘겼지만 거기엔 숫자가 없었다. 정성적인 기대효과만 언급하며 얼버무리자 분위기가 눈에 띄게 가라앉는 게 느껴졌다. 이런 상황에서 흔히 나타나는 패턴이 그대로 반복됐다 — 핵심 질문에 제대로 답을 못 하면 그 뒤로는 누구도 더 캐묻지 않는다는 것.

기술 설명을 아무도 반박하지 않았다는 것과, 아무도 그걸 승인 근거로 삼지 않았다는 것은 전혀 다른 문제였다. 틀린 말을 한 게 아니라, 상대가 애초에 궁금해하지 않는 걸 90%나 채워 넣은 셈이었다. 배경 설명과 기술 세부사항부터 늘어놓으면 핵심에 닿기도 전에 경영진 청중의 관심을 잃기 쉽다는 지적^[1]이, 그대로 재현된 셈이었다. 기술을 아는 사람에게는 아키텍처가 곧 설득의 근거처럼 느껴지지만, 예산과 우선순위를 결정하는 자리에서는 순서가 반대라는 걸 그제야 체감했다.

다시 쓴 기획서 — 숫자로 시작하기

재작성의 시작점은 숫자를 만드는 방식을 통째로 바꾸는 것이었다. 반려 다음 날부터 숫자를 모으기 시작했다. 처음엔 엑셀로 팀원 다섯 명의 업무 시간을 정리했는데, 각자 파일을 따로 채워 메일로 보내오니 버전이 꼬이고 취합에 적잖은 시간이 들었다. 구글 스프레드시트로 옮겨 실시간으로 같이 채우게 하자 그 문제는 사라졌다. 혼자 정리하는 작업이었다면 엑셀이 더 편했겠지만, 여러 명이 동시에 같은 숫자를 검증해야 하는 상황에서는 구글 시트 쪽이 훨씬 나았다. 2주간 실제 업무 로그를 잰 끝에 다음 세 줄을 뽑아냈다.

• 현재 소요: 월 100시간 안팎
• 도입 후 예상: 월 40시간대
• 절감액 환산: 월 150만원 안팎

재작성판 초안은 클로드로 먼저 뽑았고, 표와 계산식이 많이 들어가는 부분은 챗GPT에게 다시 물어 다듬었다.

• 클로드: 문단 흐름 정리
• 챗GPT: 수식·계산 로직 검증

이 두 개를 번갈아 쓰는 습관은 그 뒤로도 계속 남았다. 숫자를 정리하는 과정에서 뜻밖의 사실도 드러났다. 팀원 중 두 명은 실제 업무 시간이 내 예상보다 훨씬 길었고, 반대로 한 명은 이미 나름의 방식으로 절반쯤 자동화를 해두고 있었다. 기획서 밖에서 이런 걸 미리 확인하지 않았다면, 숫자를 채웠어도 또 다른 곳에서 반박당했을 것이다.

통과된 버전에서 바뀐 건 내용이 아니라 순서였다. 재작성판은 첫 페이지부터 숫자로 시작했고, 기술 설명은 부록으로 뒤로 뺐다. 이는 이른바 결론부터 말하기(BLUF)^[2] 구조이자, 결론을 맨 앞에 두고 근거를 뒤에 배치하는 피라미드 원칙^[3]과 같은 방향이었다. 아키텍처 다이어그램은 15장 중 딱 2장으로 줄였다. 발표 분위기부터 확연히 달라졌다. 이번엔 그 숫자가 어떻게 산출됐는지를 확인하는 질문이 먼저 나왔다 — 반박이 아니라 검증이었다.

뒤이어 적용 가능한 시점을 묻는 질문이 이어졌고, 그 순간 이 기획서가 통과되겠다는 걸 직감했다. 3주 전엔 발표 시간 내내 방어하는 자세였다면, 이번엔 발표를 마친 뒤 남은 시간 전부가 다음 단계를 묻는 대화로 채워졌다. 아키텍처도, 모델 선택 근거도 1차 기획서와 거의 그대로였다. 순서만 바뀌었을 뿐인데 반응은 완전히 달랐다. 같은 사람, 같은 회의실, 같은 아키텍처였는데 결과만 정반대였다는 게 지금 봐도 신기하다.

그 뒤로 습관이 된 체크리스트

이 경험 이후로 원칙이 하나 생겼다. 어떤 기획서든 첫 페이지에 세 줄짜리 정량 지표부터 넣는다는 것이다. 노션에 “기획서 체크리스트” 템플릿을 만들어 맨 위 항목에 “숫자 3개 있는가”를 체크박스로 넣어뒀을 정도다. 컨플루언스도 한동안 써봤다. 혼자 빠르게 템플릿을 복제하고 고치는 용도로는 노션 쪽이 손에 더 붙었다. 여러 팀이 권한을 나눠 문서를 관리해야 하는 조직 규모라면 컨플루언스가 나을 수 있지만^[4], 혼자 반복해서 기획서를 찍어내는 내 작업 방식엔 오히려 과했다.

경영진 설득은 기술을 얼마나 잘 아는지의 문제가 아니라, 숫자를 얼마나 먼저 보여주는지의 문제였다 — 그 뒤로 올린 기획서마다 이 사실을 다시 확인하고 있다. 지금도 발표 자료를 만들다가 아키텍처 슬라이드부터 손이 가려는 순간이 있다. 그럴 때마다 그 반려 도장 찍힌 표지를 떠올린다. 기술이 부족해서 떨어진 게 아니라, 순서가 틀렸을 뿐이었다는 걸 잊지 않으려고 그런다.

관련 글

• AI 도입 체크리스트: 도구 선정 전 확인할 5단계
• AI 도입 첫 3개월, 우리 팀이 놓쳤던 것들