🔍리뷰미가 뭐예요?

(광고) 리뷰미를 통해 함께 일한 동료로부터 피드백을 받아보세요!

리뷰미 바로가기

리뷰미는 우테코 레벨 3, 4 프로젝트 기간 동안 피땀 흘려 열심히 기획하고 개발한 서비스이다. 동료로부터 피드백을 받아 자신이 어떤 개발자인지 파악하고, 표현하는 데 도움을 주는 서비스이다.

🤔 나는 무엇을 잘하는 개발자일까?
📚 어떤 점을 보완하면 내가 더 성장할 수 있을까?
🫂 우리 팀원은 나를 어떻게 생각할까?

개발자라면 한 번쯤은 이런 고민들을 했을 것이다!
우테코에서는 크루들끼리 서로 피드백 해주는 문화가 활성화되어 있는데, 피드백을 통해 성장하는 데 도움이 되었다. 이 경험을 살려 위의 질문들에 답하는 데 도움을 주고자 리뷰미가 세상에 나오게 되었다.

이관하게 된 배경

우테코에서는 레벨 3부터 수료할 때까지 AWS 리소스를 제공해준다. 리뷰미 프론트엔드는 AWS CodeBuild와 CodePipeline으로 CD를 구축했고, S3와 Cloudfront를 사용해 배포했다.

하지만 수료식과 동시에 AWS 지원이 끊어지기 때문에 서비스를 계속 유지하기 위해서는 인프라를 이관해야 했다. 레벨 5 기간 동안 두 차례 인프라 회의를 통해 어디로 이관할지와 어떤 서비스를 사용할지 세부 전략을 세웠다.

인프라 선정 기준
1. 비용의 대부분은 서버에서 발생하기 때문에 백엔드 팀원들의 의견을 더 듣는다.
2. 비용 부담은 최소화한다.

Microsoft Azure, Amazon AWS, Naver Cloud, Oracle Cloud 등 여러 후보가 있었다. 그 중 무료 요금제로 4대의 인스턴스를 제공하고 객체 스토리지도 제공하는 Oracle cloud로 결정했다. 관련 자료가 많지 않다는 점이 걸렸지만, 우선은 백엔드와 프론트엔드 모두 오라클 클라우드로 이관하기로 했다.

OCI(Oracle Cloud Infrastructure)는 기존에 사용하던 AWS와 사용하는 용어가 많이 달랐지만, CodePipeline이나 CodeBuild 등과 대응하는 서비스들은 모두 제공하고 있었다.

OCI, 순탄하지 않았다

OCI를 사용해 보면서 삽질을 통해 많은 공부가 되었다.

가장 먼저 어떤 것을 이관할 것인지 정리했다.

스토리지: AWS S3 → OCI Object Storage
CDN: Cloudflare
CI: 기존의 GitHub Actions 유지
CD: AWS CodeBuild, CodePipeline → OCI DevOps

OCI에도 AWS S3와 유사한 객체 스토리지를 제공하고 있었다. CDN의 경우엔 OCI에서 자체적으로 제공하지 않기 때문에 외부 서비스인 Cloudflare를 사용하기로 했다. 이는 관련 자료를 발견했기 때문에 결정할 수 있었다.
CI는 기존의 방식을 유지하고, CD는 빌드부터 파이프라인까지 한 번에 관리할 수 있는 OCI의 DevOps 서비스를 사용하기로 했다.

OCI DevOps 도전하기

DevOps 프로젝트를 생성한 뒤에, 리뷰미 레포지토리를 연동하려 했다. DevOps 메뉴 중 Code Repository와 External Connection를 사용해 보았다.

Code Repository에서는 HTTPS 방식이나 SSH 방식으로 레포지토리 클론이 가능했다. 이 과정에서 SSH 키를 생성하고, OCI에 공개 키를 저장해두고 config 파일도 만들어보았다. 뭔가 이상했다. 깃허브 레포지토리를 클론하는 것으로 이해했는데 안내해주는 Git 명령어는 그렇지 않았다.

공식문서를 자세히 읽어보면서 Code Repository에 대해 찾아보았더니, 해당 서비스는 깃허브 레포지토리 연동이 아니라 DevOps 전용 Git 레포지토리를 만드는 것이었다.

다음으로는 External Connection로 외부(깃허브) 레포지토리를 연동하려 했다. 이를 위해서는 OCI에 깃허브 PAT를 담은 Secret을 만들어서 validate하는 과정이 필요했다. 하지만 리뷰미 레포지토리는 우테코의 Organization 하위에 있었기 때문에 내 개인 계정에서 발급한 PAT로는 인증하지 못했다.

