다국어를 일부 yml 파일로 처리하자는 의견이 나와서 작업을 진행했다.
기존에 다국어를 이미 DB 또는 Spring properties로 관리하고 있었기 때문에 왜 일부는 yml로 빼는지 의문이 생겨 찾아보고 정리한 글!
시작합니다.
YML 파일에 다국어 값을 저장하는 이유?!
1. 구조화된 설정 관리:
- YML 파일은 기본적으로 설정 파일로 사용되기 때문에, 다국어와 관련된 설정 값을 하나의 파일에서 구조화된 형태로 관리할 수 있다.
- 다국어뿐만 아니라 서버 설정, 외부 API 설정 등을 함께 관리할 수 있기 때문에 설정 통합 관리가 가능하다. 예를 들어,
batchmonitor.server-type처럼 특정 모듈의 서버 유형을 YML 파일에 저장함으로써 코드 변경 없이 설정만 업데이트할 수 있다.
2. 배포 시 수정이 쉬움:
- YML 파일은 애플리케이션의 설정 파일이기 때문에, 코드를 수정하지 않고 설정을 변경하거나 추가할 수 있다.
- 예를 들어, 새로운 언어가 추가되거나 기존 서버 유형의 명칭이 바뀌는 경우에도 애플리케이션 재시작 또는 핫스왑만으로 쉽게 변경사항을 적용할 수 있다. DB나 message code 방식보다 빠르게 대응할 수 있음.
3. 경량화 및 속도:
- YML 파일은 애플리케이션 구동 시 메모리에 로드 되어 빠르게 참조할 수 있다. DB에서 값을 불러오는 것보다 조회 속도가 빠르고, 코드 내에서 간단히 접근할 수 있어. 메시지 코드 방식보다는 비교적 가볍고 단순하다.
4. 환경별 설정 가능:
- Spring에서 프로파일 기능을 이용해 YML 파일을 환경별로 다르게 설정할 수 있다. 즉, 개발 환경, 테스트 환경, 운영 환경에서 각기 다른 다국어 설정을 사용할 수 있음.
- DB 방식으로 다국어를 관리할 경우 환경마다 데이터베이스에 추가 설정을 해야 하거나 복잡한 동기화가 필요할 수 있지만, YML 파일은 환경에 맞게 쉽게 분리할 수 있음.
5. 단순성과 유지보수 용이성:
- YML 파일에 다국어 설정을 관리하면 복잡한 로직 없이 간단히 값을 가져와 사용할 수 있다. message code 방식은
messages.properties에 다국어 값을 정의하고 코드에서MessageSource를 통해 불러오는 방식인데, 이는 좀 더 복잡한 구조를 요구한다. - 반면 YML 파일을 사용하는 방식은 직관적이고 추가/수정이 용이해. 예를 들어, 새로운 서버 유형이 추가되거나 언어가 추가될 때 YML 파일에 직접 추가하면 되니까 유지보수가 간편함.
다른 방식과 비교
1. DB에 저장:
- 장점: 다국어 데이터를 동적으로 관리할 수 있고, 데이터베이스 쿼리를 통해 검색 및 통계를 낼 수 있다. 다국어 데이터를 중앙에서 통합 관리할 수 있고, 다국어 텍스트가 많을 때 유리함.
- 단점: 조회 속도가 느릴 수 있고, 변경 사항을 반영하려면 DB 업데이트 및 쿼리 수정이 필요하다. 애플리케이션 레이어에서 DB 연결 없이 간단한 다국어 처리를 할 수 없기 때문에, YML 파일처럼 가볍지 않음.
2. Spring Message Code (messages.properties):
- 장점: 메시지 코드 방식은 Spring이 기본 제공하는 기능이므로 통합성이 높고, 다국어 메시지를 일관되게 관리할 수 있다. 기본적인 메시지 포맷팅, 다국어 지원, 그리고 재사용성이 높음.
- 단점: 추가/수정 시 properties 파일을 수정해야 하고, 코드 내에서
MessageSource와의 연결이 필요해 복잡도가 약간 올라감. 특히 다국어와 상관없는 설정 값을 관리할 때는 적합하지 않다.
💡
YML 파일에 다국어 설정을 저장하는 이유는 구조화된 설정 관리, 간편한 유지보수, 속도, 그리고 환경별로 쉽게 적용 가능하기 때문이다. 다국어 값의 변화나 추가가 자주 일어나는 경우, 코드 수정 없이 YML 파일만 수정해서 적용할 수 있다는 점에서 매우 유용함. 특히, 설정 값으로 처리하는 경우 YML 파일을 사용하는 것이 적합하다.
YML에 다국어 설정을 저장하는 단점:
1. 대규모 데이터 관리에 불리함:
- YML 파일은 설정 파일로써 소규모의 간단한 데이터를 관리하기에 적합해. 하지만 다국어 항목이 많아지고 데이터가 복잡해지면 파일 자체의 크기가 커지고, 관리가 어려워질 수 있다.
- 특히 수백, 수천 개의 다국어 메시지를 처리해야 하는 경우, YML 파일로 관리하는 것은 비효율적이다. 이런 경우 DB처럼 대량의 데이터를 효율적으로 저장하고 조회할 수 있는 방식이 필요함.
2. 동적 변경의 어려움:
- YML 파일은 정적 설정 파일이기 때문에, 애플리케이션이 실행된 후에는 내용을 변경하기 어렵다. 변경 사항이 있을 경우 애플리케이션을 재시작해야 적용되기 때문에, 실시간으로 다국어 설정을 업데이트하거나 동적으로 적용할 수 없다는 단점이 있다.
- 반면 DB나 properties 파일을 사용하면, 다국어 메시지를 실시간으로 변경하고, 즉시 반영할 수 있다. 예를 들어, 관리자가 다국어 텍스트를 변경할 수 있는 관리 화면을 제공하려면 DB 방식이 유리하다.
3. 버전 관리의 복잡성:
- YML 파일은 코드와 함께 버전 관리되기 때문에, 다국어 텍스트의 변경 이력을 따로 관리하려면 번거로울 수 있다. 특히 여러 개발자가 동시에 작업할 경우, 충돌이 발생할 수 있고 이를 해결하기 위해 불필요한 작업이 추가될 수 있다.
- DB를 사용하면 다국어 메시지에 대한 변경 이력을 자동으로 추적할 수 있고, 메시지의 추가/수정/삭제도 별도 관리가 가능하다.
4. 파일 크기 증가:
- YML 파일의 크기가 커지면 애플리케이션 구동 속도에 영향을 줄 수 있다. 모든 다국어 데이터를 로드해야 하므로 메모리 사용량도 증가할 수 있다. 반면, DB는 필요한 데이터만 필터링해서 조회하기 때문에 메모리 부담이 적고, 확장성도 높다.
5. 환경에 따른 설정 분리의 어려움:
- YML 파일을 환경별로 나누기는 쉬우나, 다국어 설정이 각 환경마다 크게 달라지면 파일 관리가 복잡해질 수 있다. DB는 환경에 상관없이 동일한 데이터베이스를 사용할 수 있으므로, 환경에 독립적인 다국어 데이터 관리에 적합하다.
왜 DB나 properties 파일과 섞어서 사용하는가?
YML 파일과 DB 또는 properties 파일을 섞어서 사용하는 이유는, 각각의 장점과 단점을 잘 조합하여 효율적인 다국어 관리를 하기 위함이다.
적용 방법:
1. YML은 기본 설정:
- 고정된 소규모의 다국어 값(예: 서버 유형, 고정된 시스템 메시지)은 YML 파일에 저장해서 사용한다. 이런 값들은 자주 변경되지 않으므로 YML 파일로 관리하면 편리함.
2. DB는 대규모 데이터 및 동적 변경:
- 동적으로 추가되거나 자주 수정되는 다국어 메시지는 DB에서 관리한다. 예를 들어, 사용자 정의 메시지나 관리자가 자주 수정하는 내용을 실시간으로 반영하려면 DB에 저장하는 게 훨씬 유리하다.
- DB 방식은 다국어 메시지를 동적으로 불러올 수 있고, 애플리케이션을 재시작하지 않아도 되기 때문에 실시간 반영이 가능하다.
3. properties는 메시지 코드 관리:
- Spring의 message code(
.properties 파일)는 주로 에러 메시지나 폼 필드 검증 메시지처럼 특정 로직에서 반복적으로 사용되는 메시지를 관리할 때 유리하다. properties 파일은 다국어 메시지를 중앙에서 관리하고, 필요할 때마다 손쉽게 가져올 수 있음. - properties 방식은 다양한 언어의 에러 메시지를 코드로 정의해두고, 쉽게 유지보수할 수 있는 장점이 있다.
💡
YML 파일은 다국어 설정을 관리하는 데 간단하고 빠르지만, 대규모 데이터나 실시간 변경이 필요한 경우에는 한계가 있다. 그래서 DB나 properties 파일을 사용하는 방식과 섞어서 사용하는 것이 일반적임.
각각의 방법을 상황에 맞게 조합해서 사용하면 효율적이고, 필요에 따라 다국어 데이터를 확장하거나 동적으로 관리할 수 있는 유연성을 갖출 수 있다.
Active 🙌 Curious 🤔 Energetic 💪