작업과 티켓 — 개념, 추적 시스템 및 작업 관리

작업과 티켓이란?

작업 — 추적 시스템에 기록된 작업 단위. 설명, 우선순위(Critical, High, Medium, Low), 담당자, 마감일, 상태를 포함합니다. 모바일 개발에서 작업은 “아바타가 있는 프로필 화면 추가”, “피드 페이지네이션 구현”, “targetSdk를 35로 업데이트” 등이 될 수 있습니다. 각 작업은 프로젝트, 스프린트, 특정 개발자 또는 팀에 연결됩니다.

티켓 — 더 넓은 개념입니다. 티켓은 버그 리포트(“Android 14에서 화면 회전 시 앱 충돌”), 기능 요청(“다크 테마 지원 추가”), 기술 지원 문의(“푸시 알림이 도착하지 않음”) 또는 관리자의 작업(“월간 충돌률 보고서 준비”)일 수 있습니다. 작업과 티켓의 경계는 모호합니다. Jira에서는 두 개념이 Issue로 통합됩니다. 주요 차이점: 작업에는 항상 담당자가 있지만, 티켓은 트리아지까지 특정 담당자가 없는 요청일 수 있습니다.

Scrum과 Kanban에서 작업은 백로그의 주요 요소입니다. 각 작업은 INVEST 기준(Independent, Negotiable, Valuable, Estimable, Small, Testable)을 충족해야 합니다. 독립적인 작업은 어떤 순서로든 구현할 수 있습니다. 추정 가능 — 팀이 노력을 추정할 수 있습니다. 작음 — 한 스프린트에 들어갑니다. 테스트 가능 — 명확한 승인 기준이 있습니다. 큰 작업(에픽)은 모든 기준이 충족될 때까지 더 작은 작업으로 분해됩니다.

모바일 개발의 작업 유형

Feature — 새로운 애플리케이션 기능. 예: “생체 인증 로그인 화면(Face ID / Touch ID)”. Feature 작업은 항상 사용자 스토리에 연결되며 승인 기준이 있습니다. 추정은 스토리 포인트(1, 2, 3, 5, 8, 13)로 합니다. Bug — 개발 또는 테스트 중 발견된 결함. 버그 티켓의 우선순위는 심각도로 결정됩니다(crash → Critical, UI 버그 → Medium, 오타 → Low). 모바일 개발에서 충돌률이 0.1%를 초과하면 즉시 수정이 필요한 심각한 버그입니다.

Tech Debt / Chore — 사용자에게 눈에 띄는 영향이 없는 기술 작업: 라이브러리 업데이트(Dependency Bump), 리팩토링(ViewPager에서 ViewPager2로 마이그레이션), CI/CD 설정, 테스트 작성. Tech Debt 작업은 종종 과소평가되지만, Stripe 2025에 따르면 모바일 팀 시간의 최대 30%가 유지보수와 기술 부채 상환에 사용됩니다. 기술 부채를 무시하면 버그가 증가하고 새 기능 개발이 느려집니다.

추가 유형: Spike(연구 작업 — 새 기술 탐색, POC 작성), Task(코드 외 작업 — 문서화, 디자인 리뷰), Improvement(기존 기능 개선 — 화면 로드 시간 최적화). Jira에서 이슈 유형은 프로젝트별로 사용자 정의할 수 있습니다. 모바일 팀의 표준 세트: Story, Bug, Task, Improvement, Epic. Epic — 여러 스토리를 통합하는 큰 주제. 예: “이커머스: 장바구니 및 결제”.

작업 수명 주기: 생성부터 완료까지

