AI 에이전트가 부서를 넘나들며 일할 수 있다면, 회사에 기존 조직 구조가 여전히 필요할까

1. AI 어시스턴트에서 여러 단계의 일을 맡는 시스템으로

보조는 일을 하나씩 시켜 주기를 기다리지만, 직원은 목표를 받으면 끝까지 해냅니다. AI는 지금 보조에서 직원 쪽으로 옮겨 가는 중이고, 그래서 조직을 운영하는 방식도 함께 바뀌어야 합니다.

AI 어시스턴트는 사람이 시킬 때 질문에 답하거나 초안을 만듭니다. AI 에이전트는 목표를 받아 일련의 작업을 수행합니다. 요청을 읽고, 데이터를 확인하고, API를 호출하고, 문서를 만들고, 승인을 요청하고, 진행 상황을 챙기는 식입니다. 그러면 자동화의 단위가 "작업(Task) 하나"에서 "성과(Outcome) 하나"로 바뀌는데, 성과는 대개 여러 시스템과 부서에 걸쳐 있습니다.

2. 사일로 구조가 회사를 느리게 만드는 이유

견적서를 요청한 고객은 상세 내용은 영업팀에, 가격은 회계팀에, 납기는 생산팀에 있다는 사정에 관심이 없습니다. 언제 답을 받을 수 있는지만 궁금할 뿐입니다. 일이 다른 사람의 책상으로 넘어갈 때마다 어김없이 대기열이 하나 생깁니다.

부서는 전문성을 한데 모으려고 만든 조직입니다. 그런데 고객 업무의 워크플로는 조직도의 경계에서 멈추지 않습니다. 고객이 원하는 것은 견적서이고, 데이터는 영업팀에, 가격은 재무팀에, 납기는 운영팀에 있다는 사정은 고객이 알 바가 아닙니다. 인계(Handoff)가 한 번 일어날 때마다 대기열이 하나 늘고, 해석이 엇갈릴 여지와 정보가 빠질 가능성도 함께 커집니다.

에이전트가 데이터를 연결할 수 있게 되면, 이메일과 스프레드시트로 일을 넘기는 관행이 새로운 병목이 됩니다. AI가 몇 초 만에 답변을 준비해 놓고 승인자를 하루 동안 기다릴 수도 있고, 문서를 만들어도 사람이 손으로 시스템에 옮겨 적어야 할 수도 있습니다. 그래서 바꿔야 할 대상은 의사결정 권한(Decision Rights)과 워크플로 자체입니다. 기존 업무 프로세스 위에 에이전트를 얹는 것으로는 부족합니다.

그렇다고 부서를 모두 없애서는 안 됩니다. 전문성, 인재 육성, 직무별 전문 기준, 관리 감독은 여전히 필요합니다. 해법은 "Functional Home + Outcome Workflow" 모델입니다. 직원은 전문 분야별 부서에 소속을 두되, 일은 성과 책임자가 공통으로 정해진 업무 흐름을 따라 합니다.

3. 워크플로 중심으로 운영하는 조직

4. 에이전트형 조직(Agentic Organization)에서 사람이 하는 일

팀장은 대기열을 나누고 진행 상황을 챙기는 데 쓰던 시간을 줄이고, 그 시간을 예외의 원인 분석, 지식 베이스 보완, 처리 용량에 관한 결정에 씁니다. 현장 직원은 모호하고 영향이 큰 건을 맡게 됩니다. 그러니 에이전트가 하다 만 일을 맥락 없이 조각으로 넘겨받는 대신, 필요한 정보가 모두 담긴 요약과 함께 받아야 합니다.

중간 규모 회사라면 새 직책을 너무 많이 만들 필요는 없습니다. 한 사람이 여러 역할을 맡아도 되지만, 역할마다 범위를 분명히 적어 두어야 합니다. 특히 에이전트가 잘못된 데이터를 쓰거나 맡은 범위를 벗어나 움직였을 때 누가 책임지는지는 반드시 정해 두십시오.

