넥스트리

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

company Pinned Post

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

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

AI로 빨라진 개인, 소화하지 못하는 팀

AI로 빨라진 개인, 소화하지 못하는 팀

- AI 활용으로 코드와 문서 작성은 빨라졌지만, 그것이 곧바로 팀의 진척으로 이어지진 않습니다. 개인의 작업 속도를 팀의 생산성으로 연결하기 위해 갖춰야 할 흡수 역량을 판단 가능성, 추적 가능성, 복구 가능성으로 확인합니다. 처음에는 제가 쓰던 AI 워크플로를 다듬어 팀과 나누면 충분하다고 생각했습니다. 규칙과 커맨드를 정리해 공유하면, 제가 체감한 속도 향상이 팀으로 확장될

MongoDB Online Archive 조회 전략 재설계

MongoDB Online Archive 조회 전략 재설계

1. 문제의 시작: 저장 비용 증가 서비스 운영 기간이 길어질수록 MongoDB 저장 용량 역시 지속적으로 증가하였습니다. 비즈니스 요구사항상 이미 생성된 데이터를 삭제할 수는 없었지만, 모든 데이터를 일반 스토리지에 계속 유지하는 것은 비용 측면에서 부담이 커지고 있었습니다. 특히 Online Archive 적용 대상이 된 특정 컬렉션은 서비스 핵심 데이터를 포함하고 있었으며, 데이터가

JVM Heap 설정과 OOMKilled

JVM Heap 설정과 OOMKilled

1. 개요 본 프로젝트에서는 선박의 센서 데이터 이상치를 감지하여 알람을 발생시키는 기능의 도입이 필요했습니다. 이를 구현하기 위해 선박별 센서 데이터를 조회하고 알람 발생 조건을 탐지한 뒤 알람을 발생시키는 일 배치 로직을 새롭게 개발하였습니다. 이는 개발 환경의 Kubernetes 클러스터에 Pod 형태로 배포된 서비스에서 실행되었고, 하루에 한 번 실행되어 선박별 알람 발생

Loopin 메신저 개발기

1. 서론 (Introduction) 1.1 프로젝트 배경 기존의 오래된 메시징 서비스 구조는 변화하는 웹 환경에 대응하기 어렵고, 유지보수 측면에서 많은 아쉬움이 있었습니다. 본 프로젝트 'Loopin'은 이러한 Smalltalk 시스템을 걷어내고, 최신 Vizend 플랫폼으로 재구축(Refactoring)하는 것을 목표로 시작되었습니다. 메신저 서비스의 핵심 가치는 '사용자 간 단절 없는

DB 스키마 마이그레이션 도구, 어떻게 고를까

DB 스키마 마이그레이션 도구, 어떻게 고를까

MSA·DDD 환경에서 Flyway·Liquibase·Bytebase·Atlas를 비교하고, 상황별로 무엇을 선택할지 정리했습니다. 1. 스키마는 멈추지 않고 바뀐다 DDD와 MSA, 클라우드 네이티브 환경에서 DB 스키마는 고정 자산이 아닙니다. 서비스를 운영하는 내내 계속 바뀝니다. 이유는 도메인에 있습니다. 엔티티와 애그리거트는 도메인 이해가 깊어질수록 함께 변합니다. 속성이 붙고, 한 덩어리였던 개념이 둘로 갈라지고, 컬럼이던

기획부터 테스트까지, 개발 사이클 경험기

기획부터 테스트까지, 개발 사이클 경험기

1. 들어가며 하나의 화면이 사용자에게 전달되기까지는 생각보다 많은 과정을 거칩니다. 기획부터 퍼블리싱 요청, 개발, 테스트까지 하나의 흐름으로 이어집니다. 이번에는 퍼블리싱을 제외한 대부분의 과정을 직접 맡아 진행했습니다. 이 글은 결과물에 대한 소개보다는 그 과정을 돌아보는 기록입니다. 한 사이클을 직접 경험하면서 어떤 고민을 했는지, 어디에서 어려움을 느꼈는지, 그리고 다음에는 무엇을 개선할 수

