macdduck 님의 블로그

GitLab과 CI/CD

macdduck — Tue, 21 Jan 2025 20:56:12 +0900

GitLab의 장점

- 오픈소스

- 자체 Git 저장소

(Jenkins는 Git저장소를 제공하고 있지 않기 때문에 GitHub나 GitLab 같은 Git저장소를 써야 함)

- 통합된 환경

- 안전성과 안정성..?

(기업에서 많이 사용하고 있기 때문에)

- 자체 호스팅 가능

(기업에서 많이 사용하고 있는 이유)

데이터 센터의 서버에 직접 설치해서 서비스 가능. 이렇게 되면 기업들의 보안 정책들(소스 코드를 반드시 제어할 수 있는 공간에 둬야 한다 등)을 달성할 수 있음.

또한, SaaS형으로 인터넷 서비스 형태로 설치 없이 사용 가능.

- 이슈 관리 툴

- 다양한 플러그인 제공

vite-react 프로젝트 생성 후 실행 시 error 사항 (작성 중)

macdduck — Fri, 20 Dec 2024 17:58:56 +0900

자료구조 - Array & LinkedList

macdduck — Tue, 29 Oct 2024 18:57:02 +0900

Array & LinkedList

가장 큰 차이점은

메모리에 저장되는 방식과 operation의 연산 속도

고정된 저장 공간에 연속적이고 순차적으로 저장. compile 시점에 메모리 크기가 결정되며 stack memory영역에 할당.

비연속적으로 데이터 값과 다음 address를 저장. runtime 시점에 동적으로 메모리 크기가 결정되며 heap memory영역에 할당.

Array & Dynamic Array

resize하여 fixed-size를 보완

Dynamic Array & LinkedList

DB Lock

macdduck — Thu, 17 Oct 2024 13:21:05 +0900

1. DB Lock

1.1 개념

데이터베이스에서 여러 트랜잭션이 동시에 같은 데이터에 접근할 때, 데이터의 무결성(일관성)을 보장하기 위해 사용되는 메커니즘.

한 트랜잭션이 특정 데이터에 대해 작업을 하고 있을 때, 다른 트랜잭션이 그 데이터에 접근하지 못하도록 잠그는 것. 데이터의 일관성 유지 및 동시에 발생할 수 있는 충돌을 방지

1.2 필요성

DB 락을 통해 데이터에 대한 접근을 제어하면, 다음과 같은 상황에서 발생할 수 있는 데이터 무결성 문제를 예방할 수 있음.

- Dirty Read: 한 트랜잭션이 데이터를 수정 중일 때 다른 트랜잭션이 그 데이터를 읽는 상황

- Non-repeatable Read: 한 트랜잭션이 데이터를 읽은 후, 다른 트랜잭션이 그 데이터를 수정하고 커밋하여 첫 번째 트랜잭션이 동일한 데이터를 다시 읽을 때 값이 달라지는 상황.

- Lost Update: 두 개의 트랜잭션이 동시에 같은 데이터를 수정하려고 할 때, 한 트랜잭션의 수정 내용이 다른 트랜잭션에 의해 덮어쓰여져 사라지는 상황.

2. 락의 종류

- 공유 락(Shared Lock, S Lock) : 데이터베이스에서 데이터를 읽을 때 사용. 여러 트랜잭션이 동시에 같은 데이터를 읽을 수 있지만, 공유 락이 걸린 동안에는 데이터를 수정할 수 없음.

- 배타 락(Exclusive Lock, X Lock): 데이터를 수정할 때 사용. 배타 락이 걸린 데이터는 다른 트랜잭션이 읽거나 수정할 수 없음. 한 트랜잭션이 배타 락을 획득하면 다른 모든 트랜잭션은 해당 데이터에 접근할 수 없음.

- 비관적 락(Pessimistic Locking): 데이터를 읽을 때부터 락을 걸어 다른 트랜잭션이 접근하지 못하도록 하는 방식. 데이터의 충돌 가능성이 높을 때 유용.

- 낙관적 락(Optimistic Locking): 데이터를 수정하기 전까지 락을 걸지 않고, 수정 시점에만 충돌을 확인하는 방식. 주로 데이터의 버전 번호를 사용하여 동시성 문제를 해결.

- 명명된 락(Named Lock): 데이터베이스에서 특정 이름으로 락을 설정하여, 동시에 하나의 프로세스만 특정 리소스에 접근하도록 하는 방식. 주로 특정 리소스나 작업에 대한 접근을 직관적으로 제어하기 위해 사용.

- 분산 락(Distributed Lock): 여러 시스템이나 인스턴스에서 동시에 동일한 자원에 접근할 때, 자원의 일관성을 유지하기 위해 사용되는 락. Redis와 같은 분산 시스템을 사용하여 구현.

2.1. 비관적 락

종류

- Pessimistic Read: 읽기 락(Shared Lock)을 설정하여, 다른 트랜잭션이 해당 데이터를 읽을 수는 있지만, 수정은 할 수 없도록 함.

- Pessimistic Write: 쓰기 락(Exclusive Lock)을 설정하여 다른 트랜잭션이 해당 데이터를 읽거나 수정하지 못하도록 함.

DB 레벨에서의 락 동작

