🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

TReNDS는 애플리케이션 오류를 실시간으로 감지하고 주변 로그와 깃허브 소스 코드를 수집한 뒤, 아마존 베드록 기반 에이전트가 근본 원인과 수정 방향을 분석해 팀에 전달하는 운영 파이프라인을 구축했다.

📌 핵심 요약

• TReNDS는 2019년부터 연구 도구와 API를 아마존 EKS에서 운영하고 FluentBit으로 로그를 아마존 클라우드워치에 전송해 왔지만, 애플리케이션 증가와 함께 오류 조사 부담도 커졌다.
• 기존 모니터링은 장애 발생 사실만 알려 주었으며, 엔지니어가 스택 추적과 소스 파일을 직접 대조해 원인을 찾는 데 단순 오류도 15~30분, 여러 서비스가 얽힌 오류는 그 이상이 걸렸다.
• 구축된 시스템은 클라우드워치 구독 필터가 오류 패턴을 탐지하면 람다를 호출하고, 스트랜즈 에이전트가 같은 컨테이너의 주변 로그와 깃허브 소스 코드를 가져와 조사하도록 구성됐다.
• 아마존 베드록의 기반 모델이 오류와 코드의 관계를 추론하고, 스트랜즈 에이전트 SDK는 모델이 필요한 도구를 상황에 따라 선택하고 호출할 수 있도록 조율한다.
• 분석 결과는 심각도, 근본 원인, 관련 소스 코드, 권장 수정 사항, 영향 가능 영역을 포함하는 구조로 작성되며 SNS를 통해 이메일과 슬랙으로 전달된다.

🧩 주요 포인트

1. 장애 탐지와 원인 규명은 별개의 문제였고, TReNDS는 수작업 조사에 가장 많은 시간이 소요된다는 사실을 근거로 근본 원인 분석 자체를 자동화 대상으로 삼았다.
2. 오류 한 줄만 해석하지 않고 동일 로그 스트림의 시간대별 기록과 실제 소스 코드를 함께 제공함으로써, 단순 패턴 요약이 아니라 실행 경로와 실패 지점을 추적할 수 있게 했다.
3. 출력 형식은 시스템 프롬프트로 통제하되 조사 순서는 모델에 맡겨, 미리 모든 오류별 의사결정 트리를 작성하지 않고도 스택 추적 유무와 코드 구조에 맞춰 조사 경로를 바꿀 수 있게 했다.

🧠 상세 정리

1. TReNDS의 운영 환경과 조사 부담

TReNDS는 조지아주립대학교, 조지아공과대학교, 에모리대학교가 공동으로 참여하는 센터로, 뇌 건강 연구를 위한 고급 분석 방법과 신경정보학 도구를 개발하고 적용한다. 이 센터는 2019년부터 아마존 웹 서비스에서 인프라를 운영했으며, 연구 도구와 API를 포함한 다양한 애플리케이션을 아마존 EKS에 배치했다. 애플리케이션 로그는 FluentBit을 통해 아마존 클라우드워치로 전송됐지만, 서비스와 오류의 양이 늘면서 엔지니어가 조사해야 할 사건도 함께 증가했다. 기존 경보 체계는 무엇인가 실패했다는 사실을 알려 주었을 뿐, 왜 실패했는지까지 설명하지 못했기 때문에 엔지니어가 로그, 스택 추적, 소스 파일과 실행 경로를 직접 대조해야 했다. 단순한 오류도 조사에 15~30분이 걸렸고, 여러 서비스에 걸친 복잡한 문제는 훨씬 더 오랜 시간이 필요했다.

2. 자동 근본 원인 분석의 목표와 전체 구조

TReNDS는 적절한 도구를 사용할 수 있는 기반 모델이라면 주변 로그를 읽고 관련 소스 코드를 확인하면서 근본 원인을 조사할 수 있다고 판단했다. 구축된 구조에서는 EKS 애플리케이션의 로그가 FluentBit을 거쳐 클라우드워치로 들어가고, 구독 필터가 ERROR, Exception, FATAL, CRITICAL 같은 오류 수준 패턴을 감시한다. 일치하는 이벤트가 발생하면 구독 필터가 람다 함수를 호출하고, 람다 내부의 스트랜즈 에이전트가 오류 조사를 시작한다. 에이전트는 전달받은 오류만 요약하지 않고 추가 로그 문맥과 깃허브 소스 코드를 확보한 뒤 오류, 코드, 실행 경로 사이의 관계를 분석한다. 완성된 분석은 아마존 SNS 주제로 발행되어 운영 팀이 사용하는 알림 채널로 전달된다.

