넥스트리

Growing Together, Creating New Days

대규모 임상 데이터 처리와 레거시 연동을 위한 MSA 백엔드 최적화 경험
blog

대규모 임상 데이터 처리와 레거시 연동을 위한 MSA 백엔드 최적화 경험

대규모 임상 데이터 처리와 레거시 연동을 위한 MSA 백엔드 최적화 경험 (AMC PROMs 구축기) 1. 도입 및 기술적 도전 과제 현대 의료의 핵심 패러다임인 '환자 중심 의료(Patient-Centered Care)'를 뒷받침하는 핵심 데이터가 바로 PROMs(환자자기평가결과)입니다. 저는 서울아산병원(AMC) PROMs 플랫폼의 백엔드 개발을 담당하며, 방대한 임상 데이터를
7 min read
Batch와 Event를 활용한 근태 집계 최적화
blog

Batch와 Event를 활용한 근태 집계 최적화

1. 개요: 실시간 집계와 시스템 부하 데브라임 근태 대시보드를 개발하며, 데이터는 일(Day) -> 월(Month) -> 년(Year)으로 데이터가 누적되며 집계되는 구조인데, 하위 데이터가 변할 때마다 상위 지표를 매번 다시 계산하는 것은 리소스 낭비가 꽤 심하다고 생각했습니다. 단순히 기능을 구현하기보다, 비즈니스 로직의 특성에 맞춰 Vizend Tempo
6 min read
MinIO 기반 파일 업로드와 WebP 변환 적용 경험
blog

MinIO 기반 파일 업로드와 WebP 변환 적용 경험

1. 적용 배경과 선택 이유 PROMs 프로젝트에서 환자/의료진이 업로드하는 이미지와 문진 이미지들을 안정적으로 저장할 필요가 있었습니다. 초기에는 단순 파일 저장만 생각했지만, 실제로는 파일 검증, 버킷 분리, 조회 URL 관리, 용량 최적화까지 함께 고려해야 했습니다. 이 과정에서 Object Storage로 MinIO를 사용하고, 이미지 업로드 시 저장 용량을 줄이기 위해 WebP로 변환하여
5 min read
FeignClient 적용 경험을 통한 외부 API 호출 구조 개선
blog

FeignClient 적용 경험을 통한 외부 API 호출 구조 개선

1. 개요 본 문서는 프로젝트 수행 중 외부 서비스와의 통신을 구현하면서 FeignClient를 적용한 경험을 정리한 것이다. 기존 방식에서 발생한 문제를 개선하고, 코드 구조를 단순화한 과정과 그 효과를 중심으로 기술하였다. 2. 도입 배경 초기에는 외부 API 호출을 위해 RestTemplate을 사용하였다. 이 방식은 구현이 직관적이라는 장점이 있었지만, 실제 개발 과정에서는 몇 가지
4 min read
IoT 데이터 처리 플랫폼에서의 InfluxDB 적용 경험
blog

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

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

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

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

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

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

AI Agent 시대의 개발자

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

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

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

Spring WebClient Non-Cache 스트리밍

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

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

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

OpenFeign과 Http Interface

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

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

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

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

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

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

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

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

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

Claude로 PPT 레이아웃 정리하기

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

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

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

Devlime에서 Time zone 설계 경험

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

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

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

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

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

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

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