에이전트는 가설을 생산한다 — Agentic Workflow와 지식 시스템의 검증 문제

요약

Agentic Workflow가 팀에 도입되면 개인의 생산성은 각자 다른 방식으로 증가한다. 이것이 왜 운영 문제가 되는지를 흔히 속도 비대칭이나 언어 분화로 설명한다. 그런데 더 근본적인 층위가 있다. Knowledge System의 관점에서 보면, 에이전트는 가설을 생산한다. 가설이 지식이 되려면 실데이터로 검증돼야 한다. 검증되지 않은 가설은, 아무리 많이 쌓여도, 발산할 뿐이다. 그리고 사람이 읽지 못하는 문서는 — 에이전트가 수행 가능하더라도 — 이 Knowledge System 안에서 여전히 암묵지다.

1. 생산성의 문제가 아니라 지식 시스템의 문제다

Agentic Workflow를 도입한 팀을 관찰하면 이상한 패턴이 보인다.

각자의 생산성은 올라간다. 문서가 빨리 나온다. 파이프라인이 만들어진다. 분석이 자동화된다. 산출량의 총량은 분명히 늘어난다. 그런데 팀이 함께 무언가를 운영하는 순간 — 결정을 내려야 하는 순간, 인수인계를 해야 하는 순간, 결과물을 검토해야 하는 순간 — 예상치 못한 벽이 나타난다.

이것을 속도의 문제, 프로세스의 문제, 소통의 문제라고 진단하면 부분적으로는 맞다. 하지만 진단이 얕다.

더 깊은 곳에서 일어나는 일은 이것이다. 에이전트가 만든 출력물이 지식 시스템 안으로 진입하지 못하고 있다. 산출량은 늘어났지만 지식은 늘어나지 않았다. 가설이 쌓였지만 검증되지 않았다.

2. 지식 시스템에서 가설과 지식의 경계

Knowledge System의 관점에서 가설과 지식은 다르다.

가설은 "세계가 이러할 것이다"라는 명제다. 구조화될 수 있고, 문서화될 수 있고, 논리적으로 정합적일 수 있다. 에이전트는 가설을 매우 잘 생산한다. 방대한 데이터를 처리하고, 패턴을 찾고, 권고안을 만든다. 출력물은 그럴듯하고 매끄럽다.

그런데 가설이 지식이 되려면 한 가지가 필요하다. 실데이터로 검증되는 것. 가설이 현실과 접촉해야 한다. 사람이 그것을 읽고, 판단하고, 실제 상황에 적용해보고, 그 결과가 다시 돌아오는 루프가 돌아야 한다.

물리적으로 검증되지 않은 가설 — 현실과 접촉하지 않은 모델링 — 은 아무리 쌓아도 발산에 지나지 않는다. 각각의 가설이 내부적으로는 정합적이어도, 서로 다른 전제와 프레이밍 위에 세워진 가설들은 공통의 지식으로 수렴하지 않는다. 더 많이 만들수록 방향이 더 많아진다. 그것이 발산이다.

3. 사람이 읽지 못하는 문서는 암묵지다

암묵지는 전통적으로 "언어로 표현되지 않은 지식"으로 정의된다. 자전거 타는 법을 아는데 설명할 수 없는 것. 그런데 Agentic Workflow 환경에서는 이 정의를 확장해야 한다.

사람이 읽지 못하는 문서는 암묵지다. 에이전트가 수행 가능하더라도.

문서가 존재한다. 에이전트는 그것을 참조하고 실행한다. 그런데 팀의 어떤 사람도 그 문서를 읽고 내용을 파악하거나 판단을 검토하지 않는다. 너무 길어서, 너무 기술적이어서, 너무 빠르게 만들어져서, 또는 단순히 아무도 시간이 없어서.

이 문서는 Knowledge System 안에서 기능적으로 암묵지와 동일하다. 개인(또는 에이전트)의 내부에 있는 지식이지만, 공유 지식 시스템으로 전이되지 않은 것. 물리적으로는 존재하지만 인식론적으로는 팀에 없는 것.

