느린 걸음으로 살아가기

최근 몇 년 사이에 소프트웨어 개발 분야에서 유행하게된 널리 단어로 '아키텍쳐'가 있다. 새롭게 만들어진 단어도 아니고 아주 오래전부터 영어사전에 등재되어 있던 것이고, 하드웨어 분야에서는 아주 오래 전부터 상식으로 쓰여진 단어인데 유달리 소프트웨어 분야에서는 최근 들어 더욱 더 관심이 높아진 듯 하다. 그건 아마도 소프트웨어의 규모가 급격히 늘어가고 있기 때문에 단순히 소프트웨어를 '개발한다'라거나 '코딩한다', '구현한다'는 단어만으로는 거대한 비지니스 프로젝트를 설명하거나 혹은 표현하기 어려워졌기 때문일 것이다. 아니면, 고급 개발자들이나 컨설턴트들이 자신의 몸값을 높이기 위해, 자신의 일을 과장하기 위해 쓰는 것일지도 모른다. 비슷하게 각광받는 단어로는 '프레임워크'라는게 있다. 문제는 아키텍쳐라거나 프레임워크라는 단어의 의미를 설명해보라고 하면 거의 모든 실무자들이 얼버무리기 시작한다. 그냥 다들 알고 있는게 아닌가, 굳이 설명해야 하는가 묻는 표정으로 멀뚱멀뚱 바라보기 일쑤다. 자신이 쓰는 용어를 제대로 이해하고 설명할 수 없다면, 대체 그 일을 어떻게 제대로 수행할 수 있을까? 의심스럽지 않은가? 목표도 모르고 전진하기만 한다면 대체 그 목표에 어떻게 닿을 수 있을까?

그나마 어렴풋이 아키텍쳐라는 단어에 대해 설명을 시도하라고 하면 거대한 프로젝트를 수행하기 위한 소프트웨어 혹은 프로젝트의 구조라거나, 각종 컴포넌트(구성 요소)들을 쌓아올리는 과정과 각 요소간의 관계를 설명한 것이라고 할 수 있다. 스스로 이런 설명을 하면서도 의문점을 가지지 않을 수 없다. 왜 거대한 프로젝트라는 제약이 필요한가? 작은 함수나 프로그램을 만들 때는 아키텍쳐가 필요 없는가? 혹은 거대한 구조를 설명하기 위해 아주 큰 부품간의 관계만을 설명하면 되는가? 다수의 프로젝트를 수행하면서 느낀 점은 대규모 프로젝트를 수행하는데 있어서 거시적인 설계를 아무리 잘 하더라도 미세한 설계를 등한히 한다면 기필코 프로젝트가 실패하게 되더라는 점이다. 이것은 굉장힌 중요한 문제이다. 예를 들어 거대한 유조선을 설계한다고 하면 분명히 청사진을 그리고 뼈대를 튼튼히 만들고, 강력한 엔진과 좋은 철강을 쓰는 것이 중요한 일일 것이다. 하지만, 건조 중에 사소한 실수로 배밑을 용접하다가 작은 구멍이라도 생긴다면 어찌될 것인가? 거대한 배가 겨우 작은 구멍 때문에 대해에서 침몰할 수도 있게 되는 것이다.

최근의 프로젝트 경향이라거나, 소프트웨어 분야의 기술 동향을 살펴보면 지나치게 거시적인 면을 중시하고 미세한 부분 혹은 아주 기초적인 부분들이 외면되고 있다는 것을 발견하게 된다. 물론 이러한 문제들을 해결하기 위한 답으로 완성된 시스템을 면밀하게 검사해주는 다양한 도구(제니퍼와 같은 모니터링 툴, 이클립스나 IntelliJ에 포함된 소스 점검 기능, JUnit 등의 테스트 툴)들이 나오고 있지만, 옛 경구대로 이런 것들은 사후약방문일 뿐이다. 이미 개발이 완료된 시스템에 수많은 결점들이 내포되어 있을 경우 그것을 해결하기 위해 드는 시간과 노력은 개발 당시보다 몇 배로 증가할 뿐더러, 만일 운영 중인 시스템이 중단된다면 그 기회 비용 상실과 피해 복구 비용을 따지는 것은 무의미할 정도가 되어 버린다.

