스프링 부트와 AWS로 혼자 구현하는 웹 서비스 by 이동욱

[ 밑줄/연결 ]
 
스프링 부트는 서버에 톰캣과 같은 웹 애플리케이션 서버를 설치할 필요도 없고 오로지 Jar(실행 가능한 Java 패키징 파일) 하나만 있으면 서비스를 운영할 수 있습니다. 거추장스럽던 수많은 설정이 자동화되어 비즈니스 로직에만 집중할 수 있습니다.
 
웹 서비스를 구축하려면 크게 두 가지 지식이 필요합니다.
서비스의 기능을 담당할 애플리케이션 개발 지식과 개발한 애플리케이션이 구동될 서버 인프라 지식입니다.
 
버전 관리를 빼놓을 수 없는 요소입니다...
버전 관리는 SVN에서  Git으로 완전히 전환되어 가는 중이며, 실제로 대부분의 IT 서비스 회사는 깃을 통해 버전 관리를 하고 있습니다. 
깃의 원격 저장소 역할을 하는 서비스는 대표적으로 Github와 Gitlab이 있습니다.
 
테스트 코드 작성을 도와주는 프레임워크들이 있습니다.....xUnit
 
스프링 부트에서는 내장 WAS를 사용하는 것을 권장하고 있습니다....
언제 어디서나 같은 환경에서 스프링 부트를 배포할 수 있기 때문입니다.
 
자바 개발자들의 필수 라이브러리 롬복(Lombok)...
자바 개발할 때 자주 사용하는 코도 Getter, Setter, 기본생성자, toString 등을 이노테이션으로 자동 생성해 줍니다.
 
어떻게 하면 관계형 데이터베이스를 이용하는 프로젝트에서 객체지향 프로그래밍을 할 수 있을까 고민했습니다....
문제의 해결책은 JPA라는 자바 표준 ORM(Object  Relational Mappinig)기술을 만나게 됩니다...
ORM은 객체를 매핑하는 것이고, SQL  Mapper라는 쿼리를 매핑합니다.
 
아직 SI환경에서는 Sping & MyBatis를 많이 사용하지만, 쿠팡, 우아한 형제들, NHN 등 자사 서비스를 개발하는 곳에서는  SpringBoot & JPA를 전사 표준으로 사용하고 있습니다.
 
관계형 데이터베이스는 어떻게 데이터를 저장할지에 초점이 맞춰진 기술입니다.
반대로 객체지향 프로그래밍 언어는 메시지를 기반으로 기능과 속성을 한 곳에서 관리하는 기술입니다...
관계형 데이터베이스로 객체지향을 표현할 수 있을까요?
 

JPA는 인터페이스로서 자바 표준명세서입니다. 인터페이스인 JPA를 사용하기 위해서는 구현체가 필요합니다.
JPA  < --- Hibernate  <-- Spring Data JPA
 
한 단계 더 감싸놓은 Spring Data JPA가 등장한 이유는 크게 두가지가 있습니다.
ㅇ 구현체 교체의 용이성  : Hibernate 외에 다른 구현체로 쉽게 교체하기 위함
ㅇ 저장소 교체의 용이성 : 관계형 데이터베이스 외에 다른 저장소로 쉽게 교체하기 위함
 
JPA를 사용하면
ㅇ CRUD 쿼리를 직접 작성할 필요가 없음
ㅇ 부모-자식 관계 표현,  1:N 관계 표현, 상태와 행위를 한 곳에서 관리하는 등 객체지향 프로그래밍을 쉽게 할 수 있음
 
보통 ibatis나 Mybatis등에서 DAO라고 불리는 DB Layer접근자입니다.
JPA에서 Repository라고 부르며 인터페이스로 생성합니다. 단순히 인터페이스를 생선 후, JpaRepository<Entity 클래스, PK타입>을 상속하면 기본적인 CRUD 메소드가 자동으로 생성됩니다.
 

 
Entity 클래스는 데이터베이스와 맞닿은 핵심 클래스입니다. Entity 클래스를 기준으로 테이블이 생성되고, 스키마가 변경됩니다.
 
서버 탬플릿 엔진을 이용한 화면 생성은 서버에서 모든 Java 코드로 문자열을 만든 뒤 이 문자열을 HTML로 변환하여 브라우저에 전달합니다.
 

 
템플릿 엔진은 화면 역할에만 충실해야만 한다고 생각합니다. 너무 많은 기능을 제공하면 API와 템플릿 엔진, 자바스크립트가 서로 로직을 나눠 갖게 되어 유지보수가 굉장히 어렵습니다.
 
