프로그래밍에서 자전거: 무엇인지, 원인과 피하는 방법

프로그래밍에서 자전거란 무엇인가

자전거는 개발자 커뮤니티의 용어로, 이미 기성 라이브러리, 프레임워크 또는 서비스로 제공되는 기능을 직접 구현하는 것을 뜻합니다. 영어권에서는 reinventing the wheel — 바퀴의 재발명이라는 표현을 사용합니다. 러시아어권 커뮤니티에서는 '자전거', '직접 구현', '자체 자전거' 같은 변형 표현도 볼 수 있습니다.

이 은유의 기원은 바퀴가 인류의 가장 오래된 발명품 중 하나라는 사실과 관련이 있습니다. 21세기에 바퀴를 다시 만들려는 시도는 무의미합니다. 프로그래밍에서도 비유는 더 정확합니다: 기성 라이브러리는 수천 명의 엔지니어가 수년간 최적화한 '바퀴'입니다. 품질이 낮은 자체 바퀴를 만드는 것은 자원 낭비입니다.

RedMonk은 분석 보고서(2023)에서 평균 상용 애플리케이션이 약 500개의 외부 의존성을 사용한다고 계산했습니다. 각각을 개발자가 직접 작성한다면 프로젝트 비용은 수십 배로 늘어나고 시장 출시 시간은 수년으로 늘어날 것입니다. 패키지 관리자(npm, Maven, PyPI, NuGet)의 생태계는 바로 자전거 발명을 피하기 위해 존재합니다.

자전거의 징후

자전거에 해당하는 코드는 몇 가지 징후로 알아볼 수 있습니다: 표준적인 작업을 비표준적인 방식으로 해결하고, 테스트나 문서가 없으며, 기성 라이브러리에서 이미 오래전에 처리된 edge case를 지원하지 않습니다. 종종 이런 코드는 프로젝트의 '고유한 요구 사항'을 가정하고 작성되지만, 실제로 그 요구 사항은 일반적인 것과 다르지 않습니다.

자전거와 커스텀 해결책의 차이

커스텀 해결책은 기성 라이브러리가 아키텍처 또는 라이선스 제약으로 맞지 않을 때 정당합니다. 자전거는 객관적인 이유 없이 — '재미로 해보고 싶다', 남의 코드에 대한 불신 또는 기존 도구를 모른다는 이유로 만들어집니다. 차이는 근본적입니다: 커스텀은 의식적인 선택이고, 자전거는 실수입니다.

개발자가 자전거를 발명하는 이유

첫 번째이자 가장 흔한 이유는 기존 해결책을 모르는 것입니다. 주니어 개발자는 표준 라이브러리에 JSON을 파싱하는 내장 함수가 있다는 것을 모를 수 있습니다. 대신 그는 파서를 직접 작성할 것입니다. 이 문제는 언어 생태계에 막 들어온 초보자에게 특히 관련이 있습니다.

두 번째 이유는 통제의 환상입니다. 경험 많은 개발자는 때때로 인기 라이브러리의 저자보다 '자신이 더 잘 쓸 수 있다'고 확신합니다. 통계는 그 반대를 말합니다: 수백만 프로젝트에서 사용되는 라이브러리의 오류 확률은 방금 작성된 코드보다 훨씬 낮습니다. Synopsys(2024)에 따르면 Open Source 코드는 천 줄당 평균 0.1개의 오류를 포함하고, 기업 코드는 1~2개를 포함합니다.

세 번째 이유는 재사용 문화의 부재입니다. 작업을 시작하기 전에 기존 해결책을 조사하는 것이 관례가 아닌 회사에서는 모든 개발자가 '자신만의 자전거'를 만듭니다. 이는 코드의 단편화를 초래합니다: 한 프로젝트에 서로 다른 직원이 작성한 HTTP 클라이언트 구현이 세 가지가 있을 수 있습니다.

심리적 측면

