MCP-서버 리팩토링 후 P&ID 추출 테스트전 다른 기능 확인 후 커밋

.roo/mcp.json

@@ -0,0 +1,3 @@
+{
+	"mcpServers": {}
+}

.roo/rules-code/diagnosis-checklist.md

@@ -0,0 +1,188 @@
+# 코드 진단 규칙
+
+코드 진단 요청 시 아래 8단계를 **반드시 순서대로** 실행한다.  
+순서를 건너뛰면 오진이 발생한다. 실제 오진 사례는 각 단계 하단에 기재.
+
+---
+
+## STEP 1 — 맥락 파악
+
+**질문: 이 파일은 무엇을 하는 파일인가?**
+
+- 파일명·디렉토리 위치로 역할 추정
+- 관련 문서 존재 확인: README, 계획서, CLAUDE.md, .roo.md
+- 아키텍처에서 어느 레이어인지 파악 (진입점 / 서비스 / 워커 / 유틸)
+
+> 이 단계를 건너뛰면 "의도적 설계"를 "버그"로 오인한다.
+
+---
+
+## STEP 2 — 구조 탐색
+
+**도구: `find`, `ls`**
+
+- 디렉토리 전체 구조 확인
+- 진단 대상이 의존하는 모듈·파일 목록 파악
+- 설정 파일(config, .env, appsettings.json) 위치 확인
+
+---
+
+## STEP 3 — 코드 읽기 ★ 가장 중요
+
+**도구: `read_file` — 전체 파일, 건너뛰기 금지**  
+**기억·요약·이전 대화에 의존하지 말 것**
+
+읽는 순서:
+1. 진입점(`main`, `__init__`, `Program.cs`, `if __name__ == "__main__"`) 먼저
+2. 인터페이스·추상 레이어
+3. 구현체 (진단 대상 파일)
+4. 의존 모듈 (필요한 것만)
+
+> **이 단계를 건너뛴 오진 사례**:  
+> `pid_worker.py` 보고서가 `asyncio.to_thread` 누락을 HIGH로 지적했으나  
+> 실제 파일엔 이미 적용되어 있었음. STEP 3을 건너뛰어 구버전 기준으로 진단한 결과.
+
+---
+
+## STEP 4 — 호출 계층 지도 작성
+
+코드를 읽으면서 다음 구조를 머릿속에(또는 메모로) 그린다:
+
+```
+HTTP 요청
+  → endpoint 함수
+      → _dispatch()          ← 여기서 try-catch?
+          → _tool_a()        ← 여기도 try-catch?
+              → 외부 I/O     ← blocking?
+```
+
+**이 지도 없이 에러 처리·블로킹을 진단하면 반드시 오진한다.**
+
+> **이 단계를 건너뛴 오진 사례**:  
+> `_dispatch()`가 전체 예외를 일괄 처리하고 있었음에도  
+> 하위 함수에 try-catch가 없다는 이유로 "에러 핸들링 불균형(MED)"으로 지적.  
+> 계층 지도를 그렸다면 상위에서 잡힌다는 것을 바로 확인할 수 있었음.
+
+---
+
+## STEP 5 — 패턴 매칭 (체크리스트 순회)
+
+우선순위 순서로 확인한다.
+
+### 🔴 런타임 즉시 실패
+
+| 체크 | 항목 | 판단 기준 |
+|------|------|-----------|
+| [ ] | 미정의 변수·함수 참조 | 임포트 없이 사용하거나 정의 전에 호출 |
+| [ ] | 잘못된 타입 | FastAPI `def f(body: dict)` → 동작 안 함. `Request.json()` 또는 Pydantic 사용 |
+| [ ] | 누락된 `app = FastAPI()` | `uvicorn.run(app, ...)` 전에 `app` 미정의 |
+| [ ] | SIGTERM이 응답보다 먼저 실행 | `os.kill` 후 `return result`는 응답이 전달되지 않을 수 있음 |
+
+### 🟠 동시성 / 비동기
+
+| 체크 | 항목 | 판단 기준 |
+|------|------|-----------|
+| [ ] | async 함수 내 blocking 호출 | `asyncio.to_thread` 없이 파일 I/O·HTTP·OCR 직접 호출 → 이벤트루프 블로킹 |
+| [ ] | Race Condition | `if key not in dict → await start()` 패턴에서 await 사이 다른 코루틴 진입 가능 → Lock 필요 |
+| [ ] | one-shot + 동시 요청 | 종료 로직이 있을 때 동시 요청이 들어오면 진행 중인 요청이 강제 종료됨 |
+| [ ] | `asyncio.sleep` 고정값으로 준비 확인 | 불안정 — 헬스체크 루프로 대체 |
+| [ ] | `asyncio.gather` 병렬화 기회 | 독립적인 await가 순차 나열 → gather로 묶을 수 있는가? |
+
+### 🟠 프로세스 / 리소스
+
+| 체크 | 항목 | 판단 기준 |
+|------|------|-----------|
+| [ ] | subprocess `stdout=PIPE` 데드락 | 대량 출력 시 파이프 버퍼 가득 참 → `DEVNULL` 또는 파일 리다이렉션 |
+| [ ] | 고아 프로세스 | 메인 프로세스 종료 시 자식이 남는가? `atexit` 또는 signal 핸들러 |
+| [ ] | DB 커넥션 누수 | `with` 블록 또는 명시적 `close()` 없이 커넥션 획득 |
+
+### 🟠 에러 처리
+
+| 체크 | 항목 | 판단 기준 |
+|------|------|-----------|
+| [ ] | 예외가 사용자에게 노출 | 최상위 핸들러까지 예외 전파 시 500 + 스택 트레이스 노출 가능 |
+| [ ] | 예외를 삼킴 | `except: pass` → 디버깅 불가. 최소 `logging.error` 필요 |
+| [ ] | 에러 응답 형식 불일치 | 일부 경로만 `{"success": false, "error": "..."}` 형식이 다르면 클라이언트 파싱 실패 |
+
+### 🟡 보안
+
+| 체크 | 항목 | 판단 기준 |
+|------|------|-----------|
+| [ ] | SQL Injection | 쿼리를 f-string으로 조합 → parameterized query 사용 |
+| [ ] | 경로 트래버설 | 사용자 입력 filepath에서 `..` 검증 없음 → 임의 파일 접근 |
+| [ ] | Command Injection | `shell=True` + 사용자 입력 → `shell=False` + 리스트 인자 |
+| [ ] | 민감 정보 로깅 | 비밀번호·토큰이 에러 메시지에 포함 |
+
+### 🟢 코드 구조
+
+| 체크 | 항목 | 판단 기준 |
+|------|------|-----------|
+| [ ] | 설정 하드코딩 | URL·비밀번호·포트가 코드에 박혀 있음 → 환경 변수 또는 설정 파일 |
+| [ ] | 미사용 import·변수 | 실행 경로에서 실제로 사용되지 않는 import |
+
+---
+
+## STEP 6 — 교차 검증 ★ 오진 방지 핵심
+
+**STEP 5에서 발견한 각 의심 항목마다 아래 4개 질문을 모두 통과해야 보고서에 올린다.**
+
+| 질문 | 확인 방법 | "예"이면 |
+|------|-----------|---------|
+| Q1. 이미 수정된 문제인가? | 파일 현재 상태 재확인 (grep) | 보고서에서 제거 |
+| Q2. 다른 레이어에서 처리되고 있는가? | STEP 4 호출 계층 지도 재참조 | 보고서에서 제거 또는 LOW 강등 |
+| Q3. 의도적 설계인가? | 문서·주석·아키텍처 계획서 확인 | 보고서에서 제거 |
+| Q4. 실제 장애 시나리오가 있는가? | 재현 경로를 구체적으로 서술할 수 있는가? | 없으면 LOW 강등 |
+
+> **이 단계를 건너뛴 오진 사례 (모두 pid_worker.py 보고서)**:
+>
+> | 지적 사항 | 실제 | 건너뛴 질문 |
+> |-----------|------|------------|
+> | `asyncio.to_thread` 누락 (HIGH) | 이미 적용되어 있었음 | Q1 |
+> | 에러 핸들링 불균형 (MED) | `_dispatch`가 전체 예외를 잡고 있었음 | Q2 |
+> | `lru_cache` 메모리 고정 (MED) | one-shot 워커에서 의도적 싱글톤 패턴 | Q3 |
+> | `max_tokens` 차이가 중복 (LOW) | 도구마다 의도적으로 다른 값 사용 | Q3 |
+
+---
+
+## STEP 7 — 심각도 분류
+
+| 등급 | 기준 |
+|------|------|
+| 🔴 HIGH | 런타임 즉시 오류, 데이터 손실, 보안 취약점 — 재현 가능한 시나리오 있음 |
+| 🟠 MED | 간헐적 오류, 성능 저하, 동시성 문제 — 특정 조건에서 발생 |
+| 🟡 LOW | 유지보수성, 하드코딩, 스타일 — 동작에는 영향 없음 |
+
+심각도 결정 전 스스로 확인: "이 문제가 언제, 어떤 조건에서 실제 장애를 일으키는가?"
+
+---
+
+## STEP 8 — 보고서 작성 및 자가 검증
+
+### 보고서 형식 (항목당 4줄)
+
+```
+### [번호]. [제목] (HIGH / MED / LOW)
+
+**문제**: 어떤 상황에서 무엇이 잘못되는가 (구체적으로)
+**근거**: 파일명:줄번호 — 코드 인용 필수
+**영향**: 실제로 어떤 장애가 발생하는가
+**수정**: 구체적인 수정 코드 또는 방향
+```
+
+### 보고서에 포함하지 않는 것
+
+- 이미 수정된 문제 (Q1 탈락)
+- 다른 레이어에서 처리되어 실제 장애가 없는 문제 (Q2 탈락)
+- 의도적 설계를 버그로 지적한 사항 (Q3 탈락)
+- 재현 시나리오 없는 추정 (Q4 탈락)
+- 실측 없는 성능 수치 ("느릴 것이다", "메모리가 많이 든다")
+
+### 제출 전 자가 검증
+
+- [ ] 각 지적 사항을 "현재 파일 몇 번 줄"로 직접 가리킬 수 있는가?
+- [ ] HIGH 항목은 재현 가능한 시나리오를 한 문장으로 말할 수 있는가?
+- [ ] 교차 검증 4개 질문을 모두 통과한 항목만 포함되어 있는가?
+- [ ] 보고서의 수정 예시가 현재 코드에 아직 적용되지 않은 내용인가?
+- [ ] "더 좋은 방법 제안"과 "현재 코드가 틀렸다"를 혼동하지 않았는가?
+-------------------------------------------------------------------------------------------
+