캐시 전략으로 푼 응답 지연 문제

캐시 전략으로 푼 응답 지연 문제

1. 개요 마이데이터 서비스 운영을 맡으면서 가장 먼저 마주한 과제는 사용자 수가 빠르게 늘어나는 와중에 발생한 메인 화면 응답 지연이었습니다. 서비스 초기에는 큰 문제가 되지 않았던 구조가, 사용자 규모가 커지면서 체감 지연이라는 형태로 표면화되었습니다. 이 글은 당시 문제를 어떻게 진단하고 해결했는지, 그리고 그 해결책이 지금 돌이켜보면 어떤 기술적 흐름과 맞닿아

OpenHTMLtoPDF 적용 경험

OpenHTMLtoPDF 적용 경험

1. 들어가며 프로젝트를 진행하던 중 사용자가 견적서 및 문서 데이터를 PDF 형태로 다운로드할 수 있는 기능이 필요하게 되었습니다. 처음에는 단순히 PDF 파일을 생성하면 될 것이라 생각했지만 실제 검토 과정에서는 여러 고려 사항이 존재했습니다. * 한글 출력 지원 * 레이아웃 수정 편의성 * 라이센스 이슈 * 개발 생산성 * 유지보수성 특히 문서 양식 변경 요청이 자주

MSA 품질관리 CI게이트로 풀어내기

MSA 품질관리 CI게이트로 풀어내기

1. 품질관리체계를 CI에 두기로 한 이유 저는 DevOps 엔지니어 역할로 현재 한 MSA 컨설팅에 참여하고 있습니다. 컨설팅이라고 하면 보통 서비스 경계나 도메인 분리 같은 설계 얘기를 떠올리실 텐데, 제가 맡은 영역은 그쪽이 아닌 품질관리체계였습니다. 이 글은 그 작업에 대한 기록입니다. 품질관리라고 하면 코드 스타일, 정적분석, 테스트 커버리지, 이미지 취약점 스캔

산업용 IoT의 표준, MQTT

산업용 IoT의 표준, MQTT

1. 산업용 IoT와 데이터 수집 최근 제조업 현장에서는 설비 상태 모니터링, 생산 데이터 분석, 원격 관리 등 다양한 목적으로 IoT 기술이 활용되고 있습니다. PLC, 센서, 로봇과 같은 장비들은 지속적으로 데이터를 생성하며, 이러한 데이터를 효과적으로 수집하고 활용하는 것은 스마트 팩토리 구축의 중요한 요소 중 하나입니다. 하지만 산업 현장에는 다양한 제조사의 장비와

ESLint와 Prettier로 코드 스타일 통일하기

ESLint와 Prettier로 코드 스타일 통일하기

1. 배경 이전 글에서 모노레포(Monorepo) 기반의 물리적 구조 설계를 다루었다면, 이번에는 그 위에서 코드를 작성하는 개발자 간 코드 작성 규칙을 통일하는 방법을 이야기해 보려 합니다. 프로젝트 규모가 커질수록 동일한 파일을 여러 개발자가 수정하는 일이 많아졌고, 들여쓰기나 따옴표 스타일 차이로 인한 불필요한 Git diff가 지속적으로 발생했습니다. 이러한 스타일 차이는 단순한

Fixture 기반 테스트 데이터 구성

Fixture 기반 테스트 데이터 구성

1. 들어가며 프로젝트를 진행하다 보면 "테스트 코드를 작성해야 한다"는 것을 알면서도 일정에 쫓겨 미루게 되는 경우가 많습니다. 저 역시 마찬가지였습니다. 백엔드 서비스를 개발하면서, 초기에는 테스트 코드 없이 Insomnia나 화면을 통해 수동으로 기능을 확인하고 있었습니다. 하지만 서비스의 규모가 커지고 도메인 간의 관계가 복잡해지면서, 하나의 기능을 수정할 때 다른

