IA 분류 기준 | 카테고라이징 방법론 (UX)

일반 이용자의 관점에서 IT 웹 서비스는 직관적이고 단순하다. 본인이 겪는 일상의 불편함이나 욕망을 간편하게 해소하기만 하면 되기 때문이다. 메신저로는 친구와 대화하면 그만이고, 은행 앱으로는 송금만 원활히 처리되면 만족한다. 가끔 필요에 따라 계좌를 개설하거나 금융 상담을 받는 정도가 전부다. 쇼핑 앱 역시 물건이 필요할 때 켜서 곧바로 구매할 수 있다면 그것으로 충분하다.

이렇듯 대다수의 이용자에게 IT 서비스는 별다른 기술 없이도 만들기 쉬운 영역처럼 보이기 쉽다. 서비스를 직접 제작하기로 처음 마음먹었을 때도 이러한 시선은 한동안 유지된다. 외주 업체를 만나 상담을 받아보면 이미 그들이 보유한 코드 템플릿을 통해 쉽게 제품을 공급받을 수 있다는 인상을 받는다. 게다가 인터넷에 있는 카페24나 노코드 툴 같은 플랫폼을 활용하면 혼자서도 얼마든지 제품을 뚝딱 만들어낼 수 있을 것처럼 느껴지며, AI가 생성해 준 수려한 목업 이미지까지 확인하고 나면 이보다 쉬운 사업은 없을 것 같다는 착각마저 든다.

그러나 외주 제작이든, 노코드 툴이든, AI를 활용했든 간에 실제 제품이 만들어진 바로 그 순간부터 IT 서비스의 진짜 난관이 시작된다. 외주 업체가 완성한 결과물은 본인이 머릿속으로 그린 서비스만큼 멋지거나 간편하지 못한 경우가 대부분이다. 처음부터 생각을 구체화한 기획안도 없이 미팅을 진행했다면 실망감은 더욱 커질 수밖에 없다. 노코드 툴로 제작한 서비스 역시 모두가 같은 툴을 공유하기에 차별화를 기대하기 어렵다. 기능을 덧붙일수록 오류가 터져 나오고 초기 기획 의도와 동떨어진 결과물로 이어지는 AI의 구조 또한, 파고들수록 토큰만 낭비되고 답답함만 키울 뿐이다. 이는 기술이 아무리 발전한다 해도, 기획자 스스로 생각을 구체화하여 지시, 전달하지 않는다면 그것이 사람이든, AI이든 결코 만족스러운 결과물을 얻을 수 없다는 원초적인 한계를 보여준다.

더욱이 서비스를 지속해서 운영하기 위해서는 일반 이용자만을 고려해서는 안 된다. 비즈니스를 영위하기 위한 데이터(상품) 공급자 시스템은 물론, 자체적으로 서비스를 관리하고 제어하기 위한 운영자 전용 시스템이 필수적으로 요구된다. 이 부분은 이용자 관점으로만 IT 서비스에 접근했을 때 가장 쉽게 놓치는 대목이다. 백엔드와 운영 단의 시스템을 전혀 고려하지 못한 채 이용자 화면만 외주로 덜컥 만들어두었다가, 추후 실제 서비스 운영이 불가능해져 업체와 극심한 갈등을 빚는 사례가 허다한 이유가 여기에 있다.

결국 성공적인 IT 서비스를 제작하기 위해서는 전체 시스템을 유기적으로 이해하는 거시적인 안목이 필요하다. 그리고 이 복잡한 시스템의 전체 구조를 명확히 파악하고 설계하기 위해 반드시 거쳐야 하는 작업이 바로 정보 구조 설계, 즉 Information Architecture(IA)이다. IA를 올바르게 정의할 때 비로소 거대한 시스템의 큰 그림을 편리하고 정확하게 파악할 수 있다.

IA 란? (Information Architecture)

