library_mini.log https://velog.io/ Sat, 14 Feb 2026 15:46:28 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed Copyright (C) 2019. library_mini.log. All rights reserved. <![CDATA[세션과 토큰의 진짜 차이와 사용처]]> https://velog.io/@library_mini/%EC%84%B8%EC%85%98%EA%B3%BC-%ED%86%A0%ED%81%B0%EC%9D%98-%EC%A7%84%EC%A7%9C-%EC%B0%A8%EC%9D%B4%EC%99%80-%EC%82%AC%EC%9A%A9%EC%B2%98 https://velog.io/@library_mini/%EC%84%B8%EC%85%98%EA%B3%BC-%ED%86%A0%ED%81%B0%EC%9D%98-%EC%A7%84%EC%A7%9C-%EC%B0%A8%EC%9D%B4%EC%99%80-%EC%82%AC%EC%9A%A9%EC%B2%98 Sat, 14 Feb 2026 15:46:28 GMT 로그인 기능을 구현하려고 찾아보니, 요즘은 다들 JWT(JSON Web Token) 를 쓰는 추세인 것 같았습니다. 하지만 '남들이 다 쓰니까 나도 쓴다'는 마인드를 버리기 위해, 전통적인 세션(Session) 방식과 어떤 점이 다르고 실제 서비스에서는 각각 언제 쓰이는지 공부해 보았습니다.

1. 세션

세션은 서버의 메모리나 DB에 '누가 로그인했는지(방문자 명부)' 를 적어두고 관리하는 방식입니다. 클라이언트에게는 그 명부의 번호표(ID)만 줍니다.

장점: 서버가 모든 정보를 쥐고 있습니다. 만약 해킹이 의심되거나 비밀번호가 변경되면, 서버에서 그 번호표를 지워버리면 끝입니다. (즉시 강제 로그아웃 가능)

단점: 동시 접속자가 10만 명이 되면, 서버는 10만 명의 명부를 다 들고 있어야 해서 무거워집니다. 서버를 여러 대 늘릴 때 명부를 공유하기도 까다롭습니다.

2. JWT (토큰)

JWT는 서버가 기억하지 않습니다. 대신 '위조 불가능한 전자 출입증' 을 만들어서 클라이언트에게 아예 줘버립니다. 서버는 나중에 클라이언트가 문을 두드릴 때, 출입증이 진짜인지만 검사합니다.

장점: 서버가 누구를 기억할 필요가 없어서(Stateless), 접속자가 아무리 많아져도 서버 메모리에 부담이 없습니다. 서버를 여러 대 띄우기도 아주 쉽습니다.

단점: 한 번 발급한 출입증은 유효기간이 끝날 때까지 서버가 마음대로 뺏을(강제 로그아웃) 수 없습니다. 누군가 출입증을 훔쳐 가면 막기가 까다롭습니다.

그래서 언제, 무엇을 써야 할까?

공부해보니 두 기술은 '좋고 나쁨'이 아니라 '목적' 이 달랐습니다.

세션(Session)이 더 어울리는 곳

보안과 통제가 가장 중요한 서비스

예시: 은행 / 금융권 앱, 사내 관리자(Admin) 페이지, 넷플릭스처럼 '동시 접속 기기 수'를 제한해야 하는 서비스.

이유: 서버에서 특정 사용자를 즉시 차단하거나 관리할 수 있는 강력한 통제력이 필요하기 때문입니다.

JWT(토큰)가 더 어울리는 곳

사용자가 엄청 많고, 확장이 중요한 서비스

예시: 인스타그램 같은 대규모 SNS, 모바일 앱(App) 환경, 백엔드와 프론트엔드가 완전히 분리된 서비스.

이유: 앱 환경에서는 브라우저처럼 세션 관리가 쉽지 않고, 접속자가 많아 서버를 유연하게 늘려야(Scale-out) 하므로 서버가 상태를 가지지 않는 것이 유리하기 때문입니다.

결론 (Insight) 무조건 유행하는 기술(JWT)을 맹신하지 말자.

보안과 강제 로그아웃이 중요하다면 세션, 서버의 확장성과 모바일 환경을 고려한다면 JWT를 선택하는 것이 올바른 기준이다.

