클라우드 나침반

장애가 났다. 응답이 갑자기 느려져 로그를 열어 prompt를 들여다본 순간, 사용자가 본인 확인을 위해 입력한 주민등록번호 뒷자리와 카드번호가 그대로 찍혀 있다. 모델 응답 로그에는 내부 시스템 프롬프트에 있던 DB 접속 정보까지 따라 나왔다. 디버깅을 위해 켜둔 평범한 로그 하나가, 그 순간부터 개인정보 유출 사고가 된다.LLM을 서비스에 붙이는 일은 점점 쉬워지고 있다. 그러나 로그와 관측성(Observability) 설계는 일반 웹 애플리케이션 시절의 감각으로 접근하기 어렵다. 입력과 출력 자체가 자유 형식의 자연어이기 때문에, 어떤 데이터가 들어올지 사전에 정의할 수 없고, 어떤 데이터가 나갈지도 보장하기 어렵다. 이 글은 LLM 서비스를 운영할 때 로그에 절대로 그대로 남기면 안 되는 데이터 ..

AIOps는 모니터링 엔지니어의 일을 없애지 않는다. 오히려 더 많은 판단을 요구한다. "AI가 알아서 고쳐 주는 시스템"을 기대했다가 오탐(False Positive) 폭탄을 맞은 팀이 적지 않다. 기본 지표와 로그가 부실한 상태에서 AIOps를 얹으면 잘못된 판단이 더 빠르게 확산될 뿐이다. 이 글은 AIOps를 어떤 맥락에서 받아들여야 하는지, 운영자 관점에서 정리한다.요약AIOps는 모니터링을 없애는 기술이 아니라, 모니터링과 Observability 데이터를 해석하고 운영 흐름으로 연결하는 계층에 가깝습니다. 장애 징후를 더 빨리 묶고, 원인 후보를 좁히고, 반복 대응을 자동화하는 데는 도움이 되지만 기본적인 지표, 로그, 트레이스, 알림 기준이 부실하면 오히려 잘못된 판단을 빠르게 확산시킬 수..

요약Agentic AI를 실제 업무에 붙이기 시작하면 질문은 금방 바뀝니다. 처음에는 "어떤 모델을 쓸까?"를 고민하지만, 운영 단계에서는 "이 에이전트가 어떤 도구를 호출했고, 어떤 권한으로 실행됐으며, 장애가 났을 때 어디서 추적할 수 있는가?"가 더 중요해집니다.이번 글에서는 AWS의 Amazon Bedrock Agents 및 Bedrock AgentCore와 Azure의 Azure AI Foundry Agent Service를 운영자 관점에서 비교합니다. 단순 기능 목록보다 런타임, 권한, 도구 연결, 관측성, 배포 흐름을 기준으로 어느 상황에 어떤 접근이 더 자연스러운지 정리합니다.이런 분들을 위한 글클라우드 인프라, DevOps, 플랫폼 엔지니어링, AI 서비스 운영을 담당하면서 Agentic..

요약Agentic AI를 운영 환경에 붙일 때 가장 먼저 준비해야 할 것은 모델 선택이 아니라 관측 가능성, 즉 Observability 기준이다. Agent는 단순히 답변을 생성하는 것을 넘어 도구를 호출하고, 외부 시스템을 조회하고, 여러 단계의 판단을 거쳐 결과를 만든다.그래서 운영자는 "정답이 나왔는가"만 볼 수 없다. 어떤 사용자 요청에서 시작됐고, 어떤 Agent 버전이 동작했고, 어떤 도구를 어떤 권한으로 호출했으며, 실패했을 때 어느 단계가 원인이었는지를 추적할 수 있어야 한다.이 글을 읽으면 좋은 사람클라우드 운영, DevOps, SRE, 플랫폼 엔지니어링, LLMOps 업무에서 Agentic AI 도입을 검토하는 분들을 위한 글이다.특히 AWS Bedrock Agent, Bedrock ..

AI Agent에게 운영 권한을 줄 때 먼저 나눠야 할 경계오늘의 관점Agentic AI의 위험은 "AI가 틀릴 수 있다"에서 끝나지 않는다. 실제 운영 환경에서는 틀린 판단보다 더 위험한 것이, 그 판단이 곧바로 변경 권한과 연결되는 구조다.요약Agentic AI는 단순 챗봇과 다르게 도구를 호출하고, 시스템을 조회하고, 경우에 따라 실제 변경 작업까지 수행할 수 있다. 그래서 운영 환경에 AI Agent를 붙일 때는 모델 성능보다 먼저 권한 경계, 승인 흐름, 감사 로그를 설계해야 한다.이 글에서는 인프라와 DevOps 담당자가 Agentic AI를 운영 자동화에 적용하기 전에 확인해야 할 권한 설계 원칙을 정리한다. AWS와 Azure 관점에서는 Agent가 어떤 도구를 호출할 수 있는지, 어떤 작..

알람 이후의 탐색, 판단, 승인 흐름을 AI Agent로 줄이는 방법"장애 대응 자동화의 목표는 사람을 없애는 것이 아니라, 사람이 판단해야 할 순간까지 더 빨리 도착하게 만드는 것이다." 1. 장애 대응에서 가장 오래 걸리는 일1.1 알람은 빠르지만 판단은 느리다운영 환경에서 알람은 이미 충분히 빠르다. CloudWatch Alarm, Prometheus Alertmanager, Datadog, Slack 알림까지 붙어 있으면 문제 발생 자체는 금방 알 수 있다.그런데 실제 장애 대응에서 시간이 오래 걸리는 부분은 알람 수신이 아니다. 알람 이후에 "무엇을 먼저 봐야 하는가"를 판단하는 과정이다.1.1.1 운영자가 동시에 확인하는 정보예를 들어 API 지연 시간이 갑자기 증가하면 운영자는 보통 다음 정..