각자 빨라지면, 함께 느려진다 — Agentic Workflow와 운영 지식의 문제

요약

Agentic Workflow는 개인의 생산성을 높인다. 그런데 그 방식이 사람마다 다르다. 같은 팀이 서로 다른 속도로, 서로 다른 경로로 움직이기 시작하면, 결과물을 함께 운영하는 순간 예상치 못한 벽에 부딪힌다. 개인 생산성의 분화가 팀 운영의 병목이 되는 역설. 그리고 그 밑에는 지식 공유가 작동하지 않는다는 더 오래된 문제가 있다.

1. 같은 팀, 다른 속도

Agentic Workflow를 도입한 팀에서 이상한 일이 일어나기 시작한다.

A는 에이전트와 함께 기획 문서를 하루 만에 완성한다. B는 같은 분량을 사흘이 걸린다. C는 리서치 파이프라인을 만들어 주간 리포트를 매일 생성한다. D는 여전히 수동으로 자료를 취합한다. 이것은 실력 차이가 아니다. 에이전틱 워크플로우를 어떻게, 얼마나 깊이 사용하느냐의 차이다.

처음엔 이것이 좋은 일처럼 보인다. 빠른 사람이 더 많이 한다. 팀 전체의 산출량이 늘어난다. 그런데 결과물을 함께 운영해야 하는 순간이 오면 다른 일이 벌어진다.

2. 사례 1 — 속도가 달라지면 리뷰가 쌓인다

한 제품팀의 이야기다.

시니어 기획자가 에이전틱 워크플로우를 도입했다. 에이전트와 함께 사용자 인터뷰 노트를 분석하고, 인사이트를 정리하고, PRD 초안을 만드는 데 걸리는 시간이 이전의 3분의 1이 됐다. 그는 같은 스프린트에 두 배의 기획 산출물을 내기 시작했다.

문제는 리뷰에서 생겼다.

팀의 리뷰 프로세스는 기획자 한 명이 PRD 하나를 완성하는 속도에 맞춰 설계되어 있었다. 리뷰어들은 두 배의 문서를 같은 시간에 검토해야 했다. 리뷰 품질이 떨어졌다. 일부는 검토 없이 통과됐다. 그 문서들이 개발로 넘어간 뒤에 문제가 발견됐다.

에이전트는 기획자의 생산 속도를 높였다. 하지만 팀의 운영 구조는 그 속도를 받아줄 수 없었다. 개인의 가속이 팀의 병목을 만들었다.

3. 사례 2 — 언어가 달라지면 회의가 어긋난다

한 콘텐츠팀의 이야기다.

팀원 중 한 명이 에이전트와 함께 콘텐츠 전략을 짜기 시작했다. 키워드 클러스터링, 토픽 맵, 경쟁사 분석을 에이전트가 구조화하고, 그 위에서 의사결정을 내리는 방식이었다. 주간 콘텐츠 기획 회의에 그가 가져오는 문서는 10페이지짜리 구조화된 분석 리포트였다.

다른 팀원들은 메모 수준의 아이디어 목록을 가져왔다.

회의가 어긋났다. 구조화된 리포트를 가져온 사람은 이미 여러 선택지를 검토하고 권고안을 만든 상태였다. 다른 사람들은 아직 아이디어 단계였다. 같은 주제를 논의하고 있었지만, 출발점 자체가 달랐다.

더 큰 문제는 그 리포트가 어떻게 만들어졌는지를 아무도 몰랐다는 것이다. 에이전트가 어떤 기준으로 클러스터링했는지, 어떤 전제가 분석에 들어갔는지. 결과물은 매끄러웠지만 과정은 블랙박스였다. 팀은 그 결과물을 검토할 수 없었다. 수용하거나 무시하거나, 둘 중 하나였다.

4. 사례 3 — 암묵지가 쌓이면 인수인계가 막힌다

한 운영팀의 이야기다.

팀에서 가장 에이전틱 워크플로우를 깊이 사용하는 사람이 퇴사했다. 그가 만든 에이전트 파이프라인은 남겨졌다. 어떻게 돌아가는지 문서는 없었다. 정확히는, 문서가 있었다. 그런데 그 문서를 읽어도 파이프라인을 운영할 수 없었다.

파이프라인이 잘 작동하는 이유는 문서에 적힌 것 때문이 아니었다. 그것을 만든 사람이 에이전트와 수백 번의 반복을 통해 익힌 감각 — 어느 지점에서 프롬프트를 바꿔야 하는지, 어느 출력이 신뢰할 수 없는지 — 이 파이프라인 안에 암묵적으로 내재되어 있었다.

그 감각이 팀에 전달되지 않은 채 사람만 떠났다. 파이프라인은 멈췄다.

이것은 단순한 문서화 실패가 아니다. 에이전틱 워크플로우의 핵심 역량이 암묵지의 형태로 개인에게 쌓이고, 팀에는 전달되지 않았다는 구조적 문제다.

5. 운영의 벽이 존재하는 이유

세 사례는 표면적으로 다르지만 같은 구조를 가진다.

Agentic Workflow는 개인의 생산 속도를 높인다. 그런데 결과물의 운영 — 리뷰, 의사결정, 인수인계, 재사용 — 은 팀이 담당한다. 개인의 생산 속도와 팀의 운영 속도 사이의 간격이 벌어지면, 그 간격이 병목이 된다.

