CELL AI DEVLOG

AI 에이전트를 만들고 나면 이런 질문이 생겨요."이 에이전트가 잘 동작하는 건지 어떻게 알지? 그냥 써보는 것 말고 제대로 측정하는 방법이 있나?"일반 소프트웨어는 테스트가 간단해요. 같은 입력에 같은 출력이 나오면 패스, 다르면 실패. 근데 AI 에이전트는 비결정적이고, 여러 단계를 거치고, 툴을 호출하고, 컨텍스트를 누적해요. 전통적인 테스트 방식이 안 통해요.이번 글에서는 에이전트 평가가 왜 어려운지, 무엇을 측정해야 하는지, 어떤 방법으로 측정하는지 정리해 드릴게요.왜 에이전트 평가는 어려운가일반 LLM 평가와 에이전트 평가의 차이는 이거예요.일반 LLM 평가프롬프트 입력 → 답변 출력 → 정답과 비교에이전트 평가목표 입력 → 툴 호출 결정 (올바른 툴인가?) → 툴 실행 (파라미터가 맞는가..

여러 에이전트를 만들고 나면 이런 고민이 생겨요."에이전트들을 어떻게 연결하지? 누가 누구한테 일을 시키고, 결과는 어떻게 모으지?"이게 오케스트레이션 패턴 선택의 문제예요. 패턴을 잘못 고르면 에이전트들이 무한루프에 빠지거나, 병목이 생기거나, 디버깅이 불가능한 시스템이 돼요. 이번 글에서는 세 가지 핵심 패턴을 원리부터 실전 적용까지 정리해 드릴게요.패턴 1: Pipeline (순차 파이프라인)개념에이전트들이 고정된 순서대로 실행돼요. A의 출력이 B의 입력이 되고, B의 출력이 C의 입력이 되는 조립 라인 구조예요.사용자 입력 │ ▼[에이전트 A: 정보 수집] │ ▼[에이전트 B: 분석] │ ▼[에이전트 C: 글쓰기] │ ▼[에이전트 D: 검수] │ ..

RAG 시스템을 만들고 나면 이런 한계가 생겨요."단순한 질문은 잘 답하는데, '2024년 실적을 바탕으로 2025년 전략을 분석해줘' 같은 복잡한 질문은 엉뚱한 답이 나온다."이건 일반 RAG의 구조적 한계예요. 한 번 검색하고 끝나는 구조로는 복잡한 다단계 질문을 처리할 수가 없어요. 이걸 해결하는 게 Agentic RAG입니다.일반 RAG의 한계일반 RAG의 파이프라인은 고정돼 있어요.질문 → 벡터 검색 → 상위 K개 문서 → LLM → 답변단순하고 빠른데, 세 가지 문제가 있어요.한 번밖에 검색 못 해요. 검색 결과가 별로여도 그냥 그걸로 답해요. "부족하다"는 판단을 못 해요.쿼리 복잡도를 무시해요. "파이썬이 뭐야?" 같은 단순 질문과 "2024년 AI 트렌드를 분석하고 우리 회사 전략에 어떻..

Elasticsearch로 RAG 시스템을 만들다 보면 이런 상황이 생겨요."의미 기반 벡터 검색도 하고 싶고, 정확한 키워드 검색도 하고 싶은데 어떻게 같이 써?"그리고 한국어 데이터를 다루면 또 이런 문제가 생겨요."형태소 분석 없이 BM25 하면 '검색엔진'으로 검색할 때 '검색'만 들어간 문서가 안 나오네."이번 글에서는 Dense Vector KNN으로 의미 검색을 하고, Nori 형태소 분석기 기반 BM25로 키워드 검색을 하고, 두 개를 하이브리드로 결합하는 방법을 처음부터 끝까지 정리해 드릴게요.전체 구조 먼저사용자 쿼리 │ ├─ 임베딩 변환 → Dense Vector KNN (의미 기반 검색) └─ 텍스트 그대로 → BM25 + Nori (키워드 기반 검색) │ ..

파라미터 크기가 작은 LLM을 사용하여 AI 에이전트를 만들다 보면 이런 상황이 반드시 생겨요."분명히 JSON으로 답하라고 했는데 왜 마크다운 코드블록으로 감싸서 오지? 왜 필드가 빠져 있지?"LLM 출력을 믿고 그냥 json.loads() 하면 언젠가 반드시 터져요. 이번 글에서는 Pydantic으로 LLM 출력을 안정적으로 검증하는 방법을 정리해 드릴게요.왜 LLM 출력 파싱이 어려운가LLM은 확률적으로 텍스트를 생성해요. "JSON으로만 답해"라고 해도 이런 일이 생겨요.문제 1: 마크다운 펜스가 붙어서 옴```json{"result": "success"}**문제 2: 필드가 빠져 있음**```json{"result": "success"}// reasoning 필드가 없음문제 3: 타입이 틀림{"..

RAG 시스템을 만들 때 이런 고민이 생깁니다."벡터 DB가 이렇게 많은데 뭘 써야 하지? 다들 자기가 제일 빠르다고 하는데."벤더 벤치마크는 전부 자기한테 유리하게 나와 있어요. 이번 글에서는 ChromaDB, Qdrant, Pinecone, Elasticsearch 네 가지를 실전 관점에서 비교해 드릴게요.벡터 DB가 왜 필요한가일반 DB는 정확한 값으로 검색해요. "이름 = 홍길동"처럼요. 벡터 DB는 의미적으로 유사한 것을 찾아요. "강아지"를 검색하면 "멍멍이", "반려견", "puppy"도 찾아주는 거예요.RAG 시스템에서 "사용자 질문과 관련된 문서를 찾아서 LLM에 넘기는" 과정이 바로 벡터 검색이에요. 이 검색이 빠르고 정확해야 RAG 전체 품질이 올라갑니다.4개 한눈에 비교구분 Chro..

AI 에이전트로 긴 작업을 시키다 보면 이런 일이 생겨요."분명히 앞에서 결정한 내용인데 에이전트가 또 같은 실수를 하네?"컨텍스트 창이 꽉 찼거나, 중요한 정보가 밀려나버린 거예요. 이 문제를 어떻게 해결하느냐가 프로덕션 수준의 에이전트를 만드는 핵심입니다. 이번 글에서는 컨텍스트 압축의 세 가지 전략과 실제로 어떻게 조합해서 쓰는지 정리해 드릴게요.왜 컨텍스트 관리가 중요한가모델의 컨텍스트 창은 유한해요. 긴 작업을 하다 보면 툴 출력, 중간 대화, 오류 메시지들이 쌓여서 창을 잠식합니다. 새로운 정보가 들어올 자리가 없어지고, 중요한 정보가 창 밖으로 밀려나기 시작하면 에이전트가 앞서 한 결정을 기억하지 못하거나 같은 실수를 반복해요.이걸 **컨텍스트 표류(Context Drift)**라고 해요. ..

AI 에이전트를 만들 때 흔히 하는 실수가 있어요."툴을 많이 줄수록 에이전트가 더 잘하겠지."Vercel AI SDK 팀이 정확히 이 생각으로 접근했다가 반대 결과를 경험했어요. 툴을 계속 추가했더니 어느 순간부터 오히려 성능이 떨어졌고, 툴을 80%까지 줄였더니 성능이 올라갔습니다.이번 글에서는 왜 이런 일이 생기는지, 그리고 툴을 어떻게 설계해야 하는지 정리해 드릴게요.왜 툴이 많으면 성능이 떨어지나이유 1: 선택 비용 (Choice Overhead)모델이 툴을 고를 때마다 의사결정을 해야 해요. 툴이 5개면 "이 중에 뭘 써야 하지?"가 간단한 문제지만, 툴이 50개면 모델이 정의를 전부 읽고 비교하고 선택해야 합니다. 이 과정에서 추론 토큰이 낭비되고, 잘못된 툴을 고를 확률도 올라가요.인간도 ..

AI 에이전트를 만들다 보면 이런 경험을 하게 됩니다."GPT-4 쓰는데 왜 Claude Code보다 못하지? 모델이 비슷한데 결과가 왜 이렇게 다르지?"모델 성능 차이가 아니에요. 하네스 엔지니어링 수준 차이입니다. 이번 글에서는 하네스 엔지니어링이 뭔지, 어떤 구성요소로 이루어지는지, 그리고 Claude Code가 이걸 어떻게 구현했는지 분석해 드릴게요.하네스 엔지니어링이란?AI 에이전트가 "실험실에서 잘 되네" 수준을 넘어서 실제 프로덕션에서 안정적으로 동작하게 만드는 설계와 구축 작업 전체예요.모델은 이미 충분히 똑똑해요. GPT-4, Claude, Gemini 다 비슷한 수준이에요. 근데 어떤 제품은 잘 되고 어떤 제품은 망하는 이유가 뭐냐 — 하네스 엔지니어링 수준 차이입니다.실제 사례를 보면..

AI 에이전트를 공부하다 보면 이런 의문이 생깁니다."LLM 모델 자체는 그냥 질문에 답하는 거잖아. 그럼 Claude Code나 Cursor는 어떻게 파일도 읽고 API도 호출하는 거지?"그 답이 바로 **하네스(Harness)**입니다. 이번 글에서는 하네스가 뭔지, Orchestrator와 어떻게 다른지, 실제 제품에서 어떻게 쓰이는지 정리해 드릴게요.모델 단독으로는 "실험실" 수준이다LLM 모델 자체는 "질문 받으면 답변 생성"하는 것밖에 못 해요. 실제 업무에 투입하면 세 가지 한계가 바로 드러납니다.첫째, 기억이 리셋됩니다. 대화가 끝나면 이전 맥락을 전혀 기억하지 못해요. 컨텍스트 창이 꽉 차면 앞 내용이 잘려나가기도 하고요.둘째, 에러가 나면 그냥 멈춥니다. API 호출이 실패하거나 도구 ..