.roo/rules-code/glm-code-rules.md

@@ -0,0 +1,101 @@
+# GLM-4.7-Flash 코드 작업 규칙 (ExperionCrawler)
+
+## 필수 준수 사항
+
+### 작업 전
+- 반드시 `task_state.md`를 먼저 읽어 진행 상태 파악
+- 파일 수정 전 반드시 `read_file`로 전체 내용 확인 후 수정
+
+### 코드 수정 원칙
+- 요청된 범위만 수정 — 관련 없는 코드 리팩토링 금지
+- 빌드 검증: 각 파일 수정 후 `dotnet build src/Web/ExperionCrawler.csproj --no-restore -v q` 실행
+- 빌드 실패 시 즉시 원인 수정 후 재빌드, 다음 항목으로 넘어가지 않음
+
+### issues.md 작성 형식
+```
+| # | 파일 | 심각도 | 분류 | 내용 | 상태 |
+|---|------|--------|------|------|------|
+| 1 | src/... | HIGH/MED/LOW | bug/perf/quality/security | 설명 | pending/fixed |
+```
+심각도 기준:
+- HIGH: 런타임 예외, 데이터 손실, 보안 취약점
+- MED: 성능 저하, 잘못된 동작, 예외 미처리
+- LOW: 코드 품질, 불필요한 코드, 명명 불일치
+
+### 클로드 검수를 위한 커밋 규칙
+- 각 이슈 수정 완료 시: `git add -p` 후 이슈 번호 포함 커밋
+  예: `fix(#3): ExperionDbContext null 참조 예외 방어 처리`
+- 전체 완료 후 `REVIEW_REQUEST.md` 생성하여 검수 요청
+
+### MCP 도구 활용
+- `search_codebase`: 관련 코드 패턴 검색에 적극 활용
+- `ask_iiot_llm`: IIoT/OPC UA 도메인 판단이 필요할 때 사용
+
+---
+
+## [CRITICAL] ASP.NET Core 컨트롤러 JSON 직렬화 규칙
+
+### 배경 (반드시 숙지)
+
+`src/Web/Program.cs`에 다음 설정이 있다:
+```csharp
+opt.JsonSerializerOptions.PropertyNamingPolicy = null;  // PascalCase 그대로 직렬화
+```
+
+이로 인해 C# 속성명이 **그대로** JSON 키가 된다.  
+프론트엔드(`app.js`)는 **모든 JSON 필드를 camelCase**로 접근하므로,  
+PascalCase 키가 오면 **모든 값이 `undefined`** 가 된다.
+
+### 금지 패턴 (절대 사용 금지)
+
+```csharp
+// ❌ shorthand 익명 객체 — C# 속성명(PascalCase)이 JSON 키로 그대로 사용됨
+return Ok(new { x.Id, x.TagName, x.NodeId, x.LiveValue });
+
+// ❌ typed 객체를 Ok()에 직접 전달 — PascalCase 직렬화됨
+return Ok(result);
+return Ok(new MyDto { Id = 1, TagName = "abc" });
+```
+
+### 올바른 패턴 (항상 명시적 camelCase 매핑)
+
+```csharp
+// ✅ 항상 명시적으로 소문자 키 지정
+return Ok(new
+{
+    id        = x.Id,
+    tagName   = x.TagName,
+    nodeId    = x.NodeId,
+    liveValue = x.LiveValue,
+    timestamp = x.Timestamp
+});
+
+// ✅ 컬렉션 포함 응답
+return Ok(new
+{
+    total = r.Total,
+    items = r.Items.Select(x => new
+    {
+        id       = x.Id,
+        tagName  = x.TagName,
+        nodeId   = x.NodeId
+    })
+});
+```
+
+### C# 예약어 처리
+
+`class`는 C# 예약어이므로 `@class`를 사용한다. System.Text.Json이 `"class"`로 정상 직렬화한다:
+
+```csharp
+// ✅ @class → JSON "class"
+return Ok(new { id = x.Id, @class = x.Class, name = x.Name });
+```
+
+### 점검 체크리스트
+
+컨트롤러에서 `Ok(...)` 또는 `return` 사용 시:
+- [ ] 익명 객체의 모든 키가 소문자(camelCase)인가?
+- [ ] `new { x.SomeProp }` 형태(shorthand)가 없는가?
+- [ ] typed record/class를 그대로 반환하지 않는가?
+- [ ] C# 예약어(`class`, `string` 등)에 `@` 접두사를 붙였는가?

