최신 글
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저) 10~ 11장 정리
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저) 10~ 11장 정리
카테고리 없음
2026.08.30 00:14
10장. 모르면 답답해지는 네트워크 기초네트워크 기초를 모르면서버 장애의 원인이 애플리케이션 코드가 아니라 네트워크 설정에 있을 수 있다.내부 통신에 사용하는 IP와 외부에서 접근할 때 사용하는 IP를 혼동하면 접속 허용 대상을 잘못 지정할 수 있다.서버 개발자가 네트워크를 깊게 알 필요는 없지만, 장애 원인을 찾고 설정 문제를 해결하려면 기본 개념은 알아야 한다.노드, 네트워크, 라우터데이터를 송수신하는 모든 장치를 노드(Node)라고 한다.휴대폰, 노트북, 서버, 네트워크 장비 등이 해당한다.노드가 서로 데이터를 주고받기 위해 연결된 시스템을 네트워크(Network)라고 한다.노드가 네트워크를 통해 전송하는 데이터의 단위를 패킷(Packet)이라고 한다.헤더에는 송수신 정보, 페이로드에는 실제 데이터..
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저) 7~ 9장 정리
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저) 7~ 9장 정리
Study
2026.08.15 20:19
7장. IO 병목, 어떻게 해결하지네트워크 IO와 자원 효율서버는 클라이언트, DB, 레디스, 외부 API 등과 네트워크로 데이터를 주고받는다.네트워크 통신은 데이터를 보내는 write()와 받는 read()로 정리할 수 있다.DB에 SELECT 쿼리를 실행할 때도 서버가 쿼리를 전송하고 DB의 응답을 읽는다.입출력이 끝날 때까지 스레드가 기다리는 것을 블로킹이라고 한다.네트워크 연동이 많은 프로그램은 코드 실행보다 IO 대기에 더 많은 시간을 사용할 수 있다.요청마다 스레드를 할당하면 한 스레드가 IO를 기다리는 동안 다른 요청을 처리할 수 있다. 하지만 트래픽과 함께 스레드 수가 늘어나면 자원 효율이 떨어진다.스레드마다 사용하는 메모리가 증가한다.실행할 스레드를 바꾸는 컨텍스트 스위칭이 늘어난다.컨텍..
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저) 4~ 6장 정리
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저) 4~ 6장 정리
Study
2026.08.02 23:49
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저)📌 Chapter 04. 외부 연동 장애 대응외부 연동(결제, 알림, 검색, LLM API 등)은 내가 통제할 수 없는 영역이다. 이 장의 핵심은"외부 서비스가 느려지거나 죽어도, 내 서비스 전체가 같이 죽지 않게 만드는 것"이다.1. 타임아웃 (Timeout)가장 기본이면서 가장 자주 놓치는 설정. 타임아웃을 설정하지 않으면 스레드가 무한정 대기하게 되고,그 스레드들이 쌓이면 스레드 풀이 고갈되어 정작 멀쩡한 다른 요청까지 처리 못 하는 연쇄 장애로 번진다.구분설명권장 범위연결 타임아웃 (Connection Timeout)TCP 연결 자체를 맺는 데 걸리는 최대 대기 시간3초 ~ 5초읽기 타임아웃 (Read Timeout)연결 후 응답을 받..
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저) 1 ~ 3장 정리
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저) 1 ~ 3장 정리
Study
2026.07.19 02:39
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저)Chapter 01. 들어가며1장. 신입 개발자 A의 일화개발자 A는 내부 직원이 사용할 간단한 사이트를 만들었다.얼마안가 오류가 발생한다는 연락을 받았다.개발자 A가 개발 주소에 접근하니 DB에 연결할 수 없다는 오류가 발생한다.일부 코드에서 사용이 끝난 DB 커넥션을 닫지 않은 것이다.// 개발자 A가 작성한 문제의 코드Connection conn = ds.getConnection(); // 커넥션 풀에서 구함try {} catch (Exception e) { ... 에러 처리}// conn.close()가 누락 -> 커넥션 풀에 반환하지 않음DB 커넥션을 사용한 뒤 풀에 반환하지 않았고 그로 인해 커넥션이 누수되었다.결국 풀에 있던 ..
[짠팟] 인프라 개선 방향에 대한 고민
[짠팟] 인프라 개선 방향에 대한 고민
짠팟
2026.04.19 21:05
짠팟 인프라 개선 방향 — 보안과 확장성현재 단일 EC2 구조에서 발생할 수 있는 위험 요소를 분석하고, 트래픽 증가와 보안 위협에 대응하기 위한 AWS 인프라 개선 방향을 정리합니다.1. 현재 아키텍처 구조현재 짠팟의 전체 서버 흐름은 아래와 같습니다. 현재 짠팟은 VPC 내 Public/Private Subnet이 분리된 구조입니다. EC2(Nginx, Spring Boot Blue/Green, Prometheus+Grafana)는 Public Subnet에, RDS는 Private Subnet에 위치하여 외부 직접 접근이 차단되어 있습니다. 단, EC2는 단일 인스턴스로 운영 중이며 단일 AZ(ap-northeast-2a)에 집중되어 있습니다.2. 현재 구조의 위험 요소현재 짠팟은 모든 것이 EC2..
인기 글
주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저) 7~ 9장 정리
Study2026.08.15 20:19주니어 백엔드 개발자가 반드시 알아야할 실무지식 (최범균 저) 7~ 9장 정리

