¶ 1권 — 업무 시스템 활용 가이드 (Slack·Jira·Confluence 구독형 기반)
이 책은 스타트업이 몸집을 키우다 보면 반드시 부딪히는 문제 — "결정은 났는데 기록이 없다", "담당자가 퇴사하니 배경도 함께 사라졌다" — 를 다룬다. 핵심 전제는 정보마다 저마다 다른 생명주기가 있고, 그 생명주기에 맞는 도구에 담아야 유실되지 않는다는 것이다.
¶ 정보의 생명주기와 단계별 도입
정보는 성격에 따라 담아야 할 도구가 다르다.
- 지금 이 순간의 신호 → Slack (휘발성 실시간 소통)
- 무엇을 언제까지 누가 할지 → Jira (반영구 업무 기록)
- 왜 그렇게 했는지의 배경 → Confluence (영구 지식관리)
세 곳을 링크로 연결해두면 몇 달 뒤 이슈 하나만 열어도 배경부터 결과까지 따라갈 수 있다.
세 도구는 모두 인원 비례 구독료를 내는 SaaS다. 이 책은 빠른 도입이 우선인 초기 단계의 구독형 조합을 기준으로 삼는다.
도입도 단계별로 이뤄져야 한다.
| 조직 규모 | 도입 신호 | 도입 도구/조치 |
|---|---|---|
| 1~5명 | — | Slack만으로 충분 |
| 5~15명 | "누가 하기로 했었지?"가 반복됨 | Jira 도입 |
| 15~50명 | 퇴사로 배경 지식이 사라지는 신호가 보임 | Confluence 도입 |
| 50명 이상 | — | 부서 단위 표준화와 자동화(라우팅 규칙) 도입 |
흔한 실패는 두 가지다.
- 작은 팀이 무거운 프로세스를 앞서 갖추는 것
- 큰 팀이 "자유로운 문화"를 핑계로 정비를 미루다 조직 기억을 통째로 잃는 것
¶ Slack: 실시간 소통의 규율
Slack의 기본 원칙은 "지금 확인하면 끝나는 것"만 여기 남기고, 다시 찾아봐야 할 것은 Confluence로 옮기는 것이다.
채널 운영 원칙은 다음과 같다.
- 전사 공지 채널을 하나로 고정
- 목적별(공지/정보공유/협업/알림)로 채널 분리
- 접두어 규칙으로 채널명 통일
- 활동 없는 채널은 주기적으로 아카이빙
이 책이 제시하는 8가지 실무 규칙이 핵심 뼈대다.
- 업무 관련 논의는 DM이 아닌 채널에서
- 메시지는 쪼개지 말고 한 번에 정리해서
- 업무시간 외엔 예약전송
- 민감정보는 남기지 않기
- 링크만 던지지 말고 맥락과 함께
- 정말 급하면 채팅보다 전화
- 긴 메시지는 TL;DR(결론 요약)부터
- 채널 본문엔 TL;DR만 남기고 세부는 스레드로
멘션·요청에는 반드시 최소한의 반응(👀 확인, 🔄 진행중, ✅ 완료 등 이모지)을 남겨야 한다. 이는 "즉시 응답"이 아니라 "언제든 소통 가능하다는 신뢰"를 지키는 장치다.
사람이 쓰는 메시지 외에 Jira 상태 변경 알림, 서비스 모니터링 알림처럼 시스템이 자동으로 보내는 알림도 별도 채널로 분리해 관리해야 한다.
¶ Jira: 업무·요청·투입시간을 하나로 관리하기
Jira는 원칙적으로 모든 업무를 관리하는 기준점이며, 세 가지 용도로 쓰인다.
첫째, 업무 관리
- 프로젝트를 조직 구조(팀=프로젝트, 그룹=상위 프로젝트)에 대응
- 이슈 유형(에픽/스토리/작업/버그/하위작업)을 팀 성격에 맞게 선택
- 정기적 업무(회고·보고 등): 에픽 하나에 성격별 스토리를 고정해두고 실행할 때마다 작업만 새로 생성하는 lifecycle 방식
- 비정기 업무: 바로 작업이나 스토리로 등록
에픽에는 세부 내용 대신 "왜, 무엇을 위한 것인지"만 담고 Confluence 문서로 상세를 연결하는 것이 핵심 원칙이다. "공통업무"처럼 포괄적인 이슈에 실제 작업을 몰아넣는 것은 추적 불능을 초래하므로 피해야 한다.
둘째, 업무 요청 받기
요청 전용 이슈 유형에 다음 항목을 채운다.
- 제목
- 담당팀
- 설명 (배경/주요 수행 내용/기타 고려사항의 경량 3단 템플릿)
- 우선순위
- 희망완료일
팀 규모가 커지면(15명 이상) 담당팀 선택 시 자동으로 하위 작업이 생성되는 자동화 라우팅을 도입한다.
셋째, Worklog(작업 이력) 관리
세부 이슈 단위로 당일(늦어도 다음날 오전까지) 작업일·소요시간·설명을 기록한다. R&D 세액공제 등 외부 증빙이 필요한 조직에 특히 중요하다.
이 세 가지가 실제로 맞물리는 흐름은 하나의 사례로 제시된다.
- 회의 직후 Confluence 검토서 작성
- Jira 에픽 생성(문서 링크 포함)
- 작업/스토리 분해
- 매일 Worklog 기록
- 완료 처리
¶ Confluence: 배경과 지식을 정착시키기
"이 정보를 나중에 다시 찾아봐야 하는가"가 Confluence에 남길지 판단하는 기준이다. 대상은 다음과 같다.
- 회의록과 결정 배경
- 프로세스·매뉴얼
- 설계문서
- 협업 이력
- 인수인계 문서
스페이스(최상위 단위) 아래 페이지를 트리 구조로 쌓되, 전사 표준을 처음부터 완벽히 만들기보다 한 팀이 먼저 써보고 다른 팀이 따라가는 방식이 실용적이다. 숫자 접두어로 정렬 순서를 고정하는 방법도 소개된다.
Confluence는 "만들어두면 저절로 유지되는" 도구가 아니다. 이 책은 다섯 가지 관리 원칙을 제시한다.
- 스페이스·주요 페이지마다 담당자(Owner) 지정
- 분기 1회 점검
- 오래된 내용은 경고 표시
- 또는 보관용 스페이스로 이동
- 계층은 2~3단계 이내로 유지
회의 기록의 모범 흐름은 7단계로 정리된다.
- 사전 안건 공유(빈 페이지 미리 생성)
- 실시간 메모+녹음
- STT 보완
- 배경/논의내용/결정사항/액션아이템 순 초안 작성
- 작성자 자체 리뷰 후 게시
- 참석자 리뷰(기한 명시)
- 확정 표시 및 Jira 연결
¶ Google Workspace와의 역할 분담, 그리고 세 시스템을 잇는 흐름
Google Workspace(또는 Microsoft 365)는 핵심 3대 시스템을 보조하는 작업공간이다.
| 도구 | 역할 |
|---|---|
| Gmail | 외부 공식 소통 (조치 필요 건은 Jira로 등록) |
| Docs/Slides | 공동편집 초안 작성 (완성되면 Confluence로 정착) |
| Calendar | 일정 조율 (결과물은 Confluence·Jira로 연결) |
| Drive | 원본 파일 백업소 |
| Google 그룹스 | Confluence 스페이스 권한과 SSO 연동 |
결론적으로 이 책은 업무 기록을 "배경 → 주요 수행 내용 → 이슈 및 고려사항"이라는 하나의 서사 구조로 본다. 세 도구는 이 서사의 각 부분을 나눠 맡는 것에 비유된다.
- Slack = 일기
- Jira = 경력사항
- Confluence = 회고록
책은 다섯 가지 원칙으로 마무리된다.
- 정보 성격별 도구 분리
- 상호 링크 연결
- 작은 것부터 정비
- 가능한 부분 자동화(테스트 필수)
- 팀 규모에 맞게 계속 갱신
이 모든 것의 근본 목적은 정보 비대칭을 없애는 투명한 기록 문화에 있다.
¶ 참고할 만한 사례
- GitLab: Slack 논의가 핸드북에 기록되지 않으면 "공식적으로 없었던 일"로 취급
- Slack(社): 채널 접두어·설명란·자동 아카이빙 규칙으로 채널 난립을 관리
- Doist·Zapier·Automattic 등 비동기 근무 문화 조직: DM 대신 공개 채널, TL;DR, 처리 시점 선통보를 공통적으로 준수
- 우아한형제들: 목적별 채널 분리, Jira·Confluence의 Slack 연동, Slack Connect로 외부 협업사와 소통
- Atlassian: 자사 제품을 스스로 쓰며 "에픽엔 배경만" 원칙 준수
- Spotify: 스쿼드 자율성과 Now/Next/Later 로드맵으로 큰 그림만 공유
- Google·Amazon: Google의 설계 문서 문화와 Amazon의 6페이지 내러티브 회의 문화 모두 "말보다 문서"라는 같은 원칙을 보여줌
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.