레시피와 기술 이전 모델링: 이동 가능한 공정 지식

📍 현재 위치: 2부 · 발견과 개발, 모델링 — 9장. 개발은 하나의 분자, 관리된 공정, 그리고 검증된 방법을 만들어 냈습니다. 이 장은 그 모든 것을 공장으로 실어 나르는 꾸러미를 모델링하고, 그 이동에 대해 모델이 보장할 수 없는 것을 정면으로 마주합니다.

2부가 쌓아 올린 모든 것 — 분자, 세포주, 설계 공간(design space), 분석 방법 — 은 이제 꾸려져 제조 부서에 넘겨져야 합니다. 그 꾸러미가 레시피(recipe)이고, 기술 이전(tech transfer)은 그것을 실험실 또는 발원 사이트에서 그것을 대규모로 돌릴 공장으로 옮기는 행위입니다. 레시피를 잘 모델링한다는 것은 공정 지식이 개발팀의 머릿속에 갇히는 대신 이동 가능하게 만드는 일이고, 그것을 정직하게 모델링한다는 것은 개발용 벤치와 다른 사이트의 2,000리터 바이오리액터 사이의 간극을 레시피가 건널 수 없는 것이 무엇인지를 인정하는 일입니다.

쉽게 말하면

레시피 카드는 요리가 여행할 수 있게 해 줍니다. 카드와 부엌을 가진 사람이라면 원칙적으로 누구나 그 요리를 만들 수 있습니다. 하지만 "노릇해질 때까지 구우세요"는 그 카드가 쓰일 때 가정한 것과 같은 오븐을 전제하고, 케이크 하나에서 천 개로 규모를 키운 레시피는 그냥 곱셈으로 풀리지 않습니다 — 타이밍과 열이 다르게 작동하기 때문입니다. 기술 이전(tech transfer)은 레시피 카드를 새 부엌에 넘기는 일이고, 규모 확대(scale-up)는 케이크를 하나가 아니라 천 개 만드는 일입니다. 이 장은 레시피 카드 — 그 단계, 필요한 장비, 핵심 설정값 — 를 정밀하게 모델링하고, 완벽한 카드라 해도 새 부엌의 첫 배치가 제대로 나온다는 보장은 없음을 정직하게 인정합니다.

이 장에서 다루는 내용

우리는 레시피(recipe)를 ISA-88 배치 표준으로 구조화되고 생산 공정에서 실현되는 정보 산출물로 모델링하며, 장비 요구사항(equipment requirement)을 그것을 채우는 물리적 장비와는 구별되는 역할로 모델링합니다. 레시피의 계층 구조를 해부하고, 어떻게 같은 모델이 하나의 레시피를 서로 다른 사이트의 장비에서 돌아가게 하는지 보이며, 진정으로 미해결인 부분 — 구조적 모델이 표시할 수는 있지만 예측할 수는 없는 규모 확대 효과와 사이트 차이 — 으로 마무리합니다.

레시피는 실현되는 정보다

레시피는 제품 콘셉트나 분석 방법과 같은 종류의 것입니다. 일반 의존 연속체(generically dependent continuant), 즉 정보 산출물이며, 손실 없이 사이트 사이로 복사될 수 있습니다. 그것은 배치도 아니고 런(run)도 아닙니다 — 그것은 생산 공정이 실현(realize)하는 처방(prescription)입니다. 1부의 상위 척추(upper spine)가 마련해 준 이 구별이 바로, 하나의 레시피가 여러 배치에서 실현되었다거나, 두 사이트가 같은 레시피를 돌렸다거나, 레시피가 두 캠페인 사이에 개정되었다고 그래프가 말할 수 있게 하는 것입니다 — 레시피는 정보로서 지속되는 반면 각 런은 별개의 발생체(occurrent)입니다. 마스터 배치 기록서(master batch record, MBR)는 발행된 채로의, 관리된 형태의 레시피이고, 실행된 각 배치 기록서는 특정 공정이 그것을 실현했다는 실행된 채로의 증거입니다.

