Disclaimer: 나는 대학을 가지 않았다. 그 점을 감안해서 읽어주시면 좋겠다. 또, 나는 한국에서 평생을 살았기 때문에, 이 글에서 “한국에서는”이라고 표현한 것이 실제로는 다른 나라에서도 마찬가지인 경우도 있을 수 있다.

이리 저리 직장을 옮겨 다녔지만 매번 개발자로 일했다. 개발자로 일하면서 신입 개발자를 뽑을 때마다 마주했던 문제가 있다. 관련 학과를 전공하는 대학생 인턴, 대학교 졸업생 신입 개발자 상당수가 (공채를 통해 뽑았다면) 내가 최소한으로 요구하는 수준에도 훨씬 미치지 못한다는 것이다. 내가 신입한테 기대하는 수준은 이런 것이다. 주워들은 것은 많지만 실무 경험은 없어서, 코딩을 하고 나면 꼭 사고를 친다. 실제 수준은 이렇다. 코딩을 못하므로 사고를 칠 일도 없다.

사실상 대부분의 대학교 관련 학과 졸업생에게서 기대할 수 있는 수준이랑, 내가 다니던 실업계 고등학교의 관련 학과 졸업생에게서 기대할 수 있는 수준과 크게 다르지 않다.

컴퓨터 과학을 전공한 대학생이 학교에서 분명히 기본적인 알고리즘과 자료구조, 코딩을 가르치는 데도 불구하고 실제로 약간이라도 유용한 프로그램을 단 한 줄도 작성하지 못하는 상태로 졸업하는 데에는 복합적인 원인이 존재할 것이다. 가령, 전공의 지식보다는 영어나 자기소개서 준비와 같은 학과에 크게 관련이 없는, 일반적인 취업 스펙을 쌓는 데에 집중하는 것이 더 유리하다는 분위기가 퍼져있는 것도 한 이유일 것이다. 첫 전공 수업에서 다루는 지식의 너무나 이질적이고 거북한 느낌에 받을 수밖에 없는 충격도 이유가 될 수 있겠다. 내가 줄곧 대학생이었던 주변의 친구들, 그리고 인턴으로 들어온 대학생들, 막 졸업한 신입 개발자를 보면서 느낀 점은 그들은 스스로 그 분야에 재능이 없다고 판단하는 것 같다는 것이다.

본인 스스로 자신이 선택한 전공에 재능이 없다고 느끼는 것을 넘어서 흥미가 없는 것은, 얼마든지 있을 수 있는 일이다. 하지만 대학교 졸업생의 상당 비율이 그러한 느낌을 공유한다면 그것은 무언가 문제가 있는 것이다. 그 사람 각각의 전공 선택이 실수인 것이 아니라, 전공을 선택하는 방식에 대한 사회적인 분위기 내지는 합의가 잘못되어 있다고 생각한다.

가령 내가 대학을 갔다면 나는 컴퓨터 과학을 공부하려고 했을 것이다. 혹은, 컴퓨터는 취미로 공부하기로 정하고, 다른 자연 과학 내지는 공학 분야를 선택했을지도 모른다. 하지만 내가 수능에서 요령으로, 혹은 컨닝을 해서 부정한 방법으로 높은 점수를 받아서, 운 좋게 의대나 법대에 갈 수 있게 되었다고 해도 의대/법대를 선택하지는 않았을 것이다. 운 좋게 의대/법대를 들어간다고 해서 내가 잘 해낼 수 있을 리가 없다고 생각하기 때문이다.

하지만 한국 사회는 “막상 들어간다고 해도 잘 해낼 수 있을 리가 없다”는 점에 대해서 그리 고민하지 않는 듯하다. 들어가는 것 자체가 언제나 중요한 것이다. 그래서 점수 맞춰서 대학 가기라는 전략이 주로 널리 쓰인다.

여러 문제의 원인은 대부분 사회적인 문제로 돌려야 하겠으나, 그게 하루 아침에 고쳐질 리가 없고, 이 글에서는 개개인 수준에서 취할 수 있는 전략에 대해 얘기해보고 싶다.