여기서 핵심적인 역설이 생긴다. Agentic Workflow는 암묵지를 문서화하는 것처럼 보인다. 에이전트가 과정을 기록하고, 판단 근거를 출력하고, 구조화된 결과물을 만든다. 그런데 그 문서를 사람이 읽지 않으면, 문서화는 일어났지만 지식 이전은 일어나지 않은 것이다. 형식은 명시지지만 기능은 암묵지.

4. 팀 안에서 가설이 발산하는 방식

사례로 들어가 보자.

사례 1: 검토 없이 통과된 PRD

한 기획자가 에이전트와 함께 PRD를 만든다. 사용자 인터뷰 데이터를 처리하고, 경쟁사 분석을 자동화하고, 기능 우선순위를 스코어링한다. 30페이지짜리 문서가 나온다. 잘 구조화되어 있고 논리적으로 정합적이다.

리뷰 회의에서 팀원들은 문서를 읽지 않은 채 권고안만 확인하고 승인한다. 문서 안에 담긴 전제 — 어떤 사용자 세그먼트를 우선했는지, 어떤 데이터 소스를 기반으로 스코어링했는지 — 는 검토되지 않는다.

개발이 시작된 뒤에야 전제가 틀렸다는 것이 드러난다. 에이전트가 처리한 인터뷰 데이터에는 특정 사용자 집단이 과대표집되어 있었다. 이 가설은 검증 없이 통과됐고, 이제 팀 전체가 그 가설 위에 쌓은 작업을 되돌려야 한다.

사례 2: 서로 다른 가설 위에서 열리는 회의

목적중심 팀의 주간 전략 회의. 기획자 A는 에이전트가 만든 경쟁사 분석 리포트를 기반으로 발언한다. 마케터 B는 자신이 에이전트로 돌린 시장 조사 결과를 기반으로 발언한다. 개발자 C는 에이전트가 생성한 기술 실현 가능성 평가를 기반으로 발언한다.

세 결과물은 각자 내부적으로 정합적이다. 그런데 서로 다른 데이터 소스, 서로 다른 시점, 서로 다른 프레이밍 위에 세워진 가설들이다. 회의는 진행되지만 수렴하지 않는다. 각자가 서로 다른 세계 모델을 갖고 있기 때문이다.

이것은 의견 차이가 아니다. 가설의 발산이다.

사례 3: 파이프라인이 실행되지만 아무도 읽지 않는 리포트

한 팀원이 리서치 파이프라인을 구축했다. 매일 아침 시장 변화, 경쟁사 동향, 고객 시그널을 자동으로 수집하고 요약한다. 15페이지짜리 리포트가 매일 생성된다.

세 달 뒤, 팀에서 이 리포트를 실제로 읽는 사람은 파이프라인을 만든 사람뿐이다. 팀은 그 존재를 알고 있지만 매일 읽기에는 너무 길다. 중요한 내용이 있을 수 있다는 것도 안다. 하지만 어느 날 아침 읽기 시작한 내용이 그날의 의사결정에 영향을 미쳤다는 경험이 없다.

파이프라인은 매일 가설을 생산한다. 그 가설들은 검증되지 않은 채 축적된다. 팀의 지식 시스템 안으로 진입하지 못한 가설들. 그것이 리포트의 실제 위상이다.

5. 개인 생산성이 팀 발산이 되는 구조

세 사례의 공통 구조는 이것이다.

에이전트는 개인의 가설 생산 속도를 높인다. 그런데 가설이 팀의 지식 시스템으로 진입하려면 인간의 검증을 통과해야 한다. 인간이 읽고, 판단하고, 실제 운영에 적용해야 한다. 이 검증 루프의 처리 속도는 에이전트의 생산 속도를 따라가지 못한다.

결과: 검증되지 않은 가설이 쌓인다. 각 개인의 에이전트가 서로 다른 방향으로 가설을 생산한다. 팀 수준에서 공유 세계 모델이 형성되지 않는다.

이것이 Agentic Workflow가 팀 안에서 만드는 발산의 메커니즘이다.

