가 신청서를 결재받고 나서 근태 기록을 따로 고칩니다.
신규 입사자가 오면 메일, 메신저, 결재 계정을 하나씩 만들어 줍니다.
퇴사자 계정은 어디까지 정리했는지 매번 다시 확인합니다.

도구가 하나씩 늘어날 때는 크게 불편하지 않은데요. 인원이 늘고 업무가 많아질수록 이 작은 수고가 매주 반복되는 관리 업무가 됩니다.

업무 도구가 나뉘어 있으면 어떤 문제가 생길까요?

같은 정보를 여러 번 입력하고, 계정 관리가 담당자 기억에 기대게 되고, 업무 도구 비용이 한눈에 보이지 않습니다.

같은 정보를 여러 번 입력합니다

휴가, 외근, 출장처럼 결재와 근태에 동시에 걸리는 일은 시스템이 나뉘어 있으면 두 번 처리해야 합니다. 한쪽만 고치고 다른 쪽을 놓치면 월말 근태 정산 때 숫자가 맞지 않죠.

계정 관리가 담당자 기억에 의존합니다

입사자와 퇴사자가 생길 때마다 서비스별로 계정을 만들고 지워야 합니다. 퇴사자 메일 계정이 하나라도 남아 있으면 회사 정보가 외부에서 열람될 수 있는 상태가 되고요.

비용이 어디서 얼마나 나가는지 보기 어렵습니다

서비스마다 결제일과 결제 수단, 과금 기준이 다르다 보니 업무 도구에 매달 얼마를 쓰고 있는지 정확히 아는 회사가 많지 않습니다.

[참고] 회사에서 쓰는 SaaS가 몇 개인지, 비용이 어디서 새고 있는지 점검하고 싶다면?
👉 정액제 끝난 SaaS 비용, 핀옵스(FinOps)로 관리하는 이유

도구 수를 줄이는 것만으로도 이런 관리 업무는 상당 부분 줄어듭니다.

하이웍스란?

하이웍스는 기업메일, 전자결재, 근무관리, 메신저를 하나의 서비스로 제공하는 국내 그룹웨어입니다.

2025년 국내 500인 미만 기업을 대상으로 한 조사에서 그룹웨어·메일 시장 점유율 1위를 기록했습니다(하이웍스 자료 기준). 국내 기업 환경에 맞춰 만들어진 서비스라, 해외 협업툴을 쓰면서 결재나 근태 관리를 따로 붙여 쓰던 회사도 하나의 서비스 안에서 업무를 처리할 수 있습니다.

하이웍스 하나로 해결할 수 있는 것

무제한 기업메일

회사 도메인으로 기업메일을 쓰면서 용량 걱정을 덜 수 있습니다. 개인 메일이나 무료 메일로 업무를 주고받던 회사라면 대외 신뢰도와 보안 관리 측면에서 먼저 정리해 두는 게 좋습니다.

전자결재와 근무관리

결재와 근무관리가 같은 서비스 안에 있으니, 휴가·외근 같은 신청을 결재와 근태 기록에서 따로 처리하지 않아도 됩니다. 종이 서류나 메신저로 받던 승인 절차도 기록이 남는 형태로 바뀌고요.

메신저와 하이웍스 AI

사내 메신저로 업무 대화를 한곳에 모으고, 하이웍스 AI 기능까지 같은 환경에서 쓸 수 있습니다. 메일과 결재, 대화가 한 서비스에 있으니 업무 맥락을 찾느라 여러 앱을 오갈 일이 줄어듭니다.

보안인증(CSAP·ISMS)

하이웍스는 클라우드 보안인증(CSAP)과 정보보호 관리체계 인증(ISMS)을 갖추고 있습니다. 고객사나 협력사가 보안 기준을 요구하는 경우에도 검토 자료로 활용하기 좋은 부분이에요.

파이브클라우드에서 도입하면 어떤 혜택이 있나요?

첫해 이용료 50% 할인과 법정의무교육 무료 제공, 두 가지 혜택을 함께 받을 수 있습니다.

신규 도입 첫해 이용료 50% 할인

하이웍스를 처음 도입하는 기업이라면 메일과 그룹웨어 전 상품을 첫해 50% 할인된 가격으로 이용할 수 있습니다.

법정의무교육 무료 제공

하이웍스 기업교육 서비스를 통해 매년 챙겨야 하는 법정의무교육을 무료로 받을 수 있습니다. 경영지원 담당자가 교육 업체를 따로 알아보고 비용을 들이던 부분까지 함께 해결되는 셈이죠.

이런 회사라면 검토해 보세요

1. 메일, 결재, 근태를 서로 다른 서비스로 쓰고 있나요?
   2. 입·퇴사 때마다 여러 서비스에서 계정을 만들고 지우고 있나요?
   3. 아직 개인 메일이나 무료 메일로 업무를 처리하는 직원이 있나요?
   4. 고객사나 협력사로부터 보안인증 관련 자료를 요청받은 적이 있나요?
   5. 매년 법정의무교육을 따로 알아보고 비용을 내고 있나요?

이 중 우리 회사에 해당하는 사항은 몇 개인가요? 두 개 이상이라면 도입 상담을 받아 보세요!

자주 묻는 질문

☑️ 하이웍스 가격은 얼마인가요?
사용 인원과 이용할 상품 구성에 따라 달라집니다. 상담을 신청하시면 우리 회사 조건에 맞춘 견적과 할인 적용 금액을 함께 안내해 드립니다.

☑️ 50% 할인은 누가, 언제까지 받을 수 있나요?
하이웍스를 처음 도입하는 기업이 대상이며, 메일과 그룹웨어 전 상품에 적용됩니다. 프로모션은 [종료일]까지 진행됩니다. 함께 제공되는 법정의무교육은 2025년 가입 고객 2회, 2026년 가입 고객 1회입니다.

☑️ 도입은 어떤 절차로 진행되나요?
파이브클라우드 홈페이지에서 상담 신청 폼을 작성하시면, 담당자가 메일 또는 전화로 혜택과 견적을 안내해 드립니다. 바로 문의하고 싶다면 아래 연락처를 이용해 주세요.

• Tel: 02-6925-7014
•  Email: fivecloud@fastfive.co.kr

그룹웨어는 한번 정하면 쉽게 바꾸기 어려운 만큼, 처음 도입할 때 우리 회사 규모와 업무 방식에 맞는지 따져 보는 게 중요하죠.

파이브클라우드는 하이웍스를 비롯해 Microsoft 365, Google Workspace 같은 기업용 소프트웨어를 함께 다루고 있어, 우리 회사에 맞는 업무 환경을 비교해 보고 결정하실 수 있습니다. 첫해 50% 할인 혜택이 진행되는 지금, 하이웍스 도입을 편하게 상담해 보세요!

그리고 이런 사고는 대부분 정교한 해킹이 아니라 새어 나간 액세스 키 하나에서 시작됩니다. 다행히 대응도 그만큼 단순합니다. 키는 가능한 한 임시 자격증명으로 쓰고, 새어 나가더라도 빠르게 알아차릴 알림을 걸어두고, 키로 호출할 수 있는 범위를 미리 좁혀두는 것입니다.

최근 Amazon Bedrock 액세스 키가 GitHub 같은 공개 저장소에 노출되면서 생긴 과금 피해 사례가 부쩍 늘고 있습니다. 생성형 AI 서비스는 호출한 만큼 비용이 쌓이는 구조라, 키 하나가 새어 나가면 다른 서비스보다 피해가 훨씬 빠르게 불어나는데요. 담당자가 자리를 비운 사이, 혹은 잠든 사이에도 공격자는 자동화된 스크립트로 쉬지 않고 고비용 모델을 호출합니다. 다음 날 아침이면 이미 감당하기 어려운 청구서가 기다리고 있는 셈이죠.

Bedrock을 쓰고 있다면 우리 회사 계정에서 아래 항목들을 하나씩 확인해 보세요!

Bedrock 접근 키, 어떤 걸 써야 안전할까요?

가장 안전한 건 키를 아예 두지 않는 IAM Role이고, 그다음이 수명이 짧은 단기 Bedrock API 키입니다.

Bedrock에 접근하는 방식은 크게 IAM 액세스 키와 Bedrock 전용으로 발급하는 Bedrock API 키로 나뉩니다. 이름은 비슷해 보여도 연결되는 권한 주체와 위험도는 꽤 다릅니다.

EC2나 Lambda처럼 AWS 리소스에서 직접 Bedrock을 호출한다면, 키를 따로 발급받지 말고 역할을 연결하는 게 가장 안전합니다. 정적 키 자체가 존재하지 않으니 유출될 것도 없죠. 부득이하게 장기 키를 써야 한다면 최소 90일 주기로 교체해서, 유출됐을 때 노출되는 시간 자체를 줄여두시기 바랍니다.

키는 코드가 아니라 환경 변수나 Secrets Manager에 둡니다

액세스 키를 소스 코드나 설정 파일에 하드코딩한 채 공개 저장소에 올리면, 키를 자동으로 수집하는 공격자들의 스캔에 금방 걸립니다. 운영 환경에 영향을 주는 비밀 값은 환경 변수나 AWS Secrets Manager 같은 자격증명 저장소로 관리하는 게 원칙입니다.

.gitignore에 .env 파일을 등록해두는 습관, 커밋 전에 민감 정보를 자동으로 검사하는 pre-commit 훅 하나만 팀 차원에서 갖춰도 실수로 인한 노출은 크게 줄어듭니다.

[참고] Bedrock이 정확히 어떤 서비스인지부터 다시 짚어보고 싶다면?
👉 AWS GenAI 서비스 베드록(Bedrock)이란?

키가 새어 나가도 빨리 알아차리는 방법

그래도 실수는 일어날 수 있습니다. 그래서 두 번째로 챙길 건 알아차리는 속도입니다.

Health Dashboard 알림을 담당자에게 연결합니다

AWS는 공개 저장소에 노출된 액세스 키를 자동으로 탐지하면, 해당 키에 격리 정책을 붙여 추가 피해를 막고 계정에 등록된 연락처와 AWS Health Dashboard로 이 사실을 알려줍니다.

이 기능이 제대로 작동하려면 계정 연락처 정보가 최신이어야 하고, 누군가 Health Dashboard를 실제로 챙겨봐야 합니다. AWS User Notifications로 이 알림을 이메일, 콘솔 모바일 앱 푸시, Teams나 Slack 같은 채팅 채널로 보내두면 훨씬 빨리 인지할 수 있습니다. 여기에 Health 이벤트를 Amazon EventBridge로 전달해 Lambda를 실행하도록 걸어두면, 격리에 더해 해당 키를 즉시 삭제하는 대응까지 자동화할 수 있습니다.

비용 알림은 걸되, 실시간이 아니라는 점을 기억합니다

가장 기본은 AWS Budgets로 월 예산을 정하고 임계치를 넘으면 이메일이나 SNS로 알림을 받는 방법입니다. Cost Anomaly Detection을 함께 켜두면 예산을 넘지 않았더라도 평소와 다른 지출 패턴이 보일 때 따로 알려줍니다.

다만 두 가지 모두 실시간은 아닙니다. AWS 공식 문서에 따르면 비용 데이터는 최소 24시간마다 한 번 갱신되고, 그보다 늦게 반영되는 경우도 있습니다. 하루 만에 비용이 폭증하는 사고라면 알림이 오기 전에 이미 피해가 쌓여 있을 수 있죠.

호출 가능한 모델 자체를 좁혀 둡니다

그래서 더 효과적인 방법은 실제로 쓰는 모델만 남기고 나머지는 IAM 정책으로 막아두는 것입니다. 키가 새어 나가더라도 공격자가 호출할 수 있는 모델이 제한되니 피해 규모도 함께 줄어듭니다. 여기에 CloudWatch의 Metric Math 기능으로 Bedrock 토큰 사용량 지표를 비용으로 환산해 알람을 걸어두면, 청구 데이터보다 빠르게 이상 징후를 잡을 수 있습니다.

[참고] 이상 징후를 Slack·전화로 바로 통보받는 방법이 궁금하다면?
👉 상주 관제 없이 하는 AWS 운영, 월 5만 원부터 가능한 이유

계정 기본 보안까지 챙겨야 하는 이유는?

Bedrock 키를 아무리 잘 관리해도, 계정 자체가 뚫리면 소용이 없기 때문입니다.

특히 개발 실무를 수월하게 하기 위해 담당자 계정에 Admin 권한을 그대로 주는 경우가 적지 않은데요. 이런 계정의 접속 정보나 키가 유출되면 공격자는 비용 알림 수신자부터 지워 감지를 피한 뒤, 고비용 리소스를 무단으로 만들고 호출할 수 있습니다. 앞에서 걸어둔 알림까지 함께 무력화되는 셈이죠.

그래서 Bedrock 보안은 계정 기본 보안 위에서 완성됩니다. 루트와 IAM 사용자 모두에 다중 인증(MFA)을 걸고, 권한은 필요한 만큼만 주고, Root·IAM 비밀번호는 담당자가 바뀌거나 유출이 의심될 때 바로 교체해두세요.

[참고] 루트 MFA부터 최소 권한까지, 계정 기본 보안을 하나씩 점검하고 싶다면?
👉 AWS 계정 보안, 4가지 질문으로 점검하는 기본 체크리스트

Bedrock 계정 보안 체크리스트

바로 답하기 망설여지는 항목이 있다면, 그 지점이 지금 가장 먼저 채워야 할 빈틈입니다.

1. 장기 키 대신 IAM 역할이나 단기 키를 우선 쓰고, 장기 키는 90일 이내로 교체하고 있나요?
   2. 코드 저장소에 키가 하드코딩된 곳은 없는지 확인하셨나요?
   3. 계정 연락처 정보가 최신이고, Health Dashboard 알림을 담당자가 받고 있나요?
   4. 예산 알림이나 비용 이상 탐지가 켜져 있나요?
   5. 실제로 쓰지 않는 Bedrock 모델은 IAM 정책으로 막아두셨나요?
   6. 루트 계정과 IAM 사용자 모두 MFA가 켜져 있나요?
   7. 실무자나 장기 자격증명용 IAM 사용자에게 필요 이상의 권한이 들어가 있지 않나요?

7가지 항목을 하나씩 확인하고 빈 곳을 직접 채우는 일은 생각보다 시간이 많이 듭니다. 키와 권한, 알림이 서로 맞물려 있어 한 곳만 고쳐서는 효과가 잘 나지 않기 때문이죠.

파이브클라우드는 AWS 환경에서 Bedrock을 안전하게 도입할 수 있도록 키·권한 관리 체계를 함께 설계합니다. 이상 징후가 감지되면 Slack과 전화로 바로 알려주는 알림팩도 함께 지원해, 사고가 나더라도 인지 시점을 앞당길 수 있습니다.

대부분은 서버를 띄우고 서비스를 올리는 게 먼저입니다. 계정 보안은 "나중에 정리하자"며 미뤄두기 쉽죠. 하지만 클라우드에서는 계정 하나로 서버와 데이터베이스, 스토리지까지 모두 다룹니다. 계정 하나가 뚫리면 그 안의 모든 것이 위험해진다는 뜻입니다. 과금 폭탄, 데이터 유출, 리소스 삭제가 한꺼번에 터질 수도 있습니다.

다행히 계정 보안의 기본은 아래 네 가지 질문만으로 점검할 수 있습니다. 우리 회사는 이 중 몇 개에 바로 "괜찮다"고 답할 수 있을지 세어 보세요. 질문마다 왜 중요한지, 지금 무엇을 하면 되는지도 차례로 정리했습니다.

