분류 전체보기

🌏 인트로LLM 기반 서비스를 만들 때 가장 핫한 기술 중 하나는 RAG 입니다.그런데 실제로 구현해보면 모델을 불러서 돌리는 것보다, 파이프라인을 어떻게 연결할지, 메모리를 어디에 둘지, 프롬프트 변형은 어떤 조건에서 할지 같은 구성 문제가 훨씬 어렵습니다.LangChain과 LangGraph는 이런 복잡한 LLM 워크플로우를 안정적으로 만들기 위해 등장한 도구입니다.✅ 사전지식: RAG(Retrieval-Augmented Generation)RAG(Retrieval-Augmented Generation)는 모델이 답을 생성하기 전에, 외부 지식 저장소에서 관련 문서를 검색해 함께 넣어주는 방식입니다. LLM은 기본적으로 학습 시점까지의 정보만 알고 있어 최신 데이터나 사내 데이터는 알 수 없기 때문..

해당 글을 읽기 전 먼저 이전 포스팅(MSA 운영에서 발생하는 이슈들)에 대해서 읽고 오시길 바랍니다! 🌏 인트로앞선 포스팅에서 MSA를 실제로 운영할 때 자연스럽게 발생하는 대표적인 문제들을 정리했습니다.✅ MSA 운영 이슈들조인 불가: 단일 DB가 아니기 때문에 서비스 간 조인이 불가능합니다.트랜잭션 불확장: 트랜잭션이 서비스 경계를 넘어서 확장되지 않습니다.장애 전파: 한 서비스의 장애가 네트워크 타고 전체로 전파됩니다.이벤트 불일치: 이벤트 전달이 실패하거나 순서가 바뀔 수 있습니다.조회 성능 저하: 조회가 여러 서비스 호출로 변하면서 성능 문제가 생깁니다. 이번 글에서는 이러한 문제들을 해결하기 위해 현업에서 가장 널리 사용되는 패턴들을 정리해보려고 합니다. SAGA, CQRS, Outbo..

🌏 인트로MSA는 Microservice Architecture(마이크로서비스 아키텍처)의 약자로, 하나의 큰 애플리케이션을 여러 개의 독립적인 작은 서비스로 나누어 개발·배포·운영하는 아키텍처입니다. 각 서비스는 자체 DB와 로직을 가지며 서로 API나 이벤트로 통신합니다. 이렇게 분리하면 기능별 확장과 독립 배포가 쉬워지지만, 서비스 간 협력이 복잡해지고 일관성·장애 관리 문제가 함께 따라옵니다. MSA에 대해서는 크게 장점으로는 나누어져 있으니 일부만 scale out 할 수 있어 비용이 절감된다, 그리고 단점으로는 운영이 복잡하다를 들곤 합니다. 근데 실제로 어떤 부분에 있어서 운영이 얼마나 복잡해질까요? 🌏 MSA 운영에서 발생하는 이슈들MSA 구조를 실제로 운영해보면, 처음에 기대했던 서비..

🌏 MCP(Model Context Protocol)AI 모델이 외부 시스템, 데이터, 도구와 상호작용하는 방식을 표준화한 통신 규약✅ 개념 MCP는 비교적 최근(2024년 말부터 2025년 초까지) Anthropic에서 발표한 프로토콜로, LLM 기반 에이전트 시대에 필요한 모델 중심 프로토콜입니다. 기존 인터넷 프로토콜(HTTP, WebSocket 등)은 네트워크 통신 자체만 정의했지만, MCP는 AI 모델이 어떤 메시지를 주고받을지 자체를 정의합니다. LLM은 적당히 똑똑하지만, 모델 자체가 학습 시점의 지식에 고착되어 있고, 외부 세계와 상호작용할 수 없습니다. 즉, 실시간 데이터에 액세스하거나 회의 예약, 고객 기록 업데이트와 같은 작업을 수행할 수 없습니다. [LLM이 못 하는 것]실제 ..

🌏 CDN(Content Delivery Network)✅ 개념정적 콘텐츠를 전송하는 데 쓰이는 지리적으로 분산된 서버의 네트워크우리가 평소 쓰는 정적 파일(이미지, JS, CSS, 비디오 등)을 캐시해, 더 가까운 곳에서 보내주기 위해 존재하는 인프라입니다.(최근에는 동적 컨텐츠를 캐싱하는 데도 CDN을 사용하지만, 이 경우는 다음 포스팅에서 소개하겠습니다)정적인 파일을 미국 서버에서 가져오면 200ms 이상 걸리지만, 서울에 있는 POP(Point of Presence)에서 가져오면 10~20ms 정도로 끝나기 때문에 속도가 확 달라지는 것이죠. Origin Server: 원본 컨텐츠를 저장하는 중앙 서버Edge Server: 전세계 곳곳에 위치한 분산 서버로, 오리진 서버의 컨텐츠를 캐싱함DNS ..

