algml0703

내부 네트워크를 이용해서 외부 단말기 접속 방법

algml0703 — Tue, 11 Feb 2025 19:58:27 +0900

> ifconfig | grep "inet " | grep -v 127.0.0.1

맥에서 위의 명령어 입력 시 아래와 같은 결과를 출력하여주는데, 해당 명령어는 현재 컴퓨터의 네트워크 인터페이스에서 루프백주소(Loopback) 즉 127.0.0.1을 제외한 IPv4주소를 출력하여 주는 명령어이다.

ifconfig -> 현재 네트워크 인터페이스 정보를 출력하여 주는 명령어 ifconfig(=interface configuration)

grep "inet " -> ifconfig를 통한 결과에서 inet 문자열을 포함하는 줄들을 찾는 명령어

grep -v 127.0.0.1 -> 위에서 찾은 줄들에서 127.0.0.1이 포함된 줄을 제외하고 출력하여 주는 명령어

inet 123.45.6.7 netmask 0xffffff00 broadcast 123.45.6.255

이때 예를 들어 내 노트북 컴퓨터에서 로컬호스트로 서버를 실행 시킨 후에 같은 네트워크를(ex 와이파이 or 유선 랜/이더넷)를 사용중인 휴대폰이나 다른 컴퓨터를 통해 123.45.6.7와 서버를 실행 시킨 포트에 접속하면 내 노트북에서 실행되는 서버에 접속이 가능하다. (방화벽으로 막힌 경우를 제외...)

위에서 출력된 결과를 확인해보면

inet 123.45.6.7 -> 현재 네트워크 인터페이스의 IPv4 주소, 즉 현재 내 컴퓨터가 사용하는 네트워크의 주소

netmask 0xffffff00 -> 16진수로 표현된 서브넷 마스크 (255.255.255.0)

broadcase 123.45.6.255 -> 브로드캐스트 주소

TODO: 더 자세히 알아볼 내용
* 이더넷
* 네트워크 인터페이스
컴퓨터와 네트워크를 연결하는 장치를 의미
- 물리적 네트워크 인터페이스
- 가상 네트워크 인터페이스
* 루프백(Loopback) 주소
~ 개발할 때 자기 자신의 서비스(예: 로컬 DB, API 서버 등)와 통신하는 용도로 활용
* 서브넷 마스크
* IPv4 주소
컴퓨터나 장치가 네트워크에서 식별되는 고유한 숫자 주소로, 같은 네트워크에 있는 다른 장치들과 통신하기 위해 사용되는 주소이다.

[ docker ] - docker에서 oracle 데이터베이스 설치 실행 (feat. mac m1)

algml0703 — Sun, 12 Jan 2025 18:43:33 +0900

docker에서 oracle 데이터베이스 설치 실행 (feat. mac m1)

오라클 데이터베이스의 경우 공식적으로는 macOS를 지원하지 않아서 mac에서 로컬로 오라클 데이터베이스를 사용하기 위해서는 도커를 사용하거나, Virtual Box나 VMware같은 가상화 소프트웨어를 이용해야 한다. 그 중에서는 나는 도커를 사용하여 오라클 데이터베이스를 로컬에서 실행해보았다. 근데 기존에 도커에서 그냥 단순히 이미지를 pull 받아서 해당 이미지를 run하여 컨테이너로 만들어 실행시키는 방식이 나의 경우 무엇이 문제인지 정확히 모르겠지만 계속 에러가 났다. docker를 삭제했다가 재설치 하는 식으로도 여러 번 해보고, 오라클 이미지를 각기 다른 이미지를 받아 실행시켜 보았는데도 실행하면 계속 컨테이너가 꺼졌다. 어찌 어찌 해결은 했는데 추후에 혹시 또 노트북 바꾸거나 새로 세팅해야 하는 경우를 대비하여 글로 작성하였다. (아래의 방식은 직접 오라클 도커 이미지를 빌드한 후 직접 빌드한 이미지를 컨테이너로 실행시킨 것이다.)

** 맥에서 직접 오라클을 실행시키는 것은 안 되고, 도커로 이미지를 빌드해서 오라클을 실행시키는 것은 가능한 이유?

1. git에서 직접 oracle docker-images 다운 받기

> git clone https://github.com/oracle/docker-images

