자체호스팅 AI 에이전트 플랫폼의 운영 아키텍처

통제권을 얻으면 운영 책임도 함께 들어온다

Rakazo는 모델과 실행환경을 직접 선택해 사내에 배치하는 오픈소스 자체호스팅 에이전트 플랫폼이다. 규제 산업이나 온프레미스 환경처럼 데이터 반출이 제한되는 조직에서는 상용 서비스의 성능이 좋아도 선택 자체가 불가능할 수 있다.

자체 운영 스택은 데이터가 조직 경계를 넘지 않도록 하고, 모델 선택과 버전 고정을 조직이 통제하게 한다. 반면 모델 교체, 성능 튜닝, 장애 대응, 업그레이드는 모두 내부 운영의 몫이 된다. 이 선택은 성능 비교보다 통제권과 운영 부담을 어떻게 교환할지의 문제에 가깝다.

운영을 시작하려면 인프라 관리와 모델 평가를 함께 맡을 역할이 필요하다. 모델 추상화, 런타임 교체, 자격증명 관리, 실행 격리, 성능 프로파일, 대체 전환, 자원 스케줄링, 감사 로그를 개별 기능으로 두지 않고 하나의 운영 체계로 묶어야 한다.

플랫폼 내부에서 분리해야 할 경계

모델 요청과 응답은 내부 규격으로 고정하고, 모델별 차이는 어댑터 뒤로 숨긴다. 특정 모델의 고유 기능을 내부 규격 밖으로 노출하기 시작하면 추상화 계층은 이름만 남는다.

실행 백엔드도 설정으로 교체할 수 있어야 한다. 다만 토큰 계량, 중단 처리, 스트리밍 지원은 백엔드마다 다르므로 교체 시 확인할 항목을 미리 관리해야 한다.

외부 서비스 연결용 자격증명은 내부 저장소에서 발급하고 회수한다. 실행 컨텍스트에 평문으로 남기지 않는 것이 중요하다. 로그와 프롬프트 역시 자격증명이 새어 나갈 수 있는 경로다.

작업마다 파일 시스템과 네트워크 접근 범위를 제한한 실행 환경을 만들고, 작업 간 상태가 섞이지 않게 한다. 자체 운영 환경에서는 한 작업의 잔여 파일이 다음 작업의 입력이 되는 사고가 흔하다.

모델 선택은 작업 유형별 정확도, 지연, 자원 사용량을 기록한 성능 프로파일을 바탕으로 이뤄져야 한다. 이 기록이 없으면 모델 교체 판단은 감에 의존하게 되고, 되돌릴 근거도 남지 않는다.

주 모델이 응답에 실패하거나 지연이 초과되면 대체 모델로 넘기는 경로가 필요하다. 이때 대체 모델의 품질 차이는 사용자에게 알려야 한다. 조용한 전환은 품질 저하의 원인을 추적하기 어렵게 만든다.

GPU와 메모리는 작업 등급별로 배분하고 대기 큐를 관리한다. 배치 작업이 대화형 작업을 밀어내지 않도록 우선순위도 분리한다. 요청, 모델 선택, 도구 호출, 결과는 실행 단위로 남기되, 감사 로그가 민감한 데이터의 사본이 되지 않도록 기록 범위와 보관 기간을 함께 통제해야 한다.

⤢✕

운영 범위를 먼저 확정하는 도입 방식

데이터 반출 제약은 법적 근거와 함께 목록으로 정리한다. 조직 경계를 넘을 수 없는 데이터뿐 아니라 제약이 없는 데이터도 표시해야 한다. 모든 데이터를 반출 불가로 처리하면 자체 운영 범위가 불필요하게 커진다.

현재 업무에서 수용 가능한 정확도와 응답 시간은 숫자로 기준선을 정한다. 기준선 없이 후보 모델을 비교하면 더 큰 모델이 항상 정답처럼 보이고, 인프라 규모는 과대해지기 쉽다.

후보 모델은 조직 데이터로 만든 평가 세트로 비교한다. 공개 벤치마크 순위가 조직의 도메인 성능을 대신해 주지는 않는다. 평가 세트는 모델을 교체할 때마다 새로 만들 대상이 아니라, 비교 가능성을 유지하기 위한 자산으로 관리한다.

동시 실행 수와 모델 크기에서 GPU 수와 메모리를 역산하고, 피크 대비 여유분도 정한다. 여유가 없으면 대체 모델 전환이 작동할 자원도 남지 않는다.

인프라 운영, 모델 평가, 보안 통제는 역할을 명시적으로 배치한다. 한 사람이 이 역할을 겸하는 구조는 도입 초기에는 가능하지만, 확장 시점에는 역할 분리 계획이 필요하다.

플랫폼 버전과 모델 버전은 분리해 갱신하고 각각의 되돌림 경로를 확보한다. 업그레이드 전후에는 성능 프로파일을 비교한다. 오픈소스 플랫폼의 메이저 갱신은 동작 변화를 동반한다.

신규 모델 도입, 자격증명 발급 범위, 감사 로그 보관 정책은 승인 대상으로 두고, 격리 실행 경계의 설정 변경은 보안 검토 항목으로 편성한다.

관리형 서비스와 비교할 때 남는 선택 기준

구분	자체호스팅 플랫폼	상용 관리형 서비스
데이터 통제	완전	계약 의존
운영 부담	높음	낮음
모델 선택권	넓음	제공 범위 내
초기 투자	큼	작음
성능 상한	인프라 의존	벤더 최적화
정책 변경 노출	없음	있음

