AWS 기술 블로그
생성형 AI로 실현하는 장애 대응부터 지식 자산화까지: Amazon Bedrock, Slack 그리고 Atlassian Confluence 통합 지능형 시스템
배경 및 문제 정의
현대의 IT 인프라 환경은 그 규모와 복잡성이 기하급수적으로 증가하고 있습니다. 클라우드 네이티브 아키텍처의 도입이나 마이크로서비스 기반 애플리케이션의 확산으로 기업의 IT 운영팀이 대응해야 할 영역은 지속적으로 확장되고 있습니다. 특히 시스템 전반에서 발생하는 다양한 종류의 로그 데이터, 메트릭 그리고 메시지들을 효과적으로 분석하고 신속하게 대응하는 것이 중요한 과제로 떠오르고 있습니다.
- 신속한 장애 대응의 필요성
특히 운영중인 시스템에 장애가 발생할 경우, IT운영팀은 해당 원인을 신속히 파악하고 해결해야 하는데, 시스템 규모 그리고 아키텍처 복잡성으로 인해 증가된 정보는 에러 메시지 발생시 빠르게 근본 원인을 식별하기가 어렵습니다. 게다가 다양한 연관 솔루션을 운영한다면 IT운영팀의 부담은 더욱 가중됩니다. - 지식의 자산화 필요성
또한 장애가 해결된 이후에도 동일한 문제 발생 시 과거의 경험을 바탕으로 보다 빠르고 효율적으로 해결할 수 있다면 IT운영팀의 축적된 장애 대응 경험과 해결 노하우가 매우 중요한 자산입니다. 그래서 우리는 이러한 정보를 잘 요약된 내용으로 정리하여 추후 장애 시 활용한다면 장애의 빈도가 높은 모듈에 대한 개선 그리고 업무의 효율성을 높일 수 있습니다.
문제 해결 솔루션: 생성형 AI 기반 문제 분석 및 활용
이 블로그에서는 위와 같은 문제를 지원하기 위해 AWS의 생성형 AI서비스와 기업에서 주로 활용중인 협업 도구인 Slack, Atlassian Confluence를 통합한 생성형 AI 기반 클라우드 운영 지원 솔루션을 소개할 예정입니다. 이 솔루션은 아래 그림과 같이 총 3개의 주요한 흐름으로 구성되어 있습니다.
Figure 1. 솔루션 프로세스
1. Slack에서의 협업 및 문제 해결(①,②,③,④,⑤)
IT운영팀은 Slack을 Amazon Bedrock Agents와 연계합니다. 이후 Amazon CloudWatch Logs 로 수집되는 메시지에 대한 1차 식별 및 추가 정보를 AWS Lambda를 통해 Amazon Bedrock 에게 요청하고 Amazon Bedrock Agents Connector 로 추가 해결 방안을 논의하면서 팀원들과의 커뮤니케이션으로 메시지를 분석하고 모니터링 할 수 있습니다.
2. 분석 된 문제를 요약 후 게시글 생성(⑥)
문제가 해결되면, Slack Channel 내 전체 해결과정을 AWS Lambda를 통해 Amazon Bedrock Agents로 전달되어 요약본이 생성됩니다. 이 요약은 AWS Lambda로 Atlassian Confluence 에 자동 게시할 수 있습니다.
3. 지속적인 학습 및 개선활용(⑦)
생성된 요약은 Amazon Bedrock Knowledge Bases에 추가되어 향후 유사한 문제 해결에 활용됩니다. 이를 통해 향후 이 솔루션은 지속적으로 문서화된 정보를 참조하여 점점 더 정교한 분석과 제안을 제공할 것입니다.
기대효과
이 솔루션은 IT 운영팀의 업무 효율성을 높이는데 초점을 두었고 AWS의 생성형 AI서비스, 서버리스 컴퓨팅 그리고 협업 도구를 결합하는 것을 목표로 합니다. 다양한 메시지를 받게 되는 IT운영팀이 메시지에 대한 대응을 자동화하고 과거의 장애 처리 이력과 해결 노하우들을 팀의 Knowledge Bases화 할 수 있도록 합니다. 그리고 이를 LLM이 다시 참조하여 추후 문제 해결에 활용함으로써, 보다 신속하고 운영환경에 맞는 자동화된 장애 대응이 가능해질 것으로 기대하고 있습니다.
사용 사례 1 : 운영중 수신되는 Error Message에 대한 빠른 분석
애플리케이션, 데이터베이스, 보안, 네트워크 등 IT운영자에게 수신되는 다양한 형태의 Error Message를 빠르게 분석해 주고 추가적으로 어떤 조치를 해야 할지 대응을 위한 권고 또는 가이드를 해 줄 수 있습니다. 아래는 이 솔루션을 활용하여 Slack으로 수신받은 Error Message(데이터베이스, 보안 관련)에 대해 분석한 샘플입니다.
Figure 2. 데이터베이스와 WAF 관련 문제 분석
사용 사례 2 : Knowledge Bases 를 통한 문제의 근본 원인 분석 및 해결 방안 제시
뿐만 아니라 Slack내 AWS Chatbot을 연결하고 Amazon Bedrock Agent Connector로 추가적인 분석을 LLM에게 요청하면, Amazon Bedrock Knowledge Bases를 참조하여 문제의 근본 원인을 분석하고 해결 방안을 빠르게 제시합니다. 이는 잘 모르는 분야의 인시던트 처리나 업무를 처음 접하는 초보 운영자에게 대응 능력을 심어줄 수 있을 것으로 기대합니다.
Figure 3. Amazon Bedrock Agents Connector를 통한 모델과의 Interaction
사용 사례 3 : 분석이 완료된 내용을 자산화
위와 같이 분석된 내용을 LLM을 통해서 요약함과 동시에 사내 Atlassian Confluence 에 손쉽게 Reporting 하여 향후 운영을 위한 자산으로 활용합니다.
Figure 4. 분석된 내용을 요약 후 Atlassian Confluence에 게시글 자동 생성
시스템 아키텍처 및 흐름
이 솔루션의 전체 아키텍처는 다음과 같으며 흐름은 특정 시나리오를 기반으로 설명 드리겠습니다.
시나리오: AWS 환경에서 B2C 쇼핑몰을 운영중인 기업의 IT운영팀은 10명의 담당자로 이루어져 있으며, Slack의 #Issue-all 채널을 통해서 운영 관리되는 인프라에서 발생하는 모든 종류의 메시지를 수신 합니다. 또한 팀의 wiki(Confluence) 에서 작업내역과 장애관리 및 회고를 관리하고 있습니다.
Figure 5. 전체 솔루션 아키텍처와 동작 설명
단계 1: Knowledge Bases 구성
IT운영팀(Cloud Operator)은 기존 Atlassian Confluence에 작성하는 작업내역, 운영중의 장애 대응 히스토리 등을 작성하고, AWS 서비스에 대한 FAQ나 주요 서비스 Docs 등을 Amazon S3에 적재합니다.
단계 2: 로그 모니터링 및 알림 전송
운영팀의 협업도구로 전달되는 Message는 Amazon CloudWatch, APM, 보안 솔루션 등 다양합니다. (이 블로그에서는 Amazon CloudWatch Logs 로 한정하여 설명) Amazon CloudWatch Logs는 log groups filter를 통해 Application Resources 로 부터의 로그를 실시간으로 수집합니다. 특정 filter에 해당하는 Message가 발생 시 AWS Lambda는 Slack 의 #Issue-all 채널로 알림을 전송하게 됩니다.
(이 블로그에서는 Amazon CloudWatch Logs에서 수집할 수 있는 특정 Error를 예시로 설명)
AWS Lambda는 아래와 에러 로그를 수집하고 Slack으로 원문 메시지를 전달합니다.
(Function: message-to-slack)
[ERROR]"An error occurred (ClientException) when calling the RegisterTaskDefinition operation: Invalid 'cpu' setting for task."
Figure 6. Error Message 수신 담당자 확인
수신받은 메시지에 대해 “Watch/To bedrock agent/Reporting“ 3가지 버튼이 주어지게 되며, 팀원중 먼저 Watch를 선택 시 Thread에는 “xx님이 Watching 중 입니다.” 이라는 메시지가 달리며 팀원들은 동료가 이슈를 확인중임을 알 수 있습니다.
단계 3: 이슈 분석
1차 분석을 위해 To Bedrock Agent 버튼을 누르면 이 Error Message는 Slack과 연동된 AWS Chatbot Connector를 통해서 Amazon Bedrock Agents에 로그 분석을 요청합니다.
Figure 7. Amazon Bedrock Agents 를 호출하여 Error Message 1차 분석
그 밖에도 Slack의 Thread 내에서 AWS Chatbot과 연결된 Amazon Bedrock Agent Connector를 통해 추가적으로 “@aws ask connector name …”과 같이 Amazon Bedrock Agents 에 Alias 를 지정하여 문제 해결을 위한 대화를 통해 완성도 있는 분석을 수행해 나갑니다.
Figure 8. Amazon Bedrock Knowledge Bases 를 통해Error Message 2차 분석
이 과정에서 Amazon Bedrock Knowledge bases에 연동된 Amazon S3 (AWS FAQ Docs과 각종 애플리케이션, 솔루션 관련 플레이북)와 사내 장애 히스토리가 정리된 Wiki(Atlassian Confluence Workspace)가 RAG에 활용됩니다.
단계 4: 분석내용의 등록 및 자산화
Slack Thread에 누적된 대화내용과 작업 히스토리 그리고 Amazon Bedrock Agents 를 통해 분석한 내용을 자산화 하기 위해 Reporting 버튼을 눌러서 Atlassian Confluence 에 등록합니다. 등록된 결과는 해당 문제에 대한 원인/해결여부/참여자/해결과정
으로 요약되어 팀의 Atlassian Confluence에 게시글로 생성 됩니다.
Figure 9. 분석이 완료되고 자산화를 위한 Reporting 시 Atlassian Confluence에 요약 등록
이 Reporting 된 정보는 Amazon Bedrock Agents에 의해 팀을 위한 Knowledge bases로 재활용됩니다. 즉 장애대응을 위한 Amazon Bedrock Knowledge bases에 다시 이 해결 과정이 Sync 되면서 추후에 유사 이슈해결을 위한 가이드 역할을 하는 자산 형태로 운영이 가능합니다.
Figure 10. Atlassian Confluence 에 등록된 장애에 대한 요약 보고서
이러한 형태의 리포팅 히스토리를 모아서 Weekly, Monthly 형태로 요약하고 분석 한다면 좀 더 자동화 된 장애 분석이나 우리 회사가 운영중인 주요 서비스에 발생하는 장애 Trend 를 파악하는 용도로도 활용해 볼 수 있을 것 입니다.
솔루션 구성 요소:
본 문서에서 다루는 서비스와 역할에 대해 알아봅니다.
- Amazon Bedrock: Amazon Bedrock은 AWS의 생성형 AI 서비스로, Claude, AI21 Labs의 Jurassic-2, AWS Titan과 같은 대규모 언어 모델(LLM)을 제공합니다. 이를 통해 로그 분석, 문제 원인 파악, 해결 방안 제안, 자동 요약 생성 등 다양한 AI 작업을 수행할 수 있습니다.
- Agents for Amazon Bedrock: 워크플로를 간소화하고 반복적인 작업을 자동화며 사용자 요청을 처리하고, 필요한 정보를 수집하며, 효율적으로 응답을 생성하는 역할을 합니다.
- Amazon Bedrock Knowledge Bases: Amazon Bedrock의 파운데이션 모델(FM)을 회사 데이터에 안전하게 연결하여 검색 증강 생성(RAG)을 지원할 수 있습니다. 추가 데이터에 액세스하면 지속적으로 FM을 재훈련할 필요 없이 관련성이 높고 상황에 맞는 정확한 응답을 생성하는 데 도움이 됩니다. 운영팀의 경험과 과거 문제 해결 사례를 체계적으로 저장하여 LLM에게 학습 자료를 제공합니다. 이를 통해 응답은 지속적으로 개선되고 더 나은 결과를 도출할 수 있습니다. RAG(Retrieval Augmented Generation) 기술을 활용하여 데이터를 검색하고, 기초 모델의 프롬프트를 보강하여 보다 정확하고 관련성 높은 응답을 생성하도록 돕습니다. 아래는 RAG 의 기본적인 단계를 소개 합니다.
- 단계: 데이터 소스에서 문서를 가져와 벡터 데이터베이스에 저장합니다.
- 단계: 사용자 쿼리에 대해 적절한 데이터를 검색하여 기초 모델 프롬프트를 보강합니다.
- 단계: 검색된 정보를 기반으로 자연어 응답을 생성하거나 직접 인용문을 제공합니다
- AWS Lambda :이벤트에 대한 응답으로 코드를 실행하고 컴퓨팅 리소스를 자동으로 관리하는 컴퓨팅 서비스이며, 이 솔루션에서는 서버리스 컴퓨팅 환경에서 각종 로그 데이터 수신 및 Slack 내 Event 수행과 대화중인 Thread에 대해 Prompt를 통해 Atlassian Confluence 로의 Reporting 을 수행하게 됩니다. 이 과정을 수행하며 Atlassian Confluence는 지속적인 장애 히스토리를 업데이트 하며 향후 자산으로 활용할 수 있게 됩니다.
- AWS Chatbot: AWS Chatbot은 Microsoft Teams, Slack과 같은 협업 도구와 AWS 리소스를 연결합니다. 특히, 2024년 9월 17일에 출시된 Slack과 Agents for Amazon Bedrock 간 상호작용 기능은 운영팀이 Slack 내에서 직접 LLM과의 대화를 통해 장애 대응과 해결을 수행할 수 있도록 지원합니다.
- AWS Secrets Manager : 데이터베이스나 애플리케이션의 보안 인증, OAuth 토큰, API 키 및 기타 암호를 관리, 검색, 교체할 수 있습니다. 이 블로그에서는 AWS Lambda가 수행할 Task에 필요한 협업도구의 인증 정보들를 Secrets 으로 저장하고 AWS Lambda의 환경변수로 활용했습니다.
- Slack :운영팀이 익숙하게 사용하는 협업 도구로 Message 전달용 Bot과 연동하고AWS Chatbot과 통합하여 실시간 문제 해결을 Agents connector 로 수행합니다.
- Atlassian Confluence : 팀이 프로젝트나 아이디어를 통해 작업을 체계적으로 조직하고 공유하여 모든 팀원이 협업할 수 있는 도구이며, 팀의 지속적인 Knowledge Bases으로 활용 됩니다.
구현 방안
이 블로그에 소개해 드린 솔루션에 필요한 서비스를 소개해 드리겠습니다.
1. Pr-erequisites:
본 문서에 사용되는 서비스는 다음과 같으며 사전에 준비가 필요 합니다.
아래의 3가지는 사전에 준비가 필요하며, 각 인증 정보들을 통해 상호간 API 연동을 하게 됩니다.
- AWS Account 준비하기
- Amazon S3: IT운영팀이 활용할 기술 FAQ, 팀내 서비스 API, 장애 이력 같은 문서들을 적재합니다. 이 Amazon S3는 Amazon Bedrock Knowledge Bases 가 참조하게 됩니다.
- Slack 채널 생성
- AWS Lambda와 연동을 위한 Workspace ID, Channel ID, Bot Token 등의 정보를 확보해 둡니다.
- Atlassian Confluence 및 공간생성
- AWS Lambda와 안전한 API연동을 위한 Administer Personal Access Tokens, URL 정보 등이 필요합니다.
2. Amazon Bedrock Knowledge Bases 준비:
먼저 Amazon Bedrock Knowledge Bases 를 생성해 봅니다.
그리고 Data Source Type은 Amazon S3와 Atlassian Confluence 를 선택합니다. 이 Data Source 는 동시에 선택이 안 되므로 먼저 Amazon S3를 선택하여 Amazon Bedrock Knowledge Bases 생성을 완료한 뒤에 Atlassian Confluence 를 추가로 선택하시기를 권장 드립니다.
Atlassian Confluence 를 추가하기 위해서는 Atlassian Account의 API토큰 메뉴에서 API토큰을 미리 생성하고, Domain 정보도 확보해 둡니다.
위와같이 Atlassian Account에서 API토큰을 만들고 해당 정보를 AWS Secret Manger에 저장한 뒤 그 ARN을 Data Source 를 설정할 때 사용하면 됩니다.
다음은 Atlassian Confluence 를 추가 선택하는 과정입니다.
설정에서는 Authentication method 로 Basic Authentication 을 선택 후 인증을 위해 미리 생성해둔 AWS Secrets Manager Secret 의 ARN을 등록하여 Amazon Bedrock Knowledge Bases 와 Atlassian Confluence 간의 안전한 연결을 만듭니다.
생성된 Amazon Bedrock Knowledge Bases 의 Data Source 인 Atlassian Confluence 의 인증정보는 추후 AWS Lambda 의 환경변수에 등록하여 사용 됩니다.
이렇게 만들어진 Amazon Bedrock Knowledge Bases 에는 Data Source 가 2개 연결 되었습니다. 마지막으로 Data Source 에 대한 순차적 개별 동기화를 수행하여 Amazon Knowledge Bases 준비를 완료 합니다.
3. Amazon Bedrock Agents 생성:
다음은 Amazon Bedrock 을 호출할 Amazon Bedrock Agents 를 생성하는 화면입니다. Amazon Bedrock 을 통해 사용할 Foundation Model을 선택(Anthropic Claude 3.5 Sonnet v1)하고 Agent 의 역할, 수행할 작업과 사용자와 상호작용하는 방식을 명확히 정의해 줍니다. 저는 아래와 같이 지시사항을 부여했습니다.
명확한 지시 사항은 에이전트의 역할, 행동 방침, 기술적 제한 등을 포함하여 에이전트가 사용자와 효과적으로 상호작용할 수 있도록 도울 수 있습니다.
“You are an Agent supporting IT operators running the AWS cloud. If you receive questions about aws cloud in general from IT operators on slack, you should first check the S3 and Confluence wikis linked to Bedrock's knowledge base, and answer them accurately by summarizing them through Claude LLM selected by Bedrock. Of course, you must answer them in Korean. In summary, you are an agent for smooth communication between Slack and Bedrock. I'd like you to do your best to find and attach relevant URLs with evidence for the messages you receive. And please provide a solution as close to the correct answer as possible to resolve this issue."
이렇게 Agent 생성을 수행하고, 미리 생성한 Amazon Bedrock Knowledge Bases 와 연결시켜 줍니다.
이 Agent는 이제 앞서 선택한 FM모델과 Amazon Bedrock Knowledge Bases 의 Data Source 인 Amazon S3와 Atlassian Confluence를 활용해서 IT운영팀 질의에 대해 대응할 수 있습니다.
Agent 를 생성했다면 위와 같이 Alias도 생성합니다. 이 Alias는 추후 Slack에 배포된 AWS Chatbot에서 Agent Connector로 Amazon Bedrock 을 호출할 때 활용 됩니다.
4. 로그 수집용 Lambda Function 생성:
아래의 AWS Lambda 코드(message-to-slack)는 Python 으로 개발되었으며, Slack API를 사용하여 특정 채널에 메시지를 게시하는 기능을 수행하게 됩니다.
- Slack 메시지 전송: 메시지에는 오류 내용과 함께 User Interactive 을 위한 버튼이 포함되어 있어, 추가적인 조치를 취할 수 있도록 합니다.
5. AWS Chatbot을 생성하고 Slack과 연동:
AWS Chatbot 은 Amazon Chime 이나 Slack과 연동하여 업무 자동화를 구현할 수 있는 서비스 입니다. 최근에는 Slack 과 연동한 AWS Chatbot과 Amazon Bedrock Agents와의 통합을 기점으로 더욱 손쉽게 Slack뿐만아니라 Microsoft Teams 채팅 채널에서 직접 Amazon Bedrock Agent와 상호작용이 가능하게 되어 기존에 비해 훨씬 심플하게 Amazon Bedrock과의 연동을 할 수 있게 되었습니다. 이 블로그에서는 AWS Chatbot을 생성하여 Slack Channel에 배포하고 Guardrail policies 2개(ReadOnlyAccess, AmazonBedrockFullAccess)를 추가한 내용을 공유 드리며 자세한 설정방법은 Amazon Bedrock 에이전트 연결 설명서 페이지를 참조하세요.
Slack의 Channel에서 Amazon Bedrock Agents 가 Amazon Bedrock 의 FM(Foundation Model)을 호출하기 위해서는 최초 1회 Connector 설정이 필요 하며 그 방법은 아래와 같습니다.
설정이 완료 되었다면 이후 Slack에서 Amazon Bedrock Agents 를 활용하기 위해서는 아래와 같이 호출합니다.
@aws ask “connector 이름” 사용자 질문!!
6. Lambda와 통합할 API GW 생성:
이제 Slack Channel에서 분석한 내용을 요약하여 Atlassian Confluence 로 Reporting 하기 위한 요청을 수행하는 AWS Lambda 를 작성합니다. 이 때 Amazon API Gateway와 통합하게 되는데, Slack Channel에서 버튼으로 수행되는 Reporting 요청을 AWS Lambda 함수로 라우팅하는 역할을 합니다.
Amazon API Gateway에서 사용하는 Mapping Templates은 요청 또는 응답의 페이로드를 다른 형식으로 변환하기 위해 사용되는 스크립트입니다. 이 스크립트는 Amazon API Gateway가 AWS Lambda 함수와 같은 AWS 서비스와 통합될 때 데이터 형식을 조정하는 데 유용합니다. Mapping Templates 역할 은 다음과 같습니다.
- 데이터 변환: 클라이언트가 보내는 요청의 페이로드를 AWS Lambda 함수가 이해할 수 있는 형식으로 변환하거나, 반대로 AWS Lambda 함수의 응답을 클라이언트가 이해할 수 있는 형식으로 변환합니다.
- 파라미터 매핑: 경로 파라미터, 쿼리 스트링 파라미터, 헤더 파라미터 등을 Amazon API Gateway의 요청 메서드에 연결하여 사용합니다.
Slack에서는 Amazon API Gateway의Endpoint 를 호출하고 그에 통합된 AWS Lambda는 이 Invoke URL 을 트리거로 함수가 수행하게 됩니다.
7. Slack 설정하기:
최초 AWS Lambda로 부터 Slack Channel 로 수신되는 원본 Error Message 에 대해 3가지 Action[Watching | To Bedrock Agent | Reporting]
을 담당자가 할 수 있게 도와주는 역할을 제공하는 Slack App 을 하나 생성합니다. 이 App은 Slack에서 각 버튼을 선택하면 사용자의 요청을 수행해 주며, 즉시 결과를 Thread 에 알립니다.
이 Slack App은 Atlassian Confluence Reporting 요청도 담당하기 때문에 아래와 같이 Slack App 설정화면에서 Interactivity Request URL 을 지정해 줍니다. 기재할 URL은 위에서 Amazon API Gateway 와 통합된 Amazon API Gateway의Endpoint 입니다.
Slack App은 Slack 내에서의 사용자 버튼 Action 에 대해 Reporting 요청도 수행하게 됩니다. 이러한 상호작용을 위해서 Slack App의 OAuth Token 값이 필요한데 이 블로그에서는 AWS Lambda에서 안전한 API 연동을 위해 Slack OAuth Token, Atlassian Confluence API Key와 URL정보, Amazon Bedrock Agents와 Alias까지 AWS Secret Manager 에 저장 했으며
AWS Lambda에서는 여기에 저장된 ws/chatops/secret 값을 환경변수로 설정하여 보안에 유의했습니다.
Slack 의 OAuth Token을 발급하고 Permission scopes 을 잘 설정해 줘야 Slack App과 User간의 원활한 대화가 가능 합니다. 이 블로그에서 소개하는 구성에선 아래의 옵션들을 추가했으니 참고 하세요.
assistant:write, channels:history , channels:read, channels:write.topic, chat:write, chat:write.public, groups:history, groups:write, im:history, incoming-webhook, mpim:history
8. Confluence Reporting용 Lambda Function:
이 AWS Lambda 코드(gw-to-slack)는 AWS Lambda 환경에서 Slack과 Atlassian Confluence, 그리고 AWS Bedrock Agents를 통합하여 다양한 작업을 수행하는 역할을 합니다.
- 실시간 오류 알림 및 분석: Slack에서 발생하는 오류 메시지를 실시간으로 알리고, AWS Bedrock Agents를 통해 자동으로 분석할 수 있습니다.
- 협업 및 문서화 지원: 분석된 결과를 Atlassian Confluence에 문서화하여 팀원들과 공유할 수 있도록 합니다. 이는 협업을 강화하고 정보의 중앙 집중화 그리고 분석된 내용을 업데이트 하며 자산화를 할 수 있습니다.
- get_secret() 함수는 AWS Secrets Manager에서 Slack 토큰, Atlassian Confluence API 키 등 필요한 Secrets value를 가져옵니다.
- get_user_name() 함수는 Slack API를 사용하여 사용자 ID로부터 사용자 이름을 가져옵니다. 이는 캐시를 사용하여 반복 호출을 줄입니다.
- send_slack_message() 함수는 지정된 채널에 메시지를 전송하게 되는데 이는 Slack API의postMessage 엔드포인트를 사용하여 수행됩니다.
- create_confluence_page() 함수는 주어진 내용을 Atlassian Confluence에 새로운 페이지로 생성하게 되는데 Atlassian Confluence API를 사용합니다.
- invoke_bedrock_agent() 함수는 AWS Bedrock Agent를 호출하여 error_message를 분석하거나 요약합니다.
마무리
지금까지 Amazon Bedrock 과 Claude 3.5 Sonnet 모델 그리고 연관된 서비스인 Amazon Bedrock Agents, Amazon Bedrock Knowledge bases와 Slack의 통합은 IT 운영팀이 직면한 주요 문제를 해결하는 데 있어 신속한 도구로 활용할 수 있음을 확인했습니다. 또한 다양한 형태의 실시간 오류 분석과 대응, 효율적인 협업 환경을 통한 히스토리의 자산화를 자동화 하며 업무의 생산성과 효율성을 높일 수 있었습니다.
이 블로그에서 공유드린 내용은 아직 작은 일부분이지만 앞으로 생성형AI 기술이 더욱 발전함에 따라, IT운영을 위한 솔루션은 계속 확장해 나갈 수 있을 것입니다. 생성형 AI기반의 클라우드 운영을 통해서 IT 운영팀은 더 복잡하고 전략적인 과제에 집중할 수 있을 것입니다. 지금 바로 AWS Bedrock과 AWS Chatbot을 기업에서 사용하는 다양한 협업 도구들과 활용하여 클라우드 운영 환경을 변화시켜 보세요.
또한 솔루션에 사용되는 AWS의 서비스들의 자세한 자료와 활용사례를 참고해 보세요.
- Amazon Bedrock의 기능에 대해 더 자세히 알아보고 싶으신 경우, Amazon Bedrock Workshop을 참고하세요.
- RAG 구축 시 활용된 Amazon Bedrock의 Knowledge base를 직접 사용해보고 싶으시다면, 다음 블로그를 읽어보시는 것을 추천 드립니다: Amazon Bedrock Knowledge base로 30분 만에 멀티모달 RAG 챗봇 구축하기 실전 가이드
- Amazon Bedrock Knowledge base 및 Agent를 활용한 또다른 챗봇 활용 사례를 다음 블로그에서 확인해 보세요: 오늘의집 비서, ‘오집사’ 개발 여정
- Amazon Bedrock용 Knowledge bases, 추가 데이터 커넥터 지원에 대한 내용은 다음 블로그에서 확인해 보세요.