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

- API 엔드포인트 보안 (2025-02-10)
- Ollama 로컬 LLM 사용후기 (2025-02-15)
- Cursor 에이전트 1달 후기 (2025-03-20)
- AI에게 개발 잘 시키는법 (2025-03-25)
- 개발인생 20년 회고 (2025-04-10)
- 라즈베리파이 키오스크 (2025-07-20)

Author: realcoding2003

_posts/2025-02-10-api-endpoint-security-without-login-en.md

@@ -0,0 +1,86 @@
+---
+layout: post
+title: "API Endpoint Security Without Authentication - How Far Should You Go?"
+date: 2025-02-10 09:00:00 +0900
+categories: [Development, Security]
+tags: [API, Security, CORS, Rate Limiting, Token]
+author: "Kevin Park"
+lang: en
+excerpt: "Protecting API endpoints on public sites with no login system. CORS alone isn't enough, but you can't force authentication either. Here's the practical approach."
+---
+
+# API Endpoint Security Without Authentication
+
+## The Problem
+
+I needed to secure API endpoints on a public website with no login functionality.
+
+Example: a company info page with a contact form that submits data via API. The API is exposed to the public. No login means no JWT or session-based authentication.
+
+Leave it unprotected? Someone discovers the API URL and scripts thousands of form submissions.
+
+## CORS Alone Isn't Enough
+
+The first thing that comes to mind is CORS configuration.
+
+```
+Access-Control-Allow-Origin: https://mysite.com
+```
+
+This blocks browser requests from other domains. But CORS is a **browser policy**. Requests from curl, Postman, or server-side scripts bypass CORS entirely.
+
+CORS is a convenience mechanism, not a security mechanism. Necessary but insufficient.
+
+## Practical Defense Strategy
+
+You need to combine multiple approaches.
+
+**1. API Key + HMAC Signature**
+
+The frontend generates an HMAC signature with a timestamp for each request. The server validates it using the same method. The key is exposed in source code, but combined with obfuscation, it deters casual attacks.
+
+**2. Rate Limiting**
+
+Block requests from the same IP beyond a certain threshold. Configurable at the API Gateway or Nginx level.
+
+```
+# Nginx rate limiting
+limit_req_zone $binary_remote_addr zone=api:10m rate=5r/m;
+
+location /api/contact {
+    limit_req zone=api burst=2 nodelay;
+}
+```
+
+No legitimate use case needs more than 5 contact submissions per minute. This stops scripted attacks.
+
+**3. CAPTCHA**
+
+Add reCAPTCHA or hCaptcha to the form. The most reliable way to block automated submissions. Downside: degrades user experience.
+
+**4. Honeypot Fields**
+
+Add a hidden input field via CSS. Humans can't see it and won't fill it. Bots try to fill every field. If the field has a value, reject the submission.
+
+```html
+<input type="text" name="website" style="display:none" tabindex="-1">
+```
+
+Simple but surprisingly effective.
+
+**5. One-Time Tokens**
+
+Issue a disposable token on page load. Include it with the API request. Discard after single use. Similar principle to CSRF protection.
+
+## My Chosen Combination
+
+Here's what I implemented:
+
+1. **Rate Limiting** (baseline defense)
+2. **Honeypot field** (bot defense)
+3. **One-time token** (replay prevention)
+4. **CORS** (standard configuration)
+
+Skipped CAPTCHA due to UX impact. Not perfect, but achieves a realistic security level for a no-auth environment.
+
+There's no 100% perfect security. The core strategy is raising the attack cost until it's not worth the effort.

_posts/2025-02-10-api-endpoint-security-without-login-ja.md

