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

- API Gateway 스테이지별 Lambda 함수 분리 삽질기
- 경쟁 PT에서 사이트 리뉴얼 프로젝트 수주 경험
- jQuery 개발자의 Vue.js 입문기

Author: realcoding2003

_posts/2021-03-15-aws-api-gateway-lambda-stages-en.md

@@ -0,0 +1,96 @@
+---
+layout: post
+title: "API Gateway Stage-Specific Lambda Functions - A Tale of Debugging Permissions"
+date: 2021-03-15 09:00:00 +0900
+categories: [Development, DevOps]
+tags: [AWS, API Gateway, Lambda, Stages, Serverless]
+author: "Kevin Park"
+lang: en
+excerpt: "I wanted API Gateway to call different Lambda functions per stage — dev, staging, prod. The docs made it look simple. It wasn't."
+---
+
+# API Gateway Stage-Specific Lambda Functions
+
+## What I Wanted
+
+After [getting into AWS](/2020/09/10/getting-into-aws-en/) and [passing the Developer Associate cert](/2020/12/15/aws-developer-certification-en/), I started applying it to real projects.
+
+One thing I needed was calling different Lambda functions per API Gateway stage. Dev, staging, and production environments each needed their own function. Sounds straightforward, right?
+
+The desired setup:
+
+```
+API Gateway
+├── dev stage → my-function-dev
+├── staging stage → my-function-staging
+└── prod stage → my-function-prod
+```
+
+## First Attempt - Stage Variables
+
+API Gateway has a feature called Stage Variables. You can set different variable values per stage and reference them in the Lambda integration.
+
+In the Lambda integration config, set the function name to:
+
+```
+my-function-${stageVariables.env}
+```
+
+Then set the `env` variable to `dev`, `staging`, or `prod` in each stage.
+
+The official docs cover this much. But if you stop here, it simply won't work.
+
+## The Permissions Problem
+
+It fails because of Lambda's resource-based policy.
+
+For API Gateway to invoke a Lambda function, the function needs a policy saying "API Gateway is allowed to invoke me." When you set up the integration through the console normally, this permission is added automatically. But with stage variables, the automatic permission doesn't get created.
+
+Why? Because the console adds permission for a specific function name, and `${stageVariables.env}` isn't resolved to an actual name yet.
+
+You need to manually add permissions to each Lambda function:
+
+```bash
+aws lambda add-permission \
+  --function-name my-function-dev \
+  --statement-id apigateway-dev \
+  --action lambda:InvokeFunction \
+  --principal apigateway.amazonaws.com \
+  --source-arn "arn:aws:execute-api:ap-northeast-2:123456789:api-id/*/GET/resource"
+```
+
+Run this for dev, staging, and prod functions individually.
+
+## This Had Me Stuck for Hours
+
+The official docs say "you can specify Lambda functions using stage variables" but the part about manually adding permissions was buried in a small note. Finding proper explanations online wasn't easy either.
+
+The error message wasn't helpful: "Execution failed due to configuration error: Invalid permissions on Lambda function." No clear indication of what to fix.
+
+I ended up digging through CloudWatch logs, Stack Overflow, and AWS forums before figuring it out.
+
+## Alternative Approach - Lambda Aliases
+
+Instead of stage variables, you can use Lambda Aliases.
+
+Deploy multiple versions of a single function and attach aliases to each:
+
+```
+my-function:dev
+my-function:staging
+my-function:prod
+```
+
+This way you manage one function instead of three. Deployments are cleaner too — just update the alias.
+
+The permissions issue is the same though. Each alias needs its own permission grant.
+
+## Takeaway
+
+The core issue was **permissions**. The functionality itself is simple — it's the authorization that breaks things.
+
+Working with AWS, I've come to feel that IAM permissions account for roughly half of total learning time. Setting up "who can call whom" is harder than the services themselves.
+
+Still, getting it working felt great. Now the dev-to-prod deployment pipeline runs cleanly.
+
+This was the first real-world case where studying for the certification actually paid off. Education doesn't betray you... or so I'd like to believe.

