2022 마스터즈 코스(백엔드) 40일차 회고(2022. 3. 4.) - "협업에는 친화력도 중요하다."

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

 

수강 회고

오늘로 코드스쿼드 마스터즈 코스 수강 40일차가 되는 날이다. 나이가 들수록 매년 시간이 빠르게 지나간다고 생각하는데, 특히나 마스터즈 코스를 수강하면서 2개월이라는 시간은 더욱 금방 지나간 것 같다. 그리고 이제는 뭔가 그룹 스크럼, 마스터 클래스 강의, 그룹 리뷰 등이 일상처럼 편하게(?) 느껴지고 있다.

 

예전에는 그룹원들과 그룹 스크럼이나 그룹 리뷰 시간에 주로 미션 과제와 관련된 내용을 주로 얘기했었다면 요즘에는 그룹원들과 일상적인 얘기도 종종 하고 있다. 확실히 미션 과제와 같은 업무적인 얘기 보다는 일상적인 얘기를 주고받는 것이 소그룹원들과 친밀한 관계를 쌓기에는 효과적인 것 같다. 나는 이러한 면에서 그룹 스크럼이나 주간 회고 같은 시간이 내게 유익하다는 생각이 들었다.

 

왜냐하면 실제로 회사에서 팀원들과 같이 협업을 할 때는 팀원간의 업무적인 팀워크 능력도 중요하지만 인간 대 인간으로 친밀함 내지 신뢰 관계를 쌓는 것도 매우 중요하다고 생각하기 때문이다. 이는 일이라는 것도 결국에는 인간이 하는 것이기 때문이다. 물론 업무를 할 때는 사적인 감정을 섞지 않는 것도 중요하지만 인간은 명백하게 감정을 가진 동물이기 때문에 결코 이를 무시할 수 없는 것이다.

 

전 직장에서의 경험을 미루어 보았을 때 회사에서의 직원들의 유형을 나눌 수 있는 여러가지 기준들이 있겠지만 나 같은 경우 이러한 방식으로도 나누어 볼 수도 있었다. 첫 번째 유형은 일은 엄청 잘하지만 친화력(사교성 내지 인간 관계)은 좋지 않은 유형이다. 이 유형의 사람들은 자신에게 주어진 업무 처리는 매우 잘하지만 같은 부서 내지 타 부서 사람과의 관계가 좋지 못할 확률이 높다. 때문에 자신이 추진하는 사업에 대해 타 부서의 협조를 얻기 쉽지 않다. 회사에서 하는 일은 결코 혼자서 할 수 없다. 그렇기 때문에 타 부서와의 협조 관계는 매우 중요하다. 앞서 언급했듯이 업무를 할 때는 사적인 감정을 배제하는 것이 "프로"의 자세지만 인간은 명백하게 감정을 지니고 있으며 무의식 중으로 이 감정이 자신의 생각과 행동을 결정하게 된다.

 

두 번째 유형은 일은 못하지만 친화력이 좋은 유형이다. 이 유형의 사람들은 자신에게 주어진 업무 처리는 못해도 타 부서 사람과의 관계가 좋을 확률이 높다. 다만 타 부서 사람과의 관계가 좋을지라도 같은 부서 내의 사람으로부터는 지지받지 못할 확률이 높다. 일을 못한다는 것은 자신에게 주어진 "역할과 책임"을 제대로 수행하지 못한다는 것이다. 이로 인한 업무 누수는 나머지 팀원들이 부담하게 될 확률이 매우 높다. 아울러 회사에서 일하다 보면 부서간 "업무 핑퐁(떠넘기기)"이 굉장히 성행한다. 이때 이 유형의 사람이 부서장 내지 팀장을 맡는다면 부서간 업무 핑퐁 싸움에서 패배할 확률이 굉장히 높다. 마찬가지로 이로 인한 부담은 소속 팀원들이 지게 된다.

 

세 번째 유형은 인생에서의 마법의 단어 "균형잡인" 일도 잘하고 친화력도 좋은 유형이다. 이 유형의 사람들은 회사별로 다르겠지만 거의 극소수로 존재한다. 이 유형의 사람들은 회사의 중요한 사업 내지 업무를 수행하고 있을 확률이 높으며 회사 내 대부분의 직원들은 이 유형의 사람과 같이 일하고 싶어한다. 또한 이 유형의 사람들을 미워하는 사람들도 "거의" 없다.

 

네 번째 유형은 둘 다 좋지 않은 유형이다. 물론 여기서 유형을 나눈 기준은 "나의 편의상" 다소 극단적인 기준으로 나눈 것으로 실제로는 어떤 기준으로 나누기 힘들 정도로 회사에는 무궁무진하게 다양한 사람들이 존재하며 어떤 유형의 사람이 좋고 나쁘고를 감히 판단할 수는 없다. 다만, 개인적인 생각으로 어떻게 하면 "협업을 잘 할 수 있을지"에 대한 고민을 하다보면 세 번째 유형에 맞는 사람이 되고 싶은 것이 사실이다. 누군가에게는 직장이라는 곳이 단지 돈만 버는 곳이라고 생각한다면 이러한 고민을 굳이 하지 않아도 되겠지만 직장에서 보다 "성장"하기를 원한다면 이러한 고민이 생길 수밖에 없다고 생각한다.

 

