Flutter 개발자의 AI 워크플로우와 스킬 설계 원칙

URL: https://www.youtube.com/watch?v=4hfmNiQDt1g
날짜: 2026-09-02
채널: Tech Bridge
원문 제목: [한영자막] Flutter 개발자 인터뷰: 플러터 개발자의 AI 워크플로우
출연자: Ivana
영상 길이: 15분 28초

---

📌 핵심 질문 / AI 코딩을 재사용 가능한 개발 체계로 만드는 방법

==AI 코딩 생산성의 핵심은 프롬프트를 한 번 잘 쓰는 데 있지 않고, 프로젝트 지식·반복 절차·검증 단계를 스킬(Skill)로 구조화해 필요한 순간에만 불러오는 데 있다.==

• 프롬프트(prompt)는 현재 작업을 메시지로 지시하고, 프로젝트 규칙(project rules)은 에이전트가 늘 알아야 할 지식을 제공한다.
• 스킬(skill)은 반복 업무나 자동화할 일회성 워크플로우를 단계별 지침·스크립트·참조 자료로 묶어 선택적으로 로드한다.
• 공식 스킬과 내용 검증으로 prompt injection 위험을 줄이고, 여러 에이전트와 실제 UI 캡처를 통해 코드·제품 결과를 함께 검증한다.

Flutter 개발자 Ivana의 접근법은 AI를 복사·붙여넣기 도구로 두지 않고, 작업을 분배하고 결과를 교차 점검하는 팀처럼 운영하는 방식이다. 세 대의 머신에서 Claude, Codex, Antigravity를 병렬로 돌리며 같은 프로젝트의 작업을 넘겨받게 하고, Flutter의 단일 코드베이스 멀티플랫폼 배포 이점을 AI의 속도와 결합한다.

1. 프롬프트, 프로젝트 규칙, 스킬의 역할 분리

AI 코딩 에이전트의 컨텍스트는 모든 정보를 한꺼번에 넣는 방식보다, 항상 필요한 지식과 작업별 지식을 분리할 때 효율적으로 유지된다.

1.1. 메시지형 프롬프트와 프로젝트 규칙

1. 프롬프트는 현재 작업을 짧은 메시지로 전달한다

   1. 직접 지시: “이 작업을 해 달라(do this for me)”처럼 에이전트에게 원하는 행동을 메시지로 요청한다.
   2. 버그 수정: “버그를 고쳐 달라(Fix the bug)”처럼 구체적인 현재 과업을 바로 위임한다.

2. 프로젝트 규칙은 지속적으로 필요한 지식을 보관한다

   1. 단일 Markdown 파일: 프로젝트의 구조·관례·기술적 지식을 한 Markdown 파일에 저장한다.
   2. 상시 참조: 에이전트는 프로젝트 규칙 파일을 항상 읽어야 하므로, 모든 작업에 공통으로 필요한 제약과 배경을 이곳에 둔다.

1.2. 스킬의 선택적 로딩

1. 스킬은 과업별 실행 지침이다

   1. 구성: 스킬은 Markdown 파일과 필요에 따라 scripts, assets, references 같은 부속 요소로 구성된다.
   2. 선택적 컨텍스트: 에이전트는 모든 스킬을 항상 읽지 않고, 특정 과업과 관련 있다고 판단한 스킬만 로드한다.

2. 스킬은 조직의 작업 방식을 코드화한다

   1. 개인화: 사용자가 원하는 동작에 맞춰 자기만의 스킬을 만들 수 있다.
   2. 확장 주체: 팀과 엔터프라이즈도 각자의 절차와 도메인 지식을 스킬로 만들어 공유하게 된다.

2. 스킬을 만들어야 하는 순간

반복성과 자동화 욕구가 스킬 도입을 판단하는 가장 실용적인 기준이다.

2.1. 반복 업무의 표준화

1. 반복은 스킬 작성의 주된 신호다

   1. 코드 리뷰(Code Review): 매번 같은 확인 작업을 되풀이한다면 수행 순서와 판단 기준을 하나의 템플릿으로 묶을 수 있다.
   2. 단계별 지침: 반복되는 작업을 step-by-step instruction으로 바꾸면 에이전트가 일정한 순서로 실행하는 스킬이 된다.

