IA(정보구조도) 제대로 그려야 합니다

IA 다 그렸는데... 왜 개발자는 헷갈려 하고 사용자는 길을 잃을까요?

주니어 기획자 시절, 저는 어느순간 IA(정보구조도) 문서를 만드는 데 꽤 자신이 생겼습니다. 당시 저희 회사에서는 IA를 엑셀로 그렸는데요. 엑셀에 GNB(주 메뉴)와 LNB(서브 메뉴)를 구분하고, Depth(깊이)에 따라 들여쓰기를 맞추고, 화면 ID까지 붙여 깔끔하게 정리했죠. 어느 날 제가 그린 IA(정보구조도)를 가지고 회의에 들어가게 됐을 때, 저는 은근한 자신감으로 가득차 있었습니다.

하지만 회의가 시작된 지 5분 만에, 그 자신감은 산산조각이 났습니다. 평소 친하게 지내던 개발자 K님이 미간을 찌푸리며 첫 질문을 던지셨죠.

"M님, IA는 잘 읽어봤는데요. 5-2번에 있는 '이벤트' 화면이랑 3-4번에 있는 '프로모션' 화면은 뭐가 다른 거죠? 데이터베이스 테이블을 따로 파야 하는 건가요, 아니면 그냥 보여주는 이름만 다른 건가요?"

제가 "어... 잠시만요..."라고 우물쭈물하는 사이, 디자이너 C님도 손을 들었습니다.

"저도 헷갈리는 게, '고객센터' 아래에 '공지사항'이 있는데, GNB에 있는 '새소식' 메뉴 안에 있는 '공지'와는 다른 화면인 거죠? 그런데 둘 다 목록 형태라... 사용자가 헷갈릴 것 같은데, 혹시 의도하신 건가요?"

분명히 목록은 빠짐없이 만들었는데, 정작 그 구조와 관계, 그리고 용어에 대해서는 아무런 생각이 없었던 거예요. 사용자가 이 서비스를 어떻게 받아들일지, 개발자가 이 구조를 보고 어떻게 효율적으로 설계할지에 대한 깊은 고민이 빠져있었죠. 결국 그날 회의는 "IA 다시 잡아오세요"라는, 기획자에게는 정말 처참한 말을 들으면서 끝이 났습니다.

많은 주니어 기획자분들이 저와 비슷한 실수를 하곤 합니다. IA를 단순히 서비스에 들어갈 화면 목록이나 메뉴 목록으로 생각하고 목록을 채우는데 급급한 상황이죠. 하지만 IA는 그렇게 단순한 문서가 아닙니다. 오늘은 IA의 진짜 역할은 무엇인지, 그리고 사용자와 개발자 모두를 행복하게 만드는 좋은 IA는 어떤 조건을 갖춰야 하는지, 제 실패 경험을 바탕으로 조금 더 깊고 자세하게 이야기해 보려고 합니다.

Part 1. IA, 아직도 사이트맵처럼 그리고 계신가요?

IA(정보 구조도, Information Architecture)는 말 그대로 정보의 설계도입니다. 우리는 보통 처음 방문한 대형 쇼핑몰에서 헤매지 않고 유아 휴게실이나 푸드코트를 찾아갈 수 있는데요, 그건 곳곳에 붙어있는 명확한 안내 표지판과 논리적인 공간 배치 덕분이죠. 좋은 IA 역시 우리 서비스를 그렇게 만드는 역할을 합니다.

많은 분들이 헷갈려 하시는데, 사이트맵은 IA의 결과물 중 하나일 뿐, IA 그 자체는 아닙니다. 사이트맵이 어떤 메뉴들이 존재하는지 보여주는 평면적인 목록이나 지도라면, IA는 각 정보가 왜 거기에 있어야 하는지(Why), 어떤 관계를 맺고(Relation), 어떤 경로로 이동하며(Flow), 사용자에게 궁극적으로 어떻게 불려야 하는지(Labeling)를 정의하는 훨씬 더 입체적이고 전략적인 설계도에 가깝습니다.

IA가 중요한 진짜 이유는 크게 세 가지입니다. 이 세 가지를 놓치면 나중에 반드시 큰 비용을 치르게 되더라고요.

