AX 기술 스택 설계

기술 스택은 도구 목록이 아니라 운영 지도다

AX를 시작할 때 많은 기업이 먼저 묻는 질문은 이렇다.

"어떤 AI 툴을 써야 합니까?"

하지만 AX 관점에서 더 중요한 질문은 따로 있다.

"우리 회사의 업무, 데이터, 시스템, 권한, 성과 관리를 AI와 어떻게 연결할 것인가?"

AI 도구 하나를 도입하는 것은 어렵지 않다. 문제는 그 도구가 회사의 실제 업무 안으로 들어갈 때 생긴다. 고객 데이터는 CRM에 있고, 매출 데이터는 ERP에 있으며, 문서는 그룹웨어와 드라이브에 흩어져 있다. 직원별 권한도 다르고, 부서별 업무 방식도 다르다. 여기에 AI를 붙이려면 단순한 챗봇 화면만으로는 부족하다.

AX 기술 스택은 이 연결 구조를 설계하는 일이다. 즉, AI가 사내 지식에 접근하고, 기존 시스템과 대화하며, 사람의 승인을 받고, 결과를 기록하고, 품질과 비용을 관리할 수 있게 만드는 기술 지도다.

파일럿 단계에서는 빠른 실험이 중요하다. 그러나 전사 확산 단계에서는 운영 가능한 구조가 더 중요하다. 처음부터 너무 거창한 플랫폼을 만들 필요는 없지만, 나중에 확장할 수 없는 방식으로 시작해서도 안 된다.

AX 기술 스택의 목적은 세 가지다.

첫째, AI가 필요한 데이터와 업무 시스템에 안전하게 접근하게 하는 것.

둘째, AI의 답변과 실행 결과를 관리하고 검증할 수 있게 하는 것.

셋째, 부서별 실험을 재사용 가능한 전사 역량으로 바꾸는 것이다.

AX 기술 스택의 기본 구성

기업 AX를 구현하는 기술 스택은 크게 여섯 층으로 볼 수 있다.

이 여섯 층이 함께 움직여야 AI가 실험 도구를 넘어 기업 시스템이 된다.

예를 들어 영업 제안서 작성 AI를 생각해 보자. 겉으로는 직원이 "A 고객사 제안서 초안을 만들어 줘"라고 입력하는 단순한 기능처럼 보인다. 그러나 실제로는 여러 기술이 함께 작동한다.

AI는 먼저 고객사의 기본 정보를 CRM에서 가져와야 한다. 과거 제안서와 계약 조건은 문서 저장소에서 찾아야 한다. 제품 가격과 재고 정보는 ERP나 내부 데이터베이스에서 확인해야 한다. 최신 영업 정책은 사내 지식 시스템에서 검색해야 한다. 작성된 제안서는 회사 양식에 맞아야 하고, 특정 할인율 이상이면 팀장 승인을 받아야 한다. 마지막으로 누가 어떤 고객 정보를 조회했고 어떤 제안서를 생성했는지 로그가 남아야 한다.

이 전체 흐름이 AX 기술 스택이다.

LLM은 두뇌지만 전체 시스템은 아니다

AX 기술 스택의 중심에는 LLM이 있다. LLM은 Large Language Model의 약자로, 대규모 언어 모델을 뜻한다. 문장을 이해하고, 요약하고, 분류하고, 초안을 작성하고, 질문에 답하는 역할을 한다.

그러나 LLM을 기업 시스템의 전부로 보면 위험하다. LLM은 언어 처리 능력이 뛰어난 엔진이지, 회사의 최신 정보를 자동으로 알고 있는 데이터베이스가 아니다. 또한 업무 권한을 판단하는 관리자도 아니고, 결과의 법적 책임을 지는 주체도 아니다.

LLM의 역할은 다음과 같이 이해하는 것이 좋다.

• 문서를 읽고 요약한다.

• 질문의 의도를 해석한다.

• 여러 정보를 바탕으로 초안을 만든다.

• 복잡한 내용을 쉬운 말로 설명한다.

• 정해진 기준에 따라 분류하거나 비교한다.

• 필요한 다음 작업을 제안한다.

반대로 LLM만으로 해결하면 안 되는 영역도 있다.

• 최신 매출 수치 확인

• 고객 개인정보 조회

• 계약 승인

• 금융 거래 실행

• 법적 판단의 최종 확정

• 인사 평가 결정

• 보안 권한 부여

