가끔 프로젝트 관리를 하다보면 인코딩이 말썽을 일으킬 때가 있다. 

가령 원격 환경에서 GIT 작업을 했는데, 마침 에디터가 제공하는 인코딩이 달라서 저장할 때 파일 전체의 인코딩이 바뀌는 경우가 있다.

(대표적인 경우로 메모장이나 이상하게 세팅되어있던 예전 노트북의 에디터 플러스가 그랬다.)


관련 일을 하는 것이 아니라면 일반 개발자에게 크게 중요하지는 않아보이지만 어느정도 기본적인 유니코드에 대해서 지식은 필요하다고 생각한다.



일반 유니코드는 모든 글자를 2byte로 표현하는 모든 문자를 표현할 수 있는 기본적인 인코딩 형식이다

HTML로 작성이 불가능하다.


 UTF8 인코딩은 모든 문자를 표현하기 위한 개선된 인코딩 형식으로 영문/숫자/기호는 1byte, 

한글 및 한자 등은 3byte를 잘 안쓰이는 문자는 4byte로 표현한다.


통상 유니코드라 하면 UTF8인코딩을 의미하기 때문에, 웬만한 설정은 UTF-8 로 통일시켜주면 큰 문제는 일어나지 않는다.


 *참고로 EUC-KR은 한글 인코딩에 특화되어있는 유니코드 인코딩으로 한글에 2Byte를 사용한다.



SQL이란 DBMS에서 데이터를 질의하기 위해 만들어진 언어이다. 크게 다음과 같이 3가지로 분류된다.


 - DDL (Data Definition Language) : 데이터를 정의하기 위한 언어로, CREATE, DROP, ALTER, TRUNCATE 등으로 시작하는 Query 문이 속한다.
 - DML (Data Manipulation Language) : 데이터를 다루기 위한 언어로 흔히 말하는 CRUD 에 해당하는 SELECT, INSERT, UPDATE, DELETE 등 Query 문이 속한다.
 - DCL (Data Control Language) : 데이터를 관리하기 위한 언어로 주로 사용자에게 권한을 부여하거나 철회할 수 있는 GRANT, REVOKE 등의 Query 문이 있다.


실제로 사용하면서 유용하게 썼던 SQL 쿼리문들을 정리해두었다. 실무에서도 응용해서 사용하면 크게 무리는 없었던 것 같다.

인터넷을 돌아다니다 발견할 수 있는 Geek 한 것들을 모아두진 않았다.


-        접속 방법

 : mysql -u root -p (dbname)


-        비밀번호 변경

 : mysqladmin -u root password 새로운 비밀번호


-        테이블의 생성

 : create table {테이블이름}({칼럼명} {칼럼타입});

(ex) CREATE TABLE member (

id int(11) NOT NULL,

);


-        구조 보기

 : desc 테이블 / explain 테이블  /  show create table {테이블명}


-        이름 변경

 : rename table {테이블명A} to {테이블명B}


-        삭제

 : drop table {테이블명}


-        레코드 삽입

 : Insert into {테이블명} values(v1, v2) / Insert into table(col1, col2) values(v1, v2);


-        조회

 : select * from table {테이블명}


> AS : 칼럼의 이름을 달리 명명해서 출력. (ex) Col1 as 'name'

> Desc : 내림차순, Asc : 오름차순 (ORDER BY)

> LIMIT 10 : 0~10 까지 레코드 수 제한. / LIMIT 100, 10 : 100~110까지 레코드 범위


-        수정

 : Update {테이블명} set col1 = 칼럼1 where 조건


-        삭제

 : Delete from {테이블명} where 조건


-        칼럼 추가

 : Alter table {테이블명} add col3 varchar(255) not null.


-        칼럼 삭제

 : Alter table {테이블명} drop col3


-        칼럼 수정

 : Alter table {테이블명} modify col3 char(50) not null.


-        In : 원하는 필드값만을 선택 추출하는데 사용되는 그룹 조건문


-        조인

(1)  Inner join

 : Select * from tableA inner join tableB on tableA.col1 = tableB.col1

 => tableA col1 tableB col1이 일치하는 데이터만을 출력. ON 절의 조건이 일치하는 조인테이블의 결과만을 출력한다.


