본문 바로가기

분류 전체보기

 (716)
Spring Boot 2에서 3으로의 완벽한 마이그레이션 가이드: 새로운 변화와 적용 방법 Spring Boot 3 버전은 성능, 보안, 효율성 면에서 여러 중요한 개선 사항을 포함하고 있으며, Java 17과 Spring Framework 6을 기반으로 합니다. 이 블로그에서는 Spring Boot 2에서 3으로 마이그레이션 할 때 필요한 주요 변경 사항들을 설명하고, 각 단계에서 유의할 점과 해결 방법을 코드 예제와 함께 제시합니다.1. 주요 변경 사항 소개Spring Boot 3는 Jakarta EE 10, 새로운 의존성 관리, 보안 패치 등 많은 부분에서 변화가 있었습니다. 마이그레이션 전에 Spring Boot 2.7로 업그레이드하고 Java 17을 사용하는 것이 필수입니다.2. 의존성 및 구성 변경2.1. Jakarta EE 패키지로 전환Spring Boot 3에서는 javax 패키..
검색 정확도를 높이는 비결: Reranker의 역할과 도입 효과 Reranker란 무엇인가?Reranker는 검색 증강 생성(RAG, Retrieval-Augmented Generation) 시스템에서 사용되는 기술로, 초기 검색 결과의 순위를 재정렬하여 보다 관련성이 높은 정보를 상위에 배치하는 역할을 합니다. 일반적으로 검색 엔진이나 AI 기반 질의 응답 시스템에서 사용됩니다. Reranker는 문서와 쿼리 간의 유사도를 더욱 정확하게 측정하여 최적의 답변을 제공할 수 있도록 돕습니다​​.Reranker의 역할Reranker는 RAG 시스템에서 첫 번째 검색 후 후보 문서들이 제공되었을 때, 해당 문서들을 다시 평가하여 쿼리와 가장 관련성 높은 문서가 상위에 위치하도록 순서를 조정합니다. 이를 통해 사용자는 더욱 정확하고 유용한 정보를 빠르게 얻을 수 있습니다. ..
앤트로픽의 새로운 비밀 무기: Contextual Retrieval로 LLM의 한계를 넘어서다 인공지능 모델이 특정 맥락에서 유용하게 사용되기 위해서는 배경 지식에 대한 접근이 필요합니다. 예를 들어, 고객 지원 챗봇은 해당 비즈니스에 대한 지식이 필요하며, 법률 분석 봇은 방대한 과거 사례에 대한 정보를 알아야 합니다.개발자들은 일반적으로 **RAG(Retrieval-Augmented Generation)**를 사용하여 AI 모델의 지식을 향상시킵니다. RAG는 지식 베이스에서 관련 정보를 검색하여 사용자의 프롬프트에 추가함으로써 모델의 응답을 크게 개선하는 방법입니다. 그러나 전통적인 RAG 솔루션은 정보를 인코딩할 때 맥락을 제거하는 경향이 있어, 시스템이 지식 베이스에서 관련 정보를 검색하지 못하는 경우가 종종 발생합니다.이 글에서는 RAG의 검색 단계를 획기적으로 개선하는 방법을 소개합니..
Spring REST Docs vs Swagger: API 문서화를 완벽하게 관리하는 두 가지 방법 1. API 문서화의 필요성과 통합 관리의 장점API 문서화는 개발자가 작성한 API에 대해 정확하고 이해하기 쉬운 정보를 제공하는 중요한 과정입니다. 이 과정은 여러 가지 이유로 필수적입니다:개발자 간 의사소통: 팀 내에서나 외부 개발자와 협업할 때, API가 어떻게 동작하는지에 대한 명확한 설명이 필요합니다. 문서화된 API는 불필요한 커뮤니케이션 비용을 줄여줍니다.유지 보수의 용이성: 프로젝트가 확장되거나 유지 보수 단계로 넘어갈 때, 문서화된 API는 빠른 파악과 문제 해결을 돕습니다.사용자 및 클라이언트의 이해도 향상: 외부 클라이언트나 API를 사용하는 다른 팀들이 API를 쉽게 이해하고 올바르게 사용할 수 있도록 문서화는 필수적입니다.테스트 및 품질 향상: API 문서는 테스트를 보다 정확하..
마이크로서비스의 핵심! Service Discovery로 유연하고 확장 가능한 아키텍처 만들기 마이크로서비스 아키텍처에서 Service Discovery의 필요성과 출연 배경마이크로서비스 아키텍처는 각 서비스가 독립적으로 개발, 배포, 그리고 관리되는 구조입니다. 이를 통해 확장성과 유연성을 높일 수 있지만, 서비스들이 서로 통신하기 위해서는 각 서비스의 위치(IP 주소 및 포트 번호)를 알아야 합니다. 문제는 마이크로서비스 환경에서는 이러한 서비스들이 빈번하게 스케일링(증가/감소), 이동, 또는 재시작되기 때문에 각 서비스의 위치가 동적으로 변할 수 있다는 점입니다.초기의 모놀리식 아키텍처에서는 모든 서비스가 하나의 코드베이스에 통합되어 있어 통신이 비교적 단순했습니다. 그러나 마이크로서비스로 전환하면서 서비스들이 서로 독립적으로 배포되기 때문에 서비스 간의 위치 정보를 관리하는 방식이 필요해졌..
백준 알고리즘 문제 풀이 가이드: 코딩 면접 대비 완벽 준비-5639 이진 검색 트리 편 (python) 문제 살펴보기!!문제 링크 : https://www.acmicpc.net/problem/5639솔루션 살펴보기!!import sysimport syssys.setrecursionlimit(100000) # 재귀 한계를 늘려 깊은 트리도 처리 가능하게 함def construct_postorder(preorder, index, bound, postorder): """ 전위 순회 리스트를 기반으로 후위 순회 리스트를 생성하는 재귀 함수. Args: - preorder: 전위 순회 리스트 - index: 현재 처리 중인 인덱스를 담은 리스트 (참조를 위해 리스트로 전달) - bound: 현재 서브트리의 상한값 - postorder: 생성된 후위 순회 리스트 "..
깔끔한 커밋 히스토리를 만드는 방법: Git Squash의 모든 것 Git을 사용하다 보면 하나의 기능이나 이슈를 해결하기 위해 여러 번의 커밋이 발생할 수 있습니다. 코드 수정, 버그 해결, 코드 리뷰 대응 등 다양한 이유로 커밋이 쌓이게 되는데요. 이런 여러 커밋을 그대로 남겨두면 커밋 히스토리가 불필요하게 복잡해질 수 있습니다. 특히, 오픈 소스 프로젝트나 여러 개발자가 협업하는 환경에서는 깔끔한 커밋 히스토리가 매우 중요합니다. 이를 해결하기 위한 방법으로 Git Squash를 사용할 수 있습니다.이 포스트에서는 Git Squash가 무엇인지, 왜 필요하며, 어떻게 사용하는지에 대해 자세히 알아보겠습니다.Git Squash란 무엇인가?Git Squash는 여러 커밋을 하나로 합치는 기능입니다. Squash를 사용하면 여러 개의 커밋 이력을 단일 커밋으로 병합하여 ..
GitLab Merge Request 충돌 해결하기: 웹에서 vs. 로컬에서 Merge Request(MR) 과정에서 발생하는 **Code Conflict(코드 충돌)**은 협업 개발에서 피할 수 없는 부분입니다. 하지만 이를 효율적으로 해결하는 방법을 잘 알고 있다면, 개발 흐름을 지연시키지 않고 빠르게 작업을 이어갈 수 있습니다. 이번 글에서는 GitLab에서 Merge Request 시 발생하는 코드 충돌의 원인과 이를 해결하는 두 가지 방법에 대해 알아보겠습니다. 먼저 GitLab 웹에서 간편하게 해결하는 방법을 살펴보고, 그다음으로 로컬 환경에서 Git 명령어를 통해 직접 해결하는 방법을 설명하겠습니다.1. Code Conflict(코드 충돌)이 발생하는 이유코드 충돌은 여러 개발자가 같은 파일의 동일한 부분을 수정할 때 발생합니다. 특히 Merge Request는 서로..

티스토리툴바