배포 워크플로우 개선하기
GitHub Actions 중복 제거와 SSH Deploy Key 도입기
들어가며
이전 글에서 Vinxi를 사용해 백오피스에 gRPC를 도입했고, AWS Lambda로 배포까지 성공했어요. 하지만 프로젝트가 늘어나면서 각 프로젝트가 비슷한 배포 워크플로우를 복사-붙여넣기하고 있었고, Private repository 접근을 위한 PAT 관리도 점점 부담스러워졌습니다. 이번 글에서는 이런 문제들을 GitHub Actions의 Reusable Workflows와 SSH Deploy Key로 해결한 경험을 공유하려고 해요.
기존 문제점
1. 코드 중복 문제
기존 workflow 파일들은 같은 내용이 여러 파일에 중복되어 작성되어 있었어요. 프로젝트마다 비슷한 배포 로직을 복사-붙여넣기하다 보니 유지보수가 어려웠습니다.
2. PAT의 한계
Private repository 접근을 위해 Personal Access Token(PAT)을 사용하고 있었는데, 개인 계정에 종속적이라 팀원이 퇴사하면 문제가 생기고, 권한 범위나 만료기간 관리도 어려워서 보안상 위험했어요.
개선사항
Reusable Workflows
GitHub Actions의 workflow_call 기능을 사용하면 하나의 워크플로우를 다른 워크플로우에서 호출할 수 있어요. 공통된 배포 로직을 중앙화하고, 호출하는 쪽에서는 프로젝트명이나 환경 같은 필요한 값들을 파라미터로 넘겨줍니다.
워크플로우 구조:
lambda.yml (핵심 배포 로직)
├── lambda-deploy-manual.yml (수동 배포)
└── lambda-deploy-on-push.yml (자동 배포)
재사용 가능한 워크플로우 정의 (lambda.yml):
# lambda.yml - 핵심 배포 로직
on:
workflow_call:
inputs:
name:
required: true
type: string
description: "배포할 패키지 이름"
environment:
required: true
type: string
description: "배포 환경 (dev/stg/prod)"
...
워크플로우 호출 예시 (lambda-deploy-manual.yml):
# lambda-deploy-manual.yml - 수동 배포
jobs:
call-deploy-workflow:
uses: ./.github/workflows/lambda.yml
with:
name: ${{ github.event.inputs.name }}
environment: ${{ github.event.inputs.environment }}
secrets: inherit # 부모 워크플로우의 secrets 상속
Reusable Workflows 도입으로 기존에 각 프로젝트마다 복사-붙여넣기하던 코드를 공통 워크플로우로 통합할 수 있었어요. 이제 배포 로직을 수정할 때 한 곳만 변경하면 모든 Lambda 함수에 자동으로 적용되어 유지보수 시간이 크게 단축되었고, 환경별 IAM 역할도 자동으로 매핑되어 잘못된 계정에 배포하는 실수를 방지할 수 있게 되었습니다!
SSH Deploy Key 도입
Personal Access Token(PAT)의 한계를 극복하기 위해 SSH Deploy Key로 전환했어요.
PAT vs SSH Deploy Key 비교:
| 구분 | PAT | SSH Deploy Key |
|---|---|---|
| 권한 범위 | 계정 전체 | Repository 단위 |
| 소유자 | 개인 계정 | Organization |
| 만료 기간 | 주기적 갱신 필요 | 영구적 |
| 권한 세분화 | 제한적 | 읽기/쓰기 구분 가능 |
구현 예시:
# 여러 private repository에 동시 접근
- uses: webfactory/[email protected]
with:
ssh-private-key: |
${{ secrets.SSHKEY_FOR_USER_SERVICE }}
${{ secrets.SSHKEY_FOR_PAYMENT_SERVICE }}
${{ secrets.SSHKEY_FOR_AUTH_INTERFACE }}
# ... 각 서비스별 deploy key
SSH Deploy Key 전환으로 개인 계정에 종속되지 않는 안정적인 배포 시스템을 구축할 수 있게 되었습니다. 각 repository별로 독립적인 SSH key를 사용하여 필요한 최소 권한만 부여할 수 있게 되었고, PAT처럼 주기적으로 만료되지 않아 관리 부담도 크게 줄었습니다. 특히 팀원이 퇴사하더라도 배포 시스템에 영향을 주지 않아 운영 안정성이 크게 향상되었어요.
마무리
처음에는 단순히 반복되는 Lambda 배포 작업을 줄이고 싶었는데, GitHub Actions의 Reusable Workflows를 도입하면서 팀 전체의 배포 프로세스를 체계화할 수 있었어요.
앞으로도 이런 방식으로 다른 배포 파이프라인들도 점진적으로 개선해나갈 예정이에요. 혹시 비슷한 고민을 하고 계신 분들께 도움이 되었으면 좋겠습니다!