AI개발 AI가 실제로 반복한 실수 모음 — 진짜 사고 편

2026년 10월 29일 · @martin

가상 사례는 이제 그만

이 글에 나오는 사고는 전부 실제로 겪은 일입니다.

클로드 코드와 클로드로 제품을 만들고, 로고·명함·방 배치 같은 일상 일까지 맡기면서 진짜 사례가 쌓였습니다. 대화 기록을 다시 훑어보니 일곱 건이 나왔고, 모아 놓고 보니 같은 모양이 반복됐습니다.

그래서 이번 글은 사례 나열이 아니라 패턴 정리입니다. 실수의 종류를 알면 어디에 장치를 걸지 알 수 있기 때문입니다.

한눈에 보기

일곱 건은 네 가지 패턴으로 묶입니다. 패턴마다 막는 자리가 다릅니다.

패턴 1. 보이는 것만 옮긴다

AI는 화면에 찍히는 부분은 정확하게 만들고, 출력 없이 상태만 바꾸는 줄은 빼먹습니다. 두 건 모두 미단재 게시판에 글이 쌓이고 나서야 드러났습니다.

페이지 번호 41개가 한 줄에

목록 하단에 1부터 41까지 페이지 번호가 전부 깔려 가로로 넘쳤습니다. 클로드 코드가 디자인에 맞춰 새로 짠 페이저 뷰에서 CI4 기본 템플릿 첫 줄이 빠진 것이 원인이었습니다.

<?php $pager->setSurroundCount(2) ?>

이 호출이 없으면 PagerRenderer는 첫 페이지부터 마지막 페이지까지 모두 그립니다. <ul> 마크업과 클래스는 깔끔했지만, 화면에 아무것도 찍지 않는 설정 한 줄은 옮겨 오지 않았습니다. 글이 몇 개 없을 때는 페이지가 두세 개라 "전부 출력"과 "앞뒤 2개 출력"의 결과가 같아 아무도 몰랐습니다.

요약문에 —가 글자 그대로

페이저를 고치고 나니 같은 화면의 요약문에 —,  가 문자 그대로 노출돼 있었습니다. 본문 HTML에서 strip_tags()로 태그만 벗기고 엔티티는 디코딩하지 않은 채 자른 뒤, 뷰의 esc()가 &를 한 번 더 이스케이프한 것으로 보였습니다.

"태그 벗기고 자르기"는 어디서나 볼 수 있는 관용구입니다. AI는 그 관용구를 그대로 가져왔고, 특수문자가 든 글이 들어오기 전까지는 문제가 없었습니다.

두 건의 원인은 화면 증상을 보고 잡은 것이라, 실제 코드와 다르면 바로잡아 주세요.

공통점: 없어도 당장 티가 안 나는 줄이 빠집니다. 빈 DB로는 절대 안 보입니다.

패턴 2. 일반론을 내 환경에 그대로 쓴다

AI가 꺼내는 답은 대개 교과서적으로 맞습니다. 문제는 제 저장소와 제 도구가 교과서와 다르게 설정돼 있다는 걸 모른다는 점입니다.

스쿼시 머지 저장소에서 git branch --merged

dev-issue 스킬을 만들면서 브랜치 정리를 맡기면, AI는 머지 여부를 git branch --merged로 판단하려 했습니다. 머지 커밋으로 합치는 저장소라면 정답입니다.

저는 feature → dev를 스쿼시 머지로 합칩니다. feature의 원래 커밋은 dev 이력에 없으니, git 입장에서는 머지되지 않은 브랜치입니다. 정리 대상이 하나도 안 잡혔습니다.

결국 기준을 바꿨습니다. 머지 여부는 git이 아니라 PR에 묻습니다.

gh pr list --state merged --base dev --json headRefName -q '.[].headRefName'

이 판단 기준은 지금 prune-branch 스킬 맨 위에 적혀 있습니다.

명함 재단 여백 3mm

AIvance 명함에 "AI 개발 · 컨설팅 · 교육" 문구를 넣고 미리캔버스에 올리는 작업이었습니다. 두 번 걸렸습니다.

1. SVG가 mm 단위 크기와 외부 폰트를 쓰는 텍스트로 돼 있어 미리캔버스가 받지 않았습니다. 폰트를 넣고 600dpi PNG로 바꿔서 해결했습니다.
2. 파일은 재단 여백 3mm의 96×56mm로 만들어져 있었습니다. 미리캔버스는 여백 2mm의 94×54mm입니다.

두 번째가 진짜 사고감이었습니다. 앞면 하단의 그라데이션 바가 3mm 여백 안에 통째로 들어 있어, 그대로 인쇄했다면 재단되면서 사라졌을 겁니다. 내가 채널 사양을 말하기 전까지 AI는 "명함은 보통 3mm"라는 일반론으로 작업했습니다.

공통점: 틀린 지식이 아니라 내 사정을 모른 것입니다. 내 사정은 내가 적어 주지 않으면 AI가 알 길이 없습니다.

