강아지와 바퀴

초보 개발자가 '의미 있는' 나만의 라이브러리를 개발 하는 법 - 1

"바퀴를 다시 발명하지 마라"

프로그래밍의 오랜 격언입니다. 이미 존재하는 툴을 다시 개발하는 데 시간을 쓰지 말라는 의미죠. 한동안 이 글귀를 볼 때마다 뜨끔하는 기분이었습니다. 혹시 당신도 마찬가지인가요?

내가 발명한 바퀴

웹 프론트엔드 개발은 오픈 소스 라이브러리들로 인해 돌아갑니다. React처럼 업계의 표준이 된 라이브러리부터 각종 유틸리티, 디자인 시스템, 번들러, 복잡한 프레임워크까지. 수많은 오픈소스들이 살아숨쉬는 레포지토리들을 돌아다니다보면 '나도 언젠가 대단한 라이브러리를 만들어보고 싶다' 라는 꿈을 마음속 깊은 곳에 품곤 합니다.

그러나 라이브러리를 만드는 것은 우리의 현실과 많이 동떨어진 이야기입니다. 이미 세상에는 유용하고 잘 관리되는 오픈소스 라이브러리들이 많습니다. 능력 있는 개발자가 되는 방법은 풍부한 지식과 좋은 서칭 능력을 바탕으로 이러한 거인의 어께에 안정적으로 올라타는 것입니다. 조금 더 욕심을 낸다면 이들을 유지보수하는 데 기여할 수도 있겠습니다. 버그를 고치고, 테스트 코드를 작성하고, 먼지가 쌓인 코드 조각들을 최신 환경에 맞게 업데이트하면서 말입니다.

만약 라이브러리를 직접 개발하기로 결심했다면 그 때부터 가시밭길은 시작입니다. 단순히 공부나 흥밋거리가 아니라 실제로 사용하기 위한 라이브러리를 만든다면 더욱 그렇습니다. 우리가 발명한 바퀴는 주변의 아마 다른 어떤 바퀴보다도 느릴 것이고, 때로는 아예 굴러가지 않을 겁니다. 이를 고치려 급하게 덧댄 코드는 출발점의 열정으로 써내려간 README를 무색하게 만들 것이고, 라이브러리에 간단한 기능을 하나씩 추가할 때마다 우리는 밤을 샐 겁니다. 그리고 우리의 체력과 열정이 동났을 때 쯤, 문제의 라이브러리는 동료 개발자들에 의해 발견되고, 기소된 다음, 팀 전체의 추가적인 비용을 소모하며 다른 기성품의 바퀴로 대체됩니다.

"그러니, 당신이 잘난 개발자가 아니라면 라이브러리를 개발하겠다는 헛된 꿈은 접어두고 이미 있는 도구들이나 잘 사용하라" 라는 말을 할 것이었다면, 이 글은 첫 문장에서 끝났어야 하죠. 저는 여전히 라이브러리 직접 만들어보는 것이 꼭 시간 낭비는 아니고, 초심자에게도 충분히 의미 있는 작업이라고 주장하고자 합니다. 개발을 시작하기 전에 충분한 고민을 거친다면 말입니다. 만약 당신이 초심자임에도 불구하고 좋은 라이브러리를 개발하는 꿈을 마음 속에 품고 있다면, 그래서 저처럼 욕심을 부리다 온갖 시행착오를 겪은 적이 있다면, 글을 마저 읽어보길 권하겠습니다.

개밥 먹이기

개밥 먹이기(Dogfooding)는 스타트업에서 종종 언급되는 용어로, 어떤 조직에서 만든 서비스를 그 조직에서 실제로 사용하는 전략을 의미합니다. 개밥 먹이기는 실제 서비스 이전에도 유의미한 데이터를 쌓을 수 있게 도와주고, 때로는 복잡한 테스트를 거쳐야 하는 문제점을 찾아주기도 합니다. 물론 조직원들이 미완성 서비스를 사용하는 데에서 오는, 때로는 꽤나 심각한 생산성 하락을 감수해야겠지만 말입니다. 초심자가 만든 라이브러리는 스타트업의 초기 프로덕트와 비슷합니다. 만든 사람 말고는 아무도 사용하지 않는다는 점에서 말이죠. 우리에게 라이브러리 마케팅 전담 팀이나 어마어마한 수의 팔로워가 붙어있지 않는 한, 개밥 먹이기는 좋은 전략이 될 수 있습니다.

