10살 어린 대학생 인턴에게 코드 리뷰 빠꾸 먹은 이야기

최근 채널톡을 컨트롤하는 모듈을 만들다가 아주 기발하다고 생각한 아이디어가 있어서 리뷰를 요청했다. 아이디어는 아래 내용과 같다.

1. 채널톡의 문의버튼을 Vue 컴포넌트처럼 사용할 수 있게 만들었다. 원래 채널톡 버튼은 iframe을 삽입하도록 동작한다. 
2. 1의 컴포넌트를 상태 관리 라이브러리(Pinia)의 getter에 선언했다.

더 자세한 맥락은 다른 글 "SPA에서 채널톡 사용하기" 에서 작성할 예정.

 

이 방식이 재밌다고 느껴서 들뜬 마음으로 리뷰를 기다렸다. 그리고 우리팀 인턴이 그날 밤 이런 리뷰를 달아주셨다.

그림1. 대학생 인턴의 리뷰

조금 설명을 덧붙이자면 컴포넌트처럼 보이게 하지 않고, 조금 귀찮더라도 채널톡이 제공하는 method를 lifecycle hook에서 직접 호출하는 방식이 어떻겠냐는 의견이었다. 왜 그렇게 생각했는지 궁금해서 다음날 출근하자마자 찾아가서 물어보았고, 다음과 같은 얘기를 나누게 되었다.

1. store의 getter에 컴포넌트를 작성한다는 것은 처음보는 패턴이다. 그래서 코드를 쉽게 이해하기 어려울 수 있다. 
2. 1의 이유 때문에 pinia 라이브러리가 업데이트 되었을 때 이런 패턴이 안정성 있을거라고 생각되지 않는다.
3. 컴포넌트가 아닌 버튼을 컴포넌트처럼 보이게 하면 코드를 오해하게 할 가능성이 있다.

나눴던 얘기가 모두 타당하다고 생각했고, 바로 수정하여 PR을 올렸다.

 

문제를 팀과 함께 해결하려면

내 아이디어가 부정당했지만, 나는 이 일이 아주 재미있다고 느꼈다. 이렇게 느낀 이유가 나도 궁금해서 생각을 되짚다 내가 일했던 방식에 대해서 생각해보게 되었다. 처음 개발을 시작할 때 내가 일했던 방식은 아마 아래 그림2와 가까웠을 것이다.

그림2. 먼저 구현하고 리뷰를 받는 방식

위 방식의 문제는 구현까지 완료하고 나서야 다른 사람의 의견을 듣는다는 것이었다. 만약 접근 방식이 잘못되었다면 몇일을 구현한 결과가 소용없어져서 새로 만들거나, 촉박한 시간 때문에 구린 결과를 참는 선택을 하기도 했다. 리뷰를 받을 때마다 새로 만드는 일이 많아지면 리뷰 받기가 두려워진다. 구린 결과를 참으면 기술 부채가 쌓일 수도 있고, 내 실력이 거기서 머무르기도 쉽다. 그래서 아래 그림3처럼 바뀌어갔다.

그림3. 리뷰를 먼저 받고 구현을 하는 방식

해결방법을 고민한 뒤, 어떻게 해야겠다는 생각이 들면 곧바로 리뷰를 받았다. 설명을 위한 조금의 구현을 먼저 할 수도 있다. 아이디어에 대한 리뷰만 받기 때문에 다시 하게 되더라도 별로 손해볼 일이 없다. 동료와 함께 설계에 대한 리뷰가 끝나면, 그 때 구현을 시작한다. 구현하다보면 몰랐던 문제가 발생할 수도 있는데, 이 때도 똑같이 동료에게 먼저 의견을 물어본다. 구현 후에 받는 최종 리뷰도 더 간단해진다.

 

다시 돌아와서, 이번 리뷰 덕분에 기발한 코드가 일반적이지 않은, 그래서 오해를 일으킬 수 있는 코드가 될 수 있다는 생각을 해보게 되었다. 물론 나도 좋은 반응을 기대했던 건 사실이다. 하지만 기대했던 반응을 만나지 못한 것보다, 새로운 관점을 만나게 된 것이 더 재미있었다. 그 동안 많은 리뷰를 주고 받으며 단단해진 것 같다.

리뷰가 어려운 사람들에게

개발을 꼭 처음 시작하는게 아니더라도 성격상 리뷰를 받는걸 어려워하는 사람이 있는 것 같다. 아마 내 접근과 생각이 구리다고 평가받는게 두려워서 그런게 아닐까 한다. 만약 그렇다면 시작단계에서 리뷰를 요청해보길 바란다. 리뷰를 “동료와 같이 문제를 해결하는 과정”이라고 인식을 바꾸기 수월해진다.

A: 이 문제는 이렇게 풀어보는게 어떨까?
B: 그럼 이런 문제가 발생할 것 같은데?
A: 그럼 이렇게 보완해보면 어떨까?
B: 그건 되게 좋은 접근인데?

 

A와 B의 대화가 문제에 대해서 의견을 나누는 것으로 느껴졌으면 좋겠다. 리뷰가 누군가의 잘못을 지적하려고 하는 대화가 아니라는 뜻이다. 나는 이런 방식으로 리뷰를 하고 있고, 이런 방식이 아주 맘에 든다. 만약 지금 좋은 리뷰를 하고 있지 않다고 느껴진다면 이런 방식도 시도해 보기를.