2022 마스터즈 코스(백엔드) 65일차 회고(2022. 4. 8.) - "첫 프로젝트 주간 그리고 소통의 중요성"

해당 글은 코드스쿼드 2022 마스터즈 코스 "Java 웹 백엔드" 과정을 수강하면서 학습한 내용 등에 대한 회고 글입니다. :)

 

수강 회고

프로젝트 과정의 첫 번째 주간이 종료되었다. 이번 한 주는 지난 12주간과 달리 프론트 엔드와 처음으로 협업하는 과정이었으며 아울러 그동안 한번도 봽지 못했었던 Hanse와 처음으로 호흡을 맞추면서 백엔드 시스템을 구성해나갔었던 뜻 깊었었던 한 주였다. 이번 한 주를 보내면서 특히, 프론트 엔드와 협업하면서 많은 것들을 배울 수 있었는데, 그 중 하나가 바로 '소통의 중요성'이었다.

 

나름대로 API를 설계할 때 프론트 엔드 단에서 어떻게 처리하는 게 편할지를 곰곰이 생각해보고 설계를 해보았지만, 실제 프론트 엔드와 해당 API와 관련해서 협의를 진행하면 수정되는 일이 잦았는데, 이는 프론트 엔드 단 나름대로 해당 데이터들을 처리함에 있어 여러가지 애로 사항들이 많았던 것이다. 즉, 기능 구현을 위한 API를 만들기까지 프론트 엔드와의 충분한 의사소통이 필요한 것이다.

 

프로젝트를 진행하는 중에 크롱이 갑작스럽게 우리 팀 프로젝트 줌 회의실에 방문한 적이 있었다. 그때 크롱이 했었던 말 중 가장 인상깊었던 말이 있었는데, "일반적으로 프론트 엔드는 백 엔드에 질문이 많은 반면, 백 엔드는 프론트 엔드에 질문이 거의 없는 편"이라는 것이었다. 해당 말을 들었을 때 솔직히 부인할 수 없었는데, 이는 백 엔드와 프론트 엔드의 역할과 책임과 관련이 있다는 생각이 들었다.

 

웹 서비스의 화면 구성을 담당하는 것은 프론트 엔드이며, 프론트 엔드는 사용자와 직접적으로 대면하게 된다. 이때 더 나은 UX를 제공하기 위해 프론트 엔드 입장에서는 백 엔드로부터 응답받는 데이터의 값과 계층 등에 관심을 가질수밖에 없고 이는 질문으로 이어질 수밖에 없다는 생각이 들었다. 반면 백엔드 였던 나는 내가 응답한 데이터를 프론트 엔드가 적당히 사용하기를 기대하고 프론트 엔드에 무심했었던 것 같고 이는 프론트 엔드에 별다른 질문을 안 하게 된 결과로 이어졌던 것 같다.

 

하지만 하나의 '웹 서비스'를 제공함에 있어 프론트 엔드와 백 엔드는 한 배를 탄 것과 마찬가지라는 생각이 들었다. 아울러 백 엔드는 프론트 엔드의 요청에 응답하기 위해 존재하는 것이 아니라 더욱 근본적으로 사용자의 편익을 제고하는 서비스를 제공하기 위해 존재하며 백엔드는 이와 관련해서 프론트 엔드와 충분한 소통이 필요하다는 생각이 들었다.

 

개개인이 힘을 합쳐 팀으로써 함께 이뤄내는 것은 팀, 회사, 사회를 제대로 작동하게 하는 원동력이다.

 

- Vince Lombardi -           

 

 

학습 회고

• 투두리스트 구현 프로젝트
  
  • 팀원들(백 엔드 2명, 프론트 엔드 2명)과 zoom 회의실에서 학습

 

객체 지향 설계 5원칙 中 단일 책임 원칙

어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.(로버트 C. 마틴) 이 말은 클래스의 역할(책임)을 분리하라는 것이다. 즉, 하나의 클래스에 각종 성격의 속성과 메서드를 집약시키지 말고 각 성격에 따라 역할 및 책임을 분리하여 클래스를 나누라는 것이다.

 

이러한 원칙은 클래스의 분할뿐만 아니라 속성, 메서드, 패키지, 모듈, 컴포넌트, 프레임워크 등에도 적용할 수 있는 개념이다. 예를 들면 하나의 속성이 여러 의미를 갖는 경우도 단일 책임 원칙을 지키지 못하는 경우다. 심지어 데이터베이스 테이블을 설계할 때도 이러한 단일 책임 원칙을 고려해야 한다. 데이터베이스 테이블을 설계할 때는 정규화라고 하는 과정을 거치게 되는데, 정규화 과정을 조금 더 확장해서 생각해 보면 테이블과 필드에 대한 단일 책임 원칙의 적용이라고 할 수 있다.

 

만일 강아지라는 클래스 안에 소변보다() 메서드가 있다고 가정했을 때 하나의 메서드 안에 수컷 강아지의 행위와 암컷 강아지의 행위를 모두 구현하려고 하면 단일 책임 원칙을 위배하고 있는 것이다. 메서드가 단일 책임 원칙을 지키지 않을 경우 나타나는 대표적인 냄새가 바로 분기 처리를 위한 if문이다. 이러한 단일 책임 원칙은 객체 지향 4대 특성 중 모델링 과정을 담당하는 추상화와 가장 밀접한 관계가 있다.

 

 

좋았던 점

• 이번 한 주간 같은 백엔드 클래스 팀원 Hanse 그리고 프론트 엔드(Khan, Nick)와 협업하면서 '팀 플레이'를 할 수 있어서 좋은 경험을 많이 얻을 수 있었습니다. 👍

 

 

아쉬웠던 점

• 당초 목표했던 것 대비 기능을 구현하지 못한 점이 다소 아쉬웠습니다. 👀

 

 

이전 보다 개선되었던 점

• 스프링 웹 앱을 개발하면서 이전 보다는 더 나은 개발을 하는 듯한 기분이 들었던 한 주였습니다. 🥕

 

 

참고자료

• 위키북스 출판 '스프링 입문을 위한 자바 객체 지향의 원리와 이해'