[주간 인프런 #40] 개발자의 공유 문화 이모저모 (1) 오픈소스 & 기술 블로그

[주간 인프런 #40] 개발자의 공유 문화 이모저모 (1) 오픈소스 & 기술 블로그

신기하고 재미있는
개발계 공유 문화 삼대장!

#오픈소스 #기술블로그 #회고문화

개발에 막 발을 들였거나, 
개발자와 협업을 자주 하는 분들이라면 
한 번쯤 개발자의 문화에 관심을 가져보셨을 거예요. 

무엇보다 자신만의 노하우를 꽁꽁 감추기는커녕, 
오히려 널리 공개하고 알리는 점
신기하게 다가오기 마련입니다. 

‘왜 오픈소스로 기술을 공개하는 걸까?’ 
‘개발하기도 바쁠 텐데, 왜 개발자는 기술 블로그를 쓸까?’
‘개인 또는 기업 차원에서 해마다 회고를 진행하는 이유는 뭘까?’

이번 <주간 인프런> #40, #41는 바로 개발 업계의 공유 문화에 주목하기로 했습니다.
오픈소스 모델, 기술 블로그, 회고가 개발자들 사이에 중요한 문화로 자리를 잡고 있는 이유가 무엇인지 알아보도록 해요.

이번 주간 인프런 #40은 👨‍💻

주간 인프런 #40, #41 <개발자의 공유 문화 이모저모>는 총 2주에 걸쳐 연재됩니다. 이번 호에서는 오픈소스 문화기술 블로그에 대해 다룹니다 😊

주간 인프런 #40 🌿

오픈 소스 문화의 빛과 그림자 & 
인프런 개발자가 직접 말하는 
기술 블로그를 운영하는 이유까지! 

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

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

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

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

기여로 만드는 오픈소스

오픈소스 소프트웨어(Open-Source Software)?

개발의 핵심 소스 코드를 공개함으로써 누구나 코드를 접근, 사용할 수 있도록 한 소프트웨어.

오픈소스 모델의 기원을 따라가보면 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(오픈소스 이니셔티브) 라이선스를 분류하여 소개하고 있어요. ⓒ한국저작권위원회

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

빛 #1  
윈도우 없는 도시 만들기?  

바르셀로나 자유 소프트웨어 제작자 커뮤니티 웹페이지. ⓒBarcelona Free Software

2018년부터 스페인 바르셀로나에서는 공공에서 사용하는 모든 소프트웨어를 우분투(Ubuntu) 등의 오픈소스 소프트웨어로 전면 대체하는 정책을 추진하였습니다. 오픈소스 활성화에 투자함으로써 소프트웨어 라이선스 비용을 줄이고 특정 업체에 대한 의존을 탈피하고자 하는 시도라고 볼 수 있어요.

빛 #2  
포스트 코로나 시대의 오픈소스

코비드 쉴드의 공식 캐나다 버전, COVID Alert는 현재 iOS/Android 모바일 애플리케이션으로 이용할 수 있어요. ⓒCOVID Shield

코로나19로 전지구적인 위기를 맞은 요즈음, 다양한 오픈소스 커뮤니티에서 문제를 함께 해결하려는 움직임이 눈에 띕니다. 대표적으로 리눅스 재단은 코로나19 관련 대책을 세우는 데 도움이 되는 기술을 공개하는 LFPH(Linux Foundation Public Health)라는 프로젝트를 시작했어요. LFPH의 기술을 기반으로 확진자 동선을 파악하고 스마트폰 알림을 보내는 코비드쉴드(COVID Shield), 코비드그린(COVID Green) 등의 프로젝트가 공개되어 있죠. 

그림자 #1  
오픈소스에 폭탄이 떨어졌다고요?

"휴가를 마치고 돌아와보니 우리 프로젝트의 실패한 빌드를 정리해야 하는 나 자신을 발견했어요." 사건 이후 colors.js 깃허브 커밋에는 전세계 수많은 개발자의 아우성(!)이 달렸습니다. ⓒcolors.js

지난 2022년 1월 초, 유명 오픈소스 패키지 colors.js 및 faker.js가 패키지 개발자에 의해 고의적으로 손상되는 극단적인 사건이 일어났습니다. colors.js의 소스 코드에 "LIBERTY! LIBERTY! LIBERTY!"라는 무한 루프 문자열을 생성하는 악성 코드를 의도적으로 커밋하고, faker.js의 소스 리포지터리(저장소)를 초기화시켜 버린 것이죠.

많은 프로젝트가 오픈소스에 기대고 있는 오늘날, 이런 사태를 어떻게 방지하고 오픈소스 커뮤니티를 지속할 수 있을지 깊은 고민을 남기게 되네요.

그림자 #2  
법정 위에 오른 오픈소스

어도비 포스트스크립트 및 PDF 페이지 변환을 위해 마련된 오픈소스 소프트웨어, Ghostscript 로고 ⓒArtifex Software Inc.

오픈소스 라이선스 관련 분쟁 역시 간단하지 않은 문제입니다. 2017년 한글과컴퓨터는 아티펙스(Artifex)로부터 아티펙스가 공개한 오픈소스 프로젝트 고스트스크립트(Ghostscript)를 무단 사용했다는 혐의로 소송을 당했는데요. 아티펙스는 한글과컴퓨터가 PDF 문서 변환 기능을 고스트스크립트를 사용해 구현하면서도 GPL 라이선스에 따른 코드 공개 또는 사용료 지불을 하지 않았다고 주장했습니다.

해당 소송은 이듬해 2018년, 한글과컴퓨터가 아티펙스와 합의하면서 종료되었다고 해요.

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


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

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

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

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

기술 블로그(Tech Blog, Engineering Blog)?

개발자 개인 또는 기업 차원에서 프로그래밍 및 엔지니어링을 주제로 운영하는 블로그.

많은 개발자들과 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)인데요. 예쁘지 않은 한글 폰트에도 불구하고 ‘글을 쓰고 싶다’는 생각이 들게 만드는 점이 가장 큰 장점으로 저에게 다가왔어요.

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

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

>> 다음 호에 계속 💌

재미있게 읽어보셨나요?
이어지는 주간 인프런 #41에서는
개발자들의 회고 문화를 소개합니다. 커밍 순!


이번 [주간 인프런] 어떠셨나요?
솔직한 의견을 들려주세요!

유익해요 | 아쉬워요

지난 [주간 인프런] 이 궁금하다면? (클릭)

댓글 5
  • 기명진
    기명진

    개발 블로그를 만드는 와중에 이런 글을 읽게 되어서 도움이 되었습니다.

  • Mx
    Mx

    커리어를 어떻게 만들어야 할 지 고민을 많이 하는 시기인데 도움이 많이 되는 글이네요

  • HM
    HM

    구글링하다 보면 기술 블로그가 많아서 늘 의문이었는데 궁금증이 해결됐어요! 유익하고 재밌는 주간지였슴니다! 특히, 기술 블로그 플랫폼을 여럿 알려주셔서 고르는데 수월할 것 같아요~!

  • yappsk999
    yappsk999

    ㅋㅋㅋ넘 현실적이고 재미있는 글이네요

  • POKN
    POKN

    감사합니다🧸🧡

지식공유자 되기
많은 사람들에게 배움의 기회를 주고,
경제적 보상을 받아보세요.
지식공유참여
기업 교육을 위한 인프런
“인프런 비즈니스” 를 통해 모든 팀원이 인프런의 강의를
자유롭게 학습하는 환경을 제공하세요.
인프런 비즈니스