junse0 님의 블로그

NCP 인프라 기초

junse0 — Fri, 10 Jul 2026 17:15:02 +0900

0. 시작하며

이번 방학에 프로젝트를 진행하게 되면서 INFRA 분야에 대해 더 폭넓은 이해를 가지기 위해 스터디를 시작하게 되었다. 기존 AWS가 아닌 NCP에 대하여도 알아보기 위해 네이버 비즈니스 스쿨 커리큘럼을 보며 인터넷 강의를 수강하였다.

https://bizschool.naver.com/online/course/65189/lecture/1461898?currentTab=curriculum

Associate : 네이버클라우드 이해하기

네이버 비즈니스 스쿨

bizschool.naver.com

https://bizschool.naver.com/online/course/65148/lecture/1461736?currentTab=curriculum

네이버클라우드 인프라 구축은 어떻게 하는 걸까요? _ 데이터센터와 서버

네이버 비즈니스 스쿨

bizschool.naver.com

1. 가상화 기술

서버 가상화 - 하나의 물리 리소스 위에 여러 대의 VM이 독립적으로 구동됨.

Type 1(Native) - 하드웨어 위에 바로 하이퍼바이저가 올라가고, 그 위에 여러 개의 OS가 구동되는 구조. 대표적으로 젠이나, KVM이 해당된다.

전가상화 - 하드웨어를 모두 가상화함 => 게스트 OS가 직접 CPU에 하드웨어 제어 명령 가능

반가상화 - 하드웨어를 완전히 가상화하지 않음 => 게스트 OS가 하이퍼바이저에게 하드웨어 제어를 의뢰하는 구조.

Type 2(Hosted) - 하드웨어가 올라가고 그 위에 OS가 설치되고, 그 위에 하이퍼바이저가 구동되는 형태.

2. 클라우드를 사용하는 이유

1) 비용 절감

사용한 만큼만 지불하면 되므로, 기회 비용 최적화 등을 통해 비용 절감 가능
다양한 부가 상품 이용을 통해 개발 비용 절감

2) 빠른 Deploy

기존 Legacy 인프라에 비해 빠른 인프라 구성 시간

3) 글로벌 진출 시 용이

글로벌 리전 활용을 통해 글로벌 진출 시 빠르고 손쉬운 인프라 구성

4) 보안

인프라에 대한 보안은 클라우드 공급 엄체에 위임
다양한 보안 상품을 이용하여 보안 강화

3. 클라우드 구분

IaaS - 스토리지, 서버와 같은 인프라 리소스를 클라우드 형태로 제공 | Infra as a Service

PaaS - 플랫폼 형태로 제공, 그 위에 바로 개발 환경을 얹어서 사용할 수 있음 | Platfrom as a Service

SaaS - 완제품을 클라우드에서 사용할 수 있는 형태 | Software as a Service

Private Cloud - 기업 내부에 직접 클라우드를 구현하는 형태. 자체 데이터센터와 사내 인력을 대상으로 구현

Public Cloud - 누구나 사용할 수 있는 클라우드 형태. 클라우드 서비스를 제공하는 프로바이더에게 인프라가 존재하고, 프로바이더 엔지니어들이 담당하여 관리 => 초기 구축 비용 및 인프라 환경 운영에 대한 부담을 줄일 수 있음.

Hybrid Cloud - Private과 Public Cloud를 혼합하여 사용하는 형태

4. 네이버 클라우드 플랫폼에서 제공하는 서비스

서버 및 클라우드 서비스

AI 및 애플리케이션 서비스

보안 및 관리 서비스

5. 상품 의존성

리전(Region)

리전에 종속하는 리소스
다른 존에 있는 상품들 간에도 서로를 공유할 수 있음
VPC 상품
Object Storage, Archive Storage 상품
Init script 등

존(Zone)

Zone에 종속적인 리소스
Server, NAS, Block Storage 같은 IaaS 상품
Subnet 상품

전 세계

어느 리전에서나 동일하게 사용할 수 있는 리소스
Sub Account 상품
Global Traffic Manager 같은 리전 LB 상품
Safter, Checker 등의 Security 상품

멀티 존

Cloud DB 상품
Load Balancer 상품

6. IT 인프라 이해하기

1) IT 인프라 구성 요소

하드웨어 - 장비를 설치하기 위한 데이터센터 및 냉각시설, 서버, 스위치, 라우터 등

소프트웨어 - Windows 및 Linux 같은 운영체제(OS)를 포함하여, 아파치 같은 웹서비스, 미들웨어 등

네트워크 - 물리 단인 케이블, 스위치, 라우터, 네트워크 및 방화벽

2) IT 인프라 유형

On-Premise: 기업이 자체 데이터센터를 보유하고, 그 안에 서버와 네트워크 장비 등을 구축하고 자체적으로 운영하는 방식

Public Cloud: 인프라를 Cloud Service Provide(CSP)에서 구축하고 운영 및 관리, 어느 기업이든 클라우드 이용을 원한다면 CSP에서 제공하는 콘솔을 통해 필요한 리소스를 바로 생성하고 이용할 수 있음 => 운영하는 서비스에만 집중할 수 있음.

7. 인프라 구축

데이터 센터 - 서버, 네트워크 회선 등을 제공하는 건물 또는 시설. 냉각시스템이 존재.

서버 - 네트워크를 통해 클라이언트에게 정보를 제공하는 컴퓨터 시스템.
CPU, Disk, Network Interface Card가 중요 고려 요소.

CPU와 Memory 스펙은 서버 성능과 직결되는 중요 구성요소로, CPU에서는 클럭 속도와 core 개수를 보고, Memory는 처리할 데이터를 저장하는 공간으로 많을수록 좋다.

HDD - 자기 디스크 기반, 최근에 사용량 점점 떨어짐.

SSD - 플래시 메모리 기반, HDD에 비해 성능 우월하지만 가격이 더 비싸고 수명이 짧음.

RAID - 저장 장치 여러 개를 묶어 사용하는 기술로, 가용성과 고성능을 위해 사용됨.

네이버 클라우드 플랫폼 가상화 서버 제공 서비스

8. 마무리하며

이전에 AWS Cloud를 공부하며 클라우드에 대한 전반적인 공부를 한 경험이 있기에, 기초적인 인프라 내용에 대해서는 학습하는데에 어려움이 없었다. 아직 실습은 진행해보지 않았고, 이론만을 공부했기에 aws와의 차이점을 크게 느끼지 못했고, 플랫폼에서 제공하는 서비스의 형태나 사용 방법이 다른 것 같다. 실습을 통해서 네이버 클라우드 사용하는 방법과 제공하는 서비스에 대해 더 자세히 알아보고, 학습해보아야겠다.

다음 프로젝트를 진행할 때에는 AWS 대신 NCP를 이용해 배포해보는 경험을 해보아야겠다.

[Docker] Docker의 핵심 구조 이해하기

junse0 — Sat, 16 May 2026 16:28:36 +0900

Docker를 사용하는 이유에 대하여 학습한 것에 이어 핵심 구조에 대하여 이해해보는 시간을 가졌다.

1. Docker의 기본 아키텍처

Docker는 클라이언트(Client) - 서버(Host)의 구조로 동작한다. 사용자가 명령어를 입력하면 Docker 데몬이 이 명령어를 해석하고 실행하는 방식으로 동작한다.

● Docker Client: 사용자가 docker build, docker run 등의 명령어를 입력하면 REST API로 변환하여 데몬에게 전달. 로컬뿐만 아니라 원격에 있는 Docker 데몬도 제어할 수 있음.

● Docker Host(Daemon): API 요청을 수신하여 실제로 컨테이너를 관리하고 이미지, 네트워크, 볼륨 등을 생성하는 핵심 엔진(dockerd).

● Docker Registry: 이미지를 저장하고 공유하는 저장소 (ex. Docker Hub)

2. Docker의 3대 핵심 구성 요소

Docker의 3대 요소로는 이미지(Image), 컨테이너(Container), 레지스트리(Registry)가 있다.

● 이미지(Image)

- 여러 개의 Read-Only(읽기 전용) 레이어로 구성된다. Dockerfile의 각 명령어(FROM, RUN, COPY 등)는 새로운 레이어를 생성한다.

- 서로 다른 이미지라도 베이스 이미지가 같다면 해당 레이어를 공유하여 용량을 절약한다.

● 컨테이너(Container)

- 컨테이너를 실행하면 이미지 레이어 위에 아주 얇은 Container Layer(Read-Write)가 추가된다.

- 모든 변경 사항(파일 수정, 로그 등)은 이 쓰기 층에만 기록된다.

- 컨테이너가 삭제되면 이 레이어도 사라지기 때문에, 데이터를 영구 저장하기 위해서는 Volume이 필수적이다.

● 레지스트리(Registry)

- 이미지(Image)를 보관하고 배포하는 장소이다.

- 이미지를 push, pull 하는 등 공유한다.

● 동작 흐름

1. 소스 코드 작성: 애플리케이션 코드 작성

2. Dockerfile 정의: 코드를 실행할 환경(OS, 런타임, 환경변수)을 명시

3. CI(Build & Push): Github Actions나 Jekins 같은 도구가 코드를 이미지로 빌드하고 레지스트리에 업로드

4. CD(Pull & Run): 서버에서 최신 이미지를 내려받아 컨테이너 교체

3. Docker가 경량인 이유

Docker가 기존의 가상 머신(VM)보다 가벼운 이유는 커널을 공유하며 리눅스 자체의 기술을 사용하기 때문이다.

1) 레이어 저장 방식(Union File System)

Docker 이미지는 여러 개의 레이어(Layer)로 겹쳐져 있어 만약 이미지가 수정되어도 바뀐 부분만 새로운 레이어로 쌓이기 때문에 용량이 획기적으로 줄어들게 된다.

2-1) 격리 기술(Namespaces)

각 컨테이너가 독립된 공간(IP, 파일 시스템, 프로세스 ID 등)을 가진 것처럼 속이는 기술이다.

pid: 프로세스 번호 격리 (컨테이너 안의 1번 프로세스)
net: 네트워크 인터페이스 격리(컨테이너만의 고유 IP)
mnt: 파일 시스템 마운트 지점 격리
uts: 호스트네임 격리

