2015.02.20 13:27

한참을 내달리고 있는 프로젝트에 뒤늦게 합류해서, 선행팀이 늘어놓은 짐들을 정리하는 중입니다. 덕분에 주말에도 나와서 코드를 분석하게 되었죠. 프로젝트 파트 리더라는 역할에다가 Application Architect라는 역할을 더하고 있기 때문에 주중에는 거의 회의 참석에 시간을 뺏기게 되고 주말에야 조금 코드를 들여다 볼 수 있습니다.


오늘 분석하게 된 코드는 Code Generator 입니다. 데이터베이스의 스키마 정보를 읽어내서, VO(Value Object), DAO(Data Access Object), CRUD (Create, Read, Update, Delete) 쿼리, 웹 페이지에서 입력받은 데이터에 대한 검증 코드(validator)까지 자동으로 생성하는 모듈입니다. 작년에 다른 프로젝트에서 이러한 기능을 이클립스 플러그인 형태로 만들어서 프로젝트 팀원들이 낭비하는 시간을 줄여준 적이 있기 때문에 가벼운 마음으로 분석을 시작했습니다.


그러나, 정작 엉뚱한 곳에서 분석 흐름이 막혀 버리더군요. 제 경험으로 이해하기 어려운 코드들이 보이는 것입니다. 예를 들자면 ...Wrapper, ...Resolver 라는 클래스인데 정작 속성(property)와 입출력(getter/setter) 메소드 외에는 별다를 로직이 없더군요. 이거 어디서 많이 본 명명 패턴(naming pattern) 인데 잘못 적용했구나, 왜 이런 식의 의도하지 않은 실수가 나왔을까? 하는 생각이 꼬리에 꼬리를 물었습니다. 그리고 참 많은 생각을 하게 되었습니다.


일단, ~er 이라는 접미사(postfix)를 왜 붙이는지 따져 봅니다. 무언가 단일 행위에 대한 책임을 전담하는 클래스에 대해 ~er이라는 접미사를 붙이고는 합니다. 즉, 일반적으로 ~er로 끝나는 클래스는 Value Object 같은 데이터 보관 및 전달 역할에 쓰이지 않을 것라고 암묵적인 합의를 가지고 있습니다. 이런 원칙 혹은 관습은 어느 학회나 표준화 단체에서 정한 것이 아니라 관습으로 내려온 것이죠.


그럼 이런 관습을 우리가 따라하게된 근거는 무엇일까요? 앞서 언급한 접미사들은 Spring framework에 익숙하신 분들이 많이 보셨을 겁니다. 바로 Spring framework를 창시한 로드 존슨(Rod Johnson)과 그의 동료들( 유겐 할러 Juergen Hoeller 등)에 의해 굳어진 패턴입니다. 또, 예전에 스프링 프레임워크 3.0를 처음 접했을 때, 무턱대고 '토비의 스프링 3.0'을 저술하신 이일님 님에게 메신저로 이렇게 질문해 본적이 있습니다. 대체 스프링 프레임워크는 어떤 역사를 가지고 있느냐고, 기원(origin)이 무언가 라고 말입니다. 토비님 왈, 그냥 어느 날 로드 존슨이 만들어서 세상에 내놓았습니다.


우리가 익숙하게 써 온 기술들의 대다수, 업계 표준(de-facto standard)라고 알고 있는 것들, 원래 그런 것이다.. 라고 하는 것들이 수맣은 개발자들에 의해 합의되고 고쳐지고 또 개선되어 온 것이 아니라, 소수의 선각자(pioneer)들에 의해 어느 날 뚝딱 만들어진 것입니다.


스프링을 수많은 개발자들이 모여서 만들지는 않았습니다. 스프링 기반의 상용 프레임워크 - 전자정부 프레임워크 같은거죠... -를 설계 및 개발했을 때, 스프링 소스를 이리저리 분석해봤습니다. 거의 대다수의 소스에 작성자(author) 및 수정자 이름으로 로드 존슨과 유겐 할러의 이름이 적혀 있더군요. 스프링 프레임워크가 견고하고, 그 설계의 일관성이 유지된 이유는 수 많은 개발자들이 협력해 만들지 않았기 때문입니다. 이것은 역설처럼 들리지만, 또한 진실입니다. 많은 SI 프로젝트에서 개발자를 더 투입하면 일정이 줄어든다고 생각하지만, 이러한 생각이 틀렸다는 것은 이미 오래 전부터 피플웨어 (톰 디마르코, 티모시 리스터 지음) 같은 책에서 설파되어 왔습니다.
아키텍쳐를 제대로 이해하고, 핵심 모듈에 대한 품질을 유지하면서 프레임워크 혹은 핵심 엔진를 만들기 위해 소수의 개발자, 바로 아키텍트(architect)들이 필요한 것입니다. 헨리 포드가 컨베이어 벨트 기반의 분업 시스템를 만들고 난 이후, 급격하게 공장 생산성이 늘어 났습니다. 에디슨이 전구를 상용화 - 발명한 것인지는 논란이 있죠 - 한 후, 인류의 밤이 없어지게 되었습니다.


