국내 개발 블로그 명글 큐레이션 3 — AI와 ML 실무, 직접 열어 확인한 14편

이 목록이 무엇으로 채워졌는지 먼저 밝힙니다
검색과 RAG — 모델보다 먼저 무너지는 곳
서빙과 운영 — 붙이고 나서 시작되는 문제
모델의 기초 — 붙여 쓰기 전에 한 번은 봐야 할 것
- [논문 리뷰 & 코드 구현] Transformer (Attention is All You Need)
- [자연어 처리] 4. BERT
도입 현장의 기록 — 조직이 실제로 겪은 것
이 블로그의 관련 글과 도구
시리즈의 다른 글

이 목록이 무엇으로 채워졌는지 먼저 밝힙니다

선정 방법은 시리즈 전체와 같습니다. 검색으로 후보를 찾은 뒤 글을 직접 열어 확인했고, 그중에서 설명이 구체적이고 재현 가능한 것을 골랐습니다. 이 목록은 편집자의 선택이며 순위가 아닙니다. 조회수나 인기는 측정하지 않았고 측정할 수단도 없습니다.

한 가지 솔직하게 밝힐 것이 있습니다. 이 주제에서 확인 가능한 한국어 글을 모아 보니, 무게 중심이 모델을 학습시키는 쪽보다 이미 있는 모델을 붙이고 운영하는 쪽에 확실히 쏠려 있었습니다. 그래서 이 목록도 그렇게 구성되어 있습니다. 논문 리뷰와 모델 기초를 다룬 글도 두 편 넣었지만, 전체적으로는 RAG와 서빙과 운영이 주를 이룹니다. 이것은 제 선택이기도 하고 지금 한국어 개발 글의 분포이기도 합니다.

출처는 개인 블로그를 우선했고, 개인 도메인과 GitHub Pages 블로그가 절반 가까이 됩니다. 이 분야는 개인이 실험한 기록이 회사 발표보다 유용한 경우가 많아서 그렇게 되었습니다.

링크는 2026-08-12에 직접 열어 확인했습니다. 개인 블로그 글은 사라지거나 주소가 바뀔 수 있습니다.

검색과 RAG — 모델보다 먼저 무너지는 곳

RAG가 기대만큼 안 되는 이유는 대개 모델이 아니라 검색에 있습니다. 이 절의 글들은 그 검색 쪽을 봅니다.

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

블로그 · 작성자: 테디노트 (Teddy Lee)
한 줄 요약: 문서 적재부터 분할, 임베딩, 벡터 저장, 검색, 프롬프트, 모델 선택까지 RAG 파이프라인의 일곱 단계를 실제 PDF로 관통합니다.
이런 사람에게: RAG를 튜토리얼 수준에서 한 번 만들어 봤지만 각 단계에서 무엇을 조절해야 하는지 모르겠는 사람.

이 글의 강점은 완결성입니다. 파이프라인을 조각내지 않고 처음부터 끝까지 하나의 문서로 관통하기 때문에, 어느 단계의 선택이 어느 단계에 영향을 주는지가 보입니다. 분할 전략과 검색기 설정처럼 결과가 크게 갈리는 지점에 실험이 붙어 있는 것도 좋습니다. 한국어로 이 정도 범위를 한 편에 담은 글은 많지 않아서, 팀 내부 교육 자료로 링크를 걸어 두기에 적합합니다. 심화편이므로 기본 개념은 알고 읽는 편이 낫습니다.

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

블로그 · 작성자: Engineering Blog by Dale Seo
한 줄 요약: 텍스트가 벡터가 되고 코사인 유사도로 비교되는 과정을, 글자가 하나도 겹치지 않는 한국어 예시로 설명합니다.
이런 사람에게: 의미 검색을 도입하자는 말은 나왔는데 그것이 정확히 무엇인지 설명해야 하는 사람.

환불이라는 질의로 결제 취소라는 문서를 찾는 예시가 이 글의 중심에 있습니다. 글자 겹침이 전혀 없는데도 찾아진다는 사실 하나로 키워드 검색과의 차이가 즉시 이해됩니다. 파이썬과 자바스크립트 예제가 함께 있어서 어느 쪽 스택이든 바로 따라 할 수 있습니다. 개념을 짧고 정확하게 설명하는 글이 필요할 때 이만한 것을 찾기 어렵습니다.

