레퍼런스 아키텍처: 한 스택, 계층별로

📍 현재 위치: 청사진입니다. 명령어를 단 한 줄도 입력하기 전에, 우리는 플랫폼 전체를 한 페이지에 펼쳐 봅니다. 모든 계층, 모든 오픈소스 도구, 모든 ISA-95 레벨을 펼쳐 놓고, 오픈소스가 끝나고 상용 시스템이 시작되는 경계선을 그어 봅니다.

서문은 여러분에게 한 가지 약속을 했습니다. 저장소(repository) 하나를 클론(clone)해서, 계층별로 오픈소스로 동작하는 생물공정 데이터 플랫폼(bioprocess data platform)을 만들어 보겠다는 약속이었습니다. 이 장은 바로 그 플랫폼의 지도입니다. 공사를 시작하기 전에 벽에 붙여 두는 설계 도면, 즉 이후 모든 장이 조용히 다시 가리키게 될 그 도면이라고 생각하면 됩니다.

아직은 아무것도 실행하지 않습니다. 실행은 2장에서 합니다. 여기서는 더 어려운 일을 합니다. 첫 조각을 만들기 전에, 스택 전체의 형태를 여러분이 볼 수 있게 하는 일입니다. pH 프로브(probe)에서 태어난 숫자 하나가 어떻게 메시지 버스(message bus)를 거쳐 히스토리안(historian)에 안착하고, 배치 기록(batch record)에 꿰매지고, 지식 그래프(knowledge graph)의 트리플(triple)이 되며, 마침내 규제 제출 문서(regulatory submission)를 조립하는 데 도움을 주는지를 말입니다.

쉽게 말하면

8층짜리 건물을 떠올려 보세요. 1층은 원자재(센서 측정값)가 도착하는 하역장입니다. 그 위의 각 층은 의미를 하나씩 더합니다. 어떤 층은 배송물에 라벨을 붙이고 경로를 정해 주고, 어떤 층은 그것들을 창고에 보관하고, 어떤 층은 모든 상자를 그것이 속한 주문과 대조하며, 어떤 층은 검사관이 어떤 상자든 그 출처까지 추적할 수 있게 합니다. 맨 위 층들은 규제 당국이 방문하는 곳입니다. 이 장에서 우리가 할 일은 평면도를 그리고, 각 층에 배치된 오픈소스 도구의 이름을 붙이고, 그리고 빨간 잉크로 표시하는 것입니다. 무료 인력만으로는 검사를 통과할 수 없어 면허를 가진 전문가를 고용해야 하는 층이 어디인지를 말입니다.

이 장에서 다루는 내용

위에서 아래로 이어지는 계층형 청사진, 그리고 동반 저장소(companion repo)의 빌드 순서가 왜 그것을 따르는지.
각 계층을 ISA-95 / 퍼듀(Purdue) 레벨, 그리고 우리가 그 계층에 고른 오픈소스 도구에 매핑하기.
정직한 OSS↔상용 경계가 어디에 떨어지는지, 그리고 왜 거기에 떨어지는지.
스택 전체를 조인 가능(joinable)하게 만드는 단 하나의 설계 결정: 히스토리안과 배치 모델(batch model)이 같은 데이터베이스 안에 사는 것.
컴포넌트 및 라이선스 목록, 그리고 모든 장을 관통하며 되풀이되는 데이터 무결성(data integrity) 질문.

한 페이지짜리 청사진

플랫폼의 모든 계층은 동일한 직무 명세를 가집니다. 아래 계층에서 데이터를 받아, 한 종류의 의미를 더하고, 위로 넘긴다. 아래에서부터 읽어 보세요.