그 처방을 구조화하기 위한 국제 어휘는 이미 존재합니다. 배치 제어 표준인 ISA-88(IEC 61512)은 레시피를 계층 구조 — 절차(procedure)로 이루어지고, 절차는 단위 절차(unit procedure)로, 단위 절차는 오퍼레이션(operation)으로, 오퍼레이션은 페이즈(phase)로 이루어진 — 로 모델링하며, 레시피를 그것을 실행하는 물리적 장비와 분리합니다 [1]. 그 짝인 ISA-95(IEC 62264)는 레시피가 돌아가는 장비와 기업 맥락을 모델링하고 [2], B2MML은 데이터 책의 아키텍처 장이 기댔던 XML 직렬화를 제공합니다 [3]. 레시피를 제조 온톨로지에 정렬된 ISA-88 계층 구조로 모델링한다는 것은, 각 단계가 공정 개발에서 나온 CPP와 CQA를 정확히 그것들이 적용되는 페이즈 위에 실어 나를 수 있다는 뜻입니다 — 관리 전략이 레시피 구조 옆에 떠 있는 것이 아니라 그 구조에 붙어 있는 것입니다. 적재 가능한 트리플로 표현하면, 레시피는 IOF 중간 수준에 정렬되고 런이 실현하는 정보이며, 그 옆에 놓인 사양과는 구별됩니다.

# align.ttl + instances.ttl — the recipe as portable information, realized by the run.
bp:MasterBatchRecord rdfs:subClassOf iof:MasterRecipe .  # IOF biopharma 'master recipe' (Released, Release_202602); a directive ICE
bp:Recipe-mAb-A a bp:MasterBatchRecord ;     # the master recipe — information, copyable across sites
    bp:hasRecipeElement bp:RP-production .   # ISA-88 composition: the recipe has recipe phases as parts
bp:RP-production a bp:RecipePhase ;          # the production-phase recipe element (prescription, not the run)
    bp:prescribesParameter bp:FeedRate , bp:Temperature ;
    bp:requiresEquipment bp:REQ-2000L .      # the equipment requirement this phase places on its vessel
bp:CCP-001 bp:realizes bp:Recipe-mAb-A .     # the production run *realizes* the recipe (not identical to it)
bp:Spec-DS-mAb-A a bp:Specification .        # the release spec — an IOF requirement specification, a different artifact

하나의 레시피를 온전히 펼쳐 본 모습: 절차, 오퍼레이션, 페이즈로 이루어진 ISA-88 계층 구조이며, 각각은 그것에 적용되는 핵심 변수와 점검을 실어 나르고, 더하여 그것이 필요로 하는 장비 역할까지 담고 있습니다 — 모두 나중에 생산 런이 실현하는 정보로서. 저자가 AI의 도움을 받아 직접 제작한 그림입니다.

장비 요구사항은 역할이지 장비가 아니다

레시피를 이동 가능하게 만드는 수는, 각 단계가 무엇을 필요로 하는지를 어느 한 사이트가 무엇을 가지고 있는지와 분리하여 모델링하는 것입니다. 레시피는 "용기 BR-101"을 요구하지 않습니다. 그것은 특정 클래스와 규모를 갖추고 특정 제어가 가능한 생산 바이오리액터를 요구합니다 — 이것이 장비 요구사항(equipment requirement)이며, BFO 용어로는 실제 용기가 역할을 수행함으로써 채울 수 있는 사양입니다. 사이트 A의 BR-101과 사이트 B의 BR-204는 레시피가 명시한 역할을 둘 다 지닐 수 있는 서로 다른 물질 엔티티입니다. 레시피가 요구사항에 결합되고 그 요구사항은 역할에 의해 채워지기 때문에, 같은 레시피가 다시 쓸 필요 없이 서로 다른 사이트의 장비에서 돌아가고, 그래프는 후보 용기가 어떤 단계에 자격이 있는지를 기계적으로 점검할 수 있습니다 — 그것이 요구사항이 지정하는 클래스, 규모, 능력을 충족하는가? 이것은 신원 규율을 능력에 적용한 것입니다. 레시피는 무엇이 필요한지를 참조하고, 무엇이 존재하는지와의 조정은 처방에 용기를 하드코딩하는 것이 아니라 역할을 통해 일어납니다.

