두 개의 신호, 하나의 방향
최근 두 가지 흐름이 거의 동시에 주목받고 있다. 하나는 GoodBarber가 공개한 에이전트 기반 앱 운영 방식—사용자가 화면을 클릭하는 대신 "6시에 푸시 보내줘"라고 말하면 AI가 실제 앱에서 직접 실행한다. 다른 하나는 189,000개 GitHub 스타를 받은 단 하나의 파일, CLAUDE.md—Andrej Karpathy가 관찰한 AI 코딩 실패 패턴을 70줄 미만의 원칙으로 압축한 가이드다. 언뜻 무관해 보이지만, 이 둘은 같은 질문을 향해 수렴한다. AI가 일하는 방식에 맞게 인터페이스와 개발 프로세스를 어떻게 재설계할 것인가.
인터페이스의 방향이 뒤집혔다
지금까지 모든 인터페이스는 사용자가 '올라가는' 구조였다. 메뉴를 외우고, 대시보드 동선을 익히고, 설정 이름을 기억해야 했다. 아무리 잘 설계된 백오피스라도 결국 학습 비용이 존재했다. dev.to의 GoodBarber 아티클이 지적하듯, "도구가 문법을 정하고, 사용자가 거기에 맞췄다."
에이전트 기반 인터페이스는 이 방향을 뒤집는다. 사용자는 의도를 말하고, AI가 그것을 앱의 실제 동작으로 번역한다. 이것이 단순한 UX 편의 개선이 아닌 이유는, 지금까지 백오피스를 끝내 익히지 못했던 사람—시간이 없거나, 디지털 도구에 익숙하지 않거나—이 이제 앱을 온전히 운영할 수 있게 되기 때문이다. 접근성의 의미가 시각적 가독성을 넘어 '조작 가능성' 자체로 확장된다.
인터페이스의 단위가 픽셀에서 동사로
이 변화가 프론트엔드 개발자에게 던지는 시사점은 생각보다 깊다. 에이전트는 클릭하지 않는다. 에이전트는 호출한다. 따라서 에이전트가 다룰 수 있는 앱을 만들기 위해 필요한 것은 더 예쁜 화면이 아니라, 앱이 할 수 있는 일을 명확히 정의된 액션으로 노출하는 것이다—publish, update, schedule, notify.
GoodBarber가 채택한 MCP(Model Context Protocol) 표준은 이 액션들을 에이전트가 범용적으로 이해할 수 있게 만드는 레이어다. 흥미로운 점은, 액션을 노출하는 것 자체보다 액션을 잘 노출하는 것이 훨씬 어렵다는 데 있다. "뉴스 섹션에 기사 발행하고 독자에게 푸시 보내줘"라는 요청을 에이전트가 올바른 순서로 처리하려면, 각 액션의 이름·범위·파라미터가 기계가 읽을 수 있을 만큼 정밀하게 정의되어야 한다. 모호하거나 유사한 액션이 두 개 존재하면, 에이전트는 기사가 게시되기 전에 푸시를 먼저 보내버릴 수 있다.
결국 인터페이스 설계의 핵심 단위가 픽셀에서 동사로 이동하고 있다. 우리는 인간이 탐색할 화면만 설계하는 것이 아니라, 에이전트가 조합할 능력(capability)을 설계해야 한다.
AI가 코드를 짤 때 반복하는 실패, 70줄로 막는다
인터페이스가 재설계되는 동안, 개발 워크플로우 쪽에서도 조용하지만 중요한 움직임이 있다. Karpathy가 X에 올린 관찰—AI 모델이 코드를 작성할 때 반복하는 실패 패턴—을 multica-ai(Jiayuan Zhang)가 CLAUDE.md 하나로 압축한 결과물이 189,000 스타를 받았다.
파일의 핵심은 4가지 원칙이다. 코딩 전에 먼저 생각하기(가정을 드러내고, 불명확하면 질문하기), 단순함 우선(필요한 코드만 작성, 미래를 위한 과도한 추상화 금지), 외과적 변경(요청과 관련된 코드만 수정, 무관한 리팩토링 금지), 목표 중심 실행(모호한 작업을 검증 가능한 목표로 전환 후 반복 개선).
dev.to 리뷰 아티클이 짚어낸 것처럼, 이 4가지는 하나의 연쇄를 끊는다. 대부분의 AI 코딩 실패는 명확하지 않은 가정 → 조용한 추측 → 과도한 추상화 → 불필요한 리팩토링 → 모호한 목표로 인한 재작업 순서로 이어진다. 각 원칙은 그 체인의 정확히 한 고리씩을 제거한다.
작은 파일이 큰 문제를 푸는 이유
주목할 만한 것은 이 파일의 형식 자체가 주는 메시지다. 수백 개 규칙의 대형 프롬프트 킷이 아니라, AI가 반복적으로 틀리는 지점만 골라낸 70줄. 비교 대상인 superpowers(12개 이상의 스킬과 강제 게이트)가 AI를 장시간 자율 실행할 때 필요한 '레일'이라면, CLAUDE.md 방식은 인간이 각 턴을 함께 감독하는 협업 환경에 맞는 '원칙'이다.
이 차이는 AI 코딩 도구 선택에서 실질적인 기준이 된다. 내가 매 단계를 함께 보고 있다면 명확한 원칙 몇 개로 충분하다. AI를 혼자 오래 달리게 둔다면 그것을 막을 구조적 장치가 필요하다. 도구의 크기가 아니라, 내 워크플로우의 구조에 맞는 도구를 고르는 것이 핵심이다.
가장 즉시 쓸 수 있는 원칙 하나를 꼽자면: 불명확할 때 질문하는 것을 '실패'가 아니라 '올바른 동작'으로 명시하는 것. AI 코딩 실패의 절반은 모델이 침묵하며 추측하는 데서 시작된다.
프론트엔드 개발자가 지금 설계해야 할 것
두 흐름을 함께 놓으면 하나의 그림이 된다. AI는 지금 인터페이스 레이어와 개발 레이어를 동시에 재설계하고 있다. 사용자는 화면을 배우는 대신 의도를 말하고, 개발자는 코드를 한 번에 완성하는 대신 AI와 함께 목표를 향해 반복 개선한다.
Lovable이 생성한 앱에 자체 MCP 서버를 탑재하기 시작했다는 소식은 이 방향이 사변이 아님을 확인해 준다. 앱이 '보여지는 것'만큼 '말 걸어지는 것'을 위해 설계되어야 하는 시대가 빠르게 다가오고 있다.
프론트엔드 개발자로서 지금 준비해야 할 것은 두 가지다. 첫째, 화면 설계와 병행해 에이전트가 호출할 액션을 얼마나 명확하게 정의할 수 있는가. 둘째, AI와 협업하는 코딩 세션에서 어떤 원칙이 실패를 구조적으로 줄이는가. 이 두 질문에 답하지 않은 팀은, 빠르게 움직이는 것처럼 보이지만 같은 자리에서 반복 실패하고 있을 가능성이 높다.