AI UI 자동 수정이 실패하는 이유와 궁극적인 해결책

@Lonely__MH
중국어2026년 9월 13일
185K
241
36
58
483

TL;DR

저자는 AI 기반 UI 자동 수정이 종종 품질 저하로 이어지는 이유를 탐구하고, 시각적 차이 비교(visual diffs), 구조화된 진단, 그리고 과거의 최적 버전을 보존하여 결과를 안정화하는 워크플로우를 제안합니다.

이 글은 최근 AI를 사용해 페이지를 복제할 때 겪었던 몇 가지 함정을 기록한 것입니다. 이후 이러한 문제를 해결하기 위한 워크플로우를 구축하고 전체 과정을 참고용으로 정리했습니다.

여러분도 이런 경험을 해본 적이 있을 겁니다.

가끔 스크린샷을 AI에게 던져주고 이를 바탕으로 페이지를 만들어 달라고 요청하곤 합니다. 첫 버전은 대략적으로 맞아 보이지만, 자세히 살펴보면 어딘가 이상합니다: 카드가 약간 더 넓고, 폰트가 작으며, 그림자가 틀리는 등 사소한 문제들이죠.

그런 다음 어떤 부분을 어떻게 수정해야 하는지 말로 설명해야 합니다. 여러 라운드를 반복하는 데 상당한 시간이 걸립니다.

그래서 렌더링, 스크린샷, 비교, 수정을 하나의 워크플로우로 연결하여 모델이 스스로 확인하고 수정하도록 해보려 했습니다. 이 접근법은 합리적으로 보였습니다.

하지만 실제로는 계획대로 되지 않았습니다. 2라운드를 수정한 후 3라운드에서 변경 사항이 되돌아가는 경우가 있었고, 결과가 들쭉날쭉했으며 페이지가 반복될수록 오히려 나빠지기도 했습니다.

바로 본론으로 들어가겠습니다.

스스로 교정하게 만드는 방법

프로세스는 복잡하지 않습니다:

text
1Target Screenshot ──▶ Model writes HTML ──▶ Browser renders 1:1 screenshot ──▶ Pixel-by-pixel diff generation
2
3Keep Best History ◀── Re-render ◀── Model diagnoses then edits code ◀── Original + Rendered + Diff

Diff 는 모델을 위해 페이지를 고쳐주지 않습니다. 단순히 "뭔가 좀 아닌 것 같다"는 느낌을 구체적인 편차의 시각적 지도로 변환하여 모델에 다시 전달하고, 모델이 다음 단계를 결정하도록 돕습니다.

모델이 Diff 에 근거해 막연히 추측하는 것을 방지하기 위해, 각 수정 전에 세 가지 질문에 답하도록 요구합니다:

  1. 가장 큰 문제는 어디인가?
  2. 어떤 요소나 CSS 속성이 원인일 가능성이 높은가?
  3. 어떻게 수정할 계획인가?

답변을 한 후에만 코드를 건드립니다.

이번 테스트에서는 Ling-3.0-flash-VL 을 사용했고, 간단한 데모를 위해 두 개의 카드를 선택했습니다: 하나는 밝은 배경에 굵은 검은 테두리와 선명한 그림자가 있는 노란색 카드이고, 다른 하나는 그라데이션 버튼, 태그, 기능 목록이 포함된 어두운 SaaS 가격 카드입니다.

저는 카드가 완벽하다고 생각합니다. 요소가 너무 많지도 않지만, 너비, 여백, 버튼 방향, 그림자 중 하나라도 어긋나면 즉시 눈에 띄기 때문입니다.

첫 번째 실행

노란색 카드로 시작해 봅시다.

첫 번째 버전 이후 전반적인 결과는 꽤 좋았습니다.

구조, 색상 구성표, 복사문, 버튼 위치가 대부분 복제되었습니다. 원본과 나란히 비교하지 않는다면 충분히 유사하다고 생각할 수 있습니다.

하지만 함께 배치하면 미묘한 차이가 드러납니다: 카드가 약간 더 크고, 폰트 두께가 다르며, 여백/버튼 크기가 완벽하게 정렬되지 않았습니다.

