RDBMS 종속 객체 지향 프로그래밍 아닌가?
인공지능 시대의 소프트웨어 공학
이 글은 지난 글에서 이어지는 글입니다.
추상(抽象)이 어떤 정신 활동인지 따져 보다
하지만, 프로그래밍 언어 차원에서 캡슐화(Encapsulation)를 지원한다고 해서 추상화가 보장되는 것은 아닙니다. 추상(抽象)이라는 낱말의 뜻을 따져 보면 알 수 있습니다. 추출이나 파악에 필요한 규칙에 대한 판단을 컴퓨터에게 맡길 수 있을 만큼 분명한 경우라면 굳이 응용 프로그램을 만들어 쓰지는 않을 테니까요.
물론, 인공지능이 발달하면서 데이터 속에서 패턴을 찾아 추출과 파악을 할 수 있는 시대가 되었으니 상황이 조금 바뀌어 가고 있기는 합니다. 하지만, 여전히 보편적인 추상은 사람의 일입니다. 적어도 AGI가 만들어지기 전까지는 그렇겠죠.
추출(抽出)이나 파악(把握) 과정에서는 본질적으로 선택(選擇)이 필요합니다. 앞서 <의사결정 부담을 줄여주는 패턴과 if로 시작하는 조건문>을 쓰면서 선택은 의사결정이라는 말로 치환할 수도 있음을 확인했는데요. 의사결정에서 의사(意思)는 '하고자 하는' 주체를 전제한 말입니다. 고로 사람의 주관이 바탕이 되는 활동입니다. 물론, LLM이 사람처럼 결과를 낼 수는 있지만, 이는 결국 사람이 만들어 낸 데이터를 바탕으로 통계적으로 생성한 가짜 주관이라고 하겠습니다.
RDBMS 종속 객체 지향 프로그래밍 아닌가?
추상이 사람의 의사(혹은 뜻)가 반영된 사고의 결과물이란 사실을 살펴봤습니다. 다시 앞선 글에서 응용 프로그래밍 환경을 추상화한 그림을 불러와서 이야기를 계속하겠습니다.
캡슐화는 프로그래밍 언어가 제공하는 기법이라 의미를 이해하지 못해도 쉽게 쓸 수 있습니다. 언어 입장에서는 훌륭한 기능을 제공한다고 자랑할 수 있지만, '객체 지향'이라는 기법 관점에서는 여전히 사람에게 의존하는 부분이 큽니다.
그래서, 다음 그림과 같이 객체나 구조체를 조작할 때, RDBMS에 특화된 명령어에 해당하는 SQL을 사용하게 됩니다.
여기에 더하여 SQL 사용에 익숙해지면 데이터베이스 트랜젝션(Database transaction)이 중요한 수행 단위가 되기도 합니다.
트랜젝션 스크립트에서 객체 지향 코드와 모델을 향해
이런 현상을 두고 마틴 파울러[1]는 그의 저서 <Patterns of Enterprise Application Architecture>에서 트랜젝션 스크립트(Transaction Script)라는 표현을 내놓습니다. 요약하자면, 프로그램의 비즈니스 로직이라는 것이 데이터베이스 트랜젝션 수행을 위한 구문에 그치는 것이죠. 그는 더 나아가 Anemic domain model이라는 안티패턴을 제안하기도 했습니다. 위키피디아 정의 부분을 크롬 번역으로 인용합니다.
빈약한 도메인 모델은 도메인 객체에 유효성 검사, 계산, 규칙 등과 같은 비즈니스 로직이 거의 또는 전혀 포함되지 않는 프로그래밍 안티패턴으로 설명됩니다.
'Anemic'은 크롬 번역으로 '빈혈'이라고도 하고, 파파고 번역에서도 '빈혈'이 됩니다. 확실히 부정적인 어감을 주는 말이죠. 객체 지향 모델링을 중흥시키려는 운동의 일환이라고 할 수 있을 것 같은데요.
이후 Eric Evans의 명서 DDD(Domain Driven Design)이나 JPA 기술 따위의 다양한 자산과 노력이 쌓여 RDBMS 종속을 일정 부분 벗어났다고 할 수 있습니다.
하지만, 여전히 모델의 형상은 임의적이거나 임시적이고, 지배적인 다수를 차지한 형태는 아직 없습니다.[2] 추상을 위한 합의된 형식은 아직 없다고 봐야겠죠.
주석
[1] 필자는 학부 때 마틴 파울러의 책으로 UML 책을 처음 접하며 소프트웨어 공학 공부를 시작하게 되었습니다.
[2] 잠시 UML이 왕좌를 노리는 듯했지만, 지금은 그렇다고 할 수 없죠.
인공지능 시대의 소프트웨어 공학 연재
4. 반복은 모든 탐구의 핵심이자 실제 지식 습득의 기본
7. 소프트웨어 설계는 어떻게 새롭게 정의할 수 있나?
9. 컨텍스트 엔지니어링 분류 체계와 구현 기술의 진화 양상
10. 목적에 따라 소프트웨어 설계 활동의 양상이 달라진다