계층	무엇을 더하는가	ISA-95 / 퍼듀 레벨	이 책의 OSS 도구
엣지 연결(Edge connectivity)	센서를 읽는 표준적이고 자기 기술적인 방식	Level 0–2 (센서, 제어)	OPC UA (asyncua)
메시지 버스(Message bus)	모든 값의 이름 붙은 실시간 스트림	Level 2–3 경계	MQTT + Sparkplug B (Mosquitto)
히스토리안 / TSDB	대규모로 내구성 있고 질의 가능한 시계열	Level 3	TimescaleDB hypertable
배치 및 장비 모델(Batch & equipment model)	숫자에 의미를 부여하는 맥락	Level 3	PostgreSQL (ISA-88/95)
맥락화(Contextualization)	조인: 이 값, 이 배치, 이 단계	Level 3	SQL views
시맨틱(Semantics)	시스템을 가로지르는 기계 추적 가능한 계보	Level 3–4	RDF / SPARQL (Apache Jena Fuseki)
컴플라이언스 / 신뢰(Compliance / trust)	감사 추적된 진실의 기록	Level 3–4	Postgres audit + hash chain
분석(Analytics)	예측과 공정 이해	Level 3–4	Python (SPC, PLS soft-sensor)

ISA-95 — 기업 시스템과 제어 시스템을 통합하기 위한 국제 표준(IEC 62264)으로, 2025년 판에서 갱신되었습니다 — 에 대한 매핑은 장식이 아닙니다 [1]. 그것은 각 도구가 어디에 정당하게 사는지를, 그리고 결정적으로 그들 사이의 경계가 어디에 놓이는지를 알려 줍니다. 이 표 전체에서 가장 중요한 단 하나의 경계는 Level 2(실제로 바이오리액터(bioreactor)를 돌리는 제어 시스템)와 Level 3(이 책에서 우리가 만드는 모든 것) 사이의 경계입니다. 검증된(validated) 제어 시스템은 신성합니다. 우리는 결코 그 안으로 쓰지 않습니다. 우리는 그것으로부터 읽습니다.

그 원칙에는 이름이 있습니다. NAMUR — 유럽 자동화 기술 사용자 협회 — 는 바로 이를 위해 NAMUR 오픈 아키텍처(NAMUR Open Architecture, NOA) 개념을 발표했습니다. 검증된 핵심 공정 제어 시스템을 변경하지 않으면서 모니터링, 히스토리화, 최적화를 먹여 주는 두 번째의 읽기 위주(read-mostly) 데이터 채널입니다 [2]. 이 책의 거의 모든 것은 그 경계선의 NOA 쪽에 삽니다. 우리가 "우리는 결코 DCS를 건드리지 않는다"고 말하는 것을 들을 때, 그것을 축복하는 표준이 바로 NOA입니다.

아래의 바이오리액터 센서에서 위의 규제 제출 문서까지 이어지는 수직 계층형 스택: 엣지 연결(OPC UA), 메시지 버스(MQTT/Sparkplug), 히스토리안(TimescaleDB), 배치 모델(PostgreSQL ISA-88/95), 맥락화(SQL views), 시맨틱(SPARQL), 컴플라이언스(audit + hash chain), 그리고 분석. 각 계층에는 그 오픈소스 도구와 ISA-95 레벨이 표시되어 있으며, 상단의 컴플라이언스 띠는 순수 오픈소스가 검증과 상용 시스템에 자리를 내주는 지점을 표시하기 위해 음영 처리되어 있다.

레퍼런스 아키텍처, 아래에서 위로. 데이터는 위로 흐른다. 각 계층은 한 종류의 의미를 더해 다음 계층으로 넘긴다. 음영이 없는 계층들은 노트북에서 직접 만들고 실행하는 순수 오픈소스이다. 제출 문서 근처의 음영 처리된 컴플라이언스 띠는 정직한 하이브리드이다. 검증, 자격을 갖춘 서명, 그리고 벤더 책임이라는 GxP의 마지막 1마일로, 오픈소스만으로는 전달할 수 없는 영역이다. Original diagram by the authors, created with AI assistance.

같은 스택, 데이터플로우로 본다면

