“메뉴 구조”가 아니라 “서비스의 질서”를 설계하는 일

기획을 하다 보면 이런 말을 자주 듣는다.
“일단 IA부터 정리해볼게요.”
그런데 실제로 IA를 깊게 고민하지 않으면 결국 나중에 화면이 늘어나고, 기능이 추가될 때마다 구조가 무너지기 시작한다.
IA는 단순히 메뉴를 나누는 작업이 아니다. 서비스 전체의 정보 질서를 정의하는 작업이다.
1. IA의 본질은 정보의 위치와 관계를 정하는 것이다.
IA를 더 정확하게 표현하면 이렇다.
사용자가 원하는 정보를 가장 적은 인지 비용으로 찾도록 정보의 위치와 관계를 설계하는 것.
여기서 핵심은 두 가지다.
첫째, 위치다.
- 이 정보는 어디에 있어야 하는가?
- 사용자는 이걸 어디에서 찾을 것 같은가?
둘째, 관계다.
- 이 정보는 무엇과 연결되어야 하는가?
- 상위 개념은 무엇이고 하위 개념은 무엇인가?
- 같은 레벨에 있어야 하는가, 아니면 종속 관계인가?
예를 들어
- 주문 내역은 마이페이지에 있어야 할까, 구매 완료 화면에서도 접근 가능해야 할까.
- 쿠폰은 결제 단계에만 있어야 할까, 아니면 마이페이지에서도 관리 가능해야 할까.
- 공지사항은 고객센터에만 두는 것이 맞을까, 메인에도 일부 노출해야 할까.
이런 결정들이 곧 IA다.
2. IA 설계는 언제 시작해야 하는가
IA 설계는 가능한 한 이른 시점에 시작해야 한다.
많은 경우 와이어프레임을 그리면서 IA를 동시에 정리하려고 하지만, 사실은 그 반대가 더 자연스럽다.
일반적인 흐름은 다음과 같다.
- 서비스 목적을 정의한다.
- 주요 사용자를 정의한다.
- 핵심 기능을 도출한다.
- 기능을 그룹핑한다.
- IA 구조를 설계한다.
- User Flow를 연결한다.
- 그 이후에 와이어프레임을 제작한다.
IA 없이 화면부터 그리기 시작하면 화면 단위 사고에 갇혀 전체 구조를 놓치게 된다.
3. IA 설계의 실제 단계 (실무 프로세스)
1. 실무에서 IA를 설계할 때는 먼저 기능을 전부 나열한다.
이 서비스에서 사용자가 할 수 있는 행동을 최대한 많이 적어본다.
회원가입, 로그인, 상품 조회, 필터 적용, 찜하기, 장바구니, 결제, 리뷰 작성, 문의하기 등 가능한 모든 기능을 꺼내놓는다.
이 단계에서는 구조를 고민하지 않는다. 일단 다 펼쳐놓는 것이 중요하다.
2. 그 다음 기능을 목적 기준으로 묶는다.
사용자의 행동 목적을 중심으로 그룹핑한다.
예를 들어 구매와 직접적으로 연결되는 기능들을 하나의 묶음으로 만들고, 계정 관리와 관련된 기능들을 또 다른 묶음으로 만든다.
이때 중요한 건 기획자 관점이 아니라 사용자 관점이라는 점이다. 내부 조직 구조 기준으로 묶으면 나중에 사용자 동선이 꼬이기 쉽다.
3. 그 다음 단계는 계층 구조를 만드는 것이다.
상위와 하위 관계를 정리한다. 어떤 항목이 1depth에 있어야 하는지, 어떤 항목은 2depth로 내려가야 하는지 판단한다.
이 과정을 거쳐 우리가 흔히 보는 사이트맵 형태의 구조도가 나온다. 하지만 사이트맵은 결과물일 뿐, IA의 본질은 그 안에 담긴 판단 과정이다.
4. IA와 User Flow의 연결
IA는 정적인 구조이고, User Flow는 동적인 경로다.
IA를 만들었다면 반드시 주요 사용자 시나리오를 구조 위에서 시뮬레이션해봐야 한다.
- 로그인하지 않은 사용자가 결제를 시도하면 어디로 이동하는가.
- 상품 상세에서 바로 구매를 누르면 어떤 화면을 거치는가.
- 비회원 주문은 어떤 흐름을 따르는가.
이 과정을 거치지 않으면 중간에 예외 페이지가 계속 생긴다.
5. IA와 데이터 구조의 연결
서비스 규모가 커질수록 IA는 데이터 구조와도 연결된다.
게시글과 댓글 구조, 상품과 옵션 구조처럼 정보 간의 관계는 결국 데이터 모델로 이어진다.
IA에서 관계를 느슨하게 설계하면 개발 단계에서 데이터 구조를 다시 설계해야 하고, 이는 일정 지연으로 이어진다.
6. IA 설계 시 반드시 체크해야 할 질문
IA를 설계할 때 스스로에게 던져보는 질문들도 생겼다.
- 사용자가 이 정보를 찾을 때 어디를 먼저 눌러볼까.
- 이 항목은 정말 이 레벨에 있어야 할까.
- 같은 레벨에 두면 안 되는 항목은 무엇인가.
- 기능이 두 배로 늘어나도 이 구조가 유지될까.
- 모바일 환경에서도 이 구조가 자연스러울까.
특히 기능이 늘어나도 무너지지 않는 구조인지 고민하는 것이 중요하다. 확장성이 없는 IA는 결국 중간에 리빌딩하게 된다.
7. IA가 무너지는 순간이란?
실무에서 IA가 무너지는 순간은 보통 기능 추가가 반복될 때다. 일단 여기 넣자는 식의 판단이 쌓이면서 구조가 비대해진다.
또 이해관계자의 요청이 계속 추가되면 메뉴가 늘어나고 깊이가 깊어진다. 초기 구조 설계 없이 빠르게 시작한 프로젝트는 중간에 전체 구조를 다시 뜯어야 하는 상황이 생긴다.
8. IA 작업은 결국 선택의 연속이다.
- 묶을 것인가, 분리할 것인가.
- 노출할 것인가, 숨길 것인가.
- 상위에 둘 것인가, 하위에 둘 것인가.
이 판단이 서비스의 질서를 만든다.
IA는 눈에 잘 드러나지 않지만 서비스 전체를 지탱하는 뼈대다. 화면 디자인보다 앞에 있고, 개발 구조보다 먼저 고민되어야 하는 영역이다.
아직 경험이 많지 않은 입장에서 정리한 내용이지만, 실무를 겪을수록 느끼는 건 IA를 가볍게 시작하면 결국 후반에 구조를 다시 정리하게 된다는 점을 알 수 있었다.
'기타 (회고, 생각, 기획 등)' 카테고리의 다른 글
| Claude Code 해커톤이 보여준 개발의 변화 (0) | 2026.03.06 |
|---|---|
| 토스 인앱(Toss Mini App) 기획 및 개발 후기 (0) | 2026.03.06 |
| Principle of Least Privilege (최소 권한 원칙) (0) | 2026.02.19 |
| Single Source of Truth (SSOT) (0) | 2026.02.10 |
| WBS, 간트차트, 마일스톤의 차이 (2) | 2026.01.13 |