AI에게 “이번 분기 목표 달성률을 계산해 줘”라고 해도 될까? 생성형 AI를 기업 업무에 적용하다 보면 자연스럽게 숫자를 묻게 됩니다. 예를 들어 다음과 같은 질문입니다. “이번 분기 목표 달성률은 얼마인가?” “실제로 수주 가능성이 높은 영업 파이프라인은 얼마인가?” “현재 손실 위험이 높은 프로젝트는 어디인가?” “조직별 가동률은 어떻게 되는가?” “지난달 대비 원가율이 얼마나 높아졌는가?” 생성형 AI는 이런 질문을 이해하고 자연스럽게 설명할 수 있습니다. 그렇다면 필요한 데이터를 모두 LLM에게 넘기고 계산까지 맡기면 되는 것일까요? 기업 업무에서는 조금 다르게 접근할 필요가 있습니다. 특히 매출, 원가, 손익, 목표 달성률, 가동률, 파이프라인처럼 중요한 경영 숫자는 단순한 산술문제가 아닙니다. 어떤 데이터를 사용할 것인지, 어느 시점을 기준으로 할 것인지, 어떤 항목을 포함하고 제외할 것인지, 어떤 계산식을 적용할 것인지가 함께 정의되

기업에는 데이터가 많은데 왜 AI는 회사 상황을 제대로 답하지 못할까? 기업에는 이미 많은 데이터가 있습니다. ERP에는 매출, 원가, 회계 데이터가 있고 CRM에는 고객과 영업기회가 있습니다. HR 시스템에는 조직과 인력 정보가 있고 PMS에는 프로젝트 일정과 진행상태가 있습니다. 문서시스템과 그룹웨어에는 보고서, 승인문서, 회의자료와 업무기록도 쌓여 있습니다. 그런데 생성형 AI에게 다음과 같이 물어보면 상황은 달라집니다. “이번 분기 목표 달성이 어려운 조직은 어디인가?” “실제로 믿을 수 있는 영업 파이프라인은 얼마인가?” “손실 위험이 높은 프로젝트는 무엇인가?” “프로젝트 종료 후 가용 가능성이 높은 인력은 누구인가?” 이 질문들은 한 시스템의 데이터를 검색하는 것만으로 답하기 어렵습니다. ERP의 숫자와 CRM의 영업상태를 연결해야 할 수도 있고, PMS의 프로젝트 일정과 HR의 투입인력을 함께 봐야 할 수도 있습니다. 여기에 회사

기업 AI를 검토하다 보면 왜 갑자기 ‘온톨로지’가 등장할까? 기업이 생성형 AI를 도입하기 시작하면 처음에는 대개 익숙한 기술부터 살펴봅니다. 사내 문서를 검색하고 싶으면 RAG를 검토하고 개념과 데이터의 관계를 연결하려면 Knowledge Graph라는 용어를 접하게 됩니다. 상품, 조직, 문서, 업무 유형을 분류하다 보면 Taxonomy가 등장합니다. 그리고 AI가 기업의 업무와 데이터까지 제대로 이해하게 만들려다 보면 결국 Ontology, 즉 온톨로지라는 개념을 만나게 됩니다. 문제는 이 네 가지가 비슷해 보인다는 것입니다. “온톨로지는 결국 잘 만든 분류표 아닌가?” “Knowledge Graph가 있으면 Ontology도 있는 것 아닌가?” “RAG에 문서를 많이 넣으면 굳이 온톨로지가 필요한가?” 이 질문에 답하려면 각각이 무엇을 하기 위한 구조인지부터 구분해야 합니다. 핵심부터 말하면 다음과 같습니다. Taxonomy는 ‘어떻게 분

U.STRA Light API Gateway, 복잡한 APIM 대신 필요한 연결만 가볍고 안전하게 API Gateway를 검토하는 기업이 늘고 있습니다. 그룹웨어, HR SaaS, ERP, CRM, 외부 SaaS, AI Agent까지 업무시스템이 많아질수록 “어떤 시스템이 어떤 API를 호출할 수 있는가”, “누가 어떤 데이터에 접근할 수 있는가”, “장애나 과부하가 발생했을 때 어떻게 통제할 것인가”가 중요한 문제가 되기 때문입니다. 하지만 모든 기업이 처음부터 고가의 Enterprise APIM을 도입해야 하는 것은 아닙니다. 대형 API 관리 플랫폼은 기능이 풍부하지만, 실제 현장에서는 API 라우팅, 인증, 승인, 속도 제한, 장애 대응, 모니터링, 감사 로그처럼 핵심 기능만 먼저 필요한 경우가 많습니다. GS비즈플이 주목하는 지점은 바로 이 간극입니다. 기업이 실제로 자주 사용하는 Gateway 핵심 기능은 알차게 제공하면서, 도입 부담은