2022 마스터즈 코스(백엔드) 70일차 회고(2022. 4. 15.) - "즐겁고 재밌었던 첫 번째 팀 프로젝트"

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

 

수강 회고

오늘로 지난 2주간 진행되었던 프로젝트 과정의 첫 번째 미션 투두리스트 구현 프로젝트가 종료되었다. 이번 미션 과제의 경우 백 엔드 2명과 프론트 엔드 2명이 팀을 이루어 과제를 수행하는 방식으로서 지금까지의 미션 과제들 보다 더욱 특별했었다. 지난 2주라는 시간을 되돌아 보았을 때 깃(Git), 스프링(Spring), 데이터 베이스(Database), AWS, 문서(Document) 작성 등 개발과 관련된 많은 것들을 학습할 수 있었는데, 무엇보다 가장 가치가 있었던 학습은 '협업'에 관한 것이었다.

 

백 엔드와 프론트 엔드간의 협의 사항 중 최대의 접점은 API와 관련된 것이었다. HTTP API 메서드(GET, POST 등), URI, 그 중에서도 특히 json 데이터 속성 및 구조에 관해서 많은 논의와 소통이 이루어졌었다. 이에 대해 논의하는 과정에서 프론트 엔드 팀원들께서 많은 의견들을 주셨고 백 엔드였던 나와 Hanse는 그 의견들을 최대한 반영하고자 하였는데, 결과론적으로 프론트 엔드 팀원들께서 주셨던 의견들이 웹 앱의 원활한 기능에 도움이 되는 요소들이 많았었다.

 

이번 팀 프로젝트를 진행하기에 앞서 우리 팀원들이 프로젝트에 임하는 마인드를 정한 것이 있었는데 다음과 같았다.

 

1. 재밌게 하자

2. 즐겁게 임하자

3. 최대한 많이 소통하자

4. 기능을 다 만들어 보자

 

우선 '재밌게 그리고 즐겁게' 프로젝트에 임하는 것은 성공할 수 있었던 것 같다. 지난 2주 동안 프로젝트를 진행하면서 오전 스크럼 시간(10:00 ~ 10:30)과 오후 스크럼(17:00 ~ 18:00) 시간을 통해 각자의 일상 얘기들을 통해 친목을 다질 수 있었다. 이렇게 아이스 브레이킹 시간을 가지고나니 업무 협의 함에 있어서 좀 더 편안하게 서로간 다가갈 수 있었던 것 같았고 나중에는 서로간 약간의 장난을 칠 수 있을 정도까지 친해졌었던 것 같다. 특히, 백 엔드였던 나와 Hanse는 공통적으로 '휴식'을 중요시 여겼는데, 너무 미션 과제에 치이지 않고 적당히 휴식을 취해준 덕에 지난 2주 동안 좀 더 프로젝트에 활기차게 참여할 수 있었던 것 같다.

 

'최대한 많이 소통하자' 역시 성공할 수 있었던 것 같다. 이번 프로젝트를 하면서 한번도 프론트 엔드 팀원들과 다툼이 없었는데, 이는 백 엔드였던 우리(나와 Hanse)도 프론트 엔드의 의견을 수렴하려고 노력했었지만 무엇보다 프론트 엔드였던 Khan과 Nick 역시 백 엔드의 의견을 적극적으로 반영하고자 노력해주신 덕이라는 생각이 들었다. 실제로 이번 프로젝트를 진행하면서 충분히 백 엔드와 프론트 엔드간 논쟁의 여지가 있는 이슈들이 여럿 있었는데, 서로의 의견을 존중하고 최대한 많이 소통하려고 노력했었기에 무사히 진행될 수 있었던 것 같다.

 

마지막으로 '기능을 다 만들어 보자' 역시 어느 정도 달성할 수 있었던 것 같다. 사실 나 역시도 지난 웹 백엔드 과정 중 특히 스프링 웹 앱 미션을 하면서 테스트 코드, 예외 처리, 인증 처리 등을 만들면서 정작 기능을 다 구현하지 못했었던 것이 아쉬움으로 남았었는데, (사실 해당 작업들은 반드시 해야하는 매우 중요한 작업들이긴 하다. 😅) 팀원 중 한 분께서 이번 팀 프로젝트에서 기능을 다 구현해보고 싶다는 의견을 주신데다가 첫 번째 프로젝트인 만큼 백 엔드와 프론트 엔드간 '협업' 경험을 익히고자 '기능 구현에' 좀 더 초점을 맞추기로 했었다. 결론적으로 기획서 상에 나온 모든 기능을 다 구현한 건 아니지만, 우리 팀이 당초 목표 했었던 기능들은 다 구현할 수 있었으며 배포(AWS)까지 성공할 수 있었다. (역설적이게도 막상 기능을 구현하고 나니 인증, 예외처리, 테스트 코드 등의 작업을 소홀히 한 게 아쉬워진...😅)

 

