스프링부트 코딩 공작소

@Grab 애너테이션을 어디에 두어야 할까?
@Grab 애너테이션을 꼭 별도의 클래스에 둘 필요는 없다. ReadingListcontrollerL JdbcReadingList Repository에 애너테이션을 추가해도 여전히 마법 같은 기능을 선보일 것이다. 하지만 구조적인 면을 고려하여 필 요한 @Grab 애너테이션을 모두 붙인 별도의 빈 클래스를 정의하는 것이 좋다. 이렇게 하면 명시적으로 선언한 라이브 러리 의존성을 모두 한곳에서 볼 수 있다.


@Grab 애너테이션은 그루비의 Grape(GRoovy Adaptable Packaging Engine 또는 GRoory Advanced Packaging Engine) 특징에서 왔다. 요약하자면 Grape는 그루비 스크립트가 런타임에 메이븐이나 그레이들 같은 빌드 도구를 사용하지 않고 의존성 라이브러리를 다운로드할 수 있게 한다. Grape는 QGralb 애 너테이션에 기능적인 면을 제공할 뿐만 아니라 스프링 부트 CLI가 코드에서 추론한 의존성을 가져오는 데도 사용한다.
@Grab 애너테이션을 사용하는 것은 의존성을 나타내는 것만큼이나 간단다. 예를 들어 프로젝트 에 H2 데이터베이스를 추가한다고 하자. 다음 aGrab 애너테이션을 프로젝트의 그루비 스크립트 중 하나에 추가하면 된다.

@Grab(group="com.h2database", module="h2", version="1.4.192")

이런 방법으로 사용하면 group, module, version 속성은 의존성을 명시적으로 지정한다. 이 방 법 말고도 그레이들 빌드 명세에 의존성을 선언하는 방법처럼 콜론으로 구분된 형식으로 의존성 을 더 간결하게 선언할 수도 있다.

@Grab ("com.h2database:h2:1.4.192")
이 두 가지 방법은 aGrab 애너테이션을 사용하는 교과서적인 예다. 하지만 스프링 부트 CLI는 aGrab 애너테이션을 더 사용하기 쉽게 하려고 두 가지 방법으로 @Grab 애너테이션을 확장한다.
먼저 의존성 대부분은 버전을 명시하지 않아도 된다. 따라서 이 H2 데이터베이스 의존성 예는 다음 eGrab 애너테이션으로 선언할 수 있다.

@Grab ("com.h2database: h2")
의존성 버전은 현재 사용 중인 CLI 버전으로 결정된다. 예를 들어 스프링 부트 CLI 1.3.6 버전을 사용한다면 H2 의존성은 1.4.192 버전이 된다.

그레일즈의 가장 흥미로운 부분은 GORM (그레일즈 객체- 관계형 매핑) 일 것이다. GORM으로 영속화할 엔티티만 선언하면 데이터베이스 작업은 쉽다.

영속화:
"영속화"란 객체를 데이터베이스에 저장하여, 애플리케이션이 종료된 후에도 데이터가 유지될 수 있도록 하는 것을 의미합니다. 즉, 프로그램이 실행 중에 생성된 객체의 상태를 데이터베이스에 저장하고, 나중에 다시 해당 데이터를 불러올 수 있게 하는 과정입니다.

스프링부트 프로젝트에 GORM 사용하려면 GORM 의존성을 빌드에만 추가하면 된다. 메이븐 사용 시 <dependency>를 빌드에 추가하자

‹dependency>
‹groupId›org.grails‹/groupId> 
‹artifactId>gorm-hibernate4-spring-boot‹/artifactId>
‹version> 1.1.0. RELEASE‹/version> 
</dependency>

**스프링 부트(Spring Boot)**와 **그레일즈(Grails)**는 둘 다 자바 기반의 웹 애플리케이션 프레임워크로, 개발의 생산성을 높이고 복잡한 설정을 줄이는 데 도움을 줍니다. 그러나 두 프레임워크의 사용 빈도와 목적에는 차이가 있습니다.

1. 스프링 부트 (Spring Boot)

