빅뱅식 전면 재작성 없이 레거시 소프트웨어를 현대화하기

자리 잡은 거의 모든 회사에는 하나쯤 있습니다. 모두가 속으로 못마땅해하는 소프트웨어 말입니다. 느리고, 보기 흉하며, 팀의 절반은 아무도 고치지 않은 버그의 우회법을 알고 있고, 그것을 이해하던 단 한 사람은 2019년에 떠났습니다. 충동은 늘 같습니다. 다 태워 버리고 새것을 짓자는 것이죠. 그리고 그 충동이야말로, 대개의 경우, 좋은 회사가 한 해와 적지 않은 거금을 헛되이 잃는 바로 그 방식입니다.

대규모 재작성이 잘못되는 것을 충분히 여러 번 보아 왔기에 저는 그에 대한 반사적인 경계심을 가지고 있습니다. 창업자가 삐걱대는 주문 시스템이나 오래된 일정 관리 도구를 보여주며 한숨을 쉬고는 이런 식으로 말합니다. “그냥 통째로 바꿔야 할 것 같아요.” 어쩌면 언젠가는 그렇게 될 수도 있습니다. 그러나 전면 재작성, 즉 낡은 시스템을 뜯어내고 그 옆에 번쩍이는 새것을 지어 스위치를 넘기는 일은 소프트웨어 전반에서 가장 위험한 수 가운데 하나입니다. 비용이 많이 들고, 약속보다 훨씬 오래 걸리며, 그동안 내내 눈을 가린 채 나아가게 됩니다. 낡은 시스템이 십오 년 동안 조용히 처리해 온 온갖 기이한 예외 사례를 새것이 모두 감당하기를 그저 바라면서요.

다행스러운 점은, 빅뱅식 재작성이 유일한 선택지인 경우는 거의 없고 최선인 경우도 드물다는 것입니다. 더 차분한 현대화의 길이 있습니다. 점진적이고, 되돌릴 수 있으며, 작업하는 동안에도 돈을 벌어야 하는 사업에 부드러운 방식입니다. 이 글은 그 길에 대한 안내입니다. 정말 무엇을 고쳐야 하는지 어떻게 가려내는지, 전체 시스템을 멈추지 않고 아픈 부분을 어떻게 교체하는지, 그리고 전면 재작성이 진정으로 옳은 판단이 되는 때는 언제인지 알려드립니다.

빅뱅식 재작성은 왜 그토록 매혹적이고, 또 그토록 위험한가

전면 재작성이 유혹적인 까닭은 백지상태를 약속하기 때문입니다. 레거시의 난장판도 없고, 타협도 없으며, 최신 도구로 제대로 지은 신선한 코드베이스. 화이트보드 위에서는 당연해 보입니다. 그러나 현실에서는 수년간 쌓인 업무 로직을 다시 짓는 일에 서명하는 것입니다. 그 상당수는 문서화되어 있지 않고, 일부는 떠난 사람들의 머릿속에만 살아 있습니다. 그러는 동안에도 시계는 돌아가고 청구서는 날아듭니다.

더 깊은 함정은 평행 우주 문제입니다. 교체본을 짓는 수개월에서 수년 동안, 두 개의 시스템을 떠안게 됩니다. 낡은 것은 여전히 사업을 돌려야 하고, 새것은 아직 준비되지 않았습니다. 사업에 필요한 모든 변경은 두 번씩 해야 하며, 그러지 않으면 새 시스템은 출시되기도 전에 현실에 뒤처집니다. 팀은 둘 다 살려 두느라 소진됩니다. 그리고 새 시스템이 모든 것을 해내기 전까지는 누구도 전환을 허락받지 못하므로, 이른 성과도, 피드백도, 작동한다는 증거도 없습니다. 오직 단 한 번의 거대한, 전부 아니면 전무인 출시일을 향한 길고 불안한 기다림만 있을 뿐입니다.

