Romantic Binaries

distribute, pip

최근에 setuptools 대신 distribute를, easy_install 대신 pip를 쓰기 시작했다.

조금 설명하자면, setuptools는 Python 표준 라이브러리에 있는 distutils를 확장한 것인데, distutils는 Makefile 같은 빌드 스크립트의 Python 버전이다. Ruby의 rake나 Java의 Ant를 생각하면 된다. 표준 라이브러리에 있기 때문에 Python에서 프로젝트를 패키징하고 빌드 자동화를 하는 가장 기본적이고 표준적인 방법이라고 보면 된다. setuptools는 distutils의 확장 인터페이스를 이용해¹ 의존성 해결(dependency resolution)도 해주게 만든 것이다. 보통은 setup.py 파일을 아래처럼 작성하므로 setuptools가 설치되어 있지 않아도 빌드는 가능하다.

try:
    from setuptools import setup
except ImportError:
    from distutils.core import setup

distribute는 setuptools를 대체하기 위해 리팩토링한 버전이다. 사실 setuptools의 차세대 대안이라고들 말해서 쓰긴 하지만 나도 정확히 어떤 잇점이 있는지는 모른다. 다만 요즘 여러 패키지들이 distribute로 패키징을 하다보니까 가끔 setuptools에서 설치되지 않는 경우가 있어서 설치하게 되었다. distribute의 가장 큰 목표가 setuptools를 완전히 대체하는 것이기 때문에 저게 설치되면 setuptools를 완전히 갈아치워서 import setuptools를 해도 실제로는 import distribute as setuptools한 것처럼 작동한다. setuptools와의 호환성도 유지하지만 distribute에만 있는 기능을 쓴다면 제대로 setuptools만으로는 당연히 제대로 설치되지 않는다. 그리고 가끔 의존성에 아예 distribute를 넣어두는 패키지가 있어서, 그걸 설치하면서 쥐도 새도 모르게 설치되기 쉬운게 바로 distribute라고 할 수 있겠다.

setuptools나 distribute는 정확히 말해서 의존성의 전체 목록과 설치 순서를 계산해주며, 실제로 의존하는 패키지들을 PyPI에서 다운로드하고 순서대로 설치하는 것은 easy_install 명령어가 구현한다. 다만 easy_install 명령어가 setuptools 패키지를 설치하면 생기기 때문에 보통 setuptools가 easy_install이라고 기억하는 사람도 적지 않다. pip는 easy_install 명령어의 차세대 대안이다. 이건 라이브러리가 아니라 프론트엔드이기 때문에 명령어의 하위호환성을 갖는 것은 아니며, 더 나은 인터페이스를 제공하기 위해 중간 명령어를 추가했다. 예를 들어 easy_install SQLAlchemy라고 쓰던 것을 pip install SQLAlchemy처럼 쓰게 한 것이다(그래도 글자수는 더 적다). 눈에 띄는 가장 큰 개선점으로 두 개가 있는데:

• 설치했던 패키지를 uninstall 명령어로 쉽게 삭제할 수 있다.
• 일단 의존하는 모든 패키지를 다운로드를 받고 나서 설치한다. 따라서 설치하다가 중간에 네트워크 문제로 중단되더라도 일부만 설치되는 일이 없다.

pip는 distribute가 나오기 전에 만들어진 것이고, easy_install만을 대체하기 위해 만들어졌으므로 setuptools와 pip를 함께 쓰는 경우도 많다. 물론 반대로 distribute를 설치해서 easy_install 명령을 여전히 사용하는 경우도 있다. 내가 바로 얼마 전까지distribute와 easy_install을 함께 사용하다가 최근부터 pip를 쓰기 시작했는데, 아무래도 pip는 프론트엔드이기 때문에 사용자로서 개선되었다는 느낌을 더 강하게 받는 것은 distribute보다는 pip인 것 같다.

팀 IRC

