Site Search

Amplify를 사용해 보았습니다.

안녕하세요. 이번 기사에서는 AWS Amplify를 활용한 Next.js의 SSR(서버사이드 렌더링) 개발 도입 및 운영에 대해 실제 프로젝트 경험을 기반으로 설명하겠습니다. Next.js 13 이후 추가된 App Router와 SSR 개발을 용이하게 하는 기능들, 그리고 Amplify가 제공하는 편리함을 백엔드와 프론트엔드 관점에서 어떻게 활용했는지 구체적으로 소개합니다. 각 프로세스에서 얻은 교훈과 과제를 공유하여 독자 여러분의 개발에 도움이 되는 정보를 제공하고자 합니다. Next.js나 Amplify를 처음 사용하는 분들, 혹은 이미 활용 중인 분들에게도 유익한 내용이 될 것이라 확신합니다.
 
 

전체

SSR이 필요했던 이유

 
저희가 Next.js를 처음 도입한 것은 버전 11 때였으며, 당시 CSR(클라이언트 사이드 렌더링)을 활용한 웹사이트 제작을 진행했습니다. SSG(정적 사이트 생성)로 빌드하는 것은 비교적 쉬웠지만, CI/CD나 SEO 관련 문제로 어려움을 겪은 적이 있었습니다.
 
 

이러한 상황에서 Next.js 13 이후에는 App Router와 SSR 개발을 용이하게 하는 새로운 기능들이 추가되었고, AWS Amplify가 SSR을 지원하는 호스팅을 제공하게 되었습니다. 새로운 사내 서비스를 제작하면서 Next.js를 선택하게 되었고, 팀 내에 SSR 지식을 축적할 필요성이 있다고 판단하여 SSR을 도입하기로 결정했습니다.
 
 

초기에는 SSR 호스팅 서비스로 Vercel이 주류였지만, AWS Amplify가 Next.js 기반의 SSR 구현을 쉽게 할 수 있다는 것을 알게 되어 Amplify를 활용한 SSR 웹사이트 제작에 도전하게 되었습니다.

  

백엔드

Amplify를 사용하게 된 과정과 절차

