"모델로 설계한다"의 다음에 오는 것

10년 전 장비와 지금의 장비를 나란히 놓아 보십시오. 차이는 크기가 아닙니다. 관여하는 사람의 수입니다.

기구, 전기, 제어, 소프트웨어, 안전. 각각 담당이 있고, 각자 자기 범위 안에서는 옳은 것을 쓰고 있습니다. 그런데도 현장 시운전에서는 문제가 납니다. 게다가 어느 담당의 자료를 다시 읽어봐도 그 문제는 쓰여 있지 않습니다. 누구의 설계에도 쓰여 있지 않은 거동이 조립된 순간에 나타납니다.

장비가 한 사람의 머리에 담기지 않게 됐습니다. 사양서와 실물 장비가 어딘가에서 조용히 어긋나 갑니다. 이 현상이 낯선 장비 엔지니어는 아마 없을 겁니다.

그리고 이런 일이 일어난 것은 장비 업계만이 아닙니다.

세계는 이미 모델로 설계하기 시작했다

자동차도, 항공기도, 의료기기도 같은 벽에 부딪혔습니다. 나온 답은 설계를 문서가 아니라 모델로 갖는 것이었습니다. Model-Based Systems Engineering, Model-Based Design. 부르는 이름은 여럿이지만 하는 일은 같습니다. 요구도, 상태도, 인터페이스도 사람이 읽는 산문이 아니라 기계가 다룰 수 있는 구조로 씁니다.

Simulink로 블록 다이어그램을 그리는 것도, SysML로 상태 기계를 쓰는 것도, 설계 관리 도구로 요구와 모듈을 묶는 것도 전부 이 흐름 안에 있습니다. 이 글을 읽는 분의 회사에서도 이미 어느 하나는 돌아가고 있을지 모릅니다 —— 그렇게 부르지 않을 뿐.

이것은 착상 수준의 이야기가 아니라 시장으로 움직이고 있습니다. 제3자 조사에 따른 추계로는 MBSE의 시장 규모가 2024년에 약 74억 달러, 2033년에는 약 227억 달러입니다. 연평균 성장률로는 약 13%. “새롭고 좋아 보이는 사고방식”의 숫자가 아닙니다. 이미 갈아타기가 시작됐다는 것의 숫자입니다.

즉 이 사다리에는 이미 많은 현장이 발을 올려놓았습니다.

모델은 만드는 데까지만 책임진다

여기서 모델링 도구가 실제로 해 주는 일을 늘어놓아 보겠습니다.

모델을 쓸 자리를 제공한다
모델을 그림으로 보여 준다
모델 서식의 정합성(참조 누락, 타입 불일치)을 확인한다
모델에서 코드를 생성한다

마지막 하나는 강력합니다. 사람이 손으로 옮겨 적는 공정이 사라지므로, 옮겨 적기 실수라는 오류의 종류가 통째로 없어집니다.

그러면 이렇게 물어보십시오. 그 모델은 옳습니까.

어떤 도구도 이 질문에는 답하지 않습니다. 답하고 있는 것처럼 보이는 것도 있지만, 보고 있는 것은 “모델로서 서식이 갖춰져 있는가”이지 “그 모델대로 장비를 움직여서 안전한가”가 아닙니다.

옳지 않은 모델에서도 코드는 완벽하게 생성됩니다. 생성된 코드에 오류는 하나도 없습니다 —— 쓰여 있는 대로 움직인다는 의미에서는. 오류는 모델 쪽에 있고, 코드를 아무리 읽어도 나오지 않습니다. 코드 리뷰로는 절대로 찾을 수 없는 오류가 거기에 있습니다.

모델을 만드는 일과, 그 모델이 옳다고 증명하는 일은 별개의 일입니다.

별개의 일이니 별개의 도구가 필요합니다.

그 공백을 메우는 것이 형식기법입니다

여기까지를 하나의 사다리로 늘어놓으면 이렇게 됩니다.

장비가 복잡해져서, 머리와 종이 안에서만으로는 설계가 따라가지 못하게 됐다
  → 그래서 세계는 "모델"로 설계하게 됐다(MBSE / MBD)
  → 그러나 "그 모델은 정말 옳은가"는 아무도 증명하지 않았다
  → 형식기법에 의한 검증이 그 공백을 메운다