이런 영역은 반드시 기존 시스템, 권한 체계, 승인 절차, 사람의 검토와 연결되어야 한다. 좋은 AX 아키텍처는 LLM을 과신하지 않는다. LLM이 잘하는 일과 기업 시스템이 해야 할 일을 분리한다.

검색 시스템과 벡터DB는 AI의 기억을 만든다

지난 장에서 살펴본 RAG는 AX 기술 스택에서 매우 중요한 위치를 차지한다. RAG는 AI가 답변하기 전에 관련 문서나 데이터를 검색해 참고하도록 만드는 방식이다. 기업에서는 이 구조가 특히 중요하다. 사내 규정, 제품 설명서, 고객 응대 매뉴얼, 회의록, 보고서, 계약서처럼 회사 내부 지식이 답변의 근거가 되기 때문이다.

이때 필요한 기술이 검색 시스템과 벡터DB다.

검색 시스템은 사용자의 질문과 관련 있는 문서를 찾아준다. 전통적인 검색은 키워드가 일치하는 문서를 찾는 방식에 강하다. 예를 들어 "휴가 규정"이라고 검색하면 해당 단어가 들어간 문서를 찾는다.

벡터DB는 의미가 비슷한 정보를 찾는 데 강하다. 벡터는 문장의 의미를 숫자 형태로 바꾼 값이라고 이해하면 된다. 예를 들어 사용자가 "배우자 출산 시 며칠 쉴 수 있나요?"라고 질문해도, 문서에 "배우자 출산휴가"라는 표현이 있다면 의미상 가까운 정보로 찾아낼 수 있다.

기업 AX에서는 보통 키워드 검색과 벡터 검색을 함께 사용한다. 이를 하이브리드 검색이라고 한다. 키워드가 정확히 맞아야 하는 규정 문서에는 전통 검색이 유리하고, 표현이 다양하게 바뀌는 상담이나 지식 검색에는 벡터 검색이 유리하다.

검색 계층을 설계할 때는 다음 질문을 던져야 한다.

• 어떤 문서를 AI가 검색할 수 있게 할 것인가?

• 문서의 최신성은 어떻게 관리할 것인가?

• 부서별·직급별 접근 권한은 어떻게 반영할 것인가?

• 검색 결과의 근거 문서를 사용자에게 보여줄 것인가?

• 오래된 문서와 최신 문서가 충돌할 때 무엇을 우선할 것인가?

• 답변에 사용된 문서를 로그로 남길 것인가?

검색 품질은 답변 품질을 결정한다. AI 모델이 좋아도 잘못된 문서를 가져오면 답변은 틀린다. 반대로 평범한 모델이라도 정확한 근거를 제공하면 업무에 쓸 만한 답변을 만들 수 있다.

워크플로우 도구는 AI를 업무 흐름에 넣는다

AI가 문서 초안을 작성하거나 질문에 답하는 단계까지는 비교적 쉽다. 어려운 것은 AI가 실제 업무 흐름 안에서 작동하게 만드는 일이다.

워크플로우 도구는 여러 단계를 순서대로 연결하는 기술이다. 예를 들어 고객 문의 처리 업무를 보면 다음과 같은 흐름이 필요하다.

1. 고객 문의가 들어온다.

2. AI가 문의 유형을 분류한다.

3. 관련 고객 정보를 CRM에서 조회한다.

4. 사내 매뉴얼에서 답변 근거를 찾는다.

5. 답변 초안을 작성한다.

6. 민감한 내용이면 상담원에게 검토를 요청한다.

7. 승인된 답변을 고객에게 발송한다.

8. 처리 결과를 고객지원 시스템에 기록한다.

이런 흐름을 사람이 매번 수동으로 연결하면 AX가 아니라 단순 AI 사용에 머문다. AX에서는 업무의 일부 단계가 자동으로 이어지고, 필요한 지점에서 사람이 개입하며, 결과가 시스템에 남아야 한다.

워크플로우 도구는 다음 역할을 한다.

• AI 호출 순서를 정한다.

• 외부 시스템 API를 연결한다.

• 조건에 따라 다음 단계를 나눈다.

• 승인 요청을 보낸다.

• 실패 시 재시도하거나 사람에게 넘긴다.

• 실행 결과를 기록한다.

