Field note · 2026-04-23

관행은 사람을 위한 룰이었다 — AI-Native 전환에서 어긋나는 세 가지 지식

기획자가 에이전트로 시장 분석을 마쳤다. 한 시간. 예전이라면 사흘이 걸리던 작업이었다. 결과물을 결재 라인에 올렸다. 팀장이 다음 주 정기 회의에서 검토하기로 했다. 그 사이 시장이 움직였다. 이 장면이 낯설지 않다면, 지금 많은 조직에서 일어나고 있는 일이기 때문이다. 결재 프로세스가 느린 게 아니다. 에이전트가 그

관행은 사람을 위한 룰이었다 — AI-Native 전환에서 어긋나는 세 가지 지식


회의실에서 시작된 어긋남

기획자가 에이전트로 시장 분석을 마쳤다. 한 시간. 예전이라면 사흘이 걸리던 작업이었다. 결과물을 결재 라인에 올렸다. 팀장이 다음 주 정기 회의에서 검토하기로 했다. 그 사이 시장이 움직였다.

이 장면이 낯설지 않다면, 지금 많은 조직에서 일어나고 있는 일이기 때문이다. 결재 프로세스가 느린 게 아니다. 에이전트가 그 프로세스를 설계할 때 전제했던 시간을 압축했다. 관행은 사람의 속도를 전제로 만들어졌고, AI-Native 전환은 그 전제를 해제한다.

그런데 관행을 버리면 되는가. 그렇게 단순하지 않다. 관행은 단순한 비효율이 아니었다. 사람들의 지식이 전달되고, 맥락이 공유되고, 판단이 조율되는 구조였다. 그것이 무너지는 자리에서 무엇을 잃는지를 먼저 봐야 한다.


기능조직이 잘 한 것 — 그리고 목적조직이 치르던 비용

기능중심 조직의 프로세스는 느리지 않다. 아니, 느리게 보이지만 실제로는 다른 일을 하고 있다.

같은 전문성을 가진 사람들이 모인 기능조직에서 프로세스는 암묵지의 통로다. 법무팀이 계약서를 여러 단계로 검토하는 방식은 규정이기 이전에 교육이다. 20년 경력 변호사가 "이 조항은 이 고객에게 절대 통하지 않는다"고 아는 이유가, 그 검토 과정을 수백 번 거치면서 몸에 새겨진 것이다. 신입이 그 과정을 밟으면 규정을 배우는 것이 아니라 판단 방식을 배운다. Nonaka & Takeuchi가 Socialization이라고 부른 것 — 공유 경험을 통한 암묵지 이전 — 이 프로세스 안에 내재되어 있다. Socialization이 작동하는 조건은 단순하다. 같은 문제를 같은 맥락에서 반복해서 마주하는 것. 기능조직의 일상 업무가 정확히 이 조건을 충족하며, 이것이 기능조직이 전문성을 저비용으로 전달할 수 있었던 이유다.

목적중심 조직은 다르다. 마케터, 개발자, 기획자가 한 팀에 있다. 각자의 언어가 다르고, 각자의 암묵지가 다르다. 이 팀의 프로세스는 암묵지를 전달하기 위해 설계된 것이 아니라, 이질적인 지식들이 충돌하지 않고 접촉하도록 하기 위해 설계된 것이다. 그래서 회의가 더 많고, 보고서가 더 길고, 승인 단계가 더 많다. Deloitte의 2025년 연구는 크로스펑셔널 팀이 AI에서 30% 더 높은 효율·혁신 성과를 낸다는 것을 확인했는데, 이 수치가 흥미로운 것은 정확히 그 팀들이 조율 비용이 가장 높은 구조이기 때문이다. 가장 비효율적으로 보이는 곳에서 가장 큰 가능성이 열린다.

