서문 — 센서에서 허가까지

📍 현재 위치: 3부작의 세 번째이자 마지막 책으로 들어서는 정문입니다. 여기서부터는 생물공정 데이터에 관한 글을 읽는 것을 멈추고, 바이오리액터(bioreactor)의 센서에서 규제 허가 제출까지 데이터를 실어 나르는 플랫폼을 직접 만들기 시작합니다.

이 3부작의 첫 번째 책 From Cell to Cure는 단일클론항체(monoclonal antibody, mAb)가 실제로 어떻게 만들어지는지를 살펴보았습니다. 살아 있는 CHO 세포, 유가식(fed-batch) 바이오리액터, 단백질 A(Protein A) 컬럼이 그 무대였습니다. 두 번째 책 Data Management in Biopharmaceutical Manufacturing Processes는 한 걸음 물러서서, 그 공정에서 나오는 데이터를 어떻게 거버넌스해야 하는지를 물었습니다. 누가 그것을 소유하는지, 어떻게 신뢰성을 유지하는지, "좋은" 상태란 어떤 모습인지를 다뤘습니다. 두 책 모두 읽는 책이었습니다.

이 책은 실행하는 책입니다.

여러분은 Git 저장소 하나를 클론하고 make up을 입력한 뒤, 실제로 동작하는 오픈소스 생물공정 데이터 플랫폼이 여러분의 노트북에서 살아나는 것을 지켜보게 됩니다. 책을 끝낼 무렵이면 여러분에게는 실시간 센서 데이터를 저장하는 히스토리안(historian), 그 숫자들에 의미를 부여하는 배치 모델(batch model), 직접 변조를 시도해 보고(그리고 그 시도를 스스로 잡아내는) 감사 추적(audit trail), 그리고 라만 스펙트럼(Raman spectrum)으로부터 항체 역가(titer)를 예측하는 소프트 센서(soft-sensor)가 갖춰져 있을 것입니다. 이 책의 모든 코드 블록은 실제로 실행되고 테스트된 그 저장소의 파일에서 나온 것입니다. 얼버무린 것은 하나도 없습니다.

쉽게 말하면

첫 번째 책은 요리하는 법을 가르쳤습니다. 두 번째 책은 주방 위생과 위생 검사관의 사고방식을 가르쳤습니다. 이 책은 주방 그 자체를 건네줍니다. 화구, 온도계, 작업 일지, 레시피 카드까지 — 모두 오픈소스이고, 모두 서로 연결되어 있습니다 — 그리고 그것을 직접 만드는 방법을 보여 줍니다. 그런 다음, 어떤 장비는 여전히 상용 벤더에게서 사야 한다는 사실을 솔직하게 말해 줍니다. 무료 장비만으로는 그 자체로 검사를 통과할 수 없기 때문입니다.

이 장에서 다루는 내용

• 이 책이 누구를 위한 책인지, 그리고 앞선 두 책으로부터 어떻게 바통을 이어받는지.
• 책 전체를 하나로 묶는 두 가지 생각: 오픈소스 우선(open-source first), 그리고 순수 오픈소스(OSS)가 더 이상 나아갈 길이 없을 때를 위한 정직한 하이브리드(honest hybrid).
• 우리가 절대 어기지 않는 단 하나의 규칙: 모든 주장은 여기서 실행 가능하거나 출처가 인용되어 있다.
• 이 책을 관통하는 사례 — 유가식 CHO + 단백질 A 항체 생산 라인 — 그리고 동반 저장소를 클론하고 시작하는 정확한 방법.
• 모든 장에서 보게 될 관례: 코드를 어떻게 보여 주는지, 출처를 어떻게 인용하는지, 그리고 오픈소스만으로는 충분하지 않은 지점을 어떻게 표시하는지.

이 책은 누구를 위한 것인가

데이터가 벤더의 블랙박스 속으로 사라지는 것을 지켜본 공정 엔지니어, "그냥 바이오리액터를 클라우드에 연결하라"는 요청을 받은 자동화 또는 데이터 엔지니어, 맥락 없는 CSV 파일만 받는 데 지친 데이터 과학자, 또는 실제 제약 데이터 스택이 어떻게 맞물려 돌아가는지 보고 싶은 학생이라면 — 이 책은 여러분을 위한 것입니다. 미생물학자나 규제 업무(regulatory-affairs) 전문가일 필요는 없습니다. 앞선 두 책이 그 기초를 제공하며, 진행하면서 중요한 부분은 다시 짚어 줍니다. 다만 터미널을 한 번이라도 본 적이 있다면 더 편하게 따라올 수 있습니다. Docker 전문가일 필요는 없으며 — 2장이 여러분의 수준을 끌어올려 줍니다 — 명령어를 입력하고 오류 메시지를 당황하지 않고 읽을 의지만 있으면 됩니다.

