한화솔루션의 Amazon Bedrock 기반 Claude Cowork 전사 도입 여정 — 사내 LLM Gateway로 완성한 거버넌스

이 블로그는 한화솔루션 분석/AI팀과 AWS의 협업으로 작성되었습니다

한화솔루션은 사내 임직원과 개발자가 Claude 기반 도구(Claude Cowork, Claude Code)를 안전하고 통제 가능한 방식으로 사용할 수 있도록, Amazon Bedrock 위에 단일 사내 LLM Gateway를 구축했습니다. 특히 Claude Cowork를 AWS 기반으로 전사에 안정 배포한 것은 국내 첫 사례입니다. 이 게이트웨이는 계열사별로 분리된 여러 인증 체계를 하나로 수용하는 멀티테넌트 인증에서 출발해, 엔터프라이즈 클라이언트 환경의 현실적 제약을 넘고, 조직별 비용 집계와 보안 정책을 중앙에서 강제하는 데까지 나아갔습니다. 이 글은 게이트웨이를 만든 배경과 모델·플랫폼 선택 근거, 아키텍처와 핵심 구현, 그리고 직접 부딪혀 본 뒤에야 알게 된 시행착오까지를 순서대로 담았습니다.

1. 들어가며

기획자가 보고서 작성에 Claude Cowork를, 개발자가 코드 리뷰에 Claude Code를 쓰기 시작하면 조직에는 곧 하나의 질문이 생깁니다. 임직원이 각자 알아서 쓰게 둘 것인가, 아니면 회사가 안전한 경로를 하나 만들어 모두가 같은 규칙 위에서 쓰게 할 것인가. 전자는 빠르지만 사내 코드·설계 문서가 통제 없이 외부로 나가고 입력 이력도 비용도 남지 않습니다. 한화솔루션은 후자를 선택했고, 이 글에서는 그 선택을 실제 인프라로 구현한 과정을 담습니다.

한화솔루션 소개

한화솔루션(Hanwha Solutions)은 한화그룹 계열의 종합 에너지·소재 기업으로, 케미칼·큐셀·인사이트·Q ENERGY·Wire & Cable 부문과 다수 해외법인으로 구성되어 있습니다.

이 사례에서 특히 중요한 것은 조직 구조입니다. 다수의 계열사와 글로벌 법인을 운영하는 특성상, 신원 인증의 기반인 Microsoft Entra ID 테넌트가 물리적·논리적으로 분리된 복합 환경입니다. “단일 회사 = 단일 디렉터리”라는 전제로는 전사적 AI 통합이 불가능하며, 뒤에서 다룰 멀티테넌트(Multi-tenant) 인증 설계는 이 현실을 수용하기 위한 전략적 선택이었습니다.

이 글에서 다루는 내용

한화솔루션이 다룬 문제는 임직원과 개발자가 Claude Cowork와 Claude Code를 회사의 통제 아래 안심하고 쓰게 만드는 것이었습니다. 개별 도구를 배포하는 대신, 모든 AI 호출이 반드시 거쳐 가는 단일 관문인 사내 LLM Gateway를 Amazon Bedrock 위에 구축했습니다. 특히 비개발 임직원까지 아우르는 Claude Cowork를 전사에 배포하면서 거버넌스까지 함께 갖춘 점이 이 사례의 차별점입니다.

이 게이트웨이는 계열사별로 분리된 Entra ID 테넌트를 하나의 인증 체계로 수용하고, 엔터프라이즈 엔드포인트(주로 Windows) 환경의 도입 장벽을 넘으며, 조직별 비용 집계를 포함한 보안·비용 거버넌스를 중앙에서 강제합니다. 이어지는 장에서는 게이트웨이를 만든 배경, Claude와 Amazon Bedrock을 선택한 이유, 실제 구현 방식을 다룹니다.

2. 배경 및 도전 과제

도입 배경: 엔터프라이즈 AI 거버넌스 확보와 아키텍처의 진화

생성형 AI의 업무 효용성이 입증되며 현업의 AI 도구 활용 요구가 폭발적으로 증가했습니다. 하지만 임직원이 개별적으로 외부 AI 서비스를 사용하면 엔터프라이즈 IT의 세 가지 필수 요건, 즉 민감 데이터의 외부 유출 방지(Data Protection), 사용자별 프롬프트·사용 이력 감사(Auditability), 전사 AI API 비용·사용량 최적화(FinOps)를 충족하기 어렵습니다. 특히 석유화학·태양광 분야의 공정 노하우가 핵심 경쟁력인 한화솔루션에서는 프롬프트에 담긴 설계 값이나 코드 한 조각이 곧 영업 비밀이므로, 보안과 거버넌스는 타협할 수 없는 과제입니다.

이에 한화솔루션은 외부 상용 AI 도구가 엔터프라이즈 수준으로 성숙하기를 기다리는 동안 사내 자체 플랫폼(Agent H)을 선제적으로 구축·운영했습니다. 임직원이 통제되지 않은 외부 서비스 대신 회사 보호망 안에서 AI를 경험하게 하는 가교 역할을 통해, 기술 성숙을 기다릴 시간을 벌면서 데이터 유출 방지와 사용량 통제의 기반을 마련했습니다.

이후 외부 상용 생태계가 성숙하고 현업 요구가 다변화되면서, 단일 사내 플랫폼을 넘어 다양한 외부 도구를 안전하게 포용하는 아키텍처 전환이 필요해졌습니다. 특히 내부 데이터를 능동적으로 조회하고 업무를 수행하는 ‘AI 에이전트’ 활용이 본격화되면서, 다수 글로벌 법인을 아우르는 통합 거버넌스의 중요성도 함께 커졌습니다.

자체 플랫폼 운영 경험은 방향을 분명히 했습니다. 도구를 각각 배포하는 파편화된 방식으로는 고도화된 엔터프라이즈 요건을 감당할 수 없다는 것입니다. 결국 사내 플랫폼, 개발자 도구, 향후 추가될 애플리케이션의 모든 AI 호출을 단일 통제 지점으로 모으는 ‘API 게이트웨이’ 아키텍처로 전략을 정했습니다.

