'빌드 미 어 대시보드.' 프롬프트를 입력하고 결과물이 나타나는 순간, 우리는 흔히 이렇게 생각한다. '오, 꽤 그럴싸한데?' 그런데 조금만 더 깊이 들여다보면 질문이 쌓인다. 이 UI가 실제 사용자 멘탈 모델과 맞는가? 정보 구조는 의도적으로 설계된 건가, 아니면 LLM이 그냥 보기 좋아 보이는 걸 골라낸 건가? 디자인 토큰은 일관성이 있는가? 대부분의 경우 답은 '아니오'다. 결과물은 소프트웨어처럼 보이지만, 소프트웨어처럼 느껴지지 않는다.
29년 경력의 디자이너 Julian Oczkowski가 dev.to에서 지적한 핵심이 바로 이 지점이다. 그는 Adobe, IBM을 거치며 Sketch가 Photoshop을 대체하고, Figma가 Sketch를 대체하는 흐름을 목격했다. 그러나 AI는 도구만 바꾸는 게 아니라 프로세스 자체를 대체하고 있다고 말한다. 문제는 대부분의 사람들이 프로세스 없이 실행 단계로 곧장 뛰어든다는 것. 그 결과는 '더 빠른 혼돈(faster chaos)'이다.
그가 제시한 해법은 프로세스 자체를 Claude Code의 커스텀 스킬로 인코딩하는 것이다. 7단계 워크플로는 'Grill Me'(요구사항 심문)에서 시작해 Design Brief(코드베이스 분석 기반 설계 명세), Information Architecture(페이지·네비게이션 구조화), Design Tokens(CSS 커스텀 프로퍼티 자동 생성), Brief to Tasks(의존성 기반 태스크 분해), Frontend Design(실제 빌드), Design Review(Playwright MCP를 활용한 자동 캡처 및 접근성 검증) 순으로 이어진다. 결과는 단순한 코드 생성이 아니다. Lighthouse 접근성 점수 100, 성능 점수 91의 완성도 높은 애플리케이션이 나왔다—'한 줄짜리 막연한 프롬프트'에서 출발해서.
흥미로운 건 이 접근이 단순히 '좋은 프롬프트 쓰기'의 문제가 아니라는 점이다. 첫 번째 스킬 'Grill Me'는 LLM이 코드를 한 줄도 쓰기 전에 20분 동안 요구사항을 심문하도록 설계되어 있다. "무엇을 만들고 왜 만드는지 명확히 말할 수 없다면, LLM도 만들어선 안 된다." 이 원칙은 AI 협업의 본질을 꿰뚫는다. 에이전트의 실행 속도가 빨라질수록, '무엇을'과 '왜'를 정의하는 인간의 역할은 오히려 더 중요해진다.
한편 AI 에이전트를 느리고 비용 많이 드는 존재로 만드는 또 다른 구조적 문제가 있다. 컨텍스트 낭비다. dev.to의 Mnemosyne 엔진 소개 글은 829개 파일 규모의 프로덕션 코드베이스에서 Claude Code가 관련 코드를 찾는 데만 45K 토큰을 소비했다는 수치를 제시한다. 대화 3턴이면 컨텍스트가 증발하고, 에이전트 품질이 급격히 저하된다. 20개 질문 세션이면 900K 토큰—거의 전체 컨텍스트 윈도우를 소진한다.
Mnemosyne은 이 문제를 코드베이스와 LLM 사이에 앉아 SQLite 기반 인덱싱과 6개 검색 신호(BM25, TF-IDF, 심볼 검색, 사용 빈도, 예측 프리페치, 선택적 밀집 임베딩)를 퓨전해 토큰 예산 안에서 최적 청크만 전달하는 방식으로 해결한다. AST 인식 청킹으로 Python, Go, Rust, TypeScript 등 주요 언어를 지원하며, 설치는 pip install mnemosyne-engine 한 줄이다. 보고된 토큰 절감율은 73%. CLAUDE.md에 세 줄만 추가하면 에이전트가 파일을 읽기 전에 Mnemosyne에 먼저 쿼리하도록 강제할 수 있다.
컨텍스트 낭비 문제를 다른 각도에서 접근하는 전략도 있다. dev.to의 'AI Coding Tip 013'이 소개하는 '프로그레시브 디스클로저(Progressive Disclosure)' 패턴이다. 핵심은 단순하다. 20개 파일을 한꺼번에 컨텍스트에 올리는 대신, 키워드 트리거를 정의해 필요한 파일만 조건부로 로드한다. 15,000토큰짜리 모놀리식 스킬 파일 대신 800토큰의 라우터와 용도별 모듈 파일들로 분리하면, "DECLARE 123이 유효한가?"라는 질문에 전체 문법 규칙을 불러오는 대신 선언문 관련 파일 1,200토큰만 로드한다. 이 패턴은 발견(Discovery)→활성화(Activation)→실행(Execution)의 3단계로 구조화되며, 에이전트가 실제로 필요한 순간에만 정보를 요청하도록 설계된다.
세 가지 접근을 종합하면 하나의 원칙이 보인다. AI 에이전트의 품질은 프롬프트의 품질이 아니라 '협업 구조의 품질'에서 온다. 실행 전 요구사항을 구조화하고(Grill Me 패턴), 대용량 코드베이스에서 관련 컨텍스트만 정밀하게 추출하고(Mnemosyne), 스킬 자체를 필요 기반으로 모듈화하는 것(프로그레시브 디스클로저)—이 세 층위는 각각 독립적이지만, 함께 작동할 때 에이전트를 진짜 '동료'에 가깝게 만든다.
프론트엔드 개발자 관점에서 가장 주목할 지점은 Playwright MCP와의 결합이다. 에이전트가 헤드리스 브라우저로 직접 애플리케이션을 탐색하고, 스크린샷을 찍고, 접근성 갭을 식별하고, 수정까지 제안하는 자율 리뷰 루프는 기존의 수동 QA 프로세스를 근본적으로 재설계한다. '디자인-개발 협업에서 AI의 역할'이 단순 코드 생성 보조를 넘어 리뷰어이자 QA 엔지니어이자 IA 설계자로 확장되는 순간이다.
결국 Claude Code를 진짜 동료로 만드는 것은 더 영리한 프롬프트가 아니다. 에이전트에게 '생각할 구조'를 먼저 주는 것이다. 프로세스 없이 속도만 높이면 혼돈도 빨라진다. 반면 요구사항 심문, 컨텍스트 최적화, 조건부 로딩이라는 세 가지 설계 원칙이 갖춰지면, LLM은 단순한 코드 생성기가 아니라 프로덕트 사고를 함께 실행하는 파트너가 된다. 도구가 빨라지는 속도보다 프로세스 설계가 더 중요해지는 시대—그 전환점이 지금이다.