AI가 시안대로 UI를 짜도, 맞는지 자동으로 검증할 수가 없다 — 개발 자동화 루프의 진짜 병목

개인 개발 루프를 최대한 AI에게 맡기면서 가장 먼저 체감한 건 "화면이 빨리 나온다"였다. 디자인 시안 이미지 한 장을 던지면 그럴듯한 프론트엔드 코드가 몇 초 만에 돌아온다. 그런데 한참 뒤에야 이상한 지점을 깨달았다. 정작 손이 멈추는 곳은 코드를 만드는 단계가 아니라, 그렇게 나온 화면이 시안대로 됐는지 확인하는 단계였다. 이 확인만큼은 여전히 내가 눈으로 하고 있었다.

왜 여기만 자동화가 안 될까 궁금해서 최근 연구와 도구를 뒤졌다. 결론부터 말하면, 지금 자동화된 건 "무엇이 달라졌나"를 검출하는 데까지다. 스크린샷을 코드로 바꾸는 생성은 (적어도 웹에서) 484개 웹페이지 벤치마크에서 절반 가까이(49%) 사람이 "원본 대신 써도 된다"고 할 만큼 올라왔는데, 정작 "그 결과가 시안대로 나왔는가"를 자동으로 검증하는 쪽은 세 갈래 기술 모두 "의도에 맞나"라는 마지막 한 걸음을 못 넘는다.

병목은 '생성'이 아니라 '검증'에 있다

개발 자동화 루프를 한 장의 그림으로 그려 보면 막히는 지점이 어디인지 선명해진다.

다이어그램 설명. 이 그림이 보여주는 건 하나다 — 초록색으로 칠한 "코드를 생성"하고 "화면을 렌더링"하는 단계, 그리고 "픽셀 비교·유사도 지표·AI 판정" 같은 자동 검증 시도까지는 기계가 돌리는데, 빨간색 "사람이 눈으로 승인" 단계는 끝내 사람에게 되돌아온다. 자동 검증 경로가 하는 일은 "이전과 달라졌다"를 검출하는 데까지이고, "그 차이가 시안 의도에 맞는 변화인가 어긋난 실수인가"는 가리지 못해 결국 사람 승인으로 합류한다. 루프에서 자동화가 끊기는 지점이 정확히 이 마지막 승인 노드다. 흔한 오해는 "생성이 되면 검증도 곧 될 것"이라는 기대인데, 생성과 검증은 전혀 다른 능력이고 뒤에서 보듯 검증 쪽이 훨씬 뒤처져 있다.

스크린샷을 코드로 바꾸는 일은 — 적어도 웹에서는 — 검증보다 앞서 있다

먼저 잘 되는 쪽부터 보자. 스탠퍼드 등에서 낸 Design2Code라는 벤치마크(484개 실제 웹페이지를 스크린샷만 주고 HTML/CSS로 복원하게 시키는 시험)에서, GPT-4V가 만든 페이지는 시각적 외관과 콘텐츠 기준으로 49% 사례에서 "원본 대신 써도 된다"는 사람 평가를 받았다. 다만 두 가지를 못 박아 두자. 이건 웹 HTML/CSS 이야기이고, 49%는 연구 벤치마크의 수치이지 상용 제품의 합격선이 아니다. 뒤집어 말하면 절반 이상은 여전히 사람이 손봐야 한다는 뜻이다.

그래도 방향 자체는 개선되는 쪽이다. DCGen이라는 방법은 "분할 정복(divide and conquer)" 발상 — 큰 스크린샷을 통째로 코드로 바꾸려 하지 말고, 화면을 조각으로 나눠 조각별로 코드를 만든 뒤 다시 합치는 방식이다. 이렇게 하면 큰 이미지에서 시각적 유사도가 최대 15%, 코드 유사도가 8% 올라갔다(절대 점수가 아니라 개선 폭이다). 큰 화면일수록 한 번에 처리하면 세부가 뭉개지는데, 잘게 쪼개면 각 부분에 집중할 수 있다는 직관이 잘 들어맞은 결과다.