프로젝트 목표

한화솔루션은 임직원과 개발자가 승인된 단일 경로로만 Claude 기반 도구에 접근하도록 하는 사내 LLM Gateway 구축을 목표로 삼았습니다. 이 게이트웨이는 네 가지 요건을 동시에 만족해야 했습니다.

• 안전성: 사내 민감 데이터가 모델 학습에 사용되지 않고, 전 구간 암호화 및 유해·민감한 정보 사전 필터링
• 통합 인증: 계열사별로 분리된 여러 Entra ID 테넌트를 단일 게이트웨이가 수용하되 허용된 테넌트만 통과
• 거버넌스와 가시성: 모든 프롬프트 호출의 감사 로그화, 조직·사용자 단위 사용량·비용 집계
• 실사용 경험: 평소 쓰던 Claude Desktop 클라이언트를 거의 그대로 쓰면서 배후에서 통제가 투명하게 적용

목표는 분명했습니다. 개인 단위의 AI 활용을 넘어 조직 전체가 협업하는 AI 환경을 만들어 생산성을 높이고, 업무 자동화로 불필요한 부담을 줄여 사업 경쟁력으로 잇는 것이었습니다.

이를 실행 목표로 구체화해, 착수 후 1개월 이내에 미국·한국 법인에 Claude Cowork를 도입·안정화한다는 목표를 세웠습니다. 한 번에 전사 배포하는 대신 선도 조직을 1차 대상으로 PoC를 조기 추진해 파일럿 운영과 안정화를 병행하고, 검증 결과를 바탕으로 단계적으로 확산했습니다. PoC의 목표는 ① 전사 단위 Cowork 협업 환경 구축, ② 수백 명 규모 배포·안정화, ③ 데이터 주권(Data Sovereignty)을 포함한 전사 확장용 인프라 구축이었습니다.

도입 속도 역시 목표의 일부였습니다. Amazon Bedrock 환경의 Claude Cowork는 2026년 4월 21일 처음 이용 가능해졌고, 한화솔루션은 글로벌 엔터프라이즈 최초 도입을 목표로 지원 개시 직후 착수해 한 달여 만에 구성을 완료했습니다. Claude Cowork의 서드파티(3P) 추론이 7월 9일 정식 출시(GA)될 때 이미 전사 배포와 안정화를 마친 운영 단계였습니다.

3. Claude on Amazon Bedrock을 선택한 이유

게이트웨이의 목표가 정해진 뒤 남은 선택은 두 가지였습니다. 어떤 모델을 쓸 것인가, 그 모델을 어디서 호출할 것인가. 한화솔루션은 사내 초기 도입 AI 모델로 Claude를, 실행 기반으로 Amazon Bedrock을 선택했습니다.

3.1 Claude를 선택한 이유

주 사용 시나리오가 문서·업무 협업(Claude Cowork)과 코드 작성·리뷰(Claude Code)였던 만큼, 코딩 성능과 긴 컨텍스트 처리, 한국어를 포함한 다국어 품질, 안전성이 핵심 평가 축이 되었습니다. 다만 선택을 뒷받침한 것은 벤치마크 수치만이 아니라, 그 역량을 임직원이 실제 업무에서 느끼게 해준 두 가지 요인이었습니다.

첫째는 데스크탑 애플리케이션입니다. 임직원이 쓰는 클라이언트 앱은 Claude Desktop이며 Chat·Cowork·Code 세 모드를 제공합니다. 이 중 문서·업무 협업을 담당하는 Cowork가 전사 도입의 중심이 되었고 개발자를 위한 Code가 함께합니다. 명령줄 도구는 문서 업무 중심 임직원에게는 진입장벽인 반면 Claude Desktop은 익숙한 GUI에서 곧바로 실행되며, 모델 성능이 뛰어나도 거기 다다르는 경로가 복잡하면 채택률은 떨어지므로, 앱의 완성도 역시 무시할 수 없는 요소였습니다.

둘째는 하네스 엔지니어링(Harness Engineering)의 완성도입니다. 하네스는 모델이 파일을 읽고 쓰고, 도구를 호출하고, 여러 턴의 작업을 스스로 계획·실행하도록 감싸는 실행 환경으로, 같은 모델이라도 설계에 따라 에이전틱 작업의 성공률이 크게 갈립니다. Claude Code는 Anthropic이 하네스를 모델과 함께 직접 설계·운영하기에 도구 호출 신뢰성과 장기 작업의 맥락 유지가 두드러졌고, 우리에게는 벤치마크 점수보다 긴 작업을 끝까지 완수하는지가 더 실질적인 기준이었습니다.

현재 게이트웨이는 용도와 비용·성능 트레이드오프에 따라 Claude Fable 5, Opus 5, Sonnet 5, Haiku 4.5를 함께 제공하며, 교차 리전 추론(Cross-Region Inference)으로 가용성과 처리량을 확보합니다.

3.2 Amazon Bedrock을 선택한 이유

모델을 Claude로 정한 뒤에도 이를 어디서 호출할지는 별개의 결정입니다. Amazon Bedrock은 단일 API로 Claude를 포함한 여러 파운데이션 모델을 제공하는 완전관리형 서비스이며 서울 리전(ap-northeast-2)에서도 사용할 수 있습니다.

게이트웨이 관점의 근거는 네 가지 표준 보안 기능이었습니다. ① 데이터 비학습·암호화 — 입력·출력을 모델 제공사와 공유하거나 학습에 쓰지 않고, 저장하지 않으며 전송 중·저장 시 모두 암호화합니다(Data protection). ② 프라이빗 연결 — PrivateLink VPC 엔드포인트로 공용 인터넷을 거치지 않습니다. ③ 최소 권한·감사 — 특정 모델 ARN에 InvokeModel만 허용하는 IAM 정책과 CloudTrail 로깅으로 호출 이력을 추적합니다. ④ Guardrails — 6종 안전장치와 프롬프트 인젝션·탈옥 탐지를 제공합니다.