2-2) 격리기술(Control Groups)

컨테이너가 사용할 CPU, 메모리 등의 자원 할당량을 제한하는 기술로, 호스트의 모든 CPU나 메모리를 점유하여 다른 프로세스에 영향을 주는 것을 방지한다.

4. Docker의 네트워크와 볼륨 (데이터와 통신)

1) Docker Network

Docker 네트워크는 격리된 컨테이너들이 서로 or 외부와 어떻게 연결되는지를 정의한다.

① 네트워크 드라이버 종류

Docker는 목적에 따라 여러 네트워크 모드를 제공한다.

Bridge(기본값): 동일한 Docker 호스트 내의 컨테이너들이 서로 통신할 때 사용하는데, docker0라는 가상 브릿지를 통해 각 컨테이너에 사설 IP가 할당된다.
Host: 컨테이너가 호스트의 네트워크 환경을 그대로 사용한다. 포트 포워딩 없이 호스트의 포트를 직접 점유하며, 네트워크 성능이 가장 빠르다.
None: 네트워크 연결을 아예 차단한다. 로컬 작업만 필요한 보안용 컨테이너에 사용한다.
Overlay: 여러 대의 Docker 호스트(Swarm 또는 클러스터)에 흩어져 있는 컨테이너들을 하나의 네트워크로 묶어준다.

② 포트 포워딩(Port Fowarding)

컨테이너 내부에서 도는 서비스(ex. 8080포트)를 외부 사용자가 접속할 수 있게 호스트의 포트와 연결하는 기술로, -p 80:8080으로 호스트의 80포트로 접속하면 컨테이너의 8080포트로 전달하게 한다.

2) Docker Volume & Mount

컨테이너의 파일 시스템은 컨테이너가 삭제되면 함께 사라지는데, 이를 방지하기 위해 호스트의 저장 공간을 컨테이너에 연결(Mount)하는 세 가지 방법이 있다.

① Volume(도커 관리형)

Docker가 직접 호스트의 특정 영역(/var/lib/docker/volumes)에 저장 공간을 만들어 관리한다.

● 특징: Docker의 명령어로 관리 가능하며, 호스트의 파일 시스템 구조에 의존하지 않아 가장 권장되는 방식이다.

● 장점: 여러 컨테이너가 안전하게 데이터를 공유할 수 있고, 백업 및 이동이 쉽다.

② Bind Mount(사용자 지정형)

사용자가 호스트의 특정 경로를 컨테이너 내부와 직접 연결한다.

● 특징: C:\Users\Project 같은 경로를 직접 지정할 수 있다.

● 장점: 개발 중인 소스 코드를 컨테이너에 실시간으로 동기화하여 바로 확인할 때 매우 유용하다.

③ tmpfs Mount(임시 저장형)

데이터를 디스크가 아닌 호스트의 메모리(RAM)에 저장한다.

● 특징: 컨테이너가 중단되면 데이터가 사라진다.

● 장점: 보안상 중요한 정보(비밀번호 등)를 저장하거나, 아주 빠른 입출력이 필요한 임시 작업에 사용한다.

5. 마무리하며

이번에 Docker에 대한 개념을 공부해보았으니, 다음에는 Spring Boot에서 Dockerfile을 작성하는 방법에 대해서 공부해보고 실제로 작성해보아야겠다. Dockerfile까지 작성할 수 있게 된다면 프로젝트를 배포하는데에 한 발자국 더 가까워졌다는게 실감날 것 같다.

[Docker] Docker를 사용하는 이유

junse0 — Fri, 15 May 2026 14:41:51 +0900

1. 문제 상황

이번에 프로젝트에서 백엔드 개발을 하다 보니 로컬에서는 정상적으로 동작했지만, 서버에 배포하여 팀원들이 사용했을 때에 오류가 발생하는 일이 있었다. 이 문제점들은 단순히 코드의 문제가 아닌 실행 환경의 차이에서 생긴 오류였다.

Java의 버전이 다르거나, DB 설정, OS, 라이브러리 버전이 다르는 등의 여러 실행 환경에서의 차이점으로부터 생긴 문제들이었고, 이를 해결하기 위해 동일한 환경을 직접 세팅하여 프로그램을 실행하는 것은 너무나 번거로운 일이었다.

2. 기존 방식(VM웨어)의 한계

이러한 문제점을 해결하기 위해 VM(가상 머신)을 사용하는 기존의 방식이 있었다. 하나의 물리 서버 위에서 여러 개의 독립적인 OS를 실행할 수 있게 해주는 방식인데, 개발 환경과 동일한 OS를 만들고 그 위에 애플리케이션을 올려 프로그램을 실행할 수 있도록 해준다.

하지만, OS 전체를 포함하기에 다음과 같은 문제점들이 존재한다.

VM 자체가 무겁다
부팅 시간이 오래 걸린다
메모리, CPU 사용량이 크다
이로 인해 여러 개를 띄우기 부담스럽다

따라서, VM으로는 환경을 일치시키는 것은 해결할 수 있지만, 효율성이 떨어지는 트레이드 오프가 발생한다.

그렇지만, VM웨어를 사용하는 것의 장점도 존재한다.

독립적인 실행 환경을 제공하여 서로 다른 OS 간의 충돌 방지
여러 서버를 가상화하여 자원을 효율적으로 사용할 수 있음
백업 및 복구 기능을 제공하여 데이터 손실 방지
네트워크 가상화 및 보안 기능 제공

그래서 무작정 VM웨어를 사용하는 대신 Docker를 사용하는 것보다 요구 사항에 따라 더 알맞는 기술을 선택하여 사용하는 것이 적합하다.

3. Docker

Docker는 위에서 언급한 문제들을 해결하기 위해 다른 방식으로 접근한다.

Docker는 개발 환경을 이미지화시키고 해당 이미지를 통해 개발 및 배포 환경을 쉽게 컨테이너화하여 구축할 수 있다. 해당 이미지를 실행한 인스턴스인 컨테이너를 활용한다.

Dockerfile을 통해 설치할 언어, 프레임워크, 패키지 등을 미리 코드 형태로 명시하여 어느 컴퓨터에서든 쉽게 자동으로 설치할 수 있게 한다. 이를 통해 개발자와 운영자가 동일한 환경에서 작업을 할 수 있게 된다.

Docker는 CI/CD 파이프라인에서도 중요한 역할을 하는데, Jenkins와 같은 도구와 통합하여 자동화된 빌드 및 배포 프로세스를 구현할 수 있다.

실행 환경 자체를 코드로 관리해준다고 생각하면 된다.

4. 마무리하며

Docker에 대하여 간단하게 알아보았는데, 다음으로는 Docker의 핵심 구조에 대해서 이해해보는 시간을 가져야겠다. 빠르게 학습을 마치고 Docker를 이용하여 프로젝트를 EC2에 배포하는 것을 목표로 삼아야겠다.

[AWS CLOUD] IAM

junse0 — Tue, 12 May 2026 16:16:55 +0900

AWS Cloud를 회원가입을 하고 로그인할 때 IAM user 로그인이 있어 조금 헷갈리기도 했고, 뭔지 잘 몰랐었다.

그래서 IAM이 무엇인지에 대해 먼저 알아보기로 하였다.

1. IAM이란?

사용자의 접근 권한을 관리하는 서비스로, 조직 내부의 AWS를 사용하는 사람들에게 서비스들과 서비스에 생성된 자원 등에 대한 세분화된 권한을 지정할 수 있다.

ex) 개발부서 그룹은 EC2와 S3 서비스에 대한 엑세스 권한을 주고, DB부서 그룹에겐 RDS 엑세스 권한을 주는 등.

IAM은 엑세스 권한 설정 뿐만 아니라, 언제 어디서 누가 무엇을 어떻게 할 수 있는가를 상세히 설정할 수 있어 2~3시까지만 S3의 특정 버킷의 자료를 열람할 수 있도록 하는 것이 가능하다.

이외에도 기능을 정리해보면 아래와 같다.

사용자 생성 / 관리 / 계정의 보안 - 사용자의 패스워드 정책 관리 (일정 시간마다 비밀번호 변경 등)
AWS 계정에 대한 공유 엑세스: AWS 계정의 리소스 관리 및 권한을 부여 가능
세분화된 권한: 리소스에 따라 여러 사람에게 다양한 권한 부여 가능
- 일부 사용자에게는 EC2 전체 엑세스 권한, 일부에게는 S3 읽기전용의 권한, 일부에게는 회원 정보만 엑세스 할 수 있도록
EC2 애플리케이션 권한 자격 부여: 사용자 뿐만 아니라, EC2에 실행되는 애플리케이션에 IAM기능을 이용해 자격증명 제공 가능 - 어떤 EC2가 S3 버킷이나 RDB 테이블에 접근할 수 있는 액세스 권한을 지니도록 함.
멀티 팩터 인증(MFA): 보안강화를 위해 암호나 액세스 키 뿐 아니라 특별히 구성된 디바이스 코드를 제공하는 인증 추가 가능
자격증명 연동: 기업 네트워크, 인터넷 자격 증명 공급자같이 다른 곳에 이미 암호가 있는 사용자에게 AWS 계정에 대한 임시 액세스 권한 부여 가능
계정에 별명 부여 가능
글로벌 서비스

2. IAM 구성 요소

크게 사용자(Users), 그룹(Groups), 역할(Roles), 정책(Policies) 으로 구성되어 있다.

1) IAM 사용자(Users)

실제 AWS의 기능과 자원을 이용하는 사람 OR 애플리케이션을 의미하며 사용자(사람)가 AWS 서비스를 엑세스하는 것을 조정하고, 애플리케이션이 서비스에 엑세스하는 것을 관리한다.

2) IAM 그룹(Groups)

사용자가 많아진 경우에 권한을 보다 편하게 관리하기 위해서 그룹이라는 개념을 사용한다.

하나의 그룹에 여러 명의 사용자를 지정해서 공통적으로 권한을 주어야 하는 상황일 때 사용하는 것이 유용하다.