AI 에이전트를 도입할 때도 워크플로우 설계가 중요하다. 에이전트가 모든 것을 자유롭게 하도록 두는 것이 아니라, 어떤 조건에서 어떤 도구를 사용할 수 있는지 정해야 한다. 고객 정보 조회는 가능하지만 수정은 불가능하게 할 수 있다. 초안 작성은 가능하지만 외부 발송은 사람 승인 후에만 가능하게 할 수 있다.

좋은 AX 시스템은 자동화와 통제를 함께 설계한다.

API는 기존 시스템과 AI를 연결하는 통로다

기업은 이미 많은 시스템을 가지고 있다. CRM, ERP, 그룹웨어, 전자결재, 데이터웨어하우스, 고객센터 솔루션, 마케팅 자동화 도구, 협업 도구 등이 있다. AX는 이 시스템들을 버리고 새로 시작하는 일이 아니다. 기존 시스템 위에 AI를 연결해 업무 방식을 바꾸는 일이다.

이때 핵심이 API다.

API는 시스템과 시스템이 서로 요청하고 응답할 수 있게 만든 연결 규칙이다. 쉽게 말해, AI가 기존 시스템과 대화하는 통로다.

예를 들어 AI 영업 비서가 제대로 작동하려면 다음 API 연결이 필요할 수 있다.

• CRM에서 고객 정보 조회

• ERP에서 가격과 재고 확인

• 전자결재에서 승인 상태 확인

• 문서 저장소에서 제안서 양식 조회

• 이메일 시스템에서 발송 초안 생성

• 데이터웨어하우스에서 매출 추이 조회

API 기반 AX 아키텍처의 장점은 확장성이다. 처음에는 영업 제안서 작성 기능 하나로 시작하더라도, 나중에 고객 분석, 캠페인 추천, 계약 갱신 알림, 매출 예측 등으로 확장할 수 있다. 이미 연결된 시스템과 권한 구조를 재사용할 수 있기 때문이다.

반대로 API 없이 파일 업로드와 수작업 복사·붙여넣기로만 AI를 쓰면 확산이 어렵다. 파일럿에서는 빨라 보이지만 운영 단계에서 막힌다. 데이터가 최신인지 알 수 없고, 권한 통제가 어렵고, 결과 기록도 남지 않는다.

AX를 장기적으로 추진하려면 주요 업무 시스템의 API 현황을 먼저 파악해야 한다.

• 어떤 시스템이 API를 제공하는가?

• 읽기만 가능한가, 쓰기도 가능한가?

• 인증 방식은 무엇인가?

• 호출량 제한은 있는가?

• 외부 AI 서비스와 연결할 수 있는가?

• 개인정보나 기밀정보 전송 제한은 무엇인가?

• API 사용 로그를 남길 수 있는가?

기술 스택 설계는 새로운 AI 도구를 고르는 일만이 아니다. 기존 시스템이 AI와 연결될 준비가 되어 있는지 확인하는 일이기도 하다.

SaaS를 쓸 것인가, 직접 만들 것인가

AX 기술 스택을 설계할 때 가장 현실적인 고민은 이것이다.

"이미 있는 SaaS를 쓸 것인가, 직접 만들 것인가?"

SaaS는 Software as a Service의 약자로, 인터넷을 통해 구독형으로 사용하는 소프트웨어를 뜻한다. 기업용 AI 챗봇, 고객지원 자동화 도구, 문서 요약 서비스, 회의록 AI, 마케팅 콘텐츠 생성 도구 등이 여기에 속한다.

SaaS의 장점은 빠르다는 것이다. 별도 개발 없이 바로 사용할 수 있고, 기능 업데이트도 공급사가 해준다. 초기 비용도 비교적 낮다. AX를 처음 시작하는 기업이나 중소기업에는 좋은 선택이 될 수 있다.

하지만 SaaS만으로 모든 AX를 해결하기는 어렵다. 회사 고유의 업무 프로세스와 깊게 연결해야 하거나, 민감한 데이터를 다루거나, 기존 시스템과 복잡하게 연동해야 할 때는 한계가 있다.

직접 구축의 장점은 맞춤화다. 회사의 데이터 구조, 권한 체계, 업무 규칙, 승인 흐름에 맞게 설계할 수 있다. 장기적으로는 핵심 경쟁력을 내부에 축적할 수도 있다. 그러나 개발 기간이 길고, 운영 인력이 필요하며, 보안과 품질 관리 책임도 회사가 져야 한다.

선택 기준은 다음 네 가지로 정리할 수 있다.

