안녕하세요. 이그나이트 FE1팀 한준호입니다. 프론트엔드 개발에서 CI/CD 파이프라인의 성능 최적화는 개발 생산성에 직결되는 중요한 과제입니다. 특히 모노레포 구조에서 여러 앱을 동시에 빌드하는 환경에서는 의존성 설치 시간이 전체 파이프라인 시간의 상당 부분을 차지하게 됩니다. 저희 팀에서는 GitLab CI와 pnpm을 사용하는 모노레포 프로젝트에서 빌드 시간을 단축하기 위해 캐시 전략을 도입했지만, 예상과 다른 결과를 경험했습니다. 이 글에서는 그 과정에서 겪은 시행착오와 교훈을 공유하고자 합니다. 초기 상황: 느린 의존성 설치 문제점 모노레포 구조: 5개의 워크스페이스 프로젝트 의존성 설치 시간: 각 앱당 20-30초 전체 빌드 시간: 의존성 설치만으로도 상당한 시간 소요 기존 GitLab CI 설정 5개 앱이 존재하기 때문에 개별 앱이 빌드될 때 매번 의존성을 처음부터 다운로드받아야 했고, 이는 명백한 비효율이었습니다. 해결 시도: pnpm 캐시 도입 캐시 전략 설계 pnpm의 콘텐츠 주소 지정 스토어(Content-addressable Store) 특성을 활용하여 한번의 pnpm i 만 구동하여 나머지 앱에서는 pnpm-store node_modules 를 캐싱하도록 다음과 같이 스크립트를 작성했습니다. 예상 효과 캐시 적중 시: 의존성 설치 시간 대폭 단축 개발자 경험: 더 빠른 피드백 사이클 빌드 결과

안녕하세요. 이그나이트 FE1팀 한준호입니다. 오늘은 크롬 개발자 도구를 활용해 react 기반 웹 서비스에서 실제로 발생한 입력 지연 문제를 분석하고 개선한 경험을 공유해보려 합니다. 문제를 어떻게 정의했고, 어떤 도구로 추적했으며, 어떤 방식으로 개선했는지. 그리고 개선 전후의 수치와 체감 변화는 어땠는지 정리해 보았습니다. 🧩 "입력이 느려요" 새로운 프로젝트의 어드민 서비스를 개발하던 중, 예상치 못한 문제가 발생했습니다. react-hook-form 을 활용한 복잡한 화면에서 input 필드에 값을 입력할 때마다 프레임 드랍이 발생한 것이었습니다. 처음엔 큰 문제가 아니라고 생각했지만, 입력이 끊기듯 반응하면서 사용자에게 눈에 띄는 불편함을 주는 수준으로 나타났고, 그때부터 본격적인 분석을 시작했습니다. 아래 영상에서는 입력 시 텍스트가 끊겨 보이거나, 반응 속도가 늦어지는 현상을 확인할 수 있습니다. 🔍 React DevTools – Highlight 해당 어드민은 react 기반으로 개발되었습니다. 먼저, 입력 시 어떤 컴포넌트가 리렌더링되는지 확인하기 위해 React Developer Tools의 highlight 리렌더링 기능을 활성화해 보았습니다. 예상대로, 특정 input 필드에 값을 입력하면 화면 전체에서 대량의 리렌더링이 발생하는 것이 시각적으로 확인되었습니다. highlight 기능을 통해 리렌더링이 다수 발생하는 것은 인지했으니, 이 리렌더링이 정말 성능 저하의 원인인지 파악할 필요가 있습니다. 성능 저하는 layout shift, heap memory 증가로 인한 GC 부하 등 다양한 요인으로 발생하기 때문입니다. react는 화면을 최신 상태로 유지하기 위해 리렌더링을 의도적으로 수행합니다. state나 props가 변경되면 해당 컴포넌트를 다시 렌더링하는 구조는 react의 핵심 동작 원리입니다. 또한, 최신 react는 fiber reconciliation을 통해 렌더링 성능을 최적화합니다. 불필요한 DOM 변경은 건너뛰고, 실제로 변경이 필요한 부분만 선별적으로 갱신되도록 설계되어 있습니다.