(2)  Outer join

 : Select * from tableA left outer join tableB on tableA.col1 = tableB.col1

 => tableA.col1이 존재하나 tableB.col1이 존재하지 않으면 tableB.col1 = NULL인 상태로 출력. 조인하는 테이블의 ON 절 조건 중 한쪽의 모든 데이터를 가져옴(LEFT JOIN , RIGHT JOIN) 양쪽(FULL JOIN)

 

-        내장함수 Benchmark

 : Select Benchmark(반복횟수, 실행쿼리)

(ex) Select Benchmark(100, (select * from table)); => 해당 쿼리를 100번 반복한 벤치마크 결과를 출력.


-        DISTINCT

 : 주로 UNIQUE COLUMN이나 TUPLE을 조회할 때 사용되는 키워드. 칼럼을 DISTINCT 를 이용하여 조회한다면 중복을 제거한 값들을 바로 얻을 수 있다. 단 이 때, 여러 개의 칼럼을 지정한다면 칼럼의 조합이 중복되는 것을 제외한다. DISTINCT는 함수처럼 WHERE이 아닌 HAVING 조건식에도 사용이 가능하다.

(ex) Select DISTINCT email from table;

(ex) SELECT class FROM courses GROUP BY(class) HAVING count(distinct student) >= 5;


-        GROUP BY

 : 데이터를 그루핑해서 결과를 가져오는 경우 사용. 내부적으로 중복값을 배제한채 정렬된 결과를 가져온다. 주로 HAVING과 같이 사용되며 그룹으로 묶어서 자체 정렬한다. 좀 더 정확히는 그룹의 대표값을 정렬해서 가져온다. 그렇기 때문에 모든 컬럼에 대해 단순 SELECT 하는 쿼리문에는 쓰기 적절치 않으며 테이블 내에서 데이터를 가공할 때 사용하기가 좋다. 예를 들어 accountType에 따라 해당하는 accountName의 row수를 그루핑 하고 싶다면 다음 쿼리를 사용해보자. Select accountType, COUNT(accountName) from accounts group by(accountType);

 

-      HAVING

 : HAVING은 GROUP BY 와 같이 쓰이는 구문으로 GROUP BY의 조건문이라 할 수 있다. 위의 쿼리에서 COUNT가 1개 이상인 내용만 쿼리를 하는데 다음처럼 사용 가능하다. SELECT accountType, COUNT(accountName) FROM accounts GROUP BY(accountType) HAVING COUNT(accountName) > 1; HAVING의 시점은 GROUPING이 끝난 이후이고 WHERE 절과 다르게 HAVING 절은 통계함수를 포함할 수 있다.

HAVING은 () 를 안 싸는 것이 좋다. 버전에 따라 오작동 위험이 있는듯하다 ;;


WHERE 구문과 같이 사용할 때, WHERE 구문이 먼저 적용되고 난 다음의 조건 결과에 대해 GROUP BY ~ HAVING 조건문이 걸린다. HAVING 조건문은 그룹화되어진 필드들에 대해 적용된다.

 

-      SubQuery 사용법

 : 복잡한 쿼리문을 만들 때 많이 사용하게 되는 구문이 서브쿼리문이다. 서브쿼리의 사용은 Nested Loop 를 돌기 때문에 사용에 주의하자.

(ex) SELECT accountInfo from accounts where accountName in (select accountName from accountNames);       //accountNames 테이블에 있는 이름에 대해서만 accountInfo를 조회하는 쿼리(Validation)

 


간단한 쿼리문 들이라 대부분 자주 쓰다보니 외워진 상태이지만, SQL에 막 입문하는 사람이거나 쿼리문에 익숙하지 않은 분들은 이 내용만 알게되어도 어느정도 복잡한 쿼리문도 다룰 수 있을 것이다.




최근 심심치 않게 들리는 소프트웨어 용어 중 하나가 프로비저닝(Provisioning) 이다. 


생각보다 오래사용되오던 단어인 것으로 보이나, 최근에 좀 더 각광을 받게 된 이유는 아무래도 클라우드 인프라가 도입되면서 부터지 않을까 생각된다.


프로비저닝(Provisioning) 이란 의미는 영어 직역한 그대로 "제공하는것" 이다. 

어떤 종류의 서비스든 사용자의 요구에 맞게 시스템 자체를 제공 하는 것 프로비저닝이라고 하며 제공해줄 수 있는 것은 인프라 자원이나 서비스, 또는 장비가 될 수도 있다.