실무에서는 둘 중 하나만 선택하지 않는다. 대부분은 혼합 전략을 쓴다.

예를 들어 회의록 작성, 문서 요약, 개인 업무 생산성 도구는 SaaS로 시작할 수 있다. 반면 고객 데이터, 계약 정보, 제조 공정 데이터, 금융 심사 데이터처럼 민감하고 핵심적인 영역은 내부 시스템과 직접 연결하거나 별도의 통제 구조를 둔다.

중요한 것은 과제의 성격에 맞게 선택하는 것이다. 모든 것을 직접 만들면 속도가 느려진다. 모든 것을 SaaS에 맡기면 통제가 약해진다.

모델 선택보다 모델 교체 가능성이 중요하다

많은 기업이 AX 기술 스택을 논의할 때 특정 모델 이름부터 거론한다. 어떤 LLM이 가장 좋은지, 어떤 모델을 표준으로 삼을지 고민한다. 물론 모델 선택은 중요하다. 그러나 더 중요한 것은 모델을 바꿀 수 있는 구조다.

AI 모델 시장은 빠르게 변한다. 오늘 가장 좋은 모델이 내년에도 최선이라는 보장은 없다. 업무별로 적합한 모델도 다르다. 고난도 분석에는 강력한 모델이 필요할 수 있지만, 단순 분류나 요약에는 비용이 낮은 모델로 충분할 수 있다. 고객 응대에는 안정성과 응답 속도가 중요하고, 내부 전략 보고서 작성에는 추론 품질이 더 중요할 수 있다.

따라서 AX 아키텍처는 특정 모델에 종속되지 않도록 설계하는 것이 좋다. 이를 위해 AI 게이트웨이 또는 모델 중개 계층을 둘 수 있다. 사용자는 하나의 AI 기능을 쓰지만, 내부에서는 업무 유형에 따라 적절한 모델로 요청을 보내는 방식이다.

예를 들어 다음과 같이 운영할 수 있다.

• 단순 문서 요약: 저비용 모델 사용

• 민감 문서 검토: 보안 기준을 충족하는 모델 사용

• 복잡한 의사결정 지원: 고성능 추론 모델 사용

• 대량 고객 문의 분류: 빠르고 저렴한 모델 사용

• 코드 리뷰: 개발 업무에 특화된 모델 사용

이 구조를 갖추면 비용과 품질을 함께 관리할 수 있다. 또한 특정 공급사의 장애나 가격 정책 변화에도 유연하게 대응할 수 있다.

모델 선택의 기준은 단순히 "가장 똑똑한가"가 아니다. 다음 기준을 함께 봐야 한다.

• 업무 정확도

• 응답 속도

• 사용 비용

• 보안 조건

• 데이터 저장 정책

• API 안정성

• 한국어 처리 품질

• 장문 문서 처리 능력

• 도구 호출 능력

• 평가와 모니터링 지원 여부

AX는 모델 경연이 아니다. 업무 성과를 안정적으로 내는 운영 체계를 만드는 일이다.

보안과 권한은 나중에 붙이는 기능이 아니다

기업 AI에서 보안은 선택 기능이 아니다. 처음부터 설계에 들어가야 한다.

AI가 사내 문서와 시스템에 접근하기 시작하면 기존보다 더 복잡한 보안 문제가 생긴다. 직원이 직접 검색할 때는 접근 권한이 분명했지만, AI가 중간에 들어오면 "AI가 대신 찾아준 정보"의 권한을 어떻게 판단할지 정해야 한다.

예를 들어 한 직원이 "이번 분기 영업 전략을 요약해 줘"라고 요청했다고 하자. AI가 검색 시스템을 통해 경영진 전용 문서를 찾아 답변에 포함한다면 문제가 된다. 사용자는 직접 접근 권한이 없지만, AI를 통해 간접적으로 정보를 얻은 셈이기 때문이다.

따라서 AX 기술 스택에는 권한 기반 검색이 포함되어야 한다. 사용자가 볼 수 없는 문서는 AI도 참고하지 못해야 한다. 시스템 간 API 호출도 마찬가지다. AI가 어떤 시스템을 호출할 수 있는지, 어떤 데이터 항목을 조회할 수 있는지, 수정이나 삭제 권한은 있는지 분리해야 한다.

보안 설계의 기본 원칙은 다음과 같다.