ex) Developers 그룹에 S3 ReadOnly 정책을 연결하면, 해당 그룹의 IAM 사용자들에게 이 정책이 적용되게됨.

따라서, 동일한 권한을 가지는 사용자들에게 권한을 편리하게 설정할 수 있다.

하나의 사용자는 최대 10개의 그룹에 속할 수 있다.

3) IAM 정책(Policy)

사용자와 그룹, 역할이 무엇을 할 수 있는지에 대한 permission 설정 모음 데이터 문서로, 하나 이상의 AWS 리소스에 대하여 어떠한 작업을 수행 가능한지에 대한 규칙을 JSON 형식으로 작성된다.

이 정책 문서를 IAM 사용자와 그룹, 역할에 연결한다.

IAM 정책은 6가지의 타입으로 분류된다.

4) IAM Policy Type

자격 증명 기반 - AWS 관리형 정책, AWS 고객 관리형 정책, AWS 인라인 정책
리소스 정책 기반
권한 경계 기반 정책
조직 SCP 기반 정책
액세스 제어 리스트
세션 정책

| 자격증명 기반 정책(Id-Based Policy) |

- AWS 관리형 정책 - AWS에서 생성 및 관리하는 독립적인 정책으로, AWS에서 기본으로 제공되는 정책이다.

- AWS 고객 관리형 정책 - AWS 관리형 정책과 다르게, 사용자가 정책을 새로 생성하여 커스텀한 것으로, 만들어진 Acoount에서만 사용할 수 있다.

- AWS 인라인 정책 - 1 to 1 정책으로 명시적으로 할당되는 정책으로, 하나의 사용자에게 하나의 정책을 적용하는 개념이다.

| 리소스 기반 정책(Resource-Based Policy) |

사용자나 그룹에 적용하는 자격증명 기반 정책과 달리, AWS 서비스 리소스에 적용하는 정책으로, S3 버킷 정책이 여기에 속한다.

5) IAM 역할(Role)

그룹만으로도 권한이 다양해지면 복잡해지고 관리가 어려워지니 역할(Role)이라는 개념을 도입했다.

IAM 역할은 리소스에 대한 엑세스 권한이 없는 사용자나 서비스에게 일시적으로 권한을 위임하는 개념이다.

ex) 아무 권한이 없는 IAM 사용자 / EC2 인스턴스가 S3 버킷에 접근하려면 직접 정책을 설정하여 사용후 회수하는 설정을 일일히 해야한다. 이보다 임시 자격 증명서를 부여함으로서 해당 역할에 연결된 권한을 사용할 수 있도록 한다. 원할 때마다 역할을 부여했다가 사용하고 회수함으로서 더 간편하게 관리할 수 있다.

IAM 역할(Role) 기능들에 대해 요약하면 아래와 같다.

AWS 리소스가 무엇을 할 수 있는지를 정의하는 자격증명서
그룹에 권한을 부여하는 대신, 역할을 만들고 역할을 그룹이나 사용자에게 주는 방식
다른 사용자가 역할을 부여 받아 사용가능 - 임시적인 자격 증명을 얻어 해당 권한을 일시적으로 얻게됨
AWS 사용자 뿐만 아니라, EC2 인스턴스, 다른 AWS 계정, Facebook, Google 계정 등 폭 넓게 접근 권한 설정 가능

보안 자격증명을 공유할 필요가 없어 보안이 향상되고, 언제든지 접근 권한을 회수할 수 있어 권한 제어가 가능하며, 각 사용자에게 매번 필요한 권한을 일일이 부여할 필요가 없다는 장점이 있다.

6) IAM 권한 검증 절차

7) IAM 자격증명 보고서 다운

보고서에는 비밀번호부터 언제 IAM 계정에 로그인했는지 등 전반적인 관리자로서의 IAM 관리 정보들이 포함되어 있다. 4시간 주기로 갱신된다.

3. 실습

1) IAM 사용자 만들기

사용자 메뉴에서 사용자 생성 버튼을 눌러 새로운 IAM 사용자를 추가한다.

추가적으로 사용자 이름과 권한을 설정해주고 생성해준다.

2) IAM 그룹 만들기

IAM 사용자 그룹 메뉴로 이동해서 새로운 사용자 그룹을 생성한다.

그룹명을 지정해주고, 그룹에 등록할 정책을 선택한다.

3) 그룹에 사용자 추가

만든 Group1에 생성한 User1을 선택하고 추가한다.

4) IAM 사용자 정책 설정

기존에 선택해둔 정책에 더해 추가적으로 정책을 추가하거나 기존의 정책을 삭제할 수 있다.

Administrator 접근 권한을 추가해주었다.

5) IAM 사용자 계정 접속하기

사용자의 액세스 키를 생성하고 .csv 파일로 다운로드 받는다.

만들어낸 액세스 키와 User 이름으로 IAM 사용자로 로그인한다.

암호는 다운한 csv파일에 있으며, ID는 메일로 온 url에 있는 숫자를 입력하면 된다.

4. 마무리하며

이어서 AWS Cloud의 기초적인 내용에 대해서 공부해보았는데, 로그인할 때마다 헷갈렸던 IAM의 존재에 대해서 조금은 알 수 있었던 시간이었다. 추후로 S3 등을 더 공부해보고 실제로 AWS Cloud를 사용해 배포를 해보는 경험을 해봐야겠다. 이를 위해 추가적으로 docker 컨테이너에 대해서도 학습할 예정이다.

[AWS CLOUD] EC2

junse0 — Sun, 10 May 2026 21:34:54 +0900

1. EC2란?

Amazon Elastic Compute Cloud의 줄임말로서 AWS에서 제공하는 클라우드 컴퓨팅이다.

독립된 컴퓨터를 임대해주는 서비스로, 금액을 지불하고 aws에서 컴퓨터를 대여하여 사용하는 서비스이다.

초기 구입비, 세팅비가 없고, 사용한만큼만 비용을 지불하면 되어 비용면에서 save할 수 있다.

또한, 복잡한 공유기 세팅없이 인터넷으로 자유롭게 접속할 수 있고, 이미지(AMI) 기능도 사용 가능하다.

*이미지(AMI): OS 상태 그대로 저장하는 기능

원하는 만큼 가상 서버를 구축하고 보안 및 네트워크 구성과 스토리지 관리가 가능하며, 신속하게 규모를 확장 및 축소할 수 있어 서버 트래픽 예측 필요성이 줄어들어 사용하는데에 간편하다.

2. EC2 구성

컴퓨터: 인스턴스

하드디스크: EBS

랜카드: ENI

1) 인스턴스

AWS Cloud에서 사용하는 가상 컴퓨터로, CPU, 메모리, 그래픽카드 등 연산을 위한 하드웨어 부분을 담당한다.

컴퓨터마다 쓰임새가 다양하기 때문에 게임용, 서버용, 영상용 등 나뉘어져 있는 것이 인스턴스 유형이다.

시리즈: 위의 그림처럼 다양한 시리즈가 있고, m은 범용타입이기에 aws 초심자가 가장 많이 사용하는 프리티어에서 쓰는 타입이므로 자주 접할 수 있는 타입이다. 이외에도 많은 시리즈의 타입들이 존재한다.
세대: 6은 6세대를 의미하고, 앞으로 세대가 업그레이드되며 점점 증가할 것이다.
추가 구분자: a는 AMD기반의 CPU 프로세서를 사용한다는 의미이고, 각각의 구분자마다 뜻이 다르다.
사이즈: 사이즈의 표에서 볼 수 있듯 nano부터 아래로 내려갈수록 더 큰 크기를 지닌다. 사이즈가 클수록 CPU나 메모리의 성능이 증가한다.

2) EBS

Elastic Block Storage의 약자로, 데이터를 저장하는 역할을 하기에 클라우드에서 사용하는 HDD라고 볼 수 있다.

EBS는 AWS Cloud의 EC2 인스턴스에 사용할 영구 블록 스토리지 볼륨을 제공하고, 사용량을 확장 또는 축소할 수 있으며 빌린 부분에 대해서만 비용을 지불 할 수 있다.

EBS 볼륨 유형은 위의 표와 같은 타입들이 있고, 범용타입인 GP3를 보통 많이 선택하여 사용한다.

3) AMI

Amazon Machine Image의 약자로, EC2 인스턴스를 실행하기 위한 정보를 모은 단위이다.

EC2를 실행하기 위해서는 CPU 프로세서 타입, 저장공간 용량, 32 or 64비트인지, 윈도우 or 리눅스,... 등등의 정보가 많이 필요한데 이러한 세팅 정보를 저장한 단위라고 생각할 수 있다.

ex) 윈도우가 깔린 EC2를 사용할 것이면 인스턴스를 생성하고 OS를 일일히 설치하는게 아닌 윈도우 환경 세팅이된 템플릿 AMI를 EC2에 적용시키는 것

현재 상태의 EC2 세팅을 복제하여 다른 계정이나 다른 리전에 전달하는 것도 가능하다.

3. 실습

1) EC2 인스턴스 시작

리전을 아시아 태평양(서울)로 선택하고 EC2로 들어가 인스턴스를 시작한다.

AMI는 프리 티어에서 사용 가능한 AMI를 사용하고, 맨 위에 있는 LINUX 2 AMI를 사용한다.

2) 인스턴스 유형 선택

프리 티어에서 사용 가능하고, 범용적으로 많이 사용하는 t3 그룹에 micro유형 크기인 t3.micro 유형을 선택하여 사용한다. 인스턴스 유형에 대해서는 이전 VPC 글에서 다루었다.

3) EC2 인스턴스 세부 정보 구성

네트워크와 서브넷 등 네트워크 설정은 일단 하지 않고, 기본 값으로 설정한 채로 넘어간다.

4) EBS(가상 스토리지) 설정

크기(GiB): 메모리 GB단위
볼륨 유형: EBS는 5가지 타입이 있다. 5가지 종류의 SSD가 있는데, 비용 발생을 피하기 위해 범용 SSD를 선택한다.
종료 시 삭제: 인스턴스가 삭제될 때 EBS도 삭제할지 말지를 설정하는 옵션이다. 해당 옵션이 체크되면, 인스턴스를 종료할 때 컴퓨터와 저장장치가 모두 폐기된다. 체크하지 않으면, 컴퓨터만 폐기된다.
암호화: EBS 자체를 암호화시키는 것으로, 해킹당해도 암호화가 되어 있기에 데이터가 안전하다는 뜻이다.

