개발 소스코드 규칙 정의하기
최근 개발 소스코드의 불규칙한 패턴을 재정의하고, 고치는 작업을 진행 했다. 이러한 작업을 하기 전 패턴에 대한 생각을 해보았다.
일정한 패턴이 필요할까?
단순하게 생각했을 때, 나는 고민 거리를 줄여준다고 본다. 나는 항상 부모님에게 전화를 할 때 저녁 8시 쯤에 한다. 어업에 종사하시는 부모님은 항상 아침 일찍 부터 오후 늦게까지 바다에서 일을 하고 집에와 정리하고 저녁을 먹은 후에야 여유롭게 시간을 보낸다. 이러한 부모님의 패턴을 알고 있기 때문에, 나는 8시라는 예측가능한 시간에 연락을 드리고 연결에 성공하여 대화를 할 수 있는 확률이 높다. 그런데 만약 부모님의 일하는 시간이 불규칙 하다면, 나는 생각이 많아질 것이다. '언제 전화를 해야하지?'라는 고민과 함께 연락이 되지 않았을 때는 주변인에게까지 연락을 하는 상황까지도 갈 수 있다.
다행히, 부모님의 일관된 생활 패턴 덕분에 나는 언제 연락을 할 지 계획을 할 수 있고, 불필요한 커뮤니케이션을 줄일 수 있다.
개발도 규칙이 필요해
일정한 패턴 없이 개발을 하게 되면 어느 부분을 고쳐야할지 계획하기 힘들고 동료와의 커뮤니케이션 비용이 즐가 할 수 밖에 없다. 이는 유지보수를 하는 상황에서 크게 두가지 문제점을 발생시킨다.
첫 번째는 커뮤니케이션 비용의 증가는 곧 생산성의 하락이다. 개발이라는 것은 높은 집중력으로 밀도 있게 작업해야하는 일이기 때문에, 중간중간의 자주 질문을 하는것은 상대방의 업무 효율성을 상당히 떨어뜨릴 수 있다. 그럼에도 불구하고, 기존에 동료가 개발한 기능에서 수정이 들어가야 한다면, 로직에 대한 의문과 함께 소스코드가 어떻게 로직으로 이어지는지 부터 확인한다. 그렇기 때문에 동료에게 질문하는 횟수도 늘어나고, 코드를 읽는 시간이 몇배는 증가할 수 밖에 없다. 최악의 경우 개발하는 시간보다 이해하는데만 시간을 더 소모할 수 있고, 이를 개발했던 동료 또한 방해를 받아 생산성이 떨어질 수 있다.
두 번째는, 어디서부턴 손봐야할지 난감해지고, 결국 오류 발생률이 더 증가할 수 밖에 없다. 동료가 작성한 소스코드의 패턴을 이해하고 이에 맞추어 개발을 해야하기 때문에 환경 자체가 낯설다. 그리고 아무리 맞춘다고 하더라도 나의 스타일이 혼재될 수 밖에 없기 때문에 더욱 혼란이 야기되기도 한다. 결국 이렇게 정리되지 않은 코드는 오류를 범하기 쉽고, 범해진 오류를 처리하기 위해 대응도 힘들어 질 수 밖에 없다.
개발을 할때 명확한 패턴을 만들고, 이에 맞춰 개발을 하는 것이 조금은 불필요한 일이라고 여겨질 수 있다. 패턴대로 개발하지 않아도 동작은 할 수 있기 때문이다. 그래도 협업을 하는 거라면 귀찮더라도 나중을 위해 미리미리 하는것이 좋고, 조금 늦더라도 MVP 정도 뽑아내고 이 프로젝트를 지속적으로 유지보수 해야한다는 판단이 선다면 그때라도 꼭하는 것이 필요하다고 생각한다.
이번에 코드 컨벤션을 시작 하게된 계기는?
최근 소스코드를 보면서 문득 동료 개발자가 작업한 소스코드, 그리고 내가 작업한 소스코드가 마치 땅따먹기를 하듯 치열하게 서로 다른 코드 스타일이 하나의 로직 안에서 영역 싸움을 하고 있는 듯 했다. 매번 개발을 하면서 코드 컨벤션을 빨리 해야하는데 라는 생각을 했었지만, 결국 흐지브지되어 지금까지 흘러왔다.
이러한 현상이 지속된 데에는 우선, 최소한의 규칙을 그때 그때 정하고 이를 조금씩 적용해가면서 규칙에 대한 풀을 넓여가고자 했다. 그러나 문제가 있었다. 규칙이 꾸준하게 준수 되지 않았다. 시간이 지나면서 빨리 개발해서 배포하자라는 식의 판단을 하면서 규칙이 묻히기 일 수 였다. 한 번 무너진 규칙을 결국 돌이키기 쉽지 않았다.
또 하나는 지금 당장 규칙을 정하고 이를 위해 소스코드를 고치는 작업을 하기 보다는 서비스 안정화를 위해 에러를 해결하고, 새로운 실험들을 위한 작업을 우선적으로 진행해야 했다. 비즈니스 사이클에서 이제 막 성장하기 시작하는 스타트업에서 조금이라도 더 많은 고객을 확보하기 위해 여러 아이디어를 실험하는게 더 중요했기 떄문이다. 기록해놓은 릴리스노트만 봐도, 두명의 개발자가 일주일에 적어도 1번 많게는 3번도 한적이 있었다. 미뤄질 수 밖에 없는 상황이었다.
결국 최근 로직을 개발하는것 보다 동료개발자의 소스코드를 이해하는데 시간이 더 소모됨을 발견하고는, 더 이상은 애매하게 대응할 수 없다는 결정을 했다. 그리고, 이제서야 숨고르기 타이밍에 들어섰고, 명확한 코드 컨벤션과 함께 대대적인 개편을 시작했다.
코드 리뷰 도입
규칙 준수 여부에 대한 코드리뷰를 같이 시작했다. 코드 교칙이 도입되어 개편을 했으니, 이를 꾸준하게 유지할 수 있는 방법이 필요했다. 개발자는 기계가 아닌 사람이기 때문에 이 일관성을 지키는 것이 쉽지 않다. 규칙에 정의되어 있지 않은 예외 상황이 올 경우, 이에 대한 합의가 필요하다. 규칙이라는 것은 만드는 것보다 꾸준하게 유지되는 것이 어렵기 때문에 이를 위한 노력또한 소홀이 하면 안됨을 알기에 꼭 실행하고 있다.
이번에 규칙을 정하면서 생각한 목표점은 한 명의 개발자가 작업한 것 처럼 일정한 패턴이 유지 되는 것이 었다. 하나하나 세세한 부분까지 규칙을 적용하는 것이 힘들었지만 마치 나의 어지럽혀져 있는 옷장을 정리 하는 느낌처럼 개운했다. 상당히 귀찮은 작업이었지만, 현재의 동료 그리고 이후 들어올 동료가 로직에 대한 고민에 집중할 수 있도록 하는 최소한의 매너라고 생각하며 정리를 마무리 했다.
