기획서를 쓰는 법이 곧 실력이 되는 이유

기획서가 왜 실력인지, 저는 AI에게 일을 시켜 보고서야 알았습니다. 그 전까지는 문서 작업이라고만 생각했거든요.

AI에게 "일정 위젯을 만들어 줘"라고 적었어요. 잠시 뒤 화면이 나왔는데 색도 맞고 카드 모양도 그럴듯했습니다. 다 됐다고 생각했죠. 그런데 휴대폰 홈화면에 실제로 붙여 보니 오늘 일정이 안 보이더군요. 앱을 먼저 열어야 새 일정이 들어왔고, 로그아웃한 뒤에도 직전 사용자의 일정이 그대로 남아 있었고요.

위젯은 분명히 있었습니다. 그런데 제가 필요했던 일은 하나도 안 끝났어요.

이 장면을 한 번 겪고 나면 기획서가 다르게 보입니다. 기획서는 멋진 아이디어를 길게 설명하는 문서가 아니에요. 만드는 사람에게 열정을 불어넣는 선언문은 더더욱 아니고요. 끝났다는 말을 무엇으로 확인할지 미리 적어 두는 문서입니다.

코드를 모르는 사람이 AI와 제품을 만들수록 이게 더 중요해집니다. 코드를 읽어서 맞고 틀림을 가릴 수 없다면 사용자가 실제로 겪는 장면으로 결과를 검수하는 수밖에 없으니까요. 저는 기능 이름을 많이 아는 것보다 그 장면을 정확하게 쓰는 쪽이 훨씬 오래 남는 실력이라고 봅니다.

같은 기능 이름, 전혀 다른 끝 그림

"일정 공유"라고 적어 놓으면 다들 같은 기능을 떠올릴 것 같죠. 그런데 누가 누구의 일정을 보는지, 상대가 초대를 거절하면 어떻게 되는지, 관계를 끊은 뒤에 과거 일정이 남는지에 따라 완전히 다른 제품이 됩니다. "결제를 붙인다"도 마찬가지예요. 결제 창이 뜨는 것만 말하는 건지, 돈이 실제로 들어오고 이용 권한이 열리는 것까지인지, 취소했을 때 권한이 닫히는 것까지인지 전혀 모호합니다. 기능 이름은 출발점이지 완료 기준이 아니에요.

그래서 저는 기획할 때 사람 한 명을 장면 하나에 먼저 세웁니다.

"출근 준비 중인 사용자가 앱을 열지 않고 홈화면에서 오늘 첫 일정을 확인해요."

이 한 문장이 생기면 필요한 게 저절로 갈립니다. 홈화면에서 보여야 하고, 새 일정이 반영돼야 하고, 잠금화면에 개인 정보가 어디까지 나올지도 정해야 하죠. 반대로 이 장면에 필요 없는 복잡한 설정은 뒤로 밀어 둘 수 있고요.

좋은 기획은 기능을 늘리는 문서가 아니라 범위를 자르는 문서입니다. 접은 기능과 접은 이유를 굳이 기록해 두는 것도 같은 이유예요. 넣을 수 있다는 사실과 지금 넣어야 한다는 판단은 다릅니다.

해결책부터 말하면 기획이 흐려져요

"알림 기능이 필요해요."

이 문장만 놓고 보면 알림을 열 개도 만들 수 있습니다. 왜 필요한지가 없거든요. 손님이 예약을 잊는 건지, 직원이 변경을 놓치는 건지, 사장이 앱을 자주 안 여는 건지에 따라 만들어야 할 게 전부 달라집니다.

문제 장면을 먼저 적으면 이렇게 바뀝니다.

"예약 시간이 바뀌었는데 담당 직원이 이전 시간을 보고 준비했어요. 변경 사실이 담당자 화면과 알림에 함께 남아야 해요."

이제 검수가 됩니다. 시간을 바꾸고, 담당자 화면을 열어 보고, 알림을 확인하면 되니까요. "알림이 구현됐습니다"라는 보고보다 훨씬 단단하죠.

사람에게 일을 맡길 때 이유가 필요한 것과 닮았습니다. 지시에 왜를 붙여야 하는 이유에서 말한 명분은 AI에게도 그대로 필요해요. 다만 AI는 서운해하지 않는 대신 빈칸을 아주 그럴듯하게 채웁니다. 그래서 이유만 주면 안 되고 통과 장면까지 줘야 하는 거예요.

긴 양식보다 질문 다섯 개

저는 문서 형식을 갖추기 전에 이 질문들부터 채웁니다.

누가 언제 쓰는가. "사용자"라고 쓰지 말고 출근 전 사장, 예약을 확인하는 직원, 초대를 받은 가족처럼 상황과 함께 적으세요.

지금 무엇이 막혀 있는가. 기능이 없다는 사실이 아니라 그 때문에 어떤 일이 틀어지는지를 적습니다. 앱을 자주 안 연다, 변경이 전달되지 않는다, 누가 결제했는지 섞인다 — 이런 식으로요.

