자바스크립트 어플리케이션 마이그레이션하기 (2/2)

자바스크립트 어플리케이션 마이그레이션하기에 대해 알아봅니다.

작성자

조덕기

조덕기

DanielCho

본 포스팅은 JS PlaygroundMigrating complex JavaScript applications를 저자의 허락하에 번역한 글입니다. 오탈자, 오역 등이 있다면 연락부탁드립니다.

Tests

이 과정에서 우리는 어플리케이션이 망가지지 않았는지 확인해야 했습니다. 기능이 손상되지 않았는지 확인하기 위한 일련의 테스트 없이 마이그레이션된 코드를 일주일에 몇 번이나 배포하는 것은 불가능합니다. 이미 작성된 Angular용 테스트 코드가 사실 많은 도움이 되었습니다. 그리고 Angular에서 React로 테스트 코드를 바꿀 수 있었습니다 (Jest와 Enzyme을 이용해서 작성된 것 – 여기에서 더 자세히 읽어보실 수 있습니다) 그러나, 테스트 코드를 마이그레이션할 때, 마이그레이션 과정에서 아무런 이슈가 없다는 것을 확신할 수 없습니다. 우리에게 소중했던 것은, Protractor을 이용해 작성된 end to ends test를 진행한 것입니다.

우리는 IE를 지원하고 있었는지, 아니면 마이그레이션할 때 크로스 브라우저 버그를 만들지 않았는지 확인하며 IE11에서 이러한 테스트들을 구동할 수 있었습니다. 이 테스트들의 이점은 코드에서 완전히 분리된다는 것입니다. 그들은 상호작용 하는 UI가 Angular 또는 React 기반이라면 상관하지 않습니다. 이 테스트의 단점은 느리다는 것입니다. 그래서 우리는 핵심 사용자 이동과 인터렉션을 다루는 다섯 가지 테스트에만 머물러 있었습니다. 테스트 커버리지 대 테스트 속도 사이에서 균형을 찾는 것이 중요합니다.

Team

이 프로젝트에서 저에게 가장 중요한 것들 중 하나는 (하지만 블로그에는 잘 기술하지 않는 하나는) 긴 시간동안 한 팀에서 한 프로젝트를 위해 일하며 배운 것들입니다. 일 년 동안 같은 프로젝트만을 위해 일하는 것은 새로운 경험이었습니다. 보통은 한 프로젝트의 한 가지 목표를 위해 2-3주간 일하고, 다음으로 넘어갑니다.

여기에서 가장 중요한 측면 중 하나는 무엇을 해야하는지 아는 것이었습니다. 우리는 마이그레이션에 필요한 모든 코드가 있었고, 그 중에서 작업해야할 부분을 선택할 수 있었습니다. 우리가 무엇을 선택하고 어떤 부분을 먼저 공략해야 할까요? 첫 번째 단계는 모든 기능을 확인하고 우리가 지원해야하는 기능인지 확인하는 것입니다. 우리는 코드베이스의 많은 부분이 사용되었거나, 필요 없는 기능을 지원하는 것을 발견했고, 이 때문에 우리는 많은 코드를 지워야 했습니다. 모든 기능을 거치며 어떤 것이 필요한지 골라내는 데 시간이 많이 걸렸지만, 다른 대안 방법에 비해서는 매우 효과적이었습니다. 다시는 사용되지 않을 기능을 마이그레이션하는 것은 그 누구에게도 좋지 않았을 것입니다.

필요 없는 코드를 지운 후, 다음 세 가지에 기반하여 구성 요소의 우선 순위를 매겼습니다.

  • 버그 비율 – 마이그레이션과 동시에 버그를 수정할 수 있었으므로 버그가 많은 기능이 우선 순위를 차지했습니다.

  • 코드 품질 – 우리가 이해하지 못한 코드가 우선 순위를 차지했습니다. 아무도 이해하지 않는 코드를 지우는 것은 전체 마이그레이션의 큰 동기 부여가 되었습니다.

  • 사용 빈도 – 이것은, 일주일에 몇 번이나 해당 코드가 사용되었는지에 대한 것입니다. 많은 개발자들이 사용하는 코드는 마이그레이션해야합니다. 우리는 예전의 Angular 코드를 가지고 일하거나 유지하는 데 최소한의 시간을 쓰고 싶습니다.

세 가지 요소를 감안해 일의 우선 순위를 정할 수 있습니다:

img

