기술을 이해하는 데에는 그 기술의 동기가 중요하다. 정확히는, 그 기술을 ‘이상하게’ 오용하지 않기 위해서는 동기를 이해해야 한다.

이상적으로는 기술을 이해하는 데에도 기술의 역사에 대한 지식이 동반되어야 하겠지만, 현실적으로는 우리에게는 그러한 것까지 일일히 기억할 만큼의 여유가 없다. 우리가 습득해야 하는 기술은 일터에서 허겁지겁 주워삼키는 것들이다.

기술 문서를 쓸 때도 이와 같은 갈등에 놓인다. 대여섯 문단을 할애하여 이 기술의 배경에 대해 다룰 것인가? 아니면 와닿지 않는 한 문장으로 동기에 대한 설명을 퉁치고, 곧바로 기술의 작동 방식에 대한 서술로 넘어갈 것인가?

기술 문서를 읽는 입장에서 보자면, 기술의 배경에 대해 길게 서술한 내용은 내가 그 기술에 개인적인 관심을 두고 있지 않은 이상, 그러니까 당장 오늘 저녁까지 어떤 것을 구현해내기 위한 과정으로 문서를 읽고 있는 경우, 잘 눈에 들어오지 않는다. ‘허겁지겁’ 주워삼킨다는 것은 이런 뜻이다. “복사해서 붙여넣을 예제 코드가 필요하다.”

여러 해 기술 문서를 쓰는 것에 대해 고민해왔는데, 그래서 이 문제에 대한 해결책을 찾았냐고 하면 여전히 해결책이 묘연한 상태다. 다만 한가지 노하우는 공유할 수 있을 것 같다.

기술 문서를 자랑 내지는 광고를 한다는 태도로 쓰면 좋다. 문서를 어떤 방향으로 작성해야 할지 실마리가 잘 풀린다. 어떤 내용이 필요 없는지도 비교적 잘 보인다. 다만, 애초에 자랑이나 광고를 할 마음이 들지 않을 수도 있다. 그렇다면 그 기술의 가치에 대해 고민해볼 필요가 있다. 그런 마음이 든다고 해서 항상 가치가 없다는 얘기는 아니지만, 정말 가치가 없어서 그런 생각이 들 때도 분명 있기 때문이다.

1주 전
Geofront: 소규모 팀을 위한 SSH 키 관리 서비스

스포카 개발팀에서 SSH 키를 편하게 관리하기 위해 만든 오픈 소스 소프트웨어인 Geofront를 소개합니다.

스포카에 들어간 뒤에 나도 처음으로 기술 블로그에 글을 써봤다. Geofront는 만들어서 실제로 개발팀에서 써온 지는 3개월 정도 된 소프트웨어이다. 처음부터 오픈 소스로 공개할 것을 염두로 만들기는 했지만, 남들이 쓰지 않더라도 팀 내에서 유용하게 쓰고 있으니 이미 수고에 대한 본전은 뽑았다고 생각한다.

저 글에서 쓰지 못한 부분을 주절거려보자면:

  • Python 2와 3 양쪽에서 호환되는 코드는 이전에도 계속 써왔지만, Python 3 전용으로, Python 3에만 있는 기능들을 마음껏 활용해보며 프로젝트를 진행한 것은 이게 처음이었다. Python 3는 이제 공개 라이브러리를 만드는 것이 아니라면, 애플리케이션 수준에서는 충분히 도입해도 문제가 없겠다는 확신이 들었다. 써야 했던 라이브러리(Paramiko, Werkzeug, Flask, Apache Libcloud, Waitress) 가운데 어떤 것도 Python 3 지원 안 하는 게 없었다. 여담으로 최근에는 boto마저 Python 3를 지원하기 시작했다.

  • 기업용 오픈 소스 라이센스로 GPL 계열이 부적합하다는 소리들을 하곤 하지만 반만 맞는 얘기다. MIT/BSD 등의 비감염적 라이센스는 기업이 해당 프로젝트를 쓰는 입장일 때야 좋지만, 반대로 기업이 그 프로젝트를 공개하는 입장일 때는 딱히 좋을 게 없다. 오히려 GPL로 프로젝트를 공개하면 다른 곳에서 그 소프트웨어를 고쳐서 쓸 때 개선한 부분을 공개시키는 강제성이 생긴다는 잇점이 있다.

  • 프로젝트 이름의 유래는 알만한 사람들은 아는 바로 그 작품에 나오는 지오프론트가 맞다. 딱히 비유적인 의도는 없고, 원래 프로젝트 이름으로 그 작품에 나오는 것들을 종종 써왔다. (Asuka라던가…)

This was posted 2주 전. It has 12 notes.

오픈 소스의 경계 설정 문제

