docs(blog): sir.kr 2024년 포스트 4건 마이그레이션 (3개 언어)

- 블로그 유목민 정착기 (플랫폼 전전 → GitHub Pages)
- MSA 설계에 ChatGPT 활용 후기
- SvelteKit 프레임워크 입문 도전
- 벡터 데이터베이스 도입 판단 기준 정리

Author: realcoding2003

_posts/2024-01-15-blog-nomad-finally-settled-en.md

@@ -0,0 +1,58 @@
+---
+layout: post
+title: "The Blog Nomad Finally Settles Down"
+date: 2024-01-15 09:00:00 +0900
+categories: [Life, Essay]
+tags: [Blog, WordPress, GitHub Pages, Developer, Writing]
+author: "Kevin Park"
+lang: en
+excerpt: "Naver Blog, Tistory, WordPress, GitHub Pages... After years of platform-hopping, I've finally settled. A developer's blog nomad journey comes to an end."
+---
+
+# The Blog Nomad Finally Settles Down
+
+## A History of Wandering
+
+I didn't expect running a single blog to be this hard.
+
+Looking back, the number of blog platforms I've been through is embarrassing.
+
+**Naver Blog** — Where it all started. Accessible, but code block support was terrible. You can't write dev content without proper code formatting. The frustration drove me out.
+
+**Tistory** — Moved for the free skin customization. Markdown support was decent. But after Kakao acquired it, things felt unstable. Policies kept changing, and depending on a platform for my own content felt wrong.
+
+**WordPress** — Self-hosted means full ownership, so I switched. The plugin ecosystem is incredible, but update management is a pain. Plugin conflicts crash the site, skip security patches and you get hacked. I came to write blog posts but ended up managing a server.
+
+**GitHub Pages** — Jekyll-based static site. Write in Markdown, git push, done. No server management, free, full ownership. Initial setup was a bit tedious though, and the entry barrier for non-developers is high.
+
+## Why All the Moving?
+
+Each migration had its reasons. But honestly, looking back, they were closer to excuses.
+
+The real reason is simple: **when you're not writing, you blame the platform.**
+
+"The code blocks look ugly here." "Loading is slow." "SEO is bad." Switching blog platforms is like giving yourself a pass for not writing. Moving feels like a fresh start. But you move and still don't write.
+
+It's the same as buying workout clothes to start a diet.
+
+## This Time Is Different
+
+I've settled on GitHub Pages + Jekyll.
+
+The reasons are straightforward:
+
+- Write in Markdown — the most natural format for developers
+- Managed with git — version control built in
+- No hosting costs — free
+- Custom domain support — looks professional
+- No platform lock-in — Markdown files can go anywhere
+
+The most important thing: writing a blog post follows the same workflow as writing code. Open editor, write Markdown, git commit, push. It feels natural because it's identical to the development cycle.
+
+## It's About Habit, Not Platform
+
+In the end, blog failure isn't a platform problem — it's a habit problem.
+
+No matter which platform you use, the key is writing consistently. Don't aim for perfect posts. Write short, write often. And stick with wherever you've chosen. No more moving.
+
+I'm genuinely going to write regularly this time. Of course, I've made this promise every time... but this time it's for real. Probably. Maybe.

_posts/2024-01-15-blog-nomad-finally-settled-ja.md