AWS Amplify에서 새로운 리포지토리를 생성할 때 “새로운 리포지토리 생성”을 선택합니다. 이후 소스 코드를 저장할 플랫폼을 선택하라는 안내가 표시되며, 이때 CodeCommit을 선택했습니다. 선택 이유는 다음과 같습니다.

  

  • 회사가 사용하는 GitLab이 엔터프라이즈 버전이기 때문입니다. 엔터프라이즈 버전에서는 URL이 일반 GitLab과 다릅니다. 더불어 AWS Amplify는 기존 GitLab URL 변경을 지원하지 않습니다.
  • 이에 따라 Jenkins를 사용하여 GitLab 리포지토리를 복제한 뒤, 이를 CodeCommit에 동기화하여 푸시하는 방식을 채택했습니다.
  • CodeCommit을 이용함으로써 AWS 상에서 일관된 관리를 할 수 있었고, 다른 리포지토리 혼재로 인한 리스크를 회피할 수 있었습니다.
  • 최종적으로 GitHub로 이관하면서 초기 문제가 해결되어 현재는 이런 방식을 사용하지 않고 있습니다.
  •   

    아래 이미지와 같이 Amplify를 생성했습니다. 프론트엔드 관련 요청이 있을 경우, Amplify Hosting의 빌드 설정에서 amplify.yml 파일을 수정하여 적용해야 합니다.
     
    Create App 방법
    프로젝트를 저장하고 있는 플랫폼을 선택합니다.

      

    이후 이름과 브랜치를 설정합니다.

      

    앱의 빌드 설정을 확인합니다.

      

    Hosting 설정
    App 생성하면 기본적으로 AWS에서 제공하는 도메인이 생성됩니다. 필요 시 추가적인 호스팅 설정도 가능합니다.
     
     
    Route53에 등록된 도메인 중 하나를 선택합니다.
    도메인이 없는 경우, お名前.com 등에서 구매 후 Route53에 등록합니다.

      

    브랜치에 따라 도메인을 설정하는 것도 가능합니다.

      

      

    도메인을 추가한 후, DNS 레코드를 확인하여 해당 레코드를 Route53에 등록하면 설정이 완료됩니다.

      

    위와 같이 설정하면 Amplify 구성이 완료됩니다.

      

    Amplify 사용 소감

    AWS Amplify는 백엔드 개발자가 없어도 서버리스 환경을 구축할 수 있는 강력한 도구라고 느꼈습니다. 하지만, 데이터 구조가 복잡해지거나 트래픽이 증가하는 경우 유연하게 대응할 수 있는 백엔드 개발자가 필요할 수 있다고 느꼈습니다.
     
     

    프론트엔드

    Amplify 활용 방식

    App-hub 프로젝트에서 AWS Amplify를 활용하여 프론트엔드 개발을 진행했습니다. 백엔드 팀에서 Amplify 환경 설정 및 배포를 담당했기 때문에 제가 직접 환경 설정에 관여하지는 않았지만, Amplify로 구성된 환경에서 다음과 같은 작업을 진행했습니다:

      

    호스팅 환경에서의 테스트
    Amplify의 자동화된 배포 파이프라인을 통해 스테이징 및 프로덕션 환경에서 실시간으로 작업 결과를 확인하며 테스트를 진행하려 했습니다. 그러나, 현재 사내에서 사용하는 GitLab은 내부 전용이라 연동이 어려웠고, CodeCommit은 현재 권한이 없었습니다. 따라서 Git에 코드를 푸시한 후, Jenkins를 통해 CodeCommit으로 배포하면 Amplify가 자동으로 CodeCommit의 코드를 배포하는 방식을 사용했습니다. 하지만, 향후 GitHub로 코드 관리를 이전하여 Amplify와 연동하면 푸시만으로 즉시 배포 및 테스트가 가능해질 예정입니다.
     
    (CodeCommit은 2024년 7월 서비스 종료)
     
     

    Amplify를 사용해 본 소감

    AWS Amplify는 프론트엔드와 백엔드의 연동 작업을 매우 간단하고 효율적으로 만들어 주는 도구로 강력하다고 느꼈습니다. 특히 Amplify의 주요 기능을 활용하며 다음과 같은 장점을 경험했습니다:
     
     
    1.생산성 향상
    다른 도구에 비해 백엔드 설정이나 복잡한 배포 과정을 신경 쓰지 않아도 되어 프론트엔드 개발에 더 많은 시간을 할애할 수 있었습니다.
      

    2.자동화된 배포
    Amplify가 제공하는 CI/CD 파이프라인은 배포 과정을 단순화하고 환경 설정 및 오류를 최소화하는 데 기여했습니다. 코드 푸시만으로 빠르게 결과를 확인할 수 있어 매우 효율적이었습니다.
     
     
    3.문서와 커뮤니티
    Amplify의 문서는 매우 잘 정리되어 있어 기능 사용법을 빠르게 습득할 수 있었습니다. 또한, 커뮤니티에서도 다양한 문제 해결 방법을 찾을 수 있었습니다. 덕분에 초보자나 팀 협업에도 적합한 도구라고 느꼈습니다.
     
     

    요약

    AWS Amplify와 Next.js를 결합한 SSR 개발은 효율적인 개발 프로세스와 유연한 환경 구축을 가능하게 하는 강력한 선택지라는 것을 알게 되었습니다.
     
     
    하지만 복잡한 데이터 구조나 고부하 트래픽에 대해서는 더 고도화된 백엔드 개발 대응이 필요하다는 점도 느꼈습니다. AWS Amplify의 간단함과 확장성을 최대한 활용하면서, 앞으로의 과제를 대비한 기술력을 더욱 강화해 나가는 것이 중요합니다.

     

    이 기사를 통해 Amplify나 SSR 개발에 관심 있는 분들에게 도움이 되기를 바랍니다.

    Category

    Tag