실패에서 재탄생: 프런트엔드 AI 에이전트를 성공적으로 구축한 실제 사례 연구 오늘 FEDay에서 프런트엔드 에이전트 구현 사례 연구를 공유했습니다. 핵심은 성공을 자축하는 이야기가 아니라, 한 팀이 "기술적 성공"에서 "제품 실패"로 나아가는 과정, 그리고 그 실패가 어떻게 인지 프레임워크의 중요한 업그레이드로 이어졌는지에 대한 이야기였습니다. 이 이야기의 가치는 성공을 위한 방법론에 있는 것이 아니라, 우리가 겪었던 어려움과 사고의 진화에 있습니다.
2025년은 "에이전트의 해"로 불리고 있습니다. Deep Research, Manus, Claude Code 등의 출시로 기술 업계는 들썩이고 있습니다. 많은 팀들이 똑같은 질문을 던지고 있습니다. "에이전트를 만들어야 할까요?"
본론으로 들어가기 전에, 제가 생각하는 AI 에이전트의 정의를 명확히 하겠습니다. AI 에이전트: 특정 목표를 달성하기 위해 도구 호출을 반복적으로 수행하는 대규모 언어 모델(LLM). - 반복적인 도구 사용: 모델이 도구를 호출하고 -> 결과를 얻고 -> 추론을 계속합니다. - 명확한 종료점: 무한 루프가 아닌 목표 달성을 위해 작동합니다. - 유연한 목표 소스: 목표는 사용자 또는 다른 LLM에서 가져올 수 있습니다. - 기본 메모리: 대화 기록을 통해 맥락을 유지합니다.
과제: 개인 맞춤형 디자인 시스템 제 친구의 팀이 실제 기업에서 흔히 발생하는 문제점에 직면했습니다. 회사는 완벽한 내부 디자인 시스템과 자체 개발한 프런트엔드 프레임워크를 보유하고 있었지만, 이 코드가 비공개였기 때문에 공개 AI 모델이 학습시킨 적이 없었습니다. 범용 모델로는 내부 사양을 준수하는 코드를 생성할 수 없었던 것입니다. 목표는 명확해 보였다. "러버블(Lovable)"과 유사한 도구를 만들되, 자체 디자인 시스템을 기반으로 하는 것이다. 사용자는 피그마(Figma) 디자인이나 스크린샷을 업로드하고, 에이전트는 내부 표준을 준수하는 프런트엔드 코드를 자동으로 생성하는 것이다. 완벽하죠?
현실 점검: 당면 과제는 상당했습니다. 1. 완벽한 에이전트 시스템을 구축하는 것은 겉보기보다 어렵습니다(사용자 상호작용, 컨텍스트 엔지니어링 등). 2. 모델은 이전에 본 적 없는 비공개 구성 요소를 이해하고 사용해야 합니다. 3. 생성된 코드의 실시간 브라우저 미리보기가 필요했습니다. 4. 코드 실행에 오류가 발생할 경우 자동 복구 기능이 필요했습니다.
"기술적 성공": 그 비결 기술 컨설턴트로서 제가 드린 첫 번째 조언은 실용적인 것이었습니다. "최적화하기 전에 먼저 실행해 보세요." 에이전트를 구축하는 것이 가장 어려운 부분이 아닙니다. 전체 실행 과정을 완료하는 것이 진짜 어려운 부분입니다.
1. 재단: Claude Agent SDK 우리는 바퀴를 새로 발명하는 대신 Claude Agent SDK를 기반으로 개발했습니다. - 검증 완료: 클로드 코드(Claude Code)는 이 아키텍처가 효과적임을 입증했습니다. - 바로 사용 가능: 내장 도구가 시나리오의 90%를 지원합니다. - 확장성: 사용자 정의 도구, MCP(모델 컨텍스트 프로토콜) 및 사용자 정의 스킬을 지원합니다. (프로토타입 코드의 일부는 다음 링크에서 오픈소스로 확인할 수 있습니다: https://t.co/eon1eb3ECD)
2. 미리 보기 솔루션: 로컬 파일 시스템 처음에 코드 미리보기를 위해 Sandpack(브라우저 기반 샌드박스)을 사용해 보았지만, 복잡한 비공개 구성 요소에서는 제대로 작동하지 않았습니다. 그래서 에이전트에 로컬 파일 시스템(세션별 VM 또는 디렉터리)을 제공하는 방향으로 전환했습니다. 이를 통해 에이전트는 코드를 자유롭게 읽고, 쓰고, 수정하고, 컴파일할 수 있게 되었습니다.
에이전트에 로컬 파일 시스템을 제공하는 것이 에이전트의 기능을 극대화하는 유일한 방법입니다.
3. "알 수 없는 구성 요소" 문제 해결 인공지능에게 이전에 본 적 없는 컴포넌트 라이브러리 사용법을 어떻게 가르칠 수 있을까요? 새 직원을 대하듯이 다루세요. 디자인 시스템 사양, 구성 요소 목록 및 API 문서를 마크다운으로 변환했습니다. 복잡한 RAG는 필요하지 않았습니다. 에이전트가 로컬 문서와 "고품질 참조 코드"에서 파일 검색을 수행하도록 허용하기만 하면 되었습니다.
4. 품질 보증: 검증 루프 코드가 실제로 작동하는지 확인하기 위해 생성 -> 검증 -> 수정의 자동화된 루프를 구축했습니다. - 도구: 정적 린팅, 컴파일 검사 및 시각적 차이점 비교(Chrome 개발자 도구 MCP 사용). - 최적화: 메인 에이전트의 컨텍스트 창을 복잡하게 만들지 않도록 검증 도구를 스킬 또는 서브 에이전트에 배치했습니다.
"제품 실패": 출시 후의 침묵 시스템은 제대로 작동했다. 데모는 훌륭했다. 출시했지만... 거의 아무도 사용하지 않았다. 초기의 신선함이 사라지자 사용 중단율이 급증했습니다. 심층적인 사후 분석과 사용자 인터뷰를 통해 문제의 원인이 기술적인 문제가 아니라 제품 로직과 사용자 습관 간의 불일치라는 것을 깨달았습니다.
실패한 이유는 무엇일까요? 1. 습관 저항: 디자이너와 PM은 Figma에서 주로 작업하며 채팅창에는 익숙하지 않습니다. 익숙한 환경에서 대화형 인터페이스로 전환하는 것은 엄청난 마찰 요인이었습니다. 대부분은 무엇을 입력해야 할지조차 몰랐습니다. 2. 80/20 병목 현상: 에이전트가 작업의 80%는 완벽하게 수행했지만, 나머지 20%는 수동 수정이 필요했고, 이는 엄청난 노력을 요구했습니다. 종종 이 20%의 수정 작업이 코드의 사용 가능 여부를 결정짓기도 했습니다. 3. 워크플로 분리: 생성 환경이 실제 개발 환경과 분리되어 있었습니다. 개발자들은 코드를 수동으로 복사 붙여넣기해야 했기 때문에 과정이 매우 번거로웠습니다.
인지 능력 향상: 문제 재구성 우리는 "디자인 시스템 AI 에이전트를 어떻게 구축할 수 있을까?"라는 잘못된 질문을 던졌다는 것을 깨달았습니다. 이 질문은 에이전트를 수단이 아닌 목표로 삼게 만들었습니다. 진정한 질문은 "우리 디자인 시스템의 궁극적인 목적은 무엇인가?"였습니다. 1. 기업 전체에 걸쳐 통일된 설계 사양. 2. 개발 효율성 향상.
변화 1: 인간이 아닌 AI를 위한 디자인 현재의 워크플로는 사람 중심적입니다. 수동 소통, 반복적인 수정, 수동 확인이 포함됩니다. 미래의 워크플로는 AI 중심적이어야 합니다. 입력 -> AI 에이전트 -> 출력 순으로 진행되어야 합니다. 새로운 디자인 원칙: - AI 친화적: LLM이 쉽게 이해할 수 있는 기술 스택을 선택하세요. - 경량화: 디자인 토큰만 유지합니다. 방대한 자체 라이브러리를 유지 관리하는 대신 AI 친화적인 오픈 소스 시스템(예: shadcn/ui)을 활용합니다.
2단계 변화: "에이전트"에서 "스킬"로 가장 중요한 전환점은 "독립 에이전트 플랫폼"을 포기한 것이었습니다. 기존 모델(아일랜드): 개발자와 격리된 독립형 에이전트로, 마찰을 일으킵니다. 새로운 모델(통합): 디자인 시스템을 기존 AI 개발 환경(예: Cursor 또는 Claude Code)에 내장할 수 있는 스킬로 전환합니다.
스킬이란 무엇인가요? 간단히 말해 AI가 읽을 수 있는 마크다운 문서와 프로젝트 초기화 및 시스템 설치를 위한 자동화 스크립트입니다. 이제 개발자는 익숙한 환경에서 작업합니다. 디자인 시스템이 필요할 때, 일반 에이전트는 이를 "스킬"이라고 호출하고 생성된 코드는 프로젝트 저장소에 직접 저장됩니다. (참조 접근 방식: anthropics/skills/tree/main/skills/web-artifacts-builder)
심층 분석: 4가지 핵심 요점 1. 기술적 성공 ≠ 제품 성공 많은 엔지니어들(저를 포함해서)은 "작동하니까 성공한 것이다"라는 함정에 빠지곤 합니다. 사용자들은 여러분의 기술 스택에는 관심이 없습니다. 그들은 자신들의 문제를 해결해 주고 작업 흐름을 방해하지 않는지에 관심이 있습니다. 2. "AI 중심" 워크플로우 설계 우리는 "사용자 중심"에 대해 이야기하지만, 여기에 "AI 중심"이라는 요소를 추가해야 합니다. AI가 인간의 작업 방식을 모방하게 해서는 안 됩니다. AI가 최고의 효율로 작동할 수 있도록 작업 방식을 재설계하고, 그 결과를 인간이 누리도록 해야 합니다. 3. 스킬 > 에이전트 독립형 에이전트 플랫폼은 도입 장벽이 높습니다. 기존 생태계에 통합될 수 있는 스킬 형태로 기능을 캡슐화하는 것이 훨씬 더 실용적인 접근 방식입니다. 4. 행동 초기 제품은 "실패"했지만, 인지 능력 향상은 값을 매길 수 없을 만큼 귀중했습니다. 직접 경험하지 않고서는 "인간의 업무 방식"에서 "AI의 업무 방식"으로 전환하는 법을 배울 수 없습니다.
그냥 만들어 보세요! 실패는 용납될 수 있다. 아무것도 하지 않는 것보다는 훨씬 낫다.