5) 태그 추가

태그는 어떤 인스턴스를 만들고, 어떤 용도, 누가 관리하는지 등의 메모기능이라고 볼 수 있다.

인스턴스를 여러 개 사용할 경우 각 인스턴스를 알아보기 쉽게 별명으로 구분하는 기능이지만, 설정을 하지 않아도 된다.

딱히 추가할 태그가 없어서 사용하진 않았다.

6) 보안 그룹 구성

방화벽을 설정하는 단계로 네트워크를 통해 해당 인스턴스에 어떤 접속방식을 어디까지 허용할지 설정한다.

기본 값으로는 SSH 접속을 22번 포트를 사용하여 모든 IP의 사용자가 접속할 수 있도록 설정되어 있고, 웹에서 접속하게 하려면, 규칙을 추가해서 HTTP 80번 포트를 추가해 열어주면 된다.

이외에도 https나 추가저인 세팅도 필요하다.

7) 인스턴스 생성

Pair Key도 생성해주고, 인스턴스를 생성한다.

8) 인스턴스 삭제

우클릭 후 인스턴스 종료(삭제)를 누르면 인스턴스가 삭제된다.

삭제한 인스턴스는 상태가 '종료됨'으로 변경된다.

9) EC2 인스턴스 웹서버 설치하고 접속

인스턴스에 웹서버를 설치한다.

따로 추가 설정 없이 연결을 해서 EC2 커넥트에 접속한다.

이로써 웹에서 리눅스 터미널을 사용할 수 있게 된 것이다.

아래의 사진은 ping을 쳐보고, 정상적으로 연결이 되었는지 확인해본 것이다.

이후에 아파치 웹 서버를 설치한다.

Public IPs로 브라우저에 접속해본다.

4. 마무리하며

지난 시간에 VPC를 공부하고 실습해본 것에 이어 EC2에 대해서 공부해보고 실습을 진행해 보았는데, 아무래도 VPC보다 EC2를 먼저 학습을 하는게 더 좋은 순서인 듯 하다. AWS Cloud의 주요 서비스들을 하나씩 공부해보니 조금씩 이해가 되기 시작했다. 직접 배포도 곧 해보는 시간을 가지도록 해야겠다.

[AWS Cloud] VPC

junse0 — Sun, 3 May 2026 22:17:18 +0900

1. AWS의 리전 가용 영역

대규모의 서버 컴퓨터를 모아 둔 곳으로, 한 곳에 몰아두면 다음과 같은 단점이 존재한다.

자연 재해가 발생할 경우 모든 서비스가 마비됨
모든 자원이 북미에 있다면, 반대편인 아시아는 멀기 때문에 서비스가 느림

위의 두 가지 문제를 해결하고자 서비스를 위한 자원들을 여러 곳에 분산하여 배치해둔 것이다.

위의 그림에서 보이듯이 전세계 곳곳에 분산되어 있고, 대한민국에도 하나의 리전이 있다.

가용영역은 리전을 한 번 더 분산하여 배치한 것이라고 생각하면 된다.

2. VPC(Virtual Private Cloud)란?

우선 VPC를 공부하기 전에 서브네팅, 라우팅, IP 클래스 등의 대한 내용 선학습이 필요하다.

컴퓨터네트워크 과목을 수강했었기에 바로 VPC 이해를 위한 공부를 시작했고, 기억이 안나는 것들은 그 때마다 아래의 블로그에서 찾아보며 공부하였다.

https://inpa.tistory.com/entry/WEB-IP-%ED%81%B4%EB%9E%98%EC%8A%A4-%EC%84%9C%EB%B8%8C%EB%84%B7-%EB%A7%88%EC%8A%A4%ED%81%AC-%EC%84%9C%EB%B8%8C%EB%84%B7%ED%8C%85-%EC%B4%9D%EC%A0%95%EB%A6%AC

IP 클래스 · 서브넷 마스크 · 서브넷팅 계산법 총정리

아이피(IP) 정리 IP(Internet Protocol) 란 인터넷에 연결되어 있는 모든 장치들(컴퓨터, 서버 장비, 스마트폰 등)을 식별할 수 있도록 각각의 장비에게 부여되는 고유 주소이다. 아이피(ip)는 일반적으

inpa.tistory.com

VPC는 AWS 클라우드 내에서 사용자에게 할당된 논리적으로 격리된 가상 네트워크 공간으로, 데이터 센터의 네트워크를 직접 구상하듯 IP 대역, 서브넷, 라우팅 테이블, 게이트웨이를 직접 제어할 수 있다. 또한, 다른 사용자의 네트워크와 분리되어 있으므로 보안성이 뛰어나다는 장점이 있다.

AWS는 모든 서비스에 VPC를 적용하도록 강제하고 있으며, 대부분의 AWS 서비스가 VPC에 의존적이기 때문에 VPC에 대한 이해가 필수적으로 필요하다.

VPC는 가상의 네트워크 영역이기에 사설 아이피 주소를 가지게 되어, 사설 IP 대역에 맞추어 설계해야하며, 사용하는 사설 IP 대역은 아래와 같다.

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

그리고, 하나의 리전 안에서 VPC를 여러 개 생성할 때 DNS IP를 잡지 못하는 에러가 발생하지 않도록 서로 아이피는 겹치면 안된다. 예를 들면 172.31.0.0/16으로 기본 VPC가 생성되어 있다면 172.31 네트워크 IP 주소를 피해서 생성해야한다. 또한, AWS에서는 /16~/28 비트의 서브넷 마스크만을 허용한다.

그리고 VPC에서 한 번 설정된 IP 대역은 수정할 수 없으며, 각각의 VPC는 독립적이기 때문에 서로 통신할 수 없다. 통신을 하려면 VPC 피어링(peering) 서비스를 통해 VPC 간 트래픽을 라우팅할 수 있도록 설정해야한다.

3. 서브넷 (Subnet)

VPC가 논리적인 범위라면, 서브넷은 VPC의 IP 주소를 나누어 리소스가 배치되는 물리적인 주소 범위이다.

서브넷은 VPC안에서 실제로 리소스가 생성될 수 있는 네트워크 영역으로, EC2, RDS와 같은 리소스를 생성할 수 있다. 하나의 가용영역 내부에서 여러 서브넷을 생성할 수 있지만, 여러 가용영역에 거쳐 서브넷을 생성할 순 없다.

아래의 5가지 IP는 AWS의 관리 IP로서 사용자가 사용할 수 없는 주소이다.

10.0.0.0	네트워크 주소 (Network ID)
10.0.0.1	AWS에서 VPC 라우터용으로 예약 (Default Gateway)
10.0.0.2	DNS 서버 주소 DNS 서버의 IP 주소는 기본 VPC 네트워크 범위에 2를 더한 주소. CIDR 블록이 여러 개인 VPC의 경우, DNS 서버의 IP 주소가 기본 CIDR에 위치하게 된다.
10.0.0.3	AWS에서 앞으로 사용하려고 예약한 주소
10.0.0.255	네트워크 브로드캐스트 주소

호스트 범위의 첫 번째 주소는 네트워크 주소이고, 마지막 주소는 브로드캐스트 주소로서 사용할 수 없는데, 이에 3개가 추가되어 총 5개의 IP를 사용할 수 없다.

이 서브넷은 다시 Public Subnet과 Private Subnet으로 나뉘어진다.

Public Subnet: 인터넷에 접근 가능한 Subnet으로, VPC 외부 / 내부와 통신
Private Subnet: 인터넷에 접근 불가능한 Subnet으로, VPC 내부에서만 통신

따라서, Public Subnet에 존재하는 인스턴스는 인터넷에 연결되어 외부와 양방향 트래피을 주고 받을 수 있지만, Private Subnet은 외부에 노출도어 있지 않기에 접근할 수 없다. 그렇기에, Private Subnet에 주로 민감한 데이터 정보들을 저장해 보안을 강화하는 식으로 설계를 한다.

공용 아이피 주소는 공유기에만 할당이되고, 공유기에 연결한 디바이스들은 사설 아이피 대역을 받게 된다. 외부 인터넷은 공유기로 먼저 데이터를 보내고, 공유기는 포트를 통해 각 디바이스들을 구분하여 데이터를 보내주게 된다. 따라서, 외부 네트워크의 디바이스는 공유기를 거쳐 데이터를 보내야하는데, 공유기가 이상한 데이터를 버려준다면 보안성 측면에서 좋다.

만약 데이터 업데이트에 인터넷 연결이 필수라면 NAT Gateway를 통해 Private Subnet 내부의 인스턴스들이 인터넷에 연결이 가능하도록 할 수 있다.

4. 라우팅

각각의 Subnet은 서로 다른 네트워크 영역을 가지고 있기 때문에, 한 Subnet에서 다른 Subnet으로 가기 위해서는 Routing이 필요하다.

라우팅 테이블은 VPC 안에서 발생한 네트워크 요청을 처리하기 위해 어디로 트래픽을 전송해야하는지 알려주는 표지판 역할을 수행한다.

각 서브넷들은 이러한 라우팅 테이블을 가지고 있으며, 요청 발생시 이 라우팅 테이블을 사용해 목적지를 찾는다.

VPC 내부에 대해서는 디폴트로 Routing이 자동으로 생성되어 있어 별도의 설정 없이 한 Subnet에서 다른 Subnet으로 통신이 가능하다.

자신이 속한 Subnet이 아닌 Subnet으로 향할 때 Router를 거치게 된다.

서브넷이 라우팅 테이블을 가지고 있는 것을 확인할 수 있다.

5. 인터넷 게이트웨이

VPC는 기본적으로 격리된 네트워크 환경이므로, 인터넷과 VPC의 리소스와 통신을 활성화하기 위해서는 인터넷 게이트웨이가 필요하다.

