THINK TANK / 방법 · R1

직무·책임 분석에서 역할별 업무 매뉴얼로: 참여자가 어떻게 기여할지 알 수 있게 하려면

사업에 필요한 결과에서 출발해 직무·책임 분석을 가치 기여 역할의 업무 매뉴얼로 구체화한다. 작업, 조건, 권한, 산출물과 협업을 분명히 하고, 요구사항 정리 협력자의 가정 사례로 매뉴얼을 실제 작업에 적용하고 개선하는 방법을 설명한다.

이 자료의 활용 방법방법
용도
사업에 필요한 결과에서 출발해 직무·책임 분석을 가치 기여 역할의 업무 매뉴얼로 구체화한다. 작업, 조건, 권한, 산출물과 협업을 분명히 하고, 요구사항 정리 협력자의 가정 사례로 매뉴얼을 실제 작업에 적용하고 개선하는 방법을 설명한다.
사용 조건
대상, 목표, 제약이 현재 과제에 맞는지 확인하고 본문에 명시되지 않은 조건은 별도로 확인하세요.
방법
단계, 입력, 완료 조건
근거와 검증 범위
실제 업무에서 매뉴얼을 시험해 책임, 업무가 시작되는 경로, 산출물 조건을 확인하고 피드백에 따라 수정합니다. 이 글에 대한 외부 검증 결과는 별도로 등록되어 있지 않습니다. 공개 자체가 효과의 검증을 뜻하지는 않습니다. 본문의 근거, 가정, 한계를 확인하세요.
버전
R1 · 수정 2026-11-04

읽고 인용할 수 있는 지식 자료이며 설치된 Skill이 아닙니다. AI에 사용할 때도 출처와 한계를 유지하고 결과를 검토하세요.

CC BY-NC-ND 4.0 · 별도 명시가 없는 한 원본 글에 적용되며 제3자 자료는 제외됩니다. 다운로드나 기계 판독은 기존 허락 범위를 확대하지 않으며 2차 저작물, 상업적 이용, 모델 학습을 별도로 허용하지 않습니다.

어떤 사업에 참여하고 싶다는 사람이 있다. 그다음에는 어떻게 시작해야 할까?

“요구사항을 정리해 주세요”, “콘텐츠 작업을 도와주세요”라고만 하면, 상대는 곧 구체적인 문제에 부딪힌다. 누구에게 상황을 물어봐야 하는지, 어떤 자료를 쓸 수 있는지, 어느 정도 완성해야 넘길 수 있는지, 의견이 다를 때는 누구에게 결정을 요청해야 하는지 알기 어렵다.

기업 내부에서도 같은 문제가 생긴다. 직무와 책임을 적어 놓고 절차도 그렸지만, 담당자가 바뀌면 이전 담당자가 같은 설명을 거듭해야 한다.

업무 매뉴얼에는 책임을 맡은 뒤 어떻게 일을 시작하고 진행할지를 분명히 적어야 한다고 생각한다. 참여자는 자신이 무엇을 기여할 수 있는지, 어떤 조건이 필요한지, 다른 사람과 어떻게 연결해 일하는지 알아야 한다.

1. 먼저 이 일이 어떤 결과를 뒷받침해야 하는지 살펴본다

매뉴얼을 쓰기 전에 실제 사업 하나를 골라, 지금 어떤 결과가 필요한지부터 확인한다.

예를 들어 기업이 사업 소개 자료를 만들려고 한다고 하자. 당장 필요한 것은 원고 작성자와 디자이너가 작업을 시작할 수 있는, 확인된 요구사항 설명일 수 있다. 어떤 고객을 위한 자료인지, 어디에서 사용할지, 고객이 무엇을 이해하도록 도와야 하는지도 분명해야 한다.

“지금 누가 시간이 있나”부터 생각해 일을 나누면, 임시 배정을 장기적인 책임으로 굳히기 쉽다. 기존 직무 이름에 맞춰 내용을 채우기만 해도, 사업에 꼭 필요하지만 아직 아무도 맡지 않은 일을 놓칠 수 있다.

