미노드로그

[프론트] SPA(Single Page Application)

미노드 — Thu, 12 Feb 2026 21:40:47 +0900

프론트엔드가 SPA(Single Page Application, 단일 페이지 애플리케이션)로 구성된다는 것은 웹 애플리케이션에 필요한 모든 정적 리소스를 최초 접근 시 한 번만 다운로드하고, 이후에는 페이지 새로고침 없이 필요한 데이터만 비동기(AJAX)로 가져와 화면을 갱신하는 방식을 의미합니다.

전통적인 멀티 페이지 애플리케이션(MPA)과 달리, 앱(App)과 유사한 부드러운 사용자 경험을 제공하여 모던 웹 개발의 주류 패러다임으로 자리 잡았습니다.

1. SPA의 주요 특징 및 장점

빠른 사용자 경험(UX): 화면 전환 시 서버에서 HTML을 새로 받아오지 않고 화면의 일부분만 DOM 구조를 통해 교체하므로 네이티브 앱과 유사한 빠른 상호작용이 가능합니다.
서버 부하 감소: 웹 페이지 전체를 렌더링하는 대신, 데이터(JSON)만 서버에서 가져오기 때문에 서버의 부담이 줄어듭니다.
프론트-백엔드 분리: 프론트엔드(React, Vue 등)와 백엔드(API)가 명확히 분리되어 개발 효율성이 향상되고, 프론트엔드 개발자가 사용자 인터페이스에만 집중할 수 있습니다.
앱과 유사한 구조: 한 번 로드되면 페이지 이동이 없으므로, 하이브리드 앱 개발에 매우 적합합니다.

2. SPA의 단점 및 도전 과제

초기 로딩 속도: 처음에 HTML, CSS, JS 등 모든 리소스를 한 번에 다운로드하므로 초기 로딩 시간이 길어질 수 있습니다.
검색 엔진 최적화(SEO)의 어려움: 초기 HTML이 비어있는 쉘(Shell) 형태인 경우가 많아 검색 봇이 데이터를 수집하기 어렵습니다. (SSR 기술 등으로 해결 가능).
보안 이슈: 데이터가 클라이언트 사이드에서 처리되기 때문에, 비즈니스 로직이 노출되거나 API가 취약해질 수 있어 보안 대책이 중요합니다.

3. SPA 구현 기술 (2026 트렌드)

2026년 기준, SPA를 구현하는 대표적인 라이브러리와 프레임워크는 다음과 같습니다:

React: 가장 널리 사용되는 라이브러리로, 유연성이 높습니다.
Vue.js: 이해하기 쉽고 사용성이 좋습니다.
Angular: 대규모 엔터프라이즈 프로젝트에 적합한 강력한 프레임워크입니다.
Svelte/SvelteKit: 빠른 속도를 자랑하며 성능 중심 개발자들에게 인기가 높습니다.
Next.js/Nuxt: SPA의 SEO 문제를 해결하기 위해 SSR(Server Side Rendering)을 결합한 하이브리드 방식이 주류를 이룹니다.

4. SPA를 사용하기 좋은 경우

애플리케이션 내 상호작용이 많고(예: SNS, 대시보드), 빠르고 즉각적인 반응이 필요한 서비스.
사용자 데이터가 실시간으로 변경되는 경우.
네이티브 앱 형태로 전환을 고려하는 웹 서비스.

반면, 정적 콘텐츠 위주의 블로그나 SEO가 매우 중요한 사이트라면 SPA 대신 SSR(Server-Side Rendering)이나 SSG(Static Site Generation) 방식을 고려해야 합니다.

[프론트] 프론트 서버(BFF/SSR)

미노드 — Thu, 12 Feb 2026 21:39:33 +0900

1. BFF (Backend for Frontend)

BFF는 특정 프론트엔드(웹, 모바일 앱, 데스크톱 등)에 최적화된 맞춤형 백엔드 서버를 의미합니다.

배경: 마이크로서비스 아키텍처(MSA)에서 프론트엔드가 여러 백엔드 API를 직접 호출하면 데이터 가공이 복잡하고 비효율적인 문제를 해결하기 위해 등장했습니다.
역할:
- 데이터 통합 및 가공: 여러 마이크로서비스에서 데이터를 가져와 화면에 맞게 정리(API 오케스트레이션)하여 전달.
- 프론트 친화적 API: 프론트엔드 개발자가 원하는 구조의 API 제공.
- 보안/인증: 프론트엔드-백엔드 사이의 인증 로직, CORS 정책 등을 처리하여 클라이언트 사이드 보안 강화.
장점: 프론트엔드의 비즈니스 로직 복잡성 감소, 클라이언트별 최적화된 데이터 제공, API 변화에 대한 유연성.
단점: 클라이언트별로 BFF를 관리해야 하므로 복잡성 증가, 관리/유지보수 부담.

2. SSR (Server-Side Rendering)

SSR은 서버에서 페이지를 렌더링하여 완전한 HTML을 브라우저에 보내는 방식입니다.

