'COBOL'에 해당되는 글 1건

  1. 2013.01.21 전문가 기고: 통신 소프트웨어의 흐름 - 김자명 부장


뉴스레터 4호의 기고문을 맡아 주신 분은 연구개발본부의 김자명 부장님입니다. 이동통신 시장에서 15년 이상을 근무하시며 보아온 통신 소프트웨어의 개발 역사와 미래를 인사이트를 가지고 풀어주셨습니다.



통신 소프트웨어의 흐름



연구개발본부 개발1부 김자명 부장









제가 처음 프로그램을 직접 짜본 것은 대학에 다닐 때였습니다.  당시 PC에서 볼랜드(Borland) C나 터보 (Turbo) C로 주로 개발했었는데, 개발할 때의 주의할 점은 사용할 수 있는 메모리가 한정적이라는 것입니다.  그래서 아주 큰 프로그램을 만들지는 못하였으며, 그럴 경우에는 학교 전산실의 유닉스 시스템에서 개발을 해야 했습니다.  그 당시 개발 환경은 지금과는 비교할 수 없을 정도로 열악했었는데 속도는 느리고, 메모리는 최소로 사용해야 해서, 프로그램을 만들다가 디버깅을 하게 되면 상당히 오래 걸리는 게 다반사였습니다. 



실제로 대학원 다니던 선배는 졸업 논문을 쓰기 위해 새로운 알고리즘을 만들었는데, 이 알고리즘이 기존보다 좋은 결과를 보여준다는 걸 증명하기 위해 시뮬레이션을 하였습니다. 보통 논문을 쓸려면 최소 50회 이상의 반복 실험에서 기존보다 좋은 결과를 보인 것이 몇 %인지를 기록해야 하는데 실험을 많이 하면 많이 할수록 좋은 논문으로 인정받을 수 있었습니다. 근데 하나의 시뮬레이션을 하는데 보통 2 일 동안 프로그램을 돌려야 하는 게 문제였습니다. 학과 전산실에 가장 빠른 PC 2, 3 대에 시뮬레이션을 돌리고 키보드에 절대 건드리지 못하게 쪽지를 적어서 붙여놔도 일부 학생들이 당시 유행하던 게임을 하기 위해 돌고 있던 시뮬레이션을 종료하는 문제가 태반으로 발생했었습니다.  학과 전산실 문을 잠궈 보기도 하고, 지켜보기도 했지만 100% 막을 수는 없어서 결국 그 선배는 다른 사람보다 6개월 늦게 졸업을 했었다고 합니다.


저는 그 선배의 알고리즘을 직접 구현하여 그 결과를 발표하는 세미나를 준비했었는데 제가 만들어서 할 때에도 당시 펜티엄 초기 모델에서 한번 시뮬레이션 하는데 2~3시간 정도 걸렸습니다.  CPU 속도의 증가로 시뮬레이션 시간은 많이 줄었지만 여전히 빨리 끝나지는 않았습니다. 문제는 디버깅이었는데 프로그램이 제대로 만들어 졌는지 검증을 하기 위해 돌려 보면 꼭 종료할 때 쯤에 죽는 것이었습니다. 그래서 최종 결과를 기록하지 못해서 몇 날 몇 일을 디버깅했던 기억이 있네요. 결국 제 날짜에 세미나를 하지 못하고 연기시켜야 했지만 하나 배운 것은 있습니다. 프로그램은 코딩하는 것도 중요하지만 디버깅이 더 중요하다는 것입니다.


또 비슷한 예로 패턴 인식하는 과제가 있었는데, 사진 속에서 드라이버나 망치를 찾는 프로그램이었습니다. 생각 같아서는 1초도 안되어서 찾을 수 있을 것 같았지만, 막상 프로그램으로 만들다 보니 이것도 사진 속의 도구 4개를 전부 다 찾으려고 하니 한번 테스트하는데 5-6시간이 걸렸습니다. 그래서 빨리 찾기 위해 사진 파일에서 픽셀을 크게 움직이면 찾지를 못하고, 촘촘히 움직이면 가끔 찾기는 하지만 너무 오래 걸리는 문제가 있었습니다.  결국 제한 시간 내에 과제를 해결한 사람은 전체 30여명 중에서 2명 정도였던 걸로 기억합니다. 



지금과는 비교조차 할 수 없을 정도로 열악한 환경이었는데 사실은 그때나 지금이나 하드웨어의 발전 속도에 못지 않게 소프트웨어도 많은 발전이 있었습니다. 당시에는 여러 환경 및 상황 때문에 원하는 소프트웨어를 개발한다기 보다는 잘 동작하기 위한 소프트웨어를 개발해 왔던 때였는데, 지금은 원하는 소프트웨어를 다양한 환경에서 다양한 방법론을 이용하고 다양한 개발 플랫폼을 이용하여 만들 수가 있게 되었습니다. 


