프로젝트 기간: 2022.09 ~ 2022.10

❗️프로젝트 시작

참여하고 있던 부트캠프에서 프로젝트를 진행하게 됐다.

부트캠프에 참여한 모든 인원이 프로젝트 아이디어를 하나씩 제출하고, 투표를 해서 뽑힌 주제들에 팀원들이 지원하는 방식으로 팀이 구성됐다. 놀랍게도 내 아이디어가 선정이 되어 팀장을 맡게 되었고, 4명의 팀원과 함께 프로젝트를 진행하게 됐다.

프로젝트 아이디어

프로젝트는 내 대학 시절의 아쉬움에서 나왔다. 경제학을 전공한 나는 매번 시험기간에 많은 양의 문제를 풀어야 했다. 전공책의 문제를 풀어본 사람은 알겠지만, 이 놈의 전공책은 답지가 없다. 답지가 있어도 해설이 없다. 불친절의 끝을 달린다. 새벽부터 교수님한테 물어볼 수도 없고, 친구놈은 나랑 또이또이하다.

인터넷에 문제를 검색하면 아~~~주 간혹 Chegg라는 사이트에 동일한 문제와 해답이 보이곤 한다. 그런데 이 사이트는 또 영어로 되어 있어서 나에게 엄청난 시련을 가져다 주곤 했다.

위와 같은 시련을 많은 대학생들이 느꼈을 것이라 생각한다. 기존에 존재하는 질의응답 플랫폼은 국내의 학부생을 타겟으로 하지 않는다. 특히, 인문이나 예술 분야의 경우는 전무하다고 볼 수 있다. 공학이나 상경은 해외 사이트라도 이용할 수 있지.. 이런 빈틈(?)을 채우기 위한 서비스라고 보면 좋을 거 같다.

😎 프로젝트 진행

프로젝트 설계

우선 첫 회의에서 우리가 만들 서비스의 MVP 모델을 만들었다. 구현해야 할 사항, 서비스 정책상 추후 결정되어야 할 사항들을 정리했다.

어디선가 스크럼, 스프린트, 애자일 방법론과 같은 단어들을 봤던 기억이 났고, 실제로 스크럼 방법론을 적용해보고자 했다. 앞서 작성한 MVP 모델을 바탕으로, 주어진 8주간의 시간 동안 처리할 프로세스를 작성했다.

Trello나 Jira를 써볼까 고민도 했지만, 당시 부트캠프에서 Notion을 주력으로 사용하고 있었기 때문에 Notion을 통해 스크럼 관리를 하고자 했다.

Git

Git Flow

Git 관리에 대해서 고민이 많았다. 프로젝트 경험이 유일한 나조차도 Git은 능숙하지 않아서, 간단하면서도 명료한 규칙체계가 필요했다. git flow라는 것을 알게 되면서, 한 번 적용해보고자 하였다.

참고 링크를 보고 느낀 바는, 결국 git flow란 branch 관리의 한 전략이라는 것이었다. 어떤 작업인 지에 따라 branch를 분리함으로써 깔끔한 관리를 돕는 하나의 방식이며, 이를 위해 4개의 branch로 분리해보았다. 지금와서 보면 test 환경도 있으면 좋았을 거 같지만, test 자체를 짜지 않아서...

Commit 규칙

git flow와 마찬가지로 commit 메세지도 일정한 규칙을 따르는 것이 협업을 위해 좋은 방법이다. 이를 위해 팀 내부적으로 commit 규칙을 정하기로 하였다.

참조링크는 너무 꼼꼼하고 복잡(?)하다는 판단하에, 우리끼리 필요하다고 생각하는 선에서 규칙을 재설정해보았다.

프로젝트 진행

1. 백엔드

백엔드 개발에서는 크게 두 개가 어려웠다.

첫번째는 질의응답 게시물의 카테고리 설정이었다. 우리가 설계하는 대학생을 위한 질의응답 서비스를 위해선 상위 카테고리와 하위 카테고리가 필요하다. 대분류로 인문, 사회, 상경, 자연, 공학, 예술로 구분이 되고, 소분류로는 각 대분류 하위 전공이 포함되어야 한다. 가령, 인문 카테고리라면 국문, 영문, 노어... 등이 포함될 수 있겠다.

이때 문제가 됐던 것은, 프론트의 요청이 들어왔을 때 카테고리를 어떻게 검사할 지에 대한 것이었다. 카테고리 Request의 자료형을 Enum으로 선언하면 에러 메세지 관리가 힘들다는 어려움이 있었고, String으로 받자니 @Valid 어노테이션을 활용하기 어렵다는 단점이 있었다.

