현장의 AI와 사내 문서의 AI를 어디서 나눌까. Cor.주식회사의 설계 판단

안녕하세요, Cor.주식회사의 데라다입니다.

현장의 AI와 사내 문서의 AI를 어디서 나눌까요. 로컬 AI 상담에서는 이 둘이 하나로 말해지기도 합니다.

하나는 카메라나 센서 가까이에서 움직이는 AI입니다. 다른 하나는 사내 문서와 업무 데이터를 다루는 로컬 LLM입니다.

둘 다 외부 클라우드로의 전송을 줄이는 구성을 고를 수 있습니다. 그것만으로 같은 환경에 모아도 되는 것은 아닙니다. Cor.주식회사에서는 무엇에 연결되고, 무엇을 다루며, 문제가 나면 어디까지 영향이 가는지를 따로 봅니다.

중시하는 조건

현장 AI에서는 입력을 받고 판단을 돌려주기까지의 시간과, 통신이 끊겼을 때의 동작을 봅니다. 기계를 움직이는 용도에서는 이상일 때 안전 쪽으로 옮길 수 있는 것도 빠질 수 없습니다. 멈추지 않는 것만이 정답은 아닙니다.

현장에서 함께 보는 것은 멈추지 않는 것(가용성), 늦지 않는 것(실시간성), 위험할 때 안전하게 멈출 수 있는 것입니다.

사내 문서를 다루는 AI에서는 누가 어느 문서를 볼 수 있는지가 큰 논점입니다. 담당이 바뀌었을 때 권한을 뗄 수 있는가. 뗀 권한이 검색과 답변에도 반영되는가. 필요한 조작을 나중에 확인할 수 있는가.

현장 AI에도 권한 관리가 필요합니다. 사내 LLM에도 응답 시간과 안정된 가동이 필요합니다. 설계에서 특히 보는 곳이 다릅니다.

신뢰 경계

같은 클러스터에 있다는 것이 위험한지 아닌지의 결론은 아닙니다. 장비가 다르다는 것도 안전의 증명은 아닙니다.

같은 기반 위에서도 네트워크 분리, 인증과 인가, 워크로드 격리로 경계는 설계할 수 있습니다. NIST의 제로 트러스트는 물리적 장소나 네트워크상의 위치만으로 신뢰하지 않는 생각입니다.

현장 장비를 단일 클러스터에 무조건 참여시키면 경계가 모호해집니다. 공통 접근 권한, 인증 정보, 관리 경로를 이유를 확인하지 않고 공유하면 영향 범위가 넓어집니다. 현장에 둔 장비가 사내 문서에 가까운 곳까지 닿을 수도 있습니다.

구성도 위에서는 가는 선 하나입니다. 운용에서는 큰 차이입니다.

숫자를 모으는 방식

대수와 속도의 숫자를 더하면 자료는 보기 좋아집니다. Cor.주식회사에서는 다른 용도로 움직이는 장비를 한 시스템의 대수에 더하지 않습니다. 조건이 다른 측정값도 하나로 묶지 않습니다. 무엇을 잰 숫자인지 알 수 있는 형태로 둡니다. 이것은 자사의 집계 규칙입니다. 다른 사람의 의도는 여기에 쓰지 않습니다.

경계가 모호하면 다음을 설명할 수 없게 됩니다. 이 에지 장비가 멈췄을 때 사내 LLM의 어느 이용에 영향이 가는가. 이 장비의 계정을 멈추면 어디까지 멈추는가.

지금의 방침

Cor.주식회사가 지금 고르는 것은 다음의 나누기입니다. 방침이지, 나누어 두었으니 안전하다는 뜻은 아닙니다.

• 피지컬 추론 에지는 에지 전용으로 설계한다
• 사내 로컬 LLM의 본선 클러스터에는 올리지 않는다
• 대외 설명에서도 본선의 구성이나 성능 이야기에 에지 장비를 섞지 않는다
• 둘 사이에 데이터를 넘길 때는 넘기는 내용과 경로를 건별로 정한다

에지에서 나온 결과를 업무 쪽에서 쓰고 싶다는 요청은 있습니다. 그때도 「같은 클러스터에 있으니 자유롭게 읽을 수 있다」로 하지 않습니다.

설명용 예

현장의 검사 결과를 사내 업무에서 쓰고 싶은 경우를 생각합니다. 이것은 설명을 위한 구성 예입니다. Cor.주식회사가 구현을 끝낸 기능도, 고객 사례도 아닙니다.

검사 ID와 시각과 판정 결과만으로 업무가 진행된다면, 영상 전체나 현장 단말로의 자유로운 연결은 넘기지 않아도 될 수 있습니다. 이미지가 필요한 용도라면 그 필요와 다루는 범위를 먼저 확인합니다.

