Legacy는 왜 나쁜건가!?
아 우리 회사 기술 부채가 많이 생긴 것 같으니 이번에 개편했으면 하는데 앵과장 이것 좀 분석해서 내일까지 부탁해요!!
많은 분들이 Legacy에 대한 안 좋은 추억들 하나씩 있을 것 같은데 저도 마찬가지입니다.
프로젝트를 개편하거나 추가 기능을 만들려고 하면 기존에 서비스에서 동작하고 있는 기능에 대한 부분들을 이해하고 정책이나 다양한 케이스에 대해서 파악이 필요하기 때문입니다.
Legacy는 왜? 힘든 거지
Legacy 코드는 분명히 필요해서 구현했는데
고치려고 하면 왜 이렇게 힘든 건가요?
코드가 만들어지는 여러 가지 상황들 때문에 코드에 복잡도, 확장, 유연 여러 가지 문제가 발생하기 때문인 것 같습니다.
그리고 제일 중요한 프로젝트 진행되고 있는 현재 복잡한 상황 때문인 것 같아서 몇 가지 케이스로 코드가 만들어지는
과정을 예로 들어보겠습니다.
CASE A
스타트업 같은 경우 정확한 체계가 없기 때문에 자유분방한 코드가 만들어집니다.
코드 컨벤션, 코드 구성, 언어, 아키텍처 정해진 틀이나 규칙보다는 서비스에 필요한 필수적인 기능이 동작할 수 있는 코드 레벨들이 만들어지게 됩니다.
분명히 동작은 하지만 기능이 동작한다라는 부분에 초점이 있기 때문에 빠른 시간 동안 만들다 보면 운영을 해야 보이는 다양한 케이스가 보이기 때문에 그럴 수 있습니다.
CASE B
SI 프로젝트를 진행하다 보면 차세대라는 단어를 종종 보게 되는데
보통 차세대는 악랄한 프로젝트라는 인식이 강하게 드는 단어입니다.
우리은행 차세대 프로젝트
하나증권 차세대 프로젝트
삼성 보험 차세대 프로젝트
농협 차세대 프로젝트
예금보험공사 차세대 프로젝트
보건복지부 차세대 프로젝트
듣기만 해도 오금이 저리네요 ㅋㅋㅋㅋㅋ
차세대란?!
기존에 있는 서비스를 완전히 새로 만든다 라는 의미로 포장하지만 정작.....
바뀌는 건 껍데기뿐인 프로젝트가 무수히 많이 존재합니다.
요새는 빅뱅이라는 단어로도 얘기하는데
결국 둘 다 똑같은 행위를 하기 때문에 같은 거라고 보면 됩니다.
IT 개발자라면 피할 수 있으면 피해야 되는 프로젝트 중 하나라고 보면 됩니다.
굳이 똥을 꼭 찍어먹어 봐야겠다는 분들은 말리지 않겠습니다 ㅋㅋㅋㅋㅋㅋ
(사실 저도 궁금한걸 못참는 성격이라...찍어먹어보고 고생하는 스타일입니다 ㅜㅡㅜ)
검증도 안된 다양한 갑을병정에서 눈먼 돈을 벌려고 하는 인력 사장들이 돈 버는 수단 같은 프로젝트이기
때문에 이래도 되나 싶은 일정과 사람들로 구성이 됩니다.
IT감리사, PM, 아키텍처그룹(AA, TA, DBA), 외주인력
프로젝트 하면서 언급한 단어 2-3개 이상 구성이 되고 있다면 당신은 SI 프로젝트를 하고 있다고 보면 됩니다.
보통 저렇게되면 제대로 만들어지는걸 본적이 없네요!!
Legacy 를 접근하는방법
Legacy는 그당시 분석 설계 오픈소스 등 다양한 관점에서 선택되고 만들어졌기때문에
코드가 나쁘다 라기보다는 상황이 문제일 경우가 다반사입니다.
명확한 코드컨벤션, 일정, 사람 훌륭한 Legacy 코드레벨도 많기 때문입니다.
올바른 방향으로 구성된 개발 코드는 훌륭한 개발문화를 통해서 공유됩니다.
괜찮은 스타트업, 어느정도 인지도가 있는 네카라쿠배 같은경우는 테크 블로그에서 공유되는 자료를 보더라도
내가 지금이렇게 일해도 되나 싶은 올바른 방향에 자료들을 볼수 있습니다.
일단 Legacy 코드를 분석할때는 정책, 기획, 서비스, 타킷, 방향, 목표 등에 대해서 고민해보고
코드레벨 부터 차근차근 점진적으로 테스트 단위 코드를 구성하면서 작업해야합니다.
제일 중요한 마음가짐으로는 그럴수 있다는 마음으로 진행하시면됩니다.
그래...... 그럴수있지
지금 다른 회사에서는 내가짠 코드를 보면서 왜!! 이렇게 했지 라고 생각하는 개발자를 떠올리며
항상 겸손한마음으로 구현된 코드를 접근해보시면됩니다.