오랜만에 다시 스프링에 대한 글을 시작한다.

스프링과 AOP(Aspect-Oriented Programming) 관계는 다음 그림이 잘 설명해준다.



AOP는 기괴하다 싶을 용어와 함께 하기로 유명하다. 그래서, 비유적으로 이야기를 끌어가 보자. 위 삼각형을 도원 탁자라고 해보자. 탁자 위에는 사발과 술병이 올려 있을 법하다. 물론 탁자를 앞에 두고 유비, 관우, 장비가 앉아 있다. 스프링의 중추인 IoC는 유비에 비유할만하다. 하지만, 스프링이 EJB를 잠재우는 데에는 관우격인 Portable Service Abstractions의 공이 크다. 이제 하나 남은 AOP는 장비라 하자.

AOP는 장비만큼이나 다루기 어렵다. 보통은 으뜸가는 장수로 일당백을 한다. 하지만, 감정에 휘말려 자칫 실수를 범한다. 비유가 기막히게 들어맞는다. 보통 스프링을 처음 쓸 때는 AOP를 쓰는지도 모르고 사용한다. 레퍼런스를 따라 하다 보면, 필수 기능인 트랜잭션 처리 과정에서 자연스레 쓰이기 때문이다.

이제 비유는 접어두고 스프링 삼각형의 한 축을 이루는 AOP의 역할을 한마디로 정의하면 다음과 같다.


하지만, 스프링은 반드시 AOP를 쓰도록 강제하진 않았다. IoC 컨테이너와 AOP 기능은 소위 말하는 "loosely-coupled" 연결을 맺고 있다. AspectJ와 통합하면서 점차 강력해지긴 했지만, 초창기 Spring은 AOP에 대한 별다른 지식이 없이도 AOP를 활용할 수 있게 했다. 스프링은 AOP 적용에 있어서도 늘 그렇듯 다양한 선택을 준비했다. 그래서, 새로운 기술을 무리하게 도입하기보다는 점진적으로 활용할 수 있는 토대를 제공한다.


어느 조직이나 회사건 모든 업무에 걸쳐 발생하는 일이 있다. 기획, 영업, 구매, 회계, 총무, 경영지원 등 기능과는 다른 영역이 있다. 예를 들어 청소나 기반 제품 납품과 유지보수 같은 일은 어떤가? 최근에는 본질적 기능 외에는 전문 업체에 외주(Out-sourcing)를 줘서 전체 비용(TCO)을 줄인다.

AOP는 이러한 지혜를 순수 기술 차원에 포팅했다. 그 이름도 유명한 제록스(Xerox)가 해냈다. 지금은 다른 엔지니어와 조직에서 계승했다.

하지만, 태생적으로 본질 업무(OOP)와 다른 면이 있어서 오브젝트(object)가 아닌 애스펙트(aspect) 혹은 어드바이스(Advice)로 구분한다.

너무 비유로 흘렀는데 Professional Java Development With The Spring Framework 에 따르면 다음 사항이 AOP 적용을 통해 이익을 볼 수 있는 전형적인 사례다.

• 특정 인터페이스를 구현하는 모든 메소드(혹은 Operation)가 각기 다른 트랜잭션 안에서 수행해야 할 때
• 결과 반환에 자원 소모가 많은 경우에 빠른 응답을 위해 일정 기간 캐시(cache)를 써야 할 때
• 공유하는 DB 필드(field) 값인지라 한 쓰레드에서 변경이 발생하면, DB Lock을 걸고 바로 반영하여 I/O를 발생하기보다는 메모리에서 처리하고 필요할 때 혹은 노는 시간(idle time)에 반영하기
• 한 달간 진행하는 판촉행사를 위한 코드를 현행 코드 여기저기에 끼워 넣고 나중에 빼버리는 실수하기 위한 작업이 아니라 명확하게 구분하여 관리할 수 있게 하기

예전에 어떤 개발자가 R&R이란 표현이 모양이 나게 여겨졌는지, 문맥에 관계없이 R&R이란 표현을 남발했다. 옆에서 보면서 드는 생각이 R&R이 폼나는 표현이 아니란 사실을 알기 전까지는 그 의미를 전혀 모르겠구나 싶었다. 그리고 어떤 관리자는 틈만 나면 R&R 따지지 말고 서로 도와가며 일하라고 말했다. 우습게도 그 말에 반박했던 나 역시 얼마 후 다른 이에게 비슷한 말을 했다.

