소프트웨어를 교체하지 말고, 재창조하세요

대부분의 기업은 소프트웨어 문제가 있는 것이 아닙니다. 그들은 '소프트웨어를 사용하는 방식'에 문제가 있습니다.

잠시 생각해 보세요. 귀사의 회사는 이미 데이터베이스(database), CRM, 재고 관리 시스템(inventory system), 내부 도구들의 집합체, 그리고 이 모든 것을 연결하는 몇 가지 API를 가지고 있을 것입니다. 여러분은 이러한 시스템을 구축하거나 구매하는 데 수년을 보냈습니다. 이 시스템들은 데이터를 보유하고, 워크플로우를 지원하며, 비즈니스가 움직이도록 유지합니다.

하지만 사람들은 여전히 대시보드를 클릭하고, 애플리케이션 간에 정보를 복사하고, 보고서를 작성하고, 동료들에게 자신이 기술적으로 접근할 수 있는 데이터를 뽑아달라고 요청하는 데 시간을 소비합니다.

좀 터무니없지 않나요?

만약 해답이 또 다른 소프트웨어 마이그레이션이나, 또 다른 값비싼 플랫폼, 혹은 팀이 배워야 할 또 다른 도구가 아니라면 어떨까요? 여러분이 이미 소유하고 있는 소프트웨어가 단순히 더 많은 것을 할 수 있다면 어떨까요?

이것이 바로 기존 소프트웨어를 교체하는 대신 재창조한다는 아이디어의 배경입니다.

끊임없이 소프트웨어를 교체하는 것의 숨겨진 비용

성장하는 기업들 사이에는 익숙한 패턴이 있습니다.

팀은 특정 문제를 해결하기 때문에 도구를 사용하기 시작합니다. 시간이 지나면서 비즈니스는 성장하고, 워크플로우는 더 복잡해지며, 그 도구는 제한적이라고 느껴지기 시작합니다. 누군가 더 강력한 플랫폼으로 전환할 것을 제안합니다.

그러면 프로젝트가 시작됩니다.

데이터를 마이그레이션해야 합니다. 통합(integration)을 다시 구축해야 합니다. 직원들은 교육을 받아야 합니다. 권한(permission)을 설정해야 합니다. 오래된 워크플로우는 재창조되어야 하며, 출시 직전 주까지 아무도 기억하지 못하는 기능이 항상 있습니다.

저는 비즈니스 기술에 대한 수많은 논의에서 이 패턴이 전개되는 것을 보았습니다. 교체는 모든 것을 단순화할 것이라고 되어 있지만, 전환 과정은 몇 달간의 추가 작업을 만들어냅니다.

그리고 때로는, 그 모든 노력 끝에도 불구하고, 새로운 소프트웨어는 또 다른 문제 세트를 도입합니다.

좌절스러운 점은 무엇일까요? 원래 시스템이 그 일을 처리하는 데 완벽하게 충분했을 수도 있다는 것입니다. 문제는 사람들이 그것과 어떻게 상호작용했는지에 있었습니다.

시스템을 교체하기 전에, 더 간단한 질문을 던져볼 가치가 있습니다: 현재 가지고 있는 시스템을 사용하기 더 쉽게 만들 수는 없을까?

이러한 질문은 또 다른 마이그레이션 프로젝트보다 훨씬 흥미로운 곳으로 이어질 수 있습니다.

당신의 소프트웨어는 이미 업무를 처리하는 방법을 알고 있다

작은 이커머스 회사를 가정해 봅시다.

이 회사의 팀은 주문 관리를 위해 MySQL 데이터베이스를 사용하고, 고객 지원을 위한 별도의 애플리케이션, 그리고 재고 확인을 위한 내부 API를 사용합니다. 모든 것이 작동합니다. 기술적으로는 말이죠.

고객이 주문에 대해 문의할 때, 직원은 주문 관리 시스템을 열어 주문 번호를 검색하고, 결제 상태를 확인한 다음, 재고로 전환했다가 고객 지원 애플리케이션으로 돌아와 답변을 작성합니다.

요청 하나. 세 개의 시스템. 몇 분의 시간 소요.

이것을 매일 수십 또는 수백 건의 요청에 곱하면, 상당한 양의 낭비되는 시간이 발생합니다.

이제 직원이 단순히 다음과 같이 질문한다고 상상해 보세요:

