Confluence 시작하기: 스페이스·페이지·문서 트리 구조를 실무에 맞게 설계하는 방법
Confluence 시작하기: 스페이스·페이지·문서 트리 구조를 실무에 맞게 설계하는 방법
Confluence를 처음 열었을 때 가장 많이 드는 생각은 대체로 비슷합니다. “그래서 뭘 어디에 써야 하지?” 기능보다 먼저 막히는 지점은 바로 구조입니다. 페이지는 만들 수 있는데 어디에 둬야 할지 모르겠고, 스페이스는 만들 수 있는데 팀별로 나눌지 프로젝트별로 나눌지 헷갈리기 쉽습니다.
특히 IT 실무 기획자는 회의록, 요구사항 문서, 운영가이드, 정책 문서처럼 성격이 다른 문서를 자주 다루기 때문에 초반 구조를 잘못 잡으면 문서가 쌓일수록 찾기 어려워집니다. 반대로 처음에 스페이스와 페이지 구조를 깔끔하게 설계해두면 Confluence는 단순한 문서 도구를 넘어 팀의 지식 허브로 작동합니다.
이번 글에서는 Confluence를 처음 시작하는 분들을 위해 스페이스와 페이지, 문서 트리 구조를 어떻게 설계하면 좋은지 실무 관점에서 차근차근 정리해보겠습니다.
1. Confluence 시작 전 먼저 이해해야 할 기본 구조
Confluence를 처음 시작할 때 가장 먼저 이해해야 할 것은 도구의 기본 단위입니다. 핵심은 크게 세 가지입니다. 스페이스, 페이지, 문서 트리입니다.
스페이스는 팀이나 프로젝트가 함께 문서를 만들고 저장하는 작업 공간입니다. 페이지는 그 안에 작성하는 개별 문서입니다. 문서 트리는 페이지와 하위 페이지를 연결해 문서의 계층을 만드는 구조입니다.
쉽게 말하면 스페이스는 문서가 사는 동네이고, 페이지는 각 집이며, 문서 트리는 골목길입니다. 골목길이 꼬이면 배달도 늦고 사람도 헤맵니다. 문서도 비슷합니다. 처음 구조를 대충 잡으면 나중에 모두가 길을 잃습니다.
2. 스페이스란 무엇인가: 팀별로 나눌까, 프로젝트별로 나눌까
Confluence에서 스페이스는 가장 큰 작업 단위입니다. 보통 팀 단위, 서비스 단위, 프로젝트 단위로 운영합니다. 문제는 여기서부터 선택지가 생긴다는 점입니다. 팀별로 나눌 것인지, 프로젝트별로 나눌 것인지에 따라 전체 문서 체계가 달라집니다.
2-1. 팀별 스페이스가 좋은 경우
운영팀, 기획팀, 개발팀처럼 조직이 비교적 안정적이고, 팀이 장기적으로 같은 업무를 반복한다면 팀별 스페이스가 관리하기 쉽습니다. 온보딩 문서, 운영 정책, 공통 회의록, 정기 보고서처럼 반복 문서가 많을수록 팀별 구조가 잘 맞습니다.
2-2. 프로젝트별 스페이스가 좋은 경우
서비스 개편, 신규 구축, 시스템 전환처럼 프로젝트 중심으로 일하는 조직이라면 프로젝트별 스페이스가 더 직관적일 수 있습니다. 특정 프로젝트와 관련된 요구사항, 회의록, 일정, 결정 이력을 한곳에 모으기 좋기 때문입니다.
2-3. 실무에서는 어떻게 선택할까
대부분의 IT 조직에서는 팀별 스페이스를 기본으로 두고, 규모가 큰 프로젝트만 별도 스페이스로 운영하는 방식이 가장 안정적입니다. 모든 프로젝트를 스페이스로 쪼개면 나중에 문서가 너무 많이 분산되고, 반대로 모든 문서를 하나의 스페이스에 몰아넣으면 정리가 되지 않습니다.
3. 페이지란 무엇인가: 문서의 기본 단위를 이해하자
페이지는 Confluence에서 실제로 문서를 작성하는 단위입니다. 회의록 한 개, 요구사항 문서 한 개, 운영가이드 한 개가 각각 하나의 페이지가 됩니다. 즉 페이지는 파일 하나라고 생각하면 이해가 쉽습니다.
다만 일반 문서 파일과 다른 점은 페이지가 서로 링크로 연결되고, 댓글과 멘션으로 협업할 수 있으며, 상위 페이지와 하위 페이지 구조를 만들 수 있다는 점입니다. 그래서 페이지는 단순한 파일보다 훨씬 유기적으로 연결됩니다.
실무에서는 문서를 너무 크게 만들기보다 주제별로 적절히 쪼개는 것이 좋습니다. 예를 들어 “서비스 운영 정책 전체”를 한 문서로 몰아넣기보다, 계정 정책, 알림 정책, 장애 대응 기준처럼 나누는 편이 수정과 검색이 편합니다.
4. 문서 트리 구조는 어떻게 잡아야 할까
Confluence에서 문서 트리는 페이지를 계층 구조로 정리하는 방식입니다. 보통 상위 페이지 아래에 하위 페이지를 두어 큰 주제와 세부 문서를 연결합니다.
4-1. 추천 구조는 2~3단계
문서 트리는 너무 깊지 않게 운영하는 것이 좋습니다. 일반적으로 2~3단계 정도가 가장 관리하기 편합니다. 깊이가 너무 깊어지면 사용자가 어느 문서 아래에 들어가야 하는지 헷갈리기 쉽습니다.
4-2. 상위 페이지는 허브 역할로 만들기
상위 페이지는 긴 설명을 가득 적는 문서라기보다 하위 문서로 연결되는 허브로 만드는 것이 좋습니다. 예를 들어 “서비스 운영가이드”라는 상위 페이지를 만들고, 그 아래에 장애 대응, 계정 운영, 공지 기준, 모니터링 정책 페이지를 두는 식입니다.
4-3. 같은 성격의 문서는 같은 위치에 두기
회의록은 회의록끼리, 정책 문서는 정책 문서끼리, 기획 문서는 기획 문서끼리 모여 있어야 찾기 쉽습니다. 문서가 생기는 대로 아무 데나 두면 처음엔 편하지만, 세 달 뒤에는 누구도 찾지 못하는 종이 미로가 됩니다. 디지털인데도 길을 잃는 건 꽤 현대적입니다.
5. IT 실무 기획자에게 추천하는 Confluence 문서 구조 예시
IT 실무 기획자라면 아래와 같은 구조로 시작하는 것이 무난합니다.
예시: 서비스 기획팀 스페이스 구조
- 팀 소개 및 온보딩
- 회의록
- 주간 회의
- 프로젝트 회의
- 의사결정 기록
- 기획 문서
- 요구사항 정의서
- PRD
- 화면 정책
- 운영 문서
- 운영가이드
- FAQ
- 장애 대응 기준
- 프로젝트 아카이브
이 구조의 장점은 문서 성격이 명확하게 나뉜다는 점입니다. 새 문서를 만들 때도 “이건 회의록인가, 정책 문서인가, 운영가이드인가”만 판단하면 어디에 둘지 바로 결정할 수 있습니다.
6. 템플릿을 먼저 만들면 좋은 이유
Confluence를 처음 시작할 때 많은 팀이 구조부터 만들고 템플릿은 나중으로 미룹니다. 그런데 실무에서는 오히려 템플릿을 초반에 잡는 것이 훨씬 효율적입니다.
6-1. 반복 문서 품질이 일정해진다
회의록, 요구사항 문서, 운영 점검표처럼 자주 쓰는 문서는 템플릿만 있어도 팀 전체 문서 품질이 안정됩니다. 누가 작성하든 기본 형식이 같아지기 때문입니다.
6-2. 새 문서 작성 속도가 빨라진다
빈 페이지는 보기엔 깨끗하지만 실제로는 생각보다 잔인합니다. 무엇을 먼저 써야 할지 모르게 만들죠. 템플릿은 그 공백을 줄여줍니다. 제목, 목적, 배경, 작업 항목, 결정 사항 같은 기본 틀만 있어도 작성 속도가 확 달라집니다.
6-3. 실무 추천 템플릿
- 회의록 템플릿
- 요구사항 문서 템플릿
- 운영가이드 템플릿
- 장애 보고 템플릿
- 온보딩 문서 템플릿
7. 권한 설정은 어떻게 시작해야 할까
초기 권한 설계는 Confluence 운영에서 생각보다 중요합니다. 너무 열어두면 민감한 정보가 보일 수 있고, 너무 잠가두면 협업이 느려집니다.
7-1. 기본은 스페이스 권한 중심
처음에는 스페이스 단위로 접근 권한을 나누는 것이 가장 쉽습니다. 예를 들어 운영팀 스페이스는 운영팀 중심으로, 프로젝트 스페이스는 참여자 중심으로 권한을 설정하면 됩니다.
7-2. 민감 문서만 페이지 제한 사용
급여, 인사, 보안 정책, 외부 공개 전 문서처럼 민감한 문서만 페이지 제한 기능으로 관리하는 방식이 실무적입니다. 처음부터 모든 문서를 세세하게 잠그면 관리 비용이 커집니다.
7-3. 권한은 문서 구조와 함께 설계해야 한다
문서 구조와 권한은 따로 놀면 안 됩니다. 예를 들어 공개 문서와 제한 문서가 한 상위 구조 안에 뒤섞여 있으면 운영이 어려워집니다. 따라서 공개 범위가 비슷한 문서는 같은 영역에 두는 편이 좋습니다.
8. Confluence 처음 세팅할 때 자주 하는 실수
- 스페이스를 너무 많이 만들어 문서가 흩어지는 경우
- 한 페이지에 모든 내용을 몰아넣어 가독성이 떨어지는 경우
- 문서 트리를 너무 깊게 만들어 찾기 어려워지는 경우
- 템플릿 없이 문서를 작성해 형식이 제각각이 되는 경우
- 권한을 과하게 제한해 협업이 느려지는 경우
이 다섯 가지는 Confluence 초보 팀에서 자주 보는 전형적인 장면입니다. 처음엔 다들 “일단 만들자” 모드로 돌진하는데, 그 결과 문서 도시계획 없이 건물이 올라갑니다. 그리고 몇 달 뒤 재개발 회의를 하게 됩니다. 문서도 도시처럼 처음 설계가 중요합니다.
결론
Confluence를 잘 시작하려면 기능보다 구조를 먼저 이해해야 합니다. 스페이스는 큰 작업 공간이고, 페이지는 실제 문서이며, 문서 트리는 그 문서들을 찾기 쉽게 연결하는 길입니다. 여기에 템플릿과 권한 설정까지 더해지면 문서는 단순 저장물이 아니라 실무 자산으로 바뀝니다.
IT 실무 기획자라면 처음부터 완벽한 구조를 만들 필요는 없습니다. 대신 팀별 스페이스를 기본으로 두고, 문서 성격별로 상위 카테고리를 나누고, 자주 쓰는 문서부터 템플릿을 만드는 방식으로 시작하면 충분합니다.
Confluence는 많이 쓰는 사람이 이기는 도구가 아니라, 잘 정리한 사람이 오래 편한 도구입니다. 시작은 단순하게, 구조는 명확하게 가져가면 됩니다.
FAQ
Q1. Confluence에서 스페이스와 페이지의 차이는 무엇인가요?
A. 스페이스는 팀이나 프로젝트 단위의 작업 공간이고, 페이지는 그 안에 작성하는 개별 문서입니다. 스페이스 안에 여러 페이지가 들어간다고 이해하면 쉽습니다.
Q2. Confluence를 처음 만들 때 가장 먼저 정해야 할 것은 무엇인가요?
A. 문서를 어떤 기준으로 나눌지 정하는 것이 먼저입니다. 팀별, 프로젝트별, 서비스별 중 어떤 구조가 우리 조직에 맞는지 결정해야 이후 페이지 체계도 자연스럽게 잡힙니다.
Q3. 문서 트리는 몇 단계까지 만드는 것이 좋나요?
A. 보통 2~3단계 정도가 가장 실무적입니다. 너무 깊으면 찾기 어렵고, 너무 얕으면 문서가 한곳에 몰려 복잡해질 수 있습니다.
Q4. 템플릿은 왜 초반에 만드는 것이 좋나요?
A. 회의록, 요구사항 문서, 운영가이드처럼 반복 문서를 표준화할 수 있기 때문입니다. 작성 속도와 문서 품질, 협업 효율이 모두 좋아집니다.
Q5. 권한은 어떻게 시작하는 것이 좋나요?
A. 처음에는 스페이스 단위 권한을 기본으로 설정하고, 민감한 문서만 페이지 제한 기능으로 관리하는 방식이 가장 무난합니다.