올해로 8년째 방법론과 직간접적으로 인연을 맺어왔다. 누군가에겐 우습게 들릴 수 있지만, 방법론에 대한 애증이 쌓였다. 요즘 누가 나에게 방법론이 무어냐고 물으면, '방법론은 R&R이다.'라고 말해주고 싶다.

R&R은 'Role and Responsibility'의 약자다. 우리말로 역할과 책임이다. 역할과 책임을 규정하지 않고 일하는 조직이 어디 있을까? 하지만, 방법론이 효과를 발휘하려면 R&R이 더 명확해야 한다. 마치 오랫동안 잘 돌아가는 프로그램을 만들려면, 함수 시그너처가 명확해야 하고, 컴포넌트 인터페이스 규약이 명확해야 하고, 계층(layer)간 주고받는 항목과 제약사항이 명확해야 하는 것과 같은 이치다.

산출물(deliverable)이라는 명확한 '부가가치'의 연쇄구조(chain)를 통해 최종 제품을 만든다. 마치 컨베이어 벨트처럼 방법론을 기계화 수준의 시스템으로 만들면 효율성은 극대화한다. 하지만, 아쉽게도 아직 소프트웨어 개발에 있어서는 제조업의 노하우를 그대로 쓸 수는 없다. 개념적으로는 이미 오래전에 소프트웨어 공장을 논했다. 하지만, 산업 경계를 넘어가면 재해석을 해서 새로운 행동 계획(action plan)이 필요하다.

물리적으로는 하나의 산출물이라도 여기에 부여한 부가가치의 생산자는 다르다. 이를 명확하게 해야 효과를 내는 R&R 정립이다.

소프트웨어 설계를 고민하면서 동시에 혹은 번갈아 방법론을 고민하다 보면 무척 닮았음을 알 수 있다. R&R 정립이 가져오는 팀 협업 구도는 loosely-coupled로 불리는 시스템 연동 방식과 원리가 같다. ^[각주:1]

주말에 랄프 존슨 특강에 참석했다. 프로젝트 초기라 바쁜 와중에 맞이하는 주말인데 굳이 유명인사 특강에 참석해야 할까 싶은 생각을 안고 자리에 나갔다. 아마도 특강 개설 과정에 참여하지 않았으면 그 자리에 있진 않았을 것이다.

랄프 존슨 특강을 듣기 시작한 지 얼마 지나지 않아 생각이 바뀌었다. 기름기가 잔뜩 꼈던 정신상태에 경종을 울렸다. 먼저 두 가지 사항을 반성했다.

• 영어에 자유로워지겠다고 결심했지만, 실제 행동은 그렇지 못했다.
• 디자인 패턴에 대해 충분히 안다고 생각했는데, 사실 아무것도 모르는 사람과 별반 다르지 않음을 느꼈다.

내 블로그가 반성을 위한 일기 역할을 하지만, 방문객을 고려해서 반성은 그만두겠다. 짧은 영어 실력 탓에 대가의 특강을 충분히 소화하지 못했다. 그럼에도 화학반응을 통해 영감을 얻어 쏟아진 생각을 메모할 겸 공유하고자 한다.

1강: Fifteen Years of Design Patterns
베스트셀러인 GoF 디자인 패턴. 실제 발표는 94년 OOPSLA인데 출간은 95년이다. 이유가 무엇일까? 출판업자는 우리나라와 다르지 않았다. 연초에 출간해야 매출에 유리하기 때문에 해를 넘겨 책을 볼 수 있었다. 후속으로 쏟아진 관련 서적이 매우 많다. 랄프는 그중에서 4권을 꼽았다. 그 중 두 권에 대한 논평이 인상깊다. 하나는 그 유명한 헤드 퍼스트 시리즈다. 헤드 퍼스트는 자신의 책보다 더 많이 팔렸다며 미소를 지었다. 그리고, 헤드 퍼스트의 독특한 전개 방식에 대해 높이 평가했다. 두 번째는 에릭 에반스의 DDD에 대한 평이다. 랄프는 크리스토퍼 알렉산더를 글 잘 쓰는 사람으로 평가했다. 그리고 컴퓨터 과학과 건축(building)은 다르다고 이야기했다. DDD는 알렉산더류에 가까우면서 매우 독창적인(very unique) 책이라는 점을 강조했다.