1. 사용자를 위한 서비스를 만드는 설계도 "이 서비스는 왜 이렇게 쓰기 어려워?" 사용자가 이런 불평을 한다면 90%는 IA부터 비롯된 문제입니다. 사용자가 원하는 기능을 찾기 위해 3번, 4번씩 클릭해야 한다면 어떨까요? 사용자는 금방 지쳐서 "아 짜증나네, 그냥 다른 거 써야지"하고 이탈해 버릴 겁니다. 좋은 IA는 사용자가 서비스 내에서 자신의 현재 위치를 명확히 알고, 최소한의 노력으로(이를 인지적 비용이 낮다고 표현합니다) 원하는 목적지까지 도달할 수 있게 서비스를 설계하는 설계도 역할을 합니다.
   
   

2. 팀을 위한 공용 언어 앞서 제 경험처럼, 기획자가 '프로모션'이라고 부르는 걸 개발자가 '이벤트'라고 이해하고, 디자이너는 '할인전'이라고 디자인한다면 어떻게 될까요? 이건 그냥 짜증 나는 상황이 아니라, 실제 비용을 발생시킵니다. 팀이 커질수록, 디자이너는 다시 디자인하고, 개발자는 짜놓은 컴포넌트와 API 연동 코드를 수정해야 하는 상황은 비일비재 합니다. 기획서의 단어 하나가 달라져서 개발팀 하루치 공수가 날아가는 건 생각보다 흔한 일이죠. IA는 기획, 디자인, 개발, 마케팅, 운영팀 모두가 동일한 구조와 용어를 보고 소통하게 만드는 공통의 언어이자 청사진입니다. IA가 명확해야 "이 화면은 어디에 붙어요?" 같은 불필요한 질문이 사라지고, 모두가 같은 그림을 그리며 시너지를 낼 수 있습니다.
   
   

3. 서비스가 계속해서 확장할 수 있도록 잡아주는 뼈대 “PM님, 다음 달에 프리미엄 멤버십 기능 오픈해야 하는데, 이 메뉴는 어디에 넣을까요?”

서비스는 살아있는 생물처럼 계속 성장하고 기능은 추가되기 마련입니다. 이때 IA라는 뼈대가 튼튼하지 않으면 기존 메뉴 구조와 전혀 상관없는 곳에 새 기능을 억지로 끼워 넣게 됩니다. 설정 메뉴 안에 갑자기 멤버십 혜택이 들어가거나, 마이페이지가 20개가 넘는 하위 메뉴로 터져나가기 시작하죠. 좋은 IA는 당장의 기능뿐만 아니라, 1~2년 뒤 추가될 기능까지 고려한 유연하고 확장 가능한 뼈대 역할을 해야 합니다. 뼈대가 튼튼해야 기능 하나 추가할 때마다 전체 구조를 뒤엎는 대참사를 막을 수 있습니다.

Part 2. 내 IA가 망했다는 신호: 나쁜 IA의 3가지 특징

그렇다면 우리가 경계해야 할, 프로젝트를 산으로 가게 만드는 나쁜 IA는 어떤 모습일까요? 지금 그리고 있는, 혹은 그려놨던 IA 문서를 열고 한번 냉정하게 스스로 진단해 보세요.

(1) 라벨링(이름)이 제멋대로다. 가장 흔하고, 가장 치명적인 실수입니다. 사용자가 쉽게 이해할 수 있는 단어가 아니라, 우리가 부르고 싶은 대로, 혹은 내부에서 부르는 대로 이름을 짓는 거죠.

Bad Case: 어떤 GNB 메뉴는 '내 정보'인데, 하위 메뉴의 버튼은 '마이페이지로 가기'입니다. 푸터에는 '계정 설정'이라는 링크가 또 있습니다. 이 세 가지가 같은 기능인지, 다른 기능인지 사용자는 물론이고 이 문서를 보는 팀원들조차 헷갈리기 시작합니다. 또, 어떤 메뉴는 이름이 ‘요구사항’입니다. 그런데 사용자들은 이 버튼을 보고 가만히 생각합니다. “누가 누구한테 뭘 요구한다는 거야?” 우리 팀 내부에서는 그냥 쓰고 있는 말인데, 사용자는 정확히 무엇을 의미하는 말인지 모릅니다.