들어가며 개인적인 경험으로, 회사에서 진행하는 프로젝트 중에서 오직 단독 시스템으로 동작하는 서비스는 없었던 것 같다. 대부분은 외부 시스템과 연동하게 되며, MSA를 주력으로 사용하는 부서라면 더더욱 많은 연동을 하게 될 것이다. 연동해야 하는 시스템이 많다는 것은 그만큼 관리 포인트가 늘어나는 것이고, 그에 따라 맞닥뜨려야 할 오류 또한 증가하게 된다. 일부 요청 추적(Request Tracing)을 지원하는 DataDog, PinPoint, Jaeger 등의 서비스를 사용하여 요청/응답을 간략하게 확인할 수 있는 툴을 사용한다면 좋겠지만, 그렇지 않고 독자적으로 시스템에서 외부 시스템을 호출할 때의 로그를 남기고 싶어 하는 부서도 있다. 이 글에서는 그중에서도 RestTemplate을 사용하여 외부 시스템과 연동할 때, 요청/응답에 대해 로그를 DB로 남기는 것을 설명하려 한다. 예제 프로젝트 세팅 이 글에서는 기본적으로 Kafka의 값에는 Json 형식으로 메시지를 저장하는 부분에서 나아가 Json 부분을 암호화하고, 복호화하는 것을 추가하여 설명하려고 한다. 우선 Json 값을 저장하는 예제 프로젝트로 아래와 같이 Producer와 Consumer 세팅하였다. build.gradle DelegateController http://localhost:8080을 호출할 때 RestTemplate을 사용하여, http://httpbin.org/get을 호출하고, 이에 대한 응답을 HttpBinResponse로 정의하여 반환한다. 로컬에서 애플리케이션을 실행시켜 아래와 같이 동작하는 것을 확인할 수 있다. RestTemplate 요청/응답 로그를 DB에 저장하기 1. 사용자 정의 ClientHttpRequestInterceptor 작성하기 Spring에서는 ClientHttpRequestInterceptor를 통해, RestTemplate이 요청/응답을 보내기 전/후의 동작을 정의할 수 있다. 인터페이스는 다음과 같다. HttpRequest: 요청에 대한 객체이며, HttpHeaders getHeaders(), URI getURI(), HttpMethod getMethod()를 가지는 인터페이스다.

