INI

INI는 오래된 전통 설정 파일, 윈도우 시스템에서 많이 쓴다. 주석도 지원하고 가독성도 좋지만 계층구조를 표현하기가 어렵다. 계층구조를 표현하려면 섹션 아래 키를 .(dot) 기반으로 네임스페이스로 표현해야 한다.

conf, cfg

유닉스에서 많이 쓴다. 그러나 내부 형식은 프로그램마다 다르다. 문법적 요소보다 '어떤데 쓰이는 설정 파일이다' 라는 의미를 더 부각시켜서 알아보기 쉽고, 모아보기 쉽게 하는데 의미를 더 두는게 아닌가 생각한다. ini도 initialize의 앞자이고 conf나 cfg도 configuration을 뜻하는 것이니...

json, xml

데이터 전송할 때 쓰이는 표준 규격이기도 하면서 설정파일 역할도 수행할 수 있다. xml과 json은 파싱 속도와 정보 표시량에서 각각 다르지만 요즘같이 하드웨어가 좋은 시대에 파싱 속도와 코드량 많은게 별 대수는 아닌것 같다. 두 규격다 데이터를 계층 구조로 표현할 수 있어서 좋다.

JSON은 웹에서 xml은 하드웨어 메니페스트 쓸 때 많이 본 것 같다. json은 파이썬과 자바스크립트에서 빌트인 패키지로 파싱할 수 있고, 딕셔너리 구조라서 파이썬과 js와 상성이 좋다. 특히 파이썬에서는 딕셔너리를 바로 클래스 멤버변수로 할당 할 수 있어서 좋다. 그러나 주석을 달 수 없다. 문법적 검사를 할 수 있지만 주석 못다는게 아주 사소하게 불편하다.

참고로 xml도 윈도우 닷넷이 ini처럼 많이 좋아한다.

toml, yaml

toml과 yaml도 키-값 방식인데 표현 방식이 조금 다르다. 좀더 가독성 좋다. 마치 노트에 사람이 쓰는 것처럼 흐름이 자연스럽다.
ansible이나 깃헙 액션같은데 스크립트어로 많이 쓰인다.

toml은 잘 모르겠지만 yaml은 방언이 있어서 안 맞는 문법이 있을 수 있다. 그런데 아직까지 본적도 없고 점점 자리를 잡아가서 표준어만 쓰는 것 같기에 별로 상관은 없는듯.

주석도 지원하고 계층구조도 지원하고 멀티라인 쓰는것도 좋고 가독성도 좋은데 아직까지 ini와 json에 비하면 오래 널리 사용된 것은 아니라 모든 랭귀지가 빌트인 파서를 가지고 있지 않는게 소소한 단점이다.

config.py, config.js, config.cs 등등 스크립트 언어에서 같은 코드 파일로 쓰기

config.py나 config.js 등 코드 파일 확장자로 저장하면 인터프리터가 바로 읽어올 수 있는데 장점이 있다. 파서 없이 바로 로드되는 것이 큰 장점이다. 그러나 이 경우는 해당 코드에 종속되는 것으로 API키 같이 사용자가 플랫폼에서 어떤 랭귀지로 개발할지 모르는 환경에서는 사용하면 안된다. 또, 하나의 프로젝트안에 이 설정을 참고하는 다른 언어나 프로그램 또는 스크립트가 있을 경우도 마찬가지 이다.
file
<이미지 참고: https://en.wikipedia.org/wiki/TOML>