아주 큰 집단이거나, 혹은 함께 있는 시간이 적은 팀에서 소통하는 방법 중 하나가 아마 네이트온 같은 IM일 것이다. 하지만 나는 IM보다는 IRC를 더 추천한다. 여러 이유가 있는데, 한번 적어보겠다. (IM과 IRC가 대충 어떤 건지는 안다고 가정하고 글을 쓴다.)

셋 이상이서 대화

MSN이나 네이트온 등의 IM에도 초대 기능이 있어서, 셋 이상이서 대화하는 것이 가능하다. 하지만 IM은 직접 초대하기 전까지는 단 둘만의 대화창이고, 직접 IM에서 누군가에게 먼저 말을 건다는 메타포가 부담이 있다. 그에 비해 IRC는 원래 채널이 존재하고, 그 채널에 들어가기만 하면 된다. 컴퓨터를 킨 사람은 그냥 IRC 채널에 들어온다. 원래 그 채널은 여럿이서 대화하는 곳이니 “말을 건다”는 부담은 없다. 오히려 “나 말고 다들 있다는 그 채널”에 나도 들어가는 것이다.

쉽게 생각해 항상 친구들이 놀고 있는 놀이터에 간다고 생각하면 된다. 그에 비해 IM은 친구네 집에 불쑥 찾아가는 것에 가깝다.

야간개발팀 같은 경우 멤버 전원이 IRC 채널에 상주하고 있다. (주말에는 잘 안들어오는 멤버도 있긴 하지만, 평일엔 다들 있다.)

로그

팀에게 유리하게 작용하는 IRC의 또다른 특징은 로그라고 할 수 있다. 약간의 설정을 통해 (봇 등을 마련해서) 로그를 기록하게 하면 누군가가 없던 시간에 다른 사람들이 어떤 대화를 했는지 알 수 있다. 사람이 많아질수록 모두 모이기 힘든 것을 감안하면 꽤나 좋은 점이라고 할 수 있다.

야간개발팀의 경우 인트라넷에 아예 IRC 로그 메뉴가 있고, 1년전 기록도 볼 수 있고, 아예 특정 키워드로 검색도 가능하다.

작업 방해

IM은 대화창이 한 번 열리면, 그 뒤에 상대방이 말을 한 번이라도 보내면 내가 확인할 때까지 작업표시줄 등에서 번쩍거리며 관심을 요구한다. 그래서 작업에 집중하기 힘든 경우가 많고, 힘들게 집중했는데 누가 말을 걸어서 방해를 받는 경우도 있다. IRC는 기본적으로 다대다 소통 방식이기 때문에, 누군가가 하는 말이 꼭 내게 하는 소리라고는 볼 수 없으므로 대개의 IRC 클라이언트는 그런 걸로 사용자에게 주의를 요구하지 않게 되어있다.

물론 대화 내용 중에 자신의 이름이 언급되면 IRC 클라이언트가 주의를 요구하긴 한다. IRC를 많이 쓰는 사람에겐 아주 익숙한 것인데, 대부분의 IRC 클라이언트가 이 “하이라이트” 기능을 제공하고 하이라이트를 쉽게 할 수 있도록 “사용자 이름 자동완성” 기능도 제공한다. 이를테면 대화창에서 “홍”까지만 쓰고 탭 키 따위를 누르면 “홍민희, ” 혹은 “홍민희: ”로 펼쳐지는 식이다. (내용 중간이라면 쉼표나 콜론 없이 이름만 완성된다.) 이렇게 말을 걸면 불리운 사람의 IRC 클라이언트는 사용자에게 “네 얘기를 하고 있다”라는 뜻에서 사용자에게 주의를 준다.

