"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가지

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

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

지난 2026년 3월, Python 패키지 저장소 PyPI에서 실제로 그런 일이 일어났습니다. litellm이라는 라이브러리에 악성 코드가 포함된 버전이 배포됐고, 이 패키지를 설치한 환경의 환경 변수와 API 토큰까지 빨려나갈 수 있는 구조였죠.

흥미로운 건 공격이 시작된 곳이 litellm 자체가 아니었다는 점인데요. 공격자는 패키지를 직접 손대지 않았어요. 대신 그 패키지를 배포하던 CI/CD 파이프라인을 먼저 침해해서, 정식 경로로 악성 버전을 올렸습니다.

이번 글에서는 litellm 사건이 어떤 구조로 일어났는지 짚어보고, 우리 회사 CI/CD를 같은 패턴으로부터 지키기 위해 인프라 관점에서 무엇을 점검해야 하는지 정리해 드릴게요!

PyPI litellm 사건, 무슨 일이 있었나요?

2026년 3월 24일, PyPI에서 배포되던 litellm 패키지에 악성 코드가 포함된 버전이 발견됐습니다.

litellm은 OpenAI·Anthropic·Gemini 같은 여러 LLM API를 하나의 인터페이스로 호출할 수 있게 해주는 Python 라이브러리예요. 요즘 AI 기능을 백엔드에 붙이는 회사라면 한 번쯤 만져보는 패키지인 만큼, 영향 범위가 크다는 점에서 큰 주목을 받았습니다.

이 사건에서 주목할 점은 패키지 코드 자체에 취약점이 있던 게 아니라, litellm을 PyPI에 올리던 배포 파이프라인이 먼저 침해됐다는 점입니다.

좀 더 정확히 풀어보면 이런 순서로 일어났습니다.

왜 이런 공급망 공격이 가능했을까요?

요즘 공급망 공격은 개발과 배포 과정 전체를 하나의 연결된 신뢰 체인(Trust Chain)으로 보고, 그중 가장 약한 연결을 노려 침투하는 구조로 행해집니다.

현대 소프트웨어 개발 환경을 떠올려볼게요. 우리 회사 개발팀은 외부 오픈소스 라이브러리를 패키지 매니저로 가져다 쓰고, CI/CD 파이프라인이 빌드·테스트·배포를 자동으로 하고, 각 단계 사이에 외부 SaaS와 클라우드 API가 연동돼 있을 거예요. 이 구조가 업무 생산성을 높여주긴 하지만 외부 의존이 늘어난다는 의미이기도 합니다.

특히 GitHub Actions처럼 서드파티 Action을 적극적으로 가져다 쓰는 환경은 이 위험을 더 키웁니다. Action은 본질적으로 외부에서 만든 코드를 우리 회사 빌드 환경 안에서 실행하는 구조니까요. 평소엔 편리하지만, 그 Action 하나가 변조되는 순간 우리 회사 파이프라인의 자격 증명·소스코드·빌드 결과물이 동시에 위험해질 수 있습니다.

이번 litellm 사건이 단적인 예시예요. 공격자는 litellm 코드를 직접 손대지 않았고, 그 패키지를 배포하던 파이프라인의 의존 도구(Trivy Action) 하나만 공격했습니다. 그게 자격 증명을 노출시키고, 자격 증명이 패키지 배포 권한을 열고, 그 권한이 다시 수많은 후속 환경으로 공격 영향을 퍼뜨렸습니다.

그래서 공급망 공격 방어는 애플리케이션 보안만으로는 부족합니다. 개발 파이프라인 자체를 하나의 보안 영역으로 보고, 그 안의 자격 증명·외부 코드·권한 부여 범위를 다시 들여다봐야 해요.

우리 회사 CI/CD를 지키는 3가지 방법

AWS 비용을 통제하려면 과금 구조를 파악해야 합니다! 컴퓨팅, 스토리지, 데이터 전송에서 과금이 발생합니다. 이 셋의 누수 패턴을 잡는 것만으로도 평균 30~40%의 비용을 줄일 수 있습니다.

이 글은 AWS를 운영 중인 CTO·DevOps·인프라 담당자를 위한 정리입니다. 세 영역 어디에서 비용이 새고, 어떻게 막을 수 있는지를 구체적으로 살펴보겠습니다.

컴퓨팅: '안 쓰는 시간'까지 과금되고 있습니다

EC2와 Lambda, RDS 같은 컴퓨팅 리소스는 사용량 기반으로 과금됩니다. 쓴 만큼 지불하는 구조라서 합리적으로 보이지만, 정작 많은 기업이 '쓰지 않는 시간'까지 비용을 내고 있습니다.

퇴근 이후 아무도 접속하지 않는 개발 서버가 24시간 돌아가는 경우나 트래픽이 절반으로 줄어도 인스턴스 대수는 그대로일 때 비용이 새고 있습니다. 

아래 사항을 점검해 보세요.

• 개발·스테이징 서버가 야간이나 주말에도 계속 실행되고 있지 않은가
• 실제 CPU 사용률이 20%도 안 되는데 과하게 큰 인스턴스 타입을 쓰고 있지 않은가
• Auto Scaling이 빠져 있거나, 최소 대수가 과하게 잡혀 있지 않은가
• 예약 인스턴스(RI)나 Savings Plans 없이 온디맨드로만 운영하고 있지 않은가

이중 우리 회사에 해당하는 사항은 몇 개인가요? 경우에 따라 여기에서만 30% 이상의 비용을 낭비하고 있는 기업이 적지 않다고 하네요.

사용량 기반 과금제는 '얼마나 똑똑하게 쓰느냐'에 따라 비용 절감액이 달라집니다. 시간과 규모를 트래픽에 맞춰 사용법을 개선해 보세요!
Auto Scaling으로 수요에 따라 자동 증감시키고, 장기 사용 구간은 Savings Plans로 최대 72%까지 할인받을 수 있습니다. 야간에 비가동 리소스를 끄는 스케줄링만 적용해도 적지 않은 절감 효과가 나옵니다.

[참고] EC2 요금 체계를 온디맨드·RI·Savings Plans별로 비교하고 싶다면?
👉 <AWS EC2 요금은 어떻게 되나요?> 글을 살펴보세요! 

스토리지: 어제 만든 데이터가 오늘의 청구서를 늘립니다

S3와 EBS, EFS 같은 스토리지 비용은 한 번 발생하면 계속 비용으로 나갑니다. 컴퓨팅처럼 '끄면 줄어드는' 구조가 아니기 때문이죠. 데이터를 저장하는 순간부터, 그 데이터를 누군가 쓰든 말든 매달 같은 금액이 빠져나갑니다.

인스턴스를 종료하면서 EBS 볼륨은 그대로 남고, 백업으로 만든 스냅샷이 수년치 쌓이고, 종료 통보 없이 잊힌 테스트 RDS 인스턴스가 살아 있습니다. 로그·백업이 차곡차곡 들어가는 S3 버킷에는 1년 전 디버깅 자료가 그대로 보관됩니다. 자산화하기 위해 자료를 보관하지만, 쓰지 않는 데이터는 비용을 갉아먹을 뿐입니다.

이 문제는 '시스템이 자동으로 정리'하게 만들면 해결할 수 있습니다.
S3에 라이프사이클 정책을 설정하면 자주 쓰는 데이터는 Standard에, 가끔 쓰는 데이터는 Infrequent Access에, 거의 안 쓰는 데이터는 Glacier로 자동 이동시킬 수 있습니다. 한 번 정책을 걸어두면 매달 최대 70%까지 스토리지 비용이 줄어드는 사례가 많습니다.

EBS는 gp2에서 gp3로 전환만으로 약 20% 저렴해집니다. 사용하지 않는 스냅샷은 AWS Backup으로 정리하고, 미사용 리소스는 Trusted Advisor와 Cost Explorer로 분기마다 가시화합니다.

[참고] 스냅샷과 백업을 수동으로 관리하고 계신가요? 자동화 설정 방법을 정리해 뒀습니다.
👉 AWS Data Lifecycle Manager(DLM)로 백업 자동화하기

데이터 전송: AWS 안에서만 끝나고 있습니까

세 영역 가운데 가장 늦게 발견되는 비용인 데이터 전송. 청구서에 'Data Transfer'로 단일 라인이 잡히지만, 그 안에서 어떤 데이터가 어디로 흘렀는지 추적하기가 까다롭습니다. 다시 말하면, 새고 있는데 어디서 새는지 안 보이는 영역입니다.

AWS 안으로 들어오는 데이터는 대부분 무료, 밖으로 나가는 데이터는 유료인데요. 같은 AWS 안이라도 리전이나 가용영역(AZ)이 다르면 요금이 붙습니다. 창고에 짐을 쌓을 때는 비용이 들지 않지만, 외부로 배송할 때마다 무게당 요금이 붙는 택배 구조로 비유해 설명해 드리겠습니다.

문제는 우리 회사 데이터를 매달 어디로 얼마나 '배송'하고 있는지 추적조차 하지 않는 기업이 많다는 점입니다.

아웃바운드 트래픽이 늘어나는 지점은 대체로 아키텍처 결정과 맞닿아 있습니다. CloudFront(CDN)를 거치지 않고 S3에서 사용자에게 직접 전송하는 구조, 리전 간 데이터 복제가 필요 이상으로 잡혀 있는 설정, 멀티 AZ 구성에서 AZ 간 트래픽이 과도하게 오가는 토폴로지, API 응답에 불필요하게 큰 페이로드가 실리는 패턴까지. 비용 문제로 보기보단 설계 문제로 봐야할 것입니다.

해결 방향도 같습니다. 데이터를 최대한 AWS 안에서, 그리고 사용자와 가까운 곳에서 처리하도록 아키텍처를 다시 잡는 것입니다.

CloudFront를 앞단에 두면 캐싱된 콘텐츠가 원본까지 가지 않아 전송 비용을 최대 60%까지 줄일 수 있습니다. VPC 엔드포인트를 활용하면 S3나 DynamoDB 트래픽이 인터넷 구간을 타지 않습니다. 로그도 가능한 한 같은 리전 안에서 처리하도록 설계를 손봅니다.

서버 비용에만 집중하기 쉽지만, 실제로는 이 보이지 않는 택배비가 전체 청구서의 20% 이상을 차지하는 경우가 흔합니다.

[참고] 클라우드 비용 진단을 외부 파트너와 함께 진행한 사례가 궁금하신가요?
👉 파이브클라우드 클라우드 비용 컨설팅 사례를 함께 보시면 도움이 됩니다.

지금 점검할 3가지

1. 사용량 기반 리소스가 적정 크기로 운영되고 있나요?

CPU·메모리 사용률을 한 주만 모니터링해 봐도 인스턴스 사이징이 과한지 부족한지 답이 나옵니다. Auto Scaling 적용 여부와 Savings Plans 커버리지를 함께 점검합니다.

2. 방치된 스토리지와 스냅샷이 매달 얼마를 소모하고 있나요?

Cost Explorer에서 스토리지 항목을 분리해 보면 인지하지 못한 EBS 스냅샷, 미사용 볼륨, 오래된 S3 데이터가 드러납니다. 라이프사이클 정책 설정 여부부터 확인합니다.

3. 아웃바운드 트래픽이 CDN과 VPC 엔드포인트로 최적화되어 있나요?

청구서의 'Data Transfer' 항목 비중을 한 번 확인하시기 바랍니다. 전체의 15%를 넘는다면 CloudFront 도입이나 엔드포인트 설계를 검토할 시점입니다.

AWS 비용을 잡는 일은 기술 작업이라기보다 운영 결정에 가깝습니다. 컴퓨팅에서 '쓰지 않는 시간'을 줄이고, 스토리지에서 '시스템이 자동으로 정리하게' 하고, 데이터 전송에서 '아키텍처를 사용자 가까이로 옮기는 일.' 이 세 가지를 실행한다면 새는 비용을 줄여나갈 수 있습니다.

다만 셋을 동시에 손보는 시도는 권장하지 않습니다. 청구서에서 비중이 가장 큰 영역부터 차근 차근 정리하는 편이 더 빠릅니다. 하나를 정리하고 나면, 다음 영역에서 새고 있는 비용도 같은 관점으로 드러나기 때문이죠.

화상회의 도중 화면이 자꾸 깨집니다.
신입사원의 슬랙 계정을 누가 만들지 정해져 있지 않습니다.
한 달 전에 퇴사한 직원의 Notion 계정이 아직 살아 있습니다.

직원이 30명 안팎이라면 익숙한 풍경일 겁니다. 그런데 이 일들은 모두 같은 원인에서 출발합니다. 10명에게 맞춘 IT 구조를 30명이 그대로 쓰고 있기 때문입니다.

공유기 한 대로 사무실 전체가 커버되고, 어느 팀이 어떤 SaaS를 쓰는지 대표가 머릿속에 다 담아두던 시절의 운영 방식은 30명 사무실에서는 지속하기 어렵습니다.

30명 안팎은 IT 관점에서 가장 까다로운 구간인데요. 이때를 어떻게 정리하느냐가 50명·100명으로 갈 때 같은 고생을 반복할지를 좌우합니다.

한꺼번에 신호가 옵니다

처음에는 한두 영역에서 가벼운 잡음으로 시작합니다.
그러다 어느 순간부터 여러 군데에서 동시에 문제가 올라옵니다.

가장 먼저 체감되는 건 네트워크입니다. 회의 도중 Wi-Fi가 끊기거나, 특정 회의실에서만 신호가 약합니다. 외부 고객과의 화상회의에서 화면이 깨지는 일이 주 단위로 반복됩니다. 통신사에 문의해도 회선은 정상이라는 답만 돌아옵니다.

그다음은 계정 관리입니다. 신입사원의 계정을 누가 만들지 정해져 있지 않으니 인사팀, 팀장, 대표가 번갈아 처리합니다. 퇴사자 정리도 일관되지 않습니다. Slack은 비활성화됐는데 Notion은 남아 있고, Figma는 결제 관리자만 지울 수 있는데 그 관리자가 휴가를 가면 바로 삭제가 되지 않아 한 달 뒤에 퇴사자 계정이 살아 있다는 걸 우연히 발견하기도 합니다.

