게임 프로그래밍 하시는 분들은 상당히 진보적이지 않나요? 요즘엔 generic programming이니 aspect oriented programming이니 하던데 ;;

질문이 참 난해합니다.
시스템 설계시 객체지향 방법론의 적용을 말씀하시는거죠?

많이 아니 굉장히 많이 씁니다.
설계가 잘된 곳도 굉장히 많습니다.

금융권은 거의 다 객체지향 방법론 적용했고...
삼성은 거의 다 EJB로 다 바꾼 듯 하고..
현재 진행되는 프로젝트도 모두 CASE 툴을 이용한 객체지향 방법론을 적용하고 있고..
대형 프로젝은 모두 도입하고 있습니다. 특히 정부 기관은 default입니다.

도대체 우리나라에서 안쓴다는 말이 무슨 말인지?

어떤 일을 하시는분의 말씀인가여?
C만 죽어라 코딩하던 분의 말씀이라면.... 그런말이 나올 법도 하지요

실지로.... 객체지향 같은거에 아직도 많은 거부감을 가지고 있는 사람이 많으니까요

실제로 큰 프로젝트에서 EJB를 쓰는데를 봐도 설계자가 EJB 스펙의 50%라도 이해하고 제대로 쓰는데는 아직까지 단 한 번도 못봤습니다. 그냥 EJB가 좋다니까, 미션 크리티컬한 솔루션에 적합하다니까 쓰는거지 구체적으로 어떤 이점이 있는지 이해하고 적용하는 경우는 거의 없습니다.

그러다보니 EJB 설계랍시고 한 걸 보면 사실상 세션빈은 펑션 모음이고 엔티티빈은 데이터베이스 테이블 매핑입니다. 이건 결코 객체지향도 아니고 원래 EJB 같은 컴포넌트 중심의 프레임워크는 제대로 써도 객체지향적인 설계가 나오기 쉽지 않습니다.

외국의 경우는 EJB가 실패하고 경량 컨테이너와 경량 퍼시스턴스 솔루션으로 이행하는 추세입니다. 이런 경우 그나마 객체지향의 이점을 살려 설계가 가능할 지 몰라도 '웹개발=디비설계 + html 삽질'이란 공식이 일반적인 우리나라 SI 쪽에서는 별로 영향을 안받을 것 같군요...

어쨌든 최소한 웹 쪽 SI만 놓고 볼 때 실무에서 개발되는 코드의 95%는 전혀 객체지향적이지 않습니다. 거의 데이터베이스 스크립트와 html/자바스크립트의 조합이라고 보셔도 크게 틀리지 않습니다.

암담한 현실이지요 :cry:

객체지향...
object oriented 를 우리말로 번역한 것이라지요.
그런데 object oriented 를 객체지향이라고 번역한 것 자체가 잘못이라는 이야기도 있더군요. 개체기반이라고 해야 된다는 이야기도 있고... 어떻게 번역해야 정확한 번역이 될지는 저도 잘 모르겠습니다.
object oriented 라는 개념을 정확히 이해하는 사람이 적어서가 아닐까요?

객체지향의 구체적으로 어떤 부분을 사용해야 한다는 것인지 잘 이해가 가질 않습니다. 가령 웹기반 서비스를 개발하는 프로젝트에 EJB를 도입한다고 하면, 윗 분 말씀대로 세션빈은 펑션의 집합입니다. 엔티티 빈은 잘 쓰지도 않습니다. 웹 환경이라는 게 초기 설계가 6개월이내에 대부분 DB 설계부터 수정이 가해지기 때문에 엔티티 빈은 운영상에 장애요인으로 작용합니다.
객체지향의 추상화, 상속, 다형성 중에 추상화와 다형성은 어느 정도 사용되지만 상속은 특히 웹기반 서비스에는 거의 쓰이지 않습니다. EJB 컨테이너 솔루션 엔지니어들도 상속은 쓰지 않을 것을 권고합니다. 그 이유는 튜닝이 어렵고 리소스의 낭비가 심해질 수 있으며 디버깅이 어려워지는 경우도 있기 때문입니다.
그 외에 다른 분야는 잘 모르겠네요. :)

딴지 거는 건 아니지만 정확히는 상속이 웹기반 서비스에서 거의 쓰이지 않는 것이 아니라 컴포넌트 지향적인 특성상 EJB 솔루션에서는 쓰기가 어렵습니다. 튜닝이 어려워 진다는 부분은 잘 이해가 가지 않지만 어쨌든 구조적으로 거의 쓰기가 불가능합니다.

EJB에 대한 비판은 여러 가지가 있지만 대표적으로 앞서말한 비객체지향적 특성 이외에도 불필요한 오버헤드, 생산성 저하, 비슷한 종류의 중복되는 코딩 - 예를들어 엔티티빈과 데이터모델(value object), 유닛 테스트의 어려움, 벤더 종속성 등등이 있습니다.

이런 한계를 극복하려는 시도가 다방면에서 있어왔고 최근의 경량 프레임워크 들을 활용하면 웹기반 서비스에서도 상속과 같은 객체지향의 장점들을 100% 활용할 수 있습니다. 따라서 객체지향적 설계가 어렵다는 건 웹기반 솔루션의 한계라기 보다는 EJB 모델의 한계라고 하는게 더 적합할 것 같습니다.