(https://github.com/oracle/docker-images)

위치는 바탕화면에 docker-images 폴더 하위에 프로젝트를 받았다. 즉 프로젝트가 desktop/docker-images/docker-images로 존재하는데 나는 프로젝트 폴더명을 oracle로 변경하여서 desktop/docker-images/oracle 구조가 되었다.

2. oracle 실행 zip 다운로드 (LINUX.X64_191900_db_home.zip)

https://www.oracle.com/database/technologies/oracle19c-linux-arm64-downloads.html

위의 링크를 통해 오라클 데이터베이스를 직접 다운로드 받고, 해당 zip파일(LINUX.X64_191900_db_home.zip)은 desktop/docker-images/oracle/OracleDatabase/SingleInstance/dockerfiles/19.3.0 폴더의 하위에 위치시킨다. (이때 주의

점은 압축파일을 해제해서 위치시키는게 아니라 zip 파일 그대로 위치시키는 것이다.)

3. docker image build

> ./buildContainerImage.sh -e -v 19.3.0 -t oracle19c

** 위 명령어는 도커 이미지 빌드 시 oracle19c 라는 도커 이미지명을 사용하고, 버전은 19.3.0임

desktop/docker-images/oracle/OracleDatabase/SingleInstance/dockerfiles 폴더 하위에 buildContainerImage.sh란 파일이 존재하는데 도커 이미지로 빌드하기 위해 위의 명령어로 해당 파일을 실행시킨다. 이때 명령어 실행하는 터미널 위치는 desktop/docker-images/oracle/OracleDatabase/SingleInstance/dockerfiles 이어야 한다. 해당 위치가 아닌 경우에는 /desktop/docker-images/oracle/OracleDatabase/SingleInstance/dockerfiles/buildContainerImage.sh -e -v 19.3.0 -t oracle19c 이와 같이 경로를 모두 명시해주어야 한다.

** 이때에 주의점은 두번째 단계에서 다운로드하였던 설치 파일이 해당 버전의 디렉토리 안에 존재해야 한다. 즉 dockerfiles/19.3.0 폴더 하위에 오라클 설치 파일(=LINUX.X64_191900_db_home.zip)이 존재해야 한다.

도커 이미지 빌드가 완료되면 최종적으로 build completed in ~ 이런 식으로 나온다.

이후 아래 명령어 실행 시 oracle19c 라는 이름의 도커 이미지가 생성된 것을 확인할 수 있다.

> docker images

4. 도커 이미지를 통해 컨테이너 생성 및 실행

> mkdir -p ~/Desktop/dockerdatas/oracledata/oradata

컨테이너를 종료하거나 재시작하더라고 데이터가 손실되지 않도록 컨테이너 생성 시 볼륨 마운트 설정해줄 폴더 생성하여주는 명령어

> sudo chown -R 54321:54321 ~/Desktop/dockerdatas/oracledata/oradata

chown은 Change Ownership의 약자로 파일과 디렉토리의 소유자와 소유그룹(첫 번째가 소유자, 두 번째가 소유 그룹)을 변경해주기 위해 사용하는 명령어이다. 더불어 -R은 해당 디렉토리는 물론 하위의 모든 파일 및 디렉토리에도 적용함을 의미한다. 즉 해당 디렉토리에 대한 소유자와 소유그룹의 ID를 54321로 변경해준 것인데, 이는 도커 컨테이너 내부의 프로세스가 특정 파일에 접근할 때 사용자 ID와 그룹 ID 를 필요로 하는데 기본적으로 Oracle 도커 이미지의 경우에는 데이터 파일의 소유자 ID와 소유 그룹 ID를 54321로 갖고 있도록 하고 있다. 때문에 데이터 볼륨을 마운트 설정해주기 위해서는 해당 디렉토리가 컨테이너에서 사용하는 사용자ID/그룹ID와 일치하도록 설정해준 것이다.

> Sudo chmod -R 777 ~/Desktop/dockerdatas/oracledata/oradata

chmod는 change mode의 약자로 디렉토리나 파일의 권한을 변경하여 주는 명령어이다. 컨테이너가 해당 파일에 대해 읽기/쓰기와 같은 작업을 원활하게 수행할 수 있도록 해당 디렉토리에 대해 모든 권한도 허용하여 주었다.

- 첫 번째 숫자 : 소유자 권한
- 두 번째 숫자 : 소유 그룹 권한
- 세 번째 숫자 : 기타 사용자 권한
4 (읽기) + 2 (쓰기) + 1 (실행) = 7
즉 모든 사용자에게 읽기, 쓰기, 실행의 권한을 부여함

> docker run --name local-oracle -d -p 1521:1521 -e ORACLE_SID=ORCLDB -e ORACLE_PWD=1234 -e ORACLE_CHARACTERSET=AL32UTF8 -v /Users/mihee/desktop/dockerdatas/oracledata/oradata:/opt/oracle/oradata oracle19c:latest

docker run	컨테이너를 생성하고 실행
-d	컨테이너를 백그라운드로 실행, 해당 옵션을 주지 않는 경우, 컨테이너가 생성 실행되는 동안 터미널에서 다른 작업이 불가능하다.
--name [컨테이너명]	해당 컨테이너 생성 또는 실행 시 컨테이너명
-p [호스트포트번호]:[컨테이너내부포트번호]	호스트(=로컬컴퓨터)의 포트와 컨테이너 내부의 포트를 매핑해줌 ex) -p 1521:1521 로컬컴퓨터의 1521포트로 접속 시 컨테이너 1521 포트로 접속 가능
-e [환경변수키]=[환경변수값]	환경변수 설정해준 것 ex) -e ORACLE_SID=ORCLDB ORACLE_SID는 오라클 데이터베이스의 식별자로 즉 ORCLDB를 데이터베이스명으로 사용 ex) -e ORACLE_PWD=1234 오라클 관리자 계정(SYS, SYSTEM)으로 접속 시 비밀번호 ex) -e ORACLE_CHARACTERSET=AL32UTF8 데이터베이스 문자 설정, AL32UTF8
-v [호스트디렉토리]:[컨테이너디렉토리]	볼륨마운트 설정을 위한 옵션으로, 컨테이너가 종료되어도 데이터를 영구적으로 보존할 수 있도록 로컬에 저장해두는 공간을 설정해두는 것이다. 즉 컨테이너 내부적으로 오라클 데이터 파일이 저장되는 디렉토리를 호스트의 디렉토리로 매핑하여 준 것이다.

> docker exec -it local-oracle sqlplus sys as sysdba

local-oracle 컨테이너 내부의 터미널에 접속하여 관리자 계정으로 sqlplus 실행

이후 아래와 같이 비밀번호 입력

> select instance_name, status from v$instance; 쿼리를 통해 데이터베이스 상태 확인

+ DBeaver 접속 시

[ DATABASE ] - Oracle에서 사용자 생성 및 테이블스페이스 생성

algml0703 — Tue, 7 Jan 2025 06:18:26 +0900

사용자 생성 및 테이블스페이스(TableSpace) 생성

1. tabalespace 생성

// -> 기본 tablespace 생성 oracle 쿼리
CREATE TABLESPACE [테이블스페이스명] 
DATAFILE [파일경로] 
[옵션]

ex)
CREATE TABLESPACE myts 
DATAFILE 'C:\oracle\oradata\myts.dbf' 
SIZE 100M 
AUTOEXTEND ON NEXT 5M MAXSIZE 500M;

// tablespace 변경 시
ALTER DATABASE DATAFILE [경로] [변경사항]

ex) 
// tablespace의 데이터파일 크기 200MB로 확장
ALTER DATABASE DATAFILE 'C:\oracle\oradata\myts.dbf' RESIZE 200M;
// 해당 테이블스페이스 읽기 전용으로 상태 변경
ALTER TABLESPACE myts READ ONLY;

