우리가 '인터페이스'라고 부르는 것의 정의가 조용히 흔들리고 있다. 지난 수십 년간 프론트엔드 개발자의 역할은 명확했다—사람이 클릭할 버튼을 만들고, 폼을 설계하고, 시각적 피드백을 다듬는 것. 그런데 AI 에이전트가 웹을 탐색하고, 터미널이 개발의 중심으로 귀환하고, 색상 하나가 접근성과 브랜드 정체성 사이에서 충돌하는 지금, 그 역할의 경계가 빠르게 재편되고 있다.
1. 접근성은 타협이 아니다—색상 도구가 증명한 UX 설계의 본질
"WCAG를 통과했습니다. 그런데 이건 우리 브랜드 색이 아닌데요?" 디자이너라면 누구나 한 번쯤 겪어본 순간이다. 대부분의 접근성 도구는 명도 대비 수치만 맞추면 임무를 완수했다고 판단한다. 브랜드 팔레트가 망가졌든 말든. dev.to에 공개된 Smart Color Contrast Checker 사례는 이 문제를 정면으로 건드린다. 단순히 통과/실패를 알려주는 것이 아니라, 원본 색상과 시각적으로 가장 가까운 WCAG 준수 대안을 제안하는 방식이다.
흥미로운 건 구현 전략이다. 알고리즘 모드는 API 키 없이 브라우저에서 완전히 실행되고, AI 모드는 OpenAI를 통해 브랜드 맥락을 반영한 제안을 생성한다—단, 모든 제안은 사용자에게 노출되기 전 검증을 거친다. Figma 플러그인까지 갖춰 디자이너의 실제 워크플로우 안으로 들어간다는 점도 중요하다. 이건 단순한 도구 이야기가 아니다. 접근성을 브랜드와 충돌하는 규제가 아닌, 함께 최적화할 수 있는 설계 파라미터로 바라보는 관점의 전환이다. AI를 활용했지만, 최종 검증 루프는 사람이 쥐고 있다는 구조도 눈여겨볼 만하다.
2. 터미널의 귀환—가장 오래된 인터페이스가 AI의 기본값이 되다
dev.to에 게재된 "AI Didn't Kill the Terminal. It Made It the Default Interface"는 현재 개발 생태계에서 가장 선명하게 보이는 역설을 포착한다. 수십 년간 GUI로 대체하려 했던 터미널이, AI 시대에 오히려 기본 인터페이스로 복귀하고 있다는 것. Charmbracelet Crush, OpenCode(SST), Claude Code CLI—주요 AI 코딩 도구들이 하나같이 CLI·TUI 우선 경험을 선택하고 있다.
이유는 구조적이다. AI 대화는 본질적으로 텍스트 기반이고, 터미널도 텍스트 기반이다. 두 패러다임은 자연스럽게 수렴한다. Nushell이 모든 출력을 구조화된 데이터로 처리하는 방식, CRT 스캔라인과 형광 글로우가 트렌드 디자인 보고서에 등장하는 현상—이건 단순한 복고 감성이 아니다. 텍스트가 다시 인터페이스의 주언어가 되는 아키텍처 전환에 대한 감각적 반응이다. 여기에 MCP Apps가 더해지면서 상황은 더 복잡해진다. 터미널 대화 안에 Figma, Slack, Canva 같은 서비스의 인터랙티브 HTML UI가 임베드되는 구조—터미널과 GUI의 경계 자체가 용해되고 있다.
3. WebMCP—AI 에이전트를 위한 세 번째 인터페이스 계층
가장 주목해야 할 흐름은 W3C Web ML 커뮤니티 그룹이 2026년 2월 공개한 WebMCP 드래프트다(dev.to 기고 "AI Agents Don't Need to Touch the UI" 참조). AI 에이전트가 웹과 상호작용하는 방식은 지금까지 두 가지였다. 화면의 클릭과 키 입력을 시뮬레이션하는 UI 자동화(느리고 깨지기 쉽다), 그리고 백엔드 MCP 서버나 OpenAPI를 통한 통합(서버 구현 비용이 크다). WebMCP는 세 번째 경로를 제안한다.
핵심 아이디어는 간단하다. 웹 페이지가 JavaScript 함수를 '도구'로 등록하면, 브라우저 안의 AI 에이전트가 그 도구를 직접 호출한다. navigator.modelContext.provideContext()로 도구를 등록하고, 에이전트가 발견·실행·결과 수신까지 처리한다. 기존 프론트엔드 코드를 그대로 재사용할 수 있고, 별도의 서버가 필요 없다. 구매나 메시지 전송 같은 파괴적 액션 전에는 requestUserInteraction()이 사용자 확인을 요청하는 human-in-the-loop 설계도 내장되어 있다.
아직 드래프트 단계고, 보안 명세는 TODO 상태이며, Firefox와 Safari는 미지원이다. Chrome Early Preview Program으로만 체험 가능하다. 하지만 이 미완성이 갖는 의미를 과소평가해선 안 된다. Microsoft와 Google의 엔지니어들이 공동으로 설계하고 있고, MCP의 tool 포맷과 정렬되어 있다는 점은 생태계 연결 가능성을 시사한다.
시사점: 프론트엔드 개발자가 설계해야 할 새로운 계층
세 가지 흐름을 한 프레임에 놓으면 공통된 질문이 떠오른다. "이 인터페이스는 사람만을 위한 것인가?" 색상 접근성 도구는 사람과 AI가 협력해 더 나은 디자인 결정을 내리는 방식을 보여준다. 터미널의 귀환은 AI 에이전트와 개발자가 같은 텍스트 공간에서 작업하는 미래를 가리킨다. WebMCP는 웹사이트가 사람뿐 아니라 AI 에이전트를 위한 공식 진입점을 제공해야 하는 시대를 예고한다.
프론트엔드 개발자에게 이건 추상적인 미래 이야기가 아니다. 비즈니스 로직을 UI에서도, AI 에이전트에서도 호출 가능하도록 설계하는 것이 실질적인 경쟁력이 될 것이다. 도구별 권한과 감사 로그 설계는 새로운 프론트엔드 아키텍처 책임 영역이 된다. 그리고 접근성은 규제 통과가 아닌, 다양한 사용자와 에이전트 모두가 서비스를 제대로 이용할 수 있게 하는 보편적 설계 원칙으로 다시 정의된다.
전망: GUI, TUI, WebMCP—다층화되는 인터페이스의 미래
GUI가 사라지는 것이 아니다. 레이어가 늘어나는 것이다. 사람을 위한 시각적 UI, AI 에이전트를 위한 도구 레이어(WebMCP), 그리고 둘이 공유하는 텍스트 공간(터미널). 이 세 계층을 동시에 설계할 수 있는 개발자가 다음 시대의 진짜 프론트엔드 엔지니어가 될 것이다. WebMCP가 드래프트를 벗어나 표준화되는 시점, 그리고 AI 에이전트가 웹사이트의 공식 도구를 호출하는 것이 당연해지는 시점—그 변곡점은 생각보다 가까이 와 있다.