부연 하자면 바로 그런 관행이 국내 웹SI 설계의 수준을 반증한다고 생각합니다. 대부분, 최소한 제가 수년간 실무에서 본 개발자 모두는 SQL에 대한 지식은 수준급이지만 객체지향적 개발이나 XP 등의 방법론에 대해서는 거의 경험이 없습니다. 그러다보니 모든 개발이 데이터베이스를 중심으로 돌아가게 되고 설계는 곧 ERD를 그리는 것이라는 잘못된 고정관념이 생긴 것입니다. 말씀하신 대로 대부분 초기에 기획서를 보고 데이터베이스를 좀 아는 개발자가 ERD를 뽑아 놓으면 나머지 초급 개발자들이 달라붙어 부분 부분 나눠서 디자이너가 작성한 html과 연결하는 식의 작업이 대표적인 국내의 웹기반 SI의 개발 방법론(?)입니다.

사실 EJB의 엔티티빈이 나오게된 배경을 보아도, 이는 엔티티빈 이전부터 널리 쓰이던 O/R 매핑이나 퍼시스턴스 프레임워크 들을 표준화 하려는 시도입니다. 즉, 정석대로 도메인 객체를 설계하고 이를 퍼시스턴스하는 과정에서 DAO를 만들건 TopLink 같은 O/R 매핑 툴을 쓰건 하는 탑다운 방식이 권장되었음을 알 수 있습니다. 그런데 이런 엔티티빈이 아예 '탑다운'이라는 개념 자체가 생소한 국내에 들어오면 반대로 기존의 ERD에 엔티티빈을 '올리는' bottom-up으로 둔갑하다보니 "왜 굳이 ERD를 만들었는데 또 엔티티빈이 있어야 하나?"하는 의문이 드는 것입니다.

물론 외국에서 EJB, 특히 그 중에서도 엔티티빈이 비판받는 건 다른 이유지만 엄밀히 말하면 국내에서 정상적으로 엔티티빈을 제대로 이용해서 설계를 한 경우는 제가 아는 한 많지 않습니다.

즉, 이런 문제점들은 웹 개발이라는 환경에서 비롯된 것이 아니라 대부분 데이터베이스 중심적 사고를 하는 국내 개발자들의 수준에서 오는 것이라고 생각합니다.

c만 죽어라 '코딩'하는 사람으로써 매우 기분 나쁘군요.
기껏해야 생성자와 소멸자가 주는 편리함 정도 때문에 c++을 쓰는 사람에게 c를 쓴다는 이유만으로 "c를 쓰면 안됩니다. oo로 개발해야합니다."라는 소리를 들었던 때처럼 황당하기도 하구요.

c로도 oo 할 사람들은 다 한답니다.
뭐 c가 oo를 '진정'으로 구사할 수 있냐는 논쟁을 원하시는 거라면 해야할 코딩이 쌓여 있어서 피하고 싶군요. 다만 그 문제는 학문으로서 컴퓨터언어론을 파고 있지 않다면 여기 bbs에 그에 대한 많은 글이 있으니까 검색해서 읽어보시고 각자가 나름대로 선택하면 될 문제라고 생각합니다.

글쎄요, EJB가 Top-Down 식의 설계 방법을 도입해야한다는 건 좀 의외입니다. 실제로 지금까지 제가 수행해온 Web 기반의 SI 프로젝트는 모두 Top-Down 방식이었습니다. 거기에 EJB등의 객체지향 솔루션을 도입하면서 CBD 방법론이나 UML 툴을 써서 설계를 하는 게 유행(?) 비슷한 경향이 되었습니다. 물론, UML을 쓴다, EJB를 쓴다고 해서 그게 객체 지향적이고 컴퍼넌트 기반의 시스템이 된다고는 생각하지 않습니다.
그리고 설계란 곧 ERD가 아니라 업무를 IT적으로 분석한 것이 곧 ERD라고 생각합니다. 기타 class 설계는 업무에 기반했다기 보다는 순수 구현을 위한 설계라는 것이 개인적인 견해입니다. 액션 중심의 시스템이라면 객체와 액션간의 상관관계에서 엔티티를 끌어낼 수 있지만 데이타 중심의 시스템이라면 엔티티의 효율적인 사용을 위해 객체와 액션을 정의할 수 있는 것 아닌가요? 웹 기반이라면 물론 액션에 치우치는 경향이 많지만 대용량 DB나 데이타간의 연관관계가 복잡해질 경우엔 ERD의 설계가 전체의 절반이상을 차지한다고 봅니다. 거꾸로 제가 겪어본 웹 관련 개발자들은 엔티티나 DB의 중요성은 경시하고 액션에만 치우쳐서 어떻게 EJB를 멋있게 쓸 것인가에만 골몰하는 경우가 더 많았습니다.

물론 개인적인 경험이므로 개인적인 견해입니다. :)

객체지향이라고 한참 떠벌리고 그게 아니면 죽음을 달라던 시절은 이미 96년도에 지나 갔습니다. 지금은 어떤 방식이 수행 작업에 가장 적절한지 판단해서 사용하는 시대입니다. 모든걸 객체지향이어야 한다는 생각은 이제 그만되었으면 하네요.

저도 이부분에 대해서는 매우 동감합니다. EJB를 왜 써야되고 어떤면에서 장점이 있는가를 파악하기보다는 EJB이기 때문에, 뭔가 있어보이기 때문에 쓰는 경우도 적지 않았습니다.

그때문인지 서블릿 수준에서 끝날 웹 어플도 EJB로 개발 하는 경우를 종종 보았구요.

