Config 파일과의 전쟁 (config 파일 작성 방법, 불러오기, 관리 방법)

🔶 Config 파일을 수정해야겠다

데이터 ETL 코드를 전체적으로 리팩토링 하고 있다. 환경도 다양하고, 데이터 타입도 다양하다 보니 ETL 환경 설정이 여러개인데, 전역 변수로 나와 있는 것들을 config로 다 정리해야겠다고 마음먹었다. 전역 변수로 적게 되면 오염될 가능성이 있고, 휴먼 에러가 발생할 확률이 높다. 그러나 이걸 config 파일에 한번에 정리해 두고, 검토만 한다면 휴먼 에러는 확실히 줄어들 것이다. 그리고 필요힌 변수를 받고, 만들어내는 과정도 config 파일에 잘 정의만 헤둔다면 줄일 수 있을 것이다.

 

❓그렇다고 config 파일이 없었냐?

그건 아니다. 암호화 정보나 DB 접속 정보 등 기본적인 것은 다 Config 파일로 관리하고 있다. 그러나 파일 경로와 접속 정보들이 파일 경로마다 달라졌다. Test를 할 때도 실제 운영 환경에서는 영향이 가면 안 되기 때문에 또 설정을 바꿔줬다. 이런 것들에 더이상 내 노동력을 쓰고 싶지 않다. 환경 이름만 바꾸면 알아서 도는 구성의 Config를 만들고 싶다.

 

 

---

 

🔶 첫 번째 수정 Config

{
  "dev": {
    "service1": {
      "API_KEY": "...",
      "ENDPOINT": "..."
    },
    "service2": {
      "API_KEY": "...",
      "ENDPOINT": "..."
    }
  },
  "prod": {
    "service1": {
      "API_KEY": "...",
      "ENDPOINT": "..."
    },
    "service2": {
      "API_KEY": "...",
      "ENDPOINT": "..."
    }
  }
}

 

심지어 이것도 고친 거라면 믿으시겠습니까? 원래는 dev 와 prod가 파일로 물리적으로 나누어져 있었고, 공통적으로 쓰이는 접속 정보만 config 파일 안에 있었다. 그러나 파일이 물리적으로 분리가 되어 있으니 dev와 prod 간 코드를 배포할 때 신경 쓰여서 두 개의 환경 변수를 한 파일에 관리하고자 합쳤다. 저런 식으로 바꾸면 배포할 때 신경 쓰지 않아도 되고, dev, prod 환경 이름만 바꿔 주면 해결된다.

 

그러나 문제점이 있었다. service 단위에서 겹치는 변수가 세네 개 정도가 되어 중복되는 게 많았다. 모든 서비스에서 겹치지 않고, 한두 개의 서비스에서만 중복되는 변수도 있었다. 서비스 단위가 아니라 dev-prod 간 중복되는 변수도 있었다. 총체적 중복 파티였다.

 

🔶 두 번째 수정 Config

{
  "dev": {
    "common": {
      "RETRY_COUNT": 3,
      "TEAM_NAME": "data",
      "TIMEZONE": "Asia/Seoul"
    },
    "service1": {
      "API_KEY": "service1-dev-key",
      "ENDPOINT": "https://dev.service1.example.com"
    },
    "service2": {
      "API_KEY": "service2-dev-key",
      "ENDPOINT": "https://dev.service2.example.com",
      "EXTRA_CONFIG": "some-value"
    }
  },
  "prod": {
    "common": {
      "RETRY_COUNT": 5,
      "TEAM_NAME": "data",
      "TIMEZONE": "Asia/Seoul"
    },
    "service1": {
      "API_KEY": "service1-prod-key",
      "ENDPOINT": "https://prod.service1.example.com"
    },
    "service2": {
      "API_KEY": "service2-prod-key",
      "ENDPOINT": "https://prod.service2.example.com"
    }
  }
}

 

리뷰도 하고 GPT 한테도 물어본 결과, 공통 의견은 common 항목을 만들어 중복된 변수를 묶으라는 것이었다. common 항목으로 중복된 변수를 묶었더니 훨씬 덜 피로해졌다. 

그러나

common 으로 묶인 변수들이 dev와 prod에서 또 또 또 겹쳤다 중복이 줄어들기는 했지만 완벽하게 줄어들지는 않아서 100퍼센트 만족스럽지는 않았다.

 

🔶 세 번째 수정 Config

🔸Config 폴더 구조