여기에 다섯 번째 근거인 데이터 주권(Data Sovereignty)이 더해집니다. Bedrock을 외부 API로 호출하는 대신 한화솔루션이 소유한 AWS 계정과 VPC 경계 안에서 게이트웨이 전체를 운영했습니다. 프롬프트가 거쳐 가는 인증·감사·캐시 저장소(DynamoDB, Aurora, S3)가 모두 자사 계정 내 자산이므로 Anthropic을 포함한 어떤 외부 사업자도 이 경계 내부에 임의로 접근할 수 없으며, 이는 2장의 세 번째 PoC 목표를 아키텍처 차원에서 실현하는 근거가 되었습니다.

3.3 데이터 보안 요건별 대응

이제 이 선택 위에서 게이트웨이를 어떤 구조로 구성했는지 살펴봅니다.

4. 솔루션 아키텍처

4.1 설계 원칙: “키를 나눠주지 않는다”

가장 먼저 세운 원칙은 누구에게도 장기 API 키를 직접 발급하지 않는다는 것입니다. Claude Desktop은 업무용 PC와 개발자 워크스테이션에서 직접 실행되므로, 사용자가 정적 API 키를 로컬에 보관하면 키 유출·회수 불가·사용량 귀속 불명확이 동시에 발생하고, Cowork처럼 비개발 임직원 PC까지 배포가 확대되면 그 규모는 개발 조직 수준을 훨씬 넘어섭니다. 그래서 “사용자는 회사 계정으로 한 번 로그인하고, 게이트웨이가 그 신원을 근거로 단기 자격 증명을 대신 발급한다”는 구조를 택했습니다. 이 원칙은 멀티테넌트 인증(5.1), 가상 키 라이프사이클(5.2), 조직별 비용 집계(5.3)의 공통 토대입니다.

두 번째 원칙은 중앙 집중형 정책 집행입니다. 모델 접근 권한, 개인정보 보호 정책, 예산 한도, 감사 로깅을 게이트웨이 한 곳에서 강제하므로, 정책 변경 시 수천 대의 엔드포인트가 아니라 게이트웨이 설정만 갱신하면 됩니다.

4.2 전체 구성

• 클라이언트: Claude Cowork / Claude Code
• 인증: 중앙 Bootstrap 서버(디바이스 코드 인증 대행), Microsoft Entra ID, API Gateway + Lambda Authorizer(멀티테넌트 JWT 검증), Token Service Lambda(JWT → 가상 키 교환)
• 프록시·정책·모델: LiteLLM(로드 밸런서 뒤 다중 인스턴스 운영), Bedrock Guardrails, Claude 모델(Fable 5 / Opus 5 / Sonnet 5 / Haiku 4.5)
• 자격 증명·상태: Secrets Manager(Master Key), DynamoDB(가상 키 캐시), Aurora(SpendLogs)
• 감사·관측: S3(Prompt Audit), CloudWatch(EMF + X-Ray, ADOT 사이드카), CloudTrail, AWS Budgets

그림 1. 한화솔루션 LLM Gateway 전체 아키텍처

참고: 이 장은 특정 컴퓨트나 오케스트레이션 방식에 종속되지 않는 요청의 논리 경로 기준으로 서술하며, 동일한 인증·정책 경로는 게이트웨이를 어디에 배치하든 유지됩니다.

4.3 요청 흐름 ①~⑥

프롬프트 입력부터 Amazon Bedrock 응답까지 여섯 단계를 거치며, 각 번호는 그림 1의 경로와 대응합니다.

① 신원 확인 — JWT 획득. 사용자는 Microsoft 365에 한 번 로그인(MFA 포함)합니다. Claude Desktop이 Bootstrap 서버에 접속해 디바이스 코드 방식으로 인증을 시작하면, Bootstrap 서버가 Entra ID 인증을 대신 수행해 JWT(JSON Web Token)를 확보·전달합니다. 계열사마다 테넌트가 분리되어 있어 이 JWT에는 발급 테넌트를 식별하는 tid 클레임이 담깁니다.

② 진입과 테넌트 검증 — API Gateway + Lambda Authorizer. JWT를 Bearer 토큰으로 실어 Token API를 호출하면, Lambda Authorizer가 tid를 허용 테넌트 목록과 대조하고 해당 테넌트의 서명 키로 검증합니다(상세는 5.1).

③ 자격 증명 교환 — Token Service Lambda. 검증을 통과하면 사용자 신원을 근거로 단기 가상 키(Virtual Key)를 발급해 반환합니다. Master Key는 Secrets Manager에 보관되어 노출되지 않고, 발급된 가상 키는 DynamoDB에 캐시됩니다(5.2).

④ 프록시 진입 — LiteLLM. LiteLLM이 키의 유효성·예산·요청 한도를 확인하고 모델명을 Bedrock 모델 식별자로 매핑합니다.

⑤ 정책 집행 — Guardrails. 모델 호출 전후로 프롬프트를 Bedrock Guardrails로 검사해 유해 콘텐츠·프롬프트 공격을 차단합니다(6장).

⑥ 추론과 응답. 통과한 요청은 용도에 맞는 Claude 모델이 처리하고 응답은 역순으로 전달되며, 프롬프트·응답 본문은 S3 감사 로그로, 메타데이터는 CloudWatch 메트릭으로 비동기 기록됩니다(5.3).

4.4 이 구조를 택한 세 가지 이유

결정 1: LiteLLM 앞에 자체 인증 계층을 둔다. LiteLLM은 가상 키 기반 접근 제어는 제공하지만 기업용 SSO에 필요한 JWT 검증은 없습니다. 가상 키 체계는 활용하되 앞단에 JWT를 검증·교환하는 계층을 따로 구현해, 사용자 인증(회사 신원)과 게이트웨이 인가(가상 키)를 독립적으로 진화시킬 수 있게 했습니다.

