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

예를 들어 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와 같은 형태로 점을 찍어서 상대 임포트를 한다고 하는군요.

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

Write your message and submit

파이썬 마을 입추 기념 번개

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

Write your message and submit

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.
Write your message and submit

마소 인터뷰

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에 대해 이야기할 기회도 있었고, 마소가 이래저래 많은 인연을 만들어 주고 있습니다.

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

  1. Favicon of http://kaistizen.net BlogIcon 최재훈

    | 2007.08.04 11:28 | PERMALINK | EDIT | REPLY |

    요즘은 파이썬에 올인 중이신가봐요? 저도 파이썬을 미리 익혀둬야 할 분위기라, 이번 마소 기사가 흥미롭더군요. ㅎㅎ

  2. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.08.07 21:14 신고 | PERMALINK | EDIT |

    요즘 가장 많은 시간을 사용하는 언어다보니 자연스레 올인하게 되었습니다. 예전에 파이썬 하루 반나절이면 배운다고 광고하던 게 기억나는데, 옛날 그 파이썬이 아니더군요...

  3. Favicon of https://3tour.tistory.com BlogIcon 사람사는 세상 만들기

    | 2007.08.06 18:31 신고 | PERMALINK | EDIT | REPLY |

    마소는 그나마 명맥을 계속 유지하네. 얼마나 유지할련지....^^
    날로날로 발전하는 모습이 좋다.
    서울에 가면 연락하마...

  4. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.08.07 21:15 신고 | PERMALINK | EDIT |

    엉~_~

  5. Favicon of http://innolab.tistory.com BlogIcon chong

    | 2007.08.10 20:40 신고 | PERMALINK | EDIT | REPLY |

    정말 꾸준히 기사를 쓰셨네요. 대단하시네요. 기사 마감에 맞추는게 은근 큰 스트레스던데... 그리고 8월호 developer story 잘 보았습니다. 웃는 모습이 멋지십니다~ :)

  6. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.08.11 01:46 신고 | PERMALINK | EDIT |

    마감의 압박 장난 아니죠. 15일이 넘어가기 시작하면 불안과 초조함이 엄습하는^^;;

Write your message and submit

IBM dW 인터뷰

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

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

  1. axis

    | 2007.07.28 19:04 | PERMALINK | EDIT | REPLY |

    인터뷰 잘했던데 뭘... ^^

  2. Favicon of http://www.jayr.org BlogIcon 프로그래머 류

    | 2007.07.29 01:01 | PERMALINK | EDIT | REPLY |

    오.. 알찬데요? 마소에 실린 글도 봤어요. 화이팅! ^^

  3. 장진성

    | 2007.07.30 10:37 | PERMALINK | EDIT | REPLY |

    짝짝짝~~~~~ 기대가 크다... ^^

Write your message and submit

파이썬 데코레이터

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

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

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

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

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


  1. 광식

    | 2007.06.26 10:35 | PERMALINK | EDIT | REPLY |

    제 생각에는 웹의 경우 기술 우위가 경쟁력이 아닙니다. delicious, flickr, digg, facebook, twitter, youtube, ... 모두 기술로 현재의 위치에 오른 웹사이트가 아닙니다.

    웹의 중요 키워드는 가치입니다. 우후죽순으로 나오고 있는 youtube 클론들도 더 높은 기술과 기능이 있는 것보다는 더 많은 가치를 줄 수 있는 것들이 성공하고 있습니다.

  2. 서광열

    | 2007.06.26 11:38 | PERMALINK | EDIT |

    경쟁력의 요소야 당연히 기술 뿐만 아니라 여러 가지가 있겠죠. 서비스 초기에는 서비스 아이디어나 효용성(얼마나 더 큰 가치를 주느냐)이 더 중요한 것도 맞고요.

    하지만 해당 비지니스가 주목을 받고 어느 정도 돈이 된다고 알려졌을 때, 같은 서비스를 순식간에 제공할 수 있는 다른 업체들을 어떻게 따돌릴 것이냐는 문제는 여전히 남아있습니다.

    웹 관련 회사에서 기술적 인프라가 눈에 띄는 것은 아니지만, 남들보다 저렴하게 같은 서비스를 제공할 수 있는 인프라나, 뛰어난 검색 기술 등을 간과하면 안 된다고 봅니다.

  3. Axis

    | 2007.06.26 17:13 | PERMALINK | EDIT | REPLY |

    개인적으로는 저도 광식님의 생각에 동의합니다. 일례로 사이월드만해도 하부 시스템은 엉망이었지만 성공을 했죠. 뒤에 고생은 했지만요. 애당초 어떤 기술 도구로 일이 쉬워졌다면 일 자체의 복잡도가 아닌 부수적인 복잡도가 불필요하게 높았던 것을 낮췄다고 생각하는게 맞을 것 같습니다.

    또한 어떤 서비스가 후발 주자에게 쉽게 따라 잡힐 수 있다면 그건 그 서비스가 충분히 모멘텀을 얻지 못했을 뿐이라고 봅니다. 웹에서 처음부터 기술이 진입 장벽이 되는 경우는 거의 없다고 봅니다. 구글의 AJAX 애플리케이션이 기술 때문에 각광을 받는 걸까요? 아니라고 봅니다.

  4. Favicon of http://jsjang.tistory.com BlogIcon 장진성

    | 2007.06.27 17:32 | PERMALINK | EDIT | REPLY |

    웹의 가치는 기술이 아니라 사용자가 아닐까 하는 생각이 드네.
    Ajax든 SilverLight든 Apollo든 어느 기술을 사용하느냐가 아느라 사용자에게 얼마나
    불편함을 주지 않느냐가 기술이지 않을까하는 생각이 드는데.
    웹어플리케이션 컨퍼런스에서 SilverLight 봤는데, 정말 대단히 기술임은...ㅋㅋ

