파이썬에서 모듈을 임포트할 때는 현재 패키지의 위치에 따라 상대적으로 모듈을 임포트합니다.

예를 들어 glux.draw.pixmap 모듈에서 import cairo하면 glux.draw.cairo, glux.cairo, cario 순으로 임포트를 시도합니다. 만약 glux.draw.cairo라는 모듈이 우연히 존재했다면 원래 의도했던 cairo 모듈을 임포트하는 게 쉽지 않은 일이 됩니다. sys.modules를 통해서 직접 모듈을 찾아오거나, glux.draw.cairo를 glux.draw.gluxcairo 같은 이름으로 변경해야 합니다. 그래서 파이썬 개발자들은 보통 패키지 내부 모듈이라도 표준 라이브러리와 겹치는 이름을 사용하길 꺼려합니다.

다행히 파이썬 2.5부터는 PEP328에 정의된 from __future__ import absolute_import를 사용하면 절대 임포트(absolute import)를 기본으로 만들 수 있습니다. 절대 임포트를 사용하면 위와 같은 상황에서 glux.draw.cairo가 아닌 cairo 모듈을 임포트할 수 있습니다. 이후에 나올 파이썬(파이썬 3000 포함)은 절대 임포트가 기본이 되고 import .cairo와 같은 형태로 점을 찍어서 상대 임포트를 한다고 하는군요.

까멜레오 개발하면서 상대 임포트에 따른 의도치 않은 모듈 임포트를 겪은지라 포스트를 남겨봤습니다.

파이썬 마을 입추 기념 번개

Posted 2007. 8. 7. 21:33
파이썬 마음 입추 기념 번개를 신청했습니다. 이런 저런 모임에 나가보려고 노력은 하지만 항상 뒷북(마감 끝나고 나서 신청하기)만 치다가 이번에는 대략 순위권에 들었습니다. 파이썬을 중심으로 벌써 몇 개월째 까멜레오 프로젝트를 진행하고 있는데, 정작 파이썬 커뮤니티에는 한 번도 못 나가봐서 아쉬웠는데, 이번 기회에 회포를 풀겠군요. 파이썬 전문가분들을 뵙고 그 동안 궁금했던 걸 물어봐야겠군요. 참석 후 소식 전하겠습니다.

Using Haskell from Python with ctypes

Posted 2007. 8. 7. 03:01
Recently, I am trying to make it possible to write Chameleo plugins in Haskell. Chameleo is wirtten mostly in Python and there is no direct method to call Haskell functions in Python. However, Python is the most powerful glue language in the world(Okay, maybe next to Perl), it is not hard to use both Haskell and Python at the same time within an application. PythonVsHaskell shows an example which compiles the Haskell code with ghc and generates a dll file. Python ctypes can call these functions in the DLL as if they are normal C functions.

MissingPy seems to be another option for calling Python code from Haskell (but not calling Haskell code from Python). The recent version is 0.8.9, but it seems to be still in beta quality.

마소 인터뷰

Posted 2007. 8. 4. 05:33
IBM dW에 이어 8월 마이크로소프트웨어에도 "DEVELOPER STORY│노매드커넥션 서광열"이라는 제목으로 인터뷰가 실렸습니다. 마소에서 보내준 책이 아직 도착하지 않은 관계로 저도 내용을 확인해 보지 못하고 있습니다 ㅠ.ㅠ

마소에 처음 글을 실은 게 2005년 4월이니 벌써 2년이 넘게 지났네요. 한 동안은 한 달에 기사를 두 개씩 올리느라 무척 힘들었던 기억이 생생합니다. 얼마 전 후배가 사내 세미나 이야기를 꺼내면서 그간 마소에 기고한 글 제목을 좀 보내달라고 해서, 저도 처음으로 그간 썼던 글들의 제목을 쭉 적어봤습니다.

2007년 09월 파이썬 메타클래스 프로그래밍(작성중)
2007월 08월 파이썬 언어 확장하기
2007월 07월 시맨틱 웹과 RDF
2007년 06월 외부 함수 인터페이스
2007년 05월 XUL 프로그래밍
2007년 04월 자바스크립트의 재해석
2007년 03월 병렬 프로그래밍 (멀티쓰레드 포함)
2007년 01월 포팅 레이어
2006년 12월 1) 안전한 자바 프로그래밍은 꿈인가? 2) 코드 난독화(Code Obfuscation)
2006년 11월 1) 계약에 의한 디자인(DbC) 2) 동적 타이핑에 대한 오해
2006년 10월 1) 자바 플랫폼의 동적 타입 언어 지원, JSR292 2) 자바 메모리 모델
2006년 09월 1) C/C++ volatile 키워드 2) 가비지 콜렉션
2006년 08월 1) 디버거의 동작 원리 2) 자바 동기화(Syncronization)와 최적화
2006년 07월 1) 자바 컴파일러 들여다보기 2) 싸이클론(Cyclone)
2006년 06월 코드 커버리지 도구
2006년 04월 1) 프로그램 분석 도구를 이용하자 2) 휴메인 API vs 미니멀리즘 API
2006년 03월 코드의 재발견  프로그래밍 언어와 통합개발환경
2006년 02월 코드의 재발견  네임스페이스, 모듈, 패키지
2006년 01월 코드의 재발견  객체지향 개발의 논쟁거리, 클래스와 인터페이스
2005년 12월 코드의 재발견  제어문에 대한 색다른 이해
2005년 11월 코드의 재발견 디자인 패턴과 프로그래밍 언어
2005년 10월 코드의 재발견
타입과 타입 시스템 논쟁
2005년 09월 코드의 재발견 예외처리
2005년 05월
프로그래밍 언어를 선택하는 다섯 가지 기준
2005년 04월 프로그래밍 언어론을 배워야 하는 이유

