서울 리전에서 Bedrock을 쓰면 데이터는 어디서 처리됩니까

보안 검토서에는 대개 데이터가 어디에서 처리되는지 적는 칸이 있습니다. 클라우드 서비스를 쓸 때 이 칸은 보통 리전 이름 하나로 채워집니다. 서울 리전을 골랐으니 서울에서 처리된다는 뜻으로 읽는 것입니다.

그런데 생성형 AI 모델을 호출하는 경우에는 그 두 문장이 항상 같지 않습니다. Amazon Bedrock에서는 어느 리전의 엔드포인트를 부르는가와, 그 요청이 실제로 어느 리전에서 처리되는가가 갈릴 수 있습니다. 아래에서는 그 갈림이 왜 생기는지와, 우리 환경에서 실제 처리 위치를 확인하는 순서를 다룹니다.

무엇을 넣을지 고르는 일과 누구에게 열어 줄지 정하는 일은 AI 챗봇 구축 전의 데이터·권한 준비에서 따로 다룹니다. 여기서는 그 앞의 기술 사실 하나 — 요청이 물리적으로 어디에서 처리되는가 — 에만 집중합니다.

리전과 추론 프로파일은 서로 다른 것을 가리킨다

이 주제가 헷갈리는 이유는 처리 위치를 정하는 값이 하나가 아니기 때문입니다. 최소한 세 가지를 나눠 봐야 합니다.

리전 설정만 보고 처리 위치를 판단하면, 세 번째 값이 시야에서 빠집니다. 실무에서 어긋나는 지점이 대체로 여기입니다.

서울에서 부른 요청이 다른 리전에서 처리되는 경우

교차 리전 추론은 요청을 하나의 리전에 묶지 않고, 미리 정해진 여러 리전 중 여유가 있는 곳으로 보내 처리하는 방식입니다. 목적은 데이터를 옮기는 것이 아니라 트래픽이 몰릴 때의 가용성과 처리량을 확보하는 것입니다. 그래서 기능 자체는 이용자에게 이롭게 설계돼 있습니다.

문제는 이 방식이 선택 사항이 아닐 때가 있다는 점입니다. 최신 모델 중 일부는 교차 리전 추론 프로파일로만 제공되어, 특정 리전 하나에서 단독으로 호출하는 선택지가 아예 없습니다. 이 경우 서울 리전 엔드포인트로 요청을 보내더라도 실제 처리는 그 프로파일이 포함하는 리전 범위 안에서 일어납니다.

프로파일의 성격은 대체로 모델 식별자의 앞부분에서 드러납니다. 지리 범위를 나타내는 접두사가 붙어 있으면 그 범위 안에서 처리된다는 뜻이고, 전역 범위를 뜻하는 접두사가 붙어 있으면 범위가 더 넓습니다. 접두사가 없는 식별자는 대개 해당 리전 단독 호출입니다. 다만 어떤 모델이 어떤 프로파일로 제공되는지는 계속 바뀌므로, 지원 현황 문서를 채택 시점에 직접 확인하셔야 합니다. 여기에 모델 목록을 적지 않는 이유도 같습니다.

여기서 한 가지 구분을 명확히 해 두겠습니다. 교차 리전으로 처리된다는 것은 요청이 처리되는 위치에 관한 이야기이고, 그 데이터가 어딘가에 영구히 저장된다는 뜻이 아닙니다. 저장은 다음에 나오는 로깅 설정이 정합니다. 두 가지를 뭉개면 검토가 실제보다 과하게 무거워집니다.

확인해야 하는 순서

우리 환경의 처리 위치를 답하려면 아래 순서를 밟으면 됩니다. 순서를 바꾸면 답이 나오지 않습니다.

1. 쓰려는 모델이 서울 리전에서 단독으로 제공되는가. 리전별 서비스 제공 현황과 Bedrock 문서에서 확인합니다. 단독 제공된다면 처리 위치를 한 곳으로 묶는 구성이 가능합니다.
2. 지금 호출이 어떤 추론 프로파일로 잡혀 있는가. 코드에 적힌 모델 식별자를 그대로 꺼내 보십시오. 문서에서 그 식별자가 어떤 프로파일에 속하는지 확인하면 처리 리전의 범위가 나옵니다. 이 단계를 건너뛰고 리전 설정만 적으면 검토서의 답이 틀리게 됩니다.
3. 실제로 어디서 처리됐는지 로그로 확인한다. 문서로 추정한 것과 실제가 같은지는 기록으로만 확정됩니다. AWS는 교차 리전 추론 요청을 호출한 리전의 CloudTrail에 남기고, additionalEventData.inferenceRegion 필드에 요청이 실제로 처리된 리전을 적습니다. 검토서에 「추정」이 아니라 「관측」을 적을 수 있는 자리가 여기입니다.
4. 그 처리 리전이 내부 규정·계약과 맞는가. 앞의 세 단계가 사실을 확정하고, 이 단계가 판단입니다. 맞지 않으면 선택지는 둘입니다. 서울에서 단독 제공되는 다른 모델로 바꾸거나, 그 범위를 전제로 고지·계약을 정리하는 것입니다.

학습 사용 여부는 처리 위치와 별개 항목이다

처리 위치와 자주 섞이는 질문이 “우리 데이터가 모델 학습에 쓰이느냐”인데, 다른 항목이라 따로 확인해야 합니다. AWS의 정책 서술과 확인 방법은 Amazon Bedrock으로 기업 AI를 구축할 때의 장점과 제약이 갖고 있습니다.

여기서 이어지는 것은 그 다음 항목입니다. 사업자 정책과 별개로 우리가 만든 시스템의 기록에 프롬프트와 응답 원문이 그대로 쌓이는지는 우리 설계의 문제이고, 처리 위치 검토에서 실제로 빠뜨리는 자리가 여기입니다.