Write your message and submit

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

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

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

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

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

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 대회에 입상도 못하고 초보 수준의 문제 몇 개만 풀어보고 함부로 이야기하는 놈'이 쓴 글을 보고 분해하신 분들은 오해 푸시길.^^;;

  1. 이전 댓글 더보기
  2. Favicon of http://proxima.1manshow.co.kr BlogIcon proXima

    | 2007.06.19 23:11 | PERMALINK | EDIT | REPLY |

    ACM 문제를 잘 이해하고 또 잘 풀 수 있는 능력이
    소프트웨어 설계할 때 도움이 될 거라고 생각하는데...

    그 내용을 이미 starplayer님이 적어주셨군요 ㅋㅋㅋ

  3. Favicon of http://skyul.tistory.com BlogIcon 서광열

    | 2007.06.20 00:20 | PERMALINK | EDIT |

    ACM 문제가 도움이 안 된다는 얘기라기 보다는 ACM 문제만 풀어서는 안 된다는 거였음. 눈높이 수학 열심히 하면 수학 시험 잘 치잖아-0-

  4. 지나가는이

    | 2007.06.29 16:20 | PERMALINK | EDIT | REPLY |

    acm icpc 문제푸는게 도움이 안된다라..
    그건 수준이 낮아서 그런거 아닌가요??
    World Final에 우승할 정도의 실력이라면...말이 달라질텐데요..그냥 단순히 코딩만해서 풀 수 있는거라...
    논문이해해서 문제푸는것도 많거든요.

    필자가 해봤자 끄적끄적거리는 수준이라서 도움이 안된다라고 하는게 아닐려나...

  5. 쥬이

    | 2007.07.14 16:00 | PERMALINK | EDIT | REPLY |

    안녕하세요. 지나가다가 글 보고 한마디 끄적거리고 갑니다.
    저는 중고등학교때 KOI(한국정보올림피아드: ACM과 형식이 아주 유사합니다)를 공부했었고, 대학에 들어와서는 모학원에서 학생들에게 KOI를 대비하여 알고리즘을 가르친지 1년정도가 되었습니다.

    ACM과 KOI가 형식이 매우 유사하다보니, ACM 문제들 위주로 학원에서 공부를 많이 시키고 있습니다. 저 또한 예전에 ACM문제들을 많이 풀었구요.

    ACM문제들이 단순 계산이나 공식들로만 이루어져 있다고 하셨는데, 그렇지 않습니다.
    문제도 굉장히 많고, 대학별로도 따로 문제가 있습니다. 이 문제들에 전세계적으로 꽤나 많은 사람들이 문제를 풀고 있는데는 이유가 있습니다.
    물론 쉬운 문제도 있는건 사실입니다만, 어떤 문제를 보셨는지 모르겠지만.. 그중에는 난이도가 매우 높은 문제들도 다수 있습니다.(지금도 전세계 사람들이 풀기 위해 아마 고분분투하고 있을겁니다)

    ACM은 여러 알고리즘들을 잘 알고 있고 그것들을 적절히 잘 조합해서 적절히 문제에 응용할 수 있는 능력을 가진 사람만이 잘 풀어나갈 수 있습니다. 여기서 얻어지는것은 '사고능력'이죠. 단순히 계산하고 공식만 외워서 풀 수 있는 문제들이라면 과연 그 많은 사람들이 계속하여 문제를 풀고자 노력할 것이라고는 생각하지 않습니다. 또한 이 '사고능력'은 그렇게 단시간 내에 이루어지는 것이 아닙니다. 명령어 가르쳐줘도 응용을 못하면 아무 소용이 없겠지요.. '사고능력'이 길러진 사람들은 이해도도 빠르고 응용도 대개 잘 할 수 밖에 없습니다.

    실제로 KOI출신의 입상학생들은 95%이상 대학에서 컴퓨터학과를 선택하고, 대학에 와서 ACM을 준비하는 학생들도 많습니다. 그러나 ACM만 준비하는 것이 아니라 대다수의 학생들이 ACM외의 프로그래밍 공부들도 합니다(제가 아는 잘나가는 학생들은 그 회사에 갈게 아니라면 인턴을 하지 않습니다. 인턴에서 배우는것에 비해 페이도 너무적거니와, 학교 다니면서 프리랜서로 개발하는 사람들도 많거든요..) 또 기존에 아는 사람들이 많기 때문에 서로 자극받으면서 공부를 하기 마련입니다. 또한 미리 전공공부를 하고 들어왔기 때문에(최소한 C언어, 자료구조, 알고리즘은 공부하고 왔기 때문..) 학점도 조금만 관리하면 다른 학생들보다 관리하기가 아주 쉽죠.

    물론 프로그래밍에서 중요한건 명세(specification)과 설계(design)가 맞는건 사실입니다. 또한 실제 개발과 ACM의 알고리즘은 많은 차이가 있다는것도 압니다. 하지만 제가 알기에 ACM출신자들 중 많은 사람들이 개발을 잘하는건 공공연한 사실입니다.(꼭 잘한다는건 아닙니다..)

    이런현실에서 ACM을 눈높이 수학에 '격하'시키는것은 대단히 안타깝네요..

    지나가다가 조금 씁쓸해서, 몇자 적고 갑니다.

  6. -_-;

    | 2007.07.14 23:19 | PERMALINK | EDIT | REPLY |

    ACM에 대해서 얼마나 깊이 있게 공부하시고 도전해 보셨는지 모르겠지만

    너무 수박 겉할기식으로 ACM을 바라 보시고 실제로 오랜 경험을 통해서

    ACM 준비를 통한 이득에 대한 체험도 없이 글을 쓰신 것 같군요.

    ACM이야 말로 생각나는데로 코드 짜면 망하기 때문에 프로그램 흐름에 대한 체계를 충분히 세우고 프로그래밍을 해야 한다는 사고를 기르는데 더없이 훌륭한 교과서적인 것이라고 생각하는데요.

  7. astein

    | 2007.07.15 21:00 | PERMALINK | EDIT | REPLY |

    본문에 보면 아래와 같은 부분이 있는데요.
    ------------
    사실 ACM 문제는 문제별로 난이도 차이는 있지만, 한 문제만 놓고 살펴보면 조금 똑똑한 학부 1-2학년에게 시간만 충분히 주면 누구나 풀 수 있는 쉬운 문제에 지나지 않습니다.
    ------------

    > 쉬운 문제들의 경우에는 모르겠지만, 대부분의 난이도 있는 문제들에는 이론적인 배경이 뒷받침되어 있지 않다면 아무리 시간을 줘도 풀 수 없는 문제들이 나옵니다. "조금 똑똑한 학부 1-2학년에게 시간만 충분히 주면 누구나 풀 수 있는 쉬운 문제"라는 부분은 대회를 오랫동안 겪어본 학생의 입장으로서는 납득하기 힘드네요 :)

  8. -_-;

    | 2007.07.15 21:28 | PERMALINK | EDIT | REPLY |

    ACM 문제 해결 가능한 사람과 시스템 디자이너와의 차이는 큽니다.
    ACM류의 문제를 풀기 위해선 알고리즘이란 것을 알아야합니다. 누구나 풀수있는 쉬운 알고리즘 부터 아무나 풀지 못하는 고급 수학을 요하는 알고리즘까지 다양한 알고리즘이 이용됩니다. 그리고 어느 단계 이상을 나가기 위해서는 위에도 언급했듯 "수학"의 영역으로 반드시 접근을 해야합니다.그래야 실제로 단 한줄을 짜더라도 심도있는 코어를 만들어 낼 수 있습니다.
    이를 위해서 ACM류의 문제는 매우 좋은 접근 방법입니다.

    시스템 디자이너 또한 개발에 있어서 매우 중요한 요소이지요. 하지만 시스템 아키텍쳐 설계는 그리 큰 수학을 요구하기 보다는 "경험"이라던지 경험 보다 조금 깊은 사고 정도만 요합니다.

    예를 들면 3d게임을 만들어 내는 것은 시스템 디자이너의 몫이지만 훌륭한 3d 엔진을 만들어 내는 사람은 ACM등에서 알고리즘의 영역에 들어가 수학적 백그라운드가 탄탄한 사람들이나 가능합니다.

    더욱더 본질 적인 것은 무엇일까요? 3d엔진 개발자는 3d게임을 만들어 낼 수 있습니다. 하지만 3d게임 개발자는 3d엔진을 만들수없습니다.

    1류와 2류의 차이는 큽니다..

    수학적인 알고리즘의 필요성을 알게 하는데 일조하는 ACM.. 절대로 무시 못합니다.

  9. eilef

    | 2007.07.16 11:06 | PERMALINK | EDIT | REPLY |

    사실 ACM 문제는 문제별로 난이도 차이는 있지만, 한 문제만 놓고 살펴보면 조금 똑똑한 학부 1-2학년에게 시간만 충분히 주면 누구나 풀 수 있는 쉬운 문제에 지나지 않습니다. <--

    1. 점화식이 복잡하거나 부분문제 정의 자체가 막막한 고차원 다이나믹 문제는 풀어 보셨나요?

    2. 주어진 시간안에 최적해를 보장 못하는 문제에 대해 단순한 BT에서 시작해서 GM, B&B, SA, GA등 여러 '휴리스틱'기법을 사용해서 성능을 비교분석 해보신적 있으신가요?

    3. 눈으로 보고 이해하기는 쉽지만 실제 코드로 표현하기 상당히 껄끄러운 공간지각적인 문제에 각종 기하 알고리즘을 적용은 해 보셨나요?

    ACM및 KOI준비하는 학생들 위에서 말씀드렸던 1,2,3번 전부다 피땀흘리며 공부하고 연습합니다.

    학부 1,2학년이라...-_- 요즘은 대학에서 1,2학년때 저러한 알고리즘 이론들을 다 가르치고 실제 문제에 적용하는 연습을 시키는가 보죠? 제가 졸업한지 무려 5개월이나 지나서 요즘 대학의 실태에 어두운가 봅니다. ㅎㅎ

  10. 휴가쓰고놀기

    | 2007.07.18 15:41 | PERMALINK | EDIT | REPLY |

    ACM과 참 오랜 인연을 가지고 있습니다만.. ACM문제를 매번 풀 때마다 좌절하는 저로써는 조금은 가슴을 아프게 하는 글이군요. 학생들이 그러하듯 숙제로서 ACM문제는 그다지 가치가 없어 보이긴 합니다. 다만 대회를 준비한다는 면에서는 타의 추종을 불허할 정도로 엄청나게 도움이 된다고 감히 말씀드리겠습니다. 이유는 한 가지입니다. ACM대회의 제약 조건 때문입니다. 3명이 1대의 컴퓨터를 5시간동안 사용한다는 것 그것이 가장 큰 제약입니다만 그 제약으로 인해 대회를 준비하는 학생들에게 있어서는 엄청난 발전을 이룩할 수 있게 해줍니다. 코딩에 들어가기전에 생각하는 습관 그것을 토론하는 습관, 토론을 통해 문제를 발견하는 습관, 그런 후에 코딩을 시작해서 생각했던 것을 하나의 프로그램으로 완전히 만들어 내기 전까지 컴파일도 하지않고 오로지 머릿속의 구조물을 코딩으로 만들어 내는 그 습관이야 말로 대회를 준비하면서 제가 얻은 가장 큰 수확이라 생각합니다. 덧붙이면 문제들간의 코딩 난이도 및 디버깅 시간까지 고려해서 문제를 푸는 순서도 스케줄링을 하기도하고 때로는 코딩 스피드를 조절하기도 합니다. 개인적으로 6년 넘게 일을하면서 한번도 마감일을 어겨본 적이 없는걸 자랑으로 여기는데 그 이유이기도 합니다.

    명세와 디자인에 관한 중요성은 님이 말씀하신 것 처럼 강조를 안 할 수가 없는 것입니다. 이를 위한 좋은 이론들이 새롭게 나올 때마가 계속해서 찾아보고 익혀보는 그런 노력이 필요합니다. 하지만 제가 언급한 몇가지 습관들은 명세와 디자인 이후의 일입니다. 그런 점에서 두 부류에 대해서 서로의 중함을 비교할 수는 없다는 결론을 드립니다.

  11. Favicon of http://libe.tistory.com BlogIcon LIBe

    | 2007.07.20 18:31 | PERMALINK | EDIT | REPLY |

    한가지 부탁드리고자 합니다. "ACM 문제 풀지마라" 라는 제목은 좀 어떻게 바꾸실 수 없을련지요?

  12. 촌음

    | 2007.07.23 22:17 | PERMALINK | EDIT | REPLY |

    예전에 KLDP에서도 이와 비슷한 글타래가 있었던 것으로 기억하는데요, 저도 서광열님 의견에 98%정도 동의합니다. 알면 도움될 "지식"수준의 알고리즘을 학습하고 응용능력을 기르는 것, 중요합니다. 하지만 상식과는 다른 특수한 상황하에서 이루어지는 알고리즘을 구현하는 ACM 대회의 문제들을 풀다보면 자칫 "화성인 아키텍트"가 될 수 있다고 생각합니다.

    조엘 온 소프트웨어에도 관련 글이 나오는데요, 공부해야 할게 정말 많은 학생들이 ACM문제를 푼다고 많은 시간을 할애하고, 정작 중요한 공부(OS, compiler, assembly, debugging..)는 하지 못한채 대기업에 취업할 경우 회의에서 이런 이야기를 하게 될 지도 모릅니다. "오라클 보다는 자바가 좀 더 통합적이라는데 우리 회사에서는 왜 자바를 사용하지 않는 거죠?" 또는 다음과 같은 논문을 발표할 지도 모릅니다. "프로그래밍 언어로서 스프레드시트가 지니는 이론적인 전산언어학적 성질".. 조엘 스폴스키이 말처럼, 똑똑하긴 하지만 쓸모가 없습니다.(이 말이 왜 이상한지 모르겠다면 당신이 바로 화성인 아키텍트입니다.)

    평소 잡지에 기고된 서광열님의 글과 번역서를 봐왔는데 개인적으로 본받을 만한 분이라고 생각합니다. 컴퓨터 아키텍처에 있어서 대한민국은 아직 삼류에 불과하다는 것이 제 생각이고 이런 현실은 이 포스트에서 다루는 주제와 무관하지 않습니다. 대부분의 학생들이나 현업에 종사하고 있는 엔지니어분들 마저도 "쓸모있는 컴퓨터 공학자"가 되기 위한 이 포스트를 가볍게 여기지 않았으면합니다.

    마지막으로 2%정도 동의할 수 없는 것은, "단정적이고 강한어조"라는 사실에 많은 분들이 동의하실 것 같네요. 그럼이만.

  13. .

    | 2007.07.31 19:52 | PERMALINK | EDIT | REPLY |

    글쎄요..
    남이 시키는 일을 받아서 코딩하는 사람과
    남에게 어떤 류의 코딩을 시켜야 하는 사람간의
    공부해야 하는 것의 다름이 아닌가 싶네요.
    해외 유수기업 혹은 교수들까지도, 왜 acm에서 좋은 성적을 거두는 학생을 데려가려고 하는지
    이해해볼 필요가 있다고 보네요. 그들이 더 실력 좋은 사람을 놓칠 수 있다라고 말씀하셨는데,
    코딩을 해야하는 부류의 좋은 인재는 구하기가 쉬워서 관심의 대상이 아닌거 아닐까요?

  14. NONAKC170

    | 2008.04.10 02:44 | PERMALINK | EDIT | REPLY |

    수준이 낮은 ACM 문제만 보면 그렇지요.

    프로그래밍엔 다른 요소들도 있지만
    ACM 문제들에 녹아있는 요소들도 무시하면 큰일나지요.

    3D MAX라거나, Direct 3D 등에 들어있는 아름다운(-_-..) 기하 알고리즘들을 이해하는데는 ACM 문제를 푸는 것보다도 더 어려울겁니다.

    ACM 월파 수준의 문제를 풀 수 있는 능력을 가진 사람이 없으면,
    겉껍데기가 될 수도 있어요.

    프로그래밍에 다른 요소들이 많고 다른 요소들이 매우 중요하다는것도 알지만, 도저히 무시할 수 없는 요소들이 ACM 문제에 들어있습니다.

    ACM 문제 풀지말라고 하는 것은 너무 과격해보입니다..

  15. bym

    | 2009.08.03 17:11 | PERMALINK | EDIT | REPLY |

    문제가 깔끔하고 정답이 딱 떨어지기 때문에...
    -> 말 그대로 학부 1,2년 학생이 풀 수 있을만한 문제만 그렇다고 봅니다. 대회에서 1번 문제 정도?

    하지만 문제 풀이가 어느 정도 숙달되고 나면 그 뒤로는 사실상 눈높이 수학 식의 문제 풀이 연습 밖에 되질 못합니다.
    -> 1번 수준 문제만 계속 푼다면 동의.

    딱 떨어지는 정답을 만들기 위해 단순화시킨 요구사항과 언제나 정답이 있다는 가정 때문에 깊은 사고력에는 오히려 방해가 되는 것이죠.
    -> 요구사항은 입출력 포맷 말하는건가요? printf와 scanf ;)?
    정답이 있는 문제만 있지만 그 정답을 위한 한가지 방법만 존재한다고 은근슬쩍 가정해 버리셨네요.

    사실 실제 소프트웨어 작성에서 분초를 다투는 알고리즘 작성 능력은 별로 중요하지 않습니다.
    -> 실제 ACM대회에서도 분초를 다투는 코딩 능력은 크게 중요하지 않습니다. 논리적으로 얼마나 정확한 해결법을 찾는지가 매우 중요하죠..

    ACM 문제 자꾸 풀면 득보단 해가 됩니다.
    -> ..... ACM 문제 자꾸 풀어서 나빠진 그 어떤게 있나요? 사고에 경직을 느껴보셨나요? 그런 학생, 동료 보신적 있나요?
    저는 ACM 문제 풀어보면서 프로그래밍 스킬과 논리적 사고력을 향상 시킬수 있었고 비교적 단기간에 효과적으로 문제 해결을 위한 사고 체계를 훈련할 수 있었다고 생각하는데요?

    이 글은 ACM을 세계 대회 수준으로 진지하게 준비하고 알고리즘과 데이터 구조의 깊이를 추구하시는 분들을 비하하기 위해 쓴 글이 아닙니다.
    -> 저는 ACM 문제를 갓 접하기 시작하는 학부생이 이 글을 읽고 오해 하지나 않을까 하는 걱정에 답글을 남깁니다.

    토익이나 토플 만점이 영어를 잘한다는 척도가 되지만, 그렇다고 토익이나 토플 공부만 해서는 영어를 잘할 수 없는 것과 같은 논리를 편 것이죠.
    -> 이건 제 경험을 토대로 한 주관적인 생각이긴 하지만 토익/토플과 영어능력의 상관관계 보다는 ACM 문제풀이능력과 프로그래밍능력의 상관관계가 비교할수 없을 정도로 더 크다고 생각되는데요? 비교 대상을 잘 못 잡으신것 같습니다.

    단지 프로그래밍을 잘하기 위해서 혹은 알고리즘이나 데이터 구조를 깊이 공부하기 위해서 무작정 ACM을 푼다는 상황은 오히려 역효과를 가져올 수도 있다는 이야기를 한 것입니다.
    -> 프로그래밍을 잘하기 위해서나 알고리즘이나 데이터 구조를 깊이 공부하기 위해 무작정 ACM 문제를 푸는 사람도 없을거라 생각하고 기본적으로 프로그래밍, 자료구조, 알고리즘에 대한 기초 없이는 몇 문제 풀지도 못할 거라고 생각하지만, 설령 그런다 하더라도 저는 글쓴이께서 말하는 그 역효과는 제로에 가깝다고 생각합니다.


    글쓴이께서 말하는 디자인 능력이 중요하다는 것에는 동의하지만, 결론이 ACM 문제 풀이가 해롭다라고 난 것은.. 심각한 논리적 오류라고 생각합니다. ACM 문제만 많이 풀면 디자인 능력이 떨어진다라고는 그 어떤 이유를 봐도 생각하기 힘들고 근거도 없는듯 하고요..


    끝으로... 다시 한번 이야기 드립니다.
    2년도 넘은 글을 지금 보게 되었지만..
    ACM 문제를 갓 접하기 시작했거나 접하게 될 학생들이 이 글을 읽고 경험해보기도 전에 잘못된 편견을 가져 매우 효과적인 프로그래밍 공부방법을 지나쳐 버릴까봐 염려되어 답글을 남깁니다.

  16. 너보다니언니

    | 2009.10.11 10:37 | PERMALINK | EDIT | REPLY |

    어디서나 반복되는 작업은
    사람을 단순화시키는 것이 사실이죠.

  17. b

    | 2010.09.13 02:00 | PERMALINK | EDIT | REPLY |

    필자께서 스스로 'ACM 대회에 입상도 못하고 초보 수준의 문제 몇 개만 풀어보고 함부로 이야기하는 놈'이라고 생각을 하신다면 처음부터 잘 모르는 주제에 대하여 강하고 단정적인 어조로 글을 쓰신것부터가 실수입니다.

  18. 최원준

    | 2011.02.13 03:51 | PERMALINK | EDIT | REPLY |

    훌륭한 글입니다.
    저는 고등학생인데요. 캐나다에서 각종 프로그래밍 대회를 준비하고 있습니다.
    나중에 제 의기가 꺽여서 나태해지면, 이 글을 핑계로 "어차피 해봤자 다 쓸데없어" 라면서 포기하렵니다. 패배자한테 좋은 핑계거리를 주는 글이네요 :D.

  19. Favicon of https://naraeon.tistory.com BlogIcon ebangin127

    | 2016.09.04 13:56 신고 | PERMALINK | EDIT |

    당시 고등학생이셨으니 이제는 대학을 가셨겠군요. ACM 문제는 수단에 불과한 것인데 그걸로 승리자/패배자를 논하는 사고방식에서 벗어나셨기를 바랍니다 ㅎㅎ

    의지가 꺾이면 저걸 핑계로 벗어나겠다고 했는데, 사실 그렇게 되면 ACM 밖의 넓은 세계가 보일겁니다. 마치 고등학교 때 수능밖에 모르다가 수능이 끝나면 진정한 전공의 길이 열리고, 학부가 끝나고 대학원에 가면 학문의 길이 열리고, 그 뒤에도 이런 과정을 계속하며 더 넓은 세계가 있음을 알아가는 것과 같죠.

  20. | 2011.04.06 19:34 | PERMALINK | EDIT | REPLY |

    비밀댓글입니다

  21. 벌써6년

    | 2014.01.24 09:42 | PERMALINK | EDIT | REPLY |

    누구나 풀 수 있다? 그렇게 따지면 세상 어느일이든 충분한 시간만 주어지면 누구든 할 수 있답니다.

  22. Favicon of https://naraeon.tistory.com BlogIcon ebangin127

    | 2016.09.04 14:20 신고 | PERMALINK | EDIT |

    정지 문제도요? ACM에서 배울 수 있는 것들 중 하나가 반례를 생각하는 능력 아니던가요. 테스트 해야 하는 것은 코드만이 아닙니다. 일찌기 정약용 선생은 "이 편지가 수백 년 동안 전해져서 안목 있는 많은 사람들의 눈에 띄더라도 조롱받지 않을 만한 편지인가를 생각해야한다."라고 했습니다. 자신의 글에 쓰인 문장들이 수백 년 뒤의 테스트 케이스에도 걸리지 않게 할 것을 명시하고 있죠.

    답이 정해진 ACM 밖에도 세상은 있답니다. 생각보다 엄청난 시간이 주어진대도 인간이 할 수 없는 세상 일은 많습니다. 거창하게는 어떤 양자의 위치를 정확히 관측하는 일부터 시작해서 단순하게는 멍청할 정도로 단순한 정지 문제의 답을 내는 일이 그렇죠.

  23. Favicon of http://mezeet.tistory.com BlogIcon 미짓

    | 2014.11.21 14:05 신고 | PERMALINK | EDIT | REPLY |

    계속되는 반론은 "나는 ACM 과 고관여되어 있고 그것이 내게 매우 효능을 주며 그것은 너 따위가(!!) 알 수 없다" 라는 내용이고...

    본문에 이미 반복되는 눈높이 수준의 문제만 푸는 상황이 되는 경우에 ACM 문제를 계속 푸는 것은 문제의 목적인 사고력 향상에 도움이 안된다고 밝히고 있음에도... 너 따위라 라면서 자신의 존재를 구별지으려는 시도를 계속 하고 있습니다.

    왜 그럴까요? ㅎㅎㅎ ACM 문제를 풀 정도의 사고력이 있는 사람들이 왜 본문에 나와있는 내용을 보지 못하고 정작 ACM 문제 보다는 글쓴이를 격하시키고 자신을 높이려는 글을 쓰고 있을까요? ㅎㅎ 양상이 재미있네요.

    ACM 이 없으면 자기 이미지가 망가져 버릴 정도로 중요한 건가요 그게?

  24. Favicon of http://gracefulife.blog.me BlogIcon Gracefulife

    | 2015.10.17 11:45 | PERMALINK | EDIT |

    제목이 자극적이긴 하나 .. 댓글을 쭉 읽다보니 미짓님 댓글을 보았는데.. 시원하네요ㅋㅋㅋ

  25. Favicon of https://naraeon.tistory.com BlogIcon ebangin127

    | 2016.09.04 14:10 신고 | PERMALINK | EDIT | REPLY |

    사실 컴퓨터 과학 연구자들은 코딩과도 큰 상관이 없는 경우가 많죠. ACM의 유용성을 강조하시는 분들이 많이들 얘기하는 게 결국은 코딩으로 배울 수 없는 이론적인 내용을 배울 수 있다는 것인데, 그건 ACM보다도 더 코딩과 유리된 부분입니다.

    제가 존경하는 분인 김민장씨도 석사까지는 코딩 실력이 유지되지만 박사가 되면 오히려 줄어들 수 있다고 경고한 바 있습니다. 알고리즘 연구해 보신 분들은 다들 공감하실 듯 합니다.

    교수님들 중에도 코드를 구체적인 프로그래밍 언어로 표현해서 빠르게 문제를 풀어내는 능력은 적을 지 몰라도, 그 기반이 되는 알고리즘을 짜내는 능력은 존경할 만한 분들도 적지 않습니다. 젊을 때는 문제를 잘 풀었더라도 나이를 드시다 보니 그렇게 된 경우도 많지요. 그렇다고 ACM 1등보다 연구 능력이 떨어진다고는 볼 수 없겠죠.

    알고리즘의 효율성은 소프트웨어를 구성하는 수많은 요소중 단 하나일 뿐이고, ACM도 거기에 도달하는 방법 중 하나일 뿐입니다. 제목의 단정성에 대해 지적하는 것은 좋지만, 너무들 목숨 걸지 맙시다.

