본문으로 바로가기
리옵트 핸드북
리옵트 핸드북
개발자 언러닝

왜 바꿔야 하는가

전문성이 짐이 되는 순간'내가 다 짜야 한다'는 착각

설계와 구현의 전환

사전 설계에서 반복 설계로프롬프트는 설계 언어다AI 시대의 코드 리뷰

실무 습관 리셋

테스팅 전략의 전환디버깅 습관 리셋컨텍스트 관리: 새로운 핵심 역량기술 부채의 재정의

팀과 커리어

팀 워크플로우의 변화절대 언러닝하면 안 되는 것에이전틱 전환 전략

부록

검증 리포트업데이트 내역
핸드북›Developer Unlearning›디버깅 습관 리셋
한국어English

디버깅 습관 리셋

console.log·디버거의 수동 추적에서 벗어나, 증상을 구조화해 AI에게 확률 순 가설을 받고 검증하는 디버깅으로 전환하는 방법과 실전 케이스

핵심 요약

  • console.log와 디버거는 도구만 다를 뿐, "어디를 봐야 하는지"를 사람의 직감으로 정하는 똑같은 수동 추적 루프를 따른다.
  • AI 디버깅은 "어디서"가 아니라 "왜 이런 증상이 나타나는가"에서 출발하고, AI가 가능한 원인을 확률 순으로 제안한다.
  • 좋은 요청에는 증상, 재현 조건, 시도한 것, 의심 영역 네 가지 컨텍스트가 들어가야 한다.
  • 환경 의존 버그와 타이밍 버그는 사람 판단이 결정적이지만, 타입 에러나 정규식, 비동기 로직은 AI가 훨씬 잘 잡아낸다.
  • 디버거, 프로파일러, git bisect 같은 기존 도구는 원인을 직접 찾기보다 AI에게 줄 증거를 모으는 용도로 바뀐다.

버그를 만나면 개발자는 본능적으로 추적을 시작한다. 누군가는 console.log를 심고, 누군가는 브레이크포인트를 걸고 스텝 실행을 돌린다. 도구는 다르지만 접근은 같다. "어디서 값이 이상한지"를 한 지점씩 좁혀가는 것이다.

이 방식이 수십 년을 살아남은 이유는 확실하기 때문이다. 하지만 확실하다고 늘 효율적인 건 아니다. AI 시대의 디버깅은 **"어디서"**가 아니라 **"왜"**에서 시작한다.

수동 추적의 두 축: console.log와 디버거

디버깅의 수동 추적 방식은 크게 두 가지로 나뉜다.

console.log 방식

가장 원시적이지만 가장 널리 쓰이는 방식이다.

// 1차: 의심 지점에 로그 삽입
console.log("user:", user);
console.log("items:", items);

// 2차: 범위 좁히기
console.log("before filter:", items.length);
console.log("after filter:", filtered.length);

// 3차: 더 깊이
console.log("item[0]:", JSON.stringify(items[0], null, 2));

// ... 5-6회 반복 후 원인 발견
// ... 그리고 심어둔 console.log 전부 제거

디버거 방식

IDE나 DevTools의 디버거를 적극 활용하는 접근이다. console.log보다 분명히 강력하다.

1. 의심 지점에 브레이크포인트 설정
2. 실행 → 중단점에서 멈춤
3. 변수 패널에서 현재 상태 확인
4. 콜스택 추적 → 호출 경로 파악
5. 스텝 오버/스텝 인 → 한 줄씩 실행하며 상태 변화 관찰
6. 조건부 브레이크포인트로 특정 케이스만 포착
7. ... 반복하며 원인 좁히기

공통된 한계

도구는 다르지만, 두 방식 모두 같은 패턴을 따른다.

특성console.log디버거
탐색 방식로그 삽입 → 실행 → 관찰 → 반복브레이크포인트 → 실행 → 관찰 → 반복
한 번에 확인하는 범위삽입한 로그 지점만중단된 지점의 스코프만
방향 결정개발자의 직감개발자의 직감
속도 제한 요인로그 삽입/삭제/재실행 사이클스텝 실행 속도, 스택 탐색 시간
핵심 병목어디를 봐야 하는지 모른 채 한 지점씩 탐색어디를 봐야 하는지 모른 채 한 지점씩 탐색

