Data_study_clip

트래픽 폭주 : 캐시(Cache) vs Queue(메시지 큐)

dev_SiWoo — Fri, 17 Jul 2026 09:35:46 +0900

들어가며

트래픽이 폭주하여 서버가 느려졌다. 이 때, 캐시(Cache)와 메시지 큐(Queue) 중 어느 것을 도입해야하는가?

진짜 문제를 해결하기 위해서는 '원인(병목)'을 먼저 찾아 그에 알맞게 선택해야한다.

1. 캐시(Cache)

느려진 원인이 반복적인 데이터 조회(Read) 때문일 때.

데이터베이스(DB)까지 가지 않고 메모리에서 데이터를 즉시 반환(조회 속도 O(1))하여 서버와 DB의 연산 부담을 줄임.

2. 메시지 큐(Queue)

느려진 원인이 무거운 작업이나 쓰기/생성(Write) 요청 때문일 때.

서버가 요청을 받자마자 메시지 큐에 던져두고 사용자에게는 "접수 완료" 응답을 바로 보냄.

실제 무거운 처리는 백엔드에서 비동기(Asynchronous)로 차례차례로 처리한다.

3. 병목을 찾는 모니터링 도구

"조회가 문제인지, 쓰기가 문제인지"를 감으로 찍어 맞출 수는 없다.

인프라의 상태와 서비스 내부 상황을 정밀하게 관측(Observability)하기 위해 아래와 같은 도구들을 고려해볼 수 있다.

1) 프로메테우스 (Prometheus) : 인프라의 '바이탈 사인' 측정

서버, 데이터베이스, 네트워크 장비의 하드웨어 및 시스템 자원 현황(Metrics)을 수집하는데

보통 CPU 사용량, 메모리 잔량, 디스크 I/O, 네트워크 대역폭)를 실시간으로 기록한다.

2) 그라파나 (Grafana) : 데이터를 한눈에 보는 '대시보드'

프로메테우스나 APM이 수집한 수많은 가공되지 않은 데이터를 시각적 대시보드로 그려준다.

뛰어난 시각화 기능과 자유로운 커스텀이 장점이며, 임계치(예: CPU 사용량 80% 이상)에 도달하면

슬랙이나 디스코드로 경보(Alerting)를 보낼 수 있다.

3) APM (Application Performance Monitoring) : 소스 코드와 DB의 'MRI 촬영'

애플리케이션 내부로 들어가 어떤 소스 코드 라인, 어떤 데이터베이스 쿼리문(Traces)이 지연을 유발하는지 정밀 추적한다.

▶ 오픈소스 도구: Pinpoint(핀포인트), Scouter(스카우터), SigNoz(시그노즈) 등이 존재

프로메테우스로 "DB 서버 부하가 높다"는 것을 알았다면, APM을 열어 구체적으로

"어떤 API 호출과 어떤 SQL 쿼리가 DB를 죽이고 있는지" 범인을 잡아낼 수 있다.

Schema - DBMS별 용어 구분

dev_SiWoo — Wed, 15 Jul 2026 19:39:16 +0900

Schema

Schema는 테이블, 뷰, 인덱스 등의 데이터베이스 객체를 구분하고 관리하는 이름 공간이다.

그런데 Schema라는 용어는 MariaDB, PostgreSQL, Oracle에서 조금씩 다른 의미로 사용된다.

따라서 사용하던 DBMS가 변경되면 같은 Schema라는 표현 때문에 데이터베이스 구조를 혼동할 수 있다.

DBMS별 구조를 간단히 정리하면 다음과 같다.

MariaDB

DB 서버 → Database(= Schema) → Table

PostgreSQL

DB 서버 → Database → Schema → Table

Oracle

DB 서버·인스턴스 → PDB → User(≒ Schema) → Table

우리 회사 AI는 왜 인사팀 대외비를 일반 직원에게 유출했을까?

dev_SiWoo — Thu, 21 May 2026 16:32:50 +0900

들어가며

기업용 생성형 AI 시장의 판도가 하루가 다르게 바뀌어가고 있다. 기존의 AI 도입이 직원의 질문에 단순히 사내 문서를 찾아 답변만 전달하는 수동적인 '조회용 챗봇(Passive RAG)' 수준에 머물렀다면, 이제는 시스템이 스스로 판단하고 워크플로우를 리드하는 단계로 진화하기 위한 과속 페달을 밟고 있다.

