누구에게나 열려라 참깨! 오픈소스

기업의 개발자 채용 공고를 보면 종종 이런 문구가 눈에 띄곤 하는데요. 
‘오픈소스에 기여한 경험이 있으신 분 우대’

_{NAVER Cloud 빅데이터 분석 플랫폼 개발 채용 공고 ⓒNAVER}

대기업은 물론 많은 기업에서 개발자를 채용할 때 오픈소스 기여 경험을 높게 평가하고 있다는 이야기인데요. 서로의 작업물(코드)을 공개하고 발전시킬 수 있게끔 열어두는 개발자 공유 문화의 뿌리에 바로 이 오픈소스 소프트웨어 모델이 있습니다.

기여로 만드는 오픈소스

오픈소스 모델의 기원을 따라가보면 1980년대까지 거슬러 올라갑니다. 1984년 MIT 인공지능 실험실 소속의 개발자 리처드 스톨먼은 70년대 대학가에서 무료로 배포되던 유닉스(UNIX) 운영체제가 기업(AT&T)에 의해 상업화된 상황에 반대하며 ‘GNU(GNU is Not Unix: GNU는 유닉스가 아니다) 프로젝트’를 시작합니다. 그리고 저작권(Copyright)에 대항하는 카피레프트(Copyleft) 개념을 적용한 자유 소프트웨어 라이선스(GPL: General Public License)를 공표하죠. 누구나 자유롭게 배포된 코드를 이용하고 변경할 수 있지만, GPL이 적용된 코드를 변형한 파생 저작물 역시 코드를 공개/배포할 의무가 있다는 라이선스 조항입니다.

_{리눅스(Linux)의 마스코트 펭귄, 턱스(Tux). 지금도 활발하게 쓰이고 있는 리눅스가 바로 이 GPL에 따라 1991년에 공개된 자유 소프트웨어(Free Software) 운영체제입니다. ⓒLinux}

그런데 한편에서는 이 자유 소프트웨어(Free Software)라는 용어가 너무 모호하게 느껴지고, GPL 조항이 너무 엄격해서 실제 소프트웨어에 적용하기 어렵기 때문에 기업들이 참여를 꺼리게 된다는 논의가 계속해서 이루어졌습니다. 이에 1998년 에릭 레이먼드, 크리스틴 피터슨, 브루스 페런스 등이 참여한 회의에서 오픈소스라는 용어가 처음 등장하게 되죠.

오픈소스와 자유 소프트웨어는 얼핏 차이가 없는 개념처럼 느껴질 수도 있는데요. 하지만 자유 소프트웨어가 사용자의 자유를 위해 소프트웨어를 부당하게 독점해서는 안 된다는 윤리적·사회적 운동이라면 오픈소스는 개발 방법론 및 사용 권한에 가깝습니다. 소프트웨어의 소스 코드에 접근하고, 개선할 수 있도록 개방형 협업을 장려하는 권리 자체를 오픈소스라고 불러요.

_{구글에서 개발한 안드로이드(Android) 운영체제 역시 리눅스 커널 기반의 대표적인 오픈 소스입니다. 삼성전자 등 스마트폰 제조사에서 안드로이드 운영체제를 가져다 소스 코드를 수정해서 쓸 수 있는 이유죠. ⓒGoogle Android}

이러한 오픈소스의 핵심 개념은 기여(Contribution)입니다. 크게는 버그를 수정하거나 소스 코드를 개선하고 기능을 추가하는 것부터, 작게는 오타를 수정하거나 다양한 언어로 번역하고 가이드 문서를 만드는 것까지 모두 다 오픈소스 커뮤니티에 기여하는 활동으로 볼 수 있어요.

개인의 개발 역량을 키우는 데도 도움이 되고, 보람을 느끼기도 하며, 개발 커뮤니티 안에서 이름을 알리는 기회가 될 수도 있기 때문에 전세계 많은 개발자들이 자발적으로 오픈 소스 프로젝트에 기여하고 있죠. 

_{깃허브(Github)는 오픈소스를 위한 저장소 호스팅을 무상 제공하고 있고, 많은 기업에서도 깃허브를 통해 자사의 프로젝트 코드를 오픈소스로 공개합니다. 실제로 EPAM에서는 여러 기업의 깃허브 기여량에 따른 랭킹을 측정해 공개하고 있어요. 이 랭킹 알고리즘 역시 Github에서 확인해볼 수 있습니다. ⓒEPAM}

오픈소스는 피해갈 수 없는 대세

현재 개발 업계에서 활발하게 쓰이고 있는 기술들의 적지 않은 수가 오픈소스입니다. 빅데이터 플랫폼 하둡(Hadoop), 관계형 데이터베이스 MySQL, 웹 브라우저 파이어폭스(Firefox), 기계학습 라이브러리 텐서플로(TensorFlow), 가상화 플랫폼 도커(Docker), CMS 솔루션 워드프레스(Wordpress) 등 많은 소프트웨어가 오픈소스로 코드를 공개하고 있죠. 현재 오픈소스 기술이 쓰이지 않은 서비스가 거의 없다고 해도 무방할 정도입니다.

