기술 마이그레이션 전략에 대한 전체 가이드: (1부 – 소개)

게시 됨: 2020-12-23

새로운 기술이 나날이 발전함에 따라 오래된 기술은 쓸모가 없어지고 있습니다. 오늘날의 시장에서 살아남기 위해 모든 회사가 최신 정보를 유지하는 것이 필요하게 되었습니다. 사용자에게 다양한 서비스와 플랫폼을 제공하는 모든 회사는 매일 업그레이드되는 기술에 대처할 준비가 되어 있어야 합니다. 이러한 경우 마이그레이션이 그림으로 나타납니다. 회사는 항상 새롭고 더 나은 플랫폼으로 마이그레이션할 수 있습니다. 이제 마이그레이션이 무엇인지 생각할 수 있습니다. 대답은 짧고 동시에 약간 복잡합니다. 마이그레이션은 한 곳에서 다른 곳으로 마이그레이션하는 것을 의미하는 비기술적 머글에 대한 매우 간단한 용어입니다. 그러나 우리와 같은 기술 마법사에게는 약간 다른 의미가 있습니다. 따라서 첫 번째 단계를 수행하고 기술적인 용어로 마이그레이션을 이해해 보겠습니다. 마이그레이션은 현재 플랫폼에서 다른 플랫폼으로 이동하는 것을 의미합니다. 대부분의 경우 더 나은 작업 환경과 사용자 경험을 제공하기 때문에 더 나은 플랫폼으로 마이그레이션이 이루어집니다. 때로는 보안 문제로 인해 마이그레이션이 발생할 수도 있습니다. 마이그레이션에는 여러 유형이 있으며 다음은 가장 많이 논의되는 마이그레이션 주제 중 일부입니다.

기술 마이그레이션
프런트 엔드 기술 마이그레이션
백엔드 기술 마이그레이션
CMS 구축 웹사이트 마이그레이션
데이터베이스 마이그레이션
도메인 및 호스팅 서버 마이그레이션

기술적인 측면에서 마이그레이션은 상상할 수 있는 것보다 훨씬 더 광범위한 주제입니다. 모든 마이그레이션 주제와 유형을 하나의 블로그로 다루는 것은 다소 어렵습니다. 따라서 이 주제는 유형과 함께 마이그레이션의 중요성을 설명하는 여러 부분으로 나뉩니다. 다음 블로그에서 읽을 수 있습니다.

마이그레이션은 중요한 작업이며 마이그레이션 시기, 마이그레이션 방법, 마이그레이션 범위 정의 등과 같은 질문이 귀찮다면 이 블로그를 계속 읽으면서 마음을 비울 수 있습니다.

마이그레이션이 필요한 이유는 무엇입니까?

오랫동안 일해 온 현재 기술이 더 이상 비즈니스 요구 사항의 기대치를 충족할 수 없을 때.
기술이 구식이고 구식 버전에 대한 공급업체 지원도 사용할 수 없는 경우.
당신의 고객이 당신에게 중요하고 당신이 당신의 분야에서 최고가 되어야 할 때.
오픈 소스 플랫폼으로 전환하여 현재 스택의 막대한 라이선스 비용을 더 이상 원하지 않을 때.

그 때 마이그레이션이 최선의 선택이 될 것입니다. 마이그레이션은 복잡한 프로세스이며 많은 계획이 필요합니다.

마이그레이션 프로세스의 첫 번째 단계는 마이그레이션 프로세스를 원활하게 수행할 수 있는 몇 가지 정의와 기본 규칙을 설정하는 것입니다. 프로젝트 요구 사항에 따라:

먼저 마이그레이션해야 하는 프로젝트 또는 애플리케이션의 현재 상태를 분석해야 합니다.
마이그레이션 중에 발생할 수 있는 계산된 위험 및 가능한 솔루션의 로드맵을 준비합니다.
프로젝트의 모든 요구 사항을 충족하는 적절한 기술을 선택해야 합니다.
다음으로 마이그레이션 프로세스를 실행하기 위한 적절한 계획이 필요합니다.
마지막으로 마이그레이션 프로세스가 완료되면 애플리케이션이 새 플랫폼에서 예상대로 작동하는지 확인합니다.

