Flutter Agent Skills: AI 에이전트가 Flutter를 제대로 다루게 하는 방법

요약: 사용하고 있는 AI 코딩 어시스턴트는 일반론적입니다. Flutter처럼 보기에 맞는 코드는 작성하지만, 실제로는 2022년 패턴을 자주 사용합니다. Agent Skills는 Dart 및 Flutter 팀에서 제공하는 새로운 공식 기능으로, 에이전트에게 작업별로 검증된 워크플로우를 필요할 때 로드하여 전달하는 방식입니다. 두 개의 저장소인 flutter/skills와 dart-lang/skills는 반응형 레이아웃, 라우팅, 테스트, 현지화(localization), 정적 분석 등 즉시 사용할 수 있는 스킬들을 제공합니다. 다음 명령어로 설치할 수 있습니다:

npx skills add flutter/skills --skill '*' --agent universal
npx skills add dart-lang/skills --skill '*' --agent universal

본 게시물에서는 Agent Skills가 무엇인지, 규칙 파일(rules files) 및 MCP와 어떻게 다른지, 전체 카탈로그, 실제 스킬이 내부적으로 어떤 모습인지, 그리고 이것들이 실제로 변화를 가져오는지 등을 자세히 다룹니다. (스포일러: 대부분 그렇지만, 솔직한 주의사항이 하나 있습니다.)

제가 매일 거의 겪는 싸움에 대해 말씀드리겠습니다.

AI 에이전트에게 태블릿에 맞게 화면을 조정하도록 요청합니다. 그러면 MediaQuery.orientationOf(context)를 기반으로 레이아웃을 전환하는 코드를 자신감 있게 건네줍니다. 깔끔해 보입니다. 컴파일도 되고, 심지어 실행까지 됩니다. 하지만 틀렸습니다. 왜냐하면 기기 방향은 폴더블 장치, 분할 화면, 또는 크기 조정 가능한 데스크톱 창에서 앱이 실제로 차지하는 창 공간과는 아무 관련이 없기 때문입니다.

모델이 바보인 것은 아닙니다. 거대한 양의 Flutter 코드를 학습한 일반론적 모델일 뿐이며, 그중 상당수는 오래된 코드입니다. 그리고 Flutter 팀이 이 기능을 출시하며 입 밖에 낸 불편한 진실은 이것입니다: Flutter와 Dart는 LLM(대규모 언어 모델)이 학습 데이터를 업데이트하는 속도보다 더 빠르게 새로운 기능을 출시한다. 이러한 지연에는 '지식 격차(knowledge gap)'라는 이름이 붙었고, 바로 이 때문에 에이전트가 태연하게 초보적인 Flutter 코드를 계속 작성하는 것입니다.

Agent Skills는 Flutter 팀이 그 격차에 대한 해답으로 제시한 것입니다. 저는 실제 프로젝트에서 이를 사용해 보았는데, 2026년의 몇 안 되는 'AI 워크플로우' 기능 중 하나로서 과장된 홍보를 받기보다는 실질적인 가치를 인정받은 경우입니다. 자세히 알아보겠습니다.

목차

• 진짜 문제: 당신의 AI는 제너럴리스트(Generalist)입니다
• Agent Skills란 정확히 무엇인가?
• Skills vs Rules vs MCP: 각각의 역할
• 전체 카탈로그: 모든 공식 Flutter 및 Dart 스킬
• 스킬의 해부: 해당 파일 내부에는 실제로 무엇이 들어있는가
• 2분 만에 실행하기
• 솔직한 견해: 과장인가, 실체인가?
• 자신만의 스킬 작성하기
• FAQ
• 마무리

진짜 문제: 당신의 AI는 제너럴리스트(Generalist)입니다

AI 에이전트(AI agents)는 Flutter와 Dart를 작성할 수 있습니다. 이는 더 이상 의문의 여지가 없습니다. 문제는 그들이 어떤 Flutter 코드를 작성하느냐입니다.

