위임하려면 먼저 쪼갤 수 있어야 한다
위임하려면 먼저 쪼갤 수 있어야 한다
신입 팀장이 된 개발자가 처음 마주하는 벽은 코드가 아니다. “이 일 좀 해줘”라고 말하는 순간, 상대방의 눈이 흐려지는 것이다. 내 머릿속에서는 완벽히 그려지는 프로세스가, 말로 옮기면 안개처럼 흩어진다.
이 경험에서 출발한 질문이 있다. 왜 사람들은 자기 업무를 자동화하지 못하는가? 기술 도구는 넘치는데, 정작 “뭘 자동화할지”를 정의하지 못한다. 답은 의외로 단순했다.
“자신의 업무를 쪼갤 수 있어야 위임할 수 있다.” 사람에게든, AI Agent에게든.
왜 이게 중요한가
위임(delegation)의 전제 조건은 **분해(decomposition)**다.
위임 대상이 사람인지 AI인지는 부차적이다. 핵심은 위임자가 자기 업무를 구조적으로 분해할 수 있는 능력을 갖추고 있는가이다.
업무를 쪼갤 수 있다 = 위임할 수 있다 = 리더 역할을 수행할 수 있다.
왜 쪼개기가 어려운가
대부분의 실무자는 업무를 “감”으로 수행한다:
- 암묵지(tacit knowledge): 말로 설명하기 어려운 판단 기준. “그냥 느낌으로 알아요.”
- 흩어진 구조: 여러 도구, 시스템, 사람에 걸친 프로세스. 전체 그림이 머릿속에만 있다.
- 컨텍스트 의존: “상황 봐서” 처리하는 예외 케이스. 매뉴얼에 없는 것들.
이것들이 구조화되지 않으면:
- 사람에게 위임해도 → 인수인계 실패, 품질 편차, “그 사람 없으면 안 돌아감”
- AI에게 위임해도 → 환각, 누락, 신뢰 불가, “이거 맞아?” 무한 확인
Workflow Studio의 접근: Discovery Interview
이 문제를 AI 인터뷰로 푼다:
- 5-level 심층 인터뷰: L1(표면) → L2(구조) → L3(규칙) → L4(경험) → L5(맥락)
- 각 레벨에서 암묵지를 명시지로 전환 — Nonaka의 SECI 모델 중 Externalization
- 결과물은 Task Catalog — 분해된 업무의 구조적 목록
- 각 Task에 Trust Level(0~4) 부여 — 얼마나 자동화/위임할 수 있는지의 단계
핵심 발견: 자동화의 본질적 난점은 “실행”이 아니라, 그 이전의 **정의(Definition)**에 있다.
더 큰 그림
개인 역량의 성장 경로
실무자 (직접 수행)
→ 구조화자 (업무를 쪼갤 수 있음)
→ 위임자 (사람/AI에게 맡길 수 있음)
→ 리더 (시스템을 설계함)
이건 The Orchestrator’s Role에서 말한 “시즌을 설계하는 사람”과 연결된다. 직접 당근을 썰지 않고, 메뉴를 설계하는 헤드 셰프. 그 전제 조건이 바로 “레시피를 분해할 수 있는 능력”이다.
AI 시대의 핵심 역량
AI Native Mindset에서 말한 “설명을 잘하는 사람이 프롬프트도 잘한다”의 연장선:
- 설명할 수 있다 = 구조를 이해하고 있다
- 프롬프트를 잘 쓴다 = 업무를 분해하여 전달할 수 있다
- AI를 잘 쓴다 = 위임할 수 있다
제품 함의
Workflow Studio의 진짜 가치는 “앱을 만들어주는 것”이 아니라 **“당신의 업무를 구조화해주는 것”**일 수 있다.
배포 가능한 앱은 구조화의 결과물이지 목적이 아님. 리서치에서도 같은 결론:
“진짜 가치는 다른 데 있을 수도 — 인터뷰 → 구조화된 스펙 → 실행이 핵심” — research-synthesis.md
- ↔️ trust-ladder-automation-is-stairs — 같은 테마: 위임의 실행 방법론
- 🌐 orchestrator-role — 다른 시각: 위임하는 리더의 역할. “시즌을 설계하는 사람들”
- 🌐 ai-native-mindset — 다른 시각: AI를 협업자로 다루는 마인드셋. 설명력 = 위임력