'분류 전체보기' 카테고리의 글 목록

분류 전체보기

Covenant

2026.06.03

시작하며Source: Linkedin (Link)자바는 올해로 30주년을 맞이하였습니다. 한때 VM 기반의 성능 한계나 장황한 코드라는 비판을 받기도 했지만, 자바는 늘 끊임없이 변화하였습니다. 오늘날 가장 현대적이고 강력한 생태계를 갖춘 언어로 자리매김하고 있습니다.JDK25는 장기 지원(LTS) 버전입니다. 단순한 버그 수정이나 소소한 개선이 아니라, 개발자 생산성과 성능을 크게 향상시키는 굵직한 변화들이 포함되어 있습니다. 일부 기능은 이전 버전에서 Preview로 먼저 선보였다가 이번에 정식 채택된 것들도 있습니다. 역동적인 자바의 변화 내용을 살펴보려고 합니다.패턴 매칭에서 기본형(Primitive Type) 사용: JEP 507패턴 매칭이 더 똑똑해졌습니다.기존에는 switch와 instanc..

지구상에서 가장 친절한 RAG 06: 조직에서 RAG를 도입할 때 자주 묻는 질문들

2026.06.03

시작하며1M Context, LLM-Wiki, Ontology, NLM MCP 사이에서 무엇을 선택해야 할까요?RAG에 대한 논의는 여전히 뜨겁습니다. 한때 RAG는 LLM의 한계를 보완하는 가장 현실적인 방법처럼 보였습니다. 내부 문서를 검색해 답변에 활용하면 hallucination을 줄이고, 최신 정보를 반영하고, 조직 지식을 쉽게 활용할 수 있을 것처럼 보였기 때문입니다.하지만 실제로 조직에서 RAG를 운영해보면 기대와 다른 지점이 금방 드러납니다.구현 자체는 어렵지 않습니다. 문서를 넣고, chunk로 나누고, embedding을 만들고, vector database에 저장하고, 질문이 들어오면 유사한 chunk를 찾아 LLM에 넣으면 됩니다. 문제는 그 다음입니다."와, 문맥 참조가 되네?"에..

지구상에서 가장 친절한 RAG 05: 검색된 근거를 더 잘 쓰는 방법

2026.06.03

시작하며RAG 시스템에서 좋은 답변을 만들기 위해서는 먼저 관련 문서를 잘 찾아야 합니다. 하지만 검색만 잘한다고 항상 좋은 답변이 만들어지는 것은 아닙니다.검색 결과에는 질문과 관련성이 높은 chunk도 있지만, 덜 중요한 chunk, 중복된 chunk, 순서가 어색한 chunk, 너무 긴 context도 함께 포함될 수 있습니다. 이 상태로 그대로 LLM에 전달하면 LLM은 불필요한 정보에 주의를 빼앗기거나, 중요한 정보를 충분히 활용하지 못할 수 있습니다.이 문제를 해결하기 위한 단계가 Post-retrieval Optimization입니다.Post-retrieval Optimization은 검색이 끝난 뒤, LLM에 context를 전달하기 전에 검색 결과를 다시 정리하고 최적화하는 과정입니다. ..

지구상에서 가장 친절한 RAG 04: 더 좋은 근거를 찾는 검색 전략

2026.06.03

시작하며RAG 시스템의 핵심은 "필요한 정보를 얼마나 잘 찾아오느냐"에 있습니다. LLM이 아무리 뛰어나도 검색 단계에서 관련 없는 문서가 들어오면 답변 품질은 낮아집니다. 반대로 사용자의 질문과 정확히 맞는 근거 문서를 찾아오면, LLM은 더 정확하고 신뢰할 수 있는 답변을 생성할 수 있습니다.이때 중요한 것이 Retrieval Optimization입니다.Retrieval Optimization은 사용자의 query에 대해 더 관련성 높은 문서나 chunk를 찾아오기 위해 검색 방식을 개선하는 전략입니다. 앞서 다룬 Pre-retrieval Optimization이 "검색 전에 query를 정리하는 과정"이었다면, Retrieval Optimization은 "검색을 수행하는 방식 자체를 개선하는 과정..

지구상에서 가장 친절한 RAG 03: 검색 전에 질문을 최적화하는 방법

2026.06.03