파일과 지식 공유는 더 천천히 진행되지만, 그만큼 손실이 큽니다. 중요한 기획 문서가 누군가의 개인 Drive에 들어가 있고, 그 사람이 휴가를 가면 접근이 막힙니다. Slack DM으로 주고받은 파일은 두 달 뒤 검색이 어렵습니다. 회사가 쌓아야 할 지식이 점점 더 개인의 기억에 의존합니다.

보안은 마지막까지도 잘 안 보이는 영역인데요. 10명까지는 서로 가깝게 지내니 신뢰만으로 큰 문제가 없었습니다. 30명을 넘기면 전체 직원의 노트북 상태를 아무도 파악하지 못합니다. SaaS 관리자 권한을 누가 가지고 있는지, 2단계 인증이 꺼진 계정이 몇 개인지조차 파악할 수 없는 상황이 어느새 우리 회사의 일상이 되죠.

혹시 회사에서 이런 증상을 겪고 있다면, 아래 내용을 보시면 해결하는 데 도움이 되실 거예요!

네트워크: 가정용 공유기와 기업용 AP

가정용 공유기는 동시 접속이 30~50대를 넘어가면 성능이 떨어집니다.
스펙에 "100대 지원"이라고 적혀 있어도, 실제 환경에서는 그렇지 않죠.

직원 30명 사무실의 접속 기기를 한번 세어 보겠습니다. 노트북 30대에 스마트폰 30대, 프린터 두세 대, 회의실 TV 서너 대, 거기에 스마트스피커와 IoT 센서까지. 80대는 쉽게 넘어갑니다. 외부 미팅 손님 노트북이 들어오는 날에는 더 늘어나고요.

가정용 공유기 한 대로 감당할 수 있는 규모가 아닙니다.

기업용 AP는 구조 자체가 다릅니다. 한 대당 동시 접속 100대 이상을 안정적으로 처리하고, 여러 대를 묶어 배치하면 자동으로 신호 세기를 조정합니다. 직원이 회의실에서 자리로 돌아와도 연결이 그대로 유지됩니다.

다만 기업용 AP로 바꾸기만 하면 된다고 생각하면 곤란합니다. 사무실에 벽이 많거나 금속 파티션이 많으면 신호 감쇄가 크기 때문입니다.

장비 사양보다 AP 개수와 위치 설계가 더 중요합니다. 시공 업체와 이야기할 때는 "AP 몇 대 설치"가 아니라 "사무실 전 영역의 신호 커버리지"를 기준으로 협의하시는 게 좋습니다.

[참고] 네트워크 시공 실제 사례가 궁금하시다면?
👉 글로벌 게임사 시프트업의 사옥 네트워크 인프라 구축 후기를 함께 보세요!

계정과 파일은 시스템으로 관리하기

10명 회사에서는 누가 무엇을 쓰는지 대표나 COO가 머릿속에 담을 수 있지만, 인원이 많아지면 더이상 기억에만 의존할 수 없습니다.

가장 먼저 손볼 것은 Google Workspace 또는 Microsoft 365 기반의 조직 계정 정리입니다. 초창기에 개인 Gmail로 업무를 보던 구조를 그대로 두면, 직원 한 명이 퇴사할 때 자료 회수가 안 되고 보안 설정도 일괄 적용할 수 없습니다.
조직 계정 기반으로 바꾸면 입·퇴사 시 계정 하나를 만들고 끄는 작업만으로 연결된 모든 업무 접근이 정리됩니다.

그다음은 공용 파일에 대한 기준입니다. "팀 드라이브에 올리는 게 원칙, 개인 드라이브는 초안만." 이 한 줄짜리 규칙만 있어도 자료 유실이 눈에 띄게 줄어듭니다. "파일명 앞에 프로젝트 코드를 붙인다" 같은 단순한 규칙을 더하면 검색성도 함께 올라갑니다.

단, 기존 파일 수천 개를 한 번에 옮기려고 하면 반발이 큽니다. 평소 쓰던 방식을 바꾸는 데서 오는 거부감도 무시할 수 없습니다.

현실적인 방식은 과거 자료는 그대로 두고, 신규 프로젝트부터 새 규칙을 적용하는 것입니다.
3~6개월쯤 지나면 새 규칙을 따르는 자료가 회사 전체 자료의 대부분을 차지합니다.

전담 채용 vs. 외부 위탁

30명 구간에서 경영진이 가장 자주 하는 고민입니다.
단순 비용만 비교하면 외부 위탁이 압도적으로 저렴하지만, 비용만으로 결정하지 마세요!

• 전담 IT 담당자 채용: 연 6천만 원 이상 (연봉 5천 + 4대보험 + 퇴직금 + 복지 + 장비)
• 외부 위탁: 월 수십~수백만 원 (서비스 범위에 따라)

전담 담당자는 상주하면서 즉시 대응이 가능합니다. 다른 팀과의 관계, 회사의 우선순위, 업무 특성을 이해한 상태에서 판단합니다. 

외부 위탁은 응답 시간에 편차가 있고 회사 내부 사정을 잘 모르지만, 네트워크부터 클라우드, 보안까지 여러 전문 영역을 한꺼번에 커버할 수 있다는 강점이 있습니다.

한 사람이 이 모든 영역에 깊은 전문성을 갖춘 경우는 드뭅니다.

30명을 앞둔 기업에게는 이 두 케이스를 '조합'하는 것이 현실적인 해결책입니다. 
회사 안에 일반적인 IT 대응을 할 담당자를 한 명 두고, 전문 영역은 외부 파트너에 맡기는 방식입니다. 내부 담당자는 직원들의 일상 요청을 처리합니다. 외부 파트너는 네트워크 설계, 클라우드 비용 관리, 보안 점검 같은 영역을 담당합니다.

 "지금 가장 문제가 되는 영역이 어디인가."를 살펴보시고 외부에 도움을 청해 보세요!
네트워크가 계속 문제라면 네트워크부터 외부에 맡기고, 퇴사자 계정이 계속 남아돈다면 계정 관리 체계를 잡는 일부터 외부 도움을 받으면 됩니다. 모든 영역을 한 번에 해결하려고 하면, 어디부터 손볼지 정하는 단계에서 시간만 흘러갈 뿐이죠.

[참고] IT 전담 인력 없이 운영 체계를 잡는 방법이 궁금하시다면?
👉 우리 회사도 IT 전문가 없이 AX 할 수 있을까? 글도 함께 살펴보세요.

30명 구간 실무 체크포인트

1. 지난 3개월간 반복된 IT 불편사항 5가지 적어보기
"Wi-Fi가 느림"이 아니라 "지난주 화요일 전체 회의에서 3번 끊김"처럼 구체적으로 적어 보세요. 위에서 말씀드린 4대 영역 가운데 어디서 가장 문제가 큰 지가 자연스럽게 드러납니다.

2. 전담 채용 전이라도 "IT 의사결정 담당자" 한 명 지정하기
문제가 생겼을 때 누구에게 물을지만 정해도 대응 속도가 달라집니다. 전공자가 아니어도 되고 겸직이어도 무방합니다. 중요한 건 "이 사안은 이 사람이 본다"는 내부 합의입니다.

3. 네 영역 중 한 곳부터 손보기
공유기와 계정, 파일, 보안을 한 번에 다 바꾸려 하면 반발과 피로가 큽니다. 가장 문제가 큰 한 곳을 정해 3개월 안에 정리하고, 다음 영역으로 넘어가는 방식이 현실적입니다.

여기까지 읽으셨다면 이미 '우리 회사도 손볼 때가 됐다'는 감이 오셨을 겁니다. 문제는 어디서부터 손대야 할지, 그 판단이 어렵다는 거죠.

파이브클라우드는 30명 안팎 조직이 가장 자주 마주치는 네트워크·계정·보안 문제를 진단하고, 지금 단계에 맞는 구조를 함께 설계합니다. 장비 하나 바꾸는 게 아니라, 50명·100명이 되어도 같은 고생을 반복하지 않을 운영 체계를 잡는 일입니다.

이렇게 반응이 갈리는 데는 이유가 있습니다. AI 도구 자체의 성능 차이도 있지만, 그보다 더 큰 변수는 '어떤 업무에, 어떤 방식으로 쓰느냐'입니다. 이번 글에서는 실제 업무 현장에서 효과가 있었던 사례와 그렇지 않았던 이유를 살펴보고, 우리 팀에 적용한다면 어디서부터 시작하면 좋을지 실무적인 관점에서 정리했습니다.

AI로 생산성이 오르는 조건

AI를 업무에 도입한 기업들의 실제 반응은 기대만큼 단순하지 않습니다. 긍정적인 결과를 낸 사례가 분명히 존재하지만, 그 효과는 도입 방식과 업무 성격에 따라 크게 갈립니다. 국내 한 중견 제조사의 경우, 영업팀이 주간 보고서 작성에 평균 3시간 이상을 쓰고 있었습니다. AI 문서 작성 도구를 도입한 후 초안 작성 시간이 약 40분대로 줄었고, 직원들은 남는 시간에 데이터 해석과 전략 검토에 집중할 수 있었습니다.

콜센터 운영사에서는 고객 문의 유형을 AI가 자동 분류하고 담당자에게 배정하는 방식을 도입했습니다. 일 평균 200건의 분류 작업이 자동화되면서 응대 대기시간이 단축됐고, 담당자는 실제 고객 응대에 더 많은 에너지를 쏟을 수 있게 되었습니다.

두 사례의 공통점은 하나입니다. 효과를 본 기업들은 AI를 "업무 전체를 맡기는 도구"가 아니라 "반복 업무를 덜어주는 보조 수단"으로 활용했습니다.

AI 도입 후 효율이 떨어지는 이유

AI 도입 후 업무 효율이 떨어졌다는 반응도 적지 않습니다. 주된 이유는 두 가지입니다.

첫 번째는 검수 부담의 증가입니다. AI가 초안을 빠르게 만들어주긴 하지만, 결과물이 실제 사용 가능한 수준인지 확인하는 작업이 생각보다 많은 시간을 잡아먹습니다. 특히 수치, 법적 표현, 고객사 이름처럼 오류가 났을 때 영향이 큰 항목이 포함된 문서일수록 그렇습니다.

두 번째는 도구 사용 자체가 새로운 업무가 되는 상황입니다. 프롬프트를 잘 써야 좋은 결과가 나온다는 사실을 모르고 도입하면, 원하는 결과를 얻기까지 여러 번 시도를 반복하게 됩니다. 처음에는 시간이 절약되는 것이 아니라, 오히려 더 많이 쓰이는 경험을 하게 됩니다.

결국 AI는 도입한다고 해서 자동으로 효율이 오르는 도구가 아닙니다. 어떤 업무에 쓸지, 어느 수준까지 믿을지, 결과물을 어떻게 다룰지에 대한 내부 기준이 없으면 오히려 업무 피로도가 높아질 수 있습니다.

 AI 결과물, 70%만 신뢰하기

AI를 잘 활용하는 팀과 그렇지 않은 팀의 차이는 도구의 성능보다 활용 방식에서 갈립니다. 효과적인 팀들은 AI 결과물을 "완성본"이 아니라 "초안"으로 받아들입니다. 이 관점이 바뀌면 검수 방식도 달라집니다. 전체를 다시 쓰는 것이 아니라, 사실 여부와 맥락이 맞는지만 빠르게 확인하는 방식으로 처리할 수 있습니다.

실제로 효율이 올라간 팀들이 공통으로 쓰는 방식이 있습니다. AI에게 전체 내용을 한 번에 쓰게 하는 것보다, 목차나 항목 구성을 먼저 받아보고 방향이 맞으면 이어서 내용을 채우는 순서로 진행합니다. 이렇게 하면 수정 포인트가 명확하게 보입니다. 검수 담당자를 정해두는 것도 중요합니다. AI가 작성한 내용을 최종 확인하는 사람이 명확하지 않으면, 아무도 책임지지 않는 상태로 결과물이 나가게 됩니다. 작더라도 이 역할을 정해두는 것만으로 결과물의 신뢰도가 달라집니다.

어디서부터 시작할까?

모든 업무에 AI를 한꺼번에 적용하려고 하면 오히려 혼란이 생깁니다. 처음에는 범위를 좁게 잡는 것이 현실적입니다. 시작점으로 적합한 업무는 세 가지 조건을 갖춘 것들입니다. 형식이 반복되는 업무, 결과물의 오류가 치명적이지 않은 업무, 담당자가 검수할 시간이 확보되는 업무입니다. 주간 보고서 초안 작성, 내부 공지문, 회의록 정리, 이메일 초안 등이 여기에 해당됩니다.

반면 계약서 검토, 재무 데이터 해석, 법적 판단이 필요한 문서, 민감한 고객 커뮤니케이션 같은 업무는 AI 결과물에 대한 의존도를 낮게 유지하는 것이 좋습니다. 이 영역에서 AI는 참고 수단이 될 수는 있어도 판단의 주체가 될 수는 없습니다. 조직 차원에서는 도구 도입 전에 팀 내 합의가 먼저입니다. 어떤 도구를, 어떤 업무에, 어느 수준까지 활용할지 기준을 정해두지 않으면 팀마다 사용 방식이 달라져 협업이 복잡해집니다.

실무 체크포인트 3가지

1. AI를 적용할 업무를 먼저 선별하기: 모든 업무에 동시 적용하기보다, '반복적이고 형식이 정해진 업무' 한 가지에서 시작하는 것이 좋습니다. 효과를 체감한 뒤에 범위를 넓히는 방식이 실패 가능성을 줄여줍니다.

2. 결과물 검수 기준과 담당자 지정하기: AI가 작성한 결과물을 팀 내 누가, 어떤 기준으로 확인할지 사전에 정해두지 않으면 책임 소재가 불명확해집니다. 간단한 체크리스트 하나만 만들어도 검수 부담이 줄어듭니다.

3. AI 결과물을 '초안'으로 규정하기: 완성본이 아닌 초안으로 받아들이는 문화를 팀 내에서 먼저 공유하는 것이 중요합니다. 기대치를 낮추는 것이 아니라, 활용 방식을 현실에 맞게 조정하는 것입니다. 이 관점 하나가 도구에 대한 피로도와 불신을 줄여줍니다.

