<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Blog on 기술 블로그</title>
    <link>https://goodhee.xyz/blog/</link>
    <description>Recent content in Blog on 기술 블로그</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 01 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://goodhee.xyz/blog/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AI 에이전트 벤치마크를 뜯어보기</title>
      <link>https://goodhee.xyz/blog/ai-benchmarks/</link>
      <pubDate>Wed, 01 Jul 2026 00:00:00 +0000</pubDate>
      
      <guid>https://goodhee.xyz/blog/ai-benchmarks/</guid>
      
      <description>&lt;p&gt;새 모델이 나올 때마다 발표 자료에 벤치마크 점수가 딸려 온다. SWE-Bench, Terminal-Bench, OSWorld, Humanity&amp;rsquo;s Last Exam, GDPval&amp;hellip; 대개는 &amp;ldquo;코딩 잘함&amp;rdquo;, &amp;ldquo;컴퓨터 잘 씀&amp;rdquo;, &amp;ldquo;추론 잘함&amp;rdquo; 정도로 읽고 넘기게 된다.&lt;/p&gt;
&lt;p&gt;그런데 이 점수가 실제로 어떻게 계산되는지는 의외로 잘 안 들여다보게 된다. SWE-Bench 70%가 GitHub 이슈에 정답 코드를 맞힌 비율인지, GUI 평가라면 실제로 마우스를 움직이는지, 터미널은 진짜로 쓰는지 — 확인해보기 전엔 그냥 넘어갔던 것들이다.&lt;/p&gt;
&lt;p&gt;다섯 개를 논문이랑 실제 harness 코드까지 확인해보니, 문제만 다른 게 아니라 평가 방식 자체가 딴판이었다. 어떤 건 Docker에서 저장소를 통째로 돌리고, 어떤 건 가상머신을 부팅해서 데스크톱을 조작하고, 어떤 건 사람이 붙어서 결과물을 채점한다. 같은 &amp;ldquo;벤치마크&amp;quot;인데 안을 열어보면 거의 다른 물건이다. 근거가 되는 논문·저장소는 각 벤치마크 이름에 링크로 걸어뒀다.&lt;/p&gt;</description>
      
    </item>
    
    <item>
      <title>Argo CD ApplicationSet을 App-of-Apps로 안전하게 전환하기</title>
      <link>https://goodhee.xyz/blog/argocd-applicationset-to-app-of-apps/</link>
      <pubDate>Wed, 08 Apr 2026 00:00:00 +0000</pubDate>
      
      <guid>https://goodhee.xyz/blog/argocd-applicationset-to-app-of-apps/</guid>
      
      <description>&lt;p&gt;list generator 기반 Argo CD ApplicationSet을 파일 단위 Application(App-of-Apps)으로 안전하게 전환하는 일반 절차.&lt;/p&gt;
&lt;h2 id=&#34;언제&#34;&gt;언제?&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;ApplicationSet 템플릿으로 생성되던 자식 Application들을 개별 git 파일로 관리하고 싶을 때&lt;/li&gt;
&lt;li&gt;StatefulSet/PVC 등 데이터 보존이 필요한 워크로드를 무중단으로 옮겨야 할 때&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;원칙&#34;&gt;원칙&lt;/h2&gt;
&lt;blockquote&gt;
&lt;p&gt;[!CAUTION]
StatefulSet/PVC를 쓰는 차트는 잘못 전환하면 cascade prune으로 볼륨까지 삭제될 수 있다. 아래 3가지를 반드시 지킬 것.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;spec 일치&lt;/strong&gt;: 새 Application의 name, namespace, source.path, helm.releaseName, destination, valueFiles가 기존 ApplicationSet 렌더 결과와 동일해야 Argo CD가 기존 helm release를 adopt (diff 0)&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;orphan 선행&lt;/strong&gt;: ApplicationSet이 element 삭제 시 자식 Application을 cascade 삭제하지 못하도록 ownerReferences를 먼저 제거&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;원자적 커밋&lt;/strong&gt;: ApplicationSet elements 제거 + 새 Application yaml 추가를 같은 커밋으로 push (분리하면 reconcile 레이스 발생)&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id=&#34;템플릿&#34;&gt;템플릿&lt;/h2&gt;
&lt;p&gt;원본 ApplicationSet &lt;code&gt;template.spec&lt;/code&gt;을 그대로 복사해서 &lt;code&gt;kind: ApplicationSet&lt;/code&gt; → &lt;code&gt;kind: Application&lt;/code&gt;으로 바꾸고 제너레이터 변수(&lt;code&gt;{{.app}}&lt;/code&gt;, &lt;code&gt;{{.namespace}}&lt;/code&gt; 등)를 실제 값으로 치환한다.&lt;/p&gt;</description>
      
    </item>
    
  </channel>
</rss>
