brunch

라이킷 8 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by HJ May 08. 2022

채사장에게 배운 레거시

개발자들은 항상 레거시와 만난다

레거시(Legacy)는 유물, 유산이라는 사전적 의미를 가지고 있습니다.

다른 분야에서는 대부분 좋은 뜻으로 쓰이는 단어로 알고 있습니다. 선조들이 남긴 기술, 유적, 지혜 등으로요. 반면 개발자들 사이에서는 유독 부정적으로 쓰이는 단어에요. 단순히 프로젝트에서 예전에 작성된 코드라는 뜻인데, 보통 잘 작성된 코드가 아닌 안좋은 코드를 지칭합니다.

명확히 정의해보면 개발자들이 말하는 레거시란 겉보기에는 동작을 하고 있어 문제가 없어보이지만 기능 추가 및 변경 등을 위해 코드를 수정하려고 하면 사이드이펙트가 터져나와 손을 댈 수가 없는 상태의 코드를 말합니다.

얼마 전 채사장의 책 우리는 언젠가 만난다을 읽는데 레거시가 떠오르는 작은 단편이 나오더군요. 요약하여 각색해보면 다음과 같아요.

새로 부임한 대대장은 부대를 시찰하던 중 이상한 광경을 발견했다. 수풀 사이로 가려진 공간에 낡은 나무벤치 하나가 놓여있고, 그 벤치를 두 명의 병사가 지키고 있었다.

대대장은 의아하여 그 병사들에게 무엇을 하고 있느냐 물었다.

“경계근무를 서고 있습니다!”

그 대답을 듣고 더더욱 의아하여 무엇에 대한 경계근무를 서고 있는지 물었다.

“적으로 부터 경계근무를 서고 있습니다!”

대대장은 무슨 이유가 있겠지 하고 돌아갔다. 다음 날 중대장을 불러 해당 병사 둘씩이나 벤치를 지키게 하는 이유를 물었다. 중대장은 자신이 부임하기 전부터 있었던 명령이라고 했다. 대대장은 이 부대에서 가장 오래있었던 주임원사를 불렀다. 하지만 주임원사 또한 같은 대답을 할 뿐이었다.

대대장은 이것이 비합리적이고 이해할 수 없는 일이라고 생각했지만 그 임무를 없앨 순 없었다. 부임한 지 얼마 안된 상태에서 잘 지켜지고 있는 기존 규칙을 괜히 바꿨다가 잡음이 날 수도 있다. 그리고 오랫동안 유지되던 임무라면 그 안에 매우 중요한 이유가 숨겨져 있을지도 모르지 않는가? 속단할 이유가 없었다.

부대를 지휘하고 관리하는 일은 굉장히 힘든 일이었기에 이것에 대한 고민은 잊혀져갔다. 그렇게 대대장은 많은 업무를 성공적으로 완수하고 인사 명령을 받아 다른 부대로 가게 되었다.

이후 새로운 대대장이 부임했다. 오자마자 부대를 둘러보던 대대장은 이상한 광경을 발견했다. 수풀로 가려진 낡은 벤치를 두 명의 병사가 지키고 있었기 때문이다. 대대장은 병사들에게 무얼 하느냐고 질문했다. 병사들은 대답했다.

“경계근무를 서고 있습니다!”

우리는 레거시를 만들 수 밖에 없습니다. 일단 작동은 하고 있으니 일단 문제는 없는데 뭔가 찝찝하고, 바로잡자니 그것대로 일이고, 있다고 큰 불편함이 있는것도 아니라 그냥 존재하는 존재들.

우리는 그렇게 유지되게 하는 힘을 관성이라고 부릅니다. 관성은 추진하는 일에 힘을 실어주고, 관성에 기반한 사고는 유연합니다. 하지만 위의 이야기처럼 경계없는 관성은 항상 찝찝한 뒷맛을 남겨두어 나중에는 사고를 일으킵니다.

