넥스트리

확신을 설계하고, 가치를 실현하는 넥스트리

company Pinned Post

확신을 설계하고, 가치를 실현하는 넥스트리

다양한 도메인에서 쌓아온 실전 경험을 바탕으로, 고도의 안정성과 무한한 확장성을 동시에 갖춘 시스템 엔지니어링을 제공합니다.

IoT 데이터 처리 플랫폼에서의 InfluxDB 적용 경험

IoT 데이터 처리 플랫폼에서의 InfluxDB 적용 경험

1. 서론 IoT 기반 서비스 개발을 진행하면서 디바이스로부터 주기적으로 수집되는 대량의 데이터를 안정적으로 저장하고, 이를 효율적으로 조회 및 분석할 수 있는 구조가 필요하였다. 수집되는 데이터는 시간(Time)을 기준으로 지속적으로 누적되며, 대부분의 조회 또한 특정 시간 범위를 기반으로 이루어진다. 초기에는 관계형 데이터베이스를 활용하는 방안을 고려하였으나, 데이터의 특성과 조회 패턴을 고려했을

MSA 환경에서 분산 트레이싱 구축기

MSA 환경에서 분산 트레이싱 구축기

OpenTelemetry + Micrometer Tracing 공통 라이브러리 제작 경험 MSA 환경에서는 하나의 요청이 여러 서비스를 거치는 것이 일상적입니다. 문제는 그 과정에서 오류가 발생했을 때인데, 단순 에러 로그만으로는 어느 서비스에서 지연이 생긴 것인지, 어디서 장애가 발생했는지 파악하기가 쉽지 않습니다. 이를 해결하기 위해 비즈니스 로직 전반에 걸친 표준화된 Tracing 체계를 구축하게 되었습니다. 투입 시점이

레거시 설문 엔진의 React 전환 및 데이터 표준화

레거시 설문 엔진의 React 전환 및 데이터 표준화

1. 개요: 플랫폼 구축 과정에서의 기술적 도전 최근 수행한 PROMs 플랫폼 구축 프로젝트의 핵심은 병원 내 산재되어 있던 다양한 환자 보고 결과(PROMs) 서식을 디지털화하고, 이를 표준화된 데이터 체계로 통합하여 임상 및 연구 활용성을 극대화하는 것이었습니다. 이 과정에서 기존 레거시 시스템의 핵심이었던 '설문 및 이벤트 관리 엔진'을

AI Agent 시대의 개발자

AI Agent 시대의 개발자

AI가 두렵지 않은 개발자는 무엇이 다른가? 1. 프롤로그 나무소리 코칭 프로그램의 첫 번째 단계와 원칙은 오랫동안 단순했습니다. 언어는 직접 써야 익혀지고, 숙달은 반복에서 온다는 것입니다. 책과 강의만으로 프로그래밍을 배울 수 없듯, 코드를 직접 작성하고 오류를 경험하는 과정이 개발자의 기본을 다지는 가장 빠른 길이라고 믿었습니다. 이제 그 전제를 재검토하는 시점이 됐습니다.

Claude Code 환경 구성

Claude Code 환경 구성

이번 강의에서는 지난 1강에서 다룬 개념을 바탕으로, 실제 개발 환경에 Claude Code를 구축하는 과정을 상세히 다룹니다. 단순한 명령어 나열이 아닌, 실제 Spring Boot 프로젝트에 적용하며 CLAUDE.md 파일이 생성되는 과정과 프로젝트 구조 분석 원리를 실무 관점에서 설명합니다.

시작-Claude Code

Claude Code에 대한 기본 개념을 학습합니다. 전통적인 개발 방식에 익숙했던 우리가 왜 에이전틱 워크플로우(Agentic Workflow)에 주목해야 하는지, 그리고 현재 가장 강력한 도구 중 하나인 Claude Code에 대해 핵심만 설명합니다.

MSA 기반 대규모 임상 데이터 처리 시스템 구축기

MSA 기반 대규모 임상 데이터 처리 시스템 구축기