우리는 또한 다양한 종류의 일을 혼합했습니다. 마이그레이션의 일부는 더 시각적인 업무였고, 작은 Angular 컴포넌트로부터 React로 이동 – 몇몇은 HTTP 레이어를 Angular의 $http 서비스로부터 fetch API 사용으로 옮기는 더 “내부적인"" 것이었습니다. 다른 것들은 순수하게 툴 기반이었습니다. 우리는 마이그레이션을 Browserify에서 Webpack으로 도구를 옮기고, Karma에서 Jest로 테스트를 옮기는 좋은 계기가 되었습니다. 우리는 개발자 개개인이 할 수 있는 한 최대한 다양한 일 (물론, 취향에 따라서도) 을 할 수 있도록 했는데, 이는 작업이 단조로워질 위험성이 있기 떄문입니다. 지루함을 느끼지 않고도 Angular에서 React로 작은 구성 요소를 마이그레이션할 수 있는 경우가 많았습니다.

팀의 동기를 유지하는 한 가지 핵심은 우리가 항상 탄력을 유지하는 것이었습니다. 이렇게 하기 위해서 우리는 배포 시에 망가짐이 생기지 않게 확인하는 테스트 시리즈를 기반으로 공격적으로 매일 새로운 React 코드를 업데이트했습니다. 이는 우리가 진전을 이루고 있는 것처럼, 심지어는 단계적으로 더 큰 작업을 한다고 느끼게 해주었습니다. 이는 또한 위험을 현저하게 줄여 줍니다 – 만약 작은 조각을 한 번에 배포하고 무언가 망가지면, 어떤 배포 사항이 (따라서 어느 코드 변경이) 원인인지 정확히 파악할 수 있습니다.

변화를 시각화하는 데 도움을 주기 위해 코드베이스에 대한 대략적인 측정을 제공하는 다양한 스크립트가 있었습니다. 하나는 React를 가져온 파일에 대한 코드베이스를 grep했고, 다른 하나는 Angular 에 대해 똑같이 했습니다. 이것은 우리에게 (매우 대략적인) 우리 과정의 개요를 주었고, 과학적이지 않았지만, 우리가 일한 것에 대해 숫자가 바뀌는 것을 팀으로서 보는 것은 아주 멋졌습니다.

Talking

우리가 처음 소프트웨어 마이그레이션을 고려할 때, 왜 해야 하는지, 얼마나 걸릴 것인지에 대해 개발팀과 소통했습니다. 개발팀과 소통할 때, 특정 전문 용어를 사용하고 상당히 심오한 수준으로 기술에 대해 토론하는 것은 자연스러운 일입니다. 다만 우리가 처음 실수한 것은 개발팀 외의 팀들과 명확하게 의사소통 하지 못한 것입니다. 이 팀들은 틀림없이 더 중요합니다. 이들은 티켓을 구입하지 못해 화난 고객을 상대하거나, 우리 제품을 사용하고 싶어하는 사람들을 상대하는 팀입니다. 그들은 우리 제품에 대한 부정적 피드백을 받는 사람들이고, 특정 기능이 작동하지 않을 경우 화난 고객들의 전화를 받는 사람들입니다. 초기에 우리는 우리의 마이그레이션에 대한 동기를 뚜렷하게 소통하지 않았으며, 따라서 개발팀 밖에서 큰 지원을 받지 못했습니다. 많은 사람들은 우리가 제품을 1년 동안 동일하게 유지하고 기본 코드만을 바꾸겠다고 했을 때 (당연히) 좌절했습니다.

이것을 해결하기 위해 커뮤니케이션을 팀의 관점에서 바꾸는 것이 중요합니다. React의 장점과 Angular의 단점을 이야기하는 것 대신, 마이그레이션이 가져올 효과에 대해 설명하는 것이 중요합니다. 이렇게 하기 위해 우리는 고치기 힘든 버그가 더 이해하기 쉬운 구조와 코드베이스로 이동하면 어떻게 쉬워질 수 있는지 설명했습니다; 우리는 모바일 장치에서 부피가 큰 코드가 느려지며 어떻게 문제가 생길 수 있는지도 설명했습니다. 시스템에 대해 더 큰 자신감을 가지며 어떻게 긴급한 요청 및 버그 수정에 신속하게 대처할 수 있는지 설명했습니다. 이것은 테크 분야 밖에 있는 사람들이 우리가 무엇을 하며 왜 하고 있는지 정말 이해하게 도와주었습니다.