그런 다음 원본 이미지, 1라운드 결과, Diff 를 다시 Ling 에게 입력하여 이러한 세부 사항을 식별하도록 요청했습니다.

진단 결과를 보면 단순히 "충분히 유사하지 않다"고 하지 않습니다. 카드 크기, 폰트, 버튼 등의 문제를 정확히 집어낸 후 해당 CSS 를 수정합니다.

Lonely - inline image

노란색 카드의 3라운드 비교: 2라운드는 개선되었지만 3라운드는 퇴보했으므로, 역사상 최고였던 2라운드를 유지했습니다.

그러나 좋은 첫 라운드가 지속적인 개선을 보장하지는 않습니다.

이 영상은 해당 문제를 포착합니다: 2라운드는 원본에 더 가까웠지만, 3라운드에서는 약간 밀렸습니다. 다행히 워크플로우는 마지막 라운드를 기본 답변으로 삼지 않고 2라운드의 역사상 최고 버전을 보존했습니다.

따라서 Diff 를 다시 입력한다고 해서 모델이 갑자기 똑똑해지는 것은 아닙니다. 많은 세부 사항을 찾아내고 판단을 특정 CSS 에 매핑할 수 있지만, 여전히 혼란스러워할 때가 있습니다.

워크플로우가 실행되는 방법에 대한 자세한 내용은 아래 화면 녹화를 참조하세요.

Lonely - inline image

어두운 가격 카드의 전체 데모: 자산 선택, 초기 생성, 슬라이더 비교, 그리고 두 번의 자가 치유 라운드 실행.

여기서의 변화는 극적이지 않았는데, 이는 첫 라운드가 이미 매우 가까웠기 때문입니다. 후속 라운드에서는 카드 크기, 모서리 둥글기, 버튼, 그라데이션에 초점을 맞춰 지속적으로 개선이 이루어졌습니다.

두 녹화 파일을 비교하면 서로 다른 추세를 볼 수 있습니다:

Lonely - inline image

노란색 카드는 2라운드까지 개선되었으나 3라운드에서 퇴보했고, 어두운 카드는 세 라운드 모두에서 꾸준한 소폭의 개선을 보였습니다. 두 개의 녹화 파일로 통계적 규칙을 증명할 수는 없지만, 동일한 워크플로우가 항상 라운드마다 더 나은 결과를 낳는 것은 아님을 보여줍니다.

명백한 문제는 보통 첫 한두 라운드에서 해결됩니다. 이후 반복에서는 폰트 크기, 모서리 둥글기, 그림자 오프셋 미세 조정이 이루어지며, 이때 하나를 고치면 다른 하나가 망가지는 경우가 많습니다. 따라서 저는 마지막 라운드가 정답이라고 가정하지 않고 역사상 최고의 버전을 저장합니다.

실제로 무엇을 할 수 있나요?

이러한 결과를 통해 첫 번째 버전은 표준적인 스크린샷-투-코드 (Screenshot-to-Code) 임을 알 수 있습니다. 흥미로운 점은 렌더링된 출력을 본 후, 단순히 "더 비슷하게 만들어라"라고 말하는 대신 문제를 특정 요소와 CSS 속성으로 정확히 집어낼 수 있다는 것입니다.

자동 수정이 없더라도 이 진단 단계는 유용한 체크리스트 역할을 합니다.

많은 시각적 문제는 오류를 발생시키지 않습니다. 모델이 브라우저의 실제 렌더링된 페이지를 볼 수 있다면, 스스로 계속 수정할 기회가 생깁니다.

또 다른 실용적인 측면: 이 워크플로우는 반복적인 모델 호출이 필요하므로 속도가 중요합니다. 제가 기록한 단일 전체 페이지 HTML 생성에는 약 7 초가 소요되었습니다. 공개 데이터에 따르면 Ling-3.0-flash-VL 은 총 매개변수가 124B 이며, 추론 시 5.5B 가 활성화되고 시각 이해 및 Visual Agent 기능이 추가되었습니다.