그런데 "이미 쓸 만하다"고 말하려면 여기서 브레이크를 밟아야 한다. 상용 도구(Locofy, Anima, Figma Dev Mode 등)를 실제로 써 본 평가는 대체로 한 방향으로 모인다 — 대략 75%까지 데려다주고, 나머지 20~40%는 사람이 손봐야 하며, 시니어가 손 안 대고 그대로 배포할 코드는 아니다. 즉 완제품이 아니라 초안·뼈대(scaffolding)를 뽑아 주는 도구다.

게다가 이 모든 근거는 전부 웹이다. 폰 네이티브(안드로이드 Compose·XML, iOS SwiftUI)로 넘어가면 벤치마크가 정적인 목업을 다시 그려 내는 수준에 머물고, 실제로 눌렀을 때의 동작(런타임)까지 검증하는 기준은 아직 없다. 자동차 계기판이나 가전 같은 기기·임베디드 UI에 이르면 스크린샷을 코드로 바꾸는 자동 변환 벤치마크가 사실상 없고, 있는 건 디자이너가 직접 화면을 그리는 시각 저작 도구(예: Qt Design Studio)뿐이다. 화면이 하드웨어 제약과 플랫폼 전용 위젯에 묶일수록, 자동 생성은 웹만큼 여물지 못했다.

그래서 이 절의 결론은 "생성이 완성됐다"가 아니라 "생성이 검증보다는 훨씬 앞서 있다"이다. 적어도 웹에서 시안을 코드로 옮기는 일은 초안이라도 내놓는데, 뒤에서 볼 검증 능력은 그마저도 못 한다. 진짜 문제는 그다음, 검증이다.

그럼 시안대로 됐는지 자동으로 검증하면 되지 않나?

당연히 나온 발상이고, 실제로 세 갈래 기술이 이걸 시도한다. 그런데 세 갈래 모두 같은 벽에서 멈춘다 — "무엇이 달라졌나"까지는 자동으로 잡는데, "그 차이가 의도 위반인가"는 못 가린다. 하나씩 보자.

검증 방식	무엇을 하나	어디서 막히나
픽셀·시각 비교 (visual regression)	승인된 스냅샷과 지금 화면을 픽셀/시각 요소 단위로 대조	"이전과 달라졌나"만 판정 — 새 시안 부합은 원리적으로 못 봄. 폰트·동적 콘텐츠로 오탐 잦음
유사도 지표 (Design2Code류)	시안 이미지와 구현 화면의 시각·구조 거리를 점수화	모델 순위엔 유효하나 "높은 점수 = 디자이너 합격"이 아님. 정답 레퍼런스가 있다고 가정
AI(VLM) 판정	시안과 구현을 함께 보여주고 "맞게 됐나"를 판단시킴	시안-구현 대조 전용 벤치가 사실상 없음. 일반 품질 판정조차 미세한 차이에선 우연 수준

표 설명. 세 방식을 "무엇을 하나 / 어디서 막히나" 두 축으로 나란히 놓은 것이다. 위에서부터 성숙도는 높지만 의도와 멀고, 아래로 갈수록 의도에 다가가려 하지만 신뢰도가 떨어진다. 공통점은 오른쪽 열 — 어느 것도 "이 차이가 디자인 의도에 맞는가"라는 최종 질문에 답하지 못한다. 아래에서 각 줄을 풀어 본다.