그러나 대다수 기업이 초기 RAG 시스템을 프로덕션(실서비스) 환경에 배포한 뒤, 복잡한 사내 매뉴얼의 표(Table) 인식 오류, 구버전 문서 간섭으로 인한 오답 생성, 그리고 사내 계정 권한(ACL) 분리 실패로 인한 보안 리스크 등 하드코어한 실무 환경의 거대한 벽에 부딪혀 좌절하곤 한다.

가장 뼈아픈 실책은 일반 직원이 챗봇에 던진 무심한 질문에 AI가 인사팀의 대외비 연봉 테이블이나 임원 회의록을 긁어다 친절하게 요약해 주는 대형 보안 사고다. LLM은 환각을 일으킨 것이 아니다. 전산팀이 구축해 놓은 데이터 파이프라인이 권한 검증 없이 대외비 문서를 검색해 바쳤고, LLM은 입력된 컨텍스트에 맞춰 성실하게 답변을 생성했을 뿐이다.

이러한 '프로덕션의 지옥'을 아키텍처 구조 자체로 방어하기 위해 고안된 구조가 바로 아래의 '단일 오케스트레이터(Orchestrator) 기반 고도화 RAG(Advanced RAG) 아키텍처'다. 단순히 컴포넌트 간 선만 무지성으로 연결한 프로토타입을 넘어,
RAG 백엔드 서버를 강력한 제어 중추로 두고 적재와 질의의 전 과정을 통제하는 구조다.

데이터 적재 파이프라인 (정기 배치 및 동기화)

사내의 파편화된 지식 자산을 가공하여 벡터 데이터베이스에 안전하게 체계화하는 전처리 과정이다.

문서 추출: 사내 위키, 매뉴얼 PDF, 업무용 문서 등 신규 및 변경 데이터가 발생하는 즉시 백엔드 서버가 이를 감지하여 안전하게 수집한다.
문맥 분할: 수집된 문서 원본은 독립된 '청킹 엔진(Chunking)'으로 전달되어 문맥의 흐름과 레이아웃이 깨지지 않도록 정교하게 분할된다.
청크 전달 및 벡터 저장: 구조화가 완료된 정돈된 텍스트 조각들이 임베딩 모델로 전송되어 고차원 벡터값으로 변환된 후, 벡터 DB(Vector DB)의 지정된 공간에 저장된다.
텍스트 적재 : 추후 답변 생성 시 원문을 대조하고 출처 정보를 정확히 매핑할 수 있도록, 벡터 값과 1:1로 대응되는 실제 텍스트 원문 및 메타데이터를 벡터 DB 내에 함께 적재한다.

실시간 질의 파이프라인 (사용자 요청 대응)

임직원이 자연어로 질문을 던졌을 때, 백엔드 서버가 게이트키퍼(Gatekeeper) 역할을 수행하며 실시간으로 응답을 도출해 내는 오케스트레이션 과정이다. 위 아키텍처에 명시된 세부 8단계 흐름을 핵심 모듈별로 압축하여 수행한다.

질문 입력 및 벡터 반환: 임직원이 사용자 UI를 통해 질문을 입력하면 백엔드 서버는 이를 가로채 적재 파이프라인과 공유되는 단일 임베딩 모델로 전송, 질문의 맥락을 고차원 벡터로 변환받는다.
유사도 검색 및 Top-K 반환: 백엔드 서버가 질문 벡터를 들고 벡터 DB에 쿼리를 날려 수학적으로 가장 유사도가 높은 최적의 연관 문서 조각 상위 K개(Top-K)를 반환받는다.
질문 + 청크 조합 및 최종 답변 생성: 백엔드 서버가 검색된 문서 정보(Context)와 사용자의 원래 질문을 결합하여 엄격한 시스템 프롬프트를 구성해 대형 언어 모델(LLM)에 전달하고, 팩트에 기반한 답변을 생성한다.
답변 표출: 백엔드 서버가 최종 생성된 답변과 정확한 출처 메타데이터를 가공하여 사용자 UI에 가시화하며 프로세스가 종결된다.

사용자 접근 권한(ACL) 기반 사전 필터링 메커니즘과 동적 동기화의 기술적 한계

