Featured Post

AI 바이브 코딩할 때 Sentry를 안 붙이면, 진짜 브레이크 없는 자전거 타는 기분이더라

작성자:
Sentry - 에러 추적 관련 이미지

요즘 개발판을 보고 있으면, 솔직히 가끔 웃음이 나와. Cursor나 Copilot 같은 AI 코딩 도구로 주니어 개발자들이 하루에 기능 하나씩 뚝딱 만들어내는 걸 보면 말이야. 내가 20년 전쯤 밤새 로그 찍어가며 삽질하던 시절이 떠오르기도 하고, 한편으론 “와, 세상 참 많이 바뀌었네” 싶기도 해.

그런데 이상하게도, 코드가 빨리 만들어질수록 더 중요해지는 게 있더라. 바로 에러 추적이야. AI가 코드를 빠르게 만들어주는 건 정말 고마운 일인데, 문제는 그 코드가 실제 서비스에서 어디서 어떻게 터지는지 내가 다 따라가기 어렵다는 거지. 그래서 요즘 나는 AI 바이브 코딩을 할 때 Sentry를 거의 안전벨트처럼 붙여놓고 있어. 오늘은 설치법만 툭 던지는 글이 아니라, 내가 실제 현업에서 AI 코딩 도구랑 Sentry를 같이 쓰면서 느꼈던 것들, 특히 토큰 아끼면서 에러를 빨리 찾는 방법을 좀 편하게 풀어보려고 해.

AI가 코드를 빨리 짤수록 Sentry 같은 안전망이 더 필요하더라

솔직히 AI가 만들어주는 코드, 생각보다 꽤 잘 짜. 예전처럼 “이게 코드야?” 싶은 수준은 이미 한참 지났잖아. 그런데 그렇다고 해서 그 코드를 전부 믿고 그냥 프로덕션에 던지는 건 좀 위험해. 뭐랄까, 여행 갈 때 내비게이션이 길을 잘 알려준다고 브레이크 없는 차를 타고 가는 느낌이랄까.

최근에 내가 겪었던 일이 하나 있어. AI가 만들어준 API 응답 파싱 로직이 있었는데, 대부분의 케이스에서는 멀쩡하게 잘 돌아갔어. 테스트 환경에서도 문제없었고. 그런데 특정 국가 코드가 들어오는 유저에게만 널 포인터 비슷한 에러가 터지더라고. 개발 중에는 전혀 못 잡았어. 그런데 배포하고 나서 Sentry가 10분 만에 알림을 보내줬어. 그때 진짜 고마웠다니까.

문제는 이런 거야. AI가 코드를 잘못 짰다, 이런 단순한 이야기가 아니야. AI가 만들어준 코드가 실제 사용자 환경에서 어떻게 움직이는지, 그 피드백을 빨리 받아야 한다는 거지. 특히 내가 느끼기에 AI가 생성한 코드에서 자주 터지는 부분은 대충 이런 쪽이었어.

    • 비동기 처리가 살짝 어긋나서 아직 값이 없는데 접근하는 경우
    • API 응답 구조를 너무 낙관적으로 가정하는 경우
    • 타입은 맞는 것처럼 보이는데 런타임에서는 다른 값이 들어오는 경우
    • 예외 처리는 되어 있지만 실제 사용자 흐름과 맞지 않는 경우
    • 렌더링 타이밍 문제로 특정 컴포넌트에서만 터지는 경우

예전에는 내가 직접 코드를 썼으니까, 에러가 나도 어느 정도 감이 있었어. “아, 내가 거기 예외 처리 안 했네” 하고 말이야. 그런데 AI가 작성한 코드는 가끔 내가 흐름을 100% 이해하기 전에 다음 작업으로 넘어가게 되거든. 이게 생산성은 좋은데, 나중에 터지면 좀 무섭다. 그래서 Sentry 같은 에러 추적 도구가 있으면 마음이 훨씬 편해져.

상황 Sentry 없이 볼 때 Sentry 붙여놓고 볼 때
프로덕션 에러 발생 사용자 제보 기다림 실시간 알림으로 바로 확인
AI가 만든 코드에서 문제 발생 어느 파일인지 추측부터 시작 파일명, 라인, 스택 트레이스로 바로 접근
특정 사용자만 에러 발생 재현이 안 돼서 답답함 환경, 브라우저, 액션 흐름까지 확인 가능
LLM에게 질문할 때 로그를 통째로 붙여넣음 핵심 정보만 뽑아서 토큰 절약

