brunch

매거진 시애틀에서 직장생활 생존기

라이킷 9 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 실러캔스 Sep 27. 2022

20화. 코드 리뷰

시애틀에서 직장생활 생존기 - 20

개발자들은 코드로 얘기한다. 물론 그 코드가 완성되기까지 필요한 갖가지 문서들이 있지만 결국은 코드를 통해서 자신이 무엇을 전달하고자 하는지를 얘기한다. 전 세계에 여러 언어가 존재하듯이 프로그래밍 언어도 종류가 많다. 개발자들은 자신이 잘 알지 못하는 언어라도 보통 기본적인 문법이 있기에 다른 언어도 깊이에 따라 다르겠지만 어느 정도는 이해할 수 있다. 우리가 실제로 말할 때 모두 자신의 스타일이 있듯이 같은 언어를 사용하는 경우라도 개발자마다 저마다의 스타일이 있다. 이 스타일을 그래도 최대한 비슷하게 만들기 위해서 Linter들이 필요하다. 그렇게 Linter를 통해서 모두 비슷한 스타일로 얘기하더라도 완벽한 코드에 대한 생각은 모두 다를 수 있다. 그래서 완벽한 코드는 존재하지 않을 수도 있다. 반면 잘못된 코드는 존재한다.

잘못된 코드나 더 좋은 방법을 다른 개발자들로 들을 수 있도록 코드 리뷰를 한다. 이는 전 세계 공통일 것이며 코드 리뷰를 통해서 더 나은 코드를 생성할 수 있도록 한다. 코드 리뷰를 통해서 내 코드가 더욱 발전할 수도 있고 내가 다른 사람의 코드를 발전시킬 수도 있다. 하지만 개발자들은 가끔 고집이 세다. 그래서 누군가가 자신의 코드를 고치려고 하면 방어 기제가 작동하기도 한다. 이럴 경우는 서로 의논을 통해서 어떤 것이 더 나은지 어떤 것이 실제로 더 효율적인지 판단해야 된다.

어느 날, 같이 일하는 동료 한 명이 코드 리뷰를 보냈다. 그중 이해가 되지 않는 코드가 있었다.

자바스크립트 (JavaScript) JSON.stringify()

위의 코드는 json을 JSON.stringify()를 통해서 예쁘게 2칸씩 들여 쓰기를 하여 (2가 들여 쓰기) 문자열로 변환한 후 문자열에서 replace()를 통해서 문자열에 존재하는 줄 바꿈 문자 (개행 문자, \n\r)를 모두 빈 문자로 변형하는 것이다. 여기서 내가 들었던 의문은 결국 문자열의 모든 개행 문자들을 빈칸으로 바꿀 것이면 들여 쓰기를 하지 않으면 문자열을 변환하지 않아도 되지 않냐는 단순한 의문이었다. 그래서 아래와 같은 첨언을 남겼다.

"여기서 결과값이 JSON을 개행 문자가 없는 문자열로 보이는데 JSON.stringify(json)로 하면 되지 않을까?"

그 외에도 몇 개의 첨언을 남겼는데 그 친구는 내가 위에서 물어본 것에는 어떠한 답변도 없이 다른 코드만 수정한 채로 다음 버전을 내놓았다. 그래서 궁금해졌다.

- 나: 내가 질문한 게 있는데 JSON.stringify(json)으로 처리하면 되지 않아? 혹시 내가 모르는 다른 이유라도 있어?
- 개발자: 저거 SonarQube (코드 품질을 높여주기 위해서 SonarQube를 팀 내에서 사용 중)에서 불평해서 변경한 거야.
- 나: JSON.stringify(json)을 불평한다는 거야?
- 개발자: 아니, 정규식을 불평해서 정규식을 좀 수정했어.
- 나: 그래, 그러면 저 코드 어차피 JSON을 개행 문자를 없앤 문자열로 변경하는 것인데 단순히 JSON.stringify(json)이면 될 것 같은데?
- 개발자: 1년 전에 변경했던 거라서 정확히 기억은 안나. 하지만 X 서비스 (AWS 서비스 중 하나를 언급)에 데이터를 보낼 때 아주 드물게 나오던 버그를 수정한 거였어.
- 나: 그래, 그건 알겠고 내가 하고 싶은 말은 네가 지금 JSON을 개행 문자 없이 문자열로 변환하는데 불필요한 요소가 있는 것 같다는 것을 말하는 거야.