- 락 설정: 비관적 락을 사용하면 SQL쿼리나 트랜잭션이 데이터베이스에 접근할 때 락이 설정.

- 락 해제: 일반적으로 트랜잭션이 종료되거나 커밋될 때 해제. 롤백되는 경우에도 락이 해제.

비관적 락은 주로 데이터베이스 레벨에서 동작, 데이터 무결성을 보장하는 데 매우 유용.

그러나 DB레벨에서 동작하기 때문에 성능에 영향을 미칠 수 있으므로, 데이터 충돌 가능성이 높은 환경에서 신중하게 사용해야 함.

스프리부트와 같은 애플리케이션에 서 비관적 락을 설정하면, 데이터베이스가 이 락을 처리하고 관리하게 됨.

비관적 락이든, 낙관적 락이든, 이거를 설정했다고 해서 충돌이 완벽하게 해소되었다. 라고 표현할 수 없음. 환경에 따라 달라지기 때문.

따라서 어느 정도의 요청량이 들어올 거라는 것을 파악해야 함. 너무 많은 요청이 온다면, DB Lock보다 메시지 큐(RabbitMQ, Kafka)를 사용하여 쓰기를 대기열에 넣어서 지연시키는 방법으로 하는 것이 더 안전.

2.2 낙관적 락

동작방식

- 낙관적 락(Optimisitc Lock)은 트랜잭션 간의 충돌을 최소화하고 성능을 향상시키기 위해 사용되는 동시성 제어 메커니

즘.

- 비관적 락이 데이터베이스 레벨에서 락을 걸어 다른 트랜잭션의 접근을 차단하는 방식이라면, 낙관적 락은 DB락을 사용하지 않고, 대신 데이터가 변경되었는지 확인하여 충돌을 처리하는 방식.

- 버전 관리:

- version이라는 필드를 엔티티에 추가하여, 해당 엔티티의 수정 횟수를 추적.

- 트랜잭션이 엔티티를 읽을 때, 현재의 버전 번호가 함꼐 읽혀옴.

- 트랜잭션이 엔티티를 수정하고 저장하려고할 때, 현재 데이터베이스에 저장된 버전 번호와 트랜잭션이 처음 읽어온 버전 번호를 비교.

- 데이터 충돌 검출

- 트랜잭션이 데이터를 저장할 때, 데이터베이스에 저장된 버전 번호가 트랜잭션이 처음 읽어온 버전 번호와 동일하다 면, 데이터가 수정되지 않았다고 간주하고 업데이트를 수행. 이때 버전 번호는 증가.

- 반면, 버전 정보가 다르다면, 다른 트랜잭션이 데이터를 수정한 것으로 간주하고, 현재 트랜잭션을 롤백하거나 재시도

장단점

- 장점:

- 성능: DB락을 걸지 않으므로 병행 처리 성능 향상.

- 유연성: 충돌이 발생했을 때, 비즈니스 로직에 따라 트랜잭션을 재시도하거나 롤백할 수 있음.

- 단점:

- 충돌 가능성: 데이터가 자주 변경되는 경우, 충돌이 자주 발생할 수 있음. 이로 인해 여러 번의 재시도 필요 가능.

- 복잡성: 충돌을 처리하기 위한 로직이 추가로 필요.

낙관적 락은 데이터베이스 락을 최소화하면서도 데이터 일관성을 유지할 수 있는 효과적인 방법임.

특히, 데이터 충돌이 적고 병행 처리가 많은 시스템에서 유용하게 사용할 수 있음.

하지만, 충돌이 발생했을 때의 처리 로직을 잘 설계해야 하며, 특정 상황에서는 비관적 락보다 복잡할 수 있음.

2.3 데드 락

데이터베이스 환경에서 데드락은 2개 이상의 트랜잭션이 서로가 점유하고 있는 자원을 기다리면서 영원히 대기 상태에 빠지는 상황을 의미.

이 상황이 발생하면, 해당 트랜잭션들은 더 이상 진행될 수 없고, 시스템 성능에 큰 영향을 미칠 수 있음.

예시

- 트랜잭션A는 테이블 X의 일부 행을 잠금(Lock)하고 이후 테이블 Y의 행을 잠금하려고 시도

- 트랜잭션B는 Y의 일부 행을 잠금하고, 이후 테이블 X의 행을 잠금하려고 시도

- 이 경우, 트랜잭션 A와 B는 서로 상대방이 보유한 잠금을 기다리면서 영원히 대기하게 되며, 이로 인해 데드락 발생

메일 발송 원리

macdduck — Sat, 12 Oct 2024 00:46:03 +0900

시작하며

플래시 세일(Flash Sale)을 주제로 프로젝트를 진행하고 있다. msa로 진행되고 있는데 그 중 알람 서비스도 맡게 되어, 플래시 세일 1시간 전 사용자가 알림 설정한 상품에 대해 메일을 발송하는 기능을 구현해야 했다.

먼저 메일이 어떤 원리로 전송이 되는지 대략적으로 정리하고, 어떤식으로 구현할 건지 간략하게 얘기해보겠다.

1. 이메일 시스템의 주요 구성 요소
2. 메일 발송을 위한 프로토콜
3. 이메일 발송의 단계별 과정
4. SMTP의 보안 강화 기술