이렇듯 점진적이지 않은 급격한 진화의 사례는 소프트웨어 업계에서도 많습니다. 아틀란타 행 비행기 안에서 만난 구루(guru) 2분, 켄트 벡(Kent Beck)은 자바를 배우고 싶었고, 에릭 감마(Erich Gamma)는 켄트벡의 스몰토크 테스트 프레임워크를 배우고 싶어 하다 두사람은 3시간 정도 일한 끝에 junit을 만듭니다. 지금은 보편적으로 쓰이는 UML(Unified Modeling Language)은 이바 야곱슨(Ivar Jacobson), 제임스 럼바(James Rumbaugh), 그래디 부치(Grady Booch) 3인방의 아이디어와 저술을 근간으로 하고 있습니다. 디자인 패턴(Design pattern)은 어떻습니까? 건축계의 아키텍트 크리스토퍼 알렉산더의 아이디어를 소프트웨어 공학에 적용한 것이고, 소프트웨어 디자인 패턴 핵심은 GoF (Gang Of Four) 에릭 감마(Erich Gamma), 리차드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시디스(John Vlissides) 4분에 의해 정리되었습니다.


작년에 모 금융 프로젝트를 2 계층에서 3계층으로 재구축하는 차세대 프로젝트를 수행하면서 경량의 TCP 서버 모듈을 구현하고자 Netty 를 분석 및 활용한 바 있습니다. 이희승(Trustin Lee)님이 만드신 경량 TCP/IP 프레임워크인데, 정말 객체를 우아하게 다루는 기법을 체험하고 싶으시다면 Netty 소스 분석을 권합니다. (감동 받다가 울 뻔 했습니다...) Netty 역시 여러 사람이 아닌, 거의 모든 설계를 이희승 님이 하신 것으로 알고 있습니다.


이 글은 열심히 일하는 소프트웨어 개발자들이 만든 코드를 힐난하기 위해 쓴 것이 아닙니다. 아키텍쳐와 코딩 패턴, 그리고 표준과 품질 등 일반적으로 소프트웨어 개발자들이 평소에 신경 쓰지 못하는 부분들이 얼마나 중요하고 그것을 지키기 어려운지 이야기 하고자 하는 것입니다. 또한, 왜 아키텍트(architect)가 필요한지 그들(혹은 우리들이) 어떤 일을 하는지 이야기 하고 싶었습니다. 다수의 개발자가 협력해서 만드는 시스템은 코딩 패턴의 일관성, 간결함, 우아함, 정교함 등의 좋은 소프트웨어가 가져야 할 덕목을 유지하기 어렵습니다. 코딩 표준을 지키도록 강제한다면, 혹은 정적/동적 코드 분석 툴(Code Analysis Tool, PMD 등)을 이용해 코드의 품질을 강제한다면 반대로 독창적이고 효율적인 코드를 만들어 내기 어렵습니다.


개발자들은 아키텍트가 어려운 용어만 늘어놓고, 비싼 몸값을 받는다고 생각합니다. 아키텍트는 개발자들이 아무 것도 모르면서 덮어놓고 비난만 한다고 생각합니다. 사실 서로 협력해야 마땅합니다. 다수의 개발자들이 사용하지 않는 기술과 프레임워크는 도태되어 사라질 뿐입니다. 반대로, 일반 업무 개발자가 아키텍트의 역할과 무거운 책임, 그리고 그들이 감내해야 하는 엄청난 수고에 대해 이해하지 못한다면 앞서 사례를 들어드린 절름발이 코드들이 난무하게 되는 것입니다. 아키텍쳐에 스며있는 숨어 있는 철학과 의도를 파악하기 어렵기 때문에, 또 그 철학과 패턴을 초지일관 고수하는 것이 너무나 힘들기 때문에 모든 프레임워크와 거대한 규모에 이르는 시스템은 소수의 아키텍트들이 책임져야 하는 것입니다. 단지, 그들이 욕심꾸러기이기 때문은 아닙니다.


앞서 소수의 아키텍트에 의해 성공한 사례들을 말씀드렸지만, 다수가 협력해 프레임워크를 만드는 것이 어려운 사례를 들어보자면 스프링 배치(Spring Batch) 프레임워크를 들 수 있습니다. 스프링 프레임워크의 한 갈래이지만 스프링의 사상을 이해하지 못한 결과, 어정쩡한 구조에 폭포수 모델(Water Fall) 기반으로 뚝딱 개발했다는 인상을 여전히 지우지 못하고 있습니다. (스프링이 최대 강점은 유연함인데, 스프링 배치는 향기 없는 꽃 같은 느낌을 주더군요.)


저는 아키텍트의 역할을 이야기할 때, 영화 매트릭스를 떠올립니다. 영화 속에서 Neo는 최종 보스(?)인 아키텍트를 만납니다. 아키텍트는 자신이 새로운 세상(New World), 새로운 패러다임(paradigm)를 만들고, 인간들에게 행복을 선사했다는 듯이 자만합니다. 하지만, Neo는 아키텍트가 만든 세상을 거부합니다. 아키텍트와 개발자들의 관계가 이와 같지 않나 싶습니다. 아키텍트는 새로운 패러다임을 설계하고, 개발자들은 붉은 알약 혹은 파란 알약을 선택하죠.


Posted by 善 곽중선