우연히 오픈 소스를 자처하는 한 프로젝트의 라이센스 설정 이슈를 보고, 오래 전부터 해온 생각이 다시 떠올라 이참에 글로 쓴다.

오픈 소스는 무엇이고, 또 무엇이 아닌가? 경계 설정 문제는 언제나 ‘무엇인지’와 ‘무엇이 아닌지’ 양쪽이 동시에 중요하지만, 대개 후자는 덜 다뤄지기 때문에 여러 개념들은 그 경계가 오해되곤 한다. 과학도 그렇고, 오픈 소스도 그렇다.

내가 보기에는 (최소한 우리나라의 경우) 많은 개발자들이 오픈 소스에 대해 몇가지 명백한 오해를 하고 있으며, 이는 개발자의 기량과 무관하게 나타나는 데다, 심지어 스스로 오픈 소스 전문가라고 자처하는 사람들 중에서도 오해가 흔하다. 어떤 오해가 있을까?

제로보드 4는 소스 코드 형태로 배포되는 무료 소프트웨어였다. 하지만 제로보드 4는 오픈 소스가 아니었다. 반면 비슷한 다른 소프트웨어인 Drupal이나 WordPress는 오픈 소스다. 대체 둘 사이에는 어떤 차이가 있는가?

GNU의 “자유 소프트웨어란 무엇인가?”라는 글은 다음과 같은 내용을 담고 있다 (강조는 내가 했음):

“자유 소프트웨어”는 사용자가 소프트웨어를 실행시키거나 이를 복제 및 배포할 수 있는 자유와 함께 소스 코드에 대한 접근을 통해서 이를 학습하고 수정, 개선시킬 수 있는 원천적인 자유까지를 모두 포괄하는 것입니다.

따라서, 간략히 말하면 다음과 같은 4가지 종류의 자유를 내포한다고 할 수 있습니다.

  • 프로그램을 어떠한 목적을 위해서도 실행할 수 있는 자유 (자유 0).
  • 프로그램의 작동 원리를 연구하고 이를 자신의 필요에 맞게 변경시킬 수 있는 자유 (자유 1). 이러한 자유를 위해서는 소스 코드에 대한 접근이 선행되어야 합니다.
  • 이웃을 돕기 위해서 프로그램을 복제하고 배포할 수 있는 자유 (자유 2).
  • 프로그램을 향상시키고 이를 공동체 전체의 이익을 위해서 다시 환원시킬 수 있는 자유 (자유 3). 이러한 자유를 위해서는 소스 코드에 대한 접근이 선행되어야 합니다.

사실 내가 강조한 부분들은 한국에서 오픈 소스에 대해 이야기할 때 자주 무시되는 것들이다. 나는 몇년 전부터, 개발자들조차 오픈 소스가 무엇인지 말해보라고 하면 다음과 같은 오해가 포함된 정의를 내놓는 것을 경험해왔다:

“소스 코드를 공개한 무료 소프트웨어”

확실히, 위와 같은 널리 오해되는 정의에 따르면 제로보드 4는 오픈 소스 소프트웨어다. 하지만 오픈 소스는 실제로 그러한 것이 아니며, 위 정의에는 크게 두 가지 부분이 잘못되었다.

  • 소스 코드 공개
  • 무료

오픈 소스는 소프트웨어 개발에 있어서 어떤 의미를 지닐까? 바로 남이 만든 것도 내가 고칠 수 있고, 내가 만든 것도 남이 고칠 수 있다는 데에 있다. 즉, 오픈 소스 소프트웨어는 전적으로 누구나 고칠 수 있느냐가 중요하다.

여기서 ‘고칠 수 있다’는 말에는 기술적인 부분과 법/권리적인 뜻이 함께 들어있다.

소스 코드에 대한 접근은 소프트웨어를 고치려면 현실적으로 필요하기 때문에 생겨난 것이다. 소스 코드 없이도 소프트웨어를 쉽게 고칠 수 있다면 오픈 소스는 소스 코드에 대해서는 어떠한 말도 하지 않았을 것이다. (연습 문제: 소스 코드긴 소스 코드인데 난독화된 소스 코드는 오픈 소스에 부합할까?) 이것이 ‘고칠 수 있다’의 기술적인 부분이다. 이것이 인용한 글에서 말하는 자유 1이다.

그렇다면 법/권리적인 부분은 무엇일까? 기술적으로 소프트웨어를 쉽게 고칠 수 있다고 해도, 저작권자가 저작물을 고치는 것을 허락해야 한다. 이것이 바로 오픈 소스 라이센스들(GPL, MIT 라이센스, BSD 라이센스, 아파치 라이센스…)이 생겨난 동기다.

