11월 1-2주차 회고 (Feat. 현명하게 이슈 공유하기)

Intro

인도에 온 지 일주일이 지났다. 많은 우려가 있었지만 생각보다 잘 적응했다. 특히 예전에 조튜브 인도 여행기 영상 보고 엄청 쫄았는데 막상 인도 도착하고서부터는 각종 회사 지원 덕분에 편하게 다녔다. 휴대폰 유심 개통에 시간이 걸려서 초반 3일 정도는 회사-숙소 외에는 어디도 드나들기 힘들었는데(그와중에 숙소 헬스장은 인도 도착한 다음날부터 엄청 잘 다녔다만) 그마저도 인터넷 사용이 가능한 이후부터는 별 문제 없었다.  

 

유튜브에서는 택시/릭샤 잘못 타서 엄청 고생하는 영상 뿐인데 우버 타면 진짜 아무 문제 없이 잘만 다닌다(물론 델리 한복판이 아닌 신도시 구르가온이라 가능한 일이었을지도?). 숙소도 다들 게스트하우스라 불러서 개고생할 각인가 했는데 막상 와보니 고급 아파트를 임대해서 쓰는 형식이라 호텔과 별 다를 바 없었다. 밥도 한식으로 잘 나오고. 게다가 현지 엔지니어 및 다른 팀과도 일할 때 대면으로 빠르게 소통하니 일하기도 훨씬 좋았다. 걱정과 달리 전반적으로 좋은 경험인듯. 물론 이 모든 건 2주짜리로, 상대적으로 짧아서 좋은 기억만 남았던 것일 수도 있다. 반응 보니 다음에는 최소 한 달짜리 출장일 것 같은데, 그때는 또 어떨지 두고보도록 하자. 그럼 회고 시작.

Keep

클린 코드 공부 & 실무에 적용(PR 리뷰)

이번주에는 클린 코드 3장 - 함수 공부한 내용을 블로그에 업로드했다. 확실히 실무를 뛰면서 클린 코드를 접하니 배운 걸 실전에 바로 적용 가능해서 좋았다.  

 

특히 이번 Keep에서는 크게 좋았던 부분이 하나 있었는데, 바로 다른 팀원 PR 리뷰를 봐주면서 배웠던 내용을 바탕으로 피드백을 줬던 경험에서였다. 한 팀원이 올린 PR을 보다가 책에서 배웠던 내용을 발견했다. 먼저 수정 전 코드부터 보자. 보안상 디테일한 내용은 삭제 및 수정하고 명사를 일반화했다.

public List<Partner> getEligiblePartners(Domain domain) {
        List<Partner> partners = partnerService.getActivePartnersByPriority();
        List<Partner> eligiblePartners = new ArrayList<>();
        List<Partner> partnersToBeDisabled = new ArrayList<>();

        for (Partner partner : partners) {
            if (isEligible(domain.getDomain().getApproved(), partner)) {
                eligiblePartners.add(partner);
            } else {
                partner.setStatus(false);
                partnersToBeDisabled.add(partner);
            }

            if (partnersToBeDisabled.size() > 0) {
                partnerService.updatePartners(partnersToBeDisabled);
            }
        }
        return eligiblePartners;
    }

해당 메소드는 파트너 리스트 중에서 Active한 상태의 파트너를 가져온 뒤, 리스트를 순회하며 각 파트너가 특정 자격이 있는지를 판별하고 자격이 있다면 eligiblePartners 리스트에, 없다면 partnersToBeDisabled에 넣는다. 이때 disabled 리스트에 파트너가 하나라도 들어가면 파트너 리스트를 업데이트해주고 최종적으로 자격이 있는 파트너 리스트를 반환하는 함수다. 여기에는 책에서 배웠던 내용 중 세 가지 수정 사항이 있다.

1. 작게 만들어라

함수의 사이즈가 크다. 책에서는 길어야 네 줄이라 했으나 해당 메소드는 15줄이나 된다.

2. 한 가지만 해라

해당 함수는 한 가지 동작만을 하지 않는다. 해당 함수의 동작을 다시 살펴보자.

1. 파트너 리스트 중에서 Active한 상태의 파트너를 가져온 뒤,
2. 리스트를 순회하며 각 파트너가 특정 자격이 있는지를 판별하고
   • 자격이 있다면 eligiblePartners 리스트에 넣고
   • 없다면
     • 파트너의 상태를 false로 바꾼 뒤
     • partnersToBeDisabled에 넣는다.
