본문 바로가기

프로젝트 기록

[SSAFY 공통 프로젝트] ssafé 회고

7주간의 SSAFY 공통 프로젝트가 드디어 끝이 났다.

아래 목차의 순서대로 회고록을 작성해 보고자 한다.

 

- 프로젝트를 통해 배운 점

 

- 아쉬운 점

 

- 차후 이어지는 프로젝트 때는 어떻게 할 건지

 

- 전반적인 프로젝트 후기

 


- 프로젝트를 통해 배운 점

 

이번 프로젝트는 비교적 긴 기간동안 맨 바탕에서부터 제대로 해보는, 내 첫 프로젝트여서 모든 게 새로웠고 그만큼 배우는 것도 많았다.

팀원들과의 지속적인 소통, 맨 바탕에서부터의 기획과 구현 모두 처음 해 보는 것이었고 그 과정에서 사용되었던 모든 툴과 기술 스택도 새로운 것이 많았다.

 

대부분의 소통은 디스코드를 통해 이루어졌고, 피그마를 통해 와이어프레임/프로토타입을 작성하며 기획했다.

ground rule, convention, 데일리 스크럼, 기술 공유 등은 Notion을 사용했으며 모든 개발은 GitHub를 통해서 진행되었다. 나는 그 과정에서 처음으로 Git flow, Issue, PR 기능 등을 사용해 보게 되었다. 

내 포지션은 백엔드였으며 구현을 위해 기획을 바탕으로 DB를 설계하고, 이를 IntelliJ IDE 위에서 Spring Boot, JPA를 활용하여 백을 구현했다. 그 과정에서 추가적으로 QueryDSL, OAuth, JWT를 사용하기도 했고, 부하 테스트에는 JMeter를 사용했으며, 개발이 끝난 뒤에는 Dockerize와 배포 또한 진행했다.

 

이 중에서 내가 싸피에서 1학기 때 미리 배워본 것은 Spring Boot밖에 없었다. 그만큼 새롭게 접하는 것이 많았기에 빠르게 배우고 바로 개발에 적용하는 것이 쉽지는 않았지만, (삽질은 덤..ㅎ) 팀장 오빠가 많이 도와주기도 했고 뒤돌아보니 그만큼 많이 성장한 것 같아 뿌듯하다.

 

같이 백엔드를 개발했던 팀장 오빠는 나와 달리 이미 프로젝트를 여러 번 진행한, 노련한 실력을 가지고 있어서 덕분에 많이 배웠다. 오빠의 코드를 보며 스켈레톤 코드 삼아 최대한 깔끔하고 RESTful하게 코드를 짜려고 노력했고, 코드 중 이해가 가지 않는 부분이 있으면 적극적으로 물어보면서 내 코드에도 활용했다. 대표적으로 Embedded 타입을 활용해서 좋아요/스크랩의 DB작업 코드를 따로 빼서, Entity class의 코드를 깔끔하게 유지했던 부분이 있다.

 

뿐만 아니라 처음부터 우리 팀의 목표는 로컬 프로젝트가 아닌 '프로덕션'이었기에, 단순히 동작만 하게 코드를 짠 게 아니라 더 나아가서 쿼리 최적화까지 진행하였다.

JPA 자체가 처음인 나로써는 며칠 동안 머리에 쥐가 날 것 같았지만, 게시판 전체조회 시 2*N+1번 쿼리가 날아가던 걸 결국 3번으로 줄이는 것에 성공했을 때의 그 희열은 아직도 생생하다.

 

그리고 더해서, 프론트와 백 간의 소통과 초기에 탄탄하게 기획하는 것이 정말 중요함을 깨달았다.

화면 단의 요소 하나 하나가 DB 그리고 백엔드의 코드와 정말로 직결되어 있다는 것을, 개발 후반부에서 화면 단에서 조금씩 수정 사항이 생기고, 그에 따라 백 코드를 바꿔야 하는 여러 번의 상황에서 정말로 깊이 체감했다.

(ex. 회사 테이블에 영문 회사 이름 필드가 뒤늦게 추가되거나, 스터디 테이블의 장소 필드가 모집 인원 필드로 변경되거나, 스터디 테이블에 썸네일 필드가 추가된다든가 하는..)