이와 함께 이미지 보안 스캔 또한 중요한 단계로 인식되고 있으며, 많은 환경에서 Trivy와 같은 도구를 활용하고 있습니다. 하지만 GitHub Actions에서 사용되는 Trivy Action 보안 스캔과 관련된 이슈까지 함께 살펴보겠습니다. 

이번 글에서는 컨테이너 배포의 기본 흐름부터, GitHub Actions의 Trivy Action 보안 스캔과 관련된 이슈까지 함께 살펴보겠습니다.

1. 컨테이너 배포는 어떻게 이루어질까?

컨테이너 기반 배포는 일반적으로 코드 작성부터 시작해 이미지 빌드, 이미지 저장, 보안 스캔, 그리고 최종 배포까지의 흐름으로 이루어집니다.

① 코드 작성

개발자는 애플리케이션 구성 코드를 작성합니다. 이 코드는 Dockerfile이라는 설정 파일을 기반으로 하나의 '이미지'로 만들어집니다. Dockerfile은 어떤 운영체제를 사용할지, 어떤 라이브러리를 설치할지, 어떻게 실행할지를 미리 설정해 두는 일종의 실행 설명서라고 볼 수 있습니다.

② 이미지 빌드

Dockerfile에 정의된 내용을 바탕으로 컨테이너 이미지를 생성합니다. 이 과정에서 애플리케이션 코드뿐만 아니라, 실행에 필요한 라이브러리와 환경 설정까지 함께 구성됩니다. 단순히 코드를 복사하는 것이 아니라, 애플리케이션이 정상적으로 실행될 수 있는 환경을 하나의 이미지로 패키징하는 과정입니다. 이렇게 생성된 이미지는 어디서 실행하더라도 동일한 환경을 보장합니다.

③ 이미지 저장

빌드가 완료된 컨테이너 이미지는 이미지 레지스트리(저장소)에 업로드됩니다. 이미지 레지스트리는 컨테이너 이미지를 보관하는 저장소로, 대표적으로 Amazon ECR이나 Docker Hub와 같은 서비스가 사용됩니다. 저장된 이미지는 필요할 때 언제든지 가져와 실행할 수 있으며, 여러 서버나 환경에서 동일한 이미지를 기반으로 배포할 수 있습니다.

④ 보안 스캔

이미지가 저장된 이후에는, 해당 이미지에 취약점이 포함되어 있는지 확인하는 보안 스캔 과정을 거칩니다. 이미지 내부에 포함된 운영체제 패키지나 라이브러리에서 알려진 보안 취약점(CVE)이 존재하는지를 검사합니다. 오래된 라이브러리나 보안 패치가 적용되지 않은 패키지가 포함되어 있다면 실행 시 보안 위협으로 이어질 수 있기 때문에 사전에 이를 확인하는 것이 중요합니다. 보안 스캔은 필수 단계는 아니지만, 서비스 안정성과 보안 요구사항이 높아지면서 점점 중요해지고 있습니다.

⑤ 배포

보안 검증까지 완료된 이미지는 실제 서비스 환경에 배포되어 실행됩니다. 일반적으로 Kubernetes와 같은 컨테이너 오케스트레이션 환경에서 배포가 이루어지며, 여러 개의 컨테이너를 자동으로 관리하고 확장할 수 있도록 구성됩니다. 결과적으로 컨테이너 환경에서는 코드가 아닌 이미지를 기준으로 배포가 이루어지며, 동일한 환경을 유지하면서 일관된 배포를 수행할 수 있습니다.

2. 배포 과정을 자동으로 실행하는 GitHub Actions

컨테이너 배포의 여러 단계를 매번 수동으로 수행하기에는 번거롭고 실수가 발생하기 쉽습니다. 이를 해결하기 위해 등장한 것이 CI/CD 파이프라인이며, GitHub Actions를 통해 배포 과정을 자동화할 수 있습니다.

GitHub Actions는 코드 저장소에 변경이 발생했을 때, 미리 정의된 작업을 자동으로 실행해주는 도구입니다. .github/workflows 경로에 YAML 파일을 작성해 이미지 빌드, 저장, 배포 등의 단계를 순차적으로 정의하면, 코드가 업로드되는 순간 자동으로 실행됩니다.

또한 uses 구문을 통해 외부에서 제공되는 Action을 가져와 사용할 수 있어 복잡한 작업도 간단하게 구성할 수 있습니다. 다만 이 구조는 내가 작성하지 않은 외부 코드가 파이프라인 내부에서 그대로 실행된다는 특징을 가지며, 보안 측면에서 새로운 위험 요소가 될 수 있습니다.

3. 보안 도구에서 발생한 공급망 공격, Trivy 이슈

보안 스캔 단계에서 많이 사용되는 Trivy는 컨테이너 이미지의 운영체제 패키지, 라이브러리, 애플리케이션 의존성을 분석해 알려진 취약점을 확인해주는 도구입니다. 최근 이 과정에서 주목할 만한 보안 이슈가 발생했습니다. 문제는 Trivy 자체의 취약점이 아니라, GitHub Actions에서 Trivy를 실행하는 방식에 있었습니다. Trivy를 실행하는 Action이 공격자에 의해 변경되면서, 보안 취약점을 점검해야 할 코드가 악성 코드로 바뀌게 된 것입니다.

uses: aquasecurity/trivy-action@v0.69.4

겉으로는 동일한 버전(v0.69.4)을 사용하는 것처럼 보이지만, 실제로 실행되는 내부 코드는 이미 악성 코드로 바뀌어 있었습니다. 이번 이슈는 GitHub Actions에서 Trivy를 사용하는 경우에 해당하며, Aqua Security 상용 플랫폼의 Trivy에는 영향이 없는 것으로 확인되었습니다. 공식적으로 권장되는 대응 방안은 다음과 같습니다.

• 1단계: 안전한 버전으로 업데이트 Trivy 바이너리 v0.69.2 ~ v0.69.3, Trivy Action v0.35.0, setup-trivy v0.2.6으로 즉시 업데이트해야 합니다.
• 2단계: 비밀 정보 교체(Secrets Rotation) 손상된 버전이 실행되었을 가능성이 있다면, 파이프라인에서 접근 가능한 모든 비밀 정보를 노출된 것으로 간주하고 즉시 교체해야 합니다. AWS / GCP / Azure 자격 증명, Git 접근 키, 컨테이너 레지스트리 인증 정보, SSH 키 및 Kubernetes 토큰 등이 모두 대상에 포함됩니다.

4. AWS 환경에서 컨테이너 보안 스캔 구성하기

AWS 환경에서는 Amazon ECR을 통해 이미지를 저장하면서 동시에 취약점 스캔을 수행할 수 있습니다. CI/CD 파이프라인 내부에서 별도의 보안 도구를 실행하지 않아도, 이미지가 저장되는 시점에 검사가 이루어지는 구조입니다.

이 방식은 외부 Action 실행 과정에서 발생할 수 있는 공급망 리스크를 줄이고, 보다 안정적인 위치에서 보안 검사를 수행할 수 있다는 점에서 의미가 있습니다. 실무에서는 ECR 기반 스캔을 기본으로 활용하면서, 필요에 따라 배포 이전 단계에서 추가 검증을 병행하는 방식이 많이 사용됩니다.

컨테이너 보안은 특정 도구를 사용하는 것보다, 이미지 생성부터 배포까지의 전체 흐름을 어떻게 설계하느냐에 따라 달라집니다. 컨테이너 배포 설계가 필요하다면, 파이브클라우드가 실무에 맞는 방향으로 함께 도와드리겠습니다. 신규 구축이나 개선이 필요하신 경우 언제든지 파이브클라우드에 문의해 주세요.

구글의 차세대 AI 실험 도구인 NotebookLM은 GWS와 만났을 때 비로소 진정한 위력을 발휘합니다. 내 드라이브 속 자료들을 나보다 더 잘 파악하고 분석해 주는 이 스마트한 파트너, 지금 바로 소개합니다.

NotebookLM, GWS와 이렇게 연동됩니다

1) Google Drive와의 완벽한 싱크

파일을 매번 다운로드해서 업로드할 필요가 없습니다. NotebookLM 내에서 구글 드라이브(Docs, Slides)에 있는 문서를 바로 불러올 수 있고, 여러 개의 구글 문서를 하나의 '노트북'으로 묶어 통합 분석하는 것도 가능합니다.

2) '소스 기반' 답변: 할루시네이션(AI의 거짓말) 제로

일반적인 챗봇은 웹상의 광범위한 데이터를 기반으로 답하지만, NotebookLM은 오직 내가 지정한 GWS 문서 안에서만 답을 찾습니다. 답변의 근거가 된 문서의 특정 문장을 클릭하면 바로 해당 위치로 이동해 확인할 수 있습니다.

3) 오디오 오버뷰(Audio Overview) — 보고서를 팟캐스트로

복잡한 구글 슬라이드나 긴 기획안을 일일이 읽기 힘드시나요? 클릭 한 번으로 두 명의 AI 호스트가 자료의 핵심 내용을 대화 형식으로 풀어주는 오디오를 생성합니다. 출퇴근길에 귀로 프로젝트 내용을 복습할 수 있습니다.

왜 GWS 환경에서 NotebookLM이 필수일까?

정보의 파편화 해결 드라이브 여기저기 흩어진 회의록, 시장조사서, 제안서를 하나의 '노트북'에 모아 연동하면, 전체 프로젝트의 맥락을 한 번에 파악할 수 있습니다.

보안과 프라이버시 구글은 GWS 기업용/교육용 계정의 데이터를 모델 학습에 사용하지 않는다고 명시하고 있습니다. 기업의 기밀 자료를 안전하게 분석할 수 있는 환경을 제공합니다. 협업의 효율성 내가 만든 '노트북'을 팀원과 공유하면, 팀 전체가 동일한 소스를 기반으로 질문하고 인사이트를 얻는 공유 지식 베이스가 구축됩니다.

실제 업무 활용 시나리오 (GWS 기반)

신규 프로젝트 온보딩 과거 프로젝트 문서와 매뉴얼이 담긴 드라이브 폴더를 연동하면, 신입 사원이 질문만으로 업무를 빠르게 파악할 수 있습니다.

제안서 작성 기존 성공 사례(Slides)와 고객 요구사항(Docs)을 소스로 지정하면, 두 문서의 공통점과 차이점을 분석해 전략 도출이 가능합니다. 회의 요약 및 액션 아이템 구글 미트(Meet)의 회의록(Transcript)을 업로드하면 주요 결정 사항과 담당자별 할 일을 즉시 정리해 줍니다.

사용 전 꼭 알아야 할 팁

• GWS 권한 확인: 노트북LM에서 드라이브 파일을 불러오려면 구글 계정 연동 권한 승인이 필요합니다.
• 멀티 소스 활용: 하나의 노트북에 최대 50개의 소스를 넣을 수 있습니다. 성격이 비슷한 문서끼리 묶어 관리하세요.
• 가이드 노트 작성: 분석된 내용을 바탕으로 새로운 인사이트를 적으면, NotebookLM이 그 메모까지 학습하여 더 정교한 답변을 줍니다.

Google Workspace가 자료를 '담는 그릇'이었다면, NotebookLM은 그 그릇 속의 내용을 '소화시키는 뇌'입니다. GWS를 사용 중인 직장인이나 학생이라면, 지금 바로 NotebookLM을 통해 잠자고 있던 문서들에게 생명력을 불어넣어 보세요. 정보를 찾는 시간은 줄어들고, 통찰을 얻는 시간은 비약적으로 늘어날 것입니다.

NotebookLM x Google Drive 연동 가이드

Step 1. 메인 화면 및 '새 노트북' 생성

새 노트북 생성 NotebookLM 홈페이지에 구글 계정으로 로그인한 뒤, 중앙의 [+ 새 노트북] 버튼을 클릭합니다. 나만의 지식 저장소가 될 노트북을 만드는 첫 번째 단계입니다.

Step 2. 소스 선택 창 (구글 드라이브 아이콘 강조)

구글 드라이브 연동 '소스 추가' 팝업창에서 [Google 드라이브] 아이콘을 선택합니다. PDF, 텍스트, 웹사이트 등 다양한 옵션 중 GWS 사용자라면 드라이브 아이콘을 클릭해 파일을 바로 불러올 수 있습니다.

Step 3. 드라이브 내 파일 선택 화면

파일 선택 내 구글 드라이브 파일 목록에서 분석하고 싶은 문서(Docs)나 슬라이드(Slides)를 선택합니다. 최대 50개까지 한꺼번에 선택해 통합 인사이트를 얻을 수 있습니다.

Step 4. 연동 완료 및 소스 가이드 확인

연동 완료 및 소스 가이드 확인 연동이 완료되면 AI가 즉시 문서 전체를 파악해 요약본을 생성합니다. 왼쪽 사이드바에 파일 목록이 표시되고, 중앙에 핵심 요약(Source Guide)이 나타납니다. 이제 질문할 준비가 끝났습니다.

Step 5. (보너스) 오디오 오버뷰 생성 화면

오디오 오버뷰 생성 우측 상단의 'Notebook guide'에서 [Audio Overview - Generate] 버튼을 클릭하면 GWS 문서들을 팟캐스트 형식으로 변환해 줍니다. 버튼 한 번으로 내 자료가 말하는 콘텐츠가 됩니다.

이럴 때 문제의 원인을 파악하기 위해 가장 먼저 확인하는 것이 바로 로그(Log)입니다. 로그에는 시스템에서 발생한 다양한 이벤트가 기록되기 때문에, 문제가 언제 발생했는지, 어디에서 발생했는지, 어떤 요청이 있었는지를 추적할 수 있습니다.

이번 글에서는 로그가 무엇인지, 그리고 로그가 어떤 형태로 기록되는지에 대해 기본 개념을 중심으로 살펴보겠습니다.

1. 로그란 무엇인가

로그는 시스템에서 발생한 일을 기록하는 데이터입니다. 사용자가 언제 요청을 보냈는지, 서버가 어떤 응답을 했는지, 오류가 발생했는지 등 시스템 내부에서 일어난 다양한 상황이 시간 순서대로 기록됩니다. 이러한 로그를 통해 시스템에서 실제로 어떤 일이 발생했는지 추적하고 원인을 파악할 수 있습니다. 예를 들어 웹 서버에서 사용자가 API를 호출하면, 요청과 응답에 대한 정보가 로그로 남게 됩니다.

