반응형 점검을 하러 들어갔다가 모달 구조를 통째로 다시 짜고 나왔다. SlateKR 개발 로그 #055에서 개발자 dh82680이 겪은 일이 정확히 그랬다. 처음 의도는 단순했다. 디자인 토큰 정리가 끝났으니 밀린 반응형 부채를 청산하자. 그런데 실물을 들여다보자 overflow 가드, 터치 타깃, 고정 높이 모달, 중첩 스크롤 컨테이너까지 줄줄이 엮였고, 결국 그룹 관리 모달의 액션 버튼 배치 자체를 다시 설계하는 것으로 세션이 끝났다.
핵심 전환점은 이 대목이다. 행마다 반복되던 버튼 세 세트(순서 ▲▼ / 이름변경 / 삭제)를, 선택된 그룹 하나에 대한 액션 헤더 한 세트로 우측 패널 상단에 모으는 마스터-디테일 패턴으로 바꿨다. 버튼이 N세트에서 1세트로 줄었고, 좌측 컬럼은 폭이 트였으며, "지금 어느 그룹을 편집 중인가"도 명확해졌다. 흥미로운 건 이 결정이 코드 분석으로 도달한 게 아니라는 점이다. 좁은 화면에서 겹침을 눈으로 직접 본 다음에야 전제 자체가 잘못됐음을 알아챘다.
이 경험이 던지는 질문은 하나다. AI 도구는 이 전환점을 짚어낼 수 있었을까? 코드 자동화 도구는 min-w-0 + truncate + shrink-0 패턴 적용이나 터치 타깃 패딩 확대 같은 '명백한 결함'은 빠르게 처리한다. 하지만 "버튼을 행 안에 둔다는 전제 자체를 버려야 한다"는 판단은 실물 검증과 맥락 이해 없이는 나오지 않는다. 반응형 점검이 단순 보정으로 끝나지 않고 구조 재설계로 이어진 것, 그게 이번 세션의 진짜 수확이었다.
비슷한 설계 철학이 전혀 다른 도메인에서도 확인된다. WordPress AI 챗봇 플러그인 Rapls AI Chatbot을 만든 개발자 rapls는 dev.to에 자신의 프로덕트 설계 결정을 공개했다. 가장 먼저 건드린 문제는 챗봇 품질이 아니었다. 설치 직후 "API 키를 발급하고 카드를 등록하라"는 단계에서 사용자가 이탈하는 퍼널의 협곡이었다. 인스톨 수와 실제 첫 대화 실행 수 사이의 갭이 문제였다.
해법은 기능 개선이 아니라 첫 성공 경험을 첫 약속 이전에 배치하는 것이었다. OpenRouter 무료 키를 활용한 온보딩 패널을 설정 화면 최상단에 놓고, 카드 없이도 실제 답변 한 건을 자신의 사이트에서 실행해볼 수 있게 했다. 무료 티어는 트라이얼이 아니라 핵심 기능을 온전히 경험할 수 있는 진짜 무료다. RAG 기반 자사 콘텐츠 검색, 지식베이스, 웹 검색 폴백이 전부 무료로 작동한다. '먼저 경험하게 하고, 그다음에 결정하게 한다'는 원칙이 퍼널 설계 전체를 관통했다.
두 사례가 공유하는 패턴이 있다. UI 결정의 품질은 코드 생성 단계가 아니라 그 이전의 설계 전제에서 결정된다는 것. 반응형 점검 사례에서는 "버튼을 행 안에 둔다"는 전제, 챗봇 사례에서는 "기능이 문제다"라는 전제가 각각 틀렸다. AI 도구가 아무리 빠르게 코드를 생성해도, 잘못된 전제 위에서는 최적화된 오답을 만들어낼 뿐이다.
여기서 세 번째 레이어가 등장한다. AI 코딩 에이전트용 문서 자동화 워크플로우 Truthmark 2.2.0은 dev.to에 공개된 문서에서 정확히 이 문제를 다룬다. AI 에이전트가 "docs를 업데이트하라"는 지시를 받으면, 제품 의도(product truth)와 구현 세부사항(engineering truth)을 구분하지 못한 채 혼합 문서를 만들어버린다는 것이다. Truthmark는 두 진실을 명시적으로 분리된 레인으로 운영한다. 제품 진실은 무엇이 사실이어야 하며 왜인가를 담고, 엔지니어링 진실은 저장소가 현재 그것을 어떻게 실현하는가를 담는다.
이 구분이 AI 에이전트에게 중요한 이유는 경계 때문이다. 경계 없이 "docs를 업데이트하라"고 하면 에이전트는 제품 의도를 구현 세부사항 요약으로 덮어쓰거나, 아무도 소유하지 않는 catch-all 문서를 생성하거나, 오래된 문서를 코드 확인 없이 업데이트한다. Truthmark 2.2.0이 에이전트에게 먼저 묻는 것은 "이게 product-lane 작업인가, engineering-lane 작업인가, 아니면 ambiguous인가"다. 모호하면 혼합 문서를 만들지 말고 라우팅을 멈추도록 설계됐다.
세 사례를 연결하면 하나의 워크플로우가 보인다. 실물 검증 → 전제 재점검 → AI 위임 범위 명확화. 반응형 점검에서 실물을 보기 전까지는 전제의 오류를 발견할 수 없었다. 챗봇 사례에서 퍼널 데이터를 보기 전까지는 진짜 병목을 알 수 없었다. Truthmark는 AI가 문서를 수정하기 전에 레인을 분류하도록 강제함으로써, 에이전트가 전제를 건드리기 전에 인간이 먼저 확인하는 구조를 만든다.
AI 도구를 UI 개선에 활용할 때 가장 흔한 실수는 도구에 너무 일찍 들어가는 것이다. overflow 가드나 터치 타깃 패딩처럼 패턴이 명확한 결함은 AI가 빠르게 처리한다. 하지만 "이 버튼이 여기 있어야 하는가"라는 질문은 실물을 보고, 데이터를 읽고, 사용자 여정을 따라가본 다음에야 제대로 물을 수 있다. 그 질문을 먼저 던지지 않으면 AI는 잘못된 위치의 버튼을 더 정교하게 만들어줄 뿐이다.
프론트엔드 개발자에게 남는 실천적 시사점은 이렇다. AI 도구를 프로토타이핑과 반복 구현에 적극적으로 쓰되, 설계 전제를 검증하는 단계는 반드시 개발자가 직접 쥐어야 한다. 반응형 점검처럼 작은 화면에서 직접 실물을 확인하는 것, 퍼널 데이터를 직접 읽는 것, 문서 레인을 분류하는 판단을 에이전트에게 넘기기 전에 명확히 정의하는 것. 이 단계들이 AI 워크플로우의 품질을 결정하는 실제 레버리지 포인트다. AI는 설계 이후를 빠르게 만들어주지만, 설계 이전을 대신해주지는 않는다.