Infra that fixes itself, thanks to coding agents - Mahmoud Abdelwahab, Railway

영상 링크: Infra that fixes itself, thanks to coding agents — Mahmoud Abdelwahab, Railway
채널명: AI Engineer

코딩 에이전트를 통한 자동 인프라 복구 데모 핵심 요약

• 영상에서는 앱 인프라가 스스로 오류를 감지하고, 코딩 에이전트를 통해 자동으로 문제를 수정하는 과정을 Railway 플랫폼 기반 데모로 시연함
• 대표적 예시로 메모리릭, 500 에러, 높은 응답 시간 등 운영 서비스에서 자주 발생하는 오류 탐지 과정을 실시간 데이터(메트릭) 분석으로 설명
• 단순 임계치 기반 알림 시스템과 달리, 일정 주기(10~30분)에 워크플로를 실행하여 서비스 헬스 및 장애 발생 영역을 전체적으로 빠짐 없이 진단함을 강조
• 진단 순서: 배포된 서비스 구조 파악 → 각 서비스별 리소스(메모리/CPU) 및 HTTP 에러/지연율 집계 → 임계치 초과/문제 서비스 목록화
• 문제가 감지되면 관련 로그, 코드 베이스 및 외부 의존성(예: 외부 API status)을 추가 조사하여 상세 맥락 정보를 확보
• 이 모든 데이터를 AI 코딩 에이전트에게 전달, 상세한 장애 분석 및 수정 플랜이 자동 생성됨
• 수정안 생성과 적용: 에이전트가 리포 클론→수정점 구현→자동 풀리퀘스트 발송까지 전체 자동화됨(오픈소스 에이전트 ‘open code’ 활용)
• ‘durable execution’ 워크플로 구조를 적용해, 단계별 캐싱 및 자동 재실행이 가능해 복원력(내결함성)과 효율성 상승
• ‘open code’는 오픈소스 단말기 코딩 에이전트로, 서버 모드에서 API를 통해 자동 풀리퀘스트, 코드 수정, 파일시스템 접근에 활용됨
• 실제 데모에선 서비스 전체 상태 점검 → 문제 서비스 상세 정보 수집 → AI 분석/수정 플랜 작성 → 풀리퀘스트 발송까지 자동화 흐름이 실현됨
• 최종적으로 모든 변경점, 원인분석, 수정사항이 풀리퀘스트에 요약되어 운용자의 수동 개입 없이 빠르게 배포 가능함을 시연

세부 요약 - 주제별 정리

앱 인프라 문제는 사전에 자동 감지되어야 하며 빠른 복구가 전제되어야 함

• Railway 대시보드에서 운영 서비스 다수를 시각화해 보여주며, 이들 서비스는 각각 다양한 버그(메모리릭, 500 에러 등)를 내포하고 있음
• 메모리릭 케이스: 메모리 사용량이 지속적으로 증가해 서버가 곧 다운될 위기임을 보여줌
• 500 에러가 94%에 달하고 응답시간도 수 초에 이를 정도로 치명적임
• 만약 실서비스에서 이런 일이 발생하면 운영자가 비상 호출(paging)을 받고 즉각적인 복구 작업에 돌입해야 함
• 일부 문제는 확연히 드러나지만, 어떤 서비스 문제(예: 느린 DB 쿼리)는 메트릭만 보았을 때 쉽게 드러나지 않음. 이로 인해 사용자는 실제 체감 성능 저하(30초 이상 대기)를 경험하게 됨

기존 임계치 알림 시스템은 한계가 있으며 탐지~수정까지 수동 절차가 과도함

• CPU, 메모리, 에러율 등에 임계치를 세팅하고 이를 넘어서면 알람을 받는 구조가 대다수임
• 알람 이후에도 운용자는 직접 로그, 트레이스, 메트릭 등을 파헤치며 원인을 찾아 수동으로 수정해야 함
• 반복적이고 수동적인 조사~수정 과정은 비효율적이고 장애 대응 지연 초래

일정 주기 워크플로 기반 진단은 순간 임계치 알림 시스템 대비 더 포괄적이고 신뢰성 높음을 강조함

• 서비스 상태를 일정 주기(10, 15, 30분 등)마다 진단하는 워크플로를 구현
• 각 워크플로는 서비스 아키텍처 파악 → 각 서비스별 CPU/메모리 등 리소스 수치 확보 → HTTP 에러율 등 지표 확인 → 임계치 초과 서비스 목록화
• 단편적 임계치 알림이 아니라 일정 시간 슬라이스 전체를 분석해 신호 잡음을 줄이고 종합적으로 현황 파악 가능
• 일정 순간 피크값(예: 순간 CPU 80% 초과)이 서비스 구성에 악영향 미치지 않을 때도 빈번하므로, 일정 주기 전체 분석이 더 실효성이 높음