픽셀·시각 비교가 실무의 주류다. Percy, Applitools, BackstopJS, Playwright 스냅샷 같은 도구가 배포 전 화면을 이전에 "승인된" 스크린샷과 픽셀 단위로 비교해 달라진 곳을 표시한다. 여기서 오해하기 쉬운 지점이 있다 — 이때 기준(baseline)이 되는 건 디자이너의 시안이 아니라, 예전에 사람이 한 번 승인해 둔 "구현 화면의 스크린샷"이다. 그래서 이 방식이 판정하는 건 "시안대로인가"가 아니라 "지난번 승인한 구현에서 달라졌는가"다. "그럼 디자이너 시안을 기준으로 삼으면 되지 않나?" 싶지만, 시안은 Figma 같은 디자인 툴이 그린 그림이고 구현은 브라우저가 그린 화면이라 폰트·서브픽셀 배치가 렌더러마다 달라 픽셀이 맞아떨어지지 않는다 — 시안을 그대로 기준 삼아 픽셀 비교를 돌리면 거의 전부가 "다르다"로 뜬다. 시안을 기준으로 한 자동 대조는 오히려 아직 안 여문 어려운 문제라(뒤에 볼 Figma↔구현 diff 도구들이 이걸 노리지만 미성숙), 성숙한 픽셀 비교 도구들은 시안 대신 "이전 구현 스냅샷"을 기준으로 쓴다. 게다가 오탐이 잦다 — 가장 흔한 원인이 글자 렌더링인데, 사람 눈엔 같은 폰트여도 OS·GPU마다 안티에일리어싱(글자 가장자리를 부드럽게 처리하는 방식)이 달라 픽셀 비교기는 수천 픽셀이 바뀐 것으로 읽는다. 날짜·광고·애니메이션 같은 동적 콘텐츠도 매번 실패를 만든다. Applitools 같은 도구는 "사람 눈처럼 보는 Visual AI"로 이걸 줄였다고, 심지어 99.9999% 정확도라고 광고하지만, 이 수치는 자사 주장일 뿐 독립 검증은 확인되지 않고 실사용 후기에는 여전히 사소한 차이에 오탐이 나 수동 승인이 필요하다는 보고가 반복된다.

유사도 지표는 학술 쪽 접근이다. 앞서 나온 Design2Code는 시안과 구현의 거리를 자동으로 점수화한다 — 고수준 시각 유사도(CLIP)와 저수준 요소 매칭(블록·글자·위치·색)을 섞는다. 이 지표는 "어느 모델이 더 잘 만드나"라는 순위를 매기는 데는 쓸 만하다. 하지만 점수가 높다고 디자이너가 합격을 주는 건 아니다. 지표는 "정답 레퍼런스와 얼마나 가까운가"를 재는데, 애초에 새로 뽑은 시안에는 정답이 없고, 레퍼런스에서 벗어난 편차를 무조건 감점하지만 사람은 그 편차를 오히려 개선으로 볼 때도 있다. "거리"와 "합격"이 단조롭게 비례하지 않는다는 게 핵심 한계다.

AI(VLM) 판정이 가장 그럴듯한 기대주다. 시안과 구현 스크린샷을 멀티모달 모델(이미지와 텍스트를 함께 이해하는 모델)에게 함께 던지고 "이거 시안대로 됐어?"라고 물으면 되지 않겠나? 그런데 이걸 정면으로 시험한 전용 벤치마크가 사실상 없다. 있는 연구들은 대개 "시안 부합"이 아니라 일반적인 UI 품질 선호를 판정하는 것들인데, 그마저도 두 UI를 비교해 나은 쪽을 고르는 정확도가 53~60%로, 차이가 미세할 때는 동전 던지기(50%)까지 떨어진다. Figma 시안과 구현을 대조해 0~100 "충실도 점수"를 내주겠다는 상용 도구(uiMatch 등)도 등장했지만 검증 논문이 없고, 결국 "시안=기준"을 사람이 세팅한 뒤 비교하는 구조라 픽셀 비교의 한계를 그대로 물려받는다.

왜 하필 이 마지막 한 걸음이 안 넘어가나