표는 아래에서 위로, 여러분이 만드는 순서대로 읽힙니다. 데이터는 물론 반대 방향으로 흐릅니다. 다음은 같은 아키텍처를 바이오리액터 BR101 위의 pH 측정값 하나가 떠나는 여정으로 나타낸 것입니다.

히스토리안(D)과 배치 모델(E)이 나란히 놓여 있고, 화살표가 아니라 그냥 선으로 연결되어 있다는 점에 주목하세요. 그것이 이 설계의 핵심(keystone)이며, 그 자체로 별도의 절을 가질 자격이 있습니다.

히스토리안과 배치 모델을 위한 하나의 데이터베이스

대부분의 시설에서 히스토리안과 배치/관계형 세계는 서로 다른 벤더의 서로 다른 두 제품이며, 이 둘을 조인하는 것은 누군가가 돌봐야 하는 야간 ETL 작업입니다. 우리는 그 분리를 거부합니다. 동반 저장소가 데이터베이스를 어떻게 정의하는지, examples/platform/compose/compose.yaml에서 보세요.

services:
  # --- core --------------------------------------------------------------
  postgres:
    # timescale/timescaledb IS PostgreSQL + TimescaleDB, so the historian
    # hypertable and the ISA-88/95 batch model live in one joinable database.
    image: timescale/timescaledb:2.17.2-pg17
    profiles: ["core"]
    environment:
      POSTGRES_USER: ${POSTGRES_USER:-bioproc}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-bioproc}
      POSTGRES_DB: ${POSTGRES_DB:-bioproc}
    ports: ["5432:5432"]
    volumes:
      - pgdata:/var/lib/postgresql/data
      - ../db:/docker-entrypoint-initdb.d:ro   # 00-60 schema files run on first init

TimescaleDB는 별도의 데이터베이스가 아니라, PostgreSQL 확장(extension)입니다. 그 핵심 추상화인 하이퍼테이블(hypertable) 은 시간에 따라 자동으로 청크(chunk)로 파티셔닝되는 평범한 PostgreSQL 테이블입니다. 그래서 고속 센서 데이터가 다른 관계형 테이블과 똑같이 동작하면서도 대규모에서 빠른 속도를 유지합니다 [3]. 히스토리안이 바로 PostgreSQL이기 때문에, 시계열과 배치 맥락은 서로 대화하는 척하는 두 시스템이 아닙니다. 그것들은 평범한 SQL로 조인할 수 있는 하나의 데이터베이스 안의 두 스키마(schema)입니다. 히스토리안은 ts 스키마에, 배치 모델은 s88 스키마에 삽니다. 다음은 하이퍼테이블로, examples/platform/db/20-historian.sql에서 가져온 것입니다.

CREATE TABLE ts.sensor_reading (
    ts       timestamptz      NOT NULL,
    tag      text             NOT NULL,
    value    double precision,
    unit     text,
    quality  smallint         NOT NULL DEFAULT 192,  -- OPC UA: 192 Good, 64 Uncertain, 0 Bad
    batch_id text
);

SELECT create_hypertable('ts.sensor_reading', 'ts', chunk_time_interval => INTERVAL '1 day');

저 quality 컬럼은 작지만 하중을 견디는 기둥입니다. OPC UA — 센서로부터 Level 3까지 데이터와 그 메타데이터를 실어 나르는 플랫폼 독립적이고 서비스 지향적인 프로토콜 [4] — 는 모든 값에 상태 코드(status code)를 붙입니다. Good에는 192, Uncertain에는 64, Bad에는 0입니다. 우리는 그것을 히스토리안까지 내내 보존합니다. 나중에 검사관이 어떤 값이 기록된 그 순간에 신뢰할 만했는지를 물을 때, 답은 추측이 아니라 하나의 컬럼입니다. 이것은 ALCOA+ 속성인 "Original(원본)"을 구체화한 것입니다. 이 책의 나머지를 떠받치는 데이터 무결성 가이던스는 원본 측정값과 그 맥락이 손상 없이 살아남기를 기대합니다 [5].

