"자바 기능에 대해서 이를 썼을 때 장단점을 다룬 글이 있는가?"라는 질문을 받았다. 퍼뜩 떠오르지가 않았다. 각 기술 혹은 기능이 소개되면, 각각의 장단을 알아야 하는 것이 기본일텐데... 소홀하지 않았나 하는 생각이 든다. 어쨌든 관련 내용을 찾는 김에 링크를 남겨본다.

1) Annotation 관련
- To Annotate or Not?
- Annotation-Hammer 에서 To Annotate or Not To 절

2) Generics
- Generics gotchas
- Collections & Generics – Q & A

3) Java5 적용
- InfoQ: JRuby: Java5 or not?

4) 예외처리 메커니즘 관련
- InfoQ: Removing Checked Exceptions from Java

어제 아침에 Test Driven Dogma라는 포스트를 읽었는데, 두 가지에 생각이 미쳤다. 하나는 균형 혹은 조화의 중요성에 대해 다시 돌아본 것이고, 다른 하나는 이분법의 강력함이다. ^[각주:1] 이틀동안 꼴이란 만화를 열심히 보고 있는데, 균형에 대해서 누차 이야기한다. 어린 시절에는 분명한 것을 좋아했는데, 살면서 점점 균형과 조화에 대해서 몸으로 익히고 있는 듯하다. 그래서 꼴에서도 시원스럽게 답(?)을 얘기하지 않는 것이 오히려 더 신뢰가 간다. 이런... 삼천포로 빠졌는데 정말 하고 싶은 이야기는 이분법의 강력함이다.

이분법은 SoC(Separation of Concerns)의 정수다. 어떤 현상이든 한 가지 기준을 삼고 양분하면 해당 문제/논지에 대해서만 집중하게 된다. 물론, 정치인들이 주로 써먹는 이분법을 말하는 것은 아니다.^[각주:2] 이분법으로 나누어 보면, 양분한 각각의 측면에 대해서 깊이 있게 사고할 수 있다. 가령, Test Driven Dogma에서 보듯 무언가를 도입해서 부족한 부분을 채웠을 때, 어딘가는 비기 마련이다. 그게 자연의 이치니까. 선인들이 '음양의 이치'를 알면 진리를 터득한다고 했던 것이 궁극의 이분법 활용이 아닌가 싶다.


막판에 너무 나갔는데... 여튼.. 복잡한 문제에 봉착했을 때 쟁점을 기준으로 양분을 할 수 있다면... 다른 것들을 배제하여 복잡도를 낮춤으로써 오히려 깊이 있게 생각할 수 있다.^[각주:3]

이분법에 대해 심오하게 파고 싶으면 이 책을 추천하고 싶다.

Applications	Business Process Management (BPM) Composite / Mash Ups (Server-side, Client-side) Dynamic Languages Functional Programming Health Model-Driven Representational State Transfer (REST) Software plus Services / Software as a Service / Platform as a Service (S+S / SaaS / PaaS) Service Oriented Architecture (SOA) Rich Internet Applications (RIA) Testability User Empowerment (shift in power from business and tech to the user) User Experience (not to be confused with UI)
Infrastructure	Cloud Computing Green IT Virtualization Very Large Databases
Performance	Grid High Performance Computing (HPC) Many-core / Multi-core Parallel Computing
Software Development	Application Life-Cycle Management (ALM) Distributed Teams Lean Scrum User-Lead XP

출처: Key Software Trends

고객이 우리가 확보한 테스트 커버리지 정당성을 입증하는 자료를 요구했다. 자료를 찾던 중에 질문을 받았다.

K군: 질문하고 싶은데 질문이 정리가 안되네요. 프레임워크에서 스프링을 사용하는데, 사용하는 개발자들한테 스프링 API가 보여지게 해야 할까요?

답은 마침 내가 보고 있던 페이지와 같다고 생각한다. ROI(Return on Investment)가 하나의 지표 역할을 할 수 있다. 래핑하는 데 들어가는 노력에 비해 얻는 것은 무엇인가?

그렇다면 다음 문제. 래핑하는 데 들어가는 노력은 어떻게 측정할 수 있나? 래핑 대상 API를 구성하는 메소드 갯수를 사용할 수 있다. 주의할 점은 실제 쓰이는 메소드를 측정해야 한다는 점이다. ^[각주:1]

