bananackck

평화롭던 어느날.... 메일이 날라왔다...

심장이 쿵 했다. api key나 jwtToken을 github에 올리면 안되는 점을 알고는 있었지만, 신경쓸 겨를이 없었다. 사실은 귀찮아서 따로 빼지 않았던 거일 수도.....

로컬에서 작업한거라서 별로 문제 될 일은 없었지만 그래도 저 무서운 메일 제목을 보고 있자니... 당장 해결해야겠다 싶었다.

JWT에 대한 내용은 추후에 작성하겠다.

JWT secret key

JWT token을 서명하고 검증하는 데 사용되는 비밀 키를 의미한다.

JWT란 공개 키와 비밀 키를 쌍으로 사용하여 토큰에 서명한다. 
브라우저가 유저를 인증하기 위해 사용하는 방식 중 하나이다. 

즉, 비밀 키이기 때문에 외부에 유출되면 안된다. 초보 개발자들이 간과하는 부분 중 하나인데, 무지성으로 git push를 날리다 보면 어느 순간 유출되있다... 이를 방지하기 위해서는 정신을 단디 차리고 이와 같은 secret key들은 따로 빼서 .gitignore에 추가해주자.

나는 spring boot 개발하다가 알람이 왔으니 spring boot + intelliJ 환경에서를 예시로 설명하겠다.

SpringBoot + intelliJ 에서 비밀 키 관리하기

1. application.properties에서 비밀 키 복사

먼저, application.properties에 아래와 같이 여러분의 비밀 키가 등록되있을 것이다. 

이 키를 복사 해두고, 여기서는 삭제하자.

...

//비밀 키
jwt.secret=secretsecretsecretsecretsecretsecretsecretsecretsecret
jwt.expiration-ms=86400000

...

2. application-secret.properties에 복사

보안 이슈가 있는 값들만 저장해 놓을 application-secret.properties 를 따로 만들어서 비밀 키를 복사해준다.

//비밀 키
jwt.secret=secretsecretsecretsecretsecretsecretsecretsecretsecret

3. .gitignore에 application-secret.properties 추가

application-secret.properties의 경로가 .gitignore와 같으면 파일명만 추가한다.

...
application-secret.properties

다른 경로에 있다면 경로까지 포함해준다. 아래는 내 예시이다.

...
src/main/resources/application-secret.properties

굿! 이제 push 를 하나 날려보면! 비밀 키가 안전하게 분리 된 것을 볼 수 있다.

4. 코드에 적용 확인

마지막으로 정의한 jwt.secret 이 실제 코드에서 잘 사용되고 있는지 다시 확인하자.

@Value의 설정 값을 plain secret key를 적어놓으면 말짱 도루묵이다.

   ...
    @Value("${jwt.secret}")
    private String secretKey;
   ...

+ GitGuardians

위에서 언급한 나에게 메일 경고를 쏴주었던 데가 바로 GitGuardians다. 

내 git repository의 보안을 위해서 미리미리 가입해주면 좋을 것 같다.

아래와 같이 내 리포지토리 중 보안 정보가 유출되있는 리포지토리를 보여준다.

그리고 해당 소스에 들어가면, 어느 commit, 어느 코드에서 정보 유출이 언제 일어났는지 아주 친절하게 알려준다!

커뮤니티 백엔드 코드를 작성하고 있다. 일단 넓게 고려하지 않고, 삭제 요청을 DELETE로 처리했다. 

다만, 삭제된 댓글이나 게시물을 복구하고 싶을 수도 있고, 그보다도 삭제된 엔드포인트를 참조하면 404 에러가 뜬다.()

물론 맞는 로직이지만, 왠지 404에러가 뜨면 기분이 좋지 않다....

그래서 찾아보게 된 것이 soft delete이다. 개념은 알고 있었는데 hibernate 기능으로 @SoftDelete가 있다는 희소식을 발견했다!! 대박이다.

사실 결론적으로 이번 프로젝트에서는 soft delete를 안하기로 했다. 규모가 작은 서비스이기도 하고, 데이터를 사용자 개인나 히스토리에 남기지 않기 때문이다.

Soft Delete(논리 삭제)

디비에서 데이터를 삭제 ❌

 ➡️ 사용자 입장에서 접근 권한 해제. 디비에는 여전히 데이터가 남아 있음.

ex. is_deleted 칼럼을 만들어 세팅

UPDATE `user`
SET is_deleted = TRUE
WHERE id = ##;

  <사용 이유>

  보통 삭제 프로세스 이후에도 데이터가 필요할 때 용이하게 쓰인다.

• 데이터 복구 용이
• 기록 보관 (사용자 기록을 통한 서비스 개선, 학습, 분석)
• 다른 테이블과의 외래 키 관계가 끊기지 않게 함. ➡️ 참조 무결성 유지
• DELETE 쿼리가 UPDATE 쿼리보다 느림.(트랜잭션이나 삭제 작업이 빈번한 서비스에서는 유의미한 성능 차이를 보임)

🌷트랜잭션 (Transaction)
디비의 상태를 변화시키기 위해서 수행하는 작업 단위(사용자 기능 기준)
- 원자성, 일관성, 독립성, 지속성 을 지녀야 함.

  <단점>

  삭제 프로세스가 끝나도 디비에는 데이터가 남아있기에 테이블 크기와 인덱스가 불필요하게 커질 수 있다. 또한 캐시나 메모리 상에 남아있는 데이터도 증가하여 메모리 사용량이 늘어날 수 있다.