아무쪼록 앞으로 프로그래밍으로 업을 삼을 때 결코 혼자서 프로그래밍을 하지 않을 것이며 또한 아주 많고 다양한 사람들과 협업을 하게 될 확률이 굉장히 높을 것이다. 이를 위해 다양한 사람들과 원활히 협업할 수 있는 소프트 스킬을 향상하는 것은 매우 중요하다고 생각한다.

 

이러한 관점에서 나 자신을 되돌아 보면 코드스쿼드 마스터즈 코스 중 주어진 미션 과제를 성실하게 학습하는 것도 중요하지만 주어진 스크럼 활동, 그룹 리뷰 시간 등도 적극 활용하여 팀원들과 미션 과제와 관련된 이야기도 나누고 일상적인 이야기를 나누는 것도 소프트 스킬을 향상시키는데 중요하겠다는 생각이 들었다. 아울러 이러한 생각을 하면서 최근 오전 그룹 스크럼 활동에 소홀했었던 내 자신에 대해 스스로 반성해야겠다는 생각이 들었다.

 

 

학습 회고

• 스프링 부트 관련 미션 과제 풀이
  
  • Java 웹 백엔드 클래스 내 소모임원과 zoom 회의실에서 학습

 

어제에 이어 스프링 부트 미션 1단계와 관련한 코드스쿼드 리뷰어 Dion으로부터 질문 받은 많은 생각거리들과 개선점들을 반영하고 기존 로직을 개선하는 작업을 이어서 진행했다. 오늘 학습했었던 주요 내용으로는 다음과 같다.

 

스프링 웹 앱 단위 테스트(서비스 객체)를 위한 주요 애노테이션

@ExtendWith(MockitoExtension.class)

@ExtendWith(MockitoExtension.class)을 테스트 코드 클래스 위에 명시해주면 해당 테스트 클래스가 Mockito 라이브러리를 사용할 수 있게 된다.

 

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {

}

 

@Mock

@Mock은 실제 구현된 객체가 아닌 Mock 객체(가짜 객체)로 사용되는 것을 의미하는데, 테스트 런타임 시 해당되는 구현 객체가 아닌 Mock 객체가 주입되어 단위 테스트가 진행된다. 이러한 가짜 객체를 만드는 이유는 실제 객체를 만드는데 시간을 절약하기 위함이며 아울러 많은 의존성으로 구현의 복잡함을 해소하기 위함이기도 하다.

 

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {

    @Mock
    private UserRepository userRepository;
    
}

 

@InjectMocks

@InjectMocks는 Mock 객체(가짜 객체)가 주입이 될 대상을 나타낸다. 예를 들면 위 예시에서 UserService의 메서드를 테스트하기 위해서는 UserRespository라는 Mock 객체를 생성하여 UserService에 의존성을 주입해주어야 할 필요가 있는데, 다음과 같이 적용해볼 수 있다.

 

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {

    @InjectMocks
    private UserService userService;

    @Mock
    private UserRepository userRepository;
    
}

 

Given - When -Then Pattern Test

JUnit을 통해 단위 테스트를 진행할 때는 테스트에 대한 일종의 시나리오를  Given(준비) - When(실행) - Then(검증) 형식으로 작성해볼 수 있다. 이러한 형식으로 작성하면 테스트 케이스의 자연스러운 문맥 이해와 함께 추후에 해당 테스트 코드를 유지보수하기도 용이할 것이다. 다음은 이러한 패턴을 적용한 테스트 코드 예시이다.

 

    @DisplayName("사용자가 회원가입 요청 시 사용자 정보가 저장된다.")
    @Test
    void 회원_가입() {
        // given
        given(userRepository.savaUserInformation(userInformation)).willReturn(userInformation);

        // when
        UserInformation result = userService.join(userInformation);

        // then
        assertThat(result).isEqualTo(userInformation);
    }

 

해당 테스트 코드는 웹 사이트에서 사용자가 회원가입을 요청 시 비지니스 로직을 수행하는 UserService 객체의 join 메서드가 해당 사용자가 작성한 데이터 정보를 처리하여 DB에 제대로 저장시킬 수 있는지를 검증하는 코드이다. 우선 Given(준비) 단계에서는 given 메서드 스텁을 통해 Repository 메서드의 기능을 대리하도록 설정했다. 이후 When(실행) 단계에서 테스트하고자 하는 join 메서드를 실행시켰고 Then(검증) 단계에서는 join 메서드의 처리 결과로 반환된 사용자 정보 데이터와 일치하는지를 검증하도록 했다.

 

 

 

좋았던 점

• 엊그제 코드스쿼드 마스터즈 코스 과정이 시작된 거 같은데 벌써 수강일수로만 40일째네요... 단지 대단한 건 아니고 그냥 지금까지 버틴(?) 내 자신이 자랑(?)스럽습니다...😇

 

 

아쉬웠던 점

• 이번주는 오전 소그룹 활동에 소홀히 했었던 점이 아쉬웠습니다. 😥

 

 

참고자료

• https://tech.lattechiffon.com/2021/07/03/junit5%EC%99%80-mockito%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-mock-test-java/
• https://brunch.co.kr/@springboot/292

 

 

 

이미지 출처 : 유튜브 북올림