현대 의료의 핵심 패러다임인 '환자 중심 의료(Patient-Centered Care)'를 뒷받침하는 핵심 데이터가 바로 PROMs(환자자기평가결과)입니다. 저는 한 기업 PROMs 플랫폼의 백엔드 개발을 담당하며, 방대한 임상 데이터를 안정적으로 수집·분석하고 거대한 병원 코어 시스템(AMIS)과 연동하는 미션을 수행했습니다. 이 과정에서 마주한 인증 한계, 실시간 데이터 시각화

Spring WebClient Non-Cache 스트리밍

Spring WebClient Non-Cache 스트리밍

1. 왜 스트리밍이 필요한가 파일을 외부 저장소(S3, 다른 서버 등)에서 받아 클라이언트에 내려줘야 하는 상황을 먼저 살펴보겠습니다. 전통적인 방식 (Spring MVC + RestTemplate) 클라이언트 ──요청──▶ 우리 서버 ──요청──▶ 외부 서버 │ [파일 전체 수신] [메모리 / 디스크에 적재] │ 클라이언트 ◀──응답── 우리 서버 이 방식에는 세 가지 문제가 있습니다. 1. 메모리 폭발

Java Flight Recorder를 활용한 JVM 자원 분석

Java Flight Recorder를 활용한 JVM 자원 분석

# Grafana 의 대안적 선택 ISS 2.0 프로젝트를 진행하며 한 가지 문제 상황을 겪은 적이 있습니다. 네트워크가 좋지 않은 특정 호선 내 DomainGateway라는 NATS Message(s)를 처리하는 파드가 지속적으로 OOM이 나는 것이었습니다. 애플리케이션이 구동되는 첫 시점에 쌓여있는 Message(s)를 처리하기 위해 순간적으로 부하가 높아진다고 하나, 해당 부하는 낮아지지

OpenFeign과 Http Interface

OpenFeign과 Http Interface

1. WebClient의 불편함과 어려움 과거 외부 API 호출 시 RestTemplate를 사용했었고, 한 기업에서 만나 본 외부 API 호출 코드는 각기 다른 개발자들의 특성이 묻어 있는 다양한 WebClient 코드였습니다. 다양한 반복 코드와 비동기/동기를 넘나드는 복잡함은 코드 분석에 꽤 많은 시간을 소비하게 만들었습니다. 2. 사용하기 쉬운 솔루션 찾기 점점 많아지는 외부

MSA 환경의 데이터 정합성 문제 : Outbox Pattern

MSA 환경의 데이터 정합성 문제 : Outbox Pattern

최근 제가 맡고있는 MSA 기반 서비스에서 발생했던, 데이터 동기화 장애를 어떻게 해결했는지, 그리고 그 과정에서 배운 분산 시스템의 정합성 보장 전략을 공유하고자 합니다. 1. 문제 제가 맡게된 프로젝트에서 주기적으로 이런 문의가 들어오고 있었습니다. “인사 발령이 났는데 여전히 이전 부서로 나와요.” “퇴사자가 임직원 목록에 노출되는 이유가 뭔가요?” 서비스 구조에서 주기적으로 외부

데이터베이스 테이블 파티셔닝 및 인덱스 설정의 중요성

데이터베이스 테이블 파티셔닝 및 인덱스 설정의 중요성

1. 개요 한 기업의 차세대 ISS 프로젝트는 선박 데이터 모니터링과 육상 데이터 모니터링이라는 두 가지 기능으로 구분할 수 있다. 선박에서 수집된 센서 데이터는 1초, 10초, 1분 등 다양한 주기를 갖는 데이터로 전환되어 선박 데이터베이스에 저장된다. 이러한 선박 데이터는 육상으로도 전송되어 육상 데이터베이스에 저장되는데, 그중 1분 데이터는 history_minute 라는 테이블에

연결보다 중요한 것은 종료다 — TCP 4-way handshake가 중요한 이유

연결보다 중요한 것은 종료다 — TCP 4-way handshake가 중요한 이유