• 루트 사용자, MFA 없이 쓰고 있지 않나요?
• IAM 사용자 하나를 여러 명이 같이 쓰고 있지 않나요?
• 모든 사용자에게 Admin 권한을 주고 있지 않나요?
• 액세스 키가 외부로 새고 있지 않나요?
• 네 가지 항목 한눈에 점검하기

루트 사용자, MFA 없이 쓰고 있지 않나요?

루트 사용자는 AWS 계정을 처음 만들 때 입력한 이메일 주소와 비밀번호로 로그인하는 자격 증명입니다. 모든 서비스와 리소스는 물론 결제 정보까지 다룰 수 있는, 계정에서 가장 큰 권한을 가진 사용자죠.

그만큼 이메일과 비밀번호만 유출돼도 공격자는 계정을 통째로 조작할 수 있습니다. 리소스를 마음대로 만들어 과금을 일으키거나, 데이터를 빼낸 뒤 지워버릴 수도 있습니다. 권한이 가장 큰 계정이니, 가장 덜 써야 하는 계정이기도 합니다.

이렇게 점검하세요

☑️ 루트 사용자에 MFA(다중 인증)를 등록하셨나요?
현재 AWS는 모든 계정 유형의 루트 사용자에 MFA 설정을 요구하고, 첫 로그인 시도 후 35일 안에 등록하도록 하고 있습니다. 기기는 최대 8개까지 등록할 수 있으니 분실에 대비해 2개 이상 등록해 두시기 바랍니다.

☑️ 루트 사용자의 액세스 키가 남아 있지 않나요?
루트 액세스 키가 유출되면 CLI와 API로 계정 전체를 다룰 수 있게 됩니다. 처음부터 만들지 않는 게 원칙이고, 이미 있다면 삭제합니다.

☑️ 복구 수단에 접근할 수 있나요?
MFA 기기를 모두 잃어버렸을 때는 루트 이메일 수신함과 계정에 등록된 전화번호로 본인 확인을 합니다. 퇴사자 메일이나 예전 번호로 남아 있지 않은지 확인해보세요.

MFA 기기는 휴대폰 앱으로 6자리 코드를 만드는 가상 인증 앱, 같은 코드를 생성하는 전용 기기인 하드웨어 토큰, 지문이나 안면 인식으로 인증하는 패스키 중에서 고를 수 있습니다. 

루트 계정으로 로그인한 뒤, 우측 상단 계정 메뉴의 '보안 자격 증명'에서 멀티 팩터 인증 영역을 찾아 MFA 디바이스를 할당하면 됩니다.

Root 계정으로 로그인

우상단 계정 메뉴 내 보안 자격 증명 진입 및 멀티 팩터 인증 영역 확인

멀티 팩터 인증 영역 내 MFA 디바이스 할당 진입 및 MFA 생성과 등록

↗️AWS 공식 문서로 더 자세히 확인하기 (클릭 시 AWS 사용설명서로 이동)

• AWS 계정 루트 사용자의 MFA 활성화 
• 루트 사용자를 위한 액세스 키 삭제

계정 하나를 여러 명이 함께 쓰고 있지 않나요?

루트 사용자를 일상 업무에 쓰지 않으려면, 그 대신 쓸 사용자가 필요합니다. 이 역할을 하는 게 IAM(Identity and Access Management)입니다.

IAM은 AWS 리소스에 대한 접근을 제어하는 서비스로, 두 가지를 관리합니다. 누가 로그인할 수 있는지를 정하는 인증(Authentication), 그리고 로그인한 사용자가 무엇을 할 수 있는지를 정하는 권한 부여(Authorization)입니다. 별도 비용 없이 쓸 수 있으니 계정을 만든 날 바로 설정해두는 게 좋습니다.

IAM 사용자가 AWS에 접근하는 방식은 두 가지로 나뉩니다.

• 콘솔 접근
  • 자격 증명: 사용자 이름 + 비밀번호 (+ MFA)
  • 쓰는 곳: 웹 브라우저의 AWS Management Console
• 프로그래밍 방식 접근
  • 자격 증명: 액세스 키 ID + 시크릿 액세스 키
  • 쓰는 곳: AWS CLI, SDK, API 호출

계정 하나를 여러 명이 돌려 쓰면 누가 무엇을 했는지 추적할 수 없습니다. 한 명이 퇴사하거나 비밀번호가 새어 나가면, 함께 쓰던 모두의 접근 정보를 한꺼번에 바꿔야 하죠. 사용자를 나눠두면 문제가 생긴 사용자 한 명만 막으면 됩니다.

이렇게 점검하세요

☑️ 한 사람당 IAM 사용자 하나를 쓰고 있나요?
자격 증명은 팀원끼리도 공유하지 않습니다.

☑️ 권한을 그룹 단위로 주고 있나요?
개발, 운영, 재무처럼 역할별 그룹을 만들고 사용자를 그룹에 넣으면 입·퇴사 때 관리가 훨씬 쉬워집니다.

☑️ IAM 사용자에게도 MFA가 적용돼 있나요?
MFA는 루트만의 일이 아닙니다.

☑️ 쓰지 않는 사용자와 자격 증명이 남아 있지 않나요?
 IAM 콘솔의 '마지막 액세스' 정보를 보면 오래 쓰지 않은 사용자와 액세스 키를 찾을 수 있습니다.

↗️AWS 공식 문서로 더 자세히 확인하기 (클릭 시 AWS 사용설명서로 이동)

• IAM 사용자
• AWS 계정의 IAM 사용자 생성
• IAM 사용자의 권한 변경

모든 사용자에게 Admin 권한을 주고 있지 않나요?

사용자를 나눴다면 다음은 권한입니다. 원칙은 단순합니다. 업무에 필요한 권한만 주는 것, 흔히 최소 권한 원칙이라고 부르는 방식이죠.

그런데 실무에서는 권한 오류를 피하려고 사용자를 만들 때마다 AdministratorAccess 정책을 붙여두는 경우가 많습니다. 이 정책을 열어보면 내용은 이렇습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Action과 Resource가 모두 “*”입니다. 모든 서비스의 모든 작업을, 모든 리소스에 허용한다는 뜻입니다.

이 권한을 가진 사용자의 비밀번호나 액세스 키가 유출되면 피해 범위는 계정 전체가 됩니다. 반면 특정 S3 버킷의 읽기 권한만 가진 사용자라면, 키가 새어 나가도 피해는 그 버킷을 읽는 데서 그칩니다.

권한의 크기가 곧 사고의 크기입니다.

예를 들어 특정 S3 버킷의 파일을 읽기만 하는 애플리케이션이라면, 아래 정도의 권한이면 충분합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    }
  ]
}

이렇게 점검하세요

☑️ AWS 관리형 정책으로 시작하고 있나요?
ReadOnlyAccess나 직무별 관리형 정책처럼 이미 만들어진 정책을 먼저 활용하면 출발이 쉽습니다.

☑️ 고객 관리형 정책으로 범위를 좁혀가고 있나요?
AWS 관리형 정책은 모든 고객을 위해 만들어진 것이라, 우리 회사 용도에는 넓을 수 있습니다. 실제로 쓰는 작업과 리소스만 남긴 정책을 직접 만들어 교체합니다.

☑️ IAM Access Analyzer를 써보셨나요?
CloudTrail에 기록된 실제 사용 내역을 바탕으로, 필요한 권한만 담은 정책을 생성해줍니다.

☑️ 안 쓰는 권한을 주기적으로 회수하고 있나요?
'마지막 액세스' 정보에서 오래 쓰지 않은 권한을 찾아 정리합니다.

☑️ 관리자 권한은 소수에게만 있나요?
꼭 필요한 담당자에게만 주고, 이 사용자에게는 MFA를 반드시 적용합니다.처음부터 완벽한 최소 권한을 설계하기는 어렵습니다. 넓게 시작했더라도 사용 내역을 보며 조금씩 줄여가는 과정이 더 중요합니다.

↗️AWS 공식 문서로 더 자세히 확인하기 (클릭 시 AWS 사용설명서로 이동)

• 최소 권한 부여

액세스 키가 공개 저장소에 올라가 있지 않나요?

CLI나 SDK로 AWS를 다루려면 액세스 키가 필요한데요. 이 키를 .env, .yaml, .config 같은 설정 파일에 적어둔 채 GitHub나 Bitbucket의 공개 저장소에 그대로 푸시하는 경우가 생각보다 많습니다. 계정 유출 사고에서 가장 자주 보이는 경로이기도 합니다.

예를 들어 # .env - 이 파일이 공개 저장소에 올라가면 사고입니다

AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE

AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

특히 놓치기 쉬운 게 Git 히스토리입니다. 나중에 파일을 지우고 다시 커밋해도, 이전 커밋에는 키가 그대로 남아 있습니다. 한 번이라도 공개 저장소에 올라간 키는 이미 유출된 것으로 봐야 합니다.

예방: 이렇게 점검하세요

☑️ 액세스 키 없이 쓸 방법을 먼저 찾아보셨나요?
EC2나 Lambda 같은 AWS 컴퓨팅 리소스에 IAM 역할을 연결하면 임시 자격 증명이 자동으로 전달됩니다. 코드에 키를 넣을 필요 자체가 없어지죠.

☑️ 비밀 값을 AWS Secrets Manager에 보관하고 있나요?
DB 비밀번호나 외부 API 키는 코드에 적지 않고 Secrets Manager에 저장한 뒤, 애플리케이션이 실행 시점에 불러오도록 합니다. SDK 호출 몇 줄이면 충분합니다.

☑️ .gitignore에 설정 파일을 등록해뒀나요?
.env처럼 비밀 값이 들어가는 파일은 처음부터 Git 추적 대상에서 빼둡니다.

☑️ 푸시 전에 키를 검사하고 있나요?
GitHub의 푸시 보호(push protection)나 git-secrets 같은 도구를 쓰면 커밋에 섞인 키 패턴을 찾아 경고해줍니다.

☑️ 쓰지 않는 액세스 키를 정리하고 있나요?
미사용 키는 비활성화한 뒤 삭제하고, 꼭 필요한 키는 담당자가 바뀔 때처럼 필요한 시점에 교체합니다.

이미 노출됐다면

1. 해당 액세스 키를 즉시 비활성화하고, 새 키로 교체한 뒤 기존 키를 삭제합니다.
2. CloudTrail에서 그 키의 사용 내역을 확인합니다. 관리 이벤트는 기본으로 최근 90일치가 기록됩니다.
3. 모르는 리소스가 생기지 않았는지, IAM 사용자와 역할, 청구 내역까지 함께 확인합니다.
4. AWS Support 케이스로 안내를 받아 후속 조치를 진행합니다.

AWS도 자체 안전장치를 두고 있습니다. GitHub 시크릿 스캐닝과 연동해 공개 저장소에서 키가 발견되면, 해당 IAM 사용자에 AWSCompromisedKeyQuarantine 정책을 자동으로 붙이고 이메일과 Support 케이스로 알려주죠.

다만 이 정책은 위험한 작업 일부만 막을 뿐, 키 자체는 여전히 유효합니다. 교체와 삭제는 직접 해야 한다는 점을 꼭 기억해두세요!

액세스 키 삭제는 IAM 콘솔에서 키가 있는 사용자를 선택한 뒤, '보안 자격 증명' 탭의 액세스 키 영역에서 진행합니다.

IAM 내 IAM 사용자 중 액세스 키 존재 사용자 선택

보안 자격 증명 내 액세스 키 영역 중 삭제 작업 선택

↗️AWS 공식 문서로 더 자세히 확인하기 (클릭 시 AWS 사용설명서로 이동)

• IAM 사용자의 액세스 키 관리
• IAM 역할 생성
• IAM 사용자에게 권한을 부여할 역할 생성

[참고] Bedrock 같은 생성형 AI 서비스의 키가 새어 나가면 피해가 얼마나 빨리 커지는지 궁금하다면?
👉 늘어나는 Bedrock 해킹 사고, 우리 AWS 계정은 안전한가요?

4가지 질문, 한눈에 점검하기

지금까지 살펴본 내용을 질문과 정답, 핵심 조치로 다시 정리했습니다.

☑️ 루트 사용자를 MFA 없이 사용하고 있나요?
정답: 아니요
루트에 MFA 등록, 루트 액세스 키 삭제, 일상 작업에 루트 사용 금지

☑️ 계정 내 IAM 사용자를 만들어 쓰고 있나요?
정답: 예
한 사람당 사용자 하나, 그룹 단위 권한, 전원 MFA

☑️ 모든 사용자에게 Admin 권한이 있나요?
정답: 아니요
최소 권한 부여, 미사용 권한 주기적 회수

☑️ 자격 증명이 외부 저장소에 공개돼 있나요?
정답: 아니요
IAM 역할과 Secrets Manager 사용, 미사용 키 삭제, 푸시 전 검사

네 가지 모두 계정을 만든 날 바로 적용할 수 있는 항목입니다. 하나라도 놓친 게 있다면 오늘 아래 순서대로 확인해보세요.

1. 루트 사용자에 MFA가 등록돼 있는지 확인
   2. 루트 사용자의 액세스 키가 있다면 삭제
   3. 일상 작업용 IAM 사용자를 따로 만들고 MFA 적용
   4. AdministratorAccess가 붙은 사용자 목록을 확인하고 축소
   5. 오래 쓰지 않은 액세스 키를 비활성화한 뒤 삭제
   6. 저장소에 .env 같은 설정 파일이 올라가 있지 않은지 검색

계정 보안은 한 번 설정하고 끝나는 일이 아닙니다. 사람이 늘고 서비스가 늘면 사용자와 권한도 함께 늘어나기 때문에, 분기에 한 번 정도는 같은 체크리스트로 다시 점검하는 게 안전합니다.

여기까지 읽고 나면 "우리 계정은 지금 몇 개나 통과할까" 궁금해지실 텐데요. 막상 IAM 사용자와 정책을 하나씩 열어보면, 누가 언제 만든 건지 알 수 없는 사용자나 용도가 불분명한 키가 생각보다 많이 나옵니다.

파이브클라우드는 AWS 계정의 루트·IAM 설정과 권한 구조를 함께 점검하고, 우리 회사 조직 구조에 맞는 권한 체계를 설계해 드립니다. 설정 이후에도 이상 징후를 빠르게 알아차릴 수 있도록 알림 체계까지 이어서 지원합니다.

[참고] 보안 설정 이후, 이상 징후를 놓치지 않고 바로 통보받는 방법이 궁금하다면?
👉 상주 관제 없이 하는 AWS 운영, 월 5만 원부터 가능한 이유

채용의 흐름을 바꾸는 SaaS, ‘그리팅’을 만드는 두들린

그리팅은 국내 1위 채용 관리 솔루션입니다. 채용에 필요한 모든 기능을 하나의 플랫폼에서 제공합니다. 상시 채용부터 대규모 공개 채용까지, 채용 규모와 전략에 구애받지 않고 유연하면서도 안정적으로 운영할 수 있다는 점이 강점인데요. 연중 채용이 활발한 패스트파이브에서도 그리팅을 사용하고 있습니다.

나아가 그리팅은 단순한 업무 효율화를 넘어 채용 전 과정에 AI를 더하는 '채용 AX'를 통해, 기업이 핵심 인재를 더 빠르게 만날 수 있도록 채용의 방식 자체를 혁신해 나가고 있습니다. 현재 스타트업부터 중견·대기업까지 10,000곳이 넘는 기업이 그리팅과 함께하고 있습니다.