Write your message and submit

마소 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 얘기 좀 하다보니 지면이 반이 넘어가서 뒤쪽은 조금 부실해진 느낌이 있습니다-_-...

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

Write your message and submit

까멜레오 프로젝트

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

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

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

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

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

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

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





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

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

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


  1. Favicon of http://koko8829.tistory.com BlogIcon 열이아빠

    | 2007.06.14 08:24 | PERMALINK | EDIT | REPLY |

    블로그내 데모페이지에서 구글비디오는 플레이버튼이 보이길래
    계속 화면을 클릭해버렸습니다.ㅎㅎ
    조만간 데모도 chameleo 를 통해 볼 수 있으면 좋겠네요.

  2. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.06.14 14:52 신고 | PERMALINK | EDIT |

    네. 조만간 유튜브 플레이어가 아닌 까멜레오 플레이어로 까멜레오 데모를 보여드릴 수 있도록 하겠습니다^^

  3. Favicon of http://innolab.tistory.com BlogIcon 송치형

    | 2007.06.14 09:02 | PERMALINK | EDIT | REPLY |

    동영상 UCC의 새로운 가능성이 열리는 것인가요? ^^ 서비스 오픈 기대하겠습니다~! 화이팅~!

  4. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.06.14 14:52 신고 | PERMALINK | EDIT |

    감사합니다! 공 좀 들여서 좀 더 멋진 걸 내놔야죠~

  5. Favicon of http://mate4u.com BlogIcon starplayer

    | 2007.06.14 13:03 | PERMALINK | EDIT | REPLY |

    기대중입니다. : )

  6. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.06.14 14:51 신고 | PERMALINK | EDIT |

    감사.

  7. Favicon of http://www.jayr.org BlogIcon 프로그래머 류

    | 2007.06.14 22:06 | PERMALINK | EDIT | REPLY |

    이럴수가 저의 상상력으로는 데모를 보고서도 감히 짐작이 가지 않네요. 매력적인 기회들을 재껴두고 선택하신 작품이다보니 기대가 큽니다. ^_^

  8. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.06.19 01:53 신고 | PERMALINK | EDIT |

    요건 맛뵈기^^;;

  9. Favicon of http://m1nk.tistory.com BlogIcon minku

    | 2007.06.15 03:35 | PERMALINK | EDIT | REPLY |

    기대하고 있겠습니다..^-^

  10. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.06.19 01:53 신고 | PERMALINK | EDIT |

    생유~

  11. Favicon of http://jsjang.tistory.com BlogIcon 장진성

    | 2007.06.15 17:14 | PERMALINK | EDIT | REPLY |

    개발에 박치를 가하고 있네... 꼭 대박나기를 바란다... ^^
    UCC시류에 따른 좋은 아이디어인 것 같네.
    대박나기를....^^

  12. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.06.19 01:53 신고 | PERMALINK | EDIT |

    옥희~

