소프트웨어는 녹이 슨다

이상한 얘기이지만 소프트웨어는 가만 냅두면 녹이 슨다. 소프트웨어 개발자가 이런 얘기를 하다니 정말 전문성이 떨어지는 느낌이다. 하지만 소프트웨어가 냅두면 녹이 슨다고 하면 오히려 소프트웨어 개발자들이야 말로 강하게 동감할 것이다.

소프트웨어는 언제나 망가져 있다. 수사적 표현이 아니라, 기술적으로 그러하다. 소프트웨어는 다양한 방법으로 망가질 수 있는데 이는 매우 당연한 것이다. 왜냐하면 소프트웨어는 완전히 망가져 있는 상태에서 약간 덜 망가진 상태로 ‘수리되면서 태어나기’ 때문이다. 좀더 정확히 말하면, 원래 자연 상태에서는 소프트웨어라는 것이 있지도 않으며 이것이 내가 ‘완전히 망가진 상태’라고 하는 것이다. 이것이 자연의 디폴트 상태라고 보면 모든 소프트웨어가 언제나 상당히 망가져 있다는 주장은 크게 이상할 것도 없는 얘기다.

언젠가 ‘가만히 냅뒀는데 왜 서버가 죽어요?’라는 질문도 들었다. 나는 ‘가만히 냅두니까 죽은 겁니다’라고 대답해 주었다. 스스로 코드를 변경시키는 소프트웨어는 거의 없다. 대부분의 코드는 사람이 직접 짜는 것이다. 소프트웨어는 대량 복제되지만 코드는 대량 생산되지는 않는다. 소프트웨어는 변하지 않아도 그걸 쓰는 사람들은 변한다.

내 소프트웨어는 변하지 않았어도 다른 사람들이 만든 소프트웨어는 자꾸 바뀐다. 소프트웨어 세계는 상호운용성이 중요하므로 가만히 있으면 소프트웨어는 고장난다. 자고 일어날 때마다 한국어 억양이 계속 바뀐다고 생각해보라. 한 달이 지났더니 나만 서울말을 하고 다른 사람들은 모두 평양말을 한다. 두 달 지났더니 연변말을 한다. 일 년이 지났더니 일본어 같이 되었다. 나만 서울말을 한다. 소프트웨어 세상은 그런 식이다. 다만 서울말이 일본어가 된다고 더 좋아질 것도 없는 반면 소프트웨어 세상의 말, 프로그램 인터페이스는 조금씩 좋아진다. 그걸 잘 따라가면 적은 말로도 많은 것을 더 정확히 할 수 있게 된다.

소프트웨어가 바뀌지 않아도, 소프트웨어의 어디가 망가져 있는지에 대한 정보 역시 업데이트된다. 시간이 지나면 알려진 결함이 쌓인다. 그때그때 얼른 고쳐주지 않으면 마치 사람이 나이가 들며 병이 드는 것마냥 소프트웨어가 버그가 많아져 쓸 수 없게 되는 것을 볼 수 있다.

홀연히 사라졌던 whytheluckystiff는 이렇게 말한 바 있다: “프로그래밍은 죄다 부질없는 짓이다. 당신의 작품이 1년 뒤 더 우월한 것에 의해 대체되는 것을 보게 된다. 좀더 지나면 아예 돌아가지도 않는다.”

나는 이렇게 생각한다. 소프트웨어가 프로그래밍해서 스스로의 코드를 개선할 수 있게 되기 전까지는, 소프트웨어는 누군가가 돌보지 않으면 금세 시들게 된다. 그렇다면 내가 만든 소프트웨어에게 긴 생명을 주고 싶다면 어떻게 해야 할까? 나 말고도 다른 누군가가 고칠 수 있게 해야 한다. 내 소프트웨어가 가치가 있다면 다른 누군가도 쓸 것이다. 내 소프트웨어가 가치가 있다면 망가졌을 때 다른 사람도 고치고 싶어할 것이다. 다른 사람이 고치고 싶어할 때 고칠 수 있게 허락해야 한다. 그렇게 소프트웨어는 약간 더 좋아지고 조금 더 시간을 번다.

1주 전
Apache Libcloud

최근 libcloud를 써볼 일이 있었다. 많이 써보지는 않았지만 여러모로 좋은 라이브러리라는 생각이 들어 소개해본다.