프로그래밍 언어 이야기를 자주 하긴 했지만, 뭔가 일관성이 없다는 느낌이 들기도 하고, 2005년 초기에 쓴 글들은 지금 보면 조금 부끄럽더군요. 그래도 마소 덕분에 삼성 소프트웨어 멤머쉽 강사로 자바VM에 대해 이야기할 기회도 있었고, 마소가 이래저래 많은 인연을 만들어 주고 있습니다.

바쁘다는 핑계로 항상 마감 직전에야 원고를 보내고 있는데, 조금 더 일찍 쓰고 검토하고 고민하는 노력을 보여야겠습니다.

IBM dW 인터뷰

Posted 2007. 7. 28. 04:25
바빠서 소식 전하는 걸 잊고 있었는데 7월 중에 IBM dW와 인터뷰한 내용이 dw 인터뷰란에 올라왔습니다. 원래는 릴레이 형식으로 앞선 개발자가 다음 인터뷰할 대상을 지목하는 방식이었는데, 이 방식으로 가니깐 너무 같은 분야 혹은 그룹에서만 인터뷰가 돌고 있어서 그 방식을 버린 첫 번째 인터뷰 대상이 저였습니다. (결국 추천 받아서 인터뷰한 게 아니라는 뜻? ^^....)

워낙 두서 없이 인터뷰한 지라 무슨 얘기를 한지도 몰랐는데 다시 보니깐 조금 부끄럽군요. 다른 분들 인터뷰 보면 어느 분야 전문가라는 자부심이 있던데 저는 그냥 이것저것 잡다하게 공부하고 있는 것처럼 보이는 걸 보니 조금 부끄럽습니다. 어느 한 분야든 골라 잡아서 조금 더 깊이 공부를 해야겠다는 생각을 깊이 하고 있습니다. 그리고 제가 함수형 언어의 전문가도 아닌데, 함수형 언어 관련된 얘기가 많이 나온 것 같습니다. 이 부분은 그냥 저렇게 생각하는 사람도 있구나하고 봐주시길 바랍니다.

파이썬 데코레이터

Posted 2007. 7. 28. 03:56
오래간 만에 포스팅입니다. 요즘 3-4시간 밖에 못자는 야근을 거듭하느라 블로깅 할 여유가 전혀 없었습니다. 근데 또 한동안 글을 안 쓰니깐 손이 근질근질해서 이제는 짧은 내용이라도 하루에 1-2개 정도는 반드시 남겨야 겠다는 다짐을 해봅니다. 민감한 문제는 안 건드리고 주로 가벼운 프로그래밍 얘기만 하는 걸로요.

요즘 파이썬으로 코딩하는 일이 많아지면서, 파이썬 언어를 조금 더 진지하게 보고 있습니다. 관련해서 마소 8월호에 파이썬 데코레이터(decorator)를 이용한 파이썬 언어 확장을 주제로 글을 쓰기도 했습니다. 조금 있으면 나올테니깐 관심 있으신 분들은 서점에서 잠깐 보시고요. 까멜레오 프로젝트에도 파이썬 데코레이터를 자바의 어노테이션(annotation)처럼 활용하고 있습니다.


예를 들어서 어떤 함수를 수정해야 겠다고 표시해 놓을 때 다음과 같은 @fixme 데코레이터를 사용합니다.

   @fixme("""Take 'border-width' property into account.""")
    def __init__(self):
        ...


코드를 작성하다가 머리가 아파서 아직 구현을 안 한 경우 나중에 구현을 다 한 줄 알고 착각하는 걸 방지하기 위해 다음과 같이 @notimplemented 데코레이터를 붙여놓습니다.

    @notimplemented
    def reorder_child(self, child, position):
        ...


코드를 짜기는 짰는데, 이거 구현이 엉망이라 잠시 해당 메서드를 부르더라도 아무 일도 하지 않게 만드려면 @nop만 붙여주면 됩니다.


    @nop
    def do_many_things(self):
        ...


조금 복잡한 어노테이션으로는 C#의 new와 override 변경자(modifier)를 파이썬으로 데코레이터로 구현해 쓰고 있습니다. @new는 상위 클래스의 메소드를 오버라이드하지 않는 새로운 메소드를 정의함을 의미하고, @override는 반대로 반드시 상위 메소드를 오버라이드한다는 의도를 드러냅니다.


데코레이터가 좋은 점은 코드를 봤을 때 가독성을 높여주는 효과도 있지만, 실제로 코드 수행 시에 여러 가지 일을 해줄 수 있다는 점에 있습니다. 예를 들어 @fixme(comment)는 함수가 호출될 때 콘솔에 comment 내용을 WARNING으로 출력해줘서 항상 이 함수를 고쳐야하겠구나라는 경각심을 가질 수 있게 해줍니다. 반대로 @notimplemented를 붙여놓고는 다 구현한 줄 알고 안심한 개발자에게는 해당 메서드가 불리자 말자 구현 안했다고 에러 메시지를 낸 후 배째고 수행을 중지합니다. @nop은 함수 바디를 무시하고 아무 것도 안 하고 리턴하도록 바꿔버리고요.