해법: 사용자가 질문을 입력하는 순간, RAG 백엔드 서버가 해당 사용자의 사내 로그인 세션 정보(부서, 직급 등)를 강제로 결합한다. 이후 유사도 검색 단계에서 백엔드 서버는 벡터 DB에 단순히 질문만 던지지 않고, "이 질문과 유사한 청크를 찾되, 현재 로그인한 직원의 권한 등급 코드가 일치하는 문서 안에서만 찾아라"라는 메타데이터 사전 필터링(Metadata Pre-filtering) 조건을 쿼리에 주입한다. 권한이 없는 대외비 문서는 검색 대상에서 원천 배제되므로 보안 사고가 차단된다.
실무 아키텍처의 리얼 테크 포인트: 단순히 쿼리 필터를 거는 것은 시작일 뿐이다. 엔터프라이즈 환경에서 문서의 열람 권한(ACL)은 실시간으로 바뀐다. 인사팀에서 대외비 문서의 권한을 변경했을 때, 벡터 DB 내에 이미 적재된 수백만 개 청크의 메타데이터 권한 값을 실시간으로 동기화(Upsert)하는 동적 권한 동기화 배치 파이프라인이 백엔드 내부나 인접 인프라(예: Active Directory 연동 모듈)에 반드시 유기적으로 맞물려야만 이 아키텍처가 실제로 작동한다.

구조적 청킹을 통한 비정형 테이블 데이터 파싱 및 고차원 벡터 임베딩의 공간적 한계

해법: 문서를 그냥 텍스트로만 무지성으로 긁어대면 표의 가로세로 줄이 다 무너지고 숫자가 뒤섞여 AI가 수치 계산을 완전히 틀리게 된다. 이를 막기 위해 위 아키텍처에서는 백엔드가 문서를 추출한 직후, 곧바로 임베딩 모델로 보내지 않고 독립된 청킹 엔진(Chunking) 단계를 거치게 만든다.

이 컴포넌트는 단순 텍스트 추출기가 아니라, PDF나 Word 문서 내의 표 구조를 인지하여 마크다운(Markdown)이나 HTML 형태의 구조화된 텍스트로 트랜스파일링하는 역할을 수행한다. 표의 행과 열 맥락이 완벽히 보존된 데이터가 임베딩 모델로 넘어가므로, 최종 단계에서 LLM이 복잡한 전산 매뉴얼의 수치를 정확하게 읽어낼 수 있다.
실무 아키텍처의 리얼 테크 포인트: 표를 마크다운 텍스트로 이쁘게 가공하더라도, 기존의 표준 텍스트 임베딩 모델은 그리드(Grid) 형태의 2차원 공간 좌표와 행·열의 상관관계를 완벽히 포착하지 못한다. 즉, 유사도 검색 단계에서 정작 중요한 표 청크 자체가 누락될 위험이 상존한다.

따라서 완벽한 프로덕션을 위해서는 청킹 엔진 단계에서 표를 요약한 텍스트로 임베딩을 따로 파서 원문 표에 매핑하는 멀티 벡터 리트리버(Multi-Vector Retriever) 전략을 병행하거나, 테이블 전용 비전 멀티모달 임베딩 아키텍처를 적용하는 고도화 작업이 백엔드 단에서 추가로 뒷받침되어야 한다.

시계열 데이터 버전 관리를 위한 메타데이터 필터링 및 리랭킹 알고리즘의 적용 범위와 거버넌스 과제

해법: 과거 규정과 최신 규정이 시스템 내에 공존할 때 발생하는 지식 오염 문제는 점선으로 표시된 텍스트 적재 단계를 통해 해결된다. 문서를 파이프라인에 태울 때 {상태: 최신(Active), 개정일자: 2026-05-21} 같은 데이터 꼬리표를 청크에 새겨 넣는 것이다. 이후 백엔드 서버가 유사도 검색 및 반환 과정을 제어할 때 최신 문서만 필터링하거나, 검색 결과로 올라온 청크들을 백엔드 내부에서 날짜순으로 재정렬하는 리랭킹(Reranking) 추론 알고리즘을 수행하여 과거 데이터의 간섭을 무력화한다.
실무 아키텍처의 리얼 테크 포인트: 리랭킹 모델은 질문과 텍스트의 '문맥적 친밀도' 점수를 다시 매겨줄 뿐, 어떤 문서가 팩트로서 진짜 최신 규정인지 스스로 판단하는 솔루션이 아니다. 만약 'Active' 상태인 서로 다른 팀의 가이드라인이 충돌한다면 리랭킹만으로 해결할 수 없다. 시스템적 필터링 이전에, 사내 데이터 소스를 정제하고 오래된 중복 문서를 아카이빙(Archiving)하는 철저한 데이터 거버넌스(Data Governance) 정립이 전제되어야 아키텍처가 제 성능을 100% 발휘한다.