CBD 방법론이나 UML 툴을 써서 설계를 하는 게 유행 비슷한 경향이 된 건 사실입니다. 하지만 CBD는 오히려 객체지향과 충돌하는 부분이 많고, 말씀하신 것처럼 UML이나 케이스툴을 쓰는 것이 곧 객체지향 설계를 하는 것은 아닙니다.

물론 엔터프라이즈 솔루션에서 엔티티의 설계는 매우 중요합니다. 하지만 여기서 말하는 '엔티티'는 절대로 데이터베이스의 테이블을 나타내는 것은 아니며 또한 ERD도 반드시 데이터베이스 스키마를 뜻하지 않습니다.

즉, 탑다운 방식으로 엔티티를 먼저 설계한다는 건 업무 분석 후에 디비 전문가가 ERWin 같은 걸로 디비 스키마를 뽑는 다는 뜻이 아니라 케이스 툴을 쓰건 안쓰건 구현하고자하는 업무의 도메인 모델을 테이블이 아닌 클래스의 관계로 나타내는 작업입니다. 그 이후에 여기에 대한 프로세스를 설계하고 마지막으로 구체적인 퍼시스턴스를 구현하는게 정석입니다.

유일한 예외라면 이미 DB가 기구축되어 있어서 다른 어플리케이션과 공유하는 경우지만 제가 아는 한 대부분의 경우 EJB를 쓰건 안쓰건 국내 웹개발 환경에서 엔티티 설계는 곧 테이블 스키마를 그리는 걸 의미합니다.

국내에서 EJB를 사용할 때 얼마나 스펙과 동떨어져 사용하고 있는지는 단적인 예로 EJB의 대표적인 장점이라고 이야기하는 선언적인 보안, 트랜잭션 처리를 들 수 있습니다. 트랜잭션은 몰라도 제가 아는 한 JAAS를 연동해서 EJB 단까지 보안을 통합해서 정석대로 구축하는 경우는 그렇게 많지 않습니다. 대부분 세션에다가 플래그 박아두고 필터도 아닌 jsp 인클루드에서 조건문으로 거르는게 일반적입니다.

물론 제가 국내의 모든 웹개발자를 만나본건 아니지만 수년간 크고 작은 업체의 많은 개발자들과 접하면서 단 한명도 객체지향적인 설계를 하는 것을 보지 못했다는 건 분명 국내 웹 SI의 어떤 심각한 문제점을 나타내는 것이라 생각합니다.

동감합니다만 이는 실무에서 개발하는 분들이 실제 객체지향, 컴포넌트 지향 등등의 장단점을 이해하고 케이스별로 가장 적합한 사례를 찾아 적용할 때만 의미가 있지 않을까요? 단순하게 '아는게 데이터베이스밖에 없어서' 객체지향을 못쓰는 것이라면 문제가 있다고 봅니다.

어쨌거나 웹개발에서 많이 쓰이는 자바 언어는 객체지향적 특성을 많이 갖추고 있고 사용하는 라이브러리, 프레임워크, 방법론 등등 모두 객체지향적 원리를 적용했을 때 최상의 생산성을 내도록 구현되어 있는 경우가 많습니다.

물론 유명한 IT 격언에 '내가 가진 도구가 망치 뿐이라면 모든 문제가 다 못으로 보인다'라는 말도 있지만 망치를 쓸 줄 몰라서 톱으로 못을 박으려 하는 것도 올바른 접근은 아닐 것입니다.

엔티티가 데이터베이스의 테이블을 나타내는 것이 아니라면 구체적으로 어떤 것을 나타내는 것인지 궁금합니다.

이건 일반적인 Top-Down 방법론 같습니다. 그리고 제가 아는한 거의 대부분의 Biz proc. 을 구현하는 경우에 있어서는 위와 같은 방법을 씁니다. 클래스의 관계로 나타내는 것은 UML 에서의 용어인 듯 하구요. 업무 플로우 차트와 DFD 등의 프로세스 설계를 거쳐 ERD를 생성해 냅니다.

맞습니다. 그런데 UML에서도 엔티티와 어트리뷰트 설계는 곧 테이블 스키마로 연결되지 않던가요? ERD가 곧 테이블 스키마는 아니지만 거의 유사하게 구현되므로 별로 무리가 없는 전개라고 생각합니다.

이건 설계에 대한 것이라기 보다는 스펙에서 제공하는 기능을 사용하지 않는다고 보여지네요. 약간 논외의 이야기 같습니다.

그런데 갑자기 생긴 의문인데요.
왜 우리나라에선 객체지향이 이렇게 푸대접을 받는지 모르겠습니다.

제가 아는 사람이 지금 영국에서 공부하고 있는데요.
공부하는 커리큘럼을 보내줬습니다.
그런데 제가 대학때 배우던거랑 많이 다르더군요.

이건 뭐 1학년 때부터 4학년 때까지 전부 객체 지향으로 되어 있던걸요.
중간 중간에 자료 구조, OS, 컴파일러(이건 OS 배울때 같이 배운다고
합니다) 등등을 배우고요.

제가 그래서 '너네 학교는 객체지향만 하냐?'라고 물어봤더니
학교측에서 객체지향을 아주 중요하게 생각한다고 하더라구요.

그런데 왜 우리는 그렇게 객체지향을 중요하게 생각하지 않을까요?
외국이 좋다라는 의미도 아니고 객체지향이 무조건 좋다라는 것도 아닙니다.
그냥 왜 우리나라와 외국의 생각의 차이가 생겼는지 궁금합니다.