형식기법(formal methods)이라는 이름은 귀에 익지 않을지도 모릅니다. 하는 일은 단순합니다. 설계에 쓰여 있는 상태와 전이를 수학적으로 다룰 수 있는 형태로 옮기고, 일어날 수 있는 상태의 조합을 기계가 빠짐없이 훑게 합니다. 사람이 떠올리지 못한 순서까지 포함해서 전부입니다. 안전 조건이 깨지는 경로가 하나라도 있으면 그것을 찾아서 돌려줍니다.

중요한 것은 이것이 사다리의 한 단 위에 얹히는 층이라는 점입니다. 옆에 나란히 서서 경쟁하는 것이 아닙니다.

먼저 가장 신경 쓰일 부분부터 정리해 두겠습니다. Simulink를 버릴 필요는 없습니다. PLC 툴체인도, 사내 설계 관리도, 품질 매뉴얼의 절차도 그대로입니다. 모델은 지금까지 하던 대로 만듭니다. 그 모델에 대해 “두 축이 동시에 위험 영역에 들어가는 절차가 존재하지 않는가”를 묻는 공정이 코드 생성 앞에 한 단 들어갑니다. 그것뿐입니다.

입구가 이미 손에 있는 설계 산출물이라는 것 —— 여기가 요점입니다. 상세 설계에는 장비가 어떤 상태를 가지고, 어떤 순서로 움직이고, 어떤 조건에서 인터록이 걸리는지가 이미 쓰여 있습니다. 재료는 충분합니다.

코드 생성이 좋아질수록 설계에서 막힌다

지금은 상세 설계를 넘기면 코드가 나오는 상황이 현실이 되어 가고 있습니다. 장비 업계가 이것을 어디까지 받아들일지는 별개의 논의로 두더라도, 기술로서는 그렇게 되어 있습니다.

이것은 문제를 없애지 않습니다. 옮길 뿐입니다.

설계가 틀려 있으면 AI는 그 틀린 설계를 정확하게 구현합니다. 손으로 쓰는 것보다 빠르게, 정확하게, 대량으로. 그리고 오류는 코드 어디에도 없습니다 —— 설계에 있으니까요.

코드 생성이 좋아질수록 설계가 병목이 됩니다. 공정 중에서 가장 자동화되어 있지 않은 부분에 부하가 몰립니다. 그것뿐인 이야기입니다. 다만 그 “그것뿐”은 설계를 확인할 수단을 가지고 있는지 아닌지에 따라 전혀 다른 무게가 됩니다.

그러면 왜 다들 하지 않는가

여기는 솔직하게 쓰겠습니다. 이 사다리는 오르기 쉽지 않습니다.

MBSE 자체도 순조롭게 보급되고 있는 것은 아닙니다. 2024년 INCOSE의 조사는 도입 장벽으로 세 가지를 꼽습니다 —— 인지되는 복잡성, 기존 관행과의 궁합, 학습 곡선.

읽어 보면 알 수 있듯이 어느 것도 기술의 이야기가 아닙니다. “어려워 보인다”, “지금 하는 방식과 맞물리지 않는다”, “익히는 데 시간이 걸린다”. 형식기법은 이 세 개의 벽에 똑같이 부딪힙니다. 오히려 MBSE보다 더 세게 부딪힙니다. 수학 표기가 나온 시점에서 많은 현장은 손을 멈춥니다. 그것은 태만이 아니라 타당한 판단입니다.

그렇다면 이 한 단을 실제로 오를 수 있게 하는 데 필요한 것은 이론 이야기가 아닙니다. 설계자가 평소에 쓰고 있는 것이 그대로 입구가 되는 것. 그리고 결과가 현장의 언어로 돌아오는 것. 여기가 풀리지 않는 한 옳음의 증명은 논문 안에 머뭅니다.

DatumProof는 이 한 단을 장비 엔지니어가 평소의 설계 산출물 그대로 밟을 수 있게 하는 것을 목적으로 하는 시도입니다.

다음에 읽을 글

“설계를 확인한다”고 해도 그것이 테스트와 어떻게 다른가. 여기가 납득되지 않으면 이야기는 앞으로 나아가지 않습니다. 테스트와 형식기법은 무엇이 다른가에서 다룹니다.

그리고 이런 기법이 실제로 쓰이고 있는지 아닌지. 답은 “쓰이고 있다”이고, 그것도 장비 업계에서 그리 멀지 않은 곳입니다. 누가 실제로 쓰고 있는가에서 소개합니다.