101
10명 안팎 조직에서 전통적인 결재 구조를 도입하면 어떤 일이 벌어질까요? 기안을 올리고, 승인을 기다리고, 결재가 나면 실행하는 방식 말입니다.
"대표님, 광고 문구 수정 완료했습니다. 확인 부탁드립니다."
이런 요청이 들어올 때마다 대표 입장에서는 미묘한 감정이 생깁니다. 이 정도 건까지 내가 봐야 하나 싶으면서도, 그냥 넘기기엔 불안합니다. 직원 입장도 마찬가지입니다. 사소한 건데 문서로 만들어야 하니, 구두로 30초면 끝날 일에 문서 작성으로 10분을 더 씁니다.
이런 일이 하루에 10건만 발생해도 하루 100분이 증발합니다. 한 달이면 약 30시간입니다. 직원 5명 조직이라면 월 150시간이 사라지는 셈이죠. 초기 단계 조직을 운영하는 대표라면, 이 수치가 낯설지 않을 겁니다.
핵심은 이겁니다. 중요한 결정과 일상적인 실행이 동일한 무게로 다뤄지고 있다는 점입니다. 소규모 조직에서 결재 서류 작성은, 우선순위가 될 수 없는데도 말이죠.
이런 환경에서는 누구나 동일한 방식으로 업무를 주고받을 수 있는 요청 시스템이 답입니다.
결재를 바라보는 관점이 문제입니다
소규모 조직에서 결재 시스템을 기대하는 것 자체가 잘못일 수 있습니다. 여기서 말하는 잘못은 시스템 자체가 아니라, 결재를 대하는 관점입니다.
많은 대표들이 업무 관리를 결재로 접근합니다. 직원이 기안하고, 대표가 승인하고, 승인 후 진행하고, 완료되면 보고하는 구조입니다. 이 방식은 수백 명 이상 조직에서는 작동합니다. 대표 혼자 모든 결정을 볼 수 없으니까요. 그래서 권한을 분산하고, 단계를 만들고, 책임 라인을 명확히 합니다. 결재 구조는 이런 환경에서 설계된 것입니다.
하지만 10명 미만 조직은 다릅니다. 대표가 최종 의사결정자인 경우가 대부분이고, 중간 결정권자는 실질적 권한이 없는 경우가 많습니다. 이런 구조에서 3단계 결재, 전결 기준, 결재 후 수정 불가 같은 룰을 가져오면 어떻게 될까요?
시스템이 속도를 막는 장애물이 됩니다.
대표 확인이 필요 없다는 말은 아닙니다. 중요한 건 확인받는 방식입니다. 기안-검토-결재라는 무거운 절차보다, 업무 단위로 빠르게 요청하고 피드백받는 구조가 소규모 조직에는 더 적합할 수 있습니다. 그래서 소규모 조직에서는 관점을 바꿔야 합니다. 결재가 아니라 업무요청으로. 이건 용어 변경이 아니라, 일하는 방식 자체를 바꾸는 겁니다.
결재에서 병목이 생긴다면, 그건 시스템이 아니에요.
무거운 결재 구조가 만드는 부담
전통적 결재 구조가 소규모 조직에 구체적으로 어떤 영향을 주는지 살펴보겠습니다.
부담 1. 결재를 위한 사전 작업이 증가합니다
결재 구조가 생기면 무슨 일이 벌어질까요? 일을 시작하기 전에 서류부터 작성해야 합니다. 왜 필요한지, 얼마나 걸릴지, 어떤 결과가 나올지 미리 적어야 합니다.
문제는 소규모 조직에서는 정확히 예측할 수 없는 일이 많다는 점입니다. 진행하면서 조정해야 하는데, 결재 서류에는 확정된 내용만 적어야 합니다. 그래서 직원은 결재 통과를 위해 실제보다 더 구체적으로 포장합니다.
결재가 필요할 때마다 증빙·사전 조율·양식 맞추기가 늘어나면 실행이 밀립니다. 특히 10명 미만 조직에서는 한 사람이 여러 역할을 동시에 맡기 때문에, 서류 작성에 쓰는 30분이 실제 업무 2시간 지연으로 연결될 수 있습니다.
부담 2. 대표도 직원도 감정이 소진됩니다
결재 구조가 있으면 직원은 "이 정도면 결재 올려야 하나?" 고민합니다. 사소한 건데 결재 올리면 일을 크게 만드는 것 같고, 안 올리면 나중에 문제 생기면 책임질까봐 불안합니다.
대표도 마찬가지입니다. "이런 것까지 결재를 올려?" 하면서도, 나중에 문제 생기면 "왜 미리 말 안 했어?"가 될 수 있으니 애매합니다.
이런 상황이 반복되면 서로 눈치를 봅니다. 직원은 대표 기분을 살피고, 대표는 직원이 제대로 하는지 의심합니다. 결재 라인 하나로 신뢰가 깎입니다.
부담 3. 빠르게 움직여야 할 순간에 멈춥니다
소규모 조직의 가장 큰 장점은 속도입니다. 의사결정이 빠르고, 실행도 빠릅니다. 그런데 결재 구조가 생기면 이 속도가 깨집니다.
급한 일이 생겼을 때 "일단 진행하고 나중에 보고하자"가 아니라 "일단 결재 올려야지"가 됩니다. 대표가 회의 중이거나 외근 중이면 일은 멈춥니다. 결재가 내려올 때까지 기다리는 동안 기회가 사라질 수도 있습니다.
물론 대기업에서는 이런 과정이 필요합니다. 조직이 크면 통제가 중요하니까요. 하지만 10명 미만 조직에서는 통제보다 실행 속도가 생존에 더 직결됩니다.
소규모 조직에 필요한 건, 공 던지듯 업무를 주고받는 가벼운 구조입니다
소규모 조직에서는 서로 업무를 편하게 주고받을 수 있는 구조를 만드는 것만으로도 앞서갈 수 있습니다. 왜일까요?
대표들이 원하는 '스스로 찾아 일하는 직원'을 만들려면, 대표가 직원에게, 직원이 대표에게, 직원들끼리 스스로 업무를 빠르게 주고받을 수 있는 구조가 필요합니다. 이게 없으면 결정권이 대표에게 있기에 대표가 병목 지점이 됩니다.
업무요청이라는 개념이 여기서 중요합니다. 이건 단순히 일 시키기가 아니라, 담당자를 명확히 하고, 마감일을 정하고, 완료 여부를 추적할 수 있는 단위로 업무를 주고받는 방식입니다.
업무요청 구조의 3가지 방향
1. 직원이 대표나 상사에게 요청 및 보고
"이 광고 소재 이렇게 수정하려고 합니다" 같은 보고를 업무요청으로 올립니다. 대표는 확인하고 피드백하면 됩니다.
2. 대표가 직원에게 업무를 지시
"이번 주 안에 고객사 제안서 초안 만들어줘" 같은 지시를 업무요청으로 남깁니다. 담당자, 마감일, 진행 상태가 한눈에 보이니 대표가 일일이 물어보지 않아도 됩니다.
3. 동료끼리 요청
마케터가 디자이너에게, 기획자가 개발자에게. 대표를 거치지 않고도 직원들끼리 업무를 주고받을 수 있습니다. 이렇게 되면 대표는 모든 업무의 병목 지점이 되지 않습니다.
실제로 공여사들 구성원들도 대기업, 공기업, 스타트업까지 크고 작은 규모의 조직을 거치며, ERP, 그룹웨어, 아사나 등 협업툴을 사용했습니다. 그런데 그런 경험을 거치면서 오히려 분명해진 게 있습니다. 소규모 조직의 일하는 방식은 대규모 조직과 다르고, 그에 맞는 업무요청 구조 역시 달라야 한다는 점입니다.
결재 구조가 아니라 Task 기반 업무 구조로
결재 구조로 업무관리를 대체할 수 있을 거라 기대한다면, 멈추고 task 기반으로 업무 구조를 만드는 걸 고려해볼 필요가 있습니다.
우리의 일은 작고 가볍고 빠르게 움직입니다. 대표나 결재권자 한 사람의 무게보다, 구조가 가져올 잠재력이나 파급력이 더 큽니다. 그러니 업무가 자유롭게 움직일 수 있게 task 기반으로 업무를 주고받는 요청 구조를 만들어보는 건 어떨까요? 사내 메신저로는 task를 기록할 수 없지만 업무요청 구조에서는 가능합니다.
지금 필요한 방식이 무엇인지 판단해야 합니다
아직도 워드로 주고받고 있나요? 출력해서 도장 찍고 있나요? 멈추고, 우리 눈앞에 놓인 하나의 문제를 해결하려면 필요한 방식이 뭔지 판단해볼 필요가 있습니다.
소규모 조직에서는 대규모 조직의 방식을 그대로 가져오는 게 답이 아닐 수 있습니다. 규모에 맞는 방식이 따로 있고, 단계에 맞는 구조가 따로 있습니다. 지금 우리 회사에 맞는 건 결재 중심 구조일까요, 아니면 업무요청 중심 구조일까요?
이 질문에 대한 답은 회사마다 다를 수 있습니다. 다만 10명 미만 조직이라면, 절차보다 실행 속도가, 승인보다 담당자가, 형식보다 맥락이 더 중요할 가능성이 높습니다. 그렇다면 그에 맞는 구조를 만드는 게 먼저일 겁니다.
공여사들이 만든 구조에서는 업무요청이 중심에 있습니다. 대표도 직원도 이 방식으로 일을 주고받고, 진행 상황을 확인하고, 완료 처리를 합니다. 결재가 필요한 건 별도로 구분해서 처리합니다. 이렇게 구분하니까 일이 막히지 않고 굴러갑니다.
지금 회사의 일하는 방식에 답답함을 느낀다면, 문제는 사람이 아니라 구조일 수 있습니다. 결재 구조를 도입하기 전에, 업무요청 구조부터 도입해보는 건 어떨까요? 그게 소규모 조직에 맞는 첫 단계일 수 있습니다.
대표님들이 함께 많이 본 콘텐츠
결재 없이 일하는 구조가 되어도 사람을 늘리면 새로운 문제가 생기곤 합니다. 좋은 인재 없나만 고민했던 대표님이라면 이 글 읽고 구조 먼저 설계해보세요.
작은 회사의 노션 시스템은 어때야 할까? 점검 포인트 3가지
업무요청을 넘어 작은 회사에서 어떻게 노션을 구조화해야 하는지 구체적 방법을 제시합니다. 글을 읽으면 시스템에서 아주 사소한 설계 차이가 큰 생산성 차이를 가져옴을 알게 되실 겁니다.
© 공여사들. '일의 구조'를 만듭니다.
0
0