IKEA 효과는 사람이 직접 만든 것을 객관적으로 더 나은 기성품보다 높게 평가하는 심리 현상입니다. 프로그래밍에서 이는 '자신의 자전거'에 대한 자부심과, 명백한 장점이 있어도 기성 라이브러리로 교체하기를 꺼리는 것으로 나타납니다.

프로젝트에서 자전거를 만드는 것의 결과

경제적 결과가 가장 분명합니다. Stripe(2022)의 추정에 따르면 개발자는 작업 시간의 최대 35%를 이미 기성 해결책으로 존재하는 코드를 만드는 데 사용합니다. 10명 팀의 급여로 환산하면 매년 약 20만 달러가 자전거 발명에 쓰이는 셈입니다.

기술적 결과에는 코드베이스의 증가, 테스트 커버리지의 감소(직접 작성한 코드는 보통 테스트가 덜 됨), 버그와 취약점의 증가가 포함됩니다. 게다가 직접 작성한 각 구성 요소는 모니터링하고 유지보수해야 하는 또 하나의 장애 지점입니다.

Google은 'Why Google Stores Billions of Lines of Code'(2023) 연구에서 세계 최대 기술 회사에서도 새 의존성을 추가하거나 자체 구현을 작성할 때 엄격한 의사 결정 프로세스가 존재한다고 언급했습니다. 대부분의 내부 팀은 먼저 단일 코드 저장소에서 기성 해결책을 찾습니다.

팀에 미치는 영향

자전거는 정보 비동기화를 만듭니다: 한 개발자가 팀을 떠나면 그의 직접 작성한 구성 요소는 문서와 지원 없이 남습니다. 팀의 새 구성원은 비표준 코드를 이해하기 위해 시간을 들여야 하며, 이 시간을 생산적인 작업에 쓸 수 있었습니다.

코드에서 흔히 볼 수 있는 자전거의 예

가장 흔한 예는 JSON 또는 XML을 직접 파싱하는 것입니다. 거의 모든 현대 언어에 내장 수단이 있음에도 불구하고요. 개발자들은 JSON.parse()가 한 줄로 문제를 해결한다는 것을 모른 채 객체 트리를 탐색하는 재귀 함수를 작성합니다.

두 번째 예는 HTTP 클라이언트를 직접 구현하는 것입니다. 표준 라이브러리(fetch, axios, OkHttp, URLSession)는 캐싱, 재연결, 타임아웃, 보안을 지원합니다. 직접 작성한 클라이언트는 보통 이러한 요구 사항 중 하나도 고려하지 않아 프로덕션에서 버그를 일으킵니다.

세 번째 예는 SLF4J, Winston 또는 Log4j 대신 직접 작성한 로깅 시스템입니다. 개발자는 로테이션, 로깅 수준, 비동기 기록, 모니터링 시스템 통합을 지원하는 기성 라이브러리가 그대로 해주는 일을 하는 데 몇 주를 보냅니다.

# 자전거 — 수동 CSV 파싱
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# 대신 표준 라이브러리 사용
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

자체 ORM 안티패턴

자체 ORM(Object-Relational Mapping)을 작성하는 것은 아마도 가장 비용이 많이 드는 자전거입니다. Hibernate, Entity Framework, SQLAlchemy 같은 기성 ORM은 수년간 개발되어 캐싱, 지연 로딩, 마이그레이션, 수십 가지 DBMS를 지원합니다. 자체 ORM은 보통 하나의 데이터베이스로 제한되며 연결 관리에 심각한 오류가 있습니다.

자전거가 정당화되는 경우

학습은 자전거가 단지 정당할 뿐만 아니라 유용한 유일한 상황입니다. 학습 목적으로 자체 파서, HTTP 서버 또는 ORM을 작성하면 이러한 도구가 내부적으로 어떻게 작동하는지 이해하는 데 도움이 됩니다. 학습 프로젝트와 프로덕션 코드를 혼동하지 않는 것이 중요합니다: pet-프로젝트에 좋은 것은 상용 개발에는 허용되지 않습니다.