3. 이때 disabled 리스트에 파트너가 하나라도 들어가면 파트너 리스트를 업데이트해주고
4. 최종적으로 자격이 있는 파트너 리스트를 반환하는 함수다.

2의 세부사항까지 포함하면 사실상 6가지의 동작을 수행한다. 한 가지만 하라는 원칙을 위배한다.

3. 함수당 추상화 수준은 하나로

for문 내의 else문을 보면 다른 라인은 추상화된 함수가 들어있는 반면 여기서는 setter를 그대로 사용한다. 추상화 수준이 라인마다 다른 것을 알 수 있다.  

 

현재 글처럼 일일이 디테일하게 피드백을 주지는 못했다. 하지만 메소드의 의미를 명료하게 나타내기 위해

1. else문에서 추상화 수준을 맞출 것과
2. 메소드 이름에 동작의 의미가 보다 명료하게 포함될 수 있도록 수정할 것을

피드백드렸다. 피드백에 감사히 답변해주셨고, 결과는 아래와 같다.

public List<Partner> getEligiblePartnersByPriorityAndDailyLimit(Domain domain) {
        List<Partner> partners = partnerService.getActivePartnersByPriority();
        List<Partner> eligiblePartners = new ArrayList<>();
        List<Partner> partnersToBeDisabled = new ArrayList<>();

        for (Partner partner : partners) {
            if (isEligibleOnDailyLimit(domain.getDomain().getApproved(), partner)) {
                eligiblePartners.add(partner);
            } else {
                disablePartner(partnersToBeDisabled, partner);
            }

            if (partnersToBeDisabled.size() > 0) {
                partnerService.updatePartners(partnersToBeDisabled);
            }
        }
        return eligiblePartners;
    }

    private void disablePartner(List<Partner> partnersToBeDisabled, Partner partner) {
        partner.setStatus(false);
        partnersToBeDisabled.add(partner);
    }

배운 것을 토대로 피드백드리는 경험을 통해 나 역시 학습 내용을 복습할 수 있었다. 또한, 팀 전체적으로도 도움을 줄 수 있어 좋았다.

Learn

공유하기, 공유하기, 또 공유하기. 협조를 구하려면 계속해서 내 상태를 알려야 한다.

이번 주차 회고도 Learn 파트가 가장 중요했다. 오죽하면 노션 여기저기에다가 전부 다 써놨을 지경이니..  

 

사건은 이전에 올렸던 글인 [동료 피드백 회고]팀원들이 본 3개월 간 내 본모습은?에서 출발한다. 피드백 중에서 이런 게 있었다.  

 

작성한 문서를 조금 더 적극적으로 공유하면 어떨까요?

  

이때만 해도 잘 몰랐다. 현재 무슨 일을 하고 있고 어떤 이슈에 맞닥뜨렸는지에 대해 얼마나 적극적으로 공유하지 않고 있었는지를. 얼마 전 1 on 1에서도 팀 리드님으로부터 비슷한 피드백을 받았다. 일 진행상황에 대해서 더 적극적으로 공유했으면 좋겠다고. 이때도 잘 알아듣지 못했나보다. 여전히 같은 실수를 반복하고 있었다.  

이번에 새로 받은 작업 도메인에서는 레거시 코드를 이해하기가 쉽지 않았다. 문제는 그걸 어떻게든 혼자 해보겠다고 낑낑대느라 정작 이슈를 전혀 공유하지 않았다는데 있었다. 정확하게 객관적으로 말하면 이슈를 공유하긴 했다. 근데 공유 사이사이 기간이 길었다는 것이다. 데일리로 계속해서 어디까지 진행했고 어디가 잘 안된다고 꾸준히 공유했으면 지금보다 훨씬 더 일처리가 빨랐을 것이다. 시니어의 입장에서 보면 별 거 아닌 일이었으니까. 근데 공유를 제때 하지 않으니 한 번에 공유해야 할 일의 사이즈가 커져버렸다. 덩달아 듣는 사람도 한 번에 들어야 할 양이 많으니 도와주기가 버거워질 수밖에.  

 

이 글을 쓰면서 생각해보니 이런 이슈가 한두 번이 아니었다. 이제껏 회고 때마다 나왔던 첫 PR 역시 마찬가지였다. 사실상 매일 해당 작업에 대해 어디까지 진행했고 어디가 문제인지 등을 꾸준하게 공유했다면 PR 하나에 100개 코멘트가 달리는 불상사는 일어나지 않았을 것이다. 일을 꿍하고 혼자 한참 하면서 PR을 왕창 모았다가 한 번에 뽝!하고 뱉어버리니 그럴 수밖에.  

 

