외부 오픈소스를 우리 환경에 맞게 고쳐 쓰면서 이미지 빌드 중에 패치를 적용하는 방식을 쓰고 있었다. 지저분해 보여서 포크를 떠서 소스를 직접 관리하는 편이 낫지 않을지 검토했다.
Table of contents
Open Table of contents
upstream 구조 확인
전환하려면 upstream 구조를 알아야 해서 저장소를 직접 읽었다. 먼저 Dockerfile이 둘이었는데 데이터베이스를 이미지 안에 넣는 형태와 외부 데이터베이스에 연결하는 형태였다.
우리는 외부 데이터베이스를 쓰므로 뒤의 것이 기반이 돼야 하고 지금도 맞게 쓰고 있었다. 이 확인이 전환 계획의 첫 줄이 됐다.
잘라 내는 의존 오버라이드
패키지 설정에는 버전이 고정돼 있는데 그 아래 로컬 경로 오버라이드 섹션이 있었다. 그 섹션이 이기면 배포된 패키지 대신 로컬 소스를 쓴다.
그런데 Dockerfile이 빌드 시점에 그 섹션을 잘라 내고 있었다. 즉 로컬 소스를 직접 쓰려면 그 잘라 내기를 없애면 되고 포크해서 소스를 직접 관리한다는 계획의 구체적 방법이 그 한 줄에 있었다.
갈라진 구조
여기서 계획이 뒤집혔다. upstream의 메인 파일은 900여 줄이고 설정과 모델과 서비스와 유틸이 서브모듈로 분리돼 팩토리 패턴으로 여러 제공자를 지원하고 있었다.
우리 판은 1,400여 줄의 단일 파일 모놀리식이었다. 우리 판이 옛 버전에서 갈라져 나와 계속 붙여 온 사이에 upstream은 구조를 갈아엎은 것이다.
깨진 전제
포크 방식의 전제는 upstream 변경을 우리 포크에 병합하고 충돌만 해결하는 것이다. 구조가 다르면 이것이 성립하지 않는다.
파일이 쪼개졌으므로 우리 쪽 변경이 어느 파일로 가야 하는지를 매번 사람이 판단해야 하고 자동 병합이 전부 충돌이 된다. 포크하면 관리가 쉬워진다는 전제가 깨졌으므로 전환을 접고 현재 패치 방식을 유지하기로 했다. 지저분하지만 패치 파일이 곧 우리 변경 목록이라 어디를 고치는지가 명시돼 있다.
접은 결정의 기록
전환을 접었다고 조사가 헛된 것은 아니어서 결과를 기록에 남겼다. 향후 포크로 전환하면 어느 Dockerfile을 기반으로 하고 어느 잘라 내기를 제거해야 하는지와 구조가 정렬되기 전에는 관리가 불가능하다는 것을 적었다.
언제 다시 검토할지의 조건도 함께 적었다. 접은 이유를 안 남기면 몇 달 뒤에 누가 같은 검토를 반복하는데 지저분한 것을 보면 누구나 같은 생각을 하기 때문이다. 구조가 갈라져서 관리가 안 된다는 한 줄이면 다음 사람이 바로 안다.
정리
- 전환을 검토할 때 upstream 구조를 먼저 읽는다
- 빌드 스크립트가 의존 설정을 손대고 있을 수 있다
- 구조가 갈라졌으면 포크의 전제가 깨진다
- 지저분해도 어디를 고치는지 명시된 방식이 나을 때가 있다
- 접은 결정도 조사 결과와 함께 남긴다
- 언제 다시 볼지의 조건을 적으면 다음 검토가 싸진다
- 안 남기면 몇 달 뒤에 같은 검토가 반복된다