디버거가 console.log보다 나은 건 맞다. 변수 상태를 즉시 볼 수 있고, 콜스택을 추적할 수 있고, 코드를 수정하지 않아도 된다. 하지만 접근 방식 자체는 똑같다. 둘 다 "의심 지점을 설정하고, 실행하고, 관찰하고, 다음 지점으로 이동"하는 루프를 반복한다.

문제는 이 루프의 방향을 순전히 개발자의 직감으로 정한다는 점이다. 직감이 맞으면 빠르고, 틀리면 한참을 헤맨다.

디버거가 나쁘다는 것이 아니다

디버거는 훌륭한 도구다. 특히 상태 흐름을 정밀하게 추적해야 할 때는 여전히 최선이다. 문제는 디버거든 console.log든 "어디를 봐야 하는지"를 사람이 직감으로 결정해야 한다는 데 있다. AI는 바로 이 "어디를 봐야 하는지"를 제안하는 데 강하다.

AI 시대 디버깅: 가설-검증 기반 접근

수동 추적이 **"어디서 값이 이상한지"**로 시작한다면, 가설-검증 접근은 **"왜 이런 증상이 나타나는지"**로 시작한다.

핵심 차이는 탐색 방향을 AI가 제안한다는 데 있다. 개발자의 직감 대신 AI가 코드 패턴과 에러 유형을 보고 "가장 가능성 높은 원인"을 확률 순으로 나열해준다. 개발자는 가장 유력한 가설부터 검증하면 된다.

세 접근법의 비교

항목console.log디버거가설-검증 (AI)
시작점어디서 값이 이상한지 찍어보자어디서 상태가 변하는지 걸어보자왜 이런 증상이 나타나는지 추론하자
탐색 방향직감직감 + 콜스택AI가 확률 순 제안
한 사이클 비용높음 (코드 수정 필요)중간 (실행 제어)낮음 (가설 확인만)
범위한 지점씩한 스코프씩여러 가설 동시 고려
속도 결정 요인반복 횟수스택 깊이, 재현 난이도가설 품질
부산물제거해야 할 로그없음문서화된 디버깅 과정
학습 효과이번 버그에만 유효도구 숙련도 향상유사 버그 패턴 인식 축적

디버깅 컨텍스트의 구조

AI에게 에러 메시지만 던지는 건 의사에게 "아파요"라고만 말하는 것과 같다. 좋은 디버깅 요청에는 구조화된 컨텍스트가 필요한데, 겪어 보면 네 가지 요소가 반복해서 등장한다.

요소포함할 내용예시
증상에러 메시지 전문, 기대 vs 실제 동작"TypeError: Cannot read property 'map' of undefined"
재현 조건환경, 빈도, 패턴"로그인 직후 /users 직접 접근 시에만 발생"
시도한 것이미 확인한 부분, 배제한 가설"users 초기값은 빈 배열, API 응답은 정상"
의심 영역원인 추정, 최근 변경, 관련 모듈"SSR/CSR 하이드레이션 타이밍 문제?"

정보 전달 방식의 차이

## 정보가 부족한 경우
이 에러 좀 해결해줘:
TypeError: Cannot read property 'map' of undefined
## 구조화된 정보 전달

### 증상
사용자 목록 페이지에서 TypeError: Cannot read property
'map' of undefined 발생.
페이지 첫 로딩 시에만 발생하고, 새로고침하면 정상 동작.

### 재현 조건
- 로그인 직후 /users 페이지로 직접 접근할 때
- 사이드바에서 네비게이션으로 이동하면 발생하지 않음
- 개발 환경에서만 확인 (프로덕션 미확인)

### 시도한 것
- users 상태의 초기값 확인: 빈 배열
- API 호출 시점 확인: useEffect에서 호출
- 네트워크 탭: API 응답은 정상 (200, 배열 데이터)

### 의심 영역
- SSR/CSR 하이드레이션 타이밍 문제?
- useEffect 실행 전 렌더링 시점에서 데이터가 undefined?

구조화된 컨텍스트의 효과

위처럼 정보를 주면 AI는 5-10초 안에 가능한 원인 3-5개를 확률 순으로 내놓는다. 첫 번째 가설이 맞을 때가 많고, 아니더라도 어디를 확인해야 하는지가 분명해진다.

실전 케이스 스터디 1: React 하이드레이션 버그

버그 상황: 서버와 클라이언트 렌더링 불일치

