이유

1. 디렉토리 관리가 힘들다.
   어떤 부분은 컨셉자체가 완전히 달라서 디렉토리 구조가 특별해질 이유가 있음에도
   기존 프로젝트의 디렉토리 철학에 끼워 맞춰야 하기때문에 구조가 이상해지는 경향이 있다.

2. 회사 내부 플랫폼이 여러개인데 덩치가 좀 큰편이라 매번 이슈 핸들링할때마다 찾아가는 작업이 힘들다.

3. 번들링 속도가 느리다.

4. 빌드 속도가 느리다.

5. 특정 부분의 이슈때문에 프로젝트 전체가 뻑나는 경우가 있다.

6. react의 atomic Design철학을 적용하기에 적합하다.

7. 상기내용을 근거로 프로젝트를 분산하여 관리할 필요를 느꼈다.

(암튼 프로젝트 유지보수가 넘 어렵다는 내용임)

장점

이유에 나열돼있는 부분이 해결되는것이 장점이다.

단점

1. 역공학을 많이해야한다.

2. 하는김에 부분적인 리팩토링도 같이 들어가기때문에 시간적인 투자가 많이 들어간다.

3. 역공학하여 프로젝트의 이해도가 어느정도 수치가 도달해야지 진행이 가능하다.

4. 나뉘어진 프로젝트를 다시 병합하는 과정이 조금 까다롭다.

5. 각 프로젝트들이 서로 유기적으로 잘 상호작용하는지 즉시 확인이 어렵다.

6. 구축을 시작할때 테스트에 소모되는 비용이 크다.

7. 위 말한내용 말고도 더 많지만 간단하게 말하면 시간적인 자원소모가 꽤 있다.

후기

• 현재는 MSA적용 과정을 끝내고 부분 최적화를 들어갈 예정이다.(따로 또 작성할 것임)

• 한번 적용해두니 유의미하게 프로젝트 유지보수가 쉬워졌다는 장점이 있다.

• 다만 기존 프로젝트를 새로운 구조로 이전하는 작업이다보니 회사 내부의 고인물?들의 불만이 있다. (어디 어디에 어떤내용이 딱 있었는데 그런 구조가 많이 변경되다보니)

• 비 정상적인 구조를 정상화 시킬수 있기때문에 적용을 안할 이유가 없다.

• 따라서 이번처럼 프로젝트를 나누고 최적화 진행도 같이해주면 이것은 눈에 보이는 작업이다보니 마치 MSA를 적용했기때문에 성능이 향상됐다는 느낌을 줄 수도있다.

• 다만 나를 고용하는 회사 입장에선 지금도 잘 돌아가고있는 프로젝트를 굳이 왜 이런식으로 관리해야하는지에대한 납득이 필요하다.

• 시간 투자라는것은 비용으로 연결되기때문에 날 고용한 분들은 본인의 입장에서 더욱 생산적인 곳에 나를 사용하고 싶어하는것은 당연하다

• 회사 업무를 진행할때 엔지니어의 입장에서 정말 꼭 필요한내용이지만 실질적으로 당장 눈에 보이지 않는경우 달달한 무언가를 같이 끼워서 진행해주면 성과로도 인정받고 프로젝트를 향상시킬수도 있다.(중요함)