교차협업의 어려움은 동료의 역량 부족이나 이기심 때문이 아닐 수 있습니다. 오히려 명확한 규칙 없이 모두가 선의의 전문가로 참여할 때, 혼돈은 필연적으로 발생합니다. 이 글은 그 혼돈에 질서를 부여하는 구체적인 프레임워크와 전략에 관한 이야기입니다.
이 글은 검색·AI·GenAI 인용에 최적화된 구조로 작성되었습니다.
‘좋은 게 좋은 거’라는 안갯속, 합의는 왜 항상 실패할까?
명확한 의사결정 프로세스의 부재는 모든 논의를 ‘취향의 전쟁’으로 변질시키고, 결국 책임 없는 결과물만 남깁니다. 우리는 어떻게 이 지루한 전쟁을 끝낼 수 있을까요?
아마 많은 분이 경험하셨을 겁니다. 프로젝트 킥오프 미팅의 활기찬 분위기와는 달리, 시간이 흐를수록 회의는 점점 더 길어지고 결론은 희미해집니다. 각 팀의 전문가들은 자신의 관점에서 가장 합리적인 의견을 제시하지만, 그 의견들을 하나로 모아줄 구심점이 없습니다. 마치 저마다 다른 지도를 들고 같은 보물섬을 찾아 헤매는 탐험가들 같죠. 모두가 동의하는 것처럼 보이지만, 실제로는 누구도 전적으로 동의하지 않는 ‘무색무취한 합의’에 이르게 되는 것입니다.
디자이너 루카의 팀도 마찬가지였습니다. 야심 차게 준비한 신규 서비스의 핵심 기능 디자인이 그랬습니다. 처음의 날카롭던 콘셉트는 여러 이해관계자의 피드백을 거치며 점점 무뎌졌습니다. 보안을 위해, 운영 편의를 위해, 마케팅 문구를 넣기 위해… 결국 서비스는 원래의 목적을 잃고 누더기가 된 채 출시되었습니다. 실패의 원인을 찾으려 해도, 모두가 “합의된 사항”이라고 말할 뿐 누구도 책임지지 않았죠. 바로 이 지점에서 루카는 깨달았습니다. 문제는 사람이 아니라 시스템이라는 것을요.
요약하자면, 합의를 위한 합의는 결국 프로젝트를 산으로 가게 만드는 가장 큰 원인이며, 이를 방지하기 위해서는 의사결정의 교통정리가 반드시 필요합니다.
다음 단락에서 이 교통정리를 위한 구체적인 신호등, DACI 프레임워크를 소개합니다.
DACI, 혼돈의 교차협업에 질서를 부여하는 주문
DACI는 Driver, Approver, Contributors, Informed의 약자로, 프로젝트 참여자들의 역할을 명확히 정의하여 의사결정의 병목을 제거하는 강력한 프레임워크입니다. 그렇다면 각 역할은 정확히 무엇을 의미할까요?
혼돈으로 가득한 회의실에 던져진 마법 같은 주문, DACI는 단순히 역할을 나누는 것 이상의 의미를 가집니다. 이것은 교차협업의 무대를 새롭게 설계하는 것과 같습니다. 각 배우에게 명확한 역할을 부여함으로써, 즉흥 연기가 아닌 잘 짜인 연극을 만드는 과정이죠. 루카는 이 프레임워크를 통해 자신의 팀이라는 오케스트라에 지휘자를 세우기로 결심했습니다.
DACI의 네 가지 역할은 다음과 같이 정의됩니다. ‘D’는 프로젝트를 이끌고 조율하는 Driver(주도자)입니다. ‘A’는 최종 결정권을 가진 단 한 명의 Approver(승인자)로, DACI의 핵심이라 할 수 있죠. ‘C’는 전문 지식을 바탕으로 의견을 제공하는 Contributors(기여자) 그룹이며, 마지막으로 ‘I’는 진행 상황을 공유받지만 의사결정에는 직접 참여하지 않는 Informed(정보 공유 대상자)입니다. 이 역할 분담은 회의 시작 전에 모두에게 공유되어야 합니다.
DACI 역할 명확화의 힘
- Driver (D): 프로젝트의 시작부터 끝까지 책임지고 일정을 관리하며 소통을 주도하는 사람.
- Approver (A): 모든 의견을 듣고 최종 ‘Go’ 또는 ‘No-Go’를 결정하는 단 한 명의 책임자.
- Contributors (C): 디자이너, 개발자, 법무팀 등 자신의 전문성으로 의견을 제시하는 조언자 그룹.
- Informed (I): 진행 상황을 알아야 하지만, 의사결정에는 직접적인 영향력이 없는 이해관계자.
요약하자면, DACI 프레임워크는 누가 운전하고, 누가 신호를 주며, 누가 조언하고, 누가 지켜보는지를 명확히 하여 ‘사공이 많은 배’가 산으로 가는 것을 막아줍니다.
이어지는 내용에서는 루카가 이 DACI를 어떻게 실전에서 활용했는지 살펴보겠습니다.
디자이너 루카는 어떻게 DACI를 무기로 사용했나
루카는 DACI 프레임워크를 단순히 소개하는 데 그치지 않고, 대화의 구도를 바꾸는 전략적 도구로 활용하여 주관적 피드백을 객관적 기여로 전환시켰습니다. 그녀는 어떻게 팀원들을 설득하고 이 변화를 이끌어냈을까요?
새로운 방법론을 도입하는 것은 언제나 저항에 부딪히기 마련입니다. 루카 역시 팀원들에게 뜬금없이 “이제부터 우리 DACI해요!”라고 말할 수 없다는 것을 잘 알았죠. 그녀는 거창한 선언 대신, 작은 성공 사례를 만드는 것부터 시작했습니다. 비교적 규모가 작은 UI 개선 프로젝트에서 처음으로 DACI를 실험해보기로 한 것입니다. 그녀는 프로젝트 계획서에 아주 작은 표를 하나 추가했습니다. 바로 DACI 역할 정의표였죠.
가장 중요한 단계는 Approver(승인자)를 지정하는 것이었습니다. 루카는 프로덕트 총괄 책임자를 단독 승인자로 설정하고 모든 팀원의 동의를 구했습니다. 이후 디자인 리뷰 회의에서 예상대로 다른 팀의 시니어 매니저(Contributor)가 개인의 취향이 듬뿍 담긴 피드백을 강력하게 주장하기 시작했습니다. 과거의 루카였다면 그 의견을 방어하느라 진땀을 뺐겠지만, 이제는 달랐습니다. 그녀는 부드럽게 웃으며 말했죠. “정말 좋은 의견이네요! 해당 내용은 저희가 A/B 테스트 아이디어로 고려해보고, 최종 결정권자인 총괄님께 전달하여 전체 프로덕트 방향성과 맞는지 논의해 보겠습니다.”
이 한마디가 모든 것을 바꿨습니다. 논점은 ‘루카의 디자인 vs 매니저의 의견’이 아니라, ‘프로젝트 목표 달성을 위한 여러 아이디어 중 하나’로 바뀌었습니다. 그녀는 더 이상 자신의 디자인을 방어하는 수비수가 아니라, 모든 의견을 수렴하여 최종 결정권자에게 전달하는 훌륭한 촉진자(Facilitator)가 된 것입니다. 작은 승리였지만, 팀원들은 회의가 훨씬 효율적으로 변했다는 것을 즉시 느낄 수 있었습니다.
요약하자면, 루카는 DACI를 통해 논의의 주체를 디자인 자체가 아닌 ‘올바른 의사결정 과정’으로 옮겨옴으로써 불필요한 감정 소모를 줄이고 프로젝트의 본질에 집중하게 만들었습니다.
하지만 모든 과정이 순탄했던 것만은 아닙니다. 다음 장에서는 프레임워크 도입 시 마주할 수 있는 현실적인 어려움에 대해 이야기합니다.
프레임워크 도입의 그림자, 저항과 오해를 넘어서
DACI와 같은 새로운 시스템의 도입은 기존의 비공식적인 권력 구조에 도전하기 때문에, 자신의 영향력이 줄어든다고 느끼는 이들의 저항에 부딪힐 수 있습니다. 이 미묘한 인간적 요소를 어떻게 다루어야 할까요?
질서는 때로 누군가의 자유를 제약하는 것처럼 느껴질 수 있습니다. 특히, 과거에는 자신의 한마디가 곧 결정이었던 시니어급 이해관계자들에게 ‘Contributor(기여자)’라는 역할은 마치 강등처럼 느껴질 수 있습니다. “내가 겨우 의견이나 내는 사람이라고?”라는 볼멘소리가 들려오는 것은 어쩌면 당연한 일입니다. 루카 역시 이러한 보이지 않는 저항에 직면했습니다.
그녀는 이 문제를 정면으로 돌파하기로 했습니다. 그녀는 관련자들을 찾아가 DACI가 특정인의 권한을 빼앗기 위한 도구가 아님을 설명했습니다. 오히려, 불필요한 회의와 끝없는 수정 요청에서 모두를 해방시켜 줄 열쇠라고 설득했죠. “이 프레임워크는 우리가 더 중요한 본질에 집중하고, 더 빠르고 스마트하게 일하기 위한 약속입니다. 시니어님의 통찰력은 여전히 프로젝트에 결정적인 영향을 미치지만, 최종 결정의 부담은 Approver 한 명이 짐으로써 나머지 모두가 각자의 전문성에 더 집중할 수 있게 됩니다.”라고 말이죠.
핵심은 ‘권한 축소’가 아닌 ‘책임과 역할의 명확화’를 통한 ‘효율성 증대’라는 공동의 이익을 강조하는 것이었습니다. 모두가 원하지만 누구도 선뜻 나서지 못했던 ‘빠른 의사결정’과 ‘명확한 책임 소재’라는 가치를 제시하자, 저항의 목소리는 점차 수그러들었습니다. 결국, 투명한 프로세스는 모두에게 이롭다는 공감대가 형성되기 시작한 것입니다.
요약하자면, 성공적인 교차협업 프레임워크 도입을 위해서는 기능적 설명뿐만 아니라, 변화에 대한 구성원들의 감정적 저항을 이해하고 공동의 목표를 제시하는 섬세한 커뮤니케이션이 필수적입니다.
핵심 한줄 요약: 성공적인 교차협업의 열쇠는 모두를 만족시키는 모호한 합의가 아니라, 명확하게 정의된 역할을 바탕으로 가장 올바른 결정을 신속하게 내리는 시스템을 구축하는 것입니다.
결국 디자이너 루카의 이야기는 단순히 DACI라는 프레임워크의 위대함을 말하는 것이 아닙니다. 이것은 디자이너가 픽셀을 다듬는 역할에서 벗어나, 문제 해결의 ‘과정’ 자체를 디자인하는 주체로 거듭나는 성장 서사입니다. 최고의 사용자 경험을 설계하기 위해 우리는 먼저 최고의 동료 경험을 설계해야 할지도 모릅니다.
결국 이 이야기는 우리에게 질문을 던집니다. 당신이 만들어낼 수 있는 가장 위대한 디자인은 아름다운 인터페이스가 아니라, 탁월한 아이디어가 길을 잃지 않고 빛을 발하게 만드는 ‘총명한 협업의 구조’ 그 자체가 아닐까요?
자주 묻는 질문 (FAQ)
DACI에서 Approver(승인자)는 꼭 한 명이어야 하나요?
네, 반드시 한 명이어야 합니다. 이것이 DACI 프레임워크가 효과적으로 작동하는 핵심 원칙으로, 여러 명의 Approver는 오히려 의사결정을 지연시키고 책임 소재를 다시 불분명하게 만들기 때문입니다. 최종 결정의 병목을 제거하고 프로젝트 속도를 높이기 위한 가장 중요한 장치라고 기억해주세요.
저희 팀은 규모가 너무 작아서 DACI가 과하게 느껴져요.
DACI의 본질은 ‘역할 정의를 통한 명확성 확보’에 있으므로, 팀 규모에 맞게 얼마든지 유연하게 적용할 수 있습니다. 예를 들어, 한 사람이 Driver와 Approver를 겸할 수도 있고, 공식적인 차트 대신 회의 시작 전에 “오늘 이 안건의 최종 결정권자는 OOO님입니다”라고 구두로 합의하는 것만으로도 놀라운 효과를 볼 수 있습니다. 중요한 것은 형식이 아니라 그 정신을 실천하는 것입니다.
이 FAQ는 Google FAQPage 구조화 마크업 기준에 맞게 작성되었습니다.