@@ -0,0 +1,86 @@
+---
+layout: post
+title: "ログインなしのAPIエンドポイントセキュリティ - どこまで守るべきか"
+date: 2025-02-10 09:00:00 +0900
+categories: [Development, Security]
+tags: [API, セキュリティ, CORS, Rate Limiting, トークン]
+author: "Kevin Park"
+lang: ja
+excerpt: "ログイン機能のない公開サイトでAPIエンドポイントを安全に保護する方法。CORSだけでは不十分で、かといって認証を強制もできない状況での現実的な対策。"
+---
+
+# ログインなしのAPIエンドポイントセキュリティ
+
+## 問題の状況
+
+ログイン機能のない公開ウェブサイトでAPIエンドポイントを保護する必要が出てきました。
+
+例えば、会社紹介ページでお問い合わせフォームを送信するとAPIにデータが送られますが、このAPIが外部にそのまま公開されています。ログインがないのでJWTやセッションベースの認証が使えません。
+
+放置すると？誰かがAPIのURLを見つけて、スクリプトでフォームを何千件も送信できてしまいます。
+
+## CORSだけでは不十分
+
+最初に思いつくのはCORS設定です。
+
+```
+Access-Control-Allow-Origin: https://mysite.com
+```
+
+これで他のドメインからブラウザでリクエストするのは防げます。でもCORSは**ブラウザのポリシー**です。curlやPostman、サーバーサイドスクリプトからのリクエストはCORS制限を受けません。
+
+結局CORSはセキュリティ手段ではなく便宜的な仕組みです。必要ですが、これだけでは足りません。
+
+## 現実的な防御戦略
+
+複数の方法を組み合わせて使う必要があります。
+
+**1. APIキー + HMAC署名**
+
+フロントエンドからリクエストする際にタイムスタンプと共にHMAC署名を生成して送ります。サーバーで同じ方法で署名を検証します。キーがソースコードに露出する問題がありますが、難読化と組み合わせればカジュアルな攻撃は防げます。
+
+**2. Rate Limiting**
+
+同じIPから一定回数以上のリクエストが来たらブロックします。API GatewayやNginxレベルで設定できます。
+
+```
+# Nginx rate limiting
+limit_req_zone $binary_remote_addr zone=api:10m rate=5r/m;
+
+location /api/contact {
+    limit_req zone=api burst=2 nodelay;
+}
+```
+
+お問い合わせフォームが毎分5件以上必要なケースはないので、これでスクリプト攻撃は防げます。
+
+**3. CAPTCHA**
+
+reCAPTCHAやhCaptchaをフォームに追加します。ボットによる自動送信を防ぐ最も確実な方法です。ただしユーザー体験が悪くなるデメリットがあります。
+
+**4. ハニーポットフィールド**
+
+CSSで非表示にした入力フィールドをフォームに追加します。人間はこのフィールドが見えないので入力しませんが、ボットはすべてのフィールドを埋めようとします。このフィールドに値があればボットと判断して拒否します。
+
+```html
+<input type="text" name="website" style="display:none" tabindex="-1">
+```
+
+シンプルですが意外と効果的です。
+
+**5. ワンタイムトークン**
+
+ページロード時にサーバーからワンタイムトークンを発行し、APIリクエスト時にこのトークンを一緒に送ります。一度使われたトークンは破棄します。CSRF防御と似た原理です。
+
+## 私が選んだ組み合わせ
+
+最終的に適用したのはこの組み合わせです。
+
+1. **Rate Limiting**（基本防御）
+2. **ハニーポットフィールド**（ボット防御）
+3. **ワンタイムトークン**（再利用防止）
+4. **CORS**（基本設定）
+
+CAPTCHAはUXへの影響が大きいので外しました。完璧ではありませんが、ログインなしの環境で現実的に可能なレベルのセキュリティは確保できます。
+
+100%完璧なセキュリティはありません。結局「攻撃コストを上げて面倒にする」のが核心です。

_posts/2025-02-10-api-endpoint-security-without-login.md

