앜스토리 | 호기심 많은 개발자의 보물창고

드디어 스프링에 들어간다. 앞에서 작성한 포스팅은 스프링을 배우기전의 전반적으로 알아두어야 할 것들이다. 알고 배우는 것과 모르고 배우는 것은 보이는 시야가 다르다고 하지 않았던가 ㅎㅎ.. 스프링은 DI 컨테이너와 AOP 등을 구현하는 스프링 프레임워크를 말한다. 구현은 뒷 부분에 나오겠지만, 우선은 지금까지 포스팅한 웹 애플리케이션과 애플리케이션 아키텍처의 관계, 스프링의 필요성과 특징부터 이해하자. 스프링이란? 스프링은 로드 존슨을 중심으로 개발된 Java/Java EE용 프레임워크이다. DIxAOP 컨테이너를 중심으로 MVC 프레임워크(스프링 MVC, 스프링 웹 플로), JDBC를 추상화한 프레임워크(스프링 JDBC), 기존 프레임워크와의 통합 기능 등을 개발자에게 제공하는 애플리케이션 아키텍처의 ..

여기까지 부품화의 이야기(포스팅)은 아키텍처로서의 모놀리식(monolithic) 형태를 대상으로 해왔다. 여기서는 현재의 이야기를 해보자. 우선 모놀리식의 아키텍처는 웹 애플리케이션이 하나의 프로젝트 형태로 디플로이된 형태이다. 따라서 모놀리식 아키텍처에서는 부품화 후 한 부품을 수정하더라도 전체를 다시 디플로이 해야 한다. 이렇게 되면 부품화한 의미가 흐려질 것이다. 그래서 어느 정도의 크기 및 모놀리식이라고 보이는 복잡한 시스템은 부품을 개별로 작성-수정해서 디플로이할 수 있다고 생각한 마이크로서비스(Microservices)가 나왔다. 어느 비즈니스 용건에 특화한 단위로, 거기에 UI부터 DB의 액세스까지 포함해도 문제(단, 라이브러리 같은 범용, 공용 부품은 별도)가 되지 않는다. 이렇게 잘라낸 ..

이전 포스팅에서도 작성을 했지만, 스프링을 사용하지 않았을 때의 문제 세 가지를 꼽자면 다음과 같다. - 오브젝트의 생명 주기 문제 - 부품화 문제 - 기술 은닉과 부적절한 기술 은닉 문제 이러한 문제를 해결하지 않는 한 웹 애플리케이션은 리소스를 잘 이용하지 못하고, 테스트하기 어려우며, 확장이나 변경도 어려워질 것이다. 스프링은 이러한 문제를 해결하기 위해 태어난 컨테이너라고도 할 수 있다. 자세한 내용은 나중에 설명하겠지만, 스프링은 다음처럼 문제를 해결해줄 수 있다. - 오브젝트의 생명 주기 문제는 DI 컨테이너로 해결 - 부품화 문제는 DI 컨테이너로 해결 - 기술 은닉과 부적절한 기술 은닉 문제는 AOP로 해결 스프링은 Java/Java EE용 오픈 소스 프레임워크이고, 현재는 Pivotal ..

개발자의 수준을 고려하지 않은 채 고급 기술을 초보 개발자에게 이용하게 해서 장해를 일으키거나, 부적절한 기술 은닉으로 기술 이용을 어렵게 하는 문제도 개발 현장에서는 흔히 볼 수 있다. 게다가 고객 클래스나 수주 클래스 내에 고객이나 수주 처리라고 하기 어려운 트랜잭션이나 예외, 로깅과 같은 처리가 들어가면 프로그램의 가독성을 현저하게 떨어뜨릴 우려가 있다. 또한 여러 클래스에 걸쳐 존재하는 트랜잭션이나 예외 처리, 로깅 처리는 프로그램의 가독성을 떨어뜨리기도 하고, 유닛 테스트 역시 어렵게 만들기도 한다. 덧붙여 여러 클래스에 걸쳐 있는 트랜잭션의 예외 처리 및 로깅 처리는 부품화를 촉진하는 데 방해가 되기도 한다.

웹 애플리케이션을 구축하는 오브젝트 사이의 의존 관계는 인터페이스를 매개로 해서 구현에 의존하지 않음으로써 오브젝트 사이를 약한 결합으로 유지할 수 있다. 또한, 그렇게 함으로써 오브젝트를 쉽게 확장-변경하고, 개발 효율을 올리며, 시스템을 고품질로 유지할 수 있음은 앞에서 설명했다. 예를 들어 오브젝트가 인터페이스에만 의존하면 인터페이스가 확장/변경되더라도 이용하는 오브젝트에는 아무 영향도 주지 않는다. 또한, 인터페이스의 배후에 있는 오브젝트가 미완성일 때에도 mock 오브젝트로 치환해 개발을 중단하지 않고 진행할 수 있으며, 테스트용 클래스로 치환해 손쉽게 테스트를 시행할 수 있다. 이러한 사고방식을 적극적으로 밀고 나가면 전자 제품처럼 부품별로 개발 거점을 나누어 작성할 수 있다. ※ 물론 Moc..

