Confluence 문서 구조 설계 방법: Space·Page 트리 설계 실전 가이드
Confluence 문서 구조 설계 방법: Space·Page 트리 설계 실전 가이드
Confluence를 처음 사용할 때는 대부분 문서를 만드는 것부터 시작합니다. 하지만 프로젝트가 커지고 팀원이 늘어나면 새로운 문제가 발생합니다.
"이 문서는 어디에 만들어야 하지?"
"비슷한 문서가 왜 세 개나 있지?"
"최신 요구사항 문서는 어디 있는 거지?"
문서가 많아지는 것은 좋은 현상입니다. 하지만 구조 없이 쌓이면 Confluence는 지식 저장소가 아니라 디지털 창고가 됩니다. 찾기는 어렵고, 관리자는 점점 지치게 됩니다.
특히 IT 기획자는 요구사항 정의서, 정책 문서, 화면 설계서, 회의록, 운영 가이드 등 다양한 문서를 관리하기 때문에 처음부터 구조 설계를 제대로 해야 합니다.
이번 글에서는 IT 기획자 관점에서 Confluence Space와 Page 트리를 어떻게 설계해야 하는지, 프로젝트 관리와 문서 검색 효율을 높이는 실무 방법을 정리하겠습니다.
1. 왜 Confluence 문서 구조 설계가 중요한가
문서 관리에서 가장 중요한 것은 작성보다 검색입니다. 필요한 순간에 원하는 문서를 찾지 못하면 문서는 존재하지 않는 것과 비슷합니다.
IT 프로젝트에서는 하나의 기능을 만들기 위해 다양한 문서가 생성됩니다.
- 요구사항 정의서
- 화면 정책서
- API 문서
- 테스트 시나리오
- 운영 가이드
- 회의록
이 문서들이 목적 없이 하나의 공간에 쌓이면 시간이 지나면서 문서 관계가 끊어집니다.
좋은 Confluence 구조는 단순히 보기 좋은 트리가 아닙니다. 업무 흐름을 반영한 지식 구조입니다.
2. Space와 Page의 역할 이해하기
| 구분 | 역할 |
|---|---|
| Space | 프로젝트, 조직, 제품 단위의 큰 영역 |
| Page | 세부 문서와 정보를 관리하는 단위 |
쉽게 생각하면 Space는 책장이고 Page는 책입니다.
책장이 너무 많으면 찾기 어렵고, 책을 아무 곳에 꽂으면 다시 찾기 어렵습니다.
결국 중요한 것은 적절한 Space 개수와 논리적인 Page 구조입니다.
3. IT 기획자를 위한 Space 설계 기준
IT 기획자는 Space를 만드는 기준을 "사람"보다 "업무 목적" 중심으로 잡는 것이 좋습니다.
추천 Space 기준
- 제품(Product) Space
- 프로젝트(Project) Space
- 운영(Operation) Space
- 지식(Knowledge) Space
- 조직(Team) Space
예를 들어 신규 서비스 개발 프로젝트라면 아래처럼 구성할 수 있습니다.
Project A Space ├ 요구사항 ├ 정책 ├ 화면 설계 ├ 개발 협업 ├ 테스트 ├ 배포 └ 회고
Space는 너무 세분화하지 않는 것이 좋습니다.
문서마다 Space를 만들면 관리 포인트가 폭발합니다.
4. Page 트리 구조 설계 방법
Page 구조는 사용자가 정보를 찾는 순서대로 설계해야 합니다.
좋은 Page 구조
서비스 관리 ├ 서비스 소개 ├ 요구사항 │ ├ 기능 정의 │ ├ 정책 문서 │ ├ 화면 설계 │ └ 운영 가이드
상위 Page는 큰 개념, 하위 Page는 실행 정보가 들어가는 방식이 좋습니다.
나쁜 구조 예시
문서 ├ 문서1 ├ 문서2 ├ 신규문서 ├ 최종문서 └ 진짜최종문서
"최종", "수정본", "최종_진짜" 같은 이름은 시간이 지나면 팀의 작은 암호문이 됩니다.
5. 프로젝트 문서 구조 예시
프로젝트 Space ├ 프로젝트 개요 ├ 일정 관리 ├ 요구사항 정의 ├ 회의록 ├ 디자인 ├ 개발 ├ QA ├ 배포 └ 회고
기획자는 프로젝트 시작부터 종료까지 흐름이 이어지도록 구성하는 것이 중요합니다.
6. 제품/서비스 문서 구조 예시
Product Space ├ 서비스 소개 ├ 사용자 정책 ├ 기능 정책 ├ 화면 정의 ├ 데이터 정책 ├ FAQ └ 운영 기준
제품 문서는 프로젝트가 끝난 뒤에도 계속 유지되는 지식 자산입니다.
7. 운영 문서 구조 예시
Operation Space ├ 장애 대응 ├ 운영 가이드 ├ 모니터링 ├ 배포 절차 ├ 장애 회고 └ FAQ
운영 문서는 "찾는 속도"가 중요합니다.
장애 상황에서는 예쁜 구조보다 빠른 접근이 더 중요합니다.
8. 문서 네이밍 규칙 만들기
문서 구조만큼 중요한 것이 제목 규칙입니다.
추천 규칙
- [PRD] 기능명
- [Policy] 정책명
- [Guide] 운영 방법
- [Meeting] 회의 날짜
- [FAQ] 질문 내용
제목만 봐도 문서 목적을 알 수 있어야 합니다.
9. 구조 설계 시 자주 하는 실수
- 모든 문서를 하나의 Space에 저장
- Space를 너무 많이 생성
- 페이지 제목 규칙 없음
- 중복 문서 생성
- 아카이브 기준 없음
Confluence는 많이 만드는 것보다 잘 찾게 만드는 것이 중요합니다.
결론
Confluence 문서 구조 설계의 핵심은 Space와 Page를 업무 흐름에 맞게 설계하는 것입니다.
IT 기획자는 단순히 문서를 작성하는 사람이 아니라, 조직의 지식 구조를 설계하는 역할도 해야 합니다.
좋은 구조는 새로운 팀원이 들어와도 빠르게 이해할 수 있고, 프로젝트가 커져도 문서가 길을 잃지 않게 만듭니다.
결국 좋은 Confluence 구조란 문서를 많이 쌓는 구조가 아니라, 필요한 정보를 빠르게 찾고 실행할 수 있게 만드는 구조입니다.
FAQ
Q1. Confluence Space는 몇 개 정도 만드는 것이 좋나요?
A. 조직 규모와 업무 목적에 따라 다르지만 프로젝트, 제품, 운영 단위처럼 명확한 기준으로 만드는 것이 좋습니다.
Q2. Page 트리는 얼마나 깊게 만들어야 하나요?
A. 너무 깊으면 탐색성이 떨어지므로 보통 3~4단계 이내가 관리하기 좋습니다.
Q3. 오래된 문서는 어떻게 관리해야 하나요?
A. Archive Space를 만들어 종료된 문서를 분리하는 방식이 좋습니다.
Q4. IT 기획자가 가장 먼저 만들어야 할 문서는 무엇인가요?
A. 프로젝트 개요, 요구사항 문서, 정책 문서, 회의록 구조부터 만드는 것을 추천합니다.
Q5. 문서 구조 변경은 언제 해야 하나요?
A. 문서를 찾는 시간이 늘어나거나 중복 문서가 생기기 시작하면 구조 개선 시점입니다.