좀더 실무적인 표현으로 보자면, IT 인프라 자원을 사용자 또는 비즈니스 Customer에게 Service Vendor 가 제공해주는 것을 말한다.


Server Resource Provisioning : CPU, Memory, IO 등과 같은 실제 서버의 자원을 할당해주고 운영할 수 있게 제공해주는 것을 말한다.


OS Provisioning : OS를 서버에 설치하고 구성작업을 해서 사용할 수 있도록 제공하는 것을 말한다.


Software Provisioning : WAS, DBMS 등의 소프트웨어를 설치하고 세팅하여 실행할 수 있도록 제공하는 것을 말한다.


Account Provisioning : 접근 권한을 가진 계정을 제공해주는 것을 말한다. 클라우드 인프라 쪽에서는 해당 업무를 담당하던 관리자가 변경된 경우 권한의 인계를 Account Provisioning 을 통해 하는 경우가 많다.


Storage Provisioning : 데이터를 저장하고 관리할 수 있는 Storage 를 제공할 수 있다. 특히 클라우드에서는 제공하는 Storage 의 종류와 용도에 따라 다양한 방식의 제공이 이루어진다.


클라우드를 도입하거나 클라우드 환경에서 사용하는 것은 클라우드 Vendor 로부터 서비스를 Provisioning 받아 사용한다고 보면 된다.


이처럼 클라우드 사용시 각 서비스들을 용도에 맞게 세팅을 하여 환경 구성을 자동화 하는 것을 자동화 Provisioning 이라고 하며, 


만약 온프레미스(On premise) 환경에서 클라우드 환경으로의 이식을 준비하고 있다면 이에 많은 신경을 써야 한다.





사실 MySQL은 이미 프로그래밍을 모르는 사람들도 들어봤을 정도로 너무 유명한 Database라 MySQL이 무엇인가를 얘기하는 건 진부한 주제일 지 모른다.


그렇듯 MySQL은 우리가 흔히 "데이터베이스" 라고 하는 시스템의 표준과 같은 소프트웨어이며 그만큼 RDBMS 중 세계적으로 가장 널리 사용되고 있는 소프트웨어이다.


RDBMS에 대해서 간단히 언급을 하자면, 저장한 데이터들 간의 관계를 명시하는 "관계형 데이터 모델링" 을 지원하는 DataBase Management System 이다. 데이터는 테이블에 명시된 여러 Column 값들을 포함하는 Tuple 또는 Record 로 구성되어 Row를 이룬다. 말이 좀 복잡하지만, 간단히 얘기하면 정의된 포맷대로 나열된 데이터의 목록이라고 생각하면 쉽다. 가령 Id 와 Password 를 저장하는 유저 정보의 데이터는 다음과 같이 나타내어질 수 있다.



위의 그림에서 테이블이 나타내는건 유저의 ID와 Password 이다. 이것이 일반적인 DBMS, 즉 데이터베이스 관리 시스템의 모습이다. ID 와 PASSWORD는 테이블을 구성하는 데이터를 묘사(Description)하는 데 기준이 되는 Column 이고, 그 아래의 Record 들은 실제 데이터가 담긴다. 적층된 데이터의 행들이 ROW 이다.


그렇다면 여기에 "관계" 를 추가해보자.




왼쪽 그림과 같은 기존의 유저 ID 관리 테이블에 이번엔 오른쪽의 유저 정보 테이블을 추가했다. 

그런데 자세히 보면, 같은 Column 에 같은 데이터를 갖는 Row를 확인 할 수 있다. 가령 "a123de" 라는 유저와 "jinsp" 라는 유저는 양쪽 테이블 모두에 있으며, 왼쪽 테이블에서는 해당 ID의 비밀번호를, 오른쪽 테이블에서는 해당 ID의 이름과 나이 정보를 알 수 있다.

이렇게 두 테이블은 ID라는 데이터를 기준으로 하는 "관계(Relation)" 를 갖고 있다고 할 수 있으며 RDBMS 는 이런 기초적인 관계에 대한 고민에서 출발한다.


MySQL은 이러한 RDBMS 중에서도 가장 널리 쓰이고 잘 알려져있으며 심지어 무료로 제공되는 훌륭한 소프트웨어라고 할 수 있다. (그 외에도 장점은 많지만, 차차 기술하도록 한다.)


