DS ForgeCourses제조 시스템, 껍데기 제거

MANUFACTURING SOFTWARE FIELD LAB · v0.1

제조 시스템,껍데기 제거

ERP의 생산오더부터 MES 실행, 품질 gate, WMS 포장, carrier 추적까지. 이름을 외우지 않고 원장·권한·실패 경계를 직접 추적하는 실행형 학습 지도입니다.

전체 흐름 추적 장애 실습 열기

WO-2026-0717-A01SIMULATION · INFERENCE

SERIALIZED AUDIO UNITAU-0717-0042REV C · ROUTING R12

ORDERRELEASEDERP → MES

WIPOP 30 / TESTCELL-07

QUALITYPASSgate locked

SHIPNOT READYawait outbox

ledger: PostgreSQLtelemetry: InfluxDBUTC−04:00

FUNCTION웹·API 실행 결과는 evidence ledger에서 확인

QUALITY접근성·응답·학습 품질은 별도 측정 필요

PRODUCT / WORKFLOW사용자 학습 효과 미검증

EVIDENCE DISCIPLINE

주장보다 증거를 먼저 배치합니다.

이 랩의 기술 선택과 제조업 일반 패턴을 회사 사실로 포장하지 않습니다.

COMPANY-SPECIFIC UNVERIFIED

실제 JD가 없어 회사의 도입 범위·벤더·운영 구조는 미확인

SPEC

공식 사양이나 제품 지원 정책이 직접 정의

VERIFIED BEHAVIOR

이 저장소에서 명령을 실행해 관측한 결과만 해당

INDUSTRY PATTERN

제조업에서 흔하지만 회사별 경계가 다른 구조

INFERENCE

제공된 단서로부터 추론했지만 환경·담당자·실행 증거로 확인하지 않음

RECOMMENDED PRACTICE

공식 보안·운영 지침을 이 학습 환경에 적용한 권고

PROJECT POLICY

이 교육용 capstone이 명시적으로 선택한 값과 구조

JD PLACEHOLDER DECOMPOSITION · COMPANY-SPECIFIC UNVERIFIED

스택 이름을 검증 질문으로 바꾸기

원본 JD가 제공되지 않았습니다. 아래 행은 목표 기술 스택에서 만든 학습 가설이며 회사 사실이 아닙니다.

스택 신호 (placeholder)	학습할 역량	가능한 경계	입사 후 검증 질문
Python · Django · DRF	거래 API, 상태 전이, audit 및 integration worker를 구현할 가능성	INFERENCE — MES/MOM의 애플리케이션 계층일 수 있으나 실제 책임은 미확인	어떤 서비스가 생산·품질 상태의 authoritative write를 수행하는가?
PostgreSQL	transaction, constraint, lock, migration이 필요한 업무 원장	INFERENCE — 이 랩은 생산·품질·출하 원장으로 선택; 회사 구조는 미확인	DB별 owner, write path, isolation 수준, restore 목표는 무엇인가?
React · TypeScript	작업자·품질·운영자의 상태 확인과 제한된 명령 UI	INFERENCE — shop-floor 또는 internal portal 가능; 실제 사용자·장치는 미확인	장갑·스캐너·offline·stale data·이중 제출을 어떻게 관측하는가?
MQTT · OPC UA · OT	설비 telemetry 수집과 context 전달; 제어·안전 권한과는 분리	INDUSTRY PATTERN — L0–2 제어와 L3 실행 사이의 edge 경계	broker ACL, topic owner, timestamp 원천, offline buffer, dedupe key는 무엇인가?
InfluxDB · Grafana	시계열 보존, ingest lag·설비 추세·운영 alert 가시화	PROJECT POLICY — 이 랩에서는 파생 telemetry이며 거래 원장이 아님	tag cardinality, retention, no-data 의미, dashboard 정의 owner는 누구인가?
ERP · MES · QMS · WMS · TMS	계획→실행→품질→창고→운송의 교차 시스템 흐름	INDUSTRY PATTERN — 제품명보다 원본 데이터와 승인 권한으로 재확인 필요	한 serial의 상태가 각 시스템에서 언제, 왜, 누구에 의해 바뀌는가?
Docker · Nginx · CI/CD	재현 가능한 build, routing, health/readiness, migration, rollback	INFERENCE — 운영 모델·배포 주체·플랫폼은 실제 JD/환경 없이는 미확인	clean install, secrets, backup/restore, rollout/rollback의 실제 owner와 명령은?
Outbox · idempotency · reconciliation	timeout·중복·역순·worker crash가 있는 분산 통합의 정확성	RECOMMENDED PRACTICE — 제품 기능이 아니라 failure semantics 설계	UNKNOWN을 누가 생성·조회·해소하며, 늦은 결과가 상태를 역행시키지 않는가?

SYSTEM MAP · ISA-95 AS A LENS, NOT A COMPANY BLUEPRINT

시스템 이름보다 네 가지 경계

원본 데이터 · 결정 권한 · 시간 규모 · 복구 책임

12 SYSTEMS · 18 MODULES

ONE SERIAL · END TO END

한 개의 serial이 지나가는 호출과 데이터

각 화살표는 transaction, business event, telemetry를 구분합니다. 선택해서 소유권을 확인하세요.

authoritative owner

ERP

ERP 생산오더 단계의 command가 다음 시스템으로 전달됩니다. event_id·schema_version·occurred_at·received_at·correlation_id·idempotency_key를 기록합니다.

BOUNDARIES AS CODE · PROJECT POLICY

네 개의 서로 다른 지도

시스템 배치, 호출 순서, 상태 전이, 데이터 계보를 하나의 그림으로 섞지 않습니다.

01 · SYSTEM권한과 시간 규모

L4 · PLAN / COMMERCIAL

CRM / OMSERP / APSPLM / SCM

고객 의도·계획·설계 정의

L3 · EXECUTE / ASSURE

MES / MOMQMSWMS / TMS

실행·품질 판정·창고/운송 handoff

L2–3 · CONTEXT / OBSERVE

MQTT / OPC UAInfluxDBGrafana

telemetry 전달과 관측; 거래 write 권한 없음

L0–2 · CONTROL / SAFETY

SensorPLC / HMISafety interlock

OT가 제어·안전을 소유; 이 랩은 절대 명령하지 않음

02 · SEQUENCE호출·전달·commit 순서

01ERPMEScommand생산오더와 release된 revision
02MESPostgreSQLtransactionBOM/routing을 고정하고 WIP 생성
03EquipmentMQTT → InfluxDBtelemetry중복 가능한 합성 측정
04QMSMESdecisionPASS / HOLD / release 증거
05MESOutbox workerevent전달 전에 완료와 outbox를 commit
06Outbox workerWMScommand멱등 shipment 요청
07CarrierMES projectioneventmilestone 정규화와 상태 역행 차단

03 · STATE생산·품질 gate 전이

DRAFTRELEASEDrelease된 engineering definition
RELEASEDIN_PROGRESSserial과 첫 operation
IN_PROGRESSON_HOLDquality HOLD / FAIL
ON_HOLDIN_PROGRESS더 늦은 PASS와 권한 있는 release
IN_PROGRESSCOMPLETEDrouting·BOM·최종 PASS
COMPLETEDSHIPPED관측된 WMS/carrier 진행

PROJECT POLICY — 실제 회사의 상태명·gate·승인 역할은 미확인

04 · LINEAGE정의에서 배송 증거까지

EngineeringDefinitionsnapshot으로 고정ProductionOrder
ProductionOrder생성Unit / serial
Unit실행 사실 기록OperationExecution + MaterialConsumption
Unitgate 적용Inspection + QualityRelease
Unit출하 요청 생성Shipment + OutboxMessage
Shipment외부 진행 관측WmsEvent + CarrierEvent

READ THE IMPLEMENTATION

설명 옆에서 실제 저장소 경로 읽기

아래 발췌는 학습 길잡이입니다. 현재 동작의 증거는 해당 파일과 test/실행 결과를 함께 확인해야 합니다.

PROJECT POLICYbackend/production/services.py

released definition의 canonical hash

@transaction.atomic
def register_engineering_definition(*, validated: dict[str, Any]):
    routing_operations = sorted(
        [
            {"sequence": operation["sequence"], "code": operation["code"]}
            for operation in validated["routing_operations"]
        ],
        key=lambda operation: operation["sequence"],
    )