끝나면 무엇이 보여야 하는가. 파일이 생겼다거나 화면이 그려졌다는 말은 완료 기준이 못 됩니다. 홈화면에서 오늘 일정이 보인다, 취소된 결제의 권한이 닫힌다, 로그아웃하면 이전 데이터가 사라진다처럼 실제 사용 장면으로 쓰세요.

실패하면 어떤 모습인가. 정상 흐름만 적어 두면 예외가 나중에 사고로 돌아옵니다. 인터넷이 끊겼을 때, 중간에 창을 닫았을 때, 다른 계정으로 다시 들어왔을 때.

하지 않을 것은 무엇인가. 이번 작업에서 지원하지 않는 언어, 기기, 결제 방식, 자동화 범위를 적습니다. 이 칸이 비어 있으면 요구가 계속 자라고, 결국 끝난 시점을 아무도 모르게 돼요.

정식 문서가 아니어도 됩니다. 짧은 메모라도 답이 선명하면 그대로 쓸 수 있어요. 거꾸로 화면 목록이 아무리 길어도 이 질문들이 비어 있으면 중간 산출물만 쌓입니다. 관리자가 직접 일을 해치우는 대신 과정을 설계해야 하는 이유와 정확히 같은 구조예요.

성공 장면 옆에 반대 장면을 하나씩

정상 동작만 확인하면 제품은 가장 좋은 날에만 맞습니다. 실제 문제는 중간이 끊겼을 때 생기거든요.

일정 저장이라면 저장 버튼을 누른 순간만 보지 말고 통신이 끊겼을 때 실패가 사용자에게 알려지는지 봐야 하고, 계정 전환이라면 새 계정 화면만 볼 게 아니라 이전 계정의 내용이 실제로 사라졌는지 봐야 합니다. 결제도 성공 화면보다 창을 닫았을 때 다시 시도가 되는지가 중요하고요.

저는 이걸 "반대 장면"이라고 적어 둡니다. 해야 하는 것의 반대를 한 번 실행해 보는 거예요.

• 보여야 하는 정보라면 안 보일 때를 확인한다
• 숨겨야 하는 정보라면 다른 계정에서 보이는지 확인한다
• 한 번만 실행돼야 한다면 다시 눌렀을 때를 확인한다
• 지워져야 한다면 새로고침과 재로그인 뒤를 확인한다

이 목록은 개발 용어를 하나도 몰라도 쓸 수 있습니다. 오히려 사용자 언어라서 결과 검수에는 더 강해요. 코딩보다 어려웠던 부분도 결국 코드를 쓰는 손이 아니라 무엇을 확인할지 정하는 일이었습니다.

기획서를 두고 자주 부딪히는 말들

기획서 이야기를 꺼내면 금세 문서 분량과 직책 이야기로 흘러갑니다. 그런데 실제로 문제가 되는 건 문서가 길고 짧음이 아니라 판단을 누가 쥐고 있느냐예요.

"AI가 알아서 좋은 기획까지 해 주면 되잖아요." AI는 선택지를 넓히고 빠진 질문을 찾아내는 데 정말 뛰어납니다. 비슷한 기능의 보편적인 흐름도 잘 제안하고요. 초안은 맡겨도 됩니다. 그런데 어떤 장면이 우리 제품의 끝인지는 대신 알 수가 없어요. 사용자가 앱을 열어도 되는지, 홈화면에서 끝나야 하는지, 잠금화면에 이름이 보여도 되는지는 사업과 사용 맥락의 판단이거든요. 그 빈칸을 AI가 채우면 평균적인 제품은 나올지 몰라도 내가 풀려던 문제가 끝났다는 보장은 어디에도 없습니다. 물론 이걸 "AI 기획은 믿지 마라"로 뒤집으면 곤란해요. 초안과 반론은 맡기되 문제 장면과 최종 선택의 책임은 사람이 가져야 한다는 이야기입니다. AI에게 맡기면 안 되는 일의 경계도 여기서 시작해요.

"기획서는 길수록 빈틈이 적다." 긴 문서가 많은 내용을 담는 건 맞습니다. 다만 같은 말을 여러 방식으로 반복하면 핵심은 오히려 흐려져요. 화면 설명이 아무리 많아도 통과 기준이 없으면 작업자는 눈에 보이는 첫 결과를 완료로 판단합니다. 그렇다고 짧을수록 좋다는 것도 아니에요. 결제나 개인정보처럼 실패 비용이 큰 기능은 예외 흐름과 권한을 자세히 적어야죠. 길이는 위험과 복잡성의 결과여야지 성실함의 증거가 되면 안 됩니다. 좋은 기준은 읽는 시간이 아니라 반려할 수 있느냐예요. 결과를 보고 "왠지 좀 다른데요" 말고 어느 장면이 기준과 다른지 짚을 수 있어야 합니다.

