오픈소스를 쇼핑하는 엔지니어
BUZZVIL 블로그에 소개된 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
1. 글을 시작하며
오픈소스를 많이 사용하게 되는 스타트업 엔지니어는 항상 고민을 합니다. 쇼핑을 할 때 가격을 비교하고 사용기를 읽어보는 것처럼, 오픈소스를 선택할 때에도 자신의 기준에 맞춰서 여러가지 비교를 해보고 다른 분들의 사용기를 참고하기도 하구요. 가끔은 쇼핑중독처럼 어떤 오픈소스가 좋은지 비교하는데서 즐거움을 느끼기도 합니다(?). 허니스크린 서버를 개발하기 시작했을 때에도 당연스레 많은 고민을 했었고, 그 와중에 좋은 참고가 됐던 자료는 인스타그램의 서버구조에 관한 글이었습니다.
인스타그램에서는 아래의 세가지 원칙으로 시스템을 선택했습니다.
– 아주 간단하게 유지하라
– 바퀴를 재발명하지 마라
– 가능하면 증명되고 안정된 기술을 사용하라
인스타그램의 천만명이 넘는 서비스를 단 3명의 엔지니어가 유지하고 있었다는 사실에 놀라지 않을 수 없었습니다. 스타트업의 특성상 한정된 자원으로 퍼포먼스를 내야하는 제약이 따르기 때문에 이러한 접근 방법은 정말 유용하다는 생각이 들기도 하구요.
위의 세 가지 원칙은 결국에는 하나의 의미로 해석할 수 있습니다. 시스템을 최대한 간단하게 유지하는 것(최소한의 커스터마이징). 이를 위해서는 이미 존재하는 기술을 잘 가져다 써야 합니다. 그리고, 가져다 쓸 기술을 선택할 때에는 증명되고 안정된 것이면 좋다는 것입니다.
제가 궁금했던 점은 그러한 바퀴를 어떻게 발굴해서 잘 장착했느냐 였는데요. 바퀴를 가져다 쓰려면 이 바퀴가 썩은 바퀴인지 튼튼하고 용도에 맞는 바퀴인지 구별을 해야하는데 말처럼 쉬운 일은 아니었습니다. 더불어, 가장 첫 순간에 바퀴를 잘 선택하는 것도 매우 중요합니다. 이미 자동차가 출발해서 달리는 중에는 다른 바퀴로 갈아끼우기가 매우 힘들기 때문입니다. 서비스를 시작하고나서 서비스의 중단 없이 뭔가를 바꾸는 것이 시스템을 운영하는데 있어서 매우 어려운 부분 중에 하나라는 건 모두가 공감하실 점이라 생각합니다.
그렇다면 좋은 바퀴는 어떻게 찾아내야 할까요? 주변에 물어볼 사람이 있다면 좋겠지만 대부분은 인터넷 검색을 통해서 찾아냅니다. 무지한 개발자에게 항상 한 줄기 빛이되어주는 구글에게 감사한 마음을 가지며 제가 바퀴를 고르는 기준에 대해서 소개 해드리고자 합니다.
검색 키워드의 선정
검색에 있어서 가장 중요한 것은 키워드의 선정입니다. 검색 키워드의 중요성에 대해서 처음으로 느꼈던 때는 학부생 시절 특허수업에서였습니다. 하루는 특허관련 회사에서 일하시는 외부 강사를 초청해서 수업을 들었는데, 선행 특허를 찾아내기 위한 노하우를 알려주시면서 이리저리 다양한 키워드를 조합하여 검색하는 모습이 매우 인상이 깊었습니다. 검색에 있어서 가장 중요한 것은 키워드의 선정이라는 어찌보면 당연한 사실을 깨닫게 되는 계기였습니다.
만약 비슷한 기능을 하는 A와 B라는 라이브러리가 있다고 가정할 때, 처음에 시도해보는 몇 가지 키워드를 아래와 같이 추려보았습니다.
– A B
– A vs B
– A B 비교
– A B which is better
– A alternative
– Why A sucks
– Why moved from A
– Switch from A
유치해 보이지만 의외로 vs로 검색해보면 좋은 비교자료가 많이 나옵니다. 그리고 alternative와 같은 단어를 활용하면 A와 비슷한 기능을 하는 새로운 B를 찾는데 도움이 됩니다. 검색을 통해서 이미 알고 있는 후보군들을 비교하는 것은 물론 알지 못했던 후보를 발견하기도 합니다. 검색을 잘 하려면 어휘력이 좋아야 합니다. 어느 키워드로 검색하면 내가 원하는 답을 쉽게 찾을 수 있을까 항상 고민해야 합니다.
치명적인 단점은 없는지
위의 검색 키워드 중에 “Why A sucks”에 해당하는 이야기입니다. 예를 들면, 주변에 핸드폰을 선택 할 때 아이폰은 다 좋은데 배터리 분리가 안되서 안 쓴다는 사람이 많습니다. 선택하는데 있어서 단점이 중요한 역할을 한 사례입니다.
대부분 어떤 오픈소스를 소개하는 페이지에 가보면 좋은점만 나열되어 있습니다. 따라서 단점에 대해서 따로 파악할 필요가 있습니다. 원하는 기능이 있어서 기술을 도입했는데 알고보니 단점이 용납할 수 없는 것이었다면 나중에 후회하게 됩니다. 그리고 단점을 찾다보면 주의해야할 사항들에 대해서도 잘 알 수 있게됩니다.
예를들면 레디스 같은 경우 성능은 막강하지만 싱글스레드로 동작하고 데이터가 유실될 가능성에 대해 인지를 하고 있어야 합니다. 그리고 리플리케이션 구성에서 장애발생시 fail-over를 잘못했다가 데이터를 날려먹는 경우가 종종 있습니다.
강대명님의 “레디스, 잘못쓰면 망한다”에 잘 나와 있는 내용이네요. 실제로 장애로 일부 데이터가 소실된 트윌로의 사례도 있습니다.
활발히 개발중인지
소스 레파지토리의 커밋 로그등을 확인해서 계속 유지보수가 되고 있는지를 체크합니다. 예를들어, 마지막 커밋이 6개월 이상 됐다면 죽은 프로젝트라고 볼 수 있습니다. 당장은 괜찮을지 몰라도 나중에 버그가 발견되거나 다른 라이브러리를 버전업 하는데 있어서 호환성 문제로 걸림돌이 될 수 있습니다.
아주 간단한 라이브러리(JSON serializer 같은)들은 유지보수 할 것이 많지 않고 다른 것으로 갈아 타기도 쉬우니 예외입니다. 지금은 유지보수가 되고 있는데 조만간 문 닫을 가능성도 있습니다. 사실 이정도까지 파악하려면 감으로 할 수 밖에 없습니다. 소스 커미터들의 프로필, 레파지토리의 분위기(?)등 알아서 잘 판단합니다. 개인이 만들어서 혼자 운영하는 작은 라이브러리들은 유지보수가 잘 안될 가능성이 높습니다.
버전이 1.0 이상인지
하지만, 무조건 1.0 이상이라고 안전한 것은 아니고 반대로 1.0 미만이라고 불완전한 것도 아닙니다. 하지만 1.0 버전이 나왔다면 그만큼 실 환경에서 써도 된다고 저자가 자신감을 표현했다는 것으로 이해하면 좋을 것 같습니다. 0점대 버전임에도 프로덕션 환경에서 많이 사용하는 오픈소스의 예로는 Node.js, SQLAlchemy가 있습니다.
다만 나중에 1.0으로 버전업이 되면서 하위호환성이 보장 안 될 수는 있습니다. 버전 넘버와 함께 라이브러리가 얼마나 오래된 것인지도 함께 보고 판단 합니다. SQLAlchemy 같은 경우 거의 10년간 0점대 버전을 사용하고 있었습니다.
버전과 관련된 한가지 팁이 있는데 만약 마지막 두 개의 릴리즈가 3.9.28, 4.0.0 이라면 저는 최신버전을 사용 안하고 3.9.28버전을 사용합니다. 버전이 4.0.0이 됐다는 것은 큰 변화가 있었다는 뜻이고 버그가 있을 가능성도 매우 높습니다. 갓 나온 최신버전 보다는 안정된 버전을 선택하는 것이 좋습니다. 메이저 버전이 나온지 6개월정도는 지나야 어느정도 안심하고 사용할 수 있는 것 같습니다. GitHub의 issues 페이지도 한 번 둘러보면 특별한 문제가 없는지 확인하는데 도움이 됩니다.
레퍼런스가 충분한지
잘 알려진 곳에서 사용하는것이 확인되면 우선 그 라이브러리는 어느정도 검증이 되었다는 뜻입니다. 허니스크린의 경우 웹프레임워크로 Django와 Flask를 검토 했었는데 Django를 선택한 큰 이유중에 하나가 바로 레퍼런스의 유무였습니다.
Django는 Disqus, Instagram, Pinterest, Eventbrite 등 많은 곳에서 성공적으로 사용하고 있는 반면 Flask는 딱히 어디서 사용중이라는 정보를 얻을수가 없었습니다. Flask도 많은 사람들이 사용하고 있지만 Django만큼의 대형 사이트에서의 레퍼런스가 찾기 힘들었습니다. (물론 Flask가 좋지 않다는 이야기는 절대 아니며 위의 내용은 2013년에 비교를 했을 당시 기준이었습니다.)
구글 트렌드 검색
이래도 A와 B중에 선택을 못하겠다고 하면 구글 트렌드에 가서 A와 B로 구글에서 검색되는 빈도를 확인해봅니다. 추이를 그래프로 볼 수 있기 때문에 선택 기준의 객관적인 자료로 활용할 수 있습니다.
2. 마무리하며
어떤 오픈소스를 사용할 것인가에 대한 호불호는 갈릴 수 있습니다. 좋은 오픈소스를 잘 고른다고해서 좋은 개발자라고 말할수도 없습니다. 하지만 사용하는데 문제가 있을 만한 오픈소스를 가려낼 필요는 있습니다. 프로덕션 환경에서는 적어도 예상치 못한 문제를 일으킬 확률을 줄이고 나아가서 안정적이고 빠른 속도로 개발해 나갈 수 있도록 처음의 선택을 잘 하면 좋을 것 같습니다.
글을 쓰다보니 남이 만들어놓은 오픈소스를 가져다 쓰기만 하는 것 같아서 죄책감이 드네요. 언젠간 저도 오픈소스에 기여하는 날이 올 수 있도록 노력해야겠습니다.
