2008년은 함수형 언어가 우리 개발자들의 품으로 한 걸음 더 다가오는 해가 아닐까 싶습니다. .NET에서는 이미 OCaml의 .NET 버전인 F#을 내놓고 열심히 홍보를 하고 있고 자바 진영에서도 JVM을 타겟으로 하는 함수형 언어인 Scala가 조금씩 홍보를 시작한 것 같습니다. (개발 자체는 2001년에 EPFL에서 이미 시작되었지만요.) 마침 올해 초에 IBM developerWorks에 The busy Java developer's guide to Scala: Functional programming for the object oriented 라는 튜토리얼 형태의 글이 올라오기도 했습니다.

구글에서는 이미 2006년에 Scala를 만든 Martin Odersky를 초청해서 The Scala Experiment: Better Language Support for Component Systems? (PDF)라는 제목으로 Scala에 대한 강연을 하기도 했습니다. 참고로 Martin Odersky는 자바 진영에서 굉장히 유명한 사람인데 자바의 제네릭스를 추가하기 위한 Pizza, GJ 프로젝트에 참여했고 이 프로젝트는 결국 자바 5의 제네릭스가 되었습니다. 스스로가 함수 언어에 대한 이론을 기반으로 자바에 실용적인 활용 방안을 모색해 온 사람이라 Scala에도 이런 철학이 그대로 녹아들어가 있습니다.

Scala의 기본적인 아이디어는 함수형 언어의 특징을 객체지향 언어인 자바에 잘 집어넣자는 것입니다. 대신 Pizza나 GJ 처럼 자바 언어를 어느 정도 개선하는 스타일이 아니라 아주 새로운 언어를 만들되 타겟만 JVM으로 하는 방식을 취했습니다. Scala의 초기 논문을 보면 언어의 출발은 Java의 복잡한 컴포넌트를 쉽게 조합할 수 있는 도구에 있었습니다. 컴포넌트 재사용의 편의는 고차함수나 Algebraic Data Type 등 함수 언어 아이디어를 OO와 접목하는 걸로 해결하려고 했고요.

코드는 대충 아래와 같이 생겼습니다. 정작 타이핑을 하는 언어임에도 불구하고 타입 추론의 큰 도움으로 마치 동적인 스크립트 언어 같은 느낌을 줍니다. 실제로 같은 일을 하는 자바 코드에 비해 1/2, 1/3 정도로 코드량이 주는 것을 확인하실 수 있습니다.

object Timer
{
  def periodicCall(seconds: Int, callback: () => Unit): Unit =
  {
    while (true)
    {
      callback()
      Thread.sleep(seconds * 1000)
    }
  }

  def main(args: Array[String]): Unit =
  {
    periodicCall(1, () => 
      Console.println("Time flies... oh, you get the idea."))
  }
}

 

개인적으로 JVM을 타겟으로 하는 프로젝트를 할 일이 생기면 과감히 Scala를 써볼 생각도 있습니다. Scala에 대한 구체적인 소개는 다음 기회에 자세히 다뤄보려고 합니다. 미리 궁금하신 분은 Scala 홈페이지를 방문해주세요.

까멜레오 프로젝트에 대해서 자주 듣는 질문 중에 하나는 왜 파이썬을 사용했냐는 것입니다. Django 같은프레임워크를 이용한 웹프로그래밍도 아니고 퇴근을 일찍하기 위한 잡무 스크립트를 작성하는 것도 아닌 데스크톱 어플리케이션에 파이썬을 메인 언어로 사용했다는 이야기를 들으면 많은 분들이 어리둥절해 하시기 때문입니다.

파이썬을 사용해서 얻는 가장 큰 장점은 C 언어 바인딩이 편리하다는 사실입니다. 파이썬을 메인 언어로 선택한 이유는 수 십 개의 오픈소스 프로젝트를 가져다가 접목하는 글루(glue) 언어로 파이썬이 장점을 가진다고 생각했기 때문입니다. 특히 리눅스 GNOME 진영의 프로젝트는 대부분 파이썬 바인딩을 제공하고 있습니다. GNOME 프로젝트 자체도 코어는 C/C++을 이용하고 UI와 스크립팅 이슈는 대게 파이썬으로 처리하는 경향이 강합니다.

