AI 에이전트가 못 보는 회사의 숨은 규칙 썸네일

AI 에이전트가 못 보는 회사의 숨은 규칙

Harvard Business Review K. Sudhir How to Design Agentic Systems Around the Implicit Rules that Govern Your Company ↗

회사에는 운영체계가 둘 있습니다. 매뉴얼에 적힌 조직과, 직원이 말없이 메우는 암묵적 조직입니다. AI 에이전트는 앞의 것만 받습니다.

암묵적 조직은 세 가지를 합니다. 흩어진 일을 연결하고, 사람을 움직이게 하고, 이상할 때 멈추게 합니다. 에이전트에는 이 셋이 없습니다.

에이전트를 넣으면 그 판단층이 조용히 사라집니다. 정답은 덜 쓰기가 아니라, 보이지 않던 일을 먼저 지도로 그린 뒤 다시 설계하는 것입니다.

AI 에이전트에게 업무 매뉴얼을 통째로 넘기셨습니까?
정작 회사를 지탱해온 건, 매뉴얼 어디에도 없던 베테랑의 '왠지 이상한데'라는 망설임이었습니다.

한 자산가가 금융사에 전화해 상속인 정보를 바꿨습니다. AI 라우팅 에이전트가 정확히 분류했고, 운영팀이 처리했고, 안내 에이전트가 완료 문자를 보냈습니다. 모든 단계가 설계대로 돌아갔습니다.

그런데 담당 자문역이라면 달랐을 겁니다. 지난 분기 면담에서 그가 흘린 말, 상속 설계 이야기와 계좌 이전 질문을 기억했을 겁니다. 그건 어떤 CRM 칸에도 없는 신호였습니다. 자문역은 전화를 걸어 진짜 대화를 했을 겁니다.

한 달 뒤 그 고객은 경쟁사로 큰 계좌를 옮겼습니다. 아무도 잘못하지 않았습니다. 그런데 회사는 신호를 놓쳤습니다. 이 글은 그 '보이지 않던 일'을 다룹니다.

지난 2년간 기업은 '에이전트를 빨리 넣자'는 방향으로 움직였습니다. 같은 워크플로우를 더 빠르게 처리하는 일로 봤습니다.

HBR의 K. 수디르 교수는 그 전제를 뒤집습니다. 회사를 실제로 굴려온 건 매뉴얼이 아니라, 직원이 자동으로 메우던 암묵적 층이라는 것입니다. 사람을 에이전트로 바꾸면 처리 속도만 오르는 게 아닙니다. 그 보이지 않던 판단층이 함께 사라집니다. 그래서 처음으로, 한 번도 문서화된 적 없던 운영 논리가 눈에 보이게 됩니다.

40~80%
한 연구가 측정한 멀티 에이전트 시스템 실패율
10~15%
램프(Ramp)가 사람 판단으로 넘기는 예외 케이스 비율
2년
한 금융사 주니어가 심사 업무로 판단력을 기르던 견습 기간

첫째, 회사에는 운영체계가 둘 있습니다. 하나는 매뉴얼에 적힌 조직입니다. 워크플로우, 정책, 보고라인입니다. 에이전트를 설정하면 받는 게 바로 이것입니다. 다른 하나는 실제로 회사를 굴리는 암묵적 조직입니다. 무엇을 알아채고, 무엇을 신경 쓰고, 언제 멈출지를 정하는 불문율입니다. 매뉴얼은 무엇을 할지 알려주고, 암묵적 조직은 무엇을 살필지 알려줍니다.

수면 (보이는 경계) 문서화된 조직 매뉴얼 · 정책 · 워크플로우 → AI 에이전트가 받는 것 암묵적 조직 암묵지 · 동기 · 전문적 재량 ① 연결: 흩어진 일을 잇는다 ② 동기부여: 신경 쓰게 만든다 ③ 제약: 이상하면 멈춘다 → 에이전트에는 없는 것
회사를 빙산에 비유하면, 매뉴얼은 수면 위 일부입니다. 수면 아래의 암묵적 조직이 실제로 조직을 떠받칩니다. 에이전트는 수면 위만 보고 일합니다. 출처: Harvard Business Review (2026), K. Sudhir의 개념을 도식화

둘째, 암묵적 조직은 세 가지 일을 합니다. 연결합니다. 이상한 거래를 본 직원이 보고서 대신 동료에게 메시지를 보냅니다. 동기를 부여합니다. 직무기술서에 없어도, 문화가 관계 가치를 따지게 만듭니다. 제약합니다. 권한이 있어도 뭔가 이상하면 멈춥니다. 이 망설임에는 소프트웨어 API가 없습니다. 그런데 작은 오류가 위기로 번지는 걸 막는 게 바로 그 망설임입니다.