우리의 버그를 기준으로 마이그레이션 우선 순위를 정한 방법은 정말 통했습니다. 우리는 고객 지원 (그리고 우리 고객의) 고통을 유발하는 오랜 버그를 찾아내고, React로의 마이그레이션 과정으로 수정할 수 있었습니다. 지속적으로 문제를 일으키는 버그는 약 일 년 동안 지속되었으나, 찾아낼 수 없었고, 관련 구성 요소가 React로 마이그레이션될 때 비로소 수정되었습니다. 이것은 우리와 고객 지원 분야를 더욱 행복하게 만들었습니다! 다른 팀의 고통을 유발하는 버그를 고치며 이 일을 하는 이점을 뚜렷하게 보여주었고, 새로운 기능을 구축하는데 시간을 쓰지 못하는 이 결정이 왜 장기적으로는 유익한지 알려주었습니다.

우리가 많은 시간과 노력을 쏟은 커뮤니케이션 주제는 뭔가 이슈가 생겼을 때의 커뮤니케이션입니다. 긴 시간동안 복잡한 프로젝트를 마이그레이션하는 과정에서 버그는 발생할 것입니다.

View image on Twitter

이것이 모든 사람들을 좌절시켰지만, 자꾸 다운되는 사이트에 화가 난 고객들의 전화를 받는 서비스 팀은, 어느 누구보다 화가 날 것입니다. 우리가 문제를 발생시킬 때마다 우리는 내부를 돌이켜 보고 어떻게 일어난 이슈인지 논의했습니다. 우리는 다음의 것을 물어보았습니다.

  • 무엇이 잘못되었는가?
  • 왜 배포 전에 알지 못했는가?
  • 어떻게 수정해야 하는가?
  • 어떻게 다음에 이런 일이 재발하는 것을 막을 수 있을까?

중요한 것은 이것이 전적으로 누군가를 비난하는 일이 아니라는 것입니다. 실 서비스에 버그가 일어난다면, 그것은 코드를 쓴 한 사람의 잘못이 아니고 전체 팀의 잘못이었습니다. 버그는 테스트 간격이 적절한지 생각하게 하거나, 배포 이전에 수행되어야 했던 수동 테스팅이 필요함을 알려주었습니다. (특정 날짜 버그는 뉴욕 시간대에만 나타났으므로 런던 시간에서 그 버그를 추적하는 것은 어려웠습니다!)

그러면 여기서 배운 교훈은 플랫폼 문제를 심각하게 다루는 것 뿐만 아니라 같은 버그가 다시 일어나지 않도록 하기 위해 많은 시간과 노력을 들이고, 회사 전체와 소통하라는 것입니다.

Conclusions

요약하자면, 프로젝트를 마이그레이션 할 생각이 있다면 일곱 가지 점들을 염두해주길 바랍니다.

  1. 절대로 그냥 마이그레이션 하지 마세요. 우리의 동기가 단지 이 프로젝트가 Angular 1이었기 때문에 하는 것이었다면, 우린 절대 이 작업을 하지 않았을 것입니다. 우리를 마이그레이션하는 이유가 많이 있었습니다. 이 결정을 쉽게 보지 마세요!
  2. 계획하고, 계획하고, 다시 계획하세요. 우리는 물건을 분해하고 기능에 우선 순위를 매기기 위해 많은 시간을 화이트보드 앞에서 보냈습니다. 그 우선 순위를 차지한 일이 팀에게 보여지도록 하여 (우리는 Trello를 사용했습니다), 복잡하고 긴 프로젝트를 하면서 잘 일어나는 집중력 저하를 방지할 수 있었습니다.
  3. 다양한 이해관계자와의 커뮤니케이션은 필수적입니다.
  4. 우선순위는 어플리케이션이 지닌 현재의 단점에 맞추도록 합니다. 이는 개발팀 외의 회사 구성원들이 이 프로젝트를 긍정적으로 인지하도록 도와줄 수 있습니다.
  5. 모든 팀 멤버들에게 다양한 종류의 일을 동시에 진행하도록 하세요. 일이 덜 지루해집니다.
  6. 진행 상황을 보다 쉽게 파악하기 위해 마이그레이션의 (다소 대략적인) 측정 방법을 준비해두세요.
  7. 처음부터 완벽하게 마이그레잇 할 기대를 하지 마세요. 마이그레이션 후에도 리팩토링할 수 있습니다.

질문이 있다면, 답해 드릴게요! Twitter에서 저를 찾으셔도 좋고, GitHub 에서 질문하셔도 좋습니다.

Tags : javascript 

comments powered by Disqus