Open(To Do) — 작업이 생성되었지만 시작되지 않음. 설명, 승인 기준, 우선순위를 포함합니다. 이 상태에서 작업은 스프린트에 들어가기 전에 그루밍(정제 및 추정)을 거쳐야 합니다. In Progress — 개발자가 작업을 시작했습니다. 모바일 개발에서는 커밋과 풀 리퀘스트를 작업에 연결하는 것이 중요합니다. Jira에서는 Smart Commits(APP-123 #comment fix bug), GitHub/GitLab에서는 PR 설명의 키워드(Closes APP-123)를 사용합니다.

In Review — 코드 검토를 위해 전송됨. 자동 검사: CI(Gradle build, lint, unit tests), SonarQube(코드 품질), Danger(changelog, tests). 현재 작업이 Review 상태인 동안 개발자는 다음 작업을 가져올 수 없습니다 — 이는 멀티태스킹을 방지합니다. QA / Testing — 테스터가 실제 기기에서 확인합니다(Android — 다양한 OS 버전 및 화면 크기, iOS — 다양한 iPhone 모델). 버그가 발견되면 작업은 코멘트와 함께 In Progress로 돌아갑니다.

Done(Closed) — 작업 완료: 코드가 main/master에 병합, 테스트 완료, 릴리스 준비 완료. 일부 팀은 Deployed 상태를 추가합니다 — 빌드가 스토어에 출시된 후에만 작업이 사용자에게 도달합니다. 결과 설명과 함께 작업을 종료하는 것이 중요합니다: 어떤 버전, 어떤 PR, 어떤 메트릭이 변경되었는지. Linear(2025)에 따르면, 결과 설명과 함께 작업을 종료하는 팀은 동일한 작업으로 돌아갈 가능성이 40% 낮습니다.

수명 주기에는 Blocked 상태가 포함될 수 있습니다 — 외부 종속성으로 인해 작업을 완료할 수 없음(디자인 대기, 백엔드 응답 대기, 관리자 승인 대기). 차단된 작업에는 이유와 다음 확인 날짜가 포함된 코멘트가 있어야 합니다. 차단된 작업의 주간 검토는 개발 프로세스에서 체계적인 지연을 식별하는 데 도움이 됩니다. 2주 이상 지속되는 블로커는 제품 관리자 수준으로 에스컬레이션해야 합니다.

작업 추적 시스템

Jira — 10명 이상 팀을 위한 업계 표준. Scrum 및 Kanban 보드, 고급 워크플로 사용자 정의, 사용자 정의 필드, 자동화, Bitbucket/GitHub 통합을 지원합니다. 단점: 소규모 팀에는 과도함, 느린 UI, 복잡한 구성. 모바일 프로젝트의 경우 Jira는 Mobile-specific fields 플러그인(Platform, OS version, Device model), TestFlight 및 Firebase Test Lab 통합, 릴리스 빌드 자동화로 사용자 정의됩니다. Jira는 관료적 프로세스가 있는 엔터프라이즈 프로젝트를 위한 선택입니다.

Linear — 제품 팀을 위한 현대적인 트래커. 빠른 UI, 일류 키보드 단축키 지원, 내장 Cycle(스프린트 유사), GitHub 및 Slack 통합. 장점: CMD+K를 통한 빠른 작업 생성, 자동 단계 배포(Triaged → Backlog → Upcoming → Current → Completed), 내장 문서 및 로드맵. Linear는 속도를 중시하는 스타트업과 제품 팀이 선택합니다. 2025년에는 새로운 모바일 프로젝트의 40%가 Linear를 사용합니다.

Trello — 소규모 팀(2~5명)을 위한 간단한 칸반 보드. 체크리스트, 레이블, 마감일이 있는 카드. 단점: 스프린트 없음, 제한된 분석, 확장 어려움. YouGile — 칸반 보드, 채팅, 화상 통화가 있는 Trello의 러시아 유사 제품. Asana — 프로젝트와 타임라인에 초점을 맞춘 트래커. 트래커 선택은 팀 규모, 예산, 선호도에 따라 달라집니다: Jira는 엔터프라이즈, Linear는 제품 팀, Trello/YouGile은 스타트업용. 중요: 도구는 전체 팀에 통일되어야 합니다 — 디자이너, 개발자, QA, 관리자 모두 동일한 시스템에서 작업합니다.

작업 관리 모범 사례

승인 기준 작성 — 승인 기준은 구체적이고 검증 가능해야 합니다. 나쁨: “로그인 화면이 작동함”. 좋음: “사용자가 이메일과 비밀번호를 입력하고 로그인을 클릭합니다. 자격 증명이 올바르면 메인 화면으로 이동합니다. 올바르지 않으면 “유효하지 않은 이메일 또는 비밀번호” 오류를 표시합니다”. 승인 기준(AC)은 개발자, 테스터, 제품 관리자 간의 계약입니다. AC가 없으면 작업은 Definition of Ready(DoR)를 충족하지 않으며 스프린트에 포함되어서는 안 됩니다.

모든 것을 연결하세요. 커밋, PR, 테스트 케이스, 디자인 목업(Figma), Slack 토론 — 모든 것이 작업에 연결되어야 합니다. Jira에서는 코멘트의 링크, Linear에서는 자동 PR 연결을 통해 수행됩니다. 원클릭 규칙: 작업에서 디자인/코드/테스트까지 — 한 번의 클릭 이내. 개발자가 작업을 열면 즉시 Figma 목업, PR 링크, 테스트 케이스를 볼 수 있습니다. 이는 Linear(2025)에 따르면 새 팀원의 온보딩을 30% 가속화합니다.

유령 작업을 만들지 마세요. 설명, AC, 우선순위가 없는 작업은 쓰레기입니다. 데일리 스탠드업에서 아무도 작업이 생성된 이유를 기억하지 못하면 삭제하거나 명확히 해야 합니다. 48시간 규칙: 작업이 48시간 동안 활동 없이 In Progress 상태에 있으면 개발자가 지연 이유에 대한 코멘트를 남겨야 합니다. Jira(2025)에 따르면 3일 이상 유휴 상태인 작업의 60%가 결국 완료되지 않고 종료됩니다.

작업 분해: 에픽, 사용자 스토리, 하위 작업

에픽(Epic) — 여러 스토리를 통합하는 큰 기능 영역. 예: “사용자 온보딩”에는 “환영 화면”, “관심사 선택”, “아바타 업로드”, “알림 설정”이 포함됩니다. 사용자 스토리(User Story) — 사용자 관점의 작업. 형식: “[역할]로서, 나는 [가치]를 위해 [행동]을 원합니다”. 예: “사용자로서, 나는 매번 비밀번호를 입력하지 않기 위해 생체 인증으로 로그인하기를 원합니다”. 사용자 스토리는 제품 관리자 또는 제품 소유자가 작성합니다.

하위 작업(Sub-task) — Story/Task 내 기술 작업의 분해. Story “프로필 화면”의 예: 하위 작업 1: UI 구축(XML/SwiftUI), 하위 작업 2: ViewModel에 연결, 하위 작업 3: 단위 테스트 작성, 하위 작업 4: 스냅샷 테스트, 하위 작업 5: UI 테스트(Espresso/XCUITest). 분해 규칙: 각 하위 작업은 1~2일 내에 완료됩니다. 개발자가 하위 작업을 더 길게 추정하면 더 분해합니다. 하위 작업은 내부 팀 기술이며 제품 백로그에 표시되지 않습니다. 하위 작업 추정의 합이 반드시 상위 Story의 추정과 같지는 않습니다(일부 작업은 커뮤니케이션, 코드 리뷰, 테스트입니다).

분해 피라미드: Epic(분기/반기) → Feature/Story(스프린트) → Task(1~3일) → Sub-task(몇 시간). INVEST 기술은 분해 품질을 확인하는 데 도움이 됩니다. 작업이 Independent(독립적)가 아닌 경우(다른 작업에 의존) — 이는 잘못된 분해를 나타냅니다. 작업이 Small(작음)이 아닌 경우(8 스토리 포인트 초과) — 더 분해해야 합니다. 일반적인 패턴: Epic → 5~15 Stories → 각 Story → 3~8 Sub-tasks. 최종 에픽 추정 = Story 추정의 합계이지만, 첫 번째 스프린트는 일반적으로 추정에 20~30%의 오차 범위가 있습니다.

작업 관리 시 흔한 실수

실수 1: 작업이 너무 큼. 2주 작업은 분해가 필요한 에픽입니다. 큰 작업은 일일 추적에 통합할 수 없으며 몇 주 동안 In Progress에 머뭅니다. 규칙: 최대 작업 크기 — 2~3일 작업. 그보다 큰 것은 분해해야 합니다. 부수 효과: 개발자는 거대한 작업 하나 대신 주당 2~3개의 작업을 종료하여 진행 상황을 느낍니다. 이는 동기 부여와 일정 예측 가능성을 높입니다.

실수 2: 승인 기준 부족. 개발자가 기능을 구현하고 테스터가 확인 — 모두 좋음. 관리자: “편집 버튼은 어디 있나요?” — “작업에 없었습니다”. AC가 없으면 각 측이 작업을 다르게 이해합니다. 결과: 재작업, 갈등, 마감일 놓침. AC는 계약입니다: 작업에 기준이 없으면 스프린트에 준비되지 않은 것입니다. 그루밍에서 가장 먼저 AC의 존재를 확인합니다. AC가 없으면 작업은 제품 관리자에게 반환되어 정제됩니다.

실수 3: 기술 부채를 잊음. 팀이 스프린트마다 Feature 작업만 수행합니다. 6개월 후: 빌드에 15분 소요, Gradle이 3 메이저 버전 뒤쳐짐, 비권장으로 인해 CI에서 테스트 실패. 해결책: Tech Debt에 팀 시간의 20%를 예약합니다(Google SRE 관행 “SLO 기반 오류 예산”). 각 Feature 스프린트마다 최소 하나의 Tech Debt 작업을 만듭니다. 비율: Feature 작업 3개당 — 1개의 Tech Debt 또는 Bug. 이는 기술 부채 축적을 방지하고 개발 속도를 유지합니다.