그 당시 나는 유명한 GoF(『Gang of Four: Design Patterns』의 저자 4명을 지칭)의 디자인 패턴과 J2EE Core 패턴을 다루는 데 매우 능숙했고 UML과 래쇼날 로즈*도 알고 있었다. 자바 관련 자격 인증도 몇 가지 갖고 있었다. 나는 아키텍트라 자부할 만한 충분한 기술과 경험이 있다고 판단했고 아키텍트라는 타이틀에 기분이 좋았다.
아키텍트는 비즈니스 분석가와 대화하며 요구사항의 기능적/비기능적 요소들을 이해하고, 개발자가 따라야 할 다이어그램들을 그리는 일을 했다. 생각을 많이 해야 했다. 요구사항과 고객 환경이 어떻게 바뀔지 무당이 점치듯이 추측해야 한다. 다가올 5년 안에 추가될 모든 기능 목록과 상세 내용을 손아귀에 쥐고 있을 수는 없기 때문에 시스템이 정확히 어떤 식으로 커나갈지 예측하는 것은 거의 불가능했다. 그럼에도 불구하고 어떻게 모듈을 만들어야 시스템이 커지더라도 부작용이 적을지 고민해야 했다. 이에 대한 대응책이 추상화를 하고, 요소마다 디자인 패턴을 적용하는 것이었다. 오늘날에는 그런 방식을 오버 엔지니어링이라고 한다. 직설적으로는 어리석은 짓이라고 말하지만 그 당시에는 아키텍트의 혜안이라고 했다.
아키텍처 팀에서 몇 개월 정도 지나 팀내 아키텍트들과의 유대 수준이 전에 일하던 개발팀 동료들에 비해 너무나 낮다는 것을 느꼈다. 팀을 옮겼는데도 여전히 이전 개발팀 동료들과 점심을 먹고, 코딩에 대해서 이야기하고 애플리케이션을 어떻게 구현했는지 물어보고 있었다. 전에 비해 업무 시간 외에 코딩하는 일이 훨씬 더 많아졌다는 것도 깨달았다. 업무 시간에는 코딩을 하지 않기 때문에 개인 시간을 들여서라도 어떻게든 부족함을 메워야 했다.
거의 1년 동안 문서 작업과 다이어그램만 그리다 보니 더는 일을 계속 할 수가 없었다. 상사에게 개발팀으로 돌아가고 싶다고 했다. 그는 놀란 얼굴로 “아키텍트로 일을 잘 하고 있는데 왜? 아키텍처 팀이 얼마나 선망받는 팀인지 모르는가? 얼마나 많은 개발자들이 아키텍트가 되고 싶어하는지 알고 있나?”를 물었다. 물론 알고 있었다. 나 역시 아키텍트를 원했고, 많은 개발자가 아키텍트가 되고 싶어 한다는 것도 모르지 않았다. “네, 알고 있습니다. 저를 대신할 사람을 쉽게 찾으실 수 있을 거라고 생각해요.” 일주일 후 나는 다시 개발팀으로 돌아갔고 코딩의 즐거움도 되찾았다.
* 역자주 IBM의 S/W 모델링 도구