책 소개 이후에는 디자인 패턴 자체에 대해 설명했다. 디자인 패턴을 고급(advanced) 객체지향 프로그래밍 전형으로 소개한 점이 인상적이었다. 객체지향에선 보통 명사는 객체이고, 동사는 행위이다. 그런데 고급이란 표현은 일반적(not normal)이 아니란 의미다. 예를 들어 Strategy는 알고리즘인데, 함수가 아니라 객체로 존재한다. 뒤이어 스스로 코어라 정의한 14개 패턴을 나열했다.

• Composite
• Strategy
• Decorator
• State
• Iterator
• Observer
• Value Object
• Mediator
• Facade
• Proxy
• Command
• Template Method
• Adapter
• Null Object (Exceptional Object)
  

기울임체로 표기한 두 개 패턴은 GoF 책에는 없던 내용이다. Value Object에 대해서는 DDD에서 제대로 설명한 바 있다. 랄프가 그 이야기를 해서 반가웠다. 2판에서는 (Data) Transfer Object로 고쳤지만, 단순히 데이터 운반 수단으로만 쓰였던 Core J2EE Patterns에서 Value Object라고 작명한 내용은 틀렸다고 말했다. 그래서, 본인과 Kent Beck(Implementation Patterns 28쪽), Martin Fowler 각각 스스로 Value Object를 정의했다고 한다. 셋 모두 수긍할 수 있었던 Value Object에 대한 정의는 Eric Evans의 DDD에 나온 설명이라고 한다. :)

주로 언급한 패턴에 대해 기억에 남는 내용을 메모한다.

• Composite

컴포넌트를 종국에는 종단(Leaf)과 복합체(Composite)로 나누어 이분법의 강력함을 활용할 수 있다는 점이 눈에 띄었다. 하지만, 핵심은 복합체와 구성요소(Component) 모두가 정확하게 같은 인터페이스를 갖는다는 점이다.

• Strategy

알고리즘을 (일반적인 경우와 달리) 객체에 담았다. Strategy에 대해선 바로 설명하지 않고, 발표자료에서도 상당한 지면을 할애해 깊이 있게 다뤘다.

• Observer

Subject의 하위 클래스는 Observer 수에 무관하게 자기 일만 충실할 수 있다. 스타크래프트에서 선수가 Observer를 신경 쓰지 않고 자기 플레이만 하듯이 말이다.

그리고 위험한 패턴으로 Mediator와 Singleton을 언급했다. 많은 사람이 잘못 사용하면서, 나쁜 패턴이라 칭하는 데 대해 일침을 가했다. Mediator는 반드시 재사용을 전제로 해야 하며, 종종 데이터와 코드를 구분하는 우를 범하기 쉬운 패턴이다. 싱글턴을 써야 하는 경우를 명확하게 정의해줬다.


코어에 이어서 생성 패턴을 열거했다.

• Abstract factory (peripheral)
• Factory method
• Prototype
• Builder
• Singleton
• Dependency Injection

스프링 사용자인터라 Dependency Injection 등장이 반가웠다. 랄프 존슨은 Dependency Injection에 대해서 의존성을 객체 외부에 보존해(Keep dependencies out)서 생기는 DI의 이점에 대해 짧은 말로 명쾌하게 설명했다. 그 외 보조(peripheral) 패턴을 7개로 분류했다.

• Memento
• Chain of responsibility
• Bridge
• Visitor
• Type Object
• Extension Object
• Generation Gap

Type Object에 대한 활용은 놀라움이었다. 패턴에 대한 나의 무지를 혁혁하게 보여주었다. 랄프는 Visitor에 대해 "Cool"이라는 극찬을 감추지 않았다. 다형성을 지켜주는 보석 같은 존재로 설명했다. Extension Object를 설명할 때는 Eric Gamma와 이클립스를 예로 들었다.

마지막 카탈로그로 복합(Compound) 패턴을 두 개 꼽았다.

• Flyweight
• Interpreter

Flyweight를 설명하면서 flyweight pool을 활용해서 flyweght 객체를 만들어주는 클래스를 Memorizing Factory라 명명했다. 퍼뜩 떠오르는 녀석이 Bean Factory다. 이에 대해서는 더 고민해봐야 할 듯하다. 1강의 전반부는 여기까지다. 대가에 대한 존경심과 반성을 불러온 놀라운 강의는 후반부 Patterns in Business Software에 대한 설명이다. 그 내용은 짤막한 메모로 내가 받은 놀라운 인상을 전해줄 수 있을까 싶기도 하고, 너무 긴 글에 지쳐서 다음으로 미루겠다. 긴 글이나 예제를 시도할 수도 있어 포스트로 정리하지는 않을지 모르겠다.