실행 예제에서 이것은 더 이상 스케치가 아닙니다. 두 사이트, 받는 용기의 자격 검증, 그리고 엔지니어링 런과 확정 런을 갖춘 이전이 모두 적재 가능한 개체입니다. 레시피 페이즈는 REQ-2000L을 요구하고, 받는 사이트의 용기 BR-204는 그 요구사항에 대해 qualifiesFor를 선언하며, TechTransfer는 레시피를 발원 사이트에서 받는 사이트로 실어 나르고, 그곳에서 엔지니어링 런과 PPQ 확정 런이 자격을 갖춘 용기에서 일어납니다.

# instances.ttl — two sites, one recipe, a vessel that qualifies for the requirement.
bp:SITE-A a bp:ManufacturingSite .       # originating site (BR-101 is located here)
bp:SITE-B a bp:ManufacturingSite .       # receiving site
bp:BR-204 a bp:ProductionBioreactor ;    # the receiving-site vessel — a different material entity
    bp:locatedAt bp:SITE-B ; bp:qualifiesFor bp:REQ-2000L .  # it qualifies for the recipe's requirement
bp:TT-001 a bp:TechTransfer ;
    bp:transferredFrom bp:SITE-A ; bp:transferredTo bp:SITE-B ; bp:isAbout bp:Recipe-mAb-A .
bp:ENGRUN-001 a bp:EngineeringRun ; bp:occursIn bp:BR-204 .   # probes the move
bp:CONFRUN-001 a bp:ConfirmationRun ; bp:occursIn bp:BR-204 . # PPQ confirmation at the new site

설계에 의한 이동 가능성: 레시피는 장비 역할을 지명하므로, 두 사이트가 서로 다른 용기로 그것을 채우고 같은 처방을 변함없이 실현합니다 — 한편 경고 띠는 그 이동에 대해 모델이 표시할 수는 있지만 보장할 수는 없는 것을 가리킵니다. 저자가 AI의 도움을 받아 직접 제작한 그림입니다.

미해결 과제: 이동 가능한 모델이 이동 가능한 공정은 아니다

여기에 그 깔끔한 그림이 감추는 간극이 있으며, 그것이 기술 이전의 정직한 핵심입니다. 모델은 레시피를 이동 가능하게 만듭니다 — 같은 정보가 역할에 결합되어, 역할을 채울 수 있는 곳이라면 어디서든 돌아갑니다. 하지만 그것은 공정을 이동 가능하게 만들지는 못합니다. 생물학적 공정은 단순히 규모가 커지거나 자리를 옮기지 못하기 때문입니다. 2,000리터의 배양은 2리터의 배양과 혼합도, 산소 전달도, 전단도 다르게 합니다. 새 사이트의 물, 원자재 로트, 장비는 미묘하게 다르게 거동합니다. 이런 규모 확대와 사이트 효과(scale-up and site effects)는 모델링된 모든 변수를 동일하게 유지하더라도 CQA를 움직일 수 있습니다 — 이동 그 자체가 레시피로는 인코딩할 수 없는 변수입니다. 그래프는 이전이 일어났음을 표시하고, 그것을 탐색하는 엔지니어링 런과 확정 런을 연결하며, 새 사이트의 결과를 옛 사이트와 비교할 수 있습니다. 하지만 그 변화를 예측할 수는 없습니다. 그 예측이 바로 공정 모델과 하이브리드 소프트 센서가 시도하는 것이며, 정확히 구조적 모델이 계산적 모델에게 바통을 넘기는 지점입니다.

두 번째이자 좀 더 조용한 어려움은 매핑 그 자체의 성숙도입니다. ISA-88과 ISA-95는 수십 년 된, 널리 구현된 표준이지만, 그것들은 BFO에 기초한 온톨로지가 아니라 제어·통합 모델로 자라났습니다 — 그래서 ISA-88 레시피를 IOF 제조 온톨로지에 정렬하는 일은 단일한 정전(正典)적 답이 없는 진짜 모델링 작업이며, 이 시리즈를 관통하는 그 표준 수렴 간극과 같습니다. B2MML로 깔끔하게 모델링된 레시피와 IOF에 정렬된 그래프로 깔끔하게 모델링된 레시피가 자동으로 같은 레시피가 되지는 않습니다. 누군가가 그 교차 매핑(crosswalk)을 작성합니다. 그래서 이 장이 세우는 기준은, 다시금, 냉정합니다. 레시피의 구조와 요구사항은 아름답게 모델링되고 깔끔하게 이식되지만, 이전 하의 공정의 거동은 온톨로지가 제거하기보다는 문서화하는, 경험적인 "돌려 보고 안다"의 현실로 남습니다.

