데이터 엔지니어링에서의 Conf 파일 관리(쪼갤까, 합칠까)
모든 개발분야에서 그렇겠지만 데이터 엔지니어링에서도 Configuration 파일(conf 파일)이 데이터 파이프라인 설정, 데이터 소스 연결, 워크플로우 정의 등 핵심적인 역할을 합니다. 인프라가 복잡해질수록 함께 복잡해지는 구성 파일의 효율적인 관리와 유지보수를 위한 고민이 생기더라구요. 이번 글에서는 수많은 yaml파일을 쪼개는게 나은지 하나에 통합해서 관리하는게 나은지 감이 안 잡혀서 조사한 내용을 작성해보았습니다.
1. Configuration 파일의 역할
Configuration 파일은 데이터 엔지니어링에서 다음과 같은 목적으로 사용됩니다
• 데이터 소스 연결 정보: 데이터베이스 URI, API 키, 인증 정보 등을 관리
• 파이프라인 설정: ETL 작업, 데이터 처리 방식, 배치 스케줄 등 정의
• 환경 변수 관리: 개발, 스테이징, 프로덕션 환경별 설정 분리
2. Conf 파일 포맷
2.1. 데이터 포맷의 다양화
전통적으로 JSON이나 XML 형식이 널리 사용되었지만, 최근에는 더 가독성이 높고 간결한 형식이 선호되고 있습니다.
• YAML: 계층적 데이터 표현에 적합하며, Kubernetes, Ansible 등에서 많이 사용.
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: redis-leader-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: tkgs-storage-class-name
resources:
requests:
storage: 2Gi
• TOML: Python 기반 프로젝트에서 자주 활용되며, 간단하고 읽기 쉬운 형식. 계층구조를 허용
[server]
host = "localhost"
port = 8080
[database]
name = "my_database"
username = "admin"
password = "password123"
[servers]
# Indentation은 가능하지만 필요하지 않음
[servers.alpha]
ip = "10.0.0.1"
dc = "eqdc10"
• JSON: 여전히 직렬화 및 범용성 측면에서 널리 사용.
{
"이름": "홍길동",
"나이": 55,
"성별": "남",
"주소": "서울특별시 양천구 목동",
"특기": ["검술", "코딩"],
"가족관계": {"#": 2, "아버지": "홍판서", "어머니": "춘섬"},
"회사": "경기 수원시 팔달구 우만동"
}
• INI: 간단한 키-값 쌍으로 소규모 설정에 유리. 기계도 읽을 수 있어서 범용성이 높음
[server]
host = localhost
port = 8080
[database]
name = my_database
username = admin
password = password123
3. 설정 파일 다루기
위까진 conf파일의 기본적인 사용방법이고 아래 내용은 제가 요즘 가장 많이 다루는 YAML파일을 다루는 방식에 대한 트렌드입니다.
저는 데이터 파이프라인을 만들면서 필요한 정보들을 하나의 파일에 넣고 KEY값으로 DB명을 사용해서 작업하곤 했습니다. 관리해야하는 DB가 늘어날수록 DB별로 파일을 쪼개야 하는가?에 대한 고민이 들어 이를 해결하기 위해 작성하는 내용입니다. 결론부터 말하자면 모듈화된 YAML파일, 즉 쪼개진 파일을 더 선호한다고 합니다.
3.1. 하나의 YAML 파일에 모든 구성을 몰아넣는 방식
제 생각엔 YAML 파일은 key-value의 중첩형태로 되어있으니 내용이 아무리 많아도 관리하기 편하다고 생각해서 하나에 몰아넣고 작업하곤 했습니다. 하지만 프로젝트 부피가 커질 수록 몇천자가 넘는 줄을 보면서 이게 맞는가 고민하게되더라구요.
이 방식의 장점은 제가 생각한 바와 같았습니다.
장점
• 모든 설정이 한 파일에 있어, 파일을 열면 전체 구성을 한눈에 파악할 수 있습니다.
• 파일 경로를 따로 기억하거나 찾을 필요가 없어 관리가 간편합니다.
• 하나의 파일만 전달하면 되므로 간단한 프로젝트에서는 배포 과정이 단순화됩니다.
• 다른 설정과의 관계를 한 파일 안에서 정의하므로 의존성과 참조를 관리하기가 더 직관적입니다.
이러한 장점들에도 불구하고 제가 겪은 바와 같은 단점들이 있었습니다.
단점
• 파일이 커지면 특정 설정을 찾거나 수정하기가 어려워질 수 있습니다.
• 여러 사람이 동시에 수정하려면 충돌이 발생하기 쉽습니다.
• 개발, 테스트, 프로덕션 환경별 설정이 한 파일에 섞이면 실수로 잘못된 설정을 배포할 가능성이 높습니다.
결국은 소규모 프로젝트에서 사용하면 좋은 방식인거고 단일 사용자가 주로 관리하는 경우에는 적합해보였습니다.
3.2 YAML 파일을 여러 개로 나누는 방식
저도 현재는 가독성 문제때문에라도 파일을 여러개 쪼개서 관리하고 있습니다. 종종 경로문제 때문에 번거롭다고 느끼긴 하지만 그래도 가독성 측면에서 크게 향상됨을 느꼈습니다.
YAML을 여러개의 파일로 관리할 때의 장점입니다.
장점
• 개발, 테스트, 프로덕션 환경별로 파일을 나누어 설정을 독립적으로 관리할 수 있습니다.
• config.dev.yaml, config.prod.yaml처럼 파일을 나누면 실수를 줄이고 명확성을 높일 수 있습니다.
• 공통 설정은 별도의 파일로 분리(common.yaml)하여 환경별 파일에서 이를 참조하도록 구성할 수 있습니다.
• 파일이 작아져 특정 파일만 수정하면 되므로 협업 시 충돌 가능성을 줄일 수 있습니다.
• 프로젝트가 확장될 때 새로운 설정을 추가하기 쉽습니다. 새로운 도메인이나 기능별로 파일을 추가하면 됩니다.
단점
• 파일이 많아지면 경로를 기억하거나 참조 관계를 관리하기가 번거로울 수 있습니다.
• 잘못된 참조로 인해 문제가 발생할 가능성이 있습니다.
• 모든 설정을 한 번에 보고 싶을 때 여러 파일을 열어야 하므로 번거로울 수 있습니다. (이게 진짜 번거로워요..)
프로젝트가 커질수록 하나의 파일에서 관리하기엔 무리가 따릅니다. 이럴 땐 파일을 여러개로 쪼개고 경로를 잘 설정하면서 작업하면 될 것 같습니다.
반복이 걱정된다면 common.yaml로 빼놓고 반복해서 설정을 사용할 수 있으니 깔끔하게 관리가 가능합니다.
4. 결론
결론적으론 소규모 프로젝트에서는 YAML 파일을 하나로 몰아넣어 관리의 단순성을 유지하는 것이 좋아보입니다. 프로젝트 규모가 커질 수록 YAML 파일을 환경별 또는 기능별로 나누어 모듈화하는 방식이 유지보수와 확장성 측면에서 더 적합할 듯 합니다.
적고나니 별거 없는 당연한 사실들같지만.. 막상 공부해보니 다음에 누가 yaml파일이 왤케 많냐 왤케 쪼개놨냐고 말하면 대답할 수 있을 것 같네요.ㅎㅎ
이 내용은 설정 파일 뿐만 아니라 웬만하면 통용되는 장단점일 듯 합니다. 경로를 쪼갠다거나 파일을 쪼개는 내용 등이요. 프로젝트 규모와 관리 능력 등을 고려하여 조절해나가야겠습니다.