시작하며RAG 시스템을 개선한다고 하면 보통 검색 알고리즘, 벡터 데이터베이스, 임베딩 모델, re-ranking 같은 요소를 먼저 떠올립니다. 하지만 검색 품질은 실제 검색이 시작되기 전부터 이미 많은 부분이 결정됩니다.사용자의 질문이 모호하거나 너무 복잡하거나, 검색 시스템이 이해하기 어려운 형태라면 아무리 좋은 검색기를 사용해도 원하는 정보를 정확히 찾기 어렵습니다. 이 문제를 해결하기 위한 접근이 Pre-retrieval Optimization입니다.Pre-retrieval Optimization은 검색을 수행하기 전에 사용자의 query를 더 검색하기 좋은 형태로 바꾸거나, 여러 하위 질문으로 나누거나, 적절한 검색 경로로 보내는 기법입니다. 쉽게 말하면 "검색을 잘하기 위해 질문을 먼저 정리하..

지구상에서 가장 친절한 RAG 02: 청킹 전략은 왜 중요한가

2026.06.03

시작하며RAG 시스템을 설계할 때 많은 사람들이 임베딩 모델이나 벡터 데이터베이스 선택에 집중합니다. 하지만 실제 검색 품질을 크게 좌우하는 요소 중 하나는 문서를 어떻게 나누는지, 즉 Chunking Strategy입니다.Chunking은 큰 문서를 작은 단위로 나누는 과정입니다. RAG에서는 사용자의 질문과 가장 관련 있는 chunk를 검색한 뒤, 그 내용을 LLM에 전달해 답변을 생성합니다. 따라서 chunk가 어떻게 만들어졌는지에 따라 검색 결과의 품질과 최종 답변의 정확도가 달라집니다.좋은 chunking은 단순히 문서를 잘게 자르는 작업이 아닙니다. 문서의 의미와 구조를 최대한 보존하면서, 검색하기 좋은 크기와 단위로 재구성하는 과정입니다.전체 흐름왜 Chunking이 중요한가요?RAG에서 문..

지구상에서 가장 친절한 RAG 01: 데이터 전처리가 검색 품질을 결정하는 이유

2026.06.03

1. 시작하며 RAG를 도입할 때 많은 사람들이 먼저 LLM 성능, 임베딩 모델, 벡터 데이터베이스, 프롬프트 최적화에 집중합니다. 물론 이 요소들도 중요합니다. 하지만 실제 RAG 시스템의 품질을 좌우하는 더 근본적인 요소가 있습니다. 바로 Data Pre-Processing, 즉 데이터 전처리입니다. RAG는 외부 문서를 검색한 뒤, 검색된 정보를 LLM에 전달해 답변을 생성하는 방식입니다. 따라서 LLM이 아무리 좋아도 검색되는 데이터가 부정확하거나 지저분하면 좋은 답변을 만들기 어렵습니다. 결국 RAG의 답변 품질은 어떤 데이터를, 어떤 형태로, 얼마나 잘 검색 가능하게 만들었는지에 따라 결과가 결정됩니다.전체 흐름 2. 데이터 전처리란? 데이터 전처리는 원본 데이터를 RAG 시스템에서 사용할 ..

지구상에서 가장 친절한 RAG 00: LLM에게 필요한 정보를 찾아주는 기술

2026.06.03

RAG 전체 흐름도 시작하며 요즘 LLM 기반 서비스를 만들다 보면 에이전트, 툴 호출, 에이전틱 워크플로우, 온톨로지, 그래프 RAG 같은 용어를 자주 만나게 됩니다.하지만 그보다 먼저 이해해야 할 기본 개념 중 하나가 바로 RAG입니다.RAG는 오래된 개념처럼 보일 수 있지만, 여전히 LLM을 실무 시스템으로 만들 때 매우 중요한 구조입니다.특히 모델이 모르는 정보를 어떻게 제공할 것인지, 최신 데이터나 내부 문서를 어떻게 활용할 것인지 고민한다면 RAG는 거의 반드시 등장합니다.벡터 기반 RAG를 중심으로, RAG의 목적과 동작 방식, 임베딩, 벡터 DB, 청킹, 리랭킹, Query Transformation 같은 핵심 개념을 정리합니다.1. RAG가 왜 필요한가요? LLM은 많은 지식을 알고 있는..

클로드코드 스킬 실전 가이드: 에이전트에게 일하는 법 가르치기

2026.05.30

시작하며Claude Code를 쓰다 보면 비슷한 요청을 계속 반복하게 됩니다."테스트는 Given-When-Then으로 작성해줘", "API 응답에는 에러 핸들링을 포함해줘", "우리 팀 컨벤션에 맞춰 파일명을 정리해줘" 같은 요청입니다. 처음 몇 번은 프롬프트로 적으면 되지만, 프로젝트가 길어질수록 같은 말을 반복하는 것이 번거로워집니다.이때 사용할 수 있는 기능이 Claude Code의 Skill입니다.Skill은 Claude에게 특정 업무를 어떻게 수행해야 하는지 알려주는 재사용 가능한 지침입니다. 회사에서 신입사원에게 온보딩 문서를 주는 것처럼, Claude에게도 프로젝트의 규칙과 작업 방식을 문서로 전달하는 방식입니다.이번 글에서는 Claude Code Skill이 무엇인지, Agent와는 무엇..