레이아웃 방식이란 공통 영역을 별도의 파일로 분리하여 필요한 곳에서 가져다 쓰는 방식을 이야기합니다.
 
24시간 365일 운영되는 서비스에서 배포 환경 구축은 필수 과제 중 하나입니다. 
여러 개발자의 코드가 실시간으로 병합되고, 테스트가 수행되는 환경, master 브랜치가 푸시되면 배포가 자동적으로 이루어지는 환경을 구축하지 않으면 실수할 여지가 너무나 많습니다.
 

 

[ 자평 ] good. 책을 읽은 목적을 달성하다. 
 
Big Data를 기반으로 4차산업혁명의 선도자, 조력자가 되겠다고 한창 떠든지가 엊그제 같다.
잠시 잦아 드나 싶더니 Digital Innovation, Digital Transformation이라는 간판을 새로 달고 나와 또 한창을 떠든다.
요즈음은 전부 또  AI를 기반으로,  초거대언어모델의 가지고 혁신을 이끈다고 떠들어 댄다.
 
김대중정부시절부터 IT업계 언저리에서 밥벌이를 하고 사는 문송으로서 나는 이런 소리들이 시끄러울 뿐이다. 
 
특히 이렇게 떠드는 분들은 대부분 우선 (정도는 다르겠지만) IT에 대한 경험과 지식이 깊지도 않은, 나이 많은 문송이지만, 권력은 가지고 있는 분들이다. 
그렇게 때문에 이들의 말에는 치명적인 단점 두 가지가 있다.
 
우선 Big Data든, AI든 기본적으로 데이터를 SW를 처리하여 서비스를 만들고, 운영하는 전체 매커니즘에 대한 기본적인 이해가 없다.
자기가 만들어 내고 싶은 것이 수류탄 정도인지? 원자탄 정도인지? 단지 불꽃놀이 폭죽 정도? 인지를 모른다. 
"아, 나는 잘 모르겠고"...."난 내가 주주들, 시장에 얘기할 수 있는 화려한 폭발력을 원해!" 만이 이들이 원하는 것이다. 시장에 “빵”하고 터져 나를 빛내고 싶은 것, 그것만을 원한다.
이들의 병적인 것은 솔직히 (나는 잘 모르겠고)라는 말도 못하거나, 안한다는 것이다.
권력자니까...권력자가 모른다는 말을 하기는 내 경험상 죽었다 깨어나도 들을 수 없는 단어였다.
 
두 번째 이들이 이 분야를 조력하거나, 이끌기에는 (이 분들이 열심히 경험하고, 배웠더라도) 이미 낡았고, (지식적으로) 늙었다.  생명은 늙으면 젊은 것들과의 속도에서 뒤쳐지기 마련이다. 그래서 우수한 기업은 CEO를 교체하는 것이다. 
하지만 마이크로서비스 시대에 몇 몇 우리 기업은 메인프레임 시대를 넘어, 천공카드 시대의 문송 리더로 교체하면서 새러운 시대를 이끌어 주기를 원한다.

생물학적으로 불가능하고, 물리학적으로 불가능라며, 경영학적으도 불가능한데, 정치적/권력적/인맥적/홍보적/사심적으로는 가능하다고 한다.
 
이러니 뭐가 나오 겠는가?

물속에 들어가서 아기마기 절로 생겨 숨을 쉬게 되는 진화가 자기 임기내에 생기리라고 기대하는 것과 같다. 
 
바보들은 바보들을 뽑고, 그 바보들은 또 바보같은 결정들을 한다.
그러면서도 미켈란제로 같은, 톨스토이 같은, 베토벤 같은 작품을 기대한다. 
 
바보는 아니지만, 바보같은 권력 집단에 들어 가지 못한 바보가 아닌 아랫 사람들이, 바보들에게 바보같은 지시를 받고, 괜찮은 결과물을 결국 바보가 이해할 수 있도록 바보를 위해 바보 같이 만들어, 바보들에게 보고하고, 바보들의 미소를 맞춰 줄 수 밖에 없는 것이 현실이다.
 
그래도, 바보로 남지 않고 싶은 욕심에 간만에 요즘 개발 트렌드를 따라가 보기 위해 들취본 책들 중 하나다. 
다시 정리를 하면서 세 번째 훑어 보는 것 같은데, 정말 잘 썼다. 
문송이고 개발자도 아니라 매커니즘을
이해할 목적으로만 뵜다

그 정도는 충분히 달성해 중 정도로 잘 썼다

2023년 10월 기준으로, 같은 목적으로 아래 책도 곧 훑어 볼 생각이다.