[소마] 프로젝트 7월 회고

7월 회고록

본격적으로 소마 프로젝트를 시작한 달이었기에, 이것저것 개발할게 많았던 7월이었다. 

 

집 밖에 거의 안나가고 하루종일 개발이랑 공부만 했었다....

 

팀에 합류했을 때는 백엔드 개발을 맡았었지만, 8월에 배포하기로 팀 내부적으로 합의를 해서

 

개발의 속도와 협업을 위해 인프라쪽을 메인으로 작업했었던 것 같다.

 

AWS 로고

아 그리고 AWS 사옥에서 3일동안 교육을 받았다.

 

센터필드 건물이 너무 좋아서 3일내내 꼭 여기서 일하고 싶다는 생각이 계속 들었다.

무엇을 했는가

7월엔 무엇을 했을까요?

AWS EKS 클러스터 구축

우리 팀은 인프라를 쿠버네티스로 관리하기로 결정했다.

 

관리상의 편의를 위해 AWS의 Managed k8s인 EKS를 사용하기로 했다.

 

쿠버네티스는 프로젝트 시작전에 사람들과 스터디도 하고 책을 사서 공부도 했지만 실제로 써본적은 처음이었다.

 

더군다나 EKS라는 환경에 대해서도 지식이 아예 없었기에 초반에는 정말 공부만 했던것 같다.

 

또, 인프라 관리를 Terraform으로 하기로 해서 러닝 커브가 더 가팔랐었다.

 

처음에는 콘솔을 통해 EKS를 생성해보며 구성요소들을 파악했고,

 

이후 클러스터를 완전히 삭제한 다음 테라폼으로 다시 작성했다.

 

아키텍쳐 구성도 그리는데에만 이틀이 걸린것 같다.

 

초기 아키텍쳐 구성도

 

VPC, Subnet과 같이 그동안 헷갈렸던 개념을 확실히 이해하는 계기가 되었다.

 

때 마침 AWS 측에서 소마 센터로 EKS 워크숍을 와서, 사전 질문지를 작성할 수 있었다.

 

모르는게 너무 많아서 막막했었다.

시간 관계상 다 물어보진 못했지만 어느정도 궁금증은 해결되었다!

 

이후로도 몇번의 멘토링을 받고, 개발환경 분리를 네임스페이스단이 아닌 클러스터 단위로 분리하기로 결정했다.

 

트러블 슈팅은 아래 포스팅에 담아두었다.

 

https://imsongkk.tistory.com/entry/AWS-EKS-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0-%EA%B5%AC%EC%84%B1-%EB%B0%8F-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0-12

AWS EKS 클러스터 구성 및 배포하기 [1/2]

 

Terraform

팀에 테라폼을 도입하기로 결정했다!

 

백엔드 개발자 2명이서 각자 백엔드와 인프라로 나뉘어져 작업을 해야했기 때문에 코드를 통한 인프라 관리가 필요했다.

 

코드로 남겨두면 나중에 다른 백엔드 개발자가 그 코드를 보고 현재 인프라의 구조를 이해할 수 있으며

 

코드 리뷰 해주기에도 편하다고 생각했다.

 

테라폼도 EKS와 마찬가지로 낯선 기술이었기 때문에 이해하는데 꽤나 고생했다...

 

최대한 dev와 prod 환경을 관리하기 편하게 하기 위해 모듈별로 Structure를 짰다.

 

리소스들을 module단위로 분리하였다.

 

모듈로 빼냈기에, 개발 환경에 따라 그에 맞는 환경 변수를 넣어주면 빠른 개발 환경 분리가 가능해졌다.

 

전체 코드는 아래에서 확인할 수 있다.

 

https://github.com/SWM-YouQuiz/Terraform

GitHub - SWM-YouQuiz/Terraform: Terraform manifest repository for AWS(Amazon Web Service)

 

처음에는 VPC도 어떻게 만드는지 몰라서 헤맸었지만, 지금은 가닥을 잡고 열심히 뚝딱뚝딱 하고 있다.

 

API 배포

프론트엔드와의 작업 속도를 맞추기 위해 API 서버의 배포가 필요했다.

 

처음부터 완벽하게 클러스터 환경을 구축하고 올리고 싶었으나, 일정이 안나올것 같아

 

Raw Manifest 파일로 EKS 내에 올렸다.

 

 

MSA 환경에서 각 서비스들을 정의할 Deploy 부터, Service, Secret 등을 하나의 파일에 몰아넣었고

 

그 서비스가 이용할 DB도 Statefulset으로 정의해 클러스터에 올렸다.

 

썩 마음에 들진 않았지만 그래도 프론트엔드 팀원이 성공적으로 API를 이용하는것을 보고 뿌듯했다.

 

Swagger 서버 구축

맨 처음에는 API Spec을 임시로 notion에 저장했었다.

 

하지만 가독성이 떨어졌었고 매번 수동으로 고쳐주니까 관리가 힘들었다.

 

따라서 Swagger 서버를 따로 구축해 각 서비스들의 API Spec을 실시간으로 한번에 볼 수 있게 했다.

 