결정 2: 프라이빗 연결로 데이터 경로를 폐쇄한다. 게이트웨이와 Bedrock 간 통신을 인터페이스 VPC 엔드포인트(PrivateLink)로 연결해 인터넷 게이트웨이나 NAT를 거치지 않으며, 사내 프롬프트가 퍼블릭 인터넷으로 나가지 않아야 한다는 요건에 부합합니다.

결정 3: 감사와 관측을 요청 경로에서 분리한다. 감사 로깅(S3)과 관측 메트릭(CloudWatch)을 비동기 콜백으로 처리해, 로깅 파이프라인에 문제가 생겨도 사용자의 실시간 요청은 영향받지 않습니다.

5. 핵심 구현

이 장은 게이트웨이의 핵심 구현을 세 부분으로 나누어 다룹니다. 분리된 Entra ID를 단일 게이트웨이로 수용하는 멀티테넌트 인증(5.1), 정적 키를 주지 않기 위한 가상 키 라이프사이클(5.2), 그리고 관측성과 조직별 비용 집계(5.3)입니다.

5.1 멀티테넌트 인증 — 분리된 Entra ID를 하나의 문으로

문제: 계열사마다 다른 테넌트

한화솔루션은 케미칼·큐셀·인사이트·Q ENERGY 부문과 다수 해외법인으로 구성되며, 그룹 특성상 Entra ID 테넌트가 조직별로 분리되어 있습니다. 전사 확장을 위해서는 서로 다른 테넌트에서 발급된 토큰을 하나의 게이트웨이가 모두 수용해야 했습니다. 그런데 API Gateway 내장 JWT Authorizer는 단일 발급자만 지원합니다. 테넌트가 여럿이면 발급자 URL도 여럿이므로, 내장 기능만으로는 불가능해 Lambda Authorizer를 직접 구현하기로 했습니다.

해결: tid 기반 Lambda Authorizer

핵심 아이디어는 “서명을 검증하기 전에 tid 클레임을 먼저 읽어, 그 테넌트에 맞는 검증 규칙을 동적으로 선택한다”는 것입니다.

1. Bearer 토큰을 추출한다.
2. 서명 검증 없이 payload만 디코드해 tid를 확인한다.
3. tid가 등록된 계열사 allowlist에 있는지 확인한다. 이 목록은 Systems Manager Parameter Store에 {테넌트 ID: 기대 client ID} 형태로 보관한다.
4. 해당 테넌트의 발급자 URL과 JWKS(JSON Web Key Set)로 서명을 검증하고 iss·aud·exp·nbf·iat를 모두 필수로 강제한다. 알고리즘은 RS256으로 강제해 alg: none이나 HS256 혼동 공격을 차단한다.
5. 승인 시 다운스트림(Token Service)이 쓸 컨텍스트(tid, oid, 이메일, 앱 ID)를 전달한다.

# authorizer/handler.py — 멀티테넌트 JWT 검증 (핵심 발췌)
def handler(event, _context):
    token = _extract_bearer(event)
    unverified = jwt.decode(token, options={"verify_signature": False, "verify_exp": False})
    tid = unverified.get("tid")  # 서명 검증 전 tid 선독
    expected_aud = _load_tenant_app_map().get(tid)  # SSM allowlist 대조
    if not expected_aud:
        return _deny("tenant_not_allowed", tid=tid)
    key = _get_jwks_client(tid).get_signing_key_from_jwt(token).key  # JWKS 테넌트별 캐시
    claims = jwt.decode(token, key, algorithms=["RS256"],  # RS256 강제 검증
        issuer=f"https://login.microsoftonline.com/{tid}/v2.0",
        audience=expected_aud,
        options={"require": ["exp", "iat", "nbf", "iss", "aud"]})
    return {"isAuthorized": True, "context": {"tid": tid,  # 컨텍스트 전달
        "oid": claims.get("oid") or claims.get("sub"),
        "email": claims.get("preferred_username", ""), "app_id": expected_aud}}

위 코드는 개념 전달을 위한 핵심 발췌로, 실제 운영 코드의 예외 처리·보조 함수·캐시 세부는 생략했습니다. 실제 적용 전에는 각 조직의 보안·규정 검토가 필요합니다.

이 설계의 실무적 이점은 신규 계열사 추가가 코드 배포 없이 이루어진다는 점입니다. 온보딩 시 Parameter Store의 테넌트 목록에 한 줄만 추가하면 되고 Lambda 재배포는 필요하지 않습니다. JWKS는 테넌트별로 인메모리 캐시되어 매 요청마다 Entra ID를 조회하지 않으며, 거부 사유는 구조화 로그로 남겨 CloudWatch Metric Filter로 거부율을 모니터링합니다.

IAM Identity Center가 아니라 Entra ID를 단독 IdP로 삼은 이유도 여기에 있습니다. 임직원이 이미 매일 Microsoft 365에 로그인하므로, 기존 로그인 흐름을 재사용하면 별도 인증 수단 없이 자연스러운 경험을 제공할 수 있다고 판단했습니다.

클라이언트 측: 하루 한 번 로그인, 종일 무재인증

인증은 사용자에게 보이지 않아야 합니다. 클라이언트는 매 LLM 호출 직전 로컬 캐시 확인 → JWT 유효성 확인 → 필요 시 Bootstrap 서버 재인증 순으로 동작합니다. 아침에 M365에 한 번 로그인하면 이후에는 팝업 없이 토큰이 갱신되어 종일 재인증 없이 작업할 수 있습니다.

이 구조가 처음부터 이렇지는 않았습니다. 초기에는 클라이언트가 직접 실행하는 apiKeyHelper 스크립트가 MSAL 기반 Silent SSO로 로컬에서 단기 자격 증명을 확보했습니다. 이후 인증 로직을 중앙 Bootstrap 서버로 옮겨, 클라이언트는 Bootstrap URL 호출만으로 인증을 완료하게 되었습니다. 프로토콜도 함께 바뀌었습니다. 초기 OIDC 방식은 사용자 정보가 Claude Desktop에 이미 존재해야 했지만, 디바이스 코드 방식으로 전환하면서 그 제약이 사라졌습니다. apiKeyHelper 구조에서 검증된 “로컬 캐시 → 토큰 확인 → 재발급” 순서는 Bootstrap 전환 후에도 동일하게 유지됩니다. 임직원 입장에서 이 모든 구성은 사내 포털의 셋업 페이지 하나로 시작됩니다. 공식 클라이언트를 내려받은 뒤, LLM Gateway·SSO·MCP 연동이 담긴 표준 보안 구성 패키지를 OS에 맞게 실행하면 위의 인증 체계가 자동으로 적용됩니다.

