한국에서는 대부분의 소프트웨어 관련 프로젝트는 성공한다. 하지만 프로젝트에서 만들어진 제품이나 시스템이 제대로 사용되는 비율로 따져 보면 50% 아니 20 ~ 30%도 안될 것이다. 한국에서의 프로젝트 실패는 프로젝트와 관련된 여러 구성원들의 "피"를 의미하기 때문에 프로젝트 종료 시점에서 실패라는 단어를 언급하지 않는 것이 불문율이라 할 수 있다.
역사는 항상 반복된다고 한다. 소프트웨어 개발에서도 역사는 반복된다. 과거에 실패한 사례를 분석하여 더 이상 똑같은 실수를 하지 않는 프로젝트/기업만이 진정한 "성공"을 잡을 가능성이 높다.
한국의 "실패" 라는 단어를 두려워하는 문화때문에 국내의 프로젝트 또는 회사에 대한 실패 경험담은 거의 전무하다. 이 책은 미국의 사례이기는 하지만 우리가 잘 알고 있는 IBM, 마이크로소프트, 애플 등의 잘못된 사례에 대해 아주 자세하고 재미있게 묘사하고 있다. 노벨을 고질라에 비유하고 이 고질라를 무너뜨린 NT를 광선검에 비유하고 있으며, Windows98과 NT를 거의 비슷한 시기에 출시하여 고객들에게 어떤 제품을 구매해야 할지 혼동을 일으키게한 마이크로소프트의 실수를 이야기 하고 있다. 마이크로소프트 성공의 시작을 알리는 IBM과의 MS-DOS 계약에 대한 숨겨진 이야기 등 80 ~ 90년대에 춘추전국 시대를 방불케 했던 수 많은 소프트웨어 회사와 제품이 어떻게 실패했는지에 대해 설명하고 있다.
이 책의 주요 내용은 개발 기술에 대한 내용은 아니지만 자신이 만든 소프트웨어가 고객에게 사랑받지 않고 CD에 담긴채 서랍에 쳐박혀 있거나, 자신이 만든 서비스에 고작 하루에 100명 정도의 사용자만 다녀가지 않게 하기 위해서는 개발자들도 이런 종류의 책에 관심을 가져야 한다.
국내에서도 이 책과 같이 프로젝트, 제품, 회사의 실패를 다룬 많은 정보가 공유되고 실패의 원인에 대한 분석이 이루어 지기를 바란다.
정말로 소설일까 하고 하는 의아심이 있었지만 처음부터 끝까지 동시에 진행되는 6개 상용 소프트웨어를 개발하는 관리자가 주인공이 되어 다양한 등장인물과 함께 이야기를 풀어가는 소설이었다.
책의 내용은 많은 생각을 하게 하였다. 그리고 지금까지 내가 알고 있는 소프트웨어 개발에 대한 지식은 단순히 기술적인 문제에 불과하다라는 것을 인식하게 되었다. 그나마 형식이 소설이기 때문에 "그런 것들은 소설이니까 가능할 거야" 라는 위안을 삼으면서 읽어 나갔다.
하지만 현실은 그렇지 않을 것이다. 이책에 나오는 많은 내용들은 소설속에 나오지만 실제로도 많은 선진 프로젝트에서 이미 사용하거나 연구되고 있을 것이다.
우리의 현실은 어떤가? 제대로된 소프트웨어 공학 연구소 하나 없는 상황이고, 현재의 국내 소프트웨어 개발의 현실과, 문제점, 이를 개선할 수 있는 방법등에 대한 연구 등은 진행되고 있지 않은 것 같다. 물론 이미 진행되거나 성과를 낸 조직도 있을지도 모른다. 하지만 실제 프로젝트에는 이런 소리가 들리지 않는 것을 보면 소설에서 보는 것처럼 활발하게 연구되지는 않는게 확실하다.
필자도 이제 막 사내에서 연구소라는 곳으로 부서를 옮겼다. 필자의 예상대로 전문화된 연구소라기 보다는 회사의 신규 사업 진출을 준비하는 수준으로서의 연구 활동만 수행하고 있다. 지금은 부서를 옮긴지 얼마 되지 않아서 어렵지만, 언제 한번 마음먹고 국내, 아니 좁게는 필자가 다니는 회사의 소프트웨어 관련 연구에 대해서 글을 한번 써야 겠다고 마음을 먹었다.
책에서 내용 중에 다른 것은 고민해 볼 내용들이지만 당장 실천할 수 있는 것은 주인공인 '톰킨스'가 프로젝트를 진행하면서 새로 배워나가는 것들을 메모하는 습관이다. 프로젝트가 종료되었을 때에는 노트에는 100여개의 새롭게 배운 내용들이 정리되어 있었지만 주인공은 이 노트를 출판사에게 넘기고, 자신은 가져 가지 않는다. 이미 자심의 가슴속에 있다고 하면서...
이것은 필자도 당장 내일부터 적용해 볼까 한다. 그러기 위해서는 아주 비싼 노트를 한권 살 작정이다. 비싼 노트라야 잃어버지지 않게 주의하고 돈을 주고 산만큼 그냥 버려두지는 않을 것 같다라는 생각이다.
두번째는 프로젝트 관리자 또는 상급자로서 가져야할 자질이라 생각하는데, 주인공 '톰킨스'는 많은 프로젝트원들과 중간 관리자로부터 존경을 받고 그들은 스스로 적극적으로 일을 추진하고 있다. 이것의 원인을 책에서는 "사람들이 그를 좋아해서가 아니라, '톰킨스'가 그들을 좋아하기 때문이다." 라고 말하고 있다. 그것이 '톰킨스'가 가지고 있는 힘이라고 했다.
자바지기 스터디에서 북크로싱 행사에서 안용상님이 추천한 책이다.
최근 나의 책상에도 보고싶은 책들이 줄지어 기다리고 있고, 아침마다 새롭게 생겨나는 블로그들...
이전에는 1시간 정도 투자하면 대충 정리되었지만 이제는 혼자서 감당할 수준을 넘어설 정도로 많은 정보를 접하고 있는 현실이다.
과거보다 정보가 많아져서 그럴수도 있겠지만 나의 관심의 분야가 과거에 비해 그 만큼 넓어졌다는 증거이기도 하다. 하지만 너무 벅찰 정도 많은 정보이다.
이런 시기에 아주 적절한 책을 읽은 것 같아 추천해준 안용상님에게 감사하다는 말을 전한다. 용상아 고마워...
이 책은 라이코스 검색 팀장으로 검색과 뉴스 서비스를 총괄한 전병국님이 자신의 정보관리 철학을 정리한 책이라고 할 수 있다. 바쁜 업무와 짧은 시간을 핑계로 책 한권 읽지 않는 많은 개발자들에게 권하고 싶다.
책에서는 정보를 지배하기 위해서는 DeCaff(디카페인)을 강조한다. 카페인의 중독성에 반대되는 개념이라 할 수 있다.
첫째, 나에게 중요한가?
1. 아니면 버린다.(Delete)
2. 중요하면 내 것으로 바꾼다.(Change)
두번째, 급한가?
3. 급하면 실행한다(Act)
4. 아니면 저장한다(File with schedule)
요즘 블로그에 글 올릴 시간도 없을 만큼 정신이 없다.
자바지기 스터디를 시작했고, 사내 자바 커뮤니티 활성화를 위해 많은 사람들을 만나고 있다. 그리고 보안 관련 애플리케이션을 만들고 있다. 너무 많은 일을 벌린 것 같아 내심 조금 걱정은 되지만 그래도 반드시 뭔가를 이루고 말겠다는 새해 아침의 다짐을 다시한번 새겨본다.
이런 바쁜 와중에도 출퇴근 버스 안에서나 여유시간에 계속 앞의 블로그에서 소개한 "세계는 평평하다: 라는 책을 읽고 있다.
이 책을 읽고 있으면 나도 모르게 미국, 인도, 중국, 유럽을 자유롭게 돌아다니고 있는 듯한 착각을 한다.
지금 읽고 있는 부분에서 국내 상황은 어떠한가 하고 잠깐 생각해봤는데 다음과 같은 내용이다.
과거 1990년대말, 2000년대 초에서는 인도, 중국의 많은 기술 인력들이 미국에서 많은 활동을 했고, 미국으로 가기 위해 미국비자발급받기 라는 책이 나올 정도 였다고 한다.
하지만 지금의 인도, 중국의 상황은 굳이 미국에 가지 않고도 자신의 나아에서 얼마든지 미국에서와 같은 생활을 유지하고 자신이 하고 싶은 일을 할 수 있기 때문에 중국, 인도의 유능한 엔지니어들이 더 이상 미국행 비자를 받는 줄에 서 있지 않다는 것이다.
책의 저자처럼 중국, 인도를 방문하여 거기서 성공한 몇몇 젊은 엔지니어와 토론을 한번 해보고 싶다. 정말로 그렇게 생각하고 있는지. 우리나라의 S/W 개발 환경과 무엇이 틀린지 직접 내눈으로 보고 내귀로 들어보고 싶다.
최근에 80 ~ 90년대 발표된 글이나 논문에 많은 관심을 가지고 있습니다. 하지만 실제로 마음잡고 읽지는 않았습니다. 과거 기술에 관심을 가지는 이유는 최근 새롭게 발표되거나 만들어지는 툴들이 한순간에 만들어지지 않았다는 생각에서 입니다.
컴퓨터는 거의 미국에서 시작하여 미국이 주도적으로 이끌어 나가고 있습니다. 이들은 60 ~ 70년대의 준비기를 맞아 80 ~ 90년대에 적극적으로 산업에 적용하고 연구하면서 지금과 같은 부흥기를 맞이하고 있지 않나 생각합니다. 우리에게는 이러한 역사가 없습니다. 과거가 없이 미래는 없습니다. 우리에게 과거가 없으면 그들의 과거에서라도 배워야 하지 않을까요.
최근 개발자들이 고민하고 있는 미래에 대한 불확실성을 해소시키기 위해서는 우리나라의 소프트웨어 산업도 탄탄한 기본기를 갖추고 그 위에 새로운 응용된 기술을 주도적으로 만들어 가야 합니다. 그러기 위해서는 과거 기술에 대한 공부가 필수가 아닐까요?
Java의 새로운 버전이 나오면서 추가되는 개념들은 LISP에서 많이 따오고, eclipse의 여러 개념들도 emacs에서 나오고 있습니다.
이런 측면에서 최근에 읽고 있는 책인 "누가 소프트웨어의 심장을 만들었는가" 라는 책에 나오는 주요 링크를 정리해 보았습니다.
1년 동안의 집필 과정으로 통해 드디어 출판되었습니다.
개인적으로는 두번째 책입니다. 2004년 겨울 정도에 출판 되었으면 더 좋았을 것이라는 아쉬움이 있지만...
책의 주요 내용은 객체지향으로 분석설계된 도메인 모델을 어떻게 POJO로 구현할 것인가에 대한 내용입니다. OR Mapping 관련 구현 기법 등에 대해 많은 부분을 설명하고 있습니다.
머리말에도 언급하고 있지만 책의 내용 중 일부는 현재 관점에서는 틀린 내용도 있을 수 있고 더 좋은 기법이 있을 수 있습니다. 책으로 출판하면서 책에 일부 오류가 있다고 하는 것은 독자에 대한 집필자의 책임이 아닌 줄 알지만 빠르게 변화고 있는 기술환경에서는 어쩔수 없다라고 변명을 해봅니다. 의견이 있으신 분들은 언제든지 메일 또는 블로그에 남겨 주세요.
머리말
책의 주요 내용은 EJB를 이용하지 않고 순수자바객체(POJO, Plain Old Java Object)를 이용하여 컴포넌트를 구현하는 방법에 대해 설명하고 있다. POJO를 이용하여 컴포넌트 내부를 구성하는 방법에는 많은 방법을 사용할 수 있지만 본 글은 도메인 모델의 구축과 그것에 대한 구현을 주제로 하고 있다. "도메인모델"이라는 용어를 처음 접하는 독자들은 객체지향에서 말하는 클래스, 상속, 객체와의 관계를 이용해서 시스템 대상 업무를 모델링 한 것이라고 생각하면 된다. POJO로 컴포넌트를 구현하기 위해서는 객체지향적인 구현 기법을 익히는 것이 필수이기 때문에 글의 대부분의 내용은 객체지향을 이용하여 엔터프라이즈 애플리케이션을 구현하는 방법에 집중하고 있다.
많은 책들이 EJB 또는 컴포넌트를 설명하고 있지만 컴포넌트 기반으로 이동하는 전 단계인 객체지향의 구현 방법에 대해 설명하고 있는 책들은 많지 않다. 객체지향적 사고나 구체적인 구현 기술에 대한 가이드가 없다면 방법론 자들이 주장하는 컴포넌트 기반 개발의 모든 내용들은 허구에 지나지 않을 것이다. 필자는 컴포넌트 기반 개발 방법을 평가 절하하려는 것이 아니라 컴포넌트를 도입하기 위해 우리의 개발조직, 개발자의 역량은 성숙되었는지에 대해 의문을 제기하는 것이다.
객체지향은 복잡한 비즈니스를 이해하기 쉽게 접근하고 구현할 수 있는 방법을 제시하고 있다. 그리고 과거 몇 년 동안의 노력으로 이제 객체지향 기술은 엔터프라이즈 시스템에 적용하기에 충분하고 이미 많은 사이트들이 객체지향을 이용하여 구축되었으리라고 생각한다. 이런 기술적인 성숙에도 불구하고 국내에 나와 있는 대부분의 책들은 EJB의 스펙만을 설명하거나 각종 프레임워크에 대한 사용 매뉴얼(user's guide) 수준으로 언급된 내용들뿐이다. 객체지향 기술을 기업의 엔터프라이즈 애플리케이션에 적용하기 위해서는 모델링 기법, 객체와 관계형 데이터베이스의 매핑 기법, 각종 패턴의 활용, 성능과 관련된 문제 등 많은 내용들을 이해해야 한다. 이런 기술적인 성숙에도 불구하고 아직 해결되지 않는 많은 문제들이 있다. 이런 문제를 해결하기 위해서는 개발자 스스로가 다양한 사례와 이론들을 공론화하고 토론해야 하지만 아직까지 국내 객체지향 개발 커뮤니티는 이런 단계까지는 진행하지 못한 것 같다.
이 글의 내용은 객체지향을 이용한 엔터프라이즈 애플리케이션 구축과 관련하여 소스 레벨에서의 구현과 관련된 주제를 다루고 있다. 글을 읽는 독자들에게는 조금 미안하지만 글에서 주장하는 많은 내용들이 틀릴 수 있고 이미 누군가 만들어서 사용하고 있는 것일 수 있다. 하지만 이 글을 통해 여러 개발자들이 토론할 수 있는 기본적인 자료가 되었으면 하는 것이 필자가 글을 쓰기로 결심한 이유임을 이해해 주기 바란다.
필자가 처음 객체지향 기법을 접하고 엔터프라이즈 애플리케이션에 적용하고자 했을 때에는 이것은 풀 수 없는 수수께끼의 연속 같았다. 하나를 해결하면 또 다른 수수께끼가 나타나고, 외국의 웹사이트 또는 여러 참고 서적에 흩어져 있는 조작들을 모으고, 그래도 없는 부분은 직접 만들어서 붙이고 하는 작업의 반복이었다(외국의 많은 사이트의 경우 전체 소스를 공개해 놓은 사이트는 매우 드물었다). 이것은 너무 고통스러운 작업이었으며 프로젝트를 진행하면서 퍼즐을 맞춘다는 것은 거의 불가능의 작업이었다. 약 2년에 걸친 조각 맞춤이 지난 후에야 실제 사용할 수 있을 정도의 모습이 나타났으며 아직까지 이 조작 맞춤은 진행형이라고 할 수 있다.
최근에는 Hibernate, ibatis, TopLink 등과 같이 많은 O-R 매핑 도구가 나타나고 있으며 이들이 주장하는 것은 이제 더 이상 O-R 매핑 도구는 프로젝트 자체에서 만들 필요가 없다고 한다. 물론 이것은 맞는 말이다. 여러 사이트에서 검증된 좋은 도구들이 많은데 굳이 새로운 것을 만들 필요는 없다. 하지만 그러한 도구들을 사용하는 개발자들이 O-R 매핑에 대한 개념을 충분하게 이해하지 못한 상태에서 사용했을 때에는 더욱 심각한 문제를 초래할 수 있다. 이 책에서는 O-R 매핑 도구를 만들어 가면서 왜 이러한 기능들이 필요하며 어떻게 사용해야 하는지에 더 많은 의미를 두고자 한다.
이 글은 현재 자바를 이용하여 엔터프라이즈 애플리케이션을 개발하고 있거나, 이미 개발된 시스템을 유지보수 하고 있는 개발자를 대상으로 하여 작성하였다. 따라서 글의 내용을 이해하기 위해서는 Java 언어의 기초 지식과 J2EE 중 JSP & Servlet, 그리고 JDBC와 같은 기본적인 개념은 이해하고 있어야 한다. 하지만 EJB에 대한 사항은 자세하게 알지 못해도 글의 내용을 이해하는데 어려움은 없을 것이다.
책이 초반부에는 TDD(Test Driven Development) 기법을 적용하여 테스트 코드를 먼저 만들고 실제 코드를 만드는 방식으로 전개하고 있다. 이것은 동일한 기능을 수행하는 코드를 다양한 방식으로 접근해보고, 각각의 장점과 단점을 이해하는 방식으로 진행되기 때문에 변경된 코드의 정상적인 기능 수행여부를 확인하는 방법으로 TestCase를 사용하고 있다. 책의 후반부로 넘어갈수록 필자는 TDD를 사용하지 않는데 이유는 복잡해지는 프로그램에 대한 테스트 코드 작성의 경험부족이다. 테스트 코드에 대한 경험이 없는 내용을 활자화한다는 것에 대한 두려움으로 뒷부분에서는 테스트 코드의 작성을 포기하였다. 하지만 분명하게 강조하고 싶은 것은 이것은 필자의 경험의 부족으로 인한 것이지 결코 자동화된 테스트 코드를 만드는 것이 어려워서가 아니라는 것을 밝혀두고자 한다.
목차
패러다임의 변화
- 도메인 모델(Domain Model)
- 도메인(domain)
- 도메인 모델(domain model)
- object vs. table
- 도메인 모델의 장/단점
- Emp, Dept 도메인 객체
- 도메인 객체를 이용하는 클라이언트
- O-R(Object-Relational) Mapping
도메인 객체 로딩
- 구조적 프로그래밍 vs. 객체지향 프로그래밍
- 연관관계 객체의 로딩(JOIN)
. 도메인 객체의 equals() 메소드
. Mapper(Data Access Object)
. DomainKey 클래스
. DomainObject 클래스
. DBMapper
. 객체는 유일해야 한다
. 트랜잭션
. 트랜잭션 관리와 객체 Pool
. 1:N 관계 로딩
. AssociationLoader
. JOIN 로딩의 문제점
. JOIN 로딩 정리
- 연관관계 객체의 로딩(CASCADE)
- 연관관계 객체의 로딩(Lazy 로딩)
. VirtualList
. 1:1 관계에서의 lazy load
객체 대 테이블 매핑
- 기본 매핑
. 하나의 테이블로 매핑(Single Table)
. FK를 이용한 매핑
- 상속관계매핑
. 모든 클래스를 하나의 테이블(One table for all classes)
. 하나의 클래스에 하나의 테이블(One table for one class)
. 하나의 구체화된 클래스에 하나의 테이블(One table for one concrete class)
- 연관관계매핑
. FK를 이용하여 매핑
. 연관관계 테이블 이용 매핑
게시판 로딩 구현
- 답변형 게시판 설계내용
- 객체-테이블 매핑
- 개발 환경 구성
- 구현을 위한 클래스 다이어그램
- User, Board
- Article, ArticleFile
- 상속 관계의 Mapper
- Article User 관계설정
- Article ArticleFile 관계 설정
- TopArticle Board 관계 설정
- ReplyArticle Article 관계 설정
- 게시글 목록조회
- 게시글 상세조회
객체의 저장
- 객체의 트랜잭션 처리
- 객체의 생성
. 트랜잭션 Pool
- 트랜잭션의 시작/종료/오류
. TxAdapter
. DBMapper의 insert 기능
. TxManager의 트랜잭션 종료 처리
- 객체의 수정
. Dirty flag
. 수정 기능 추가의 편의성
. 1:1 연관관계 수정(Emp Dept)
. 1:N 연관관계 수정(Dept Emp)
. AssociationMapper를 이용한 연관관계 Update 처리
. DomainList
. AssociationList
. 1:N 연관관계에서의 객체 생성(Dept Emp에서 Emp 생성)
. 1:N 연관관계에서의 객체 생성(Dept Emp에서 Dept 생성)
. VirtualList
- 객체의 삭제
- N:N 관계에서의 연관관계 저장
- 양방향 관계에서의 수정/삭제 처리
- 저장소가 DBMS가 아닌 경우 Persistency 계층 구성(SAP/R3)
게시판 적용
- 객체의 로딩
- 게시글 등록
- 게시글 수정
- 게시글 삭제
도메인 모델을 이용한 컴포넌트 개발
- 컴포넌트란?
. 재사용성
. 대체가능성
. 독립기능성
. 구현 관점에서의 컴포넌트
- CBD 방법론
- 컴포넌트 개발
. 컴포넌트 식별
. 컴포넌트 인터페이스 정의
. 컴포넌트 설계
. 애플리케이션 설계
. EJB 컴포넌트
. 컴포넌트 운영 환경(CEE, Component Execution Environment)
. Runtime Object Type Binding
. Deployment Descriptor
. 컴포넌트 구현
. 화면 계층은 컴포넌트 내부인가? 외부인가?
. 컴포넌트에서의 성능문제
. 다른 컴포넌트로 대체
. 컴포넌트의 테스트
. 컴포넌트 패키징
- 컴포넌트 내부 구현
프리젠테이션 계층
- JSP Model2(MVC 패턴)
- Struts
. Struts Model
. Struts View
- JSP Model2 프레임워크 만들기
. FrontController 구현
. Action 구현
. JSP Model2의 문제
- 소스 생성 도구의 사용
컴포넌트 제작 사례
- ACL 관리(Access Control List) 컴포넌트
. 도메인 분석
. 설계
. O-R 매핑
. 구현
. 다른 시스템에 적용하기
. WebServices로 전환하기
12. 평균을 뛰어넘기
이 글을 읽기 전에는 대부부의 고급 프로그래밍 언어가 유사하다고 생각했는데 잘못된 생각인 것 같다...
한번 확인해보기 위해 책에서 주장하는 LISP를 공부해볼 까 하는 생각도 있다.
13.공부벌레의 반격
내용 중에 pointy haired boss 라는 용어가 나오는데 인터넷에서 조금 찾아보니까 Dilbert라는 만화에 나오는 캐릭터 중의 한명인데 다음과 같은 성격을 가지고 있는 보스를 의미한다고 함.
Typical traits of a pointy haired boss :
- Does not understand what his employees do for a living.
- Enjoys using buzzwords such as synergy, leadership, accountability, evangelize, leverage, competency, collaboration, empowerment, quality, paradigm, team-enhancing, and culture-shift often to escape having to commit or be precise.
- Pretends to understand technology, but is really clueless. He often shifts towards buzzwords (see above) to compensate or change subject.
- Easily mesmerized by silver-tongued sales people peddling management or technology fads.
- Decisions seem random or capricious.
- Gross failures of logic, such as holding repeated long meetings to discuss why a project is behind schedule.
- Likes meetings because he/she does not know how to use email properly or does not want his/her bad decisions committed to writing.
- Uses his employees' ideas and presents them as his own, almost always to the same employees
- Is always right. Or at least, thinks he/she is.
- You warn him/her to do X or else Y will happen. He doesn't do X. Y happens. You somehow get the blame.
- Doesn't seem to remember anything beyond a month's range.
- Rewards employees based on how well they stroke his/her ego instead of how well they do their job.
- More focused on sounding important than being important.