그리고 나는 아래와 같은 예를 들었다.

설명을 위해서 제시한 예제.

- 나: 자 봐. 네가 작성한 거랑 JSON.stringify(json)은 결국 사이에 공백을 제외하면 동일한 결과야.
- 개발자: X 서비스 버그를 고치기 위해서 개행 문자를 없애야 했어.
- 나: (말이 통하지 않자 점점 화가 났다) 개행 문자는 네가 들여 쓰기 "2"를 넣었기 때문에 생기는 거야. 들여 쓰기를 애초에 하지 않으면 개행 문자는 처음부터 JSON을 문자열로 변환 시 생성되지 않아. 그렇게 되면 replace()를 통해서 문자열을 변환할 필요가 없어져.
- 개발자: 그 말이 맞을 수도 있어. 하지만 코드는 지금 정상적으로 동작하고 변경 후 테스트를 진행해야 하는 번거로움이 있어.

대화가 통하지 않자 나는 말을 멈췄다. 몇 시간이 지나자 그 개발자에게서 지금 내가 코드 리뷰를 막고 있어서 다음으로 넘어갈 수가 없으니 처리해줄 수 있냐는 말을 들었다. 어이가 없었다. 그래서 나는 아래와 같은 장문의 첨언을 남겼다.

네가 (보통 코드 리뷰에 You라는 직접적인 표현은 쓰지 않는다) 여기서 얻고자 하는 결과값이 정확히 무엇이냐? 결과값이 어떻게 생겨야 되냐? (이 질문을 한 이유는 입력과 출력을 정확히 이해하지 못하고 있는 듯 보여서 던졌다)

내가 어려운 것을 물어본 것도 아니고 복잡한 것을 변경하라고 얘기한 것도 아니다. 단순히 왜 저렇게 써야만 했는지 내가 모르는 이유가 있는지 궁금해서 물어봤다.

(다시 예제를 들며)

위에서 다른 것이라고는 네가 작성한 코드에는 "2"로 인해서 빈칸이 발생했고, 내가 작성한 코드에는 빈칸이 없다는 것 말고는 다른 것이 없다. 실제로 네가 작성한 코드는 replace()를 해야 하기 때문에 성능면에서도 떨어진다 (물론 작은 입력에 대해서는 큰 차이는 없을 수 있다). 또한 결과값을 base64로 인코딩할 경우 (다음 코드에서 인코딩을 진행하고 있었다) 길이도 늘어난다. 그 늘어난 문자열을 전송하게 되면 비용도 더 많이 든다 (보통 AWS 서비스들은 입력받은 데이터 값에 대해서 비용을 청구하는 경우가 많다).

완벽한 코드는 없을 수도 있다. 하지만 향상할 부분이 발견되면은 그 부분은 향상해야 한다. 또한 우리 코드는 오픈 소스로 아마존의 이름으로 공개가 된다. 우리가 불필요한 코드를 많이 넣어서 오픈 소스로 공개할 경우 다른 사람들이 아마존을 어떻게 생각하겠냐?

내가 해줄 수 있는 말은 여기까지다. 네가 내가 받아들일 수 없는 이유로만 설명했고, 그 이유들을 단 하나도 나는 받아들일 수가 없다. 하지만 네가 내가 받아들일 수 있는 이유 단 하나만이라도 제대로 설명한다면 너에게 끼친 불편함을 진심으로 사과하겠다.

그리고 여기에 대한 그 개발자의 답변.