실제로 실무에서도 대부분 MySQL 을 사용하며, 같은 갈래에서 나온 MariaDB나, PostgreSQL 과 같은 DBMS들도 MySQL 에서 상당 부분 아이디어를 공유한다. (물론 각 DB들에 따라 특색은 있다.)



MySQL 을 설치하게 되면 패키지 형태의 프로그램이 깔리게 되며, 이는 여러 가지 단위 모듈들로 구성되어 있다.


<그림 - 출처 MySQL 홈페이지>


엔진을 담당하는 MySQL 은 DB 자체이며, DB를 접근하기 위한 서버와 클라이언트의 형태를 제공한다. 기본적으로 DB에 접근하기 위한 인터페이스를 서버로 두고 있다. 이 서버는 기본 설정에 따르면 localhost IP 에 3306 포트로 열려있으며 이를 통해 MySQL 클라이언트가 이에 접근(Connect) 하여 질의(Query) 하는 구조로 되어 있다. 이때 질의하는 언어는 SQL이다.


즉, 외부에서 드라이버 또는 통신으로 접근 시에도 마찬가지로 TCP/IP 를 통해 MySQL 패키지의 클라이언트 또는 서버로 접근하여 MySQL DB 자체에 접근하게 되는 것이다. (당연해보이는 개념이지만, 개발 시에 SDK 형태로 제공되는 Driver 의 동작원리를 이해하는 것은 중요하다.)


MySQL Server 를 설치하게 되면, MySQL 서버 프로그램으로 MySQL 서비스와 mysqld 프로그램, MySQL 클라이언트 프로그램으로 mysql.exe(CLI 인터페이스), Workbench, slap, mysqladmin 등이 같이 설치된다.






 모놀리식 아키텍처란, 마이크로서비스의 각광에 따라 마이크로서비스가 아닌 전통의 아키텍처를 지칭하는 의미로 생겨난 단어이다. 위의 그림에서 처럼 모든 모듈은 서비스 내부의 Product 형태로 종속되어 있으며, 서비스에만 집중할 수 있는 구조로 되어 있다.


이는 Monolithic 이라는 단어의 뜻 그대로 하나의 Massive 한 Context 형태의 아키텍처를 의미하며 

하나의 서비스 또는 어플리케이션이 하나의 거대한 아키텍처를 가질 때, Monolithic 하다고 한다. 


 모놀리식 아키텍처를 갖는 Software의 특징은 그 자체로 강건하며 내부 요소간의 Dependency 를 크게 가질 수 있다는 점이다. 그리고 이는 필연적으로 구조적인 Coupling 이 강력하게 유지되는 결과를 초래한다. 


 또한 각 비즈니스 컴포넌트들이 하나의 강한 결합 구조를 지니며 통일성이 있다.

이는 비즈니스 로직이 서비스에 최적화된 코드를 만들어내는데 좀 더 집중할 수 있는 반면 복합적인 예외를 만들 수 있는 위험성을 내포하게 된다.



장점과 단점


 개발 초기에는 단순한 아키텍처 구조와 개발의 용이함이 큰 장점이지만 규모가 커짐에 따라 복잡도가 심각하게 증가한다.


 가령 토이 프로젝트를 한다고 생각해보자. 생각이 흐르는대로 Prototyping 을 할 때는 구조가 복잡하고 Dependency 가 크더라도 손쉽게 만들 수 있으며 오히려 모듈별로 분리하고 나누는 것은 코드의 최적화 및 구현에 방해가 되는 경우가 많다.


 그러나 프로토 타이핑 이후에 새로운 컨텐츠를 추가하거나 새로운 팀원이 생겼을 때 문제는 시작된다. 이 거대한 구조가 본인에게는 간단하고 쉬울 수 있으나 새로운 팀원에게는 가혹하게 느껴질 것이다.


 또한 최근 클라우드 환경이 각광받으면서 두드러지게된 단점으로 하나의 모듈을 수정하기 위해서는 전체 어플리케이션의 배포가 수반되며 서버 기동, 빌드 및 배포 시간이 오래걸린다는 점이 있다.