물론 앞서 역설했듯 직접 만든 라이브러리를 사용하는 것은 시간낭비로 이어지기 딱 좋은 선택입니다. 그러나 창업이든 개발이든 항상 첫 단추가 중요한 법. 어떤 라이브러리를, 어떻게 만들기로 계획했는 지에 따라 우리는 조잡한 바퀴로 많은 것을 얻어갈 수도 있습니다.

의미 있는 라이브러리를 개발하기 위해 미리 거쳐야 하는 과정들을 아래의 세 단계로 정리해보았습니다. 명확한 근거가 있기 보다는 저의 시행착오를 토대로 작성된 목록인데요, 이 과정이 부디 여러분들의 시간을 아껴줄 수 있길 바랍니다.

1. 얻어갈 것을 확실하게 정하기

2. 최소한의 MVP 설정하기

3. 레퍼런스를 찾고, 잘 구분하기

얻어갈 것을 확실하게 정하기

창업 아이템과 마찬가지로, 우리의 라이브러리는 어떤 문제, 이왕이면 지금까지 제대로 해결된 적이 없던 문제를 해결할 수 있어야 합니다. 라이브러리의 사용자, 즉 우리 자신이 어떤 가치를 얻어. 대단한 개발자가 아닌 이상 우리의 라이브러리가 웹 생태계의 고질적인 문제를 해결하여 대단한 가치를 제공하기는 어려울 겁니다. 그러나 '내가 직접, 원하는 것을 만들어볼 수 있다'라는 이 라이브러리만의 성질로 인해 얻어갈 수 있는 작고 소중한 가치들도 존재합니다.

그 중 하나는 단순한 아이디어를 검증하기입니다. 개발을 하다보면 때로 '이 방법을 사용하면 개발이 수월하지 않을까?'라거나, 'A와 B를 섞어서 사용하면 성능이 상승하지 않을까'라는 등의 발상이 떠오르기 마련입니다. 그러나 좋은 오픈소스 개발자가 마침 나와 똑같은 생각을 했던 게 아니라면, 가설에 불과한 이 아이디어들을 검증하기는 어려운 법이죠. 이 때 '검증하고자 하는 아이디어를 최대한 확실하게 기술'하고, 딱 '이 아이디어만을 검증하기 위한 최소한의 라이브러리'를 만들어 사용해보는 것은 좋은 경험이 될 수 있습니다.

또 다른 가치로는, 무언가의 동작 원리를 제대로 습득하기도 있습니다. React와 같은 고수준의 라이브러리들은 개발자들의 편의를 위해 내부의 복잡한 동작 방식을 잘 감춰두었습니다. 단순히 공식 문서를 읽거나 레포지토리를 들여다보는 정도로는 이해하기가 막막하죠. 이 때 좋은 라이브러리의 일부분을 공부하고, 이를 비슷하게 만들어보는 것은 좋은 공부의 출발점이 되곤 합니다. 서비스를 클론 코딩하며 실무 경험을 쌓듯, 일종의 라이브러리의 클론 코딩을 진행하는 것이죠.

아무리 고민해봐도 얻어갈 것이 없다면, 또는 목표가 너무 허황되어 보인다면 라이브러리 빠르게 다른 아이디어로 눈을 돌리는 것도 방법입니다. 조금 더 공부하다보면 내가 꼭, 직접 작성봐야 할 라이브러리가 눈에 보일 수도 있으니까요.

목표를 확실히 정했다면, 다음 단계는 MVP를 도출하는 것입니다. 라이브러리에 무슨 MVP냐 할 수도 있지만, 이는 우리가 언제까지 개발을 진행하고 언제 그만둬야 할 지를 판단하는 데 큰 도움을 준다는 점에서 아주 중요합니다. 좋은 MVP를 도출하는 방법에 대해서는 다음 글에서 살펴보도록 하겠습니다.