정보 구조란 웹사이트, 애플리케이션, 소프트웨어 등 디지털 환경에서 콘텐츠와 기능을 사용자가 직관적으로 이해하고 쉽게 탐색할 수 있도록 정보를 주호화 하고 체계화하는 마스터 플랜(설계도)를 의미한다. 형식은 엑셀이나 Figma를 이용해 자유롭게 표현한다. 전체 구조의 흐름만 파악할 수 있다면 형식은 정해져있지는 않다.

모두가 같이 설계하는 전체적인 그림

IA의 작성은 보통 기획자가 중심을 잡고 작성을 한다. 하지만 이는 기획자만 작성할 줄 알아야 한다는 것이 아니다. IT서비스를 운영하는 팀원 전체가 IA를 이해해야한다. IA의 전체 설계도는 곧 기능명세서가 되며 IA의 초안이 MVP가 된다. 최초 기능개발의 범위가 되고 운영제품의 장점과 사용방법이 녹아내려있는 것이기 때문에 서비스의 판매포인트 누구를 대상으로 영업을 할 것인가 어떤 기능들을 개발할 것인가 그리고 개발한 서비스의 대한 통합테스트의 기준까지, 모든 설계가 IA구조를 설계할 때 존재하기 때문에 모두가 적극적으로 IA설계에 참여해야 한다.

IA의 포함되어야 하는 내용

IA의 설계는 앞서 이야기 한 바와 같이 정해져있는 방법론은 없이 유연하게 조정하여 사용한다. 개인적인 IA설계 방법을 공유한다.

1depth	2depth	3depth	내용 (기능)	ID	진행상태
page1	page-1-1	page-1-1-1	function 1	PAG-CON-SUB	진행중
ㅤ	page-1-2	page-1-2-1	function 2	PAG-CON-SUB	대기중

1depth의 경우 기능의 대분류이다. 사용자가 서비스에 접속하였을 때 직관적으로 자신이 무엇을 할 수 있는지 판단하는 레벨의 기능이다. 사용자 중심으로 어떤 행위를 할 수 있는 지 명확하게 해주지 않고 개발자 중심으로 분류한다면 사용자가 사이트에 접속하여 해맬 수 밖에 없다.

2depth는 기능의 세분화이다.

3depth는 실질적인 기능의 이름이고 세부적인 역할이다 이 페이지에서 어떤 것을 사용자가 얻을 수 있는 지 명확하게 파악할 수 있어야 한다.

내용은 곧 기능이다. 어떤 행위들을 할 수 있는지, 어떤 내용들이 개발되어야 하는지 상세하게 서술 하여 모두가 파악할 수 있어야 한다.

ID는 각 페이지 및 기능들에 부여하는 ID로 나 같은 경우는 화면의 디자인 ID에도 부여하고 테스트에도 연결하여 테스트를 진행한다. 해당 ID를 통해 기획 - 디자인 - 개발 - 테스트 모든 단계를 추적하고 대응할 수 있는 것이다.

진행상태를 추가하여 관리한다 필요에 따라 담당자도 직접 관리하며, ID 또한 세분화해서 관리하여 전체 진행사항을 파악할 수 있다.

구체적인 ID 관리 방법

ID관리도 다양한 방식이 존재하며 아래의 내용은 기획, 디자인, 개발, 테스트 까지 모두 관리하기 위해 부여하는 방식이다. 각 기능의 대한 접두사는 동일하나 순번은 서로 연관성이 없고, 기획 → 디자인 → 개발 → 테스트의 링크를 각각 달아줘서 바로 진행상태를 파악할 수 있다.

