python-performance-optimization

python-performance-optimization 스킬 개요

python-performance-optimization 스킬이 하는 일

python-performance-optimization 스킬은 Python 코드가 왜 느리거나 메모리를 많이 쓰는지 진단하고, 추측이 아니라 프로파일링 결과에 근거해 정확한 개선안을 제시하도록 돕습니다. 이 스킬은 실무 성능 개선에 맞춰 설계되어 있어, 병목을 찾고, CPU·메모리·I/O 문제를 구분하고, 실제 부하가 걸리는 코드 경로에 맞는 최적화 방법을 고르는 데 강합니다.

누가 설치하면 좋은가

이 스킬은 “이거 좀 빠르게 해줘” 수준의 일반적인 조언으로는 부족한 개발자, 데이터 엔지니어, 백엔드 팀, 그리고 에이전트 워크플로에 특히 잘 맞습니다. 이미 기능적으로는 동작하는 스크립트, 서비스, 노트북, 파이프라인이 있는데 지연 시간, 처리량, 메모리 사용 특성을 더 좋게 만들어야 할 때 특히 유용합니다.

실제로 해결해 주는 일

대부분의 사용자는 Big O 설명만 필요한 것이 아닙니다. 실제로 필요한 것은 다음 질문에 반복 가능하게 답하는 방식입니다:

• 무엇이 느린가
• 어떻게 제대로 측정할 것인가
• 어떤 최적화를 먼저 하는 것이 가치가 큰가
• 병목이 아닌 코드는 어떻게 건드리지 않을 것인가

바로 이 지점에서 python-performance-optimization 스킬은 일반 프롬프트보다 강합니다. 이 스킬은 워크플로를 “최적화 먼저”가 아니라 “프로파일링 먼저”로 이끕니다.

이 스킬이 다른 이유

이 저장소는 성능을 하나의 문제로 뭉뚱그리지 않고, 여러 프로파일링 방식과 최적화 계층을 함께 다룹니다. 범위는 다음을 포함합니다:

• CPU 프로파일링
• 메모리 프로파일링
• 라인 단위 분석
• 호출 그래프 관점의 분석
• 캐싱 같은 구현 패턴
• NumPy 벡터화, async I/O, 병렬화 같은 고급 경로

실질적인 차별점은 넓은 범위를 다루면서도 “프로파일링 우선”이라는 관점을 일관되게 유지한다는 점입니다.

잘 맞는 경우와 잘 맞지 않는 경우

잘 맞는 경우:

• 느린 Python 엔드포인트, 작업, CLI 도구, ETL, 데이터 처리
• 메모리 증가나 설명되지 않는 RAM 급증
• 캐싱, 알고리즘 변경, 벡터화, 동시성 중 무엇을 선택할지 판단해야 할 때
• 운영 코드 수정 전에 최적화 계획을 세워야 할 때

잘 맞지 않는 경우:

• 실제 병목이 인프라, 네트워크 토폴로지, 데이터베이스 스키마에 있는데 측정값이 전혀 없는 코드베이스
• 바로 실행 가능한 완전 자동 벤치마킹 스크립트를 기대하는 팀
• 성능 진단이 아니라 코드 스타일 정리만 원하는 상황

python-performance-optimization 스킬 사용 방법

python-performance-optimization 설치 맥락

wshobson/agents 저장소에서 스킬을 설치하세요:

npx skills add https://github.com/wshobson/agents --skill python-performance-optimization

설치 후에는 프롬프트가 Python 성능 진단, 프로파일링, 메모리 사용량, 지연 시간 감소, 처리량 개선, 병목 분석과 명확히 관련될 때 사용하면 됩니다.

먼저 읽어야 할 저장소 파일

가장 빨리 이해하려면 다음 순서로 시작하세요:

1. plugins/python-development/skills/python-performance-optimization/SKILL.md
2. plugins/python-development/skills/python-performance-optimization/references/advanced-patterns.md

