프레임워크 만능주의

지금, 이 순간 당신이 처음부터 다시 시작해서 개발자가 된다고 상상해보자. 열정이 넘치고 똑똑한 당신이라면 무엇부터 어떻게 시작할까? 평소 컴퓨터에 관심이 많고 관련 정보를 일부러 찾아 읽는 수준이라면, 프론트엔드는 React, 백엔드는 Spring이 대세라는 정도는 알고 있을 것이다. 물론 여전히 프레임워크가 무엇인지조차 정확히는 모르겠지만, 나름대로 깊이 고민한 끝에 프론트엔드 개발자로서의 길을 선택하고 React부터 차근차근 알아가 보기로 결심한다.

 

React에 대한 첫인상은 그리 나쁘지 않다. 파이썬으로 기본적인 알고리즘을 몇 번 공부해본게 전부라 두려움도 있었지만, 그러나 프레임워크 자체는 생각보다 복잡하지 않다. 무엇보다 개발한 결과물이 즉시 화면에 표시되면서 개발하는 맛을 느낀다. 개발이 재미있어진다면 더 열심히 할 수 있을 것 같다는 장밋빛 미래도 그려본다. React 강의도 듣고, 공식 문서도 훑어보며, 틈틈이 유명한 사이트의 클론 코딩도 시도해본다. 기회가 오면 멋진 사이드 프로젝트도 진행한다.그렇게 6개월이라는 시간이 흘렀다. 자, 이제 당신은 개발자가 된 것일까? 매우 안타깝지만, 아니다.

무엇이 문제였을까?

 

 

프레임워크 만능주의

프레임워크의 가장 큰 장점이자 단점은 너무나 강력하고 매력적이라는 것이다. 프레임워크를 사용하기로 결정한 순간 프레임워크는 우리에게 개발에 필요한 모든 것을 제공한다고 약속해 준다. 프레임워크가 제공하는 구조와 문법에 따라서 코딩하기만 하면, 복잡해 보이던 애플리케이션도 간결하게 만들어진다는 놀라운 경험을 할 수 있다. 갑자기 나를 겁줬던 개발자들이 다 엄살이었단 생각이 든다. 이런 프레임워크의 강력함을 경험하고 나면 프로그래밍 == 프레임워크라는 생각이 절로 든다(그렇기에 자바스크립트를 배우기 전에 리액트를 먼저 하는 것 아니겠는가?). 나는 이런 프레임워크의 강력함에 매료되어 모든 것을 프레임워크로 해결하려는 현상을 프레임워크 만능주의라고 부른다

 

프레임워크는 과연 얼마만큼 중요할까? 실제로 프레임워크는 중요하다. 프레임워크는 개발에 필수적으로 필요하지만 복잡하거나 번거로운 개념적 구조를 아주 쉽고 명확하게 표현하도록 해준다. 이 차이는 이렇게 말로 표현되는 것보다 엄청난데, 엔터프라이즈 애플리케이션을 스프링 같은 프레임워크 없이 개발하는 건 이제는 상상하기조차 힘들다. 프레임워크의 또 다른 중요한 측면은 협업에서 드러난다. 개발자의 개발 스타일은 다양하기 때문에 규모가 큰 애플리케이션을 만들 때 이들의 스타일을 통일하는 것은 항상 해결해야 하는 까다로운 문제다. 프레임워크는 정교한 구조와 자체 문법을 강제하여 개발자들끼리 협업 시 스타일을 통일하는 그라운드 룰로써의 역할을 해준다.

 

