요약Terraform Drift는 Terraform 코드, 상태 파일, 실제 클라우드 리소스가 서로 다른 방향으로 움직이면서 생기는 운영 불일치다. 단순히 "누가 콘솔에서 바꿨다"의 문제가 아니라 장애 대응, 긴급 권한, 자동 확장, 외부 정책, 여러 도구의 동시 사용이 얽힌 결과인 경우가 많다.이 글에서는 Terraform Drift가 왜 생기는지, AWS와 Azure 운영에서는 어떻게 드러나는지, 그리고 실무자가 어떤 절차로 탐지하고 대응해야 하는지 정리한다.이 글이 필요한 사람Terraform으로 AWS나 Azure 인프라를 관리하지만, 운영 중 콘솔 변경, 긴급 수정, 보안 정책 변경 때문에 terraform plan 결과가 예상과 달라지는 경험을 한 엔지니어를 위한 글이다.또한 IaC를 도입했지..
요약Agentic AI를 실제 업무에 붙이기 시작하면 질문은 금방 바뀝니다. 처음에는 "어떤 모델을 쓸까?"를 고민하지만, 운영 단계에서는 "이 에이전트가 어떤 도구를 호출했고, 어떤 권한으로 실행됐으며, 장애가 났을 때 어디서 추적할 수 있는가?"가 더 중요해집니다.이번 글에서는 AWS의 Amazon Bedrock Agents 및 Bedrock AgentCore와 Azure의 Azure AI Foundry Agent Service를 운영자 관점에서 비교합니다. 단순 기능 목록보다 런타임, 권한, 도구 연결, 관측성, 배포 흐름을 기준으로 어느 상황에 어떤 접근이 더 자연스러운지 정리합니다.이런 분들을 위한 글클라우드 인프라, DevOps, 플랫폼 엔지니어링, AI 서비스 운영을 담당하면서 Agentic..
AI Agent에게 운영 권한을 줄 때 먼저 나눠야 할 경계오늘의 관점Agentic AI의 위험은 "AI가 틀릴 수 있다"에서 끝나지 않는다. 실제 운영 환경에서는 틀린 판단보다 더 위험한 것이, 그 판단이 곧바로 변경 권한과 연결되는 구조다.요약Agentic AI는 단순 챗봇과 다르게 도구를 호출하고, 시스템을 조회하고, 경우에 따라 실제 변경 작업까지 수행할 수 있다. 그래서 운영 환경에 AI Agent를 붙일 때는 모델 성능보다 먼저 권한 경계, 승인 흐름, 감사 로그를 설계해야 한다.이 글에서는 인프라와 DevOps 담당자가 Agentic AI를 운영 자동화에 적용하기 전에 확인해야 할 권한 설계 원칙을 정리한다. AWS와 Azure 관점에서는 Agent가 어떤 도구를 호출할 수 있는지, 어떤 작..
- Total
- Today
- Yesterday