3. 아마존 베드록과 스트랜즈 에이전트의 역할

시스템에서 오류와 코드의 관계를 실제로 추론하고 근본 원인을 판단하는 구성 요소는 아마존 베드록의 기반 모델이다. 스트랜즈 에이전트 SDK는 모델 위에서 도구 사용을 조율하며, 개발자는 사용할 수 있는 도구를 정의하지만 어떤 도구를 언제 어떤 순서로 호출할지는 모델이 조사 과정에서 결정한다. 예를 들어 스택 추적에 파일 경로가 있으면 관련 소스 파일을 가져오고, 처음 확인한 코드가 공용 유틸리티나 의존 구성 요소를 가리키면 추가 코드를 따라갈 수 있다. 이 방식은 조사 경로를 오류 종류별로 하드코딩한 규칙 기반 체계와 달리, 에이전트가 확보한 증거에 맞춰 다음 행동을 선택하게 한다. 따라서 핵심은 언어 모델의 단순 오류 메시지 요약이 아니라, 로그 및 코드 조회 도구와 추론을 결합한 자율적 조사 과정에 있다.

4. 데이터 경계와 적용 조건

TReNDS는 건강 관련 연구 데이터를 다루기 때문에 데이터 상주 위치와 규정 준수 가능성을 중요한 조건으로 고려했다. 원문에 따르면 아마존 베드록 요청은 해당 AWS 계정 안에서 처리되므로, 조사에 사용되는 로그 데이터와 소스 코드를 외부 분석 엔드포인트로 전송하지 않고 기존 애플리케이션 환경과 같은 관리 경계 안에 둘 수 있다. 이는 HIPAA 요건이 적용될 가능성이 있는 건강 관련 연구 데이터를 취급하는 TReNDS의 상황에서 특히 중요한 요소로 제시됐다. 다만 소개된 구조와 권고는 TReNDS 팀의 실제 운영 경험을 반영한 것이며, 참여 대학들의 공식 지침을 의미하지는 않는다. 또한 EKS와 FluentBit을 사용한 구현이 중심이지만, 클라우드워치로 로그를 전송할 수 있다면 ECS, 람다, EC2 또는 클라우드워치 에이전트를 사용하는 온프레미스 작업에도 같은 패턴을 적용할 수 있다고 설명한다.

5. 구현에 필요한 구성 요소와 권한

제시된 구현을 위해서는 앤트로픽 클로드 소넷을 사용할 수 있는 아마존 베드록 접근 권한이 있는 AWS 계정이 필요하다. 애플리케이션 로그를 FluentBit으로 클라우드워치에 전송하는 EKS 클러스터와 구독 필터가 설정된 로그 그룹, 분석 대상 애플리케이션의 소스 코드가 저장된 깃허브 저장소도 전제된다. 에이전트 구현에는 스트랜즈 에이전트 SDK와 파이썬 사용 경험이 필요하며, 배포 시에는 SDK를 직접 묶는 대신 공식 람다 계층을 사용할 수 있다. 알림 전달을 위한 아마존 SNS 주제도 미리 구성해야 한다. 람다 함수에는 아마존 베드록, 클라우드워치 로그, AWS 시크릿 매니저, SNS에 접근할 수 있는 적절한 IAM 권한이 부여되어야 한다.

6. 깃허브 소스 코드 조회 도구

에이전트에 제공된 도구 가운데 가장 중요한 기능은 스택 추적에 나타난 파일의 실제 구현을 읽을 수 있게 하는 소스 코드 조회 도구다. 예시의 fetch_source_code 함수는 스트랜즈의 @tool 장식자를 사용하고, 저장소 내부 파일 경로와 소유자 및 저장소 형식의 식별자를 인수로 받는다. 깃허브 토큰은 AWS 시크릿 매니저에서 가져오며, 함수는 깃허브 콘텐츠 API를 호출한 뒤 응답에 포함된 베이스64 형식의 내용을 디코딩해 문자열로 반환한다. 요청이 성공하지 않으면 대상 파일과 저장소, HTTP 상태를 포함한 오류 메시지를 돌려주도록 작성됐다. 함수의 설명문과 자료형 힌트는 스트랜즈가 모델에 도구의 용도와 필요한 매개변수를 알려 주는 근거가 되며, 모델은 오류에서 발견한 정보에 따라 이 도구의 호출 여부를 결정한다.

7. 클라우드워치 이벤트 해제와 주변 로그 수집

