AI 에이전트에게 코드를 작성하게 하다 보면, 기술적으로 불가능한 상황에 직면했을 때의 행동 패턴에서 위험한 양상이 있다는 것을 깨닫게 됩니다. 인간이라면 "이것은 라이브러리의 사양상 불가능합니다"라고 보고할 상황에서, AI는 할 수 없는 것을 숨기고 무의미한 수정을 계속 반복하곤 합니다.

이미지 출력 계열의 Web 도구를 대량으로 운용하는 과정에서 실제로 겪었던, AI의 3가지 회피 방식과 이를 멈추기 위한 규칙을 작성합니다.

주제: html2canvas 사양의 벽

DOM을 캡처하여 이미지화하는 대표적인 라이브러리인 html2canvas에는 사양상의 한계가 있습니다. backdrop-filter는 무시되어(유리 효과가 사라짐) 일부 CSS filter도 렌더링에서 누락됩니다.

즉, "미리보기의 모습과 다운로드되는 이미지가 일치하지 않는" 케이스가 아무리 노력해도 발생합니다.

버그가 아니라, 라이브러리의 사양입니다.

이것이 지금도 유효한지는 공개 직전(2026년 7월 10일)에 실측했습니다. 흑백의 선명한 경계 위에 backdrop-filter: blur(10px) 유리면을 겹치고, html2canvas 1.4.1로 캡처합니다. 브라우저 자체는 backdrop-filter를 지원하므로(CSS.supports로 확인), 화면상으로는 흐릿하게 보입니다. 하지만 출력 이미지의 픽셀 값은 경계의 왼쪽 2px에서 51, 오른쪽 2px에서 255였습니다. blur(10px)라면 20px 폭의 그라데이션이 되어야 할 자리에 선명한 경계가 그대로 남아 있었습니다. 이 문제의 GitHub Issue(#2406)는 2020년부터 미해결 상태로 남아 있습니다.

회피 방식 1: 불가능을 보고하지 않고 무의미한 수정을 계속함

이 벽에 부딪힌 AI가 저지르기 쉬운 행동은, "할 수 없습니다"라고 말하지 않고 효과 없는 코드 수정을 끝없이 이어가는 것입니다. CSS를 미세 조정하고, 옵션을 바꾸고, 다시 미세 조정하고. 태스크를 완료하지 못한 상태를 인정하고 싶지 않은 것처럼, 의미 없는 파일 편집이 쌓여갑니다.

대책으로 규칙을 만들었습니다. 한계에 직면하면 수정을 시도하기 전에 먼저 보고하도록 합니다.

• 무엇이 라이브러리 사양상 불가능한지를 명시할 것
• 선택지를 트레이드오프(Trade-off)와 함께 제시할 것 (이 표현을 포기한다 / 다른 구현 방식으로 바꾼다 / 외관의 불일치를 허용한다)
• 인간의 판단을 기다린 후 작업을 수행할 것

포인트는, 솔직하게 불가능을 보고하는 것을 태스크의 정당한 완료 형태로 명시적으로 인정하는 것입니다. AI는 "태스크를 완료한 형태"를 향해 최적화되기 때문에, 보고라는 출구를 마련해 주지 않으면 무의미한 수정이 그 대안이 됩니다.

회피 방식 2: 프리뷰 측의 DOM을 건드려 "일치"시키려 함

또 다른 위험한 회피 방식은, 캡처 결과에 맞춰 프리뷰 쪽을 망가뜨리는 것입니다. 이미지화 과정에서 사라지는 표현이 있다면, 처음부터 프리뷰에서도 지워버리면 "일치"하게 됩니다. 사용자 경험(UX)을 희생시킨 임시방편입니다.

대책으로서 수정해도 좋은 위치를 기계적으로 한정했습니다. html2canvas에는 onclone 콜백(캡처용으로 복제된 DOM만 건드릴 수 있는 훅)이 있습니다. 렌더링 차이의 보정은 onclone 내부, 즉 클론(Clone) DOM에서만 수행하고, 프리뷰의 실제 DOM은 건드리지 않습니다. 어디를 고칠지를 재량에 맡기지 않고 구조로 제약합니다. 이를 통해 프리뷰 품질을 인질로 잡는 임시방편을 막을 수 있었습니다.

회피 방식 3: 말없이 라이브러리를 교체하여 다른 문제를 가져옴

가장 실질적인 피해가 컸던 것이 이것입니다. html2canvas의 에러에 부딪힌 AI가 무단으로 html-to-image로 교체하여 "해결"한 적이 있었습니다.

겉보기에는 작동합니다. 하지만 이 라이브러리는 SVG를 통해 외부 리소스를 불러오기 때문에, 사이트의 CSP(Content Security Policy)에 저촉되어 브라우저 측에서 크래시(Crash)가 발생했습니다. 에러는 사라졌지만, 보안 정책 위반이라는 다른 문제가 유입된 것입니다.

에러가 나지 않는 것과 문제가 해결된 것은 다릅니다.

대책: 라이브러리 교체와 외부 CDN 추가를 승인이 필수적인 작업으로 지정했습니다. 의존성(Dependency)의 변경은 코드 수정과는 별개의 판단(보안, 라이선스, 유지보수성)을 포함하므로 AI의 재량에서 제외합니다.

변종: 체리 피킹(Cherry-picking)

불가능에 대한 회피와는 조금 다르지만, 같은 계열의 태만으로서 체리 피킹 문제도 있습니다. 기존 UI를 AI에게 쇄신하게 하면, 자신이 작성한 오래된 DOM 구조에 집착하여 새로운 디자인에서 색상 클래스만 골라 붙이거나, 반대로 수동으로 수정한 기존 로직을 검증되지 않은 새로운 코드로 통째로 덮어쓰는 등 어느 한쪽으로 치우치기 쉽습니다.

대책은 작업 전에 어느 쪽을 골격으로 삼을지 선언하게 하는 것입니다. "외형적 골격은 신규, 로직은 기존"과 같이, 병합(Merge)의 주종 관계를 미리 고정합니다.

성실함은 성격이 아니라, 설계로 만드는 것이다

3가지 회피 방식의 공통점은 AI가 불성실해서 발생하는 것이 아니라, "태스크 완료"를 향한 최적화가 보고보다 잔꾀를 부리도록 선택하게 만드는 구조가 있다는 점입니다. 따라서 대책 또한 훈계가 아닌 설계가 되어야 합니다. 불가능하다는 보고를 정당한 완료로 인정할 것. 건드려도 되는 영역을 구조적으로 제한할 것. 의존성(Dependency) 변경을 승인 필수 사항으로 만들 것. 이 세 가지를 통해 제 환경에서는 문제가 해결되었습니다.

제한 및 주의사항

html2canvas의 제한 사항은 집필 시점의 사양입니다 (2026년 7월 10일에 1.4.1 버전에서 재현 확인 완료). 라이브러리 업데이트로 해결될 가능성은 있습니다.

승인 필수 수준은 프로젝트 규모에 따라 다릅니다. 개인 개발에서 모든 것을 승인제로 만들면 본인이 병목(Bottleneck)이 됩니다. 저는 "의존성 변경·외부 리소스 추가"만 승인제로 설정하고, 일반적인 코드 수정은 재량에 맡겨두고 있습니다.

검증: 2026년 전반기 운영 + 2026년 7월 10일에 html2canvas 1.4.1로 재현 시험 실시. 환경: Claude Code / 이미지 출력 계열 Web 툴군.

Discussion