한빛출판네트워크

저자: 『Building Java Enterprise Applications vol: Architecture』의 저자 브렛 맥래플린, 역 김인희

필자는 본 기사에서 프로그래밍 관련 팁을 직접적으로 알려주기 보다는 엔터프라이즈 프로그래밍을 할 때 흔히 범할 수 있는 몇 가지 실수에 대해 살펴볼 것이다. 이 외에도 반드시 해야 할 것이 아니라 하지 말아야 하는 것에 중점을 두어 기사를 전개해나갈 생각이다.

대부분의 프로그래머들은 필자가 쓴 『Building Java Enterprise Applications vol: Architecture』과 같은 책을 보고 거기서 좋은 면을 받아들이려고 노력한다. 그럼에도 불구하고 그들은 같은 프로그램을 작성하는데도 여전히 실수를 하게 마련이다. 그래서 필자는 엔터프라이즈 프로그래밍을 할 때 일어나는 일반적인 에러사항을 살펴보고 짧게나마 어떻게 이러한 실수들을 피할 수 있는지 알아보고자 한다.

1. 어떤 데이터 저장 타입을 사용하는 지는 중요하지 않다.

애플리케이션 설계시 고려해야 할 사항 중에 하나는 데이터를 저장하는 방법이다. 일반적으로 거의 모든 애플리케이션은 데이터베이스에 그 기반을 두고있으므로, 데이터베이스에 데이터를 저장하는 것이 특별한 일은 아니다. 그러나 최근들어 그 선택의 폭이 관계형 데이터베이스, XML 데이터베이스, 객체지향 데이터베이스, 디렉토리 서버 등으로 크게 확장되었다.

그 결과 많은 회사들은 현실적으로 고려해보지도 않고 데이터 저장 타입을 바꾸기 시작했다. 단지 데이터베이스보다 더 싸다는 이유로 디렉토리 서버를 선택하는 경우도 있고, XML 데이터베이스가 매력적이고 기술적으로 빠르게 발전하고 있기 때문에 사용한다고도 한다. 그러나 충분히 검토도 하지 않고 데이터 저장 타입을 결정하는 것은 정말 어리석은 일이다. 애플리케이션에 성능저하가 올 수 있으며, 코드가 아주 복잡해지고 심지어는 왜 그렇게 복잡해 졌는지 알 수조차 없게 된다.

데이터 저장 타입은 각기 그 사용 용도가 다르다. 예를 들어 디렉토리 서버는 빈번히 읽어들이기는 하지만 거의 쓰지 않는 경우에 최적화 되어있다. 사용자를 인증하고 이름과 주소를 탐색하는 일은 디렉토리 서버를 사용하는 이유이기도 하다. 그러나 프로그래밍적으로 자주 디렉토리 서버에 데이터를 입력하기 시작하면 성능은 저하된다. 이런 경우에는 데이터베이스를 사용하는 것이 더 적절하다.

어떤 데이터베이스를 사용해야 할지 결정하는 일도 중요하다. 예를 들어 데이터베이스에서 XML를 추출하지 않는 애플리케이션에 XML 데이터베이스를 사용하는 것은 적절치 못한 선택이라고 할 수 있다. 최신 기술(XML)을 선택했지만 절대로 그 기술을 사용하지는 않게 되기 때문이다.

필자는 책에서 어떠한 상황에 어떠한 데이터 저장 타입을 사용해야 할지를 상세히 기술했다. (이런 의미에서 필자의 책은 자바만을 다룬 책이 아니라고 할 수 있다.) 하나의 애플리케이션에서 데이터베이스와 디렉토리 서버를 통합하는 방법과 이 두 데이터 저장 타입간의 데이터 교환 방법도 배울 수 있도록 해놓았기 때문이다.

2. 벤더에 의존적으로 프로그래밍을 하면 작업 속도가 올라간다.

프로그래머들은 코드를 더 빨리 작성할 수 있는 지름길을 찾으려 노력한다. 그렇지만 대개의 경우 이 지름길은 오히려 길고 험한 길로 돌변하게 된다. 당장 프로그래밍하는 시간을 아낄 수는 있겠지만 잘못된 것을 올바로 고치는 데에는 항상 더 오랜 시간이 걸리게 마련이다. 예를 하나 들어보겠다.

엔터프라이즈 자바빈즈(EJB)와 데이터베이스 테이블로 작업한다고 가정해보자. 테이블의 ID 필드에 숫자를 넣는 일은 흔히 발생하는 일이다. 이 작업을 위해 오라클은 시퀀스, MySQL은 자동증가 필드를 지원하지만, 다른 테이블에서는 이러한 기능을 제공하지 않는다.

필자는 EJB 코드에서 오라클의 시퀀스나 MySQL의 자동 증가 필드 또는 다른 데이터베이스에 직접 접근하는 경우를 자주 보았다. 다시 말해, EJB가 모든 데이터베이스에서가 아니라 오로지 하나의 데이터베이스에서 동작하는 경우를 말이다. 사실 동일한 벤더의 데이터베이스를 사용한다고 해도 데이터베이스 버전이 달라서 작동하지 않는 경우가 심심치 않게 있다. 이러한 코드는 이식성이 없고 수명도 짧아서 회사의 요구를 수용하지 못하는 결과에 까지 이르게 된다.

