다메카솔

Vue.js로 개발을 하기위해 환경세팅을 할 때, npm과 yarn을 사용할 일이 있었습니다.

둘 다 node.js 개발환경에 필요한 패키지를 관리하는 패키지매니저라는 것을 알고 있었는데, 어떤 차이점이 있는지, 그리고 두가지를 혼용하여 사용해도 왜 크게 문제가 없는지 궁금하여 각각의 특징과 차이점을 찾아보았습니다.

Yarn과 npm

Yarn과 npm은 둘 다 JavaScript 개발에서 종종 사용되는 패키지 매니저로, 프로젝트의 종속성을 관리하고 설치하는 데 사용됩니다. 이들은 개발자가 애플리케이션에 필요한 외부 라이브러리와 패키지를 쉽게 관리할 수 있게 해줍니다.

npm (Node Package Manager)

npm은 Node.js의 기본 패키지 매니저입니다. Node.js는 JavaScript 실행 환경이며, npm은 Node.js를 다운로드하고 설치할 때 자동으로 함께 설치됩니다. npm은 npm 레지스트리라는 저장소를 통해 수많은 패키지 생태계를 제공합니다. 이는 패키지를 설치, 게시, 관리하는 데 사용되는 명령 줄 도구입니다.

주요 기능:

• 대규모 패키지 생태계: npm은 사용 가능한 수백만 개의 패키지를 보유하고 있어 프로젝트에서 쉽게 사용할 수 있습니다.
• 버전 관리: npm은 패키지 버전을 지정하고 semantic versioning에 따라 종속성을 관리할 수 있습니다.
• 스크립팅: npm에는 다양한 개발 작업을 정의하고 실행할 수 있는 내장된 태스크 러너가 포함되어 있습니다.
• 협업: npm은 자체 패키지를 공유하고 게시할 수 있도록 해주어 다른 사람들이 해당 패키지를 사용할 수 있습니다.

Yarn

Yarn은 JavaScript 애플리케이션용으로 개발된 또 다른 인기 있는 패키지 매니저입니다. Facebook에서 npm의 한계와 성능 문제를 해결하기 위해 개발되었습니다. Yarn은 npm으로 설계된 패키지와 호환될 수 있도록 되어 있습니다.

주요 기능:

• 성능: Yarn은 패키지 설치 및 종속성 해결 등에서 보다 빠르고 안정적입니다. 특히 대규모 프로젝트에서 성능상 이점이 있습니다.
• 결정론적 설치: Yarn은 락파일(yarn.lock)을 사용하여 동일한 종속성 버전이 다른 기기에서도 일관되게 설치되도록 보장합니다.
• 오프라인 모드: Yarn은 내장된 오프라인 캐싱을 가지고 있어 인터넷에 연결되지 않은 상태에서도 패키지를 설치할 수 있습니다.
• 병렬 다운로드: Yarn은 패키지를 병렬로 가져오기 때문에 설치 과정을 크게 가속화할 수 있습니다.

Yarn과 npm의 차이점

• 패키지 설치: Yarn은 결정론적 알고리즘과 락파일을 사용하여 일관된 설치를 보장하는 반면, npm은 package-lock.json 파일을 사용합니다. 이로 인해 설치된 종속성에 약간의 차이가 생길 수 있습니다.
• 성능: 일반적으로 Yarn이 패키지 설치 및 종속성 해결과 같은 작업에서 더 빠르고 효율적입니다. 특히 대규모 프로젝트에서 그 이점이 큽니다.
• 캐싱: Yarn은 내장된 캐싱 기능을 가지고 있어 인터넷 연결이 없는 상황에서도 패키지를 설치할 수 있으며, 다음 설치 과정을 가속화합니다. npm은 npm 버전 5부터 캐싱을 지원하지만 Yarn의 캐싱 기능만큼 고급화되지 않았습니다.
• 사용자 인터페이스: Yarn은 npm에 비해 더 간결하고 사용자 친화적인 명령 줄 인터페이스를 제공합니다.

요약하면, Yarn과 npm은 JavaScript 프로젝트에서 종속성을 관리하는 데 사용되는 패키지 매니저입니다. Yarn은 npm의 성능 및 신뢰성 문제를 개선하기 위해 만들어졌지만, 두 패키지 매니저 모두 JavaScript 생태계에서 널리 사용됩니다. 선택은 주로 개인의 선호도와 프로젝트 요구 사항에 따라 달라집니다.

증상

* What went wrong:
Execution failed for task ':sonar'.
> org/sonar/batch/bootstrapper/EnvironmentInformation has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

젠킨스 파이프라인을 이용해 SonarQube 정적분석을 실행하려고 할 때, 위와같은 에러 메세지가 발생하였습니다.

원인

위 에러는 Java 실행환경이 클래스파일 버전을 52.0까지 지원하지만, 컴파일된 버전의 클래스 버전이 55버전이라 발생한 문제입니다. 

해결책

가장 간단한 해결책은 Java Runtime을 더 최신 버전으로 업데이트하는 것입니다. 이렇게 하면 최신 버전의 클래스 파일도 인식할 수 있게 됩니다. Oracle 또는 OpenJDK 웹 사이트에서 Java Development Kit (JDK)의 최신 버전을 다운로드하여 설치할 수 있습니다.

참고자료

Java 버전 업데이트: https://www.oracle.com/java/technologies/javase-jdk13-downloads.html

클래스 파일 버전 다운그레이드: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html#BABGBJCI

Gradle 설정: https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_java_version

지난 5월 15일, 코엑스 컨퍼런스룸 3층에서 열린 마이크로소프트 x 깃허브 로드쇼에 참석했습니다. 이 행사에서는 2년 전에 출시된 Github Copilot을 활용하여 개발자의 생산성을 향상시키는 방법과 클라우드 네이티브 환경에서 인공지능(AI)의 도움을 받아 빠르게 서비스를 출시하는 미래 시대의 개발문화를 체험할 수 있었습니다.

ChatGPT는 이미 많은 직장인들이 업무에 활용하여 반복적인 작업을 줄이고 생산성을 높이는 데 큰 도움을 주고 있습니다. 실제 개발자의 코드 작성 작업에서도 ChatGPT는 주석을 입력하면 원하는 코드를 제안해주고, 제안된 템플릿을 검토한 후 상황에 맞게 수정하여 적용하면 잘 작동합니다. 또한, 코드형 인프라(IaC)의 설정 파일 작성과 쿠버네티스 설정도 지원하는 것을 시연했습니다.

이 행사에서는 Github Copilot과 마이크로소프트에서 제공하는 다양한 클라우드 서비스들을 소개했지만, 가장 인상 깊었던 것은 AI를 활용한 개발 생산성 향상이었습니다. AI가 다양한 영역에서 사람들의 업무를 자동화하고 개발 생산성을 향상시키는 상황에서, 이를 비즈니스에 어떻게 적용하여 더 좋은 제품과 서비스를 제공할 수 있는지, 그리고 AI가 대체하지 못하는 요소들(예: 팀의 성격, 문화, 아키텍처 등)에는 어떻게 AI의 도움을 받아 더욱 생산성을 향상시킬 수 있는지에 대한 궁금증이 생겼습니다.

우선 AI시대에 뒤쳐지지 않도록 업무에서 활용하며 큰 효과를 보고있는 Copilot을 팀원들에게 적극 추천하고, 개발생산성에 대한 논의를 제시해보는 방법부터 시작해봐야 할 것 같습니다.

많이 지났지만, 지난 2023년 3월 19일 SQLP 시험을 보고 왔습니다.

먼저 시험 결과부터 이야기하자면, 불합격 하였습니다. 그래도 시험을 보고 나니 응시하길 잘한 것 같아서 다행입니다.

작년 말 빅데이터 분석기사 실기 합격결과 발표 때, 내년엔 무엇을 공부할까 고민하던 중 어렵기로 유명한 SQLP 자격증이 떠올랐습니다. SQLP 자격증은 합격률이 10% 미만으로 매우 어려운 시험으로, 공부량도 많고 내용도 어려워서 정말 쉽지 않은 도전이 될 것이라 생각했습니다. 하지만, 개발자로 일하면서 언젠간 느린 SQL을 튜닝해야 할 상황이 올 것이고, 데이터베이스 아키텍처에 대해 체계적으로 공부해야 더 성장할 수 있다고 느꼈습니다. 그래서 2023년에 SQLP 시험을 보기로 결심했습니다.

실제 시험은 예상보다 익숙한 용어들이 많이 등장하였고, 공부한 내용들도 생각보다 꽤 출제되었습니다. 꾸준한 노력과 숙달하게 공부한다면, 다음 시험이나 다다음 시험에서는 더 나은 결과를 얻을 수 있을 것 같은 희망이 생겼습니다.

다음 시험은 9월입니다. 합격발표가 나고 4월부터 공부를 시작했는데 한 3주는 열심히 하다 요즘 지지부진해진 것 같네요 ㅠ.ㅠ 다시 마음잡고 공부를 해야겠습니다.

https://product.kyobobook.co.kr/detail/S000200381165

독서기간 : 2023.03

독서시간 : 5H

평점 : ★★★★☆

한줄평 : 시니어들이 경력을 쌓으며 만든 원칙들을 공유받을 수 있습니다.

인생을 살아가면서 사람들은 다양한 경험을 하고, 성공과 실패를 통하여 이전보다 더 성장합니다.

개발자들은 조직의 문제, 프로젝트의 문제, 더 나아가 사회의 문제를 해결하기 위해 성장을 추구합니다.

