keun90 님의 블로그

SECS/GEM 시뮬레이터 - 테스트 시나리오SECS/GEM Equipment–MES 통신 데모 구현기

keun90 — Fri, 8 May 2026 20:43:14 +0900

프로젝트 소개

반도체 제조 현장에서 9년간 MES 개발을 담당하면서, 장비와 MES가 어떻게 통신하는지 직접 구현해보고 싶었습니다. 이 프로젝트는 SEMI 국제 표준인 SECS/GEM 프로토콜을 사용하여 장비 시뮬레이터와 MES 호스트가 실제 TCP 통신을 주고받는 풀스택 데모입니다.

단순한 Mock이나 가상 통신이 아닌, 실제 Secs4Net 라이브러리를 이용한 HSMS TCP 소켓 통신으로 구현했습니다.

.NET 8 Angular 17 SECS/GEM SignalR SEMI E30 HSMS TCP

실행 화면

SECS/GEM이란?

SECS/GEM은 반도체 장비와 MES(Manufacturing Execution System) 간의 통신을 정의하는 SEMI 국제 표준입니다. ASML, Applied Materials 같은 장비 업체와 삼성전자, SK하이닉스 같은 FAB에서 모두 사용하는 사실상의 업계 표준입니다.

표준	역할
SEMI E5 (SECS-II)	메시지 포맷 정의 (Stream/Function 번호, Item 타입, 데이터 구조)
SEMI E37 (HSMS)	TCP/IP 전송 계층 (연결 관리, 세션, 메시지 프레이밍)
SEMI E30 (GEM)	장비-MES 간 행동 규약 (상태머신, 이벤트 리포트, 알람, 레시피)

시스템 아키텍처

3개의 독립 프로세스가 각각 다른 포트에서 실행됩니다.

┌─────────────────────────────────────┐
│  Angular UI  (localhost:4200)        │
│  SignalR Connected  ●               │
│  ┌──────────┐ ┌───────────────────┐ │
│  │ Scenario │ │ GEM State Diagram │ │
│  │  Panel   │ │   Trace Chart     │ │
│  └──────────┘ └───────────────────┘ │
└──────────┬──────────────────────────┘
           │ HTTP REST  &  SignalR WS
           ▼
┌─────────────────────────────────────┐
│  Host MES API  (localhost:5001)      │
│  ScenarioOrchestrator               │
│  EventSubscriber → MessageBroadcaster│
└──────────┬──────────────────────────┘
           │ SECS/HSMS TCP (SEMI E37)
           ▼
┌─────────────────────────────────────┐
│  Equipment Simulator  (:5000/:5002)  │
│  GemStateMachine  ProcessSimulator  │
│  S1F13 / S2F33~37 / S6F11 / S5F1   │
└─────────────────────────────────────┘

서비스	포트	프로토콜
Equipment HSMS (장비)	5000	SECS/GEM TCP
Equipment HTTP (이벤트 트리거)	5002	REST
Host MES API	5001	REST + SignalR WS
Angular Frontend	4200	HTTP

핵심 구현 내용

① GEM 상태머신 (SEMI E30)

SEMI E30 표준은 장비가 두 가지 상태를 동시에 유지하도록 규정합니다. Stateless 라이브러리로 허용된 전이만 선언하여, 잘못된 상태 전이 시 예외가 자동 발생하도록 구현했습니다.

// 통신 상태 (CommState)
NotCommunicating ──(S1F13)──► Communicating
Communicating    ──(연결 단절)──► NotCommunicating

// 공정 상태 (ProcessState)
Idle ──► Setup ──► Ready ──► Executing ──► Idle
                                 │
                              (알람) ──► Pause ──► Executing

② 동적 Report 설정 (S2F33/S2F35/S2F37)

GEM의 핵심 설계 철학입니다. 장비 코드 수정 없이 MES가 런타임에 "어떤 이벤트 때 어떤 데이터를 보내라"를 지시합니다.

S2F33 — Report 정의
  "RPTID #1001 = [LOT_ID, PPID, START_TIME]"
  "RPTID #1002 = [LOT_ID, WAFER_COUNT, END_TIME, RESULT]"

S2F35 — 이벤트 연결
  "PROCESS_START(CEID=2) 발생 시 → RPTID #1001 전송"
  "PROCESS_END(CEID=3) 발생 시  → RPTID #1002 전송"

S2F37 — 이벤트 활성화
  "CEID=1,2,3,4 감시 시작"

③ S6F12 응답 우선 처리 — T3 타이머 데드락 방지

장비의 SendAsync(S6F11)은 S6F12를 받을 때까지 블로킹됩니다. Host가 S6F12 응답보다 SignalR 브로드캐스트를 먼저 처리하면 T3 타이머(45초) 초과로 통신이 단절됩니다. 현업에서 실제로 발생하는 패턴입니다.

// 잘못된 순서 — T3 타이머 위험
await broadcaster.BroadcastAsync(msg);  // ← 여기서 실패하면 S6F12가 영원히 안 감
await secsGem.SendAsync(reply);

// 올바른 순서 — S6F12 먼저
await secsGem.SendAsync(reply);         // ← T3 타이머 해제
await broadcaster.BroadcastAsync(msg);  // ← 그 다음 UI 업데이트

SECS 메시지 전체 흐름

HOST                           EQUIPMENT
 │──── S1F13 (통신 수립) ──────────►│
 │◄─── S1F14 (수락)  ──────────────│
 │──── S2F33 (리포트 정의 ×3) ─────►│
 │──── S2F35 (이벤트 연결 ×3) ─────►│
 │──── S2F37 (이벤트 활성화) ──────►│
 │                                  │
 │◄─── S6F11 (CarrierArrived) ─────│  CEID=1
 │──── S2F41 (PP-SELECT) ──────────►│  레시피 선택
 │◄─── S6F11 (ProcessStart) ───────│  CEID=2  → Track-In
 │◄─── S6F11 (Trace ×N) ───────────│  CEID=4  → 온도/압력 실시간
 │◄─── S5F1  (Alarm Set)  ─────────│  ALCD=0x80 [alarm 시나리오]
 │◄─── S5F1  (Alarm Clear) ────────│  ALCD=0x00
 │◄─── S6F11 (ProcessEnd)  ────────│  CEID=3  → Track-Out

3가지 자동 시나리오

시나리오	LOT	레시피	웨이퍼	알람	시간
Normal Process Run	LOT-2026-001	RCP-PHOTO-A1	25매	없음	~15초
Alarm Recovery	LOT-2026-002	RCP-PHOTO-A1	25매	고온 알람	~23초
Alternative Recipe	LOT-2026-003	RCP-PHOTO-B2	13매	없음	~10초

기술 스택

Backend (.NET 8 / C#)

ASP.NET Core 8.0
Secs4Net 2.4.4 (HSMS/SECS-II)
Stateless 5.20.1 (상태머신)
SignalR (WebSocket hub)
Serilog (구조화 로깅)

Frontend (Angular 17)

Angular 17.3.0
@microsoft/signalr 10.0.0
RxJS 7.8.0
TypeScript 5.4.2
순수 SVG 차트 (외부 라이브러리 없음)

UI 대시보드 구성

컴포넌트	설명
State Panel	COMM STATE / PROCESS STATE 실시간 색상 표시
GEM State Diagram	SEMI E30 상태 전이 SVG 시각화 (현재 상태 강조)
Message Log	S#F# 메시지 타임스탬프 테이블 (방향 표시)
Trace Chart	온도 / 가스유량 / 압력 실시간 라인 차트 (SVG)
Alarm Panel	알람 발생/해제 목록 (ALID, 알람 텍스트)
Process History	Track-In/Out 이력 테이블 (LotId, Wafer, 시각, 결과)
Scenario Results	실행 완료 시나리오 결과 카드 (PASS/FAIL, 소요시간)

실행 방법

터미널 3개를 열어 순서대로 실행합니다.

# Terminal 1 — Equipment Simulator (먼저 실행)
cd src/SecsGemDemo.Equipment
dotnet run

# Terminal 2 — Host MES API
cd src/SecsGemDemo.Host.Api
dotnet run

# Terminal 3 — Angular Frontend
cd src/SecsGemDemo.Frontend
npm install && npm start

브라우저에서 http://localhost:4200 접속 후 시나리오를 선택하고 Run 버튼을 클릭합니다.

마치며

이 프로젝트를 통해 MES와 장비가 통신하는 구조를 단순 이론이 아닌 동작하는 코드로 직접 확인할 수 있었습니다. 특히 S2F33/35/37의 동적 Report 설정 메커니즘과 T3 타이머 기반의 블로킹 통신 구조는 현업에서 가장 자주 마주치는 패턴이라 직접 구현하면서 많이 배웠습니다.

향후 1:N 다중 장비 지원, FDC 연동, 시계열 DB(InfluxDB) 연동으로 확장해볼 계획입니다.

소스코드 (GitHub)

github.com/KEUN-KEUN/lam-mes-secs-gem-demo

BriefStock 개발일지 #5 - 실사용이 드러낸 3가지 함정 — yfinance 지연, LLM JSON 중첩, 캐시 동시성 (Phase 7)

keun90 — Fri, 17 Apr 2026 20:20:03 +0900

BriefStock 개발일지

Phase 7: 데이터 신선도 · 비용 최적화 · 유튜브 파싱 안정화

KOSPI 실시간 보정 · 전일 대비 변동률 · Claude API 비용 80% 절감 설계 · 유튜브 JSON 파싱 복구
15개 파일, +1,033줄 / -234줄 변경

프로젝트 진행 현황

Phase 6까지 완료한 상태에서, 실사용 중 발견된 데이터 정확성·비용·안정성 이슈를 집중 해결했습니다.

Phase	내용	상태
Phase 0~1	환경 세팅 + 앱 골격	완료
Phase 2~3	포트폴리오 + AI 투자 브리핑	완료
Phase 3.5~3.9	UI 리디자인 + 코드 품질 + 대시보드 레이아웃	완료
Phase 4	유튜브 채널 분석	완료
Phase 5	Supabase Auth + 배포 준비	완료
Phase 6	포트폴리오 심층 분석 + 전문가 인사이트	완료
Phase 7	데이터 신선도 + 비용 최적화 + 유튜브 안정화	이번 세션

01. KOSPI 지수가 하루 늦게 보이던 문제

실사용 중 "코스피가 오늘 하락 중인데 대시보드에는 상승으로 나온다"는 문제를 발견했습니다.

문제: yfinance KOSPI 데이터 1~2일 지연

yfinance의 ^KS11 history는 4/15까지만 반환되고, last_price는 4/16 종가를 보여주는 상황. 오늘(4/17) 데이터가 없었습니다.

prev_close도 4/15 종가라서 변동률 계산 자체가 틀림.

해결: pykrx KODEX 200 ETF 역산

pykrx의 인덱스 API가 깨져 있어, KODEX 200 ETF(069500)의 당일 OHLCV 변동률을 구한 뒤 yfinance KOSPI last_price에 적용하는 방식으로 해결했습니다.

services/market_data.py — KOSPI 조회 로직 1) pykrx로 KODEX200 ETF OHLCV 조회 (당일 데이터 포함) 2) ETF 전일 대비 변동률 계산 (예: -0.68%) 3) yfinance KOSPI last_price를 전일 종가로 사용 4) 전일 종가 × (1 + 변동률) = 오늘 추정 KOSPI 결과: KOSPI 6,185.95 (전일 6,226.05 대비 -0.64%) source: "KRX (pykrx+yfinance)"

시장 지표 캐시

4시간 → 10분

종목 분석 캐시

4시간 → 30분

KOSPI 지연

1~2일 → 당일

02. 포트폴리오 전일 대비 변동률 추가

기존에는 평균 매입가 대비 수익률만 보여줬습니다. "오늘 얼마나 올랐는지/빠졌는지"를 즉시 확인하고 싶다는 니즈.

BE: prev_close + daily_change_pct

services/price.py가 현재가뿐 아니라 전일 종가도 함께 반환하도록 확장. KR 종목은 pykrx OHLCV에서, US 종목은 yfinance fast_info.previous_close에서 가져옵니다.

routers/portfolio.py에서 (현재가 - 전일종가) / 전일종가 × 100으로 변동률 계산.

FE: 이중 수익률 표시

종목 카드 우측에 전일 대비(▲/▼)와 평단 대비(배지) 두 가지를 함께 표시합니다.

삼성전자                      ₩216,000
005930 · 50주 · 평균 ₩200,000    ▼0.69% +8.00%
                                 전일대비 평단대비

03. Claude API 비용 최적화

3일간 briefings 테이블을 조사했더니, 하루에 22건이나 저장된 날이 있었습니다. 캐시가 있는데도 중복 호출이 발생.

문제: 동시 요청 시 중복 Claude 호출

사용자가 대시보드를 열면 뉴스 브리핑 + 전문가 분석이 동시 요청됩니다. 캐시 확인 → 없음 → Claude 호출이 두 요청 모두에서 실행되어 같은 분석이 2번 생성·저장.

해결 1: 사용자별 asyncio.Lock

briefing.py와 asset_management.py에 사용자 ID별 Lock을 추가. 같은 사용자의 동시 요청은 첫 번째가 완료될 때까지 대기 → 두 번째는 캐시 히트.

해결 2: ANTHROPIC_FAST_MODEL 환경변수

구조화 JSON 출력(유튜브/전문가 분석)에는 Haiku로 충분합니다. .env에 한 줄 추가하면 해당 호출만 경량 모델로 전환.

# .env (API tier 업그레이드 후 활성화) ANTHROPIC_FAST_MODEL=claude-haiku-4-5-20251001 # 모델 결정 로직 뉴스 브리핑 → ANTHROPIC_MODEL (Sonnet) — 품질 중요 유튜브 분석 → ANTHROPIC_FAST_MODEL (Haiku) — JSON 구조화 전문가 인사이트 → ANTHROPIC_FAST_MODEL (Haiku) — JSON 구조화

항목	기존	최적화 후
중복 호출	하루 최대 22건	최대 3건 보장
유튜브/전문가 모델	Sonnet (고비용)	Haiku 전환 가능 (80% 절감)
일일 비용 (예상)	~$0.08 + 중복	~$0.04

04. 유튜브 JSON 파싱 안정화

유튜브 분석 결과가 빈 화면이거나 raw JSON이 그대로 노출되는 문제.

문제: Claude가 JSON을 중첩 반환

Claude에게 JSON 출력을 요청했더니, consensus_summary 값 안에 전체 JSON을 코드블록으로 감싸서 넣어버림. 외부 래퍼는 빈 배열만 남고, 실제 데이터는 문자열 속에 갇힌 구조.

실제 DB에 저장된 깨진 데이터: { "consensus": "neutral", ← 외부 래퍼 (빈 기본값) "consensus_summary": "```json\n{ ← 여기 안에 실제 분석이 통째로! \"consensus\": \"bullish\", \"keywords\": [...], ... }\n```", "keywords": [], ← 비어있음 "channel_summaries": [] ← 비어있음 }

해결: 3단계 파싱 파이프라인

_parse_claude_json() 함수를 신규 작성하여 다양한 형태의 Claude 응답을 모두 처리합니다.

_parse_claude_json() 파싱 파이프라인 1단계: 코드블록 제거 (```json ... ``` → 순수 JSON) 2단계: 중첩 JSON 감지 → consensus_summary가 "{"로 시작하면 내부 JSON 추출 → 내부에 필수 키(consensus, keywords 등)가 있으면 대체 3단계: 잘린 JSON regex 폴백 → 불완전한 JSON에서 consensus, consensus_summary 추출 → 완전한 keyword 객체만 regex로 복구

프롬프트 강화

근본 원인 방지를 위해 프롬프트에 명시적 제약을 추가했습니다:

• "반드시 순수 JSON만 출력. ```json 코드블록으로 감싸지 마세요"

• "consensus_summary 값은 반드시 일반 텍스트 문장이어야 합니다"