데이터베이스에 의존하지 말고 대신 빈(beans)이 자체적으로 번호 매기기(numbering)를 수행할 수 있도록 하자. 벤더에 의존적이던 코드는 제거하고 이 빈을 사용하면 시스템은 벤더에 중립적이고 유연성을 갖게 되며 (대다수의 경우) 성능은 더 향상된다. 필자의 책에서는 이와 같은 경우를 대비한 코드를 볼 수 읽고 특정 벤더에 의존하지 않는 방법도 배울 수 있다.

		Building Java Enterprise Applications vol I: Architecture

3. 엔터프라이즈 자바빈즈를 작성하기 위해서는 에디터와 개발도구가 필요하다.

필자는 종종 EJB를 작성할 때 어떤 개발도구를 사용하느냐는 질문을 받는다. 그 중에서도 사람들은 특히 리모트 인터페이스, 홈 인터페이스, 그리고 이 인터페이스들을 구현하는 클래스 소스 코드를 생성하는데 어떤 도구를 사용하는지에 관심이 많다. 대개 이런 컴포넌트를 만들려면 필요한 코드를 반복적으로 사용하기 때문에 작업을 더 간단히 하기 위해 개발도구 찾는다. 만약 이런 기본적인 EJB 코드를 직접 수정할 경우 대개 중요한 부분을 놓치거나 메소드를 잘못 작성하게 마련이다. 그 결과 코드 자체가 컴파일이 안되거나 디버깅하기가 어렵게 된다.

필자는 vi와 notepad를 통해 자바에 대한 경험을 쌓았고 Ctrl+C와 Ctrl+V 그리고 "yy", "dd" 그리고 "p"를 사용하는데 만족해 하고 있다. vi와 notepad와 같은 텍스트 에디터에서 텍스트를 복사하고 붙이는 작업은 다른 에디터나 개발도구를 사용하는 것보다 편하고 더 재미있다. 위에서 언급한 에디터를 사용하면 코드도 더 잘 이해할 수 있게되며 코드에서 정확히 어떤 작업을 하고 있는지도 한 눈에 볼 수 있다.

그렇다고 에디터나 개발도구를 사용하지 말아야 한다는 뜻은 아니다(참고로 필자는 jEdit를 사용함). 그러나 개발도구에 의지하다보면 어려움에 처하게 된다. 텍스트 에디터만으로 한 주동안 코드를 작성하고 나면, 자신이 작성한 코드에 상당히 친숙해져 있을 것이다. 물론 필자는 책에서 어떠한 개발도구도 사용하지 않았다. 개발도구를 사용하지 않으면 정확한 개발 과정을 알 수 있기 때문에 애플리케이션에 있는 컴포넌트와 빈을 더 논리적이고 효과적으로 작성할 수 있다.

4. 모든 애플리케이션마다 JMS, XML, JAXP 등을 사용한다.

오랫동안 필자의 책과 기사를 읽어온 사람이라면 아마 필자가 또 어떤 이야기를 꺼낼지 짐작이 갈 것이다. 이말에 다들 질려버렸을지도 모르겠지만 다시 한 번 더 강조하면 프로그램의 용도에 맞게 필요한 것만 골라서 사용해야 한다는 것이다. 지겹더라도 이 기술을 전부 이해하고 사용하게 될 때까지 필자는 계속해서 주의를 줄 것이다.

J2EE 애플리케이션에 J2EE의 모든 기술을 사용해야 한다는 주장은 잘못된 생각이라고 지적하고 싶다. 사람들은 애플리케이션이 EJB, JMS, JMX, XML 등 애플리케이션 서버가 포함하고 있는 모든 기술을 사용하지 않으면 대개 돈을 낭비하고 있다고 생각한다.

실제로도 상당수의 사람들이 그렇다고 생각하기 때문에 필자는 최근에 저술한 책에서 자바 메시지 서비스(JMS, Java Message Service)에 대한 내용을 담고 있는 단원을 억지로 넣다시피 했다. JMS가 중요하지 않아서 그런 것은 아니다. 단지 책에서 소개한 애플리케이션에서는 JMS을 거의 사용하지 않기 때문이다. JMS을 사용하는 애플리케이션을 몇 개 작성해본 경험을 바탕으로 JMS을 적절하게 사용할 수 있는 경우를 제시했었다. 그러나 실무에서는 의도한 대로 상황이 맞추어져 있지 않기 때문에 책에 나온대로 애플리케이션을 만드는 것이 아나라 상황에 맞춰 어떤 애플리케이션을 만드느냐가 더 중요하다. 이는 마치 요리를 하는데 있어 부엌의 모든 조리 공간을 사용할 필요가 없는 것과 같은 이치이다.