우리는 약 16GB RAM을 갖춘 노트북에 Docker와 Docker Compose가 설치되어 있고 [1], uv(make venv가 사용하는 빠른 Python 환경 및 패키지 설치 도구)와 함께 Python 3.12, Git [2], 그리고 GNU Make가 갖춰져 있다고 가정합니다. 이 책의 모든 명령은 make 타깃이기 때문입니다. 전제 조건은 그게 전부입니다. 핵심 스택 — 가장 먼저 띄우는 부분 — 은 대략 3GB RAM에 들어가며, 이후의 더 무거운 구성 요소는 선택적으로 추가되므로 여러분의 컴퓨터는 지금 보고 있는 장에 필요한 만큼만 부담합니다.

이 책을 떠받치는 두 가지 생각

오픈소스 우선

이 책의 핵심 주장은, 현대적이고 규제를 인식하는 생물공정 데이터 플랫폼의 대부분을 오픈소스 소프트웨어로 만들 수 있으며, 그렇게 하는 것이 오히려 명료하게 해 준다는 것입니다. 모든 계층을 들여다볼 수 있을 때, 비로소 여러분은 자신의 데이터가 무엇을 하고 있는지 이해하게 됩니다. 우리는 전체 스택 — PostgreSQL + TimescaleDB 히스토리안, Eclipse Mosquitto 메시지 브로커(message broker), Grafana 대시보드 계층, SQL로 구현한 ISA-88/95 배치 모델, 지식 그래프(knowledge graph), ALCOA+ 감사 체인(audit chain), 그리고 라만-역가 소프트 센서 — 을 거의 전부 관대한 라이선스를 가진 도구들로 조립합니다.

하지만 "오픈소스 우선"은 출발점이 되는 자세이지 종교가 아닙니다. 상용 시스템이 정직한 답인 곳에서는, 우리는 그렇다고 말하고 그것과 통합합니다.

정직한 하이브리드

여기 우리가 여러분이 모르는 채로 넘어가게 두지 않을 선이 있습니다. 어떤 오픈소스 도구도 다운로드 그대로 21 CFR Part 11을 준수하지 않으며, 내려받기만으로 준수하게 되는 일은 앞으로도 결코 없습니다 [3]. Part 11 — 미국 식품의약국(U.S. Food and Drug Administration, FDA)의 전자 기록 및 전자 서명에 관한 규정 — 은 전자 기록을 신뢰할 수 있고 종이 기록과 동등한 것으로 취급하기 위한 기준을 정합니다 [3]. 그 동반 지침은 이 점을 더욱 날카롭게 짚습니다. 준수는 *위험 기반(risk-based)*이며, 검증된(validated) 시스템과 그것을 둘러싼 절차에 부여되는 것으로, 특정 통제에 대해서는 집행 재량(enforcement discretion)을 적용해 다뤄집니다 — 선반 위에 놓인 소프트웨어 한 조각에 부여되는 것이 아닙니다 [4]. 유럽의 대응물인 EudraLex Annex 11도 다른 표현으로 같은 말을 합니다. 규제 대상 공정에 사용되는 전산화 시스템(computerised system)은 감사 추적과 데이터 무결성(data integrity) 통제를 갖추어 검증되어야 하며, 그 속성은 어느 한 구성 요소가 아니라 시스템 전체에 속한다는 것입니다 [5].

그래서 우리가 책 전반에 걸쳐 되풀이하는 정직한 추정은 이렇습니다. 순수 오픈소스는 여러분을 대략 80% 지점까지 데려다줍니다. 그것은 데이터를 포착하고, 저장하고, 맥락을 부여하고, 시각화하며, 심지어 의미론적으로(semantically) 추론하게도 해 줍니다. 나머지 20% — 검증, 적격성이 입증된(qualified) 전자 서명, 벤더 책임성(vendor accountability), 고가용성(high-availability) 보장이라는 GxP의 마지막 1마일(last mile) — 은 여러분이 직접 진지한 하드닝(hardening) 작업을 하거나 상용 제품에 손을 뻗어야 하는 지점입니다. (여기서 cGMP, 즉 현행 우수 제조 관리 기준(current Good Manufacturing Practice)을 처음 사용하니 정의해 둡니다. FDA가 집행하는 품질 시스템으로, GxP 데이터 무결성 규정이 그 안에서 작동합니다.)