배경: 클라이언트 사이드 렌더링(CSR)의 초기 로딩 속도 저하와 검색 엔진 최적화(SEO) 문제를 해결하기 위해 다시 주목받고 있습니다.
역할:
- 초기 페이지 렌더링: 사용자가 URL에 접속하면 서버에서 데이터를 받아 HTML을 미리 생성.
- SEO 향상: 검색 봇이 렌더링된 HTML을 쉽게 크롤링할 수 있어 검색 노출에 유리.
장점: 빠른 초기 로딩 속도(TTI, FCP 개선), 뛰어난 SEO.
단점: 서버 부하 증가, CSR 대비 페이지 이동 시 상호작용 속도가 느릴 수 있음.

3. BFF와 SSR의 관계 및 활용

현대적인 프론트엔드 서버는 종종 BFF와 SSR의 역할을 모두 수행합니다. 특히 Next.js가 그 대표적인 예입니다.

데이터 요청 및 렌더링: SSR을 통해 서버에서 데이터를 요청(BFF 역할)하고, 그 데이터를 사용하여 HTML을 렌더링(SSR 역할)합니다.
프론트엔드 개발자의 영역 확대: 과거 UI 구현에 집중했던 프론트엔드 개발자가 Node.js 기반의 BFF/SSR 서버를 직접 구축하고 관리하게 되었습니다.

요약하자면, BFF는 '데이터의 가공'에 집중하고, SSR은 '화면의 렌더링'에 집중하여, 두 기술 모두 프론트엔드 생산성과 사용자 경험(UX)을 극대화하는 데 사용됩니다.

[AWS] aws cli에서 사용하기 좋은 명령

미노드 — Tue, 10 Feb 2026 23:31:20 +0900

# EC2 ssm 연결가능한지 확인
aws ssm describe-instance-information \
  --region ap-northeast-2 \
  --filters Key=InstanceIds,Values=<새로운-instance-id>
### InstanceInformationList: []   이런식으로나오면 ssm연결불가능함

# 인스턴스에서 ssm agent 띄우는법
sudo dnf install -y amazon-ssm-agent
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent

# 이 인스턴스가 있는 VPC / Subnet / SG / IAM Instance Profile 확인
aws ec2 describe-instances \
  --region ap-northeast-2 \
  --instance-ids $INSTANCE_ID \
  --query "Reservations[0].Instances[0].{VpcId:VpcId,SubnetId:SubnetId,Az:Placement.AvailabilityZone,SGs:SecurityGroups[*].GroupId,IamProfileArn:IamInstanceProfile.Arn}" \
  --output json

# VPC에 SSM 관련 VPC Endpoint가 있는지 확인
VPC_ID=vpc-xxxx
aws ec2 describe-vpc-endpoints \
  --region ap-northeast-2 \
  --filters Name=vpc-id,Values=$VPC_ID \
  --query "VpcEndpoints[].{Id:VpcEndpointId,Service:ServiceName,Type:VpcEndpointType,State:State}" \
  --output table

# terraform console 로 현재 테라폼에서 사용가능한 변수 확인하기
terraform console
> var.enable_eks
> var.enable_bastion

# EC2 인스턴스에서 실행시 사용된 userData 스크립트 확인하기
aws ec2 describe-instance-attribute \
  --region ap-northeast-2 --instance-id i-02f4ba579ed76a1ea --attribute userData \
  --query "UserData.Value" --output text | base64 -d | head -n 80

# EC2 Console Output (중요, 많이씀)
# 커널 메시지,ㅡ, cloud-init 진행 로그 일부
# user_data에서 /dev/console로 찍은 로그
aws ec2 get-console-output \
  --region ap-northeast-2 \
  --instance-id i-xxxxxxxxxxxxxxxxx \
  --latest \
  --query "Output" \
  --output text | tail -n 200

[Webflux] 이해하기, webflux는 무엇인가?

미노드 — Tue, 23 Dec 2025 10:58:51 +0900

WebFlux로 “외부 HTTP 호출 → 응답 수신”을 할 때
스레드를 잡아두지 않고(Non-blocking), 데이터가 도착하는 이벤트에 반응해서 다음 단계로 흘려보내는 파이프라인으로 동작한다.
이 구조로 대기 기간이 없는 Nonblocking 방식의 통신을 지원한다.

Webflux 구성요소를 정리해보면 다음과 같다.

호출 주체: WebClient

반환 타입: Mono / Flux (응답을 담는 그릇)

외부 응답을 “값”으로 받는 게 아니라 “스트림”으로 받는다.
Mono: 응답 0~1개 (보통 단건 응답)
Flux: 응답 여러 개 (SSE/스트리밍/페이지 분할 등)

요청 구성에 필요한 것 준비

(1) URL / QueryParam
.uri("https://...") 또는 .uri(uriBuilder -> uriBuilder.path("/x").queryParam("a", 1).build())
(2) Method
.get() / .post() / .put() / .delete()
(3) Headers (인증/추적/콘텐츠 협상)
Authorization(Bearer/API-Key), Content-Type / Accept, Trace/Correlation-Id (로그 추적용)
(4) Body (POST/PUT)
JSON: .bodyValue(reqDto), Form: .body(BodyInserters.fromFormData(...)), 파일 멀티파트: MultipartBodyBuilder

응답 수신에 필요한 것들