경우에 따라 50번에 한번정도로 정말 필요한 것만을 사용해야 한다. 서블릿과 JDBC 코드정도만 필요하다면 계속해서 이 두 가지만 사용하도록 해라. 필요도 없는데 일부러 EJB의 복잡한 기능을 넣을 필요는 없다. EJB가 필요하긴 하지만 애플리케이션에 메시지 구동 빈(message-driven beans)을 사용하지 않는다고 걱정하지 않아도 된다. 장기적으로 봤을 때 애플리케이션의 복잡성을 줄인 것에 대해 감사하게 생각할 것이다.

5. Stateful 빈을 사용하면 프로그래밍을 좀 더 객체지향적으로 할 수가 있다.

이 실수는 흔히 하는 실수로 쉽게 고칠 수 있는 실수 중 하나이다. 기본적인 실수는 메소드를 호출하는 방식에서 일어난다. 예를 들면 stateful 세션 빈의 리모트 인터페이스에 다음과 같은 메소드가 있다고 하자.

    Public User create(String username);
    Public Address getAddress();
    Public List getAccounts();
    Public Boolean deleteAccount(Account account);

이 메소드들로 statuful 세션 빈을 만들면 단 한번에 (create() 메소드에)사용자 이름을 전달할 수 있다고 생각하고 다음과 같이 메소드를 호출할 것이다.

    User user = userHome.create(username);
    Address address = user.getAddress();
    List accounts = user.getAccounts();

이렇게 하는 것이 다음 메소드들을 포함하는 stateful 빈보다 훨씬 더 객체지향적이다.

    public User create();
    public Address getAddress(String username);
    public List getAccounts(String username);
    public Boolean deleteAccount(String username, Account account);

이 빈을 사용하면 다음과 같이 메소드를 호출할 것이다.

    User user = userHome.create();
    Address address = user.getAddress(username);
    List accounts = user.getAccounts(username);

놀랍지 않은가? 위와 같이 코드를 작성하면 이해하기 어려울 뿐더러 작업하기도 힘들어진다. (약간 빈정대는 것같이 들리겠지만, 프린트물만을 보고서는 왜 그렇게 되는지 이해하기 힘들 것이다) 알다시피, 이 방법은 OO(object-oriented)적이지 않다. 하지만 두 번째 방법은 stateless 빈의 경우에 비추어 볼 때 (애플리케이션 서버에 따라)10배내지 100배정도 더 수행 속도가 빠르다. 비록 객체지향적인 코딩면에서는 다소 희생이 따르지만 그만큼 수행 속도는 더 빨라진다. 마지막으로 터무니없는 실수 한가지만이 남았다.

6. 프로그래밍을 할 때 내게 조언해줄 사람이 필요하지 않다

그렇다. 우리 모두 그렇게 하고 있다. 필자도 프로그래밍을 시작한 처음 몇 년 동안은 항상 혁신적이고 창조적이었으며 절대로 남의 코드를 모방하지도 않고 어떠한 도움도 받지 않았다. 물론 나중에서야 필자가 내건 "혁신"이라는 것이 문제를 인식하는데 장애물이 되고 "최적화"된 문제 해결 방법에 오히려 방해가 되었다는 것을 알게 되었지만 말이다. "최적화"된 문제 해결 방법을 받아들이지 않을 정도로 이기적이었던 것은 정말 어리석은 일이었다.

물론 책을 팔려고 한 말은 아니다. 단지 여러분이 하고 있는 작업과 관련된 사항들을 점검하고 필요한 것이 있으면 다른 곳에서 정보를 얻으라고 조언하고자 한 말이다. 필자는 오라일리 책뿐만 아니라 다른 출판사의 기술 서적도 가지고 있으며 이 모든 책에서 항상 필요한 정보를 얻고 있다.

이 외에도 오픈 소스 커뮤니티에 동참하라고 권하고 싶다. 상상하지 못했던 것을 얻을 수 있기 때문이다. 커뮤니티 활동을 통해 정말 똑똑하고 생기 넘치는 사람들을 접할 수 있다. 이 사람들로부터 가능한 한 많은 지식들을 얻을 수 있기를 바란다. 만약 다른 사람들의 도움이 필요하지 않다고 생각한다면 그때부터 여러분의 실수는 늘어만 갈것이다.

이상으로 필자가 여러 번 보아왔던 여섯 가지 일반적인 문제들을 살펴보았다. 이 중에 한 두 가지 정도의 실수를 겪어봤다고 부끄러워할 필요는 없다. 필자도 한때 위 실수들을 해보았지만 결국에는 그 실수들을 극복해냈기 때문이다. 지금까지 경험한 실수들이 더 좋은 프로그래머가 되는 원동력이라고 받아들이자. 필자의 신간 『Building Java Enterprise Applications vol: Architecture』를 재미있게 읽어보길 바란다.

브렛 맥래플린(Brett McLaughlin)은 『Building Java Enterprise Applications vol: Architecture』의 저자로 자바와 자바관련 기술을 사용하여 애플리케이션 이프라스트럭쳐를 구축하는 일을 전문으로 하고 있다.