일을 제대로 공유하고 관리하는 법: 투명한 협업의 기술

365 Proejct (284/365)

어떻게 일할 것인가 001

왜 우리는 일을 공유하고 기록해야 하는가

일을 한다는 것은 혼자 하는 것이 아닙니다. 특히 제품을 만드는 일은 더욱 그렇습니다. 우리가 매일 하는 일들이 서로 연결되어 있고, 누군가의 결과물이 다른 누군가의 시작점이 되기 때문입니다. 그래서 우리는 일을 투명하게 공유하고 체계적으로 관리해야 합니다.

일의 흐름을 만들고 유지하기

동시에 시작하지 말고, 하나씩 끝내기

여러 일을 동시에 시작하면 어떻게 될까요? 대부분의 일이 중간에 멈추고, 전체적인 속도는 오히려 느려집니다. 마치 고속도로에 차가 너무 많으면 모든 차가 느려지는 것과 같습니다. 그래서 우리는 '끌어오기(Pull)' 방식으로 일합니다. 한 가지 일을 끝내면, 그다음 일을 끌어오는 것입니다.

진행 중인 일의 수를 제한하는 것은 단순해 보이지만 매우 강력한 원칙입니다. 팀원 한 명이 동시에 2-3개 이상의 일을 진행하지 않도록 하면, 각 일에 더 집중할 수 있고 더 빨리 끝낼 수 있습니다. 무엇보다 중요한 것은, 시작한 일을 끝내는 문화가 자리 잡는다는 점입니다.

실제로 이를 적용할 때는 팀 규모에 따라 조정이 필요합니다. 예를 들어 6명 팀이라면 '진행 중' 상태의 일을 3-4개로 제한하고, '리뷰 대기' 상태는 2개로 제한하는 식입니다. 이 한도를 초과하면 새로운 일을 시작하지 않고, 먼저 진행 중인 일을 끝내거나 막힌 일을 해결하는 데 집중해야 합니다.

큰 목표를 작은 조각으로 나누기

큰 일을 그대로 시작하면 언제 끝날지 알 수 없고, 중간에 방향이 틀렸을 때 돌아오기도 어렵습니다. 그래서 우리는 큰 목표를 작은 조각으로 나눕니다.

프로젝트 수준의 큰 목표(Epic)는 수주에서 수개월에 걸친 작업입니다. 이것을 사용자 관점의 가치 단위(Story)로 나누고, 다시 1-3일 내에 끝낼 수 있는 실행 단위(Task)로 쪼갭니다. 각 단계마다 명확한 완료 기준이 있어야 합니다. Epic은 비즈니스 가설과 측정 가능한 성공 지표가 있어야 하고, Story는 사용자 관점의 수용 조건이 명확해야 하며, Task는 구체적인 산출물이 정의되어야 합니다.

이렇게 작게 나누는 것이 중요한 이유는 빠른 검증 때문입니다. 작은 단위로 가설-실행-리뷰 루프를 빠르게 돌면서, 잘못된 방향으로 가고 있다면 빨리 발견하고 수정할 수 있습니다. 3일 이상 걸리는 작업이 있다면 "하위 결과물이 독립적으로 검증 가능한가?"를 기준으로 더 작게 나누는 것이 좋습니다.

일을 명확하게 정의하고 공유하기

제목을 쓰는 법: 동사로 시작하라

일의 제목은 그 일의 얼굴입니다. 좋은 제목은 네 가지 조건을 갖춰야 합니다. 완전한 문장이어야 하고, 실행 가능해야 하며, 결과에 초점을 맞춰야 하고, 범위가 명확해야 합니다.

"CI 개선"이라고 쓰면 무엇을 어떻게 개선한다는 것인지 알 수 없습니다. 대신 "CI 빌드 속도를 50% 향상시키는 방법 조사하기"라고 쓰면, 무엇을 해야 하고 어떤 결과를 기대하는지 명확해집니다. 동사로 시작하는 이유는 행동을 의미하고, 행동은 시작과 끝이 있기 때문입니다.

설명은 맥락을 담되 간결하게

일의 설명을 쓸 때 가장 중요한 원칙은 "Simple & Silly"입니다. 복잡한 템플릿을 채우려고 애쓰지 말고, 이 설명을 누가 읽을지 생각하며 필요한 정보만 전달하세요.