PROJECT POLICYbackend/integration/services.py

outbox idempotency 충돌 차단

if not created and (
    message.aggregate_id != str(aggregate_id)
    or message.event_type != event_type
    or canonical_payload_hash(message.payload) != canonical_payload_hash(payload)
):
    raise DomainError(
        "IDEMPOTENCY_KEY_REUSED",
        "The outbox idempotency key was already used for a different event.",
    )

PROJECT POLICYbackend/integration/telemetry.py

topic/identity contract validation

TELEMETRY_TOPIC = re.compile(
    r"^factory/(?P<plant>[^/]+)/equipment/(?P<equipment>[^/]+)/telemetry$"
)

if event_type != "equipment.telemetry" or schema_version != "1.0":
    raise DomainError(
        "UNSUPPORTED_TELEMETRY_CONTRACT",
        "Only equipment.telemetry schema 1.0 is accepted.",
        400,
    )

PROJECT POLICYbackend/integration/services.py

timeout을 UNKNOWN으로 보존

elif normalized in {"TIMEOUT", "UNKNOWN"}:
    message.status = OutboxMessage.Status.UNKNOWN
    message.last_error = detail or "External outcome is unknown after timeout."
    message.attempts = F("attempts") + 1
    message.lease_token = None
    message.lease_until = None

PROJECT POLICYbackend/integration/urls.py

carrier webhook · /api/v1/integrations/carriers/{carrier}/webhooks/

path(
    "carriers/<str:carrier>/webhooks/",
    CarrierWebhookView.as_view(),
    name="carrier-webhook",
)

FAILURE SIMULATOR

정상보다 실패를 먼저 이해하기

합성 이벤트만 사용합니다. 실제 PLC·장비·회사 시스템에는 연결하지 않습니다.

시나리오를 실행하면 이벤트가 여기에 나타납니다.

LOCAL SYNTHETIC API OPERATOR · READ + CONFIRMED SYNTHETIC MUTATION

원장을 읽고, 확인한 다음 stage만 실행

현재 origin 또는 loopback의 합성 랩만 사용합니다. API key는 메모리에만 두고, actor·role·명시적 확인 뒤 한 stage씩 실행합니다. PLC·장비·안전 제어는 없습니다.

LOCAL READOUTmutation 없음 · 장비 제어 없음

public health 또는 API key가 필요한 원장 snapshot을 선택하세요.

BOUNDED VERTICAL SLICE · LOCAL SYNTHETIC ONLY

ERP → MES → Quality → Shipping operator

FUNCTION OBSERVATION ONLY · QUALITY / PRODUCT UNVERIFIED

01
Engineering definition releaserole · engineer
NEXT
02
ERP order / inbox deduperole · integration
WAITING
03
Order release / unit startrole · planner → operator
WAITING
04
Material genealogy / ordered operationsrole · operator
WAITING
05
Synthetic final quality PASSrole · quality
WAITING
06
Unit completion / outbox observationrole · operator
WAITING
07
Shipment dispatch / timeline observationrole · shipping
WAITING

STAGE OBSERVATIONSno run

API key·actor·확인을 입력하면 첫 synthetic engineering stage가 활성화됩니다.

PROJECT POLICY — base URL은 현재 origin 또는 loopback host로 제한됩니다. shared key와 self-asserted role은 교육용 guard이며 enterprise IAM이 아닙니다. 화면의 OBSERVED는 HTTP/원장 기능 관측일 뿐 품질·학습 효과 검증이 아닙니다.

MAP → RUN → TRACE → BREAK → RECONCILE → HARDEN

18개 모듈, 하나의 연결된 capstone

각 모듈은 실행·실패·복구 증거를 요구합니다. 체크 표시는 학습 진행 기록일 뿐, 명령 실행이나 품질 검증을 뜻하지 않습니다.

0 / 18이 브라우저에만 저장 · 체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M00JD와 공장 현실gemba · evidence요구 증거 · 시스템·사람·원장 지도

냉정한 실체

기술 이름은 실제 배치·소유권의 증거가 아니다.

학습 결과

확인·추론·정책을 분리한다.

실습

주문 하나를 현장부터 고객까지 추적

요구 증거 (미실행이면 미검증)

시스템·사람·원장 지도

01
JD 연결COMPANY-SPECIFIC UNVERIFIED · gemba · evidence는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: ISA-95
02
냉정한 실체와 오해
기술 이름은 실제 배치·소유권의 증거가 아니다.
03
선수 지식 / 예상 시간
JD 원문, process-map 기초 · 3시간
04
Mental model
‘문구 → 검증 질문 → 관측 → 증거 등급’ 사다리. 스택 이름은 채택 증거가 아니다.
05
공장 물리 흐름
입고 dock, 생산 cell, 검사 station, 출하 dock에서 한 order·serial·shipment를 따라간다.
06
Data ownership
실제 owner와 원장은 미확인이다. 인터뷰, 화면, API, runbook을 교차 확인해 unknown으로 시작한다.
07
내부 실행 과정
JD 문구를 그대로 인용하고 사실·추론·질문을 분리한 뒤 현장 관측으로만 승격한다.
08
최소 코드 경로
docs/SOURCE-MATRIX.md에서 주장 하나의 source와 분류를 추적한다.
09
Production 확장 경로
docs/FIRST-90-DAYS.md와 실제 incident/deploy/owner map을 연결하되 회사 정보는 입사 후 채운다.
10
중요 코드 설명
evidenceClasses와 JD placeholder 표가 회사 미확인 정보를 VERIFIED로 보이지 않게 하는 guard다.
11
End-to-end trace
주문 하나를 현장부터 고객까지 추적 · 실제 경로: docs/SOURCE-MATRIX.md
12
Transaction / failure boundary
기술 이름을 회사 채택 사실로 바꾸지 않는다.
13
실패 주입
추론을 VERIFIED로 표시
14
구체적 test matrix
Unit: 분류 규칙; integration: 한 serial trace; contract: source URL; concurrency: owner 충돌; load: 20개 주장 점검.
15
보안 / 제조 안전
gemba 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
docs/SOURCE-MATRIX.md 실행에서 correlation_id, 시간, 상태 전이, latency와 시스템·사람·원장 지도를 함께 관측한다.
17
제출 산출물
시스템·사람·원장 지도 · 실행: Review evidence classes before claims
18
기계적 완료 조건
한 serial의 사람·시스템·원장·unknown 표를 만들고 각 행에 출처 또는 미확인을 붙인다.
19
현업 질문
누가 상태를 쓰고, 누가 승인하며, 장애 시 누가 reconcile하고, 어느 문서가 최신인가?
20
시나리오형 자가시험
JD에 Django가 적혀 있다. ‘회사가 MES에 Django를 쓴다’고 말하기 전에 필요한 증거 세 가지는?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M01Enterprise System MapISA-95 · ownership요구 증거 · authoritative owner 표

냉정한 실체

제품명이 아니라 데이터 원본과 결정 권한이 경계를 만든다.

학습 결과

ERP/MES/QMS/WMS/OT 경계를 설명한다.

실습

시스템 경계 패널 탐색

요구 증거 (미실행이면 미검증)

authoritative owner 표