싱글 에이전트, 멀티 에이전트 어느것을 선택해야할까?

2026.05.30

시작하며2026년의 AI 개발 도구 흐름을 보면 멀티 에이전트라는 키워드를 자주 보게 됩니다.분석 에이전트, 구현 에이전트, 검증 에이전트, 리뷰 에이전트처럼 역할을 나누고, 각 에이전트가 독립적으로 움직이며 결과를 합치는 방식입니다. 이름만 들으면 꽤 그럴듯합니다. 특히 대규모 코드베이스를 대상으로 마이그레이션이나 리팩터링을 해야 한다면, 여러 에이전트를 동시에 투입하는 편이 더 효율적으로 보입니다.하지만 제가 회사에서 마이그레이션을 진행해 보았을 때, 꼭 그렇지는 않았습니다.예를 들어 Spring Boot 3.0대에서 3.5로 올리고, JDK도 21에서 25로 올리는 마이그레이션을 생각해 보겠습니다. 이런 작업은 단순히 버전 숫자만 바꾸는 일이 아닙니다. Spring Security 설정 변경, 의존..

스프링부트 3에서 jakarta 패키지 전환

2026.05.30

시작하며Spring Boot 3.0으로 프로젝트를 올리거나 새 프로젝트를 만들다 보면 가장 먼저 눈에 들어오는 변화가 있습니다. 익숙하게 사용하던 javax.persistence.Entity, javax.servlet.http.HttpServletRequest 같은 패키지가 더 이상 자연스럽게 잡히지 않고, 대신 jakarta.persistence.Entity, jakarta.servlet.http.HttpServletRequest를 사용해야 합니다.처음 보면 단순히 패키지 이름만 바뀐 것처럼 보입니다. 실제 API 사용법도 크게 다르지 않아서 IDE의 자동 변환만 믿고 넘어가기 쉽습니다.그러나 javax에서 jakarta로 바뀐 것은 단순한 리팩터링이 아닙니다. Java 엔터프라이즈 생태계가 Oracl..

n8n is dead?

2026.05.30

n8n is dead?작년 이맘때만 해도 n8n은 자동화 툴의 대세였습니다. 유튜브와 각종 SNS에는 n8n 워크플로우로 자동화한 사례가 하루가 멀다 하고 올라왔습니다. 그런데 올해는 n8n 이야기는 사라지고 조용합니다. 이걸 반영이라도 하듯 해외 커뮤니티에서는 n8n is dead?라는 주제의 글이 종종 보이곤 합니다.작년 7월부터 회사에서 팀에서 사용할 n8n을 구축하였습니다. 다른 팀보다 꽤 빠르게 도입하였습니다.n8n을 적용하고, 실제 업무에 붙여보고 사용하면서 한계를 몸으로 겪었습니다. n8n 그 후기를 남겨보려고 합니다.n8n의 적용에 막히는 지점들1. 약한 병렬 처리n8n에 병렬 처리 기능이 있긴 합니다. 그런데 각종 제약이 많기에 막상 써보면 리소스를 충분히 사용하지 못합니다. 이러한 n8..

엔트로픽의 오픈코드 차단 사건 정리

2026.01.23

앤트로픽에서 오픈코드의 차단Reddit. OpenCode를 OAuth 방식을 통해 Claude에 접속한 사용자의 차단 (Source. Reddit)2026년 1월 9일, 평화롭던 바이브코딩을 즐기던 개발자들에게 깜짝 놀랄 소식이 공유되었습니다.잘 사용하던 앤트로픽 계정이 정지되었다는 제보가 잇따랐습니다. 공통점은 하나였습니다. 바로 Claude Code의 인증 토큰을 활용해 OpenCode를 사용하던 유저들이었습니다.앤트로픽은 해당 사용자들에게 "허용되지 않은 자동화된 접근" 을 이유로 계정을 영구 정지하거나, 조직(Organization) 단위의 밴을 적용했습니다. 일부 사용자에게는 결제된 금액인 $200를 환불하며 우리 서비스를 떠나라는 통보를 보냈습니다.Raddit. OpenCode 저장소 이슈에 ..

Covenant