Write your message and submit

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

  1. Favicon of http://proxima.1manshow.co.kr BlogIcon proXima

    | 2007.05.28 03:30 | PERMALINK | EDIT | REPLY |

    저는 별 생각 없이 LALR로 하면 문제 없겠구나 싶어서 CUP을 사용했습니다.
    jflex나 CUP이나 사용해 본 것은 꽤 괜찮은 경험이었던 것 같아요.
    ANTLR 이라는 parser가 있다는 것은 처음 알았네요. 항상 배워갑니다. (--)(__)(--)

  2. hansolo

    | 2007.07.24 22:57 | PERMALINK | EDIT | REPLY |

    필자의 선동에 혹해서 ANTLR 을 썼다가 나중에 삽질한 1人 (- -);

  3. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.07.28 04:14 신고 | PERMALINK | EDIT |

    잘 해놓고서는!

  4. Huang

    | 2011.03.08 00:24 | PERMALINK | EDIT | REPLY |

    지금 보는 책에서 SQL Parser를 LL (1) 으로 구현하여 LL이 뭔가하여 구글링하다가 또다시 여기까지 왔네요 ㅎㅎ
    저번에 volatile 구글링하다가도 왔었는데 ㅎㅎ
    감좀 잡아 갑니다~!

  5. 안녕하세요

    | 2012.06.21 00:49 | PERMALINK | EDIT | REPLY |

    안녕하세요
    Left recursion과 Left factoring은 다른 개념입니다

    Left recursion은
    A -> Ab | c 인경우
    해법은
    A -> bA'
    A' -> cA' | ε

    Left factoring은
    A -> bc | bd 이런 경우입니다
    해법은
    A -> bA'
    A' -> c | d

