Stack Overflow Blog에 게재된 글은 모델 지향 프로그래밍(Model Oriented Programming)의 개념을 재고하자고 제안한다. 이는 시스템 요구 사항과 소프트웨어 설계를 분리한 다음, 모델 자체를 활용해 시스템을 생성하고 유지 관리할 수 있는 방향이다. 저자는 13년 전 Mo+라는 언어와 개발 환경을 개발한 경험을 바탕으로 설명하며, 이를 기업 프로젝트에 사용했지만 아이디어가 널리 확산되지는 않았다고 말한다.
이 글은 이용 가능한 언어나 새로운 연구 프로젝트를 발표하는 것이 아니라, 특히 인공지능의 중요성과 소프트웨어 시스템의 복잡성이 커지는 세계에서 이 분야에 대한 추가 연구와 개발을 촉구하는 논지다.
구조와 데이터로서의 모델
저자는 모델을 두 가지 요소로 정의할 것을 제안한다. 하나는 규칙이나 스키마를 정의하는 구조이고, 다른 하나는 해당 구조를 따르는 데이터다. 구조는 계층적이며, 루트 노드에서 시작해 노드와 속성으로 분기한다. 필요할 경우 한 속성이 다른 노드를 참조할 수도 있다. 이러한 관점에서는 관계형 데이터베이스 스키마를 데이터베이스, 테이블, 열, 키와 같은 노드로 구성된 계층적 형태로 표현할 수 있다. 데이터 자체가 행과 관계에 분산되어 있더라도 마찬가지다.
글은 레스토랑, 고객, 직원, 메뉴 항목과 이들 사이의 관계를 포함하는 단순화된 레스토랑 시나리오를 사용해 이 개념을 설명한다. 또한 동일한 시나리오를 표현할 수 있는 여러 구조를 제시하며, 구조의 선택이 모델을 탐색하는 용이성과 모델에 의존하는 프로그램을 작성하는 방식에 영향을 준다고 설명한다.
모델 지향 개발의 네 가지 형태
- 비공식 모델링: 머릿속이나 종이 위에 존재하는 모델, 또는 소프트웨어 도구가 직접 사용하지 않는 다이어그램이다.
- 내장형 모델링: Entity Framework와 NHibernate 같은 ORM 프레임워크나 Angular와 React 같은 사용자 인터페이스 프레임워크에서처럼 코드 안에 모델이 포함되는 방식이다.
- 결합형 모델링: 주로 UML을 사용해 외부 모델을 만들고, 코드 요소 및 이를 관리하는 도구와 강하게 연결하는 방식이다.
- 분리형 모델링: 요구 사항, 데이터, 워크플로에 초점을 맞춘 모델을 만들고 세부적인 코드 설계는 남겨 두는 방식이다. 따라서 모델의 각 요소가 특정 소프트웨어 구성 요소와 연결되지 않는다.
저자는 가장 큰 가능성이 결합형 모델링과 분리형 모델링, 특히 후자에 있다고 본다. 분리형 모델링은 요구 사항을 모델에, 설계를 코드에 배치하기 때문이다. 저자는 자신의 경험을 통해 이러한 분리가 모델링과 프로그래밍 과정을 더 원활하게 만들었다고 말한다.
모델에서 시스템으로
글은 모델 지향 프로그래밍의 활용을 세 가지 영역으로 나눈다. 변환 방식에서는 프로그램이 모델을 해석해 소스 코드, 구성 파일 또는 이후에 개발할 수 있는 문서를 생성한다. 모델 모델링 방식에서는 언어가 모델의 구조와 데이터를 생성하고 유지 관리하는 일을 돕는다. 목표 방식에서는 언어를 직접 사용해 시스템 환경을 구축하고 관리하며, 이를 위해서는 더 완전한 언어가 필요하다.
제안된 언어의 기능
핵심 제안은 모델 구조를 언어 문법의 일부로 만드는 것이다. 이를 통해 모델을 표현하기 위한 별도의 클래스와 객체를 생성하는 대신 Entity, Property, Relationship과 같은 노드를 직접 다룰 수 있다. 저자는 또한 데이터 트리에서 프로그램의 위치에 기반하는 모델 컨텍스트를 제안한다. 여기에는 부모 노드로 올라가거나 하위 요소로 내려가 요소 사이를 검색할 수 있는 스택이 포함된다.
또 다른 아이디어는 ‘모델 지향 속성’이다. 이는 특정 노드 유형에 연결되고 여러 인스턴스에서 평가할 수 있는 독립적인 코드 조각이다. 이러한 속성을 조합해 클래스 정의나 속성을 생성하는 등의 코드를 만들거나, 검색 및 필터링 작업에 사용할 수 있다. 변환 방식에서는 속성에 결과를 파일이나 대상 환경에 저장하는 put 작업이 포함될 수도 있다.
저자는 인터프리터가 프로그래밍 세션을 시작할 때 모델 노드와 속성을 언어 문법에 추가하는 동적 규칙도 제안한다. 이는 표준 모델에 충분한 정보가 포함되지 않았거나 모델이 특정 기관이나 분야에 특화되어 있을 때 유용하다. 또한 프로그램의 서로 다른 부분에서 허용되는 작업을 제한하는 컨텍스트 규칙을 제시한다. 이를 통해 부작용을 줄이고 읽기와 쓰기의 책임을 분리할 수 있다.
이 구상이 중요한 이유
이 아이디어의 실용적 가치는 모델을 개발 과정과 분리된 단순한 설계 문서가 아니라 실행 가능한 대상으로 만들려는 시도에 있다. 요구 사항, 데이터, 워크플로를 재사용 가능한 생성 및 유지 관리 메커니즘과 연결할 수 있다면 모델과 코드 사이의 중복을 줄일 수 있다. 그러나 이 글은 표준 언어나 이용 가능한 도구, 또는 이 접근 방식이 현재의 모델링 및 코드 생성 프레임워크보다 우수하다는 것을 입증하는 비교 결과를 제시하지 않는다.
여전히 중요한 질문이 남아 있다. 규모가 크고 변화하는 모델을 어떻게 관리할 것인가? 생성된 코드는 어떻게 테스트할 것인가? 가독성, 보안, 개발 도구와의 통합 측면에서 동적 규칙에는 어떤 한계가 있는가? 따라서 이 글은 즉시 사용할 수 있는 완성된 해결책이라기보다 언어 개발자와 연구자에게 가치 있는 연구 제안으로 보인다.