이 차이가 꽤 커. 특히 혼자 개발하거나 작은 팀에서 빠르게 기능을 밀어붙이는 상황이면 더 그렇고. Sentry가 있으면 “어디서 터졌지?”에서 시간을 덜 쓰고, “어떻게 고칠까?”로 바로 넘어갈 수 있어.

Sentry 로그를 LLM에 통째로 넣으면 토큰이 줄줄 샌다

AI 코딩 도구한테 에러를 물어볼 때, 처음엔 나도 그냥 Sentry 이벤트 화면을 복사해서 통째로 붙여넣었어. 스택 트레이스부터 브라우저 정보, 사용자 환경, 요청 헤더, Breadcrumbs까지 싹 다 넣고 “이거 왜 이래?” 하고 물어봤지.

근데 해보니까 이게 꽤 별로더라. 답변이 길어지긴 하는데 핵심을 잘 못 짚는 경우가 있었어. 그리고 무엇보다 토큰 낭비가 심해. 요즘 LLM 비용도 비용이지만, 긴 로그를 넣으면 모델이 중요한 에러 메시지나 실제 발생 라인을 놓치는 경우가 생기더라고. 사람도 긴 회의록 던져주고 “그래서 문제 뭐야?” 하면 피곤하잖아. AI도 비슷한 느낌이야.

내가 지금은 Sentry에서 딱 필요한 정보만 잘라서 넣어. 특히 아래 네 가지를 중심으로 정리해.

    • 에러 타입: TypeError, ReferenceError, AxiosError 같은 것
    • 에러 메시지: 실제로 터진 핵심 문장
    • 발생 위치: 파일명과 라인 번호
    • 직전 사용자 액션: Breadcrumbs에서 확인한 흐름

실제로 내가 자주 쓰는 프롬프트는 이렇게 생겼어.

에러 타입: TypeError
에러 메시지: Cannot read properties of undefined (reading 'price')
발생 위치: ProductCard.tsx, line 42
직전 사용자 액션: checkoutButton.click -> cartSummary.fetch -> render ProductCard

이 흐름에서 price가 undefined가 되는 원인을 짚어주고,
방어 코드와 구조 개선 방향을 같이 제안해줘.

이 정도만 넣어도 AI가 꽤 잘 잡아. “fetch 응답이 오기 전에 price에 접근하고 있을 가능성이 큽니다”라든지, “cartSummary가 null일 때 기본값을 넣어야 합니다” 같은 답을 바로 줘. 괜히 스택 트레이스 전체를 넣었을 때보다 답변이 더 또렷해지는 느낌이 있어.

여기서 내가 나름 정리한 기준이 하나 있어. AI에게 로그를 주는 게 아니라, 사건 현장을 설명해준다는 느낌으로 프롬프트를 만드는 거야. 로그 전체는 사건 현장 CCTV 원본이고, 내가 LLM에 주는 건 “용의자가 어디서 들어와서 어디서 넘어졌는지” 정도의 편집본인 셈이지.

내가 자주 쓰는 Sentry 정보 압축 방식

Sentry 정보 LLM에 넣을지 여부 내 기준
에러 메시지 넣음 가장 중요. 절대 빼면 안 됨
발생 파일과 라인 넣음 Source Map이 있으면 정확도가 확 올라감
Breadcrumbs 핵심만 넣음 사용자 액션 흐름 위주로 3~5개만
전체 스택 트레이스 대부분 제외 필요한 프레임만 잘라서 사용
브라우저, OS 정보 상황 따라 넣음 특정 환경에서만 터질 때만 포함
요청 헤더 전체 거의 제외 보안상으로도 조심해야 함

그리고 하나 더. Sentry의 Issue ID나 Group ID를 내부 메모에 남겨두면 좋아. LLM 자체가 그 ID를 magically 이해하는 건 아니지만, 내가 에러를 추적할 때 맥락을 잃지 않게 해줘. “이 이슈는 지난주 릴리스에서도 있었던 그거다”라는 식으로 연결되거든. 개발하다 보면 이런 작은 끈이 은근히 큰 도움이 돼.

Source Map 안 올리면 AI도 난독화된 코드 앞에서 멍해진다

Sentry 붙일 때 가장 많이 놓치는 게 Source Map이야. 사실 나도 예전에 “일단 DSN 연결됐고 에러 올라오네? 됐다” 하고 넘겼던 적이 있어. 그런데 막상 프로덕션에서 에러가 터졌는데 스택 트레이스가 이렇게 나오면 좀 막막해져.

main.abc123.chunk.js:1:2345
vendor.991ef.js:1:88210
app.min.js:1:13022