고유한 요구 사항은 실제로 자체 구현이 필요할 수 있습니다. 어떤 라이브러리도 특정 프로토콜, 데이터 형식 또는 하드웨어 플랫폼을 지원하지 않는다면 커스텀 해결책을 만드는 것이 정당합니다. 하지만 그 전에 작업이 정말 고유한지, 아니면 단지 제대로 연구되지 않았는지 확인해야 합니다.

라이선스 제약은 또 하나의 합법적인 이유입니다. 일부 Open Source 라이선스(GPL, AGPL)는 회사의 비즈니스 모델과 호환되지 않을 수 있습니다. 이런 경우 더 허용적인 라이선스로 자체 구현을 개발하는 것이 정당합니다.

세 번 시도하는 규칙

실용적인 규칙이 있습니다: 자체 구현을 작성하기 전에 세 가지 다른 기성 해결책을 찾아 테스트해 보세요. 어느 것도 맞지 않으면 직접 만들되, 기존 옵션을 거부한 이유를 문서화하세요. 이는 무의식적인 자전거 발명을 막아줍니다.

자전거를 만드는 것을 피하는 방법

첫 번째 단계는 어떤 일반적인 작업을 시작하기 전에 기성 해결책을 찾는 습관을 기르는 것입니다. 패키지 관리자, GitHub, Stack Overflow 검색을 사용하세요. 조사에 쓰는 시간은 자체 코드 작성을 포기함으로써 몇 배로 보상됩니다.

두 번째 단계는 자전거 발견에 초점을 맞춘 코드 리뷰를 도입하는 것입니다. 리뷰에서 '이 작업에 기성 라이브러리를 사용하지 않는 이유는 무엇인가?'라는 질문을 하세요. 답에 객관적인 이유가 없다면 그것은 자전거입니다. 대기업(Google, Meta)에서는 코드 리뷰에 자전거 발명 확인이 필수 항목으로 포함됩니다.

세 번째 단계는 내부 지식 저장소를 만드는 것입니다. 프로젝트에서 어떤 라이브러리와 도구를 사용하고 어떤 작업을 해결하는지 문서화하세요. 새 개발자는 무지로 인한 자전거를 만들지 않도록 이 정보에 접근할 수 있어야 합니다. 선택 근거와 함께 수용된 아키텍처 결정(ADR) 목록을 유지하세요.

• 조사하세요: 새 작업을 시작하기 전에 패키지 관리자를 확인
• 확인하세요: 언어의 표준 라이브러리 — 일반적인 작업의 80%를 커버
• 사용하세요: 자전거 발견을 위한 코드 리뷰
• 문서화하세요: 라이브러리 선택에 대한 결정
• 업데이트하세요: 컨퍼런스와 블로그에서 생태계 지식

Not Invented Here 증후군

NIH 증후군(Not Invented Here — '여기서 발명되지 않음')은 외부 해결책 사용에 대한 조직적 편견입니다. NIH 증후군이 있는 회사는 Open Source 라이브러리가 자체 개발보다 우수할 때에도 모든 것을 직접 개발하는 것을 선호합니다. 이 증후군은 자전거의 기업 버전입니다.

고전적인 예는 1990년대 후반의 Netscape입니다. 이 회사는 기존 코드베이스를 발전시키는 대신 브라우저를 처음부터 다시 작성하는 데 수년을 보냈습니다. 결과는 시장 점유율 상실과 AOL에 의한 흡수였습니다. 반대로 Android는 Linux 커널 위에 구축되고 수천 개의 Open Source 구성 요소를 사용합니다 — 이를 통해 제품을 기록적인 기간 안에 시장에 출시할 수 있었습니다.

Harvard Business Review(2023) 연구는 NIH 증후군 수준이 낮은 회사가 제품을 40% 더 빨리 시장에 출시하고 개발 비용을 30% 덜 쓴다는 것을 보여주었습니다. 코드 재사용 문화는 현대 개발에서 경쟁 우위입니다.

// 자전거 — 커스텀 정렬 구현
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// 내장 정렬 — 표준 해결책
arr.sort((a, b) => a - b);