이것은 오픈소스의 패배가 아닙니다. 그것이야말로 현대의 지침이 실제로 기대하는 바입니다. 컴퓨터 시스템 검증을 위한 업계의 주요 참고 문헌인 ISPE의 GAMP 5 제2판은 오픈소스 소프트웨어에 관한 부록과 위험 기반 보증(risk-based assurance) 접근법을 명시적으로 추가했으며, OSS가 GxP 환경에서 사용될 수 있음을 — 다만 검증된 수명 주기(validated lifecycle) 안에서만 — 확인했습니다 [6]. FDA의 컴퓨터 소프트웨어 보증(Computer Software Assurance) 사고방식도 같은 방향을 가리킵니다. 보증은 소프트웨어 위에 덧입혀지는, 위험에 비례하고 의도된 용도(intended-use)에 맞춘 활동이며, 바로 그렇기 때문에 어떤 도구도 준수된 상태로 도착하지 않습니다 [7]. 우리는 실행 가능한 80%를 만들고, 하이브리드 20%를 분명하게 가리키며, 마지막 장에서는 각 경계에서 정확히 무엇을 포기하게 되는지 점수를 매깁니다.

센서에서 허가까지: 데이터는 포착, 히스토리안, 배치 맥락, 의미론, 신뢰 계층을 거쳐 왼쪽에서 오른쪽으로 흐릅니다. 음영이 없는 부분은 여러분이 여기서 직접 만들고 실행하는 순수 오픈소스이고, 제출 가까이의 음영 처리된 마지막 1마일은 정직한 하이브리드입니다 — 검증, 적격성이 입증된 전자 서명, 그리고 오픈소스 단독으로는 제공하지 못하는 벤더 책임성입니다. Original diagram by the authors, created with AI assistance.

단 하나의 규칙: 실행 가능하거나 인용되거나

이 책의 모든 사실적 주장은 둘 중 한 방식으로 뒷받침됩니다. 실행 가능하거나 — 동반 저장소에 여러분이 직접 실행해 확인할 수 있는 파일이 있거나 — 아니면 1차 출처에 인용되어 있습니다. 규정, 표준, 공식 문서 페이지, 또는 동료 심사를 거친 논문(peer-reviewed paper)이 그 출처입니다.

동반 저장소는 examples/에 있으며 한 번만 클론하면 됩니다. 그 README.md는 약속을 분명하게 밝힙니다:

# From Sensor to Submission — companion repo

Everything the book claims is **either runnable here or cited.** This repo is the
"runnable" half — and CI runs the same `make` targets the book prints, so
"implementable on a laptop" is *proven*, not asserted.

그 마지막 문장이 우리가 하는 가장 강력한 약속입니다. 여러분이 책을 읽으며 입력하는 바로 그 make 타깃들이, 지속적 통합(continuous integration)에 의해 깨끗한 머신에서 실행됩니다. 이 책의 어떤 명령이 동작하지 않았다면, 빌드가 출판 전에 실패했을 것입니다.

관통하는 사례와 시작하는 방법

책 전반에 걸쳐 우리는 하나의 공정을 따라갑니다. 단일클론항체를 생산하는 유가식 CHO 세포 배양으로, 단백질 A 컬럼에서 포착되는 공정 — 오늘날에도 승인된 항체 대부분을 만들어 내는 일꾼입니다. 중요한 곳에서는 현대의 집약화된(intensified) 변형을 짚어 줍니다. 다중 컬럼 연속 포착 트레인(multi-column continuous capture train)에 공급하는 관류(perfusion) 배양이 그것입니다. 시뮬레이터(simulator)는 두 가지를 모두 제공하므로, 그 차이는 단지 읽는 것이 아니라 실행해 볼 수 있는 무언가입니다.

시작은 다섯 개의 명령입니다. examples/README.md에서:

make venv          # Python env + the simulator (uv)
make data          # generate every dataset deterministically + MANIFEST.sha256
make up            # bring up the core stack (postgres+timescale, mosquitto, grafana)
make seed          # load the ISA-88/95 reference CHO line
make load          # load the datasets into the historian + lab tables