@new와 @override는 파이썬의 동적인 특징을 최대한 활용해 메서드가 불리는 순간에 self의 클래스를 구한 후에 클래스의 슈퍼클래스들을 타고 올라가서 같은 이름의 메서드가 있는지를 찾아냅니다. 이렇게 찾아낸 정보로 만약 @new인데 상위 클래스에 같은 이름의 메서드가 있거나 @override인데 상위 클래스에 해당 메서드가 없으면 에러를 출력해 주는 것이죠.

별 것 아닌 확장이지만, 컴파일 언어와 달리 조금만 방심하면 버그가 있어도 모른 채 넘어가는 파이썬 코딩과 디버깅에는 많은 도움이 됩니다. 다음은 @new와 @override의 소스 코드입니다. 버그가 있을지도 모르니 유심히 살펴보시고 더 좋은 아이디어 있으면 환영합니다.


class NoOverrideMethodFoundError(Exception):
    """Exception class for override decorator."""

    def __init__(self, message):
        self.message = message

    def __str__(self):
        return repr(self.message)

def override(func):
    """If there is no suitable method found to override,
    throw an exception."""

    def new_func(self, *args):
        try:
            getattr(new_func, "__override_checked__")
            new_func.__override_checked__ = True
        except:
            method = None
            for base in self.__class__.__bases__:
                try:
                    method = getattr(base, func.__name__)
                    break
                except AttributeError:
                    pass

            if method == None:
                raise NoOverrideMethodFoundError, \
                        "%s is not found to in %s' base classes." \
                        % (func.__name__, self.__class__.__name__)

        return func(self, *args)

    return new_func

#------------------------------------------------------------------------------
# @new
#------------------------------------------------------------------------------

class AccidentalOverrideError(Exception):
    """Exception class for new decorator."""

    def __init__(self, message):
        self.message = message

    def __str__(self):
        return repr(self.message)

def new(func):
    """Prevent accidental method overriding.

    When you use @new decorator, your intention is to declare a
    new method which does not accidentally override the base method.
    """

    def new_func(self, *args):
        try:
            getattr(new_func, "__new_checked__")
            new_func.__new_checked__ = True
        except:
            for base in self.__class__.__bases__:
                try:
                    method = getattr(base, func.__name__)
                    raise AccidentalOverrideError, \
                    "%s.%s accidentally overrided the method %s.%s." \
                        % (self.__class__.__name__, func.__name__, \
                        base.__name__, func.__name__)
                except AttributeError:
                    pass

        return func(self, *args)

    return new_func

상상한 것을 그대로 웹에 구현하는 시대을 보면서 드는 생각이 하나 있습니다. 기존 기술로 작성이 어려웠던 유려한 웹어플리케이션을 실버라이트를 이용해 쉽고 간단하게 만들 수 있다는 사실은 일단 인정하고 시작합시다. 하지만, 그렇다고 해도 실버라이트를 기반으로 장사를 하려고 하면 한 가지 문제가 남아 있습니다. 바로 기술 진입 장벽과 관련된 문제입니다.

누구나 손쉽게 유려한 웹어플리케이션(RIA)를 작성할 수 있다는 말은, 바꿔 말해서 웹어플리케이션의 가치는 더욱 떨어지고, 결국 큰 부가가치를 창출하지 못하는 시장이 된다는 의미이기도 합니다. 반대로 말해, 고만고만한 업체와 기술적인 차별화를 하려면, 실버라이트가 기본으로 제공하는 기술 이상의 무엇인가를 확보해야만 하는 것이죠.

제 주변에도 실버라이트로 비디오 플레이어를 만드는 회사가 있는데, 대학생 알바를 고용해서 한 2달 정도면 쓸만한 웹플레이어를 뚝딱 만들어내는 것 같더군요. 바꿔 말해 실버라이트를 비롯한 RIA 플랫폼을 이 정도 수준에서만 이용한다고 하면, 결코 고급 기술로 볼 수가 없는 것이죠.

AJAX를 한계까지 지어짜낸 구글처럼 RIA의 경우도 RIA 플랫폼의 성능을 극한으로 끌어내는 기술을 가진 업체가 결국은 경쟁 우위를 확보할 가능성이 큽니다. 실버라이트는 아직 초창기라 데모 수준의 시연이 대부분이긴 한데, 이 위에서도 어떤 종류의 기술을 확보한 회사가 주도권을 쥐게 될지 궁금하군요.


까멜레오 프로젝트 블로깅 정책

Posted 2007. 6. 26. 03:12
지난 14일 제가 진행 중인 까멜레오 프로젝트에 대한 간략한 설명을 드린지 벌써 2주가 지났네요. 그간 여러 작업이 이루어졌음에도 불구하고, 회사 내부에서 까멜레오 프로젝트에 대한 블로깅 정책이 정해지지 않은 터라 관련 내용을 포스팅하기가 조심스러운 상황에 있었습니다.

오늘 회사에서 회의를 통해 까멜레오에 대한 블로깅 정책을 확정지었습니다. 까멜레오 플랫폼과 플레이어 모두 릴리즈와 동시에 오픈소스화를 생각하고 있는 프로젝트이기 때문에 관련된 기술 이슈에 대해서도 최대한 자유롭게 블로깅을 허용하는 쪽으로 결론을 내렸습니다.

그간 비디오 데이터 저장 기술과 관련된 조사 및 디자인 작업을 하느라, 플랫폼과 플레이어 쪽 작업이 약간 지연되긴 했지만, 앞으로 적극적인 블로깅을 통해 많은 분들의 의견을 들으려고 합니다. 꼭 까멜레오에 대한 내용 뿐만 아니라, 코덱에 대한 고민, 플랫폼에 대한 고민, 플레이어의 기능 및 UI에 대한 고민 등을 함께 공유해서 많은 분들이 좋아하고, 사용하기 편한 소프트웨어를 만드는 데 큰 목적이 있습니다.

