22. ABS 설계 방법론: ODD 프로토콜

7부(1821)에서 DES를 형식론부터 최적화까지 파고들었다. 8부는 나머지 두 축, agent-based 시뮬레이션(ABS)과 디지털 트윈의 심화다. 16편에서 ABM을 소개하며 마지막에 남긴 경고를 기억하자 — 행동 규칙과 파라미터의 자유도가 높아 “이 규칙이 맞는가”를 정하고 검증하기가 유난히 어렵고, 그럴듯한 창발 패턴이 나왔다고 모델이 옳다는 보장은 없다는 것. 16편이 “ABM이 무엇인가”였다면, 2223편의 질문은 “어떻게 제대로 만들고 믿을 것인가” 다.

그 첫 번째 처방은 의외로 소박하다. 모델을 기술(記述)하는 방식부터 표준화하는 것이다. 이 글은 ABM 커뮤니티가 합의한 그 표준 서식, ODD 프로토콜을 다룬다.

문제의식: 산문으로 적힌 모델은 재현할 수 없다

ABM 논문들은 오랫동안 모델을 각자의 방식대로 산문으로 기술해 왔다. 어떤 논문은 행동 규칙부터, 어떤 논문은 결과부터, 어떤 논문은 중요한 가정을 각주에 흘리듯 적었다. 그 결과는 심각했다.

재현 불가: 논문만 읽고 같은 모델을 다시 구현할 수 없다. 상태 변수가 정확히 무엇인지, 에이전트가 어떤 순서로 행동하는지, 난수가 어디에 들어가는지가 빠져 있기 일쑤다.
검증 불가: 리뷰어조차 모델의 실체를 파악할 수 없으니, “이 결과가 규칙에서 나온 것인지 버그에서 나온 것인지”를 따질 방법이 없다.
코드 공개로도 부족: 코드가 공개돼도 문제는 남는다. 코드는 무엇을 하는지는 담지만, 왜 이렇게 설계했는지 — 어떤 가정을 채택하고 어떤 대안을 기각했는지 — 는 코드에 없다.

Grimm 등이 2006년에 제안한 ODD(Overview, Design concepts, Details) 프로토콜은 이에 대한 답으로, ABM(그리고 individual-based model)을 기술할 때 무엇을, 어떤 순서로 적어야 하는지를 정한 표준 서식이다. 논문마다 제각각이던 모델 기술을 하나의 목차로 통일해, 읽는 사람이 항상 같은 자리에서 같은 정보를 찾을 수 있게 한다. 18편의 형식론이 DES 모델의 모호성을 수학으로 제거했다면, ODD는 (수학까지는 가지 않되) ABM 기술의 모호성을 구조화된 문서 양식으로 제거하려는 시도다.

ODD의 구조: 3그룹 7요소

ODD는 7개 요소를 3개 그룹으로 묶는다. 전체를 먼저 보이면 이렇다.

그룹	요소
Overview	① Purpose and patterns ② Entities, state variables and scales ③ Process overview and scheduling
Design concepts	④ Design concepts (11개 세부 항목)
Details	⑤ Initialization ⑥ Input data ⑦ Submodels

순서에 의도가 있다. Overview에서 모델의 뼈대를 먼저 보여 독자가 큰 그림을 잡게 하고, Design concepts에서 설계 결정의 근거를 밝히고, Details에서 재현에 필요한 모든 세부를 채운다. 큰 것에서 작은 것으로 — 독자는 필요한 깊이까지만 읽으면 된다.

각 요소를 구체적인 running example로 살펴보자. 반도체 FAB의 AMHS(automated material handling system, 자동 반송 시스템) 반송 차량 — 천장 레일을 달리며 웨이퍼 캐리어를 나르는 OHT(overhead hoist transport) — 를 에이전트로 하는 ABM을 기술한다고 하자.

Overview ①: Purpose and patterns

모델이 무엇을 위해 존재하는가, 그리고 모델이 재현해야 할 현실의 관측 패턴은 무엇인가를 적는다.

Purpose: 예 — “OHT 배차·경로 선택 규칙이 반송 시간과 레일 정체에 미치는 영향을 평가하기 위함.”
Patterns: 예 — “반송 요청이 폭주하는 시간대에 특정 베이(bay) 주변 레일에서 정체가 형성·해소되는 패턴”, “반송 완료 시간의 시간대별 분포.”

