AI가 코드를 짜주는 시대가 왔는데, 정작 그 코드가 만든 UI를 누가 검증하고 있을까? 이 질문이 불편하게 느껴진다면, 이미 그 문제 한가운데 있는 것이다. 최근 세 가지 흐름이 동시에 가시화되고 있다. AI Chat UI 설계의 프로덕션 기준이 높아지고 있고, Claude Code 같은 에이전트가 한계에 부딪혔을 때 개발자가 그 공백을 어떻게 채우느냐가 출력 품질을 결정하며, 마크다운으로 쓴 회귀 테스트가 AI 생성 코드의 검증 레이어로 진지하게 쓰이기 시작했다. 세 흐름은 결국 하나의 결론으로 수렴한다. AI가 UI를 만드는 시대일수록, 설계·검증·신뢰의 루프를 사람이 명확하게 쥐고 있어야 한다.
프로덕션 Chat UI: '데모'와 '제품' 사이의 간극
dev.to의 'AI Chat UI Best Practices' 포스트는 불편한 현실을 정직하게 짚는다. 텍스트 입력창 하나와 말풍선 목록으로 구성된 기본 골격은 첫 번째 ChatGPT 래퍼 붐에는 통했지만, 지금 기업 고객을 설득하고 사용자 신뢰를 쌓아야 하는 제품에는 턱없이 부족하다. 스트리밍 엣지 케이스, 인용 렌더링, 피드백 수집, 안전 신호, 세션 지속성, 접근성—이 중 어느 하나도 기본 메시지 목록에서 공짜로 따라오지 않는다.
특히 스트리밍 처리는 생각보다 까다롭다. LLM API는 불완전한 마크다운, 절반짜리 코드 블록, 잘린 단어를 스트리밍으로 뱉는다. 닫히지 않은 볼드 태그가 레이아웃을 망가뜨리지 않도록 파셜 토큰을 버퍼링해야 하고, 코드 블록은 닫는 펜스가 도착하기 전까지 렌더링을 미루거나 스트리밍 인디케이터를 따로 보여줘야 한다. 토큰 하나가 추가될 때마다 전체 메시지가 리레이아웃되는 레이아웃 스래시도 막아야 한다. 이것만 제대로 처리해도 '데모'와 '제품'의 체감 차이가 확연히 달라진다.
신뢰 메커니즘도 선택이 아니다. 법률·의료·기업 검색처럼 사용자가 AI 출력에 기반해 행동을 결정하는 도메인에서, 인용 UI는 가장 중요한 신뢰 장치다. 응답 텍스트 안에 번호가 붙은 인라인 인용을 두고, 클릭하면 소스 카드가 확장되는 패턴이 가장 효과적이다. 피드백 수집도 계층화가 필요하다. 엄지 위/아래의 저마찰 첫 레이어, 썸다운 시 펼쳐지는 카테고리 선택 두 번째 레이어, 그리고 선택적인 텍스트 입력 세 번째 레이어. 두 번 클릭 이상을 요구하면 대부분의 사용자는 그냥 지나친다.
Claude Code가 멈춘 그 4시간, 무엇을 해야 하는가
'Usage limit reached. Try again in 4h 59m.' 이 메시지를 본 순간 대부분의 개발자는 X를 열거나 커피를 들고 자리를 비운다. dev.to의 'Claude Code 한계 대응 전략' 포스트는 그 쿨다운 시간의 활용 방식이 다음 AI 세션의 품질을 거의 전적으로 결정한다고 말한다. 이건 단순한 생산성 팁이 아니라, AI와 인간의 역할 분담에 대한 근본적인 통찰이다.
가장 임팩트가 큰 활동은 다음 세션을 위한 입력 품질을 높이는 것이다. AI 출력이 나쁠 때 대부분의 개발자는 모델을 탓하지만, 문제는 거의 언제나 입력에 있다. '팀 초대 이메일 알림 추가해줘'라는 프롬프트는 AI가 이미 프로젝트에 통합된 Resend 헬퍼와 템플릿 시스템을 무시하고 Nodemailer를 새로 설치하는 사태로 이어진다. 반면 'src/lib/email/client.ts의 기존 sendEmail() 헬퍼를 사용하고, 새 이메일 라이브러리를 설치하지 말 것'이라는 네거티브 제약과 기존 코드 포인터를 명시한 프롬프트는 재작업 세션을 절반으로 줄인다.
CLAUDE.md 파일을 정제하는 것도 쿨다운 시간의 핵심 용도다. 이 파일은 Claude Code가 프로젝트 컨텍스트를 쌓아가는 네이티브 메커니즘으로, 빌드·테스트 커맨드, 아키텍처 개요, 핵심 패턴, 네이밍 컨벤션, 그리고 무엇을 하지 말아야 하는지를 담는다. AI가 세션마다 새로 학습하는 게 아니라 누적된 지식 베이스를 참조하게 만드는 것—이게 컨텍스트 주입의 본질이다. 처음으로 CLAUDE.md를 제대로 작성한 쿨다운 이후, 다음 세션에서 수정이 단 한 번도 필요 없었다는 경험담은 과장이 아니다.
AI가 쓴 코드, AI가 짜는 테스트—누가 검증하는가
'AI Regression Tests Written in Markdown, Not Code' 포스트는 한 가지 불편한 질문에서 시작한다. AI 에이전트가 프로덕션 코드를 점점 더 많이 작성하는데, 그 코드를 테스트하는 건 누구인가? 기존 E2E 테스트(Playwright, Cypress)의 문제는 AI가 더 빠르게 쓴다는 게 아니라, AI가 써도 여전히 취약하다는 점이다. page.locator('#sidebar-nav > ul > li:nth-child(3)')처럼 정확한 셀렉터에 의존하는 결정론적 테스트는 다른 에이전트(혹은 사람)가 그 컴포넌트를 건드리는 순간 깨진다. AI가 테스트를 빠르게 쓸수록, 깨지는 테스트도 빠르게 쌓인다.
이 팀이 선택한 해법은 마크다운으로 쓰는 회귀 테스트다. 셀렉터도 XPath도 없다. 사람 테스터처럼 행동하는 테스트—'Sign In 버튼을 찾아서 클릭하라', 'ID가 뭔지는 몰라도 된다'—를 평문 마크다운으로 작성하고, Vercel의 오픈소스 CLI agent-browser가 런타임에 접근성 트리를 읽어 요소를 찾아 실행한다. snapshot -i 명령이 반환하는 접근성 트리(@e1 heading "Sign In", @e2 textbox "Email")를 기반으로 AI 에이전트가 실제 사용자처럼 인터랙션한다. CSS 클래스명이 바뀌어도, DOM 구조가 재정렬되어도 테스트는 살아남는다. 구현이 아니라 경험을 테스트하기 때문이다.
더 흥미로운 건 워크플로우 통합이다. AI 에이전트가 새 기능을 빌드하는 같은 세션에서 해당 기능의 마크다운 회귀 테스트도 작성한다. 기능과 테스트가 같은 컨텍스트에서 동시에 나온다. 테스트는 P0, P1 우선순위로 분류되고 병렬로 실행되며, 결과는 다시 마크다운 파일에 기록된다. 기존 유닛 테스트가 '로직이 작동하는가'를, E2E 테스트가 '코드가 정확히 작성된 대로 작동하는가'를 묻는다면, 이 레이어는 '사용자가 기대하는 대로 앱이 작동하는가'를 묻는다.
루프의 제어권: 설계·검증·신뢰
세 흐름을 하나로 묶으면 구조가 보인다. AI Chat UI 설계 가이드는 사용자와 AI 사이의 신뢰 레이어를 어떻게 설계할 것인지를 다룬다. Claude Code 한계 대응 전략은 에이전트의 출력을 결정하는 설계 레이어—컨텍스트 주입, 작업 분해, 제약 명시—를 개발자가 직접 챙겨야 한다는 것을 말한다. 마크다운 회귀 테스트는 AI가 생성한 코드를 AI가 인간처럼 검증하는 루프를 닫는 방법론이다.
이 루프에서 개발자의 역할은 코드를 직접 타이핑하는 것에서 루프 자체를 설계하고 통제하는 것으로 이동하고 있다. AI가 빠르게 UI를 생성할수록, 그 UI가 사용자에게 실제로 신뢰를 주는지·컨텍스트를 올바르게 반영했는지·기대하는 대로 작동하는지를 확인하는 루프의 설계는 더 명확하게 사람의 몫이 된다. 툴이 자동화할 수 있는 건 실행이지, 루프의 설계 자체가 아니다. 그 경계선을 어디에 그을지 아는 것—그게 지금 프론트엔드 개발자에게 필요한 핵심 역량이다.