스킬캠퍼스
9강 · 검증과 디버깅
강의

오늘 끝나면

검증과 디버깅

  • 검증과 디버깅의 핵심 문제를 한 문장으로 설명한다
  • 오른쪽 실습에서 검증과이 어떻게 움직이는지 관찰한다
  • 다음 강의와 이어지는 한계를 말할 수 있다

실습 미션

믿되 확인 — 에이전트 결과 검증하기 이 문장이 실제로 무슨 뜻인지 실습에서 한 번 손으로 확인한다.

성공 조건

  • 실습의 기본값을 먼저 관찰
  • 입력값이나 모드를 한 번 이상 바꿔 결과 비교
  • 왜 결과가 바뀌었는지 한 문장으로 설명

바이브코딩 · 09

검증과
디버깅

에이전트는 그럴듯하게 틀릴 수 있음.
믿되 확인 — 테스트·빌드·리뷰로 검증함.
떨어지면 맥락 보강해서 재시도함.

P.01바이브코딩 · 09

그럴듯하게 틀린다

에이전트는 LLM + 도구 루프임. 문장을 그럴듯하게 잇는 게 본질이라, 틀린 답도 자신 있게 내놓음.

코드를 짜주면 변수명도 깔끔하고 주석도 달려 있음.
그래서 읽으면 맞아 보임. 근데 보기 좋은 것과 도는 건 다른 문제임.

엣지케이스를 빼먹거나 · 없는 함수를 부르거나 · 미묘하게 한 칸 어긋남.
겉이 매끈할수록 더 위험함 — 의심 없이 그냥 믿어버리게 되니까.
그래서 첫 원칙은 하나임. 결과는 증거 없이 안 믿음.

자신감 ≠ 정답
매끈한데 · 틀림
1function parse(s) {
2 const n = Number(s)
3 return n * factorfactor 없음
4}
읽으면맞아 보임 ✓
돌리면factor is not defined ✕

겉이 매끈할수록 더 의심해야 함

P.02바이브코딩 · 09

믿되 확인한다

그렇다고 일일이 손으로 다 짤 거면 에이전트를 쓸 이유가 없음. 핵심은 믿되 확인임.

에이전트가 빠르게 초안을 냄 — 그건 믿고 받음.
대신 그 결과를 그대로 머지하지 않고, 객관적인 게이트에 통과시켜 확인함.

확인의 도구는 세 가지임 — 테스트 · 빌드 · 리뷰.
사람의 감이 아니라, 돌려보고 깨지는지 보는 기계적 검증이 기준임.
통과하면 믿고, 떨어지면 안 믿음. 판정을 사람의 인상에 맡기지 않는 게 요점임.

검증을 거친 결과만 통과
믿되 · 확인
믿음에이전트가 초안을 빠르게 냄
테스트
빌드
리뷰
확인됨통과한 결과만 머지

판정은 사람 인상이 아니라 게이트가 함

P.03바이브코딩 · 09

검증 게이트 — 테스트·빌드

검증을 게이트로 세움. 오른쪽에서 직접 돌려봄 — 에이전트 결과를 테스트·빌드에 통과시켜 합격/재시도를 판정함.

품질 슬라이더를 내리면 결과가 그럴듯하게 틀린 상태가 됨.
검증 실행을 누르면 테스트가 먼저 돌고, 다음 빌드가 돎.

둘 다 ✓면 합격 → 머지. 하나라도 ✕면 불합격 → 재시도임.
품질을 올릴수록 통과 확률이 커짐 — 게이트는 못 속임.
겉보기는 늘 멀쩡한데, 떨어뜨리는 건 항상 게이트라는 점이 핵심임.

결과를 게이트에 통과시킴
검증 게이트 · 에이전트 결과를 의심하고 통과시킴
에이전트 결과 — 겉보기엔 늘 그럴듯함
patch+ fix(parser): handle empty input
실제 품질(숨겨진 값)45
그럴듯하게 틀림진짜 맞음
검증 게이트 — 둘 다 통과해야 믿음
테스트단위 테스트가 다 도나
빌드컴파일·번들이 안 깨지나
판정시도 0

아직 안 돌림. 결과는 믿기 전에 게이트를 통과시켜야 함.

P.04바이브코딩 · 09

실패하면 맥락을 보강한다

게이트가 떨어뜨리는 건 끝이 아니라 시작임. 실패는 가장 좋은 피드백임.

그냥 “다시 해”라고 던지면 똑같이 틀림 — 새 정보가 없으니까.
그래서 실패한 테스트 이름 · 에러 메시지 · 스택 트레이스를 맥락에 더해서 다시 시킴.

에이전트는 보강된 맥락으로 어디가 깨졌는지 보고 고침.
고친 결과를 다시 같은 게이트에 통과시킴 — 통과할 때까지 이 루프를 돎.
이게 디버깅의 모양임. 실패를 맥락으로 바꿔 되먹이는 순환임.

실패 로그 → 맥락 → 재시도
실패 → 맥락 → 재시도 루프
에이전트검증 게이트실패 로그맥락에 더함통과 → 머지✕ 재시도

그냥 “다시”가 아니라, 실패 정보를 더해 다시 시킴

P.05바이브코딩 · 09

적대적 검증이 핵심

좋은 검증은 통과시키려 하지 않음. 떨어뜨리려고 덤빔 — 이게 적대적 검증임.

결과를 옹호하는 눈으로 보면 죄다 통과시킴 — “돌 것 같은데”로 넘어감.
반대로 깨뜨릴 입력은 뭔지 · 빠진 케이스는 뭔지 캐는 눈이 진짜 검증임.

그래서 에이전트가 짠 코드면 테스트도 사람이 따로 보거나 다른 에이전트에 맡김.
짠 쪽과 검증하는 쪽을 갈라야 자기 코드를 봐주지 않음.
정리하면 — 믿되 확인하고 · 떨어지면 맥락 보강해 재시도하고 · 검증은 적대적으로.

Q. 에이전트 결과를 믿어도 되는 기준은? (코드가 깔끔함 · 에이전트가 확신함 · 검증(테스트/빌드/리뷰) 통과 · 분량이 많음)정답은 검증(테스트/빌드/리뷰) 통과임.
에이전트는 그럴듯하게 틀릴 수 있어서, 깔끔함·확신·분량은 근거가 못 됨.
돌려보고 깨지지 않는다는 객관적 증거 — 테스트·빌드가 통과했을 때만 믿음.
떨어지면 실패 로그를 맥락에 더해 다시 시키는 게 디버깅 루프임.
떨어뜨리려는 쪽이 품질을 지킴
옹호 ↔ 적대
옹호적대
보는 눈통과시키려 함떨어뜨리려 함
질문돌 것 같은데?뭐로 깨뜨리지?
검증자짠 사람 본인다른 사람·에이전트
결과버그가 샘버그를 잡음

짠 쪽과 검증하는 쪽을 가르는 게 핵심

3줄 요약

  1. 1믿되 확인 — 에이전트 결과 검증하기
  2. 2검증과 디버깅은 에이전트 원리 → 도구·권한 → 스킬·하네스 → 멀티에이전트 → 실전 흐름 안의 한 칸이다.
  3. 3개념을 외우는 것보다 입력을 바꾸면 무엇이 달라지는지 보는 것이 우선이다.

완료 전 점검

복습 카드

검증과

믿되 확인 — 에이전트 결과 검증하기

에이전트

스스로 도구를 써가며 일하는 LLM 프로그램

도구

에이전트가 호출하는 기능(파일·실행·검색)