시대착오적인 설정 파일 *.properties를 버리자 프로그래밍

추가 : Java 6부터 properties 파일에 대해 다양한 문자셋의 일반 텍스트 파일을 사용할 수 있는 load(Reader reader)가 추가되었고 Spring Framework도 Encoding명시를 통해 이를 지원함.
단, @PropertySource는 이를 지원하지 않는 것으로 보임.
public static void main(String [] args) throws Exception {
    Properties props = new Properties();
    InputStream is = new FileInputStream("a.properties");
    props.load(new InputStreamReader(is, "UTF-8"));
    props.list(System.out);
}


-- 이후 원문
Eclipse의 파일 Lock 문제를 찾으면서 처음에는 Properties Editor Plugin을 원망했다. 게다가 대체품으로 선택한 Eclipse-RBE는 다소 불편한 인터페이스에 자꾸 NullPointerException을 떨궈서 사람 짜증나게 만들기 까지.

하지만 그러다가 곧 생각이 바뀌어 버렸다.

진짜 문제는 우리가 설정 파일로 시대착오적인 *.properties를 사용하고 있다는 그 사실이다.

자바의 *.proerties 파일은 텍스트 파일을 가장한 바이너리 파일이라고 보면 된다. 특수한 편집기나 변환기가 없으면 비영문권 사용자에게는 결코 텍스트 파일로써 다뤄질 수 없는 설정 파일 형식이다. 이런 것을 사용하면서 이를 편집하게 도와주는 플러그인을 탓한 것이다.

지금은 XML이나 YML 같은 잘 정형화되어있고 어느 편집기에서나 열어서 볼 수 있는 훌륭한 설정 파일 포맷이 나온지 이미 몇 년이 지난 시점이다. 그런 와중에 properties를 사용하는 나 자신을 탓하지 않고 플러그인을 탓하다니. 습관이 무섭다.

Java도 또한 이 문제점을 인지하고 Properties 객체를 XML 파일을 통해서 생성할 수 있게 만든지 이미 오래전이다. Properties XML은 형식도 매우 직관적이다. http://wiki.kwonnam.pe.kr/java/properties 를 참조하자.

게다가 더욱 훌륭한 것은 Spring Framework를 사용할 경우 <context:property-placeholder/>, <util:properties/>, 그리고 메시지 Resource Bundle 등이 모두 다 이 XML 형식의 프라퍼티를 완벽하게 지원한다는 것이다.

추가(2013/02/06) : XML 프라퍼티 형식을 사용하면 국제화지원이 안된다는 댓글이 있는데, Spring의 Resource번들은 이를 잘 지원하며 JDK 6 기본 ResourceBundle의 경우 Using Java 6 to Access Translatable Text in XML Files를 참고해보시기 바랍니다.

그래서 오늘은 특정 디렉토리의 모든 *.properties를 XML Properties로 변환해주는 간단한 툴을 만들고, Spring Bean 설정 파일에서 properties를 사용하는 부분들을 모두 XML 파일을 가리키도록 고쳐서 팀 프로젝트의 모든 *.properties 파일을 없애버렸다. 생각보다 오래걸리지도 않았다. 그리고 log4j.properties도 삭제해 버리고 log4j.xml로 전면 교체해 버렸다.

다른 Java 개발자들에게도 꼭 권한다. 프로젝트에서 *.properties를 삭제해 버리자. 어렵고 복잡한 일도 아니면서 설정 파일 읽기와  편집 효율성이 훨씬 더 증대된다.

그리고 하면서 느끼게 된 사실이 또 있는데, Spring의 <context:property-placeholder/> 사용하지 말자. 이일민씨의 블로그 글에도 보면 되도록 <util:properties/>와 SpEL을 사용하자는 것이 있는데. 이번에 수정하면서 약간은 다른 이유로 매우 동감하게 되었다.

properties-placeholder는 부모 자식 관계에 있는 Application Context XML 설정파일들의 경우에도 동일한 properties 파일임에도 모든 Bean 설정 파일에 property-placeholder를 명시해줘야 하는 문제가 있다.

하지만 <util:properties/>를 사용하게 되면 부모 컨텍스트에 딱 한번만 설정하고 그 외에는 SpEL로 명시해주면 된다. 그 외에도 SpEL을 쓰게 되면 어노테이션 기반 객체 주입시에도 사용이 가능하지만 properties-placeholder는 억지로 String 등의 Bean 객체로 생성하지 않는 이상 어노테이션에서 직접 읽을 방법이 없다(내가 아는한. 있다면 좀 댓글로 알려주세요).