머신러닝 소개 머신러닝, ML 엔지니어가 하는 일 머신러닝(Machine Learning)은 인공지능(AI)의 한 분야로, 컴퓨터가 데이터로부터 스스로 학습하여 패턴을 인식하고 예측을 수행할 수 있게 해주는 기술입니다. 전통적인 프로그래밍 방식은 규칙을 직접 코딩하지만, 머신러닝은 데이터로부터 규칙을 스스로 학습합니다. 이를 통해 복잡한 패턴 인식, 예측, 의사결정 등이 가능해집니다. 메일에서 스팸 메일을 찾아내는 간단한 일에서부터, 의료 분야에서는 질병 예측과 진단, 금융 분야에서는 사기 탐지, 그리고 자율주행 자동차 같은 것들이 머신러닝을 통해 이루어집니다. 머신러닝은 크게 정답이 포함된 데이타로 학습하는 지도학습, 데이타의 패턴을 스스로 찾아내는 비지도학습, 환경과 상호작용하며 보상을 최대화 하는 강화학습. 이렇게 3가지 유형으로 나눌 수 있습니다. 머신러닝 모델은 이런 학습과정을 거쳐 만들어진 규칙입니다. 입력 데이터를 받아 출력을 생성하는 함수와 같은 것입니다. 예를 들어, 스펨 메일 필터링 모델은 입력 메일의 특징을 분석하여 스펨 메일인지 아닌지를 예측하는 알고리즘입니다 머신러닝 모델을 개발하고 배포하는 ML 엔지니어는 데이터를 수집하고 분석하며, 머신러닝 모델을 만들고, 모델을 배포하여 실제 업무에 적용합니다. 데이타의 양이 커서, 데이타에 노이즈나 결측치가 있어서 어려움을 격기도 하고, A하드웨어에서 만든 모델이 B하드웨어에서 제대로 작동안하는 문제를 해결하기도 합니다. 이 글에서는 ML 엔지니어의 기본 업무인 데이터 분석과 모델 구축 과정을 타이타닉 생존자 예측 문제를 예로 들어 설명하겠습니다. 이를 통해 ML 엔지니어의 실제 업무와 그 과정에서 겪는 다양한 도전 과제들을 이해할 수 있을 것입니다. 타이타닉 문제로 시작하기 타이타닉 문제는 1912년 타이타닉 호 침몰 사고 당시의 실제 데이터를 기반으로 승객의 나이, 성별, 탑승 티켓 등급 등의 데이타로 해당 승객이 생존했는지 여부를 예측하는 것입니다. 데이터 규모가 크지 않아(12개의 컬럼, 891건의 데이터) 초보자도 다루기 쉬우며, 이진 분류(생존/비생존) 문제라 평가가 용이합니다. 또한 숫자, 범주형 등 다양한 유형의 데이터와 결측치(누락된 데이타)를 포함하고 있어, 데이터 전처리 과정을 연습할 수 있습니다. 이 문제는 기계학습 파이프라인의 전체 과정을 경험할 수 있는 대표적인 예제입니다.

들어가며 개발 업무를 진행하면 종종 개인정보에 대해 다룰 때가 생긴다. 보통 이러한 민감정보는 DB, Redis, Kafka 혹은 로깅에서도 암호화하여 저장하는 것이 권장된다. 이 글에서는 스프링으로 Kafka를 사용할 때, 본문 내용에 대해 암호화하여 저장하는 방법을 다루고자 한다. Json 역/직렬화 예제 이 글에서는 기본적으로 Kafka의 값에는 Json 형식으로 메시지를 저장하는 부분에서 나아가 Json 부분을 암호화하고, 복호화하는 것을 추가하여 설명하려고 한다. 우선 Json 값을 저장하는 예제 프로젝트로 아래와 같이 Producer와 Consumer 세팅하였다. producer와 consumer를 분리하였는데 이는 Spring Kafka에서 제공하는 JsonSerializer/Deserializer의 지원에 대해 설명하기 위해 분리하였다. producer의 코드들 ProducerChatMessage Kafka에 값으로 저장할 내용을 아래와 같이 정의했다. ProducingController Http 요청을 받아 ProducerChatMessage를 Kafka로 전송하는 부분으로 아래와 같이 정의한다. application.yaml Kafka에 대한 설정과 위에서 정의한 ProducerChatMessage를 아래와 같이 Json으로 직렬화하면서 별칭(alias)을 줄 수 있다. spring.kafka.producer.value-serializer와 spring.kafka.consumer.value-deserializer의 값으로 JsonSerializer, JsonDeserializer를 사용할 수 있다. 위 두 개의 클래스를 지정할 때 spring.kafka.[producer|consumer].properties.spring.json.type.mapping으로 위 예제와 같이 콜론(:) 구분으로 별칭을 줄 수 있다. 이러한 별칭은 추후 클래스를 다른 패키지로 변경하거나, 다른 클래스를 사용하게 될 때에도 유연하게 대응할 수 있도록 도와준다. 참고: Spring Boot / Reference / Messaging / Apache Kafka Support