마이크로 서비스 아키텍처 관련 포스팅에서 한번 더 언급을 하겠으나, 일반적으로 마이크로서비스 아키텍처의 Scalability 복잡도가 N+M 이라면 모놀리식 아키텍처의 복잡도는 N*M 형태로 증가하기 때문에 컨테이너의 과부하와 배포 및 스케일링의 어려움을 겪게 된다.


또한 기술 스택의 선택폭이 좁아지며 많은 문제를 해결하기 위해 보다 강력하고 탄탄한 기술력이 요구된다. 이는 내부 구성요소들 간의 강력한 Dependency 문제 때문이다. 한 모듈의 선택은 다른 외부 모듈에서 버그를 초래할 수 있다. 따라서 사용하고자 하는 프로젝트의 큰 그림이 아키텍처 구성 단계에서 그려져 있어야 문제를 최소화할 수 있다.


 최근에는 많은 서비스들이 초창기에 모놀리식으로 개발되고 향후 마이크로서비스 아키텍처로 구조를 변경한다. 

혹은 인프라가 잘 갖추어진 회사에서라면 여러분을 도와줄 많은 플랫폼들이 이미 마이크로 서비스 아키텍처로 존재할 것이다.






IP 주소를 이해하는데 있어 중요한 개념이 서브넷 마스크의 개념이다.



많이 알려져있듯이 서브넷 마스크는 커다란 네트워크를 다루기 위해 서브넷으로 네트워크들을 분리하고 나누어진 네트워크를 지정(designated) 하는 데 사용된다. 


서브넷 마스크는 서브넷을 분리하기위한 기준으로 클래스별로 어디까지가 네트워크 부분이고 어디까지가 호스트부분인가를 나타낸다. 


서브넷 마스크는 다음과 같은 형태를 띈다.


Class A: 255.0.0.0


Class B: 255.255.0.0


Class C: 255.255.255.0


클래스 A가 명시하는 바는, IP주소의 첫 8개 비트가 네트워크 영역을, 나머지 24 비트가 호스트 영역을 나타낸 다는 것을 의미한다. 


여기서 기존의 IP 주소와 자신이 갖고 있는 서브넷 마스크를 AND 연산 하면 네트워크 주소를 얻을 수 있다.


AND 연산이 갖는 의미는 자신이 가진 IP 주소의 1만큼의 부분, 즉 AND 연산으로 살아남는 부분들은 네트워크의 주소라는 일종의 Masking 이 된다. 


그리고 나머지 네트워크 주소가 아닌 호스트의 주소가 의미하는 바는 해당 서브넷에서 호스트로 할당할 수 있는 IP 주소의 범위가 된다. 


이 때 얻어진 네트워크 주소에서 Subnet Mask 의 0으로 된 비트를 모두 1로 바꾸어주면, 즉 마지막 주소가 브로드캐스트 주소가 된다.




가령 위와 같은 IP 주소가 Class C 의 서브넷 마스크를 가질 때, 위의 AND 연산의 결과로 다음과 같은 주소를 알아낼 수 있다.

(AND 연산은 연산하고자 하는 두 비트가 모두 1이면 1을, 그렇지 않으면 0을 반환한다.)


- 네트워크 주소 : 10.9.32.0

- 브로드캐스팅 주소 : 10.9.32.255

- Gateway 주소 : 10.9.32.1 (끝자리만 다른형태로 일반적으로 1)


이렇게 서브넷 마스크를 이용해서 서브넷을 나누는 것을 서브넷팅 이라 한다.

위의 변환은 일반적인 Class 의 서브넷팅을 설명한 내용이고 서브넷 마스크의 기본적인 동작을 나타낸다. 위와 같이 기본 Class C 로 나눈 경우에 해당 서브넷에 할당된 주소는 256개가 된다. 만약 나누어야하는 지역의 IP 가 이보다 훨씬 수가 적다면 이렇게 나누는 것은 낭비가 될 수 있으므로, 그럴 때는 서브넷 마스크를 변경하여 호스트 수를 조절하는 방법도 가능하다. 그리고 이를 bit를 빌려온다(borrowed)라고 표현한다. (ex) 255.255.255.128


(*서브넷팅에 대한 좀더 발전된 사례는 클라우드 쪽 포스팅에서 다룰 수 있을 듯 하다.)



위와 같은 원리로 분리된 서브넷 들을 연결한다면 다양한 네트워크를 연결하여 거대한 네트워크를 구성하기에 효율적이며 관리적 측면에서도 용이하다.


