삼성 계정 AIOps: AgentCore기반 AlOps의 실전 활용과 자율성 확장

지난 1부에서는 삼성계정 서비스의 멀티 에이전트 AIOps 시스템을 어떤 구조로 설계했고, 그 구조를 안정적으로 운영하기 위해 무엇을 뒷받침했는지, 그리고 그 위에서 자율성을 어떻게 조금씩 넓혀왔는지를 다뤘습니다. 이 글에서는 그 시스템이 실제 운영 현장에서 어떻게 쓰이고 있는지, 도입 전후로 업무가 어떻게 달라졌는지, 그리고 더 높은 수준의 자율운영으로 나아가기 위해 무엇을 준비하고 있는지를 다룹니다.

이 글은 2부작으로 구성되어 있습니다. Part 1: 삼성계정 서비스 AIOps — 멀티 에이전트 기반 운영 자동화의 여정과 Part 2: 삼성계정 서비스 AIOps — 실전 활용과 자율성 확장을 향한 다음 단계를 함께 읽어보시길 권합니다.

AIOps 시스템 제공 기능

1부에서 소개한 구조와 필라가 실제로 맞물려 돌아가는 모습은, 운영자가 매일 마주하는 화면에서 가장 직관적으로 드러납니다. 운영자는 웹 콘솔과 Slack 두 채널을 함께 활용하며, 어느 채널로 요청하든 동일한 Orchestrator에게 요청이 전달되어 같은 방식으로 처리됩니다. 다만 두 채널의 역할은 조금 다릅니다. Slack은 자연어 기반으로 동작해, 콘솔 앞이 아니어도 외부에서 긴급한 업무에 대응하거나 필요한 정보를 바로 질의할 수 있는 채널입니다. 반면 웹 콘솔은 Slack처럼 대화형으로도 쓸 수 있지만, 여러 화면과 기능이 함께 제공되어 운영 업무 전반을 훨씬 폭넓게 다룰 수 있습니다.

웹 콘솔은 화면을 세 영역으로 나눠 사용합니다. 좌측에는 현재 탭에서 볼 수 있는 메뉴 항목들이 나열되고, 중앙에는 선택한 메뉴의 콘텐츠(대시보드, 목록, 상세 화면 등)가 표시됩니다. 우측에는 화면 전환과 무관하게 항상 떠 있는 대화창이 있어, 운영자는 어떤 화면을 보고 있든 자연어로 바로 질의하거나 작업을 지시할 수 있습니다.

상단에는 8개의 탭이 있고, 각 탭은 서로 다른 목적의 화면 묶음으로 연결됩니다. 이 장에서는 그중 대표적인 네 가지 탭(MAIN 대시보드, AGENTS, BLACKBOARD, TRACE TRAIL)을 예시로 시스템이 실제로 어떻게 구성되어 있는지를 보여드립니다.

표 2. 웹 콘솔 상단 탭 구성과 제공 기능

MAIN 탭 대시보드

MAIN 탭은 시스템 전반을 조망하는 기본 화면입니다. 아키텍처 구성, 에이전트 현황, 대화·분석 이력, 요청별 트레이싱, Guardrail 탐지 이력을 한곳에서 확인할 수 있고, 그동안 쌓인 RCA와 Skill·Knowledge 문서도 이 탭에서 조회합니다. 운영자는 별도의 화면을 오가지 않고 이 대시보드 하나에서 시스템의 현재 상태를 파악합니다.

그림 18. MAIN 탭 대시보드: 시스템 전반 현황 조회

에이전트별 상세 정보

AGENTS 탭에서는 좌측 목록에서 도메인별로 배치된 에이전트를 선택하면, 우측에 해당 에이전트의 역할과 평가 지표, 실제 활용 예시가 표시됩니다. 평가 지표는 모든 에이전트에 동일하게 적용되는 고정된 항목이 아니라, 에이전트가 수행하는 작업의 특성에 맞춰 필요한 항목을 판단해 동적으로 구성됩니다. 예를 들어 여러 도구를 상황에 맞게 골라 쓰는 역할이 중요한 에이전트라면 Tool Coverage, Tool Selection, Tool Parameter, Coherence 같은 지표로 평가되어, 도구를 빠짐없이 활용하는지와 판단의 논리적 일관성을 유지하는지를 함께 봅니다. 운영자는 이 화면에서 특정 에이전트가 자신의 역할에 맞는 기준으로 얼마나 안정적으로 작업을 수행하고 있는지를 바로 확인할 수 있습니다.

