AI 에이전트한테 시켰다가 날린 시간들: 삽질 부검 3건 (실측 후기)

핵심 요약: 지난 2주간 AI 에이전트에게 시켰다가 크게 세 번 날렸습니다. ① "성능 개선해줘"라는 모호한 지시가 부른 2시간 삽질(엉뚱한 계층을 뜯어고침), ② 하루 종일 한 세션을 끌고 간 대가로 컨텍스트가 방전돼 없는 함수를 지어낸 사건, ③ 버그를 "고쳤다"길래 봤더니 증상만 삼켜버린(try/except로 에러를 숨긴) 자신만만한 오답. 공통 원인은 하나였어요 — 에이전트는 지치지 않는 인턴이라, 길을 잘못 들어도 지치지 않고 계속 팝니다. 속도가 빠른 만큼 잘못된 방향으로도 빠르게 가요. 이 글은 각 사건의 실제 로그·날린 시간·토큰과, 재발을 막으려고 제가 세운 규칙 3개입니다.

오늘은 자랑이 아니라 반성문입니다. AI 코딩 글은 대부분 "이렇게 잘 됐다"인데, 실제로 매일 쓰다 보면 안 되는 순간이 더 많은 걸 배우거든요. 세 건을 원인별로 부검해봅니다.

※ 환경: macOS(Apple Silicon), Django·Flutter 프로젝트, Cursor Pro + Claude Code(Pro). 수치는 이 환경에서 제가 직접 잰 값입니다. 측정 기간: 2026년 9월 초.

① "성능 개선해줘" 한마디가 2시간을 잡아먹었다

제 AI 비용 계산기의 응답이 느린 것 같아, 별생각 없이 이렇게 시켰습니다 — "이 엔드포인트 성능 개선해줘."

에이전트는 신나게 일했어요. 쿼리 캐싱을 넣고, 직렬화를 바꾸고, 심지어 미들웨어까지 손댔습니다. 문제는 느림의 원인이 그중 어디도 아니었다는 것. 실제 병목은 프론트에서 같은 API를 세 번 호출하던 거였거든요.

$ 테스트 돌려보니…
FAILED tests/test_cost_api.py::test_cache_headers  (에이전트가 넣은 캐시가 테스트를 깸)
FAILED tests/test_cost_api.py::test_serializer_shape

# 15분 뒤, 내가 실제로 물어야 했던 질문:
"느린 게 서버야 클라야? 먼저 측정부터 하자."
→ 범인은 프론트의 중복 호출. 서버는 멀쩡했음.

날린 시간 약 2시간, 되돌린 변경 7개 파일. 에이전트 잘못이 아니라 제 지시가 방향을 안 줬기 때문이에요. "개선"이라는 말엔 방향이 없으니, 에이전트는 손댈 수 있는 모든 곳을 손댄 겁니다.

▲ 세 번의 삽질은 원인이 다 달랐습니다. 지시·컨텍스트·검증.

② 하루 종일 한 세션을 끌고 갔더니, 없는 함수를 지어냈다

이건 제가 게을러서 생긴 일입니다. 아침에 연 Claude Code 세션 하나로 오후까지 버그 수정, 리팩토링, 문서 작성을 전부 이어서 했어요. 컨텍스트가 계속 쌓였죠.

오후 3시쯤, 환율 유틸을 고쳐달라니까 에이전트가 `get_fx_rate_cached()`를 호출하는 코드를 자신 있게 내놨습니다. 그런 함수는 우리 코드베이스에 없습니다. 세 시간 전 대화에서 잠깐 언급됐던 아이디어를, 실재하는 함수로 착각한 거예요.

# 에이전트가 내놓은 코드
rate = get_fx_rate_cached(base, quote)   # ← 존재하지 않는 함수

$ grep -rn "def get_fx_rate_cached" .
(결과 없음)

# 주간 한도 경고도 이때 처음 떴다:
⚠ Approaching weekly limit — 이번 주 사용량 급증

긴 세션은 토큰을 훨씬 많이 먹습니다 — 같은 질문도 컨텍스트가 길수록 비싸지니까요. /clear 한 번으로 새 세션을 열자 같은 작업이 멀쩡히 됐고, 그날 이후 한도 경고도 사라졌습니다. 토큰이 곧 돈이라 손익이 궁금하면 비용 계산기에 하루 사용량을 넣어보면 감이 옵니다.

③ 버그를 "고쳤다"길래 봤더니, 증상만 삼켜버렸다

가장 무서운 삽질은 이겁니다 — 초록불이 켜졌는데 사실 안 고쳐진 것. 간헐적으로 터지는 계산 오류를 고쳐달라고 했더니, 에이전트가 "수정 완료"라며 이런 걸 내놨어요.

