AX 프로젝트를 하다 보면 기술적으로 꽤 괜찮은 아이디어를 들고 회의에 들어갈 때가 있다.
데이터를 연결하고, 반복 업무를 줄이고, 사람이 일일이 찾아보던 정보를 AI가 먼저 정리해서 보여준다. 과거 사례를 기반으로 후보 전략을 추천할 수도 있다.
설명을 마치면 회의 분위기도 나쁘지 않다.
“좋은 것 같습니다.”
“한번 해보시죠.”
큰 반대도 없다.
그런데 이상하게 그다음부터 일이 잘 진행되지 않는다.
데이터를 요청하면 생각보다 오래 걸리고, 담당자 인터뷰 일정을 잡는 것도 쉽지 않다. PoC를 만들어 테스트를 부탁해도 피드백이 거의 없다.
회의에서는 분명히 반대하지 않았는데, 실제 프로젝트에는 사람이 들어오지 않는다.
나는 몇 번의 AX 프로젝트를 거치면서 한 가지를 분명하게 느끼게 됐다.
AI 도입에서 가장 무서운 사람은 반대하는 사람이 아니라 아무 말도 하지 않는 사람일 수 있다.
반대하지 않는다고 동의한 것은 아니었다
명시적인 반발은 오히려 다루기 쉽다.
“AI가 틀리면 어떻게 합니까?”
“우리 업무는 그렇게 단순하지 않습니다.”
“실제 현업 프로세스를 모르셔서 그렇게 말씀하시는 것 같습니다.”
그 자리에서는 조금 불편할 수 있다.
하지만 이런 반응에는 큰 장점이 하나 있다.
적어도 상대방이 무엇을 걱정하는지 알 수 있다는 것이다.
문제는 아무 말도 하지 않는 경우다.
회의에서는 고개를 끄덕인다. 하지만 데이터를 적극적으로 제공하지 않는다.
테스트를 부탁하면 “시간 될 때 보겠습니다”라는 답이 돌아온다.
새 시스템이 만들어져도 기존 Excel이나 기존 방식으로 계속 업무를 처리한다.
겉으로는 프로젝트에 반대하지 않는다.
하지만 실제로는 프로젝트가 그 사람의 업무 안으로 들어가지 못한다.
나는 이런 상태를 ‘조용한 저항(Silent Resistance)’이라고 생각하게 됐다.
그리고 실제 프로젝트에서는 공개적인 반발보다 이런 조용한 저항이 훨씬 더 해결하기 어려웠다.
그런데 현업의 저항에는 꽤 합리적인 이유가 있다
AI 프로젝트를 추진하는 입장에서 가장 쉬운 설명은 이것이다.
“사람들은 변화를 싫어한다.”
하지만 실제 현업과 이야기를 해보면 그렇게 단순하지 않다.
오히려 그들은 새로운 시스템이 실패했을 때 어떤 일이 발생하는지를 매우 잘 알고 있다.
컨설턴트는 프로젝트가 끝나면 떠날 수도 있다.
개발자는 기능을 구현하고 다음 프로젝트로 이동할 수도 있다.
하지만 시스템의 결과가 틀렸을 때 고객에게 설명해야 하는 사람, 잘못된 판단을 수습해야 하는 사람, 업무 프로세스가 꼬였을 때 다시 정상화해야 하는 사람은 대부분 현업이다.
그러니 이런 질문이 나오는 것은 자연스럽다.
“결과가 맞지 않을 수도 있는데, 경영진이 이걸 믿기 시작하면 어떻게 하죠?”
나는 이 질문이 단순히 AI 정확도에 관한 질문은 아니라고 생각한다.
그 안에는 훨씬 복잡한 감정이 들어 있다.
AI가 틀린 결과를 낼 수 있다는 불안.
그 결과가 숫자나 Recommendation의 형태를 갖는 순간 오히려 더 강한 권위를 가질 수 있다는 불안.
그리고 언젠가는 자신이 해오던 판단 자체가 시스템으로 넘어가는 것이 아닌가 하는 두려움이다.
AI가 틀리는 것보다, AI가 ‘신뢰받는 것’이 더 두려울 수도 있다
가령 어떤 영업 시스템이 고객 데이터를 분석하고 다음과 같은 결과를 보여준다고 해보자.
Win Probability: 73%
Recommended Strategy: A
숫자가 화면에 표시되는 순간 그것은 묘한 힘을 가진다.
특히 경영진이나 의사결정자가 그 숫자를 신뢰하기 시작하면 현업 담당자의 입장에서는 새로운 문제가 생긴다.
현업은 알고 있을 수 있다.
“이 고객은 지금 숫자로 설명할 수 없는 상황이 있습니다.”
“담당 임원이 최근에 바뀌었습니다.”
“지난 프로젝트에서 문제가 있었기 때문에 이번에는 다른 접근을 해야 합니다.”
하지만 시스템의 결과는 73%라고 말하고 있다.
이 상황에서 현업 담당자가 느끼는 불편함은 단순히 “AI가 틀릴 수 있다”는 기술적인 우려가 아니다.
내가 알고 있는 맥락보다 시스템의 숫자가 더 신뢰받게 되는 것은 아닐까.
그리고 그 질문은 결국 더 본질적인 질문으로 이어진다.
“그렇다면 언젠가는 제가 하던 판단도 AI가 하는 것 아닙니까?”
이 질문을 단순한 변화 저항으로 취급해서는 안 된다고 생각한다.
암묵지는 단순히 ‘아직 수집하지 못한 데이터’가 아니다
Enterprise AI를 이야기하다 보면 자주 등장하는 단어가 있다.
Tacit Knowledge, 암묵지다.
문서에도 없고, CRM에도 없고, 공식 프로세스에도 기록되어 있지 않지만 실제 업무를 움직이는 지식이다.
예를 들어 문서에는 이렇게 적혀 있을 수 있다.
고객 요청을 확인하고, 검토하고, 승인한 뒤 대응한다.
하지만 실제 담당자는 전혀 다른 이야기를 한다.
“이 고객은 그 프로세스로 가면 안 됩니다.”
“이 유형은 팀장 승인 전에 법무부터 확인합니다.”
“시스템에는 이렇게 되어 있는데 실제로는 다르게 처리합니다.”
“그 사람에게는 메일보다 먼저 전화를 해야 합니다.”
이런 정보가 실제 업무를 움직인다.
그리고 나는 AX 프로젝트를 하면서 암묵지를 단순히 ‘추출해서 Knowledge Base에 넣어야 하는 데이터’로 생각하면 안 된다는 것을 느꼈다.
그 지식은 어떤 사람에게는 오랫동안 조직에서 자신의 가치를 만들어온 방식이기도 하기 때문이다.
누구에게 먼저 연락해야 하는지.
어떤 고객은 어떤 방식으로 설득해야 하는지.
공식 조직도와 실제 의사결정자가 어떻게 다른지.
어떤 제안은 가격보다 다른 요소가 중요한지.
이런 것들은 그 사람이 수년간 업무를 하면서 만들어온 전문성이다.
그리고 때로는 그것이 조직 안에서의 영향력이기도 하다.
따라서 “그 지식을 시스템에 넣어주세요”라는 요구는 현업의 입장에서는 전혀 다른 의미로 들릴 수도 있다.
“내가 알고 있는 것을 시스템에 다 넣고 나면, 그다음에는 나는 무엇으로 평가받게 되는가?”
나는 이 감정을 비합리적이라고 생각하지 않는다.
오히려 AX를 설계하는 사람이라면 먼저 인정해야 하는 현실에 가깝다고 본다.
그래서 그 자리에서 상대를 이기려고 하지 않는다
프로젝트를 하다 보면 이런 반론도 듣는다.
“데이터 자체가 틀린 게 많은데 AI가 무슨 제대로 된 판단을 합니까?”
기술적으로는 대답하기 어렵지 않다.
틀린 데이터가 들어가면 틀린 결과가 나오는 것은 너무 당연하다.
Garbage In, Garbage Out이다.
문제는 데이터 품질이지 AI 자체의 문제가 아니라고 바로 반박할 수도 있다.
그런데 나는 이런 상황에서 그 자리에서 논리적으로 상대를 설복시키는 것이 반드시 좋은 대응은 아니라고 생각하게 됐다.
왜냐하면 우리가 듣고 있는 문장이 그 사람이 실제로 걱정하고 있는 문제의 전부가 아닐 수도 있기 때문이다.
데이터 품질에 대한 질문처럼 보이지만 그 뒤에는 이런 생각이 있을 수도 있다.
“이 결과가 틀렸을 때 결국 내가 책임져야 하는 것 아닌가.”
“경영진이 AI 결과만 보고 판단하면 어떻게 하지.”
“결국 이 시스템은 우리를 줄이기 위한 것 아닌가.”
그 자리에서 GIGO를 설명한다고 이 질문들이 사라지지는 않는다.
오히려 충분한 설명의 기회를 다시 만드는 것이 중요하다.
어떤 데이터를 사용하는지.
어떤 데이터는 의도적으로 사용하지 않는지.
데이터가 부족하면 시스템이 어떻게 반응하는지.
AI가 어디까지 제안하고 사람이 어디에서 최종 판단하는지.
잘못된 결과가 발생하면 사람이 어떻게 수정하고 그것을 다시 시스템에 반영할 수 있는지.
나는 이것을 설득보다는 투명성을 높이는 과정에 가깝다고 생각한다.
모든 반론에 즉답하는 것이 좋은 답변은 아니다.
때로는 그 사람이 왜 그런 질문을 했는지 이해하는 것이 먼저다.
에이전트가 수많은 데이터를 본다고 인간의 판단을 대신할 수는 없다
AI Agent가 사람보다 많은 데이터를 볼 수 있다는 것은 사실이다.
사람이 수천 건의 과거 Deal을 모두 기억할 수는 없다.
경쟁사의 최근 움직임과 시장 뉴스, 고객 정보, 과거 제안서, Win/Loss 데이터까지 동시에 비교하는 것도 현실적으로 어렵다.
Agent에게는 이런 일이 가능해지고 있다.
하지만 그렇다고 해서 Agent가 인간의 판단을 완전히 대체할 수 있다는 이야기는 아니다.
특히 B2B 비즈니스에서는 더 그렇다.
나는 이런 이야기를 종종 한다.
“당신의 고객사 카운터파트가 에이전트로 대체되지 않은 이상, 당신의 판단도 완전히 에이전트로 대체되기는 어렵습니다.”
고객도 사람이다.
그 사람에게는 그 사람의 평가가 있고, 조직 내 이해관계가 있고, 예산 상황이 있고, 지금 그 순간의 분위기가 있다.
공식 조직도와 실제 영향력이 다를 수도 있다.
제안 내용 자체보다 누가 어떤 순서로 이야기했느냐가 더 중요할 때도 있다.
수많은 데이터를 읽은 Agent라 하더라도 이 모든 것을 완벽하게 수치로 환원하기는 어렵다.
그리고 바로 이 지점에서 현업의 경험과 암묵지는 여전히 중요한 역할을 한다.
그렇다고 인간의 감각만 믿고 일해도 된다는 뜻은 아니다
여기에서 한 가지 오해는 피해야 한다.
AI가 인간의 판단을 완전히 대체할 수 없다는 것과, 인간이 계속 자신의 감각만으로 판단해도 된다는 것은 전혀 다른 이야기다.
오히려 경쟁 방식은 이미 바뀌고 있다.
고객도 데이터를 본다.
경쟁사도 데이터를 본다.
과거에 어떤 제안이 이겼는지 분석하고, 어떤 고객에서 어떤 Offering이 효과적이었는지 확인한다.
유사한 Deal을 찾고, 경쟁 상황을 비교하고, 여러 가능성을 시뮬레이션한다.
그 결과 Win Probability가 높은 전략 후보 몇 개를 먼저 만들어 놓을 수 있다.
예를 들어 예전에는 사람이 머릿속에서 처음부터 세 가지 전략을 만들어야 했다면, 이제는 데이터와 AI가 가능성이 높은 후보를 먼저 좁혀줄 수 있다.
Strategy A.
Strategy B.
Strategy C.
사람이 할 일은 단순히 가장 높은 확률의 숫자를 선택하는 것이 아니다.
그 후보 위에 자신이 알고 있는 고객의 맥락과 관계, 타이밍과 감각을 다시 얹는 것이다.
나는 이것이 앞으로 현실적으로 가장 강한 형태의 의사결정이라고 생각한다.
Human vs. AI가 아니라, Human with better evidence다.
AX의 목적은 사람을 Decision Loop 밖으로 밀어내는 것이 아니다
그래서 좋은 AX의 목표는 사람을 제거하는 것이 되어서는 안 된다.
내가 보는 방향은 오히려 반대다.
사람이 판단하기 전에 해야 했던 반복적인 탐색과 비교, 정보 수집과 정리를 AI가 대신한다.
과거 Deal 수백 건에서 유사한 사례를 찾는다.
경쟁사 정보를 모은다.
가능한 전략을 비교한다.
놓쳤을 가능성이 있는 질문을 던진다.
그리고 그 결과를 사람이 본다.
여기에서 현업 담당자는 자신이 알고 있는 맥락을 추가한다.
“이 고객은 과거 사례와 다릅니다.”
“이번에는 가격보다 납기가 중요합니다.”
“저 담당자는 이런 접근에 반응하지 않습니다.”
그 순간 암묵지는 AI와 경쟁하는 정보가 아니라 AI가 만든 후보를 수정하는 정보가 된다.
현업의 질문도 조금씩 바뀐다.
“AI가 내 일을 하는 것 아닌가요?”
에서,
“그 조건도 넣으면 결과가 어떻게 바뀌나요?”
로.
나는 이 변화가 상당히 중요하다고 생각한다.
저항이 질문으로 바뀌고, 질문이 요구사항으로 바뀌는 순간부터 사용자는 시스템의 평가자가 아니라 공동 설계자가 된다.
그때부터 AX 프로젝트는 비로소 실제 현업의 모습을 닮아가기 시작한다.
그런데 여기에서 현실적인 문제가 하나 남았다
현업 담당자가 회의 중에 이야기한다.
“그러면 제가 말씀드린 이 조건까지 넣으면 결과가 어떻게 달라지는 건가요?”
컨설턴트는 답한다.
“가능합니다. 반영해서 다음 주 데모 때 보여드리겠습니다.”
예전에는 이 답이 자연스러웠다.
그런데 AX 프로젝트를 하면서 나는 이 ‘다음 주’가 생각보다 큰 문제라는 것을 느끼게 됐다.
지금 이 사람은 자신의 경험을 이야기했다.
지금 질문이 생겼다.
지금 자신이 가진 암묵지를 시스템에 넣어보려 하고 있다.
그런데 결과를 일주일 뒤에 보여준다면 그 대화는 이미 한번 끊어진다.
일주일 뒤에는 다른 업무가 생긴다.
왜 그 이야기를 했는지 기억이 흐려질 수도 있다.
PoC를 다시 보면서도 그것이 자신의 이야기에서 시작됐다는 느낌이 약해진다.
반대로 그 자리에서, 혹은 아주 짧은 시간 안에 결과를 다시 보여줄 수 있다면 상황은 달라진다.
“아니요. 제가 말한 것은 그게 아니라 이런 경우입니다.”
다시 수정한다.
“그러면 이렇게 하면 어떻습니까?”
또 다른 이야기가 나온다.
그리고 다시 바꾼다.
나는 어느 순간부터 PoC의 목적을 기술적으로 가능한지를 증명하는 것만으로 보지 않게 됐다.
PoC는 사람과 시스템 사이의 대화 도구에 더 가깝다.
그리고 중요한 것은 완성도가 아니라 그 대화가 끊어지지 않는 것이다.
그래서 내가 줄이고 싶었던 것은 단순한 개발 시간이 아니었다.
Feedback Latency.
현업이 이야기한 내용이 실제 동작으로 돌아오기까지 걸리는 시간이었다.
그래서 개발 환경 자체를 다시 보기 시작했다
문제는 내가 사용하는 환경이 하나가 아니라는 점이었다.
Salesforce가 있고, n8n이 있고, FastAPI와 Docker가 있고, 여러 API와 Git Repository가 있다.
AI에게 코드를 물어보고 결과를 복사해서 서버에 붙이고, 실행한 다음 로그를 다시 가져와 질문하고, 다시 수정하는 방식으로도 PoC를 만들 수 있다.
하지만 이렇게 하면 사람과 AI 사이의 속도는 빨라졌어도 AI와 실제 실행 환경 사이의 거리는 여전히 멀다.
그러던 중 이런 생각을 하게 됐다.
이미 내 개발 환경 안에는 Repository를 읽고, 코드를 수정하고, 명령을 실행하고, 테스트까지 수행할 수 있는 Codex CLI가 존재한다.
그렇다면 이것을 단순히 터미널에서 사람이 사용하는 Coding Assistant로만 볼 필요가 있을까.
“Codex CLI 자체를 내 Agentic Workflow에서 호출할 수 있는 하나의 실행 도구처럼 만들 수는 없을까?”
내가 원하는 것은 개발자를 없애는 완전 자율형 Agent가 아니었다.
현업과 대화하면서 나온 아이디어를 가능한 짧은 시간 안에 실제 동작으로 바꾸고, 다시 보여주고, 다시 수정할 수 있는 환경이었다.
결국 내가 만들고 싶었던 것은 코드를 빨리 만드는 시스템이라기보다 피드백을 빨리 돌리는 시스템에 가까웠다.
다음 글에서는 이 질문에서 시작해, 내가 Codex CLI를 기존 개발 환경과 연결하고 API 방식으로 호출 가능한 실행 도구처럼 만들기 시작한 과정을 정리해보려고 한다.
그리고 그 과정에서 더 중요했던 한 가지 원칙도 함께 다룰 생각이다.
Agent에게 얼마나 많은 자유를 줄 것인가가 아니라, 어디까지 자유를 주고 어디부터 결정론적으로 통제할 것인가.
빠른 PoC가 필요하다고 해서 통제를 포기할 수는 없기 때문이다.
다음 글
설명보다 빠른 PoC가 필요했다: Codex CLI를 내 AX 워크플로에 넣은 이유
Codex CLI를 단순한 Coding Assistant가 아니라 실행 가능한 Agentic Tool로 다루기 시작한 과정과, 이를 FastAPI·Git·Docker 기반 개발환경에 연결해 Feedback Latency를 줄이는 방법을 다룬다.