그림 19. AGENTS 탭: 에이전트별 역할·동적 평가 지표·활용 예시

블랙보드 기반 작업 흐름

BLACKBOARD 탭은 운영자가 요청한 작업이 완료되기까지의 전체 과정을 하나의 흐름으로 보여줍니다. 작업은 요청 → 계획 작성 → 계획 검토 → 승인 → 수행 → 결과 승인 → 완료 순서로 단계를 밟아가며, 각 단계는 사람이 담당하는 구간과 에이전트가 담당하는 구간이 번갈아 나타납니다. 운영자가 New Task로 작업을 요청하면 task-planner가 계획을 세우고, 운영자가 그 계획을 검토·승인하면 task-executor가 실제 작업을 수행합니다. 마지막으로 수행 결과를 운영자가 다시 승인해야 작업이 완료 처리됩니다.

이 흐름에서 에이전트가 참고하는 것이 Skill입니다. 새 작업을 요청할 때 운영자는 관련된 Skill 문서를 함께 지정할 수 있고, task-planner와 task-executor는 이 문서에 정리된 절차를 기반으로 계획을 세우고 작업을 수행합니다. 즉 에이전트가 처음부터 스스로 판단해 움직이는 것이 아니라, 이미 검증된 절차(Skill)를 얼마나 정확히 따르는지를 사람이 단계별로 확인하며 작업을 진행시키는 구조입니다.

그림 20. BLACKBOARD 탭: Skill 기반 새 작업 요청 화면

변경·배포 이력 추적

TRACE TRAIL 탭은 AWS 리소스 변경과 애플리케이션 배포 이력을 모두 한곳에서 관리합니다. CloudTrail 기반으로 수집된 인프라 변경 이벤트와 배포 파이프라인의 변경 사항이 함께 쌓여서, 운영자는 언제 어떤 서비스와 리소스에 변경이 발생했는지를 시간순으로 바로 확인할 수 있습니다. 장애나 이상 징후가 발생했을 때 “최근에 무엇이 바뀌었는가”를 가장 먼저 확인해야 하는데, 이 탭이 바로 그 질문에 답하는 화면입니다.

그림 21. TRACE TRAIL 탭: 서비스·리소스별 변경·배포 이력 추적

실제 활용 사례

앞서 살펴본 기능들이 실제로 맞물려 돌아가는 모습은, 그 뒤에서 있었던 사례를 통해 가장 직관적으로 확인할 수 있습니다. 이 장에서는 시스템이 현장에서 어떻게 작동했는지를 대표적인 네 가지 사례로 보여드립니다.

장애 알람 실시간 분석

모니터링 시스템의 알람은 Slack과 직접 연동되어 있습니다. 이상 지표가 감지되어 알람이 발생하면 별도의 확인 절차 없이 Orchestrator가 즉시 이를 트리거해, 관련 도메인의 Supervisor에게 분석을 넘기고 장애 분석이 자동으로 시작되는 구조입니다.

실제로, 지난 5월 26일 밤 Amazon DynamoDB 관련 API 오류가 급증하며 알람이 발생했을 때도 이 흐름대로 처리됐습니다. Slack으로 들어온 이 알람은 Orchestrator를 거쳐 incident-supervisor와 db-supervisor에 동시에 전달되어, 영향 범위와 실제 DB 상태를 각자의 관점에서 병렬로 분석했습니다. 두 분석 모두 특정 서비스의 문제가 아니라 DynamoDB 자체의 일시적인 이슈라는 결론으로 수렴했고, 운영팀은 이를 근거로 AWS와 곧바로 커뮤니케이션하며 빠르게 대응할 수 있었습니다.

예전에는 원인을 좁히고 대응 방안을 마련하는 데 시간이 걸렸지만, 지금은 서로 다른 도메인의 에이전트가 동시에 분석해 결론을 맞춰주기 때문에 그 시간이 크게 줄었습니다.

그림 22. 두 도메인 에이전트의 병렬 분석으로 대응까지 이어지는 흐름

그림 23. Slack 알람 기반 DynamoDB 장애 분석 결과

인프라 변경 영향도 분석