AI-Native 전환은 이 두 구조 모두에서 균형을 깨뜨린다. 그리고 깨뜨리는 방식이 다르다. 기능조직에서는 암묵지 통로인 프로세스가 에이전트 속도와 충돌하고, 목적중심 조직에서는 조율 구조 자체가 흔들린다. Colfer & Baldwin(2016)의 실증 분석에 따르면, 70%의 연구가 조직의 커뮤니케이션 경계가 시스템 설계 경계로 복제된다는 Conway의 명제를 지지한다. 에이전트도 예외가 아니다. 기능 사일로가 에이전틱 fluency 사일로로 복제되는 것은 규칙의 작동이지 예외적 현상이 아니다. 그리고 더 깊이 들어가면, 두 경우 모두에서 실제로 벌어지는 일은 같다. 세 가지 지식이 서로 다른 방향으로 분화하기 시작한다.


세 가지 지식 — 원래는 하나였던 것

AI-Native 업무로 전환한 팀에서 실제로 분화되는 것은 세 층위다.

사람의 지식은 경험과 판단의 축적이다. 이 시장에서 어떤 변수가 중요한지, 이 고객이 어떤 방식으로 반응하는지, 어떤 선택이 나중에 문제가 되는지. 말로 설명하기 어렵고, 함께 일하면서 전달된다. Polanyi(1966)의 표현을 빌리면, 우리는 말할 수 있는 것보다 더 많은 것을 안다. 이 지식은 천천히 쌓이고, 공유 경험 없이는 이전되지 않는다.

KnowledgeBase for Agent는 에이전트가 작동하는 데 필요한 구조화된 지식이다. 도메인 개념, 용어 정의, 업무 범위, 판단 기준. 에이전트가 일관되게 참조하려면 명시적이고 정합적이어야 한다. 모호함이 허용되지 않는다. 사람이 읽는 방식으로 쓰인 문서와 에이전트가 처리하는 방식으로 구조화된 문서는 형식이 다르다.

업무의 맥락은 지금 이 순간의 조건이다. 이 결정이 왜 지금 필요한지, 어떤 제약이 있는지, 어떤 이해관계자가 어떤 방향으로 기울어져 있는지. 어제의 맥락과 오늘의 맥락이 다르고, 다음 주는 또 다르다.

세 지식의 차이를 명확히 하면, 분화 이후 무엇이 달라지는지가 보인다.

지식 유형전달 조건이동 속도분화 시 증상
사람의 지식Socialization — 공유 경험 누적느림"역시 AI는 한계가 있다"는 오진. 실은 KB 미전환이 원인
KnowledgeBase for Agent명시화 + 구조화 작업중간일반적 답변만 반환. 도메인 편향이나 오류가 조용히 누적
업무의 맥락실시간 주입, 지속 갱신빠름논리는 맞는데 "뭔가 빠진 느낌". 방향이 팀과 어긋남

기존 관행은 이 셋을 하나의 흐름으로 처리했다. 회의는 맥락을 공유하는 자리이자, 사람의 지식이 발화되는 자리이자, KB가 구두로 전달되는 자리였다. 보고서는 맥락을 기록하고, 사람의 판단을 명시하고, KB를 문서화하는 기능을 동시에 수행했다. 이 통합이 느렸지만, 작동했다.


분화가 시작되는 지점

에이전트를 도입하면 이 통합이 해제된다. 정확히는, 세 가지 지식이 각각의 속도로 움직이기 시작하면서 간격이 생긴다.

기능조직에서 먼저 드러나는 문제는 KB의 공백이다. 에이전트가 접근할 수 있는 정보는 기술적으로 풍부하다. 데이터베이스가 있고, 문서가 있고, 과거 자료가 있다. 그런데 그 데이터가 실제로 전문성의 핵심을 담고 있는지는 별개의 문제다. 법무팀의 계약서 아카이브가 있어도, 20년 경력 변호사가 특정 고객에 대해 갖는 판단은 거기 없다. 에이전트는 일반적인 법무 지식으로 답하고, 팀은 그것을 수정하면서 "역시 AI는 한계가 있다"고 느낀다. 정확한 진단이 아니다. 한계가 있는 것은 AI가 아니라 사람의 지식이 KB로 전환되지 않은 상태다. 계약서 수백 건에 묻어 있는 판단의 패턴 — 어떤 조항이 어떤 고객 유형에서 문제가 됐는지, 어떤 언어가 어떤 반응을 유발했는지 — 이 아직 에이전트가 접근할 수 있는 형태로 추출되지 않은 것이다.

