책임지기 싫어서 안바꾸는게 아니라 블랙박스화 된 레거시 코볼소스를 분석하기도 어렵고 인력 구하기 힘들기 때문입니다. 차세대 때 코볼소스 보면서 현업이 구술해주는 거 듣고 자바로 상당부분 전환했지만 일부는 그대로 유지했습니다. (소스 문서화도 되어있지 않고, 현업도 업무규칙을 전부 알지 못해서 섵불리 손대기 어려운거죠.
코드는 있지만 읽을 줄을 모르는 까막눈 신세로군요. => 정확히는 소스를 못읽는게 문제가 아니라 => 소스들로 부터 업무규칙을 캐내기가 힘든거죠.
레거시 시스템은 그대로인데 담당자는 여러차례 바뀐 상태라 완전한 로직이 무엇인지 어디서 참조되고 있는지를 확신하기가 힘든거구요. 이런 누구도 정확히알지 못하는 방치된 레거시는 금융보다 공공이 더 심하구요. (순환보직 등의 이유)
딱히 코볼의 문제라기 보다 레거시의 문제라고 보는게 정확하겠죠. 몇년전 들어갔던 공공 차세대는 끝도없이 얽히고 섥힌 엄청나게 긴 스토어드 프로시저들로 상당히 고생했죠. 여기도 마찬가지로 현업이 확신하는 범위내에서 최대한 캐내고 미심쩍고 분석하기 힘든건 남겨둔다는게 기본 정책이였습니다.
이게, 이미 구축해 놓은 게 많으면 추후 그 일부 요소가 버전이 올라 가도 함부로 바꾸기가 힘들더라구요. 물론 저는 개인 서버에 있는 것이긴 한데, 하물며 금융권은 더더욱 그렇겠죠.
프로그램이 하나가 독립적으로 돌아 가는 것이면 그나마 나은데, 수십개의 프로그램/자료들이 얽히다 보면 어느 부분을 바꿨을 때 언제 어디서 어떤 문제가 튀어 나올지 알기 힘들기 때문에, 그리고 그냥 잘 돌아 가고 있으면 굳이 새로운 버전으로 올릴 필요가 없죠.
저는 아직도 대부분의 코드에 파이썬 2.7.5를 쓰는데, 얼마 전부터 3. 이상으로 올려서 쓰고 있는데, 오늘 문제가 발생하더군요. 소스 코드 문제인줄 알았는데 디버깅이 잘 안 되어서 파이썬 2.7.5를 설치 후 이것으로 실행시키니까 제대로 되더군요. 아마도 파이썬 core library 중 하나가 문제였던 것 같습니다. 소켓 열어서 데이터 보내는 함수였는데... 대부분의 개인 서버도 여전히 CentOS 6.6이나 6.7 이구여, CentOS7.0 이 나온지 이미 오래 되었지만.
한 프로그램이 독립적으로 그것만 돌아 갈 수 있는 환경이라면 버전 맞춰서 수정하기 그나마 나은데, 여러 프로그램들이 얽히고 섥혀 있을 땐 그게 매우 힘들죠. 얼마 전엔 Visual C++ 6.0 으로 된 프로그램을 Visual Studio 2013 버전으로 옮겼는데, 뭐, 어렵지 않았습니다. 하위 호환 안 되는 문구들 몇 개 수정해 주고 나니 제대로 되더군요. 하지만 서버의 수많은 C++/python 코드들은 서로 얽혀 있는게 많다보니 여전히 python 2.7.5, C++98을 쓰고 있죠.
블랙박스화 되어 있는 부분을 분석하기 어려운 것은 아마도 두 번째 이유쯤이지 않을까, 합니다. 어차피 input/output 만 알면 그 안쪽을 새로 짜면 되거든요. 더 문제는 수많은 것들이 얽혀 있을 때 한 부분을 수정할 경우 혹은 library나 언어의 버전을 올릴 경우 어디서 문제가 발생할지 알 수 없다는 것이죠. 작은 규모여도 언어나 library, OS 버전 바꿀 때 멀쩡하던 코드가 안 되는 경우가 심심찮게 발생하는지라.
왜 아직도 코볼을 쓰는가. 이것은 코볼 엔지니어가 없기 때문이 아닙니다. 언어를 배우는 것은 그리 어려운 일이 아니고, 특히 옛날 언어들은 스펙 자체가 복잡하지 않습니다. 그런데 왜 안 바꾸는가? 저 옛날 코드들은 라이브러리화 되었기 때문입니다. 쉽게 말해서 건드릴 필요가 없는 것이지요. API 때문에 볼 필요는 있지만 바꿀 필요는 없는 코드들입니다. 아, 물론 금융이 아니라면 이런 코드들을 두고 봤을 리가 없습니다. 엔지니어들은 리펙토링을 좋아하니까요. 리펙토링의 기본은 테스트입니다. 헌데, 언어가 바뀌는 테스트 코드를 짜는 것은 그리 쉬운 일이 아닙니다. 같은 언어에서의 TC도 힘든 판국에, 코볼에서 c, 아니면 java 이건 정말 어렵죠.
글쓰기