내가 앞으로 개발할 API 서버들도 '어떤 종류의 서비스인가' 를 먼저 따져보고 인증 방식을 결정해야겠다.

]]> <![CDATA[200 OK? HTTP 상태 코드 제대로 알고 쓰자]]> https://velog.io/@library_mini/200-OK-HTTP-%EC%83%81%ED%83%9C-%EC%BD%94%EB%93%9C-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90-8hdrkcbg https://velog.io/@library_mini/200-OK-HTTP-%EC%83%81%ED%83%9C-%EC%BD%94%EB%93%9C-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90-8hdrkcbg Thu, 12 Feb 2026 10:17:07 GMT 프로젝트 API를 만들다가, 회원가입에 실패했는데도 습관적으로 200 OK를 리턴하고 있었다. 프론트엔드 입장에서 "성공인 줄 알았는데 열어보니 에러" 인 상황을 막기 위해, HTTP 상태 코드(Status Code)의 의미를 명확히 정리했다.

1. 🟢 성공 (2xx Success)

200 OK: 가장 일반적인 성공. (조회, 수정 등)

201 Created: 리소스가 성공적으로 생성됨. (회원가입, 글쓰기 성공 시 사용)

200 OK

2. 🟠 클라이언트 실수 (4xx Client Error)

400 Bad Request: 요청 파라미터가 틀림. (비밀번호 누락, 이메일 형식이 아님 등)

401 Unauthorized: 인증 안 됨. (로그인 안 하고 접근)

403 Forbidden: 권한 없음. (로그인은 했는데 관리자 페이지에 접근하려 함)

404 Not Found: URL을 잘못 입력했거나, 삭제된 게시물을 조회함.

404 Not Found

3. 🔴 서버 실수 (5xx Server Error)

500 Internal Server Error: 내 코드에 버그가 있거나 DB가 터짐.

500 Internal Server Error

4. 적용 (Insight)

회원가입 성공 시: return ResponseEntity.ok() ➡️ return ResponseEntity.status(HttpStatus.CREATED)로 변경.

비밀번호 틀림: 무조건 200에 메시지만 띄우지 말고, 400이나 401을 명확하게 던져주자.

결론: 정확한 상태 코드는 프론트엔드 개발자와의 약속이다.

]]> <![CDATA[맨날 MySQL만 쓰다가 궁금해서 찾아본 RDBMS와 NoSQL 차이]]> https://velog.io/@library_mini/%EB%A7%A8%EB%82%A0-MySQL%EB%A7%8C-%EC%93%B0%EB%8B%A4%EA%B0%80-%EA%B6%81%EA%B8%88%ED%95%B4%EC%84%9C-%EC%B0%BE%EC%95%84%EB%B3%B8-RDBMS%EC%99%80-NoSQL-%EC%B0%A8%EC%9D%B4 https://velog.io/@library_mini/%EB%A7%A8%EB%82%A0-MySQL%EB%A7%8C-%EC%93%B0%EB%8B%A4%EA%B0%80-%EA%B6%81%EA%B8%88%ED%95%B4%EC%84%9C-%EC%B0%BE%EC%95%84%EB%B3%B8-RDBMS%EC%99%80-NoSQL-%EC%B0%A8%EC%9D%B4 Mon, 09 Feb 2026 13:03:02 GMT "왜 다들 MySQL을 쓸까? 그리고 몽고DB는 언제 쓰는 걸까?" 프로젝트를 할 때마다 습관적으로 MySQL을 설치해서 썼습니다. 문득 '다른 데이터베이스는 언제 쓰는 거지?'라는 의문이 들어서, 가장 대표적인 RDBMS와 NoSQL의 차이점을 공부해보고 정리합니다.

1. 익숙한 친구, RDBMS (MySQL)

