2024.06.03 (월)

  • 맑음속초20.4℃
  • 맑음24.0℃
  • 맑음철원24.2℃
  • 맑음동두천24.7℃
  • 맑음파주24.6℃
  • 구름많음대관령15.6℃
  • 맑음춘천24.0℃
  • 맑음백령도23.4℃
  • 맑음북강릉19.1℃
  • 맑음강릉21.7℃
  • 구름조금동해20.3℃
  • 맑음서울25.4℃
  • 맑음인천25.3℃
  • 맑음원주23.9℃
  • 구름조금울릉도19.5℃
  • 맑음수원24.2℃
  • 맑음영월27.6℃
  • 맑음충주23.6℃
  • 맑음서산24.7℃
  • 맑음울진19.5℃
  • 구름조금청주25.1℃
  • 맑음대전24.0℃
  • 구름조금추풍령21.6℃
  • 구름조금안동22.7℃
  • 맑음상주22.9℃
  • 구름조금포항20.2℃
  • 맑음군산24.5℃
  • 구름조금대구22.4℃
  • 맑음전주25.4℃
  • 구름조금울산20.9℃
  • 구름조금창원23.5℃
  • 맑음광주26.3℃
  • 구름많음부산20.7℃
  • 구름많음통영22.0℃
  • 맑음목포23.8℃
  • 구름조금여수21.2℃
  • 구름많음흑산도23.0℃
  • 구름많음완도26.8℃
  • 맑음고창27.2℃
  • 구름조금순천23.7℃
  • 맑음홍성(예)23.7℃
  • 맑음23.0℃
  • 구름많음제주23.5℃
  • 구름많음고산21.3℃
  • 맑음성산23.1℃
  • 구름조금서귀포23.5℃
  • 구름조금진주24.0℃
  • 맑음강화23.6℃
  • 맑음양평24.0℃
  • 맑음이천23.8℃
  • 구름조금인제24.0℃
  • 맑음홍천24.9℃
  • 구름많음태백20.0℃
  • 구름조금정선군23.4℃
  • 맑음제천22.5℃
  • 구름조금보은22.2℃
  • 맑음천안24.2℃
  • 맑음보령24.9℃
  • 맑음부여24.7℃
  • 맑음금산24.8℃
  • 맑음23.8℃
  • 맑음부안25.7℃
  • 맑음임실24.1℃
  • 맑음정읍27.1℃
  • 맑음남원25.5℃
  • 구름조금장수24.2℃
  • 맑음고창군26.9℃
  • 맑음영광군26.3℃
  • 구름많음김해시23.8℃
  • 맑음순창군25.3℃
  • 구름많음북창원24.2℃
  • 구름많음양산시23.5℃
  • 맑음보성군23.7℃
  • 구름조금강진군24.3℃
  • 맑음장흥24.4℃
  • 맑음해남25.1℃
  • 구름조금고흥24.0℃
  • 구름조금의령군25.4℃
  • 맑음함양군25.5℃
  • 구름조금광양시24.1℃
  • 구름많음진도군23.5℃
  • 구름많음봉화21.3℃
  • 구름조금영주22.2℃
  • 맑음문경22.5℃
  • 구름조금청송군22.0℃
  • 맑음영덕21.9℃
  • 구름조금의성23.6℃
  • 구름조금구미22.1℃
  • 구름조금영천21.2℃
  • 구름조금경주시22.6℃
  • 구름조금거창23.2℃
  • 구름조금합천24.7℃
  • 구름많음밀양22.9℃
  • 구름조금산청25.1℃
  • 구름많음거제21.9℃
  • 구름조금남해22.3℃
  • 구름많음23.5℃
기상청 제공
Business & Issue | 개발 방법론과 프레임워크 통합
  • 해당된 기사를 공유합니다

Business & Issue | 개발 방법론과 프레임워크 통합

   
 
Global Software를 꿈꾸며


고영률
유비원 대표이사
magic@ubqone.com

 


“우리
개발자들은 도대체 왜, 무엇이 문제인 것일까??
“내가 왕년에 이런 프로그램은 하루에도 수십 본씩 짰는데….”
“간단한 거 하나 고치는데, 왜이리 많은 시간이 걸리는 것일까??
하루에도 골백번씩 내가 직접 코딩을 하고 싶을 때가 많아진다.

