Skip to content
←

필사 모드: Korean Dev Blog Curation 3 — AI and ML in Practice, 14 Posts I Opened and Checked

English
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

What This List Is Made Of, Stated Up Front

The selection method is the same across the series. I found candidates by searching and then opened each post directly to check it, keeping the ones whose explanations were concrete and reproducible. This list is an editorial pick, not a ranking. I did not measure views or popularity and have no way to.

There is one thing worth stating honestly. When I gathered verifiable Korean-language writing on this topic, the center of gravity sat clearly on attaching and operating existing models rather than on training them. So this list is composed the same way. Two entries cover paper reviews and model fundamentals, but the bulk is RAG, serving, and operations. That is partly my choice and partly the actual distribution of Korean developer writing right now.

I gave priority to personal blogs, and personal domains plus GitHub Pages make up close to half the list. In this field an individual's experiment log is often more useful than a company announcement, which is how it turned out that way.

A note for readers outside Korea: every linked post is written in Korean. You will need Korean to read them, though the code, benchmark tables, and architecture diagrams carry over regardless.

All links were opened and checked directly on 2026-08-12. Personal blog posts can disappear or change addresses.

Search and RAG — Where It Breaks Before the Model Does

When RAG underdelivers, the cause is usually retrieval rather than the model. The posts in this section look at the retrieval side.

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

  • Blog · Author: 테디노트 (Teddy Lee)
  • One-line summary: Seven stages of a RAG pipeline — loading, splitting, embedding, storing, retrieving, prompting, model choice — carried through on a real PDF.
  • Read this if: You have built RAG once at tutorial level but do not know what to tune at each stage.

The strength here is completeness. The pipeline is carried end to end in a single document rather than chopped up, so you can see how a choice at one stage affects another. Experiments are attached at the points where results diverge most, like splitting strategy and retriever configuration. Not many Korean-language posts pack this range into one piece, which makes it a good link to pin as internal training material. It is the advanced installment, so read it with the basics already in hand.

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

  • Blog · Author: Engineering Blog by Dale Seo
  • One-line summary: How text becomes a vector and gets compared by cosine similarity, demonstrated with a Korean example that shares no characters at all.
  • Read this if: Someone proposed adopting semantic search and you have to explain what it actually is.

The example at the center is a query for one word retrieving a document that uses an entirely different phrase for the same idea. That single fact — no character overlap, still found — makes the difference from keyword search immediately legible. Python and JavaScript examples are both present, so you can follow along on either stack. When you need a short and accurate explanation of the concept, this is hard to beat.

[Vector DB] 2. Vector DB 의 종류

  • Blog · Author: Jongya's blog
  • One-line summary: Seven widely used vector databases compared on licensing, characteristics, and trade-offs, with selection criteria.
  • Read this if: You have to pick a vector store and there are too many candidates to start without a table.

Comparison posts date quickly, but this one puts selection criteria ahead of the feature list, which extends its life a little. Organizing around data scale, deployment mode, and integration with existing systems makes it easy to substitute your own situation. Including licensing as a comparison axis is honest from an operational standpoint. It is the second post in a series, so picking up the concepts from the first entry helps.

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

  • Blog · Author: k_bell.log · k_bell (velog)
  • One-line summary: Moving a running RAG service off pgvector to Qdrant, with the reasoning and the numbers.
  • Read this if: You are running a vector extension on your existing relational database and wondering whether that is enough.

If the previous post is a map, this is a record of actually walking the route. It describes the resource contention and filtering performance problems that arise when vector search sits on a relational database, framed as symptoms in the author's own service, then presents the change in response times as numbers. The value of a migration writeup lies not in the conclusion but in the conditions that produced it, and this post states those conditions. That also lets you judge that if your service does not match them, you need not follow along.

Serving and Operations — The Problems That Start After You Ship

Between a working prototype and a working service sit two walls: throughput and cost.

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

  • Blog · Author: Kingjun.log · kukjunLEE (velog)
  • One-line summary: What changes when you move from a local experimentation tool to a production inference engine, recorded with benchmarks.
  • Read this if: You attached a locally spun-up model straight to a service and then hit a throughput ceiling.

This is good because it explains the move structurally. It identifies what the absence of continuous batching and tensor parallelism produces under which loads, and the engine change follows from that. Validating quantized models and putting several models behind one gateway round out a wide scope. The number in the title was measured in the author's environment, so treat the measurement method as the takeaway rather than expecting the same figure. That the method is written down at all is the post's real value.

MLOps - #8 LLM 서빙 지표

  • Blog · Author: jaewonnow_ (velog)
  • One-line summary: Time to first token, time per output token, throughput, GPU utilization, and cost per token, organized as interlocking trade-offs.
  • Read this if: You need to set performance targets for an LLM service and do not know what to target.

Plenty of posts list metrics; few handle the relationships between them. This one takes as its premise that improving one degrades another, and tells you to choose priorities based on the character of the service. The conclusion that conversational interfaces and batch processing should watch different metrics looks obvious, yet optimizing without that distinction wastes effort routinely. Reading it before a goal-setting meeting will shorten the meeting.

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

  • Blog · Author: Outsider's Dev Story
  • One-line summary: Building a tool that consolidates token usage across several AI coding agents into one view.
  • Read this if: AI tool spend is rising on your team and you cannot explain where it goes.