그렇다면 오픈소스 소프트웨어가 대세가 된 이유는 무엇일까요? 우선 진입 비용이 낮습니다. 공개된 소스를 기반으로 수정, 개선, 재배포를 할 수 있기 때문에 새로운 기반 기술을 마련하는 데 드는 비용을 줄일 수 있습니다. 또 누구나 접근할 수 있는 코드이기 때문에 전세계 개발자들의 손을 타고 버그 수정이나 성능 개선이 빠르게 이루어지기도 해요. 그만큼 품질이 높은 풍성한 생태계를 낮은 비용으로 경험할 수 있다는 뜻이죠. 

물론 단점도 있습니다. 커뮤니티가 활성화되어 있지 않거나, 상용 소프트웨어에 비해 관련 문서가 빈약한 경우가 많아 막상 실제 개발 단계에서는 운용이 지연될 수도 있죠. 기술 지원이 빈약하기 때문에 유지 보수에도 어려움이 따릅니다. 업데이트가 잘 이루어지지 않을 수도 있고, 잘못된 정보나 취약점이 끼어있을 수도 있으며, 갑자기 지원이 중단되면 해당 기술을 차용한 프로젝트는 치명적인 손해를 입을 수도 있어요. 또 오픈소스라고 하더라도 라이선스에 따라 의무 사항의 범위가 조금씩 다르기 때문에 주의가 필요합니다.

_{한국저작권위원회 오픈소스SW 라이선스 종합정보시스템에서는 GPL, LPGL, MIT Lisence 등 대표적인 OSI(오픈소스 이니셔티브) 라이선스를 분류하여 소개하고 있어요. ⓒ한국저작권위원회}

그밖에: 오픈소스의 빛과 그림자

다양한 영역에서 쓰이고 있는 오픈소스, 여러분은 어떻게 바라보고 계신가요?
적어도 한동안 오픈소스는 거스를 수 없는 대세인 것 같습니다.
실제 개발 영역에서 오픈소스가 유익한 역할을 하기 위해서는 오픈소스 커뮤니티에 대한 많은 관심과 기여가 필요할 거라는 생각이 드네요 😊

개발자의 글쓰기, 기술 블로그 

‘개발자는 코드로 말한다’고들 하죠? 개발자 채용 과정에서 본인이 운영하는 깃허브(Github) 링크를 이력서에 첨부하는 경우가 늘고 있습니다. 꾸준히 코드를 커밋한 기록이 개발자의 역량을 잘 보여줄 수 있다는 뜻이죠. 

한편 깃허브 링크만큼이나 개발자의 역량과 생각을 잘 드러내는 수단이 한 가지 더 있습니다. 바로 개발자가 직접 운영하는 기술 블로그죠.

성장하는 개발자들은 왜 블로그를 쓸까 

많은 개발자들과 IT 회사에서 기술 블로그를 운영하고 있어요. 사용하고 있는 기술에 대해 공부한 내용부터 적용 사례에 대한 기록, 특정 기술이나 개발 이슈에 대한 개인의 관점, 프로젝트 회고 등 개발을 둘러싼 다양한 기록을 블로그에 싣고 있죠.

_{우아한형제들 기술 블로그. 기술 블로그는 개인이 운영하기도 하지만, 기업이 브랜딩 및 아카이빙 차원에서 운영하기도 합니다. ⓒ우아한형제들}

그럼 도대체 왜 기술 블로그를 운영하는 걸까요? 여러 개발자들이 개발 역량을 키우는 데 기술 블로그가 중요한 역할을 한다고 이야기합니다. 각종 기술이 끊임없이 업데이트되는 요즈음, 자신이 겪는 시행착오나 공부한 내용을 기록하며 지식을 문서화하는 과정에서 많은 배움이 된다고 해요. 또 공개적인 기록을 통해 다른 개발자들과 지식을 공유하고 틀린 내용을 바로잡거나 의견을 나누는 기회가 되기도 하고요.

_{개발자들 사이에는 책 『실용주의 프로그래머』에서 등장한 ‘고무 오리 디버깅’(Rubber Duck Debugging)이라는 방법론이 널리 알려져 있습니다. 고무 오리 인형을 두고 자신이 짠 코드를 설명하는 과정에서 스스로 문제점을 깨달을 수 있다는 뜻인데요. 기술 블로그에 공부한 내용을 정리하고 공개하는 것 역시 비슷한 방법이라고 볼 수 있죠.}

또 앞서 이야기했듯 구직 활동이나 개인 브랜딩을 위한 포트폴리오 역할을 하기도 합니다. 비슷한 수준의 이력과 실력을 갖춘 지원자들 사이에서라면 기술 블로그로 개발에 대한 고민과 잠재력 등을 어필하는 게 유리할 수 있죠. 실제로 여러 기업에서 채용 우대 사항으로 기술 블로그 운영 경험을 꼽기도 합니다. 또 기술 블로그를 통해 집필이나 강연 등 다양한 제의를 받을 수도 있고요.