많은 책을 읽거나 컨퍼런스 등에 참여하여 새로운 정보를 얻고, 그 정보를 사람들과 나누며 함께 성장하며 살아갑니다.

이제 막 개발을 시작한 주니어들은 주변에 사수가 있을 수도 있고, 없을 수도 있고, 같이 성장할 비슷한 레벨의 동료들이 있을 수도 있지만 없을 수도 있습니다. 

위 책은 시니어 레벨의 테크 리더들이 현실세계의 문제를 해결하면서 깨달은 성공, 그리고 성장을 위한 원칙들의 노하우를 요약한 책입니다. 일을 하거나 인생을 살아가면서 이미 경험한 누군가가 건네주는 조언은 후임자들의 실행착오를 줄여주며 그만큼 더 생산적인 결과가 나올 수 있게되고, 결과적으로 사회가 더 좋아지게 될 것입니다.

각각의 테크리더들이 처한 상황과 관점이 다르다보니 책에서 소개하는 원칙들을 독자들이 처한 상황에 100% 적용할 수 있을지는 잘 모르겠습니다. 저같은 경우 주니어레벨에게 설계의 원칙을 이야기한 챕터를 읽을 때, 아직은 해당 원칙을 고민해야 할 정도로 개발자로서 성장하지 않았다는 느낌을 받았습니다.

하지만 지금 제 고민을 더 좋은 방법으로 해결해줄 수 있는 원칙들도 있었고, 곧 닥쳐올 고민에 대한 이야기도 있었습니다.

책을 통해 쉽게 듣기 힘든 테크리더들의 노하우를 공유받을 수 있다는 부분에서 유익한 독서였습니다.

Nginx는 오픈소스 웹 서버 및 리버스 프록시 서버 소프트웨어로, 다양한 운영 체제에서 사용되며 높은 성능과 안정성을 가지고 있습니다. Nginx는 이벤트 기반 구조를 사용하여 비동기적으로 동작하며, 적은 자원으로 많은 연결을 처리할 수 있어 인기 있는 소프트웨어입니다.

이전에 작성한 Nginx에 대한 소개 글에 이어 Nginx의 구조에 대해 살펴보겠습니다.

https://damecasol.tistory.com/86

Nginx의 구조

NGINX는 이벤트 구동, 비동기 및 비차단 모델을 지원하여 마스터-슬레이브 아키텍처로 구성되어있습니다.

1. Master process : 모든 워커 프로세스를 관리하는 부모 프로세스입니다.
2. Worker process : 클라이언트 요청을 처리하는 자식 프로세스입니다.
3. Event module : Nginx의 비동기 이벤트 처리 엔진으로, I/O 처리를 담당합니다.
4. Cache module : 자주 요청되는 리소스를 캐시하여 처리 속도를 높입니다.
5. HTTP module : HTTP 요청 및 응답 처리를 담당합니다.
6. Reverse proxy module : 웹 서버에서 클라이언트 요청을 받아 백엔드 서버로 전달하는 역할을 합니다.
7. Load balancing module : 여러 백엔드 서버로 부하를 분산하는 로드 밸런싱을 수행합니다.
8. SSL module : SSL/TLS 암호화 연결을 지원합니다.

위의 이미지에서 핵심 부분 3가지를 조금 더 정리하면 다음과 같습니다.

Master Process

클라이언트의 요청에 따라 작업자에게 작업을 할당합니다. 작업자에게 작업이 할당되면 마스터는 작업자의 응답을 기다리지 않는 클라이언트의 다음 요청을 찾습니다. 작업자로부터 응답이 오면 마스터가 클라이언트에 응답을 보냅니다.

Worker Process

워커는 NGINX 아키텍처의 슬레이브이며 마스터를 리스닝합니다(원문 heed). 각 워커는 단일 스레드 방식으로 한 번에 1000개 이상의 요청을 처리할 수 있습니다. 프로세스가 완료되면 응답이 마스터로 전송됩니다. 단일 스레드는 다른 메모리 공간 대신 ​​동일한 메모리 공간에서 작업하여 RAM 및 ROM 크기를 절약합니다. 다중 스레드는 다른 메모리 공간에서 작동합니다.

Cache 

Nginx 캐시는 서버에서 가져오는 대신 캐시 메모리에서 가져와 페이지를 매우 빠르게 렌더링하는 데 사용됩니다. 페이지에 대한 첫 번째 요청 시 페이지가 캐시 메모리에 저장됩니다.

정리

Nginx의 구조를 알아보면서 마스터-슬레이브 아키텍처, 그리고 Nginx가 멀티프로세스 - 단일스레드 방식으로 작동한다는 것을 알게 되었습니다.

위의 내용에 대해서는 후에 더 정보를 찾아봐야 겠습니다.

참고자료

https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/

https://medium.com/@premsuryamj/nginx-architecture-9f97cf7887e2