하나의 로그에는 여러 정보가 포함되어 있으며, 이는 서버에서 어떤 일이 발생했는지 이해하는 데 활용됩니다. 로그에서 자주 확인할 수 있는 주요 구성 요소는 다음과 같습니다.

• timestamp: 로그가 발생한 시간으로, 이벤트 발생 시점을 확인하는 데 사용됩니다.
• level: 로그의 중요도를 나타내며 DEBUG, INFO, WARN, ERROR로 구분됩니다.
  • DEBUG: 개발 및 분석을 위한 상세 로그입니다.
  • INFO: 정상 동작 상태를 의미합니다.
  • WARN: 이후 문제로 이어질 수 있는 상태입니다.
  • ERROR: 실제 오류가 발생한 상황입니다.
• request: 클라이언트의 요청을 의미합니다.
  • method: 요청 방식으로 GET, POST, PUT 등이 사용됩니다.
  • path: 요청한 API 또는 리소스의 경로입니다.
  • protocol: HTTP 프로토콜 버전을 의미합니다.
• status: 요청 처리 결과를 나타내는 HTTP 상태 코드입니다.
• latency: 요청 처리에 걸린 시간입니다.

모든 로그가 동일한 형식을 사용하는 것은 아니며, 운영체제, 웹 서버, 애플리케이션, 데이터베이스 등 각 시스템의 목적에 따라 형식이 달라질 수 있습니다. 하지만 대부분의 로그에는 공통적으로 다음과 같은 정보가 포함됩니다. timestamp는 이벤트가 발생한 시간, level은 로그의 중요도, message는 어떤 이벤트가 발생했는지에 대한 설명입니다. 결국  로그는 언제, 어디에서, 어떤 일이 발생했는지를 확인하기 위해 사용됩니다.

2. 로그의 종류

로그는 시스템의 종류와 목적에 따라 다양한 형태로 생성됩니다. 같은 시스템이라도 어떤 정보를 기록하느냐에 따라 로그의 종류가 달라질 수 있습니다.

대표적으로 다음과 같은 로그가 있습니다.

• 웹 서버 로그
  • 사용자가 웹 서버에 요청을 보냈을 때 생성됩니다.
  • 어떤 URL이 호출되었는지, 응답 상태 코드는 무엇인지 등을 확인할 수 있습니다.

• 애플리케이션 로그
  • 애플리케이션 내부에서 발생하는 이벤트를 기록합니다.
  • 사용자 로그인, 비즈니스 로직 실행, 오류 발생 등의 정보가 포함됩니다.

• 데이터베이스 로그
  • 데이터베이스에서 실행된 쿼리나 트랜잭션 등의 정보를 기록합니다.
  • 데이터 변경 이력이나 성능 분석에 활용됩니다.

• 시스템 로그
  • 운영체제 수준에서 발생하는 이벤트를 기록합니다.
  • 시스템 시작, 서비스 실행, 보안 이벤트 등의 정보가 포함됩니다.

이처럼 로그는 시스템의 종류에 따라 다양한 형태로 생성됩니다. 하지만 형식은 서로 달라도, 대부분 시스템에서 어떤 일이 발생했는지를 기록하기 위한 데이터라는 공통된 목적을 가지고 있습니다.

3.로그는 어떻게 생성되는가

로그는 실제로 어떤 방식으로 생성될까요? 로그는 시스템이 동작하는 과정에서 다양한 방식으로 기록됩니다. 시스템에 따라 파일로 저장되기도 하고, 콘솔(stdout)에 출력되기도 하며, 개발자가 코드에서 직접 로그를 남기도록 설정할 수도 있습니다.

대표적으로 다음과 같은 방식으로 로그가 생성됩니다. 파일로 저장되는 로그는 가장 일반적인 방식으로, 로그를 파일 형태로 기록하는 방법입니다. 예를 들어 Linux 서버에서는 /var/log 경로에서 로그 파일을 확인할 수 있으며, syslog나 nginx의 access.log와 같은 파일에 시스템과 서비스에서 발생한 이벤트가 지속적으로 기록됩니다.

콘솔(stdout, stderr)로 출력되는 로그도 많이 사용됩니다. 특히 Docker나 Kubernetes와 같은 컨테이너 환경에서는 애플리케이션 로그를 파일이 아니라 stdout으로 출력하고, 이를 플랫폼에서 수집하여 관리하는 구조가 일반적입니다. 애플리케이션이 실행되면 콘솔에서 로그를 확인할 수 있으며, 이러한 로그는 로그 수집 시스템에서 모아서 관리됩니다.

개발자가 직접 남기는 로그도 있습니다. 애플리케이션 코드에서 특정 이벤트가 발생했을 때 로그를 기록하도록 구현할 수 있으며, 예를 들어 사용자 로그인 성공이나 데이터베이스 연결 실패와 같은 상황을 코드에서 직접 로그로 남길 수 있습니다. 이를 통해 문제 분석이나 서비스 상태 확인에 활용할 수 있습니다.

이처럼 로그는 파일, 콘솔 출력, 애플리케이션 코드 등 다양한 방식으로 생성되며, 이러한 로그를 통해 시스템에서 어떤 일이 발생했는지 추적할 수 있습니다.

4. 운영 환경에서의 로그 수집: Kubernetes 사례

지금까지 살펴본 것처럼 로그는 다양한 시스템에서 생성됩니다. 웹 서버, 애플리케이션, 데이터베이스, 운영체제 등 여러 곳에서 로그가 발생하기 때문에, 운영 환경에서는 이러한 로그를 한 곳으로 모아서 관리하는 구조를 사용합니다.

이 과정을 로그 수집(Log Collection)이라고 합니다. 예를 들어 Kubernetes 환경에서는 로그 수집을 위해 Fluent Bit과 같은 로그 수집 도구를 사용하기도 합니다. 또한 AWS EKS에서는 다음과 같은 유형의 로그를 CloudWatch Logs 등으로 수집할 수 있습니다.

• Application Logs는 컨테이너 애플리케이션에서 출력되는 로그입니다. (/var/log/containers)
• Data Plane Logs는 Kubernetes 노드 및 kubelet 관련 로그입니다. (kubelet, kube-proxy, docker)
• Host Logs는 노드 운영체제에서 발생하는 시스템 로그입니다. (/var/log/messages, /var/log/dmesg)

이러한 로그를 통해 클러스터 상태와 애플리케이션 동작을 보다 자세하게 확인할 수 있습니다. 최근 파이브클라우드에서 설계한 AWS EKS 환경에서는 Fluent Bit Add-on을 활용하여, 클러스터에서 실행되는 각 애플리케이션 컨테이너의 stdout 로그를 CloudWatch Logs로 수집하도록 구성했습니다.

이렇게 수집된 로그는 Kubernetes Namespace 기준으로 CloudWatch Log Group이 생성되도록 설정했습니다. 예를 들어 특정 네임스페이스의 로그만 수집하도록 필터를 구성하면, CloudWatch Logs에는 다음과 같은 로그 그룹이 생성됩니다.

/aws/eks/fastfive-cluster/fastfive-app: fastfive-app 네임스페이스의 모든 Pod 로그
/aws/eks/fastfive-cluster/fastfive-web: fastfive-web 네임스페이스의 모든 Pod 로그
/aws/eks/fastfive-cluster/fallback: 필터 매칭 실패 시 기록되는 기본 로그 그룹

각 로그 그룹 내부에서는 Pod 단위로 로그 스트림이 생성됩니다. 예를 들어 fastfive-app 네임스페이스에서 다음과 같은 Pod가 실행 중이라면

fastfive-web-a1234567
fastfive-web-b1234567
fastfive-app-c1234567

CloudWatch Logs에서는 위 Pod 이름을 기준으로 로그 스트림이 생성됩니다. 이러한 구조를 사용하면 특정 서비스에서 발생한 로그를 빠르게 조회할 수 있으며, 서비스 단위의 장애 분석을 수행할 수 있습니다.

또한 필요에 따라 Kubernetes Deployment에 label을 추가하고, Fluent Bit 필터에서 해당 label을 활용하도록 구성하면 로그를 더욱 세분화하여 관리할 수 있습니다. 이처럼 운영 환경에서는 로그를 단순히 기록하는 것에 그치지 않고, 중앙 로그 시스템으로 수집하여 서비스 상태를 분석하고 문제 원인을 파악할 수 있도록 구성합니다.

지금까지 로그가 무엇인지, 그리고 Kubernetes 환경에서 로그가 어떻게 수집되는지에 대해 간단히 알아보았습니다. 실제 운영 환경에서는 서비스 규모와 아키텍처에 따라 로그 수집 방식이나 분석 구조가 조금씩 달라질 수 있습니다.

​만약 Kubernetes, AWS, 로그 수집 및 모니터링 환경 구축과 관련해 고민이 있으시다면 언제든지 파이브클라우드에 문의해 주세요. 다양한 클라우드 운영 경험을 바탕으로 최적의 아키텍처를 함께 고민해 드리겠습니다.

메신저로 명령만 보내면 파일을 정리하고 브라우저를 실행하며 다양한 작업을 스스로 처리하는 모습은 많은 사람들에게 신선한 충격을 주었습니다. 하지만 강력한 편의성만큼이나 보안과 통제 문제에 대한 논쟁도 함께 커지고 있습니다.

이번 글에서는 OpenClaw가 무엇인지, 그리고 왜 기업 환경에서 논쟁이 되고 있는지 핵심 내용을 중심으로 정리해보겠습니다.

1. OpenClaw란 무엇일까?

OpenClaw는 단순히 질문에 답하는 챗봇이 아니라 사용자의 컴퓨터를 대신 조작해 실제 작업을 수행하는 AI Agent입니다. 터미널 실행, 파일 수정, 브라우저 조작과 같은 행동을 AI가 직접 수행할 수 있다는 점이 가장 큰 특징입니다.

기존 AI가 ‘답변 중심’이었다면, OpenClaw는 ‘행동(Action) 중심’이라고 볼 수 있습니다. 사람이 직접 프로그램을 실행하고 클릭하며 입력하던 과정을 AI에게 위임할 수 있는 구조입니다.OpenClaw는 Discord 같은 메신저와 연결해 사용할 수 있습니다. 사용자는 평소처럼 메시지를 보내기만 하면 되고, AI가 해당 명령을 해석해 실제 컴퓨터 작업을 수행합니다.

예를 들어 사용자가 메신저에 “오늘 보고서 폴더 정리하고 압축해서 업로드해줘” 라고 보내면 OpenClaw는 다음과 같은 흐름으로 동작합니다.

• 메시지 내용을 AI가 해석
• 로컬 PC 또는 서버에서 파일 탐색
• 지정된 폴더 정리 및 압축 실행
• 브라우저 또는 API를 통해 업로드 수행완료
• 결과를 메신저로 회신

사용자는 채팅만 했지만 실제로는 파일 작업, 프로그램 실행, 웹 작업까지 자동으로 진행되는 구조입니다. 이러한 특징 때문에 OpenClaw는 메신저 기반으로 AI를 호출할 수 있어 사용 진입장벽이 낮고, 단순 대화를 넘어 실제 업무 자동화가 가능하며, 개인용 AI 비서처럼 커스터마이징이 가능하다 는 점에서 많은 관심을 받고 있습니다. 결국 OpenClaw는 “AI와 대화하는 단계”를 넘어 “AI에게 일을 맡기는 단계”로 넘어가는 흐름을 보여주는 사례라고 볼 수 있습니다.

2. OpenClaw가 문제로 이야기되는 이유

OpenClaw는 단순한 챗봇이 아니라 실제로 행동하는 AI Agent이기 때문에, 편리함과 동시에 여러 현실적인 문제도 함께 제기되고 있습니다.

1) AI가 실제 권한을 가진다는 점

OpenClaw는 사용자의 컴퓨터에서 파일을 열고 수정하거나 삭제하고, 브라우저를 통해 웹 작업을 수행할 수 있습니다. 즉 AI가 단순히 추천하는 것이 아니라 직접 실행 권한을 가지는 구조입니다. 이 경우 다음과 같은 보안 이슈가 발생할 수 있습니다.

• 중요한 파일이 실수로 삭제되는 경우
• 민감한 정보가 외부 서비스로 업로드되는 경우
• API 키나 계정 정보가 노출될 가능성

사람이 직접 작업할 때는 한 번 더 확인할 수 있지만, AI는 명령을 그대로 실행하기 때문에 사고 범위가 커질 수 있습니다.

2) 메신저 기반 자동 실행 구조의 위험

OpenClaw는 Discord 같은 메신저와 연결해 사용하는 경우가 많습니다. 사용자는 메시지를 보내기만 하면 되지만, 이 구조는 보안 관점에서 다음과 같은 우려를 만듭니다.

• 악성 명령 전달 가능성
• 프롬프트 인젝션 등 외부 입력 조작
• 의도하지 않은 자동 행동 실행

즉 메신저 메시지 하나가 실제 시스템 동작으로 이어질 수 있다는 점이 기존 AI와 가장 큰 차이입니다.

3) 플랫폼 입장에서의 고민

AI Agent가 메신저나 웹 서비스를 자동으로 조작하기 시작하면 플랫폼 입장에서도 문제가 발생할 수 있습니다.

• 사람이 아닌 자동화된 행동 증가
• 대량 메시지 전송 또는 자동 클릭
• 계정 오남용 및 정책 우회 가능성

결국 서비스 운영 측면에서는 사용자 행동인지 AI 자동화인지 구분하기 어려워지는 문제가 발생합니다.

3. 이에 대한 기업들의 대응

AI Agent가 실제 서비스를 자동으로 조작하기 시작하면서 글로벌 플랫폼 기업들도 대응에 나서기 시작했습니다.

1) Google 사례

구글은 OpenClaw가 자사 서비스 일부에 접근하는 과정에서 대규모 비정상 사용과 시스템 과부하가 감지됐다고 밝혔습니다. 특히 OpenClaw가 OAuth 방식으로 월정액 AI 계정을 연동해 대량의 토큰을 사용하는 구조가 문제로 지적됐습니다.

