How to Use a Coding Agent to Fix Production Bugs

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

프로덕션 버그를 고치는 코딩 에이전트에는 Sentry·Datadog의 운영 정보, Firecrawl의 외부 개발 자료, 실제 앱 실행과 수정 전후 검증이 필요하며, 최종 판단은 사람이 증거와 코드를 검토해 내려야 한다.

📌 핵심 요약

• 저장소만으로는 실제 서버에서 발생한 오류의 조건, 외부 라이브러리의 문제, 수정의 성공 여부를 알기 어렵다. 원문은 에이전트를 바꾸기보다 기존 에이전트에 이 세 가지 정보를 제공해야 한다고 주장한다.
• Sentry는 오류 위치·발생 빈도·영향받은 사용자를, Datadog는 발생 시점·확산 범위·동시 변화를 파악하는 데 쓰인다. 서버 상황을 먼저 확인하고, 외부 문제를 조사한 다음, 수정할 코드를 찾는 순서를 권한다.
• Sentry의 조사 예시는 최근 24시간의 미해결 이슈 상위 5개를 추린 뒤, 가장 심각한 이슈의 최근 발생 사례·스택 추적·주변 로그·Seer 분석을 확인하고 코드 수정으로 이어진다. Datadog는 사용자의 기존 권한을 따르며, 필요한 도구 그룹만 활성화하도록 권한다.
• Devin의 검증 방식은 준비, 핵심 종단 간 흐름 선정, 화면 녹화를 포함한 실행으로 구성된다. 화면 변경은 데스크톱 1280픽셀과 모바일 375픽셀에서 수정 전후 스크린샷 4장을 비교하고 브라우저 콘솔 출력도 함께 검토하지만, 이 검증이 코드 리뷰를 대체하지는 않는다.
• Firecrawl은 7,000만 개 이상의 GitHub 이슈·풀 리퀘스트·문서를 검색해 이미 알려진 외부 문제를 찾는 수단으로 소개된다. 상위 10개 결과 안에 정답이 포함되는 비율이 63%로 웹 검색의 45%보다 높다는 수치는 Firecrawl의 주장이다. 제공된 본문은 외부 버그 조사 부분의 도입에서 끊겨 이후 설명은 확인할 수 없다.

🧩 주요 포인트

1. 정보원별 역할 분리 → Sentry·Datadog로 실제 장애 조건을 좁히고 Firecrawl로 외부 원인을 확인하면, 저장소만 보고 그럴듯한 수정을 제안하는 오류를 줄일 수 있다.
2. 조사 범위와 접근 권한 제한 → 최근 24시간의 이슈 상위 5개, 단일 Sentry 프로젝트, 필요한 Datadog 도구 그룹으로 범위를 좁히면 조사 집중도를 높이고 불필요한 접근을 줄일 수 있다.
3. 실행 증거와 사람의 검토 결합 → 핵심 종단 간 흐름과 1280픽셀·375픽셀의 수정 전후 화면은 실제 동작을 확인하게 하지만, 구현 품질과 장기적 안정성은 별도의 코드 리뷰가 필요하다.

🧠 상세 정리

1. 저장소만으로 프로덕션 버그를 설명하기 어려운 이유

원문은 코딩 에이전트가 전체 저장소, 실패한 테스트, 커밋 이력, 전달받은 스택 추적을 갖고 있어도 그럴듯하지만 틀린 수정을 제안할 수 있다는 문제에서 출발한다. 이를 모델의 능력 부족으로만 설명하지 않고, 서버에서 실제로 일어난 일을 묻는 질문에 로컬 파일만 제공한 정보의 불일치로 설명한다. 특정 사용자와 특정 릴리스에서 발생한 오류가 11일 전에 잘못된 업데이트를 내놓은 라이브러리와 관련될 수 있다는 예시는, 중요한 원인이 저장소 밖에 있음을 보여준다. 따라서 좋은 프로덕션 디버깅을 위해 반드시 다른 에이전트를 선택해야 하는 것은 아니며, 이미 사용하는 에이전트에 빠진 정보를 연결하는 것이 핵심이라는 주장이다. 글은 에이전트 제품 선택 자체보다 오류 추적, 운영 관측, 외부 개발 자료 검색, 실행 검증을 어떻게 붙일지에 초점을 맞춘다.

