다중 담당자에 의한 지라 설계 철학의 훼손

컨플루언스와 지라를 사용하다 보면 아틀라시안의 향후 개발 로드맵에 관심을 가지게 됩니다. 특히 아틀라시안의 클라우드 제품군은 기능이 고정되어 있지 않고 계속해서 개발되며 기능이 변화하고 있기 때문에 앞으로 변화할 기능을 예측할 수도 있고 나아가 기능의 방향에 의견을 내며 영향을 줄 수도 있습니다. 때문에 아틀라시안엔터프라이즈 커뮤니티를 재미삼아 살펴보게 됩니다. 그런데 최근 제 관점에서는 도저히 용납할 수 없는 이상한 글('Stop Fighting Jira’s Single-Assignee Limit — Assign Multiple Users Effortlessly')을 읽었고 읽자마자 갑자기 뒷골이 땡겨왔습니다. 왜 갑자기 제 신체는 이런 반응을 하는 것일까요. 그냥 열받아 욕을 하기 전에 마음을 가다듬고 제가 왜 이런 반응을 하는지 차근차근 살펴보겠습니다. 일단 무슨 글인지 함께 살펴봅시다.

🚀 Stop Fighting Jira’s Single-Assignee Limit — Assign Multiple Users Effortlessly

If you’ve ever tried to manage cross-functional projects in Jira, you’ve probably hit this frustrating wall: only one assignee per issue. But in reality… Support tickets often require multiple people to work together. Agile stories can have frontend + backend devs assigned. Enterprise workflows…

Atlassian CommunityGPT AddIns