// UserDashboard.tsx - 문제의 코드
export default function UserDashboard() {
  const [greeting, setGreeting] = useState(
    `안녕하세요, 현재 시각은 ${new Date().toLocaleTimeString()}입니다`
  );
  const [windowWidth, setWindowWidth] = useState(window.innerWidth);

  return (
    <div>
      <h1>{greeting}</h1>
      <p>화면 너비: {windowWidth}px</p>
    </div>
  );
}

에러: window is not defined (SSR 시), 하이드레이션 불일치 경고

접근법 비교

// 1차: 렌더링 확인
console.log("렌더링 시작", typeof window);

// 2차: useEffect 타이밍
useEffect(() => {
  console.log("useEffect 실행", window.innerWidth);
}, []);

// 3차: SSR vs CSR 구분
console.log("IS_SERVER:", typeof window === "undefined");

// ... 5-6번의 로그 삽입/삭제 반복
// 총 소요시간: 약 40분

과정: 로그를 하나씩 심고, 실행하고, 출력을 읽고, 다시 심는 반복. 매번 코드를 수정하고 앱을 재시작해야 한다.

결과 비교:

항목console.log디버거AI 가설-검증
소요 시간약 40분약 15-20분약 3분
코드 수정 횟수6회 (로그 삽입/삭제)0회 (설정만)1회 (최종 수정)
방향 결정직감직감 + 스택AI 가설
학습 효과이 케이스만SSR 디버깅 경험SSR 패턴 전반

핵심은 시간 차이가 아니다. "어디를 봐야 하는지"를 직감으로 찾느냐, AI가 제안하느냐의 차이다. 숙련된 개발자는 디버거로도 빠르게 찾겠지만, AI는 숙련도와 상관없이 일정한 속도를 낸다.

실전 케이스 스터디 2: 간헐적 검색 실패

상황: 검색 결과가 때때로 빈 배열을 반환

// searchService.ts
export async function searchDocuments(query: string) {
  const index = getSearchIndex(); // Orama 인덱스
  const results = await search(index, { term: query });
  return results.hits;
}

같은 검색어로 3번 요청하면 2번은 정상, 1번은 빈 배열 반환. 서버 로그에 에러 없음.

이런 비결정적 버그는 디버거로도 잡기 어렵다. 브레이크포인트를 걸어도 "실패하는 순간"을 잡으려면 여러 번 실행해야 하고, 타이밍 자체가 원인이면 디버거가 실행을 멈추는 것만으로 재현 조건이 바뀌어버린다.

AI에게 전달: 증상 + 코드 + 비결정적 재현 패턴

AI가 생성한 가설 목록:

순위가설확인 방법소요
1인덱스 빌드가 비동기 완료 전 요청 도달빌드 상태 로깅 1줄2분
2캐시 만료 시 빈 결과 반환캐시 비활성화 테스트3분
3커넥션 풀 소진으로 타임아웃커넥션 풀 모니터링5분
4토크나이저의 비결정적 동작동일 입력 반복 테스트5분

가설 1 검증 결과: 원인 확인

// 수정 전: 인덱스 준비 여부 확인 없음
export async function searchDocuments(query: string) {
  const index = getSearchIndex();
  const results = await search(index, { term: query });
  return results.hits;
}

// 수정 후: 인덱스 준비 완료 대기
let indexReady = false;
let indexPromise: Promise<void>;

export async function searchDocuments(query: string) {
  if (!indexReady) {
    await indexPromise; // 인덱스 빌드 완료 대기
  }
  const index = getSearchIndex();
  const results = await search(index, { term: query });
  return results.hits;
}

console.log를 열 군데 심거나 브레이크포인트를 걸고 실패를 기다리는 대신, 가설 하나를 검증해서 문제를 푼 사례다.

AI 협업 디버깅의 흐름

효과적인 AI 디버깅에는 일정한 흐름이 있다.

증상 공유 — 개발자가 사실 기반으로 보고

  • 에러 메시지 전달, 관련 코드 첨부, 재현 조건 설명
  • 핵심: 추측 배제, 관찰한 사실만 전달

가설 수립 — AI가 패턴 매칭 기반으로 가설 생성

  • AI가 가능한 원인을 확률 순으로 나열
  • 개발자가 도메인 지식으로 가설을 필터링하고 우선순위 조정

검증 — 개발자가 유력한 가설부터 확인

  • 한 번에 하나씩 검증, 결과를 AI에게 피드백
  • AI가 검증 방법과 수정안 제안