2. 에이전틱 디버깅과 세 가지 정보 공백

에이전틱 디버깅은 코딩 에이전트가 엔지니어처럼 실제 오류를 조사하고, 가능한 원인을 판단해 코드를 바꾼 뒤, 앱을 실행하여 수정이 작동하는지 확인하는 과정으로 정의된다. 채팅창에 스택 추적을 붙이는 방식과의 차이는 에이전트가 스스로 증거를 가져오고 자신의 수정을 시험하며, 사람이 그 결과를 검토한다는 점이다. 첫 번째 정보 공백은 실행 중이던 릴리스, 영향을 받은 사용자, 발생 빈도, 당시 시스템 상태를 포함한 서버의 실제 상황이다. 두 번째는 정상적인 자체 코드가 외부 라이브러리 변경 때문에 깨졌는지와 같이 다른 저장소의 GitHub 논의에서 드러나는 원인이다. 세 번째는 수정 후 실제 동작으로, 앱을 실행하지 않으면 에이전트는 작동하는 수정과 코드 차이만 그럴듯한 수정을 구분할 수 없다. 원문은 이 세 공백이 서로 다른 잘못된 답을 낳기 때문에 각각에 맞는 정보원과 검증 방법이 필요하다고 설명한다.

3. 정보원의 역할과 조사 순서

Sentry는 무엇이 어느 코드 줄에서 깨졌고 얼마나 많은 사용자가 영향을 받았는지를 설명하는 정보원이며, Datadog는 언제 시작됐고 얼마나 확산됐으며 무엇이 함께 변했는지를 파악하는 데 쓰인다. 저장소는 수정할 코드가 있는 곳이고, Firecrawl Developer index는 다른 개발자가 이미 같은 버그를 겪었는지 확인하는 역할을 맡는다. 연결 경로로는 Sentry의 mcp.sentry.dev/mcp, Datadog의 Claude Code 플러그인 또는 HTTP 엔드포인트, Firecrawl의 /v2/search/developer가 제시된다. Sentry와 Datadog가 사용하는 MCP는 Model Context Protocol의 약자로, 에이전트가 파일을 읽듯 연결된 도구를 호출할 수 있게 하는 표준으로 설명된다. 원문이 권하는 순서는 서버에서 실제로 벌어진 일을 먼저 확인하고, 외부 세계의 알려진 문제를 조사한 다음, 원인이 좁혀졌을 때 자체 코드를 살펴보는 것이다. 2026년 9월 6일자 Firecrawl 출처 표기는 이 정보원 구분과 함께 제시되며, 전체 과정은 사람이 증거를 확인해야 끝난다고 강조한다.

4. Sentry 연결과 조사 범위 축소

Sentry는 MCP 서버를 직접 호스팅하므로 별도 설치 없이 Claude Code에 연결할 수 있으며, 처음 사용할 때 브라우저에서 로그인하는 흐름으로 소개된다. 하나의 서비스를 디버깅한다면 계정 전체보다 단일 프로젝트를 대상으로 삼아 잡음을 줄이고 에이전트가 관련 없는 데이터로 조사 범위를 넓히지 않게 하라고 권한다. 별도 플러그인 방식도 있으며, getsentry/sentry-mcp를 플러그인 마켓플레이스에 추가한 뒤 sentry-mcp@sentry-mcp를 설치하는 명령이 본문에 나온다. 이 플러그인은 전용 Sentry 보조 에이전트에 관련 질문을 맡겨 주 대화가 핵심 조사에 집중하도록 돕는다고 설명한다. 또한 Sentry의 자동 근본 원인 분석 기능인 Seer가 기본 활성화되어 오류와 주변 코드를 읽고 원인을 제안하며, 필요하면 --disable-skills=seer로 끌 수 있다. Seer의 결과는 원인에 대한 제안으로 제시되므로, 이후 실제 코드와 실행 결과를 확인하는 과정까지 이어져야 한다.