맺으며

초기 단계의 RAG 아키텍처는 구축의 용이성이라는 장점이 있으나, 실제 프로덕션 환경이 요구하는 엄격한 보안 규정, 데이터의 최신성, 그리고 비정형 데이터의 복잡성을 수용하기에는 명확한 한계를 지닌다. 권한 검증 없는 데이터 노출이나 깨진 표 데이터 기반의 오답 생성은 생성형 AI 도입의 투자자본수익률(ROI)을 완전히 무력화하는 치명적인 리스크로 작용한다.

결국 엔터프라이즈 환경에서 성공적인 생성형 AI 서비스를 안착시키기 위해서는, 본 도식이 제시하는 '단일 오케스트레이터 기반의 고도화된 RAG 아키텍처'로의 패러다임 전환이 전제되어야 한다. 모든 데이터와 실시간 질의의 흐름을 백엔드 서버가 게이트키퍼로서 강력하게 통제할 때, 비로소 시스템의 안정성과 신뢰성을 확보할 수 있다.

물론 백엔드 내부와 사내 레거시 인프라간의 실시간 권한 동기화, 임베딩 모델의 공간적 한계를 극복하기 위한 복합 리트리버 설계 등 전산팀이 해결해야 할 고난도의 기술적 과제는 여전히 존재한다. 또한 기술적 고도화에 앞서 사내 소스 데이터를 정제하고 노후화된 문서를 격리하는 데이터 거버넌스의 정립 역시 동시에 수행되어야 한다.

이러한 아키텍처적 통제력과 거버넌스가 결합될 때, 기업의 생성형 AI는 예측 불가능한 시한폭탄에서 벗어나 사내 보안을 철저히 준수하고 자산화된 지식을 정확하게 전달하는 '통제 가능하고 신뢰할 수 있는 사내 지식 인프라'로 거듭날 것이다.

우리 서비스에 Refresh Token이 정말 필요할까?

dev_SiWoo — Mon, 4 May 2026 14:20:09 +0900

소셜 로그인 기능을 구현하다 보면 마주하게 되는 단어가 있다.

바로 Access Token과 Refresh Token

많은 튜토리얼에서 Refresh Token을 DB에 저장하라고 가르치지만, 모든 서비스가 그럴 필요는 없다.

오히려 불필요한 저장 방식은 보안 리스크만 키울 수 있다.

이번 글에서는 서비스의 성격에 따른 OAuth 2.0 관리 정책의 차이점을 정리해보고자 한다.

1. 시나리오 A: "사용자가 서비스에 접속해 있는 동안만 권한이 필요해요"

(단순 로그인 및 실시간 데이터 조회 서비스 + 활동 기반 실시간 인증 방식)

사용자가 우리 서비스에 로그인해서 마이페이지를 보거나, 버튼을 눌러 본인의 구글 드라이브 파일 목록을 불러오는 경우이다.

핵심 로직: 사용자가 우리 서비스에 '로그인' 상태를 유지하는 것이 곧 구글 API 사용의 전제조건이다.
토큰 관리 전략:
- Silent Refresh(조용한 갱신): Access Token은 보통 1시간이면 만료되지만, 사용자가 페이지를 이동하거나 버튼을 클릭하는 등 '활동 중'이라면 서버가 백그라운드에서 Refresh Token을 사용해 새 Access Token을 받아오게 처리한다.
- 이를 통해 사용자는 1시간이 지나도 로그아웃되지 않고 끊김 없는 경험을 유지한다.
저장소: Refresh Token을 영구적인 DB보다는 서버 세션이나 Redis 같은 보안 세션 저장소에 보관한다.
유저가 브라우저를 완전히 끄고 세션이 만료되면 자연스럽게 권한도 소멸되게 설계한다.
장점: 구현이 상대적으로 간결하며, 유저가 활동을 멈추고 떠나면 토큰 권한도 사라지므로 보안 리스크가 적다.

