설정 파일?
프로그래밍을 하다 보면 여러 설정 값들을 다뤄야 합니다. 서버라면 어떤 포트에 띄울지, API 통신을 한다면 API Key 값, DB의 아이디/비밀번호까지... 이런 값들은 코드에 하드코딩을 해 놔도 되지만 여러 이유로 따로 설정 파일을 둬서 관리합니다.
- 프로그램이 실행되는 환경에 따라 값을 다르게 하기 위해 (개발 환경, 운영 환경 등)
- 코드가 공개된 경우 보안을 위해 민감한 값을 실행 시점에 주입받기 위해
- 코드 수정 없이 설정 값만 빠르게 바꾸기 위해
이런 설정 파일을 위해 보통은 .yml, .properties, .json 이나 아니면 언어별로 특화된 DSL을 각자 만들어 씁니다. 자바 진영에서는 gradle 설정을 위해 Groovy나 Kotlin의 DSL을 사용합니다.
하지만... 이런 설정 파일에는 문제가 있습니다.
- yml, properties, json 등: 프로그래밍 언어가 아니기 때문에 유연성과 Type Checking 능력이 떨어짐
- 언어별 DSL: 언어별로 통일되지 않고, 설정용이라 하기에는 문법이 너무 복잡하고, 설정용으로 디자인되지 않았기 때문에 값의 Validation 등이 원하는 만큼 없음
이를 보완한게 피클 (PKL)입니다. 프로그래밍 언어지만 다른 언어로도 유연하게 컴파일되고, 설정에서 많이 쓰이는 기능 위주로 들어 있습니다.
피클 (PKL)의 특징
피클은 애플이 제안한 설정 파일 형식이고, 오픈소스입니다. 아마 애플 내부에서는 활발하게 쓰고 있을 거라 추측합니다. 🤔
- 공식 홈페이지
- Github
기존에 많이 쓰이는 설정 파일(properties, yml)에 비교해 타입이 더 강하고, 여러 흐름제어에 관련한 프로그래밍 문법을 쓸 수 있고 (if, for 등), class를 사용해 구조화 할 수 있고, 값에 대한 validation을 바로 할 수 있습니다.
기존 설정파일과 피클 (PKL) 비교해 보기
제 개인 프로젝트의 개발 환경 설정 파일로 YML과 PKL의 차이를 비교해 보겠습니다!
🐜 YML
server:
port: 80
error:
include-message: always
application:
jwt:
secret-key: ${JWT_SECRET_KEY}
token-prefix: Bearer
token-expiration-after-days: 1
token-expiration-after-days-stay-login: 7
spring:
application:
name: booksitout
datasource:
url: jdbc:h2:mem:booksitout;DB_CLOSE_DELAY=-1
driver-class-name: org.h2.Driver
username: sa
password: password
platform: h2
h2:
console:
enabled: true
path: /h2-console
jpa:
show-sql: true
hibernate:
ddl-auto: update
properties:
hibernate:
format-sql: true
servlet:
multipart:
enabled: true
max-file-size: 10MB
max-request-size: 10MB
cache:
type: caffeine
- .properties에 비하면 엄청 깔끔합니다.
- 들여 쓰기가 눈에 잘 안 들어오는 거 같지만 이건 취향 문제긴 합니다.
- YML 문법을 잘 모르면 헷갈릴 지점들이 몇 개 있습니다. 환경 변수 사용법 (${})은 YML을 오해 썼지만 여전히 헷갈립니다.
- 설정값의 데이터 타입이 뭔지 명확하지 않습니다. 당연히 Type Checking도 없습니다.
🐜 PKL
const TOKEN_EXPIRATION_DAYS = 1
const TOKEN_EXPIRATION_DAYS_STAY_LOGIN = 7
const MAX_FILE_SIZE = "10MB"
server {
port = 80
error {
include_message = "always"
}
}
application {
jwt {
secret_key = env("JWT_SECRET_KEY")
token_prefix = "Bearer"
token_expiration_after_days = TOKEN_EXPIRATION_DAYS
token_expiration_after_days_stay_login = TOKEN_EXPIRATION_DAYS_STAY_LOGIN
}
}
spring {
application {
name = "booksitout"
}
datasource {
url = "jdbc:h2:mem:booksitout;DB_CLOSE_DELAY=-1"
driver_class_name = "org.h2.Driver"
username = "sa"
password = "password"
platform = "h2"
}
h2 {
console {
enabled = true
path = "/h2-console"
}
}
jpa {
show_sql = true
hibernate {
ddl_auto = "update"
properties {
hibernate {
format_sql = true
}
}
}
}
servlet {
multipart {
enabled = true
max_file_size = MAX_FILE_SIZE
max_request_size = MAX_FILE_SIZE
}
}
cache {
type = "caffeine"
}
}
- 프로그래밍 언어처럼 중요한 값들은 맨 위에 상수로 뺄 수 있습니다.
- 모든 데이터 타입은 String일 경우 ""로 구분되기 때문에 명확합니다. 당연히 Type Checking도 됩니다.
- 환경 변수 사용법도 env()로 하니 헷갈리지 않습니다.
- Hierchary의 구분이 {}로 되니 더 눈에 잘 들어옵니다. (개인 취향)
피클 (PKL)이 널리 쓰이게 될까?
PKL의 첫 인상은 2가지였습니다.
- 와 내가 쓰는 라이브러리/프레임워크가 잘 지원해 주면 겁나 편하겠다!
- 좀 과하다
모든 기술은 특정 부분에서 더 우월하다고 갑자기 채택되지 않습니다.
- 내가 이미 쓰고 있는 기술들과 얼마나 호환이 잘 되는지
- 사용하고 설치하기 편한지
- 오류는 없는지
- 커뮤니티가 기존에 익숙했던 기술들과 비교해서 얼마나 배우기 쉬운지
등등 여러 상황에 좌우됩니다.
제 개인적인 생각으로는 PKL이 분명 더 편한 부분이 있다고 생각합니다. 하지만 현재 상황에서는 PKL을 지원하는 라이브러리나 프레임워크가 거의 없기 때문에 PKL을 쓰고 싶다면 타입이나 Class 등을 직접 생성해야 합니다. 물론 Type Checking이 없어도 PKL을 쓸 이유는 많지만 그것만으로는 부족한 느낌입니다.
하지만 라이브러리 지원이 잘 되기 시작하면 새로운 프로젝트에 PKL을 쓰지 않을 이유는 없는 거 같아요. 설정 파일에서 여러 프로그래밍 문법을 다 쓸 수 있다는 게 좀 과한 부분들이 있지만 그건 안 쓰면 그만이니 저는 PKL을 사용할 거 같습니다.
참고 자료
'👨💻 프로그래밍' 카테고리의 다른 글
B2B vs B2C, 개발자 입장에서 비교해 보기 (0) | 2024.08.23 |
---|---|
영어권에서 자주 쓰는 프로그래밍 신조어 소개 (feat. Programming Slag) (0) | 2024.08.04 |
Scale-out이 Scale-up보다 효과적인 이유 (0) | 2024.07.10 |
🐶 신입 개발자가 3개월 현업에서 굴러본 후기 (0) | 2023.11.26 |
🥳 토스 NEXT 2023 합격 후기 (서버 전형, 신입) (1) | 2023.09.23 |