기능중심 조직이라면 이 발산이 일정 범위 내에서 억제된다. 같은 역할을 하는 사람들이 자연스럽게 같은 종류의 가설을 생산하고, 비공식적인 상호작용 — 짝 작업, 리뷰, 일상 대화 — 을 통해 가설을 맞춰간다. Nonaka & Takeuchi의 Socialization이 작동하는 구조다.

목적중심 조직에서는 이 억제 메커니즘이 약하다. 각자가 다른 종류의 가설을 생산하고, 그것을 맞춰갈 공유 언어와 공유 실천이 없다. Conway's Law가 여기서도 작동한다. 팀의 커뮤니케이션 경계가 가설의 수렴 범위를 결정한다. 경계를 넘는 검증이 일어나지 않으면, 경계를 넘는 지식도 형성되지 않는다.

6. 검증이 일어나는 조건

그렇다면 가설이 지식으로 전환되는 조건은 무엇인가.

세 가지가 필요하다.

인간 가독성. 문서가 사람이 읽을 수 있는 밀도와 형식이어야 한다. 논리적 완결성이 아니라 인간 처리 가능성이 기준이다. 아무리 정확한 가설도 읽히지 않으면 지식 시스템에 진입하지 못한다.

판단의 접촉. 결과물이 실제 의사결정과 접촉해야 한다. 회의에서 근거로 쓰이거나, 실행의 방향을 바꾸거나, 예측이 현실과 대조되는 루프가 있어야 한다. 참조됐지만 영향을 미치지 않은 결과물은 검증된 것이 아니다.

공유 기록. 가설이 어떻게 검증됐는지 — 또는 기각됐는지 — 가 팀이 접근할 수 있는 형태로 남아야 한다. 개인의 판단이 팀의 지식이 되려면 기록이 인터페이스가 되어야 한다.

이 세 조건은 에이전트 파이프라인 설계 안에 내재되어야 한다. 결과물의 길이와 형식을 인간 가독성 기준으로 제어하는 것. 결과물이 어느 의사결정에 연결되는지를 명시하는 것. 가설과 그 검증 이력이 팀이 읽을 수 있는 형태로 유통되는 것.

이것이 경계 객체(Boundary Object)의 설계다. 에이전트의 출력이 직접 지식이 되는 것이 아니라, 인간이 각자의 위치에서 읽고 판단을 투입할 수 있는 구조물을 통해 지식 시스템으로 진입하는 것.

7. 그래서 Grounding이 더 어렵다

여기까지 논의의 층위는 팀 안의 사람 간 지식 공유였다.

그런데 사실 그 이전에, 더 기초적인 층위에서 같은 종류의 문제가 반복된다. 사람과 에이전트 사이에서.

에이전트가 결과물을 만들 때, 그것은 에이전트가 세운 가설이다. 나의 의도를 에이전트가 어떻게 해석했는지, 어떤 전제를 채워 넣었는지, 어떤 가능성을 검토하고 어떤 가능성을 제거했는지 — 이것이 결과물 안에 있다. 그런데 나는 그것을 모두 읽지 못한다. 결과물만 보인다.

에이전트의 출력을 내가 검증하지 않은 채 다음 작업의 입력으로 넘기면, 나는 검증되지 않은 가설 위에 새 가설을 쌓는 것이다. 이 누적이 개인 수준에서의 발산이다.

사람 간 지식 공유가 어렵다는 것을 살펴봤다. 하지만 그보다 먼저, 사람과 에이전트 사이의 Grounding — 내 의도와 에이전트의 해석이 실제로 정렬되어 있는지를 확인하는 것 — 도 쉽지 않다. 이 Grounding이 작동하지 않으면, 팀 수준에서 공유해야 할 결과물 자체가 이미 검증되지 않은 가설일 수 있다.

다음에는 이 Grounding의 구조를 좀 더 깊이 들여다보려 한다. 사람-에이전트 간 지식 정렬이 어떤 방식으로 실패하는지, 어떻게 설계할 수 있는지. 그리고 그것을 기반으로, AI Native라는 개념 — 단순히 AI 도구를 사용하는 것이 아니라, 에이전트와의 지식 교환 자체를 업무 구조로 내재화하는 것 — 과 Agentic Workflow가 어떻게 연결되는지를 종합적으로 다뤄보려 한다.