서비스의 크기가 커질수록 그 관성 또한 커질 수 밖에 없습니다. 그 힘이 없으면 애초에 동작하지 않는게 서비스니까요. 기존에 작성되어있던 고마운 레거시 모듈들 덕분에 직접 구현하지 않고 가져다 쓸 수 있고, 따로 처리해주지 않아도 여러 기능을 담아 강력한 기능을 만들 수 있어요. 간단한 상속으로 대부분의 기능이 구현된 클래스를 만들어낼 수도 있죠.

하지만 쌓이고 쌓인 안좋은 레거시들은 사용되지 못해서 모두에게 외면받고, 비슷한 코드가 또 생기며 대체되거나 버려집니다. 한 귀퉁이에 쓰이지도 않은 채 방치된 코드는 의심 많고 눈썰미 좋은 개발자가 없다면 의미없이 그 자리를 계속 지킬거에요.

그렇게 또 하나의 레거시가 쌓여가다 보면, 더이상 지속할 수 없는 상태가 옵니다. 뭐 하나 수정하면 수반되는 오류를 잡느라 한세월씩 걸리는 코드 말이에요. 그 때가 되면, 아마 다시 만드는게 빠를 수도 있겠다 생각하고 다 뒤엎어버릴지도 모릅니다.

그래서 낡은 벤치의 결말은 뭐냐구요?

아주 오래 전, 부대가 창설된 지 얼마 되지 않은 어느 날, 상급부대로부터 지시가 내려온다. 병사들의 심적 안정을 위해 쉴 수 있는 공간을 마련하라. 부대는 다양한 조치를 했고 그 중 하나가 벤치를 만드는 것이었다. 당시엔 수풀로 가려져있지 않았지만, 그렇다 한들 벤치에 앉을 시간이 어딨겠는가. 벤치는 그렇게 잊혀져갔다.

시간이 흘러 상급부대 지휘관인 사단장이 부대를 시찰하기로 했다. 깔끔히 보이기 위해 부대가 분주했다. 그러던 중 대대장의 눈에 수풀 사이 낡은 벤치가 눈에 띄었다. 대대장은 급히 페인트 칠을 지시했다. 지시를 받은 중대장은 페인트 칠을 다 하고나니 모르고 누가 벤치에 앉아서 더럽히면 어쩌나 걱정했다. 경고판을 쓸까 하다가 그것도 소용없을까 한명의 병사를 배치하게 했다. 지시를 받은 소대장은 이를 경계 명령서에 작성하여 정식 명령으로 등록했다.

하지만 별 일 없이 사단장은 지나갔고, 그렇게 다시 벤치는 잊혀졌다. 시간이 흘러 상급 부대에서 경계 강화 지시가 떨어졌다. 모든 경계를 2인 1개조로 편성하라는 지시였다. 무수한 계절이 지나고, 수많은 지휘관들이 교체되었지만 이 부대의 규칙과 질서는 반복되고 이어졌다.

이것이 두 명의 병사가 벤치를 지켜온 이유였다.

저자는 이 이야기를 두고, 의심하라고 주문합니다. 모두가 그냥 넘어가려고 하고, 분란을 일으키지 말라고 해도 진실을 의심하라고 말이죠. 물론 이 맥락에서는 다르게 해석해야겠지요. 개발자의 입장에서 이 말은, 우리는 잘 동작하는 코드라 할지라도 더 좋은 구조를 생각하고, 유지 가능한 단위를 고려하고, 끊임없이 바꿔나가야 한다는 말과 일맥상통할 것입니다.

실용주의 프로그래머라는 책에서 개발 비용은 생산 비용과 유지 비용의 합이라는 내용이 나오죠. 지속가능한 코드에 힘을 꽤나 실어줘야 한다는 말이고, 레거시는 유지비용 그 자체라고 봐도 무방한 개념입니다. 물론 레거시는 안만드는게 최고겠지만 그건 불가능해요. 그 대신, 항상 경계하며 마주치는 코드마다 더 좋은 구조를 생각하고, 변경해보며 나아가야 합니다. 그것이 지속가능한 코드를 만드는 방법이 아닐까 합니다.