생성한 Public Subnet을 실제 Public용으로 만들기 위해서는 인터넷 게이트웨이를 라우팅 테이블에 설정하고 등록해주어야 한다. 인터넷 게이트웨이에 연결되면 Public Subnet이고, 연결되어 있지 않으면 Private Subnet이라고 볼 수 있다.

6. 실습

1) VPC 실전 구성

리전을 서울로 변경하고 VPC를 생성한다.

추가적으로 설정에서 DNS 호스트 이름을 활성화한다.

2) Subnet 실전 구성

	ap-northeast-2a(AZ)	ap-northeast-2c(AZ)
Public Subnet	10.0.1.0/24	10.0.2.0/24
Private Subnet	10.0.3.0/25	10.0.4.0/25

위의 표처럼 2개의 가용범위를 Public Subnet 2개, Private Subnet 2개로 구성해본다.

위에서 만든 VPC를 선택한다.

위처럼 Public Subnet, Private Subnet을 각각 2개씩 만들었다.

성공적으로 4개의 서브넷이 만들어졌다.

두 개의 Public Subnet에 주소 자동 할당 활성화를 체크한다.

3) Subnet에 EC2 인스턴스 넣기

Private, Public Subnet에 각각 Instance를 1개씩 생성한다.

2개의 인스턴스가 생성되었다.

4) 인터넷 게이트웨이 설정

아래와 같이 인터넷 게이트웨이를 생성해준다.

아직 VPC에 연결하지 않았기에 상태는 Detached이다.

위에서 생성한 VPC에 이어서 연결해준다.

퍼블릭용 라우팅 테이블을 생성하여, 이전에 만든 public subnet들이 진짜 public용으로 설정되게 라우팅 설정을 완료한다.

기본(예)로 생성된 서브넷들은 기본적으로 private-table을 사용해서 인터넷에 접근하지 못하는 보안성을 확보하고, 외부와 연결이 필요한 서브넷들은 public-table을 따로 추가로 만들어서 넣어주면 된다.

이후에 public subnet 2개를 public routing table에 등록한다.

발생하는 모든 트래픽에 대해 10.0.0.0/16은 로컬로 보내고 이를 제외한 모든 트래픽은 외부 인터넷과 연결하도록 public-table을 편집해준다.

라우팅 테이블 연결 설정을 마치면 정말로 public 서브넷과 prviate 서브넷을 완성시킨 것이다.

아래 사진에서 보이듯 명시적으로 인터넷 게이트웨이를 연결한 라우팅 테이블에 등록함으로서 외부에 연결이 된 것이며, public-subnet 2개는 외부로 연결이 되었고, private-subnet 2개는 외부로 연결이 되어 있지 않다.

최종적으로 아래와 같은 구조를 지니게 된다.

7. 마무리하며

이번에 처음으로 AWS Cloud를 사용해서 VPC와 서브네팅, 마지막으로 인터넷 게이트웨이까지 연결을 해보았는데, 이론적으로 공부하여 새로운 사실들을 알긴 했는데, 이를 어떻게 배포에 실제로 사용할지는 아직 잘 모르겠다.

그래도 첫 시작을 했으니 더욱 공부해봐서 실제로 배포하고 운영해보며 실무적인 경험을 해보아야겠다. 그래도 생각보다 꽤 재밌어서 시간이 날 때마다 틈틈히 더 공부해보아야겠다.

BOJ 10828 - 스택 C++

junse0 — Thu, 9 Apr 2026 17:45:44 +0900

문제 번호

백준 10828 - 스택 (실버IV)

문제 설명

이 문제는 자료구조 중에서 스택을 구현하여 문제에서 제공하는 아래의 5개의 명령어를 수행하도록 작성하는 것이다.

push X: 정수 X를 스택에 넣음.
pop: 스택에서 가장 위에 있는 정수를 빼고 그 수를 출력. (비어있으면 -1)
size: 스택에 들어있는 정수의 개수를 출력.
empty: 스택이 비어있으면 1, 아니면 0을 출력.
top: 스택의 가장 위에 있는 정수를 출력. (비어있으면 -1)

접근 방식

C++에서 제공하는 stack 라이브러리를 사용하면 그대로 바로 풀 수 있겠지만, vector 라이브러리를 사용해서 풀이해보았다.

트러블

top함수를 구현하는데에서 스택이 비어있는 상태에서 empty()체크를 하기 이전에 back()으로 값을 먼저 참조하려고 했기에 비어있는 vector를 참조하려 하는 오류가 발생했었다.
-> empty()체크를 참조 이전에 시행하여 해결했다.

최종 코드

#include <iostream>
#include <vector>

using namespace std;

// push
void push(vector<int>& arr, int num) {
    arr.push_back(num);
}

// pop
void pop(vector<int>& arr) {
    // 스택이 빈 경우
    if (arr.empty()) {
        cout << "-1\n";
    }
    else {
        int k = arr.back();
        cout << k << "\n";
        arr.pop_back();
    }
}

// size
void size(vector<int>& arr) {
    // 스택이 안 비어있는 경우
    if (!arr.empty()) {
        cout << arr.size() << "\n";
    }
    else {
        cout << "0\n";
    }
}

// empty
void empty(vector<int>& arr) {
    if (arr.empty()) {
        cout << "1\n";
    }
    else {
        cout << "0\n";
    }
}

//top
void top(vector<int>& arr) {
    if (arr.empty()) {
        cout << "-1\n";
    }
    else {
        cout << arr.back() << "\n";
    }
}

int main() {
    vector<int> arr;
    int n, num;
    string str;

    cin >> n;

    for (int i = 0; i < n; i++) {
        cin >> str;  // 명령어 입력
        if (str == "push") {
            cin >> num;
            push(arr, num);
        }
        else if (str == "pop") {
            pop(arr);
        }
        else if (str == "size") {
            size(arr);
        }
        else if (str == "empty") {
            empty(arr);
        }
        else if (str == "top") {
            top(arr);
        }
        else {
            cout << "잘못된 명령어.";
        }
    }
}

분석

시간 복잡도: 모든 명령어가 인덱스 접근 및 수정만 하므로 O(1)의 시간복잡도를 가지고, 명령의 수 N에 따라 총 시간 복잡도는 O(N)이 된다.
공간 복잡도: vector 자료형은 들어오는 데이터의 양에 맞게 메모리를 추가 할당받는다. vector의 capacity가 가득 찼을 때에 데이터가 추가되면 기존 N의 2배인 2N만큼의 메모리를 추가적으로 점유한다. 최종적으로는 O(N)의 공간 복잡도를 가지게 된다.

vector 자료형으로 문제를 해결했지만, stack을 처음 다룬다면 배열로 직접 stack 자료형을 구현해보는 것도 좋을 것 같다고 생각했다. 자료구조를 처음 배우거나 아직 미숙한 경우에는 직접 구현해보는 편이 좋은 것 같다.

ADsP, SQLD 후기

junse0 — Thu, 9 Apr 2026 17:14:11 +0900

우선 필자는 컴퓨터공학을 전공하고 있고 백엔드 개발자 취업을 희망하는 대학생이다.

2025년도에 복학을 하고, 본격적인 진로에 대한 고민이 깊어갔다.
예전부터 막연하게 금융권 IT 개발자로 취업하고 싶다는 생각이 있었지만, 이를 이루기 위해 구체적으로 관련 스펙을 쌓은 경험이 없었다.

2학년까지는 그저 학점관리와 강의에서 배우는 cs 지식들에 대한 공부에만 집중하였는데, 그러다 보니 프로젝트 경험과 실무에 큰 도움이 될법한 경험이 없다고 느껴졌다.

이제 3학년이 되는데 뭐라도 해야겠다는 생각이 들어 데이터 구조와 분석에 도움이 되는 ADsP와 SQLD 자격증을 취득하기 위한 공부를 하기로 했다.

1. ADsP 취득 과정

컴퓨터공학을 전공했지만, 데이터 분야에서는 다루어본 적이 없어 노베이스라고 생각하고 넉넉하게 2주 정도를 공부기간으로 잡았다.
하루에 오래 공부하는걸 선호하지도 않기에 기간을 길게 잡고 하루에 1시간에서 많게는 3시간까지 꾸준히 공부하도록 계획했다.

제 48회 시험을 신청하였고, 시험일은 2026-02-07이었다. 시험 신청은 시험일로부터 약 1달 전쯤에 하기에 미리 일정을 확인하고 신청하는 것이 좋을 것 같다.

1) 교재

우선 책은 유명한 민트책을 구매하여 공부했다.

https://www.dataedu.kr/product/adsp-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B6%84%EC%84%9D-%EC%A4%80%EC%A0%84%EB%AC%B8%EA%B0%80-2026/

책을 구매하면 데이터에듀 사이트에서 강의도 제공해주고, 기출 복원문제들도 풀어볼 수 있어 공부하는데에 도움될 것 같았다.
기본적으로 민트책은 책 자체에서 약 한 달로 계획을 짜두었는데, 이 커리큘럼은 굉장히 널널하게 짜여져있어 이 계획표는 무시하고 진행하였다.

2) 개념 강의

우선 첫 10일 동안에 데이터에듀 강의를 배속하여 1회독을 하였고, 완강을 한 후에는 유튜브에서 요약본 영상을 보며 헷갈리는 개념들을 따로 정리하여 암기하는 과정을 가졌다. 아래 링크의 동영상은 유튜브 요약본인데 도움이 많이 되었어서 추천한다.

https://www.youtube.com/watch?v=rClfO1GdmFM

1, 2과목만 요약강의를 시청했는데, 큰 도움이 되었다. 3과목도 있으니 찾아서 들으시면 도움이 될 듯 하지만 개인적으로 3과목은 문제를 많이 풀어보는 것이 도움이 된다고 느꼈다.

3) 데이터에듀 어플

책을 모두 풀이한 후에는 데이터에듀 어플리케이션을 다운로드 받아 기출복원 문제를 풀이했다.

최근 10회차를 풀이했는데, 초반에는 60점 근처에 점수가 나와 굉장히 불안했다. 그래도 점점 풀다보니 비슷한 내용의 문제들도 있어서인지 안정적으로 70~80점대가 나왔고, 실제 시험을 본 48회차 시험도 난이도가 크게 다르진 않았다.

