“업무용 보안 브라우저를 알아보던 중인데, AWS 신규 고객 제한 공지를 봤어요. 기존에 쓰던 팀도 당장 다른 서비스로 옮겨야 할까요?” 이 질문은 신규 도입과 기존 운영을 나눠 보면 정리가 됩니다. 2026년 10월 29일부터 Amazon WorkSpaces Secure Browser는 신규 고객에게 열리지 않지만, 이미 사용 중인 고객은 계속 이용할 수 있습니다. AWS는 해당 서비스의 운영과 지원을 계속한다고 안내했습니다. 이번 공지만으로 기존 고객의 즉시 이전이나 지원 종료가 결정됐다고 해석할 근거는 없습니다.
이 글은 2026년 10월 30일 확인한 AWS 공지·관리자 문서·요금 안내를 바탕으로 작성했습니다. 실제 계정을 새로 등록하거나 서비스를 이전해 본 시험기는 아닙니다. 신규 도입을 검토하는 담당자와 이미 사용하는 팀이 무엇을 확인하면 좋을지, 사실과 실무 제안을 구분해 차근차근 살펴볼게요.
10월 29일에 달라진 것은 무엇인가요?
AWS가 9월 29일 게시한 서비스 가용성 공지는 WorkSpaces Secure Browser를 Maintenance 대상으로 분류하고, 신규 고객 접근 제한의 시작일을 10월 29일로 명시했습니다. 공지 게시일과 제한이 적용되는 날은 한 달 차이가 납니다. 이번에 확인해야 할 최근 변화는 예전 공지가 검색됐다는 점이 아니라, 안내된 적용일이 실제로 지났다는 점입니다. AWS 서비스 가용성 공지에서 분류와 날짜를 함께 확인할 수 있습니다.
같은 공지에는 종료 일정을 제시하는 Sunset 항목도 따로 있습니다. 따라서 Maintenance라는 상태와 서비스 지원 종료를 같은 뜻으로 묶으면 판단이 달라질 수 있어요. 내부 공유 문서에도 “신규 도입 제한”이라고 구체적으로 적는 편이 좋습니다. “AWS 브라우저 서비스 종료”라고만 전달하면 현재 사용자가 느끼는 긴급성과 실제 안내의 범위가 어긋날 수 있기 때문입니다.
우리 팀이 기존 고객인지부터 확인해 볼까요?
처음 도입하려는 팀이라면 이미 승인된 예산이나 검토 문서에 Secure Browser가 들어 있다는 이유만으로 도입이 가능하다고 가정하지 않는 게 좋겠습니다. 반대로 기존에 운영하는 팀은 이번 공지 한 줄만 보고 사용 중인 환경을 없앨 필요가 있는지부터 따져 봐야 합니다. 도입 검토와 운영 변경은 서로 다른 의사결정으로 다루자는 제안입니다.
확인할 때는 “우리 회사가 AWS를 쓴다”와 “해당 서비스의 기존 고객이다”를 나눠 적어 보세요. 이 글에서는 특정 계정이 기존 고객에 해당하는지 판정하지 않습니다. 담당자가 사용하는 계정과 조직, 현재 포털, 실제 이용 상태를 확인하고, 새 계정·조직 개편·추가 도입과 연결된 질문은 AWS에 구체적으로 문의해 주세요. 계정 정보를 확인하지 않은 외부 글로 이용 자격을 확정하는 것은 피하는 편이 안전합니다.
여기서 필요한 건 공포에 가까운 이전 계획보다 현재 상태를 설명하는 작은 문서입니다. 누가 업무에 사용하고 있는지, 어떤 웹 서비스가 꼭 필요한지, 어느 정책이 빠지면 업무를 진행할 수 없는지부터 적어 보세요. 계약이나 보안 검토에 필요한 사실과, 아직 질문으로 남아 있는 항목을 분리하면 다음 논의가 훨씬 편해집니다.
보안 브라우저를 바꾼다는 건 무엇을 바꾸는 일일까요?
Secure Browser 제품 소개는 AWS 클라우드의 원격 브라우저 세션에서 화면을 처리하고, 암호화된 픽셀을 사용자의 로컬 브라우저로 전송하는 방식을 설명합니다. 사내 웹사이트와 SaaS, 인터넷에 접근하는 용도로 안내하고 있습니다. 이런 제품을 비교할 때는 브라우저 창이 열린다는 표면적인 모습만 보지 말고, 업무 화면이 어디서 처리되는지와 회사 정책을 어디에서 적용하는지 살펴봐야 합니다. AWS 제품 소개의 설명을 출발점으로 삼을 수 있어요.
예를 들어 견적 요청서를 만든다면 “현재 브라우저와 비슷한 것”보다 질문을 조금 더 구체적으로 바꿔 보세요. 사용자가 회사에서 관리하지 않는 기기로 접속하는지, 내려받기와 복사에 어떤 규칙이 필요한지, 문제 발생 시 어느 팀이 기록을 확인하는지를 적는 식입니다. 이는 특정 제품의 보안 우열을 뜻하지 않습니다. 우리 업무에서 지켜야 할 조건을 먼저 문장으로 만들자는 제안입니다.
대안 안내가 있어도 그대로 옮겨지는 것은 아니에요
AWS 관리자 문서는 직접 관리하는 Chrome 이미지를 사용하는 WorkSpaces Applications와 기업용 보안 브라우저를 대안으로 제시합니다. Applications에서 비슷한 원격 화면 전달 방식을 활용할 수 있어도, 기존 기능과 운영 방식이 모두 자동으로 이어지는 것은 아닙니다. 문서에는 하위 애플리케이션의 SSO, 브라우저 정책 갱신, 감사 기록 등에서 별도 구성이 필요한 차이가 나와 있습니다. 공식 가용성 변경 및 대안 안내에서 해당 부분을 확인해 주세요.
이 차이는 이름보다 업무 흐름으로 검토하는 편이 이해하기 쉽습니다. 사용자가 처음 로그인한 뒤 사내 도구까지 자연스럽게 들어가는지, 정책을 바꾼 후 어느 시점에 반영되는지, 문제가 생겼을 때 담당자가 필요한 기록을 찾을 수 있는지를 질문해 보세요. 여기서는 각 기능을 설정하는 명령이나 실제 동작 결과를 제공하지 않습니다. 도입 후보를 좁히기 위한 확인 항목입니다.
| 확인할 업무 조건 | 검토 문서에 남길 질문 |
| 로그인 흐름 | 첫 로그인부터 필수 업무 화면까지의 확인 책임자는 누구인가요? |
| 정책 운영 | 변경 승인, 반영 확인, 문제 발생 시 되돌리기는 누가 맡나요? |
| 기록 확인 | 업무 장애와 보안 검토에 필요한 기록을 어디에서 확인하나요? |
| 사용자 환경 | 실제 사용하는 기기와 네트워크에서 확인할 항목을 정했나요? |
표의 답이 비어 있다면 제품을 먼저 결제하기보다 담당 부서와 확인 범위를 합의하는 것이 좋겠습니다. 제품 안내에 기능 이름이 있다는 것과 우리 환경에서 필요한 상태로 준비됐다는 것은 검토 단계가 다릅니다. 작은 범위의 확인을 마친 뒤 적용 범위를 넓히면, 확인하지 않은 기능을 이미 갖춘 것처럼 보고하는 실수를 줄일 수 있습니다.
가격 비교는 월 이용자 수부터 맞춰 보세요
Secure Browser 요금 안내는 포털에 접근한 월간 활성 사용자, 즉 MAU를 기준으로 설명합니다. 월 요금에 사용자별 스트리밍 200시간이 포함되고 이를 넘기면 추가 시간 요금이 붙습니다. 선택한 인스턴스 유형과 리전에 따라 요금 조건도 달라집니다. 제품 첫 화면의 시작 가격 하나를 모든 계정의 확정 견적으로 사용하기 어려운 이유입니다. 실제 조건은 Secure Browser 요금 안내에서 확인해 주세요.
기존 고객의 비용을 점검한다면 전체 직원 수와 실제 이용자 수를 따로 적어 보세요. 월중 누가 사용했는지, 필요한 이용 시간이 어느 정도인지, 비교하려는 조건이 같은지를 먼저 정리하는 겁니다. 금액을 적는 칸 옆에는 사용한 리전과 인스턴스 유형, 확인일도 남겨 두면 좋겠습니다. 이 글에서는 특정 계정의 청구 내역을 조회하지 않았으므로 절감액이나 다음 달 요금을 계산하지 않습니다.
Applications 요금 페이지는 인스턴스 유형·크기·운영체제와 사용 자원을 기준으로 설명하고, 플릿 외에도 이미지 빌더와 앱 블록 빌더 같은 항목을 구분합니다. 선택한 운영체제와 조건에 따라 사용자 요금도 확인해야 합니다. 그래서 Secure Browser의 사용자당 월 금액과 Applications의 인스턴스 시간당 금액을 나란히 놓는 것만으로 어느 쪽이 저렴한지 결정할 수 없습니다. Applications 요금 안내를 같은 이용 조건으로 읽어야 합니다.
견적 비교표에는 현재 서비스의 확인된 이용 범위, 후보 서비스의 과금 단위, 별도로 검토할 라이선스와 운영 작업을 각각 적어 보세요. 모르는 항목을 0원으로 채우기보다 “추가 확인”으로 남기는 편이 낫습니다. 관리 업무에 누가 얼마나 참여할지도 질문해 두면, 서비스 요금표와 내부 운영 부담을 섞지 않고 검토할 수 있습니다. 이 부분은 비용이 반드시 늘거나 줄어든다는 예측이 아니라 비교 누락을 줄이기 위한 제안입니다.
운영팀과 도입 검토팀의 다음 행동은 달라요
기존 운영팀이라면 현재 서비스의 사용 목적과 필수 조건을 정리한 뒤, 변경할 필요가 있는 부분을 선별해 보세요. 서비스 공지 확인일, 현재 문의 사항, 다음 검토 담당자와 날짜를 남기면 막연히 “일단 지켜보자”는 결론보다 관리하기 쉽습니다. 이전이 필요하다고 결정한 경우에도 기존 환경을 언제 없앨지부터 정하지 말고, 후보에서 업무가 가능한지 확인하는 기준부터 합의하는 편이 좋겠습니다.
새 도입 검토팀은 제안서와 구매 요청서의 제품명부터 다시 확인해 보세요. 현재 요구사항을 충족하는 후보를 검토하되, 기능 확인·비용 확인·운영 책임 확인을 각각 완료 조건으로 두는 방법을 권합니다. 세 항목 가운데 하나라도 미확인이라면 승인 문서에 그 상태를 그대로 표시해 주세요. 빠르게 결론을 내리는 것보다 무엇을 확인하고 결정했는지 설명할 수 있는 편이 이후 협업에 도움이 됩니다.
- 현재 계정과 이용 상태를 확인하고, 신규 도입인지 기존 운영인지 구분해요.
- 공식 공지의 적용일과 작성 기준일을 함께 기록해요.
- 로그인·정책·기록·사용자 환경에서 빠지면 안 되는 조건을 정해요.
- 같은 이용 범위로 요금을 비교하고 미확인 비용은 별도 항목으로 남겨요.
- 확인 담당자와 완료 기준을 정한 뒤 변경 여부를 결정해요.
자주 묻는 질문과 확인 범위
기존 고객도 10월 29일부터 이용을 중단해야 하나요? 확인한 AWS 공지에서는 기존 고객의 계속 이용과 운영·지원을 안내합니다. 이 글에서 확인한 자료만으로 즉시 중단을 요구한다고 볼 수는 없습니다. 다만 이를 기간 제한 없는 보장으로 바꿔 해석하지 말고, 실제 계약·계정 질문과 이후 공지를 확인해 주세요.
요금 페이지에 무료 체험 안내가 남아 있으면 신규 등록이 가능한가요? 요금·체험 설명이 보인다는 사실만으로 현재 이용 자격이 확인되는 것은 아닙니다. 제품 가용성 공지와 본인 계정의 조건을 함께 봐야 합니다. 이 글은 신규 등록 성공 여부를 실제 시험하지 않았습니다.
지금 바로 대안으로 이전하는 게 정답인가요? 이 글은 일괄 이전을 권하지 않습니다. 현재 이용 상태, 필요한 기능, 확인된 비용, 운영 책임을 기준으로 판단해 보세요. 대안의 존재와 이전 검증의 완료는 다릅니다. 업체 공지로 확인한 사실과 우리 팀이 아직 확인해야 할 항목을 나눠 두면 결정이 한결 명확해집니다.
공식 자료와 사실 확인일
사실 확인일은 2026년 10월 30일입니다. 적용일은 AWS 공지에 적힌 2026년 10월 29일이며, 다음 날의 정책 변경이나 개별 계정 자격까지 확정한 것은 아닙니다. 본문에 연결한 AWS 가용성 공지, 제품 소개, 관리자 가이드와 두 서비스의 요금 안내를 직접 확인했습니다. 기능·가격·계약의 최종 판단은 해당 시점의 공식 안내와 실제 계정 조건을 기준으로 해 주세요.
'소프트웨어개발' 카테고리의 다른 글
| 구글 시트 Gemini 셀별 출처 업데이트: 유료 전환 전 확인할 요금제와 한도 (0) | 2026.10.31 |
|---|---|
| Compose exec가 CI에서 TTY 오류일 때: -T와 표준입력 구분 (0) | 2026.10.30 |
| Git push는 성공했는데 태그가 없을 때: 브랜치와 태그 전송 구분 (0) | 2026.10.30 |
