시나리오 로직은 DSL에 살아야 한다
OpenSCENARIO DSL로 시나리오를 적는다고 했습니다. 그런데 "DSL로 적는다"에는 함정이 있습니다 — 절반은 DSL에, 절반은 별도 스크립트에 적는 경우입니다. 이게 왜 문제이고, 왜 모든 로직이 DSL 안에 self-contained로 살아야 하는지가 이 글의 주제입니다.
안티패턴 — 로직이 새는 시나리오
흔한 안티패턴은 이렇습니다. 시나리오의 겉은 OSC로 적혀 있지만, 실제 편성 데이터(어떤 자산을 어디에 몇 대)는 별도의 파이썬 헬퍼 스크립트에 박혀 있습니다.
도식 렌더링 중…
실제로 측정해 보니, 한때 해상 시나리오 OSC의 41%가 별도 submit 스크립트의 편성 데이터에 의존하고 있었습니다. 겉보기엔 "OSC로 만든 시나리오"인데, OSC만으론 재현이 안 되는 반쪽짜리였던 것입니다.
⚠️ 반쪽 DSL = 데모 한정 — 시나리오 로직의 절반이 코드 스크립트에 박혀 있으면, end-user는 그 코드를 모르는 한 같은 시나리오를 만들 수 없습니다. 그건 "한 번 보여주고 끝나는 데모"이지, 고객이 직접 쓰는 제품이 아닙니다.
기준 — end-user가 DSL만으로 재현 가능한가
납품 가능한 구조의 기준은 명확합니다. end-user가 도메인 언어(OSC·manifest·API)만으로 같은 결과를 만들 수 있는가?
그래서 새 시나리오·기능을 만들기 전에 자문합니다.
- 이게 데모 한 번 돌리고 끝날 것인가, 납품 가능한 구조인가?
- end-user가 도메인 언어만으로 같은 결과를 만들 수 있는가?
- 비슷한 표준 패턴이 이미 있는가? 있으면 따라 하라.
💡 카탈로그도 코드가 아니라 데이터로 — 같은 철학이 무기·자산 카탈로그에도 적용됩니다. 무기 특성을 코드에 박는 대신 YAML 한 줄로 두면, 한 줄 추가로 지상→대공→대함까지 코드 수정 0으로 확장됩니다. "의도는 도메인 언어/데이터에, 실행은 엔진에"가 핵심입니다.
왜 이렇게까지 엄격한가
self-containment를 고집하는 이유는 단 하나 — 이 시스템은 데모용이 아니기 때문입니다. 고객·엔지니어가 시스템의 도메인 언어만으로 의도를 표현할 수 있어야, 비로소 제품입니다. 로직이 내부 스크립트에 새는 순간, 그건 우리만 돌릴 수 있는 일회성이 됩니다. 그래서 self-contained 비율을 100%로 끌어올리는 게 설계의 목표가 됩니다.
한 줄 정리
📌 시나리오 로직이 절반은 OSC, 절반은 스크립트로 흩어지면 데모 한정이다. end-user가 도메인 언어(OSC·manifest·API)만으로 재현할 수 있어야 납품 가능한 구조다 — 의도는 DSL/데이터에, 실행은 엔진에. "데모용이 아니다"가 self-containment를 강제한다.