고객사 10,000곳의 채용을 감당하는 인프라, 비용은 어떻게 관리할까

공고가 열리고, 지원서가 쌓이고, 면접 일정이 조율되는 모든 순간이 인프라 위에서 돌아갑니다. 서비스가 커진다는 건 곧 인프라가 커진다는 뜻이고, 인프라가 커질수록 청구 금액이 올라갑니다.

1천만 원짜리 청구서가 가져온 경각심

두들린이 클라우드 비용을 '관리해야 할 대상'으로 인식하기 시작한 건 비싼 청구서가 날아오기 시작했던 순간이었습니다.

"고객사들이 일정 규모를 넘어서면서 클라우드 비용이 월 1천만 원을 넘어간 순간부터 무서워지기 시작하더라고요."

막상 내역을 뜯어보니 생각지도 못했던 곳에서 비용이 새고 있었습니다.

• EC2가 Auto Scaling* 되면서 발생한, 쓰지 않는 자원
• PoC*를 위해 만들어두고 삭제하지 않은 자원

두 경우 모두 담당자가 의도해서 쓴 비용이 아니었습니다. 관리 범위 밖에서 조용히 쌓이던 금액이었죠. 이후로 두들린은 본격적인 비용 관리에 들어갑니다.

*Auto Scaling: 트래픽 변화에 맞춰 서버 대수를 자동으로 늘리고 줄이는 AWS 기능입니다. 편리하지만, 늘어난 자원이 제때 정리되지 않으면 비용으로 남습니다. 
*PoC(Proof of Concept): 기술이나 아이디어가 실제로 동작하는지 검증하는 시험 단계를 뜻합니다.

“매달 1%라도 줄이자” 루틴이 된 비용 관리

두들린이 비용을 바라보는 관점은 명확합니다. 절감은 특별한 이벤트가 아니라 루틴이어야 한다는 것.

"비용 절감의 필요성을 어느 순간 느끼고 단기적으로 할 수 있는 방안들을 실현하는 것도 방법이지만, 그렇게 접근하면 이미 많은 비용이 버려진 뒤고 장기적인 계획을 세우는 데에도 한계가 생겨요."

"지금보다 1%라도 줄일 수 있는 방법이 없을까?" 이 질문을 매주, 매달 계속 던지다 보면 어떤 부분이 문제인지, 앞으로 어떤 계획을 세워야 하는지가 선명해진다는 겁니다. 실제로 두들린은 매달 직접 빌링 포털에 접속해 비용 발생 내역을 눈으로 확인하고, 유관 부서와 절감 방안을 논의합니다.

비용 관리를 꾸준히 이어온 배경에는 SaaS 비즈니스에 대한 명확한 인식이 있었습니다. 결국 클라우드 비용을 낮추는 것이 곧 회사의 이익을 키우는 길이니까요.

놓친 옵션을 찾아주는 파트너, 파이브클라우드

직접 빌링 포털을 확인하는 담당자에게도 AWS는 복잡합니다. 서비스마다 세부 옵션이 갈리고, 그 선택 하나하나가 비용으로 연결되니까요. 두들린이 파이브클라우드와 정기 미팅을 이어온 이유가 여기에 있습니다.

"AWS를 쓰다 보면 나도 모르게 비용이 발생하는 부분이 많고, 옵션 하나하나가 비용이 되는 지점이 정말 많더라고요. 파이브클라우드와 비용 절감 아젠다로 정기적으로 미팅을 했는데, 매번 저희 사용량을 꼼꼼히 들여다보고 오셔서 저희가 모르고 있던 옵션 하나로 비용이 절감되고 있다는 걸 알려주셨어요."

번거롭고 손이 많이 가는 영역은 파이브클라우드에 맡기기로 했습니다.

"RI(Reserved Instance)의 만료 시기를 관리하는 게 솔직히 너무 번거롭고, 시간당 사용 금액을 약정하는 SP(Savings Plans)는 그 범위를 적절히 계산해서 걸어둬야 하다 보니 직접 하기엔 어려웠어요. 그런데 파이브클라우드에서는 그 시기를 관리해서 알려주시고 적절한 SP 값까지 알려주시니 믿고 맡기게 됐습니다."

RI도 SP도 한 번 설정하고 끝나는 일이 아닙니다. 만료 시점이 다가오면 갱신 여부를 판단해야 하고, 사용량이 달라지면 약정값도 다시 계산해야 하죠. 주기적으로 손이 가는 운영 업무인 셈입니다.

두들린이 꼽은 파이브클라우드의 가장 만족스러운 부분은 비즈니스를 이해하는 파트너십이었습니다.

"세일즈와 엔지니어 분들이 각자 역할을 넘어서 함께 저희 상황을 챙겨주시는 느낌이었어요. 단순히 고객을 넘어 파트너로서 저희 비즈니스 상황을 이해해주시고, 해결할 방법을 찾아주시는 게 가장 만족스러운 부분입니다."

두들린의 RI/SP 운영법

그렇다면 두들린은 RI와 SP를 실제로 어떻게 운영하고 있을까요?

1. 약정은 예측이 가능해진 뒤에

"서비스가 안정화되고 트래픽 예측이 가능해질 때부터였어요. 빠르게 성장하던 시기에는 한두 달 사이에 인스턴스가 1~2개씩 꾸준히 늘었는데, 안정화되고 나서는 인스턴스 개수가 고정되고 필요한 스펙도 확정할 수 있었거든요. 그때부터는 무조건 RI/SP를 쓰는 게 맞다고 판단했어요."

약정 할인은 사용량을 예측할 수 있을 때 효과를 냅니다. 

2. 단순 연장 대신 스펙 교체로 효율 극대화

RI를 걸기 위해 인스턴스 개수를 확인하던 중, 두들린은 단순 연장이 아닌 스펙 변경이라는 선택지를 발견합니다.

"내부적으로 Spring 기반 서버 자원이 많다 보니 CPU 사용량에 비해 Memory 사용량이 더 높은 편인데요. 기존에는 m 타입 인스턴스를 쓰고 있었는데, r 타입으로 바꾸면 인스턴스 수가 절반 이상 줄어들 수 있겠다고 판단해서 빠르게 교체하고 RI를 걸었어요."

m 타입은 CPU와 메모리가 균형 잡힌 범용 인스턴스, r 타입은 메모리에 최적화된 인스턴스입니다. 같은 vCPU 기준으로 r 타입이 더 많은 메모리를 제공하죠. 메모리를 많이 쓰는 워크로드라면 같은 작업을 더 적은 대수로 감당할 수 있습니다.

약정보다 '무엇에 약정할지'를 먼저 정리한 순서가 효과를 키운 사례입니다. 갱신 시점을 단순 연장의 기회가 아니라 구조를 점검하는 기회로 본 셈이죠.

3. 비용 관리 주체 선정

"비용 관리는 저희처럼 SaaS 서비스를 하는 기업에게는 당연한 일이라고 생각해요. 다만 단순히 신경 쓰는 걸 넘어서 본격적으로 줄이기 위한 액션까지 수행한 건, 클라우드를 중점적으로 관리할 수 있는 DevOps 부서가 생기고 나서부터였던 것 같아요."

비용 절감이 좋은 일이라는 데 반대하는 조직은 없습니다. 다만 관리 주체가 정해지지 않으면 실행하기 어렵습니다. 두들린의 경우 DevOps 부서가 관리의 책임을 맡았죠.

성장의 속도만큼 인프라 효율도 높이기 위해

두들린의 다음 과제는 두 가지입니다. 

1. 세밀한 관리를 위한 '리소스 태깅'

"일단 리소스 태깅이 시급한 과제예요. 지금은 AWS 서비스 단위로 비용을 보다 보니 세밀하게 관리하기엔 한계가 있는데, 태깅을 통해서 더 심도 있게 비용을 줄이고 싶어요."

서비스 단위로만 보면 어느 팀의 어느 기능이 얼마를 쓰는지 알 수 없습니다. 태깅을 하면 그 구분이 가능해집니다.

2. 아키텍처 전환을 위한 'Graviton 도입'

"다음으로 보고 있는 건 Graviton* 타입으로의 변경이에요. Graviton 인스턴스가 다른 인스턴스들에 비해 비용이 저렴한 편이라 넘어가고 싶은데, 해당 타입으로 넘어가려면 많은 시간을 테스트에 할애해야 가능하더라고요. 프로젝트 기간을 조금 길게 잡고 전환하는 것을 목표로 하고 있습니다."

*Graviton: AWS가 자체 설계한 ARM 기반 프로세서입니다. 같은 성능 대비 비용이 낮지만, 기존 x86 환경과 아키텍처가 달라 애플리케이션 호환성 검증이 필요합니다.

당장의 절감액에 연연하기보다 지속 가능한 구조를 지향하며 비용을 더 쪼개어 들여다보고 아키텍처를 바꾸는 시도를 하는 등 두들린은 성장과 효율을 동시에 잡아가고 있습니다.

두들린과 패스트파이브, 서로의 성장을 돕는 파트너십

두들린은 AWS 클라우드 비용 관리와 RI/SP 운영에 파이브클라우드를 이용하고 있고, 패스트파이브는 채용 업무에 두들린의 그리팅을 활용하고 있습니다. 각자의 영역에서 서로를 고객이자 파트너로 두고 있는 관계입니다.

패스트파이브가 직접 써보고 선택한 채용 솔루션, 그리팅이 궁금하시다면
👉그리팅 데모 신청 >>

범위를 정하려면 먼저 짚어야 할 질문이 있습니다. 

장애 대응은 왜 늦어질까요?

관제 인력이 없어서가 아닙니다. 이상 징후가 담당자에게 닿는 '경로'가 설계되어 있지 않기 때문입니다.

실제로 현장에서 만나는 조직 대부분은 이미 CloudWatch에 알람을 걸어두고, 대시보드도 늘 열어두고 있습니다. 그런데도 장애 소식은 고객 문의로 먼저 들어오곤 하죠.

문제는 이 공백을 '사람'으로 메우려 할 때 생깁니다. 관제 도입을 알아보면 받게 되는 견적은 대개 24시간 상주 인력이 기준입니다. 회사 규모에 비해 부담스러운 금액이다 보니 검토는 원점으로 돌아가곤 하죠. 그러다 몇 달 뒤 다음 장애가 터지고 나서야 같은 논의가 다시 시작됩니다.

해법이 '사람을 더 두는 것'만 있는 건 아닙니다. 24시간 상주 관제와 아무 대응도 하지 않는 것 사이에는, 감지와 통보만 떼어내 자동화하는 방법이 있습니다. 파이브클라우드는 이 방법을 표준 상품 '알림팩'으로 정리했습니다. 이상 징후가 감지되면 심각도에 따라 Slack으로, 긴급한 경우 전화로까지 담당자에게 곧바로 알려주는 구성이죠. 사람이 상주하지는 않지만, 앞서 말한 '담당자에게 닿는 경로'를 만들어주는 경량 관제에 가깝습니다.

관제 고민이 좀처럼 풀리지 않는 이유

알람은 켜져 있지만, 새벽에는 볼 사람이 없습니다

문제는 알람이 어디로 가느냐입니다. 이메일함이나 일반 업무 채널로 흘러가면, 근무 시간이 끝난 뒤에는 아무도 열어보지 않습니다. 새벽 3시에 난 장애를 다음 날 출근해서야 알게 되는 이유죠.

중요한 알람이 정보성 알람에 묻힙니다

임계치를 기본값으로 두면 하루에도 수십 건의 알람이 쏟아지는데, 대부분은 당장 조치할 필요가 없는 신호입니다. 이런 알람이 며칠만 쌓여도 사람들은 채널을 열지 않게 되고, 정말 중요한 알람도 그 사이에 묻혀버립니다.

견적은 상주 인력을 전제로 나옵니다

이런 공백을 메우려고 관제를 문의하면, 24시간 3교대 엔지니어 배치를 기준으로 한 금액이 나옵니다. 대규모 트래픽을 다루는 조직이라면 타당한 구조입니다. 하지만 EC2 수십 대와 RDS 몇 대를 운영하는 조직에는 과한 설계죠. 결국 부담스러운 금액에 검토는 원점으로 돌아가고, 몇 달 뒤 다음 장애가 터지고 나서야 같은 논의가 다시 시작됩니다.

세 가지 문제의 뿌리는 같습니다. 무엇을 감시할지, 심각도를 어떻게 나눌지, 각 알람을 누구에게 어떤 채널로 보낼지가 설계되어 있지 않다는 점이죠.

필요한 건 상주 인력이 아니라 전달 체계

관제 업무는 크게 세 단계로 나뉩니다. 이상 징후를 감지하고, 심각도를 판단해 전달하고, 실제로 조치하는 단계죠. 이 중 앞의 두 단계는 사람이 상주하지 않아도 표준화할 수 있습니다. 인지 지연은 두 번째 단계에서 생기고, 비용이 크게 드는 건 세 번째 단계입니다.

전달 체계를 나누는 기준은 우편함과 화재경보기를 떠올리면 쉽습니다. 우편함은 하루 한 번만 확인해도 되지만, 화재경보는 자는 사람도 깨워야 하죠. 알람도 이 원칙대로 나눕니다.

• Critical: 서비스에 즉시 영향을 주는 이상. Slack 알림과 전화가 동시에 나갑니다.
• Normal: 추이를 지켜봐야 하는 신호. 일반 채널에 쌓아두고 근무 시간에 확인합니다.

이렇게만 나눠도 야간 장애를 알아차리는 시점이 몇 시간 단위로 앞당겨집니다. 전화까지 가는 알람을 의도적으로 좁히니, 앞서 말한 알람 피로도 함께 줄어들고요.

파이브클라우드는 클라우드 도입과 운영 단계에 맞춰 세 가지 상품을 제공합니다. 환경 분석과 인프라 설계·구축을 맡는 구축팩, 실시간 감지와 통보를 맡는 알림팩, 전담 기술지원까지 포함하는 운영팩입니다. 이 중 대부분의 조직에 가장 먼저 필요한 건 알림팩입니다.

알림팩이 '표준 상품'이라는 건 온보딩이 가볍다는 뜻이기도 합니다. 감시 항목 정의부터 SNS 연동, 전용 Slack 채널 개설, 알람 설정과 테스트까지 절차가 정해져 있어 2시간 안에 세팅이 끝납니다. 내부에서 같은 작업을 처음부터 설계하는 것과 비교하면 차이가 크죠.

[참고] 관제를 어디까지 맡길지, MSP라는 개념부터 정리해두고 싶다면?
👉 클라우드 MSP, 정확히 무엇인가요? 역할부터 비용까지를 함께 보세요!

도입 전에 확인해야 할 세 가지 기준

알림 체계를 검토한다면, 견적을 받기 전에 아래 세 가지부터 내부에서 정리해 두세요. 필요한 범위가 훨씬 빨리 좁혀집니다.

감시할 리소스가 몇 개인가

EC2, RDS, ELB, EKS 노드까지 포함해 실제로 상태를 봐야 하는 리소스를 세어봅니다. 이 숫자가 알림팩 티어를 정하는 기준입니다. 모르는 채로 견적을 요청하면 과한 구성으로 이어지기 쉽습니다.

월 몇 건의 기술지원이 필요한가

지난 3개월간 외부 도움이 필요했던 이슈를 세어봅니다. 분기에 한두 건이라면 브론즈로 충분하고, 매주 문의가 생긴다면 골드 이상이나 운영팩을 검토하는 게 합리적입니다. 기술지원 횟수는 매월 갱신되어, 필요에 따라 조정할 수 있습니다.