자체호스팅은 데이터가 조직 경계를 넘지 않아 규제 요건을 구조적으로 충족할 수 있다. 모델과 버전을 조직이 고정할 수 있으므로 벤더의 모델 폐기나 가격 변경에도 영향을 받지 않으며, 감사 로그를 내부에 둬 조사 요구에 직접 대응할 수 있다. 대신 하드웨어 투자와 운영 인력이 선행 비용으로 들고, 최적화·모니터링·장애 대응은 전부 내부 책임이 된다. 최신 모델의 성능을 따라가려면 인프라도 계속 늘려야 한다.

상용 관리형 서비스는 초기 투자 없이 시작할 수 있고 사용량에 따라 비용이 붙는다. 벤더가 최적화와 가용성을 책임지며 최신 모델도 자동으로 제공된다. 그러나 데이터가 외부 인프라를 경유하므로 규제 산업에서는 도입 자체가 막힐 수 있다. 모델 폐기나 정책 변경은 통보만으로 이뤄질 수 있고, 장애가 발생했을 때 대응 수단은 문의에 한정된다.

반출 불가 데이터가 실제로 있는 조직에는 선택지가 많지 않다. 그렇지 않은 조직이라면 운영 인력을 확보할 수 있는지가 실질적인 판단 기준이 된다.

모델 교체가 가능한 추상화는 성능이 역전되거나 가격이 바뀌었을 때 어댑터 교체로 이전할 수 있게 한다. 작업 유형별로 서로 다른 모델을 배치해 비용과 품질을 함께 조정할 수도 있고, 한 모델의 장애가 서비스 전체를 멈추게 하지 않는다. 반면 모델 고유 기능을 활용하기 어려워 최적화 여지는 공통 분모로 줄며, 어댑터별 동작 차이를 흡수하는 코드와 모델 수만큼의 테스트 대상이 쌓인다.

단일 모델에 고정하면 프롬프트와 도구 정의를 해당 모델에 맞춰 최적화할 수 있고, 구현과 테스트도 단순해지며 성능 특성은 일관된다. 하지만 모델을 바꿔야 하는 시점에는 프롬프트와 평가 세트를 통째로 다시 만들어야 하고, 이전 비용이 한꺼번에 발생한다. 모델 이전이 실제로 필요한지 조직의 위험 성향부터 판단해야 한다.

오픈소스 플랫폼 채택은 실행 격리, 도구 연동, 스케줄링처럼 직접 만들면 오래 걸리는 기반을 활용할 수 있어 도입 속도가 빠르다. 커뮤니티의 결함 수정과 기능 추가를 받을 수 있고, 유지보수 인력이 떠난 뒤에도 외부 지식으로 이어갈 여지가 있다. 다만 조직 고유 요건과 맞지 않는 부분은 우회하거나 포크해야 하며, 상류 갱신을 따라가는 부담은 계속된다. 프로젝트가 중단되면 그 시점의 코드가 그대로 부채가 된다.

자체 개발은 조직 요건에 정확히 맞출 수 있고, 불필요한 기능이 없어 공격면과 운영 대상이 좁다. 내부 표준과도 자연스럽게 통합할 수 있다. 그러나 기반을 처음부터 만드는 데 상당한 기간이 들고 그동안 도입 효과는 나오지 않으며, 만든 사람이 떠나면 유지가 어려워진다. 요건 적합도의 격차를 포크로 메울 수 있는지가 선택의 기준이다.

아키텍처와 운영 통제가 만나는 지점

모델 추상화 계층과 런타임 교체 인터페이스는 계층 분리와 의존성 역전을 적용한 구조다. 대체 모델 전환 경로는 이중화와 축퇴 운전 설계에 해당한다.

작업 격리 실행 경계와 자격증명 내부 관리는 접근 통제와 자격증명 보호 요건을 구현한다. 감사 로그를 내부에 보관하면서 기록 범위를 통제하는 일은 로그 관리 통제와 개인정보 최소 수집 원칙이 만나는 지점이다.

성능 프로파일 수집과 업그레이드 전후 비교는 변경 관리와 성능 관리를 결합한 절차다. 자원 할당 스케줄러와 우선순위 분리는 용량 관리와 서비스 수준 관리의 실행 수단이 된다.

자체호스팅 운영이 향하는 방향

규제 산업의 에이전트 도입에서는 온프레미스 자체호스팅이 기본 검토안으로 올라오는 방향이다. 모델 추상화 계층을 갖춘 오픈소스 플랫폼이 늘면서 모델 교체 비용은 실질적으로 낮아지는 흐름도 있다.

조직 내부 평가 세트를 자산으로 관리하는 관행은 모델 선정 절차의 필수 요소로 자리 잡는 방향이다. 자체호스팅 운영 인력의 역할 정의 역시 채용 요건으로 명문화되며 직무가 분화되는 흐름이다.

데이터를 외부로 내보낼 수 없는 조직은 성능이 좋아도 상용 서비스를 사용할 수 없다. 자체호스팅 플랫폼은 그 선택지를 실행 가능하게 하지만, 통제권을 얻는 만큼 최적화와 가용성의 책임도 함께 받아야 한다. 모델 추상화, 격리 실행, 성능 프로파일, 내부 감사 로그는 최소 구성으로 볼 수 있으며, 특히 로그의 보관 범위와 기간은 설계 단계에서 정해 두어야 한다.