소프트웨어 포크 (Software Fork)
소프트웨어 포크(software fork)는 기존 프로젝트의 소스 코드를 복사해 독립적으로 개발을 이어 가는 별도 프로젝트를 만드는 일입니다. 오픈소스 라이선스가 허용하는 범위에서 누구나 코드를 가져가 다른 방향으로 발전시킬 수 있으며, 이는 블록체인 자체가 둘로 갈라지는 '하드 포크·소프트 포크'와 구별해야 합니다.
자세히 알아보기
포크는 보통 두 가지 이유로 생깁니다. 첫째, 원래 프로젝트의 개발 방향이나 운영 방식에 동의하지 않는 개발자들이 따로 나가는 경우입니다. 둘째, 검증된 코드를 바탕으로 새로운 기능을 붙인 제품을 빠르게 만들고 싶은 경우입니다. GitHub의 'Fork' 버튼처럼 기여를 위해 개인 사본을 만드는 것도 같은 말을 쓰지만, 여기서 말하는 포크는 독립 프로젝트로 갈라지는 것을 뜻합니다.
포크가 가능한지는 라이선스가 결정합니다. MIT·Apache 같은 허용적 라이선스는 거의 제약 없이 포크를 허용하고, GPL 계열은 파생 코드도 같은 조건으로 공개하도록 요구합니다. 반대로 일정 기간 상업적 사용을 막는 소스 공개형 라이선스(예: BSL)를 쓰는 프로젝트도 있습니다.
블록체인·암호화폐에서는
암호화폐 생태계는 포크 위에서 성장했습니다. 라이트코인은 2011년 비트코인 코드를 포크해 해시 알고리즘(scrypt)과 블록 생성 간격(약 2.5분) 등을 바꿔 만들어졌고, BNB 스마트 체인과 폴리곤 PoS의 노드 클라이언트는 이더리움 클라이언트 Geth를 포크한 것입니다. DeFi에서는 2020년 스시스왑이 유니스왑 v2 코드를 포크해 등장한 사례가 유명합니다.
중요한 차이는 이렇습니다. 소프트웨어 포크는 코드만 복사하므로 기존 체인의 거래 기록이나 잔액을 가져가지 않습니다. 새 체인은 제네시스 블록부터 시작합니다. 반면 블록체인 하드 포크는 같은 기록을 공유하던 체인이 특정 블록 높이에서 둘로 갈라지는 것이어서, 분기 시점의 잔액이 양쪽 체인에 모두 존재하게 됩니다(예: 2017년 비트코인과 비트코인 캐시).
포크 프로젝트를 사용할 때는 원본에서 수정된 보안 패치가 포크에 반영되었는지 확인해야 합니다. 원본의 취약점을 그대로 물려받는 경우가 많기 때문입니다.
장점과 단점
- 맞춤화: 기존 코드를 처음부터 다시 쓰지 않고 특정 요구에 맞게 기능, 거버넌스 구조, 기반 기술을 바꿀 수 있습니다.
- 혁신: 새 기능을 실험할 수 있고, 검증된 기능이 원래 프로젝트에 다시 반영되기도 합니다.
- 파편화: 여러 포크가 사용자 기반과 개발 인력을 나눠 전체 진행을 늦출 수 있습니다.
- 호환성 문제: 포크가 원본이나 다른 포크와 호환되지 않으면 지갑, 거래소 연동 등에서 통합 문제가 생깁니다.
- 유지 관리 부담: 독자 기능을 지키면서 원본의 변경을 계속 따라가려면 상당한 노력이 필요합니다.
쉽게 말하면
남의 요리 레시피를 복사해 내 식당에서 재료를 바꿔 새 메뉴로 내놓는 것과 같습니다. 레시피만 가져갈 뿐, 원래 식당의 손님이나 매출은 따라오지 않습니다.
예시
어떤 DEX의 스마트 컨트랙트 코드를 그대로 복사해 수수료 비율과 토큰 이름만 바꿔 다른 체인에 배포했다면, 이는 소프트웨어 포크입니다. 원본 DEX의 유동성이나 이용자 잔액은 새 DEX로 넘어오지 않으며, 새 DEX에는 처음부터 새로 유동성이 공급되어야 합니다.
이 글은 학습을 위한 일반 정보이며 투자 권유나 법률 자문이 아닙니다. 가상자산은 가격 변동이 크고 원금 손실 위험이 있습니다.