HC900-Crawler/docs/논의-AI운전원-제어-아이디어.md

논의 정리: AI 운전원 / 직접제어 아이디어

2026-06-11 대화 정리. 스마트폰에서 진행한 브레인스토밍을 다시 논의하기 위해 기록.

출발 질문

• 히스토리컬 데이터 기준으로 현재 제어출력(OP)에서 앞으로 5분간 유량 예측이 가능한가?

결론

가능. 단 "예측"을 둘로 나눠야 함:

• OP → 유량 정상상태: 유량 루프는 응답 빠른 계통(시정수 수 초~수십 초). 5분(300초)은 과도응답이 아니라 거의 정상상태. → OP에 대한 정상상태 게인 맵으로 예측 쉬움. (이미 learned-control의 steady-state map과 동일한 물건)
• 5분 동안의 변동 요인: 예측 오차의 진짜 원인.
  • OP 자체가 5분 안에 바뀜 (자동=컨트롤러, 수동=운전원) → OP 미래궤적부터 예측해야 함
  • 미측정 외란 (헤더 압력, 상류 공급, 다른 루프 간섭)

데이터 제약

소스	주기	5분=점개수	용도
history_table	60초	~5점	정상상태 예측엔 충분, 동특성 식별엔 거침
realtime_table	~1초	~300점	FOPDT 동특성 식별에 필요

---

우리 프로젝트의 진짜 자산 (moat)

이 셋을 한 시스템 안에 다 가진 게 차별점 (대부분 시스템은 하나만 가짐):

1. 컨트롤러 직접 쓰기 가능 — gateway WriteTag + mode write가 C3에서 실측 검증됨
2. 운전원 행동 히스토리 + P&ID 그래프 + KB 문서 — trace_connections, build_pid_graph
3. LLM/RAG 추론 레이어

후보 아이디어 (임팩트 순)

1. 🔥 "AI 운전원" — 자문에서 자율로: 학습 모델이 선택된 MANUAL 루프에 직접 OP 쓰기. 쓰기 경로 이미 검증됨. 단계적(자문→1클릭 승인→화이트리스트 자율). 안전장치: 그래프/KB로 하류 영향 사전 체크.
2. 그래프 기반 자동 근본원인 추적: 값 비정상 시 P&ID 그래프 따라 상류 전파 추적 → 원인 노드 식별. 알람 홍수를 한 줄 인과로 압축.
3. 외란 도착 예측 → 선제 피드포워드: 그래프에 시간 입혀서 상류 외란 도착 시각 계산 → PV 움직이기 전에 OP 선제 조정. 5분 예측이 보고용이 아니라 선제 제어입력이 됨.
4. 소프트 센서: 필드계기는 고유 태그 없음. 측정 안 되는 양을 상관 태그+모델로 추정 → 비용 0으로 계측점 늘리기.

추천 방향: #1을 목표로, #2·#3을 안전·예측 엔진으로 깔기 = "설명 가능하고(그래프) 앞을 내다보는(예측) AI 운전원".

---

⚠️ 핵심 반론 (사용자 지적)

지난 4개월 운전원 수동 데이터 온도 프로파일을 보면 민감단 온도가 크게 안 흔들림 → 운전원이 이미 제어를 매우 잘함. → 우리가 직접 제어해서 "더 정밀하게" 이겨봐야 어필이 안 됨. 운전원의 정상상태 제어를 타이트하게 이기는 건 어렵고, 이겨도 감동이 없음.

대응 전략: 채점표를 바꿔라

운전원이 이기는 축(정상상태 온도 타이트함)에서 싸우지 말고, 운전원이 구조적으로 못 이기는 세 축에서 싸운다.

① 경제 마진 — 진짜 팔리는 숫자

• 민감단 온도가 안 흔들린다 = 운전원이 보수적 마진을 깔고 운전(환류/스팀 여유). 그 여유 = 매일 버려지는 에너지/처리량.
• 어필: "온도 안정도는 운전원과 동일, 셋포인트를 최적점으로 당겨 스팀 X% 절감."
• 제어를 이기는 게 아니라 같은 안정도로 더 싸게. APC가 30년간 돈 번 방식. 운전원은 다변수 동시 최적화 못 하니 구조적으로 못 따라옴.