// -> tablespace 삭제 시 쿼리 
// 해당 tablespace는 물론 관련한 데이터 및 파일을 삭제한다.
DROP TABLESPACE myts INCLUDING CONTENTS AND DATAFILES;

Tablespace

oracle에서 데이터베이스 저장 공간을 논리적으로 나뉜 단위를 의미한다. (즉 oracle에서 모든 데이터는 tablespace에 저장되어 관리된다.)
tablespace는 물리적으로는 일종의 파일 단위로 존재한다.
백업이나 복구 등의 작업 단위가 된다.
tablespace는 기본적으로는 하나의 파일로 생성되지만, 하나의 tablespace가 여러 개의 데이터 파일로 구성되도록 할 수 있다.
데이터 파일의 크기 설정을 통해 tablespace의 크기를 구성할 수 있다.
성능을 위해 인덱스 등과 같은 부분만을 별도의 테이블스페이스를 통해 저장 관리하거나 대규모 데이터를 가진 테이블을 파티셔닝하여 다른 테이블스페이스에 저장 관리하여 접근 속도와 성능을 향상시킬 수 있다.
사용자마다 특정 tablespace를 할당함으로써 데이터 접근 권한을 제어할 수 있다.

oralce은 설치 시에 기본적으로 (1) SYSTEM Tablespace (2) SYSAUX Tablespace (3) UNDO Tablespace (4) TEMP Tablespace (5) USERS Tablespace 를 가지고 있다.

oracle 설치 시 기본으로 생성되는 tablespace

(1) SYSTEM Tablespace

oracle 데이터베이스의 주요한 메타데이터를 관리하는 테이블스페이스로, SYS, SYSTEM 스키마는 물론 초기화 정보 및 주요한 시스템 테이블들이 저장된다.

(2) SYSAUX Tablespace

SYSTEM 테이블스페이는를 보조하는 역할을 하며, 성능, 백업, 복구 등의 기능과 관련한 데이터를 포함하는 테이블스페이스이다.

(3) UNDO Tablespace

트랜잭션 롤백 및 데이터 복구를 위한 정보를 저장하는 테이블 스페이스이다.

(4) TEMP Tablespace

정렬 및 임시 작업 시에 데이터를 저장하는 테이블 스페이스이다.

(5) USERS Tablespace

일반 사용자 데이터를 저장 관리하는 테이블 스페이스이다.

CREATE TABLESPACE myts DATAFILE 'C:\oracle\oradata\myts.dbf' SIZE 100M AUTOEXTEND ON NEXT 5M MAXSIZE 500M; 쿼리는 myts라는 tablespace을 생성하고 해당 테이블스페이스에 저장되는 데이터는 C:\oracle\oradata 폴더 하위에 myts.dbf 라는 데이터 파일에 저장, 해당 데이터 파일의 크기는 100MB로 설정, AUTOEXTEND ON 즉 데이터 파일의 자동 확장을 허용하여, 데이터 증가로 공간이 부족해지면 지정된 크기만큼 데이터 파일이 자동으로 확장되도록 옵션을 설정. NEXT 5M은 데이터 파일이 확장될 때 증가하는 크기의 단위이다. 단 데이터 파일 크기의 무제한 확장을 막기 위해 해당 데이터 파일의 최대 크기는 500MB가 넘지 않도록 MAXSIZE 500M;설정한 것이다.

** oracle에서 스키마나 사용자 생성 시 에러 발생하는 경우 -> C##을 붙여서 사용해야 하는 경우가 있는데 이때 ALTER SESSION SET "_ORACLE_SCRIPT"=true; 쿼리를 통해 스키마나 사용자명 앞에 C##을 붙이지 않고도 생성할 수 있다. 현재 세션에서 _ORACLE_SCRIPT를 true로 설정한다는 것은 현 세션에서 생성하는 스키마를 시스템 정의 스키마처럼 생성되도록 해주는 쿼리이다.

C##은 오라클 데이터베이스에서 공통사용자(Common User)와 로컬 사용자(Local User)를 구분하기 위해 사용하는 접두사로, 공통사용자인 경우에는 사용자명 앞에 C##을 붙여야 사용자 생성이 가능하다. 공통사용자는 CDB와 PDB 모두에서 유효하다.

2. 사용자 생성

// -> 기본 사용자 생성
CREATE USER [사용자명] IDENTIFIED BY [비밀번호];

ex) 
create user ora_user identified by 1234;

---

// -> tablespace 설정하여 사용자 생성
CREATE USER [사용자명] IDENTIFIED BY [비밀번호]

DEFAULT TABLESPACE [테이블스페이스명]

TEMPORARY TABLESPACE [임시테이블스페이스명];

ex) 
create user ora_user identified by 1234

default tablespace myts

temporary tablespace temp;

Oracle에서는 사용자와 스키마가 동일하다. 즉 사용자를 생성하면 해당 사용자가 소유하는 스키마가 자동으로 생성되게 된다. 하나의 데이터베이스 안에는 여러 개의 스키마가 존재할 수 있다.

아래의 두 번째 쿼리의 경우 사용자를 생성하는 동시에 해당 사용자가 사용할 기본 테이블스페이스를 myts로 설정한 것이다.

** 스키마 : Oracle에서 스키마는 특정 데이터베이스 사용자에 의해 소유되는 데이터베이스 객체의 집합을 의미하며, 여기에는 테이블, 뷰, 인덱스, 시퀀스, 프로시저, 트리거 등을 포함한다.

위의 쿼리 실행 시 데이터베이스 툴인 dbeaver를 통해 확인해 보면 아래와 같이 ora_user 라는 스키마가 생성된 것을 확인할 수 있으며, 해당 스키마의 사용자명은 ora_user, 비밀번호는 1234, 스키마가 저장되는 tablespace는 myts를 가지게 된다.

3. 권한 부여

GRANT DBA TO [사용자명];

ex) grant dba to ora_user;

[설정] - 환경변수와 사용자 변수 ?