단계	ID 형태	예시	의미 설명
기획 (IA)	`IA-[기능]-[순번]`	`IA-SIGN-001`	회원(`MEM`) 가입(`SIGN`)의 첫 번째 주요 기능 단계 (이메일 가입 폼 입력)
디자인 (Figma)	`SCR-[기능]-[순번]`	`SCR-SIGN-001`	기획 기능에 대응하는 첫 번째 디자인 화면 (Figma Frame 이름으로 사용)
개발 (Git/Jira)	`[IA ID]` 또는 `[Jira Key]`	`IA-SIGN-001`	코드 커밋 메시지나 PR 타이틀에 기획 ID를 태깅하여 코드와 기획 매핑
테스트 (QA)	`TC-[기능]-[순번]`	`TC-SIGN-001`	해당 기능을 검증하기 위한 첫 번째 테스트 케이스

단계 접두사 (Phase Prefix):

IA- : 기획 기능 고유 ID (기능의 메뉴 위치가 바뀌어도 평생 유지되는 마스터 ID)
SCR- : 디자인 화면 ID (Figma 프레임 매핑용)
TC- : 테스트 케이스 ID (QA 시나리오 매핑용)

기능 코드 (Feature Code): 대분류(위치)는 제외하고, 기능 그 자체의 고유 행동을 뜻하는 약어 → 기능이 이동되는 경우가 있다.

예: 회원가입 → SIGN, 로그인 → AUTH, 결제 → PAY, 검색 → SRCH 등

독립적 3자리 순번 (3-Digit Sequential): 각 단계 내에서 독립적으로 부여하는 순차 번호(001, 002...)로, 중간에 항목이 추가/삭제되어도 다른 단계에 영향을 주지 않는다.

ID부여까지 완료된 전반적인 IA설계가 완료되면 아래와 같은 현황표가 완성된다.

IA ID (기능 코드)	1depth	2depth	3depth / 기능 상세	디자인 화면 ID (Figma Frame)	통합 테스트 ID (QA Case)	담당자 (PM/Des/Dev/QA)	진행 상태
`IA-MEM-001`	회원	회원가입	이메일 가입 폼 입력	`SCR-MEM-001`	`TC-MEM-001` `TC-MEM-002`	기획: 김OO 디자인: 이OO	개발 중
`IA-MEM-002`	회원	회원가입	이메일 중복 확인	`SCR-MEM-001` (동일 화면)	`TC-MEM-003`	기획: 김OO 개발: 박OO	디자인 완료

정보 구조(IA) 작성원칙

이제 IA작성을 완료하였다. 그렇다면 본격적으로 IA를 작성하는데 주의해야 할 내용을 알아보자

IA를 분류하고 나누는데 단편적으로 공급자 중심 분류로 나뉘어서 제공될 가능성이 농후하다. 사용자가 어떻게 제품을 활용할까의 고민보다는 기능단위로 A그룹, B그룹, C그룹으로 분류하여 카테고라이징 하는 것이다. 그러나 이는 사용자의 목적에 부합하지 않은 구조라 페이지의 탐색에 오랜시간을 소요하여 결국 이탈률을 높히는 일이 발생할것이다.

기초적인 분류 방법에서 조금 더 나아가 다양한 고민을 통해 사용자들이 더욱 편안하게 시스템을 설계할 수 있는 3가지의 축을 제시한다.

정보 구조의 3대 핵심원칙

사용자 중심의 IA의 설계

같은 시스템이지만 다양한 목적으로 사용되며, 사용자라고 뭉퉁그려 표현했지만 관리자, 운영자, 공급자, 등등 다양한 계층의 이용자들이 존재한다. 하지만 보통 하나의 시스템을 만들어놓고 운영자들에게 접근권한으로 제어하는게 초기단계의 MVP로 구성되지만, 좋은 제품을 위해서는 각각의 사용자가 이 시스템을 어떻게 바라 보는가를 고민해야된다.

