Amazon 주문 처리 조직에서 반복된 재설계
끝나는 것은 코드의 악화인가, 사업인가
기술 부채에는 파산이 없다
초기화에 대한 기대 대신 지속적인 품질 관리
구구절절 다 올른말이지만, 개선할 능력이 있어도
조직 구조와 보상체계를 빼먹을 수는 없어요.
특히 제조업에서는 “제가 이렇게 저렇게 해서 SW부채를 해결했습니다.” 라고 한들 알아 듣는 사람이 없고,
성과로 인정해주지 않는 문화라면 굳이 어렵고 도전적이고 알아주지 않는 일에 뛰어들기란 쉽지 않습니다.
그래서 매출에 얼마만큼의 영향을 미쳤지?
그래서 뭐가 더 좋아졌다고? 얼만큼의 경쟁력이 더 생겨서 판매에 도움이 댓나?
즉시 효과가 발생하는, 눈에 보이는 일을 한 사람에게 성과나 공이 돌아가는 조직과 문화에서는 이런 진실된 논의가 많이, 아주 많이 퇴색되는걸 많이 보기도 하고 실제 겪기도 했죠. 더욱이 이런 일을 시작하는 것 자체도 어려울 수 있는 조직문화도 많아요.
기술과 개발에만 신경써도 힘든데, 정치도 잘해야되고 지금 하는 일의 포장도 그럴싸하게 잘해야 되니까 배로 힘든 일이네요.
지금도 유효한 얘기일까요
Lobste.rs 의견들
재설계하려면 먼저 시스템을 이해해야 함
재설계는 고급 작업처럼 들리지만, 기존 시스템의 기능을 이해하는 일은 허드렛일처럼 들리는 게 문제임
제대로 이해하고 나면 구조를 바꿀 아이디어도 떠오르겠지만, 재작성을 주장하는 상당수는 그 단계까지 가지 못함
레거시인 만큼 핵심 정보에 잡음이 많이 섞여 있기 때문임
그런데 문서도 없고 초기 개발자들마저 떠났다면 막막해짐
끝을 알 수 없는 재작성에 매달리지 않아 사업적으로도 합리적이고, 이미 충분히 이해한 부분부터 교체할 수 있음
물론 사업 환경에서는 기존 코드베이스를 버리기 전에 새 시스템부터 만들어야 할 것임
기존 시스템이 기술 부채에 빠져 회생 불가능하다고 선언하고, 새 팀을 꾸려 처음부터 다시 만들기 시작함
하지만 기존 시스템은 핵심 사업을 계속 운영하므로 변경이 멈추지 않음
곧 폐기될 시스템을 맡은 개발자들은 새 기능을 최소한의 노력으로 추가하게 되고, 기술 부채는 더 쌓임
새 팀은 야심 차고 다소 순진한 상태에서 출발함
처음에는 새로 만드는 덕에 속도가 빠르지만, 시간이 갈수록 대체 대상의 동작과 범위를 누구도 완전히 이해하지 못한다는 사실이 드러남
애초에 문서화와 테스트가 잘되어 있었다면 교체할 필요도 없었을 것임
몇 달, 심하면 몇 년 동안 가치를 내놓지 못하면 출시 압박이 커짐
결국 기존 기능 일부만 처리하거나, 거의 방치된 기존 시스템에 넣기 어려웠던 새 기능만 담당하는 형태로 출시하게 됨
이제 운영 환경에는 아무도 손대기 싫은 낡은 시스템과, 몇 가지 기능만 처리하면서 코드의 80%는 언젠가 기존 시스템을 대체하려고 대기 중인 새 시스템이 함께 존재함
회사가 인내심을 잃지 않고 작업을 계속 허용해 주면 그나마 다행임
시간이 길어지고 기존 시스템이 끈질기게 계속 돌아갈수록 “우선순위가 바뀌었다”며 교체 작업을 중단할 위험이 커짐
결국 하나였던 시스템이 둘로 남게 됨
이 과정을 책임 있게 완수하는 방법을 다룬 글 중 가장 좋았던 것은 Will Larson의 Migrations: the sole scalable fix to tech debt 임
다음에 비슷한 상황을 만나면 기존 시스템의 자동화 테스트를 최대한 보강 한 뒤, 필요한 부분을 겨냥한 리팩터링으로 원하는 구조에 도달할 수 있는지 살펴보라고 강하게 권할 것임
많은 경우 처음부터 새로 만들겠다는 유혹보다 이쪽의 성공 가능성이 훨씬 높다고 봄
몇 군데를 보고 나면 명확한 책임자 없이 여러 사람의 손을 거친 시스템 을 알아볼 수 있게 됨
근본적으로 도메인 경험과 연속성이 있어야 시스템이 더 단순하고 짜임새 있어짐
사람들은 대개 기능을 추가하며 기여하려 하지만, 기능마다 제약과 불변 조건이 늘어나 시스템의 일관된 구상이 흐려짐
덧붙이기는 쉽고 제거를 정당화하기는 훨씬 어려워서, 여러 사람을 거칠수록 개념적 일관성이 약해짐
“지금 전부 고치자”는 태도는 통하지 않음
변수 이름을 바꾸고, 알아낸 사실을 코드에 주석으로 남기고, 작업 절차를 문서화·자동화해 지식이 살아남게 하고, 테스트로 동작을 파악하고 변경 시에도 유지되게 하는 작은 개선의 축적 은 효과가 있음
이해가 깊어지고 자동화 테스트가 보강되면 더 큰 변경도 안전하게 할 수 있음
핵심 참고서는 Feathers의 Working Effectively with Legacy Code와, 훨씬 덜 알려진 Object-Oriented Reengineering Patterns 임
문제는 급한 불을 끄기 시작하자마자 진척 소식을 들은 사람들이 “더 안전해진” 코드베이스에 뛰어들어 다시 기능을 추가하려 한다는 데 있음
그러다 무엇을 출시해도 다른 곳이 깨지는 지경이 되어 개발 속도가 0에 가까워짐
이런 시스템은 대개 “붕괴”하지 않음
코드 변경 비용이 커지고 변경 속도와 정확성이 떨어져 사람들이 손대기를 피하게 됨
기능은 시스템 바깥에 덧붙여지고, 문제가 연동 코드로 서서히 번지며, 그 팀들에서도 인력 교체가 일어나면 악화가 가속됨