• 사용자의 기존 권한을 AI 검색과 실행에도 동일하게 적용한다.

• 민감 정보는 입력, 검색, 출력 단계에서 모두 통제한다.

• AI가 외부로 전송하는 데이터 범위를 제한한다.

• 고객 정보와 임직원 정보는 별도 보호 기준을 둔다.

• 중요한 실행 작업은 사람 승인 후 처리한다.

• 모든 요청과 응답, 데이터 접근 기록을 남긴다.

특히 개인정보, 영업비밀, 계약 정보, 인사 정보, 재무 정보는 별도 등급을 정해야 한다. AI 사용을 전면 금지할 필요는 없지만, 어떤 조건에서 사용할 수 있는지 명확해야 한다.

보안이 약하면 AX는 확산될수록 위험해진다. 반대로 보안 기준이 지나치게 모호하면 직원들이 AI를 쓰지 못한다. 좋은 보안 설계는 금지가 아니라 안전한 사용을 가능하게 하는 기준이다.

로그와 모니터링은 AI 운영의 계기판이다

자동차를 운전할 때 속도, 연료, 경고등을 보지 않고 달릴 수 없다. AI도 마찬가지다. 기업 시스템으로 운영하려면 사용 현황과 품질 상태를 계속 봐야 한다.

AI 운영에서 로그는 매우 중요하다. 로그는 누가, 언제, 어떤 목적으로, 어떤 데이터를 사용해, 어떤 결과를 얻었는지 남긴 기록이다. 로그가 있어야 문제가 생겼을 때 원인을 찾을 수 있다. 비용이 왜 늘었는지, 어떤 부서가 많이 쓰는지, 어떤 업무에서 오류가 잦은지도 알 수 있다.

모니터링해야 할 항목은 크게 다섯 가지다.

첫째, 사용량이다. 부서별 사용자 수, 요청 건수, 기능별 사용 빈도를 봐야 한다. 사용량이 없으면 도입 효과도 없다. 반대로 사용량이 갑자기 늘면 비용과 성능 문제가 생길 수 있다.

둘째, 비용이다. LLM은 호출량, 입력 문서 길이, 출력 길이, 모델 종류에 따라 비용이 달라진다. 같은 업무라도 프롬프트를 길게 쓰거나 불필요한 문서를 많이 검색하면 비용이 커진다. AX 운영에서는 기능별 단가를 관리해야 한다.

셋째, 응답 품질이다. AI 답변이 정확한지, 유용한지, 근거 문서를 잘 사용했는지, 사용자가 수정 없이 활용할 수 있는지 평가해야 한다. 단순히 "답변을 생성했다"는 것으로는 성과를 말할 수 없다.

넷째, 지연 시간이다. 응답이 너무 느리면 사용자는 AI를 쓰지 않는다. 고객 응대, 상담 지원, 현장 작업자 지원처럼 속도가 중요한 업무에서는 지연 시간이 품질의 일부다.

다섯째, 안전성이다. 민감 정보 노출, 부적절한 답변, 금지된 실행, 권한 없는 데이터 접근이 발생했는지 확인해야 한다.

운영 지표를 예로 들면 다음과 같다.

이 지표들은 다음 장에서 다룰 AI 플랫폼과 거버넌스 도구의 기초가 된다. 기술 스택을 설계할 때부터 로그와 모니터링 구조를 넣어야 나중에 통제할 수 있다.

비용 관리는 AX 확산의 현실 조건이다

AI는 사용량이 늘수록 비용 구조가 달라진다. 파일럿 단계에서는 비용이 작아 보일 수 있다. 몇 명이 몇 가지 업무에만 쓰기 때문이다. 그러나 전사 확산이 시작되면 이야기가 달라진다. 수백 명, 수천 명이 매일 AI를 호출하면 모델 사용료, 검색 인프라 비용, 저장 비용, 모니터링 비용, 보안 도구 비용이 함께 늘어난다.

비용 관리를 하지 않으면 두 가지 문제가 생긴다.

하나는 예산 초과다. 사용이 늘수록 비용이 예측 불가능해진다. 다른 하나는 과도한 제한이다. 비용이 불안해지면 회사는 AI 사용을 막거나 승인 절차를 복잡하게 만든다. 그러면 AX 확산이 멈춘다.

따라서 처음부터 비용 구조를 설계해야 한다.

• 업무별 적정 모델을 정한다.

• 불필요하게 긴 입력과 출력을 줄인다.

