[e테크]기존IT시스템의 재활용-코볼에서 자바 전환 순조로울까?

코볼과 자바언어간의 구조적, 개념적, 문화적 부조화로 인해 오는 2004년까지 코볼 프로그래머들을 통해 코볼의 새로운 응용 프로그램을 개발하고 이를 토대로 자바언어로 변환하는 것은 가능하지 않을 것으로 예상된다. 장년기에 있는 언어로 작성된 기존 시스템의 모듈을 새로운 프로그래밍 언어로 이전 또는 변환하려면 구조적, 개념적, 문화적 장애요소에 유의해야 한다.

　기존 코드를 재조정하면 비용을 절감하고 기능을 향상시킬 수 있을 뿐 아니라 기존 시스템을 새로운 언어나 기술로 이전, 변환 또는 연결하는 데 필요한 첫번째 조치기도 하다. 하지만 기존 코드를 성공적으로 재조정했다고 해서 코볼이나 RPG언어를 자바로 직접 변환할 수 있는 것은 아니다. 기술적 및 구조적 차이와 변환의 복잡성 등으로 인해 프로그래밍 언어를 한꺼번에 변환하는 것은 어려운 일이다. 언어의 변환을 위한 번역 및 재조정을 추진할 때는 다음 네 가지 함정을 피해야 한다.

　첫째, 구조적 부조화-언어 및 플랫폼의 구조와 디자인이 서로 다르기 때문에 기존 프로세서 중심의 시스템에서 새로운 분산형 시스템으로 변환하기가 어렵다. 단일 플랫폼의 기존 시스템에서는 응용 프로그램이 발표, 처리 및 데이터베이스 논리 속에 섞여 있다. 반면 분산환경에서는 이러한 기능이 따로 분리돼야 한다. 코볼, CICS 등 전통적인 언어들은 메인프레임에 맞게 작성돼 있으나 분산형 언어는 분산형 컴퓨팅, 플랫폼의 이식, 컴포넌트간의 상호 작용 등을 가능하게 해준다. 언어의 변환을 효율적으로 추진하려면 디자인 개념(assumption)의 번역내용과 문장구조 등을 숙지해야 한다.

　둘째, 패러다임의 부조화-자바는 객체지향 언어로 현재 널리 사용되고 있는 절차 프로그래밍 언어 및 절차 코딩에 사용되는 혼성 객체지향 언어들과 상당히 다르다. 절차와 객체지향 패러다임은 개념이 다르기 때문에 언어간의 번역을 매우 복잡하게 해준다. 분산 프로그램은 3270 시스템을 운영할 때보다 더 구체적인 기술 인프라 지식을 필요로 한다. 코볼기반 업무처리 절차에 컴포넌트 구조를 채용하면 유지관리에 도움이 되겠지만 이 경우 궁극적으로 코드를 변환할 것인지 아닌지를 고려, 판단해야 할 것이다. 언어를 변환하지 않고 별도의 데이터, 처리절차, 사용자 인터페이스 코드만 재구성해도 관리비용을 상당히 절감할 수 있다.

　기존 프로그램을 소단위로 컴포넌트화(componentization)하면 이의 연장, 변환 또는 이전이 쉬워진다.

　셋째, 문화적 부조화-아무리 노련한 코볼 프로그래머나 자바 전문가라 하더라도 상대방 기술의 세밀한 부분까지는 이해하지 못한다. 이와 같은 상대방 기술에 대한 무지로 인해 상당히 많은 프로젝트가 잘못된 방향으로 추진돼 시스템의 개발이 미완성 상태에서 끝나든가 반대로 코드가 너무 많든가 코볼을 적절하지 않은 부분에 많이 사용해 불완전한 시스템이 될 가능성이 높다. 이런 경우 디자인을 상호 교환 검토하고 교육훈련을 실시하는 것이 효과적인 변환방법이 될 것이다.

