[Main-Project] 회고

작업 레포지토리 

GitHub - codestates-seb/seb39_main_045: 🌵선인장 키우기🌵

Main-Project  챌린지 웹 서비스 

나만의 챌린지와 함께 선인장을 키워보세요

---

 

팀장의 Role

Pre-Project에 이어 Main-Project에서도 팀장의 역할을 수행했다.

이전 프로젝트에서 회고한 것을 바탕으로 조금 더 나아진 모습으로 Main-Project에 임하기로 했다.

조금 더 체계적이고 명확한 일정 관리와 업무 분담을 위해 Github의 Issues를 활용하여 기능 단위 별로 마일스톤과 프로젝트 칸반을 활용했다.

프로젝트 끝날 때 보니 Pull Request를 비롯한 264개의 이슈가 있었다. 

확실히 팀원과 커뮤니케이션이 잘 되면 될 수록 이러한 협업 툴로 관리하기 편했다.

군 부사관을 지내오면서 겪은 수직적인 리더쉽과는 다르게, 수평적 리더쉽을 발휘해야 했는데

내가 가장 잘하는 사람이며 모든 팀원들의 역량과 성향을 파악을 해뒀어야 하는 강박을 벗어나

내가 조금 부족하고 힘들 때, 팀원과의 활발한 커뮤니케이션을 통해 내려놓을 수 있었다고 생각한다.

어느 누군가가 부족한 만큼 다른 팀원이 그것을 채워줄 수 있는 그러한 팀이 되었다고 생각한다. 앞으로 실무, 현업에서 협업할 때에 필요한 경험을 했다고 생각한다.

팀원 모두가 유기적으로 자기 객관화를 통한 일정, 업무 분담 토의를 진행했기에

프로젝트가 성공적으로 기한 내에 끝날 수 있었다. 팀원 모두에게 너무 감사하고 좋은 것을 배웠던 경험이었다.

---

프론트엔드와의 협업

 

기술적인 오류를 마주하는 것 이상으로 프론트엔드와의 협업에서 발생하는 소통 문제도 많았다.

공통의 프로젝트를 완성하는 과정에서 서로에게 요구사항이 발생하면 그것을 엄밀한 기술로 설명을 할 필요가 있었는데

이 과정에서 서로가 서로의 스택을 잘 모르다보니 같은 이야기를 해도 이해를 못하는 상황이 많았다.

프론트엔드와 백엔드 스택이 나뉘어있지만 협업을 위해서는 서로의 요구사항을 이해할 정도의 지식은 가질 필요가 있었다고 생각한다.

엄밀하게 생각하면 클라이언트의 요청을 일방적으로 받는 서버의 입장에서는 dto 하나로 소통하면 되는 것이 맞다.

어떤 데이터로 요청이 오고 그것을 어떻게 응답을 하는지에 대한 것들만 명확히 이해하고 원활하게 소통을 할 수 있었다면

이러한 답답함을 느끼지 않았을 것이라 생각한다.

API 명세서 또는 문서를 체계적으로 작성을 했더라면 발생하지 않았을 문제였다.

취업 준비생의 입장에서 각 스택 별로 서로 원하는 것이 어떤 것인지 이야기하는 것에 대해서는 어쩔 수 없었다고 생각은 하지만, 프로젝트가 끝난 시점에서 앞으로 협업을 하게 된다면 

위와 같은 엄밀한 dto, API 명세를 바탕으로한 소통이 요구될 것이라 생각하며
원활하기 위해서는 많이 경험해보고 정확한 API 설계가 필요하고 

무엇보다도 웹 개발에 필요한 기본 지식을 체계적으로 학습할 필요가 있다고 생각했다.

---

설계의 어려움

Pre-Project에서 했었던 스택오버플로우 클론 프로젝트의 경우 

이미 눈에 보이는 영역이 많았기에 어떤 기능으로 요청과 응답을 하는지 금방 파악을 했었지만

