넥스트리

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

company Pinned Post

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

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

MultiDatasource·Prologue로 Pod·JVM 비용 절감

MultiDatasource·Prologue로 Pod·JVM 비용 절감

서비스 경계를 유지한 통합 백엔드 설계와 공통 자동 구성 승격 과정 1. 들어가며 마이크로서비스가 늘어나면 비즈니스 기능만 늘어나는 것이 아닙니다. 서비스마다 Pod와 JVM이 필요하고, 각 JVM 안에는 Spring Context, thread pool, connection pool이 만들어집니다. 배포 대상과 모니터링 대상도 서비스 수에 비례하여 증가합니다. 트래픽이 많지 않은 서비스까지 독립 실행 단위로 유지하면

모바일 앱 QA, 어디서 어떻게 검증해야 할까

모바일 앱 QA, 어디서 어떻게 검증해야 할까

QA는 왜 실제 디바이스에서 해야할까? TestFlight 실기기 검수 사례와 앱 출시 전후 QA 운영 전략 1. QA는 화면의 차이를 찾는 것으로 끝나지 않는다. 디자인 QA는 흔히 Figma와 개발 결과물을 나란히 놓고 폰트, 간격, 색상, 버튼 크기를 확인하는 일로 이해됩니다. 이 검수는 필요하지만 충분하지 않습니다. 디자인 의도가 사용자에게 전달되려면 화면이 정확히

모던 백엔드 - Spring Boot 4.0 개관(2)

모던 백엔드 - Spring Boot 4.0 개관(2)

[Modern Backend] 강좌의 Part 2 10강의 두 번째 시간, "Spring Boot 4.0 개관(2)" 기술적 과제 및 신규 기능 편입니다. 이번 강의에서는 Spring Boot 4.0으로의 마이그레이션 과정에서 실무 개발자가 반드시 직면하게 되는 Jackson 3 전환, JSpecify 기반 널(Null) 안전성 표준화, 차세대 HTTP 클라이언트와 내장 회복탄력성,

모던 백엔드 - Spring Boot 4.0 개관(1)

모던 백엔드 - Spring Boot 4.0 개관(1)

[Modern Backend] 강좌의 Part 2 첫 번째 시간, "Spring Boot 4.0 개관 (1)" 이론 및 리스크 분석 편입니다. 이번 강의에서는 기존 Spring Boot 3.x 환경에서 차세대 메이저 버전인 Spring Boot 4.0으로 전환해야 하는 당위성과, 5대 핵심 베이스라인의 동시 격상에 따른 생태계 변화 및 사전에 파악해야

모던 백엔드 - 신규 문법 적용 리팩토링

모던 백엔드 - 신규 문법 적용 리팩토링

[Modern Backend] 강좌의 Part 1 마지막 시간, "신규 문법 적용 리팩토링" 실습 강의입니다. 이번 강의에서는 앞선 8강에서 다루었던 Java 25의 신규 기능들 중 실제 코드에 직접 반영할 수 있는 두 가지 핵심 문법인 모듈 임포트(Module Import)와 유연한 생성자 본문(Flexible Constructor Bodies)을 게시판 실습 프로젝트에

모던 백엔드 - 문법 & 성능 개선(2)

모던 백엔드 - 문법 & 성능 개선(2)

[Modern Backend] 강좌의 Part 1 여덟 번째 시간의 두 번째 강의, "문법 & 성능 개선 (2)" 이론 및 원리 편입니다. 이번 강의에서는 Java 25의 유연한 생성자 본문(Flexible Constructor Bodies)이 동작하는 엄격한 규칙과 초기화 순서, 그리고 컴팩트 객체 헤더(Compact Object Headers) 설정 및 Java 25 성능

모던 백엔드- 문법 & 성능 개선(1)

모던 백엔드- 문법 & 성능 개선(1)

