1. 소개
DevOps 라는 분야를 들어본적이 있을 것이다. DevOps는 개발(Dev)과 운영(Ops)의 결합을 통해 소프트웨어 개발 생명주기 전반에 걸쳐 효율성과 품질을 향상시키는 방법론과 도구 집합을 의미한다. 이는 지속적인 통합(Continuous Integration), 지속적인 배포(Continuous Deployment), 자동화된 테스트, 인프라스트럭처 코드화(Infrastructure as Code), 모니터링 및 로깅 등 다양한 관행과 도구를 포함한다. 이러한 방법론이 최근 Front-end 개발자에게도 요구되기 시작했다.
현대의 웹과 애플리케이션 개발 환경은 빠른 기술 변화와 다양한 요구 사항이 빠르게 변화하는 특성을 가지고 있다. 이러한 환경에서 프론트엔드 개발자들은 사용자 인터페이스의 품질과 상호 작용을 최전방에서 수행하며 그 역할이 중요해지고 있다. 사용자 경험을 최적화하고, 애플리케이션의 성능을 개선하며, 어플리케이션의 안정성을 지키는 것은 이제 당연한 요구 사항이다. 이러한 요구 사항을 충족시키기 위해 프론트엔드 개발자들은 단순한 코드 작성을 넘어서, 소프트웨어 개발과 운영의 전 과정에 걸쳐 효율성과 품질을 향상시키는 DevOps의 기술과 원칙을 이해하고 적용할 필요가 있다.
특히 최근에는 프론트엔드 웹 애플리케이션의 규모가 커지고 아키텍처의 복잡성이 증가함에 따라, 이러한 접근 방식은 개발 과정의 효율성과 제품의 품질을 향상시키는 데 필수적인 역할을 한다. 해외에서는 이미 위와 같이 Frontend DevOps라는 용어가 등장하기 시작했고, 국내에서도 토스, 우아한형제들 등에서 Frontend DevOps 의 필요성을 느끼고 채용함을 알 수 있다.
2. 본론
그렇다면 구체적으로 Frontend-DevOps 는 어쩌다 필요하게 되었고, 어떤 일을 해야하는 것일까. 왜 필요한지를 기준으로 크게 3가지로 나누어 보았다.
첫째, 프론트엔드 애플리케이션의 규모 증가. 모던 FE 개발자라면 프론트엔드 규모가 커졌다는 것에 모두 동의할 것이다. 다양한 인터랙션과 역할이 FE로 넘어왔고, SSR의 등장으로 서버자원까지 관리하게 되었다.
둘째, 아키텍처의 복잡성 증가. 규모가 커짐에 따라 프론트엔드에도 다양한 아키텍처가 등장하기 시작하였고, 대표적으로 MFA(마이크로 프론트엔드 아키텍처)가 큰 인기를 끌고 있다. 이러한 과정에서 자연스럽게 DevOps 방법론이 필요하게 되었다.
셋째, 효율적인 프로젝트 관리. 서비스 규모가 커지면서 패키지 의존성도 복잡해졌고, NPM과 같은 패키지 매니저에 대한 이해도가 중요해졌다. 게다가 테스트하고, 빌드하고 배포하는 과정도 커지고 복잡해지면서 이러한 CI/CD 과정에 대한 이해도도 중요하다. 아래에서 각각에 대해 자세히 알아보자.
* 애플리케이션의 규모 증가
모듈화와 컴포넌트 기반 개발 : 현대의 프론트엔드 개발은 재사용 가능한 컴포넌트와 모듈화된 아키텍처를 지향한다. 이러한 접근 방식은 애플리케이션의 확장성과 유지 관리를 용이하게 하지만, 동시에 의존성 관리와 버전 관리의 복잡성을 증가시켰다.
성능 최적화 : 대규모 프론트엔드 애플리케이션에서는 페이지 로딩 시간과 인터랙티브성이 사용자 경험에 큰 영향을 미칩니다. DevOps 방법론은 성능 모니터링, 자동화된 테스트, 자원 최적화를 통해 이러한 요구 사항을 충족시키는 데 필수적이다.
Server Side 로직 : SSR 기술의 활용으로 초기 페이지 로딩 속도 개선과 SEO 최적화에 큰 이점을 제공하게 되었으나 이에 따라 서버사이드에 대한 이해도가 필요하다. Next.js 같은 프레임워크를 통한 SSR 구현은 프론트엔드 개발자에게 서버 측 로직과 환경 설정에 대한 이해를 요구하며, DevOps 지식은 이러한 서버 관리 작업을 자동화하고 최적화하는 데 도움을 준다.
* 아키텍처의 복잡성 증가
마이크로프론트엔드 아키텍처 : 복잡한 웹 애플리케이션을 관리하기 위해 마이크로프론트엔드 아키텍처가 점점 더 인기를 얻고 있다. 마이크로프론트엔드 아키텍처를 적용하면, 각 팀이 독립적으로 기능을 개발하고 배포할 수 있어 프로젝트의 유연성이 크게 향상된다. 이러한 접근 방식은 전체 시스템의 안정성을 유지하면서도 개별 서비스의 신속한 업데이트를 가능하게 한다. 하지만 분리되는 만큼 많은 서비스 앱이 생기게되고, 관리의 복잡성과 서비스 간의 통일성 이슈가 생기기 마련이다. DevOps는 이러한 아키텍처에서 서비스 간의 통일성을 보장하며, 애플리케이션의 지속 가능한 성장을 지원할 수 있다. 게다가 복잡성이 높아질 수록 MFA내의 통합은 매우 중요한 과제이다. kubernetes, API 게이트웨이나 서비스 메시 같은 도구를 통해 서비스 간의 통신을 관리하고,여러 마이크로프론트엔드 간의 조화로운 작업 흐름을 보장해야 한다.
클라우드 기반 개발 환경 : 모던 개발 환경에서 클라우드 서비스는 필수가 되었다. 클라우드 서비스의 사용 증가는 개발과 운영의 유연성을 대폭 향상시켰지만 프론트엔드 개발자와는 거리가 있는 것처럼 느껴졌다. 그러나 모던 프론트엔드 개발자는 클라우드 리소스 관리, 비용 최적화, 보안 설정 등에 대한 이해를 바탕으로 애플리케이션을 개발, 테스트하고 배포할 수 있다. 추가적으로 서버리스 컴퓨팅과 같은 클라우드 기반 서비스의 활용은 프론트엔드 개발에서도 중요한 역할을 차지하고 있다. 이러한 기술 도입은 배포, 스케일링, 운영을 단순화하지만, 동시에 새로운 보안, 네트워크, 데이터 관리 측면의 고려 사항을 갖게 되었다. 프론트엔드 개발자가 DevOps 원칙을 적용함으로써, 이러한 새로운 기술 환경에서도 애플리케이션의 안정성과 성능을 최적화할 수 있다.
* 효율적인 프로젝트 관리
패키지 의존성의 효율적 관리: 프론트엔드 프로젝트의 규모가 커짐에 따라, NPM 같은 패키지 매니저를 통한 의존성 관리의 중요성이 커지고 있다. 특히 의존성이 많은 대규모 프로젝트에서는 패키지 버전의 일관성 유지와 보안 취약점의 신속한 해결이 필수적이다. DevOps 접근 방식을 통해, 의존성 관리를 자동화하고, 패키지 업데이트를 지속적으로 모니터링함으로써, 프로젝트의 안정성을 유지할 수 있다.
지속적인 통합과 배포에서의 패키지 관리 : CI/CD 파이프라인 구축 시, 패키지 매니저를 통한 의존성 관리는 자동화된 빌드와 테스트 과정에서 중추적인 역할을 한다. 이는 개발자가 코드를 커밋할 때마다 자동으로 의존성을 설치하고, 애플리케이션을 빌드, 테스트하는 과정을 포함한다. 이 과정에서 패키지 매니저의 활용과 이해는 프로젝트의 배포 속도를 향상시키고, 배포 과정에서의 오류를 최소화하는 데 기여한다. 이를 통해 새로운 기능을 더 빠르게 시장에 출시할 수 있게 도와준다.
3. 사례
위의 내용만 봐서는 사실 크게 와닿지 않을 수도 있다. 그래서 필자의 경험과 주변의 사례를 토대로 가상사례를 만들어봤다. 실제로는 더 복잡하고 다양한 이해관계가 얽혀있지만 최대한 간단하게 풀어보았다.
* CICD 속도 개선
X팀은 고객의 피드백을 빠르게 반영하고 서비스를 개선시키기 위해 에자일하게 서비스를 운영하고 있다. 최근 서비스가 커지면서 빌드와 배포시간이 10분이상 걸리는 것을 확인하였다. 이에 따라 기다려야하는 시간이 생기고, 문제가 생기면 다시 처음부터 빌드해야하므로 불편함이 늘게되었다. X팀은 인프라팀과 DevOps 팀에 연락하였다. 인프라팀은 네트워크 속도를 개선시켜 주었고, DevOps팀은 도커 캐싱을 좀 더 효율적으로 동작하도록 수정해주었다. 결과적으로 CICD 속도는 10분내로 줄어들 수 있었다. 하지만 여전히 불편하여 개선을 하기로 하였다. 어떻게 개선할 수 있을까. 먼저 npm으로 되어 있던 패키지 매니저를 pnpm으로 바꾸어 의존성을 좀 더 효율적으로 관리하고 설치할 수 있게하였다. 그리고 프로젝트에 트리쉐이킹과 코드 스플리팅 등을 적용하여 청크파일을 최소화하였다. 결과적으로 패키지 설치 시간, 빌드시간이 감소하였다. 게다가 가벼워진 서비스는 배포되는 시간도 감소하게 되었다. 이를 통해 5분 이내의 CICD를 이룰 수 있게 되었다.
* 서비스 장애 해결
Y팀의 서비스는 kubernetes 환경에 배포되어있다. Next.js로된 서비스의 안정적인 운영을 위해 파드를 3개띄워두었고, 센트리를 통해 지속적으로 로깅 및 모니터링을 하고 있다. 하지만 최근 간헐적으로 서비스에 접근이 안된다는 CS를 받았다. 직접 서비스에 들어가보니 10번중 1번 정도로 접속이 안되고 있었다. 하지만 센트리에는 아무런 로그가 남지 않았다. Y팀은 서비스 코드 내에서 오류를 찾아보다가 DevOps팀에 도움을 요청하였다. DevOps팀은 곧바로 클러스터를 확인해보았고, 파드 3개중 1개에 문제가 있음을 발견하여 다시 파드를 띄워 해결하였다. 하지만 이미 오류가 발생한지 1시간 이상이 되어 CS가 쌓여있었다. 만약 Y팀이 센트리에 로그가 없는 것을 보고 곧바로 직접 클러스터에서 파드를 내렸다면 단순한 헤프닝정도로 넘어갔을 것이다.
* 효율적인 협업
Z팀은 10개의 서비스를 운영하고 있다. 각 서비스는 동일한 곳에서 제공된다는 UIUX를 주기위해 일관성을 갖고 있다. 하지만 팀이 커지고 각 서비스가 점점 커지면서 협업이 어려워졌다. 이에 따라 Z팀은 모노레포를 도입하기로 하였다. 하나의 레포 내에 있게되자 팀원들간의 일관성이 지켜지기 쉬워졌고, 공통적인 패키지는 함께 관리할 수 있게 되었다. 그럼에도 큰 규모의 서비스 내에서 통일성을 지키는 것은 쉽지 않았다. 그래서 MFA(Micro Front-end Architecture) 를 도입하여 공통부분을 별도 앱으로 분리하였고, BFF를 도입하여 API도 통합 관리가 되는 부분은 분리하거나 캐싱되도록 하였다. 결과적으로 10개의 서비스는 육안으로 보기에는 하나의 서비스로 느껴졌고, 각각의 서비스는 손쉽게 별도로 배포할 수 있게 되었다.
4. 결론
여기까지 읽었다면 Frontend-DevOps 가 어떤 새로운 분야나 직무를 말하는 것이 아니라는 것을 느꼈을 것이다. 프론트엔드 개발자가 DevOps에 직접 참여함으로써 얻을 수 있는 이점은 단순히 기술적인 부분에 그치지 않는다. 이는 팀 간의 소통을 개선하고, 작업 흐름을 최적화하며, 프로젝트의 전반적인 품질과 배포 속도를 향상시킬 수 있다. 이는 프로젝트의 성공적인 완성과 시장 출시 속도를 결정짓는 핵심 요소이다.
프론트엔드 개발자가 DevOps 기술과 원칙을 적극적으로 받아들이고, 의존성 관리, 모니터링, CICD 등의 DevOps 관련 작업에 참여함으로써, 더 빠르고 안정적인 웹 애플리케이션 개발이 가능해진다. 결과적으로 프론트엔드 개발자는 코드를 작성하고 UI/UX를 디자인하는 것 이상의 역할을 수행하며, DevOps 영역에서의 적극적인 참여를 통해 전체 소프트웨어 개발 및 배포 프로세스의 효율성과 안정성을 높이는 데 기여할 수 있다. 이를 통해 최종 사용자에게 더 나은 제품을 제공할 수 있다.
'Client > Front-end' 카테고리의 다른 글
| <BFF> BFF 개발 시의 고려요소 (4) | 2023.06.09 |
|---|---|
| <BFF> BFF에 대한 이해와 구현 (0) | 2023.06.02 |
| <FE> 프론트 엔드의 테스트 (with. Jest, testing-library) (4) | 2022.03.09 |
| <FE> React-Query 의 필요성 (0) | 2022.02.16 |
| <FE> 프론트 관점에서 맛보는 GraphQL (0) | 2022.02.05 |