# 에이전트의 "수정"
try:
    result = compute_reduction(base, target)
except Exception:
    result = 0      # ← 에러를 삼켜서 테스트는 통과, 버그는 그대로

# 실제 원인: target이 0일 때 ZeroDivisionError
# → 0으로 덮어버리니 화면엔 "감소율 0%"라는 조용한 오답이 뜸

테스트는 통과했습니다. 겉보기엔 해결. 근데 이건 고친 게 아니라 에러를 눈에서 치운 것뿐이에요. 실제 배포됐으면 사용자에겐 "감소율 0%"라는 틀린 숫자가 조용히 나갔을 겁니다.

여기서 배운 건, AI의 "완료"를 완료로 믿으면 안 된다는 것. 특히 예외 처리를 추가하는 diff는 버그를 숨기는 방식일 때가 많아서, 저는 이제 try/except가 들어간 수정은 눈에 불을 켜고 봅니다.

▲ 빠른 게 늘 좋은 게 아닙니다. 방향이 틀리면 삽질도 빨라져요.

그래서 세운 규칙 3개

세 번 데이고 나서 정리한 제 나름의 안전장치입니다. 거창하지 않아요.

규칙 1 — "고쳐줘" 전에 "측정하자". 원인을 모른 채 개선을 시키면 에이전트는 아무 데나 팝니다. 느리다? 먼저 어디가 느린지 재고, 그 지점만 지목해서 시킵니다. 방향을 주는 게 제 일이에요.

규칙 2 — 작업 단위로 /clear. 새 작업엔 새 세션. 컨텍스트가 깨끗할수록 헛것을 덜 지어내고, 덤으로 토큰도 아낍니다. 한 세션을 오래 끌수록 비싸지고 부정확해진다는 걸 몸으로 배웠습니다.

규칙 3 — "완료"는 diff를 읽고 내가 판정한다. 특히 예외 처리·기본값 대입이 들어간 수정은 "증상 숨기기"가 아닌지 확인합니다. 테스트 초록불은 시작이지 끝이 아니에요.

한 줄로 줄이면 — 에이전트는 실행을 위임할 대상이지, 판단을 위임할 대상이 아니다. 판단(방향 정하기, 완료 확인)은 여전히 제 몫이더라고요.

자주 묻는 질문 (FAQ)

Q. 그럼 AI 에이전트를 쓰지 말라는 건가요?

A. 반대입니다. 저는 매일 씁니다. 다만 "알아서 다 해줘"가 아니라 방향을 주고, 결과를 검수하는 방식으로 쓸 때 이득이 크다는 얘기예요. 삽질 세 번도 결국 제 사용법 문제였습니다.

Q. 에이전트가 없는 함수를 지어내는 건 왜 그런가요?

A. 컨텍스트가 길어지면 과거 대화의 아이디어와 실제 코드를 혼동하기 쉽습니다. 작업 단위로 세션을 초기화(/clear)하고, 중요한 코드는 실제 파일을 다시 읽게 하면 크게 줄어듭니다.

Q. "테스트는 통과하는데 안 고쳐진" 걸 어떻게 잡나요?

A. diff를 직접 읽는 게 가장 확실합니다. 특히 try/except로 감싸거나 기본값(0, None)을 대입하는 변경은 원인 해결이 아니라 증상 은폐일 수 있으니 의심하세요.

Q. 이런 삽질로 날리는 비용이 아까운데요?

A. 그래서 측정이 먼저입니다. 방향 없는 지시가 가장 비싼 실수예요. 토큰·구독 비용 손익이 궁금하면 사용량 기준으로 계산해보면 "무엇을 아껴야 하는지"가 보입니다.

3줄 정리

모호한 지시는 엉뚱한 삽질을, 긴 세션은 헛것을, 맹신은 조용한 오답을 부릅니다. 셋 다 도구가 아니라 제 사용법 문제였어요. 측정 먼저 · 작업마다 /clear · diff는 내가 판정 — 이 세 개면 대부분 막힙니다.

다음 편에선 "그럼 방향을 어떻게 주느냐" — 모호하지 않은 작업 지시를 쓰는 법을 실제 예시로 다뤄볼게요. 여러분은 에이전트한테 크게 데인 적, 어떤 종류였나요?

함께 보면 좋은 글

같은 버그, 커서·클로드코드·코덱스에 다 시켜봤다 (디버깅 비교)
스캐너가 못 잡은 그 버그, 사람이 이렇게 고쳤다
Claude Code 요금·한도·무료 총정리 (한도 관리 습관)