클라우드워치 구독 필터는 베이스64로 인코딩되고 gzip으로 압축된 로그 이벤트를 람다에 전달하며, 한 번의 호출에는 짧은 시간 구간에서 필터와 일치한 이벤트가 하나 이상 포함될 수 있다. 람다 처리기는 이 데이터를 해제한 뒤 로그 그룹 이름과 일치한 이벤트를 추출해 에이전트 분석에 넘긴다. 그러나 필터가 전달한 단일 오류 행만으로는 원인을 판단하기 어려우므로, TReNDS는 오류를 낸 특정 컨테이너의 로그 스트림에서 주변 기록을 가져오는 별도의 도구를 만들었다. fetch_log_context 도구는 로그 그룹, 로그 스트림, 오류 시각과 기본 30초의 전후 시간 창을 받아 해당 범위의 메시지를 시간 순서대로 결합한다. 이렇게 로그 스트림을 한정하면 다른 동시 요청의 잡음을 줄이면서 오류를 유발한 요청, 앞서 발생한 경고, 전체 예외 추적을 같은 컨테이너의 연속된 문맥으로 확보할 수 있다.

8. 자율 분석과 결과 전달

에이전트는 오류와 주변 로그를 받은 뒤 스택 추적의 파일 경로와 클래스 이름을 해석하고, 필요한 소스 파일과 추가 문맥을 스스로 선택해 조회한다. 스택 추적이 명확하지 않은 오류라면 오류 메시지 문자열을 코드베이스에서 검색하는 방향으로 조사할 수 있어, 개발자가 가능한 모든 오류 유형의 결정 트리를 미리 작성할 필요가 없다. 시스템 프롬프트는 에이전트를 운영 오류를 분석하는 선임 사이트 신뢰성 엔지니어 역할로 설정하고, 심각도, 근본 원인 설명, 관련 소스 코드, 권장 수정 사항, 영향 가능 영역을 포함하도록 출력 구조를 지정한다. 람다 처리기는 선택한 베드록 모델과 이 프롬프트, 소스 조회·코드 검색·로그 문맥 조회 도구를 에이전트에 제공한 뒤 로그 그룹과 오류 메시지를 전달해 조사 반복을 시작한다. 분석이 끝나면 결과는 SNS를 통해 이메일과 슬랙으로 배포되며, 제시된 예시에서는 결제 게이트웨이 시간 초과 시 null이 될 수 있는 응답을 검사하지 않고 거래 식별자에 접근한 코드가 높은 심각도의 NullPointerException 원인으로 식별됐다.

🧾 핵심 주장 / 시사점

• 이 구조의 핵심 차별점은 오류 문구를 자연어로 바꾸는 데 있지 않고, 동일 컨테이너의 로그와 실제 소스 코드를 증거로 확보한 뒤 실행 경로를 추적하도록 모델에 도구를 제공한 데 있다.
• 로그 그룹 전체가 아니라 오류를 생성한 로그 스트림과 제한된 시간 창을 조회하면, 조사에 필요한 요청·경고·예외 흐름은 유지하면서 동시 요청에서 발생하는 불필요한 로그를 줄일 수 있다.
• 시스템 프롬프트는 결과의 필수 항목을 표준화하고 도구 선택은 모델에 맡기므로, 보고 형식의 일관성과 오류 유형에 따른 조사 유연성을 함께 확보하는 설계다.

✅ 액션 아이템

• 장애 탐지와 근본 원인 분석을 분리하고, 수작업 조사 시간이 가장 긴 오류 유형부터 자동화 대상으로 우선순위를 정한다.
• 오류 한 줄이 아니라 동일 로그 스트림의 시간대별 기록과 깃허브 소스를 함께 넘겨 실행 경로와 실패 지점을 추적하도록 입력 범위를 정의한다.
• 출력은 심각도·근본 원인·관련 코드·권장 수정·영향 영역으로 고정하고, 조사 순서는 스택 추적 유무와 코드 구조에 맞춰 모델이 바꾸게 둔다.

❓ 열린 질문

• 단순 오류 15~30분, 다중 서비스 오류는 그 이상인 현재 조사 시간 중 어떤 구간을 먼저 줄이는 것이 효과적인가?
• 클라우드워치 구독 필터가 람다와 스트랜즈 에이전트를 호출할 때, 같은 컨테이너 주변 로그의 시간 창은 어디까지로 잡을 것인가?
• 시스템 프롬프트로 출력 형식만 통제할 때, 권장 수정과 영향 가능 영역의 신뢰도를 어떤 기준으로 판단할 것인가?