
AI를 사내 데이터에 연결하기 전에 결정해야 할 5가지 분리 규칙
요약
사내 데이터와 AI를 연결할 때 고려해야 할 5가지 분리 규칙을 다룹니다. 모델의 성능보다 기억(Memory), 컨텍스트 경계, 제어권, 보안 관측, 시스템 운용 관점의 설계가 중요함을 강조합니다.
핵심 포인트
- 기억을 대화 메모리, 영구 메모리 등으로 계층화하여 설계해야 함
- 모델 사용 권한과 업무 데이터 연결 권한을 엄격히 분리해야 함
- AI를 단순 도구가 아닌 지속 가능한 시스템으로 접근해야 함
- 컨텍스트 전달 경계와 클라우드/로컬 제어권을 명확히 정의해야 함
AI 기능을 도입할 때, 논의는 자칫 「어떤 모델이 강력한가」로 치우치기 쉽습니다. 하지만 2026년 6월 1일부터 6월 4일에 공개된 영어 원천 정보를 나열해 보면, 구현 현장의 병목(Bottleneck)은 다른 곳에 있습니다.
- 모델의 기억이 어디까지 자동으로 성장하는가
- 사내 컨텍스트(Context)를 어떤 경계에서 전달할 것인가
- 클라우드와 로컬의 제어 측면을 어떻게 나눌 것인가
- 공격 측도 AI를 깊은 공정에서 사용하는 것을 전제로 무엇을 관측할 것인가
- 생성형 AI를 「편리한 도구」가 아니라 「지속적으로 운용하는 시스템」으로 다룰 수 있는가
이 기사에서는 OpenAI, Anthropic, Microsoft의 2026년 6월 초 공식 발표를 바탕으로, AI를 사내 데이터·사내 도구·사내 워크플로우(Workflow)에 연결하기 전에 결정해야 할 5가지 분리 규칙을 정리합니다. 뉴스의 요약이 아니라, 구현 판단에 직결되는 형태로 풀어냅니다.
| 분리 규칙 | 먼저 결정할 것 | 구현의 결과물 |
|---|---|---|
| 1. 기억의 분리 | 대화 이력, 영구 메모리, 업무 상태를 동일시하지 않음 | memory policy / TTL / reset |
| ... |
요점은 단순합니다. AI를 똑똑하게 만들기 전에, AI가 무엇을 기억하고, 무엇에 연결되며, 어디까지 움직일 수 있는지를 별도로 제어하는 것입니다.
OpenAI는 2026년 6월 4일에 ChatGPT의 새로운 memory synthesis를 설명했습니다. 기억은 명시적으로 저장한 메모뿐만 아니라, 백그라운드에서 통합되는 방향으로 나아가고 있습니다.
원문:
"always provide the freshest, most relevant context"
일본어 번역:
항상 최신의 가장 관련성 높은 컨텍스트를 제공한다.
이는 편리하지만, 사내 시스템에 연결하는 AI에서는 주의점입니다. 채팅 지원을 위한 「자연스러운 기억」과 업무 시스템에서의 「정답으로 취급하는 상태」는 별개이기 때문입니다.
섞었을 때 일어나기 쉬운 사고는 다음과 같습니다.
- 과거의 대화에서 추출된 오래된 전제로 실행됨
- 사용자의 취향 메모와 고객 업무 규칙이 동일한 수준으로 취급됨
- 어떤 판단이 검색 결과 유래이고, 어떤 판단이 기억 유래인지 추적할 수 없음
최소한, 기억은 3개 층으로 나누어 설계하는 것이 안전합니다.
| 층 | 예 | 취급 |
|---|---|---|
| 대화 메모리 | 최근의 주고받음, 작업 중인 전제 | 단기 TTL, 수동 리셋 가능 |
| ... |
memory_policy:
conversational:
ttl_hours: 24
...
OpenAI는 2026년 6월 1일에 OpenAI frontier models와 Codex가 AWS에서 일반 제공되었다고 발표했습니다. 이는 도입 장벽을 낮추지만, 동시에 「기존 인프라에 연결된다」는 것 자체가 리스크가 됩니다.
원문:
"move from evaluation to production with less friction"
일본어 번역:
평가에서 본산 도입으로, 더 적은 마찰로 진행한다.
도입이 간편해질수록 다음과 같은 오해가 늘어납니다.
- Bedrock을 경유하면 자동으로 안전하다
- AWS 내부니까 데이터 경계는 충분하다
- 모델 이용 신청과 본산 VPC 연결 신청을 한꺼번에 해도 된다
실제로는, 모델을 사용할 수 있다는 것과 업무 데이터에 연결해도 된다는 것은 별도의 심사를 거쳐야 합니다.
- 모델 이용 가능 여부
- 연결 대상 S3 / RDS / SaaS의 가능 여부
- 추론 로그의 저장 위치
- 프롬프트에 포함해도 되는 데이터 분류
- 개발 환경과 본산 환경의 자격 증명(Credentials) 분리
integration_review:
model_access:
provider: openai_on_aws
...
Microsoft는 2026년 6월 2일에 기업용 AI는 단일 모델이 아니라, 문맥화·거버넌스(Governance)·관측까지 포함한 시스템으로 다루어야 한다고 설명했습니다.
원문:
"secured and governed by design"
일본어 번역:
설계 단계부터 안전성과 거버넌스를 통합한다.
같은 날의 Build 발표에서는 로컬 에이전트까지 포함한 제어 측면과, 에이전트 루프(Agent Loop)에 제어를 적용하는 사양이 강조되었습니다.
원문:
"a single control plane to observe, govern and secure agents"
일본어 번역:
에이전트를 관측하고, 거버넌스를 적용하며, 안전하게 유지하는 단일 제어면(Control Plane).
여기서 도출할 수 있는 구현 원칙은, 사내 컨텍스트를 일괄 투입하지 않는 것입니다. 회의 메모, 고객 정보, 설계서, 티켓, 감사 로그는 각각 목적이 다릅니다.
나쁜 예:
- 무엇이든 벡터 DB (Vector DB)에 넣기
- 검색 결과(Retrieval results)를 그대로 전부 모델에 전달하기
- 개발 지원 AI와 영업 지원 AI에 동일한 권한 세트 사용하기
좋은 예:
- 용도별로 검색 인덱스 (Retrieval index)를 분리하기
- PII (개인정보)를 마스킹한 파생 인덱스 만들기
- 에이전트(Agent) 종류별로 읽을 수 있는 데이터 소스를 변경하기
| 에이전트 종류 | 읽어도 되는 것 | 읽게 해서는 안 되는 것 |
|---|---|---|
| 개발 지원 | 설계서, issue, CI 로그 | 고객 개별 정보, 매출 장부 |
| ... |
Anthropic은 2026년 6월 3일에 AI를 사용한 사이버 위협의 1년 치 분석을 공개했습니다. 주목할 점은 AI 이용이 초기 침입보다 그 이후의 복잡한 공정으로 확산되고 있다는 것입니다.
원문:
"Cyberattacks are becoming more autonomous"
한국어 번역:
"사이버 공격은 더욱 자율적으로 변하고 있다."
또한 같은 날, AI는 공격자의 기술 격차를 보이지 않게 만들며, AI를 어느 공정에서 사용하는가가 리스크 판단에 더 효과적이라고 언급했습니다. 즉, 방어 측은 '누가 사용하는가'뿐만 아니라 '어디까지 연결하여 실행할 수 있는가'를 감시해야 합니다.
이 관점을 자사의 AI 운영으로 돌려보면, 다음과 같은 분리가 필요합니다.
- 생성과 실행을 분리
- 제안과 적용을 분리
- 초안과 공개를 분리
- 탐지와 수정 반영을 분리
| 실패 패턴 | 무엇이 위험한가 | 대안 |
|---|---|---|
| AI가 만든 SQL을 즉시 실행 | 데이터 파괴 | explain / read-only dry run |
| ... |
Anthropic은 2026년 6월 2일에 Project Glasswing의 확대도 발표했습니다. 여기서 중요한 것은 강력한 모델의 등장 그 자체가 아니라, 병목 현상이 '찾아내는 것'에서 '검증하고 고치는 것'으로 옮겨가고 있다는 점입니다.
원문:
"the bottleneck in cybersecurity is now verifying, disclosing, and patching"
한국어 번역:
"사이버 보안의 병목 현상은 이제 검증, 공개, 그리고 패치에 있다."
AI가 대량의 후보를 낼 수 있게 될수록, 운영은 다음 순서로 막히기 쉽습니다.
- 재현할 수 없음
- 중요도를 판정할 수 없음
- 담당 팀으로 전달되지 않음
- 수정 후의 검증이 따라가지 못함
따라서 방어 계열 AI는 처음부터 하나의 자동화 프로세스로 만들지 않는 것이 안전합니다.
security_ai_lane:
detect:
auto: true
...
- 기억(Memory)을 대화 메모리, 영구 선호도(Persistent preference), 업무 상태로 분리했는가
- 모델 이용 승인과 운영 데이터 연결 승인을 별도 신청으로 분리했는가
- 벡터 DB나 검색 인덱스를 용도별로 나누었는가
- PII나 계약 정보를 마스킹한 파생 데이터를 준비했는가
- 생성, 제안, 적용, 공개의 각 단계에 정지점(Stop point)을 두었는가
- 로컬 에이전트와 클라우드 에이전트의 제어 측면을 나누었는가
- 탐지 AI의 출력을 분류(Triage)할 담당 레이인을 결정했는가
- 실행 로그에 '무엇을 읽었는지', '무엇을 변경했는지'를 남겼는가
2026년 6월 1일부터 6월 4일까지의 1차 정보를 보면, AI 도입의 승부처는 모델 성능 그 자체보다 연결·기억·실행을 어떻게 분리하여 제어할 것인가로 옮겨가고 있습니다.
- OpenAI의 memory 강화는 편리함과 동시에 기억 경계(Memory boundary)의 재설계를 요구한다
- OpenAI on AWS는 도입 마찰을 줄이는 만큼 연결 심사의 세밀도를 높일 필요가 있다
- Microsoft는 AI를 단일 기능이 아닌 제어 가능한 시스템으로 다루는 방향을 강화하고 있다
- Anthropic은 공격 측도 방어 측도 AI를 깊은 공정에서 사용하는 시대에 진입했음을 보여준다
AI를 사내에 연결하기 전에 가장 먼저 만들어야 할 것은 거대한 기반이 아닙니다.
무엇을 기억해도 되는지, 무엇에 연결되어도 되는지, 어디서 멈춰야 하는지를 정의한 분리 규칙입니다. 이곳이 모호한 상태에서 연결 수만 늘리면, 편리함보다 사고 비용이 먼저 쌓이게 됩니다.
다음은 참고할 만한 자료들입니다:
- https://openai.com/index/chatgpt-memory-dreaming/
- https://openai.com/index/openai-frontier-models-and-codex-are-now-available-on-aws/
- https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/
- https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/
- https://www.anthropic.com/news/AI-enabled-cyber-threats-mitre-attack
- https://www.anthropic.com/news/expanding-project-glasswing
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기