[Vector DB] 2. Vector DB 의 종류

블로그 · 작성자: Jongya's blog
한 줄 요약: 널리 쓰이는 벡터 데이터베이스 일곱 종을 라이선스, 특징, 장단점으로 비교하고 선택 기준을 정리합니다.
이런 사람에게: 벡터 저장소를 골라야 하는데 후보가 너무 많아서 비교표부터 필요한 사람.

이런 종류의 비교 글은 금세 낡기 마련인데, 이 글은 기능 목록보다 선택 기준을 앞에 두어서 수명이 조금 더 깁니다. 데이터 규모, 배포 방식, 기존 시스템과의 통합이라는 세 축으로 정리하기 때문에 자기 상황을 대입하기 쉽습니다. 라이선스를 비교 항목에 넣은 것도 실무 관점에서 정직합니다. 시리즈의 두 번째 글이라 앞 편에서 개념을 잡고 오면 더 잘 읽힙니다.

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 에이전트를 쓴 점도 이 시기의 기록으로서 흥미롭습니다. 비용 관리를 시작해야 하는 팀에게 최소한의 출발점을 제공합니다.

모델의 기초 — 붙여 쓰기 전에 한 번은 봐야 할 것

응용만 반복하다 보면 어느 순간 판단이 막힙니다. 그때 필요한 것이 이 절의 두 편입니다.

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

블로그 · 작성자: tony3ynot.log · 박주용 (velog)
한 줄 요약: 트랜스포머 논문을 리뷰하는 데서 멈추지 않고 파이토치 구현까지 붙여 놓았습니다.
이런 사람에게: 어텐션을 그림으로는 이해했지만 코드로는 써 본 적 없는 사람.

논문 리뷰는 많고 구현도 많은데 둘이 한 글에 있는 경우는 드뭅니다. 이 글은 구조 설명 다음에 임베딩과 위치 인코딩과 멀티헤드 어텐션과 마스킹을 각각 코드로 보여 주기 때문에, 개념과 구현 사이의 간격이 좁습니다. 마스킹처럼 글로 읽으면 헷갈리는 부분이 코드에서는 명확해지는 것도 이 구성의 장점입니다. 기초를 다시 잡고 싶을 때 한 편으로 해결되는 종류의 글입니다.

[자연어 처리] 4. BERT

블로그 · 작성자: Hyungcheol Noh's Blog
한 줄 요약: BERT를 그 앞의 모델들과 이어서 설명하고, 사전 학습 과제와 미세 조정 방식과 벤치마크 결과까지 정리합니다.
이런 사람에게: 지금의 대규모 모델들이 어디에서 왔는지 계보를 잡고 싶은 사람.

BERT를 단독으로 설명하지 않고 그 이전 모델들과의 관계 속에 놓는 것이 이 글의 방식입니다. 그래서 양방향 인코딩이 왜 그때 의미 있는 진전이었는지가 납득됩니다. 시리즈의 네 번째 글이라 앞 편들과 이어 읽을 수 있고, 수식과 성능 표가 함께 있어 얕게 지나가지 않습니다. 지금 시점에서 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 도구 규칙을 정했는데 아무도 따르지 않아서 곤란한 사람.

문제가 현실적입니다. 설정을 문서로 공지하면 지켜지지 않고, 강제하면 작업 흐름이 망가집니다. 이 글은 실행 파일 앞에 얇은 층을 두어 설정을 끼워 넣는 방식으로 그 사이를 지나가는데, 오래된 유닉스 관행 두 가지를 조합한 것이 흥미롭습니다. 새 기술이 아니라 익숙한 기법으로 새 문제를 푸는 사례여서, 아이디어 자체가 다른 곳에도 옮겨집니다. 다만 투명한 개입은 디버깅을 어렵게 만들 수 있다는 점은 도입 전에 고려할 부분입니다.

이 블로그의 관련 글과 도구

시리즈의 다른 글

이전 글: 국내 개발 블로그 명글 큐레이션 2 — 장애 회고와 트러블슈팅
다음 글: 국내 개발 블로그 명글 큐레이션 4 — 프론트엔드
전체 목록: 1 백엔드와 인프라 · 5 커리어와 성장