Skip to content
Published on

韓国の開発ブログ名文キュレーション 3 — AIとML実務、直接開いて確認した14本

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

このリストが何で構成されているかを先に明かします

選定方法はシリーズ全体と同じです。検索で候補を見つけたあと、記事を直接開いて確認し、そのなかから説明が具体的で再現可能なものを選びました。このリストは編集者の選択であり、ランキングではありません。 閲覧数や人気は測定していませんし、測定する手段もありません。

正直に明かしておくことがあります。このテーマで確認可能な韓国語の記事を集めてみると、重心がモデルを学習させる側よりも既存のモデルをつないで運用する側に明らかに寄っていました。ですからこのリストもそのように構成されています。論文レビューとモデルの基礎を扱った記事も2本入れましたが、全体としてはRAGとサービングと運用が主になります。これは私の選択でもあり、いまの韓国語の開発記事の分布でもあります。

出典は個人ブログを優先し、個人ドメインとGitHub Pagesのブログが半分近くを占めます。この分野は個人が実験した記録のほうが会社の発表より役に立つことが多く、結果としてそうなりました。

韓国国外の読者に一点。リンク先は韓国語です。 読むには韓国語が必要ですが、コードやベンチマークの表やアーキテクチャ図はそのまま読み取れます。

リンクは2026-08-12に直接開いて確認しました。個人ブログの記事は消えたりURLが変わったりすることがあります。

検索とRAG — モデルより先に崩れるところ

RAGが期待どおりにならない理由は、たいていモデルではなく検索にあります。この節の記事はその検索側を見ます。

LangChain RAG 파헤치기: 문서 기반 QA 시스템 설계 방법 - 심화편

  • ブログ · 著者: 테디노트 (Teddy Lee)
  • 一行要約: 文書の読み込みから分割、埋め込み、ベクトル保存、検索、プロンプト、モデル選択までRAGパイプラインの七段階を実際のPDFで通します。
  • こんな人に: RAGをチュートリアルの水準で一度作ってみたが、各段階で何を調整すべきか分からない人。

この記事の強みは完結性です。パイプラインを細切れにせず最初から最後まで一つの文書で通すので、どの段階の選択がどの段階に影響するかが見えます。分割戦略や検索器の設定のように結果が大きく分かれる箇所に実験が付いているのも良いところです。韓国語でこれだけの範囲を一本に収めた記事は多くないので、チーム内の教育資料としてリンクを貼っておくのに向いています。応用編なので基本概念は分かった状態で読むほうがよいでしょう。

의미 검색(Semantic Search)은 어떻게 동작할까: 임베딩과 벡터 유사도

  • ブログ · 著者: Engineering Blog by Dale Seo
  • 一行要約: テキストがベクトルになりコサイン類似度で比較される過程を、文字がひとつも重ならない韓国語の例で説明します。
  • こんな人に: 意味検索を導入しようという話が出たが、それが正確に何なのかを説明しなければならない人。

ある語での問い合わせが、同じ意味をまったく別の表現で書いた文書を見つける例がこの記事の中心にあります。文字の重なりがまったくないのに見つかるという事実ひとつで、キーワード検索との違いが即座に理解できます。PythonとJavaScriptの例が両方あるので、どちらのスタックでもすぐ追えます。概念を短く正確に説明する記事が必要なとき、これに並ぶものはなかなかありません。

[Vector DB] 2. Vector DB 의 종류

  • ブログ · 著者: Jongya's blog
  • 一行要約: 広く使われるベクトルデータベース7種をライセンス、特徴、長短所で比較し、選択基準を整理します。
  • こんな人に: ベクトルストアを選ばなければならないのに候補が多すぎて、まず比較表が欲しい人。

この種の比較記事はすぐ古びるものですが、この記事は機能の一覧より選択基準を前に置いているので寿命が少し長くなっています。データ規模、デプロイ方式、既存システムとの統合という三つの軸で整理するため、自分の状況を当てはめやすくなっています。ライセンスを比較項目に入れているのも実務の観点から誠実です。シリーズの二本目なので、前編で概念を掴んでから読むとより頭に入ります。

Vector DB 마이그레이션: 왜 pgvector 대신 Qdrant를 선택했나

  • ブログ · 著者: k_bell.log · k_bell (velog)
  • 一行要約: 運用中のRAGサービスをpgvectorからQdrantへ移した過程と、その判断の根拠を数値とともに残します。
  • こんな人に: 既存のリレーショナルデータベースにベクトル拡張を載せて使っていて、それで十分か気になる人。