1. 이메일 시스템의 주요 구성 요소

이메일 발송 과정에서 핵심적으로 사용되는 구성 요소는 크게 3가지로 나뉜다. 이메일 클라이언트(MUA), 메일 서버(MTA), 메일 수신 서버(POP3, IMAP)이다.

이메일 클라이언트 (Mail User Agent)

이메일 클라이언트는 사용자가 이메일을 작성하고 발송하는 소프트웨어다. 흔히 사용되는 Gmail 등의 애플리케이션이 이에 해당한다. 클라이언트는 작성한 이메일을 메일 서버로 전달하며, 발송 과정에서 SMTP프로토콜을 사용한다.

메일 서버 (Mail Transfer Agent)

메일 서버는 이메일을 실제로 처리하고 전달하는 역할을 한다. 메일 서버는 발신자의 메일 서버와 수진자의 메일 서버로 나뉘며, 이 두 서버는 이메일 전송을 위해 서로 통신한다.

예를 들어, A가 Gamil로 B의 Naver mail에 메일을 보낸다고 하면, 구글의 메일 서버와 네이버의 메일 서버가 통신한다.

POP3, IMAP → 수신자의 메일 서버(MTA)에서 사용

수신된 이메일은 POP3나 IMAP 프로토콜을 통해 사용자에게 전달된다. 수신자는 이 서버에 접속하여 이메일을 다운로드(POP3)하거나 서버에서 직접 확인(IMAP)할 수 있다.

POP3
수신자의 클라이언트에서 이메일을 MTA에서 다운로드한 후, 기본적으로 서버에서 삭제된다.
주로 단일 디바이스에서 이메일을 관리할 때 사용한다.
IMAP
이메일을 서버에 그대로 남겨두고, 여러 디바이스에서 이메일을 동기화할 수 있다.
여러 기기에서 이메일을 확인하는 경우 적합하다.

2. 메일 발송을 위한 프로토콜

이메일을 발송할 때 사용되는 핵심 프로토콜은 SMTP(Simple Mail Transfer Protocol)이다. 클라이언트가 메일 서버에 이메일을 전송하고, 메일 서버 간 이메일을 전송하는 표준 프로토콜이다.

SMTP의 작동 원리

SMTP는 클라이언트-서버 모델로 작동하며, 클라이언트가 서버에게 이메일을 보내면 서버는 이를 수신자의 메일 서버로 전송하는 역할을 한다.

또한, 통신은 명령어와 응답 코드로 이루어지는데, 이 부분은 추후에 다룰 기회가 있으면 자세하게 다뤄보겠다.

3. 이메일 발송의 단계별 과정

[발신자 클라이언트]

사용자가 이메일 클라이언트에서 이메일을 작성하고, 전송 버튼을 누르면 SMTP프로토콜을 통해 이메일이 발신자의 메일 서버로 전송된다. SMTP는 포트 25에서 작동한다.

[발신자 메일 서버]

사용자의 이메일 클라이언트로부터 받은 이메일은 발신자의 메일 서버(MTA)로 전송된다. MTA는 수신자의 이메일 주소를 분석하여 해당 이메일이 어떤 도메인으로 가야 하는지 확인한다.

DNS를 사용해 수신자의 도메인에 연결되 MX 레코드(Mail Exchange Record)를 조회한다. 이는 해당 도메인에서 메일을 수신할 수 있는 메일 서버의 정보를 포함하고 있다. 특히 IP 주소가 포함되어 있어, 이를 통해 발신자의 메일 서버는 수신자의 메일 서버로 연결할 수 있다.

[릴레이 서버]

이메일이 발신자의 메일 서버에서 수신자의 메일 서버로 전달될 때, 직접 전송이 될 수도 있지만, 여러 중간 서버를 거칠 수도 있다. 중간 서버를 릴레이 서버라고 하는데, 이 부분은 생략하겠다.

[수신자 메일 서버]

이메일이 수신자의 MTA에 도달하면, 수신자 MTA의 MDA(Mail Delivery Agent)는 이메일을 최종적으로 수신자의 메일함으로 전달한다. 이때 이메일은 수신자의 MTA에 저장된다.

[수신자 클라이언트]

이제 수신자는 자신의 이메일 클라이언트를 통해 메일 서버에 접속하여 이메일을 확인할 수 있다. 이때 이메일을 확인하는 방식에 따라 POP3, IMAP을 선택하게 되는데, 요즘은 거의 IMAP이 사용된다.

4. SMTP의 보안 강화 기술

SMTP는 인터넷이 비교적 작고 신뢰할 수 있는 환경에서 설계된 메일 전송 프로토콜이었기 때문에 보안이나 인증 측면이 약했다고 한다. 즉 서버 간에 신뢰를 전제로 설계되어 별도의 인증 없이도 메일을 주고받을 수 있었다. 하지만, 인터넷 환경이 복잡해지고 악의적인 사용자가 늘어남에 따라, 현대의 SMTP는 여러 보안 기술을 통해 신뢰 기반의 취약점을 보완하고 있다고 한다.

물론 우리가 흔히 쓰는 구글이나 네이버에서 보안관련 설정을 해주기 때문에 우리가 핸들링할 상황은 거의 없을 것 같지만, 그래도 어떤식으로 보안을 강화했는지 간단하게 정리해 보겠다.