SKILL.md에는 핵심 워크플로와 도구 분류가 정리되어 있습니다. references/advanced-patterns.md는 1차 진단 결과가 벡터화, 캐싱, 메모리 튜닝, async I/O, 데이터베이스 중심 작업 쪽을 가리킬 때 두 번째로 읽기 좋습니다.

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

python-performance-optimization usage의 품질은 사용자가 제공하는 근거에 크게 좌우됩니다. 가능하면 에이전트에게 다음을 주세요:

• 느린 함수, 파일, 엔드포인트, 또는 작업
• 예상 워크로드 크기
• 실제 증상: 지연 시간, CPU 포화, 메모리 증가, 타임아웃, 높은 쿼리 수
• 가능하다면 프로파일링 결과
• 제약 조건: 의존성 추가 불가, API 유지 필수, 운영 환경 안전성만 허용 등
• 환경 정보: Python 버전, 프레임워크, OS, 단일 프로세스인지 멀티프로세스인지

이런 입력이 없더라도 스킬이 프로파일링 절차 자체는 제안할 수 있지만, 권장안은 훨씬 덜 구체적일 수 있습니다.

막연한 요청을 강한 프롬프트로 바꾸기

약한 프롬프트:

• “Optimize this Python code.”

더 나은 프롬프트:

• “Use the python-performance-optimization skill to analyze this Django view. P95 latency is 1.8s under ~200 requests/min. CPU is high, memory is stable. Here is the view code and a cProfile summary. Identify the top bottlenecks, explain whether the issue is Python execution, DB access, or serialization, and propose fixes ranked by expected impact and implementation risk.”

이 방식이 더 잘 작동하는 이유는 워크로드, 증상 유형, 근거, 원하는 출력 형식을 함께 제공하기 때문입니다.

코드 수정 요청보다 먼저 진단을 요청하기

좋은 워크플로는 보통 다음 순서입니다:

1. 성능 증상을 설명한다
2. 코드와 측정 데이터를 제공한다
3. 에이전트에게 병목 유형 분류를 요청한다
4. 그다음에야 코드 변경을 요청한다

이렇게 하면 너무 이른 리라이트를 피할 수 있습니다. python-performance-optimization skill은 메트릭에서 개입 지점까지 추론할 수 있을 때 훨씬 더 유용합니다.

결과 품질을 크게 높여 주는 프로파일링 입력

특히 좋은 입력은 다음과 같습니다:

• CPU 부하가 큰 코드에 대한 cProfile 요약
• 핫 함수에 대한 line-profiler 결과
• RAM 문제에 대한 memory-profiler 결과나 객체 증가 증거
• I/O, DB, HTTP, 직렬화 경계별 시간 분해 결과
• 장난감 입력이 아닌 대표성 있는 샘플 데이터

아직 측정값이 없다면, 무작정 최적화를 시키기보다 먼저 프로파일링 계획을 설계해 달라고 요청하는 편이 낫습니다.

이 스킬이 지원하는 전형적인 워크플로

실무적인 python-performance-optimization guide는 보통 이렇게 진행됩니다:

1. 성능 목표를 정의한다
2. 맞는 프로파일링 유형을 고른다
3. 대표 워크로드로 프로파일링한다
4. 가장 뜨거운 경로나 가장 큰 할당 지점을 찾는다
5. 위험은 낮고 효과는 큰 최적화를 고른다
6. 변경 전후를 벤치마크한다
7. 정확성과 가독성 회귀를 점검한다

이 순서 자체가 이 스킬의 핵심 가치입니다.

고급 레퍼런스를 봐야 하는 시점

병목이 아래 영역 중 하나에 있을 가능성이 높다면 references/advanced-patterns.md를 여세요:

• NumPy 적용 가능성이 있는 수치 계산 루프
• functools.lru_cache가 도움이 될 수 있는 반복적인 순수 함수 작업
• async 패턴이 유리할 수 있는 높은 I/O 워크로드
• multiprocessing이 효과적일 수 있는 비용 큰 병렬 가능 작업
• 데이터베이스 최적화 관점이 필요한 쿼리 중심 애플리케이션