_posts/2021-03-15-aws-api-gateway-lambda-stages-ja.md

@@ -0,0 +1,96 @@
+---
+layout: post
+title: "API Gatewayステージ別Lambda関数の分離 - 権限設定で苦労した話"
+date: 2021-03-15 09:00:00 +0900
+categories: [Development, DevOps]
+tags: [AWS, API Gateway, Lambda, ステージ, サーバーレス]
+author: "Kevin Park"
+lang: ja
+excerpt: "API Gatewayでdev、staging、prodステージごとに異なるLambda関数を呼び出したかった。公式ドキュメントだけでは全然できなくて、かなり苦労しました。"
+---
+
+# API Gatewayステージ別Lambda関数の分離
+
+## やりたかったこと
+
+[AWSにハマって勉強し](/2020/09/10/getting-into-aws-ja/)、[資格まで取った](/2020/12/15/aws-developer-certification-ja/)後、実際のプロジェクトに本格的に適用し始めました。
+
+そこで必要になったのが、API Gatewayのステージごとに異なるLambda関数を呼び出すことでした。開発（dev）、ステージング（staging）、本番（prod）環境でそれぞれ異なる関数を呼び出す必要があったのですが、これが思ったより簡単ではありませんでした。
+
+やりたかった構成はこうです：
+
+```
+API Gateway
+├── dev ステージ → my-function-dev
+├── staging ステージ → my-function-staging
+└── prod ステージ → my-function-prod
+```
+
+## 最初の試み - ステージ変数
+
+API Gatewayにはステージ変数（Stage Variables）という機能があります。ステージごとに異なる変数値を設定でき、Lambda関数名にこの変数を使えます。
+
+Lambda統合設定で関数名をこう設定します：
+
+```
+my-function-${stageVariables.env}
+```
+
+そして各ステージで`env`変数を`dev`、`staging`、`prod`に設定。
+
+ここまでは公式ドキュメントにも書いてあります。でもこのままだと動きません。
+
+## 権限の問題
+
+動かない理由はLambdaのリソースベースポリシー（Resource-based Policy）にあります。
+
+API GatewayがLambdaを呼び出すには、Lambda側で「API Gatewayが自分を呼び出してもよい」という権限を付与する必要があります。コンソールで統合を設定すると、この権限は自動的に追加されます。でもステージ変数を使うと、自動追加されないのです。
+
+なぜなら、コンソールが追加する権限は特定の関数名に対するものですが、`${stageVariables.env}`のような変数はまだ確定した値ではないからです。
+
+結局、各Lambda関数に手動で権限を追加する必要があります：
+
+```bash
+aws lambda add-permission \
+  --function-name my-function-dev \
+  --statement-id apigateway-dev \
+  --action lambda:InvokeFunction \
+  --principal apigateway.amazonaws.com \
+  --source-arn "arn:aws:execute-api:ap-northeast-2:123456789:api-id/*/GET/resource"
+```
+
+これをdev、staging、prodの各関数に対して実行する必要があります。
+
+## これでかなり時間を取られました
+
+公式ドキュメントには「ステージ変数でLambda関数を指定できます」とだけ書いてあり、権限を手動で追加しなければならないという説明は小さな注記にありました。資料を探しても、ちゃんとした説明があまり見つかりませんでした。
+
+エラーメッセージも直感的ではありませんでした。「Execution failed due to configuration error: Invalid permissions on Lambda function」と表示されるのですが、何をどう直せばいいのか分かりませんでした。
+
+結局CloudWatchのログを調べ、Stack Overflowを調べ、AWSフォーラムを調べて解決しました。
+
+## もう一つの方法 - Lambda Alias
+
+ステージ変数方式の他に、Lambda Aliasを使う方法もあります。
+
+一つのLambda関数に複数のバージョンをデプロイし、各バージョンにaliasを付けます：
+
+```
+my-function:dev
+my-function:staging
+my-function:prod
+```
+
+これなら関数を複数作る必要がなく、一つの関数で管理できます。デプロイもaliasを更新するだけなので、よりスッキリします。
+
+ただし、権限の問題は同じです。alias別に権限を個別に付与する必要があります。
+
+## 結論
+
+結局、核心は**権限設定**でした。機能自体はシンプルなのに、権限のせいで動かないのです。
+
+AWSを使っていて思うのですが、IAM権限が学習時間全体の半分は占めている気がします。サービス自体よりも「誰が誰を呼び出せるか」を設定する方が難しいです。
+
+でも成功したら達成感がありました。今はdevでテストしてprodにデプロイするパイプラインがきれいに動いています。
+
+資格取得時に勉強した内容が実戦で役立った最初のケースでした。やはり勉強は裏切らない...と信じたいです。