Libcloud는 boto와 비슷한 기능을 공유하는 라이브러리인데, boto가 Amazon Web Services API의 클라이언트 라이브러리라면, libcloud는 AWS 외에도 Microsoft Azure, Google Cloud Compute 등 다양한 업체의 서비스도 함께 지원한다는 점이 가장 큰 차이점이라고 할 수 있다. 어차피 각 업체마다 대응되는 같은 용도의 서비스가 있는데, 크게 EC2 같은 가상화 인스턴스 서비스 (그야말로 클라우드의 primitive라고 할 수 있는…), EBS와 같이 거기서 쓸 블록 스토리지 서비스, S3와 같은 오브젝트 스토리지 서비스, ELB 같은 로드 밸런서 서비스, Route 53 같은 DNS 서비스 등이다.

그래서 가령 libcloud를 이용해서 EC2 인스턴스를 새로 만들고, 만들었던 인스턴스를 삭제하고, S3에 이미지를 올리는 스크립트를 짜고 나서, 맨 위쪽에서 드라이버 종류만 AWS에서 다른 업체로 바꾸면 그대로 돌아간다. (실제로는 각 프로바이더마다 확장하는 기능이 존재하는데, 네이밍 컨벤션에 따라 그런 함수나 인자명은 앞에 ex_가 붙는다.)

Libcloud는 현재 25 종류 이상의 드라이버를 제공하고 있고, 이 안에는 심지어 KT ucloud까지 포함되어 있다. 강대명 씨가 드라이버 코드를 기여했다고 한다. 나는 앞으로도 쓸 일이 없겠지만… 전략적으로 돈이 없을 때 ucloud를 쓰다가 사업이 번창하여 돈을 많이 벌면 AWS 등으로 옮길 때 유용하게 쓸 수 있을 것이다. ㅋㅎㅎ

이 외에도 boto보다 libcloud가 더 나은 점이 많다.

  • API가 boto보다 더 깔끔하고 쓰기 쉽게 되어 있다. 여러 클라우드 서비스를 오갈 일이 없이, 그냥 AWS만 쓴다고 해도 boto의 대안으로서 나쁘지 않다.
  • Python 2에서만 돌아가는 boto와 달리 Python 3에서도 아주 잘 돌아간다.
  • 더미 드라이버를 제공하기 때문에 단위 테스트 짜기가 훨씬 쉽다. boto를 쓰면 mock을 만들거나, 아예 libcloud가 해주는 그런 레이어링을 내 애플리케이션 코드에서 만들어야 하는데 이러다가 풀고자 하는 문제에 집중을 못하게 된다.

물론 아직 boto를 써야만 하는 이유도 있다. 가령 SQS 같이 AWS에서 제공하지만 다른 업체들에서는 일반적으로 제공하지 않는 종류의 제품군은 libcloud로 커버가 안된다. 그런 것들을 boto를 이용해서 쓰고 있었다면 당장 libcloud를 쓰기에는 기능이 부족할 것이다.

This was posted 2주 전. It has 8 notes.
Composable IT

어째서 Atom이나 Sublime Text가 (Emacs는 몰라도) Vim을 대체할 수는 없는지에 대한 글을 페이스북에 링크했다가 우연히 매우 좋은 발표 자료를 알게 되었다. 2007년 이맘때에 신재호(netj) 님이 발표한 자료이다. 5년도 지난 자료이지만 내용의 탁월함은 어디로 가지 않는다. (2007년 3월은 Chrome도 iPhone도 세상에 나오기 전이다.) 링크로 때우는 글은 블로그에 잘 안 쓰고 페이스북에 올리는데, 이 자료는 꼭 여러 사람들에게 보여주고 싶다는 마음에 여기에 올린다.

Composable IT
“netj와 함께 고민해보는 우리 IT의 미래”

IT 업계에 있는 사람들이라면 모두들 한번씩 보고 음미해 보았으면 좋겠다.

우리가 만드려고 하는 놀라운 아이폰 앱은 과연 composable한가? 1년 뒤에는 사람들이 그 앱을 훨씬 더 능숙하게 쓸 수 있게 해주는가(learning curve v. learning gap)? 이 바닥에서 우리가 만드는 것들이 함께 쓰이기보다는 서로 충돌하고 경쟁하게 되는 이유가 무엇일까?

This was posted 1달 전. It has 24 notes.

왜 그 버튼은 폭을 줄이는 것조차 힘든가