그림 2. 사내 포털(AGENT H)의 Claude Desktop 셋업 페이지

이 흐름에는 멀티테넌트 환경 특유의 안전장치도 있습니다. JWT의 tid가 해당 PC에 배포된 테넌트 ID와 다르면 경고를 남겨 MDM 배포 실수나 사용자의 조직 이동을 조기에 감지하며, 가상 키(Virtual Key)는 별도의 로컬 캐시 파일로 저장하지 않고 Claude Desktop 메모리 영역에 휘발성 데이터로만 유지해 다른 로컬 사용자의 접근을 원천 차단합니다.

5.2 가상 키 라이프사이클

가상 키를 도입한 이유

“키를 나눠주지 않는다”는 원칙을 구현하는 장치가 가상 키(Virtual Key)입니다. 인증된 사용자는 Token Service Lambda를 통해 단기 가상 키를 발급받고 이 키로만 게이트웨이에 접근하므로, Master Key를 결코 보지 못합니다. 가상 키에는 사용자·조직 단위의 예산과 요청 한도가 묶여 있어 오남용 시 해당 키만 회수하면 됩니다.

Token Service는 Authorizer가 이미 검증한 컨텍스트를 소비하므로 JWT를 다시 검증하지 않으며, 캐시 키를 {tid}:{oid}로 합성해 서로 다른 테넌트의 동일 사용자 ID가 충돌하지 않도록 격리합니다. 발급 응답에는 만료 시각 (expires_at)이 함께 담겨, 클라이언트가 로컬 캐시의 만료를 서버 실만료에 맞춰 정렬합니다.

5.3 관측성과 조직별 비용 집계

실시간 관측 — EMF와 X-Ray

게이트웨이 운영에서 “누가 무엇을 얼마나 쓰는가”를 실시간으로 보지 못하면 비용도 품질도 관리할 수 없습니다. 한화솔루션은 LiteLLM 컨테이너 옆에 ADOT(AWS Distro for OpenTelemetry) 사이드카를 두고, 관측 신호를 두 갈래로 보냅니다. 지표는 CloudWatch EMF(Embedded Metric Format)로, 분산 추적은 AWS X-Ray로 전송합니다. 생성형 AI 표준 지표(gen_ai.*)와 Claude Code 고유 지표(claude_code.*)를 함께 수집해 토큰 사용량·지연·세션 특성을 대시보드로 관측합니다.

중요한 설계 결정은 프롬프트·응답 본문을 관측 신호에 싣지 않는다는 것입니다. 본문은 오직 S3 감사 로그로만 보관하고, OpenTelemetry 경로에는 메타데이터만 흐르게 해(turn_off_message_logging) 관측 파이프라인을 통해 민감한 정보가 새어 나가지 않도록 차단했습니다.

team_id 기반 조직별 비용 집계

멀티테넌트 게이트웨이에서 비용을 조직별로 나누어 보려면 모든 사용량 기록에 “어느 조직인가”라는 축이 있어야 합니다. 우리는 Token Service가 가상 키를 발급할 때 테넌트(tid)를 LiteLLM의 team_id로 매핑하고, 이 team_id가 LiteLLM SpendLogs(Amazon Aurora)에 기록되도록 했습니다. 그 결과 계열사·법인 단위로 토큰 사용량과 비용을 집계할 수 있습니다.

여기에 AWS Budgets로 예산 임계값(예: 실제 사용액 기준 다단계 알림, 예측 기반 알림)을 걸어 초과 징후를 조기에 포착하고, 비상시에는 접근을 차단하는 브레이크글라스(break-glass) 절차를 함께 두었습니다.

그림 3. LiteLLM 관리 포털의 사용량 뷰

6. 보안 및 거버넌스

엔터프라이즈 AI 게이트웨이의 성패는 상당 부분 보안과 거버넌스가 좌우합니다. 이 장에서는 데이터 보호의 전제, 서버 측 정책 강제, 감사·접근 제어를 다룹니다.

6.1 데이터 보호의 전제

토대는 3장의 Bedrock 데이터 비학습·미저장 보장과 4장의 PrivateLink 프라이빗 연결입니다. 다만 모델 제공자가 데이터를 남기지 않더라도 게이트웨이가 스스로 만들어 내는 데이터(감사 로그·가상 키·사용량 기록)는 별도로 보호해야 하므로, 어떤 데이터가 어디에 남는지를 먼저 정리한 뒤 나머지 통제를 설계했습니다.

핵심 원칙은 두 가지입니다. 본문은 감사 목적의 S3 한 곳에만 남기고 관측·비용 저장소에는 싣지 않으며(5.3), 이 모든 저장소가 한화솔루션 명의 계정·VPC 경계 안의 자체 리소스이므로(3장 데이터 주권) 데이터가 머무는 위치를 회사가 통제합니다. 이어서 정책의 서버 측 강제(6.2)와 감사·접근 제어(6.3)를 다룹니다.

6.2 서버 측 정책 강제 — Guardrails

Guardrails를 잘 정의해도 클라이언트가 우회할 수 있다면 의미가 없습니다. Claude Desktop은 스트리밍 InvokeModel 경로로 동작하므로, 클라이언트가 요청 헤더로 Guardrail을 지정하는 방식은 사용자가 헤더를 제거하면 검사가 건너뛰어질 수 있어 정책 평가를 보장하지 못했습니다.