#config 폴더 구조
/config
├── base_config.json            # 모든 환경 공통
├── dev/
│   ├── base.json				# dev 공통 설정
│   ├── service1.json			# dev + service2 공통 설정
│   └── service2.json           # dev + service1 전용 설정
├── prod/
│   ├── base.json               # prod 공통 설정
│   ├── service1.json    		# prod + service1 공통 설정
│   └── service2.json           # prod + service2 전용 설정

 

• base_config.json: 모든 환경에서 공통으로 쓰는 설정 (TIMEZONE, SPARK_CONF 등)
• dev/base.json / prod/base.json: 각 환경의 공통 설정 (TEAM_NAME, RETRY, DEFAULT_TABLE_PATH 등)
• dev/service.json / prod/service.json: 서비스 전용 설정 (TABLE_INFO_PATH, USE_ENCRYPTION, SPECIAL_INDEX_HINTS 등)

 

모든 환경에서 공통으로 쓰는 설정을 두 번째 수정한 파일에서 추가해 버리면 depth 가 늘어나 보기 불편해졌다. 차라리 물리적으로 나눠 버리면 어떨까 싶어 위와 같이 config 구성을 바꾸었다. 이렇게 바꾸면 파일 하나당 depth가 1이 된다. 길이 자체도 길지 않아 읽기 편하다. 

 

장점

깔끔한 구조	파일 단위로 역할 분리 (env, service, global)
중복 최소화	공통 값은 base에 한 번만 정의
수정 용이성	환경/서비스 변경해도 다른 파일에 영향 없음
테스트 편의성	dev/prod 설정 따로 테스트 가능

 

단점

단점은 config 파일 개수가 늘어난다는 점이다. service 단위로 환경 변수를 파악하는데, 한 파일에서 확인하기 불편하고 base_config, env/base, service 순서로 내려와야 한 서비스 안에 쓰이는 환경 변수를 파악할 수 있다.

 

---

 

config 파일 구축 한번 잘해 놓으면 전체적으로 볼 일은 별로 없을 것 같아 단점을 감수하고 물리적으로 나누는 방법을 선택했다. 그러면 환경 공통 변수를 추가할 때 딱 한 번만 추가하면 된다. 바꿀 때도 딱 한 번만 손을 대면 된다. 테스트 용도나 특수한 환경에서는 service 단위별로 파일이 나누어져 있으니 service 파일에서만 수정하여 overwrite 해서 사용하면 된다. 지금 운영하고 있는 서비스에서는 이런 config 구조가 가장 적절하다.

 

json 파일

파일 하나하나 들여다보면 depth=1 인 일반적인 json 형태이다.

 

✅ /config/base_config.json

{
  "TIMEZONE": "Asia/Seoul",
  "SPARK_APP_NAME_PREFIX": "DataPipeline",
  "DEFAULT_NUM_PARTITIONS": 200
}

 

✅ /config/dev/base.json

{
  "LOG_LEVEL": "DEBUG",
  "TEAM_NAME": "data_dev",
  "DEFAULT_SAVE_FORMAT": "parquet"
}

 

 

✅ /config/dev/service.json

{
  "TABLE_INFO_PATH": "/dat/home/airflow/dags/table_list/data_info_dev.txt",
  "USE_ENCRYPTION": true,
  "SPARK_CUSTOM_CONF": {
    "spark.sql.shuffle.partitions": "50"
  }
}

파일의 개수는 많아졌지만 가독성은 훨씬 올라갔다.

 

🔶 Common 변수의 범위는?

어느 정도 구성을 마쳐 놓고 필요한 변수를 넣는데, 공통 설정의 범위를 어디까지 해야 하느냐가 고민이었다. 서비스가 네 개 있다고 치면, 그중에 2개의 서비스에만 겹쳐도 공통 변수에 넣어야 하는가, 4개의 서비스에서 모두 사용할 때만 공통 설정에 넣어야 하는가. 나는 전자가 맞다고 생각했다. 중복을 줄이려고 base 변수 파일을 만들어 관리하고 있는데 공통 변수의 조건을 엄격하게 잡으면 중복이 생겨나기 때문이다.

 

챗 GPT의 답변은 아래와 같다.

 

---

 

✅ "base_config에 넣을 수 있는 조건"

✅ 공통 사용 + 같은 의미 + 같은 값	"log_level": "INFO"처럼 공통 적용 가능한 경우	넣는 게 좋음
⚠️ 공통 사용 + 같은 의미 + 사용하는 서비스만 있음	"hdfs_base_path"가 2~3개 서비스에서만 사용, 나머지는 무시	⚠️ 조건부로 넣어도 됨
❌ 의미/형태가 다른 경우	"ftp_path" vs "hdfs_path"처럼 유사해 보여도 의미 다름	base에 넣으면 안 됨

---

😐 너 상황은?

