솔직히 고백하자면, 저는 3년 전쯤 퇴사를 진지하게 고민했습니다.
이유는 단 하나, '레거시(Legacy)' 때문이었어요.
문서 한 장 없는 5년 된 스파게티 코드, 배포할 때마다 터지는 원인 모를 버그, 그리고 "일단 되게만 해주세요"라는 기획팀의 요청.
개발자라면 누구나 한 번쯤 겪는 '늪'이죠.
코드를 뜯어고치자니 어디서부터 손대야 할지 막막했고, 그대로 두자니 썩어가는 게 눈에 보였습니다.
마치 생명력을 잃어버린 황무지 같았죠.
그런데 최근 일리노이 주에서 들려온 흥미로운 소식을 보고, 그때의 기억이 떠올라 무릎을 쳤습니다.
200년 만에 바이슨(Bison)이 돌아왔다는 소식입니다.
일리노이 케인 카운티(Kane County)라는 곳인데, 이곳은 원래 광활한 초원(Prairie)이었습니다.
하지만 지난 200년 동안 농경지로 개발되면서 바이슨은 자취를 감췄고, 생태계는 완전히 망가졌죠.
재미있는 건, 사람들이 단순히 '보기 좋으라고' 바이슨을 데려온 게 아니라는 점입니다.
바이슨은 생태학 용어로 '핵심종(Keystone Species)'입니다.
이 친구들이 돌아와서 흙목욕을 하며 땅을 파헤쳐야 웅덩이가 생기고,
그 웅덩이에 물이 고여야 곤충이 살고,
그 곤충을 먹으러 새들이 돌아옵니다.
실제로 바이슨이 사라진 후, 바이슨 등 위의 벌레를 잡아먹던 새들의 행동 양식까지 이상하게 변했었다고 해요.
즉, '핵심' 하나가 빠지니까 전체 시스템의 로직이 꼬여버린 겁니다.
저는 이 기사를 읽으면서 우리가 마주하는 '시스템 아키텍처'를 떠올렸습니다.
우리가 관리하는 코드베이스도 마찬가지 아닐까요?
처음엔 급하게 기능을 추가하느라(마치 농경지를 개간하듯),
코드의 일관성이나 테스트 코드 같은 '핵심 가치'를 몰아내 버립니다.
당장은 콩을 심어 수확을 하듯 기능이 돌아가는 것처럼 보입니다.
하지만 시간이 지나면 어떻게 되나요?
사소한 수정에도 사이드 이펙트(Side Effect)가 터지고, 개발자들은 지쳐서 떠납니다.
생태계가 무너진 겁니다.
기사에서 인상 깊었던 건, 이 복원 프로젝트를 주도한 분들의 태도였습니다.
그들은 바이슨을 '소유(Own)'한다고 말하지 않습니다.
대신 '관리(Steward)'한다고 표현하더군요.
"우리는 바이슨의 관리자(Stewards)입니다. 그들이 괜찮은지 확인하고 돌볼 뿐이죠."
이 대목에서 저는 3년 전, 그 엉망진창이었던 프로젝트를 대하던 제 태도를 반성했습니다.
당시 저는 "이건 내 코드가 아니야, 전임자가 싼 똥이지"라며 방관하거나,
반대로 "내가 다 갈아엎어서 내 걸로 만들 거야"라는 오만에 빠져 있었습니다.
하지만 진정한 시니어 개발자라면, 코드를 소유하려 들기보다 '건강한 생태계'를 만드는 데 집중해야 했습니다.
마치 바이슨을 다시 데려오듯 말이죠.
개발 조직에서의 '바이슨'은 무엇일까요?
아마도 견고한 CI/CD 파이프라인일 수도 있고,
팀원 모두가 합의한 코딩 컨벤션일 수도 있으며,
때로는 심리적 안전감을 주는 회고 문화일 수도 있습니다.
저희 팀은 당시 무리한 리팩토링 대신, 아주 작은 '핵심 규칙' 하나를 도입했습니다.
"모든 버그 수정에는 반드시 실패하는 테스트 케이스를 먼저 작성한다."
거창한 아키텍처 변경이 아니었습니다.
하지만 이 작은 '바이슨' 한 마리가 들어오자 변화가 시작됐습니다.
테스트가 쌓이니 배포 공포가 줄어들었고,
코드를 읽는 시간이 단축되니(가독성),
여유가 생긴 개발자들이 다시금 코드 퀄리티를 논의하기 시작했습니다.
마치 바이슨이 돌아오자 멸종 위기였던 새들이 다시 날아든 것처럼요.
오늘 여러분의 프로젝트를 한 번 돌아보세요.
혹시 기능 개발이라는 명목하에, 시스템을 지탱하던 '바이슨'을 쫓아내진 않았나요?
지금 당장 거대한 숲을 만들 수는 없습니다.
하지만 200년 만에 돌아온 바이슨 여섯 마리가 황무지를 바꾸기 시작했듯,
오늘 작성하는 작은 테스트 코드 하나, 친절한 주석 한 줄이
여러분의 죽어가는 레거시를 다시 숨 쉬게 할 '핵심종'이 될 수 있습니다.
우리는 코드의 주인이 아니라, 이 거대한 디지털 생태계의 관리자(Steward)니까요.