여기에는 업계에 잘 알려진 이야기가 있고, 그럴 만합니다. 두 번째 시스템, 그 거창한 재작성은 추정치의 세 배가 걸리고, 대체하려던 것보다 적은 기능으로 도착하는 버릇이 있습니다. 추정이 빗나가는 것은 사람들이 부주의해서가 아닙니다. 낡은 시스템이 조용히 제대로 해내고 있는 자잘한 일들을, 시작 시점에는 누구도 모두 내다볼 수 없기 때문입니다.

'레거시'가 실제로 뜻하는 것 (나이의 문제가 아닙니다)

우리는 레거시라는 말을 그저 '낡았다'는 뜻인 양 던집니다. 그렇지 않습니다. 십 년째 돌아가는 소프트웨어 가운데 멀쩡한 것이 수두룩합니다. 지루하고, 안정적이며, 값을 다 치렀고, 제 일을 합니다. 나이만으로는 무언가에 손댈 이유가 되지 않습니다. 이 분야 전체에서 가장 값비싼 실수는, 조용히 잘 돌아가던 것을 그저 낡아 보인다는 이유로 현대화하는 것입니다.

소프트웨어가 레거시라는 딱지를 얻는 것은, 그것이 적극적으로 당신의 발목을 잡을 때입니다. 아무도 완전히 이해하지 못해 안전하게 바꿀 수 없을 때. 지금 의존하는 도구들에 연결되지 못할 때. 단 한 사람만이 그것을 살려 둘 수 있는 유일한 사람일 때. 너무 느리거나 부서지기 쉬워 팀이 그 주위에 우회법의 거대한 구전을 쌓아 올렸을 때. 그것이 진짜 정의입니다. 작성된 연도가 아니라, 그것이 오늘 당신에게 지우는 비용과 내일로 떠안기는 위험입니다.

무엇이든 손대기 전에 진단하십시오

단 한 줄이 다시 쓰이기 전에, 고통이 실제로 어디에 있는지에 대한 정직한 지도가 필요합니다. 대개 모두가 미워하는 시스템은 80퍼센트는 멀쩡합니다. 말썽은 몇몇 특정한 곳에 집중되어 있습니다. 느린 화면 하나, 망가진 연동 하나, 이중 입력을 강요하는 워크플로 하나. 그리고 그 몇 곳이 거의 모든 불만을 만들어 냅니다. 그것들을 찾으면 프로젝트 전체를 찾은 셈입니다.

그것들을 찾는 방법은 기술 감사를 먼저 하는 것이 아니라 대화입니다. 그것을 매일 쓰는 사람들과 마주 앉아 어디가 아픈지 물으십시오. 어디에서 기다립니까? 무엇을 다시 입력합니까? 괴로워서 무엇을 피합니까? 공식 시스템을 우회하려고 어디에 개인 스프레드시트를 둡니까? 그 우회법들은 금입니다. 하나하나가 고칠 가치가 있는 문제를 정확히 비추는 엑스레이입니다.

• 사람들이 가장 많이 불평하는 화면과 단계 — 이론이 아니라 그들의 실제 일상 업무에서.
• 두 시스템이 서로 말하지 않아 데이터가 두 번 입력되는 모든 곳.
• 망가졌거나 애초에 없어서, 도구 사이의 수작업 복사·붙여넣기를 강요하는 연동.
• 오직 한 사람만 다루거나 고칠 줄 아는 모든 것 — 당신의 단일 장애점.
• 정말로 멀쩡한 부분. 그래서 지키고 그대로 둘 수 있도록.
• 지금 시스템이 도저히 따라 자라지 못하는, 내년에 사업이 필요로 할 것.

이를 정직하게 하면 프로젝트는 대개 줄어듭니다. “전부 바꾸자”며 들어온 대표가 고쳐야 할 것은 세 가지뿐임을 깨닫고 나갑니다. 그것은 실망이 아니라 안도입니다. 고칠 수 있는 세 가지는 이번 분기에 끝낼 수 있는 프로젝트입니다. 전면 교체는 살아남지 못할 수도 있는 한 해입니다.

스트랭글러 방식: 한 번에 한 조각씩 교체하기