　넷째, 성숙도 부조화-코볼과 RPG 응용 프로그램은 이들 프로그래밍 언어의 장기간에 걸친 실험, 버그 제거 및 재정리작업 등을 통해 적지 않은 혜택을 입고 있다. 자바가 많은 응용 프로그램에 ‘충분히 좋은 기술’인 것이 사실이지만 RPG나 코볼 시스템보다는 덜 안정적이다. 자바는 기업 업무의 병목현상을 확인하는 데 어려움이 있고 중요한 업무처리와 친숙하지 않기 때문에 기업의 중요한 업무처리용 응용 프로그램 언어를 자바로 변환하는 데는 위험이 따른다. 한편 기업의 덜 중요한 응용 프로그램을 자바로 변환하는 것은 별 의미가 없다. 코볼과 자바를 혼합한 솔루션이 응용 프로그램을 확장하는 데 효과적인 해결책이 될 수 있을 것이다.

　

　기존 프로그램 변환의 성패는 집행보다 계획에 달려 있다. 기존 프로그램의 가치를 제대로 파악하려면 적절한 툴, 우수한 프로젝트 관리기능 및 건실한 방법론 등이 있어야 한다. 코볼을 자바로 변환하려면 다음의 단계를 거처야 한다.

　·기존 프로그램의 분석:변환이 가능한 것과 가능하지 않은 프로그램의 목록을 작성하고 변환된 코드와 남아있는 코드를 연결하는 데 필요한 인터페이스를 확인한다.

　·구문론적 번역:코볼 절차를 자바 분류방법으로 번역한다.

　·의미론적 번역:변환된 코드가 구문론적으로 완벽하다 하더라도 의미론적으로는 틀릴 수 있다. 이 단계를 거치면 입력과 출력 코드가 적절히 변환됐는지 확인할 수 있다.

　·새로운 개발:비현실적으로 변환돼 일부 응용 프로그램은 자바로 재 작성할 필요가 있을 것이다.

　·변환된 응용 프로그램과 기존 프로그램간의 연결:변환된 프로그램과 그렇지 않은 부분, 다른 응용 프로그램 및 새로운 미들웨어를 연결하는 인터페이스가 있어야 한다.

　·실험:변환된 자바 응용 프로그램이 최소한 기존 코볼 응용 프로그램과 같은 수준의 신뢰성을 가질 수 있도록 여러 단계의 실험을 실시한다.

　·최종 사용자 교육:변환된 프로그램의 새로운 인터페이스와 기능에 대한 교육을 실시한다.

　·지원 및 행정:새로운 하드웨어나 소프트웨어 플랫폼에 적합한 지원 및 행정을 실시한다.

　앞으로 5년에서 10년 사이에 자바가 코볼처럼 널리 보급될 것인가. 자바를 코볼과 비교하는 것이 부적절하다고 할지 모르나 코볼이 오늘날과 같은 지배적 위치에 서기까지 10년이 걸린 것을 보면 자바의 보급속도가 느리다고 속단할 필요는 없다. 만일 IBM의 연구개발자들이 자바를 중요하게 생각한다면 그들은 이를 지원할 것이다. IBM이 그 제품에 자바기술을 채용한다면 자바가 기업의 컴퓨팅 플랫폼으로 널리 보급될 것이다.

　

　가트너가 지난 98년말 미국 200개 IT업체의 경영인을 대상으로 조사를 실시한 결과 자바에 대한 관심이 높은 것으로 나타났다. 그러나 100% 순수 자바에 대한 관심은 낮았다. 응용 프로그램의 분산적이고 이질적인 특성, OS/390이 분산형 개발을 위한 플랫폼으로 다시 자리를 굳히고 콤포넌트기반개발(CBD:Component-Based Development)을 통한 소프트웨어 처리 개선에 새로운 초점이 맞춰진다면 자바가 기업에 많이 보급될 것이다. 그러나 코볼을 자바로 진화시키는 것이 쉬운 일은 아니다.