2. 표준화는 지루한 작업의 품질 편차를 낮춘다

   1. 누락 방지: 사람이 매번 기억해야 할 절차를 문서화해 동일한 체크리스트를 적용한다.
   2. 재사용: 한 번 만든 템플릿을 다음 코드 리뷰나 유사 업무에 반복 적용한다.

2.2. 한 번뿐인 워크플로우의 자동화

1. 반복하지 않아도 자동화할 가치가 있다

   1. 모바일 광고 사례: 앱에 모바일 광고를 넣는 작업은 한 번일 수 있지만, Google Ads를 Flutter 앱에 설치하는 큰 기능 구현 과정은 자동화할 수 있다.
   2. 외부 스킬 활용: 해당 설치 절차를 담은 검증된 스킬이 있다면 매일 반복하지 않아도 한 번 로드해 작업에 사용할 수 있다.

2. 일회성 스킬은 사용 후 정리한다

   1. 목적 중심 사용: 필요한 기능을 완성할 때까지만 스킬을 프로젝트에 불러온다.
   2. 컨텍스트 관리: 작업이 끝난 뒤 더 이상 필요하지 않은 스킬은 제거해 프로젝트 컨텍스트를 불필요하게 키우지 않는다.

3. Markdown 스킬의 보안과 유지보수

파일 확장자가 Markdown이라는 이유만으로 스킬을 무해한 문서로 취급하면 안 된다.

3.1. Prompt injection과 데이터 탈취 위험

1. 스킬도 공격 표면이 된다

   1. 악성 지침: 인터넷에서 받은 MD 파일에 prompt injection이 포함될 수 있고, 에이전트가 공격자의 지시를 따르게 만들 수 있다.
   2. 비밀정보 탈취: 악성 스킬은 에이전트에게 키(key)나 기타 비밀정보를 훔치도록 유도할 수 있다.

2. 겉보기 텍스트만으로 안전성을 판단할 수 없다

   1. 숨은 문자: 텍스트 자체는 정상처럼 보여도 보이지 않는 Unicode 지침이 prompt injection으로 작동할 수 있다.
   2. 무해하다는 오해: MD 파일은 실행 파일처럼 보이지 않지만, 에이전트가 읽고 행동으로 옮기는 지시문이므로 실제 영향력은 크다.

3.2. 안전한 스킬 선택과 관리

1. 공식 출처를 우선한다

   1. Google 저장소: Google repository의 공식 Flutter skills와 Dart official skills처럼 관리 주체가 명확한 자료를 우선한다.
   2. 공식 패키지 유지관리자: Jasper 같은 공식 package maintainer의 스킬도 무작위 검색 결과보다 안전한 선택지로 제시된다.

2. 비공식 스킬은 내용을 직접 검사한다

   1. 첫 검색 결과 회피: “Flutter mobile ads skill” 같은 검색어로 찾은 첫 파일을 곧바로 다운로드하지 않는다.
   2. 구성 검토: 공식 버전이 없다면 지침 내용과 숨은 Unicode를 확인한 뒤 사용하고, 권한과 비밀정보 접근 범위도 점검한다.

3.3. 스킬은 작은 저장소처럼 관리한다

1. 공식 스킬도 지속적인 유지보수가 필요하다

   1. 새로운 저장소 규모: 팀에서 작성한 공식 스킬을 관리하는 일은 사실상 하나의 새로운 repository를 운영하는 일에 가깝다.
   2. 커뮤니티 운영: Flutter 커뮤니티 스킬을 정리해 공개 저장소로 운영하는 경우에도 변경점과 개선점을 계속 확인해야 한다.

2. 주기적 점검이 품질을 지킨다

   1. 점검 주기: 커뮤니티용 Flutter skills 저장소는 최소 2주마다 변경·업데이트·최적화 필요성을 확인한다.
   2. 유지보수 비용: 스킬이 유용하다는 커뮤니티 피드백은 가치가 있지만, 그만큼 새로운 지침을 검토하고 맞춰 가는 작업도 발생한다.

4. AI가 스킬을 만들 때 인간이 맡을 역할

AI가 스킬과 스킬을 만드는 도구까지 생성하는 시대에는 인간이 직접 타이핑하는 사람보다 작업을 설계하고 감독하는 관리자로 이동한다.

4.1. Skill creator로 제작 공정 자동화