② 선제성(앞먹임) — 운전원은 PV 움직인 뒤에 반응

• 우리는 그래프로 상류 외란 도착 미리 계산 → 온도 움직이기 전 OP 조정.
• 어필: "공급 변동 시 민감단 온도 최대 편차, 운전원 대비 절반." 운전원이 원리적으로 못 이기는 영역.

③ 분산(variance) — 4개월 프로파일의 함정

• 깔끔한 프로파일은 잘하는 운전원의 좋은 날 평균. 교대조별·시간대별(새벽 3시)·신참으로 쪼개면 표준편차 다름.
• 가치 = "항상 최고 운전원 수준, 24시간, 모든 교대조." 평균이 아니라 최악 시간대를 끌어올림.

---

다음 액션: 제어 건드리기 전 오프라인 검증

4개월 히스토리로 카운터팩추얼 분석 (컨트롤러 안 건드림, 데이터로만):

1. 운전원이 깔고 있는 보수 마진 측정 (민감단 온도 vs 제약한계 거리, 환류/스팀 여유분)
2. "온도 안정도 그대로 두고 마진만 당겼다면 절감액 = ?" 정량 추정
3. 외란 구간 운전원 반응 지연 측정 → 앞먹임으로 줄일 수 있는 편차 정량화

→ 이 세 숫자가 나오면 제어 켜기 전에 어필 자료 완성. 셋 다 "운전원보다 정밀"이라는 어려운 약속이 아니라 "운전원이 못 하는 것"이라는 방어 가능한 약속.

첫 단추 (추천)

①(마진)부터. 필요한 것: 민감단 온도 태그 + 환류/스팀 관련 태그. → 4개월치로 "버려지는 마진"이 실제 존재하는지 데이터로 확인.

데이터 검증 1회차 (2026-06-12) — ① 마진 가설 부분 반증

대상 확정: P6-1 / C-6111 진공증류탑 (C3). ⚠️ 데이터 창 (확정): 현장 실데이터 = 2026-02-05 ~ 2026-06-05 (field_hist dtat KST 기준; UTC recorded_at 02-05 03:53 ~ 06-05 02:22). field_hist 17개 cont 전수조회로 확인(주 테이블 336,519행). 그 이후 ~06-12는 C3 시뮬레이션 소스이므로 제외. 분석 컷오프 = recorded_at < '2026-06-05 02:22 UTC' (사용자 (A) 선택). (메모리의 06-05는 정확; 이전 "5월말일"은 며칠 짧았음.)

태그 매핑 확정 (정정: 민감단 = TI-6111C, NOT D):

• 민감단(품질·분리도 proxy) = TI-6111C.PV = T_C (중상부). DB·문서·현 프로그램 모두 이 기준. 실창 p05p95 = **83.986.0, sd 1.45** → 실제로 움직임. (작업플랜-민감단온도-전환복귀제어.md L26)
• 참고: TI-6111D.PV(상부)는 sd 0.19로 못박혀 있으나 민감단 아님 — 품질 프록시로 쓰지 말 것.
• 에너지 레버 = 스팀 FIQ-6115.PV(T_C 주조작변수), 리플럭스 FICQ-6113.PV
• 처리량 = feed FICQ-6101.PV (p05p95 = 393918, 2.3배 변동)
• 하부온도(스팀 자동제어) = TICA-6111A (.PV/.SP/.OP)

핵심 발견 (분 단위 피벗, feed·민감단 T_C 동시 고정 counterfactual; n=13,137):

검증	전체 변동(실창)	feed 600700 & T_C(TI-6111C) 84.685.0 고정 후
스팀 FIQ-6115	sd 146 (p05p95 277664)	sd 12.5, p10p90 478500 (±2.3%)
리플럭스 FICQ-6113	sd 442 (p05p95 9052042)	sd 37, p10p90 14701497 (±1%)
feed FICQ-6101	sd 197 (p05p95 392913)	(고정변수)