이번엔 얻는 것은 어떻게 측정할 수 있을까? 두 가지 정도가 떠오른다.

1. 래핑한 이후 프로그래밍 모델이 단순해지는 효과
2. 인터페이스의 변화 가능성: 사용하는 라이브러리 인터페이스 바뀌어도 애플리케이션 변경은 없애기^[각주:2]

1번은 애초부터 우리가 만든 API를 쓰는 곳의 사용 사례가 단순한지 판단해봐야 한다. 유형이 많지 않은 경우 이를 쉽게 만드는 것은 래핑해서 얻을 수 있는 장점이다. 그러나, 변형 가능성이 농후한데 무리하게 래핑한다면, 마치 짧은 경로를 놓아두로 돌아가는 길에 닦아 놓는 것과 같은 결과를 낳을 것이다.

2번은 사용하는 라이브러리의 안정성과 관련이 있다. 예를 들어, 스프링 프레임워크라면 API 변동이 적고 하위호환성이 훌륭해 래핑을 하지 않아도 상당기간 존속이 가능하다. 그러나, 스프링 하위 프로젝트 중에도 초기 버전은 주요 인터페이스가 바뀌는 경우를 볼 수 있다. 특히 1.0 이하에서 Snapshot으로 배포하는 것을 쓴다면 래핑할 필요성이 커진다. 안정성은 과거를 통해 미래를 유추하듯, API 변천사로 추정할 수 있다.

K군: 근데 래핑할 일정이 도저히 안나와요.


안영회: 그러니까.. 그건 또 다른 문제지. 문제를.. 구분해서 봐야지. 섞어서 생각하면 뒤죽박죽.. 머리만 아파. 앞의 문제는.. 기술적인 효과 문제고, 일정은.. 프로젝트 제약의 문제지
안영회: 그건 따로 따로 생각해서.. 각각이 의사결정 포인트가 되는거고, 거기까지 하고 이해당사자가 모여서 결정해야지.

당신이 생각하는 TDD에서 나눈 대화 후에 내가 왜 TDD에 관심을 가졌던가 떠올랐다. 생각해보면 TDD라는 말을 사용하여 몇차례 강의까지 했음에도 불구하고, 아무도 TDD가 무어냐고 나에게 묻지 않았던 것 같다. 내가 TDD를 처음 찾은 것은 UP/RUP 혹은 CBD 방법론을 써서 UML 모델링을 할 때의 취약성 때문이었다. 설계 언어로써 UML은 한계가 많다. 결국, 10여년이 지났어도 UML은 설계서를 Unified 하지 못한 것 같다. 유용하게 쓰이는 것은 높은 추상화 수준에서 클래스 다이어그램이나 객체가 스무개를 넘지 않는 작은 시퀀스 다이그램정도다.

내가 과거에 답답했던 것은 가이드에 의해 만들어내는 UML설계모델의 수많은 다이어그램들이 별로 유기적으로 코드로 이어지지 못하고 있다는 점이다. 내가 만들어야 했던 것은 요구사항부터 구현으로 이어지는 전체 표준 프로세스였다. 결국 유스케이스에서 테스트케이스를 만들게 하고, 이 때 설계한 내용을 구현에 반영하게 했다. 그때, 해결하지 못했던 것은 요구사항에 대응하는 Acceptance test수준에서 컴포넌트 테스트, 그 하위의 클래스 테스트까지 체계화하고, 유기적으로 연계할 방법이었다.

그로부터 2~3년이 흘렀다. 토비형 질문을 통해 내 머리속에서 추출한 TDD의 정의는 내가 TDD를 어떻게 써먹었는가를 여실히 보여준다. 당시 내 입장에선, 지금 이곳에서 유용한 내용을 실천하는 것이지, 원론적인 TDD는 아니었으니까.(지금은 2~3년 전과 같은 상황이 아니고, 이젠 TDD를 Kent Beck이 정의한대로 이해할 필요가 있기 때문에 다시 TDDBE책을 열어봤다. Preface를 꼭 보시기 바란다. ^^)


2~3년이 지났지만, 밑줄친 저 부분에 대한 대답은 여전히 요원하다. 나비효과로 토비형과의 대화에서 'TDD에 어떻게 관심을 가졌