다만 범주를 이미 알고 있는 경우가 아니라면 처음부터 여기로 뛰어들지는 마세요. 측정된 병목에서 출발하는 것이 우선입니다.

흔한 사례별 좋은 프롬프트 패턴

CPU 바운드 코드라면:

• “Use the python-performance-optimization skill to review this function and cProfile output. Focus on algorithmic complexity, repeated work, and Python-level loop overhead.”

메모리 문제라면:

• “Use the python-performance-optimization skill to inspect this batch job. RSS climbs from 400MB to 3GB. Suggest likely retention causes, profiling steps, and memory-safe refactors.”

I/O 중심 서비스라면:

• “Use the python-performance-optimization skill on this async API client. Requests are slow despite low CPU. Determine whether the bottleneck is blocking I/O, connection handling, serialization, or concurrency limits.”

어떤 결과를 기대할 수 있는가

다음 영역에서 특히 강한 결과를 기대할 수 있습니다:

• 적절한 프로파일링 접근법 선택
• 흔한 성능 패턴 해석
• 실현 가능성이 높은 최적화를 우선순위와 함께 제안
• 캐싱, 벡터화, 병렬화, 코드 단순화 사이의 트레이드오프 설명

반대로 코드도 없고, 워크로드 형태도 없고, 측정값도 없다면 결과 품질은 떨어질 가능성이 큽니다.

python-performance-optimization 스킬 FAQ

Performance Optimization 용도로는 일반 프롬프트보다 python-performance-optimization이 더 나은가요?

대체로 그렇습니다. 즉흥적인 제안이 아니라 구조화된 진단이 필요할 때 특히 그렇습니다. 일반 프롬프트는 곧바로 “캐시를 쓰세요” 또는 “NumPy를 쓰세요”로 넘어가기 쉽습니다. 반면 python-performance-optimization 스킬은 먼저 CPU, 메모리, I/O, 알고리즘 문제를 분리해서 보려는 경향이 더 강합니다.

초보자도 쓰기 쉬운가요?

네, 코드와 증상을 공유할 수 있다면 충분히 시작할 수 있습니다. 처음부터 프로파일링 전문가일 필요는 없습니다. 다만 초보자일수록 구체적인 근거를 제공하고, 수정안을 내기 전에 왜 그 병목이 중요한지 설명해 달라고 요청할 때 결과가 훨씬 좋아집니다.

사용 전에 꼭 프로파일링 결과가 있어야 하나요?

아니요. 하지만 있으면 python-performance-optimization usage 품질이 훨씬 좋아집니다. 아직 측정값이 없다면, 무엇을 어떤 도구 범주로 프로파일링해야 하는지 정확히 알려 달라고 에이전트에게 요청하세요.

언제는 이 스킬을 쓰지 않는 것이 좋나요?

문제가 Python 애플리케이션 로직 바깥에 분명히 있을 때는 건너뛰는 편이 낫습니다. 예를 들면:

• 인프라 리소스 부족
• 네트워크 문제
• 앱 레벨 근거 없이 데이터베이스 서버 설정이 잘못된 경우
• Python 백엔드 실행과 무관한 프론트엔드 지연

이런 경우에도 조사 방향을 잡는 데는 도움이 될 수 있지만, 1차 도구로는 적합하지 않습니다.

속도뿐 아니라 메모리도 다루나요?

네. 이 저장소는 CPU 프로파일링과 실행 시간 분석뿐 아니라 메모리 프로파일링과 메모리 최적화도 명시적으로 다루고 있어서, 단순히 “속도만” 보는 프롬프트보다 활용도가 높습니다.

데이터 워크로드에도 도움이 되나요?

네. 특히 벡터화, 배치 처리, 캐싱, Python 루프 오버헤드 감소가 개선 경로가 될 수 있을 때 유용합니다. 수치 계산 및 데이터 처리 코드라면 고급 레퍼런스의 관련성이 특히 높습니다.

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

소스 코드만이 아니라 벤치마크 근거를 함께 주기

