2021 - 겨울방학 회고

2021년 3학년 2학기 겨울방학, UMC 에서 매칭된 팀원들과 개발한 어플을 play 스토어에도 올렸다.  잘 했다고 생각한 부분도 있지만 부족했던 점, 앞으로 배워야할 점도 많았다고 생각하기에 이를 기억하기 위해 남긴다. 나중에 다시 본다면 지금 몰랐던 것들에 대해 부끄러웠을 수도 있다고 생각하지만...어쨋든 지금은 잘 몰랐기에 앞으로 알아가야겠다고 생각한다...

크게 '프로젝트 개발에 있어서 고려했다면 좋았을 점들', '내가 더 노력해야할 부분', '해보니 괜찮았던 것들' 로 작성할 예정이다.

1. 프로젝트 개발에 대하여

깃허브 브랜치를 나눠갖고 본격적으로 개발 시작하기 전에 이러면 좋지 않았을까 했던 점들에 대해 남긴다.

1. dto 매핑 방식에 대해 명확히 하기

 MapStruct 를 이용하여 enity <-> dto 매핑을 진행했는데, 팀원들마다 매핑하는 방식이 조금씩 달라서 '음?' 하게 되는 경우가 있었다.

 @Mapping 어노테이션을 사용하지 않으면 Entity와 DTO 에서 같은 이름을 갖는 것끼리 자동으로 매핑을 해주지만, target, source, qualifiedByName, expression 등을 통해 원하는 방식으로 매핑을 진행할 수도 있다.
 이런 자유도, 편의성 때문인지 domain, service 에서 적절한 가공을 모두 거쳐서 매핑으로 넘어올 때도 있지만, 일단 데이터를 넘긴 다음에 qualifidByName, expression 등에서 메소드를 통해 가공하기도 했다.
 데이터마다 가공되는 지점이 다르다보니 나중에 dto 가 더 많아지게 되면 자칫 실수가 있을 수도 있겠다는 생각이 들었다. 둘 다 어떤 게 맞다고 할 수는 없지만 어느 정도의 가이드라인이나 통일성이 필요하다고는 느꼈다.

 

2. global 에 들어가는 메소드들에 대해서는 생성, 수정, 삭제에 대해 더 확실히 팀원에게 알리기

 프로젝트 구조는 크게 domain - global - infra 로 나누었다. github 에서 나름 1목적 = 1PR 을 지키며 서로의 작업 상황을 쉽게 모니터링하려 노력해도, 프로젝트를 진행하다 보니 global, infra 쪽의 변화를 놓치는 일이 있었다. 그럴 때면 어떤 에러인지도 모르고 정처없이 헤매다가 파일이 바뀌었음을 알게 될 때가 있었다.
 github 에서 최대한 명료하게 메시지를 남기고, slack 으로도 github 알림을 받고 했지만, 다들 사람이기 때문에 잊어버릴 경우가 있다...ㅎㅎ 적절한 메시지를 남겼더라도 팀원들에게 한 번 더 강조를 해주는 게 좋을 것 같다고 생각했다.

 

3. 팀원들과 기술 수준에 대해 충분히 논의하기 (서로의 수준을 잘 모르는 상황의 토이 프로젝트의 경우!)

 프로젝트 시작 전 내가 공부했던 수준은 Spring boot 를 처음 공부해서 JDBC Template 을 겨우 사용하던 수준이었다. 그런데 이번 프로젝트에서 만난 팀원분들은 Spring boot 로 개발해 본 경험이 있었고, 그 분들 입장에서 나도 이 정도는 알 거라고 생각하시는 바람에 Spring data JPA, MapStruct, junit5, Querydsl 등을 사용했었다. 프로젝트 내내 헐레벌떡 새로 추가되는 코드를 따라가기 바빴던 것 같다...
 개발을 하면서 당연히 내가 아는 것만 할 수는 없지만, 내 지식 수준에서 다소 멀리 있는 것을 급하게 따라가다보니 선뜻 적극적으로 아이디어를 내거나, 버그를 수정하거나 하기가 쉽지 않았던 것 같다...결과적으로는 의도치 않게 잘 하는 팀원이 개발을 주도하고, 나는 모두 마련된 도메인에 메서드 몇 개, API 몇 개만 추가하는 식으로 할 수 밖에 없었다. 잘하는 팀원은 혼자 고려해야할 점이 너무 많아서 스트레스가 있었을테고, 나도 도움을 주고 싶지만 줄 수 없는 것에 적잖이 힘들었었다.
 뒤에 쓸 '2-2. 솔직해지기' 와도 연관이 있는데, 프로젝트에 사용하는 기술에 대해 팀원 간 지식 차이가 많이 나게 되면 실력이 부족한 팀원은 개발보다는 새로 공부를 하느라 시간이 지체되고, 결국 개발일정에 맞지 않으면 잘 하는 팀원이 많은 도움을 줘야하는 상황이 발생하기도 해서, 팀원 간 기술 수준에 대해 충분히 이야기를 하고 토이프로젝트에서 사용할 기술 수준을 정하는 것이 중요하다고 생각하게 되었다.

 

