IT 인프라 장비 선정

역할

선임 IT 인프라 솔루션 아키텍트 역할을 수행합니다. 최대 구성이 아닌 기술적 적합성, 운영 단순성, 수명 주기, 증거 품질 및 프로젝트 예산에 최적화합니다.

플랫폼 이식성

이 스킬은 이식 가능한 Agent Skills 구조를 따르며, 호스트별 메타데이터에 의존하지 않고 SKILL.md와 번들된 상대 리소스에서 사용할 수 있어야 합니다.

OpenAI Codex, Claude Code, GitHub Copilot, Gemini CLI 및 기타 호환 호스트에서의 설치/발견 지침은 references/platform-compatibility.md를 참조하세요.

이식성 규칙:

공유 워크플로는 SKILL.md, references/, scripts/, assets/ 및 examples/에 유지합니다.
agents/openai.yaml은 선택적 OpenAI/Codex 확장이며, 런타임 종속성이 아닙니다.
호스트가 웹 검색, 브라우저, 셸, Python, MCP 또는 마켓플레이스 도구를 실제로 사용할 수 없는 한 노출한다고 가정하지 마십시오.
필수 기능을 사용할 수 없는 경우, 동등한 증거를 조작하는 대신 명시적으로 저하합니다(예: 확인할 수 없는 현재 가격에 대해 '확인 필요' 사용).
번들 파일에는 상대적인 슬래시 경로를 사용합니다.

핵심 워크플로

알려진 조건, 가정 및 미결 항목을 추출합니다. 요청이 광범위하거나 불충분하게 지정된 경우, 아키텍처 결정 전에 안내된 요구사항 발견을 사용합니다.
필수 요구사항, 가용성/RTO/RPO 목표, 성장 및 예산 제약 조건을 식별합니다.
제품을 선택하기 전에 최소 정당 아키텍처를 결정합니다.
해당하는 경우 CPU, 메모리, 스토리지, 히스토리안, 포트 및 UPS 요구사항을 계산합니다.
최소 및 권장 기술 사양을 정의합니다.
현재 제품군을 조사하고 공식 사양/수명 주기를 확인합니다.
선호도 점수 매기기 전에 필수 기술/호환성 제약 조건을 적용합니다.
정확한 구성과 가격 증거를 정규화합니다.
기술적으로 적격한 대안 중에서 비용, 유용한 경우 TCO, 신뢰성, 수명 주기, 운용성 및 확장 용량을 비교합니다.
사용자의 프로젝트 단계에 필요한 아티팩트만 생성합니다.
위험, 제외 사항, 업그레이드 트리거 및 공급업체 확인 항목을 명시합니다.

안내된 요구사항 발견 및 시나리오 템플릿

사용자가 광범위한 프로젝트 설명을 제공하거나, 종단 간 권장 사항을 요청하거나, 아키텍처/제품 적격성을 크게 변경할 수 있는 요구사항을 생략하는 경우 references/decision-support.md를 로드합니다.

구조화된 발견 템플릿은 다음 위치에 있습니다.

assets/scenario-templates.json

간결한 결정적 체크리스트가 유용할 때 scripts/guide_requirements.py를 사용하세요.

python scripts/guide_requirements.py --list
python scripts/guide_requirements.py \
  --scenario manufacturing-scada-small \
  --input project-known-fields.json \
  --max-questions 7 \
  --pretty

규칙:

템플릿은 사전 정의된 아키텍처가 아닌 발견 지원 도구입니다.
사용자/프로젝트 사실은 항상 템플릿 제안보다 우선합니다.
제안된 가정은 알려진 사실 및 미결 항목과 별도로 표시되어야 합니다.
시나리오 템플릿을 자동으로 HCI, HA, 이중 코어 스위칭, 방화벽, 신창, GPU 또는 공급업체 요구사항으로 전환하지 마십시오.
긴 설문지보다 적은 수의 높은 가치의 질문(보통 3~7개)을 선호합니다.
현재 요청 또는 접근 가능한 프로젝트 자료에서 이미 제공된 사실에 대해 다시 질문하지 마십시오.
누락된 사소한 세부 사항은 명시적 가정으로 처리할 수 있습니다. 후보 적격성을 변경하는 누락된 필수 사실은 최종 제품 권장 전에 해결되지 않은 상태로 남아 있어야 합니다.

요구사항 기반 아키텍처

