'의도대로 만들어졌나'를 자동으로 검증할 수 있을까 — 학계가 디자인 의도를 직접 판정하지 않고 '우회'하는 이유

앞 글에서 "AI가 시안대로 UI를 짜도, 맞게 짰는지 자동으로 검증하는 데서 개발 루프가 막힌다"는 이야기를 했다. 그러면 오픈 커뮤니티와 학계는 이 문제를 손 놓고 있을까 싶어 최근 2~3년 연구를 훑었다. 결론부터 말하면, 손 놓기는커녕 여러 갈래로 활발히 파고 있었다. 그런데 그 방식들을 늘어놓고 보니 공통점이 하나 도드라졌다.

아무도 "의도(design intent)" 자체를 정면으로 판정하지 못한다. 대신 다들 의도를 검증 가능한 다른 것으로 바꿔치기해서 우회한다. 그리고 그 우회를 안 하고 AI에게 곧장 "이거 시안 의도대로 됐어?"라고 물으면, 어느 쪽이 나은지 순위는 대충 맞혀도 "이 정도면 합격이냐"라는 절대 판정에서 무너진다 — 인간 전문가와 겨우 70%쯤 일치하고, 5점 척도에서 정확히 같은 점수를 주는 비율은 3분의 1(32~34%)에 그친다.

아무도 '의도'를 직접 재지 않는다 — 그 대신 우회한다

먼저 지형을 한 장으로 그려 보자.

다이어그램 설명. "디자이너가 원한 것"이라는 한 덩어리에서 두 갈래가 뻗는다. 초록색 갈래는 의도를 곧장 재는 대신 기계가 확인할 수 있는 무언가로 바꿔 검증한다 — 색·간격 같은 "디자인 토큰"이 규칙대로 쓰였는지(형식 규칙), 버튼을 누르면 제대로 동작하는지(기능 명세). 이 둘은 실제로 잘 돌아간다. 빨간색 갈래는 AI에게 시안과 구현을 보여주고 "의도대로 됐냐"를 직접 물어보는 정공법인데, 여기가 무너지는 지점이다. 핵심은 초록 갈래가 성공하는 이유가 곧 그 한계라는 것 — 의도를 검증 가능한 프록시로 좁혔기 때문에 자동화됐고, 좁힌 만큼 "의미로서의 의도"는 검증 범위 밖으로 빠진다.

우회 전략 — 의도를 '검증 가능한 것'으로 바꿔치기

