요구사항 정리해서 주기
무엇을 만들어 달라는 건지 글로 적어서 건네는 일이에요. 적힌 것만 만들어져요. 외주에게도 AI에게도 같은 원칙이에요.
쉽게 말하면
간판을 주문하는 날을 생각해 보세요. 간판집에 가서 "멋지게 해 주세요"라고만 말하고 오면, 완성된 간판은 간판집 사장님 취향으로 나와요. 반대로 가로 3미터, 바탕은 흰색, 글씨는 상호만 크게, 전화번호는 오른쪽 아래. 이렇게 적어 주면 적은 대로 나와요. 만드는 사람은 주문한 사람의 머릿속을 볼 수 없어서, 적힌 것만 만들 수 있어요. 요구사항 정리는 이 주문서 한 장을 쓰는 일이에요.
요구사항이라는 말이 거창하게 들리지만 실체는 단순해요. 무엇을 만들어 달라는 건지 글로 적은 목록이에요. 형식은 자유예요. 종이 한 장이어도 되고, 휴대폰 메모여도 돼요.
빈칸을 만드는 사람이 자기 짐작으로 채워요. 결과물을 받아 보고 나서야 서로 다른 그림을 그리고 있었다는 걸 알게 돼요.
짐작이 끼어들 틈이 없어요. 다르게 나오면 이 종이를 근거로 고쳐 달라고 말할 수 있어요.
적힌 것만 만들어져요
이 문서에서 한 문장만 가져가신다면 이거예요. 적힌 것만 만들어져요. 말한 것도 아니고, 머릿속에 있던 것도 아니고, 적힌 것만요.
말로 한 부탁은 시간이 지나면 서로 기억이 달라져요. 그리고 기억이 다를 때 꺼내 놓고 확인할 물건이 없어요. 결과물이 이상하게 나와도 "그때 그렇게 말씀하셨잖아요"라는 말 앞에서 할 수 있는 게 없고요.
"당연한 것"이 제일 위험해요
사장님에게 당연한 것은 만드는 사람에게 당연하지 않아요. "예약이 되면 당연히 취소도 되겠지"는 적지 않으면 안 만들어져요. 매일 그 일을 하는 사람일수록 당연한 게 많아서, 오래 장사한 사장님일수록 빠뜨리는 게 많아요. 당연하다고 느껴지는 것부터 적으세요.
적는 데는 또 하나의 효과가 있어요. 적다 보면 내 생각이 정리돼요. 말로는 다 아는 것 같던 일이, 적으려고 하면 안 정해진 데가 드러나요. 그 빈칸을 만드는 사람이 발견하게 하지 말고 사장님이 먼저 발견하는 거예요.
무엇을 적나: 다섯 칸이면 돼요
전문 문서처럼 쓸 필요 없어요. 아래 다섯 칸을 채우면 첫 판으로 충분해요. 다 합쳐 한 장이면 돼요.
| 칸 | 적는 것 | 예시 |
|---|---|---|
| 목적 한 문장 | 누가, 무엇을 하러 오는 곳인지 | "동네 손님이 전화 없이 필라테스 수업을 예약하는 곳" |
| 화면 목록 | 필요한 화면의 이름만 나열 | 소개 화면, 예약 신청 화면, 예약 확인 화면 |
| 화면마다 할 일 | 그 화면에서 손님이 하는 행동 | "날짜와 시간을 고르고 이름·연락처를 남긴다" |
| 안 만들 것 | 이번에는 뺀다고 못 박는 것 | 회원가입, 결제, 관리자 화면 |
| 완성 판정 문장 | 무엇이 되면 끝난 것으로 볼지 | "손님이 폰으로 예약을 넣으면 내가 확인할 수 있다" |
"안 만들 것" 칸이 힘이 제일 세요
만들 것 목록은 누구나 쓰는데, 안 만들 것 목록은 대부분 안 써요. 이 칸이 없으면 만드는 도중에 "이것도 필요하지 않을까요"가 계속 붙어서 일정과 비용이 같이 늘어나요. 뺀 것은 없어진 게 아니라 다음 차례로 미룬 거예요. 무엇을 먼저 빼는지는 MVP 문서의 기준을 그대로 쓰면 돼요.
- 1목적 한 문장부터 적어요. 이게 안 정해지면 나머지 칸이 다 흔들려요.
- 2손님이 되어 처음부터 끝까지 머릿속으로 걸어 봐요. 걸으면서 지나는 화면을 그대로 화면 목록에 적어요.
- 3화면마다 손님이 하는 행동을 한 줄씩 적어요. 기능 이름을 몰라도 돼요. "사진을 넘겨 본다"처럼 행동으로 적으면 만드는 사람이 알아서 옮겨요.
- 4뺄 것을 적어요. 지금 없어도 손님이 오늘 할 일을 끝낼 수 있는 건 다 이 칸으로 보내요.
- 5완성 판정 문장을 적고 끝내요. "무엇이 되면 끝"이 적혀 있어야 일이 끝나요.
AI에게 줄 때도 같은 원칙이에요
이 원칙은 외주에게만 통하는 게 아니에요. 스튜디오에 만들어 달라고 요청할 때도 AI는 사장님 머릿속을 못 봐요. [[prompt|프롬프트]]가 곧 AI에게 주는 요구사항이에요. 다섯 칸을 채워 봤다면 그 내용이 그대로 좋은 요청문이 돼요.
| 이렇게만 적으면 | 이렇게 적으면 |
|---|---|
| "예약 사이트 만들어 줘" | "동네 필라테스 예약을 받는 화면. 손님이 날짜와 시간을 고르고 이름·연락처를 남겨요" |
| "보기 좋게 해 줘" | "글씨는 크게, 신청 버튼은 화면에서 제일 눈에 띄게 해 주세요" |
| "이것저것 다 되게 해 줘" | "이번에는 회원가입과 결제는 빼 주세요" |
AI에게는 한 번에 다 안 줘도 돼요
외주는 중간에 말을 바꾸면 비용이 붙지만, AI는 하나 시키고 확인하고 다음을 시켜도 돼요. 그래서 다섯 칸 중 목적 한 문장과 안 만들 것만 먼저 주고, 나머지는 결과를 보면서 한 줄씩 보태는 방식이 잘 맞아요.
직접 해보기
다섯 칸 중 첫 칸으로 요청해 보세요
머릿속 아이디어를 목적 한 문장으로 줄여서 스튜디오에 넣어 보세요. "누가, 무엇을 하러 오는 곳" 한 줄이면 돼요. 나온 결과가 생각과 다르면, 그 다른 지점이 바로 적었어야 했던 요구사항이에요.
스튜디오 열기실제로 벌어지는 일
장면 1 · 외주 결과물이 생각과 다르게 나왔다
“말씀하신 대로 만들었는데요. 취소 기능은 얘기에 없었어요. 추가하시려면 별도 비용입니다.”
적어 둔 게 없으면 이 대화에서 사장님이 불리해요. 서로 기억이 다른데 증거가 없거든요. 요구사항 문서가 있으면 이야기가 달라져요. 적혀 있는 건 원래 범위라서 고쳐 달라고 할 수 있고, 안 적혀 있는 건 추가 요청이라 값을 치르는 게 맞아요. 어느 쪽이든 기준이 있으니 감정 싸움이 안 돼요. 그래서 이 문서는 계약서에 붙는 부속 문서이기도 해요.
장면 2 · 일이 끝나지 않는다
“이 정도면 끝난 것 아닌가요? 사장님이 자꾸 하나씩 더 말씀하셔서요.”
완성 판정 문장이 없으면 일의 끝을 정하는 사람이 없어요. 사장님은 볼 때마다 아쉬운 게 보이고, 만드는 쪽은 끝나지 않는 일에 지쳐요. "손님이 폰으로 예약을 넣으면 내가 확인할 수 있다. 여기까지가 이번 일" 처럼 한 문장을 미리 적어 두면, 그 뒤에 보이는 아쉬움은 다음 일감으로 넘길 수 있어요.
자주 묻는 것
- Q. 개발을 하나도 모르는데 요구사항을 쓸 수 있나요?
- 쓸 수 있어요. 오히려 기능 이름을 쓰려고 하면 어긋나요. 손님의 행동으로 적으세요. "손님이 사진을 넘겨 보고, 마음에 든 걸 골라서 문의를 남긴다"처럼요. 이걸 기술 용어로 옮기는 건 만드는 사람의 일이에요. 사장님의 일은 손님과 가게를 정확히 적는 것이고, 그건 사장님이 세상에서 제일 잘해요.
- Q. 얼마나 자세히 적어야 하나요?
- 첫 판은 한 장이면 돼요. 자세함보다 빠진 칸이 없는 게 중요해요. 목적, 화면 목록, 화면마다 할 일, 안 만들 것, 완성 판정. 이 다섯 칸이 다 있으면 짧아도 좋은 문서예요. 열 장짜리인데 안 만들 것 칸이 없는 문서보다, 한 장인데 다섯 칸이 다 있는 문서가 나아요.
- Q. 그림도 그려야 하나요?
- 화면 배치까지 정하고 싶으면 그림이 글보다 정확해요. 손으로 그린 스케치를 사진 찍어 붙여도 충분하고, 부끄러워할 일이 아니에요. 다만 그림이 없어도 다섯 칸이 있으면 일은 시작할 수 있어요. 그림은 있으면 좋은 것, 다섯 칸은 없으면 안 되는 것이에요.
- Q. 적어 놓고 나중에 바꾸면 안 되나요?
- 바꿔도 돼요. 만들다 보면 생각이 바뀌는 게 정상이에요. 다만 두 가지를 지키세요. 바꾼 내용을 문서에도 반영하고, 바꾸는 값이 있다는 걸 받아들이는 것. 외주라면 추가 비용이나 일정이 붙는 게 정당하고, 그 견적이 정당한지는 바뀐 글자 수가 아니라 다시 만들어야 하는 범위로 판단해요. 문서를 안 고치고 말로만 바꾸면 처음부터 다시 어긋나기 시작해요.
- Q. 업체가 요구사항 문서를 대신 써 준다는데 맡겨도 되나요?
- 초안을 받는 건 좋아요. 전문가가 빠진 칸을 찾아 주기도 하고요. 다만 최종 확인은 반드시 사장님이 해야 해요. 이 문서는 나중에 견적서와 결과물을 판정하는 기준인데, 기준을 상대방이 혼자 쓰면 기준이 상대방에게 유리해져요. 받은 초안을 한 줄씩 읽으면서 "우리 가게 이야기가 맞나"를 확인하고 서명하세요.
확인해 보세요
외주에 예약 화면을 맡기려고 해요. 말로 충분히 설명했고 서로 잘 통했어요. 다음에 할 일은?
하나 더
완성된 예약 화면에 취소 기능이 없어요. 요구사항 문서에도 취소 이야기는 없었어요. 이 상황은?
더 깊이 (안 읽어도 괜찮아요)
요구사항과 견적의 관계 · 견적은 요구사항의 가격표예요. 요구사항이 흐리면 업체는 두 가지 중 하나를 해요. 위험한 만큼 값을 올려 부르거나, 싸게 부르고 나중에 추가 비용으로 메꾸거나요. 어느 쪽이든 사장님 손해예요. 반대로 다섯 칸이 정확하면 여러 업체에 같은 문서를 주고 견적을 나란히 비교할 수 있어요. 문서 없이 받은 견적 세 장은 서로 다른 물건의 가격이라 비교 자체가 안 돼요.
"무엇을"과 "어떻게"를 나누는 선 · 요구사항에는 무엇을 적고 어떻게는 적지 않는 게 원칙이에요. "손님이 예약을 넣으면 내가 알 수 있어야 한다"까지가 사장님의 영역이고, 그걸 문자로 할지 메일로 할지 화면으로 할지는 만드는 사람이 제일 잘 아는 영역이에요. 어떻게까지 지정하면 더 비싸고 더 나쁜 방법을 강요하게 되는 경우가 있어요. 다만 예외가 하나 있어요. 이미 쓰는 도구가 있어서 반드시 거기 붙어야 한다면, 그건 어떻게가 아니라 조건이니까 적어야 해요.
간판 비유가 안 맞는 지점 · 간판은 한 번 달면 끝이지만 서비스는 열고 나서도 계속 바뀌어요. 그래서 요구사항 문서를 한 번 쓰고 액자에 넣는 게 아니라, 바뀔 때마다 같이 고치는 살아 있는 문서로 다뤄요. 그리고 간판 주문서는 완성품과 1:1로 맞아떨어지지만, 서비스는 만들다 보면 적을 때 몰랐던 갈림길이 나와요. 그때마다 문서가 판단 기준이 되는 것이지, 문서가 판단을 대신해 주지는 않아요.
이것만 기억하세요
- ·적힌 것만 만들어져요. 말한 것도 머릿속에 있던 것도 아니고, 적힌 것만요
- ·다섯 칸이면 돼요. 목적 한 문장, 화면 목록, 화면마다 할 일, 안 만들 것, 완성 판정 문장
- ·당연해 보이는 것부터 적어요. 사장님에게 당연한 건 만드는 사람에게 당연하지 않아요
- ·안 만들 것 칸이 일정과 비용을 지켜요. 뺀 것은 없어진 게 아니라 다음 차례예요
- ·AI에게도 같은 원칙이에요. 프롬프트가 곧 요구사항이에요