자주 쓰이는 이유:
현대 웹 개발 표준: 요즘 대부분의 자바 기반 웹 개발에서 스프링 부트가 기본으로 사용될 정도로 인기가 많습니다.
마이크로서비스 개발: 여러 작은 서비스로 시스템을 나누는 마이크로서비스 아키텍처에 적합합니다.
생태계: 방대한 플러그인, 라이브러리, 커뮤니티 지원.
간편한 설정: application.properties 같은 설정 파일을 이용하여 복잡한 XML 설정을 대체.
자동 구성: 많은 기본 설정이 자동으로 제공되어 빠르게 개발 시작 가능.

주요 사용 목적:
웹 애플리케이션 개발 (REST API, MVC 웹사이트 등)
데이터 처리 및 백엔드 서비스
마이크로서비스 구조의 애플리케이션
데이터베이스 연동과 CRUD 기능 구현
보안 (스프링 시큐리티)과 인증 기능
비동기 작업 및 메시징 시스템과의 통합


2. 그레일즈 (Grails)
요즘은 덜 쓰임:

그레일즈는 한때 Ruby on Rails의 자바 대안으로 인기를 끌었으나, 최근에는 사용 빈도가 줄었습니다. 이는 스프링 부트와 같은 프레임워크의 압도적인 성장과 생태계 부족 때문입니다.

왜 쓰이는지:
간단한 코드로 빠르게 애플리케이션 프로토타입을 개발할 수 있음.
스프링 기반: 내부적으로 스프링 프레임워크를 사용하므로 스프링의 모든 기능을 활용 가능.
Groovy 언어: 자바보다 더 간결하고 동적이며, 생산성 높은 코드를 작성 가능.

주요 사용 목적:
빠른 프로토타이핑과 MVP 개발
작은 규모의 프로젝트나 특정 팀의 내부 도구 개발
동적 웹 애플리케이션 개발
쉽게 설명하자면:
스프링 부트는 다양하고 큰 규모의 프로젝트에 적합하고, 많은 기업과 개발자가 사용하는 표준 도구입니다.

👉 "큰 회사나 스타트업에서 제대로 된 백엔드와 API를 구축하려고 할 때 사용."
그레일즈는 빠르고 간단하게 만들고 싶은 프로젝트에 적합했지만, 요즘은 많이 쓰이지 않음.
👉 "복잡한 설정 없이 빠르게 결과를 보고 싶을 때 (하지만 더 좋은 대안이 많아짐)."
요약:

스프링 부트는 현재 대세이고, 그레일즈는 예전에 대세였다가 사용 빈도가 줄어들고 있음.
둘 다 간편함을 목표로 하지만, 스프링 부트가 더 강력하고 범용적이기 때문에 요즘은 주로 스프링 부트를 선택.

액추에이터:
**액추에이터(Actuator)**는 스프링 부트 애플리케이션을 관리하고 모니터링하는 데 도움을 주는 기능이에요. 액추에이터는 애플리케이션의 상태, 메트릭, 로그, 환경 정보 등을 REST API 엔드포인트를 통해 제공해요.

주요 개념
REST 엔드포인트:
액추에이터가 제공하는 정보에 접근할 수 있는 URL 주소라고 생각하면 돼요. 예를 들어, /actuator/health로 요청을 보내면 애플리케이션이 "정상적으로 작동 중인지" 알려줍니다.
유용한 정보 제공:
액추에이터는 이런 데이터를 제공해요:

상태 정보(health): 서버가 살아 있는지 확인 가능
메트릭(metrics): CPU 사용량, 메모리 사용량, 요청 처리 시간 같은 성능 정보
환경 정보(env): 애플리케이션의 설정 정보 (예: 환경 변수, 프로파일)

원격 셸 접속:
이 문장은 액추에이터를 사용해서 외부에서 애플리케이션 정보를 확인하거나 상태를 점검할 수 있다는 뜻이에요.
예를 들어, 서버에 직접 들어가지 않아도, REST API를 사용해 필요한 정보를 받을 수 있는 거죠.