🌏 캐시✅ 캐시의 필요성대규모 서비스를 운영할 때 가장 큰 문제는 데이터베이스의 부하입니다. 사용자가 많아질수록 모든 요청이 DB로 향하게 되고, DB는 디스크 기반으로 동작하기 때문에 속도가 한계에 부딪힙니다. 특히 동일한 데이터를 여러 사용자가 반복해서 조회하는 경우, 매번 DB를 거치는 것은 불필요한 낭비입니다. 이때 캐시(Cache)는 자주 조회되는 데이터를 메모리(RAM)에 저장해, 다음 요청 때는 DB가 아닌 캐시에서 바로 반환하도록 하는 구조입니다. 결과적으로 DB 부하를 크게 줄이고, 응답 속도를 몇십 배까지 향상시킬 수 있습니다. 웹 서비스에서는 상품 목록, 배너, 사용자 정보처럼 변경이 적고 조회가 잦은 데이터들이 대표적인 캐시 대상입니다. 이런 데이터들은 DB보다는 캐시에서 처리하는..

🌏 로드 밸런싱대규모 트래픽을 다루는 모든 서비스에서 로드 밸런서는 필수적입니다. ✅ 개념여러 대의 서버로 들어오는 요청을 균등하게 분산시켜 전체 시스템의 안정성과 처리량을 높이는 기술 대규모의 트래픽을 다루기 위해서는 단순히 서버 여러 대를 늘리는 것만으로는 충분하지 않고, 부하를 지능적으로 분배하고 장애를 격리하는 구조가 필요합니다. 이때 중앙에서 분산을 담당하는 장치나 소프트웨어가 바로 로드 밸런서(Load Balancer)입니다.로드 밸런서는 크게 두 가지 역할을 수행합니다. 1) 트래픽 분산여러 대의 서버 중 한 곳에 요청이 몰리지 않도록 요청을 골고루 나누는 역할입니다.덕분에 서버 과부하를 막고, 수평 확장을 통해 전체 처리량을 늘릴 수 있습니다. 2) 장애 감지 및 격리(Health C..

🌏 소스 코드https://github.com/gitchan-Study/kafka-playground GitHub - gitchan-Study/kafka-playgroundContribute to gitchan-Study/kafka-playground development by creating an account on GitHub.github.com 🌏 인트로이 포스팅에서는 Spring Boot와 Kafka를 사용하여 "회원가입"이라는 하나의 이벤트가 발생했을 때, "쿠폰 발급"과 "이메일 발송"이라는 두 가지 후속 작업이 어떻게 독립적으로 처리될 수 있는지 보여주는 예제 프로젝트에 대해 설명하겠습니다.미니 프로젝트로 진행한 만큼 카프카를 원래 사용하는 목적이라면 대용량 트래픽을 감당하기 위한 것이..

🌏 발단일본어 공부의 시작이 언제더라,, 19년도 대학교 1학년 때 나고야에서 온 일본인 룸메를 만나면서부터였다.룸메는 워낙 내성적인 성격에 샤이니가 좋다고 한국에 왔지만 이후로 현재까지 나말고는 한국인 친구를 단 한명도 사귀지 못했다고 한다(?) 룸메가 많이 외로워보여 같이 놀기 시작하면서부터 일본어를 하나씩 접했고 그렇게 야매 공부는 시작되었다. 🌏 JLPT 시작 전 베이스 그렇게 공부하다가 좀 잘해보고 싶어서 학교에서 21년도 여름 계절학기로 일본어(1)을 수강했다. 단 3주간의 과정이었고 그렇게 대략 N4의 수준을 지니게 되었지만, 아직 JLPT를 볼 생각까지는 못했던 것 같다. 그러던중 오빠가 여자친구가 생겼는데 그녀는 고베 출신에 부모님 모두 한국어를 전혀 못하셨다. 결혼한다고 상견례 등..

🌏 인트로서비스를 실제로 개발하다 보면 단위 테스트(Unit Test)보다 훨씬 현실적인 End-to-End(E2E) 테스트를 작성할 일이 많습니다.E2E 테스트는 실제 API를 호출하고, 데이터베이스와의 연동, 인증 절차, 외부 요청 등까지 통합적으로 검증하는 테스트입니다.✅ E2E 테스트 예시(인수테스트입니다)@Testvoid 고객이_자신의_리워드를_조회한다() { String ownerAccessToken = 카페_사장_회원_가입_요청하고_액세스_토큰_반환(OWNER_CREATE_REQUEST); Long savedCafeId = 카페_생성_요청하고_아이디_반환(ownerAccessToken, CAFE_CREATE_REQUEST); String customerToken = 가입_고..