@SoftDelete

클래스 위에 @SoftDelete 를 써주면 삭제상태를 처리하는 컬럼이나 클래스 변수가 없어도 자동으로 boolean 타입의 deleted 컬럼이 생성된다.

삭제 진행 시 자동으로 UPDATE 쿼리가 나간다. 

@SoftDelete

//또는...
@SoftDelete(converter = 사용중인컨버터.class, columnName = "컬럼명지정가능")

참고

https://sundries-in-myidea.tistory.com/165

import * 와 같이 *(aestrick)를 사용해서 패키지나 클래스를 가지고 오는 것을 와일드 카드 import라고 한다. 자바, SQL 등 에서 가끔 보인다. 단순히 생각했을 때는 그럼 모든 import의 상위호환아니야? 라고 생각할 수 있지만, 위험한 생각이다. 그럼 와일드 카드 import가 왜 쓰이는지. 왜 권장하지 않는지 알아보자.

와일드카드 Import

*(aestrick)를 사용해서 패키지의 하위 클래스들을 모두 import 해 온다. 

import java.util.*

위처럼 사용하면 util 내부의 모든 클래스를 가져올 수 있다. 

언뜻 보면 매우 편리한 기능같다.

하지만 와일드카드 import는 Google JAVA convention에서도 그렇고 지양하는 방법이다.

이에는 치명적인 단점이 있기 때문이다.

와일드카드 Import의 단점

🚨 클래스명 중첩 가능성

"다른 패키지에 같은 클래스명을 가진 클래스가 없다"를 보장할 수 없다.

즉, 같은 이름을 가진 클래스가 2개 이상이어서 오버라이딩이 발생할 수 있고, 이는 예기치 않은 오류 발생으로 이어진다.

와일드카드 Import에 대한 오해

위의 정의에서 "와일드카드 import는 패키지의 모든 클래스를 가져온다"라고 했지만, 실상 모두 메모리에 로드되는 것은 아니다.

🤔 1. 메모리 낭비가 발생한다?

NO!

- JVM이 클래스를 메모리에 로드하는 시점은 런타임이다.

- import는 컴파일 타임에 사용된다.

≫ import를 많이 사용한다고 해서 메모리 사용량이 늘어나지는 않는다.

🤔 2. 컴파일 시 클래스 매칭 시간이 오래 걸린다?

사실상 NO!

와일드카드를 쓰면 컴파일러가 해당 패키지에서 사용한 클래스만 찾는 작업을 한다. 

이론상으로는 매칭 시간이 오래 걸릴 것 같지만, 현대 컴파일러의 처리 속도나 IDE의 지원으로 사실상 무시 가능한 수준이다.

intelliJ에서 자동 와일드카드 import 설정 해제

intelliJ 설정(커멘드 + ,) -> 에디터 -> 코드 스타일 -> Java -> "'*'가 포함된 import 문을 사용하는 클래스 수" 100으로 설정(걍 큰 수로 설정)

ERD를 그리다가 VARCHAR 단위를 보게 되었다. VARCHAR은 CHAR과 어떤 점이 다를지 궁금해져서 조사해보았다.

sql에도 당연하게 데이터 타입이 존재한다. 언제 어떤 데이터타입을 사용하는게 좋을 지 정리해본다.

FLOAT

= 소수점 아래 7자리까지 부동 소수점 숫자 표현

(4바이트)

DOUBLE(REAL)

= 소수점 아래 15자리까지 부동 소수점 숫자 표현

(8바이트)

INT

= ±21억 까지의 정수

(4바이트)

CHAR(n)

= 값의 실제 크기와 관계없이 지정된 크기만큼의 저장공간 할당

(1 ~ 255바이트)

→ 실제 데이터의 크기와 선언된 데이터 크기의 편차가 클 경우 공간 낭비!

• 그냥 CHAR=CHAR(1)

VARCHAR(n)

= 값의 실제 크기만큼 저장공간 할당

(1 ~ 65535바이트)

→ 데이터 수정(UPDATE)시 빈번한 페이지 재정렬 발생 가능… 비효율적…

UPDATE 후의 데이터가 기존 데이터보다 크기가 클 경우, 기존 데이터 영역을 폐기하고 새로이 할당

→ 크기가 큰 varchar을 여러 개 사용하면 row size 제한에 걸린다. 데이터 전체가 row size에 영향을 준다.

→ 조회 요청이 여러번 오면 버퍼에 캐싱되어 읽어온다.

TEXT

= 값의 실제 크기만큼 저장공간 할당

(1 ~ 65535바이트)

→ 크기가 큰 text를 여러 개 사용해도 row size 제한에 걸리지 않는다.

데이터가 별도로 저장되고, 그 존재만 row size에 영향을 주기 때문에 9~12바이트만 row size에 영향을 준다.

→ 조회 요청이 여러번 오면 별도 저장된 데이터를 실제 공간만큼 할당하고 사용을 요청만큼 반복한다.

📌 VARCHAR vs TEXT

🌷 MySQL에는 string 타입이 없다!

DATETIME

= 'YYYY-MM-DD HH:MM:SS' 형식

(8바이트)

TIMESTAMP

= 'YYYY-MM-DD HH:MM:SS' 형식

(4바이트)

→ time_zone 시스템 변수와 관련이 있고 UTC 시간대 변환하여 저장

JSON

= JSON 문서를 저장

(8바이트)