국민대학교 BIT대학원 부설 KIMEC에서 주최하는 Ralph Johnson 세미나 공지입니다. 주최측에서 약 50명 정도의 한정된 인원으로 소프트웨어 공학 관련 실무자와 함께 하고자 제가 참석 신청을 대행하기로 했습니다. 참석을 원하는 분은 블로그 왼쪽 상단의 메일(Gmail) 주소로 '성함, 휴대폰 번호, 이메일 주소'를 보내주세요.

2009학년도 국민 BIT전문대학원 특강안내
	1. 교육 강좌명 : 'Ralph Johnson과 함께하는 소프트웨어 개발의 지혜들'    2. 교육 목적     소 프트웨어 설계 전문가로 프레임워크 관련 다수 서적의 저자인  Ralph Johnson과 함께 소프트웨어 개발의 지혜를 나누고자 한다. 랄프 존슨은 소프트웨어 개발 방법에 있어 객체 지향 프로그래밍을 연구해온 인물로 다양한 프로젝트를 진행했으며, 디자인 패턴 분야의 바이블로 알려진 Deign Patters의 공동 저자이다. 패 턴은 반복되는 디자인 기술을 나타내며 언제, 왜 사용해야 하는지를 설명하고 있고, 디자이너들이 좀 더 생산적이고 서로간의 커뮤니케이션이 잘 될 수 있도록 한다.  이번 교육의 목적은 소프트웨어 아키텍트 및 개발자 들과 깊이 있는 이야기를 나누는 장이 되고자 한다.    3. 교육대상자    - 소프트웨어 중, 고급 개발자    - 소프트웨어 아키텍트   4. 강의개요     1) 교육 일시 :  2009년 8월 15일 (토) 오전 10시 - 오후 2시 30분     2) 교육 장소 :  국민대학교 경상관 317호 (BIT 컨퍼런스 룸)     3) 교육 인원 :  선착순 50명     4) 교 육 비  :   5만원  [327-120897-01-042 (국민대학교)_우리은행]                          * 꼭! 본인명의로 입금요망.                          * 영수증 필요하신분은 사업자등록증을 Fax로 보내주세요.     5) 기     타  :  강의교재비, 주차비 무료,  점심제공, 강사와 간담회 개최

시 간 내용 강    사 10:00 - 11:30 Fifteen years of Design Patternsn. "Design Patterns" was released in October, 1994. In the years since, some of the patterns have turned out to be very important, some less important. New patterns have arisen that have displaced some of the older patterns.  There are common ways that the patterns are misused. Ralph Johnson will talk about what he has learned about the patterns since the book was published. Ralph Johnson is one of four coauthors of "Design Patterns" and the leader of the group that built the first refactoring tool, the Smalltalk Refactoring Browser. He is currently working on patterns for parallel programming and for safe software, and on tools for refactoring systems to be more secure and to be more parallel. Ralph Johnson is a Research Associate Professor in the Department of Computer Science at the University of Illinois at Urbana-Champaign. Ralph Johnson 11:30 - 12:30 점심 먹으면서 간담회   12:30 - 02:00 Keeping software young and limber As software ages, it tends to get harder to change.  People try to make changes in such a way that nothing breaks, but it becomes harder and harder to change it successfully.  Eventually the software is so hard to change that it is abandoned. Not all projects are like this.  Open source projects seem to run on and on.  Some commercial projects seem to last indefinitely, sometimes because they are so valuable that no effort to save them is too great, other times because the software stays flexible and so developers are able to adaptit to new situations. There are a set of techniques that help keep software flexible and adaptable.  They are often named "refactoring", but there is a lot more to it than just a particular set of techniques for changing code.  Flexible code requires certain management practices, as well.  This talk will describe how to keep your software young and limber.  Ralph Johnson 02:00 - 02:30 질의 및 응답

- 문 의 처 : KIMEC 행정팀 [담당 : 강희주]                 (Tel : 02-910-4086, 910-4018/Fax : 02-910-4017)                   http://bitfamily.kookmin.ac.kr

Implementation Patterns를 보고 다 읽지도 않은 책에 대해 한 마디 남긴다. 현남씨 말대로 어려운 영어도 아니고, 켄트 벡 책 답게 얇다. 하지만, 휙 하고 읽어 버리고 싶지 않아 남겨 두었다.