새벽에 전화를 받을 사람이 정해져 있는가

가장 자주 빠지는 항목입니다. Critical 알람이 전화로 울렸을 때 받을 담당자와 순번이 정해져 있지 않으면, 통보 체계를 갖춰도 대응은 늦어집니다. 알람 설계보다 수신자 목록이 먼저인 이유죠.

[참고] 실제로 구축부터 운영 지원까지 파이브클라우드의 AWS MSP를 도입한 사례가 궁금하다면? 
👉 AWS 구축부터 운영지원까지! MSP 서비스를 함께 보세요!

새벽에 EC2가 멈추면, 지금 누구의 휴대폰이 울리나요?

알람 채널에는 읽지 않은 메시지가 몇 건이나 쌓여 있나요?

두 질문에 바로 답하기 어렵다면, 견적보다 알람 구조 점검이 먼저입니다. 다만 이 설계를 내부에서 처음부터 잡으려면 생각보다 손이 많이 갑니다.

파이브클라우드 알림팩은 정해진 온보딩 절차로 이 과정을 대신하고, 월 5만 원부터 시작할 수 있습니다. 감지와 통보만 맡기는 구성이라 상주 관제와는 비용의 자릿수가 다르죠. 상주 관제는 아직 이르다고 판단했던 조직도 부담 없이 시작할 수 있는 이유입니다. 구축이나 전담 기술지원이 필요하다면 구축팩·운영팩과 함께 구성할 수도 있습니다.

그런데 똑같은 제품인데도, 공식 리셀러(파트너)를 통하면 홈페이지보다 낮은 금액을 제안받는 경우가 있습니다. 중간에 한 다리를 더 거치면 값이 붙는 게 상식인데, 기업용 소프트웨어 시장은 그 상식대로 움직이지 않습니다.

리셀러를 거쳐 얻는 건 가격만이 아닙니다. 계약 만료일을 챙기고, 흩어진 청구서를 정리하고, 신규 입사자 계정을 열어주는 일까지. 라이선스를 굴리는 데 드는 관리 업무를 통째로 맡길 수 있죠.

물론 리셀러에게 맡기는 게 능사는 아닙니다. 직접 구매가 더 합리적인 경우도 분명 있고요.

이번 글에서는 리셀러 구매와 직접 구매를 조건별로 비교하며, 소프트웨어를 가장 합리적으로 구매하는 방법을 알려드리겠습니다.

리셀러를 거치는데도 더 저렴한 이유

소프트웨어를 개발하고 판매하는 기업을 '벤더'라고 부릅니다. 벤더가 홈페이지에 공개한 가격과 공식 리셀러에게 제공하는 가격은 다를 수 있습니다.

벤더 입장에서 영업과 계약, 결제, 고객 지원은 적지 않은 비용이 드는 일입니다. 이 업무를 리셀러가 대신 맡는 대가로, 벤더는 리셀러에게 별도의 공급 조건을 적용합니다.

홈페이지에서 정가로 판매하는 제품이라도 리셀러는 파트너 공급가 기준으로 견적을 냅니다. 여기에 벤더가 파트너 채널에만 제공하는 프로모션이나 개별 협상 조건이 더해지면 조건은 더 유리해집니다. 고객이 직접 벤더와 조건을 조율하지 않아도, 리셀러가 이미 확보한 구매 조건을 그대로 활용할 수 있는 셈입니다.

리셀러의 마진은 홈페이지 정가 위에 추가되지 않고, 벤더가 리셀러에게 제공한 공급 조건 안에서 조정됩니다. "리셀러가 마진을 붙이는데 어떻게 더 저렴할 수 있지?"라는 의문이 이제 풀리실 겁니다.

물론 할인 폭은 제품, 구매 수량, 파트너 등급, 계약 시점에 따라 달라집니다. 리셀러가 언제나 더 저렴하다고 단정할 수는 없습니다. 다만 리셀러를 거치면 무조건 더 비싸진다고 판단할 이유도 없습니다.

지금 쓰고 있는 제품이 있다면 공식 리셀러에게 견적을 요청해 보세요. 같은 제품, 같은 라이선스인데 조건이 다를 수 있습니다.

구매가 끝나도 관리 업무는 계속됩니다

소프트웨어 구매는 결제로 끝나지 않습니다.

신규 입사자가 생기면 계정을 추가하고, 퇴사자가 생기면 라이선스를 회수합니다. 인원이 바뀌면 요금제를 조정하고, 계약 기간이 다가오면 갱신 여부도 판단해야 하죠. 여기에 제품마다 다른 결제일과 문의 창구까지 따로 챙겨야 합니다. 소프트웨어 하나면 몰라도, 열 개 스무 개가 되면 이건 관리 업무가 크게 늘어나죠.

직접 구매하면 이 업무를 내부 담당자가 모두 처리해야 하지만, 리셀러를 통하면 지원 범위에 따라 이 업무의 상당 부분을 직접 처리하지 않아도 됩니다.

특히 담당자가 바뀌는 시점에서 차이가 크게 느껴질 거예요. 직접 구매한 제품은 갱신 안내가 최초 결제 담당자의 이메일로 전달되는 경우가 많은데, 담당자가 퇴사하거나 부서를 옮기면 알림 경로도 같이 놓치는 경우가 많습니다. 갱신 누락 사고가 담당자 교체 시점에 주로 발생하는 이유입니다. 하지만 리셀러가 계약 이력을 함께 관리한다면 담당자가 바뀌어도 확인할 수 있는 창구가 남아 있습니다.

소프트웨어가 늘어날 수록 업무 부담이 늘어납니다

소프트웨어 하나만 놓고 보면 큰 부담처럼 느껴지지 않을 수 있습니다. 하지만 사용하는 제품이 늘어나면 같은 업무가 벤더 수만큼 반복됩니다. 벤더마다 계약 조건도, 갱신일도, 결제 방식도, 문의 창구도 모두 다르기 때문입니다.

연간 관리 시간은 대략 이렇게 계산해볼 수 있습니다.

(벤더 수 × 갱신 처리 시간) + (월 청구서 장수 × 12 × 건당 회계 처리 시간) + (벤더 수 × 연간 문의 대응 시간)

여섯 개의 소프트웨어를 사용한다고 가정해보겠습니다. 실제 소요 시간은 회사마다 다르니, 우리 회사 상황에 맞는 숫자를 넣어 직접 계산해보시길 권합니다.

1년에 약 64시간입니다. 담당자 인건비를 시간당 3만 원으로 가정하면 벤더 6곳 기준 연 190만 원 남짓, 10 곳이면 약 320만 원 수준입니다.

여기에 시간으로 환산되지 않는 리스크까지 더해질 가능성이 높죠. 모르는 사이 결제된 자동 갱신, 회수하지 않은 퇴사자 라이선스, 팀별 중복 구매까지.

제품이 하나일 때는 크게 느껴지지 않던 차이가, 사용하는 소프트웨어가 늘어나며 새는 비용으로 드러나게 됩니다.

[참고] 여러 SaaS를 쓰다 보면 이런 관리 시간 외에도 중복 구독이나 미사용 라이선스 같은 숨은 비용이 함께 쌓이는데요.
👉 정액제 끝난 SaaS 비용, 핀옵스(FinOps)로 관리하는 이유를 함께 보세요!

어떤 리셀러를 선택하느냐도 중요합니다

모든 리셀러가 같은 수준의 서비스를 제공하는 것은 아닙니다.

라이선스만 받아서 전달하는 곳도 있고, 구매 조건 검토부터 청구, 갱신, 기술 문의까지 함께 지원하는 곳도 있습니다. 그래서 견적을 받을 때는 가격뿐 아니라 어떤 업무를 지원하는지도 함께 확인하는 게 좋습니다.

가격·계약 영역

• 파트너 공급 할인 활용
• 벤더 프로모션 적용
• 계약 기간·수량별 옵션 비교
• 갱신 시 조건 재협상
• 다수 계약 경험 기반 조건 벤치마크

운영·지원 영역

• 여러 SaaS 구매 창구 통합
• 라이선스 증감과 갱신 관리
• 초기 세팅 및 마이그레이션 지원
• 기술 문의와 벤더 에스컬레이션
• 사용자 교육·활용 지원 (리셀러에 따라 상이)

직접 구매가 유리한 경우도 있습니다

그렇다면 모든 소프트웨어를 반드시 리셀러를 통해 구매해야 할까요? 그렇지는 않습니다. 구매 채널이나 계약 조건에 따라 직접 구매가 유일한 선택지이거나, 더 유리한 경우도 있습니다.

이런 경우는 대체로 구매 경로 자체에 제약이 있는 상황입니다. 회사 규모가 작다는 이유만으로 직접 구매가 유리해지는 것은 아닙니다. 직원 다섯 명 규모여도 리셀러 조건이 더 좋을 수 있고, 규모가 큰 회사라도 특정 제품은 직접 구매해야 할 수 있습니다.

비교 기준은 총소유비용(TCO)입니다

홈페이지 가격과 리셀러 견적을 나란히 놓고 보는 것만으로는 실제 비용이 드러나지 않습니다. 어느 쪽이든 라이선스 가격 뒤에 따라붙는 항목이 있기 때문입니다.

직접 구매의 실제 비용은 라이선스 가격에 내부 관리 비용을 더한 값입니다. 계약 확인, 청구서 처리, 갱신 일정 관리처럼 앞서 64시간으로 계산해본 그 업무들이죠. 리셀러 구매는 제안 가격에, 리셀러가 처리하고 남은 몫만 더하면 됩니다.

사용하는 제품이 적고 계약이 단순하다면 두 값의 차이는 크지 않습니다. 하지만 제품이 늘어나고 인원 변동이 잦을수록 리셀러 구매 쪽이 효율적일 수 있습니다.

실무에서는 아래 두 가지를 먼저 점검해 보세요

1. 지금 제안받은 가격이 우리 회사가 확보할 수 있는 최선의 조건인가요?
2. 구매 이후 회사 내부에 남는 관리 업무는 얼마나 되나요?

같은 소프트웨어라도 어떤 방식으로 구매하고 관리하느냐에 따라 실제 비용은 달라집니다. 좋은 리셀러를 통하는 이유도 여기에 있습니다. 구매 조건을 유리하게 가져가면서, 구매 이후 반복될 운영 업무까지 함께 줄이는 것이죠.

여기까지 읽으셨다면 우리 회사가 지금 쓰고 있는 소프트웨어들을 어떤 방식으로 구매했는지 한 번 점검해보고 싶어지실 텐데요. 문제는 벤더 하나하나에 다시 연락해 조건을 확인하는 일이 꽤 번거롭다는 겁니다.

파이브클라우드는 MS 365, Google Workspace, Adobe 등 기업이 자주 쓰는 소프트웨어를 통합 구매·관리할 수 있도록 돕는 공식 파트너입니다. 여러 벤더에 흩어진 계약을 하나의 창구로 모으고, 갱신·청구·라이선스 변경까지 함께 챙깁니다.

클라우드 서비스 보안인증(CSAP)과 정보보호 및 개인정보보호 관리체계(ISMS) 인증을 획득해 기업이 요구하는 보안 기준을 충족하며, 기존 업무 환경 안에서 AI 기능을 자연스럽게 활용할 수 있습니다.

혜택 안내

✅ 첫해 이용료 50% 할인

✅ 5대 법정의무교육 무료 제공

안내 사항

- 첫해 50% 할인은 하이웍스를 처음 이용하는 기업의 메일·그룹웨어 전 상품 대상이며, 프로모션 기간은 2026년 11월 30일까지입니다.
- 5대 법정의무교육 무료 제공은 하이웍스 기업교육 서비스 이용 고객 중 2026년 가입 고객 대상 1회 제공되며, 제공 기한은 2026년 12월 31일까지입니다.

웹사이트와 애플리케이션의 콘텐츠를 사용자와 가까운 위치에서 빠르게 전달함과 동시에, 각종 사이버 공격으로부터 안정적으로 보호할 수 있도록 지원합니다.

혜택 안내

✅ 연간 약정 금액에 대한 Cloudflare CDN

✅ 패스트파이브 특별 할인 제공

인프라 모니터링, APM(애플리케이션 성능 모니터링), 로그 관리, 보안 모니터링 등의 기능을 대시보드로 통합 제공하여, 시스템 이상 징후를 빠르게 감지하고 장애 대응 시간을 단축할 수 있도록 지원합니다.

혜택 안내

✅ 무상 POC 제공

✅ 연간 약정 금액에 대한 패스트파이브 특별 할인 제공 

기존 VPN보다 비용과 복잡성 없이 엔터프라이즈급 보안과 성능을 제공하며, 원격 근무·IT 지원·다수 장치의 통합 관리까지 하나의 플랫폼에서 해결할 수 있습니다.

혜택 안내

✅ 최대 7% 할인

안내 사항

- 연간 계약으로만 진행 가능합니다.
- 본 혜택은 신규 계약 고객 대상이며, 기존 팀뷰어 이용 고객은 영업보호 정책상 계약 이관이 불가합니다.
- 사용 규모가 크거나 엔터프라이즈(Tensor) 환경으로 도입하실 경우 7% 이상의 할인율이 적용될 수 있어, 별도 상담을 통해 안내드립니다.
- 원화 세금계산서 발행이 가능합니다.

대부분의 조직은 AWS를 온디맨드(On-Demand) 방식으로 시작합니다. 쓴 만큼 내는 구조라 워크로드 예측이 어려운 초기에는 합리적인 선택입니다. 문제는 서비스가 안정화되고 사용 패턴이 예측 가능해진 뒤에도, 단가를 결정하는 요금 모델은 초기 그대로 온디맨드에 머물러 있는 경우가 많다는 점입니다.

RI(Reserved Instance)와 Savings Plans(SP)는 일정 기간 사용을 약속하는 대신 온디맨드 대비 최대 72~75%까지 할인받는 구조입니다. 월 컴퓨팅 지출이 큰 조직일수록 이 제도의 활용 여부에 따라 연간 비용 차이가 수억 원단위로 벌어집니다. 

'약정'이라는 단어 때문에 도입을 미루는 경우도 많지만, 구조를 이해하면 리스크는 충분히 통제할 수 있습니다.

온디맨드만 쓰는 것은 '정가'만 내는 구조입니다

온디맨드를 택시에 빗대어 보겠습니다. 언제든 잡아탈 수 있고, 내리고 싶을 때 내리면 됩니다. 대신 미터기 요금을 냅니다. 언제 어디로 갈지 모르는 출장 같은 이동이라면 택시가 정답입니다.

그런데 매일 같은 시간에 같은 경로로 출퇴근하면서 매번 택시를 타는 사람은 드뭅니다. 클라우드도 같은 구조입니다. 운영 환경의 웹 서버, 24시간 돌아가는 데이터베이스, 항상 떠 있어야 하는 API 서버처럼 1년 뒤에도 켜져 있을 게 확실한 워크로드에 온디맨드 정가를 계속 내는 것은, 값싼 정기권이 있는 노선을 매일 비싼 택시로 다니는 것과 같습니다.

온디맨드 요금은 매달 쓴 만큼 찍히기 때문에, 낭비가 아니라 정상 사용처럼 보입니다. 인스턴스를 껐다 켜는 스케줄링, 스펙을 줄이는 라이트사이징은 모두 '사용량' 측면의 절감이라 눈에 보이고 실행하기도 쉽습니다. 반면 '단가’ 측면에서 같은 사용량을 더 싸게 사는 방법이 있다는 걸 많이 놓치십니다.