초기 자료인 『SOP(표준작업절차) 정리·설계 방법론』은 이미 업무 흐름, 직무별 작업, 구체적인 행동, 기준과 인계를 연결하고, 시험 적용 후 개선하도록 제안했다. 이 생각을 발전시키려면 먼저 필요한 결과를 찾고, 현재의 일이 그것을 어떻게 뒷받침하는지 확인하면 된다. 잘 작동하는 분담은 유지하되, 책임이 겹치거나 인계에 공백이 있거나 조건이 부족한 부분은 다시 논의해야 한다.[1]

여기서는 두 층위의 결과를 구분해야 한다. 요구사항 설명을 확인받는 것은 하나의 업무 산출물이다. 그것이 실제로 자료를 더 명확하게 만들고 고객의 판단에 도움이 되는지는 후속 사업에서 관찰해야 한다. 매뉴얼이 완성되어 있고 작업을 제때 마쳤다고 해서 경영 성과까지 개선되었다고 단정할 수는 없다.

2. 역할, 사람, 이번 작업을 각각 분명히 한다

직무 분석은 일을 이해하는 출발점이 된다. 팀과 조직을 넘나드는 협업에서는 그중 비교적 독립적으로 맡을 수 있는 기여를 역할로 설명할 필요가 있다.

여기서 가치 기여 역할이란 특정 유형의 기여와 그에 따르는 책임에 대한 약속이다. 예를 들어 ‘요구사항 정리 협력자’는 요구사항을 수집하고 확인해, 후속 작업에 사용할 요구사항 확인서를 만들 수 있다. 적절한 조건이 갖춰지면 내부 직원도 외부 전문 협력자도 이 역할을 맡을 수 있다.

구분답해야 할 질문요구사항 정리의 예
역할어떤 유형의 기여를 지속해서 맡고, 그 범위는 어디까지인가?사업 소개 자료 제작 요구사항을 수집·확인·정리한다
사람누가 필요한 역량, 시간과 참여 조건을 갖추고 있는가?이번에는 내부 동료 또는 외부 협력자 한 명이 맡는다
작업이번에 무엇을 제출하고, 누가 맡아 수행하며 누가 검수하는가?합의한 기한 안에 특정 프로젝트의 요구사항 확인서를 제출한다

한 사람이 여러 역할을 맡을 수도 있고, 같은 역할을 여러 사람이 맡을 수도 있다. 다만 매번 작업 수행자, 협력자, 검수자를 명확히 해야 한다. ‘요구사항 정리 역할이 담당’이라고만 적어서는 부족하다. 여러 사람이 함께 맡는다면 각자의 범위도 정해, 모두 다른 사람이 처리했다고 생각하는 상황을 막아야 한다.

자원, 운영·관리, 고객, 자본은 참여 관계를 살펴보는 네 가지 생태계다. 역할별 업무를 정할 때 이 네 생태계에 맞춰 매뉴얼을 기계적으로 하나씩 만들 필요는 없다. 모든 유형의 참여자는 먼저 기여를 제안할 수도 있고 구체적인 요구에 응답할 수도 있다. 소수 정예 운영·관리팀은 관련 의사결정과 규칙을 맡고, 가치 생산, 판매 채널과 고객 관계를 조율한다. 개별 사안을 누가 결정할지는 실제 위임된 권한에 따라 따로 분명히 해야 한다.

업무 매뉴얼은 실제로 맡은 가치 기여 역할에 대응한다. 구매·사용 고객은 구매, 사용, 피드백, 사후 서비스 등의 절차에 따라 참여한다. 투자만 하는 사람은 해당 투자와 정보 소통 절차에 따라 참여한다. 이 두 신분만을 이유로 공동 작업용 매뉴얼을 요구하지 않는다. 이들이 별도로 제품 공동 개발, 전문 연구 등 명확한 기여 역할을 맡으면 그 역할의 매뉴얼을 사용한다.[2]

좌우로 스크롤하거나 큰 그림을 열어 확인하세요.

그림 1. 사업에 필요한 결과를 먼저 정하고, 기여 역할을 정의해 매뉴얼을 만든 뒤 개별 작업에 적용한다.
그림 1. 화살표는 이 글이 제안하는 정리 순서다. 한 사람이 여러 역할을 맡을 수 있으며, 작업을 맡는 방식은 매번 따로 정한다. 예시는 효과가 검증되었다는 뜻이 아니다.

큰 그림 열기 ↗편집 가능한 SVG 다운로드 ↓

