멀리 돌아왔다. 드디어 이 시리즈의 가장 큰 목표, Spring이다. Spring이 등장한 배경을 알기 위해 이 시리즈를 기획했는데, 깊이 들어가다보니 EJB가 나왔고, EJB라는 것 자체가 그렇게 어려우면 안쓰면 될 텐데! 하고 더 파보다 보니 java의 등장과 발전 과정이 나왔기에, 시리즈를 기획할 수 밖에 없었다. 아무튼, 이번 포스팅의 주제는 Spring의 등장이다. 자료 조사 자체가 만만치 않았다. 여러 서적과 블로그, 당시 진행했던 강연과 같은 것들을 훑어 보고 이를 정리하다보니 많은 시간이 걸려 이 포스팅이 늦어지게 되었다. 먼저, 지난 포스팅 마무리 단계에서 나왔던 EJB를 사용하게 된 계기에 대해 말해보자면, 트랜잭션 관리 인증과 접근 제어 EJB 인스턴스 풀링 세션 관리 DB와의 커넥션 관리 위와 같은 로우 레벨 기술을 개발자들이 신경쓰지 않아도 될 수 있게, EJB 사양이 이를 대신 해주었던 것이다. 하지만 이를 위해 E

이전 포스팅에서는 ejb의 탄생 배경과 특징, 가능한 기능에 대해 다루어 보았다. 이번 포스팅은 어떤 구조를 가지며, 동작 원리는 어떻게 되는 지 정리하려 한다. > #### 용어 정리 Enterprise Beans, EJB Bean - 빈 EJB Container - 컨테이너 먼저 EJB를 사용하기 위해서는, 두 가지가 필요하다. 예전 web server와 WAS를 다룬 포스팅에서 잠깐 언급했는데, WAS의 내부 모듈이면서도 WAS의 다른 이름인 Web Container, 그리고 EJB Container이다.(일부 문서에서는 EJB 엔진이라고 표현하기도 한다.) 그리고 빈은 컨테이너 내부에서 동작하며, 컨테이너는 빈들의 lifecycle 관리를 맡는다. *빈

Servlet, JSP의 등장 이후 시스템 규모가 점점 커져갔다. 대량의 트래픽을 감당하기 위해 서버를 나누고, 여러 대의 서버와 DB가 데이터를 주고 받다보니 시스템 구조의 복잡성이 증가했다. 한 가지 요청을 위해 여러 서버나 DB가 개입해야 한다든지, 여러 db 요청이 오가야 한다든지, 요청 중 다른 요청을 동시에 처리해야 한다든지 등의 복잡한 기술이 요구되기 시작했다. 여러 시스템이 운용되다보니, 데이터가 오가는 데에 있어 보안이 취약해지는 부분이 생기기도 했다. 하지만 기업 내 한정된 개발자 풀 내에서 비즈니스 로직 뿐만 아니라 위의 문제와 요구를 해결하기는 쉽지 않았다. 이러한 문제를 해결하고자 나온 기술이 바로 이번 포스팅에 소개할 EJB이다. EJB EJB의 사상은 위에 제기된 여러 문제, 즉 로우 레벨의 기술에 대한 문제를 신경쓸 필요 없이 비즈니스 로직에만 집중할 수 있게 하는 데에 있다. EJB는 독립적으로 개발한 컴포넌트를 배포하고, 서로 연동해

Servlet이 등장한 이후, 위와 같이 html 태그를 한줄 씩 작성하여 response를 작성했다. 하지만 손이 너무 많이 가는 방식이라고 판단되어 큰 틀의 html을 미리 짜놓고, 그 안의 동적 요소만 인자값에 따라 달라지는 templete을 만들게 된다. 하지만 templete을 사용하는 방법 또한 손이 너무 많이 갈 뿐 아니라, html내용이 변함에 따라 전체적으로 모두 개편해야 하는 상황이 발생하게 된다. JSP 지난 포스팅에서 다뤘던 Servlet이 자바 코드에 html을 담는 개념이었다면, JSP는 html에 자바 코드를 담은 형태로 이루어지는 기술이다. 자바 코드를 사용하기 위해 JSTL이라는 형식을 사용해 html태그 사이에 JSTL태그가 섞여 들어가게 된다. 물론 html 형식에 자바