무엇보다 블로그에 꾸준히 글을 쓰는 건 쉽지 않은 일입니다. 그만큼 개발자 개인에게는 좋은 동기 부여 수단이자, 본인의 성장을 돌아볼 수 있는 기회가 되어줄 거예요.

_{기술 블로그로 이용되는 플랫폼 역시 다양합니다. 헥소(HEXO), 지킬(Jykell), 휴고(Hugo) 등을 이용한 깃허브(Github) 블로그, 미디엄(Medium), 워드프레스(WordPress), 블로그스팟(Blogspot), 고스트(Ghost), 벨로그(velog), 티스토리(Tistory), 브런치(Brunch) 등 여러 가지 플랫폼이 있으니 각자의 기준과 기호에 맞춰 선택할 수 있어요.}

1. 블로그를 쓰게 된 이유

제가 블로그를 쓰게 된 이유는 첫 회사에서 동료와 있었던 일 때문인데요. 2018년 즈음 JavaScript 서적을 사서 변수 생성 과정을 읽고 있었습니다.
var, let, const로 변수를 생성하면 내부적으로 어떻게 되며, 호이스팅이 무엇인지에 대한 내용이었습니다. 🙂

당시에 저는 한참 책으로 공부하는 시점이었어요. 때문에 많은 책을 읽었다면, 많이 공부했다고 생각하곤 했습니다. 헌데 때마침 동료의 코드를 리뷰하게 되었는데 온통 var를 이용해서 변수를 선언했더라고요. 그래서 아래와 같은 전개가 시작되었습니다.

나: 혹시 변수를 var로 선언한 이유가 있을까요? 이것보단 let과 const를 써야 하는데.
동료: 어... 왜 var로 선언하면 안 돼요? 
나: (지난주 공부한 것을 설명할 생각에 신남) 자 그러니까~ 이게 이렇게 되면 개발자 실수로 값이 바뀔 수 있고, 또 호이스팅 현상이란 게 있는데 이게 뭐냐면~~~... 음... 어... 어??
동료: (...이놈이?)
나: 제... 제가 조금 뒤에 찾아갈게요... 😢

이때 처음으로 제가 공부했다고 생각한 부분에 대해 제대로 이해하지 못했다는 사실을 깨달았습니다. 그리고 처음으로 공부 방법에 대해 의문을 느끼게 되었습니다. 단순히 책을 눈으로 읽고 가끔 코드를 타이핑하는 방법이 아닌, 다른 방법을 찾아야겠다고 생각했습니다. 제 자신을 객관적으로 관찰해보니 두 가지 문제가 있었습니다.

1. 책을 읽고 이해했다고 생각한 것과, 이것을 실제로 남에게 설명하는 것에는 차이가 있다.
2. 인정하자. 내 기억력은 특별하지 않다.

우선 블로그에 글을 쓰려면 단순히 책을 읽는 데서 그치는 게 아니라, 공부한 내용을 조금 더 정확하게 이해해야 했습니다.  또 남들이 보는 글을 쓰려면 추가적인 질문을 생각하게 됩니다. ‘이 글을 읽는 사람들이 이걸 궁금해하지 않을까? ...근데 나도 모르네? 찾아보자’

또한 이렇게 쓴 글들은 다음에 제가 바로바로 찾아볼 수 있습니다. 실제로 시간이 지나서 제가 쓴 글을 본 일이 적지 않았습니다. 제가 썼기 때문에 다른 글보다 이해도 빠르고, 때때로 함께 일하는 사람에게 특정 기술이나 상황을 말로 설명하지 않고 공유할 때도 유용합니다.

2. 블로그를 어디에 써야 할까?

당시 개발자들이 블로그를 보통 어디에 쓰는지 찾아보니 보통 티스토리(Tistory), 구글 블로그스팟(Blogspot), 미디엄(Medium)에 글을 쓰더라구요. 처음에 저는 블로그스팟으로 블로그를 만들기로 했는데, 개발자들이 CSS를 건드려서 블로그스팟을 커스터마이징 한다는 글을 보고 정했습니다. 이유는 단순했어요. ‘이렇게 CSS도 공부해보자!’

그렇게 블로그스팟에 여러 글을 쓰고 동료 개발자 (위에서 언급한) 에게 자랑했습니다.

나: 짠~ 이게 제 블로그예요 
동료: 오~ 다 좋은데 블로그가 너무 안 이쁜데요? 글을 읽기가 싫어요 
나: ...?????? 😨

많이 부끄럽지만 당시 제 블로그스팟을 첨부합니다.

친한 동료의 촌철살인에 저는 결국 다른 서비스에 블로그를 만들기로 결정했습니다. 바로 미디엄(Medium)인데요. 예쁘지 않은 한글 폰트에도 불구하고 ‘글을 쓰고 싶다’는 생각이 들게 만드는 점이 가장 큰 장점으로 저에게 다가왔어요.

또 미디엄 블로그에 공부한 것을 적어나가다 보니, 읽는 사람들의 좋아요와 하이라이팅 기능도 글을 쓰는 저를 뿌듯하게 만들어주는 요소인 것 같아요.

_{인프런 개발자 꾸기의 기술 블로그를 소개합니다 😊}