01
JD 연결INDUSTRY PATTERN + PROJECT POLICY · ISA-95 · ownership는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: ISA-95
02
냉정한 실체와 오해
제품명이 아니라 데이터 원본과 결정 권한이 경계를 만든다.
03
선수 지식 / 예상 시간
M00, transaction/event/master data 구분 · 4시간
04
Mental model
시스템 상자는 기능명이 아니라 authoritative write, 결정 권한, 시간 규모, 복구 owner의 묶음이다.
05
공장 물리 흐름
수요→계획→release→cell 실행→검사→창고→carrier 흐름에 시스템 경계를 겹친다.
06
Data ownership
ERP는 계획, MES는 실행, QMS는 disposition, WMS는 위치/작업을 소유한다는 것은 산업 패턴이며 실제 owner는 검증한다.
07
내부 실행 과정
write별 producer, consumer, key, time, 승인, rollback을 owner matrix 한 행으로 기록한다.
08
최소 코드 경로
app/data.ts의 systems와 system-map 패널에서 한 serial의 경계를 클릭해 본다.
09
Production 확장 경로
docs/SYSTEM-BOUNDARIES.md에 API/event schema, RACI, degraded mode, reconciliation owner를 추가한다.
10
중요 코드 설명
systems.authority와 recovery가 같은 기능 이름 안에서도 write와 복구 책임을 분리한다.
11
End-to-end trace
시스템 경계 패널 탐색 · 실제 경로: docs/SYSTEM-BOUNDARIES.md
12
Transaction / failure boundary
각 write에는 authoritative owner가 하나 있다.
13
실패 주입
제품명을 곧 데이터 소유권으로 간주
14
구체적 test matrix
Unit: owner 행 완전성; integration: serial trace; contract: event schema; concurrency: 이중 writer; load: 100 event route 분류.
15
보안 / 제조 안전
ISA-95 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
docs/SYSTEM-BOUNDARIES.md 실행에서 correlation_id, 시간, 상태 전이, latency와 authoritative owner 표를 함께 관측한다.
17
제출 산출물
authoritative owner 표 · 실행: Open system map and trace one serial
18
기계적 완료 조건
모든 write에 owner 하나, 모든 timeout에 recovery owner 하나, 미확인 제품에는 UNKNOWN을 둔다.
19
현업 질문
계획과 실행 수량이 갈라질 때 어느 원장을 먼저 보고 어떤 key로 맞추는가?
20
시나리오형 자가시험
Grafana와 MES 수량이 다르다. 어느 시스템이 무엇을 소유하며 첫 trace는 어디서 시작하는가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M02Python RuntimeCPython · typing · time요구 증거 · 프로파일과 결정 기록

냉정한 실체

GIL은 모든 동시성 문제를 해결하지도, 모든 병렬성을 막지도 않는다.

학습 결과

I/O·CPU·thread·process·async 선택을 근거화한다.

실습

이벤트 재생 generator와 fake clock

요구 증거 (미실행이면 미검증)

프로파일과 결정 기록

01
JD 연결PROJECT POLICY · CPython · typing · time는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: Python docs
02
냉정한 실체와 오해
GIL은 모든 동시성 문제를 해결하지도, 모든 병렬성을 막지도 않는다.
03
선수 지식 / 예상 시간
Python 문법, process/thread 기초 · 6시간
04
Mental model
object identity·mutability와 scheduler/GIL은 별개다. I/O wait와 CPU work를 측정해 실행 모델을 고른다.
05
공장 물리 흐름
설비 event가 socket에서 decode→validate→dedupe→DB commit→export되는 작업 흐름을 runtime 단계로 본다.
06
Data ownership
Python object는 메모리 표현일 뿐이고 commit된 PostgreSQL 행이 거래 사실을 소유한다.
07
내부 실행 과정
iterator/context manager로 bounded stream을 읽고 Decimal·UTC datetime을 검증하며 exception을 domain error로 번역한다.
08
최소 코드 경로
backend/pyproject.toml과 telemetry parser test를 실행해 typing, Decimal, datetime 경계를 확인한다.
09
Production 확장 경로
fake clock, bounded queue, graceful cancellation, CPU/profile snapshot을 worker에 추가하는 경로를 설계한다.
10
중요 코드 설명
generator의 lazy iteration과 context manager cleanup이 replay 크기와 shutdown 누수를 제한한다.
11
End-to-end trace
이벤트 재생 generator와 fake clock · 실제 경로: backend/pyproject.toml
12
Transaction / failure boundary
시간과 retry는 test에서 제어 가능하다.
13
실패 주입
thread가 자동으로 correctness를 제공한다고 가정
14
구체적 test matrix
Unit: Decimal/time; integration: worker+DB; contract: schema types; concurrency: duplicate threads; load: bounded 1k synthetic events.
15
보안 / 제조 안전
CPython 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/pyproject.toml 실행에서 correlation_id, 시간, 상태 전이, latency와 프로파일과 결정 기록를 함께 관측한다.
17
제출 산출물
프로파일과 결정 기록 · 실행: cd backend && pytest
18
기계적 완료 조건
동일 fixture를 sync/thread/async로 측정하고 wall/CPU/memory와 선택 이유를 기록한다.
19
현업 질문
CPU-bound 구간, blocking client, cancellation, memory ceiling, timezone source는 무엇인가?
20
시나리오형 자가시험
MQTT consumer가 느려졌다. GIL 탓이라고 결론 내리기 전에 어떤 profile과 queue 지표를 확인하는가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M03Django Transaction CoreDjango · DRF · audit요구 증거 · migration·system check·API test

냉정한 실체

요청 성공과 외부 부작용 성공은 같은 transaction이 아니다.

학습 결과

atomic·lock·constraint·on_commit을 적용한다.

실습

생산오더 상태 전이 API

요구 증거 (미실행이면 미검증)

migration·system check·API test

01
JD 연결PROJECT POLICY · Django · DRF · audit는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: Django transactions
02
냉정한 실체와 오해
요청 성공과 외부 부작용 성공은 같은 transaction이 아니다.
03
선수 지식 / 예상 시간
M02, HTTP/SQL/transaction 기초 · 8시간
04
Mental model
request lifecycle과 DB transaction, 외부 side effect는 서로 다른 경계다.
05
공장 물리 흐름
operator submit이 Nginx→middleware→serializer→service→PostgreSQL→outbox worker로 이동한다.
06
Data ownership
Django service가 상태 전이를 조정하지만 constraint와 commit된 PostgreSQL이 불변식을 최종 보존한다.
07
내부 실행 과정
serializer validation 후 atomic block에서 select_for_update, 상태/audit/outbox write를 완료하고 commit 뒤 전달한다.
08
최소 코드 경로
backend/production/services.py와 production API test에서 release→start→complete를 추적한다.
09
Production 확장 경로
permission, on_commit, background worker lease, graceful shutdown, health/readiness를 같은 trace에 연결한다.
10
중요 코드 설명
transaction.atomic과 select_for_update는 상태·audit·outbox의 commit 순서를 지키며 외부 호출은 밖에 둔다.
11
End-to-end trace
생산오더 상태 전이 API · 실제 경로: backend/production/services.py
12
Transaction / failure boundary
상태 전이와 audit/outbox 생성은 한 원자 경계다.
13
실패 주입
commit 전 외부 부작용
14
구체적 test matrix
Unit: serializer; integration: PostgreSQL transition; contract: error schema; concurrency: double start; load: bounded API p95/query count.
15
보안 / 제조 안전
Django 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/production/services.py 실행에서 correlation_id, 시간, 상태 전이, latency와 migration·system check·API test를 함께 관측한다.
17
제출 산출물
migration·system check·API test · 실행: cd backend && python manage.py check
18
기계적 완료 조건
system check/migration replay와 transition·permission·race test를 통과시키고 transaction trace를 남긴다.
19
현업 질문
audit actor는 어디서 오며, 요청 취소·worker shutdown·migration 중 write는 어떻게 다루는가?
20
시나리오형 자가시험
DB commit 전 ERP를 호출했다가 timeout 됐다. 어떤 split-brain이 생기며 outbox로 어떻게 바꾸는가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M04REST와 통합 계약OpenAPI · webhook · idempotency요구 증거 · 계약 test와 error schema

냉정한 실체

timeout은 실패가 아니라 결과 미확정일 수 있다.

학습 결과

idempotency·version·retry·UNKNOWN을 설계한다.

실습

ERP inbox와 carrier webhook

요구 증거 (미실행이면 미검증)

계약 test와 error schema

