프로덕션 크래시와 수정 사이의 시간 단축

Source: Dev.to

문제

코드를 배포하고, 모든 것이 정상적으로 동작한다— 그런데 갑자기 프로덕션에서 크래시가 발생한다.

잘 모니터링된 시스템이라 할지라도 조사 과정은 보통 다음과 같다:

• 모니터링 알림 확인
• 로그를 파헤치기
• 코드베이스 검색
• 문제를 재현해 보기
• 수정사항 작성
• 풀 리퀘스트 열기

많은 팀에서 이 과정은 쉽게 몇 시간씩 걸릴 수 있다.

Crashloom 소개

수년간 복잡한 애플리케이션과 중요한 데이터 워크플로를 다루면서, 이 조사 과정의 일부를 자동화할 수 있지 않을까 하는 생각이 들었다.

크래시 감지와 검증된 수정 사이의 루프를 단축할 수 있을까?

이것이 바로 Crashloom을 만들게 된 계기다.

Crashloom은 AI 에이전트를 활용해 크래시를 조사하고, 잠재적인 근본 원인을 식별하며, 풀 리퀘스트를 만들기 전에 검증 가능한 수정안을 제안하는 실험이다.

목표는 개발자가 조사 워크플로를 수행하는 데 도움을 주어, 프로덕션 크래시와 안전한 수정 사이의 시간을 줄이는 것이다.

작동 방식

crash → investigation → sandbox validation → pull request

피드백 요청

프로젝트는 아직 초기 단계이며, 다른 팀들이 오늘날 프로덕션 인시던트를 어떻게 처리하고 있는지 궁금하다.

크래시 감지 → 머지된 수정까지 보통 얼마나 걸리는지 알려주세요.