7장. IO 병목, 어떻게 해결하지네트워크 IO와 자원 효율서버는 클라이언트, DB, 레디스, 외부 API 등과 네트워크로 데이터를 주고받는다.네트워크 통신은 데이터를 보내는 write()와 받는 read()로 정리할 수 있다.DB에 SELECT 쿼리를 실행할 때도 서버가 쿼리를 전송하고 DB의 응답을 읽는다.입출력이 끝날 때까지 스레드가 기다리는 것을 블로킹이라고 한다.네트워크 연동이 많은 프로그램은 코드 실행보다 IO 대기에 더 많은 시간을 사용할 수 있다.요청마다 스레드를 할당하면 한 스레드가 IO를 기다리는 동안 다른 요청을 처리할 수 있다. 하지만 트래픽과 함께 스레드 수가 늘어나면 자원 효율이 떨어진다.스레드마다 사용하는 메모리가 증가한다.실행할 스레드를 바꾸는 컨텍스트 스위칭이 늘어난다.컨텍..

HTTP vs HTTPS 환경에서의 쿠키 보안 설정
블로그 3기2026.02.19 00:06HTTP vs HTTPS 환경에서의 쿠키 보안 설정

HTTP vs HTTPS 환경에서의 쿠키 보안 설정 Spring Boot로 인증 시스템을 구현하다 보면, 로컬 개발 환경과 배포 환경에서 쿠키 설정을 다르게 해야 하는 상황을 마주하게 됩니다.이번 글에서는 왜 그래야 하는지, 그리고 쿠키 보안의 전반적인 개념을 정리해보겠습니다.1. 문제 상황: 왜 환경마다 쿠키 설정이 다를까?Spring Boot에서 Refresh Token을 쿠키로 관리할 때, 보통 이런 식으로 환경별 설정을 분리합니다.# application-local.yml (로컬 개발)security: cookie: refresh: secure: false same-site: Lax# application-prod.yml (배포)security: cookie: re..

[Keepit] Spring Security OAuth2 소셜 로그인에서 JSESSIONID가 생성되는 문제 해결하기
블로그 3기2026.02.08 22:30[Keepit] Spring Security OAuth2 소셜 로그인에서 JSESSIONID가 생성되는 문제 해결하기

JWT 토큰 기반 인증인데 왜 세션 쿠키가 날아가는 걸까? Spring Security의 SecurityContext 저장 메커니즘을 파헤쳐보자.1. 문제 발견프론트엔드 개발자로부터 이런 피드백을 받았다. "배포 환경에서 보니까 쿠키를 통해 세션 ID, 그리고 리퀘스트 헤더에 액세스 토큰을 같이 보내네요. 토큰 + 세션 기반이 중복으로 처리되고 있는 것 같습니다. 저희는 토큰 기반이기 때문에 세션은 필요 없지 않을까 싶습니다." 우리 프로젝트는 Spring Boot + JWT 토큰 기반 인증 구조다. SessionCreationPolicy.STATELESS로 세션을 사용하지 않도록 설정했고, OAuth2 인가 요청도 세션 대신 쿠키에 저장하는 HttpCookieOAuth2AuthorizationReque..

[네트워크] 쿠키, 세션, JWT, 인증 그리고 웹 보안 등
블로그 3기2026.01.25 00:16[네트워크] 쿠키, 세션, JWT, 인증 그리고 웹 보안 등

쿠키와 세션의 차이사용 이유HTTP 프로토콜의 특징이자 약점을 보완하기 위해 사용한다.HTTP는 Connectionless 즉, 비연결형 프로토콜이다. 클라이언트가 서버에 요청을 했을 때, 그 요청에 맞는 응답을 보낸 후 연결을 끊는 처리 방식이다. HTTP가 TCP(TCP:연결 지향) 위에서 구현되었기 때문에 연결지향이라는 논란이 있지만, 서버 측에서 비연결 지향적인 특성으로 커넥션 관리에 대한 비용을 줄이는 것이 명확한 장점으로 보기 때문에 비연결 지향으로 생각하자.HTTP는 Stateless 프로토콜 커넥션을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다. 하지만, 실제로는 데이터 유지가 필요한 경우가 있다. → 따라서, Stateful 경우를 대처하기 위해 쿠..