즉 사용자들의 멘탈모델을 구성하여 이 사용자들의 목적별로 IA접근 경로를 미리 상상해보아야 탐색에서의 마찰을 줄일 수 있는 것이다. 아래와 같은 멘탈모델을 그려볼 수 있다. (예시를 위해 간략하게 표현한 멘탈모델로 기획의 입장에서 어떻게 시스템을 바라볼것인가 어떤 시간에 사용할 것인가 등등의 사용자 입장에서 생각할 수 있는 요소에 대해서 상세하게 작성할 수 록 더욱 편리한 시스템을 설계할 수 있다.)

사용자	역할	주요목적
홍길동	시스템에서 운영서비스를 관리한다.	• 상품재고 관리 이후 상품의 리스트를 업로드한다. • 판매실적을 확인하고자한다. • 기타 등

홍길동 사용자의 주요 IA 이동경로를 시나리오별로 생성해보며 사용자가 어떻게 시스템과 인터렉션 하는 지 가설을 세워본다.

순서	목적	ID	IA접근	설명
1	상품재고관리	`IA-PRD-001`	재고관리 페이지	아침루틴으로 어떤 주문이 들어오고 재고가 관리되는지 파악한다
2	판매실적	`IA-DAS-001`	실적 페이지	실적을 확인한다

같은 페이지라도 접근의 이유가 다를 수 있으며 특정 페이지들은 또한 권한에 따라 제어될 필요가 생긴다. 이를 명확히 파악하기 위해서 IA설계 시 여러 멘탈모델로 어떻게 사용되는지 파악해두는 것이 중요하다.

어떤 기능들이 존재하는가? 그리고 그것들간의 관계는?

IA를 설계하기 위해서는 사용자를 이해하는 것도 중요하지만, 시스템에 어떤 기능들이 존재하고 그것들이 어떻게 동작하는지 면밀히 살펴야 한다. 사용자가 이를 어떻게 활용할 것이며 각 기능 간의 관계가 어떻게 얽혀 있는지 깊이 고민해야 하는 것이다. 이러한 일련의 고민과 복잡한 개념들을 OOUX(객체 지향 UX) 프레임을 활용해 알기 쉽게 개념화한다.

OOUX(Object-Oriented UX)는 화면의 흐름이나 기능(동사)을 먼저 설계하기 전에, 사용자가 시스템에서 인지하고 상호작용하는 핵심 정보 단위인 '객체(명사)'를 중심으로 인터페이스를 구조화하는 방법론이다. 사용자의 멘탈 모델과 일치하는 실제 세계의 사물이나 개념을 먼저 정의한 뒤, 그 객체들이 서로 어떻게 연결되는지 관계를 구축하는 것에 초점을 맞춘다.

이를 구체적으로 실행하기 위해서는 먼저 기능들을 나열한 뒤, 해당 기능들의 핵심 객체가 되는 개념들을 추출해야 한다. 이는 보통의 IA를 설계할 때 기능 분류의 대분류 역할을 해준다. 하지만 이렇게 추출한 개념들을 기존의 방식처럼 각각 독립된 공간에 분리하여 배치해서는 안 된다. 사용자의 행동과 집중이 순간적으로 끊기기 때문이다. 대신 동일한 공간 안에서 브릿지(링크 등)를 통해 자연스럽게 이동할 수 있도록 구조화하여 작업의 연속성을 보존해주어야 한다. 사용자가 어떤 데이터를 바라보고 상호작용하는지에 온전히 집중하도록 만드는 것이 핵심이다.

예를 들어 프리랜서용 프로젝트 관리 플랫폼을 설계한다고 가정해 보자. 이때 "송장을 발행한다", "고객 정보를 수정한다", "태스크 완료 체크박스를 누른다"와 같이 개별 기능 중심의 화면 흐름(동사, Verbs)을 먼저 그리지 않는다. 그보다 서비스의 근간이 되는 핵심 정보 단위인 프로젝트(Project), 고객(Client), 송장(Invoice), 태스크(Task)라는 명사(Nouns) 객체들을 먼저 식별해낸다.