내일부터는 자유롭게 까멜레오 프로젝트에 대한 썰을 풀어볼까 합니다. 그동안 입이 근질근질해서 고생했거든요^.^…

ACM 문제 풀지마라

Posted 2007. 6. 19. 02:31
ACM-ICPC(International Collegiate Programming Contest)는 전세계 대학생들이 모여서 프로그래밍 실력을 겨루는 대회로 우리나라에서도 많은 분들이 참여해서 좋은 성적을 거두고 있습니다. 대회는 경쟁 방식으로 짧은 시간 안에 많은 문제를 풀면 됩니다.

문제가 깔끔하고 정답이 딱 떨어지기 때문에 평가하기가 좋은 관계로 많은 대학에서 학부 1, 2학년 프로그래밍 언어 실습 문제로 ACM 문제를 활용하고 있습니다. 제 경험으로도 1학년 때 C 언어 수업, 2학년 때 객체지향언어(C++) 수업 프로젝트 일부가 ACM 문제로 나왔습니다.

ACM 문제는 주로 알고리즘 위주의 문제로 빠른 두뇌 회전력과 사고력을 요구하기 때문에 사고력을 향상시키는 데 많은 도움이 됩니다. 하지만 문제 풀이가 어느 정도 숙달되고 나면 그 뒤로는 사실상 눈높이 수학 식의 문제 풀이 연습 밖에 되질 못합니다. 딱 떨어지는 정답을 만들기 위해 단순화시킨 요구사항과 언제나 정답이 있다는 가정 때문에 깊은 사고력에는 오히려 방해가 되는 것이죠.

그래서 일부 교수님들은 대학교 3-4학 넘어가면 ACM 문제 풀지 말라고 충고하시곤 하셨습니다. 알고리즘 위주의 ACM 문제 풀이는 프로그래밍 연습이 필요한 1,2학년 때는 많은 도움이 되지만 보다 깊이 있는 이론과 복잡한 현실 문제를 다뤄야 하는 고학년에게는 오히려 사고를 단순화시킬 수 있다는 것이죠.

사실 ACM 문제는 문제별로 난이도 차이는 있지만, 한 문제만 놓고 살펴보면 조금 똑똑한 학부 1-2학년에게 시간만 충분히 주면 누구나 풀 수 있는 쉬운 문제에 지나지 않습니다. 물론 짧은 시간 안에 척척 문제를 풀어내는 것은 아무나 할 수 있는 일은 아니지만 ACM 문제 풀이에만 익숙해진다는 것은 복잡한 덧셀 뺄셈을 빨리하는 연습을 한 초등학생과 다를 바가 없다는 것이죠.

사실 실제 소프트웨어 작성에서 분초를 다투는 알고리즘 작성 능력은 별로 중요하지 않습니다. 시간이 조금 걸리더라도 깊이 있게 사고하고, 유연하고 견고한 디자인을 하는 능력이 더 중요하죠. 칠판에 문제 써놓고 5분 안에 면접관 안에서 알고리즘 못 만들어냈다고 떨어뜨리는 압박 면접 회사는 정작 중요한 인재를 놓치고 있는지도 모릅니다.

소프트웨어 작성에서 결국 중요한 것은 명세(Specification)과 디자인(Design) 능력입니다. 명세와 디자인을 끝내고 함수 정의를 만들어주면 누구나 비슷한 결과물을 산출해 냅니다. 실제로 회사에서 방학 때 인턴을 시켜보면 명세와 디자인을 다 주고 코드를 짜오라고 했을 경우와 어떤 프로그램이 필요하다고 말만 해줬을 경우 그 결과의 차이는 확연합니다.

정리하면, ACM 문제 자꾸 풀면 득보단 해가 됩니다. 물론 타고난 재능으로 ACM 문제를 잘 푸는 것은 좋은 재능이지만, ACM 문제 풀이 속도가 좋은 개발자임을 증명하는 것은 아닙니다.


--

며칠 안 들어온 사이에 리플이 너무 많이 달려서 일일이 답변해 드리지는 못하고 여기 간단히 의견을 남깁니다. 이 글은 ACM을 세계 대회 수준으로 진지하게 준비하고 알고리즘과 데이터 구조의 깊이를 추구하시는 분들을 비하하기 위해 쓴 글이 아닙니다. (제가 어찌 감히 그럴리가 있겠습니까.)

다만 어떤 종류의 시험이든 평가 방법의 한계상 측정하지 못하는 다른 능력들이 많이 있다는 사실을 말하고 싶은 거였죠. 토익이나 토플 만점이 영어를 잘한다는 척도가 되지만, 그렇다고 토익이나 토플 공부만 해서는 영어를 잘할 수 없는 것과 같은 논리를 편 것이죠. 프로그래밍 대회의 경우 ACM을 구체적인 예로 들었지만, 꼭 ACM 뿐만 아니라 어떤 종류의 시험이든 마찬가지고요.

단지 프로그래밍을 잘하기 위해서 혹은 알고리즘이나 데이터 구조를 깊이 공부하기 위해서 무작정 ACM을 푼다는 상황은 오히려 역효과를 가져올 수도 있다는 이야기를 한 것입니다. ACM 공부하시면 알고리즘 책도 보시고, 논문도 읽어보시고, 연구도 하실텐데 그런 과정을 모두 ACM 문제 풀이로 포함하시면 ACM 문제 푸는 것도 당연히 많은 도움이 되리라 생각합니다.