문제 서비스는 상세 맥락 및 외부 의존성까지 추가 확인해 근본 원인을 입체적으로 파악함

• 임계치 초과 서비스는 추가로 운영 로그, 빌드/배포 로그, 코드베이스(저장소) 분석을 통해 컨텍스트 확보
• 코드 분석을 통해 외부(업스트림) API, 예를 들어 결제 API 등과의 연결을 파악하고, 해당 API 서비스 장애가 감지되면 ‘대기’ 지침까지 내릴 수 있음
• 이런 추가 정보까지 종합해, 단순 리소스 초과인지, 진짜 오류(버그)인지, 외부 원인에 의한 장애인지 구분할 수 있음

AI 코딩 에이전트에게 모든 맥락 정보를 전달, 자동 분석&수정 플랜을 생성함

• 조사된 프로젝트 구조, 각 서비스별 장애/리소스 상세, 로그, 의존성 등 모든 정보를 마크다운 형태로 에이전트로 전달
• 에이전트(LLM 등)는 종합 분석을 통해 수정 플랜/디버깅 체크리스트/수정 코드 등의 상세 작업 계획 수립
• 예시로, 오류 재현(동일 부하로 로컬 테스트), 오류 조건/원인 명시, 수정 방법 제시 등 자동 생성

워크플로 엔진은 내결함성 작업 분할 및 단계별 재시작(‘durable execution’)로 복잡한 추적/실행을 단순화함

• 각 워크플로(지속 실행 작업)는 단계별로 캐시됨
• 예: 영상 업로드 후 → 전사 → 요약 → DB 저장 작업이 있을 때, 마지막 DB 저장만 실패해도, 재실행 시 이전 성공 단계(전사/요약) 결과는 재활용됨
• 각 단계는 실패 시 자동 재시도(exponential backoff 등 옵션 가능)
• 이는 API 호출, 메트릭 집계, 로그 수집 등 모든 복잡한 작업의 신뢰성 및 효율 대폭 향상

오픈소스 에이전트 ‘open code’ 도입으로 자동 코드 수정 및 pull request까지 완전자동화됨

• open code는 오픈소스 터미널/서버 AI 코딩 에이전트임
• cloud code와 유사하지만, 오픈소스이므로 LLM 모델·API 프로바이더 자유 선택 가능
• 서버 모드로 headless 운용, API 통해 외부 워크플로와 통신 가능, 오토 PR, 코드 수정, 파일시스템 접근, git 연동 등 모든 자동화 인프라 작업 가능
• railway 환경에서는 Dockerfile로 오픈코드와 모든 필요 도구(curl, jq, git, GitHub CLI 등) 구성해 배포

실제 데모 시나리오에서 전체 자동화 흐름이 실시간으로 증명됨

• ‘monitor project health’ 워크플로에서 프로젝트 아키텍처, 서비스/DB/볼륨 등 인프라 현황, 각 서비스별 리소스/에러/지연/상태까지 상세 집계
• 각종 HTTP, 빌드/배포 로그도 모두 자동 수집함
• 분석된 데이터는 깔끔히 포맷팅되어 AI 에이전트로 이관
• 다음 단계에서 ‘generate fix’ 워크플로가 AI 분석→디버깅/수정 플랜 생성→세션 생성→풀리퀘스트 자동 오픈이라는 자동화 흐름을 거침
• 실제 데모에서 문제 서비스 탐지→상세 맥락 분석→자동 수정 생성→실제 PR 오픈(수정분, 원인 요약, 수정 내역 포함)까지 모두 실시간 시연

최종적으로 도입 구조는 인프라 문제의 감지, 분석, 수정 제안 및 풀리퀘스트 생성까지 완전 자동화로 연결됨

• PR에는 모든 주요 변경점, 에이전트 분석요약, 원인 상세, 수정내역 등이 자동 기재됨
• 운용자는 수동 코드 분석, 로깅, PR 생성 과정 없이 간단히 PR만 리뷰&머지하면 배포 완료됨
• 운영 중 장애 대응의 ‘탐지수정배포’ 전 과정을 획기적으로 단축/자동화할 새로운 패러다임 사례를 제시함