돌미나리

매번 코드를 수정할 때마다 서버에 접속해서 git pull을 받고, 빌드를 다시 하고, 프로세스를 재시작하는 과정은 번거롭고 실수하기 쉽습니다. 이러한 반복 작업을 자동화하여 개발자가 오직 '코드'에만 집중할 수 있게 해주는 기술이 바로 CI/CD입니다.

오늘은 별도의 서버 설치 없이 GitHub에서 제공하는 강력한 자동화 도구인 GitHub Actions를 사용하여, 코드를 푸시하면 내 EC2 서버에 즉시 배포되는 환경을 만들어보겠습니다.

1. CI/CD란 무엇인가?

• CI (Continuous Integration): 지속적 통합. 개발자들이 작업한 코드를 자주 병합하고, 그때마다 자동으로 테스트와 빌드를 수행하여 코드의 품질을 검증하는 과정입니다.
• CD (Continuous Deployment): 지속적 배포. 검증된 코드를 실제 운영 서버에 자동으로 반영하는 과정입니다.

2. GitHub Actions의 핵심: Workflow 파일

GitHub Actions는 프로젝트 루트의 .github/workflows/ 디렉토리에 있는 YAML 파일을 통해 동작합니다.

2.1 배포 시나리오 (Workflow)

1. 개발자가 main 브랜치에 코드를 Push합니다.
2. GitHub Actions가 가상 환경을 실행하여 코드를 **빌드(Build)**합니다.
3. 빌드가 성공하면 SSH를 통해 내 EC2 서버에 접속합니다.
4. 서버에서 최신 코드를 받고 서비스를 재시작합니다.

3. 실전! 자동 배포 스크립트 작성하기

먼저 GitHub 저장소의 Settings > Secrets and variables > Actions에서 서버 접속 정보(IP, Username, SSH Key)를 등록해야 안전합니다.

3.1 deploy.yml 예시

name: Deploy to EC2

on:
  push:
    branches: [ main ] # main 브랜치에 푸시될 때 실행

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 저장소 코드 가져오기
        uses: actions/checkout@v3

      - name: SSH 접속 후 배포 명령 실행
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USERNAME }}
          key: ${{ secrets.EC2_SSH_KEY }}
          script: |
            cd /home/ubuntu/my-project
            git pull origin main
            npm install
            pm2 restart all # Node.js 서비스 재시작 예시

4. CI/CD 도입 시 얻게 되는 효과

• 빠른 피드백: 코드를 올리자마자 빌드 오류나 테스트 실패 여부를 알 수 있습니다.
• 배포 실수 방지: 수동으로 명령어를 입력하다 발생할 수 있는 오타나 누락을 원천 차단합니다.
• 생산성 향상: 배포에 소요되는 시간을 줄여 핵심 로직 개발에 더 많은 시간을 투자할 수 있습니다.
• 안정적인 릴리즈: 정해진 절차에 따라 기계적으로 배포되므로 서비스의 안정성이 높아집니다.

5. 실무 꿀팁: Slack/Discord 알림 연동

배포가 성공했는지 실패했는지 매번 GitHub 사이트에서 확인할 수는 없습니다. GitHub Actions에 알림 스텝을 추가하면 배포 결과를 실시간으로 메신저로 받아볼 수 있습니다.

6. 결론: 자동화는 선택이 아닌 필수입니다

스무 차례에 걸쳐 리눅스 서버 기초부터 보안, 모니터링, 그리고 자동 배포까지 달려왔습니다. CI/CD 구축은 이 모든 여정의 마침표이자, 진정한 엔지니어로 거듭나는 시작점입니다.

도메인을 구매하는 곳(가비아, 고대디 등)과 서버가 위치한 곳(AWS)이 다를 때, 초보 개발자들은 어떻게 이 둘을 연결해야 할지 막막해하곤 합니다. 단순히 IP만 연결할 수도 있지만, AWS의 Route 53을 활용하면 DNS 응답 속도가 빨라질 뿐만 아니라 SSL 인증서 발급이나 로드 밸런싱 연동이 훨씬 간편해집니다.