5. Datadog의 도구 범위와 권한 제약

Datadog MCP 서버는 시간에 따른 로그, 메트릭, 추적 정보를 제공하며, 플러그인 설치 후 /ddsetup으로 지역을 선택하고 로그인하는 흐름이 소개된다. 제품 영역별 도구 그룹은 /ddtoolsets로 켜고 끌 수 있고, 연결 URL에 ?toolsets=apm,llmobs처럼 지정할 수도 있으므로 사용하지 않는 그룹을 비활성화하라고 권한다. 모든 도구를 열어 두면 단순한 널 포인터 오류를 고치는 중에도 에이전트가 여러 대시보드를 탐색하며 제한된 작업 기억을 낭비할 수 있다는 것이 그 근거다. 권한 측면에서는 인증된 사용자 자신의 자격 증명을 Datadog API로 전달하므로 에이전트가 사용자와 같은 범위의 정보를 보며, 모니터 편집 같은 변경에는 별도로 부여해야 하는 특정 권한이 필요하다고 설명한다. 2026년 9월 기준 제한은 10초마다 50개 요청과 월 100,000회 도구 호출이며, Datadog의 정부 클라우드 사이트에서는 작동하지 않는다고 명시한다. 이 부분은 연결 자체뿐 아니라 조사에 필요한 기능만 노출하고 기존 사용자 권한의 경계를 유지하는 것이 중요하다는 논지로 이어진다.

6. 장애 조사를 단계별 질문으로 좁히기

원문은 프로덕션에서 무언가 깨졌으니 전부 찾아보라는 큰 질문이 에이전트에게 오류의 벽을 보여 줄 뿐, 무엇이 중요한지 구별할 기준을 주지 못한다고 지적한다. Sentry의 cookbook 예시는 먼저 최근 24시간의 미해결 이슈 상위 5개를 요청하고, 각 이슈에서 무엇이 실패하는지와 발생 빈도 및 영향받은 사용자 수를 확인하도록 나눈다. 다음에는 가장 심각한 후보 하나를 골라 최근 발생 사례의 전체 스택 추적, 당시 주변 로그, Seer의 근본 원인 분석을 요청한다. 이처럼 실제 사건을 좁힌 뒤에야 대응하는 코드를 찾아 수정하도록 하며, 변경 전에 코드 차이를 보여 달라는 요청으로 잘못된 접근을 일찍 검토할 기회를 둔다. 배포 직후 나타난 오류라면 최초 발생 시점과 당시 실행 중이던 릴리스를 추가로 확인해야 한다. 배포 4분 뒤 시작한 오류와 한 달 동안 조용히 반복된 오류는 조사해야 할 맥락이 다르다는 예시가 시간 정보의 중요성을 뒷받침한다.

7. Devin 방식으로 수정의 실행 증거 만들기

원문은 앱을 실행하지 않는 에이전트가 합리적으로 보이는 편집과 실제 해결을 구별할 수 없다는 점을 들어, 자신의 출력을 실행한 뒤 완료를 선언하는 검증 과정을 강조한다. Devin의 방식은 풀 리퀘스트와 코드를 읽고 .agents/skills/의 프로젝트별 지침을 확인하며 필요한 서비스에 로그인하는 준비 단계에서 시작한다. 이어 기능이 작동함을 입증하는 가장 중요한 종단 간 흐름 하나를 골라 실행 전에 계획을 보여 주고, 화면 녹화를 시작해 앱을 조작하면서 중요한 순간을 표시한다. 결과물은 표시가 붙은 스크린샷을 포함한 짧은 보고서와, 장별 구분 및 각 검사의 성공·실패 목록을 담은 전체 영상이다. 좋은 검증 지시는 장바구니에 상품을 담고 결제로 이동해 양식을 작성한 뒤 주문 확인의 총액을 검증하는 식으로 경로와 기대 결과를 명시하며, 모든 것을 시험하라는 지시는 피한다. 반복 절차를 파일로 저장하는 예시에서는 git diff로 변경된 페이지를 찾은 뒤 해당 페이지의 콘솔 오류, 레이아웃 문제, 깨진 링크를 확인하도록 해 검증 범위를 실제 변경에 맞춘다.