쉽게 이해하는 과정
만약 "이 서버 지금 잘 돌아가고 있는지?" 궁금하다면, 원격으로 /actuator/health를 호출하면 "OK" 같은 상태를 반환해요.
"CPU나 메모리 사용량은 어떤지?" 알고 싶다면 /actuator/metrics로 호출하면 그 데이터를 받을 수 있습니다.

결론: 액추에이터는 "관리 콘솔" 같은 역할을 하는데, 이걸 REST API 엔드포인트로 제공한다는 뜻이에요.

**액추에이터(Actuator)**는 별도의 프로그램을 다운로드하지 않아도 됩니다. 액추에이터는 스프링 부트(Spring Boot) 프레임워크의 일부로, 프로젝트에 의존성(dependency)을 추가하기만 하면 바로 사용할 수 있어요.

1. 의존성 추가
Maven 프로젝트라면 pom.xml 파일에 아래 내용을 추가하세요:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Gradle 프로젝트라면 build.gradle 파일에 아래 내용을 추가하세요:

implementation 'org.springframework.boot:spring-boot-starter-actuator'

애플리케이션 실행 후 확인
의존성을 추가하고 프로젝트를 실행하면 기본적으로 몇 가지 액추에이터 엔드포인트가 활성화됩니다.
예를 들어, http://localhost:8080/actuator/health를 브라우저나 Postman으로 호출하면 애플리케이션의 상태를 확인할 수 있어요.
설정을 변경하고 싶다면
application.properties 또는 application.yml 파일에서 설정을 조정할 수 있습니다. 예를 들어:

management.endpoints.web.exposure.include=health,info
management.endpoint.health.show-details=always

이 설정은 /actuator/health와 /actuator/info만 활성화하고, health 엔드포인트에서 자세한 정보를 보여줍니다.


취업 준비생 프로젝트에서 액추에이터를 사용하는지?
일반적으로 취업 준비생 프로젝트에서 반드시 액추에이터를 사용하는 건 아니에요. 하지만 액추에이터를 추가하면 프로젝트가 더 실무적이고 관리적인 면에서 완성도 있어 보이기 때문에 플러스 요인이 될 수 있어요.

액추에이터를 사용할 때 유용한 점:

모니터링 및 상태 점검:
서비스가 정상적으로 작동하는지, 리소스 상태는 어떤지 쉽게 확인 가능.
health로 서버 상태 점검
metrics로 성능 데이터를 확인
운영 환경에 가깝게 보이게 함:
실무에서는 서버 상태나 애플리케이션 성능을 확인하는 모니터링 도구(예: Prometheus, Grafana)를 자주 사용합니다. 액추에이터를 프로젝트에 추가하면, 실제 운영 환경과 유사한 설정을 보여줄 수 있어요.
프로젝트 발표에서 차별화:

"저희 프로젝트는 액추에이터를 사용해서 애플리케이션 상태를 모니터링할 수 있도록 설계했습니다"라고 하면, 관리 측면까지 고려했다는 점에서 가산점을 받을 가능성이 높아요.

취업 준비생에게 꼭 필요한 기능은?
액추에이터를 사용할지 말지는 프로젝트 목표와 방향에 따라 달라요. 다음 경우라면 추천합니다:

백엔드 서버 개발에 집중한 프로젝트:
REST API를 개발하고 서버 상태를 모니터링하거나 운영 효율성을 강조하고 싶다면 추가 가치가 있습니다.

DevOps나 클라우드 관련 프로젝트:
AWS, Azure 같은 환경에서 모니터링 연동을 시도할 경우, 액추에이터는 기본적으로 포함되는 경우가 많아요.


