활용 시나리오

Sophonz AI Agent가 실제 에러를 발견하고 이슈와 코드 수정 PR/MR을 자동으로 생성하는 엔드투엔드 시나리오를 설명합니다.

Sophonz AI Agent가 프로덕션 에러를 어떻게 처리하는지, 정기 자동 점검부터 맞춤 조사 요청까지 주요 시나리오를 단계별로 살펴봅니다.

시나리오 1 — 정기 자동 점검

상황. 개발팀이 직접 대시보드를 열지 않아도, 에이전트가 정해진 주기로 새 에러를 감지하고 이슈·수정 PR/MR·테스트·코드 리뷰까지 자동으로 완료합니다.

스케줄 트리거 — 설정된 cron 일정에 따라 에이전트 실행이 시작됩니다. 이전 성공 실행 이후의 시간 윈도를 기준으로 새 에러만 조회하며, 이미 처리한 그룹은 건너뜁니다.
에러 선별 — Observability Agent가 Sophonz 텔레메트리에서 가장 영향이 큰 에러 그룹 1~3개를 선별하고, 각 그룹의 스택 트레이스 상위 프레임을 복원합니다.
코드 분석 및 수정안 작성 — Engineering Agent가 리포지토리를 탐색해 원인 파일을 찾고 수정 브랜치를 생성합니다. 변경이 필요한 각 파일의 전체 내용을 담아 커밋하고, 스택 트레이스·원인·수정 근거를 본문에 포함한 이슈와 MR/PR을 자동으로 엽니다.
회귀 방지 테스트 추가 — Test Engineer Agent가 같은 MR/PR에 단위 테스트를 추가 커밋합니다. 필요하면 CI 파이프라인에 테스트 잡도 추가합니다.
통합 코드 리뷰 — Critic Agent가 이슈, 수정 코드, 테스트, CI 변경을 종합 검토하고 MR/PR에 리뷰 코멘트를 남깁니다. 수정이 문제를 실제로 해결하는지, 부작용은 없는지, 회귀 방지가 충분한지를 평가합니다.
개발자 머지 승인 — 모든 자동 처리가 끝난 MR/PR을 개발자가 검토하고 머지합니다. 자동 머지는 발생하지 않습니다.

NOTE — 중복 처리 방지

에이전트는 이미 처리한 에러 그룹 목록을 추적합니다. 같은 에러가 다음 실행 때 다시 들어와도 중복 이슈·MR이 생성되지 않습니다.

상황. 야간에 예상치 못한 크래시 급증 알림을 받았습니다. 다음 정기 점검까지 기다리지 않고 지금 바로 분석을 시작하고 싶습니다.

수동 트리거 — 대시보드의 "지금 실행" 버튼을 클릭합니다. 내부적으로 정기 점검과 동일한 파이프라인이 triggerType=manual로 실행됩니다.
이후 흐름은 시나리오 1과 동일합니다. Observability → Engineering → Test Engineer → Critic 순서로 진행됩니다.

TIP — 효과

개발자가 여러 도구를 오가며 수동으로 처리하던 작업을 버튼 클릭 한 번과 머지 승인 한 번으로 처리할 수 있습니다. 일반적으로 수 시간이 걸리던 초기 대응 시간이 수 분으로 단축됩니다.

상황. 정기 모니터링이 잡지 못한 특정 시간대·특정 서비스 타입의 에러를 조사하고 싶습니다. 예를 들어 결제 화면에서 특정 시간대에만 발생한 에러의 원인을 파악하고 코드 수정안을 받고 싶습니다.

예시 커머스 앱의 2026-05-20 14:00~15:00 KST 구간 Android 크래시를
분석하고 코드 수정안까지 작성해줘.

요청 생성 — 대시보드에서 프로젝트와 자연어 본문(시간 범위 포함)을 입력해 조사 요청을 만듭니다. 요청 상태가 running으로 시작됩니다.
에러 조회 — Observability Agent가 요청 본문의 시간 범위를 그대로 사용해 해당 구간의 에러를 조회하고, 가장 영향이 큰 fingerprint의 스택 트레이스를 복원합니다.
수정안 작성 — Engineering Agent가 리포지토리 코드를 읽어 원인 파일을 특정하고, 수정이 필요한 각 파일의 전체 내용을 담아 회신합니다. 이 단계에서는 코드를 직접 커밋하지 않습니다.
diff 검토 대기 — 요청 상태가 awaiting_review로 전환됩니다. 개발자가 변경 내용 diff를 확인합니다.
승인 또는 수정 요청 — 개발자가 Approve하면 MR/PR이 생성되고 요청이 완료됩니다. Changes Requested를 선택하면 새 시도가 시작되어 같은 흐름을 다시 거칩니다.

NOTE — 검토 게이트

맞춤 조사 요청은 개발자가 diff를 직접 확인한 뒤에만 MR/PR이 생성됩니다. 자동 점검과 달리 코드 반영 전 단계에서 사람이 반드시 개입합니다.

상황. 예시 커머스 앱의 결제 화면에서 처음 발견된 네트워크 에러가 P1 심각도로 분류되었습니다. 이후 같은 유형의 에러가 다른 화면에서도 산발적으로 발생합니다.

최초 발견 — 에이전트가 네트워크 에러를 처음 탐지하면, 영향 범위와 발생 패턴을 분석해 높은 심각도 라벨(critical, network 등)과 함께 P1 이슈를 생성합니다.
후속 발생 분류 — 같은 에러 그룹의 후속 발생에 대해서는 이미 분류된 그룹임을 인식하고, 톤과 제목 접두사·라벨을 조정해 일반 버그 이슈로 생성합니다.
Critic의 재평가 — Critic Agent는 수정 이후에도 동일 에러가 재발하거나 영향이 예상보다 크다고 판단되면, 리뷰 코멘트를 통해 심각도 재산정을 제안합니다.

TIP — 의의

단순히 버그를 고치는 것에서 나아가, 같은 유형의 에러가 다시 발생했을 때 더 빠르게 우선순위가 결정됩니다. 반복 패턴에 대한 처리 방식이 누적될수록 이후 실행의 정확도가 높아집니다.

정기 자동 점검이 활성화된 상태에서 개발자가 매일 수행하는 작업은 다음과 같이 단순해집니다.