특히 Glib 라이브러리를 사용하는 (정확히는 GObject) 프로젝트들은 codegen을 이용해 C 헤더 파일에서 파이썬 바인딩을 자동으로 생성해 낼 수 있습니다. 물론, 필요에 따라 일부 함수들을 오버라이드해야 하긴 하지만 언어 바인딩을 자동으로 생성할 수 있다는 장점은 파이썬을 선택한 가장 큰 이유였습니다. IBM DW에 보시면 Wrap GObjects in Python이라는 글이 C 코드에서 파이썬 바인딩을 만들어내는 방법을 잘 보여주고 있습니다.

또한 파이썬 표준 라이브러리에 포함되어 있는 ctypes도 굉장히 유용하게 사용됩니다. 특히 C로 이미 작성된 공유 라이브러리(DLL)를 불러 쓸 때 C 코드를 전혀 작성할 필요 없이 외부 함수를 불러 쓸 수 있다는 것은 파이썬의 큰 장점입니다. pyglet 같은 프로젝트는 ctypes만을 이용해 운영체제의 윈도 시스템과 OpenGL 바인딩을 모두 구현해놨습니다.

파이썬은 이 외에도 C와 파이썬을 혼용할 수 있게 해주는 수많은 외부 함수 인터페이스가 존재합니다. 하지만 과학적 계산 등의 코드가 거의 없는 까멜레오 프로젝트에서는 이런 식의 조합은 거의 필요가 없었습니다. 파이썬 코드도 사실상 내부적으로 C 코드를 불러 쓰는 경우가 대부분이었기 때문입니다.

이렇게만 쓰면 파이썬을 사용한 것이 굉장히 좋은 선택이었던 것처럼 보이는데, 파이썬을 본격적으로 사용하면서 겪은 시행 착오와 실수도 엄청 많습니다. 이 부분에 대해서는 다음 기회에 따로 한 번 정리해 보려고 합니다.

얼마 전에 과학소설(SF) 계의 큰 별이자 미래학자이기도 한 아서 클라크경(Sir Athur Charles Clarke) 운명하셨다고 합니다. SF 소설을 즐겨보는 편은 아니지만 이 분의 명성은 익히 알고 있었는데 안타까운 소식입니다.

클라크 경은 예측에 대한 세 가지 법칙으로 유명한데요. 다음과 같습니다.









저는 3번 법칙이 제일 와닿습니다. 제가 자동차, 휴대폰, TV 등을 들고 100년 전으로만 돌아가도 저는 종교 단체 지도자가 되고도 남을 엄청난 기적을 보여줄 수 있을테니깐요.

요즘은 각종 방법론(개발 방법론, 학습 방법론) 등에도 비슷한 생각을 가지게 되었습니다. 한 때 소프트웨어 공학에서 말하는 전통적인 각종 방법론과 프로세스 개선 방법에 대해서도 공부해보고, 나중에는 애자일 방법론과 XP 등에 대한 각종 도서들을 열심히 읽고 느끼는 바도 많았습니다. 하지만 시간이 지날수록 내가 처한 현실은 별로 변하는 것 같지 않은데 방법론은 점점 고도화되고 어려워진다는 느낌을 피할 수가 없더군요.

클라크 경의 3번 법칙을 변형해서 방법론에 적용해보면 충분히 발전한 방법론자는 도인과 구분할 수 없다라는 결론이 나옵니다. 가끔 방법론의 자기 개선(자기 발전적인) 학습에 너무 치우친 나머지 일반 개발자들과 괴리감을 보이고 방법론을 강의하는 건지 인생 철학을 강의하는 건지 심리학을 강의하는 건지 전혀 모르겠습니다. 듣고 보면 좋은 말인 것 같은데 뭘 해야할지 모른다고 해야할까요.