종합적으로 이번 첫 번째 팀 프로젝트는 재밌었고 유익했었던 경험이었다. 비록 우리가 완벽한 웹 앱을 만든 것은 아니지만 각자가 첫 번째 협업이었음에도 불구하고 '협업'을 위해 상호를 존중할 수 있었고 그 과정에서 개발 지식 및 경험 뿐만 아니라 협업을 위한 소통 방식 등도 많이 배울 수 있었다. 다음주부터는 새로운 조원들과 새로운 프로젝트 과제를 수행하게 될텐데 지난 2주간의 팀 프로젝트 경험을 통해 '보다 더 나은 웹 앱'과 '보다 더 나은 협업'을 이루고 싶은 욕심이 있다. 아무쪼록 지난 2주를 잘 보낼 수 있었던 것은 나의 노력 보다도 우리 팀원들의 노력이 있었기에 가능했었던 것이라고 생각된다. 지난 2주간 팀 프로젝트에 열심히 임해주셨던 Hanse, Khan, Nick 모두에게 감사의 인사를 드리고 싶다.

 

 

학습 회고

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

 

야생형으로 프로그래밍하는 편이라 스프링 웹 앱 개발 기초에 소홀히 하고 있었는데 요즘 김영한님의 인프런 강의를 수강하면서 많이 배우고 있습니다. 관련해서 SOLID 원칙의 중요성에 대해 자주 언급해주시는데, 어제에 이어서 SOLID 원칙을 살펴보았습니다.

 

의존 역전 원칙

1. 고차원 모듈은 저차원 모듈에 의존하면 안 된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.
2. 추상화된 것은 구체적인 것에 의존하면 안 된다. 구체적인 것이 추상화된 것에 의존해야 한다.
3. 자주 변경되는 구체 클래스에 의존하지 마라.

 

만일 자동차 클래스가 스노우 타이어, 일반 타이어, 광폭 타이어 중 하나를 의존한다고 해보자. 이때 각각의 타이어 클래스들은 언제든지 변경될 수 있다. 즉, 각각의 타이어 클래스들은 구체적인 클래스라고 볼 수 있으므로 이는 의존 역전 원칙에 위배되는 것이다.

 

이러한 상황에서 의존 역전 원칙을 적용한다면 자동차가 추상화된 타이어 인터페이스에만 의존하게 함으로써 스노우 타이어에서 일반 타이어로, 또는 다른 타이어(구체적인) 클래스로 변경돼도 자동차 입장에서는 그 영향을 받지 않게 된다. 이는 개방 폐쇄 원칙과 일맥상통하는 내용이다.

 

이때 스노우 타이어, 일반 타이어, 광폭 타이어 클래스 입장에서는 기존에 그 무엇도 의존하지 않았었으나 추상적인 타이어 인터페이스에 의존하게 됐다. 즉, 의존 관계가 역전된 것이다. 이처럼 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 것이 의존 역전 원칙이다.

 

상위 클래스일수록, 인터페이스일수록, 추상 클래스일수록 변하지 않을 가능성이 높기에 하위 클래스나 구체 클래스가 아닌 상위 클래스, 인터페이스, 추상 클래스를 통해 의존하라는 것이다.

 

 

학습 참고자료

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

 

 

좋았던 점

• 지난 2주간 개발 관련 지식 및 경험뿐만 아니라 협업 경험도 많이 할 수 있어 유익한 시간이었고 무엇보다 재미있고 즐겁게 할 수 있어서 좋았습니다!! ✨

 

 

아쉬웠던 점

• 막상 기능을 구현하고나니 인증, 예외처리, 테스트 코드 등 작업에 소홀히 한 점이 아쉬웠습니다. 💦

 

 

이전 보다 개선되었던 점

• 2주라는 시간은 어떻게 보면 아주 짧은 시간이지만 분명한 건 2주 전의 나보다 현재의 내가 개발 관련해서나, 협업 관련해서나 더욱 성장할 수 있었다는 것을 느낄 수 있었습니다. 마스터즈 코스 과정 한 주 한 주를 통해 많이 배우고 있습니다. 👍