Write your message and submit

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)이 주가 되는 실무에 일부 활용해 보려고 고민 중인데, 관련 소식을 업데이트 하겠습니다.

  1. Favicon of http://neocode.egloos.com BlogIcon 백승우

    | 2007.11.19 20:32 | PERMALINK | EDIT | REPLY |

    저도 얼마전부터 혼자 공부하고 있는데(잠시중단^^)
    너무 어렵습니다. --

  2. Favicon of http://skyul.tistory.com BlogIcon 서광열

    | 2007.11.21 01:26 | PERMALINK | EDIT |

    언제 관심 있는 분들 모아서 같이 한 번 공부해야겠습니다^^

Write your message and submit

마소 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월호가 나오면 보실 수 있습니다.


  1. Favicon of http://www.jiniya.net BlogIcon codewiz

    | 2007.05.18 23:48 | PERMALINK | EDIT | REPLY |

    늘 좋은 글 잘 읽고 있습니다.
    이번 달 연재 내용도 예고편만으로도 기대되네요. ^^

  2. Favicon of https://skyul.tistory.com BlogIcon 서광열 lambda

    | 2007.05.20 06:48 신고 | PERMALINK | EDIT |

    감사합니다^^

Write your message and submit

Haskell에 대한 오해?

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

사용자 삽입 이미지

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

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

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

