#방법론#정보구조

(잇기) IA(Information Architecture)

잇기

IA는 정보 구조를 설계하는 작업이다

IA(Information Architecture)는 말 그대로 정보 구조를 설계하는 작업입니다. 단순히 메뉴를 나열하는 것이 아니라, 서비스에 들어갈 기능을 정리하고 그것을 체계적으로 연결하는 과정입니다.

정보는 기능을 의미한다

여기서 말하는 정보란 단순한 텍스트나 콘텐츠가 아니라, 서비스에 들어갈 기능을 의미합니다.
기능은 크게 두 가지로 나눌 수 있습니다.

1. 핵심 기능은 문제를 직접 해결한다

핵심 기능은 고객의 문제점을 직접적으로 해결하는 기능입니다. 예를 들어 이미지 제공 서비스라면 ‘이미지를 제공하는 기능’이 핵심 기능이 됩니다. 이 기능이 없으면 서비스의 존재 이유가 사라집니다.

2. 서브 기능은 핵심 기능을 보조한다

서브 기능은 핵심 기능과 연관되거나 그것을 도와주는 기능입니다. 예를 들어 이미지 편집 기능이나 확장자 변경 기능은 핵심 기능을 강화해주는 보조 기능입니다. 핵심 기능이 중심이라면, 서브 기능은 완성도를 높이는 역할을 합니다.

 

구조는 나뭇가지처럼 깊어진다

구조란 나뭇가지처럼 뻗어 나가는 형태를 의미합니다. 이를 Depth라고 부릅니다. 하나의 상위 기능 아래에 하위 기능이 매달리고, 그 아래에 또 세부 기능이 연결됩니다. 기획에서 IA를 설계하는 이유는 아이디에이션 과정에서 나온 아이디어를 정리하기 위함입니다. 생각은 흩어져 있지만, IA는 그것을 구조화하여 연결합니다.

 

IA는 뼈대를 세우는 작업이다

IA를 사람의 팔에 비유해볼 수 있습니다. 팔을 구성하는 요소에는 뼈, 신경, 근육, 살이 있습니다. 어깨뼈, 손목뼈, 연골처럼 각각의 구조가 연결되어 있어야 하나의 팔이 완성됩니다. 마찬가지로 IA는 서비스의 뼈대를 만드는 작업입니다. 구조가 잡히지 않으면 기능은 제각각 흩어집니다. 구조가 정리되면 기능은 유기적으로 연결됩니다.

이 작업에는 Figjam 같은 도식화 툴을 활용하면 정리가 수월합니다.

 

IA 작성 순서

1. 정보를 아이디에이션한다

먼저 서비스에 들어갈 기능을 최대한 자유롭게 나열합니다. 이 단계에서는 구조를 생각하지 않고 기능을 적어내는 것이 중요합니다.

2. 기능을 구체화하고 반대 기능을 설정한다

기능은 항상 쌍으로 존재하는 경우가 많습니다. 이를 반대 기능이라고 볼 수 있습니다.
예를 들어,

  • 구매 ↔ 환불
  • 생성 ↔ 탈퇴
  • 장바구니 담기 ↔ 장바구니에서 빼기

계정 기능이라면 생성, 로그인, 로그아웃, 계정 정보 수정 등으로 확장됩니다. 로그인 기능 안에서도 계정 확인, SNS 로그인 같은 세부 기능이 파생됩니다.
이처럼 기능을 구체화하면 Depth가 자연스럽게 늘어납니다. 실무에서는 기능을 우측에 계속 확장해가며 작성하는 방식을 권장합니다. 그래야 구조가 눈에 잘 들어옵니다.

3. 연관성 있는 기능끼리 구조화한다

나열된 기능을 연관성 기준으로 묶습니다.

예를 들어, 계정 → 생성 → 로그인 → 로그아웃 → 계정 정보 수정
이런 식으로 하나의 상위 개념 아래에 하위 기능을 연결합니다. 이렇게 구조화하는 과정이 IA의 핵심입니다.

4. 고객용을 기준으로 어드민을 설계한다

IA 설계 시 중요한 원칙이 하나 있습니다. 먼저 고객용 구조를 완성한 뒤, 그에 맞춰 어드민을 설계해야 합니다. 어드민은 고객 기능을 관리하기 위한 구조입니다. 고객용이 불분명하면 어드민은 더 혼란스러워집니다. 따라서 항상 고객 중심 구조가 먼저입니다.

비교해서... GPT에게 IA에 대해 물어봤습니다.

 

GPT가 알려주는 IA

정보 아키텍처(Information Architecture, IA) 문서는 웹사이트나 앱이 어떤 정보 구조로 구성되어 있는지를 체계적으로 정리한 자료입니다. 단순히 메뉴를 나열하는 문서가 아니라, “사용자가 어떤 경로로 들어와서 어떤 흐름으로 탐색하며, 어떤 정보에 도달하도록 설계되어 있는가”를 팀 전체가 같은 언어로 이해하도록 만들어 줍니다. 그래서 IA는 디자인, 개발, 기획이 서로 다른 방식으로 해석하지 않도록 기준선을 세워주는 역할을 합니다.