이를 해결한 방법은 여기에 정리해 두었다.

두번째는 사진추가에 관한 것이었다. 질의응답에서 빠질 수 없는 것이 사진이다. 텍스트 에디터로 작성할 수 있는 것에 한계가 있다. 때로는 텍스트 에디터에 입력하기보다는 수식을 직접 펜으로 작성해서 사진을 찍어 올리는 방식이 편할 수 있다. 이를 위해선 사진 등록이 필요한데, 근래에는 사진을 글 작성 단계에서 확인할 수 있게 한다. 당장 Velog만 하더라도 사진을 삽입하면 미리보기를 통해 확인할 수 있다.

이를 위해선 사진 등록을 위한 API를 게시글 등록과 별도로 분리해야 했고, 이를 별도의 장소에 저장 및 저장 url을 반환해주어야 했다. 이를 위해 AWS의 S3를 사용했고, 이 과정에서 UUID를 사용하는 등, 많은 공부를 할 수 있었다.

2. 코드리뷰

나를 제외한 모든 팀원분들이 처음 프로젝트를 진행하는 것이기 때문에, 배운 스프링 내용을 능숙하게 활용하기란 힘들 것이라 생각했다. 물론 나도 능숙하지 않지만, 그래도 프로젝트를 한 번 진행해봤고 스프링에 조금은 더 익숙하다는 이유로 모든 pr에 대한 리뷰를 진행했다.

부끄러우니깐 리뷰 내용도 살포시 가리기

초기에는 그래도 코드의 양이 많지 않았고, 내가 해야 할 일도 간단했기에 다른 분들의 코드를 리뷰하는 게 그렇게 어렵지는 않았다. 그러나 뒤로 갈수록 내가 맡은 기능 구현도 늘고, 팀원분들도 리뷰를 해보고 싶다는 요청이 있어서 리뷰 방식을 변경하게 되었다.

리뷰는 팀원간 상호 리뷰를 진행하고, 나는 보조적으로 리뷰에 참여하는 형태가 되었다. 가령 A팀원이 B팀원의 pr에 대한 리뷰를 모두 진행하고, 추후 리뷰 내용에 대한 리뷰를 진행하는 방식으로 말이다. 팀원 간의 리뷰 내용 중에서 틀린 부분은 없는지 (내가 아는 선에서), 이런 부분에 대한 내용을 조금 더 공부했으면 좋겠다는 식의 리뷰를 진행했다.

리뷰에 대한 리뷰만을 진행하면서 짐을 덜을 수는 있었지만, 코드의 퀄리티가 조금씩 떨어지는 듯한 느낌이 강하게 들었다. 직접 코드를 보지 않게 되다 보니, 구체적인 부분을 수정하지 못하게 되면서 발생하는 부작용인 듯 했다. 그럼에도 부담을 덜었다는 점, 팀원들의 리뷰 경험 등을 고려해보면 결과적으론 긍정적이었던 거 같다.

3. 프론트엔드

백엔드 부트캠프에서 진행한 프로젝트이다 보니 프론트엔드는 주변의 프론트엔드 취준생 친구에게 부탁하고자 했다. 그러나 중간에 운영진과의 의사소통상 문제로 뒤늦게 프론트도 작성해야 함을 알게 되었고, 주어진 8주의 개발기간 중 6주차에 들어섰을 때야 부랴부랴 프론트를 작성하게 됐다.

다른 팀원들은 API 개발에도 버거워하고 있던 상황이었기 때문에, 내가 모든 프론트 작업을 진행해야 했다. 정말 눈앞에 아득해지는 순간이었다.

프론트를 어떻게 개발해야 할까. 다른 팀들은 Thymeleaf를 이용하여 개발을 하는 듯 했고, 이미 RestAPI로 설계를 다 해놓은 상황이었기 때문에 다른 방법을 찾아야 했다. 많은 대안들이 있었지만 결과적으론 React를 활용하기로 했다. JavaScript도 모르는 문외한이지만, '어떻게든 되겠지', '2주면 되겠지'라는 마음으로 시작했다.

React의 러닝커브에 대해서 들어보셨다면 나의 선택이 얼마나 무모했는지 아실 것이다. 그럼에도 불구하고, 2주 동안 프론트 개발을 해내지 못한다면 모든 작업물들을 시각적으로 보여줄 수 없다는 압박감이 강했다.

운 좋게도 프론트 개발자 친구가 있었던 덕분에, 개똥같은 UI/UX지만 완성을 할 수 있었다.