제가 아는 한 DB table과 객체(Entity)는 다른 것입니다.
DB table은 객체의 persistence를 구현하기 위한 하나의
수단일 뿐입니다.
정확하게 1:1로 매치되는 경우도 있지만 그렇지 않은 경우도
많습니다.
1개의 객체가 여러개의 table에 저장될수도 있고 그 반대로
하나의 table이 여러개의 객체와 연관될수도 있습니다.

또 Top-Down 방식과 객체지향적 구현 절차에 대해서 제 의견을 말하자면,
이 둘이 상당히 비슷해 보이는 것이 사실입니다.
실제로 정보 공학과 객체 지향은 서로 밀접한 관련이 있습니다.
하지만 가장 큰 차이점은 프로그램의 구성 요소로서 객체를 생각하느냐
구체적인 DB table을 생각하느냐 입니다.

제 생각에는 UP에서 바로 객체가 스키마로 전환되는 경우는 없습니다.
뭐 객체를 저장할 구조로 그렇게 구현하기로 했다면 그대로 전환해도
별 무리는 없습니다.

대부분의 EJB 컨테이너가 배포시에 엔티티빈에 맞춰서 테이블을 생성해 주고 Hibernate와 같은 많은 수의 퍼시스턴스 프레임워크도 유사한 기능을 갖추고 있습니다. 즉, 탑다운 방식에서 데이터베이스란 단순히 데이터를 지속적으로 저장하는 장치 이상도 이하도 아님을 뜻합니다.

객체지샹 설계에서 ('UML에서'보다는 정확한 표현인 것 같습니다. 객체지향이 반드시 UML로 표기될 필요는 없으니까요 :)) 클래스의 관계로 나타난 도메인 모델이 어떤 형식으로든 퍼시스턴트 레이어에 매핑되어야 한다는 건 맞지만 여기에는 여러가지 문제점이 있습니다.

OODBMS가 아닌 이상 특히 엔티티의 상속관계(테이블이 테이블을 상속할 수 없습니다)나 1:n의 관계(FK-PK 관계는 n:1, n:m만 허용합니다), 네비게이션을 다양하게 표현할 수 없는 것 (테이블에서는 무조건 FK가 있는 쪽에서의 네비게이션만 가능합니다) 등등의 문제가 있고 이는 전통적으로 'impedence mismatch'라는 문제로 알려져 있습니다.

외국에서는 탑다운 접근 방식을 유지하면서 이런 문제를 해결하기 위해 DAO 패턴이나 O/R 매핑 솔루션, JDO/EJB 등을 고안해 냈습니다. 하지만 기본적으로 데이터베이스 스키마에서 bottom-up으로 올라오는 경우 사실상 데이터베이스 연결 관련 유틸 클래스를 제외하면 이런 '부가적'인 계층에 대한 필요를 느끼지 않는 다는 차이가 있습니다.

최근에 UML이나 MDA(모델 드리븐 아키텍쳐/어프로치) 등등이 유행하지만 이런 모든 방식은 탑다운으로 도메인 모델을 완성한 후 여기에 대한 퍼시스턴스 레이어를 얼마나 쉽고 투명하게 만들어줄 수 있나 하는데 초점이 맞추어져 있지 어떻게하면 데이터베이스 위에 상부구조를 얹을 수 있는지에 있지 않습니다.

후자의 경우라면 투게더 등의 유명 케이스툴의 UI는 클래스다이어그램에서 출발하는게 아니라 데이터베이스 테이블의 컬럼들을 선택해서 이를 클래스로 표현하는 식이 되어야 맞겠지요 (실제 이런 툴들이 있기는 합니다만...)

이런 추세에서는 데이터베이스 전문가는 어디까지나 솔루션 전체의 설계를 담당하는 사람이 아니라 객체지향에 능숙한 설계자가 O/R 매퍼를 통해 자동으로 생성한 디비 스키마를 다듬고 튜닝하는 전문가로 역할이 제한됩니다. 이런 부분이 상향식과 하향식 개발 방법론, 그리고 디비 중심적, 혹은 객체지향적 접근 방법의 근본적인 차이점이라고 봅니다.

물론 "엔티티가 곧 테이블이다. " 는 저도 틀린 말이라고 생각합니다. 하지만 ERD를 그려대는 것이 곧 테이블 설계부터 하는 것이라는 논리에서 의문이 생겨서 설명을 부탁드린 것입니다. 그렇기는 해도 실제 구현에 있어서는 거의 엔티티가 그대로 테이블로 생성되는 경우가 많습니다.그리고 제가 하고 싶은 말도 UML등의 툴을 쓰는 것은 CBD등의 컴포넌트 기반, 즉 객체지향 방법론에 적합하지 Top-Down 은 오히려 구조적인 프로그래밍을 많이 쓰는 고전적인 방법론이라는 것입니다.

여담입니다만, 엔티티는 객체 지향에서 말하는 객체가 아니라 고전적 의미의 어트리뷰트를 갖는 개체이겠지요? 객체 혹은 개체(Object)와 개체(entity)의 의미가 섞여서 표현된 것 같아 덧붙입니다.