3. 매뉴얼 한 권으로 여덟 가지 질문에 답할 수 있어야 한다

책임 설명에는 먼저 ‘무엇을 맡는가’를 적을 수 있다. 업무 매뉴얼은 여기서 더 나아가 어떻게 시작하고, 처리하고, 마무리할지 알려주어야 한다.

다음 여덟 가지 질문은 첫 매뉴얼의 점검표로 쓸 수 있다. 분량은 일의 복잡성에 맞추면 된다. 목차를 채우려고 불필요한 내용을 만들 필요는 없다.

답해야 할 질문매뉴얼에 들어갈 내용
이 역할은 왜 필요한가?누구를 위한 일인지, 뒷받침할 사업 결과, 역할의 범위
어떤 일을 내가 맡는가?주요 책임, 작업이 들어오는 경로, 다른 역할과의 분담
어떤 조건이 갖춰져야 시작할 수 있는가?필요한 자료, 역량, 시간, 도구와 접근 권한
보통 어떻게 일을 진행하는가?핵심 단계, 관련된 적용 가능 SOP, 양식과 예시
무엇을 스스로 결정할 수 있는가?직접 확인·처리할 사안과 다른 사람의 결정이 필요한 사안
무엇을 내야 하고, 어떤 상태면 합격인가?산출물, 품질 요구사항, 검수 방식, 인수할 역할
부족한 점이나 변경이 생기면 어떻게 하는가?기록 방식, 연락 대상, 보완·조정·일시 중단을 요청할 경로
누가 이 매뉴얼을 관리하는가?관리 담당자, 버전, 적용 범위, 시행 시점과 변경 방식

책임은 다른 사람이 구체적으로 무슨 일을 하는지 알 수 있을 정도로 적는다. ‘요구사항 관리 담당’은 아직 너무 넓다. ‘제작 목적, 사용 상황과 내용 범위를 확인해 요구사항 확인서를 만들고, 출처와 미확인 사항을 표시한다’처럼 더 구체적으로 쓸 수 있다.

기준도 일과 관련되어야 한다. 사실 확인이 필요한 일이라면 무엇에 출처가 있어야 하는지, 어떤 자료 부족이 진행에 영향을 주는지 적는다. ‘성실하게’, ‘신속하고 효율적으로’ 같은 말로 요구사항을 대신하지 않는다. 탐색적인 일에는 방법을 고를 여지를 남긴다. 답해야 할 질문, 근거에 대한 요구와 논의 시점을 분명히 하되, 모든 단계를 고정할 필요는 없다.

SOP(표준작업절차)와 역할별 매뉴얼은 서로 참조할 수 있다. 매뉴얼은 역할을 기준으로, 어떤 상황에서 어떤 절차를 쓸지 알려준다. SOP는 하나의 일을 기준으로 관련 역할, 단계와 기준을 설명한다. 공통 절차는 유효한 버전 하나만 관리하고 매뉴얼에서 이를 참조한다. 여러 곳에 복사해 놓고 각기 다르게 바뀌는 문제를 줄이기 위해서다.

4. 실제 일에서 내용을 찾고, 다른 사람에게 써 보게 한다

첫 버전은 이미 수행했거나 곧 시작할 작업 하나에서 출발할 수 있다.

실제 수행자에게 일이 어디에서 들어오는지, 처음에 어떤 자료를 보는지, 어떤 판단에 경험이 필요한지, 보통 누구에게 확인하는지, 마지막에 무엇을 누구에게 넘기는지 설명해 달라고 한다. 이어 선행·후속 담당자에게 각각 확인한다. 수행자가 끝났다고 생각한 일을 후속 담당자가 정말 받아서 쓸 수 있는지는 이때 드러나는 경우가 많다.

정리할 때는 확인된 방식, 시험 적용할 계획, 아직 결정되지 않은 문제를 구분한다. 오래 해 온 방식이라고 합리적인 기준이 되는 것은 아니다. 새로 제안한 좋은 방법도 실제로 써 봐야 한다.

그다음 기본 역량은 있지만 해당 일에는 익숙하지 않은 협력자에게, 매뉴얼을 보고 범위가 통제 가능한 작업 하나를 해 보게 한다. 처음에는 도움을 줄 사람이 있어도 된다. 동시에 어디에서 멈췄는지, 무엇에 추가 설명이 필요했는지, 어떤 입력 자료를 아예 구할 수 없었는지 기록한다.