너무 강한 어조로 글을 작성해서 본의보다 글이 더 나간 것 같네요. 아무쪼록 열심히 ACM-ICPC 준비하시다가 'ACM 대회에 입상도 못하고 초보 수준의 문제 몇 개만 풀어보고 함부로 이야기하는 놈'이 쓴 글을 보고 분해하신 분들은 오해 푸시길.^^;;

마소 7월 원고

Posted 2007. 6. 19. 01:49
오뉴월에 감기 증상으로 끙끙대는 가운데 7월 마소 원고를 겨우 마감했습니다. 7월에는 RDF(Resource Description Framework) 개념을 간략히 소개했습니다. 2002년 마소를 보니 미래의 웹 기술로 대대적으로 RDF를 소개했던데 아직도 미래의 기술이네요.

시맨틱웹 얘기도 조금 하기는 했는데, 될 것 같지도 않은 거창한 희망 같은 건 안 쓰고 RSS 1.0FOAF 애기를 조금 곁들여 넣었습니다.

시맨틱웹을 얘기하면 10장 분량 안에 개념을 다 풀어쓰기가 힘들 것 같아서 RDF 모델, RDF Schema, SPARQL 등으로 이야기를 한정 했는데도 RDF Triple 얘기 좀 하다보니 지면이 반이 넘어가서 뒤쪽은 조금 부실해진 느낌이 있습니다-_-...

아는 만큼 쉽게 쓸 수 있다고 하는데 이번 원고는 조금 어려운 것 같아서 죄송하네요. 시간이 조금만 더 있었어도 좀 더 고민해서 쓰는 건데 말이죠. 대신에 블로그를 통해 시간나는 대로 내용을 조금 보충해 볼까 합니다.

까멜레오 프로젝트

Posted 2007. 6. 14. 02:55
한동안 블로그가 뜸했습니다. 회사에서 나름대로 야심찬 프로젝트를 준비하느라 바빠서 블로그에 신경쓸 시간이 없었네요. 사실 블로그라는 게 열심히 할 때는 탄력 받아서 열심히 쓰는데, 한 번 게을러지기 시작하면 관성이 붙더라고요.

그동안은 개인적인 관심사만 블로그에 올렸었는데, 이번에는 간단히 제가 회사에서 하고 있는 일을 소개해 보려 합니다. 저는 현재 (주)노매드커넥션이란 회사에서 일하고 있고, 공식 직함은 CTO이고 실제로는 개발팀장의 역할을 수행하고 있습니다.

현재 주력으로 개발 중인 프로젝트는 까멜레오(Chameleo)입니다. ‘까멜레오’라는 이름은 카멜레온에서 왔고, 어원을 따졌을 때 레온이 사자라면 레오는 아기 사자를 의미합니다. 작고 귀여운 카멜레온이란 뜻이지요. 까멜레오는 미디어 플랫폼을 지향합니다.

미디어 플랫폼은 꽤나 추상적인 말이라 구체적으로 어떤 제품인지 상상하기 어려울 수도 있는데, 쉽게 말하면 미디어 플레이어나 미디어 편집기 등 동영상과 멀티미디어에 관련된 응용 프로그램을 손쉽게 제작할 수 있는 플랫폼 혹은 런타임입니다. 플래시를 이용해 웹플레이어를 손쉽게 제작할 수 있는 것과 비슷한 개념이지요.

까멜레오는 다음과 같이 세 가지의 주요 특징을 가지고 있습니다.

1) OpenGL 및 3D 기술을 차용한 UI
2) 동영상 메타데이터 DB와 검색
3) 미디어 위젯

현재 까멜레오 블로그를 보면 플랫폼을 이용해 만든 데모 프로그램을 보실 수 있는데, 일단은 말풍선 위젯이나 점수 매기기 위젯 등 간단한 기능들을 보실 수 있습니다. 최종적으로는, 위젯을 쉽게 제작하고 사용할 수 있도록 플랫폼을 완전히 오픈하는 것을 염두에 두고 있습니다.





기술적으로는 현재 90% 이상의 코드가 파이썬으로 작성되어 있고, 위젯 작성도 파이썬 기반이 될 것입니다. 다양한 오픈소스 프로젝트와 표준 기술들을 사용하고 있습니다. 다른 기술들에 대해서도 개발을 진행하면서 차츰 소개를 할 생각입니다.

현재 플랫폼의 개발은 어느 정도 진척이 많이 되었고, 더불어 까멜레오 플랫폼을 이용한 데스크탑 동영상 플레이어도 클로즈드 알파단계에서 초기 테스트를 진행 중입니다. 현재 계획으로는 6, 7월 중에 공개 가능한 베타 버전이 나오리라 예상이 됩니다. 앞으로도 관련 소식을 업데이트 하겠습니다.

까멜레오 프로젝트 페이지를 방문하시면, 초대권 신청하는 란이 있습니다. 이름과 이메일을 남겨 주시면, 베타 버전이 완성될 경우 가장 먼저 체험해 볼 수 있는 기회를 드립니다!


LL 파서의 추억

Posted 2007. 5. 24. 09:55
Haskell 컴비네이터 파서(Combinator Parser)인 Parsec 문서를 보다가 학창 시절 파서에 얽힌 기억이 떠올라서 올려봅니다. 4학년 때 들은 컴파일러 수업은 기말 프로젝트가 C-라는 프로그래밍 언어의 컴파일러를 구현하는 것이었습니다. C-는 C의 서브셋으로 데이터 타입이 정수 밖에 없고 포인터도 없는 간단한 프로그래밍 언어입니다. 타겟 머신은 X86이 아닌 아주 간단한 어셈블리 언어였습니다.