다만, 문제에 어휘나 유형이 이전과는 살짝 달라서 헷갈린 부분이 있었다.
ex) 정형데이터 -> 정량데이터

시험 당일에 데이터에듀 유튜브에서 복원 문제를 풀이하며 답을 확인하는 라이브를 진행하는데, 저녁즈음에 해당 라이브가 유튜브에 올라오기에 답부분만 넘기면서 확인해 대충 점수를 예상해보았다.
물론, 완벽 복원된 문제는 아니라 좀 다르긴 하지만 그래도 안정권이 나와 안심하였고, 실제로 78점으로 합격할 수 있었다.

4) 마무리

민트책은 확실히 비전공자를 위해서는 좋은 것 같다. 다른 책들을 본 적이 없긴 하지만 데이터에듀 앱에서 공부할 수 있다는 점이 너무 큰 장점이라 생각해 추천드린다.

지하철이나 이동시간에 휴대폰으로 개념문제나 기출문제를 풀고 공부할 수 있기에 이런 부분에 장점을 느끼시는 분들은 개인적으로 민트책을 추천드린다.

간혹 1, 2과목에서 개념 부분에 내용이 너무 많다고 느껴지는데 그런 파트들은 그냥 한 번 읽어보고 문제를 위주로 풀이하며 외우는 것을 추천한다.

데이터에듀 어플에서 R언어도 실습해볼 수 있는데, 실습하며 공부하면 도움이 되긴 하겠지만 저는 시간이 아까워서 그 시간에 기출 문제를 한 번 더 푼다는 생각으로 안하고 문제를 풀며 R언어 문제들을 익혔습니다.

2. SQLD 취득 과정

ADsP를 취득한 후에 바로 SQLD 시험을 신청하였다.
SQLD는 컴퓨터공학과 학생들은 거의 모두 다 취득한다고 하는 자격증이라고들 하길래 미리 취득해두려는 생각이었다.
개강하면 데이터베이스 과목을 수강할 예정이기도 했기에 비록 자격증을 취득하지 못해도 수업을 예습했다고 생각하기로 하고 준비하기 시작했다.

제 60회 시험을 신청하였고, ADsP 때와 마찬가지로 2주 정도 기간을 잡고 공부를 시작하였다.

1) 교재

ADsP를 취득했지만 SQL은 다루어본 적이 없어 비전공자에게 좋다는 이기적의 기본서를 구매했습니다.

https://shop.youngjin.com/goods/view?no=1207

유튜브 무료 강의도 제공해주기에 추천드립니다.

2) 개념 강의

  ADsP 때와 마찬가지로 첫 10일동안은 우선 이기적 유튜브에서 제공해주는 강의들을 배속으로 1회독을 했고, 이후에는 요약 강의본을 보며 똑같이 헷갈리는 개념들에 대해 정리하며 공부하였다.

  아래 강의는 ADsP 때 들은 요약강의와 동일한 유튜버 분의 요약강의인데 둘 다 도움이 많이 되었기에 추천한다.

https://www.youtube.com/watch?v=e_AIZkWJNqA&t=2124s

해당 강의들을 모두 듣고 이기적 교재 뒷편에 있는 모의고사를 풀이하였다.
생각보다 문제들이 어렵지 않았고, 점수도 고득점이 나와서 무난하게 합격할 것이라 생각하고 있었는데 이전 회차인 58, 59회차가 굉장히 높은 난이도로 나왔다는 소식을 듣고 복원된 문제를 찾아 몇 문제 보았는데 지금껏 이기적 교재에서 푼 문제들과 난이도가 차원이 달라 급하게 노랭이 책을 구매하여 풀이하게 되었다.

3) 노랭이

시험을 주관하는 한국데이터산업진흥원에서 출판한 책이기에 많은 분들이 이 책으로 공부한다고 하였다.

https://product.kyobobook.co.kr/detail/S000212021705

  문제들로만 이루어져 있어 이기적 교재로 개념까지 공부할거라 구입하지 않으려 했는데 실제 시험이 노랭이 교재와 비슷한 난이도로 나온다는 이야기에 구매하여 풀이했다.

  Part1, 2만 풀이하였고, 문제 양도 많고 꽤나 어려워서 짧은 시간에 모두 풀이하지는 못하였다. 확실히 이기적 교재의 문제들보단 어려웠고, 한 문제 한 문제 푸는데에 꽤 시간이 걸렸다.

4) 실제 시험

  걱정을 가진 채 시험을 보러 갔는데, 그리 만만하게 볼 시험은 아니었다고 느꼈다.
  ADsP 때에는 헷갈리는 문제들을 제외하고 모두 풀이하는데에 30분이면 충분하였지만, SQLD는 정말 시간을 모두 사용하여 풀이를 진행했다.
  처음 보는 유형의 문제들도 있었고, 노랭이 책에서 보았던 문제들도 몇 보여 노랭이 책을 풀어보길 잘했다고 생각했다.

  그래도 다행히 ADsP때와 같은 점수인 78점으로 합격할 수 있었다.

5) 마무리

  컴퓨터공학을 전공하여 SQL을 다루어본 경험이 있다면 개념서 말고 노랭이 책이나 기출문제들만 풀이해보아도 충분히 합격할 수 있을 것이라 생각한다.

  하지만, 나처럼 SQL을 접해보지 못하였고 비전공자라면 개념서를 구매하여 개념 공부를 하고 여유가 된다면 노랭이책도 구매하여 한 번 풀어보는 걸 추천한다.

  최근에 SQLD 난이도가 오르는 추세이기에 노랭이 책 푸는게 예전보다 더 도움이 된다고 생각하고 시험비도 5만원이기에 교재 살 돈 아끼다가 괜히 시험을 한 번 더 보는 것보다 처음할 때 확실하게 준비하는 것이 좋을 것 같다.

  SQL 문은 영어로 되어있고 굉장히 직관적이라고 생각하기에 어려운 문제들을 버리고 푼다면 그래도 무난하게 풀 수 있을 것 같고 1과목이 개인적으로 더 어려웠다.

3. 앞으로의 계획

  이제 자격증은 4학년에 정보처리기사를 취득하는 것을 계획으로 해야겠다.

  학교 강의에서 Java언어를 배웠으니 이를 바탕으로 Spring Boot 공부와 자격증 공부를 하며 배운 지식들과 데이터베이스 수업에서 배운 내용을 토대로 직접 데이터베이스를 설계해보며 데이터를 다루는 경험도 쌓아야겠다.

  틈틈히 경제와 it뉴스를 보며 관련 분야의 흐름을 파악하는데에도 소홀해지지 않아야겠다.

웹 보안 및 인증 프로토콜 (JWT & OAuth)

junse0 — Wed, 8 Apr 2026 19:07:43 +0900

1. 세션과 JWT의 차이점

세션은 유저가 로그인하면 서버가 그 정보를 자신의 메모리나 DB에 저장하고, 유저에게는 그 정보의 주소인 '세션ID'만 건네주는 방식이다.

● 동작 원리: 유저는 '세션ID'가 담킨 쿠키를 들고 다니고, 서버는 요청이 올 때마다 서버의 메모리에 해당 ID가 있는지 확인한다.

● 장점: 서버가 유저의 상태를 완전히 통제할 수 있어 보안이 의심되는 유저를 서버에서 즉시 강제 로그아웃시켜 통제할 수 있다.

● 단점: 유저가 많아져서 서버를 여러 대로 늘리면, 1번 서버에 로그인한 유저 정보가 2번 서버에는 없어 로그인이 풀리는 현상이 발생한다. 이를 해결하기 위해서는 별도의 공유 저장소(Redis 등)가 필요해 인프라 복잡도가 상승하는 단점이 있다.

JWT는 유저 정보를 암호화해서 유저에게 직접 들려보내는 방식으로, 서버가 따로 정보를 저장하지 않는다.

● 동작 원리: 유저가 로그인하면 서버는 유저 정보를 담은 '토큰'을 발급하고, 유저는 매 요청마다 이 토큰을 제출한다. 서버는 이 토큰이 서버의 열쇠로 서명된 것이 맞는지 검증만 진행한다.

● 장점: 서버가 정보를 저장하지 않으므로 서버를 수백 대 늘려도 상관없다. 모든 서버가 같은 검증 로직만 가지면 되기 때문이다. -> 이 장점으로 인해 금융권 및 차세대/MSA 환경에서 이 방식을 선호한다.

● 단점: 한 번 발급된 토큰은 만료될 때까지 서버가 제어하기 어려워 해커가 토큰을 훔쳐가면 서버 측에서 즉시 무효화하기가 매우 까다롭다.

구분	세션( Session )	JWT( JSON Web Token )
저장 위치	서버( Memory, DB, Redis 등 )	클라이언트 ( Local Storage, Cookie 등 )
인증 매개체	세션ID( 단순 문자열 )	토큰 ( 유저 정보가 담긴 암호화된 문자 )
상태 유지	Stateful( 서버가 유저 상태를 기억함 )	Stateless ( 서버가 유저 상태를 기억 안함 )
확장성	상대적으로 낮음 ( 서버간 공유 필수 )	매우 높음 ( 서버 확장시 매우 유리 )
보안 제어	서버에서 즉시 로그아웃 제어 가능	토큰 탈취 시 만료 전까지 제어 어려

2. JWT (JSON Web Token) 특징

1) 자가 수용적 (Self - Contained)

토큰 자체가 정보를 담고 있다.

● 내용: 사용자 식별 정보, 토큰의 발행 일시, 만료 일시, 권한 범위(Scope) 등을 Payload에 담을 수 있다.

● 장점: 서버는 DB를 매번 조회하지 않고도 토큰을 해독하는 것만으로 "이 유저가 누구인지", "이 요청을 할 권한이 있는지" 바로 알 수 있다.

● 활용: 여러 마이크로서비스 ( ex. 계좌 조회 서비스, 이체 서비스 )가 흩어져 있을 때, 각 서비스가 공통 DB에 접근할 필요 없이 토큰만으로 인증을 처리할 수 있어 성능상 매우 유리하다.