SPF (Sender Policy Framework)
발송자가 인증된 메일 서버를 통해 이메일을 보냈는지 검증한다.
DKIM (DomainKeys Identified Mail)
이메일 본문에 서명하여, 메일이 변경되지 않았음을 보장한다.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
SPF와 DKIM을 함께 사용하여 발송자 신원 확인을 강화하고, 의심스러운 메일에 대해 정책을 설정하는 방법이다.
TLS (Transport Layer Security)
이메일 전송 중에 내용을 암호화하여, 이메일이 가로채지더라도 내용이 보호되도록 한다.

마치며

메일 발송 기능을 구현하기 전 어떤 식으로 작동하는 건지 원리에 대해서 알아보았다. 물론 위에서 적은 내용들 중 내가 핸들링할 사항은 많지 않겠지만, 동작원리 및 전체적인 그림에 대해서 알고 가는 것이 중요하다고 생각하는데 잘 정리가 된 것 같다.

프로젝트 내에서 메일 발송 기능을 어떤식으로 구현할 건지도 적어보려 했으나, 내용이 길어져 다음 글에 써보도록 하겠다.

토큰 유효성 검사 관련 리팩토링

macdduck — Mon, 7 Oct 2024 18:18:08 +0900

시작하며

이번 프로젝트에도 인증, 인가 부분을 포함한 부분을 맡게 되었다. 이제는 개념이 많이 잡힌 것 같고, 기존 프로젝트 때 잘못했던 부분들을 파악할 수 있게 되고 있는 것 같다.

토큰 유효성 검사 시 예외 처리 부분을 잘못하고 있었다는 것을 발견했는데 그 부분에 대해서 얘기해 보겠다.

1. 문제상황

1. 문제상황

토큰에 대한 유효성 검사를 할 때 실행되는 JwtUtil 내 메서드이다. 어떤 예외가 발생하는 지 알기 위해서 주로 발생하는 예외에 대해서 try~catch문으로 감싸서 처리를 했다.

특히, 만료된 토큰인지 검증하는 메서드는 토큰 재발급시 단독으로 사용될 것 같아 분리해서 처리를 했다.

아래 로그는 만료된 토큰으로 api요청을 보냈을 때 발생하는 에러인데,

잘못 생각했던 부분은 2가지였다.

첫번째는, 내가 원하는 대로 log.error가 찍히지 않는 상황이다. 분명 ExpiredJwtException이 발생하고 있는데
위 isNotExpiredAccessTeken메서드의 catch문에서 적은 log.error가 찍히지 않고 있다. 심지어 print는 찍히고 있었다.

이유는 뒤에 getUserIdFromAccessToken(token) 메서드 실행 시, 만료된 토큰이므로 여기서 또 ExpiredJwtException이 발생하기 때문이었다. 따라서 이 부분을 수정하거나, 제거해야 했다.

방법은 3가지 정도가 떠올랐다.

1. SecurirtyContextHolder에서 id를 가져오기.

2. Jwt에서 Payload를 추출하고, 거기서 id를 가져오기.

3. id 찍는 부분을 삭제하기.

1번. Auth서비스에서 Security의존성을 가지고 있지 않으므로 불가했다.

2번. id를 로그에 저장하려면 이 방법이 가장 적합해 보였다. 다만, 이 로그를 가지고 어떤 인사이트를 얻을 수 있느냐를 생각해 봤을 때, 굳이? 라는 생각이 들었다.

성별, 연령별, 직업 등의 빅데이터를 기반으로 토큰이 만료됐을 때, api요청을 보내는 빈도를 분석할 것도 아니고, 만약 유의미한 결과가 도출됐다고 해도, 각 집단 별 토큰의 만료기간을 다르게 할 것도 아니다. 결정적으로 우리 서비스는 일단 회원가입 시 사용자를 군집화할 데이터를 받지도 않고 있다.

따라서 3번. 아예 id를 찍는 부분을 제거하기로 결정했다.

그 결과 이렇게 원하는 대로 에러 로그가 찍히게 됐다.

잘못 생각했던 부분 두번쨰는, 토큰 유효성 검사 메서드에서 만료된 토큰인지 확인하는 메서드를 분리했던 점이다.

AccessToken에서 id를 가져오는 메서드에서 알 수 있듯이, 아래 사진처럼 굳이 jwt의 Expiration에서 값을 가져와서 현재시간과 비교하지 않아도, 만료된 토큰이면 ExpiredJwtException이 발생한다.

즉, 아래 사진처럼 코드를 작성하면, 만료된 토큰인지 알 수 있는 로그만 찍히지 않을 뿐, false가 반환돼 service단에서 예외가 발생한다.

따라서 위 두 코드를 합쳐서 진행하기로 결정했다.

마치며

Auth서비스에 불필요한 요청이 가지 않도록 Gateway에서 캐싱처리를 하고 api테스트 중 위와 같은 상황을 인지하여, 코드를 수정하게 되었다. 나름 잘 해결된 것 같고, 현재는 Gateway에 캐싱된 데이터가 있는데도 불구하고, Auth서비스로 verify요청이 가는 문제상황에 직면했다.. 아직 이유를 찾지는 못하였는데, 디버깅을 통하여 빨리 해결해 보겠다.