_posts/2021-03-15-aws-api-gateway-lambda-stages.md

@@ -0,0 +1,96 @@
+---
+layout: post
+title: "API Gateway 스테이지별 Lambda 함수 분리 - 삽질 끝에 성공한 이야기"
+date: 2021-03-15 09:00:00 +0900
+categories: [Development, DevOps]
+tags: [AWS, API Gateway, Lambda, 스테이지, 서버리스]
+author: "Kevin Park"
+lang: ko
+excerpt: "API Gateway에서 dev, staging, prod 스테이지별로 다른 Lambda 함수를 호출하고 싶었다. 공식 문서만 보고는 도저히 안 돼서 한참 삽질했다."
+---
+
+# API Gateway 스테이지별 Lambda 함수 분리
+
+## 하고 싶었던 것
+
+[AWS에 빠져서 공부하고](/2020/09/10/getting-into-aws/) [자격증까지 딴](/2020/12/15/aws-developer-certification/) 이후로 실전 프로젝트에 본격적으로 적용하기 시작했다.
+
+그러다 필요해진 게 API Gateway 스테이지별로 다른 Lambda 함수를 호출하는 것이었다. 개발(dev), 스테이징(staging), 운영(prod) 환경에서 각각 다른 함수를 호출해야 하는데, 이게 생각보다 쉽지 않았다.
+
+원하는 구조는 이랬다:
+
+```
+API Gateway
+├── dev 스테이지 → my-function-dev
+├── staging 스테이지 → my-function-staging
+└── prod 스테이지 → my-function-prod
+```
+
+## 처음 시도 - 스테이지 변수
+
+API Gateway에는 스테이지 변수(Stage Variables)라는 기능이 있다. 스테이지마다 다른 변수 값을 설정할 수 있는 건데, Lambda 함수 이름에 이 변수를 쓸 수 있다.
+
+Lambda 통합 설정에서 함수 이름을 이렇게 넣으면 된다:
+
+```
+my-function-${stageVariables.env}
+```
+
+그리고 각 스테이지에서 `env` 변수를 `dev`, `staging`, `prod`로 설정.
+
+여기까지는 공식 문서에도 나와 있다. 근데 이대로만 하면 작동을 안 한다.
+
+## 권한 문제
+
+작동 안 하는 이유는 Lambda 리소스 기반 정책(Resource-based Policy) 때문이다.
+
+API Gateway가 Lambda를 호출하려면 Lambda 쪽에서 "API Gateway가 나를 호출해도 된다"는 권한을 줘야 한다. 콘솔에서 통합을 설정하면 자동으로 이 권한이 추가되는데, 스테이지 변수를 쓰면 자동 추가가 안 된다.
+
+왜냐하면 콘솔이 추가하는 권한은 특정 함수 이름에 대한 권한인데, `${stageVariables.env}` 같은 변수는 아직 확정된 값이 아니니까.
+
+결국 수동으로 각 Lambda 함수에 권한을 추가해야 한다:
+
+```bash
+aws lambda add-permission \
+  --function-name my-function-dev \
+  --statement-id apigateway-dev \
+  --action lambda:InvokeFunction \
+  --principal apigateway.amazonaws.com \
+  --source-arn "arn:aws:execute-api:ap-northeast-2:123456789:api-id/*/GET/resource"
+```
+
+이걸 dev, staging, prod 함수 각각에 대해 실행해줘야 한다.
+
+## 이것 때문에 한참 헤맸다
+
+공식 문서에는 "스테이지 변수로 Lambda 함수를 지정할 수 있습니다" 라고만 되어 있고, 권한을 수동으로 추가해야 한다는 건 작은 글씨로 노트에 있었다. 자료를 찾아봐도 제대로 된 설명이 잘 없었다.
+
+에러 메시지도 직관적이지 않았다. "Execution failed due to configuration error: Invalid permissions on Lambda function" 이게 뜨는데 뭘 어떻게 고쳐야 하는지 감이 안 왔다.
+
+결국 CloudWatch 로그 뒤지고, Stack Overflow 뒤지고, AWS 포럼 뒤져서 해결했다.
+
+## 또 다른 방법 - Lambda Alias
+
+스테이지 변수 방식 말고 Lambda Alias를 쓰는 방법도 있다.
+
+하나의 Lambda 함수에 여러 버전을 배포하고, 각 버전에 alias를 붙인다:
+
+```
+my-function:dev
+my-function:staging
+my-function:prod
+```
+
+이러면 함수를 여러 개 만들 필요 없이 하나의 함수에서 관리할 수 있다. 배포도 alias만 업데이트하면 되니까 좀 더 깔끔하다.
+
+근데 이것도 권한 문제는 똑같이 있다. alias 별로 권한을 따로 줘야 한다.
+
+## 결론
+
+결국 핵심은 **권한 설정**이었다. 기능 자체는 간단한데 권한 때문에 안 되는 거다.
+
+AWS 쓰면서 느끼는 건데, IAM 권한이 전체 학습 시간의 절반은 차지하는 것 같다. 서비스 자체보다 "누가 누구를 호출할 수 있는지" 설정하는 게 더 어렵다.
+
+그래도 성공하고 나니 뿌듯하다. 이제 dev에서 테스트하고 prod로 배포하는 파이프라인이 깔끔하게 돌아간다.
+
+자격증 딸 때 공부한 내용이 실전에서 도움이 된 첫 번째 케이스였다. 역시 공부는 배신하지 않는다... 고 믿고 싶다.

