이슈와 문서를 1:1로 연결한 팀 운영 규칙
이슈와 문서에 같은 업무 유형을 붙이고 작업마다 같은 이름의 문서를 연결했습니다.
작업 요약
17종 업무 유형 · 이슈와 문서 1:1 연결 · 운영 가이드 6개
이슈와 문서를 1:1로 연결한 이유
같은 문제를 다시 확인할 때 이전 작업의 기록을 찾을 수 있어야 했습니다. 이슈와 문서가 따로 쌓이면 장애 원인과 변경 이유를 다시 찾기 어려웠습니다.
작업↔중앙 문서 1:1 매핑과 태그 체계를 잡은 뒤, 실제 온보딩 로드맵·개인 기록 템플릿·멘토링 체크리스트까지 이어 붙인 이유는 누가 보더라도 지금 일이 어디까지 왔고 다음에 무엇을 봐야 하는지 찾을 수 있게 하기 위해서였습니다.
배경
팀이 커지면서 이슈와 문서가 사람마다 다른 방식으로 쌓이기 시작했습니다. 같은 작업을 어디에 기록했는지, 어떤 문서가 어떤 작업의 결과물인지 추적하기 어려워졌고 인수인계·온보딩 때마다 작업 배경과 진행 상황을 다시 확인해야 했습니다.
- 이슈 제목·문서 제목에 일관된 규칙이 없어 검색·추적이 비효율적
- 작업 기록과 문서가 서로 연결되지 않아 "이 작업의 문서가 어디 있나"를 매번 탐색
- 문서가 여러 곳에 흩어져 실제 인수인계·온보딩에서 잘 쓰이지 못함
17종 업무 유형 태그
태그가 전혀 없던 업무 추적에 17종 업무 유형 태그 체계를 신설하고 업무 추적 시스템과 중앙 문서 페이지에 동일하게 적용했습니다. 제목만 봐도 작업 성격이 드러나도록 했고, Google Docs/Sheets처럼 별도 문서 도구가 필요한 경우도 Confluence에서 끊기지 않도록 사용 기준과 링크 규칙을 정했습니다.
예) [신규 개발 | 라이브러리]처럼 유형과 영역이 제목 한 줄에 드러나도록 정리했습니다.
작업과 중앙 문서의 1:1 연결
핵심 운영 규칙은 작업 단위 ↔ 중앙 문서 페이지를 1:1로 매핑하는 것입니다. 문서화가 필요한 하위 작업이 생기면 같은 이름의 문서 페이지를 생성하게 했습니다. 구현·운영 흐름은 Jira 이슈, Confluence 문서, Bitbucket 저장소가 서로 끊기지 않도록 연결하는 방향으로 정리했고, 신규 구성원용 온보딩 페이지는 로드맵·환경 세팅·코드베이스·도메인·워크플로우·배포/운영·첫 티켓·개인 기록·멘토링 체크리스트로 분리했습니다.
이로써 "작업 → 허브 → 문서"가 항상 같은 구조로 연결되어 어떤 작업이든 결과 문서를 바로 찾을 수 있습니다. 코드 저장소가 필요한 작업은 온보딩 문서에 관련 repo군을 함께 남겨, 후임자가 이슈만 보고도 어느 저장소부터 열어야 하는지 찾을 수 있게 했습니다.
8월 말부터는 전체 구조, 서버 구조, 저장소 지도, DB, 데이터 배포, 개발 절차를 6개 가이드로 정리했습니다. 수집 DB에서 배포 DB와 고객사 DB까지 데이터가 이동하는 경로, 스키마 전환 때 이미지부터 배포한 뒤 DAG를 바꾸는 순서, AI 리뷰 뒤 사람이 확인할 사항을 실제 운영 흐름에 맞춰 적었습니다.
결과
역할
제가 직접 정한 범위는 업무 유형 태그 17종, Jira 작업과 Confluence 중앙 문서의 1:1 연결, 30/60/90일 확인 순서와 첫 티켓 가이드였습니다.
최근에는 플랫폼과 운영 흐름을 설명하는 6개 가이드를 작성했습니다. 문서를 작성한 범위와 시스템을 직접 구현한 범위는 구분했습니다. 고객사 배포와 일상 운영은 기술지원팀이 맡고, 데이터팀은 문제를 재현하고 수정하는 것으로 역할을 명시했습니다.
개별 개발 항목(예: Go 크롤러 라이브러리)도 이 표준 규칙 위에서 기록·관리됩니다.