AI 검증 비즈니스 프로젝트 - 로그인 관련 트러블 슈팅

macdduck — Wed, 28 Aug 2024 23:16:22 +0900

시작하며

Spring Security와 JWT를 사용하여 회원가입, 로그인을 구현하고자 했다. 회원가입을 완료하고, 로그인을 했더니 403 FORBIDDEN에러가 발생했다. 확인 결과 UsernamePasswordAuthenticationFilter를 상속해서 커스텀한 Filter를 호출하지 못하고 있었다. 왜 안되는지 몇 시간 동안 씨름을 하다 결국 내부 코드를 까서 원인을 찾았다.

어떤 문제가 있었고 어떻게 찾았는지, 그리고 어떻게 해결했는지 정리해 보겠다.

1. 전체적인 흐름 정리

먼저 jwt를 사용할 때의 전체적인 흐름에 대해서 먼저 정리해 보겠다.

1) SpringSecurity의존성을 추가하게 되면 기존 톰켓의 Servlet 컨테이너의 필터 체인에 DelegatingFilter를 등록하게 된다. 이름에서 알 수 있듯이 DelegatingFilter는 모든 요청을 가로채서 SecurityFilterChain에 넘긴다.

2) jwt를 사용하려면 기존 security의 기본 동작 방식을 disabled 시켜줘야 한다.

3) formLogin을 disabled로 해주고, 세션 옵션을 stateless로 바꿔주면 SpringSecurityFilter의 UsernamePasswordAuthenticationFilter가 동작을 하지 않게 된다. 이 필터는 로그인 요청을 처리하는 필터인데, 인증 정보를 검증하여, 인증 과정을 처리한다. 이 필터가 동작을 하지 않으므로, 강제로 커스텀해서 JWT인증 시 작동하도록 설정을 해줘야 한다!!

4) 따라서 UsernamePasswordAuthenticationFilter를 상속받아서 커스텀을 하고, 추가로 발급된 토큰에 대해서 인증, 인가 처리를 하는 Filter도 커스텀하여, SecurityConfig파일에 Filter를 추가했다.

5) 로그인 요청에 대해 테스트를 하기 위해, 회원가입부터 진행하고 로그인을 진행하였다.

6) 전에 이미 완료했던 회원가입은 잘 진행됐고 로그인 요청을 하였는데, 403 Forbidden에러가 발생했다.

2. 트러블 슈팅 과정

1) 코드의 논리 확인

우선은 어디서 문제가 생겼는지 찾아야 했다... JWT를 처음 사용하는 것이어서 최대한 흐름이 어떻게 되는지 붙잡으면서 코드를 작성했다. 많은 자료조사도 했고, 공식 문서도 확인하면서 어느 정도 납득이 되면 스텝을 밟았다.

그럼에도 불구하고 예외가 터지니 내가 이해했던 부분에 대해 신뢰도도 내려가고, 처음부터 다시 확인할 수밖에 없었다. 의존성 주입이 잘 됐는지부터, 전체적인 흐름에 대해 다시 검토를 하였지만, 로직에는 문제가 없는 것 같았다.

2) 로그 찍기

로직에는 문제가 없어서 더 문제였다. 그래서 찍을 수 있는 모든 곳에 로그를 찍기 시작했다. 그 결과 내가 커스텀해서 등록한 Filter 중 UnernamePasswordAuthenticationFilter를 상속받아 커스텀 한 필터가 호출되지 않는다는 것을 알아냈다.

부끄러운 로그의 흔적인데,, 해당 로그가 찍히지 않는 것을 발견했다. 그렇지만, 로직도 괜찮았고 해당 필터도 당연히 등록을 해줬기 때문에 몇 시간 동안 뭐가 문제인지 찾지를 못하였다...

3) security 디버그 모드

@EnableWebSecurity의 debug옵션을 true로 바꾸고 애플리케이션을 실행하니 여러 정보들이 나왔다. 정보들 중에 적용된 filter chain들이 있었는데, 호출이 안된다고 생각했던, JwtAuthentiationFilter가 등록되어 있었다..!!

4) 인텔리제이 디버거

따라서 AuthenticationFilter에 문제가 있는 것 같으니, 바로 위 필터인 JwtAuthorizationFilter에 브레이크 포인트를 걸고 디버깅을 진행했다.

뭔가 보이는 것 같으면서도 문제점을 찾지 못하였다...

5) 직접 코드 내부 들여다보기

그래도 위에서 말한 필터 주변에서 문제가 있는 것 같으니, 상속받은 필터의 코드 내부를 들여다보기로 하였다. UsernamePasswordAuthenticationFilter인데 이미 글이 너무 길어졌으니, 다음 글에서 트러블 슈팅 과정을 마무리하겠다..!

마치며

글을 쓰며 전체적인 흐름에 대해 다시 정리된 기분이다. JWT를 통해 로그인, 회원가입을 구현해 보았다면, 위 글을 읽고 어디서 문제가 있었는지 이미 찾았을 수도 있다. 다음 글에서 마저 정리해 보도록 하겠다.