make data에 있는 *결정론적으로(deterministically)*라는 단어가 핵심입니다. 시뮬레이터는 하나의 고정된 시드(SIM_SEED=2026)에서 실행되므로, 14일짜리 배치는 여러분의 노트북에서나 우리 쪽에서나 바이트 단위로 동일합니다. 생성이 끝나면 MANIFEST.sha256이 모든 파일의 해시를 기록합니다:

e3a78c7291c873b8ede54611d775152c356da138c22be1fc2f35ded04b359701  batches.csv
9b2eec56e5af4d12d7b78895578199fc88a49cf352ba2b45f99f447d275aa441  fedbatch_timeseries.parquet
6f4b5c4261fe3d7c4052326bd4d8fd3530c1cc06f8f0fd305dbb706cf9a0547c  fedbatch_timeseries_10min.csv

여러분의 숫자가 책의 숫자와 어긋나는 일이 생기면, 단 하나의 차트가 여러분을 오도하기 전에 매니페스트가 곧바로 알려 줍니다. 이것이 작은 규모의 FAIR 데이터 사고방식입니다 — 찾을 수 있고(Findable), 접근 가능하고(Accessible), 상호 운용 가능하고(Interoperable), 재사용 가능한(Reusable) — 재현성(reproducibility)을 희망이 아니라 설계 목표로서 처음부터 새겨 넣은 것입니다 [8].

make up이 실제로 시작하는 것

make up 명령은 얇은 래퍼(wrapper)입니다. examples/Makefile에서 그것은 core 프로파일만 띄우고 데이터베이스가 응답하기를 기다립니다:

up: ## bring up the core stack (postgres+timescale, mosquitto, grafana)
	$(COMPOSE) --profile core up -d
	@echo "waiting for postgres..." && sleep 3
	@until docker exec sensor-to-submission-postgres-1 pg_isready -U bioproc >/dev/null 2>&1; do sleep 2; done
	@echo "core stack up."

그 뒤에는 모든 서비스를 정확히 한 번씩 정의하는 하나의 선언적 파일 examples/platform/compose/compose.yaml이 자리합니다. Docker Compose는 하나의 YAML로 멀티 컨테이너 애플리케이션을 기술하고 단일 명령으로 시작하게 해 주며 [9], 우리는 그 프로파일(profiles) 기능에 기댑니다. 그래야 여러분이 지금 보고 있는 계층에 대해서만 비용을 치릅니다:

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"]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-bioproc} -d ${POSTGRES_DB:-bioproc}"]
      interval: 5s
      timeout: 5s
      retries: 20

  mosquitto:
    image: eclipse-mosquitto:2.0.22
    profiles: ["core"]

  grafana:
    image: grafana/grafana-oss:11.4.0
    profiles: ["core"]

그 스니펫에서 천천히 짚어 볼 만한 점이 두 가지 있습니다. 첫째, 모든 이미지가 정확한 버전에 고정되어(pinned) 있습니다 — timescale/timescaledb:2.17.2-pg17, eclipse-mosquitto:2.0.22, grafana/grafana-oss:11.4.0 — 결코 :latest가 아닙니다. 떠다니는(floating) 태그는 규제 시스템 안의 시한폭탄이며, 이 저장소의 설계는 한 걸음 더 나아갑니다. 각 이미지의 기반 다이제스트(digest)를 versions.lock에 고정해, 실행 중인 스택과 라이선스 인벤토리, 검증 등록부가 결코 조용히 어긋나지 않게 할 작정입니다. 둘째, postgres의 주석은 의도된 선택을 드러냅니다. TimescaleDB는 시계열 확장(time-series extension)을 갖춘 PostgreSQL 그 자체이므로, 여러분의 고빈도 센서 이력과 ISA-88/95 배치 맥락이 조인 가능한 동일한 데이터베이스에 함께 자리합니다. 이 하나의 결정이 나중에 통합의 고통 한 부류를 통째로 덜어 줍니다.

명령이 끝나면 여러분에게는 히스토리안, 메시지 브로커, 대시보드 서버가 돌아가고 있습니다 — 이후 모든 장이 전제하는, 늘 켜져 있는 토대입니다.

어디서나 보게 될 관례