Liquibase로 데이터베이스 마이그레이션 정의
Flyway는 스프링 부트의 자동 구성 덕분에 간단하게 사용할 수 있다. 하지만 SQL 기반의 마이그 레이션 스크립트는 양날의 검이 될 수 있다. SQL 작업은 쉽고 일반적이지만 다른 플랫폼에서는 작동하지 않으며, 하나의 데이터베이스 플랫폼에서만 작동하는 마이그레이션 스크립트를 정의하 는 것은 위험하다.
Liquibase는 특정 플랫폼으로 제한되는 SOL 대신에 플랫폼에 상관없이 마이그레이션 스크립트를 작성할 수 있게 여러 형식을 지원한다. XML, YMI, JSON, SQL도 지원한다.
스프링 부트에 Liquilbase를 사용하려면 먼저 빌드에 의존성을 추가해야 한다. 그레이들 의존성은 다음과 같다.

Liquibase는 여전히 널리 사용되는 데이터베이스 마이그레이션 프레임워크입니다. 특히, 아래와 같은 이유로 많은 개발자와 조직에서 선호하고 있습니다:

1. 다중 플랫폼 지원
Liquibase는 XML, YAML, JSON, 그리고 SQL 형식으로 마이그레이션 스크립트를 작성할 수 있어 다양한 환경에서 유연하게 사용 가능합니다. 특히, 특정 데이터베이스 플랫폼에 종속되지 않는 형식으로 작성할 수 있어 유지보수가 용이합니다.

2. 스프링 부트와의 통합
Liquibase는 스프링 부트와 자연스럽게 통합되며, 의존성 추가만으로 쉽게 설정 및 실행이 가능합니다. 이는 최근의 마이크로서비스 및 CI/CD 파이프라인에서 큰 장점입니다.

3. 강력한 버전 관리
Liquibase는 변경 로그(change log)를 사용해 데이터베이스 상태를 관리합니다. 이를 통해 데이터베이스 변경 사항을 추적하고 롤백할 수 있어 안전한 배포가 가능합니다.

4. 오픈 소스와 커뮤니티 지원
Liquibase는 오픈 소스 프로젝트로서 활발한 커뮤니티 지원과 업데이트를 받고 있습니다. 이는 새로운 데이터베이스 기술 및 사용 사례에 빠르게 적응할 수 있음을 의미합니다.

5. 대안과 비교
물론 Flyway와 같은 다른 데이터베이스 마이그레이션 툴도 많이 사용됩니다. Flyway는 SQL 중심의 간단한 접근 방식을 선호하는 팀에게 인기가 있습니다. Liquibase는 다양한 형식 지원과 XML 기반 설정 등으로 더 복잡한 요구사항에 적합합니다.

결론적으로, Liquibase는 특히 복잡한 데이터베이스 환경에서 강력한 도구로 여전히 많이 사용됩니다. 다만, 프로젝트의 요구사항과 팀의 선호도에 따라 Flyway와 같은 다른 옵션도 고려해볼 만합니다.


Liquibase는 데이터베이스 마이그레이션 관리를 위한 오픈 소스 도구입니다. 간단히 말해, 데이터베이스 구조를 변경할 때 발생하는 여러 변경 사항(예: 테이블 추가, 컬럼 변경, 인덱스 생성 등)을 추적하고, 관리할 수 있도록 돕는 도구입니다.

Liquibase의 주요 기능
버전 관리:
Liquibase는 데이터베이스 스키마 변경 사항을 버전 관리할 수 있게 해줍니다. 이를 통해 팀 간에 데이터베이스 구조를 공유하고, 변경 사항을 쉽게 추적할 수 있습니다.
예를 들어, 개발자들이 여러 명일 때 각자가 데이터베이스 변경 사항을 정의하고, 이를 쉽게 병합하거나 롤백할 수 있습니다.
다양한 형식 지원:
Liquibase는 XML, YAML, JSON, SQL 등의 형식으로 마이그레이션 스크립트를 작성할 수 있습니다. 이를 통해 개발자는 자신이 편한 형식으로 마이그레이션을 정의할 수 있습니다.
SQL 기반의 마이그레이션 스크립트도 작성할 수 있지만, XML이나 YAML을 사용하면 데이터베이스 종속적인 코드 없이 다양한 DB에서 동작할 수 있습니다.
자동화:
Liquibase는 CI/CD 파이프라인에 통합할 수 있어, 배포 시 자동으로 데이터베이스 마이그레이션을 실행할 수 있습니다. 이를 통해 수동으로 SQL을 실행하거나 데이터베이스 변경을 관리하는 번거로움을 줄여줍니다.
롤백 지원:
Liquibase는 이전의 변경 사항을 롤백할 수 있는 기능도 제공합니다. 예를 들어, 잘못된 마이그레이션을 실행했을 경우, Liquibase를 사용해 데이터베이스를 이전 상태로 되돌릴 수 있습니다.
SQL을 손쉽게 쓰게 해주는 도구인가?
Liquibase는 단순히 SQL을 손쉽게 작성하게 해주는 도구는 아닙니다. 오히려 SQL을 포함한 다양한 형식으로 데이터베이스 변경 사항을 관리하고, 이를 버전 관리 및 자동화하는 도구입니다. SQL은 Liquibase의 한 가지 지원 형식에 불과하고, XML이나 YAML과 같은 형식으로도 마이그레이션을 정의할 수 있습니다.

