부스트캠프 리뷰어 회고 - 1

아직 끝나지도 않았지만, 옛날 생각이 떠오른다.

 

리뷰어는 뭐 하는 사람인가?

 

코드 리뷰는 위와 같은 구성으로 이루어진다.

코드 리뷰라고 해서, 모든 코드를 한 줄 한 줄 읽는 게 아니고, 자동화한 부분을 제외한 나머지 부분에 중점을 둔다.

코드 스타일은 Eslint, Prettier가 잡아줄 부분이고, 우리는 문서화와 비즈니스에 더 중점을 두고 바라본다고 생각하면 된다.

자동화할 수 있는 부분은 굳이 사람의 눈으로 잡지 않고, 컴퓨터가 대신할 수 없는 부분을 리뷰한다고 생각하면 되겠다.

 

하지만 부스트캠프에서 이루어지는 코드 리뷰는 누군가를 가르치고, 또한 가까이서 조력하기 위함이기에 모든 단계를 함께 한다.

지나칠 수는 있겠지만, 그래서 더욱 조심히, 코드 스타일에도 관여를 한다.

배우는 단계에 있는 캠퍼들은 어떤 코드가 좋은 컨벤션인지에 대한 생각이, 남에게 들었을지언정 그리 와닿지 않을 수 있기 때문이다.

최대한 그들 스스로의 색채를 찾을 수 있게 배려하되, 잘못된 것은 아예 하지 말라고 말을 해주는 편이다.

물론 리뷰어도 사람인지라, 어쩌면 정답이라고 하는 것을 알고 있는 상태다 보니 말하고 싶어 입이 근질거리는 때가 있다.

이 때를 참는 건 너무 어려운 일이다.

 

반대로, 리뷰어도 사람인지라, 자신의 리뷰가 틀린 답일 수도 있고, 그저 의견에 불과할 때도 있음을 잘 안다.

하지만 리뷰어라는 입장이, 어쩌면 권위를 만들고 다른 생각일 수 있음을 의심하지도 못하게 만드는 건 아닌가 불안하기도 하다.

근데 그거 아는가?

나는 캠퍼들과 어쩌면 나이가 같거나, 대학교 동문 선후배거나, 어쩌면 그냥 동네 아는 형 동생일 수 있다는 것.

설령 직장에서 만났다고 하더라도 내가 당신들에게 가질 수 있는 권위는 하나도 없을 텐데 너무 겁 먹은 거 아닌가 싶다.

 

그래서, 쫄지말고 리뷰 요청 했으면.

벌써 8명의 캠퍼들에게 말했지만, 피드백의 주기가 짧을 수록 배우는 사람들에게 유리하다.

캠퍼들 중에는 오늘 짠 코드를 다듬고 다듬고 다듬고 다듬고... 끝 없이 다듬다가 새벽 1시에 리뷰 요청한다고 하는 경우도 있다.

이런 경우에는 새벽 1시에 해줄 게 아니라면야 다음 날 회사 출퇴근 이후, 다시 밤에 리뷰를 하게 된다.

그러면 캠퍼는 그 리뷰를 보고 그 다음 날에 자신의 코드를 수정한다.

코드 한 줄을 고치기 위해서 길게는 이틀이 걸릴 수도 있는 것이고, 이러면 캠퍼는 코드 수정을 포기할 가능성이 클 것 같다.

2주일이라는 짧은 시간동안 프로젝트를 완성시켜야 하는데, 작성한지 며칠이나 된 코드를 고치라고?

그것도 비교적 초기에 작성한 코드를?

 

"다음 프로젝트 때 적용해보겠습니다!" 라는 답변이 돌아오면 다행이다.

 

배우는 데 있어서 가장 중요한 것은 피드백 사이클이다.

자기 자신에게는 하루 간격으로 반문을 하고, 조금 나은 사람에게는 일주일에 한 번 질문을 던져야 하고,