• 변수를 쓰는 서비스도 있고, 안 쓰는 서비스도 있음
• 쓰는 서비스에서는 거의 같은 의미로 사용됨
• 나중에 새로운 서비스가 추가되면 이걸 사용할 가능성도 있음

→ 이럴 땐 넣어도 괜찮음!

단, 해당 서비스에서 아예 안 쓰면 영향도 없고,
설정 로딩 구조가 override 방식이라 나중에 다른 서비스에서 필요할 때만 쓰면 돼.

 

---

 

config를 불러오는 데에 그렇게 큰 리소스를 요구하지 않는다. 내 리팩토링의 목적은 "중복을 줄이자" 이다. 두 개 이상의 서비스에서만 겹쳐도 일단은 base 파일에 넣기로 했다. 다만, 지금은 서비스의 종류가 그렇게 많지 않기 때문에 할 수 있는 결정이다. 만약 환경 변수를 관리해야 하는 서비스의 종류가 열 종류를 넘어간다면 이 기준은 더 엄격해져야 할 듯하다.

 

🔶 Config를 불러올 때

config 파일을 분리하면서도 이걸 어떻게 불러오지 고민했다. 환경 이름과 서비스 이름을 변수로 받고 base+env_base+service 레이어처럼 받아올 수 있게 코드를 작성했다.

 

import os
import json


class ConfigLoadError(Exception):
    pass


def read_json_file(path: str) -> dict:
    """파일 존재 시 JSON 로딩, 없으면 빈 dict 반환"""
    try:
        with open(path, 'r') as f:
            return json.load(f)
    except FileNotFoundError:
        return {}
    except json.JSONDecodeError as e:
        raise ConfigLoadError(f"JSON 파싱 오류: {path}") from e


def get_env_config(base_path: str, env: str) -> dict:
    return read_json_file(os.path.join(base_path, env, "base.json"))


def get_service_config(base_path: str, env: str, service: str) -> dict:
    return read_json_file(os.path.join(base_path, env, f"{service}.json"))


def get_global_config(base_path: str) -> dict:
    return read_json_file(os.path.join(base_path, "base_config.json"))


def get_dag_config(dag_config_path: str) -> dict:
    return read_json_file(os.path.join(dag_config_path, "dag_config.json"))


def get_dag_common_config(dag_config_path: str) -> dict:
    return read_json_file(os.path.join(dag_config_path, "base_dag_config.json"))


def merge_dicts(*configs: dict) -> dict:
    merged = {}
    for config in configs:
        merged.update(config)
    return merged


def load_merged_config(env: str, dag_id: str) -> dict:
    base_path = "/path/to/config"
    dag_config_path = "/path/to/dags/dag_config"

    try:
        all_dag_config = get_dag_config(dag_config_path)
        dag_config = all_dag_config.get(dag_id)

        if not dag_config:
            raise ValueError(f"DAG 설정 없음: {dag_id}")

        service = dag_config.get("service")
        if not service:
            raise ValueError(f"DAG '{dag_id}'에 'service' 항목이 없습니다.")

        return merge_dicts(
            get_global_config(base_path),
            get_env_config(base_path, env),
            get_service_config(base_path, env, service),
            get_dag_common_config(dag_config_path),
            dag_config
        )

    except Exception as e:
        raise RuntimeError(f"설정 로딩 실패: {e}")
        
def load_env_config_file(env: str, filename: str) -> dict:
    """
    설정 파일 병합:
    - base_config.json (전역 공통)
    - {env}/base.json (환경 공통)
    - {env}/{filename} (서비스 전용)
    """
    base_path = "/path/to/config"
    
    global_config = read_json_file(os.path.join(base_path, "base_config.json"))
    env_base_config = read_json_file(os.path.join(base_path, env, "base.json"))
    service_config = read_json_file(os.path.join(base_path, env, filename))

    return merge_dicts(global_config, env_base_config, service_config)

 

실제 서비스에서는 코드를 수정했지만 전체적인 틀을 보면 이렇다. airflow를 같이 사용하고 있어서 dag_id를 넣으면 config를 불러올 수 있는 함수까지 만들었다.

 

일주일 동안 config 구성 짜느라 머리 굴렸는데 정작 글로 정리하니까 길지 않네..

 

config 구성은 예상보다 만족스럽다!! 이게 정답은 아니지만 지금 운영하고 있는 서비스에 최적화된 구조인 것 같다. 이제 config에 담을 수 있는 건 모조리 담아 버리고 적용할 차례이다. config 파일 관리는 어떻게 보면 정말 기본이지만 나는 이것도 몰랐기에..!! 중복 없이 잘 관리해 봐야지 😂