2026 All-Day-Project (029/365)
기다림의 기술에서 우리는 침묵과 인내에 대해 이야기했다. 팀원이 스스로 생각할 공간을 만들어주는 것, 성장을 향해 실패할 시간을 허용하는 것. 그러나 기다림만으로는 부족하다. 기다리는 동안 우리는 무엇을 넘겨주어야 하는가? 무엇을 맡겨야 하는가?
기다림이 '공간을 만드는 기술' 이라면, 위임은 '그 공간에 씨앗을 심는 기술'이다.
많은 리더가 위임을 잘못 이해한다. "내가 바쁘니까 넘긴다." "이건 귀찮은 일이니까 맡긴다." 이것은 위임이 아니라 회피다. 그리고 팀원들은 그 차이를 안다.
진짜 위임은 자신이 할 수 있는 일을 넘기는 것이다. 자신이 잘하는 일, 자신이 직접 하면 더 빠르고 정확하게 끝낼 수 있는 일. 그것을 팀원에게 넘기는 것이 위임이다. 왜? 팀원의 성장이 당신 혼자의 효율보다 중요하기 때문이다.
시어도어 루스벨트가 말했던 것처럼, "가장 훌륭한 리더는 자신이 바라는 일을 수행할 적임자를 고르는 감각과, 그들이 그 일을 하는 동안 간섭하지 않을 수 있는 절제력을 가진 사람이다." 적임자를 고르는 것이 위임의 시작이고, 간섭하지 않는 것이 기다림의 기술이며, 이 둘을 연결하는 것이 리더의 몫이다.
애플에서 스티브 잡스가 도입한 개념이 있다. DRI(Directly Responsible Individual). 직역하면 '직접 책임지는 개인'. 모든 프로젝트, 모든 결정, 모든 과업에는 단 한 명의 DRI가 있다.
왜 중요한가?
"우리 팀이 담당합니다"라고 말하는 순간, 아무도 책임지지 않게 된다. 회의에서 "이거 누가 하기로 했죠?"라는 질문이 나오는 이유다. 책임이 분산되면 책임은 증발한다. 반면 DRI가 명확하면 그 사람이 결정권을 갖고, 그 사람이 결과를 소유한다. 책임에 이름이 붙는 순간, 책임은 비로소 실체가 된다.
위임과 DRI의 결합
위임은 일을 넘기는 것이다. DRI는 책임을 명확히 하는 것이다. 이 둘이 결합할 때 진짜 임파워먼트(empowerment)가 일어난다.
단순히 "이거 해주세요"라고 말하는 것은 업무 분담이다. "당신이 이것의 DRI입니다. 이 프로젝트의 성공과 실패는 당신에게 달려 있고, 결정 권한도 당신에게 있습니다"라고 말하는 것이 위임이다.
성숙한 책임을 지는 사람은 결과를 예측하고, 선택하고, 그 결과를 소유한다. DRI는 이 성숙한 책임을 제도화한 것이다. "누가 책임지나요?"라는 질문에 망설임 없이 답할 수 있게 만드는 구조.
케이스 스터디: 민수 팀장의 신규 서비스 런칭
민수 팀장은 신규 결제 시스템 프로젝트를 맡게 되었다. 팀원은 5명. 그는 킥오프 미팅에서 이렇게 말했다.
"이 프로젝트는 우리 팀이 함께 책임집니다. 다 같이 열심히 해봅시다."
두 달 후, 런칭 일주일 전. 결제 모듈에서 심각한 버그가 발견되었다. 민수 팀장이 물었다.
"이거 누가 담당이었죠?" 침묵이 흘렀다. 모두가 서로를 쳐다봤다.
결국 민수 팀장이 밤새 직접 버그를 잡았다.
프로젝트가 끝난 후, 민수 팀장은 방식을 바꿨다. 다음 프로젝트에서 그는 화이트보드에 이렇게 적었다.
- 결제 모듈 DRI: 지현
- 사용자 인증 DRI: 승우
- 관리자 대시보드 DRI: 하나
"지현 씨, 결제 모듈은 당신이 DRI입니다. 이 부분의 기술적 결정은 당신이 내리고, 문제가 생기면 당신이 해결합니다. 대신 필요한 리소스는 제가 지원하겠습니다."
같은 상황이 다시 왔을 때, 지현은 스스로 야근하며 문제를 해결했다. 민수 팀장에게 도움을 요청하지 않은 게 아니다. 자신이 책임자라는 것을 알았기 때문에 먼저 최선을 다한 것이다. 그리고 그 과정에서 지현은 성장했다.
그러나 위임은 쉽지 않다. 흔히 빠지는 함정들이 있다.
첫 번째 함정: 책임 없는 권한.
"알아서 해"라고 말하면서 결정권은 주지 않는 것. 팀원이 결정을 내릴 때마다 "그건 내가 확인해볼게"라고 끼어드는 것. 이것은 위임이 아니라 위임의 연기(演技)다. 권한과 책임은 함께 움직여야 한다.
두 번째 함정: 권한 없는 책임.
결과에 대한 책임은 팀원에게 지우면서, 결정 권한은 리더가 쥐고 있는 것. "결정은 내가 했지만 실패의 책임은 네가 져"라는 구조. 이것은 위임이 아니라 희생양 만들기다. 신뢰를 파괴하는 가장 빠른 방법이다.
세 번째 함정: 마이크로매니지먼트로의 회귀.
위임했다가 불안해서 다시 끼어드는 것. "그냥 확인 차원에서" 라는 말로 시작해서, 결국 모든 것을 다시 쥐게 되는 것. 기다림을 포기하는 순간, 위임도 무너진다.
케이스 스터디: 세 명의 팀장, 세 가지 함정
영희 팀장 (책임 없는 권한)
영희 팀장은 신입 개발자 준호에게 말했다. "이 기능 설계는 네가 맡아. 알아서 해봐."
준호는 열심히 설계안을 만들었다. 그러나 리뷰 미팅에서 영희 팀장이 말했다.
"음, 이 부분은 내가 다시 볼게. 그리고 이 결정은 내가 해야 할 것 같아." 준호는 혼란스러웠다.
결국 그는 모든 결정을 영희 팀장에게 확인받기 시작했고, '알아서 하라'던 위임은 유명무실해졌다.
철수 팀장 (권한 없는 책임)
철수 팀장은 마케팅 캠페인 기획을 수아에게 맡겼다.
단, 예산, 일정, 채널 선택은 모두 철수 팀장이 결정했다. 캠페인이 실패하자 철수 팀장은 말했다.
"수아 씨가 담당이었는데 왜 이런 결과가 나온 거죠?" 수아는 억울했다.
자신이 내린 결정은 하나도 없었기 때문이다. 다음 프로젝트에서 수아는 DRI를 거부했다.
정훈 팀장 (마이크로매니지먼트로의 회귀)
정훈 팀장은 시니어 개발자 미래에게 아키텍처 설계를 위임했다.
"당신이 가장 잘 아니까 믿고 맡길게요." 그러나 3일 후, 정훈 팀장은 불안해졌다.
"그냥 확인 차원에서" 미래의 설계 문서를 검토하기 시작했다.
일주일 후에는 매일 진행 상황을 물었다. 2주 후에는 설계 회의에 참석해서 의견을 내기 시작했다.
미래는 결국 손을 놓았다. "팀장님이 하시는 게 낫겠네요."
정훈 팀장은 위임했던 일을 다시 떠안게 되었다.
DRI 시스템이 제대로 작동하려면 몇 가지 조건이 필요하다.
첫째, 명확한 범위 정의.
무엇에 대한 DRI인지 모호하면 안 된다. "이 프로젝트 전체의 DRI"와 "이 기능 구현의 DRI"는 다르다. 경계가 명확해야 권한도 명확해지고, 책임도 명확해진다.
둘째, 실패할 권리.
DRI에게 실패할 권리를 주어야 한다. 실패하면 문책당한다면, 아무도 DRI가 되려 하지 않을 것이다. 물론 같은 실패를 반복하면 문제다. 그러나 처음 시도하는 것에서의 실패는 학습이다.
셋째, 에스컬레이션 경로.
DRI가 혼자 감당할 수 없는 상황이 올 수 있다. 그때 어디로 도움을 요청해야 하는지가 명확해야 한다. "당신이 책임자니까 알아서 해결해"가 아니라, "막히면 나에게 와"라는 안전망.
넷째, 맥락의 공유.
DRI가 좋은 결정을 내리지 못하는 가장 큰 이유는 무엇인가? 리더만큼 정보를 모르기 때문이다. 권한을 주면서 정보는 주지 않으면, DRI는 어둠 속에서 결정을 내려야 한다.
넷플릭스의 리드 헤이스팅스(Reed Hastings)가 말한 원칙이 있다: "통제하지 말고 맥락을 공유하라(Lead with Context, not Control)."
맥락이란 무엇인가?
- 이 프로젝트가 왜 중요한지, 전사적 전략에서 어디에 위치하는지
- 어떤 제약 조건이 있는지 (예산, 일정, 기술적 한계)
- 이해관계자들이 무엇을 기대하는지
- 과거에 비슷한 시도가 있었다면 왜 성공/실패했는지
정보를 독점하면서 권한만 위임하는 것은 위험하다. 그것은 팀원에게 눈가리개를 씌우고 달리라고 하는 것이다. 권한을 주려면 정보도 함께 줘야 한다. DRI가 리더와 같은 맥락을 공유할 때, 비로소 리더처럼 결정할 수 있다.
모든 것을 한꺼번에 위임할 수는 없다. 점진적으로 해야 한다.
1단계: 관찰자로서의 참여.
먼저 당신이 하는 것을 지켜보게 한다. 왜 이런 결정을 내리는지, 어떤 것들을 고려하는지 보여준다.
2단계: 함께 하기.
같이 결정하고, 같이 실행한다. 이 단계에서 피드백이 오간다.
3단계: 위임 후 검토.
팀원이 결정하고, 당신은 검토한다. 치명적 오류만 바로잡고, 나머지는 학습의 기회로 남겨둔다.
4단계: 완전한 위임.
팀원이 결정하고, 실행하고, 결과를 보고한다. 당신은 결과만 확인한다.
이 과정에서 핵심은 단계를 건너뛰지 않는 것이다. 1단계에서 바로 4단계로 가면 실패한다.
위임의 스펙트럼: 상황에 맞는 위임 레벨 선택
위임은 0과 1의 문제가 아니다. Management 3.0의 '위임 포커(Delegation Poker)'*개념은 위임을 7단계의 스펙트럼으로 나눈다:
1. 말해준다(Tell) - 리더가 결정하고 알려준다
2. 설득한다(Sell) - 리더가 결정하고 그 이유를 설명한다
3. 상의한다(Consult) - 의견을 구하지만 최종 결정은 리더가 한다
4. 합의한다(Agree) - 함께 논의하여 합의에 이른다
5. 조언한다(Advise) - 팀원이 결정하되 리더가 조언한다
6. 문의한다(Inquire) - 팀원이 결정하고 리더에게 알린다
7. 위임한다(Delegate) - 팀원이 완전히 결정한다
그렇다면 어떤 기준으로 단계를 선택해야 하는가? 앤디 그로브(Andy Grove)의 '과업 관련 성숙도(Task Relevant Maturity, TRM)' 개념이 해답을 준다. TRM은 특정 과업에 대한 팀원의 경험, 지식, 의지의 조합이다.
같은 사람이라도 과업에 따라 TRM이 다르다. 10년차 개발자도 처음 맡는 영역에서는 초보자다.
TRM이 낮을 때: 1~3단계의 위임이 적절하다. 구체적 지시와 빈번한 확인이 필요하다. 이때 완전한 위임(7단계)은 '방임'이다. 팀원을 수렁에 던져놓는 것이다.
TRM이 중간일 때: 4~5단계가 맞다. 함께 논의하고, 팀원의 결정을 지지하되 필요할 때 조언한다.
TRM이 높을 때: 6~7단계로 가야 한다. 결정을 맡기고 결과만 공유받는다. 이때 1~3단계에 머무르면 '간섭'이다. 유능한 인재를 질식시키는 것이다.
위임의 레벨은 사람이 아니라 사람-과업의 조합 으로 결정해야 한다. 리더의 역할은 각 상황에서 적절한 위임 레벨을 찾아내는 것이다.
케이스 스터디: 같은 사람, 다른 위임 레벨
소영 팀장은 10년차 백엔드 개발자 재민을 데리고 있다. 재민은 API 설계의 달인이다.
소영 팀장은 새 API 프로젝트가 생기면 재민에게 7단계(완전한 위임)로 맡긴다.
재민이 설계하고, 결정하고, 구현한다. 소영 팀장은 결과만 공유받는다.
그런데 회사에서 새로운 전략이 내려왔다. "ML 기반 추천 시스템을 구축하라." 재민에게도 이 업무가 할당되었다. 10년차 개발자이지만, ML은 처음이다.
이때 소영 팀장이 똑같이 7단계로 위임하면 어떻게 될까?
재민은 수렁에 빠질 것이다. 무엇을 모르는지도 모르는 상태에서 혼자 헤매게 된다.
소영 팀장은 위임 레벨을 조정했다:
1~2주차: 2단계(설득한다). 팀장이 ML 기초와 추천 시스템 아키텍처에 대해 설명하고, 왜 이 접근이 필요한지 공유한다.
3~4주차: 3단계(상의한다). 재민이 학습한 내용을 바탕으로 설계안을 가져오면, 함께 논의하되 최종 결정은 팀장이 한다.
2개월 차: 4단계(합의한다). 재민의 ML 지식이 늘었다. 이제 함께 논의하고 합의에 이른다.
4개월 차: 6단계(문의한다). 재민이 이제 이 영역에서도 자신감이 생겼다. 그가 결정하고, 팀장에게 알린다.
같은 재민이다. 그러나 과업에 따라 TRM이 다르고, 위임 레벨도 달라져야 한다. 이것을 무시하면 방임 아니면 간섭이 된다.
그러나 위임할 수 없는 것도 있다.
비전과 방향. 팀이 어디로 가야 하는지는 리더가 제시해야 한다. 이것을 위임하면 팀은 표류한다.
최종 책임. DRI에게 일차적 책임을 맡기더라도, 궁극적 책임은 리더에게 있다. 팀원의 실패는 결국 리더의 실패다. 이것을 부정하면 신뢰가 무너진다.
사람에 대한 결정. 채용, 해고, 평가. 이런 중대한 인사 결정은 위임의 대상이 아니다.
위기 상황에서의 결정. 배가 침몰할 때 선장은 위임하지 않는다. 직접 키를 잡는다.
위임은 주는 자의 기술만이 아니다. 받는 자의 기술이기도 하다.
위임받았다면, 그것을 온전히 소유해야 한다. "일단 해볼게요, 안 되면 도와주세요"가 아니라 "제가 책임지고 해내겠습니다. 막히면 미리 알려드리겠습니다"여야 한다.
결과가 좋으면 팀의 공이다. 결과가 나쁘면 DRI의 책임이다. 이 비대칭을 받아들일 수 있어야 진정한 DRI가 될 수 있다. DRI는 영광보다 책임을 먼저 지는 사람이다.
원숭이를 돌려보내라: 역위임의 함정
윌리엄 온켄 주니어(William Oncken Jr.)의 '원숭이 관리(Monkey Management)'*개념이 있다. 여기서 '원숭이'는 다음 행동에 대한 책임을 의미한다.
팀원이 "팀장님, 이거 어떻게 하죠?"라고 물을 때, 리더가 "음, 내가 생각해보고 알려줄게"라고 답하는 순간—원숭이는 팀원의 등에서 리더의 등으로 뛰어넘는다. 이것이 역위임(Reverse Delegation)이다.
역위임이 반복되면 리더의 등에는 원숭이가 수십 마리 매달리고, 팀원들은 빈 등으로 다음 지시를 기다린다. 위임은 실패하고, 리더는 지쳐가며, 팀원은 성장하지 못한다.
이를 막으려면 원칙이 필요하다:
"문제를 가져오지 말고, 해결안을 가져오라."
팀원이 질문을 가져왔을 때, 답을 주지 마라. 대신 질문을 던져라:
- "어떤 방법들을 생각해봤어?"
- "그중에 가장 좋다고 생각하는 건?"
- "그 방법의 리스크는 뭐라고 생각해?"
이렇게 하면 원숭이는 팀원의 등에 남는다. 리더의 역할은 답을 주는 자판기가 아니라, 질문을 던지는 코치다.
물론 정말 모를 때는 도움을 줘야 한다. 그러나 먼저 생각해보게 하고, 생각한 것을 가져오게 해야 한다. 그것이 위임을 지키는 방법이다.
케이스 스터디: 현우 팀장의 원숭이 농장
현우 팀장은 6명의 팀원을 이끈다. 어느 날 그는 자신의 하루를 되돌아봤다.
아침 9시, 팀원 A가 왔다. "팀장님, 이 API 설계 어떻게 하면 좋을까요?" 현우는 답했다. "음, 내가 생각해보고 오후에 알려줄게."
10시, 팀원 B. "팀장님, 이 고객 이슈 어떻게 대응하죠?" "일단 내가 검토해볼게."
11시, 팀원 C. "팀장님, 이번 스프린트 우선순위가 헷갈려요." "그래, 내가 정리해줄게."
점심시간이 되자 현우의 등에는 원숭이 세 마리가 올라타 있었다. 오후에도 두 마리가 더 올라왔다. 팀원들은 빈 등으로 점심을 먹으러 갔고, 현우는 샌드위치를 먹으며 그들의 원숭이를 돌봤다.
저녁 7시, 팀원들은 퇴근했다. 현우는 남아서 다섯 마리의 원숭이를 돌보고 있었다.
다음 날, 현우는 방식을 바꿨다.
팀원 A: "팀장님, 이 API 설계 어떻게 하면 좋을까요?"
현우: "어떤 방식들을 고민해봤어?"
A: "RESTful하게 가는 방법이랑, GraphQL을 쓰는 방법이요."
현우: "좋아. 각각의 장단점은 뭐라고 생각해?"
A: "REST는 익숙하지만 오버페칭이 있고, GraphQL은 유연하지만 학습 곡선이..."
현우: "그중에 뭐가 낫다고 생각해?"
A: "우리 상황에서는 REST가 나을 것 같아요. 팀원들 모두 익숙하고, 일정이 빠듯하니까요."
현우: "좋아, 그렇게 진행해. 막히면 언제든 와."
원숭이는 A의 등에 남았다. A는 스스로 결정하는 법을 배웠다. 현우의 저녁 시간은 돌아왔다.
기다림의 기술이 "팀원이 '내가 해냈다'고 느끼게 하는 것"을 목표로 했듯이, 위임도 마찬가지다.
잘 된 위임은 보이지 않는다. 팀원은 자신이 선택하고, 자신이 실행하고, 자신이 성공했다고 느낀다. 리더가 넘겨준 것이라는 사실조차 잊는다. 그것이 위임의 완성이다.
나를 위한 위임의 원칙
- 내가 할 수 있는 일을 넘긴다 (회피가 아닌 투자)
- 권한과 책임을 함께 넘긴다
- DRI를 명확히 지정한다
- 점진적으로 위임의 범위를 넓힌다
- 위임 후에는 필요한 만큼 기다린다.
- 실패할 권리를 보장한다
- 에스컬레이션 경로를 열어둔다
- 최종 책임은 내가 진다
농부는 씨앗을 심고 기다린다. 물을 주고, 햇빛이 들게 하고, 잡초를 뽑는다. 그러나 농부가 작물을 대신 자라게 할 수는 없다. 자라는 것은 식물의 몫이다.
그러나 농부가 먼저 해야 할 일이 있다. 토양을 가꾸는 것이다.
아무리 좋은 씨앗도 척박한 땅에서는 자라지 않는다. 돌이 많은 땅, 양분이 없는 땅, 오염된 땅에서는 어떤 씨앗도 싹을 틔우지 못한다. 마찬가지로, 아무리 명확한 위임도 비난하는 문화 속에서는 뿌리내리지 못한다.
'비난 없는 문화(Blameless Culture)'—이것이 위임이 자라는 토양이다. 실패했을 때 "누구 책임이야?"가 아니라 "무엇을 배울 수 있지?"를 먼저 묻는 문화. 시도가 칭찬받고, 실수가 학습이 되는 환경. 이 토양이 없으면 아무도 DRI가 되려 하지 않는다. 위임을 받아도 안전하게 뒤로 숨으려 할 것이다.
리더의 역할은 단순히 씨앗을 심고 기다리는 것이 아니다. 그 전에 토양을 일구어야 한다. 비난의 돌멩이를 골라내고, 신뢰의 양분을 채우고, 심리적 안전감이라는 수분을 공급해야 한다.
위임은 씨앗을 심는 것이다. DRI를 지정하는 것은 그 씨앗에 이름을 붙이는 것이다. 기다림은 자랄 시간을 주는 것이다. 그리고 비난 없는 문화를 만드는 것은 씨앗이 자랄 토양을 준비하는 것이다.
그리고 어느 날, 팀원이 스스로 결정하고, 스스로 책임지고, 스스로 성장하는 것을 본다. 그 순간이 리더에게 주어지는 유일한 보상이다.
위임은 일을 덜어내는 기술이 아니다. 사람을 키우는 기술이다. 그리고 사람이 자라려면, 먼저 자랄 수 있는 땅이 필요하다.