스킬캠퍼스

오늘 끝나면

검증과 디버깅

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

실습 미션

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

성공 조건

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

바이브코딩 · 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 프로그램

도구

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