해결 — 수정 적용 + 회귀 확인

  • 수정 적용, 부작용 확인, 테스트
  • 디버깅 과정을 기록으로 남기기

각 단계에서 개발자와 AI의 역할이 자연스럽게 나뉜다.

단계개발자의 역할AI의 역할
증상 공유사실 기반 보고경청 및 분류
가설 수립도메인 지식으로 필터링패턴 매칭 기반 가설 생성
검증실제 코드 확인, 실행검증 방법 및 수정안 제안
해결수정 적용, 부작용 확인엣지 케이스 점검, 테스트 생성

AI가 잘 못하는 디버깅, 잘하는 디버깅

AI가 만능은 아니다. 유형에 따라 AI의 효과가 크게 달라진다.

AI에게 맡기기 어려운 영역

아래 유형은 AI에게 가설을 받되 최종 판단은 사람이 하는 편이 낫다. AI의 가설을 출발점으로 쓰되, 환경과 맥락을 읽는 사람의 판단이 결정적이다.

디버깅 유형AI가 어려운 이유보완 방법
환경 의존적 버그AI는 로컬 환경을 직접 볼 수 없음환경 변수, OS 버전, 메모리 등 상세 제공
타이밍/동시성 버그비결정적이라 가설 검증이 어려움사람이 시나리오 좁히고 AI가 분석
레거시 코드 버그역사적 맥락을 모름git blame 결과 + 당시 배경 설명
인프라/네트워크 버그코드 레벨이 아닌 환경 문제구성 파일과 로그를 AI에게 제공
데이터 오염 버그DB 상태를 직접 조회 불가쿼리 결과를 텍스트로 전달
UI 레이아웃 버그시각적 렌더링 결과 판단 어려움스크린샷 + DOM 구조 함께 제공

반대로 AI가 확실히 앞서는 영역도 있다.

디버깅 유형AI의 강점활용 팁
타입 에러 / 인터페이스 불일치코드 전체를 빠르게 스캔관련 타입 정의 파일 함께 제공
라이브러리 API 오용방대한 문서 지식사용 중인 버전 명시
정규식 버그패턴 분석과 반례 생성 우수의도하는 매칭 예시 제공
비동기 코드 로직 오류Promise 체인 흐름 추적전체 비동기 흐름 코드 제공
알고리즘 로직 오류반례 빠르게 생성기대 입출력 쌍 제공
CSS 스타일 충돌우선순위 규칙 정확히 적용관련 CSS 파일 모두 제공

이렇게 나눠 놓고 보면, AI 디버깅의 핵심은 "무엇이든 AI에게 맡기는 것"이 아니라 어떤 종류의 문제에 AI를 투입할지 가려내는 것이다.

기존 도구와 AI의 조합

기존 디버깅 도구를 AI와 함께 쓰면, 도구를 쓰는 방식 자체가 달라진다. 도구로 직접 원인을 찾는 대신, AI에게 줄 증거를 모으는 데 쓰는 것이다.

도구기존 사용법AI와 조합한 사용법
브라우저 DevTools네트워크 탭에서 직접 원인 추적응답 헤더/페이로드를 AI에게 분석 요청
디버거 (브레이크포인트)한 줄씩 스텝 실행하며 상태 변화 관찰중단 시점의 변수 스냅샷을 AI에게 전달
프로파일러flame chart를 직접 읽고 병목 판단프로파일링 결과를 AI에게 병목 분석 요청
git bisect수동으로 이진 탐색AI에게 의심 커밋 범위를 먼저 좁히게 한 후 실행
React DevTools리렌더링 횟수를 직접 세고 원인 추적리렌더링 패턴을 AI에게 전달해 원인 분석
구조적 로깅JSON 로그를 직접 읽고 패턴 파악로그 뭉치를 AI에게 패턴 분석 요청

예시: 프로파일러 결과를 AI에게 전달

아래는 Node.js 프로파일러 출력 중 상위 5개 함수입니다.

| 함수 | 자체 시간 | 총 시간 | 호출 횟수 |
|------|----------|---------|----------|
| processOrder | 2.3ms | 450ms | 1 |
| validateItems | 1.1ms | 380ms | 1 |
| checkInventory | 350ms | 350ms | 47 |
| formatResponse | 0.5ms | 0.5ms | 1 |
| logMetrics | 0.2ms | 0.2ms | 1 |

checkInventory가 47번 호출되는 것이 의심됩니다.
상품 목록은 최대 10개인데 왜 47번 호출되는지 분석해주세요.

