웹 개발 패러다임 변화
풀스택 개발자에 대한 부정적 이미지가 왜 생겼는지를 웹 개발 패러다임 변화로 설명한다. 과거 일체형 서비스에선 모두가 풀스택이었지만, 프런트·백 기술이 각각 심화되며 둘 다 깊이 있게 하기 어려워진 배경을 짚는다.
MVC·멀티페이지 방식에서 요구사항이 늘며 렌더링에 필요한 데이터가 많아지고, 액션마다 새로고침되는 성능 문제를 설명한다. 자바 개발자들이 JS를 잘 못해 코드 리뷰도 어렵고 아무도 만지기 싫어하는 코드가 된 상황을 든다.
필요한 정적 리소스를 최초 한 번 받고 이후 비동기로 데이터만 받는 SPA의 개념과, 복잡한 UI·동적 요소·로그인 필수 서비스에 적합함을 설명한다. 프런트 개발자·기획자·QA를 UI 개편이라는 명분으로 설득한 과정을 공유한다.
앵귤러·리액트·Vue의 특징을 비교하고, JS 숙련도가 낮은 팀에 러닝커브가 낮고 퍼블리셔와 마크업 협업이 쉬운 Vue.js를 선정한 이유를 든다. Webpack 설정과 ES6 문법 학습이라는 예상 밖 허들도 솔직히 공유한다.
스프링부트+Vue를 한 프로젝트로 메이븐 빌드하는 샘플을 따라 했다가, 프런트 배포에도 백엔드를 함께 빌드해야 하는 아쉬움을 겪는다. 결국 빌드·배포를 완전히 분리하고 웹서버가 UI 요청을, 백엔드가 API만 처리하도록 수정한 과정을 설명한다.
클라이언트 렌더링으로 바뀌며 백엔드의 VO 파싱 역할이 애매해진 문제를, 넷플릭스 Zuul API 게이트웨이로 푼다. 스프링부트 설정만으로 프록시를 구현하고 Zuul 필터로 헤더·파라미터를 처리해 불필요한 VO 클래스를 걷어낸 방법을 든다.
복잡한 컴포넌트 간 데이터 흐름을 상태관리 Vuex로 중앙 집중화하고, 디바운스·캐싱으로 API 호출을 줄인 팁을 공유한다. 다국어는 스프링 메시지 대신 별도 메시지 서비스를 만들어 빌드·배포 없이 실시간 문구 변경이 가능하도록 한 구성을 설명한다.
새로고침 감소로 API 호출과 페이지 속도가 개선되고, 프런트·백 분리 배포와 메시지 서비스로 배포 부담이 줄었음을 정리한다. ESLint·컴포넌트 재사용으로 코드 품질이 오르고, 풀스택 개발자를 제너럴리스트로 재정의하며 발표를 마무리한다.