아무래도 논의에 있어서 여러가지 개념이 불분명하게 섞여서 논지가 흐려지는 듯 합니다. 처음 시작된 것은 객체 지향이 적용되고 있느냐였는데, 워낙 그 범위가 불명확하다 보니 객체 지향적인 개발 방법론(CBD나 Use-Case tool등과 Top-Down, ERD 등의 차이), 객체 지향적 플랫폼 사용(EJB가 제대로 사용되는가), 객체 지향 DB(DAO패턴,OODB와 RDB의 차이)까지 나오고 있는 것 같습니다. :)

기본적으로 impedence mismatch 에 대한 문제는 RDB에서의 경우로 알고 있습니다. 이건 개발 방법론과는 거리가 있는 이야기입니다. 솔루션에 디펜던트한 경우이고 DB 설계에 국한되는 이야기입니다.

C로도 OOP를 할 수 있듯이 RDB로도 객체 지향 방법론에 따른 개발이 가능합니다. 거꾸로 Top-Down 방식으로도 class 설계를 거친 객체 지향형 시스템 개발이 가능합니다. 예를 들어 기업에서의 Web 서비스 개발은 보통 J2EE 가 대세를 이루고 있기 때문에 EJB를 사용해서 객체 지향적인 시스템을 개발하려고 하나 방법론은 고전적인 것을 사용할 수 있습니다. 아무래도 문제 제기 하신 분이 어떤 개념으로 객체 지향이 우리 나라에서 이루어지고 있는가 명확하게 구분하지 않으신 게 이렇게 동어반복적인 논의를 만들고 있다고 생각 되네요. :)

덧. ERD는 테이블 설계가 아니라 entity 설계인데 왜 처음에 데이타 베이스 전문가가 ERD부터 그리며 테이블 설계를 한다고 하셨는지 궁금네요. 그리고 DB 전문가와 DBA는 반드시 같은 영역이 아니라고 생각합니다. DB 스키마와 튜닝에 대한 전문가도 있고 데이타 베이스 모델링을 하는 전문가는 엔티티 설계의 전문가라고 생각합니다. 그리고 객체 지향이던 구조적이던 전문가를 구분할 필요는 없다고 생각합니다. 넓은 의미에서 "설계" 이고 어떤 "방법론"을 적용하는가를 고민하는 것이 설계자가 아닐런지요.

동감입니다.
UML은 객체지향 방법론이 난립하던 시절 표기법의 난립을 하나로 통합한
일종의 규격안 입니다.
뭐 UML을 구조적 분석/설계에 쓸수 없는 것은 아니지만 아무래도 객체지향
방법론에 맞춰진 도구입니다.

음...
정보 공학측과 객체지향측의 사용하는 언어가 좀 틀립니다.
저는 UML에서 사용되는 Boundary/Control/Entity, 이렇게 3개의
기본적인 stereo type중 하나인 Entity를 말한 것입니다.
저는 객체(Object)를 말했는데 혹시나 개체로 받아들이신건 아닌지요?

음... 구체적인 예를 드는게 서로 간의 이해를 도울 수 있을 것 같네요 :)

최근 추세는 무엇보다 도메인 모델이나 비즈니스 로직을 설계할 때 가능하면 외부 컨테이너나 어떤 특정 인터페이스를 구현해야 한다는 등의 의존성을 제거하고 순수하게 객체지향에 근거한 일반 클래스(자바에서는 POJO - Plain Old Java Object라고 합니다)를 사용해서 설계하는 것입니다.

왜 이런 경향이 생겼는지 살펴보면, 예를들어 EJB 엔티티빈을 사용하려면 원격 호출을 위해 반드시 빈 클래스 이외에도 홈인터페이스, 원격 혹은 로컬 인터페이스를 만들어야 하며 이들은 J2EE의 특정 인터페이스를 상속해야 합니다. 또한 이러한 엔티티빈 객체를 웹에서 직접 불러들이는 것은 여러가지 이유로 적합하지 않기 때문에 Session Facade나 Bulk Load 등등의 방식으로 실제 엔티티에 대응하는 도메인 클래스를 다시 만들어 변환합니다.

이런 방식에서는 다음과 같은 문제가 있습니다 :
(1) 개발이 불필요하게 복잡해 집니다
(2) 배치 디스크립터 등 벤더 종속적 의존성이 생깁니다
(3) 실제 도메인 클래스들 간에는 상속 관계가 있을 수 있어도 이에 대응하는 엔티티빈은 CBD의 특성상 상속 관계가 나오기 어렵습니다
(4) XP에서 권장하는 유닛테스트의 경우 엔티티빈은 반드시 컨테이너에서 동작하기 때문에 단순한 방법으로 유닛테스트를 적용하기 어렵습니다.

다시 본론으로 돌아가서, 이런 문제를 극복하기 위해 나온 경량 컨테이너/퍼시스턴스 프레임워크의 대표적인 스프링/하이버네이트의 조합을 예로 들겠습니다.

(1) 어떠한 종속성도 없이 순수하게 요구사항에 대한 도메인 모델을 일반 클래스로 구현합니다. UML 기반 CASE 툴이나 MDA를 지원하는 툴을 사용하면 자동으로 생성할 수도 있습니다.

(2) (1)의 결과물인 도메인 모델을 바탕으로 데이터베이스 스키마와 실제 테이블을 자동 생성합니다. 이의 결과물은 데이터베이스 전문가에게 넘겨 튜닝작업을 병행합니다.

(3) (1)의 도메인 모델을 사용하는 비즈니스 계층을 역시 의존성없는 일반 클래스로 구현합니다. 트랜잭션이나 퍼시스턴스에 필요한 세션 등등의 모든 리소스는 외부에서 IOC(Inversion of Control)의 방식으로 제공하기 때문에 코드 자체에 의존성은 불필요합니다.