지난 시리즈에서 기술한 바와 같이, 동적 페이지를 만들기 위해 자바 애플릿이 사용되었고, 시간이 지남에 따라 동적 페이지에서 요구하는 데이터의 양이 방대해지기 시작하면서 자바 애플릿 태그로 프로그램을 다운받아 사용하는 방식에서 CGI라는 방식이 등장했다. > 여기서 잠깐, 정적 페이지와 동적 페이지의 차이에 대해 다시 짚고 간다. 정적 페이지 - 파일 경로를 받아 경로에 맞는 페이지를 반환한다. 이미 만들어져 있는 html, css, image와 같은 컴퓨터에 저장된 파일을 반환하는 것 동적 페이지 - 동적 페이지는 인자를 받아 인자에 맞는 페이지를 반환한다. 인자를 처리하는 로직이 필요하며, 웹 서버에 의해 실행되는 프로그램의 로직을 통해 만들어진 결과물을 반환하는 것 결국 정적 페이지와 동적 페이지는, 이미 만들어져 있는 페이지를 반환하느냐, 사용자에 따라 변화된 페이지를 반환하느냐의 차이라고 볼 수 있다. CGI ![](https://velog.vel

나는 자바 개발자로 활동하면서 어떤 배경에서 필요성이 대두되었고, 그 필요성과 편의성을 위해 제작되었는지 정리하기보다, 어떻게 사용해야 하는 지 알아보고 정리하는 것에 급급했다. 시리즈를 시작하면서, 기술이 어떤 이유에서 생겼고, 어떤 장점을 가지고 현재에 와 있는지, 그리고 혹시나 내가 더 좋은 방향으로 발전시킬 수 있진 않을 지 알아보기 위해 정리해본다. OAK의 탄생 자바는 제임스 아서 고슬링이라는 현재까지도 활동중인 개발자에 의해 개발되었다. 이 사람은 sun micro system이라는 기업에 재직 중 '그린 프로젝트'라는 프로젝트에서 냉장고, tv등 가전 제품 내 플랫폼과 독립된 기능을 만들고자 oak라는 언어를 개발했다. sun micro system은 1982년 설립된 기업

프로젝트 마무리와 함께 하는 정리,, 어느덧 몰입해있던 프로젝트를 마무리하고 편히 쉴까,,,,하다가 '언제든 보아도 다시 구현 할 수 있는 정리를 해내자!'라는 마음으로 정리를 해본다. 블로그 머리에 써둔 것처럼 '제대로 아는 것만 정리하기'로 했기에, 정말 제대로 알고 있다고 생각하는 질리도록 보아왔지만 이후 보지 않을 수 있는 내용들을 정리해 나가려 한다. kafka는 두 가지 프로젝트에서 사용했다. MSA 아키텍쳐이자 여러 데이터베이스를 가지는 서비스에서 데이터 전송을 용이하게 하고 또 다른 모듈을 개발할 계획이 있었기 때문에 확장성을 고려했던 프로젝트, 실시간 데이터 전송을 하고자하는 프로젝트에서 사용했다. 사실 이 포스팅의 초안은 팀 동료들과 kafka에 대한 이해와 구축 방법에 대한 공유를 위해 작성되었으나, 이후에 볼 나와 모두를 위해 블로그에 작성하기로 했다. 그래서 kafka는 왜 쓰는데..? ![](https://vel

얼마 전 좋은 제안을 받았다. 본인이 하고 있는 웹 앱 프로젝트가 있는데, 프론트엔드로 참여하겠냐는 제안이었다. 나는 한 우물에 집중하는 편인지라, 현재 기업에서 일하고 배우는 것을 중점적으로 하기에 벌써 사이드 프로젝트를 진행하는 것은 좋지 못하다 생각이 들어 거절했다. 그 프로젝트에는 여러 개발자들이 참여한다고 들었다. 주로 게임 개발자들이 많다고 하는데, 그들은 개발을 해온 삶이 게임에 치중되어 있었을 테고, 게임에서 사용하는 통신이나 툴을 웹에도 이용하면 더 효율적이라 생각하고 있는 듯 했다. 그 중 흥미로운 주제는,, "아니 http를 왜 쓰는 거예요? 그냥 tcp쓰면 되지 않나요?" 라는 주제였다. 사실 현재 재직 중인 기업에서 Netty를 이용해 tcp 서버를 구현해본 내 입장에서는,, "..그러게?" 라는 느낌이었다. 이 전에 타 사와 협력하는 프로젝트 진행 중, 상대 기업 보안이 까다로워 통신 호스트에 대해 모두 조사해야하는 업무가 있었는데, W

const, let, var로 시작하여 모르는 단어들이나 개념들이 많아 공부하면서 정리하다보니 여기까지 오게 되었는데, 오늘은 JavaScript 코드를 실행하는 원리인 인터프리터와 비슷하면서도 다른 원리인 컴파일러에 대해 이야기 해보겠다. Compiler vs Interpreter 컴퓨터 언어들을 몇 가지 살펴보다 보면, 컴파일 언어, 인터프리터 언어라는 말이 있었다. 사실 나도 이 블로깅을 위한 공부를 하기 전까지만 해도 컴파일링 - 편집, 인터프리팅 - 통역 정도의 직역만 가능했다. Conpiler 컴파일러와 인터프리터의 가장 큰 차이점은, 컴파일링 작업의 유무이다. 컴파일링 작업은 컴파일러나 프로그래밍 언어의 특성에 따라 일부 단계는 생략되거나 더 세부적인 단계로 나뉠 수도 있지만,

내용에 들어가기에 앞서 이 내용은 추상적인 개념을 다루고 있기에, 추상적인 설명과 예시가 주된 내용임을 미리 알립니다. 오늘은 태선이 한 달 전부터 준비한 프러포즈를 하는 날이다. 반지는 이미 준비하여 주머니에 넣어 두었고, 깜짝 이벤트를 위해 친구들에게 한강 한적한 곳에 이벤트 장소를 꾸며달라고 말해두었다. 태선은 친구들이 한강에서 이벤트 장소를 준비하는 동안, 여자친구와 데이트를 할 것이다. 태선은 ENTJ답게 오늘의 데이트는 여자친구가 일이 끝나는 오후 5시부터 시작할 것이며, 친구들의 이벤트 준비는 오후 6시에 시작하여 8시 쯤 끝나는 것으로 철저히 계획했다. 태선은 5시에 여자친구를 만나 6시 쯤 이태원의 낭만 있는 오마카세에 들러 식사를 시작했다. 그리고 태선이 식사를 시작할 때 쯤, 태선은 친구들에게 이벤트 준비를 시작해달라고 여자친구 모르게 연락했다. 이벤트 준비가 제대로 되지 않으면 완벽을 추구하는 태선이 얼마나 면박을 줄 지 알기에, 친구들은

오늘 알아볼 개념은 실행 컨텍스트와 콜 스택이다. 실행 컨텍스트(Execution Context) 1-1. 전역 실행 컨텍스트(Global Execution context) 1-2. 함수 실행 컨텍스트(Function Execution context) 1-3. 실행 컨텍스트의 물리적 형태 콜 스택(Call Stack) 2-1. 콜 스택이란? 2-2. 예시 이러한 순서로 진행해보도록 하겠다. 1. 실행 컨텍스트(Execution Context) > 실행 컨텍스트는 실행 가능한 코드를 형상화하고 구분하는 추상적인 개념이다. -ECMAScript 쉽게 말해 코드가 실행되는 환경인 것으로 이해되는데, 대표적으로 두 가지 타입의 실행 컨텍스트가 있다고 한다. 1-1. 전역 실행 컨텍스트(Global Execution context) 자바스크립트 엔진은 코드가 실행되면 가장 먼저 전역 실행 컨텍스트를 생성한다.