스프링 AI : 2. 프로젝트 생성 및 OpenAI 의존성
Spring2025.08.02 15:19스프링 AI : 2. 프로젝트 생성 및 OpenAI 의존성

이 글은 유튜브 개발자 유미 영상을 바탕으로 개인적인 정리를 위해 작성한 글입니다.https://www.youtube.com/watch?v=-g6goXtCilM&list=PLJkjrxxiBSFCgcsP_pzuntmqC3AlTMWFx스프링 AI : OpenAI스프링 AI 의존성들을 활용하기 위한 스프링 부트 프로젝트를 생성한다. 첫번째 의존성 활용은 OpenAI이다.스프링부트 기반의 웹 서비스를 구축하며, 그 웹 서비스에서 OpenAI의 서비스가 필요한 경우,기존에 RestTemplate, WebClient와 같은 API 호출 클라이언트를 통해 모든 과정을 작성해야했다. 하지만 OpenAI 의존성만 사용하면 위 과정들을 추상화하여 사용할 수 있다. OpenAI 클라이언트 등록OpenAI API를 활용하기 ..

스프링 심화 1기
[중간발표] B2B2C SaaS 대기열 서비스
[중간발표] B2B2C SaaS 대기열 서비스
스프링심화1기
2024.10.11 00:30
중간발표 자료  Monorepo를 통해 멀티모듈 구조를 채택했고, 루트 프로젝트에서 각각의 서브 프로젝트를 관리하고versions.properties를 통해 여러 서버에서 사용하는 JWT 같은 의존성의 버전을 통합관리했다.브랜치 전략으로는 main-dev-hotfix-feature로 이슈를 발행한 후 해당 브랜치를 파고, PR과 코드리뷰를 통해 이슈와 브랜치를 닫는 전략을 사용했다. 또한 sprint 단위로 일정을 관리했다.이번 프로젝트에서 기획한 서비스는 B2B2C로, 서비스의 사용자는 대기열 서비스를 원하는 기업의 개발자가 될 것이며, 해당 기업은 엔드포인트 사용자에게 서비스를 제공하는 구조로 이루어져 있다.처음에 각자 개발하고 싶은 부분을 고민하다가, 개발자를 위한 서비스를 만들면 어떨까라는 의견이..
Chapter 5. 팀 프로젝트 2주차 WIL
스프링심화1기
2024.10.07 14:36
Weekly I Learned 2주차 간단 요약- 프로젝트 주제 선정 후 설계 과정 이번 프로젝트에서 Kafka 도입을 통해서 최대한 안정성 있게 데이터처리를 하고자 한다.구현 과정에서 높은 러닝 커브가 있고 이슈가 매번 생길 때 로깅에 대한 전략이 필요한데 이런 경우를 대비해서 이벤트 소싱 패턴을 전략을 사용하려 한다. 이벤트 소싱 패턴 (Event Sourcing Pattern) 이란?해당 패턴의 전략의 기본은 데이터를 저장하는 방법에 대한 정의이다.일반적으로 우리는 데이터를 저장할 때, 최종적인 데이터 값만 저장한다. 하지만 이벤트 소싱 패턴은 해당 과정 속 모든 순간의 이벤트를 저장하는 거라고 생각하면 쉽다!어플리케이션의 모든 상태 변화를 순서에 따라 이벤트로 보관한다.일반유저요청(주문)요청(추가..
Domain Driven Design (DDD)
Domain Driven Design (DDD)
스프링심화1기
2024.09.09 11:03
2024.09.05(금) 특강 정리 1. DDD의 개념과 등장 배경소프트웨어를 설계할 때 고객의 요구사항을 정확히 이해하는 것이 중요하다.요구사항을 잘못 이해하면 잘못된 기능을 만들고 수정하는 것도 어렵다. 그럼 이런 문제는 왜 발생할까?과거에는 주로 기술 중심의 개발 방법론이 사용되었기 때문이다.이러한 방법론은 기술적 요구사항을 중점적으로 다루지만,비즈니스 측면에서 발생하는 다양한 요구사항을 효과적으로 반영하기에는 한계가 있었다. 특히, 비즈니스 전문가와 개발자 간의 소통이 원활하지 않으면, 최종 소프트에어가 비즈니스의 실제 요구를 충족시키지 못할 수 있었다.이러한 문제점들을 해결하기 위해 나온 설계가 도메인 주도 설계(Domain Driven Design)이다. '도메인'이란 소프트웨어로 해결하려는 ..
회고
image