원래는 사용량 기반 API로 관리되어야 하는 요청이 Agent 자동화 구조를 통해 우회적으로 대량 실행되면서 1) 서비스 품질 저하, 2) 과도한 리소스 사용, 3) 약관 및 사용 정책 충돌과 같은 문제가 발생했습니다.

이에 따라 구글은 OpenClaw 전체를 금지하기보다는 약관 범위를 벗어난 접근 방식에 제한을 적용하는 방향으로 대응했습니다.

2) 네이버·카카오 사례

국내에서도 AI Agent에 대한 대응이 시작됐습니다. 네이버와 카카오는 임직원을 대상으로 OpenClaw 사용을 제한하거나 금지하는 공지를 발표했습니다.

OpenClaw가 실제 사용자 권한 수준의 동작이 가능하기 때문에 기업 입장에서는 다음과 같은 위험 요소가 발생할 수 있습니다.

• 사내 정보 자산 노출 가능성
• 내부 시스템의 비의도적 조작
• 보안 통제 범위를 벗어난 자동화 실행

이에 따라 네이버와 카카오는 사내망과 업무용 기기에서 OpenClaw 사용을 제한하는 정책을 적용했습니다. 이는 특정 도구를 단순히 금지한 것이 아니라 AI Agent가 기업 내부 환경에 직접 접근하는 시대에 대한 선제적 보안 대응으로 볼 수 있습니다.

4. OpenClaw를 안전하게 사용하는 방법

그렇다면 OpenClaw는 위험하기 때문에 사용하면 안 되는 도구일까요? 반드시 그렇지는 않습니다. 보안 원칙을 지키고 실행 환경을 분리해 운영한다면 충분히 활용할 수 있습니다.

가장 중요한 원칙은 개인 컴퓨터에 직접 설치하지 않는 것입니다. 전용 PC나 별도의 장비, 또는 클라우드 VM 같은 분리된 환경에서 실행하는 방식이 권장됩니다. 이렇게 하면 개인 환경과 AI 실행 환경을 분리할 수 있습니다. 또한 계정과 인증 정보를 분리하는 것도 중요합니다. 개인 이메일이나 업무 계정을 직접 연결하기보다는 AI 전용 계정을 별도로 생성하고, 2FA 코드 자동 접근 기능을 비활성화하는 것이 안전합니다.

권한 관리 역시 중요합니다. 편리하다고 모든 권한을 허용하기보다는 이메일 쓰기나 삭제 권한, 파일 삭제 권한, 캘린더 수정 권한 같은 기능은 제한하고 필요한 최소 권한만 부여하는 것이 좋습니다. 외부 플러그인 사용에도 주의가 필요합니다. 검증되지 않은 기능이나 플러그인은 데이터 외부 전송이나 프롬프트 인젝션 같은 위험이 존재할 수 있기 때문에 출처가 명확하지 않은 기능은 설치하지 않는 것이 좋습니다.

마지막으로 OpenClaw 인스턴스를 인터넷에 직접 노출하지 않는 것이 중요합니다. 로컬 환경이나 VPN 환경에서 실행하고, 방화벽과 접근 제어를 적용하는 것이 기본적인 보안 원칙입니다.

OpenClaw 사례는 AI 에이전트 기술이 어디까지 발전했는지를 보여주는 동시에, 기업 환경에서는 보안과 통제 설계가 반드시 필요하다는 점을 보여주는 사례이기도 합니다.

AI가 실제 시스템을 조작하는 단계로 넘어간 만큼 단순히 도구를 도입하는 것만으로는 충분하지 않습니다. 어떤 환경에서 실행할 것인지, 어떤 권한을 부여할 것인지, 어떤 방식으로 관리할 것인지까지 함께 설계하는 것이 중요합니다.

AI 도입이나 클라우드 환경 설계·운영에 대한 고민이 있으시다면 파이브클라우드 전문가와 상담을 통해 조직 환경에 맞는 전략을 확인해 보시기 바랍니다.

‘질문하면 답을 주는’ 수동적인 챗봇의 시대는 끝나고, 2026년 현재는 “이것 좀 처리해 줘”라는 목표만 전달하면 AI가 스스로 작업 계획을 세우고 필요한 툴을 찾아 실행까지 수행하는 에이전틱 AI(Agentic AI) 가 등장했습니다. 이 변화로 인해 실무자들의 고민도 달라졌습니다. 이제 중요한 질문은 “어떤 AI가 가장 똑똑한가?”가 아니라 “내 업무에 가장 적합한 AI는 무엇인가?” 입니다.

AI 모델마다 강점과 역할이 다른 만큼, 업무의 성격에 맞는 AI를 선택하는 것이 중요합니다. 이번 글에서는 실무 환경에서 활용되는 주요 AI 모델의 특징과 활용 전략을 정리했습니다.

1. OpenAI GPT-5.2 : 기획 단계에서 가장 강력한 브레인스토밍 파트너

초기 아이디어 발굴이나 브레인스토밍이 필요한 상황에서는 GPT-5.2가 특히 강력한 도구가 됩니다. 아직 정리되지 않은 아이디어나 모호한 질문 속에서도 사용자의 의도를 파악하고 구조화된 초안을 빠르게 만들어낼 수 있기 때문입니다.

예를 들어 “요즘 20대 초반이 좋아할 만한 친환경 팝업스토어 기획안을 작성해 달라”는 요청만으로도 타겟 페르소나 설정, 예산 분배, 시간대별 운영 시나리오 등을 포함한 기획 초안을 빠르게 생성합니다. 또한 다양한 플러그인 생태계를 통해 텍스트 생성뿐 아니라 디자인 템플릿 제작 등 여러 작업을 동시에 수행할 수 있다는 점도 장점입니다.

다만 수치나 통계처럼 정확성이 중요한 영역에서는 환각 가능성을 고려해 결과를 검증하는 과정이 필요합니다. 새로운 프로젝트 방향을 설정할 때 GPT를 비판적인 리뷰어 역할로 활용하는 것도 좋은 방법입니다. 예를 들어 “작성한 기획안에서 논리적으로 부족한 부분을 지적해 달라”고 요청하면 스스로 놓치기 쉬운 맹점을 확인할 수 있습니다.

구글 워크스페이스를 사용하는 기업 고객과 미팅을 진행하다 보면 자주 듣는 고민입니다. 큰맘 먹고 도입했지만, 정작 직원들이 단순 번역이나 이메일 작성, 구글링을 대체하는 용도로만 쓰고 있다면 경영진 입장에서는 의문이 들 수밖에 없습니다.

이제 AI는 단순히 신기한 기능을 제공하는 ‘비서’를 넘어섰습니다. 도입 여부보다 중요한 것은 AI를 조직의 업무 프로세스 안에 얼마나 구조적으로 내재화했는가입니다.

2026년 현재, AI는 더 이상 선택이 아닌 비용 절감과 업무 효율을 수치로 증명해야 하는 생산성 인프라입니다. 이번 글에서는 Gemini를 단순한 도구를 넘어, 조직의 전략적 자산으로 운영하는 3가지 실전 로드맵을 정리해 드립니다.

1. 우리 회사 전용 지식 엔진 구축: ‘Gems’ 활용 전략

많은 기업이 Gemini를 활용할 때 범용적인 챗봇 기능에만 의존합니다. 하지만 진정한 생산성 혁신은 외부의 일반 정보가 아니라 '우리 회사의 데이터’와 결합할 때 시작됩니다.

파편화된 사내 데이터를 하나의 지능으로

회사의 핵심 자산은 구글 드라이브 곳곳에 흩어져 있는 제안서, 매뉴얼, 기획안들입니다. 'Gems' 기능을 활용해 이 폴더들을 연동해 보세요. 외부 데이터가 아닌, 오직 우리 회사의 성공 사례와 규정만을 바탕으로 답변하는 '사내 전문가'가 탄생합니다.

부서별 맞춤형 AI 설계 

Gemini는 전사 공용 도구가 아니라, 부서별 목적에 맞게 설계할 때 효과가 극대화됩니다.

• HR 전용 봇: "입사 3년 차 리프레시 휴가 규정 알려줘" 같은 반복적인 문의에 인사팀이 일일이 대응할 필요가 없습니다.
• 세일즈 가이드 봇: 신입 사원이 과거 미팅 로그와 성공적인 제안서를 분석해 즉시 전략 초안을 도출하도록 돕습니다.

2. 데이터 분석의 속도 혁신: Google Sheets와 Gemini

데이터 기반 의사결정은 중요하지만, 실제로 분석을 요청하고 결과를 공유받기까지는 꽤 많은 시간이 소요됩니다. Gemini가 탑재된 구글 스프레드시트는 이 과정을 '초 단위'로 단축합니다.

자연어로 데이터와 대화하기

이제 복잡한 함수나 SQL을 몰라도 분석이 가능합니다. “지난 분기 매출 중 전년 대비 10% 이상 감소한 지역만 정리해 줘”라고 입력하면, Gemini가 데이터를 분석해 시각화 차트까지 자동으로 생성합니다. Connected Sheets를 활용하면 수백만 행의 대규모 데이터셋도 가뿐하게 처리할 수 있습니다.

회의 중 즉시 내리는 의사결정

회의 도중 돌발 질문이 나와도 별도의 리포트를 기다릴 필요가 없습니다. 그 자리에서 Gemini에게 질문을 던지고 도출된 분석 결과를 보며 바로 논의를 이어가세요. 분석 대기 시간을 없애는 것만으로도 조직의 실행 속도는 2배 이상 빨라집니다.

3. Google Vids로 업무 커뮤니케이션의 전환

여전히 많은 업무 소통이 텍스트 중심으로 이뤄지지만, 반복되는 보고나 교육 영역에서는 영상 기반의 전달 방식이 훨씬 효과적입니다.

보고서의 구조 재설계

A4 용지 몇 장 분량의 텍스트 보고서를 Gemini 기반 스토리보드로 변환해 짧은 영상으로 제작해 보세요. Google Vids를 활용해 핵심 지표와 전략을 시각적으로 공유하면 정보의 이해도와 전달 효율이 압도적으로 개선됩니다.

교육 콘텐츠의 표준화와 자동화

신규 입사자 온보딩이나 솔루션 가이드를 매번 대면으로 설명하고 계신가요? 영상으로 제작된 튜토리얼은 한 번의 제작으로 수많은 사원에게 동일한 퀄리티의 교육을 제공합니다. 이는 교육 담당자의 리소스를 아끼고 업무 표준화를 이루는 핵심 전략입니다.

Gemini는 단순 라이선스 구매만으로 효과가 나타나는 도구가 아닙니다. 어떤 데이터와 연결할 것인지, 어떤 업무에 적용할 것인지, 누가 어떻게 활용할 것인지에 대한 전략이 필요합니다.

결국 AI는 도입이 아니라 운영이 핵심입니다. 조직의 업무 프로세스에 맞게 Gemini를 설계하고 적용할 때, 생산성 향상은 비용 대비 효과로 연결될 수 있습니다.

현재 우리 조직의 라이선스 구조와 업무 흐름이 Gemini를 제대로 활용하고 있는지 점검이 필요하신가요? 파이브클라우드는 고객사의 환경에 맞는 최적의 Gemini 적용 전략을 진단하고 제안해 드립니다. 전문가와의 상담을 통해 우리 조직에 딱 맞는 AI 로드맵을 그려보시기 바랍니다.

이 글에서는 복잡한 기술 설명은 최소화하고, 데이터베이스가 왜 여러 유형으로 나뉘는지, 어떤 상황에서 어떤 DB를 선택해야 하는지, 그리고 AWS에서는 각 유형이 어떤 서비스로 제공되는지를 중심으로 실무 관점에서 정리했습니다.

DB 선택이나 구축, 마이그레이션을 고민하고 있는 기업이라면, 이 글이 기본적인 판단 기준이 되기를 바랍니다.

1. 데이터베이스는 왜 여러 종류로 나뉘었을까?

데이터베이스가 다양한 형태로 발전한 이유는 단순합니다. 모든 데이터를 같은 방식으로 저장하는 것은 비효율적이기 때문입니다. 예를 들어 다음과 같은 데이터가 있다고 가정해보겠습니다.

• 회원정보처럼 정확성이 중요한 데이터
• 실시간으로 쌓이는 로그·이벤트 데이터
• 접속 속도가 중요한 세션 정보
• 대량 데이터를 모아 분석하는 통계·리포트용 데이터

이 모든 데이터를 하나의 데이터베이스에서 처리하려 하면, 어떤 데이터는 느려지고, 어떤 데이터는 관리가 어려워집니다. 그래서 데이터베이스는 어떤 데이터를, 어떤 방식으로, 어떤 목적에 사용할 것인가에 따라 점점 전문화된 형태로 나뉘게 되었습니다. DB를 선택할 때 “가장 유명한 DB”를 기준으로 삼기보다는, 다음과 같은 질문이 더 중요합니다.

• 이 데이터는 정확성이 중요한가?
• 응답 속도가 가장 중요한가?
• 데이터 구조가 자주 바뀌는가?
• 트래픽이 급격히 증가할 가능성이 있는가?
• 장애 발생 시 영향도는 얼마나 큰가?

이 기준에 따라 선택해야 할 데이터베이스 유형이 달라집니다.

2. 실무에서 많이 사용하는 데이터베이스 유형

1) 관계형 데이터베이스 (RDB)

가장 전통적이고 널리 사용되는 데이터베이스 유형입니다. 엑셀처럼 행과 열 구조로 데이터를 저장하며, 데이터 간 관계를 명확하게 관리할 수 있다는 점이 특징입니다. 주문, 결제, 회원정보처럼 오류가 허용되지 않는 데이터, 정확성과 일관성이 중요한 업무 환경에 적합합니다. 즉, “정확함”이 핵심인 경우에 가장 잘 맞는 데이터베이스입니다.

2) NoSQL 데이터베이스

고정된 테이블 구조를 강제하지 않고, 데이터 구조를 유연하게 정의할 수 있는 데이터베이스입니다. 데이터 구조가 자주 변경되거나, 대규모 데이터를 빠르게 처리해야 하는 경우, 트래픽이 급격히 증가할 가능성이 있는 서비스 환경에서 강점을 보입니다. 확장성과 유연성이 중요한 경우에 적합한 유형입니다.