숫자를 지식으로 바꾸는 계층

ts.sensor_reading의 한 행은 BR101.DO.PV = 41.3 %sat at 2026-03-08T11:00:00Z라고 말합니다. 사실이긴 하지만, 그것만으로는 거의 쓸모가 없습니다. 그 배치는 성장 중이었나요, 생산 중이었나요? 이 용존산소(DO) 측정값은 그 단계에 대해 통제된 범위 안에 있었나요? 답하려면 배치 모델이 필요합니다. 맥락화 계층은 그것을 공급하는 조인이며, examples/platform/db/60-views.sql에서 한 번 정의됩니다.

-- A reading with its full batch + phase context.
CREATE OR REPLACE VIEW s88.v_batch_sensor AS
SELECT r.ts, r.tag, r.value, r.unit, r.quality, r.batch_id,
       b.product_id, b.recipe_id, b.unit_id,
       bp.phase_id, ph.name AS phase_name
FROM ts.sensor_reading r
JOIN s88.batch b              ON b.batch_id = r.batch_id
LEFT JOIN s88.batch_phase bp  ON bp.batch_id = r.batch_id
     AND r.ts >= bp.start_ts AND (bp.end_ts IS NULL OR r.ts < bp.end_ts)
LEFT JOIN s88.phase ph        ON ph.phase_id = bp.phase_id;

이 단 하나의 뷰(view)는 모든 것을 하나의 데이터베이스에 담아 둔 것의 아키텍처적 보상입니다. 그것은 시계열 측정값(ts.sensor_reading)을 그것이 속한 배치(s88.batch)에, 그리고 그 순간에 활성화되어 있던 ISA-88 단계(s88.batch_phase → s88.phase)에 조인합니다. 배치 모델 자체는 ISA-88 / ISA-95 계층 구조를 따릅니다. 기업 → 사이트 → 영역 → 유닛, 그리고 레시피 → 오퍼레이션 → 단계로, examples/platform/db/10-isa88-95.sql에 모델링되어 있습니다. 저장소는 그것을 구체적인 유가식(fed-batch) CHO 라인으로 examples/platform/db/seed/seed_cho_line.sql에서 시드(seed)합니다.

INSERT INTO s88.unit VALUES
    ('BR101',         'UPSTREAM',   'Production Bioreactor 101', 'bioreactor',     'Sartorius', 'Biostat STR 50'),
    ('N1SEED',        'UPSTREAM',   'N-1 Seed Bioreactor',       'bioreactor',     'Sartorius', 'Biostat STR 10'),
    ('PA01',          'DOWNSTREAM', 'Protein A Capture Skid',    'chromatography', 'Cytiva',    'AKTA process'),
    ('TFF01',         'DOWNSTREAM', 'UF/DF Skid',                'tff',            'Cytiva',    'AKTA flux'),
    ('FILL-LINE-01',  'FILL',       'Aseptic Fill Line',         'fill_line',      'Bausch+Stroebel', 'KSF');

이것이 데이터로 표현한 우리의 실행 사례입니다. 생산 바이오리액터 하나, N-1 시드, 단백질 A(Protein A) 캡처 스키드, UF/DF 스키드, 그리고 충전 라인입니다. 트릴로지 전체가 따라가는 유가식 CHO + 단백질 A 단일클론항체(monoclonal antibody, mAb) 공정입니다. (같은 라인의 관류(perfusion) / 다중 컬럼 연속 변형판은 이후 장들에서 사이드바로 등장합니다. 스키마는 의도적으로 동일하게 만들어, 연속 공정 사례가 모든 테이블을 재사용하도록 했습니다.) 맥락화 뷰가 일단 존재하면, 한때는 고고학 프로젝트였던 질문 — "골든 배치(golden batch)에서 용존산소가 단계별로 어떻게 움직였나?" — 은 make contextualize가 s88.v_batch_sensor에 대해 실행하는 한 줄짜리 쿼리가 됩니다.