• 코드는 저장소에서 나온다. 각 블록은 그 출처 파일을 밝힙니다(예: in examples/platform/compose/compose.yaml). 우리는 API도, 플래그도, 출력 한 줄도 지어내지 않습니다.
• 목(mock)은 목이라고 라벨링된다. 노트북에서 실행할 수 없는 시스템 — AVEVA PI, SAP, Emerson DeltaV, 상용 LIMS — 은 실제 API 계약을 따르는, 분명하게 라벨링된 FastAPI 또는 OPC UA 목으로 표현되며, 운영 엔드포인트로 교체하는 방법이 문서화되어 있습니다. 통합 코드는 진짜이며, 그 상대편이 시뮬레이션된 것일 때는 항상 알려 드립니다.
• 인용은 본문 안에 있다. [1] 같은 숫자 표시는 이 장의 참고 문헌 목록으로 연결됩니다. 본문에 별도의 참고 문헌 절은 없습니다.
• 한계에 대한 정직함은 하나의 기능이다. 오픈소스가 GxP, Part 11, 고가용성, 또는 벤더 책임성에 미치지 못하는 곳마다, 우리는 그것을 분명하게 말하고 하이브리드 또는 상용 답을 가리킵니다. 또한 2026년의 라이선스 함정 — TimescaleDB의 TSL 기능, Grafana의 AGPL, 그 밖의 것들 — 도 표시합니다. "오픈"이라는 이유로 채택한 도구가 재배포나 SaaS 맥락에서 여러분을 놀라게 하지 않도록 말입니다.
• 이중 언어. 이 책은 영어와 한국어로 출간됩니다. 코드, 식별자, 로그 출력은 두 언어 모두에서 그대로 유지됩니다.

왜 중요한가

생물공정은 데이터의 급류를 만들어 냅니다 — 분당 수천 개의 태그가 붙은 센서 판독값, 오프라인 분석값, 크로마토그램(chromatogram), 스펙트럼 — 그리고 대부분의 시설에서 그 데이터는 아무도 질의할 수 없는 히스토리안, 공유 드라이브 위의 스프레드시트, 그리고 빌려 쓰되 통제하지는 못하는 벤더 클라우드에 흩어져 있습니다. 그 비용은 추상적인 것이 아닙니다. 그것은 7일 차 온도 일탈(temperature excursion) 동안 센서가 무엇을 하고 있었는지 아무도 재구성할 수 없어서 3주가 걸리는 배치 조사로, 또는 수신 사이트가 발신 사이트의 태그 이름을 해석할 수 없어 멈춰 버리는 기술 이전(technology transfer)으로 나타납니다.

스택을 직접, 공개적으로 만드는 것은 그 데이터와 여러분의 관계를 바꿔 놓습니다. 여러분은 플랫폼을 마법으로 취급하기를 멈추고 엔지니어링으로 취급하기 시작합니다. 그리고 우리가 모든 것을 실행 가능하거나 인용되거나 규칙에 묶어 두기 때문에, 여러분은 벤더의 마케팅이 주장하는 것과 규정이 실제로 요구하는 것의 차이를 배우게 됩니다 — 검사관이 여러분의 시설에 서 있을 때, 그것만이 유일하게 중요한 구분입니다.

실제 현장에서는

정직한 하이브리드는 책을 팔기 위해 우리가 지어낸 타협이 아닙니다. 그것은 모든 바이오 제조 데이터 팀의 일상적 현실입니다. 현대적인 시설에 들어가 보면, 오픈소스 도구들 — Grafana, PostgreSQL, Python, MQTT — 이 검증된 상용 히스토리안과 수백만 달러짜리 MES와 나란히 즐겁게 돌아가고 있는 것을 보게 됩니다. 업계가 실제로 값을 치르는 기술은 그 경계가 어디에 있는지, 그리고 왜 거기에 있는지를 아는 것입니다.

표준 기구들도 이를 따라잡았습니다. 이제 2025년판으로 나온 ISA-95(IEC 62264)는 책 전체가 그 위에 구성되는, 현장의 센서에서 전사 시스템까지를 아우르는 계층화된 레벨 0–4 참조 모델을 제공합니다 [10]. GAMP 5 제2판은 검증된 수명 주기 안에서의 오픈소스 소프트웨어를 명시적으로 승인했고 [6], FDA의 컴퓨터 소프트웨어 보증 지침은 검증을 문서 연극(documentation theater)이 아니라 위험에 비례하는 보증으로 재정의했습니다 [7]. Part 11 [3], 그 범위 및 적용 지침 [4], 그리고 EU Annex 11 [5]과 함께 읽으면 메시지는 일관됩니다. 규제 당국은 여러분의 시스템이 통제되고 여러분의 데이터가 무결성을 갖추는지에 관심이 있지, 상자에 어느 로고가 박혀 있는지에는 관심이 없습니다.

