들어가며
실무에서 사용하는 오픈소스가 요구사항을 "거의" 충족하지만, 딱 하나가 안 되는 경우가 있다. 이때 선택지는 보통 세 가지다:
1.
다른 방식으로 직접 구현
2.
다른 레이어에서 우회
3.
오픈소스를 커스텀
이 글에서는 실제로 오픈소스 커스텀을 선택했던 경험을 바탕으로, 의사결정 프레임워크를 정리한다.
상황: "거의 다 되는데, 하나가 안 된다"
예를 들어, 어떤 파이프라인 프레임워크의 Sink Connector가 JSON 직렬화만 지원하는데, 우리 환경에서는 Avro + Schema Registry가 필수인 상황이라고 가정하자.
이 프레임워크를 쓰면 파이프라인 정의가 YAML 몇 줄로 끝나고, 직접 코드를 작성하면 수백 줄의 코드와 테스트가 필요하다. 포기하기엔 아깝고, 강행하기엔 막히는 지점이 있다.
세 가지 선택지의 트레이드오프
선택지 1: 다른 방식으로 직접 구현
프레임워크를 버리고, 필요한 기능을 직접 코드로 구현한다.
장점: 완전한 제어가 가능. 어떤 요구사항이든 구현할 수 있다.
단점: 프레임워크가 제공하던 편의성을 포기해야 한다. 개발 비용이 높다. 프레임워크가 해주던 에러 핸들링, 재시도, 메트릭 수집 등을 직접 구현해야 한다.
언제 선택하는가: 커스텀 범위가 너무 넓어서 오픈소스의 핵심 구조를 건드려야 할 때. 또는 프레임워크 자체가 해당 유스케이스를 지원할 설계가 아닐 때.
선택지 2: 다른 레이어에서 우회
프레임워크는 그대로 두고, 앞이나 뒤에서 변환한다. 예를 들어 JSON으로 먼저 내보낸 뒤, Consumer 쪽에서 Avro로 변환한다.
장점: 프레임워크 코드를 건드리지 않아 유지보수 부담이 없다.
단점: 아키텍처 복잡도가 증가한다. 변환 레이어가 추가되므로 장애 포인트가 늘어난다. 타 부서 협의가 필요할 수도 있다.
언제 선택하는가: 커스텀 범위가 작고, 변환 로직이 단순할 때. 또는 오픈소스의 라이선스가 커스텀을 허용하지 않을 때.
선택지 3: 오픈소스 커스텀
오픈소스 코드를 포크하거나, 확장 포인트를 활용하여 필요한 기능을 추가한다.
장점: 프레임워크의 편의성을 유지하면서 요구사항을 충족할 수 있다.
단점: 유지보수 부담이 가장 크다. 원본 오픈소스가 업데이트되면 머지 충돌이 발생할 수 있다. 문서화가 부족하면 인수인계가 어렵다.
언제 선택하는가: 커스텀 범위가 명확하고, 프레임워크의 확장 포인트(인터페이스, 플러그인 구조 등)가 잘 설계되어 있을 때.
의사결정 프레임워크
다음 질문들을 순서대로 던져보면 선택지를 좁힐 수 있다:
Q1. 커스텀 범위가 프레임워크의 핵심 구조를 건드리는가?
핵심 구조(파서, 스케줄러, 코어 모듈 등)를 건드려야 하면 → 직접 구현
확장 포인트(Serializer, Plugin, Hook 등)만 건드리면 → Q2로
Q2. 우회할 수 있는 다른 레이어가 있는가?
우회가 가능하고, 변환 로직이 단순하면 → 다른 레이어에서 우회
우회가 불가능하거나, 아키텍처 복잡도가 과도하게 증가하면 → Q3으로
Q3. 유지보수 비용을 감당할 수 있는가?
문서화, 버전 업그레이드 대응, 인수인계 등의 비용을 감당할 수 있으면 → 오픈소스 커스텀
감당하기 어려우면 → 직접 구현이 장기적으로 나을 수 있다
커스텀을 선택했다면: 유지보수 부담 줄이기
1. 커스텀 범위를 최소화하라
원본 코드를 가능한 한 적게 수정하고, 확장 포인트를 최대한 활용하라. "원래 코드에서 무엇을 바꿨는지"를 한 테이블로 정리할 수 있을 정도로 범위를 좁히는 것이 이상적이다.
2. 문서화에 투자하라
커스텀 오픈소스의 가장 큰 리스크는 "이걸 만든 사람이 나가면 아무도 모른다"는 것이다. README, 설정 옵션 테이블, 예제 파이프라인 등을 꼼꼼히 작성하라. AI 에이전트를 활용하면 이 부담을 크게 줄일 수 있다.
3. 원본 버전과의 차이를 추적하라
원본 오픈소스의 어떤 버전을 기반으로 커스텀했는지 명시하고, 원본이 업데이트될 때 어떤 부분을 확인해야 하는지 문서화하라.
같은 문제, 다른 선택
흥미로운 점은, 같은 팀에서도 상황에 따라 다른 선택을 할 수 있다는 것이다.
예를 들어, MongoDB CDC에는 "직접 구현"을, PostgreSQL CDC에는 "오픈소스 커스텀"을 선택할 수 있다. MongoDB는 프레임워크가 해당 소스를 지원하지 않아 직접 구현이 불가피했고, PostgreSQL은 프레임워크가 소스를 지원하되 Sink 직렬화만 추가하면 됐기 때문이다.
기술 선택은 맥락에 따라 달라진다. 중요한 것은 "왜 그 선택을 했는가"를 설명할 수 있는 것이다.
결론
오픈소스 커스텀은 "편의성을 유지하면서 요구사항을 충족하는" 매력적인 선택지다. 하지만 유지보수 비용이 보이지 않는 곳에서 쌓이므로, 의사결정 시점에 이 비용을 명시적으로 고려해야 한다.
그리고 한 번 결정하면, 그 결정의 근거를 문서로 남겨라. "왜 커스텀했는가", "다른 선택지는 왜 기각했는가" — 이 기록이 6개월 뒤 유지보수할 자신에게, 또는 인수인계 받는 동료에게 가장 큰 도움이 된다.