2. 시나리오 B: "사용자가 없어도 서버는 일해야 합니다"

(백그라운드 자동화 및 대행 서비스)

"새 이메일이 오면 슬랙으로 알림 보내기"나 "매일 새벽 구글 시트에 데이터 백업하기"처럼,
유저가 브라우저를 닫아도 서버가 돌아가야 하는 경우

핵심 로직: 유저의 '로그인 여부'와 상관없이 구글 서버에 접근할 수 있는 '영구 통행증'이 필요.
토큰 관리:
- 인증 시 access_type=offline 옵션을 주어 Refresh Token을 반드시 받도록 처리해야한다.
- Access Token이 만료되면 서버가 스스로 Refresh Token을 꺼내 새 토큰을 발급받는다.
저장소: RDB(Relational DB)에 안전하게 영구 저장해야함.
장점: 유저에게 최고의 편의성(자동화)을 제공할 수 있음.

한눈에 비교하는 관리 정책

구분	시나리오 A (활동 기반 유지)	시나리오 B (오프라인 자동화)
주요 목적	로그인 유지 및 실시간 데이터 조회	백그라운드 작업, 데이터 자동 동기화
핵심 경험	활동 중인 유저의 흐름 유지	접속하지 않은 상태의 작업 대행
토큰 갱신	세션이 살아있는 동안 백그라운드 갱신	서버 스케줄러/웹훅에 의한 수시 갱신
DB 저장	비권장 (세션/Redis 보관)	필수 (DB 암호화 저장)
인증 방식	access_type=online (또는 세션 내 관리)	access_type=offline

[Deep Dive] 왜 시나리오 B는 세션으로 해결이 안 될까?

"세션 유효기간을 무한대로 늘리면 되지 않는가?"라고 생각할 수 있지만 여기에는 문제가 있다.

Session은 '요청' 기반
Session은 브라우저의 '요청'이 있어야만 서버가 인식할 수 있다.
새벽 3시에 서버 혼자 돌아가는 스케줄러는 브라우저 요청이 없으므로 세션에 접근할 방법이 아예 없다.
메모리 과부하
모든 유저의 Refresh Token을 메모리(세션)에 무기한 들고 있는 것은 서버 자원을 낭비하며, 서버가 꺼지면 모든 세션정보가 날라가게되어 예약된 자동화 작업이 모두 실패하는 장애로 이어지게 된다.

세션(Session) vs 데이터베이스(DB)

비교 항목	시나리오 A (세션/Redis)	시나리오 B (DB 영구 저장)
비유	놀이공원 자유이용권 팔찌	집 금고에 보관된 인감도장
핵심 이점	가벼움과 보안성	지속성과 자동화
보안 책임	낮음 (로그아웃 시 자동 소멸)	매우 높음 (암호화 필수)
사용자 부재 시	서비스 중단 (재접속 시 재개)	중단 없이 24시간 작동
서버 재시작	세션 휘발 (재로그인 필요)	데이터 유지 (작업 연속성 보장)
추천 저장소	Redis (속도 + 세션 공유)	MySQL, PostgreSQL 등 RDB

NIC(Network Interface Card) 설정

dev_SiWoo — Fri, 3 Apr 2026 15:57:18 +0900

1. NIC 설정이란?

"NIC(네트워크 인터페이스 카드)"설정은 운영체제에서 IP 주소, 서브넷 마스크, 게이트웨이, DNS 등을 구성하여 네트워크 통신을 가능하게 하는 과정" 이라고 정의되어 있다.

우리가 Window에서 이더넷 설정으로 DHCP를 사용하지 않고 수동으로 고정 IP설정을 할 때, 아래의 같은 설정창에서

설정하는 것도 NIC 설정이라고 볼 수 있다.

window 11 에서의 NIC 설정

2. 각 설정 항목의 역할

단순히 숫자를 입력하는 것처럼 보이지만, 이 값들은 네트워크 통신을 위한 '주소 체계'를 형성한다.

