alt text

단순한 GitHub 링크 버튼 하나, AWS Parameter Store까지 사용한이유

최근 게시물 상세 페이지에 '좋아요' 기능을 성공적으로 추가하였고, 이어서 나를 표현할 수 있는 작은 버튼 하나를 더 추가해보기로 했다. 바로 내 GitHub 프로필로 연결되는 링크 버튼이다.

처음에는 아주 간단한 작업이라고 생각했다. 아이콘 하나 추가하고, <a> 태그로 내 GitHub 주소를 하드코딩하면 끝날 일이었다.

"하지만 깃허브 URL을 코드에 그냥 넣는 게 최선일까?"

하드코딩의 달콤한 유혹과 불편한 미래

개발을 진행하다 보면 누구나 한 번쯤 겪어봤을 유혹이다. 지금 당장은 가장 빠르고 쉬운 방법. 하지만 이 작은 습관이 미래에 어떤 불편함을 가져올지 상상해봤다.

유연성 부족: 만약 미래에 내 GitHub 사용자 이름이 바뀐다면? 혹은 다른 SNS 링크로 교체하고 싶어진다면? 그때마다 나는 코드 저장소를 열고, PostUtilButtons.tsx 파일을 찾아 URL을 수정한 뒤, 프론트엔드 프로젝트 전체를 다시 빌드하고 배포해야 한다.
관리의 분산: 지금은 URL 하나지만, 나중에 Google Analytics ID, 광고 스크립트 키 등 관리해야 할 설정 값들이 늘어난다면? 이 값들이 코드 여러 곳에 흩어져 있다면 관리는 재앙이 될 것이다.
나쁜 습관: 무엇보다, '이 정도는 괜찮겠지'라는 안일한 생각이 쌓여 결국 유지보수하기 어려운 코드를 만들게 된다.

이 작은 버튼 하나가 앞으로 만들어갈 내 블로그 시스템 전체의 좋은 선례가 되어야 한다고 생각했다. 그래서 "설정(Configuration)은 코드와 분리한다" 는 원칙을 적용하기로 결심했다.

해결책: AWS Systems Manager Parameter Store

그래서 내가 선택한 도구는 AWS Systems Manager Parameter Store다. 이름은 거창하지만, 본질은 매우 간단하다. **애플리케이션에서 사용할 설정 값들을 안전하고 체계적으로 보관하는 '중앙 설정 보관소'**다.

왜 Parameter Store인가?

런타임 성능 저하가 없다: 가장 큰 우려였다. "설정 값을 외부에서 읽어오면 API 응답이 느려지지 않을까?" 하지만 Parameter Store는 람다 함수가 실행될 때마다 매번 호출되는 것이 아니다. 인프라를 배포하는 시점(cdk deploy)에 딱 한 번만 값을 읽어와서, 람다 함수의 환경 변수로 구워준다. 따라서 사용자가 느끼는 성능 저하는 전혀 없다.
중앙 관리: 모든 설정 값을 한곳에서 관리할 수 있다. URL이 바뀌면 AWS 콘솔에 접속해서 값만 수정하면 끝이다. 코드 변경도, 재배포도 필요 없다.
미래를 위한 확장성: 지금은 GitHub URL 하나지만, 앞으로 추가될 모든 설정 값들을 위한 훌륭한 보금자리를 미리 마련해두는 셈이다.

구현 과정 A to Z

1단계: Parameter Store에 URL 저장하기

먼저 AWS 콘솔에 접속해 내 GitHub URL을 '파라미터'로 생성했다. 이때, 나중에 관리하기 쉽도록 /를 사용한 계층형 이름 규칙을 사용했다.

이름: /new-blog/frontend/github-url
유형: 문자열
값: https://github.com/jungyuya

alt text

2단계: CDK 코드에서 파라미터 값 불러오기

다음으로, AWS CDK 코드(apps/infra/lib/InfraStack.ts)가 배포 시점에 이 값을 읽어올 수 있도록 수정했다.

// apps/infra/lib/InfraStack.ts

// 1. ssm 모듈 import
import * as ssm from 'aws-cdk-lib/aws-ssm';

// ...

// 2. FrontendServerLambda를 정의하기 전에 파라미터 값을 읽어온다.
const githubUrlParameter = ssm.StringParameter.valueForStringParameter(
  this,
  '/new-blog/frontend/github-url' // 위에서 생성한 파라미터 이름
);

// 3. 람다 함수의 환경 변수로 주입한다.
const serverLambda = new lambda.DockerImageFunction(this, 'FrontendServerLambda', {
  // ...
  environment: {
    // ... 기존 환경 변수들 ...
    NEXT_PUBLIC_GITHUB_URL: githubUrlParameter, // 하드코딩 대신 변수를 사용
  },
});

ssm.StringParameter.valueForStringParameter는 CDK가 배포될 때 AWS에 "이 이름의 파라미터 값 좀 알려줘"라고 요청하고, 그 응답 값을 githubUrlParameter 변수에 담아주는 마법 같은 코드다.

3단계: 프론트엔드에서 환경 변수 사용하기

이제 모든 준비가 끝났다. 프론트엔드에서는 이 값을 평범한 환경 변수처럼 사용하기만 하면 된다.

먼저, 로컬 개발 환경을 위해 .env.local 파일에도 동일한 변수를 추가해준다.

# apps/frontend/.env.local
NEXT_PUBLIC_GITHUB_URL=https://github.com/jungyuya

그리고 PostUtilButtons.tsx 컴포넌트에서 이 값을 읽어와 <a> 태그에 연결했다.

// apps/frontend/src/components/PostUtilButtons.tsx

// 1. 환경 변수 읽기
const githubUrl = process.env.NEXT_PUBLIC_GITHUB_URL;

// 2. JSX에서 버튼 렌더링
{githubUrl && (
    <a
        href={githubUrl}
        target="_blank"
        rel="noopener noreferrer"
        className="p-2 rounded-full text-gray-500 hover:bg-gray-100 ..."
        aria-label="Visit my GitHub profile"
    >
        <GitHubIcon />
    </a>
)}

NEXT_PUBLIC_ 접두사는 Next.js가 이 환경 변수를 브라우저에서도 접근 가능하도록 만들어주는 중요한 규칙이다.

결론: 좋은 습관이 좋은 시스템을 만든다

단순한 버튼 하나를 추가하는 작업이었지만, "어떻게 하면 더 유연하고, 더 관리하기 쉬운 시스템을 만들 수 있을까?"라는 고민을 통해 AWS Parameter Store라는 훌륭한 도구를 내 프로젝트에 도입하게 되었다.

이번 경험을 통해, 당장의 빠른 길보다 조금 돌아가더라도 올바른 원칙을 지키며 좋은 습관을 만드는 것이 결국 미래의 나를 편하게 해준다는 사실을 다시 한번 깨달았다. 이 작은 버튼이 앞으로 내 블로그를 더욱 견고하게 만들어줄 튼튼한 주춧돌이 되리라 믿는다.

Github Link 버튼 추가 회고록