프로젝트 소개
Hello, GSM이란?
기존에 복잡했던 입학 지원 과정을 온라인 웹사이트를 통해 간편하게 할 수 있도록 개발한 웹 서비스입니다.
hellogsm에 대한 간략한 소개는 https://about.hellogsm.kr 에서 보실 수 있습니다.
멤버
- 개발 팀의 숫자만 세자면 프론트엔드 2명, 백엔드 3명, 디자인 1명으로 진행하였습니다.
- 백엔드를 구분하자면 메인 개발, DBA, Ops. 이렇게 나눌 수 있겠네요.
진행기간
- 약 6개월 (4월 ~ 10월 중순)
어쩌다가 이 프로젝트에 참여하게 됐을까?
Hello, Gsm프로젝트를 하자라고 이야기가 나왔을때가 3월 말이였다. 당시 필자는 지방 기능대회때문에 바빴던 시즌이기에 참여하지 않을려고하였지만 테스트는 5월달부터 진행될 것 같고 DevOps Chapter을 맡으신 선배도 합류하신다길래 '이 선배한테 빨대꽂고 많이 배워야겠다' 라는 생각으로 프로젝트에 합류하게되었다.
(아니 이렇게 길어질줄은 몰랐죠)
본격적인 프로젝트 시작
4월부터 날마다 일일 스크럼 회의를 진행하였다. (이런식으로 팀 노션에 모든 내용들이 기록되어있다.)
당시 나는 DevOps 파트(사실상 Ops 파트)로 프로젝트를 진행해본 경험이 거의 없다시피하였기 때문에 날마다 배포 관련 공부, Docker 공부 이런식으로 구체적인 내용보단 두루뭉실한 내용들을 어제 하였고, 오늘 할 것이다. 라고 이야기하였다.
(저렇게 두리뭉실하게 말하고 엄청 하지도 않았음. 진짜 왜 그랬지)
그렇게 날마다 Ops를 공부하고, Hello,Gsm의 백엔드 스택인 NestJS를 공부하고,스크럼 회의를 하던 와중 새로운 백엔드 애들이 올해 말이나 내년에 합류할 것 이다라는 소리도 있어서 Spring 강의도 사서 공부를 하였다.
으악 스프링 싫어
새로 합류할 예정인 친구들이 모두 스프링을 공부하기 때문에 나중에 원활한 프로젝트 진행을 위해 스프링을 미리 공부하였다. 한 달 정도 공부했었던 것 같은데 자바의 그 특유의 그런 것들이 나랑 너무나도 맞지 않았고, AWS, Docker 등의 Ops랑 연계하기 너무 무겁다? 라는 생각이 들었다.
그러던 와중 서울에서 여러 개발자를 만나고 오신 선배가 Django+Ops 도 할 줄 알면 되게괜찮더라 라는 말씀을 해주셨다.
그 말을 듣고 '아 어차피 Ops를 위주로 공부하면서 기능대회를 준비할거 백엔드는 내가 하고 싶고, 잘 맞는 스택을 골라서 하면되지 않을까?' 라는 생각이 들어 예전에 배웠었고, 하면서 굉장히 재밌고 잘 맞았던 Django 를 다시금 공부하게되었다.
출결이 그렇게 달더라
출결, 즉 출석과 결석에 관한 협조증인데 학교랑 관련된 프로젝트를 하다보니 담당하시는 선생님이 출결협조증을 써주셔서 수업을 모조리 빼고 프로젝트 개발에 집중할 수 있었다. (물론 중간고사, 기말고사 성적은 말아먹어서 싫어들하셨다.)
도서실에 모여서 1교시부터 11교시까지 프로젝트를 같이 진행하고 서로 피드백하며 실시간으로 오류를 함께 보는 등 굉장히 즐겁고 유익했던 시간이였다.
글을 쓰는 이 시점에도 유지보수를 핑계(?)삼아 수업을 듣지 않고 다른 실에서 Django를 공부하며 velog글들을 쓰고 있다.
(히히 담당쌤 최고)
프로젝트 끝!
이 글이 업로드된 시점의 저번주에 원서 접수까지 모두 마무리됐다. 큰 이슈가 없이 잘 마무리가 되었고, 6개월간의 여정을 잘 끝마친 느낌이라 굉장히 뿌듯했다.
DevOps Chapter Memoir
프로젝트를 진행하면서 인간 대 인간으로? 느꼈던 것들을 적었으니 이제 프로젝트를 진행하면서 배우고 사용하였던 스택들에 대한 이야기를 해볼려고한다.
우선 우리 서비스의 아키텍처다.
배포
그냥 골때렸다. 내가 해본 배포라곤 기능대회에서 배웠던 배포밖에 없었다. 그래서 어떤식으로 배포를 해야 효율적으로 배포가 되는지도 몰랐기에(지금도 잘 모르지만) 무작정 EC2를 열고 git clone을 받고 nest start를 했다.하지만 될리가 없지 yarn, prisma 등 다양한 서비스를 다운받아야하고 공부해야됐었다.
EC2
처음 시도했던 배포를 위한 서비스다. 어떠한 과정으로 배포를 하였냐면
- 테스트 서버였기 때문에 무지성 public subnet EC2에 nest application git clone 받아오기
- 로드밸런서, 타겟그룹 등등 배포를 위한 서비스들 연결
- 서버 들어가서 실행 -> 아 이거 왜 안돼
- 백엔드 친구한테 설명하고, 실행을 위해 필요한 서비스들 세팅(prisma, yarn 등등)
다른 서비스들에 비해 굉장히 잘 알고 있었던 서비스였기 때문에 AWS 서비스들은 전혀 어렵지 않았지만 백엔드가 익숙하지 않았던 나였기에 백엔드와 관련된 부분에서 굉장히 많은 삽질을 하고 굴렀다. 백엔드 친구의 local은 윈도우, 서버는 ubuntu 였었기 때문에 OS에서 나는 차이점 같은 것도 고려하느라 참 골때렸다.
중간에 한번 ECR,ECS로 갈아타고 다시 EC2로 돌아왔다.
도메인
도메인 관련된건 기능대회 때문에 딱 한번 해봤지만 엄청 어렵거나 한건 없어서 금방했다. SSL 인증서에 대한 개념이 잘 박혀있진 않아서 바로 되지 않으면 안되는줄 알고 왜 안되는데 ~~ 하고 멘탈 깨져서 저녁에 다시 보니 되어있어서 https 가 되고 그런식으로 어찌저찌 기술적으론 쉽게 해결했던 것 같다.
prisma 등의 백엔드 서비스
굉장히 골때렸다. prisma 는 처음듣고, nestjs 도 뭔지만 알지 한번도 사용해본적 없고... 그렇기에 최대한 백엔드에 맞춰서 내가 배워갔던 것 같다.
배포때문에 내가 추가한 서비스는 pm2 말곤 없는 것 같다.
지금 생각해보면 백엔드 서비스의 이걸 조금 수정해서 이렇게 해보면 좀 더 배포쪽에서 편하고 좋을 것 같다 ~ 라는게 몇 개씩 있었던 것 같은데 이 당시엔 잘 몰라서 적용을 시키지 못한게 아쉽다.
ECR/ECS
3기? 2기? 선배가 오셔서 현업에 관한 이야기도 해주시고, 프로젝트에 대한 조언을 해주셨는데 EC2로 배포를 하기보단 어차피 백엔드를 하는 친구가 Docker를 사용할 줄 아니까 ECR과 ECS를 사용하여서 컨테이너 단위로 배포를 해도 좋을 것 같다 라고 하셨다.
처음사용해본 서비스였기에 굉장히 예를 먹어서 처음부터 끝까지 실습을 하는 글들을 찾아 다녔다. 구글링을 굉장히 열심히하였고, 결국엔 찾아서 어찌저찌 찾아서 잘 구축하였다.
조금 이따 설명할 CI/CD 파트에서 모노레포로 인한 엄청난 오류들로 인해 결국엔 지금은 사용하지 않고있다.
(써보고 싶었는데 좀 많이 아쉬웠다.)
CI/CD 등의 자동화
CICD는 2가지의 자동화 툴을 사용하였다.
Github Action
프로젝트전부터 많이는 사용하지 않았지만 조금씩 사용하던 툴이였다. ECR/ECS 를 사용했었기 때문에 github에서 제공해주는 ECR/ECS 워크플로우를 적용시켜 조금씩 바꾸어서 편하게 사용할 수 있었다.
하지만 application 에 모노레포가 적용되자 ECR/ECS CI/CD를 위해 필요한task-definition.json 의 경로 등의 문제로 일주일 내내 오류를 고치다가 결국 딜레이가 너무 돼서 ec2-codeseries 스택으로 변경하게되었다.
version 2를 배포할때는 꼭 이 오류들을 해결하고 싶다. (다른 방법으로 돌아서 해결하든 직접적으로 해결하든 컨테이너 단위로 배포하고 싶다.)
(진짜 오류 고치다가 정신 나갈 뻔했다. 진짜로)
AWS CodeSeries
ECR/ECS - GitAction 을 할 수 없게 되자 사용한 CI/CD 툴. 이미 깃허브를 사용하여 협업을 하고 있었기 때문에 codecommit은 사용하지 않고 github - codebuild - codedeploy 방식으로 CI/CD를 진행하였다.
처음에는 ubuntu 환경이라 루비가 제대로 설치되지 않아codedeployagent(codedeploy 관련해서 설치해야하는 서비스)를 설치하는 과정에서 여러 에러가 있었지만 과감하게 amazon linux 서버로 바꾸고 재구축하였다. 이후 여러가지 해외글들도 찾아보고, 적용해보면서 성공적으로 잘 적용하였다.
codebuild buildspec.yml 과 관련해서 조금 시간을 많이 썼지만 지금은 잘 적용시킬 수 있다. 음음
다음에 codepipeline을 구축할땐 순수 codeseries만 사용하는게 아니라 jenkins 등 외부 툴들도 끌어다가 연계해서 사용해보고 싶다.
로깅
cloudwatch만 사용하였다. 정확히는 cloudwatch - sns - lambda - discord. 이런 식으로 구축하였고, 500에러가 로그에 잡혀서 경보가 울리면 discord로 어디서 오류가 났다! 라는 알람이 울리게하였다.
discord로 알람이 오는 lambda 코드를 내가 직접 작성해보고 싶었지만 시간이 너무 많이 걸리기도하였고, 선배들이 사용하였던 lambda 코드로만해도 충분히 로깅이 되기 때문에 그냥 선배들것들 돚거하였다.
추후 시간이 있을때 좀 더 공부하여서 내가 직접 python으로 lambda 코드를 짜보고 싶다.
RDS
백엔드 챕터중에 DB를 관리하는 친구가 따로 있어서 내가 딱히 건들진 않았고 그 친구가 모르는 내용들만 알려주면 그 친구가 작업하는 식으로 진행하였다.
RDS에서 오류가 생기면 같이 작업하는 정도? 라서 딱히 요쪽을 건들진 않았떤 것 같다.
글을 마치며 주저리주저리
음 그냥 생각없이 주저리주저리 쓰다보니 글이 굉장히 난잡해진 것 같지만 그것또한 필자의 회고록스타일이니 넘어가자.
6개월동안 진행된 프로젝트. 지금까지 해온 프로젝트중에 가장 기간이 길지 않았나 싶다. 6개월동안 이 프로젝트를 통해 진짜 여러 툴들을 익혔다. 사용한 시간보다 삽질한 시간이 많았던 것 같긴한데 그 과정에서 진짜 많은 것을 얻었던 것 같다.
version 2는 아래기수인 후배들이 맡아서 진행할 것 같은데 나도 그때 합류해서 조금 더 뭔가를 해보고 싶다는 욕심이있다.
개발한 팀원들 모두 수고 많았고, 프로젝트 진행을 도와준 운영팀, 도움을 준 선배들에게 감사를 표한다.
이상, Hello, Gsm 회고록 끝!
(프로젝트 끝나고 먹는 치킨이 그렇게 맛있더라고요)