IPv4 주소: 네트워크상에서 내 컴퓨터를 식별하는 고유한 주소 번호
서브넷 마스크: 네트워크 상에서 내 PC가 속한 '동네의 범위'를 의미함
어디까지가 내부 네트워크(우리 동네)이고 어디부터가 외부인지 구분하는 기준
기본 게이트웨이: 동네 밖으로 나가기 위해 반드시 통과해야 하는 '마을 입구(톨게이트)' 주소.
일반적인 환경에서는 공유기나 라우터의 IP가 이 역할을 하지만,
기업용 네트워크나 서버실 환경에서는 L3 스위치가 이 게이트웨이 역할을 수행하기도 함.
결국 "외부망으로 연결되는 첫 번째 관문"의 주소를 적어주는 것이 핵심.
DNS 서버: google.com 같은 이름을 IP 주소 숫자로 바꿔주는 '전화번호부'라고 볼 수 있음.

3. 고정 IP 설정 시 주의사항

단순히 숫자를 바꾸는 것보다 더 중요한 것은 '안정적인 통신'을 유지하는 것임.
주소를 변경하기 전, 다음 사항을 반드시 체크해야함.

IP 충돌 확인: 바꾸려는 주소를 이미 다른 서버나 장비가 사용 중인지 확인해야함.
- Tip: CMD에서 ping [바꿀 IP 주소]를 입력해 응답이 오는지 확인
게이트웨이/서브넷 유지: IP 주소(끝자리)를 변경하더라도, 같은 네트워크 대역이라면 게이트웨이와 서브넷 마스크는 기존 값을 유지해야 통신이 끊기지 않는다.
서비스 영향도 평가: 서버나 NAS의 IP를 변경하면 해당 주소로 접속하던 모든 클라이언트와 서비스의 연결이 끊어질 수 있으므로 신중해야한다.

4. 마치며

윈도우 UI에서는 클릭 몇 번으로 끝나는 설정처럼 보이지만, 실제로는 OS 드라이버를 통해

하드웨어인 NIC에 통신 규칙을 부여하는 중요한 과정이다.

특히 서버 수십 대를 관리하는 환경에서는 이런 기초적인 NIC 설정이 인프라 관리의 시작점이라고 할 수 있다.

업링크(Uplink) 포트란?

dev_SiWoo — Thu, 2 Apr 2026 14:38:52 +0900

스위치 오른쪽 끝에 별도로 떨어져 있거나, 속도가 더 빠른 포트를 말한다.

보통 SFP라고 적혀 있거나 광케이블을 꽂는 구멍인 경우가 많음!

용도: '스위치와 스위치' 를 연결하거나, '스위치와 상단 백본/방화벽'을 연결할 때 사용
비유: 일반 포트가 동네 골목길이라면, 업링크 포트는 고속도로 톨게이트와 같다.
수많은 골목길의 차들이 모여서 더 넓은 큰길로 나가는 통로인 셈

Win32 hosts 파일 설정에 대해

dev_SiWoo — Fri, 27 Mar 2026 11:45:52 +0900

1. hosts 파일의 역할과 우선순위

정의: OS가 도메인 주소를 IP 주소로 변환할 때 가장 먼저 참조하는 로컬 도메인 인덱스라고 볼 수 있다.
우선순위: hosts 파일은 외부 DNS(KT, SKT 등) 서버보다 항상 우선함.
핵심 기능: 특정 도메인(예: tplm...)을 입력했을 때, 전 세계 공통 주소가 아닌 내가 지정한 특정 IP로 강제 연결함.

2. 도메인 및 서버 환경 구성

서브도메인(Subdomain): 메인 도메인(hyundaieverdigm.com) 앞에 붙는 tplm, tplmdb, search 등을 말하며, 하나의 메인 주소 아래 여러 서비스를 구분할 때 사용
환경별 분리: # 주석을 활용하여 Dev(개발), Test(테스트), Prod(운영) 환경의 IP를 관리합니다. 주석을 풀고 묶는 것만으로 소스 코드 수정 없이 접속 대상을 즉시 변경할 수 있음.
다중 매핑: 하나의 IP(172.18.102.210)에 여러 서브도메인을 연결하여, 서버 한 대가 다양한 역할을 수행하도록 설정할 수 있음

3. 접속 이슈의 원인 (PC vs 모바일 LTE)

PC 접속 가능: hosts 파일에 지도가 그려져 있으므로, 브라우저가 사내망 IP(172.18.x.x)를 찾아갈 수 있음.
모바일 LTE 접속 불가:
- 이정표 부재: 핸드폰에는 PC의 hosts 설정이 없음.
- 공인/사설 망 분리: LTE는 공용 망을 쓰지만, 설정된 IP는 사내 전용(사설) IP임.
  공용 DNS 서버는 이 내부 주소를 알지 못함.
