객체지향 분석설계 말고 객체지향 사고법
설계: 생각을 ‘차려’ 물질로 만드는 힘
설계에 관심이 많은 yeTi 님이 저에게 이런 이야기를 했습니다.
그렇다면 왜 객체지향을 고민할수록 이벤트 드리븐으로 종결하느냐를 말씀드려 보면, 결국 두 객체는 각자의 역할을 가진 자율적인 객체라는 전제가 생기는데요. 자율적이라는 말이 갑이라는 객체가 메시지를 전달했을 때 을이라는 객체는 메시지의 완전하게 처리해야만 하는 의무를 가진다는 것입니다. 이 사상을 대응할 수 있는 것이 이벤트 드리븐이라는 사상밖에 없다고 생각하여 객체지향을 고민할수록 이벤트 드리븐으로 종결한다고 말씀드리는 이유입니다.
저는 이에 대해서 개념적으로는 대체로 동의할 수 있고 제가 선호하는 방식이기도 하지만, 보편화하는 데에는 무리가 있다고 말했습니다. yeTi 님은 제 말이 납득이 어려운 눈치였는데, 거기에 대해 저는 사전 정의를 내리는 일을 좋아하는 사람도 있지만, 반대로 코드로 드러나거나 코드로 상상할 수 있는 구체적인 효용성 없는 논의를 좋아하지 않는 사람에게는 이런 식의 논의가 별 가치가 없을 수 있다고 답을 했죠.
이후에 더 이야기가 이어졌는데, 여기서는 당시 말로 표현하지 못했던 내용을 글로 기록하려고 합니다.
'객체 지향'이란 무엇인가?
제 생각을 펼치기 전에 지나치게 주관적으로 흐르지 않기 위해 습관적으로 위키피디아를 열다가 잠시 멈춰서 제미나이에게 물어보았습니다. 제 질문의 특이점은 '객체 지향'까지만 물었다는 것입니다. 아무튼 제미나이는 OOP(객체지향 프로그래밍)으로 바꿔서 답을 했습니다. 영어로 물으면 달라질까 싶어서 영어로도 해 보았더니 'programming paradiam'이란 표현이 달랐고, 이하 내용은 OOP를 설명한다는 점에서 공통점이 많았습니다.
제 질문이 특이한 이유는 위키피디아에서 Object-oriented라고 하는 형용사에 대해 설명하는 페이지는 없기 때문입니다. 다시 말해서 '객체 지향'이란 개념은 없습니다. 대신에 다음과 같은 개념이나 이를 구현한 기술들이 있죠.
Object-oriented analysis and design
그래서 일단 '객체 지향'이라고 말하면, 서로 오해의 소지가 생깁니다. 제가 경험한 내용을 일부 공유하겠습니다.
OOP는 객체를 모듈의 기본 단위로 제한한다
먼저 개발자들에게 익숙한 OOP 개념을 위키피디아 페이지를 통해 살펴보겠습니다. 먼저 정의를 보겠습니다.
Object-oriented programming (OOP) is a programming paradigm based on the concept of objects, which can contain data and code: data in the form of fields (often known as attributes or properties), and code in the form of procedures (often known as methods). In OOP, computer programs are designed by making them out of objects that interact with one another.
크롬 번역도 첨부합니다.
객체 지향 프로그래밍 ( OOP )은 데이터와 코드 (종종 속성 또는 속성 이라고도 함 ) 형태의 데이터와 프로시저 형태의 코드를 포함할 수 있는 객체 개념을 기반으로 하는 프로그래밍 패러다임입니다. (종종 메소드 로 알려짐 ). OOP에서 컴퓨터 프로그램은 서로 상호 작용하는 객체로 만들어 설계됩니다.
객체란 개념을 중심에 둔 프로그래밍 패러다임이라고 합니다. 이하 내용도 쓱 훑어보고 눈에 띄는 내용은 두 가지 정도입니다. 하나는 프로시저로 모듈(프로그램 덩어리)을 만드는 방식과 데이터와 프로시저를 합쳐서 만든 모듈인 객체라는 이분법이 서구 개발자 커뮤니티에서는 오랜 대비란 점입니다.
한때, 함수형 프로그래밍이 뜨기 시작할 때, 객체 안에 담겨 있는 데이터가 만드는 상태 관리의 어려움이나 부작용을 겨냥한 글들이 많았던 기억도 납니다. 결국 OOP가 객체라는 단위로 기본 모듈을 만든다면 프로시저와 데이터 구조체를 별도로 다룰 수 있는 방법을 '절차적'이라고 부르기도 한다는 사실을 알 수 있습니다.
그리고, 두 번째로 눈에 띄는 지점은 연혁(크롬 번역) 부분을 보면 굉장히 오랜 역사를 지녔다는 점입니다.
현대적인 의미의 객체 지향 프로그래밍에서 "객체"를 사용하는 용어는 1950년대 후반과 1960년대 초반 MIT의 인공 지능 그룹에서 처음 등장했습니다. "객체"는 식별된 속성(속성)을 가진 LISP 원자를 나타냅니다.
객체지향 분석 설계란 무엇인가?
이번에는 OOAD 설명을 보겠습니다.
Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.
역시 크롬 번역도 첨부합니다.
OOAD ( 객체 지향 분석 및 설계 )는 객체 지향 프로그래밍을 적용하고 소프트웨어 개발 프로세스 전반에 걸쳐 시각적 모델링을 사용하여 이해관계자 커뮤니케이션 및 제품 품질을 안내함으로써 애플리케이션, 시스템 또는 비즈니스를 분석하고 설계하는 기술적인 접근 방식입니다.
이후에 연혁을 보면 1990년대 CASE 도구와 함께 발전한 부분과 UML에 대한 설명이 이어집니다. 저는 BK21 사업의 혜택을 받아서 OOAD를 포함한 소프트웨어 공학 수업(지금은 사라진 코스)을 들을 수 있었습니다. 그래서 RUP 그림을 보았을 때 굉장히 반가웠습니다.
우리나라에서 제가 현장에서 경험한 내용을 기준으로 하면, 2010년 정도까지는 Rational 이란 기업이 주도한 이런 방법이 대기업 중심으로 소프트웨어 개발에 널리 쓰였지만, 이후에 Rational 이 몰락(?)하고 소프트웨어 업계가 실리콘 밸리 기업 중심으로 주도권이 바뀌면서 OOAD는 힘을 잃어갔습니다.
OOP와 OOAD의 문화와 지향점은 꽤 달랐다
간략하게 배경 설명을 했는데, 결국 OOP와 OOAD는 직접적인 연관성이 없다는 점입니다. 예를 들어 OOP 페이지를 보면 OOAD에 대한 설명은 참조 링크만 있을 뿐, 어디에서도 설명하지 않습니다. OOP 기반의 설계 방법으로 고안했다는 점에서 OOAD는 OOP에 기반을 두고 있습니다. 그러나, UML 2.0이 만들어질 때 OOP 코드를 자동생성하려는 업계의 열망으로 인해 오히려 OOP는 가려지는 아이러니한 현상이 벌어졌습니다. 피부로 느끼기에는 OOAD가 되려 OOP를 좋아하는 개발자들과 척을 지는 느낌마저 들었습니다.
시간이 한참 흘러 MS가 Github을 인수할 때 스프링을 개발한 Rod Johnson이 당시의 소회를 담은 글을 올린 적이 있었는데, 업계 현장에 있었던 사람으로 깊이 공감할 수 있었죠.
객체지향 분석설계 대신에 객체지향 사고법
결론적으로 '객체 지향'이라고 말하면, 사실 무슨 이야기가 담길지 모호하다는 것이 제 주장입니다. OOAD를 전공하다시피 하고 수년간 현장에 적용하던 저는 자바를 사용하기도 했기 때문에 OOP에도 익숙한 편입니다. 하지만, 둘을 섞어서 사용한다고 보는 편이 더 적절할 정도로 이들 개념이나 기술에 열의를 가진 사람들의 생각은 꽤 다른 편입니다.
Rational이 IBM에 인수되고, 코드 자동 생성이라는 CASE 도구의 꿈이 점차 사라져 갈 때 제가 아는 범위에서는 DDD 책을 통해 객체지향설계의 기법들이 실용적으로 보급된 측면이 있다고 생각합니다. 하지만, 그 이후에는 강력한 주도권을 갖고 이를 설계 방법이나 도구를 개발한 진영이 있는지는 잘 모르겠습니다.
그래서, 제 경우는 최근에는 '객체지향 사고법'이란 표현을 씁니다. UML도 널리 쓰이지 않고, RUP라는 방법론도 애자일에 밀려 쓰임새를 보기가 거의 어렵습니다. 하지만, 여전히 개발 과정에 도움을 줄 수 있는 사고법은 생각의 도구로 응용할 수 있기 때문이죠.
이렇게 전제를 하고 나면, 사고 방식이나 사고법 차원에서 yeTi 님이 이벤트 드리븐에 대한 강한 확신이나 선호를 납득할 수 있습니다. 저 역시 이미 2022년에 <이벤트는 변경을 알리는 표준 프로그래밍 단위>라는 글을 썼기 때문이죠. 이벤트에 대한 이야기는 다른 글에서 다뤄보겠습니다.
지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재
1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?
