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

비즈니스 로직 층은 서비스나 도메인 같은 비즈니스 로직을 구현하는 웹 애플리케이션의 중심이다. 개인적으로는 웹 애플리케이션의 성공은 비즈니스 로직 층에 달려 있다고 믿는다. 다음 표처럼 비즈니스 로직 층은 유스 케이스로 표현되는 특정 업무나 특정 부서 처리의 통합인 서비스 및 도메인으로 구성된다. 도메인은 서비스에서 시작되는 비즈니스 실행에서 필요한 고객이나 주문 등의 처리르 구현하는 클래스의 집합이다. 이 서비스와 도메인은 각각 비즈니스 층에 만들어진 서비스 패키지의 클래스와 도메인 패키지의 클래스로 구현한다. 그런데 개발할 때나 운영할 때나 웹 애플리케이션의 기능 추가와 변경은 주로 비즈니스 로직 층의 로직 변경이다. 다시 말해 아키텍처가 유연한 웹 애플리케이션을 만들기 위해서는 로직 층을 잘 만드는..

웹 애플리케이션이 비즈니스에 도입될 당시에는 한정된 사람만이 컴퓨터를 이용했고 일반 소비자는 별로 이용하지 않았다. 그래서 시스템 운영을 우선했고 사용자 인터페이스는 대충 만드는 경우가 많았다. 물론 버튼 위치라든가 표의 위치 등 세밀한 부분에 신경 쓰는 경우는 당시에도 있었지만, 사용자 인터페이스 자체가 지금처럼 복잡하지 않아 개발 기간을 생각하면 개발 비용의 차이는 미미한 수준이었다. 그러나 요즘은 일반 가정까지 컴퓨터(컴퓨터라고 부르는 자체가 시대에 뒤처져 보이기도 하지만)가 보급돼 초등학생도 인터넷으로 쉽게 검색할 수 있다. 웹 브라우저에서는 Ajax에 의한 비동기 통시능로 편의성 향상을 도모하고, iOS나 Android 등을 사용하는 스마트폰에서는 TV 게임과 같은 사용자 인터페이스를 제공하고 ..

예전 J2EE의 MVC2(Model-View-Controller)는 스몰토크(smalltalk)에서 확립된 MVC 패턴을 참고한 것으로, Model 부분에 JavaBeans(EJB), View 부분에 JSP, Controller 부분에는 Servlet을 사용한다. MVC2라는 이름은 스몰토크의 MCV 패턴을 따라했거나, JSP Model2가 MVC 패턴과 유사한 데서 만들어진 것으로 보인다. Column2 MVC2와 JSP 모델 JSP 모델은 표시 부분인 프레젠테이션과 비즈니스 로직을 분리해 변경을 최소화하는 기술의 발전사를 보여준다고 할 수 있다. 일반적으로 컨트롤러는 스프링이 제공하는 스프링 MVC나 오픈 소스의 MVC 프레임워크에서 제공되므로 이를 이용할 때가 많다. 요즘은 그런 일이 없겠지만 프로..

웹 애플리케이션의 레이어는 크게 비즈니스와 관련된 부분과 비즈니스 로직의 결과를 어떻게 표현할지 구현하는 두 부분으로 나눌 수 있다. 비즈니스 로직이야말로 애플리케이션에서 가장 중요하며, 비즈니스 로직의 결과를 어떻게 다룰지 구현하는 기술(예를 들어 브라우저에 표시하거나 RDB에 저장하는 기술 등)이 비즈니스 로직에 영향을 미치지 않는 것이 좋은 설계이다. 그러므로 기존의 세로형 레이어를 버리고 새로운 형태의 레이어를 생각해야 한다. 그것이 이번에 다룰 오목형 레이어이다. 아래 그림에 관해 덧붙이자면 UML 방식으로 그린 것이다. 그림 안의 동그라미는 UML의 인터페이스, 사각형은 클래스이다. 자바를 이용하는 엔지니어라면 반드시 UML을 읽을 수 있어야 한다. 혹시 그림의 원이나 사각형에서 뻗어가는 점선..

웹 애플리케이션의 아키텍처는 크게 티어라고 하는 물리층과 레이어라고 하는 논리층으로 나뉜다. 티어와 레이어 양쪽 다 한국어에서는 층이니 중의해야 한다. (사람에 따라서는 티어를 단, 레이어를 층으로 구별하기도 하지만, 보통 양쪽 다 층으로 해석한다.) 티어는 클라이언트 층, 중간층, EIS(enterprise Information System)층의 3개 층이 기본이다. 기본적으로 웹 애플리케이션에서 고려할 것은 중간 층이지만, 현재의 웹 애플리케이션에서는 클라이언트 층이 데스크톱 컴퓨터이고 중간층에 있는 웹 애플리케이션에서 웹 브라우저에 HTML을 보내는 것이라는 설명만으로는 충분하지 않는다. 예를 들어, 클라이언트가 스마트폰이고 스마트폰 앱이 웹 애플리케이션의 기능 일부를 구현하는 경우도 있다. 그럴 ..