제너럴리스트(Generalist) 모델은 수백만 개의 Stack Overflow 답변을 학습했으며, 그중 절반은 이미 지원이 중단(Deprecated)된 것들입니다. 따라서 당신이 구체적인 무언가를 요청하면, 모델은 수년간의 패턴을 평균 내어 현재 올바른 답이 아닌, 통계적으로 가장 흔한 답을 내놓습니다. 결과적으로 다음과 같은 상황을 겪게 됩니다:

• 가용 공간 대신 기기 유형(

이를 작업 지향적인 청사진(blueprint)이라고 생각하십시오. "Flutter에 대한 모든 것을 알려주겠다"가 아니라, "피해야 할 함정과 완료 여부를 확인하기 위한 체크리스트를 포함하여, 적응형 레이아웃(adaptive layout)을 구축하는 정확하고 올바른 단계별 방법은 이것이다"라고 말하는 것입니다.

이것을 실용적으로 만드는 메커니즘은 Flutter 팀이 **점진적 공개 (progressive disclosure)**라고 부르는 것인데, 만약 여러분이 Flutter를 작성한다면 이미 직관적으로 이해하고 있을 것입니다. 즉, 여러분의 컨텍스트 창(context window)을 위한 지연 로딩(deferred loading)입니다.

그 개념은 다음과 같습니다. 에이전트는 모든 스킬(skill)로부터 모든 지침을 미리 컨텍스트로 들이키지 않습니다. 그렇게 하면 토큰 예산(token budget)을 낭비하고 신호(signal)를 묻어버리게 될 것입니다. 대신 다음과 같이 작동합니다:

1. 에이전트는 먼저 각 스킬의 가벼운 메타데이터 (metadata)(이름과 언제 사용하는지에 대한 짧은 설명)만 읽습니다.
2. 실제 작업이 일치할 때(예를 들어, 반응형 레이아웃을 요청할 때), 에이전트는 필요에 따라 _해당 스킬 하나_에 대한 전체 지침을 가져옵니다.

지연 로딩된 전문 지식(Lazy-loaded expertise)입니다. 에이전트는 전문가가 되어야 하는 순간까지 가볍게 유지되다가, 그 순간 정확히 올바른 플레이북(playbook)을 로드합니다. 이것이 핵심 비결이며, 모델을 압도하지 않으면서 수십 개의 스킬로 확장할 수 있는 이유입니다.

Skills vs Rules vs MCP: 누가 무엇을 하는가

이 부분에서 대부분의 사람들이 혼란을 겪는데, 왜냐하면 이제 Flutter는 AI 에이전트를 조종할 수 있는 세 가지 방법을 제공하기 때문입니다. 이들은 경쟁 관계가 아니라 계층(layers)입니다. 제가 사용하는 멘탈 모델은 다음과 같습니다:

계층 (Layer)	정의	제어 대상	비유
Rules 파일 (Rules files)	프로젝트 전반에 걸친 지속적인 설정 (예: AI 규칙 파일)	모든 작업에 걸친 에이전트의 일반적인 동작	항상 적용되는 하우스 스타일 가이드
...

가장 깔끔하게 말하자면 다음과 같습니다: MCP는 에이전트에게 도구를 제공합니다. Skill은 에이전트에게 특정 작업을 위해 그 도구들을 올바르게 사용하는 방법을 가르칩니다. Rules는 모든 것에 대한 톤(tone)을 설정합니다.

실제 사용에서는 이들이 완벽하게 결합됩니다. MCP 서버는 에이전트가 실행 중인 앱에 연결하고 변경 사항 발생 시 핫 리로딩(hot reload)할 수 있도록 합니다. 스킬은 레이아웃 오버플로우(layout overflow)를 수정하는 과정의 일부로서, 언제 그리고 왜 그렇게 해야 하는지를 알려줍니다. Rules는 전체 과정을 프로젝트의 컨벤션과 일관되게 유지합니다. 이 모든 것이 합쳐지면, 단순히 인턴처럼 행동하기보다는 코드베이스의 표준을 숙지한 팀원처럼 행동하는 에이전트가 탄생합니다.

전체 카탈로그: 공식 Flutter 및 Dart 스킬 모음

두 저장소 모두 실제 Dart 및 Flutter 팀에서 관리하며 BSD-3-Clause 라이선스를 따르므로, 이것은 임의의 커뮤니티 자료가 아니라 1차 출처(first-party) 가이드입니다. 다음이 배포된 내용들입니다.

Flutter 스킬 (flutter/skills)

Skill	기능
flutter-build-responsive-layout	LayoutBuilder, MediaQuery, Expanded/Flexible를 사용하여 **창 공간(window space)**에 적응하는 레이아웃을 구축합니다.
...

Dart 스킬 (dart-lang/skills)

Skill	기능
dart-run-static-analysis	dart analyze를 실행하고 dart fix --apply로 기계적인 수정 사항을 자동 적용합니다.
...
Flutter 개발자의 관점에서 이 목록을 보면 가치가 즉시 느껴집니다. 이것들은 일반화된 모델이 현재의 최적 모범 사례(best practice)에서 실수하기 쉬운 바로 그 작업들입니다. 적응형 레이아웃, 라우팅(Routing), 현지화(Localization), 직렬화(Serialization). 눈에 띄지는 않지만 미묘하게 틀리기 쉬운 것들이죠.

스킬의 해부학: 파일 안에 실제로 무엇이 들어있는가

'마크다운 파일'이라는 말은 내용을 열어보기 전까지는 별것 아닌 것처럼 들립니다. 제가 이전에 발견했던 방향성 버그(orientation bug)와 완벽하게 반박할 수 있는 flutter-build-responsive-layout 스킬을 보여드리겠습니다.

스킬은 구조화된 가이드입니다: 규칙(rules), 안티 패턴(anti-patterns), 체크리스트 형태의 워크플로우(workflows-as-checklists), 그리고 실행 가능한 예제들로 구성됩니다. 이 스킬이 에이전트에게 가르치는 핵심 내용은 다음과 같습니다:

**협상 불가한 규칙(The non-negotiable rules):

다음은 번역된 내용입니다.

• 물리적 기기(physical device)가 아닌 **앱 창(app window)**을 측정하려면 MediaQuery.sizeOf(context)를 사용하세요.

• LayoutBuilder를 사용하고 constraints.maxWidth로 분기 처리하세요.

• 레이아웃 전환을 위해 트리의 상단 근처에서 MediaQuery.orientationOf나 OrientationBuilder를 사용하지 마세요; 방향은 사용 가능한 창 공간을 반영하지 않습니다.

• 하드웨어 유형(

• --agent universal 플래그를 사용하면 모든 항목이 호환 가능한 에이전트가 자동으로 탐색하는 표준 .agents/skills 디렉토리에 저장됩니다. 이를 커밋하면 팀 전체(및 CI)가 동일한 전문 지식을 상속받게 됩니다.

• '*' 대신 일부만 사용하고 싶으신가요? --skill flutter-build-responsive-layout과 같이 특정 스킬 이름을 입력하세요.

• 나중에 npx skills update로 업데이트할 수 있습니다.

설치가 완료되면, 제가 가장 선호하는 첫 번째 단계는 에이전트에게 현재 무엇을 할 수 있는지 물어보는 것입니다:

"내 .agents/skills 디렉토리를 검토해줘. 설치된 스킬 중 이 대시보드를 태블릿과 데스크톱에서 작동하게 만드는 데 도움이 될 만한 것이 뭐야?"

그러면 에이전트는 flutter-build-responsive-layout을 찾아내고 계획을 설명할 것이며, 여러분은 어떤 주문(incantation)을 입력해야 할지 고민할 필요 없이 바로 작업을 시작할 수 있습니다.

솔직한 견해: 거품인가, 실체인가?

이 기능들이 출시되었을 때, X(구 트위터)와 Reddit의 Flutter 커뮤니티는 늘 그렇듯 스크린샷을 올리고, "AI 코딩이 또 한 번 바뀌었다"며 열광했습니다. 저는 여러분께 솔직해지고 싶습니다. 거품은 누구에게도 도움이 되지 않기 때문입니다.

실체는 분명히 존재합니다. 이것은 단순히 분위기(vibe)의 문제가 아닙니다. 이는 흔히 발생하는 현재의 실수들을 입증 가능한 수준으로 방지해 주는, 퍼스트 파티(first-party)의 작업 범위 지정형 가이드입니다. 또한 점진적 공개(progressive disclosure) 방식 덕분에 토큰(token) 사용량은 낮추면서 정확도는 높이는 방식으로 작동합니다. 앱 개발의 화려하지 않은 80% 영역(레이아웃, 라우팅, 직렬화, 지역화, 테스트)에서 이는 진정한 업그레이드입니다. 저 또한 이 기능 덕분에 더 깔끔한 초안을 작성하여 배포할 수 있었습니다.

하지만 주의할 점이 있습니다. 스킬은 가드레일(guardrails)이지, 뇌 이식(brain transplant)이 아닙니다. 스킬은 에이전트가 알려진 작업에 대해 신뢰할 수 있게 정확하게 행동하도록 만들 뿐, 새로운 아키텍처에 대해 창의적으로 만들거나 모호한 프롬프트를 구제해주지는 않습니다. 초기 세트는 의도적으로 "가장 흔한 장애물"로 범위를 제한했습니다. Flutter 팀은 이것이 완성된 제품이 아닌 시작점임을 명시했으며, 커뮤니티에 이슈를 제기하고 더 많이 기여해 달라고 공개적으로 요청하고 있습니다.

따라서 올바른 프레임링(framing)은 "AI가 이제 내 앱을 만들 수 있다"가 아닙니다. 그것은 다음과 같습니다: 당신의 에이전트가 이제 쉬운 작업에서 실패하는 것을 멈추었으므로, 당신은 더 어려운 문제에 당신의 판단력을 집중할 수 있게 되었다. 이것은 제가 매일이라도 기꺼이 받아들일 만한 거래입니다.

만약 당신이 이미 Cursor, Claude Code, Antigravity, 또는 .agents/skills를 읽는 그 어떤 에이전트를 사용하고 있다면, 다음 작업에서 이를 시도해 보지 않을 이유가 사실상 없습니다.

자신만의 스킬 작성하기

차이점을 느끼고 나면, 당신은 당신 팀만의 패턴을 인코딩(encode)하고 싶어질 것입니다: 당신의 상태 관리(state management) 선택, 폴더 컨벤션(convention), API 클라이언트 등 말이죠. 스킬은 단순한 마크다운(Markdown) 폴더일 뿐이기에, 이는 매우 실행 가능한 일입니다. 효과적인 구조는 다음과 같습니다:

1. 폴더 생성: .agents/skills/your-skill-name/ 아래에 SKILL.md 파일을 포함한 폴더를 생성합니다.
2. 간결한 메타데이터 작성: 이름과 한 줄짜리 "이것을 ~할 때 사용하세요..." 식의 설명을 작성합니다. 이 부분은 에이전트가 가장 먼저 읽는 부분이므로, 트리거(trigger) 조건을 명확하게 만드세요.
3. 규칙 및 안티 패턴(anti-patterns) 명시: 무엇을 해야 하는지만 말하지 말고, 무엇을 하지 말아야 하는지도 말하세요. "orientation을 사용하지 마세요"와 같은 한 줄이 반응형(responsive) 스킬을 완벽하게 만듭니다.
4. 워크플로우 체크리스트 추가: 에이전트가 따라가며 스스로 검증할 수 있도록 단계들을 실제 작업 목록(task list) 형태로 상세히 기술하세요.
5. 실행 가능한 예시 포함: 하나의 정석적이고 올바른 코드 스니펫(snippet)은 수천 개의 형용사보다 가치 있습니다.