7 초라는 수치는 제 특정 인터페이스와 설정을 기반으로 합니다. 저는 횡단 비교를 수행하지 않았으며, 활성 매개변수만으로 속도/비용을 도출하지 않을 것입니다.

함정은 어디에 있나요?

실제 시간 낭비의 주된 원인은 모델 연결이 아니라 피드백의 정확성을 확보하는 것이었습니다. 처음에는 변동성이 모델 불안정성 때문이라고 생각했습니다. Diff 를 하나씩 검토해 보니, 문제의 일부는 저의 피드백 루프에 있었습니다.

1. 첫 번째 함정: 크기

타겟 이미지가 축소되었고 브라우저 스크린샷이 다른 크기로 찍혔다면, 이미지는 처음부터 정렬되지 않습니다. 정답이 맞더라도 Diff 는 큰 불일치를 보여줍니다.

픽셀 Diff 의 경우, 전역적으로 몇 픽셀만 어긋나도 거대한 오차 영역이 발생합니다.

2. 두 번째 함정: 애니메이션

한번은 모델이 기능 목록에 페이드 인 효과를 추가했습니다. 애니메이션 중간에 캡처된 스크린샷은 콘텐츠가 투명하게 남았습니다.

애니메이션을 제거한 후 페이지는 시각적으로 정상으로 보였지만, 자동화된 비교 점수는 오히려 악화되었습니다.

이유: 투명한 콘텐츠가 배경을 드러내어 픽셀 알고리즘이 "더 비슷해 보인다"고 판단했기 때문입니다.

3. 세 번째 함정: 버전 관리

어떤 라운드에서 디자인이 망가졌다면, 잘못된 코드 위에 계속 패치를 적용하면 오류가 누적됩니다. 마치 기울어진 기초 위에 집을 짓는 것과 같아서, 노력할수록 더 엉망이 됩니다.

요약하자면, Diff 는 도구이지 판사가 아닙니다.

피드백이 잘못되면 모델은 이를 알아채지 못합니다. 결함이 있는 입력을 바탕으로 성실하게 잘못된 방향을 수정하려 할 뿐입니다.

결론

규칙을 세 가지로 요약했습니다:

  1. 원본과 브라우저 스크린샷은 동일한 차원을 사용하고, 2 차 축소는 하지 마세요.
  2. 뷰포트, 폰트, 애니메이션 상태, 스크린샷 타이밍을 고정하세요.
  3. 각 라운드마다 역사상 최고의 버전에서 계속 진행하며, 성능이 저하된 코드를 패치하지 마세요.

작동하는 코드는 단지 첫 단계일 뿐입니다. 오류는 아니지만 모양새가 이상한 문제는 시각 모델이 실제로 확인할 수 있습니다. 그러나 편차를 발견했다고 해서 매번 올바르게 수정할 수 있다고 보장되지는 않습니다.

그래서 저는 이제 라운드가 많을수록 결과가 더 좋을 것이라고 가정하지 않습니다. 명백한 문제를 먼저 고치고, 개선이 정체되면 멈추는 것이 저에게는 충분합니다.

모델은 오픈 소스이며 2 주간 무료입니다. 직접 실행하려면 다음 링크를 사용하세요 👇🏻:

P.S.: 이 기사는 AI 가 구술하고 다듬었으므로 영혼이 담겨 있습니다 ✌🏻

원클릭 저장

YouMind로 바이럴 글을 AI 심층 읽기

소스를 저장하고, 핵심 질문을 던지고, 주장을 요약해 바이럴 글을 다시 활용할 수 있는 노트로 바꾸세요. 하나의 AI 워크스페이스에서 모두 할 수 있습니다.

YouMind 둘러보기
크리에이터를 위해

당신의 Markdown을 깔끔한 𝕏 글로

직접 쓴 장문을 올릴 때 이미지, 표, 코드 블록을 𝕏에 맞게 정리하는 일은 번거롭습니다. YouMind는 전체 Markdown 초안을 깔끔하고 바로 게시할 수 있는 𝕏 글로 바꿔 줍니다.

Markdown → 𝕏 사용해 보기

분석할 패턴 더 보기

최근 바이럴 아티클

더 많은 바이럴 아티클 보기