1. 스킬 생성 명령을 활용한다

   1. 내장 기능: 많은 도구에는 skill creator command가 있으며, 기능이 없더라도 원하는 주제의 스킬을 만들어 달라고 에이전트에 요청할 수 있다.
   2. 부속 자료 생성: 에이전트는 SKILL.md뿐 아니라 scripts, references, assets까지 작성해 스킬을 더 강력하게 만들 수 있다.

2. 자동 생성 결과를 그대로 승인하지 않는다

   1. 질문과 반복: 스킬 생성 과정에서 에이전트가 목적과 동작 방식에 관한 질문을 던지면 답을 조정하며 원하는 모양으로 반복 개선한다.
   2. 인간의 통제: 생성된 지침을 직접 읽고 수정해야 하며, “그냥 자동화”하는 대신 결과에 대한 통제권을 유지한다.

4.2. 복사 작성자에서 작업 관리자로

1. AI가 만드는 도구의 연쇄

   1. 도구의 중첩: AI가 AI 코드를 작성하도록 돕는 도구를 만들고, 그 도구를 돕는 스킬까지 AI가 만드는 구조가 생겼다.
   2. 인간의 위치: 인간은 모든 코드를 직접 복사해 작성하기보다 목표·순서·품질 기준을 정하고 에이전트의 결과를 판단하는 쪽으로 이동한다.

2. 관리에는 검증과 편집이 포함된다

   1. 리뷰: 자동 생성된 스킬이 프로젝트의 실제 규칙과 보안 요구를 반영하는지 확인한다.
   2. 조정: 필요 없는 단계, 위험한 권한, 프로젝트에 맞지 않는 가정을 제거하고 팀이 재사용할 수 있는 형태로 다듬는다.

5. Flutter 개발자가 추천한 다섯 가지 스킬

다섯 가지 추천은 스킬 제작 공정, 품질 검토, 프로젝트별 기능 추가, Flutter 레이아웃, 실제 UI 검증이라는 개발 수명주기를 넓게 덮는다.

5.1. 스킬 생성과 코드 품질

1. 첫 번째는 skill creator skill이다

   1. 제작 자동화: 스킬을 만드는 전체 과정을 자동화해 초기 작성 부담을 줄인다.
   2. 구성 요소 보존: scripts, references, assets를 함께 고려하므로 SKILL.md만 작성하고 끝내는 실수를 줄인다.

2. 두 번째는 code review skill이다

   1. 검증된 개인 도구: Ivana는 1년 넘게 자신의 code review skill을 사용했고, 공개 skills repository에도 공유했다.
   2. 교차 검토: Kevin Moore의 PR triager skill을 별도 에이전트에 맡겨 한 에이전트는 코드 리뷰, 다른 에이전트는 PR triage를 수행하게 한 뒤 두 보고서를 서로 대조한다.

5.2. 프로젝트별 기능 추가

1. 세 번째는 백엔드 새 엔드포인트를 앱에 연결하는 커스텀 스킬이다

   1. 프로젝트 특화: 새 backend endpoint를 지원하는 방식은 프로젝트마다 다르지만, 앱의 반복 작업이라는 공통점이 있다.
   2. 작업 범위: 새 기능에는 새 페이지, navigation 등록, 기존 scaffold, 앱의 navigation 패턴, design system, repository 데이터 연결이 함께 필요할 수 있다.

2. 설명(description)이 트리거 역할을 한다

   1. 명시적 사용 조건: 스킬 설명에 “우리 앱에 새 기능을 추가할 때 사용(use when adding new feature to our app)”이라고 적는다.
   2. 관련 자료 로드: 에이전트는 새 기능 요청을 받으면 해당 스킬을 읽고 assets 폴더의 템플릿과 새 페이지를 추가하는 절차를 참고한다.

5.3. Flutter 레이아웃과 시각적 QA

1. 네 번째는 기본 Flutter 레이아웃 스킬이다

   1. 권장 위젯: Row, Column, Wrap, Stack의 동작과 사용 시점을 작은 스킬로 정리한다.
   2. 레이아웃 품질: 텍스트를 왼쪽, 이미지를 오른쪽에 두는 단순한 요구에도 에이전트가 Container와 padding의 이상한 조합이나 불필요한 Stack을 택할 수 있으므로, Row와 Flexible, Expanded를 올바르게 선택하도록 유도한다.