→ 스팀·리플럭스 2.3~2.4배 변동은 거의 전부 feed/T_C로 설명됨. 진짜 민감단 T_C로 고정하니 스팀 변동이 더 작아짐(sd 12.5) — 스팀이 곧 T_C를 잡는 MV이므로 당연. 정상상태 "같은 품질·더 적은 스팀" 마진 = p50−p10 ≈ 11 kg/h (~2.3%).

결론: ①(정상상태 에너지 마진)은 헤드라인 불가(~2.3%). 변동의 원천은 feed 변화와 그 과도구간(transition), 그리고 T_C 자체가 sd 1.45로 움직이는 구간. 가치는 정상상태가 아니라 전환·T_C 이탈에 있음.

🔑 핵심 발견 — 이 thread는 이미 작업라인: docs/작업플랜-민감단온도-전환복귀제어.md 가 정확히 이 방향을 설계해 둠 (T_C 대역유지 → 이탈 시 전환류 도피 → bumpless 복귀). C# 인프라 일부 가동 중: FeedforwardEngine/ColumnMode{Normal,Recovering,Returning} 상태기계, SteamAdvisor(steam=f(feed,product,T_C) 맵 = T_C 목표역산·디커플링), FeedRampAdvisor. → 브레인스토밍이 기존 작업라인으로 수렴. 다음 단계는 T_C 이탈 구간의 정량화(빈도·크기·원인=feed/grade/주야)로 그 작업라인의 가치를 사이징하는 것.

미해결 단서: TICA-6111A.SP 이봉성 (p05=84.0, p50=88.4, p95=88.4) → 두 모드(저온~84/고온88.4) = grade/feed 모드 전환 추정. T_C 이탈과 묶이는지 확인 필요.

데이터 검증 2회차 (2026-06-12) — ★전환 후 재정착에 마진이 있다

T_C 이탈 정량화 결과 (2,861시간, 실데이터):

• 시간 내(분 단위 제어): 98.9%가 폭 ≤0.5°C (시간당 평균폭 0.26, sd 0.06). 이탈시간(폭>1°C) = 0.5%.
• 시간 간(의도 이동): 99.3%가 ≤0.25°C/h, p99=0.166. 최대 3.63°C(드문 큰 전환).
• 주야 차이 거의 없음 (day/swing/night avg range 0.25/0.28/0.25, 이탈 0.42/0.74/0.42%) → ③ 교대조 분산 닫힘. → T_C 총 2.3°C 폭은 싸운 이탈이 아니라 의도적 조건변경의 누적. 운전원은 단기·전환 모두 매우 잘함.