이걸 AI에게 보여주면 답이 뻔해. “난독화된 코드라 정확한 분석이 어렵습니다”라는 식으로 말하지. 맞는 말이긴 한데, 듣고 있으면 좀 허탈해. 그래서 나는 이제 CI/CD 파이프라인에 sentry-cli를 넣어서 배포할 때마다 Source Map을 자동으로 업로드하게 해놨어.

이걸 해두면 Sentry 대시보드에서 실제 원본 파일 기준으로 에러 위치가 보여. 예를 들면 이런 식이야.

src/components/ProductCard.tsx:42
src/hooks/useCartSummary.ts:18
src/pages/CheckoutPage.tsx:77

이 차이가 진짜 커. AI에게도 “ProductCard.tsx 42번째 줄에서 price 접근하다가 터졌어. 아래 코드 보고 수정해줘”라고 말할 수 있거든. 그러면 답변 품질이 확 올라가. AI에게 좋은 질문을 하려면, 내가 먼저 좋은 단서를 줘야 하더라. 이건 개발뿐 아니라 사람 사이 대화도 비슷한 것 같아.

내가 배포 파이프라인에 꼭 넣는 Sentry 설정

    • 배포 시점마다 Release를 생성한다
    • Git 커밋 해시를 Release 버전으로 사용한다
    • 빌드 후 Source Map을 Sentry에 업로드한다
    • 업로드 후 외부에 Source Map이 노출되지 않도록 정리한다
    • 환경값을 development, staging, production으로 분리한다
    • 사용자 식별 정보는 필요한 수준으로만 마스킹해서 보낸다

특히 Release 기능은 꼭 써봤으면 좋겠어. AI 바이브 코딩을 하다 보면 하루에도 코드가 여러 번 바뀌잖아. 기능 하나 만들고, 리팩터링하고, 테스트 코드 보완하고, 다시 배포하고. 이때 Release 기준으로 에러를 보면 “이번 배포에서 새로 생긴 문제인지”가 바로 보여.

예를 들어 아침에 AI 도움을 받아서 UserProfile 컴포넌트를 새로 만들었다고 해보자. 그리고 점심쯤 배포했는데, 그 릴리스에서만 undefined is not a function 에러가 갑자기 늘어났다? 그러면 거의 그쪽을 보면 돼. 전체 코드베이스를 뒤질 필요가 없어지는 거야. 이런 게 쌓이면 하루 컨디션이 달라져. 진짜로.

AI에게 Sentry 데이터를 줄 때 내가 지키는 작은 규칙들

AI에게 에러 분석을 맡길 때, 나는 요즘 몇 가지 규칙을 거의 습관처럼 지켜. 별거 아닌 것 같아도, 이게 답변 품질을 꽤 갈라놓더라.

로그보다 상황을 먼저 말해준다

그냥 “이 에러 고쳐줘”라고 하면 AI가 대충 방어 코드만 제안하는 경우가 많아. 그런데 “결제 페이지에서 카드 선택 후 쿠폰 적용 버튼을 누르면 발생한다”처럼 상황을 붙여주면 훨씬 현실적인 답을 해줘.

상황:
결제 페이지에서 사용자가 쿠폰을 적용한 직후 cartSummary를 다시 불러온다.
그 직후 ProductCard가 렌더링되면서 price가 undefined로 터진다.

에러:
Cannot read properties of undefined (reading 'price')

내가 원하는 답:
1. 가장 가능성 높은 원인
2. 임시 방어 코드
3. 근본적으로 구조를 고치는 방법

이렇게 물어보면 AI가 단순히 optional chaining 하나 붙이고 끝내지 않고, 상태 초기화나 로딩 처리, API 응답 스키마까지 같이 봐주는 경우가 많았어.

전체 코드를 넣지 말고 문제 주변만 잘라준다

토큰을 아끼려면 전체 파일을 다 넣는 습관을 버리는 게 좋아. 나도 예전엔 불안해서 파일 전체를 붙여넣었는데, 이제는 문제가 터진 함수와 관련 타입 정도만 넣어. 대략 에러 라인 기준 위아래 20줄 정도면 충분한 경우가 많더라.

interface Product {
  id: string;
  name: string;
  price?: number;
}

function ProductCard({ product }: { product?: Product }) {
  return (
    <div>
      <span>{product.price.toLocaleString()}원</span>
    </div>
  );
}

이 정도만 줘도 AI는 바로 알아봐. “product가 undefined일 수 있고, price도 optional인데 바로 접근하고 있습니다”라고 말이야. 괜히 프로젝트 전체 맥락을 다 설명하려다 보면 나도 지치고, AI도 산으로 가.

원하는 답변 형식을 미리 정해준다