patterns를 purpose 옆에 두는 것이 핵심이다. 패턴은 단순한 배경 설명이 아니라 모델의 합격 기준이다 — 모델이 이 패턴들을 재현하지 못하면 목적에 비추어 실격이라고, 기술 단계에서 미리 선언하는 것이다. 이렇게 검증 기준을 문서 맨 앞에 박아 두면, “결과가 그럴듯해 보이니 통과”라는 식의 사후 합리화를 막을 수 있다. (이 기준이 실제 검증에서 어떻게 쓰이는지는 다음 글의 pattern-oriented modeling에서 이어진다.)

Overview ②: Entities, state variables and scales

모델에 어떤 종류의 개체가 있고, 각 개체는 어떤 상태 변수를 가지며, 공간·시간 스케일은 무엇인가.

Entities: OHT 차량 에이전트, 레일 네트워크(환경), 로드포트·스토커(반송 출발/도착 지점), 반송 요청(job).
State variables: 차량마다 — 현재 위치(레일 위 좌표), 속도, 적재 상태(빈 차 / 캐리어 적재), 배정된 목적지. 요청마다 — 발생 시각, 출발지, 도착지, 상태(대기/배정됨/완료).
Scales: 공간 — 레일 토폴로지를 방향 그래프로 표현(node = 분기·합류점, edge = 레일 구간). 시간 — 1초 단위 time step, 시뮬레이션 지평은 24시간.

여기서 중요한 규율은 상태 변수를 남김없이 나열하는 것이다. 상태 변수 목록이 곧 “이 모델이 세계의 무엇을 기억하는가”의 전부이므로, 목록에 없는 정보에 의존하는 행동 규칙은 있을 수 없다. 산문 기술에서 가장 자주 누락되던 부분이 바로 이것이다.

Overview ③: Process overview and scheduling

매 시점 누가, 어떤 순서로, 무엇을 하는가. OHT 예라면:

새로 발생한 반송 요청을 대기 목록에 추가
배차: 미배정 요청을 빈 차량에 할당
각 차량의 경로 선택(재계산 포함)
모든 차량 이동
충돌 회피: 선행 차량과의 간격 검사, 필요 시 감속·정지
도착 차량의 적재/하역 처리, 완료 요청 기록

각 단계가 어떤 순서로, 그리고 한 단계 안에서 에이전트들이 어떤 순서로 처리되는지까지 적어야 한다. 이것이 왜 형식적 항목이 아닌지는 아래에서 별도의 절로 다룬다.

Design concepts: 설계 결정의 근거 11항목

두 번째 그룹은 “무엇을 하는가”가 아니라 “왜 이렇게 설계했는가” 를 묻는 체크리스트다. 11개 항목이 있다: basic principles, emergence, adaptation, objectives, learning, prediction, sensing, interaction, stochasticity, collectives, observation. 2020 개정판은 모델에 해당 없는 항목은 생략해도 된다고 명시하지만, 그럼에도 이 11개 체크리스트를 한 번씩 훑는 것 자체가 “생각해 보지도 않은 설계 결정”을 드러내는 힘이다. 특히 중요한 네 항목을 OHT 예와 함께 보자.

Emergence — 무엇이 창발로 나오기를 기대하고, 무엇을 규칙으로 강제하는가. 이 구분이 ABM 기술의 심장이다. OHT 모델에서 베이 정체 패턴은 창발이어야 한다 — 개별 차량의 규칙 어디에도 “정체를 만들라”는 없고, 국소적 경로 선택과 충돌 회피의 상호작용에서 정체가 나와야 한다. 반면 “선행 차량과 최소 간격 유지”는 규칙으로 강제된 것이다. 만약 정체를 규칙으로 심어 놓고(예: 특정 구간 통과 시간에 지연을 하드코딩) “정체가 재현됐다”고 주장한다면 그 모델은 아무것도 설명하지 못한다. 무엇이 결과이고 무엇이 가정인지를 여기서 갈라 적는다.
Sensing — 각 에이전트가 무엇을 관측할 수 있는가. 16편에서 강조한 국소성(locality)을 명시하는 자리다. OHT 차량은 전방 일정 거리 내의 차량과 자기 경로 위 구간의 점유 상태만 보는가, 아니면 중앙 반송 제어 시스템이 전역 정보를 갖고 배차하는가? 같은 행동 규칙이라도 관측 범위가 다르면 전혀 다른 모델이다. “에이전트가 사실상 전역 정보를 훔쳐보는” 구현 실수는 sensing을 명시하지 않은 모델에서 흔히 발생한다.
Stochasticity — 어디에 왜 난수를 쓰는가. OHT 예: 반송 요청의 발생 시각과 출발·도착지는 분포에서 샘플링한다 — 상위 공정 스케줄을 통째로 모델링하는 대신, 그 결과로 나타나는 요청 스트림만 확률적으로 흉내 내는 것이다. 적재·하역 소요 시간의 잔차도 난수다. “왜”가 붙는 이유는, 난수는 항상 무언가를 모델링하지 않기로 한 결정의 흔적이기 때문이다. 그 결정이 문서에 남아야 나중에 출력 분석 단계에서 분산의 출처를 추적할 수 있다.
Observation — 모델에서 무엇을 기록하는가. 베이별 링크 점유율 시계열, 반송 요청별 완료 시간, 차량별 공차 주행 거리 등. 기록 항목은 ①의 patterns와 짝을 이뤄야 한다 — 재현해야 할 패턴이 “베이 정체”라면 그것을 확인할 수 있는 관측량이 정의되어 있어야 한다.