애플리케이션 아키텍처를 개발하는데 한 가지 오해하지 말아야 할 것이 있다. 사용자의 요구에 따라서 변경이나 확장의 용이성을 무시하고 애플리케이션 아키텍처 등을 고려하지 않은 채 JSP로 데이터베이스에 직접 접근해도 좋다는 것이다. 이 역시 사용자의 요구를 만족하기 위한 훌륭한 기술이다. 사용자의 요구나 여러 조건도 고려하지 않고 '책에 쓰여 있으니까' 또는 '외국의 유명한 사람이 말했으니까'라는 이유만으로 이것도 안된다, 저것도 안 된다고 하는 엔지니어가 많다. 우리는 이러한 꽉 막힌 사고방식에는 반대한다. 그것이야말로 엔지니어의 창조력을 방해하고 일하는 즐거움을 앗아가는 일이기 때문이다. 우리가 지향하는 웹 애플리케이션 개발이란 사용자의 요구와 개발자/운영자의 요구라는 두 가지 목표를 만족하는 애플리케..

우선 개발 효율성을 살펴보자. 이 목표가 왜 필요한지는 직관적으로 이해할 수 있을 것이다. 애플리케이션의 아키텍처를 이해하기 위해 5,000쪽이나 되는 문서를 읽어야 한다거나 애플리케이션의 아키텍처를 동작하게 하려고 의미를 알 수 없는 주문 같은 코드를 삽입해야 한다면 말이 되지 않을 것이다. 애플리케이션 아키텍처는 이해하기 쉽고 간단히 사용할 수 있어야 한다. 테스트도 마찬가지이다. 어떤 오브젝트를 테스트하기 위해 웹 컨테이너를 꼭 준비해야 하거나 라이브러리에 클래스 경로를 이것저것 설정해야 하거나 테스트를 위해 구현을 변경하는 것은 귀찮은 작업이다. 테스트는 간단하게 실행할 수 있는 것이 가장 좋다. 웹 애플리케이션의 생명 주기와 애플리케이션 아키텍처의 필요성에 대해 알아보자. 애플리케이션 아키텍처의..

애플리케이션 아키텍처는 시스템 개발의 성공에서 가장 중요한 요소이다. '난 프로그래머니까 설계나 아키텍처와는 관계없다'고 하지 말고 꼭 구독해보자. 게다가 우리가 생각하는 프로그래머란 애플리케이션 아키텍처를 이해해야 비로서 한 사람 몫을 할 수 있다. 레퍼런스나 설명서를 읽고 자바로 코딩할 수 있는 정도로는 절반의 몫밖에 하지 못한다. 또한 애플리케이션 아키텍처를 이해하지 않고는 스프링이 왜 웹 애플리케이션 개발에 필요한지 이해할 수 없을 것이다. 애플리케이션 아키텍처의 필요성에 대해 알아보자. 애플리케이션 아키텍처는 일반적으로 애플리케이션 전체의 구조, 공통된 방식(메커니즘) 이라고 정의할 수 있다. 다시 말해, 시스템의 애플리케이션이 공통적으로 이용할 수 잇는 사용자 인터페이스 구조나 데이터베이스 접..

현재는 사실상 스프링이 Java/Java EE의 표준 프레임워크이다. 특히 2008년부터 대한민국 공공 기관의 앱 개발 시 사용을 권장하고 있는 전자 정부 표준 프레임워크의 기반 기술로 쓰고 잇다. 아키텍트라고 부르는 사람 중에는 '자바로 개발할 때 스프링을 이용하지 않는 다른 선택을 찾는 일이 더 어렵다'고 말하는 사람이 있을 정도이다. 자바 자체가 앞으로 클라우드를 향해 진화하고 점점 더 이용될 것을 고려하면, 마찬가지로 클라우드를 지향하는 스프링의 정보를 따라잡는 일은 앞으로 더 중요해질 것이다. 어쨌든 자바의 진화를 재촉한 것은 다름 아닌 스프링이기 때문이다.

1990년대 말, 자바의 엔터프라이즈 에디션인 J2EE는 버전업을 거듭할 때마다 JSP, Servlet, EJB의 기능도 많아지고 새로운 표준도 추가되엇따. 이렇게 시간이 지날수록 J2EE는 무거워지고 복잡해졌다. 그래서 웹 애플리케이션 개발에는 더 가벼운 것을 이용하고 싶은데 J2EE는 너무 무겁다고 생각하는 사람이 많아졌다. 스프링 개발을 이끌어온 로드 존슨도 그중 한 사람이었다. 중량급인 J2EE 컨테이너를 대신할 경량 컨테이너로서 DI와 AOP의 기능을 가진 DI x AOP 컨테이너인 스프링을 고안해낸 것이다. DI x AOP 컨테이너는 POJO(Plain Old Java Object)라고 부르는, 컨테이너와 프레임워크 등에 의존하지 않는 일반 오브젝트의 생명 주기 관리나 오브젝트 간의 의존 관계..