들어가며 SaaS(Software As A Service)가 보편화되며 아마 많은 개발자가 이를 구현하기 위해 Twelve-Factor를 읽어보았을 것으로 생각된다. 이 글은 Twelve-Factor에서 설정에 대해 어떻게 Spring Boot를 사용하는 개발자들이 외부의 설정 저장소에 접근하여 설정을 읽을 수 있을지 구현에 관해 이야기하고자 한다. 이미 대부분의 스타트업들은 클라우드 환경에서 시작하고 있으며, 국내 IT 대기업들은 자체 클라우드를 구축하고, IT 업계 외의 사업을 주로 하는 기업들도 클라우드로 옮겨가고 있다. 주된 방향성은 클라우드 환경에 있지만 아직 온프레미스를 주로 사용하는 조직도 있기에, 여기서는 온프레미스와 클라우드 환경에 따라 어떻게 설정을 달리할 수 있는지 다뤄보려고 한다. Spring Externalized Configuration 본문에서 다루고자 하는 모든 개발 방법의 기반은 Spring Documentation에서 이미 기술하고 있는 내용에 대한 응용이다. 또한 외부에서 설정을 읽는 부분에 대한 많은 지원을 이미 Spring Cloud Config에서 제공하고 있으니, 사용하려는 환경이 이미 Spring Cloud Config에서 지원하고 있다면 사용하는 것이 좋다. 이 글은 Spring Cloud Config보다는 좀 더 바퀴를 만드는 방법에 대해 다룬다. 본문이 도움될 만 한 상황 아래와 같은 상황에서 이 글이 도움이 될 것이라 생각된다. Spring Cloud Config를 조금 더 가볍게 모듈화하거나, 자신의 조직에 맞게 구성하고 싶은 경우. 전체 혹은 일부 설정에 대해 Spring Cloud Config에서 지원하지 않는 외부 설정 저장소를 사용하려는 경우. 혹은 아래와 같이 application.properties를 커스터마이징하려는 경우. 외부 환경에서 설정을 개발자가 직접 호출하도록 개발하기 Spring Cloud Config에서 지원하지 않는 환경에 설정을 저장하고, 불러와야 하는 경우가 있다. 사내에서 자체 구축한 시스템을 사용하는 경우이다. 이런 경우 EnvironmentPostProcessor를 진입점으로 간주하고 원하는 결과를 이룰 수 있다.

안녕하세요. 이그나이트 FE1팀 한준호입니다. 이그나이트 FE1팀에서는 기아인증중고차를 포함해서 다수의 백오피스와 사내 공통패키지를 운영하고 있습니다. 오늘은 다수의 프로젝트 운영간 마주한 문제와 이를 해결하기 위한 기술인 Module Federation에 대해 기술하고자 합니다. Module Federation 도입은 왜 필요할까? 현대 웹 애플리케이션의 규모와 복잡도가 증가함에 따라, 개발팀은 효율적인 개발, 유지보수, 배포 방법을 모색해야 합니다. 특히 대규모 프로젝트에서는 빌드 및 배포 시간이 길어지고, 공통 컴포넌트의 변경으로 인해 전체 애플리케이션을 재빌드해야 하는 문제가 발생합니다. 도입 배경 이그나이트 FE팀은 나열한 문제들로 Module Federation 도입을 고민하게 되었습니다. 빌드 시간의 증가 대규모 애플리케이션의 경우 빌드 시간이 길어져 개발 생산성이 저하됨 공통 컴포넌트 및 유틸의 파편화 여러 프로젝트에서 일관된 UI/UX와 개발 경험(DX)을 유지하는 데 어려움이 있음 문제 해결 대안 모노레포(Monorepo) 여러 프로젝트를 하나의 레포지토리에서 관리하여 코드 공유와 협업을 용이하게 함. 하지만, 공통 컴포넌트의 변경 시 전체 프로젝트를 재빌드해야 하는 단점이 있음. 단일 레포 프로젝트를 모노레포에 편입시키기 위한 마이그레이션 과정은 이미 운영되고 있는 서비스에 도입하기엔 서비스 전수 QA, 개발 리소스 부담 등 여러 차원에서 큰 부담이 됨. Iframe 서로 다른 애플리케이션을 하나의 페이지에 통합하는 방법으로, 간단하게 독립적인 배포가 가능하지만, UI/UX와 보안 문제로 인해 실용성이 떨어짐