원문 글 이후에 프로그래머 입장에서의 여러 변주가 있었는데, 나야 동감하지만 프로그래머가 아닌 사람도 저런 변주에 동감할까 하는 생각이 든다. 그래서 단순하고 거친 비유를 하나 들어볼까 한다.

어떤 플랫폼(iOS든, Android든) 위에서의 GUI 요소들이라는 것은 일종의 기성품 같은 것이다. 어떤 플랫폼은 완전히 조립되어 있는 가구처럼 되어 있기도 하고, 어떤 플랫폼은 IKEA 제품 수준으로 조립 가능하게 되어 있지만 그렇다고 해도 그러한 요소들은 어떻게 조립되어야 하는지에 대한 ‘의도’가 사전에 존재한다. IKEA에서 침대를 구입하면 오는 부품들을 조립하여 어떻게든 의자 모양이 나게 얹혀둘 수는 있겠지만 제대로 된 의자 기능을 하게 만들기는 상당히 어려울 것이다.

GUI 애플리케이션이라는 것은 디자이너 입장에서 보기와는 달리 조각 같은 것이라기 보다는 부품 공장에서 파는 기성품들 가운데 적절한 것들을 골라서 사온 다음 약간만 다듬어 조립하는 일에 가깝다. 기껏 사온 부품을 다른 모양을 내기 위해 나무를 깎기 시작하면 부품을 사온 의미가 사라진다. 내가 처음부터 통나무를 깎는 게 나을 정도로 비용이 올라가는 것이다.

자, 그렇다면 왜 그 버튼은 폭을 줄이는 것조차 힘든가? 여러분이 5.3인치 폭의 iPad mini를 고르거나 9.4인치 폭의 iPad Air를 고를 수는 있지만 7인치 폭의 iPad를 만들어내는 것은 힘든 것과 같은 이유에서 그렇다. 7인치 폭의 iPad가 필요하다면 나는 iPad를 분해해서 모든 것을 처음부터 다시 만들어야 한다. 5.3인치와 9.4인치 중에서 iPad를 골라 주문하면 받기까지 일주일이 채 안 걸리지만 7인치 폭의 iPad를 만들기 위해서는 일단 전자공학을 공부하기 위해 4년 이상의 기간을 예상해야 한다.

그래서 이 글의 결론이 무엇이냐 하면, 버튼 폭을 줄이라는 요구를 하지 말라는 것은 결코 아니고, 다만 디자이너에게도 다음의 경구는 유용하지 않겠냐는 것이다.

If you optimize everything, you will always be unhappy.

Donald E. Knuth

1달 전
Earth Reader

Google Reader 망한다는 소식이 뜬지 얼마 되지 않았을 때, RSS 리더는 원래 데스크탑 앱이었다는 글을 쓴 적이 있습니다. 그 때 생각만 해두고 실제로 실행에 옮기지는 못하고 있다가, Google Reader 망한지 한참 지나서야 뒷북치며 RSS 리더를 직접 만들게 되었습니다.

이름은 Earth Reader입니다. 구름(클라우드)과 반대되는 느낌의 이름을 찾다가 땅이 좋겠다고 생각해서 지었습니다. 지구 리더가 아니라 땅 리더인 셈입니다.

Earth Reader의 목표는 지난번에 썼던 글의 동기를 거의 그대로 물려받았습니다. 바로 구독자의 모든 데이터(읽었던 모든 글들, 읽은 표시, 별표 등)에 대한 제어권을 되찾기 위해, 특정 업체의 중앙집중적인 서비스에 의존하지 않고 뉴스를 구독하자는 것입니다. 그러기 위해서 다음과 같은 몇가지 세부적인 하위 목표가 생겼습니다.

  • 모든 데이터는 구독자 자신에 의해 관리될 수 있어야 합니다. 데이터를 파기하는 것도, 유지하는 것도 구독자의 제어 아래 있어야 합니다. 그러기 위해 모든 데이터를 손에 잡히는 모습으로, 파일 시스템 위에 저장합니다.
  • 그러면서도 기존 서비스형 뉴스 리더 서비스가 제공하던 가장 큰 장점, 바로 다양한 기기 간에 일관적인 데이터를 보여주는 것을 그대로 취합니다.
  • 데이터 형식은 기존에 이미 널리 사용되던 기술적인 표준을 최대한 따르고자 합니다. 나아가, 구현 기술 역시 오픈 소스로 고쳐서 쓸 수 있도록 합니다.
  • 가능하면 여러 플랫폼에서 네이티브 앱의 형태로 다가가려 합니다. (저희는 Transmission의 크로스플랫폼 전략을 따르고 싶습니다.)

