AI가 UI를 뽑아주는 시대가 됐다. 프롬프트 몇 줄이면 Hero 섹션, 카드 그리드, CTA 버튼까지 순식간에 나온다. 그런데 요즘 AI가 만든 랜딩 페이지들을 보면 묘하게 비슷하다는 느낌을 받은 적 없는가? Hero → 기능 카드 3개 → CTA → Footer. 서비스의 성격이 달라도, 브랜드 색이 달라도, 골격만큼은 수렴한다. 이건 우연이 아니다. LLM이 학습 데이터에서 가장 많이 본 패턴으로 회귀하는 자연스러운 결과다.
문제는 이 '균질화'가 비즈니스에 실제로 손해를 끼친다는 데 있다. 사용자 눈에 모든 서비스가 비슷해 보이면, 기억에 남는 경험이 없어진다. 결국 전환율도, 재방문율도, 브랜드 인지도도 흐릿해진다. AI가 UI를 '생성'해주는 건 확실히 편리하지만, 그 생성물이 좋은 경험을 담보하지는 않는다. 그래서 지금 필요한 건 생성 도구 자체가 아니라, 생성 전에 설계하고 생성 후에 검증하는 프로토콜이다.
AI 균질화를 막는 설계: Hallmark의 접근
최근 공개된 디자인 에이전트 프레임워크 Hallmark(velog.io의 소개 글 기준)는 이 문제를 정면으로 겨냥한다. 흔히 생각하는 것처럼 "더 화려하게 만들어줘"라는 프롬프트를 정교하게 다듬는 방식이 아니다. 오히려 AI가 선택지를 제멋대로 고르지 못하도록 선택 구조 자체를 설계하는 방향을 택한다.
Hallmark의 핵심 개념은 Macrostructure와 Theme의 분리다. Theme은 색상·타이포그래피·표면 인상을 담당한다. 반면 Macrostructure는 페이지 자체의 형태, 즉 콘텐츠가 공간에서 어떻게 조직되는지를 결정한다. 예를 들어 'Bento Grid'는 크기가 다른 블록을 불규칙하게 배치하고, 'Manifesto'는 큰 선언과 타이포그래피가 페이지를 주도하며, 'Workbench'는 실제 제품 화면과 사용 흐름을 중심으로 구성된다. 현재 21가지 Macrostructure가 정의되어 있고, Theme도 21가지다.
이 둘을 분리한 이유가 중요하다. Hallmark가 강조하는 것은 색상을 바꾸기 전에 구조부터 달라져야 한다는 원칙이다. 테마만 바꾸면 표면적으로는 달라 보이지만 골격은 같다. 반면 Macrostructure를 먼저 다르게 선택하면, 같은 콘텐츠도 전혀 다른 경험으로 읽힌다. 내부적으로는 구조를 6개 축(section heading 위치, 본문 구성, section divider, button 표현, image 처리, reveal 방식)으로 더 세분화해서, 문서상 조합 가능한 구조적 fingerprint는 이론상 42,000개에 달한다.
하지만 Hallmark는 이 42,000가지를 AI에게 자유롭게 조합하라고 넘기지 않는다. 대신 먼저 21개의 검증된 Macrostructure 중 하나를 고르게 하고, 필요한 경우에만 일부 축을 수정한다. 자유도를 무한히 주는 것보다, 충분히 다른 선택지를 명시적으로 만들고 그중 하나를 먼저 고르게 하는 방식이 LLM의 기본 패턴 회귀를 막기 훨씬 쉽다는 판단이다. 이건 프롬프트 엔지니어링이라기보다 일종의 의사결정 아키텍처다.
다양성을 유지하는 메모리 구조
Hallmark가 특히 재사용 가치가 높다고 평가받는 아이디어 중 하나는 이전 선택을 상태로 저장하고, 다음 생성의 제약 조건으로 활용하는 방식이다. 프로젝트의 CSS에는 선택한 Macrostructure를 comment stamp로 남기고, .hallmark/log.json에는 이전 생성 결과의 구조·테마·enrichment 정보를 기록한다. 다음 생성 시에는 이 최근 기록을 읽는다.
예를 들어 직전 결과가 Bento Grid였다면, 다음에도 무심코 Bento Grid를 선택하지 못하게 막는다. 최근 여러 출력에서 같은 구조가 과도하게 등장했다면 다른 계열을 우선한다. "이번엔 이전과 다르게 만들어줘"라는 자연어 요청을 반복하는 대신, 이전 디자인 선택을 상태로 저장하고 다음 선택의 제약 조건으로 사용하는 것이다. 이 원리는 디자인에만 국한되지 않는다. AI 코드 생성에서도 이전 선택을 기록하고 다음 탐색 공간에서 제외하는 방식으로 확장할 수 있다.
생성 이후가 더 중요한 이유: Slop Test
Hallmark의 또 다른 축은 생성 후 검증이다. slop-test.md와 SKILL.md의 실행 흐름은 현재 58개 gate를 기준으로 한다. 단순한 취향 검사가 아니라 실제 구현 품질 항목도 상당수 포함되어 있다. 예컨대 transition: all 사용 여부처럼 성능에 직접 영향을 미치는 패턴을 잡아낸다.
58개 gate를 적용하기 전에 별도의 self-critique 단계도 있다. Philosophy, Hierarchy, Execution, Specificity, Restraint, Variety, 여섯 축을 1~5점으로 평가하고, 하나라도 3점 미만이면 먼저 수정한다. 이 흐름이 말해주는 것은 분명하다. Hallmark는 디자인을 생성하는 prompt library가 아니라, 생성 전 선택 규칙과 생성 후 lint 규칙을 묶은 디자인 프로토콜이다. 생성이 절반이라면, 검증이 나머지 절반이다.
프론트엔드 개발자가 설계해야 할 '좋은 거짓말'
AI가 UI 구조를 뽑아주더라도, 그 UI가 실제로 사용자에게 좋은 경험을 주는지는 별개의 문제다. 여기서 프론트엔드 개발자 특유의 역할이 등장한다. velog의 한 글에서 표현을 빌리자면, 프론트엔드 개발자는 좋은 거짓말을 해야 한다.
실제 서버 응답 속도를 0.1초 줄이는 데 엄청난 공수를 쏟아도, 그 0.1초 동안 화면이 하얗게 멈춰 있으면 사용자는 여전히 "왜 이렇게 느리지?"라고 느낀다. 최종 판단 주체는 기계가 아니라 사람이기 때문이다. 인간의 뇌는 100ms 이내의 반응은 즉각적으로 인지하고, 1초가 넘어가면 집중의 흐름이 끊긴다. 숫자로 찍히는 로딩 시간보다 사용자가 느끼는 심리적 대기 시간이 실제 만족도를 결정한다.
이를 해결하는 두 가지 대표 기법이 스켈레톤 스크린과 낙관적 UI(Optimistic UI)다. 스켈레톤 스크린은 데이터가 도착하기 전에 회색 박스로 화면의 뼈대를 먼저 보여준다. 막연히 빙글빙글 도는 스피너보다 "콘텐츠가 곧 채워진다"는 구조적 신호를 주기 때문에 심리적 불안감을 줄인다. 낙관적 UI는 서버 확인을 받기 전에 화면부터 먼저 바꾸는 방식이다. 인스타그램에서 하트를 누르면 서버 응답 전에 이미 하트가 채워지는 것이 그 예다.
물론 낙관적 UI는 안전장치 없이 남발하면 위험하다. 네트워크 오류나 서버 실패 시 이전 상태로 정확히 롤백하는 로직(React Query의 onMutate·onError 활용 등)이 반드시 함께 설계되어야 한다. 금액 결제나 데이터 삭제처럼 되돌리기 어려운 작업에는 적용하지 않는 것이 원칙이다. 좋은 거짓말이 좋은 경험이 되려면, 뒤에서 철저한 안전장치가 받쳐줘야 한다.
AI에게 레이아웃을 맡기기 전에 프레임워크가 먼저 잠가야 할 것들
문서와 슬라이드 자동화 프레임워크인 open-doc의 설계도 같은 맥락에서 읽힌다. 코딩 에이전트는 콘텐츠를 잘 쓴다. 하지만 레이아웃은 창의적 여지가 없는 영역이다. A4 여백, 페이지 번호, 줄 바꿈 위치는 틀리거나 맞거나 둘 중 하나다. open-doc의 접근은 프레임워크가 틀리면 안 되는 부분을 먼저 잠그고, 에이전트는 잘하는 것(콘텐츠)만 담당하게 한다는 분업이다.
특히 흥미로운 지점은 "매뉴얼은 대화창 프롬프트가 아니라 레포지토리 안에 있어야 한다"는 원칙이다. 프롬프트에 붙여넣는 사용 가이드는 대화가 길어지면 잘리고, 업데이트되지 않으며, 다른 팀원이나 다른 에이전트가 쓸 때마다 다시 붙여야 한다. 반면 레포 안의 AGENTS.md나 .agents/skills/ 하위 Markdown 파일은 버전 관리되고, 프로젝트에 귀속되며, PR 리뷰 대상이 된다. Hallmark의 design.md와 .hallmark/log.json 전략도 같은 철학이다.
설계의 책임은 여전히 사람에게 있다
세 가지 도구와 기법을 함께 놓고 보면 하나의 패턴이 보인다. AI가 생성 속도를 높일수록, 생성 전 선택 구조와 생성 후 검증 구조를 설계하는 일은 오롯이 사람의 몫으로 남는다. Hallmark가 Macrostructure 선택 제약과 58개 slop gate를 사람이 정의하듯, 스켈레톤과 낙관적 UI의 적용 범위와 롤백 로직을 결정하는 것도 사람이 해야 한다. open-doc이 A4 치수를 프레임워크에 고정하듯, 에이전트에게 무엇을 허용하고 무엇을 잠글지를 먼저 결정하는 것도 사람이다.
AI가 UI를 뽑아주는 것은 이미 기정사실이다. 지금 필요한 질문은 "AI가 생성한 UI가 사용자에게 진짜 좋은 경험인가"이고, 그 답을 설계하는 일은 아직 자동화되지 않았다. 생성은 빨라졌지만, 어떤 구조를 선택하고, 어떤 감각으로 연출하고, 어떤 기준으로 검증할지—그 판단은 여전히 직접 해야 한다.