The problem definition is clear: usage is scattered per tool so nobody can see the total, and the fix is a local collector shipping to a remote dashboard. The architecture is simple enough to copy directly, and which numbers the author chose to track is itself a reference. There is something fitting about the fact that the tool was built using the very agents it tracks, which makes it a good record of this moment. For a team that has to start managing cost, it supplies a minimum viable starting point.

Model Fundamentals — What to Look at Once Before Wiring Things Up

Repeat applications long enough and judgment eventually stalls. That is when the two posts in this section matter.

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

  • Blog · Author: tony3ynot.log · 박주용 (velog)
  • One-line summary: A Transformer paper review that does not stop at review — a PyTorch implementation is attached.
  • Read this if: You understand attention as a diagram but have never written it as code.

Paper reviews are plentiful and implementations are plentiful; having both in one post is rare. After the architecture walkthrough, embeddings, positional encoding, multi-head attention, and masking each appear as code, so the gap between concept and implementation narrows. Parts like masking, which read confusingly in prose, become unambiguous in code — another advantage of this structure. It is the kind of post that resolves a foundations refresh in a single sitting.

[자연어 처리] 4. BERT

  • Blog · Author: Hyungcheol Noh's Blog
  • One-line summary: BERT explained in continuity with the models before it, through its pretraining objectives, fine-tuning approach, and benchmark results.
  • Read this if: You want to establish the lineage of where today's large models came from.

Rather than explaining BERT in isolation, this post places it in relation to its predecessors. That is what makes it clear why bidirectional encoding was a meaningful step at the time. It is the fourth in a series so it reads alongside the earlier entries, and the presence of equations and performance tables keeps it from skimming the surface. BERT is not current in 2026, but the pretrain-then-fine-tune frame that still governs practice is laid out here.

Reports from the Field — What Organizations Actually Went Through

The most recently written pieces are gathered in this section. Tooling moves fast, so the shelf life of these records is short; read the dates alongside them.

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

  • Blog · Author: 기억보단 기록을 · 향로
  • One-line summary: Twenty-one items covering what one company confirmed and what it has not yet confirmed across nine months of AI tool adoption.
  • Read this if: You are in a position where you have to explain AI adoption results to executives.

The virtue of this post is that it does not overstate the effect. It says outright that efficiency gains were confirmed but that translation into business results is not yet proven, and it maintains that distinction throughout the rest. The observation that a process has to exist before you automate it, and the conclusion that documentation, testing, version control, and permission management remain the foundation, will outlast whichever tools are current. It is split into performance measurement, intellectual property, tooling, infrastructure, and security, so you can read only the section you need. As a real case study for an organization evaluating adoption, its value is high.

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

  • Blog · Author: 기억보단 기록을 · 향로
  • One-line summary: The misconception created by the surface similarity of taking a query and returning a result, worked through with a recommender system example.
  • Read this if: You have received — or are about to make — a proposal to replace an existing system with an LLM.

This reads less as a technical explainer and more as a decision criterion. Retrieving something stored exactly and generating something plausible from learned patterns are different jobs, and missing that distinction misaligns the architecture. The conclusion — narrow the candidate set first and hand that to the model, rather than replacing the recommender wholesale — is a design guideline you can apply immediately. It is short with a clear thesis, which makes it easy to cite in a team discussion.

AI는 접바둑 도구

  • Blog · Author: 기억보단 기록을 · 향로
  • One-line summary: A framing of AI not as a substitute player but as a tool that lets you set your own difficulty and keep playing.
  • Read this if: You are working out how to guide teammates on using AI tools.

A precise analogy becomes a tool in its own right. The handicap-go framing conveys in one move that AI does not replace skill but adjusts the board so you can keep playing. A case of a junior building a customized advisor for themselves is attached, so it does not stay abstract. The view that learning, once dependent on the luck of meeting a good mentor, has become self-adjustable is arguable — and worth arguing about.

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

  • Blog · Author: MangKyu's Diary (망나니개발자)
  • One-line summary: When an MCP server needs authorization and what the full flow looks like, broken into six steps.
  • Read this if: You have to build an MCP server that reaches internal data.

Most MCP posts stop at how to attach a tool; this one handles the permission side. It first distinguishes when authorization is required, then walks the flow in order from protected resource metadata discovery through to the token request. Client registration options and PKCE are included, which makes it useful at the design stage before implementation. If your server touches per-user data, this is not a section you can skip.

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

  • Blog · Author: MangKyu's Diary (망나니개발자)
  • One-line summary: A structure for injecting team-wide AI tool configuration without disturbing anyone's workflow.
  • Read this if: Your team agreed on AI tool conventions and nobody follows them.

The problem is real: announce configuration in a document and it goes unfollowed; enforce it and workflows break. This post threads between them by putting a thin layer in front of the executable, and the interesting part is that it combines two long-standing Unix practices to do it. It solves a new problem with familiar techniques, which means the idea transfers elsewhere. Worth weighing before adoption, though: transparent interception can make debugging harder.

Related Posts and Tools on This Blog

Other Posts in This Series

현재 단락 (1/73)

The selection method is the same across the series. I found candidates by searching and then **opene...

작성 글자: 0자원문 글자: 13,241자작성 단락: 0/73