algml0703 — Mon, 6 Jan 2025 21:55:57 +0900

환경변수와 사용자변수

새로운 프로그램을 설치해주는 경우 이에 맞추어 환경 변수와 사용자 변수 설정을 추가해주어야 하는 경우가 있다. 예를 들면 자바를 설치 시 JAVA_HOME 이라는 환경변수를 함께 추가해주는 경우가 그러하다. 그 동안 그냥 구글에 검색 시 그냥 블로그에서 시키는 대로 생각없이 따라하면서 설치하고 환경변수를 추가해주었는데 왜 해주는 것인지 한 번 알아보았다.

환경변수 (System Variables)

환경변수는 시스템 전체에 적용되는 것으로, 모든 사용자 계정과 프로그램에 환경변수로 설정된 것을 참조할 수 있다. 기본적인 시스템 설정과 관련한 경로, 파일 위치, 구성 정보 등을 저장한다. 일반적으로 운영체제 및 모든 사용자에게 공통적으로 적용되어야 할 필요가 있는 경우에 환경변수로 설정하여 준다.

사용자변수 (User Variables)

사용자 변수는 특정 사용자 계정에서만 사용하려는 경우에 적용하는 설정이다. 개별 사용자의 환경 설정이나 프로그램 실행에 필요한 정보를 설정해두는 것이다.

기본적으로 사용자 변수가 환경변수보다 우선 순위가 높다. 때문에 사용자 계정의 Path 변수에 특정 경로를 추가하면 이는 시스템 변수의 Path 보다 먼저 참조된다.

** Path: 실행 파일 등에 대한 경로를 설정하여 어느 위치에서든 해당 실행 파일을 실행할 수 있도록 설정하여 주는 파일 경로이다.

Window 환경에서는 설정 창에서 환경 변수를 검색하여 환경 변수나 사용자 변수에 대한 설정을 해주는 것이 가능하며, Mac 을 사용하는 경우에는 시스템 변수의 경우 /etc/paths 파일에, 사용자 변수의 경우 ~/.bash_profile을 통해 확인 또는 설정할 수 있다. Mac의 경우에는 셸 세션에서 직접 설정된 변수의 우선 순위가 가장 높고, 그 다음으로 ~/.zshrc 나 ~/.bash_profile을 통해 설정된 사용자 변수, 그 다음으로 etc/paths에 설정된 환경변수 순으로 우선 순위를 가진다.

현재 셸 세션에서 설정된 변수란 터미널을 실행시키고, export JAVA_HOME=[경로] 와 같이 해당 세션에서 명령어를 통해 바로 설정한 변수를 의미한다. 아래를 이미지를 보면 처음에 JAVA_HOME 확인 시에는 사용자 변수로 설정되어 있는 값을 가져오지만, export JAVA_HOME = [새로운경로] 를 설정해준 후 JAVA_HOME을 확인한 이후에는 새롭게 설정한 JAVA_HOME의 값이 나오는 것을 확인할 수 있다. 하지만 이는 해당 창의 터미널에서만 유효하면 새로운 터미널 창을 실행시켜 JAVA_HOME을 확인해보면 처음과 같이 사용자 변수로 설정되어 있는 값을 가져온다.

** 해당 세션에서 적용되는 변수 설정해주는 명령어

export var=[경로]
ex) JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home"

// 해당 세션 뿐만 아니라 사용자변수 설정에 영구적으로 반영하려는 경우는 아래의 명령어
source ~/.bash_profile

** Path에 설정되어 있는 경로 확인하는 명령어

echo $PATH | tr ':' '\n'

** 셸 (Shell) : 사용자와 컴퓨터 운영체제 간의 인터페이스를 제공하는 것으로, 명령어를 처리하는 프로그램이라 할 수 있다. 사용자가 명령어를 입력하면 Shell이 해당 명령어를 운영체제에 전달하고 실행 결과를 사용자에게 반환하여 준다. 그 중에서도 Bash와 Zsh는 Mac이나 Linux와 같은 유닉스 계열 운영체제에서 주로 사용되는 셸의 종류이다. 터미널에서 echo $SHELL 실행 시 /bin/bash가 나오는 경우, Bash를, /bin/zsh가 나오는 경우 Zsh를 사용하고 있는 것임을 알 수 있다.

** JAVA_HOME 등과 같이 특정 변수명으로 설정해주는 것과, Path에 경로를 추가해주는 것의 차이?

우선 JAVA_HOME과 같이 변수에 경로를 설정해 준 것은 Maven이나, Gradle 과 같은 툴 실행 시 사용될 JDK의 경로를 설정해준 것이라 할 수 있다. ex) JAVA_HOME : C:\Program Files\jdk-21.0.5

Path에 추가해주는 것들은 CLI를 통해 프로그램 실행 시 전역에서 해당 명령어가 실행 가능하도록 해주는 설정이다. 때문에 일반적으로 실행 스크립트가 있는 bin 폴더를 기준으로 Path를 추가해준다. ex) %JAVA_HOME%\bin

-- %JAVA_HOME%과 같이 %[변수명]% 을 통해 기존에 변수에 설정된 값을 가져올 수 있다. 즉 %JAVA_HOME%\bin 은 C:\Program Files\jdk-21.0.5\bin 과 같다.

[ 설정 ] - 플러그인 디펜던시 차이?

algml0703 — Sat, 28 Dec 2024 00:03:32 +0900

플러그인(plugin)과 디펜던시(dependency)의 차이?

플러그인(Plugin)?

플러그인은 gradle을 통한 빌드 시에 기능이나 새로운 작업을 추가해주는 역할을 한다. 주로 빌드, 테스트, 배포와 같은 빌드 작업을 정의하고 설정을 자동화한다.

ex) build.gradle