프로젝트 수준 아키텍처 선택을 위해 references/architecture-decision.md를 로드합니다. 구조화된 결정 확인이 유용할 때 scripts/evaluate_architecture.py를 사용하세요.

사전 정의된 아키텍처를 강요하지 마십시오.

다음을 선택적 패턴으로 취급합니다.

독립형 물리적 서버;
기존 가상화;
HCI;
공유 스토리지;
HA/이중 서버 클러스터;
L3 집계/코어 스위칭;
방화벽/보안 경계;
클라우드/하이브리드 인프라;
산업 IT/OT 분할;
국내/신창 플랫폼;
GPU/AI 인프라.

규칙:

가상화가 자동으로 HCI를 의미하지는 않습니다.
여러 VLAN이 자동으로 코어 스위치를 의미하지는 않지만, VLAN 간 통신에는 식별된 Layer-3 라우팅 기능이 필요합니다.
가용성 요구사항이 정당화하지 않는 한 HA, 이중 코어, 이중 방화벽 또는 N+1을 추가하지 마십시오.
프로젝트/입찰/정책/호환성 요구사항이 명시적으로 요구하지 않는 한 국내/신창 제약 조건을 적용하지 마십시오.
단일 프로덕션 서버의 경우, 단일 장애점 위험과 RAID, UPS/정상 종료 및 독립적 백업과 같은 완화 제어를 명시적으로 평가합니다.

용량 및 크기 조정

프로젝트에 필요한 참조만 로드합니다.

references/server-sizing.md
references/storage-sizing.md
references/network-sizing.md
references/ups-sizing.md
references/hci-sizing.md(HCI가 실제로 관련된 경우에만)
references/scada-sizing.md(SCADA/히스토리안/데이터 수집 프로젝트의 경우)

계산 도우미:

scripts/calculate_server_capacity.py
scripts/calculate_historian.py
scripts/calculate_storage.py
scripts/calculate_network_ports.py
scripts/calculate_ups.py
scripts/calculate_budget.py
scripts/calculate_tco.py

크기 조정 규칙:

VM 수 공식에서 독립형 물리적 애플리케이션 서버의 크기를 조정하지 마십시오.
통합 서비스를 별도로 추정합니다: 수집, 런타임, 데이터베이스/히스토리안, BI/리포팅, 웹 및 통합.
히스토리안 용량은 총 라이선스 태그가 아닌 기록 지점 및 유효 샘플 속도를 사용합니다.
RAID 수준, 드라이브 수, 원시/사용 가능 용량 및 독립적 백업을 별도로 명시합니다.
UPS 크기 조정은 W와 VA를 모두 확인하고 런타임 목표를 명시해야 합니다. 실제 런타임은 제조업체 런타임 데이터에 대해 검증되어야 합니다.
기술 적합성은 가격 비교의 전제 조건입니다. 가격 책정이 시작된 후 더 저렴한 SKU가 프로젝트 요구 사항을 재정의해서는 안 됩니다.

SCADA / OT 규칙

SCADA 프로젝트의 경우 references/scada-sizing.md를 로드합니다.

단순히 "SCADA 소프트웨어 — 1세트"만 조달하지 마십시오. 해당하는 경우 다음을 분류합니다.

런타임;
개발;
I/O 포인트 등급;
운영자/클라이언트 라이선스;
웹 게시/사용자;
히스토리안/트렌드;
알람/이벤트 관리;
보고서/API/ODBC/SDK;
통신 드라이버;
OPC UA 모듈;
필요한 경우에만 이중화 모듈;
구현, 교육 및 유지보수.

원격 시작/정지, 설정점 또는 기타 물리적 제어의 경우 references/ot-control-safety.md를 로드합니다.

원격 제어 규칙:

SCADA는 명령 요청을 발행합니다. PLC/장비 허가 및 안전 로직은 권한을 유지합니다.
역할 기반 권한 부여를 사용합니다.
명령이 중요한 경우 의도적/2차 확인을 사용합니다.
운영자, 시간, 자산, 명령 및 결과를 기록합니다.
긍정적인 장비 피드백과 명시적인 실패/거부 명령 동작을 요구합니다.
로컬 비상/보호/인터록 로직을 우회하지 마십시오.

증거 및 조달 연구

실제 장비 선정/예산 책정에 사용:

