Pojo란?
Spring은 POJO 기반의 프레임워크라는 말을 들어보았을 것이다. 여기서 POJO의 의미는 무엇일까? POJO는 Plain Old Java Object의 약자로 말 그대로 해석을 하면 오래된 방식의 자바 오브젝트라는 말이다. 뜻이 애매하고 와닿지도 않는다. 이런 애매모호함은 다양한 해석을 만들었고, 포스팅마다 설명이 다르다.
결국 정확한 어원과 의미를 알아야겠다는 생각을 가지게 되었고, 다양한 자료들을 조사하기 시작하였다. POJO를 정확하게 이해하기 위해서는 단어 등장의 배경부터 알아야한다.
EJB의 등장
현재에 와서는 상상이 가지 않겠지만 원래 자바의 초점은 클라이언트 GUI를 만다는데 맞춰줘 있었다. 그러다가 곧 서버 시장에서의 가능성에도 주목받기 시작하였으며, 서버개발에 필요한 기능을 모아서 J2EE(현재의 JAVA EE)라는 표준을 만들게 되었다. 하지만 J2EE의 Servlet, JSP 레벨의 최소한의 서버 프로그래밍 인터페이스만 가지고는 복잡한 엔터프라이즈 애플리케이션을 제작하는데에는 부담이 있었다. 기업 업무처리의 IT 시스템에 대한 의존도가 높아지면서 시스템이 다뤄야 하는 비즈니스 로직은 점점 복잡해졌고, 개발자들이 비즈니스 로직과 더불어 다양한 상세기술의 복작함을 다룬다는 것은 쉬운일이 아니었다.
결국 많은 사용자의 처리 요구를 빠르게 안정적이면서 확장 가능한 형태로 유지하기 위해 필요한 로우레벨의 기술적인(트랜잭션 처리, 상태관리, 멀티쓰레딩, 리소스풀링, 보안 등) 처리가 필요했다. 이러한 문제를 다루기 위해 EJB가 등장하였고, EJB의 모토는 ‘개발자는 로우레벨의 기술들에 관심을 가질 필요도 없다’ 였다.
EJB의 한계
이렇게 등장한 EJB는 당시 개발자들의 주목을 받으며 널리 쓰이게 되었다. 하지만 시간이 지남에 따라 몇 가지 심각한 문제들로 인해 비판을 받게 되었다. EJB 컴포넌트는 컨테이너 밖에서는 정상적으로 동작할 수 없으므로 개발자들은 끝도 없이 반족되는 수정-빌드-배포-테스트의 과정으로 시간을 낭비해야한다. 가장 최악의 문제점은 EJB 스펙을 따르는 비즈니스 오브젝트들은 객체지향적인 특징과 장점을 포기해야했다는 것이다. EJB 빈은 상속과 다형성등의 혜택을 제대로 누릴 수 없었다.
POJO 개념의 등장
결국 EJB는 낮은 생산성과 느린 성능, 불필요한 기술적인 복잡도등으로 자바의 엔터프라이즈 개발에 대한 불신을 가중시켰고, 마틴 파울러는 EJB와 같은 잘못된 설계된 과도한 기술을 피하고, 객체지향 원리에 따라 만들어진 자바 언어의 기본에 충실하게 비즈니스 로직을 구현하는 일명 POJO 방식으로 돌아서야 한다고 지적했다. POJO방식의 개발은 EJB가 잃어버린 소중한 가치인 객체지향적인 설계와 자동화된 테스트의 편의성, 개발생산성 등을 회복시켜 줄 수 있는 길이기 때문이다.
결국 POJO를 정리하자면
- 특정 규약에 종속되지 않는다.(Java 언어와 꼭 필요한 API 외에 종속되지 않는다.)
- 특정 환경에 종속되지 않는다.
- 객체지향원리에 충실해야 한다.
POJO를 사용하는 이유
- 코드의 간결함(비즈니스 로직과 특정환경/low 레벨 종속적인 코드를 분리하므로 단순하다.)
- 자동화 테스트에 유리
- 객체지향적 설계의 자유로운 사용
POJO 개념의 오해
많은 자료를 조사하다보니 POJO객체를 기본자료형과 Getter/Setter메소드로만 이루어진 클래스로 정의하는것을 보았다. 하지만 위에서 살펴본 것과 같이 POJO의 등장배경과 의미를 살펴보면, 특정 규약/환경에 종속되지 않은 일반적인 클래스들을 지칭하는 단어임을 알 수 있다. 즉, 엄밀히 말하면 Getter/Setter 메소드로 이루어진 클래스는 POJO에 포함된 개념으로 볼 수 있다.
마치며
오늘은 POJO의 등장배경에 대해 알아보았다. 이 포스팅을 정리하며 EJB부터 Spring까지 Java 서버개발의 역사에 대해 전반적으로 알 수 있었다. 사실 EJB에 대해서 정확하게 알 수는 없지만 Spring, Pojo의 등장 배경에 대해 좀 더 잘 이해할 수 있는 시간이어서 의미있는 시간이었다.
이전 포스팅에서도 언급했지만 개발자로 살아간다면, 자신이 사용하거나 사용할 기술들에 대하여 ‘왜 사용되어야 하는가?’ 라는 의문은 계속 제기하면서 살아야 한다고 생각한다. 그런 의미에서 이번 POJO 포스팅은 좀 더 개발다운 사람이 되는 시간이었다.
출처: