일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- vscode
- styling
- styled-components
- Swift
- nextJS
- viewcontroller
- REACT
- npm
- HTML
- Branch
- js
- currying
- React Native
- ios
- JavaScript
- DevOps
- xtring.log
- shortcut
- Docker
- react-native
- ES6
- commit
- GitLab
- github
- npm install
- git
- rn
- Android
- ReactNative
- Xcode
- Today
- Total
xtring.dev
[dev.log] 프론트엔드팀이 '리눅스 커널'이 주제로 스터디를 하게된 이야기 본문
소개
제가 속한 프런트엔드팀에서는 필요한 기술 스택이거나 함께 공부할 주제를 정해 주 1회 스터디를 진행하고 있습니다. 6~8명이 1년 넘게 운영해 오면서 다양한 책들을 함께 읽으며 토론했습니다. 주된 관심사는 대부분 프런트엔드 기술과 직간접적으로 연관 있는 내용들이었습니다. 이번엔 새로운 스터디를 시작하기 전에 종종 추천 책으로 나오던 리눅스 커널이 주제인 책이 선정되었습니다. 어찌 보면 프런트엔드와는 직접적으로 관련이 없는 주제가 어떻게 프런트엔드 팀의 스터디 주제가 되었을까요?
이 주제를 선정하게된 이유
최근 프론트엔드 진영에서는 React와 Next.js를 기반으로 웹 기술이 활성화되고 있습니다. 그리고 우리는 이 라이브러리와 프레임워크를 가지고 SPA, SSR, SSG, ISR 등 다양한 렌더링 방식으로 웹 사이트를 구성하는데요. 페이지를 어떻게 보여주고 어떤 전략을 가져가냐에 따라 우리는 여러 방식 중 1+a를 적용하곤 합니다. 그리고 Next.js의 SSR(Server Side Rendering) 메서드를 통해 간편하게 구현하여 성능과 간편함을 한 번에 가져갈 수 있어 최근 많은 팀에서 적용하곤 합니다. 프런트엔드 팀의 스터디 주제가 '리눅스 커널'이 된 이유는 여기에 있기도 합니다.
*SSR에 대해서는 요즘 많은 분들이 소개하여 이 글에서는 다루지 않겠습니다.
3~5년 이내 유행했던 JAM Stack에 대해서 들어보셨을까요? JAM Stack은 JavaScript, API, Markup 기술로 웹 서비스를 구현하는 Stack이라는 의미인데요. 이 기술의 Stack을 통해 정적 파일을 CDN을 통해 제공하고 서버의 부하를 줄이며, 서버 로직과 프론트엔드 로직을 분리하여 보안에도 강점을 가지고 있습니다. 또 서버리스 아키텍처를 통해 확장성도 가지고 있지요. 그러나 개발팀이 비즈니스를 고도화하며 마주하는 여러 구현 사항을 적용하다보면 꼭 한가지 아키텍처나 패턴만을 사용할 수 없습니다. 따라서 아키텍처는 계속해서 변하고 진화하게 되는데 JAM Stack으로 유행했던 방식에서 요즘에는 Server Side Rendering(이하 SSR)을 통해 페이지를 렌더링하는 전략을 많이 가는 것 같습니다.
SSR은 제가 사용하고 있는 Next.js를 기준으로 Next Node 서버에서 HTML + CSS + JS를 다른 서버 API의 데이터를 하나로 Document로 만들어 클라이언트에게 전달하는 방식입니다. 즉 SSR을 하게 되면 우리의 서버 컴퓨터가 그만큼 일을 더 많이 해야한다는 말입니다. 우리는 SSR을 적용하고 운영하게 되면서 Node 서버 리소스를 직접 모니터링하고 관리하게 됐습니다.
일반적으로 클라우드 환경에서 서비스를 다루는 백엔드 개발자의 경우 이런 과정과 환경이 익숙할테지만 프런트엔드 개발자 입장에서는 이러한 부분이 처음엔 쉽지 않습니다. 즉, 프런트엔드 개발자도 단순히 UI 만들고 배포하고 하는 것만이 아닌 만들어진 애플리케이션의 상태를 보고 보완하고 대비할 수 있어야 한다는 말입니다. 애플리케이션의 상태와 성능을 확인하고 리소스의 확장과 보안에 대해서도 신경 쓸 수 있어야 하는데 여기에 필요한 것이 리눅스를 잘 알고 있다면 많은 것들을 해결할 수 있습니다.
프런트엔드 개발자가 리눅스 커널에 대해 알고 있으면 좋은 이유
프런트엔드 개발자가 리눅스 커널에 대해서 알고 있으면 좋은 이유를 4가지로 정리해보았습니다.
1. 시스템 성능 최적화 이해
• 리눅스 커널에 대한 지식은 시스템 리소스 관리, 메모리 할당, 프로세스 스케줄링, 입출력 처리와 같은 저수준 시스템 동작 방식을 이해하는 데 도움을 줍니다. 이로 인해, 개발한 애플리케이션이 시스템 리소스를 어떻게 사용하는지 파악할 수 있어 성능 최적화에 유리합니다.
• 예를 들어, 서버에서 웹 애플리케이션이 어떻게 실행되고 네트워크 자원과 메모리를 효율적으로 사용하게 할지 고려할 때 도움이 됩니다.
2. 배포 및 서버 환경에 대한 깊은 이해
• 리눅스 기반 서버 환경은 대부분의 웹 애플리케이션 배포에 사용되며, 특히 프런트엔드 배포 시 Nginx, Docker, Kubernetes와 같은 툴을 다룰 때 유용합니다. 커널에 대한 이해는 이러한 환경에서 애플리케이션이 어떻게 동작하는지 더 잘 이해할 수 있게 해 줍니다.
• 예를 들어, 컨테이너 환경에서 리소스 제한을 설정하거나 네트워크 문제를 해결할 때 커널의 역할을 알면 트러블슈팅이 더 쉬워집니다.
3. 디버깅 능력 향상
• 커널 지식이 있으면, 시스템 레벨에서 발생하는 문제나 오류를 더 잘 파악할 수 있습니다. 애플리케이션이 예기치 않은 방식으로 동작하거나 성능 이슈가 발생할 때, CPU 사용량이 높거나 메모리 누수가 있는 상황에서 커널 로그나 시스템 진단 도구를 통해 원인을 파악하고 디버깅할 수 있습니다.
• 특히 성능 문제나 메모리 관련 오류가 발생할 경우, 커널 로그와 메모리 관리 방식을 이해하면 디버깅 속도가 빨라집니다.
4. 보안 강화 및 이해
• 커널은 시스템의 보안을 관리하는 핵심 역할을 합니다. 이를 이해하면 서버와 프런트엔드 간의 보안 연결, 데이터 전송, 인증 및 권한 부여 등의 보안 문제를 더 잘 이해할 수 있습니다.
• 예를 들어, 애플리케이션과 데이터베이스 간의 보안 연결 설정이나, 방화벽 및 네트워크 설정을 다룰 때 커널의 보안 메커니즘을 이해하면 도움이 됩니다.
마무리
위 내용을 기반으로 팀에서는 이 책을 결정하게 되었습니다. 애플리케이션에 지속적으로 머지되고 변화하는 과정에서 배포 전/후 서버 리소스가 변화되는 것들을 확인하면서 직접 관리할 수 있어야 한다고 생각했습니다. 또 트래픽이 몰리거나 서비스 API의 상태에 따라 팀이 대비할 수 있도록 하는 것이 목표입니다. 물론 여기에는 Node.js와 Next.js의 구현/동작 방식에 대해서도 아주 잘 알고 있으면 좋을 것 같습니다.
선정된 책은 DevOps와 SE(Software Engineer)를 위한 리눅스 커널 이야기입니다.
*홍보의 목적이 아닌 정확한 정보 전달 위해 명시했습니다. 책 링크는 아래 달아두도록 하겠습니다.
참고
'dev.log' 카테고리의 다른 글
[dev.log] 사수의 유무는 당신의 개발 실력에 도움이 되지 않는다. (0) | 2021.04.24 |
---|---|
클럽하우스, 새로운 문화, 소통 그리고 느낀점 (0) | 2021.02.14 |
[dev.log] 성장이란 무엇인가 (0) | 2020.08.31 |