프로가 되기 위한 웹 기술 입문 by 고모리 유스케

[ 밑줄 ]

 

어떤 배경에서 문제의식이 싹트고, 그것을 해결하고자 새로운 기술이 만들어진다. 그리고 그 기술을 이용하는 과정에서 또 다른 문제가 발생하며, 그 문제를 해결하기 위해 또 새로운 기술이 탄생하고....

---> 인생이 만나서 모든 것들은 다 이런 것 같다. 하여 '우린 언젠가 답을 찾을것이다'란 선언을 나는 싫어한다. '삶은 문제해결의 연속이다'에서 한 표를 준다.

--> 내가 생각하는 기술/제도/조직/인간정신 등 모든 것들의 진화모델은 '상승하는 나선'모양이다. 어제 보다는 나아졌지만 도달하지는 못하는/않는...끊임 없는 나아짐......박석교수가 그런 주장을 하고, 근래에는 세계적인 신경과학자이자 우울증 전문가인 앨릭스 코브 (Alex Korb)가 '우울할 때 뇌과학'이란 책에서도 유사한 주장을한다.

CGI를 이용한 웹 애플리케이션의 새로운 문제점

- 개발 언어의 문제 : 요구 기능이 커지고 많아져 Perl만으로 개발 한계. 객체지향도 아니고...

- 성능 문제: 늦은 반응시간. 멀티 스레드, 보안, 네트워크통신 등 기술 지원 필요

 

서블릿(Servlet): 자바로 만들어진, HTML 등의 웹 콘텐츠를 생성하기 위한 프로그램

(웹 애플리케이션 프레임원크의 등장)

재사용이라는 발상의 효과적....

자주 사용하는 코드는 Library라는 프로그램 부품으로 정비해 몇 번이고 똑같은 프로그램을 만들지 않아도 되게 한 것도 그 중 하나..

재사용할 수 있는 부분을 늘려 애플리케이션 개발을 용이하게 하는 토대로 만들어진 것이 프레임워크....

프레임워크를 토대로 필요한 부분을 만들어 나가면 원하는 애플리케이션을 단기간에 개발할 수 있음

정보는 패킷이라고 부르는 단위로 분할하여 송수신된다.

패킷의 송수신은 TCP/IP가 책임지고 수행한다.

웹서버와 DB서버 사이에도, DB 제품 고유의 통신 프로토콜을 사용해 통신한다. 그러나 대부분의 경우는 이런 통신을 하는 DB접속용 라이브러리가 표준으로 제공되기 때문에 애플리케이션 개발자가 프로토콜을 의식할 필요는 없다.

(JEBC, ADO.NET 등)

서브릿/JSP를 작동시키기 위한 애플리케이션 서버

(웹 서버와 애플리케이션 서버 연동의 이점)

(애플리케이션 서버가 제공하는 기능)

(1) 세션 관리: 웹 애플리케이션에서 상태를 관리하는 방법이 세션. 사용자가 사용하는 브라우저에 맞춰 세션 ID를 주고받아야 하는데, 이런 것을 애플리케이션 서버에서 자동으로 해 주게 된다.

(2) 트랜잭션 관리: 일련의 처리를 확실하게 종료시켜야 한다는 요구사항이 있을 때.....업무상 함께 실행돼야 하는 일련의 처리를 트랜잭션(trasaction)이라고 한다. 트랜잭션에서 중요한 것은 트랜잭션에 포함된 처리 내역을 전부 성공해야 한다는 점이다. 어느 하나라도 실패할 경우에는 성공한 다른 처리 내역도 원래의 상태로 되돌려야 한다. (Rollback)

(3) DB접속관리: 접속에서 절단까지 철저히 실시해야 하며, 절단 처리를 잊어버리거나 하면 필요 이상으로 메모리를 낭비해 서버 다운의 원인이 될 수 있다.

(4) 웹 애플리케이션 관리와 시스템의 가용성...성능향상: 애플리케이션 서버가 DB에 접속윽 확보해 놓고 웹 애플이케이션의 필요에 맞춰 재사용함으로써 DB 접속을 고속화하는 기능도 제공.....(Connection Pooling)

여러 대의 애플리케이션 서버를 준비해 다운된 서버의 처리를 맡김으로써 시스템의 가용성(Availability)를 향상시켜야 하는데, 이를 위해서는 세션 복제(Session Replication)이라 해서 애플리케이션 서버끼리 연동해 세션의 상태를 공유해야 한다. 

 

(SW건축양식)

비슷한 용도로 사용되는 SW는 필연적으로 닮은 부분이 나타난다. 그리고 그런 설계 스타일과 그 설계에 바탕을 둔 전체 구조를 아키텍처(Architecture)라고 한다.....

(1) 모델

- 애플리케이션의 처리 부분과 그와 관련된 정보의 보존을 담당 (로직 부분)

- 화면에 대한 입출력 같은 부분에는 일절 관여하지 않음

- 모델에 해당하는 작업을 서블릿 내부에서 처리....

(2) 뷰

- 모델의 처리 결과를 화면에 표시하는 역할을 담당 (디자인 부분)

- 처리 결과 자체는 모델에서 가지고 있으므로, 뷰는 모델에서 처리 결과를 추출해 사용자기 보기 편한 행태로 만든 다음 화면에 표시함

- 화면에 표시하는 역할만 하며, 정보 처리에는 일절 관여하지 않음

(3) 컨트롤러

