국내 IT 기업들의 기술 블로그 글을 한 곳에서 모아보세요
- 매주 배포하는 스타트업 환경에서 어떻게 일해야 효율적일까?- 헤이딜러에서 QA팀이 일하는 방식을 소개합니다.안녕하세요.피알앤디컴퍼니 QA Engineer 이동언입니다.헤이딜러는 고객용, 딜러용, 평가사용, 폐차, 딜러 콜, 평가사 콜 6가지 서비스를 운영하고 있습니다.PRND에서는 1주일 간격으로 배포를 진행하고 있는데요, 이러한 짧은 배포 주기를...
안녕하세요. 금융 FE 임문수 입니다.네이버페이 부동산에서 부하테스트를 진행한 경험을 바탕으로 부하테스트에 대한 설명과 nGinder를 활용한 부하테스트를 진행했던 과정에 대해 소개하려 합니다.배경네이버 부동산의 경우 레거시 시스템에서 새로운 프로젝트로의 전환을 진행하고 있습니다.최근 부동산에서 가장 접근이 많은 페이지 중 하나인 각 매물의 정보를 볼 수 있는 상세 페이지 전환을 진행하게 되면서,새로운 페이지가 기존의 사용자 요구를 원활하게 수용할 수 있는지 검증하고 많은 유저가 접근한 경우에도 서비스가 정상 작동을 확인하기 위해 부하테스트를 진행하게 되었습니다.네이버 페이 매물 상세 페이지부하테스트란?부하테스트(Load Testing)는 소프트웨어, 애플리케이션 또는 시스템이 실제 운영 환경에서 예상되는 부하 수준에서 어떻게 수행되는지 평가하는 과정으로 시스템이 사용자의 요구를 충족할 수 있는지, 그리고 특정 부하 조건에서도 안정적으로 작동하는지 확인합니다.서비스 출시 이전 부하테스트를 통해 시스템의 최대 처리 용량을 파악하고, 성능 개선이 필요한 부분을 식별할 수 있습니다.부하테스트 목적1. 성능 한계 확인사용자의 수요나 트래픽 증가 상황에도 안정적으로 서비스를 제공하기 위해 애플리케이션의 최대 처리 가능한 한계를 파악합니다.성능이 과도하게 떨어진다면 필요한 성능 개선 조치를 검토합니다.2. 서비스 코드와 서버 설정 검증서비스 코드에 문제는 없는지 메모리 누수가 발생하거나 응답시간이 과도하게 지연되지 않는지, 서버 설정에 문제가 없는지 확인합니다.3. 목표 TPS 달성을 위한 설정서비스의 목표 TPS 달성을 위한 필요한 서버 구성을 확인하고 예상치 못한 사용자 수요 증가나 트래픽 급증 상황에서도 안정적으로 운영될 수 있도록 준비합니다.이러한 목적을 달성하기 위해 아래 몇가지 점검 사항을 작성하여 부하테스트를 진행하였습니다.- 한 서버당 TPS는 얼마나 나오며 목표 TPS를 달성하기 위해서 필요한 서버 구성은 무엇인가?- 많은 사용자가 접근할 때 메모리 누수나 에러가 발생하지 않는가?- 현재 인프라 설정이 자원이 적거나 과도하게 많지는 않는가?- 하나의 서버당 가장 적합한 인스턴스 수는 몇 개인가?- HPA(HorizontalPodAutoscaler) 설정은 올바른 값을 바라보고 있고 부하 상황에 따라 확장, 축소 되는가?부하테스트 도구부하테스트를 진행하기 전에 아래에서 몇 가지 주요 부하테스트 도구들을 간략히 소개하고 넘어가겠습니다.ApacheBench (ab)ApacheBench는 Apache HTTP 서버 프로젝트에 포함된 경량의 명령줄 부하 테스트 도구입니다.간편한 사용법과 빠른 결과 제공이 장점이나, 고급 기능 부족과 분산 테스트의 한계로 인해 복잡한 테스트에는 제한적일 수 있습니다. 주로 간단한 웹 서버 성능 측정에 활용됩니다.JMeterApache JMeter는 다양한 서버 유형과 프로토콜에 대한 부하 테스트를 지원하며 오픈소스입니다. 사용자는 GUI 및 비GUI 모드를 통해 복잡한 테스트 시나리오를 쉽게 구현하고 실행할 수 있고 오랫동안 사용된 도구라 많은 예시와 커뮤니티 정보가 있습니다.그러나 대규모 테스트를 GUI 모드에서 실행시 리소스 사용이 많아 성능 저하가 발생할 수 있으며 기능이 많아 제대로 사용하려면 학습이 필요합니다.ArtilleryNode.js 기반의 부하테스트 도구로 HTTP/HTTPS, WebSocket, Socket.io 등 다양한 프로토콜과 애플리케이션에 대한 부하 테스트를 지원합니다.간단하게 npm으로 라이브러리를 설치하여 json 혹은 yaml 파일로 부하테스트를 진행할 수 있습니다. 상대적으로 적은 리소스로 높은 성능의 테스트를 실행할 수 있으며 실시간으로 모니터링 제공하고 테스트 결과를 저장하여 그래프로 상세 결과를 볼 수 있습니다.하지만 복잡한 테스트가 필요할 경우 기능이 제한적일 수 있으며 여러 테스트 결과를 비교 분석하기에 조금 불편 할 수 있습니다.nGrindernGrinder는 스크립트 기반 부하테스트 플랫폼으로, 테스트 관리를 위한 Controller와 부하 생성을 위한 Agent로 구성됩니다. 사용자 인터페이스로 테스트를 관리하며, 실시간 보고와 모니터링, 자동 결과 저장 기능을 제공합니다. 또한, 다중 지역 에이전트를 이용해 글로벌 부하 테스트 환경을 손쉽게 구축할 수 있습니다. 하지만, Jython 에 대한 지식이 없다면 복잡한 스크립트를 작성하기에 어려울 수 있고 분산 테스트를 위해 여러 Agent를 사용하는 경우 많은 양의 시스템 자원이 필요합니다.네이버의 경우 이미 사내에서 nGrinder 서비스가 구축되어 있어 테스트와 모니터링, 보고서를 쉽게 볼 수 있는 nGrinder를 이용하여 부하테스트를 진행하였습니다. (nGrinder 설치)테스트 실행 및 모니터링nGrinder 서비스는 부하테스트를 실행하는 성능 테스트 탭과 스크립트를 생성하는 스크립트 탭으로 나누어져 있습니다.부하테스트를 진행하기 위해 스크립트를 먼저 생성합니다.1. 스크립트 작성하기nGrinder는 Groovy와 Jython을 스크립트 언어로 지원합니다. 복잡한 테스트 시나리오 없이 단순 페이지 접근을 수행하는 경우, 샘플 코드를 적절히 수정하여 활용할 수 있습니다.네이버 부동산에서는 비 로그인 상황에서 충분히 테스트가 가능하여 기본으로 제공되는 비 로그인 기반의 샘플 코드를 수정하여 부하테스트를 진행했습니다.스크립트 명을 지정하고 생성하기를 누르면 기본 샘플 코드가 제공되며,단순 접근만 필요한 경우 샘플코드에서 Test 부분을 접근이 필요한 서비스 주소로 변경합니다.@Testpublic void test(){ // 서비스 주소 HTTPResponse response = request.GET("http://please_modify_this.com", params) if (response.statusCode == 301 || response.statusCode == 302) { grinder.logger.warn("Warning. The response may not be correct. The response code was {}.", response.statusCode) } else { assertThat(response.statusCode, is(200)) }}다른 샘플 및 설명은 nGrinder GitHub 에서 확인할 수 있습니다.2. 부하테스트 진행스크립트를 작성했다면 성능 테스트 탭으로 이동하여 부하테스트를 진행합니다.각 에이전트에서 접근하는 사용자 수를 조절하여 서버에 부하를 줄 수 있습니다.우선 1회 실행하여 스크립트가 정상 동작하는지 확인합니다.스크립트가 정상 동작하는 지 확인한 이후 하나의 서버가 받을 수 있는 부하를 확인하기 위해 오토스케일링 옵션이 있다면 동작하지 않도록 설정하고 테스트를 진행합니다.참고 : 다른 서비스나 자원에 영향이 가지 않도록, 해당 서비스가 아닌 부분을 주석 처리하거나 정적 자원으로 변경 후 테스트 진행을 고려합니다.1. 웜업 진행테스트 사이에 코드 변경이나 장비 설정 변경으로 서버가 새로 올라간 경우,초기 서버의 불안정한 상태가 테스트 결과에 영향을 미치지 않도록 부하테스트 시작 전 1~5분 동안 서버 웜업을 진행합니다.nGrinder를 모니터링하여 TPS (Transactions Per Second) 그래프가 안정화될 때까지 웜업을 유지합니다.2. 테스트를 위한 최대 부하 찾기극한의 환경에서 테스트를 진행하기 위해, 서버가 재시작되거나 접근 불가 상태가 되지 않는 범위 내에서 최대 부하를 찾아냅니다.nGrinder의 Agent 수와 vuserPerAgent 값을 조절하여 에러가 발생하지 않는 범위 내에서 테스트를 진행하기 위한 최대 부하를 찾습니다.(참고: 총 vuser가 같더라도 agent가 많을 수록 에러가 더 잘 발생했습니다.)먼저 대략적인 총유저 수를 찾기 위해 유저를 변경하여 실행 종료하면서 nGrinder 모니터링 및 보고서에서 에러가 발생하지 않는 값을 찾습니다.에러가 많이 발생하거나 오른쪽 그래프가 너무 튄다면 총 유저 수를 줄이고에러가 발생하지 않으면서 오른쪽의 TPS 그래프가 너무 튀지 않는 대략적인 범위를 찾습니다.이후 부하 값을 자세히 확인하기 위해 서비스 서버 모니터링 도구를 함께 활용합니다.서버에서 가장 큰 병목 현상을 일으키는 자원을 확인하여 그 자원이 한계에 도달하는 최대 사용자 수를 결정합니다.부동산 FE 서버의 경우 CPU에 가장 많은 병목이 있었고, CPU 부하가 99%에 근접하게 유지되는 총 유저 값을 찾아 부하테스트를 진행했습니다.3. 설정 변경에 따른 데이터 수집인스턴스 개수, 서버 자원, 캐시 적용 등을 통해 결과 값을 기록하여 TPS 성능이 잘 나오면서 그래프가 안정된 형태를 유지하는 최적의 설정 값을 찾습니다.4. 기타 점검 사항 확인부하 테스트를 지속적으로 진행하면서 메모리 누수가 있는지 확인합니다. 이후 다른 점검이 끝났다면 오토스케일링이 발생 가능하도록 설정을 다시 변경하고 부하 상황에 따라 스케일 확장, 축소가 정상 동작 하는지 확인합니다.부하 테스트 결과점검 사항 확인한 서버당 TPS는 얼마나 나오며 목표 TPS를 달성하기 위해서 필요한 서버 구성은 무엇인가?서비스가 예상(혹은 측정) 부하를 견딜 수 있도록, 적절한 안전 마진을 고려하여 최대 RPS를 설정하였습니다. 서버의 실측 RPS 데이터(최대 부하)를 토대로 각 서비스의 목표 RPS에 맞게 대응 가능하도록 pod의 min, max 수치를 결정하였습니다.많은 사용자가 접근할 때 메모리 누수나 에러가 발생하지 않는가?단일 부하 테스트 수행 시 메모리 사용량이 지속적으로 상승하는지 확인하고 지속적으로 부하테스트를 진행하면서 사용량이 계속 상승하고, 가비지 컬렉션이 제대로 이루어지지 않는지 확인하였습니다.계속해서 메모리가 증가하여 재시작 되는 경우(출처: How we resolved a memory leak on our)테스트 진행 시 마다 메모리의 하단 지점과 메모리가 상승 하는 경우현재 인프라 설정이 자원이 적거나 과도하게 많지는 않는가?최대 부하상황에서의 서버 모니터링을 통해 자원을 결정하였습니다.nginx의 경우 최대 부하상황에서도 부하가 크지 않아 자원을 적게 할당했고, nextjs의 경우 부하 테스트 후 잔여 메모리가 높아 기존보다 메모리를 좀 더 높게 설정하였습니다.하나의 서버당 가장 적합한 인스턴스 수는 몇 개인가?부하 테스트를 통해 각 Pod 당 최적의 Instance 수를 도출하였습니다. 이전 부하테스트 경험을 통해 Instance 6~10개 범위 내에서 테스트를 진행하였고 nGrinder 모니터링 그래프의 평균 TPS와 TPS 그래프의 증감폭 (아래 박스 영역), 시스템의 안정성을 고려하여 인스턴스 수를 결정하였습니다.HPA(HorizontalPodAutoscaler) 설정은 올바른 값을 바라보고 있고 부하 상황에 따라 확장, 축소 되는가?최소값을 1로 주고 부하를 주어 바라보고 있는 값이 유의미한 값인지, 해당 값으로 오토스케일링이 잘 동작하는지 확인하였습니다.이외 부하테스트를 통해 확인 및 개선된 사항부하테스트를 진행하면서, 기존에 테스트한 다른 서비스에 비해 TPS가 낮게 나오는 문제가 발생했습니다. 서비스 모니터링 결과, BFF 서버에서 많은 부하로 인해 병목 현상이 발생하는 것을 확인하였고 이를 해결하기 위해 아래와 같은 사항들을 점검하여 일부를 개선했습니다.SSR 요청 개선해당 페이지의 경우 서버 사이드 렌더링(SSR)과정에서 순차적으로 처리되어야 하는 API 호출이 3단계로 나누어져 응답 시간 지연이 발생하고, SSR과정에서 너무 많은 API를 호출하고 있었습니다. SSR 에서 호출되는 API 호출 단계를 2단계로 줄여 next js 서버의 지연을 줄이고 상단 영역이 아닌 API들은 클라이언트에서 필요할 때 호출하도록 하여 페이지 접근과 동시에 발생하는 API 부하를 줄였습니다.캐시 적용해당 페이지의 경우 일부 데이터를 제외하고 사용자 기반이 아닌 매물에 대한 정보를 제공하여 실시간성이 중요한 페이지가 아니었기 때문에 `Cache-Control` 헤더를 설정하였습니다.s-maxage, max-age, stale-while-revalidate 값들을 적절히 지정하여 캐싱이 적용될 수 있도록 설정하였습니다.마치며지금까지 금융 FE에서 nGrinder를 사용하여 진행된 부하테스트를 소개해드렸습니다.처음에는 부하테스트와 관련된 용어와 개념들이 낯설고 복잡하게 느껴질 수 있으나,실제로 nGrinder를 사용해 부하테스트를 진행하면서, 명확한 목적과 방법을 갖고 진행하면 예상보다 접근하기 쉬웠다는 것을 깨닫게 되었습니다.네이버 페이 부동산에서는 이러한 방법으로 부하테스트를 진행하여 개선하였고 안정적으로 배포하여 현재 서비스를 제공하고 있습니다.이 글이 nGrinder를 활용한 부하테스트에 대한 이해를 돕고, 여러분의 서비스에 적용하여 보다 견고하고 안정적인 서비스를 제공하는 데 도움이 되기를 바랍니다.nGrinder를 활용한 부하테스트 was originally published in NAVER Pay Dev Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
LINE에서는 3년 전 기존 헤드리스 CMS의 구조와 성능을 개선한 새로운 헤드리스 CMS, LandPress Content를 사내 임직원 대상으로 출시했습니다. 그 후 전통적인...
안녕하세요, 저는 올리브영의 데이터 플랫폼 인프라를 담당하는 슈로쿤입니다. 현재 저희 회사는 데이터 플랫폼 인프라의 안정적이고, 유연한 확장 그리고 보다 더 빠른 데이터 분석을 위해 Google Cloud…
브뤼셀 효과와 관련된 EU의 디지털 규제는 현재 IT 시장에 큰 영향을 미치고 있습니다. 각 법률에 대한 구체적인 사례와 함께 실제로 어떻게 적용되고 있는지 쉽게 이해할 수 있습니다.
안녕하세요. ABC Studio 기획자 권다이, 디자이너 김보람입니다. 저희는 일본의 최대 규모 배달 서비스인 데마에칸(Demaecan, 出前館)에서 사장님들을 위한 Merchan...
안녕하세요, 요기요 Search Platform 팀의 정승한입니다. 저희 팀은 요기요에서 검색과 관련된 모든 시스템을 관리하고 있으며, 사용자가 입력한 키워드에 가장 적합한 가게와 메뉴를 찾아주는 역할을 하고 있습니다.요기요에서 처음으로 선보이는 검색 관련 테크 블로그인 만큼, 이번 글에서는 가장 기본적인 주제인 사용자의 입력 키워드를 분석하는 방법에...
보완재 추천 모델을 서빙하기 위한 아키텍처 소개
2024년, 빅테크 기업은 더 이상 제품이 아닌, AI, 클라우드 컴퓨팅, 엣지 컴퓨팅, 메타버스 등 혁신적인 기술을 중심으로 경쟁하고 있습니다. 이 글에서는 마이크로소프트, 구글, IBM, 엔비디아 등의 최근 키노트를 통해 글로벌 IT 동향과 미래 전망을 살펴보겠습니다.
들어가며 안녕하세요. LINE+ Contents Service Engineering 조직에서 백엔드 개발을 맡고 있는 양강현, 이병찬입니다. 저희가 속해 있는 Contents Se...
여러분은 주로 어디서 기술 정보를 얻으시나요? 블로그, YouTube 등 다양한 방법이 있지만, 동료에게서 얻는 지식도 많습니다. 잠깐의 티타임, 회식 자리 등 일상적인 교류에서 ...
보완재 추천 모델을 적용하고 성과를 거둔 사례 소개
안녕하세요. ABC Studio 김영재입니다. 저는 LINE이 2020년에 인수한 일본 최대 규모 배달 서비스 데마에칸(出前館, Demaecan) 프로덕트를 담당하고 있습니다. H...
문제 상황 저는 ABC Studio에서 MessagingHub라는 플랫폼 프로젝트를 담당하고 있습니다. MessagingHub는 다양한 비즈니스 요구에 맞춰 엔드 유저를 대상으로 ...
에어플로우는 오늘날 엔터프라이즈 데이터 공급망에서 중요해지고 있으며, 포춘 500대 기업 중 상당수가 데이터 파이프라인 오케스트레이션을 위해 에어플로우를 사용하고 있습니다.
안녕하세요. 요기요 R&D Center에서 Backend Developer로 일하고 있는 이해만입니다. 저는 Discovery & User Squad에서 요기요 채널링 서비스를 담당하고 있습니다.요기요 채널링 서비스란?요기요 앱 외에 다른 플랫폼을 통해 요기요 주문을 해보신 적 있나요?아마 많은 분들이 카카오톡, Gmarket, 또는 비...
클라우드는 단순한 기술 수단을 넘어 비즈니스의 필수 요소로 진화하고 있습니다. 이러한 클라우드 기술을 활용하여 기업은 비용을 절감하고, 운영 효율성을 개선하며, 새로운 비즈니스 모델과 혁신을 추진할 수 있는 기회를 찾고 있습니다.
(2주 스프린트라는 굴레에 갇혀 발버둥 치는 IT업계의 모든 동지들을 생각하며….. 💪)스크럼 개발 프로세스에서 반복되는 짧은 개발 주기마다 지속적인 품질과 생산성을 유지하기 위해서는 모든 프로세스 단계가 그에 맞게 최적화되어 있어야 합니다.정말 군더더기 없이 잘 준비된 아이템을 한 치의 오차와 지연 없이 거뜬하게 해낼 때야 다다를 수 있는 경지가 2...
디지털 고객 경험을 통해 상품을 구매하고 서비스를 상호작용하는 방식이 변화하고 있습니다. 자동차 판매업체는 소비재 판매업체로부터 변화를 수용하고 진화하는 방법을 배울 수 있습니다.
알리익스프레스와 CJ제일제당의 협력은 한국 시장에서 주목할만한 이벤트로, 한국 시장에서의 알리 입지를 더욱 강화하는 계기가 되었습니다. 알리의 한국 시장 확대는 단순한 진출을 넘어서, 글로벌 이커머스 산업의 경계를 재정립하고, 중국 기반 이커머스 플랫폼들이 전 세계적으로 어떻게 영향력을 확대해 나가고 있는지 잘 보여주고 있는 사례입니다.
…
Fixture를 활용한 테스트 코드 작성해보겠습니다. 그런데 이제 🙉 를 곁들인... 안녕하세요. 😀 올리브영에서 백엔드 개발을 하고 있는 윤노트입니다. 테스트 코드를 작성할때 사용하는 Fixture…
Photo by Jo Barnard on UnsplashHEIC/HEIF 란?HEIC(High Efficiency Image Container) 파일 포맷은 Apple이 모바일 디바이스에서 전통적으로 사용하던 HEIF(Efficiency Image Format)의 업데이트 버전입니다.출처: HEIC 파일의 역사 / 장,단점HEIC 형식은 우리 주변에서...
2014년부터 시작되어 매년 미국 라스베이거스에서 열리는 AWS 공식 개발자 행사인 re:Invent! 개발자들의 축제 현장에 다녀온 올디브의 이야기 지금부터 시작합니다. 2023년 AWS re:Invent (이하 : AWS)는 11월 2…
기업이 ESG 목표를 달성하기 위해서는 다양한 기술을 적극적으로 활용할 수 있어야 하는데, 이때 클라우드, 데이터, AI는 핵심 기술로서 중요한 역할을 합니다. 클라우드와 빅데이터 기술을 통합함으로써 에너지 사용 최적화와 지속 가능한 자원 관리가 가능해지고, AI와 머신러닝은 신재생 에너지의 효율적 관리와 배분에 활용할 수 있습니다.
랭체인은 언어 모델 기반의 애플리케이션을 개발하는 프레임워크입니다. 랭체인을 사용해 챗봇 또는 개인 비서를 만들고, 문서 또는 구조화된 데이터에 대한 Q&A를 요약, 분석, 생성하고, 코드를 쓰거나 이해하고, API와 상호작용하고, 생성형 AI를 활용하는 여러 애플리케이션을 만들 수 있습니다.
소개 안녕하세요. 다나와에서 검색 서비스를 개발하고 있는 곽명환입니다. 오늘은 주기적으로 들어오는 요청의 자동화에 대해서 소개해보도록 하겠습니다. 문제점 검색 서비스 담당팀은 정기적으로 변화하는 처리 키워드와 비 처리 키워드를 업데이트하며, 이를 검색 팀에 처리 요청합니다. 처음에는 관련 위키를 참조하며 대응했으나, 몇 가지 문제점을 파악했습니다. 첫...
안녕하세요, 네이버페이 내자산&회원FE에서 프론트엔드 개발하는 이선아입니다.저희 팀이 담당하는 일은 원용님의 아래 글에 잘 정리되어 있습니다.내자산: 마이데이터 자산 조회 by wonyong01.kim이 글에서는 코드 관리의 관점에서, 모노레포에 대해 간략히 알아보고 기존에 있던 두 레포를 하나로 통합하는 과정과 진행하면서 생겼던 고민거리와 느낀 점을 공유하려 합니다.개편 이전의 코드 관리저희 팀에서는 내자산 서비스뿐만 아니라, 신용점수, 송금, 간편결제 등의 서비스도 담당하고 있는데, 각 서비스에서 다뤄야 할 기능이 많다 보니 서비스 별로 레포를 분리해서 코드를 관리하고 있습니다.그리고 공통으로 사용해야 하는 부분을 패키지로 뽑아 패키지용 레포를 따로 두고 있었습니다. 패키지에는 범용적으로 사용되는 코드를 모아둔 utils 패키지나 원용님께서 설명해 주신 Session IO를 사용하기 위한 패키지 등이 있습니다.저희 팀에서 관리하는 레포가 늘어나다 보니, 패키지만 따로 뽑아둔 레포는 개발 스택 업데이트에서 누락되는 등 관리가 안 되는 문제가 발생했습니다. 서비스 코드 작업이 더 급하다 보니 패키지 코드 개선은 후순위로 밀리는 경우가 많았습니다.또한 패키지는 카나리 배포를 해야 코드 동작을 확인할 수 있다보니, 작업을 위한 컨텍스트 스위칭에 피로도가 높아졌습니다.결정적으로 배포 프로세스가 변경되었는데 패키지 레포에서도 이를 새로 적용해야 했고, 이전의 불편사항을 개선하기 위해 패키지 레포와 서비스 레포를 합쳐 모노레포로 관리하기로 결정했습니다.모노레포란?잠깐 모노레포에 대해 설명하자면, 여러 프로젝트의 코드를 하나의 레포에서 저장, 관리하는 소프트웨어 개발 전략을 뜻합니다.기존에도 패키지들을 하나의 레포에서 관리하고 있었으니 해당 레포는 모노레포 전략을 취하고 있었다고 볼 수 있습니다. 이전에 패키지들만 모아서 관리하던 레포에서 패키지들을 옮겨와 하나의 레포에서 코드를 관리할 수 있도록 변경했습니다.Repo before & afterturbo repo란?모노레포를 구성하기 위해서 저희는 turbo repo를 사용했습니다.turbo repo는 자바스크립트 또는 타입스크립트로 된 프로젝트를 대상으로 하는 고성능의 빌드 시스템입니다.turborepo모노레포를 구성하는 많은 방법 중에서 선택할 때에 저희의 기준은 두 가지였는데요, 적용 및 사용하기 어렵지 않을 것과 빌드 속도가 크게 저하되지 않을 것이었고, 결론적으로 저희 팀은 만족하며 사용하고 있습니다.turbo repo 알아보기turbo repo 사용법을 간략하게만 설명하려 합니다. turbo에서는 `turbo.json` 파일에서 설정을 명시하여 사용합니다.{ "$schema": "https://turbo.build/schema.json", "pipeline": { "build": { "cache": false, "dependsOn": ["^build"] }, "deploy": { "cache": false, "dependsOn": ["^build"] }, "start": { "dependsOn": ["^build"] }, "lint": {} }}pipeline은 turbo로 실행할 스크립트의 이름을 키로 가지는 객체입니다. `turbo run`으로 실행할 수 있으며 각 package.json에서 일치하는 스크립트가 있으면 실행시켜줍니다. 예를 들어 `turbo run build`를 실행하면 레포 내의 모든 패키지와 서비스를 빌드 할 수 있습니다.pipeline 별로 설정을 다르게 할 수 있습니다. turbo에서는 빠른 실행을 위해 캐싱을 지원하고 있는데, 스크립트를 실행한 결과를 저장해두어 다시 실행했을 때에 캐시 되어있던 결과가 있다면 그대로 사용합니다. 프로젝트를 빌드 할 때에는 캐싱 된 결과를 사용하지 않도록 cache로 설정을 제어할 수 있습니다. 스크립트 간에 의존성이 있을 경우에는 dependsOn으로 설정합니다.패키지 이관하기패키지 레포에 있는 코드들을 이관하고 turbo로 실행할 수 있도록 스크립트를 정리해 주었습니다.그리고 패키지 매니저인 pnpm에서 제공하는 기능으로, 서비스 코드에서 배포된 버전이 아닌 같은 레포에 있는 코드를 바라볼 수 있도록 package.json을 수정해 주었습니다.{ // ... "dependencies": { "@mydata/packageA": "workspace:*", "@mydata/packageB": "workspace:*" }}배포 프로세스 정리하기코드 이관 후에는 github actions를 이용하여 패키지 버전관리와 배포 프로세스를 정리했습니다. 우선 패키지의 버전 관리와 changelog 작성을 쉽게 하도록 도와주는 Changesets를 도입했습니다.ChangesetsChangesets를 활용한 버전 관리 과정을 짧게 설명하면, PR 생성 시에 패키지에 변경사항이 있는지를 감지하여 코멘트를 달아줍니다.코멘트에서 major, minor, patch 중 어떤 버전을 bump할 것인지 선택하고 changelog를 작성하면 임시 파일을 추가해 줍니다. 해당 PR이 특정 브랜치인 develop에 머지 되면 이를 감지해서 임시파일의 내용으로 버전 업데이트와 changelog를 추가하여 새로운 PR를 생성해주며, 패키지 작업이 모두 완료되었을 때에 작업자가 머지합니다.여기에 나아가서 develop에서 패키지 버전에 변경이 있었을 때에 자동으로 publish를 실행하도록 했습니다. 배포가 정상적으로 완료되면 메신저로 알람을 보내 배포 결과를 공유합니다. 작성한 publish actions 코드를 발췌한 내용입니다.name: Release Publishon: push: branches: - developjobs: publish: runs-on: air-fe steps: - name: Checkout Repo uses: actions/checkout@v2 - name: install dependencies run: pnpm install --frozen-lockfile - name: Create Release Pull Request id: changesets uses: common-fe/changeset-actions@main with: title: "🚀 version changed packages" publish: pnpm run publish - name: Publishing success! if: steps.changesets.outputs.published == 'true' uses: actions/github-script@v6 with: script: # 배포 성공한 경우 사내 메신저인 works 발송마지막으로, 작업 중 카나리 배포를 쉽게 할 수 있도록 PR 코멘트에서 canary-publish를 인식하여 카나리 배포를 자동화했습니다.자동화 작업할 때에는 한주님이 작성해 주신 FinFE Bot을 많이 활용했습니다. 처음 소개해 주신 글보다 지금은 더 많은 기능을 고도화하여 제공하고 있지만, 읽어보시면 자동화에 대한 인사이트를 얻을 수 있습니다!반복적이고 귀찮은 일은 Bot에게! by 이한주불편한 점 개선하기배포 프로세스까지 정리하고 나니 “해야 하는 일”은 다 끝난 상태였고, 약간의 불편한 부분이 남은 상태였습니다.첫 번째로 CI/CD에 걸리는 시간이 길어진 것이었습니다. PR 생성 시에 작성한 코드에 이상이 없는지 확인하는 CI가 걸려있는데, 코드를 모두 빌드 하는 단계가 포함되어 있었습니다. 패키지에 비해 서비스 빌드 시간이 더 길었는데, 패키지 코드를 조금만 고쳐도 긴 서비스 빌드 시간을 기다려야 했습니다.이런 문제를 해결하기 위해서 빌드 스크립트를 분리하고 패키지 변경 시에는 서비스 코드에 대한 테스트를 건너뛸 수 있도록 github actions를 보완했습니다.두 번째로는 브랜치 관리가 이슈가 되었습니다. 패키지 코드 작업과 서비스 코드 작업에 의존 관계가 있어서 문제 되는 부분이 있었습니다.처음에는 패키지 수정 시에 패키지 쪽만 수정해서 PR을 작성하여 changelog에서 쉽게 확인할 수 있도록 하려 했는데, 서비스 코드에서 이를 참조하고 있어서 에러가 발생할 수 있습니다. 브랜치가 잘못 관리 되면 다른 브랜치로 에러가 전파될 수 있어서 브랜치 관리 전략을 새로 논의해야 했습니다.장단점 분석해보기모노레포로 전환하고 몇 달간 사용해 보면서 느낀 장단점을 분석해 봤습니다.장점은- 한 레포에서 관리하다 보니, 패키지 작업이 수월해졌습니다.- 개발 스택 업데이트할 때에 누락되는 경우가 적어졌습니다.- 코드 검색과 관리가 쉬워졌습니다.단점은- 브랜치 관리 방법이 더 복잡해졌습니다.- 팀원 모두 빌드 시스템에 대한 공부가 더 필요했습니다.전체적으로 봤을 때에 코드 작업 측면에서는 모노레포를 사용하는 것이 유리하지만, 환경 설정이나 브랜치 관리가 복잡하여 피로해진 부분도 있었습니다.마치면서작업 착수 전에는 코드 이동만 하면 되려나 했는데, 실제로 작업하면서는 빌드 시스템부터 github actions까지 다양하게 공부해 볼 수 있었습니다.제 경험기가 모노레포 전환을 고려하시는 분들께 조금이나마 도움이 되었으면 좋겠습니다.이번 모노레포 전환 작업을 진행하면서 시행착오도 많이 하고 고민도 많이 하면서 한 뼘 더 성장할 수 있었습니다. 작업 중 막힐 때마다 함께 고민해 주신 팀원분들 덕분에 무사히 마무리할 수 있었습니다.저희 네이버페이 내자산&회원FE에서는 팀원들의 지속적인 성장을 독려하고 있습니다. 저희와 함께하실 열정적인 분들을 언제나 기다리고 있습니다!채용: https://recruit.naverfincorp.com/코드, 어떻게 관리하세요? was originally published in NAVER Pay Dev Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
쏘카플랜 개편기 대부분의 개발자들은 논리적 사고와 정교한 설계를 통해 체계적으로 멋진 제품을 만드는 것을 목표로 합니다. 하지만 현실에서는 마감일에 쫓겨 우선순위를 정하고, 기능만 동작하도록 급히 코드를 작성해야 하는 상황에 처할 때가 많습니다. 다음과 같은 분들이 읽으면 좋습니다. 모든 프론트엔드 개발자 코드 품질과 마감일 사이에서 고민 중인 개발자...
생성형 기업이란 AI, 머신러닝, 딥러닝 등 생성형 기술을 활용하여 새로운 콘텐츠, 제품, 서비스를 창출하고, 비즈니스 모델을 혁신하는 기업을 의미합니다. 생성형 기술을 성공적으로 적용하기 위한 전략, 핵심 구성 요소, 그리고 생성형 기업으로 진화하기 위한 전략적 접근 방법을 제시합니다. 마지막으로, 생성형 기술의 미래 전망 및 도전 과제를 논의하며,...