legacy 라는 단어를 쓰지 않는 이유

단어가 대화를 끝낸다

팀 안에서 “이 부분은 레거시라서요”라는 말이 나오면 대화가 거기서 멈추는 경우가 많다. 레거시라는 단어는 묘하게도 설명을 대신한다. 왜 건드리기 어려운지, 어디서 문제가 생기는지를 말하는 대신 한 단어로 상황을 정리해버린다.

우리는 그 단어를 쓰지 않기로 했다. 정확히는, 팀 내부 논의에서는 쓰지 않기로 규칙을 정했다. 외부에 설명할 때는 맥락상 쓰는 경우가 있지만, 코드를 같이 보는 자리에서는 더 구체적인 표현으로 대체한다.

대신 쓰는 표현들

우리가 “레거시”라고 부르려는 상황은 실제로는 여러 가지다. 각각을 조금 더 정확하게 나눠보면 이렇다.

“테스트가 없어서 변경이 무섭다”는 상황은 테스트 커버리지 문제다. “이 코드를 마지막으로 건드린 사람이 없다”는 상황은 문서화 문제다. “이 API는 지금 기준으로 설계했으면 다르게 만들었을 것”이라는 상황은 설계 부채다. “지금 빌드가 특정 환경에서만 된다”는 상황은 환경 의존성 문제다.

이것들을 전부 “레거시”로 묶으면 해결책도 뭉뚱그려진다. “언젠가 다시 만들어야 한다”는 말만 남는다. 각각을 분리해서 부르면 각각에 맞는 다음 행동이 생긴다.

실제로 어떻게 달라졌나

이 규칙을 적용하고 나서 코드 리뷰나 스프린트 계획 자리에서 발언이 더 구체적으로 바뀌었다. “이 함수는 테스트가 없어서 변경 영향 범위를 추적하기 어렵다”는 말이 나오면, 그 자리에서 최소한 어떤 테스트가 필요한지 논의가 이어진다. 반면 “레거시라서”라고 끝냈다면 그냥 다음 안건으로 넘어갔을 것이다.

변화가 작게 느껴질 수 있다. 어차피 바쁜 팀에서 단어 하나를 교체한다고 뭐가 달라지냐고 생각할 수 있다. 하지만 말하는 방식이 바뀌면 문제를 바라보는 방식이 바뀐다. 그게 쌓이면 팀이 기술 부채를 대하는 태도 자체가 달라진다.

예외는 있다

외부 미팅에서 클라이언트가 “레거시 시스템”이라는 표현을 쓰면 우리도 그 표현을 쓴다. 그 자리에서 용어를 교정하는 건 핵심이 아니다. 우리가 피하는 건 내부에서 그 단어로 생각을 멈추는 습관이다.

언어는 사고를 따라가기도 하고, 사고를 끌고 가기도 한다. 우리는 후자를 의식적으로 관리하려 한다.

— by slecs