"4821번 주문은 어떻게 되어가고 있나요? 배송되었는지, 그리고 대체품 재고는 충분한가요?"

기존 시스템에 연결된 AI 에이전트가 관련 정보를 검색하고, 이를 결합하여 명확한 답변을 제공할 수 있습니다.

새로운 주문 관리 플랫폼은 필요 없습니다. 중복 데이터베이스도 없습니다. 직원에게 또 다른 복잡한 인터페이스를 가르칠 필요도 없습니다.

기반 소프트웨어는 제자리에 머무릅니다. 사람들이 그것과 상호작용하는 방식만 바뀝니다.

이것이 AI 기반 비즈니스 자동화에 주목할 만한 이유 중 하나입니다. AI를 별도의 목적지로 취급하기보다는, 기업이 이미 의존하고 있는 시스템을 다루는 실용적인 방법이 될 수 있습니다.

솔직히 말해서, 이것이야말로 비즈니스 AI에게 훨씬 더 유용한 방향으로 느껴집니다.

진정한 기회는 또 다른 챗봇이 아니다

우리는 질문에 답할 수는 있지만 실제로는 별로 할 수 없는 챗봇들을 많이 봐왔습니다.

당신은 특정한 것을 요청하는데, 그들은 스스로 하는 방법을 설명하는 단락을 제공합니다. 고맙긴 한가요?

진정으로 유용한 AI 에이전트는 단순한 대화형 인터페이스 이상의 것이 필요합니다. 실제 작업을 수행할 수 있는 도구에 대한 접근 권한과, 그것이 무엇을 할 수 있는지 결정하는 권한 및 안전장치가 필요합니다.

주간 판매 보고서가 필요한 재무 관리자를 상상해 보세요.

오늘날 그들은 스프레드시트를 내보내고, 데이터를 정리하고, 합계를 계산하고, 이전 주와 숫자를 비교하며, 경영진을 위한 요약을 준비할 수 있습니다.

회사의 데이터베이스에 연결된 AI 에이전트는 이 과정의 상당 부분을 처리할 수 있습니다. 관리자가 보고서를 요청하면, 에이전트가 적절한 기록을 검색하고, 결과를 계산하며, 읽기 쉬운 요약본을 반환합니다.

관리자는 여전히 그 결과를 검토하고 중요한 결정을 내립니다.

이것이 차이점입니다. AI는 단순히 사람들이 지침을 찾는 것을 돕는 것이 아닙니다. 일을 완료하도록 돕는 것입니다.

만약 기존 비즈니스 시스템과 연동되는 AI 에이전트를 탐색하고 있다면, 얼마나 자연스럽게 소통하는지에만 초점을 맞추지 마세요. 대신 그것들이 실제로 귀사의 도구와 상호작용할 수 있는지, 귀사의 권한을 존중하는지, 그리고 유용한 작업을 신뢰성 있게 완료할 수 있는지 물어보십시오.

대화는 단지 인터페이스일 뿐입니다. 진정한 가치는 그 이후에 일어나는 것에 있습니다.

더 똑똑하게 만들기 위해 모든 것을 재구축할 필요는 없습니다

고려해 볼 만한 또 다른 상황이 있습니다.

성장하는 물류 회사가 6년 동안 동일한 내부 운영 데이터베이스를 사용해 왔습니다. 특별히 예쁘지는 않고, 인터페이스도 구식처럼 느껴집니다. 하지만 작동합니다. 배차 담당자들은 모든 것이 어디에 있는지 알고 있고, 데이터는 신뢰할 수 있으며, 회사는 그 주변으로 프로세스를 구축했습니다.

경영진은 현대적인 운영 플랫폼을 구매하는 것을 고려합니다.

판매 시연은 환상적입니다. 새로운 대시보드는 아름답고, 보고 기능은 인상적이며, 모든 것이 더 쉬워 보입니다.

그러다가 누군가 실제 전환 비용을 계산합니다: 데이터 마이그레이션, 통합 개발, 직원 교육, 다운타임, 그리고 일상 운영을 방해할 위험성 말입니다.

갑자기 프로젝트는 덜 매력적으로 보입니다.

이제 다른 접근 방식을 상상해 보세요. 회사는 AI 에이전트를 기존 데이터베이스에 연결하고, 선택된 작업을 통제된 도구 세트를 통해 외부에 노출합니다.

배차 담당자는 여러 화면을 탐색할 필요 없이 어떤 배송이 지연되었는지 문의하거나, 미결 작업 요약을 요청하거나, 특정 경로에 대한 정보를 검색할 수 있습니다.