마이그레이션 계획 단계를 진행하기 전에 염두에 두어야 할 몇 가지 사항이 있습니다.

비즈니스 문제에 따라 마이그레이션 계획 단계 전에 프로젝트 예산과 일정을 결정합니다.
기존 시스템에서 새 시스템으로 마이그레이션하려는 새 클라이언트에 대해 시간당 요금 또는 주간 요금 설정과 같은 작업 모델을 결정합니다. 향후 블로그 시리즈에서 논의할 몇 가지 회색 영역이 있으며 이는 새로운 개발 팀이 작업을 시작할 때만 발생할 수 있습니다. 마이그레이션은 새 팀에 대한 고정 추정 작업으로 처리할 수 없습니다.
클라이언트가 기술 전문가가 아닌 경우 마이그레이션 계획 단계 전에 마이그레이션 범위를 명시한 계약서에 서명하는 것이 좋습니다. 그렇지 않으면 클라이언트가 개발 팀과 연락할 수 있는 계약 프로젝트 관리자를 고용할 수도 있습니다.

마이그레이션 범위 정의

현재 시스템을 알지 못하는 마이그레이션 프로젝트에서 작업하는 모든 개발자 팀의 경우 클라이언트는 팀이 시스템의 흐름을 이해하는지 확인하기 위해 새 팀과 시간을 보내야 합니다. 새 팀은 기존 시스템을 분석하고 마이그레이션 계획을 세우는 데 충분한 시간이 필요합니다. 한편, 클라이언트는 항상 현재 시스템에서 직면하고 있는 비즈니스 문제를 제기할 수 있습니다.

프로젝트 범위를 정의하려면 클라이언트가 마이그레이션을 성공적으로 완료하기 위해 세부 프로젝트 요구 사항을 공유해야 합니다. 개발자와 클라이언트는 마이그레이션 계획과 동일한 페이지에 있어야 하며 모든 미래 문제로부터 보호하기 위해 마이그레이션의 모든 측면에 대해 적절한 논의가 있어야 합니다.

때로는 개발 팀이 백엔드 기술에 매핑된 비즈니스 로직에 대한 자세한 문서를 작성하지 않을 수 있습니다. 동일한 팀에서 마이그레이션을 수행하면 큰 문제가 발생하지 않지만 새 팀에서 마이그레이션을 수행할 때는 문서가 정말 중요합니다. 따라서 비즈니스 로직에 대한 자세한 문서를 보유하는 것이 좋습니다.

범위 문서에 원래 범위를 벗어난 모든 작업은 추가 작업으로 간주되며 원래 예산을 포함한 프리미엄 요금이 부과된다는 점을 명확하게 명시해야 합니다. 이는 향후 발생할 수 있는 스코프 크립을 방지하는 데 도움이 됩니다.

스코프 크립에 대처하는 방법은 무엇입니까?

Scope Creep의 처리를 이해하기 전에 Scope Creep이라는 용어와 이것이 개발 팀에 미치는 영향에 대해 설명하겠습니다. Scope Creep은 일정의 연장이나 프로젝트 예산의 증가 없이 프로젝트에 도입되고 있는 기술 요구 사항을 변경한 결과입니다.

스코프 크립이 발생하는 많은 이유가 있으며 프로젝트 마이그레이션에서 이러한 크립을 피하기 위해 매우 일반적인 이유 중 일부가 아래에 나열되어 있습니다.

프로젝트 요구 사항을 잘못 이해하는 것은 마이그레이션의 나중 단계에서 개발자에게 문제를 일으키는 범위 크리프 뒤에 있는 가장 일반적인 이유 중 하나입니다.
최종 사용자의 잦은 피드백과 같은 함정을 피하십시오. 모든 피드백 포인트를 즐겁게 하는 포인트는 없습니다. 하지만 피드백을 전혀 받지 않는 것은 아닙니다. 가장 반복적이고 눈에 띄는 것만 선택하십시오.
모든 변경 요청에 동의하는 것은 처음에는 긍정적인 관계를 구축하는 데 도움이 될 수 있지만 결국 프로젝트에 대한 클라이언트의 불만으로 끝날 것입니다. 따라서 피드백이나 변경 요청에 동의하기 전에 우선 순위와 긴급성을 확인하고 최종 고객에게 노력에 미치는 영향에 대해 알립니다.
기존 기술에 추가된 새로운 기능, 시장의 경제적 변화, 개인 비상 사태 등 프로젝트 범위에 영향을 미치는 수많은 다른 요인이 있으므로 이러한 가능성에 대비하는 것이 좋습니다.