실제 기업들의 AWS 비용 점검을 하다 보면, 사용량 최적화는 어느 정도 되어 있는데, 이 사용량 전체를 여전히 정가로 지불하고 있는 경우를 많이 봅니다. 이때 남은 절감 수단이 약정 할인입니다. 즉, 온디맨드는 유연함의 대가로 정가를 내는 예측 불가능한 워크로드용 방식이고, 약정 할인(RI/SP)은 사용을 약속하는 대가로 할인을 받는 예측 가능한 워크로드용 방식입니다.

RI/SP는 "우리 인프라에서 확실히 계속 쓸 부분이 어디인가"를 요금에 반영하는 것입니다. 사용 패턴은 이미 바뀌었다면, 지불 방식 변경도 고려해 보시는 게 좋습니다.

[참고] 인스턴스 사용량 축은 어떻게 최적화하는지 더 궁금하다면?
👉 AWS 비용이 매달 새는 3가지 구조와 절감 포인트

RI와 Savings Plans, 각각 무엇을 약속하는 걸까요

RI(Reserved Instance)는 '무엇을 쓸지'를 약속합니다. Savings Plans(SP)는 '얼마나 쓸지'를 약속합니다. 같은 할인 제도인데 약속의 대상이 다르죠.

RI는 "서울 리전에서, 이 타입의 인스턴스를, 1년(또는 3년) 동안 쓰겠다"고 구성을 지정해서 예약하는 방식입니다. 예약과 같은 조건(리전, 인스턴스 타입, OS 등)의 인스턴스가 실제로 돌아가고 있으면 그 요금이 자동으로 할인가로 청구되고, 조건이 다른 인스턴스만 돌아가고 있으면 할인은 적용되지 않습니다.

SP는 "시간당 10달러어치 컴퓨팅을 쓰겠다"라고 금액만 약속하는 방식입니다. 어떤 인스턴스를 쓰든 그 금액까지는 할인가가 자동 적용됩니다. 다만 약정한 시간당 금액은 실제 사용량과 무관하게 매시간 청구되고, 사용량이 약정에 못 미치면 그 차액은 그대로 낭비가 됩니다. 할인 범위에 따라 Compute SP와 EC2 Instance SP, 두 가지로 나뉩니다.

네 가지 옵션의 조건과 할인율을 표로 정리했습니다. (할인율은 3년 약정에 선결제를 적용했을 때의 최대치이며, 1년 약정을 선택하거나 선결제 비중을 낮추면 낮아지고 인스턴스 타입·리전에 따라서도 달라집니다.)

바꿀 수 있는 범위가 넓어질수록, 약정 조건이 가벼워질수록 할인율이 낮아지는 사실 하나를 잘 기억해 주세요. 여기에 약정 기간과 결제 방식까지 조합하면 경우의 수가 상당히 많아지기 때문에, 실제 설계는 사용 패턴 데이터를 놓고 정하게 됩니다.

2026년에는 여기에 큰 변화가 하나 생겼습니다. re:Invent 2025에서 발표된 Database Savings Plans입니다. 그동안 SP는 컴퓨팅 영역 중심이었고 데이터베이스는 RI로만 약정할 수 있었는데, 이제 RDS · Aurora · DynamoDB · ElastiCache 등 10개 데이터베이스 서비스가 SP 방식으로 묶입니다. 다만 1년 약정만 가능하고, 최신 세대(Gen 7 이상) 인스턴스만 대상이며, 최대 할인율도 35% 수준으로 RDS Standard RI(최대 69%)보다 낮습니다. 기존 DB RI를 대체하는 게 아니라, DB 구성이 자주 바뀌는 조직을 위한 유연성 옵션이 하나 추가된 것으로 이해하면 됩니다.

RI와 SP 중 뭘 골라야 하는가는, 워크로드마다 답이 달라집니다.

[참고] 약정 설계와 운영을 실제로 어떻게 진행하는지 사례로 보고 싶다면?
👉 AWS 구축부터 운영지원까지! MSP 서비스

약정을 걸기 전에 점검할 2가지

실무에서 가장 자주 나오는 질문은 RI와 SP 중 무엇을 선택할지입니다. 2026년 현재 실무의 답은 양자택일이 아니라 레이어링입니다. 확실한 바닥 사용량(baseline usage)은 Compute SP로 넓게 덮고, 구성이 절대 바뀌지 않는 고정 워크로드는 할인율 높은 RI로 덮고, 변동분만 온디맨드로 남깁니다. AWS가 할인 적용 순서를 자동으로 최적화하기 때문에, 여러 약정을 겹쳐도 충돌하지 않습니다.

최근 60~90일의 '최소 사용량 바닥선'을 확인하셨나요? 

약정 금액은 평균 사용량이 아니라 최소 바닥선 기준으로 잡아야 합니다. 시간대별 사용량 그래프에서 가장 낮은 구간, 새벽에도 항상 돌아가는 수준이 안전한 약정 기준입니다. 실무에서는 이 바닥선의 70~80% 수준부터 약정을 시작하고, 활용률을 확인하며 단계적으로 늘리는 방식이 권장됩니다. 과다 약정은 미사용분이 그대로 낭비로 남습니다.

약정 취소·변경 조건을 확인하셨나요? 

2026년 기준 SP 반환 정책은 생각보다 엄격합니다. 시간당 약정 100달러 이상의 SP는 반환이 불가능하고, 그 미만도 같은 달 내 7일 이내, 연 10회까지만 반환할 수 있습니다. 규모가 큰 약정일수록 사실상 되돌릴 수 없다는 뜻이므로, 처음부터 크게 걸기보다 작게 나눠 거는 편이 안전합니다.

이 두 가지만 점검해도 "약정이 부담스러워 온디맨드 정가를 계속 내는 상태"와 "리스크를 통제하면서 할인을 받는 상태"의 차이가 생깁니다. 인프라는 하나도 바꾸지 않고, 지불 방식만 바꿔서 같은 사용량을 더 낮은 비용으로 운영하는 셈입니다.

마무리 전에, 우리 환경을 한번 점검해 보시기 바랍니다.

• 1년 뒤에도 확실히 켜져 있을 워크로드가 지금 온디맨드 정가로 돌아가고 있지 않나요?
• 최근 60~90일의 시간대별 최소 사용량 바닥선을 확인해 본 적 있나요?
• 이미 구매한 RI/SP가 있다면, 활용률과 커버리지를 정기적으로 보고 있나요?
• 데이터베이스 영역은 RI와 Database Savings Plans 중 어느 쪽이 유리한지 검토해 봤나요?

이 질문에 바로 답하기 어렵다면, 약정을 걸기 전에 사용 패턴 분석부터 시작하는 것이 순서입니다. 약정은 데이터에 기반한 의사결정입니다.

파이브클라우드는 워크로드 사용 패턴 진단부터 RI/SP 약정 포트폴리오 설계, 구매 이후의 활용률·커버리지 모니터링과 갱신 전략 수립까지, 약정 기반 비용 최적화의 전 과정을 함께합니다.

핀옵스(FinOps)란 무엇일까요

핀옵스는 'Finance(재무)'와 'DevOps(개발·운영)'의 합성어로, 조직 내 클라우드 컴퓨팅 인프라의 비용과 비즈니스 가치를 최적화하는 운영 문화이자 프레임워크입니다.

기존의 핀옵스는 AWS, Azure 같은 퍼블릭 클라우드 인프라의 낭비를 찾아내고 비용을 최적화하는 체계로 출발했습니다. 반면 SaaS(서비스형 소프트웨어)는 전통적으로 '1인당 월 얼마'를 내는 정액제 구독 모델이 중심이라, 예산을 예측하고 통제하기가 상대적으로 수월했습니다.

하지만 2026년 현재, 이야기가 조금 달라졌습니다. 2025년 2월 발표된 NASSCOM 보고서에 따르면 전 세계 SaaS 시장 규모는 2026년 3,150억 달러에 달할 것으로 전망되며, 2025년 기업들의 평균 SaaS 지출액은 2억 4,600만 달러에 이릅니다. 엔터프라이즈 기술 지출이 늘어나는 이면에는 새로운 비용 구조가 자리 잡고 있습니다.

정액제에서 종량제로 바뀌는 SaaS 요금제

AI 기능은 호출할 때마다 연산 자원을 씁니다. 그래서 벤더들은 기존 구독료는 그대로 두고, AI 사용량만 별도 단위로 떼어 과금하는 방식을 택하고 있습니다. 따라서 1인당 정액 구독이 차지하는 비중은 줄어들고, 사용량 기반 과금 모델의 비중이 늘어나는 추세입니다.

어도비, 마이크로소프트365, 깃허브 같은 주요 IT 서비스들이 이런 종량제 요소를 속속 도입하고 있습니다. Microsoft Security Copilot이 대표적인 예입니다. Microsoft 365 E5 라이선스 기준으로 유료 사용자 1,000명당 매월 400 SCU(Security Compute Unit)라는 기본 제공 한도가 있는데, 이를 초과하면 1 SCU 당 6달러의 추가 요금이 붙습니다. 어도비는 생성형 AI 기능 파이어플라이에 크레딧을 매깁니다. 전용 파이어플라이 플랜 없이 일반 Creative Cloud를 쓰는 사용자는 월 크레딧이 소진되면 생성이 멈추고, 추가 크레딧을 구매해야 합니다.

가트너는 2030년까지 엔터프라이즈 SaaS 지출의 최소 40%가 사용량이나 성과 기반 모델로 전환될 것으로 내다봤습니다. 통제 장치가 없다면, AI 에이전트의 단순 반복 작업만으로도 예상치 못한 요금이 쌓일 수 있다는 뜻입니다.

[참고] SaaS 라이선스를 실제로 어떻게 할인·정리했는지 사례가 궁금하다면?
👉 어도비 클라우드 할인 라이선스 관리 꿀팁

파악되지 않는 구독: SaaS 스프롤과 섀도우 IT

SaaS 비용을 늘리는 또 다른 원인은 'SaaS 스프롤(SaaS Sprawl)'과 '섀도우 IT(Shadow IT)'입니다. SaaS 스프롤은 조직 내에서 서비스형 소프트웨어의 도입과 사용이 통제되지 않고 확산되는 현상을 말합니다. 부서나 개별 직원이 IT 부서의 통제 없이 법인카드로 필요한 소프트웨어를 직접 결제해 쓰는 경우가 대표적입니다. 섀도우 IT도 비슷하게, 회사 IT 부서의 공식 승인이나 감독 없이 조직 내 부서나 개인이 무단으로 쓰는 하드웨어·소프트웨어·클라우드 서비스를 뜻합니다.

이러한 미사용·저활용 라이선스 비중은 여러 조사에서 25~30% 수준으로 언급됩니다. 다만 이 수치는 SaaS 관리 솔루션을 판매하는 업체들이 낸 조사가 많으므로 참고용으로만 두고, 실측치로 다시 확인해 보시는 편이 정확합니다.

가상 시나리오로 보는 비용 누수

직원 60명 규모 회사가 협업툴, 디자인툴, CRM, AI 코딩 도구를 쓰고 있다고 가정해 보겠습니다.

카드 명세를 모아보니 결제 주체가 네 부서로 나뉘어 있었고, 갱신 월도 제각각이었습니다. 기능이 겹치는 도구가 두 개 있었고, 퇴사자 계정이 정리되지 않은 좌석도 남아 있었습니다.

이 상태에서 먼저 줄어드는 비용은 단가 협상이 아니라 정리에서 나옵니다. 협상은 결제 창구와 갱신 시점을 맞춘 다음 순서입니다.

부서별 중복 툴 도입, 사용량 기반 과금의 무분별한 확대, 숨어있는 AI 추가 요금, 불필요한 상위 등급 업그레이드, 방치된 미사용 라이선스는 눈에 띄지 않는 비용 누수를 만듭니다. 이제 기업들은 AI, SaaS, 클라우드 비용을 각각 단절된 예산으로 다룰 게 아니라, 하나의 통합된 프레임워크 안에서 함께 관리해야 합니다.

[참고] 클라우드 비용이 어디서 새는지 항목별로 더 짚어보고 싶다면?
👉 AWS 비용이 매달 새는 3가지 구조와 절감 포인트

통합 구매 및 비용 관리 전략

실제 절감률은 계약 구조와 관리 수준에 따라 차이가 있지만, 미사용 SaaS 라이선스를 체계적으로 정리하는 것만으로도 비용 메리트는 상당합니다. 가트너가 리더 기업으로 선정한 SaaS 관리 플랫폼 CloudNuro는 SaaS 지출의 23~30%까지 절감할 수 있다고 제시합니다.

지금 확인해 볼 실무 체크포인트 3가지

우리 회사는 얼마나 관리가 되고 있을까요? 아래 세 가지부터 점검해 보시길 권합니다.

• 최근 12개월간 SaaS 결제 건을 부서별·갱신 월별로 정리해 보셨나요? 이 목록이 IT 부서가 파악한 것보다 많다면, 그 차이가 첫 번째 정리 대상입니다.
• 계약서에서 '기본 제공량'과 '초과 단가'를 찾아 확인해 보셨나요? AI 기능이 포함된 서비스는 과금 단위(시간·토큰·크레디트)와 사용량 상한 설정 기능 여부까지 확인해야 합니다.
• 도구별로 최근 30일 로그인 횟수가 0회인 계정을 파악해 보셨나요? 갱신 30일 전에 이 숫자를 근거로 라이선스 사용자 수를 조정하면, 별도 솔루션 없이도 정리가 가능합니다.

SaaS 비용 관리는 결제 구조를 파악하는 일에서 시작됩니다. 결제 창구를 정리하고 갱신 시점을 맞추는 것만으로도 한눈에 파악할 수 있는 범위가 크게 넓어집니다.

파이브클라우드는 SaaS ·클라우드 지출을 하나의 프레임워크로 통합해 진단하고, 통합 구매와 계약 조건 최적화까지 함께 설계합니다. 흩어진 결제 창구부터 정리하고 싶으시다면 지금 상담해 보세요.

AI 사용료가 예측을 벗어나는 이유

지난 5월, 한 기업이 클로드(Claude) 사용료로 월 5억 달러를 청구 받았다는 보도가 나왔습니다. 컨설턴트 한 명이 전한 얘기라 숫자 자체는 그대로 믿을 필요 없지만, 원인은 생각해 볼 만합니다. 조직 차원의 지출 한도나 사용량 통제가 애초에 없었다는 것입니다.

최근엔 한 사용자에게 251억 원이 청구된 사건도 화제였습니다. 앤트로픽은 자동 충전 설정 오류라고 했는데, 사용자는 자동 충전을 켜둔 적이 없다고 했습니다. 청구가 됐지만, 원인은 아직 아무도 모릅니다. 이런 일들이 하나둘 쌓이면서 "우리도 언젠가 저런 청구서를 받을 수 있다"라는 불안이 번지고 있습니다.

기업 5곳 중 4곳이 AI 비용 예측에 실패합니다

늘어나는 AI 비용은 개별 기업의 해프닝을 넘어, 글로벌 IT 인프라 전반의 구조적 문제로 확산되고 있습니다. 더 심각한 건 '비용 예측' 자체가 안 된다는 점인데요. AI 비용 거버넌스 관련 조사에 따르면 전 세계 기업의 85%가 AI 비용을 오차 10% 이내로 예측하지 못하며, 조사 대상 372개 기업 중 25%는 실제 비용이 예측치보다 15% 이상 벌어졌습니다.