• 자주 쓰는 답변은 캐시를 활용한다.

• 검색 문서 수와 길이를 최적화한다.

• 부서별 사용량 한도와 예산 기준을 둔다.

• 고비용 모델 사용은 특정 업무로 제한한다.

• 기능별 ROI를 주기적으로 검토한다.

비용 최적화는 단순 절감이 아니다. 중요한 업무에는 충분한 성능을 쓰고, 단순 업무에는 가벼운 구조를 쓰는 것이다. 모든 업무에 최고급 모델을 쓰는 것은 낭비이고, 모든 업무에 저가 모델을 쓰는 것은 품질 저하다.

AX 기술 스택은 비용과 품질의 균형을 조정할 수 있어야 한다.

파일럿용 구조와 확산용 구조는 다르다

파일럿은 빠르게 배워야 한다. 완벽한 시스템보다 검증이 중요하다. 그래서 파일 업로드, 간단한 챗봇, 수동 데이터 추출, 단일 모델 호출로 시작할 수 있다.

하지만 파일럿에서 쓴 구조를 그대로 전사 확산에 쓰면 문제가 생긴다.

파일럿용 구조의 특징은 다음과 같다.

• 특정 부서와 특정 사용자 중심이다.

• 데이터 연결이 임시적이다.

• 권한 관리가 단순하다.

• 품질 평가는 수작업에 가깝다.

• 로그와 비용 관리가 제한적이다.

• 예외 상황 처리가 부족하다.

확산용 구조는 달라야 한다.

• 여러 부서가 함께 쓸 수 있어야 한다.

• 데이터 연결이 자동화되어야 한다.

• 권한과 보안 기준이 체계화되어야 한다.

• 사용량과 비용을 추적해야 한다.

• 품질 평가 기준이 있어야 한다.

• 장애와 오류 대응 절차가 있어야 한다.

• 재사용 가능한 컴포넌트가 있어야 한다.

여기서 컴포넌트란 반복해서 쓸 수 있는 기술 구성요소를 말한다. 예를 들어 문서 검색 모듈, 고객 정보 조회 API, 승인 워크플로우, 프롬프트 템플릿, 로그 수집 기능, 평가 데이터셋 등이 있다.

좋은 AX 조직은 파일럿을 할 때도 확산을 염두에 둔다. 처음부터 거대한 플랫폼을 만들지는 않지만, 나중에 버릴 구조로 만들지도 않는다.

API 기반 AX 아키텍처의 기본 형태

기업에서 활용할 수 있는 AX 아키텍처를 단순화하면 다음 흐름으로 정리할 수 있다.

1. 사용자가 업무 화면에서 AI에 요청한다.

2. 인증 시스템이 사용자의 신원과 권한을 확인한다.

3. AI 오케스트레이션 계층이 요청의 의도와 필요한 작업을 판단한다.

4. 검색 시스템이 관련 사내 문서와 데이터를 찾는다.

5. 필요한 경우 CRM, ERP, 그룹웨어, 데이터웨어하우스의 API를 호출한다.

6. LLM이 검색 결과와 시스템 데이터를 바탕으로 답변이나 실행안을 만든다.

7. 민감하거나 중요한 작업은 사람의 승인을 받는다.

8. 결과가 업무 시스템에 기록된다.

9. 전체 과정의 로그, 비용, 품질 지표가 운영 시스템에 남는다.

여기서 AI 오케스트레이션은 여러 기술과 단계를 조율하는 역할을 한다. 오케스트라의 지휘자처럼, 어떤 모델을 쓸지, 어떤 문서를 검색할지, 어떤 API를 호출할지, 언제 사람에게 넘길지를 결정한다.

예를 들어 구매 부서의 AI 업무 지원 시스템은 다음처럼 움직일 수 있다.

직원이 "최근 원자재 가격 변동을 반영해 다음 달 발주 위험을 분석해 줘"라고 요청한다. 시스템은 직원의 권한을 확인한다. 그다음 ERP에서 발주 내역을 가져오고, 데이터웨어하우스에서 가격 추이를 조회하며, 공급업체 평가 문서를 검색한다. AI는 이를 바탕으로 위험 요인을 정리하고, 추가 확인이 필요한 공급업체를 표시한다. 일정 금액 이상 발주 변경이 필요하면 구매 책임자 승인 요청을 생성한다. 모든 조회와 분석 결과는 로그로 남는다.