도메인 비등록: 도메인 이름 자체는 존재하더라도, 보안이나 내부 관리 목적으로 외부(공용 DNS)에 등록하지 않을 수 있음.

SSH 현재 접속자 확인 명령어

dev_SiWoo — Fri, 20 Mar 2026 17:54:07 +0900

️ 리눅스 vs 윈도우 명령어 비교

기능	Windows (PowerShell)	Linux (Bash/Zsh)
현재 접속자 확인	quser 또는 query user	w, who
로그인 기록 확인	이벤트 뷰어 확인	last
특정 세션 강제 종료	logoff [ID]	pkill -u [사용자명] 또는 skill -9 [TTY]

IP 주소 클래스와 옥탯 개념

dev_SiWoo — Wed, 18 Mar 2026 16:59:32 +0900

1. IP 주소 클래스 범위 비교

클래스	시작 범위 (10진수)	비트 패턴 (2진수 시작)	주요 용도
A클래스	0 ~ 127	0...	대규모 네트워크
B클래스	128 ~ 191	10...	중규모 네트워크
C클래스	192 ~ 223	110...	소규모 네트워크
D클래스	224 ~ 239	1110...	멀티캐스트 (공용)
E클래스	240 ~ 255	1111...	연구 및 실험용

2. 옥탯 개념

IP 주소는 크게 네트워크 부분(어디에 있는가)과 호스트 부분(누구인가)으로 나뉜다.

구분	옥텟 값	의미 및 역할 (기본 정의)	비유 (주소 체계)
1~2번째	192.168	사설 네트워크 식별자 (Private Network)	"동네 이름" (예: 서울시 강남구)
3번째	10	서브넷 ID (Subnet ID)	"상세 구역" (예: 역삼동 또는 아파트 단지)
4번째	1	호스트 ID (Host ID)	"동/호수" (예: 101동 101호)

3. 사설 IP(Private IP)의 3가지 약속된 범위

전 세계 어디서나 내부망용으로만 쓰기로 약속된 대역은 딱 세 군데입니다. 이 범위에 속하면 사설 IP, 이 범위를 벗어나면 공인 IP입니다.

클래스	사설 IP 주소 범위	비고
A 클래스	10.0.0.0 ~ 10.255.255.255	대규모 내부망 (기업, 학교 등)
B 클래스	172.16.0.0 ~ 172.31.255.255	중규모 내부망
C 클래스	192.168.0.0 ~ 192.168.255.255	소규모 내부망 (가정용 공유기 등)

4. 구체적인 구분 방법

172로 시작할 때 주의할 점 (B클래스)

가장 헷갈리는 구간으로 172로 시작한다고 무조건 사설 IP는 아닙니다.

사설 IP: 172.16.x.x 부터 172.31.x.x 까지만 사설
공인 IP: 172.12.x.x나 172.32.x.x는 전 세계 누군가가 실제로 쓰고 있는 공인 IP

10으로 시작할 때 (A클래스)

첫 번째 숫자가 10이기만 하면 뒤에 뭐가 오든 무조건 사설 IP
예: 10.1.1.1, 10.254.0.1 등

192로 시작할 때 (C클래스)

192.168까지 세트로 붙어야 사설 IP
만약 192.169.x.x라면? 그것은 공인 IP

5. 특수 목적 주소 (추가 구분)

사설 IP는 아니지만, 공인 IP로도 쓰지 않는 독특한 주소들이 있음.

Loopback (127.0.0.1): 내 컴퓨터 자신을 가리킬 때 씀. (Localhost)
APIPA (169.254.x.x): IP를 자동으로 할당받지 못했을 때 윈도우가 임시로 부여하는 주소 (인터넷 안 됨)

[SQL] - 쿼리튜닝 잡기술

dev_SiWoo — Wed, 11 Mar 2026 23:39:30 +0900

1. INSERT 직후 UPDATE 하는 '이중 작업'을 CASE 문으로 통합하기