사실 위의 목표 중 저희가 가장 중요하다고 생각했던 몇가지는 기본적인 수준으로 달성을 했습니다. Earth Reader는 사실 데이터를 어떻게 동기화할지 고려하지 않고, 동기화 기능을 직접 제공하지도 않습니다. 하지만 원한다면 Earth Reader 데이터 폴더(저희는 ‘저장소’라고 부릅니다)를 Dropbox 폴더 안쪽에 두거나, 혹은 Google Drive, 아니면 다음 클라우드 폴더 안쪽에 두고 쓰실 수 있습니다. 컴퓨터에 익숙한 분이면 아예 직접 rsync를 걸어도 됩니다. 중요한 것은, Earth Reader는 서로 다른 기기에서 동시에 같은 저장소에 접근하고 수정해도 데이터 정합성이 항상 유지되도록 고려되어 있다는 점입니다.

반면 여러 플랫폼에서 네이티브 앱 형태로 만들겠다는 목표는 아직 큰 진전이 없습니다. 오늘 소개하는 Earth Reader의 첫 버전도 사실은 (저희의 목표가 무색하게도) 웹 버전입니다. 하지만 여러 앱 사이에서 공통으로 사용될 기술은 libearth라는 공용 라이브러리 형태로 따로 제작되고 있으므로 머지 않아 데스크탑 앱 형태로도 모습을 보여드릴 수 있을 것 같습니다.

웹 버전은 기본적으로 개인 서버가 있는 분들, 즉 코딩을 할 줄 알고 컴퓨터를 꽤 익숙하게 다루시는 분들을 대상으로 한 첫번째 구현입니다. Earth Reader는 오픈 소스이므로 초기 사용자들이 직접 기능 제안도 하고 기여도 하길 원했기 때문에 나쁜 시작은 아니라고 위안하고 있습니다.

설치하려면 일단 Python이 필요합니다. 최소 Python 2.6부터 Python 3.3 버전까지 쓸 수 있습니다. (아쉽게도 Python 3.0부터 Python 3.2까지는 쓸 수 없습니다.) 웹 버전은 현재 PyPI에 올라가 있으므로 pip를 써서 설치할 수 있습니다.

$ pip install EarthReader-Web

다 설치하고 나면 earthreader라는 명령어가 생깁니다. earthreader server 명령을 써서 서버를 실행시킬 수 있습니다. 이 때 인자로 데이터를 저장할 저장소 경로를 지정해야 합니다. 존재하지 않는 경로면 알아서 디렉토리를 생성합니다.

$ earthreader server /path/to/repository/dir
$ earthreader server -p 8080 /path/to/repository/dir  # listen to 8080 port

브라우저를 통해 서버에 접근하면 아무 구독도 포함되어 있지 않은 빈 목록이 나옵니다. 그 상태에서 구독을 추가해서 사용해보실 수 있습니다. (아직 디자인이 안 되어 있습니다. 다소 못 생겼어도 이해해주세요…)

Python 웹 개발에 익숙하신 분들은 WSGI 서버를 직접 운영하는 방법도 있으니 참고해주세요.

혹시 개발에 적극적으로 참여하고 싶으신 분들, 혹은 사용하는데 문제가 생겨서 질문이 필요한 분들은 웹용 Earth Reader 이슈 트래커(눈에 보이는 UI 관련), libearth 이슈 트래커(로직 관련), 메일링 리스트(earthreader@librelist.com), 혹은 IRC 대화방(오징어 네트워크 #earthreader 채널)을 찾아주세요.

소스 코드는 GitHub 저장소에서 보실 수 있습니다:

Earth Reader for Web
https://github.com/earthreader/web
libearth
https://github.com/earthreader/libearth

Google Reader 망하기 전에 제가 Google Reader에 있는 모든 데이터를 다 백업하는 스크립트를 공개한 적이 있습니다. 그때 백업한 데이터를 Earth Reader로 그대로 옮길 수 있습니다. 스크립트 저장소에 있는 toearth.py 스크립트를 쓰면 백업한 데이터를 Earth Reader 저장소로 만들어줍니다.

This was posted 3달 전. It has 16 notes.