메시지 버스: 점대점 연결의 엉킴이 아닌, 이름 붙은 스트림

센서와 히스토리안 사이에 메시지 버스가 자리합니다. 그 역할은 점대점(point-to-point) 연결의 혼돈을, 어떤 소비자(consumer)든 구독(subscribe)할 수 있는 하나의 이름 붙은 실시간 스트림으로 바꾸는 것입니다. 우리는 경량 발행/구독(publish/subscribe) 프로토콜인 MQTT를 사용하며, 이를 Mosquitto 브로커(broker)가 실어 나릅니다. 같은 compose 파일에 핀(pin)되어 있습니다.

  mosquitto:
    image: eclipse-mosquitto:2.0.22
    profiles: ["core"]
    ports: ["1883:1883"]
    volumes:
      - ../mosquitto/mosquitto.conf:/mosquitto/config/mosquitto.conf:ro

하지만 가공되지 않은 MQTT 토픽(topic)은 무법지대이고, 무법지대는 데이터 무결성의 적입니다. 그래서 MQTT 위에 우리는 Sparkplug B를 채택합니다. 표준화된 토픽 네임스페이스(namespace), 압축된 페이로드(payload), 그리고 — 가장 중요하게는 — 탄생/소멸(birth/death) 세션 상태를 부과하는 Eclipse 명세로, 소비자가 디바이스가 살아 있는지와 무엇을 보고하고 있는지를 항상 알 수 있게 합니다 [6]. Sparkplug는 4장에서 만나게 될 "통합 네임스페이스(Unified Namespace)" 개념의 배후 메커니즘입니다. 공장 전체를 위한 하나의 자기 기술적이고 브로커가 매개하는 주소 공간이지요. OPC UA → Sparkplug 수집기(collector)는 5장에서 만들 것입니다. 여기서의 요점은 그저 이 버스가 즉흥적인 배관이 아니라 표준을 갖춘 이름 붙은 계층이라는 것입니다.

오픈소스가 멈추는 곳: 정직한 경계

이제 빨간 잉크입니다. 데이터플로우를 다시 위로 따라가면서, 순수 오픈소스가 길이 끊기는 지점이 어디인지 지켜보세요.

캡처, 히스토리화, 맥락화, 시각화, 추론 — 아래쪽 여섯 계층 — 은 순수하고 실행 가능한 오픈소스입니다. 여러분은 그 전부를 노트북에서 만들 것이고, make test가 그것이 동작함을 증명합니다. 그것이 대략 플랫폼의 첫 80%입니다.

컴플라이언스 및 신뢰 띠는 정직한 하이브리드가 시작되는 곳입니다. 어떤 오픈소스 컴포넌트도 별도의 작업 없이 그대로 21 CFR Part 11을 준수하지 않으며 [7] — 평행한 EU Annex 11 체제도 충족하지 않습니다 — 다운로드만으로 그렇게 되지도 않습니다. 우리는 신뢰 계층 — PostgreSQL 안의 시스템 버전 관리(system-versioned) 감사 추적과 암호학적 해시 체인(hash chain)(20–21장) — 을 시연하며, 그것은 진정으로 유용합니다. 변조를 탐지 가능하게 만들기 때문입니다. 그러나 그것이 변조를 불가능하게 만들지는 않습니다. 데이터베이스 슈퍼유저(superuser)는 감사 행을 쓰는 트리거(trigger)를 비활성화할 수 있습니다. Part 11 준수는 어떤 단일 도구의 속성이 아니라 검증된 시스템과 그 절차의 속성입니다 [7]. 현대의 가이던스는 그 방법론에 동의합니다. GAMP 5 제2판은 위험 기반의, 비판적 사고(critical-thinking) 접근법(그리고 오픈소스 부록)을 추가하여 OSS가 검증된 라이프사이클 안에서 GxP에 사용될 수 있게 합니다 [8]. 그리고 FDA의 컴퓨터 소프트웨어 보증(Computer Software Assurance) 가이던스는 그 라이프사이클을, 문서를 위한 문서가 아니라 로그, 감사 추적, 공급자 증거를 활용하는 위험 비례적 보증으로 재구성합니다 [9]. 그것이 바로 우리가 보여 주는 작업이며, 어떤 도구도 준수된 채로 도착하지 않는 정확한 이유입니다.