추측하기로는 우테코 계정에서 PAT를 생성해서 공유해주어야 하는데, 현실적으로 이는 불가능했다.

DevOps 없이 CD 구축하기

백엔드 팀원 아루의 도움을 받아 우테코 계정의 권한을 사용하지 않는 방식으로 우회하는 방법을 생각해냈다.

OCI Object Storage에서는 정적 웹 사이트 호스팅 서비스인 OCI API Gateway를 제공하고 있다. 여기에 GitHub Actions와 OCI CLI를 함께 사용하는 접근 방식이다.

구체적인 흐름은 다음과 같다.

1. GitHub Actions Workflow 설정
- 특정 브랜치에 머지되면 작동하도록
2. OCI CLI 설치 및 인증 설정
- OCI Auth Token을 발급받고, 이를 사용해서 CLI에 접근할 수 있도록
3. 소스 빌드
- GitHub Actions에서 프로젝트 빌드
4. Object Storage에 업로드
- 빌드 결과물을 CLI를 통해 OCI Object Storage에 업로드
5. API Gateway 서비스를 통해 호스팅

이렇게 되면 PAT를 발급받지 않고도 CD를 구축할 수 있게 된다.

OCI Docs에 가이드가 있어 참고해서 API Gateway를 설정했지만 다음과 같은 오류를 마주했다.

배포를 생성할 때 설정을 잘못했는지, 혹은 접근 권한이 없어서 그런지는 파악하지 못했다. 문제를 해결하려 했지만 시간은 어느덧 수료식 전날이 되었다.

당장 다음 날이면 지원이 종료되어 서비스를 사용할 수 없게 될 텐데, 아직 OCI로 이관된 것이 없었다.

사용자들이 끊김없이 서비스를 사용하는 것이 가장 중요했기 때문에 우선은 빠르게 배포할 수 있는 서비스로 임시 이관하기로 했다.

Cloudflare Pages로 정착

Cloudflare Pages는 정적 웹사이트를 손쉽게 배포하고 호스팅할 수 있는 플랫폼이다. GitHub와 연동해서 코드가 변경되면 자동으로 빌드하고 배포해주기 때문에 별도로 CD를 구축할 필요가 없다. 글로벌 CDN을 통해 배포하기 때문에 AWS의 Cloudfront를 대체할 수 있다.

다른 사이드 프로젝트에서 Cloudflare Pages를 사용해서 배포하고 있는데, 굉장히 쉬워서 사용하기로 했다. 그리고 무료 요금제는 월 500번까지 무료로 빌드할 수 있는데, 현재 우리 서비스는 그 정도로도 충분했다.

간단하게 target branch, 환경 변수 등만 설정해주면 되기 때문에 빠르게 배포할 수 있다.

현재 develop과 release 두 가지로 배포되고 있는 모습이다.

급한 불을 끄기 위해 임시로 선택했던 Cloudflare Pages였지만, 사실 기본적으로 제공하는 기능만으로도 충분했다.

Cloudflare Pages를 사용하면서 AWS에서 사용하는 기능들을 완전히 이관할 수 있었다.

• AWS S3 스토리지는 Cloudflare Pages 전용 스토리지로 대체되었다.
• Cloudfront는 Cloudflare Global Network로 대체되어 전세계에 배포된다.
• AWS CodeBuild, CodePipeline은 Cloudflare Pages의 빌드 서비스로 대체되었다.

그밖에 캐시나 SSL 인증 등을 모두 지원하기 때문에 우리 서비스를 배포하는 데 문제가 없다고 판단했다. 또한, OCI의 API Gateway는 무료 요금제여도 월 3달러의 요금이 부과된다. 최대한 비용을 아끼는 방향으로 작업하기로 했기 때문에 Cloudflare Pages도 괜찮은 선택지였다. 처음에는 OCI로의 최종 이관을 목표로 했다가, 팀원들과의 상의를 통해 Cloudflare Pages에 정착하는 것으로 결정했다.

추후에 Cloudflare Pages에서 지원하지 않는 기능을 필요로 하거나, 배포할 때 세밀한 설정이 필요한 경우에는 다른 방법을 다시 고려할 것 같다.

마치며

OCI는 결국 사용되지 않았지만 직접 몸으로 부딪혀 보면서 얻어가는 것이 분명 있었다. 인프라를 구축하는 방법은 여러 가지가 될 수 있고, 상황에 따라 사용할 수 있는 자원들을 잘 조합해야겠다는 것. 유연한 사고가 중요하다는 것을 다시끔 깨달았다🫠

리뷰미 인프라 이관 끝!