performance-optimization

performance-optimization 스킬 개요

performance-optimization 스킬이 하는 일

performance-optimization 스킬은 추측에 기대지 않고 앱 속도 문제를 진단하고 개선하기 위한, 측정 우선 워크플로입니다. 핵심 역할은 단순합니다. 먼저 프로파일링하고, 실제 병목을 찾아내고, 그 병목을 해결한 뒤, 결과를 검증하도록 돕는 것입니다. 그래서 막연한 “이거 더 빠르게 해줘” 식 프롬프트보다, 근거 있는 성능 개선 작업이 필요할 때 훨씬 실용적입니다.

누가 설치하면 좋은가

이 performance-optimization skill은 웹 앱, 프론트엔드, API, 데이터 집약적 기능을 다루며 지연 시간, 로드 속도, Core Web Vitals가 중요한 개발자, AI 보조 코더, 기술 리드에게 특히 잘 맞습니다. 이미 증상이나 요구사항이 분명할수록 적합합니다. 예를 들어 상호작용이 느리거나, LCP/INP/CLS가 좋지 않거나, 번들 크기가 크거나, 변경 이후 성능 회귀가 생겼거나, 트래픽에 민감한 코드 경로를 다뤄야 하는 경우입니다.

설치 전 실제로 따져볼 기준

performance-optimization은 마법 같은 즉답형 최적화가 아니라, 반복 가능한 최적화 프로세스를 원할 때 설치하는 스킬입니다. 가장 큰 차별점은 성급한 최적화를 분명히 경계하고, 판단의 중심에 증거를 둔다는 점입니다. 반대로 측정 없이 바로 적용할 수 있는 프레임워크별 튜닝 레시피만 원한다면, 이 스킬은 그 용도에는 다소 원칙적이고 엄격하게 느껴질 수 있습니다. 무엇부터 최적화해야 할지 결정하는 방법이 필요하다면 좋은 선택입니다.

performance-optimization 스킬 사용 방법

설치 맥락과 가장 먼저 읽어야 할 곳

performance-optimization skill을 사용하려면 AI 코딩 환경에 상위 스킬 컬렉션을 추가한 뒤, 측정 가능한 성능 목표가 포함된 작업에서 스킬 이름으로 호출하면 됩니다. 가장 먼저 skills/performance-optimization/SKILL.md를 읽는 것이 좋습니다. 이 저장소 경로가 중요한 이유는, 이 스킬이 자체 완결형이며 별도의 헬퍼 스크립트나 참고 리소스를 함께 제공하지 않기 때문입니다. 즉, 숨겨진 도구보다도 어떤 입력을 주느냐가 결과 품질을 더 크게 좌우합니다.

스킬이 잘 작동하려면 어떤 입력이 필요한가

좋은 performance-optimization 활용은 막연한 불만이 아니라 증거에서 시작합니다. 다음 정보를 함께 주는 것이 좋습니다.

• 영향을 받는 페이지, 라우트, 기능, 또는 엔드포인트
• 현재 지표 값 또는 체감 증상
• 그 값을 어떤 방식으로 측정했는지
• 환경 정보: 기기, 브라우저, 네트워크, 데이터셋 크기, production인지 local인지
• 성능 회귀가 의심된다면 최근 변경 사항
• “프레임워크 마이그레이션 불가”, “SEO 유지 필수” 같은 제약 조건

좋은 입력 예시:

Use performance-optimization for our product page. Mobile LCP is 4.1s in Chrome, CLS is 0.18, and users report delayed hero rendering on 4G. We recently added a carousel and a third-party review widget. Please identify likely bottlenecks, suggest measurement steps, rank fixes by expected impact, and tell me how to verify improvement.

부족한 입력 예시:

Make my site faster.

모호한 목표를 쓸 만한 프롬프트로 바꾸는 방법

좋은 performance-optimization 가이드형 프롬프트는 보통 다음 구조를 따릅니다.

1. 목표 지표 또는 사용자 불만을 먼저 밝힙니다.
2. 기준선 수치를 제공합니다.
3. 범위를 명확히 지정합니다.
4. 코드 또는 아키텍처 맥락을 공유합니다.
5. 우선순위가 매겨진 해결책과 검증 단계를 요청합니다.

예시:

Apply the performance-optimization skill to our React checkout flow. INP is ~320ms on mid-range Android during quantity changes. The page renders a large cart list, coupon validation runs on input, and analytics fire on every interaction. Help me measure the hot path, isolate the interaction bottleneck, propose code-level fixes, and define a before/after verification checklist.

실전 워크플로와 기대할 수 있는 출력