.roo/rules-code/roo-rules.md

@@ -0,0 +1,97 @@
+# roo-rules.md
+
+Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+## 1. Think Before Coding
+
+**Don't assume. Don't hide confusion. Surface tradeoffs.**
+
+Before implementing:
+- State your assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them - don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+## 2. Simplicity First
+
+**Minimum code that solves the problem. Nothing speculative.**
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines and it could be 50, rewrite it.
+
+Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+
+## 3. Surgical Changes
+
+**Touch only what you must. Clean up only your own mess.**
+
+When editing existing code:
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it - don't delete it.
+
+When your changes create orphans:
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+The test: Every changed line should trace directly to the user's request.
+
+## 4. Goal-Driven Execution
+
+**Define success criteria. Loop until verified.**
+
+Transform tasks into verifiable goals:
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multi-step tasks, state a brief plan:
+```
+1. [Step] → verify: [check]
+2. [Step] → verify: [check]
+3. [Step] → verify: [check]
+```
+
+Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
+
+## 5. Save the token & time - Roo code must keep this rule not API
+- "Do not summarize the code or changes after completing a task"
+- "Once the code is written, do not repeat the explanation"
+- "Only output the final file content if necessary"
+
+## 6. Backup + Diff Before Edit
+
+**기존 파일을 수정하기 전에 반드시 다음 두 단계를 수행할 것.**
+
+### Step 1 — 백업
+수정 대상 파일을 `.rooBackup/` 폴더에 현재날짜와 시간으로 폴더를 만들고 그 폴더에 수정전 원본 그대로 저장한다.
+
+- 저장 경로: `.rooBackup/<날짜-시간>/<원본경로>/<파일명>`
+- 예: `src/Web/wwwroot/js/app.js` → `.rooBackup/src/Web/wwwroot/js/app.js`
+- 백업 후 "백업 완료: `.rooBackup/...`" 를 출력할 것
+
+### Step 2 — Diff 제시
+변경 내용을 diff 형식으로 보여주고, 사용자 확인 후 실제 수정 진행.
+
+```diff
+- 기존 코드
++ 변경된 코드
+```
+
+변경 이유를 한 줄로 함께 설명할 것.
+
+### 예외 (백업/diff 생략 가능)
+- 신규 파일 생성
+- 공백/포맷팅만 바뀌는 경우
+
+**위반 사례 (금지):** 백업·diff 없이 바로 파일을 덮어쓰는 것 — roo가 이전에 fastRecord 섹션 전체를 날린 것이 이 케이스에 해당.
+
+---
+
+**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.