AI를 업무에 사용하는 방법은 이제 꽤 익숙해졌습니다. 개발자는 코드와 관련 정보를 AI에게 Context(참고 정보)로 전달해 문제를 분석하고, 영업 담당자는 고객에게 보낼 메일을 작성하고, 직원들은 사내 문서를 AI에게 참조시켜 필요한 부분만 요약합니다. 이전에는 직접 찾아보고 작성해야 했던 일을 몇 번의 프롬프트 질문만으로 처리할 수 있게 되었습니다.
기업 안에서도 조직과 팀마다 사용하는 Cloud AI가 다를 수 있습니다. 개발팀은 코드 분석에 적합한 모델을, 영업팀은 문서 작성과 고객 응대에 적합한 모델을 선택합니다. 업무용 플랫폼과 연결한 AI 서비스가 달라지면서, 같은 회사의 자료도 여러 경로를 통해 AI에 전달됩니다.
업무를 잘 처리하려면 AI에도 필요한 정보를 제공해야 합니다. 그런데 기업 입장에서는 그 과정에서 한 번 더 확인해야 할 문제가 있습니다.
“지금 AI에게 보내는 내용에 회사 밖으로 나가면 안 되는 정보가 들어 있지는 않을까?”
고객정보, 계약 조건, 아직 공개하지 않은 사업 계획, 내부 소스코드까지. AI가 업무를 더 잘 이해하도록 자료를 제공할수록, 기업이 보호해야 할 정보도 함께 전달될 수 있습니다.
AI Keeper를 만들게 된 이유도 여기에 있습니다. 여러 AI를 함께 쓰는 환경에서, 회사가 허용할 서비스와 전달할 정보의 범위를 정하고 그 기준을 실제 업무에 적용할 수 있는 방법이 필요했습니다.
사용자는 질문 한 줄만 입력했는데, 더 많은 정보가 나갈 수 있습니다
영업 담당자가 사내 AI에 다음과 같이 질문했다고 가정해보겠습니다.
“이 고객의 지난 상담 내용을 정리해줘.”
이 문장에는 고객의 연락처나 계약 조건이 없습니다. 하지만 AI 서비스가 답변을 만들기 위해 고객관리 시스템과 사내 문서를 검색하면, 찾아온 자료에는 고객 개인정보가 포함되어 있을 수 있습니다. 사용자가 직접 입력하지 않은 고객정보까지 AI에 전달될 수 있는 구조입니다.
개발 업무에서도 비슷한 상황이 생깁니다. 오류 원인을 찾으려고 코드와 설정 정보를 AI에게 전달했는데, 그 안에 서버 접속 비밀번호나 인증정보가 함께 들어 있는 경우입니다. 사용자는 문제를 해결하려고 했지만, 결과적으로 외부로 보내면 안 되는 정보까지 전달하게 됩니다.
이전에 나눈 대화도 마찬가지입니다. 새로 입력한 문장에는 민감한 내용이 없더라도, AI가 함께 참고하는 과거 대화에는 민감한 정보가 남아 있을 수 있습니다. 화면에 보이는 질문만 확인해서는 실제로 어떤 자료가 전달되는지 알기 어렵습니다.
Cloud AI의 데이터 보관 기간과 접근 조건도 서비스, 계약, 설정에 따라 확인해야 합니다. 여기에 조직과 팀이 각자 AI 플랫폼과 모델 연결을 관리하면, 회사 전체에서 어떤 자료를 보내고 있는지 파악하기가 더 어려워집니다. 조직 혹은 팀마다 선택한 AI가 달라도 회사의 기밀 데이터를 보호하는 기준은 일관되게 적용되어야 합니다.
이러한 보호 기준은 AI가 직접 업무를 수행하는 Agent 환경에서도 중요한 설계 요소입니다. Meta는 Muse의 보안 설계에서 인증정보를 분리해 보관하고, Sentinel이라는 별도의 보안 Agent가 작업 권한과 외부 통신을 감시하고 승인하도록 구성했습니다. AI에게 더 많은 일을 맡기는 만큼, 그 과정에서 데이터를 보호하고 작업을 통제할 장치도 함께 마련한 사례입니다. ▶ Meta의 Muse 보안 설계 사례
기업에서도 사용할 AI를 정하는 것과 함께, 어떤 자료를 보내도 되는지, 무엇을 가려야 하는지, 사내에서만 처리해야 할 정보는 무엇인지 정해야 합니다. 직원들에게 주의를 당부하는 데서 그치지 않고, 실제 데이터가 전달되는 과정에 이 기준을 중앙화해서 적용할 수 있어야 합니다.
AI Keeper 개발 배경 : 사내에서 운영하며, 여러 AI 서비스에 같은 보호 기준을 적용합니다
처음에는 SLEXN의 기업용 AI 코딩 플랫폼인 CodeCenter에서 Cloud AI를 사용할 때 필요한 보호 기능을 중심으로 생각했습니다. 코드와 사내 문서를 활용하는 만큼 외부로 전달할 정보의 기준이 중요했기 때문입니다.
그런데 이 문제는 CodeCenter에만 해당하지 않았습니다. 고객사에서는 개발용 AI 외에도 사내 문서 검색, 고객 응대, 업무 자동화 등 여러 AI 서비스를 사용할 수 있습니다. 서비스마다 보호 방식이 다르면 같은 정보가 한쪽에서는 차단되고 다른 쪽에서는 그대로 전달될 수도 있습니다.
사내에 충분한 GPU 자원과 운영 환경이 갖춰져 있다면 로컬 모델을 직접 운영할 수 있습니다. 다만 GPU 확보에 시간이 걸리거나 도입·운영 비용이 부담되는 경우에는 모든 AI 수요를 사내에서 처리하기 어렵습니다.
이미 GPU를 보유하고 있더라도 최신 고성능 Open Weight 모델을 운영하려면 추가 GPU와 비용이 필요할 수 있습니다. 그래서 사내 모델로 처리할 수 있는 업무는 내부에서 수행하고, 더 높은 답변 품질이 필요한 복잡한 분석이나 개발 작업에는 고성능 Cloud AI를 함께 활용하기도 합니다. 이러한 Hybrid, 즉 사내 모델과 Cloud AI를 함께 사용하는 구성은 보유한 인프라와 비용, 업무에 필요한 품질을 함께 고려한 선택입니다.
이런 환경에서는 같은 플랫폼에서도 선택한 모델에 따라 데이터가 처리되는 곳이 달라집니다. 사내 모델로 작업하던 대화를 Cloud 모델로 이어가면 이전 대화와 참조 자료도 함께 전달될 수 있습니다. 모델을 바꾸는 순간에도 외부로 보내도 되는 정보인지 다시 확인해야 하는 이유입니다.
그래서 AI Keeper를 여러 AI 서비스와 연결할 수 있는 독립 제품으로 구성하고, Gateway 기능을 함께 담았습니다. Gateway는 쉽게 말해 업무용 AI 서비스와 외부 또는 사내 AI 모델 사이의 공통 연결 지점입니다.
직원은 CodeCenter를 비롯한 연동된 AI 플랫폼에서 회사가 허용한 여러 모델을 사용할 수 있습니다. 관리자는 누가 어떤 모델을 사용할 수 있는지, 어떤 정보를 차단하거나 가릴지, 사용량과 비용을 어떻게 관리할지 한곳에서 설정하고 확인할 수 있습니다. 고객사가 자체 개발한 AI 서비스나 외부에서 도입한 AI 플랫폼도 연결할 수 있어, 각 서비스에 보호 기능을 따로 구현하는 부담을 줄일 수 있습니다.
배포 방식은 처음부터 고객사 내부망에 설치하는 On-Prem(AirGap 지원)을 기본으로 고려했습니다. 민감한 원문을 검사하는 과정과 보호 정책 관리를 고객사가 통제하는 환경 안에 두기 위해서입니다.
업무용 AI 서비스가 요청을 보내면 사내에 설치한 AI Keeper가 먼저 검사하고, 회사가 정한 보호 정책을 통과한 내용만 Cloud AI로 전달합니다. 외부 반출을 허용하지 않는 업무는 사내 모델만 사용하도록 제한할 수 있습니다. 인터넷 연결이 제한된 폐쇄망에서도 Cloud 연결을 막고 사내 로컬 모델로만 운영할 수 있습니다.
중요한 정보가 나가기 전에 차단하거나 가립니다
AI Keeper의 핵심 동작은 차단과 마스킹입니다. 관리자가 설정한 규칙에 따라 보호할 정보를 확인하고, AI에게 보낼 내용을 조정하거나 전송을 멈춥니다.
보내면 안 되는 내용은 차단합니다. 서버 인증정보나 회사가 지정한 기밀 문구가 발견되면 요청의 전송을 멈추고, 사용자에게 회사가 정한 안내 메시지를 전달합니다.
가려도 업무를 진행할 수 있는 정보는 마스킹합니다. 상담 내용을 요약하는 데 고객의 실제 이메일 주소가 필요하지 않다면, 그 주소를 가린 내용을 AI에게 전달할 수 있습니다.
물론 상담 내용 자체가 기밀이라면 이메일만 가려서는 충분하지 않습니다. 해당 요청을 차단하거나 사내 AI에서만 처리하도록 기준을 정해야 합니다. 관리자가 모든 탐지 패턴을 처음부터 만들 필요도 없습니다. AI Keeper는 공개된 정보 형식과 패턴을 바탕으로, 반복해서 활용할 수 있도록 표준화한 다양한 탐지 룰셋을 템플릿으로 제공합니다.
- 개인정보: 외국인등록번호, 운전면허번호 등 개인을 식별할 수 있는 번호의 형식
- 서비스 인증정보: Cloud AI의 API 키, 개발 도구의 접근 토큰, 비밀번호가 포함된 접속 정보
- 금융정보: 국가별 은행 계좌번호 형식, 카드 결제 보안코드가 명시된 항목
관리자는 각 템플릿의 지원 형식과 적용 조건을 확인하고, 회사에 필요한 항목을 선택해 차단 또는 마스킹 방식과 적용 범위를 설정할 수 있습니다. 회사 고유의 기밀 문구나 업무 규칙도 추가할 수 있습니다. 이렇게 구성한 정책은 시뮬레이션으로 결과를 확인한 뒤 적용합니다. 이미 준비된 룰셋에서 출발해 자사 기준에 맞게 조정할 수 있어, 처음 보호 정책을 만드는 부담을 줄일 수 있습니다.
검사 대상에는 연동된 서비스가 전달하는 질문뿐 아니라 문서에서 꺼낸 텍스트, 업무 조회 결과, 이전 대화도 포함됩니다. 보호 검사가 필요한 요청은 검사를 완료하기 전까지 외부 AI로 보내지 않습니다.
회사에서 사용하는 AI 서비스를 AI Keeper에 연결하면, 모델에 보낼 내용을 전송 전에 검사할 수 있습니다. AI가 어떤 사내 문서를 열어보고 어떤 작업을 수행할 수 있는지는 해당 AI 서비스에서 따로 설정합니다. AI Keeper를 거치지 않고 직접 보내는 요청에는 이 보호가 적용되지 않습니다.
업무에 맞는 AI를 자동으로 연결합니다
보호 기준을 마련하고 나면 또 하나의 고민이 생깁니다.
“이 업무를 어떤 AI에게 맡기는 것이 좋을까?”
간단한 메일 초안을 작성하는 일과 여러 파일의 관계를 살펴 오류 원인을 찾는 일은 필요한 능력이 다릅니다. 모든 요청을 같은 모델로 처리하면 비용이나 응답 시간, 결과의 품질을 업무에 맞게 조절하기 어렵습니다. 그렇다고 직원이 매번 모델의 특성을 비교해 선택하는 것도 현실적이지 않습니다.
AI Keeper는 LLM Auto Routing으로 이 선택을 돕습니다. 회사가 사용을 허용한 AI 모델들 가운데, 관리자가 정한 기준과 요청의 성격에 맞는 모델을 자동으로 연결합니다.
- 간단한 요약이나 메일 초안: 해당 업무에 충분한 품질을 내면서 빠르고 비용 부담이 적은 라이트한 모델을 연결합니다.
- 복잡한 코드 분석이나 문제 해결: 결과의 품질을 보장하는 프론티어 모델을 연결합니다.
- 외부 반출이 금지된 자료를 다루는 업무: 처음부터 사내 모델만 선택 대상이 되도록 구성합니다.
관리자가 정한 명확한 규칙을 먼저 적용하고, 규칙에 해당하지 않는 요청은 질문의 의미와 목적을 분류해 연결할 모델을 선택합니다. 관리자는 실제 업무에서 확인한 품질과 비용, 응답 속도를 바탕으로 사용할 모델과 연결 기준을 설정할 수 있습니다.
자동으로 모델을 선택하더라도 회사의 보안 기준은 그대로 적용됩니다. AI Keeper가 차단한 요청을 다른 모델로 돌려 우회하는 동작은 허용하지 않습니다.
다음 로드맵은 On-Prem 기반의 지능형 판단 모델을 도입할 예정입니다
최근 AI 분야에서는 업무 과정에 필요한 판단을 별도의 모델에 맡기는 접근도 등장하고 있습니다. TypeSafe의 Jev는 주어진 내용을 보고 미리 정한 선택지 중 하나를 고르거나, 특정 조건에 해당하는지 판단하는 데 초점을 둔 모델입니다. 쉽게 말하면 “이 내용이 어떤 성격인지”, “다음에 무엇을 해야 하는지”를 판단하는 역할입니다.
▶ TypeSafe Jev 소개
Spring AI 공식 블로그에서도 Jev를 활용한 분류와 라우팅, 위험한 입력과 응답을 점검하는 사례를 소개했습니다. AI에게 업무를 맡기는 과정에서 이런 판단 기능의 활용을 살펴볼 수 있습니다.
▶ Spring AI의 Jev 활용 소개
저희는 이 접근을 참고해 사내에서 구동하는 지능형 판단 모델을 AI Keeper와 LLM Auto Routing에 도입하는 로드맵을 검토하고 있습니다. 보호할 원문을 살펴보는 판단 과정까지 고객사 내부에서 수행하는 On-Prem 구성을 목표로 합니다.
AI Keeper에서는 단어와 패턴을 찾는 검사에 문맥 판단을 더하려 합니다. 이메일 주소나 API 키처럼 일정한 형식이 있는 정보는 준비된 룰셋으로 찾을 수 있습니다. 여기에 앞뒤 내용을 이해하는 판단을 더하면, 정해진 형식이 없는 정보도 살펴볼 수 있습니다.
예를 들어 “할인율 계산 방법을 알려줘”라는 질문과 “A사에는 할인율 10%를 제안하되, 내부적으로는 20%까지 조정할 수 있다”는 내용에는 모두 ‘할인율’이 들어 있습니다. 하지만 전자는 일반적인 업무 질문이고, 후자는 외부에 알려지면 협상에 영향을 줄 수 있는 내부 정보입니다.
이처럼 같은 단어가 있어도 앞뒤 문맥에 따라 정보의 성격을 구분하고, 회사의 보호 기준에 맞춰 민감정보를 더 정교하게 탐지하도록 고도화할 계획입니다.
LLM Auto Routing에서는 업무의 복잡도와 맥락을 더 세밀하게 판단하는 데 활용하려 합니다. 같은 코드 수정 요청이라도 단순한 문구 수정과 여러 시스템에 영향을 주는 변경은 필요한 능력이 다릅니다. 이러한 차이를 판단해, 회사가 허용한 모델 가운데 적합한 모델을 선택하는 기준을 고도화할 계획입니다.
Gateway 안에서 데이터 보호와 모델 선택을 함께 관리합니다
이 Gateway는 여러 업무용 AI 서비스를 사내 모델과 Cloud AI에 연결하며, AI Keeper를 통한 데이터 보호와 LLM Auto Routing을 통한 모델 선택을 함께 제공합니다. 기업은 하나의 Gateway에서 AI 연결과 보안, 사용량과 비용을 관리할 수 있습니다.
|
Gateway가 제공하는 기능
|
맡는 역할
|
|---|---|
|
AI 연결 · 운영 관리
|
여러 AI 서비스와 모델을 연결하고, 사용 권한 · 사용량 · 비용을 한곳에서 관리합니다.
|
|
AI Keeper · 데이터 보호
|
AI에게 보낼 내용을 회사의 보호 규칙에 따라 검사하고, 민감한 정보가 탐지되면 요청을 차단하거나 해당 정보를 가립니다.
|
|
LLM Auto Routing · 모델 선택
|
회사가 허용한 모델 가운데 요청의 성격과 업무 목적에 맞는 모델을 자동으로 선택합니다.
|
앞으로는 On-Prem 지능형 판단 모델을 도입해, AI Keeper가 내용의 문맥을 살피고 Auto Routing이 업무의 복잡도를 더 세밀하게 판단하도록 고도화할 계획입니다.
AX 전환을 추진하거나 개발 업무에 AI를 도입하려는 기업, RAG 기반의 사내 문서 검색 시스템을 구축하려는 고객사들을 만나면서 비슷한 고민을 많이 들었습니다. 사내 GPU 자원은 제한적이고, 업무에 필요한 성능과 효율을 확보하려면 최신 고성능 Cloud AI를 함께 활용해야 하는 경우가 많았습니다. 하지만 사내 자료와 고객정보를 어디까지 외부로 보내도 되는지, 이를 실제로 어떻게 통제할지가 도입의 걸림돌이 되곤 했습니다.
이 Gateway는 현장에서 들은 요구에서 출발했습니다. Cloud AI를 업무에 활용하면서도 회사의 기밀을 보호하고, 기업이 정한 보안 기준을 실제 사용 과정에 적용할 수 있어야 한다는 요구입니다. 이를 위해 데이터 보호와 모델 선택, 사용 관리를 하나의 Gateway에서 함께 제공하도록 구성했습니다.
보안 문제로 Cloud AI 활용에 제약이 있거나, 외부 연결이 제한된 환경에서 사내 AI 도입을 검토하고 계신다면 SLEXN에 문의해 주세요. 현재의 GPU 환경과 업무 목적, 보안 요구사항을 바탕으로 기업에 맞는 AI 활용 방안을 함께 검토해드리겠습니다.