前の比較記事が地図なら、この記事は実際に歩いてみた記録です。リレーショナルデータベースにベクトル検索を載せたときに生じるリソース競合とフィルタリング性能の問題を自分のサービスの症状として説明し、移したあとの応答時間の変化を数字で提示します。移行記事の価値は結論ではなく、どんな条件でその結論が出たかにありますが、この記事はその条件を明らかにしています。自分のサービスがその条件に当てはまらないなら従う必要はない、ということも一緒に判断できます。

サービングと運用 — つないでから始まる問題

プロトタイプが動くこととサービスが回ることのあいだには、スループットとコストという二つの壁があります。

Ollama에서 vLLM으로: 프로덕션 LLM 서빙 4.8배 빠르게 만들기

  • ブログ · 著者: Kingjun.log · kukjunLEE (velog)
  • 一行要約: ローカル実験用のサービングツールから運用向けの推論エンジンへ移す際に何が変わるかを、ベンチマークとともに記録します。
  • こんな人に: 個人実験用に立てたモデルをそのままサービスにつないで、スループットで詰まった人。

この記事が良いのは、移した理由を構造で説明しているからです。連続バッチングとテンソル並列がないことがどんな負荷でどんな結果として現れるかを押さえ、だからエンジンを替えたという順で続きます。量子化モデルの検証と、複数のモデルを一つのゲートウェイの後ろに置く構成まであって範囲が広くなっています。タイトルの数字は著者の環境で測られた値なので、そのまま期待するより測定方法を参考にするのが妥当です。その測定方法が書かれていることこそがこの記事の価値です。

MLOps - #8 LLM 서빙 지표

  • ブログ · 著者: jaewonnow_ (velog)
  • 一行要約: 最初のトークンまでの時間、トークンあたりの時間、スループット、GPU使用率、トークンあたりのコストを、噛み合ったトレードオフとして整理します。
  • こんな人に: LLMサービスの性能目標を決めなければならないが、何を目標にすべきか分からない人。

指標を並べる記事は多いのですが、指標同士の関係を扱う記事は多くありません。この記事は一つを良くすればもう一つが悪くなる構造を前提に置き、サービスの性格に応じて何を優先するか選べと言います。対話型のインターフェースとバッチ処理が別の指標を見るべきだという結論は当然に見えますが、実際にはこの区別なしに最適化して無駄を出すことが少なくありません。目標設定の会議の前に一度読んでおくと議論が短くなります。

LLM Usage Tracker: Claude Code와 Codex 사용량 기록하기

  • ブログ · 著者: Outsider's Dev Story
  • 一行要約: 複数のAIコーディングツールのトークン使用量を一か所に集めて見るツールを自作した記録です。
  • こんな人に: チームでAIツールの費用が増えているのに、どこにいくら使われているか説明できない人。

問題の定義が明確です。ツールごとに使用量が散らばっていて全体が見えないということで、解決策はコレクタをローカルに置き、リモートへ送ってダッシュボードで見ることです。構成が単純なのでそのまま真似して作りやすく、何を指標にしたかがそれ自体で参考になります。ツールを作る過程に、そのツールが追跡しようとしているAIエージェントを使った点も、この時期の記録として興味深いところです。コスト管理を始めなければならないチームに、最小限の出発点を与えてくれます。

モデルの基礎 — つないで使う前に一度は見ておくもの

応用ばかり繰り返していると、どこかで判断が止まります。そのとき必要になるのがこの節の2本です。

[논문 리뷰 & 코드 구현] Transformer (Attention is All You Need)

  • ブログ · 著者: tony3ynot.log · 박주용 (velog)
  • 一行要約: Transformerの論文をレビューするだけで終わらず、PyTorchの実装まで付けています。
  • こんな人に: アテンションを図では理解しているが、コードとして書いたことのない人。

論文レビューは多く実装も多いのですが、二つが一本の記事に入っている例は多くありません。構造の説明のあとに埋め込みと位置エンコーディングとマルチヘッドアテンションとマスキングをそれぞれコードで見せるので、概念と実装のあいだの隔たりが狭くなります。マスキングのように文章で読むと混乱する部分がコードでは明確になるのも、この構成の利点です。基礎を組み直したいときに一本で片づく種類の記事です。

[자연어 처리] 4. BERT

  • ブログ · 著者: Hyungcheol Noh's Blog
  • 一行要約: BERTをその前の系譜につなげて説明し、事前学習の課題とファインチューニングの方式とベンチマーク結果まで整理します。
  • こんな人に: いまの大規模モデルがどこから来たのか、系譜を掴みたい人。

BERTを単独で説明せず、それ以前のモデルとの関係のなかに置くのがこの記事のやり方です。だから双方向のエンコーディングがなぜ当時意味のある前進だったのかが腑に落ちます。シリーズの四本目なので前の記事と続けて読め、数式と性能表があるので浅く通り過ぎません。2026年の時点でBERTは最新ではありませんが、事前学習とファインチューニングという今も有効な枠組みはここで整理されます。