아주 빼어난 사람을 만났으면 한 달이나 분기에 한 번은 만나 방향성에 대해서 물어봐야 한다고 들었다.

정말 좋은 말이지만, 한 가지 반론하고 싶은 게 있다면, 이 하루, 일주일, 한달과 분기라는 사이클 주기에 대한 것이다.

나는 이 사이클 주기는 그저 상대와 나 사이에서 주고 받을 수 있는 지식의 총량이 다르기 때문에 생긴, "예의"일 뿐이라고 생각한다.

내가 줄 수 있는 지식이 없는 상태에서 무조건적으로 사사받는 것은 상대에게 실례이기 때문에 생겨난 주기가 아닐까?

만약 이 예의를 걷어찰 수 있는 기회가 온다면, 하루에 한 번이라도 질문을 던질 수 있어야 한다.

 

나 역시 부스트캠프를 수료한 학생이었고, 그렇기 때문에 캠퍼들과 똑같은 고민을 하며 기회를 놓쳐본 적이 있다.

하지만 곧 거기서 놓친 기회들이 너무나 아까웠어서, 리뷰어로 참여한 지금은 강제로 손에 기회를 쥐어주고자 노력하고 있다.

하지만 생각만큼 리뷰어 역할 수행이 쉬운 것 같지는 않다.

개구리가 자기 올챙이일 때를 모른다는데, 반대로 올챙이도 개구리의 심리를 알 수는 없는 모양이다. (...)

리뷰이일 때나, 리뷰어인 지금이나, 정작 어려운 건 코드가 아님을 느낀다.

 

더 많이 질문하고, 더 많이 대화하기

리뷰어 입장에서는, 사실 캠퍼들의 수준은 이제 막 배우는 단계인지라 가르칠 것 투성이로 보인다.

하지만 스스로 탐구하는 과정에서 배우는 것이 많기 때문에 일부러 답을 주지 않고 질문으로 대체하는 경우도 왕왕 있다.

하지만 그건 대화할 생각이 없다는 게 아니기 때문에, 혼자 고민한 다음에라도 리뷰어에게 답을 주면 정말 좋은 결과를 얻을 수 있다.

 

"저번 질문에 대해 고민해봤는데, 내 생각은 이렇다."

 

리뷰는 위에서 아래로 하는 게 아니고, 서로 토의를 하는 과정이라고 생각한다.

만약 그럴 생각이 없다면 그냥 연차에 따라 의견에 힘일 실릴 게 뻔한데 뭣하러 코드 리뷰를 하겠는가?

그냥 가장 경력이 긴 개발자가 일방적으로 자기 말을 할 뿐인 시간이 될 게 뻔하다.

아이디어를 개진하는 데에는 연차나 실력은 아무런 의미가 없다.

때로는 아직 배우지 못한 단계에서도 창의적인 아이디어를 낼 수 있고, 애초에 프로그래밍은 연차가 길다 해서 모든 걸 알 분야도 아니다.

새로 나온 개념은 신입일수록 더 빠삭한 경우가 있으며, 오히려 연차가 긴 개발자들은 전혀 들어본 적도 없어 할 때가 있다.

 

이 시간이 서로 대화하고, 더 나은 답을 찾는 시간이 됐으면 한다.

 

컨벤션이 왜 "중요"하고, 어떻게 해야 하는 건가?

컨벤션은 중요하다.

하지만 왜 중요한지는 사실 협업을 경험하지 않는 지금 단계에서는, 캠퍼들도 사실 이해하기 어려울 것이다.

지금은 혼자 개발하고 있기 때문에 자기가 짜고 싶은 대로 짜는 것이 오히려 알아보기도 쉬울 것이기 때문에 그러하다.

하지만 리뷰어 입장에서는 혼자만 알아볼 수 있는 코드가 결국 나중에 자기 자신도 못알아볼 코드가 될 거라는 것을 알고 있다.