지원되는 작업의 경우, 에이전트는 적절한 권한 하에서 변경 사항을 시작할 수도 있습니다.

오래된 인터페이스가 하룻밤 사이에 사라질 필요는 없습니다. 데이터베이스도 이동할 필요가 없습니다. 비즈니스는 전체 조직을 뒤엎지 않으면서 더 편리한 작업 방식을 도입할 수 있습니다.

이것이 바로 기존 소프트웨어에 AI를 연결하는 것이 매우 흥미로운 접근 방식인 이유입니다. 모든 것을 교체해야 한다고 가정하기보다는, 이미 존재하는 기능을 활용하는 데 초점을 맞춥니다.

때로는 가장 스마트한 업그레이드가 완전한 재구축을 요구하지 않는 경우입니다.

하지만 AI에게 프로덕션 시스템에 접근 권한을 주는 것은 심각한 문제입니다

보통보다 더 많은 주의를 기울여야 할 부분에 대해 이야기해 봅시다.

AI 에이전트가 데이터베이스를 읽고, 고객 기록을 업데이트하거나, API를 통해 작업을 트리거할 수 있다면, 만약 그것이 실수했을 때는 어떻게 될까요?

지원 직원 한 명이 에이전트에게 중복된 고객 기록을 삭제하도록 요청한다고 상상해 보세요. 직원은 특정 기록 하나만을 의미하지만, 요청은 모호합니다. 설계가 미흡한 에이전트는 잘못된 기록을 선택하거나 아무도 의도하지 않은 결과를 초래하는 작업을 시도할 수 있습니다.

이는 사소한 불편함이 아닙니다. 프로덕션 환경에서는 실제 운영 문제가 될 수 있습니다.

해결책은 AI에게 무제한 접근 권한을 주고 최선을 바라는 것이 아닙니다. 또한, AI가 유용한 일을 하는 것을 반드시 막아야 하는 것도 아닙니다.

더 나은 접근 방식은 그것이 무엇을 할 수 있는지 주변에 명확한 경계를 구축하는 것입니다.

예를 들어:

• 읽기 권한 (Read permissions): 에이전트가 불필요한 쓰기 접근 권한을 부여받지 않고 필요한 정보를 검색할 수 있도록 합니다.
• 역할 기반 접근 (Role-based access): 사용자가 기존 역할이 허용하는 작업만 수행하도록 보장합니다.
• 인간 승인 (Human approval): 파괴적이거나 기타 민감한 작업을 수행하려면 권한 있는 사람의 승인을 받도록 요구합니다.
• 검증된 인자 (Validated arguments): 제안된 모든 작업이 유효한 입력을 사용하고 예상되는 스키마와 일치하는지 확인합니다.
• 실행 기록 (Execution records): 무엇이 요청되었는지, 에이전트가 무엇을 제안했는지, 어떤 검사가 실행되었는지, 그리고 실제로 무슨 일이 일어났는지를 추적합니다.

중요한 세부 사항은 안전 점검(safety checks)이 모델 자체의 추론 외부에서 발생해야 한다는 것입니다. AI에게 조심하라고 요청하는 것은 그 요청을 실행하는 소프트웨어에서 권한을 강제하는 것과는 다릅니다.

이것이 바로 secure AI workflow automation이 단순히 안심시키는 약속이 아니라 실제 접근 제어, 검증 및 책임성(accountability)을 중심으로 설계되어야 하는 이유입니다.

목표는 AI가 변경을 할 수 없게 만드는 것이 아닙니다. AI가 할 수 있는 변경이 적절하고, 승인되었으며, 추적 가능하도록 만드는 것입니다.

소프트웨어 재창조는 지루한 것부터 시작됩니다

AI 혁신을 극적인 무언가로 상상하는 경향이 있습니다. 한 회사가 에이전트 군단을 배치하고, 전체 부서를 자동화하며, 갑자기 두 배의 속도로 운영하게 되는 식입니다.

실제 발전은 보통 훨씬 덜 흥미롭게 보입니다.

단순히 하나의 질문에 답하기 위해 세 개의 애플리케이션을 확인할 필요가 없어지게 된 고객 지원팀에서 시작될 수도 있습니다.

또는 매주 금요일 오후마다 동일한 보고서를 작성하는 데 시간을 쓰는 것을 멈춘 운영 관리자에서 시작될 수도 있습니다.

