MVP가 무엇인지는 이미 여러 번 읽으셨을 거예요. 문제는 그다음이에요. 개발사 문의 폼 앞에 앉으면 손이 멈춰요. "퇴근 후 클래스 예약 앱을 만들고 싶어요"라고 보내면 돌아오는 답은 견적서가 아니라 질문 목록이거든요. 어떤 문서를 어디까지 만들어서 보내야 하는지, 그걸 알려주는 글은 의외로 없어요.
이 글은 개념 설명을 하지 않아요. 착수 직전, 개발사에 실제로 넘길 산출물만 다뤄요. 그리고 발주자 시점이 아니라 그 문서를 받아 견적을 내는 쪽의 시점에서 써요. 무엇을 남기고 무엇을 뺄지 고르는 기준 자체가 아직 안 잡혔다면 MVP 개발 완전 가이드의 범위 정하기 부분을 먼저 보시고, "이 앱이 대체 어떤 문제를 푸는 건가"부터 막혀 있다면 비개발자 창업자를 위한 앱 기획 첫 단추가 그 앞 단계예요. 여기서는 방향이 정해졌다고 보고 시작할게요. 예시는 하나로 끝까지 끌고 갈게요. 호스트가 원데이 클래스를 열고 수강생이 예약·결제하는 앱이에요.
솔직히 말하면 개발사는 받은 기획서를 처음부터 끝까지 정독하지 않아요. 견적을 내야 하니까 특정 정보를 찾아 읽어요. 문의 메일을 열었을 때 저희가 실제로 채우려는 칸은 네 개예요.
이 네 칸이 채워지면 저희는 보통 하루 이틀 안에 견적을 드려요. 안 채워지면 견적 대신 질문 목록이 돌아가고, 그 질문에 답하다 보면 결국 창업자분이 이 네 칸을 직접 채우게 돼요. 순서가 뒤로 밀릴 뿐 해야 할 일은 같아요.
중요한 건 이 네 칸이 아이디어의 좋고 나쁨과 아무 상관이 없다는 점이에요. 시장이 크다는 설명, 경쟁사 분석, 3년 뒤 로드맵은 읽으면 반갑지만 견적을 1원도 바꾸지 못해요. 기획서를 잘 썼다는 건 문장이 매끄럽다는 뜻이 아니라, 받는 쪽이 네 칸을 스스로 채울 수 있다는 뜻이에요. 아래에 정리한 산출물은 전부 그 네 칸을 채우는 도구라고 보시면 돼요.
순서가 있어요. 앞 문서가 뒤 문서의 재료가 되기 때문에 건너뛰면 뒤에서 막혀요.
검증하려는 것을 한 문장으로 적어요. "퇴근길에 당일 저녁 클래스를 발견한 직장인은 그 자리에서 결제까지 마친다" 정도면 충분해요. 여기서 상한선을 말씀드리면, 정말 한 문장이면 끝이에요. A4 열 장짜리 시장 분석은 견적을 바꾸지 못해요. 이 한 줄이 필요한 이유는 따로 있어요. 뒤에 만들 세 문서에서 무엇을 넣고 뺄지 정하는 기준이 여기서 나오거든요. 화면 목록이 스무 개를 넘어가는 경우, 원인은 대개 이 한 줄이 비어 있는 거예요.
서비스를 쓰는 사람의 종류를 적고, 각 사람이 하는 일을 동사로 나열해요.
충분 기준은 역할 3개 이하, 역할당 행동 5개 이하예요. 이 안에 안 들어오면 MVP 규모가 아니라고 봐도 돼요. 그리고 자주 빠지는 게 마지막 줄, 운영자예요. "관리자 페이지"는 기획서에 거의 안 적히는데 견적에는 반드시 들어가요. 환불을 누군가는 처리해야 하니까요.
화면 이름만 나열하고 옆에 한 줄씩 붙여요. 클래스 목록, 클래스 상세, 예약하기, 결제, 예약 완료, 내 예약, 로그인, 클래스 등록, 예약자 명단, 운영자 대시보드. 이 예시는 열 개예요. 스무 개를 넘어가면 MVP가 아니라 1.0이에요. 재미있는 건, 세어보는 행위 자체가 범위를 알려준다는 거예요. 목록을 만들다가 "이게 왜 이렇게 많지?" 싶은 순간이 오면 그게 신호예요.
화면을 화살표로 이어요. 최소 세 갈래면 돼요. 핵심 행동, 가입·로그인, 그리고 결제가 있다면 결제. "클래스 목록 → 상세 → 예약하기 → 로그인 → 결제 → 완료"처럼 한 줄로 적어도 괜찮아요. 종이 한 장이면 충분하고, 여기서도 상한선이 있어요. 예외 경로는 그림으로 그리지 말고 한 줄 문장으로만 적으세요. "정원이 차면 대기 신청으로 바뀐다", "결제 실패하면 예약은 잡히지 않는다" 같은 문장이요. 이 한 줄들이 화살표 그림보다 견적을 훨씬 크게 바꿔요.
네 문서를 다 만들었다면 앞에서 말한 네 칸이 저절로 채워져요. 화면 목록이 화면 수를, 역할 목록이 역할 수를, 화면 흐름의 결제·본인인증 구간이 외부 연동을, 각 화면에서 사용자가 입력하는 항목이 데이터 저장 범위를 알려주거든요. 그래서 이 순서를 지키면 "기획서를 어떻게 써야 하나"가 아니라 "네 칸이 채워졌나"만 확인하면 돼요. 반대로 아무리 두꺼운 문서라도 네 칸 중 하나가 비어 있으면 견적은 하한과 상한이 크게 벌어진 범위로 나와요. 개발사가 성의가 없어서가 아니라, 비어 있는 칸이 최악일 때를 함께 계산해야 하기 때문이에요.
기획을 다룬 글에는 "기술 요구사항 목록을 미리 만드세요"라는 조언이 자주 나와요. 저희도 IT 프로젝트 기획 가이드에서 같은 표현을 썼어요. 목록에 담긴 항목 자체는 맞아요. 플랫폼, 로그인 방식, 결제 형태, 알림, 저장할 데이터 — 견적을 낼 때 저희가 실제로 확인하는 것들이거든요. 걸리는 건 이름이에요. "기술 요구사항"이라고 부르면 창업자분들은 기술을 지정해 달라는 뜻으로 읽고, DB나 서버 구성까지 적어 오세요. 정작 그 목록에 있는 항목은 대부분 기술이 아니라 사업 판단이고요. 그래서 경계선을 다시 그어볼게요.
기준은 기술이냐 아니냐가 아니라 비즈니스 결정이냐 구현 결정이냐예요.
DB 구조, 기술 스택, 서버 구성, 권한을 어떻게 구현할지는 개발사 몫으로 남기는 편이 오히려 견적을 정확하게 만들어요. 이유가 있어요. 개발사는 기획서에 적힌 기술 지정을 요구사항으로 읽어요. "MySQL로 해주세요"라고 적혀 있으면 왜 필요한지 되묻지 않고 그대로 반영해요. 근거 없는 제약이 하나 붙은 만큼 선택지가 줄고, 줄어든 선택지는 대개 금액으로 돌아와요. 검증되지 않은 기술 지정은 견적을 낮추지 않고 올려요.
반대로 개발사가 절대 대신 정해줄 수 없는 게 하나 더 있어요. 성공·실패 지표예요. "출시 4주 안에 예약 30건, 그중 재예약 5건"처럼 숫자로 적어두세요. 이 숫자가 없으면 나중에 무엇을 빼도 되는지 판단할 기준이 사라져요.
참고로, 여러 업체에 같은 조건을 뿌려 제안을 받는 단계라면 RFP라는 별도 문서가 필요해요. RFP는 "우리가 이런 조건으로 발주하니 제안해주세요"라는 발주 문서이고, 지금 만드는 산출물은 "무엇을 만들 것인가"를 정의하는 제품 문서예요. 목적이 달라서 하나로 합치면 둘 다 흐릿해져요. 쓰는 법은 IT 외주 RFP 작성 가이드에 따로 정리해 뒀어요.
네 문서를 어느 수준까지 쓰면 되는지, 그리고 빠졌을 때 개발사 쪽에서 무슨 일이 생기는지 한 번에 정리했어요. 「어디까지 쓰면 충분한가」 칸이 이 표의 핵심이에요. 부족한 기획만큼이나 과한 기획도 시간을 버리거든요.
| 산출물 | 이 문서가 답하는 질문 | 어디까지 쓰면 충분한가 | 없으면 개발사가 겪는 일 |
|---|---|---|---|
| 한 줄 가설 | 이 제품으로 무엇을 확인하려는가 | 한 문장. 시장 분석 자료는 견적과 무관해요 | 중간에 들어온 기능 요청을 걸러낼 기준이 없어 요청을 그대로 반영하게 돼요 |
| 사용자 역할·핵심 행동 목록 | 누가 쓰고, 각자 무엇을 하는가 | 역할 3개 이하, 역할당 행동 5개 이하 | 권한 구조를 짐작으로 잡았다가 역할이 늘어나면 전체를 다시 설계해요 |
| 화면 목록 | 만들어야 할 화면이 몇 개인가 | 화면 이름 + 한 줄 설명. 20개 넘으면 MVP 범위가 아니에요 | 견적의 기본 단위가 없어 금액이 넓은 범위로만 나와요 |
| 화면 흐름(user flow) | 사용자가 어떤 순서로 목적을 달성하는가 | 종이 한 장. 예외 경로는 그림 대신 한 줄 문장으로 | 결제·인증 구간을 늦게 발견해 심사 대기가 일정에 통째로 얹혀요 |
네 칸이 다 채워지면 개발사는 화면 수·역할 수·외부 연동·데이터 저장 범위를 문서에서 직접 읽어낼 수 있어요.
기획서에 무엇까지 적어야 하는지 헷갈릴 때 쓰는 경계선이에요. 기준은 기술이냐 아니냐가 아니라, 비즈니스 결정이냐 구현 결정이냐예요.
| 항목 | 결정 주체 | 그쪽이어야 하는 이유 |
|---|---|---|
| 검증할 가설 | 창업자 | 무엇을 확인하려고 이 제품을 만드는지는 창업자만 알아요 |
| 사용자 역할 | 창업자 | 누가 이 서비스를 쓰는지는 시장을 아는 쪽의 판단이에요 |
| 화면 목록 | 창업자 | 제품이 사용자에게 무엇을 보여줄지는 제품 결정이에요 |
| 화면 흐름 | 창업자 | 사용자가 어떤 순서로 목적을 달성해야 하는지는 서비스 설계예요 |
| 성공·실패 지표 | 창업자 | 무엇을 성공으로 볼지 정해야 나중에 무엇을 빼도 되는지 판단할 수 있어요 |
| 화면 디자인 시안 | 개발사·디자이너 | 컴포넌트 규칙과 상태별 화면까지 다시 정의되므로 초안 픽셀은 대부분 버려져요 |
| DB 구조 | 개발사 | 데이터가 어떻게 조회될지를 알아야 정할 수 있고, 그건 화면 흐름을 받아본 뒤에 보여요 |
| 기술 스택 | 개발사 | 근거 없이 지정하면 개발사는 그것을 요구사항으로 받아 선택지를 줄인 채 견적을 내요 |
| 외부 연동 방식 | 개발사 | 심사 기간·수수료·연동 난이도를 아는 쪽이 골라야 일정이 정확해져요. 이미 계약한 업체가 있다면 그것만 알려주세요 |
| 보안·권한 구현 | 개발사 | 역할 목록만 주면 되고, 그것을 코드에서 어떻게 강제할지는 구현 영역이에요 |
앞 5개는 창업자만 답할 수 있고, 뒤 5개는 개발사에 맡길수록 견적이 정확해져요.
정해진 형식은 없어요. 노션 문서든 구글 문서든 손으로 적은 메모든, 개발사가 읽고 화면 수·사용자 역할 수·외부 연동·데이터 저장 범위를 파악할 수 있으면 충분해요. 실무적으로는 한 줄 가설, 사용자 역할과 핵심 행동 목록, 화면 목록, 화면 흐름 네 가지가 들어 있으면 되고 전부 합쳐 서너 장이면 돼요. 형식을 다듬는 데 쓰는 시간보다 이 네 가지가 다 있는지 확인하는 게 훨씬 중요해요.
정교한 와이어프레임은 필요하지 않아요. 손으로 그린 박스 수준이면 충분하고, Figma로 여백과 컬러를 맞추는 작업은 디자인 단계에서 대부분 다시 그려져요. 그림보다 값어치 있는 건 화면마다 「여기서 사용자가 할 수 있는 일」을 한 줄로 적는 거예요. 그 문장이 화면의 상태 개수와 분기를 알려주기 때문에 견적에 훨씬 크게 기여해요. 다만 대시보드나 지도 기반 서비스처럼 배치 자체가 제품의 핵심인 경우는 예외예요.
만들 수 있어요. 화면 목록은 기술 문서가 아니라 「사용자가 보게 될 장면의 이름」을 적는 일이라서 개발 지식이 필요 없어요. 사용자 역할별 핵심 행동을 먼저 적고, 그 행동을 하려면 어떤 장면이 필요한지 따라가면 자연스럽게 목록이 나와요. 클래스 목록, 클래스 상세, 예약하기, 결제, 예약 완료처럼 이름과 한 줄 설명만 있으면 충분해요. 로그인 화면과 관리자 화면만 빠뜨리지 않으면 돼요.
받을 수는 있지만 하한과 상한이 크게 벌어진 범위 견적이 나와요. 개발사가 성의가 없어서가 아니라, 비어 있는 정보가 최악일 경우까지 함께 계산해야 하기 때문이에요. 실제로는 견적 대신 질문 목록이 먼저 돌아오는 경우가 많고, 그 질문에 답하다 보면 결국 같은 산출물을 만들게 돼요. 순서가 뒤로 밀릴 뿐이라서, 간단하게라도 먼저 정리해 보내는 편이 빨라요.
적지 않는 편이 나아요. 개발사는 기획서에 적힌 기술 지정을 요구사항으로 읽고 그대로 반영하기 때문에, 근거 없는 지정이 하나 붙으면 선택지가 줄고 그만큼 금액이 올라가요. 대신 비즈니스 결정에 해당하는 것들은 꼭 적어주세요. 카카오 로그인이 필요한지, 결제가 단건인지 정기 결제인지, 이미 계약한 결제사가 있는지 같은 것들이에요. 이건 사용자와 수익 모델을 아는 쪽만 답할 수 있어요.
괜찮아요. 오히려 화면 목록이나 화면 흐름은 개발사와 같이 정리하면 빠르게 끝나는 경우가 많아요. 다만 검증할 가설과 성공·실패 지표만큼은 창업자가 직접 정해두시는 게 좋아요. 이 두 가지는 개발사가 대신 정해줄 수 없고, 없으면 개발 중간에 무엇을 빼도 되는지 판단할 기준이 사라지거든요. 문서가 비어 있는 상태로 상담을 시작해도 되지만, 가설 한 문장만은 들고 오시는 걸 권해요.
결론부터 말씀드리면 손으로 그린 박스 수준이면 충분해요. Figma로 여백을 맞추고 컬러를 고르는 작업은 대부분 디자인 단계에서 다시 그려져요. 개발에 들어가려면 컴포넌트 규칙, 반응형 동작, 그리고 로딩·빈 화면·에러 같은 상태를 다시 정의해야 하는데, 그 과정에서 창업자분이 맞춰둔 픽셀은 거의 남지 않아요. 사흘 넘게 와이어프레임을 붙들고 있다면 기획이 아니라 디자인을 하고 계신 거예요.
대신 훨씬 값어치 있는 게 있어요. 화면마다 "여기서 사용자가 할 수 있는 일"을 한 줄로 붙이는 것이에요. 클래스 상세 화면이라면 이렇게요. "날짜와 시간을 고르고 예약하기를 누른다. 정원이 차 있으면 버튼이 대기 신청으로 바뀐다. 로그인 전에도 내용은 볼 수 있다."
이 한 줄이 그림보다 견적에 크게 기여하는 이유는 화면의 상태 개수를 알려주기 때문이에요. 그림은 한 가지 상태만 보여줘요. 반면 위 문장 하나에서 개발사는 상태 세 개(예약 가능, 정원 마감, 비로그인)와 분기 하나를 읽어요. 화면 목록에는 한 줄로 세어지는데 실제로 만들고 테스트할 것은 그보다 훨씬 많아지는 지점이 바로 여기예요.
예외도 있어요. 화면 배치 자체가 제품의 핵심인 경우예요. 정보가 빽빽한 대시보드나 지도 위에서 조작하는 서비스라면 배치 스케치가 실제로 의미 있어요. 그 외에는 배치보다 문장이에요.
"기획이 부실하면 비용이 늘어난다"는 말은 다들 하는데, 왜 늘어나는지는 잘 설명하지 않아요. 견적을 다시 계산하게 만드는 트리거는 크게 세 가지이고, 세 가지의 성격이 서로 완전히 달라요.
가장 온건한 변경이에요. 화면 하나가 추가되면 그 화면과 거기 딸린 API, 상태 처리, 테스트가 붙어요. 더해지는 양이 예측 가능해서 "며칠 늘어납니다"라고 답할 수 있어요. 창업자분들이 걱정하는 것과 달리, 이건 사실 가장 싼 변경이에요.
가장 비싼 변경이에요. 앞의 예시에서 역할은 수강생·호스트·운영자 셋이었죠. 개발 중반에 "호스트가 강사를 여러 명 두고, 강사도 자기 클래스는 직접 관리했으면 좋겠다"는 요청이 들어왔다고 해볼게요. 네 번째 역할이 생긴 거예요. 화면 두어 개 추가처럼 들리지만 실제로 다시 설계되는 건 권한 분기 전체예요. 로그인하면 누구를 어디로 보낼지 다시 정해야 하고, 이미 만든 모든 API에 대해 "이 호출을 이 역할이 해도 되는가"를 하나씩 다시 판정해야 해요. 데이터 소유권도 다시 정의돼요. 이 클래스는 호스트 것인지 강사 것인지, 강사가 같은 호스트에 속한 다른 강사의 예약자 명단을 볼 수 있는지, 정산은 누구 앞으로 찍히는지 같은 질문이 새로 생겨요. 운영자 화면에는 강사를 붙이고 떼는 자리가 추가되고요. 만든 것을 전부 다시 훑는 일이라, 남은 일정이 아니라 이미 끝낸 일정까지 건드려요. 역할 목록을 처음에 적어두라는 말이 잔소리처럼 들리는 이유가 여기 있어요.
이건 성격이 또 달라요. 결제나 본인인증은 코드만의 문제가 아니라 계약, 서류, 심사가 따라와요. 개발 자체는 이틀이어도 심사 대기가 2주면 일정은 2주가 밀려요. 그리고 이 대기는 개발자를 더 투입해도 줄지 않아요. 앱 스토어 심사도 같은 성격이에요. 기획 단계에서 "돈이 오가는 지점"과 "실명 확인이 필요한 지점"만 표시해두면 이 대기는 개발과 나란히 돌릴 수 있어요.
그래서 견적이 흔들린다는 건 개발사가 말을 바꿨다는 뜻이 아니라, 앞서 말한 네 칸 중 하나가 바뀌어서 계산이 다시 돌아갔다는 뜻이에요. 그리고 이 세 가지는 전부 착수 전에 확정할 수 있는 것들이에요.
앞에서 손그림이면 충분하다고 말씀드렸는데, 실제로 어디서 멈출지는 수준을 나란히 놓고 봐야 판단이 서요. 기준은 「예쁜가」가 아니라 「이 작업물이 개발 단계까지 살아남는가」예요.
| 수준 | 만드는 방법 | 개발 단계에서 살아남는 것 | 견적에 주는 영향 | 이 수준이 맞는 경우 |
|---|---|---|---|---|
| 손그림 박스 | 종이나 화이트보드에 사각형과 화살표만. 한 화면에 몇 분 | 배치는 바뀌어도 화면 이름과 순서는 그대로 쓰여요 | 화면 수를 셀 수 있게 되니까 견적의 기본 단위가 잡혀요 | 대부분의 MVP. 여기서 멈춰도 돼요 |
| 손그림 + 화면당 한 줄 설명 | 박스 옆에 「여기서 사용자가 할 수 있는 일」을 한 문장씩 | 상태 목록과 분기가 그대로 요구사항 문서로 넘어가요 | 크게 기여해요. 화면 하나가 실제로는 상태 두세 개라는 게 드러나거든요 | 조건에 따라 화면이 바뀌는 서비스(정원, 권한, 결제) |
| 도구로 그린 와이어프레임(Figma 등) | 여백·정렬·컴포넌트까지 맞춤. 한 화면에 붙는 시간이 손그림과 비교가 안 돼요 | 앞 줄과 같은 것만 남아요. 여백과 정렬에 들인 시간이 추가로 알려주는 정보는 없어요 | 앞 단계 대비 달라지는 게 거의 없어요 | 대시보드나 지도처럼 배치 자체가 제품의 핵심인 경우 |
| 디자인 시안(컬러·타이포까지) | 디자이너 작업 영역 | 화면 목록이 확정된 뒤에 그린 시안은 그대로 쓰이고, 확정 전에 그린 시안은 범위가 바뀔 때마다 다시 그려요 | 견적을 바꾸지 않아요. 착수 후 디자인 단계에 넣는 게 순서예요 | 브랜드 가이드가 이미 있고 화면 목록이 확정된 뒤 |
멈추는 지점을 고르는 법은 간단해요. 위에서부터 읽다가 「견적에 주는 영향」 칸이 「거의 없어요」로 바뀌는 줄, 거기가 멈출 자리예요. 대부분은 두 번째 줄이고 세 번째 줄부터는 계약 이후에 시작해도 늦지 않아요.
세 가지를 한 줄에 놓고 보면 대응 방법이 갈려요. 특히 「사람을 더 투입하면 줄어드나」 칸을 보세요. 개발자를 더 넣어 만회할 수 있는 변경과 그렇지 않은 변경을 구분해야 일정 약속을 지킬 수 있거든요.
| 변경 | 실제로 다시 하는 일 | 일정에 붙는 양 | 사람을 더 투입하면 줄어드나 | 착수 전에 막는 법 |
|---|---|---|---|---|
| 화면이 늘어난다 | 화면 하나 + 그 화면이 부르는 API·상태 처리·테스트 | 화면 수에 비례해서 예측 가능해요 | 어느 정도 줄어요 | 화면 목록에 번호를 매겨두면 추가 요청이 「몇 번 화면이 하나 는다」는 대화가 돼요 |
| 사용자 역할이 하나 늘어난다 | 권한 분기 전체, 이미 만든 API의 호출 권한 재판정, 데이터 소유권 재정의, 운영자 화면 추가 | 남은 일정만이 아니라 이미 끝낸 부분까지 다시 훑어요 | 거의 안 줄어요. 만들어둔 것을 다시 보는 일이라서요 | 역할을 3개 이하로 적고, 역할마다 「남의 데이터를 어디까지 보나」를 한 줄씩 붙여둬요 |
| 외부 연동이 뒤늦게 발견된다 | 코드보다 계약·서류·심사가 더 큰 비중 | 개발은 며칠인데 심사 대기가 주 단위로 얹혀요 | 전혀 안 줄어요. 대기 시간은 인원과 무관해요 | 결제사·본인인증 업체 선정과 서류 준비를 착수와 같은 주에 시작해요. 임계경로는 코드가 아니라 이쪽이에요 |
네 번째 칸이 「안 줄어요」인 두 줄은 돈이나 인력으로 만회가 안 되는 변경이에요. 일정을 약속하기 전에 이 두 줄부터 확정됐는지 보시고, 남은 게 첫 줄뿐이라면 착수 후에 조정해도 되는 범위예요.
문서를 다 만들었다면 보내기 직전에 스스로 답해보세요. 개발사 입장이 되어 자기 문서를 읽는 연습이에요.
통과하지 못한 항목이 남아 있어도 괜찮아요. 다만 그 항목은 첫 미팅에서 개발사가 그대로 되물어올 질문이라고 보시면 돼요. 미리 답을 적어두면 미팅이 한 번 줄고, 견적이 나오는 시점도 그만큼 당겨져요.
기획의 목표는 완벽한 문서가 아니에요. 개발사가 창업자와 같은 그림을 보게 만드는 최소한이면 돼요. 한 줄 가설, 역할과 행동, 화면 목록, 화면 흐름. 네 개 다 합쳐서 서너 장이면 충분하고, 그 이상은 대체로 낭비예요. 부족한 것보다 과한 기획이 덜 지적받을 뿐이지, 버려지는 시간은 똑같아요.
포텐랩은 이 산출물이 아직 비어 있는 상태에서 오시는 분들과도 일해요. 첫 상담에서 하는 일이 대체로 이 네 칸을 함께 채우는 거예요. 아이디어는 있는데 문서로 옮기는 데서 막혀 계시다면, 지금 가진 만큼만 들고 오셔도 괜찮아요. 나머지 칸은 같이 채우면 돼요.