코드가 부채다. - 일주일간 작성한 코드를 오늘 삭제했다.

일주일간 작성한 코드를 설명하기 위한 장표

들어가기

 최근에 아주 조금 내가 성장했다고 느낀 계기가 있었다.

 최근 회사에서 개발자의 유후 시간이 약 한 달정도 주어졌다. 이 기간동안에는 직군별로 미쳐 시간이 없어 하지 못했던 작업을 할 수 있는 시간이 주어졌다. 기술부채로 쌓여있던 해야될 것을 나열하며 그 중 하나로서 '콘텐츠 슬롯 A/B 테스트 가능한 구조 적용하기' 가 나의 미션이였다.

무엇인지 문장만 보고 이해할 때는 말 그대로 'A/B 테스트가 가능한 구조'를 만드는게 우선이지 않을까? 라는 생각을 하며 동작하는 코드를 살펴보니 실제 동작도 하드 코딩으로서 A/B 테스트를 처리하고 있었다.

여기서 A/B 테스트란? 사용자를 A/B 군집으로 나누어 비지니스 로직/UI 등을 다르게 전달하여 더 나은 선택지를 데이터로서 찾기 위한 수단이다.

 하드코딩되어 A/B 테스트을 진행시킴으로서 Source Code에서 발생할 수 있는 잠재적인 문제점이 있었다. 무슨 A/B 테스트 인지? 동일한 코드 복사/붙여넣기 등. 이런 문제를 해결할 수 있는 방안으로 여러 방법을 고민했고, 고민한 결과에 따라 코드 작업을 이어갔다.

어떤 A/B테스트를 진행중인지 알 수 있도록, 기존 코드에 쉽게 붙이고 제거할 수 있도록 작업을 수행했다. 약 3~4일의 작업시간을 들여 'API 단위에서의 A/B 테스트'가 가능한 구조를 만들었다.

그리고 작업한 내역을 팀원들에게 공유할 때 이야기 끝내, 내가 작성한 'API 단위의 A/B 테스트 가능한 구조'의 코드를 삭제했다. 그리고 기존에 남아있던 하드코딩된 A/B테스트 관련 코드도 함께 제거했다.

코드는 부채다.

 동작중인 Source Code에 나의 코드가 반영되지 못했다. 처음 해야될 일을 논할 때 'API 단위의 A/B 테스트'가 아니라 '콘텐츠 슬롯 A/B 테스트 가능한 구조 적용하기' 였다. 여기서 콘텐츠 슬롯이란 내가 다루고 있는 도메인의 핵심적인 부분이고, 포탈사이트에서 콘텐츠가 노출되는 특정 구역을 슬롯이라 부른다.

 '동작중인 Source Code 에 일주일동안 개발한 나의 코드를 반영하지 않겠다.' 라고 직접 말했다.
'API 단위의 A/B 테스트' 를 동료분에게 공유하며 이야기를 나누며 필요성을 어필해보았지만, A/B 테스트는 오직 프론트엔드에서만 진행될 것이며 백엔드에서는 A/B테스트에 대한 의존성이 아예 없었으면 한다고 한다고 의견을 모았다. 다시 정리하면, 앞으로 백엔드단에서는 A/B 테스트 라는 단어가 없었으면 한다는 게 요점이였다. (사실 반감이 많이 앞서기도 했다. 앞으로의 요구사항을 예측할 수 없기에 과연 A/B 테스트를 백엔드에서 아예 안할 수가 있을까?) 그렇다면 '콘텐츠 슬롯 A/B 테스트 가능한 구조 적용하기' 이란 무엇이냐면- A/B 테스트 가능할 수 있도록 콘텐츠 슬롯 좀 더 쉽게 바꿔치기 할 수 있는 기능이 필요했던 것이였다. A/B테스트 와는 무관하게 말이다. 타 팀의 코드를 레퍼런스로서 살펴봤을 때도 내가 만든 기능과 동일한 것을 발견할 수 있었지만 우리 팀에서는 당장 필요하지 않을 수도 있다는 생각을 했다. 그리고 나또한 여기에 동의를 했다.

 코드를 작성하는 소프트웨어 엔지니어이며 동시에 도메인에서 발생하는 문제를 해결하는 사람이므로 코드를 추가하고 싶은 마음이 솟구쳤지만, 효과적인 문제 해결 방안으로 코드를 반영하지 않았다.

결론

 대부분의 회사에서 힘들어하는 주된 요소는 레거시 코드(legacy code)라고 생각한다. 코드는 당연히 없어서 안될 존재이지만 하루만 지나도 유지보수의 대상이 된다. 그러므로 동작중인 Source Code에 나의 코드가 반영되는 것을 신중하게 생각할 필요가 있다.

'있으면 나중에 언젠가 누군가 쓰지 않을까?' 라는 마음으로 코드를 대하는 것은 좋지 못하다. 코드는 나의 자산이 아닌 팀의 자산임을 잊지 않아야 하는것 같다.