AWS 무료티어 기간이 전부 소모되어 갈쯤 미니PC를 사서 서버를 마이그레이션 해보고자 해서 중고나라에서 구매하였다.가격은 46만원... ryzen 5700u, ram 32GB, m.2 512GB요새 램값이며 ssd값이며 AI 돌풍 덕분에 엄청 가격이 올랐다. 그거 치고는 잘 산듯! 먼저 우리집 환경(?)을 살펴보자면메인 pc는 집에서 개발 및 서핑용으로 사용하고 있다미니PC는 서버 겸 넷플릭스나 유튜브 보기용으로 사용할 예정마침 구매한 미니PC가 윈도우 버전이 pro이기도 하고, linux를 바로 깔기에는 좀 아깝다고 생각했다. 제일 처음 생각 프로세스는 이거였다.미니PC가 윈도우 프로니까 pro버전은 윈도우 원격(MSTSC)가 가능함wsl이라고 윈도우에서 리눅스기능을 파워쉘에서 사용할 수 있게 해주는..

1. 문제 상황 (Issue)현상: API 호출 시 400 Bad Request조치 내용: 운영 서버(EC2)에 접속해 Nginx 컨테이너 설정을 수동으로 수정하여 정상 작동을 확인.재발: GitHub Actions를 통해 자동 배포를 진행하면 수정한 설정이 사라지고 다시 에러 발생. 어제 고쳤는데 오늘 다시 터지는 '무한 루프' 상황 발생.2. 원인 분석 (Root Cause)🔍 기술적 원인: 잘못된 Nginx 설정400 에러: proxy_set_header Connection ""; 설정 때문. SSE(Server-Sent Events)를 위해 추가했으나, Spring Boot(Tomcat)는 Connection 헤더가 비어 있으면 보안상 비정상 요청으로 판단해 입구를 차단함.🔍 구조적 원인: G..

최근 프로젝트를 EC2 운영 환경에 배포하던 중 로컬에서는 정상적이던 로그인이 배포 서버에서만 실패하는 현상을 겪었다. 결론부터 말하면 사소한 포트 번호 오타와 도커 컴포즈의 환경변수 주입 시점 문제였으며 그 해결 과정을 기록으로 남긴다.1. 문제 발생: "로컬은 되는데 배포 환경만 안 된다?"본인은 로컬 개발 시 빠른 피드백과 디버깅을 위해 Spring Boot와 React는 로컬 호스트(Localhost)에서 직접 실행하고 Redis와 DB만 도커 컨테이너로 띄워 사용한다.로컬에서는 Spring이 도커에 뜬 Redis 포트(6379:6379 매핑)를 통해 localhost:6379로 바로 접속하므로 아무런 문제가 없었다. 하지만 모든 서비스를 도커 컨테이너화하여 올린 배포 환경에서는 상황이 달랐다.로..

React, Spring Boot, MySQL을 Docker Compose로 묶고 Nginx를 리버스 프록시로 두는 구조를 구성했다.로컬 환경에서는 정상적으로 동작하던 API가 Docker 환경에서 실행하자마자 프론트엔드 요청에 대해 계속 401 에러를 반환했다.백엔드 서버는 분명 실행 중이었고 Spring Security 설정도 permitAll()로 열어둔 상태였다.그래서 처음에는 자연스럽게 이런 생각이 들었다. “401이면 권한 문제잖아?”“그럼 Security 설정이 문제 아닌가?” 401 에러를 보고 처음 들었던 생각내가 알고 있는 401 에러는 명확했다.인증이 안 되었을 때토큰이 없거나 잘못되었을 때권한이 없는 요청일 때그래서 이 상황이 더 이상했다. JWT도 아직 적용하지 않음, 모든 요..

Nginx의 주요 역할웹서버 (Web Server): 사용자의 요청(Request)을 받아 정적인 파일(HTML, CSS, 이미지 등)을 전달(Serve)하는 기본 역할이다.리버스 프록시 (Reverse Proxy): 사용자의 요청을 받아서, 그요청을 대신 내부의 다른 서버(Node.js, Java 애플리케이션)로 전달하고 응답을 다시 사용자에게 보내주는 중개자 역할이다. 이 역할이 핵심 강점이다.로드 밸런서(Load Banancer): 요청이 폭주할 때, 여러 개의 서버에 요청을 균등하게 나누어 분산시켜주는 역할이다.Nginx의 장점: 비동기 이벤트 기반 아키텍처Nginx가 빠르고 강력한 이유는 비동기 이벤트 기반 아키텍처 덕분이다.동시성 처리: 대부분의 서버들은 요청마다 새로운 프로세스나 스레드를 생..

도커란?도커(Docker)는 애플리케이션을 실행하는 데 필요한 환경을 **컨테이너(Container)**라는 형태로 묶어 언제 어디서나 동일한 환경에서 실행할 수 있게 만들어주는 플랫폼이다.즉 “내 컴퓨터에서는 되는데?” 같은 문제를 해결해주는 강력한 개발·배포 도구다. 도커는 운영체제를 통째로 가상화하지 않고 필요한 실행 환경만 가볍게 격리해서 실행한다는 점에서 기존의 VM과 큰 차이가 있다.Virtual Machine vs Docker도커를 이해하려면 먼저 기존 가상화 방식인 **Virtual Machine(버추얼머신)**과 비교하는 것이 가장 쉽다.Virtual Machine(버추얼머신)버추얼머신은 하드웨어 위에 또 하나의 운영체제(OS)를 통째로 올리는 방식의 가상화 기술이다.구조[Hardware..

API 설계를 하면서 POST 요청에서 Response에 데이터를 포함하는 것에 대해 중요한 깨달음을 얻었다.처음에는 회원가입이나 글 작성 같은 POST 요청에서는 "회원가입 완료", "글 작성 완료" 같은 단순 메시지만 반환하면 충분하다고 생각했다. GET 요청에서는 데이터를 포함해서 반환하는 것이 당연하지만 POST는 결과 자체만 알면 된다고 설계 초기에는 판단했기 때문이다. 고민하면서 깨달은 점은 POST 요청에서도 데이터를 함께 반환하면 클라이언트 입장에서 효율성이 크게 증가한다는 것이다.예를 들어 회원가입을 생각해보자.사용자가 회원가입 폼에 정보를 입력하고 완료한 뒤 로그인을 하는 플로우가 있을 때 POST Response에 새로 생성된 회원 정보를 포함하면 클라이언트는 추가적인 GET 요청 없..

프로토콜을 알아야하는 이유는 실제 서비스의 동작 원리를 정확히 이해하고 문제를 해결하며 보안과 성능을 개선하기 위해서도 있지만 근본적인 것은 역시 문제해결인 것 같다. 인터넷과 네트워크는 도로프로토콜은 그 위를 달리는 차와 신호체계백엔드 개발자는 차를 운전하며 도로 설계까지 한다.프로토콜을 모르면 눈 가리고 운전하는 격. 코딩을 할 때 내부적인 오류 Exception, 런타임 에러등의 문제도 있지만 만약 DNS를 아예 모른다고 가정하면 우리가 브라우저에 도메인을 입력해도 404, DNS_PROBE_FINISHED_NXDOMAIN같은 오류를 만나면 원인을 알수 없다. 서버에 배포했는데 도메인을 연결이 안되는 경우에 DNS의 A 나 CNAME 설정 개념이 없으면 문제 해결이 안된다. 만약 우리가 클라우드 서..