나머지 항목은 간결히: basic principles(모델이 딛고 선 일반 이론·가설 — 예: 최단 경로 기반 라우팅), adaptation(에이전트가 상태에 따라 행동을 바꾸는 규칙 — 예: 혼잡 감지 시 우회 경로 선택), objectives(적응 행동이 무엇을 높이려 하는가 — 예: 예상 도착 시간 최소화), learning(경험으로 규칙 자체가 바뀌는가 — 이 모델에서는 없음), prediction(에이전트가 미래를 예측해 행동하는가 — 예: 링크 통과 예상 시간 추정), interaction(에이전트 간 상호작용 방식 — 여기서는 레일 점유를 통한 간접 상호작용), collectives(에이전트 집단이 하나의 단위로 행동하는가 — 없음).

Details ⑤~⑦: 재현을 완성하는 세부

Initialization — 시뮬레이션 시작 시점의 상태. 차량 몇 대가 어디에 배치되는가(레일에 균등 분포? 실제 시스템의 특정 시점 스냅샷?), 초기 대기 요청은 있는가. 결과가 초기화에 민감하다면 반드시 명시해야 한다 — 예컨대 차량 초기 배치가 한쪽에 몰려 있으면 초반 정체 패턴이 완전히 달라지는데, 이를 적지 않으면 같은 모델로도 다른 결과가 재현된다.
Input data — 시뮬레이션 도중 외부에서 주입되는 시계열. OHT 예라면 실제 MES 로그에서 추출한 반송 요청 스트림. 모델 내부에서 생성되는 난수(stochasticity)와 외부에서 들어오는 데이터(input data)를 구분해 적는 것이 요점이다.
Submodels — Overview ③에서 이름만 나열한 각 프로세스의 수식·알고리즘 전체. “경로 선택”이라면: 링크 $e$ 의 비용을 $c_{e} = τ_{e} + α u_{e}$ (기본 통과 시간 $τ_{e}$ + 혼잡도 $u_{e}$ 의 가중 페널티)로 두고 최단 경로를 푼다는 것, $α$ 의 값과 그 근거, 재계산 주기까지. 파라미터 표(기호, 의미, 값, 출처)도 여기에 온다. 7개 요소 중 분량이 가장 큰 부분으로, 이 절만 읽고 코드를 다시 짤 수 있어야 합격이다.

Scheduling의 함정: 갱신 순서가 모델을 바꾼다

Process overview and scheduling이 왜 Overview에, 그것도 강제 항목으로 들어가 있을까. 에이전트 갱신 순서 자체가 창발 패턴을 바꿀 수 있기 때문이다. 같은 행동 규칙이라도 스케줄링이 다르면 다른 모델이다.

에이전트 $i$ 의 상태를 $s_{i}$ , 행동 규칙을 $f_{i}$ 라 하자. 동기(synchronous) 갱신은 모든 에이전트가 시각 $t$ 의 상태를 보고 동시에 다음 상태를 계산한다.

s_{i}^{t + 1} = f_{i} (s_{1}^{t}, \dots, s_{N}^{t}) for all i

이 식이 말하는 것: 모든 에이전트가 같은 세계를 보고 결정한다. 시각 $t + 1$ 의 어떤 상태도 다른 에이전트의 $t + 1$ 상태에 의존하지 않는다. Conway의 생명 게임이 이 방식이며, 동기 갱신은 그 정의의 일부다.

반면 비동기(asynchronous) 갱신은 에이전트를 정해진 순서(예: $1, 2, \dots, N$ )로 하나씩 갱신하며, 뒤 순번은 앞 순번의 이미 갱신된 상태를 본다.

s_{i}^{t + 1} = f_{i} (s_{1}^{t + 1}, \dots, s_{i - 1}^{t + 1}, s_{i}^{t}, \dots, s_{N}^{t})