3) 인메모리 데이터베이스

데이터를 디스크가 아닌 메모리(RAM)에 저장해 매우 빠른 응답 속도를 제공합니다. 로그인 세션, 캐시, 임시 데이터 처리처럼 속도가 중요한 영역이나, 메인 데이터베이스의 부하를 줄이고 싶은 경우에 활용됩니다. 즉, “지연 시간 최소화”가 목표인 역할을 담당합니다.

4) 분석용 데이터베이스 (데이터 웨어하우스)

서비스 운영이 아닌, 데이터를 모아 분석하는 데 특화된 데이터베이스입니다. 로그와 이력 데이터를 집계하거나, 통계·리포트·BI 분석을 수행해야 하는 경우, 운영 DB와 분석 환경을 분리하고 싶을 때 적합합니다. 분석과 의사결정 지원이 목적일 때 선택됩니다.

정리하면, 데이터의 정확성이 가장 중요하다면 관계형 데이터베이스가 적합하고, 확장성과 구조의 유연성이 필요하다면 NoSQL이 적합합니다. 응답 속도가 핵심이라면 인메모리 데이터베이스가 활용되며, 데이터를 모아 분석하고 인사이트를 도출하는 것이 목적이라면 데이터 웨어하우스를 고려하게 됩니다.

다만 실제 서비스 환경에서는 이 중 하나만 사용하는 경우는 드뭅니다. 대부분의 시스템은 여러 유형을 조합해 설계하며, 각 데이터베이스가 서로 다른 역할을 분담하도록 구성됩니다.

3. 데이터베이스 유형별 AWS 서비스 살펴보기

앞서 살펴본 데이터베이스 유형을 AWS 서비스에 대입해보겠습니다. AWS는 각 유형에 맞는 관리형 데이터베이스 서비스를 제공하며, 목적에 따라 이를 조합해 설계할 수 있도록 구성되어 있습니다.

1) 관계형 데이터베이스 – Amazon RDS, Amazon Aurora

관계형 데이터베이스 영역에서 대표 서비스인 Amazon RDS와 Amazon Aurora는 금융, 주문, 결제 시스템처럼 트랜잭션의 정확성과 데이터 무결성이 중요한 환경에 적합합니다.

• Amazon RDS
  • MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 등 다양한 엔진을 지원하며, 기존 온프레미스 DB와의 호환성이 높습니다. Multi-AZ 구성을 통해 가용성을 확보할 수 있고, 비교적 단순한 구조로 안정적인 운영이 가능합니다.
• Amazon Aurora
  • MySQL·PostgreSQL과 호환되며, 스토리지와 컴퓨팅을 분리한 구조를 기반으로 더 높은 성능과 확장성을 제공합니다. 3개 AZ에 걸친 6중 복제 스토리지 구조를 사용하며, 스토리지는 자동으로 확장됩니다. 빠른 Failover와 Serverless 옵션도 제공해 트래픽 변동이 큰 환경에 적합합니다.

2) NoSQL 데이터베이스 – Amazon DynamoDB, Amazon DocumentDB

NoSQL 영역에서 대표 서비스인 Amazon DynamoDB와 Amazon DocumentDB는 스키마 유연성과 수평 확장에 강점이 있으며, 대규모 트래픽 환경에 적합합니다.

• Amazon DynamoDB
  • 완전 서버리스 구조로 인스턴스를 관리할 필요가 없으며, 자동 확장과 밀리초 단위 응답을 제공합니다. 글로벌 테이블을 통해 Multi-Region 복제가 가능하며, TTL, Streams, DAX 같은 기능으로 캐시와 이벤트 기반 아키텍처를 구성할 수 있습니다. Key-Value 기반 설계를 사용하며, 조인을 지원하지 않기 때문에 비정규화 설계를 고려해야 합니다.
• Amazon DocumentDB
  • MongoDB API와 호환되는 문서 기반 데이터베이스입니다. JSON 형태로 데이터를 저장하며, 인스턴스 기반구조로 운영됩니다. 스토리지가 자동 확장되고, 읽기 복제본을 통해 확장성을 확보할 수 있습니다.

3) 인메모리 데이터베이스 – Amazon ElastiCache

인메모리 데이터베이스 대표 서비스인 Amazon ElastiCache는 Redis와 Memcached를 지원합니다. 초저지연 응답이 필요한 캐시, 실시간 랭킹, 세션 관리에 주로 활용됩니다.

• ElastiCache for Redis
  • 다양한 자료구조를 지원하며, TTL 설정과 Pub/Sub 기능을 제공합니다. 복제와 Multi-AZ 구성을 지원하고, 장애 시 자동 Failover가 가능하며, 필요에 따라 데이터 영속성 옵션(RDB/AOF)을 설정할 수 있습니다. 
• ElastiCache for Memcached
  • 단순 Key-Value 구조를 기반으로 멀티스레드 환경에서 빠른 성능을 제공합니다. 다만 복제나 영속성 기능은 제공하지 않아 단순 캐싱 목적에 적합합니다.

4) 분석용 데이터베이스 – Amazon Redshift

분석 목적의 데이터베이스는 Amazon Redshift가 대표적입니다. 대규모 집계 쿼리와 BI 리포트, 데이터 분석 환경에 적합하며, 운영 DB와 분리된 분석 전용 환경을 구성할 때 활용됩니다.

• Redshift
  • 컬럼 기반 저장 방식을 사용하며, 여러 노드가 병렬로 데이터를 처리하는 MPP(Massively Parallel Processing) 구조를 갖추고 있습니다. 스토리지와 컴퓨팅을 분리해 확장할 수 있으며, Amazon S3와 연동해 대용량 데이터를 효율적으로 처리할 수 있습니다.

지금까지 데이터베이스 유형별 특징과 AWS에서 제공하는 관리형 서비스에 대해 살펴보았습니다. 중요한 점은 각 데이터베이스가 서로 경쟁하는 관계가 아니라, 목적에 따라 함께 설계되어야 하는 구성 요소라는 점입니다.

DB 설계나 마이그레이션을 고민하고 계시다면, 현재 환경과 목표를 기준으로 어떤 조합이 적절한지 검토하는 과정이 필요합니다. 파이브클라우드는 이러한 설계 방향을 함께 고민하고 구체화해 드립니다.

실제로 일부 대기업이 사내에서 일반 생성형 AI 사용을 제한했다는 소식을 한 번쯤은 들어보셨을 텐데요. 하지만 Google Workspace용 제미나이는 개인이 무료로 사용하는 AI와는 다르다는 점을 알고 계셨나요? 기업용 서비스로 제공되는 만큼, 적용되는 보안 정책과 데이터 보호 기준이 역시 개인용 서비스와는 다르게 설계되어 있습니다. 

Q1. 우리 회사 데이터로 AI를 학습시키나요?

결론부터 말씀드리면, 아니요. 기본적으로 학습하지 않습니다. 다만, 사용 중인 요금제에 따라 확인이 필요한 경우는 있습니다. 가장 많이 오해하시는 부분이 “직원이 입력한 프롬프트나 업로드한 문서를 구글이 가져가 AI 학습에 활용하는 것 아니냐”는 점입니다.

Google Workspace의 핵심 서비스로 제공되는 제미나이는 다음과 같은 원칙을 따릅니다. 우선, 사용자가 작성한 이메일, 문서, 채팅 내용은 구글의 기본 AI 모델을 학습시키는 데 사용되지 않습니다. 또한 데이터의 소유권은 구글이 아닌 고객, 즉 기업에 있으며 광고 목적이나 외부 활용에도 사용되지 않습니다. 즉, 회사 내부 문서를 제미나이에게 요약시키거나 분석하더라도 그 내용이 다른 기업이나 외부 사용자에게 노출될 가능성은 없습니다.

Q2. 구글 직원이 제미나이 대화 내용을 볼 수 있나요?

아니요. 사람에 의한 검토는 없습니다.(정책 위반 감지 등 일부 예외 상황은 제외됩니다.) 일부 무료 AI 서비스의 경우, 서비스 품질 개선을 목적으로 엔지니어가 대화 내용을 직접 검토하는 경우가 있습니다. 이 과정에서 보안 우려가 발생할 수 있죠.

하지만 기업용 제미나이는 다릅니다. 구글 엔지니어는 고객의 프롬프트나 결과 데이터를 열람하지 않으며, 모든 데이터는 전송 중이거나 저장된 상태 모두에서 강력한 암호화가 적용됩니다. 또한 ISO/IEC 27001, SOC 2 등 국제적으로 검증된 보안 인증 기준을 충족해 기업 환경에서 요구되는 보안·감사·통제 요건을 함께 만족합니다.

Q3. 제미나이가 권한 없는 문서까지 읽을 수 있나요?

불가능합니다. 제미나이는 기존 Google Workspace의 문서 접근 권한 체계를 그대로 따릅니다. 제미나이는 회사 전체 문서를 자유롭게 읽는 AI가 아니라, 현재 질문한 사용자 본인이 접근할 수 있는 문서 범위 안에서만 답변을 제공합니다.

예를 들어, 인사팀장이 인사 관련 문서 요약을 요청할 경우, 해당 문서에 대한 열람 또는 편집 권한이 있다면 제미나이가 정상적으로 답변합니다. 반대로 영업팀 직원이 같은 인사 문서를 요청할 경우에는 접근 권한이 없기 때문에 “관련 정보를 찾을 수 없거나 접근 권한이 없습니다”라는 응답을 받게 됩니다.

즉, 제미나이는 회사 전체 문서에 접근하는 구조가 아니라, 현재 사용자에게 부여된 권한 범위 내에서만 정보를 활용합니다.

꼭 확인해야 할 마지막 포인트

그렇다면 이런 질문이 생깁니다. “모든 Google 계정에서 제미나이를 사용해도 안전할까요?” 정답은 “요금제에 따라 확인이 필요합니다.”입니다. 구글의 보안 정책에 따르면, 제미나이가 핵심 서비스(Core Service)로 분류되는 요금제에서만 앞서 설명한 수준의 데이터 보호 정책이 적용됩니다.

✅사용 전 요금제 확인이 필요한 경우

아래 요금제에서는 제미나이가 Google Workspace의 핵심 서비스가 아닌 ‘추가 서비스’ 형태로 제공됩니다. 이 경우, 이용 약관에 따라 서비스 개선 목적의 데이터 활용 가능성이 존재할 수 있어 기업 환경에서 사용하기 전 반드시 확인이 필요합니다.

해당 요금제는 다음과 같습니다.

• 구버전 G Suite (Basic / Business)
• Essentials Starter
• Workspace Individual (개인사업자)
• Cloud Identity
• 무료 개인 계정(@gmail.com)

이 요금제들을 사용하는 경우, 입력한 데이터가 AI 학습에 사용되지 않는다고 단정할 수 없기 때문에 기업 내부 정보나 민감한 데이터를 다룰 때는 주의가 필요합니다.

✅기업 환경에서도 안전하게 사용 가능한 경우

반면, 아래 요금제에서는 제미나이가 Google Workspace의 ‘핵심 서비스(Core Service)’로 포함되어 제공됩니다. 이 경우에는 데이터가 AI 학습에 사용되지 않으며, 기업 데이터 보호 정책이 적용됩니다.

해당 요금제는 다음과 같습니다.

• Google Workspace Business (Starter / Standard / Plus)
• Enterprise 전 요금제
• Frontline
• Nonprofits
• Essentials

이들 요금제에서는 엔터프라이즈급 보안 정책과 세분화된 권한 관리(ACL)가 함께 적용되어, 기업 환경에서도 안심하고 제미나이를 활용할 수 있습니다.

보안은 지키고, 생산성은 높이세요

정리하면, Google Workspace Business 또는 Enterprise 요금제를 사용 중인 기업이라면 제미나이는 안심하고 활용할 수 있는 기업용 AI 도구입니다. 중요한 것은 “제미나이가 안전한가?”보다 “우리 회사가 어떤 요금제와 보안 환경에서 사용하고 있는가?”를 정확히 파악하는 것입니다.

파이브클라우드는 기업의 라이선스 현황과 보안 요구사항을 함께 진단해, 가장 안전한 방식으로 제미나이를 도입하고 실제 업무에 효과적으로 활용할 수 있도록 지원합니다. 보안은 지키면서 업무 생산성은 확실하게 높이고 싶다면, 파이브클라우드와 함께 시작해보세요.

기업에서 가장 많이 비교하는 선택지는 Google Workspace와 Microsoft 365로, 두 솔루션 모두 전 세계적으로 검증된 생산성 도구지만 지향하는 업무 방식에는 분명한 차이가 있습니다. 중요한 점은 “어떤 툴이 더 좋은가”가 아니라 “우리 조직의 업무 방식에 어떤 툴이 더 잘 맞는가”입니다.

이번 글에서는 파이브클라우드가 다양한 기업의 도입을 컨설팅하며 정리한 실무 관점에서의 Google Workspace와 Microsoft 365의 차이와 선택 기준을 소개합니다.

‘속도와 공유’가 중요한 조직이라면, Google Workspace

Google Workspace는 웹 브라우저 자체가 업무 공간이 되는 구조를 기반으로 합니다. 파일을 주고받기보다는 링크(URL)로 공유하고 함께 작업하는 방식이 중심이죠. 이런 구조는 협업 속도와 실시간 공유가 중요한 조직에 강점으로 작용합니다.

Google Sheets

여러 명이 동시에 접속해도 끊김 없이 편집이 가능해 데이터 취합과 실시간 공유에 매우 유리합니다. 다른 시트의 데이터를 실시간으로 불러오는 함수 활용도 쉬워 팀 간 협업 효율을 크게 높일 수 있습니다.

→ 마케팅팀, 기획팀처럼 현황 공유와 수시 수정이 잦은 조직에 적합합니다.

Gmail

강력한 검색 기능과 스팸 필터가 가장 큰 장점입니다.수년 전 메일도 키워드 하나로 빠르게 찾을 수 있고, 폴더 대신 ‘라벨’ 기반 관리로 메일 분류와 검색 부담을 줄일 수 있습니다.

Google Drive