셋째, 이 층을 드러내는 질문은 세 개입니다. 사람들이 데이터에 없는데도 알아채는 것은 무엇입니까. 직무기술서 밖에서 신경 쓰는 것은 무엇입니까. 언제 속도를 늦춥니까. 이 답과 문서화된 절차 사이의 간격이, 에이전트에게 줘야 할 진짜 설계도입니다. 사람만 있는 회사에선 이 층이 보이지 않습니다. 사람이 자동으로 메우기 때문입니다.

넷째, 멀티 에이전트는 위험이 더 큽니다. 에이전트 여러 개가 시스템으로 엮이면, 공유된 역사도 사람의 책임감도 없습니다. 한 연구는 이런 시스템의 실패율을 40~80%로 봤습니다. 에어캐나다 챗봇은 없는 환불 정책을 지어내 말했고, 법원은 회사에 책임을 물렸습니다. 사람은 한 번에 하나씩 실수하고 돌아봅니다. 에이전트는 오류를 빠르게, 조용히 쌓습니다. 6개월 뒤 고객 유지율이 떨어진 걸 발견해도, 어느 에이전트도 단독 책임이 없습니다.

다섯째, 대응은 셋 중 하나입니다. 작동하는 건 하나뿐입니다. 수디르 교수는 기업의 대응을 셋으로 나눕니다. 아래 ①②③입니다. 앞의 둘은 맹점을 그대로 두거나 더 빠르게 만듭니다. 마지막만 작동합니다. 우리 조직이 지금 어디에 서 있는지부터 확인합니다.

① 끼워넣기 (실패): 에이전트를 기존 워크플로우에 그냥 투입합니다. 암묵적 조직이 알아서 적응하길 기대합니다. 결과는 진짜 업무의 반쪽만 기계 속도로 돌아갑니다.

② 순진한 재설계 (실패): 에이전트 성능에 맞춰 새로 짭니다. 단 토대가 여전히 문서화된 절차입니다. 같은 맹점을 더 빠르게 재생산합니다.

③ 정보에 입각한 재설계 (작동): 사람이 무엇을 알고, 무엇에 신경 쓰고, 언제 멈추는지부터 지도로 그립니다. 그 결과를 이루도록 워크플로우를 새로 짭니다. 원래 모습과 전혀 달라도 괜찮습니다.

램프(Ramp)가 세 번째 길을 걸었습니다. 비용 정책은 에이전트가 자동 집행하고, 판단이 필요한 10~15%만 사람에게 넘깁니다. 사람은 문지기가 아니라, 베테랑이 적지 않던 암묵적 규칙을 시스템에 가르치는 교사입니다. 그렇게 깨지기 쉬운 기억이 단단한 인프라가 됩니다.

1
자동화 전에 세 가지 질문을 던집니다.
그 업무를 하는 사람에게 직접 묻습니다. "데이터에 없는데 당신이 알아채는 건 뭔가요. 직무기술서 밖에서 신경 쓰는 건요. 언제 속도를 늦추나요." 세 답과 매뉴얼 사이의 간격이 에이전트 설계도입니다. (인터뷰 30분, A4 1장)
2
에이전트에 '망설임'을 설계로 넣습니다.
신뢰도 임계값, 이상 탐지, 에스컬레이션 규칙을 답니다. 단 이건 예상한 위험만 막습니다. 그래서 사람 검토는 임시방편이 아니라 상시 설계입니다. 에이전트 확신이 낮은 케이스로 검토자를 보내되, 평범한 케이스도 일부 섞어 '정상'의 감각을 지킵니다. (규칙 초안 1장)
3
견습 경로를 따로 설계합니다.
자동화 전에 묻습니다. "직원은 어떻게 시니어의 판단력을 익히나요." 답이 "이 업무를 해보면서"라면, 그 업무를 없애기 전에 대체 경로를 만듭니다. 주니어에게 AI 결정을 깨보게 하는 레드팀 순환이 한 방법입니다. (HR·팀장 회의 1건)

이 글은 미국 대기업과 전문직 사례 중심입니다. 금융사, 컨설팅, 소프트웨어 회사가 배경입니다. 한국 중소기업의 업무 구조와 인력 규모는 다릅니다. 방향만 읽고, 자기 조직의 데이터로 확인합니다.

