-
반응형
이번 글에서는 설정 파일에 대한 이야기를 하려고 한다. 개발을 할 때 설정 파일 포맷을 직접 만들어서 개발하는 경우가 있는데 사실 아래와 같은 경우가 아니라면 이미 잘 만들어진 포맷들을 이용하는 것이 좋다.
- 잘 알려진 설정 포맷들이 내가 원하는 기능을 지원하지 않을 때
- 다양한 멀티 플랫폼을 고려해야할 때
원하는 기능을 제공하지 않는 경우는 할 이야기가 없지만, 멀티 플랫폼 고려에 대해서는 apache와 nginx를 소개하려 한다. apache, nginx 웹 서버에서 사용하는 설정 포맷은 ini 스타일과 비슷하지만 독자 스펙으로 개발되었다. 왜냐하면 다양한 플랫폼을 고려해야하기 때문이다. 그도 그런 것이 다양한 플랫폼에서 설정 포맷 라이브러리가 모두 지원되리라는 법이 없기 때문에 이런 경우는 만들어서 사용하는 것이 좋다. 그런 이유로 개발 언어를 선택할 시 대부분 C가 채택된다.
참고: nginx에서 지원하는 플랫폼
- FreeBSD 3 — 11 / i386; FreeBSD 5 — 11 / amd64;
- Linux 2.2 — 4 / i386; Linux 2.6 — 4 / amd64; Linux 3 — 4 / armv6l, armv7l, aarch64, ppc64le;
- Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v;
- AIX 7.1 / powerpc;
- HP-UX 11.31 / ia64;
- macOS / ppc, i386;
- Windows XP, Windows Server 2003.
하지만 독자 스펙의 설정 파일을 사용나는 경우, 최초 개발 당시에는 문제가 없었을 수도 있겠지만 유지보수를 하게 되면서 새롭게 나타나는 버그들을 고려했을 때 이 또한 비용이 있는거라 할 수 있다. 설정 관련하여 기능 개선이나 버그를 고칠 시간에 다른 일을 할 수 있기 때문이다.
우리가 사용하는 수 많은 제품들은 직접 만든 설정 파일 포맷을 사용하지 않는다. 안드로이드 UI는 xml 기반으로 작성되며 virtuabox의 프로젝트 설정 파일 또한 xml 기반으로 작성한다. linux system daemon들은 대부분 ini 스타일을 따르게 되고 최근에는 yml이나 toml과 같은 형태도 종종 사용하는 것을 보게 된다. 참, github에 연동되는 travis CI 설정은 yml 포맷을 따른다.
설정 파일 포맷들이 어떤 장단점이 있는지를 알아야 선택하기 수월하다. 아래 예시들과 정의는 위키피디아에서 발취했다.
ini
; 주석입니다 [database] server=1.1.1.1 port=143 file="payroll.dat"
INI(Initialization) 파일 포맷은 설정 파일에 대한 de facto 표준이다. INI 파일은 단순 구조의 텍스트 파일로 이루어져 있다. 보통 마이크로소프트 윈도와 연결되어 있지만 다른 운영 체제에서도 사용할 수 있다. INI 파일이라는 이름은 ".INI"라는 파일 확장자가 따라오지만, ".CFG", ".conf", ".TXT" 등의 다른 확장자를 사용하기도 한다. ini 스타일은 전형적인 key=value 로 작성되며, [SECTION]으로 설정들을 그룹화하여 관리할 수 있다. 단순하게 사용할 수 있는 장점이 있지만 key간 depth를 주거나 value에 또다른 key를 넣는 계층 설정은 불가능하다.
C++에서는 boost 라이브러리를 사용하면 손쉽게 ini 파일 포맷을 활용할 수 있다.
- http://www.boost.org/doc/libs/1_60_0/doc/html/property_tree/parsers.html
xml
<VirtualBox xmlns="http://www.virtualbox.org/" version="1.16-macosx">
<Machine uuid="{6df93114-c25d-4365-9055-a95c98dcaf8e}" name="Hadoop" OSType="Ubuntu_64" snapshotFolder="Snapshots" lastStateChange="2017-04-28T06:13:50Z">
<MediaRegistry>
<HardDisks>
</HardDisks>
<DVDImages>
</DVDImages>
</MediaRegistry>
<ExtraData>
<ExtraDataItem name="GUI/LastCloseAction" value="PowerOff"/>
<ExtraDataItem name="GUI/LastNormalWindowPosition" value="246,146,800,621"/>
<ExtraDataItem name="GUI/RestrictedRuntimeDevicesMenuActions" value="HardDrives"/>
<ExtraDataItem name="GUI/RestrictedRuntimeMachineMenuActions" value="SaveState,PowerOff"/>
<ExtraDataItem name="GUI/StatusBar/IndicatorOrder" value="HardDisks,OpticalDisks,FloppyDisks,Network,USB,SharedFolders,Display,VideoCapture,Features,Mouse,Keyboard"/>
</ExtraData>
</VirtualBox>
XML(Extensible Markup Language)은 W3C에서 개발된 마크업 언어이다. XML은 SGML의 단순화된 부분집합으로, 다른 많은 종류의 데이터를 기술하는 데 사용할 수 있다. XML은 주로 다른 종류의 시스템, 특히 인터넷에 연결된 시스템끼리 데이터를 쉽게 주고 받을 수 있게 하여 HTML의 한계를 극복할 목적으로 만들어졌다. 다만 아래에서 이야기할 json에 비해 덩치가 크다는 단점이 있어 요즘 웹에서는 xml 보다는 json을 많이 활용하는 편이다. 오히려 프로그램들이 xml 포맷을 설정 파일로 많이 채택하여 사용하고 있다. Tag를 활용하여 key/value 설정이 가능하며 바이너리 데이터를 제외하고는 대부분의 설정 표현이 가능하다. 주석 또한 작성할 수 있다.
json
1 { 2 "이름": "테스트", 3 "나이": 25, 4 "성별": "여", 5 "주소": "서울특별시 양천구 목동", 6 "특기": ["농구", "도술"], 7 "가족관계": {"#": 2, "아버지": "홍판서", "어머니": "춘섬"}, 8 "회사": "경기 수원시 팔달구 우만동" 9 }
JSON (JavaScript Object Notation)은 경량화된 데이터 직렬화 형식이다. 이 형식은 사람이 읽고 쓰기에 용이하며, 기계가 분석하고 생성함에도 용이하다. JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999의 일부에 토대를 두고 있다. json 포맷도 설정 파일로 활용되는 경우가 많다. key/value로 저장이 가능하며 계층 설정 뿐 아니라 array 설정까지 가능하다. 거의 대부분의 언어에서 지원한다는 큰 장점을 가지고 있지만 주석(comment)을 사용할 수 없는 불편함을 가지고 있다.
yaml
--- # Favorite movies, block format - Casablanca - Spellbound - Notorious --- # Shopping list, inline format [milk, bread, eggs]
YAML이라는 이름은 "YAML은 마크업 언어가 아니다 (YAML Ain't Markup Language)” 라는 재귀적인 이름에서 유래되었다. 원래 YAML의 뜻은 “또 다른 마크업 언어 (Yet Another Markup Language)”였으나, YAML의 핵심은 문서 마크업이 아닌 데이터 중심에 있다는 것을 보여주기 위해 이름을 바꾸었다. XML이 데이터 직렬화에 쓰이기 시작하면서, 많은 사람들이 YAML을 '가벼운 마크업 언어'로 사용하려 하고 있다.
YAML은 문자를 따옴표로 묶어주지 않아도 되며, 구조적으로 설정을 표현하는데 용이하다. 또한 주석을 사용할 수 있는 장점이 있다. 구조적 설정을 위해서는 탭과 개행을 잘 맞춰주어야 한다는 단점을 가지고 있지만 작성된 내용을 보면 가독성은 좋은 편이다.
결론
설정이 중요하지 않은 개발이라면 우선적으로는 ini 스타일을 고려해보자. 하지만 프로그램이 확장될 것을 고려한다면 ini 선택은 다소 성급할 수 있다. 그렇다면 다음으로는 xml을 고려해보자. 이미 많은 곳에서 사용하고 있는 범용성을 무시할 수 없기 때문이다. 대부분의 개발 언어들이 xml 라이브러리를 지원한다. 한편 json은 간결하고 문법이 명확한 장점이 있지만 주석을 사용할 수 없는 단점 때문에 유지보수시 불편함이 많을 것이다. xml이 지저분하고 가독성이 좋지 않아 보인다면 yaml를 한번 사용해보길 바란다.
반응형