이 구조가 중요한 이유는 AI가 별도 공간에서 혼자 답변하는 것이 아니라, 실제 업무 시스템과 연결되어 움직이기 때문이다.

기술 선택 전에 업무 유형을 먼저 나눠라

기술 스택을 잘 설계하려면 먼저 AX 과제를 업무 유형별로 나눠야 한다. 모든 업무에 같은 기술 구조를 적용할 필요는 없다.

대표적인 유형은 다섯 가지다.

첫째, 개인 생산성형이다. 문서 요약, 번역, 회의록 정리, 이메일 초안 작성처럼 개인 업무 시간을 줄이는 과제다. 이 영역은 SaaS나 범용 AI 도구로 빠르게 시작할 수 있다.

둘째, 사내 지식 검색형이다. 규정, 매뉴얼, 제품 정보, 기술 문서, 과거 사례를 검색해 답하는 과제다. RAG, 검색 시스템, 권한 관리, 문서 최신성 관리가 중요하다.

셋째, 업무 프로세스 자동화형이다. 문의 분류, 승인 요청, 데이터 입력, 보고서 생성처럼 여러 단계를 연결하는 과제다. 워크플로우 도구와 API 연동이 핵심이다.

넷째, 의사결정 지원형이다. 수요 예측, 리스크 분석, 고객 세분화, 투자 판단 지원처럼 데이터를 바탕으로 판단을 돕는 과제다. 데이터웨어하우스, 분석 모델, 설명 가능한 결과, 사람 검토가 필요하다.

다섯째, 고객 접점형이다. 챗봇, 상담 보조, 개인화 추천, AI 상담원처럼 고객에게 직접 영향을 주는 과제다. 품질 관리, 응답 속도, 브랜드 톤, 법적 책임, 장애 대응이 중요하다.

업무 유형을 나누면 기술 선택이 쉬워진다. 개인 생산성형 과제에 복잡한 내부 플랫폼을 만들 필요는 없다. 반대로 고객 접점형 과제를 단순 챗봇 도구 하나로 운영해서는 안 된다.

장기 확산을 위한 표준을 정하라

AX가 전사로 확산되면 부서별로 다양한 요구가 쏟아진다. 마케팅은 콘텐츠 생성 AI를 원하고, 영업은 제안서 AI를 원하며, 고객지원은 상담 자동화를 원한다. 인사는 채용 서류 검토를 원하고, 재무는 비용 분석 자동화를 원한다.

이때 부서마다 다른 도구와 다른 방식으로 만들기 시작하면 곧 관리가 어려워진다. 비용이 중복되고, 보안 기준이 달라지고, 같은 데이터를 여러 방식으로 연결한다. 나중에는 어떤 AI가 어떤 데이터를 쓰고 있는지도 파악하기 어렵다.

그래서 AX 기술 스택에는 표준이 필요하다.

표준화해야 할 항목은 다음과 같다.

• 승인된 AI 모델 목록

• 모델 사용 기준과 금지 기준

• 사내 문서 연결 방식

• 벡터DB와 검색 인덱스 관리 기준

• API 인증 방식

• 프롬프트 템플릿 관리 방식

• 로그 수집 항목

• 개인정보와 기밀정보 처리 기준

• 품질 평가 기준

• 비용 배부 기준

• 장애 대응 절차

표준은 혁신을 막기 위한 것이 아니다. 오히려 확산 속도를 높이기 위한 것이다. 공통 기반이 있으면 부서는 매번 처음부터 만들 필요가 없다. 검증된 연결 방식, 승인 절차, 보안 기준, 평가 지표를 재사용할 수 있다.

AX의 속도는 개별 도구의 속도가 아니라 재사용 가능한 기반의 속도에서 나온다.

중소기업과 스타트업을 위한 현실적 접근

모든 기업이 대규모 AI 플랫폼을 만들 수 있는 것은 아니다. 특히 중소기업과 스타트업은 인력과 예산이 제한되어 있다. 그렇다고 AX를 포기할 필요는 없다. 오히려 작은 조직일수록 빠르게 표준을 정하고 단순한 구조로 시작할 수 있다.

현실적인 접근은 다음과 같다.

첫째, 범용 SaaS로 개인 생산성 과제를 먼저 해결한다. 회의록, 문서 요약, 이메일 작성, 보고서 초안처럼 바로 효과가 나는 업무부터 시작한다.