학부 컴파일러 수업의 보통 여러 파싱 이론(Parsing Theory)를 배우는 데 많은 시간을 할애하는데, 물론 컴퓨터 프로그래밍 언어를 위한 파서이므로 자연어 처리에나 필요할 만한 깊이 있는 파싱 이론을 하지는 않습니다. CFG(Context Free Grammar) 파싱할 수 있는 LL, LALR, LR 파서가 대표적인 주제이죠.

당시 프로젝트 구현 언어는 자바였기 때문에 파서 생성기(Parser Generator) 선택을 두고 학생들은 LL(k) 파서(정확히 말하자면 Predicated-LL(k) 파서)인 ANTLR과 LALR(1) 파서인 자바 CUP으로 양분 되었습니다. 당시 교과서가 호랑이 책(Modern Compiler Implementation in Java)였기 때문에 원래 프로젝트는 파서 생성기로 CUP을 쓸 것을 명시해 놨었는데, 제가 강력 주장해서 ANTLR도 옵션으로 포함되었습니다. 일부 학생들은 저의 선동에 혹해서 ALTLR을 선택했었습니다.

ANTLR의 장점은 LL(k) 파서인데다 테이블 기반(Table-Driven)이 아닌, 사람이 손으로 작성한 것과 유사한(Recursive Descent Parser) 같은 코드를 토해내는 데 있었습니다. 따라서 생성된 코드를 쉽게 이해하고 문제점을 고칠 수 있었죠. 반대로 완전한 테이블 기반의 파서인 LALR 파서는 문제(주로 Reduce-Reduce Conflict)가 발생해도 에러 메시지만 가지고는 뭐가 문젠지 알기 힘든 점이 있었고요.

근데 ANTLR을 선택한 학생들이 저에게 원망을 하기 시작했습니다. LALR 파서에는 그냥 되는 문법이 ANTLR에서는 안 된다는 것입니다. 그럴 수 밖에 없는 게, ANTLR은 기본적으로 LL 파서이기 때문에 Left Recursion을 직접 제거(Left Factoring) 해주거나 일부 문법에 Predicate을 통해 미리보기(Lookahead)를 직접 지정해주어야 했거든요. 이 차이점을 제대로 이해 못한 사람들이 많았던 것이죠.

LL(1) 만으로 파싱할 수 있는 문법은 많지 않고 대게는 필요에 따라 LL(2), LL(3) 등으로 들어나는데, k 값이 1 증가할 때마다 파서 성능이 엄청 떨어집니다. 사실 문법 중에 단 한 군데만 LL(2)가 필요한데 전체 파서를 LL(2)로 처리하는 건 문제가 있습니다. ANTLR은 이 문제를 해결하기 위해 Syntatic Predicate, Semantic Predicate 같은 개념을 도입합니다. 쉽게 설명하면 LL 파서가 구분하지 못하는 특정 문법에만 Lookahead를 통해 힌트를 주는 것이죠.

다시 Haskell 이야기로 돌아가면, Parsec도 기본적으로 LL(1) 파서입니다. LL 파서는 필히 Left Recursion 문제에 대해 고민을 해야하는데, Parsec의 방식은 직관적이며 간단합니다. Parsec은 LL(1) 파서를 지향하되, 필요에 따라서는 백트래킹(Backtracking) 하는 전략을 취합니다. 즉, 파서 룰에 try 라고만 명시해주면, 일단 왼쪽 룰부터 파싱을 시도해보고 실패하면 아무 일도 없었던 것처럼 다음 걸 다시 시도해 보는 방식입니다. 따라서 개념적으로는 LL(무한대) 문법을 파싱할 수 있게 되는 것이죠. 물론 백트래킹 파서는 무척 비효율적이기 때문에 LL(1) 파서를 지향하되, try라고 명시된 부분에 한해서만 백트래킹 모드로 변신합니다.

요즘은 파싱이 필요한 거의 대부분의 데이터를 XML로 처리하기 때문에 파서를 작성하거나 파서 생성기를 쓸 일이 정말 드뭅니다. 프로그래밍 언어의 파서를 작성하거나 하는 일은 정말 소수의 개발자가 하는 일이니깐요. 하지만, 개발 작업을 보면 사실 대부분의 일이 파싱/언파싱입니다. 데이터를 얻어오고 저장하는 일에는 필히 파싱이 동반되니깐요. 시간만 되면 이쪽으로 좀 깊이 있게 공부해 보고 싶은데, 항상 마음만 굴뚝 같군요.

Haskell 독서중.

Posted 2007. 5. 20. 06:46
주말 동안에 Haskell, The Craft of Functional ProgrammingThe Haskell School of Expression을 열심히 읽고 있습니다. 2001년도에 프로그래밍 언어(PL) 수업 들으면서 한참 함수형 언어에 빠져들어서 샀던 책인데, 최근에 다시 한 번 읽어보는 중입니다.

최근 프로젝트에서 파이썬을 주 언어로 사용하고 있는데, 제대로 된 타입 시스템이 없는 파이썬 코드에 영 적응이 안 되던 차에 강력한 타입 시스템을 제공하는 헤스켈에 대한 향수가 생겼달까요.

그때만 해도 컨셉은 좋지만 실용적으로 쓰기에는 무리라고 판단을 내렸었는데, 다시 보는 헤스켈이 생각보다 성능이 좋군요. 헤스켈을 바이너리로 컴파일해 주는 GHC(Glasgow Haskell Compiler)의 성능도 상당히 향상된 것으로 보이고요.