❌ 변경 전: 임시 테이블에 일단 데이터를 다 넣고(INSERT), 조건에 맞는 데이터만 다시 찾아서 수정(UPDATE)
✅ 변경 후: 데이터를 삽입(INSERT)하는 과정에서 SELECT나 VALUES 절 내에 CASE 문을 사용하여 조건을 평가해 한 번에 처리
핵심: 디스크 I/O(읽고 쓰기)를 절반으로 줄이고, 대량 업데이트 시 발생하는 엄청난 양의 트랜잭션 로그 오버헤드를 방지하여 성능을 대폭 향상시킵니다.

2. 인덱스 컬럼 가공하지 않기 (좌항 날 것 유지)

❌ 변경 전: WHERE YEAR(JoinDate) = 2023 (인덱스가 걸린 컬럼 자체에 함수를 씌워버림)
✅ 변경 후: WHERE JoinDate >= '2023-01-01' AND JoinDate < '2024-01-01' (컬럼은 그대로 두고, 비교하는 우항의 값을 변경)
핵심: 인덱스가 걸린 컬럼(좌항)을 함수나 연산으로 변형하면, 데이터베이스가 기껏 만들어둔 인덱스(사전)를 타지 못하고 테이블 전체를 처음부터 끝까지 뒤지는 '풀 테이블 스캔'을 해버립니다.

**3. 존재 여부 확인 시 COUNT(*) 대신 EXISTS 사용하기**

❌ 변경 전: IF (SELECT COUNT(*) FROM Orders WHERE CustomerID = 123) > 0 (조건에 맞는 데이터를 끝까지 다 세어봄)
✅ 변경 후: IF EXISTS (SELECT 1 FROM Orders WHERE CustomerID = 123) (데이터를 찾다가 하나라도 발견하면 즉시 종료)
핵심: COUNT는 무조건 테이블을 끝까지 읽어 숫자를 합산하는 무거운 작업입니다. 존재 여부만 볼 때는 발견 즉시 스캔을 멈추는 EXISTS가 훨씬 가볍고 빠릅니다.

4. 중복 제거가 필요 없을 땐 무조건 UNION ALL 사용하기

❌ 변경 전: SELECT Email FROM A UNION SELECT Email FROM B (두 결과를 합친 후, DB 내부적으로 무거운 정렬 및 중복 제거 작업을 숨어서 수행)
✅ 변경 후: SELECT Email FROM A UNION ALL SELECT Email FROM B (정렬 없이 그냥 위아래로 데이터를 단순 병합)
핵심: UNION은 중복을 제거하기 위해 데이터베이스에 엄청난 부하를 주는 정렬(Sort/Hash) 작업을 동반합니다. 두 데이터 셋에 중복이 없거나 중복되어도 상관없다면 반드시 UNION ALL을 써야 합니다.

**5. 무의식적인 SELECT * 금지 (필요한 컬럼만 명시)**

❌ 변경 전: SELECT * FROM CustomerOrders WHERE OrderDate = '2023-10-01' (실제로는 2개 컬럼만 쓰는데 50개 컬럼을 다 퍼옴)
✅ 변경 후: SELECT CustomerID, OrderAmount FROM CustomerOrders WHERE ... (화면이나 로직에 진짜 필요한 컬럼만 콕 집어서 명시)
핵심: 안 쓰는 데이터까지 가져오면 불필요한 디스크 읽기, 메모리, 네트워크 대역폭 낭비가 발생합니다. 또한, 필요한 컬럼만 지정하면 테이블을 안 뒤지고 인덱스만 읽어서 결과를 뱉어내는 '커버링 인덱스'의 마법을 누릴 확률이 높아집니다.

6. LIKE 검색 시 와일드카드(%)는 문자열 뒤에만 사용하기

❌ 변경 전: WHERE Name LIKE '%김%' ('김'이 중간이나 끝에 있을지도 모르니 인덱스를 못 쓰고 전체 테이블을 다 뒤짐)
✅ 변경 후: WHERE Name LIKE '김%' ('김'으로 시작하는 것만 찾으면 되니 인덱스 사전에서 'ㄱ' 파트만 쏙 뽑아옴)
핵심: DB의 인덱스는 국어사전처럼 '앞에서부터' 정렬되어 있습니다. %를 맨 앞에 두면 사전의 장점을 전혀 살릴 수 없습니다. 어쩔 수 없는 경우가 아니라면 와일드카드는 반드시 뒤에만 붙이세요.