많은 객체 지향 언어와 다양한 Script 언어가 개발되었고, 소프트웨어 개발을 위한 많은 개발환경 등이 만들어지고 있으며 지금도 계속 발전하고 있습니다. 특히 통신 네트워크 소프트웨어 쪽에서는 그 특성상 아직까지 C 언어를 많이 선호하고 있으며 오래 전에 만들어진 소프트웨어가 아직까지 사용되고 있습니다. 현재 개발되고 있는 시스템들도 전혀 새로운 환경에서 새로 개발되는 것이 아니라 약 10여 전에 만들어진 소프트웨어에 기반을 두는 경우가 많습니다. 


이렇게 다른 분야보다 발전이 느린 편이지만 최근 들어서는 자바(Java)나 루아(Lua)같은 언어를 사용하는 시스템도 많아지고 점점 발전되는 속도가 빨라지고 있는데, 그러면 과연 통신 소프트웨어는 어느 방향으로 발전할까요? 



그에 대한 답은 사실 누구도 알지 못할 것입니다. 하지만 현재까지 변화된 것을 보면 앞으로의 변화를 어렴풋이 알 수는 있을 것입니다. 초창기 통신 시스템을 개발하던 시절에는 규격에 정의된 시스템을 먼저 만드는 것이 가장 중요했습니다. 국내에서는 누구도 만들어 본 적이 없기 때문에 외국 장비를 도입해야 하는 상황이었으므로, 국내 솔루션은 먼저 만들기만 하면 공급하는데 큰 문제점이 없었습니다.

 

하지만 지금은 상황이 많이 달라져서 국내에서도 통신 사업자가 원하는 솔루션을 제공할 수 있는 업체가 이전보다 많아졌습니다. 이렇게 되니 점점 경쟁은 점점 치열해지고 다른 경쟁업체보다 장점이 많아야만 경쟁에서 이길 수 있는 상황입니다. 이렇게 되다 보니 통신 소프트웨어도 이전과는 다른 방향으로 발전하고 있습니다.


그 첫 번째 변화는 “안정성”입니다. 이전에는 빨리 개발하다 보니 조금의 문제나 장애가 발생할 수 있었고, 이러한 부분은 후속 조치에 따라서 어느 정도 인정될 수도 있었습니다. 하지만, 이동 통신 서비스가 국내에서 시작된 지 약 20년 가까이 된 지금에서는 발생할 수 있는 모든 종류가 문제와 장애, 오류는 이미 한차례 이상씩 발생했었기 때문에 이를 받아 들이는 쪽에서는 발생하기 힘든 경우의 문제로 인식하기 보다는 아직 성숙하지 못한 수준의 소프트웨어를 보유하고 있다고 생각합니다. 그만큼 소프트웨어에 대한 사업자의 수준이 많이 높아 진 것입니다. 그리고 문제를 많이 일으키는 소프트웨어를 보유한 업체나 개발자는 점차 기회를 잃어 갈 것입니다. 사업자의 해당 서비스나 시스템 담당자도 자신의 평가에 악영향을 주는 것을 감수하면서 계속 일하고 싶어 하지는 않을 것이기 때문입니다.


그리고, 두 번째 변화는 “빠른 분석 및 대응”입니다. 통신망이 2G에서 3G로 진화하면서 최근에는 LTE망으로 또 음성에서 데이터 및 VoLTE로 진화를 하다 보니 그 복잡도는 이전보다 휠씬 증가했습니다. 그러다 보니 문제나 이슈가 발생하게 되면 원인 파악 및 분석에 이전보다 많은 시간이 투입될 수 밖에 없으나, 빠른 해결을 원하는 고객의 기대 수준 향상으로 어렵고 복잡한 문제를 이전보다 짧은 시간에 풀거나 해결해야 하는 상황이 되었습니다. 그래서 사업자는 자신들이 모든 걸 해결할 수 없다는 것을 알고 있기 때문에 이러한 능력을 보유한 개발업체를 더욱 선호하게 되었습니다. 그래서 서비스를 제공하는 시스템이나 장비에서 통계나 장애 및 상태 감시 기능이 점점 더 강화되고 있는 추세입니다. 