그렇다면 프레임워크의 단점은 무엇일까? 프레임워크는 아무것도 해결하지 않는다는 것이다. 놀랍게도 모든 걸 해결해 줄 것만 같았던 프레임워크는 사실 아무것도 해결해 주지 않는다. 그토록 강력한 프레임워크가 왜 아무것도 해결하지 못하는걸까? 그 이유는 간단한데 프레임워크는 당신의 문제를 모르기 때문이다. 프레임워크는 당신이 어떤 비즈니스 도메인에 속하는지, 어떤 문제를 해결하고자 하는지, 어떤 사용자 시나리오를 구현하는지 모를 뿐만 아니라 관심도 없다. 모르는데 어떻게 해결하겠는가? 프레임워크의 관심사는 이미 널리 알려져 있고, 대부분의 애플리케이션 개발에 있는 공통적이고 일반적인 문제들이다. 이것들이 당신이 해결하고자 하는 문제에도 일부분 포함되기 때문에 프레임워크를 사용하는 것이 개발에 도움이 되겠지만 애플리케이션의 핵심이 되는 비즈니스 로직과는 무관할 것이다.

 

이 문제를 어떻게 해결하면 좋을까? 잠시 고민하다가 아주 좋은 생각이 났다. 프레임워크가 우리 문제를 몰라서 해결하지 못한다면, 프레임워크에 우리 문제를 알려주면 되지 않는가? 프레임워크는 분명 똑똑하니까 문제만 알려주면 해결 방법을 찾아낼 것이다. 안타깝지만 그런 일은 일어나지 않는다. 프레임워크는 만능이 아니다. 프레임워크에 당신의 문제를 알려주는 순간 프레임워크는 든든한 친구이자 동반자에서, 내 일에 사사건건 간섭하면서 지는 마음대로 행동하는 난폭한 친구로 돌변할 것이다. 이런 상황을 프레임워크와 비즈니스 로직이 강하게 결합하였다고 한다.

 

우리가 꽤 유용한 애플리케이션을 만들고 있다면 비즈니스 문제를 해결하는 개념적 구조 자체가 이미 복잡할 것이다. 여기에 프레임워크가 강하게 결합되면 복잡성이 떨어질거라는 기대와는 달리 서로의 개념적 구조 차이로 인한 우발적 복잡성이 매우 크게 증가한다. 이제 비즈니스 로직을 구현할 때 프레임워크 눈치를 봐야할 뿐만 아니라, 갑자기 비즈니스 변화에 맞추기도 바쁜데 프레임워크가 업데이트 되더니 비즈니스 로직을 쑥대밭으로 만들고 간다. 점점 비즈니스 로직은 무겁고 복잡해진다. 유지보수 비용은 높아지고 새로운 기능 업데이트는 갈수록 느려진다. 참다참다 못해 심각성을 인지하여 비즈니스 로직과 프레임워크를 분리하기로 결심하지만 이미 늦었다. 둘 결합의 가장 큰 문제는 한번 결합되면 다시 분리하기가 매우 어렵다는 것이다. 애플리케이션 가장 깊숙한 곳까지 스며든 프레임워크와 작별하는 일은 마치 내 삶에 반쪽이었던 연인과 이별하는 것 만큼의 후유증을 가져온다. 정말이다.

 

위에서 살펴본 것 처럼 프레임워크는 만능이 아니다. 매우 유용하고 사실상 필수적인 도구이지만, 프레임워크는 우리의 핵심인 비즈니스 문제를 모르고 알아서도 안된다. 프레임워크가 아무리 발전하더라도 우리가 애플리케이션의 핵심 비즈니스 로직에 집중하도록 도와주는 것 그 이상으로는 기능하지 못한다.

 

 

프레임워크 주도 개발

프레임워크는 막강한 무기처럼 보이지만, 그것이 만능은 아니다. 그럼에도 불구하고 핵심 로직에 깊게 집중할 수 있게 도와주기에 그 가치는 여전히 크다. 특히 '순수한 비즈니스 로직'의 중요성을 자랑하는 스프링 프레임워크 같은 도구를 사용하는 개발자들은 “내 이야기 아니네”하고 넘어갔을지도 모른다. 아무튼 이런 관점에서 프레임워크는 여전히 필요하기에 프로젝트 시작 시점에 선정하고 가는 것은 꽤 합리적으로 보인다. 그렇지 않은가?

 