인프라는 Terraform으로 코드 관리되고 있고, 변경은 대부분 PR로 시작됩니다. 기존에는 리뷰어가 diff를 읽고 관련 리소스의 현재 상태를 직접 조회해 영향도를 판단해야 했습니다. code-reviewer는 PR이 열리면 코드 변경 자체를 리뷰해 특이사항을 짚어줄 뿐만 아니라, 실제 운영 중인 리소스까지 함께 점검해 이 변경이 실제로 어떤 영향을 미칠지를 분석해 코멘트로 남깁니다. 예를 들어 보안 그룹 규칙을 좁히는 PR에서는 그 규칙에 실제로 걸리는 트래픽이 있는지를 VPC Flow 로그 기반으로 확인해 알려주고, RDS 파라미터 그룹 변경 PR에서는 현재 연결 수와 예상 재시작 영향을 함께 표시합니다. 리뷰어는 코드와 실제 운영 상태를 각각 따로 확인하는 대신, 이 코멘트 하나를 참고해 더 빠르고 근거 있게 승인 여부를 판단합니다.

그림 24. 코드 변경과 운영 상태를 함께 분석하는 code-reviewer 처리 흐름

그림 25. Terraform PR에 대한 인프라 영향도 분석 코멘트

월간 리포트 자동화

앞서 설명한 것처럼, 기존에는 모니터링 지표와 비용 지표를 비롯한 여러 데이터를 매달 하나씩 직접 조회하고 정리해 리포트를 작성했습니다. 지금은 각 도메인 에이전트가 지난 한 달간의 주요 알람 분석 및 모니터링 지표, 인프라 변경 이력, 보안 점검 결과, 비용 추이를 자신의 영역에서 직접 취합해 정리하고, 그중 눈여겨봐야 할 핵심 포인트까지 짚어 강조한 뒤 하나의 월간 리포트로 모아 보여줍니다. 운영자는 데이터를 긁어모으는 작업 없이, 이미 정리되고 강조된 초안에 맥락을 더하고 다듬는 데만 집중하면 됩니다.

그림 26. 도메인 에이전트별 취합으로 완성되는 월간 통합 리포트

그림 27. 월간 리포트 내 인프라 변경 이력 예시

원격 긴급 작업 수행

특정 파드나 노드 삭제, 재시작, 스케일 인·아웃처럼 긴급하게 처리해야 하는 작업이 있습니다. 운영자는 이런 작업을 Slack이나 웹 콘솔에서 자연어로 요청할 수 있고, task-executor가 그 요청을 받아 처리합니다. 다만 에이전트가 직접 실행하는 것이 아니라, 1부에서 설명한 스케줄러 방식을 그대로 따릅니다. 에이전트는 무엇을 어떻게 실행할지를 스케줄러에 등록만 하고, GitOps 방식의 승인 절차를 거쳐야 실제 실행이 이뤄집니다. 이 구조 덕분에 운영자는 사무실이나 콘솔 앞이 아니어도, 이동 중이거나 원격에 있는 상황에서도 비정상적인 상태를 감지하는 즉시 승인만으로 조치를 진행할 수 있습니다.

그림 28. 원격 긴급 작업 처리 흐름: 자연어 요청부터 결정적 실행까지

그림 29. Slack 자연어 요청과 GitOps 승인 화면

그림 30. 스케줄러 등록과 실행 결과 화면

에이전트 도입 전후 업무 변화

시스템을 도입하고 가장 뚜렷하게 달라진 것은 운영자가 하루를 시작하는 방식입니다. 도입 전에는 알람이 오면 관련 콘솔을 하나씩 열어 지표를 확인하고, 로그를 검색하고, 과거 유사 사례를 기억에서 더듬는 과정이 반복됐습니다. 지금은 알람이 오는 시점에 이미 교차 분석된 결과가 함께 도착합니다. 아래 표는 대표적인 업무 영역별로 도입 전후를 비교한 것입니다.

표 3. 에이전트 도입 전후 업무 영역별 변화

수치만큼 중요한 것은 업무의 무게중심 이동입니다. 운영자는 더 이상 정보를 모으는 데 시간을 쓰지 않고, 이미 정리된 분석 결과를 검증하고 최종 판단을 내리는 역할에 집중하게 되었습니다. 반복적인 조사 업무가 줄어든 만큼, 근본 원인을 더 깊이 파고들거나 재발 방지책을 설계하는 데 쓸 수 있는 시간이 늘었습니다. 물론 이 변화가 모든 업무에 균등하게 적용된 것은 아닙니다. 분석 중심으로 자동화가 적용된 영역은 체감 효과가 크지만, 아직 사람이 전 과정을 수행하는 영역도 남아 있습니다. 다음 장에서 다룰 더 높은 수준의 자율운영으로의 확장이 바로 이 남은 격차를 줄이기 위한 다음 단계입니다.