2) 무상태성 (Stateless)

서버가 유저의 인증 상태를 유지하지 않는다.

● 내용: 세션은 서버 메모리에 '로그인 상태'를 저장하지만, JWT는 서버에 아무것도 저장하지 않고 토큰의 유효성만 검사한다.

● 장점: 어떤 서버로 요청이 들어와도 동일한 비밀키만 있다면 인증이 가능하기에 서버를 수평적으로 확장하기 매우 쉽다.

3) 무결성 보장 (Integrity via Signature)

JWT는 데이터의 보안(비밀 유지)보다는 데이터가 변조되지 않았음을 보장하는데 특화되어 있다.

● 내용: Signature(서명) 부분이 핵심이다. 서버는 Header + Payload + Secret Key를 조합해 해시값을 만든다.

● 특징: 만약 해커가 Payload에 있는 유저 ID를 내 계정에서 다른 사람 계정으로 바꾸면 서버에서 다시 계산한 서명값과 토큰에 적힌 서명값이 달라지므로 즉시 거부된다.

● 주의사항: 하지만 Payload 자체는 암호화된 것이 아니라 Base64로 인코딩만 된 것이므로 누구나 디콩하여 내용을 볼 수 있다. 따라서 개인정보나 주요 비밀번호 등을 Payload에 넣는 것은 피해야한다.

4) 확장성 (Extensibility)

토큰을 표준화된 방식으로 주고받기 때문에 다양한 환경에서 사용 가능하다.

● 내용: HTTP 헤더의 Authorization: Bearer <token> 형식을 통해 전달되므로, 웹 브라우저뿐만 아니라 모바일 앱(iOS/Android), IoT 기기, 서버 간 통신(M2M) 등 어디서나 인증 체계를 통합할 수 있다.

5) 만료 시간의 명시 (Expiration)

JWT는 생성될 때부터 수명을 가지고 태어난다.

● 내용: Payload의 exp 클레임을 통해 토큰의 유효 기간을 초 단위로 설정한다.

● 사용 전략: 보안을 위해 보통 Access Token의 수명은 매우 짧게 (15~60분)으로 설정한다. 만약 토큰이 탈취되더라도 해커가 사용할 수 있는 시간을 최소화하기 위함이다. 대신 사용자가 계속 로그인 상태를 유지할 수 있도록 Refresh Token을 함께 사용하는 전략을 취한다.

3. JWT 서명(Signature)의 수학적 원리: HMAC과 SHA-256

JWT의 서명은 서버가 해당 토큰을 만든 것이 맞다고 인증하는 인감도장과 같은 역할이다. HMAC SHA-256 알고리즘이 가장 많이 사용된다.

● 원리: 서버는 Base64(Header) + "." + Base64(Payload)라는 문자열을 만들고, 여기에 서버만 아는 비밀키(Secret Key)를 더한 뒤, SHA-256 알고리즘으로 암호화(해싱)한다.

● 안전한 이유: 해시 함수는 입력값이 단 1비트만 바뀌어도 결과값이 완전히 달라지기에 해커가 Payload의 유저 ID를 조금만 바꿔도, 서버가 다시 계산한 결과인 서명과 토큰에 적힌 결과값이 일치하지 않기 때문이다.

● 실무: 서버의 Secret Key가 털리면 모든 보안이 무너지기에 이 키를 코드에 직접 적지 않고, AWS Secrets Manager나 Valut 같은 별도의 관리 도구를 사용해 엄격하게 관리한다.

4. 토큰 저장소에 대한 고민: 어디에 저장할 것인지

1) 로컬 스토리지 (Local Storage)

● 방식: 브라우저의 저장 공간에 텍스트 형태로 저장

● 장점: 구현이 매우 쉽고, 새로고침해도 로그인이 유지된다.

● 단점: 매우 치명적인 단점으로 자바스크립트로 접근이 가능해, 해커가 악성 스크립트를 심으면(XSS), localSotrage.getItem() 한 줄로 사용자의 토큰을 바로 훔쳐갈 수 있다.

2) 쿠키 (Cookie + httpOnly/Secure)

● 방식: HTTP 헤더를 통해 브라우저에 저장

● 보안 설정:

httpOnly: 자바스크립트로 쿠키를 읽을 수 없게 막는다. (XSS 방어)
Secure: HTTPS 통신일 때만 쿠키를 전송한다.
SameSite 타 사이트에서의 요청을 제한하여 CSRF(사이트 간 요청 위조)공격을 방어한다.

● 단점: CSRF 공격에 대한 추가 방어 로직이 필요하며, 모바일 앱과의 통신 시 설정이 번거로울 수 있다.

5. Spring Boot + JWT 구현 코드

1) 설정 정보 분리

Secret Key를 코드에 직접 하드코딩하지 않고 환경 변수로 관리하는 습관을 가진다.

jwt:
  # 실무에서는 환경 변수나 보안 저장소를 통해 주입받는다.
  secret: ${JWT_SECRET_KEY:vmfhaltmskdlfnbmsdfglkjbnm4352t6345b3456b3456b3456}
  access-token-expiration: 3600000 # 1시간 (ms 단위)
  refresh-token-expiration: 1209600000 # 14일

2) JWT 토큰 생성 및 검증 유틸리티 (JwtTokenProvider.java)

가장 핵심이 되는 클래스로, 자바의 jjwt 라이브러리를 사용한다.

@Component
public class JwtTokenProvider {

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

    @Value("${jwt.access-token-expiration}")
    private long expireTime;

    private Key key;

    // 객체 초기화 시 Secret Key를 알고리즘에 맞는 Key 객체로 변환
    @PostConstruct
    protected void init() {
        byte[] keyBytes = Decoders.BASE64.decode(secretKey);
        this.key = Keys.hmacShaKeyFor(keyBytes);
    }

    // 1. JWT 토큰 생성
    public String createToken(String userUid, List<String> roles) {
        Claims claims = Jwts.claims().setSubject(userUid); // Payload에 유저 식별 정보 저장
        claims.put("roles", roles); // 권한 정보 추가

        Date now = new Date();

        return Jwts.builder()
                .setClaims(claims)
                .setIssuedAt(now)
                .setExpiration(new Date(now.getTime() + expireTime))
                .signWith(key, SignatureAlgorithm.HS256) // HMAC SHA-256 서명
                .compact();
    }

    // 2. 토큰 유효성 및 만료 기간 검증
    public boolean validateToken(String token) {
        try {
            Jwts.parserBuilder().setSigningKey(key).build().parseClaimsJws(token);
            return true;
        } catch (SecurityException | MalformedJwtException e) {
            log.info("잘못된 JWT 서명입니다.");
        } catch (ExpiredJwtException e) {
            log.info("만료된 JWT 토큰입니다.");
        } catch (UnsupportedJwtException e) {
            log.info("지원되지 않는 JWT 토큰입니다.");
        } catch (IllegalArgumentException e) {
            log.info("JWT 토큰이 잘못되었습니다.");
        }
        return false;
    }
}

3) Spring Security 필터 연동 (JwtAuthenticationFilter.java)

모든 요청에서 토큰을 검사하여 인증된 사용자인지 확인하는 필터이다.

public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtTokenProvider jwtTokenProvider;

    @Override
    protected void doFilterInternal(HttpServletRequest request, 
                                    HttpServletResponse response, 
                                    FilterChain filterChain) throws ServletException, IOException {
        
        // 1. 헤더에서 토큰 추출
        String token = resolveToken(request);

        // 2. 토큰 유효성 검사 후 SecurityContext에 인증 정보 저장
        if (token != null && jwtTokenProvider.validateToken(token)) {
            Authentication authentication = jwtTokenProvider.getAuthentication(token);
            SecurityContextHolder.getContext().setAuthentication(authentication);
        }

        filterChain.doFilter(request, response);
    }

    private String resolveToken(HttpServletRequest request) {
        String bearerToken = request.getHeader("Authorization");
        if (StringUtils.hasText(bearerToken) && bearerToken.startsWith("Bearer ")) {
            return bearerToken.substring(7);
        }
        return null;
    }
}

4) 추가 사항

실제 서비스라면 validateToken 과정에서 발생하는 에러 메시지를 사용자에게 자세히 보여주지 않도록 커스텀 예외 처리를 구현하는 편이 좋을 것 같다.

6. Refresh Token 관리

1) DB or Redis에 저장해야하는 이유

JWT는 무상태가 장점이지만, Refresh Token만큼은 서버가 상태를 기록해야하므로 따로 저장이 필요하다.

● 강제 로그아웃: 사용자의 기기를 분실하거나 보안 사고가 의심될 때, 서버에서 저장된 Refresh Token을 삭제하여 해커가 더 이상 Access Token을 재발급할 수 없도록 한다.

● 중복 로그인 방지: 특정 계정으로 새로운 기기에서 로그인할 때 기존 토큰을 무효화할 수 있다.

● 탈취 감지: 누군가 Refresh Token을 훔쳐 사용했을 때, 서버가 이를 감지하고 해당 계정의 모든 토큰을 폐기하기 위함이다.

2) DB 설계

가장 기본적인 형태의 Refresh Token 엔티티이다.

@Entity
@Getter
@NoArgsConstructor
public class RefreshToken {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false, unique = true)
    private String userId; // 유저 식별자

    @Column(nullable = false)
    private String token; // Refresh Token 값

    @Column(nullable = false)
    private LocalDateTime expiryDate; // 만료일시

    public RefreshToken(String userId, String token, LocalDateTime expiryDate) {
        this.userId = userId;
        this.token = token;
        this.expiryDate = expiryDate;
    }

    public void updateToken(String newToken, LocalDateTime newExpiryDate) {
        this.token = newToken;
        this.expiryDate = newExpiryDate;
    }
}

3) 로그인 시 저장 로직 (AuthService.java)

사용자가 로그인에 성공하면 Access Token은 클라이언트에게 주고, Refresh Token은 DB에 저장 or 업데이트한다.

@Service
@RequiredArgsConstructor
public class AuthService {

    private final RefreshTokenRepository refreshTokenRepository;
    private final JwtTokenProvider jwtTokenProvider;