이 식이 말하는 것: 같은 $f_{i}$ 를 쓰더라도 에이전트 $i$ 가 보는 세계가 동기 갱신과 다르다 — 앞 순번의 행동이 이미 반영된 세계다. 따라서 도달하는 상태 궤적이 달라질 수 있고, 그 위에서 창발하는 거시 패턴도 달라질 수 있다. 고정 순서 대신 매 스텝 순서를 무작위로 섞는(random order) 변형도 있는데, 이는 특정 에이전트가 항상 먼저 움직이는 인위적 우선권을 없애는 대신 결과에 스케줄링 난수라는 새로운 확률 요소를 넣는 선택이다.

OHT 예로 보면 즉각적이다. 두 차량이 같은 분기점을 향해 접근할 때, 동기 갱신이면 둘 다 “분기점이 비어 있다”고 보고 진입해 충돌 처리 로직이 필요해지고, 고정 순서 비동기면 순번이 빠른 차량이 항상 선점하며, 무작위 순서면 선점이 확률적으로 갈린다. 셋은 같은 규칙 집합에서 다른 정체 패턴을 만든다. 산문 기술에서는 “각 차량은 매초 이동한다” 한 줄로 뭉개지던 이 차이를, ODD는 Overview 단계에서 반드시 밝히게 강제한다. 갱신 순서를 적지 않은 ABM 기술은 미완성이다.

2020 업데이트: rationale의 강조

ODD는 한 번에 완성된 것이 아니다. 2006년 초판(Ecological Modelling)이 서식을 제안했고, 실제 사용 경험을 반영한 2010년 1차 개정을 거쳐, 2020년 JASSS에 2차 개정판이 나왔다. 2020 개정의 요지는 세 가지다.

Purpose에 patterns를 결합 — 초판의 “purpose” 요소를 “purpose and patterns”로 확장해, 모델이 재현해야 할 패턴 = 검증 기준을 문서 맨 앞으로 당겼다. 검증을 뒤로 미루지 말라는 구조적 압박이다.
Rationale의 강조 — 각 설계 결정마다 왜 이렇게 했는지를 적으라고 요구한다. 코드에는 결코 담기지 않는, 그러나 모델을 신뢰하는 데 가장 필요한 정보가 바로 이 근거다.
초보자용 가이드 부록 — 요소별 작성 요령과 예시를 담은 가이드를 부록으로 제공해, ODD를 처음 쓰는 사람의 진입 장벽을 낮췄다.

ODD는 생태학(individual-based model 전통)에서 출발했지만, 2020 개정판은 제목부터 “agent-based and other simulation models”로, 분야를 가리지 않는 시뮬레이션 모델 기술 표준을 지향한다. 실제로 사회과학·교통·제조 등 ABM을 쓰는 여러 분야에서 사실상의 표준으로 자리 잡았다.

정리

ABM의 고질적 약점 — 높은 자유도, 재현·검증의 어려움 — 에 대한 첫 처방은 모델 기술의 표준화다. 코드 공개만으로는 부족하다. 코드에는 왜가 없다.
ODD 프로토콜은 7요소 3그룹 — Overview(purpose and patterns / entities, state variables and scales / process overview and scheduling), Design concepts(emergence·sensing·stochasticity·observation 등 11항목), Details(initialization / input data / submodels) — 로 ABM 기술을 구조화한다.
Emergence 항목은 무엇이 결과(창발)이고 무엇이 가정(규칙)인지 가르고, sensing은 국소성을, stochasticity는 “모델링하지 않기로 한 것”을, observation은 기록 대상을 명시한다.
에이전트 갱신 순서(동기/비동기, 고정/무작위)는 창발 패턴을 바꾸는 모델의 일부다. 같은 규칙 + 다른 스케줄링 = 다른 모델. ODD가 scheduling을 Overview의 강제 항목으로 둔 이유다.
2020년 2차 개정은 patterns를 purpose에 결합해 검증 기준을 앞으로 당기고, 설계 결정마다 rationale을 적도록 강조했다.

잘 기술된 모델은 그 자체로 목적이 아니라 출발점이다 — 상태 변수와 파라미터, 그리고 재현해야 할 패턴이 명시되어 있어야 비로소 파라미터를 데이터에 맞추고(calibration) 모델을 현실에 비추어 검증(validation)할 수 있다. 다음 글 23편에서 그 보정·검증 방법을 다룬다.

참고문헌

Volker Grimm et al., “A standard protocol for describing individual-based and agent-based models”, Ecological Modelling 198(1–2), pp. 115–126, 2006. DOI
Volker Grimm et al., “The ODD Protocol for Describing Agent-Based and Other Simulation Models: A Second Update to Improve Clarity, Replication, and Structural Realism”, Journal of Artificial Societies and Social Simulation 23(2):7, 2020. DOI

Roh's Warehouse

Explorer