빅테크 기업도 예외는 아닙니다. 마이크로소프트는 개발자 1인당 월 500~2,000달러까지 치솟은 AI 코딩 라이선스 비용을 감당하지 못해 내부 사용을 축소했고, 아마존에서는 일부 직원이 사내 리더보드 상위권을 차지하려고 토큰 소비량을 과장한 사실이 적발되기도 했습니다. AI 지출은 더 이상 소액의 실험 비용이 아니라, 기업 손익계산서를 흔드는 자본 지출이자 운영비로 자리 잡았습니다.

[참고] 비슷한 맥락에서 클라우드 비용이 어디서 새는지 궁금하다면?
👉 AWS 비용이 매달 새는 3가지 구조와 절감 포인트

선두 기업들은 이렇게 대응하고 있습니다

무작정 AI 사용을 줄이는 대신, 글로벌 선두 기업들은 기술적 최적화와 거버넌스 체계를 함께 구축하는 쪽을 택하고 있습니다.

스마트 AI 라우팅으로 작업 난이도에 맞는 모델을 자동 배정합니다

모든 작업에 가장 성능 좋은 모델을 무조건 투입하는 건 비효율적입니다. 메타(Meta)를 비롯한 선도 기업들은 작업의 난이도와 문맥을 자동으로 분석해 적합한 모델로 요청을 분배하는 'AI 라우터'를 개발하고 있습니다. 예를 들어 Switchboard AI 같은 모델 라우터는 사용자나 AI 에이전트의 요청 난이도를 평가해 처리할 모델을 결정합니다. 단순 요약이나 데이터 정제, 일상적인 질문은 저렴한 경량 모델로, 고난도 기획이나 복잡한 리팩토링, 고성능 추론이 필요한 작업은 프리미엄 모델로 자동 배정하는 방식입니다. 이 라우팅 전략만 적용해도 전체 토큰 지출 단가를 낮출 수 있습니다.

하네스(Harness) 설계만으로 토큰 소비를 크게 줄입니다

AI 연구 컨설팅사 시스티마(Systima)에 따르면, AI 비용에는 모델 자체보다 '하네스(Harness)' 설정 방식이 더 큰 영향을 미칩니다. 같은 모델을 쓰더라도 어떤 지시문, 어떤 외부 도구, 어떤 작업 분할 방식과 함께 쓰느냐에 따라 요금이 크게 달라진다는 뜻입니다. 업계에서는 이 설정 층을 하네스라고 부르는데, 한 하네스 판매사는 동일 모델에서 하네스 설계만 바꿔도 토큰 소비량 최대 38%, 과금 비용 최대 41%, 실행 시간 최대 44%를 동시에 절감한 사례가 있다고 밝혔습니다.

FinOps 자동화와 표준화로 비용 이상을 실시간 추적합니다

AWS는 최근 'AWS FinOps Agent'를 공개했습니다. 비용이 갑자기 튀는 이상 징후가 발생하면 원인을 추적해 Jira 티켓을 생성하고, Slack으로 담당 개발자에게 즉시 알림을 보내 대응 지연을 최소화하는 방식입니다. 엔지니어링 워크플로 안에서 AI ·클라우드 비용 이상을 자동 추적하는 기능도 추가될 예정입니다. 한편 리눅스 재단은 구글 클라우드, 마이크로소프트, 액센츄어 등의 지지를 받아 'Tokenomics Foundation'을 출범하고, 클라우드 비용 표준 사양인 FOCUS(FinOps Open Cost and Usage Specification)를 확장해 토큰 소비를 실시간으로 가시화하는 표준 프레임워크를 마련하고 있습니다.

[참고] AI 인프라 의존도가 높아질수록 커지는 다른 리스크도 궁금하다면?
👉 클라우드 송환이 답일까? 비용 폭증의 진짜 원인과 해법

전담 핀옵스팀이 없는 기업이 지금 확인해야 할 3가지

대기업처럼 자체 핀옵스(FinOps) 전담팀을 두거나 거대한 라우팅 인프라를 직접 개발하기 어려운 기업이라면, 아래 세 가지부터 확인해 보시길 권합니다.

• AI 사용액을 팀·용도별로 나눠서 볼 수 있나요? 청구서가 한 덩어리로 오면 절감 논의 자체가 시작되기 어렵습니다.
• 자동 충전 설정과 지출 한도가 함께 걸려 있나요? 한도 없는 자동 충전에 재시도 루프까지 겹치면, 청구액은 걷잡을 수 없이 불어납니다.
• 배치·자동화 워크플로에 재시도 횟수 상한과 타임아웃이 걸려 있나요? 사람이 낮 시간에 쓰는 비용보다, 자동화가 밤새 돌며 쓰는 비용이 더 커지기 쉽습니다.

핵심은 '보이느냐, 안 보이느냐'입니다. 지금 우리 회사 AI 비용을 누가 얼마나 쓰는지 보인다면 관리할 수 있지만, 안 보이면 청구서를 받고 나서야 알게 됩니다. 위 체크포인트 중 하나라도 "어, 이거 확인 안 해봤는데" 싶은 항목이 있다면, 오늘 바로 점검해 보시길 권해드립니다.

파이브클라우드는 AI ·클라우드 인프라 전반의 비용 가시성 확보부터 사용량 기반 예산 통제 체계 수립까지 함께 설계합니다. 청구서를 받고 놀라는 대신, 미리 통제할 수 있는 구조를 지금부터 준비해 보세요.

복잡한 데이터 준비(전처리)부터 심층 분석까지, 마우스 드래그 앤 드롭 방식의 쉬운 화면 구성으로 현업 담당자부터 경영진까지 누구나 쉽게 활용할 수 있습니다.
실시간 데이터 연동을 통해 신속하고 정확한 의사결정을 지원하며, 전사적인 데이터 기반 기업 문화(Data Culture) 구축을 위한 강력한 기반을 제공합니다.

혜택 안내

✅ 최대 10% 가격 할인
✅ 전문 컨설턴트의 1:1 무료 맞춤 상담 (고객 환경별 최적의 도입 방안 제안)

안내 사항

✅ 대규모 도입은 별도 문의 부탁드립니다.

약 3주 만에 조치는 해제되었으나, 기업들에게는 잊을 수 없는 메시지를 남겼는데요. 이제는 AI 모델 도입 시 성능과 비용뿐만 아니라 ‘지정학적 리스크’와 ‘업무 연속성(BCP)’도 고려해야 한다는 것입니다.

사건 개요: 국경 없는 인프라와 국적 기반 규제의 충돌

지난 6월 12일, 미국 정부는 국가 안보를 이유로 앤트로픽 최신 모델의 '미국 외 외국 국적자 접근 차단' 지침을 하달했습니다. Fable 5의 보안 우회(Jailbreak) 가능성이 발단이었는데요.

• 정밀 제어의 한계: 글로벌 클라우드 인프라(AWS Bedrock 포함) 특성상 실시간으로 사용자의 국적을 식별하는 것은 불가능
• 전면 중단 사태: 결국 미국 시민을 포함한 전 세계 모든 고객의 서비스가 전면 차단되는 결과 초래
• 시사점: 서비스 발생 18일 만인 6월 30일 규제는 해제되었으나, 국경 없이 작동하는 AI 인프라가 국가 단위의 지정학적 규제와 충돌할 때 시스템 전체가 마비될 수 있음을 증명

소프트웨어를 넘어 전략 자산이 된 AI, 남의 일이 아닙니다

이번 사태는 국내 기업들에게도 직접적인 영향을 미쳤습니다. 앤트로픽의 보안 프로그램 'Project Glasswing'에 참여 중인 삼성전자, SK하이닉스, SK텔레콤 등 주요 기업은 물론, 해외 프런티어 모델을 도입한 국내 기업 대부분이 규제 대상인 '외국 국적자'에 해당하기 때문입니다.

어제까지 문제없이 호출하던 API가 우리 회사의 기술적 오류가 아닌, 지정학적·외교적 사유로 통보 한 번에 끊길 수 있다는 리스크가 현실화된 것입니다.

AI 모델 선택, 이젠 단순한 기술 스택 비교를 넘어 '지정학적 리스크'라는 변수도 살짝 얹어서 고민해 봐야 합니다.

[참고] 기업 데이터 보안 관점의 AI 도입 체크포인트가 궁금하다면?
👉 기업이 꼭 알아야 할 제미나이 보안 팩트 3가지

단순 중단을 넘어선 규제 및 컴플라이언스 위기

문제는 서비스 일시 중단에서 끝나지 않습니다. AI 모델에 대한 통제권을 잃는 순간, 기업의 데이터 거버넌스와 컴플라이언스 체계 전체가 흔들릴 수 있습니다.

• 데이터 국외 이전 및 규제 이슈: 개인정보보호법상 데이터의 국외 이전 시 필요한 별도 고지 및 동의 절차가 복잡해짐
• 산업별 망분리 및 규제: 금융·공공 분야의 망분리 의무나 ISMS-P 등 정보보호 인증을 유지해야 하는 기업이라면, '어느 국가의 어떤 모델로 데이터가 흘러가는지'를 파악하지 못하는 순간 심각한 규제 리스크로 이어짐

이제 AI 도입은 단순한 편의성 확보를 넘어 "이 모델이 언제든 멈출 수 있는가?", "우리 데이터가 어디로 흘러 어떤 규제에 걸리는가?"까지 함께 관리해야 하는 경영 리스크의 영역이 되었습니다.

[참고] 외부 서비스 리스크 관리법을 더 알아보고 싶다면
👉 CI/CD 공급망 공격, 우리 회사 파이프라인은 안전한가요?

IT 리더가 즉시 점검해야 할 5가지 핵심 항목

성공적인 AI 활용을 위해서는 어떤 상황에서도 업무가 멈추지 않도록 만드는  '회복탄력성(Resilience)' 입니다. 이를 위해 IT 리더는 다음 5가지 항목을 즉시 점검해야 합니다.

1. API 종속성 전수 조사: 내부 시스템, 영업 플랫폼, 코드 관리 도구 등에서 호출 중인 해외 AI 모델 현황 파악
2. 멀티 모델 Failover 아키텍처 구축: 주력 모델 장애 발생 시 대체 모델로 즉시 전환되는 자동화 경로 확보
3. 데이터 유출 방지 및 국외 이전 통제: 핵심 기밀 및 개인정보가 외부 모델로 직접 유출되지 않는 파이프라인 구성
4. 공급업체 계약 및 SLA 점검: 규제 및 차단 발생 시 비상 로직 적용 여부 및 비용 발생 조건 확인
5. 거버넌스 및 대응 책임 명확화: 모델 변경 및 국가별 규제 대응을 총괄할 내부 의사결정 프로세스 수립

지속 가능한 AI 인프라를 구축하려면

AI 인프라의 본질은 특정 단일 공급업체에 얽매이지 않고, 데이터 통제권을 유지하면서 비즈니스 연속성을 확보하는 데 있습니다. 동일한 프런티어 모델을 쓰더라도 아키텍처의 이중화와 거버넌스의 밀도에 따라 기업의 안정성은 완전히 달라집니다.

파이브클라우드는 AI·클라우드 인프라 전반의 리스크 진단부터 이중화 아키텍처 설계, 데이터 거버넌스 체계 수립까지 맞춤형 솔루션을 제공합니다. 지정학적 리스크에 흔들리지 않는 견고한 AI 인프라를 마련해 보세요.

핵심부터 짚어보자면, MSP는 단순한 '운영 대행업체'가 아닙니다. 도입 전 아키텍처 설계부터 구축, 운영, 나아가 비용 최적화까지 클라우드 여정 전반을 주도하는 파트너입니다. 이 글에서는 MSP와 Managed Services의 실질적 역할을 정의하고, 파이브클라우드의 서비스 및 비용 구조를 상세히 안내합니다.

클라우드 관리 서비스, 무엇을 관리해주는 걸까요?

MSP(Managed Service Provider)의 역할은 CSP(Cloud Service Provider)와의 관계를 통해 명확히 이해할 수 있습니다.

• CSP(AWS, GCP 등): 건물을 지어 임대하는 사업자입니다. 튼튼한 인프라와 설비를 제공하지만, 기업의 환경에 맞춘 내부 설계나 실무적인 시설 관리를 지원하지는 않습니다.
• MSP: 입주한 공간을 기업에 맞게 설계하고 실무를 대행하는 운영 주체입니다. 이들이 제공하는 설계, 구축, 장애 대응 등의 실무 전반을 'Managed Services'라고 부릅니다.

CSP와 직접 계약할 경우 아키텍처 설계, 보안 구성, 장애 대응, 환율 관리 등 모든 리스크를 내부 인력이 감당해야 합니다. MSP는 CSP와 고객 사이에서 기술적·계약적 '통역자' 역할을 수행하며, 파트너 할인, 원화 청구, 한국어 기술 지원 등 실질적인 이점을 제공합니다. 같은 클라우드를 쓰더라도 어떤 경로로 계약하느냐에 따라 받는 게 달라지는 이유입니다.

[참고] MSP가 실제로 어떻게 도입 과정을 함께하는지 사례로 보고 싶다면? 
👉 AWS 구축부터 운영지원까지! MSP 서비스

Managed Services의 5대 핵심 영역 

업계에서 통용되는 Managed Services는 기업의 필요에 따라 크게 다섯 가지 영역으로 나뉩니다.

• 구축·배포·전환: 리소스 프로비저닝, IaC 기반 구축, CI/CD 구축, 마이그레이션
• 전문 기술운영: OS, 미들웨어, DB, 애플리케이션 운영
• 최적화: 비용 최적화(FinOps), 성능 향상, 아키텍처 개선, 리포트 제공
• 모니터링·장애대응: 알람 구성, 장애 감지 및 신속 대응
• 운영지원·서비스관리: 기술 문의 처리, 운영 가이드 제공, 백업 및 복구

이 다섯 영역을 방치할 경우, 반드시 예기치 못한 비용 낭비와 장애 리스크로 이어지게 됩니다.

[참고] 클라우드 비용이 어디서 새는지 항목별로 더 짚어보고 싶다면?
👉 AWS 비용이 매달 새는 3가지 구조와 절감 포인트

파이브클라우드의 2가지 Managed Services 모델 

파이브클라우드는 클라우드 전담 인력이 부족한 스타트업 및 SMB 고객의 니즈에 맞춰 두 가지 상품을 제공합니다.

• 프로젝트형 (1회성 비용): 새로운 인프라 도입 시 아키텍처 설계부터 구축, 마이그레이션까지 진행하며, 목표 환경이 완성되면 종료됩니다.
• 운영형/구독형 (월 사용량 연동): 비용 최적화, 장애 모니터링, 일상적인 이슈 처리 등 운영 부담이 큰 인프라 계층 관리에 집중합니다. 사용량이 적은 초기 기업을 위한 최소 비용 구간이 마련되어 유연한 확장이 가능합니다.

상품 설계 시 개발팀이 서비스 로직과 밀접한 OS 및 미들웨어 내부를 직접 핸들링하는 스타트업과 SMB의 특성을 고려했습니다. 파이브클라우드는 개발팀의 자율적인 배포 속도를 저해하지 않도록 인프라 계층이라는 기술 전문 영역에만 집중하는 운영 모델을 지향합니다.