01
JD 연결PROJECT POLICY · OpenAPI · webhook · idempotency는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: OWASP API Security
02
냉정한 실체와 오해
timeout은 실패가 아니라 결과 미확정일 수 있다.
03
선수 지식 / 예상 시간
M03, HTTP semantics, JSON schema · 7시간
04
Mental model
HTTP status는 transport 관측이고 business outcome은 별도다. timeout은 UNKNOWN일 수 있다.
05
공장 물리 흐름
ERP event→MES inbox와 MES outbox→WMS, carrier webhook→tracking projection을 각각 추적한다.
06
Data ownership
inbox/outbox가 전달 증거를, domain ledger가 주문·unit·shipment 상태를 소유한다.
07
내부 실행 과정
versioned serializer→idempotency hash→domain transaction→stable error contract; signed webhook은 replay window를 검사한다.
08
최소 코드 경로
/api/docs/에서 ERP inbox와 production command schema를 열고 한 요청을 contract test와 대조한다.
09
Production 확장 경로
pagination, ETag/version, timeout budget, jitter, circuit breaker, polling/webhook reconciliation을 추가한다.
10
중요 코드 설명
같은 idempotency key의 payload hash가 다르면 409로 막아 retry와 충돌을 구분한다.
11
End-to-end trace
ERP inbox와 carrier webhook · 실제 경로: backend/mes_project/urls.py
12
Transaction / failure boundary
동일 key+동일 payload만 replay다.
13
실패 주입
timeout을 FAILED로 단정
14
구체적 test matrix
Unit: canonical hash; integration: inbox/outbox; contract: OpenAPI/error; concurrency: same key conflict; load: bounded retry-rate test.
15
보안 / 제조 안전
OpenAPI 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/mes_project/urls.py 실행에서 correlation_id, 시간, 상태 전이, latency와 계약 test와 error schema를 함께 관측한다.
17
제출 산출물
계약 test와 error schema · 실행: Open /api/docs/
18
기계적 완료 조건
happy/replay/conflict/timeout/UNKNOWN/reconcile를 같은 correlation_id로 관측하고 schema diff를 저장한다.
19
현업 질문
client와 proxy timeout 계층, idempotency 보존 기간, webhook secret rotation, UNKNOWN owner는 누구인가?
20
시나리오형 자가시험
POST가 timeout됐지만 remote side effect는 생겼다. 안전한 다음 요청과 관측 순서는?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M05PostgreSQL 정확성MVCC · locking · EXPLAIN요구 증거 · constraint와 동시성 test

냉정한 실체

ORM은 lost update·deadlock·N+1을 자동으로 없애지 않는다.

학습 결과

MVCC·격리·lock·index를 관측한다.

실습

serial 경쟁 할당

요구 증거 (미실행이면 미검증)

constraint와 동시성 test

01
JD 연결PROJECT POLICY · MVCC · locking · EXPLAIN는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: PostgreSQL concurrency
02
냉정한 실체와 오해
ORM은 lost update·deadlock·N+1을 자동으로 없애지 않는다.
03
선수 지식 / 예상 시간
SQL, M03 transaction, index 기초 · 8시간
04
Mental model
MVCC snapshot, row lock, constraint, index는 각기 다른 정확성/성능 도구다.
05
공장 물리 흐름
두 scanner 요청이 같은 serial과 row를 경쟁하고 commit/rollback 뒤 작업자 화면으로 결과가 돌아간다.
06
Data ownership
PostgreSQL이 production·quality·shipping transaction ledger이며 Influx/Grafana는 이를 대체하지 않는다.
07
내부 실행 과정
predicate/constraint→row lock→version check→write→commit; deadlock은 bounded retry 대상으로 분류한다.
08
최소 코드 경로
backend/production/models.py constraint와 PostgreSQL-marked tests를 함께 읽는다.
09
Production 확장 경로
EXPLAIN ANALYZE, pooling, autovacuum/bloat, partition, online migration, restore drill을 dataset과 함께 기록한다.
10
중요 코드 설명
unique constraint가 application pre-check의 race를 막고 select_for_update가 상태 전이 순서를 직렬화한다.
11
End-to-end trace
serial 경쟁 할당 · 실제 경로: backend/production/models.py
12
Transaction / failure boundary
constraint가 race 후에도 불변식을 지킨다.
13
실패 주입
SQLite test를 PostgreSQL 동시성 증거로 사용
14
구체적 test matrix
Unit: query builder; integration: real PG; contract: schema constraint; concurrency: lost update/deadlock; load: p95+pool saturation.
15
보안 / 제조 안전
MVCC 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/production/models.py 실행에서 correlation_id, 시간, 상태 전이, latency와 constraint와 동시성 test를 함께 관측한다.
17
제출 산출물
constraint와 동시성 test · 실행: cd backend && pytest -m postgres
18
기계적 완료 조건
SQLite와 구분된 PostgreSQL race test, query plan, migration forward/reverse, restore 결과를 남긴다.
19
현업 질문
isolation level, longest transaction, pool ceiling, hot index, vacuum 경보, RPO/RTO는?
20
시나리오형 자가시험
두 요청이 같은 serial을 통과시켰다. application check만으로 부족한 이유와 DB 방어층은?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M06MES/MOM 실행WIP · genealogy · state요구 증거 · 선행조건과 revision 불변식

냉정한 실체

MES는 계획 원장도 PLC safety controller도 아니다.

학습 결과

WIP·traveler·genealogy·state machine을 만든다.

실습

release→dispatch→complete

요구 증거 (미실행이면 미검증)

선행조건과 revision 불변식

01
JD 연결PROJECT POLICY · WIP · genealogy · state는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: ISA-95
02
냉정한 실체와 오해
MES는 계획 원장도 PLC safety controller도 아니다.
03
선수 지식 / 예상 시간
M01·M03·M05, routing/BOM 기초 · 10시간
04
Mental model
MES는 ‘계획 수량’을 복사하는 곳이 아니라 serial별 실행 사실과 gate를 보존하는 state machine이다.
05
공장 물리 흐름
released order→dispatch→serial scan→자재 lot→순차 operation→검사→완료·인계를 따라간다.
06
Data ownership
ERP가 계획 order를, MES PostgreSQL이 WIP·operation·genealogy·completion을 소유한다.
07
내부 실행 과정
release한 definition hash를 order에 고정하고 predecessor·material·quality guard 후 audit/outbox와 함께 완료한다.
08
최소 코드 경로
backend/production/services.py와 scripts/capstone_smoke.py의 release→start→material→operation→complete를 대조한다.
09
Production 확장 경로
rework·scrap·labor·downtime·offline traveler·shift/DST·ERP reconciliation을 별도 상태와 event로 확장한다.
10
중요 코드 설명
released_definition_hash와 operation sequence guard가 과거 definition을 바꾸거나 공정을 건너뛰는 것을 막는다.
11
End-to-end trace
release→dispatch→complete · 실제 경로: backend/production/services.py
12
Transaction / failure boundary
선행 공정·자재·품질 gate 없이는 완료할 수 없다.
13
실패 주입
계획 수량을 실행 실적으로 오인
14
구체적 test matrix
Unit: state guard; integration: ERP→MES; contract: event envelope; concurrency: serial/double-submit; load: bounded order throughput.
15
보안 / 제조 안전
WIP 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/production/services.py 실행에서 correlation_id, 시간, 상태 전이, latency와 선행조건과 revision 불변식를 함께 관측한다.
17
제출 산출물
선행조건과 revision 불변식 · 실행: Run scripts/capstone_smoke.py after stack start
18
기계적 완료 조건
revision mismatch·operation skip·material replay·quality block을 주입하고 한 serial의 as-built trace를 재생한다.
19
현업 질문
dispatch owner, traveler 원본, WIP definition, rework 권한, offline 동기화 규칙은?
20
시나리오형 자가시험
order release 후 BOM이 바뀌었다. 기존 WIP가 참조해야 할 definition과 예외 절차는?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M07PLM·QMS·CMMSEBOM · NCR · CAPA요구 증거 · 차단 test와 audit reason

냉정한 실체

설계 revision, 품질 disposition, 정비 release는 서로 다른 권한이다.

학습 결과

ECO·NCR·CAPA·교정 경계를 연결한다.

실습

revision mismatch와 quality hold

요구 증거 (미실행이면 미검증)

차단 test와 audit reason