    @Transactional
    public TokenResponse login(LoginRequest request) {
        // 1. 유저 인증 로직 (생략)
        
        // 2. 토큰 생성
        String accessToken = jwtTokenProvider.createAccessToken(request.getUserId());
        String refreshToken = jwtTokenProvider.createRefreshToken(request.getUserId());

        // 3. Refresh Token DB 저장 (기존 토큰이 있다면 업데이트, 없다면 새로 저장)
        refreshTokenRepository.findByUserId(request.getUserId())
            .ifPresentOrElse(
                token -> token.updateToken(refreshToken, LocalDateTime.now().plusDays(14)),
                () -> refreshTokenRepository.save(new RefreshToken(request.getUserId(), refreshToken, LocalDateTime.now().plusDays(14)))
            );

        return new TokenResponse(accessToken, refreshToken);
    }
}

4) 토큰 재발급 로직 (Access Token 만료시)

클라이언트가 만료된 Access Token 대신 Refresh Token을 보냈을 때 처리하는 과정이다.

@Transactional
public String refreshAccessToken(String refreshToken) {
    // 1. Refresh Token 유효성 검증
    if (!jwtTokenProvider.validateToken(refreshToken)) {
        throw new RuntimeException("Refresh Token이 유효하지 않습니다.");
    }

    // 2. DB에 저장된 토큰인지 확인
    RefreshToken savedToken = refreshTokenRepository.findByToken(refreshToken)
            .orElseThrow(() -> new RuntimeException("등록되지 않은 토큰입니다."));

    // 3. 만료 여부 추가 확인
    if (savedToken.getExpiryDate().isBefore(LocalDateTime.now())) {
        refreshTokenRepository.delete(savedToken);
        throw new RuntimeException("만료된 토큰입니다. 다시 로그인하세요.");
    }

    // 4. 새로운 Access Token 발급
    return jwtTokenProvider.createAccessToken(savedToken.getUserId());
}

5) 추가 사항

현재 짠 코드는 RDB에 저장하는 코드이지만, 실제 서비스처럼 사용자가 많아지면 매번 재발급할 때마다 DB 조회가 발생하는 것이 부담이 될 수 있다. 따라서 TTL(Time To Live) 기능을 지원하는 Redis를 사용하는 것이 성능과 관리 측면에서 유리할 것이라 생각된다.

Access Token을 재발급할 때마다 Refresh Token도 매번 새로 발급하여 DB를 업데이트하면 더 안전하게 관리할 수 있을 것이다.

7. OAuth 2.0

OAuth 2.0은 내 서비스가 사용자를 대신해 다른 서비스(카카오, 구글, 은행 등)의 데이터에 접근할 수 있는 권한을 얻는 표준이다.

1) 주요 용어

● Resource Owner(사용자): 내 앱을 사용하는 고객

● Client(내 앱): 권한을 부여받아 데이터를 사용하려는 앱

● Authroization Server(인증 서버): 권한을 승인하고 '인가 코드'와 '토큰'을 주는 곳 (카카오, 구글, 금융결제원 등)

● Resource Server(자원 서버): 실제 데이터(프로필, 계좌 내역 등)가 있는 서버

2) Authorization Code Grant(인가 코드 승인 방식)

금융권과 대부분의 상용 서비스에서 표준으로 사용하는 가장 안전한 방식이다.

● '인가 코드'를 먼저 받는 이유: 브라우저(Front-End)를 통해 바로 토큰을 받으면 탈취 위험이 크기에 브라우저를 통해 '인가 코드'만 받고, 실제 열쇠인 Access Token은 백엔드 서버끼리 보이지 않는 곳에서 안전하게 주고받기 위함이다.

● 전체 흐름 (Flow)

권한 요청: 사용자가 앱에서 "카카오로 로그인"을 누르면, 앱이 카카오 인증 페이지로 사용자를 보낸다.
로그인 및 동의: 사용자가 카카오에 로그인하고 정보 제공에 동의한다.
인가 코드 발급: 카카오가 Redirect URI를 통해 앱의 백엔드로 '인가 코드'를 보낸다.
액세스 토큰 교환: 백엔드 서버가 '인가 코드 + Client Secret'을 들고 카카오 서버에 가서 진짜 Access Token과 바꾼다.
데이터 조회: 이제 이 토큰을 사용해 사용자의 프로필이나 금융 정보를 가져온다.

8. OAuth 2.0 Spring Boot 실전 구현 (구조 설계)

1) application.yml 설정

실무에서는 각 플랫폼(카카오, 네이버 등)의 ID와 Secret을 아래와 같이 관리한다.

spring:
  security:
    oauth2:
      client:
        registration:
          kakao:
            client-id: ${KAKAO_CLIENT_ID}
            client-secret: ${KAKAO_CLIENT_SECRET}
            authorization-grant-type: authorization_code
            redirect-uri: "{baseUrl}/login/oauth2/code/kakao"
            client-authentication-method: client_secret_post

2) 사용자 정보 처리 (OAuth2UserService.java)

카카오나 구글로부터 받은 유저 정보를 우리 서비스의 DB에 저장하거나 로그인 처리하는 로직이다.

@Service
@RequiredArgsConstructor
public class CustomOAuth2UserService extends DefaultOAuth2UserService {

    private final UserRepository userRepository;

    @Override
    public org.springframework.security.oauth2.core.user.OAuth2User loadUser(OAuth2UserRequest userRequest) {
        OAuth2User oAuth2User = super.loadUser(userRequest);

        // 1. 어느 플랫폼인지 확인 (kakao, google 등)
        String registrationId = userRequest.getClientRegistration().getRegistrationId();
        
        // 2. 플랫폼별 유저 정보 파싱 (데이터 추출)
        OAuthAttributes attributes = OAuthAttributes.of(registrationId, oAuth2User.getAttributes());

        // 3. 우리 DB에 저장하거나 업데이트
        User user = saveOrUpdate(attributes);

        return new DefaultOAuth2User(
            Collections.singleton(new SimpleGrantedAuthority(user.getRoleKey())),
            attributes.getAttributes(),
            attributes.getNameAttributeKey()
        );
    }
}

3) 추가적으로

한국의 마이데이터 서비스는 OAuth 2.0 기반의 표준 API를 사용하여 사용자가 여러 은행의 정보를 한 앱에서 안전하게 조회할 수 있게 한다. 이 때 보안을 위해 일반 OAuth보다 강화된 MTLS(상호 인증) 등을 결합하기도 한다.

9. 마무리하며

이번에 처음으로 보안에 관련된 내용들을 알아보았다. 기존에 백엔드 개발을 시도했을 때에는 보안에 관해 생각해보지 못하였는데, 이번 학습을 통해 보안에 신경을 써서 개발을 해야겠다고 생각했다.

현재 진행중인 프로젝트에서 당장 JWT의 Acess Token과 Refresh Token을 도입시켜 조금이라도 더 보안을 향상시켜보는 방향으로 우선 도입을 해보아야겠다.

이외에도 실생활에서도 PASS어플이나 카카오 인증하기로 인증을 하는 절차에서 궁금증이 있었는데 OAuth 2.0에 대해 알아보며 이 궁금증도 해결하게 되어 뜻깊은 시간이었던 것 같다.

한층 더 보안에 관심이 생기고 알게 되어 좋았고, 앞으로는 실제 적용시켜 보며 생기는 어려움에 대해서 기록을 남겨보아야겠다.

로그인과 JWT 토큰

junse0 — Wed, 27 Aug 2025 20:45:47 +0900

회원기능 테스트 진행

0. DB 연결

docker-compose up -d --build

도커 DB에 연결

docker ps

3개의 컨테이너가 모두 연결이 완료되었는지 확인

docker에서 이렇게 실행중인 container가 보인다.

1. 회원가입

Invoke-WebRequest -Uri 'http://localhost:8080/v1/auth/signup' -Method POST -Headers @{"Content-Type"="application/json"} -Body '{"email":"test@example.com","password":"password123","name":"테스트 유저"}'

테스트 유저를 회원가입

성공적으로 회원가입 완료.

중복된 유저로 회원가입시 500 코드 응답이 발생

2. 로그인

위에서 회원가입한 아이디로 로그인

Invoke-WebRequest -Uri 'http://localhost:8080/v1/auth/login' -Method POST -Headers @{"Content-Type"="application/json"} -Body '{"email":"test@example.com","password":"password123"}'

토큰의 값을 제대로 확인하려면 아래의 코드로 로그인 해주어야한다.

Invoke-WebRequest -Uri 'http://localhost:8080/v1/auth/login' -Method POST -Headers @{"Content-Type"="application/json"} -Body '{"email":"test@example.com","password":"password123"}' -UseBasicParsing | Select-Object -ExpandProperty Content

액세스 토큰의 유효기간은 15분, 리프레시 토큰은 14일이다.

위에서 얻은 액세스 토큰과 리프레시 토큰은 모두 기록하여둔다 (특히 리프레시 토큰은 꼭)

3. 리프레시

액세스 토큰은 유효기간이 15분이므로, 재발급을 받아주어야한다.

로그아웃할 때 액세스 토큰과 리프레시 토큰이 모두 유효하여야하므로 액세스 토큰이 만료되었다면, 리프레시 토큰을 이용하여 액세스 토큰을 재발급 받는다.

$refreshToken = "여기에_새로_발급받은_리프레시_토큰_값을_붙여넣으세요"

Invoke-WebRequest -Uri 'http://localhost:8080/v1/auth/refresh' -Method POST -Headers @{"Content-Type"="application/json"} -Body '{ "refreshToken": "' + $refreshToken + '" }'

4. 로그아웃

Invoke-WebRequest -Uri 'http://localhost:8080/v1/auth/logout' -Method POST -Headers @{"Authorization"="Bearer <여기에_accessToken_값을_넣으세요>"; "Content-Type"="application/json"} -Body '{"refreshToken":"<여기에_refreshToken_값을_넣으세요>"}'

로그인시에 받았던 액세스 토큰과 리프레시 토큰의 값을 복사하여 해당 부분에 넣어주어야한다.