2. 레이아웃 지침은 반응형 설계를 앞당긴다

   1. 모델의 편향: 에이전트는 결과를 빨리 내도록 보상받은 학습 특성 때문에 하드코딩된 위치 지정이나 우회적인 위젯 조합을 선호할 때가 있다.
   2. 첫날부터 반응형: 레이아웃별 역할을 알려 주면 초기 구현부터 responsive design을 적용하고, 나중에 위치를 다시 뜯어고치는 일을 줄일 수 있다.

3. 다섯 번째는 실제 스크린샷 기반 QA 스킬이다

   1. 자동 캡처: 앱을 웹에서 실행하고 실제 화면을 스크린샷으로 캡처해 QA 자료를 만든다.
   2. 독립적 시각 검사: 사람이나 다른 에이전트가 코드만 읽거나 테스트가 통과했다는 사실만 확인하지 않고, 화면 이미지에서 UI 결함을 찾는다.

4. 실제 캡처와 Golden test는 역할이 다르다

   1. Golden test의 비용: Golden test는 폰트 로딩과 이미지 처리 차이를 맞추는 우회 작업이 필요하지만, UI regression 탐지에는 여전히 유용하다.
   2. 실제 화면의 장점: QA에는 실제 스크린샷을 사용하고, 때로는 animated WebP로 화면 흐름이나 제스처를 기록해 iPhone simulator가 앱을 로드할 때까지 기다리지 않고 결함을 즉시 확인한다.

6. 세 대의 에이전트를 병렬 운용하는 일상 워크플로우

AI는 Ivana의 개발 속도를 크게 높였지만, 생산성 증가는 작업량과 토큰 사용량을 계속 늘리는 운영 습관과 함께 나타난다.

6.1. 같은 프로젝트를 여러 머신에 분산

1. 세 대의 머신이 서로 다른 에이전트를 실행한다

   1. 병렬 구성: 한 머신은 Claude, 한 머신은 Codex, 한 머신은 Antigravity를 실행한다.
   2. 작업 인계: 세 에이전트가 서로 작업을 hand off하며, 한 에이전트의 결과를 다음 에이전트가 이어받는다.

2. 병렬 작업은 개인 개발을 에이전트 팀처럼 바꾼다

   1. 동일 프로젝트: 세 머신은 보통 같은 프로젝트를 실행한다.
   2. 개인 프로젝트 적용: RevenueCat의 Ship-a-ton에 제출할 앱을 만들기 위해 정규직 본업 이후 저녁과 주말에 에이전트 팀을 운영한다.

6.2. 생산성과 토큰 사용의 심리

1. AI에 대한 신뢰는 오래된 경험에서 시작됐다

   1. 기술 배경: Ivana는 과거 machine learning과 data engineering 경험이 있어 AI 회의론자 진영에 속하지 않았고, AI가 모든 것을 바꿀 것이라고 일찍부터 믿었다.
   2. Midjourney의 충격: Midjourney가 등장했을 때 비기술자에게 AI가 만든 이미지를 보여 주며, 입력과 출력이 모두 숫자인 순수한 확률 계산이 예술을 만들어 내는 현상에 감탄했다.

2. 높은 생산성에는 과몰입 위험이 따른다

   1. 토큰 소진 목표: 세 에이전트의 사용 한도가 남아 있으면 모두 소진할 때까지 계속 작업하고 싶어지는 심리가 작동한다.
   2. 게임화된 감각: 남은 토큰을 소진하는 감각은 일종의 심리적·게임화된 자극이며, 스스로 “조금 속도를 늦춰야 한다”고 느낄 정도로 생산성을 끌어올린다.

7. Flutter에서 AI 코딩이 갖는 강점과 한계

Flutter의 AI 활용성은 모델 학습 데이터의 양만으로 결정되지 않으며, 한 코드베이스로 여러 플랫폼에 배포하는 프레임워크의 구조가 큰 보완 효과를 낸다.

7.1. 학습 데이터 부족과 반복 지침

1. Flutter는 Python이나 JavaScript만큼 학습 데이터가 많지 않다

   1. 상대적 데이터 격차: AI가 접한 Flutter 자료는 Python·JavaScript에 비해 적으므로 Flutter 관용 패턴을 항상 정확히 고르지 못할 수 있다.
   2. Row·Column 반복: 기본적인 Row와 Column 사용법조차 에이전트에게 반복해서 알려 주거나 전용 레이아웃 스킬로 보강해야 한다.