다만 이 변화를 업무량이 줄었다는 말로만 정리하면 절반만 맞는 설명입니다. 기존 SRE 업무는 위 표에서 본 것처럼 상대적으로 효율화되었지만, 그 자리를 대신해 에이전트를 직접 개발하고 고도화하는 에이전틱 엔지니어링(Agentic Engineering) 업무가 새로 생겨났습니다. 에이전트가 잘못 판단한 사례를 분석해 프롬프트와 판단 기준을 다듬고, 반복되는 작업을 Skill 문서로 정리해 등록하고, 새로운 도메인에 에이전트를 붙이기 위한 도구와 평가 지표를 설계하는 일은 모두 사람이 직접 해야 합니다. 즉 운영 실행 업무는 줄었지만, 그 운영을 대신 수행하는 에이전트를 만들고 관리하는 업무가 새로 늘어난 것입니다. 아래 그림은 이 두 축이 어떻게 맞물려 이동했는지를 보여줍니다.

그림 31. 반복 실행 업무에서 에이전틱 엔지니어링 업무로의 재배분

결국 총 업무량이 단순히 줄어든 것이 아니라, 운영자의 시간이 반복 실행에서 에이전트를 설계·검증하는 쪽으로 재배분된 것에 가깝습니다. 초기에는 이 전환 비용 때문에 오히려 체감 업무량이 늘어난 시기도 있었지만, Skill과 평가 체계가 쌓일수록 한 번의 엔지니어링 투자가 여러 반복 업무를 동시에 대체하기 때문에, 장기적으로는 이 투자가 다시 운영 효율로 되돌아옵니다.

그리고 이 재배분이 만들어내는 결과는 단순한 업무 분담의 변화에 그치지 않습니다. 운영자가 반복 조사에 쓰던 시간을 에이전트의 판단 기준을 다듬고 재발 방지책을 설계하는 데 쓰게 되면서, 장애 감지와 대응은 더 빨라지고, 같은 원인으로 반복되는 장애는 줄어듭니다. 결국 에이전틱 엔지니어링에 들어가는 투자는 운영자의 업무를 대체하는 것을 넘어, MTTD·MTTR 개선과 반복 장애 예방으로 이어져 서비스 품질을 실제로 끌어올리는 효과로 귀결됩니다. 즉 AIOps 도입은 단순히 사람의 일을 줄이는 수단이 아니라, 서비스 안정성과 사용자 경험을 높이는 데 직접적으로 기여하는 투자라는 점이 지금까지의 운영 결과가 보여주는 가장 중요한 결론입니다.

Level 3, Level 4 적용을 위한 방향

1부에서 정의한 자율운영 성숙도 모델에서, 우리는 현재 Level 2(계획 후 승인 실행)까지 와 있습니다. Level 3(조건부 자율)와 Level 4(완전 자율 운영)로 넘어가려면 기술을 더 얹는 것만으로는 부족합니다. 신뢰를 어떻게 검증하고, 어디까지를 먼저 맡길 것인가를 구체적으로 설계해야 합니다. 이 장에서는 그 다음 단계를 위해 지금 진행하고 있는 네 가지 방향을 다룹니다.

프로세스 개선을 통한 수행 영역 구분과 단계별 확산

Level 3로 가는 첫걸음은 기술을 더 얹는 것이 아니라, 기존 운영 프로세스를 다시 들여다보고 에이전트가 안전하게 수행할 수 있는 영역과 여전히 사람의 판단이 필요한 영역을 명확히 구분하는 것입니다. 절차가 표준화되어 있고 입력과 출력이 명확한 작업은 에이전트가 수행 가능한 영역으로, 판단 기준이 상황마다 달라지거나 결과를 되돌리기 어려운 작업은 여전히 사람이 담당하는 영역으로 분리합니다. 이 구분이 선명해질수록 어떤 작업을 먼저 자율화 대상으로 옮길지에 대한 근거도 함께 명확해집니다.

그림 32. 장애 분석 프로세스의 Digital Worker·Human-in-the-Loop 영역 구분

