appllama-skills
무엇인가
appllama-skills는 모바일 앱 화면을 만드는 AI 코딩 에이전트에 '조사 → 카테고리 디자인 언어 추출 → 구현 → 시뮬레이터 검증'이라는 작업 순서를 주입하는 스킬 묶음이다. 단일 규칙 파일이 아니라 역할이 분리된 두 스킬로 구성된다. appllama-usage는 상위 매출 앱의 실제 화면·플로우·UI 패턴을 어떤 기준과 순서로 읽을지 결정하는 조사 엔진이고, appllama-app-design-skill은 그 결과를 네이티브 품질의 화면으로 옮기는 구현 규칙이다. 두 스킬은 한 쌍으로 설계되어, 조사만 하고 끝나는 리서치 결과물과 근거 없이 화면만 찍어내는 구현 결과물을 동시에 막는다. 규율 대상은 모바일 UI의 마감 품질, 화면 전환 구조, 온보딩과 페이월 배치, 모션 설계다. README가 못 박는 종료 조건은 하나다. 시뮬레이터에서 흠잡을 데 없는 화면이 나올 때까지 루프를 닫지 않는다. 화면 한 장을 만드는 것이 목적이 아니라, 그 화면이 이미 이기는 앱 옆에 놓여도 무너지지 않는 수준에 도달하는 것이 목적이다. 이 기준은 저장소 설명의 'builder, not just a researcher'라는 문장과 같은 뜻이다.
어떻게 동작하나
이 규칙이 없을 때 에이전트가 보이는 실패는 반복적이다. 첫째, 카테고리 관례를 무시한 일반적인 레이아웃을 만든다. 상위 앱이 이미 합의해 둔 정보 위계와 밀도를 참조하지 않으므로 화면은 '그럴듯하지만 어디서 본 듯한' 상태에 머문다. 둘째, 화면 전환 구조를 임의로 정한다. 푸시로 밀어야 할 화면을 시트로 띄우거나 그 반대로 처리하고, 결제가 끝난 뒤에도 뒤로 가기로 페이월에 다시 들어가는 경로를 남긴다. 셋째, 모션을 아무 스레드에나 붙인다. 삭제해야 할 애니메이션을 그대로 두고, 속도 곡선이 빠진 전환을 넣으며, 사용자가 조작하지 않았는데 움직이는 요소를 추가한다. 넷째, 검증 없이 완료를 선언한다. 코드가 빌드된다는 이유만으로 화면이 상위 앱과 비교 가능한 수준이라고 보고한다. 특히 페이월 재진입 경로는 매출 손실과 직결되는데, 에이전트는 화면 단위로만 판단하므로 플로우 전체를 보지 않으면 이 구멍을 남긴다. 조사 없이 시작한 구현은 마감 단계에서 색·간격·타이포를 임의로 조정하는 반복으로 이어지고, 그 조정은 다시 검증되지 않는다.
무엇과 다른가
규칙은 취향 목록이 아니라 결정의 형태로 쓰였다. 어떤 화면을 푸시로 열고 어떤 화면을 시트로 띄우는지, 온보딩의 각 단계가 무엇을 얻고 페이월이 어디에 앉는지를 에이전트가 문장으로 먼저 정하게 만든다. 결정을 강제하면 구현 전에 구조가 드러나고, 나중에 뒤집히는 비용이 줄어든다. 종료 조건을 시뮬레이터로 못 박은 것도 같은 이유다. '코드 작성 완료'는 판정 가능한 상태가 아니지만 '상위 앱 화면과 나란히 놓고 흠이 없는 상태'는 판정 가능하다. anti-slop 규율은 금지 목록이 아니라 기본값을 뒤집는 장치다. 그럴듯한 카드, 그라디언트, 과잉 그림자를 기본값으로 두지 않고 카테고리에서 실제로 관찰된 패턴만 근거로 채택한다. 호출당 1크레딧이 소모되고 get_credits만 무료라는 제약도 규칙 설계에 반영된다. 이 제약은 리서치를 게으르게 만드는 것이 아니라 관찰 항목을 미리 정하게 만들고, 무작정 많이 보는 대신 적은 호출로 판단을 끝내도록 조사 순서를 좁힌다.
어떻게 쓰나
배포 형태는 프롬프트가 아니라 디렉터리다. 각 스킬은 SKILL.md를 포함한 평범한 폴더로 배포되며, 프로젝트 단위로는 .claude/skills/, 사용자 전역으로는 ~/.claude/skills/에 복사하면 된다. 설치 명령은 npx skills@latest add appllama/appllama-skills이고, -a 플래그로 대상 에이전트를 지정하거나 -y로 확인 프롬프트를 생략하며, -g를 붙이면 프로젝트가 아닌 사용자 전역에 설치된다. --skill 플래그를 쓰면 두 스킬 중 하나만 설치할 수 있다. 스킬 본문에는 어떤 작업에서 발동하는지에 대한 설명이 포함되어, 에이전트가 모바일 화면 구현이나 화면 개선 요청을 만났을 때 해당 스킬을 작업 컨텍스트로 선택한다. appllama-usage는 Appllama MCP(https://mcp.appllama.io/mcp) 연결을 전제로 동작하고, appllama-app-design-skill은 MCP 없이도 단독으로 동작하되 연결 시 판정 근거가 구체해진다. MCP는 Claude, Cursor, Codex 등 MCP 클라이언트에 커스텀 커넥터로 추가하고 계정으로 승인한다.
전제와 한계
내부 구성은 두 스킬의 분업 위에 이름이 붙은 세 장치로 짜인다. appllama-usage는 조사 담당으로, 이기는 앱의 모든 화면을 어떤 순서로 읽고 카테고리의 디자인 언어를 어떤 형태로 뽑아낼지 정한다. appllama-app-design-skill은 구현 담당으로, 추출된 언어를 네이티브 품질 기준(native-quality build bar)에 맞춰 화면으로 옮긴다. 그 위에 anti-slop 규율과 full-motion 시뮬레이터 루프가 얹힌다. anti-slop은 채택 근거를 카테고리 관찰로 한정하는 필터이고, full-motion 루프는 정적 화면이 아니라 전환과 모션까지 포함한 상태를 검증 대상으로 삼는다. 입력 참조 방식도 규칙에 포함된다. 스크린샷, 코드, 또는 appllama.io의 'Copy Screen ID' 참조를 받아 화면 단위 개선을 수행하고, 모션 검토는 '삭제할 것 / 잘못된 스레드에 있는 것 / 속도(velocity)가 빠진 것'이라는 세 질문으로 고정된다. 호출 비용을 확인하는 get_credits도 절차의 일부로 들어간다.
프롬프트 직접 작성과의 차이는 적용 범위가 세션 밖에 남는다는 점이다. 좋은 지시문을 매번 복사해 넣는 방식은 세션이 끝나면 사라지고, 저장소에 커밋되어 팀이 같은 판정 기준을 공유하지 못한다. CLAUDE.md·AGENTS.md 같은 상시 규칙 파일과의 차이는 로드 조건이다. 상시 규칙은 모든 작업에 동일하게 걸리지만, 이 묶음은 두 스킬로 쪼개져 있어 조사가 필요한 작업과 구현이 필요한 작업에 각각 다른 규칙이 선택적으로 걸린다. 플러그인이나 MCP 서버와도 층이 다르다. MCP는 화면·플로우 데이터를 공급하는 통로이고, 스킬은 그 데이터를 어떤 순서로 읽고 무엇을 근거로 채택할지 정하는 판단 절차다. 데이터만 있고 절차가 없으면 에이전트는 조회 결과를 나열하는 데 그치고, 절차만 있고 데이터가 없으면 일반론으로 되돌아간다. 리서치 전용 에이전트와 갈리는 지점도 여기다. 조사 결과를 보고서로 끝내지 않고 시뮬레이터 검증까지 같은 루프에 묶는다.
실무에서는 요청 문장의 형태가 결과를 좌우한다. README가 제시하는 요청은 다섯 가지로 정리된다. 습관 트래커를 만들되 상위 앱을 먼저 조사하고 모든 화면이 시뮬레이터 비교를 통과할 때까지 멈추지 말라는 요청, 스크린샷·코드·화면 ID를 붙여 특정 화면을 개선하라는 요청, 상위 피트니스 앱의 온보딩 길이와 각 단계의 획득물, 페이월 위치를 묻는 조사 요청, 결제 플로우를 푸시와 시트로 어떻게 나눌지 정하고 결제 후 페이월 재진입을 막으라는 요청, 애니메이션에서 삭제·스레드 오배치·속도 누락을 지적하고 계획을 세우라는 요청이다. 첫 사용에서 확인할 항목은 세 가지다. 에이전트가 조사 단계를 건너뛰고 바로 코드로 가지 않는지, 완료를 선언할 때 시뮬레이터 확인을 근거로 대는지, 결제·온보딩 같은 플로우에서 화면 단위가 아니라 경로 전체를 검토하는지다. 이 확인 없이 완료 선언을 받아들이면 스킬은 형식만 남는다.
전제 조건은 분명하다. appllama-usage는 Appllama MCP 연결과 Pro 등급 계정을 요구하며, 크레딧은 매월 1일에 전액 리셋되고 호출마다 1크레딧이 차감된다. 조사 호출 계획 없이 루프를 돌리면 중간에 근거 공급이 끊기고, 이후 판정은 기억에 의존하게 된다. 지원 범위는 Claude Code를 포함해 Cursor, Codex 등 npx skills가 대상으로 삼는 70여 개 에이전트이며, 수동 설치 시에는 각 하네스의 스킬 디렉터리 관례를 따라야 한다. 스킬 선택 자체가 에이전트의 판단에 맡겨지는 구조이므로 어떤 작업에서도 자동 적용이 보장되지는 않는다. 라이선스는 MIT이나 Appllama 이름과 라마·로고는 상표로 남아 있어 사용 권한이 부여되지 않는다. 대상은 모바일 앱 화면과 그 플로우이며 README는 그 밖의 플랫폼을 다루지 않는다. 스킬은 코드를 실행하지 않으므로 최종 판정은 에이전트와 사람에게 남는다.
선택 기준은 산출물의 형태로 갈린다. 상위 앱의 관례를 근거로 삼아야 하는 신규 화면·플로우라면 두 스킬을 함께 둔다. 이미 그려진 화면 하나의 마감만 손보는 작업이라면 appllama-app-design-skill 단독으로 충분하다. 온보딩 길이, 페이월 위치, 화면 전환 방식처럼 구조 결정이 먼저인 질문은 appllama-usage로 시작해 결정을 문장으로 남긴 뒤 구현으로 넘긴다. MCP 연결이나 크레딧 운용이 어려운 환경이거나 판정 기준을 이미 팀 문서로 고정해 둔 경우에는 스킬 대신 그 문서를 상시 규칙 파일로 두는 편이 낫다. 웹·백엔드처럼 모바일 화면 밖의 작업에는 이 묶음이 겨냥하는 규율이 없으므로 다른 규칙을 쓴다. 기준은 하나로 모인다. 결과물을 상위 앱 옆에 놓고 비교해야 하는 작업이면 이 스킬을 쓰고, 그 비교가 성립하지 않는 작업이면 쓰지 않는다.