지금까지 제가 써왔던 MySQL은 RDBMS(관계형 데이터베이스)였습니다. 공부해보니 가장 큰 특징은 '엑셀(Excel) 표'와 비슷하다는 것이었습니다. 특징: 행(Row)과 열(Column)이 딱 정해져 있습니다. 장점: 데이터의 형태가 일정해서 관리가 쉽고, 테이블끼리 연결(JOIN)해서 정보를 가져오기 좋습니다. 단점: 데이터 구조를 바꾸려면 테이블 전체를 수정해야 해서 번거롭습니다. 내 생각: 회원가입 정보나 결제 내역처럼 '딱 떨어지고 정확해야 하는 데이터'를 저장할 때 좋은 것 같습니다.

2. 자유로운 친구, NoSQL (MongoDB)

NoSQL은 'Not Only SQL'의 약자라고 합니다. SQL 말고 다른 방식도 있다는 뜻인데, 대표적으로 MongoDB가 있습니다. 특징: 표 형태가 아니라, JSON 문서(Document) 형태로 저장합니다. 스키마(구조)가 없어서 데이터를 자유롭게 넣을 수 있습니다. 장점: 데이터 구조가 자주 바뀌어도 상관없고, 읽고 쓰는 속도가 굉장히 빠르다고 합니다. 단점: 데이터가 중복될 수도 있고, 관리가 조금 느슨할 수 있습니다. 내 생각: 게임 로그나 SNS 피드처럼 '엄청 빠르게 쌓이고 형태가 다양한 데이터'에 적합해 보입니다.

3. 그래서 결론은?

무조건 "최신 기술인 NoSQL이 좋다" 가 아니라, 데이터의 성격에 따라 골라 써야 한다는 걸 배웠습니다. 지금 하고 있는 공부나 프로젝트에서는 데이터의 정확성 (관계) 이 중요하기 때문에 MySQL을 계속 사용하겠지만, 나중에 로그를 수집하거나 채팅 기능을 만든다면 MongoDB 도입을 고려해봐야겠습니다.

]]> <![CDATA["Port 8080 was already in use" 해결 방법 (Mac/Windows)]]> https://velog.io/@library_mini/Port-8080-was-already-in-use-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-MacWindows https://velog.io/@library_mini/Port-8080-was-already-in-use-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-MacWindows Mon, 09 Feb 2026 12:28:58 GMT 주니어 개발자라면 누구나 한 번쯤 겪는 '포트 충돌 에러' 해결법입니다. 가장 흔하지만, 막상 닥치면 명령어가 기억 안 나서 검색하게 되는 주제죠.

스프링 부트를 비정상적으로 종료하거나 재시작할 때 자주 마주치는 에러입니다. 매번 검색하기 귀찮아서 제 블로그에 박제 !

1. 문제 상황

IntelliJ에서 신나게 코드를 짜고 Run을 눌렀는데, 아래와 같은 빨간 에러가 뜨면서 서버가 켜지지 않습니다.

Bash

Description: Web server failed to start. Port 8080 was already in use.

Action: Identify and stop the process that's listening on port 8080 or configure this application to listen on another port.

원인 : 이전에 실행했던 서버가 제대로 종료되지 않고 좀비 프로세스처럼 살아있어서, 8080 포트를 계속 붙잡고 있기 때문입니다.

2. 해결 방법

터미널(Terminal)을 열고, OS에 맞는 명령어를 입력해서 좀비 프로세스를 죽여줍니다.

Mac / Linux

1. 포트 8080을 점유 중인 프로세스(PID) 찾기

Bash

lsof -i :8080

위 명령어를 치면 아래처럼 나옵니다. 여기서 PID 숫자를 기억하세요. (예시 : 12345)

2. 해당 프로세스 강제 종료 (Kill)

Bash

kill -9 [PID]

예시: kill -9 12345

Windows (PowerShell)

1. 포트 8080 점유 중인 프로세스 찾기

PowerShell

netstat -ano | findstr :8080

맨 오른쪽 끝에 있는 숫자가 PID입니다.

2. 프로세스 종료

PowerShell

taskkill /PID [PID] /F

(예시 : taskkill /PID 12345 /F)

3. 짧은 회고

교훈: 서버를 끌 때는 가급적 IDE의 Stop 버튼을 눌러서 우아하게 종료하는 습관을 들이자.

에러 메시지를 읽어보면 답이 있다 ! 당황하지 말고 로그를 읽자!

]]>