Why?: 사용자는 “내 비밀번호를 바꿔야지”라는 명확한 목표를 가지고 행동합니다. 이때 일관성 없는 이름은 사용자의 학습 비용을 높이고 극심한 혼란을 유발합니다. "아까 본 '내 정보'로 가야 하나, '계정 설정'으로 가야 하나..." 이 망설임이 쌓이거나, 혹은 “어? 비밀번호 바꾸려면 어떤 메뉴로 가야하지?”라는 의문이 들면 서비스에 대한 신뢰가 무너집니다.
신입 기획자가 빠지는 함정: 기획 초기 단계에서는 화면이나 메뉴, 기능 목록을 나열하는 데 급급해서, 각 화면이나 메뉴, 기능의 정확한 이름을 정의하는 것을 소홀히 하기 쉽습니다. 혹은 마케팅팀, 운영팀 등 각 부서에서 사용하는 용어를 그대로 가져와 기획서에 섞어 쓰면서 문제가 시작되기도 합니다.

(2) 구조가 너무 깊다 (Deep Depth). 원하는 기능을 찾기 위해 끝없이 더보기를 누르거나 메뉴를 파고 들어가야 하는 구조입니다.

Bad Case: 이커머스 앱에서 '내 주문의 배송조회'를 확인하기 위해 마이페이지 > 쇼핑 정보 > 주문/배송 관리 > 최근 주문 내역 > 상세보기 > 배송조회처럼 45번 이상 클릭해야 합니다.

Why?: "3-Click Rule"이라는 말이 있죠. 사용자가 3번의 클릭 안에 원하는 정보에 도달하지 못하면 이탈할 확률이 높다는 고전적인 법칙입니다. 물론 요즘처럼 복잡한 서비스에서 이게 절대적인 법칙은 아니지만, 그만큼 깊이를 조절하는 것이 중요하다는 원칙을 담고 있습니다. 더 중요한 개념은 '정보 향기(Information Scent)'입니다. 사용자는 각 단계의 메뉴 이름(링크)에서 향기를 맡고, “이걸 누르면 내가 원하는 정보가 나오겠다”라는 생각을 가져야 쉽게 다음 단계로 나아갈 수 있습니다. IA의 깊이가 너무 깊거나 라벨링이 모호하면 이 향기가 희미해지기 마련이고, 사용자는 길을 잘 모르겠다고 느끼며, 우리에게는 너무나도 슬프게도 바로 이탈해 버립니다.
신입 기획자가 빠지는 함정: 최대한 많은 기능을 관련 있어 보이는 상위 메뉴 안에 다 집어넣으려는 경향이 있습니다. 그러다 보면 설정 메뉴 하나에 30개가 넘는 기능이 3~4 Depth로 들어가 있는 기형적인 구조가 탄생하기도 합니다.

(3) 그룹핑 기준이 모호하다.

이건 정말 최악의 경우인데요, 메뉴를 나누는 기준 자체가 잘못된 경우입니다.

Bad Case 1 (중복): '공지사항' 메뉴가 '고객센터' 아래에도 있고, '새소식'이라는 GNB 메뉴 아래에도 있습니다. 둘의 차이점이 명확하지 않다면 사용자는 혼란스럽습니다.
Bad Case 2 (공급자 중심): 사용자가 이해하는 기준(ex: '쇼핑하기', '내 정보', '고객지원')이 아니라, 회사 내부의 조직도(ex: '마케팅팀 이벤트', '운영팀 공지', 'CS팀 문의')를 기준으로 메뉴를 나눕니다. 사용자는 우리 회사 팀 구조에 아무런 관심이 없는데도 말이죠.

Why?: 좋은 IA의 기본은 'MECE(Mutually Exclusive, Collectively Exhaustive)' 원칙입니다. 쉽게 말해, '상호 배타적이고(중복 없이), 전체 망라적인(빠짐없이)' 구조를 가져야 한다는 뜻입니다. A그룹에 속한 것은 B그룹에 속하지 않아야 하고, 모든 정보는 A든 B든 어딘가에는 속해야 합니다. 이 기준이 무너지면 사용자는 "내가 찾는 건 도대체 어디에 있는 거야?"라며 검색창만 찾게 됩니다. 그리고, 솔직히, 이런 서비스에서는 아무리 검색을 해도 사용자가 찾는 정보는 찾을 수가 없습니다(저는 보통 은행이나 카드 앱에서 그렇더라구요.)

Part 3. 개발자가 사랑하고 사용자가 환호하는 '좋은 IA'의 3가지 조건