나는 여기서 프레임워크의 숨겨진 한계점에 주목하고 싶다. 프레임워크는 그 자체로는 단순히 기술적 구성 요소들의 집합일 뿐이다. 즉 프레임워크도 특정 상황에 적합한 개념적 구조를 표현하는 도구일 뿐이라는 것이다. 현대의 트렌드를 따르는 프레임워크는 현대 애플리케이션 개발의 필요성에 부응하는 개념적 구조를 표현할 것이다. 하지만, 그 프레임워크의 개념적 구조가 정말로 당신의 애플리케이션에 완벽히 적합한가? 그렇다 해도, 앞으로도 그렇게 적합할 것이라고 자신할 수 있을까?

 

진정한 전문가 개발자라면 문제를 보고 개념적 구조를 잡아 이에 적합한 기술을 선택하여 문제를 풀어나갈 것이다. 하지만 특정 프레임워크와 같은 기술에 매몰되거나 선택할 수 있는 도구가 한정된 사람은 기술 중심으로 개념적 구조를 먼저 잡고 이를 문제에 대입하여 해결하려 한다. 이는 주도하는 주체가 정반대로 된 것으로 나는 이를 프레임워크 주도 개발이라고 부른다.

 

프레임워크 주도 개발은 심각한 안티패턴이다.프레임워크의 개념적 구조와 당신의 실제 문제에 필요한 개념적 구조가 상충할 때, 우발적 복잡성이 높아지게 된다. 그뿐만 아니라 비즈니스가 변화하고 성장함에 따라, 기존 프레임워크로는 더 이상 적합하지 않을 수 있다. 그렇기에, 항상 프레임워크 선택은 유동적이어야 한다. 프레임워크는 단지 도구일 뿐이다. 이를 잘 이해하고, 상황에 따라 올바른 도구를 선택하는 능력이 우리에게 필요하다.

 

그렇다면, 프레임워크 주도 개발이라는 안티 패턴은 대체 왜 등장하게 된 것일까? 나는 그 원인 중 하나로 프레임워크의 강력함을 꼽을 수 있다. 하지만 더 중요한 원인은 현대의 프로그래밍 교육 방식에 있다고 생각한다. 소프트웨어 분야가 성숙해지면서, 우리가 현재 사용하는 애플리케이션의 개념적 구조와 초기 개발자의 개념적 구조 사이의 차이는 점점 벌어지게 되었다. 이러한 상황에서 초기 개발자들에게는 소프트웨어 발전 흐름에 따라 개념을 순차적으로 습득하기보다, 바로 최신 기술을 배우고 그 기술 내재된 개념적 구조를 습득하는 방식이 더 효과적으로 다가올 수 있다. 이 방식의 핵심 장점 중 하나는 학습자의 흥미를 유발하는 것이다. 최신 기술의 활용을 통해 빠르게 결과물을 만들어내는 경험은 학습자에게 큰 만족감을 주기 때문이다. 그러나, 이러한 교육 방식의 함정은 명확하다. 학습자들은 기술을 습득할 때 그 안에 내재된 개념적 구조에 너무 의존하게 된다. 즉, 문제를 만났을 때 그 문제에 맞는 개념적 구조를 만들어 기술로 해결하는 대신, 이미 알고 있는 기술의 구조를 문제에 강제로 맞추려는 경향이 생긴다. 이런 방향은 문제 해결의 본질적인 접근법과는 정반대의 패러다임을 가진다. 이러한 교육 방식의 가져오는 함정을 깨달아야 한다. 그렇지 않으면, 프레임워크와 기술의 강력함에만 의존하게 되어, 진정한 문제 해결 능력을 잃어버릴 위험이 있다. 우리는 기술을 도구로 활용하는 데 그치지 않고, 본질적인 문제 해결 능력을 계속해서 키워나가야 할 책임이 있다.

 

 

기술 스택 수집가

앞서 보았던 특정 프레임워크에 매몰된 유형과는 또 다른 극단에 있는 유형이 있다. 이들은 인터넷 광고에 나오는 <한번에 배우는 72가지 필수 기술 스택> 같은 슬로건에 마음을 자주 뺏기며 기술 스택을 마치 카드 수집하듯이 쌓는 것을 좋아한다. 나는 이런 유형을 ‘기술 스택 수집가’라고 부른다.

 

