한 줄 정의

PrivateLink는 AWS VPC 안의 서버가 지원되는 AWS 서비스, 다른 계정의 서비스, SaaS 서비스, 일부 VPC 리소스에 사설 IP 경로로 접근하게 해 주는 네트워크 기술이야. AI 문맥에서는 모델 이름이 아니라, Amazon Bedrock 같은 서비스 호출이 어느 네트워크 경계와 감사 체계 안에서 도는지 알려 주는 단서에 가까워.

짧게 말하면 “모델을 무엇으로 호출하나”보다 “그 호출이 공용 인터넷 경로를 지나가나, 회사 VPC의 사설 endpoint를 지나가나”를 가르는 말이야. 그래서 OpenAI API를 직접 호출하는 흐름과 Bedrock을 거치는 흐름을 비교할 때 PrivateLink는 보안팀과 플랫폼팀이 먼저 확인하는 항목이 돼.

어떻게 작동하나

사용자는 VPC 안에 VPC endpoint를 만들고, 접근하려는 서비스나 리소스를 endpoint 대상으로 지정해. AWS 문서는 이때 subnet마다 endpoint network interface가 만들어지고, 이 network interface가 서비스로 가는 트래픽의 입구가 된다고 설명해. 요청은 보통 DNS 이름으로 시작하지만, private DNS를 켜면 기존 AWS 서비스 endpoint 이름이 VPC endpoint의 private IP로 해석될 수 있어.

PrivateLink 흐름은 크게 두 역할로 나뉘어.

  • 소비자: 서비스에 접근하려는 계정이나 VPC야. interface endpoint, resource endpoint, service network endpoint 같은 endpoint를 만들어.
  • 제공자: AWS 서비스, AWS Marketplace 파트너, 다른 AWS 계정, 또는 VPC 리소스 소유자야. endpoint service나 resource configuration을 통해 접근 대상을 열어.
  • 통제 지점: endpoint policy, 보안 그룹, private DNS, 연결 승인, CloudTrail 로그가 실제 운영에서 봐야 할 항목이야.

예를 들어 Bedrock으로 추론 요청을 보내는 사내 앱이 있다고 해 보자. 앱 서버가 private subnet에 있고, 보안 정책상 NAT gateway나 public IP 경로를 피해야 한다면 PrivateLink를 지원하는 Bedrock endpoint로 요청을 보내도록 구성할 수 있어. 이때 핵심은 모델이 더 똑똑해지는 게 아니라, 요청 경로와 로그와 권한을 AWS 계정 안에서 더 좁게 관리하는 거야.

2026년 4월 28일 발표된 OpenAI on AWS도 이 맥락이야. OpenAI와 AWS는 OpenAI models on AWS, Codex on AWS, Bedrock Managed Agents를 limited preview로 열었다고 밝혔고, AWS 공지는 OpenAI 모델이 IAM, PrivateLink, Guardrails, encryption, CloudTrail logging 같은 Bedrock 통제를 이어받는다고 적었어. PrivateLink는 여기서 모델 기능이 아니라 네트워크 통제 항목이야.

왜 중요한가

PrivateLink가 중요한 이유는 기업의 AI 도입에서 “인터넷으로 API 하나 부르면 끝”이 잘 통하지 않기 때문이야. 고객 데이터, 사내 문서, 코드베이스, 결제 정보가 들어가는 요청은 모델 성능만 볼 수 없어. 어떤 VPC에서 요청이 나가고, 어떤 endpoint policy가 적용되고, 누가 로그를 볼 수 있고, 비용이 어느 계정에 잡히는지까지 같이 봐야 해.

Amazon Bedrock이 AI 기사에서 자주 나오는 이유도 비슷해. Bedrock은 여러 모델을 AWS 계정 안에서 호출하게 해 주고, PrivateLink, CloudTrail, guardrail, 암호화 같은 운영 통제를 같은 구매·보안 경로로 묶어. OpenAI 발표는 Codex 주간 사용자가 400만 명을 넘는다고 설명했는데, 기업 입장에서는 사용자가 많다는 사실만큼 “그 코딩 에이전트 호출을 기존 AWS 약정과 보안 절차 안에서 다룰 수 있나”도 중요해져.

또 PrivateLink는 Agent 운영에서 더 눈에 띄어. 단순 챗봇은 답변만 만들면 되지만, 업무 agent는 내부 API 호출, 문서 검색, 권한 확인, 행동 로그가 붙어. 네트워크 경로를 좁히면 공격 표면을 줄이는 데 도움이 되지만, 동시에 endpoint 수, AZ 구성, DNS 설정, 데이터 처리 비용을 관리해야 해. AWS pricing 문서는 interface endpoint가 AZ별 시간 단위와 GB 단위 데이터 처리량으로 과금된다고 설명해.

주의해서 볼 점

첫째, PrivateLink는 보안 제품 전체가 아니야. 공용 인터넷 경로를 피하고 사설 endpoint를 쓰는 기술이지, 잘못된 권한 정책이나 모델의 잘못된 답변까지 막아 주는 장치는 아니야. Guardrail, 권한 설계, eval, 로그 검토를 따로 둬야 해.

둘째, endpoint 유형을 섞으면 안 돼. AWS 문서는 interface, Gateway Load Balancer, resource, service network endpoint를 PrivateLink 쪽으로 설명하지만, S3와 DynamoDB용 gateway endpoint는 PrivateLink를 쓰는 endpoint 유형이 아니라고 분리해. “VPC endpoint니까 전부 PrivateLink”라고 생각하면 네트워크 설계를 잘못 읽기 쉬워.

셋째, 비용과 가용성을 같이 봐야 해. AWS pricing 문서는 interface endpoint 데이터 처리 단가를 월 리전 합산 기준 첫 1PB $0.01/GB, 다음 4PB $0.006/GB, 5PB 초과 $0.004/GB로 제시하고, endpoint가 각 Availability Zone에서 유지되는 시간에도 과금된다고 적어. AWS 서비스 접근 문서는 프로덕션에서 최소 2개 Availability Zone 구성을 권장해. 보안 경로를 좁히는 대신 운영 비용과 장애 설계가 따라오는 셈이야.

넷째, OpenAI on AWS 발표를 넓게 해석하면 위험해. 2026년 4월 28일 기준 OpenAI models, Codex, Managed Agents는 limited preview였고, PrivateLink가 언급됐다고 해서 OpenAI API의 모든 기능이 그대로 AWS 사설 endpoint 뒤에 복제됐다는 뜻은 아니야. 실무에서는 대상 서비스가 PrivateLink를 지원하는지, 리전과 계정 접근권이 맞는지, private DNS와 endpoint policy가 실제 요청 경로를 어떻게 바꾸는지부터 확인해야 해.