왜 이런 문제가 자꾸 일어날까 고민해보니, 혼자 결과를 만들어내야 한다는 강박이 생겨서인 것 같다. 나한테 일이 주어졌으면 내가 책임지고 어떻게든 해내야 한다는 생각 때문이었다. 오너십을 갖는 건 좋은데, 오너십과 해당 이슈를 팀원과 함께 고민하고 논의하는 건 전혀 별개의 문제라는 걸 인지하자. 혼자 일하는 게 아니라 팀으로 일한다고 생각해야 한다. 애초에 창업을 그만두고 회사로 온 이유가 어떻게 협업하는지 제대로 배우기 위해서인데, 혼자 일하는 관성을 못 버리면 쓰나.  

 

오늘 리드님과 이야기하면서 들어준 선례가 있다. 예전에 CTO를 하다가 우리 회사 서버팀에 합류하셨던 분이셨는데,(현재는 다시 창업하러 나가셨다) 팀에 합류한 이후부터 틈날 때마다 자신의 상황을 적극적으로 알리고 공유하려는 모습을 보였다고 하셨다. 연차가 적지 않으셨음에도(보통 연차가 많아질수록 자기가 뭐하고 있고 무슨 이슈가 있고 등을 공유하기 어려워하니까) 이렇게 하는 모습을 보면서 대단하다고 느꼈다고 하셨다. 실제로 같이 일하는 측면에서도 그런 태도가 훨씬 도움이 많이 됐다고 하셨다.  

 

가만 생각해보니 나 역시 그럴 때가 있었다. 22살 꼬꼬마 때 잠시 몸담았던 스타트업 인턴 시절, 진짜 아무 것도 몰랐을 때라 틈만 나면 옆자리에 계신 팀장님께 현재 상황을 주기적으로 보고했다. 이런 걸 하고 있고 이런 게 잘 안 되고 등등. 그리고 월말 피드백 시간 때, 이런 이야기를 들었다. 정말 감사한 내용인지라 메모장에 써놨는데 지금 찾아보니 그대로 있더라.  

 

"우니는 애티튜드가 좋아서 어딜 가도 정말 사랑받으실 거예요. 두 가지 포인트가 있는데,

1. 일을 맡길 때 긍정적으로 화답하는 부분과 - "네, 제가 할게요! 제가 하겠습니다!"
2. 소통을 잘하는 부분 - "이거 이렇게 해봤는데, 한 번 봐주시겠어요?"

이런 측면에서 상급자가 같이 일하고 싶어하는 팀원임에 분명해요."

 

지난 7년 사이에 무슨 일이 있었는가 싶다..만.. 원래 내가 지닌 강점이었다는 걸 상기하자. 1은 여전히 잘하고 있으니, 2번을 예전처럼 해보자.  

 

여기서 중요한 포인트는 그렇다고 무작정 이슈를 던지는 게 아니라는 것이다. 이슈 공유도 현명하게, 듣는 이를 배려해서 해야 한다. 예컨대

• 그냥 이거 안돼요가 아니라
• 해당 이슈는 이거고 여기여기까지는 시도해서 해봤고 이렇게 하면 될 것 같다고 생각했는데 이런이런 이유로 안되더라구요 가 되어야 한다.

 

핵심은 그냥 이슈만 툭 던지는 게 아니라 어디까지 해봤는지, 내 생각은 무엇인지 디테일하게 들고 가야 한다는 것이다. 그래야 무작정 해결해주세요 징징대는 게 아니라 팀원 간의 생산적인 논의가 이뤄진다. 시니어는 같이 논의해서 함께 문제를 해결하기 위한 동료이지 내 문제를 해결해주기 위해 있는 사람이 아니다.  

 

이제 내 문제를 명확하게 인식했으니, 다음에는 똑같은 실수를 반복하지 않도록 하자.

Try

• 데일리로 일 진행상황 슬랙 채널에 공유하기(특히 해당 일과 관련된 동료들에게는 더욱 더 디테일하게)
  • 특히 이슈 터지면 혼자 끙끙 앓지 않고 채널에 바로 던질 것
• 이슈 던질 때 무턱대고 공유하지 않고 구조화한 뒤 명료하게 전달하기
• 해당 내용 노션 데일리 업무 일지에 넣어서 매일 제대로 진행하고 있는지 체크할 것