導入現場の記録 — 組織が実際に経験したこと

もっとも最近書かれた記事がこの節に集まっています。ツールの入れ替わりが速い分、記録の有効期限も短いので、日付を一緒に見てください。

인프랩 AI 네이티브 9개월 정리

  • ブログ · 著者: 기억보단 기록을 · 향로
  • 一行要約: ある会社が9か月のあいだAIツールを導入して確認できたことと、まだ確認できていないことを21項目にまとめます。
  • こんな人に: AI導入の効果を経営陣に説明する立場にある人。

この記事の美点は効果を誇張しないところにあります。効率が上がったことは確認できたが事業成果につながったとはまだ証明されていない、と明記し、その区別を保ったまま残りを語ります。自動化の前にまず手順が必要だという指摘、文書とテストとバージョン管理と権限管理が依然として基盤だという結論は、ツールが変わっても残る内容です。成果測定と知的財産とツールとインフラとセキュリティに分かれた構成なので、必要な節だけ拾い読みしても構いません。導入を検討する組織が参考にできる実例として価値が大きいものです。

LLM은 데이터베이스가 아니다

  • ブログ · 著者: 기억보단 기록을 · 향로
  • 一行要約: 問い合わせを受けて結果を返すという表面的な類似から生まれる誤解を、レコメンドの事例で整理します。
  • こんな人に: 既存システムをLLMで置き換えようという提案を受けた、あるいはしようとしている人。

これは技術の解説というより判断基準を提示する記事です。保存されたものを正確に取り出す仕事と、学習したパターンからもっともらしいものを作り出す仕事は別の仕事で、この区別を落とすとアーキテクチャがずれます。レコメンドをLLMで丸ごと置き換えるのではなく、候補を先に絞って渡せという結論は、実務ですぐ使える設計指針です。短く論旨が明確なので、チームの議論に引用しやすい記事でもあります。

AI는 접바둑 도구

  • ブログ · 著者: 기억보단 기록을 · 향로
  • 一行要約: AIを代わりに打ってくれる人ではなく、難易度を自分で調節して打ち続けられるようにする道具として見る視点を提示します。
  • こんな人に: チームのメンバーにAIツールをどう使えと案内すべきか悩んでいる人。

的確な比喩はそれ自体が道具になります。置き碁という比喩は、AIが実力を代替するのではなく打ち続けられるように盤を合わせてくれる、という意味を一度に伝えます。ジュニアが自分に合ったやり方で助言者を作って使った事例が付いているので、抽象的に終わりません。良いメンターに出会う運に依存していた学習が自分で調節できるものになった、という視点は議論の余地がありますが、考えてみる価値があります。

[MCP] MCP 서버의 인증 과정에 대한 이해(MCP Authorization flow)

  • ブログ · 著者: MangKyu's Diary (망나니개발자)
  • 一行要約: MCPサーバーに認可が必要な場合と、その全体の流れを六段階に分けて説明します。
  • こんな人に: 社内データにアクセスするMCPサーバーを作らなければならない人。

MCP関連の記事はたいていツールをつなぐ方法で終わりますが、この記事は権限の側を扱います。いつ認可が必要かをまず区別し、そのうえで保護されたリソースのメタデータ探索からトークン要求までの流れを順に押さえます。クライアント登録方式の選択肢とPKCEの適用まで含まれていて、実装前の設計段階で役に立ちます。ユーザーごとのデータを扱うサーバーなら、この部分を飛ばすことはできません。

[AI] AI Harness(하네스) 구축을 위한 shim 아키텍처 with Busy Box pattern and PATH 하이재킹

  • ブログ · 著者: MangKyu's Diary (망나니개발자)
  • 一行要約: チーム全体のAIツール設定を、開発者の作業フローに触れずに注入する構造を提案します。
  • こんな人に: チームでAIツールの規約を決めたのに誰も従わなくて困っている人。

問題が現実的です。設定を文書で告知しても守られず、強制すれば作業フローが壊れます。この記事は実行ファイルの前に薄い層を置いて設定を差し込む方式でそのあいだを通り抜けますが、古くからあるUnixの慣行を二つ組み合わせているのが面白いところです。新しい技術ではなく馴染みのある技法で新しい問題を解く事例なので、アイデア自体が別の場所にも移せます。ただし透明な介入はデバッグを難しくしうるという点は、導入前に考えておくべきところです。

このブログの関連記事とツール

シリーズの他の記事

Discuss on Twitter • View on GitHub