IA가 꼭 있어야하나요? (with IA 작성법)
Information Architecture는 어떻게 작성하는게 좋을까?
회사에 입사했는데 이미 굴러가고 있는 프로덕트가 하나(혹은 여러 개) 있다면, 신규 입사자로서 가장 먼저 느끼는 건 “도대체 이 서비스가 어떻게 돌아가는 거지?”라는 막막함일 것이다. 특히 프로덕트 규모가 크고 기능이 복잡하다면, 메뉴나 기능, 데이터 흐름이 뒤엉켜 머릿속에서 미로를 이루기 딱 좋다.
이때 IA(Information Architecture)를 한 번 딱 짚고 넘어가는 경험이 온보딩 속도를 비약적으로 올려준다는 사실을 알게 된다.
생각해보자.
IA를 보고 프로덕트를 이해하는 신규 입사자와, IA 없이 문서나 피그마 여기저기를 헤매며 프로덕트를 파악하려는 신규 입사자 중 누가 더 빠르게 정글을 정복할 수 있을까? 전자가 분명히 더 빠르다. 나무를 하나하나 파악하며 울창한 숲에 길을 낼 필요 없이, 이미 잘 짜인 지도를 들고 탐험하는 셈이니까. IA는 마치 복잡한 도심 한가운데에서 ‘여긴 식당가, 저긴 커피숍, 이쪽은 쇼핑몰!’ 하고 한눈에 길을 알려주는 안내판 같은 역할을 한다.
최신화가 안되거나 잘못된 IA를 보면 오히려 더 헤멜 수 있다...문제는 IA 설계에 정석이 없다는 점이다. 인터넷을 뒤져봐도 “IA는 이렇게 그리는 거야!”라고 딱 부러지게 말하는 레퍼런스는 찾기 힘들다. 그래서 작성자의 개성, 회사의 문화, 제품의 특성에 따라 IA는 천차만별로 그려진다. 게다가 막상 “가장 쉽게 정리하는 동시에, 가장 이해하기 어렵지 않게” 만들려면, 또 그게 제일 어려운 일이다.
그렇다면 우리는 PM으로서 왜 IA를 작성해야 하고, 어떤 방식으로 접근해야 할까?
1. 왜 IA가 필요할까?
프로덕트 규모가 커지고 기능이 복잡해질수록, 신규 입사자는 물론 기존 팀원들마저 전체적인 구조를 한눈에 파악하기 어렵다. IA는 이 복잡한 환경 속에서 하나의 ‘전체 지도’ 역할을 한다.
또한 PM은 이 프로덕트를 이끌어가야하는 역할로 누구보다 프로덕트를 잘 알고 설명할 수 있어야한다. 그렇기에 지도를 잘 만들면 여러 상황에 큰 도움을 줄 수 있다.
빠른 온보딩
신규 입사자는 IA를 통해 서비스 흐름을 단시간에 파악할 수 있다. 잘 만들어진 IA는 전체적인 프로덕트에 대한 이해도를 높일 수 있고 빠르게 실무에 투입될 수 있도록 돕는다.
팀 내 공통 언어 형성
IA는 디자이너, 개발자, 마케터, CS 담당자 모두가 같은 그림을 바라보게 해준다. 프로젝트 진행 중 “그 메뉴가 어디에 있죠? 그 페이지에 어떤 내용들이 있죠?” 같은 기본적인 의문을 줄이고, 의미 있는 의사결정에 더 많은 에너지를 쏟을 수 있다.
확장 및 개선의 기초
새로운 기능을 추가하거나 개편할 때, IA가 있다면 어디에 배치하고 어떤 부분을 재구성해야 할지 명확해진다. 따라서 IA 설계시 추후에 어느정도 예상되는 기능도 같이 고려를 하면 좀 더 수월하게 기획&디자인을 할 수 있다. (잘못 설계하면 '어라 이 페이지가 왜 여기서 나오지?가 될 수 있다.')
2. IA의 정석은 없다 그래서 더 자유롭다
IA에는 검색해봐도 '이렇게 해야한다!' 라고 정해진 답이 없다. 정답이 없기에 회사, 프로덕트, 문화, 비즈니스 상황에 맞춰 자유롭게 변할 수 있다. 이커머스, 소셜 네트워크, SaaS 툴 등 제품별로 요구하는 IA의 포인트가 다르며, 팀마다 문서화 스타일도 제각각이다.
엑셀부터 각종 툴까지 표현 방법이 다양하다.하지만 그렇다고 너무 디테일하게 컴포넌트 하나하나까지 정의할 필요는 없다.
IA는 말그대로 '지도'의 역할을 하는것이지 우리는 그 지도에서 이 지역에 돌맹이가 몇개인지 나무가 몇개인지를 보고 싶은건 아니기 때문이다. (그 시간에 더 효율적인 업무를 하자...)
정답이 없다는 것은 한편으로 어렵지만, 동시에 자유롭다. 그렇기에 방식보다 중요한건 나와 함께 업무하는 동료들이 이해할 수 있는 문서를 만드는것이다.
3. 그렇다면 IA를 어떻게 작성하면 좋을까?
정답이 없는 IA 설계를 어떻게 시작해야 할지 고민된다면, 다음과 같은 접근 방식을 참고해보자. 물론, 모든 과정에 완벽한 공식은 없지만, 기본적인 순서를 따라가면 훨씬 수월해진다.
1) 사용자 목표에서 출발하기
IA를 작성할 때 가장 중요한 것은 사용자 관점을 놓치지 않는 것이다. 사용자들이 이 프로덕트에서 무엇을 하려고 하는지, 어떤 기능을 가장 먼저 찾는지, 어떤 경로를 거쳐 목표를 달성하는지를 생각해보자.
- 유저 여정맵(User Journey Map) 활용
로그인부터 결제, 콘텐츠 소비까지 사용자가 거치는 흐름을 단계별로 정리하면, 자연스럽게 IA에 반영할 수 있다
- 카드소팅(Card Sorting)
주요 기능이나 정보를 카드에 적어, 사용자나 팀원들에게 분류를 부탁해보자. 예상치 못한 그룹핑을 발견하고, 이로부터 IA 구조에 대한 아이디어를 얻을 수 있다.
2) 핵심 흐름을 중심으로 뼈대 잡기
모든 기능을 동일한 레벨에서 다루면 복잡하기만 하다. 먼저 가장 중요한 기능과 페이지를 상위에 두고, 부가 기능과 상세 정보는 하위 레벨에 배치하자. 핵심 흐름을 먼저 잡아두면, 마치 건물을 지을 때 기둥부터 세우듯 구조가 단단해진다.
- 중요도 순위 매기기
꼭 필요한 메인 메뉴와 서브 메뉴를 정하고, 어느 정도 깊이까지 파고들어갈지 결정한다.
- 간결한 네이밍
메뉴나 카테고리 이름은 짧고 직관적으로 짓자. “상품”이라 쓰고 “이게 뭔데?”라고 묻지 않게 하자.
3) 시각적으로 명확하게 표현하기
IA는 머릿속 개념을 시각적 구조로 옮겨놓는 일이다. 여기서 중요한 건 한눈에 파악하기 좋은 시각적 표현이다.
- 단순한 형태의 다이어그램
복잡한 아이콘보다 화살표, 박스, 라벨 정도로 충분하다. 지나친 장식은 오히려 혼란만 야기한다
- 계층적 구조(트리 구조) 활용
루트(메인)에서 출발해 하위로 내려가는 트리 형태, 또는 허브 앤 스포크(Hub and Spoke) 형태 등 직관적인 구조를 선택하자.
4) 팀원과 함께 검토하고 피드백 받기
IA는 개인 작품이 아닌 팀 전체의 나침반 역할을 한다. 초기 버전을 만든 뒤, 디자인, 개발, 마케팅, CS 등 다양한 직군의 팀원들과 검토하는 자리를 가져보자.
- 크고 작은 질문에 대비하기
“이 기능은 어디서 접근하죠?”, “이 페이지는 왜 여기에 있죠?” 같은 팀원들의 질문에 답하며 IA를 다듬으면 훨씬 명확해진다.
- 가볍게 수정하기
피드백을 받아도 모든 걸 한 번에 완벽히 고치려고 애쓸 필요는 없다. 필요할 때마다 조금씩 업데이트하면 된다.
4. 작성하면 끝일까? (무슨 소리야 죽어야 끝나지...)
유지·관리하며 지속적으로 업데이트하기
IA는 한 번 완성하고 끝나는 문서가 아니다. 프로덕트가 진화하면 IA도 바뀌어야 한다.
사실 업무하다보면 가장 늦게 업데이트가 되는 문서이기도 한데 보통 신규 입사자가 오면 그즈음 업데이트를 했던거 같다... (밀린 숙제하기...)
또한 경영진의 장기 로드맵에 따라 주기적으로 IA를 점검하고 프로덕트의 정체성을 유지하기 위해 방향성을 체크해야한다.
히스토리 관리도 같이 하다보면 과거의 문서를 봤을때 '나 왜 이렇게 했지?' 하고 회고하는 모습을 볼 수 있다.
꼭....그렇게...해야만 했냐....!마무리하며
IA는 “정답 없는 설계도”다. 이 말은 결코 부정적인 의미가 아니다.
오히려 프로덕트 고유의 특성과 팀 문화, 비즈니스 목표에 맞추어 자유롭게 변주할 수 있다는 뜻이다.
PM으로서 IA를 고민하고, 작성하고, 개선하는 과정은 프로덕트 이해도를 높이고 팀 커뮤니케이션을 강화하며, 신규 입사자의 온보딩 속도까지 끌어올리는 데 큰 도움을 준다.
정답이 없으니 두려워말고, 시작해보자. 가장 중요한 건 IA를 통해 결국 “사용자와 팀 모두에게 명확하고 직관적인 길잡이”를 제공하는 것이다.
이를 통해 복잡한 프로덕트의 숲 속에서도 우리는 더 빠르고 효율적인 탐험을 할 수 있을 것이다.
