---
name: optimize-ptop-build
description: 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에 없을 수 있다.** 먼저 탐색하고, 못 찾으면 측정을 포기하되 그 사실을 명시한다.

```bash
# 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](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](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).