왜 중요한가

기술 이전은 프로그램이 시간과 지식을 잃는 지점이며, 모델링된 레시피는 그 둘 모두에 대한 해독제입니다. 레시피가 그 ISA-88 구조, 페이즈별 CPP와 CQA, 장비 요구사항을 질의 가능한 사실로 실어 나르면, 받는 사이트는 다시 해석해야 할 문서 더미가 아니라 공정 이해를 물려받습니다 — 그리고 그래프는 새 사이트의 장비가 자격이 있는지, 그리고 그 확정 배치가 관리 전략이 지명하는 모든 CQA를 충족하는지 점검할 수 있습니다. 레시피가 산문과 스프레드시트의 더미일 때는, 받는 사이트가 발원자가 이미 알았던 것을 다시 도출하고, 추적성이 가장 중요한 바로 그 인계 지점에서 계보 실타래가 닳아 풀립니다. 레시피를 모델링하는 일이야말로 2부 전반에 걸쳐 쌓아 올린 지식이 개발과 제조 사이의 벽을 온전히 살아남게 하는 길입니다.

통신선에서 그래프까지

이 장은 B2MML을 세 번 언급했고 그것이 만들어 내는 레시피 트리플을 보여 주었지만, 그 트리플이 나오는 통신선(wire) 형식은 한 번도 보여 주지 않았습니다. 동반 저장소가 그 간극을 메웁니다. examples/platform/ontology/b2mml/master-recipe.xml은 B2MML(MESA, http://www.mesa.org/xml/B2MML)로 직렬화된, 실제이며 추려진 ISA-88 마스터 레시피입니다 — MES나 배치 실행 계층이 실제로 주고받는 형태입니다. ISA-88/95와 B2MML은 모든 공장이 돌리는 제어 시스템에 구현된 상용 등급 표준이므로, 이것은 파일럿 산출물이 아니라 통신선 위의 실제 형식입니다.

<MasterRecipe xmlns="http://www.mesa.org/xml/B2MML">
  <ID>Recipe-mAb-A</ID>
  <RecipeElement>
    <ID>RP-production</ID>
    <RecipeElementType>Phase</RecipeElementType>
    <Parameter>
      <ID>Temperature</ID>
      <Value><ValueString>36.5</ValueString><DataType>real</DataType><UnitOfMeasure>Cel</UnitOfMeasure></Value>
    </Parameter>
    <Parameter>
      <ID>FeedRate</ID>
      <Value><ValueString>0.40</ValueString><DataType>real</DataType><UnitOfMeasure>/d</UnitOfMeasure></Value>
    </Parameter>
    <EquipmentRequirement>
      <ID>REQ-2000L</ID>
    </EquipmentRequirement>
  </RecipeElement>
</MasterRecipe>

examples/platform/ontology/b2mml_to_rdf.py는 이 문서를 요소별로 훑어 갑니다. MasterRecipe의 ID는 bp:Recipe-mAb-A a bp:MasterBatchRecord가 되고 — bp:MasterBatchRecord는 rdfs:subClassOf iof:MasterRecipe이므로, 이 레시피는 이 장 앞부분의 적재 가능한 트리플이 단언한 그대로 IOF 중간 계층에 정렬되어 안착합니다. Phase 타입의 RecipeElement는 bp:hasRecipeElement로 도달하는 bp:RP-production a bp:RecipePhase가 됩니다. 각 Parameter는 bp:prescribesParameter 엣지가 됩니다 — bp:Temperature와 bp:FeedRate로 향하는 엣지입니다. EquipmentRequirement는 bp:requiresEquipment로 도달하는 bp:REQ-2000L a bp:EquipmentRequirement가 됩니다. 스크립트는 B2MML -> RDF: 8 triples from the master recipe를 보고합니다 — 정확히 이 장이 이미 단언한 레시피 트리플입니다. 위에서 말한 "누군가 크로스워크를 작성한다"는 단서는, 여기서 시연된 크로스워크 그 자체입니다. 실제 B2MML 문서가 들어가고, IOF에 정렬된 레시피 그래프가 나오며, 그 사이에 지어낸 것은 아무것도 없습니다. 다음 부는 바이오의약품의 공유 어휘를 만드는 표준화 기구들을 추적합니다.

실제 현장에서는

ISA-88과 ISA-95는 배치 제조와 기업 통합의 공용어이며, 모든 공장이 돌리는 MES와 제어 시스템에 구현되어 있고, B2MML은 그것들의 확립된 교환 형식입니다 [1][2][3]. 기술 이전과 생애주기 관리는 제약 품질 시스템 지침의 명시적 관심사이며, 그 지침은 공정 지식을 다시 만들어 내는 것이 아니라 이전되어야 할 자산으로 다루고, 승인 후 변경을 사이트 사이에서 그 지식을 유지하는 것을 중심으로 짜냅니다 [4][5]. 최전선은 그 확립된 제어 표준을 BFO에 기초한 제조 온톨로지에 결합하여, 레시피가 단지 제어 시스템에서 실행 가능한 것을 넘어 지식으로서 질의 가능하고 점검 가능하게 만드는 일입니다 — 그리고 오픈소스 배치-장비 장은 그래프가 그 위에 쌓아 올리는 바로 그 ISA-88/95 모델의 관계형 형태를 보여 줍니다. 7부는 이 기관들로 곧장 되돌아갑니다. 표준·컨소시엄 장은 ISA-88/95와 B2MML을 누가 관장하는지 추적하고 Pistoia Alliance의 ISA-88 정렬 CMC Process Ontology를 짚으며, 제조 현장 장은 그 결합이 실제 생산 공장에 얼마나 도달했는지를 가늠합니다. 바로 이 바이오제조 모듈들을 성숙시키는 가장 활발한 노력은 OAGi/NIIMBL 협업으로, NIIMBL이 자사 빅데이터 프로그램 온톨로지를 Open Applications Group(OAGi)에 기증해 ISA-88·ISA-95에 기반하고 BFO·IOF Core에 정렬된 바이오제조 온톨로지를 구축하는 것입니다 — 제조 현장 장이 이 책이 지은 모델과 가장 직접적으로 이어지는 참조 노력으로 꼽는 작업입니다.

핵심 용어

• 레시피(recipe) — 배치를 만들기 위한 처방으로, 생산 공정이 실현하는 일반 의존 연속체(정보)로 모델링됨. 마스터 배치 기록서는 그것의 발행된 채로의 형태임.
• ISA-88(IEC 61512) — 레시피를 절차 → 단위 절차 → 오퍼레이션 → 페이즈 계층 구조로 구조화하는, 그것을 실행하는 장비와는 분리된 배치 제어 표준.
• ISA-95(IEC 62264) / B2MML — 장비와 기업 맥락을 위한 표준, 그리고 그것의 XML 직렬화.
• 장비 요구사항(equipment requirement) — 레시피 단계가 필요로 하는 것(특정 클래스, 규모, 능력을 갖춘 용기)으로, 실제 용기가 역할을 수행함으로써 채우는 사양으로 모델링됨 — 용기 그 자체와는 구별됨.
• 기술 이전(tech transfer) — 레시피와 그 공정 지식을 새 사이트로 옮기는 일. 모델로서는 이동 가능하지만 공정으로서는 경험적임.
• 규모 확대 / 사이트 효과(scale-up / site effects) — 모델링된 모든 변수를 일정하게 유지하더라도 더 큰 규모나 새 사이트에서 공정이 보일 수 있는 물리적·생물학적 변화. 그래프는 그것을 표시하지만 예측할 수는 없음.

다음 이야기

2부가 완성되었습니다. 프로그램의 지식이 모델링되어 이동 가능한 레시피로 꾸려졌습니다. 3부는 그 레시피를 공장 현장으로 따라가며, 거기서 정보가 행동이 되고 특정 캠페인의 계보가 엣지 하나하나로 깔립니다. 다음 장, 종균 배양과 계보의 시작 모델링은 WCB-CHO-001 바이알 하나를 해동하고, 확장 단계들을 거치며 세포를 키우고, 각 규모 확대를 하나의 물질을 소비하여 다음 물질을 생산하는 공정으로 모델링합니다 — 이 책이 줄곧 가리켜 온 그 배치의 첫 구체적 derivedFrom 엣지들입니다.