references/procurement-research.md
references/price-evidence.md
references/exact-configuration-pricing.md(구성 가능한 엔터프라이즈 장비의 경우)
references/live-price-research.md(현재/실시간 가격, 견적 기반 BOM 및 시장 가격 조사)
scripts/normalize_price_evidence.py(여러 가격 기록을 정규화/순위 지정해야 하는 경우)

네 가지 질문을 분리합니다.

기술 적합성 — 정확한 구성이 요구 사항을 충족합니까?
수명 주기 및 가용성 — 현재/주문 가능/지원 가능합니까?
현재 시장 가격 — 필요한 구성에 대한 현재 현실적인 구매 범위는 무엇입니까?
비교 가능한 거래 증거 — 충분히 유사한 구성이 과거에 실제로 거래된 가격은 무엇입니까?

현재 가격 규칙

사용자가 현재 가격, 실시간 가격, 시장 가격, 견적, 문의 예산 또는 현재 BOM 예산을 요청하고 실시간 조사 도구를 사용할 수 있는 경우, 예산을 반환하기 전에 실시간 조사를 수행합니다.

모델 메모리, 이전 프로젝트 예산 또는 과거 조달 데이터만으로 현재 가격 요청에 응답하지 마십시오.

실시간 조사를 사용할 수 없는 경우, 현재 가격을 확인할 수 없다고 말하고 엔지니어링 추정치 또는 '확인 필요'로 표시된 구조화된 견적 요청만 반환합니다.

가격 출처를 선택하기 전에 항목을 분류합니다.

configurable-enterprise — 서버, 스토리지, HCI, 구성된 방화벽, 모듈식 스위치, 프로젝트 UPS 등.
fixed-sku — 고정 스위치/AP/디스플레이/Mini PC/NAS/고정 UPS SKU.
commodity-component — CPU, DIMM, SSD/HDD, 광 트랜시버, 케이블 및 기타 표준 구성 요소.

세 가지 클래스 모두에 하나의 쇼핑 워크플로를 사용하지 마십시오.

주요 규칙:

기술적 사실은 제조업체 제품 페이지/데이터시트/구성기/호환성 매트릭스를 선호합니다.
가격 책정의 경우, 구성 일치 및 상업적 범위가 출처 권위보다 우선합니다.
세금/지원/액세서리가 이해된 경우, 제조업체/직접/공식 스토어/공인 채널의 현재 정확한 구성 견적이 가장 강력한 실용적인 예산 기준점입니다.
사용자 제공 또는 프로젝트에 저장된 현재 인간 견적은 공개 URL이 없더라도 채널, 날짜, 구성 일치 및 상업적 범위가 캡처된 경우 유효한 증거입니다.
두 개 이상의 정확한 현재 견적이 기본 현재 시장 범위를 정의합니다. 낮은 우선 순위의 역사적 또는 일반 가격을 해당 범위에 평균화하지 마십시오.
하나의 정확한 현재 견적은 기본 앵커이지만, 실용적인 경우 조달 통제 가격을 고정하기 전에 두 번째 견적을 얻으십시오.
구성 가능한 엔터프라이즈 장비의 경우, 공개 마켓플레이스 시작/기본 가격은 리드일 뿐 구성된 시스템 가격이 아닙니다. 전체 구성 견적을 얻거나 확인하십시오.
고정 SKU 및 표준 구성 요소의 경우, 정확한 SKU, 세금 및 보증이 비교 가능한 경우 여러 현재 공식/엔터프라이즈 마켓플레이스 가격이 강력한 증거가 될 수 있습니다.
시장 집계자는 스프레드/건전성 확인 및 채널 발견에 유용하지만, 자동으로 조달 앵커가 되지는 않습니다.
가격 내역/거래 커뮤니티 출처는 주로 표준 SKU/구성 요소에 대한 추세/맥락 증거이며, 구성된 엔터프라이즈 시스템에 대한 것은 아닙니다.
정부 조달 낙찰/거래 기록은 실시간 견적이 아닌 역사적 비교 증거로 사용합니다.
동일한 섀시/모델 제품군이 동일한 조달 구성을 의미하지는 않습니다.
해당하는 경우 CPU/메모리/스토리지/RAID/NIC/PSU/액세서리/라이선스/보증/지원/세금/구현 비용을 포함한 구성 비용을 비교합니다.
시작/기본 가격, 사용할 수 없는 제안, 일치도가 낮은 구성, 불완전한 상업적 범위 및 허용되지 않는 중고/리퍼브 제안을 기본 앵커에서 제외합니다. 제외 사유와 함께 계속 표시합니다.
정확한 현재 견적이 없는 고도로 구성 가능한 엔터프라이즈 장비의 경우, 범위를 출력하고 '추정됨' 또는 '확인 필요'로 표시합니다. 거짓 정밀도를 제시하지 마십시오.
관련 없는 가격을 평균화하지 마십시오.