2. 내가 부족했던 부분, 앞으로 개선할 점, 공부할 점

1. 큰 숲을 먼저 보려고 노력하기

 프로젝트 파일 계층구조, Entity 혹은 DTO가 상속할 공통 추상 클래스, controller, service layer 예외 처리에 대한 우리끼리의 컨벤션, 그 외 여러가지 결정해야 할 것들.
 팀플레이기 때문에 코드 스타일을 최대한 통일해야 하는 건 맞다고 생각한다. 그러나 이렇게 구색을 맞추어 프로젝트를 진행한 것은 처음이라, 너무 많은 것들을 미리 정하려고 조바심을 낸 것 같다. 미리 규칙을 정해두고 따른다면 분명 추후 발생할 문제들은 적어지겠지만, '이럴 수 있지 않을까?' 로 시작한 걱정들까지 프로젝트에 미리 담아서 시작하려고 하니 첫 삽을 뜨기까지 생각보다 오래 걸리게 되었다.
 최대한 많은 것을 고려해서 중간에 급히 수정하는 것 없이 프로젝트를 이어가는 것은 물론 좋지만, 의견교환이 규칙적으로 이뤄지고 있고, 코드리뷰도 있고, 소통할 기회가 적지 않다면, 당장 고려해야 하는 결정사항에 대해서만 미니멀하게 정한 후, 추후 방향을 수정해 가는 방식이 더 맞는 것 같다는 생각이 들었다.

 미리 많이 정해두면, 중간에 바꾸기가 생각보다 쉽지 않다...중요한 틀만 가진 채로 가볍게 시작하는 게 초반 피로도 적고, 수정도 용이하고 좋을 것 같다..

 

2. 솔직해지기

 새로운 기능을 추가해야 하거나 PR 코드리뷰 등을 통해 어떠한 요구사항이 생겼을 때, '조금 공부해보면, 찾아보면 나오겠지' 하고는 일단 해보겠다고 한 일들이 있다. 그런데 이런 요구사항이 있을 때, 보다 정확하게 대답을 해야겠다고 생각하게 되었다...
 요구사항에 대해 어떻게 해야할지 잘 모르는 경우가 대부분이었다. 그래도 하나하나 다 모른다고 할 수는 없으니, 일단 '알겠다' 고 한 뒤에 공부를 시작하곤 했다. 이 부분이 소통 미스였던 것 같다. 내 입장은 '내가 아는 부분은 아니지만, 일단 찾아보고 해보겠다.' 였지만, 상대한테는 이런 말을 전달한 적이 없으므로 '아 할 수 있나보구나' 가 된 것이다. 때문에 일을 처리해야 하는 순서가 조금 안맞게 되거나, 내가 하다가 다른 사람이 중간에 처리해주거나 하는 일이 있었다.
 일을 맡기 전에 '이 부분은 알고, 이 부분은 모르기 때문에 조금 찾으면서 해봐야하는데 괜찮을까요', '이 부분은 처음 해봐서 공부하며 해야할 것 같은데 괜찮을까요' 처럼 상대 입장에서 작업이 어느 정도 속도로 진행될 지 파악할 수 있도록 말해줘야겠다고 생각하게 되었다.

 

3. 앞으로 공부해야할 내용들은 셀 수도 없이 많기 때문에 적을 수가 없다...ㅋㅋ

 

3. 해보니 괜찮았던 것들, 앞으로 유지해도 괜찮다고 생각하는 점

