아무도 책임지지 않는 코드

레거시 코드? 책임은 누가?

다른 사람이 작성해서 나에게 넘어온 코드, 오래된 코드 등을 흔히들 레거시 코드라고 한다. 이 레거시 코드는 개발자라면 혼자서 개발을 하는 것이 아니기 때문에 반드시 누구나 경험했고, 경험하고 있고, 경험할 코드이다.

이제 개발 세계에 발을 들인 지도 벌써 1년이 지났지만 아직도 겨우 1인분 할까 말까한 주니어인 내 입장에서는 레거시 코드를 맞닥뜨리면 그저 다 때려치우고 울고만 싶다. 물론 누군가는 별도의 문서에나 주석으로 친절하게 설명을 달고 누가 봐도 한눈에 이해할 수 있을 만큼 깔끔한 코드를 레거시 코드로 남겨놓았을 수도 있다. 하지만 그동안 나는 그런 코드를 거의 본 적이 없다. 짧디 짧은 경력에 아직 배워야 할 것이 더 많은 내 눈에도 "이건 대체 누가 이따위로 작성한 거야?" 소리가 나올 정도로 엉망진창인 것만 봐왔기 때문이다. 그러다 보니 나에게 레거시 코드란, 리팩토링이 절실한데 감히 손대기에는 일이 너무 커지고 그냥 두기에는 뒤이어 개발할 내 코드까지 더럽게 만드는 주범일 뿐이었다.

그리고 오늘, 이번에도 누가 작성했는지 모를 레거시 코드를 마주하고 쏟아지려는 경악과 한숨을 억지로 삼키고 있는데 문득 이런 생각이 들었다.

대체 이런 코드는 누가 책임지지?

이미 오래 전에 작성자의 손을 떠난 코드는 그 다음 사람에게 전달되고 또 그 다음 사람에게 전달되면서 마침내는 내 앞에 당도했다. 그럼 이번 프로젝트를 맡게 된 나의 책임일까? 아니면 리팩토링이 절실한데도 그냥 넘겨버린 전임자의 책임일까? 그것도 아니면 처음 그 코드를 작성한 누군가일까?

책임의 소재를 따져보자면 아무래도 후임자로서는 억울한 점이 더 많아진다. 개발새발 작성한 사람은 어디론가 떠나고 없고 그걸 온전히 다음 사람이 떠안았으니 말이다. 심지어 뒷사람이 코드 리팩토링을 맡았다면 더더욱 부담도 크다. 어떻게든 깔끔하게 고쳐보려고 하다가 잘못 건드려서 잘 되던 기능이 안 된다던가 하면 큰일날 수도 있고(그런데 애초에 그렇게 엉켜버린 스파게티 코드를 작성하지 않았어야 하지 않나...?), 리팩토링 범위가 커서 정말 일이 커져버릴 수도 있는 등등 여러 상황이 발생할 수 있기 때문. 그런데 그렇게 힘들게 리팩토링한 코드가 또 그 다음 후임자에게 넘어갔을 때에도 여전히 욕을 먹을 가능성 역시 높다.

그래서 책임의 소재를 따지는 것도 억울한 사람만 늘어나게 할 뿐, 별 의미가 없다고 봐야 한다. 그런 거 따져봤자 일단 코드를 넘겨받은 사람도 그냥 지치기만 하니까.

책임지는 사람이 필요하다

그렇다고 해서 나쁜 코드의 부담을 폭탄 돌리기처럼 넘기고, 넘기고, 또 넘기기만 해서는 안 된다. 좋은 코드도 나쁜 코드도 어쨌든 누군가가 책임을 져야만 한다. 처음부터 그따위로 작성한 책임까지 지라는 소리는 절대 아니다. 어떤 프로젝트를 맡은 팀에는 PM이든 팀장이든 그 팀을 이끌어가는 사람이 존재하듯이 어쨌든 해당 코드가 속한 프로젝트를 담당하는 사람이 있어야 한다는 이야기다.

사람 한 명이 당장 급한 스타트업에서는 잠깐 왔다 가는 사람들 붙잡고 겨우 덕지덕지 코드 기우기만 할 수밖에 없는 상황인 것은 잘 알고 있다. 규모가 작은 회사이다 보니 시니어 개발자 구하기는 얼마나 더 힘든지도 알고 있다. 그럼에도 최소한 개발자가 한 명은 있어야 하지 않을까? 자사 서비스에 대한 이해도와 프로젝트에 대한 이해도가 있는 개발자 한 명. 그 한 명이 있어야만 회사와 개발자 직원들이 둘 다 윈윈할 수 있다고 생각한다.

모두가 괴롭다면 과연 잘 굴러가고 있는 걸까?

좋은 코드를 쓰려고 노력하자

요상한 레거시 코드도 감내하고 프로젝트를 이끌어가는 한 사람 외에도 우리는 어쨌든 개발자로서 좋은 코드를 쓰기 위해 노력해야 한다.

2013년에 출시되었음에도 아직도 많은 사람들이 읽고 있는 로버트 C. 마틴의 책 이름, 클린 코드는 모든 개발자가 지향하는 것이다. 또한, 아무나 할 수 없는 것이기도 하다. 그 이유는 많을 것이다. 개발자 자신의 능력이나 주변 상황 같은 변수들이 너무 많다. 하지만 코드는 어차피 처음부터 완벽할 수 없다. 리팩토링을 거친 코드도 그땐 완벽해보였는데 나중에 다시 보면 또 고쳐야 할 부분이 보이는 것처럼 어차피 좋은 코드는 한 번에 나오지 않는다. 그러니 그때그때 할 수 있는 한 최선을 다해서 해봐야 하지 않을까?

이런 글을 쓰고 있는 나조차도 아직 클린 코드 책을 다 읽어 본 적은 없다. 그렇지만 최소한 내가 지금 작성하고 있는 코드가 좋은 코드가 아니란 것은 알고 있다. 그러면 거기에서 한 발 더 나아가 어떻게 이 코드를 더 나아지게 할 수 있을지 고민하는 것에서부터 좋은 코드가 시작된다고, 나는 믿는다. 여전히 부족하지만 계속해서 그 상태에 머무르는 것이 아니라 우리는 더디게나마 조금씩 앞으로 나아가야 한다.

그리고 아무리 바빠서 리팩토링할 시간이 없다고 해도 우리는 한 번만 더 고민함으로써 충분히 조금 더 나은 코드를 작성할 수 있다.

• 누가 보아도 직관적으로 이해 가능한 변수명과 함수명 짓기
• 여러 곳에서 똑같이 사용되는 함수는 별도로 분리해서 재사용성과 가독성 높이기
• 구구절절 늘어쓴 조건문을 따로 빼서 상수화하여 사용하기
• 컨벤션을 잘 지켜서 작성하기

지금 당장 생각나는 것만 몇 가지 작성한 것이라 빈약하지만 이외에 우리가 지금 바로 적용할 수 있는 것은 훨씬 많이 있다. 그걸 모두 다 지켜서 쓰라는 말은 아니다. 그저 우리가 잘 알고 있지만 하지 못한다는 변명 뒤에 숨어서 하지 않는 것들만 살려도 내 동료 개발자, 내 후임자, 심지어 나 자신이 구원받는다.

그러니 잊지 말자. 작은 실천으로 우리 모두가 편해질 수 있다는 것을.