이런 문제가 생기면 먼저 매뉴얼과 업무 조건을 확인한다. 설명이 불분명한가, 아니면 작업이 역량을 넘어서는가? 절차에 빠진 것이 있는가, 아니면 권한·자료·시간이 마련되지 않았는가? 원인을 확인한 뒤 교육을 보충할지, 분담을 바꿀지, 조건을 조정할지, 매뉴얼을 고칠지 결정한다.

일의 불확실성이 여전히 크다면 짧은 역할 설명과 작업 명세서로 시작해, 진행하면서 기록해도 된다. 미리 고정된 단계로 억지로 만들면, 사용자가 더 이상 성립하지 않는 전제를 따라 계속 일하게 할 수 있다.

5. ‘요구사항 정리 협력자’ 역할을 예로 작성해 본다

아래는 기업 사업 소개 자료 제작을 가정한 예다. 방법의 사용법을 설명하기 위한 것이며, 특정 프로젝트에서 이미 얻은 성과를 뜻하지 않는다.

역할의 목적: 원고 작성자와 디자이너가 어떻게 일을 시작할지 판단할 수 있는 수준으로 제작 요구사항을 정리한다. 사용 상황, 내용 범위와 사업상 사실을 반복해서 추측하는 일을 줄인다.

시작 조건: 프로젝트 책임자가 제작 목적, 소통 대상과 대략적인 범위를 정했다. 사용 가능한 기존 자료를 제공하고 사업상 사실을 확인해 줄 사람도 정한다. 이번 작업의 제출 기한, 투입 가능한 시간과 검수자는 별도로 합의한다.

주요 업무: 먼저 누가 자료를 보는지, 어디에서 사용하는지, 상대가 무엇을 이해하거나 어떤 행동을 하기를 바라는지 확인한다. 이어 사업 내용과 표현 요구사항을 정리한다. 핵심 설명의 출처를 확인하고, 의견 차이와 부족한 부분을 목록으로 만들어 권한이 있는 사람에게 확인을 요청한다.

산출물: 요구사항 확인서 한 부다. 최소한 사용 상황, 대상, 내용 범위, 주요 사업상 사실과 출처, 납품 규격, 확인된 사항, 미확인 사항과 각각의 책임자를 포함한다. 구체적인 기한, 확인 상태와 적용 버전은 이번 작업 기록에 남긴다.

권한과 협업: 협력자는 질문하고, 자료를 정리하고, 표현 방식을 제안할 수 있다. 사업 범위, 제품에 관한 약속, 가격이나 공개 시점은 해당 권한을 가진 사람이 확인한다. 정리자가 문서에 적었다는 이유만으로 아직 결정되지 않은 사항이 기업의 약속이 되어서는 안 된다.

검수와 인수: 검수자는 사실과 범위를 확인한다. 원고 작성·디자인 역할은 작업을 시작할 조건이 갖춰졌는지 살핀다. 부족한 자료가 일부 내용에만 영향을 준다면, 이미 확인된 부분 중 어디부터 시작할지 정할 수 있다. 전체 방향에 영향을 주는 문제라면 먼저 보완하거나 다시 결정한다. ‘파일을 제출했다’는 사실로 실제 사용 가능성에 대한 판단을 대신할 수는 없다.

예외 처리: 자료가 서로 모순되거나, 사용 상황이 달라지거나, 추가 요구가 범위를 넘으면 문제와 영향을 기록한다. 해당 책임자에게 보완, 조정, 일시 중단 또는 취소를 결정해 달라고 요청한다. 새로운 범위와 기한은 다시 확인해야 한다. 협력자가 먼저 개선을 제안할 수도 있지만, 실제 행동에는 적절한 권한과 조건이 갖춰져야 한다.

완료와 인계: 최종 확인서와 필요한 근거를 보관하고, 후속 담당자에게 미결 사항, 제약과 버전을 설명한다. 수행자가 바뀌면 미완료 작업, 파일 위치와 접근 권한 관련 사항을 인계한다.