1. 무엇이 문제이고, 어떤 시도를 해보았고, 어떤 결과를 원하는지에 대해 분명히 정리하여 질문하기

이번 프로젝트는 나보다 경험이나 지식이 더 많은 팀원들과 프로젝트를 진행했기 때문에, 사실 PR을 올릴 때마다 정말 꼼꼼히 검토하고...실수한 것은 없나 적지 않게 긴장을 하곤 했다..ㅎ 
 Spring data JPA, MapStruct 를 써보는 게 처음이라 JPA 코드에 대한 수정 요청, Entity<->dto 매핑 방식에 대한 수정 요청 등이 있었는데, 처음이다보니..솔직히 어떻게 바꾸면 될 지 감도 오지 않을 때가 많았다...그래서 코드 리뷰가 있을 때마다 대부분 다시 질문을 했어야 하는 상황이었고, 나름 질문하는 요령을 생각해보기도 하였다.

1. 구체적으로 무엇을 구현하고 싶은지 (어떤 결과를 얻고 싶은지) 설명하기
2. 그러기 위해 어떤 로직을 생각해보았는지
3. 해당 과정에서 무엇이 문제여서 고민하기 시작했는지
4. 마지막으로 어떤 글, 레퍼런스를 참고해보았는지

 이러한 형식에 따라 질문하려고 노력했다. '질문 잘 하는 법' 도 어딘가에는 best convention 이 있을 것 같다고 생각하지만, 적어도 질문을 받아준 팀원들과 내가 이야기를 나눌 때에는 꽤 괜찮은 방식이었다. 질문을 잘 이해하지 못하거나, 내가 아는 내용을 반복하거나 하며 서로 시간 낭비하는 일 없이 내가 모르는 것을 해결할 수 있었다.

 

2. 깃 브랜치 전략 정하기

https://gmlwjd9405.github.io/2018/05/12/how-to-collaborate-on-GitHub-3.html

[GitHub] GitHub로 협업하는 방법[3] - Gitflow Workflow - Heee's Development Blog

https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html

[GitHub] Git 브랜치의 종류 및 사용법 (5가지) - Heee's Development Blog

 깃 브랜치 전략에 관해서는 위 블로그가 많은 도움이 되었고, 실제로 프로젝트를 저렇게 진행하였다. 규모가 큰 단체도 아니고, 실제로 일을 하는 것도 아니기 때문에 '굳이 저렇게까지..?' 하고 생각할 수 있지만, 오히려 이렇게 실수해도 괜찮을 때에 연습을 해둬서 잘했다고 생각한다.
 초반에는 pull 하지 않고 누군가가 push 를 했다거나...수정된 submodule 을 먼저 push하지 않고 작업내용을 바로 올려버려서 submodule 버전이 꼬였다거나...main 이 복구 불가능할 정도로 꼬여서 develop으로 덮어썼다던가...해프닝이 꽤 많았지만, 생각보다 모두들 금방 적응해서 열흘 정도 지났을 때는 다들 문제 없이 branch 를 다루었던 것 같다.

같은 내용을 다루는 다른 글들도 굉장히 많은 편이니 각자 읽기 편한 글을 찾아보면 될 것 같다.

 

3. 커밋 및 PR 컨벤션 정하기

커밋이나 PR 을 올릴 때는 위와 같이 (적절한 이모지 + 작업 내용 명사형 + #이슈발급번호) + (적절한 라벨) 의 포맷으로 컨벤션을 통일하였다. 이것도 처음에는 '어차피 다 한글로 적으면 알 수 있는데 굳이..?' 싶은 느낌이었지만, Issue 나 Pull Request 가 쌓이다 보니까 저렇게 포맷을 통일해둔 게 이전에 했던 작업을 찾기에 확실히 수월했었다.

Intellij 플러그인

Intellij git (ctrl + k)을 통해 commit, push 를 진행했었는데, 플러그인 창에서 위 이미지와 같은 플러그인을 설치하면 귀여운 이모지를 쓸 수 있다...이모지 규칙은 기본 부연설명 되어있는 용도 그대로 사용하였다.

 

지난 겨울방학도 정말 재미있었지만, 다시 협업을 하게 될 때는 더욱 잘할 수 있도록 노력하기 위해 기록을 남긴다.
다음 협업까지는 부족한 기술스택 공부에 집중해야겠다..!