LGES-OC5-PtoP-Welder/.claude/skills/optimize-ptop-build/SKILL.md

name

description

optimize-ptop-build

ILSOS_PrismaticRD_PTOP의 빌드 최적화 및 CI/CD 자동화. 멀티 구성 빌드(Debug/Release — Simulation·UserDefineUnit은 sln에서 Release로 매핑되어 별도 구성이 아니다) 분석, 의존성 최적화, 빌드 시간 단축, CI/CD 파이프라인 설계. "빌드 최적화", "PTOP 빌드 성능", "CI/CD 자동화 설계", "배포 파이프라인" 요청 시 사용. 구분 — 계층 구조는 `analyze-ptop-architecture`, 시퀀스 내부 로직은 `analyze-ptop-implementation`, 셋을 함께 보려는 종합 요청은 `orchestrate-ptop-harness`. 이 스킬은 분석·제안 전용이며 프로젝트 파일을 수정하지 않는다. 맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 대상을 먼저 확인한다.

Optimize PTOP Build Skill

목표

ILSOS_PrismaticRD_PTOP의 빌드 성능 및 자동화를 최적화한다.

분석 영역

1단계: 현재 빌드 상태 분석

수집 대상:

• 솔루션 내 프로젝트 목록 (ILSOS_All.sln)
• PTOP이 참조하는 프로젝트
• 각 프로젝트의 빌드 시간 측정

측정 방법:

msbuild는 PATH에 없을 수 있다. 먼저 탐색하고, 못 찾으면 측정을 포기하되 그 사실을 명시한다.

# 1) PATH 확인
command -v msbuild MSBuild.exe

# 2) 없으면 vswhere로 탐색 (VS 2022 설치 시)
"/c/Program Files (x86)/Microsoft Visual Studio/Installer/vswhere.exe" \
  -latest -products '*' -find 'MSBuild/**/Bin/MSBuild.exe'

# 3) 찾았으면 구성별 측정 (time으로 소요시간 확보)
time "<MSBUILD>" ILSOS_All.sln -p:Configuration=Release -p:Platform=x64

셋 다 실패하면 2개 구성의 시간 칸을 전부 미측정으로 확정하고, 보고서 "미측정·미검증"에 "MSBuild 미탐색 — 빌드 시간 측정 불가"를 사유와 함께 남긴다. 추정치를 채우지 않는다. 이 하네스는 빌드를 실행만 하고 프로젝트 파일을 고치지 않는다.

수집 항목: (§3단계 참조 — PTOP의 실질 구성은 2개다)

구성	총 소요시간	병목 프로젝트 (상위 3)	캐시 효율
Debug|x64	?	?	?
Release|x64	?	?	?

Simulation|x64·UserDefineUnit|x64는 ILSOS_All.sln:413-416에서 PTOP이 Release|x64로 매핑되어 바이너리가 동일하다. 별도 측정 대상이 아니므로 표에 행을 만들지 않는다.

2단계: 의존성 분석

PTOP의 최소 필수 의존성 파악:

의존성 트리를 소스에서 직접 만든다. 미리 적힌 필수/선택 판정을 그대로 옮기지 않는다 — 잘못된 판정을 따라 참조를 지우면 빌드가 깨진다.