@@ -0,0 +1,58 @@
+---
+layout: post
+title: "ブログ遊牧民、ついに定住する"
+date: 2024-01-15 09:00:00 +0900
+categories: [Life, Essay]
+tags: [ブログ, WordPress, GitHub Pages, 開発者, 執筆]
+author: "Kevin Park"
+lang: ja
+excerpt: "いくつものブログプラットフォームを転々として、ようやく定住しました。開発者のブログ遊牧生活の終結記です。"
+---
+
+# ブログ遊牧民、ついに定住する
+
+## 遊牧生活の歴史
+
+ブログ一つ運営するのがこんなに大変だとは思いませんでした。
+
+振り返ると、今まで経てきたブログプラットフォームの数は一つや二つではありません。
+
+**韓国の大手ブログ** → 最初に始めた場所。アクセシビリティは良かったのですが、コードブロックのサポートがひどかったです。開発記事を書くにはコードが必須なのに、きれいに表示されない。そのストレスで離れました。
+
+**Tistory** → スキンのカスタマイズが自由だったので移動。Markdownもサポートしていてまあまあ良かったです。でも買収後に何か不安になりました。ポリシーが頻繁に変わり、自分のコンテンツなのにプラットフォーム依存というのが引っかかりました。
+
+**WordPress** → 自分でホスティングすれば完全な所有権があるので移動。プラグインのエコシステムは素晴らしいのですが、アップデート管理が面倒です。プラグインの競合でサイトがダウンし、セキュリティパッチを怠ると攻撃される。ブログを書きに来たのにサーバー管理をしている状態でした。
+
+**GitHub Pages** → Jekyllベースの静的サイト。Markdownで書いてgit pushすれば完了。サーバー管理不要、無料、完全な所有権。ただし初期セットアップが少し面倒で、非開発者にはハードルが高いです。
+
+## なぜこんなに引っ越したのか
+
+毎回引っ越すたびにそれなりの理由がありました。でも正直に振り返ると、言い訳に近かったです。
+
+本当の理由は一つ。**書いていないからプラットフォームのせいにしている。**
+
+「ここはコードブロックがきれいじゃないから」「ここはロードが遅いから」「ここはSEOが弱いから」...ブログプラットフォームの引っ越しは、書かない自分への免罪符のようなものです。引っ越せば新しく始められる気がする。でも引っ越しだけして、また書かない。
+
+ダイエットのために運動着を買うのと同じです。
+
+## 今度こそ違います
+
+今回定住した場所はGitHub Pages + Jekyllです。
+
+理由はシンプルです：
+
+- Markdownで書く → 開発者にとって最も自然なフォーマット
+- gitで管理する → バージョン管理ができる
+- サーバー費用がない → 無料
+- カスタムドメイン対応 → プロフェッショナルに見える
+- プラットフォームに依存しない → Markdownファイルはどこにでも移せる
+
+最も重要なのは「ブログを書く過程が開発ワークフローと同じ」ということです。エディタでMarkdownを書いて、git commitして、push。コードをコミットするようにブログが書けるので自然です。
+
+## プラットフォームではなく習慣の問題
+
+結局ブログがうまくいかないのはプラットフォームの問題ではなく、習慣の問題でした。
+
+どのプラットフォームを使おうが、コンスタントに書くことが核心です。完璧な記事を書こうとせず、短くても頻繁に書くことが大事です。そして一度決めた場所で書き続けること。引っ越しはもうおしまい。
+
+今回の定住地では本当にコンスタントに書くつもりです。もちろんこの決意も毎回してきましたが...今度こそ本当です。たぶん。おそらく。

_posts/2024-01-15-blog-nomad-finally-settled.md

@@ -0,0 +1,58 @@
+---
+layout: post
+title: "블로그 유목민, 드디어 정착하다"
+date: 2024-01-15 09:00:00 +0900
+categories: [Life, Essay]
+tags: [블로그, 티스토리, 워드프레스, 네이버블로그, 개발자]
+author: "Kevin Park"
+lang: ko
+excerpt: "네이버 블로그, 티스토리, 워드프레스, GitHub Pages... 블로그 플랫폼을 전전하다가 드디어 정착했다. 개발자의 블로그 유목 생활 종결기."
+---
+
+# 블로그 유목민, 드디어 정착하다
+
+## 유목 생활의 역사
+
+블로그 하나 운영하는 게 이렇게 어려울 줄 몰랐다.
+
+돌이켜보면 지금까지 거쳐 온 블로그 플랫폼이 한둘이 아니다.
+
+**네이버 블로그** → 처음 시작한 곳. 접근성은 좋았는데 코드 블록 지원이 형편없었다. 개발 글 쓰려면 코드가 필수인데 이쁘게 들어가질 않으니까 스트레스받아서 떠남.
+
+**티스토리** → 스킨 커스터마이징이 자유로워서 이동. 마크다운도 지원하고 나름 괜찮았다. 근데 카카오가 인수하고 나서 뭔가 불안해졌다. 정책이 수시로 바뀌고, 내 콘텐츠인데 플랫폼 의존적이라는 게 꺼림칙했다.
+
+**워드프레스** → 직접 호스팅하면 완전한 소유권이 있으니까 이동. 플러그인 생태계가 대단하긴 한데, 업데이트 관리가 귀찮다. 플러그인 충돌 나면 사이트가 뻗고, 보안 패치 안 하면 해킹당하고. 블로그 쓰려고 왔는데 서버 관리를 하고 있다.
+
+**GitHub Pages** → Jekyll 기반 정적 사이트. 마크다운으로 쓰고 git push하면 끝. 서버 관리 필요 없고, 무료이고, 완전한 소유권. 근데 초기 세팅이 좀 귀찮고, 비개발자한테는 진입 장벽이 높다.
+
+## 왜 이렇게 옮겨 다녔나
+
+매번 옮길 때마다 나름의 이유가 있었다. 근데 솔직히 돌이켜보면 핑계에 가까웠다.
+
+진짜 이유는 하나다. **글을 안 쓰니까 플랫폼 탓을 하는 거다.**
+
+"여기는 코드 블록이 안 이뻐서", "여기는 로딩이 느려서", "여기는 SEO가 안 좋아서"... 블로그 플랫폼 옮기는 건 글 안 쓰는 자신에 대한 면죄부 같은 거다. 이사하면 뭔가 새롭게 시작할 수 있을 것 같은 기분. 근데 이사만 하고 글은 또 안 쓴다.
+
+다이어트하려고 운동복 사는 거랑 같은 거다.
+
+## 이번에는 다르다
+
+이번에 정착한 곳은 GitHub Pages + Jekyll이다.
+
+이유는 단순하다:
+
+- 마크다운으로 글을 쓴다 → 개발자한테 가장 자연스러운 포맷
+- git으로 관리한다 → 버전 관리가 된다
+- 서버 비용이 없다 → 무료
+- 커스텀 도메인 지원 → 전문적으로 보인다
+- 플랫폼에 종속되지 않는다 → 마크다운 파일은 어디로든 옮길 수 있다
+
+가장 중요한 건 "글 쓰는 과정이 개발 워크플로우랑 같다"는 거다. 에디터에서 마크다운 쓰고, git commit하고, push. 코드 커밋하듯이 블로그를 쓸 수 있으니까 자연스럽다.
+
+## 플랫폼이 아니라 습관의 문제
+
+결국 블로그가 안 되는 건 플랫폼 문제가 아니라 습관의 문제였다.
+
+어떤 플랫폼을 쓰든 꾸준히 글을 쓰는 게 핵심이다. 완벽한 글을 쓰려고 하지 말고, 짧더라도 자주 쓰는 게 중요하다. 그리고 한번 정한 곳에서 계속 쓰는 게 중요하다. 이사는 이제 그만.
+
+이번 정착지에서는 진짜로 꾸준히 써보려고 한다. 물론 이 다짐도 매번 했었지만... 이번에는 진짜다. 아마도. 아마.