01
JD 연결PROJECT POLICY · EBOM · NCR · CAPA는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: FDA CAPA overview
02
냉정한 실체와 오해
설계 revision, 품질 disposition, 정비 release는 서로 다른 권한이다.
03
선수 지식 / 예상 시간
M06, revision/effectivity·inspection 기초 · 7시간
04
Mental model
engineering release, quality disposition, maintenance return-to-service는 같은 승인이 아닌 서로 다른 권한 그래프다.
05
공장 물리 흐름
drawing/ECO→MBOM/routing→수입·공정검사→NCR/CAPA→교정·정비 release→MES gate를 연결한다.
06
Data ownership
PLM은 설계 definition, QMS는 검사·disposition, CMMS는 정비 작업과 return-to-service를 소유한다.
07
내부 실행 과정
effectivity를 평가해 definition을 고정하고 검사 결과를 append하며 권한있는 reason으로만 hold를 해제한다.
08
최소 코드 경로
backend/quality/services.py의 HOLD/FAIL/PASS와 quality release test를 읽는다.
09
Production 확장 경로
NCR disposition, deviation expiry, CAPA linkage, calibration due, maintenance lockout를 별도 owner와 구조화한다.
10
중요 코드 설명
더 늦은 PASS와 supervisor reason만 hold를 해제하며 이전 FAIL은 삭제하지 않는다.
11
End-to-end trace
revision mismatch와 quality hold · 실제 경로: backend/quality/services.py
12
Transaction / failure boundary
승인 권한과 audit reason이 분리되어 남는다.
13
실패 주입
FAIL 후 이전 PASS로 release
14
구체적 test matrix
Unit: effectivity; integration: QMS→MES gate; contract: inspection schema; concurrency: double release; load: bounded inspection batch.
15
보안 / 제조 안전
EBOM 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/quality/services.py 실행에서 correlation_id, 시간, 상태 전이, latency와 차단 test와 audit reason를 함께 관측한다.
17
제출 산출물
차단 test와 audit reason · 실행: cd backend && pytest -k quality
18
기계적 완료 조건
revision mismatch·expired deviation·FAIL 후 이전 PASS·unauthorized release를 차단하고 audit reason을 보존한다.
19
현업 질문
ECO effectivity, NCR disposition, CAPA closure, calibration override, return-to-service 승인자는?
20
시나리오형 자가시험
PASS 후 FAIL이 추가됐다. 출하 gate에서 어느 결과와 actor/reason을 사용하는가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M08ERP·SCM·OMSMRP · split-brain · reconcile요구 증거 · inbox dedupe와 reconcile backlog

냉정한 실체

공식 재고·위치 재고·line-side·WIP는 같은 수량이 아니다.

학습 결과

계획과 실행의 reconciliation을 설계한다.

실습

중복 production order 수신

요구 증거 (미실행이면 미검증)

inbox dedupe와 reconcile backlog

01
JD 연결PROJECT POLICY · MRP · split-brain · reconcile는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: ISA-95
02
냉정한 실체와 오해
공식 재고·위치 재고·line-side·WIP는 같은 수량이 아니다.
03
선수 지식 / 예상 시간
M01·M04·M06, MRP/inventory 기초 · 7시간
04
Mental model
customer intent, demand plan, financial inventory, execution WIP는 서로 다른 정의와 reconciliation key를 갖는다.
05
공장 물리 흐름
quote→sales order→MRP→PO/production order→MES execution→fulfillment→invoice를 역할별로 본다.
06
Data ownership
ERP는 계획·원가·재무 재고, MES는 WIP 실행 사실을 소유하고 inbox/outbox가 전달을 증명한다.
07
내부 실행 과정
versioned ERP envelope를 inbox에 dedupe하고 order를 생성한 뒤 completion outbox를 ERP ACK와 reconcile한다.
08
최소 코드 경로
backend/integration/views.py와 capstone_smoke의 duplicate ERP POST를 대조한다.
09
Production 확장 경로
master-data versioning, partial completion, split order, supplier exception, cost posting, polling reconciliation을 추가한다.
10
중요 코드 설명
inbox의 idempotency_key+payload hash가 retry는 재사용하고 충돌은 차단한다.
11
End-to-end trace
중복 production order 수신 · 실제 경로: backend/integration/views.py
12
Transaction / failure boundary
중복 주문 수신이 수량을 늘리지 않는다.
13
실패 주입
재시도로 별도 order 생성
14
구체적 test matrix
Unit: envelope hash; integration: ERP→MES→ACK; contract: version schema; concurrency: duplicate order; load: bounded inbox replay.
15
보안 / 제조 안전
MRP 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/integration/views.py 실행에서 correlation_id, 시간, 상태 전이, latency와 inbox dedupe와 reconcile backlog를 함께 관측한다.
17
제출 산출물
inbox dedupe와 reconcile backlog · 실행: cd backend && pytest -k erp
18
기계적 완료 조건
같은 event replay·다른 payload 충돌·ERP/MES split-brain·completion ACK timeout을 재현·reconcile한다.
19
현업 질문
order cancel/change, allocation, financial inventory, supplier master, completion correction의 owner와 key는?
20
시나리오형 자가시험
ERP는 2개, MES는 1개 완료로 보인다. 즉시 수정 전에 무엇을 비교하는가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M09WMS·TMS·ShippingLPN · tracking · RMA요구 증거 · 상태 비역행 test

냉정한 실체

출하는 MES 한 시스템의 상태 전이가 아니다.

학습 결과

pick·pack·manifest·tracking·RMA를 분리한다.

실습

역순 carrier webhook

요구 증거 (미실행이면 미검증)

상태 비역행 test

01
JD 연결PROJECT POLICY · LPN · tracking · RMA는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: GS1 EPCIS
02
냉정한 실체와 오해
출하는 MES 한 시스템의 상태 전이가 아니다.
03
선수 지식 / 예상 시간
M04·M06·M08, warehouse/tracking 기초 · 7시간
04
Mental model
allocation·pick·pack·manifest·carrier milestone·RMA는 다른 ledger와 상태 기계다.
05
공장 물리 흐름
finished unit→bin/LPN→pick→pack/label→dock→carrier scan→delivery/return을 추적한다.
06
Data ownership
MES는 생산·quality gate, WMS는 창고 작업/위치, carrier는 운송 event, ERP는 fulfillment 금액을 소유한다.
07
내부 실행 과정
quality gate 후 dispatch outbox를 생성하고 WMS event를 watermark로 정규화하며 서명된 carrier sequence의 역행을 무시한다.
08
최소 코드 경로
backend/shipping/services.py의 dispatch·WMS event·timeline test를 읽는다.
09
Production 확장 경로
pick shortage, partial shipment, multi-package, label/manifest UNKNOWN, delivery exception, RMA genealogy를 확장한다.
10
중요 코드 설명
sequence/watermark와 semantic payload hash가 duplicate는 흡수하고 DELIVERED 후 regression은 무시한다.
11
End-to-end trace
역순 carrier webhook · 실제 경로: backend/shipping/services.py + backend/integration/urls.py
12
Transaction / failure boundary
늦은 milestone이 배송 상태를 역행시키지 않는다.
13
실패 주입
DELIVERED 뒤 IN_TRANSIT 적용
14
구체적 test matrix
Unit: status rank; integration: MES→WMS→carrier; contract: signed webhook; concurrency: duplicate dispatch; load: bounded webhook burst.
15
보안 / 제조 안전
LPN 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/shipping/services.py + backend/integration/urls.py 실행에서 correlation_id, 시간, 상태 전이, latency와 상태 비역행 test를 함께 관측한다.
17
제출 산출물
상태 비역행 test · 실행: cd backend && pytest -k shipping
18
기계적 완료 조건
quality hold·pick shortage·timeout UNKNOWN·duplicate/delayed webhook·tracking regression을 테스트한다.
19
현업 질문
shipment split, label, manifest, tracking projection, exception, RMA의 authoritative owner와 SLA는?
20
시나리오형 자가시험
DELIVERED 후 더 낮은 sequence의 IN_TRANSIT가 도착했다. 저장·projection·audit은 어떻게 다른가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M10MQTT와 OTMQTT 5 · OPC-UA · telemetry요구 증거 · event_id dedupe와 lag metric

냉정한 실체

QoS 2는 business exactly-once가 아니다.

학습 결과

duplicate·reconnect·clock skew·ACL을 다룬다.

실습

설비 simulator replay

요구 증거 (미실행이면 미검증)

event_id dedupe와 lag metric

