코드 리뷰, 괜찮아요?
***님, 괜찮으시죠?
코드 리뷰를 남겼을 때 개발팀 내에서 나온 반응이다. 코드 리뷰가 개발 과정 중 ‘당연’한 절차였던 나에게 이런 반응은 그 자체로 의문이 들었다. 당연히 해야 할 일인데 무엇이 안부를 묻게 만드는 일일까?
개발 조직에서 코드 리뷰는 기능/디자인 QA와 동등한 목적을 가진다. QA라 함은 기능 보증을 위한 프로덕트 배포 전 확인 및 보완 과정이다. 기능은 요구된 기능이 들어갔는지, 원하는 대로 진행되는지 확인해야 하므로 기능(비즈니스 플로우) QA 전문가에게 맡겨진다. 디자인 QA는 화면이 디자인대로 나오는지 확인해야 하므로 디자인 전문가에게 맡겨진다. 그리고 코드 리뷰, aka 코드 QA는 당연히 동료 개발자(들)에게 맡겨진다.
그렇다면 코드 QA는 어떤 것을 보느냐? 퍼포먼스와 확장성(및 캡슐화)에 관한 부분이다(미리 얘기하자면 두 부분에 대한 QA를 하다 보면 자연스레 코드 퀄리티를 다루게 된다). 코드가 기획대로 기능하는 것은, 또 디자인한 대로 보이는 것은 ‘당연’ 한 일이다. 코드 QA는 앞선 두 종류의 QA에서 보지 못한 부분을 점검하고 해결할 수 있다. 그냥 기능하는 것이 아닌 ‘잘’ 기능하고 있어야 이후 서비스를 변형/확장하며 계속 이어갈 수 있다. 코드를 죽이지 않고 살 수 있는 방향으로 올려야 비즈니스 성장도 보증할 수 있다. 마치 기반이 튼튼한 건축의 그것과 같다. 좀 더 자세히 얘기해보자.
먼저 퍼포먼스, 다음과 같은 문제들이 보일 수 있다.
1. 반응이 느리다. → 연산 복잡도가 높다. O(n2) → 목적한 기능을 위한 동적 메모리 할당이 크다.
2. 중복 호출이 발생하고 있다. → 동적 메모리 할당이 크다. → 콜 스택 오버플로우의 가능성이 있다. → 불필요한 서버 비용 지출이 예상된다.
두 경우 모두 엔드 유저의 사용성 저하와 서비스 공급자의 불필요한 비용 낭비를 동시에 가져온다. 이런 문제들이 쌓이면 결국 애플리케이션 termination으로 인해 서비스 자체가 불가능해져 유저 이탈이 자명해진다. 스마트폰에서 무거운 애플리케이션들이 얼마나 사용성이 떨어지며, 또 얼마나 쉽게 불시 종료되는지 경험해봤을 것이다. 대표적인 어플이 Notion과 네이버 지도이다. 이런 부분들에 대한 문제를 고민하지 않고 수없이 많은 (저질) 코드를 다양한 사람이 한 도메인에 얹다 보니 최신의 기기가 아니고는 동작조차 보증하지 않는 서비스가 우후죽순 세상에 내놓아진 것이다.
퍼포먼스에는 인적 퍼포먼스도 존재한다. 한 줄에 작성 가능한 코드를 열 줄에 적고, 이런 비슷한 코드를 20개 작성했다 생각해보자. 20줄에 마무리될 코드를 10줄 * 20개 = 200줄로 작성해 놓으면 일단 해당 파일의 코드가 한눈에 안 보여 다음 변형이나 확장을 해야 하는 상황에서 그것이 어떤 기능을 하는 코드인지 처음부터 파악하고 작업을 진행하여야 하므로 시간이 많이 소요된다. 실제로 많은 경우 코드가 길어지면 코드의 목적을 파악하는 게 기하급수적으로 어려워지고 종단엔 코드 파악을 포기하고 conditional exception 일변도로 기능 변형과 확장을 처리해야 하는 경우가 너무도, 너무도 쉽게 발생한다. 모두가 모여 CDD(Consiousness Driven Development, a.k.a 의식주도 개발)를 통해 낮은 퍼포먼스로 코드를 만들면서 기형적인 코드를 양산한다. 최후의 마지막에는 쓰레기 버리듯 해당 도메인을 포기하고 새 도메인으로 갈아탄다. 1년, 2년씩 동일한 기능을 리팩토링 하는데 시간과 비용을 지출하며 비즈니스 타이밍을 망치고 팀의 사기를 저하시킨다.
다음은 확장성(및 캡슐화),
어떤 피쳐 개발이라도 그다음이 있다. 다음 개발이 이번에 개발된 내용과 전혀 관계없으면 좋겠지만 그런 경우는 존재하지 않는다. 도메인이나 패스 네임이 다르다 해도 마찬가지이다. 라우트 미들웨어, 세션, 브라우저 히스토리 등 하나의 서비스 도메인 내에 있다면 무조건 관련이 있다. 그러므로 다음을 대비한 개발이 그 전 개발에 동시에 진행되어야 한다. 서비스가 변형, 확장될 수 있음을 염두에 둔 코드로 다음 진화의 교두보를 만들어야 한다.
이를 위해서 코드 확장성에 대한 QA가 있어야 한다. 확장성이 있으려면 코드는 잘 모듈화(캡슐화) 되어 있어야 한다. 하나의 파일을 만들어 코드를 올린다면 그 파일의 코드는 다른 파일의 코드와 의존성이 최소화되어야 한다. 또한 코드 자체가 잘 이해되게 작성되어 있어야 한다. 코드가 확장될 때 필연적으로 코드의 변형이 필요한데 이때 한 파일 내의 코드가(혹은 한 블록 내의 코드가) 어떤 역할을 하는 것인지 한눈에 알 수 없다면, 그리고 의존성이 일파만파 퍼져있다면 다음 변형과 확장은 필연적인 불확실성을 낳는다. 서비스 에러를 쉽게 발생시키게 되고 개발 비용은 드라마틱하게 증가해 나갈 것이다.
앞서 얘기됐던 문제들이 모두 코드 QA, 즉 코드 리뷰에서 확인할 수 있는 부분이고, 코드 리팩토링을 통해서만 문제를 해결할 수 있는 부분이다. 어떤가? 여전히 코드 리뷰는 QA가 아닌가? 안부를 물어야 하는 행위인가? 상대의 자존심을 건드릴 수 있기 때문에 피해야 하는 일인가? 그렇게 생각한다면 당신의 개발팀이 생산해내는 코드는 죽음을 향해 달려갈 것이다. 기형적인 확장과 예외처리에만 의존하다 종단엔 누구도 건드릴 수 없는 괴물을 만들어 내고 팀원들은 다시금 채용공고를 뒤지기 시작할 것이다.