이번 Main-Project에서는 처음부터 끝까지 설계를 해야 했기에

직접적인 코딩 시간보다 설계, 토의하는 시간이 길었다.

Spring Data JPA를 기반으로한 엔티티 설계부터 

어떤 기능을 구현할지, 그러한 기능을 어떤 기술로 구현할지 고민이 참 많았던 것 같다.

토의 하면서 왜 이렇게 설계를 해야 하는지, 다른 방법은 없는지, 있다면 어떤 부분에서 장단점이 존재하는지

이러한 사고의 흐름을 뒷받침하는 여러 지식들을 학습해야했다.

---

DDD?

 

학습이 부족하여 전체적인 아키텍처도 부분 부분 검색해가면서 완벽하게 구현하진 못했다.

대표적으로 DDD(Domain Driven Design) 도메인 주도 설계를 적용하기로 했는데

이것에 대한 고민이 깊지 않았던 점이 아쉬웠다.

Pre-Project에서 설계했던 것은 

객체가 가져야 할 데이터에 초점을 맞춘 데이터 주도 설계였다.

필요한 엔티티부터 구성을 하고 그것에 맞는 계층 패키지를 설계했었는데

이럴 경우, 과도한 접근자나 수정자가 발생하고 이후에 어떤 곳에 사용될지 애매한 상황이 발생하게된다.

대부분 구현이 외부에 노출되기 때문에 캡슐화의 원칙을 위반하기도 한다.

내부 구현이 퍼블릭 인터페이스에 노출돼서 다른 객체와 강하게 결합하게 된다.

그래서 객체 내부 구현이 변경이 되면 이 인터페이스에 의존하는 모든 객체가 함께 변경돼서 높은 결합도를 유지할 수 밖에 없다.

요구사항, 소프트웨어로 해결하려는 영역에서의 도메인을 중심으로 아키텍처를 설계하는 것이 어떠한 장점이 있는지 엄밀하게 생각했어야 했다.

---

MSA?

 

모놀리스 아키텍처와 마이크로 서비스 아키텍처라는 개념이 있다.

소프트웨어를 어떤 방식으로 설계하는지

각각의 장단점이 무엇이고 개선점으로 어떤 것들이 나왔으며 

나오게 된 배경과 자세한 설계 방식에 대해 학습하는 것과 고민하는 시간이 없었다는 것이 후회로 남는다.

잘 모르다보니 어중간하게 클론에 가까운 방식으로 어떻게든 클라이언트와 api 통신을 하는 목적으로 난잡하게 설계했었다. 

Pre-Project와 Main-Project 둘 다 그런 고민 없이 진행 했었다.

서비스가 동작하기만 하면 된다는 식으로 이러한 근원적인 고민을 하지 않고 무작정 코드부터 쳤었던 나는 매우 무지했다 라고 생각하고 반성하고 있다.

취업해서 실무에 들어가기 전까지 이러한 근원적인 지식을 이해하고 갈 필요가 있겠다고 생각했다.

이와 관련된 내용은 공부하여 블로그에 따로 포스팅할 생각이다.

 

---

배포와 자동화에 대한 이해 부족

 

AWS를 사용하는 이유

어떠한 서비스들이 제공되고 각각 어떤 장단점이 있어서 적절히 선택하여 적용했는지 고민하기에는 너무나 방대한 내용과 난도였다고 생각한다.

공식문서를 읽고, 레퍼런스를 찾아보며 따라하기 바빴다.

수 많은 오류와 마주했지만 따로 정리해두지 않았던 점이 가장 큰 후회된다.

회고를 남기는 이 순간 이후로 내가 했던 부분에 대해 엄밀한 내용 정리와 이해가 필요할 것이다.

모든 건 

왜?

어떻게?

다른 건 어떤데?

등등 의문을 가지며 하나 하나 학습해야 그 다음 단계로 성장할 수 있다고 생각한다.