이렇게 분리된 네트워크가 갖는 장점은 보다 기능적인 브로드 캐스팅 도메인을 구성할 수 있고, 


좀 더 큰 의미에서 보자면 IP 주소의 절약 및 효율적인 사용에도 도움이 되기 때문이다. 


라우터를 중간에 둔 상태에서 여러 개의 간섭받지 않는 서브넷을 둔다면 큰 네트워크는 단지 대표 주소 들에 대한 서브넷을 관리하여 계층적인 구조를 이룰 수 있기 때문이다. (자세한 내용은 라우터를 다루면서 한번 더 정리한다.)



일반적인 서브넷은 IP 네트워크 주소를 지역적으로 나누기 때문에, IP가 바뀌더라도 LAN은 동일한 서브넷으로 묶인다. 







가끔 대화를 하다보면 은근히 웹서버(Web Server), 어플리케이션 서버(Application Server) 혹은 웹 어플리케이션 서버(Web Application Server) 간에 단어의 사용이 혼동되어 쓰이는 경우가 많다.


실제로 "웹 프로젝트" 를 한다고 했을때 많은 학생들은 물론 가끔은 실무자 조차도 더러 자신이 만든 프로젝트가 어떤 종류의 서버인지 긴가민가 여기는 때가 있다.


가령 토이 프로젝트로 게시판을 만들었을 때, 이를 웹서버 경험이 있다고 해야하는지, 아니면 웹 뷰가 없을 때 이를 App Server 라고 봐야하는지 헷갈린다거나, 실무에서 해당 웹 프로젝트 아키텍처의 일부분으로 구성된 서버로 어떤 종류의 서버가 붙어야하는지 헷갈린다면 이 문서가 도움이 될 수 있다.




<굉장히 간단히 표현한 Application Server>



먼저 Application Server란 위에 보이는 것 처럼 말그대로 서버 그자체를 나타낸다. 그림에서 보이는 것처럼, 네트워크가 연결되어있기만 하다면, 그 네트워크를 통해 서버와 Endpoint 간의 통신을 할 수 있는 Server 이다.


즉, HTTP 뿐 아니라 TCP, UDP 등 다양한 프로토콜을 전달받아 클라이언트에 다양한 서비스를 제공한다. 

당연히 복잡한 비즈니스 로직의 처리를 할 수 있으며 이에 따라 Client는 단순히 정보를 Display하는 것 이상의 동작이 자유롭다. Java 진영에서는 트랜잭션 처리, 보안 처리, 리소스 풀링, 메시징 등을 처리해주는 EJB, J2EE 등이 대표적이다. 


많은 Application Server는 단순히 Web page를 띄우는 이상을 처리한다.(DB와의 동적인 연동, 클러스터링, fail-over, 로드밸런싱 등) 대표적인 Java 진영의 예로는 레진서버, Spring framework, Expresso 등이 J2EE의 대표적인 Application Server Framework이다. 

Application Server는 엄밀히 말하면 Web Server와 Web Application Server를 포함하는 상위 개념이라고 할 수 있다.




 Web Server 는 HTTP 프로토콜을 주로 처리하는 서버이다. 즉, Web Server는 Application Server에 포함된다. 

HTTP Request를 받아 HTTP Response를 주며, Request를 처리하기 위해 Static HTML, Image 또는 JSON 등을 이용한다. JSP, 서블릿, ASP 등이 이용되어 요청에 대한 단순 응답을 반환하는 간단한 구조를 갖는다. 인터넷 발달 초기, 단순히 인터넷을 통해 문서 조회만 가능하던 시절의 HTTP 서버들은 주로 정적인 동작만 하는 Web Server 였다고 할 수 있다.


 대표적으로 Apache가 있으며, Apache는 정적인 처리에 특화된 웹서버이고, 세트로 있는 Tomcat은 Servelet Container로 정적인 데이터와 동적인 데이터 처리가 가능하지만, 주로 동적인 데이터의 처리를 하는 Web Application Server이다. 


 WAS 가 태어나게 된 배경은, 인터넷의 발달을 예로 들 수 있다. 인터넷의 편한 접근성과 HTTP 라는 단순하면서도 효율적인 프로토콜의 발달로, 인터넷을 통해 단순히 문서 조회 이상의 많은 것들을 요구하게 되었다. 