_posts/2024-02-10-msa-and-chatgpt-en.md

@@ -0,0 +1,61 @@
+---
+layout: post
+title: "Using ChatGPT for Microservice Architecture Design - An Honest Review"
+date: 2024-02-10 09:00:00 +0900
+categories: [Development, AI]
+tags: [MSA, ChatGPT, Microservices, Architecture, AI]
+author: "Kevin Park"
+lang: en
+excerpt: "I tried using ChatGPT to help design a microservice architecture. It's no replacement for an architect, but as a rubber duck debugging partner, it's unbeatable."
+---
+
+# Using ChatGPT for MSA Design
+
+## ChatGPT as Architecture Consultant?
+
+I've been actively using ChatGPT at work lately.
+
+Using it for code generation and debugging is old news. This time, I tried it during the design phase of a microservice architecture project — decomposing an existing monolith into microservices, using ChatGPT as an architecture sounding board.
+
+Bottom line: more useful than expected.
+
+## Where It Helped
+
+These were the main areas:
+
+**Service boundary identification.** The hardest part of moving from monolith to microservices is deciding where to cut. I described the current system to ChatGPT and asked how it might be decomposed. The suggestions were reasonably sound. Not directly usable, but a solid starting point for thinking.
+
+**Communication pattern decisions.** When debating synchronous (REST) vs asynchronous (message queue) for inter-service communication, I asked for pros, cons, and situational recommendations. Textbook answers, but well-organized — useful as decision-support material.
+
+**Failure scenario simulation.** Questions like "If the payment service goes down in this architecture, what happens?" yielded helpful cascade failure scenarios. It surfaced edge cases I'd overlooked.
+
+## Clear Limitations
+
+ChatGPT can't replace an architect.
+
+It doesn't know your actual system. Traffic patterns, team size, codebase state, business constraints — you can explain all of this, but it still can't fully grasp the real context.
+
+It offers "general best practices," not "the right answer." MSA design varies by situation, but ChatGPT defaults to textbook responses. "Our team is 3 people with 100K lines of legacy code" type constraints don't get properly factored in.
+
+And it occasionally states wrong things with full confidence. Hallucinations are particularly common with recent libraries and tool specifics. Never trust answers without verification.
+
+## The Most Useful Role
+
+Where ChatGPT proved most valuable was as a **rubber duck debugging partner.**
+
+When designing architecture solo, it's easy to get trapped in your own thinking. You convince yourself an approach works and stop seeing counterarguments. Explaining your design to ChatGPT and asking "any problems with this?" surfaces edge cases you hadn't considered.
+
+It's like having a colleague you can ask "can you review this?" — except this one answers at 2 AM. It can't replace a real colleague's experience and intuition, of course.
+
+## My Practical Workflow
+
+Here's the approach I've settled on:
+
+1. I create the design first
+2. Explain it to ChatGPT and request a review
+3. Incorporate only the valid criticism
+4. Ask about implementation details during the build phase
+
+The key: ChatGPT reviews my design — it doesn't create it. I always maintain ownership. That keeps responsibility clear.
+
+AI tools genuinely boost productivity. But "AI will figure it out" is a dangerous mindset. Tools are tools, nothing more.