TCP/IP 통신을 이야기할 때 우리는 보통 3-way handshake를 통해 연결의 신뢰성을 확보하는 과정에 집중한다. 하지만 실제 서비스 환경에서는 연결보다 더 중요한 것이 있다. 바로 연결을 어떻게 종료하고 자원을 회수하느냐다. TCP 연결은 단순한 데이터 통신을 넘어, 소켓, 버퍼, 커널 리소스 등 다양한 시스템 자원을 점유하는 상태를 의미한다. 따라서 연결이 제대로

MSA 도메인 구조 기반 리팩터링 및 시스템 통합

MSA 도메인 구조 기반 리팩터링 및 시스템 통합

1. 프로젝트 개요 및 목표 해당 과제는 기존에 자사가 지향하는 개발 방향 및 표준 솔루션 구조와 어긋난 형태로 개발된 특정 파트의 메뉴들을 전면 리팩터링하는 작업이었습니다. 주요 목표는 레거시 코드를 분석하여 우리 회사의 솔루션 구조 및 MSA 환경에 최적화된 구조로 재설계하고, 전체 시스템에 안정적으로 통합하는 것이었습니다. 2. 기존 아키텍처의 문제점 및

Claude로 PPT 레이아웃 정리하기

Claude로 PPT 레이아웃 정리하기

— 워크플로우 설계부터 트러블슈팅까지 — 1. 왜 AI로 슬라이드 작업을 시도했는가 프로젝트를 진행하면서 기존 슬라이드 자료를 새로운 디자인 템플릿에 맞게 재구성해야 하는 작업이 발생했다. 수십 장의 슬라이드를 수작업으로 하나하나 정리하는 것은 상당한 시간과 노력이 필요했고, 반복적인 레이아웃 조정 작업에서 비효율을 느꼈다. 이를 해결하기 위해 AI를 활용한 슬라이드 정리 자동화를 시도하게 되었다. 단순히

Shared Ubiquitous 라이브러리 환경 분리 적용기

Shared Ubiquitous 라이브러리 환경 분리 적용기

1. Shared Ubiquitous의 환경 간 간섭과 운영 리스크 제가 담당한 시스템은 MSA 구조로 이루어져 공통 도메인이나 유틸리티성 로직을 ‘Shared Ubiquitous’라는 라이브러리로 묶어 여러 서비스에서 공유해왔습니다. 문제는 이 라이브러리가 개발계와 운영계 구분 없이 동일한 버전을 바라보고 있었다는 점입니다. 개발 단계에서 기능을 수정하고 테스트를 위해 Nexus에 스냅샷이나 새 버전을 올리면, 같은

Devlime에서 Time zone 설계 경험

Devlime에서 Time zone 설계 경험

1. 배경 Devlime의 개발 목적 중 하나는 시간과 장소에 제약 없이 협업이 가능한 글로벌 개발 환경을 구축하는 것입니다. 이에 따라 다국어 및 Time zone 도입을 포함한 글로벌 환경 구축을 담당하게 되었으며, 여러 국가의 사용자가 동일한 시스템에서 함께 작업할 수 있도록 하는 것이 목표였습니다. 초기 시스템은 모든 시간을 UTC 기준으로 저장하거나,

실시간 채팅 시스템 및 알림의 멀티 인스턴스 문제, Redis Pub/Sub으로 해결하기

실시간 채팅 시스템 및 알림의 멀티 인스턴스 문제, Redis Pub/Sub으로 해결하기

Communication 서비스 · WebSocket + STOMP + Redis 1. 들어가며 — 문제는 서버가 늘어나면서 시작됐다 Communication 서비스는 의료진과 환자 간 실시간 채팅을 WebSocket + STOMP로 처리한다. 개발 초기, 서버가 1대일 때는 모든 게 정상이었다. 메시지를 보내면 상대방이 받았고, 읽음 처리도 즉각 반영됐다. 문제는 서버를 2대 이상으로 늘리면서 발생했다. 서로 다른 서버에 연결된 사용자 사이에서 메시지가

마이크로 프론트엔드(Micro-Frontend, MFE) 도입 전략

마이크로 프론트엔드(Micro-Frontend, MFE) 도입 전략

