1990년대, 소프트웨어 개발을 업으로 삼은 지는 정확히 3년 차. 나는 스스로 꽤 실력있는 개발자라고 생각했다. 네 종류의 개발 언어에 능숙했고, 파스칼에 어셈블리를 섞어서 코딩해 동료들에게 실력을 뽐내기도 했으니까. 몇 줄 안 되는 코드로 윈도우 API를 숨겨서 호출하는, 아주 난해하고 기교 넘치는 코드를 델파이로 짤 수 있었다. 이런 코드를 해독할 수 있는 개발자는 매우 드문 시절이었다.

그 당시에는 난해한 코드를 만들 수 있는 능력이 개발자의 실력을 가늠하는 척도였고, 그 코드를 이해하지 못한다면 아직 숙련이 덜 된 거라고 치부했다. 아무도 이해할 수 없는 코드를 짤 수 있다면 즉시 고급 개발자로 인정받을 수 있었다. “이 코드는 지금 수정 못해. 담당자가 휴가에서 돌아와야 해. 다른 사람은 이 코드를 이해할 수가 없거든.”이라는 식의 이야기가 흔한 때였다.

개발자 생활을 7년쯤 했을 때, 그런 ‘숙련된 개발자’는 이제 그만하기로 했다. 이제는 내 커리어를 한 단계 더 발전시켜야 했다. ‘개발자’, ‘프로그래머’, ‘코더’가 아닌, ‘소프트웨어 아키텍트’가 되고 싶었다. 내가 생각하기에는 아키텍트 타이틀을 달지 못할 이유가 없었다. 당시에 큰 컨설팅 회사에서 자바 엔터프라이즈(J2EE) 애플리케이션 프로젝트를 맡고 있었다. 래쇼날 통합 프로세스(RUP) 프레임워크를 사용했고, 코드를 작성하기 전에 사용자 시나리오, 클래스, 시퀀스 다이어그램같은 것을 먼저 만들었다.

얼마 후 승진을 하면서 아키텍처 팀으로 옮기게 되었다. 아키텍처 팀은 개발자들이 따라야만 하는 디자인 패턴 북을 만드는 막강한 권한이 있는 팀이었다. 사내의 모든 개발자는 아키텍처 팀이 만든 디자인 패턴에 따라 클래스 모델을 작성해야만 했다.