가장 실효적인 자동화는 의도를 형식 규칙으로 내려놓는 쪽이다. design linter(디자인 시스템 규칙을 아는 코드 검사기)가 대표적이다. 예컨대 Atlassian은 자사 디자인 시스템에 "디자인 토큰을 써라"는 규칙을 ESLint 플러그인으로 상용 제공한다 — 코드에 색상값을 직접 박으면(#0052CC 같은 하드코딩) 경고를 띄우고, 승인된 토큰(color.background.brand)을 쓰도록 강제한다. 색·간격·타이포의 일관성을 코드 단계에서 자동으로 지키는 것이다. 하지만 이건 "이 파란색이 디자이너가 의도한 그 파란색인가"가 아니라 "약속된 토큰 목록에서 골랐는가"만 본다. 형식 준수이지 의미 판정이 아니다.

다른 갈래는 의도를 기능 명세로 내려놓는다. UI를 픽셀 이미지가 아니라 "이런 상호작용을 해야 한다"는 검사 가능한 모델로 환원하는 계보다(모델 기반 테스트, 속성 기반 UI 테스트). 로그인·검색 같은 반복되는 UI 패턴을 형식화해 여러 구현 위에서 테스트를 자동 생성하는 식이다. 이쪽은 성숙도가 꽤 높다 — 한 최신 벤치마크(FrontendBench)에서 생성된 UI에 대해 자동 스크립트로 동작을 검증한 결과가 사람 판정과 90.54% 일치했다. 다만 이 90%가 검증하는 건 "버튼이 눌리고 폼이 제출되는가"라는 동작이지, "이 화면이 디자이너가 그린 그 느낌대로인가"라는 시각적 의도가 아니다.

두 우회 모두 자동화에 성공했다. 그리고 성공한 정확한 이유가, 판정 대상을 의도의 대리물(토큰 규칙, 기능 동작)로 좁혔기 때문이다.

정면 돌파 — AI에게 직접 "의도대로 됐냐"를 물으면

그렇다면 좁히지 말고, 멀티모달 AI에게 시안과 구현을 함께 던져 "이거 의도대로 됐어?"를 직접 물으면 어떨까? 2025~2026년에 이걸 정면으로 시험한 연구들이 나왔고, 결과는 일관되게 "아직 아니다"였다.

웹 개발 결과물의 품질을 AI가 판정하게 한 WebDevJudge에서, 최상위 판정자(GPT-4.1)조차 인간 전문가와 70.34% 일치에 그쳤다. 인간끼리의 일치도(84.56%)에는 15%p 넘게 못 미쳤고, 어떤 모델도 70% 언저리를 넘지 못하고 정체했다. 실패 양상이 특히 시사적이다 — AI 판정자는 글자 그대로(literal) 해석에 매여, 사람이라면 "다른 방식으로 구현했지만 의도는 충족했다"고 인정할 유효한 대안을 오탐으로 기각했다. 의도란 "이 목적을 이루면 된다"는 것인데, AI는 "정확히 이 모양이어야 한다"로 읽는다.

더 근본적인 한계는 순위는 매겨도 점수는 못 매긴다는 것이다. 한 연구(제목 그대로 "VLM 심판은 순위는 매길 수 있어도 점수는 못 매긴다")는 최신 VLM 판정자가 5점 척도에서 사람과 정확히 같은 점수를 준 비율이 32~34%에 불과하고, 예측의 4분의 1 이상이 2점 넘게 빗나갔음을 정량화했다. "A가 B보다 낫다"는 상대 순서는 그럭저럭 맞히지만, "이건 몇 점이다 / 합격이다"라는 절대 판정은 신뢰할 수 없다는 뜻이다. 그런데 개발 루프에서 검증 게이트가 필요로 하는 건 정확히 그 절대 판정 — "이거 내보내도 되나 안 되나"다. UI의 지각적 품질을 예측하게 한 다른 연구에서도, 두 화면의 차이가 클 때만 90% 넘게 맞히고 미세할 때는 동전 던지기 수준으로 떨어졌다.

그나마 가장 앞선 시도는 열린 질문("좋아?") 대신 명시적인 디자인 가이드라인을 입력으로 주고, 위반 지점을 화면의 특정 영역(bounding box)에 짚어 지적하게 하는 방식이다. 전문가들이 이 방식의 지적을 기본 모델보다 대체로 선호했다는 결과가 있지만, 그마저도 한 지표에서 사람과의 격차를 절반만 좁혔다. 방향은 맞아도 아직 절반이다.

전문가들의 판정 — 최신 벤치마크가 'AI 심판'을 빼버렸다

이 분야가 지금 어디쯤인지를 가장 솔직하게 보여주는 건, 2026년에 나온 spec-to-app 벤치마크 VISTA의 설계 결정이다. 이 벤치마크는 "명세대로 앱을 만들었는가"를 평가하는데, AI 심판(LLM-as-judge)을 불안정하다는 이유로 의도적으로 배제하고, 대신 화면의 DOM 요소를 좌표에 맞춰 대조하는 결정론적 방식으로 되돌아갔다. 의도 판정을 AI에게 맡기는 걸 만든 사람들이 포기한 것이다.

그 벤치마크가 실증한 사실이 결정적이다 — 시각적 충실도와 기능적 정확도가 서로 따로 논다. 논문 기준 한 최상위 모델은 시각 유사도(CLIP)가 0.853으로 가장 높았는데 실제 동작 정확도는 0.283으로 가장 낮았고, 다른 모델은 정반대였다. "겉보기가 시안과 비슷하다"와 "의도한 대로 작동한다"가 같이 가지 않는다는 것 — 표면 유사도로는 의도 이행을 추적할 수 없다는 걸 수치로 못박았다. 비슷하게, 생성된 UI가 명세 의도에 부합하는지를 판정한 다른 연구(SpecifyUI)는 그 "의도 부합" 판정을 자동 지표가 아니라 전문 디자이너 16명의 사람 평가로 측정했다. 정면 판정이 필요한 순간, 결국 사람에게 돌아온다.

정리 — 의도는 아직 '자동으로 판정할 대상'이 아니라 '사람에게 남길 대상'이다

정리하면, 학계·커뮤니티는 이 문제를 활발히 다루되 하나같이 같은 선택을 했다. 의도를 검증 가능한 프록시로 환원할 수 있는 만큼 환원해 자동화하고(토큰 규칙 준수, 기능 동작 정확도), 환원되지 않는 "의미로서의 의도 부합"은 사람 판정에 남겼다. AI에게 그 마지막 판정을 직접 맡기려는 시도는 순위는 매겨도 점수는 못 매기는 벽에 반복해서 부딪혔고, 가장 최신의 벤치마크는 아예 AI 심판을 빼버렸다.

개인 개발 루프에 적용하는 방법도 여기서 나온다. "의도대로 됐나"를 통째로 자동화하려 들지 말고, 프록시로 내려놓을 수 있는 건 최대한 내려놓는다 — 색·간격은 디자인 토큰 린트로 코드에서 강제하고, 동작은 상호작용 테스트로 잡는다. 그렇게 기계가 확실히 지킬 수 있는 층을 넓히고 나면, 남는 건 "이 화면이 정말 의도한 느낌인가"라는 얇은 의미 판정뿐이고, 사람의 시간을 딱 거기에만 쓰면 된다. 자동화가 못 넘는 선이 어디인지 정확히 알면, 그 선까지는 기계에게 맡기고 그 너머만 내가 본다. 앞선 UI 검증 글도, 성능 최적화 글도 결국 같은 결론에 닿는다 — 자동화의 가치는 "무엇을 맡길 수 있는가"가 아니라 "무엇을 맡기면 안 되는가"를 아는 데서 나온다.

---

참고한 공개 자료:

• design-lint — 디자인 토큰 준수 정적 검사기 (오픈소스) — https://github.com/bylapidist/design-lint
• Atlassian ESLint 플러그인 — ensure-design-token-usage 규칙 — https://atlassian.design/components/eslint-plugin-design-system/ensure-design-token-usage/
• Pattern Based GUI Testing (PBGT), UI Test Patterns 형식화 (STVR 2017) — https://onlinelibrary.wiley.com/doi/abs/10.1002/stvr.1629
• UI-design driven model-based testing (Bowen & Reeves, 2013) — https://link.springer.com/article/10.1007/s11334-013-0199-6
• WebDevJudge — 웹 개발 결과 판정에서 AI가 인간 전문가에 못 미침 (2025) — https://arxiv.org/html/2510.18560
• VLM Judges Can Rank but Cannot Score — 순위-점수 격차 (2026) — https://arxiv.org/html/2604.25235v1
• MLLM as a UI Judge — 지각적 품질 판정의 한계 (2025) — https://arxiv.org/html/2510.08783v1
• Visual Prompting with Iterative Refinement for Design Critique Generation (UICrit) — https://arxiv.org/pdf/2412.16829
• VISTA — spec-to-app 벤치마크, LLM-as-judge 배제·시각/기능 발산 실증 (2026) — https://arxiv.org/html/2605.26144
• SpecifyUI — 의도 부합 판정을 전문 디자이너 사람 평가로 측정 — https://arxiv.org/abs/2509.07334

---

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