아마 개발자라면 모두 새로운 기술 스택에 대한 강박이 있을 것으로 생각한다. 내가 모르는 새로운 기술 스택이 등장하거나, 친구랑 이야기하다가 모르는 기술 스택이 나오면 마치 뒤처진 것만 같은 불안감이 엄습해 온다. 이런 강박은 어디서 오는 걸까?

 

내 생각에는 이런 강박은 우리 업계에 뿌리 깊은 통념인 “기술은 끊임없이 변하고, 이에 맞춰 개발자는 평생 공부해야 한다”에서 나온 듯하다. 개발자라면 분명 위와 같은 말을 들어 본 적이 있을 것이고 이를 직업의 숙명으로 삼고 있을 것이다. 기술의 변화에 맞춰 새로운 기술을 계속 공부하는 것은 물론 좋은 일이다. 문제는 시간이다. 매일매일 새로운 기술이 쏟아져나오는 상황에서 모든 기술을 팔로우하는 것은 현실적으로 불가능하다. 개발자라면 기술의 폭도 중요하지만, 개발자라면 기술의 폭도 중요하지만, 자신이 사용하는 기술의 깊이를 가져야 한다. 하지만 당신이 모든 기술을 팔로우하기로 마음먹은 순간 당신의 하루는 새로운 기술들에 둘러쌓여 사라질 것이다.

 

또 다른 문제는 강박으로 인해 쫓기듯이 하는 기술 공부가 과연 얼마나 유용할지에 대한 것이다. 강박으로 인한 공부는 필요성을 느끼고 주도적으로 하는 공부가 아니라 단순히 불안을 잠재우기 위한 것이다. 이런 공부의 특징은 기술을 폭 넓은 맥락에서 이해하기보다 단순한 사용 방법에 집중한다는 것이다. 우리가 기술을 공부하는 이유는 이 기술의 표현하는 개념적 구조를 학습하고 이를 적절한 문제해결 상황에 적용하기 위해서이다. 하지만 사용 방법에만 집중해서는 이러한 유연성을 기르기 어렵다.

 

“기술은 끊임없이 발전하며 바뀌고, 이에 맞춰 개발자는 평생 공부해야 한다”라는 통념은 개발자의 시간과 집중력을 낭비하는 것처럼 보인다. 이러한 관성에는 항상 의문을 제기해 볼 필요가 있다. 특히 그것이 낭비를 일으키고 있다면 반드시 그래야만 한다.

 

 

기술은 정말 끊임없이 변하는가?

지식은 자주 변하지만 많이 바뀌진 않는다. 인간은 자주 변하지 않지만 변화의 깊이가 깊다.
-켄트 백-

 

그렇다. 이 질문에 의문을 제기하기는 어려워 보인다. 사실상 매일 새로운 기술들이 자신이 기존 기술보다 유용함을 주장하면서 쏟아져 나오고 있다. 좀 더 유용한 질문은 이 모든 기술들을 모두 배워야 하는가? 이다.

 

이 질문에 답하기 전에 먼저 개발자는 왜 기술을 배워야 할까? 기술이 계속 변하기 때문이다. 자신이 지금 사용하는 기술도 결국 사라지고 새로운 기술이 등장할 것을 알기 때문이다. 새로운 기술에 적응하지 못하는 개발자가 도태되는 경우를 우리는 너무 많이 봐왔다. 어느 누구도 20년 째 자바랑 이클립스만 외치는 개발자가 되고 싶지는 않을 것이다.

 

그렇다면 기술은 왜 변할까? 무엇이 기술의 변화를 초래하는가? 아무리 생각해도 비즈니스 외에는 생각나는 게 없다. 이 대답에 반증을 제시할 수 있겠는가? 비즈니스 변화가 기술의 변화를 이끈다. 결국 왜 기술을 배워야 할까에 대한 답은 비즈니스 변화에 대응하는 개발자가 되기 위해서이다. 우리는 기술의 변화보다는 비즈니스 패러다임의 변화에 집중해야 한다.

 