python-performance-optimization 결과를 개선하는 가장 좋은 방법은 다음을 제공하는 것입니다:

• 변경 전후 시간 측정
• 프로파일링 요약
• 샘플 입력 크기
• 처리량 또는 지연 시간 목표

소스 코드만 있으면 에이전트는 가설을 세울 수밖에 없습니다. 측정값이 있으면 우선순위를 잡을 수 있습니다.

의심하는 병목 유형을 명시하기

확신이 없어도, 어떤 문제라고 생각하는지 말해 주세요:

• CPU-bound
• memory-bound
• database-bound
• network/I/O-bound
• startup-time problem
• batch throughput problem

이 정보는 스킬이 더 적절한 진단 경로를 고르고, 뻔한 조언으로 흐르는 것을 막는 데 도움이 됩니다.

현실적인 제약 조건 포함하기

최적화 조언은 제약 조건에 따라 크게 달라집니다. 아래처럼 직접 적어 주세요:

• cannot change public API
• cannot add NumPy
• must remain readable for junior team
• must run on AWS Lambda
• must preserve deterministic ordering
• multi-tenant memory ceiling is fixed

이런 정보는 막연하게 “최고 성능”을 요청하는 것보다 의사결정 품질을 훨씬 더 높여 줍니다.

우선순위가 매겨진 권장안을 요청하기

좋은 프롬프트는 에이전트에게 다음 기준으로 제안을 순위화해 달라고 요청합니다:

1. 기대 효과
2. 구현 노력
3. 정확성 리스크
4. 의존성 비용

이렇게 해야, 반복 작업 제거 또는 비효율적인 쿼리 수정 같은 단순한 이득보다 더 복잡한 변경을 먼저 권하는 흔한 실패를 막을 수 있습니다.

흔한 실패 패턴을 경계하기

python-performance-optimization skill의 효과를 약하게 만드는 요인에는 다음이 있습니다:

• 핫 패스가 아닌 코드를 최적화하는 경우
• 운영 워크로드와 맞지 않는 마이크로벤치마크를 사용하는 경우
• 유지보수 가능한 코드보다 영리해 보이는 코드를 더 높게 평가하는 경우
• 실제로는 I/O나 GIL 특성상 맞지 않는데 multiprocessing을 적용하는 경우
• 무효화 전략이나 메모리 비용 논의 없이 캐싱을 권하는 경우

각 최적화안이 측정된 병목과 어떻게 연결되는지 근거를 제시해 달라고 요청하세요.

첫 답변 이후 한 번 더 반복하기

좋은 2차 프롬프트의 예시는 다음과 같습니다:

• “Here is the updated code and new benchmark. The runtime dropped from 2.4s to 1.5s, but memory increased by 35%. Re-run the python-performance-optimization analysis and suggest the next best change with minimal memory growth.”

이렇게 하면 이 스킬을 일회성 리라이트 도구가 아니라, 반복적인 최적화 루프로 활용할 수 있습니다.

저장소 읽기 경로를 전략적으로 활용하기

첫 답변이 너무 일반적이라면, 에이전트에게 다음 파일을 근거로 추론하라고 명시하세요:

• 프로파일링 분류와 워크플로는 SKILL.md
• 벡터화, 캐싱, 메모리 관리, 병렬화, async I/O, 벤치마킹 같은 구현 옵션은 references/advanced-patterns.md

이렇게 하면 답변의 구체성이 대체로 높아집니다.

도입이 막혀 있다면 측정 계획부터 요청하기

막히는 지점이 “어디서부터 시작해야 할지 모르겠다”라면, 최소한의 계획을 요청하세요:

• 가장 먼저 무엇을 측정할지
• 어떤 프로파일러 범주가 맞는지
• 타이머를 어디에 넣어야 하는지
• 어떤 워크로드를 재현해야 하는지
• 어떤 성공 지표를 쓸지

이 단계에서는 python-performance-optimization guide를 이런 식으로 활용하는 것이 팀에 가장 큰 가치를 주는 경우가 많습니다.