목적중심 조직에서는 다른 방식으로 문제가 생긴다. 각자가 에이전트를 각자의 방식으로 쓰기 시작한다. 마케터의 에이전트는 마케터의 맥락 위에서 작동하고, 개발자의 에이전트는 개발자의 맥락 위에서 작동한다. Conway의 명제가 여기서 다시 작동한다. 팀의 커뮤니케이션 경계가 에이전트의 지식 경계로 복제된다. 기능 사일로가 에이전틱 fluency 사일로가 된다. 6개월 뒤 회의실에서 세 사람이 같은 단어를 쓰지만 다른 개념을 말하는 상황이 만들어진다. 각자의 에이전트가 각자의 언어로 각자의 결과물을 만들어왔기 때문이다.

그리고 이 두 경우 모두에서 가장 조용하게 사라지는 것이 맥락이다. 맥락은 문서화하기 어렵다. "지금 이 결정이 왜 필요한지"는 슬랙 메시지 몇 줄과 복도에서 나눈 대화에 있다. 빠르게 움직이는 팀에서 이것을 에이전트에게 전달하는 사람은 없다. 에이전트는 어제의 맥락을 모른 채 오늘의 결과물을 만든다. 결과물은 논리적으로 정확하다. 그런데 팀이 그것을 읽으면 "뭔가 빠진 느낌"이 온다. 이 공백은 단일 결과물에서는 잘 보이지 않는다. 누적되면서 드러난다. 팀이 에이전트 결과물을 수정하는 빈도가 서서히 늘어나는 것으로, 또는 에이전트의 방향이 팀의 실제 방향과 점점 어긋나는 것으로.


분리하지 않고는 복원되지 않는다 — 두 팀의 이야기

결과물이 일정하지 않은 팀

콘텐츠 팀 하나의 이야기다. 에이전트 도입 석 달 뒤, 결과물의 품질이 일정하지 않다는 것을 팀이 인식했다. 좋을 때는 아주 좋고, 나쁠 때는 팀의 방향과 완전히 어긋났다. 들쭉날쭉함의 패턴을 확인해보니 공통점이 있었다. 캠페인이 전환되는 주, 이해관계자 방향이 바뀐 직후, 새 포맷을 실험하는 기간에 어긋남이 집중됐다. 맥락이 바뀐 시점이었다.

이 팀이 선택한 것은 프로세스 복원이 아니었다. 세 지식을 분리해서 다루는 것이었다.

첫 번째로 한 것은 판단 메모였다. 에이전트의 결과물을 검토할 때마다 "이건 왜 괜찮은가", "이건 왜 아닌가"를 한두 줄로 기록했다. 에이전트를 위한 피드백이 아니었다. 팀 안의 사람들이 왜 그렇게 판단하는지를 가시화하는 것이었다. 이것이 사람의 지식층이었다.

두 번째는 이 메모에서 반복되는 패턴을 추출하는 것이었다. 팀이 일관되게 좋다고 판단하는 것, 일관되게 아니라고 판단하는 것. 이것을 에이전트가 참조하는 별도 문서로 만들었다. 판단 메모와는 형식이 달랐다. 에이전트가 모호함 없이 참조할 수 있도록 구조화된 KB였다.

세 번째는 맥락 주입 루틴이었다. 스프린트가 시작될 때, 이번 주 어떤 캠페인이 진행 중인지, 어떤 방향으로 피봇하고 있는지를 2-3문장으로 에이전트에게 주입했다. 매주 갱신했다. 일회성 문서가 아니라 지속적으로 업데이트되는 맥락 레이어였다.

