메뉴구조도 작성법 2026 — IA·화면목록 차이와 화면 ID·공통화면 7단계

메뉴 구조도는 "화면이 어디 걸려 있나"를 그린 지도다

메뉴 구조도를 한 줄로 말하면 만들 화면을 전부 나열하고 어느 메뉴 아래 놓을지 정한 트리다. 메뉴트리(menu tree)라고도 부른다.

발주처가 검토하기 가장 쉬운 문서다. 그림이 트리 하나여서 IT 를 몰라도 읽힌다. 그런데 여기서 화면 개수가 나오고, 화면 개수가 견적을 만든다. 쉬워 보여서 대충 넘기면 견적의 근거가 사라진다.

관리자
├─ 대시보드
├─ 회원
│  ├─ 회원 목록
│  ├─ 회원 상세
│  └─ 등급 관리
├─ 주문
│  ├─ 주문 목록
│  ├─ 주문 상세
│  └─ 취소·환불
└─ 설정
   ├─ 공통 코드
   └─ 권한

이 트리에서 잎(leaf) 이 화면이다. 위 예시는 화면 9개다.

받는 시점은 설계 초반이다. 요구사항 정의서가 확정된 직후, 화면설계서를 그리기 전이다. 순서를 뒤집어 화면설계서부터 받으면 「이 화면은 어느 메뉴에 있나」가 안 정해진 상태로 디자인이 나오고, 메뉴를 나중에 붙이면서 화면이 늘어난다.

발주처가 가장 많이 틀리는 지점은 이 문서를 「메뉴 이름 정하기」로 오해하는 것이다. 메뉴 이름은 오픈 직전에도 바꿀 수 있다. 바꿀 수 없는 것은 잎의 개수다. 화면 9개로 합의하고 착수한 프로젝트에 화면 14개를 요구하면 그건 범위 변경이다.

IA·정보구조도·화면 목록과 무엇이 다른가

이름이 다섯 개쯤 돌아다녀서 헷갈린다. 실무에서 쓰는 구분은 이렇다.

메뉴 구조도는 「어디 걸려 있나」, IA 는 「어떻게 묶이나」, 화면 목록은 「몇 개인가」다.

셋이 겹쳐 보이는 이유는 작은 프로젝트에서 실제로 하나로 합쳐도 되기 때문이다. 사내 관리 시스템처럼 사용자 화면이 단순하면 메뉴 구조도 하나로 충분하고, IA 를 따로 그리면 문서만 늘어난다. 반대로 콘텐츠가 많고 검색·분류·태그가 얽히는 서비스는 IA 를 따로 그려야 한다.

⚠️ 개발사가 셋을 다 요구하면 왜 필요한지 물어본다. 문서 수가 품질이 아니다. 「IA 는 왜 따로 필요한가」에 답이 안 나오면 메뉴 구조도로 합치는 편이 낫다.

화면 개수가 견적을 만든다

메뉴 구조도를 대충 그리면 견적이 흔들리는 경로가 명확하다.

화면 하나의 통상 공수는 아래 정도로 잡힌다.

⚠️ 위 공수는 시장에서 통용되는 범위이고 스택·디자인 수준에 따라 달라진다. 업체 간 비교 기준으로만 쓰는 것이 맞다.

모바일과 PC 를 각각 세는지 반드시 확인한다. 반응형 하나로 끝나는 화면과 따로 만드는 화면은 공수가 두 배 차이 난다. 메뉴 구조도에 그 구분이 없으면 견적서에서 처음 알게 된다.

어디까지 쪼개나 — 잎의 기준

깊이를 무한히 늘리면 문서가 안 읽히고, 얕으면 화면 개수가 안 나온다. 기준은 하나다.

화면이 새로 뜨면 잎이고, 같은 화면 안에서 바뀌면 잎이 아니다.

깊이는 3단계면 대개 충분하다. 4단계를 넘어가면 메뉴가 아니라 데이터 분류일 가능성이 크다 — 그건 IA 나 공통 코드로 빼는 것이 맞다.

같은 화면이 여러 메뉴에 걸릴 때

실무에서 견적 다툼이 실제로 터지는 지점이다. 「회원 상세」가 회원 메뉴에도 걸리고 주문 메뉴에서도 열린다면 화면 하나인가 둘인가.

판정 기준은 화면이 아니라 코드다 — 같은 화면을 재사용하면 1개, 따로 만들면 2개다. 그리고 이건 개발사가 정하는 것이 아니라 요구가 정한다. 주문 메뉴에서 열 때 주문 이력만 보여야 한다면 그건 다른 화면이고 공수도 따로 든다.

트리에는 두 곳에 다 적고 한쪽에 「(재사용)」을 표시한다. 표시가 없으면 발주처는 하나로, 개발사는 둘로 세고, 그 차이가 견적서에서 처음 드러난다.

화면 ID 를 붙인다

메뉴 구조도만으로는 검수를 못 한다. 화면 목록 표로 옮겨 ID 를 붙이는 순간 기능 정의서·테스트·검수가 같은 단위로 이어진다.