id("java")
compileJava, test, jar 등과 같은 작업을 자동으로 수행하도록 해주는 플러그인이다. (java의 경우 gradle 자체 내장 플러그인으로 버전을 명시해주지 않아도 된다. 외부 플러그인의 경우에는 반드시 버전을 명시하여 주어야 한다. )
id("org.springframework.boot")
bootRun, bootJar를 등의 작업을 자동화해주어, 최소한의 설정만으로 스프링 어플리케이션을 실행시킬 수 있도록 돕는 플러그인이다.
id("io.spring.dependency-management")
디펜던시를 관리하여 주는 플러그인이다.

* jar란

Java 애플리케이션이나 라이브러리를 JAR(Java Archive) 파일로 패키징하는 작업을 의미한다. 즉 Java 클래스 파일과 리소스 파일을 포함하는 압축 형식의 파일이다. 기본적으로 src/main/java 디렉토리 하위에 있는 java 소스 파일을 컴파일하여 .class 파일로, src/main/resource 디렉토리 하위의 파일들에 대해 jar로 만들어 build/libs에 생성한다. jar를 이용함으로써 Java 어플리케이션을 배포하거나, 라이브러리로써 활용이 가능하다. 즉 jar는 Java 환경에서 특별히 동작하도록 설계된 구조와 메타데이터를 포함하는 일종의 압축 파일이라 할 수 있다.

* java -jar [jar 파일]

해당 jar로 구성된 애플리케이션을 실행시켜 준다. ex )java -jar ./board/build/libs/board-0.0.1-SNAPSHOT.jar

** gradle은 java 뿐 아니라 Kotlin, Groovy 등의 다양한 프로젝트 언어를 지원한다. 때문에 플러그인 설정을 통해 다양한 언어를 지원할 수 있게 된다. 예를 들어 코틀린을 사용하는 경우 플러그인으로 id("org.jetbrains.kotlin.jvm")를 추가하면 코틀린 적용 가능하다.

# https://plugins.gradle.org/

디펜던시(Dependency)?

프로젝트에서 사용하는 외부 라이브러리를 의미한다. 아래와 같이 디펜던시를 추가하면 원격저장소에서 라이브러리를 다운받아와 준다. 플러그인이 빌드, 테스트, 배포 등 gradle 자체의 프로세스와 기능을 자동화하거나 확장해주는 역할이라면, 디펜던시의 경우 해당 프로젝트 내에서 사용되는 실제 기능이나 코드를 제공하여 주는 코드 모음이라 할 수 있다.

# https://yooverd.tistory.com/19 (라이브러리 버전 관리 관련 설명 블로그)

디펜던시를 추가할 때는 아래와 같이 implementation, testImplementation, runtimeOnly 등이 있다.

implementation
컴파일과 런타임 모두에 사용되는 의존성 라이브러리 추가 시 사용, implementation으로 추가한 디펜던시의 경우 해당 모듈에서만 적용되고, 상위 모듈로 전파되지 않는다.
api
implementation과 유사하게 컴파일과 런타임 모두에 사용되는 의존성 라이브러리 추가 시 사용되지만, 차이점은 api를 통해 추가한 디펜던시의 경우 해당 모듈 뿐 아니라 상위 모듈에도 전파되어 사용 가능하다.
testImplementation
테스트 실행 시 사용되는 의존성 라이브러리 추가 시
compileOnly
컴파일 시에만 필요한 의존성 라이브러리 추가 시
runtimeOnly
JDBC나 로그 구현체 관련한 디펜던시 등 런타임 시에만 필요한 의존성 라이브러리 추가 시
AnnotationProcessor
Lombok과 같이 컴파일 시에 어노테이션 관련한 의존성 라이브러리 추가 시 (컴파일 시에 Lombok을 사용해 코드 생성, 런타임시에는 필요하지 않다.)

build.gradle 설정 관련

하나 이상의 모듈로 구성된 프로젝트 구조를 갖춘 경우 기본적으로 루트 프로젝트와 서브프로젝트라는 개념이 존재한다. 여러 모듈이 모인 가장 최상단이 루트 프로젝트가 되고, 그 안의 각각의 모듈이 하나의 서브프로젝트가 된다. 예를들어 아래의 구조를 보면 market이 루트 프로젝트가 되고, 그 안의 market-boot, market-controller, market-domain, market-service 가 각각의 서브 프로젝트가 된다.

[ plugins ]

이때에 build.gradle 설정 시에는 공통적인 플러그인 설정은 plugins 스코프 안에, 모든 서브 프로젝트에 적용하려는 플러그인의 경우 subprojects 스코프 안에 넣어준다. 또 한 가지 다른 점은 플러그인 적용 시에 subprojects에서 적용되는 플러그인은 apply plugin: '[플러그인]' 이와 같은 식으로 적용된다. 아래의 코드를 보면 디펜던시의 경우에도 공통적으로 모든 서브프로젝트에서 사용되는 경우에는 해당 디펜던시를 추가해줌

또한 각각의 모듈은 모듈 내부의 build.gradle 파일을 통해 각 모듈에 독립적인 플러그인 설정도 가능하다.

[ ext ]

ext의 경우 gradle에서 사용할 속성을 사용자가 추가적으로 정의하여 할 때 사용한다. 예를 들어 아래 build.gradle 설정에서는 ext { lombokVersion = '1.18.24'} 명시해줌으로서 lombok 버전을 전역적으로 관리하게 된다. 이를 통해 공통적인 속성 값에 대한 관리가 편리해진다.

[ allprojects ]

루트 프로젝트와 서브 프로젝트 모두에서 공통적으로 적용되는 설정을 추가하려 할 때 사용한다.

[ configurations ]

디펜던시 관련한 설정을 하려 할 때 사용한다. 위에서 디펜던시 부분에서 언급하였던 것처럼 implementation, compileOnly, runtimeOnly 등의 각각의 디펜던시 그룹별로 적용할 설정을 할 수 있고, configurations { all { .. } }을 통해 모든 의존성 그룹에 대해 적용하는 설정을 하는 것도 가능하다.