상용 시스템은 하이브리드의 다른 한쪽입니다. AVEVA PI, SAP, Emerson DeltaV, Siemens, 그리고 상용 LIMS는 노트북에서 실행될 수 없고 라이선스로 잠겨 있습니다. 우리가 작성하는 통합 코드는 진짜입니다. 그 상대편은 같은 API 계약과 문서화된 프로덕션 교체(production swap)를 갖춘, 명확히 라벨이 붙은 목(mock)입니다(17–19장). 그리고 아키텍처 전체가 걸쳐 있는 OT/IT 경계 자체가 하나의 보안 경계선이며, 이는 ISA/IEC 62443 — 퍼듀 레벨 사이의 어디에 방화벽, 데이터 다이오드(data diode), 또는 단방향 NOA 채널이 속하는지를 말해 주는 존-앤-컨듀잇(zones-and-conduits) 표준(이전의 ISA-99) — 에 의해 통제됩니다 [10]. 마지막 장은 각 경계에서 여러분이 정확히 무엇을 맞바꾸는지를 한 줄씩 채점합니다.

컴포넌트 및 라이선스 목록

우리가 특정 도구를 추천하기 때문에, 여러분에게 그것들의 라이선스 — 그리고 2026년의 함정 — 를 빚지고 있습니다. examples/platform/compose/compose.yaml의 핵심 스택은 작고 의도적입니다.

컴포넌트	핀된 이미지	라이선스	2026년 참고 사항
PostgreSQL + TimescaleDB	`timescale/timescaledb:2.17.2-pg17`	PostgreSQL License + Apache-2.0 (OSS build)	우리는 오직 Apache-2 기능만 사용합니다. TSL 컬럼스토어/압축/HA는 우리가 피하는 함정입니다.
MQTT 브로커	`eclipse-mosquitto:2.0.22`	EPL-2.0 / EDL-1.0	재현성을 위해 안정적인 2.0.x 라인에 핀했습니다.
대시보드	`grafana/grafana-oss:11.4.0`	AGPL-3.0	로컬 사용은 괜찮습니다. 재배포하거나 타인을 위한 SaaS로 호스팅하면 AGPL 의무가 발동됩니다.
트리플스토어	`apache/jena-fuseki:5.2.0`	Apache-2.0	다이제스트(digest)를 검증하세요. 커뮤니티 이미지가 이동했습니다.
메트릭 저장소	`victoriametrics/victoria-metrics:v1.108.1`	Apache-2.0	v3 라이선스 전환을 피하려고 InfluxDB 3 대신 탑재했습니다.

모든 이미지는 태그(tag)로 핀되어 있고, 저장소의 락 파일(lock file)에서는 다이제스트로도 핀되어 있습니다. 그래서 실행 중인 스택, 라이선스 목록, 그리고 22장이 검증을 위해 생성하는 공급자 등록부(supplier register)가 조용히 서로 어긋날 수 없습니다. 히스토리안의 OSS 입장은 examples/platform/db/20-historian.sql의 스키마 주석에 바로 적혀 있습니다.

-- Only Apache-2/Community features are used (no TSL columnstore/compression),
-- so the stack stays cleanly open-source — the trade-off Chapter 13 discusses.

저 단 하나의 주석이 이 책의 라이선스 철학 전체를 담고 있습니다. 우리는 오픈된 기능을 의도적으로 사용하고 독점적인 것은 큰 소리로 표시합니다. 그래서 "오픈"이라는 이유로 채택한 도구가 나중에 여러분을 기습하지 않도록 말입니다.