Twitter가 잘 엔지니어링되지 못한 IRC 클론이라고 말하는 사람도 있는데, 실제로 이런 IRC 사용 패턴은 Twitter의 언급(mention) 기능에 영향을 준 것 같다. 사실 앞서 말한 IRC의 특징들을 가만히 보고 있으면 결국 Yammer 같은 기업용 마이크로블로깅 서비스가 해주는 일을 대부분 해준다는 것도 알 수 있다.

“하이라이트” 외에 채팅방에서의 “귓속말”이라고 할 수 있는 “쿼리”라는 것도 IRC에 있다. 이 “쿼리”로 하는 대화는 일반 IM과 비슷하게 작동하는 편이다. 그러니까, 대부분의 IRC 클라이언트가 쿼리로 오가는 말에는 사용자에게 계속 주의를 요구한다.

IRC를 시작하려면?

IRC를 시작하는 것은 어찌보면 조금 번거롭기도 하고, 쉽기도 하다. 적당한 IRC 클라이언트를 골라 적당한 IRC 네트워크에 채널을 만들어서 들어가면 된다. 하지만 여력이 된다면 직접 IRC 네트워크 서버를 구축해서 운영하는 편이 좋긴 한다.

“적당한 IRC 클라이언트”라는 말이 생각보다 어려운데, Mac이라면 엄청나게 심플한 LimeChat을 추천하고, Linux라면 대부분의 배포본에서 패키지로 제공되어 설치하기 쉬운 XChat을 권한다. 문제는 Windows인데 대부분 mIRC를 사용하는 모양이지만 나는 추천하지 않는 편이다. 주변 몇 사람들은 IRC 클라이언트로 Opera 브라우저를 추천하기도 한다.¹ 이도저도 싫다면 랜덤여신 님이 만든 인클 웹 IRC를 추천한다. 워낙 다른 Windows용 IRC 클라이언트들이 UI가 후져서 이게 제일 깔끔한 편이다. 게다가 Google Chrome의 web application shortcuts 기능을 쓰면 일반 애플리케이션처럼 사용할 수도 있다.

“적당한 IRC 네트워크”로는 주저없이 오징어 IRC 네트워크를 추천한다. 비교적 가장 최근에 구축된 네트워크이기 때문에 EUC-KR을 사용해야 하는 등의 레거시가 없다(UTF-8을 쓴다).

Java만 하는 사람들은 진짜 Java만 한다. Java는 한번 제대로 하려고 마음 먹으면 너무 배울 것이 많기 때문에 더 그렇다. Java밖에 안 하니까 우물안 개구리가 되기 십상이다.

Java에 배울 것이 많다는 것이 Java의 심오함을 대변하는 것은 아니다. 사실은 그 반대다. Java에는 Java 자체가 해결해주지 못하는 문제들이 너무 많기 때문에 디자인 패턴부터 시작해서 온갖 workaround가 판을 치기 때문에 배울 것이 더 많아진다. 정작 Java에 몰두한 사람들은 그것들이 workaround가 아니라 굉장히 우아한 해결책이라고 느끼는 것이 더 큰 문제다. 그 사람들이 workaround를 우아한 해결책이라고 믿는 이유는 그것들이 Java의 문제를 해결하는 것이 아니라, 프로그래밍 본질적인 문제를 해결하는 것이라고 착각하는 경우가 많기 때문이다. 예를 들어 디자인 패턴의 꽤 많은 전략이 다른 언어에서는 필요하지 않은 경우가 많다. 하지만 Java만 하던 사람은 Java 외의 다른 언어를 진지하게 배워볼 시간이 없었기 때문에¹ Java가 갖는 문제를 프로그래밍 본질의 문제로 보기 쉽다. 그렇게 Java 진영에서 우아한 해결책들로 알려진 workaround를 하루하루 체득해가며 세월을 보내는 것이다.

Hibernate가 좋은 ORM이라고 칭찬하는 글을 보며 문득 저 사람에게 SQLAlchemy를 보여주면 뭐라고 할지 궁금하다는 생각이 들어 이런 글을 쓴다.