Write your message and submit

함수형 언어 공헌자들.

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

음. 부러워라.

  1. Favicon of http://proxima.1manshow.co.kr BlogIcon proXima

    | 2007.05.18 21:45 | PERMALINK | EDIT | REPLY |

    아아아 lambda calculus!!! 쉽지 않네요 ㅋㅋㅋ -_-;;;

  2. 서광열

    | 2007.05.18 21:48 | PERMALINK | EDIT |

    학교 있을 때 잘 배워두도록 어디 나가서 나중에 배우려면 훨씬 힘들다 ㅋㅋ

  3. Favicon of http://mate4u.com BlogIcon futari

    | 2007.05.22 20:08 | PERMALINK | EDIT | REPLY |

    쿠쿠
    얼마전에 복도에 걸린 사진들을 주욱~ 살펴봤는데
    사실 거기 자주 지나가면서도 잘 볼 기회가 없었던 것 같아요.
    아. 이번학기는 모든 과목이 프로젝트가 있어서 참 갈수록 조여드네요 ㅋ

  4. 서광열

    | 2007.05.25 04:55 | PERMALINK | EDIT |

    옹. 열심히 하도록. 복학하고 첫 학기 아닌가? ㅋㅋ

Write your message and submit

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이라 불린답니다.
Write your message and submit

