레거시를 미워하지 말자

지금 다니는 회사에 처음 입사했을 올해 1월, 모든 것들이 다 레거시였습니다. 프론트엔드의 경우 외주 개발로 만들어진 프로덕트였기 때문에 추가적인 확장이 힘들었고, 팀에서는 레거시 프로덕트를 인하우스 개발자들이 만든 프로덕트로 대체하려고 노력 중이었습니다.

특히 문제는 백엔드였는데, 프론트엔드 개발자에 비해 백엔드 개발자가 부족했고 회사는 더 크게 성장하기 위해 빠른 서비스 런칭과 확장이 필요했습니다. 그래서 1월부터 최근 6월까지, 동작은 하는 백엔드의 문제들을 개선하지 않은 채로 그대로 프론트엔드 프로덕트가 개발되어 왔습니다.

어떤 쿼리는 너무 느렸고, 딱히 처리가 되어있지 않은 예외, 백엔드에서 날아오는 response의 구조가 클라이언트에서 다루기에는 너무 복잡한 경우도 있었지만 웹앱의 인하우스 프로덕트로의 리뉴얼, 모바일 앱 런칭, 채팅 기능 런칭이 진행되었습니다.

그 과정에서 "백엔드가 왜 이렇게 생겨서 내가 고생하지" 라는 생각이 한 번도 들지 않았다면 거짓말일 것입니다.

빠르게 앱을 개발하면서 백엔드가 레거시로 남아있는 것에 대한 비용을 프론트엔드도 감당했습니다. 할 것은 정말 많은데 한 태스크를 처리하는 시간이 생각했던 것보다 오래 걸렸고, 태초에 이 코드를 짠 개발자나 코드가 원망스럽기도 했습니다.

그런데 당장 해야할 일이 많은 상황에서 이런 감정들이 별로 일에 도움을 주지는 않습니다. 지금 당장 수정이 되지도 않을 레거시를 다루거나, 레거시 코드를 리팩토링할때 레거시에 화를 내 봤자, 욕을 해봤자 레거시가 저절로 수정되지는 않습니다. 화 내면서 일하는 것 보다, 감정 섞지 않고 묵묵히 일하는게 효율도 더 좋습니다.

지난 6개월간의 저를 반성하면서... 레거시 프로덕트를 어떻게 생각해 보면 좋을지에 대해 생각을 해봤습니다.

1. 레거시에 대한 리스펙

저는 일단 레거시에 대한 고마움을 좀 가지려고 노력하는 편입니다. 그 동안 레거시 코드가 열심히 돌면서 제 월급을 벌어다?줬기 때문이죠.

저는 개발자면서 회사 직원이기 때문에 개발을 열심히 하는 것 만큼 회사가 잘되는 것도 제 직장생활의 보람과 성과에 큰 영향을 미칩니다. 그런데 그동안 레거시가 큰 문제없이 잘 돌아가 오며 회사의 비즈니스 목표에 기여했다면 레거시 코드는 그 동안의 공로에 칭찬을 더 받아야 합니다.

일하기 불편하다고 레거시를 비난하는 것은 회사의 입장일 수 없습니다.

2. 비즈니스 목표가 정해졌다면 개발자로서 할 수 있는 것을 해내자

레거시를 손대야 하는 일이 회사의 비즈니스 목표에 부합할 때, 개발자는 레거시를 가지고 작업을 합니다.

앞에서 말했듯, 레거시를 비난해봤자 레거시가 저절로 수정되지는 않는 것처럼 비난할 시간에 레거시를 어떻게 하면 좋은 제품으로 변모시킬까 고민하는게 더 유익하다고 봅니다. 개발자로서 실질적으로 할 수 있는 것에 집중하는게 좋습니다.

그리고 비즈니스의 목표는 대부분 시간이 얼마나 걸리더라도 깔끔하고 멋진 코드를 작성해 우아한 프로덕트를 만들자!가 아닐 것입니다. 코드 리팩토링이나 제품 퀄리티 개선 역시 비즈니스 목표에 부합하는 선에서 이루어져야 합니다.

3. 그때는 맞고 지금은 틀리다

회사의 비즈니스 목표와 일정에 따라 프로덕트를 만들다 보면, 좋은 아키텍처나 모든 컨벤션을 지키면서 개발을 하는게 어려울 수도 있습니다. 아니면 비즈니스 환경이 너무 빨리 변해서 과거에 선택했던 설계가 지금은 답이 아닐 수도 있습니다.

소프트웨어는 항상 변화할 수 있는 굉장히 특이한 기계입니다. 다른 기계에 비해 과거의 과오를 현재에 와서 비교적 쉽게 개선할 수 있는 기계이기도 합니다. 과거에는 이 설계가 정답에 더 가까웠을 것이라 판단한 과거의 나 자신이나 다른 개발자의 선택을 존중하고, 이해하는 태도를 가지는게 태스크 진행에는 더 도움이 되지 않을까 생각합니다.

4. 내 코드도 언젠가는 레거시가 된다

내가 작성한 코드도 언젠가는 레거시가 됩니다. 모든 개발자들은 레거시로 바뀔 코드를 작성하고 있습니다. 개발자에게 레거시를 맞닥뜨리는 일은 일상에 가까운 일이니 굳이 레거시에 특정한 감정을 가질 필요는 없는 것 같아요.

그냥 현재 가장 최선인 코드가 뭘까, 가장 비즈니스 목표를 더 빠르고 정확하게 달성할 수 있는 방법은 뭘까 생각하면서 열심히 일을 해내는게 현재의 가장 최선이라고 생각합니다.

더불어 지금의 레거시를 개선한 코드도 역시도 언젠가는 레거시가 됩니다. 레거시 코드를 개선할 때 언제나 모든 부분을 획기적으로 개선할 수 있는 것도 아닙니다. 시간이나 능력의 제약이 존재할 수 있습니다.

소프트웨어는 굉장히 오랜 시간 동안, 천천히 더 나은 프로덕트를 향해 전진하는 방향으로 개선되어야 합니다. 변화의 큰 그림을 모색하고 당장 모든 것을 다 개선해버릴 거라는 욕심 대신, 현재의 정답이 무엇인지를 계속 생각하며 개발을 진행하는게 더 좋은 일처리 방식이 아닐까 생각합니다.