그 많던 토큰은 누가 다 먹었을까

그 많던 토큰은 누가 다 먹었을까

LLM을 업무에 활용하다 보면 처음에는 프롬프트를 얼마나 짧고 명확하게 쓰는지가 가장 중요해 보입니다. 저도 처음에는 토큰을 아끼려면 제가 입력하는 문장을 줄이면 된다고 생각했습니다. 하지만 Codex 같은 에이전트형 개발 도구를 사용하면서 생각이 바뀌었습니다. 실제 토큰 낭비는 사용자가 직접 쓴 문장보다 도구가 반환한 데이터에서 더 크게 발생할 수 있습니다. MCP, 파일 검색,

요구사항, IA, 플로차트 작성

요구사항, IA, 플로차트 작성

1. 들어가며: 기획자는 '화면'이 아닌 '프로세스'를 설계한다 IT 업계에서 서비스 기획자의 역할을 흔히 "스케치를 하고 화면을 그리는 사람"으로 오해하곤 합니다. 디자인 툴을 활용해 버튼을 배치하고 와이어프레임을 만드는 작업이 가장 눈에 띄기 때문입니다. 그러나 시각적인 화면은 기획자가 정의한 수많은 논리와 정책이 최종적으로

설문 관리 서비스 구현 사례

설문 관리 서비스 구현 사례

1. 프로젝트 배경 및 기술 선택 설문 서비스는 환자가 직접 보고하는 결과(PRO, Patient-Reported Outcome)를 다루는 의료 설문 플랫폼의 핵심 서비스로, 설문 서식의 정의부터 발송, 응답 수집, 마감에 이르는 설문의 전 생명주기를 책임집니다. 채점·통계·리포트 가공은 별도의 메트릭 서비스가, 알림·채팅·SMS/이메일의 실제 발송은 별도의 커뮤니케이션

Devlime 재사용 설계로 유지보수성 높이기

Devlime 재사용 설계로 유지보수성 높이기

1. 배경 Devlime 개발은 여러 개발자가 각자의 기능과 도메인을 담당하여 동시에 개발을 진행하는 방식으로 이루어졌습니다. 비젠드(Vizend) 플랫폼을 기반으로 개발되기 때문에 프로젝트 구조나 기본적인 개발 방식은 어느 정도 통일되어 있었으며, 전체적인 아키텍처 역시 잘 정립되어 있었습니다. 그러나 제품 규모가 커지고 기능이 증가하면서 기존 기능을 수정하거나 다른 개발자가 작성한 코드를 분석해야

React Query 캐시 전략에 대한 고찰

React Query 캐시 전략에 대한 고찰

1. 서론: 서버 상태(Server State)는 언제 낡는가 프론트엔드를 운영하다 보면 사용자로부터 반복적으로 듣게 되는 두 가지 제보가 있습니다. 하나는 “방금 등록했는데 목록에 안 보여요”이고, 다른 하나는 그 반대인 “가만히 있었는데 화면이 갑자기 깜빡이며 다시 로딩됐어요”입니다. 언뜻 무관해 보이는 이 두 증상은 사실 같은 뿌리에서 나옵니다. 서버의

Keycloakify의 page_hint 상태 관리 개선

Keycloakify의 page_hint 상태 관리 개선

들어가며 현재 프로젝트에서 Keycloak 기반 로그인과 계정 관련 화면을 맡아 유지보수하고 있습니다. 이번에는 직원 계정 최초 설정 화면에서 새로고침 시 일반 비밀번호 찾기 화면으로 바뀌는 문제를 확인하고 원인을 분석했습니다. 처음에는 일반적인 React SPA처럼 생각해서, 화면을 구분하는 값을 URL 쿼리 파라미터에만 넣어주면 될 것이라고 생각했습니다. 하지만 코드를 따라가 보니 Keycloakify에서는 그

