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

* 써 놓고 보니 서론은 정말 읽을 필요 없겠습니다. 본론으로 점프 하세요. ^^;;

블로그를 개설한 이후 아침마다 습관처럼 하는 것이 방문 통계 보는 것입니다. 몇 사람이 방문했는지를 먼저 보기는 하지만 검색 키워드를 가장 유심히 보게 됩니다. 어떤 이유로 이 어둠의 장소까지 흘러 들어오셨는지 참 궁금하더라구요. 그런데 어제 어떤 분이 '프레임워크를 사용하는 이유' 라는 키워드로 제 블로그를 방문해 주셨더군요.

사실 많은 분들이 이런 질문을 한 번 쯤은 하셨을 것 같습니다. 저도 물론 그랬구요. 굳이 프레임워크가 아니더라도 어떤 기술을 써야 할지 말아야 할지 늘 고민을 하게 되죠. 그래서 저 나름대로의 기준을 가지고 Lost In space of technology라는 글을 쓰기도 한 것 입니다.

사실 어떤 기술을 채용한 이유를 순전히 객관적으로 설명하라고 하면 과연 얼마나 많은 사람이 그걸 논리적으로 설명해서 반대자들을 설득 할 수 있을까요? 어떻게 설명이야 하겠지요. 그러나 수 많은 논란만 일으킬 뿐 결론이 나지는 않을거라고 생각합니다. 그 사람이 하는 설명이 어느 정도의 합리적인 형태를 갖추기야 하겠지만 저는 기술적인 결정의 지배적인 요인은 현실적으로 정치적인 타협 또는 신념의 관철이라고 봅니다. 한마디로 취향인거죠. 다행히 팀의 취향이 동일하다면 별 문제 없이 그 기술이 적용되겠지만 누군가 불만이 있다면 팀장이나 일부 어떤 오피니언 리더의 고집과 평화주의자들의 침묵 가운데 어쩔 수 없이 쓰게 되는 경우가 될 겁니다.

저도 몇 번은 어거지로 기술을 도입하게 했던 범죄를 저지른 경험이 있고... 또 투덜거리면서 맘에 들지 않는 기술을 억지로 사용했던 적도 있습니다. 잘 진행이 안될 때 그 기술을 도입하자고 했던 사람을 공격하는 것은 물론 잊지 않았죠. ㅎㅎ

요즘은 어떤 기술을 쓸지 결정하는 과정에서 권위 있는 발언을 하는 사람은 보통 '이해관계자'라고 번역되는 Stakeholder들이라고 생각합니다. 한마디로 돈줄을 쥐고 있는 사람들이죠. 고객이 될 수도 있고 투자자가 될 수도 있고... 사장이 되기도 하고... 이 사람들은 어디선가 봤던 기술 단신 또는 식사를 같이 했던 영업사원의 감언이설에서 그 기술에 대한 환상을 갖게 되고 이것을 기술진들에게 강요하곤 합니다.

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


서두가 길어졌는데 제가 프레임워크를 쓰는 이유를 간단히 생각나는 대로 적어보았습니다.
  1. 코드 품질을 보장하기 위해
  2. 백지의 압박이 싫어서
  3. 언어의 표준화
  4. 유지보수성
  5. 개발 편의
  6. 뒤쳐지지 않고 있다는 위안
하나씩 간단히 설명을 해볼까요?

코드 품질을 보장하기 위해

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

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

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

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

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

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

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

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

백지의 압박이 싫어서

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

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

언어의 표준화

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

유지보수성

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

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

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

개발 편의

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

뒤쳐지지 않고 있다는 위안

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

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

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

by 박성철 | 2007/12/17 17:18 | 프로그래밍 이야기 | 트랙백(2) | 덧글(7)

트랙백 주소 : http://gyumee.egloos.com/tb/1151159
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from 한국스프링사용자모임 K.. at 2008/07/01 01:16

제목 : 프레임워크에 관한 인상적인 글, 두 개
서핑하다가 프레임워크에 관한 인상적인 글 두 개를 봤습니다. 둘 다 봄날포럼[footnote]봄날포럼? 설마 모른다곤 하지 말아주세요[/footnote]에서 부지런히 글 쓰는 이들이라 뿌듯하군요. Application Framework 개발의 원칙 낮에 일하느라 바빠서, 혹은 눈치 보여서[footnote]젠장, 떳떳하게 봐야지 이런 글은[/footnote] 못봤다가 집에 와서 본 글. 짧긴 짧다. 기본적인 이야기지만, 간과할 내용은 아니다. 현......more

Tracked from 한국스프링사용자모임 K.. at 2008/07/01 01:16

제목 : 프레임워크에 관한 인상적인 글, 두 개
서핑하다가 프레임워크에 관한 인상적인 글 두 개를 봤습니다. 둘 다 봄날포럼[footnote]봄날포럼? 설마 모른다곤 하지 말아주세요[/footnote]에서 부지런히 글 쓰는 이들이라 뿌듯하군요. Application Framework 개발의 원칙 낮에 일하느라 바빠서, 혹은 눈치 보여서[footnote]젠장, 떳떳하게 봐야지 이런 글은[/footnote] 못봤다가 집에 와서 본 글. 짧긴 짧다. 기본적인 이야기지만, 간과할 내용은 아니다. 현......more

Commented by 뜨 내 기 at 2007/12/28 13:31

struts 를 배우는 중 왜 이걸 쓰는지 몰라 검색으로 들어오게 되었습니다

말씀을 들으니 조금 이해가 가는군요 잘 배우고 갑니다 감사합니다
Commented by 박훈 at 2008/01/02 17:06
일하세요!!!
(옆자리에서... ㅋㅋ)
Commented by ookoo at 2009/07/04 18:30
좋은 글 감사합니다. ^^
Commented by 초짜 at 2009/10/22 15:25
스프링 mvc 적용중에 있습니다.
글을 보면서 프레임워크에 대해서 다시 한번 생각하는 계기가 되었습니다.
좋은글 감사합니다.^^
Commented by 골드만삭스 at 2010/02/09 11:29
기존의 모델1 기반을 springMVC 등 다른 프레임워크 기반으로 변경하는 부분을 검토중에 님의 글을 구글링 햇습니다. ^^
좋은 자료 감사합니다. 제가 미처 생각치 못햇던 부분에 대해서도 다시한번 돌아봐야 겟내요. 2주정도 도입에 대해 우리 실정에 대해. 고민중..
Commented by mao at 2014/08/20 17:06
글 감사합니다. 이해하기 쉽게 정리해주셔서..
제 블로그에 저장했어요~~출처는 적었습니다.^^
꾸벅.~
Commented by mz at 2015/10/01 23:54
품질을 떨어뜨리지 않기 위해서

라는 구문이 마음에 참 와닿았습니다 :)

:         :

:

비공개 덧글

◀ 이전 페이지다음 페이지 ▶