대기업과 엔터프라이즈 환경에서의 에이전트 AI
Agentic AI in Big Tech and Enterprise
핵심 요약
대기업의 AI 도입은 생산성 향상보다 기존 조직의 비효율을 제거하는 과정이며, 속도와 유지보수성 사이의 전략적 선택이 핵심입니다.
- 생산성 착시 — AI 도입으로 인한 생산성 증가는 회의 감소 등 조직적 비효율 제거에서 기인함.
- 워크플로우 부재 — 도구만 제공할 뿐 실질적인 업무 적용 사례를 보여주지 못해 도입이 실패함.
- 엔지니어링 현실 — 코드 작성보다 아키텍처, 규정 준수, 테스트 등 복잡한 과정이 병목 현상을 유발함.
- 경제적 트레이드오프 — AI 에이전트는 비용 절감 효과가 크지만, 기술 부채와 유지보수성 저하라는 위험을 동반함.
면책 조항 - 이 글은 제가 쏟아낸 생각들을 바탕으로 AI가 다시 작성했습니다. 그럼에도 불구하고 영감을 주고 유용하다고 생각합니다. 대기업에서 연구 개발 팀을 운영하는 사람으로서 직접 겪은 경험입니다. 더 핵심을 찌르는 글로 수정해야 한다면 알려주세요 :D
긴 글 주의
배경을 설명하자면, 저는 생명과학 분야의 엔터프라이즈 소프트웨어 개발을 관리하고 있습니다. 거대 기업들을 위한 여러 프로젝트에 걸쳐 약 50명의 엔지니어를 관리하죠. 직원 10만 명 이상, 수십억 달러의 매출, 끝없는 규정 준수 요구 사항, 그리고 아무도 제대로 이해하지 못하는 복잡한 프로세스가 얽힌 그런 회사들입니다.
지금 이런 회사들 내부에서 벌어지는 일은 흥미롭습니다. 경영진은 AI가 무엇을 하는지 이해하는 그룹과, 이해한다고 착각하는 그룹으로 나뉩니다.
두 그룹은 같은 정리 해고와 생산성 보고서를 보고도 완전히 다른 결론을 내립니다.
현실은 대부분의 거대 기업이 AI 이전부터 이미 인력이 과잉 상태였다는 것입니다. 너무 많은 병렬 이니셔티브, 아무도 건드리고 싶어 하지 않는 레거시 소프트웨어, 수년 전부터 수익을 내지 못하는데도 유지되는 시스템을 가진 부서들이 너무 많습니다.
그래서 기업들은 오버헤드를 줄여 수백만 달러를 확보하고, 그 돈을 AI 전환 이니셔티브에 재투자합니다.
문제는 많은 임원들이 이제 소규모 팀에 AI를 더하면 자동으로 20~30%의 생산성 향상이 일어날 것이라고 생각한다는 점입니다. 실제로 팀 내부를 평가해보면, 생산성 향상은 주로 조정 오버헤드를 제거하는 데서 옵니다. 인원이 줄면 회의가 줄고, 충돌이 줄고, 대기 시간이 줄고, 승인 절차로 인한 마비가 줄어듭니다.
이런 개선은 AI 없이도 가능했을 일입니다.
물론 일부 엔지니어는 실제로 2~3배 빨라졌습니다. 하지만 그 후 재미있는 일이 벌어집니다. 사람들이 평소 업무를 더 빨리 끝내면, 그동안 시간이 없어서 미뤄뒀던 일들을 하기 시작합니다. 더 나은 문서화, 더 나은 테스트, 리팩토링, 검증, 정리 같은 것들 말이죠.
그래서 전체적인 처리량은 거의 변하지 않습니다. 대시보드 수치는 몇 퍼센트 정도 오르락내리락하고, 경영진은 소음 속에서 혁명을 환각하기 시작합니다.
저는 지난 1년 동안 Claude, Codex, Cursor, 에이전트 등 모든 것을 팀들이 도입하도록 도왔습니다.
가장 놀라운 점은 이 도구들이 무엇인지 실제로 이해하는 사람이 거의 없다는 것입니다.
평범한 직원에게 Claude를 주는 것은 아이에게 스마트폰을 주는 것과 같습니다. 버튼을 좀 누르다가 지루해지면 다시 기본으로 돌아가죠. 같은 기기를 유능한 사업가나 트레이더에게 주면 갑자기 무에서 유를 창조해냅니다.
대부분의 엔터프라이즈 AI 도입이 실패하는 이유는 기업들이 실제 워크플로우를 보여주지 않기 때문입니다.
모든 AI 타운홀 미팅은 똑같습니다.
"Productivity increased here"
"Claude helped there"
"Cursor accelerated development"
하지만 아무도 실제로 '어떻게' 하는지는 보여주지 않습니다.
아무도 실제 사례를 단계별로 설명해주지 않습니다.
직원들은 미팅을 나오며 이렇게 생각합니다.
"Cool story. Could’ve been an email."
최근 저는 비즈니스 컨설턴트 그룹에게 Claude를 활용해 컨설팅 제안서를 폴더에 넣고, 이를 다단계 연구 및 검증 파이프라인으로 바꾸는 방법을 보여주었습니다.
Extract claims.
Research supporting evidence.
Find contradictions.
Run another validation pass.
Rebuild the migration proposal with new findings.
이 모든 과정은 3개의 마크다운 파일과 하나의 긴 지시 프롬프트로 이루어졌습니다.
그들은 충격을 받았습니다.