자, 그럼 나쁜 IA의 특징을 알았으니, 이걸 뒤집으면 좋은 IA의 조건이 되겠죠? 단순히 뒤집는 것을 넘어, 개발자가 회의 시간에 질문 대신 감탄을 하고, 사용자가 “이 앱은 쓰기가 편하네”라고 느끼게 만드는 구체적인 노하우를 알려드릴게요.

(1) 명확하고 일관된 라벨링 (Good Labeling) 좋은 IA는 사용자 입장에서 쉽고 직관적인 단어와 철저하게 일관된 용어를 사용합니다.

How-to: 용어 정의서(Glossary)부터 만드세요. IA 설계를 시작하기 전에, 엑셀이나 구글 시트, 노션에 시간을 투자해서 용어 정의서부터 만드세요. 거창할 필요 없습니다. 바빠죽겠는데 시간 낭비라고 생각할 수도 있지만, 결과적으로는 시간을 아끼게 해줄 겁니다.

1단계 (수집): 우리 서비스에서 사용될 모든 명사(ex: 게시물, 상품, 사용자)와 동사(ex: 등록하다, 수정하다, 구매하다)를 나열합니다.
2단계 (정의): 팀원들(특히 개발자, 디자이너, 마케터)과 함께 사용할 용어을 정합니다. (ex: '사용자'로 통일. '회원', '유저', '고객' 등은 사용 X)
3단계 (공유): 이 정의서를 프로젝트 채널에 고정하고 모두가 따르도록 약속합니다.
이 간단한 약속 하나가 기획서, 디자인 가이드, 심지어 개발자의 코드 변수명까지 통일시켜 나중에 수십 시간의 커뮤니케이션 비용을 아껴줍니다.

(2) 얕고 넓은 구조 (Shallow Depth) 좋은 IA는 중요한 정보를 숨기지 않고, 사용자가 최소한의 노력으로 접근할 수 있게 밖으로 꺼내놓습니다.

How-to: 정보 향기를 유지하며 Depth를 줄이세요.

앞서 말한 "3-Click Rule"을 맹신하기보다, “사용자가 다음 단계에 무엇이 나올 것인지 예상하며 나아갈 수 있는가?”를 점검하세요.
Depth를 줄이는 실질적인 방법은 메가 메뉴(Mega Menu)를 활용하는 것입니다. GNB에 마우스를 올렸을 때 LNB와 그 하위 메뉴까지 한눈에 보여주는 방식이죠. 이는 사용자가 구조를 빠르게 파악하고 원하는 곳으로 바로 점프하게 도와줍니다.
또 다른 방법은 대시보드를 활용하는 겁니다. '마이페이지'가 좋은 예시죠. '주문 내역', '쿠폰함', '내 정보 수정' 등 각기 다른 Depth에 있는 기능들을 사용자가 가장 많이 찾는 순서대로 한 화면에 모아 바로가기를 제공하는 겁니다.

(3) 상호 배타적인 그룹핑 (Good Grouping) 좋은 IA는 MECE(배타적이고 망라적이어야 한다) 원칙을 따르며, 무엇보다 공급자가 아닌 사용자의 머릿속을 기준으로 정보를 그룹핑합니다.

How-to: 내 감을 믿지 말고, 카드 소팅(Card Sorting)을 하세요. 내 머릿속의 논리가 사용자의 논리와 일치할 것이라는 착각을 버려야 합니다. 가장 좋은 방법은 실제 사용자(혹은 최소한 동료)에게 직접 물어보는 카드 소팅 기법을 활용하는 겁니다.

1. 준비: 서비스에 들어갈 모든 기능과 정보 조각들을 포스트잇이나 디지털 카드(ex: FigJam, Miro)에 하나씩 적습니다.

2. 실행 (Open Card Sorting): (신규 서비스에 유용) 5~10명의 사용자에게 이 카드들을 나눠주고, "비슷하다고 생각하는 것끼리 묶어주시고, 각 그룹에 어울리는 이름을 붙여주세요"라고 요청합니다.

3. 실행 (Closed Card Sorting): (기존 서비스 개선에 유용) 기획자가 미리 GNB 메뉴(그룹)를 정해두고, 사용자에게 카드들을 가장 어울리는 그룹에 분류해달라고 요청합니다.