(1) 상태코드 처리: retrieve() + onStatus(...)
(2) 바디 파싱: bodyToMono(...) / bodyToFlux(...)
(3) 타임아웃/리트라이/서킷브레이커 같은 “복원력”

Thread/Blocking 규칙: “절대 막지 말기”

WebFlux 에서 가장 중요한 단 하나:
.block(), .join(), JDBC 같은 블로킹 호출을 같은 체인에서 섞으면 WebFlux의 장점이 깨짐
왜냐면 WebFlux는 이벤트 루프 기반이라, 블로킹이 들어오면 이벤트 루프 스레드를 점유해버려서 전체 처리량이 떨어진다.

가능하면 R2DBC(DB), reactive driver를 쓰는 게 정석

“내 서비스”에서 컨트롤러까지 이어지는 형태

외부 호출 결과를 WebFlux 컨트롤러가 그대로 리턴할 때의 이상적인 흐름:

Controller는 Mono를 반환

Service는 WebClient로 외부 호출하고 Mono로 반환

중간에 매핑/검증/에러처리/로깅을 map/flatMap/onErrorMap/doOnNext 등으로 체이닝

즉, “받은 다음 처리”가 아니라 “받으면 처리하도록 선언”하는 스타일.

필수인 부가 요소

외부 호출은 “호출 성공” 뒤에 필요할 수 있는 요소

로깅/트레이싱: request-id, response time, status 기록

메트릭: 성공/실패/latency

에러 모델링: 외부 에러를 내부 에러코드로 매핑 (예: PG 오류 → 우리 도메인 에러)

논블로킹(Non-blocking)이란?
“기다림 자체가 없다”

스레드가 I/O 대기 때문에 멈추지 않음

“데이터 준비됨” 이벤트가 올 때만 처리

보통 이벤트 루프(Event Loop) 구조

WebFlux에서의 논블로킹
WebFlux는:

요청 N개 = 소수 이벤트 루프 스레드

외부 API 대기 중에도 스레드는 놀지 않음

비동기: 언제 올지 모르는 결과를 Mono/Flux로 표현

논블로킹: 그 결과를 기다리느라 스레드를 묶지 않음

WebFlux: 비동기와 논블로킹을 동시에 강제하는 모델

기존 MVC에서는

요청 1개 = 스레드 1개

외부 API 1초 지연 → 스레드 1초 점유 (대기, blocking)

비동기로 할 수 있지만, 대기가 필요할 수 있어 논블로킹은 아니다.

[HTML] CSRF 가 무엇?

미노드 — Wed, 10 Dec 2025 15:46:49 +0900

1. CSRF(Cross-Site Request Forgery)가 무엇인가?

“유저의 브라우저를 속여서, 유저가 의도하지 않은 요청을 서버로 보내게 만드는 공격”

예시로 이해해보자

사용자가 A사이트(admin.example.com)에 로그인했음
→ 브라우저에는 JSESSIONID 같은 쿠키가 저장됨
사용자가 악성 사이트 B를 방문
그 사이트가 숨겨진 HTML을 자동 제출함:

<form action="https://admin.example.com/user/delete" method="POST"> <input type="hidden" name="userId" value="100"> </form> <script>document.forms[0].submit();</script>

4. 브라우저는 자동으로 쿠키(JSESSIONID)를 붙여서 A 서버로 요청을 보냄

→ 서버는 "정상 로그인된 사용자"라고 착각하고 요청을 처리함

즉, CSRF는 ‘브라우저가 자동으로 쿠키를 요청에 넣는 동작’을 악용한 공격이다.

2. Spring Security csrf()의 역할

Spring Security는 기본적으로 CSRF를 방어하기 위해 아래 조건을 확인함:

POST/PUT/PATCH/DELETE 같은 요청이 올 때
요청 안에 CSRF Token이 있는지 검사
없으면 요청을 차단

즉, CSRF Token 체계를 강제하는 장치.

3. csrf().disable() → false 로 바꿔서 끌 때의 효과

true = CSRF 보호 활성화 (기본값)

HTML Form 기반 프로젝트에서 필요
다음 조건 충족해야 요청 허용됨:
- 요청에 CSRF 토큰 존재
- 토큰이 서버에 저장된 값과 일치

❗ HTML form 에 hidden input으로 _csrf 값을 넣어야 함
❗ REST API 클라이언트(axios, fetch)는 매 요청마다 헤더로 CSRF 토큰을 보내야 함

❗ false = CSRF 보호 비활성화 (csrf().disable() )

토큰 검사 없음
서버는 POST/PUT/DELETE 요청을 그대로 허용함
브라우저 쿠키 기반 인증이면 매우 위험해짐 → CSRF 공격에 취약

4. CSRF를 꺼도 안전한 경우 (핵심 이해 포인트)

JWT 기반 인증 + Authorization Header 사용

JWT가 쿠키에 들어가지 않고, 매 요청마다 이렇게 보낸다면:

Authorization: Bearer <jwt>

➡️ 브라우저는 자동으로 Authorization 헤더를 넣지 못함
➡️ 공격자가 악성 페이지에서 요청을 보내도 JWT를 실을 수 없음
➡️ CSRF 자체가 성립하지 않음

5. CSRF를 반드시 켜야 하는 경우

세션 기반 로그인(JSESSIONID 사용)