- 화면에서의 정보 입력과 모델의 호출, 결과에 따른 뷰의 호출을 담당함 (로직과 디자인 부분을 연결하는 접착제 역할)

- 사용자가 화면에 입력한 정보를 추출해 처리를 담당하는 모델에 넘긴다....모델의 처리 결과에 따라 결과를 표시할 뷰를 선택해 호출함. 전체의 흐름을 제어하는 것

- 서블릿이 컨트롤러에 해당함 

 

웹 브라우저에서 송신된 요청 ① 을 먼저 컨트롤러가 접수. 컨트롤러는 요청에서 매개변수를 추출하고, 필요하다면 세션에서도 정보를 추출함. 이러한 입력 정보를 처리할 모델을 호출해 각 매개변수를 넘긴다(②). 

모델은 받은 매개변수를 바탕으로 입력 정보를 처리하며 그 결과를 컨트롤러에 반환한다(③). 다만 여기서 돌려주는 것은 처리 결과 자체가 아니라 작접이 올바르게 성공했는지 여부를 나타내는 상태에 불과함.

컨트롤러는 모델에게서 받은 상태를 바탕으로 표시해야 할 화면을 선택하고 그 화면을 표시하기 위한 뷰를 호출한다(④)

뷰는 모델을 참조해 표시해야 할 정보를 추출하고(⑤), 그 결과를 HTML로 출력해 HTTP 응답으로 웹 브라우저에 돌려 보낸다.(⑥)

 

(프레임워크를 통한 아키텍쳐 구현)

- 아키턱처의 지식을 간단히 구현할 수 있는 방법은 없을까? 그래서 등장한 것이 프레임워크(framework)라는 개념

- 본래 틀 또는 구조라는 의미

- 공통적인 아키턱처 부분을 반완성품 SW로서 구현해 차이가 있는 부분만 만들면 되게 한 것이 바로 프레임워크

- 아키텍처를 구현하는 부분은 공통화하고 겉모습이나 사용자에게 제공하는 서비스처럼 애플리케이션마다 다른 부분은 따로 개발할 수 있게 하면 효율적으로 애플리케이션을 개발할 수 있다.

- 모든 것을 처음부터 개발하지 않아도 되기 때문에 품질도 높아진다. 이 아키텍처를 구현하는 공통 부분이 바로 SW에서의 프레임워크다. 

(프레임워크 이용의 장점과 단점)

(장점)

- 설계/개발 공수의 절감: 시행착오/검증된 것들의 재사용. 

- 품질 향상

- 테스트 공수의 절감

(단점)

- 학습 비용의 증대

- 설계의 자유도 저하

- 장기적인 기술력의 저하

 

[ 자평 ]

 

2010년이니 기술 분야에서는 상당히 오래된, 낡은 책이다.

웹 애플리케이션의 기본에 대해서 정말 잘 쓴 책이다. 모든 분야가 마찬가지만 기술/과학 분야를 쉽게 쓰기란 어렵다....

 

알고 있는 것과 만들 줄 아는 것은 천지차이다.

그래서 나는  무언가를 만들어 낼 줄 아는 사람들이 부럽고 존경스럽다.

경험상 (나쁜 결과를 바탕으로 비유하자면) 나 같은 문돌이는 '혀'로 일하는 족속들이고, 기술/공돌이 들은 '손'으로 일하는 족속들이다........평균적으로 조직에 '혀'로 일하는 족속들이, '손'으로 일하는 족속보다 많거나 , 권력의 비중이 혀로 쏠린다면.... 그 조직은 '화려한 불꽃'처럼 망한다.....'화려한 말발'로 터져서 망한다.....

나처럼 경영진이나 임원들과 가까이 있다는 특권으로 PPT와 엑셀위에서 혀만 살아 있는 문돌이들은 항상 스스로를 경계해야 한다고 본다.. 돌아 봐야 한다고 본다.... 내 말과 글이 혹시 '허세'는 아닌가.....잘못된 곳을 지향하고 있지는 않은가...

'뭔가를 만들어 내 본 것이 없다'는 것은 참으로 불행한 일이지만...

대충 경영학/경제학 등 실용학문을 전공한 사람들의 생각은 아래 그림과 같다.

'Black Box'가 핵심인데.....Input/Out 그리고 전체 시스템의 Organizing이 핵심이라고 스스로 세뇌한다.

비핵심적인 것은 기술/공학자들에게 시켰고....나는 핵심인 전체 시스템을 관리한다. '관리'(managing)도 기술이다.

경영이 핵심이다. 또한 대부분의 일이란 실패하기 때문에 이런 구도가 실패에 대한 면피의 사유와 근거, 논리와 바탕으로 작용할 경우가 많다.....

나는 ROI가 만들어 지는, 고객이 원하는, 경쟁자를 뛰어남는 것을 만들라고 했으나... 만드는 자들이 못 만든 탓이다....

 

이제는 프로그램을 하거나 관련된 일을 할 일이 없기 때문에 거의 읽지는 않는다.

하지만 기술들이 어떻게 구현되는지가 궁금하여 개발자용 책을 독서하듯이 읽을 때가 있다.

 

만들 줄 모른다면, 어떻게 만들어지는지 대충은 알아야 한다.

대충은 모르더라도 만드는 사람들에 대해서 공감할 정도는 알아야 한다.

공감할 정도도 모른다면 그 고충은 알아야 한다.

고충을 까지는 모른다면, 서로의 존재와 역할의 가치는 인정해야 한다.

존재와 역할을 인정할 줄 모르면.... 만들 줄 알아야 한다.