5. 에이전트가 늘어나기 전에 컨트롤 플레인부터 갖추기

컨트롤 플레인(Control Plane)은 어떤 에이전트가 있는지, 각 에이전트의 스폰서는 누구인지, 어떤 모델을 쓰는지, 어떤 데이터와 도구에 접근하는지, 비용은 얼마인지, 성과는 어떤지를 한곳에서 파악하는 중앙 시스템입니다. 에이전트마다 고유 계정(Identity)을 주고, 최소 권한 원칙(Least Privilege)에 따라 꼭 필요한 권한만 주어야 합니다. 직원 계정을 같이 쓰게 해서는 안 됩니다.

모델, 데이터, 워크플로는 계속 바뀌므로 평가도 꾸준히 해야 합니다. 중요한 사례를 모아 두고 배포할 때마다 미리 시험하며, 운영 환경에서도 무작위로 점검하십시오. 품질이 떨어지면 오류가 쌓이게 두지 말고, 시스템이 자동으로 사람 검토 단계로 넘어가야 합니다.

6. 에이전트형 조직의 Lead-to-Cash 예시

사람은 중요한 지점에서 개입합니다. 영업 담당자는 모호한 고객 요구를 해석하고, 관리자는 할인을 승인하며, 재무팀은 위험한 고객을 점검합니다. 에이전트가 서로 맞지 않는 데이터를 발견하면 오류 메시지만 덩그러니 보내지 말고, 일을 멈춘 뒤 지금까지 파악한 내용과 결정이 필요한 사항을 정리해 넘겨야 합니다.

7. 혼란 없이 기존 부서 체계에서 벗어나는 방법

1. 가치 흐름 하나 고르기: 업무 흐름도를 그리고 성과 책임자(Outcome Owner)를 정합니다.
2. 공통 상태 정보 만들기: 진행 상황을 이메일이나 여러 버전의 파일로 주고받는 일을 그만둡니다.
3. 작업 나누기: 정해진 규칙대로 도는 자동화, AI의 판단, 사람의 결정을 서로 구분합니다.
4. 섀도 모드로 시험하기: 에이전트가 추천만 하고 실제 행동은 하지 않게 한 상태에서, 실제 팀의 결과와 비교합니다.
5. 권한은 한 단계씩 열기: 읽기부터 시작해 초안 작성으로 넘어가고, 쓰기나 발송은 표준적인 경우에 한해 맨 마지막에 허용합니다.
6. KPI와 역할 조정하기: 부서마다 자기 지표만 좋게 만들고 워크플로 전체는 느려지게 하는 지표는 없앱니다.

전환 기간에는 수작업 처리 절차와 장애 대응 책임자가 있어야 합니다. 기존 방식과 새 시스템을 끝없이 병행 운영하면 같은 일을 두 번 하게 되니 피하십시오. 새 시스템이 안정되고 업무가 몰리는 시기를 한 번 넘기면 옛 단계를 정리한다는 기준을 미리 정해 두십시오.

8. 경영진을 위한 도입 준비 점검표

빠진 항목이 여럿이라면 업무 프로세스와 데이터 기반부터 다지십시오. 에이전트 플랫폼을 먼저 사 놓고 기술이 조직의 불분명한 부분을 메워 주기를 기대하면 안 됩니다. 시스템은 모호함과 갈등을 예전보다 더 빨리 퍼뜨릴 뿐입니다.

요약: 에이전트는 부서 사이의 벽을 얇게 만들겠지만, 전문성과 책임이 필요하다는 사실은 그대로입니다. 앞으로의 조직은 Functional Home과 Outcome Workflow를 결합하고, 공통 상태 정보와 컨트롤 플레인을 갖춰야 합니다. 의사결정 권한과 데이터를 지금부터 설계하는 회사는 통제력을 잃지 않고 에이전트를 부서 간 업무에 쓸 수 있습니다.