Cookie: JSESSIONID=abc123

이런 형태라면 브라우저는 자동으로 쿠키를 첨부함 → CSRF 성립
→ 반드시 CSRF를 켜야 함

JWT를 쿠키에 저장하는 경우

토큰이 쿠키로 내려온다면:

Cookie: accessToken=eyJhbGciOi...

이 경우도 쿠키는 자동 첨부되므로 CSRF 공격 가능

6. 핵심 요약 (가장 중요한 4줄)

CSRF는 브라우저가 쿠키를 자동으로 보내는 특성을 악용한 공격이다.
CSRF true(=보호 ON) → POST/PUT/DELETE 는 반드시 CSRF 토큰 검증 필요.
CSRF false(=보호 OFF) → 토큰 검사 없이 요청 허용 → 쿠키 기반 인증이면 매우 위험.
JWT를 쿠키에 저장하지 않고 Authorization 헤더로만 사용한다면 CSRF는 성립하지 않으므로 disable이 안전하다.

[암호] aes, sha 알고리즘의 특징

미노드 — Tue, 25 Nov 2025 13:27:20 +0900

업무를 진행하며 암호화 알고리즘으로 어떤 것을 선택해야 할지 판단 기준이 모호하고 어려운 부분이 있어 이부분에 대해 정리하고 넘어가려고 한다.

1. AES (Advanced Encryption Standard)

→ 대칭키 암호화 알고리즘

암호화·복호화에 동일한 키를 사용한다.
데이터를 숨기는 용도(기밀성).
블록 단위로 데이터를 암호화한다. ( 128bit, 192bit, 256bit 키 지원 )
키 길이가 길수록 안전하지만 연산량이 약간 증가
AES-256은 현재 전 세계적으로 가장 강력한 표준 대칭키 암호

1.1 동작 방식(운용 모드)

블록암호라 “어떻게 묶어서 암호화할지” 모드가 중요함.

ECB: 블록 반복 노출 → 보안 취약 (실무에서 금지)
CBC: 초기화 벡터(IV) 필요, 패딩 필요 (AES/CBC/PKCS5Padding)
GCM: 암호 + 무결성 검증까지 제공 → 최신 표준
CTR: 패딩 불필요, 병렬처리 빠름

1.2 장단점

✔ 장점

매우 빠름
대용량 데이터 처리 적합
하드웨어 가속(AES-NI) 지원으로 성능 뛰어남

✔ 단점

키 관리가 어렵다(같은 키를 양쪽 모두 안전하게 보관해야 함)
키가 유출되면 복호화 가능 → 기밀성 완전히 붕괴

2. SHA (Secure Hash Algorithm)

→ 해시 함수 / 단방향 함수

입력 데이터를 고정 길이의 해시값으로 변환
절대 복호화 불가능(단방향)
→ 암호가 아니라 지문 만드는 방식, 역함수가 없어 복호화 불가능
→ 레인보우 테이블(Rainbow Table)
데이터가 바뀌었는지 확인(무결성)
비밀번호 저장(평문 대신 해시 저장)
디지털 서명·토큰 생성(JWT 등)

2.1 해시 함수 종류

SHA-1 (취약) — 사용 금지
SHA-256 — 가장 널리 사용되는 표준
SHA-384, SHA-512 — 더 긴 해시값 제공

2.2 해시 함수 특성

동일 입력 → 항상 동일 해시값 출력 (Deterministic)
입력 조금만 바뀌어도 완전히 다른 값 출력 (Avalanche 효과)
해시값으로 원래 데이터 복원 불가
충돌이 발생하기 어려움

2.3 장단점

빠르고 단순
데이터 무결성 체크에 최적
저장 공간 적게 사용(고정 길이)

암호화가 아니므로 데이터 보호 불가능
단독으로 비밀번호 보호에 쓰면 위험 → 단순 SHA-256(password) 금지
→ 반드시 salt + 반복 횟수 필요 (PBKDF2, bcrypt, scrypt)

2.4 Salt

?? **Salt(솔트)**는 해시(Hash) 과정에 섞어 넣는 임의의 랜덤 문자열.
SHA-256 같은 해시는 같은 입력 → 같은 출력이라는 특징 때문에, 보안에서 취약점이 생기는데, 이를 막기 위한 필수 요소가 바로 salt
- Salt가 추가되면 이렇게 바뀐다. (즉 기존의 hash값으로 찾는게 불가능해진다. 미리 계산된 값으로 추적 불가능)
SHA256("123456" + salt1) → 8fa1...
SHA256("123456" + salt2) → c21e...

1) 사용자별로 다른 salt를 사용, salt는 각 계정마다 랜덤 생성하는 게 원칙.
2) salt는 비밀키가 아니며, 평문으로 DB에 저장해도 괜찮다.
salt의 목적은 비밀번호 패턴을 깨뜨리는 것이지 감추는 게 아님.
3) 길고 예측불가능해야 한다. (8~16바이트 이상 랜덤값 사용.)
4) 반복 연산(PBKDF2/bcrypt/argon2)과 함께 써야 더욱 안전
SHA-256 단독 + salt → 여전히 빠르기 때문에 공격자도 빨리 계산 가능
➡ 그래서 bcrypt / PBKDF2 / Argon2 같은 “느린 해시 함수”를 사용해야 안전함.