2. 데이터 한계가 결과 전체를 막지는 않는다

   1. 구현 능력: Flutter 개발자가 AI로 멋진 앱을 만드는 경험 자체는 매우 좋다고 평가한다.
   2. 지침의 보완: 부족한 프레임워크 지식은 프로젝트 규칙과 작은 전문 스킬을 필요한 순간에 주입해 보완한다.

7.2. 한 코드베이스로 네 플랫폼 배포

1. Flutter는 한 번의 개발로 여러 플랫폼을 제공한다

   1. 배포 대상: 하나의 코드베이스에서 Android, iOS, Windows, macOS에 앱을 배포할 수 있다.
   2. 개발 선택: 게임 같은 앱을 만들 때도 네 플랫폼을 함께 겨냥할 수 있으므로 Flutter를 선택할 이유가 커진다.

2. AI와 Flutter의 결합은 산출량을 증폭한다

   1. 두 배의 가치: Flutter는 “두 개를 한 가격에(two for the price of one)” 제공한다는 표현처럼, 하나의 구현이 여러 플랫폼 결과로 이어진다.
   2. 종합 평가: AI의 빠른 구현과 Flutter의 멀티플랫폼 배포가 결합되면 개발자는 적은 반복으로 더 많은 제품 표면을 만들 수 있다.

주요 발언 모음

“스킬을 쓰기 시작할 가장 중요한 신호는 반복이다(The main indicator for starting to write your skill is repetition).”

“MD 파일은 실제로 그렇게 무해하지 않다(MD files are not that harmless actually).”

“그냥 자동화하지 말고, 실제로 어느 정도 통제권을 가져야 한다(Don’t just automate it, but actually have some control).”

“나는 세 대의 머신에서 병렬로 작업한다. 하나는 Claude, 하나는 Codex, 하나는 Antigravity를 실행한다(I work on three parallel machines).”

“Flutter는 두 개를 한 가격에 제공한다(Flutter gives you two for the price of one).”

핵심 데이터 & 수치

• 스킬 사용 기준 2가지: 반복 업무의 표준화와 반복되지 않는 워크플로우의 자동화가 핵심 도입 사례다.
• 공식 스킬 유지보수 주기: 커뮤니티 Flutter skills 저장소는 최소 2주마다 변경·업데이트·최적화 필요성을 점검한다.
• 추천 스킬 5가지: skill creator, code review, 프로젝트별 새 기능·엔드포인트 지원, Flutter 기본 레이아웃, 실제 스크린샷 QA가 제시된다.
• 코드 리뷰 경험 1년 이상: Ivana는 자신의 code review skill을 1년 넘게 사용했다.
• 병렬 머신 3대: Claude, Codex, Antigravity를 각각 실행하고 같은 프로젝트의 작업을 서로 인계한다.
• 멀티플랫폼 4종 이상: Android, iOS, Windows, macOS를 하나의 Flutter 코드베이스로 배포할 수 있다.
• 영상 길이 15분 28초: 스킬 설계·보안·추천 스킬·병렬 AI 워크플로우·Flutter의 장점이 압축적으로 이어진다.

결론 및 시사점