디버거로 checkInventory에 브레이크포인트를 걸고 47번 스텝 실행하는 것보다, 호출 패턴을 AI에게 던지는 쪽이 훨씬 빠르다.

디버깅 과정의 기록

팀 전체의 디버깅 효율을 높이는 데 의외로 크게 기여하는 것이 디버깅 과정 자체를 기록하는 일이다.

## 버그 #1234: 결제 금액 불일치

### 증상
- 할인 쿠폰 적용 시 최종 결제 금액이 예상보다 높음
- 100원 단위에서 차이 발생

### 가설 (AI 생성)
1. [검증 완료] 반올림 방식 차이 (Math.round vs Math.floor)
   결과: 원인 아님
2. [검증 완료] 할인율 적용 순서 (쿠폰 vs 포인트)
   결과: 원인 확인
3. [미검증] 세금 계산 타이밍

### 원인
할인 적용 순서가 기획 의도와 다름.
기획: 쿠폰 먼저, 포인트 차감
구현: 포인트 먼저, 쿠폰 적용

### 수정
applyDiscount 함수의 적용 순서를 기획 의도에 맞게 수정.

### 교훈
할인 적용 순서는 비즈니스 규칙이므로 CLAUDE.md에 명시 필요.

디버깅 로그의 가치

디버깅 로그를 남기면 효과가 세 가지다.

  1. 같은 버그가 재발하면 곧바로 원인을 짚어낼 수 있음
  2. AI에게 과거 사례를 주면 비슷한 버그의 진단 정확도가 올라감
  3. 팀원 온보딩 때 시스템의 함정을 미리 공유할 수 있음

상황별 디버깅 프롬프트

에러 분석

다음 에러의 가능한 원인을 확률 순으로 3-5개 나열해줘.

에러: [에러 메시지]
발생 위치: [파일명:라인번호]
재현 빈도: [항상/간헐적/특정 조건]
환경: [Node 버전, OS, 프레임워크 버전]

각 가설에 대해:
- 왜 이 에러가 발생하는지 메커니즘 설명
- 확인 방법 1줄 요약
- 예상 수정 방향

성능 병목 분석

아래 프로파일링 결과를 분석하고 최적화 방안을 제안해줘.

[프로파일링 결과 붙여넣기]

현재 응답 시간: [현재값]
목표 응답 시간: [목표값]
제약 조건: [변경 불가능한 부분]

코드 리뷰 기반 잠재 버그 탐지

이 코드에서 버그가 될 수 있는 부분을 찾아줘.
특히 다음 관점에서 검토:
- null/undefined 처리 누락
- 비동기 에러 처리
- 엣지 케이스 (빈 배열, 빈 문자열, 큰 숫자)
- 타입 안전성

[코드 붙여넣기]
프롬프트 유형적합한 상황예상 효과
에러 분석명확한 에러 메시지가 있을 때원인 특정 시간 80% 단축
성능 병목프로파일링 데이터가 있을 때최적화 포인트 즉시 식별
잠재 버그 탐지코드 리뷰 또는 배포 전프로덕션 버그 사전 예방

디버깅 역량의 진화 과정

디버깅 역량이 어떻게 발전하는지 들여다보면 흥미로운 패턴이 보인다. 레벨 1과 2는 도구만 다를 뿐 같은 접근이고, 레벨 3에서 접근 방식 자체가 바뀐다.

레벨 1 — console.log 추적

  • console.log로 값 확인 → 로그 삽입/삭제 반복
  • 에러 메시지 구글 검색 → Stack Overflow 답변 참고
  • 도구: 텍스트 에디터 + 터미널

레벨 2 — 디버거 활용

  • 브레이크포인트, 콜스택 추적, 워치 표현식, 조건부 중단
  • 프로파일러, DevTools 네트워크 탭 등 전문 도구 사용
  • console.log보다 빠르고 정밀하지만, 탐색 방향은 여전히 직감에 의존

레벨 3 — 가설-검증 전환 ← 접근 방식이 바뀌는 지점

  • "어디를 볼까"가 아니라 "왜 이런 증상이 나타나는가"로 시작
  • AI에게 가설 목록을 요청하고 확률 순으로 검증
  • 기존 도구들은 가설을 검증하는 수단으로 역할이 재정의됨