그리고 디버깅의 중요성에 대해서 다시 한번 알게 되었다. 뭔가 모르겠다 싶으면, 디버거를 사용해서 디버깅도 해보고, 내부 코드를 보는 것에 대해 두려워하지 말아야겠다. 엄청 오랜만에 본 것 같은데, 너무 재밌었다.

로그인, 회원가입 구현을 위해 필요한 개념 목록

macdduck — Sun, 25 Aug 2024 22:26:23 +0900

spring security 사용의 이유. 장점.

세션 vs jwt → cs 인증 방식 완성

jwt토큰을 담는 위치 cookie vs reqeust header

refresh token 관련 설정 및 장단점

flow 정리

SQLD 벼락치기...

macdduck — Sat, 24 Aug 2024 01:42:15 +0900

2-29 다시 보기

엔티티 매핑 관련 문제는 NULL인 것 제외 혹은 VALID CUSTOMER 같은 것 생각!! 중복 제외도 생각!

SELECT 절에 DISTINCT는 항상 SELECT 바로 뒤에 위치한다.

별칭(ALIAS)에 공백, 특수기호가 포함되거나 대소문자를 구분하고 싶을 때 "쌍따옴표" 붙여줘야 함.

TRUNCATE는 DDL

SELECT절에서 컬럼 별칭을 사용하면 ORDER BY 절에서만 사용 가능

LPAD('X', 5, 'Y') → X의 왼쪽에 Y를 삽입해서 5개를 만들어라

INSTR('A', 'B', x, y) → A에서 B를 x번째부터 찾는데, y번째 발견된 위치를 반환해라

CEIL() → 올림. CEIL(3)은 3

ROUND(X, -3) → 3번째에서 반올림

SIGN() → 양수 음수 판별, 양수면 1, 0이면 0, 음수면 -1 return

NVL(A, B), ISNULL(A, B) → A가 NULL이면 B, NOT NULL이면 A

A와 B의 데이터 타입은 꼭 일치해야 함!! 불일치하면 오류

COALESCE(A, B, ...) → NULL이 아닌 가장 앞에 있는 값 return

NULLIF(A, B) → A와 B가 같으면 NULL이 return. 같지 않으면 A return

DECODE(A, B, C, D, .... ) → A가 B와 같으면 C, 같지 않으면 D return

DECODE(A, B, C) → A가 B와 같으면 C, 같지 않으면 NULL return

TRIM()함수는 제거해 나가다가, 제거하지 않을 문자를 만나면 스탑!

INITCAP() → 카멜 표기법으로 바꿈

REPLACE(A, B, C) → A에서 B를 C로 치환

REPLACE(A, B) → A에서 B를 모두 삭제

TO_CHAR(100, '9999.99') → 공백100.00

TO_CHAR(100, '0000.00') → 0100.00

즉, 9는 공백 / 0은 0으로 채움

INNER JOIN 사용 시, USING이나 ON을 반드시 사용해야 한다. 참

CASE문에서 WHEN 앞에 비교대상이 들어가면 타입이 무조건 맞아야 함.... 1-18

CASE문에서 CASE ~ WHEN ~ THEN ~

WHEN ~ THEN~ ELSE ~. // 이렇게 ELSE는 마지막에 한 번만 올 수 있음

오라클에서 100+'1' 은 101!

일(DAY)만 쓰게 되면 나머지 년월 시분초 등은 현재 날짜를 따름...!

날짜 +- 1에서 1은 하루

날짜 계산시 30/24/60의 값은 30 * 1/24/60으로 보면 됨 → 30 * 1시간/60 → 30분

CASE WHEN DEPTNO = 10 THEN 1 ELSE 0 END

CASE WHEN DEPTNO = 10 THEN 1 END → 1이 아니면 NULL임

연산자 우선순위 → NOT, AND, OR 순

NULL을 포함한 SUM → NULL로만 구성된 SUM은 NULL return / 포함이 됐으면 NULL은 무시

NULL과 사칙연산 → NULL return

NULL을 포함한 COUNT → NULL은 카운트하지 않음!! / NULL로만 구성된 COUNT는 0

WHERE 절이 FALSE이면 아무것도 출력되지 않음!!

ORDER BY와 NULL → 오라클에서는 NULLS LAST가 DEFAULT(오름차순)

근데 내림차순으로 ORDER BY 를 하면 거꾸로 되니까 NULL이 첫번째로 옴....

MOD(X, Y) → X를 Y로 나눈 나머지

GROUP BY절에는 컬럼 별칭을 사용할 수 없다..... → 별칭을 지정할 수 없다는 게 아니라, SELECT절에서 지정한 컬럼 별칭을 사용할 수 없다는 뜻...!

ORDER BY절에서만 유일하게 사용 가능하다.

OFFSET N → N 행을 건너 뜀

GROUP BY절에서는 그룹함수를 사용할 수 없다!

GROUP BY절에서는 명시되지 않은 컬럼을 그룹함수 없이 SELECT절에서 사용할 수 없다 1- 24 - 3

GROUP BY절에서 나열되는 컬럼 순서는 중요하지 않다

GROUP BY절에 사용한 컬럼만 ORDER BY 절에 사용할 수 있

GROUP BY절에서 NULL도 묶임...!