세 방식을 관통하는 이유는 하나다. 자동화가 확립된 건 "정답 이미지와의 거리 측정"까지인데, "시안대로 됐나"는 거리 문제가 아니라 의도 해석 문제이기 때문이다. 어떤 픽셀 차이는 무시해야 한다 — 안티에일리어싱이나, 화면 폭에 맞춰 의도적으로 재배치되는 반응형 리플로우가 그렇다. 반대로 어떤 차이는 치명적이다 — 2px 밀린 정렬, 잘못 들어간 강조색이 그렇다. 이 둘을 가르려면 "무엇이 원래 디자인 의도였나"를 알아야 하는데, 픽셀 비교기는 의도가 없어서 못 가르고, 유사도 지표는 정답이 이미 있다고 가정하며, AI 판정자는 의도를 추론하려 들지만 정작 미세하고 결정적인 차이에서 신뢰도가 무너진다. 그래서 "이 차이가 의도 위반인가"라는 최종 판단에 검증된 근거가 없고, 사람 승인 게이트가 남는다.

정리 — 자동화는 '만드는 곳'이 아니라 '의도대로인지 판정하는 곳'에서 멈춘다

정리하면 이렇다. 디자인을 코드로 만드는 일은 적어도 웹에서는 검증보다 앞서 있다(연구 벤치 49% 대체 가능, 상용은 초안 수준, 기기 UI는 벤치마크조차 얇다). 그런데 그 결과가 시안대로 됐는지 자동으로 판정하는 일은 셋 다 "차이 검출"에서 멈추고 "의도 부합"을 못 넘는다. 자동화 루프가 막히는 건 내 손이 느려서가 아니라, 지금 도구들에 이 최종 판정을 맡기면 "달라졌다"는 알림만 잔뜩 받고 정작 "이게 맞나 틀리나"는 내가 다시 봐야 하기 때문이다.

그래서 나는 개인 개발 루프를 이렇게 조정했다. 생성·렌더링·차이 검출 같은 앞단은 AI와 자동 도구에 통째로 맡기되, 사람이 개입하는 지점(human-in-the-loop)을 "이 차이가 의도 위반인가"를 판정하는 노드 하나에만 남긴다. 모든 픽셀을 내가 훑으면 자동화의 의미가 없고, 아무것도 안 보면 오탐과 진짜 결함이 뒤섞인 채 배포된다. 자동 도구가 걸러 준 "달라진 곳"만 놓고 의도 부합 여부를 내가 판정하는 게, 지금으로선 시간을 가장 아끼는 배치다. 다음 글에서는 똑같은 함정이 성능·메모리 최적화 자동화에서 어떻게 반복되는지 — "6.86배 빨라졌다"는 숫자를 왜 그대로 믿으면 안 되는지 — 를 다룬다.

---

참고한 공개 자료:

• Design2Code: How Far Are We From Automating Front-End Engineering? (NAACL 2025) — https://salt-nlp.github.io/Design2Code/ , https://arxiv.org/abs/2403.03163
• DCGen: Automated Web Design-to-Code (divide-and-conquer) — https://arxiv.org/abs/2406.16386
• 상용 design-to-code 도구의 실무 한계 (약 75% + 20~40% 수작업, 시니어 배포 불가) — https://blog.vibecoder.me/figma-to-code-tools-workflows-compared
• Beyond NL2Code: 모바일 UI 코드 생성 벤치마크의 런타임 검증 부재 (survey) — https://arxiv.org/pdf/2606.15932
• Qt for Automotive HMI — 기기·임베디드 UI는 자동 변환이 아니라 시각 저작 도구가 주류 — https://www.qt.io/development/qt-in-automotive
• Visual regression testing의 원리와 한계 (픽셀 diff·flakiness) — https://www.boundev.ai/blog/ui-visual-regression-testing-pixel-perfect-automated-guide
• Applitools Visual AI / Eyes (99.9999% 자사 주장) 및 실사용 오탐 반박 — https://applitools.com/platform/eyes/ , https://aitestingguide.com/applitools-review/
• 멀티모달 LLM을 UI 판정자로 쓸 때의 한계 (일반 품질 선호, 미세 차이 우연 수준) — https://arxiv.org/html/2510.08783v1
• Figma 시안↔구현 자동 diff 상용 도구 (충실도 점수, 검증 논문 없음) — https://dev.to/kosaki08/uimatch-figma-to-implementation-visual-diff-with-playwright-and-ci-1819

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.