이후 '특정 프로젝트 상세 화면에서 연관 송장 목록 카드를 누르면 송장 상세 화면으로 이동하고, 거기서 다시 발주 고객 정보 카드를 통해 즉시 넘어가는 양방향 브릿지 링크' 형태로 객체 간의 관계를 유기적으로 엮어 화면을 설계한다. 이러한 명사 중심의 구조화를 통해 사용자는 끊김 없이 자연스럽게 시스템을 이용할 수 있게 된다.

다양한 맥락에서의 시스템 접근

이외에도 사용자가 반드시 홈 화면(Home)을 통해서만 서비스를 시작하지 않는다는 점을 유념해야 한다. 구글 검색을 거쳐 유입된 서브 페이지나 블로그 글, 소개 페이지 등이 첫 접속 창구가 될 수 있으며, 특정 마케팅 랜딩 페이지를 통해 시스템에 처음 도달할 수도 있다. 만약 이때 랜딩 페이지에서 다른 페이지로의 전환이 불가능하거나, 서브 페이지에서 메인 시스템으로 접근하는 경로가 막혀 있다면 사용자는 큰 불편을 느끼고 즉시 이탈해 버린다. 따라서 설계자는 사용자의 다양한 진입 경로와 접속 상황을 반드시 고려해야 한다.

동시에 IA를 설계하는 시점에는 비즈니스 목표와 현실적인 제약 조건도 함께 저울질해야 한다. 투입 가능한 개발 리소스와 기간을 계산하여 IA의 설계 범위를 명확하게 한정 지어야 하는 것이다. 사용자의 맥락에 완벽히 부합하는 풍부한 기능의 초기 버전도 좋지만, 개발 기간이 지나치게 늘어지면 시장 검증을 받기도 전에 예산이 소진되어 프로젝트 자체가 무산될 위험이 크다. 결국 세상에 공개조차 하지 못한 채 사장되는 셈이다. 그러므로 객관적인 상황 판단을 기반으로 삼아 최소 기능 제품(MVP) 수준의 IA를 우선 설계한 뒤, 버전 업데이트를 거치며 차츰차츰 구조를 발전시켜 나가는 전략이 필요하다.

IA를 지탱하는 8가지 기준점

지금까지 살펴본 복잡한 화면 간의 유기적 연결, 사용자의 이탈 방지, 그리고 현실적인 개발 범위 설정 등의 고민은 비단 새로운 이야기가 아니다. 디자인 에이전시 '에이트셰이프(EightShapes)'의 공동 창립자이자 UX 디자이너인 댄 브라운(Dan Brown)이 제안한 '정보 구조의 8가지 원칙(8 Principles of Information Architecture)'을 살펴보면, 우리가 IA를 설계할 때 무엇을 점검하고 기준 삼아야 하는지 한층 더 명확해진다.

객체의 원칙 (Principle of objects): 콘텐츠를 고유한 속성과 수명 주기를 가진 독립적인 객체로 정의한다. 앞서 다룬 OOUX의 개념처럼 기능보다 명사를 먼저 식별하는 작업의 근간이 된다.

선택의 원칙 (Principle of choices): 지나치게 많은 옵션은 사용자의 의사결정을 방해한다. 인지적 과부하를 줄일 수 있도록 선택지의 개수를 적절히 제한해야 한다.

공개의 원칙 (Principle of disclosure): 방대한 정보를 한 번에 노출하기보다, 요약된 정보를 먼저 보여준 뒤 사용자가 원할 때 점진적으로 상세 내용을 공개하는 구조를 취한다.

모범 사례의 원칙 (Principle of exemplars): 모호하거나 추상적인 카테고리는 직관적으로 이해하기 어렵다. 사용자의 이해를 돕기 위해 범주를 대표하는 구체적인 예시나 시각 자료를 함께 제공한다.