사용자 스토리를 작성할 때는 "As a [사용자], I want [무엇을], so that [가치]" 형식을 사용하면 목적이 명확해집니다. 수용 조건은 Given-When-Then 형식으로 작성하면 테스트 가능한 명확한 기준이 됩니다. 예를 들어:

Given 신규 사용자가 플랜을 선택했고 When 유효한 카드로 결제를 시도하면 Then 결제는 승인되고 즉시 프리미엄 권한이 부여된다

중요한 것은 왜(Why) 이 일을 하는지 반드시 포함시키는 것입니다. 맥락 없는 일은 방향을 잃기 쉽고, 나중에 "이거 왜 했더라?" 하는 상황이 생깁니다.

메타데이터를 일관성 있게 사용하기

우선순위는 4단계로 구분하는 것이 효과적입니다. Blocker는 즉시 착수해야 할 장애나 보안 이슈, High는 48시간 내 리뷰가 필요한 주요 기능, Medium은 일반적인 개선사항, Low는 유휴 시간에 처리할 낮은 영향도의 작업입니다. 각 단계별로 명확한 SLA를 정하면 팀원들이 무엇부터 해야 할지 판단하기 쉬워집니다.

라벨은 도메인-컴포넌트-유형의 3단 구조로 사용하면 체계적입니다. 예를 들어 'billing-api-bug'처럼 말입니다. 이렇게 하면 특정 영역의 특정 유형 이슈를 쉽게 찾을 수 있습니다.

담당자는 반드시 한 명으로 명확히 해야 합니다. 공동 책임은 무책임이 되기 쉽습니다. DRI(Directly Responsible Individual) 원칙을 지켜, 한 사람이 끝까지 책임지도록 합니다.

우선순위를 정하고 시간을 관리하기

NOW, NEXT, LATER로 생각하기

모든 일이 급하고 중요해 보일 때가 있습니다. 하지만 정말 그럴까요? 우리는 일을 세 가지 카테고리로 나눕니다. NOW는 지금 당장, 이번 주에 반드시 끝내야 하는 일입니다. NEXT는 다음 주기에 할 일입니다. LATER는 언젠가 하면 좋을 일입니다.

이렇게 분류할 때는 자비롭지 못할 정도로 엄격해야 합니다. NOW에는 정말 긴급한 것만 넣으세요. 나머지는 과감하게 NEXT나 LATER로 미루세요. 백로그를 정리할 때는 상위 10-20개만 "준비됨" 상태로 유지하고, 나머지는 아이디어 풀로 관리하는 것이 좋습니다.

역산으로 계획하기

일의 마감일이 정해져 있다면, 끝에서부터 거꾸로 계획을 세워보세요. 금요일까지 완성해야 한다면, 목요일에는 리뷰가 끝나야 하고, 수요일에는 개발이 완료되어야 하고, 화요일에는 중간 점검을 해야 합니다. 이렇게 역산하면 지금 당장 무엇을 시작해야 하는지 명확해집니다. 그리고 항상 예상 시간의 20% 정도는 버퍼를 두세요.

협업을 명확하게 만들기

역할과 책임의 명확화

협업의 기본은 명확한 역할 분담입니다. 이 일의 주 담당자는 누구인가? 누구의 도움이 필요한가? 언제 함께 논의해야 하는가? 이런 것들이 처음부터 명확해야 합니다.

특히 여러 팀이 관련된 일이라면 "프론트엔드는 앨리스가, 백엔드는 밥이, 결제 시스템은 찰리가 담당하고, 매일 오전 10시에 싱크업"처럼 구체적으로 정하고 기록하세요. 의사결정 과정과 근거도 반드시 기록으로 남겨야 합니다. 주요 변경사항이 있을 때는 왜 바뀌었는지 코멘트를 남기는 것이 중요합니다.

리뷰와 피드백의 속도

리뷰는 일의 흐름에서 가장 큰 병목이 되기 쉽습니다. 누군가 열심히 일을 끝냈는데, 리뷰가 며칠씩 지연되면 전체 흐름이 막힙니다. 그래서 24시간 내 리뷰 응답을 원칙으로 해야 합니다. 완벽한 리뷰보다는 빠른 피드백이 더 중요합니다.

리뷰 대기 중인 작업이 쌓이면 팀 전체가 새로운 작업을 시작하기보다 리뷰를 우선적으로 처리해야 합니다. 이것이 전체적인 처리량을 높이는 가장 효과적인 방법입니다.