@@ -0,0 +1,86 @@
+---
+layout: post
+title: "로그인 없는 API 엔드포인트 보안 - 어디까지 막아야 하나"
+date: 2025-02-10 09:00:00 +0900
+categories: [Development, Security]
+tags: [API, 보안, CORS, Rate Limiting, 토큰]
+author: "Kevin Park"
+lang: ko
+excerpt: "로그인 없이 접근 가능한 API를 안전하게 보호하는 방법. CORS만으로는 부족하고, 그렇다고 인증을 강제할 수도 없는 상황에서의 현실적인 대책."
+---
+
+# 로그인 없는 API 엔드포인트 보안
+
+## 문제 상황
+
+로그인 기능이 없는 공개 웹사이트에서 API 엔드포인트를 보호해야 하는 상황이 생겼다.
+
+예를 들어 회사 소개 페이지에서 문의 폼을 제출하면 API로 데이터가 전송되는데, 이 API가 외부에 그대로 노출되어 있다. 로그인이 없으니 JWT나 세션 기반 인증을 쓸 수가 없다.
+
+그냥 놔두면? 누군가 API 주소를 알아내서 스크립트로 문의 폼을 수천 건씩 제출할 수 있다.
+
+## CORS만으로는 부족하다
+
+가장 먼저 떠오르는 건 CORS 설정이다.
+
+```
+Access-Control-Allow-Origin: https://mysite.com
+```
+
+이렇게 하면 다른 도메인에서 브라우저로 요청하는 건 막을 수 있다. 근데 CORS는 **브라우저 정책**이다. curl이나 Postman, 서버 사이드 스크립트에서 보내는 요청은 CORS 제한을 안 받는다.
+
+결국 CORS는 보안 수단이 아니라 편의 수단이다. 있어야 하지만 이것만으로는 안 된다.
+
+## 현실적인 방어 전략
+
+여러 방법을 조합해서 써야 한다.
+
+**1. API Key + HMAC 서명**
+
+프론트엔드에서 요청할 때 타임스탬프와 함께 HMAC 서명을 생성해서 보낸다. 서버에서 같은 방식으로 서명을 검증한다. 키가 소스 코드에 노출되는 문제가 있지만, 난독화와 조합하면 캐주얼한 공격은 막을 수 있다.
+
+**2. Rate Limiting**
+
+같은 IP에서 일정 횟수 이상 요청이 오면 차단한다. API Gateway나 Nginx 레벨에서 설정할 수 있다.
+
+```
+# Nginx rate limiting
+limit_req_zone $binary_remote_addr zone=api:10m rate=5r/m;
+
+location /api/contact {
+    limit_req zone=api burst=2 nodelay;
+}
+```
+
+문의 폼이 분당 5건 이상 필요한 경우는 없으니까 이 정도면 스크립트 공격은 막을 수 있다.
+
+**3. CAPTCHA**
+
+reCAPTCHA나 hCaptcha를 폼에 붙인다. 봇이 자동으로 제출하는 걸 막는 가장 확실한 방법이다. 근데 사용자 경험이 나빠지는 단점이 있다.
+
+**4. Honeypot 필드**
+
+폼에 CSS로 숨긴 입력 필드를 추가한다. 사람은 이 필드를 안 보니까 안 채우지만, 봇은 모든 필드를 채우려고 한다. 이 필드에 값이 있으면 봇으로 판단해서 거부한다.
+
+```html
+<input type="text" name="website" style="display:none" tabindex="-1">
+```
+
+단순하지만 의외로 효과적이다.
+
+**5. 일회용 토큰**
+
+페이지 로드 시 서버에서 일회용 토큰을 발급하고, API 요청 시 이 토큰을 함께 보낸다. 한 번 사용된 토큰은 폐기된다. CSRF 방어와 비슷한 원리다.
+
+## 내가 선택한 조합
+
+결론적으로 내가 적용한 건 이 조합이다.
+
+1. **Rate Limiting** (기본 방어)
+2. **Honeypot 필드** (봇 방어)
+3. **일회용 토큰** (재사용 방지)
+4. **CORS** (기본 설정)
+
+CAPTCHA는 UX 영향이 커서 뺐다. 이 정도면 완벽하진 않지만, 로그인 없는 환경에서 현실적으로 가능한 수준의 보안은 확보된다.
+
+100% 완벽한 보안은 없다. 결국 "공격 비용을 올려서 귀찮게 만드는" 게 핵심이다.

_posts/2025-02-15-ollama-local-llm-review-en.md

@@ -0,0 +1,65 @@
+---
+layout: post
+title: "Running LLMs Locally With Ollama - It Depends on the Use Case"
+date: 2025-02-15 09:00:00 +0900
+categories: [Development, AI]
+tags: [Ollama, LLM, Local AI, Llama, Offline]
+author: "Kevin Park"
+lang: en
+excerpt: "I wanted to run LLMs locally so I set up Ollama. Surprisingly easy to get running, but the gap with cloud APIs is clear when you need real capability."
+---
+
+# Running LLMs Locally With Ollama
+
+## Why Run AI Locally?
+
+Using cloud services like ChatGPT and Claude, there's always one nagging concern: sending my code to external servers.
+
+Personal projects, fine. But working with client code or company-confidential material? That's uncomfortable. "We don't use your data for training," they say. But still.
+
+So I decided to try running LLMs locally. Ollama seemed like the simplest option for installation and model management.
+
+## Setup Is Dead Simple
+
+```bash
+# macOS
+brew install ollama
+
+# Start the service
+ollama serve
+
+# Download and run a model
+ollama run llama3.1
+```
+
+That's it. Three lines and you have a local LLM running. No Docker configuration, no GPU driver hassle.
+
+The model library is solid too. Llama 3.1, CodeLlama, Mistral, Gemma — open-source models downloadable with a single `ollama pull`.
+
+## Real-World Usage
+
+**Code assistance** — Tried CodeLlama. Simple function generation and code explanation work fine. But complex refactoring or architecture-level suggestions fall well short of GPT-4 or Claude.
+
+**Document summarization** — Used Llama 3.1 for summarization. English documents came out decent. Non-English languages are noticeably weaker compared to cloud models.
+
+**Speed** — Ran it on an M4 Mac Mini. 7B models have acceptable speed. But 70B-class models generate tokens too slowly to be practical. GPU memory is the bottleneck.
+
+## My Conclusion
+
+After trying various configurations, here's where I landed:
+
+**Local LLM works well for:**
+- Security-sensitive environments (proprietary code, confidential documents)
+- Offline usage requirements
+- Simple repetitive tasks (format conversion, basic classification)
+- Reducing API costs
+
+**Cloud LLM wins for:**
+- Complex reasoning tasks
+- Non-English language processing
+- Access to current knowledge
+- Long context handling
+
+The conclusion is the predictable "it depends on the use case," but actually using both clarified exactly where that boundary sits. Local LLMs don't replace cloud LLMs — they complement them.
+
+For daily work, Claude and GPT remain the primary tools, with Ollama reserved for security-sensitive tasks. Open-source models are improving rapidly, so this could change — but that's where things stand today.

