홈 › 오류로부터 PR 초안을 작성하는 AI
가이드 · 자율 엔지니어링
오류 보고서로부터 풀 리퀘스트 초안을 작성하는 AI
실제로 비용을 지불하는 워크플로우.
2026년의 수동 버그 분류는 다음과 같습니다:
- Sentry 경고 발생.
- 누군가 알림을 받습니다 (근무 시간 외에는 아침까지 기다립니다).
- 엔지니어가 Sentry를 열고, 스택 트레이스를 읽고, 코드베이스를 엽니다.
- 주변 코드를 읽어 무슨 일이 일어나는지 이해합니다.
- 수정 사항이 명확하면 작성합니다.
- 그렇지 않으면, Slack을 열어 이 파일을 마지막으로 수정한 사람을 찾습니다.
- 컨텍스트와 함께 PR을 엽니다.
- 병합.
최상의 경우: 오류당 30분. 포트폴리오 운영자의 현실적인 경우: 오류당 2시간, 왜냐하면 "코드베이스를 연다"는 것은 몇 주 동안 보지 않았던 제품의 컨텍스트를 로드하는 것을 포함하기 때문입니다.
매일 수십 개의 오류가 발생하는 15개 제품의 경우, 이는 풀타임 역할입니다. 또는 매주 증가하는 백로그가 됩니다.
AI 팀원이 대신하는 일.
- Sentry 경고 발생.
- AI 팀원은 알림, 스택 트레이스, 주변 코드, git blame, 최근 커밋, 그리고 Slack 컨텍스트를 읽습니다.
- 판단합니다: 실제 버그인가, 아니면 노이즈인가? (불안정한 테스트, 서드파티 API 일시적 오류, 알려진 중복을 필터링합니다.)
- 실제 버그인 경우: 수정 사항을 초안하고, 올바른 브랜치에 PR을 열고, PR 설명에 컨텍스트를 추가하고, 검토자를 태그합니다.
- 엔지니어가 검토(보통 5~20줄), 승인 또는 편집합니다.
- 병합.
시간 절약: 간단한 수정은 90%, 복잡한 수정은 60%.
포트폴리오 규모에서는 이것이 "전담 버그 분류 팀이 있다"와 "수정 사항이 들어오는 대로 배포한다"의 차이입니다. 더 넓은 패턴은 자율 운영 을 참조하십시오.
PR 초안을 작성하는 AI에서 찾아야 할 것.
- 1. 오류 메시지뿐만 아니라 실제 코드를 읽습니다. 오류 메시지만 보는 제품은 환각적인 수정 사항을 생성합니다.
- 2. git 기록을 읽습니다. 이 파일을 마지막으로 수정한 사람은 누구인가? git 인식이 없는 제품은 이미 수정된 버그를 다시 도입합니다.
- 3. 팀의 PR 패턴을 사용합니다. 설명적인 커밋 메시지, 필요한 경우 테스트.
- 4. 노이즈를 필터링합니다. 모든 알림이 실제 버그는 아닙니다.
- 5. 리포지토리 인식이 아닌 포트폴리오 인식. 단일 제품의 경우, 어떤 코딩 AI(Cursor, Claude Code, Codex)든 작동합니다. 5개 이상의 제품 포트폴리오의 경우, AI는 어떤 제품, 어떤 리포지토리, 어떤 팀인지 이해해야 합니다.
- 6. 오탐 PR을 우아하게 처리합니다. 잘못된 PR을 닫는 것은 한 번의 클릭으로 가능해야 합니다.
2026년에 이 기능을 제공하는 제품.
Qualia
포트폴리오 범위 AI 팀원. 모든 제품에서 Sentry를 읽고 올바른 리포지토리에 PR을 작성합니다. 3~20개의 제품을 운영하는 2~10명 규모의 팀을 위해 구축되었습니다.
Viktor
AI employee 역할 중 "엔지니어"의 일부입니다. 팀당 한 명의 명명된 AI engineer를 원하는 팀에 가장 적합합니다. 포트폴리오 범위는 아닙니다. 참조: Qualia vs Viktor.
Cursor / Claude 코드 및 맞춤형 자동화
DIY 설정. 엔지니어링 시간이 있다면 작동합니다.
Sentry AI 자동 수정
Sentry 자체 베타. Sentry로 제한되며 해당 제품 로드맵에 종속됩니다.
GitHub Copilot Workspace
수정 제안에 유용하지만, 사람이 시작해야 합니다. 자율적이지 않습니다.
Devin / Cognition
범용 자율 코딩 에이전트. 대부분의 PR 초안 작성 워크플로우에는 과도합니다.
확정하기 전에 평가하는 방법.
- 1단계. 지난 30일간 발생한 실제 Sentry 오류 10개를 선택하세요. 간단한 오류와 복잡한 오류를 섞으세요.
- 2단계. 각 오류를 AI 동료에게 제공하세요. PR 초안을 작성하도록 요청하세요.
- 3단계. 각 PR을 평가하세요: 정확성, 완전성, 관례, 맥락.
- 4단계. 제품별로 비교하세요. 10개 중 8개를 올바르게 처리하고 나머지 2개를 능숙하게 다루는 제품이, 간단한 오류는 10개 중 10개를 맞추지만 복잡한 오류에서 환각을 일으키는 제품보다 낫습니다.
흔한 실수.
- 검토 게이트 없이 배포하는 것. AI가 작성한 PR이 자동으로 병합되도록 절대 허용하지 마세요.
- AI를 git 기록에 연결하지 않는 것. 오류만 보는 AI는 이미 수정된 버그를 다시 도입합니다.
- 너무 공격적으로 필터링하는 것. "진정한 버그만"은 예외 사례를 놓칩니다. "모든 것"은 노이즈입니다. 2주 동안 반복하세요.
- 리포지토리 범위 제품에서 포트폴리오 범위를 가정합니다. 단일 리포지토리 도구(Cursor, Copilot)는 "어떤 제품, 어떤 리포지토리"를 기본적으로 처리하지 않습니다.
자주 묻는 질문.
AI가 실제로 좋은 수정 사항을 작성하나요?
간단한 수정 사항(null 검사, 유형 강제 변환, 누락된 가져오기)의 경우 그렇습니다. 복잡한 수정 사항의 경우 AI는 자신감 있는 잘못된 수정 사항을 생성하기보다는 불확실성을 표시해야 합니다.
Cursor 또는 Claude Code와 함께 사용할 수 있나요?
네. 대부분의 포트폴리오 운영자는 대화형 코딩을 위해 Cursor를 사용하고 자율적인 분류를 위해 AI 동료를 사용합니다.
AI가 너무 많은 PR을 열면 어떻게 되나요?
임계값 이상에서만 트리거되도록 필터를 구성하세요. 매주 반복하세요.
이것이 엔지니어를 대체하나요?
아니요. 분류에 소요되는 엔지니어 시간을 대체합니다.
비용은 얼마인가요?
포트폴리오 가격 책정 제품에는 이것이 하나의 기능으로 포함됩니다. 전용 버그 수정 제품은 수정당 또는 리포지토리당 가격이 책정됩니다.
제품이 하나뿐이면 어떻게 되나요?
단일 리포지토리 도구로 충분할 수 있습니다. 포트폴리오 범위는 3개 이상의 제품에서 중요합니다.
언제쯤 유용해지나요?
첫 PR은 며칠, 필터 보정은 몇 주, 피드백 루프를 통해 분류에서 중간 수준 엔지니어보다 지속적으로 나아지는 데는 몇 달이 걸립니다.