(4) (1) + (3)으로 구성된 백엔드 어플리케이션에 웹단의 프론트 엔드를 제작합니다, 주로 Struts 등의 MVC 구성을 이용합니다.

이런 방식이 최근에 유행하는 웹개발의 best practice이고 보시다시피 철저하게 탑다운 접근 방식이 중시되고 있습니다.

반면에 우리나라의 전통적(?) 접근 방식을 보겠습니다 :

(1) 데이터베이스 전문가가 ERD를 그립니다.
(2) 사용할 데이터베이스에 맞는 커넥션 관련 유틸 클래스를 제작합니다.
(3) 각각의 비즈니스 로직을 위해 적절한 SQL 쿼리를 날리고 생성 결과를 반환하는 클래스를 작성합니다.
(4) (3)을 이용해 jsp 페이지를 만듭니다.

일부의 경우 (3)과 (4) 사이에 그나마 객체지향적 접근을 위해 쿼리를 담을 수 있는 모델을 설계하기도 하지만 많은 경우에 문자열 배열이나 벡터 혹은 맵에 다 때려 담아 넘기는 등의 구현도 많습니다. 이 경우 아예 '도메인 모델'이란 개념 자체가 없는 설계지만 설사 이런 중간단계의 모델을 설계 했다고 해도 탑다운에 비해 명확한 제약이 있습니다.

즉, 모델이 나타내는 건 직접적인 비즈니스 요구사항(requirement)가 아닌 특정 쿼리에 대한 결과 집합입니다. 즉, 비즈니스 로직과 엔티티는 테이블 스키마와 이에 대한 SQL 쿼리가 표현하는 반면, 실제 사용되는 클래스는 단순히 이 결과 값을 전달하기 위한 도구에 지나지 않습니다. 따라서 SQL이나 디비 스키마가 상속이나 클래스의 다양한 관계를 표현할 수 없는 이상 여기에 대한 모델 역시 동일한 문제를 지닙니다.

또한 비즈니스 로직이 SQL로 표현되는 관계로 쿼리가 복잡해지고 데이터베이스 벤더에 종속적이 될 수 있습니다.

EJB를 쓴다고 해도 이런 모델에 적용하면, 데이터베이스와 코드 사이에 단지 복잡한 계층을 덧붙여 생산성을 떨어뜨리는 결과 이상을 기대하기 어렵습니다.

대부분의 CASE 툴이 UML, 그 중에서도 클래스다이어그램을 중심으로 구성되어 있다는 점만 봐도 이런 객체지향적인 탑다운 접근 방식의 이점을 잘 알 수 있지 않나 생각합니다...

impedance mismatch는 솔루션에 국한된 이야기라기 보다는 RDBMS를 객체지향언어로 다루는 이상 피할 수 없는 문제입니다. 다만 탑다운이 아니라 데이터베이스 중심적인 설계를 할 때 그 문제점이 더 극명히 드러날 뿐입니다.

DB 전문가와 DBA는 물론 다릅니다. 하지만 튜닝등의 분야가 아니라 데이터베이스 모델링 자체만 놓고 본다면 점차 비중이 떨어지는 추세에 있는 것만은 분명합니다. 이런 시대의 변화가 바로 탑다운으로 도메인 모델에서 자동으로 퍼시스턴트를 관리하는 설계가 늘어나기 때문이 아닌가 싶네요...

글이 밀려서 어뚱한 곳에 글을 올리게 되었습니다.
급히 읽으시는 분이 계시면 마치 조선일보식 처럼
엉뚱하게 받아들일수도 있겠는데요? :lol:

객체의 중요한 특성(?)중 하나가 persistence 입니다.
어떻게 객체의 속성(attribute)를 프로그램이 끝난후 또는
다른 위치에서도 유지할수 있는가가 객체지향의 주요
논의점중 하나였습니다.
그래서 ODMG(Object Data Management Group)가 생겨나게
되었습니다.

이제는 그 결과 Hibernate, JDO, Turbin 등등 수많은 도구들이
생겨났습니다.
아참 EJB는 종합선물세트지만 어쨌든 EJB도 여기에 속한다고 할수
있습니다.

지금 이야기의 흐름이 주제와 벗어나긴 했지만 중요한 주제를
다루고 있다고 생각합니다.

저도 사실은 이야기의 주제를 바꿔보고자 중간에 글을 하나 썼는데요.
그냥 위로 쭉 올라가 버리고 말았습니다.

어떻게 하는게 좋을까요?
원래의 주제로 돌아가는게 좋을까요?
아니면 지금의 것으로 하는게 좋을까요?

자꾸 드는 의문입니다만, CBD 는 EJB의 특성이고 Top-Down 개발 방식이 객체 지향 개발 방법론에 쓰인다고 하셨는데요, CBD 방법론 자체가 바로 클래스 다이어그램을 중심으로 개발하는 방법론으로 알고 있었는데 어떻게 된 일인지요.