비교 요약

구분	AES	SHA
유형	대칭키 암호화	해시 함수
목적	데이터 기밀성	무결성, 비밀번호 해싱
키 존재	있음(암호화·복호화 동일 키)	없음
역변환	가능	불가능
출력 길이	입력 크기와 동일(암호문)	고정 크기(예: 256bit)
사용 예	파일 암호화, TLS, DB 암호화	JWT, 비밀번호 저장, 체크섬

3. 언제 AES, 언제 SHA?

AES 사용해야 할 상황

DB에 중요한 값을 암호화해야 함
통신 데이터를 암호화해야 함
파일을 저장하는데 외부 유출 위험이 있음
➡ 복호화가 필요한 데이터

SHA 사용해야 할 상황

비밀번호 저장
데이터가 변경되었는지 검증
토큰 서명(JWT의 Signature 부분)
➡ 복호화가 필요 없는 데이터

참고, Spring Security 표준 암호화 방식인 BCrypt 도 단방향 암호화, 해시 방식.

Spring Security 기본 PasswordEncoder는 BCryptPasswordEncoder

장점

자동 솔팅(salt 포함)
비용(cost factor)로 연산 난이도 조절 가능
무차별 대입 공격에 강함
Java/Spring 진영에서 가장 널리 사용됨

Spring Security 5+에서는 PasswordEncoderFactories.createDelegatingPasswordEncoder() 의 기본 알고리즘이 {bcrypt} 로 되어 있음 → 표준 채택이라는 의미.

집사고나서 나가는 세금 정리하기, 취득세부터 재산세 등

미노드 — Fri, 10 Oct 2025 23:15:59 +0900

현재 2025년 10월 기준, 집을 살 때, 보유하고 있을 때, 팔 때, 상속할 때 들어가는 세금에 대해 정리해보자.

만약 집을 사게된다면 내가 알아서 세금을 납부하지 않으면 문제가 생길 수 있을 것이다보니 공부하기 위해 정리해둔다.

내돈은 내가 지켜야한다.

1. 집 살때, 매매할 때 세금

구분	세목명	설명	주요 세율 / 계산 기준
① 취득세	부동산을 취득할 때 내는 지방세	집을 매매·증여·상속 등으로 소유권을 취득할 때 부과됨 중요, 취득세는 대출이 안된다. 이거 감안해서 대출해야한다.	- 일반 주택: 1~3% (누진세) • 6억 이하: 1% • 6억~9억: 2% • 9억 초과: 3% - 조정대상지역 2주택: 8% - 조정대상지역 3주택 이상: 12% ※ 현재 서울전역, 경기 일부 지역은 조정대상지역이다. - 비조정대상지역 1~2주택 : 1~3% - 비조정대상지역 3주택 : 8% - 비조정대상지역 4주택 12.4~13.4% - 오피스텔·상가: 4.6% (지방교육세 포함)
② 농어촌특별세 / 지방교육세	취득세의 부가세	취득세의 일정 비율로 추가	보통 취득세의 10~20% 수준
③ 인지세	매매계약서 작성 시	부동산 매매계약서에 붙이는 세금	거래금액별로 정액 • 1억~10억: 15만 원 • 10억 초과: 35만 원
④ 중개보수(수수료)	세금은 아니지만 실비로 발생	부동산 중개업소 이용 시	매매금액의 0.4~0.9% 이내 (상한표 있음)

2. 집 사고나서, 보유하고 있을 때 세금

구분	세목명	설명	세율
① 재산세	매년 6월 1일 기준 소유자에게 부과 1년에 2번 (7월 / 9월) 납부 가능	지방세로 시·군·구에 납부 가장중요 "재산세"안내려고 6월1일 전에 판매하는 사람도있음.	- 과세표준 × 0.1~0.4% • 6억 이하 0.1% / 6~15억 0.15% / 15억 초과 0.4% - 7월, 9월 2회 분납
② 지방교육세	재산세의 부가세 재센세 낼때 포함해서 납부	재산세의 일정 비율	재산세의 20%
③ 종합부동산세(종부세)	일정 금액 이상의 부동산을 보유한 경우 매년 부	국세 (국세청 부과)	- 공시가격 합산 12억 초과 (1주택자 기준) - 세율: 0.5~6.0% (누진) - 1주택자 기준 공시가격 12억 원 이하는 비과세
④ 임대소득세	임대 수익 발생 시	월세·전세보증금 간주이자 등	- 연 2천만 원 이하: 분리과세 14% - 초과: 종합소득세 누진세율 적용 (6.6~45%)

3. 집 팔때, 나가는 세금

양도세는 중요한데, 양도세때문에 팔때 차익보다 더 나가는 경우도 있다.

구분	세목명	설명	주요 세율
① 양도소득세 (양도세)	부동산을 팔아서 이익이 발생할 때	“양도차익 = 양도가 - 취득가 - 필요경비”로 계산	- 기본세율: 6~45% 누진 - 1주택자 비과세 요건 (보유하고 거주까지 해야함.) • 12억 미만 주택 • 2년 이상 보유 • 실거주 2년 (조정지역) - 단기 양도 시 중과 • 1년 미만: 70% • 2년 미만: 60%
② 지방소득세	양도소득세의 부가세	양도소득세의 10%	예: 양도세 1천만 원이면 지방소득세 100만 원
③ 중개보수 / 법무사비용	세금은 아니지만 발생	매도 시에도 부담 가능