사람의 재능이라는 것은 크게 두 가지로 나눠볼 수 있을 법하다. 하나는 어떤 특수한 분야에만 유용하고, 다른 분야에는 그리 유용하지 않은 특수한 재능이다. 다른 하나는 어떤 분야를 하건 대체로 다 도움이 될만한 일반적인 재능이다. 가령 끈기나, 체력, 이해력 등은 일반적인 재능이라고 볼 수 있을 것이다. 누구나 특수한 재능은 어느 정도 지니고 태어나지만, 일반 재능은 좀더 귀한 것으로서, 누구에게나 주어지는 것은 아니다. 이걸 풀어서 얘기하면, 어떤 전공을 선택하더라도 어떻게든 잘 해낼 수 있는 재능은 흔치 않은 것이다. 따라서 내게 그러한 일반 재능이 풍부할 것이라고 가정하는 것은 리스크가 매우 높은 베팅이다.

“점수에 맞춰서 학교와 전공을 고른다”는 전략은 결국은 그러한 일반 재능, 너무나 희귀한 그 재능을 가진 사람에게만 좋은 전략이 된다. 대부분의 사람들에게는 그러한 전략은 무리수에 가깝다. 하지만 부모님과 선생님은 대체로 반대의 의견을 지닌다. “그래도 공부가 제일 쉬워”는 오래된 격언이다. 나는 그 격언이 잘못된 판단이라는 데에 베팅했다.

물론 학생 개개인에게 어떠한 특수한 재능이 있는지 측정하는 것은 우리가 짐작하는 것보다는 사회적 비용이 많이 드는 일이다. 반면에 일반 재능은 그것을 잘 측정하는 방법만 개발되면 보편적으로 쓰일 수 있기 때문에 상대적으로 비용이 적게 든다. 가령 수능은 이름 그대로 일반적인 수학 능력에 대해서 측정한다. 하지만 전국의 학생들 중에서 만에 하나 있을 뛰어난 바둑 인재를 놓치지 않기 위해 프로 기사 시험을 수능과 함께 보게 하는 것은 쉬운 결정이 아니다. 따라서 그러한 현실적인 어려움 때문에, 각자의 특수한 재능을 발견하는 것은 각자의 몫이 된다. 수능은 내가 치지 않겠다고 해도 선생님과 부모님, 친구들이 이구동성으로 봐야 한다고 조언해주지만, 프로 바둑 기사 시험을 치르는 것은 나의 선택이 된다.

그럼 뭘 어쩌란 말이냐?

그래서 내가 제안하고 싶은 것은: 가정 교육 수준에서, 자녀들이 무엇을 할 때 즐거움을 느끼는지에 대해서 항상 관심을 가져야 한다고 생각한다. 이 때 즐거움이란 특수한 즐거움을 말한다. 위의 특수 재능과 일반 재능을 나눈 것과 마찬가지로 즐거움도 두 종류로 나눠볼 수 있을 법하다. 가령 친구들과 어쩌다 바둑을 하면서 다들 지루해 하는데 나만 즐거워 한다면, 그것은 특수한 즐거움이다. 반면 다같이 비디오 게임을 했는데 모두들 즐거워 했다면, 그것은 일반적인 즐거움이다. 요는 다른 사람은 별로라고 하는데도 나한테는 즐거운 것에 주목할 필요가 있다는 것이다. 나는 초등학교나 중학교 때 컴퓨터실에서 친구들과 다같이 게임도 했지만 HTML로 홈페이지 만드는 수업도 했다. 게임은 나도 즐겁고 친구들도 즐거웠지만, 홈페이지 만드는 것은 나만 즐거워 했다. 나는 어릴 때 그러한 차이에 주목했기 때문에 컴퓨터를 배워야겠다는 생각을 자연스럽게 하게 된 것이다. 즐거움은, 항상 그렇지는 않겠지만, 재능의 신호인 것이다.

3주 전

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

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

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

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

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

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

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 1달 전. 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 라이센스, 아파치 라이센스 등에서 하나를 고르면 된다.

1달 전

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

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

3달 전