allprojects : 루트프로젝트와 서브프로젝트 모두에 적용
configurations : 의존성 관련한 설정을 하려는 부분
configurations { all {} } : 모든 의존성 그룹에 대해 설정 적용
resolutionStrategy : 의존성 전략 관련 설정 (버전이나 캐싱 설정 등)
resolutionStrategy.cacheChanginModulesFor : SNAPSHOT 버전의 디펜던시에 대한 캐싱 지속 시간 설정
resolutionStrategy.cacheChanginModulesFor 0, 'seconds' : 캐싱 시간을 0초로 설정, 즉 gradle 빌드 실행 시에 원격 저장소에서 항상 최신 버전의 라이브러리를 가져온다.
resolutionStrategy.cacheChanginModulesFor 1, ' hours' : 이과 같이 설정 시에는 1시간 동안 로컬캐시를 사용하다가, 이후에 원격저장소를 확인하여 버전이 업데이트 된 경우, 가장 최신 버전을 받아온다.

** https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html (resolutionStrategy 관련)

즉 gradle이 모든 프로젝트에 대해 추가된 SNAPSHOT 버전의 라이브러리에 대해 캐시하지 않고 원격 저장소에서 항상 최신 버전으로 가져옴. 해당 설정을 해주지 않으면 SNAPSHOT 버전의 라이브러리는 기본적으로 24시간 캐싱되기 때문에, 추가적으로 개발이 진행되어 라이브러리가 업데이트 되어도 이전 버전의 라이브러리를 그대로 사용하게 된다. (반면 라이브러리 사용이 많은 프로젝트에서 매번 새로 라이브러리르 받아오면 빌드 속도가 저하될 수 있다.)

** SNAPSHOT : 기본적으로 지속적으로 업데이트가 발생할 가능성이 있는 개발 중인 디펜던시에 대해 SNAPSHOT을 붙인다.

** release : SNAPSHOT과 반대로 1.0.0, 1.0.1 등과 같이 개발이 완료되어 정식으로 배포된 고정된 버전을 의미한다.

[ dependencyManagement ]

io.spring.dependency-management 플러그인과 함께 사용되어 의존성의 버전을 전역적으로 관리할 수 있게 도와주는 설정이다.

'io.spring.dependency-management' 플러그인은 maven에서 사용하는 BOM 기능을 gradle에서 사용 가능하도록 해준다.

* * BOM : 의존성 버전 목록을 정의한 파일. 라이브러리들의 버전을 BOM 파일에 정의하여, 별도로 각각의 라이브러리에 버전을 설정하여 주지 않아도 된다.

위의 설정을 spring-boot-starter-web의 경우 버전을 명시해주지 않았지만, dependencyManagement 설정에 의해 BOM이 제공하여 주는 버전을 다운받게 된다. (모든 라이브러리에 대한 버전 정보를 가지고 있는 것은 아니기 때문에 BOM에 정의되지 않은 경우에는 별도로 라이브러리 버전을 명시해주어 관리해야 한다.)

즉 dependencyManagement -> 디펜던시에 대한 버전을 spring-boot-dependencies BOM에서 가져와서 각각의 라이브러리 버전을 자동으로 설정해주는데, 이때 각 스프링부트 버전별로 라이브러리 버전도 달라지기 때문에 어떤 버전으로 가져올 지 설정해주어야 한다.

[ Error ] Not registered via @EnableConfigurationProperties, marked as Spring component, or scanned via @ConfigurationPropertiesScan

algml0703 — Mon, 20 May 2024 19:27:57 +0900

Not registered via @EnableConfigurationProperties, marked as Spring component, or scanned via @ConfigurationPropertiesScan

config 관련한 부분이 제대로 등록되지 않아서 발생하는 에러이다.

빈으로 등록해주는 클래스에 @Component, @Service 등이 있는지 확인하고, boot를 실행시키는 main 메서드가 있는 클래스에 @ConfigurationPropertiesScan 어노테이션이 추가되어 있는지 확인해주어야 한다.

[ Java ] - QueryDSL이란 무엇인가? (+기본 세팅)

algml0703 — Sun, 19 May 2024 23:51:13 +0900

QueryDSL :Query Domain Specific Lanauage

QueryDSL이란 무엇인가?

QueryDSL은 자바 코드를 기반으로 하여 쿼리를 작성 할 수 있도록 도와주는 도구로 직관적이고 유연한 쿼리 작성을 가능하게하기 때문에, 복잡한 쿼리나 동적 쿼리 또는 여러 테이블 간의 조인을 통한 값 조회가 요구되는 쿼리 생성이 필요한 경우 등에 JPQL(=JPA Query Lanauage)과 함께 널리 사용되는 라이브러리입니다.

** 자바에서는 데이터베이스 관련 작업을 위해 기본적으로 jpaRepository가 사용되는데, jpaRepository는 자바에서 데이터베이스와 연동된 작업을 하기에 매우 편리하고 간단하지만, 단순 CRUD 위주의 작업을 벗어난 복잡한 쿼리나 혹은 동적 쿼리 또는 여러 테이블과 조인이 필요한 경우 등에는 jpaRepository 만으로는 작업에 어려움이 있어서 해당 작업이 필요한 경우 JPQL과 QueryDSL을 사용합니다.

** 동적쿼리
동적쿼리란 실행 시점에 쿼리의 형태가 변경될 수 있는 쿼리를 의미합니다. 예를 들어 mybatis로 작성된 아래의 쿼리를 보면, title과 sub_category에 대한 조건은 파라미터의 값이 존재하거나 같은 경우에만 조건으로 구현이 되고, title의 값이 존재하지 않거나, category의 값이 Daily가 아닌 경우에 쿼리의 조건은 DEL_YN으로만 하여 생성됩니다. 이와 같이 실행 시점에 들어오는 파라미터의 값들에 따라 구현되는 쿼리의 모양이 달라지는 쿼리를 동적쿼리라고 합니다.

Q) JPQL보다 QueryDSL의 사용이 권장되는 이유?