어디서나 하는 말이지만, 결국 기초가 부족하면 안된다는 말을 되풀이 하게 된다. 아무리 좋은 프레임워크를 도입하고 아무리 생산성 좋은 개발환경을 구축한들 개발자 개개인의 자질이 부족하면 좋은 소프트웨어를 만들 수 없게 된다. 도요타 자동차가 세계적인 자동차 메이커가 된것은 그들의 훌륭한 경영진 뿐 아니라 컨베이어벨트 옆에서 매순간 자동차를 조립하는 조립자들의 장인 정신이 결합되었기에 가능한 일이다. 물론 열악한 환경에서 일하기에, 개발 기간이 촉박하기에 어쩔수 없다는 변명을 늘어놓을 수도 있다. 그렇게 남의 탓이라는 나름의 이유을 늘어 놓는다고 해서 자신의 처지가 나아지는 것이 아니다. 더구나 남이 나서서 내 운명을 바꾸어주지 않는다. 환경이 바뀌기 기다리는 것은 로또가 당첨되기를 바라는 것과 다르지 않다.

점점 거대화 되어 가는 소프트웨어들을 제대로 만들기 위해서 다양한 해법들이 제시되고 있고, 다양한 프레임워크들이 나오며 개발자들은 프레임워크를 받아들이지 못해 헤메고 있는 것이 현실이다. 프레임워크들이 생산성을 높여줄 것이라는 환상도 많이 작용하고 있어 프레임워크가 silver bullet이나 만병통치약 쯤으로 이해된 적도 있지만 세상에 어떤 솔루션이나 개발 언어도 개발 생산성을 갑자기 높여주지는 않는다. 아무리 좋은 프레임워크도 그것을 습득하고 제대로 다루지 못하면 프랑켄슈타인과 다를 바 없고, 제대로 다룰 줄 아는 엔지니어들이 있다고 한들 문제는 모든 엔지니어가 동등하게 고급 기술을 습득할수도 없다는 것이다.

그렇다면 당장 눈앞의 프로젝트들과 앞으로 개발해야 하는 무수한 난제들을 어떻게 해결해야할 것인가? 프레임워크를 버릴 필요는 없다. 다양한 도구를 가지는 것은 다양한 해법을 가지는 것과 같다. 프레임워크도 개발 툴도, 각종 라이브러리들도 모두 다 필요한 도구들이다. 전쟁을 이기기 위해서는 다양한 병법을 필요로 한다. 군대 구성도 공군, 육군, 해군에다가 특수부대도 필요하다. 개발에서도 마찬가지다. 그런데, 전쟁을 마치기 위해서는 결국 육군이 점령지를 밟아야 한다는 말처럼 개발에서도 절대적으로 필요한 것이 있다. 결국 개발자가 프로그램을 짜야 한다는 것이다. 아무리 좋은 툴, 서버, 프레임워크와 훌륭항 아이디어를 가지고 있어도 개발자가 코드를 잘 작성해야만 프로젝트가 성공하는 것이다.

거시적(macro) 아키텍쳐가 중요하지만, 더욱 더 중요한 것은 미시적(micro) 아키텍쳐다. 달리 말하자면 좋은 코드를 작성하는 개발자가 가장 중요한 자산이라는 것이다. 좋은 코드를 짜는 개발자는 결국 개발 속도가 빠르고 디버깅하기 좋으며, 유지보수가 어렵지 않은 프로그램을 만들어 낸다. 아키텍트 혹은 프로젝트 매니저가 해야하는 중요한 일들 중에서 결국 가장 중요한 것은 사람을 잘 선택하거나 혹은 사람을 가르치는 것이다.

이 글과 관련있는 글을 자동검색한 결과입니다 [?]

• 왜 아키텍쳐 설계가 필요한가? by 써니
• 새 책 왔다!! by Solid_One