프레임워크를 사용하는 이유

프레임워크를 사용하는 이유

프레임워크를 사용하는 이유

서두가 길어졌는데 제가 프레임워크를 쓰는 이유를 간단히 생각나는 대로 적어보았습니다.

1. 코드 품질을 보장하기 위해
   
2. 백지의 압박이 싫어서
3. 언어의 표준화
4. 유지보수성
   
5. 개발 편의
6. 뒤쳐지지 않고 있다는 위안

하나씩 간단히 설명을 해볼까요?

코드 품질을 보장하기 위해

저희 개발팀에 프레임워크라는 것을 처음 도입한 유일한 이유는 코드 품질 때문이였습니다. 품질을 향상 시키려는 게 아니고 품질을 떨어트리지 않으려고...;;;

저랑 한두 명이 일할 때는 제가 모든 사람의 코드를 살펴 보고 문제가 있는 부분은 지적해서 고치게 했었습니다. 작동만 하면 된다는 것은 저한테 통하지 않았기 때문에 저 때문에 많이 힘들어 했었을 겁니다. 다른 사람이 자기 코드를 한줄한줄 짚어가면서 잘못을 지적한다면 무척 기분 나쁘겠죠. 하지만 남의 돈을 받아가면서 일을 하는 이상 일정한 품질은 반드시 유지해야 한다고 생각했습니다. 저도 사회 초년생일 때에 저희 상사에게서 그렇게 배웠구요. 저도 기분 나빴지만 솔직히 배우는게 더 많았습니다.

그런데 사람들이 더 늘어나면서 품질에 문제가 생기기 시작했습니다. 저도 제가 맡은 분량이 있으니 모든 사람의 코드를 다 살펴보는 것이 사실상 불가능해진 것이죠. 문제는 여기저기서 생기고... 이미 그렇게 하면 안된다는 것을 다른 사람들은 알고 있었지만 신입사원에게 그것이 전달되는 시스템은 없었던 것입니다.

개발팀이 체계적으로 잘 만들어져서 운영된다면 따로 교육기간도 있고 품질 관리나 개발 방법론 같은 것도 정립되어야 할 것 같지만 저희 같이 작은 회사에서 그런 것을 다 만든다는 게 힘들 뿐 아니라 솔직히 오히려 부작용만 있을 수 있다는 생각이 있습니다. 오히려 문화를 만들고 공유하는 것이 더 효과적이지요.

같은 언어를 쓰고 같은 방식으로 설계하고 구축하는 것이 정착된다면 품질 때문에 문제가 되는 일이 많이 줄어들 것이라 생각했고 그래서 적당한 프레임워크를 도입하거나 만들어 쓰게 되었습니다.

혼자 일한다면야 이런 부분에서 문제를 별로 느끼지 못하시겠지만 팀의 품질을 일정 수준으로 유지해야만 하는 상황, 더구나 특별히 누군가가 그 일을 위해서 시간을 투자해 신경을 쓸 수 없는 상황에서 적절한 프레임워크를 도입하게 되면 많은 효과가 있는 듯 합니다.

그러나 외부의 프레임워크를 그대로 가져다 쓰면 이것이 자연스럽게 해결되지는 않더군요. 오히려 이 프레임워크를 더 다듬어서 다양한 사례에 적용해보고 그 결과를 공유하는 작업이 필요했습니다. 저 같은 경우는 이 부분에서 신경을 쓰지 못해서 수년 동안 문제 있는 코드가 회사 내에 유령처럼 떠돌아다니는 상황을 목격했습니다. 

이런 코드는 사실 제가 투입되지 않았던 프로젝트에서 대부분 생산이 되었는데 이것을 없애기가  바퀴 벌래 박멸 보다 더 힘들어 보입니다. 사실 제가 포기하고 말았지요. 결국 아키텍처는 그 프레임워크로 어플리케이션을 개발하는 사람 중 하나가 만들어야 한다는 말은 진짜 옳은 말입니다.

백지의 압박이 싫어서

무슨 일을 할 때에 일을 하는 순서가 정해진 것과 매번 백지에서 하는 것과는 심리적으로 느끼는 부담감이 다릅니다. 프레임워크는 이런 부담을 많이 줄여줍니다. 일의 순서가 정해져 있으니 그것을 따라 하면 되는 것이죠. TDD가 주는 부수적인 이점도 비슷하다고 생각합니다. 일단 돌려서 결과를 볼 수 있다는 게 개발의 지루함을 많이 줄여주게 되니까요.

프레임워크를 사용한 다양한 예제가 있다면 더욱 좋다고 생각합니다. 저도 대부분 예전에 작업했던 코드를 가져다 수정하는 방식으로 개발을 많이 하는데 프레임워크가 사용하지 않았다면 이런 일은 어렵겠죠. 매번 새로운 프레임워크를 써야 하는 상황이라면 조금 다르다고 생각하는 분이 계시겠지만 같은 방식의 프레임워크 간의 포팅은 완전히 새로 짜는 것 보다 쉽게 느껴지더군요. 예를 들어 struts로 개발한 코드를 struts2나 spring mvc로 포팅하는 것은 쉬운데 tapestry나 jsf로 포팅하는 것은 비용이 많이 들겠죠. 저는  struts의 코드를 spring mvc로 포팅해서 구축한 경험이 있었는데 그리 어렵지 않았습니다. 처음부터 다시 짠 것 보다 더 빨리 작업했는지는 모르겠지만 적어도 맘은 편했습니다. ^^