영역 3자 + S + 일련번호면 충분하다. 규칙보다 중요한 건 한번 부여한 번호를 바꾸지 않는 것이다. 기능 ID 쪽 규약은 기능정의서 작성법에 정리했다.

권한 칸을 비워 두지 않는다. 화면은 같아도 권한별로 보이는 항목이 다르면 사실상 다른 화면이고 공수도 다르다. 이걸 안 적어서 개발 후반에 「관리자는 이 버튼이 보여야 한다」가 나오면 화면을 다시 짠다.

비로그인·오류·빈 화면을 빼먹는다

메뉴 구조도는 정상 흐름만 그려진다. 그런데 실제로 만들어야 하는 화면은 더 있다.

• 로그인·비밀번호 찾기·회원가입
• 권한 없음 안내
• 404 / 500 오류 화면
• 데이터가 0건일 때의 빈 화면
• 점검 중 안내
• 이메일·알림 템플릿 (화면은 아니지만 공수가 든다)

이걸 「공통 화면」으로 따로 묶어 메뉴 구조도 아래에 붙인다. 메뉴에는 안 걸리지만 만들어야 하는 것들이다. 빠지면 견적에서 빠지고, 오픈 직전에 급하게 만든다.

의외로 비싼 것이 빈 화면이다. 데이터가 0건일 때 무엇을 보여줄지는 화면마다 다르고, 「등록된 회원이 없습니다」 한 줄로 끝나는 곳과 「첫 상품을 등록해 보세요」 + 등록 버튼을 놓아야 하는 곳이 섞인다. 목록 화면이 30개면 빈 화면 판단도 30번 해야 한다.

권한 없음 화면도 비슷하다. 「접근 권한이 없습니다」를 띄울지, 메뉴 자체를 숨길지, 로그인 화면으로 보낼지가 갈린다. 세 방식의 공수가 다르고 보안 판단도 다르다 — 메뉴를 숨기면 권한 구조가 화면 렌더링에 들어간다.

⚠️ 공통 화면은 개발사가 견적에서 빠뜨리기 쉬운 항목이 아니라, 빠뜨려도 티가 안 나는 항목이다. 견적서에 「공통 화면」 줄이 없으면 물어본다.

발주처가 검토할 때 볼 것

개발사가 메뉴 구조도를 주면 다섯 가지만 확인해도 견적 다툼의 대부분을 막는다.

1. 잎을 세어 화면 개수가 나오는가 — 견적서의 화면 수와 대조한다
2. 모바일·PC 구분이 있는가 — 없으면 물어본다
3. 권한별로 갈리는 화면이 표시돼 있는가
4. 공통 화면(로그인·오류·빈 화면)이 있는가 — 없으면 절반이 빈 문서다
5. 요구사항 정의서의 항목이 다 어딘가에 걸려 있는가

⚠️ 1번을 실제로 세어 봐야 한다. 눈으로 훑으면 맞는 것처럼 보인다. 잎을 세서 견적서 화면 수와 숫자가 다르면 그 차이가 어디서 왔는지 물어본다.

5번(요구사항 대조)은 표로 하면 30분이면 끝난다. 요구사항 번호 옆에 화면 ID 를 적어 넣는다.

빈 칸이 나오는 행이 곧 누락이다. 반대로 화면 ID 쪽에 대응 요구사항이 없는 행도 본다 — 요청하지 않은 화면이 들어가 있으면 그만큼 공수가 다른 데서 깎였다는 뜻이다. 같은 방식을 기능 단위로 하는 법은 기능정의서 작성법에 정리했다.

흔한 실수 5가지

① 대분류만 그리고 끝낸다 「회원 관리」 한 줄로는 화면 개수가 안 나온다. 견적의 근거가 사라진다.

② 잎이 아닌 것을 잎으로 센다 팝업·탭·필터를 각각 화면으로 세면 화면 수가 부풀고 견적이 과대해진다. 반대로 개발사가 부풀리는 경로이기도 하다.

③ 공통 화면을 안 적는다 로그인·오류·빈 화면은 메뉴에 안 걸리니까 잊는다. 공수는 그대로 든다.

④ 깊이를 4단계 이상 파고든다 메뉴가 아니라 데이터 분류를 메뉴로 그린 경우다. 공통 코드나 IA 로 빼야 한다.

⑤ 화면 ID 없이 넘어간다 검수 단계에서 「이 화면이 완료된 거냐」를 판정할 단위가 없어진다.

메뉴 구조도 완성 7단계

[ ] 1. 사용자 유형을 먼저 나눈다 (관리자 / 일반 / 비로그인)
[ ] 2. 유형별로 최상위 메뉴를 나열한다
[ ] 3. 메뉴 아래 화면(잎)을 3단계까지 쪼갠다
[ ] 4. 공통 화면을 따로 묶어 붙인다
[ ] 5. 잎을 세어 화면 개수를 확정한다
[ ] 6. 화면 목록 표로 옮겨 화면 ID·권한·연결 기능 ID 를 채운다
[ ] 7. 견적서 화면 수와 대조 → 발주처 확정