이렇게 하면 참여자는 ‘요구사항 정리를 도와 달라’는 말만 듣는 것이 아니다. 자신에게 일을 맡을 조건이 있는지 판단할 수 있고, 시작한 뒤 어떻게 앞으로 진행할지도 알 수 있다.

6. 작업에 매뉴얼을 적용한 뒤에도 조정할 길을 남긴다

시작할 때 양측은 범위, 조건, 기한과 검수 방식을 확인한다. 수행 중에는 적용 가능한 버전에 따라 일하고, 부족한 점이 생기면 바로 알린다. 끝날 때는 산출물과 후속 담당자의 인수 상태를 확인한 뒤, 매뉴얼 자체의 문제를 관리 담당자에게 전달한다.

검수에 통과하지 못한 사항은 무엇을 보완하거나 다시 해야 하는지 적고, 완료 후 다시 검수한다. 의견이 갈리면 미리 정한 책임자나 재검토 역할이 처리한다. 일시 중단한 사항은 처리 대기 상태로 두고, 계속해야 할 때 조건을 다시 확인한다. 취소한 사항은 필요한 마무리를 한 뒤 끝낸다. 작은 팀에서는 한 사람이 여러 역할을 겸할 수 있다. 그래도 중요한 약속이나 이해충돌이 있는 사안은 실제 규칙에 따라 재검토하도록 해야 한다.

매뉴얼 개정에도 근거가 필요하다. 한 번의 특별한 처리는 우선 예외로 기록해 둘 수 있다. 같은 문제가 반복되거나 사업 조건이 달라지면 일반적인 방식을 바꿀지 결정한다. 새 버전에는 무엇을 바꿨는지, 어디에 적용하는지, 언제부터 시행하는지 적는다. 미완료 작업에 신구 버전을 어떻게 적용할지도 설명하고, 이전 버전은 나중에 확인할 수 있게 보관한다.

좌우로 스크롤하거나 큰 그림을 열어 확인하세요.

그림 2. 역할별 매뉴얼을 작업 수락, 수행, 검수와 피드백에 적용한다. 예외는 권한을 가진 사람이 결정하고, 필요할 때 검토 후 개정한다.
그림 2. 제안하는 운영 방식이다. 예외를 처리한 뒤 계속할 작업은 조건을 다시 확인해야 하며, 개정판은 시행을 확인해야 한다. 산출물의 적합성, 후속 작업에서의 사용 가능성, 사업 결과의 변화는 각각 관찰한다.

큰 그림 열기 ↗편집 가능한 SVG 다운로드 ↓

매뉴얼이 쓸모 있는지는 구체적인 질문부터 살펴보면 된다. 새 참여자가 어디서 시작할지 더 잘 아는가? 핵심 문제를 더 일찍 발견했는가? 설명과 재작업이 줄었는가? 후속 담당자가 더 쉽게 인수할 수 있는가? 시험 적용 전후에는 비슷한 작업의 범위, 복잡성과 담당자 경험을 가능한 한 기록한다. 작업이 쉬워졌거나 사람이 더 숙련된 것도 결과에 영향을 줄 수 있다. 모든 개선을 매뉴얼 덕분이라고 해서는 안 된다.

매뉴얼에는 산출물과 기여 기록에 어떤 근거를 남겨야 하는지 정할 수 있다. 보수, 비용, 권리·이익과 그 조건은 실제 사업의 계약과 제도에 따라 별도로 확인한다. ‘매뉴얼에 따른 작업을 마쳤다’는 사실에서 자동으로 도출되는 것은 아니다.[2]

AI는 적용할 내용을 찾고, 기존 자료를 정리하고, 확인서 초안을 작성하거나 매뉴얼을 바탕으로 빠진 부분을 짚는 일을 도울 수 있다. 그래도 사실을 누가 확인하는지, 어떤 사항을 결정할 수 있는지, 결과를 누구에게 넘길지는 명확해야 한다. 재사용 가능한 단계를 실행 지침인 Skill로 정리하려면 적용 범위, 입력과 출력, 사람이 판단해야 하는 경계도 분명히 해야 한다.

지금 설명을 반복해야 하는 역할 하나를 고른다. 실제 작업 하나를 놓고 목적, 조건, 업무, 권한과 산출물을 적는다. 다음에 적합한 참여자가 써 보게 하고, 그가 부딪힌 문제를 바탕으로 수정하면 매뉴얼을 실제로 쓰기 시작할 수 있다.