(서버를 내려서 내용물이 없다.)

JavaScript도 모르는 백엔드 개발자 지망생이 React로 프론트 페이지를 만들면서 정말 많은 어려움을 겪었다. 그래서 그 소중한 삽질을 블로그에 기록(Footer 고정하기, 다른 Component로 값 넘기기)으로 남겨두었다.

느낀점

아쉬웠던 점

사실 이 후기는 아쉬운 점을 기록해두기 위해 작성하는 것이다. 아쉬운 점이 너무나도 많았던 프로젝트기 때문이다.

리더로서

이전에도 감투는 많이 써왔다. 중학교 때부터 조장이고 반장이고 가리지 않고 해왔고, 학부생이 되어서도 팀 리더가 되어 많은 공모전이나 경진대회에서 우승해왔다. 그만큼 나 스스로의 리더십에 의문을 가져본 적이 없다. 물론 내 스스로가 엄청 뛰어난 리더십을 가졌다는 것이 아니라, 그래도 중간은 가는 리더였다는 것을 의미하는 것이다.

그런데 개발자로서, 리딩을 하는 일은 너무나도 어렵고 힘들었다. 무엇보다 개발자로서 내 역량이 너무 부족함을 느꼈다. 거기서 오는 문제가 너무나도 컸다.

우선, 스크럼 방법론을 적용하면서 스프린트 기간을 너무 길게 잡았다는 아쉬움이 있다. 다시말하면, 주어진 기간동안 구현해야할 기능을 너무 적게 할당했다. 8주간의 주어진 시간동안 주어진 기능을 5등분(인원수만큼)하고 8등분(주어진 주차만큼)한 것을 할당했다.

사실 MVP가 개발의 끝이 아니다. 추가 기능, 유지, 보수 뿐만 아니라 다양한 Devops를 시도해볼 수 있었다. 그러나 그러지 못했다. 스프린트 기간에 주어진 할당량을 채우면 그것에 만족을 느끼고 말았다. 그러다보니 자연스레 느슨해지고, 이는 나뿐만이 아닌 모든 팀원들도 마찬가지였다. 리더로서 다시 그 때로 돌아간다면, 진행 상황에 대한 객관적인 피드백을 통해 더 많은 스프린트를 할당하고자 했을 것이다.

스크럼 방법론을 적용시키며 생겼던 아쉬움도 있지만, 개인의 역량에 대한 아쉬움도 존재한다. 리뷰를 진행하면서 내가 아는 선에서만 대안이나 해결을 제시하게 됐다. 분명 명쾌한 대안이나 해결책이 아닌 것이 느껴짐에도 불구하고, '이 부분에 관해서 조금 더 찾아보세요'라는 첨언을 할 수 밖에 없는 게 너무나도 아쉬웠다.

게다가 Devops를 진행하면서 조금 더 나은 시스템 아키텍처를 구성하고자 하는 욕심이 있었지만, 프로젝트 후반 프론트 작업을 맡게 되면서 욕심을 접어두어야 했다. 조금 더 나은 역량을 가지고 있는 사람이었다면 더 나은 결과물을 얻을 수 있었을 것이라 장담한다.

프로젝트 구성원으로서

프로젝트가 너무나도 흐지부지 마무리되었다. 발표 날에 맞추어 프론트도 너무 급급하게 완성이 되었고, 백엔드도 몇 가지 추가 기능을 구현하지 못했다. 테스트의 부재는 말할 것도 없고, 시스템 아키텍처 역시 아쉬웠다.

발표가 끝난 이후에 팀원들에게 추가적인 작업을 제안했다. 프론트도 조금 더 공부하며 추가적인 작업을 진행하고, 백엔드도 미처 못다한 기능을 구현하고, CI/CD도 적용해보며 Docker도 사용하는 등, 많은 것들을 시도해보고자 하였다. 4명의 팀원 중 3명이 동의하였고, 추가 회의를 거듭하며 어떤 것들을 더 할 지, 어떤 것들을 포기할 지 결정했다.

그러나, 한 번 느슨해졌던 팀이었던 탓인지 얼마 못 가 다시 느슨해지며 추가 작업은 이내 끝나고 말았다. 리더로서 아쉬운 점이 될 수도 있는 부분이지만, 나 역시도 프론트를 맡았던 한 구성원으로서 느슨해진 것에 대한 아쉬움이 존재한다.

물론, 백엔드 개발자인데 프론트 추가 작업 하기 싫은... 크흠...