이를 안전하게 하는 패턴이 있고, 다소 으스스하지만 기억에 남는 이름이 붙어 있습니다. 스트랭글러 방식입니다. 목 졸라 죽이는 무화과나무에서 따왔습니다. 나무를 휘감고 자라며 그 구조를 서서히 차지하다가, 마침내 새 가지가 홀로 서고 낡은 줄기는 사라지는 그 덩굴 말입니다. 소프트웨어에 적용하면 그 발상은 아름답도록 실용적입니다. 낡은 시스템을 단 한 번의 영웅적 교체로 바꾸지 않습니다. 그 주위로 새것을 한 조각씩 길러, 낡은 것 중 누구에게도 필요한 것이 남지 않을 때까지 이어 갑니다.

실제로는 이렇게 돌아갑니다. 아픈 조각 하나를 고릅니다. 이를테면 모두가 미워하는 청구 모듈이죠. 그 조각만의 현대적 교체본을 만듭니다. 청구를 새 모듈로 보내고, 나머지 모두는 낡은 시스템 위에서 손대지 않은 채 계속 돌립니다. 한동안 지켜봅니다. 단단해지면 낡은 시스템의 그 부분은 잠잠해지고, 다음 조각으로 넘어갑니다. 낡은 시스템은 한꺼번에 허물리는 대신 촛불처럼 서서히 줄어듭니다.

이것이 재작성보다 훨씬 안전한 까닭은 모든 단계가 작고, 살아 있으며, 되돌릴 수 있기 때문입니다. 결코 눈을 가린 채 나아가지 않습니다. 새 조각마다 빠르게 실사용에 들어가므로, 정말 작동하는지를 빨리 알게 됩니다. 무언가 잘못되어도 위험에 건 것은 한 모듈일 뿐 사업 전체가 아니며, 고치는 동안 대개 낡은 경로로 되돌아갈 수 있습니다. 끝에 단 한 번의 무서운 출시 대신, 도중에 성과를 얻습니다. 그리고 사업은 그 내내 평소대로 돌아갑니다.

그 리듬은 실제로 어떻게 보이는가

1. 1
   가장 아프고 가장 독립적인 조각을 고르십시오

   큰 고통과 깔끔한 경계를 원합니다. 많이 아프면서도 다른 모든 것에 손가락을 들이밀지 않은 모듈 말입니다. 그것이 첫 표적입니다.
2. 2
   낡은 시스템 앞에 얇은 층을 두십시오

   작은 라우팅 층이 어느 요청을 낡은 시스템으로, 어느 것을 새 조각으로 보낼지 결정합니다. 이것이 나머지 모두를 가능하게 하는 이음매입니다.
3. 3
   그 한 조각만 만들어 내보내십시오

   한 모듈을 교체해 실제 사용자의 손에 쥐여 주고, 그 한 조각의 업무만 그쪽으로 보냅니다. 몇 년이 아니라 몇 주이며, 나머지 시스템은 전혀 움직이지 않았습니다.
4. 4
   안정시킨 뒤 다음 조각으로 넘어가십시오

   새 모듈이 신뢰를 얻으면, 그에 대응하는 낡은 시스템의 부분이 잠듭니다. 다음 아픈 조각으로 반복하며, 나아가면서 배웁니다.
5. 5
   비었을 때 낡은 시스템을 퇴역시키십시오

   마침내 레거시 시스템은 누구도 의지하지 않는 상태가 됩니다. 그때서야 전원을 끕니다. 조용히, 소동 없이. 중요한 것은 이미 모두 옮겨졌기 때문입니다.

재작성과 무엇이 다른지 눈여겨보십시오. 두려워할 단 하루의 출시일이 없습니다. 유지할 평행 우주가 없습니다. 새 시스템은 3주 차부터 운영에 들어가 제 몫을 벌며 당신에게 무언가를 가르칩니다. 자꾸만 미뤄지는 출시를 연구실에서 기다리는 대신 말입니다.

때로는 교체할 필요조차 없습니다