공집합에 대해 GROUP BY를 하면 공집합

공집합을 COUNT()하면 공집합

공집합은 아무것도 없는 것이고, NULL은 비어 있는 것이어서 둘은 다름

GROUP BY의 결과가 아무것도 없을 때 COUNT를 하면 공집합

단순히 WHERE절을 만족시키지 않을 때 COUNT를 하면 0

SELECT절에서 컬럼 별칭을 정의하면, 컬럼 별칭 앞에 테이블 명을 사용할 수 없음

<>과 !=은 같음. 같지 않으면 TRUE return

비교 연산자와 NULL → NULL을 포함하면 FALSE / NULL = NULL 또는 NULL != NULL이 성립할 수 없음

FROM절에서 , 로 이어져 있으면, JOIN임....

LEFT OUTER JOIN → A LEFT OUTER JOIN B ON 조건이면, 조건을 만족하지 않는 A컬럼은 유지되고, 나머지 컬럼은 NULL로 채워짐

FULL OUTER JOIN → UNION으로 됨.. 중복 제거!!!

CROSS JOIN → 카디널리티의 곱 (모든 경우의 수)

NATURAL JOIN → 컬럼의 이름이 같은 놈들끼리 JOIN / 주의!!! NULL과 NULL은 같다고 할 수 없음!!

USING이나 ON을 사용할 수 없음!!!!

IN 연산자와 NULL → A IN (X, Y, Z)이면 A = X or A = Y or A = Z이므로 X, Y, Z 중에 NULL이 오면 반환 제외 1- 31

NOT IN 연산자와 NULL → A NOT IN (X, Y, Z)이면 A != X and A != Y and A != Z이므로, X, Y, Z에 하나라도 NULL이 오면 모두 제외. 아무것도 안 나옴.

EXISTS(서브쿼리) → 서브쿼리의 결과가 존재하면 출력

NOT EXISTS(서브쿼리) → 서브쿼리의 결과가 존재하지 않으면 출력

여기서 서브쿼리내 SELECT A 에서 A에는 아무거나 들어가도 상관 없음!!! 존재 유무만 판단하면 되기 때문

날짜 대소비교에서 2020/02 보다 크면, 2020/02/01 이후이면 됨(크거나 같으면 2월 1일 포함)

WHERE A <= ALL(30, 40, 50) → A가 30 보다 작거나 같아야 함

서브쿼리가 있을 때 무조건 서브 쿼리가 먼저 실행되는 게 아니라, 해당 절을 탔을 때의 서브쿼리가 먼저 실행

JOIN시 USING (필수)을 사용하는 경우 → 두 테이블의 공통된 컬럼을 기준으로 JOIN할 때... 무조건 괄호!

INNER JOIN을 걸면 구매를 안 한 고객은 생략되고 구매가 안 된 서비스는 생략 됨.. 1 - 35

LEFT OUTER JOIN을 걸고 COUNT를 해주면 됨...! 근데 COUNT를 하더라도 무엇을 하냐에 따라 차이가 있음!!

SELECT TOP(2) WITH TIES → 2등이 여러명이더라도 2등까지 모두 출력!!

ROLLBACK TO SAVE1; → SAVE POINT로 롤백!!!

ROLLBACK; → 아직 커밋하지 않은 쿼리 모두 롤백!!!!!!!

타입 관련

NUMBER(5, 2) → XXX.XX // 정수 부분은 무조건 최대 3자리수! 소수 부분은 아무리 많이 들어와도 자동으로 2자리

테이블 컬럼 별칭을 지정할 때 A, "A"는 다른 것임

HAVING절에서는 그룹함수가 없는 일반 조건을 사용할 수가 있다.

TRUNC(A, B) → 숫자일 때, 소수점 아래 B까지 버림

날짜일 때, TRUNC(8월 24일, 'MM') 이면 월의 첫째날인 8월 1일이 됨 // DEFAULT는 DAY값 버림

날짜 포멧

RRMMDD → RR이 1~49이면 2000년대, 50~99이면 1900년대

TTMMDD → YY는 무조건 2000년대 이후

(SYSDATE - BIRTHDAY) / 365 → (오늘 날짜 - 생일) / 365 = 만 나이

ORDER BY절에 SELECT절에 정의되지 않은 컬럼을 사용할 수 있다

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

그룹 함수

GROUPING SETS(A, B, . . .) → A, B, . . .로 GROUP BY 결과

ROLLUP(A, B) → A, (A, B), 전체()로 GROUP BY 결과 / 전체는 GROUPING SETS로 표현했을 때, ()이나 NULL?

CUBE(A, B) → A, B, (A, B), 전체()로 GROUP BY 결과

여기서 전체는 전체 총계 의미!!! 아마 SUM값 구하고 나머지는 NULL로 채우면 될듯

윈도우 함수

기본 골격

SELECT

윈도우함수([대상])

OVER([PARTITION BY 컬럼] // 출력할 총 데이터 수 변화 없이 그룹연산 수행할 GROUP BY 컬럼

[ORDER BY 컬럼 ASC | DESC] // RANK의 경우 필수

[ROWS | RANGE BETWEEN A AND B]); // 연산 범위 설정, ORDER BY절 필수

PARTITION BY는 ㅇㅋ