로깅을 켜면 원문이 어디에 쌓이는가

Bedrock은 모델 호출 로깅을 제공합니다. 켜면 요청과 응답 데이터가 우리 계정의 CloudWatch Logs나 Amazon S3에 기록되며, 저장 위치는 설정할 때 우리가 정합니다.

이 기능은 문제를 되짚고 감사 근거를 남기는 데 필요합니다. 끄는 것이 정답은 아닙니다. 다만 켜는 순간 다음 세 가지가 함께 결정돼야 합니다.

• 어디에 쌓이는가 — 저장 대상과 그 리전을 명시적으로 정합니다. 여기가 실제 데이터 보관 위치입니다.
• 얼마나 보관하는가 — 보관 기간을 정하지 않으면 원문이 무기한 쌓입니다.
• 누가 열람하는가 — 로그 저장소의 접근 권한이 원문 열람 권한과 같다는 사실을 인지해야 합니다.

정리하면 이렇습니다. 처리 위치는 추론 프로파일이 정하고, 보관 위치는 우리가 로깅 설정에서 정합니다. 검토서에서 이 둘을 한 칸에 적으면 답이 흐려집니다.

Bedrock이 무엇을 관리형으로 맡고 무엇이 여전히 우리 몫인지의 전체 그림은 Amazon Bedrock의 장점과 제약에 정리돼 있습니다.

국외 이전 검토에서 확인할 항목

개인정보가 포함된 데이터를 다룬다면 처리 위치는 곧 국외 이전 검토와 이어집니다. 다만 어떤 고지나 동의가 어떤 형식으로 필요한지는 데이터의 성격과 법령 해석에 달려 있어, 여기서 단정하지 않겠습니다.

기술 쪽에서 준비할 수 있는 것은 판단의 재료가 되는 사실관계입니다. 아래 항목을 문서로 정리해 두면 검토가 훨씬 빨라집니다.

• 모델에 보내는 항목 중 개인정보에 해당하는 것이 있는지, 있다면 무엇인지
• 그 요청이 처리되는 리전의 범위(추론 프로파일 기준)
• 로그와 그 밖의 저장소에 원문이 남는지, 남는다면 어느 리전에 얼마나
• 그 데이터에 접근할 수 있는 주체와 권한의 범위
• 위 사실을 뒷받침하는 공식 문서와 설정 화면의 근거

이 항목들이 채워지면 남는 것은 법적 판단입니다. 고지·동의의 필요 여부와 형식은 법무·개인정보 담당과 확인하십시오. 기술 담당이 이 판단을 대신 내리는 것이 이 영역에서 가장 흔한 사고 유형입니다.

교차 리전 처리에 추가 전송료는 붙지 않습니다

교차 리전으로 처리된다고 해서 전송료가 따로 붙지는 않습니다. AWS 문서는 교차 리전 추론에 추가 라우팅 비용이 없고, 요금은 추론 프로파일을 호출한 리전을 기준으로 계산된다고 명시합니다. 오히려 전 세계로 라우팅하는 프로파일 쪽이 지역을 묶는 프로파일보다 약 10% 저렴하다고 같은 문서의 비교표가 적고 있습니다.

⇒ 비용과 데이터 위치는 서로 반대 방향을 가리킵니다. 처리 범위를 좁히면 규정을 지키기 쉬워지는 대신 단가가 올라가고, 넓히면 반대가 됩니다. 이 절충을 아는 것이 처리 리전 결정의 실제 내용입니다. 다만 단가와 절감폭은 시점에 따라 바뀌므로 채택 시점에 Amazon Bedrock 요금 문서에서 확인하십시오.

정리

• 리전을 골랐다는 것과 그 리전에서 처리된다는 것은 다른 말입니다. 둘을 가르는 값이 추론 프로파일입니다.
• 최신 모델 중 일부는 교차 리전 프로파일로만 제공되어 단독 리전 호출이라는 선택지가 없습니다.
• 확인 순서는 모델의 단독 제공 여부 → 지금 호출의 프로파일 → 내부 규정과의 정합 세 단계입니다.
• 학습 활용 여부와 우리 로그의 원문 잔존은 별개의 확인 항목입니다. 앞은 사업자 문서로, 뒤는 우리 설정으로 답합니다.
• 국외 이전 고지의 형식은 기술 담당이 정할 일이 아닙니다. 사실관계를 정리해 법무·개인정보 담당에게 넘기는 것까지가 기술 쪽의 몫입니다.

빌드업웍스는 처리 위치를 확인할 때 리전 설정이 아니라 실제 호출의 추론 프로파일을 근거로 삼고, 정리한 사실관계를 법무·개인정보 담당에게 넘기는 것까지를 기술 쪽의 몫으로 봅니다.

클라우드에서 AI를 쓰는 방식 자체를 처음부터 정리하고 싶으시면 클라우드 AI란 무엇인가가 출발점으로 맞습니다. 지금 조직의 데이터·거버넌스 상태를 몇 분 안에 가늠하시려면 AI 준비도 진단을 이용하실 수 있고, 연락처 없이 결과를 바로 보실 수 있습니다.

우리 계정에서 실제로 어떤 모델과 프로파일이 쓰이고 있는지 확인이 필요하시면 상담 신청으로 연락 주십시오.

참고 자료

• Amazon Bedrock — Cross-region inference
• Amazon Bedrock — Supported Regions and models for inference profiles
• Amazon Bedrock — Data protection
• Amazon Bedrock — Model invocation logging
• Amazon Bedrock — Security, privacy, and responsible AI
• AWS — 리전별 서비스 제공 현황