1. Machines/ILSOS_PrismaticRD_PTOP/*.csproj의 <ProjectReference> / <Reference> 전수 수집
2. 각 참조에 대해 심볼이 실제로 쓰이는지 검색 (using 문만으로 판단하지 말 것 — 죽은 using이 있다)
3. 판정 근거를 기록: 필수 — <어느 코드가 쓰는가 파일:라인> / 미사용 후보 — <검색 결과>

참조	종류	사용 근거(파일:라인)	판정	제거 시 위험
	ProjectReference / NuGet		필수 / 미사용 후보 / 불명확

분석 시 주의:

• 조건부 컴파일 심볼로만 쓰이는 참조가 있는지 확인한다. 단 이 프로젝트의 DefineConstants는 DEBUG;TRACE / TRACE뿐이고 #if SIMULATION 류는 0건이므로(csproj 확인), 새 심볼을 가정하지 말 것.
• 리플렉션·DI 등록으로만 쓰이면 정적 검색에 안 잡힌다. EquipmentSetup.cs의 디바이스 등록부를 반드시 확인한다.

산출물: _workspace/04a_dependency_analysis.csv

3단계: 빌드 구성별 최적화

Debug|x64 최적화

• 기호 생성 필요 (유지)
• 최적화 비활성화 (유지)
• 증분 빌드 활용

Release|x64 최적화

.csproj는 legacy 형식 + .NET Framework 4.8.1이다. PublishTrimmed·TieredCompilation· DebugType=embedded 같은 SDK 스타일(.NET Core/5+) 속성은 동작하지 않는다. 제안 전에 해당 속성이 이 프로젝트 형식에서 유효한지 먼저 확인하라.

Simulation|x64 / UserDefineUnit|x64 — 별도 컴파일 구성이 아니다

ILSOS_All.sln:413-416에서 PTOP({8BB07B4C-…})의 Simulation|x64·UserDefineUnit|x64가 Release|x64로 매핑된다. 즉 PTOP은 Release와 동일한 바이너리이며 출력도 x64-Release/다. 다만 솔루션의 다른 프로젝트 상당수는 Simulation|x64 → Debug|x64이므로 최소 빌드 집합을 논할 때 프로젝트별 매핑을 각각 확인해야 한다.

시뮬레이션은 조건부 컴파일이 아니라 런타임 플래그로 갈린다 — Device/PLC/PLCContoller.Config.cs의 isSimul 계열. Machines/ 전체에 #if SIMULATION은 0건이고 DefineConstants는 DEBUG;TRACE / TRACE뿐이다(csproj 확인).

이 사실을 모르고 "Simulation 구성만 따로 최적화"를 제안하면 존재하지 않는 빌드를 대상으로 삼게 된다. 구성별 차이를 논하기 전에 sln의 ActiveCfg 매핑을 먼저 읽어라.

4단계: CI/CD 파이프라인 설계

목표:

• 자동 빌드 (commit, PR)
• 자동 테스트 — Simulation은 별도 구성이 아니므로(§3단계) 테스트 잡을 Simulation 구성으로 나누지 않는다. 시뮬 동작은 런타임 isSimul 플래그로 켠다.
• 자동 배포 (수동 승인)

추천 플랫폼:

• GitHub Actions (GitHub 저장소 사용 중 가정)
• Azure Pipelines (Microsoft 클라우드)
• Jenkins (온프레미스)

파이프라인 구조: references/cicd-pipeline-template.yml 를 시작점으로 삼아 _workspace/05_cicd_pipeline.yml에 프로젝트 맞춤 버전을 쓴다.

템플릿은 미검증 초안이다. 실제로 러너에서 돌려본 적이 없으므로, 검증 없이 "CI/CD 설계 완료"라고 보고하지 않는다. 검증 여부를 보고서에 명시한다.

5단계: 배포 패키징

산출물:

• 실행 가능 파일 (Aurora.exe)
• 필수 DLL (AuroraDevices, WeldingComponents, etc.)
• 설정 파일 (app.config)
• 리소스 파일 (이미지, 데이터)
• 배포 설명서

패키징 형식:

• ZIP 아카이브 (간단)
• NSIS 설치 프로그램 (사용자 친화적)
• Chocolatey 패키지 (자동 업데이트)

통합 산출물

최종 보고서: _workspace/06_ptop_build_optimization.md

(보조 산출물: _workspace/04_build_analysis.md, _workspace/05_cicd_pipeline.yml)

보고서 골격은 references/report-template.md 참조.

빌드 시간·크기·개선율을 지어내지 않는다. 실제로 측정했을 때만 수치를 적고 측정 명령어를 병기한다. 측정하지 않았으면 미측정이라고 쓴다. "이 의존은 제거 가능해 보인다" 같은 미검증 판단에는 [추론]을 붙인다 (rules.md #15·#16). 심볼 참조를 실제로 검색해 확인한 뒤에만 표기를 떼고 근거를 병기한다. 미측정(측정 못 함)과 축이 다르니 대체하지 말고 필요하면 병기한다.

입력 조건

단독 호출 시: 생성할 _workspace/ 파일 목록을 사용자에게 제시하고 승인받은 뒤 시작한다 (rules.md #2). 오케스트레이터(orchestrate-ptop-harness)를 통해 호출된 경우는 이미 승인을 받았으므로 생략한다.

사용자 요청 시:

• "PTOP 빌드 최적화"
• "빌드 시간 단축"
• "CI/CD 파이프라인 설계"
• "배포 자동화"
• "Release 빌드 성능"

출력 결과

• 빌드 성능 분석 보고서
• 의존성 맵핑 CSV
• CI/CD 파이프라인 (YAML/JSON)
• 빌드 최적화 설정 (PropertyGroup)
• 배포 패키징 스크립트
• 최종 보고서

주의사항

1. .NET Framework 4.8.1 호환성 — 최신 .NET 기능 사용 불가
2. Visual Studio 2022 기준 — MSBuild 경로 확인
3. Windows 플랫폼 전용 — x64 아키텍처 명시
4. 빌드 머신 사양 — CI 환경의 OS/RAM 확인
5. 라이선스 확인 — NuGet 패키지, 외부 도구의 라이선스
6. 주석·프로퍼티명을 맹신하지 않는다 (rules.md #1) — 구성 이름(Simulation·UserDefineUnit)이 별도 컴파일을 뜻하지 않는 것이 그 예다. 판단 근거는 .sln·.csproj 실제 매핑이다.

단독 기동으로 04~06을 갱신했으면 stale 표기 의무는 네게 있다. "빌드 분석만 다시"는 docs/harness-ptop.md 가 후속 트리거로 열거한 발화라 이 스킬로 직접 들어올 수 있고, 그때는 오케스트레이터가 표기해 주지 않는다. 갱신한 파일 첫 줄에 이번 실행에서 갱신됨(YYYY-MM-DD), 재사용한 기존 산출물 첫 줄에 이전 실행 결과 재사용 — 정합성 미확인(YYYY-MM-DD) 을 남긴다 (문구 3종 → orchestrate-ptop-harness/references/data-protocol.md).

이 스킬은 10분을 넘긴다 — 단계 전환마다 지금 어느 단계인지 한 줄로 보고한다(rules.md #10).

단독 호출로 마무리할 때: 보고는 rules.md #11~13 출력 형식(수정 줄=초록 화살표, 단어=주황, 미변경=기본색)을 따르고, 끝에 관련 .md를 갱신할 부분이 있는지 묻는다(rules.md #6).