전면 문의 원칙 (Principle of front doors): 모든 사용자가 홈 화면으로만 진입하지 않는다. 외부 검색이나 서브 페이지로 직접 유입되는 상황을 대비해, 어떤 화면에서든 길을 잃지 않도록 내비게이션을 상시 배치한다.

다중 분류의 원칙 (Principle of multiple classifications): 사람마다 정보를 탐색하는 방식은 제각각이다. 카테고리별 검색이나 브랜드별 검색처럼 사용자의 다양한 성향을 포용할 수 있도록 다각적인 분류 체계를 마련한다.

집중 내비게이션의 원칙 (Principle of focused navigation): 내비게이션 메뉴는 무분별하게 혼재되어서는 안 되며, 철저히 통일된 주제와 일관된 목적 중심으로 분할 구성되어야 혼선을 막을 수 있다.

성장의 원칙 (Principle of growth): 비즈니스는 끊임없이 변화하고 콘텐츠는 늘어난다. 당장 필요한 구조에만 매몰되지 않고, 전체 아키텍처의 큰 틀을 깨뜨리지 않으면서 유연하게 확장할 수 있는 설계를 유지해야 한다.

이처럼 댄 브라운의 8가지 원칙은 우리가 앞서 고민했던 다양한 접속 상황과 비즈니스 제약, 그리고 객체 중심의 구조화가 결국 하나의 유기적인 정보 구조체로 귀결된다는 점을 잘 보여준다.

함께 만드는 유기적인 아키텍처, IA를 시작하며

결국 철저한 IA 설계를 바탕으로 제품을 준비한다는 것은 시스템의 체계적인 '상태 관리'를 가능하게 만든다는 의미와 같다. 만약 기준 없이 주먹구구식으로 "이것도 필요하고 저것도 추가해야 해"라며 기능들을 덧붙이기만 한다면, 일정은 끝없이 지연되고 일은 결코 마무리되지 않는다.

물론 비즈니스를 전개하다 보면 정말 중요한 기능이 중간에 발견될 수도 있고, 그럴 때는 유연하게 추가할 수 있어야 한다. "처음 기획에 없었으니 절대 안 된다"라는 식의 경직된 선언이 정답은 아니다. 다만 프로세스 중간에 새로운 스펙이 추가되는 만큼, 기획자는 구성원들에게 이 기능이 왜 필요한지, 왜 반드시 지금 타이밍이어야만 하는지, 그리고 일정을 늦춰서라도 강행할 가치가 있는지 투명하게 공유하고 설득할 수 있어야 한다.

좋은 제품은 결국 깊이 있는 고민이 녹아든 좋은 기획에서 탄생한다. 기획 단계에서 어떤 점들을 고려하여 기능들을 배치했고, 출시 이후 사용자들이 이에 어떻게 반응했는지 등의 구체적인 데이터가 시스템적으로 관리되지 않으면 안 된다. 전후 맥락에 대한 기록과 추적이 없다면, 제품에 문제가 생겨도 원인이 무엇인지 모른 채 서서히 몰락해가는 제품을 바라볼 수밖에 없다.

IT 서비스를 구축한다는 것은 결코 혼자만의 플레이가 아니다. 기획자, 디자이너, 개발자 등 다양한 플레이어들이 긴밀하게 소통하고 함께 결정해 나가는 유기적인 협업의 과정이다.

실무를 하다 보면 나 역시 이 모든 원칙을 완벽하게 지키며 세밀하게 업무를 수행하지 못할 때가 많다. 현실적인 제약과 타협해야 하는 순간은 언제나 찾아오기 마련이다. 그러나 중요한 것은 부족한 부분을 인지하고 차츰차츰 프로세스의 체계를 잡아가는 태도다. 거대한 시스템의 이정표가 되어줄 Information Architecture를 명확히 세우는 것부터 시작해 보자. 탄탄한 구조 위에서 비로소 시장과 사용자에게 선택받는 좋은 서비스가 만들어지는 법이다.