5천억 원짜리 SW버그

해당 기사의 링크는 다음과 같다. 

https://zdnet.co.kr/view/?no=20131118093913 

5천억원짜리 SW버그가 주는 메시지

 

해당 사건에 대해 간단히 요약하면, 나이트 캐피털(Knight Capital)이라는 회사에서 8대 서버 중 마지막 8번 서버에서 사용되지 않던 레거시의 변수가 새 버전의 소프트웨어를 출시하면서 활성화되어 45분만에 5천억 원의 손해를 입게 된 것이다.

 

 

여기서 우리는 사용되지 않지만 존재하고 있는 코드에 대한 위험성을 알 수 있다. 이러한 코드를 삭제하지 않고 오랜 시간이 지나버리면 우선 해당 코드를 작성한 개발자가 프로젝트에 없을 경우, 배포되고 있는 서비스에서 해당 코드의 기능을 알 수 없으므로 (누군가 총대를 메고 코드를 정리하려고 작정하지 않는 이상) 서비스에 이상이 생길 까봐 해당 코드는 건드리지 않고 자연스럽게 내버려 두게 된다. 그러다 보면 이제 시간이 점차 흘러서 없앨 수도 없고, 남기기도 애매한, 목적을 알 수 없는 리스크를 안고 가는 것이다. 물론 해당 레거시가 어디에도 사용되지 않아 서비스가 원만하게 진행되면 다행이지만, 위 나이트 캐피털처럼 한 회사를 망하게 만들 수도 있는 것이다.

 

 

그렇다면 이러한 문제를 해결하기 위해서는 어떻게 해야 할까?

가장 근본적인 답은 레거시가 생기지 않도록 하는 것이다. 사용되지 않는 실행파일, 소스코드들을 우선적으로 확인하고 없애야 한다. 물론 사용되지 않는다는 것을 확신하기 위해 해당 소프트웨어에 대한 설명이 적혀 있는 문서와 같은 자료 기반으로 살펴본 뒤에 실행해야 한다. 이 때 이전의 논리를 주석처리하거나, if문을 통해 우회하는 것은 삼가하는 게 좋다.

그렇지만 이 이야기는 굉장히 이상적인 이야기이다. 이 모든 조건을 시행해서 언제나 레거시 없는 코드를 만들 수 있을까? 시간이 지나 해당 프로젝트에 새로운 기능들이 추가/삭제되는 과정에서 어떤 코드든 레거시가 될 수 있는 가능성을 가지고 있다. 그렇다면 이러한 현실에서 위와 같은 이슈를 줄이기 위해서 해당 기능을 추가할 때, 테스트 코드를 작성해야 한다.

아래 링크는 테스트 과정이 사례와 함께 나타나 있는 링크이다. 

https://sozu.tistory.com/24

낡은 코드(legacy code)를 어떻게 테스트 하시나요?

 

 

여러 기업들에서도 이러한 문제를 해결해서 깨끗한 프로그램을 만들기 위해 다양한 노력을 한다. 필자가 기억나는 것은 2023 네이버 데뷰에서 자바에서 런타임 데드 코드를 분석할 수 있는 프로그램 scavanger이다. 여기서 설명을 들으면서 클래스 로딩을 하지 않고 사용자 코드를 읽는다는 부분이 인상적이었고, 데드 코드 분석 외에 QA 진행 시 기능성 테스트 부족 인지와 같은 다른 기능들도 추가되었는데 scavanger가 특정 메소드를 호출했는지 안했는지에 대한 핵심 아이디어로 여기까지 확장된 게 기억에 남았다. 그리고 추후 go와 파이썬도 지원할 예정이라고 한다.

(데드 코드는 소스 코드에서 실행되지만 결과가 다른 계산에 사용될 수 없는 세션으로, 시간과 메모리가 낭비된다.)

해당 프로그램에 관련된 세션과 프로젝트 코드 페이지는 아래 링크를 참고하면 된다.

https://www.youtube.com/watch?v=qE7HY7Y-5vs&list=PLsFtzQAC8dDcQAcSG4PNrW7-0ExDZqqJA&index=34 

https://github.com/naver/scavenger 

GitHub - naver/scavenger: a runtime dead code analysis tool

 

이렇게 글을 쓰다 보니 코드를 통해 해당 기능을 잘 구현하는 것도 중요하지만, 필요 없는 코드에 대해서도 알고 해당 코드를 쓰지 않도록 고민하는 것도 그에 준하게 중요하다는 생각이 들었다. 그래서 클린 코드, 클린 아키텍처, TDD 관련 책들도 그만큼 많겠지?

어떤 분야든 그 분야에 대한 배움은 꾸준히 즐겁게 이어나가고 싶다.