ORDER BY 도 ㅇㅋ

ROWS | RANGE BETWEEN A AND B가 문제인데....

ROWS: 값이 같더라도 각 행씩 연산

RANGE: 같은 값의 경우 하나의 RANGE로 묶어서 동시 연산(DEFAULT)

BETWEEN A AND B → DEFAULT는 처음부터 현재행까지

A) 시작점 정의

CURRENT ROW: 현재행부터
UNBOUNDED PRECEDING: 처음부터(DEFAULT)
N PRECEDING: N 이전부터

B) 마지막 시점 정의

CURRENT ROW: 현재행까지(DEFAULT)
UNBOUNDED FOLLOWING: 마지막까지
N FOLLOWING: N 이후까지

윈도우 함수 종류

순위 관련 함수

RANK(특정 값) WITHIN GROUP: 특정 값에 대한 순위 확인

RANK() OVER(): 내가 평소에 생각하던 랭킹 시스템. → ORDER BY절 필수

DENSE_RANK() OVER(): 1등이 여러 명이더라도 그 다음 순위가 2등

ROW_NUMBER() OVER(): 그냥 나열한 순서대로.. 1순위가 두 명이어도 순서대로, 1순위 2순위

LAG() OVER(): 이전 값

LEAD() OVER(): 이후 값

주의 : DEFAULT는 처음부터 현재행까지임

FIRST_VALUE() OVER(): 처음 값

LAST_VALUE() OVER(): 마지막 값

NTILE(특정 값) OVER(): 특정 값이 2이면 컬럼들을 2개로 분리

TOP N QUERY → 페이징 처리를 효과적으로 수행하기 위해 사용

추출 방법

ROUNUM

RANK

FETCH

계층형 질의

기본 골격

SELECT

FROM 테이블명

START WITH 시작 조건

CONNECT BY PRIOR 연결조건; // A = B 이면 상위레벨의 A 와 하위레벨의 B가 같은 것을 찾으면 됨

현재 읽은 컬럼을 지정하는 구문 → PRIOR

PIVOT과 UNPIVOT

PIVOT: LONG DATA → WIDE DATA

UNPIVOT: WIDE DATA → LONG DATA

PIVOT 기본 골격

SELECT * FROM 테이블명 또는 서브쿼리

PIVOT (VALUE 컬럼명 FOR UNSTACK 컬럼명 IN (값1, 값2, 값3));

STACK 컬럼은 FROM절에서 선언한 컬럼 중 VALUE와 UNSTACK컬럼을 제외한 모든 컬럼!!!

따라서 FROM절을 반드시 제한해줘야 함! 에러는 아님....

UNPIVOT 기본 골격

SELECT * FROM 테이블명 또는 서브쿼리 // UNPIVOT은 여기를 굳이 제한할 필요는 없음

UNPIVOT (VALUE 컬럼명 FOR STACK 컬럼명 IN ("값1", "값2", ... )); // 컬럼 이름은 문자이므로 쌍따옴표로 전달

// 단, 대명사는 쌍따옴표 붙이지 않음!!!

정규 표현식

SQLD 정리...

macdduck — Fri, 23 Aug 2024 20:00:24 +0900

2. SQL 기본

NULL과 사칙연산은 NULL return;

NULL과 비교연산은 FALSE return;

2. SQL 활용

2-9 서브쿼리 → 서브쿼리 절에 ORDER BY 사용 불가!

1. WHER절 서브쿼리

단일행 서브쿼리(서브쿼리 결과가 1개)
다중행 서브쿼리(서브쿼리 결과가 여러 개)
다중컬럼 서브쿼리(서브쿼리 결과와 여러 컬럼 비교, 대소비교 불가)
상호연관 서브쿼리(메인과 서브 비교)

2. 인라인뷰(FROM절에서 테이블처럼 사용)

3. 스칼라(SELECT절에서 컬럼처럼 사용)

→ 결과는 '단일행' 서브쿼리 형태

→ 데이터가 NULL일 때 생략 없이 출력 like OUTER 조인

2-10 집합 연산자

1. 합집합

UNION → 중복 제거
UNION ALL

2. 교집합

INTERSECT

3. 차집합

MINUS

4. 주의 사항

컬럼 수, 순서, 타입 일치해야 사용 가능
컬럼 사이즈(행의 수, 데이터 길이) 등은 달라도 OK
맨 뒤에는 가능하나, 첫 번째에 ORDER BY 사용 불가!

2-11 그룹 함수 → NULL은 무시하고 연산!

GROUP BY절에 나오는 함수

1. GROUPPING SETS(A, B, ...)

A별, B별 그룹 연산 출력

UNION ALL로 대체 가능 → SELECT절에 NULL 필요

2. ROLLUP(A, B)

A, (A, B), 전체로 묶음! 따라서 순서 중요

마찬가지로 UNION ALL로 대체 가능. 필요한 부분 NULL로 채움

3. CUBE(A, B)

A, B, (A, B), 전체로 묶음!

GROUPING SETS(A, B, ...)로 대체가능

UNION ALL로도 대체가능

2-12 윈도우 함수

순위 관련 함수

1. RANK WITH GROUP

2. RANK() OVER()

3. DENSE_RANK

4. ROW_NUMBER