본문 바로가기

IT

 (31)
51. 포워드 프록시(Forward Proxy) vs 리버스 프록시(Reverse Proxy) vs API Gateway 완벽 정리 안녕하세요, Hans 입니다.클라이언트와 서버 사이에서 트래픽을 중계하는 컴포넌트들을 다루다 보면, 포워드 프록시, 리버스 프록시, 그리고 API 게이트웨이의 개념이 서로 혼동될 때가 많습니다. 모두 중간에 위치한다는 공통점이 있지만, 실제 차이점은 어느 쪽을 대변하는지와 어떤 문제를 해결하는지에 있습니다. 각 컴포넌트의 역할과 아키텍처상 위치를 명확하게 정리해 보겠습니다.1. 포워드 프록시 (Forward Proxy)포워드 프록시는 클라이언트 바로 옆(Client Network)에 위치합니다.대변하는 대상: 클라이언트를 대변하여 요청을 인터넷으로 전달합니다.익명성 보호: 노트북이나 모바일 기기가 요청을 보내면 프록시가 이를 대신 전달하므로, 목적지 웹사이트나 API에서는 사용자의 실제 IP 주소를 볼 ..
50. [AI 입문] 내 AI를 똑똑하게 만드는 두 가지 방법: RAG vs Agent 완벽 비교! 안녕하세요, Hans 입니다.챗GPT나 대형 언어 모델(LLM)을 사용해 보신 분들이라면 한 번쯤 경험해 보셨을 겁니다. 우리 회사 내부 규정이나 어제 나온 최신 뉴스에 대해 질문하면, AI가 엉뚱한 거짓말(환각 현상, Hallucination)을 하거나 모른다고 답하곤 하죠. LLM은 학습된 데이터만을 기억하기 때문에 생기는 자연스러운 현상입니다.그렇다면 AI에게 새로운 지식을 가르치거나, 스스로 일하게 만들려면 어떻게 해야 할까요? 이를 해결하기 위해 요즘 AI 업계에서 가장 많이 언급되는 두 가지 핵심 패턴이 있습니다. 바로 RAG(검색 증강 생성)와 AI Agent(에이전트)입니다.이 두 가지가 무엇이고, 어떤 차이가 있는지 초심자의 눈높이에서 아주 쉽게 정리해 드리겠습니다.!1. 📖 오픈북 테..
데이터 수집 전 '분석 목적과 대상'을 먼저 정의해야 하는 이유 1. 데이터 다다익선의 오류: 필요한 데이터만 선별 수집해야 하는 이유많은 기업과 실무자가 "데이터는 일단 많이 쌓아두면 언젠가 쓸모가 있겠지"라는 생각으로 접근합니다. 하지만 무조건적인 데이터 적재는 오히려 다음과 같은 비효율을 초래합니다.⚠️ [실무 사례] 전수 로그 적재 요청과 그 한계상황: 한 PM(Product Manager) 리더가 서비스 내 모든 화면 요소(버튼, 텍스트, 페이지)의 모든 이벤트(클릭, 마우스 오버, 성공/실패 등)를 빠짐없이 로그로 적재해 달라고 요청함.이유: 추후 어떤 가설을 검증할지 모르니, 데이터를 미리 다 쌓아두면 나중에 분석하기 편할 것이라는 판단.결과 및 문제점: 일일 수십만 건 이상 발생하는 전수 로그는 시스템 비용(저장소, 네트워크 트래픽), 데이터 관리 및 ..
[HTTP Method] 새로운 HTTP 메서드의 등장: 대용량 조회를 위한 QUERY 메서드 이해하기 안녕하세요, Hans 입니다.최근 HTTP 스펙을 관리하는 IETF(국제 인터넷 표준화 기구)에서 공식 표준화(RFC 10008) 과정을 거치며 큰 주목을 받고 있는 QUERY 메서드에 대한 조사 내용입니다.기존 웹 생태계가 가진 고질적인 아키텍처 한계를 해결하기 위해 등장한 개념으로, 핵심 내용을 알기 쉽게 정리해 드립니다.1. HTTP QUERY 메서드란?QUERY 메서드는 한마디로 "안전하고 멱등하면서도, 대용량의 구조화된 데이터를 요청 본문(Body)에 담아 서버에 조회를 요청할 수 있는" 새로운 HTTP 메서드입니다. 기존의 GET과 POST가 가진 장점만을 결합한 형태라고 볼 수 있습니다.2. 왜 도입되었을까? (기존 메서드의 한계)기존에는 웹에서 데이터를 조회할 때 주로 GET을, 데이터를 ..
[FrontEnd] 웹사이트 속도를 2배 높이는 프론트엔드 성능 최적화 전략 8가지 안녕하세요, Hans입니다.여러분의 웹사이트는 얼마나 빠르게 로딩되시나요? 현대 웹 개발에서 프론트엔드 성능 최적화(Frontend Performance Optimization)는 단순히 '속도가 빠르다'를 넘어, 사용자 이탈률을 줄이고 매출을 극대화하는 핵심 비즈니스 전략입니다. 특히 구글 검색 엔진(SEO)은 웹사이트의 로딩 속도와 사용자 경험지표(Core Web Vitals)를 상위 노출의 매우 중요한 랭킹 요소로 평가하고 있습니다.오늘은 프론트엔드 개발자라면 반드시 알아야 할 웹 성능 개선을 위한 8가지 핵심 최적화 기법을 알기 쉽게 정리해 드리겠습니다!1. 파일 압축 (Compression)웹 성능 개선의 첫걸음은 네트워크를 통해 주고받는 데이터의 절대적인 크기를 줄이는 것입니다.개념: 서버에서..
[우버(Uber) 기술 블로그] 10만 대의 DB 서버를 자동으로 움직이는 힘, Stateful 플랫폼 '오딘(Odin)' 이야기 안녕하세요! 오늘은 글로벌 모빌리티 기업 우버(Uber)가 대규모 데이터베이스와 스토리지 시스템을 어떻게 효율적으로 자동 관리하고 있는지, 그들의 핵심 인프라 플랫폼인 '오딘(Odin)'에 대해 소개해 드리려고 합니다.최근 많은 기업들이 서비스 확장을 위해 쿠버네티스(Kubernetes)를 도입하지만, 데이터베이스(MySQL, Cassandra)나 메시지 큐(Kafka) 같은 상태 저장(Stateful) 시스템을 대규모로, 그것도 완전히 자동화하여 관리하는 것은 여전히 까다로운 영역입니다.몇 백 대 수준에서 시작해 현재 10만 대 이상의 호스트를 관리하기까지, 우버가 겪은 고민과 기술적 해법을 함께 살펴보겠습니다.1. 런북(Runbook)의 한계에서 탄생한 '오딘'2014년, 우버가 무서운 속도로 성장하..
[AWS 가이드] 어떤 데이터베이스를 써야 할까? 아키텍처별 AWS DB 선택 팁 안녕하세요! Hans입니다.대규모 클라우드 아키텍처를 설계하거나 새로운 프로젝트를 시작할 때 가장 고민되는 부분 중 하나는 바로 "어떤 데이터베이스(DB)를 선택할 것인가?"일 것입니다.AWS는 강력하고 다양한 관리형 DB 서비스를 제공하지만, 서비스의 특성에 맞는 최적의 DB를 고르는 것은 쉽지 않습니다. 오늘은 데이터의 형태(관계형, 비관계형, 인메모리)에 따라 어떤 AWS DB 서비스를 선택해야 하는지 정리했습니다.1. 관계형 데이터베이스 (Relational DB)전통적인 테이블 구조, ACID 트랜잭션, 명확한 스키마가 필요할 때 선택하는 데이터베이스 유형입니다.AWS RDS (Managed Relational DB Service)특징: MySQL, PostgreSQL, Oracle 등 친숙한 ..
개발자의 기본 소양, RESTful한 API 주소 설계 규칙 5가지(feat. Path Variable vs Query Parameter) 지난 포스팅에서는 우리가 매일 사용하는 URL의 6가지 기본 구조(Protocol부터 Fragment까지)에 대해 알아보았습니다.🔗 지난 글 보기: 매일 쓰는 주소창의 비밀, URL 구조 완벽 정리 지난 글의 예시 주소 중에 /blog/posts/88 기억하시나요? 왜 하필 주소가 이렇게 설계되었을까요?오늘은 실무에서 백엔드와 프론트엔드 개발자들이 가장 많이 고민하고, 기술 면접에서도 단골로 출제되는 'RESTful한 API 주소(URI) 설계 규칙'을 깔끔하게 정리해 보겠습니다.이 규칙만 지켜도 누구나 한눈에 알아볼 수 있는 "클린 코드" 같은 주소를 만들 수 있습니다. 💡 REST API 주소 설계의 핵심 철학REST(Representational State Transfer) API 주소를 설계할..

티스토리툴바