그래도 우리 팀은 비교적 초반에 기획을 탄탄히 하고, 프론트 팀원들은 최대한 백의 편의를 봐 주려고 하고 우리 백은 최대한 프론트에게 맞춰주려고 하는 훈훈한 분위기였기에 갈등 없이 잘 넘어간 것 같다.

개발이 진행되어 가면서 수정 사항이 생기는건 당연한 일이므로, 당연히 감수해야 하는 일이라고 생각한다.

 

 

- 아쉬운 점

 

1. 순간의 귀찮음을 이유로 기록을 미룬 점

 

기록의 중요성은 프로젝트를 시작하기 전부터 누누이 들었지만 막상 프로젝트를 시작하니 너무 바쁘거나 피곤해서, 또는 귀찮아서 기록들을 미룬 적이 더러 있다.

중후반부에 가서야 초반에 미뤄뒀던 기록했어야 할 내용들이 하나도 떠오르지 않자 부랴부랴 기록하기 시작했는데, 초반에 놓친 기록들이 아쉽다.

 

 

2. 마음속에 피어나는 의구심을 그냥 지나치고 개발하면, 후에 꼭 되돌아와서 더 시간을 들여 고쳐야 함을 늦게 깨달은 점

 

이 말이 무슨 말인가 하면, 그 당시에 개발할 땐 '이렇게 해도 되나...?' '프론트한테 이게 맞냐고 안 물어보고 일단 그냥 진행해도 되나..?'라는 의구심이 마음 속에 작게 피어올라도 일단 피곤하고 귀찮아서(?) '에이 맞겠지~'하면서 그냥 내 쪼대로 개발하곤 했다.

하지만 꼭 내가 우려했던 게 현실이 되고.. 그래서 나중에 그 코드로 되돌아와서 손을 봐야 했는데, 그때는 이미 개발 스케일이 더 커진 상태라 고치는 데 더 애를 먹은 적이 더러 있었다.

 

예를 들어, 좋아요와 스크랩 등록/취소를 단순히 POST, DELETE로 구현했었다. 구현 하면서도 '이렇게 하면 같은 유저가 좋아요를 두번 이상 누르면 좋아요가 계속 쌓이지 않나...?'하는 생각이 들었는데, 프론트 분들이 알아서 해 주시겠지 하면서 그냥 그렇게 구현했다. 하지만 막바지에 결국은 좋아요/스크랩을 토글 형태의 PUT 방식으로 바꾸게 되었다.  애초에 처음부터 좋아요 기능 구현할때부터 PUT으로 했더라면 두세번 일 하지 않아도 됐을 텐데..하는 생각이 들었다.

 

 

 

3. 개발할 때 좀 더 주의를 기울여서 개발할 걸

 

이것도 2번과 연장선에 있는 부분이긴 하다. 개발을 할 때 너무 생각없이 기계적으로 개발하기 보다는, 좀 더 효율적인 코드가 뭔지, 그리고 특히 다른 백 팀원과의 api url 이나 코드 컨벤션이 잘 통일된 상태로 개발하고 있는지를 계속 살펴보면서 개발할 필요성을 느꼈다. 그래야 일을 두세번 하지 않고 한 번에 끝낼 수 있다.

 

좀 더 효율적인 코드의 경우에는, 게시물/스터디 검색 기능이 그 예가 될 수 있겠다. 처음 개발할 때는 그냥 단순하게 생각해서 검색, 조회순, 최신순, 좋아요 순 정렬 api를 각각 구현했다. 하지만 후에 프론트 팀원의 제안으로 api url을 /search로 통일하고, 매개변수로 criteria(정렬 기준), title(검색어)를 넘기는 걸로 해서 검색과 모든 종류의 정렬을 하나의 api로 만들었다. 즉, 훨씬 더 효율적으로 검색 및 정렬 api를 리팩토링 한 것이다.

 

뿐만 아니라 개발 마무리 단계에서 보니 팀장 오빠와 내 api url 컨벤션이 통일되지 않는 부분이 있어서 url를 고치고 api document도 여러 번 수정한 적이 있는데, 이 또한 처음부터 잘 살피며 했으면 두번 작업하지 않아도 되는 부분이었다. 

 

 

 

4. 테스트와 코드 리뷰를 제대로 진행하지 못한 점

 

7주라는 기간이 사실 ssafé 정도로 어느 정도 규모가 있는 프로젝트를 완성도 있게 끝낸 후 배포까지 마치기에는 짧은 기간이다.