모바일 UI 로 첫 나들이

들어가며 입사 후 계속 웹 화면을 기준으로 디자인을 해왔습니다. 그러다 비젠드 프로젝트에 투입되며 비젠드 디자인 시스템을 기반으로 웹 화면 디자인을 이어갔으며, 1년이 넘는 시간 동안 자연스럽게 웹 중심의 감각이 쌓였습니다. 여백이 얼마나 있어야 숨이 트이는지, 폰트가 몇이어야 읽히는지, 버튼은 어디에 두어야 손이 가는지… 그러다 반장노트 모바일 앱 프로젝트가 새로 시작되며

선언적 폼 바인딩

1. 서론 웹 애플리케이션 개발에서 다이얼로그(Dialog)나 모달 화면을 통한 데이터 수정 폼(Form)을 구현하는 것은 가장 흔하면서도 복잡도가 높은 작업 중 하나입니다. 특히 관리자 페이지나 대시보드의 '콘텐츠 상세 정보 수정 화면'과 같이, 화면이 열리는 시점에 백엔드 API로부터 비동기로 상세 데이터를 조회하여 폼의 초기값으로 바인딩해야

MAT을 활용한 HeapDump 분석

MAT을 활용한 HeapDump 분석

성능 분석의 고전 클래식, Heap Dump K8s 환경에서 프로젝트를 진행하던 도중, 특정 파드가 반복적으로 재시작되는 케이스를 발견했습니다. 파드가 왜 재시작되는지 확인하기 위해 Last State 속성을 살펴본 결과, 원인은 당연하게도 OOM이었습니다. 보통 파드가 이런 식으로 무한 재시작되는 경우는 대부분 OOM Killed가 주 원인이었습니다. 이 상황에서 OOM을 유발한 원인을 찾기 위해, 먼저

싱글톤 패턴을 이용한 캐시 관리

싱글톤 패턴을 이용한 캐시 관리

1. 들어가며 기업용 서비스에서는 사용자별 권한 관리가 매우 중요한 기능 중 하나입니다. 사용자가 로그인한 이후 어떤 메뉴를 조회할 수 있는지, 어떤 기능을 사용할 수 있는지, 어떤 데이터에 접근할 수 있는지는 모두 권한 정보에 의해 결정됩니다. 진행 중인 서비스 역시 사용자 권한에 따라 노출되는 메뉴가 달라지는 구조를 가지고 있었습니다. 관리자는 별도의

putlfAbsent()의 한계와 변경감지 개선

putlfAbsent()의 한계와 변경감지 개선

1. 들어가며 실시간 모니터링 시스템에서는 특정 값에 대한 계산식의 메타 데이터를 여러 서비스 간에 동기화해야하는 경우가 많습니다. 이번 프로젝트에서도 계산식이 생성되거나 변경될 때 이벤트를 발행하여 다른 서비스에 변경 사항을 전달하는 기능이 필요했습니다. 초기 구현에서는 동일한 계산식이 중복 생성되지 않도록 ConcurrentHashMap의 putIfAbsent()를 사용하였습니다. 조건문에 putIfAbsent()를 넣어서 통과한 경우에만 계산식

AI 시대, 디자이너의 '다음'

AI 시대, 디자이너의 '다음'

최근 AI를 활용한 디자인 툴들이 빠르게 발전하면서 디자이너의 역할에 대한 고민도 함께 커지고 있습니다. 예전에는 화면을 직접 설계하고 컴포넌트를 제작하는 것이 디자이너의 핵심 업무였다면, 이제는 AI가 짧은 시간 안에 상당 수준의 UI를 생성해내는 시대가 되었습니다. AI가 점점 그럴듯한 화면을 만드는 것을 보면서 자연스럽게 이런 질문이 떠오를 수밖에 없었습니다. "UI를

Site footer