심볼 연산(symbolic computation)이 주가 되는 실무에 일부 활용해 보려고 고민 중인데, 관련 소식을 업데이트 하겠습니다.

마소 6월 원고: FFI

Posted 2007. 5. 18. 21:51
오늘 마소 6월 원고를 마감했습니다. 지난 달 원고 쓴지 얼마 안 된 것 같은데 원고 마감은 왜 이렇게 빨리 돌아오는지! 이번달 주제는 외부 함수 인터페이스로 정했습니다. 자바에서 C를 부르고, 파이썬에서 C를 부르고 하는 것들을 말합니다.

외부 함수 인터페이스(FFI, Foreign Function Interface)

근래의 소프트웨어들을 살펴보면, 보통 한 가지 이상의 언어로 작성됨을 알 수 있다. 복잡한 프로그램의 요구 사항을 만족시키기 위해 여러 프로그래밍 언어의 장점만을 취하려는 전략이다. 대표적인 예가 주 개발은 자바로 하고, 성능이 필수적인 일부 모듈만 C 언어로 작성하는 것이다. 자바 언어의 안정성과 방대한 라이브러리를 취하면서, 동시에 C의 높은 성능을 얻을 수 있기 때문이다. 자바와 C를 연결하기 위해 사용하는 인터페이스는 JNI(Java Native Interface)라 불리는데, 자바뿐만 아니라 대부분의 언어들이 외부 함수를 호출할 수 있는 인터페이스(FFI, Foreign Function Interface)를 제공하고 있다. 이 글에서는 자바(JNI)와 파이썬(Python/C API)을 통해 FFI의 개념과 사용 방법을 살펴보자.


자세한 내용은 6월호가 나오면 보실 수 있습니다.


Haskell에 대한 오해?

Posted 2007. 5. 18. 04:57
현대 함수형 언어의 대표격인 Haskell은 이제 대부분 개발자가 이름 정도는 들어본 언어가 되었죠?
그리고 Haskell의 강력함을 소개하는 예제로 빠지지 않고 등장하는 것이 바로 C 언어로 정확하게 구현하려면, 머리 잡아 뜯으며 디버깅해야 한다는 퀵소트(QuickSort)를 다음과 같이 매우 직관적이고 손쉽게 할 수 있다는 것이죠.

사용자 삽입 이미지

위 간단한 예제는 Haskell의 List Comprehension이나 Generic Recursion 같은 함수 언어 특유의 여러 특징을 잘 보여줍니다.

그런데 요즘 주변 친구들에게 Haskell 언어 아냐고 물어보면 이런 대답이 돌아옵니다. 그거 퀵소트 잘하는 언어 아냐? 그냥 퀵소트 잘하는 언어. 아무 짝에도 쓸모 없는 퀵소트만 잘하는 언어...

프로그래밍 언어도 보다 적극적인 마케팅이 필요한 시대입니다.

함수형 언어 공헌자들.

Posted 2007. 5. 18. 04:50
함수형 언어는 대부분 학계에서 출발했습니다. 대학 다닐 때 학과 복도를 보면 컴퓨터 공학 발전에 지대한 공헌을 하신 분들의 사진이 죽 걸려 있었습니다. 그 중에 함수형 언어 공헌자들 사진만 뽑아봤습니다.

사용자 삽입 이미지
Lazy 함수 언어들을 만들고 Miranda 시스템 만든 David Turner

사용자 삽입 이미지
타입 추론(type inference)과 다형 타입(polymorphic type)을 도입한 함수형 언어 ML의 창시자 Robin Milner

사용자 삽입 이미지
고차 함수 등의 개념을 강조한 함수 언어인 FP를 만든 John Backus
 
사용자 삽입 이미지
첫 번째 순수 함수형 언어 ISWIM을 만든 Peter Landin


사용자 삽입 이미지

Lisp을 만든 John McCarthy



사용자 삽입 이미지

Lambda Calculus를 만든 Alonzo Church

음. 부러워라.

Tuple이라는 단어의 기원

Posted 2007. 5. 14. 03:50
함수형 언어의 대부분과 파이썬 등은 튜플(tuple)을 내장(builtin) 타입으로 가지고 있습니다.

("Salt", 100)

과 같이 서로 다른 타입을 가지며 순서가 중요한 타입입니다. 보통은 불변형(immutable) 타입이고요. 함수에서 2개 이상의 값을 리턴할 때 유명하게 쓰입니다. 이 튜플(tuple)이라는 단어가 어디서 왔을지는 별로 생각을 안 해보고 쓰고 있었는데 알고보니 엄청 단순한 거였더군요.

(a, b) -> pairs
(a, b, c) -> triples
(a, b, c, d) -> quadruples
(a, b, c, d, e) -> quintuples
(a, b, c, d, e, f) -> sextuples

이렇게 보면 2개 짜리 pair를 제외한 모든 단어가 tuples 비슷하게 끝납니다. 그래서 tuple이라 불린답니다.

파이썬 -i 옵션

Posted 2007. 5. 9. 14:57
항상 쓰는 프로그램인데도 새로운 기능을 발견하는 경우가 종종 있습니다. 최근에 진행 중인 프로젝트에서 파이썬을 메인으로 쓰고 있는데, 모듈의 테스트를 위해 __name__이 '__main__'인지 확인하고 UI 쓰레드를 만드는 코드가 있습니다.