실무에서는 이 스킬을 보통 네 단계로 나눠 쓰면 좋습니다. 기준선 파악, 병목 분리, 해결안 설계, 검증입니다. 이때 가설과 확인된 사실을 구분해서 답하도록 요청하세요. 이미 프로파일링을 해두었다면 trace, Lighthouse 결과, DevTools 분석 내용, flamegraph 요약을 그대로 붙여 넣는 편이 좋습니다. 아직 측정하지 않았다면, 먼저 프로파일링 계획부터 설계해 달라고 요청하세요. 이것이 performance-optimization 설치 판단에서 가장 중요한 품질 레버입니다. 이 스킬은 실제 측정값과 저장소 맥락이 함께 있을 때 가장 가치가 크며, 그것들을 대신해 주는 도구는 아닙니다.

performance-optimization 스킬 FAQ

일반적인 “성능 최적화해줘” 프롬프트보다 나은가

대체로 그렇습니다. 목표가 신뢰할 수 있는 의사결정이라면 특히 더 그렇습니다. performance-optimization skill은 측정 → 원인 식별 → 수정 → 검증이라는 더 강한 기본 워크플로를 제공합니다. 일반 프롬프트는 실제 병목이 무엇인지 확인하기도 전에 캐싱, memoization, lazy loading, code splitting 같은 기법부터 나열하는 경우가 많습니다.

웹 성능과 Core Web Vitals에만 쓰는 스킬인가

아닙니다. 다만 이 스킬은 사용자 체감 성능 신호를 분명히 중시하고, Core Web Vitals 목표를 직접 언급합니다. 그래서 프론트엔드와 페이지 속도 개선에 가장 자연스럽게 맞지만, “느리다”의 정의를 명확히 하고 측정할 수만 있다면 백엔드 지연, 데이터 처리 병목, 성능 회귀 같은 문제에도 같은 프로세스를 적용할 수 있습니다.

performance-optimization을 쓰지 말아야 할 때는 언제인가

문제의 증거가 전혀 없는 상태라면, performance-optimization for Performance Optimization을 첫 대응으로 쓰지 않는 편이 맞습니다. 실제 느려짐도 없고, 성능 예산도 없고, SLA도 없고, 사용자 불만도 없다면 이 스킬 자체의 관점에서도 최적화 작업을 권하지 않습니다. 또한 벤치마킹 자동화나 프레임워크 전용 스크립트가 기본 포함된 구성을 기대한다면 적합도가 낮습니다. 저장소가 그런 보조 자산을 제공하지 않기 때문입니다.

performance-optimization 스킬을 더 잘 활용하는 방법

요청을 넓히기보다, 근거를 더 날카롭게 주기

performance-optimization 결과 품질을 가장 빨리 끌어올리는 방법은 범위를 좁히고 지표를 더 분명하게 제시하는 것입니다. “모바일 checkout page, LCP 3.8s, 이미지와 폰트 이슈 가능성 높음” 같은 요청은 “앱 전체가 느리다”보다 훨씬 좋은 결과를 냅니다. 가능하다면 스크린샷, 프로파일러 메모, 번들 리포트, 요청 waterfall, 최근 커밋도 함께 주세요. 관측 가능한 사실이 있을수록 스킬의 추론 정확도도 높아집니다.

performance-optimization에서 자주 생기는 실패 패턴 주의하기

가장 흔한 실패 패턴은 병목을 확인하기도 전에 해결책부터 요구하는 것입니다. 또 하나는 너무 많은 증상을 한 번에 섞는 경우입니다. 시작 속도 저하, 상호작용 지연, API latency는 대개 서로 다른 방식으로 조사해야 합니다. “가능한 최적화를 전부 알려줘” 같은 요청도 피하는 것이 좋습니다. 이런 요청은 우선순위 있는 실행안이 아니라, 어디서나 볼 수 있는 일반론적 목록으로 흐르기 쉽습니다. 기대 효과, 구현 비용, 검증 방법 기준으로 순위를 매긴 해결안을 요청하세요.

첫 답변 이후 반드시 반복 개선하기

첫 번째 답변을 받은 뒤에는 결과를 가지고 다시 돌아오는 것이 좋습니다. 예를 들어 “We deferred the widget script and LCP improved from 4.1s to 3.2s, but INP is unchanged.”처럼요. 이렇게 해야 performance-optimization skill이 이론 수준의 조언에서 벗어나, 실제 결과를 반영한 반복 개선 단계로 넘어갈 수 있습니다. 가장 좋은 워크플로는 순환형입니다. 기준선을 잡고, 의미 있는 변수를 하나 바꾸고, 다시 측정한 뒤, 추측성 수정 10개를 한꺼번에 적용하기보다 다음으로 영향이 큰 개선 항목을 묻는 방식입니다.