그래서 게이트웨이 서버 측(LiteLLM)에서 Guardrails를 강제하는 방식을 택했습니다. LiteLLM은 모델 호출 직전/후 프롬프트를 Bedrock Guardrails로 검사하며, 이 검사는 클라이언트 설정과 무관하게 항상 수행됩니다. 위반 시 예외를 억제하지 않고 마스킹 또는 HTTP 400으로 반환해 차단 사실을 분명히 전달합니다.요점은 정책 집행 지점을 신뢰 경계 안쪽으로 옮겼다는 것입니다.

이 정책은 LiteLLM의 config.yaml에 선언됩니다. 모델 등록부터 Guardrail 연결, 감사·관측 콜백까지 게이트웨이의 런타임 구성이 이 파일 하나로 모이며, 이렇게 기준이 되는 단일 출처를 흔히 single source of truth라고 부릅니다.

예컨대 사용자가 프롬프트에 고객 개인정보를 입력하더라도 게이트웨이가 이를 익명화해, 모델은 {NAME}·{PHONE}·{EMAIL} 같은 placeholder만 받습니다. 아래 화면에서 모델이 “placeholder 변수가 담긴 템플릿을 받았다”고 응답하는 것이 그 증거입니다.

그림 4. 서버 측 Guardrails의 민감한 정보 익명화

Amazon Bedrock Guardrails는 유해 콘텐츠 필터, 금지 주제, 민감한 정보 필터(개인정보 마스킹·익명화), 그리고 프롬프트 공격(prompt injection·jailbreak) 탐지를 지원합니다. 다만 Claude Code 같은 에이전트형 워크로드는 도구(tool) 정의와 매우 긴 컨텍스트를 포함하는 특성상, 프롬프트 공격 탐지가 정상 요청을 위협으로 오탐할 수 있습니다. 이는 에이전트형 애플리케이션 특유의 도전 과제로, 콘텐츠 필터 강도를 워크로드 특성에 맞게 조정하는 튜닝이 필요합니다.

6.3 감사·접근 제어·최소 권한

S3 프롬프트 감사 로깅

모든 요청·응답의 감사 기록은 Amazon S3에 적재됩니다(LiteLLM success/failure 콜백). 관측 신호에는 본문을 싣지 않고 감사 로그에만 본문을 보관하므로, 민감한 정보가 담긴 감사 로그는 접근 통제·암호화·보존 정책을 엄격히 적용해야 하는 대상입니다. 본문이 담기는 버킷인 만큼, 전송·저장 구간을 모두 암호화하고 비(非)TLS 접근을 원천 차단하는 버킷 정책을 기본값으로 두었습니다.

여기에 저장 시 암호화(SSE-KMS)와 버전 관리·수명 주기(보존 기간 후 만료) 정책을 함께 걸고, 접근 권한은 감사 담당자와 게이트웨이 쓰기 역할로만 제한합니다. 아울러 Amazon Bedrock의 모델 호출 로깅(Model Invocation Logging)을 함께 활성화하면 요청·응답을 S3/CloudWatch Logs에 남겨 플랫폼 차원의 감사 근거를 이중으로 확보할 수 있습니다.

7. 구축 과정의 시행착오 (Lessons Learned)

이 게이트웨이가 안정적으로 동작하기까지 참조 아키텍처만으로는 예측할 수 없었던 여러 벽에 부딪혔습니다. 상당수는 개발자 도구를 소수에게 배포할 때는 드러나지 않다가 Claude Cowork를 전사 임직원의 표준 PC로 확산하는 순간 나타났습니다. 엔터프라이즈 클라이언트 환경, 비용 구조, 멀티테넌트 인증에서 겪은 시행착오를 같은 길을 가려는 조직을 위해 솔직하게 정리했습니다.

7.1 엔터프라이즈 클라이언트 환경이라는 복병 — 보안 SW·세션 이관

무엇이 막혔나. 초기 개발과 검증은 대부분 macOS와 Linux에서 이루어졌지만, 임직원의 실제 업무 단말은 강력한 보안 정책이 적용된 표준 Windows PC였습니다. Cowork의 핵심 시나리오가 Excel·Word·PowerPoint 문서 작업과 맞닿아 있는 만큼 이 환경을 넘지 못하면 전사 배포 자체가 성립하지 않았고, 게이트웨이 쪽 문제가 모두 해결된 뒤에도 정작 사용자 쪽 클라이언트에서 문제가 연달아 드러났습니다. 배포 초기에는 사내 보안 소프트웨어의 실시간 검사와 충돌해 한 번의 요청 처리에 약 8~15초의 지연이 발생했고, 실시간 검사를 수행한 MDS와 Windows Defender에서 실행 파일을 미인가 프로세스로 취급했습니다. 운영이 안정된 뒤에도 인증·배포 체계를 개선하는 과정에서는 사용자들이 쌓아 온 대화 세션을 잃지 않고 옮겨야 하는 숙제가 생겼습니다.

어떻게 풀었나. 문제별로 원인 계층이 달랐기 때문에 해법도 각기 달랐습니다.

• 보안 SW 충돌: 증상만으로는 원인 특정이 어려워, 클라이언트 로그를 구간별로 분석하고 보안 SW 검사 예외를 둔 대조 실험으로 지연 원인을 격리했습니다. 가장 손쉬운 해법인 경로 기반 예외는 해당 폴더의 다른 실행 파일까지 무검사로 통과시키므로 보안팀이 수용할 수 없었고, 경로가 아니라 실행 파일 해시를 보안 SW의 허용 목록(allowlist)에 등재하는 방식을 택했습니다. 특정 바이너리 하나만 신뢰하므로 공격 표면을 넓히지 않으면서, 요청당 지연을 약 8~15초에서 약 1~3초 수준으로 줄였습니다. 클라이언트가 업데이트될 때마다 새 버전의 해시를 등재하는 절차는 운영 프로세스로 정착시켰습니다. 실시간 검사를 수행한 MDS와 Windows Defender에서 실행 파일을 미인가 프로세스로 차단하던 문제도 같은 접근으로 풀었습니다 — 전면 예외가 아니라 해당 실행 파일만 프로세스 허용 목록에 등록했습니다.
• 세션 이관: 그 전환은 새로운 숙제도 만들었습니다. 인증·배포 체계를 로컬 스크립트 방식에서 Bootstrap 중앙 관리로 전환하자, 기존 대화 세션이 목록에는 보이는데 이어가기(resume)는 실패하는 현상이 나타났습니다. 세션 저장 경로 규칙의 동작 차이를 Anthropic에 문의하여 파악한 뒤, 자체 제작한 설치 도구에 기존 세션을 새 경로 규칙에 맞게 옮기는 이관 로직을 구현·검증해, 사용자들의 작업 맥락을 잃지 않은 채 전환을 마쳤습니다.

