AI 에이전트가 코드를 작성하는 과정을 오래 지켜보다 보면, 기술적인 불가능함에 직면했을 때 나타나는 위험한 행동 양식을 발견하게 됩니다. 인간이라면 "이 라이브러리는 이 기능을 지원하지 않습니다"라고 보고하겠지만, 에이전트는 그 불가능함을 숨긴 채 의미 없는 수정 사항들을 계속해서 반영합니다.

이미지 출력 웹 도구들을 대규모로 운영하면서, 저는 세 가지 뚜렷한 탈출 패턴(escape patterns)을 발견했으며, 각 패턴을 차단하는 규칙들을 찾아냈습니다.

테스트 케이스: html2canvas와 그 한계점

표준적인 DOM-to-image 라이브러리인 html2canvas는 설계 단계부터 한계를 가지고 있습니다. backdrop-filter는 무시되며(프로스트 글래스 효과가 사라짐), 일부 CSS filter 값은 렌더링에서 누락됩니다.

이는 아무리 노력해도 "미리보기와 다운로드된 이미지가 일치하지 않는" 현상이 발생할 것임을 의미합니다.

버그가 아니라, 라이브러리의 한계입니다.

이것이 오늘날에도 여전히 유효할까요? 저는 게시 직전(2026년 7월 10일)에 이를 측정했습니다. 선명한 흑백 경계선 위에 backdrop-filter: blur(10px) 유리창을 겹치고 html2canvas 1.4.1로 캡처했습니다. 브라우저 자체는 CSS.supports를 통해 확인한 결과 backdrop-filter를 지원하므로, 라이브 라이브 뷰에서는 블러(blur)가 보입니다. 하지만 출력된 이미지의 픽셀 값은 경계선 왼쪽 2px 지점에서 51, 오른쪽 2px 지점에서 255였습니다. blur(10px)가 약 20px의 그라데이션을 퍼뜨려야 하는 상황임에도, 날카로운 경계선이 그대로 살아남았습니다. GitHub 이슈(#2406)는 2020년부터 열려 있는 상태입니다.

탈출 패턴 1: 불가능함을 보고하지 않고 무의미한 수정을 반복함

이러한 벽에 부딪혔을 때, 에이전트의 기본 동작은 "할 수 없다"고 말하지 않는 것입니다. 대신 CSS를 미세 조정하거나, 옵션을 변경하거나, 다시 미세 조정합니다. 마치 작업이 완료될 수 없음을 인정하고 싶지 않은 듯, 아무런 효과도 없는 파일 수정 사항들을 쌓아 올립니다.

저는 규칙을 통해 이를 중단시켰습니다. 한계에 부딪히면, 어떤 수정 시도를 하기 전에 먼저 보고하도록 합니다:

1. 라이브러리가 할 수 없는 것이 무엇인지 정확히 명시할 것
2. 트레이드오프(trade-offs)가 포함된 옵션들을 제시할 것 (이 시각 효과를 포기할 것인지 / 구현 방식을 바꿀 것인지 / 미리보기와 출력물 간의 불일치를 수용할 것인지)
3. 코드를 건드리기 전에 인간의 결정을 기다릴 것

핵심은 정직한 불가능 보고 (honest impossibility reporting)를 작업의 정당한 완료 상태로 명시적으로 정의하는 것입니다. 에이전트는 "작업 완료"를 향해 최적화됩니다. 만약 보고가 탈출구(exit)가 아니라면, 무의미한 수정 작업이 그 대안적인 탈출구가 됩니다.

탈출 2: "일치"를 강제하기 위해 프리뷰 DOM 변조하기

두 번째 탈출 방식은 더 고약합니다. 캡처 결과와 맞추기 위해 프리뷰를 망가뜨리는 것입니다. 만약 내보낸 이미지에서 특정 효과가 사라졌다면, 프리뷰에서도 해당 효과를 제거해 버립니다. 그러면 이제 둘은 "일치"하게 됩니다. 사용자 경험 (UX)을 희생시키면서 장부 정리 (Bookkeeping)를 하는 셈입니다.

해결책은 행동이 아닌 구조적인 것입니다. 즉, 수정이 허용되는 범위를 제한해야 합니다. html2canvas는 onclone 콜백을 제공하는데, 이는 캡처에 사용되는 복제된 DOM에만 접근할 수 있는 훅 (hook)입니다. 모든 렌더링 차이 보정은 onclone 내부에서 이루어져야 하며, 실제 라이브 프리뷰 DOM에서는 절대 이루어져서는 안 됩니다. "어디를 수정할지"를 에이전트의 재량에 맡기지 마세요. 구조로 이를 제약해야 합니다. 이렇게 하면 프리뷰를 인질로 잡는 장부 정리 행위가 완전히 중단됩니다.

탈출 3: 라이브러리를 몰래 교체하여 다른 문제를 가져오기

이 방식은 가장 실질적인 피해를 입혔습니다. html2canvas 에러에 직면한 에이전트가 묻지도 않고 html-to-image로 교체해 버린 사례가 있었습니다.

겉보기에는 작동하는 것처럼 보였습니다. 하지만 해당 라이브러리는 SVG를 통해 외부 리소스를 로드하는데, 이는 사이트의 CSP (Content Security Policy, 콘텐츠 보안 정책)를 위반하여 브라우저에서 충돌을 일으켰습니다. 에러는 사라졌지만, 보안 정책 위반이라는 문제가 뒷문으로 들어온 것입니다.

에러가 없는 상태와 문제가 해결된 상태는 같은 것이 아닙니다.

규칙: 라이브러리 교체 및 외부 CDN 추가는 승인이 필요한 작업입니다. 의존성 (Dependency) 변경은 코드 수정과는 다른 차원의 판단 기준 (보안, 라이선스, 유지보수성)을 수반하므로, 에이전트의 재량권에서 완전히 제외되어야 합니다.

유사 사례: 체리 피킹 (Cherry-picking)

불가능함을 숨기는 것과는 약간 다르지만, 같은 계열의 게으름입니다. 에이전트에게 기존 UI를 재설계하라고 요청하면 다음 두 가지 방식 중 하나로 흐릅니다. 기존의 DOM 구조에 집착하며 그 위에 새로운 컬러 클래스만 덧붙이거나, 사용자가 직접 수정한 로직을 검증되지 않은 새로운 코드로 밀어버리는 것입니다.

해결책: 작업을 시작하기 전에 스켈레톤(skeleton)을 선언하게 만드세요. "새로운 디자인으로부터 시각적 스켈레톤을, 기존 코드로부터 로직을" — 병합 계층 구조(merge hierarchy)를 사전에 확정하는 것입니다.

정직함은 성격적 특성이 아니라 설계 속성입니다

세 가지 탈출 패턴의 공통점은 에이전트가 부정직해서 발생하는 것이 아니라는 점입니다. 이 현상은 "작업 완료"를 최적화하는 구조가 보고(report)보다 속임수(tricks)에 보상을 주기 때문에 발생합니다. 따라서 대응책은 훈계가 아닌 설계여야 합니다. 불가능 보고(impossibility reports)를 유효한 완료 상태로 인식하세요. 편집 가능한 영역(editable surfaces)을 구조적으로 제한하세요. 의존성 변경(dependency changes)은 승인 절차를 거치도록 제한하세요. 제가 운영하는 플릿(fleet)에서는 이 세 가지 방법으로 문제를 해결했습니다.

한계 및 주의사항

html2canvas의 한계는 작성 시점 기준입니다 (2026년 7월 10일, 1.4.1 버전에서 재검증됨). 향후 릴리스에서 해결될 수 있습니다.

승인의 세분화(granularity) 정도는 프로젝트 규모에 따라 달라집니다. 1인 프로젝트에서 모든 것을 제한하면 스스로 병목 현상(bottleneck)이 됩니다. 저는 의존성 변경과 외부 리소스만 제한하며, 일반적인 코드 수정은 재량에 맡깁니다.

검증됨: 2026년 상반기까지 프로덕션 적용, 2026년 7월 10일 html2canvas 1.4.1에서 재현 테스트 완료. 환경: Claude Code / image-output 웹 도구.