코드스테이츠 백엔드 부트캠프 메인 프로젝트 회고 -2

본격적인 프로젝트 진행

01

우리 팀의 깃허브 이슈 라벨과 나의 첫 이슈 작성

 본격적으로 프로젝트가 시작되었다. 개인적으로 메인 프로젝트에 들어가면 꼭 해보고 싶었던 것 중 하나가 바로 깃허브 내에 이슈와 칸반보드를 활용하는 것이었다. 프리 프로젝트 때는 처음이기도 하고 시간도 짧아 전혀 활용하지 못했기 때문에 메인 프로젝트에서는 최대한 활용하여 프로젝트를 진행해보고 싶었다. 이유는 간단하다. 1. 협업하는 기분을 낼 수 있고(ㅋ.ㅋ), 2. 팀원들의 진행 상황을 굳이 물어보지 않아도 한눈에 파악할 수 있기 때문이다. 팀에서도 이슈나 칸반보드를 활용해보고 싶다는 의견이 지배적이었기 때문에 내가 나서서 만들고 회의할 때 팀원분들께 보여줬더니 다들 매우 좋아하셨다. 특히 label이 예쁘다고 칭찬받았다ㅎㅎ

 

 

첫 멘토링

01

멘토님과의 첫 만남과 수정된 ERD

 멘토링 전 날에 백엔드 팀원분들과 함께 ERD를 작성했다. 나는 ERD를 작성하는 게 매우 어색하다. 연관관계 매핑도 완벽히 이해하지 못했기 때문에 제대로 할 수 있을까 걱정이 들었다. 이렇게 하는 게 맞나 싶으면서 일단 작성을 했는데 팀원분들과 고민하며 작성하니 생각보다 금방 끝이 났다. 다음 날 멘토링 시간 때 멘토님과 처음으로 만나 조언에 따라 ERD를 수정했다. 전체적인 구조나 매핑에 대해서는 지적하지 않으셨다. 오히려 '멱등성을 고려했냐', '이모지 데이터를 프런트 쪽에 맡기면 되게 이상한 거다.', '장소에 추천수는 굳이 필요 없을 것 같은데?' 등 전혀 생각하지 않은 부분에서 질문이 나왔다. 나는 어떤 질문도 쉽게 대답할 수 없었고 이게 과연 내가 만든게 맞나.. 하는 생각이 들었다. 급해보이는 공부가 또 하나 늘었다.

 

 멘토님은 기존에 내가 가지고 있던 생각에 찬물을 끼얹는 이야기도 하셨다. 나는 지금껏 자바 스프링 개발자가 되기 위해 공부하고 있으니 이게 내 메인 기술이며, 이 두 부분을 최대한 많이 공부해야 한다고 생각했다. 때문에 아직까지는 스스로 실력이 많이 부족하다고 생각하여 수료 후 한 달 정도를 인프런과 유어클래스 내용을 함께 공부하면서 지금까지 배운 자바와 스프링에 대한 내용을 다시금 복습할 생각이었다. 그러나, 멘토님께서는 '자바 스프링 잘해서 뭐 어쩌라고?', '그게 다가 아니다', 현재 기업들이 신입 개발자에게 요구하는 필수적인 역량을 모두 공부해야 한다.'라고 조언해 주셨다. 대표적으로 도커, aws, ci/cd 파이프 라인 등을 언급하시며, 지금부터 이것들도 함께 공부해야 하며 오히려 자바 스프링을 깊게 공부하는 것보다 취업에 도움이 될 수도 있다고 하셨다. 또, 꼭 자바 스프링으로만 취업할 거라고 생각하지 말라고 하셨다. 매우 충격적인 말이었다. 내가 지금껏 배운 건 자바 스프링이 거의 전부인데 말이다. 멘토님의 조언에 머리가 매우 복잡해졌지만 지금 시기에 꼭 들어봐야 할 이야기인 것 같았다.

 

 가장 중요했던 얘기는 지금부터 취업 준비를 해야 한다는 말이었다. 여러 부트캠프, 국비지원 학원의 수료 일자가 비슷하기 때문에 취업 시장에 나와 비슷한 취준생이 쏟아져 나온단다. 수많은 예비 개발자들과의 경쟁에서 차별점을 두고 앞서기 위해서는 빠르게 치고 나가야 한다고 하셨다. 또, 개인 공부보다는 취업 준비를 통한 자연스러운 공부를 추천하셨다. 일반적인 공부로는 방대한 양에서 무엇이 중요한지를 구분하기 어렵지만, 취업 준비를 하면 기업을 찾아보거나 면접을 준비하는 과정에서 당장 필요한 공부가 눈에 들어오기 때문이다.

 

 멘토님 이야기를 듣고 보니 다 맞는 말 같았다. 당장 이번 메인 프로젝트 진행에 있어서도 실전 경험이 없는 게 바로 드러났다. 우리는 백엔드끼리 ERD를 작성한 후 이를 토대로 API 명세서를 작성하고 나중에 프런트엔드 쪽으로 보내줄 생각을 하고 있었는데 이는 매우 잘못된 방식이라고 지적받았다. API 명세서는 사용자 요구사항 정의서 작성이 끝나고 프런트엔드와 백엔드가 함께 모여 초안을 작성하는 게 일반적이라고 한다. 만약 프런트엔드 없이 백엔드끼리 API 명세서를 작성하게 되면 기능 구현 중간에 프런트엔드 쪽에서 기능 변경 및 추가를 요구하게 되고 이로 인해 테이블 수정이 불가피하게 되어 결국 프런트엔드 위주의 개발이 되어버린다. 프런트엔드 위주의 개발은 백엔드의 코드나 데이터베이스가 더러워지는 최악의 결말을 맞이할 확률이 높다고 하셨다. 나는 지금껏 배려한다고 프런트엔드를 먼저 생각했었는데 아주 잘못된 생각이라는 걸 깨달았다. 이런 기본적인 내용은 경험이 없으면 알기 힘든 내용이겠구나 싶었다.

 

 