이건 정말 소소한데 효과가 좋아. “고쳐줘”라고 하지 말고, 내가 받고 싶은 형태를 말해주는 거야.

아래 형식으로 답해줘.

원인:
수정 코드:
추가로 확인할 Sentry 항목:
재발 방지 방법:

이렇게 해두면 답변이 훨씬 써먹기 좋아져. 특히 바쁠 때는 긴 설명보다 바로 적용할 수 있는 형태가 고맙잖아. 나이 들수록 그런 실용적인 게 좋아지더라. 괜히 멋진 말보다, 지금 내 문제를 덜어주는 답이 최고야.

성능 모니터링까지 붙이면 AI 코드의 느린 부분도 잡힌다

Sentry를 에러 추적용으로만 쓰는 분들도 많은데, Performance Monitoring도 같이 보면 꽤 쓸 만해. AI가 만들어준 코드가 기능적으로는 맞는데, 성능은 좀 애매한 경우가 있거든. 특히 불필요한 API 호출이 반복되거나, 렌더링이 과하게 일어나는 경우가 그래.

한번은 AI가 만들어준 대시보드 화면에서 특정 API가 사용자의 필터 변경마다 계속 호출되는 문제가 있었어. 화면은 돌아가니까 처음엔 몰랐지. 그런데 Sentry 성능 트레이스에서 보니까 같은 endpoint가 짧은 시간에 여러 번 찍히더라고. 응답 시간도 5초 가까이 튀고 있었고.

그 데이터를 AI에게 이렇게 넘겼어.

문제 상황:
대시보드 필터를 변경할 때마다 /api/report-summary가 3~5회 반복 호출됨.

Sentry Performance:
transaction: DashboardPage load
slow span: GET /api/report-summary
duration: 5.2s
반복 호출 위치로 의심되는 파일: useReportFilters.ts

원하는 것:
불필요한 중복 호출을 줄이는 방법과 React Query 기준 개선 코드를 제안해줘.

이렇게 물어보니까 AI가 debounce 적용, queryKey 정리, enabled 조건 추가 같은 제안을 꽤 현실적으로 해줬어. 물론 그대로 다 믿고 넣으면 안 되고, 내가 한 번 더 보고 다듬어야 해. 그래도 출발점이 생기니까 속도가 확 빨라져.

내 기준으로 Sentry는 AI 바이브 코딩의 안전장치다

개발자라면 에러 추적 도구가 중요하다는 건 다 알아. 그런데 AI 바이브 코딩을 시작하면 그 중요도가 한 단계 더 올라가는 것 같아. 왜냐하면 코드 작성 속도는 빨라졌는데, 내가 그 모든 코드를 머릿속에 다 넣고 가는 건 점점 어려워지거든.

그래서 나는 요즘 이렇게 생각해. AI 코딩 도구는 엔진이고, Sentry는 브레이크와 계기판이다. 엔진만 좋다고 멀리 갈 수 있는 건 아니잖아. 속도를 내는 만큼 멈출 수 있어야 하고, 어디가 과열되는지도 봐야 해.

이 글은 특히 이런 분들이 읽으면 도움이 될 것 같아.

    • Cursor, Copilot 같은 도구로 AI 바이브 코딩을 시작한 개발자
    • 혼자서 빠르게 사이드 프로젝트나 서비스를 만들고 있는 분
    • AI가 만든 코드의 품질을 어떻게 관리해야 할지 고민하는 팀 리더
    • 프로덕션 에러를 사용자 제보로만 알게 되는 상황이 불안한 분
    • LLM에 로그를 넣을 때마다 토큰이 아깝다고 느꼈던 분

초반 셋업에 하루 정도는 들어갈 수 있어. Source Map도 붙여야 하고, Release도 잡아야 하고, 환경값도 정리해야 하니까. 그런데 솔직히 그 하루는 아깝지 않아. 한번 해두면 그다음부터는 정말 편해져. 에러가 터지면 Sentry가 알려주고, 나는 핵심 정보만 추려서 AI에게 던지고, AI가 원인 후보와 수정 방향을 빠르게 잡아준다. 이 흐름이 익숙해지면 예전 방식으로 돌아가기 힘들어.

20년 개발하면서 느낀 건데, 좋은 도구는 개발자를 게으르게 만드는 게 아니라 마음을 덜 불안하게 만들어줘. Sentry가 내게는 그런 도구였어. AI로 속도를 내고 싶은데 프로덕션이 무섭다면, Sentry부터 붙여봐. 진짜로. 브레이크 있는 자전거가 훨씬 멀리 가거든.

댓글

댓글 쓰기