Back-end & Framework...

Back-end.. Server side...

 

 나의 시작은 Front 개발자였고 엄밀히 말하면 안드로이드 개발자를 지향 하였다. 하지만 세상은 그렇게 녹녹치 않았다. 

첫회사가 스타트업 이였고 서버 개발자가 필요 한 경우가 다 많았다. 갓 졸업한 나에겐 spring framework 는 생소했고 어려웠고 이해가 안갔다. 

 그래서 그냥 쌩~ 자바로 서버를 짰다. 쓰레드풀을 만들고 커넥션풀을 만들고 accept ... 되는 족족 쓰레드를 만들어서 돌리고 ... 로그는 어떻게 쓸까 고민하다가 로그 생성하는 자바 쓰레드를 만들고 ... 수정하고 또 수정하고 ...

그렇게 회사가 망했다. 내가 남은건 과연 성능적으로 괜찮은지 모를 프로그램 소스와 수제 유틸리티들 ... 힘들게 들어간 회사가 망해서 허망했지만 난 다시 일을 하기위해 구직을 해야 했다. 이때 참 좋은 팀장님을 만나 인생이 바뀐거 같다. 

 스프링이 뭔지도 모르는 나를 채용하셨고 가르쳐 주기 시작하셨다. 단순히 mvc 패턴으로 서비스를 구성해서 api 몇개를 만들어보고 스스로 뿌듯했다. 그리고 기계처럼 일단 아는것만 가지고 사용하기 시작했고 뭔가 더 필요하기 시작한 시점이 오면서 스프링을 파기 시작했다... AOP , ID 이런 개념도 모르고 일단 쓰기만 했던 나에겐 스프링은 마냥 어려운 툴이였고 그냥 자바로 짜면 안되나 ? 라는 생각이 한동안 지배 했던거 같다. 

 

 Spring , Node.js , Play .... 등등 

 

프레임워크 = 디자인 패턴 + 라이브러리 

 

프레임워크는 다양하다. 언어별로 대표하는 프레임워크들은 하나씩은 꼭 존재하는거 같다. 왜일까 ? 근본적인 물음이 생겼다. 프레임워크를 왜 쓰는가 ? 장단점을 먼저 생각해보기로 했다. 

 

프레임워크 장점 

 1. 구조화, 추상화 ,재사용성이 좋다. 

 2. 안정적인 성능을 보장

 3. 유지보수가 쉬워진다. 

 4. 확장성을 보장한다. 

 5. 개발시간 단축

 

프레임워크 단점

 1. 하나의 출력을 위해 여러가지 작업이 일어나므로 무겁다. 

 2.  프레임워크에 의존도가 높아지면 개발자 개인 능력이 낮아 진다. 

 

구글링해보면 뭐 이런식으로 나오는거 같다. 일부는 동감하는 부분도있지만 또다른 부분은 동감하지 못하는 부분도 있다. 

 

나만의 정의를 내리자면 프레임워크를 쓴다는것은 내가 회사에 속해있고 결과물을 내고 유지보수를 해야한다면 정말 너무 단순한게아니라면 쓰는게 맞다고 본다.  그렇게 생각하는 이유는 아래와 같다. 

 

1.  품질 보장 

 프레임워크를 사용할경우 어느정도 디자인패턴과 코딩 패턴이 강제되는 부분이 있다. spring 만해도 mvc 패턴에 최적화 되있다. 그리고 bean 객체를 생성하는 부분이라던가 기능적으로 볼때 일반적으로 개발할때 활용할법한 기능들이 이미 구현되있다. 그렇다면 이것들을 사용하기위해선 최소한의 코드레벨을 지켜나가며 코딩을 해야하고 경력이 아무리 낮은 신입개발자라 하더라도 그들이 만들어내는 코드는 최소한의 구성과 로직을 가지고 생성될것이다. ( 물론... 개판으로 만들려고 맘먹으면 개판은 되더라... ) 

 

2. 언어의 표준화 

 앞서 말했지만 언어별로 대표되는 프레임워크들이 존재한다. java = spring 이런 극단적인 공식이 감시 성립한다고 말할수도 있을거 같다. 개인 개발자나 학자 레벨에선 분명 프레임워크에 종속되면 안되고 넓은 사고방식으로 상황에 맞는 언어와 프레임워크를 사용해야하는게 맞다고 생각한다. 하지만 회사에서 그렇게 되면 어떻게 될까 ? 최악의 상황을 볼수 있다. java, php, python , ruby , c# 등 회사에 서비스들이 이 언어들을 전부 사용하고있다면 ? 유지보수가 과연 쉬울까 ? 프레임워크 버전관리부터 어마어마한 일거리들이 생길것이다. 상황에 맞게 언어를 쓰되 기본으로 회사를 대표하는 언어는 필요하지 않을까 ?

 