따라서 나는 <context:property-placeholder/>를 버리고 <util:properties/>와 SpEL 사용을 강력하게 권한다.


핑백

  • 까먹지말자! : Spring 3.1 PropertySource가 XML Properties를 지원하지 않고 있다. 2012-10-20 21:55:41 #

    ... 보면 지정된 리소스를 일반 *.properties 파일로 간주하고 읽어버린다. 그런데 문제는 나는 *.properties를 매우 싫어한다. 시대착오적인 설정 파일 *.properties를 버리자. 참조. 일단 버그 리포팅은 해 뒀는데 어쨌든 당장 해결책이 필요해서 땜빵을 해봤다. 원리는 간단하다. @Configuration 지정 ... more

  • 까먹지말자! : Properties 상속으로 공통 설정과 부가 설정 분리 2013-07-28 18:41:21 #

    ... properites 형식을 함께 지원한다. 나는 *.properties를 별로 안 좋아한다.이렇게 읽은 값은 SpEL로 사용하면 된다. 나는 placeholderConfigurer가 불편하다고 보고 있다. 이를 사용하면 프라퍼티 형태가 다음과 같이 된다. parent-properties.xml &lt;properties&gt; & ... more

  • fmt:message vs spring:message | BUYWORKSELL 2013-09-24 00:04:25 #

    ... 정인 자바 8도 이쁘게 잘 나오면 좋겠네요. properties 설정 파일 자체가 국제화를 고려하지 않는 오래된 방식입니다. 아래 글 참조. http://kwon37xi.egloos.com/4665590 http://lusiea.tistory.com/entry/JSP-JSTL-fmt%ED%83%9C%EA%B7%B8-%EA% ... more