기존에 TCP / UDP 등의 프로토콜들이 처리하던 전자상거래, 파일 공유 등의 기능 들을 HTTP 로 수행하려다 보니 나타난 새로운 형태의 서버라 볼 수 있다.


 추가로 말하자면 정적인 HTTP 데이터 처리에 특화된 Web server에 동적인 데이터를 이용하게끔 하는 Container를 엮으면 WAS가 되며, WAS는 HTTP 를 이용하는 Application Server로 볼 수 있다.


이러한 미세한 차이 때문에 일반적으로 위에 언급한 Static Server 의 경우 WAS라고 말하기 보다는 Web Server 혹은 스태틱 서버 라고 표현을 많이 하고, HTTP 프로토콜을 사용하지 않는 TCP 서버 등은 WAS가 아닌 App Server 혹은 Application Server 로 표현한다.




소프트웨어에 배움은 끝이 없다고 생각합니다.


그렇기 때문에 지식 들에도 무한한 발전이 가능하며 포스팅 들에 대한 피드백을 지속적으로 받아 업데이트할 예정입니다.


건강한 토론은 언제든 환영합니다.


많은 피드백 부탁드립니다. :)



Spring 을 공부하다보면 빠지지않고 등장하는 개념이 바로 POJO(Plain Old Java Object) 이다.


이는 정말 단순한 개념이지만, 개인적으로 Spring Framework 라는 훌륭한 프레임워크를 만들게 되는 철학의 가장 밑바탕을 구성하고 있다고 생각하는


핵심적인 개념이다. 개인적으로 공부하고자 이 글을 보게되었다면 이해하고 넘어가야한다고 생각한다.



POJO 의 개념 : 주로 특정 자바 모델이나 기능, 프레임워크를 따르지  않는 Java Object를 지칭한다.


거창해보이지만 다음 예제를 보면 간단해진다.

 


public class MyPojo {
private int name;
private int value;

public int getName() {
return name;
}
public int getValue() {
return value;
}
public void setName(int name) {
this.name = name;
}
public void setValue(int value) {
this.value = value;
}
}



그렇다 위와 같은 가장 기본적인 형태의 Java 객체를 POJO라 한다.


좀 더 자세히 명시하자면...


EJB 등에서 사용되는 Java Bean 이 아닌 Getter 와 Setter 로 구성된 가장 순수한 형태의 기본 클래스를 POJO라 하며, 이는 Spring에서 고안된 철학의 핵심적인 부분을 구성하는 요소로 사용된다



향후 포스트를 통해 언급하게 되겠지만 Spring 에서 고안된 중요한 철학은 바로 "복잡성의 해결 을 통한 생산성의 향상" 이다. 


이를 위해서 POJO 는 EJB 의 Bean 에 비해 훌륭한 객체의 단위가 될 수 있다.


그 이유로 먼저 POJO는 그 자체로 객체지향 철학이 반영된 가장 기본적인 단위의 객체이다. 


객체의 상태와 동작을 정의하는 Member variable 과 Method 를 독자적으로 가질 수 있으며 그 자체로 하나의 객체를 묘사할 수 있다. 


또한, 상속성, Interface 등의 여러가지 기술에 의해 종속되지 않는 객체이기 때문이다.  


Java가 급격히 발전해가는 비즈니스 요구를 효과적으로 만족시키고자 Enterprise Java 로 진화하면서 생겨난 EJB는 

오히려 과도한 Over engineering 때문에 객체지향 철학 자체를 효과적으로 구현할 수 없었던 아이러니를 가졌으며, 

이는 개발자들의 시선을 다시 POJO로 향하게 만들었다. 


POJO 의 단순한 구조는 Over engineering 으로 인한 복잡성을 해결하고 모듈화시킬 수 있는 부분에서 큰 이점을 가진 보다 나은 형태의 구조 였고, 이후 개발된 Spring과 같은 POJO 기반의 프레임워크 들은 이러한 이점을 살려 보다 효과적인 기술 스택으로 자리잡을 수 있었다.




블로그 시작을 알리는 첫글 입니다 ^^


개인적으로 경험하고 배웠던 많은 것들을 공유하고 싶습니다.


저에게도 방문해주시는 분들에게도 큰 도움이 되길 바랍니다.

+ Recent posts