혹은 모든 작은 요청에 대해 임시 스크립트를 작성하는 대신 일반 언어(plain language)를 사용하여 내부 서비스에 질의할 수 있게 된 개발자에서 시작될 수도 있습니다.

이러한 개선 사항들이 항상 인상적인 기조연설 발표 자료가 되는 것은 아닙니다. 하지만 시간과 반복 작업을 절약하고, 사람들이 실제로 주의를 기울여야 하는 결정에 집중할 수 있게 해줍니다.

저는 반복적이고, 합리적으로 잘 정의되어 있으며, 검증하기 쉬운 작업부터 시작할 것입니다.

예를 들어, 영업팀이 매일 아침 30분 동안 전날의 주문을 확인하고 요약 보고서를 준비한다고 가정해 봅시다. AI 에이전트는 데이터를 검색하고, 총계를 계산하며, 특이한 변화를 파악하고, 초안 보고서를 작성할 수 있습니다.

팀은 공유하기 전에 그 결과물을 검토합니다.

그 워크플로우가 신뢰할 만하다는 것이 입증되면, 더 복잡한 작업을 고려해 볼 수 있습니다. 어쩌면 에이전트가 내부 티켓을 생성하거나, 선택된 레코드를 업데이트하거나, 여러 연결된 시스템에 걸쳐 업무를 조정할 수도 있습니다.

작은 성공들이 자신감을 만듭니다. 또한 데이터가 어디서 지저분한지, 권한 설정이 어디서 불명확한지, 그리고 인간의 판단이 여전히 필수적인지를 보여줍니다.

그것만으로도 유용한 정보입니다. 첫 번째 실험이 완벽하지 않더라도 말이죠.

만약 목표가 일상적인 비즈니스 운영에 AI를 도입하는 것이라면, 모든 것을 한 번에 자동화할 필요는 없습니다. 짜증 나는 작업 하나를 찾아 눈에 띄게 더 쉽게 만드세요.

그리고 거기서부터 구축하세요.

기존 도구를 AI 기반 워크스페이스로 만들기

더 흥미로운 가능성 중 하나는 단일 대화형 인터페이스를 통해 여러 시스템을 연결하는 것입니다.

다음과 같이 질문한다고 상상해 보세요:

"어떤 주문이 지연되었고, 그 원인은 무엇이며, 어떤 고객에게 업데이트가 필요한가요?"

그 질문에 답하려면 주문 데이터베이스, 배송 API, 그리고 고객 지원 플랫폼의 정보가 필요할 수 있습니다.

전통적으로 직원은 각 시스템을 열어 정보를 모으고, 결과를 비교하고, 응답을 준비해야 했습니다.

적절하게 구성된 AI 에이전트는 이러한 조회 작업을 조정하고, 결과를 결합하며, 한 곳에 그 발견 사항들을 제시할 수 있습니다.

사용 가능한 통합 및 권한 설정에 따라, 고객 알림을 준비하거나 다음 단계를 추천할 수도 있습니다.

이것이 바로 API 및 데이터베이스에 연결된 AI 에이전트가 단순한 대화 인터페이스를 넘어설 수 있는 지점입니다. 이들은 자연어를 통해 통신하도록 설계되지 않았던 시스템 전반에서 작동하는 공통 방식을 제공할 수 있습니다.

물론, 이는 통합의 품질, 에이전트에게 제공되는 정보, 그리고 실행의 신뢰성에 달려 있습니다. 모든 워크플로우가 자동화되어야 하는 것은 아니며, 모든 시스템이 에이전트가 필요로 하는 작업을 노출하는 것도 아닙니다.

그럼에도 불구하고 잠재력은 매우 강력합니다.

직원들에게 모든 시스템의 인터페이스를 학습하도록 요구하는 대신, 필요한 기능을 더 간단한 방식으로 접근할 수 있도록 할 수 있습니다.

Caterfli의 사고방식

Caterfli에서 핵심 아이디어는 간단합니다. 기업들이 AI의 혜택을 누리기 위해 이미 의존하고 있는 소프트웨어를 교체할 필요가 없어야 한다는 것입니다.

Caterfli는 기존 데이터베이스, API 및 MCP 서버에 연결하여 사용 가능한 기능을 발견하고, 사람들이 자연어를 사용하여 상호작용할 수 있는 AI 에이전트 생성을 돕습니다.