01
JD 연결INDUSTRY PATTERN + PROJECT POLICY · MQTT 5 · OPC-UA · telemetry는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: MQTT 5.0
02
냉정한 실체와 오해
QoS 2는 business exactly-once가 아니다.
03
선수 지식 / 예상 시간
M02·M04, pub/sub·OT zone 기초 · 8시간
04
Mental model
MQTT QoS는 broker hop 전달 의미이며 business exactly-once와 제어 안전 권한을 제공하지 않는다.
05
공장 물리 흐름
sensor/PLC→edge gateway→broker→consumer→PostgreSQL receipt→Influx export를 simulator로만 재현한다.
06
Data ownership
OT가 control/safety를 소유하고 MQTT는 전달, PostgreSQL receipt는 dedupe, Influx는 telemetry 보존을 소유한다.
07
내부 실행 과정
topic/source/schema/identity/time을 검증해 durable receipt을 commit한 뒤 ACK하고 poison은 DLQ와 수동 resolve로 격리한다.
08
최소 코드 경로
backend/integration/telemetry.py와 equipment simulator의 happy/duplicate/out-of-order mode를 대조한다.
09
Production 확장 경로
TLS/device identity/ACL, persistent session, LWT, store-and-forward, reconnect jitter, schema evolution, clock discipline을 추가한다.
10
중요 코드 설명
event_id·source·topic identity hash와 manual ACK 순서가 duplicate와 crash replay에서 원장 중복을 막는다.
11
End-to-end trace
설비 simulator replay · 실제 경로: backend/integration/telemetry.py
12
Transaction / failure boundary
message/event identity로 duplicate를 흡수한다.
13
실패 주입
QoS를 business exactly-once로 해석
14
구체적 test matrix
Unit: topic/schema; integration: broker+consumer; contract: envelope; concurrency: duplicate delivery; load: bounded ingest/lag/cardinality.
15
보안 / 제조 안전
MQTT 5 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/integration/telemetry.py 실행에서 correlation_id, 시간, 상태 전이, latency와 event_id dedupe와 lag metric를 함께 관측한다.
17
제출 산출물
event_id dedupe와 lag metric · 실행: docker compose --profile simulation up equipment-simulator
18
기계적 완료 조건
duplicate·역순·stale retained·disconnect·offline replay·clock drift·poison을 합성 event로 재현한다.
19
현업 질문
topic/ACL owner, device identity, timestamp source, offline buffer ceiling, command topic 승인 경계는?
20
시나리오형 자가시험
QoS 2 message가 consumer crash 후 재전달됐다. 생산 수량을 한 번만 늘리는 transaction은?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M11InfluxDB 시계열cardinality · retention · late data요구 증거 · series 수와 retention 기록

냉정한 실체

tag cardinality와 retention은 설계 결정이다.

학습 결과

telemetry를 거래 데이터와 분리한다.

실습

late data와 tag 폭발

요구 증거 (미실행이면 미검증)

series 수와 retention 기록

01
JD 연결PROJECT POLICY · cardinality · retention · late data는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: InfluxDB schema design
02
냉정한 실체와 오해
tag cardinality와 retention은 설계 결정이다.
03
선수 지식 / 예상 시간
M05·M10, time-series 기초 · 5시간
04
Mental model
measurement/tag/field/timestamp의 schema는 cardinality·retention·query cost를 결정하며 transaction ledger와 다르다.
05
공장 물리 흐름
durable telemetry receipt→lease→Influx write→downsample/query를 event/device/ingest time와 함께 추적한다.
06
Data ownership
PostgreSQL은 receipt/export 상태, InfluxDB는 파생 telemetry series를 소유하며 생산·품질 원장은 아니다.
07
내부 실행 과정
bounded field/tag를 line protocol로 write하고 retry lease·backoff·UNKNOWN/QUARANTINED를 PostgreSQL에 보존한다.
08
최소 코드 경로
consume_telemetry.py와 Influx provisioning에서 tag/field, bucket, scoped token을 확인한다.
09
Production 확장 경로
retention/downsampling, late backfill, versioned backup/restore, historian boundary, cardinality budget을 설계한다.
10
중요 코드 설명
serial/order/customer ID를 unbounded tag로 쓰지 않고 export failure를 transaction truth와 분리한다.
11
End-to-end trace
late data와 tag 폭발 · 실제 경로: backend/integration/management/commands/consume_telemetry.py
12
Transaction / failure boundary
serial은 고 cardinality tag로 사용하지 않는다.
13
실패 주입
동일 timestamp write collision 또는 tag 폭발
14
구체적 test matrix
Unit: line protocol; integration: PG→Influx; contract: measurement schema; concurrency: lease fencing; load: series/cardinality budget.
15
보안 / 제조 안전
cardinality 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/integration/management/commands/consume_telemetry.py 실행에서 correlation_id, 시간, 상태 전이, latency와 series 수와 retention 기록를 함께 관측한다.
17
제출 산출물
series 수와 retention 기록 · 실행: Query Influx only after telemetry smoke
18
기계적 완료 조건
late write·same timestamp·tag explosion·token denial·retry exhaustion을 재현하고 series/lag/backlog을 기록한다.
19
현업 질문
retention owner, accepted lateness, tag budget, downsample definition, historian/Influx 권한 경계는?
20
시나리오형 자가시험
Grafana에 point가 없지만 MES completion은 있다. 어느 원장을 수정하고 어디를 reconcile하는가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M12Grafana 운영 시야OEE · alert · no-data요구 증거 · dashboard JSON과 alert runbook

냉정한 실체

대시보드 숫자는 원장을 수정하거나 증명하지 않는다.

학습 결과

WIP·FPY·ingest lag·API latency를 구분한다.

실습

slow query·no-data alert

요구 증거 (미실행이면 미검증)

dashboard JSON과 alert runbook

01
JD 연결PROJECT POLICY · OEE · alert · no-data는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: Grafana alerting
02
냉정한 실체와 오해
대시보드 숫자는 원장을 수정하거나 증명하지 않는다.
03
선수 지식 / 예상 시간
M05·M11, metric/alert 기초 · 5시간
04
Mental model
dashboard는 파생 query의 관점이지 원장이 아니다. no-data, zero, stale, error를 분리한다.
05
공장 물리 흐름
cell event→metrics/series→query→panel→alert→on-call→runbook/action의 판단 사슬을 따라간다.
06
Data ownership
Grafana는 query/panel/alert definition을 소유하지만 production·quality transaction을 write하지 않는다.
07
내부 실행 과정
source/query variable→unit/threshold→annotation→no-data policy→alert routing을 owner·runbook·SLO와 연결한다.
08
최소 코드 경로
ops/grafana/provisioning의 datasource/dashboard JSON에서 WIP·ingest lag·backlog panel을 추적한다.
09
Production 확장 경로
FPY·scrap·downtime·OEE·API p95/p99에 definition owner, drill-down, alert inhibition, query budget을 추가한다.
10
중요 코드 설명
dashboard query에 serial/order/customer ID label을 넣지 않고 no-data를 healthy 0으로 바꾸지 않는다.
11
End-to-end trace
slow query·no-data alert · 실제 경로: ops/grafana/provisioning/
12
Transaction / failure boundary
대시보드는 원장의 write 권한을 갖지 않는다.
13
실패 주입
no-data를 0 또는 정상으로 표시
14
구체적 test matrix
Unit: query expression; integration: datasource; contract: units/labels; concurrency: refresh storm; load: dashboard query duration/cardinality.
15
보안 / 제조 안전
OEE 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
ops/grafana/provisioning/ 실행에서 correlation_id, 시간, 상태 전이, latency와 dashboard JSON과 alert runbook를 함께 관측한다.
17
제출 산출물
dashboard JSON과 alert runbook · 실행: Open /grafana after the smoke run
18
기계적 완료 조건
slow query·no-data·stale source·ledger mismatch를 주입하고 alert→runbook→owner 연결을 확인한다.
19
현업 질문
metric 정의, threshold, silence, on-call, dashboard 배포, query budget의 owner는?
20
시나리오형 자가시험
FPY panel이 100%지만 PostgreSQL에 FAIL이 있다. 어떤 query/time-window/definition을 먼저 검사하는가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M13Shop-floor React UXReact · scanner · accessibility요구 증거 · 키보드·320px·focus 검사

냉정한 실체

위험 작업에 optimistic UI를 쓰면 현장 상태를 속일 수 있다.

학습 결과

double submit·stale·offline·role을 표현한다.

실습

operator console 시뮬레이터

요구 증거 (미실행이면 미검증)

키보드·320px·focus 검사

