[개인생각] ProFrame에 대한 상반된 시선

ProFrame 싫다.

처음 ProFrame이란 프레임워크를 접했을 때는 상당히 거부감이 들었다. 

Proframe은 많은 것을 제공한다. 업무개발자는 정말 순수 업무 로직만 개발하면 된다. 개발자 입장에선 편리하다는 장점이 있지만 너무 많은 편의로 인해 개발 실력을 쌓을 많은 기회를 놓치게 된다. 한참 성장하고 싶은 초보 개발자의 입장에서 이점이 가장 싫었다. C언어를 사용하여 개발하는데도 Proframe을 이용하면 인프라 레벨의 low level 프로그래밍을 할 기회가 거의 없어진다. OS, 네트워크, 프로세서 동작 구조, 메모리 관리와 동작방식, 라이브러리 동작, 링커/로더등에 대해 이해하고 고민할 필요가 없어진다. 그저 입력구조체를 만들고 데이터를 받아 처리하는 업무로직을 구현하고 출력구조체로 가공된 데이터를 던져주기만 하면 된다. 인프라 레벨의 모든것을 프레임워크가 처리해준다. 편리하다. 하지만 배우는게 적다.

ProFrame 팀에 들어와서 교육을 받으며 처음 몇주간은 속으로 욕을 했다. 왜 이렇게 개발자의 자유를 억압 해뒀을까? ProFrame 사용하는 개발자는 이러다 바보가 되는 것 아닌가 하는 생각도 들었다. 

ProFrame 좋다.

팀에 들어와서 현재 ProFrame을 사용하고 있는 많은 기업들과 아직 사용하지 않았지만 사용하려고 준비중인 기업들의 이슈들과 입장을 알고나니까 ProFrame이 왜 이렇게 만들어졌는지 이해가 가기 시작했다. 개발자로 성장하고 싶던 내 입장에선 ProFrame이 적이였는데 개발된 시스템을 운영하는 운영자나 기업입장에서는 ProFrame이 정말 좋은 선택지가 된다. 

몇천줄 몇만줄이 넘어가는 거대시스템이 pro*c로 짜여있다면 후임자가 업무 하나 변경하는데도 소스 파악을 위해 꽤 오랜 시간을 투자해야하고, 인프라 레벨까지 직접 구현되어 있어 작은 변경에도 수많은 테스트가 필요할 것이다. 이 경우 문제가 생기면 개발자의 책임이기에 어지간한 실력과 업무에 대한 지식이 없으면 어디서부터 손대야 할지 난감한 경우도 많다. 

하지만 ProFrame를 이용해서 개발한 시스템은 EMB design이라는 방식으로 한눈에 업무 파악을 하기 쉽고, 업무 로직들이 모두 각각의 업무 모듈로 개발되어 동적링크로 구성되기 때문에 해당 업무모듈만 변경 후 테스트, Hot deploy로 간단하게 변경이 가능하다. 인프라 레벨은 개발자가 전혀 손대지 않기 때문에 업무 변경에 있어서 훨씬 안전하고 인프라 레벨의 문제는 티맥스소프트에서 기술지원을 받으면 되기 때문에 책임 소재의 부분에 있어서도 자유롭다.

실제로 기존 시스템을 수정하며 운영하는 것이 너무 어려워서 ProFrame을 도입하는 레퍼런스가 증가하고 있다. 

개발자의 생산성이 비교하기 힘들만큼 좋아지기 때문에 기업입장에서 man/month 를 책정할때도 이점이 있을 것이다.

결론적으로, 장단점이 있다.

ProFrame은 철저하게 System Software의 영역과 Application의 영역을 구분하는것을 지향한다. 최대한 AP 개발자들에게 편의를 제공해 업무 로직 구현에만 집중하게 하고 인프라 레벨은 알아서 관리해준다. 익숙해지면 정말 편하고 생산성이 매우 높아진다.

하지만 배움에 목마른 개발자들은 ProFrame을 이용한 개발 이외에도 스스로 많은 공부를 병행 해야 할 것이다. 자칫 잘못하면 반쪽짜리 개발자가 될 수도 있다. 근데 이건 비단 ProFrame만의 문제는 아니고 대부분의 프레임워크들이 그런것 같다. UI단에서 넥사크로를 이용하면 화면 개발이 정말 편해지지만 화면 뒷단에서 어떤식으로 UI가 동작하고 그려졌는지 큰 고민을 안하게 되는것처럼, 혹은 자바 Spring 프레임워크를 사용할 때 구현된 Spring API를 가져다 쓰면서 그 API가 어떻게 구현되었는지 크게 고민하지 않고 사용했던 것처럼. 

다른점이 있다면 Spring 쓸때는 그래도 개발자인 내가 주도적인 느낌이였는데 ProFrame으로 개발할때는 주도권을 ProFrame에게 빼앗긴 느낌이 들어서 처음에 조금 반발감이 심했던 것 같다.