_posts/2024-02-10-msa-and-chatgpt-ja.md

@@ -0,0 +1,61 @@
+---
+layout: post
+title: "MSA設計にChatGPTを活用してみた感想"
+date: 2024-02-10 09:00:00 +0900
+categories: [Development, AI]
+tags: [MSA, ChatGPT, マイクロサービス, アーキテクチャ, AI]
+author: "Kevin Park"
+lang: ja
+excerpt: "マイクロサービスアーキテクチャの設計にChatGPTを活用してみました。万能ではありませんが、ラバーダックデバッグの相手としては最高です。"
+---
+
+# MSA設計にChatGPTを活用してみた
+
+## ChatGPTがアーキテクチャ設計を？
+
+最近、ChatGPTを業務に積極的に活用しています。
+
+コード作成やデバッグに使うのはもう一般的ですが、今回はMSA（Microservice Architecture）の設計段階で使ってみました。既存のモノリシックサービスをマイクロサービスに分離するプロジェクトを進めながら、ChatGPTにアーキテクチャの相談をしてみたのです。
+
+結論から言うと、思ったより使えました。
+
+## どこに活用したか
+
+主にこういった部分で助けてもらいました。
+
+**サービス境界の設定**。モノリスからマイクロサービスに分離する時、最も難しいのが「どこで切るか」です。ChatGPTに現在のシステム構造を説明して「これをMSAに分離するならどう分けられるか？」と聞いたところ、かなり合理的な提案が出てきました。そのまま使えるわけではありませんが、思考の出発点としては良かったです。
+
+**通信パターンの選択**。サービス間通信を同期（REST）にするか非同期（メッセージキュー）にするか迷った時、それぞれの長所短所と状況別の推奨を聞きました。教科書的な回答ではありますが、整理されていて意思決定の参考として良かったです。
+
+**障害シナリオのシミュレーション**。「この構成で決済サービスがダウンしたらどうなるか？」のような質問を投げると、連鎖障害のシナリオを列挙してくれます。見落としていた部分を発見するのに役立ちました。
+
+## 限界も明確
+
+ChatGPTがアーキテクトを代替することはできません。
+
+まず私たちのシステムの実際の状況を知りません。トラフィックパターン、チーム構成、既存コードの状態、ビジネス上の制約...全部説明しても実際のコンテキストを完全には理解できません。
+
+「正解」ではなく「一般的なベストプラクティス」を教えてくれます。MSA設計は状況によって正解が異なりますが、ChatGPTは教科書的な回答に近いです。「うちのチームは3人でレガシーコードが10万行なんだけど」のような現実的な制約を反映した回答は期待しにくいです。
+
+そして時々、自信を持って間違ったことを言います。特に最新のライブラリやツールの詳細についてハルシネーションが出ます。回答をそのまま信じず、必ず検証が必要です。
+
+## 最も有用だった使い方
+
+結局ChatGPTが最も有用だったのは**ラバーダックデバッグの相手**としてです。
+
+一人でアーキテクチャを設計すると、自分の考えに閉じこもりがちです。「これでいけるのでは？」と確信すると反対意見が見えなくなります。ChatGPTに自分の設計を説明しながら「これに問題はないか？」と聞くと、思いもよらなかったエッジケースを提示してくれます。
+
+以前は同僚に「これちょっと見てくれない？」とお願いしていたのが、深夜2時でも答えてくれる同僚ができたようなものです。もちろん本物の同僚の経験と直感は代替できませんが。
+
+## 実践ワークフロー
+
+私が定着した活用方式はこうです：
+
+1. まず自分で設計案を作る
+2. ChatGPTに設計案を説明してレビューを依頼する
+3. 指摘された部分のうち妥当なものだけ反映する
+4. 実装段階で詳細を質問する
+
+核心は「ChatGPTが設計するのではなく、自分が設計してChatGPTがレビューする」方式です。主導権は常に自分が持つこと。そうすれば結果に対する責任も明確になります。
+
+AIツールが生産性を上げてくれるのは確かですが、「AIが何とかしてくれるだろう」は危険です。ツールはツールに過ぎません。