막히는 지점은 1번과 5번이다.

1번(사용자 유형) 을 건너뛰면 관리자 화면과 사용자 화면이 한 트리에 섞여 개수가 안 세진다. 유형을 먼저 나누면 트리가 두세 개로 갈리고 각각이 훨씬 단순해진다.

5번(개수 확정) 은 세는 사람에 따라 달라지므로 앞서 정한 잎 기준을 문서에 같이 적는다. 「탭은 데이터가 다를 때만 별개 화면으로 센다」 한 줄이 견적 협의를 한 번 줄인다.

6번과 7번의 순서를 바꾸지 않는다. 화면 ID 를 붙이기 전에 견적과 대조하면 무엇이 빠졌는지 지목할 수 없다. 「화면이 12개인데 견적은 9개분」까지는 알 수 있지만 어느 3개인지는 모른다. ID 를 먼저 붙이면 빠진 것이 행 단위로 특정된다.

4번(공통 화면)을 3번보다 뒤에 두는 이유도 같다. 메뉴 트리를 다 그린 뒤에 「메뉴에 안 걸리는 화면」을 찾는 편이 빠뜨릴 확률이 낮다. 먼저 적으려고 하면 무엇이 공통인지 판단할 기준이 없다.

AI-Native 팀이 메뉴 구조도를 다루는 방식

트리숲은 AI-Native Team 으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 메뉴 구조도에서 어려운 것은 그리는 일이 아니라 빠진 화면을 찾아내는 일이다.

• 누락 화면 도출 — 요구사항 정의서·기능 정의서와 트리를 대조해 「이 기능이 걸릴 화면이 없다」를 찾는다
• 공통 화면 점검 — 권한 없음·오류·빈 화면처럼 메뉴에 안 걸리는 화면을 목록에서 빠뜨렸는지 본다
• ID 정합성 유지 — 화면 ID 가 기능 정의서·테스트·검수 문서에서 어긋나지 않는지 대조한다

메뉴 구조도의 품질은 견적서의 화면 수와 트리의 잎 수가 일치하는가로 판가름난다. 대조 작업을 자동화해 사람이 업무 판단에 집중하게 만드는 것이 AI-Native 개발 방식의 관점이다.

AI 기능 없이 순수 웹·앱 개발이 필요하다면 포텐랩(Potenlab)도 좋은 선택이다. MVP 부터 플랫폼 개발까지 전문으로 한다.

자주 묻는 질문

메뉴 구조도와 IA 중 뭐가 먼저인가요? 메뉴 구조도가 먼저다. 화면이 정해져야 정보 위계를 논할 수 있다. 콘텐츠가 많은 서비스라면 IA 를 먼저 그리고 거기서 메뉴를 뽑는 순서도 쓴다.

발주처가 메뉴 구조도를 써야 하나요? 초안은 발주처가 쓰는 편이 좋다. 「어떤 메뉴가 필요한가」는 업무를 아는 쪽이 더 정확하다. 잎까지 쪼개고 화면 ID 를 붙이는 것은 개발사가 한다.

화면이 몇 개면 적당한가요? 개수에 정답은 없다. 다만 잎 수 × 화면당 공수가 견적과 맞아떨어지는지는 확인할 수 있다. 사내 관리 시스템은 30~80개, 커머스 관리자는 80~200개 선이 흔하다.

엑셀로 그려도 되나요? 된다. 트리만 읽히면 도구는 상관없다. 들여쓰기로 계층을 표시하고 잎에 화면 ID 를 붙이면 그대로 화면 목록이 된다.

모바일과 PC 를 한 트리에 그리나요? 공유하는 메뉴가 대부분이면 한 트리에 그리고 「PC 전용」·「모바일 전용」을 표시한다. 완전히 다른 서비스면 트리를 나눈다.

정리

메뉴 구조도는 화면 개수의 근거 문서다. 시스템 구성도가 「무엇이 어디에 있는가」를 다룬다면, 메뉴 구조도는 「사용자가 무엇을 보는가」를 센다.

실무에서 결과를 가르는 지점은 셋이다.

1. 잎까지 쪼갰는가 — 대분류만 있으면 견적의 근거가 없다
2. 공통 화면을 적었는가 — 로그인·오류·빈 화면은 메뉴에 안 걸리지만 공수가 든다
3. 화면 ID 가 기능·테스트·검수까지 이어지는가

이 셋만 챙겨도 착수 후 「이 화면은 범위에 없었다」가 거의 사라진다.

인프라 쪽 그림은 시스템 구성도 작성법에, 화면 하나하나의 동작은 화면설계서 작성법에 정리했다.

화면 개수를 공수로 바꿔 견적을 검증하는 방법은 기능점수(FP) 견적 가이드를, 문서 전체 지도는 외주 산출물 문서 7단계를 참고하면 된다.