_posts/2021-06-10-competitive-website-renewal-en.md

@@ -0,0 +1,51 @@
+---
+layout: post
+title: "Winning a Website Renewal Project Through Competitive Pitch"
+date: 2021-06-10 09:00:00 +0900
+categories: [Life, DevDiary]
+tags: [Freelance, Pitch, Website Renewal, Project, Developer]
+author: "Kevin Park"
+lang: en
+excerpt: "I won a website renewal project through a competitive pitch. Turns out writing proposals is harder than writing code."
+---
+
+# Winning a Website Renewal Through Competitive Pitch
+
+## The Competitive Pitch
+
+I landed a website renewal project through a competitive pitch.
+
+Smaller projects usually come through referrals, but bigger ones require a formal pitch process. Multiple vendors submit proposals, present their plans, and one gets selected.
+
+Honestly, these competitive pitches are exhausting. I'm confident in my coding, but writing proposals, creating presentation decks, and presenting — that's an entirely different skill set.
+
+## Proposals Are Harder Than Code
+
+Every time I write a proposal, I'm reminded: this is harder than coding.
+
+Code just needs to work. If the logic is right, you get results. But a proposal needs to *persuade* — explain *why* things should be done a certain way. The same feature gets completely different evaluations depending on how it's framed.
+
+As a developer, I want to present the technically optimal solution. But what clients want isn't technical excellence — it's "a site that helps our business." Bridging that gap is always the hard part.
+
+## What I Did Differently This Time
+
+I've lost competitive pitches before. Last time, I focused on technical specs. Didn't get selected.
+
+This time, I changed my approach:
+
+- Minimized technical talk, focused on business outcomes
+- Emphasized "what business value does this feature deliver"
+- Included competitor site analysis (this landed particularly well)
+- Presented projected post-renewal improvements with numbers
+
+When developers do planning, we tend to fixate on "how will we build this." But for clients, "what improves after it's built" matters more. This pitch really drove that lesson home.
+
+## After Winning
+
+Feels good to win the project, but now the real work begins.
+
+Everything I proposed in the pitch needs to actually get built. Looking back at the proposal, some parts feel like... I might have oversold a bit. But promises were made.
+
+When a developer handles planning, design, development, and maintenance solo, time management is everything. If I deliver this project well, it's another one for the portfolio. Time to buckle down.
+
+Though I can't help thinking — if I'd spent the proposal-writing time coding instead, I'd probably be halfway done already.