두번째 예시에서 ERD부터 그린다고 하셨습니다만...객체 지향 방법론을 쓰지 않는 경우에도 ERD부터 그리지는 않습니다. User request 에 대한 Biz Logic 분석을 위해 플로우 차트부터 생성을 하고 거기에서 DFD를 그린 후에 프로세스별 엔티티를 정의하고 통합하여 릴레이션을 생성해 나갑니다. 이 부분이 ERD 작성입니다. SQL 쿼리에 Biz Logic을 담을 수도 있지만, 순수히 Table로 정의되는 logic 외의 것은 function을 정의하여 묶을 수도 있고 나름대로 class를 정의하여 사용하기도 합니다. 이것이 사용하는 접근 방식이 다를뿐 유스케이스 다이어그램부터 시작하는 것과 비교할 때 Top-Down이라고 하지 못할 이유는 없다고 봅니다. 제가 알기로 다양한 User Requirement에보다 유동적으로 대응할 수 있고 관계를 쉽게 파악할 수 있는 모델이 Use-Case Diagram 일 뿐이지 고전적 방법론이 ERD부터 그려나가는 거라고는 알고 있지 않습니다.

'Persistence'라는 말 자체가 객체지향적인 사고와 데이터베이스 중심적 사고의 간극을 잘 나타내고 있는게 아닐지요... 실제 실무에서 교육을 할 때 개발자에게 'persistence'라는 개념을 이해시키는 것보다 어려운 점은 없습니다.

디비 중심에 익숙해지면 웹단에서 디비에 있는 걸 끌어와서 보여주고 반대로 입력한 걸 넣어주면 되는거 아니냐? 도대체 왜 복잡하게 별도의 계층이 필요하냐?라고 반문 하는 경우가 많습니다.

그런 경우 저는 데이터베이스 없이 클래스로만 게시판 프로그램을 짜보라고 권합니다. Board 클래스를 만들고 Thread, Message 등등의 클래스와 이를 연동하는 BoardManager를 만들게 한 후 "이렇게 구현했을 때 JVM이 종료하면 Board나 Thread 등등의 인스턴스가 사라진다. 바로 이 문제를 해결하는 것이 persistence이다"라고 설명하면 이해가 빠른 것 같습니다 :)

음.. 그리고 쓰레드에 대한 문제는 주제가 크게 벗어나지 않으면 어차피 많은 사람들이 토론을 하는 주제도 아니니 굳이 별도의 쓰레드를 달 필요는 없을 것 같다는 생각입니다.

앗..저도 하고픈 말 한마디만 하겠습니다. 물론 개인적인 경험에서 우러나온 것입니다. UML tool 써서 Use-Case Diagram 설계 후에 entity까지 유도해서 class 까지 스크립트로 생성시켜 바로 사용할 수 있는 경우는 못봤습니다. 거의 90% class는 재 설계를 해야되더군요. :)

ERD는 테이블 스키마가 아닌데 ERD 달라면 테이블 스키마 준다. 그러므로 설계부터 ERD 그리는 건 테이블 설계부터 하려는 데이타 베이스 중심의 사고방식이다. - 제가 맞게 이해한 것인가요?

따라서 클래스다이어그램이나 CASE 툴은 오히려 후자보다 전자의 방식에 더 적합합니다.

약간 제 생각을 전달하는 과정에 문제가 있었던 것 같습니다. 요구사항 수집을 제외하면 오히려 탑다운이던 아니던 ERD 부터 접근하는게 일반적입니다. 문제는 그 ERD가 클래스 사이의 관계로 표현되는지 테이블 스키마로 표현되는지가 아닐까요?

그리고 어떤 독립적인 기능(펑션)의 묶음이 클래스가 되는 것은 객체지향적인 특성은 아닙니다. 물론 유틸클래스도 존재하지만 객체지향적인 특성은 속성과 동작이 합쳐져 그 자체로 비즈니스 로직을 나타낼 때 의미가 있는게 아닌지요...

넵. 문제는 제 경험상 실제로 실무에서 대부분의 경우 초기 접근을 RDBMS의 테이블 스키마를 그린다는데 있다는 뜻이었습니다.

즉, 요구사항 수집도 안하고 엔티티부터 그린다는게 아니라 엔티티 설계는 곧 RDBMS 설계라고 동일시하는 관행을 이야기 한 것입니다.

비록 형태는 비슷하지만 프로그램의 구성 요소로 보는 것이 다릅니다.
그래서 비 객체지향에서 객체지향으로 전환시에 어떤 관점의 변화
(paradime shift)가 필요하다고 객체지향의 전문가가 어떤 책에서 쓴걸
본적이 있습니다.
저도 그의 생각에 동의하구요.

사실 ERD부터 그리는 것은 나쁜 것 입니다.
마치 기본적인 분석/설계도 하지 않고 바로 코딩에 들어가는 것 처럼 말입니다.
구조적 분석/설계, 정보 공학쪽에서도 그렇게는 하지 않습니다.

저는 정보 공학도 좋아하고 구조적 분석/설계도 좋아합니다.
그리고 객체지향적 방법론도 좋아합니다.
모두들 다 장점과 단점을 가지고 있기 때문에 어떤 특정한 상황에
써야지 최대의 효과를 얻을수 있습니다.

구조적 분석/설계에서는 절대 ERD 부터 그리는 것을 추천한적도 없고
그렇게 하지 말라고 반대하는 입장에 있습니다.
fender님도 아마 이 말에는 적극 찬성할 것입니다.

하지만 실무에서는 그렇지 않은 경우를 몇번 본적이 있습니다.
당장 납기일에 맞춰야 한다는 명분으로 그런 프로그램 개발 단계를
간단히 skip해 버리더군요.

fender님은 아마도 이런 현실에 대해서 말했을 거라고 생각합니다.
그리고 절대로 구조적 분석/설계에서 ERD 부터 먼저 그리지 않습니다.
적극 동감합니다.