오늘은 외부에서 구매한 도메인을 AWS Route 53으로 가져와 내 EC2 서버와 연결하는 전 과정을 상세히 알아보겠습니다.

1. Route 53 호스팅 영역(Hosted Zone) 생성

먼저 AWS가 내 도메인 정보를 관리할 수 있도록 '방'을 만들어주어야 합니다.

1. AWS 콘솔에서 Route 53 서비스로 접속합니다.
2. [호스팅 영역 생성] 버튼을 클릭합니다.
3. 도메인 이름: 본인이 구매한 도메인(예: yumina-dev.com)을 입력합니다.
4. 유형: '퍼블릭 호스팅 영역'을 선택하고 생성을 완료합니다.

생성이 완료되면 NS(네임서버) 유형의 레코드 4개가 나타납니다. 이 주소들이 바로 외부 업체에 알려줘야 할 AWS의 주소입니다.

2. 외부 업체(가비아 등)에서 네임서버 변경하기

이제 도메인 구매 업체 사이트로 이동하여 "이 도메인의 관리 권한을 AWS에 넘기겠다"고 설정해야 합니다.

1. 가비아(또는 해당 업체) 로그인 후 **[도메인 관리] -> [네임서버 설정]**으로 이동합니다.
2. 기존에 적혀 있던 네임서버를 지우고, Route 53에서 확인한 4개의 NS 레코드를 차례대로 입력합니다.
   • 주의: 주소 끝에 있는 마침표(.)는 제외하고 입력해야 합니다.
3. 변경 내용을 저장합니다. (네임서버 정보가 전 세계로 전파되는 데는 최소 5분에서 최대 48시간이 소요될 수 있습니다.)

3. 레코드 생성을 통한 EC2 IP 연결 (A 레코드)

네임서버 연결이 끝났다면, 이제 도메인 주소를 입력했을 때 내 EC2 서버로 접속되도록 설정해야 합니다.

1. Route 53 호스팅 영역 안에서 **[레코드 생성]**을 누릅니다.
2. 레코드 이름: 비워두면 루트 도메인(example.com), www를 입력하면 www.example.com이 됩니다.
3. 레코드 유형: A - IPv4 주소 및 일부 AWS 리소스에 트래픽 라우팅을 선택합니다.
4. 값: 내 EC2 인스턴스의 탄력적 IP(Elastic IP) 주소를 입력합니다.

이제 잠시 후 브라우저에 도메인을 입력하면 내 서버의 페이지가 뜨는 것을 확인할 수 있습니다!

4. Route 53 활용의 장점: CNAME과 Alias

단순히 IP만 연결하는 것이 아니라, Route 53은 더 스마트한 기능을 제공합니다.

• CNAME 레코드: 도메인을 다른 도메인 이름으로 연결할 때 사용합니다. (예: blog.example.com을 tistory.com으로 연결)
• 별칭(Alias): AWS의 고유 기능으로, 로드 밸런서(ALB)나 CloudFront 같은 서비스의 주소가 바뀌더라도 Route 53이 알아서 추적하여 연결해 줍니다. 별도의 쿼리 비용이 들지 않아 경제적입니다.

5. 결론: 전문적인 도메인 관리의 시작

Route 53은 단순한 주소 연결 도구를 넘어, 전 세계 사용자에게 가장 빠른 경로로 서비스를 안내하는 길잡이 역할을 합니다. 가비아에서 네임서버를 한 번만 옮겨두면, 이후에는 AWS 콘솔 안에서 모든 네트워크 설정을 제어할 수 있어 관리 효율성이 극대화됩니다.