[Modern Backend] 강좌의 Part 1 여덟 번째 시간의 첫 번째 강의, "문법 & 성능 개선 (1)" 입니다. 이번 강의에서는 Java 25에서 정식 채택 및 개선된 핵심 언어 문법 기능들과 HotSpot JVM의 주요 성능 최적화 요소들을 살펴봅니다. 📌 주요 학습 내용: * 유연한 생성자 본문 (Flexible Constructor Bodies, JEP 513): super(

모던 백엔드 - 컨텍스트 전파 리팩토링(3)

모던 백엔드 - 컨텍스트 전파 리팩토링(3)

[Modern Backend] 강좌의 Part 1 일곱 번째 시간의 세 번째 강의, "컨텍스트 전파 리팩토링 (3)" 실습 편입니다. 이번 강의에서는 앞서 6강과 7강에서 학습한 설계 이론을 바탕으로, 게시판 실습 프로젝트의 기존 ThreadLocal 코드를 Java 25의 범위값(Scoped Value)으로 직접 전환하는 라이브 코딩 실습을 진행합니다. 📌 주요 학습 내용: * 1단계:

모던 백엔드 - 컨텍스트 전파 리팩토링(2)

모던 백엔드 - 컨텍스트 전파 리팩토링(2)

[Modern Backend] 강좌의 Part 1 일곱 번째 시간의 두 번째 강의, "컨텍스트 전파 리팩토링 (2)"입니다. 이번 강의에서는 게시판 프로젝트의 병렬 실행 구간(StructuredTaskScope)에서 ScopedValue의 자동 상속 메커니즘을 적용하고, 비동기 경계별 바인딩 패턴과 사이드 이펙트 없는 리팩토링 전략을 다룹니다. 📌 주요 학습 내용: * 병렬 실행 구간에서 fork() 호출

Naver Cloud에서 IaC 기반 Managed Platform 구축하기

Naver Cloud에서 IaC 기반 Managed Platform 구축하기

요즘 인프라를 이야기할 때 “IaC(Infrastructure as Code)”라는 말은 너무 익숙합니다. Terraform으로 클라우드 리소스를 만들고, Ansible로 서버 설정을 자동화하고, Kubernetes와 GitOps로 애플리케이션 배포를 관리하는 방식은 이제 특별한 기술이라기보다 운영의 기본기에 가까워졌습니다. 그런데 실제 운영 환경을 구성해보면, IaC는 단순히 “코드로 인프라를 만든다”는 수준에서 끝나지 않습니다. 오히려 중요한 질문은 그다음부터

MongoDB 클러스터 연결 장애와 설정 개선

MongoDB 클러스터 연결 장애와 설정 개선

이번 사례는 AWS EKS 배포와 MongoDB Atlas 버전 업그레이드가 겹치면서 발생한 장애를 바탕으로, 클러스터 환경의 MongoDB 접속 설정을 점검한 내용입니다. 1. 예상하지 못한 장애 발생 MongoDB Atlas를 사용하는 시스템을 AWS EKS에 배포하던 중 일부 MongoDB 클러스터의 연결이 완료되지 않아 신규 WAS가 정상 기동하지 못했습니다. 즉시 오류가 발생해 프로세스가 종료된 것도

AI와 배포 점검 같이 하기

AI와 배포 점검 같이 하기

1. 배경 Devlime은 개발·스테이지·운영 세 환경으로 운영하고, 이를 관리하는 gitops 저장소는 둘입니다. 어느 환경으로 올리든 배포 앞뒤에는 같은 점검이 붙습니다. 이번에 무엇이 올라가는지, DB 반영 사항이 있는지와 그것이 가이드대로 작성됐는지, 서비스끼리 참조하는 라이브러리 버전이 어긋나지 않았는지, 미커밋·미푸시가 없는지 등을 확인하는 일입니다. 점검이 끝나면 반영 내역을 정리합니다. 스테이지에

끊기는 선육 간 네트워크에서 데이터 신뢰성 지키기

끊기는 선육 간 네트워크에서 데이터 신뢰성 지키기

스마트쉽 솔루션(이하 SS) 데이터 정합성 관리 – 누락 감지부터 복구, 검증, 이상 데이터 탐지까지 선박에서는 IAS, VDR, ACONIS를 비롯한 다양한 장비에서 항해·기관·설비 데이터가 지속적으로 생성됩니다. SS는 이러한 데이터를 선상에서 수집하고 표준화·가공한 뒤 기계류 관리, 항해 관리, 선박 관리 등의 서비스에서 활용하고, 필요한 데이터를 육상으로 전달하는 선상–육상

Jev를 이용하여 AI를 보다 똑똑하게 사용하자

Jev를 이용하여 AI를 보다 똑똑하게 사용하자

서론: 우리는 LLM을 너무 많이 사용하고 있는 것은 아닐까요? 최근 몇 년간 AI 애플리케이션 개발은 사실상 LLM(Large Language Model)을 중심으로 이루어져 왔습니다. 사용자가 질문하면 LLM에게 보내고, 문서를 분석할 때도 LLM에게 보내고, 이메일을 분류할 때도 LLM에게 보내며, Agent가 다음 행동을 결정할 때도 다시 LLM에게 물어봅니다. LLM은 매우 강력합니다. 자연어를

에이전트 플로우를 개선하며 배운 것들

에이전트 플로우를 개선하며 배운 것들

들어가며 AI 코딩 에이전트를 업무에 사용하기로 한 일은 도구 하나를 설치하는 일이 아니었습니다. 업무 방식 자체를 다시 정해야 하는 일이었습니다. 처음에는 프롬프트나 스킬만 잘 쓰면 될 거라고 생각했습니다. 하지만 몇 달이 지나고 보니 실제로 남은 것은 프롬프트가 아니었습니다. 규칙 문서와 실패 기록, 실패를 규칙으로 바꾸는 반복적인 절차였습니다. 이 글에서는 제가

POI에서 DsExcel로: SpreadJS 연동 가이드

POI에서 DsExcel로: SpreadJS 연동 가이드

1. 들어가며: 왜 다시 '엑셀(Excel)'인가? 기업용 엔터프라이즈 솔루션 개발에서 가장 흔하면서도 까다로운 요구사항 중 하나는 단연 **'엑셀(Excel) 처리'**입니다. 실무 현장의 사용자들은 웹 화면에서 화려한 대시보드를 보는 것에 그치지 않고, 복잡한 다중 헤더 그리드 데이터를 조회하고, 그룹별 트리 구조로 서식이 지정된 템플릿을 다운로드

UI 딜레마 규칙과 유연 사이

UI 딜레마 규칙과 유연 사이

디자인을 하다 보면 정해진 답이 없어서 결정하기 어려운 순간들을 자주 마주하곤 합니다. “이건 고정값으로 하는 게 좋을까?” “콘텐츠에 따라 유동적으로 만드는 게 좋을까?” 간단한 결정 사항처럼 보이지만, 막상 작업하다 보면 하나를 선택하기가 쉽지 않습니다. 사이즈를 고정하면 전체적으로 깔끔하고 일관성 있어 보이지만 어떤 콘텐츠가 들어오느냐에 따라 답답하거나 여백이 많을 수 있고,

애자일 12원칙과 SI 프로젝트에 적용하는 방법

애자일 12원칙과 SI 프로젝트에 적용하는 방법

-애자일은 단순히 ’빠르게 개발하는 방법’이 아니다- 소프트웨어 개발 현장에서 ’애자일(Agile)’이라는 말을 흔히 들을 수 있습니다. 하지만 애자일을 단순히 “개발을 빨리 하는 것” “스프린트를 2주 단위로 돌리는 것” “매일 아침 데일리 미팅을 하는 것” 정도로 이해하면 애자일의 핵심을 놓치기 쉽습니다. 애자일의 출발점은 2001년 발표된 애자일 소프트웨어 개발 선언(

롤만으로는 부족할 때: ReBAC와 SpiceDB

롤만으로는 부족할 때: ReBAC와 SpiceDB

1. 들어가며: 롤만으로 감당이 안 되는 순간 데브라임에선 권한 처리는 이렇게 시작합니다. @AuthorizedRole(roles = { ScrumRoles.ROLE_PROJECT_MANAGER, ScrumRoles.ROLE_PROJECT_MEMBER }) public class FindProductProjFetch extends FetchRequest<ProductRdo> { "프로젝트 관리자와 프로젝트 멤버만 이 API를 호출할 수 있다." 명확하고, 읽기 쉽고, 대부분의 경우 이걸로 충분합니다. 데브라임 전반에서

Vue.js와 React.js의 사용 경험 비교

Vue.js와 React.js의 사용 경험 비교

1.React와 뷰: 프론트엔드의 양대 산맥 최근 1년 넘게 react 환경에서 개발을 진행해오다, 최근에 뷰를 사용하는 프로젝트를 하게 되어 vue라는 프론트엔드 프레임워크를 알게 되었습니다. 기존에도 vue가 react보다 더 쉽다는 말을 자주 들었기에 배우는 데에는 거부감이 없었던 것 같습니다. vue 공식 문서를 보면서 react와는 다른 매력을 느끼게 되었고, 비록 인기도에 있어서

MCP 서버와 에이전트 호스트, 왜 둘로 나누었는가

MCP 서버와 에이전트 호스트, 왜 둘로 나누었는가

“하나로 만들면 프로젝트가 하나 줄 텐데”라고 생각했던 순간부터, 실제 문제 해결은 시작되었습니다. 사내 플랫폼에 자연어로 서비스를 조작할 수 있는 AI 에이전트를 붙이기로 하였습니다. 그런데 첫 질문은 “무엇을 만들 것인가”가 아니라 “무엇을 몇 개 만들 것인가”였습니다. 대화 UI를 기존 서비스 화면 안에 두기로 했으니, MCP 서버와 에이전트 호스트를

Fabric8로 서비스별 Pod 상태 조회하기

Fabric8로 서비스별 Pod 상태 조회하기

-Spring Boot 4.1.0 · Java 25 · Fabric8 Kubernetes Client 7.1.0- 현대의 많은 백엔드 시스템은 Kubernetes 위에서 운영되며, 서비스 상태 점검을 위한 Pod 조회는 매우 빈번하게 발생합니다. 지금까지는 운영자(또는 개발 담당자)가 서버에 접속해 kubectl 명령어를 직접 입력하는 방식으로 처리해 왔지만, 운영 규모가 커질수록 이 방식은 여러

Nexus Repository

Nexus Repository

들어가며 Nexus Repository란 무엇인가 한 문장으로 말하면 사내 공용 부품 창고입니다. 개발할 때 쓰는 라이브러리, 패키지, 도커 이미지 같은 것들을 한곳에 모아두고 필요할 때 꺼내 쓰도록 관리해 주는 서버입니다. 지금은 개발자들이 각자 인터넷에서 필요한 것을 내려받습니다. 같은 라이브러리를 스무 명이 스무 번 받고, 외부 사이트가 잠깐 멈추면 모두의 빌드가 함께

코드 생성에서 개발 라이프사이클 전체를 AX로

코드 생성에서 개발 라이프사이클 전체를 AX로

-AI 코딩에서 테스트·운영까지, 개발 프로세스는 어떻게 바뀌어야 할까- 1. AI에게 코딩을 맡기는 방식이 달라졌다 AI를 개발에 본격적으로 사용하게 된 지 불과 몇 달 만에 직접 코드를 작성하는 경우가 거의 없어졌습니다. 처음에는 필요한 기능을 설명하고 코드를 만들어달라고 하는 정도였으나, 지금은 AI와 개발 목표를 계획하고 상세 계획을 세운 뒤 구현과 검증까지

Site footer