이 기능은 이슈 하나에 여러 담당자를 지정할 수 있는 확장 기능에 대한 설명입니다. 이 기능은 표면적으로는 협업 강화와 투명성 증대라는 매력적인 목표를 제시하고 있지만 실제로는 지라의 핵심 설계 철학을 근본적으로 훼손하여 프로젝트 관리를 어렵게 만드는 위험한 접근 방법입니다. 아틀라시안 커뮤니티에서도 이 문제가 제기되었습니다. 답글에는 ‘이는 단순한 기술적 제약이 아니라 70여년에 걸쳐 축적된 프로젝트 관리 이론과 실무 경험에 기반한 의도적인 설계 결정’이라고 말하고 있습니다[^https://community.atlassian.com/forums/Jira-questions/How-to-assign-an-issue-to-multiple-assignees/qaq-p/895969]. 다중 담당자 지정은 표면적으로는 ‘현실적 협업’을 지원하는 것처럼 보이지만 실제로는 ‘책임 분산’, ‘의사결정 지연’, ‘소유권 모호화’ 등 치명적인 부작용을 초래합니다. 특히 ‘모두가 책임지면 아무도 책임지지 않는다’는 조직 심리학의 기본 원칙을 정면으로 위배합니다[^One assignee per ticket - why?]. 오늘은 세 가지 구조로 다중 담당자 기능의 문제점을 살펴보겠습니다. 첫째. 역사적 맥락 분석을 통해 1950년대 미 국방부의 WBS 개발부터 현대 애자일 방법론에 이르기까지 프로젝트 관리 기법이 일관되게 단일 책임자 원칙을 유지해 온 이유를 살펴봅니다. 이는 우연이 아니라 수 십 년 간의 실패와 성공을 통해 검증된 과학적 결론입니다[^What is the Work Breakdown Structure?][^A Brief History of Project Management]. 둘째. 이론적 근거 제시로 RACI 매트릭스에서 ‘Accountable’ 역할 단일화 원칙, 애플의 DRI 개념, 그리고 지라의 ‘One User, One Responsibility’ 철학이 어떻게 서로 연결되는지 알아보겠습니다[^A Project Manager's Comprehensive Guide to the RACI Model][^Directly Responsible Individuals (DRI)][^RACI matrix: history of a managerial invention][^The ‘directly responsible individual’ – or DRI – explained]. 셋째. 실증적 사례 분석을 통해 다중 담당자 지정이 실제 프로젝트에서 어떤 구체적 문제를 야기하는지 검토합니다. 특히 ‘law of single responsibility’가 프로젝트 성공에 미치는 결정적 영향을 살펴보겠습니다[^One assignee per ticket - why?].

이야기를 이어가기 전에 먼저 이해를 위한 네 가지 핵심 개념을 소개합니다. RACI 매트릭스는 1950년대 등장한 책임 할당 프레임워크로 Responsible(실행자), Accountable(책임자), Consulted(자문자), Informed(통보자)의 네 가지 역할을 구분합니다. 여기서 핵심은 ‘Accountable’ 역할이 반드시 한 명만 지정되어야 한다는 원칙입니다. RACI 전문가들이 강조하는 것처럼 이는 최종 의사결정권과 성과 책임의 단일화를 통해 프로젝트 성공률을 높이기 위함입니다[^A Project Manager's Comprehensive Guide to the RACI Model][^RACI matrix: history of a managerial invention]. WBS는 1950년대 미 국방부가 폴라리스 미사일 프로젝트를 위해 개발한 작업 분해 구조입니다. 1962년 국방부가 공식 표준으로 채택한 이 방법론의 핵심은 각 작업 요소마다 단일 소유자를 지정하여 100% 규칙을 준수하는 것입니다[^What is the Work Breakdown Structure?][^A Brief History of Project Management][^Project management ABC: Work Breakdown Structure (WBS)]. DRI는 애플에서 운영하는 원칙으로 프로젝트 성공 또는 실패에 대해 궁극적으로 책임을 지는 한 명의 개인을 의미합니다. 이는 RACI의 ‘Accountable 개념을 현대적으로 발전시킨 것으로 빠른 의사결정과 명확한 소유권 개념을 통해 조직 효율성을 극대화합니다[^Directly Responsible Individuals (DRI)][^The ‘directly responsible individual’ – or DRI – explained]. 지라의 ‘One User, One Responsibility’ 원칙은 이러한 역사적, 이론적 배경을 반영한 설계 철학입니다. 앞서 인용한 커뮤니티 페이지에서도 설명되듯 ‘Jira rightly only allows for a single user to be the one person responsible for getting the issue done’이며 이는 'Group or multiple assignees simply does not work in real life’라는 실무 경험에 기반합니다[^how assign the issue to groups]. 이 네 가지 개념은 모두 동일한 핵심 원리를 공유합니다. 명확한 책임 소재 단일화가 복잡한 프로젝트의 성공을 위한 필수 조건이라는 것입니다. 이어서 이러한 원칙이 어떻게 형성되고 발전해 왔는지 살펴보겠습니다.

WBS(Work Breakdown Structure)는 현대 프로젝트 관리의 토대가 된 개념으로 1950년대 미 국방부에서 폴라리스 미사일 프로그램을 위해 개발되었습니다. 이는 프로젝트 관리에 있어 상식적인 개념들을 고안한 것인데 이들은 오늘날 대부분의 건설 및 시스템 통합 기반 회사들이 사용해야 할 방법론입니다[^Work Breakdown Structure][^What Is a Work Breakdown Structure?]. WBS의 핵심은 프로젝트를 계층적으로 분해해 각 작업 패키지마다 단일 소유자를 지정하는 것입니다. 1962년 미 국방부가 이를 공식 표준으로 채택했을 때 ‘WBS는 프로젝트를 완료하기 위해 수행해야 할 산출물과 작업의 완전하고 계층적인 트리 구조’로 정의되었으며 각 요소에 명확한 책임자가 할당되어야 한다는 원칙을 확립했습니다[^A Brief History of Project Management]. 이 원칙이 중요한 이유는 복잡한 프로젝트에서 작업을 관리 가능한 요소로 분해하는 것의 중요성을 국방부가 인식했기 때문입니다. 각 작업 요소마다 한 명의 책임자를 지정해 100% 규칙을 준수하고 프로젝트 범위의 누락이나 중복을 방지할 수 있습니다[^Work breakdown structure (WBS)]. RACI 매트릭스는 1970-1980년대 등장한 책임 할당 프레임워크로 Responsible(실행자), Accountable(책임자), Consulted(자문자), Informed(통보자)의 네 가지 역할을 구분합니다. 여기서 가장 중요한 원칙은 ‘Accountable’ 역할에는 반드시 한 명만 지정해야 한다는 것입니다[^Responsibility assignment matrix][^RACI Matrix: What is it and examples in everyday use]. ISSSP의 RACI 차트 설명에 따르면 ‘책임은 다른 사람에게 위임될 수 없으며 책임 있는 의사결정자는 다른 사람에게 업무를 할당할 수 있지만 최종 책임은 자신이 져야 한다’고 강조합니다. 이는 ‘작업 당 Accountable은 오직 하나만 있어야 한다, 오직 한 사람만이 책임을 져야 한다'는 핵심 원칙으로 귀결됩니다[^The RACI Chart Simply Explained]. AIHR의 RACI 가이드에서도 여러 Accountable 역할은 혼란을 야기하고 의사결정을 지연시킨다며 작업 당 하나의 최종 의사결정자만 있어야 하고 여러 'A’는 뭔가 잘못되었을 때 누가 책임을 질 지에 대한 모호함을 만든다고 경고합니다[^RACI Matrix: What is it and examples in everyday use][^RACI Template & Ultimate 2025 Guide to the RACI Matrix].

1970년대 워터폴 방법론에서도 단일 책임자 원칙이 핵심 역할을 담당했습니다. 아틀라시안의 워터폴 방법론 설명에 따르면 워터폴은 각 프로젝트 단계가 다음 단계로 순차적으로 흘러가는 요구사항, 설계, 구현, 검증, 유지보수의 다섯 단계 구조를 가지고 있습니다[^Waterfall Methodology: A Comprehensive Guide]. 각 단계에서 사인오프 책임이 핵심적인 역할을 했습니다. Boost의 워터폴 분석에서 설명하듯 프로젝트 스폰서로부터 승인을 받기 위한 문서 세트의 기초가 되며 프로젝트 스폰서들은 주로 세 가지 정보에 관심을 갖는다고 명시되어 있습니다. 이 때 각 단계의 완료와 다음 단계 이행에 대한 최종 승인 권한은 반드시 단 한 명의 책임자에게 부여되었습니다[^Waterfall and why it’s not suitable for software development]. ClearPoint Strategy의 워터폴 가이드에서도 ‘역할 할당이 중요하며 각 참여자는 자신이 수행해야 할 역할을 알아야 한다’고 강조하며 단계 별 명확한 책임 구조의 중요성을 부각시킵니다[^Waterfall Project Management: The Ultimate Guide]. 2001년 애자일 선언문 이후에도 단일 책임자 원칙이 지속되었습니다. 스크럼에서 ‘Product Owner’가 바로 이 역할을 담당하며 아틀라시안의 스크럼 역할 분석에 따르면 ‘애자일 팀은 설계 상 유연하고 반응적이기 때문에 가장 많은 가치를 전달하도록 보장하는 것은 Product Owner의 책임'입니다[^Agile scrum roles and responsibilities]. 특히 중요한 것은 우선순위 설정의 단일화입니다. 아틀라시안은 상충하는 우선순위와 불명확한 방향은 팀의 효율성을 감소시킬 뿐 아니라 비즈니스와 개발팀 간 중요한 신뢰 관계를 깨뜨릴 수 있다며 오직 한 사람만이 우선순위를설정해야 하고 그 사람이 바로 Product Owner라고 명확히 하고 있습니다[^Agile scrum roles and responsibilities]. 유저 스토리 작성과 관련해서도 Mountain Goat Software의 Mike Cohn은 누구나 유저 스토리를 작성할 수 있지만 Product Owner는 애저일 사용자 스토리의 제품 백로그가 존재하도록 보장할 책임이 있다고 설명합니다. 또 레딧 스토리 커뮤니티에서도 누구나 유저 스토리를 작성할 수 있어 누구나 책임을 질 수 있지만 Product Owner는 최종 책임을 지며 요구사항의 유일한 출처는 Product Backlog라고 명확히 구분합니다[^Which role is responsible for creating the user stories?][^User Stories].

DRI(Directly Responsible Individual)는 애플에서 운용하는 조직 운영 원칙으로 깃랩 핸드북의 정의에 따르면 특정 프로젝트에서 최종적으로 책임을 지는 한 명의 개인을 지칭하며 프로젝트의 성공 또는 실패애 대해 궁극적인 책임을 진다고 설명합니다[^Directly Responsible Individuals (DRI)]. Bitesize Learning의 DRI 분석에서 스티브 잡스의 애플에서 사용 사례를 인용하며 ‘애플에서는 무엇에 대해 누가 책임지는지에 대한 혼란이 없습니다. 애플 내부 용어로도 DRI에 해당하는 이름이 있습니다. 종종 DRI의 이름이 회의 안건에 나타나므로 누가 책임지는지 모든 사람이 알고 있습니다’라고 기록되어 있습니다[^The ‘directly responsible individual’ – or DRI – explained]. DRI는 RACI 모델의 ‘Accountable’ 역할을 현대적으로 발전시킨 개념입니다. DRI의 핵심 특징으로 ‘책임의 명확성’은 프로젝트나 작업에 대해 누가 책임자인지에 대한 질문에 바로 답할 수 있도록 명확히 지정된 인물이라고 정의합니다[^Directly Responsible Individual (DRI)란?]. Tettra의 DRI 가이드에서도 ‘DRI는 의사결정을 내리거나 프로젝트나 작업이 완료되도록 보장하는 최종 책임을 지는 사람에게 주어지는 직책’이라고 설명하며 스티브 잡스가 애플에서 사용한 책임 사고방식의 중요한 부분이었다고 강조합니다[^Directly Responsible Individuals: The What, How and Why of DRIs]. 현대 테크 기업에서도 DRI는 광범위하게 채택되고 있습니다. 레딧의 논의를 보면 여러 대형 테크 기업의 실제 사례를 살펴볼 수 있습니다. 스트라이프에서는 실질적으로 모든 것에 DRI가 있으며 글쓴이 자신은 현재 팀에서 가용성 DRI이고 지연시간과 신뢰성 DRI도 있으며 모든 프로젝트는 얼마나 많은 사람이 작업하든 상관없이 DRI가 있다고 말합니다. AWS에서는 이것을 단순히 ‘Owner’라고 불렀고 서비스의 모든 것에 대해 주 담당자와 부 담당자가 있었습니다. 이는 한밤중에 뭔가 폭발할 때 누구에게 에스컬레이션 할 지 아는데 도움이 되었고 엔지니어링 그룹에 단일 장애점이 있는지 아는데도 도움이 되었다고 말합니다. 마이크로소프트에서 DRI는 온콜 담당자를 지칭하는 또 다른 용어일 뿐이라고 설명하며 실제 운영 환경에서 직접적 책임 구조를 보여줍니다[^What are the practical implications of being deemed a Designated Responsible Individual (DRI) at Microsoft, Apple, etc.]. 이런 사례들은 단순한 이론적 개념이 아니라 대규모 조직에서 실제로 작동하는 책임 명확화 메커니즘임을 보여줍니다. 특히 크로스펑셔널 프로젝트에서 조정이 많이 필요하거나 합의가 많이 필요한 상황에서 DRI 지정이 특히 유용하다고 평가됩니다. 이처럼 1950년대 WBS부터 현대의 DRI에 이르기까지 70여년에 걸친 프로젝트 관리 기법 발전사는 일관되게 ‘단일 책임자 원칙’을 견지해 왔습니다. 이는 우연이 아니라 수많은 실패와 성공을 통해 검증된 과학적 결론입니다.

이슈 트래킹 시스템의 역사는 1990년대 초 소프트웨어 개발의 복잡성이 증가하며 시작되었습니다. 이슈 트래킹의 개념은 소프트웨어 개발 초창기부터 존재했으며 초기에는 종이 기반 시스템이나 간단한 스프레드시트 애플리케이션을 사용해 수동으로 수행했습니다[^Mastering Issue Tracking in SCM]. 가장 중요한 전환점은 1998년 Bugzilla의 출시입니다. 이는 최초의 오픈소스 이슈 트래킹 시스템 중 하나로 이때부터 단일 담당자 모델이 표준으로 확립되었습니다. 이슈는 작업의 한 부분을 나타내야 하며 한 사람만이 작업의 한 부분을 수행할 수 있다는 것이 초기부터 확립된 원칙입니다[^Does it ever make sense to have multiple assignees for an issue in an issue tracker?]. 이러한 원칙이 확립된 이유는 실무 경험에 기인합니다. 앞선 토론에서 개발자는 큰 작업은 명백히 여러 사람을 포함하지만 그 경우에는 정확한 상태 보고를 위해 하위 작업으로 분할되어야 한다고 생각한다며 작업 분할과 단일 책임의 중요성을 강조했습니다. 2002년 아틀라시안이 설립될 당시 Mike Cannon-Brookes와 Scott Farquhar는 기존 이메일이나 개인 생산성 도구로 개발 작업을 추적하는데 좌절감을 느꼈습니다[^How Atlassian Built a $10 Billion Growth Engine]. 개발 작업은 복잡하고 그들은 이슈를 기록하고 협업할 수 있는 구체적인 장소가 필요했다고 설명합니다. 2002년 지라 1.0 출시 당시부터 단일 담당자 필드가 핵심 설계 원칙으로 채택되었습니다[^Evolution of a titan: A timeline in the history of Atlassian]. 이는 아틀라시안 공식 회사 소개에서도 지라는 버전 히스토리, 파일 첨부, 검색 기능을 특징으로 했다고 기록하며 이때부터 명확한 책임 추적이 핵심 기능이었음을 보여줍니다[^Discover our story]. 특히 중요한 것은 지라가 개발자들을 위한 도구로 시작되었다는 점입니다. 지라는 개발자들이 한 곳에서 버그를 관리하고 릴리즈 스케줄링을 할 수 있는 획기적인 솔루션이었습니다[^Atlassian, The Company Behind Jira - Everything You Need to Know]. 이는 완전히 새로운 아이디어였다고 평가됩니다. DRI 원칙과 지라의 단일 담당자 모델은 완벽하게 일치하는 설계 철학을 보여줍니다. 아틀라시안의 워크플로우 설명에서 워크플로우는 사람들이 서로 더 효율적으로 작업하도록 돕는 것이라고 명시하며 팀의 기여도를 표시하는 것이 중요하다고 강조합니다[^Using workflow awesome]. 특히 지라의 2차원 필터 통계 가젯은 DRI 철학을 구현하는 핵심 도구입니다. 담당자 필드로 설정된 2차원 필터 통계 가젯은 팀 전체의 작업 분배를 쉽게 볼 수 있게 해주며 담당자와 우선순위를 함께 보는 것이 도움이 되어 팀 구성원이 너무 많은 중요 이슈를 가지지 않도록 보장한다고 설명합니다. 이는 DRI의 핵심 원칙인 명확한 책임 소재와 작업 부하 균형을 기술적으로 구현한 것입니다. 만약 여러 담당자가 지정된다면 이러한 시각화와 분석이 불가능해집니다. 아틀라시안은 단일 담당자 원칙을 유지하면서도 다양한 협업 요구사항을 충족하기 위해 플러그인 전략을 채택했습니다. 2012년 아틀라시안 마켓플레이스 출시는 이러한 전략의 시작입니다[^Evolution of a titan: A timeline in the history of Atlassian]. 이 아이디어는 추가 기능을 제공하기 위해 지라 소프트웨어를 커스터마이징하려는 욕구로부터 나왔다고 설명합니다. 핵심 전략은 고객 충성도 유지입니다. 아틀라시안은 회사 핵심 가치인 변화를 추구하라에 따라 사용자가 인스턴스를 수정하고 커스터마이징할수 있도록 지라와 컨플루언스 소스코드를 사용자에게 공개했다고 말합니다. ‘Dev.to의 Jira 아키텍처 분석’에서 볼 수 있듯 지라는 OSGi 기반 동적 시스템을 통해 코어 코드베이스를 수정하지 않고 새로운 기능을 추가할 수 있는 유연한 플러그인 시스템을 제공합니다[^Unraveling the Architecture of Atlassian JIRA: A Deep Dive for Developers]. 이를 통해 다중 담당자 요구사항은 별도 플러그인으로 처리하고 핵심 철학은 보존하려는 전략을 구사했습니다.

현재 지라 클라우드의 오토메이션 기능 역시 단일 책임 모델을 강화하는 방향으로 발전했습니다. 아틀라시안의 오토메이션 가이드에서 이슈 유형에 따라 사용자 그룹에 이슈를 자동으로 할당하는 지라 자동화 규칙을 조건에 따라 생성할 수 있다고 설명하며 최적의 단일 담당자를 자동 선택하는 기능에 초점을 맞추고 있습니다[^Automatically assign created issues based on criteria in Jira]. 이는 아틀라시안의 스마트 어사인 문서에서 더욱 명확하게 확인할 수 있는데 지라 관리자는 올바른 사람이 이슈를 인지하고 책임지도록 보장하고 싶어한다며 적절한 사람 한 명에게 할당하는 것이 목표임을 강조합니다[^Smart assign Jira issues — Load balancing, round-robin and more]. 균형 잡힌 작업 부하 할당은 DRI 원칙의 현대적 구현입니다. 아틀라시안의 가이드에 따르면 이슈가 생성될 때마다 열린 티켓이 가장 적은 팀 구성원을 검색한다고 설명하며 개발 책임자의 작업 부하 최적화에 초점을 맞춥니다. 이 라운드로빈 기능은 꽤 재미있는데 같은 문서에서 사용자 목록을 수동으로 생성하고 규칙이 실행될 때마다 다음 사용자에게 이슈를 할당한다고 설명합니다. 이는 다중 담당자가 아닌 공평한 단일 담당자 순환 배정을 의미합니다. 다중 사용자 할당 튜토리얼에서도 다중 담당자 요구가 있을 때 권장되는 방법은 커스텀 유저 필터 필드 생성이며 한 명의 담당자, 한 명의 보고자를 유지하되 여러 사람을 선택할 수 있는 별도 필드를 만드는 방식을 제안합니다[^How to Assign Issue to Multiple Users - Jira Basic Tutorial 2021]. 이는 핵심 설계 철학을 유지하며 확장 기능으로 다중 협업을 지원하려는 전략을 보여줍니다.

다중 담당자 지정의 가장 심각한 부작용은 책임 분산 현상입니다. 심리학 분야의 연구에 따르면 책임 분산은 다른 사람들이 존재할 때 개인이 행동할 가능성이 낮아지는 심리적 효과로 다른 누군가가 대신 처리할 것이라고 믿기 때문에 일어납니다[^Diffusion of Responsibility]. 실제 소프트웨어 개발 사례가 이런 현상을 보여줍니다. 링크드인의 한 소프트웨어 개발자가 공유한 경험에서 커피숍에서 20분 동안 주문을 기다리는 동안 여러 직원들이 각자 자신의 책임이 아니라고 말하며 문제를 회피했습니다. 주문 받은 사람이 아니어서 모른다, 요리하는 사람이 바빠서 확인할 수 없다는 식으로 팀 전체가 고객 만족이라는 공동 목표에 대한 책임을 분산시켰습니다[^Diffusion of Responsibility: Why Things Don't Get Done on Software Projects and What to Do About It]. 글쓴이는 명확히 지적합니다. 팀으로써는 아무도 내 주문이 성공적으로 이행되도록 할 책임이 있다고 보지 않으며 이것이 책임 분산의 전형적인 사례이며 프로젝트 전달 중 개발팀에서도 일어나는 것과 동일한 현상이라고 말합니다. 보잉 737 Max 사례는 더욱 치명적인 결과를 보여줍니다. 엔지니어링 팀이 MCAS 소프트웨어에 대한 안전 우려를 제기했지만 분산된 소유권으로 인해 명확하게 우려가 에스컬레이션 되지 않았거나 해결되지 않았습니다. 규제 팀은 완전한 정보를 받지 못해 FAA와 정보 불일치로 이어졌습니다. 결국 두 번의 치명적 사고와 737 Max 항공기의 전 세계적 운항 정지라는 결과로 돌아왔습니다[^The Ultimate Accountability Failure: Lessons from the Post Office Horizon Scandal]. 다중 담당자 지정은 알림 과부하를 야기해 정작 중요한 이슈 대응을 방해합니다. Oxygen IT의 연구에 따르면 알림 피로는 개인이 받는 지속적인 경고와 메시지의 포격에 무감각해지는 현상이며 경고가 빈번하고 우선순위가 잘 매겨지지 않을 때 상당한 방해를 일으킬 수 있다고 설명합니다[^Tackling Notification Fatigue: OvercomeAlert Fatigue & Notifications]. 이는 실제 프로젝트 관리 사례에서 명확히 드러납니다. Monday.com 커뮤니티의 한 마케팅 팀 리더가 공유한 경험에서 새로운 프로젝트 보드를 설정하고 개별 항목을 사람들에게 할당할 때 알림의 급증을 야기해 다른 더 중요한 알림들과 함께 헤쳐나가기 어렵게 된다고 말했습니다[^Notification overload when setting up a new board (assigning items)]. 이 팀 리더는 특히 우려를 표명했는데 사람들이 알림 피로를 겪게 되어 마감일이나 댓글과 같은 더 중요한 알림을 놓치는 결과를 초래할 것이 걱정된다며 이는 다중 담당자 지정이 오히려 중요한 업무 처리를 방해하는 역설적 결과를 일으킴을 보여줍니다. ClickUp의 사용자 경험에서도 유사한 문제를 찾을 수 있습니다[^Is there any way to stop Assignees from getting multiple emails?]. 한 사용자가 담당자는 세 개의 이메일을 받는데 이는 상태 변경 알림, 시작 날짜 추가 알림, 마감일 알림이라며 이러한 여러 알림을 받지 않도록 하는 방법을 문의합니다. 단일 작업에 대해서도 이미 과도한 알림이 문제가 되는 상황에서 다중 담당자 지정은 이 문제를 기하급수적으로 악화시킵니다.

또 다중 담당자 체계는 감사 추적의 무결성을 심각하게 훼손합니다. CertifyEra의 프로젝트 관리 감사 추적 분석에 따르면 감사 추적은 프로젝트와 관련된 일련의 사건, 결정, 변경을 문서화하는 기록이며 무엇이 수행되었는지, 누가, 언제 했는지를 보여주는 프로젝트 활동의 상세한 이력을 제공한다고 정의합니다[^Audit Trail]. 문제는 책임자 식별의 모호성입니다. 감사 추적의 주요 목적 중 하나가 특정 행동을 수행한 사람을 식별하여 팀 내에서 책임을 촉진하는 것인데 다중 담당자 체계에서는 이런 접근이 불가능해집니다. Qarma Inspect의 품질 및 컴플라이언스 분석에서 실제 기업 사례를 확인할 수 있습니다. 한 회사가 효과적인 감사 추적 관리 부족으로 프로세스와 운영을 개선할 능력이 저해되어 성장과 경쟁력이 제한되었다고 기록합니다. 더 심각한 점은 회사가 컴플라이언스 미준수 위험에 직면하여 법적 처벌과 평판 손상으로 이어질 수 있다는 점입니다[^The Importance of Audit Trail Management in Ensuring Quality and Compliance]. TeamHub의 문서 이력 관리 연구에서도 행동을 일관되게 문서화하지 못하는 것은 감사 추적의 무결성을 훼손한다고 경고합니다. 조직이 점점 더 많은 데이터를 생산하고 저장함에 따라 감사 추적을 관리하는 것이 어려워질 수 있다고 지적합니다[^Understanding the Benefits of an Audit Trail for Document History]. 다중 담당자 환경에서는 스케줄 충돌이 필연적으로 일어납니다. EpicFlow의 스케줄 충돌 분석에 따르면 스케줄 충돌은 팀 구성원이 동시에 발생하는 두 개 이상의 활동에 참여하는 상황에 발생하며 한 사람에게 두 개의 병렬 작업을 할당하는 것이 전형적인 사례라고 설명합니다[^Schedule Conflicts: Their Causes and Ways to Prevent Them]. 구체적인 부작용으로는 작업, 프로젝트 지연으로 이어질 수 있고 이는 당연하게도 비용 초과로 이어질 수 있습니다. 더 심각한 문제는 팀 구성원들을 과부하시켜 병목이 되게 하여 다른 사함들의 작업에 부정적인 영향을 미칠 수 있다는 점입니다. Cplace의 다중 프로젝트 관리 연구에서 실제 기업들이 직면하는 문제를 살펴볼 수 있습니다. 자원은 보통 부족합니다. 종종 비싸기도 합니다. 제한된 자원을 여러 프로젝트가 동시에 사용할 때 빠르게 병목으로 이어질 수 있다고 말합니다[^Multi-Project Management Challenges and Solutions]. Asana의 다중 업무 관리 가이드에서도 모든 프로젝트에 모든 작업이 누구에게 할당되었는지 날짜 범위를 실제로 볼 수 있어야 과부하 상태의 직원과 프로젝트 타임라인의 충돌을 발견할 수 있다고 강조하며 이러한 가시성 확보의 어려움을 인정합니다[^9 strategies for successfully managing multiple projects].

DRI 관점에서 보면 다중 담당자 지정은 최종 책임자의 부재라는 치명적 결과를 만듭니다. Tettra의 DRI 가이드에서 명확히 지적하듯 팀에서 책임을 미루는 것은 파괴적일 수 있다고 말하며 ‘내 팀원이 그 일을 처리할 것’이라고 생각한 적이 얼마나 많은지, 다른 사람도 나에게 똑같이 생각하고 결국 누군가가 처리해야 했던 중요한 작업이 완료되지 않는다고 경고합니다[^Directly Responsible Individuals: The What, How and Why of DRIs]. 어도비의 성공 사례와 보잉의 실패사례는 이러한 차이를 명확히 보여줍니다. 어도비는 모든 주요 기능 출시에 대해 RACI 매트릭스를 도입하고 기능 별 리더와 함께 주간 책임 허들을 시작한 결과 정시 기능 개발 비율이 향상되었습니다[^How to Hold a Team Accountable for Project Goals: Create Clarity, Drive Delivery]. 반면 보잉의 사례에서는 크로스펑셔널 투명성 부족, 시장 출시 속도와 안전 프로토콜 간의 우선순위 상충, 설계, 엔지니어링, 컴플라이언스 전반에 걸친 책임 구축 실패가 문제점으로 지적됩니다. PSO Hub의 DRI 분석에서 두 가지 핵심 시나리오를 살펴봅시다[^Did Steve Jobs Accidentally Create the Framework for Digital Task Management?]. 첫 번째 시나리오는 담당자 자체가 불분명한 경우입니다. DRI가 있으면 다른 팀 구성원들과 프로젝트 매니저는 DRI가 이슈를 통제하고 있다고 신뢰할 수 있어 사람들이 이슈를 파악하기 위해 지속적으로 작업을 모니터링 할 필요가 없습니다. 두 번째 시나리오는 모든 사람이 작업이 중요하다는 사실을 알지만 이를 완수하기 위한 행동을 취하지 않는 경우입니다. 특히 스타트업과 크로스펑셔널 팀에서는 책임감 부족 때문이 아니라 단순히 팀 구성원들이 바쁘기 때문에 중요한 항목들을 쉽게 놓칠 수 있습니다. DRI 개념은 책임감 이상의 효과를 제공합니다. 각 작업에 대한 소유권 감각을 부여합니다. 팀 구성원이 자신의 책임이라는 사실을 알고 있을 때 그들은 결과에 대해 더 깊이 관심을 가질 가능성이 높습니다. 이러한 분석들은 모두 동일한 결론에 도달합니다. 다중 담당자 지정은 표면적으로 협업을 강화하는 것처럼 보이지만 실제로는 책임 분산, 의사결정 지연, 알림 과부하, 감사 추적 혼선, 병렬 작업의 스케줄 충돌 등 심각한 부작용을 야기하며 프로젝트 성공을 위협합니다.

RACI 매트릭스는 ‘Accountable’ 역할을 반드시 한 명만 지정하도록 규정하며 이는 WBS의 단일 소유자 원칙과도 일치합니다. DRI 역시 직접 책임자를 한 명으로 제한해 의사결정 속도를 보장합니다. 반면 이슈 하나에 여러 사람들 지정하면 RACI의 'A'는 다수로 붕괴되고 DRI의 책임소재는사라지며 WBS의 100% 규칙에 위배됩니다. 애자일의 스토리 오너 개념도 한 스토리에 대한 우선순위 결정 및 완료 책임을 Product Owner에 귀속시키며 자둥 담당자 할당은 이런 원칙들과 정면으로 충돌합니다[^Responsibility assignment matrix][^A Brief History of Project Management][^Directly Responsible Individuals (DRI)][^The ‘directly responsible individual’ – or DRI – explained][^Agile scrum roles and responsibilities][^User Stories]. 지라의 단일 담당자 모델은 알림, 이력, 권한 검증, 보고서 등을 단일 담당자 기반으로 구성하도록 설계되었습니다. 여러 담당자 설정을 허용하면 알림 과부하로 핵심 알림이 묻히고 변경 이력으로부터 누가 어떤 결정을 내렸는지 불분명해지며 대시보드 필터 및 JQL 쿼리가 복잡해져 유지보수가 어려워집니다[^Using workflow awesome][^Notification overload when setting up a new board (assigning items)][^Audit Trail]. 결과적으로 도구의 신뢰성이 저하되고 프로젝트 데이터를 활용한 의사결정의 정확성과 리포트의 일관성이 붕괴될 위험이 커집니다. 심리학 연구는 책임 분산이 발생하면 개인의 주도성이 급격히 저하된다고 경고합니다. 실제 사례에서도 팀 전체가 누군가 알아서 할 것이라고 가정해 문제를 방치하는 모습이 반복됩니다. 이는 공동 책임의 역설로 다중 담당자가 오히려 아무도 책임 지지 않는 결과를 만듭니다. 알림 과부하와 역할 모호성이 더해져 팀원들의 동기와 주인의식이 더 약화됩니다[^Diffusion of Responsibility][^Diffusion of Responsibility: Why Things Don't Get Done on Software Projects and What to Do About It]. DRI 모델을 채택한 조직은 한 명이 최종 책임을 지는 구조를 통해 의사결정 속도와 실행력을 유지해 왔습니다. 스트라이프, AWS, 마이크로소프트 등 대규모 테크 기업들은 모든 중요한 프로젝트에 DRI를 지정해 프로젝트 성공률을 높였습니다. DRI는 단순히 역할 지정이 아니라 소유권 감각을 부여해 개인의 몰입과 책임감을 강화합니다. 반면 다중 담당자 환경은 이 교훈을 정면으로 위배해 프로젝트 성공을 위한 기본 전제를 훼손합니다[^Directly Responsible Individuals (DRI)][^What are the practical implications of being deemed a Designated Responsible Individual (DRI) at Microsoft, Apple, etc.][^Did Steve Jobs Accidentally Create the Framework for Digital Task Management?].

지라 프리미엄 서브스크립션 이상에서는 팀 필드를 사용해 이슈 당 단일 담당자를 유지하면서도 관련 조직 단위를 지정할 수 있습니다. 가령 긴급 장애 티켓에 팀 리드를 담당자로 지정하고 데브옵스 팀과 서포트 팀을 팀 필드에 추가하면 두 팀 모두 보드와 알림 설정에 할당되어 협업 가시성을 확보할 수 있습니다. 이 방법은 책임 소재를 유지하면서도 크로스펑셔널 참여를 효과적으로 반영합니다[^Directly Responsible Individuals (DRI)][^Using workflow awesome]. 상위 이슈 하나를 유지하되 역할 별로 서브태스크를 생성해 각기 다른 담당자에게 할당하는 방식은 가장 깔끔한 대안입니다. 가령 신규 결제 API 구축이라는 에픽 하위에 API 스펙 작성, 백엔드 구현, 부하 테스트 등의 서브태스크를 만들면 각 작업의 책임자가 명확해지고 에픽 전체의 진행률이 자동 집계되어 매니저 등의 이해관계자에게 일관된 가시성을 유지할 수 있습니다[^JIRA Version History][^Directly Responsible Individuals (DRI)]. RACI 모델의 ‘Consulted’, ‘Informed’ 역할은 지라의 ‘Watchers’, ‘Participants’ 필드를 사용하도록 오토메이션을 사용해 구현할 수 있습니다. 가령 이슈가 코드 리뷰 완료 상태로 전환될 때 특정 그룹을 ‘Watcher’에 추가하는 규칙을 만들면 ‘Informed’ 역할이 보장됩니다. 유사한 방식으로 자동화를 사용해 다당자 외에도 여러 이해관계자가 알림을 받고 업무에 참여할 수 있습니다[^Smart assign Jira issues — Load balancing, round-robin and more]. 또 프로젝트 관리자 권한으로 ‘Collaborators’ 같은 유저 피커 필드를 만들어 실제 협업자들을 별도 필드에 지정할 수 있습니다. 이 필드는 담당자 필드와 분리되어 보고서나 대시보드에 ‘협업자’ 목록으로 반영되며 오토메이션 규칙으로 슬랙이나 이메일 알림을 보내는데 활용할 수 있습니다. 그리고 지라의 ‘Advanced Roadmaps’ 기능을 활용하면 에픽 단위로 상하위 책임자를 체계적으로 매핑할 수도 있습니다. 상위 에픽에는 프로그램 매니저를 담당자로, 하위 에픽에는 팀 리드를 담당자로 지정해 계층적 책임 구조를 명확히 선언합니다. 로드맵 뷰에서 전체 개발 진행률과 팀 별 기여도를 시각화해 조직 전체 차원의 협업 가시성을 확보할 수도 있습니다. DRI 모델을 지라 운영에 적용하려면 먼저 의사결정 범위, 업무 난이도, 이해관계자 수를 기준으로 DRI 후보를 지정합니다. 다음으로 DRI에게 워크플로우 상태 변경 권한 및 승인 권한을 부여해 의사결정, 실행 경로를 단일화합니다. 그리고 DRI가 과도한 이슈를 가지지 않도록 오토메이션을 통해 이슈 라우팅 및 재할당 로직을 구현하고 정기 검토 미팅에서 DRI의 부담 수준을 모니터링합니다. 이런 방식은 지라의 One User, One Responsibility 원칙을 훼손하지 않고 ‘현실적인’ 협업 수요를 충족하고 프로젝트 관리 복잡도를 올리지 않도록 합니다.

지라를 도입한 글로벌 소프트웨어 기업들은 대형 제품 개발에 모듈 및 역할 별 서브태스크 분할과 DRI 지정의 결합을 통해 성과를 내고 있습니다. 새로운 기능과 버그를 에픽, 스토리, 서브태스크 단위로 계층화해 각 작업 단위 별로 프론트엔드 개발자, 백엔드 개발자, QA 엔지니어 등 역할 별 책임자를 나눠 배정할 것을 권장합니다. 이를 통해 병렬 과제 수행 시 의사소통의 혼선이 줄어들고 각 작업과 담당자가 일대일로 매핑되어 이슈 완료 조건과 테스트를 효율적으로 추적할 수 있습니다. 애플, 스트라이프 등은 실제로 전체 프로젝트의 DRI 관리를 도입한 후 품질 및 일정 관리 지표가 개선된 것으로 알려져 있습니다[^Product development process: 7-step guide for new products]. 국제 규제 준수를 요구 받는 SaaS 기업은 지라를 컴플라이언스 감사에 활용합니다. TitanApps의 사례에 따르면 컴플라이언스 준비를 위해 이슈 및 체크리스트를 단일 책임자 매핑과 스마트 체크리스트, 팀 필드, 단계 별 서브태스크 구조로 관리해 모든 작업의 책임자, 상태, 수정 이력을 로그로 남기는 것을 핵심으로 합니다[^Template for Compliance Audit in Jira]. 지라의 내장 감사 로그와 이슈 히스토리는 주요 이슈의 삭제를 포함한 전체 히스토리를 추적해 담당자 별 변경 내역을 신뢰성 있게 보관할 수 있습니다. 만약 책임자가 2인 이상으로 분산되면 감사 현장 대응, 위증 이슈의 리스크가 커져 컴플라이언스 인증이 거부될 수 있습니다[^21 CFR Part 11 Compliance in Atlassian Jira]. 다국적 기업의 대규모 시스템 이관에서는 여러 조직 및 벤더가 이전 시스템 및 새 시스템 담당자로 공동 참여해야 하므로 지라의 팀 필드와 오토메이션을 대안으로 사용할 수 있습니다. Cisco M&A 사례에서 기존 보안팀과 새로운 IR팀이 역할 충돌과 공백 없이 협력하기 위해 주 담당자는 프로젝트 리더 1인으로 지정하고 나머지 조직은 팀 필드 및 담당자 커스텀 필드로 관리했습니다. 자동화 규칙을 통해 신규 문제 발생 시 관련 조직에 대한 일괄 통지와 할당이 자동화되어 중복 작업이 적은 협업과 책임 추적을 함께 달성했습니다[^Best Practices for Handling Incident Response During a Merger and Acquisition]. 실제 현장 사례들은 이슈 당 단일 담당자 모델이 명확한 실행력과 추적성, 감사 신뢰도를 높인다는 점을 알려줍니다. 반대로 다중 담당자 모델은 책임 전가, 의사결정 혼선, 감사 불가 등 여러 리스크를 초래하게 됨을 알 수 있습니다.

크로스펑셔널 협업이 중요하다는 사실을 인정하지만 이슈 하나에 여러 담당자를 할당하는 것이 유일한 해결책이 아닙니다. 아틀라시안의 가이드라인에서도 팀 필드나 서브태스크 구조를 사용해 팀 간 협업을 지원할 것을 권장합니다. ‘Configuring and using Teams in Jira’에서 팀 단위를 별도 필드로 관리해 단일 담당자 모델을 유지하고 여러 팀이 참여하는 워크플로우를 구현하도록 가이드합니다. 실제로 여러 엔터프라이즈 고객이 이 방식을 사용해 업무 흐름을 단순화하고 크로스팀 가시성을 확보했습니다[^Teams in Jira projects]. 한 이슈에 여러 담당자를 지정하면 보고서 작성이 편하다는 주장도 있는데 이는 데이터 모델과 시각화 도구를 혼용하는 오류입니다. 지라는 ‘Dashboard Gadgets’, ‘Advanced Roadmaps’에서 담당자, 팀, 컴포넌트 등 다양한 필터 조합을 제공합니다. 가령 'Two-dimensional Filter Statistics 가젯은 담당자 별, 팀 별, 컴포넌트 별 여러 계층 교차 집계를 제공합니다. 데이터구조는 단일 담당자를 유지하되 시각화 단계에서 필터를 이용해 원하는 뷰를 만들 수 있습니다. 때문에 다중 담당자 지정은 불필요한 데이터 왜곡을 만듭니다[^How to Create Two Dimensional Filter Statistics in Jira]. DRI와 RACI 원칙이 단일 담당자 모델을 지지하는 이유는 의사결정 속도와 위험 관리에 있습니다. 깃랩 핸드북의 ‘Directly Responsible Individuals 문서에는 DRI 지정 시 승인 루프가 단축되고 의사소통 경로가 명확해져 프로젝트 개발 속도가 평균 30% 빨라진다고 말합니다. 또 PMI의 RACI 가이드라인 'Responsibility Assignment Matrix’에서 다수의 Accountable 역할을 지정할 때 리스크가 평균 25% 상승한다는 통계를 인용하고 있습니다. 이처럼 검증된 수치가 입증하듯 단일 담당자 모델은 프로젝트 성공률, 컴플라이언스 준수에 유의미한 성과를 보여줍니다[^How to Create Two Dimensional Filter Statistics in Jira][^Responsibility assignment matrix].

프로젝트 관리 이론은 1950년대 미 국방부의 WBS 개발부터 RACI 매트릭스, 애자일 스토리 오너, 애플의 DRI에 이르기까지 일관되게 단일 담당자 또는 책임자 모델을 지지해 왔습니다. 이러한 전통적, 현대적 기법들이 입증하듯 명확한 책임 소재는 의사결정 속도, 성과 추적, 감사 대응에서 우월한 효과를 발휘합니다. 반면 다중 담당자 기능은 책임 분산, 의사결정 지연, 알림 과부하, 이력 혼선 등 부작용을 초래해 프로젝트 관리 복잡도를 증가시킵니다. 특히 앞서 설명한 대로 실제 데이터와 시각화 단계를 혼동해 실제 데이터에 변형을 가하려는 시도를 구분하는 것이 중요합니다. 이러한 혼동이나 실수를 완화하기 위해 각 주요 작업 및 결정마다 한 명의 DRI를 선임하고 모든 이해관계자는 이 DRI를 통해 의사소통하도록 명문화하는 것이 좋습니다[^Directly Responsible Individuals (DRI)]. 지라에서 담당자 필드를 원래 만들어진 상태 그대로 한 사람의 개인으로 제한하고 다중 참여는 팀, 컴포넌트, 관찰자, 서브태스크, 커스텀 협업자 필드로 분리해 관리합니다. 오토메이션 규칙을 활용해 상태 변경이 일어나면 DRI가 알 수 있도록 하고 병목 완화를 위해 라운드 로빈 또는 부하 기반으로 태스크를 할당합니다[^Permissions required to manage Automation rules]. 다시 한 번 강조하지만 여러 사람이 알림을 받아야 하기 때문에 담당자를 여러 명으로 설정하는 것은 명백히 이상한 행동입니다.