2학년 겨울방학, 처음으로 인턴을 경험하게 되었습니다.
제가 선택한 곳은 SaaS를 중심으로 운영되는 중소기업이었습니다. 특정 솔루션을 판매하는 회사는 아니었지만, 실제로 운영되고 있는 서비스의 코드와 시스템을 가까이에서 볼 수 있다는 점이 매력적으로 느껴졌습니다.
실습생이었기에 처음부터 핵심적인 기능을 맡지는 않았지만, 대신 현업의 흐름을 직접 경험할 수 있었습니다. 업무 요청이 오고, 결재를 거치며, 일정과 우선순위가 조정되는 과정은 학교에서는 쉽게 접할 수 없는 영역이었습니다.
그 과정에서 자연스럽게 깨닫게 되었습니다.
개발은 코드만으로 이루어지는 일이 아니라는 사실을.
인턴 초반, 저는 팀장님께 일부 레거시 코드를 정리해보고 싶다고 제안드렸습니다. 물론 현업이 최우선이라는 전제는 분명히 했습니다. 학교에서 배운 구조와 기준을 실제 코드에 적용해보고 싶다는 생각이 컸습니다.
그러나 현업에서는 항상 더 중요한 일이 존재했습니다. 당장 해결해야 할 이슈, 일정에 맞춰야 하는 기능, 안정적으로 유지되어야 하는 서비스. 그 안에서 리팩토링은 ‘하면 좋은 일’이지만, 항상 ‘지금 해야 하는 일’은 아니었습니다.
처음 레거시 코드를 마주했을 때는 구조적으로 아쉬운 부분이 눈에 들어왔습니다. 중복이 보였고, 책임이 분리되지 않은 부분도 있었습니다. 정리하면 더 좋아질 것 같다는 확신도 있었습니다.
하지만 코드를 조금 더 깊이 들여다보면서 생각이 달라졌습니다.
그 코드에는 나름의 맥락이 있었습니다. 일정에 맞춰 빠르게 기능을 추가해야 했던 상황, 기존 시스템과의 충돌을 피하기 위한 선택, 유지보수를 고려한 현실적인 타협이 자연스럽게 녹아 있었습니다.
단순히 “정리되지 않아서” 남겨진 코드가 아니라, 그 시점에서의 최선이었을 가능성을 보게 되었습니다.
그때부터 레거시를 바라보는 관점이 달라졌습니다.
좋은 구조를 만드는 일과, 안정적으로 동작하는 시스템을 유지하는 일은 항상 같은 방향에 있지 않다는 것을 이해하게 되었습니다.
인턴 초반의 저는 열정이 앞섰습니다.
어쩌면 다소 성급해 보였을지도 모르겠습니다. “다들 처음 오면 그런 생각을 한다”는 말을 들었을 때는 솔직히 조금 위축되기도 했습니다.
하지만 그 말은 저를 멈추게 하기보다, 더 고민하게 만들었습니다.
지금 내가 바꾸고 싶어 하는 이 부분이 정말 필요한 변화인지, 혹은 아직 충분히 맥락을 이해하지 못한 판단은 아닌지 스스로에게 질문하게 되었습니다.