EJB의 문제(현재는 문제점이 해결된 상태) 이전에 스프링은 안티 EJB라는 느낌이었지만, EJB 자체가 버전 3.0으로 넘어가면서 DI 컨테이너, AOP 프레임워크가 됐으므로 이제 EJBㅣ와 비교해 스프링의 우위를 증명하는 방법은 성립하지 않는다. 과거에 EJB라는 중량 컨테이너의 안티테제(antithese)로서 경량 컨테이너를 자처하고 등장한 스프링이 현재는 오히려 비교 대상이 Java EE가 됐을 정도로 스프링은 거대해졌다. 이를 방지하려면 서비스 로직의 오브젝트는 싱글턴(singletone)으로 해야 하지만, 오브젝트를 싱글턴으로 하려면 구현을 변경해야 하고, 어떤 사정으로 오브젝트가 싱글턴일 필요가 없어졌을 때의 비용이 커지는 단점이 있다. 또한, 마찬가지로 싱글턴처럼 오브젝트가 HTTP의 Se..

지금까지 개발 효율성과 유연성 향상을 애플리케이션 설계 목표로 삼고 이를 실현하는 방법으로 티어와 레이어에 관해 이야기했다. 정리하면 결국 애플리케이션을 부품화하자는 말로 통일된다. 부품이 큰 쪽은 티어나 레이어가 되고, 그보다 작은 부품은 패키지나 컴포넌트가된다. 그리고 부품끼리는 인터페이스로 연결된다. 정리하면 이 모든 것이 부품화라고 할 수 있다. 더 간단히 말하자면, TV, DVD 레코더, 스피커 등으로 구성된 가전제품이나 모니터, 마우스, 메인보드, CPU와 메모리 등으로 구성된 컴퓨터처럼 애플리케이션을 여러 부품으로 조립된 전자 제품과 같은 아키텍처로 만들어서 개발 효율성과 유연성을 높이는 것이다. 티어나 레이어처럼 큰 부품은 현실 세계에서 컴퓨터와 모니터, 스피커에 해당한다고 생각하면, 패키..

DB 액세스 프레임워크로 흔히 알려진 것은 ORM(O/R 매핑 프레임워크)이다. ORM은 XML 드응로 기술된 매핑 파일로, 오브젝트와 테이블을 매핑한다. 매핑 파일 작성은 손이 많이 가지만 개발자가 SQL 문을 작성하지 않아도 된다는 특징이 있다. ORM의 대표적인 프레임워크가 하이버네이트이다. 반면 직접 SQL문 사용을 전제로 한 DB 액세스 프레임워크도 있다. 스프링에 포함된 스프링 JDBC나 MyBatis가 여기에 해당한다. 데이터 액세스 층의 설계 지침 설계를 생각하기 전에 데이터 액세스 층의 구현을 생각해보자. 데이터 액세스 층의 구현은 O/R 매핑인지 R/O 매핑인지에 따라 달라진다. O/R 매핑은 ORM이라고 일컫는 하이버네이트 등을 이용한다. R/O 매핑으로도 테이블 구조가 복잡하면 스프..

데이터 액세스 층의 역할 데이터 엑세스 층은 기본적으로 RDB(테이블) 엑세스를 비즈니스 로직에서 숨기고, 비즈니스 로직에 필요한 데이터를 테이블에 취득해서 오브젝트에 매핑하는 것이다. 이렇게 오브젝트와 RDB를 매핑하는 것을 O/R매핑이라고 한다. [O는 Object, R은 Relational(테이블)] O/R매핑 O/R매핑은 시스템 개발 방법에 따라서 O에서 R과, R에서 O의 두 가지 방향이 존재한다. 일반적으로 O에서 R의 O/R 매핑은 객체 지향 분석으로 엔티티(도메인 모델의 클래스)를 추출해, 그 엔티티를 바탕으로 설계 단계에서 테이블을 작성한다. 기본적으로 테이블읠 한 레코드가 한 오브젝트에 대응한다. 객체 지향으로 분석-설계하면 일반적으로 이러한 O/R매핑이 된다. 마찬가지로 R에서 O의 ..

트랜잭션이란 간단히 말해 처리 단위이다. 예를 들면, 웹 사이트에서 검색하고 상품 목록을 보기까지의 트랜잭션, 웹 사이트에서 상품을 주문해서 상품이 집에 도착하기까지처럼 긴 트랜잭션, 주문을 받고 발주 테이블과 고객테이블, 재고 테이블을 갱신하는 데이터베이스 트랜잭션 등이 있따. 여기서는 그중 데이터베이스 트랜잭션을 다루지만, 이처럼 다양한 트랜잭션이 있다는 점을 기억해야 한다. 이 트랜잭션에는 지켜야 할 ACID라는 특성이 있다. 이 중에서 애플리케이션 아키텍처로서 신경을 써야하는 것은 원자성(atomicty), 독립성(isolation)이다. 반면, 영속성(durability)은 우리가 만드는 애플리케이션의 전제 조건이라고 할 수 있다.(애플리케이션에서 어떻게 영속성을 보증할 것인가?) 시스템을 구축..