핵심 컨텍스트(사용자): 지난 몇 달간 운전 조건을 많이 변경함. → 데이터 = rich excitation 자연실험(moat #2 연료). 풀링 금지(레짐별로 봐야).

주별 캠페인 (median):

주	feed	T_C	스팀	제품	스팀/제품
02-16	497	84.3	344	446	0.787
02-23	798	85.4	560	717	0.783
03-02	903	86.0	652	821	0.795
04-06	804	85.5	608	717	0.847
04-27	421	84.1	304	355	0.858
05-04	403	84.0	295	355	0.834
05-11	404	84.0	281	355	0.796
05-18	406	84.0	282	355	0.792

• 운전점 자체가 크게 변동: feed 400~900(2.25배), T_C 목표 84.0(저율)~86.0(고율) = 캠페인별 의도 설정.
• ★재정착 마진: 04-27 vs 05-11 = 거의 동일 운전점(feed~410, T_C 84.0, 제품 355)인데 스팀/제품 0.858→0.796 (~8%). 조건변경 직후 보수적→수주에 걸쳐 효율점 재탐색(0.858→0.834→0.796→0.792). = 전환 후 재정착 손실.

확정된 어필 논리: 운전원은 정착하면 프런티어 근처(정상상태 마진 ~2%, ②③ 닫힘). 그러나 조건 변경 시 효율점 재탐색에 수주가 걸려 그동안 ~8% 스팀 과다. 모델은 학습한 steam=f(feed,T_C) 바닥값을 전환 즉시 적용 → 재정착 손실 회수. 전환이 잦은 공장이라 반복 적용됨. "제어를 이긴다"가 아니라 "운전원이 결국 찾는 최선을 전환 직후부터" = 방어 가능.

다음 probe: 4개월 전 구간에서 조건변경 이벤트를 자동 검출 → 각 전환의 (재정착 소요일 × 효율 페널티) 합산 = 회수가능 스팀 총량(연간 환산). 기존 SteamAdvisor(steam=f(feed,product,T_C) 맵)가 바닥값 산출 엔진.

데이터 검증 3회차 (2026-06-12) — 재정착 마진도 작음, 진짜 비용은 startup/off-spec

전환 settling 체계적 정량화 (일단위, 5캠페인/4전환; /tmp/settling_probe.py):

seg	시작	일	feed	T_C	eff	settle	penalty
0	02-05	20	501	84.3	0.810	8d	8,292kg (startup, 선례無→청구불가)
1	02-25	20	901	86.0	0.796	0	0
2	03-17	35	801	85.4	0.830	0	0
3	04-21	11	650	84.8	0.842	0	0
4	05-02	35	404	84.0	0.811	3d	2,044kg (선례有)

• 운전원은 큰 조건변경 후에도 며칠 내 자기 효율바닥 도달 (seg1·2·3 settling=0).
• 선례 있는 재정착 회수 = seg4의 2,044kg/3.9mo = 연 6,200kg ≈ 저율 연스팀의 0.25% → 무시 수준.
• 결론: 에너지 마진 전부 닫힘 — 정상상태 ~2%, 재정착 ~0.25%.

남은 진짜 기회 (에너지 아님):

1. 캠페인 간 eff 격차(0.796~0.852, ~7%) — 운전점 교란됨(저율=고정손실↑로 steam/prod 자연↑). 청구하려면 eff=f(feed,T_C) 맵(SteamAdvisor) 적합 후 모델바닥 위 잔차로 측정. seg2(35일 0.830)가 바닥 위였나가 핵심.
2. ★startup/grade 전환 = 진짜 큰 과도비용 — seg0 1회 startup = 8,292kg(8일). 스팀보다 off-spec 제품·time-to-spec이 금액 큼(미측정). bumpless-복귀 플랜(작업플랜-민감단온도-전환복귀제어)이 노리는 지점.

가치 메트릭 전환 필요: "운전원보다 적은 스팀"(닫힘) → "전환·startup의 time-to-spec / off-spec 제품 절감" + "24/7 무인 운전원-품질 보장(labor)" + "throughput 최대화(미검증)". 제어 outperform이 아니라 운전원이 잘 못하는 드문 어려운 순간과 지속 보장.

재프레임된 후보 (임팩트 순)

1. 🔥 전환 최적화 — 이봉 SP 전환 이벤트 추출 → 전환 소요시간·정착중 품질편차·추가스팀 정량화. 어필: "전환시간/off-spec 절반."
2. 🔥 처리량 최대화 — 제약 한계(하부온도/진공/플러딩)까지 feed 추가 여력 있는 시간대 정량화.
3. 분산/최악시간대(③) — 교대조·시간대·전환구간 tail 편차로 쪼개기.
4. ① 정상상태 에너지 마진 — 부수효과로만.

다시 논의할 때 정할 것

• 데이터 컷오프 = < 2026-06-05 02:22 UTC (A) · 민감단 = TI-6111C 확정
• 다음 probe: T_C(TI-6111C) 이탈 구간 정량화 — 목표대역 밖 체류시간 %·이탈 크기·빈도, 그리고 feed 변화/SP 이봉전환/주야와의 상관. 이게 기존 작업플랜-민감단온도-전환복귀제어 작업라인의 가치(=전환·분산 절감)를 사이징함.
• TICA-6111A.SP 이봉성의 정체 확인 (grade? feed 소스? 주야?) — T_C 이탈과 묶이는지
• (병렬) 처리량 최대화 여력: 제약 한계 대비 feed 깔린 시간대
• realtime 1초급 데이터가 실제로 쌓이는지 확인 (동특성 식별용) — 미확인

---

🔀 방향 전환 (2026-06-12): 제어 outperform → 편의성·리포트 제품화

위 1~4 후보(제어 성능으로 운전원 이기기)는 데이터가 거의 다 닫음. 사용자 결정: "제어를 더 잘한다"가 아니라 "운전원/관리자가 하기 힘든 결정론적 분석·리포트를 자동·셀프서비스로 해주는 편의성" 에 포커스. ← 이쪽이 더 돈에 가깝고 방어 가능.

통찰: 오늘 한 작업 자체가 제품의 프로토타입

오늘 세션에서 내가 한 일 = 기간 선정 → 드롭아웃/양자화 필터 → 효율·잔차·편차·재정착을 결정론 SQL로 계산. 이걸 운전원이 버튼으로 하게 만드는 것이 제품. DCS/MES가 못 하고 전산팀을 안 거침.

제품 = 3개 아이디어가 한 파이프라인으로 체인

캡처(fastRecord) → 결정론 계산(메트릭) → 시각화(온도프로파일 방식) → 운전원 엑셀폼 export — 전 과정이 전산팀/MES 우회, 운전원 소유.

1. 시각적 셀프서비스 분석 — 온도프로파일처럼 "기간 선택 → 효율/제어잔차/수율/편차를 자동 계산·시각화 → 특정시각 문제 즉시 확인". 작업외 시간↓.
2. 운전원-정의 엑셀폼 리포트 (= 돈) — 현 파이프라인(Experion→DB→MES→폼)은 컬럼 하나 바꾸는 데도 전산팀 협의·의도설명·장기 리드타임·재작업. 대안: 운전원이 만든 엑셀 폼을 계약(contract)으로 삼아, DB에서 Daily/Monthly/Yearly(컬럼별 에너지효율·제어잔차·수율…)를 계산해 그 폼에 즉시 꽂아줌. 포맷 즉시 변경 = 상품성.
3. ★fastRecord = 빠진 주춧돌 — UI fastRecord(태그·간격 s/min·기간 선택 레코딩)가 결정론 로직과 결합하면 60초 history로 불가능한 동특성·루프진단(FOPDT τ/deadtime, 오버슈트, 밸브 stiction/헌팅)이 열림. 외과적 step/bump test 셀프서비스 = 제어벤더가 비싸게 파는 카테고리. 보너스: 고해상 전환캡처 = SteamAdvisor/모델 학습 데이터 → 편의성으로 팔며 AI운전원 연료 축적(같은 기능 2번 일함).

결정적 기술 사실 (MVP 성립 근거)

• fast_record와 history_table가 동일 long 포맷(tagname, recorded_at, value) → 메트릭 SQL이 소스 테이블만 교체해 양쪽에서 그대로 작동 = "해상도 가변"이 공짜.
• SheetJS(xlsx.full.min.js) 이미 클라이언트 탑재 → 엑셀폼 읽기/쓰기 인프라 존재.
• FastController/FastSession/fast_record 가동 중(start/stop/sessions, 백그라운드 sampling 루프).
• 의미층(moat) 이미 존재: tag_metadata + KB 문서(단일 진실원) + loop→필드계기 매핑 + pid_equipment. ← "컬럼 하나 즉시 변경"을 가능케 하는 핵심(전산팀이 매번 수작업 재구성하는 부분).

설계 철칙

• 해상도-인지: 모든 메트릭 출력에 (source, sampling_ms, n, cleaned_fraction) 메타 동봉 — 1초 리포트 vs 60초 리포트가 사과-오렌지 안 되게.
• 결정론 검증 게이트(메모리): 셀 무음 공란/날조 금지, 모든 셀이 메트릭+SQL로 추적, 실패는 명시적 에러.
• 메트릭/매핑은 레지스트리·config (하드코딩 아님) → "컬럼 변경 = 폼/레지스트리 편집, 전산팀 0".

→ MVP 아키텍처 상세: 작업플랜-셀프서비스-분석리포트-MVP.md