이제 Scope Creep이라는 용어를 이해하고 가능한 원인을 알았으므로 예방 계획이 마이그레이션 프로젝트 범위의 크립을 방지하는 가장 좋은 방법이라는 것이 분명합니다. 모든 계획에 관계없이 프로젝트 요구 사항의 기능 변경에 대한 모든 향후 요청을 정확하게 가정할 수 있는 방법은 없습니다. 이럴 때 마이그레이션 범위에 대한 문서가 도움이 될 수 있습니다.

기술 스택 선택

개발자로서 여러분 앞에는 MongoDB에서 MySQL로, AngularJS에서 React로, MEAN 스택에서 LAMP 스택으로, Amazon AWS와 같은 클라우드 호스팅 서버에서 Apache와 같은 자체 호스팅 서버와 같은 많은 옵션이 있습니다. 이러한 옵션은 누구에게나 혼란을 줄 수 있습니다. 따라서 마이그레이션을 위해 계획된 기술 스택을 선택하는 것은 개발자의 책임입니다. 미래의 모든 요구 사항에도 대비해야 합니다.

마이그레이션 플랫폼을 선택하고 새로운 플랫폼에 대한 요구 사항을 명확하게 이해하지 못하는 경우 복잡한 시스템에서 작업한 경험이 있는 Solution Architect를 고용할 수 있는 옵션이 있습니다. 이상적으로는 제3자 컨설팅이 되어 클라이언트가 스스로 솔루션 설계자를 고용하거나 개발 회사에 비용을 지불할 수 있습니다. 이것은 마이그레이션 단계를 계획하기 전에 수행해야 하는 작업에 대해 협상하고 합의해야 합니다.

새 플랫폼의 기능이 시도되고 테스트되었는지 확인해야 합니다. 확실히, 당신은 새로운 플랫폼의 단점과 함정에 대해 가장 먼저 알고 싶지 않을 것입니다. 모든 데이터가 안전하게 보존되고 다른 기능은 새 플랫폼으로 마이그레이션한 후 많은 수정이 필요하지 않은지 확인해야 합니다. 마이그레이션은 복잡한 프로세스이지만 올바르게 수행되면 구식 기술에 새로운 시작을 제공할 수 있습니다.

현재 시스템에 DevOps가 있는지 여부를 확인하십시오. DevOps는 시스템 개발 수명 주기를 단축하고 지속적인 제공을 제공합니다. 현재 시스템에서 이미 이러한 도구를 사용하고 있는 경우 업그레이드된 버전으로 이동하거나 계속 사용할 수 있습니다. 일종의 CI/CD 도구를 사용하면 개발자가 마이그레이션 프로세스를 조금 더 쉽고 체계적으로 수행할 수 있으므로 항상 사용하는 것이 좋습니다. 또한 개발 팀은 엄격한 코드 검토 및 코드 푸시 접근 방식을 따라야 합니다. GitFlow 모델 또는 GitHubFlow.

프로젝트의 요구 사항, 마이그레이션 범위 및 기술 스택을 파악한 후에는 플랫폼에 더 나은 대체품을 쉽게 선택할 수 있습니다. 다양한 유형의 마이그레이션이 있으며 진행하기 전에 모든 마이그레이션이 동일하지 않으며 각 마이그레이션에는 적절한 계획과 실행이 필요하다는 점을 분명히 하고 싶습니다. 마이그레이션 및 그 유형은 훨씬 더 광범위한 주제이므로 이 블로그에서 계속해서 각 마이그레이션에 대한 자세한 정보를 얻을 수 있는 3개의 다른 부분이 있습니다. 다음 블로그에서는 기술 마이그레이션 유형에 대해 이야기할 예정입니다. 계속 지켜봐 주세요!