스스로 프로그래밍하는 순간을 모니터링 하는 과정을 통해 나온 지혜다. 그래서, 쉬운 글이라도 쉽게 볼 수는 없다. 경험이 있어야 경험자 이야기를 공감할 수 있다. 언젠가 경험을 하고 나서 다시 읽어보려고 곁에 두고 있다.

매 순간 온힘을 다하니까 다음과 같은 말을 쉽게 할 수 있다.


너무나도 기본에 해당하는 이야기이다. 제발 테이블과 같은 클래스 이름을 원하는 괴발자와 암호를 선호하는 게발자가 균형감을 얻기 위해 딱 한 번은 읽어보길 권한다. 

IT 밥 10년 먹으며 가장 인상적인 그림 두 장에서 처음 본 그림인데 공감 120%이다. 얼핏 노령화 사회를 연상케도 한다. 올해 신입사원에게 일방적인 감봉을 행사했다고 했던가? 자본주의 사회이니 열심히 일하는 사람에게 많은 돈이 돌아가야 한다. 관리자 역할은 무척 중요하다. 그래서 관리자는 절대 손 놓고 바라보면 안된다. 30대 중후반부터 맥없이 늙어가는 관리자가 없는 세상을 기대한다.

블로그에 글을 쓸 때는 시간과 노력을 아끼려고 맞춤법을 신경 쓰지 않았다. 그 결과 맞춤법 무시가 몸에 밴다. 물론, 생사가 걸린 문제는 아니지만, 계기가 있어 글을 쓰고 난 후 잠시 짬을 내서 한국어 맞춤법/문법 검사기를 활용한다. 결과 이력을 남기기 위해 자주 틀리는 표현이란 글을 유지한다. 흥미로운 점은 한 번 틀린 내용을 자꾸 반복해서 틀린다는 점이다. 그래서, 반복이 늘 때마다 '굵게'(2회 반복), '붉은색'(3회 반복), '형광펜'(4회 이상) 처리를 했다.

매일 구독하는 블로그에서 '굳이'를 '구지'로 썼다. 자주 보던 일이라 블로그 필자 습관이구나 생각한다. 과연 몇 번이나 '구지'를 썼을까? 눈으로 헤아릴 수는 없다. 구글 검색을 활용하니 적어도 몇 개 글에서 '구지'를 썼는지는 알 수 있다.


결과는 이렇다.


토비형에게 습관을 알려주고 싶기도 하고, 구글 검색 팁도 전할겸 짬을 내서 글을 쓴다.

UML전문가가 설계전문가?

Ray님이 기분 상할지 모르지만, 나도 종종 내뱉는 넋두리를 풀어낸 글이다. 여기 120% 공감하는 말이 있다.


거기에 더해서 혼란을 가중시키는 다양한 도구까지 있다. 수차례 내뱉은 말을 다른 사람 글로 본다.


종종 사람들은 UML이나 모델링 도구 혹은 사용 기법이 설계의 어려움을 대신해주길 바란다. 고민을 덜 하고 간단한 조작을 통해 마법이 일어나길 바란다. 혹은 다른 사람이 대신해주길 바란다. 심지어는 미루어 버리기도 한다. 도구의 역할은 같은 노력을 투입했을 때, 효과를 높여줄 뿐이다.

Ray님 글에 120% 공감하고, 내 넋두리를 대신해준 듯 속이 시원하다. 그렇지만, 짓궂게도 토를 달고 싶어진다.


UML 대신 다른 말을 대입해보자.


UML이 고작 모델링을 위해 선택할 수 있는 하나의 언어일 뿐일까? 물론, 그렇게 평가할 수 있다.

하지만, UML을 활용할 수 있는 도구가 많이 나와 있다. 설계를 모두 담아내긴 부족하긴 해도 다양한 표기법과 편리하게 의미를 담을 수 있게 해준다. 부족하긴 하지만 UML은 좋은 도구다.

끝내기 전에 하나만 부탁하자. 이미 구입한 분이 아니라면, 제발 비싼 모델링 툴은 택하지 말자. 무료 툴이 불편하다면, 20만원 정도인 EA면 충분하다.

출근을 일찍 하는 찬욱이가 아침부터 호들갑을 떨며 올린 글: [긴급]VMWare에 인수된 SpringSource!(이하 SS)