1. 프로젝트 지식과 과업 지식을 분리해야 한다: 모든 정보를 상시 로드하지 말고, 항상 필요한 규칙은 project rules에, 특정 작업에만 필요한 절차는 skill에 둔다.
2. 반복을 발견하는 즉시 스킬 후보로 삼아야 한다: 코드 리뷰처럼 반복되는 업무뿐 아니라 Google Ads 설치처럼 한 번뿐인 복잡한 작업도 재현 가능한 단계로 묶을 수 있다.
3. 스킬을 코드처럼 검증해야 한다: 공식 출처를 우선하고, 비공식 MD 파일은 prompt injection·숨은 Unicode·비밀정보 접근 가능성을 점검한다.
4. Skill creator는 시작점이지 승인 버튼이 아니다: AI가 SKILL.md, scripts, references, assets를 만들더라도 인간이 질문에 답하고 결과를 읽고 수정해야 한다.
5. 품질 검토를 서로 다른 에이전트에 분리해야 한다: code review와 PR triage를 다른 에이전트에 맡기고 보고서를 교차 확인하면 단일 모델의 사각지대를 줄일 수 있다.
6. Flutter 레이아웃 지식을 작은 스킬로 고정해야 한다: Row, Column, Wrap, Stack, Flexible, Expanded의 선택 기준을 알려 주면 하드코딩을 줄이고 반응형 UI를 일찍 확보할 수 있다.
7. 테스트 통과와 화면 품질을 분리해 확인해야 한다: 실제 웹 스크린샷이나 animated WebP를 이용한 시각 QA는 초록색 테스트만으로 놓치는 UI 결함을 발견한다.
8. AI 사용량을 생산성 지표로 착각하지 않아야 한다: 세 에이전트를 병렬로 돌리고 토큰을 소진하는 방식은 산출량을 높이지만, 지속 가능한 속도와 검토 시간을 함께 설계해야 한다.
9. Flutter의 멀티플랫폼성이 AI의 한계를 상쇄한다: 학습 데이터가 Python·JavaScript보다 적어도 한 코드베이스에서 Android·iOS·Windows·macOS를 겨냥하는 효과가 크다.

핵심 요약 (20줄)

AI 코딩 어시스턴트의 기본 프롬프트는 “이 버그를 고쳐 달라”처럼 현재 작업을 메시지로 지시하는 방식이다.

프로젝트 규칙은 모든 작업에 공통으로 필요한 지식을 하나의 Markdown 파일에 저장해 에이전트가 항상 읽도록 만든다.

스킬은 모든 지침을 상시 로드하지 않고 특정 과업에 필요한 절차와 자료만 선택적으로 불러오는 단위다.

스킬을 만들 가장 강한 신호는 코드 리뷰처럼 같은 절차를 반복해서 수행하는 상황이다.

반복되지 않는 Google Ads 설치 같은 큰 워크플로우도 한 번 자동화할 가치가 있으며 사용 후 제거할 수 있다.

인터넷에서 내려받은 MD 파일에는 에이전트를 조종하거나 키를 훔치게 만드는 prompt injection이 들어갈 수 있다.

공식 Google repository의 Flutter·Dart skills와 공식 패키지 유지관리자 스킬을 우선 사용해야 한다.

비공식 스킬은 정상적으로 보이는 텍스트뿐 아니라 숨은 Unicode 지침과 권한 범위까지 직접 검사해야 한다.

커뮤니티 Flutter skills 저장소는 새로운 repository를 운영하는 것처럼 최소 2주마다 변경과 업데이트를 점검한다.

Skill creator는 SKILL.md뿐 아니라 scripts, references, assets까지 만들어 스킬 제작 과정을 자동화한다.

AI가 생성한 스킬은 질문과 반복 개선을 거치고 인간이 내용을 검토·수정해야 안전하게 쓸 수 있다.

Ivana는 1년 넘게 code review skill을 사용하고 Kevin Moore의 PR triager skill과 교차 검토를 구성했다.

프로젝트별 새 백엔드 엔드포인트 지원 스킬은 페이지·내비게이션·스캐폴드·디자인 시스템을 반복해서 연결하는 일을 표준화한다.

Flutter의 Row, Column, Wrap, Stack 사용법을 작은 스킬로 고정하면 에이전트의 이상한 위젯 조합과 하드코딩을 줄일 수 있다.

실제 웹 스크린샷과 animated WebP를 활용한 QA는 코드와 테스트 결과만으로 발견하기 어려운 UI 결함을 보여 준다.

Ivana는 Claude, Codex, Antigravity를 세 대의 머신에서 병렬 실행하고 보통 같은 프로젝트의 작업을 서로 인계한다.

정규직 업무 이후 저녁과 주말에도 에이전트 팀을 운영해 RevenueCat Ship-a-ton 제출용 앱을 만들고 있다.

AI는 Ivana를 매우 생산적으로 만들었지만 남은 토큰을 모두 소진하려는 감각은 게임화된 과몰입으로 이어질 수 있다.

Flutter는 Python이나 JavaScript보다 학습 데이터가 적어 Row와 Column 같은 기본 레이아웃 지식을 반복해서 보강해야 한다.

Flutter는 하나의 코드베이스로 Android, iOS, Windows, macOS에 배포할 수 있어 AI와 결합할 때 멀티플랫폼 산출량을 크게 높인다.