4. 상속할 때, 물려줄 때 세금

구분	세목명	설명	주요세율
① 상속세	사망으로 재산이 이전될 때 부과	피상속인의 재산 전체 대상	- 과세표준 = (총재산 - 공제액) - 기본공제 5억 원 (배우자 등 추가공제 가능) - 세율: 10~50% 누진, 상속되는 비용에 따라 누적됨
② 증여세	살아있을 때 재산을 무상 이전	배우자·자녀 등 증여 시	- 공제한도 • 배우자 6억 / 자녀 5천만 / 부모→자녀 5천만 / 미성년자 2천만 - 세율: 10~50% 누진
③ 취득세(2차)	증여·상속으로 인한 소유권 이전 시	상속·증여받은 사람이 냄	- 상속: 0.8~2.8% - 증여: 3.5~4.6%

[AWS] EKS kubernetes RBAC 권한이 없는 문제 해결하기.

미노드 — Tue, 25 Feb 2025 16:12:05 +0900

eks를 만들었는데 eks의 내부 정보를 확인할 수 없다...

클러스터 노드의 메트릭정보나 pod정보를 확인할 수 없었다.

어떤 권한을 추가해도 해결할 수 없었는데, 해결방법은 직접 eks에 들어가 auth 정보를 추가해서 RBAC 권한을 획득하는 것이다.

방법은 2가지인데, 아래처럼 eks의 aws-auth Config-Map 에 Role 정보나 IAM 사용자 정보를 추가해주면 된다.

kubectl get configmap -n kube-system

를 해보면 config-map 정보가 나오는데 여기서 aws-auth 정보를 갱신해주면 된다.
kubectl edit configmap aws-auth -n kube-system

아래처럼 수정하면 aws Console에서도 확인 가능하다.

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::430223317801:role/ec2-role-bootstrap-role
      username: system:node:{{EC2PrivateDNSName}}
  mapUsers: |
    - userarn: arn:aws:iam::430223317801:user/rcsp_jhbae_admin
      username: rcsp_jhbae_admin
      groups:
      - system:masters
kind: ConfigMap
metadata:
  creationTimestamp: "2025-02-24T05:28:40Z"
  name: aws-auth
  namespace: kube-system
  resourceVersion: "311297"
  uid: f5ae0fd2-ac35-4ca8-a82a-28999bc1a697

수정하게되면, 아래처럼 알림 창이 사라진다.

aws 콘솔에서 노드 정보도 보이게되며, 리소스 확인도 가능해진다.

[Mysql] DBeaver 덤프 옵션 정리

미노드 — Tue, 4 Feb 2025 10:20:26 +0900

DBeaver로 덤프 파일을 만드려고 하는데, 옵션 설명이 모호하여 한번 정리하려고 한다.

DB마다 비슷비슷하게 제공하는 옵션들이 각기 다른 이름으로 존재한다.
이를 인터페이스 형식으로 공통된 이름으로 풀어서 DBeaver가 제공하는걸로 보인다.

옵션은 총 9개가 있다.

No CREATE statements
Add DROP statements
Disable keys
Extended inserts
Dump events
Additional comments
Remove DEFINER
Dump binaries in hex
Structure only

1. No CREATE statements

설명
테이블을 생성하는 CREATE TABLE 문을 포함하지 않음.
즉, 테이블의 구조(Schema)는 내보내지 않고, 데이터(INSERT INTO)만 덤프 파일에 포함됨.
사용 예시
- 이미 동일한 테이블이 존재하는 환경에서 데이터를 덤프할 때
- 동일한 구조의 테이블에 데이터만 추가하려는 경우
결과 예시 (옵션 활성화 시)
sql

INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com');

2. Add DROP statements

설명
덤프 파일에 DROP TABLE 문을 추가하여, 백업 복원 시 기존 테이블을 먼저 삭제한 후 다시 생성하도록 함.
사용 예시
- 덤프를 복원할 때 기존 데이터를 유지하지 않고 새로 덮어씌우고 싶을 때
- 기존 테이블과 충돌을 방지하기 위해 삭제 후 새로 생성하려는 경우
결과 예시 (옵션 활성화 시)
sql

DROP TABLE IF EXISTS `users`; CREATE TABLE `users` ( `id` INT PRIMARY KEY, `name` VARCHAR(255), `email` VARCHAR(255) );
INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com');

3. Disable keys

설명
ALTER TABLE ... DISABLE KEYS; 문을 포함하여, 테이블의 인덱스를 비활성화한 후 데이터를 삽입한 다음 다시 활성화함.
대량 데이터 삽입 시 성능을 향상시킬 수 있음.
사용 예시
- 많은 데이터를 한 번에 삽입해야 할 때
- 테이블의 인덱스를 재구성하여 성능을 최적화할 때
결과 예시 (옵션 활성화 시)
sql