오늘이 혹시 만우절이 아닌가부터 따져봤다. 만우절은 아니더라도 대피할 일은 아니니까 굳이 긴급이라 알릴 필요는 없었는데, 그만큼 스프링을 좋아하는 이에겐 충격적인 일이다. 개발자 사이트에서 SS가 수익을 내지 못하면 오라클에 인수될 거라 예상하는 이가 종종 있었지만, VMWare라니...

한편으론 수긍할 수 있는 부분이다. Rod Johnson은 이 결정을 제 2 장이라 표현했다. 3분기에는 협상을 마무리해서 SpringSource는 VMWare 부서(division)가 된다. 이슈를 좋아하는 미디어에서는 제목부터 4억 2천만 불이란 금액을 걸었다. ^[각주:1] 반면에 Rod Johnson은 이번 결정이 배경인 비전을 이야기한다.

흥분시키는 기회(An Exciting Opportunity)

dm Server나 tc Server 출시 시점에 SS는 엔터프라이즈 애플리케이션 개발 영역을 넘어서 배포(deployment), 운영(operation)과 관리(management) 개선에 나섰다. 마치 EJB 개발에 기준이 없던 시절 J2EE Best Practices가 원칙으로 받아들여질 때, 엔터프라이즈 애플리케이션 개발을 개선하기 위해 스프링이 등장했던 점과 같은 맥락이다.

스프링에 대해 냉정한 평가를 하던 이들의 말처럼 스프링은 엔터프라이즈 시스템 개발에 있어 일부일 뿐이다. Rod Johnson도 같은 말을 한다:
But the broader transformation in IT goes beyond Java frameworks, tooling and runtime infrastructure.

데이터센터나 클라우드에서 SS의 기술을 사용하는 최적안(the most simple, powerful, pragmatic way)은 무얼까? 단초는 2008년 SpringOne에서 어렴풋이 언급했던 VMWare와의 협력이었는데, 결과는 한 몸(?)이었다.

비전을 한 문장으로 요약하면 다음과 같다:
Working together with VMware we plan on creating a single, integrated, build-run-manage solution for the data center, private clouds, and public clouds.

Rod는 그림도 덧붙였다.


예상할 수 있듯이 커뮤니티에 대한 지원 기조는 그대로(Sleep easy – our commitment to open source practices, licenses and traditions will remain unchanged.)라고 한다. 스프링 스타일을 Build/Run/Manage solution 영역에 전파하기 위해 필요한 파트너를 찾았다는 이야기다.

Rod 글에 트랙벡을 걸려했더니 지금 폭주인 모양이다:

Error establishing a database connection

오래전 일이다. 모 SI 업체에서 컨설팅하면서 만나는 사람은 많았지만, 친한 사람은 셋뿐이었다. 한 분은 알고 보니 중학교 동문 관계임을 알고 선배 노릇 해주려는 의도였고, 나머지 두 분은 비상주인 내가 들어가는 날 최대한 많이 활용(?)하려는 의도였다. 다른 설계자나 개발자는 나를 피했다.

오래 지나지 않아 이유를 알 수 있었다. 꽤 많은 인력이 프로젝트에 참여하지만, 일하는 사람은 소수였다. 아니다. 일하는 사람은 많았지만, 뚜렷한 결과물을 만드는 사람이 드물었다. 더구나 그중에서 나이 어리고 눈치 빠른 친구는 초반에 다른 업체를 찾아 도망(?)쳤다. 사수와 부사수로 특공대(?) 역할을 자임하던 두 분이 떠나간 어린 친구 일까지 받았다. 새로 받은 일은 유명 업체(vendor)에서 만든 최신 프레임워크와 개발도구(IDE)를 쓰고 동일 d업체가 만든 WAS 최신 버전에 올리는 일은 먼저 진행하는 작업이다.

두 분이 원래 맡은 일은 무엇이었느냐? 해당 조직에서 CBD를 처음으로 도입한 터라 UML, 모델링 도구, 인터페이스를 두는 프로그래밍 방식을 최초로 전수받으며 가장 양이 적은 업무를 진행하는 POC겸 선도 개발자 역할이다.

몇 달 지나니까 DBA도 다른 곳으로 빠져나가서 선도 개발이 끝나갈 무렵 두 분에게 DBA 역할도 넘어갔다. 프로젝트 후반에 가니 가장 크리티컬한 업무도 다시 두 분 몫이었다. 너무 심하다 싶었는데 아니나 다를까 사수 역할을 하던 분은 프로젝트 이후 회사를 옮겼다.