요구 사항 수집 과정 후 설계과정에서 바로 ERD로 들어가지 않는다는 의미입니다. 만약 그렇게 하는 설계자가 있다면 그건 방법론을 '잘못' 적용한 것이지 방법론 자체가 잘못됐다고 보긴 어렵습니다.

그리고 펑션 묶음이 클래스가 된다는 의미가 아니라 펑션 묶음을 사용할 수도 있고(이건 util 적 성격의 모듈이 되겠지요. 혹은 Stored Procedure가 될 수도 있겠구요.) class 를 설계하여 사용할 수도 있다는 의미였습니다. 물론 어트리뷰트와 method를 포함하고 있어야 class의 기본 요건을 만족한다라는 기초 개념은알고 있습니다. :)

한참 타자쳐서 글을 올리면 위로 쭉 올라가 있더군요. :P

그런데 왜 우리나라에서는 객체지향을 쓰지 않게 된거죠?

즉, madhatter님께서는 게시판을 구현하기 위해서 '게시판', '게시물', '쓰레드', '사용자' 등등의 클래스를 먼저 구현하고 여기에 대해 퍼시스턴스 계층을 추가하는 개발자를 몇 명이나 보셨나요? 반대로 MESSAGE, BOARD, USER 테이블을 먼저 생성하고 이에 대한 쿼리 날리는 클래스를 얹는 경우가 훨신 일반적이지 않았나요? 별 차이가 아니라고 생각하실 수 있지만 이는 근본적인 패러다임의 차이입니다. 이 부분은 이야기가 나오면 더 설명 드리겠습니다 :)

"부분적으로 쓰고 있다." 라고 말씀드리겠습니다. 실제 SI에서 가장 큰 문제는 솔루션도 아니고 개발 방법론도 아닌 "납기" 입니다. 그리고 Client 의 요구사항은 하루가 다르게 변화합니다. 거기에 겹쳐서 개발자들의 "객체 지향"에 대한 인식이 천차 만별인 것도 있습니다. 그 이유로 보자면 IT라는 영역이 진입장벽이 낮은 것에서부터 시작할 수도 있겠습니다만..그건 길어지니 논외로 하고, 현실적으로 다양한 requirement를 충족시킬만한 객체 지향 설계를 능숙하게 할 인력이 부족하다고 봅니다.

구조적 접근도 이상적으로 되지 않는데 객체 지향적 접근이 이상적으로 될 수는 없는 것 아닐까요?

음, 확실히 이건 패러다임의 차이이겠네요. 하지만 제가 본 대부분의 개발자는 테이블에 대한 개념이 없습니다. UI의 액션에 대한 개념만 있습니다. 클래스를 먼저 생각한다기 보다는 UI 설계를 먼저 하고 그 구현을 위한 class 를 생성한 다음 필요한 데이타를 넣기 위한 도구로 DB를 생각합니다. 어떤 개발자는 그러더군요.

"필요한 칼럼이 A,B,C 입니다. 해보고 나중에 필요하면 더 넣고.."
"일단 데이타 넣어보고 운영하다가 느려지면 Index 추가하고..."

제 생각은 퍼시스턴스 개념이 없어서 클래스와 분리시켜 DB를 중요시 한다기 보다는 엔티티에 대한 물리적 계층이 DB가 가장 근접하기 때문에 설계에서 DB를 중요시 하는 것이 아닌가 합니다. 개발만 중요시 한다면 객체 지향적 방법론이 이상이겠으나 운영상의 문제를 생각한다면 반드시 이상적이라고 할 수 없습니다. 실제로 DB 스키마를 변경하는 것이 비용이 훨씬 많이 발생하기 때문입니다.

언제부터 그렇게 됐는지 모르겠지만 업계에서는 분석/설계가를 불필요하게
생각하는것 같습니다.
오직 코딩만 하는 사람만을 필요로 하구요.

사실 저는 좀 운이 좋은 경우로 제 주위에 분석/설계만 집중적으로 하는
사람들이 몇명 있습니다.
그 사람들에게도 많이 배웠구요 제 스스로 그쪽으로 공부도 많이 했습니다.
하지만 그 선배들의 경우를 보았을때 참 우리나라 IT쪽의 앞날이
막막하더라구요.

선배들은 지금 거의 외국으로 나갔습니다.
아직 우리나라에 있는 분들은 외국에 나갈려고 준비하는 사람과
영어를 배우는 사람으로 나뉘어 있습니다.
빨리 외국으로 진출하려구요.

납기에 대해서 말씀하셨는데, 맞습니다.
납기가 가장 중요하지요.
한편으로 프로그램의 품질도 아주 중요하다고 생각합니다.

그냥 저의 의견으로는 우리나라에서 만들어진 프로그램의 경우
그 품질이 아주 낮다고 생각해본적도 있습니다.
왜냐하면 한번 프로그램을 만들고 나서 그것을 확장시키는 경우를
보지 못해서요.
그냥 처음부터 다시 만들곤 하는 경우를 많이 봤습니다.

객체지향을 함으로써 얻어지는 효과중에 하나가 DB 스키마를 변경시켜도
프로그램을 수정하는 범위와 노력이 현저하게 줄어드는 현상이 있습니다.

물론 객체지향을 어설프게 적용시켜서 뭐 오히려 수정하는데 드는 노력이
늘어나는 경우도 있고요.