장애 분석 프로세스를 감지부터 종료까지 9개 단계로 펼쳐보면, 대부분의 세부 작업은 이미 Digital Worker 레인, 즉 에이전트가 자율적으로 수행하는 영역에 놓여 있습니다. 지표 이상 감지, 알람 수신, 영향도 분석, 원인 후보 도출, 승인된 조치의 실행과 모니터링까지는 에이전트가 끝까지 커버합니다. 반면 상세 확인이 필요한지 판단하는 지점, 선조치·장애 조치를 승인하는 지점, 장애를 조직 내부로 전파하는 지점, 그리고 장애 종료를 알리는 지점은 여전히 Human-in-the-Loop 레인에 남아 있습니다. 이 지점들은 조직 내 커뮤니케이션이나 비즈니스 영향 판단이 결부되어 있어, 지금 수준에서는 사람이 최종 확인을 거치도록 설계했습니다. 이렇게 프로세스를 단계 단위로 펼쳐 놓으면, 어디까지를 에이전트에게 맡길 수 있는지가 추상적인 감이 아니라 구체적인 지도로 드러납니다.

구분이 끝난 영역은 한 번에 전체를 전환하지 않고, 단계별로 에이전트를 적용해 범위를 넓혀가는 방식을 취합니다. 먼저 한두 개 대표 작업에 에이전트를 적용해 안정성을 확인하고, 문제가 없으면 같은 유형의 인접 작업으로 범위를 넓힙니다. 이렇게 단계를 밟아가면 프로세스 자체의 결함과 에이전트의 판단 오류를 구분해 조치할 수 있고, 확산 속도도 검증된 만큼만 늘려갈 수 있습니다.

수행 데이터의 신뢰 지표 정량화

“신뢰가 쌓였다”는 말은 그 자체로는 판단 기준이 될 수 없습니다. 우리는 에이전트가 실제로 수행한 업무 데이터를 아래 네 가지 신뢰 지표로 정량화해, Level 3 전환 여부를 판단하는 근거로 함께 추적하고 있습니다.

그림 33. 자율운영 전환을 판단하는 4가지 신뢰 지표

이렇게 수치화된 지표는 “감”이 아니라 데이터로 신뢰 수준을 설명할 수 있게 해주며, 다음 단계인 Level 3 전환 대상을 고르는 근거로 그대로 이어집니다.

신뢰 지표 기반 저위험·정형화 작업의 Level 3 전환 확대

앞에서 정량화한 신뢰 지표를 기준으로, 위험이 낮고 절차가 충분히 정형화된 작업을 골라 먼저 자율 실행 대상으로 옮깁니다. Level 2에서 Level 3로 넘어간다는 것은 단순 조회나 문서 작성을 넘어, 실제로 리소스를 변경하는 쓰기(write) 권한을 에이전트에게 맡긴다는 의미입니다. 따라서 후보도 조회성 업무가 아니라, 반복 수행 빈도가 높고 실행 결과가 항상 예측 가능하며 실패했을 때 되돌리기 쉬운 쓰기 작업 중에서 고릅니다. 예를 들어 노후 인스턴스 타입을 최신 세대로 전환하는 작업, 탐지된 보안 취약점을 표준 조치 절차에 따라 자동으로 패치하는 작업 같은 것이 첫 후보군입니다.

실제 전환 여부는 작업 유형별로 4개 지표의 점수를 각각의 기준치와 비교해 판정합니다. 아래는 쓰기 권한이 필요한 두 후보 작업을 같은 기준으로 채점한 예시입니다.

그림 34. 신뢰 지표 기준으로 본 Level 2 유지·Level 3 전환 판정 예시

쓰기 권한이 걸린 작업이기 때문에 이 후보들도 처음부터 완전 자율로 넘어가지 않습니다. 먼저 사후 검토 기간을 두어 에이전트가 승인 없이 실행한 결과를 사람이 매번 확인하고, 목표 달성률·작업 수행 연속 성공률·승인 거부율·변경 실패율이 일정 기준을 충족하는 것을 확인한 뒤에야 승인 게이트를 실제로 걷어냅니다. 위 두 사례처럼 지표 중 하나라도 기준을 밑도는 작업은 Level 2에 남아 계속 사람의 승인을 거치도록 하며, 이 검증 기간의 데이터가 다음 확대 대상을 고르는 기준이 됩니다.

모델 발전에 맞춘 통제 수위의 지속적 조정