Prototyping, Iteration을 하면 고객과의 Gap이 줄어든다고?
프로젝트만 하면 현업과 개발팀, 분석자와 개발자, 개발팀과 운영팀 간의 Gap은 왜 이리도 큰 것이며, 분석 시에 정의된 요구사항대로 왜 프로그램이 만들어지지 않는 것일까?
개발자가 밤새 개발한 소스들이 다음날 아침이면 쓰레기가 되는 이유는 무엇일까?
분석, 설계가 잘못 된 것일까? 정답은 잘못된 고객과의 소통이다.
이는 기업의 CIO나 PMO들이라면 한번쯤은 고민했을 이야기이고 남의 이야기가 아니라고 본다. IT가 기업의 필수 요건이 된 지난 십여 년간 이런 문제를 해결하기 위해서 내노라하는 SI업체와 컨설팅 업체에서 들고 적용했던 수많은 방법론과 케이스 툴들은 모든 것을 해결해 주지 못했다.
일부분 성과를 내기도 했지만 부분적인 해결에 불과했고 특히 현재와 같이 전문 개발인력의 부족 상황에서 고급 설계자만으로는 프로젝트를 성공하기에 매우 힘든 상황이 계속 될 것으로 생각된다.
불행하게도 현재 우리 IT 사회에는 개발인력이 너무도 부족하고 기술의 편차가 심하다. 프리랜서라고 불리는 개발자들은 대부분 책임감 없고 시키는 일만 하는 사람일 가능성이 너무나도 많다. 이런 상황을 극복하기 위한 방법은 무엇일까?
저자는 현재 우리가 사용중인 방법론과 프레임워크에 대해 조금만 사려 깊이 그리고 현실적으로 접근해 투자해가면  이러한 문제를 어느 정도 해결할 수 있다고 확신한다.
많은 프로젝트에서 활용되는 회사 고유의 방법론을 살펴보면 문서로 출발 한다.요구사항정의서, 추적표, 기능정의서, 화면정의서 등등 많은 문서를 작성한다.
하지만 시작부터가 잘못돼 있다. 개발과 운영을 잘하기 위해서 만든 문서가 정작 개발자의 70% 이상이 분석, 설계서만 가지고 개발을 할 수 없다고 말한다.
즉 개발자가 잘 알아볼 수 있도록 작성된 것이 아니고 고객과 매니저들이 알아보는 문서를 작성한 것이다. 특히 PM의 역량에 따라 더욱 더 많은 수준차이가 발생하는 것이 더 큰 문제라고 생각한다. 문서를 만드는 본질을 외면하고 있는 것이다.

   
 
사실 프로젝트 과정이 어찌됐건간에 개발 완료 후에 생성된 애플리케이션 소스를 Reverse Engineering 하면 작성된 산출물에 나와 있는 내용을 거의 알 수 있다.
물론 소스 자체로만 가독 하기에는 힘들지만 개발 전에 필요한 Metadata와 약속된 자료만 작성하면 얼마든지 가능 하다고 생각된다.
이것은 엔터프라이즈 아키텍쳐 개념에서 바라보면 애플리케이션 아키텍쳐의 구체적인 Metadata를 의미하는 것이고 데이터 아키텍쳐와의 긴밀한 연동을 의미한다.
쉽게 말하면 프로그램 구성, 기능, 화면, 컴포넌트, 데이터에 관련된 모든 내용을 코드화하고 데이터화하여 분석, 설계, 개발 시 자동화할 부분은 최대한 자동화하고 관리한다는 개념이다. 참으로 어려운 이야기지만 달리 보면 쉬운 이야기이다. 문서 작성자체를 개발에 도움이 되는 방법으로 진행하자는 아주 간단한 이야기이다.이런 식으로 분석, 설계를 진행 해야만 개발 프레임과 연동하여 개발단계와 구현단계의 Gap을 극복할 수 있다고 본다.

   
 