QueryDSL은 엔티티 클래스를 기반으로 하여 작성된 코드를 통해 쿼리를 생성하기 때문에 코드의 가독성을 높여주고 쿼리 자체의 오타나 문법은 줄일 수 있도록 돕습니다. 예를 들어 “SELECT MAX(b.sortNo) FROM BOARD b where b.category = [category]” 와 같은 쿼리는 JPQL에서 보통 아래와 같이 엔티티를 직접 참조하는 방식으로 사용되며

JPQL을 사용한 경우

QueryDSL의 경우에는 위와 같은 코드를 아래와 같이 자바 코드를 이용하는 방식으로 작성됩니다.

QueryDSL을 사용한 경우

JPQL과 QueryDSL이 구현된 방식을 보면 알 수 있듯이, JPQL의 경우 상대적으로 코드의 가독성이 떨어지고, 오타나 문법 오류 등을 찾기 어려우며, 컴파일 과정에서도 오타나 문법 오류를 걸러내지 못하여 런타임 즉 서버의 실행 과정에서 에러가 발생할 수 있습니다. 반면에 QueryDSL의 경우 도메인의 변경이 직접적으로 쿼리에 반영되고, ide가 코드 자동완성기능을 지원하여 주어 쿼리를 더욱 빠르고 안전하게 구현할 수 있도록 돕습니다. 특히나 QueryDSL을 사용한 경우에 컴파일 과정에서 쿼리에 문제가 있는 경우 이를 감지하기 때문에, 서버의 런타임 과정에서 문제가 발생할 가능성을 줄여줍니다. 더불어 가독성과 유지보수 측면에서도 QueryDSL이 JPQL 보다 많은 이점을 가지기 때문에 일반적으로 복잡한 쿼리나 동적쿼리의 구현이 필요한 경우에 JPQL보다는 QueryDSL의 사용이 권장됩니다.

QueryDSL 특징

QueryDSL은 엔티티로부터 생성된 Q클래스를 사용하여 쿼리를 구현함으로써 타입의 안정성을 보장합니다.

QueryDSL 기본 세팅

환경

Java 17
IntelliJ IDEA 2023.1
gradle

1. build.gradle 파일에 디펜던시 및 설정 추가

build.gradle에 아래의 디펜던시를 추가하여 줍니다.

** 기본적으로 jpa 와 관련한 설정은 되어있다고 가정하였습니다. (jpa 기본 설정 관련 참고 : https://mihee0703.tistory.com/232)

    // querydsl 관련 설정
    // querydsl-jpa와 querydsl-core 반드시 필요
    implementation ("com.querydsl:querydsl-jpa:${dependencyManagement.importedProperties['querydsl.version']}:jakarta")
    implementation("com.querydsl:querydsl-core")
    // querydsl 관련한 추가적인 기능을 제공하여 주는 라이브러리로 필수는 아님
    // implementation("com.querydsl:querydsl-collections")
    annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta"
    annotationProcessor "jakarta.annotation:jakarta.annotation-api"
    annotationProcessor "jakarta.persistence:jakarta.persistence-api"

- implementation("com.querydsl:querydsl-core")
queryDSL의 핵심 모듈로, queryDSL을 사용하기 위한 가장 기본적인 기능을 제공하는 역할을 합니다.
- implementation ("com.querydsl:querydsl-jpa:[version]:jakarta")
gradle에서 사용되는 문법으로 적절한 버전의 값을 자동으로 설정하여 주는 기능을 제공합니다. 해당 디펜던시는 queryDSL JPA모듈의 의존성을 추가하는 역할을 합니다. 스프링부트 3.0 이후 버전인 경우에는 jakarta를 추가해주어야 합니다.
- annotationProcessor "com.querydsl:querydsl-apt:[version]:jakarta"
해당 모듈은 엔티티 클래스를 기반으로 하여 Q클래스를 생성하기 위하여 사용되는 라이브러리입니다.
- annotationProcessor "jakarta.annotation:jakarta.annotation-api"
jakarta에서 사용되는 annotation들을 처리해주기 위해 추가해준 것입니다.
- annotationProcessor "jakarta.persistence:jakarta.persistence-api"
ompileJava를 실시하면 java.lang.NoClassDefFoundError: jakarta/persistence/Entity 에러가 발생하는데 이를 해결하기 위해 추가하여 줍니다.

** ${dependencyManagement.importedProperties['querydsl.version']}
: gradle에서 사용되는 groovy 문법으로 dependencyManagement를 통해 querydsl의 version 값을 가져오는 것입니다. 기본적으로 dependencyManagement에 의해 기본적으로 버전을 관리하여 주는데, 버전 뒤에 추가적으로 jakarta나 jpa 등 추가적으로 붙은 것이 있는 경우에는 위와 같이 직접 버전 정보를 가져와서 설정해주어야 합니다.

build.gradle에 위와 같이 설정해준 후에 compileJava를 실행하면 src/main/generated 폴더가 생성되고 그 하위에 엔티티와 관련한 Q클래스 파일이 생성되는 것을 확인할 수 있습니다.

참고

//https://velog.io/@kimsundae/Gradle-SpringBoot-3.x-QueryDSL-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0

[ Error ] - 카프카 관련 에러

algml0703 — Mon, 1 Jan 2024 18:58:14 +0900

에러 메시지

Caused by: java.lang.IllegalStateException: No group.id found in consumer config, container properties, or @KafkaListener annotation; a group.id is required when group management is used.

위와 같은 에러는 스프링 부트에서 카프카 컨슈머 사용 시 설정해주어야 하는 내용 중 group.id를 설정해주지 않아 발생한 에러이다. 이를 해결해주기 위해서는 application.yml에 아래와 같이 group.id 관련한 내용을 추가해주면 된다.

[ Next.js ] - 폰트 적용하는 법 (next/font)

algml0703 — Wed, 13 Dec 2023 00:34:53 +0900

폰트 적용하는 법 (next/font)

* next13 버전 기준

nextjs에서 프로젝트에 폰트를 적용하기 위해서는 next/font를 이용하는데, next/font는 모든 폰트 파일에 대해 자동으로 자체 호스팅 기능을 내장하고 있다. 자체 호스팅 기능을 제공한다는 것은 어플리케이션에서 사용되는 폰트 파일을 서버에 업로드하고, 해당 서버에서 자체적으로 폰트를 제공한다는 것을 의미한다. 이를 통해 본래 사용자가 웹 사이트를 방문할 때마다 폰트 파일을 외부 네트워크를 통해 다운로드하여 가져와 렌더링하던 과정을 생략할 수 있게 된다, 서버에서 자체적으로 호스팅된 폰트를 이용함으로써 폰트 파일을 최적으로 로드하는 것이 가능하고, 폰트를 불러오기 위해 외부 네트워크에 요청할 필요가 사라지기 때문에, 웹사이트의 성능과 보안상의 이점을 갖게 된다.

즉 next/font는 폰트를 서버에 자체적으로 호스팅함으로써 외부 네트워크 요청을 제거하여 더욱 나은 성능과 보안상의 이점을 가진다.

1) next/font를 통한 이점