클라우드 서비스의 대명사인 AWS(Amazon Web Services)는 신규 가입자에게 12개월간 프리티어(Free Tier) 혜택을 제공합니다. 하지만 '무료'라는 말만 믿고 설정을 소홀히 했다가는 예상치 못한 과금 고지서를 받을 수 있습니다.

오늘은 내 소중한 지갑을 지키면서 AWS EC2 인스턴스를 스마트하게 운영하는 5가지 핵심 전략을 정리해 보겠습니다.

1. 프리티어 한도 정확히 이해하기

가장 먼저 내가 쓸 수 있는 자원의 양을 알아야 합니다. EC2 프리티어의 핵심 조건은 다음과 같습니다.

• 인스턴스 사용 시간: 매달 750시간 무료 (t2.micro 또는 t3.micro 기준).
• 저장 공간(EBS): 총 30GB까지 무료.
• 데이터 전송(Outbound): 인터넷으로 나가는 데이터 매달 100GB까지 무료.

2. 요금 폭탄 방지의 핵심: '결제 대시보드'와 '예산 알림'

과금을 방지하는 가장 강력한 방법은 미리 **알람(Alarm)**을 설정하는 것입니다.

2.1 Billing Alert 설정

1. AWS 콘솔에서 **[Billing & Cost Management]**로 이동합니다.
2. **[Billing preferences]**에서 'Receive Free Tier Usage Alerts'와 'Receive Billing Alerts'를 체크합니다.

2.2 AWS Budgets 활용

특정 금액(예: $1) 이상 요금이 발생할 기미가 보이면 내 이메일로 즉시 알림이 오도록 설정하세요.

• 설정 방법: [Budgets] -> [Create budget] -> [Cost budget] 선택 -> 한도 금액 설정 후 알림 수신 이메일 등록.

3. 리소스 관리의 기술: 쓰지 않는 자원 정리

의외로 많은 과금이 '인스턴스' 자체가 아닌 부수적인 자원에서 발생합니다.

• Elastic IP (탄력적 IP): 인스턴스에 연결되지 않은 채 할당만 되어 있는 고정 IP는 시간당 요금이 부과됩니다. 인스턴스를 삭제했다면 반드시 탄력적 IP도 '릴리스(Release)' 하세요.
• EBS 스냅샷: 백업을 위해 만든 스냅샷도 용량에 따라 비용이 발생합니다. 오래된 스냅샷은 주기적으로 정리하세요.
• 미사용 볼륨: 인스턴스를 삭제할 때 '종료 시 삭제' 옵션을 체크하지 않으면, 인스턴스는 사라져도 저장 장치(EBS)는 남아 계속 과금됩니다.

4. 인스턴스 유형 선택 시 주의사항

프리티어 대상은 보통 t2.micro (일부 지역은 t3.micro)입니다. 인스턴스를 생성할 때 반드시 아래와 같이 녹색으로 표시된 'Free tier eligible' 문구를 확인하세요. 실수로 다른 사양을 선택하면 생성 직후부터 요금이 발생합니다.

5. 보안 그룹(Security Group) 최적화로 트래픽 보호

악의적인 사용자가 내 서버에 무차별적인 요청을 보내 트래픽(Outbound Data Transfer)을 과도하게 발생시키면 이 또한 요금으로 이어집니다.

• 불필요한 포트 폐쇄: 앞서 배운 UFW 설정이나 AWS 보안 그룹 설정을 통해 꼭 필요한 포트만 개방하세요.
• IP 제한: 관리자 페이지나 특정 서비스는 화이트리스트 IP만 허용하여 불필요한 트래픽 낭비를 막으세요.

6. 결론: 클라우드 관리는 모니터링에서 시작됩니다

AWS 프리티어는 공부와 테스트를 위한 아주 좋은 환경이지만, 관리에 소홀하면 독이 될 수 있습니다. 매주 한 번은 Billing Dashboard에 접속하여 사용량을 체크하는 습관을 들이세요.