_posts/2025-02-15-ollama-local-llm-review-ja.md

@@ -0,0 +1,65 @@
+---
+layout: post
+title: "OllamaでローカルLLMを動かしてみた感想 - 結論は用途次第"
+date: 2025-02-15 09:00:00 +0900
+categories: [Development, AI]
+tags: [Ollama, LLM, ローカルAI, Llama, オフライン]
+author: "Kevin Park"
+lang: ja
+excerpt: "ローカルでLLMを動かしたくてOllamaを導入しました。思ったより簡単に動きますが、クラウドAPIと比べると限界は明確です。"
+---
+
+# OllamaでローカルLLMを動かしてみた
+
+## ローカルでAIを動かしたかった
+
+ChatGPTやClaudeのようなクラウドサービスを使っていると、一つ気になることがあります。自分のコードを外部サーバーに送らなければならないことです。
+
+個人プロジェクトなら構いませんが、クライアントのコードや会社の機密が含まれる作業をする時はちょっと不安です。「データを学習に使用しません」と言われても、やはり。
+
+そこでローカルでLLMを動かしてみることにしました。Ollamaがインストールも簡単でモデル管理も楽だと聞いて選びました。
+
+## セットアップは本当に簡単
+
+```bash
+# macOS
+brew install ollama
+
+# サービス開始
+ollama serve
+
+# モデルダウンロードと実行
+ollama run llama3.1
+```
+
+これだけです。本当に3行でローカルLLMが動きます。Dockerの設定もGPUドライバも何も必要ありません。
+
+モデルも豊富です。Llama 3.1、CodeLlama、Mistral、Gemmaなどのオープンソースモデルを`ollama pull`一行でダウンロードできます。
+
+## 実際の使用感
+
+**コード作成補助** — CodeLlamaを試しました。簡単な関数作成やコード説明は大丈夫ですが、複雑なリファクタリングやアーキテクチャレベルの提案はGPT-4やClaudeに比べるとかなり劣ります。
+
+**ドキュメント要約** — Llama 3.1でドキュメント要約をさせてみました。英語のドキュメントはまあまあですが、日本語はまだ弱いです。日本語の理解力がクラウドモデルに比べて明らかに劣ります。
+
+**速度** — M4 Mac Miniで動かしましたが、7Bモデルは体感速度が悪くありません。でも70B級モデルはトークン生成速度が遅すぎて実用的ではありません。GPUメモリが鍵です。
+
+## 自分なりの結論
+
+いろいろ試してみて出した結論はこうです。
+
+**ローカルLLMが適しているケース：**
+- セキュリティが重要な環境（コード、機密文書）
+- オフライン環境で使う必要がある時
+- 単純な繰り返し作業（フォーマット変換、簡単な分類など）
+- APIコストを節約したい時
+
+**クラウドLLMの方が良いケース：**
+- 複雑な推論が必要な時
+- 日本語処理
+- 最新の知識が必要な時
+- 長いコンテキストを扱う時
+
+結局「用途次第」というありきたりな結論ですが、実際に使ってみるとこの「用途」の境界が明確になりました。ローカルLLMはクラウドを代替するのではなく、補完する関係なのです。
+
+業務用にはまだClaudeやGPTをメインで使いつつ、セキュリティが必要な作業でのみOllamaを使うのが現実的だと思います。オープンソースモデルが急速に発展しているので、今後は変わるかもしれませんが。