무언가를 교체하기 전에, 낡은 시스템이 교체를 필요로 하는지, 아니면 그저 섬이기를 그만두면 되는지를 물을 가치가 있습니다. “새 시스템이 필요하다”는 문제의 놀랍도록 많은 부분이 실은 “우리 시스템들이 서로 말하지 않는다”는 문제입니다. 낡은 소프트웨어는 제 일은 잘합니다. 그저 사일로에 앉아, 사람들에게 데이터를 손으로 실어 나르게 만들 뿐입니다.

그런 경우 가장 싸고 빠른 해결책은 새 시스템이 아닙니다. 다리입니다. 낡은 소프트웨어를 연결로 감쌉니다. 다른 도구들과 자동으로 데이터를 주고받게 하는 연동과, 사람들이 실제로 만지는 부분을 위한 현대적 계층을 위에 얹는 것이죠. 낡은 엔진은 아래에서 계속 돌고, 팀은 깔끔한 표면과 복사·붙여넣기의 끝을 얻습니다. 화려하지는 않지만, 종종 전체 작업에서 유로당 가장 높은 수익을 냅니다.

전면 재작성이 진정으로 옳은 판단이 되는 때

이 가이드 내내 대규모 재작성에서 당신을 말려 왔으니 공정하게 말씀드리겠습니다. 때로는 그것이 정말 답입니다. 아무리 땜질하고 다리를 놓고 조각별로 교체해도 살릴 수 없을 만큼 토대가 썩은 경우가 있고, 그렇지 않은 척하는 것은 시체를 떠받치는 데 돈을 쓰며 불가피한 것을 미룰 뿐입니다.

정직한 신호는 구체적입니다. 시스템이 기반으로 삼은 기술이 죽었거나 죽어 가고 있습니다. 지원도, 보안 업데이트도 없고, 다룰 수 있는 사람도 남지 않았습니다. 사업이 너무도 근본적으로 바뀌어 낡은 모델이 더 이상 현실에 전혀 들어맞지 않습니다. 또는 시스템이 너무 얽혀 있어 작은 변경조차 관계없는 곳을 으레 망가뜨립니다. 이는 대개 애초에 스트랭글러 방식을 적용할 깔끔한 이음매가 없다는 뜻이기도 합니다. 이 가운데 둘이나 셋이 한꺼번에 참일 때, 점진적 작업은 더 안전한 선택이기를 그칩니다.

그리고 결국 재구축하더라도 점진적 작업을 먼저 해 둔 데에는 조용한 보상이 있습니다. 거기에 다다를 무렵이면, 처음보다 시스템을 훨씬 잘 이해하게 됩니다. 교체한 모듈마다 원래 저자들이 결코 적어 두지 않은 무언가를 가르쳐 주었습니다. 그 지식으로 무장한 재작성은, 첫날의 낙관만으로 띄워 보낸 것과는 완전히 다른, 훨씬 안전한 짐승입니다.

아무도 말하지 않는 부분: 결국은 대부분 사람의 문제입니다

기술 가이드가 건너뛰는 것이 있습니다. 낡은 소프트웨어를 현대화하는 가장 어려운 부분은 대개 코드가 아니라, 수년에 걸쳐 그것에 적응해 온 사람들입니다. 그들은 그 별난 점들을 압니다. 그 기이한 단축키에 손이 익어 있습니다. 객관적으로 더 나은 새 모듈도 처음 두 주 동안은 그저 낯설다는 이유만으로 더 나쁘게 느껴질 수 있습니다. 이를 무시하면 완벽한 기술적 마이그레이션조차 실패할 수 있습니다.

점진적 방식은 여기서도, 거의 뜻하지 않게 도움이 됩니다. 변화가 한 번에 작은 한 조각씩 도착하므로, 사람들은 어느 월요일 아침에 모든 것을 다시 배우라고 요구받는 대신 서서히 받아들입니다. 일상 사용자를 일찍 끌어들이십시오. 교체본이 완성되기 전에 그들이 모양을 잡게 하십시오. 새 청구 화면 설계를 도운 팀은 그것을 옹호하고, 머리 위로 떨어진 팀은 그것이 똑같더라도 못마땅해합니다. 현대화란 소프트웨어 옷을 입은 변화 관리 프로젝트입니다.

자주 묻는 질문