[{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"AI","type":"tags"},{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/categories/ai-%EA%B8%B0%EC%88%A0/","section":"Categories","summary":"","title":"AI 기술","type":"categories"},{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/ai-news/","section":"AI 뉴스","summary":"","title":"AI 뉴스","type":"ai-news"},{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/tags/anthropic/","section":"Tags","summary":"","title":"Anthropic","type":"tags"},{"content":"이 글은 Anthropic 엔지니어링 블로그에 2025년 1월 6일 게재된 \u0026ldquo;Raising the bar on SWE-bench Verified with Claude 3.5 Sonnet\u0026rdquo; 을 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/swe-bench-sonnet\n한 줄로 말하면 # Claude 3.5 Sonnet이 코딩 벤치마크 1위를 찍은 건, 모델이 좋아져서만이 아니라 AI가 쓰는 도구를 잘 설계했기 때문이다.\n어떤 문제를 해결하려 했나 # AI가 코드를 잘 짠다고 하지만, 정말 실무에서 쓸 수 있는 수준인지 어떻게 알 수 있을까요?\n\u0026ldquo;간단한 함수 작성\u0026quot;이나 \u0026ldquo;알고리즘 풀이\u0026quot;는 AI가 잘합니다. 하지만 실제 개발 현장은 다릅니다. 누군가 GitHub에 이런 이슈를 올립니다.\n\u0026ldquo;requests 라이브러리에서 특정 조건일 때 타임아웃이 무시되는 버그가 있습니다.\u0026rdquo;\n이 이슈를 해결하려면 저장소 전체 코드를 파악하고, 어떤 파일을 수정해야 할지 찾아내고, 코드를 바꾸고, 테스트까지 통과시켜야 합니다. 사람도 몇 시간이 걸리는 작업입니다.\n이걸 AI 혼자 할 수 있을까? 이것을 측정하는 도구가 SWE-bench입니다.\n해결책: SWE-bench로 측정하고, 도구 설계로 돌파하다 # SWE-bench(소프트웨어 엔지니어링 벤치마크)란 # SWE-bench(Software Engineering Benchmark)는 AI가 실제 GitHub 이슈를 해결할 수 있는지 테스트하는 평가 도구입니다.\nGitHub 이슈 제공 ↓ AI가 저장소를 탐색하고 코드 수정 ↓ 실제 유닛 테스트로 정답 여부 채점 중요한 점은 AI 모델 단독이 아니라, 모델 + 도구(에이전트 시스템) 전체를 평가한다는 것입니다.\nAnthropic의 접근법: 단순하게, 도구를 정교하게 # Anthropic이 선택한 에이전트 구조는 놀랍도록 단순합니다.\n[에이전트 구성] 초기 프롬프트 (접근 방법 제안) + Bash Tool (터미널 명령 실행) + Edit Tool (파일 읽기/수정) 복잡한 구조 대신, 도구 자체를 정교하게 만드는 데 집중했습니다.\n특히 Edit Tool에는 한 가지 규칙이 있습니다. 문자열을 교체할 때 정확히 일치하는 경우에만 수정을 허용합니다. 모호한 수정을 원천 차단하는 것입니다.\n\u0026ldquo;도구 인터페이스를 설계하는 데 사람 인터페이스를 설계하는 것만큼 공을 들여야 한다.\u0026rdquo;\n결과 / 효과 # 모델 SWE-bench 점수 Claude 3 Opus 22% Claude 3.5 Sonnet (구) 33% 이전 1위 45% Claude 3.5 Sonnet (신) 49% 한 세대 만에 22% → 49%. 두 배 이상 올랐습니다.\n단, 이 수치가 만능은 아닙니다. 성공한 케이스를 보면 수백 번의 반복 작업과 10만 토큰 이상을 소비하는 경우도 있었습니다. 아직 모든 이슈를 가볍게 해결하는 단계는 아닙니다.\n핵심 결론 # 모델을 키우는 것만이 답이 아닙니다.\nClaude 3.5 Sonnet이 1위에 오른 핵심은 AI가 사용하는 도구의 인터페이스를 정교하게 만든 것이었습니다. 도구가 AI의 실수를 원천 차단하도록 설계하자, 성능이 뛰어올랐습니다.\n\u0026ldquo;AI 성능의 문제인 줄 알았는데, 사실은 AI가 쓰는 도구 설계의 문제였다.\u0026rdquo;\n내 작업에 적용한다면 # 현재 만들고 있는 발행 파이프라인에도 이 원칙을 적용할 수 있습니다.\n[지금 파이프라인] 본문 수집 → Claude 분석 → 마크다운 생성 → git push [도구 설계 원칙 적용 후] 본문 수집 ↓ [검사: 상태코드 200인지 확인] Claude 분석 ↓ [검사: front matter 형식이 맞는지 확인] 마크다운 생성 ↓ [검사: 필수 섹션이 모두 있는지 확인] git push 각 단계 사이에 실수를 원천 차단하는 검사를 넣는 것. 이게 SWE-bench에서 Anthropic이 배운 교훈이고, 우리 파이프라인을 자동화할 때도 그대로 적용됩니다.\nAnthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.\n","date":"2026년 5월 4일","externalUrl":null,"permalink":"/ai-news/swe-bench-sonnet/","section":"AI 뉴스","summary":"Claude 3.5 Sonnet이 AI 코딩 벤치마크 1위에 오른 비결. 모델만 좋아진 게 아니라, AI가 쓰는 도구를 잘 설계한 덕분이다.","title":"Anthropic 엔지니어링 블로그 #3: Raising the bar on SWE-bench Verified — AI가 GitHub 이슈를 혼자 해결한다","type":"ai-news"},{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/tags/claude/","section":"Tags","summary":"","title":"Claude","type":"tags"},{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/","section":"CodeBerry","summary":"","title":"CodeBerry","type":"page"},{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/tags/swe-bench/","section":"Tags","summary":"","title":"SWE-Bench","type":"tags"},{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/tags/%EB%B2%A4%EC%B9%98%EB%A7%88%ED%81%AC/","section":"Tags","summary":"","title":"벤치마크","type":"tags"},{"content":"","date":"2026년 5월 4일","externalUrl":null,"permalink":"/tags/%EC%BD%94%EB%94%A9%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8/","section":"Tags","summary":"","title":"코딩에이전트","type":"tags"},{"content":"","date":"2026년 5월 3일","externalUrl":null,"permalink":"/tags/agent/","section":"Tags","summary":"","title":"Agent","type":"tags"},{"content":"이 글은 Anthropic 엔지니어링 블로그에 2024년 12월 19일 게재된 **\u0026ldquo;Building Effective Agents\u0026rdquo;**를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/building-effective-agents\n이 글이 중요한 이유 # Anthropic은 수십 개의 팀과 함께 다양한 산업에서 LLM 에이전트를 구축해왔습니다. 그 경험에서 나온 결론이 이 글입니다.\n놀라운 점은, 가장 성공적인 구현들은 복잡한 프레임워크를 쓰지 않았다는 것입니다. 대신 단순하고 조합 가능한 패턴을 사용했습니다. AI 시대에 \u0026ldquo;더 복잡한 것이 더 좋다\u0026quot;는 통념을 정면으로 반박하는 내용이에요.\n에이전트 시스템이란 무엇인가 # 먼저 용어부터 정리합니다. Anthropic은 에이전트 시스템을 두 가지로 구분합니다.\n**워크플로우(Workflow)**는 LLM과 도구가 미리 정해진 코드 경로를 따라 실행되는 시스템입니다. 순서가 정해져 있고, 예측 가능합니다.\n**에이전트(Agent)**는 LLM이 스스로 다음 행동을 결정하고, 도구를 동적으로 선택하며, 환경 피드백에 따라 루프를 반복하는 시스템입니다. 훨씬 유연하지만, 그만큼 예측하기 어렵습니다.\n워크플로우: 입력 → 단계1 → 단계2 → 단계3 → 출력 (경로 고정) 에이전트: 입력 → LLM 판단 → 도구 선택 → 결과 확인 → 다시 판단 → ... (경로 유동) 중요한 것은 둘 중 어느 것이 더 좋은가가 아니라, 언제 무엇을 써야 하는가입니다.\n언제 에이전트를 써야 하는가 # 에이전트 시스템에는 트레이드오프가 있습니다.\n워크플로우 에이전트 속도 빠름 느림 비용 낮음 높음 예측 가능성 높음 낮음 유연성 낮음 높음 적합한 경우 잘 정의된 반복 작업 복잡하고 유동적인 작업 Anthropic의 핵심 조언은 간단합니다. 항상 가장 단순한 것부터 시작하세요. 에이전트가 필요하다고 느껴질 때도, 먼저 워크플로우로 해결할 수 없는지 먼저 확인하세요.\n7가지 핵심 패턴 # Anthropic이 정리한 에이전트 시스템의 빌딩 블록입니다. 이 패턴들을 조합하면 대부분의 실무 문제를 해결할 수 있습니다.\n패턴 1. Augmented LLM (기반) # 모든 것의 기초입니다. LLM에 세 가지를 붙여줍니다.\nLLM + 검색(Retrieval) + 도구(Tools) + 메모리(Memory) 검색은 RAG처럼 외부 지식을 가져오는 것, 도구는 계산기나 웹 검색처럼 LLM이 직접 할 수 없는 작업을 실행하는 것, 메모리는 대화 내용을 기억하는 것입니다. Anthropic은 외부 도구 연동에 MCP(Model Context Protocol) 를 추천합니다.\n패턴 2. Prompt Chaining (프롬프트 체이닝) # 복잡한 작업을 여러 단계로 쪼개서 순서대로 실행하는 방식입니다.\n마케팅 카피 작성 → 품질 검토 → 한국어로 번역 → 최종 검토 각 단계에서 프로그래밍 방식으로 검사(Gate)를 추가할 수 있어서, 앞 단계가 실패하면 다음 단계로 넘어가지 않습니다. 예측 가능하고 디버깅이 쉽습니다.\n적합한 경우: 고정된 하위 작업으로 분해할 수 있는 모든 작업\n패턴 3. Routing (라우팅) # 입력을 분류하고, 분류에 따라 적합한 처리 경로로 보내는 방식입니다.\n고객 문의 → 분류 → \u0026#34;환불 요청\u0026#34; → 환불 처리 모듈 → \u0026#34;기술 문의\u0026#34; → 기술 지원 모듈 → \u0026#34;일반 질문\u0026#34; → FAQ 모듈 모든 입력을 하나의 방식으로 처리하지 않고, 문제의 성격에 맞는 전문화된 처리를 연결할 수 있습니다. 복잡도에 따라 성능이 다른 모델을 연결하는 것도 가능합니다(비용 최적화).\n적합한 경우: 고객 서비스, 다양한 유형의 요청을 처리하는 시스템\n패턴 4. Parallelization (병렬화) # 두 가지 방식이 있습니다.\n섹셔닝(Sectioning): 독립적인 하위 작업을 동시에 처리합니다.\n긴 문서 → [섹션1 분석] [섹션2 분석] [섹션3 분석] → 결과 합산 (동시에 실행) 보팅(Voting): 동일한 작업을 여러 번 실행해서 다양한 결과를 얻습니다.\n코드 검토 → [검토1] [검토2] [검토3] → 다수결 또는 앙상블 적합한 경우: 독립적으로 처리 가능한 대용량 작업, 정확도가 중요한 판단 작업\n패턴 5. Orchestrator-Workers (오케스트레이터-워커) # 중앙 LLM(오케스트레이터)이 전체 계획을 세우고, 하위 LLM들(워커)에게 작업을 배분합니다.\n오케스트레이터: \u0026#34;이 기능을 구현하려면 3개 파일을 수정해야 해\u0026#34; ↓ 워커1: auth.py 수정 워커2: api.py 수정 워커3: tests.py 수정 ↓ 오케스트레이터: 결과 통합 및 검증 적합한 경우: 미리 어떤 하위 작업이 필요한지 예측하기 어려운 복잡한 작업, 코딩처럼 여러 파일에 걸쳐 변경이 필요한 작업\n패턴 6. Evaluator-Optimizer (평가자-최적화) # 한 LLM이 결과물을 만들면, 다른 LLM이 평가하고 피드백을 주는 루프입니다.\n생성자 LLM → 초안 작성 ↓ 평가자 LLM → \u0026#34;논리적 오류 있음, 3번 항목 수정 필요\u0026#34; ↓ 생성자 LLM → 수정 ↓ 평가자 LLM → \u0026#34;통과\u0026#34; ↓ 최종 결과물 적합한 경우: 명확한 평가 기준이 있는 작업, 반복 개선이 의미 있는 작업(번역 품질, 코드 정확도 등)\n패턴 7. Autonomous Agents (자율 에이전트) # 가장 고도화된 패턴입니다. LLM이 환경을 인식하고, 도구를 선택하며, 결과를 보고 다음 행동을 결정하는 루프를 스스로 반복합니다.\n목표 설정 ↓ 현재 상태 파악 → 도구 선택 → 실행 → 결과 확인 ↑___________________________________| (목표 달성까지 반복) 강력하지만 그만큼 신중하게 사용해야 합니다. Anthropic은 반드시 샌드박스 환경에서 충분히 테스트하고, 적절한 가드레일을 설치할 것을 권고합니다.\n도구 설계의 핵심: ACI # Anthropic은 ACI(Agent-Computer Interface) 설계에 HCI(Human-Computer Interface) 설계만큼의 투자가 필요하다고 강조합니다.\nSWE-bench 개발 시 팀이 발견한 사례가 인상적입니다. 모델이 상대 경로를 사용할 때 파일 경로 오류를 자주 냈는데, 절대 경로만 허용하도록 도구를 수정하자 오류가 사라졌습니다. 프롬프트를 수정한 게 아니라, 도구 자체를 수정한 거예요.\n좋은 도구 설계 원칙:\n모델이 추론할 충분한 공간(토큰)을 제공할 것 인터넷에서 자연스럽게 나타나는 형식에 가깝게 유지할 것 복잡한 포맷(정확한 카운트, 이스케이프 처리 등)은 피할 것 충분한 예시와 엣지 케이스가 포함된 문서를 작성할 것 실수를 원천 차단하는 방향으로 설계할 것 (Poka-yoke) 핵심 결론 # \u0026ldquo;성공은 가장 정교한 시스템을 만드는 것이 아니다. 나에게 맞는 올바른 시스템을 만드는 것이다.\u0026rdquo;\nAnthropic이 정리한 성공 공식:\n1. 단순한 프롬프트부터 시작 2. 포괄적인 평가로 최적화 3. 단순한 방법이 명확히 부족할 때만 복잡성 추가 많은 팀이 처음부터 에이전트를 만들려 합니다. 하지만 실제로 필요한 건 잘 설계된 프롬프트 체이닝 하나인 경우가 많습니다.\n실무 적용 방법 # 지금 당장 적용할 수 있는 것 # 패턴 선택 기준표 만들기: 새로운 자동화 과제가 생길 때마다 아래 질문을 먼저 해보세요.\n단계가 고정되어 있나? → Prompt Chaining 입력 유형이 다양한가? → Routing 독립적으로 처리 가능한가? → Parallelization 평가 기준이 명확한가? → Evaluator-Optimizer 위 모두 해당 없는 복잡한 작업? → Autonomous Agent (최후 수단) 도구보다 프롬프트 먼저: 복잡한 에이전트 프레임워크 도입 전에, 프롬프트 개선만으로 얼마나 해결되는지 먼저 확인하세요.\nACI에 투자하기: AI가 사용하는 도구의 인터페이스를 사람이 쓰는 UI처럼 섬세하게 설계하세요. 절대 경로 강제, 명확한 파라미터 명명, 풍부한 예시가 큰 차이를 만듭니다.\n우리 파이프라인에 적용한다면 # 현재 구축 중인 Anthropic 블로그 수집 → 분석 → 발행 파이프라인은 이 글의 Prompt Chaining 패턴 그 자체입니다.\n수집 (12_fetch_article.py) ↓ [Gate: 상태 코드 200 확인] 분석 (Claude) ↓ [Gate: 마크다운 형식 검증] 발행 (git push) ↓ [Gate: 배포 로그 확인] 완료 나중에 이 파이프라인을 자동화할 때, Evaluator-Optimizer 패턴을 추가하면 글 품질을 자동으로 검증하는 단계를 넣을 수 있습니다.\nAnthropic 엔지니어링 블로그를 읽고 정리합니다.\n","date":"2026년 5월 3일","externalUrl":null,"permalink":"/ai-news/building-effective-agents/","section":"AI 뉴스","summary":"수십 개의 팀과 함께 LLM 에이전트를 구축한 Anthropic이 정리한 핵심 원칙. 복잡한 프레임워크보다 단순하고 조합 가능한 패턴이 성공한다.","title":"Anthropic 엔지니어링 블로그 #2: Building Effective Agents — 에이전트를 제대로 만드는 법","type":"ai-news"},{"content":"","date":"2026년 5월 3일","externalUrl":null,"permalink":"/tags/llm/","section":"Tags","summary":"","title":"LLM","type":"tags"},{"content":"","date":"2026년 5월 3일","externalUrl":null,"permalink":"/tags/%EC%9B%8C%ED%81%AC%ED%94%8C%EB%A1%9C%EC%9A%B0/","section":"Tags","summary":"","title":"워크플로우","type":"tags"},{"content":"","date":"2026년 5월 3일","externalUrl":null,"permalink":"/tags/%EC%9E%90%EB%8F%99%ED%99%94/","section":"Tags","summary":"","title":"자동화","type":"tags"},{"content":"","date":"2026년 5월 3일","externalUrl":null,"permalink":"/tags/%ED%94%84%EB%A1%AC%ED%94%84%ED%8A%B8%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81/","section":"Tags","summary":"","title":"프롬프트엔지니어링","type":"tags"},{"content":"이 글은 Anthropic 엔지니어링 블로그에 2024년 9월 19일 게재된 **\u0026ldquo;Introducing Contextual Retrieval\u0026rdquo;**을 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/contextual-retrieval\n어떤 문제를 해결하려 했나 # AI 모델이 특정 도메인에서 유용하게 동작하려면 배경 지식이 필요합니다. 고객 지원 챗봇은 해당 기업의 정보를 알아야 하고, 법률 분석 봇은 방대한 판례를 참조할 수 있어야 합니다.\n이를 위해 개발자들은 RAG(Retrieval-Augmented Generation) 를 활용합니다. 문서를 작은 단위(청크)로 나누고, 질문과 가장 유사한 청크를 찾아 AI에게 전달하는 방식이죠.\n그런데 여기서 근본적인 문제가 생깁니다.\n문서를 청크로 잘라내는 순간, 문맥이 사라집니다.\n예를 들어 재무 보고서에서 이런 청크가 추출됐다고 해봅시다.\n\u0026ldquo;The company\u0026rsquo;s revenue grew by 3% over the previous quarter.\u0026rdquo;\n이 문장만 봐서는 어느 회사인지, 어느 분기인지 알 수 없습니다. 검색 시스템도 마찬가지입니다. 문맥이 없는 청크는 엉뚱한 질문에 매칭되거나, 정작 필요한 순간에 검색되지 않습니다.\nAnthropic의 해결책: Contextual Retrieval # Anthropic은 이 문제를 두 가지 기법의 조합으로 해결했습니다.\n1. Contextual Embeddings # 청크를 임베딩(벡터)으로 변환하기 전에, Claude가 해당 청크에 문맥 설명을 자동으로 추가합니다.\n[기존 방식] 청크: \u0026#34;The company\u0026#39;s revenue grew by 3% over the previous quarter.\u0026#34; → 그대로 임베딩 [Contextual Embeddings] 청크 앞에 추가: \u0026#34;이 내용은 Apple Inc.의 2024년 Q2 재무 보고서 중 수익 성장 섹션에서 발췌된 내용입니다.\u0026#34; → 문맥이 포함된 상태로 임베딩 Claude가 원본 문서 전체를 보고 각 청크에 맞는 50~100 토큰 분량의 설명을 자동 생성합니다.\n2. Contextual BM25 # 임베딩 기반 검색(의미 검색)에 더해, BM25(키워드 기반 검색) 도 함께 사용합니다. 이때도 마찬가지로 문맥이 추가된 청크를 인덱싱합니다.\n임베딩 검색은 의미는 잘 잡지만 정확한 키워드를 놓치는 경우가 있고, BM25는 키워드에 강하지만 의미 파악에 약합니다. 두 방법을 합치면 서로의 약점을 보완합니다.\n성능 결과 # Anthropic이 다양한 도메인에서 테스트한 결과입니다.\n방법 Top-20 청크 검색 실패율 개선율 기존 RAG 5.7% 기준 Contextual Embeddings 3.7% 35% 감소 Contextual Embeddings + BM25 2.9% 49% 감소 + 리랭킹 추가 ~1.9% 67% 감소 단순히 청크에 문맥을 추가하는 것만으로 검색 실패율이 절반 가까이 줄었습니다.\n비용은 얼마나 드나 # 문서 100만 토큰을 처리하는 기준으로 약 $1.02(단회 전처리 비용) 입니다.\nClaude의 프롬프트 캐싱 기능 덕분입니다. 원본 문서 전체를 매번 재처리하지 않고 캐시해서 재사용하기 때문에 비용이 크게 낮아집니다.\n핵심 결론 # RAG의 문제는 청킹이 아니라, 청킹 후 문맥 손실이다.\n기존에 많은 개발자들이 청크 크기를 조절하거나, 오버랩을 늘리거나, 더 좋은 임베딩 모델을 쓰는 방식으로 RAG 성능을 개선하려 했습니다. 하지만 Anthropic은 방향을 달리했습니다.\n청크를 더 잘 자르는 게 아니라, 청크가 잘린 후에도 문맥을 기억하게 만드는 것. 이 발상의 전환이 핵심입니다.\n실무 적용 방법 # 지금 당장 적용할 수 있는 것 # 하이브리드 검색 도입: 임베딩 검색만 쓰고 있다면 BM25를 함께 사용하세요. LangChain의 EnsembleRetriever로 쉽게 구현할 수 있습니다.\n청킹 전 컨텍스트 추가: 청크를 임베딩하기 전에 원본 문서의 제목, 섹션, 출처 정보를 앞에 붙이는 것만으로도 효과가 있습니다. Claude 없이도 규칙 기반으로 구현 가능합니다.\n리랭킹 모델 추가: 검색된 청크를 한 번 더 정렬하는 리랭커를 추가하면 정확도가 크게 오릅니다. Cohere Rerank나 cross-encoder 모델을 활용할 수 있습니다.\n이 글이 RAG 구현에 주는 시사점 # 우리가 앞으로 만들 RAG 파이프라인에서도 이 원칙을 적용할 수 있습니다.\n[단순 RAG] 문서 → 청킹 → 임베딩 → 검색 → 답변 [Contextual RAG] 문서 → 청킹 → 문맥 추가 → 임베딩 + BM25 → 하이브리드 검색 → 리랭킹 → 답변 처음부터 완벽하게 구현할 필요는 없습니다. 기본 RAG를 먼저 만들고, 검색 품질이 떨어지는 지점에서 이 기법들을 하나씩 추가하면 됩니다.\nAnthropic 엔지니어링 블로그를 읽고 정리합니다.\n","date":"2026년 5월 3일","externalUrl":null,"permalink":"/ai-news/contextual-retrieval/","section":"AI 뉴스","summary":"RAG 시스템에서 청킹 시 사라지는 문맥 정보를 Contextual Embeddings와 Contextual BM25로 보완하는 Anthropic의 접근법을 정리합니다.","title":"Anthropic 엔지니어링 블로그 #1: Contextual Retrieval — RAG의 맹점을 해결하는 법","type":"ai-news"},{"content":"","date":"2026년 5월 3일","externalUrl":null,"permalink":"/tags/bm25/","section":"Tags","summary":"","title":"BM25","type":"tags"},{"content":"","date":"2026년 5월 3일","externalUrl":null,"permalink":"/tags/rag/","section":"Tags","summary":"","title":"RAG","type":"tags"},{"content":"","date":"2026년 5월 3일","externalUrl":null,"permalink":"/tags/%EA%B2%80%EC%83%89/","section":"Tags","summary":"","title":"검색","type":"tags"},{"content":"","date":"2026년 5월 3일","externalUrl":null,"permalink":"/tags/%EC%9E%84%EB%B2%A0%EB%94%A9/","section":"Tags","summary":"","title":"임베딩","type":"tags"},{"content":"$ whoami 성경재 — IT 관제 / AI \u0026amp; 데이터 분석\n$ cat interests.txt AI 자동화: LLM 활용, 에이전트 설계, 업무 자동화 파이프라인 데이터 분석: 데이터 시각화, 분석 자동화, 인사이트 도출 AI 논문: 최신 연구 리뷰, 실무 적용 가능성 탐색 인프라 / 홈랩: 라즈베리파이, 셀프호스팅, 네트워크 $ cat this-blog.txt 직접 만든 서버에서 직접 운영하는 블로그입니다.\n서버: Raspberry Pi 5 (4GB) — 집에서 24시간 운영 중 스택: Hugo + Nginx + Cloudflare Tunnel 목적: 배우고 경험한 것을 기록하고, AI/데이터 분야의 유용한 정보를 공유 $ cat links.txt GitHub: Kyungjae-Sung ","date":"2026년 4월 15일","externalUrl":null,"permalink":"/about/","section":"CodeBerry","summary":"$ whoami 성경재 — IT 관제 / AI \u0026 데이터 분석\n$ cat interests.txt AI 자동화: LLM 활용, 에이전트 설계, 업무 자동화 파이프라인 데이터 분석: 데이터 시각화, 분석 자동화, 인사이트 도출 AI 논문: 최신 연구 리뷰, 실무 적용 가능성 탐색 인프라 / 홈랩: 라즈베리파이, 셀프호스팅, 네트워크 $ cat this-blog.txt 직접 만든 서버에서 직접 운영하는 블로그입니다.\n서버: Raspberry Pi 5 (4GB) — 집에서 24시간 운영 중 스택: Hugo + Nginx + Cloudflare Tunnel 목적: 배우고 경험한 것을 기록하고, AI/데이터 분야의 유용한 정보를 공유 $ cat links.txt GitHub: Kyungjae-Sung ","title":"소개","type":"page"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/homelab/","section":"Tags","summary":"","title":"Homelab","type":"tags"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/raspberry-pi/","section":"Tags","summary":"","title":"Raspberry-Pi","type":"tags"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/ssh/","section":"Tags","summary":"","title":"Ssh","type":"tags"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/tailscale/","section":"Tags","summary":"","title":"Tailscale","type":"tags"},{"content":" Tailscale이란? # Tailscale은 WireGuard 기반의 VPN 서비스입니다. 복잡한 설정 없이 여러 기기를 하나의 사설 네트워크로 묶어줍니다.\n기존에는 외부에서 라즈베리파이에 SSH 접속하려면 포트포워딩이 필요했습니다. 포트포워딩은 공유기 설정이 필요하고, 외부에 포트가 노출되는 보안 위험이 있습니다.\nTailscale을 사용하면:\n공유기 포트포워딩 불필요 실제 IP 주소 노출 없음 어디서든 안전한 암호화 연결 무료 플랜으로 최대 100대 기기 연결 가능 설치 전 준비 # Tailscale 계정이 필요합니다. tailscale.com 에서 Google, GitHub 등으로 가입할 수 있습니다.\n라즈베리파이에 Tailscale 설치 # 공식 설치 스크립트를 사용합니다:\ncurl -fsSL https://tailscale.com/install.sh | sh Tailscale 네트워크 연결 # sudo tailscale up 실행하면 인증 링크가 출력됩니다:\nTo authenticate, visit: https://login.tailscale.com/a/xxxxxxxxxx 브라우저에서 해당 링크로 접속 → Tailscale 계정으로 로그인하면 라즈베리파이가 네트워크에 추가됩니다.\n연결 확인 # Tailscale IP 확인:\ntailscale ip 연결된 기기 목록 확인:\ntailscale status 출력 예시:\n100.x.x.x raspi linux - 100.x.x.x my-macmini macOS - 100.x.x.x my-macbook macOS - 외부에서 SSH 접속 # 이제 집 밖 어디서든 Tailscale IP로 SSH 접속이 가능합니다:\nssh raspi@라즈베리파이_Tailscale_IP 같은 Tailscale 네트워크에 연결된 기기라면 어디서든 접속됩니다. 회사, 카페, 해외 등 네트워크 환경에 관계없이 동일하게 동작합니다.\n기존 방식과 비교 # 항목 포트포워딩 Tailscale 설정 난이도 공유기 설정 필요 설치 스크립트 한 줄 보안 포트 외부 노출 암호화된 사설 네트워크 IP 변경 시 재설정 필요 자동 처리 비용 무료 무료 (100대까지) 마치며 # Tailscale 덕분에 이제 외부에서도 라즈베리파이를 안전하게 관리할 수 있습니다. 홈서버를 운영한다면 Tailscale은 사실상 필수 도구라고 생각합니다.\n다음 글에서는 UFW 방화벽과 fail2ban을 설정해 서버 보안을 강화하는 과정을 다루겠습니다.\n","date":"2026년 3월 23일","externalUrl":null,"permalink":"/posts/tailscale-setup/","section":"블로그","summary":"Tailscale을 설치해 포트포워딩 없이 외부 네트워크에서도 라즈베리파이에 SSH 접속하는 방법을 정리합니다.","title":"Tailscale로 어디서든 라즈베리파이에 안전하게 접속하기","type":"posts"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/vpn/","section":"Tags","summary":"","title":"Vpn","type":"tags"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/posts/","section":"블로그","summary":"","title":"블로그","type":"posts"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/categories/%EC%9D%B8%ED%94%84%EB%9D%BC/","section":"Categories","summary":"","title":"인프라","type":"categories"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/blog/","section":"Tags","summary":"","title":"Blog","type":"tags"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/blowfish/","section":"Tags","summary":"","title":"Blowfish","type":"tags"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/cron/","section":"Tags","summary":"","title":"Cron","type":"tags"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/deploy/","section":"Tags","summary":"","title":"Deploy","type":"tags"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/github/","section":"Tags","summary":"","title":"Github","type":"tags"},{"content":" 목표 # 블로그 글을 쓸 때마다 직접 rsync로 파일을 전송하는 건 번거롭습니다. 이 글에서는 아래 흐름으로 자동화하는 방법을 정리합니다.\ngit push → GitHub → 라즈베리파이 자동 감지 → 빌드 → 배포 구조 개요 # 맥미니: Hugo로 빌드, GitHub에 push GitHub: 소스코드 저장소 라즈베리파이: 5분마다 GitHub 확인, 변경사항 있으면 자동 빌드 \u0026amp; 배포 cron: 라즈베리파이에서 배포 스크립트를 주기적으로 실행하는 역할 1단계: GitHub 저장소 설정 # GitHub에 새 저장소를 만들고 맥미니에서 push합니다.\ncd codeberry git remote add origin https://github.com/Kyungjae-Sung/codeberry.git git branch -M main git add . git commit -m \u0026#34;Initial Hugo + Blowfish site setup\u0026#34; git push -u origin main 2단계: 라즈베리파이에 Hugo 설치 # 라즈베리파이에서 직접 빌드하기 위해 Hugo를 설치합니다.\nsudo apt update \u0026amp;\u0026amp; sudo apt install hugo -y hugo version # hugo v0.131.0+extended linux/arm64 3단계: GitHub 저장소 clone # 라즈베리파이에서 GitHub 저장소를 가져옵니다.\ngit clone https://github.com/Kyungjae-Sung/codeberry.git ~/codeberry cd ~/codeberry git submodule update --init --recursive git submodule update는 Blowfish 테마를 함께 가져오기 위해 필요합니다.\n4단계: 자동 배포 스크립트 작성 # ~/deploy.sh 파일을 생성합니다.\n#!/bin/bash SITE_DIR=\u0026#34;~/codeberry\u0026#34; WEB_DIR=\u0026#34;/var/www/html\u0026#34; LOG_FILE=\u0026#34;~/deploy.log\u0026#34; cd $SITE_DIR # GitHub에서 최신 코드 확인 git fetch origin main \u0026gt;\u0026gt; $LOG_FILE 2\u0026gt;\u0026amp;1 LOCAL=$(git rev-parse HEAD) REMOTE=$(git rev-parse origin/main) if [ $LOCAL != $REMOTE ]; then echo \u0026#34;$(date \u0026#39;+%Y-%m-%d %H:%M:%S\u0026#39;) 새 코드 감지 - 배포 시작\u0026#34; \u0026gt;\u0026gt; $LOG_FILE git pull origin main \u0026gt;\u0026gt; $LOG_FILE 2\u0026gt;\u0026amp;1 git submodule update --recursive \u0026gt;\u0026gt; $LOG_FILE 2\u0026gt;\u0026amp;1 hugo --gc --cleanDestinationDir -d $WEB_DIR \u0026gt;\u0026gt; $LOG_FILE 2\u0026gt;\u0026amp;1 echo \u0026#34;$(date \u0026#39;+%Y-%m-%d %H:%M:%S\u0026#39;) 배포 완료\u0026#34; \u0026gt;\u0026gt; $LOG_FILE else echo \u0026#34;$(date \u0026#39;+%Y-%m-%d %H:%M:%S\u0026#39;) 변경 없음\u0026#34; \u0026gt;\u0026gt; $LOG_FILE fi 스크립트 동작 방식:\ngit fetch로 GitHub의 최신 커밋 정보를 가져옴 로컬 커밋과 GitHub 커밋을 비교 다르면 → pull → 빌드 → /var/www/html/ 에 배포 같으면 → \u0026ldquo;변경 없음\u0026rdquo; 기록 후 종료 실행 권한 부여:\nchmod +x ~/deploy.sh 5단계: cron으로 자동 실행 등록 # cron은 리눅스에서 특정 시간마다 명령어를 자동 실행하는 기능입니다.\ncrontab -e 아래 줄을 추가합니다:\n*/5 * * * * ~/deploy.sh */5 * * * *의 의미: 매 5분마다 실행\n6단계: 동작 확인 # 스크립트를 직접 실행해서 테스트합니다.\nbash ~/deploy.sh cat ~/deploy.log 출력 예시:\n2026-03-23 15:06:32 변경 없음 이제 맥미니에서 git push를 하면 최대 5분 이내에 codeberry.work에 자동 반영됩니다.\n앞으로의 블로그 작성 흐름 # # 1. 새 글 폴더 생성 mkdir -p content/posts/새글제목 # 2. index.md 작성 # 3. 로컬 미리보기 hugo server -D --bind 0.0.0.0 # 4. GitHub에 push git add . git commit -m \u0026#34;새 글: 제목\u0026#34; git push # → 5분 이내 codeberry.work 자동 반영! 배포 로그 확인 # 배포가 잘 되고 있는지 언제든 로그로 확인할 수 있습니다.\n# 라즈베리파이에서 tail -20 ~/deploy.log 마치며 # cron + shell script 조합은 단순하지만 강력합니다. 별도의 CI/CD 서비스 없이도 push 한 번으로 자동 배포가 가능합니다. GitHub Actions 같은 서비스를 쓰면 더 정교하게 제어할 수 있지만, 홈서버 규모에서는 이 방식으로도 충분합니다.\n","date":"2026년 3월 23일","externalUrl":null,"permalink":"/posts/github-auto-deploy/","section":"블로그","summary":"git push만 하면 라즈베리파이가 자동으로 코드를 가져와 Hugo 빌드 후 배포하는 파이프라인을 구축합니다.","title":"GitHub push 한 번으로 라즈베리파이 자동 배포하기","type":"posts"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/hugo/","section":"Tags","summary":"","title":"Hugo","type":"tags"},{"content":" 왜 Hugo인가? # 개인 블로그를 직접 만들면서 여러 선택지를 고민했습니다.\nWordPress: 설치가 쉽지만 DB 관리가 필요하고 서버 부하가 큼 Jekyll: Ruby 기반이라 의존성 관리가 번거로움 Hugo: Go 기반으로 빌드 속도가 매우 빠르고, 서버에서는 HTML 파일만 서빙하면 됨 라즈베리파이처럼 성능이 제한된 서버에서는 정적 사이트가 최적입니다. Hugo는 빌드를 맥미니에서 하고, 결과물(HTML)만 라즈베리파이에 올리면 되기 때문에 서버 부하가 거의 없습니다.\nHugo 설치 # 맥미니에서 Homebrew로 설치합니다.\nbrew install hugo 설치 확인:\nhugo version # hugo v0.158.0+extended+withdeploy darwin/arm64 extended가 포함되어야 합니다. Blowfish 테마가 extended 버전을 요구합니다.\n사이트 생성 # hugo new site codeberry cd codeberry git init Blowfish 테마 설치 # Blowfish는 깔끔한 디자인과 다양한 기능을 제공하는 Hugo 테마입니다. Git submodule 방식으로 설치하면 나중에 테마 업데이트도 쉽게 할 수 있습니다.\ngit submodule add -b main https://github.com/nunocoracao/blowfish.git themes/blowfish 설정 파일 구성 # Blowfish는 설정 파일이 여러 개로 나뉩니다. config/_default/ 폴더 아래에 목적별로 파일을 분리합니다.\nconfig/_default/ ├── hugo.toml # 사이트 기본 설정 ├── languages.ko.toml # 언어 설정 ├── menus.ko.toml # 네비게이션 메뉴 ├── params.toml # 테마 상세 설정 └── markup.toml # 마크다운 렌더링 설정 hugo.toml # baseURL = \u0026#34;https://codeberry.work/\u0026#34; languageCode = \u0026#34;ko\u0026#34; title = \u0026#34;CodeBerry\u0026#34; theme = \u0026#34;blowfish\u0026#34; params.toml (주요 설정) # colorScheme = \u0026#34;blowfish\u0026#34; defaultAppearance = \u0026#34;dark\u0026#34; autoSwitchAppearance = true enableSearch = true enableCodeCopy = true [homepage] layout = \u0026#34;profile\u0026#34; homepageImage = \u0026#34;img/profile.jpg\u0026#34; showRecent = true [author] name = \u0026#34;성경재\u0026#34; headline = \u0026#34;IT 관제\u0026#34; bio = \u0026#34;홈랩, 셀프호스팅, AI/ML, 데이터 분석에 관심이 많습니다.\u0026#34; links = [ { github = \u0026#34;https://github.com/Kyungjae-Sung\u0026#34; }, ] 콘텐츠 구조 # content/ ├── posts/ # 블로그 글 ├── projects/ # 포트폴리오 └── about/ # 소개 페이지 로컬 미리보기 # hugo server -D --bind 0.0.0.0 브라우저에서 http://맥미니IP:1313 으로 접속하면 실시간으로 미리볼 수 있습니다. 파일을 수정하면 자동으로 브라우저가 갱신됩니다.\n빌드 \u0026amp; 배포 # 미리보기에서 문제없으면 빌드:\nhugo --gc --cleanDestinationDir public/ 폴더에 완성된 HTML 파일이 생성됩니다. 라즈베리파이로 전송:\nrsync -avz --delete public/ raspi@라즈베리파이IP:/var/www/html/ 마치며 # Hugo + Blowfish 조합은 빠른 빌드 속도와 깔끔한 디자인 덕분에 개인 블로그에 최적입니다. 특히 라즈베리파이처럼 저사양 서버에서는 정적 사이트가 WordPress 대비 훨씬 가볍게 동작합니다.\n다음 글에서는 GitHub push만으로 자동 배포되는 파이프라인 구축 과정을 다루겠습니다.\n","date":"2026년 3월 23일","externalUrl":null,"permalink":"/posts/hugo-blowfish-site-setup/","section":"블로그","summary":"정적 사이트 생성기 Hugo와 Blowfish 테마를 사용해 개인 블로그를 제작한 과정을 기록합니다.","title":"Hugo + Blowfish로 개인 블로그 만들기","type":"posts"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/nginx/","section":"Tags","summary":"","title":"Nginx","type":"tags"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/self-hosting/","section":"Tags","summary":"","title":"Self-Hosting","type":"tags"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/categories/%EA%B0%9C%EB%B0%9C%ED%99%98%EA%B2%BD/","section":"Categories","summary":"","title":"개발환경","type":"categories"},{"content":" 왜 라즈베리파이 홈서버인가? # 개인 블로그를 직접 호스팅해보고 싶었습니다. 클라우드 서비스 대신 집에 있는 작은 컴퓨터로 서버를 돌리면 서버 운영의 전체 과정을 배울 수 있으니까요.\n사용한 장비 # 서버: Raspberry Pi 5 (4GB) OS: Raspberry Pi OS Lite (64-bit) 웹서버: Nginx 사이트 생성: Hugo + Blowfish 테마 외부 공개: Cloudflare Tunnel 원격 관리: Tailscale 구축 과정 # 1. OS 설치 # Raspberry Pi Imager를 사용해서 SD 카드에 OS를 설치했습니다.\n2. Nginx 설치 # sudo apt update \u0026amp;\u0026amp; sudo apt install nginx -y 3. 도메인 \u0026amp; Cloudflare Tunnel 설정 # Cloudflare Tunnel을 사용하면 포트포워딩 없이 안전하게 외부에 공개할 수 있습니다.\n다음 편 예고 # 다음 글에서는 Hugo 사이트를 제작하고 배포하는 과정을 다루겠습니다.\n","date":"2026년 3월 23일","externalUrl":null,"permalink":"/posts/rpi-homeserver-setup/","section":"블로그","summary":"라즈베리파이 5로 개인 웹서버를 구축하는 과정을 기록합니다.","title":"라즈베리파이 홈서버 구축기 1편 - 시작","type":"posts"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/tags/cloudflare/","section":"Tags","summary":"","title":"Cloudflare","type":"tags"},{"content":"$ cat project-info.txt 카테고리: 인프라 / 홈랩\n상태: 운영 중\n$ cat stack.txt 구성 요소 기술 하드웨어 Raspberry Pi 5 (4GB) OS Raspberry Pi OS Lite 64-bit 웹서버 Nginx 사이트 생성 Hugo v0.158.0 + Blowfish 테마 외부 공개 Cloudflare Tunnel 원격 관리 Tailscale 배포 자동화 GitHub → cron 5분 주기 자동 배포 $ cat description.txt 클라우드 없이 집에 있는 라즈베리파이 5로 이 블로그를 직접 호스팅합니다. 포트포워딩 없이 Cloudflare Tunnel로 외부에 안전하게 공개하고, Tailscale로 어디서든 SSH 관리가 가능한 구조입니다.\nGitHub에 push하면 5분 이내에 라즈베리파이가 자동으로 감지하고 빌드·배포합니다.\n","date":"2026년 3월 23일","externalUrl":null,"permalink":"/projects/homeserver/","section":"프로젝트","summary":"RPi5 위에서 Hugo + Nginx + Cloudflare Tunnel로 이 블로그를 직접 운영합니다.","title":"라즈베리파이 홈서버","type":"projects"},{"content":"","date":"2026년 3월 23일","externalUrl":null,"permalink":"/projects/","section":"프로젝트","summary":"","title":"프로젝트","type":"projects"},{"content":"","externalUrl":null,"permalink":"/ai-papers/","section":"AI 논문","summary":"","title":"AI 논문","type":"ai-papers"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]