프로젝트를 하다 보면 정도에 차이가 있을 뿐 비슷한 현상을 목격한다. 항시적 조직에서도 마찬가지겠지만, 상대적으로 생명주기(lifecycle)가 짧은 프로젝트에선 짧은 시간에 극명하게 드러난다. 최근에도 비슷한 사람을 여럿 접했다. 어떤 이는 조건에 따라 특급이다. 하지만, 어떤 면에서 특급인지 알기 어렵다. 결과물 기준으로 보면 하는 일은 0 이상일지 의문이다. 전혀 공헌이 없진 않겠지만, 잘못 처리한 일로 인해 몇 달 후 누군가 처음부터 다시 일해야 하는 경우가 있으니 0 이하일 수도 있다. 한때 만났던 PM은 PMP에 기술사였다. 하지만, '유령'으로 불리곤 했다.

누구나 재주는 있는 법이어서 그런 부류가 언뜻 보면 합리적일 듯한 이유를 잘 만든다. 너무 비관적일 수도 있지만, 소프트웨어 기술자 신고제도를 보면 그런 부류에 살 길을 열어주는 듯한 인상도 받는다.

이처럼 균형 잡히지 못한 시각 탓에 종종 같이 일하는 동료와 갈등을 빚곤 한다. 그래도 한 가지 신념은 변하지 않는다.

'일터에 국한하면, 일하지 않는 자는 존재 가치가 없다.'

한번도 배포 담당자로 일한 바 없다. 배포는 항상 누군가 맡아줬다. 한번은 함께 삼겹살을 먹던 배포 담당자가 급한 호출로 다시 사무실로 돌아간 일도 있었다. 멋져 보이지는 않지만, 사실은 박수를 받아야 한다.

우리 프로젝트 일로 찬욱이가 글을 썼다. WAR로 Spring APP 배포 시 발생하는 문제.
실제론 다른 친구가 썼으면 좋았을텐데. 여하튼 현재 쓰이는 방법은 WAR가 아니라 풀어서 올리는 방법이다.

이번에는 기술 책임자를 맡았다. 비록 배포를 담당하지는 않지만, 소수의 개발자에게 고된 일을 맡게 하고 싶지는 않다. 우리 팀이 조금 고생해서라도 자동화를 이루고 싶다. 현재 쓰이는 방법을 고려한다면 운영체제가 지원하는 ANT 명령을 쓰거나 쉘 프로그래밍이 필요하다. 보안이라는 장벽이 있어서 쉬울지 모르겠다.

개빈 킹이 Seam을 모호한 이름으로 바꿨던 일 이후 오랜만에 후속 이야기를 담을 포스트를 봤다. Seam(JSR-299)과 Spring(JSR-330)의 만남이다. Toby 에게 미끼를 던진 셈인데 별 반응이 없었다. 알고 보니 고열로 고생하고 있었다. 아쉽다고 했더니만, 역시나 하루 만에 글 썼다. 스스로 표준에 관심이 없다곤 하지만 산업 표준 특성상 최종 결과가 만들어지기까지 꽤 긴 이력을 갖는데, Dependency Injection 표준화? 를 보면 해박함을 알 수 있다.

Toby형과 마찬가지로 JSR의 결과에는 관심이 전혀 없다. JSR이야 JCP에 가담하는 업체(vendor)가 흥행을 꾀할 수는 있다. 하지만, 노련한 자바 개발자라면 Java 7 정도나 관심이 있지 않을까? 특히나 JEE를 구성하는 JSR은 시시하면서 복잡하기 이를 데 없다.

차분히 생각해보니 일터에서 표준을 고민하거나 만드는 역할을 맡는다. 헉! 그런 처지에 말조심하지 않는 경솔한 태도라니.

조직 표준이라 할 EA(Enterprise Architecture)를 강조하는 사람이 많다. 특히 학계 교수님이 많다. 그리고, 2, 3년 전 한바탕 EA 바람이 불고 갔다. 대규모 기업은 의례 EAMS나 메타 시스템 정도는 기본이다. 안을 들여다보면 참조 모델이 수십 개고, 표준 가이드가 수십 개다. 취지도 좋고, 내용도 나쁘지 않다. 하지만, 2, 3년 세월이 흘렀는데 처음 내용 그대로다. 초심을 잊지 말아야 하는데, 초심은 잃고 처음 만든 내용만 세월에 고스란히 낡아간다.

