블루엣 인터내셔널의 기술 이사로 재직중이며 개발 환경과 온라인 교육 시스템을 결합한 소프트웨어를 설계하고 있다. 소프트웨어 공학 기술이나 관련 이론을 실천하도록 만드는 것이 개발자로서의 목표이다.
지난 호에 예고했듯이 이번 호는 Haskell.NET에 대한 소개다. 아직 Haskell.NET이 소개할 만큼 완성도를 갖추지 못해 마지막 연재 주제로 제시할 수 없었다. 대신 지금까지 Haskell 연재를 통해 우리가 배워야 할 것이 무엇인지 정리하는 시간을 가져보려는 것으로 연재를 끝맺고자 한다. 독자들의 많은 양해 바란다.
Haskell과 같은 언어는 지금까지 일반 프로그래밍의 영역에서 한 걸음 떨어져 있었다. 필자는 그 이유를 크게 다음의 세 가지로 본다.
이 세가지 문제 중에서 가장 큰 장애가 되는 것은 역시 첫 번째다. 아마도 나머지 문제가 더 확실하게 개선되지 않는다면 학교와 산업현장에 이런 기술이 더 폭넓게 사용되기까지 상당히 오랜 기간이 필요할 것이다. 모르긴 해도 그 영향을 결코 무시할 수 없는 어떤 대형 소프트웨어 회사가 이런 기술을 적극적으로 상용화하려고 나서지 않는다면 빠른 시간 안에 개선되기는 힘들 것이다. 특히 한국의 경우 다른 나라에 비해 소프트웨어 기술이 시장에서 다양하게 성장하지 못하고 있는데다가, 대학 교육조차 업계와 같이 유행에 민감한 실정이어서 상황이 더 나쁘다고 할 수 있다. 게다가 우리의 성숙하지 않은소프트웨어 기술 문화의 수준으로 볼 때, 자각을 통해 스스로 개선하거나 진보하기를 기대하기는 아직 무리이고, 설사 그런 움직임이 있다고 하더라도 정규 교육과 기술 시장에 큰 영향을 주지 못할 동호회 수준을 벗어나기 힘들 것이다. 첫 번째 문제가 해결되려면 좀 더 추이를 지켜봐야 할 것이다.
두 번째 문제는 비교적 많이 해결돼가고 있다. 순수하게 언어의 프로그래밍 기법만을 다루는 연구가 다음 단계로 접어듦에 따라, 응용에 관한 연구가 전에 없이 활발해 실용성이 뛰어난 산출물도 많이 쏟아져 나오고 있다(http://www.research. avayalabs.com/user/wadler/realworld/). 데이터베이스, 멀티미디어 하드웨어 설계 등 다양한 응용 분야에 이와 같은 프로그래밍 기법을 적용한 사례를 보여주는 논문도 많고, 그 산출물의 장점과 발전 가능성도 상당히 밝다. VRML2의 표준안을 채택하던 당시에 마이크로소프트의 ActiveVRML에 사용된 FRAN(Functional Reactive Animation, http://www.research.microsoft.com/~conal/Fran/) 모델(Conal Elliot 등이 연구해 발표)이나, 마이크로프로세서를 설계하고 검증하기 위해 개발됐던 Hawk(http://www.cse.ogi.edu/PacSoft/projects/Hawk/) 등이 그 좋은 예다.
특히 Hawk는 하드웨어 설계와 검증, 시뮬레이션을 한 번의 코드 개발로 해결하고자 하는 노력으로(다른 프로그래밍 기법으로는이와 같은 접근 방식을 상상하기조차 어렵다) 장차 이 분야의 연구가 타 응용 분야에 어떤 영향을 주게 될 지 기대가 된다. 이에 더해 기존의 프로그래밍 자원(그래픽스 라이브러리, 데이터베이스 인터페이스 등)을 재구성해 연계 활용하는 연구도 많아지고 있기 때문에 조만간 그 범용성을 크게 염려하지 않아도 될 수준에 이르리라 본다.
마지막 문제는 컴퓨터의 끊임없는 성능 개선과 함께 소프트웨어 규모가 커짐에 따라 자연스럽게 해결의 실마리를 찾아가고 있다. 10여 년 전에는 상상하기도 어려웠을 만큼 무겁고 덩치 큰 소프트웨어가 개인용 컴퓨터에서도 잘 돌아갈 만큼 좋아졌다. 자바나 닷넷 등과 같은 바이트코드 방식의 소프트웨어 실행 환경을 산업 전반에서 채택하게 될 만큼 여유가 생겼기 때문에 Haskell과 같은 언어의 성능에 대해 물고 늘어질 핑계거리도 없다. 더구나 하드웨어와 소프트웨어는 성능과 특성을 고려하여 공동설계(Codesign)를 하는 것이 점차 일반화되었으며 독립된 연구 분야로 자리매김했다. 예를 들어 RISC 아키텍처와 같이 애초에 컴파일러와의 연계성을 염두에 두고 프로세서를 설계하는 차원에서부터, 그래픽스나 멀티미디어 자원의 처리 성능을 위해 특수 기능까지 제공한다. 컴퓨터 성능에 탄력성(scalability)을 갖도록 아예 하드웨어와 소프트웨어를 하나의 서비스 층으로 묶어서 추상화하는 방식을 따르는 것도 일반화돼 있다. 간단히 말해 프로그래밍 언어와 하드웨어 사이의 의미 수준의 차이가 점차 좁아지고 있기 때문에 폰 노이만 병목으로 대변할 수 있는 이 분야의‘유전병’이 근원으로부터 해결될 가능성을 보이고 있다.
이와 같은 하드웨어의 성능 개선은 소프트웨어의 규모 증가와 밀접한 관계가 있다. 지금의 소프트웨어는 초창기 컴퓨팅 시절의 간단하고 무뚝뚝한 프로그램이 아니다. 프로그래머나 고급 사용자 혼자서 관리하기 이미 불가능할 정도의 수많은 부품이 맞물려 돌아가고, 프로세서의 빠르기를 무색하게 만드는 화려한 인터페이스로 치장하고 있다. 또한 일반 사용자 프로그램도 복잡한 기능이 수 없이 많이 내장되어 있다. 그에 따라 소프트웨어의 개발 복잡도도 놀랄 만큼 증가했다. 이런 추세는 컴퓨팅 환경의 변화에 따라 앞으로 더 가속화될 것으로 예상된다. 지금보다 응용분야는 더 늘어나게 될 것이고, 좀 더 사용자 위주의 계산 환경이 갖추어질 것이며, 소프트웨어 간의 상호 연결성은 네트워크를 가로질러 강화될 것이 분명하기 때문이다.
이쯤 되면 지금의 소프트웨어 개발 방식으로는 그 복잡도를 감당하기 힘들다. 복잡한 하드웨어의 결함을 찾아내기 위해 HOL(Higher-Order Logic)과 같은 기술을 쓰는 것과 마찬가지로, 소프트웨어서도 보다 수준 높고 체계 있는 버그 검출 방법, 소프트웨어 품질 관리 기법, 생산성 향상 방법이 필요하다. 소프트웨어 부품 기술과 체계 있는 재사용 기법으로 그 구현의 생산성은 높아지고 있지만, 설계의 복잡도와 품질 검증은 훨씬 복잡해질 것이 자명하기 때문에 지금의 기술로는 역부족이다. 좀더 많은 작업이 일정한 체계에 따라 자동화되어야 한다. 그러기 위해서는 무엇보다 근본이 되는 프로그래밍에 대한 생각부터 다시 해야 하고 자연스레 바탕이 더 튼튼한 프로그래밍 기술을 사용하지 않을 수 없다는 결론을 내리게 된다. 경험이 곧바로 검증되고 빠르게 재사용 될수있는기술이없다면, 소프트웨어의 품질 개선과 개발 생산성의 진보를 설계 수준에서 기대하기 어렵기 때문이다. 즉, 소프트웨어 기술이 진보하면 할수록 이전의 덜 정리된 기술을 조금씩 걸러내고, 바탕이 더 튼튼한 기술을 받아들이는 것이 현실에 적응 하는 방법일 수도 있다.
필자가 Haskell과 같은 기술에 기대를 거는 이유가 바로 이 때문이다. 이 연재를 하게 된 이유가 Haskell 자체의 우아함에 감동을 받아 엔지니어로서의 본능(?)에 가까운 욕구를 분출하고 싶었기 때문 만은 아니다. 작은 힘이나마 다음에 다가올 기술 세상을 미리 바라보고 준비하자는 취지가 있었다. 또한 요즘 유행하는 프로그래밍 기술의 성향이나 소프트웨어 기술 문화가 너무 근시안적인 기술에 치우쳐 있다는 점을 Haskell을 빌어 말하고 싶었다.