왜 중요한가

아키텍처 다이어그램은 장식이 아니라 결정 기록(decision record)입니다. 이후의 모든 장은 이 하나의 공유된 청사진 위에 놓인 얇은 조각입니다. 동반 저장소는 정확히 "두꺼운 공유 플랫폼 위의 얇은 장들(thin chapters over a thick shared platform)" 로 만들어졌습니다. 5장은 히스토리안을 재정의하지 않습니다. 위에서 본 ts.sensor_reading에 씁니다. 14장은 조인을 발명하지 않습니다. s88.v_batch_sensor 뷰를 확장합니다. 20장은 새 데이터베이스를 덧붙이지 않습니다. 이미 거기 있는 스키마들 옆에 감사 스키마를 추가합니다. 계층들이 한 번 정의되고 재사용되기 때문에, 빌드 순서가 곧 아키텍처입니다. make up은 코어(데이터베이스, 브로커, 대시보드)를 띄우고, make seed는 ISA-88/95 라인을 적재하며, 그 이후의 모든 장은 프로파일(profile)을 하나씩 더 켭니다.

청사진을 일찍 제대로 잡는 것은 또한 규제된 끝단을 애초에 달성 가능하게 만드는 일입니다. 만약 히스토리안과 배치 모델이 서로 연결되지 않은 두 제품이었다면, 맥락화 뷰 — 그리고 그 위에 세워진 모든 감사 추적, 계보 쿼리, 골든 배치 비교 — 는 한 줄짜리 SQL 조인이 아니라 깨지기 쉬운 ETL 파이프라인이 되었을 것입니다. 아키텍처는 3주가 걸리는 배치 조사와 한나절이 걸리는 배치 조사 사이의 차이입니다.

실제 현장에서는

현대의 바이오 제조 시설에 들어가 보면, 비록 아무도 그것을 벽에 그려 놓지 않았더라도, 바로 이 계층 구조를 발견하게 됩니다. 스키드에는 OPC UA 서버가 있고, 히스토리안(흔히 상용)이 있으며, 배치 모델을 담은 관계형 MES가 있고, 그리고 — 점점 더 — Grafana와 PostgreSQL 같은 오픈소스 도구가 검증된 시스템과 나란히 돌아갑니다. 업계가 실제로 돈을 지불하는 기술은 그들 사이의 경계가 어디에 놓이고 왜 거기에 놓이는지를 아는 것입니다. ISA-95는 그 경계에 어휘를 줍니다 [1]. ISA/IEC 62443은 OT/IT 경계선에 통제 수단을 줍니다 [10]. NOA는 읽기 위주의 분석 채널에 정당성을 줍니다 [2].

제도적 추진력은 실재합니다. NIIMBL — 바이오 의약품 제조 혁신을 위한 미국의 민관 합동 국립 연구소(National Institute for Innovation in Manufacturing Biopharmaceuticals) — 는 정확히 이런 종류의 역량을 가속하기 위해 존재합니다. 델라웨어 대학교와 함께하는 그 파일럿 규모 cGMP(current Good Manufacturing Practice, 현행 우수 제조 관리 기준) 시설인 SABRE는 2024년 4월에 착공했으며 2026년 중반 기준으로 공사 중입니다. SABRE는 데이터 프로그램이 아니라 시설입니다. 하지만 그런 시설들이야말로 이런 아키텍처가 실제의 규제된 생산에 맞서 단련되는 곳입니다. 그리고 그런 모든 공장에서 같은 질문이 되풀이됩니다. 이 책이 매 장마다 되돌아가는 질문입니다. 어느 계층이 신뢰할 수 있고 감사 추적된 진실의 기록을 보유하는가? 여러분이 방금 읽은 청사진은 그 기록이 어디에 살 수 있는지에 대한 우리의 답입니다. 신뢰 장들은 오픈소스가 그것을 어디까지 데려갈 수 있고 어디서 데려갈 수 없는지에 대한 우리의 정직한 회계입니다.