그냥 데이터라고 이름 지은 변수가, 결국 아무도 알아보지 못할 코드가 될 거라는 것도 알고,

마음대로 확장하고 키를 delete 한 객체, 코드 중간에 import, export한 함수들이 나중에 함정으로 돌아올 거라는 걸 안다.

컨벤션은 남들과 같이 일하기 위함이며 동시에 미래의 자신이 알아보기 위해서도 꼭 필요한 이정표라고 생각한다.

그래서 리뷰를 진행하면서 꼭 말한다.

 

자기가 짠 코드가, 자기가 쓰고 있는 라이브러리와 유사한 컨벤션으로 이루어져서 남들이 볼 때 라이브러리 자체 함수인 줄 알아야 한다고.

그래서 이름을 지을 때 막히거나 어떤 컨벤션으로 짜야 하는지 모르겠으면 유명한 라이브러리의 코드를 참고하라고 말해준다.

한 캠퍼가 물어봤다.

"인증과 관련된 미들웨어를 만드는 중인데 이거 이름을 어떻게 지어야 할까요? checkLogin?"

그래서 나는 Passport.js의 authenticate 라는 내부 함수를 보여주면서 오픈소스 코드 개발자가 남긴 주석을 읽어달라고 했다.

가장 높은 점유율을 차지한 오픈소스 라이브러리의 코드는, 사실 상의 표준으로 자리잡는다는 것을 보여주고 싶었다.

 

지금까지 리뷰를 진행하며, 인증을 구현한 많은 캠퍼들이 좋은 의미로 독창적인 코드를 보여주고 있다.

혼자서 깨달은 건지는 모르겠지만 놀랍게도 개중에는 실제 라이브러리와 동일한 코드를 짜는 데 성공한 사람들도 있다.

이런 사람들을 보면, 티는 안내지만 ( 사실 이미 티가 났을지도 모르지만 ) 당장 리뷰하고 싶어질 때가 있다.

혼자 참지 못하고 지하철 출 퇴근 길에도 리뷰를 하고 있다.

 

클론만 하지말고, 비즈니스를 생각하고 만들어야.

부스트캠프에서도 처음부터 창조적인 무언가를 만들라고 요구할 수는 없을 테니, 당연히 클론 코딩으로 프로젝트를 진행한다.

그러다 보니 안타깝게도, 클론 코딩 특유의 기술적 사고만을 중시하는 경향을 보게 되는 것 같다.

어떻게 인증하고, 어떻게 코드를 처리해야 더 예쁜지만 생각하게 되는데, 사실 현업에서는 이것만 중요하지 않다.

비즈니스에서 가장 중요한 것은 돈이고, 그러니 돈을 만들어내는 코드가 더 중요한 법이다.

확장성, 재사용성, 이런 개념들이 코드를 더 예쁘게 짜기 위해서 필요하겠는가?

비즈니스가 성장함에 따라 더 많아지는 요구사항과 부족한 개발 시간을 확보하기 위한, 몸부림 친 결과다.

과정을 이해하지 못한 상태에서 확장성, 재사용성과 같은 개념들이 좋다는 것만 알고 코드를 짜면 "예쁜 개발자"가 된다.

 

근데, 개발자는 예술가가 아니다.

 

개발자는 본질적으로 제품을 만드는 사람이고, 제품과 고객에 대한 이해가 있어야 한다고, 나는 믿고 있다

그렇기 때문에 당장 손에 잡고 있는 게 클론 코딩 프로젝트라고 하더라도 실무를 하는 것처럼 임했으면 하는 마음이 있다.

고객들이 이런 사업을 정말로 원하는지, 이런 식으로 구현되기를 원했는지, 사고하는 훈련이 되기를 원한다.

설령 프로젝트를 완성하지 못하더라도 그런 본질을 보는 눈을 키우는 게 나는 더 이득이라고 생각한다.

 

무얼 중시하는 개발자인지?

