업무 추적과 문서 운영을 표준 규칙으로 통일해 팀 전체의 추적성과 인수인계·온보딩 효율을 끌어올린 프로세스 정립
문서 정리는 생산성이 좋아 보이는 부가 작업이 아니라, 팀이 같은 문제를 반복해서 묻지 않게 하는 인프라입니다. 이슈와 문서가 따로 놀면 장애와 작업 히스토리가 금방 사라집니다.
작업↔중앙 문서 1:1 매핑과 태그 체계를 잡은 뒤, 실제 온보딩 로드맵·개인 기록 템플릿·멘토링 체크리스트까지 이어 붙인 이유는 누가 보더라도 지금 일이 어디까지 왔고 다음에 무엇을 봐야 하는지 찾을 수 있게 하기 위해서였습니다.
팀이 커지면서 이슈와 문서가 사람마다 다른 방식으로 쌓이기 시작했습니다. 같은 작업을 어디에 기록했는지, 어떤 문서가 어떤 작업의 결과물인지 추적하기 어려워졌고 인수인계·온보딩 때마다 맥락을 다시 찾아야 했습니다.
태그가 전혀 없던 업무 추적에 17종 업무 유형 태그 체계를 신설하고 업무 추적 시스템과 중앙 문서 페이지에 동일하게 적용했습니다. 제목만 봐도 작업 성격이 드러나도록 했고, Google Docs/Sheets처럼 별도 문서 도구가 필요한 경우도 Confluence에서 끊기지 않도록 사용 기준과 링크 규칙을 정했습니다.
예) [신규 개발 | 라이브러리]처럼 유형과 영역이 제목 한 줄에 드러나도록 정리했습니다.
핵심 운영 규칙은 작업 단위 ↔ 중앙 문서 페이지를 1:1로 매핑하는 것입니다. 문서화가 필요한 하위 작업을 트리거로, 같은 이름의 문서 페이지를 생성하게 했습니다. 구현·운영 흐름은 Jira 이슈, Confluence 문서, Bitbucket 저장소가 서로 끊기지 않도록 연결하는 방향으로 정리했고, 신규 구성원용 온보딩 페이지는 로드맵·환경 세팅·코드베이스·도메인·워크플로우·배포/운영·첫 티켓·개인 기록·멘토링 체크리스트로 분리했습니다.
이로써 "작업 → 허브 → 문서"가 항상 같은 구조로 연결되어 어떤 작업이든 결과 문서를 바로 찾을 수 있습니다. 코드 저장소가 필요한 작업은 온보딩 문서에 관련 repo군을 함께 남겨, 후임자가 이슈만 보고도 어느 저장소부터 열어야 하는지 찾을 수 있게 했습니다.
데이터 엔지니어링 리드로서 업무 유형 태그 체계 설계 → 운영 규칙 정립 → 주간/일일 보고·문서 관리 표준화를 단독으로 설계·정립했고 이를 팀 전체에 적용했습니다. 입사 초기의 문서 표준화 경험에서 출발해 팀 운영 표준으로 발전시켰습니다.
개별 개발 항목(예: Go 크롤러 라이브러리)도 이 표준 규칙 위에서 기록·관리됩니다.