풀스택
바로가기 바이러스
윈도우 환경에 종속한 바이러스 윈도우와 usb 외장하드등 저장장치에 심어지는 바이러스
리눅스 맥 모바일 환경에서는 존재하지 못하는 형태로 윈도우 사용자들의 불편함을 유발함
주요 문제 usb가 포맷이 안되는 현상 이를 통해 윈도우 설치 usb를 만들면 바이오스에서 인식은 되지만 실행파일을 읽지 못하여 설치환경으로 넘어가지 못하고 바이오스창으로 돌아옴
한번 감염이 된 상태로 다른 pc에 옮겨져서 바로가기가 실행되면 감염 이는 공용 pc등에서 매우 조심해야 하는 부분이다.
pc를 숙주로 삼고 기생하다가 저장장치가 연결되면 감염 시켜 문제를 만든다.
DB
[DB 기초 #1] 관계형 DB(RDBMS) vs NoSQL, 무엇이 다를까? 핵심 차이점 완벽 정리
안녕하세요! 개발자 여러분. 오늘은 백엔드 면접과 시스템 설계의 단골 질문인 '관계형 데이터베이스(RDBMS)'와 'NoSQL'의 가장 큰 차이점에 대해 쉽고 명확하게 정리해 보겠습니다.
📌 가장 큰 차이점: '데이터의 구조화 방식'과 '유연성'
두 데이터베이스를 가르는 핵심은 "데이터를 저장하기 전에 엄격한 틀(스키마)을 정의하느냐, 아니면 자유롭게 저장하느냐"의 차이입니다.
1. 관계형 DB (RDBMS)
- 특징: 데이터를 엑셀 같은 2차원 테이블(행과 열) 형태로 저장합니다.
- 구조: 데이터를 넣기 전에 반드시 어떤 데이터가 들어올지 규칙(Schema)을 엄격하게 정해야 합니다. 데이터 간의 '관계'를 맺어 중복을 최소화합니다.
- 대표 주자: MySQL, PostgreSQL, Oracle
- 장점: 데이터의 정확성과 일관성이 완벽하게 보장됩니다. (금융, 결제 시스템에 필수)
2. NoSQL (Not Only SQL)
- 특징: 정해진 규격 없이 자유로운 형태(JSON 문서, Key-Value 등)로 데이터를 저장합니다.
- 구조: 스키마가 없거나 매우 유연합니다. 데이터가 늘어나면 서버를 여러 대 붙여서 확장(Scale-out)하기가 매우 유리합니다.
- 대표 주자: MongoDB, Redis, Cassandra
- 장점: 대용량 데이터 처리와 빠른 읽기/쓰기에 유리하며, 데이터 구조가 자주 바뀌는 서비스에 적합합니다.
💡 한 눈에 비교하기
| 구분 | 관계형 DB (RDBMS) | NoSQL |
|---|---|---|
| 데이터 구조 | 엄격한 스키마, 테이블 형태 | 유연한 스키마, 다양한 형태 |
| 확장 방식 | 수직 확장 (Scale-Up, 고성능 서버) | 수평 확장 (Scale-Out, 서버 분산) |
| 적합한 서비스 | 데이터 일관성이 중요한 서비스 (금융, 이커머스 주문) | 로그 데이터, 실시간 채팅, 대용량 트래픽 서비스 |
🎯 요약
데이터의 '일관성과 정확성'이 최우선이라면 RDBMS를, 서비스의 '빠른 확장성과 대용량 데이터 처리'가 필요하다면 NoSQL을 선택하는 것이 정답입니다!
[DB 기초 #2] 캐싱(Caching)이 필요한 서비스에 딱 맞는 DB는? (feat. 인메모리 DB)
안녕하세요. 오늘은 수많은 사용자가 몰려도 웹사이트가 버벅이지 않게 만드는 마법인 '캐싱(Caching)'에 대해 이야기해 보겠습니다. 캐싱이 필요한 서비스에는 도대체 어떤 데이터베이스를 써야 할까요?
📌 정답은 'In-Memory (인메모리) DB' 입니다.
캐싱이 필요한 서비스에는 데이터를 하드디스크가 아닌 컴퓨터의 '메모리(RAM)'에 저장하는 NoSQL 기반의 인메모리 DB가 적합합니다. 그중에서도 전 세계적으로 가장 많이 쓰이는 대표적인 DB는 바로 Redis(레디스)와 Memcached입니다.
❓ 왜 인메모리 DB여야 할까?
- 압도적인 속도 (하드디스크 vs RAM)
- 일반적인 DB는 하드디스크(SSD/HDD)에 데이터를 저장하므로 읽고 쓰는 데 시간이 걸립니다. 반면, 인메모리 DB는 모든 데이터를 메모리(RAM)에 올려두고 처리하므로 응답 속도가 마이크로초(μs) 단위로 상상을 초월하게 빠릅니다.
- Key-Value(키-값) 구조의 단순함
- 복잡한 연산 없이 "이 키(Key)에 해당하는 데이터(Value)를 줘!"라고 요청하면 즉시 반환하는 단순한 구조를 가집니다. 부하가 적고 직관적입니다.
🏃♂️ 어떤 서비스에서 주로 쓸까요?
- 포털 사이트 실시간 검색어 및 랭킹: 순위가 실시간으로 바뀔 때
- 로그인 세션 관리: 사용자가 로그인 상태인지 빠르게 매번 확인할 때
- 선착순 이벤트/수강신청: 순간적으로 수만 명의 트래픽이 밀려 들어올 때
🎯 결론
자주 조회되지만 매번 메인 DB에서 가져오기 부담스러운 데이터는, Redis 같은 NoSQL 인메모리 DB에 '캐싱'해 두는 것이 전반적인 서비스 성능을 올리는 핵심 전략입니다.
[DB 기초 #3] 백엔드 면접 단골 질문! PK(기본키)와 FK(외래키) 차이 1분 요약
데이터베이스를 공부할 때 가장 먼저 만나는 단어이자, 면접에서 "한 문장으로 설명해 보세요"라는 요청이 자주 들어오는 PK(Primary Key)와 FK(Foreign Key)의 차이를 깔끔하게 정리해 드리겠습니다.
📌 한 문장 정의
- PK (기본키, Primary Key): 테이블 안에서 각 행(데이터)을 유일하게 구별할 수 있는 고유한 식별자입니다. (예: 주민등록번호, 회원 고유 번호)
- FK (외래키, Foreign Key): 한 테이블이 다른 테이블의 데이터를 참조하고 연결하기 위해 사용하는 열(Column)입니다. (예: 주문 테이블에서 '누가 주문했는지' 회원 테이블의 PK를 가리키는 고유 번호)
🔍 핵심 차이점 비교
| 구분 | PK (기본키) | FK (외래키) |
|---|---|---|
| 목적 | 데이터의 유일성(식별) 보장 | 테이블 간의 연관 관계(연결) 표현 |
| 중복 및 빈 값 | 중복 불가 (Unique), 빈 값 불가 (Not Null) | 중복 가능, 빈 값(Null) 허용 가능 |
| 개수 제한 | 테이블당 단 1개만 설정 가능 | 테이블당 여러 개 설정 가능 |
💡 쉽게 이해하는 예시
'학생' 테이블이 있고 '성적' 테이블이 있다면, 학생 테이블의 학번은 PK가 됩니다. 성적 테이블에서 "이 점수가 어떤 학생의 점수인가?"를 나타내기 위해 학생 테이블의 학번을 가져와 쓰면, 그 성적 테이블의 학번은 FK가 됩니다.
[DB 기초 #4] 게시글에 작성자 이름을 직접 적지 않고 'FK'로 연결하는 진짜 이유 (데이터 무결성)
블로그나 커뮤니티 서비스를 만들 때, 게시글(Post) 테이블이 있을 것입니다. 이때 게시글 테이블에 글쓴이의 이름(예: '홍길동')을 직접 텍스트로 저장하면 편할 텐데, 왜 굳이 유저 테이블의 ID(FK)로 연결해서 저장할까요?
여기에는 데이터베이스 설계의 핵심인 '데이터 무결성'과 '유지보수의 효율성'이 담겨 있습니다. 이유를 3가지로 나누어 설명해 드립니다.
1. 이름이 바뀌었을 때의 대참사 방지 (수정의 용이성)
만약 '홍길동'이라는 유저가 이름을 '홍길순'으로 개명했다고 가정해 봅시다.
- 이름을 직접 저장했다면: 이 사람이 쓴 글이 1만 개라면, 1만 개의 게시글 데이터를 모두 찾아서 이름을 '홍길순'으로 변경해야 합니다. 시스템에 엄청난 부하가 가고, 중간에 오류가 나면 일부 글은 여전히 옛날 이름으로 남는 문제가 발생합니다.
- FK로 연결했다면: 유저 테이블에서 '홍길동'을 '홍길순'으로 딱 한 번만 수정하면 끝납니다. 게시글 테이블은 유저 ID 번호만 바라보고 있으므로 자동으로 바뀐 이름이 화면에 출력됩니다.
2. 데이터 중복 제거와 용량 절약 (정규화)
글쓴이의 이름뿐만 아니라 프로필 사진, 등급, 이메일 등의 정보를 게시글마다 다 저장하면 엄청난 데이터 낭비가 발생합니다. 회원 ID(숫자 데이터) 하나만 FK로 저장해 두고, 필요할 때마다 회원 테이블에서 정보를 불러오는(JOIN) 것이 용량을 아끼고 데이터가 꼬이지 않게(정규화) 만드는 방법입니다.
3. 유령 유저 방지 (참조 무결성)
FK를 설정해 두면 데이터베이스 시스템이 스스로 체크를 해줍니다. 가입하지도 않은 유령 회원의 ID로 글이 작성되는 것을 막아주고, 회원을 탈퇴 처리할 때 그 회원이 쓴 글을 같이 지우거나 탈퇴를 막는 등의 안전장치(참조 무결성)를 세울 수 있습니다.
🎯 한 줄 결론
데이터의 중복을 없애고, 정보가 수정되었을 때 오류 없이 완벽한 일관성을 유지하기 위해 우리는 이름을 직접 적지 않고 FK(외래키)로 연결합니다.