프로젝트의 생산성은 고급기술의 활용이 아니라 업무를 어떻게 빠르고 쉽게 그리고 고객이 원하는 대로 만들어 주는가에 있다고 생각한다. 그렇게 하기 위해서는 재 활용성이 우선된다.
하지만 이러한 장점을 살려서 개발을 하고자 한다면 참여하는 모든 사람이 우리가 가지고 있는 리소스(업무, 공통 기능)가 무엇인지 그리고 이미 만들어진 애플리케이션이 어떤 식으로 구성된 것인지를 쉽고 정확하게 파악할 수 있어야 하고 그런 것을 제공해 주는 프레임워크가 필요하다.
많은 SI 회사들은 각사 고유의 프레임워크를 사용해서 개발을 진행한다.프레임워크가 마치  도깨비 방망이 처럼 모든 것을 처리한다고 믿지만 정작 그렇게 쉽지만은 않은게 현실이다.
특히 우리가 사용중인 JAVA계열의 많은 프레임워크(대형SI사 및 전자정부프레임워크)들은 거의 Spring, Strutz, ibatis, Velocity 등을 엮어 패키징하고 거기에 벤더들이 개발한 UI관련 툴(X-internet)과 시스템관리 기능 정도를 묶어 놓은 것이 전부인 경우가 95% 이상이다. 이는 프레임워크로서의 일부 기능을 담당할 수는 있지만 진정한 생산성을 제공하기에는 역부족이라고 생각된다.
진정한 생산성을 제공하는 프레임워크는 요구사항의 정의에서 화면 설계, 디자인 및 Component, DB설계 등에 이르는 과정이 개발자들이 사용하는 언어나 개발도구와 연계돼 분석, 설계와 개발, 구현 과정의 Gap을 최소화 할 수 있어야 하며 통합 테스트와 운영 과정이 원할하게 연계돼 향후 변경된 소스를 통해 문서 현행화 되는 기능이 제공돼야 한다.
물론 이러한 전 과정이 고객과 소통이 가능하고 확인이 가능한 기능도 제공되어야 한다. 이렇게 개발된 애플리케이션은 운영과정에서도 누구나 손쉽게 파악할 수 있으며 어려운 문서를 보아가면서 개발자에게 끌려 다니는 일은 아마도 없을 것으로 확신한다.
SAP, 오라클, Salesforce등의 패키지에 적용되어 있는 방법론과 프레임워크들이 유사하며 결국 이러한 기술들이 클라우드 서비스를 하기 위한 본질이다.
특히 애플리케이션(ERP,CRM등)을 SaaS,PaaS 형태로 제공하기 위해서는 애플리케이션 속성들이  Metadata화 하여 관리되어야 하고 표준화된 개발 프레임워크가 제공돼야 한다.
혹자들은 외산 패키지들과 우리의 차이가 넘을 수 없는 벽인 것 처럼 말하고 있지만 이는 투자의 차이이지 결코 기술의 차이가 아니라고 생각 한다.새로운 기술을 적용하고 키워 나갈 수 있는 환경이 부족하기 때문에 아직까지 국내에 글로벌 SW가 존재하지 않는 것이라고 생각된다.
이러한 열악한 환경에서 프레임워크와 솔루션에 진정으로 투자를 하는 기업은 흔치 않다. 몇몇 중소기업들이 다양한 시도는 하고 있지만 영세함과 인력의 부족으로 글로벌한 회사와 다투기에는 매우 역부족인 상태이다.
프레임워크 환경으로 UB-CRM ver5.0 (SFA,VOC, CM,CSVM)을 개발하고 고객사에 적용하고 있으며 이미 공공, 제조, 금융, 유통, 서비스등  100여 개 이상의 단위 업무에 적용해 보았지만 아직 갈 길이 멀다.
이러한 기술을 대규모 SI에도 적용해서 진행하고 싶지만 PMO 입장에서는 모험이 될 수도 있다. 전혀 해보지 않은 방법으로 프로젝트를 진행하는 것에는 무리가 있을 수 있고 당장 성과를 내는 것이 아니라 누적된 지식이 더 큰 성과를 낼 수 있는 방식이므로 눈앞의 성과에 급급한 PM과 담당자들은 이를 도입하기를 꺼려하는 것을 많이 경험했다. 하지만 많은 기업이 이러한 방법을 조기에 도입해서 지식을 축적하고 있다면 차세대나 시스템 확장에 그렇게 많은 비용과 시간을 투자하지는 않았을 것이고 우리나라에도 글로벌 SI나 컨설팅회사가 지금쯤은 존재하고 있을 것이다.
우리가 만든 방법론과 프레임워크를 활용해서 개발자들이 축적해온 기술과 노하우를 극대화 할 수 있는 IT세상을 꿈꾸면서 우리는 앞으로도 계속 도전해 나갈 것이다.
Global Software가 되는 그날까지.

고영률 유비원 대표이사
2006년9월-현재 유비원 대표이사 겸 기술연구소장
2000년6월-2006년7월 비아이씨엔에스 근무
1994년5월-2000년6월 삼성에스디에스 근무(삼성전관 컴퓨터사업부 입사)
1991년1월-1994년5월 제일컴퓨터 재직