변화의 대상이 기술에서 비즈니스로 바뀌었다. 기술과 비즈니스는 무엇이 다를까? 기술은 하루 단위로 새롭게 쏟아져 나온다. IT 비즈니스도 자주 바뀌긴 하지만 기술만큼은 아니다. 내 생각에 비즈니스 변화와 관련 없는 기술들은 우선 배제되어도 되는 기술들이다. 이들은 자신들의 유용함을 주장하지만, 그것들이 비즈니스 문제와는 크게 관련이 없으며 이미 자리를 잡고 있는 기술과 표현하는 개념적 구조가 비슷하기 때문에 실제 사용이 필요해졌을 때 학습해도 무리가 없다.

 

드디어 모든 기술을 배워야 하는가? 에 대한 답을 내릴 수 있게 되었다. 우리의 시간과 집중력은 한정되어 있기에 모든 기술을 배울 수 없다. 그렇기에 배워야 하는 기술과 안 배워도 일단은 되는 기술로 나눠야 한다. 배워야 하는 기술은 비즈니스 변화로부터 파생된 기술들이며, 변화된 비즈니스 문제 해결의 필연적이고 적합한 개념적 구조를 지니고 있다. 안 배워도 일단은 되는 기술은 비즈니스 변화와 관련되지 않은 모든 것들이다. 이들은 배워야 하는 기술과 비즈니스 문제 해결에 있어서 크게 차이가 없으며 조직에서 사용을 결정했을 때 배워도 늦지 않는 것들이다. 이렇게만 해도 팔로우해야 하는 기술의 수를 대폭 줄일 수 있으며 어느 정도 강박에서 벗어날 수 있다. 오해하지 말아라 기술 공부가 중요하지 않다는 게 아니라 시간은 한정되어 있고 우리는 더 중요한 것들에 집중해야한다는 것이다.

 

 

개발자와 기술 간의 관계

우리는 위에서 개발자와 기술 간의 관계가 역전된 3가지 경우를 살펴봤다. 프레임워크 만능주의와 프레임워크 주도 개발은 특정 기술적 요소에 매몰된 경우이며, 기술 스택 수집가는 너무 많은 기술적 요소에 휩쓸려 가는 경우이다. 언뜻 보면 반대인 것 같지만 3가지 경우 모두 문제를 풀기 위한 기술이 아닌 기술로 문제를 푸는 경우에 속한다. 개발자와 기술 간의 올바른 관계는 무엇일까?

 

내 생각에 기술은 개발자에게 보조도구일 뿐이며 이 이상으로 중요해질 수는 없다. 먼저 기술은 개발자에게 도구일 수밖에 없다. 기술은 결국 문제 해결에 적합하도록 취사 선택돼야 하는 대상이기 때문이다. 우리는 이를 프레임워크 주도 개발과 기술 스택 수집가를 통해 살펴봤다. 또한 기술은 주 도구가 아니라 보조도구일 수밖에 없다. 기술은 당신의 비즈니스 도메인을 모르며 비즈니스의 핵심적인 문제 해결에 도움이 되지 않기 때문이다. 우리는 이를 프레임워크 만능주의를 통해서 살펴봤다.

 

우리는 기술적 요소를 항상 과대평가해 왔기 때문의 보조도구라는 말이 평가절하처럼 들릴지도 모르겠다. 그런데 목수가 망치로 나무를 다듬는 것만큼 우스운 일도 없으며, 망치질 못하는 목수만큼 한심한 일도 없다. 보조도구라고 할지라도 기술은 여전히 중요하다. 당신이 회사나 조직에서 사용하고 있는 기술은 전문가 수준으로 깊게 알고 다룰 수 있어야 한다. 그래야 우습지 않을 것이다. 내 말은 단지 더 중요한 일이 있다는 것이다. 문제를 이해하고 해결하기 위한 적합한 개념적 구조를 모형화하는 일 말이다. 기술이 활약하는 건 그다음이다.