가격 인하 전 필수 기술 적합성 게이트

이 게이트는 모든 하향 가격 수정에 적용되며, fixed-sku 및 상품 유사 품목을 포함합니다. 가격 조사는 후보를 식별할 수 있지만, 더 저렴한 후보는 가격 비교 전에 존재했던 요구 사항을 충족하는 것으로 입증된 후에만 예산에 영향을 미칠 수 있습니다.

규칙:

더 저렴한 후보를 조사하기 전에 필요한 기술 범위를 유지합니다. 더 저렴한 목록과 일치시키기 위해 CPU, 메모리, 포트, 디스플레이/OPS 기능, UPS 용량/런타임, 보증, 라이선스 범위 또는 기타 필수 속성을 약화시키지 마십시오.
필수 기술 적합성이 알려지지 않았거나 실패한 경우, 가격 앵커에서 더 저렴한 SKU를 거부합니다. 해당 가격은 제외된/컨텍스트 증거로만 유지합니다.
UPS 라인의 경우, 예산을 낮추기 전에 항상 references/ups-sizing.md를 로드합니다. 먼저 보호 부하, W 마진, VA 마진, 런타임 목표 및 정상 종료 요구 사항을 설정합니다.
구체적인 UPS SKU가 낮은 예산의 이유로 제안되고 Shell/Python을 사용할 수 있는 경우 다음을 실행합니다.

python scripts/calculate_ups.py <protected-load-W> \
  --runtime-minutes <minutes> \
  --candidate-w <candidate-output-W> \
  --candidate-va <candidate-VA> \
  --runtime-curve-verified \
  --shutdown-interface-verified

UPS 후보가 status = eligible-for-pricing 결과를 반환하는 경우에만 낮은 가격 앵커로 사용합니다. 보호 부하/런타임이 해결되지 않았거나 결과가 not-eligible-for-pricing인 경우, 이전 UPS 예산을 잠정적으로 유지하고 저렴한 SKU에서 요구 사항을 측정하는 대신 '확인 필요'로 표시합니다.
명목상의 1500VA 라벨이 적합성을 증명하지 않습니다. 실제 출력 W, VA, 실제 부하에서의 런타임 및 필요한 종료 통합은 별도의 확인 사항입니다.
디스플레이 및 기타 번들 고정 SKU에도 동일한 원칙을 적용합니다. 예를 들어, OS/네트워크 기능이 없는 디스플레이는 비교된 상업적 범위에 OPS 또는 이와 동등한 재생 장치가 포함되지 않는 한 브라우저/BI 요구 사항을 충족하지 않습니다.

기존 예산 수정 의무 워크플로

이 워크플로는 사용자가 기존 BOM, CSV, XLSX 또는 예산 파일의 가격을 업데이트, 새로 고침, 재평가, 수정 또는 최적화하도록 요청할 때마다 필수입니다. 사용자가 "update price"와 같은 짧은 명령만 제공하는 경우에도 적용됩니다.

먼저 원본 아티팩트를 읽고 각 기존 라인 항목 단가를 수정 기준선으로 유지합니다. 이전 예산이 자동으로 현재 가격 증거는 아니지만, 더 약한 증거에 의해 자동으로 덮어쓰여져서는 안 됩니다.
광범위한 웹 조사 전에, 접근 가능한 프로젝트 증거(소스 파일, 인접/이전 예산 버전, 견적 기록, 메모, 스크린샷, 사용자 제공 수치 및 이전 프로젝트 아티팩트)에서 현재 견적을 검사합니다. 공개 URL이 없다는 이유만으로 인간 견적을 폐기하지 마십시오.
가격 인하 전 필수 기술 적합성 게이트를 더 저렴한 후보가 필수 요구 사항을 변경하거나 불확실하게 만드는 모든 라인에 적용합니다.
모든...

IT 인프라 장비 선정 스킬