1. 사이트맵은 전체 계층 구조를 한 장으로 보여준다

사이트맵(Site Map)은 페이지의 계층 구조를 시각적으로 표현한 도표입니다. 어떤 페이지가 상위에 있고 어떤 페이지가 하위에 매달리는지, 페이지 간 관계와 탐색 경로가 어떻게 연결되는지를 한눈에 보여줍니다. 특히 전체 구조가 복잡해질수록 사이트맵은 “우리가 지금 무엇을 만들고 있는가”를 빠르게 합의하는 장치가 됩니다.

2. 와이어프레임은 화면 구성과 기능을 미리 검증한다

와이어프레임(Wireframes)은 페이지 레이아웃과 주요 요소를 단순한 도식으로 표현한 자료입니다. 메뉴, 콘텐츠 블록, 버튼 같은 구성 요소가 어디에 배치되고 어떤 역할을 하는지 시각적으로 보여주기 때문에, 디자인을 시작하기 전에 구조와 기능을 먼저 검토할 수 있습니다. 이 단계에서 문제가 잡히면 비용이 크게 줄어듭니다. 예쁘게 만드는 것이 목적이 아니라, “구조가 맞는지”를 먼저 확인하는 도구라고 보시면 됩니다.

3. 라벨링은 팀과 사용자 모두의 혼선을 줄인다

라벨링 시스템(Labeling System)은 메뉴명, 버튼 텍스트, 섹션 제목처럼 화면에서 사용되는 용어를 정리하고 의미를 정의하는 체계입니다. 같은 기능을 어떤 화면에서는 “저장”, 어떤 화면에서는 “등록”이라고 부르면 사용자는 헷갈리고 팀 내부도 혼란스러워집니다. 라벨링을 정리해두면 일관된 용어 사용이 보장되고, 사용자가 정보를 더 빠르게 이해할 수 있습니다.

4. 내비게이션은 사용자가 길을 잃지 않게 만드는 장치다

내비게이션 시스템(Navigation System)은 사용자가 사이트 안에서 어떻게 이동할 수 있는지를 정리합니다. 보통 글로벌 내비게이션(상단/하단의 주요 메뉴), 로컬 내비게이션(특정 섹션 안의 하위 메뉴), 피드백 내비게이션(현재 위치 표시, 브레드크럼 등)처럼 유형이 나뉘고, 각 요소가 어디에 배치되며 어떤 역할을 하는지도 함께 정의합니다. IA가 구조의 뼈대라면, 내비게이션은 그 뼈대 위에서 사용자가 움직일 수 있는 길을 만드는 작업입니다.

5. 콘텐츠 인벤토리는 “무엇이 존재하는지”를 먼저 확정한다

콘텐츠 인벤토리 및 분류(Content Inventory and Categorization)는 현재 존재하는 콘텐츠와 앞으로 추가될 콘텐츠를 목록으로 정리하고, 이를 어떤 카테고리에 배치할지를 결정하는 작업입니다. 서비스가 커질수록 콘텐츠는 계속 늘어나기 때문에, 초기에 “우리는 어떤 콘텐츠를 어떤 기준으로 분류할 것인가”를 잡아두는 것이 중요합니다. 이 항목이 없으면 구조가 자주 흔들리고, 메뉴/탐색 체계도 계속 바뀌게 됩니다.

6. 사용자 플로우는 “목적 달성 경로”를 설계한다

사용자 플로우(User Flows)는 사용자가 특정 목적을 달성하는 과정을 단계별로 시각화한 도표입니다. 회원가입, 구매, 문의하기처럼 목적이 명확한 행동 단위를 기준으로 흐름을 만들고, 각 단계에서 어떤 정보와 기능이 필요한지 정의합니다. 플로우를 그려두면 “이 단계에서 사용자가 막히지 않는가”, “다음 단계로 넘어가려면 무엇이 부족한가” 같은 문제가 빠르게 드러납니다.

7. 메타데이터와 태깅은 검색성과 확장성을 만든다

메타데이터 및 태깅 시스템(Metadata and Tagging System)은 콘텐츠에 붙는 속성 정보를 정의합니다. 작성자, 날짜, 태그, 카테고리 같은 정보가 대표적이며, 이는 검색과 필터링 품질을 좌우합니다. 콘텐츠가 많아질수록 태그 체계가 정교해야 사용자가 원하는 정보를 빨리 찾을 수 있고, 운영 측면에서도 관리가 쉬워집니다.

8. 기능 사양은 화면과 개발의 접점을 명확하게 만든다

기능 사양(Function Specifications)은 각 페이지나 기능이 어떻게 동작해야 하는지를 구체적으로 정리합니다. 기능의 동작 방식, 데이터 처리 방식, UI 요소의 상태 변화 등을 포함할 수 있습니다. IA가 “구조와 길”을 설계한다면, 기능 사양은 “각 지점에서 무엇이 일어나는지”를 확정하는 문서입니다. 이 부분이 명확할수록 개발/QA 단계에서 커뮤니케이션 비용이 줄어듭니다.