제도적 추진력도 실재합니다. NIIMBL — 미국의 민관 협력 기관인 국립 바이오의약품 제조 혁신 연구소(National Institute for Innovation in Manufacturing Biopharmaceuticals) — 는 바로 이런 종류의 역량을 업계 전반에서 가속하기 위해 존재합니다. 델라웨어 대학교(University of Delaware)와 함께하는 파일럿 규모 cGMP 시설인 SABRE는 2024년 4월에 착공되어 2026년 중반 현재 건설 중입니다. SABRE는 데이터 프로그램이 아니라 시설입니다 — 하지만 그와 같은 시설들이야말로 이 책이 가르치는 데이터 아키텍처가 실제의, 규제받는 생산에 대비해 시험되는 곳입니다. SABRE를 비롯한 모든 공장이 답해야 하는 열린 질문은 우리가 매 장에서 돌아오는 바로 그것입니다. 어느 계층이 신뢰할 수 있고 감사 추적이 된, 진실의 기록을 보유하는가?

핵심 용어

• OSS(open-source software) — 오픈소스 소프트웨어: 사용, 연구, 수정을 허용하는 라이선스 아래에서 소스가 공개적으로 제공되는 소프트웨어. 이 책 스택의 토대입니다.
• 정직한 하이브리드(honest hybrid): 순수 OSS가 생물공정 데이터 플랫폼의 대략 80%를 감당하고, GxP의 마지막 1마일(검증, 전자 서명, 고가용성, 벤더 책임성)은 하드닝이나 상용 시스템으로 충족한다는 이 책의 입장.
• GxP / cGMP: "Good x Practice" 품질 규정의 집합. cGMP는 현행 우수 제조 관리 기준으로, GxP 데이터 무결성 규정이 그 안에서 작동하는, FDA가 집행하는 품질 시스템입니다.
• 21 CFR Part 11: 전자 기록 또는 서명이 종이를 대체할 만큼 충분히 신뢰할 수 있는 시점을 정의하는 FDA 규정.
• EU Annex 11: 전산화 시스템에 관한 유럽 GMP 지침. Part 11에 대응하는 규제 상대물입니다.
• GAMP 5: GxP 컴퓨터 시스템 검증을 위한 ISPE의 위험 기반 참조 문헌. 제2판은 오픈소스를 직접 다룹니다.
• ISA-95(IEC 62264): 전사 시스템과 제어 시스템을 통합하기 위한 표준 계층 모델(레벨 0–4)로, 스택을 구성하는 데 사용됩니다.
• FAIR: 찾을 수 있고, 접근 가능하고, 상호 운용 가능하고, 재사용 가능한 데이터 — 플랫폼이 만들어 내는 모든 것의 설계 목표입니다.
• 유가식 CHO / 단백질 A(Fed-batch CHO / Protein A): 관통하는 공정 — 한 배치에 걸쳐 영양분을 공급받는 중국 햄스터 난소(Chinese Hamster Ovary) 세포, 그리고 단백질 A 친화 컬럼에서 포착되는 항체.
• Docker Compose / 프로파일(profile): 하나의 YAML 파일에서 멀티 컨테이너 스택을 부팅하는 도구. 프로파일은 어느 서비스가 시작될지를 통제해, 여러분이 필요한 장만 로드하게 합니다.
• 결정론적 시뮬레이터(deterministic simulator, SIM_SEED=2026): 모든 데이터셋을 바이트 단위로 재현 가능하게 만드는 고정 시드 엔진.

다음 이야기

이제 여러분은 약속을 압니다. 여러분이 직접 만들고 실행하는 오픈소스 우선 스택, 오픈소스가 멈추는 곳의 정직한 하이브리드, 그리고 우리를 포함한 모두를 정직하게 유지하는 실행 가능하거나 인용되거나 규칙입니다. 다음 장 **참조 아키텍처: 하나의 스택, 계층별로(The Reference Architecture: One Stack, Layer by Layer)**는 그 스택을 한 페이지에 펼쳐 놓습니다. 우리는 모든 계층 — 엣지 연결성(edge connectivity), 메시지 버스(message bus), 히스토리안, 배치 모델, 맥락화(contextualization), 의미론, 컴플라이언스, 분석 — 을 그 ISA-95 레벨과 우리가 선택한 오픈소스 도구에 대응시키고, OSS 대 상용의 경계를 잉크로 그어 둡니다. 그래서 여러분은 첫 조각을 만들기 전에 센서에서 허가까지의 여정 전체를 볼 수 있습니다.