고칠 수 있기만 하면 될까? 그렇지 않다. 오픈 소스에서 말하는 ‘고칠 수 있다’는 말은 ‘고쳐서 다시 퍼뜨릴 수 있다’는 얘기이다. 남이 만든 소프트웨어를 내가 고쳐서, 원한다면 다시 배포할 수 있어야 한다. 내가 만든 소프트웨어도 마찬가지로, 남이 고쳐서, 원한다면 남의 손으로도 배포할 수 있어야 한다. 이 부분이 인용한 글에서 말하는 자유 3이다.

제로보드 4는 소스 코드에 기술적으로는 접근할 수 있었지만, 라이센스는 명백하게 수정 후 재배포를 금지하고 있었다. 이래서는 오픈 소스 소프트웨어라고 볼 수 없다.

흔히 오해되는 다른 한 가지는, 오픈 소스는 무료여야 한다는 것이다. 하지만 오픈 소스는 위에서 인용한 바와 같이 “어떠한 목적을 위해서도” 사용할 수 있어야 하며, 이는 상업적으로도 사용 가능해야 한다는 점을 뜻한다. 이 부분이 앞서 인용한 내용에서 말하는 자유 0에 해당한다. 같은 글에서는 이런 내용도 나온다.

GNU 소프트웨어는 유료로 구입할 수도 있고 무료로 얻을 수도 있습니다. 그러나 어떠한 방법으로 소프트웨어를 구했던 간에 여러분은 해당 프로그램에 대한 복제와 개작의 자유를 항상 갖게 됩니다.

예를 들어, 내가 어떤 소프트웨어를 만들어서 GPLv3 라이센스를 적용한 뒤 한 카피에 만원씩 해서 팔더라도, 실제로 돈을 지불한 고객에게 소스 코드와 그것을 수정해서 재배포할 권리만 허락한다면 오픈 소스 소프트웨어라고 할 수 있다.


오픈 소스가 무엇인지에 대한 명확한 정의는 OSI 웹사이트에서 볼 수 있다. 그러나 그 정의를 읽고서 소프트웨어가 그에 해당하는지 엄밀히 따지는 것은 쉽지 않다. 법적 효과에 대한 부분을 따져봐야 하기 때문에 법 언어를 이해하지 못하는 나를 포함한 대부분 사람들에게는 엄밀한 판단은 힘들기 때문이다. 하지만 어떤 소프트웨어가 오픈 소스가 맞는지 확인하는 쉽고 명확한 방법도 존재한다. 바로, 오픈 소스 라이센스를 따르는 소프트웨어인지를 보는 것이다.

물론, 어떤 라이센스가 오픈 소스 라이센스인지 아닌지를 따져보는 것은 앞서 든 것과 똑같은 이유로 여전히 대부분 사람들에게 어려운 일이다. 이를 위해 OSI에서는 어떤 라이센스가 실제로 오픈 소스 라이센스라고 볼 수 있는지를 검증해준다.

현실적으로는, 그러한 검증 절차는 시간과 비용이 드는 일이다. 그러한 이유로 실제로 오픈 소스 세상에서 대부분의 프로그래머들에게 널리 사용되는, 소프트웨어의 오픈 소스 여부를 알아내는 질문은 다음과 같다:

OSI에서 인증한 오픈 소스 라이센스들 가운데 하나로 배포되고 있는가?”

반대로도 활용할 수 있다. 내가 만든 소프트웨어를 오픈 소스로 공개하고 싶으면 어떻게 해야할까? OSI에서 인증한 오픈 소스 라이센스 중에서 하나를 택해서 배포하면 된다. 현실적으로는 GPL, MIT 라이센스, BSD 라이센스, 아파치 라이센스 등에서 하나를 고르면 된다.

3주 전

프로그래밍은 보편적인 언어로 특수한 프로그램을 엮어내는 것이다. 그래서 (Ruby 스크립팅이 들어가기 전의) RPG 쯔꾸루를 이용해서 게임을 만드는 것이나 쇼핑몰 솔루션을 설치해서 쇼핑몰을 만드는 것은 훌륭한 제품 개발은 될 수 있을지언정 프로그래밍으로 볼 수는 없다. 반면 마인크래프트와 같이 튜링 완전한 세계에서 프로그램을 엮어낸다면 그것은 충분히 프로그래밍이라고 볼 수 있다.

그래서 이렇게 요약할 수 있다. 프로그래밍 내지는 해킹은 제품 개발과 다른 것이다. 아무리 훌륭한 제품 개발도 프로그래밍을 필수적으로 요구하지 않는다. 아무리 훌륭한 해킹도 제품성을 필수적으로 요구하지 않는다.