Liquibase와 SQL의 차이점
SQL: 데이터베이스에 특정 작업을 직접 수행하는 명령어들입니다. 예를 들어, 테이블을 추가하는 CREATE TABLE 문 등.
Liquibase: SQL뿐만 아니라 다양한 형식으로 마이그레이션을 정의하고, 그 변경 사항을 추적하고 롤백하는 기능을 제공하는 도구입니다.
따라서 Liquibase는 SQL을 작성하는 것뿐만 아니라, 데이터베이스 마이그레이션의 관리, 버전 추적, 자동화, 롤백 등을 쉽게 해주는 도구입니다.

---

마이그레이션(Migration)은 단순히 데이터를 옮기는 것뿐만 아니라 데이터베이스 구조의 변경을 관리하는 개념입니다. 즉, 데이터베이스 스키마 변경을 추적하고 적용하는 작업을 포함합니다.

마이그레이션의 의미
데이터 마이그레이션: 한 시스템에서 다른 시스템으로 데이터를 이동하는 작업입니다. 예를 들어, 한 데이터베이스에서 다른 데이터베이스로 데이터를 옮기는 것처럼 데이터를 실제로 이동하는 과정입니다.

데이터베이스 마이그레이션 (Liquibase의 경우): 데이터베이스의 구조나 스키마를 변경하는 작업입니다. 예를 들어, 새로운 테이블을 추가하거나, 컬럼을 수정하거나, 인덱스를 생성하는 등의 스키마 변경을 포함합니다.

Liquibase에서의 마이그레이션
Liquibase는 주로 데이터베이스 구조의 변경을 관리합니다. 즉, 데이터베이스 스키마에 대한 변경 사항을 기록하고, 이를 버전 관리하는 도구입니다. 이런 변경 사항은 SQL 스크립트로 정의되거나 XML, YAML, JSON 형식으로 작성되어, 데이터베이스 구조를 일관성 있게 변경할 수 있도록 도와줍니다.

예를 들어, 데이터베이스 스키마에 users라는 테이블을 추가하는 작업이 있을 수 있습니다. 이 작업은 마이그레이션의 일환으로, 특정 시점에 데이터베이스를 어떻게 변경할지 정의하는 것입니다.

정리하면:
데이터 마이그레이션은 데이터를 한 위치에서 다른 위치로 옮기는 작업입니다.
데이터베이스 마이그레이션은 데이터베이스의 구조(스키마)를 변경하는 작업입니다. Liquibase는 이런 변경을 추적하고 관리하는 도구입니다.


클라우드 파운드리(Cloud Foundry)는 여전히 일부 기업과 개발팀에서 사용되고 있지만, 요즘은 Kubernetes와 같은 컨테이너 오케스트레이션 툴이 더 인기를 끌고 있습니다. 특히 클라우드 네이티브 애플리케이션을 구축하는 데 Kubernetes가 많이 사용되며, Cloud Foundry는 상대적으로 덜 주목받고 있습니다. 그럼에도 불구하고 Cloud Foundry는 여전히 여러 조직에서 PaaS(Platform as a Service) 솔루션으로 사용되고 있습니다.