그래서 개발하느라 바빠서 제대로 코드 리뷰를 못한 점이 아쉽고, 정석적으로는 개발을 진행하면서 Junit 등을 통한 테스트까지 동시에 진행되어야 하지만 postman으로밖에 테스트를 못 한 점이 아쉽다.

테스트는 기업에서도 정말 중요하게 보는 과정 중 하나이므로, 특화 프로젝트를 진행하면서 뒤늦게라도 반드시 진행할 예정이다.

 

 

 

 

- 차후 이어지는 프로젝트에서는 어떻게 할 건지

 

일단, 특화 프로젝트를 진행하면서 이 ssafé 프로젝트도 계속해서 이어나가며 발전시킬 계획이다. 도메인을 구입하고, 배포하여 실 사용자를 받아보며 새로운 기능도 추가해 가고, 유지보수를 하는게 목표다.

 

프론트 단에서는 관리자 페이지 UI를 다듬고 또 여러 세세한 오류들을 잡아나갈 예정이고, 백 단에서는 일단 개발 일정이 너무 촉박해서 못 했던 작업들을 할 계획이다. 대표적으로 Junit을 사용한 테스트 작업과, redis 도입이 있다. 된다면 알림기능, 공고 추천 기능도 추가로 구현해 보고 싶다.

그리고 수동 배포를 하면서 자동 CI/CD의 필요성을 너무나 느꼈던 지라, Jenkins도 도입해서 도커와 젠킨스를 통해 꽤 괜찮은 파이프라인을 구축해 보는게 목표이다.

 

아, 그리고 위에 적어둔 아쉬운 점들도 반영해서 같은 실수를 반복하지 않게 할 것이다. 새롭게 습득한 기술 정리, 에러/최적화를 해결한 기록, 그때그때의 감정 등의 기록을 게을리 하지 않고, 개발할 때 정말 정신 바짝 차리고 순간의 귀찮음/의구심을 그냥 넘기지 않을 것이라 다짐한다.

 

+) 아, 그리고 곧 상반기 공채 시즌이니 알고리즘, 취업 준비도 게을리 하지 말 것.

어쩌면 공통 프로젝트 때보다 더 열심히 살아야 할지도 모르겠다.

 

 

- 전반적인 프로젝트 후기

 

초반에 프로젝트 시작할 때, 진짜 나 빼고 너무 실력자들이라 '내가 과연 1인분 몫을 해낼 수 있을까'에 대한 불안감이 꽤 컸었다. 하지만 하다 보니 7주라는 시간은 정말 빠르게 흘러갔고, 다행히 내 몫은 어찌저찌 다 해낸 것 같아 뿌듯하다.

 

공통 프로젝트 결과가 좋으니(반에서 우수팀으로 뽑혀서 결선 진출✨✨) 고생했던 게 다 보상받는 느낌이었고, 이 좋은 결과도 다 뛰어난 팀원들 덕분이라 생각한다.

 

추구하는 방향성도 잘 맞고, 티키타카도 잘 되고 또 내가 모르는 게 있으면 언제나 친절하게 잘 알려주는 우리 모람모람 팀원들 너무 소중하다🥰

 

내일부터 시작되는 특화 프로젝트도 같이 하고 ssafé도 사실상 이제부터 시작이니, 앞으로도 잘 부탁한다고 말하고 싶다💞

 

 


💁‍♀️링크

깃허브 https://github.com/moramoram

 

moramoram

moramoram has 3 repositories available. Follow their code on GitHub.

github.com

 

모람모람 공용 노션 https://www.notion.so/moramoram-09fa48957b0c4d4f885f04af6365e664

 

moramoram

SSAFY 6기 A604조 모람모람(moramoram)의 Notion입니다.

www.notion.so

 

ssafé 피그마  https://www.figma.com/file/KKHRfTcEuNC1vChK7ExJLU/ssafe-(public)?node-id=0%3A1 

 

Figma

Created with Figma

www.figma.com

 

'프로젝트 기록' 카테고리의 다른 글

정적 팩토리 메서드  (0) 2022.02.23
Thread Local이란?  (0) 2022.02.23
기타 에러 해결 기록들  (0) 2022.02.23
JPA N+1 문제 해결  (0) 2022.02.23
REST API 가이드  (0) 2022.02.23