UI 프로그램이라 전체 테스트를 자동화시킬 수는 없고 기초적인 셋업이 끝나면 바로 파이썬 인터프리터가 뜨면 좋겠다고 생각을 했습니다. 그럴 때 쓰는 용도로 -i 옵션이 있더군요. python -i script.py라고 실행시키면, 스크립트 실행이 끝난 후에도 파이썬 인터프리터를 살려주더군요.

빌드와 백신

Posted 2007. 5. 3. 23:29
최근에 구글 업데이트에서 추천하는 바이러스 스캐너와 악성 프로그램 제거기를 설치했습니다. 설마 '구글'이라는 회사가 백신을 가장한 악성 프로그램을 배포하지는 않으리라는 생각에서 부담없이 깔았죠.


그로부터 며칠 후 오늘 cygwin에서 라이브러리 하나 빌드할 일이 있었습니다. 그런데 며칠 전까지는 잘 컴파일 되던 프로그램이 중간 중간에 ranlib이나 mv 등을 하면서 permission denied 에러 메시지를 내면서 죽더군요. 그 사이에 컴퓨터가 맛이 갔나 싶어서 cygwin의 binutils나 core를 새로 깔아보기도 하고 하드 디스크 드라이브를 바꿔 보기도 했는데, 같은 문제가 반복되더군요.


어떻게 하나 싶어서 한참 고민하다 보니, 며칠 전에 깔았던 바이러스 스캐너가 원인이 아닐까라는 생각이 들었습니다. 컴파일 및 링크 과정은 새로운 파일을 생성하게 되는데, 파일이 새로 생성되면 운영체제의 이벤트를 받아 새로 생성된 파일을 바이러스 스캐너가 실시간으로 스캔하게 되죠. 그런데 이렇게 스캔 중인 파일을 곧바로 mv나 ranlib으로 수정하려고 했을 때 문제가 발생하는 게 아닐까라는 가정을 하였습니다.


확인을 해보려고, 바이러스 스캐너를 지우고 나니, 컴파일 잘 되는군요. 어흑. 바이러스 스캔은 exclusive read 모드로 하지 말란 말이다!


SKT 또 사고치다.

Posted 2007. 4. 13. 23:43
한겨례 신문에 SKT ‘멜론’ 음악서비스, 고객장비 ‘얌체’ 사용이라는 기사가 떴습니다. 사용자의 허락 없이 네트워크와 컴퓨터 자원을 불법으로 전용해 자사의 서비스에 이용한 사건이라는 측면에서 과거 네이버의 터버 플레이어 사건과 유사하네요.

각종 스트리밍 서비스의 문제점 중에 하나가 늘어나는 서버 용량을 어떻게 감당할 것인가라는 점이고, 사용자 컴퓨터를 이용한 스트리밍 전송(이른바 피어캐스팅)은 매력적인 대안이 아닐 수 없습니다. 실제로 상당히 많은 스트리밍 서비스들이 이런 기술을 사용함을 명시하고 있습니다.

하지만 SKT의 멜론 같은 경우는 질이 나빴던 게 음악 다운로드 자체에 대가를 청구하는 방식이면서, 그 과정에서 사용자의 컴퓨터를 무단으로 사용했다는 점이죠. 즉 재주는 곰이 넘고 돈은 딴 놈이 버는 상황을 연출해 버렸습니다. 물론 완전 무단은 아닙니다. 어디까지나 약관에 사용자의 자원을 마음대로 사용할 수 있다고 명시하고 있으니깐요.

사용자 삽입 이미지

이런 약관을 꼼꼼하게 안 읽어본 소비자 책임이라고 주장해봐야 SKT 이미지에 미치는 타격을 피할 수는 없을 것 같군요. 오히려 저런 걸 넣어놔서 소비자 입장에서는 더 분통이 터지는 것 같습니다.

하지만 이런 피어 간의 데이터 공유 기술이 근본적으로 나쁜 것은 아닙니다. 같은 기술도 사용자들에게 보상 체계만 잘 만들어주면 아주 유용할 수 있습니다. 비트토런트가 대표적인 예죠. 비트토런트는 아주 간단한 질문에서 시작합니다. 사용자가 자기가 다운로드 받은 파일을 공유해주면 그 대가로 무엇을 얻느냐는 것이죠. 비트토런트는 업로드해주는 만큼 다른 피어에서 다운로드 받아올 확률도 높고, 결국은 좀 더 빨리 다운받기 위해 자발적으로 공유하는 모델을 만들어줍니다.

사용자가 네트웍 자원을 기꺼이 공유해줄 경우 어떤 식으로도 보상을 해줘야 맞는 것이지요. SKT도 약관을 좀 더 명확하게 사용자들에게 주지시켜야 함과 동시에 적절한 보상 체계를 만들어줬어야 했습니다. 아래와 같은 SKT 관계자의 말은 더욱 어이가 없습니다. 보상 체계가 없는데 도대체 누가 피어링포털 기술이 내장된 멜론 플레이어를 깔고 싶어하겠습니까? 봉사 정신이 투철한 사람이 아니고서야-_-

이름을 밝히지 말 것을 요청한 에스케이텔레콤 관계자는 “피어링포털 기술을 내장한 멜론 플레이어와 뺀 것을 함께 내놓고, 이용자에게 선택하도록 했어야 했다”고 말했다.

이런 사건이 발생했을 때 쉽게 집단 소송을 할 수 있는 모임이 있었으면 좋겠군요.

« PREV : 1 : ··· : 3 : 4 : 5 : 6 : 7 : 8 : 9 : ··· : 13 : NEXT »