이러한 합리성은 비용 구조에도 반영됩니다. 리소스가 집중되는 프로젝트형은 기간과 투입 인력에 따른 단발성 비용으로 완료되며, 인프라 규모에 비례해 관리 리소스가 늘어나는 운영형(구독형)은 월 사용량에 연동됩니다. 특히 초기 단계 기업을 위한 최소 비용 구간을 운영하여, 비즈니스 성장에 발맞춰 유연하게 관리 범위를 넓혀갈 수 있도록 설계했습니다.

설계와 관리가 일체화될 때 비로소 완성되는 클라우드 

프로젝트형과 운영형은 각각 단독으로도 훌륭한 대안이지만, 두 상품이 결합될 때 시너지는 극대화됩니다. 안정적인 운영의 근간은 결국 정교한 설계에서 비롯되기 때문이죠. 타사가 구축한 인프라를 운영만 대행할 경우, 초기 히스토리 파악에 리소스가 듭니다. 반면 파이브클라우드가 설계부터 전담하면 탐색 과정 없이 즉시 운영에 착수합니다. 구조에 대한 깊은 이해를 바탕으로 장애 대응 속도와 최적화의 정밀도에서 확연한 차이를 경험할 수 있습니다.

"설계 결함인가, 운영 미숙인가"를 따지는 책임 소재의 공백은 구축과 운영의 주체가 다를 때 빈번히 발생합니다. 처음부터 단일 팀이 전 과정을 전담한다면 이러한 리스크 자체가 원천 차단됩니다.

이러한 가치를 전달하기 위해 파이브클라우드는 운영형(구독형) 계약 시 신규 구축 프로젝트 비용을 면제해 드립니다. 단발성 구축 수익에 집중하기보다, 최적화된 인프라 위에서 고객사와 함께 장기적인 성장을 도모하는 쪽에 더 큰 가치를 두기 때문이죠.

MSP의 본질을 정확히 파악하면 클라우드 도입은 단순히 '서버 임대'를 넘어 실질적인 '전문 운영 역량 이식'의 과정이 됩니다. 동일한 리소스를 쓰더라도 설계와 관리의 밀도에 따라 인프라의 가성비와 안정성은 완전히 달라집니다.

지금 바로 우리 조직의 IT 환경을 객관적으로 점검해 보세요.

• 인프라만을 전담하여 관리하는 내부 전문 인력이 부재한가요?
• 예기치 못한 장애 발생 시 즉각적인 인지와 조치가 가능한 체계가 없나요?
• 매달 청구되는 클라우드 비용의 세부 명세와 낭비 요인을 파악하기 어렵나요?
• 현재 아키텍처가 철저한 기획의 결과물인가요, 아니면 관성적으로 확장된 결과물인가요?

위 질문들 중 하나라도 명확한 답을 내리기 어렵다면, 바로 그 지점이 파이브클라우드의 전문적인 가이드가 필요한 시점입니다.

파이브클라우드는 워크로드 진단과 아키텍처 설계, 마이그레이션부터 사용량 기반의 운영형 상품까지 클라우드 여정의 모든 단계를 밀착 지원합니다. AWS, GCP, Alibaba Cloud의 공식 파트너로서 제공하는 계약 혜택은 물론, 운영형 계약 시 초기 구축 비용을 지원하는 합리적인 구조로 클라우드 경쟁력을 확보해 드립니다.

• 파이브클라우드·하이픈디자인 성장세…신사업 매출 전년 대비 94% 증가
• AX 컨설팅·마켓플레이스 확대 추진…‘오피스 플랫폼’ 전략 강화

공유오피스 시장이 성숙 단계에 접어들면서 관련 기업들도 사업 다각화에 속도를 내고 있다. 단순 공간 임대를 넘어 IT 서비스와 인테리어, 업무 운영 솔루션까지 결합한 ‘통합 오피스 플랫폼’ 경쟁이 본격화되는 분위기다.

패스트파이브는 종합 IT 솔루션 브랜드 ‘파이브클라우드’와 오피스 인테리어 브랜드 ‘하이픈디자인’이 지난해 총 310억원 규모 매출을 기록했다고 28일 밝혔다. 회사에 따르면 신사업 부문 전체 매출은 전년 대비 약 94% 성장했다. 사업별로는 파이브클라우드가 2024년 100억원에서 2025년 180억원으로 약 80% 성장했으며, 하이픈디자인은 같은 기간 60억원에서 130억원으로 늘었다.

패스트파이브는 공간 운영 과정에서 축적한 데이터와 고객 경험을 기반으로 IT 서비스와 오피스 구축 사업을 확장해 왔다. 회사 측은 각 사업 부문 전문성과 오피스 운영 노하우를 결합한 점이 성장 배경이라고 설명했다.

파이브클라우드는 스타트업과 중소·중견기업(SMB)을 대상으로 한 ‘올인원 IT 파트너’ 모델을 강화하고 있다. AWS 한국파트너리그(KPPL) 수상과 구글 워크스페이스 프리미어 파트너 자격 획득 등을 통해 기술 신뢰도를 확보했으며, AWS·구글클라우드·네이버클라우드·NHN클라우드에 이어 화웨이·알리바바까지 파트너십을 확대했다.

현재 집닥과 두들린, 레몬베이스, 아이나비, 퀸텟시스템즈 등 기업 고객들이 서비스를 이용 중이며, 누적 고객사는 285개사 수준이다.

“공간 운영 데이터 활용”…인테리어·AX 사업 확대

하이픈디자인 역시 단순 시공보다 업무 환경과 브랜드 특성을 반영한 공간 설계 역량을 강화하며 성장세를 이어가고 있다.

패스트파이브는 다수의 오피스를 직접 운영하며 축적한 사용자 데이터와 업무 공간 설계 경험을 차별화 요소로 내세우고 있다. 지난해 인테리어 문의 건수는 전년 대비 두 배 이상 증가했다. 주요 프로젝트로는 카카오게임즈 오피스 구축과 코오롱인베스트먼트 사무공간 설계 등이 있다. 지속가능 자재 적용과 VC 업무 특성을 반영한 공간 설계 등이 프로젝트에 반영됐다는 설명이다.

패스트파이브는 올해 AX(AI Transformation) 컨설팅과 마켓플레이스 사업 확대에도 나설 계획이다. 파이브클라우드는 스타트업 맞춤형 AX 컨설팅을 강화하고, 다양한 솔루션을 한 번에 비교·구매할 수 있는 마켓플레이스 구축을 추진한다. 하이픈디자인은 중대형 오피스 시장 공략과 임대인 파트너십 확대에 집중할 예정이다.

김우경 패스트파이브 인프라사업본부 본부장은 “고객 업무 환경에 맞춰 서비스를 다시 설계하는 전략이 IT와 인테리어 시장에서도 성과로 이어지고 있다”며 “AX 컨설팅과 전략적 워크플레이스 사업을 더욱 강화해 나갈 계획”이라고 말했다.

김대일 패스트파이브 대표는 “공유오피스를 넘어 기업 운영 전반을 지원하는 오피스 플랫폼 기업으로 진화하고 있다”며 “시장 변화에 맞춘 서비스를 지속 확대해 나가겠다”고 밝혔다.

기사 보기

"AI를 도입해야 한다"는 건 알겠는데, 막상 우리 회사는 어디서부터 손대야 할지 막막하지 않으셨나요?

지난 5월 20일과 21일 코엑스에서 열린 AWS Summit Seoul 2026이 그 답의 힌트를 보여줬습니다. 12회째를 맞은 이번 행사에는 18개 트랙, 120개 이상의 세션, 60개 이상의 파트너사가 참여했고, 2만 5천 명 이상이 다녀갔습니다.

행사 전반을 관통한 키워드는 에이전틱 AI였습니다. 흥미로운 점은 같은 기술을 두고도 산업마다 적용 방식이 전혀 달랐다는 것입니다. 뷰티는 고객 접점에서, 미디어는 콘텐츠 제작에서, 플랫폼은 운영 자동화에서 출발했거든요. 이 글에서는 공개된 산업별 사례 4가지를 정리하고, "우리 산업은 어디부터 시작해야 하는가"를 점검하는 관점을 함께 다룹니다.

1. 산업마다 출발점이 달랐습니다 

함기호 AWS 코리아 대표는 기조연설에서 AI 주도 개발, 에이전틱 AI, 피지컬 AI 세 가지 방향으로 혁신을 확장하겠다는 전략을 밝혔습니다.

그런데 행사장을 둘러보면 "에이전틱 AI를 도입하자"는 일률적인 메시지가 아니었습니다. 각 산업이 자기 비즈니스에서 임팩트가 큰 영역부터 AI를 붙이고 있었고, 그 진입점이 산업마다 달랐습니다.

• 뷰티·리테일 → 고객 접점 (개인화 진단, 추천) 
• 미디어 → 콘텐츠 제작 자동화 (편집, 분석)
• 플랫폼·제조 → 운영 자동화 (장애 대응, 모니터링)
• 데이터 중심 서비스 → 데이터 파이프라인 (실시간 분석, 마이그레이션)

같은 Amazon Bedrock, 같은 AgentCore를 쓰더라도 어디에 붙이느냐에 따라 결과물이 완전히 달라졌습니다. 행사장에서 가장 자주 들린 질문도 "이 기술 어떻게 만들었나요"가 아니라 "우리 산업에서는 어디부터 시작하면 좋을까요"였습니다.

AI 도입을 고민하는 실무자가 직면하는 진짜 문제는 기술 선택이 아니라 진입점 선택입니다.

2. 4개 산업, 4가지 적용 방식 

각 산업이 실제로 어떻게 다르게 적용했는지 사례별로 살펴보겠습니다. 

뷰티) 아모레퍼시픽: 고객 접점의 AI 

아모레퍼시픽은 AWS의 생성형·에이전틱 AI 플랫폼인 Amazon Bedrock AgentCore를 접목해 AI 피부진단, 피부톤 진단, 두피·헤어 진단, 퍼스널 컬러 진단 서비스를 제공했습니다. 4가지 진단을 하나의 흐름으로 연결한 통합형 뷰티 테크 경험입니다. 고객이 매장에서 마주하는 첫 접점 자체를 AI로 바꾼 사례입니다. 

미디어) KBS: 콘텐츠 제작의 자동화 

KBS의 VVERTIGO는 AWS Inferentia 기반 AI를 활용해 단 1대의 8K 카메라만으로 인물별 자동 추적과 버티컬 영상 제작을 지원합니다. ALIVE는 AWS Elemental과 Amazon Bedrock 기반 AI로 실시간 방송 영상 분석, 하이라이트·자막 생성, 멀티모달 아카이브 검색을 제공하고요. 사람의 손이 가장 많이 들어가던 영상 편집·분석 영역을 자동화한 경우입니다.

운영) 삼성 어카운트: 자율 운영 에이전트

가장 인상적이었던 운영 사례입니다. 함기호 대표는 "전 세계 21억 명 이상이 사용하는 삼성 어카운트 플랫폼에 자율 클라우드 운영 에이전트를 구축해 장애 복구 시간을 90% 이상 단축했으며, 10분 내 장애 감지를 목표로 운영하고 있다"고 말했습니다. 21억 사용자 규모의 운영 부담을 AI 에이전트가 분담하는 구조입니다. 

데이터·마이그레이션) 놀유니버스, 리멤버앤컴퍼니

국내 스타트업 놀유니버스는 AWS Transform을 도입해 150만 줄에 달하는 레거시 코드를 단 10시간 만에 전환하고, 개발 생산성을 3배 끌어올리면서 비용은 50% 절감했습니다. 리멤버앤컴퍼니는 AWS의 신규 오픈 데이터 아키텍처인 S3 Tables를 기반으로 데이터 동기화 주기를 하루 단위에서 10분 단위로 단축했고요.

같은 AWS 서비스를 쓰는데 산업마다 결과물의 모양은 다 다릅니다. 뷰티는 매장 체험으로, 미디어는 편집 워크플로우로, 플랫폼은 운영 안정성으로, 스타트업은 개발 속도로 가치를 전환했습니다. 

[참고] AI 사례마다 등장한 Amazon Bedrock이 정확히 무엇인지 먼저 알고 싶다면?
👉 AWS GenAI 서비스 베드록(Bedrock)을 다룬 콘텐츠를 함께 보세요!

3. 우리 산업은 어디부터 시작해야 할까요 

위 4개 사례를 정리하면 AI 적용의 진입점은 크게 네 가지로 나뉩니다. 우리 회사가 어디에 가까운지 살펴보시고, AI 도입의 출발점으로 삼아보세요!

고객 접점이 강한 비즈니스 

• 해당 업종: 리테일, 뷰티, 커머스, 금융 상담, 헬스케어 
• 첫 도입 영역: 개인화 진단·추천, 상담 에이전트 
• 점검 사항: 고객 데이터 통합 수준, 개인정보 처리 동의 구조, 응답 품질 검증 체계 

콘텐츠·창작이 핵심인 비즈니스

• 해당 업종: 미디어, 게임, 마케팅, 교육
• 첫 도입 영역: 콘텐츠 제작 자동화, 아카이브 분석, 자동 편집
• 점검 사항: 원본 데이터 저작권, AI 생성물 표시 의무 대응, 휴먼 리뷰 단계

대규모 운영이 부담인 비즈니스

• 해당 업종: 플랫폼, 통신, 대규모 SaaS, 제조 공정
• 첫 도입 영역: 자율 운영 에이전트, 장애 감지·복구 자동화
• 점검 사항: 관측성 데이터 정합성, 에이전트 행동 권한 범위, 자동화 단계 정의

데이터·레거시 부채가 큰 비즈니스

• 해당 업종: 금융, 공공, 제조 ERP, 오래된 SaaS
• 첫 도입 영역: 레거시 전환, 실시간 데이터 파이프라인
• 점검 사항: 마이그레이션 우선순위, 데이터 거버넌스, 전환 비용 시뮬레이션

혹시 아직 우리 회사의 출발점이 어디인지 감이 잡히지 않는다면, 아래 네 가지 질문에 답해 보세요. 

• 우리 비즈니스의 가장 큰 병목은 고객 접점, 콘텐츠 제작, 운영 부담, 데이터 처리 중 어디인가요? 
• 그 영역에서 사람의 손이 가장 많이 들어가는 작업은 무엇인가요? 
• 그 작업에 필요한 데이터는 이미 클라우드에 정돈되어 있나요? 
• AI 도입 후 결과물을 검증할 수 있는 사람과 프로세스가 있나요? 

진입점을 잘못 잡으면 아무리 좋은 기술을 써도 효과가 나지 않습니다. AWS Summit Seoul 2026이 보여준 핵심도 "어떤 기술이 등장했는가"가 아니라 "산업마다 다른 방식으로 적용하고 있다"는 점이었습니다.

[참고] 우리 업무에 맞는 AI 에이전트를 어떻게 골라야 할지 막막하다면? 
👉 AI 에이전트 시대, 업무에 맞는 AI를 선택하는 방법을 참고해 보세요! 

우리 산업의 진입점을 정확히 찾는 것이 AI 도입 성공의 절반입니다. 문제는 그 진입점을 고르고, 거기에 맞는 데이터와 아키텍처를 준비하는 일이 생각보다 까다롭다는 점이죠.

파이브클라우드는 산업별 특성에 맞는 AI 도입 진입점 진단부터 Amazon Bedrock AgentCore 기반 에이전트 구축, AWS Transform을 활용한 레거시 마이그레이션까지 전 과정을 함께 설계합니다. 우리 회사에 맞는 첫걸음을 같이 찾아 드립니다.

트래픽은 지난달과 크게 다르지 않은데 금액은 예상의 두세 배입니다. 게다가 AI 워크로드까지 본격적으로 돌리기 시작하면 비용 그래프는 천장을 뚫을 기세죠. 이런 답답함을 겪는 곳이 우리 회사만은 아닙니다.