마지막으로 보이는 변화는 “빠른 개발”입니다. 이는 안정성과는 상충되는 부분으로 개발이 빨라지면 안정성이 떨어질 수 있고, 안정성이 강조되면 개발 기간이 오래 걸리는 것이 일반적인 현상이나 최근의 소프트웨어 추세는 안정성이 높은 소프트웨어를 빠른 기간 내에 개발하도록 요청하고 있습니다. 초기부터 지금까지 가장 선호하는 소프트웨어는 빠른 기간 내에 기본 기능 및 예외 처리가 잘 고려된 안정성이 높고, 높은 성능을 보여주는 가격 경쟁력이 있는 소프트웨어인데 이 기준은 지금도 크게 바뀌지는 않았습니다. 이러한 요구 및 변화의 흐름을 따르기 위해 개발업체마다 많은 노력을 하고 있는데, 보통 시스템이나 하드웨어적으로 해결할 수 있는 부분이 있고, 소프트웨어적으로 해결할 수 있는 부분이 있습니다. 하드웨어의 발전은 가장 눈에 띄는 부분으로 속도나 성능이 거의 2-3년에 두 배씩 증가하고 있으며, 소프트웨어적으로 제공되던 기능들이 하드웨어에서 제공되어 성능적인 면에서의 발전은 상상을 초월하는 경우가 많습니다. 


이런 기술의 변화 속에서 소프트웨어를 어떤 식으로 개발해야 할 것인가가 우리의 가장 큰 고민입니다. 저의 경험과 생각을 바탕으로 한 개발 방향은 아래와 같습니다.




첫째는 간단하게 개발하는 것입니다. 

요구사항이 점점 복잡해지고, 이전 히스토리까지 포함하는 기능을 많이 요구하다 보니 소프트웨어의 복잡도는 증가할 수 밖에 없습니다. 하지만, 설계는 간단하고 심플하게 하고 개발도 가장 쉬운 방법으로 개발하는 것이 좋습니다. 복잡한 요구사항에 복잡한 case까지 고려하다 보니 해당 기능을 검증하고 확인하려고 하거나 문제가 발생했을 때 원인분석을 하려면 너무 어렵고 복잡합니다. 또 주어진 요구사항에 최적화된 소프트웨어를 개발해도 사용자나 고객은 곧 바로 새로운 기능을 요구하거나 찾을 것이므로 유지보수를 고려해도 쉽게 간단하게 설계, 개발하는 것이 좋습니다. 쉽고 간단한 레고 조각 같은 기능모듈들이 모여서 예쁘고 멋진 레고 작품 같은 소프트웨어를 만드는 것입니다. 성능적인 부분은 몇 배의 성능차이가 발생하지 않는 이상 하드웨어 성능 향상으로 점점 좋아 질 것이며 보다 정밀한 요구사항들은 새로 개발하는 것이 아니고 해당 영역의 레고 조각을 보다 작은 조각으로 만들어서 해결하는 것입니다.


둘째는 항상 예외상황을 고려해야 합니다.

소프트웨어 개발을 실제 사용하거나 운용할 고객 입장에서 만드는 것이 아니라 개발자 입장에서 개발하는 경우가 가끔 있는데, 이전에는 이런 경우가 발생하면 추가 개발 요구를 해서 실제 사용자나 운용자가 사용하기 편하게 변경했습니다. 물론 지금도 마찬가지지만, 이전과 달라진 점은 이런 경우에는 해당 개발자나 업체에 대한 수준을 미리 평가해 버린다는 것입니다. 사소한 부분이지만 섬세하게 신경쓸 때 사용자는 더욱 만족해 하고 신뢰하는 것입니다. 이를 위해서는 개발자는 항상 오류 상황과 예외처리를 고민하고 반영해야 합니다.


셋째는 개발적인 부분이 아니라 관리적인 부분인데, 모든 개발 관련된 사항에 대해서 히스토리를 정리해야 합니다.

통신 소프트웨어는 공급되고 나면 이후에는 유지보수를 하게 되는데, 시간이 지나게 되면서 이전 변경사항과 문제점등을 담당자가 바뀌거나 노트북을 교체하거나 해서 이력 관리가 되지 않는 경우가 있습니다. 실제 개발 프로젝트에서 중요한 부분이 이런 이력을 잘 관리하는 것인데, 관리가 되지 않아서 비슷한 문제가 반복해서 발생하는 경우가 있습니다. 개발자들은 코딩에만 신경쓸 것이 아니고 설계와 이력 관리에도 반드시 신경을 써야 정말 개발 잘하는 개발자로 인정받을 것입니다.


이외에도 많은 점들을 고려해야 하지만 대표적으로 3가지 정도만 언급했습니다.

개개인이 생각하는 통신 소프트웨어 개발의 흐름이 위에서 언급한 것과는 다를 수 있겠지만, 기본적인 방향에서는 다 같이 공감하는 부분이라고 생각하며 모두가 인정받는 개발자가 되기 위해서 참고할 수 있었으면 좋겠습니다.

저작자 표시
신고
Posted by 유엔젤 테크니컬라이터 손대리
comments powered by Disqus

댓글을 달아 주세요

티스토리 툴바