파이썬 -i 옵션

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

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

Write your message and submit

빌드와 백신

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


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


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


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


  1. Favicon of http://kaistizen.ent BlogIcon 최재훈

    | 2007.05.04 01:54 | PERMALINK | EDIT | REPLY |

    이번에 추가된 PC Tools 제품을 말씀하시는 건가요? 아니면 Norton 쪽 제품인가요? 저는 일단 PC Tools 제품에 문제가 있다는 이야기를 몇 번 듣긴 했습니다만...

  2. 서광열

    | 2007.05.04 06:02 | PERMALINK | EDIT |

    2개다 깔았는데 하나씩 확인해 보기 귀찮아서 동시에 지웠습니다. 어느쪽이 문제였는지는 확실히 모르겠네요.

  3. Favicon of http://innolab.tistory.com BlogIcon 송치형

    | 2007.05.06 07:41 | PERMALINK | EDIT | REPLY |

    좋은 글 감사합니다. ^^ 저도 요즘 Cygwin을 자주 사용하고 있는데 덕분에 함정 하나를 피해갈 수 있게 되었네요... :)

  4. Favicon of http://mediaplatform.tistory.com BlogIcon 전종환

    | 2007.05.08 13:23 | PERMALINK | EDIT | REPLY |

    삽질 했구려. ^^ 컴파일할 때도 조심조심해야 되다니 슬픈 세상이 되었네. 하하.

Write your message and submit

SKT 또 사고치다.

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

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

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

사용자 삽입 이미지

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

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

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

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

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

  1. Favicon of http://proxima.1manshow.co.kr BlogIcon proXima

    | 2007.04.15 17:28 | PERMALINK | EDIT | REPLY |

    SKT 여러모로 괘씸해요... -_-;;; 흑

  2. Favicon of http://teamblog.joinc.co.kr/minsu BlogIcon 김민수

    | 2007.04.23 11:09 | PERMALINK | EDIT | REPLY |

    전 그래서 7년간 쓰던 SKT를 버리고 LGT로 갈아탔죠. LGT가 도시에서는 똑같습니다. 좀 외곽이나 지하로 나가면 안터지긴 하는데, 전혀 불편함 못느낄 정도고 나름대로 서비스도 좋습니다. SKT때는 레인보우데이 할인정도나 쓸만했나.. 오래써도 혜택은 똑같은 SKT ..

Write your message and submit
« PREV : 1 : ··· : 3 : 4 : 5 : 6 : 7 : 8 : 9 : ··· : 13 : NEXT »