정체와 병목 해결하기

좀비 이슈 방지

30일 이상 상태가 바뀌지 않은 일을 '좀비 이슈'라고 부릅니다. 살아있는 것 같지만 사실은 죽은 일들입니다. 이런 일들은 과감하게 정리해야 합니다.

7일 이상 업데이트가 없는 이슈는 자동으로 담당자에게 알림을 보내고, 14일이 지나면 우선순위와 범위를 재평가하는 미팅을 합니다. 정말 필요하면 다시 정의해서 시작하고, 필요 없으면 폐기합니다. 애매하게 남겨두는 것이 가장 나쁩니다.

블로킹 이슈가 생기면 즉시 가시화해야 합니다. 플래그를 사용하거나 별도 레이블을 붙여 모두가 알 수 있게 하고, 해결 책임자와 예상 해결 시간을 명시합니다.

측정하고 개선하기

숫자로 보는 일의 흐름

우리가 얼마나 효율적으로 일하고 있는지 알려면 몇 가지 지표를 봐야 합니다. 사이클 타임(일을 시작해서 끝내는 데 걸리는 시간), 리드 타임(요청받아서 완료까지 걸리는 시간), 처리량(일주일에 완료하는 일의 양) 같은 것들입니다.

누적 흐름 다이어그램(CFD)을 보면 어디에 일이 쌓이고 있는지 한눈에 알 수 있습니다. 컨트롤 차트로는 사이클 타임의 분포와 예측 가능성을 파악할 수 있습니다. Created vs Resolved 차트는 들어오는 일과 처리하는 일의 균형을 보여줍니다.

하지만 숫자에만 매몰되면 안 됩니다. 빨리 끝내는 것도 중요하지만, 제대로 끝내는 것이 더 중요합니다. 다시 열리는 이슈가 많다면, 품질에 문제가 있다는 신호입니다.

지속적인 개선 문화

매주 또는 격주로 짧은 흐름 점검 회의를 합니다. 30-45분 정도면 충분합니다. CFD를 보며 병목을 찾고, 정체된 이슈를 확인하고, WIP 한도를 조정할 필요가 있는지 논의합니다.

월간 회고에서는 더 큰 그림을 봅니다. 데이터를 기반으로 반복되는 문제를 찾고, 프로세스나 자동화를 개선할 방법을 찾습니다. "소통을 더 잘하자"같은 추상적인 개선안이 아니라, "매일 오전 10시에 5분 스탠드업을 한다"처럼 실행 가능한 개선안을 만듭니다.

자동화로 관리 부담 줄이기

반복적인 관리 작업은 자동화해야 합니다. 7일 이상 업데이트가 없으면 자동으로 담당자에게 알림을 보내고, PR이 생성되면 자동으로 상태를 '리뷰 중'으로 바꾸고, 리뷰 대기가 너무 많으면 팀 채널에 알림을 보내는 식입니다.

이슈 링크도 적극 활용해야 합니다. 'blocks/is blocked by' 관계를 명확히 하면 의존성을 한눈에 파악할 수 있고, 'relates to'로 연관 작업을 연결하면 맥락을 이해하기 쉬워집니다.

마치며: 도구가 아닌 문화

프로젝트 관리 도구는 그저 도구일 뿐입니다. JIRA든, Notion이든, Asana든 무엇을 쓰느냐보다 중요한 것은 우리가 일을 대하는 태도와 문화입니다. 투명하게 공유하고, 명확하게 정의하고, 작게 쪼개고, 빠르게 실행하고, 지속적으로 개선하는 것. 이것이 우리가 추구해야 할 일하는 방식입니다.

완벽한 프로세스는 없습니다. 우리 팀에 맞는 방식을 찾아가는 과정이 중요합니다. 너무 많은 규칙을 만들면 오히려 일이 느려집니다. 너무 자유롭게 두면 혼란스러워집니다. 그 균형을 찾아가는 것이 핵심입니다.

기억하세요. 우리는 도구를 사용하는 것이지, 도구에 사용당하는 것이 아닙니다. 프로세스가 일을 더 잘할 수 있게 도와준다면 유지하고, 방해가 된다면 과감히 바꾸면 됩니다. 중요한 것은 우리가 함께 가치 있는 결과물을 만들어가는 것이니까요.