언어의 표준화

앞의 코드 품질과 관계되기도 하는데 개발 할 때에 프레임워크를 도입하게 되면 자연히 그 개발 철학과 언어도 같이 들어오게 됩니다. 그러면서 자연히 언어가 통일되게 되죠. 서로 대화도 편해지고 명확해집니다. 자연히 사고 방식도 맞춰지구요.

유지보수성

다른 사람이 만든 코드를 들여다 보는 게 얼마나 힘든 일인지 개발자들이라면 다 알겁니다. 그걸 수정하느니 다시 만드는 게 낫다고들 하죠. 그런데 그게 타사의 개발자가 만든 코드가 아닌 같은 회사의 개발자가 만든 코드라면 좀 문제가 심각한 것이겠죠.

저는 기본적으로 같은 회사의 개발자들은 큰 부담 없이 서로의 코드를 이해 할 수 있어야 한다고 생각합니다. 그래야 품질도 어느 수준에서 보장되는 것이고 유지보수 비용도 적게 들게 되는 것이고 재사용도 할 수 있게 되죠.

프레임워크를 사용하면 그런 면에서 많은 도움을 받을 수 있습니다. 저는 어떤 일을 하게 되면 동료들에게 비슷한 경우가 있었는지 물어보고 그 코드를 가져다 수정하는 식으로 작업을 합니다. 물론 이렇게 하려면 프레임워크를 어떻게 사용 할지에 대한 것도 시간이 지남에 따라 어느 정도 정형화 되어야 하겠지요. 

개발 편의

대부분의 프레임워크들은 개발을 편하게 하기 위한 다양한 기능들을 가지고 있습니다. 이런 것은 제가 따로 만들 수도 있겠지만 제 경험상 프레임워크에서 제공해주는 코드가 제가 만든 것 보다 훨씬 낫더군요. 저 보다 똑똑한 사람이 만든 게 분명해 보였습니다. ^^

뒤쳐지지 않고 있다는 위안

개발자라면 늘 최신 기술 흐름에서 떨어지지 않으려는 욕심이 있을 겁니다. 모든 것을 외부의 도움 없이 스스로 해결 할 수도 있겠지만 어느 한 순간 우물 안 개구리가 되는 경우도 있지요. 꼭 트렌드를 따라야 한다고 말하고 싶지는 않구요. 오히려 남들이 안하는 특수 분야를 파고 드는 것이 장점이 될 수도 있다는 것은 인정합니다. 하지만 전 좀 남들에게 개발자로 인정 받고 싶은 욕심이 있어서 그런지 외골수로 파고들기 보다는 약간은 흐름을 타고 싶더라구요.

실패를 방지하기 위한 어설픈 조언

이왕 글을 쓴 것... 프레임워크를 사용하면서 쓰라린 경험을 가지고 계신 분이 있다면 몇 가지 조언을 드려볼까 합니다. 대부분 제가 실패한 경험을 기초로 적었습니다.

1. 그 프레임워크의 철학과 해법에 동의하지 않는다면 절대 도입하지 마십시오. 혹시 그 철학이 이해되지 않는다면 더욱 도입해서는 안됩니다.
   
2. 한번만 쓸 생각이라면, 그리고 그 코드가 계속 유지보수 되어야 할 성질의 것이 아니라면 그냥 하던 대로 하십시오. 프레임워크뿐 아니라 대부분의 신기술 도입은 생각보다 ROI 주기가 상당히 긴 것 같더군요.
3. 개발 일정이 빡빡하고 개발자들이 그 프레임워크에 익숙하지 않다면 포기하십시오.
4. 그 프레임워크를 소개만하고 도입하는데 헌신 할 생각이 없다면 포기하십시오. 그것이 성공적으로 정착 되도록 남들 보다 더 연구하고 미리 고민하여 문제를 해결해둬야 합니다.
5. 풍성한 사례별 예제를 준비하십시오.
6. 단계별로 도입하는 방법을 찾아보세요. 순식간에 100% 새로운 프레임워크 환경으로 이전하는 것은 비용이 너무 많이 들고 실패 할 확률이 높습니다. 아주 기본적인 것만 적용해서 프로젝트 진행 했더라도 대부분의 개발자들은 '아직도 이해 못하겠어'라고 말 할겁니다. 개발하는 것도 정신 없어 죽겠는데 프레임워크를 따로 신경 쓰면서 공부 할 사람이 몇이나 있겠어요. 그냥 하라니까 하는거죠.

아... 일해야 하는데 내가 뭐하는 것인지...ㅠ.ㅠ

출처 http://gyumee.egloos.com/1151159