01
JD 연결PROJECT POLICY · React · scanner · accessibility는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: WAI-ARIA APG
02
냉정한 실체와 오해
위험 작업에 optimistic UI를 쓰면 현장 상태를 속일 수 있다.
03
선수 지식 / 예상 시간
React/TypeScript, M03·M06 state machine · 7시간
04
Mental model
UI는 server state의 관측자이자 제한된 command client다. 위험 작업은 optimistic success를 쓰지 않는다.
05
공장 물리 흐름
scanner/touch input→confirm+actor/role→API→server commit→response/stale marker→operator recovery를 추적한다.
06
Data ownership
React state는 편의상 projection이며 API/PostgreSQL 응답만 거래 상태를 확정한다.
07
내부 실행 과정
입력 검증→explicit confirm→pending/double-submit lock→response/error→focus/status announcement을 구분한다.
08
최소 코드 경로
app/lab-experience.tsx의 failure trace, readout, local synthetic capstone operator를 키보드로 실행한다.
09
Production 확장 경로
scanner wedge, offline queue, reconnect conflict, kiosk timeout, role change, WebSocket/SSE stale indicator를 추가한다.
10
중요 코드 설명
API key를 메모리에만 두고 local origin을 강제하며 확인된 다음 synthetic stage만 mutation한다.
11
End-to-end trace
operator console 시뮬레이터 · 실제 경로: app/lab-experience.tsx
12
Transaction / failure boundary
위험 상태를 optimistic success로 표시하지 않는다.
13
실패 주입
offline 요청을 완료로 표시
14
구체적 test matrix
Unit: reducer/validation; integration: API state; contract: error rendering; concurrency: double-click; load: bounded render/API latency; browser: 320px/focus.
15
보안 / 제조 안전
React 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
app/lab-experience.tsx 실행에서 correlation_id, 시간, 상태 전이, latency와 키보드·320px·focus 검사를 함께 관측한다.
17
제출 산출물
키보드·320px·focus 검사 · 실행: npm run build && npm test
18
기계적 완료 조건
KO/EN·hash/filter deep-link·320px·keyboard/focus·offline/error·double-submit을 검사하고 console error 0을 기록한다.
19
현업 질문
glove/scanner 환경, kiosk session, stale 표시, override 권한, accessibility owner, offline policy는?
20
시나리오형 자가시험
POST 후 network가 끊겼다. UI가 success/failure를 단정하지 않고 어떤 상태와 recovery를 보여주는가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M14분산 정확성outbox · DLQ · saga요구 증거 · 재생 후 불변식 유지

냉정한 실체

exactly-once 대신 중복 가능한 전달과 멱등 처리를 설계한다.

학습 결과

outbox·inbox·DLQ·saga·reconcile을 연결한다.

실습

commit 후 ack 전 worker 종료

요구 증거 (미실행이면 미검증)

재생 후 불변식 유지

01
JD 연결PROJECT POLICY · outbox · DLQ · saga는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: Microservices data patterns
02
냉정한 실체와 오해
exactly-once 대신 중복 가능한 전달과 멱등 처리를 설계한다.
03
선수 지식 / 예상 시간
M04·M05·M10, queue/retry 기초 · 9시간
04
Mental model
local commit과 remote observation 사이에는 duplicate·UNKNOWN·reconcile가 필수다. exactly-once는 business 보장이 아니다.
05
공장 물리 흐름
domain transaction→outbox lease→remote side effect→ACK loss→UNKNOWN task→poll/reconcile→append resolution을 따라간다.
06
Data ownership
domain ledger가 business state, outbox/inbox가 delivery evidence, reconciliation task가 미확정 작업을 소유한다.
07
내부 실행 과정
atomic outbox→lease token/fencing→bounded retry+jitter→UNKNOWN/DEAD→manual or observed resolution→audit append를 적용한다.
08
최소 코드 경로
backend/integration/services.py의 enqueue, lease, result, reconciliation을 worker command test와 대조한다.
09
Production 확장 경로
poison/DLQ/replay approval, saga compensation, retry storm budget, schema evolution, graceful worker drain을 추가한다.
10
중요 코드 설명
lease expiry·fencing token이 stale worker write를 막고 semantic hash가 같은 key의 다른 side effect를 차단한다.
11
End-to-end trace
commit 후 ack 전 worker 종료 · 실제 경로: backend/integration/services.py
12
Transaction / failure boundary
UNKNOWN은 관측된 ACK/NACK 뒤에만 해소된다.
13
실패 주입
worker 재시작 후 중복 side effect
14
구체적 test matrix
Unit: backoff/hash; integration: outbox→mock; contract: ACK/NACK; concurrency: lease expiry; load: bounded retry-storm/backlog.
15
보안 / 제조 안전
outbox 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
backend/integration/services.py 실행에서 correlation_id, 시간, 상태 전이, latency와 재생 후 불변식 유지를 함께 관측한다.
17
제출 산출물
재생 후 불변식 유지 · 실행: cd backend && pytest -k outbox
18
기계적 완료 조건
side effect 후 ACK 전 crash·outbox duplicate·poison·lease expiry·timeout UNKNOWN을 recovery한다.
19
현업 질문
retry budget, DLQ replay 승인, compensation owner, UNKNOWN SLA, schema compatibility window는?
20
시나리오형 자가시험
worker A의 lease가 끝난 뒤 worker B가 성공했다. 늦은 A의 ACK를 어떻게 처리하는가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M15테스트 전략pytest · contract · load요구 증거 · 명령·관측·제약이 있는 evidence JSON

냉정한 실체

mock 통과는 실제 PostgreSQL·broker·browser 동작의 증거가 아니다.

학습 결과

unit·integration·contract·failure·load 증거를 분리한다.

실습

대표 failure matrix

요구 증거 (미실행이면 미검증)

명령·관측·제약이 있는 evidence JSON

01
JD 연결PROJECT POLICY · pytest · contract · load는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: pytest docs
02
냉정한 실체와 오해
mock 통과는 실제 PostgreSQL·broker·browser 동작의 증거가 아니다.
03
선수 지식 / 예상 시간
pytest, M03·M05·M14 · 8시간
04
Mental model
테스트는 claim에 맞는 경계와 환경을 관측한다. mock·SQLite·짧은 load의 증거 범위를 한정한다.
05
공장 물리 흐름
재현 fixture→fault injection→log/metric/trace→ledger impact→recovery→regression→runbook을 한 세트로 본다.
06
Data ownership
evidence JSON이 command·environment·observed result·limit을 소유하며 product 효과는 사용자 검증 전 UNVERIFIED다.
07
내부 실행 과정
unit→real PG integration→API/contract→concurrency→failure→browser/a11y→bounded load 순서로 claim을 점진 강화한다.
08
최소 코드 경로
backend/tests와 tests/rendered-html.test.mjs의 assertion을 source path와 대조한다.
09
Production 확장 경로
fake clock, property/state-machine, broker/carrier contract, migration replay, load percentile, accessibility automation을 추가한다.
10
중요 코드 설명
RUN_POSTGRES_INTEGRATION 같은 명시적 gate가 테스트 미실행을 통과로 위장하지 않게 한다.
11
End-to-end trace
대표 failure matrix · 실제 경로: docs/evidence/2026-07-17-local-verification.json
12
Transaction / failure boundary
test 통과를 제품 효과로 확장하지 않는다.
13
실패 주입
fixture 결과를 실제 통합 증거로 표시
14
구체적 test matrix
Unit: invariant; integration: real services; contract: schema/signature; concurrency: race; load: rate/duration/concurrency/resources; browser: focus/320px.
15
보안 / 제조 안전
pytest 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
docs/evidence/2026-07-17-local-verification.json 실행에서 correlation_id, 시간, 상태 전이, latency와 명령·관측·제약이 있는 evidence JSON를 함께 관측한다.
17
제출 산출물
명령·관측·제약이 있는 evidence JSON · 실행: npm run typecheck && npm run lint && npm test
18
기계적 완료 조건
test별 expected/observed/duration/count/environment/limitation을 evidence ledger에 남기고 Function·Quality·Product를 분리한다.
19
현업 질문
CI에서 건너뛰는 suite, flaky owner, prod-like dataset, restore/browser 검증, failure budget은?
20
시나리오형 자가시험
32개 unit test가 통과했다. 어떤 주장까지만 할 수 있고 어떤 주장은 아직 불가능한가?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M16Docker·Nginx·CI/CDCompose · Nginx · rollback요구 증거 · config·health·shutdown 결과

냉정한 실체

health와 readiness, build와 deploy, rollback과 restore는 별개다.

학습 결과

non-root·timeout·migration·shutdown을 검증한다.

실습

Compose clean build와 Nginx timeout

요구 증거 (미실행이면 미검증)

config·health·shutdown 결과