둘째, 핵심 문서 저장소를 정리한다. 사내 규정, 제품 자료, 고객 응대 매뉴얼, 영업 자료처럼 자주 쓰는 지식을 한곳에 모으고 최신본 기준을 세운다.

셋째, 하나의 RAG 과제를 만든다. 예를 들어 "사내 규정 Q&A" 또는 "제품 매뉴얼 검색 AI"처럼 범위가 명확한 과제를 선택한다.

넷째, 기존 업무 도구와의 연결을 최소한으로 시작한다. 처음부터 ERP, CRM, 그룹웨어를 모두 연결하려 하지 말고, 가장 중요한 한두 개 시스템부터 API 연결을 검토한다.

다섯째, 로그와 비용 관리는 처음부터 한다. 복잡한 도구가 아니어도 된다. 누가 어떤 기능을 얼마나 쓰고, 어떤 문제가 있었는지 기록하는 것부터 시작하면 된다.

중소기업의 AX 기술 스택은 단순해야 한다. 그러나 단순하다는 것이 임시방편이라는 뜻은 아니다. 핵심은 "작지만 확장 가능한 구조"다.

AX 기술 스택 설계 체크리스트

기술 스택을 검토할 때는 다음 질문을 사용해 볼 수 있다.

1. 사용자 접점

• 직원은 어디에서 AI를 사용하는가?

• 별도 챗봇인가, 기존 업무 시스템 안에 들어가는가?

• 모바일이나 현장 단말에서도 필요한가?

2. 모델 계층

• 어떤 업무에 어떤 LLM을 사용할 것인가?

• 모델을 교체할 수 있는 구조인가?

• 고비용 모델과 저비용 모델의 사용 기준이 있는가?

3. 지식·검색 계층

• AI가 참고할 사내 문서 범위가 정해져 있는가?

• 문서 최신성과 버전 관리 기준이 있는가?

• 사용자 권한에 따라 검색 결과가 제한되는가?

4. 시스템 연동

• CRM, ERP, 그룹웨어, 데이터웨어하우스와 API로 연결할 수 있는가?

• 읽기 권한과 쓰기 권한이 분리되어 있는가?

• 중요한 실행 작업에는 승인 절차가 있는가?

5. 보안과 규정

• 개인정보와 기밀정보 처리 기준이 있는가?

• 외부 AI 서비스로 보낼 수 없는 데이터가 정의되어 있는가?

• 사용자의 요청과 AI 응답이 기록되는가?

6. 운영 관리

• 사용량, 비용, 품질, 오류를 모니터링하는가?

• 부서별 비용 배부나 사용 한도가 있는가?

• 장애나 잘못된 답변에 대응하는 절차가 있는가?

7. 확산 가능성

• 이번 파일럿에서 만든 구성요소를 다른 부서도 재사용할 수 있는가?

• 프롬프트, 검색, API, 평가 기준이 표준화되어 있는가?

• 기술 선택이 6개월 뒤 확산을 방해하지 않는가?

이 체크리스트에 답하다 보면 AX가 단순한 도구 도입인지, 운영 가능한 기업 시스템인지 구분할 수 있다.

기술 스택은 AX의 속도와 한계를 결정한다

AX 전환에서 기술은 전부가 아니다. 전략, 조직, 문화, 리더십이 함께 바뀌어야 한다. 그러나 기술 스택이 약하면 좋은 전략도 실행되지 않는다.

AI가 사내 지식에 접근하지 못하면 답변은 일반론에 머문다. 기존 시스템과 연결되지 않으면 업무 실행으로 이어지지 않는다. 권한과 보안이 없으면 확산이 막힌다. 로그와 품질 관리가 없으면 성과를 증명할 수 없다. 비용 관리가 없으면 예산이 불안해진다.

따라서 AX 기술 스택은 단기 파일럿의 성공보다 장기 확산 가능성을 기준으로 설계해야 한다.

좋은 기술 스택은 복잡한 구조가 아니다. 업무에 필요한 만큼 단순하고, 확산에 필요한 만큼 견고한 구조다. 처음에는 작게 시작하되, 데이터 연결, 권한, API, 로그, 품질 관리의 원칙은 놓치지 않아야 한다.

AX는 AI를 회사 밖의 도구로 쓰는 단계에서 회사 안의 운영 체계로 받아들이는 과정이다. 그 전환을 가능하게 하는 기반이 바로 기술 스택이다.