들어가며
바퀴를 다시 발명하지 마라는 유명한 프로그래밍 격언이다. 이미 만들어져있는 것을 다시 만들지 마라는 것이다. 이미 구현되어 있는 기능을 동일하게 다시 만드려고 하는 경우를 의미한다.
개발자 A의 사례
예를 들어 시간을 특정한 형식으로 보여주는 기능이 필요한 개발자 A가 있다고 하자. 이 기능은 라이브러리를 통해 제공되어 사용할 수 있다.
개발자 A에게는 선택지가 있다. 첫번째로 기존에 개발된 라이브러리를 사용하는 것이다. 두번째는 동일한 기능을 자신이 직접 한땀한땀 다시 만들 수 있다. 동일한 기능을 굳이 다시 만드는 이러한 경우를 바퀴를 다시 발명했다라고 한다.
A는 왜 바퀴를 다시 발명했을까? 여러가지 이유가 있을 수 있다. 라이브러리가 이미 존재한다는 사실을 몰랐을 수도 있고, 해당 라이브러리의 사용법을 이해하지 못했거나, 단순히 동작하는 방식이 마음에 들지 않아서 일 수 있다.(사실 동작하는 방식이 마음에 들지 않았다는 이야기는 사용하는 방법을 이해하지 못한 것에 대한 A의 변명일 가능성이 크다.)
그러나 개발자 A는 자기 자신만의 바퀴(직접 만들어서 사용한 기능)에 애착과 자부심을 가질 가능성이 크다. 이는 문제의 씨앗이 될 수 있는데 아래에서 이야기하겠다.
이미 만들어져 있는 것을 왜 다시 만들지 말아야 할까?
이미 만들어져 있는 것을 왜 다시 만들지 말아야 할까? A의 사례에서 다시 살펴보자
바퀴를 재발명하는 행위는 시간을 낭비한다
A는 라이브러리를 사용했더라면 아낄 수 있는 시간을 직접 구현해서 시간을 낭비했다. 개발자의 시간은 무한하지 않기 때문에 추가적인 비용이 발생했다고 볼 수 있다. '라이브러리의 난이도가 높기 때문에 오히려 시간이 절약됐다'라고 이야기 할 수도 있다. 과연 그럴까? 이에 대해서는 아래에서 더 살펴보겠다.
바퀴를 재발명하는 행위는 유지 보수를 어렵게 한다.
개발자 A가 사용한 기능은 유지보수가 어려워진다. 개발자 A의 동료 개발자 B가 A의 코드를 읽어나갈 때 라이브러리를 사용했다면 관련 문서나 구글링을 하면 알 수 있는 동작 방법을 A에게 직접 물어봐야한다. A가 없다면 B가 직접 코드를 읽고 해석해야 한다.
장기적으로는 해당 기능을 라이브러리를 사용하는 것으로 바꿔가야한다. 하지만 위에서 이야기한 것처럼 `개발자가 자신의 바퀴에 애착을 가지는 경우`가 있다. 이런 경우 A가 "제 코드는 완벽하게 동작하고 문제 없어요!"라며 거부 반응을 일으킬 수 있다. 이런 경우 A의 코드는 장기적으로 다른 개발자들의 자원까지 함께 갉아먹게 된다.
재발명된 바퀴는 기존의 바퀴보다 안정성이 떨어진다.
개발자 A가 직접 개발한 기능은 많은 사용자가 사용하는 라이브러리보다 문제가 발생할 여지가 더 크다. 어떤 개발자의 실력이 뛰어난지의 문제가 아니다.
많은 유저들이 사용하는 라이브러리는 안정적이다. 개발자들이 라이브러리를 사용할 때마다 라이브러리는 테스트를 받게 된다. 100명이 성공적으로 사용한 라이브러리라면 적어도 100명의 테스트를 거친 셈이다.
반면 개발자 A의 바퀴는 오직 1명 그것도 바퀴의 동작과 사용 방법을 이해하고 있는 사람의 테스트를 거쳤다. 안정성 면에서 많은 사람들의 검증을 거친 라이브러리가 우세할 가능성이 높다.
맺으며
위의 사례가 모든 케이스에 부합하지는 않을 것이다. 학습을 위해서 바퀴를 재발명해보는 케이스도 있을 것이다. 혹은 아주 작고 간단한 기능이기 때문에 직접 구현해서 사용할 수 있다. 기존에 존재하던 기능에 문제가 있거나 개선을 위해 다시 개발하는 경우가 있을 수 있다. 이러한 경우는 바퀴를 다시 발명했다고 보기보다는 개선으로 보는 것이 옳을 듯 하다.
키보드를 잡기에 앞서 내가 바퀴를 다시 발명하고 있지는 않은지 자문하며 스마트한 개발을 하자.