여기에는 두 가지 층위가 있다.

첫 번째 층위: 결과물의 속도와 양의 비대칭. 에이전틱 워크플로우를 사용하는 사람의 산출량이 늘어나면, 그것을 받아야 하는 팀 구조가 따라오지 못한다. 이것은 프로세스 설계의 문제다.

두 번째 층위: 지식 전달의 단절. 에이전틱 워크플로우로 쌓이는 핵심 역량은 암묵지다. 어떻게 에이전트와 일하는지, 어느 판단이 결과를 결정하는지 — 이것들은 문서로 완전히 표현되지 않는다. Nonaka & Takeuchi의 SECI 모델로 보면, 이 암묵지는 공유 경험(Socialization)을 통해서만 전달된다. 그런데 Agentic Workflow는 대체로 혼자 하는 작업이다. Socialization이 발생할 자리가 없다.

목적중심 조직에서 이 문제는 더 심각하다. 기능중심 조직이라면 같은 역할을 하는 사람들끼리 자연스럽게 실천 커뮤니티(Community of Practice)를 형성하고, 암묵지가 공동체 안에서 흐른다. 하지만 다양한 배경이 섞인 목적중심 조직에서는 그 공동체 자체가 형성되지 않는다. 공유 언어가 없으면 비공식 대화도 일어나지 않는다. 그 경로가 막히면 암묵지는 개인에게 고립된다.

Conway's Law가 여기서도 작동한다. 각자가 서로 다른 에이전틱 워크플로우 패턴을 발전시키면, 그 패턴들이 서로 다른 방향으로 분화한다. 기능 경계가 Agentic Fluency의 경계로 복제된다. 통합이 어려워진다.

6. 무엇이 필요한가

이 문제를 해결하는 방법은 지식을 통일하는 것이 아니다.

모두가 같은 방식으로 에이전틱 워크플로우를 사용하게 만드는 것은 가능하지 않고, 효율적이지도 않다. 에이전틱 워크플로우의 강점은 오히려 개인의 작업 방식에 맞게 유연하게 적응할 수 있다는 데 있다. 그것을 표준화하면 강점이 사라진다.

필요한 것은 다른 방향이다.

Star & Griesemer의 경계 객체(Boundary Object) 개념이 여기서 유용하다. 서로 다른 커뮤니티가 합의 없이도 협력할 수 있게 해주는 구조물. 에이전틱 워크플로우 맥락에서 이것은 판단 과정이 가시화된 결과물, 표준화된 핸드오프 형식, 에이전트와의 대화에서 어떤 판단이 내려졌는지를 기록하는 트레이스다. 에이전틱 fluency가 높은 사람은 내부 구조를 읽고, 낮은 사람은 판단 근거를 읽는다. 동일한 객체가 두 독자에게 각자의 언어로 작동한다.

운영 구조 측면에서는 Skelton & Pais의 Enabling Team 모델이 현실적이다. 에이전틱 워크플로우를 깊이 이해하는 사람이 이해를 전달하려는 대신, 다른 팀의 역량 격차를 일시적으로 채우는 역할을 맡는 구조. 이해의 통일이 아니라 역할의 분업.

그러나 이것이 완전한 답은 아니다. 경계 객체를 잘 설계하려면 에이전틱 fluency가 필요하다. Enabling Team이 작동하려면 그 역할을 맡을 사람이 있어야 한다. 두 해결책 모두 에이전틱 fluency가 이미 충분한 누군가를 전제한다. 그 사람을 어떻게 키우고, 어떻게 조직 안에 위치시킬 것인가는 여전히 열린 질문이다.

7. 다음으로 넘어가기 전에

이 글에서 원래 함께 다루려던 것이 있다.

사람 간 지식 공유가 어렵다는 것을 살펴봤다. 그런데 사실 그 이전 단계에서도 같은 종류의 어려움이 있다. 사람과 에이전트 사이의 지식 정렬 — 내가 무엇을 원하는지를 에이전트가 이해하게 만드는 것, 에이전트가 생성한 것을 내가 올바르게 읽는 것. 이 Grounding 문제도 쉽지 않다.

에이전트는 내가 말하지 않은 의도를 모른다. 나는 에이전트가 어떤 전제로 그 결과를 만들었는지 모른다. 사람 간 지식 공유의 어려움이 조직 수준에서 발생하는 문제라면, 사람-에이전트 Grounding의 어려움은 작업 수준에서 매번 반복되는 문제다.

이 두 문제는 연결되어 있다. 사람-에이전트 Grounding이 잘 작동하지 않으면, 그 결과물을 팀에 공유하는 것은 더 어려워진다. 공유할 수 있는 것이 무엇인지조차 명확하지 않은 채로 결과물이 유통된다.

다음에는 이 Grounding 문제를 좀 더 깊이 들여다보고자 한다. 그리고 그것을 기반으로, AI Native라는 개념과 Agentic Workflow가 어떻게 연결되는지 — 단순히 도구를 잘 쓰는 것이 아니라, 에이전트와 함께 일하는 방식 자체가 업무의 구조를 어떻게 바꾸는지 — 를 종합적으로 다뤄보려 한다.