교훈. 게이트웨이 아키텍처가 아무리 견고해도, 사용자 채택은 엔드포인트에서 결정됩니다. 엔터프라이즈 표준 PC에는 백신, EDR, 보안 솔루션이 겹겹이 쌓여 있어 개발 환경에는 없던 문제가 배포 직전에야 드러나고, 체계를 개선할 때마다 사용자가 쌓아 온 상태(세션)를 어떻게 보존할지도 함께 설계해야 합니다. 보안 예외를 요청할 때는 “경로 예외가 아니라 해시 예외”처럼 최소 권한 원칙을 지키는 형태를 먼저 제시해야 보안팀과의 협의가 빨라진다는 것이 이번 도입의 실무적 교훈입니다.

번외 — 가장 먼저 도입한 조직이 먼저 만나는 문제들. 지원 개시 직후 곧바로 도입에 나선 만큼, 성숙한 제품이라면 겪지 않았을 초기 버전의 제약도 우리가 먼저 만났습니다. 초기 Windows 클라이언트의 VM 격리 방식에서는 Office Add-in이 호스트의 Office 프로세스에 접근하지 못했고, 문서 미리보기에서는 한중일(CJK) 폰트 누락으로 한글이 깨졌습니다. 우리는 겪은 이슈를 재현 조건까지 정리해 적극적으로 제보했고, 두 문제 모두 이후 클라이언트 패치로 해소되어 지금 도입을 시작하는 조직이라면 만나지 않을 문제들입니다. 얼리어답터의 시행착오는 이렇게 시간이 해결해 주는 것과 스스로 풀어야 하는 것으로 나뉘며, 이 장은 후자의 기록입니다.

7.2 프롬프트 캐시 TTL 연장의 역설 — 실데이터가 뒤집은 직관

무엇이 막혔나. Bedrock의 프롬프트 캐시는 반복되는 입력 접두부를 재사용해 비용을 낮춥니다. 기본 TTL 5분을 1시간으로 늘리면 적중률이 높아져 비용이 더 줄어들 것이라는 가설이 있었고, 장기 세션이 많은 워크로드에서 효과가 클 것으로 기대했습니다.

어떻게 풀었나. 배포 대신 한 달치 실사용 로그를 분석했고, 결과는 직관과 반대였습니다.

원인은 워크로드의 시간 분포였습니다. 이미 요청의 86.5%가 5분 이내 재발생해 기본 TTL로도 대부분 적중하고 있었고, 5분~1시간 구간은 2.9%뿐이었습니다. 반면 1시간 캐시는 기록(write) 비용이 더 비싸 추가 적중으로 아낀 비용을 초과했습니다. 결국 TTL은 5분으로 유지했습니다.

같은 분석에서 1,000턴을 넘는 초장기 세션이 다수 발견되었고, 극단적으로는 한 세션이 12,388턴까지 이어지며 Haiku만으로 약 $79를 소비한 사례가 있었습니다. 세션을 종료하지 않고 이어 쓰며 심층 리서치가 조사를 과도하게 반복한 탓이었습니다. 이를 비용 이상 징후로 보고 이후 배포에서 심층 리서치를 기본 비활성화하고, “긴 작업은 세션을 적절히 분리하라”는 지침을 교육에 포함했습니다.

교훈. 비용 최적화 파라미터는 반드시 자신의 워크로드 실데이터로 검증해야 합니다. “TTL을 늘리면 싸진다”는 일반론은 요청 시간 분포에 따라 정반대로 작동할 수 있습니다. 또한 SpendLogs는 청구서가 아니라, 비정상 소비를 조기에 잡고 사용자 교육의 근거를 만드는 관측 데이터였습니다.

7.3 여러 계열사를 수용하는 단일 게이트웨이 — 인증의 진화

무엇이 막혔나. 한화그룹은 사업 부문과 해외 법인이 많아 Microsoft Entra ID 테넌트가 하나로 통합되지 않고 여러 개로 분리되어 있습니다. 초기 버전에서 사용한 API Gateway 내장 JWT Authorizer는 단일 발급자(issuer)만 검증할 수 있어, 한 테넌트의 토큰만 통과시킬 수 있었고, 여러 계열사로 확장하는 길이 애초에 막혀 있었습니다.

어떻게 풀었나. 인증 계층을 직접 구현한 Lambda Authorizer로 전환했습니다. JWT의 tid(테넌트 ID) 클레임을 먼저 확인하고, 사전 등록된 계열사 허용 목록에 대해서만 해당 테넌트의 발급자·서명키로 검증을 분기합니다. 그 결과 서로 다른 두 테넌트의 사용자가 동일한 게이트웨이에 접속할 수 있게 되었고, 신규 계열사 추가 시 코드 재배포 없이 허용 목록 파라미터만 갱신하면 됩니다(구현 세부는 5.1절 참조). 전사 확장은 본사 단일 테넌트 → 큐셀 등 확장 시 허브(Hub) 테넌트 승격 → Entra ID 교차 테넌트 동기화의 3단계 모델로 설계했습니다.

교훈. 멀티테넌트 조직에서 인증은 나중에 확장할 문제가 아니라 아키텍처 초기에 결정되는 제약입니다. 관리형 컴포넌트의 편의성이 조직 구조와 맞지 않을 때는 조기에 커스텀 Authorizer로 전환하는 편이 전체 비용이 낮으며, 도입 전 자사 IdP 통합 실태를 실측하는 것이 가장 중요합니다.

