The Art of Software Development

'Boo 를 배우며' 라는 포스트에 달린 댓글 중에 다음과 같은 것이 있었다 - 나는 프레임웍을 배우는데에만 집중을 한다. 그러는 것이 내 가치를 높일 수 있기 때문이다. 새로운 언어를 배우거나 DSL 같은 새로운 개념을 배우는 것은 단지 프레임웍을 배우는 데에 드는 시간만 뺏길 뿐이다. 이는 아주 일반적인 태도다. 나는 자기들의 관심은 마이크로 소프트의 툴들을 배우는데 있다고 하는 사람들과 많은 대화를 해 보았다. 그들은 마이크로 소프트의 툴을 배우는 자체만으로도 충분히 힘들고 그 하나로도 경력에 최고의 도움이 된다고 한다. 나는 ASP.NET MVC 경력 2년 등을 개발자의 능력으로써 평가하는 리쿠르터들이나 회사들을 봤다.

동시에 많은 개발자들에게는 레드몬드 (마이크로 소프트 본사가 있는 도시)에서 쏟아져 나오는 새로운 프레임웍들의 수가 따라가기 힘들어 보이기도 한다. 그런 개발자들은 반드시 따라잡아야 한다고 느끼고 자연히 중압감을 느낀다. 불행하게도, 한 프레임웍을 배우는데 집중하는 것은 함정이다. 어제 했던 것을 오늘 하기 위해서는 배워야 되는 또 다른 새로운 프레임웍이 나올 것이다. 마이크로 소프트에서 나온 데이타 엑세스 프레임웍들이 얼마나 많은지 보자. 배운 지식은 금새 낡은 것이 된다. 프레임웍을 하나 배우고 또 배우고, 결국 러닝머신위에서 달리기를 하는 것처럼 된다. 단지 새로운 프레임웍에 대한 경험을 쌓고 이력서를 관리하기 위해서 미래의 고용주가 사용하는 프레임웍의 범위 내에서 다음 직장을 찾아야 하는 함정에 빠진다.

프레임웍에 대한 지식이나 특히 자격증으로 개발자를 평가하는 것은 회사가 빠질수 있는 똑같이 위험한 함정이다. 이것들은 아무리 좋게 봐야 개발자에게 실제로 필요한 기술이 무엇인지에 대해 속는 것이다. 최악의 경우, 한 특정한 기술에 대한 지식의 투자는 개인이나 회사에게 변화에 방해가 되는 족쇄가 되기 때문에 감옥에 갇히는 것과 마찬가지다. 웹폼에 뛰어난 개발자들을 고용하거나 벤더 컨트롤 킷들을 배웠다고 해서 어떻게 다음 프로젝트에 ASP.NET MVC 를 적용할 수 있을까? 결국, ASP.NET MVC 에는 아무런 경험도 없으니 말이다. 그렇다면 이제 팀 전체를 해체하고 ASP.NET 경력 개발자들을 다시 고용해야 할까? 아니면, 항상 바뀐다면 ASP.NET 페이지 생명주기를 이해하고 있는 개발자들을 뽑는 것이 무슨 도움이 될까? 새로운 프레임웍을 배울 능력이 있는 개발자를 고용하는 것이 더 낫지 않을까?

