28기 기프 회고를 했던 게 5개월이나 지났다.
28기 밋업 회고도 하지 않고 29기 기프 회고를 먼저 하게 되다니? 28기 밋업 회고는 언젠간 하자...
0. 도입
28기 기업프로젝트가 내 인생 첫 팀프로젝트였다. 기술도 실력도 경험도 없는 나를 뽑아주었던 사람들과 팀원들을 실망시키지 않기 위해 노력했었는데 이번에도 약간 느낌이 비슷한 것 같다.
28기에서 웹 프론트로 활동하고, 29기에서 백엔드파트로 활동했다. 짧은 시간동안 교육기획팀 일과 파트 변경 과제를 병행하며 참 어려웠지만. . .
1년전에 스프링 강의를 듣다가 어려워서 때려쳤기에 사실상 아는 것이 없었다. literally 아는게 없었다.
그나마 28기로 활동하며 얻은 값진 협업 경험들, 소통 방법과 깃 & 협업툴 사용방법들.
3학년을 보내며 들었던 OS, 네트워크, DB, Unix같은 전공 지식은 자신이 있었다.(있는거맞나?ㅋㅋ)
1월부터 스프링 강의를 다시 들으며 기본적인 CRUD와 지식을 쌓았다. 굑팀 일도 많고 놀러도 많이 가면서 많은 시간을 쏟지는 못했다. 다행히 주변에 좋은 사람들이 너무 많아서, 모르는게 있을 때마다 물어보며 배웠던게 너무 큰 도움이 되었던 것 같다.
28기 기프, 밋업, 파트변경과제에서 사용했던 코드들 엄청많이 참고했다!
1. 프로젝트 소개
29기도 마찬가지, 백엔드파트로 경험하는 첫 팀프로젝트를 기업프로젝트로 진행하게 되었다.
2024.02.19 ~ 2024.03.10 동안, 3주 남짓한 시간동안 진행했다. 기프는 언제나 짧다.
코드잇, 코바코처럼 이름있는 기업의 과제를 하려고 했는데, 알수없는 이끌림에 쏘울라이브라는 콘텐츠큐레이팅 회사의 과제를 하게 되었다. 샌드박스처럼 유튜버,인플루언서 양성하는 그런 기업이다.
앱 과제를 하게 되었고, 모델/인플루언서 검증 앱의 UI/UX를 개선하는 과제를 받았다.
웹프론트 경험을 살리기 위해 웹 과제를 하고 싶었는데, 앱과 협업하게 되어 쪼금? 무서웠다.
1-1. 나의 역할
기획2, 디자인1, 프론트2, 백3로 구성되었다. 프론트 학회원 한명이 탈퇴하는 바람에^^ 인원수가 좀 대차게 꼬였다.
가뜩이나 기업프로젝트는 백엔드가 크게 할 일이 없는데, 셋이나 되어서 더욱 할게 없었을 것 같다.
나는 실력적으로 많이 부족하니까 오히려 다행이라고 생각했다. 코드 하나하나 곱씹어 볼 수 있었다.
다같이 ERD 설계 이후 도메인별로 나누어서 맡았다.
2. KPT 회고
지금까지 늘 해왔던 KPT회고를 진행할 것이다.
KPT회고란?
Keep, Problem, Try의 약자로 Keep은 잘 한 것, Problem은 아쉬운 것, Try는 K와 P 기반으로 무엇을 할지에 대해 작성합니다
K : 잘 해와서 유지하고 싶은 것
P : 어려움을 느껴서 개선하고 싶은 것
T : 구체적인 시도할 내용
2-1. Keep
1. 코드리뷰를 유의미하게 진행했다.
열정이 넘치는 우리 V🙂V 팀원이 코드리뷰를 정말 성실하게 작성했다. 첫 PR을 올렸을 때, 상세한 것 하나하나 댓글과 질문을 작성 해 주었다. 그 영향으로 인해 우리팀은 코드리뷰를 정말 열심히 했던 것 같다.
프론트를 할 때는 <component>가 너무 많고 네이밍컨벤션이 사람마다 제각각이라 다른 사람의 코드를 보고 이해하는게 쉽지 않았다. 백엔드는 어느정도 코드가 정형화 되어 있어 다른 사람의 코드를 보고 이해하는게 조금 가능했다. 그게 장점인 것 같다.
덕분에 나도 팀원의 코드에 모르는 내용을 질문하고, 배워가고, 성장하는데 큰 도움이 되었다. 다른 팀이 우리팀의 코드리뷰를 보고 자극을 받았다는 내용도 참 뿌듯했던 것 같다.
2. 팀원의 코드를 이해하려고 노력함
1번의 이유와 비슷한데, 코드리뷰를 제대로 달려면 확실하게 이해를 해야 한다. 그리고 지금은 내가 모르는 내용일지라도 추후에(아마 밋업때) 참고를 많이 할 코드이기 때문이기도 하다.
가장 큰 이유는 나의 성장과 이해를 위해서 였던 것 같다.
나는 역할을 나눌 때, 한번도 해 보지 못한 기능을 맡는걸 선호한다. 항상 나보다 잘하는 누군가와 팀이 되었고, 처음 구현하는 기능이나 라이브러리를 써 보며 팀원이나 누군가에게 가까운 조언과 도움을 구할 수 있다는 점이 마음에 들었다.
새로운 것을 경험하고 배우는 것은 좋은데, 나의 부족한 부분과 지식과 코드가 까발려지는게 쪼금 무서웠다. 뭐 그래도 실력 좋은 팀원들이 곁에 있어서 너무나 든든했다. 그래서 해 보지 못한 기능에 마음껏 도전할 수 있는 이유이기도 하다.
나는 사용자 커스텀 예외를 생성하는 부분과 BaseResponse를 사용하는 코드를 작성하고 싶었다. 다만 그 당시 일정상의 이유로 많은 기능을 담당하지 못했다. 단순 엔티티 조회만 여러개 구현했을 정도로 버스를 탔다.(미안)
그래서 우리 팀원이 해당 코드를 작성한 부분이나, 다른 여러가지 코드에 대해 이해를 하려고 노력을 했었다. 나에게 있어 유용한 레퍼런스가 될 것 같다.
스프링시큐리티쪽은 다음에 볼게,, 나에겐 너무 어렵자나.
3. 프론트와 소통하며 버그 해결하기
내가 만든 코드에 대한 버그가 발견되었다. 대충 JPA에서 엔티티를 한개만 조회해야 하는데, db에 쌓이는 데이터 형식이 조금 특이해서 여러개의 엔티티가 불러와져서 Error를 던지는 버그였다.
내가 만든 코드에서 버그가 발생했고, 물론 나의 잘못된 설계로 인한 거지만, 스스로 해결해보았다는 점이 뿌듯했다.
4. 그 외
협업하며 코드를 작성하면서 실력적으로 성장하고 체득한 부분은 당연하니 적지 않았다.
ci/cd로직에 대해 쪼금 더 이해했고, 프로덕션과 디벨롭 환경을 구분해 보고 싶다.
중복된 코드를 줄이고 싶은 욕구가 들었다. Entity <-> DTO를 변환하는 과정에 불필요한 db접근이나 중복된 코드가 생기는 것 같아서, 이번에는 좋은 방법을 찾아봐야겠다.
2-2. Problem
1. 열정적으로 소통하지 못했다(쪼끔).
위에도 적었는데, 새로운 것을 경험하고 배우는 것은 좋은데, 이미 여러번 해 봤던 것을 또 하는건 귀찮아 하는 것 같다. 누가보면 몇 년 한줄 알겠다. 고치자.
그런데 erd에서 특정 엔티티에 대해 Get작업밖에 없는 엔티티가 여러개 존재했다. 이 엔티티에 대해 구현코드와 더미데이터를 만드는 것은 단순 노동이라 생각해서 약간 귀찮아 했다.
그래서 약간 카톡을 늦게 보았다가 팀원한테 혼났다ㅋㅋ. 하지만 막상 해보니 나에게는 비슷한 구현 조차 많은 도움이 되었다.
그거 말고는 카톡도 열심히 하고 리뷰도 열심히 하고 기획x디자인과도 열심히 잘 했다.
2. JPA에 대한 기본기 부족
스프링 프레임워크의 동작 방식은 어느정도 이해를 했다. 다만 JPA를 통해 db에 접근하는 과정에서 기본기가 많이 부족했다. 데이터베이스 수업을 들으며 잘 알고 있다고 생각했는데, 식별관계와 비식별관계도 잘 몰랐고 그냥 많이 몰랐다.
무엇보다 직접 쿼리문을 짜는게 아니라 Spring Data Jpa를 통해 접근하다보니, jpa 메서드의 동작 방식에 대해 전무했던 것 같다.
지금 하고있는 책 스터디가 끝나면 ORM책 스터디를 할 생각이다,
3. 앱프론트와의 협업
api만 만들어주고 테스트만 잘 하면 되긴 한다. 다만 swagger명세서를 좀 더 자세히 써 주지 못한 점이 미안하다. 그리고 결과물을 눈으로 보고싶은데, 실시간으로 볼 수 없는게 조금 아쉽다.
어쩌다보니 이번 기프 개발팀이 밋업 개발팀이 되었는데, 많이 보완해보자
2-3. Try
1. 해 보지 못한 기능에 대해 도전하기
소셜로그인, 스프링시큐리티, jwt, 토큰관리, 로그정제, 사용자예외, 논리삭제 등 못했던거 다 해보고 싶다. 물론 전부 내가 하지는 못할테니, 내가 맡을수 없는 부분에 대해서는 코드리뷰를 열심히 하도록 할것이다.
2. ci/cd 더 자세히 이해하기 + 무중단배포
현재 ci/cd 동작 과정을 100프로 이해하지는 못했다. 프로덕션 환경과 디벨롭 환경, push와 PR생성 등을 구분하여 만들고 싶다. 그리도 도커에 대해서도,,, 더 잘 이해하자
그리고 깃허브액션을 통한 ci/cd 과정이 너무 오래 걸리는 것 같다. 어떻게 시간을 줄이지?
무중단배포... 해보고싶다. 단순 코드를 따라 쳐서 만드는 것이라도 일단 경험해 보고싶다.
3. 테스트코드
기본적이고 기초적인 테스트코드라도 쪼금씩 작성해 보고싶다.
4. 그외
스파게티코드, 중복코드, 더러운코드 작성하지 말자. 그리고 식별관계 사용하지 말자. ㅋ ㅋ ㅋ