'암묵적 조직'은 모든 일을 멈추라는 뜻이 아닙니다. 정보가 명확하고 규칙이 분명한 업무는 자동화가 맞습니다. 판단과 재량이 핵심인 업무에서만 이 경고가 큽니다. 둘을 구분하지 못하면 자동화 자체가 늦어집니다.

견습 붕괴는 천천히 옵니다. 주니어 업무를 자동화한 효과는 지금 좋게 보입니다. 그 비용은 10년 뒤 시니어 판단력의 공백으로 나타납니다. 지표에 안 잡힌다고 없는 위험이 아닙니다.

AI로 이기는 회사는 에이전트가 모든 걸 보는 회사가 아닙니다. 에이전트가 못 보는 것을 알아채고, 그 둘레로 조직을 다시 짜는 회사입니다.

경영진·COO 자동화 전에 '암묵적 조직 지도'를 그립니다. 세 가지 질문의 답과 매뉴얼의 간격을 설계 사양으로 삼습니다.
IT·기술 책임자 멀티 에이전트는 개별이 아니라 시스템으로 거버넌스합니다. 누구도 단독으로 책임지지 않는 결과를 누가 감시할지 정합니다.
사업부장·HR 견습 파이프라인을 의도적으로 재설계합니다. 판단력을 기르던 일을 없애기 전에 대체 학습 경로를 먼저 만듭니다.

암묵적 조직(implicit organization): 매뉴얼에 없지만 회사를 실제로 굴리는 불문율입니다. 암묵지, 동기, 전문적 재량으로 이뤄집니다.

전문적 재량(professional discretion): 권한이 있어도 뭔가 이상하면 멈추는 판단입니다. 작은 오류가 위기로 번지는 걸 막습니다.

멀티 에이전트 시스템: 여러 AI 에이전트가 서로 정보를 주고받으며 협업하는 구조입니다. 오류가 빠르게 쌓이면 실패율이 높아집니다.

휴먼 인 더 루프(human in the loop): 자동화 과정에 사람 검토를 끼워 넣는 설계입니다. 여기선 문지기가 아니라 시스템을 가르치는 교사 역할입니다.

  • Sudhir, K. (2026, June). How to Design Agentic Systems Around the Implicit Rules that Govern Your Company [Article]. Harvard Business Review. (원문 보기 ↗)
라운드테이블
B
블랙 · 중견기업 임원
저 자산가 고객 떠난 얘기, 남 일 같지 않아요. 우리도 베테랑이 그만두면서 '왜 이 고객을 특별히 챙겼는지' 아무도 모르게 된 적 있어요.
R
레드 · 저널리스트
근데 저 고객 사례, 기사도 '합성한 장면'이라고 밝혔잖아요. 실제 단일 사례가 아니라 만든 거예요. 그걸로 결론까지 끌고 가는 건 좀 봐야죠.
N
네이비 · 시니어 엔지니어
합성이긴 한데 멀티 에이전트 실패율 40~80%는 실제 연구예요. 장면은 예시고, 숫자가 본론이에요. 저는 그 숫자가 더 무서워요.
W
화이트 · 조직장
세 가지 질문 좋긴 한데, 막상 직원한테 "언제 속도 늦추냐" 물으면 "그냥 느낌이요" 그래요. 그걸 어떻게 사양으로 적어요.
B
블랙 · 중견기업 임원
"느낌"을 끝까지 캐물으면 패턴이 나와요. 금액이 평소보다 크다, 거래처가 처음 본 곳이다. 그게 바로 램프가 사람한테 넘기는 10~15%예요.
P
퍼플 · 마케터
그 '느낌'을 캐묻는 작업 자체가 우리 회사 자산이네요. 어차피 베테랑 나가면 사라질 거, 지금 받아 적어두는 게 남는 장사예요.
G
골드 · 창업자
견습 붕괴 얘기가 제일 와닿아요. 주니어 일 다 자동화했더니, 정작 5년 뒤 팀장 시킬 사람이 안 큰 거예요. 효율 챙기다 사람을 못 키웠어요.
W
화이트 · 조직장
그래서 레드팀 순환이 답일 수도 있겠어요. 주니어한테 단순 작업 대신 'AI 결정을 깨봐라' 시키면, 일은 줄이고 보는 눈은 키우니까요.
G
골드 · 창업자
맞아요. 10년 뒤 우리 회사 시니어 판단력은, 결국 지금 주니어한테 뭘 시키냐로 정해지는 거죠. 오늘의 선택이 그 답이에요.
_posts/2026-06-19-implicit-organization-ai-agents.md