처음에는 하루면 될 줄 알았는데, 생각보다 변수들이 많았어서 꽤나 오래걸렸었다...

 

이 친구도 따로 트러블 슈팅을 작성했다.

 

https://imsongkk.tistory.com/entry/MSA-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-Swagger-%EC%84%9C%EB%B2%84-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

MSA 환경에서 Swagger 서버 구축하기

 

확실히, 한 곳에서 모든 API를 실시간으로 볼 수 있어서 소통도 편해지고 개발에도 속도가 붙은 것 같다.

 

도입하길 잘 한것 같다.

Jenkins 도입

Jenkins는 이전 프로젝트에서 한번 써봤던 경험이 있었다.

 

하지만 그때는 EC2에 바이너리 형태로 설치했었고, 현재는 EKS 위에 설치를 했어야 했다.

 

크게 다르지 않을거라 생각했지만 생각보다 고려해야할 사항이 너무 많았다.

 

한 일주일은 고생했던 기억이 난다.

 

우리 팀은 Repo도 많고 관리해야 할 서비스도 많았기에 CI CD 자동화는 필수였다.

 

레퍼런스가 가장 많은 Jenkins를 채택했으며 프로젝트 CI 자동화 과정을 끝냈다.

 

CI Pipeline

Gihub Webhook을 이용해 빌드를 트리거 했으며, 

 

각 서비스 레포에 Jenkins pipeline을 정의한 Jenkinsfile과, Kaniko가 사용할 Dockerfile을 추가해줬다.

 

이후 빌드가 끝난 이미지는 AWS ECR에 적재했다.

 

트러블 슈팅은 무려 2편을 작성했다....

 

https://imsongkk.tistory.com/entry/AWS-EKS-Jenkins-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-12

AWS EKS Jenkins 환경 구축하기 [1/2]

디자인 외주

작업 인원과 금액을 고려하여, 외부 디자이너에게 UI와 UX, 로고등을 작업해 달라고 외주를 맡겼다.

 

와이어프레임은 이미 구성해두었기에 디자이너들에게 연락을 돌릴 때 공유했었다.

 

Figma

 

처음해보는 경험이었기에 어떤 점을 조심해야 하고, 확실히 해야하는지 헤맸었는데

 

멘토링과 이전 기수 연수생분들이 남겨놓은 기록을 참고하여 계약을 진행했다.

 

계약서

디자이너를 컨택할 때 중요하게 봤던순서는 포트폴리오 > 경력 > 금액 > 작업 기간 순이었다.

 

또한 우리 팀의 기획서를 끝까지 읽어보고 이해한 사람을 희망했다.

 

연락 돌렸던 양식

최종적으로 디자이너 2분과 계약을 진행했으며 한분은 UI, 한분은 앱 로고와 캐릭터 제작을 맡아주셨다.

 

무엇을 잘했는가

팀원

Jira 에 할당된 2번의 스프린트의 백로그들을 기한에 맞춰서 전부 소화했다!

 

프론트, 백엔드, 인프라로 역할을 나누어 최대한 프론트와 백엔드 간의 협업이 잘 이루어질 수 있도록 노력했었다.

 

개발에 시간을 온전히 쏟았다

 

방학도 했겠다 자취도 하겠다 개발에 신경을 쓸 시간이 많았다.

 

더군다가 낯선 기술들로 가득한 인프라 개발이었기에 더욱 시간을 많이 쏟아야 했다.

 

결과적으로는 목표했던 바를 이루었다.

팀장

프로젝트 활동비 관련 신청부터 결제 증빙까지 잘 처리했다.

 

여럿이서 관리하는것 보다는 한 사람이 책임지고 맡는것이 맞는것 같아,

 

팀장인 내가 맡겠다고 했는데 서류 작업들을 그래도 빼먹지 않고 잘 해결했다

 

멘토링 일정 같은 경우도 팀원들에게 잘 리마인드 시켜줬던 것 같다.

무엇이 아쉬웠는가

팀원

소마 센터에 잘 나가지 못했다. 아니 안했다가 맞는 표현인것 같다.

 

선릉까지는 1시간이라는 애매한 거리에 있지만 그래도 못갈 거리는 아니다.

 

대면 멘토링이나 팀끼리 대면 회의가 필요하면 그때는 갔지만 자발적으로 출근하진 않았다. 

 

초반에는 일정을 잘 지키지 못했다.

 

얼렁뚱땅 작업하고 싶지 않았기에 해당 기술에 대해 공부할 시간이 필요했다.

 

최대한 이 시간까지 포함해서 일정을 짰었지만 그래도 오차가 발생했다.

팀장

팀장으로서, 또 나이가 가장 많은 형으로서 책임을 다 하지 못한것 같아 아쉬웠다.

 

더 좋은 갈등 해결 방법과 소통 방식이 있었을텐데 하고 아쉬워했다.

 

그래도 지금은 이전보다 서로를 이해하며 열심히 개발하고 있어서 만족한다