"일단 만들어 보고 고치는 게 더 빠르다." 되돌리기 쉬운 화면은 그럴 수 있어요. 문구, 간격, 버튼 위치는 만들어 놓고 보는 편이 나을 때가 많죠. 그런데 돈의 귀속, 데이터 접근 권한, 삭제 뒤 노출처럼 틀린 상태가 차곡차곡 쌓이는 영역은 얘기가 완전히 다릅니다. 잘못 만든 뒤 고치려면 이미 생긴 기록과 사용자 상태까지 같이 복구해야 하거든요. 화면 고치는 것과는 비교가 안 됩니다. 결제를 붙이며 배운 것에서 기능보다 귀속과 복구를 먼저 본 이유가 이거예요. 그러니 방법 자체를 금지할 게 아니라 되돌릴 수 있는가, 잘못된 데이터가 남는가, 남에게 피해가 가는가로 실험 범위를 정하면 됩니다.

"기획은 아이디어 낸 사람이 하고 개발자는 실행만 하면 된다." 아이디어를 낸 사람이 문제를 제일 잘 아는 건 사실입니다. 그렇다고 실행하는 사람의 질문을 방해로 취급하면 기획이 약해져요. 실제로 만들기 시작해야 충돌과 빈칸이 드러나거든요. 좋은 실행자는 "이 경우엔 뭐가 맞나요"라고 묻고, 좋은 기획자는 그 질문을 받아 문서를 고칩니다. 역할은 나누되 판단의 왕복까지 막으면 안 돼요. 설계와 실행을 구분한다는 말이 대화를 끊는다는 뜻은 아니니까요. 현장을 아는 사람이 직접 도구를 만들 때 빈칸을 빨리 보는 것도 이 왕복이 짧아서입니다. 현장이 있는 사람이 도구를 만들 때는 구현 자랑이 아니라 이 질문의 거리에 관한 이야기예요.

그래도 기획서를 과신하면 안 됩니다

기획서가 아무리 정확해도 세상은 바뀝니다. 사용자는 예상과 다르게 행동하고, 운영 중에 새로운 제약이 튀어나와요. 문서를 계약처럼 얼려 두면 새로 발견한 사실보다 과거에 쓴 문장이 우선되는 이상한 상황이 생깁니다.

그러니 기획서는 틀리지 않는 문서가 아니라 틀린 걸 발견했을 때 어디를 고칠지 알려 주는 기준선이어야 해요. 판단이 바뀌면 이유와 함께 고쳐 적고, 이전 범위에서 무엇이 빠지는지도 같이 남깁니다.

기획서를 잘 썼다는 이유로 실제 확인을 건너뛰는 것도 금물이에요. 문서에 "로그아웃하면 일정이 사라진다"고 적었다고 제품에서 사라지는 건 아니잖아요. 그 장면을 직접 실행해 봐야 합니다. 다음번엔 다르게 하고 싶은 것들을 빌드 뒤 복기하는 법에 남겨 두는 것도 문서와 실제 사이의 거리를 잊지 않으려는 장치고요.

기획의 실력은 어려운 용어에서 나오지 않습니다. 일을 시키기 전에 끝난 장면을 보고, 결과가 왔을 때 그 장면으로 돌아갈 수 있느냐에서 나와요. 위젯 모양이 아무리 예뻐도 홈화면에서 오늘 일정이 안 보이면 아직 안 끝난 겁니다. 그 말을 작업 전에 쓸 수 있다면 이미 기획의 가장 중요한 부분을 하고 계신 거예요.

아직 남는 질문

작은 기능도 기획서를 써야 하나요? 문서 형식까지 갖출 필요는 없어요. 누가 언제 쓰는지, 끝나면 뭐가 보여야 하는지, 하지 않을 것만 짧게 적어도 충분합니다. 되돌리기 어렵거나 돈과 개인정보가 걸릴수록 예외 장면을 더 자세히 쓰시고요.

개발 용어를 모르는데 완료 기준을 어떻게 적나요? 사용자가 하는 행동과 화면에 보이는 결과로 적으면 됩니다. "데이터 동기화" 대신 "다른 기기에서 추가한 일정이 홈화면에 나타난다"라고 쓰는 식이죠. 모르는 용어를 흉내 내는 것보다 검수할 수 있는 장면 쪽이 훨씬 정확해요.

만들다가 요구가 바뀌면 처음 기획이 실패한 건가요? 아닙니다. 새로 알게 된 사실 때문에 판단이 바뀔 수 있어요. 다만 무엇이 왜 바뀌었고 그 변화로 기존 완료 기준이 어떻게 달라지는지는 반드시 남겨야 합니다. 이유 없는 변경이 반복되면 재작업이지만, 근거 있는 수정은 제품을 배우는 과정이거든요.