최근 글로벌 CIO의 80% 이상이 클라우드 송환(Cloud Repatriation)을 검토하고 있다는 조사 결과가 나왔습니다. 일부 기업은 이미 워크로드를 온프레미스로 되돌리기 시작했고요. 그렇다면 정답은 다시 온프레미스일까요? 결론부터 말씀드리면, 아닙니다. 송환 트렌드를 자세히 들여다보면 전혀 다른 이야기가 보이거든요.

클라우드 송환(Cloud Repatriation)이란 무엇인가요?

클라우드 송환은 퍼블릭 클라우드에 올렸던 워크로드를 다시 온프레미스나 프라이빗 환경으로 되돌리는 움직임을 말합니다. "클라우드로 옮기면 비용이 준다"는 기대와 달리 청구서가 계속 불어나자, 차라리 인프라를 직접 들고 있겠다는 판단이 늘어난 것입니다.

수치만 보면 "역시 클라우드는 비싸다"는 결론으로 이어지기 쉽습니다. 하지만 송환을 검토하는 기업들의 공통점을 들여다보면, 진짜 문제는 전혀 다른 곳에 있습니다. 핵심 질문은 '클라우드를 떠날 것인가'가 아니라, '클라우드를 제대로 쓰고 있는가입니다.

1. 비용 폭증의 진짜 원인은 클라우드가 아닙니다 

딜로이트의 2026년 테크 트렌드 보고서에 따르면, 일부 글로벌 기업은 매월 클라우드 요금이 수천만 달러에 달한다고 보고합니다. 클라우드 분석가 데이비드 린티컴은 실제 클라우드 비용이 기업이 예상했던 것보다 평균 2.5배 더 많이 발생한다고 분석했습니다.

문제의 본질은 '클라우드를 어떻게 쓰고 있는가'입니다. 비용이 폭증한 기업들에게서는 공통적으로 발견되는 패턴이 있습니다.

• 레거시 애플리케이션을 그대로 들어 옮기는 '리프트 앤 시프트' 방식만 사용 
• 사용하지 않는 리소스를 끄지 않고 24시간 가동 
• 워크로드 특성을 고려하지 않고 모든 것을 퍼블릭 클라우드에 배치 
• 비용 모니터링 체계 부재로 어디서 돈이 새는지 추적 불가 
• AI·GPU 워크로드를 비용 검토 없이 퍼블릭 클라우드에 그대로 운영 

특히 마지막 항목이 결정적입니다. AI 워크로드는 컴퓨팅과 데이터 자원을 막대하게 소비하는데, 비용 구조를 따져보지 않고 퍼블릭 클라우드에 올리면 전체 인프라 비용에서 클라우드가 차지하는 비중이 60~70%를 넘는 경우가 많습니다.

즉, 송환을 검토하는 기업이 진짜로 마주한 문제는 클라우드 자체의 한계가 아니라 클라우드를 잘못 사용한 결과입니다. 운영 방식을 바꾸지 않은 채 환경만 되돌리면, 방향만 반대인 같은 실수를 반복하게 됩니다.

[참고] 클라우드 비용이 어디서 새는지 항목별로 짚어보고 싶다면? 
👉 AWS 비용이 매달 새는 3가지 구조와 절감 포인트 콘텐츠를 함께 보세요!

 2. '어디로'가 아니라 '어떻게'가 정답입니다

송환을 고민 중이라면, 결정 전에 한 가지 질문을 먼저 던져봐야 합니다.

우리는 클라우드를 제대로 설계하고 운영했는가?

같은 인프라라도 어떻게 설계하고 운영하느냐에 따라 비용은 2배, 3배까지 차이 납니다. 제대로 된 클라우드 운영은 아래 세 가지 축으로 구성됩니다.

워크로드 특성에 맞는 배치

모든 워크로드를 한 환경에 몰아넣지 않고, 성격에 맞는 자리를 찾아주는 방식입니다.

• 365일 일정한 트래픽: 온프레미스 또는 장기 예약 인스턴스
• 변동성이 큰 트래픽: 퍼블릭 클라우드 오토스케일링
• 데이터 주권이 필요한 워크로드: 프라이빗 또는 하이브리드
• AI 학습·추론: 워크로드 패턴별로 비용과 성능을 따져 최적 환경 선택

FinOps 기반 비용 관리

비용을 '쓰고 나서 확인하는' 구조에서 '쓰면서 통제하는' 구조로 바꾸는 작업입니다.

• 자원 태깅 정책으로 비용 가시성 확보
• 어느 팀이 얼마를 쓰는지 명확히 하는 책임 기반 리소스 구조 설계
• 비용 모니터링 → 최적화 → 자동화로 이어지는 3단 체계 정착

멀티·하이브리드 클라우드 표준화

• CSP별 강점을 살린 전략적 워크로드 분산
• 여러 환경을 단일 운영 관점에서 통합 관리
• 자동화된 거버넌스 도구로 정책 일관성 유지

핵심은 "퍼블릭이냐 온프레미스냐"의 양자택일이 아니라는 점입니다. 트래픽이 안정적인 코어 시스템은 온프레미스에, 유연성이 필요한 서비스는 퍼블릭 클라우드에, AI 워크로드는 비용과 성능을 따져 최적의 환경에 배치하는 하이브리드 구조가 현실적인 답입니다.

문제는 이 설계를 처음부터 혼자 하기가 어렵다는 점인데요. 그래서 워크로드 진단부터 아키텍처 설계, FinOps 운영까지 전체 그림을 함께 그려줄 MSP 파트너의 역할이 그 어느 때보다 중요해졌습니다. 클라우드는 도입보다 운영이 훨씬 큰 비중을 차지하는 영역이기 때문입니다.

[참고] 2026년 인프라가 어디로 향하는지 큰 그림을 먼저 보고 싶다면? 
👉 2026년 디지털 인프라 핵심 트렌드 5가지를 함께 보세요!

3. 송환이 아니라 재설계가 만드는 변화

클라우드를 제대로 재설계한 기업들이 실제로 어떤 변화를 경험하는지 정리해 보겠습니다.

Before 송환을 고민하던 시점

• 매달 예상의 2~3배 청구서, 어디서 비용이 새는지 추적 불가 
• AI 워크로드 비용이 전체의 절반 이상을 차지 
• 사용하지 않는 리소스가 24시간 그대로 가동
• 인프라팀은 "비용 줄여라", 개발팀은 "리소스 늘려달라"로 끝없는 갈등 
• "차라리 다시 온프레미스로 가자"는 의견이 회의마다 등장 

After 워크로드 재설계와 FinOps 도입 후

• 어떤 서비스가 얼마를 쓰는지 실시간으로 파악하는 비용 가시성 확보 
• 워크로드별 최적 배치로 인프라 비용 평균 30~40% 절감 
• 안정적 워크로드는 온프레미스·예약 인스턴스, 변동성 큰 워크로드는 퍼블릭 클라우드 
• 인프라팀과 개발팀이 같은 데이터를 보고 합리적으로 의사결정 
• 송환 논의는 자연스럽게 사라지고, 비즈니스 확장에 집중 

이 변화의 핵심은 도구가 아니라 체계입니다. 비용 절감 툴 하나를 도입하는 게 아니라, 클라우드를 운영하는 방식 자체를 바꾸는 작업이죠. 그 결과 비용 효율(불필요한 리소스 차단), 운영 효율(자동화 거버넌스로 수동 작업 최소화), 확장성(성장에 맞춰 유연하게 조정), 안정성(단일 환경 의존성 제거)이 함께 따라옵니다.

송환을 검토하는 진짜 이유가 비용이라면, 답은 "어디로 옮길 것인가"가 아니라 "어떻게 운영할 것인가"입니다. 같은 클라우드라도 누가 어떻게 설계하고 운영하느냐에 따라 결과는 완전히 달라집니다.

지금 매달 청구서를 보며 송환을 고민하고 있다면, 그 결정을 내리기 전에 세 가지만 점검해 보세요.

우리 클라우드 환경은 제대로 설계되어 있나요?

워크로드는 적절한 곳에 배치되어 있나요?

비용 가시성은 확보되어 있나요?

파이브클라우드는 워크로드 진단부터 비용 최적화, 하이브리드 아키텍처 재설계까지 클라우드 운영의 전체 그림을 함께 설계합니다. 송환이라는 큰 결정을 내리기 전에, 지금의 환경부터 다시 들여다보는 일이 먼저입니다.

반복 작업의 상당 부분을 이제 제미나이(Gemini)에게 말로 시킬 수 있습니다. 2026년 들어 구글이 워크스페이스 전반에 제미나이를 탑재하면서, 시트는 '함수를 잘 알아야 했던 도구'에서 '설명할 줄 알면 누구나 빠른 도구'로 바뀌었거든요.

우리 회사 업무에 바로 적용할 수 있는 활용법 세 가지와, 사용 가능한 플랜을 정리해 드리겠습니다.

구글 시트의 제미나이, 무엇이 달라졌나요?

예전의 시트 작업은 함수와 친한 사람이 빨랐습니다. VLOOKUP, INDEX/MATCH와 같은 함수 외우고 있어야 했고, 복잡한 정리를 해야할 때면 시간을 많이 들일 수밖에 없었습니다.

2026년 3월부터 적용된 제미나이 인 시트(Gemini in Sheets), 그리고 4월 '워크스페이스 인텔리전스' 업데이트가 된 이후 이제 우리는 함수를 외우고 있지 않아도 일을 잘할 수 있게 됐습니다.

무엇을 하고 싶은지 자연어로 설명하면, 제미나이가 표 구성부터 데이터 정리, 시각화까지 여러 단계를 알아서 처리합니다. 핵심은 작업의 출발점이 '함수'에서 '대화'로 옮겨갔다는 점입니다.

기능을 외워야 했던 일이 설명하면 되는 일로 바뀌면, 실무자 모두의 생산성이 올라가게 되죠. 우리 회사에 바로 적용할 수 있는 활용법 세 가지를 살펴보겠습니다.

1. 표 짜는 데 1시간? 이제 설명 한 줄이면 됩니다 

제미나이로 생성한 이미지

시트를 열고 어떻게 작업해야 할지 막막함을 덜 수 있습니다.

담당자, 진행 상황, 마감 기한을 포함한 신규 프로젝트 일정표를 만들어줘

이런 식으로 원하는 결과를 문장으로 입력하면, 제미나이가 실무에 바로 쓸 수 있는 표 구조와 샘플 데이터를 만들어 줍니다. 단순한 일정표를 넘어 우리 회사 재무 현황 요약부터 복잡한 프로젝트 트래커까지, 여러 단계를 묶어 한 번에 구성해 주죠. 파일과 메일, 채팅, 웹에 흩어진 정보를 끌어와 표로 정리하는 것도 가능합니다. 데이터를 어디서 가져와 어떻게 배치할지 직접 고민해야 했던 일을, 이제 '무엇이 필요한지' 설명하는 일로 바꿀 수 있습니다.

2. 반복적인 데이터 정리, 제미나이가 대신합니다 이미지

제미나이로 생성한 이미지

수천 개의 고객 리뷰 분류, 주소 정제, 카테고리 태깅. 사람 손이 가장 많이 들어가던 작업이 실무자들을 번거롭게 만들곤 합니다.

내가 첫 줄에 쓴 예시를 보고, 아랫줄의 고객 리뷰를 긍정·부정·중립으로 분류해 줘.

Fill with Gemini는 이 부분을 자동화합니다. 첫 칸에 예시를 한두 개만 채워주면, 제미나이가 패턴을 읽고 나머지 칸을 채웁니다. 구글에 따르면 100칸 기준 수작업 대비 약 9배 빠르게 처리되고요. 이미 한 칸 이상 채워진 열은 끌어내리는 것만으로도 표 맥락에 맞춰 나머지가 채워집니다. 여기에 개선된 스마트 채우기(Enhanced Smart Fill)가 더해지면, 비어 있는 두 열 사이의 관계를 AI가 알아서 파악해 남은 값을 예측합니다. 복합적인 문장 맥락까지 읽어내기 때문에, 함수로는 까다롭던 텍스트 정리도 오차를 줄이며 끝낼 수 있습니다.

3. 코딩 없이 반복 업무를 자동화합니다

제미나이로 생성한 이미지

매주 월요일 아침 매출 보고서를 정리해 메일로 보내줘.

이런 정기 업무도 자연어로 설명하면 자동화 흐름으로 만들 수 있습니다. 워크스페이스의 자동화 도구인 워크스페이스 스튜디오(Workspace Studio)가 조건을 받아 백그라운드에서 작업을 구성하기 때문에, 개발자의 도움 없이도 우리 팀만의 자동화 흐름을 만들고 공유할 수 있죠.

다만 이 자동화 기능은 기본 플랜이 아니라 별도 AI 확장 옵션에 포함됩니다. 어디까지 기본으로 쓸 수 있고 무엇이 추가 옵션인지는 아래에서 짚어보겠습니다.

어떤 플랜부터 쓸 수 있나요? 

구글 워크스페이스 플랜 구성은 수시로 바뀝니다. 아래는 2026년 6월 기준이에요.

표 작성, Fill with Gemini, 스마트 채우기, 그리고 워크스페이스 스튜디오 자동화까지 핵심 기능 대부분은 비즈니스 스탠다드(Business Standard) 이상 플랜에 추가 비용 없이 포함됩니다.

과거 'Gemini for Workspace'라는 별도 부가 상품을 붙여야 했던 구조가 정리되면서, 이제는 플랜 안에 기본 탑재되는 형태로 바뀌었거든요.

그럼 유료 옵션은 언제 필요할까요? AI를 매일 대량으로 쓰는 팀이라면 AI 확장 옵션(AI Expanded Access)을 고려할 수 있습니다. 기능을 새로 열어주는 게 아니라, 워크스페이스 스튜디오 자동화 실행 한도를 높이고 고용량 이미지·영상 생성 같은 고급 기능을 더해주는 상향 옵션이죠.

결국 답은 우리 회사 사용량에 달려 있습니다. 지금 플랜으로 충분한지, 한도가 부족한지부터 우리 회사의 요금제 플랜을 확인해 보세요!

한 가지 더, 보안도 짚어둘 만합니다. 개인용 AI와 달리 워크스페이스 기업용 에디션은 우리 회사 데이터가 AI 학습에 사용되지 않습니다. 생산성은 높이면서 데이터 통제권은 지킬 수 있다는 점이, 업무에 AI를 들일 때 의사결정자가 가장 먼저 확인하는 조건이죠.

[참고] 함께 보면 좋은 콘텐츠

제미나이를 업무에 어떻게 녹일지 더 보고 싶다면
👉 Gemini로 업무 수준을 끌어올리는 실무 전략 3가지

기업 보안 관점이 궁금하다면 
👉 기업이 꼭 알아야 할 제미나이 보안 팩트 3가지

여기까지 보셨다면, 시트 작업에서 줄일 수 있는 시간이 생각보다 많다는 감이 오셨을 겁니다. 문제는 어떤 플랜으로 시작해야 우리 회사에 맞는지, 그 판단이 의외로 까다롭다는 점이죠. 

파이브클라우드는 구글 워크스페이스 도입부터 플랜·라이선스 설계, 실무 활용 교육까지 함께 설계합니다. 우리 회사가 지금 쓰는 환경을 기준으로, 제미나이를 가장 효율적으로 쓰는 구성을 제안해 드립니다.