덧글

  • 아름프로 2012/01/13 02:01 # 삭제

    재밌게 잘 봤네 ^^
  • 토비 2012/01/13 07:43 # 삭제

  • 양태호 2012/01/18 10:09 # 삭제

    잘 봤습니다~
  • 글루미 2012/03/13 15:00 # 삭제

    요즘 신경쓰고 있던 문제중 하나인데 도움이 많이 됐습니다. ^^
  • 행인 2012/03/29 14:25 # 삭제

    properties 파일에 한글을 사용하지 않으면 되는거 아닌가요?
    그거 말고 뚜렷한 이유는 없어 보이네요..
  • 권남 2012/03/30 11:17 #

    네, 한글을 사용하지 않으면 됩니다.
    그러나 저는 사용하고 싶고 사용해야 합니다.

    사용자에게 보여주는 메시지를 프라퍼리로 관리하니까요.

    그리고 두가지 솔루션이 있는데, 한 솔루션은 제약이 있고 한 솔루션은 제약이 없는 상황에서, 그리고 제약이 없는 솔루션에 딱히 다른 단점도 없는 상황에서, 굳이 제약이 있는 솔루션을 선택할 이유가 없지요.

    그래서 XML을 사용합니다.
  • kyu 2012/11/22 17:26 # 삭제

    저같은 경우는 properties 를 사용하면서 공백으로 인하여 문제가 됐던 적이 있습니다.
    가령 아래와 같은 값이 있을 때 개발자 실수로 인하여 도메인 끝에 공백이 한 개 들어가 있다고 가정하고 뒤에 파라미터를 붙일 때
    http.url=http://test.co.kr

    http://test.co.kr ?test=111&tet2=12121 와 같이 되어 연동 문제가 발생했던 적이 있습니다.
    이런 현상으로 인하여 삽질 좀 했죠..;;
  • 영민 2012/06/28 21:29 # 삭제

    xml entity 내에 '&' 를 사용하려고 하니 에러가 되는데..혹시 그런 증상은 없으신가요??
  • 권남 2012/06/28 23:15 #

    XML에서 데이터로서의 &는 &amp; 로 표현해야합니다.
  • 무느미 2012/08/03 10:58 # 삭제

    content:property-placeholer 같은 경우, env.xml 이런식으로 하면 xml 타입 프로퍼티도 작동하는 반면

    ResourceBundleMessageSource 같은 경우 xml 타입 프러퍼티를 지원하지 않는 것으로 보입니다.

    jdk의 ResourceBundel 자체도 따로 control를 구현하지 않고, 바로 xml 번들을 읽어 들이지는 못하는듯...
  • 권남 2012/08/03 13:35 # 삭제

    저희 프로젝트에서는 xml properties로 메시지 리소스 번들 잘 사용하고 있습니다. 스프링 버전을 확인해보시거나 뭔가 잘못된 설정이 있는지 확인해보시기 바랍니다.
    저희는 org.springframework.context.support.ReloadableResourceBundleMessageSource를 사용하고 있습니다.
  • 함수호 2012/12/24 14:34 # 삭제


    @Service("applicationConfig")
    public class ApplicationConfig
    {
    //util:properties 변수 읽을때
    @Value("#{commonapp['app.CLASS_DEBUG']}")
    String classDeBug;

    //properties-placeholder 변수 읽을때
    @Value("${config.application.title}")
    String configApplicationTitle;


    //환경변수 읽을때
    @Value("#{systemProperties['os.name']}")
    String osName;
    }
  • 함수호 2012/12/24 14:35 # 삭제

    저도 util:properties 쓰는거 동감하고요. 참고삼아 위에 처럼 구문 물어보신건가해서 써봄.
  • 나그네 2013/02/06 13:17 # 삭제

    properties 파일을 단순하게 설정정보를 지정하는 용도로만 쓰신다면 혹, 그렇게 생각하실 수 도 있을것 있습니다. 하지만 properties 는 각 언어/지역별 설정을 달리 지정해 놓고 설정에 따른 언어/지역별 메세지를 출력시키는 용도로 더 많이 쓰입니다. 굳이 메세지등을 설정정보로 관리하지 않는다 하더라도 국제화 확장 등으로 시스템 확장을 염두에 둔 시스템이라고 한다면 properties 로 관리하는 것이 좋습니다. 시스템 국제화 에 있어서 가장 많이 사용되고 널리 알려진게 properties 파일을 사용한 ResourceBundle 이기 때문입니다. properties 파일이 구시대적이라고 생각하시는, 엔코딩 변환된 파일을 가지고 바이너리 파일이라고 생각하시는 것은 아주 위험한 생각입니다. 사람들이 널리 쓰고 있는 데에는 다 그만한 이유가 있기 때문입니다. 님의 시대착오적, 이라는 표현은 아주 편협한 생각입니다. 지나가다가 후배님이신거 같아 한마디 적고 갑니다.
  • 권남 2013/02/06 14:34 #

    다소 오해하고 계신데요. *.properties는 JDK 5 부터 XML로 대체가 가능합니다. 동일하게 Properties객체로 생성가능합니다.
    제가 시대착오적이라고 까는 것은 *.properties 파일 형식이지 국제화 등에 사용되는 Properties 클래스가 아닙니다.
    그리고 제가 위에 분명히 썼습니다. Spring의 ResourceBundle이 지원한다고요.
    충고는 감사합니다만 그 전에 먼저 글은 똑바로 읽어 주시기 부탁드립니다.
  • 나그네 2013/02/06 15:35 # 삭제

    저는 XML 파일이 properties 의 대체가 안된다고 한 적이 없습니다. 님부터 제 글을 잘 읽어 주세요. 저 또한 XML 이나 PROPERTIES 나 똑같이 사용하고 있습니다. 여러 기본 설정을 지정할 때 XML 을 애용합니다. 요즘 JAVA 든 뭐든 프로젝트에 XML 설정파일이 없는 것도 있나요? 뭐 이런걸 반문이라고 하나요? 저는 기본 설정 정보를 제외하고 메세지에 있어서는 PROPERTIES 만 사용합니다. 메세지는 특별히 속성정보를 지정할 필요도 없으며, XML 에서 표현이 안되는 특수기호 등의 제약이 특별히 없으며 XML 에 비해 상당히 빠릅니다. 더군다나 국제화 확장의 경우에도 파일단위로 추가만 하면 되죠. 뭐 여러 사람들이 있으니, XML 이나 PROPERTIES 파일을 쓰는데 있어 느끼는 장단점 또한 여러가지가 있겠지만, 님처럼 제대로 설정해서 써보지도 못했으면서 구시대적이라느니 하는 표현을 가지고 뭐라한 겁니다. 충고가 정말 감사하다고 느끼나요?
  • 권남 2013/02/06 15:58 #

    "XML에서 표현이 안되는 특수기호 등의 제약이 없어서" 한글을 uD55CuAE00 이런식으로 표현하는군요.
  • 나그네 2013/02/06 18:07 # 삭제

    님이 말하는 [uD55CuAE00] 이건 내부적으로 유니코드 변환된 코드일뿐, 그걸 가지고 표현한다고 말하는 건가요? 한글을 파라메터로 던질때 url 이 저런식으로 변환되는건 아세요? xml 을 주고받을 때, 저런식으로 유니코드로 변환되고, 다시 읽을때 지정된 encode 타입에 따라 변환되어 읽어들이는건 아세요? 그저 xml 이 좀더 보편적으로 약속된 언어이기에 에디터-웹브라우저가 잘 변환해주고 있을 뿐, 내부적으로는 데이터를 다 저런식으로 다룬다는건 아세요? 웹브라우저가, 에디터가 잘 해주니까 xml 을 쓰면 한글이 다 해결되는것 같으신가요? 결국 한글을 표현하려면 님이 말하는 [이런식으로 표현] 해야 한다는 말입니다.
  • 권남 2013/02/06 18:55 #

    네, 잘 알고 계시군요. 그런데 "왜 컴퓨터가 아닌 사람인 우리가 그 코드를 봐야하는 것이냐? XML을 사용하면 그럴 필요가 없는데." 이것이 바로 제 글의 주제입니다.
  • 나그네 2013/02/06 19:40 # 삭제

    참나.. 님이 자꾸 딴소리 하시네요.. 전 properties 수정할때 그런 변환된 코드 안 봅니다. 님이 설정을 잘못해서, 혹은 잘못된 사용방법으로 에디터가 기대에 미치지 못한 것처럼 보이는 것을 가지고 properties 파일 형식이 시대착오적이니 뭐니 하는 표현, 그리고 잘 사용하고 있는 주변사람들에게 까지 변환하도록 권유 한다는 것은 아주 잘못된 생각에서 비롯된 것이고, 생각 자체가 편협하다는 지적이 제 댓글이었습니다. 님이 xml 이 편하시다는데 굳이 댓글로 님에게 뭐라고 안합니다. 하지만 님이 잘 못 쓰겠다고 해서 시대착오니 뭐니 하는건 정말 웃기는 소립니다. 댓글처럼 [xml 을 사용하면 그럴 필요가 없으니 편하다] 라고만 본문에서 썼다면 공감하며 박수쳤지 이렇게 댓글달지 않았을 것입니다. 댓글을 달면 조금씩 벗어나서 반문이 오네요. 더이상 님에게 뭐라고 안 하겠습니다. 처음 편협하다고 한 말 그대로 이신거 같군요.
  • 권남 2013/02/06 19:57 #

    네... 제가 사용하는 에디터가 properties를 잘 처리 못하는 것 같습니다...
  • ... 2014/07/04 14:57 # 삭제

    잠시 들렀는데, 이 분 말투 자체가 정말 거슬리네요.
    맨 첫 댓글부터 '후배님인 거 같아', '편협한 생각이다'......

    참 같은 개발자로서 느끼는 건데 정말 꽉막혔네요.
  • 원희가바닷가재 2015/05/11 21:31 # 삭제

    억양이나 상황, 기분에 따라 같은 말이라도 다르게 받아들일 수 있죠.
    저는 나그네님 글 읽으면서 친절한 반론이라 생각되었거든요.
    권남님이 시대착오적인 발상이라고 너무 과격(?)한 단어를 사용하셔서, 초보 개발자들이 "아..properties는 무조건 쓰면 안되는거구나"라고 생각할까봐 염려해서 쓴 글 같았는데 오히려 그 댓글에 권남님이 "자기 글을 똑바로 읽고나 댓글 달아라(이건 제가 글 읽으면서 받은 주관적인 느낌임)" 라는 뉘앙스로 글을 쓰셔서 그 뒤에서 서로 공격적이 된 것 같습니다. 오히려 전 말줄임표님의 말투가 거슬린다.. 편협한 생각이다.. 꽉막혔다.. 이런 식의 글이 더 눈쌀을 찌푸리게 만드네요. 시대착오적이라는 단어 선택에 반론을 제기하는 문장으로 "편협한 생각이다"가 적절한 선택이지 않은가요?
  • 김경하 2013/07/25 14:53 # 삭제

    요런 얘기는
    하고계신 프로젝트의 팀원들에게만 하시면 되겠어요^^
  • 권남 2013/07/26 17:36 #

    제 블로그에는 제 생각을 쓸 수 없는 걸까요?
  • 근거는? 2014/06/30 07:47 # 삭제

    글쓴분의 논리도 나름대로 이유가 있고 프로그램에 절대 정답은 없는 법인데..
    개발자들 특유의 편협한 마인드들 보이는 댓글들이 보여서 보기 안좋네요..
    쫌 지난후에 바라다보면 이런 갑론을박이 참으로 부질없어 보일겁니다.ㅉ
  • 행인01 2014/08/04 13:35 # 삭제

    검색하다 들렀는데 정말 오랜 글이지만 한마디 적습니다
    개발자들 중에는 친절을 배푸는 듯 하지만 공격적으로 말하며 상대방 바보만들고 올라서고 싶어하는 분들이 있습니다
    별개 아니면 그저 가르쳐주면 그만입니다
    얼마든지 평범하게 말하고 알려줄 수 있습니다
    편협한 생각, 후배님인것 같아 한마디? 충고가 정말 감사하다고 느끼나요??
    이건 일단 상대방 흥분시키고 시작하는 토론을 위장한 싸움 거는거죠
    도대체 뭐가 꼴사나와서 그런표현을 하나요?
    그런문장 절대 멋있거나 카리스마, 말 잘하는 사람으로 보이지 않습니다
    프로퍼티에 대해 조금더 케이스를 안다고 하여 개발자 선배라니 이건 왠 편협하고 뚱딴지 같은 말인지 모르겠군요
    일할때 이런분들 정말 진저리가 납니다
    좀 아는 거 인정해줄테니깐 제발 말 좀 곱게합시다..
  • 행인02 2014/08/11 16:27 # 삭제

    먼저 밝히자면 "후배님인것 같아..." 등의 표현은 듣는 방향에 따라서 기분좋지 않을 수 있을 수 있다고 저도 생각되네요.
    그런데 그 분 이야기에서 공감가는게 저도 Properties가 바이너리 파일이라는 부분은 조금 문제가 있다고 생각되네요.
    기본적으로 Properties 는 notepad로도 open할 수 있는 텍스트 파일입니다. 텍스트 파일이기 때문에 encoding이 맞지 않으면 editor에서 깨져서 나오는게 당연할겁니다. 그래서 한 파일에 여러 encoding을 담을 수가 없으니깐 u prefix를 붙여서 unicode 입력이 가능하도록 하는 것은 아마 java의 properties의 약속일겁니다. (Oracle의 Properties 파일에 관한 문서: http://docs.oracle.com/cd/E23095_01/Platform.93/ATGProgGuide/html/s0204propertiesfileformat01.html) properties라는 개념은 C에서도 사용되었었고 STL에 properties class도 있습니다. 다만 이 모든 곳에서 저런 unicode 입력방식이 통용되는가는 조금 의문이고 제가 확인하긴 어려우니 일단 확실하게 알고있는 java쪽의 약속이라고 하겠습니다.
    그리고 제 생각에는 블로그 주인장께서 개발하는 환경에서는 파일의 encoding이 고정되고 unicode 문자는 이런 표현 방식을 따르도록 도와주는 editor를 사용하셨다고 생각되구요 아마 위에 나그네라는 분은 encoding이 다른 파일은 별도의 파일로 저장을 해서 언어별로 properties encoding에 맞게 읽어서 사용하는 환경이었다고 추측되네요. bean 정의할때 encoding 혹은 fileEncoding이라는 property 하나만 추가로 넣어주면 spring에서도 잘 지원되거든요.

    뭐 각자의 상황(프로젝트, 취향, 개발팀, ...)에 맞게 취사선택된 결정사항이겠죠. 그러니 "시대착오적...", "선배로서...", "편협한... " 이런 극단적 표현은 모두 부적합하지 않을까요?
  • 행인02 2014/08/11 16:30 # 삭제

    확인해보니 Spring도 bean 정의할때 "encoding" 혹은 "fileEncoding"이라는 property 하나만 추가하면 coding 없이도 지원이 되네요.
  • 권남 2014/08/20 20:00 #

    Java 6부터 Properties.load(Reader reader) 를 통해 일반적인 텍스트를 지원하게 되었다고 합니다.
    그리고 그것을 Spring이 연계해서 지원하구요.
    이제 XML을 안써도 많이 편해질 듯 하네요.
  • 종원 2014/08/20 20:55 # 삭제

    손팀장님- 잘지내시죠- 종원입니다. 우와- 팀장님 대전에서 뵌게 엊그제 같은데 벌써 십년되었어요- 올려주시는 재미난 글-재미나게 보구 있답니다. 언제나 파이팅입니다-(^_^)/ 페이스북 타고 들어왔다 인사남기고가요-
  • 권남 2014/08/21 09:26 #

    반가워요~ 저도 계속 보고 있어요~
  • 별이 2014/09/27 03:14 # 삭제

    감사합니다.
    jsp를 시작만 몇번째하고 있는 학생인데요..
    이곳저곳 소스를 따라하다 문득.. 왜하필 .properties 를 쓰고 있는거지? 라는 의문에 검색 하여 오게 되었습니다.
    댓글 까지 전~부 다 읽었는데.. 정말이지 오랫동안 쌓아둘 지식하나를 얻어가는거 같아 좋네요 ㅎㅎ
  • ㅇㅇ 2014/12/30 10:30 # 삭제

    댓글도 그렇고 본문도 그렇고 많이 배우고 갑니다..
  • 당근당근당근 2015/01/30 18:39 # 삭제

    괜히 위에 글읽다가 쓸데 없이 싸우는 거 같아서
    각자 편한 방법을 사용하면 될거 같은데 흠...
    개인적으로 프로퍼티는 xml과 properties 두개 모두 용도에 따라 사용하지만
    보편적으로 보자면 properties 가 나을 겁니다.
    여러가지 이유에서요.
    이거 보통 자신이 있는 분야나 개발 방법에 따라 갈릴듯하네요.
  • 꾸꾸 2015/03/17 14:29 # 삭제

    지나가다가 적고 갑니다. properties 파일의 단점은 이미 권남님이 잘 지적해주셨지만
    XML도 상당히 단점이 많은 방식입니다.
    일단 쓸데없이 태그가 공간을 너무 많이 잡아먹고 그에 따라 가독성이 properties 파일에 비해 떨어진다는 점과
    반복이나 배열 형식인 경우에는 불필요한 태그가 너무 많이 쓰이게 된다 정도겠네요
    파싱도 느린편입니다.
    YAML이나 JSON처럼 XML의 단점을 보완한 방식도 많지만..

    XML 구조의 견고함과 확장성을 따라가기는 힘들지요.. ㅎㅎ 결론은 XML의 장점도 많습니다.
    가장 최선의 방식은 적절한곳에 XML, Properties등의 방식을 배치해서 사용하는거겠지요. 한가지 방식만 고집하는건 아닌것 같습니다.
    요즘 메이븐이 뒤안길로 사라지고 그래들이 부상하고 있는것도 사람들이 메이븐의 XML을 싫어하는 이유가 꽤 크더군요.. ㅜ.ㅜ
  • messiah 2016/03/18 17:32 # 삭제

    꾸꾸님 말대로 장단점이 있죠. 저도 누군가 물어본다면 어느것이 낫다라고 말 못합니다. 그냥 난 설정값을 저장할때는 properties 파일을 쓰는 것이 편하다고 말합니다. 일단 직관적이고 가독성이 좋거든요.

    개발에 정답이 이거다라고 딱 정해져 있는건 없자나요. 그냥 그때그때 상황에 맞추어가면서 자신의 방법으로 개발해가면서 조금더 효율적으로, 조금더 편한 방법으로 할 뿐이지요.

    쨋든 저는 그렇습니다. ㅎㅎ

  • asd 2016/08/30 18:28 # 삭제

    시대착오적이라고 할것까지야 있나
    지금까지의 댓글을 보면 결국 본인 주관적인 이야기일 뿐인 것을
    저같은 초보자들이 보면 properties를 절대 사용하지 말아야 할 무언가로 보게 만드는군요..
  • 문팡 2017/02/09 15:19 # 삭제

    Simple Properties Editor Plguin으로 프로퍼티를 사용중인데 불편함 없이 잘사용중입니다 그리고 프로퍼티가 XML보다 직관적이고 가독성도 뛰어난것 같습니다.
※ 로그인 사용자만 덧글을 남길 수 있습니다.