7.4 시행착오가 만든 개선 — 도입 전후 비교

8. 도입 성과

8.1 업무 분석 기반 과제 도출 및 전략적 실행

사내 AI 도입의 성패는 ‘어떤 기술을 도입할 것인가’가 아니라 ‘현장의 어떤 문제를 해결할 것인가’에 달려 있었습니다. 전사 AI 전략의 방향성을 유지하면서도 현장의 실무적 Pain point를 겨냥하는 균형 잡힌 접근을 택했고, 이를 위해 백오피스 업무 전반을 심층 분석하고 실무자들의 혁신 아이디어를 직접 접수해 실효성 높은 AI Use Case를 발굴했습니다.

수집된 과제는 구현 난이도와 비즈니스 임팩트를 기준으로 우선순위를 평가했습니다. 즉각적인 전사적 수혜가 예상되는 과제는 ‘Quick-Win’으로 선정해 최우선 수행하고, 사내 시스템이나 외부 소스 연동이 필요한 과제는 연동 우선순위와 개발 기간에 따라 중장기 파이프라인으로 분류했습니다. 데이터 기반으로 과제를 선별한 덕분에 임직원이 AI의 효용을 빠르게 체감하면서도 전사 확장 가능한 안정성을 확보할 수 있었습니다.

8.2 도입·확산 지표

세 지표 모두 목표를 상회하고 있습니다. 배포 인원 수는 1·2차 배포 목표를 55% 이상 넘겼고, 온보딩 소요 시간은 30분~1시간에서 5분~10분으로 단축되었으며, 교육 모듈도 0개에서 10개로 확충되어 학습·적응 체계를 갖췄습니다.

이 여정은 외부에서도 주목받았습니다. Anthropic은 Claude Desktop의 서드파티 클라우드 전면 지원 공식 블로그에서 한화솔루션을 도입 사례로 소개했습니다. “기존 클라우드 환경을 통해 별도의 벤더 계약 없이 Claude Desktop을 빠르게 배포했고, 자체 LLM Gateway 덕분에 한 팀이 무거운 인프라 구축 없이 전 세계 수백 명의 사용자에게 배포할 수 있었다”는 오사랑 팀장의 말은, 이 글에서 다룬 아키텍처가 만든 결과를 압축합니다.

9. 결론 및 향후 계획

한화솔루션은 Claude Cowork를 서드파티(3P) 클라우드인 Amazon Bedrock 기반으로 전사에 배포하고, 그 전체를 사내 LLM Gateway의 거버넌스 아래에 두었습니다. 핵심은 기능 하나가 아니라 분리된 계열사 Entra ID를 단일 게이트웨이로 수용하는 멀티테넌트 인증, 엔터프라이즈 클라이언트 환경의 실전 제약 대응, 실데이터에 근거한 비용·보안 거버넌스라는 세 축을 차례로 검증한 과정이었습니다. 직접 부딪혀 본 뒤에야 드러난 문제들(보안 SW 충돌, 캐시 TTL의 역설, 배포 체계 전환기의 키·세션 관리)을 하나씩 풀어낸 경험이, 개발자의 Claude Code와 비개발 임직원의 Claude Cowork를 하나의 안전한 관문 위에서 함께 쓰게 만들었습니다.

9.1 향후 계획

이 게이트웨이를 본사에 그치지 않고 한화그룹 계열사로 확산할 계획이며, 7.3절의 허브 테넌트·교차 테넌트 동기화 기반 3단계 확장 모델이 그 기술적 토대입니다.

• 계열사 확산: 본사에서 검증한 멀티테넌트 인증 구조를 토대로 그룹 내 다른 계열사로 단계적으로 넓혀 갑니다.
• 활용 고도화: 문서 협업·코드 작성을 넘어 사내 시스템과 연결된 에이전트 워크플로와 도메인별 활용(문서 자동화·코드 현대화 등)으로 확대합니다.
• 거버넌스 성숙: 조직별 비용 집계·예산 정책과 보안 필터 정책을 정교화하여, 확산 규모가 커져도 통제 가능성을 유지합니다.

9.2 참고 자료

같은 여정을 준비하는 조직이라면, 아래 자료가 출발점이 될 수 있습니다.

• 단일 LLM Gateway 아키텍처 — Claude Code와 Codex를 Amazon Bedrock을 통해 한 곳에서: 전사 거버넌스(단일 인증·예산 관리·중앙 보안 정책·로깅) 관점의 게이트웨이 설계 논거. https://aws.amazon.com/ko/blogs/tech/single-llm-gw-arch/
• Amazon Bedrock과 함께 Claude Code 사용하기: 개발자 관점에서 Claude Code를 Amazon Bedrock으로 시작하는 기본 설정과 사용법. https://aws.amazon.com/ko/blogs/tech/bedrock-with-claude-code/
• Amazon Bedrock 기반 Claude Code, 조직에서 안전하게 운영하기 — LLM Gateway 구축 가이드: IAM Identity Center SSO 기반의 게이트웨이 구축 경로 — 조직의 IdP 요건이 본문(Entra ID 직결)과 다를 때 참고할 수 있는 대안 설계. https://aws.amazon.com/ko/blogs/tech/bedrock-claude-code-llm-gw/

도입 순서를 고민하는 조직이라면 2장의 5단계 배포 로드맵이 시작 체크리스트가 될 수 있습니다 — 소수 선도 조직의 1차 배포로 실전 제약을 일찍 드러내고, 인증·게이트웨이 기반을 갖춘 뒤 단계적으로 확대하는 경로입니다. 한화솔루션의 이번 구축이, Claude Cowork와 같은 전사 협업 AI의 도입을 검토하는 조직을 포함해, 엔터프라이즈 환경에서 생성형 AI를 “안전하게, 그리고 실제로 쓰이도록” 도입하려는 모든 조직에 구체적인 참고가 되기를 바랍니다.

본문의 도표, 예시 코드, 스크린샷 및 수치는 외부 공개 가능한 수준으로 비식별·마스킹 처리하였으며, 일부는 개념 전달을 위해 단순화되었습니다.