규모가 큰 서비스라 하셨으니, 이슈가 크겠네요. 아키텍처 변경이 아마 타팀에도 영향을 미칠거구요. 상위 담당이나 본부 소속으로 아키텍처팀이 따로 존재한다면, 거시적인 시점의 아키텍처 검토를 받으시
규모가 큰 서비스라 하셨으니, 이슈가 크겠네요. 아키텍처 변경이 아마 타팀에도 영향을 미칠거구요. 상위 담당이나 본부 소속으로 아키텍처팀이 따로 존재한다면, 거시적인 시점의 아키텍처 검토를 받으시는게 좋긴 할 것 같은데요. 제 의견을 말씀드려 보자면, (1) 장애/이슈 포인트에 해당되는 부분만 리팩토링하거나, (2) 아키텍처를 새 판으로 짜야 한다면, 대규모 프로젝트가 될테니 비즈니스와 기능을 잘게 쪼개어 리스트업 한뒤, 레거시 테스트케이스를 재점검 합니다. (3) 배포 방식을 정합니다. 빅뱅으로 할지, 순차적으로 할지, 순차적으로 한다면 우선순위를 결정합니다. 반드시 배포 이후 안정화 기간의 공수까지 그 중요성을 잘 설득하셔서 예산으로 잡아야 합니다.