cto-advisor
작성자 alirezarezvanicto-advisor는 아키텍처 의사결정, 기술 부채, 엔지니어링 지표, 기술 평가, 팀 확장, 전략 계획을 지원하는 CTO 리더십 skill입니다. ADR, DORA, 평가 프레임워크와 함께 부채 분석 및 팀 확장을 위한 Python tools를 포함합니다.
이 skill은 82/100점으로, 디렉터리에 등록하기에 충분히 탄탄한 후보입니다. 디렉터리 사용자는 명확한 트리거, 재사용 가능한 프레임워크, 실용적인 스크립트를 갖춘 잘 정리된 CTO advisory skill을 얻을 수 있습니다. 다만 설치 안내가 더 명확하고 CTO 상황별 실행 경로가 더 좁게 구분되어 있다면 도입이 한층 쉬울 것입니다.
- 트리거가 명확합니다. frontmatter description에서 기술 부채, 팀 확장, 아키텍처 결정, 기술 평가, 엔지니어링 지표, DORA metrics, 기술 전략 등 사용 사례를 구체적으로 제시합니다.
- 운영 지원이 잘 갖춰져 있습니다. SKILL.md의 상세 가이드와 함께 ADRs, 엔지니어링 지표, 기술 평가를 위한 참조 프레임워크가 포함되어 있습니다.
- 기술 부채 분석과 엔지니어링 팀 확장을 위한 두 가지 Python tools, 그리고 quick-start command 섹션을 제공해 일반 prompt보다 agent 활용도를 높입니다.
- skill 경로에 설치 명령이나 README가 제공되지 않아, 사용자는 더 넓은 repository 맥락에서 설치 방법을 유추해야 합니다.
- 범위가 CTO 전략, 아키텍처, 지표, 팀 확장, 기술 부채까지 넓기 때문에, 일반적인 리더십 조언에 그치지 않으려면 agent가 사용자별 맥락을 추가로 필요로 할 수 있습니다.
cto-advisor skill 개요
cto-advisor가 필요한 상황
cto-advisor는 복잡하게 얽힌 엔지니어링 이슈를 CTO 수준의 구조화된 판단으로 정리해 주는 기술 리더십 skill입니다. 아키텍처 의사결정, 기술 부채 우선순위, 엔지니어링 지표, 기술 평가, 팀 확장, 전략 계획처럼 단순한 코드 수준 조언이 아니라 트레이드오프, 실행 순서, 경영진에게 설명 가능한 논리가 필요한 상황에 가장 잘 맞습니다.
잘 맞는 사용자와 의사결정
cto-advisor skill은 무엇을 고치고, 만들고, 구매하고, 측정하고, 조직적으로 재정비할지 결정해야 하는 창업자, CTO, VP of Engineering, staff engineer, platform lead, 제품 관점이 있는 기술 관리자에게 적합합니다. 특히 일부 맥락만 있는 상황에서 유용합니다. 예를 들어 확장성 병목, 불명확한 아키텍처 선택지, 쌓여 있는 기술 부채, 또는 “12개월 기술 로드맵을 만들어 달라” 같은 리더십 요청이 있을 때 도움이 됩니다.
일반 프롬프트와 다른 점
일반 프롬프트는 넓은 범위의 추천을 내놓는 데 그칠 수 있습니다. 이 skill은 재사용 가능한 CTO 프레임워크를 더합니다. ADR 스타일의 의사결정 기록, DORA 및 생산성 지표, 기술 평가 매트릭스, 기술 부채 분류, 팀 확장 계산 같은 도구를 활용합니다. 실질적인 가치는 단순한 “조언”이 아니라, 엔지니어링의 모호함을 우선순위가 매겨진 선택지, 측정 가능한 리스크, 다음 액션으로 바꿔 준다는 데 있습니다.
cto-advisor가 가장 강한 영역
기술, 사람, 비용, 신뢰성, 배포 속도가 함께 얽힌 Strategic Planning 문제에는 cto-advisor를 사용하세요. 시스템 맥락, 현재 제약, 비즈니스 목표, 장애나 실패 증상을 제공할 수 있을 때 가장 강력합니다. 반대로 매우 세부적인 구현 디버깅, 특정 벤더에 깊게 종속된 튜닝, 권위 있는 검토가 필요한 법무/컴플라이언스 판단에는 상대적으로 약합니다.
cto-advisor skill 사용 방법
cto-advisor 설치와 먼저 읽을 파일
다음 명령으로 skill을 설치합니다.
npx skills add alirezarezvani/claude-skills --skill cto-advisor
설치 후에는 먼저 SKILL.md를 읽어 활성화 범위와 리더십 워크플로를 이해하세요. 이후 작업에 따라 아래 파일을 확인하면 됩니다.
- 아키텍처 선택과 ADR 출력 형식은
references/architecture_decision_records.md - DORA, 품질, 생산성, 신뢰성 지표는
references/engineering_metrics.md - build-vs-buy 또는 벤더 선택은
references/technology_evaluation_framework.md - 기술 부채 점수화 로직은
scripts/tech_debt_analyzer.py - 엔지니어링 인원 계획과 조직 구조 계획은
scripts/team_scaling_calculator.py
이 repository는 큰 런타임에 의존하지 않지만, 보조 스크립트가 Python 파일이므로 로컬에서 실행하려면 Python 3가 준비되어 있어야 합니다.
cto-advisor를 더 잘 쓰기 위한 입력값
이 skill은 프롬프트에 비즈니스 목표, 현재 엔지니어링 상태, 제약 조건, 검토 중인 선택지, 의사결정 기한이 포함될 때 가장 좋은 결과를 냅니다. 맥락 없이 “우리 아키텍처는 어떻게 해야 하나요?”라고 묻는 방식은 피하세요. 대신 의사결정의 기준이 되는 요소를 제공해야 합니다.
더 좋은 프롬프트 패턴:
Use cto-advisor to evaluate whether our SaaS platform should move from a modular monolith to services. Current team: 18 engineers, 2 platform engineers, weekly deploys, 99.5% uptime target, PostgreSQL bottlenecks, customer growth from 200 to 1,000 accounts in 12 months. Constraints: 6-month roadmap, limited DevOps capacity, compliance audit in Q3. Produce an ADR-style recommendation with options, risks, migration phases, and metrics to track.
이렇게 입력하면 skill이 유행하는 아키텍처 조언으로 기본값을 잡는 대신, 실제 트레이드오프를 따져 볼 만큼 충분한 정보를 갖게 됩니다.
의사결정을 위한 실무 워크플로
대부분의 리더십 의사결정에는 다음 4단계 워크플로를 사용하세요.
- 의사결정의 틀 잡기: 문제, 비즈니스 성과, 시간 범위, 절대 양보할 수 없는 제약을 정의합니다.
- 구조화된 분석 요청하기: 의사결정 성격에 따라 ADR, 기술 평가 매트릭스, 부채 개선 계획, 팀 확장 모델, 지표 대시보드를 요청합니다.
- 가정 검증하기: 결과가 장애 빈도, 배포 데이터, 팀 역량, 비용 추정치처럼 검증되지 않은 사실에 의존하는지 확인합니다.
- 실행으로 전환하기: 30/60/90일 계획, 담당자, 마일스톤, 리스크, 측정 가능한 성공 기준을 요청합니다.
기술 부채 작업의 경우 scripts/tech_debt_analyzer.py를 실행하거나 살펴보면서 아키텍처, 코드 품질, 인프라, 보안, 성능 전반에서 부채 카테고리가 어떻게 가중되는지 이해하세요. 팀 성장을 다룰 때는 제안된 역할 비율을 그대로 받아들이기 전에 scripts/team_scaling_calculator.py를 검토하는 것이 좋습니다.
수행하려는 작업별 프롬프트 예시
기술 부채의 경우:
Use cto-advisor to prioritize technical debt across architecture, infrastructure, security, and performance. Our main pain points are manual deployments, low test coverage, slow queries, and outdated dependencies. Create a severity-ranked remediation plan with business impact, effort, dependencies, and first 3 actions.
기술 평가의 경우:
Use cto-advisor to compare Kafka, RabbitMQ, and managed cloud queues for event-driven order processing. Include functional requirements, non-functional requirements, TCO, operational burden, team expertise, exit risk, and a scoring matrix.
엔지니어링 지표의 경우:
Use cto-advisor to design an engineering metrics dashboard for a 35-person product engineering org. Include DORA metrics, quality indicators, reliability metrics, measurement method, target ranges, and behaviors to avoid incentivizing.
cto-advisor skill FAQ
cto-advisor는 초보자에게도 적합한가요?
네, 완성된 경영 전략이 아니라 의사결정 프레임워크가 필요한 사용자라면 적합합니다. 초보자는 정의, 예시, 단계별 추론을 함께 요청하는 것이 좋습니다. 다만 추천 내용은 여전히 시스템, 조직, 비즈니스 제약을 이해하는 사람이 검토해야 합니다.
cto-advisor를 쓰지 말아야 할 때는 언제인가요?
보안 승인, 법적 컴플라이언스, 재무 예측, 프로덕션 아키텍처 최종 승인에는 cto-advisor를 최종 권위자로 사용하지 마세요. 분석을 구조화하고, 트레이드오프를 드러내며, 의사결정 기록 초안을 만드는 데는 도움이 되지만 실제 결정은 시스템 데이터, 이해관계자 의견, 전문가 검토로 검증해야 합니다.
cto-advisor는 아키텍처 skill과 어떻게 다른가요?
아키텍처 전용 skill은 보통 시스템 설계에 초점을 둡니다. cto-advisor skill은 아키텍처를 더 큰 리더십 의사결정의 한 요소로 다룹니다. 로드맵 정렬, 팀 역량, 기술 부채, 배포 지표, 채용 영향, 비용, 리스크, 거버넌스까지 함께 고려합니다. 그래서 단독 설계 다이어그램보다 여러 부서가 얽힌 계획 수립에 더 유용합니다.
소규모 팀과 스타트업에도 맞나요?
네. 소규모 팀은 과도한 엔지니어링을 피하고, build-vs-buy 선택지를 비교하고, 채용 계획을 세우며, 어떤 부채를 감수할지 결정하는 데 사용할 수 있습니다. 핵심은 스타트업의 제약을 명확히 밝히는 것입니다. 런웨이, 팀 규모, 고객 긴급도, 운영 허용 수준, 단순하게 유지해야 하는 영역을 구체적으로 적어야 합니다.
cto-advisor skill 개선 방법
더 선명한 맥락으로 cto-advisor 결과 개선하기
cto-advisor 결과를 가장 빠르게 개선하는 방법은 모호한 목표를 의사결정 가능한 맥락으로 바꾸는 것입니다. 현재 팀 규모, 아키텍처, 배포 주기, 장애 이력, 비용 한도, 고객 증가, 컴플라이언스 요구, 알려진 제약을 포함하세요. 지표가 없다면 없다고 말하고, 결정을 내리기 전에 어떤 데이터를 수집해야 하는지 skill에 식별해 달라고 요청하세요.
주의해야 할 흔한 실패 패턴
가장 큰 위험은 팀의 실제 역량에 비해 지나치게 이상적인 추천을 받는 것입니다. 현재보다 더 높은 platform 성숙도, 자동화 수준, 인력, 예산을 전제로 하는 계획인지 확인하세요. 또한 microservices, 무거운 거버넌스, 광범위한 지표 프로그램을 추천하면서도 이를 명확한 비즈니스 문제와 연결하지 않는 결과는 반드시 따져 봐야 합니다.
전략에서 실행으로 반복하기
첫 번째 결과를 받은 뒤에는 우선순위를 강제로 드러내는 후속 질문을 하세요.
What assumptions would change this recommendation?What is the smallest reversible next step?Which option is best if we optimize for 6-month delivery speed?Which risks need executive approval?Turn this into an ADR with negative consequences included.
이렇게 하면 cto-advisor 사용이 단발성 추천에서 끝나지 않고, 실제 의사결정 워크플로로 이어집니다.
repository 프레임워크와 스크립트로 검증하기
답변을 채택하기 전에 포함된 reference를 체크리스트처럼 사용하세요. 아키텍처 추천은 references/architecture_decision_records.md와, 지표 제안은 references/engineering_metrics.md와, 벤더 비교는 references/technology_evaluation_framework.md와 대조하세요. 정량적 계획의 경우 생성된 숫자를 권위 있는 값으로 받아들이기보다 Python 스크립트를 직접 살펴보거나 상황에 맞게 수정하는 것이 좋습니다.