인터넷만 연결되면 별도 장비나 VPN 없이 어디서든 업무가 가능합니다. 구글의 AI 기능을 활용해 파일을 맥락 기반으로 추천해 주기 때 에 자료 탐색에 드는 시간도 줄어듭니다. 사용자당 넉넉한 저장 공간이 제공되는 점도 장점입니다.

Google Calendar

팀원들의 일정을 한 화면에서 겹쳐 볼 수 있어 공통으로 비어 있는 시간을 빠르게 찾을 수 있습니다. 일정 생성과 동시에 Google Meet 링크가 자동 생성돼 화상 회의 준비도 간편합니다.

→ 잦은 팀 미팅, 원격·재택 근무 비중이 높은 조직에 적합합니다.

💡 실무 팁: Gmail 우측 사이드바의 Keep, Tasks를 활용하면 메일을 바로 할 일이나 메모로 전환해 업무 누락 없이 관리할 수 있습니다.

‘정교함과 완성도’를 중시한다면, Microsoft 365

Microsoft 365의 핵심은 수십 년간 축적된 설치형 데스크톱 앱의 강력한 성능입니다. 정교한 문서 작업과 대용량 데이터 처리가 필요한 업무에서 여전히 강력한 경쟁력을 갖고 있습니다.

Excel

대용량 데이터 처리와 분석에서는 여전히 업계 표준입니다. 복잡한 피벗 테이블, 매크로(VBA), 고급 수식 활용이 필요한 재무·회계·데이터 분석 업무에서 압도적인 퍼포먼스를 제공합니다.

→ 재무팀, 인사팀, 데이터 분석 중심 조직에 적합합니다.

Outlook

강력한 규칙(Rule) 기능과 폴더 기반 메일 관리가 특징입니다. 메일 자동 분류, 오프라인 작업 지원 등 체계적인 업무 관리를 선호하는 사용자에게 높은 만족도를 줍니다.

Outlook Calendar

이메일과 일정의 긴밀한 연동이 강점입니다. 메일을 드래그해 바로 회의나 할 일로 등록할 수 있고, 필수·선택 참석자 구분, 회의실 예약 등 공식적인 기업 환경에 맞춘 세밀한 설정이 가능합니다.

→ 외부 미팅이 잦거나 여러 이해관계자가 얽힌 프로젝트를 관리하는 관리자·PM에게 적합합니다.

PowerPoint

제안서나 발표 자료의 완성도가 중요하다면 PPT는 여전히 강력한 선택지입니다. 디자인 자유도, 애니메이션, 인쇄 정확성 측면에서 웹 기반 도구보다 안정적인 결과물을 제공합니다.

💡 실무 팁: SharePoint를 활용하면 전사 인트라넷 구축과 문서 권한 관리까지 기업 데이터를 하나의 자산으로 통합 관리할 수 있습니다.

한눈에 정리하는 실무 선택 기준

• Google Workspace: 여러 명이 동시에 협업하며 빠르게 결과물을 만들어야 하는 조직에 적합합니다. 링크 기반 공유와 실시간 협업이 중심이 되는 마케팅, 영업, IT 개발, 스타트업 전사 환경에서 강점을 발휘합니다.
• Microsoft 365: 개인이 책임지고 완성도 높은 문서를 만들어야 하는 업무에 적합합니다. 정교한 데이터 관리와 공식적인 문서 작업이 중요한 재무, 회계, 경영지원, 전략기획 조직에 잘 맞습니다.

우리 회사의 ‘업무 DNA’에 맞춰 선택하세요

“무엇이 더 좋은가?”보다 중요한 질문은 “우리 직원들은 어떻게 일하고 있는가?”입니다.

최근에는 전사적으로는 Google Workspace를 도입해 협업 효율을 높이고, 재무·회계 등 일부 부서에는 Microsoft 365를 병행하는
하이브리드 방식을 선택하는 기업도 늘고 있습니다.

파이브클라우드는 단순한 라이선스 판매가 아니라, 기업의 업무 프로세스를 진단하고 조직에 가장 잘 맞는 오피스 환경을 함께 설계합니다. 우리 회사에 딱 맞는 오피스 툴 선택, 파이브클라우드와 함께라면 훨씬 명확해집니다.

누가 언제 어떤 의도로 설정을 변경했는지 이력이 명확히 남지 않고, 같은 환경을 다시 구성하는 것도 점점 어려워졌죠. 장애가 발생했을 때도 정확히 어디가 달라졌는지를 추적하는 데 불필요한 시간이 소요되기 시작하죠. 특히 개발·스테이징·운영 환경을 동일한 구조로 유지해야 하는 상황에서는 이 문제가 더 쉽게 드러납니다. 보안 그룹 규칙 한 줄, 라우팅 테이블 한 항목, IAM 권한 하나만 달라져도 운영 환경에서만 문제가 발생하는 경우가 적지 않습니다. 이런 차이가 쌓일수록 변경 작업은 점점 더 조심스러워지고, 속도는 느려지며, 검증과 커뮤니케이션에 드는 비용은 커지게 되죠.

이러한 배경에서 등장한 것이 IaC(Infrastructure as Code)입니다. IaC가 무엇인지, 어떤 변화를 가져오는지, 그리고 대표 도구 Terraform을 활용한 실제 적용 사례까지 함께 살펴보겠습니다.

 IaC(Infrastructure as Code)란?

IaC(Infrastructure as Code)는 말 그대로 클라우드 인프라를 코드로 정의하고 관리하는 방식입니다.

콘솔에서 하나씩 클릭해 리소스를 만드는 대신, VPC, 서브넷, 보안 그룹, 로드밸런서, 서버 같은 구성 요소를 코드로 작성하고 그 코드를 기준으로 인프라를 생성하고 변경합니다.

조금 더 쉽게 비유하면, IaC는 인프라를 레시피처럼 만들어 두는 일에 가깝습니다. 레시피가 있으면 누가 요리하더라도 결과가 크게 달라지지 않듯, IaC를 사용하면 어떤 환경을 어떤 기준으로 구성했는지가 코드로 남고 같은 레시피를 적용해 개발·스테이징·운영 환경을 보다 일관되게 유지할 수 있습니다.

그렇다면 IaC를 도입하면 실제 운영 방식에는 어떤 변화가 생길까요?

IaC가 가져오는 운영 방식의 변화

IaC를 도입하면 인프라를 만드는 방식뿐만 아니라, 클라우드 인프라를 운영하고 변경하는 문화 자체가 달라집니다. 특히 다음과 같은 변화가 현장에서 크게 체감됩니다.

1. 변경이 ‘작업’이 아니라 ‘프로세스’가 됩니다

인프라 변경이 코드 변경으로 남기 때문에 리뷰 → 승인 → 적용의 흐름이 자연스럽게 만들어집니다. 그 결과, 변경은 개인의 손기술이 아니라 팀 단위의 표준 절차로 관리되며, 실수나 누락을 사전에 걸러낼 수 있습니다.

2. 무엇이 바뀌었는지 추적하기 쉬워집니다

문제가 발생했을 때 가장 어려운 부분은 어디가 어떻게 달라졌는지를 찾는 과정입니다. IaC 환경에서는 변경 이력이 코드로 남아 변경 원인 추적이 빨라지고, 감사나 점검 시에도 현재 설정이 왜 이렇게 되었는지를 설명하기가 훨씬 수월해집니다.

3. 운영 표준을 팀 단위로 유지할 수 있습니다

팀이나 프로젝트가 늘어날수록 인프라 품질은 흔들리기 쉽습니다. IaC 환경에서는 자주 사용하는 구성을 표준 템플릿이나 모듈로 관리하면서, 신규 프로젝트에도 동일한 기준을 적용하기가 쉬워집니다. 개인이 잘하는 방식이 아니라, 조직의 표준이 그대로 확장되는 구조입니다.

4. 협업 비용과 인수인계 부담이 줄어듭니다

구성이 코드로 정리되어 있으면 신규 담당자가 합류하더라도 추측이 아닌 코드 기준으로 인프라 구조를 빠르게 파악할 수 있습니다. 설명과 인수인계에 드는 시간도 줄어들고, 운영 지식이 특정 담당자에게만 쌓이는 문제도 완화됩니다.

5. 확장과 복구가 더 예측 가능해집니다

규모 확장이나 장애 상황에서 중요한 것은 다시 동일한 기준으로 환경을 정리할 수 있는지 여부입니다. IaC 기반 환경에서는 변경 단위와 기준이 명확해 확장과 복구 작업을 보다 예측 가능하게 수행할 수 있고, 운영 리스크를 낮출 수 있습니다.

IaC를 구현하는 도구, Terraform

Terraform은 IaC(Infrastructure as Code)를 구현하기 위한 대표적인 도구 중 하나입니다. IaC가 클라우드 인프라를 코드로 관리하는 방식이라면, Terraform은 그 방식을 실무에서 적용할 수 있도록 인프라를 코드로 만들고 변경하는 과정을 표준화해주는 도구이죠.

Terraform의 흐름은 크게 세 단계로 나뉩니다.

• Define: 원하는 인프라 상태를 코드로 정의
• Plan: 변경 사항을 적용 전에 미리 확인
• Apply: 검증된 변경만 실제 환경에 반영

이 과정 덕분에 클릭 기반 작업에서 자주 발생하던 누락이나 환경 편차를 효과적으로 줄일 수 있습니다. Terraform이 많이 활용되는 이유 중 하나는 모듈 기반 구조입니다.  VPC, 보안 기준, 로깅이나 모니터링 같은 구성을 모듈로 만들어 두면, 프로젝트가 늘어나더라도 같은 기준을 반복 적용할 수 있습니다.

또한 Terraform은 현재 인프라 상태를 관리하는 state 개념을 통해 팀 단위 협업도 안정적으로 지원합니다. 상태 정보를 원격 백엔드로 관리하고 잠금 구조를 함께 적용하면, 여러 사람이 동시에 변경 작업을 진행하더라도 충돌을 방지할 수 있습니다.

파이브클라우드 고객 사례

파이브클라우드는 최근 한 고객사의 신규 클라우드 인프라 구축 프로젝트를 진행하며 IaC 기반 운영 체계를 함께 설계했습니다.

해당 고객사는 기존에 EC2 기반으로 컨테이너 서비스를 직접 운영하고 있었지만, 확장성과 운영 표준화를 위해 EKS(관리형 Kubernetes 서비스) 기반으로 전환을 결정했습니다. 이번 프로젝트의 핵심은 단순히 실행 환경을 바꾸는 것이 아니었습니다. 전환 이후에도 확장과 변경을 항상 같은 방식으로 반복할 수 있도록 코드 기반 운영 구조를 마련하는 것이었습니다.

이를 위해 Terraform을 활용해 인프라를 모듈화된 구조로 설계하고 다음과 같은 구성 요소를 코드로 표준화했습니다.

• 네트워크: 가상 네트워크, 외부·내부 구간, 통신 경로
• 컴퓨팅: 관리용 접근 환경, EKS 클러스터
• 보안: 서비스별 최소 권한 분리
• 데이터베이스: RDS 구성

배포는 ① 네트워크 → ② 공통 기반 → ③ 환경별 구성 단계로 나누어 진행했습니다. 이 구조를 통해 환경이 달라져도 같은 템플릿을 그대로 적용할 수 있고, 변경 시에도 어디가 영향을 받는지 명확히 파악할 수 있게 되었습니다. 덕분에 검토와 확인이 쉬워지고, 문제가 생겨도 원인을 빠르게 좁혀 안정적으로 운영할 수 있게 되었죠.

EKS 영역에서는 운영 요건에 맞춰 서버 설정을 표준화하고, 서비스가 필요한 권한만 갖도록 권한을 분리(최소 권한 원칙)해 보안과 운영 안정성을 함께 고려했습니다. 또한 EKS 운영에 필요한 구성요소들은 버전까지 코드로 관리해, 운영 중에도 일관된 기준으로 변경할 수 있도록 정리했습니다. 데이터베이스는 삭제 사고를 막는 안전장치와, 삭제 시 최종 백업이 남도록 하는 정책을 반영해 운영 단계에서도 기준이 코드로 유지되게 했습니다.

결과적으로 고객사는 EC2 기반 운영에서 EKS로 전환하는 과정에서 인프라 구성이 문서나 사람의 기억이 아니라 코드로 표준화되었고, 이후 확장과 변경도 예측 가능하고 반복 가능한 방식으로 이어갈 수 있는 기반을 확보했습니다. 한 번 구축하고 끝이 아니라, 운영 단계에서도 같은 기준을 유지할 수 있는 장기적인 운영 체계를 마련했다는 점이 이번 프로젝트의 핵심 성과였습니다.

결국 IaC는 인프라를 더 빠르게 만드는 방법이 아니라, 운영 단계에서 반복적으로 발생하는 변경을 표준화된 기준과 절차로 관리하기 위한 선택입니다.

파이브클라우드는 IaC 도입, Terraform 기반 표준화, EKS 전환과 운영 체계 구축까지 고객 환경과 목표에 맞는 방향으로 함께 설계합니다. IaC 도입이나 EKS 전환, 클라우드 운영 표준화가 필요하다면 파이브클라우드로 문의해 주세요.

혜택 안내

✅ 연간 계약 시 사용료의 기본 30% 부터 할인

이제는 출근과 동시에 AI 에이전트가 밤사이 처리해 둔 업무 리포트를 확인하고 승인하는 장면도 이제는 흔히 볼 수 있는 모습이 되었습니다. AI는 여러 프로그램을 넘나들며 데이터를 취합하고, 이슈를 분석하고, 필요한 경우 담당자에게 직접 질문해 결과물을 완성하죠.

이처럼 빠르게 달라지고 있는 업무 환경의 배경에는 무엇이 있을까요?

2026년이 시작된 지금, 지난 2년간의 변화를 돌아보며 AI 에이전트 확산이 업무 자동화 방식, 소프트웨어 비용 구조, 그리고 IT 인프라 환경에 어떤 변화를 불러왔는지 살펴보았습니다. 또한 이러한 변화 속에서 앞으로 기업이 경쟁력을 갖추기 위해 무엇을 점검해야 하는지도 함께 정리했습니다.

AI는 어디까지 일을 대신하게 되었을까