세 달 뒤 팀의 평가는 단순했다. 에이전트 결과물이 팀 방향과 일치하는 빈도가 올라갔고, "뭔가 빠진 느낌"이 줄었다. 기존 관행이 하나의 흐름으로 처리하던 것을 의식적으로 세 층위로 분리하여 각각을 설계한 결과였다.

전문성을 KnowledgeBase 없이 위임한 팀

계약 검토 기능을 가진 팀의 이야기다. 에이전트 도입 이후 검토 속도가 크게 빨라졌다. 그런데 석 달이 지나면서 패턴이 보였다. 에이전트가 제안하는 조항 수정 방향이 시니어의 판단과 다른 경우가 특정 고객 유형에서 집중적으로 발생했다. 진단은 명확했다. 에이전트는 일반적인 계약 패턴을 참조했지만, 특정 고객과의 관계에서 축적된 판단 기준이 KB에 없었다. 어떤 조항 표현이 이 고객과 어떤 이슈를 만들었는지, 어떤 협상 패턴이 반복됐는지 — 이 지식은 시니어 변호사의 경험 안에만 있었다.

대응은 구체적이었다. 과거 계약 협상 이력에서 반복 패턴을 추출하고, "이 고객 유형에서 쓰지 않는 표현", "이 조항 유형에서 우선 확인할 사항"을 KB 문서로 만들었다. 전문가의 암묵지를 완전히 명시화한 것이 아니었다. 에이전트가 일반 패턴 대신 이 팀의 특수 판단 기준을 참조할 수 있는 구조화된 입력을 만든 것이었다. 이것이 사람의 지식을 KB로 전환하는 실제 작업의 모습이다. 완전한 명시화가 아니라, 에이전트가 일반적으로 옳은 것과 이 맥락에서 옳은 것 사이의 차이를 접근할 수 있게 만드는 것.


관행이 묻던 질문을 다시 묻는다

관행이 무너지는 이유는 AI가 강해서가 아니다. 관행은 사람의 지식, 에이전트 KB, 업무 맥락을 하나의 흐름으로 통합하여 처리하는 구조였고, AI-Native 전환은 그 통합을 해제한다. 프로세스가 느려서가 아니라, 프로세스가 전제했던 통합이 더 이상 작동하지 않는다.

두 팀의 사례는 하나의 방향을 보여준다. 통합을 유지하려는 것이 아니라 세 지식을 분리하고 각각을 의식적으로 설계하는 것. 이것이 작동했다는 것은 분명하다. 그러나 분리가 곧 해결책은 아니다. 분리된 세 지식이 각각의 설계 안에서 움직이기 시작하면, 다음 질문이 나온다. 이 세 지식이 다시 하나의 방향으로 수렴하게 만드는 것은 누가, 어떻게 하는가.

관행이 느렸던 이유가 거기 있었다. 법무팀의 다단계 검토, 목적조직의 긴 회의 — 이것들은 비효율을 위해 설계된 것이 아니라, 사람들 사이의 지식 조율이 그 속도를 필요로 했다. AI-Native 전환으로 속도 문제는 해결됐지만, 그 속도가 담당하던 기능은 그대로 남아 있다. 분리 설계는 그 공백의 시작점을 명확히 한다. 그 이후의 질문 — 분리된 세 지식이 어떻게 다시 수렴하는가 — 은 아직 열려 있다.

그래서 관행에 대해 한 번 더 물어볼 차례다. 우리가 부딪혀온 그 관행은 정말로 개선할 방법이 없는가. 아니면 아직 그 중간지점을 찾지 못한 것인가. 에이전트의 속도와 사람들의 지식 조율이 공존하는 구조, 분리된 세 지식이 순환하며 수렴하는 구조 — 이것이 가능한가를 묻는 것이 다음 질문이다.


참고