외부에 호출할 필요 없이 자체적으로 내장된 폰트 파일을 사용하기 때문에, 로드 시간을 줄여준다.
CDN(Content Delivery Network)을 통해 클꼴을 전 세계의 서버에 분산하여 지리적으로 떨어져있는 사이트 이용자의 경우에도 폰트 파일을 불러오는데 유리하다.
서버 자체에 폰트 파일을 가지고 있기 때문에 크로스 브라우징 경험을 제공할 수 있다.
외부 서버에 대한 요청을 제거하기 때문에 보안 상의 이점을 제공하여 준다.

2) 적용 방법

next/font에는 기본적으로 구글 폰트인 next/font/google과 로컬 폰트인 next/font/local이 존재한다.

next/font/google

위와 같이 적용할 수 있다. * 구글 폰트 https://fonts.google.com/variablefonts

위와 같이 적용할 경우 한 가지 폰트만 전역적으로 적용되게 하는데, 태그벼롤 다르게 폰트를 적용하려는 경우에는 아래와 같이 적용할 수 있다.

적용하려는 폰트의 변수를 넣어준 후, 아래와 같이 global.css 파일에서 아래와 같이 설정해주면 된다.

이와 같이 설정해준 경우, p태그의 경우 폰트는 Roboto 폰트가 적용되며, h1태그의 폰트의 경우에는 PublicSans의 폰트가 적용된다.

출처

https://nextjs.org/docs/app/building-your-application/optimizing/fonts#local-fonts

[ Next.js ] - error (feat. Server Components)

algml0703 — Wed, 29 Nov 2023 23:29:20 +0900

You're importing a component that needs createContext. It only works in a Client Component but none of its parents are marked with "use client", so they're Server Components by default.

원인

Next.js의 경우 기본적으로 Server Components가 사용되는데, 이는 SSR(Server Side Rendering)즉 서버에서 렌더링 작업을 수행합니다.

위와 같은 에러는 Server Components에서 createContext와 같은 Client Components에서 사용되는 기능을 사용하려 했기 때문에 발생한 에러이다. Server Components에서 Client Components에서 사용되는 기능을 사용하기 위해서는 해당 파일의 상단에 "use client"를 명시해줌으로써 해당 파일이 Server Components로 취급되지 않도록 하는 것입니다.

즉 위의 에러를 해결하기 위해서는 아래와 같이 파일의 상단에 "use client" 라고 명시해주면 됩니다.

Server Components

Server Components의 경우 서버에서 렌더링 작업을 수행합니다. Next.js의 경우 기본적으로 Server Components를 취하여 필요에 따라 Client Component를 사용할 수 있습니다. (즉 필요에 따라 클라이언트에서 렌더링되는 UI를 구현함을 의미합니다.)

* Server Components에서 createContext, useState, useEffect와 같은 훅을 사용할 수 없습니다.

Client Componets를 사용하기 위해서는 위에서 언급한 것과 같이 "use client"를 파일 상단에 명시해주면 됩니다. "use client"는 Server Components와 Client Components를 구분하는데 사용됩니다. "use client"를 파일에 정의해준 경우, 해당 파일은 물론, 해당 파일에 속한 하위컴포넌트와, import 로 가져와서 사용한 모듈들 역시도 Client Componets 로 취급됩니다.

* RSC Payload(React Server Component)
서버에서 렌더링 작업 후 클러이언트로 전달하는 렌더링 된 서버 컴포넌트 트리의 압축된 바이너리 표현을 의미합니다. 즉 사용자의 브라우저에 사이트 화면을 출력하기 위해 서버에서 전달하는 데이터를 의미합니다.

Q) 사용자가 nextjs 기반의 사이트 방문 시 렌더링 과정?
사용자가 사이트 방문 시 해당 페이지에 대한 사용자의 요청이 서버로 전송
-> 이후 서버에서 해당 페이지에 대한 데이터를 가져와 초기 렌더링을 수행
-> 서버에서 렌더링 된 HTML, CSS, 자바스크립트 번들을 클라이언트(= 웹 브라우저=사용자)로 전송
(서버에서 렌더링 할 때에 Server Component로 지정된 경우에 대해서만 렌더링 작업을 수행합니다.)

* 데이터 처리 등 백엔드 소스에 가까운 작업은 Server Components로, 사용자와의 상호작용이 필요한 부분은 Client Components로 구분함으로써 어플리케이션의 성능과 사용자 경험을 향상 시킬 수 있습니다.
- Server Components의 경우 데이터 요청과 렌더링 모두 서버에서 이루어져 완전한 페이지가 사용자에게 출력되기 까지의 시간을 단축시켜 줍니다.

Server Components에서 유리한 작업

데이터 요청
백엔스 리소스에 접근
엑세스 토큰, API 키 등 민감 정보를 사용하는 작업

Client Components에서 유리한 작업

useState, useEffect 등을 통한 상태 관리가 필요한 작업
브라우저에서만 사용되는 API 작업이 요구되는 경우

출처

server components: https://nextjs.org/docs/app/building-your-application/rendering/server-components

client components: https://nextjs.org/docs/app/building-your-application/rendering/client-components