8. 화면 비교의 효용, 한계와 외부 자료 검색

CSS 수정은 데스크톱 화면을 개선하면서 모바일 화면을 깨뜨릴 수 있고 기존 테스트가 모두 통과할 수도 있으므로, 원문은 영향을 받는 페이지를 수정 전에 데스크톱 1280픽셀과 모바일 375픽셀 너비로 촬영하라고 권한다. 수정 후 같은 페이지와 같은 두 너비에서 다시 촬영해 스크린샷 4장을 브라우저 콘솔 출력과 함께 풀 리퀘스트에 첨부하면, 검토자가 수정됐다는 주장 대신 화면을 직접 비교할 수 있다. 다만 이 증거는 페이지가 로드되고 흐름이 실행됐음을 보여 줄 뿐, 구현이 잘 설계됐거나 다음 달에도 안정적일 것임을 입증하지는 않으므로 코드 리뷰를 대체하지 않는다. 외부 원인을 찾는 수단으로는 Firecrawl이 7,000만 개 이상의 GitHub 이슈, 풀 리퀘스트, 문서를 검색할 수 있다고 소개된다. 상위 10개 결과 안에 정답이 들어가는 비율이 63%이고 웹 검색은 45%라는 비교도 제시되지만, 이는 Firecrawl을 출처로 한 주장으로 보아야 한다. 제공된 본문은 원래 자기 코드의 문제가 아니었던 버그를 추적하는 비용을 언급하는 도입에서 끊기므로, 이후 외부 버그 조사와 라이브러리 선택에 관한 상세 논증은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 원문이 보는 디버깅의 병목은 모델 교체보다 증거의 부족에 있다. 운영 상황, 외부 문제, 실행 결과를 연결해야 에이전트가 조사할 대상과 완료 조건을 구별할 수 있다.
• 조사 범위를 좁히는 작업은 정확도와 접근 통제에 함께 기여한다. 단일 프로젝트와 필요한 도구 그룹을 선택하면 관련 없는 정보가 판단을 흐리는 문제를 줄일 수 있다.
• 실행 검증과 코드 리뷰는 확인하는 대상이 다르다. 스크린샷과 영상은 실제 동작의 증거를 제공하지만, 구현 품질과 장기적 안정성에 관한 판단은 남는다.

✅ 액션 아이템

• Sentry의 최근 24시간 미해결 이슈 상위 5개와 Datadog의 발생 시점·동시 변화를 확인해 조사할 장애를 좁힌다.
• 코드 수정 전에 Firecrawl로 이미 알려진 외부 문제를 확인하고, 필요한 Datadog 도구 그룹만 활성화해 조사 범위를 제한한다.
• 핵심 종단 간 흐름을 실행하고 1280픽셀·375픽셀의 수정 전후 스크린샷 4장과 브라우저 콘솔 출력을 코드 리뷰에서 검토한다.

❓ 열린 질문

• Sentry의 최근 24시간 미해결 이슈 상위 5개 중 발생 빈도와 영향받은 사용자를 고려할 때 가장 먼저 조사할 이슈는 무엇인가?
• Datadog의 발생 시점·동시 변화와 Firecrawl의 외부 개발 자료는 해당 장애가 자체 코드에서 비롯됐는지 판단하는 데 어떤 근거를 제공하는가?
• 핵심 종단 간 흐름과 1280픽셀·375픽셀의 수정 전후 스크린샷으로 확인한 동작 외에, 코드 리뷰에서 판단해야 할 구현 품질과 장기적 안정성의 쟁점은 무엇인가?