1부에서 언급했듯, 지금의 강한 통제는 현재 LLM 수준을 전제로 설계되었습니다. 모델이 더 정교하게 지시를 따르고 스스로 위험을 판단하는 능력이 발전하면, 지금 사람이 담당하는 검토 단계 중 일부는 에이전트에게 넘길 수 있는 여지가 생깁니다. 우리는 이런 변화를 시스템 재설계 없이 받아들일 수 있도록, 승인 게이트와 스케줄러 구조를 정책 기반으로 조정 가능하게 만들어 두었습니다. 구체적으로는 작업 유형별 자율성 레벨을 코드가 아니라 설정으로 관리해, 앞에서 정량화한 신뢰 지표와 AgentCore Evaluation 기반 평가 체계를 지속적으로 활용함으로써, 모델 성능이 함께 향상될 때 통제 수위를 점진적으로 낮출 수 있도록 준비하고 있습니다.

마무리

1부에서는 멀티 에이전트 시스템을 어떤 구조로 설계했고, 그 구조가 안정적으로 돌아가도록 무엇을 뒷받침해야 했는지를 이야기했습니다. 그리고 2부에서는 그렇게 설계한 시스템이 실제 운영 현장에서 어떻게 쓰이고 있는지, 도입 전후로 업무의 무게중심이 어떻게 이동했는지, 그리고 더 높은 수준의 자율운영으로 나아가기 위해 지금 무엇을 준비하고 있는지를 이어서 다뤘습니다. 두 편으로 그리고자 한 것은 결국 하나의 흐름입니다. 믿을 수 있는 만큼만 맡기고, 맡긴 만큼 검증해 신뢰를 넓혀가는 것입니다.

이 흐름은 처음부터 완성된 그림이 아니었습니다. 에이전트에게 무엇을 맡길 수 있는지는 한 번에 정해지지 않았고, 먼저 분석과 판단을 보여주는 단계부터 시작해, 검증된 절차와 축적된 맥락을 쌓아가며 계획 후 승인을 거쳐 실행할 수 있는 단계까지 자율성의 범위를 확장해 왔습니다. 그 결과가 2부에서 살펴본 실제 사례들, 그리고 알람·장애 원인 분석부터 리포트 작성까지 이어진 업무의 무게중심 이동입니다.

실제 사례들이 보여주듯, 지금 시스템이 만들어내는 가치는 화려한 자동화가 아니라 더 빠르고 근거 있는 판단입니다. 운영자는 정보를 모으는 대신 판단하는 데 시간을 쓰고, 반복 작업은 검증된 절차를 따라 안전하게 처리됩니다. 그 대신 에이전트를 설계하고 고도화하는 에이전틱 엔지니어링이라는 새로운 업무가 생겨났지만, 이 투자는 결국 MTTD·MTTR 개선과 반복 장애 예방으로 이어져 서비스 품질을 실제로 끌어올리는 효과로 되돌아왔습니다.

다음으로 나아가야 할 더 높은 수준의 자율운영 단계는 기술이 아니라 신뢰를 검증하는 체계가 관문이 될 것입니다. 에이전트가 수행 가능한 영역을 프로세스 단위로 구분해 단계적으로 확산하고, 그 수행 데이터를 신뢰 지표로 정량화하며, 그 지표를 근거로 저위험 작업부터 자율 실행 대상을 넓히고, 모델의 발전에 맞춰 통제 수위를 유연하게 재조정하는 것. 이 네 가지 방향이 지금 우리가 다음 단계로 가기 위해 쌓고 있는 자산입니다.

생성형 AI 에이전트를 운영에 도입하는 여정은 한 번의 구축으로 끝나지 않습니다. 여러분의 조직에서도 같은 여정을 시작하고 싶다면, Amazon Bedrock AgentCore 개발자 안내서로 첫 에이전트를 배포해 보고, AgentCore Observability와 Amazon Bedrock Guardrails로 관측과 통제의 토대를 먼저 갖추시기를 권합니다. 읽기 전용 분석부터 맡기고 신뢰가 쌓이는 만큼 범위를 넓혀가는 방식이 저희가 겪어본 가장 안전한 출발점이었습니다. 다음 단계에 실제로 도달하면 그 과정에서 얻은 경험을 새로운 블로그를 통해 공유하겠습니다.

참고

삼성전자 삼성계정 서비스 SRE팀

소새롬

김정현

김재영

이동준

최송희

편수빈

삼성계정 서비스 SRE팀은 삼성전자의 주요 서비스가 공통으로 사용하는 인증 플랫폼인 삼성계정을 운영하고 있습니다. 전 세계에서 유입되는 트래픽을 감당할 인프라를 설계·운영하고, 장애에 대응하며, 클라우드 비용과 보안을 관리합니다. 안정적인 서비스를 유지하면서도 운영 부담을 줄이는 방법을 꾸준히 고민하고 있습니다.

AWS 기술 블로그