ALTER TABLE `users` DISABLE KEYS; INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com');
INSERT INTO `users` (`id`, `name`, `email`) VALUES (2, 'Bob', 'bob@example.com');
ALTER TABLE `users` ENABLE KEYS;

4. Extended inserts

설명
INSERT 문을 하나씩 실행하는 것이 아니라 여러 개의 행을 한 번에 삽입하는 INSERT INTO ... VALUES (...), (...), (...) 방식으로 덤프를 생성함.
파일 크기를 줄이고, 덤프 복원 속도를 개선할 수 있음.
데이터가 너무 많을경우 안하는게 나을수도있음.
사용 예시
- 데이터베이스 덤프 파일의 크기를 줄이고 싶을 때
- 백업 복원 속도를 높이고 싶을 때
결과 예시 (옵션 활성화 시)
sql

INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com'), (2, 'Bob', 'bob@example.com'), (3, 'Charlie', 'charlie@example.com');

5. Dump events

설명
MySQL의 **이벤트(Event)**를 포함하여 덤프를 생성함.
이벤트는 특정 시간에 자동으로 실행되는 작업(예: 스케줄러 역할)임.
사용 예시
- MySQL에서 이벤트 스케줄러를 사용하고 있으며, 백업 시 포함해야 할 때
- 데이터 변경 작업을 자동화하는 MySQL 이벤트를 백업하고 싶을 때
결과 예시 (옵션 활성화 시)
sql
CREATE EVENT `my_event` ON SCHEDULE EVERY 1 DAY DO UPDATE users SET last_login = NOW() WHERE active = 1;

6. Additional comments

설명
덤프 파일에 추가적인 **주석(Comment)**을 포함하여, 각 부분의 역할을 명확히 설명함.
덤프 파일을 사람이 쉽게 읽고 이해할 수 있도록 도와줌.
사용 예시
- 백업 파일을 다른 사람이 확인해야 하는 경우
- 복원 시 중요한 정보를 쉽게 확인할 수 있도록 할 때
결과 예시 (옵션 활성화 시)
sql

-- 테이블 생성 CREATE TABLE `users` ( `id` INT PRIMARY KEY, `name` VARCHAR(255), `email` VARCHAR(255) );
-- 데이터 삽입 INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com');

7. Remove DEFINER

설명
DEFINER= 구문을 제거하여, 스토어드 프로시저(Stored Procedure), 트리거(Trigger), 이벤트(Event) 등을 덤프할 때 특정 사용자의 권한 정보가 포함되지 않도록 함.
사용 예시
- 다른 환경(예: 로컬 개발 → 운영 서버)으로 덤프를 이동할 때
- 특정 사용자 계정이 없는 환경에서도 덤프 파일을 실행할 수 있도록 할 때
결과 예시
➡ (옵션 활성화 전) sql
CREATE DEFINER=`root`@`localhost` PROCEDURE `my_procedure`()
BEGIN
SELECT * FROM users;
END;
➡ (옵션 활성화 후) sql

CREATE PROCEDURE `my_procedure`()
BEGIN
SELECT * FROM users;
END;

8. Dump binaries in hex

설명
BLOB(Binary Large Object) 또는 VARBINARY 같은 **이진 데이터(Binary Data)**를 16진수(Hex) 형식으로 덤프함.
일반적인 텍스트 덤프보다 복원 속도가 느려질 수 있지만, 이진 데이터를 정확하게 유지할 수 있음.
사용 예시
- 이미지, 파일, 비디오 등의 바이너리 데이터를 포함한 테이블을 백업할 때
- 데이터 손실 없이 정확하게 복원해야 할 때
결과 예시 (옵션 활성화 시)
sql

INSERT INTO `files` (`id`, `file_data`) VALUES (1,0xFFD8FFE000104A46494600010101006000600000FFDB0043);

9. Structure only

설명
테이블의 구조(Schema)만 덤프하고, 데이터(INSERT INTO)는 포함하지 않음.
사용 예시
- 데이터 없이 테이블 구조만 생성해야 할 때
- 새로운 환경에서 동일한 테이블을 만들고 데이터를 따로 삽입할 때
결과 예시 (옵션 활성화 시)
sql

복사편집

CREATE TABLE `users` ( `id` INT PRIMARY KEY, `name` VARCHAR(255), `email` VARCHAR(255) );

정리

No CREATE statements	CREATE TABLE 없이 데이터만 덤프	기존 테이블에 데이터 추가
Add DROP statements	DROP TABLE을 추가하여 테이블 삭제 후 복원	테이블 덮어쓰기
Disable keys	인덱스 비활성화 후 데이터 삽입	대량 데이터 삽입 최적화
Extended inserts	여러 행을 한 번에 삽입	백업 파일 크기 줄이기
Dump events	MySQL 이벤트 포함	이벤트 스케줄러 사용
Additional comments	SQL 주석 추가	문서화 및 가독성 향상
Remove DEFINER	DEFINER= 제거	사용자 계정 영향 방지
Dump binaries in hex	BLOB/VARBINARY 데이터를 HEX로 저장	이진 데이터 백업
Structure only	데이터 없이 테이블 구조만 저장	스키마 백업

나의 일반적인 선택은 이걸로

[CS] 직렬화(Serializable) 이해하기

