1. 코드 리뷰

새로 이직한 회사에 소프트웨어 개발 시스템을 구축해야 할 일이 생겼다. (이전 회사는 다행히도 대기업이었다)

규모가 크지 않은 회사이기도 하고 소프트웨어 개발이 주업이 아닌 회사라서 소프트웨어 관련 인프라가 전혀 없었다.

어디서부터 손을 대야 할지 막막했다.

 

아무것도 없다면...

가장 먼저 갖추어야 될건 무엇일까...?

SW 개발자라면 소스 코드가 자신의 생명과도 같은 것이니, 이 코드 관리가 제일 우선 되어야 하지 않을까?

 

처음 맞이한 소스 코드 관리 실태는 처참했다. (내 직장을 욕보일 수 있어 자세한 건 생략)

하루빨리 형상 관리 툴을 도입하고 이런 저런 인프라를 만들어야 한다는 생각이 들었다.

 

그런데....

인프라가 갖춰지면 과연 다음 스텝을 나갈 수 있을까? 란 의구심이 들었다.

인프라도 인프라지만, 오랫동안 혼자서만 코딩을 해 온 터라 이들의 사고를 바꾸는 게 더 먼저라는 생각이 들었다.

 

어떤 사고를 바꾸어야 될까?

그건 바로 오랫동안 "혼자서만 코딩하던 사고" 였다.

원했던 원하지 않았던 혼자서만 코딩을 하던 시간이 길어졌고, 이로 인해서 협업이라는 체계를 모르고 지내던 이들이다.

SW는 혼자서 코딩했을 때 절대로 좋은 SW가 될 수 없다.

물론 몇 안 되는 천재들은 혼자서도 잘 만들겠지만, 그건 천재들이고. 

 

이전부터 가지고 있던 나의 SW인에 대한 철학이 있다.

"SW인은 하루종일 모니터하고만 얘기한다. 그렇기에 혼자만의 세계에서 잘못된 길로 빠지기 가장 쉬운 직군이다.

 이런 오류를 범하지 않기 위해서는 옆사람, 뒷사람과 함께 테이블에 모여 논쟁하는 것이다."

 

 SW는 언어고 SW 세상에서 이 언어를 잘 다루기 위해서는 다른 SW인들과 최대한 많이 대화를 나누는 것이 가장 좋은 해결책이라고 20여 년간의 개발 인생을 통해 얻은 교훈이다.

 

혼자서 코딩하는 것을 당장 멈추어야 한다.

내 코드를 옆의 개발자가 보고 지적질하고 싸우고 인정하고 수정하는 과정이 절대적으로 필요하다.

스택오버플로우에 의존한 프로그래밍은 한계가 있다.

다른 경험치를 가진 다른 개발자들의 말 한마디가 백 마디 스택오버플로우보다 훨씬 값어치가 있다. (요즘은 챗GPT 가 이 일을 대신한다)

 

혼자서 코딩하는 것을 멈추기 위해서 서로 상대방의 코드를 보고 검토해 주는 "코드 리뷰"라는 개념을 팀에 알리고 전파하고 설득하는 과정이 필요했다.

---

혼자 프로그래밍을 하는 모습을 상상해 보자. (git으로 작업한다는 가정)

 

 

Fig.1 일반적인 GIT 서버 위주의 개발 workflow

 

저 고민하는 개발자는 혼자만의 고독한 싸움을 하고 있을 것이다.

이 개발자는 아래와 같은 특징을 가지고 있다.

1. 코딩의 주 업무가 “구현”이다.

2. 빌드만 잘 되면 커밋을 한다.

3. 막히는 부분이 나오면 주로 구글링을 통해 스택오버플로우로 (현대는 챗GPT로) 해결한다.

 

이 work flow는 문제가 없을까?

딱 대답하기 어렵다면 , 이런 질문을 던져보면 어떨까?

1. 저 개발자가 작성한 코드는 올바른 코드인가? “올바른”의 가치판단은 누가, 어떻게 하는가?

2. 구현만 되면 좋은 SW 인가?

3. 구글링으로 해결이 안 되면?

 

SW 개발자라면 코딩하는 내내 가지는 질문이다.

그러나 혼자만의 싸움에선 저 대답을 내가 할 수밖에 없다.

다른 모든 일도 그렇지만 나 혼자만으로는 한계가 있다. 발전하고 성장하기 위해서는 다른 경험자로부터의 채찍과 당근이 필수적이다.

 

위의 질문들에 대답을 나 아닌 다른 누군가가 나에게 해준다면 어떨까?

1. 올바른지는 모르겠지만 좋아 보이지는 않습니다. 성능적으로 문제가 있을 것 같아요.

2. 이렇게 하면 원하는 것만 동작할 거 같아요. 다른 xxxx 한 상황이라면 동작이 안될 것 같습니다.

3. 이렇게 여러 줄 작성할 필요 없이 아래처럼 하면 한 문장으로도 해결가능합니다.

 

“다른 누군가” 가 이 답을 주기 위해서는 그 “다른 누군가”가 내가 작성한 코드를 보는 단계를 거쳐야만 한다.

이게 바로 코드리뷰이고 코드리뷰는 이러한 이유로 절대적으로 필요하다.

내 수정코드가 담긴 산출물이 검증팀에 가기 전에 반드시 동료들의 코드 리뷰를 거쳐서 모두가 동의한 SW라고 인정된 SW만이 팀의 SW로서 자격을 갖출 수 있다.

아래는 이를 반영한 업무 흐름이다.

 

 

Fig.2 코드리뷰 단계가 추가된 이상적인 workflow

 

내가 미처 생각하지 못했던 부분을 누군가의 경험치를 통해 배우고 대처할 수 있다면 좋지 아니할까.

각종 에러는 툴이나 자동화 등으로 걸러낼 수 있지만 잘못된 로직은 이런 자동화가 해결해 줄 수 없다.

 

코드 리뷰는 ,

내 코드를 다른 상급자가, 내 옆 개발자가 내 코드를 검사하는 것이 아니라,

해법에 대해 다양한 사람들이 다양한 의견을 나눌 수 있고 , 그 해법에 대해 생산적인 토론 (healthy debate)을 할 수 있는 데에 그 의의와 목표가 있다.

따라서 코드 리뷰는 프로세스가 아닌 문화가 되어야만 한다.

내가 짠 코드를 내 동료들이 보고 이런저런 지적질을 할 수 있는 문화가 되어야 한다.

 

커밋 -> 푸시 -> 리뷰 -> 빠꾸 -> 다시 고민 ->  커밋 -> 푸시 -> 리뷰 -> 빠꾸 -> 다시 고민 -> ....

이러한 무한 반복 과정을 통해 나의 코드는 품질이 좋은 SW로 거듭나고 나도 그 안에서 훌륭한 SW개발자로서 성장할 수 있다.

(..라고 실짱은 믿는다)

 

---

                                                                                                                                         Next >    2. Gerrit 이란?