3. 유지 보수성

 언어의 표준화에서 나온 이야기의 연장선이다. 스프링개발자들끼리 뭉쳐서 일을하면 적어도 담당자가 없을때 어디서 장애파악을 시작할지 코드를 보자마자 어느정도 시발점을 찾기 편하다. 스프링이라고 명시해서 그렇지만 정확히는 mvc 패턴을 충실히 지킨 프로젝트라면 세세한 로직은 몰라도 어느부분에서 문제를 파악하기 시작해야하는지 대충 예측이 가능하다.  이게 별거인가라는 생각하는 사람들있는데 코드가 단순하다면 굳이 프레임워크를 써야만 유지보수성이 좋다고 할수 없다고 할수 있다.  그러나 잘생각해보면 단순한 코드만 사용하는 회사가 있을까에 의문을 던진다.  개발년차가 쌓이면서 기획,영업 등 수많은 요청사항이 있고 그에 따른 예외처리가 추가 되기 시작하면 그 프로젝트는 점점 꼬이기 시작한다. 그럼 시작은 작고 단순했던 프로젝트가 나중에는 점점 살이 붙어 비대해지기 시작할것이고 그걸 관리하겠다고 프레임워크를 도입하려는순간 재앙을 만나는경우가 부지기수였다. 

 단순 학습을 위해서 , 테스트를 위한 더미 프로그램 형식의 프로젝트라면 프레임워크는 필요치 않다. 하지만 내가 정식 서비스를 하고 오래동안 사용할거라면 그리고 내가 이걸 평생 혼자 볼게 아니라면 프레임워크를 통한 보편적인 유지보수성 확보는 팀을 위해 회사를 위해 필수이지 않을까 싶다!

 

4. 인력풀 관리 

 가끔 인력채용시 채용 공고내용에 대해서 문의를 받는경우가 있다. 그럴때마다 항상 느끼는건 프레임워크 = 기술 로 정의되는 공고내용은 가장 확실하고 간단한 공고 내용인거 같다. 채용공고 내본사람들중에

" java,c,pyton, go , ruby  등 사용가능한자"

"Play Framework, Spring boot 사용가능한자 "

두가지로 구했을때 회사 입장에선 어떤 사람을 구하기 편할까 ? 결론적으로는 후자 인거 같다. 그리고 면접시 질문도 명확하다. 프레임워크 단점에 보면 프레임워크 의존성이 높을수록 기술력이 낮아질수 있다라는말이 있는데 난 여기서 그 내용을 전적을 반박한다. 프레임워크를 많이 사용하고 공부를 했다면 그 원리에 대해 충분히 알것이고 그것을 응용하거나 더 나은프레임워크 혹은 로직을 스스로 개발할수 있는 능력이  있다고 본다. 프레임워크가 아무리 개발을 서포팅하기 위한 툴이라지만 아무 이해도 없이 툴을 제대로 사용이 가능할까 ? 툴을 잘사용했는지만 캐치할수 있더라도 인력을 채용할때 아주 좋은 지표가 될수 있다고 생각한다. 

 그리고 프레임워크를 기준으로 뽑은 인원들은 업무시작전 초기 교육시간이 획기적으로 줄어든다. 회사 입장에서 봤을때 오자마자 바로 업무에 투입할수 있는게 좋지 않을까 ? 

 

 

 모든 기술에 끝은 없다. 그리고 절대자도 없다. 프레임워크들은 한때 핫하게 떠올랐고 그에 따라 무지한상태서 무분별한 사용으로 인해 성능에 문제가 있어서 문제가 있다라는 반성이 필요한 이슈도 있었다. 프레임워크는 이정도만 알면 완벽해하는 개발자들을 무수히 봤고 굳이 새로운 버전을 써야하는가에 대한 의구심을 가지는 개발자들도 많이 보아왔다. 

 프레임워크들은 지금도 무수히 나오고 있고 무수히 업데이트 되고 있다. 있던 기능이 바뀌고 성능이 개선되고 다른 디자인패턴들을 지원하고 수많은 상황에 대처하고 있다. 예전에 쓰던방식이 멈춰있다면 과연 내 포지션은 미래에 어디쯤 있을까 ? 예전에 아무리 마스터 급으로 프레임워크를 사용했어도 그 기술은 내일이라도 노후된 기술이라고 할수있다.

  프레임워크의 원리를 이해하기 위해서 디자인패턴을 공부하게 되고  프레임워크가 지향하는 기술의 원리등을 공부해야만 제대로된 사용이 가능하다. 난 게으른 개발자다 프레임워크를 쓰면서 이해가 안가고 필요한기능을 잘쓰기 위해서 어쩔수 없이 공부를 한다. 프레임워크가 나에게 주는 이로운 영향이라고 생각한다. 프레임워크가 없었다면 아마 그전에 사용하던 생 자바 코드를 계속 복붙해가며 쓰지 않을까 ?

 

요구조건은 시대에 따라 달라지고 그 요구조건을 수용하기위해 무수히 많은 기술들이 쏟아지고 있다. 그리고 그 기술들을 잘 사용하고 서비스에 잘 구현하기위해 프레임워크들은 저마다 방식으로 지원을 하고 제안을 한다. 

 프레임워크 없이 개발을 해도 된다는 사고방식은 단언컨데 효율적인 방법은 아니라고 생각한다.  쓸필요 없다고 생각이 드는  경우라면 잘생각해길 바란다.  역으로 묻고 싶다. 굳이 사용하지 않을 이유는 있는지 ?

만일 사용하지 않는 이유가 프레임워크 사용하는데 불편하거나 적용이 힘들다면 미안하지만 그건 제대로 공부하지 않은 사람의 핑계라 생각한다.