1. 마이크로 프론트엔드(Micro-Frontend, MFE)의 이해 마이크로 프론트엔드는 백엔드의 마이크로서비스 아키텍처(MSA) 개념을 프론트엔드로 확장한 패러다임입니다. 거대하고 복잡한 하나의 프론트엔드 애플리케이션을 더 작고 독립적으로 배포 가능한 여러 개의 애플리케이션으로 분할하여 조립하는 방식입니다. 주요 특징 * 독립적인 배포 (Independent Deployment): 특정 기능이나 메뉴를 수정했을 때 전체 애플리케이션을 다시 빌드하고 배포할 필요

이벤트 및 스케줄링 기반의 CQRS 패턴을 활용한 데이터 집계 최적화

이벤트 및 스케줄링 기반의 CQRS 패턴을 활용한 데이터 집계 최적화

서론: 런타임 재집계의 한계와 능동적 데이터 축적의 필요성 이전의 프로젝트에서는 대량의 데이터를 조회할 때마다 실시간으로 전체 재집계를 수행하는 방식을 주로 사용해 왔습니다. 이러한 방식은 데이터 소스가 늘어날수록 쿼리 연산 부하를 증가시켰고, 결과적으로 시스템 전체의 응답 속도를 저하시키는 고질적인 성능 병목의 원인이 되었습니다. 본 프로젝트에서는 이러한 구조적 한계를 극복하고자 팀 내

Flyway 사용 중 마주한 문제와 해결 과정

Flyway 사용 중 마주한 문제와 해결 과정

1. Flyway 사용 배경 프로젝트를 진행하다 보면 데이터베이스 스키마 변경은 필연적으로 발생한다. 그러나 수동 SQL 관리나 환경별 개별 반영 방식으로 인해 환경 간 스키마 불일치, 변경 이력 추적의 어려움, 각종 휴먼 에러와 같은 문제가 발생하곤 한다. 이러한 문제를 해결하기 위해 Tenant 팀에서는 데이터베이스 변경 이력을 체계적으로 관리할 수 있는 Migration

MongoDB 트랜잭션 타임아웃 해결을 위한 프로세스 구조 개선

MongoDB 트랜잭션 타임아웃 해결을 위한 프로세스 구조 개선

1. 개요 프로젝트 수행 중 대용량 데이터를 처리하는 배치 프로세스에서 발생한 트랜잭션 장애를 해결하기 위해 처리 구조를 개선한 경험을 정리하였습니다. 무거운 연산 작업이 포함된 트랜잭션의 기술적 제약을 파악하고, 이를 극복하기 위해 선택한 지연 변환 방식의 적용 과정을 공유하고자 합니다. 2. 배경 초기 설계와 달리 고도화 과정에서 요구사항이 변화함에 따라 배치

SpreadJS 엑셀 로딩 성능 최적화

SpreadJS 엑셀 로딩 성능 최적화

1. 문제의 시작: 파일을 읽었는데, 왜 브라우저가 멈추지? SpreadJS를 이용해 엑셀 파일을 임포트 하는 과정에서, 파일 크기는 약 680KB로 크지 않았음에도 불구하고 브라우저가 멈추는(Freezing) 현상이 발생했습니다. 초기에는 단순히 데이터 양이 많아서 발생하는 문제로 추측했지만, 실제 데이터는 100행 수준이었습니다. 문제의 원인은 엑셀의 사용 범위에 있었습니다. * 실제 데이터: 약 100행 * 엑셀

[Troubleshooting] Jackson 2.15+ 대용량 JSON 처리 시 StreamConstraintsException 해결기

[Troubleshooting] Jackson 2.15+ 대용량 JSON 처리 시 StreamConstraintsException 해결기

1. 문제 배경 최근 프로젝트에서 메일 발송 기능을 구현하던 중, Base64로 인코딩한 이미지 데이터가 포함된 대용량 JSON을 처리하던 중 아래와 같은 예외를 마주했습니다. com.fasterxml.jackson.core.exc.StreamConstraintsException: String value length (20032631) exceeds the maximum allowed (20000000, from StreamReadConstraints.getMaxStringLength()) 2. 원인 분석 원인은 Jackson 2.15 버전부터 도입된