_posts/2021-06-10-competitive-website-renewal-ja.md

@@ -0,0 +1,51 @@
+---
+layout: post
+title: "競合プレゼンでサイトリニューアルプロジェクトを勝ち取った話"
+date: 2021-06-10 09:00:00 +0900
+categories: [Life, DevDiary]
+tags: [フリーランス, プレゼン, サイトリニューアル, プロジェクト, 開発者]
+author: "Kevin Park"
+lang: ja
+excerpt: "競合プレゼンでサイトリニューアルプロジェクトを獲得しました。企画書を書くのがコーディングより難しいことを改めて実感しました。"
+---
+
+# 競合プレゼンでサイトリニューアルを勝ち取る
+
+## 競合プレゼンとサイトリニューアル
+
+競合プレゼンを経て、サイトリニューアルプロジェクトを獲得しました。
+
+小さなプロジェクトは通常紹介で依頼が来るのですが、規模がある程度大きいプロジェクトは競合プレゼンが必要です。複数の業者が企画案を提出してプレゼンテーションを行い、その中から選定される方式です。
+
+正直、この競合プレゼンが一番大変です。コーディングには自信がありますが、企画書を書いてプレゼン資料を作って発表するのは、まったく別の領域です。
+
+## 企画書はコーディングより難しい
+
+企画書を書くたびに感じるのですが、コードを書くよりこちらの方が難しいです。
+
+コードは動けばいい。ロジックが正しければ結果が出ます。でも企画書は「なぜこうすべきなのか」を説得しなければなりません。同じ機能でも、どう見せるかによって評価がまったく変わります。
+
+開発者としては技術的に最善の方案を提示したいのですが、クライアントが求めているのは技術的な優秀性ではなく「自分のビジネスに役立つサイト」です。このギャップを埋めるのがいつも難しいです。
+
+## 今回変えたこと
+
+以前、競合プレゼンで負けたことがあります。その時は技術スペック中心で発表したのですが、選定されませんでした。
+
+今回はアプローチを変えました。
+
+- 技術の話は最小限にして、ビジネス効果を中心に発表
+- 「この機能を入れるとどんなビジネス価値があるか」を強調
+- 競合サイトの分析資料を含めた（これがかなり効果的でした）
+- リニューアル後の予想効果を数値で提示
+
+開発者が企画をすると、つい「どう作るか」に集中してしまいますが、クライアントにとっては「作ったら何が良くなるか」の方が重要です。この違いを今回はっきりと感じました。
+
+## 勝ち取ってみて
+
+プロジェクトを獲得できて嬉しいですが、これからが本当の仕事の始まりです。
+
+競合プレゼンで提案した内容を全部実装しなければなりません。企画書に書いた中には「これはちょっとやりすぎたかな...」と思うものもあります。でもすでに約束したので、やるしかありません。
+
+開発者が一人で企画、デザイン、開発、保守まで全部やるには、体力も大事ですが時間管理が核心です。今回のプロジェクトをうまく終えればポートフォリオに一つ追加されるので、頑張ってみようと思います。
+
+企画書を書いている時間にコーディングしていたら、もう半分はできていたんじゃないか...というのは秘密です。