사실 100명 200명이 똑같은 주제를 가지고 코드를 짠다면 똑같은 경험치와 똑같은 이력서를 가지게 될 것이다.

그래서 조금 더 메타인지를 할 필요가 있다.

앞서 내가 비즈니스를 생각해야 한다고 했지만 그건 어디까지나 내 기준이고, 다른 사람은 다른 기준이 있을 것이다.

그래서 리뷰어끼리도 각자 중점을 두는 부분이 다를 것이고, 캠퍼들도 제각각 다른 코드를 작성할 것이다.

근데, 리뷰어인 나는 사람들마다 다른 방식으로 코드를 짜는 걸 보고 재밌다고 느끼는데, 정작 캠퍼들은 모르는 모양이다.

이건 서로 경험치가 달라서 발생한 게 아니라, 내가 더 다른 사람의 코드를 접할 기회가 많아서 그런 게 분명하다.

캠퍼들끼리도, 서로의 코드를 보면 좋겠다는 생각에, 나는 한 사람 코드를 리뷰할 때마다 그걸 채널에 공유해주고 있다.

누구는 이렇게 코드를 짰고, 나는 거기에 이렇게 리뷰를 했다.

 

"백문이불여일타" 라는 말을 많이 들어왔는데, 사실 백문과 백견 정도 되면 일타보다는 나은 법이다.

 

캠퍼들이 더 했으면 하는 것은?

리뷰 중에 내가 그린 시퀀스 다이어그램

 

사실 이건 캠퍼들에게 말하면 되는 거지만, 캠퍼 외에도 가르치는 사람들이 있는 입장에서 기록할 필요가 있어 남긴다.

사람들이 많이 어려워하고, 헷갈려하는 개념이 뭔지 알아두면 가르치는 입장에서도 도움이 많이 된다.

 

- 배우는 데에 있어서 괜히 자존심을 부리거나, 또는 가르치는 사람이 무조건 옳다는 생각 버리기

    - 나는 이번에 리뷰하면서, "누추한 서버"를 방문해줘서 고맙다는 말까지 들었다!

 

- 다음 번에 읽는 개발자 ( 그리고 미래의 나 ) 를 배려하며 코딩하기

    - 선언, 정의, 내보내기를 가능하면 한 번에 작성하기

 

- RESTful API가 무엇이고 이게 왜 있는지, 왜 여러 METHOD들이 있음에도 지금은 4~5개 밖에 사용하지 않는 것인지?

    - RESTful은 구조적으로 완성된 것에 대한 고민도 있겠지만, 클라이언트 개발자와의 협업에 매우 유리한, 컨벤션이다.

    - 추가로 안전한 메서드 (safe method) 와 멱등성에 대해서 학습하자.

 

- 세션과 토큰 방식의 차이는 무엇이고, 이게 생겨난 까닭은 무엇인지, 어느 게 어느 순간에 더 나은 것인지?

    - 많은 블로그에, 이 두 가지에 대한 설명들이 있지만, 대부분이 너무 얕게만 다루고 판단에는 전혀 도움을 못 준다.

 

- 백엔드 아키텍처의 각 레이어가 나뉜 까닭은 무엇이고, 각 레이어는 어떤 역할을 수행해야 하는지?

 

- 확장성과 재사용성이라는 개념이, 순수하게 기술적인 요구로 탄생한 개념인지?

 

- 개발을 할 때 비즈니스적인 부분을 충분히 고려하고 있는지?

 

- 동기 함수와 비동기 함수를 구분하는 기준이 무엇인지? / ( Promise, async/await, thenable에 대해 학습하기 )

    - 동기는 응답이 돌아올 때까지 다음 동작을 진행하지 않은 상태에서 기다리는 것을 말하고, 비동기는 그 반대다.

    - 하지만 동기, 비동기 개념은 같은 프로세스 내에서나 통하지, 외부에서는 별개일 수 있다.