이런 현실을 경험하는 일은 행운이다. 그래서, 기술자로서 관심을 두는 멋진 기술과 기법 나아가 아귀가 딱딱 맞는 아카데믹한 체계를 버릴 수 있다. 비록 내가 만든다고 하더라도 주인은 다른 사람이다. 유지보수를 담당할 운영자가 편안하게 느낄 수 있어야 한다. 그들 삶에 조금이나마 도움을 주어야 한다. 굳이 욕심을 부리자면 그들이 미래에도 경쟁력을 갖도록 동지애를 갖고 새로운 흐름을 수용할 수 있게 도울 수 있으면 충분하다. 물론, 말처럼 쉽지 않다. :)

DBA로부터 DB 사용자 쿼리를 모니터링할 때 쿼리를 실행한 자바 코드 즉, DAO 를 모니터링 툴(오렌지 등)에서 바로 확인하는 방법을 원했다. 구글링해서 관련 정보를 찾을 수 있다.


Spring JDBC Template을 이용하는 경우 다음과 같은 코드로 테스트해볼 수 있다.


이렇게 하면 툴에서 모듈에 클래스 이름이 보이고, 액션에 Some Action이라는 문자 나타난다. SET_MODULE의 인자로 각각 애플리케이션 모듈 이름과 해당 모듈이 행하는 액션을 넣을 수 있다. DBA의 요구 사항이나 운영팀이 정책에 따라 적절한 값을 넣을 수 있다.

이제 다시 DAO로 돌아오면 이 쿼리는 모든 쿼리 수행 전에 불려야 한다. 이제 공통으로 적용하는 방법만 고민하면 DBA를 편하게 해줄 수 있다.

휴가로 제주도에 갔다. 지난해보다 해수욕장에 해초가 늘었다. 펜션 주인아저씨를 통해 해초가 는 이유에 대해 들을 수 있었다. 연거푸 양식장 허가를 내어 준 결과가 해수욕장에 쌓여가는 해초라고 했다. 이미 인력을 동원해서 걷어둔 해초 더미가 쌓여 있는데 수심이 조금만 깊어지면 발에 걸리는 해초 탓에 불편했다. 견딜만한 수준이긴 하지만, 더 심해지면 해수욕장 개장이 힘들 수 있다. 금능/협재가 대표하는 서편은 괜찮은 듯하다. 하지만, 세화나 우도 앞 작은 해수욕장을 포함해 동편은 지금보다 심해지면 후년을 기약하기 어려울 듯하다.

이 문제를 두고 '양식장 허가의 부당성'을 주장한 펜션 주인아저씨와 같이 해수욕장 부근에서 숙박업을 하는 사람은 양식장 허가를 반대한다. 그래서 여러 차례 민원을 넣었다고 한다. 양식 허가를 내어줬으니 시에서 인원을 동원해서라도 해초를 걷어내 주길 바란다. 쾌적한 해수욕 환경을 보장해줘야 동편에 늘어선 리조트형 펜션이 생존할 수 있다.

하지만, 양식장 허가를 원하는 이는 누굴까? 동해안에서도 전복은 이미 저렴해졌다. 이유는 다 안다. 대량생산! 바다에선 산업혁명이 있을 수 없으니 알다시피 양식의 힘이다. 제주도를 자치도로 지정하고, 정부에선 국제 행사도 늘리려고 노력하고 있다. 귀국 길에 외교통상부 장관님이 한 비행기를 탔다. 전날 제주 방송에 따르면, 그린 어쩌고... 컨벤션 비즈니스.. 어쩌고 그랬다. 하여간 사람이 늘고 인건비도 비싸지니 대부분은 양식으로 해결해야 한다. 현재 수량이 부족하니 양식장을 늘릴 수밖에 없다. 양식업자만 환영하는 일이 아니다. 중문을 비롯한 관광지역 횟집이 환영한다. 고급 뷔페를 비롯한 주요 음식점이 환영한다.

양자택일로 둘만 살아남는 그림이라면 미래는 없다. 결국, 타협을 통해 조화를 이룬다. 자연이 그러하고, 자연을 통해 이치를 배우는 사회가 그렇다. 휴가 한가운데 멍하니 이런 생각을 하면서 개발자가 "이해관계자"란 표현을 이해하는 경우나 다양한 "시각(view point)"을 이해할 때 유추를 위해 예로 들만 한 사례가 아닌가 생각해봤다.