도대체 업무 현장은 얼마나 달라진 걸까요? 흔한 업무 중 하나인 월간 보고서 작성 사례를 보면 변화가 분명해집니다. 과거의 AI는 “이 텍스트를 요약해 달라”는 요청에 따라 문장을 다듬는 역할에 머물렀습니다. 하지만 2026년의 AI 에이전트는 여러 프로그램을 넘나들며 실제 업무를 완수합니다.

“자료 취합은 제가 할게요. ○○님은 결정만 하세요.” 이 말이 더 이상 낯설지 않은 이유입니다. 

예를 들어, 내일 오전 경영진 회의를 위한 1월 실적 보고서 작성 상황을 가정해 보겠습니다. 퇴근 전에 AI 에이전트에게 “지난달 매출 실적을 정리해 경영진 보고용 슬라이드를 만들어 주세요. 목표를 달성하지 못한 부분은 원인 분석도 포함해 주세요.”라는 요청을 남깁니다.

AI 에이전트는 먼저 사내 CRM과 ERP에 직접 접속해 1월 매출 데이터와 비용 내역을 가져옵니다. 이후 매출이 목표보다 부족하다는 점을 확인하고, 영업팀 메신저 기록을 검색해 계약 지연 이슈를 원인으로 파악합니다. 부족한 정보가 있는 경우에는 담당 영업사원에게 직접 메시지를 보내 내용을 확인합니다. 이렇게 수집된 데이터와 답변을 바탕으로 그래프가 포함된 보고용 PPT 초안을 완성하고, 매니저의 이메일 임시 보관함에 저장해 둡니다.

다음 날 출근 후, 담당자는 AI 에이전트가 준비해 둔 보고 자료를 확인하고 최종 판단만 내리면 되는 것이죠. AI는 이제 단순한 보조 도구를 넘어, 업무 프로세스 안에서 실질적인 역할을 수행하는 존재가 되었습니다.

기업들은 왜 AI에게 일을 맡기기 시작했을까

이처럼 AI 에이전트가 업무 전반에 활용되기 시작한 배경에는 기업들이 공통적으로 겪고 있는 현실적인 고민이 있습니다. “일할 사람은 부족한데, 해야 할 일은 계속 늘어나고 있다”라는 점입니다. 인구 구조 변화와 인력난 속에서, 업무 효율화는 선택이 아니라 필수가 되었고, 반복적이고 소모적인 업무를 대신 수행할 수 있는 AI 에이전트는 자연스러운 대안으로 자리 잡았습니다.

2024년까지만 해도 챗봇에 질문하고 답변받는 방식이 일반적이었다면, 이제는 AI 에이전트를 하나의 팀원처럼 활용해 실제 업무를 맡기는 방식이 확산되고 있습니다. 단순 반복 업무는 AI가 처리하고, 직원들은 더욱 중요한 판단과 의사결정에 집중할 수 있게 된 것입니다.

특히 주 52시간제와 인력난으로 고민이 많은 기업에게 AI 에이전트는 현실적인 파트너가 되었습니다. 이제 기업의 고민은 “AI를 사용할 것인가”가 아니라, “어떤 AI 에이전트가 우리 조직의 업무 방식과 가장 잘 맞을 것인가”로 옮겨가고 있습니다.

달라진 소프트웨어 비용 구조

AI 에이전트 확산과 함께 체감되는 변화 중 하나는 소프트웨어 비용입니다. 과거에는 직원 수, 즉 ID 개수를 기준으로 비용을 지불하는 방식이 일반적이었습니다. 하지만 AI가 업무의 상당 부분을 수행하는 환경에서는 이러한 방식이 점점 낡은 기준이 되고 있습니다.

2026년을 기준으로, 비용은 AI가 처리한 데이터 양이나 완료한 업무 성과를 기준으로 산정되는 방식으로 변화하고 있습니다. 사용한 만큼 비용을 지불한다는 점에서는 합리적이지만, 한편으로는 월별 비용을 예측하고 관리해야 하는 새로운 과제도 함께 등장했습니다.

업무 방식의 변화가 인프라로 이어지다

AI 활용이 늘어나면서 IT 인프라 환경에 대한 고민도 커지고 있습니다. 2024년 말, 전력 부족으로 인해 수도권에 데이터센터를 추가로 구축하기 어려워졌던 상황은 2026년 현재까지도 영향을 미치고 있습니다.

판교나 강남과 같은 주요 업무 지역에 자체 서버실을 두는 것은 공간과 비용 측면에서 부담이 커졌고, 많은 기업이 전력을 찾아 지방으로 눈을 돌리거나 적은 전기로도 운영할 수 있는 고효율 인프라 도입을 검토하고 있습니다. 결국, ‘전기를 아껴주는 인프라’가 기업 생존을 좌우하는 핵심 요소가 되었습니다.

AI 시대, 기업이 점검해야 할 것들

AI 에이전트와 함께 일하는 환경은 이미 시작되었습니다. 업무 자동화 방식은 달라졌고, 소프트웨어 비용을 바라보는 기준도 바뀌고 있으며, 이를 뒷받침하는 IT 인프라 환경에 대한 고민도 커지고 있습니다.

이러한 변화 속에서, 2026년 우리 회사는 이러한 변화에 얼마나 준비되어 있을까요? AI와 함께 일하는 시대를 앞두고, 지금의 업무 방식과 인프라 환경을 점검해 볼 시점입니다. 인프라 걱정은 파이브클라우드에 맡기고, 여러분은 비즈니스 본질에만 집중하세요.

• 고효율 AI 인프라 컨설팅: 전력은 적게 사용하면서도 효율은 높은, 우리 회사에 맞는 환경을 설계해 드립니다.
• 똑똑한 비용 관리: 복잡한 요금제 속에서 불필요하게 새는 비용을 줄일 수 있도록 도와드립니다.

2025년 기준, 국내 기업당 평균 SaaS 사용량은 100개 안팎에 달한다는 분석도 등장했습니다. 즉, SaaS와 클라우드는 더 이상 '선택'이 아니라 운영의 중심 인프라가 된 것입니다.

그렇다면 2026년에 기업이 가장 먼저 주목해야 할 흐름은 무엇일까요? 파이브클라우드가 디지털 인프라 핵심 트렌드 5가지를 정리했습니다.

1. AI-Native SaaS의 본격화

2026년 가장 큰 변화는 SaaS의 중심이 AI로 이동한다는 것입니다. 기존에는 SaaS에 AI 기능이 추가되는 방식이었다면, 이제는 AI 기반으로 설계된 SaaS가 시장을 주도할 것으로 전망됩니다.

AI-Native SaaS는 단순 텍스트 요약이나 추천 기능 수준을 넘어, [데이터 분석 → 의사결정 → 실행 → 최적화]에 이르는 전 과정을 하나의 흐름으로 제공합니다. 이는 사용자의 요청을 기다리는 수동적인 도구가 아니라, 시스템이 먼저 업무 맥락을 감지하고 제안하며 실행까지 주도하는 능동형 파트너(Proactive Partner)로의 진화를 의미합니다.

이제 기업의 SaaS 도입 기준은 "AI 기능이 있는가?"에서 "AI가 비즈니스 프로세스를 얼마나 완벽하게 자동화할 수 있는가?"로 바라보아야 합니다. 다가오는 시대, AI-Native 기술의 수용 여부가 기업의 생산성과 경쟁력을 결정짓는 핵심 지표가 될 것입니다.

2. SaaS 포트폴리오 확장에 따른 조직 운영 복잡성 증가

기업의 SaaS 도입이 가속화됨에 따라 Slack, Notion, Jira, Figma, HubSpot 등 조직 내 SaaS 사용량은 계속 증가하고 있습니다. 하지만 이러한 무분별한 확장은 곧 운영 복잡성 증가로 이어지게 됩니다.

많은 기업이 겪는 문제는 다음과 같습니다:

• 보안 거버넌스 부재: 퇴사자 계정 방치 및 권한 미회수
• 섀도우 IT(Shadow IT) 확산: 개인카드로 결제된 SaaS 비용 추적 어려움
• 비용 효율성 저하: 팀별 중복 도입으로 예산 낭비 및 저조한 사용률로 인한 예산 낭비
• 관리 책임의 모호성: 결제 계정·관리자 계정이 흩어져 책임 불명확

2026년, 기업 경쟁력의 핵심은 '어떤 SaaS를 도입하느냐'가 아닌 '어떻게 운영하느냐'로 전환될 것입니다. SaaS 운영 가시화, 중복 제거, 라이선스 최적화 등 데이터 기반 SaaS 운영 체계가 기업 경쟁력을 좌우하는 척도가 될 것입니다.

3. Shadow IT 확산에 따른 SaaS 보안 리스크 급증

SaaS 중심의 업무 환경은 협업과 생산성을 높여주지만, 조직이 SaaS 접근 흐름을 제대로 통제하지 못하면 보안 위협은 기하급수적으로 증가합니다. 대표적인 보안 리스크는 다음과 같습니다.

• 데이터 유출 위협: 개인 계정 혼용 및 비인가 앱 사용으로 인한 내부 데이터의 외부 유출
• 접근 권한 방치: 퇴사자 및 외주 인력의 계정이 적시에 회수되지 않는 '좀비 계정' 문제
• 외부 공유 노출: Slack, Notion 등 협업 툴의 초대 링크 및 공유 페이지가 외부로 노출
• 연동형 공격 위험: 무분별한 OAuth 권한 부여로 인해 제3자가 시스템에 접근 가능성 발생감사 추적 불가: 공용 계정 사용으로 사용자 식별이 불가능해 책임 소재 파악 실패

2026년에는 이러한 문제를 해결하기 위해 IAM(Identity & Access Management) 중심의 보안 전략이 더욱 강화될 전망입니다. 계정 단위 접근 통제, SaaS 권한 구조 표준화, 접근 로그 기반의 위험 탐지, 자동화된 계정 수명주기 관리 등 SaaS 중심 보안 운영 체계가 일반화될 것입니다. 이제 보안팀만의 문제가 아니라, IT 운영팀 · DX팀 · 현업 부서 모두가 보안 관리의 주체가 되어야 하는 환경입니다.

4. 클라우드 비용 최적화(CFM)의 필수 운영 체계화

클라우드 비용 문제는 2026년에도 많은 기업의 공통 고민으로 남게 됩니다. AI 워크로드 확산, 글로벌 CSP(클라우드 서비스 제공자) 비용 정책 변화, 저장소 및 전송 비용 증가 등이 겹치며 운영 비용이 자연스럽게 상승하고 있습니다. 많은 기업에서 공통적으로 겪는 비용 리스크는 다음과 같습니다.

공통 비용 문제:

• 유휴 리소스 낭비: 오랫동안 사용하지 않는 EC2, RDS 및 고아(Unattached) 스토리지의 방치
• 스토리지 비용 증가: 관리되지 않은 스냅샷, 로그, 백업 데이터의 무분별한 누적
• 오버 프로비저닝(Over-Provisioning): 실제 트래픽 대비 과도한 인스턴스 스펙 설정으로 인한 예산 낭비
• 비용 책임 불명확: 계정 구조가 분리되지 않아 부서별/프로젝트별 리소스 책임 소재 파악 어려움
• AI 인프라 비용 급증: AI 모델 학습 및 추론을 위한 고가의 GPU 인프라 사용량 증가

2026년에는 CFM(Cloud Financial Management)이 단순한 비용 절감 전략이 아니라 클라우드 운영체계의 필수 요소가 됩니다. 비용 모니터링 → 최적화 → 자동화의 3단 구조가 표준이 되며, 자원 태깅 정책과 책임 기반 리소스 구조 설계가 운영 관리의 핵심이 됩니다. FinOps 전문가 혹은 MSP 파트너의 역할이 더욱 중요해질 수 밖에 없는 이유입니다. 

5. 멀티클라우드 운영 체계의 표준화

AWS · GCP · Azure를 함께 운영하는 멀티클라우드 전략은 이제 특정 기업의 선택적 전략이 아니라, 전 산업에서 일반적인 운영 방식으로 빠르게 자리 잡고 있습니다. 데이터 주권, 글로벌 시장 대응, 성능 확보, 장애 리스크 분산 등 다양한 이유로 멀티클라우드를 선택하는 조직이 증가하고 있기 때문입니다.

2026년에는 멀티클라우드를 효과적으로 운영하기 위한 표준 운영 체계가 더욱 중요해질 전망입니다. 대표적으로 필요한 운영 요소는 다음과 같습니다.

• 표준 아키텍처 수립: CSP 간 상호 운용성을 보장하는 멀티클라우드 SOP 설계
• 통합 IAM 설계: 파편화된 계정 관리를 극복하기 위한 CSP별 IAM 구조의 통합 및 표준화
• 중앙 집중형 가시성 확보: 로그 모니터링 및 보안 계층을 하나로 통합하여 사각지대 제거
• 비용 및 리소스 최적화: CSP별 상이한 비용 정책과 리소스 구조를 분석하여 최적의 비용 효율 달성
• 워크로드 배치 최적화: 각 CSP의 특장점(Best-of-Breed)을 고려한 전략적 워크로드 배치

멀티클라우드 시대에는 결국 클라우드 운영 수준, 아키텍처 역량, 자동화 체계의 성숙도가 기업의 경쟁력을 결정하게 됩니다. 

2026년의 경쟁력은 ‘도입’이 아니라 ‘운영의 정교함’

2026년 SaaS·클라우드 시장의 패러다임은 단순한 기술의 확장이 아닌, 이미 도입한 디지털 자산을 얼마나 스마트하게 운영하고 연결하느냐에 달려 있습니다.

AI-Native SaaS의 확산, Shadow IT 리스크와 IAM 중심의 보안, 멀티클라우드의 표준화, 그리고 비용 최적화(CFM)에 이르기까지. 급변하는 환경 속에서 기업의 IT 운영 방식은 새롭게 정의되어야 합니다. 내년의 핵심 전략은 개별 솔루션의 도입이 아니라, 클라우드 인프라와 SaaS 활용 체계를 아우르는 통합적인 운영 최적화하는 방향으로 이어질 가능성이 큽니다.

2026년, 성공적인 디지털 운영 전략을 고민하고 계신다면 파이브클라우드와 함께 가장 현실적이고 명확한 방향을 찾아보세요.