미노드 — Wed, 2 Oct 2024 09:52:32 +0900

직렬화(serialize)란?

컴퓨터 과학의 데이터 스토리지 문맥에서 데이터 구조나 오브젝트 상태를 동일하거나 다른 컴퓨터 환경에 저장하고 나중에 재구성할 수 있는 포맷으로 변환하는 과정이다.
오브젝트를 직렬화하는 과정은 오브젝트를 마샬링한다고도 한다

조금 더 쉽게 풀어보면, Object 또는 Data를 바이트 스트림(stream of bytes) 형태로 연속전인(serial) 데이터로 변환하는 것을 직렬화(serialize) 라고 한다.
그 반대 개념인 역직렬화는(Deserialize)는 바이트로 변환된 데이터를 원래대로 Object 또는 Data로 변환하는 기술이다.

[ 바이트 스트림 이란? ]
스트림은 클라이언트나 서버 간에 출발지 목적지로 입출력하기 위한 데이터가 흐르는 통로를 말한다.
자바는 스트림의 기본 단위를 바이트로 두고 있기 때문에, 네트워크, 데이터베이스로 전송하기 위해 최소 단위인 바이트 스트림으로 변환하여 처리한다.

이펙티브 자바 에서도 다뤘던 내용인데 직렬화 는 되도록이면 피하는게 좋다고 했었다.
다만 직렬화를 사용해야 하는 경우가 있는데, 어떤 경우일까?
다른 컴퓨터의 시스템에서도 사용 할수 있도록 전송하기 위해 데이터 화 시켜야 할 경우(json으로 변환, xml로 변환, 기타 포멧의 파일로 변환) 직렬화를 사용한다.

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

출처 : infa dev

직렬화가 사용되는 경우

직렬화가 언제 필요하여 사용되는 것일까?

- 세션 클러스터링 처럼, 세션이 공유되어야 할 경우 (세션 데이터를 저장, 공유하려면 이를 데이터 화 해야 한다.)
- 캐시 DB (redis) 같이 데이터 화 시켜 저장해야 할 경우
- DB에 저장시켜야 할 경우
- 특정 format 파일로 변환하여 저장 할 경우 (json, csv, xml 등)

자바에서 직렬화 사용하면 장점

위의 작업들을 수행하려면 직렬화가 필요하다.
그렇다면 직렬화를 사용함으로 써 느낄 수 있는 장점은 어떤 것들이 있을까?

1.레퍼런스 타입에 대해 제약 없이 외부에 내보낼 수 있다.

이는 자바로 개발하는 프로그램이 다른 언어로 만들어진 어플리케이션과 호환이 가능하도록 해준다.
수신/송신 측면에서 모두 가능하다.

2. 자바 시스템에서 개발에 최적화 되어있다.

자바는 객체 지향 개발을 지향하며 개발하는데 최적화 되어있다.
프리미티브 타입(byte short int long float double char boolean)은 왠만한 프로그래밍 언어가 공통적으로 사용하는 타입이기 때문에, 이러한 값들을 JSON 으로도 충분히 상호 이용이 가능하다.

하지만 자바의 온갖 컬렉션이나 참조 타입(String), 클래스, 인터페이스 타입들은 어떨까?
사용자가 커스텀하게 값 타입을 만들어 사용하는 경우, 단순 파일 포맷만으로는 타입 갯수가 한계가 있다.
그래서 이들을 외부에 내보내기 위해선 각 데이터를 매칭시키는 별도의 파싱(parsing)이 필요하다.

여기서 직렬화를 이용하면, 비록 파이썬이나 자바스크립트와 같은 다른 시스템에서는 사용하지 못할 수도 있으나,
직렬화 기본 조건만 지킨다면 그냥 바로 외부에 보낼수가 있다.
그리고 역직렬화를 통해 읽어들이면 별도 파싱 작업 없이 데이터 타입이 자동으로 맞춰지도록 할 수 있다.
즉, 직렬화, 역직렬화를 통해 파일을 만들어 외부로 보내고, 다시 읽어들이는 과정에서 별도 파싱 작업 없이
자바 클래스로 만들어 기능들을 곧바로 다시 이용할 수 있는다.

그러나 결론만 이야기 한다면, 요즘은 범용적인 JSON을 이용하는 추세가 점점 늘고 있다.
자바 객체를 JSON으로 변경해서 파일로 써버리면 되고, 읽을 때 에도 이에 맞춰 받도록 하면 되는데 굳이 직렬화를 할 필요가 없을 수 있다.
따라서 JSON 이냐 직렬화 이냐 에 대한 명확한 정답은 없고 '목적에 따라 적절히 써야 한다' 정도로 정리한다.
이펙티브 자바 책에서도 직렬화의 대안을 찾으라고 나오기도 하니...
그리고 업무를 수행하면서 implements Serializable 를 보게 되었는데, 이거때문에 이 글을 쓰게 되었다.

참고 블로그

https://inpa.tistory.com/entry/JAVA-%E2%98%95-%EC%A7%81%EB%A0%AC%ED%99%94Serializable-%EC%99%84%EB%B2%BD-%EB%A7%88%EC%8A%A4%ED%84%B0%ED%95%98%EA%B8%B0