패턴 3. 모르는 걸 그럴듯하게 채운다

가장 자주 나온 패턴입니다. 정보가 비어 있으면 AI는 멈추거나 묻지 않고, 가장 그럴듯한 값으로 채워서 계속 갑니다.

방 배치: 책상을 행거로, 책장을 침대로

작업실 책상 세 개의 배치를 물어본 적이 있습니다. 방은 370×270cm이고 안쪽으로 여는 문이 두 개입니다. AI는 그림을 그려 가며 제안했는데, 제가 고친 것만 이렇습니다.

• 프린터와 레이저 각인기를 올려 둔 3번 책상을 행거 수납장으로 봤습니다.
• 의자를 A문이 열리는 자리에 두었습니다.
• 왼쪽 벽 길이를 실제보다 짧게 잡았습니다.
• 책장을 침대로 알고 있었습니다.

하나하나는 사소한데, 하나만 틀려도 배치안 전체가 무너집니다. 최종안은 제가 직접 만들었습니다.

기록과 제안을 섞는다

블로그 주제를 추천받다가, AITessera 레이트 리밋 주제의 출처를 물었습니다. 인증 10회/분, 일반 120회/분이라는 숫자의 근거는 제 기록이 아니라 AI가 예전에 제안한 것이었습니다. 그런데 "기록에 있는 것"처럼 소개됐습니다. 강의 준비 주제에도 같은 과장이 있어 함께 정정했습니다.

제가 물어보지 않았다면, AI의 제안이 제 결정인 것처럼 블로그에 올라갔을 겁니다.

블로그 글의 그럴듯한 숫자

이 블로그의 초안도 예외가 아니었습니다. 메모리 파일·worktree 글의 사고 사례는 가상이었고, CI 테스트 속도 글에는 중간 측정치 같은 숫자가 채워져 있었습니다. 셀프호스티드 러너 글의 에러 메시지, 네이버 연동 글의 일부도 제 기록이 아닌 일반론이었습니다.

다행히 매번 "이 부분은 기록에 없다"는 표시가 붙어 있었고, 그 표시를 보고 고칠 수 있었습니다. 표시가 없었다면 독자는 제 경험으로 읽었을 겁니다.

공통점: 빈칸을 채운 값은 틀려도 자연스럽습니다. 그래서 가장 위험합니다.

패턴 4. 말로 한 지시는 다음 세션에 없다

클로드 코드를 쓰기 시작한 초반, 모든 메시지를 한국어로 하라고 했는데도 자꾸 영어로 답했습니다. 작업 중간에 영어로 바뀌는 일도 있었습니다.

원인은 세 가지가 겹쳐 있었습니다.

• 대화로 한 지시는 세션이 끝나면 사라집니다.
• 언어 규칙이 CLAUDE.md에 없었습니다.
• 코드, 에러 메시지, 로그가 모두 영어라 컨텍스트가 영어 쪽으로 기울었습니다.

해결은 단순했습니다. 말로 하던 걸 파일에 적었습니다.

## 언어
- 모든 응답, 커밋 메시지 설명, 코드 주석은 한국어로 쓴다.

한국어 일관성은 지금도 완벽하게 막히지는 않습니다. 그래도 규칙이 파일에 있으면 새 세션이 시작할 때마다 그 줄을 읽고 시작합니다.

공통점: 내가 기억하는 것과 AI가 기억하는 것은 다릅니다. 파일에 없으면 없는 것입니다.

패턴별로 거는 장치

네 패턴은 막는 자리가 다릅니다. 실수를 줄이는 건 요청을 더 잘 하는 것보다, 각 패턴에 맞는 자리에 장치를 하나씩 거는 것이었습니다.

세 번째 줄은 기록을 바탕으로 글을 쓸 때 특히 중요합니다. 이번에 모은 블로그 사례는 "기록에 없다"는 표시 덕분에 고칠 수 있었지만, 그 표시는 본문이 아니라 채팅 끝에 붙어 있어 놓치기 쉬웠습니다.

블로그 글 스킬을 따로 만든 것도 같은 이유입니다. 20편 가까이 매번 말로 요청하다 보니, 매번 같은 말을 하고 있었습니다.

돌아보며

일곱 건을 모아 보니, AI가 모르는 것을 모르는 실수는 거의 없었습니다. CI4 페이저도, 스쿼시 머지도, 재단 여백도 AI는 다 알고 있었습니다.

빠진 건 제 사정이었습니다. 제 저장소가 어떻게 합치는지, 제 방에 무엇이 있는지, 어느 숫자가 제 결정이고 어느 것이 AI의 제안이었는지. 사람 팀원이라면 눈치로 챙길 것들입니다.

그렇다면 AI에게 일을 맡기기 전에 물을 질문은 하나로 줄어듭니다. "이 일에서 내 사정은 무엇이고, 그걸 어디에 적어 두었나?"

사고는 앞으로도 날 겁니다. 쌓이면 2편으로 돌아오겠습니다.