2달 전
버튼의 레이블을 확인/취소 혹은 예/아니오로 쓰기보다는 실제 동사를 쓰는 게 대체로 더 낫다는 얘기가 있다. 예/아니오는 무엇에 대한 긍정 혹은 부정이고, 보통은 그 무엇에 대해 적어놓지만 주의를 기울이지 않는 사람들이 많기 때문이다.

그런데 오늘 게임을 하다가 같은 원칙을 좀더 일반적으로 확대할 수도 있겠다는 생각이 들었다.

첨부한 이미지는 링토스 세계여행 게임 화면이다. 게임을 하면서 수집품을 무작위로 얻게 되는데, 어떤 수집품은 흔해서 자주 나오지만 어떤 수집품은 매우 희귀해서 보기가 힘들다. 위 화면은 ‘여행용 캐리어’라는 수집품에 대한 정보를 보여주고 있다. 수집품을 입수했을 때도 저것과 거의 같은 화면이 뜨는데, 내가 다소 헷갈려하는 부분이 바로 ‘입수 난이도: 매우 낮음’이라고 써져있는 부분이다.

앞서 설명했듯 수집품은 입수 빈도(확률)가 ‘낮으면’ 입수 난이도가 ‘높은’ 것이고, 빈도가 ‘높으면’ 입수 난이도는 ‘낮은’ 것이다. 저 화면을 볼 때 나는 ‘매우 낮음’이 먼저 눈에 들어오고 ‘입수 난이도’ 부분은 대충 흘려보낼 때가 많다. 무심코 확인을 눌러 창을 닫고 나면 내가 방금 입수한 아이템이 ‘난이도’가 낮았다는 것인지 ‘빈도’가 낮았다는 것인지 헷갈리게 된다. 후자라면 기뻐할만한 일이지만 전자면 별 일 아닌 거니까.

아마 입수 난이도를 표시할 때 ‘입수 난이도: 매우 쉬움’이라고 적었다면 어땠을까? 마찬가지로 ‘입수 확률: 매우 흔함’이라고 적을 수도 있을 것이다.

이는 결국 버튼 뿐만 아니라 위와 같이 ‘항목: 내용’으로 적히는 것들이나 표의 컬럼 이름과 실제 컬럼 값 같은 것들처럼 대응 관계가 존재하는 모든 표지에서 적용할 수 있을만한 원칙이 아닐까?

버튼의 레이블을 확인/취소 혹은 예/아니오로 쓰기보다는 실제 동사를 쓰는 게 대체로 더 낫다는 얘기가 있다. 예/아니오는 무엇에 대한 긍정 혹은 부정이고, 보통은 그 무엇에 대해 적어놓지만 주의를 기울이지 않는 사람들이 많기 때문이다.

그런데 오늘 게임을 하다가 같은 원칙을 좀더 일반적으로 확대할 수도 있겠다는 생각이 들었다.

첨부한 이미지는 링토스 세계여행 게임 화면이다. 게임을 하면서 수집품을 무작위로 얻게 되는데, 어떤 수집품은 흔해서 자주 나오지만 어떤 수집품은 매우 희귀해서 보기가 힘들다. 위 화면은 ‘여행용 캐리어’라는 수집품에 대한 정보를 보여주고 있다. 수집품을 입수했을 때도 저것과 거의 같은 화면이 뜨는데, 내가 다소 헷갈려하는 부분이 바로 ‘입수 난이도: 매우 낮음’이라고 써져있는 부분이다.

앞서 설명했듯 수집품은 입수 빈도(확률)가 ‘낮으면’ 입수 난이도가 ‘높은’ 것이고, 빈도가 ‘높으면’ 입수 난이도는 ‘낮은’ 것이다. 저 화면을 볼 때 나는 ‘매우 낮음’이 먼저 눈에 들어오고 ‘입수 난이도’ 부분은 대충 흘려보낼 때가 많다. 무심코 확인을 눌러 창을 닫고 나면 내가 방금 입수한 아이템이 ‘난이도’가 낮았다는 것인지 ‘빈도’가 낮았다는 것인지 헷갈리게 된다. 후자라면 기뻐할만한 일이지만 전자면 별 일 아닌 거니까.

아마 입수 난이도를 표시할 때 ‘입수 난이도: 매우 쉬움’이라고 적었다면 어땠을까? 마찬가지로 ‘입수 확률: 매우 흔함’이라고 적을 수도 있을 것이다.

이는 결국 버튼 뿐만 아니라 위와 같이 ‘항목: 내용’으로 적히는 것들이나 표의 컬럼 이름과 실제 컬럼 값 같은 것들처럼 대응 관계가 존재하는 모든 표지에서 적용할 수 있을만한 원칙이 아닐까?

This was posted 3달 전. It has 17 notes and a high-res version.