근거와 선택해서 읽을 자료

[1] 초기 연구 자료인 『SOP 정리·설계 방법론』(원문 제목: 《SOP梳理设计方法论》). 주로 3~4쪽의 직무·책임과 업무 매뉴얼 관계, 6~9쪽의 문서 내용, 직무 조사, 시험 적용과 개선을 참고했다. 원자료 끝에는 2023년 버전 및 협업 기록이 남아 있다. 이 글의 생태계 공동 기여 역할, 역할과 작업의 구분, 시험 적용 제안은 그 자료를 바탕으로 이번에 발전시킨 내용이다. 과거의 직무·책임 및 흐름 연구 도표 두 장은 기존 관계를 파악하는 데만 사용했으며, 당시의 평가나 권리·이익 배분 방식을 그대로 적용하지 않았다.

[2] 『네 생태계 거버넌스 모델: 기여, 권리·이익과 협업의 순환』(중국어)은 참여 관계, 기여와 권리·이익, 사안별 권한을 다룬다. 이 글은 역할별 매뉴얼로 일을 어떻게 조직할지를 더 구체적으로 살펴보며, 공통 배분 방식을 미리 정하지 않는다.

『기업 계획 10단계: 방향, 자원과 실행을 연결하기』(중국어)는 사업 목표와 협업 조건을 이해하는 데 참고할 수 있다. 『한 번의 거래가 끝난 뒤, 기업에는 무엇이 남을 수 있을까?』(중국어)는 경험이 후속 업무에 어떻게 쓰이는지 더 살펴보는 자료다.

이 글은 실제 적용을 통해 검증해야 할 방법 설계다. 여러 기업에서의 효과를 검증한 결과는 제시하지 않는다. 도표와 가정한 예시는 작동 방식을 설명하기 위한 것이다.

본문 끝

실제 업무에서 매뉴얼을 시험해 책임, 업무가 시작되는 경로, 산출물 조건을 확인하고 피드백에 따라 수정합니다.

CONNECTED READING

문서 연결

참조 문서를 따라가며 이 글을 더 깊이 이해해 보세요.

공개된 본문의 사이트 내 링크를 바탕으로 자동 생성합니다.

CONNECTED READING

문서 관계도

드래그하여 관계도를 이동하고 버튼으로 확대·축소하세요. 노드를 선택하면 문서를 읽을 수 있습니다.

현재 문서 · 직무·책임 분석에서 역할별 업무 매뉴얼로: 참여자가 어떻게 기여할지 알 수 있게 하려면
100%
직무·책임 분석에서 역할별 업무 매뉴얼로: 참여자가 어떻게 기여할지 알 수 있게 하려면현재 문서 · 싱크탱크직무·책임 분석에서 역할별 업무매뉴얼로: 참여자가 어떻게 기여할지 알 수 있게 하려면4계층 SOP 활용법: 성과에서 업무·인재·매일의 작업까지 정리하기싱크탱크4계층 SOP 활용법: 성과에서 업무·인재·매일의 작업까지 정리하기직무 책임·프로세스·사람과 AI 협업 모델싱크탱크직무 책임·프로세스·사람과 AI 협업 모델거래가 끝난 뒤 기업에 무엇이 남을까?싱크탱크거래가 끝난 뒤 기업에 무엇이 남을까?기업 계획 10단계: 방향과 자원, 실행을 연결하기싱크탱크기업 계획 10단계: 방향과 자원,실행을 연결하기4대 생태계 거버넌스 모델: 기여, 권리·이익, 협업의 순환싱크탱크4대 생태계 거버넌스 모델: 기여,권리·이익, 협업의 순환
현재 문서이 글을 참조한 문서이 글의 참조 문서

이 글 인용하기

저자
Andrew David W.Y.
공개일
2026-11-04
정리·수정일
2026-11-04
버전
R1

Andrew David W.Y. (2026-11-04). 직무·책임 분석에서 역할별 업무 매뉴얼로: 참여자가 어떻게 기여할지 알 수 있게 하려면 · R1. https://yutengfei.com/ko/journal/co-builder-role-handbook/

고유 링크 ↗

같은 질문을 이어서 읽기

SEARCH