핵심 용어

레퍼런스 아키텍처(Reference architecture): 플랫폼 전체의 계층형 청사진으로, 각 계층은 한 종류의 의미를 더하고 ISA-95 레벨과 오픈소스 도구에 매핑된다.
ISA-95(IEC 62264): 기업 시스템과 제어 시스템을 통합하기 위한 표준 계층 모델(Levels 0–4)로, 각 도구를 배치하는 데 사용된다.
퍼듀 모델 / ISA-99 → ISA/IEC 62443(Purdue model): OT/IT 계층 구조와 그 존-앤-컨듀잇 보안 표준으로, 경계 통제 수단이 어디에 속하는지를 정의한다.
NAMUR 오픈 아키텍처(NAMUR Open Architecture, NOA): 검증된 제어 시스템을 결코 변경하지 않으면서 모니터링과 최적화를 위한 두 번째의 읽기 위주 데이터 채널이라는 개념.
OPC UA: 각 값과 그 품질 상태를 센서에서 애플리케이션까지 실어 나르는 플랫폼 독립적이고 자기 기술적인 프로토콜.
MQTT / Sparkplug B: 경량 발행/구독 전송(Mosquitto)과, 그것에 표준화된 네임스페이스와 탄생/소멸 상태를 부여하는 명세로, 통합 네임스페이스의 기반이 된다.
하이퍼테이블(Hypertable): 시간에 따라 자동 파티셔닝되는 TimescaleDB 테이블로, 고속 센서 데이터를 PostgreSQL 안에 머무르게 하는 히스토리안 추상화.
맥락화(Contextualization): 가공되지 않은 측정값을 그것의 배치, 장비, ISA-88 단계에 묶는 SQL 조인(s88.v_batch_sensor).
정직한 하이브리드(Honest hybrid): 순수 OSS가 스택의 약 80%를 덮고, GxP의 마지막 1마일(검증, 전자 서명, HA, 벤더 책임)은 강화(hardening)나 상용 시스템으로 충족된다는 입장.
진실의 기록(Record of truth): Part 11 / Annex 11의 적용을 받는, 감사 추적되고 신뢰할 수 있는 전자 기록 — 어느 계층이 그것을 보유하는가라는 되풀이되는 질문.

다음 이야기

이제 여러분은 지도를 손에 쥐었습니다. 센서에서 제출 문서까지 여덟 개의 계층, 각각 ISA-95 레벨과 오픈소스 도구에 핀되어 있고, OSS 대 상용의 경계가 잉크로 그려져 있습니다. 다음 장, 스택 세우기: 단 한 번의 docker compose up, 은 그 지도를 돌아가는 기계로 바꿉니다. 우리는 단 하나의 핀된 명령으로 코어 프로파일 — PostgreSQL + TimescaleDB, Mosquitto, 그리고 Grafana — 을 띄우고, 그 옆에서 CHO 시뮬레이터(Compose 서비스가 아니라 파이썬 패키지)를 시작하며, 첫 데이터 포인트 스모크 테스트(smoke test)로 스택이 살아 있음을 증명하고, 여러분이 방금 설계한 히스토리안으로 첫 측정값이 흘러 들어가는 것을 지켜봅니다.

이 장에서 다루는 내용​

한 페이지짜리 청사진​

같은 스택, 데이터플로우로 본다면​

히스토리안과 배치 모델을 위한 하나의 데이터베이스​

숫자를 지식으로 바꾸는 계층​

메시지 버스: 점대점 연결의 엉킴이 아닌, 이름 붙은 스트림​

오픈소스가 멈추는 곳: 정직한 경계​

컴포넌트 및 라이선스 목록​

왜 중요한가​

실제 현장에서는​

핵심 용어​

다음 이야기​