4. 분석: 이 과정을 통해 "아, 사용자들은 '쿠폰'과 '포인트'를 '결제 정보'가 아니라 '내 혜택'이라는 그룹으로 묶는구나" 혹은 "생각보다 많은 사용자가 '이벤트'와 '공지사항'을 같은 그룹으로 묶네?" 같은 강력한 인사이트를 얻을 수 있습니다.

Part 4. IA는 '박제된 문서'가 아니라 '살아있는 설계도'입니다.

많은 기획자들이 저지르는 또 하나의 실수는, IA를 프로젝트 초기에 한 번 그리고 완료 도장을 찍은 뒤 다시는 쳐다보지 않는 것입니다. 하지만 서비스가 오픈되고 사용자가 들어오는 순간부터 IA는 관리의 영역으로 들어갑니다.

데이터로 검증하기: 서비스 오픈 후, 구글 애널리틱스(GA) 같은 툴을 통해 사용자들이 어디서 길을 잃는지(이탈률이 높은 페이지), 어떤 메뉴를 가장 많이 사용하는지, 검색창에 어떤 단어를 주로 입력하는지 데이터를 확인해야 합니다. 만약 사용자들이 '배송조회'를 찾지 못해 계속 검색창에 입력하고 있다면, 그건 '배송조회' 메뉴의 위치나 라벨링에 문제가 있다는 강력한 신호입니다.
지속적인 업데이트와 버전 관리: 이런 데이터나 새로운 비즈니스 요구사항(ex: 신규 기능 추가)이 발생하면, IA는 수정되어야 합니다. 이때 기존 구조를 무시하고 덧대는 것이 아니라, “이 기능이 추가됨으로써 기존 그룹핑의 원칙이 깨지진 않는가?”를 점검해야 합니다. 그리고 IA 문서를 업데이트할 때는 반드시 IA v1.1, IA v1.2처럼 버전을 관리하고, 변경된 내용을 팀원들에게 명확히 공유(Change Log)해야 합니다.

마무리하며: 완벽한 설계도 대신, 진화하는 설계도를 만드세요.

IA는 기획의 시작점이자, 사용자와 팀원 모두를 연결하는 가장 중요한 약속입니다. 처음부터 완벽한 IA를 그리는 것은 불가능에 가깝습니다. 하지만 오늘 이야기한 3가지 기준, ‘일관된 라벨링', '얕은 깊이', '명확한 그룹핑'을 기억하고 끊임없이 다듬어 나간다면, 분명 헤매는 사용자도, 헷갈리는 팀원도 없는 훌륭한 서비스를 만들 수 있을 겁니다.

IA를 한 번에 끝내야 할 숙제로 생각하지 마세요. 사용자와 함께 호흡하며 계속 진화하는 설계도를 그린다는 마음으로 접근한다면, 어느새 사용자는 물론이고 함께 일하는 팀원들에게도 깊은 신뢰를 받는 유능한 기획자가 되어 있을 겁니다.

[주니어 기획자를 위한 Action Items]

지금 당장 '용어 정의서' 만들기 : 현재 진행 중인 프로젝트에서 가장 자주 혼용되는 단어 10개(ex: 사용자/회원, 게시물/콘텐츠, 등록/저장)를 뽑아 구글 시트에 정리해 보세요. 그리고 팀 슬랙 채널에 공유하며 "앞으로 우리 프로젝트의 공식 언어를 같이 정해주세요!"라고 제안해 보세요.

동료와 미니 카드 소팅 해보기 (1시간 투자): 지금 기획 중인 서비스의 핵심 기능 20개를 포스트잇에 적어보세요. 그리고 커피 한 잔 사주겠다며 동료 3명(다른 팀이면 더 좋습니다)에게 "비슷한 것끼리 묶어주실래요?"라고 부탁해 보세요. 내가 생각했던 그룹핑과 얼마나 다른지 비교해 보는 것만으로도 엄청난 배움을 얻을 수 있습니다.

경쟁사 앱 '3-Click' 확인하기: 내가 자주 쓰는 앱 혹은 경쟁사 앱 1개를 정해서, 사용자의 핵심 목표 3가지(ex: 배송조회하기, 비밀번호 변경하기, 이벤트 참여하기)를 정하고, 각각 몇 번의 클릭이 필요한지 직접 테스트하고 기록해 보세요. 왜 그렇게 설계했는지 역으로 추적해 보는 과정에서 IA를 보는 눈이 달라집니다.

manyfast.io