01
JD 연결PROJECT POLICY · Compose · Nginx · rollback는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: Docker Compose
02
냉정한 실체와 오해
health와 readiness, build와 deploy, rollback과 restore는 별개다.
03
선수 지식 / 예상 시간
Docker/HTTP/Linux 기초, M03 · 8시간
04
Mental model
immutable build artifact, runtime config, migration, rollout, rollback, data restore는 서로 다른 상태 기계다.
05
공장 물리 흐름
source→multi-stage image→Compose network→migration→readiness→Nginx traffic→shutdown/rollback을 추적한다.
06
Data ownership
image digest·config·secret·migration·backup은 별도 owner를 갖고 database volume은 container lifecycle와 분리된다.
07
내부 실행 과정
pinned build→non-root/read-only→migration owner→health/readiness→Nginx timeout/limit→graceful drain→rollback/restore를 검증한다.
08
최소 코드 경로
compose.yaml, Dockerfile, nginx config에 `docker compose --env-file .env.example config --quiet`를 실행한다.
09
Production 확장 경로
SBOM/scan, immutable registry, canary, secret rotation, disk alert, backup/restore drill, Windows/macOS/Linux clean install을 추가한다.
10
중요 코드 설명
readiness dependency와 분리된 migrator/app/observer role이 startup race와 과도한 DB 권한을 줄인다.
11
End-to-end trace
Compose clean build와 Nginx timeout · 실제 경로: compose.yaml
12
Transaction / failure boundary
readiness 전 traffic을 받지 않고 migration owner를 분리한다.
13
실패 주입
clean cache에서 로컬 image pull 시도
14
구체적 test matrix
Unit: config parser; integration: clean Compose; contract: health/readiness; concurrency: rolling shutdown; load: Nginx/API p95; recovery: restore.
15
보안 / 제조 안전
Compose 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
compose.yaml 실행에서 correlation_id, 시간, 상태 전이, latency와 config·health·shutdown 결과를 함께 관측한다.
17
제출 산출물
config·health·shutdown 결과 · 실행: docker compose --env-file .env.example config --quiet
18
기계적 완료 조건
clean build·health·seed·non-root·secret scan·shutdown·migration replay·restore와 exact image/version을 기록한다.
19
현업 질문
deploy approval, migration owner, timeout 계층, secret rotation, disk/backup alert, rollback/restore 책임은?
20
시나리오형 자가시험
health는 200이지만 migration이 안 됐다. traffic을 막아야 할 probe와 rollback 순서는?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

M17첫 30/60/90일gemba · runbook · handoff요구 증거 · bounded fix와 운영 handoff

냉정한 실체

첫 달의 대규모 변경보다 시스템·사람·원장 관찰이 먼저다.

학습 결과

질문·추적 객체·금지 변경·성공 증거를 정한다.

실습

한 serial의 end-to-end shadow

요구 증거 (미실행이면 미검증)

bounded fix와 운영 handoff

01
JD 연결PROJECT POLICY · gemba · runbook · handoff는 목표 스택에서 만든 학습 가설이다. 회사 적용은 미확인. 공식 lens: NIST OT Security
02
냉정한 실체와 오해
첫 달의 대규모 변경보다 시스템·사람·원장 관찰이 먼저다.
03
선수 지식 / 예상 시간
M00–M16 지도의 개요 · 4시간 계획 + 90일 수행
04
Mental model
첫 90일은 rewrite 일정이 아니라 owner·ledger·incident·rollback을 증거로 확장하는 discovery funnel이다.
05
공장 물리 흐름
plant walk→안전→order/serial/shipment shadow→incident/deploy shadow→bounded fix→handoff의 순서를 지킨다.
06
Data ownership
사람·시스템·data owner map과 unknown list를 유지하고 승인 전에 운영 definition을 바꾸지 않는다.
07
내부 실행 과정
0–30 observe/read-only, 31–60 incident shadow+contract test+small fix, 61–90 SLO/reconcile/migration+handoff로 점진한다.
08
최소 코드 경로
docs/FIRST-90-DAYS.md에 한 serial의 owner·질문·문서·금지 변경·성공 증거를 채운는다.
09
Production 확장 경로
SLO/alert, repeat-incident root cause, migration/restore drill, on-call/runbook, operator acceptance를 bounded slice에 연결한다.
10
중요 코드 설명
firstNinety의 actions/avoid/proof가 각 기간의 행동을 산출물과 금지 변경에 묶는다.
11
End-to-end trace
한 serial의 end-to-end shadow · 실제 경로: docs/FIRST-90-DAYS.md
12
Transaction / failure boundary
owner·rollback·측정 없는 변경을 만들지 않는다.
13
실패 주입
첫 달 platform rewrite
14
구체적 test matrix
Unit: checklist completeness; integration: one-serial shadow; contract: owner sign-off; concurrency: conflicting priorities; load: bounded backlog review.
15
보안 / 제조 안전
gemba 입력은 합성 식별자와 least-privilege actor로 제한한다. PLC·안전 interlock·회사 endpoint에는 명령하지 않는다.
16
Log / metric / trace / profile
docs/FIRST-90-DAYS.md 실행에서 correlation_id, 시간, 상태 전이, latency와 bounded fix와 운영 handoff를 함께 관측한다.
17
제출 산출물
bounded fix와 운영 handoff · 실행: Trace one synthetic serial before proposing changes
18
기계적 완료 조건
90일 plan에 사람·질문·문서·추적 객체·산출물·금지 변경·증거·unknown을 모두 기록한다.
19
현업 질문
plant safety, change approval, on-call, incident history, data owner, deploy/rollback, success definition은 누가 결정하는가?
20
시나리오형 자가시험
첫 주에 routing rewrite 요청을 받았다. 수정 전에 필요한 owner·trace·rollback·성공 증거는?

체크포인트는 진행 기록이며 검증 결과가 아닙니다.

FIRST 90 DAYS

입사 후, 먼저 바꾸지 말아야 할 것

DAY 0–30

관찰하고 원장을 찾기

할 일

plant walk와 안전 교육
한 work order·serial·shipment 추적
data owner·on-call·incident map
read-only query부터 시작

금지 변경

routing·recipe·PLC·대규모 migration 변경

성공 증거

사람·시스템·원장 지도와 미확인 목록

DAY 31–60

문제를 따라가고 작은 수정

할 일

issue·배포·복구 shadow
contract test 한 개 추가
느린 query 또는 alert 개선
rollback·reconcile 동반 수정

금지 변경

owner 없는 공유 schema·metric label 확장

성공 증거

재현·수정·회귀 test·runbook

DAY 61–90

bounded vertical slice 인계

할 일

반복 장애 root cause
SLO·alert·reconcile backlog
migration·restore drill
운영자와 handoff 검증

금지 변경

실사용 증거 없이 platform rewrite 선언

성공 증거

실행 가능한 slice와 owner 승인

SCENARIO CHECK

외웠는지 말고 판단할 수 있는지 확인

01carrier manifest 요청이 timeout 됐다. 재시도 전에 어떤 상태를 기록해야 하는가?

FAILED가 아니라 UNKNOWN. idempotency key로 carrier를 조회하고 reconciliation 결과가 확인된 뒤 상태를 확정한다.

02MQTT QoS 2를 쓰면 생산 수량 중복 증가가 사라지는가?

아니다. QoS는 한 MQTT hop의 전달 의미다. business event_id와 원장 transaction에서 별도 dedupe가 필요하다.

03Grafana의 생산 완료 수가 PostgreSQL보다 크다. 어느 쪽이 자동으로 맞는가?

자동으로 단정할 수 없다. 거래 원장은 PostgreSQL이지만 ingestion·query·definition 차이를 trace하고 reconciliation해야 한다.

SOURCE MATRIX

공식 자료와 실행 증거를 분리

지원 상태와 버전 주장은 공식 문서에 연결합니다. 이 페이지의 전체 근거표는 저장소 문서에 있습니다.

SPECPython 3.14.6 SPECDjango 5.2 LTS SPECDjango REST Framework SPECPostgreSQL versioning SPECReact versions SPECMQTT 5.0 SPECOPC UA SPECISA-95 SPECInfluxDB OSS v2 SPECGrafana support RECOMMENDED PRACTICEOWASP API Security RECOMMENDED PRACTICENIST SP 800-82r3 SPECGS1 EPCIS 2.0

실행 산출물Django API · React UI · PostgreSQL · MQTT simulator · InfluxDB · Grafana · Compose · Nginx

Capstone 순서 보기