평소에 피처 토글과 어떠한 관점에서 서비스를 분리해야 할지에 대해서 관심이 많았었는데
마침 에스씨지랩개발팀과 한빛앤에서 작은 서비스 조금씩 개선하기라는 주제로 세미나를 열어 참여하게 되었습니다.
규모가 커지면서 발생하기 시작한 모놀리식 배포 문제 (최범균)
첫번째 세션은 왜 서비스를 분리하게 되었고 어떠한 기준으로 분리를 진행했는지에 대한 설명을 진행하였습니다.
서비스가 커지면서 동시진행업무 증가 -> 생명주기가 긴 브랜치가 많아짐 -> 배포를 위한 머지가 수고스러움
이에 따라 결국 서비스 출시 속도가 느려졌고 이때문에 서비스 분리를 결정하게 되었음을 설명해 주셨습니다.
이때, 분리 대상은 코어 한 부분이 아닌 연관이 적은 작은 규모의 분리부터 시작하여 진행을 진행을 했다고 합니다.
분리를 진행하고 나서 에스씨지랩에서 얻은 효과는 제가 정리했을 때는 아래와 같습니다.
- 생각보다 분리 비용이 적음 (분리 비용 + 추가 비용 < 기존코드에 추가하는 비용) -> 비즈니스에 빠른 대응
- 비지니스 개발만 하던 개발자의 지루함을 달램 -> 개발자로서의 역량 성장
프런트엔드 : 마이크로 프론트엔드 적용 (임관우)
다음세션은 프론트엔드 진형에서 Webpack의 Module Federation을 통해서 마이크로 프런트엔드를 구성하는 방법에 대해서 설명해 주셨습니다.
프런트엔드에 Webpack 기술을 정확하게 인지하지는 못해서 상세한 내용은 이해하기 어려웠지만 위의 장표처럼 분리를 진행하였고 인상 깊었던 점은 SWOT 분석을 통해 해당 기술을 적용할 때 어떤 부분을 고려할지에 대해서 정리하고 도입하셨던 점이 인상이 깊었습니다.
다음에 어떠한 기술을 선택할 때 한번 분석을 통해 관리자를 설득할 때 사용해 보면 좋을 거 같다는 생각이 들었습니다.
피처 토글 적용 (박정우)
코드를 수정하지 않고 특정분기를 통해 시스템 동작을 바꾸는 개념인 피처토글을 에쓰씨지랩에서는 어떤 식으로 구현을 했을까에 대해서 궁금했었는데 오픈소스나 서드파티툴을 조합해서 사용한 건가?라고 생각을 했었는데
해당 명확한 요구사항을 사전에 정의하고 토글을 Spring 기술을 통해 직접 구현을 했다는 점에서 인상 깊었습니다.
피처 토글을 적용은 적용인데 적용 후에 운영단계에서 어떻게 무분별한 피처토글을 관리할까에 대해서 혼자 생각했었는데
마침, 설명해 주셨던 부분 중 삭제에 계획을 미리 계획 세운다. (백로그 - 티켓 생성)을 통해 관리를 진행한다고 하신 부분에 공감을 얻었습니다.
작은 서비스 조금씩 개선하기 - 마무리
작은 서비스 조금씩 개선하기의 주의사항을 설명해 주셨습니다.
- 기술 개선 사업은 결과로 보여주기 (조용히 진행)
- 서비스 운영에 구멍 내지 않기 (신뢰중요)
- 복잡하게 시작하지 않기 (팀이 감당할 수 있는 수준 )
- 중요하지 않은 일에 힘 빼지 않기 (여유 만들기)
- 꾸준히 개선하기
후기
처음에는 범균 님을 만난다는 생각에 덜컥 신청을 했었는데 생각지도 못한 좋은 인사이트를 얻은 것 같았습니다.
서비스를 분리할 때 어떤 전략을 취할까? 에 대해 고민이 있었는데 전략에 대해서도 얻은 것도 있고 "서비스 개선 사업의 사회생활팁"?을 얻었습니다.
그리고, 당연스럽게 서비스가 분리되면서 오랜 기간을 유지하던 피처 브랜치에 대한 해소에 일 부분으로 브랜치 전략이 변경되었을 거 같다는 생각에 질문을 드렸었는데, 오히려 범균 님께서는 브랜치 전략을 사용하고 있지 않고 trunk기반의 개발을 진행한다고 하셔서 내용을 들어보니 main브랜치에 그때그때 머지되어서 나갔으면 좋겠다는 말에 공감이 되었고 trunk기반의 개발 브랜치가 변화 이후에 되었던 건
아마도 피처 토글에 시너지 효과를 통해서 가능하지 않았을까? 하는 생각이 들었습니다.
한편으로는 세션을 듣고 자신에 대한 회고의 일환으로
피처토글에 서드파티를 이용해서 적용했나? 브랜치 전략이 바뀐 건가?라고 단편적인 생각을 했었는데 피처토글을 직접 구현을 하기도 하고 깃플로우 같은 브랜치 전략을 안 쓰는 모습을 보고 너무 내가 고정관념에 억메어 있나?라고 반성이 되었습니다
범균 님의 사인