• FE에서도 방어: consensus_summary가 { 또는 ```로 시작하면 렌더링 차단

05. 변경 파일 요약

15개 파일, +1,033줄 / -234줄

파일	변경 내용
`services/market_data.py`	KOSPI pykrx 역산, 캐시 10분
`services/price.py`	prev_close 함께 반환
`services/stock_analysis.py`	캐시 30분
`routers/portfolio.py`	daily_change_pct 추가
`services/claude_client.py`	model_override + get_fast_model()
`services/briefing.py`	사용자별 Lock
`services/asset_management.py`	사용자별 Lock + fast model
`services/youtube.py`	파싱 파이프라인 + 프롬프트 강화
`backend/main.py`	0.0.0.0 바인딩
`frontend/src/lib/api.ts`	타입 확장
`frontend/.../PortfolioList.tsx`	전일대비 ▲/▼ 표시
`frontend/.../YouTubeSection.tsx`	JSON 렌더링 차단, 미사용 코드 제거
`.env.example`	ANTHROPIC_FAST_MODEL 가이드
`HANDOFF.md`	Phase 7 작업 기록
`docs/dashboard-review-prompt.md`	전문 투자자 관점 검토 프롬프트

06. 회고: 실사용이 드러내는 문제들

Phase 6까지는 "기능을 만드는" 단계였다면, Phase 7은 "실제로 쓰면서 고치는" 단계였습니다.

배운 점

1. 데이터 소스를 맹신하지 말 것. yfinance가 한국 시장 데이터를 1~2일 지연 반환한다는 건 코드만 봐서는 알 수 없었습니다. 사용자가 "코스피가 하락 중인데 상승으로 나온다"고 말해줘야 발견. 데이터 파이프라인에는 반드시 교차 검증이 필요합니다.

2. LLM의 JSON 출력은 신뢰할 수 없다. "JSON만 출력하세요"라고 요청해도 Claude는 코드블록으로 감싸거나, 값 안에 JSON을 중첩하거나, 출력을 중간에 자릅니다. 프롬프트 + 파싱 + FE 방어를 3중으로 해야 안정적입니다.

3. 캐시가 있어도 동시성을 고려해야 한다. 일별 캐시가 적용되어 있었지만, 대시보드 로드 시 여러 컴포넌트가 동시에 API를 호출하면서 캐시 미스 구간에서 중복 생성이 발생했습니다. Lock 한 줄로 비용이 절반 이상 줄었습니다.

다음 단계: Claude API 크레딧 충전 후 ANTHROPIC_FAST_MODEL=claude-haiku-4-5-20251001 활성화로 비용 80% 추가 절감. 그리고 docs/dashboard-review-prompt.md에 정리한 전문 투자자 관점 검토 프롬프트로 대시보드 고도화를 진행할 예정입니다.

BriefStock 개발일지 #4 - 인증 연동·포트폴리오 심층 분석·데이터 정확성 개선 (Phase 5~6)

keun90 — Tue, 14 Apr 2026 19:50:54 +0900

BriefStock 개발일지 #4

인증 연동 · 포트폴리오 심층 분석 · 데이터 정확성 개선

Phase 5 배포 준비 + Phase 6 고도화 | 2026-04-14

01 오늘 한 일 요약

이번 세션에서는 크게 두 갈래로 작업했습니다.

Phase 5 (배포 준비): Supabase Auth JWT 인증을 전체 API에 연동하고, 로그인/로그아웃 UI를 추가했습니다. 하드코딩되어 있던 user_id를 제거하고 실제 인증 토큰 기반으로 전환했습니다.

Phase 6 (고도화): 포트폴리오 심층 분석 엔진을 새로 구축하고, 기존 코드의 데이터 정확성 버그 4건을 수정했습니다. AI 프롬프트를 '추측 금지, 수치 근거 필수' 원칙으로 전면 개편했습니다.

02 Phase 상태

Phase	내용	상태
0~1	환경 세팅 + 앱 골격	완료
2	포트폴리오 CRUD + 시세	완료
3	AI 투자 브리핑 + 리스크	완료
3.5~3.9	UI 리디자인 + 코드 품질	완료
4	유튜브 컨센서스 분석	완료
5	배포 준비 (Auth 연동)	완료
6	고도화 (심층 분석)	진행 중

03 Phase 5 — 배포 준비

Supabase Auth 인증 연동

BE: JWT 인증 미들웨어

routers/auth.py에 get_current_user_id 의존성을 추가하여 모든 API 엔드포인트에서 Supabase JWT 토큰을 검증합니다. Authorization 헤더가 없거나 유효하지 않으면 401을 반환합니다. DEV_USER_ID 환경변수 폴백으로 개발 편의성도 유지했습니다.

FE: 로그인 게이트 + 자동 토큰 주입

AuthProvider가 Supabase 세션을 감시하고, api.ts의 모든 fetch 요청에 자동으로 JWT를 주입합니다. 미로그인 시 LoginForm이 표시되고, 로그인 후 대시보드로 전환됩니다.

backend/routers/auth.py — JWT 인증 frontend/src/components/auth/AuthProvider.tsx — 세션 관리 frontend/src/components/auth/LoginForm.tsx — 로그인 폼 frontend/src/lib/api.ts — 자동 JWT 헤더 주입 page.tsx — 로그인 게이트 + 로그아웃 + 다크/라이트 테마 토글

04 Phase 6 — 포트폴리오 심층 분석

신규 분석 엔진

1 portfolio_analysis.py — yfinance 기반 정량 분석
종목별: 배당 이력/CAGR, 베타, 변동성, MDD, 샤프 비율, 52주 위치
포트폴리오: 공분산 기반 변동성, 섹터/지역/시가총액 분포, 상관관계, 블랙스완 시나리오, 기회비용(vs S&P500/KOSPI)

2 asset_management.py — Claude AI 분석 (데이터 기반)
건강 점수(0~100), 리밸런싱 가이드, DRIP 시뮬레이션(10/20/30년)
모든 문장에 수치 근거 필수, 추측/조언 표현 금지

3 AssetManagement.tsx — 포트폴리오 분석 탭 UI
자산 총괄(도넛 차트), 배당 분석(캘린더), 위험도(게이지+테이블), 상관관계, 블랙스완, 기회비용, 리밸런싱, 전문가 인사이트, DRIP

데이터 정확성 버그 수정 4건

버그	원인	수정	영향
배당수익률 113% 표시	yfinance가 이미 % 값(1.13)을 반환하는데 ×100을 또 적용	×100 제거	삼성전자 113% → 1.13%
NaN JSON 에러 + CORS 누락	yfinance 반환값에 NaN 포함 → json.dumps 실패 → 500 에러가 CORS 미들웨어 밖에서 발생	_sanitize() 함수로 NaN/Inf를 None 치환	포트폴리오 분석 탭 로딩 실패 해결
뉴스 브리핑에 JSON 표시	briefings 테이블에 전문가 분석 JSON이 섞여 캐시 조회 시 JSON 반환	마크다운만 필터링 (JSON 시작 제외)	AI 종합 판단에 정상 마크다운 표시
샤프 비율 부정확	종목별 샤프의 단순 가중평균 (수학적으로 틀림) + KR/US 거래일 불일치로 공분산 NaN	공분산 행렬 기반 계산 + 날짜 인덱스 정규화	수동 검산과 일치 확인 (변동성 50.0%, 샤프 5.39)

성능 최적화

Before vs After

수정 전: 포트폴리오 분석 탭 진입 → 31초 로딩 스켈레톤 → 한 번에 전부 렌더링
수정 후: 2초 만에 자산/배당/위험도 표시 → 전문가 분석은 백그라운드 로딩

적용 기법:
• FE 병렬 API 호출 (portfolio-analysis + expert-analysis 동시 요청)
• BE 인메모리 캐시 60초 TTL (yfinance 중복 호출 제거)
• Claude max_tokens 2000→3000 + 프롬프트 간결화 (JSON 잘림 방지)

AI 프롬프트 탈추측화

수정 전: "당신은 CFA·CAIA 자격 보유 자산관리 전문가입니다" 수정 후: "당신은 정량 데이터 분석기입니다. 의견이나 추측이 아닌 수치 사실만 서술합니다" 금지: 추측 표현, 투자 조언, 감정적/과장 표현, 데이터에 없는 정보 필수: 모든 문장에 근거 수치 포함, 비교 시 기준 명시, severity 임계값 기준 명시

05 다음 작업

1 Phase 5 완료 — 실제 배포
Vercel(FE) + Railway(BE) 배포, 환경변수 production 분리, CD 파이프라인

2 Phase 6 계속 — 분석 고도화
yfinance 호출 최적화, 전문가 분석 JSON 파싱 안정성, 상관관계 히트맵, 종목 10개+ 성능 프로파일링

3 UX 개선
유튜브 채널 URL 자동 감지, 모바일 반응형 조정, 에러 바운더리 통일

BriefStock 개발일지 #3 | 2026-04-14 | Claude Opus 4.6 + Human 협업

BriefStock 개발일지 #3 - 코드 품질 개선·대시보드 재설계·유튜브 컨센서스 분석

keun90 — Mon, 13 Apr 2026 20:10:10 +0900

BriefStock 개발기 #3

코드 품질 개선 + 대시보드 재설계 + 유튜브 분석 완성

2026.04.13 · Phase 3.7~4

01. Phase 현황

Phase	내용	상태
Phase 0~1	환경 세팅 + 앱 골격	완료
Phase 2	포트폴리오 CRUD + 시세 조회	완료
Phase 3	AI 뉴스 브리핑 + 종목 분석	완료
Phase 3.7~3.9	코드 품질 + 대시보드 + 라이트 모드	오늘 완료
Phase 4	유튜브 분석 (자막 추출 + 컨센서스)	오늘 완료
Phase 5	배포 (Vercel + Railway + Auth)	다음

02. 코드 품질 개선 (7건)

치명적 버그 수정

코스닥 종목 인식 불가

yfinance 심볼이 .KS(코스피)만 지원 → .KQ(코스닥) 자동 폴백 추가. 코스닥 종목도 정상 분석 가능.

Python 3.12 크래시

asyncio.coroutine은 Python 3.11에서 제거됨. 빈 포트폴리오 시 서버 500 에러 → if/else 분기로 안전하게 교체.

보안 개선

️ XSS 취약점 제거

dangerouslySetInnerHTML + 정규식 마크다운 → react-markdown + remark-gfm 전환.

️ 에러 메시지 마스킹

HTTP 응답에 str(e) 노출 → 서버 로그에만 기록, 클라이언트는 한국어 일반 메시지.

성능 + 코드 정리

⚡ RSS 병렬 수집

8개 뉴스 피드 순차 호출 → ThreadPoolExecutor 병렬. 수집 시간 3~5배 단축.

⚙️ 환경변수 정리

Claude 모델 ID 하드코딩 → ANTHROPIC_MODEL 환경변수. CORS origin 동적화.

03. 대시보드 UI 전면 재설계

탭 → 분석가 워크플로우

기존 3탭 구조(포트폴리오|브리핑|유튜브)를 제거하고, 투자 분석가가 실제로 정보를 소비하는 순서로 재배치했습니다.

① 매크로 지표 — "오늘 시장 분위기는?" ② 포트폴리오 — "내 종목은 어떻게 됐나?" ③ 리스크 경고 — "당장 조치할 게 있나?" ④ 종목 심층 분석 — "왜 이렇게 움직였나?" ⑤ AI 종합 판단 — "그래서 어떻게 해야 하나?" ⑥ 유튜브 컨센서스 — "전문가들은 뭐라고 하나?"

PC 2컬럼 레이아웃

1280px 이상: 메인 컬럼(분석 플로우) + 사이드바(포트폴리오+리스크) sticky 고정
1280px 미만: 단일 컬럼 유지 (모바일 호환)

라이트 모드 전환

Before (다크)

배경 #09090B · 카드 #151518 · 곤색 톤

After (라이트)

배경 #F5F5F7 · 카드 #FFFFFF · 그림자+테두리 · 폰트 확대

추가 기능

VIX 투자 가이드 툴팁 — 각 구간(매우 안정~공포) 위에 마우스를 올리면 투자 행동 가이드 표시

포트폴리오 비중 시각화 — 종목별 컬러 비중 바 + KR/US 지역 비중 표시

지수 표시 수정 — 코스피/S&P/나스닥에서 화폐 기호(₩/$) 제거 → 포인트 단위

04. Phase 4: 유튜브 분석 완성

데이터 파이프라인

채널 등록 (최대 5개) ↓ YouTube RSS 피드 → 채널당 최근 5개 영상 (병렬) ↓ youtube-transcript-api → 한국어/영어 자막 추출 (병렬) ↓ Claude → 개별 영상 투자 요약 (영구 캐시) ↓ Claude → JSON 구조화 "유튜브 컨센서스" (일별 캐시)

구조화된 컨센서스 출력

Claude가 마크다운이 아닌 JSON 구조화 데이터로 응답합니다.

컨센서스 게이지

전체 시장 전망: 강세 / 중립 / 약세

️ 키워드 태그

클릭하면 상세 분석 펼침 (종목, 감성, 언급 채널)

채널별 카드

각 채널의 stance(강세/중립/약세) + 핵심 주장 요약

⚠️ 리스크 & 행동

공통 리스크 요인 + 구체적 행동 가이드

실제 테스트 결과 (삼프로TV + 소수몽키)

컨센서스: 중립 — 전쟁 리스크 + AI/우주 성장 테마 공존

중동 전쟁 4회 비트코인 3회 스페이스X 3회 AI 2회 메모리 반도체 2회 미중 패권경쟁 1회

채널	영상	스탠스	핵심 주장
삼프로TV	4개	중립	전쟁 리스크 경계 + 비트코인 중립자산 + AI 펀더멘털 긍정
소수몽키	4개	강세	스페이스X 상장 + AI 기업가치 폭등 → 투자 기회 적극 제시

05. 다음 계획

우선순위	작업	내용
1	Phase 5: 배포	Supabase Auth + Vercel(FE) + Railway(BE)
2	UX 개선	유튜브 URL→채널ID 자동 감지, 다크/라이트 토글
3	기능 확장	포트폴리오 종목 수정, 알림 기능

변경 파일 18개 · 코드 +1,343줄 / -234줄

기술 스택: Next.js 16 · FastAPI · Supabase · Claude Sonnet · youtube-transcript-api · react-markdown

BriefStock 개발일지 #2 - AI 투자 브리핑 시스템 구축 (매크로·종목분석·리스크·Claude 종합판단)

keun90 — Mon, 13 Apr 2026 07:49:26 +0900

BriefStock 개발일지

Phase 2~3 완료: AI 투자 브리핑 시스템 구축

포트폴리오 시세 조회 · 매크로 대시보드 · 종목 심층 분석 · 리스크 진단 · Claude AI 종합 판단
토스 스타일 다크 UI 전면 리디자인까지

프로젝트 진행 현황

Phase 0~1에 이어 Phase 2~3을 완료했습니다.

Phase	내용	상태
Phase 0	환경 세팅 (FastAPI + Next.js + Supabase + Docker + CI)	완료
Phase 1	앱 골격 (Supabase 연결, API 계약, 라우터 스켈레톤)	완료
Phase 2	포트폴리오 (시세 조회, 수익률 계산, 종목 CRUD UI)	완료
Phase 3	AI 투자 브리핑 (매크로·종목분석·리스크·Claude 종합판단)	완료
Phase 3.5	UI 리디자인 (토스 스타일 전면 개편)	완료
Phase 4	유튜브 분석 (채널 관리, 자막 추출, 시황 분석)	예정
Phase 5	배포 (Vercel + Railway + Supabase Auth)	예정

01. Phase 2 — 포트폴리오 시세 조회

보유 종목의 현재가를 실시간으로 가져와 수익률을 자동 계산합니다.

BE: 시세 조회 서비스

backend/services/price.py — 국내(pykrx)와 해외(yfinance) 종목의 현재가를 비동기로 조회합니다.

backend/services/price.py ├── _get_kr_price() → pykrx 국내 종가 (최근 5영업일 범위) ├── _get_us_price() → yfinance 해외 현재가 └── get_price() → asyncio.to_thread 비동기 래핑 GET /api/portfolio 응답 변경: 기존: { items: PortfolioItem[] } 변경: { items: PortfolioItemWithPrice[] } 추가 필드: current_price, pnl_pct, currency

FE: 포트폴리오 UI

총 평가금액 요약 카드 + 종목별 현재가·수익률 카드 + 종목 추가 폼을 구현했습니다.

총 평가금액

₩2,061,302

수익률 배지

+12.3%

시장 선택

KR / US

02. Phase 3 — AI 투자 브리핑 시스템

증권사 리서치 수준의 투자 분석을 자동화합니다. 4개 데이터 레이어 + Claude AI 종합 판단.

아키텍처: 4-Layer 데이터 수집 → Claude 종합 분석

Layer 1. market_data.py — 매크로 8개 지표 (KOSPI, S&P500, NASDAQ, VIX, USD/KRW, WTI, Gold, US10Y)
Layer 2. stock_analysis.py — 종목별 심층 (펀더멘털·기술적·컨센서스·실적·내부자·기관)
Layer 3. risk_analysis.py — 섹터/지역 집중도, 52주 시나리오, 이벤트 캘린더
Layer 4. news.py — RSS 8개 피드 (연합뉴스, 한경, 매경, 서울경제, 이데일리, Investing.com, CNBC, MarketWatch)

→ briefing.py가 4개 레이어 병렬 수집 → Claude Sonnet 종합 분석 → Supabase 일별 캐싱

매크로 대시보드

글로벌 지수, 환율, 원자재, VIX 공포지수(5단계 게이지), 미국 10Y 국채 금리를 한눈에 표시

종목 심층 분석

Forward P/E, 52주 레인지 바, 애널리스트 목표가·투자의견 분포, 실적 서프라이즈 차트, RSI 게이지

리스크 진단

섹터/지역 집중도 분포 바, 경고 알림(좌측 바), 52주 최악 시나리오, 실적 이벤트 캘린더

AI 종합 판단

위 전체 정량 데이터 + 뉴스를 Claude Sonnet에 전달. 시니어 애널리스트 수준의 서술형 분석 생성

API 엔드포인트 (4개 추가)

GET /api/briefing/market → 매크로 지표 (비용 0원, yfinance) GET /api/briefing/analysis → 종목별 심층 분석 (비용 0원, yfinance) GET /api/briefing/risk → 포트폴리오 리스크 (비용 0원, 계산) GET /api/briefing/news → AI 종합 브리핑 (Claude API, 일 1회 캐싱)

비용 구조: 매크로·종목분석·리스크는 yfinance 무료 데이터만 사용합니다. Claude API 호출은 /api/briefing/news 1개뿐이며, 일별 캐싱으로 하루 ~$0.01 수준입니다.

03. 데이터 신뢰도 검증

yfinance에서 수집 가능한 모든 데이터를 실제 테스트하고 신뢰도를 평가했습니다.

데이터	신뢰도	비고
실적 서프라이즈	100%	역산 검증 완벽 일치, 공시 데이터 기반
기술적 지표 (MA/RSI)	100%	가격 데이터에서 직접 계산
기관 보유	95%	SEC 13F 기반, 최대 분기 지연
내부자 거래	95%	SEC Form 4 기반, US만 지원
애널리스트 컨센서스	90%	40명 커버리지, 1-2주 지연 가능
주가/매크로	85%	정확하나 장중 15-20분 지연
뉴스 RSS	75%	출처 신뢰, 제목 기반 (본문 미수집)

04. Phase 3.5 — 토스 스타일 UI 리디자인

전체 컴포넌트를 토스증권 디자인 원칙에 맞게 전면 개편했습니다.

항목	Before	After
최소 폰트	10px (text-[10px])	11px (caption) / 12px (label)
카드 스타일	1px 테두리	테두리 없음, 배경만
카드 radius	12px	16px
종목 분석 카드	10개 섹션 연속 나열	핵심 상단 + 접기/펼치기 토글
섹션 제목	⚠️ 이모지	이모지 없음, 텍스트만
입력 필드	32px 높이	44px, focus blue border
AI 본문	12px	14px, line-height 1.8

디자인 시스템 유틸리티 클래스

.label → 12px, tertiary (항목 이름) .value → 15px, primary, tabular-nums (수치) .caption → 11px, tertiary (출처, 시간) .card-inner → overlay 배경, radius 10px (카드 내부 영역) .alert-warn → 좌측 3px 빨간 바 + 연한 배경 (경고) .input → 44px 높이, focus blue border .btn-primary→ 48px, blue 배경 .progress-* → 6px 트랙 + 12px 도트 (레인지 바)

05. 기술 스택 현황

Frontend

Next.js 16

Backend

FastAPI

Database

Supabase

Claude Sonnet

시세 데이터

yfinance

뉴스

RSS 8개 피드

backend/ ├── services/ │ ├── market_data.py ← 매크로 8개 지표 │ ├── stock_analysis.py ← 종목별 종합 분석 │ ├── risk_analysis.py ← 포트폴리오 리스크 │ ├── news.py ← RSS 8개 피드 │ ├── briefing.py ← 전체 수집 → Claude 분석 │ ├── price.py ← 시세 조회 │ ├── portfolio.py ← 포트폴리오 CRUD │ └── supabase.py ← DB 클라이언트 frontend/src/components/ ├── briefing/ │ ├── BriefingPage.tsx ← 전체 조합 │ ├── MarketOverview.tsx ← 매크로 대시보드 │ ├── StockAnalysisCard.tsx← 종목 분석 (접기/펼치기) │ ├── RiskDashboard.tsx ← 리스크 진단 │ └── AiBriefing.tsx ← AI 종합 판단 └── portfolio/ ├── PortfolioList.tsx ← 포트폴리오 목록 └── AddForm.tsx ← 종목 추가 폼

06. 다음 작업 (Phase 4~5)

Phase 4: 유튜브 분석

시황 채널 등록 (최대 5개) → youtube-transcript-api 자막 추출 → Claude 분석 → 컨센서스 요약

Phase 5: 배포

Supabase Auth 연동 (하드코딩 user_id 제거) → Vercel(FE) + Railway(BE) 배포 → CD 파이프라인

GitHub: github.com/KEUN-KEUN/briefstock — 전체 소스코드 공개

BriefStock 개발기 #1 - Claude Code로 하루 만에 풀스택 골격 + CI/CD 완성하기

keun90 — Fri, 10 Apr 2026 20:14:27 +0900

사이드프로젝트 Claude Code 멀티에이전트

BriefStock — AI 투자 어시스턴트 개발기

Claude Code로 백엔드·프론트엔드를 동시에 개발하고, CI/CD까지 구성한 하루의 기록

01. 프로젝트 목적

왜 만드는가?

토스증권, 한국투자증권 등 여러 플랫폼에 분산된 주식을 한 곳에서 보고 싶었다. 그리고 매일 아침 내가 보유한 종목과 관련된 뉴스와 유튜브 시황 채널을 Claude AI가 자동으로 요약해주면 어떨까 하는 아이디어에서 출발했다.

핵심 기능 (목표)

① 멀티 플랫폼 포트폴리오 통합 관리
② 보유 종목 기준 AI 뉴스 브리핑 (하루 1회 자동 생성)
③ 유튜브 시황 채널 요약 — 채널별 컨센서스 파악
④ 수익률·현재가 실시간 조회 (KR: pykrx / US: yfinance)

02. 기술 스택

FRONTEND

Next.js 16

FRONTEND

TypeScript

FRONTEND

Tailwind CSS

BACKEND

FastAPI

BACKEND

Python 3.12

BACKEND

Supabase

Claude API

INFRA

GitHub Actions

03. 오늘 완료한 작업

Phase	작업 내용	상태
Phase 0 환경 세팅	FastAPI 골격 (라우터 3개), Next.js 16 App Router, Supabase 스키마 4개 테이블, Docker Compose, 토스증권 참조 다크 디자인 시스템 (CSS 변수 체계)	완료
Phase 1 앱 골격	Supabase 클라이언트 연결 (싱글톤 패턴), 포트폴리오 CRUD API 실사 테스트 통과 (11개 엔드포인트), 전체 API 타입 정의 및 프론트 클라이언트 연결	완료
멀티에이전트 체계 구성	CLAUDE.md 계층 구성 (루트 → FE → BE), /fe /be /qa /handoff 슬래시 커맨드, PostToolUse 자동 검증 훅 (validate.sh)	완료
GitHub + CI	Private 레포 생성 (KEUN-KEUN/briefstock), GitHub Actions — Backend(pytest) + Frontend(tsc+build) 병렬, main push 시 자동 실행, 첫 CI 통과 확인	완료
Phase 2~5	시세 조회, AI 브리핑, 유튜브 분석, Vercel/Railway 배포	예정

04. 프로젝트 폴더 구조

briefstock/
  ├── .claude/
  │   ├── commands/                                                                                                         
  │   │   ├── be.md          # /be 백엔드 에이전트 커맨드
  │   │   ├── fe.md          # /fe 프론트엔드 에이전트 커맨드                                       
  │   │   ├── qa.md          # /qa 테스트 에이전트 커맨드                                           
  │   │   └── handoff.md     # /handoff 핸드오프 커맨드
  │   ├── hooks/                                                                                                            
  │   │   └── validate.sh    # PostToolUse 자동 검증 훅
  │   └── settings.json      # 훅 설정                                                              
  │                                                                                                                         
  ├── backend/                                                                                
  │   ├── routers/                                                                                                          
  │   │   ├── portfolio.py   # 포트폴리오 CRUD API
  │   │   ├── briefing.py    # 뉴스 브리핑 API                                                      
  │   │   └── youtube.py     # 유튜브 분석 API                                                      
  │   ├── services/                           
  │   │   ├── supabase.py    # DB 클라이언트 싱글톤                                                 
  │   │   └── portfolio.py   # 포트폴리오 비즈니스 로직
  │   ├── main.py            # FastAPI 앱 진입점                                                    
  │   ├── pyproject.toml                      
  │   └── CLAUDE.md          # BE 에이전트 전용 규칙                                                
  │                                           
  ├── frontend/                                                                               
  │   ├── src/    
  │   │   ├── app/                                                                                                          
  │   │   │   ├── page.tsx   # 메인 페이지 (3탭 레이아웃)
  │   │   │   ├── layout.tsx                                                                                                
  │   │   │   └── globals.css # 토스 참조 다크 디자인 토큰
  │   │   ├── components/                     
  │   │   │   └── ui/        # 공통 UI 컴포넌트                                                     
  │   │   └── lib/                            
  │   │       ├── api.ts     # 전체 API 클라이언트 + 타입                                           
  │   │       └── supabase.ts                 
  │   ├── package.json                                                                                                      
  │   └── CLAUDE.md          # FE 에이전트 전용 규칙
  │                                                                                                                         
  ├── supabase/
  │   └── schema.sql         # 4개 테이블 DDL                                                       
  │                                                                                                                         
  ├── .github/workflows/
  │   └── ci.yml             # BE 테스트 + FE 빌드 병렬 CI                                          
  │                                           
  ├── CLAUDE.md              # 루트 — API 계약 + 전역 규칙                                          
  ├── HANDOFF.md             # 세션 간 인수인계 문서
  └── docker-compose.yml

05. 멀티에이전트 아키텍처

Claude Code에서 FE 에이전트와 BE 에이전트를 역할 분리해 운영했다. API 계약(CLAUDE.md)이 두 에이전트의 유일한 접점이다.

┌─────────────────────┐        ┌─────────────────────┐                            
  │   FE Agent          │        │   BE Agent          │
  │   소유: frontend/   │◄──────►│   소유: backend/    │                                      
  │        src/**       │  API   │        routers/**   │
  │        components/  │  계약  │        services/**  │                                      
  └─────────────────────┘        └─────────────────────┘                                       
            │                               │                                                                               
            └──────────── Supabase ─────────┘

# .claude/hooks/validate.sh — 코드 수정 후 자동 검증                                   
  if [[ "$FILE" == backend/* ]]; then
    uv run python -c "from main import app"   # BE import 체크             
  elif [[ "$FILE" == frontend/src/* ]]; then                                                        
    pnpm exec tsc --noEmit                # FE 타입 체크                                            
  fi

06. 오늘 작업 평가

✅ 잘 된 점

하루 만에 풀스택 골격 + CI까지 완성. 혼자 했다면 수일이 걸렸을 작업을 AI와 함께 몇 시간 만에 완료했다.

✅ 잘 된 점

CLAUDE.md 계층 구조로 에이전트 역할을 명확히 분리. FE/BE가 서로의 파일을 건드리지 않는 소유권 규칙이 효과적이었다.

✅ 잘 된 점

PostToolUse 훅으로 코드 수정 즉시 자동 검증. 에러를 사람이 발견하기 전에 Claude가 먼저 잡았다.

✅ 잘 된 점

HANDOFF.md + git push 패턴으로 WSL2 → 맥북 크로스 PC 작업 연속성을 확보했다.

⚠️ 개선 필요

병렬 에이전트 실행이 권한 문제로 실패. 루트 디렉토리에서 세션을 시작하지 않으면 서브 에이전트가 다른 디렉토리를 수정하지 못한다.

⚠️ 개선 필요

CI에서 실제 Supabase 연결 테스트가 없다. 더미 환경변수로만 검사해서 DB 쿼리 오류는 배포 전까지 발견되지 않는다.

07. Claude Code 활용율을 높이는 방법

오늘 직접 적용하고 효과를 확인한 패턴들이다. 어떤 프로젝트에도 그대로 적용할 수 있다.

CLAUDE.md에 API 계약을 먼저 써라

Claude는 현재 파일 상태를 읽어서 판단한다. "어떻게 만들어줘" 대신 구체적인 입출력 타입, 엔드포인트, 응답 형식을 CLAUDE.md에 적어두면 질문 없이 바로 구현한다. 오늘 이 방식으로 11개 API를 계획대로 구현했다.

슬래시 커맨드로 역할을 고정해라

/be, /fe, /qa 커맨드에 "무엇을 수정할 수 있고, 무엇은 금지"를 명시하면 Claude가 역할을 벗어나지 않는다. "백엔드 파일만 수정 가능, frontend/ 수정 금지"처럼 소유권 규칙을 커맨드 파일에 박아두면 된다.

훅(Hook)으로 검증을 자동화해라

PostToolUse 훅에 validate.sh를 연결하면 Claude가 파일을 수정할 때마다 자동으로 import 체크, tsc 체크를 실행한다. Claude가 실수해도 스스로 오류를 발견하고 수정한다. 사람이 개입할 필요가 줄어든다.

핸드오프 문서로 컨텍스트를 이어라

Claude의 컨텍스트는 세션이 끊기면 사라진다. /handoff 커맨드로 완료 내용과 다음 작업 지시서를 HANDOFF.md에 저장하고 git push하면 다른 PC, 다른 세션에서도 같은 맥락으로 작업을 이어갈 수 있다.

병렬 에이전트는 루트 디렉토리에서 시작해라

Claude Code의 서브 에이전트는 부모 세션의 작업 디렉토리를 기준으로 권한이 결정된다. 멀티에이전트를 병렬로 돌리려면 반드시 프로젝트 루트에서 세션을 시작해야 FE/BE 에이전트 모두 정상 동작한다.

08. 다음 계획

Phase 2 — 포트폴리오 시세 조회 + UI

pykrx(국내) / yfinance(해외)로 현재가 조회 → 수익률 계산 → 토스 스타일 카드 UI로 표시

Phase 3 — AI 뉴스 브리핑

RSS 수집 → 보유 종목 필터링 → Claude API로 요약 → 하루 1회 Supabase 캐싱

Phase 4 — 유튜브 시황 분석

등록한 채널의 최신 영상 자막 추출 → Claude로 컨센서스 요약

Phase 5 — 배포 + CD 파이프라인

Vercel(FE) + Railway(BE) 배포, GitHub Actions CD 연결, Supabase Auth 연동

작성: 2026-04-10 | 개발 환경: WSL2 + Claude Code (claude-sonnet-4-6)

AI 코딩 효율 — 프롬프트 계약서(Prompt Contracts)

keun90 — Fri, 27 Mar 2026 17:59:11 +0900

AI 코딩 실수 방지법 — 프롬프트 계약서(Prompt Contracts)로 바이브 코딩 탈출하기

AI Coding · Prompt Engineering · 2026

AI한테 코딩 맡겼다가
2,400줄 전부 버린 이유

프롬프트를 잘 쓰는 게 아니라, 계약서처럼 설계해야 한다.
바이브 코딩의 함정과 Prompt Contracts의 등장.

원문: Medium @rentierdigital ⏱ 읽기 약 5분

Episode

새벽 2시의 실수

Claude Code에게 Supabase 인증 플로우를 만들어달라고 했다. 돌아온 건 완벽하게 작동하는 Firebase 인증 시스템이었다.

코드는 컴파일됐다. 실행됐다. 심지어 깔끔해 보였다.
하지만 틀린 문제를 풀고 있었다.

피자를 주문했는데 완벽하게 조리된 리조또가 왔다. 기술적으로는 훌륭하다. 근본적으로는 틀렸다.

"나는 Claude Code로 코딩을 한 게 아니라, 도박을 하고 있었다."

Problem

바이브 코딩이란?

자연어로 AI에게 요청하고 결과를 기대하는 방식이다. AI는 컨텍스트 없이도 자신감 200%로 뭔가를 만들어낸다.

# 바이브 코딩의 전형적인 패턴

> "SaaS 대시보드 만들어줘"
→ 14개 파일, 3,000줄 생성 / 원하는 게 아닌 코드
→ 다시 요청 → 또 다시 → 무한 반복

> "로그인 폼 React로 만들어줘"
→ Tailwind + Lucide 아이콘까지 붙은 복잡한 폼 생성
→ 나는 일반 CSS를 원했지만, AI는 알 방법이 없다

AI는 그럴듯해 보이는 코드를 만든다. 그럴듯한 것이 올바른 것과 같지 않을 뿐이다.

Root Cause

바이브 코딩의 3가지 실질적 문제

⚠️

품질 보증 부재

표면적으로는 작동하지만 에러 핸들링 · 보안 검사 · 엣지 케이스 처리가 빠져있는 경우가 많다. 프로덕션에 그대로 올리면 사고난다.

프롬프트 드리프트

기능을 추가하거나 수정할수록 AI가 일관성 없는 스타일, 중복 로직, 호환되지 않는 구조를 만들어낸다. 코드베이스가 점점 망가진다.

시스템 컨텍스트 무시

기존 인증 미들웨어가 어떻게 작동하는지, 세션 관리는 어디에 있는지를 모르는 채로 요청하면 완전히 잘못된 방향이 나온다.

Solution

프롬프트 계약서(Prompt Contracts)란?

코드를 한 줄 쓰기 전에 작성하는 구조화된 명세서.
AI에게 무엇을 만들지, 어떻게 만들지, 무엇을 하면 안 되는지, 결과를 어떻게 검증할지를 사전에 명시한 문서.

핵심 개념은 "프롬프트를 API처럼 다루는 것"이다. 소프트웨어에서 함수를 호출할 때 입력값과 반환값을 모르고 쓰지 않는 것처럼, AI 프롬프트도 명시적인 입력 / 출력 / 실패 조건을 정의해야 한다.

새로운 도구나 소프트웨어가 아니다. AI에게 작업을 넘기기 전에 작성하는 구조화된 텍스트 문서다.

Template

프롬프트 계약서 구조

## ── PROMPT CONTRACT TEMPLATE ──────────────────

## GOAL
무엇을 만드는가 (한 줄로 명확하게)
  예: Supabase RLS 기반 사용자 인증 플로우 구현

## STACK
사용할 기술 스택 명시
  예: Next.js 14, Supabase, Clerk, Convex

## CONSTRAINTS
하면 안 되는 것 (명시적으로 금지)
  예: No Firebase. No Prisma. No Tailwind.
      기존 /lib/auth.ts 패턴을 반드시 따를 것.

## FORMAT
출력 형식 정의
  예: 파일 단위로 분리. 함수마다 JSDoc 주석 포함.
      index.ts → handler.ts → types.ts 순서로 작성.

## FAILURE CONDITIONS
이 결과가 나오면 실패로 간주
  예: - Firebase import 시 실패
      - RLS 정책 없이 직접 쿼리하면 실패
      - 에러 핸들링이 없으면 실패

## ──────────────────────────────────────────────

이 5가지 섹션이 전부다. 10분 작성으로 반복 수정에 드는 몇 시간을 아낄 수 있다.

Comparison

Before vs After

── BEFORE (바이브 코딩) ──────────────────────────

> "Supabase 인증 만들어줘"
결과: Firebase로 완성된 인증 시스템
      → 2,400줄 전부 삭제 → 처음부터 다시


── AFTER (프롬프트 계약서) ───────────────────────

## GOAL: Supabase RLS 기반 인증 플로우
## STACK: Next.js 14, Supabase
## CONSTRAINTS: No Firebase. No 외부 인증 라이브러리.
## FORMAT: 파일 단위 분리, 에러 핸들링 필수
## FAILURE CONDITIONS: Firebase import 시 실패

결과: 첫 번째 시도에 프로덕션 수준 코드 생성
      → 검토 → 배포

항목	❌ 바이브 코딩	✅ 프롬프트 계약서
방식	자연어로 대충 요청	구조화된 명세 사전 합의
결과 예측	불가능	예측 가능
문제 발생 시	전부 다시	조건 수정 후 재실행
AI 역할	도박사	계약 이행자
시간 비용	무한 반복 수정	첫 시도에 근접

Practice

실전 적용 3원칙

4가지 질문에 먼저 답하라

무엇을 바꿔야 하는가 / 어디에서 / 왜 (제약 조건) / 어떻게 검증할 것인가. 이 4가지가 명확하지 않으면 프롬프트를 보내지 마라.

작게 쪼개서 요청하라

데이터 모델 → 핸들러 → 비즈니스 레이어 순으로. "전체 앱 만들어줘"는 도박이다. 기능 단위로 나누면 검증이 가능해진다.

제약 조건은 앞에 넣어라

컨텍스트가 길어질수록 AI는 프롬프트 끝부분을 덜 주목한다. 금지 사항과 핵심 조건은 반드시 프롬프트 앞부분에 배치하라.

Caveat

그래도 알아야 할 한계

⚠ 중요한 경고

프롬프트 계약서도 버그가 될 수 있다.

계약서 자체가 잘못 작성되면, AI는 그 잘못된 명세를 완벽하게 따른다. 계약서가 틀리면 코드도 정확하게 틀린 방향으로 나온다.

결국 계약서를 잘 쓰려면 내가 뭘 원하는지 정확히 알아야 한다. AI는 도구다. 판단은 여전히 사람의 몫이다.

프롬프트 계약서는 새로운 마법이 아니다. 기존 프롬프트 엔지니어링을 더 체계화한 방법론에 가깝다. 하지만 이 사소한 구조화가 결과물의 질을 완전히 바꾼다.

"AI는 도구다.
도구에게 명세서를 주면,
도박이 아니라 납품이 된다."

Prompt Contracts — vibe coding의 종료 선언

Claude Code - VB6 레거시 시스템을 React + Python으로 컨버전하며 느낀 Claude 실전 후기

keun90 — Tue, 10 Mar 2026 22:15:12 +0900

오래된 레거시 시스템을 새로운 기술 스택으로 전환하는 프로젝트에 Claude 활용성을 검증해보기로 했습니다.

기술 스택 선택

Frontend: React Vue와 비교했을 때 학습 곡선이 높다는 것은 알고 있었습니다. 하지만 Claude를 함께 사용한다면 그 장벽이 크게 낮아질 것이라 판단했고, 고민 없이 React를 선택했습니다.

Backend: Python Java와 Python 사이에서 고민했습니다. Java는 유지보수 측면에서 강점이 있고, Python은 Frontend와 동일한 IDE에서 개발할 수 있다는 편의성이 있었습니다. 이번 프로젝트는 대규모 트래픽이나 특별한 성능 요구사항이 없었기 때문에, Claude 활용 검증이라는 목적에 맞게 다루기 편한 Python을 최종 선택했습니다.

작업 방식: 비즈니스 로직과 디자인의 분리

처음부터 비즈니스 로직과 디자인 요소를 철저히 분리해서 작업했습니다. 이렇게 나눈 이유는 Claude의 결과물을 단계별로 꼼꼼하게 검증하기 위해서였습니다.

비즈니스 로직 분석 흐름

기존 레거시 소스 전체를 폴더에 정리
Claude 터미널에서 소스 분석 수행
분석 결과를 별도 파일로 저장

여기서 중요한 포인트가 하나 있습니다. 레거시 시스템에는 주석 처리된 코드가 매우 많습니다. 이 주석들을 분석 대상에 포함시키면 불필요한 내용이 섞여 설계가 흐려집니다. 반드시 주석 처리된 코드는 분석 대상에서 제외하도록 Claude에게 명확히 지시해야 원하는 분석 결과를 얻을 수 있었습니다.

로직 변환 시에는 매 작업마다 아래 문구를 프롬프트에 포함시켰습니다.

"기존 소스 코드의 정상 작동을 보장하면서 변환할 것"

이 한 줄이 생각보다 큰 역할을 합니다.

디자인 구현 흐름

기존 화면을 캡처하여 Claude.ai에 이미지로 업로드
와이어프레임 코드로 변환 요청
변환된 코드를 Claude 터미널에서 React 컴포넌트로 변환
공통 디자인 요소 적용을 위한 style.md 생성 및 관리

style.md는 처음부터 만들어두시는 것을 강력히 권장합니다. 작업 초반에 공통 스타일 기준을 잡아두지 않으면, 나중에 화면마다 일관성이 무너지는 상황이 반드시 생깁니다.

### 와이어프레임 예시 

+-------------------------------------------------------------+
|  Toolbar  [ 조회 ] [ 저장 ] [ 삭제 ] [ 복사 ] [ 엑셀 ] [ 닫기 ] |
+-------------------------------------------------------------+
|  Header   항목A v | 항목B v | 항목C v | 항목D v | 상태 Badge    |
+-------------------------------------------------------------+
|  Tab:  [ 기본 정보 ]  [ 수량/사이즈 ]  [ 소재 정보 ]             |
+--------------+----------------------------------------------+
|  Left Panel  |  수량 Grid                                     |
|              |                                                |
|  기본 정보     |  구분 | 시작일 | 종료일 | 수량 | 금액          |
|  - 콤보 A     |  ------------------------------------------- |
|  - 콤보 B     |  Row                                         |
|  - 콤보 C     |  Row                                         |
|  - 텍스트     |  Row                                          |
|  - 체크박스    |                                              |
|  ----------- |                                               |
|  옵션 그룹    |                                               |
|  ----------- |                                               |
|  소재 정보    |                                               |
|  ----------- |                                               |
|  [ 이미지 ]  |                                                |
+--------------+----------------------------------------------+

실제로 느낀 Claude의 강점

상용 라이브러리 없이 구현 가능

대부분의 시스템 개발에서는 Chart, Grid 같은 컴포넌트를 상용 라이브러리로 해결합니다. 코드로 직접 구현하기 어렵기 때문에 라이선스를 구매하는 것입니다.

그런데 Claude를 활용하면 이야기가 달라집니다. 필터, 정렬, 조회 등 복잡한 Grid 기능을 모두 코드로 직접 구현할 수 있었습니다. 라이선스 비용을 절감하면서도 요구사항에 딱 맞는 커스텀 구현이 가능하다는 점은 실질적으로 큰 메리트였습니다.

향후 계획: 서브에이전트 병렬 처리

이번 검증에서는 로직과 디자인을 순차적으로 직접 확인하며 진행했지만, 실제 프로젝트에서는 다르게 접근할 계획입니다.

subagent-style — 디자인 구현 전담
subagent-logic — 비즈니스 로직 변환 전담

이 두 에이전트를 병렬로 실행하면 작업 속도를 크게 높일 수 있습니다.

시니어 엔지니어로서의 솔직한 평가

3~4일이라는 짧은 기간이었지만, Claude의 활용 가능성은 충분히 확인했습니다. 다만 한 가지 분명히 말씀드리고 싶은 것이 있습니다.

React와 Python을 모르는 분께는 추천하지 않습니다.

Claude가 빠르게 결과물을 만들어주는 것은 맞습니다. 하지만 그 결과물을 제대로 관리하려면 언어의 특성, 폴더 구조, 컴포넌트 설계에 대한 이해가 반드시 필요합니다. 이 배경 지식 없이 프롬프트만으로 개발을 진행하면, 초반에는 빠른 것처럼 보여도 공통 컴포넌트 관리와 코드 스타일 일관성이 무너지는 시점이 반드시 찾아옵니다.

결국 Claude는 도구입니다. 개인의 노하우가 담긴 프롬프트 설계와 아키텍처 지식이 결합될 때, Claude의 진짜 활용 능력이 발휘된다는 것을 이번 작업을 통해 분명하게 느꼈습니다.

개발 환경 - Frontend

구분	기술	버전	용도
언어	JavaScript (JSX)	ES2022+	주 개발 언어
프레임워크	React	18.3	UI 구성
빌드 도구	Vite	5.2	번들링/개발서버
스타일	Tailwind CSS	3.4	유틸리티 기반 스타일링
라우팅	react-router-dom	6.23	페이지 라우팅
HTTP 클라이언트	Axios	1.7	API 통신
폼	react-hook-form	7.51	폼 상태 관리
테이블	@tanstack/react-table	8.17	데이터 그리드
가상스크롤	@tanstack/react-virtual	3.5	대용량 리스트 렌더링
인증 상태	React Context + localStorage	-	전역 로그인 상태 관리

개발 환경 - Backend

구분	기술	버전	용도
언어	Python	3.11+	주 개발 언어
프레임워크	FastAPI	0.111	REST API 서버
ASGI 서버	Uvicorn	0.29	비동기 서버 실행
DB 드라이버	pyodbc (ODBC Driver 17)	5.1	SQL Server 연결
인증	python-jose + HTTPBearer	3.3	JWT 발급/검증
설정 관리	pydantic-settings + python-dotenv	-	환경변수 관리
스키마 검증	Pydantic v2	2.7	요청/응답 유효성 검사
압축	GZipMiddleware	-	응답 압축

26년 2월 24일 - 금리 인하 시그널 포착: FedWatch 기반 고배당·배당성장주 투자 전략

keun90 — Tue, 24 Feb 2026 22:25:45 +0900

CME Group의 FedWatch Tool에서 나온 데이터를 보겠습니다.

단순 설문이 아니라 실제 시장의 데이터가 기반이기 때문에 신뢰도고 높습니다.

해당 데이터틑 월가/매크로 트레이더/채권 시장에서 표준처럼 사용되고 있습니다.

2026년 기준금리 전망

금리 목표 범위 확률표이며, 각 FOMC 회의 시점의 기준금리 범위 확률을 보여줍니다. 해당 회의가 끝났을 때 금리가 어디에 있을지 예상할 수 있습니다. 2026년 3월 회의 후 금리가 3.50~3.75%일 가능성이 96%이며, 하반기에는 금리가 더욱 내려갈 것으로 보입니다.

트럼프는 소비 회복을 위해 감세, 면세, 환급 세 가지를 동시에 밀어붙이고 있습니다. 효과가 나온다면 내수 소비가 살아나고 기업 실적으로 이어집니다. 중금리 환경에서도 배당을 꾸준히 늘려온 소비재 기업들은 이중으로 수혜를 받는 구조가 형성됩니다.

베센트 재무장관은 미국 경제가 올해 최소 3.5% 성장할 수 있다고 얘기했습니다. 워시(Fed 후보)가 현금을 줄여도 소비재 기업이 좋을 것으로 보입니다.

중금리 환경이니 배당 매력이 올라가게 됩니다.

저평가 '고배당 기업' (금융, 경기순환)

티로웨프라이스(TROW), 5.45% (아래 분석으로 좋지만, 현재 금융 분야의 미래가 좋지 못함)

미국의 대형 자산운용사
39년 연속 배당주 상승
1.91% 시점이 가장 고평가 구간이었음
5.45%, 아직 배당이 높다는 것은 저평가 구간인 것을 알 수 있음

티로웨프라이스 배당률

4년째 순이익은 증가하고 있지만, 주가는 횡보하고 있습니다.

티로웨프라이스-순이익/주가

앰코(AMCR), 5.15%

포장재 회사(의약품, 식품용기 등)
코카콜라 등 대형 기업들이 앰코 제품을 사용함
친환경 포장재를 사용함으로써 ESG 변화 중
순이익은 계속 감소하고 있어 좋지 않음

저평가 '배당성장 기업'

노드슨(NDSN)

배당률 1.13% / 배당 성장률 21.1%
리쇼어링, 고마진 산업재, 소비회복

트랙터서플라이(TSCO)

배당률 1.81% / 배당 성장률 25.1%
농촌 소비, 경기방어, 내수 부양
농촌과 교외지역 주민들을 위한 생활용품 전문점
농장용품, 동물사료, 텃밭도구 (미국 농촌의 홈디포)

MSCI

배당률 1.51% / 배당 성장률 19.8%
자본시장 확대, 금융시장 성장

배당 투자는 현재가 아닌 미래를 사는 겁니다. 해당 기업의 현재 배당률은 적지만, 10년 후 크게 상승할 것으로 보입니다.

특히, 트랙터서플라이는 트럼프가 밀어주는 내수 시장과 관련이 깊습니다. 순이익과 주가를 보았을 때 성장 둔화를 보이고 있습니다. 일시적인지 지속적인 것인지 봐야합니다.

트랙터서플라이

ISA-95 스마트팩토리 관점에서 보는 계층 구조(Level, Part)

keun90 — Mon, 23 Feb 2026 20:10:55 +0900

The ISA-95 Model

ISA-95 모델 정의

ISA-95(IEC 62264)는 기업의 비즈니스 시스템(ERP 등)과 생산현장 자동화 시스템(PLC, SCADA, MES 등) 간의 정보 교환을 표준화하기 위해 제정된 국제 표준입니다. 이 표준의 목적은 제조 기업이 상위 관리 시스템과 하위 생산 제어 시스템 간에 데이터를 효율적이고 일관성 있게 교환하여, 운영 효율성과 생산성 및 품질을 향상시키는 것입니다. 즉 "어떤 데이터를 어떤 계층 사이에서 어떤 형식으로 주고 받을지"를 명확히 정의하고, 이를 통해 이기종 시스템 간 통합의 복잡성을 줄여줍니다.

ISA-95 계층 구조

Level 4: 기업 기획 및 물류 관리 (Business Planning & Logistics)
Level 3: 제조 운영 관리 (Manufacturing Operations Management, MOM/MES)
Level 2: 공정 감독 제어 (Supervisory Control)
Level 1: 기본 제어 (Basic Control)
Level 0: 물리적 공정 (Physical Process)

Level 0: 물리적 공정 (Physical Process)

가장 현장에 밀착된 계층으로, 실제 생산 라인에 존재하는 센서, 액추에이터, 펌프, 밸브, 모터, 로봇암 등의 물리적 장치들이 여기에 해당합니다.

반도체 공장에서 웨이퍼를 이송하는 로봇 암
식품 공장의 액체를 담는 밸브
자동차 조립 라인에서 용접하는 로봇
제약 공장에서 캡슐 충전기
포장 공장의 카메라 센서(비전) 등

Level 1: 기본 제어 (Basic Control)

레벨 0의 장치들을 제어하는 계층이다. PLC(Programmable Logic Controller), DCS(Distributed Control System), 임베디드 컨트롤러등이 여기에 해당합니다. 이들은 센서로부터 데이터를 수집하고 액추에이터에 신호를 보내어 기기 동작을 제어합니다.

자동화 조립 공장에서 로봇용접기의 동작을 제어하는 Siemems S7 PLC
화학 공장에서 반응기 온도를 조절하는 Honeywell DCS 컨트롤러
식음료 공장에서 충전 라인의 펌프를 제어하는 Allen-Bradley PLC.

Level 2: 공정 감독 제어 (Supervisory Control) 및 운여

레벨 1에서 제어하고 있는 프로세스를 모니터링하고 운영자가 직관적으로 상황을 파악, 제어할 수 있도록 하는 HMI(Human Machine Interface), SCADA(Supervisory Control And Data Acquisition) 시스템이 해당합니다.

석유 정제 공장에서 전체 공정 흐름도를 보여주는 SCADA 시스템 (예: Wonderware InTouch, GE iFLX)
발전소 터빈 상태를 모니터링하는 DCS 화면
식품 공장에서 모든 충전 스테이션, 포장 스테이션의 데이터 실시간 모니터링

Level 3: 제조 운영 관리 (Manufacturing Operations Management, MOM/MES)

실제 생산 활동(제조 실행)에 필요한 계획, 스케줄링, 품질 관리, 추적성 관리, 생산 실적 관리 등 제조 운영 전반을 담당하는 계층입니다. MES는 생산 오더를 관리하고, 공정 스케줄링을 최적화하며, 생산 이력과 품질 데이터, 성능 지표(OEE) 등을 관리하여 실시간으로 현장 운영 효율성을 개선합니다.

전자제품 공장에서 SAP ME를 이용하여 생산 오더 스케줄링, 공정 흐름 관리, 품질 불량 제품의 원인 추적
자동차 공장에서 Rockwell FactoryTalk ProductionCentre를 활용하여 조립 라인별 실적, 다운타임 분석, OEE 측정
식품 공장에서 Simense Opcenter를 통해 배치별 원료 투입 기록 관리 및 실시간 재고 관리

Level 4: 기업 기획 및 물류 관리 (Business Planning & Logistics)

기업 경영층에서 사용되는 ERP, SCM, CRM 시스템이 해당하는 계층입니다. 기업의 전사적 자원 관리, 판매 및 수주 계획, 생산계획 수립, 재고관리, 회계 및 재무 관리가 이루어집니다.

SAP S/4HANA를 통해 주간, 월간 생산계획 수립, 원재료 구매 발주, 출하 일정 계획
Oracle ERP를 통해 원자재 재고 파악, 고객 주문 접수, 예측 생산량 산출 후 MES로 하달
MS Dynamics 365를 이용한 제조기업의 재무회계, 인사관리, 제품원가 분석 등

ISA-95 주요 Part

Part 1: Level 4와 Level 3의 Interface에 해당하며 전사적인 관점을 지향하며 ERP 및 MES 등 시스템 통합 운영을 위한 용어 정의 및 기본 모형 제시
Part 2: Part 1에서 제시된 ERP와 MES간 표준화된 정보흐름을 표현하기 위해 객체모형과 그 속성을 제시
Part 3: 제조운영활동 구분 및 기본활동모형을 통해 Level 3의 제조운영활동을 저의
Part 4: Part 3에서 제시된 제조운영활동에 관련된 객체모형과 그 속성들을 제시
Part 5: 생산 자동화 시스템과 사주지원활동간 운영에 대한 정의로서 Level 4와 Level 3 간의 Interface에 적용 가능
Part 6: 제조 공정간 운영

ISA-95 문서

자동화 컨설턴트로서 아래 8가지 문서의 목적-구조-일고 검증하는 능력이 반드시 필요합니다.

RACI

- 업무/의사결정에 대해 누가 무엇을 책임지는지 명확히 하는 역할 매트릭스

- Responsible: 실제 작업 수행자

- Acccountable: 최종 책임자(1명 원칙)

- Consulted: 사전 협의 대상

- Informed: 결과 통보 대상

Canonical (Canonical Data Model)

- 여러 시스템 간 인터페이스를 단순화하기 위한 중립 데이터 표준 구조

- ERP → MES → APS → PLM

- 각각 데이터 구조 다름 >>> 데이터 의미 통일

ICD (Interface Control Document)

- 시스템 간 인터페이스의 계약서(정의서)

- 인터페이스 목적 / 송수신 주체 / 데이터 구조 / 트리거 타이밍 / 오류 처리 / 재처리 방식

Data Governance

- 데이터를 누가, 어떻게, 어떤 기준으로 관리할 것인가에 대한 조직적 통제 체계

- Data ownership / quality / standard / lifecycle / security

- 중요한 이유 1. Master data 정합성

- 중요한 이유 2. 설비 데이터 신뢰성

Gap & Roadmap

- 현재 상태 대비 목표 상태의 차이를 분석하고 단계별 실행 계획을 수립

KPI Dictionary & Lineage

- KPI 정의 표준집

- 중요한 이유 1. OEE 계산 방식 공장마다 다름

- 중요한 이유 2. Yield 정의 불일치

- 중요한 이유 3. 생산량 기준 불명확

Change Governance

- 시스템/공정 변경을 통제된 절차로 관리

- 중요한 이유 1. Recipe 변경

- 중요한 이유 2. 공정 라우팅 변경

- 중요한 이유 3. Master data 변경

- 중요한 이유 4. 인터페이스 변경

Global Blueprint

- 글로벌 공장에 공통 적용할 표준 운영/시스템 설계서

- 중요한 이유 1. 공장마다 MES 다름

- 중요한 이유 2. 데이터 비교 불가

- 중요한 이유 3. 운영 방식 불일치

[2026.02 경제지표 정리] Core PCE 3%, PMI 확장 유지… 금리 인하 기대는..

keun90 — Sat, 21 Feb 2026 11:07:11 +0900

트럼프가 10% 상호관세를 발표했습니다.

기존 15%에서 줄어든 내용을 보이고 있습니다.

앞으로 관세에 대해서는 100%, 25% 와 같이 높은 수치를 발표하기는 어려워보입니다.

2026년, 경제 지표는 소폭이지만, 상승을 의미하고 있습니다.

2025년 GDP 성장률은 2.2%입니다.

Source: Bureau of Economic Analysis · Get the data · Created with Datawrapper

2025년 성장률은 셧다운 영향을 제외하면 긍정적인 지표를 보였습니다.

셧다웃이 없었다면, 1.4% → 2.4%가 가능했을 것으로 보고 있습니다.

2026년 , GDP 성장률은 AI투자 + 금리인하로 인해 2.7%로 가속될 것으로 예상하고 있습니다.

PCE 근원 물가 3%로 예상 2.9%와 거의 비슷하게 나왔습니다.

시장은 예상치에 거의 비슷한 수치에 보합 수준에서 안정세를 보였습니다.

PMI 소폭 하락 50 이상

경기 소폭 확장

미시간대 소비자 심리 소폭 개선

가계의 경기 체감과 소비 의향이 약간 좋아졌다는 신호
소비 급락 우려는 완화, 그러나 경기 반등 확정 신호는 아님

https://www.indexergo.com/series/?frq=M&idxDetail=13108

신규주택 소폭 증가

BEA(Bureau of Economic Analysis)

US GDP 공식 발표
개인소득
소비지출(PCE, 연준이 가장 증시하는 물가지표)
PCE(Personal Consumption Expenditures), 미국 가계가 실제로 소비한 금액과 물가 변화를 측정하는 지표(연준이 가장 중요하게 보는 인프레이션 지표)
기업이익 통계
국제수지

PCE 물가 vs PCE 근원 물가

PCE 물가(PCE Price Index) 전체 소비 물가
PCE 근원(Core PCE) 식료품·에너지 제외한 기조 물가, 단기 노이즈 제거 후 진짜 물가 추세 보기 위함

구분	PCE 물가	Core PCE
포함 범위	모든 소비 항목	식료품 ❌ 에너지 ❌
변동성	큼	상대적으로 안정
목적	전체 물가 수준 파악	기조 인플레이션 파악
연준 중요도	중요	⭐ 매우 중요

Core PCE에서 식료품·에너지를 제외하는 이유는 날씨/지정학 영향이 크고, 단기 급등락이 많고 통화정책으로 통제가 어렵기 때문입니다.

PMI (Purchasing Manager's Index, 구매관리자 지수)

경기가 앞으로 좋아질지 나빠질지 가장 먼저 알려주는 선행 경기 온도계
기업 구매관리자 설문 기반 경기 선행지표
제조·서비스 엽황의 체감 변화를 빠르게 반영함
50 이상: 경기 확장
50 미만: 경기 위축

미시간대 소비자심리지수

소비와 인플레이션 기대를 가장 먼저 읽는 가계 체감 선행지표
경제의 70%를 차지하는 소비를 예측하기 위해 분석함(미국 경제 구조: 소비 ~ GDP의 약 70%)
1년 기대 인플레이션
5년 기대 인플레이션
기대 인플레이션 상승 → 금리 상승 압력(연준이 경제에 많이 풀린 돈을 조절하기 위함)
소비심리 급락 → 경기둔화 우려 상승

필드버스 vs 산업용 이더넷 비교 - 스마트팩토리 네트워크 핵심

keun90 — Sat, 14 Feb 2026 07:57:39 +0900

산업용 네트워크 기술 시장 분석(출처: HMS Networks)

필드버스 정의

산업용 네트워크 중 하나인 필드버스란

Field(생산에 필요한 각종 설비들이 운전 되는 현장) + Bus(각 설비 사이의 데이터를 전송하는 통로)

생산에 필요한 각종 설비들이 운전되는 현장에서 각 설비들(센서, 액추에이터, 제어디바이스) 사이의 데이터를 전송하는 디지털 직렬 통신망이라고 정의할 수 있습니다.

필드버스 장점

원각 절감과 유지보수의 편리성, 시스템 구축 시 하나의 제조회사에 의존하지 않고 사용자가 원하는 제품을 선정해 사용할 수 있다는 것입니다. 배선 방식에 비해 필드버스의 경우 리모트 I/O 모듈을 현장 근처에 설치해 단자대 없이 센서 및 기기를 직접 연결하고 통신선 한 가닥만 제어 기기로 배선함으로써 중앙 집중식 대비 약 40~50%의 절감 효과를 얻을 수 있습니다. 또한, 센서나 I/O의 이상 시 해당 노드에서 점검을 빠르게 할 수 있어 장비의 다운 타임을 줄일 수 있습니다.

필드버스 세분화

1. 컨트롤버스

PLC, DCS 또는 제어용 PC HMI(Human Machine Interface) 상호의 정보 교환에 이용되는 네트워크로서 콘트롤러 상위 네트워크라고도 합니다.

2. 필드버스

PLC, DCS 또는 아날로그형의 제어 기기와 필드 기기간의 접속을 디지털화 네트워크화한 것으로 FA계(Factory Automaiton), PA계(Process Automation)로 분류할 수 있습니다.콘트롤러 하위 네트워크 혹은 필드 네트워크라고도 합니다.

3. 센서버스

(Process Automation)로 분류할 수 있습니다.콘트롤러 하위 네트워크 혹은 필드 네트워크라고도 합니다 센서 신호, 액추에이터 신호(검출단·조작단의 온 오프 신호, 접점 신호, 또는 아날로그 입출력 신호)를 고속으로 전송하는 네트워크를 말합니다. 코드화된 제어 명령이나 메시지는 취급할 필요가 없고 디바이스 버스,비트 버스 혹은 센서 레벨 네트워크라고도 합니다.

필드버스 vs 산업용 이더넷

필드버스: 전통적인 저속 현장 제어 통신
산업용 이더넷: Ethernet 기반의 고속 확장성 공장 네트워크

산업	산업용 Ethernet	필드버스
반도체	매우 높음	일부 레거시
LCD	매우 높음	일부
자동차	높음	일부
물류 자동화	매우 높음	거의 없음
화학/정유	중간	아직 많음
제약	중간	존재

산업용 이더넷

데이터를 패킷로 나누어 네트워크를 통해 전달한느 기술입니다.

산업 현장에서는 1Gbps/s 속도로 사용이 가능합니다.

다만, 특정 패킷이 목적이에 도달하는 시간이 정해져 있지 않기 때문에 실시간 제어 기능이 보장되지 않습니다.

그렇기에 PLC 등 컨트롤러 하위는 아직 필드버스를 사용하는 데가 있으나 그 상위로 연결되는 부분은 이더넷을 사용합니다.

(이젠 필드 계열까지 이더넷 사용을 지원하는 End Device도 많이 나온 상황입니다.)

통신 방식은 제조 디바이스에 따라 결정되는 경우가 많습니다.

로크웰 오토메이션의 디바이스를 주로 사용하는 곳에서는 Ethernet/IP를, 지멘스 PLC를 주로 사용하는 현장은 PROFNET을

미쓰비시 제품을 사용하는 경우 CC-LINK IE를 사용합니다. 공장들 대부분이 혼용해서 사용하는 경우가 많고 통합 과정이 매우 까다로웠습니다. 이 상황에 대한 대응 방법으로 OPC-UA 기술이 많이 쓰이고 있습니다.

https://keun90.tistory.com/22

OPC-UA 실습 1 - 서버, 클라이언트 연동

OPC-UA 실습을 위한 Server, Client를 다운받는다. (계정이 막혔는지,, 로그인 실패 알림이 계속해서 발생한다.) 계정 메일 주소는 gmail을 활용하는 것을 추천한다. ttps://documentation.unified-automation.com/uaexp

keun90.tistory.com

LIMS System Owner의 역할

keun90 — Fri, 13 Feb 2026 19:20:38 +0900

LIMS는 단순 시험 시스템이 아니라, 규제 환경에서 데이터 무결성을 통제하는 핵심 플랫폼입니다. (LIMS: Laboratory Information Management System, 실험실 정보 관리 시스템)

검체 등록
시험 분석
결과 보고
데이터 저장 및 기기 연동

직무의 본질

GMP 환경에서 LIMS의 기술적 안정성과 데이터 무결성을 책임지는 System Owner

System Owner는 모든 레이어를 관통하는 역할을 합니다.

GMP는 위에 있는 게 아니라 전체를 감싸는 통제 계층입니다.

(GMP: Good Manufacturing Practice, 제조 및 품질관리 전 과정에서 데이터의 무결성, 추적 가능성, 일관성을 보장하기 위한 기준)

[ Business Layer ]
시험실 프로세스 / QC 업무 / 배치 Release 판단
                ↓
────────────────────────────────
[ Application Layer ]
                LIMS Core
  - 시험 관리
  - 결과 저장
  - 승인 프로세스
  - 재시험 관리
────────────────────────────────
                ↓
[ Integration Layer ]
  장비 인터페이스 ↔ MES ↔ ERP ↔ 기타 시스템
────────────────────────────────
                ↓
[ Data Layer ]
  DB (시험 결과, 원본 데이터, Audit Log)
────────────────────────────────
                ↑
[ GMP Control Layer ]
  - Data Integrity 통제
  - Change Control
  - Validation
  - Audit 대응

데이터 흐름 중심 구조

모든 단계와 변경점에 대해 기록하고 제어하는 역할이 매우 종요합니다.

[ 분석 장비 ]
     ↓ (Raw Data)
[ Interface Module ]
     ↓ (Validation & Parsing)
[ LIMS Core ]
     ↓
[ DB 저장 ]
     ↓
[ 승인/Release 프로세스 ]
     ↓
[ ERP / MES 연계 ]

모든 단계 → Audit Log 기록
모든 변경 → Change Control 대상

System Owner 의 역할

Owner는 코딩 담당자가 아니라 QA와 IT 사이의 기술적 책임자역할을 수행합니다.

변경 통제 및 Validation 책임

시스템 변경 요청 검토
변경 영향도 분석
인터페이스 로직 수정 검토
테스트 범위 정의
Validation(OQ/PC) 참여
Change Control 승인 프로세스 참여
변경 이력 관리

데이터 무결성 및 인터페이스 관리

장비 ↔ LIMS 데이터 수집 구조 검토
인터페이스 오류 모니터링
데이터 누락/중복 방지 설계
Audit Trail 점검
DB 정합성 확인
장애 발생 시 Root Cause 분석

Audit 대응 및 대내외 기술 창구

Audit 시 시스템 설명
접근 권한 구조 설명
변경 이력 제출
인터페이스 구조 설명
벤터 기술 검토
글로벌 기준 정렬

Risk-Based Approach(위험 기반 통제)

System Owner는 모든 변경을 동일하게 보는 것이 아니라, 품질에 미치는 영향 수준에 따라 통제 강도를 조절해야 합니다.

모든 기능이 동일한 Critial Level은 아님
시험 결과 계산 로직은 High Risk
UI 문구 변경은 Low Risk
인터페이스 자동 승인 로직은 High Risk

Part 11 / 전자기록 · 전자서명 개념

LIMS는 대부분 전자 기록 시스템입니다.

Electronic Record
Electronic Signature
접근 권한 분리
계정 공유 금지
비밀번호 정책

Master Data 통제

운영 데이터 외에 Master Data 통제가 더 중요합니다.

시험 항복 정의
허용 기준값(Spec)
계산 공식
시험 방법 버전

Deviation CAPA 개념

실제 GMP 환경에서는 장애를 "버그"라고 하지 않고 "Deviation(일탈)" 이라고 부릅니다.

System Owner는 장애를 기술적으로 해결하는 것뿐 아니라 Deviation 기록 근거를 제공하는 역할을 합니다.

원인 분석
재발 방지 조치(CAPA)
문서 기록

Backup / Disaster Recovery (DR)

DB 백업 정책
복구 테스트
데이터 손실 허용 범위
이중화 구성

Lifecycle 관점

기획
요구사항 정의
설계
Validation
운영
변경
폐기(Decommissioning)

폐기란, 시스템 사용 종료 / 데이터 보존 전략 수립 / 규제 요건 충족 상태 유지 / 감사 대응 가능 상태 유지 를 의미합니다.

즉, 기능은 종료 하지만, 책임은 종료되지 않습니다.

폐기 단계에서는 데이터 보존 전략 / 전급 통제 유지 / Validation 종료 문서화 / 인터페이스 정리 를 해주어야 합니다. 데이터의 삭제가 아닌 언제든 접근 가능한 상태를 유지해야 합니다.

KPI 기반 운영

인터페이스 실패율
승인 지연 시간
재시험 발생 빈도
Audit Finding 건수

Traceability Matrix 의 본질

GMP 프로젝트에서는 요규사항 정의 → 설계 명세 → 테스트 케이스 → 실행 결과 → 변경 이력 .. 이 모든 것을 연결해서 증명해야 합니다.

"이 요구사항이 어디에 구현되었고, 어떻게 검증되었는가?"를 한눈에 보여주는 지도입니다.

Audit 시 가장 많이 받는 질문에 대응하기 위해 Traceability Matrix가 반드시 필요합니다.

이 기능이 어떻게 검증되었는가?
이 요구사항이 누락되지 않았는가?
테스트되지 않은 기능이 있는가?
변경 후 재검증 되었는가?

LIMS에서 아래와 같은 형식으로 관리하게 됩니다.

URS	Risk	FS	Config	OQ	PQ	Status
URS-001	High	FS-03	Role Rule	TC-05	PQ-02	Validated

URS - 사용자 요구사항 고유 번호
FS Ref - 설계 문서의 어느 항목에 반영되었는지
Config - 설정값 or 계산 로직 or 인터페이스 모듈
QQ Test - 운영 검증 테스트 케이스 번호
PQ Test - 실제 업무 시나리오 기반 검증

Traceability의 핵심 3가지는 아래와 같습니다.

Completeness - 모든 URF가 FS에 반영되었는가?
Coverage - 모든 High Rish 항목이 QQ 테스트되었는가?
Revalidation - 변경 시 영향 받는 URS는 재검증 되었는가?

Bidirectional Traceability

Forward Traceability: URS(요구사항) → FS/DS(설계) → Config/Code → IQ/OQ/PQ(시험) → Evidence(증빙)
Backward Traceability: Evidence(증빙) → 테스트케이스 → 설정 → 코드 → 어떤 URS를 만족 / URS 없는 기능이 있는가?

규제 관점에서 실패 패턴은 두 가지가 있습니다.

역방향 추적성은 이 두 가지를 구조적으로 방지할 수 있습니다.

URS는 있는데 테스트가 없는 경우 → 검증되지 않은 요구사항(Audit에서 바로 걸림)
테스트/기능은 있는데 URS가 는 경우 → 승인되지 않은 기능(Shadow Function, 통제 위반)

GMP / 규제 관련 용어

약어/용어	Full Name	의미	System Owner 관점 핵심
GMP	Good Manufacturing Practice	제조 및 품질관리 기준	시스템 설계 원칙
ALCOA	Attributable, Legible, Contemporaneous, Original, Accurate	데이터 무결성 원칙	Audit Trail 필수 근거
CSV	Computer System Validation	컴퓨터 시스템 검증	문서 기반 검증 체계
URS	User Requirement Specification	사용자 요구사항 문서	모든 검증의 출발점
FS	Functional Specification	기능 명세	URS를 기술적으로 풀어쓴 문서
DS	Design Specification	설계 명세	실제 구현 구조 정의
IQ	Installation Qualification	설치 검증	시스템이 올바르게 설치되었는지
OQ	Operational Qualification	운영 검증	기능이 요구대로 동작하는지
PQ	Performance Qualification	성능/실사용 검증	실제 업무 환경에서 검증
RTM	Requirements Traceability Matrix	요구사항 추적 매트릭스	URS↔검증 연결 지도
OOS	Out Of Specification	허용 기준 초과	품질 리스크 발생 이벤트
Deviation	일탈	규정 위반/예외 발생	원인 분석 필요
CAPA	Corrective and Preventive Action	시정 및 예방 조치	재발 방지 체계
Change Control	변경 통제	시스템 변경 승인 절차	배포 통제 핵심
Risk-Based Approach	위험 기반 접근	위험도에 따른 통제	검증 범위 결정 기준
Part 11	21 CFR Part 11 (FDA)	전자기록/전자서명 규정	전자 승인/로그 설계 기준

LIMS / 시스템 관련 용어

약어/용어	의미	설명	Owner가 보는 포인트
LIMS	Laboratory Information Management System	시험 데이터 관리 시스템	데이터 허브
QC	Quality Control	품질 관리 부서	사용자
QA	Quality Assurance	품질 보증 부서	규제 통제 주체
Master Data	기준 데이터	시험항목, Spec, 계산식 등	변경 시 High Risk
Spec	Specification	허용 기준값	합/부 판정 기준
RBAC	Role-Based Access Control	역할 기반 접근 제어	권한 통제 핵심
Audit Trail	변경 이력 로그	누가 언제 무엇을 변경했는지	Data Integrity 핵심
Electronic Signature	전자서명	승인 인증 절차	Part 11 대상
Interface	시스템 간 연동	장비↔LIMS↔MES↔ERP	데이터 정합성
Raw Data	원본 데이터	장비에서 생성된 최초 데이터	삭제 금지
Archive	데이터 보관	시스템 폐기 시 보존	Read-Only 유지
Revalidation	재검증	변경 후 재검증	Change Control 연결

26년 2월 - 비트코인, 크립토 윈터, 하락 원인·청산 구조·반등 가능성 총정리

keun90 — Fri, 13 Feb 2026 00:29:14 +0900

개당 12만 달러를 넘어갔던 비트코인은

26.02.11 기준, 심리적 저항선으로 여겨졌던 7만 달러 밑으로 떨어졌습니다.

비트코인은 왜 금과 다르게 하락세을 보일까?

26년, 크립토 윈터(바닥을 탐색하는 시기)가 좀 더 길어질 수 있다는 분석들이 많이 나왔고

22년 11월 이후로 가장 큰 하락 폭을 보이고 있습니다.

하락의 원인은 무엇일까?

새로운 연준 의장, 케빈 워시

→ "금리는 낮춰줄 사람일지 몰라도, 시중에 뿌리고 있는 돈을 줄일 것(긴축 공포)"

모든 자산이 급락했고 이에 따라 비트코인도 함께 폭락했습니다.

다만, 반등한 다른 자산과 달리 비트코인은 반등을 보이지 못하고 있습니다.

왜 비트 코인은 반등하지 못했을까?

등락이 심한 시장에서는 고위험 레버리지의 투자가 매우 위험합니다.

→ 1코인으로 10~20코인을 굴리는, 레버리지 투자가 활발한 시장입니다.

(주식의 3배의 레버리지 투자 보다 폭이 큽니다.)

코인에는 강제 청산 이 있어, 하락 장에서는 24시간 쉬지않고 연쇄 청산이 발생할 수 있습니다.

(강제 청산: 내 담보금이 일정 기준 아래로 줄어들면, 거래소가 자동으로 팔아버림)

26년 2월, 단 하루만에 조 단위 청산이 발생하면서 가파른 하락세를 보이고 있습니다.

상승장이 올까?

24년 1월 이후 비트코인이 제도권(ETF) 편입 되면서 좋은 흐름을 보였습니다.

기관 투자자 보유 물량이 전체 코인 시장의 10%를 넘었습니다.

ETF 투자자들의 평단가는 8만8천달러로, 대부분 현재 기준 손실 구간에 빠진 것으로 보입니다.

이럴 때 기관들은 일반적으로 포트폴리오 재구성을 위해 손절 후 자산을 운영합니다.

기관 손절 → 개미 저점 매수 → 개미 청산 반복해온 것이 확인되었습니다.

스트레티지(비트코인 매수 기업)의 평단가는 7만5천달러입니다.

마라홀딩스(채굴기업)가 1비트코인을 채굴하는 비용이, 25년 3분기 기준, 6만7천달러입니다.

비트코인 가격이 채굴비용 보다 하락하게 된다면, 기관도 버티기 힘든 가격대가 됩니다.

가격 추이

2,3차를 보면 고점 대비 70%까지 하락을 보였습니다.

이 관점에서 보면, 4차 반감기의 하락의 끝이 더 남아 있는 것으로 보입니다. (현재 고점 대비 -50%)

출처: 블룸버그 키움증권

미국, 비트코인 X 크립토 O

달러와 1:1 가치를 연동한 크립토(디지털 달러), 스테이블 코인의 지니어스 법은 생겼지만,

비트코인에 대한 정책은 아직 나오지 않고 있습니다.

미국 재무 장관도 비트코인에 대해 선을 긋고 있습니다.

결론

비트코인이 우상향 한다는 의견이 있지만, 아직 위험자산으로 보입니다.

테더(세계 최대 달러 스테이블 코인 업체)는 자신들의 코인에 1대 1로 연동시켜야 할 현금과 국채 같은 달러 자산 외에도

비트코인과 실물 금괴를 사 모으고 있습니다. 비트코인의 비중은 10%이지만, 금의 비중은 10~15%까지 늘리겠다는 계획입니다.

협동로봇 입문 교육 후기 – 두산로보틱스 초급 과정 솔직 정리

keun90 — Mon, 9 Feb 2026 21:57:14 +0900

올해 가장 주목받는 분야 중 하나는 로봇입니다. 아직은 이르다는 의견도 있지만, 로봇의 중요성이 점점 커지고 있다는 점은 분명해 보입니다. 관련 지식을 빠르게 쌓고 직접 경험해보고 싶어, 국내 로봇 산업을 이끄는 두산로보틱스의 교육 과정에 참여하게 되었니다. 비록 하루짜리 초급 과정이었지만, 고가의 로봇을 하루 종일 직접 다뤄볼 수 있었던 의미 있는 시간이었습니다. 아래에 교육에서 배운 내용을 간단히 정리해보았습니다.

(가장 아래, 최종 실습 영상이 있습니다.)

교육 목표 요약

협동로봇과 산업용 로봇의 차이 이해
두산 협동로봇 구성과 인터페이스 이해 및 기본 설치·운용
티치 펜던트 UI 사용 숙련
수동 조작과 직접 교시 방식 이해
기본 좌표계 기반 Pick & Place 프로그램 구현

1. 교육 개요 (10:00~)

친절한 사내 강사님이 진행을 해주셨습니다. (수강생의 폭 넓은(?) 질문에 성실히 답변해주시는 모습이 매우 인상적이었습니다. )
초급자에게 적절한 수업 구성이었습니다.
PDF 강의 잘료에 모든 수업 내용이 담겨있었습니다.
산업용 로봇
- 사람과 함께 작업하려면 센서·안전 규제 다수 필요
- 법적 제약이 큼
협동로봇
- 사람과 함께 작업하기 쉬움
- 자동화 공정에서 활용 빈도 높음
- 동일 하중 기준 산업용 로봇보다 가벼움
- 안전 인증 충족 (PL e, Cat 4 / 해외 기준 포함)

협동로봇(M0606), 터치패드, 컨트롤러

2. 장비 연결 및 초기 세팅 (10:20~)

DART-Platform 설치
노트북(Windows)과 로봇 직접 연결(LAN)

3. 그리퍼 및 컨트롤러 이해 (10:35~)

기본 그리퍼 테스트: 신호 0(놓기) / 1(잡기) 단순 제어
타사 그리퍼·복잡 동작 시:
- 로봇 팔 직결이 아닌 컨트롤러 직접 배선으로 커스터마이징
컨트롤러 구성
- 전원/통신 케이블
- USB(로그, 업데이트)
그리퍼 규격은 표준화
- 그리퍼 통신 스펙 ↔ 협동로봇 스펙 비교 필수

4. 작업 공간과 특이점 (10:55~)

가용 작업 스페이스
- 말단 축을 굽힌 범위 기준
특이점 영역
- 도넛 형태
- 그리퍼가 몸체에 붙으면 작업 불가
- 중심점에 위치 시 회전 방향 판단 혼선 발생

5. DART-Platform 조작

언어, 날짜 설정(로그 분석 목적)
로봇 전원 ON
- “딱” 소리 6회 → 6축 브레이크 해제
터치패드로 수동 조작 실습
24시간 가동 기준 수명: 약 2~3년
- 유지보수·부품 관리는 본사에서 일괄 관리
최종적으로 DART 플랫폼에서 Task를 만들어 동작을 직접 만들어보고 로봇을 움직여보는 실습을 해보았습니다. 화면은 처음 보는 사람도 쉽게 구성되어 있습니다. (같은 작업을 로봇마다 하나씩 작업해야 한다는 사실이 불편해보였지만, AI를 활용해 쉽게 조작하는 방법을 연구하고 있다고 합니다.)

최종 Task 화면(MoveJ, MoveL이 액션 컴포넌트 입니다.)

점심은 쿠폰을 받아 사내식당을 이용했습니다. 메뉴는 4가지 정도였고, 식사 외에 샐러드를 선택할 수도 있었습니다. 식사 시간에는 두산 직원들이 자부심을 느낄 만한 쾌적한 식당과 함께, 전망이 좋은 사내 시설도 둘러볼 수 있었습니다.

24층 - 강당, 휴게 공간, 점심

6. 좌표계와 제어 개념

조인트 좌표계: 각 축의 자세
태스크 좌표계: TCP 기준
- 그리퍼 **끝 위치(TCP)**가 핵심
X, Y, Z, A, B, C 개념은 진입 난이도 있음
X, Y, Z, RX, RY, RZ 계산 기반 제어는 쉽지 않음

7. I/O 및 통신

전류 요구 증가 시 컨트롤러 전원 분리 가능
포트 확장 가능
디지털 I/O
- 컨트롤러 16개, TCP 6개

I/O On/Off를 직관적으로 확인 및 동작해 볼 수 있는 화면입니다.

아날로그 I/O
- 컨베이어 등 외부 장비 연동
통신 프로토콜
- Ethernet, Fieldbus 지원

8. 기본 설정 포인트

그리퍼 무게 설정 필수
- 미설정 시 중력 영향으로 처짐
- 무게 측정용 최적 자세 필요
인터페이스 메시지 전송 속도: 100ms

9. 그리퍼 동작 방식

단동식
- 신호 1개
- 정전 시 물건을 놓음
복동식
- 신호 2개
절대 이동 / 상대 이동 개념 구분

10. 도입 시 고려사항

로봇 사용 목적을 먼저 정의
로봇 엔지니어 + 그리퍼 엔지니어 간
- 인터페이스 사전 검증 필수
이상 발생 시 로그 전달로 정밀 분석 가능

11. 교육 참석자와 적합 대상

참석자: 로봇 사업 준비, 로봇 관심있는 처음 접하는 엔지니어, 자동화 엔지니어, 교육 사업가
적합 대상
- 협동로봇 개념 이해가 필요한 현업
- 자동화 도입 초기 단계 담당자
비적합
- 로봇 제어·인터페이스를 깊게 다루려는 엔지니어(초급 교육에서는 단순한 조작 장법에 대해 실습함)

12. 정리

이동 + 그리퍼 작동까지 직접 실습
개념 위주 초급 과정
실무 적용을 위해서는 추가 기술 교육 필요

최종 실습: Pick - 이동 - Place

교육 접수

https://robotlab.doosanrobotics.com/ko/Training/EducationList

교육 신청 : Doosan Robotics Training & Service

교육신청 필터  + 더보기

robotlab.doosanrobotics.com

제조 공정 분석 1 - LCD, MES

keun90 — Tue, 3 Feb 2026 20:11:56 +0900

TFT-LCD 패널 제조는 Array 공정, Cell 공정, Module 공정의 세 단계로 이루어지며, 각 단계마다 제조 기술과 장비, 그리고 MES 포인트가 달라지기 때문에 공정에 대한 설명과 MES 역할을 정리했습니다.

공정별 리드 타임과 MES 중점 관리 포인트는 아래와 같습니다. MES는 EAP와 직접 통신하고 미들웨어로는 TIB/RV를 사용하여 로드벨런싱을 해본 경험이 있습니다. MES 엔지니어가 아닌 설비 엔지니어가 SECS/GEM을 직접 관리해 장비 인터페이스를 구성합니다.

공정 단계	예상 소요 시간	주요 작업 내용	MES 중점 관리
Array 공정 (TFT Array)	약 5~7일	박막 증착, 포토 마스크 노광, 식각, 박리 등 일련의 미세공정 5~7회 반복	로트 이력 추적, 공정 레시피 관리, 설비 인터페이스 EAP(예: SECS/GEM) 통한 데이터 수집 및 장비 제어, WIP 재공관리 및 스케줄/디스패칭 최적화
Cell 공정 (패널 접합)	약 3~5일	TFT 기판과 컬러필터 기판 정합, 배향막 도포 및 러빙(rubbing), 액정 주입, 봉지(sealing), 폴라라이저 부착 등	로트(유리 기판 세트) 추적, 외주 자재(CF판 등) 투입 관리, 주요 공정 실적/품질 데이터 수집 (예: 정합 정밀도), 공정 병목 관리 및 실시간 WIP 모니터링
Module 공정 (모듈 조립)	약 1일	Cell 공정 완료 패널에 구동 IC 장착(COG/COF 본딩), FPC 연결, 백라이트 조립, 최종 검사 및 Aging 테스트, 제품 포장	제품 개별 패널 단위 식별 및 추적, 부자재 투입(구동칩, 백라이트 등) 관리, 최종 검사 결과 수집/분석, 불량 판정 시 재작업/폐기 처리, 출하 관리 및 이력 기록

공정별 간략한 설명

구분	공정명	핵심 목적	주요 작업
전공정	Array	픽셀 구동 회로 형성	증착, 노광, 현상, 에칭, 박리
전공정	Color Filter	RGB 색 표현	컬러 패턴 형성, 보호막
중공정	Cell	액정 셀 완성	정합, 실런트, 액정 주입
후공정	Module	제품화	BLU, IC 접합, 검사

Array 공정(TFT 어레이) 을 정리한 표 입니다.

동일 노광 장비 반복 사용 → 스케줄링 난이도 높음
수율·결함 관리가 전체 원가에 직접 영향

항목	내용
공정 성격	반도체 유사 미세 공정
반복 구조	재진입 공정 (Re-entrant Flow)
포토 공정	5~7 Mask 반복
공정 순서	세정 → 코팅 → 노광 → 현상 → 에칭 → 박리
산출물	TFT 소자 어레이 기판

Color Filter 공정을 정리한 표 입니다.

Array와 정합 정밀도가 핵심
외주 시 MES 연계 범위 축소 가능

항목	내용
목적	RGB 색 구현
기술	포토리소그래피 기반 색소 패터닝
특징	TFT 기판과 픽셀 배열 1:1 대응
공급 방식	내재화 or 외주

Cell 공정을 정리한 표 입니다.

얼라인 오차 = 불량
Lot 단위 → Panel 단위로 추적 단위 변화

항목	내용
핵심 작업	기판 정합 + 액정 주입
액정 주입	ODF(One-Drop Fill)
주요 공정	얼라인 → 실런트 → 합착 → UV 경화
이후 공정	대형 유리 → 개별 패널 절단

Module 공정을 정리한 표 입니다.

직선형 조립 공정
검사 데이터가 출하 품질 기준

항목	내용
조립 요소	BLU, Driver IC, PCB
IC 접합	ACF (Chip On Glass)
추가 공정	편광판, 터치, 코팅
검사	밝기, 색 균일도, 결점

MES 관점으로 공정 특성을 정리한 표 입니다.

구분	Array	Cell	Module
공정 유형	재진입	조립	조립
흐름	복잡	중간	단순
추적 단위	Glass / Lot	Glass → Panel	Panel / Serial
MES 포인트	스케줄링, WIP	정합 이력	검사·출하

공정별 상세 설명

Array 공정

유리 기판 위에 박막 트랜지스터(TFT) 어레이를 만드는 단계입니다. 여러 차례의 박막 증착, 포토리소그래피(노광 및 현상), 에칭 공정을 반복하여 픽셀 구동을 위한 미세한 회로 패턴을 형성합니다. 보통 5~7개의 포토마스크를 사용하여 여러층의 배선과 트랜지스터를 제작하며, 각각의 공정마다 세정 →코팅 →노광 →현상 →에칭 →박리 순으로 진행됩니다. 최종 산출물은 화소 구동용 TFT 소자가 박혀 있는 TFT 어레이 기판입니다.

컬러 필터 공정

컬러 필터 기판은 RGB컬러 화소를 생성하기 위한 색소층을 가진 유리 기판입니다. 컬러 필터 제조도 포토리소그래피를 활용하여 적·녹·청 색의 미세 패턴을 여러 층으로 형성합니다. 완성된 컬러 필터 기판은 Array 공정의 TFT 기판과 동일한 크기와 픽셀 배열을 가지며, 두 기판을 합착하기 위해 준비됩니다.(일부 디스플레이 업체는 컬러 필터 공ㄹ정을 자체 생산하지 않고 외부에서 공급받기도 합니다.)

Cell 공정

Cell 단계에서는 앞 단계에서 준비된 TFT 기판과 컬러 필터 기판을 합치는 작업이 이루어집니다. 두 기판은 정밀하게 얼라인(정렬)되고, 가장자리에는 액정이 새지 않도록 접착제(실런트)를 인쇄합니다. 접착제를 도포한 후 두 유리판을 밀착하여 봉합하고, 판들 사이의 빈 공간(셀 갭)에 액정(Liquid Crystal) 물질을 주입합니다. 주입은 진공 하에서 액정을 채우는 ODF(One Drop Fill) 공법 등이 사용되며, 액정 주입 후 자외선 경화 등을 통해 접착제를 완전히 굳힙니다. 이렇게 액정 셀(Cell)이 형성된 대형 유리 기판(Mother Glass)은 이후 규격에 맞게 잘라져 개별 패널 단위로 분리됩니다.

Module 공정

개별 LCD 패널에 백라이트 등 부품을 조립하여 최종 제품 모듈을 완성합니다. 먼저 패널 뒷면에 백라이트 유닛(LED, 광원, 도광판, 확산판 등으로 구성)을 부착하여 LCD에 광원을 제공합니다. 이어서 구동 드라이버 IC칩을 PCB 기판 똔느 유리 기판 가장자리와 접합합니다. 필요에 따라 터치 패널이나 편광판 부착, 표면 코팅(반사, 방지, 내구 코팅)등의 처리가 이루어집니다.

MES 관점에서 LOT관리가 매우 중요합니다.

항목	설명
LOT 정의	MES가 관리하는 생산 단위
LCD 예시	여러 장의 대형 유리 기판 묶음
이동 방식	공정 간 하나의 객체처럼 이동
MES 초점	장비가 아니라 LOT 흐름

LOT이 공정/설비에 투입되면 Track-In/Out 이라고 합니다. LOT이 어떤 공정을 진행해야 할지 미리 설계되어 있는 Process Flow를 따라 움직입니다. Process Flow는 설계도를 데이터로 변경하여 관리하게 됩니다.

공정 순서는 Workfow/Prcessflow로 통제
모든 이벤트는 Lot 이력으로 남음

단계	MES 역할
Track-In	공정·장비 적합성 검증
가공 중	레시피, 장비 상태, 시간 기록
Track-Out	공정 결과 데이터 저장
다음 공정	Workflow 기준 자동 이동

품질에 따라 공정을 제어하고 생산 객체를 처리해야 합니다.

검사 결과 + 누적 공정 데이터 기반 판단
재작업도 정식 공정 루트로 관리

상황	MES 판단
정상	다음 공정 진행
경미 불량	Rework 공정 유도
중대 불량	Scrap 처리

대량 자동 생산에서의 핵심은 Queue, Dispatch, Scheduling 입니다.

Hot Lot 처리, 높은 우선순위 부여
MES 디스패치 = LOT을 카세트에 담에 목적지를 설정해 반송을 명령하는 역할을 합니다.

구분	의미
Queue	설비 앞 대기 Lot
Scheduling	중장기 공정 계획
Dispatching	실시간 설비 배정

Dispatch는 MCS와 인터페이스를 이루어 반송(수동/자동)을 역할을 수행합니다.

역할	시스템
공정 판단	MES
이동 실행	MCS
이송 수단	AGV / OHT / Conveyor

"MES는 장비를 관리하는 시스템이 아니라, LOT이 공장을 통과해 완성품이 되기까지의 흐름과 판단을 책임지는 시스템입니다."

추가 내용

MES는 각 공정 장비들과 데이터를 주고받아야 합니다. 이를 위해 반도체/디스플레이 업계에서는 SECS/GEM과 같은 표준 프로토콜이 널리 사용되며, 장비의 동작 상태, 공정 진행, 측정 값 등을 MES에서 실시간 모니터링하고 제어할 수 있습니다. MES는 설비 제어용 인터페이스 모듈(EAP)을 통해 공정 Recipe 전송, LOT 시작/종료 지시, 장비 Alarm 수신, 계측 데이터 수집 등의 작업을 수행합니다.

노광기: MES 지시로 특정 LOT에 맞는 Receipe/Mask를 로딩하고 노광을 시작하며, 완료 후 MES에 종료 신호와 처리 결과 데이터를 보내도록 통신합니다. (*설비의 모델별 인터페이스 가능한 Value가 한정되어 있습니다. 반드시 설비 담당자와 스펙을 확인하는 검증 작업을 수행해야 합니다.)

MES는 공정 데이터베이스를 중심으로 방대한 생산 데이터를 관리합니다. 각 LOT의 공정 이력(어느 시간에 어떤 설비에서 처리되었는지), 투입 자재 로트, 검사 결과, 설비 로그 등이 모두 MES에 누적됩니다. MES 엔지니어는 이러한 데이터를 활용해 통계적 공정관리(SPC) 차트를 작성하거나, 이상 발생 시 근본 원인을 추적하여 공정 개선에 반영합니다. 예컨대 특정 공정 단계에서 반복적으로 불랴이 발생하면 MES 데이터 분석을 통해 문제가 되는 설비나 공정조건을 찾아낼 수 있습니다.

26년 02월 02일 - 증시 폭락, 케빈 워시, 금리 인상 예상

keun90 — Mon, 2 Feb 2026 23:19:47 +0900

26년 2월 2일 오후 3시,

미국의 새로운 연준의장 케빈 워시의 당선이 확정된 이후로 증시는 대폭락을 보였습니다.

한국만 유독 더 빠진 이유에 대해 정리해보겠습니다.

국가	지사	지수값	등락률
한국	코스피	4,949.67	-5.26%
일본	Nikkei 225	약 52,655	약 -1.25%
중국 본토	SSE Composite	약 4,015	약 -2.48%
중국 선전	SZSE Component	(추정)*	(하락)
홍콩	Hang Seng Index	약 26,775	약 -2.23%
대만	TAIEX	약 -1.3~ -1.4%	-
싱가포르	Straits Times Index	약 4,892	약 -0.26%
말레이시아	FTSE Bursa Malaysia KLCI	약 1,740	+0.58%
태국	SET Index	약 -0.32%	-
인도	Nifty 50	+1.06%	-
인도	SENSEX	+1.17%	-

2026.01.29 기준 SLV(iShares Silver Trust, 은 변동 ETF)의 거래대금은 Apple과 Amazone을 합한 것보다 컸습니다.

투자자들은 지정학적 혼란, 통화 가치 하락, 연방준비제도의 독립성에 대한 새로운 우려 속에서 금과 은에 몰려들었습니다.

중국 투기꾼들의 매수 물결이 랠리에 거품을 더했다.

https://finance.yahoo.com/news/gold-sinks-to-4900-silver-crashes-25-as-precious-metals-trade-unwinds-211140665.html

Gold sinks to $4,900, silver crashes 25% as precious metals trade unwinds

Gold and silver futures crashed on Friday in a sharp reversal of a massive rally in precious metals.

finance.yahoo.com

금요일의 극적인 매도세를 촉발한 것은 도널드 트램프 미 대통령이 케빈 워시를 연준의장으로 지명할 것이라는 소식으로, 이는 달러를 강세로 밀어 올리고 통화 약세를 허용할 것이라는 트럼프의 의지에 베팅했던 투자자들의 심리를 약화시켰습니다. 트레이더들은 워시를 최종 후보들 중 가장 강력한 인플레이션 대응론자로 보고 있어 달러를 지지하고 달러 표시 금값을 약화시킬 더 엄격한 통화정책 기대를 높였습니다.

결국, 엄청난 과열 현상 이후 대폭락했습니다.

금 하락 쉽게 설명

금/은 시장의 폭락을 예시로 들어 쉽게 설명해보겠습니다.

기존 집 값 10억 → LTV 7억 + 현금 3억

기존 집 값의 하락 + 정부에서 LTV도 낮추는 상황이 발생했습니다.

기존 집 값 8억 하락
LTV 최대 4억 감소

기존 LTV 7억 → 4억으로 3억을 당장 채워 넣으라는 통지가 받게 됩니다.

이게 바로 마진콜입니다.

현재 자산을 지키기 위해 현금 마련이 급했고 유동성있는 자산 중 많이 상승한 자산을 매각하게 됩니다.

주말 이후 가장 먼저 시작한 한국 주식을 청산하면서 하락세를 보였습니다.

한국 원화 약세가 예상(미국 달러 강세),
한국 주식 최근 상승

시계열 데이터 - 특징, ISA-95, 도입 사례

keun90 — Mon, 2 Feb 2026 20:05:05 +0900

제조 산업에서는 설비 센서나 IoT 장치로부터 끊임없이 온도·압력·진동 등의 데이터가 시간 순으로 수집됩니다. 이러한 데이터를 시계열(Time-Series) 데이터라고 하며, 시계열 DB는 기본적으로 시간(Time)을 기준으로 값이 저장되도록 설계되었습니다.

일반적인 관계형 DBMS(MSSQL, Oracle 등)와 차이점은 다음과 같습니다.

항목	관계형 DB (MSSQL, Oracle 등)	시계열 DB (InfluxDB, TimescaleDB 등)
저장 구조	정규화 테이블, 고정 스키마	타임스탬프 + 값 + 태그 구조, 유연한 확장성
인덱싱 / 파티셔닝	범용 인덱스(B+Tree)	시간 기준 파티셔닝, 시계열 전용 구조 (TSM 등)
쓰기/읽기 패턴	읽기 중심, 트랜잭션/조인 빈번	쓰기 중심, 연속 INSERT 최적화
보존 정책	수동 삭제 필요, 스크립트로 관리	Retention 정책으로 자동 삭제 및 요약
성능 최적화	대량 시계열 데이터에 비효율적	압축 저장 + 시계열 집계에 최적화

시계열 DBMS(Time-Series DBMS)는 위와 같은 구조적 차이를 바탕으로 대용량 시계열 데이터의 실시간 수집·조회에 최적화된 기능을 제공합니다.

대표 제품: InfluxDB, TimescaleDB

[시계열 DBMS 특징 및 장점]

구분	시계열 DBMS의 특징 및 장점
고속 수집/조회	초당 수백만 건 데이터 처리 가능, 삽입 성능 안정적 (정적 조인·제약 없음)
저장 효율성	시계열 전용 압축 저장, Retention 정책으로 자동 삭제 및 저장 공간 절감
분석 기능 특화	이동평균, 연속 집계, 다운샘플링 등 시계열 연산 지원, Flux/확장 SQL로 추세·이상 분석 가능
운영 편의성	TimescaleDB는 PostgreSQL 호환, InfluxDB는 TICK 스택 기반의 시각화·알림·처리 기능 제공
산업 활용 사례	스마트팩토리에서 설비 모니터링, 공정 추세 분석 등으로 TSDB 도입 사례 증가 (InfluxDB, TimescaleDB 등)

[데이터 품질 요건]

품질 요소	요구 사항 설명
정확성	센서 보정(Calibration)을 통해 신뢰 가능한 수치 확보
일관성	단위(예: °C, bar)와 변수명이 공정 및 설비 간 동일하게 유지
완전성	누락 데이터(Missing) 없이 연속적으로 수집되며, 이상치 보정 가능해야 함
시간 정렬성	타임스탬프가 오름차순 정렬되어 있고 중복·역순 없이 연속성을 보장
추적 가능성	각 데이터가 어떤 설비, 공정, 배치에서 수집된 것인지 명확한 식별 정보 포함

[시스템 연계 포인트 및 타이밍]

계층 (ISA-95 기준)	구성 요소	주요 역할 및 연계 포인트
Level 0–1	센서, PLC	실시간 센서 데이터 수집 (온도, 압력 등), 타임스탬프 포함 로우 데이터 생성
Level 2	SCADA, Historian	실시간 모니터링, 알람 처리, 히스토리 저장 (시계열 DB), 엣지 게이트웨이 연계 가능
Level 3	MES	생산 실행 정보(작업지시, 배치ID 등) 관리, SCADA/Hist. 데이터와 매핑 및 통합 분석
전송 방식	MQTT, OPC UA, REST API	엣지 장비 또는 미들웨어를 통해 상위 시스템(MES, 분석 플랫폼 등)으로 시계열 데이터 전송
문맥 정보	설비 ID, 배치 ID 등	분석을 위한 데이터 식별 및 정합성 확보 (시계열 데이터에 연관 메타데이터 포함 필요)
분석/활용	QMS, BI, AI 분석 플랫폼	MES + 시계열 데이터를 통합하여 품질 이상 감지, 공정 최적화, 예지 정비 등 고도화 분석 수행

ISA-95 는 MES과 ERP 간의 정보 교환과 역할 분리를 표준화한 국제 모델입니다. 목적은 생산 현장(OT)과 기업 경영(IT) 간의 연계 구조를 명확히 하고, 시스템 통합을 쉽게 만드는 것입니다.

구분내용

정의	제조 운영(Operations)과 경영 시스템 간의 기능·데이터 인터페이스를 표준화한 모델
목표	MES와 ERP 등 이기종 시스템 간 통신·역할 구분 명확화자동화 계층 구조 정립
적용 분야	MES 구축, ERP-MES 연동, 스마트팩토리 설계, 데이터 흐름 구조 설계 등
구성 요소	5단계 계층 모델(Level 0~4), 정보 모델(Object/Activity/Operations 등) 포함

계층(Level)별 역할을 요약해보았습니다.

레벨	설명	시스템 예시
L0	물리적 장치, 센서/액추에이터	온도 센서, 압력계, 모터 등
L1	제어 장치, 상태 수집	PLC, 드라이브, RTU 등
L2	현장 제어/운전 모니터링	SCADA, HMI
L3	생산 실행 및 스케줄링	MES (작업지시, 트래킹 등)
L4	경영 및 자원 계획	ERP (수주, 자재관리, 회계 등)

[데이터 저장 관리 및 확장성]

항목	설명
쓰기 성능	초당 수백만 건 데이터 삽입 가능, 실시간 인덱싱 및 압축 저장
저장 효율	시계열 전용 압축 기술로 저장 용량 절감, 고속 읽기 성능 유지
보존 정책	일정 기간 경과 데이터 자동 삭제 또는 집계(Downsampling) 기능 제공
확장성	클러스터 아키텍처 기반 수평 확장(노드 추가) 가능, 대규모 설비 데이터 대응
고가용성/복제	장애 대비를 위한 데이터 복제, 고가용성(HA) 클러스터 구성 지원
운영 안정성	대량 시계열 데이터에도 안정적인 수집·보관·조회 보장

[도입 사례]

각 업정 사례에서 공통적으로, 시계열 DB(히스토리안) 도입을 통해 대용량 센서 데이터를 효율적으로 관리하고 있습니다. InfluxDB, Timeplus, Grafana 같은 오픈소스 기반 솔루션도 널리 활용되며, 기존 MES/SCADA 시스템과 연동되어 데이터 파이프라인을 구축합니다.

업종	수집 데이터	분석 목적	저장/분석 시스템	도입 효과 요약
반도체	온도, 압력, 플라즈마, 가스유량 등	공정 이상 감지,설비 이상 예측	Historian + 시계열 DB + AI	공정중단 감소, 설비 예지보전, 재작업률 감소
자동차	진동, 전류, 온도, 소음, 토크 등	설비 고장 예측, 품질 이상 감지	SCADA + Historian + AI 모델	다운타임 40%↓, 불량률 70%↓, 유지보수 비용 절감
식음료	온도, 압력, 진동, 탭 사용량	품질 관리, 설비 상태 모니터링	IoT 플랫폼 + 클라우드 TSDB	생맥주 품질 27%↑, 고장률 13%↓, 서비스비 10%↓
화학/정유	진동, 압력, 온도, 유량	펌프·열교환기 이상 감지, 예지보전	Historian 또는 InfluxDB + AI	고장예측 정확도 90%↑, 점검시간 40%↓, 안전성 향상

26년 01월 31일 - 미국 SMR, ETF

keun90 — Sat, 31 Jan 2026 11:16:20 +0900

올해는 SMR에 대한 투자가 본격적으로 시작될 것으로 보입니다.

미국의 26년, 전력 소비는 4조 2560kWhSMR로 예상하며, 공급 측면에서 재생에너지와 천연가스 발전이 빠르게 일어나고 있습니다.

미국 전력 생산에서 기존 대형 원자력 비중은 18% 수준이지만, SMR이 차지하는 비중은 0%이며, 초기 단계입니다.

25년 4분기, 미국 SMR 주가는 하락세

AI버블론, 개별 기업들의 유상증자와 대주주매도 이슈 등 발생
유상증자로 확보된 자금은 26년 폭팔적 수요 대응을 위한 설비 투자(Capex) 재원으로 활용될 예정

26년, 미국 SMR에 주목

중국이 개발한 상용 SMR '링롱 1호' 가동(완공)될 예정
미국은 에너지 패권 경쟁에서 위기
실질적인 계약과 수주가 발생하는 구간을 진입 중

빨라진 미국의 원자력 시계

2024.07: ADVANCE Act, SMR 배치를 위한 법적 토대 마련
2025.05: 원자력 행정명령 4건, 트럼프 속도전 명령
2025.10: Project Janus, 미 육군 SMR 배치 계획
2025.12: SPEED Act, 규제 장벽 걷어내며 인어가 절차 가속화
2026 - 원자력 연료 제조 기업에 지원금 지급
- AI 데이터센터의 전력으로 SMR(오클로) 선택한 Meta

ETF

개별주의 변동성이 크기 때문에 ETF도 좋은 선택지가 될 수 있습니다.

(카메코를 단기간 들고 있었음에도, 변동성이 매우 크다고 느끼고 있습니다.)

ACE ETF - 미국

ACE ETF - 미국 vs 한국

VanEck Uranium and Nuclear ETF (NLR)

빅테크 기업, SMR 투자

지금까지 러시아산 에너지를 많이 사용했었지만, 의존도를 탈피하기 위해 미국 정부는 투자를 계속할 것으로 보입니다.

반도체 → 메모리 → 전력, 쇼티지를 보일 것으로 예상됨에 따라 빅테크 기업들도 투자를 시작하고 있습니다.

일로 머스크도 머지않은 미래에 에너지가 화폐를 대체할 것이라고 전망했습니다.

https://www.asiae.co.kr/article/2025120411041604899

머스크도 언급한 돈 없는 사회…"돈 보다 에너지" - 아시아경제

일론 머스크 테슬라 최고경영자(CEO)는 머지않은 미래에 에너지가 화폐를 대체할 것이라고 전망했다. 기술 발전으로 모든 게 풍족해지면 돈의 쓸모는 사라지지만,...

www.asiae.co.kr

메타가 우선 SMR 기업과 6.6GW 구매 계약을 맺었습니다.

http://hankyung.com/article/2026011137871

메타, 전력 쇼핑…오클로·비스트라와 '원전 동맹'

메타, 전력 쇼핑…오클로·비스트라와 '원전 동맹', 美기업 3곳과 6.6GW 구매 계약 가동 전인 SMR·MMR까지 '찜' '즉시 전력'부터 미래 수요도 챙겨 AI데이터센터 시장 선점 '포석'

www.hankyung.com

한국 SMR 관련

대한민국에도 두산에너빌리티(주기기 제작)와 한전기술(설계) 등 건설과 설계 관련 기업이 존재하고 있습니다.

한전기술 +90% past year
두산에너빌리티 +280% past year

SMR(Small Modular Reactor)

소형 모듈 원자로
50~300MW 출력 (기존 대형 원전 1,000MW 이상)
대규모 송전망 없이 지역 단위 전력 공급
안전성과 유연성을 강화한 분산형 원자력

26년 01월 27일 - 미주 6개월 후

keun90 — Wed, 28 Jan 2026 21:36:49 +0900

현재 시장의 위치가 실제 가치와 비교했을 때 상황을 점검해보겠습니다.

시장은 항상 경기보다 먼저 움직입니다.

선행지표 → 주식시장 → 경제지표
보통 선행지표는 주식시장보다 6개월 먼저 반영됩니다.

미국의 경제 대표 경제 지표

[대형 트럭 판매 지수]

경제위기 전에 작동하는 신호로 3가지 사례별 대형트럭판매 지수를 확인할 수 있습니다.

미국에서는 경제 성장의 확신이 생길 때 대형트럭을 구매합니다.

닷컴버블 - 2000~2002년, 대형트럭판매 정점(3~6개월)
리먼사태 - 2008~2009년, 대형트랙판매 정점(12개월)
팬데믹 - 2020년 1~2분기, 대형트랙판매 정점(6~8개월)

그래프를 보면 대형트럭의 판매 지수가 최고조에 이른 이후에 모두 하락한 것을 볼 수 있습니다.

https://ko.tradingeconomics.com/united-states/total-vehicle-sales

[주택 구매 지수 ]

또한, 주택 구매를 볼 수 있습니다.

사람들은 앞으로 경기가 좋아질 것으로 보고 주택을 구매하기 때문입니다.

주택 판매가 줄면 가구, 가전, 인테리어, 금융까지 순차적으로 볼륨이 작아집니다.

역사적 데이터를 보면 주택 판매가 꺾이면 주식시장도 하락했습니다.

미국 기존주택 판매 지수를 보면 23년부터 수축국면에 접어들었습니다.

https://ko.tradingeconomics.com/united-states/existing-home-sales

주택 판매가 회복되기 위해서는 500만채 이상이 거래되어야 합니다.

트럼프 정부가 특단의 조치를 취했으며, 하락하는 경기를 잡기 위한 노력으로 보입니다.

기관투자자 단독주택 매입 제한
모기지 시장 안정 위해 정부 개입 확대
주택 구매 문턱 낮추는 추가 정책 추진

선행지표들은 모두 시장의 하락을 가리키고 있습니다.

하지만, 기업의 이익은 전혀 줄어들지 않고 있어 주가를 계속해서 상승하고 있습니다.

그리고 트럼프도 기업을 이익을 위해 정책을 마련하고 있습니다.

기업의 이익이 겨우 주가를 떠받치고 있지만, 6개월 후 변화에 대비해야 합니다.

OPC-UA 실습 5 - 인터페이스 시나리오 설계

keun90 — Mon, 26 Jan 2026 20:17:16 +0900

샘플(노드 구조, 메시지 흐름)

현재 구성한 노드의 구조는 아래와 같습니다.

Objects
└─ Factory
   └─ LINE1
      └─ EQP1
         ├─ Status        (UInt16)    // 설비 상태 코드
         ├─ Temperature   (Double)    // 온도 값
         ├─ LastUpdate    (DateTime)  // 마지막 갱신 시각(UTC)
         ├─ Seq           (UInt32)    // 증가 시퀀스
         └─ RawMessage    (String)    // 원문 메시지(선택)

일반적인 Message Flow(TCP, Client-Server)는 아래와 같습니다.

# Message Flow (TCP, Client–Server

User        PLM          MES           OPC UA Server        PLC
 |           |            |                 |               |
 | 1.Change  |            |                 |               |
 |---------->|            |                 |               |
 |           | 2.Notify   |                 |               |
 |           |----------->|                 |               |
 |           | (Change,   |                 |               |
 |           |  SEQ=1001) |                 |               |
 |           |            | 3.Validate SEQ  |               |
 |           |            |                 |               |
 |           |            | 4.ACK           |               |
 |           |<-----------|                 |               |
 |           |            | (ACK,1001)      |               |
 |           |            |                 |               |
 |           |            | 5.Write Params  |               |
 |           |            |---------------> |               |
 |           |            | (CMD, SEQ=2001) |               |
 |           |            |                 | 6.Apply       |
 |           |            |                 |-------------->|
 |           |            |                 |               |
 |           |            |                 | 7.ACK         |
 |           |            |<--------------- |               |
 |           |            | (ACK,2001)      |               |

일반적인 Message Flow(Pub/Sub)는 아래와 같습니다.

# Message Flow (Pub/Sub)

User        PLM        Event Bus / OPC UA PubSub        MES        PLC
 |           |                 |                        |          |
 | 1.Change  |                 |                        |          |
 |---------->|                 |                        |          |
 |           | 2.Publish       |                        |          |
 |           |---------------> |                        |          |
 |           | (Event,         |                        |          |
 |           |  SEQ=3001)      |                        |          |
 |           |                 | 3.Deliver              |          |
 |           |                 |----------------------> |          |
 |           |                 | (Event, SEQ=3001)      |          |
 |           |                 |                        | 4.ACK*   |
 |           |                 | <----------------------|          |
 |           |                 | (ACK,3001)             |          |
 |           |                 |                        |          |
 |           |                 | 5.Deliver              |          |
 |           |                 |------------------------------->   |
 |           |                 | (Event, SEQ=3001)                 |

메시지 전송 트리거

[이벤트 발생 기반 전송]

특정 상태 변화나 이벤트가 발생할 때마다 메시지를 보내는 방식입니다.

특정 상태 코드(Status) 또는 온도(Temperature)가 임계치를 넘는 등 유의미한 변화가 있을 때 PLC의 OPCUA 서버는 해당 값들을 업데이트하고, 이를 MES 클라이언트가 Sub으로 감지하여 처리합니다.(Polling 없이 Sub으로 실시간 감지 가능)

[주기적/배치 전송]

특정 주기 또는 공정 단계 완료 시점 등에 정기적으로 메시지를 묶어 보내는 방식입니다. 실시간성은 떨어지지만, MES에서

수집하여 일괄 처리하거나 네트워크 부하를 조절할 때 유용합니다.

메시지 내용 및 데이터 모델

메시지의 데이터 구조는 양측 시스템 모두에 의미 있고 확장 가능하도록 설계해야 합니다.

현재 구성한 노드는 아래와 같습니다.

Status (UInt16): 설비 상태 코드 (예: 가동/정지/에러 등의 코드)
Temperature (Double): 현재 온도 값 (프로세스 변수 예시)
LastUpdate (DateTime): 해당 데이터셋이 갱신된 시각 (UTC 기준)
Seq (UInt32): 메시지 시퀀스 번호 (증가하는 고유 ID)
RawMessage (String): 원문 메시지 (선택 사항, 필요 시 구조화된 문자열 또는 JSON 등)

추가로 고려해볼 사항입니다.

[메시지 타입 식별자]

Microsoft Azure OPC UA Connector의 메시지 헤더에는 type이나 subject 필드로 메시지 종류와 대상 자산을 구분하고, sequence 필드로 메시지 일렬번호를 제공하고 있습니다.

OPC UA Message
├─ header
│  ├─ type        // 메시지 종류 (telemetry | event | alarm | command)
│  ├─ subject     // 대상 자산 (site/line/equipment/tag)
│  ├─ sequence    // 메시지 일련번호 (증가값), 자산에 메시지가 하나 발행될 때 생성
│  ├─ timestamp   // 이벤트 발생 시각 (UTC)
│  └─ source      // OPC-UA 서버 또는 Endpoint
│
└─ body
   ├─ nodeId      // OPC-UA NodeId
   ├─ value       // 실제 값
   ├─ dataType    // OPC-UA DataType
   ├─ quality     // StatusCode (Good/Bad/Uncertain)
   └─ meta        // 확장 정보 (선택)

------------------------------------------------------------------------

{
  "header": {
    "type": "telemetry",
    "subject": "factory1/lineA/eqp01/temperature",
    "sequence": 102345,
    "timestamp": "2026-01-23T01:15:30Z",
    "source": "opc.tcp://10.0.0.5:4840"
  },
  "body": {
    "nodeId": "ns=2;s=Factory.LineA.EQP01.Temperature",
    "value": 72.4,
    "dataType": "Double",
    "quality": "Good",
    "meta": {
      "unit": "C",
      "samplingIntervalMs": 1000
    }
  }
}

# 배열 

{
  "header": {
    "type": "telemetry",
    "subject": "factory1/lineA/eqp01/sensors",
    "sequence": 33012,
    "timestamp": "2026-01-23T01:15:40Z",
    "source": "opc.tcp://10.0.0.5:4840"
  },
  "body": {
    "nodeId": "ns=2;s=Factory.LineA.EQP01.SensorArray",
    "dataType": "Structure[]",
    "value": [
      { "sensorId": "T1", "value": 72.4 },
      { "sensorId": "P1", "value": 1.02 }
    ],
    "quality": "Good"
  }
}

[설비 라인 식별 정보]

지금은 subject 값으로 line, eqp 정보를 알 수 있지만, object가 많아지면 msg 항목에 추가 시켜도 좋습니다.

[여러 데이터 포인트 묶음]

데이터 덩어리가 아닌 개체로 표현
관련 데이터를 묶어, 설비의 의미를 구조로 표현하는 것

Objects
 └─ Factory
    └─ LineA
       └─ EQP01
          ├─ Status (Object)
          │   ├─ Temperature
          │   ├─ Pressure
          │   └─ RunState
          │
          └─ StatusData (Structure)
              └─ { temperature, pressure, runState, alarm }

메시지 순서 보장과 유실 검출

신뢰성 있는 MES-PLC 통신을 위해선느 메시지의 순서가 보장되고, 누락된 메시지를 감지하는 메커니즘이 필요합니다. OPCUA 자체도 전송 계층에서 순서 제어와 누락 검출 기능을 일부 제공합니다.

내용 초반에 노드 구성을 보면 Seq 노드가 응용 레벨 시퀀스 번호입니다. 이 번호를 활용하여 다음과 같은 전략을 구현할 수 있습니다.

메시지 순서 부여: PLC는 새로운 메시지 생성할 때마다 Seq 값을 1씩 증가시켜 붙입니다. MES에서 Seq 값을 확인해 누락된 것을 확인할 수 있습니다.
핸드셰이크 설계: ACK 메커니즘을 토입하면 더욱 신뢰성 있는 구성이 가능합니다. https://cache.industry.siemens.com/dl/files/835/109814835/att_1140017/v2/109814835_SiemensInformationModelKit_DOC_v3_0_en.pdf#:~:text=SequenceNo%20UInt32%20Unique%20sequence%20number,for%20this%20handshake%20interface%2C%20to

시퀀스 번호는 메시지의 순서를 추적하고 유실 여부를 판단하는 핵심 장치입니다. OPCUA 통신 자체가 TCP 기반이라 전송된 메시지는 순서를 유지하지만, 네트워크 장애나 구독 지연 등으로 인해 어떤 메시지가 전달되지 못하는 상황에 대비해야 합니다. 가능하다면, Seq와 ACK를 활용하여 검증하는 것을 권장합니다.

재기동/장애 시 복구 전략

예외 상황에서 데이터를 어떻게 복구하고 흐름을 재개할지 대비해야 합니다.

[세션 재연결 및 구독 복원]

대부분의 OPCUA 클라이언트 SDK는 세션 끊김을 감지하면 자동으로 재연결 및 sub 복구 기능을 제공하거나, 그렇지 않으면 재구독 로직을 구현해야 합니다. 재연결 후 초기에 한 번 현재 값들을 읽어서 PLC 상태를 동기화하는 것도 좋습니다.

[시퀀스 동기화]

재연결 시 MES는 현재 PLC의 Seq 값을 읽고, 자신이 마지막으로 처리한 Seq와 비교해야 합니다. 통신 장애로 인해 MES.Seq=50이고 PLC.Seq=55이면, 51~54에 대한 누락 메시지 처리 방안에 대해 정리해야 합니다.

단순 로그: 누락된 번호를 기록하고, 운영자가 별도로 확인합니다.
데이터베이스/이력 복구: PLC가 중단 후 발생한 메시지를 메모리나 파일에 보관해두었다며, MES가 재연결 후 전송을 받습니다. OPCUA-Historical Access / Events / History Read 기능이 관련있습니다.

[미처리 메시지 처리]

장애 직전에 송신되었으나 미처 Ack 받지 못한 메시지가 있을 수 있습니다. MES → PLC로 보낸 경우 PLC가 해당 명령을 수행했는지 불확실하고, PLC → MES인 경우 MES가 처리 못 했을 수 있습니다. 핸드셰이크를 도입해쑈다면, 재연결 시 Ack 불일치로 파악하여 재전송이 가능하지만, 단순 구조에서는 이 부분을 고려해야 합니다. 일반적으로 MES에서는 중요 트랜잭션은 응답을 받을 때까지 재시도하거나, PLC쪽에서는 중복 수신에 대비하여 동일한 Seq의 메시지가 다시 와도 한 번만 처리하도록 만들어 두는 것이 안전합니다.

Sequence

메시지에 붙은 고유한 번호
이 메시지가 몇 번째인가?를 식별하기 위한 값
메시지 중복 판단 / 순서 보장
Seq만으로는 "처리되었는지" 알 수 없음

ACK(Acknowledgement)

이 Seq 메시지를 정상 처리했다 라는 응답
송신자가 안심하고 다음 단계로 넘어가게 하는 신호
ACK는 수진자가 전송
ACK 없으면 처리 여부 불확실

MES → PLC
SEQ: 101, 102, 103 ...

PLC → MES
ACK: seq=101

요약하면, 재기동/장애 시에는 세션 복구 → 시퀀스 동기화 확인 → 누락 데이터 검토의 단계를 거칩니다. OPCUA의 내재된 신뢰성 기능을 활용하고, 추가로 응용단에서 시퀀스 비교를 통한 누락 검출 및 로그를 시행하면 한층 견고한 통신을 구현활 수 있습니다.

MES-PLC 양방향 통신의 중요성

MES → PLC 명령이나 설정값을 보내고, PLC → MES 로 생산 실적이나 이벤트를 보내는 것 모두 원활해야 제조 실행 시스템이 제대로 가능합니다. 시나리오를 예로 정리해보았습니다.

MES → PLC

생산 지시 다운로드, 레시피 파라미터 전송, 설비 제어 명령(가동/정지 등) 등을 MES에서 PLC로 내보낼 수 있어야 합니다.
OPCUA에서는 이를 위해 MES에서 PLC의 변수를 Write하거나 OPCUA 메서드를 호출하는 방식이 일반적입니다.
메서드는 하나의 호출로 여러 파라미터(구조체 형태)를 전달하고 실행 겨로가를 돌려받을 수 있습니다.

PLC → MES

설비에서 발생하는 이벤트, 알람 등은 OPCUA 서버가 값 변경이나 Event 발생을 통해 MES로 전달해야 합니다.
Seq 증가와 노드 업데이트 매커니즘이 바로 이 방향의 통신을 담당합니다.

PLC ↔ MES

PLC에서 설비 알람을 MES로 전송합니다.
MES에서 담당자가 알람을 확인/해제하면, PLC에 전달하여 PLC도 알람 acknowledge를 완료하는 형태가 됩니다.

단순 구현과 향후 확장성 고려

현재 요구를 단순하고 확실하게 충족하면서도 미래의 확장에 대비해야 합니다.

[과도한 오버엔지니어링 지양]

초기 단계부터 복잡한 시나리오를 구현하려 하면 개발과 유지보수가 어려워질 수 있습니다. 간략한 구조에서 Seq/Ack 태그만으로 메모리 버퍼에 데이터를 안전하게 주고받게 구성할 수 있습니다. https://cache.industry.siemens.com/dl/files/835/109814835/att_1140017/v2/109814835_SiemensInformationModelKit_DOC_v3_0_en.pdf#:~:text=The%20client%20checks%20for%20available,it%20is%20ready%20to%20receive

[OPCUA 표준 기능 활용]

가능한 한 OPCUA 표준 케커니즘을 활용하는 것이 좋습니다.

연결 유지(Keep-Alive)
자동 재연결
데드밴드(Deadband)를 통한 잡음 필터링
히스토리 데이터 저장
...

[확장 시나리오 대비]

향후 더 많은 장비가 추가되거나, 메시지 종류가 다양해질 것으로 대비하여 모델을 일반화하면 좋습니다. OPCUA의 네임스페이스와 노드 구조를 체계적으로 설계해 두면, MES 쪽에서도 Browse 경로나 Node ID 패턴을 통해 동적으로 장비를 추가해나가기 수월합니다.

[테스트 및 모니터링 도구]

자동화된 통합 테스트를 만들어 다양한 시나리오에서 메시지 흐름을 검증해야 합니다.

다음 시간

소캣, opc 어떤 통신이던 queue에 쌓아놓고 처리하는 설계가 필요할 것 같다

[AI Prompt]

너는 OPCUA, MES 전문가이다.
전문가 의견으로 판단해줘.
나는 MES를 다루는 엔지니어이다.
OPCUA에 대한 아주 기본적인 사항은 마무리한 것으로 보인다.
#다음작업으로 실제 메시지 흐름을 설계해보고 싶다.
나의 생각에 대해 부족한 부분이 있으면 의견부탁한다.

#구축완료한환경 :
- 하나의 윈도우 PC에 OPC-UA 서버 구동 완료
- 하나의 윈도우 PC에 OPC-UA 클라이언트 구동 완료
- 서버와 클라이언트 연동 완료
- 서버의 uanodesetimport.xml에 Node 추가(bjects → Factory → Line → PLC → Message)
- PLC 역할의 메시지 전달 로직 수행, 2개
- uaexpert에서 Message Value 값 수정 가능 확인
- 노드 구조
Objects
└─ Factory
   └─ LINE1
  └─ EQP1
├─ Status        (UInt16)    // 설비 상태 코드
├─ Temperature   (Double)    // 온도 값
├─ LastUpdate    (DateTime)  // 마지막 갱신 시각(UTC)
├─ Seq           (UInt32)    // 증가 시퀀스
└─ RawMessage    (String)    // 원문 메시지(선택)
- 테스트 PLC 코드로 테그값 변경 완료
- StressTest 진행
Write 부하 테스트 수행, 10개 서비스 구동 중
    Subscription 서비스 10개, 서비스당 4개 노드 구독
- Stress 테스트 종료
- Pub/Sub에 대한 개념 이해

#다음작업
-  메시지 언제 보낼 것인가 (이벤트 기준)
-  메시지 무엇을 담을 것인가 (데이터 모델)
-  메시지 순서/유실을 어떻게 판단할 것인가 (Sequence)
-  재기동/장애 시 어떻게 복구할 것인가

#DO
- 코딩 외적으로 필요한 부분은 주석으로 설명

#DO NOT
- 의미 없는 코드 작성
- 오버 엔지니어링 금지

26년 01월 23일 - 미국 증시 요약

keun90 — Sat, 24 Jan 2026 15:14:11 +0900

전체 현황

다음 주 실적 발표와 통화정책 이벤트를 앞두고 숨 고르기에 들어간 모습을 보였습니다.

엔화는 일본 당국이 환율 방어를 위해 개입할 수 있다는 관측이 나오면서 상승했습니다.

트럼프 대통령은 이란에 군 병력을 집결시켰습니다.

종목별

[엔비디아, NVDA]

중국이 H200 AI 칩 주문 준비를 허용했다는 소식에 1.5% 상승했습니다.

H200: 데이터센터·AI 훈련·추론용으로 개발한 고성능 AI 가속 칩
H20 → H200 → Blackwell/Rubin

[인텔, INTC]

실적 전망 부진 여파로 17% 급락했습니다.

26년 1분기 실적 가이던스(전망)가 월가 기대치보다 낮게 발표됨
월가 기대치($12.6 B), 인텔 가이던스($12.2 B)
제조 및 공급망 문제로 AI 서버용 칩 수요를 충분히 맞추지 못할 것이라고 경영진이 언급하면서 실적 회복 속도에 대한 불확실성이 커짐
CPU의 수요는 강했지만, 공급을 못하고 수율과 마진이 좋지 못해서 부정적 영향 발생
NVDA, AMD, TSMC 모두 주가 상승을 보임

[크래프트하인즈, KHC]

버크셔도 전량 주식을 매각할 준비를 하면서 기업의 전망은 매우 불투명해졌습니다.

어디서부터 무너져온 걸지 알아보겠습니다.

3G캐피탈이 크래프트 + 하인즈를 인수·합병하면서 사모펀드의 특징에 따라 기업의 비용 절감을 시작합니다.

비용 절감을 위해 모든 제품 품질 등 산업 전반에 걸쳐 부정적인 영향을 주게 됩니다.

직원들은 압박에 이기지 못해 회계 부정까지 저지르는 사건이 발생합니다.

악재가 겹치자 버빗도 62% 손실을 얻게 되었습니다.

지표

[소비자 심리]

26년 1월 미국 소비자 심리가 5개월 만에 최고치를 기록했습니다.

전원 대비 상승했지만, 지수 수준은 여전히 작년 같은 달보다 20% 낮은 수준
높은 물가, 노동시장 우려, 구매력 압박 등 소비자들이 느끼는 부담이 여전함
다른 실물 지표들과 함께 추세를 봐야 의미 있는 판단이 가능

[인플레이션심리]

단기적 개선

실제 물가가 아니라 기대 심리 지표
상승: 물가 불안 → 금리 인하 어려움
안정/하락: 물가 통제 신뢰 → 금리 인하 여지

[PMI, Purchasing Managers Index]

개선

기업 현장의 체감 경기 지표
기업들이 지금 주문·생산을 늘리고 있는가
제조업·서비스업 구매 담당자에게 직접 설문
PMI (↑) + 신규주문 (↑) → 경기 회복 초입
PMI (↓) + 고용 (↓) → 경기 둔화·침체 신호

자금 흐름 데이터

미국에서 빠져나가는 흐름이 포착되었습니다.

미국 주식형 펀드에서 170억 달러 유출
유럽·일본·신흥시장으로의 자금 유입은 오히려 가속화되었음

단, 개인투자자는 미국 주식을 약 40억 달러어치 순매수했습니다.

국채(Treasury)

현재 투자자들이 포트폴리오 다각화를 위해 미국 채권을 팔고 있으며, 이를 미국이 사주고 있는 상황입니다.

미국 국체를 만기로 구분한 말의 의미입니다.

만기	시장에서 의미	무엇을 반영	핵심 질문
1년물	현재 금리	연준 정책금리, 단기 유동성	지금 금리는 어떤가
2년물	연준의 다음 수	향후 1~2년 금리 경로	언제 금리를 내릴까
5년물	중기 경기	경기 사이클, 인플레 지속성	침체가 온다면 얼마나 갈까
10년물	장기 경제 신뢰	장기 성장률, 물가, 재정 신뢰	미국 경제는 장기적으로 괜찮은가

원자재

The US-China AI and geopolitical power race and global energy supply waves drive our analysts key convictions..

Goldman Sachs Research's cyclical macro base case of sturdy global GDP growth and 50 basis points of Fed rate cuts in 2026is again supportive of top-down commodify returns.

원자재 시장이 강세를 유지할 위험/기회 요인들이 존재하며, 2026년의 거시 환경(성장+금리 인하)이 원자재 수익에 우호적이라고 보여지고 있습니다.

금/은/구리가 대표적으로 긍정적인 영향을 보이고 있으며, 이에 따라 코인 시장은 점차 위축될 것으로 보입니다.

다음주 이슈

매그니퍼센트 7 기업 다수가 실적을 발표할 예정입니다.

https://old.earningswhispers.com/calendar

또한, 연준은 다음 주 금리를 동결할 가능성이 높지만, 파월 의장의 발언을 면밀히 분석해야 합니다.

OPC-UA 실습 4 - Pub/Sub 아키텍처

keun90 — Wed, 21 Jan 2026 20:10:02 +0900

Pub/Sub 아키텍처의 필수성

공장 자동화 현장에서 보면, 필수라기 보다는 "선택지"에 가깝습니다.

공장 데이터의 외부 연계(Cloud, AI)
MES 외에도 Dashboard, AI, 모니터링 등 데이터 소비자 증가
(메시지를 한 번 발생하고, 필요한 쪽에서 알아서 구독하는 모델)
네트워크 경계(OT ↔ IT ↔ 외부)

Pub/Sub이 오버엔지니어링인 경우는 다음과 같습니다.

통신 주체가 명확하다.
소비자가 소수이다.
Read/Write가 중요하다.
실시간 제어와 상태 조회가 핵심이다.

느슨한 통신 구조 + 여러 클라이언트가 있다면, Pub/Sub 구조가 적합할 것입니다.

Pub/Sub을 구성하기에 앞서 다음과 같은 질문을 해보았으면 합니다.

이 메시지는 유실돼도 되는가?
중복되면 문제가 되는가?
느린 Sub는 어떻게 처리하는가?
재기동 시 이전 메시지를 처리해야 하는가?
이 메시지는 언제까지 유효한가?
누가 이 메시지를 책임지는가?

Pub/Sub vs Broadcasting

Broadcast 방식은 커낵션 되어 있는 모든 대상에 메시지를 전송하는 것입니다.

Pub/Sub은 Topic를 구독한 애들만 받도록 함에 있어 구조적 차이가 있습니다.

Topic은 메시지를 분류하는 논리적 주소(채널)입니다.
Pub → Msg → Topic
Sub 는 Topic을 구독합니다.

Pub/Sub이 Topic을 구성하지 않으면 Broadcast와 유사해집니다.

Pub/Sub의 구조

간략한 구조와 코드에 대한 설명을 해보겠습니다.

Pub은 msg를 Topic에 전달하고, Topic 구조를 명확히 해줍니다.

Sub은 Topic에 대한 구독자를 등록하기 위해, subscribe()를 호출해줍니다.

화면에서는 Sub한 메시지를 직접 조회하지 않고 Cache 데이터를 바라봅니다.

만약, Sub 종료가 필요하면, 반드시 UnSubscribe를 해주어야 합니다.

# Topic 
	factory/line1/eqp1/status
    
Publisher
  └─ publish("factory/line1/eqp1/status", msg)
        ↓
PubSubBus
        ↓
Subscriber(on_status) 만 호출, Topic에 구독자(on_status)가 등록되어 있음


#화면 구동 시 데이터 갱신 

[화면 열기]
   ↓
subscribe() 실행
   ↓
Subscriber 콜백 등록
   ↓
Publisher publish()
   ↓
콜백 호출
   ↓
화면 데이터 갱신 (Cache의 데이터를 조회)

다음은 실제로 현장에 존재할 메시지 시나리오를 작성해보겠습니다.

- 메시지 언제 보낼 것인가 (이벤트 기준)
- 메시지 무엇을 담을 것인가 (데이터 모델)
- 메시지 순서/유실을 어떻게 판단할 것인가 (Sequence)
- 재기동/장애 시 어떻게 복구할 것인가

OPC-UA 실습 3 - 가상 환경, Message, StressTest, Pub/Sub

keun90 — Wed, 21 Jan 2026 12:40:37 +0900

실습 2에 이어서 환경 구성을 더욱 운영 환경에 맞추어 설정하보겠습니다.

PLC 테스트 코드를 하나 더 증가, 다중 테스트

PLC 테스트, 메시지 전송하는 프로그램을 추가, 동일한 node로 메시지를 전송해보았습니다.

하나의 노드는 두 PLC 메시지를 정상적으로 처리했습니다.

노드를 쪼개서 관리하면 하나의 설비에서 상태 값 별로 서로 다른 메시지를 OPC-UA서버로 전달하는 구조가

가능할 것 같습니다.

장점

값별로 독립적으로 갱신 가능
MES는 필요한 태그만 Subscription
서버가 동시 write 요청 처리 가능

단점

동시성 관리 필요
Seq/Timestamp 설계 없으면 누락 인지 어려움
노드 수 증가, 관리/메모리 부담
설계 복잡도 증가

Message Value 단순 구조가 아닌, 실제 Message 포맷으로 변경

NodeSet이란 OPC UA 서버가 외부에 공개할 데이터/구조의 설계도 입니다.

2장, uanodesetimport.xml에 노드를 추가하면서 다루어본 경험이 있습니다.

노드를 쪼개기 위한 구조는 다음과 같습니다.

# 기존 구조
Factory → Line → PLC → Message(String)

Objects
 └─ Factory
     └─ LINE1
         └─ EQP1
             ├─ Status      (UInt16 or Int32)   # 0=STOP,1=RUN,2=ALARM...
             ├─ Temperature (Double)            # ex 36.7
             ├─ LastUpdate  (DateTime)          # 서버/설비 기준 시간
             ├─ Seq         (UInt32)            # 누락/순서 검증용
             └─ RawMessage  (String)            # (선택) 원문/디버깅용

uanodesetimport.xml 설정 파일은 아래 더보기를 클릭해주세요.

<UAObject NodeId="ns=1;s=Factory" BrowseName="1:Factory">
    <DisplayName>Factory</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=61</Reference>

        
        <Reference ReferenceType="Organizes" IsForward="false">i=85</Reference>

        
        
        

        
        <Reference ReferenceType="Organizes">ns=1;s=Factory.LINE1</Reference>
    </References>
    </UAObject>

    
    

    
    <UAObject NodeId="ns=1;s=Factory.LINE1" BrowseName="1:LINE1">
    <DisplayName>LINE1</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=61</Reference>

        
        <Reference ReferenceType="Organizes" IsForward="false">ns=1;s=Factory</Reference>

        
        <Reference ReferenceType="Organizes">ns=1;s=Factory.LINE1.EQP1</Reference>
    </References>
    </UAObject>

    
    <UAObject NodeId="ns=1;s=Factory.LINE1.EQP1" BrowseName="1:EQP1">
    <DisplayName>EQP1</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=61</Reference>

        
        <Reference ReferenceType="Organizes" IsForward="false">ns=1;s=Factory.LINE1</Reference>

        
        <Reference ReferenceType="HasComponent">ns=1;s=Factory.LINE1.EQP1.Status</Reference>
        <Reference ReferenceType="HasComponent">ns=1;s=Factory.LINE1.EQP1.Temperature</Reference>
        <Reference ReferenceType="HasComponent">ns=1;s=Factory.LINE1.EQP1.LastUpdate</Reference>
        <Reference ReferenceType="HasComponent">ns=1;s=Factory.LINE1.EQP1.Seq</Reference>
        <Reference ReferenceType="HasComponent">ns=1;s=Factory.LINE1.EQP1.RawMessage</Reference>
    </References>
    </UAObject>

    
    <UAVariable NodeId="ns=1;s=Factory.LINE1.EQP1.Status"
            BrowseName="1:Status"
            DataType="UInt16"
            AccessLevel="3"
            UserAccessLevel="3">
    <DisplayName>Status</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=63</Reference>
        <Reference ReferenceType="HasComponent" IsForward="false">ns=1;s=Factory.LINE1.EQP1</Reference>
    </References>
    <Value>
        <uax:UInt16>0</uax:UInt16>
    </Value>
    </UAVariable>

    
    <UAVariable NodeId="ns=1;s=Factory.LINE1.EQP1.Temperature"
            BrowseName="1:Temperature"
            DataType="Double"
            AccessLevel="3"
            UserAccessLevel="3">
    <DisplayName>Temperature</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=63</Reference>
        <Reference ReferenceType="HasComponent" IsForward="false">ns=1;s=Factory.LINE1.EQP1</Reference>
    </References>
    <Value>
        <uax:Double>0</uax:Double>
    </Value>
    </UAVariable>

    
    <UAVariable NodeId="ns=1;s=Factory.LINE1.EQP1.LastUpdate"
            BrowseName="1:LastUpdate"
            DataType="DateTime"
            AccessLevel="3"
            UserAccessLevel="3">
    <DisplayName>LastUpdate</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=63</Reference>
        <Reference ReferenceType="HasComponent" IsForward="false">ns=1;s=Factory.LINE1.EQP1</Reference>
    </References>
    <Value>
        <uax:DateTime>1601-01-01T00:00:00Z</uax:DateTime>
    </Value>
    </UAVariable>

    
    <UAVariable NodeId="ns=1;s=Factory.LINE1.EQP1.Seq"
            BrowseName="1:Seq"
            DataType="UInt32"
            AccessLevel="3"
            UserAccessLevel="3">
    <DisplayName>Seq</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=63</Reference>
        <Reference ReferenceType="HasComponent" IsForward="false">ns=1;s=Factory.LINE1.EQP1</Reference>
    </References>
    <Value>
        <uax:UInt32>0</uax:UInt32>
    </Value>
    </UAVariable>

    
    <UAVariable NodeId="ns=1;s=Factory.LINE1.EQP1.RawMessage"
            BrowseName="1:RawMessage"
            DataType="String"
            AccessLevel="3"
            UserAccessLevel="3">
    <DisplayName>RawMessage</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=63</Reference>
        <Reference ReferenceType="HasComponent" IsForward="false">ns=1;s=Factory.LINE1.EQP1</Reference>
    </References>
    <Value>
        <uax:String></uax:String>
    </Value>
    </UAVariable>

노드의 구조의 연결, 아이디 중복 등 문제가 발생한다면, 서버 구동 시 다음과 같이 에러가 납니다.

에러 로그 또한 남기 때문에, 원인 분석이 가능합니다.

또한, 자주 만날 수 있는 에러인 BadWriteNotSupported 가 있습니다.

BadWriteNotSupported:
The server does not support writing the combination of value,
status and timestamps provided.
“서버는 값(Value), 상태(Status), 타임스탬프(Timestamp)가 함께 포함된 쓰기 요청을 지원하지 않는다.” 의미입니다.

이는 테스트 서버에서 Value만 쓰기를 허용해서 발생하는 것으로 운영 서버에서는 모두 지원하고 있습니다.

Value
Value + StatusCode
Value + Timestamp
Value + Status + Timestamp

OPC-UA 서버 구동 완료 + Node/Tag 등록이 완료되었다면, 이제 파이썬 코드로 Tag 값을 변경해보면 됩니다.

import asyncio
import time
from datetime import datetime, timezone
from asyncua import Client, ua

OPC_UA_ENDPOINT = "opc.tcp://keun90:48010"

# 서버 NamespaceArray에서 확인된 URI (당신 환경 기준)
TARGET_NAMESPACE_URI = "urn:UnifiedAutomation:CppDemoServer:UANodeSetXmlImport"

# 업데이트 대상 설비 경로
BASE = "Factory.LINE1.EQP1"

# 주기
INTERVAL_SEC = 1


async def get_ns_index(client: Client, namespace_uri: str) -> int:
    """서버 NamespaceArray(i=2255)에서 namespace_uri의 index(ns)를 찾는다."""
    ns_array = await client.get_node(
        ua.NodeId(ua.ObjectIds.Server_NamespaceArray)
    ).read_value()
    return ns_array.index(namespace_uri)


def node_id_str(ns: int, s: str) -> str:
    """ns=<runtimeIndex>;s=<identifier> 형태로 NodeId 문자열 생성"""
    return f"ns={ns};s={s}"


async def main():
    async with Client(OPC_UA_ENDPOINT) as client:
        ns = await get_ns_index(client, TARGET_NAMESPACE_URI)

        # 태그 노드 핸들 (한 번만 만들어 재사용)
        n_status = client.get_node(node_id_str(ns, f"{BASE}.Status"))
        n_temp   = client.get_node(node_id_str(ns, f"{BASE}.Temperature"))
        n_ts     = client.get_node(node_id_str(ns, f"{BASE}.LastUpdate"))
        n_seq    = client.get_node(node_id_str(ns, f"{BASE}.Seq"))
        n_raw    = client.get_node(node_id_str(ns, f"{BASE}.RawMessage"))

        seq = 0
        while True:
            seq += 1

            # ---- 값 생성 (의미 없는 로직 없이 최소) ----
            status = seq % 3  # 0,1,2 반복 (STOP/RUN/ALARM 같은 상태코드라고 가정)
            temp = 36.0 + (seq % 10) * 0.1  # 36.0 ~ 36.9
            ts = datetime.now(timezone.utc)

            raw = (
                f"LINE1|EQP1|status={status}|temp={temp:.2f}|"
                f"seq={seq}|ts={int(time.time())}"
            )

            # ---- 모든 태그 업데이트 ----
            # 모든 태그 업데이트 (Value only write)
            await n_status.write_attribute(
                ua.AttributeIds.Value,
                ua.DataValue(ua.Variant(status, ua.VariantType.UInt16))
            )
            await n_temp.write_attribute(
                ua.AttributeIds.Value,
                ua.DataValue(ua.Variant(temp, ua.VariantType.Double))
            )
            await n_ts.write_attribute(
                ua.AttributeIds.Value,
                ua.DataValue(ua.Variant(ts, ua.VariantType.DateTime))
            )
            await n_seq.write_attribute(
                ua.AttributeIds.Value,
                ua.DataValue(ua.Variant(seq, ua.VariantType.UInt32))
            )
            await n_raw.write_attribute(
                ua.AttributeIds.Value,
                ua.DataValue(ua.Variant(raw, ua.VariantType.String))
            )

            print("UPDATED", BASE, "seq", seq, "status", status, "temp", temp)
            await asyncio.sleep(INTERVAL_SEC)


if __name__ == "__main__":
    asyncio.run(main())

Stress Test

서버의 옳바른 스펙을 산출하는 것도 시니어 엔지니어의 역할이라고 생각합니다.

대표적으로 아래 두 가지 부하 테스트를 진행해보겠습니다.

PLC → Server Write 부하
Client Subscription 부하

Wrtie 부하 테스트 환경은 다음과 같습니다.

로컬 Desktop의 스펙

stressTest 로직 (메시지 전송/초, 업데이트 대상 Tag 4개)
stressTest 서비스 10개 수행

Write 부하까지, 테스트 결과는 CPU=00으로 전혀 부하를 주지 못하는 것을 확인했습니다.

Subscription 부하로 테스트를 이어가겠습니다.

OPC-UA에서 Pub/Sub의 개념을 알아야 하며, 이 개념은 Redis 등 폭 넓게 사용됩니다.

Subscription이란, 클라이언트가 계속 Read를 반복하지 않고, 서버가 "변화"를 알려줍니다.

SubScription 테스트 환경은 다음과 같습니다.

노드에는 총 4개의 Tag가 있습니다.
총 4개의 태그에 subscription을 걸어두었습니다.
총 10개의 서비스를 수행했습니다.

Write + Subscription 테스트 결과 부하를 주지 못하는 것을 확인했습니다.

CPU 점유율을 높이기 위해서는 태그를 1,000 개 단위로 크게 올리는 것이 필요할 것으로 보입니다.

테스트를 수행하면서 작성한 테스트 코드는 아래 주소에 업로드했습니다.

https://github.com/KEUN-KEUN/plc_python_MessageChange/tree/main

GitHub - KEUN-KEUN/plc_python_MessageChange

Contribute to KEUN-KEUN/plc_python_MessageChange development by creating an account on GitHub.

github.com

실습 4에서는 아래 내용을 다루어보겠습니다.

- Pub/Sub에 대한 이벤트별 시나리오 설계

- OPC-UA에 대한 고급 설정

26년, AI '환멸의 골짜기' 맞을 것인가

keun90 — Tue, 20 Jan 2026 22:22:48 +0900

카트너의 기술 사이클 그래프(Hype Cycle)

신기술이 등장하여 시장의 주류로 자리 잡기까지 거치는 일반적인 심리적·성숙 단계를 시각화한 것입니다.

https://www.aitimes.com/news/articleView.html?idxno=158055

가트너 "내년에 생성 AI '환멸의 골짜기' 찾아올 수 있어" - AI타임스

가트너가 현재 생성 인공지능(AI)의 기대감이 절정에 달했으며, '과장광고(hype) 기술의 주기상' 이르면 내년에는 기대감과 관심이 급격하게 떨어질 수도 있다고

www.aitimes.com

카트너에서 26년에 환멸의 골짜기 진입할 것으로 예측할 것으로 발표했습니다.

묻지마 투자 시대 저물고 실질적 수익을 증명하는 기업만 살아남는 시기 (옥석 가리기)
AI 지출 전망은 +44%로 역대 최대 규모지만, 현실적인 문제 드러나며 실패하는 기업들 나타날 것

https://n.news.naver.com/article/092/0002406481?lfrom=twitter

[SW키트] 美 빅테크 실적 발표 임박…AI에 돈 쓴 만큼 벌었나?

밀키트는 손질된 식재료와 양념을 알맞게 담은 간편식입니다. 누구나 밀키트만 있으면 별도 과정 없이 편리하게 맛있는 식사를 할 수 있습니다. [SW키트]도 마찬가지입니다. 누구나 매일 쏟아지

n.news.naver.com

진짜 옥석을 가리는 시기간 온다면, AI로 돈을 버는 기업으로 더욱 돈이 몰릴 것으로 예상됩니다.

포트폴리오를 AI 선두기업 + ETF로 분산한다면, 하락장을 지킬 수 있을 것입니다.

다가올 AI 빅테크 기업의 실적 발표 날짜에 주목해야 합니다.

애플	AAPL	2026년 1월 29일	2025년 4분기 실적	맥데일리뉴스 보도 (2026년 1월 6일)
마이크로소프트	MSFT	2026년 1월 28일	2025년 4분기 실적	마이크로소프트 공식 보도자료 (2026년 1월 7일)
알파벳(구글)	GOOGL	2026년 2월 4일	2025년 4분기 실적	알파벳 IR 보도자료 (2026년 1월 8일)
아마존	AMZN	2026년 2월 5일 (예상)	2025년 4분기 실적	시장 전망치 (Benzinga 기준)
메타	META	2026년 1월 28일	2025년 4분기 실적	메타 IR 보도자료 (2026년 1월 14일)
엔비디아	NVDA	2026년 2월 25일	2025년 4분기 실적	모틀리풀 기사 (2025년 12월 29일)
테슬라	TSLA	2026년 1월 28일	2025년 4분기 실적	테슬라 보도자료 (2026년 1월 2일)
브로드컴	AVGO	2025년 12월 11일	2025년 4분기 실적	브로드컴 보도자료 (2025년 12월 11일)
AMD	AMD	2026년 2월 3일	2025년 4분기 실적	AMD 보도자료 (2026년 1월 6일)
넷플릭스	NFLX	2026년 1월 20일	2025년 4분기 실적	넷플릭스 IR 보도자료 (2025년 12월 15일)

전기료 및 각종 비용 부담 발표(1/14)

트럼프

"빅테크 전력 비용 부담을 국민에게 떠넘기면 안된다."

마이크로소프트

"기업이 모두 부담하겠다."

다른 테크 기업들도 이에 대해 대답할 예정입니다.

이에 따라 전력 관련주들은 더 주목받을 가능성이 커졌습니다.

10년 이상 대규모 투자 필요 발언(1/12)

메타는 데이터센터에 이어 AI인프라에 투자할 것을 발표했습니다.

소셜미디어로 많은 돈을 벌고 있지만, 투자에 대한 수익이 없어 주가를 고점 대비 -20%인 상태입니다.

추가 채무 은폐 손해배상 소송(1/14)

오라클 채권단은 돈 빌리는 것을 은폐하고 계속 돈을 빌린 것으로 나타났습니다.

채권단은 집단 소송을 진행하고 있습니다.

구글, 스마트폰 AI 시장 사실상 평정한 것으로 보입니다. (애플, 삼성..)

https://www.chosun.com/economy/tech_it/2026/01/13/6DN6YIWJJRCCBNCTUBMWZACLI4/

뒤쳐져도 버티던 애플, 결국 ‘AI 경쟁’ 백기?...아이폰에 구글 제미나이 탑재

뒤쳐져도 버티던 애플, 결국 AI 경쟁 백기...아이폰에 구글 제미나이 탑재

www.chosun.com

OPC-UA 실습 2 - PLC 테스트 코드 → OPCUA 서버 → 클라이언트(Uaexpert) 확인

keun90 — Mon, 19 Jan 2026 20:05:00 +0900

테스트 시나리오

OPCUA 서버 : Node 컨피그 작성
PLC 테스트 코드 작성: OPCUA로 1초 주기, 메시지 전송
클라이언트(Uaexcpert) : PLC 메시지 적용 값 확인

다운로드 받은 OPCUA 서버에 node 설정 값을 추가해줍니다.

경로 : UaCPPServer\bin\uanodesetimport.xml
구조 Factory → Line → PLC

<!-- Factory > Line > PLC > Message Structure -->
<UAObject NodeId="ns=1;s=Factory" BrowseName="1:Factory">
    <DisplayName>Factory</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=61</Reference>
        <Reference ReferenceType="Organizes" IsForward="false">i=85</Reference>
        <Reference ReferenceType="Organizes">ns=1;s=Factory.Line</Reference>
    </References>
</UAObject>
<UAObject NodeId="ns=1;s=Factory.Line" BrowseName="1:Line">
    <DisplayName>Line</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=61</Reference>
        <Reference ReferenceType="Organizes" IsForward="false">ns=1;s=Factory</Reference>
        <Reference ReferenceType="Organizes">ns=1;s=Factory.Line.PLC</Reference>
    </References>
</UAObject>
<UAObject NodeId="ns=1;s=Factory.Line.PLC" BrowseName="1:PLC">
    <DisplayName>PLC</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=61</Reference>
        <Reference ReferenceType="Organizes" IsForward="false">ns=1;s=Factory.Line</Reference>
        <Reference ReferenceType="Organizes">ns=1;s=Factory.Line.PLC.Message</Reference>
    </References>
</UAObject>
<UAVariable DataType="String" NodeId="ns=1;s=Factory.Line.PLC.Message" BrowseName="1:Message" AccessLevel="3">
    <DisplayName>Message</DisplayName>
    <References>
        <Reference ReferenceType="HasTypeDefinition">i=63</Reference>
        <Reference ReferenceType="Organizes" IsForward="false">ns=1;s=Factory.Line.PLC</Reference>
    </References>
    <Value>
        <uax:String></uax:String>
    </Value>
</UAVariable>

NodeId를 ns=1;로 설정해도 서버 런타임에서 NamespaceIndex가 재할당되면 변경될 수 있습니다.

저도 ns=1; 설정했지만, " ns=7;s=Factory.Line.PLC.Message " 로 설정된 것을 확인했습니다.

PLC 메시지를 보내기 전, OPCUA 서버에서 ns 값을 조회해 후 사용(+캐싱) 하면 됩니다.

OPCUA 서버를 다시 실행해줍니다.

실행 파일 경로 : UaCPPServer\bin\uaservercpp.exe

실행 후 uanodesetimport 값이 적용되어 어떤 NamespaceIndex 가 할당 되었는지 #결과 값에서 확인이 가능합니다.

import asyncio
from asyncua import Client, ua

async def check_namespaces():
    async with Client("opc.tcp://keun90:48010") as client:
        ns_array = await client.get_node(
            ua.NodeId(ua.ObjectIds.Server_NamespaceArray)
        ).read_value()

        for i, uri in enumerate(ns_array):
            print(i, uri)

if __name__ == "__main__":
    asyncio.run(check_namespaces())
    
    
# 결과 값    
0 http://opcfoundation.org/UA/                                                                                          
1 urn:keun90:UnifiedAutomation:UaServerCpp                                                                                2 urn:UnifiedAutomation:PubSubConfiguration
3 http://www.unifiedautomation.com/DemoServer/                                                                          
4 urn:UnifiedAutomation:CppDemoServer:BuildingAutomation                                                                
5 http://www.unifiedautomation.com/DemoServer/AccessPermission
6 http://www.unifiedautomation.com/DemoServer/StateMachines
7 urn:UnifiedAutomation:CppDemoServer:UANodeSetXmlImport

uanodesetimport 가 정상적으로 적용되었으면, Uaexpert에서도 조회가 가능합니다.

아래와 같이 트리구조가 폴더로 보기 좋게 나타납니다.

OPCUA로 1초 주기, 메시지 전송하는 코드입니다.

uanodesetimport의 ns값 + Node 구조(Factory+Line+PLC)로 통신합니다.

Message의 Value 값을 수정하면, Uaexpert에서 조회가 가능합니다.

import asyncio
import time
from asyncua import Client, ua

OPC_UA_ENDPOINT = "opc.tcp://keun90:48010"

# ✅ 서버에서 실제로 조회된 URI (ns=7에 해당)
TARGET_NAMESPACE_URI = "urn:UnifiedAutomation:CppDemoServer:UANodeSetXmlImport"

# ✅ XML에서 정의한 s=... 부분만 고정
NODE_IDENTIFIER = "Factory.Line.PLC.Message"

WRITE_INTERVAL_SEC = 1


async def resolve_node(client: Client):
    ns_array_node = client.get_node(ua.NodeId(ua.ObjectIds.Server_NamespaceArray))  # i=2255
    namespace_uris = await ns_array_node.read_value()

    ns_index = namespace_uris.index(TARGET_NAMESPACE_URI)  # 여기서 7이 나와야 정상
    node_id_str = f"ns={ns_index};s={NODE_IDENTIFIER}"
    return client.get_node(node_id_str)


async def plc_simulator():
    seq = 0

    while True:
        try:
            async with Client(OPC_UA_ENDPOINT) as client:
                node = await resolve_node(client)

                while True:
                    seq += 1
                    message = f"PLC_MSG_{seq}_{int(time.time())}"

                    dv = ua.DataValue(ua.Variant(message, ua.VariantType.String))
                    await node.write_attribute(ua.AttributeIds.Value, dv)

                    readback = await node.read_value()
                    print("WRITE:", message, "/ READBACK:", readback)

                    await asyncio.sleep(WRITE_INTERVAL_SEC)

        except Exception as e:
            print(f"[ERROR] {type(e).__name__}: {e}")
            await asyncio.sleep(2)


if __name__ == "__main__":
    asyncio.run(plc_simulator())


# plc 테스트 환경 스크립트
# python -m venv .venv
# .\.venv\Scripts\activate
# pip install asyncua
# -- 설치 확인 
# python -c "from asyncua import Client, ua; print('asyncua OK')"

OPCUA로 서버로 메시지 전송시 아래와 같은 에러가 발생할 수 있습니다.

노드 아이이 매칭 오류
packages\asyncua\ua\uatypes.py", line 383, in check raise UaStatusCodeError(self.value) asyncua.ua.uaerrors._auto.BadNodeIdUnknown: The node id refers to a node that does not exist in the server address space.
쓰기 거부 오류
BadWriteNotSupported:
The server does not support writing the combination of value, status and timestamps provided

Uaexpert에서 Value 값이 정상적으로 수정되었는지 확인해봅니다.

아래는 PLC 테스트 코드에서 Value 값을 보낸 로그입니다.

Uaexpert의 Message.Value 값을 새로고침하면 변경되는 것을 확인할 수 있습니다.

다음 단계입니다.

- PLC 테스트 코드를 하나 더 증가

- Message Value 단순 구조가 아닌, 실제 Message 포맷으로 변경

- 메시지 스트레스 테스트, 가능할까..

- Pub/Sub 구조

- OPCUA 고급 설정

영화 인턴 대본

keun90 — Mon, 19 Jan 2026 12:51:02 +0900

But I never seem to do anything right around here.

never seem to + 동사원형

항상 그런 느낌이 아니다.

do anything right

제대로 해내다.

around here

물리적 장소 + 조직 관계 환경

And you're, like, 50 years older than me and you're deaf.

deaf

귀가 먹은, 청각 장애가 있는

I happen to think you do a lot of things right.

happen to + 동사

우연히 ~하다.

개인적인 견해를 조심스럽게 던진다.

think + (that) + S + V

명사절

things

a lot of + 복수 가산명사

thing = 가산명사

a lot of = 수량 표현 -> 복수 필요

I bust my ass for her 14 hours a day, and she never notices.

bust one's ass

죽도록 일하다 / 온 힘을 쏟다

I hate girls who cry at work.

girls

특정 한 명이 아닌, 그런 유형 전체

who cry

현재시제 동사 규칙

s 붙는 경우

주어 = 3인칭 단수

he / she / it

a girl / the girl

who(선행사가 단수일 때)

s 안 붙는 경우

주어 = 복수

they

girls

who(선행사가 복수일 때)

I = 1인칭 단수

How about if you, just as an experiment, try letting me help you.

how about if ~

해보는 건 어때?

, just as an experiment,

그냥 시험 삼아서

삽입구 구조

부사구 삽입

try + V-ing

시험 삼아 해보다

try + to V

노력하다 / 시도하다

A lot of your stress is gonna be lifted once you're out from under this mountain of worry.

A lot of + 불가산명사

A lot of your stress = 단수 취급

be gonna be + p.p

곧 ~ 될 것이다

once 절

once = when / as soon as

미래 의미지만 현재형 사용

out from under ~

억압 부담 통제에서 벗어난

this mountain of worry

은유, 엄청남 걱정 덩어리

And maybe you should consider leaving here at a normal hour once in a while.

should consider + -ing

진지하게 생각해보다 / 고려하다

consider 동명사만 가능

at a normal hour

at + 시간대

once a while

가끔, 이따끔

maybe

압박 제거

I can offer my assistance in this area.

in this area

이 부분

In this part, I would have made the same decision.

I would have made the same decision on this part.

would have made

would have + 과거분사

과거 사실이 아닌 가정, 추측, 평가

과거에 (그 상황이었다면) 그렇게 했을 것이다.

I would love to, actually.

would

공손함 + 톤 조절

I love to 직설적

I would love to 정줌 함

I just don't want her to think that I can't do my job and I need an intern to help me.

I just don't want ~

그냥 ~ 하고 싶지 않다.

want her to think

want + 사람 + to + 생각/행동

can't do my job

내 일을 못한다.

need an intern to help me

인턴의 도움이 필요하다.

think A and B

A이면서 동시에 B라고 생각하다.

Okay, you're not gonna wanna hear this,

you're not gonna wanna ~

you're not going to want to ~

you're

/jər/ 열 ~

but I heard women who sleep less than seven hours a night gain 38% more weight than women who sleep more than seven hours a night.

I heard (that) ~

~ 라고 들었다

gain 38% more weight

gain weight 살이 찌다

I took a look at the data purchase patterns.

take a look

숙어

look 명사로 사

"문장에서 내가 알아야할 모든 내용의 핵심 전문가 수준으로 정리. 단어가 아닌, 사용하기 유용한 구간으로 정리해줘. 문장이 잘 들리지 않는 이유가 원어민 발음이 이유에 대해 알려줘"

SMR, AI 전력난

keun90 — Sun, 18 Jan 2026 18:52:52 +0900

전기 생성 방법은 아래 방법이 있습니다.

대형 원전
천연가스 터빈
해상풍력 및 태양광 등 신재생에너지

하지만, 송전망이 있어야 전기를 가져올 수 있습니다.

생활권에 송전망을 증설하는 것은 어렵습니다.

이러한 문제로 인해 지역별 작은 발전소를 설치해 전기 과부족을 해결하려고 합니다.

[ 발전소 조건 ]

- 소형

- 발전소의 가동률이 자유로워야 한다.

천연가스는 소형 불가능, 가동률 조절 할 수 없습니다.

조건을 충족하는 방법은 SMR로, 가동률(20~100%)이 자유롭습니다.

그래서 지금 유일한 대안은 소형원자로입니다.

소형원자로의 도입이 실패한 경험이 있습니다.

소형원자로는 건설의 개념, 공사 기간이 길어지다 결국 2023년에 무산되었습니다.

(공사 기간 지연, 금액 증가, 자금 지원 주체 없음)

https://www.energytransitionkorea.org/brief/?bmode=view&idx=81067375

[이슈브리핑] 뉴스케일의 SMR 사업, 추가용량 확보 실패로 사업위기 : 에너지전환포럼 자료

사)에너지전환포럼보도자료“사람‧환경‧미래를 위한 에너지전환”2023년 11월 07일 (화요일)즉시 보도가능합니다배포2023년 11월 07일 (화요일)문의석광훈 전문위원 admin@energytransitionkorea.org황수

www.energytransitionkorea.org

태양광과 풍력 모든 신재생에너지도 정부의 도움 없이는 현실화되기 어렵습니다.

마찬가지로 SMR은 정부의 도움이 필요하지만, 미국의 트럼프는 임기내에 성과낼 수 있는 정책에 집중하고 있습니다.

이에따라 SMR이 아닌 천연가스에 초점을 맞추고 정책을 펼쳤습니다.

GE Vernova(천연가스 인프라)주가를 보면 트럼프의 천연가스 우선 정책이 주가에 미친 영향을 확인할 수 습니다.

https://kr.investing.com/equities/ge-vernova-llc

트럼프 정책의 변화가 있습니다.

https://news.kbs.co.kr/news/pc/view/view.do?ncd=8451306

트럼프 행정부, 자체 우라늄 농축 시설 구축에 4조 원 투입

미국이 원자력 발전 등에 사용되는 핵연료인 농축 우라늄을 자체적으로 확보하기 위해 약 4조 원을 투입하...

news.kbs.co.kr

우라늄 농축시설 구축에 보조금이 SMR(고농축 우라늄)으로 넘어올 가능성도 있습니다.

우라늄에 대해 더 알아보겠습니다.

우라늄의 핵심이 되는 공정은 농축입니다.

우라늄 원석에서 우라늄-235 비중은 0.7%-0.8% 밖에 안됩니다.

경수로 3%(농축 정도)
SMR 20%
핵무기 90%

기존에는 농출 기술을 러시아에 의존했으나, 불안한 정세로 인해 변할 것입니다.

우라늄은 구조적으로 안전하다는 전문가 의견이 있습니다.

항목	대형 원전	SMR
냉각	펌프 의존	자연순환
열 밀도	높음	낮음
구조	복잡	단순·일체형
사고 대응	능동	수동

중국은 고온가스로 방식으로 4세대 소형원자로에 관심이 많습니다.

https://asiatimes.com/2025/11/china-uses-nuclear-reactor-technology-to-expand-global-influence/?utm_source=chatgpt.com

China uses nuclear reactor technology to expand global influence - Asia Times

This article was first published by Pacific Forum. It is republished with permission. On October 13 of this year, the state media outlet China Energy News

asiatimes.com

어떤 국가가 SMR 시장을 장악할 수 있을지 고민입니다.

중국은 태양광 시장을 장악한 이력이 있고 미국은 기술력이 있어 누가 패권을 잡을지 아직 모르겠습니다.

SMR 지금은 작은 시장이지만, 에너지 패권·산업 표준·지정학이 결합된 '차세대 전략 무기'이며, 중국은 기술 선점, 미국은 시장 지배를 노리고 있다고 생각합니다.

용어

SMR(Small Modular Reactor)

소형 모듈 원자로

차세대 원자력, 소형·표준화·모듈 조립

GE Vernova

천연가스 기반 전력(가스터빈) + 전력망(HVDC)로 단기 성과를 만드는 에너지 인프라 기업

우라늄-235

핵연료로 쓰이는 우라늄의 방사성 동위 원소

경수로(Light Water Reactor)

가장 검증된 상업용 원전 시술이며, 현재 SMR의 기술적 출발점

그레이 마켓

비공식적인 경로로 거래하는 합법과 불법의 경계가 모호한 시장

2026.01.10 삼성전자, Foundary, NAND Flash, DRAM

keun90 — Sun, 18 Jan 2026 16:27:23 +0900

삼성 파운드리

2025년 기준 적자, 2조 5천억
But, 적자가 점차 줄고 있음
파운드리 적자폭 변경 사항에 따라 주가 변동이 있을 것이라고 판단함

HBM

수요
2025년 대비 수요가 지속 증가하고 있음

경쟁사

SK
      ADR 상장 (+)
         다른 시장에서 거래가 가능하게 설정
              나스닥에서 거래 가능함

마이크론

최대 규모의 반도체 제조시설 창공

2030년 D램 생산

145조 투자

D램 공급 안정성 미국 내에서 확보

미국 내 유일한 반도체 기어으로 미국 지원을 받음

단점

메모리에 편중되어 있음

용어

삼성 파운드리
      고객 설계 → 삼성 생산
      경쟁사
          TSMC, Intel Foundary
      약점
          TSMC 대비 신뢰 격차
      산업 내 위치
          AI/HPC 시대
              고성능, 저전력 공정 수요 증가
주가
      EPS(실적) * PER(기대감)

NAND Flash

전원이 꺼져도 데이터가 유지되는 비휘발성 저장 메모리

사용처

SSD, eMMC, UFS, USB, ..

DRAM

전원이 켜져 있을 때만 동작하는 고속 휘발성 연산 메모리

사용처

PC/서버 메인 메모리

모바일(LPDDR)

LPDDR (Low Power Double Data Rate DRAM)

저전력에 최적화된 DRAM

CPU 기억장치

HBM

High Bandwidth Memory

소속 연산용 데이터 처리

AI 연산에 최적화된 메모리

메모리

DRAM

NANd

GPU

Graphic Processing Unit

연산장치

HPC

High Performance Computing

시스템 전체 개념

CPU + GPU

직장인, 은퇴 분위기

keun90 — Sun, 18 Jan 2026 15:29:22 +0900

직장인 평균 퇴사 49~50세 .. 하지만, 지금은 더 빨라지고 있는 상황입니다.

경기침체가 아님에도 인원 감축을 강행하고 있는 분위기 입니다.

기업에서는 돈을 벌어다 주는 사람이 아닌 인원을 감축하는 분위기가 커지고 있습니다.

정년 보장이 되는 회사는 "노조"가 있는 회사입니다. (오피스 근무는 어렵습니다..)

신입의 경우 경력을 쌓기조차 어려워지는 시장이 되었습니다.

AI의 시대, AI 오퍼레이팅이 매우 중요해지고 있습니다.

AI를 다루는 사람의 기술 격차는 점차 커지고 있어, 경쟁력 차이의 크기 또한 점차 커지고 있습니다.

그렇다면, AI가 일자리를 점차 차지고 있는 비중이 커짐에 따라 미래에 어떤 식으로 우리가 대처해야 할지 고민해봐야 합니다.

https://www.vietnam.vn/ko/elon-musk-va-nhung-du-bao-soc-tien-bac-loi-thoi-robot-cuop-viec-bac-si

일론 머스크의 충격적인 예측: 돈은 쓸모없어지고, 로봇이 의사들의 일자리를 빼앗을 것이다.

(댄 트리 신문) - 세계 최고 부자 억만장자가 향후 20년에 대한 놀라운 전망을 내놓았습니다. 돈은 쓸모없어지고, 로봇이 의사들의 일자리를 "빼앗아" 갈 것이며, 죽음은 단순히 프로그래밍 오류

www.vietnam.vn

경력 관리를 잘 해온 직장인이라면, 은퇴 후 수입의 감소폭이 완만할 것, 안정적인 삶을 길게 유지할 확률이 올라갑니다.

(쉬운 얘기는 아닙니다.)

설비/단말/시스템 간 인터페이스 경험(Socket,API,Message Queue,OPC-UA), 현대차 SDF 관점

keun90 — Sat, 17 Jan 2026 09:35:06 +0900

설비 인터페이스 선택은 기술 문제가 아니라
"공정의 시간축·책임·실패 허용 범위"를 결정하는 설계 문제다.

설비 제어 영역(Press/Body/Paint)

Press

공정 특성

대형 프레스(Transfer/Tandem) 연속 운전

사이클 타임: 수 초 단위

금형 교체(Smart Die Change), 소재 코일 타입

설비 보호가 최우선(오작동 = 수십억 손실)

데이터 특성

스트로크 수, 하중, 속도, 금형 상태

불량은 즉시 차단, 분석은 사후

실시간 제어 데이터 ≠ 생산/품질 데이터

Press는 SDF에서 제어와 데이터 분리가 가장 엄격해야 하는 공정

인터페이스 설계(역할 분리)

Socket / Fieldbus(제어 전용)

연결

프레스 <-> PLC <-> 안전 제어 시스템

데이터

스트로크 인터록

하중 초과, 비상정지

원칙

MES / IT 시스템 접근 절대 금지

제어망 폐쇄(OT Network)

OPC-UA(설비 상태 표준화)

연결

PLC -> OPC-UA Server -> Edge

데이터

Stroke Count

Press Load Curve 요약값

Die Status / Alarm Code

설계 포인트

공정 의미를 가진 값만 노출

설비 상태의 표준 인터페이스

Message Queue(SDF 핵심)

연결

Edge -> MQ -> MES / Quality / Data Platform

예: PRESS_STROKE_COMPLETED..

특징

비동기

재처리 가능

라인 확장 시 구조 변경 없음

Body

로봇 용접 중심

차체 품질의 결정 구간

인터페이스

제어: Socket

상태: OPC-UA

생산·추적: Message Queue

실적·품질: API

Paint

...

Assembly

...

용어 정리

OPC-UA(Open Platform Communication Unified Architecture)

보안이 내장된, 의미 중심의 산업용 데이터 인터페이스 표준

산업 설비·시스템 간 데이터를 표준화된 정보 모델 + 보안 통신으로 교환하는 프로토콜.

이기종 장비(PLC, 로봇, 센서) <-> 상위 시스템(MES, SCADA, ERP) 간 의미 있는 데이터 연결.

아키텍처 핵심 용어

OPC-UA Server

설비/시스템의 데이터를 제공하는 주체.

예: PLC, 로봇 컨트롤러, 설비 게이트웨이

OPC-UA Client

Server에 접속해 데이터를 읽고/구독/제어.

예: MES, SCADA, 데이터 수집 서비스

Endpoint

Client가 접속하는 Server의 접점(URL + 보안 정책)

Session

Client-Server간 논리적 연결 단위(인증·권한 포함)

정보 모델(Information Model)

Node

OPC-UA 데이터의 최소 단위(객체, 변수, 메서드 등)

Nodeld

Node를 식별하는 고유 ID

Object Node

설비, 장비, 공정 같은 실체 개념

Variable Node

실제 값(온도, 속도, 상태 등)

Method Node

설비 제어 명령(Reset, Start 등)

Reference

Node 간 관계(구조·의미 연결)

Address Space

모든 Node와 Reference로 구성된 전체 데이터 맵

OPC-UA는 값(Value) 만이 아니라 의미(Structure)를 함께 전달.

통신 방식

Read/Write

Subscription

변경 시점에 이벤트 기반으로 데이터 수신

Monitored Item

Subscription에 포함된 감시 대상 변수.

Sampling Interval

Server가 값을 확인하는 주기

Publishing Interval

Client로 전송하는 주기

보안

Security Policy

암호화 알고리즘 규칙 집합

Message Security Mode

None / Sign / SignAndEncrypt

Certificate(X.509)

Client·Server 상호 인증 수단

User Authentication

Anonymous / Username / Certificate

OPC-UA는 설계 단계부터 보안이 내장됨.

데이터 타입 & 품질

DataType

Boolean, Int, Float, String, Structure 등

Value + StatusCode + Timestamp

OPC-UA 데이터의 3요소

StatusCode: 갑의 신뢰도

Timestamp: 측정 시점

확장 개념

Companion Specification

산업별 표준 정보 모델 (로봇, 자동차, 반도체 등)

OPC-UA PubSub

Client-Server 구조 없이 메시지 브로커/멀티캐스트 기반 통신

Edge Gateway

PLC <-> IT 시스템 사이 중계·변환 역할

OPC-UA와 개념(MES)

keun90 — Sat, 17 Jan 2026 09:28:07 +0900

OPC(OLE for Process Control)

표준화된 통신 프로토콜

(구) OPCDA, OPC Classic

OPC-DA

윈도우 환경에서만 구동

DCOM 통신, 포트 지정

DCOM(Distributed Component Object Model)

Window 전용 분산 객체 통신 기술

OPC-DA가 네트워크, 방화벽, 보안 문제를 자주 일으키는 근본 원인

외부에서 접속가능한 설정이 까다로움

(신) OPCUA(Open Platform Communications Unified Architecture)

OPC 목적

PLC는 각각의 프로토콜로 통신을 합니다. 결국 PLC의 데이터를 상위 시스템으로 인터페이스를

하기 위해서는 PLC 별로 통신 드라이브를 구축해야 합니다.

OPC-UA는 PLC 통신의 중계 역할을 하게 됩니다.

OPC-UA 특징

플랫폼 독립성

Window, Linux, Android, iOS 다양한 운영체제에서 사용

센서, 클라우드까지 적용 가능한 서비스 지향 아키텍처

단일 통합 프레임워크

DA, HDA, A&E 등 여러 규격을 하나의 정보 모델로 통합

클라이언트는 단일한 서비스 집합으로 다양한 데이터 접근

DA: OPC Classic

HDA: 이력 데이터

A&E: 알람/이벤트

다양한 통신 바인딩

바이너리 프로토콜(바이너리 TCP) 표준

낮은 오버헤드로 빠른 통신 제공

HTTP/HTTPS 웹 서비스 방식

방화벽과 프록시 환경에서 쉽게 사용 가능

단일 포트 통신

하나의 TCP 포트만 사용

방화벽 설정 유리

정보 모델링 및 확장성

표준화된 정보 모델(객체 모델)을 통해 복잡한 데이터 구조를 표현

새로운 기능으 ㄹ추가해도 기존 응용 프로그램에 영향을 주지 않음

산업 자동화 및 IIoT 연계

센서에서 클라우드까지 데이터 교환 지원

Pub/Sub 통신을 포함한 다양한 통신 패턴 제공

IIoT(Industrial Internet of Things)

확장성

소규모부터 대규모 환경에 적용 가능함

클라우드 가능

보안성

웹 서비스 보안 표준을 사용하여 메시지를 보호하며, 데이터 전송 시 높은 수준의 보안 제공

X.509 인증서 기반의 보안 도입

클라이언트-서버 간 통신 암호화하고 서명함으로써 데이터 위변조나 무단 접근 방지함

상호 운영성

다양한 벤더의 장비와 시스템 간의 원활한 통신을 가능하게 함

OPC-DA vs OPC-UA 통신 구조

OPC-UA (Application + Session 통합 계층)

데이터 모델

세션 관리

보안(인증서, 암호화)

서비스 호출(Read/Write/Subscribe)

COM / RPC 없음

OS 독립

OPC API

MES/SCADA가 사용하는 OPC 인터페이스

Read / Write / Subscribe 제공

Application Layer (COM / DCOM)

분산 객체 호출

OPC Server의 객체를 원격에서 호출

Session Layer(RPC)

원격 프로시저 호출 관리

세션 상태 유지

Transport Layer(TCP/UDP)

실제 데이터 전송

Network Layer(IP)

주소 지정, 라우팅

Data Link Layer(Ethernet Framing)

프레임 전달

Physical Layer(Ethernet)

물리적 신호 전송

MES와 OPC-UA

OPC-UA서버는 기기의 하드웨어 통신 프로토콜을 표준 OPC 인터페이스로 변환하고, 주소 공간 (Address Space)이라는 구조화된 데이터 모델을 외부에 제공한다.

MES 클라이언트는 이 주소공간의 태크(Tag)들을 탐색(browse)하여 필요한 데이터를 구독하거나

읽어올 수 있다. 데이터가 객체 단위로 있어, 각각의 데이터가 무엇을 의미하는지 쉽게 파악할 수 있다는 장점이 있다.

이해하기 좋은 사이트

https://blog.naver.com/suresofttech/221394318179?trackingCode=blog_bloghome_searchlist

OPC-UA 소개 주소

https://maplesystems.com/industrial-internet-of-things-iiot/opcua/?srsltid=AfmBOorcm9__5PNfwN2sUe5klnKDLY4Ut6h7JICzJwsMeNDG1GAiOoAB#:~:text=OPC%20UA%20is%20supported%20by,and%20how%20to%20use%20it

OPC-UA 소개 유투브 !!!

https://www.youtube.com/watch?v=D3JnN1GBnGc

OPC-UA 실습 1 - 서버, 클라이언트 연동

keun90 — Fri, 16 Jan 2026 19:31:32 +0900

OPC-UA 실습을 위한 Server, Client를 다운받는다.

(계정이 막혔는지,, 로그인 실패 알림이 계속해서 발생한다.)

계정 메일 주소는 gmail을 활용하는 것을 추천한다.

ttps://documentation.unified-automation.com/uaexpert/1.4.2/html/index.html

설치 후 uaexpert.exe 실행하면 다음과 같은 UI를 확인할 수 있다.

난이도가 중 이상의 항목에 대해 다시 정리했다.

구분	항목	중요도	중요한 이유 (핵심만)
SUBJECT	Common Name (CN)	중	서버·로그·인증서 목록에서 운영자가 클라이언트를 구분하기 위한 식별자
SUBJECT	Country (C)	중	일부 서버/보안 정책에서 X.509 형식 검증을 통과하기 위해 필요
OPC UA INFO	Application URI	최상	서버가 클라이언트를 식별하고 신뢰 여부를 판단하는 기준 값
	Domain Names	중	서버가 인증서와 실제 실행 호스트의 일치 여부를 검증할 때 사용
	IP Addresses	중	IP 기반 검증 환경에서 실행 주체 확인에 사용
CERT SETTING	RSA Key Strength	중	보안 정책 충족 + 암호화 성능 균형을 위한 기준
	Signature Algorithm	중	서버가 허용하는 암호 알고리즘 조건 충족 여부
	Certificate Validity	중	만료 시 즉시 통신 불가
	Private Key Password	중	개인키 유출 시 클라이언트 위·변조 방지

정상적으로 Client 가 작동했다면, 이제 Server를 다운받아 구동시켜 보자.

다운로드 후 uaservercpp.exe를 실행하면 cmd 창이 나타난다.

(Java, Python 여러 가지 버전을 찾아 구동시켜볼 수 있다. Java를 다운받은 후 코드를 보았지만, 내용을 이해하기는 쉽지 않다.)

Client에서 방금 구동한 Server를 추가해보자.

[Add Server] → [Double click to Add Server] → Server URLs 입력

연결 가능한 목록이 아래와 같이 None- / Basic- / Aes- 등 목록이 나타난다.

None- 을 클릭하면 증명 알림이 발생한다.

첫 연결 시, 신뢰할 것인지 묻는 의미이다.

커낵션이 성공하면 Serves 하위에 나타난다.

Claude 기본 활용 방법 2 - 서브에이전트(SubAgent)

keun90 — Thu, 15 Jan 2026 22:02:58 +0900

서브에이전트(SubAgent) 개념

markdown 파일을 활용해 서브에이전트를 생성해 AI작업 수행한다.
아래 경로 (.claude\agents 폴더 하위) 생성

명령어는 아래와 같이 CLI에 입력하면 된다.

@agent-docs-architect 를 사용해 현재 코드베이스에 대한 문서화를 하고, READE.md 파일에 저장해줘

.md 파일에 포함할 권장 사항

체크리스트

필수 요구 사항

접근 방식

테스트 방버

사용할 MCP

DO, DO NOT (*보안)

검증된 서브에이전트 활용 방안

   • https://github.com/contains-studio/agents
   • https://github.com/wshobson/agents
   • https://github.com/VoltAgent/awesomeclaude-code-subagents
   • https://github.com/0xfurai/claude-codesubagents
   • https://github.com/iannuttall/claude-agents

서브에이전트(SubAgent) 장점

병렬처리로 토큰/컨택스트 사용량 효율이 향상 된다.
20만 토큰, 에이전트 마다 할당한다
결과를 메인 에이전트가 받는다
/context 명령어로 토큰 사용량 확인 가능하다

subagents를 활용하면 Free Space의 사용량이 많이 증가하지 않는다.

Claude 기본 활용 방법 1

keun90 — Thu, 15 Jan 2026 19:50:24 +0900

슬래시 명령어

예제 경로

git clone https://github.com/stepanowon/test-svc

/init

프로젝트(현재의 디렉토리()의 구조를 자동으로 분석해서 CLAUDE.mcd 파일 생성

CLAUDE.md

AI 모델이 이 프로젝트를 이해하기 위한 핵심 컨텍스트

매번 챗 시작할 때 자동으로 읽어서 프로젝트의 맥락을 기억함

수준별 유형

프로젝트 수준의 메모리

/init에 의해 생성

git 과 같은 도구를 이용해 소스 제어되는 메모리

다른 개발자와 공유

CLAUDE.local.md

다른 개발자들과 공유되지 않음

.gitignore에 포함시켜 소스제어 되지 않음

개발자 개인 메모리

~/.claude/CLAUDE.md

사용자 수준의 메모리

로컬 머신의 모든 프로젝트에 적용되는 전역 규칙

지침별 우선순위

System Prompt > 프로젝트 수준의 ./CLAUDE.md > 사용자 수준의 ~/.claude/CLAUDE.md

/status

claude code의 상태 확인

/model

현재 사용중인 모델 확인, 모델 변경

Default | Opus

* 일상 코딩은 Sonnet 사용 권장 !!!

* 설계 Opus

/clear

대화 기록 삭제함

삭제된 기록은 컨텍스트에 포함되지 않음

/doctor

설치 상태 확인

/compact [args]

args 지침을 반영해 대화 내용 압축 → 토큰 사용량 줄여줌

(75%이상 넘어가면 자동으로 실행)

Chat 창이 길어지면 토근 사용량이 증가함

/permissions

권한 모드

default

표준동작, 도구가 첫번째 사용될 때 권한을 요청함

acceptEdits

현재 세션에 대해 파일 편집 권한을 자동으로 요청함

plan

Claude가 분석만 수행하고 파일을 수정하거나 명령을 실행하지 않음

bypassPermissions

모든 권한 프롬프트를 패스함

권한

Allow

Ask

Deny

Workspace

도구

Bash,, MCP..

Claude 개발 환경 구축 가이드 (Windows 기준)

keun90 — Wed, 14 Jan 2026 22:52:50 +0900

1. Node.js 환경 (nvm)

목적

Claude Code는 Node.js 기반
Node 버전 충돌 방지를 위해 nvm 사용

설치

다운로드
https://github.com/coreybutler/nvm-windows/releases
→ nvm-setup.exe

기본 명령어

nvm list
nvm install 22
nvm use 22

2. Python 환경

목적

일부 MCP(Model Context Protocol) 도구는 Python 기반
Claude Code 확장 활용을 위해 필요

설치

다운로드
https://www.python.org/downloads/

권장 버전

Python 3.13 이상

확인

python --version

3. Claude Code

목적

AI 기반 코드 작성·리팩토링·분석 도구

조건

Claude Pro Plan 이상 구독 필요

설치

공식 페이지
https://claude.com/ko-kr/product/claude-code

npm install -g @anthropic-ai/claude-code

4. IDE (개발 도구)

▸ Cursor

AI 코딩에 최적화된 IDE
실무에서 많이 사용
단점: 가격이 비쌈, 사용 모델 제한

▸ Visual Studio Code

범용 IDE
확장성·안정성 우수
대부분의 개발 환경과 호환

5. 계정 및 플랫폼

▸ GitHub

Git Remote Repository
소스 관리 및 협업 필수
계정 생성 필수

▸ Supabase

https://supabase.com/dashboard/sign-up

특징

대표적인 BaaS (Backend-as-a-Service)
DB, Auth, Storage, API 제공
소규모 프로젝트 / 테스트 단계에 적합

▸ Vercel

https://vercel.com/signup

특징

프론트엔드 중심의 빠른 배포 플랫폼
Serverless Function 기반 백엔드 지원
GitHub / GitLab 연동 가능

Serverless Function 개념

요청 시에만 실행되는 백엔드 코드
서버를 직접 관리하지 않음
서버가 “없는 것”이 아니라 운영을 신경 쓰지 않는 구조
지원 언어: Node.js, Python

6. Git 환경

Git SCM

Git 자체 설치 도구
로컬 ↔ 원격 저장소 연동 필수

Git CLI

git 명령어 사용을 위한 CLI
체크포인트(이력) 관리의 핵심

정리 요약

nvm + Node 22 : Claude Code 필수
Python 3.13+ : MCP 및 확장 대응
Claude Code : AI 코딩 핵심 도구
IDE + GitHub + Supabase + Vercel : 실전 풀스택 최소 구성

OPC-UA Node / Address Space

keun90 — Wed, 14 Jan 2026 18:41:56 +0900

Address Space 란

OPC UA 서버는 내부에 Address Space라는 구조를 가진다.

서버가 외부에 공개하는 모든 데이터, 기능, 상태의 전체 지도다.

Address Space 내부

Object : 설비나 라인을 표현

값이 없다.

의미의 표준이 없다.

Variable: 온도·속도·상태

값 하나

실시간 값 or 설정값 or 단순 카운터 ..

Method : 제어 동작

표준에 있다

현장에서는 구현 난이도가 높아 실사용은 안한다

Event : 알람·이벤트

Reference: 이 모든 것을 묶는 관계

중요 포인트

OPC UA 표준은 "이런 구조를 만들 수 있다" 까지만 정의한다.

"이 구조가 무엇을 의미하는지"는 전혀 정의하지 않는다.

Address Space 그래프이다.

트리 구조로서 관계의 완성이 되어야 한다.

# UAExpert 클라이언트, 마치 폴더 구조로 보인다.
Objects
 └─ Line1
     └─ Motor1
         ├─ Speed
         └─ Status

Node 란

OPC UA 의 모든 구성 요소는 노드(Node)로 표현된다.

하지만 노드는 본질적으로 다음 세 가지만 가진다.

1. NodeId - 서버 내부 식별자

2. Attribute - 값, 타입, 접근권한

3. Reference - 다른 노드와의 연결

노드는

"이게 선서다."

"이건 모터다."

"이 값은 생산량이다."

의미를 스스로 알지 못한다.

NodeId 특징

서버 내부에서 유일하기만 하면 된다.

의미를 가질 필요가 없다.

NodeId 예시 

ns=2;i=1034
ns=2;i=1035

의미를 알기 위해서는 아래 내용을 종합적으로 추론해야 한다.

BrowseName

DisplayName

구조

Reference

OPC UA를 쓰면 자동으로 의미가 생기는 게 아니라,

의미가 없는 구조를 의미 있다고 착각하지 않기 위해 노드와 Address Space를 이해해야 한다.

동시성 제어 없는 낙관적 프로그래밍

keun90 — Sat, 3 May 2025 11:03:59 +0900

TX1의 조회 시점(t1)의 가격이 변경(t2)된다면 동시성 제어를 해주어야 한다.

insert into 주문
select :상품코드, :고객ID, :주문일시, :상점번호,...
from 상품
where 상품코드 = :상품코드
and 가격 = :가격;

if sql%rowcount = 0 then
alert('상품가격이 변경되었습니다.');
end if;

Lock

keun90 — Wed, 16 Apr 2025 23:05:55 +0900

오라클 Lock

DML Lock - 다중 트랜잭션이 동시에 액세스하는 사용자 데이터의 무결성을 보호해 준다. 테이블 Lock과 로우 Lock이 있다.
DLL Lock -
래치 - SGA에 공유된 각종 자료구조를 보호하기 위해 사용한다.
버퍼 Lock - 버퍼 블록에 대한 액세스를 직렬화하기 위해 사용한다.
라이브러리 캐시 Lock/Pin - 라이브러리 캐시에 공유된 SQL 커서와 PL/SQL 프로그램을 보호하기 위해 사용한다.

DML 로우 Lock

두 개의 동시 트랜잭션이 같은 로우를 변경하는 것을 방지한다.

update, delete와는 다르게 insert에 대한 로우 lock 경합은 unique 인덱스가 있을 때만 발생한다. 블로킹이 발생하면, 후행 트랜잭션은 기다렸다가 선행 트랜잭션이 커밋하면 insert에 실패하고, 롤백하면 성공한다.

DML 테이블 Lock

오라클은 dml 로우 lock을 설정하기에 앞서 테이블 lock(TM Lock)을 먼저 설정한다. TM Lock이 걸려있다고, 모든 작업을 수행하지 못하는 것이 아니다. RS, RX 등 레벨을 설정하여 작업이 가능하여 다음 트랜잭션의 제어할 수 있다.

select * from t for update -> lock 해제될 때까지 기다린다.

select * from t for update wait 3 -> 일정 시간만 기다리다 포기한다.

select * from t for update nowait -> 기다리지 않고 작업을 포기한다.

Lock을 푸는 열쇠, 커밋

블로킹(blocking) - 선행 트랜잭션이 설정한 Lock 때문에 후행 트랜잭션이 작업을 진행하지 못하고 멈춰 있는 상태를 말한다. 커밋과 롤백으로 풀어주어야 한다.
교착상해(deadlock) - 두 트랜잭션이 각각 특정 리소스에 lock을 설정한 상태에서 맞은편 트랜잭션이 lock을 설정한 리소스에 또 lock을 설정하려고 진행하는 상황을 말한다. 둘 중 하나가 죽어야 해소된다.

ora-00060 : deadlock detected while waiting for resource

오라클 10gR2부터 제공하는 비동기식 커밋과 배치 커밋을 활용하는 방법은 아래와 같다.

wait : lgwr가 로그버퍼를 파일에 기록했다는 완료 메시지를 받을 때까지 기다린다.(동기식 커밋)

nowait : lgwr의 완료 메시지를 기다리지 않고 바로 다음 트랜잭션을 진행한다.(비동기식 커밋)

immediate : 커밋 명령을 받을 때마다 lgwr가 로그 버퍼를 파일에 기록한다.

batch : 세션 내부에 트랜잭션 데이터를 일정량 버퍼링했다가 일괄 처리한다.

파티션을 활용한 대량 INSERT 튜닝

keun90 — Tue, 15 Apr 2025 00:10:16 +0900

비파티션 테이블

대량 데이터를 INSERT 하려면, 인덱스를 Unusable 시켰다가 재생성하는 방식이 더 빠를 수 있다.

1. nologging 모드 변환

alter table t1 nologging;

2. 인덱스 unusable 상태 변경

alter index t1_x01 unusable;

3. (할 수 있다면 direct path insert) 방식으로 대량 데이터를 입력한다.

insert /*+ append */ into t1
select * from s1;

4. (할 수 있다면 nologging 모드로) 인덱스를 재생성한다.

alter index t1_x01 rebuild nologging;

5. logging 모드로 전환한다.

alter table t1 logging;
alter index t1_x01 logging;

파티션 테이블

초대용량 인덱스를 재성성하는 부담이 만만치 않기 때문에 시간이 더 올래 걸리더라도 실무에서 웬만하면 인덱스를 그대로 둔 상태로 작업한다. 하지만, 파티셔닝이 되어 있고, 인덱스토 로컬 파티션이라면, 파티션 단위로 인덱스를 재생성할 수 있다.

1. (할 수 있다면) 작업 대상 테이블 파티션을 nologging 모드로 전환한다.

alter table t1 modify partition p_202504 nologging;

2. 작업 대상 테이블 파티션과 매칭되는 인덱스 파티션을 unusable 상태로 전환한다.

alter index t1_x01 modify partition p_202504 unusable;

3. (할 수 있다면 direct path insert 방식으로) 대량 데이터를 입력한다.

insert /* append */ into t1
select * from s1 where dt between '202501' and '20251231'

4. (할 수 있다면 nologging 모드로) 인덱스 파티션을 재생성한다.

alter index t1_x01 rebuild partition p_202504 nologgin;

5. logging 모드로 전환한다.

alter table t1 modify partition p202504 logging;
alter index t1_x01 modify partition p202504 logging;

파티션을 활용한 대량 DELETE 튜닝

keun90 — Mon, 14 Apr 2025 23:50:48 +0900

일반 delete 문이 느린 이유는 하나씩 삭제하면서 많은 로그를 남기기 때문이다.

delete from 거래;

1. 테이블 레코드 삭제

2. 테이블 레코드 삭제에 대한 undo logging

3. 테이블 레코드 삭제에 대한 redo logging

4. 인덱스 레코드 삭제

5. 인덱스 레코드 삭제에 대한 undo logging

6. 인덱스 레코드 삭제에 대한 redo logging

7. undo (2,5번)에 대한 redo logging

Partition Drop

alter table custom drop partition p202503;

alter table custom drop partition for ('20250301') --> 11g이상. 값을 이용해 대상 파티션 지정이 가능함.

파티션 Truncate를 이용한 대량 데이터 삭제

대량 데이터를 지울 때 남길 데이터만 백업했다가 재입력하는 방식이 빠르다. 아래와 같은 순서로 처리하면 된다.

1. 임시 테이블 생성하고 남길 데이터만 복제한다.

create table 거래_t
as 
select * 
from custom
where 거래일자 < '20250301'
and 상태코드 = 'zzz'

2. 삭제 대상 테이블 파티션을 truncate 한다.

alter table 거래 truncate partition p20250301;

insert into 거래 
select * from 거래_t;

drop table 거래_t;

2025.04.12

keun90 — Sun, 13 Apr 2025 08:11:05 +0900

증시 현황 : 시원한 반등 그러나 해결되지 않은 문제

투자 성향 : 반도체 + 나스닥 + 테슬라 + SCHD

이슈 러쉬 : 4월 9일, SCHD, 관세전쟁

글로벌 증시 현황

1. ARM, 데이터센터,

2. TSMC, 1분기 매출 37조

3. BABA -7%

주식이 오르고, 채권은 하락

미국 증시 현황

1. 엔비디아,+17%,

2. 애플, 5%, 중국에 생산공장 많아 관세 영향 큼

3. 아마존, +8%, AI 계속 투자, 반도체 직접 생산?

4. 헬스케어 관련 주, 대부분 하락

고점대비 하락률

1. 엔비디아 10% 남음

기술주가 반등이 컸음

섹터별 수익률

정보기술

임의소비재 - 아마존, 테슬라, 홈디포, 맥도날드 ... *테슬라 6월 자율주행

통신서비스

항공주가 많이 올랐음

유나이트등 - 급등, 급락 * 관심

s&p500 200일 이동평균선 비율

*** 전체 흐름을 보는구만

마소가 최고점 대비 가장 많이 근접했음,

ETF 색터별 고점대비 얼마나 남았는지.

- 문제점 분석 가능

SCHD 괜찮을까 ?

- 에너지와 헬스케어가 많이 포함되어 있음

- 배당률 4.16% (매우 높음, 위험은 큼)

- 물가상승률보다 높게 성장하고 있음

- 월 100만원 투자, 30년 - 14억, 원금 3억

테슬라

- 4/22, 실적 발표

파티션, 대량 UPDATE 튜닝

keun90 — Mon, 7 Apr 2025 23:47:39 +0900

입력/수정/삭제하는 데이터 비중이 5%를 넘는다면, 인덱스를 그대로 둔 상태에서 작업하기보다 인덱스 없이 작업한 후에 재생성하는 게 더 빠르다.

파티션 exchange를 이용한 대량 데이터 변경

1. 임시 테이블 생성한다.

create table 거래_t

nologging

select * from 거래 where 1=2;

2. 거래 데이터를 읽어 임시 테이블에 입력하면서 상태코드 값을 수정한다.

insert /*+ append */ into 거래_t

select 고객번호, 거래일자, 거래순번, ...

, (case when 상태코드 <> 'ZZZ' then 'ZZZ' else 상태코드 end) 상태코드

from 거래

where 거래일자 < '20150101';

3. 임시 테이블에 원본 테이블과 같은 구조로 인덱스를 생성한다. 할 수 있다면 nologging 모드로 생성한다.

create unique index 거래_t_pk on 거래_t (고객번호, 거래일자, 거래순번) nologging;

4. 파티션과 임시 테이블을 exchange 한다.

alter table 거래

exchange partition p201412 with table 거래_t

including indexes without validation;

5. 임시 테이블을 drop한다.

drop table 거래_t;

6. 파티션을 logging 모드로 전환한다.

alter table 거래 modify partition p201412 logging;

...

튜닝 - exists, NL semi join

keun90 — Mon, 7 Apr 2025 13:13:12 +0900

[데이터]

상품 : 1,000건

계약 : 5,000만 건

- 1년 간 계약 건수는 500만 건

계약 row가 만 건으로 10년 치 데이터가 쌓여 있음을 알 수 있다.

- 상품유형코드를 '=' 조건으로 검색할 때의 평균 카디널리티는 100

Cardinality 란 중복도가 낮으면 높고, 중복도가 높으면 낮다. (여자, 남자 Car-di- 는 2이다.)

즉, 100이란 숫자는 상품유형코드에 대한 중복도가 매우 낮음을 의미한다.

카디널리티로 선택도(Selectivity)를 구할 수 있다.

(Selectivity : 전체 레코드 중에서 조건절에 의해 선택될 것으로 예상되는 레코드의 비율% 이다.)

선택도 = 카디널리디 / 총 레코드 수, 100/1000 = 10%

500만 건의 10%, 50만 건 중 100(카디널리티)개의 상품 집합을 쿼리에서 가져오려고 한다.

[인덱스 구성]

상품_PK : 상품번호

상품_X1 : 상품유형코드

계약_PK : 계약번호

계약_X1 : 계약일

계약_X2 : 상품번호

select distinct p.상품번호, p.상품명, p.상품가격, p.상품분류코드

from 상품 p, 계약 c

where p.상품유형코드 = :pclscd

and c.상품번호 = p.상품번호

and c.계약일자 >= trunc(add_months(susdate, -12))

[실행계획]

상품_X1 > 상품 테이블 엑세스 > 계약_X2 > NL > 계약 테이블 엑세스 > NL > 필터 > Hash

실행 계획대로 수행되도록 인덱스 재구성과 힌트를 작성해야 한다.

/*ordered nl(c) */

인덱스 재구성 :

상품_X1 : 상품유형코드 + 계약일자

<유형1>

select p.상품번호, p.상품명, p.상품가격, p.상품분류코드
from 상품 p
where p.상품유형코드 = :pclscd
and exists (
select /* unnest nl_sj */ 'X'
from 계약 c
where c.상품번호 = p.상품번호
and c.계약일자 >= trunc(add_months(susdate, -12))
);

</유형1>

<유형2>

select p.상품번호, p.상품명, p.상품가격, p.상품분류코드
from 상품 p
where p.상품유형코드 = :pclscd
and exists (
select /* no_unnest */ 'X'
from 계약 c
where c.상품번호 = p.상품번호
and c.계약일자 >= trunc(add_months(susdate, -12))
);

</유형2>

개념

exists를 사용하면 실행 계획 상에서 nested loops semi join(nl semi join)이라는 조인 방식이 자주 사용된다. 존재 여부만 확인(매칭 여부만 필요할 때)하여 첫 매칭 후 중단한다. 빠른 필터링, 적은 메모리 사용이 특징이다.
unnest ? 메인 쿼리와 조인 방식으로 병합(unnest)하도록 강제한다. 기본적으로 필터 방식일 수도 있는 서브쿼리를 조인으로 변환하여 성능 향상을 유도 한다.
no_unnest ? 해당 서브쿼리를 unnest하지 않고 필터 방식으로 유지하라는 의미이다.

파티션을 활용한 DML 튜닝

keun90 — Thu, 3 Apr 2025 23:31:22 +0900

Range 파티션

create table 주문 ( 주문번호 number, 주문일자 varchar2(8), 고객 ID varchar2(5)...)

partition by range(주문일자) (

partition P2025_Q1 values less than ('20250401')

, partition P2025_Q2 values less than ('20250701')

...

, partition P9999_MX values less than (MAXVALUE)

);

해시 파티션

파티션 키 값을 해시 함수에 입력해서 반환받은 값이 같은 데이터를 같은 세그먼트에 저장하는 방식이다.

해시 파티션은 고객 ID처럼 변별력이 좋고 데이터 분포가 고른 컬럼을 파티션 기준으로 선정해야 효과적이다.

create table 고객 ( 고객 ID varchar2(5), 고객명 varchar2(10) ... )

partition by hash (고객 ID) partitions 4;

리스트 파티션

사용자가 정의한 그룹핑 기준에 따라 데이터를 분할 저장하는 방식이다.

create table 인터넷매물 (물건코드 varchar2(5), 지역분류 varchar2(4) ... )

partition by list(지역분류) (

partition P_지역1 values('서울')

, partition P_지역2 values('경기', '인천')

...

, partition P_기타 values(DEFAULT)

);

Range Partition	값의 순서에 따라 저장할 파티션이 결정된다.
Hash	오라클이 정한 해시 알고리즘에 따라 임의로 분할한다.
List	순서와 상관없이 불연속적인 값의 목록에 의해 결정된다. 사용자가 정의한 논리적인 그룹에 따라 분할한다.

인덱스 파티션

non-partitioned table
partitioned table
local partitioned index : 테이블 파티션과 인덱스 파티션이 서로 1:1 대응 관계가 되도록 오라클이 자동으로 관리하는 파티션 인덱스를 말한다.
global partitioned index : 로컬이 아닌 파티션 인덱스가 모두 글로벌이며, 테이블 파티션과 독립적인 구성을 갖는다.
non-partitioned index

로컬 파티션 인덱스

create index 주문_x01 on 주문 (주문일자, 주문금액) local;

각 인덱스 파티션은 테이블 파티션 속성을 그대로 상속받는다. 테이블 구성을 변경 하더라도 인덱스를 재생성할 필요가 없다. 변경작업이 순식간에 끝나므로 피크 시간대만 피하면 서비스를 중단하지 않고도 작업할 수 있는 편리함이 있다.

로컬 파티션 인덱스

파티션을 테이블과 다르게 구성한 인덱스다. 테이블 파티션 구성을 변경하는 순간 unusable 상태로 바뀌므로 곧바로 인덱스를 재생성해 줘야 한다. 그동안 테이블을 사용하는 서비스를 중단해야 한다.

create index 주문_x03 on 주문 (주문금액, 주문일자) global

partition by range(주문금액) (

partition P_01 values less than ( 10000)

, partition P_MX values less than (MAXVALUE)

);

비파티션 인덱스, non-partitioned

파티셔닝하지 않은 인덱스다. 글로벌 비파티션 인덱스라고 부르기도 한다. 테이블 파티션 구성을 변경하는 순간 ... 서비스를 중단해야 한다.

create index 주문_x04 on 주문 ( 고객 ID, 배송일자 );

Prefixed vs Nonprefixed

인덱스 파티션 키 컬럼이 인덱스 구성상 왼쪽 선두 컬럼에 위치하는지에 따른 구분이다.

prefixed : 인덱스 파티션 키 컬럼이 인덱스 키 컬럼 왼쪽 선두에 위치한다.

nonprefixed : 인덱스 파티션 키 컬럼이 인덱스 키 컬럼 왼쪽 선두에 위치하지 않는다. 파티션 키가 인덱스 컬럼에 아예 속하지 않을 때도 여기에 속한다.

Direct Path I/O

keun90 — Sat, 29 Mar 2025 08:13:48 +0900

정보계 시스템(DW/OLAP등)이 배치 프로그램에서 사용하는 SQL은 주로 대량 데이터를 처리하기 때문에 버퍼캐시를 경유하는 I/O 메커니즘이 오히려 성능을 떨어뜨릴 수 있다. 그래서 오라클은 버퍼캐시를 경유하지 않고 곧바로 데이터 블록을 읽고 쓸 수 있는 Direct Path I/O 기능을 제공한다.

1. 병령 쿼리로 Full Scan을 수행할 때

2. 병렬 DML을 수행할 때

3. Direct Path Insert를 수행할 때

4. Temp 세그먼트 블록들을 읽고 쓸 때

5. direct 옵션을 지정하고 export를 수행할 때

6. nocahe 옵션을 지정한 LOB 컬럼을 읽을 때

select /*+ full(t) parallel(t 4) */ * from big_table t;

Direct Path Insert

방식

1. insert .. select 문에 append 힌트 사용

2. parallel 힌트를 이용해 병렬 모드로 insert

3. direct 옵션을 지정하고 sql loader(sqlldr)로 데이터 적재

4. ctas(create table ... as select) 문 수행

빠른 이유

1. freelist 참조하지 않고 hmv(high-water-mark) 바깥 영역에 데이터를 순차적으로 입력한다.

2. 블록을 버퍼캐시에서 탐색하지 않는다.

3. 버퍼캐시에 적재하지 않고, 데이터파일에 직접 기록하낟.

4. undo 로깅을 안 한다.

5. redo 로깅을 안 하게 할 수 있다.

- alter table t nologging; (o)

- insert into t nologging select * from test; (x)

- insert /*+ append nologging */ into t select * from test; (x)

주의할 점 두 가지

1. exclusive 모드 tm lock이 걸린다.

2. freelist 조회하지 않고 hwm 바깥 영역에 입력하므로 테이블에 여유 공간이 있어도 재활용하지 않는다. 테이블 사이즈 증가한다.

병렬 DML

insert는 append 힌트 이용, update/delete는 기본적으로 direct path write 불가능하다. 아래와 같이 병렬 dml을 활성화해야 한다.

alter session enable parallel dml;

insert /*+ parallel(c 4) */ into 고객 c

( insert /*+ append parallel(c 4) */ into 고객 c )

select /*+ full(o) parallel(o 4) */ * from 외부가입고객 o;

update /*+ full(c) parallel(c 4) */ 고객 c

set 고객상태코드 = 'WD'

where 최종거래일시 < '20100101';

delete /*+ full(c) parallel(c 4) */ from 고객 c

where 탈퇴일시 < '20100101';

QC(query coordinator) : sql을 병렬로 실행하면 병렬도로 지정한 만큼 또는 두 배로 병렬 프로세스를 띄워 동시에 작업을 진행하는데, 이때 최초 DB에 접속해서 sql을 수행한 프로세스는 qc역할을 맡는다. 단, 병렬로 처리할 수 없거나 병렬로 처리하도록 지정하지 않은 작업은 qc가 직접 처리한다.

MERGE

keun90 — Tue, 25 Mar 2025 23:24:07 +0900

일반적인 merge 예시 <q1>

<q1>

merge into cutomser t using customer_delta s on (t.cust_id = s.cust_id)

when matched then update

set t.cust_nm = s.cust_nm, t.email = s.email, ...

when not matched then insert

(cust_id,,,, ) values

(s.cust_id,,,,);

</q1>

간혹 merge를 활용해 update(<q2>)를 사용한다.. 그러지 말자.. 불필요한 테이블 접근은 좋지 않다.

update 대상 건수를 쉽게 확인하고자 한다면, <q3>을 활용하는 것을 권장한다.

<q2>

merge into emp t2

using( select t.rowid as rid, s.ename

from emp t, emp_src s

where t.empno = s.empno

and t.ename = s.ename ) s

on (t2.rowid = s.rid)

when matched then update set t2.ename = s.ename;

</q2>

<q3>

update (

select s.ename as s_ename, t.ename as t_ename

from emp t, emp_src s

where t.empno = s.empno

and t.ename <> s.ename

)

set t_ename = s_ename;

</q3>

세이노의 가르침

keun90 — Tue, 25 Mar 2025 07:06:56 +0900

삶의 변화를 위해 새벽에 세이노의 가르침을 읽는다.

나를 위해, 미래에 나의 가족을 위해, 현재의 나의 가족을 위해 나는 내 삶에 변화를 준다.

6:47, 2025-03-25

#무엇을 공부하여야 하는가

: 일당직 노가다 같은 일을 하고 있다면 그 일을 잘하는 방법부터 배워 나가고 그 일과 관련된 책부터 먼저 읽어라. 현장에서 일을 잘하는 사람이 누구인지 살펴보고 그 사람에게 일 좀 잘할 수 있게 가르쳐 달라고 부탁하여라. 인격적으로 존중해 주는 사람 밑에서 일하는 것보다 너를 호되게 야단치는 사람 밑에서 일하는 것이 좋다. 버텨라. 부자 되는 법 같은 책들은 읽지 마라. 헛꿈만 꾸게 되면서 일획천금만 노릴 테니까.

- 유투브를 보면서 나와는 너무 큰 차이가 나는 삶을 단기간에 따라 잡을 생각을 하면서 따라가기 바쁜 경험을 해왔다. 그리고 지치고 포기했다. 그러지 말자. 나의 꿈이 그들과 같지만 내 길에 있는 사람은 나이기 때문에 내 길을 가야 한다.

6:49, 2025-03-26

#일의 대가는 질로 따져라

남들이 하지 않는 서비스를 제공할 것, 절대 오늘의 이득에 눈이 멀면 안 된다는 것, 부자들은 끼리끼리 산다는 것, 한 명의 고객으로부터 신뢰를 받게 되면 시간은 좀 걸리지만 그 주변의 모든 부자들도 언젠가는 내 고객이 된다는 것.

자기가 일하는 시간을 시급을 받기 위한 시간인 것뿐으로 생각하는 그 머리가 깨지지 않는 한, 평생 인생살이가 고달파질 것이다.

6:47, 2025-03-27

#일의 종류에 따라 부자 되는 길이 다르다.

같은 일을 반복하지만 시간이 지나면 봉급이 인상되는 일이 있다. 본인이 노력을 많이 하여도 경제적 대가가 빠르게 증가하는 것도 아니고 노력을 한 사람이나 안 한 사람이나 비슷한 대가를 받기 십상이다. 승진 역시 공정치 못한 경우가 많다. 그럼에도 불구하고 능력 계발을 게을리하면 안 된다. 이런 곳에서 하는 일들은 그 집단 밖으로 나오게 되면 그 경제적 가치가 대부분 사라지기 때문이다. 그런 곳에 너무 오래 있다 나오게 되면 다리의 근육은 이미 마비된 상태에 가까울 수 있으므로 홀로서기를 시도할 때는 조심하는 것이 좋다.

8:20, 2025-03-29

#좋아하는 일이라고 섣불리 하지 마라

언제나 자신감 있는, 당당한 태도가 있어야 하며 "무소유를 즐길 각오가 되어 있어야 한다.

생업을 영위하면서 거기서 얻은 자금으로 자기가 좋아하는 것을 시작하다가 전문가의 경지에 다다르는 사람들은 한두 명이 아니다.

좋아한다고 선택하지 말고 같은 것을 좋아하는 사람들보다 훨씬 더 잘할 자신이 있을 때 비로소 그 좋아하는 것을 선택하여라.

6:50, 2025-04-03

자동차를 타고 가다가 길이 막혀 어쩔 수 없이 보내게 되는 시간 같은 것이 크로노스이다. 가치 있는 시간, 보람 있는 시간이 모두 카이로스이다. 크로노스를 카이로스로 바꾸어 살아가야 한다. 재미없어 보이는 지식들을 위하여 '돈이 되는 시간'을 먼저 투자하는 사람만이 크로노스의 굴레에서 벗어 날 수 있다. 재미있는 것만 즐기면 시간을 보내는 동안 당신의 삶 자체가 조만간 재미없어질 것이다. 개인 방송 서비스에 빠져서 시간 가는 줄 모르는 사람들이 꽤 많을 거다. 그들의 호주머니를 노리고 연동 방송은 계속 늘어나는 것 같고, 그런 것들에 중독되지 않기를 빈다.

SQLP 학습 이유

keun90 — Mon, 24 Mar 2025 23:02:31 +0900

1. Backend 개발을 하면서 SQL을 다루지 않는 개발자는 거의 없을 것이며, 이는 내가 어떤 산업 및 직군에서 일을 시작해도 강점이 될 수 있다.

2. 시스템 성능에 직접적이고 단순? 눈에 보이게 영향을 주는 언어로 자원을 효율적으로 사용함으로써 많은 것을 아낄 수 있다고 생각한다.

Google for Startups 방분.. 좋다.

keun90 — Mon, 24 Mar 2025 21:30:57 +0900

처음으로 회사 옆 현대? 이제는 넥슨게임즈가 구매한 건물에 위치해 있는 구글 공유 오피스에 방문했다.

항상 뭐지?뭐지? 하다가 무료로 입장이 가능하다고 하여 가입 후 들어갔다.

들어서는 순간 느꼈다.. 그래 이런 환경에서 일하고 싶어서 IT를 시작했지...

잠시 앉아서 회사 동료와 대화를 나누었고 나는 그 짧은 순간 감동을 느꼈다..

물론 나도 내가 구글 ! 네이버 ! 절대 못가는 것을 알고 있다..

하지만, 그래도 내가 어디까지 IT의 중심에 갈 수 있을지 궁금하다.

이제 36.. 늦은 나이.. 그래도 하고 싶은건 끝까지 해봐야 직성이 풀린다.

두렵기도 하다.. 아닌 길을 계속 고집하는 것은 아닌지..

분명 나와 같은 사람이 있을 것이다.

나와 같은 사람을 응원해주고 싶다.

(내가 위로 받고 싶어서 그런가..)

잘하지는 못하지만 잘하고 싶은 열정이 있다.

내가 어디까지 IT로 나아갈 수 있을지 여기에 기록하겠다.

나와 같은 사람이 모두 좋은 결과를 얻었으면 좋겠다.