AWS와 친해지기

012

EC2 인스턴스 내 빌드 시도와 Github Actions를 이용한 배포 자동화 성공까지

 멘토님께서 조언해주신 또 다른 내용은 바로 배포 자동화를 미리 해놓으라는 것이었다. 배포 자동화는 미리 해놔야 의미가 있지 수동으로 배포하다가 나중이 돼서야 자동화를 적용하는 건 아무 의미 없다고 하셨다. 이것 역시 듣고 보니 맞는 말.. 참 모르는 게 많다ㅋㅋ

 

 멘토링 다음 날, 나를 포함한 우리 팀원들 중에는 aws를 제대로 경험해 본 사람이 없어 일단 백엔드 세 명이서 각자의 aws 계정을 이용해 실습해보는 시간을 가지기로 했다. 세 명 모두 ec2 인스턴스에 git clone을 받아 빌드하고 RDS와 연결하는 것까지 성공했다.

 

 그 날 정규 수업 시간이 종료되고 팀장님과 둘이 github actions를 만져봤다. 이해하기 어려운 에러가 있었지만 팀장님 덕분에 빠르게 벗어날 수 있었다. 이후 팀장님은 식사를 하러 가시고 나 혼자 배포 자동화를 진행해 봤는데 며칠이 걸릴 거라고 예상한 것과는 달리 몇 번의 에러를 전부 해결하고 하루 만에 성공해 버렸다. actions 빌드 부분을 제외하고는 거의 혼자서 구현한 거라 팀에 도움이 되었다는 생각에 매우 뿌듯했다. 다음 주에는 기본 기능 구현을 끝내고 jwt 적용을 도전해볼 텐데 다른 것보다 어떤 에러를 만나게 될지 기대가 된다..