레벨 4 — 체계화

  • 디버깅 과정을 로그로 기록 → 팀 지식 자산화
  • 예방적 디버깅 → AI로 잠재 버그 사전 탐지
  • CLAUDE.md에 반복 패턴 등록 → 같은 유형의 버그 재발 방지

여기서 흥미로운 점은, 레벨 1→2 전환은 도구를 갈아탄 것이지만 레벨 2→3 전환은 접근 방식을 바꾼 것이라는 데 있다. 디버거를 아무리 능숙하게 다뤄도 "어디를 봐야 하는지"를 직감으로 정하는 한 수동 추적의 한계를 벗어나지 못한다.

레벨 4에 도달한 개발자도 때로는 console.log를 쓰고, 때로는 브레이크포인트를 건다. 다만 그것이 유일한 선택지가 아니라는 것을 알고 있을 뿐이다.

이 챕터의 핵심

기억할 한 문장

디버깅의 핵심 변화는 더 좋은 도구를 쓰는 것이 아니라, "어디를 볼까"에서 "왜 이런 증상이 나타나는가"로 출발점을 바꾸는 것이다.

다음 장 미리보기

디버깅에서는 AI에게 좋은 컨텍스트를 주는 것이 핵심이었습니다. 다음 장에서는 이 "컨텍스트 제공" 능력을 더 넓게 확장합니다. AI에게 무엇을 알려주고 무엇을 생략할지 가리는 컨텍스트 관리는 AI 시대 개발자의 새로운 핵심 역량입니다.


참고 자료

참고 자료 안내

이 장의 관점과 프레임워크를 뒷받침하는 참고 자료입니다. 본문의 모든 주장을 아래 자료에서 그대로 인용한 것은 아니며, 실무 경험과 커뮤니티 사례를 묶어 해석한 내용이 섞여 있습니다.

  • Microsoft. "Debug JavaScript in Chrome DevTools." https://code.visualstudio.com/docs/nodejs/browser-debugging
  • Anthropic (2025). "Troubleshooting and Debugging with Claude Code." https://docs.anthropic.com/en/docs/claude-code/common-workflows

관련 문서

가설을 문장으로 고정

Agentic MVP · Agentic MVP의 가장 비싼 비용은 개발 시간이 아니라 애매함입니다. 대상·문제·가치·행동·측정·판정 기준 6줄 가설 템플릿과 타겟을 날카롭게 만드는 질문을 다룹니다.

폼 & 데이터 입력

AI 시대의 디자인 시스템 · FormField 합성, Zod 검증, onBlur 검증 타이밍, 에러 메시지·마이크로카피 표준화, 다단계·동적·조건부 폼 등 AI가 일관된 폼을 생성하기 위한 패턴.

Ch10. IDE 기능 활용

Kiro 고급 활용 · Vibe/Spec 모드, 인라인 편집·컨텍스트 메뉴·명령 팔레트, settings.json 커스터마이징과 Document Attachments·Hunk-Based Edits 등 Kiro IDE 활용법

테스팅 전략의 전환

테스트를 AI 구현 위임의 작업 지시서로 삼는 전환과, 동작 명세 테스트·통합 테스트 비중 확대, AI가 테스트를 쓸 때의 함정을 다루는 장

컨텍스트 관리: 새로운 핵심 역량

컨텍스트 윈도우를 작업 기억으로 이해하고, 프로젝트·세션·프롬프트 3계층으로 정보를 나눠 CLAUDE.md와 컨텍스트 예산으로 AI 출력 품질을 끌어올리는 법

On this page

수동 추적의 두 축: console.log와 디버거console.log 방식디버거 방식공통된 한계AI 시대 디버깅: 가설-검증 기반 접근세 접근법의 비교디버깅 컨텍스트의 구조정보 전달 방식의 차이실전 케이스 스터디 1: React 하이드레이션 버그버그 상황: 서버와 클라이언트 렌더링 불일치접근법 비교실전 케이스 스터디 2: 간헐적 검색 실패상황: 검색 결과가 때때로 빈 배열을 반환AI 협업 디버깅의 흐름AI가 잘 못하는 디버깅, 잘하는 디버깅기존 도구와 AI의 조합예시: 프로파일러 결과를 AI에게 전달디버깅 과정의 기록상황별 디버깅 프롬프트에러 분석성능 병목 분석코드 리뷰 기반 잠재 버그 탐지디버깅 역량의 진화 과정이 챕터의 핵심다음 장 미리보기참고 자료