「같은 회사 안에 있으니 읽을 수 있다」로 하지 않습니다. 「이 용도에 필요하니 이 내용만 넘긴다」로 합니다. 이용을 멈춘 뒤에 연결이 거부되는지, 한쪽이 멈추면 다른 쪽에 어떻게 영향이 가는지는 구성마다 확인하는 항목입니다. 이 글은 그 확인이 끝났다고 쓰지 않습니다.

시뮬레이션에서 본 것

Cor.주식회사에서는 수박 깨기처럼 몸을 쓰는 과제를 소재로 피지컬 추론을 검증하고 있습니다. 현재는 시뮬레이션에서의 검증입니다. 이 검증 환경도 사내 문서를 다루는 환경과 떼어 두는 방침입니다.

실험에서도 정보의 취급을 모호하게 두지 않습니다. 시뮬레이션에서 확인한 것을 실기의 안전성이나 성능의 증명으로 하지 않습니다. 실기의 안전성과 성능은 따로 확인이 필요합니다. 여기는 미확인입니다.

성능과 운용

속도는 중요합니다. 필요한 시간 안에 답이 돌아오지 않으면 업무에 쓸 수 없습니다. 추론 성능은 Cor.주식회사가 연구개발에서 힘을 주는 곳입니다. 속도는 환경과 용도에 따라 크게 달라집니다.

속도만으로는 업무에 쓸 수 있는지가 정해지지 않습니다. 답이 빨라도, 보면 안 되는 문서가 나오거나, 이용을 멈출 수 없거나, 장애 때의 대응이 정해져 있지 않으면 곤란합니다.

목표로 하는 것은 성능 요건을 충족하는 것에 더해, 안전하게 운용할 수 있는 구성까지 함께 확인하는 것입니다. 어떤 환경에서든 안전하게 운용할 수 있다는 보증은 아닙니다.

누가, 어디까지, 언제까지 쓸 수 있는지를 설명할 수 있는 것. 경계, 권한, 실효, 안전성까지 포함해 설계하는 것입니다.

로컬에 둔다고 자동으로 안전해지지는 않습니다. 기존 설비를 출발점으로, 로컬에서 처리할 범위와 업무에 맞는 구성을 생각합니다.

책임의 범위

클라우드도 공동 책임 모델입니다. 접근 권한과 데이터 관리는 원래 이용자 쪽의 책임으로 남습니다. 나눔의 내용은 서비스 형태에 따라 다릅니다. 참조한 것은 AWS가 공개한 설명의 한 예입니다.

로컬로 하면 거기에 기반의 물리적 관리와 운용까지 더해집니다. 자사에서 긋는 선이 그만큼 늘어납니다. 그 선을 하나씩 설명할 수 있는 상태로 두는 것. Cor.주식회사에서는 그곳을 소중히 합니다.

심사의 상태

Cor.주식회사는 ISMS를 운용하고 있습니다. 2026년 10월에 ISO/IEC 27001 2단계 심사를 마쳤습니다. 인증 등록은 2026년 12월경의 예상입니다. 심사의 상태와, 개별 시스템에서 무엇을 검증했는지는 나누어 전합니다.

연결하는 범위

현장 AI와 사내 문서 AI를 나누는 것은 연결을 그만두기 위해서가 아닙니다. 필요한 곳만 이유가 있는 형태로 연결하기 위해서입니다.

누가, 무엇을, 언제까지 쓸 수 있는가. 연결을 멈추면 어떻게 되는가. 문제가 났을 때 어디까지 영향이 가는가. 이 설명을 구성도뿐 아니라 설정과 확인 결과까지 잇는 방침입니다. 확인 결과가 아직 없는 항목은 있는 것처럼 쓰지 않습니다.

사내 문서와 현장 데이터를 AI로 다루고 싶지만 연결 범위를 정하지 못한 분은, 대상 업무와 지금 구성의 개요부터 상담해 주십시오. 첫 상담에 기밀 문서나 인증 정보를 보낼 필요는 없습니다.

참고 자료

• NIST SP 800-207: Zero Trust Architecture - 네트워크상의 위치를 암묵의 신뢰로 두지 않는 생각(2026년 10월 29일에 개요를 확인)
• AWS: Shared Responsibility Model - 클라우드 책임 분담의 한 예. 분담은 서비스 형태에 따라 다름(2026년 10월 29일 확인)
• Cor.주식회사: 보안 - ISMS를 운용하고 있으며, 2026년 10월에 ISO/IEC 27001 2단계 심사를 마치고, 2026년 12월경에 인증 등록을 예상한다는 점