내가 지금 보다 젊었을때, 최신의 기술들을 배우는데 촛점을 맞추곤 했었다. 왜냐하면 내 가치를 높혀주는 최상의 길로 보았기 때문이다. MFC 와 ATL 등의 내부구조를 알기 위해 수없이 많은 시간을 쏟아 부었고, STL, Boost, Loki 같은 것들에 대해서 상세하게 설명을 할 수 있었다. 그런 라이브러리들에 대해 전문가가 되고 싶었다. 최신 프레임웍들을 사용할 기회가 오지 않으면 새 직장을 찾아 봤다. 그래서 내가 더 나은 개발자가 되었을까? 아마 그랬을지도 모른다, 하지만 내가 기대했던 것과는 달랐다. 그런 프레임웍들에 쏟아 부어 얻은 것은 결국 그 프레임웍들이 기반하고 있는 공통적인 패턴들을 알게 되었다는 것이다. 그 내부가 어떻게 구현 되었는지를 이해함으로써 무엇인가를 배웠을지도 모른다. 하지만 나에게 가장 많은 득이 된것은 이터레이터, 팩토리, 템플릿 메서드 같은 패턴에 대한 깨달음이었다. 그 후 다른 라이브러리를 배우려고 했을 때는 내가 이해한 문제들을 어떻게 풀었는지, 내가 아는 패턴과 원리들을 어떻게 사용하고 있는지를 보았다. 이것은 바로 그 프레임웍으로 더 빨리 일을 할 수 있다는 것이었다. 하지만 난 이것을 힘들게 알았다. 내가 알고 있던 패턴을 알아 차리거나 어디에 구현이 되어있는지를 본 것이 아니라 그것들이 반복되고 있다는 것을 알아차림으로써 깨닫게 된 것이다.

우리들 같은 수많은 사람들이 Patterns of Enterprise Application Architecture 같은 마틴 파울러의 책이나 DSL 의 GUI Architecture 같은 글에 열광을 하는 이유는 그들은 그러한 패턴과 원리들을 찾아내기 때문이다. 모델, 뷰, 컨트롤러에 대한 탄탄한 지식은 여러 다른 웹 프레임웍들을 더 빨리 배울수 있게 도와준다. 그 이유는 그 프레임웍들이 문제를 어떻게 해결하는지를 보려고 하기 때문이다.

Boo 에서 DSL을 어떻게 작성하는가 같은 새로운 기술을 배우는 것은 아키텍쳐가 더 잘 설계된 애플리케이션을 만들수 있는 폭넓은 방법들을 제공해준다. 유지보수의 부담이 새로 만드는 부담보다 크다. 따라서 더 잘 설계된 애플리케이션은 회사의 입장에서는 항상 더 나은 투자이다. 최신의 프레임웍에서 이상한 기능을 짜내는 것보다도 훨씬 낫다.

만약 소프트웨어 산업이 아주 기초적인 프레임웍에서부터 나아간 것이 있다면 그리고 추상화가 더 나아 졌다면, 어떻게라는 것은 점점 이해할 필요가 없어지고 왜라는 것은 더 많아 진다. 패턴과 원리들에 대한 지식은 프레임웍이 변해도 지속되는 가치를 제공한다. 또한 프레임웍을 어떻게 사용해야 하는지를 이해하는데 도움이 되고 가장 좋은 활용방안에 대한 판단의 기준으로도 사용할 수 있으며 딱히 좋은 방안이 없을 때 프레임웍을 변칙적으로 사용할 수도 있게 해준다.

사람들을 인터뷰할때, 나는 세세한 것보다 원리에 대한 이해를 더 비중있게 본다. 문제는 '더 나은' 프레임웍이나 인기있는 새 패러다임이 항상 있을 것이기 때문이다. 어느 프로젝트에서든지 사용하고 싶은 새로운 언어가 있을 가능성은 항상 있기 마련이다. 원리를 이해하는 사람들은 적응을 할 수 있고, 세세한것에 촛점을 둔 사람들은 변화에 비타협적이다. 왜냐하면 자신들이 전문가가 된 프레임웍에 너무 많은 투자를 했기 때문이다.

나는 사람들이 자신이 사용하는 툴들을 최대한 활용하기 위해서 어떻게 사용하는지 몰라도 된다고 말하려는 것은 아니다. 그건 당연한 것이다. 하지만 프레임웍 뒤에 있는 원리들을 이해함으로써 새로운 프레임웍을 효과적으로 배우고 평가하는 방법이 개개의 프레임웍을 배우는 것보다 훨씬 효과적인 방법이라는 것을 알게될 것이다.