MOMSOFT / 기술 블로그
19년 넘게 금융 · 엔터프라이즈 · 모바일 시스템을 만들며 실제로 부딪히고 해결한 것들을 적습니다. 정답을 파는 글이 아니라, 같은 자리에서 고민할 사람에게 판단의 근거를 남기는 글입니다.
Spring · Java
Spring Boot 2에서 3으로, 실제로 시간을 잡아먹는 것들
패키지 이름 치환은 도구가 대신 해 줍니다. 나머지 전부가 진짜 일입니다. 되돌릴 수 있는 단위로 끊어 올리는 순서를 정리했습니다.
N+1 문제를 진짜로 없애는 순서
지연 로딩과 프록시가 만드는 N+1을 측정으로 먼저 드러내고, 전역 배치 페치부터 별도 조회까지 순서대로 걷어내는 판단 기준을 정리했습니다.
QueryDSL로 동적 검색 조건을 안전하게 짜는 법
동적 조건의 기본 단위는 if 블록이 아니라 메서드입니다. null 규약 하나만 팀 규칙으로 고정하면, 조건이 스무 개로 늘어도 검색 코드는 무너지지 않습니다.
@Transactional을 잘못 걸어 생기는 사고들
애너테이션 한 줄은 붙는 순간 끝나는 설정이 아니라, 프록시·커넥션·예외 규칙이 얽힌 계약입니다. 그 계약이 깨지는 지점과 점검 순서를 짚습니다.
Database
PostgreSQL 인덱스가 안 타는 흔한 이유
플랜을 먼저 읽고, 못 쓰는 것인지 안 쓰는 것인지 가른 뒤에 손을 대야 합니다. 진단 없이 추가한 인덱스는 쓰기 비용만 남깁니다.
Redis를 캐시로 쓸 때 실제로 겪는 문제들
캐시는 붙이는 순간이 아니라 만료되고 지워지는 순간에 무너집니다. 스탬피드·TTL·관통·직렬화·무효화를 실무 판단 기준으로 정리했습니다.
대용량 엑셀·PDF 내보내기를 메모리로 죽지 않게 만들기
엑셀 내보내기가 죽는 이유는 대개 POI가 아니라 설계입니다. 조회·문서·전송 세 계층을 각각 스트리밍으로 바꾸는 순서를 정리했습니다.
Frontend
Vue 2에서 3으로 옮기며 실제로 오래 걸린 부분
문법 치환은 목록만 만들면 끝나는 일입니다. 정작 일정을 잡아먹는 건 서드파티 UI 라이브러리, 전역 API에 얽힌 암묵적 결합, 반응성 모델 교체, 그리고 빌드 도구입니다.
파일을 서버에 올리지 않고 브라우저에서 처리한다는 것
이미지·PDF를 클라이언트에서 처리할 때 무엇을 얻고 무엇을 치르는지, 그리고 어디서부터는 여전히 서버로 보내야 하는지 그 경계를 정리합니다.
웹 접근성, 자동 검사로는 절대 안 되는 항목들
자동 검사는 확실히 틀린 것만 잡도록 설계돼 있습니다. 사용자가 실제로 막히는 지점과 인증 심사에서 반복 지적되는 항목은 대부분 그 바깥에 있습니다.
Architecture
모놀리스를 쪼갤 때 현실적인 순서
쪼개는 단위는 코드가 아니라 데이터입니다. 소유권을 먼저 나누고, 모듈형 모놀리스에서 한 번 멈춘 뒤, 운영이 준비된 다음에야 프로세스를 분리하십시오.
로그와 추적을 나중에 붙이면 늦는 이유
장애가 터진 뒤에 로그를 붙이면, 그 장애는 이미 못 봅니다. 관측 장치를 코드와 같이 짜야 하는 이유와, 최소 비용으로 넣는 순서를 정리했습니다.
레거시 재구축에서 데이터 이관이 프로젝트를 잡아먹는 이유
이관은 프로젝트 후반의 배포 작업이 아니라 착수 첫 주에 시작해야 하는 분석 작업입니다. 왜 늘 과소평가되는지, 어떤 순서로 접근해야 하는지 정리했습니다.
Mobile
Flutter로 게임을 만들 때 부딪히는 성능 문제
Flutter로 게임이 안 되는 게 아니라, 앱을 만들던 습관 그대로 게임을 만들면 프레임이 무너집니다. 무엇을 어디까지 내려가서 손볼지 판단하는 기준을 정리합니다.
오프라인 우선 앱을 설계한다는 것
네트워크를 전제에서 끌어내려 부가 기능으로 만드는 설계. 충돌 규칙과 부분 실패, 로컬 스키마 마이그레이션까지 판단 순서로 정리합니다.
CTO · 조직
CTO 대행이 첫 2주에 실제로 하는 일
첫 2주의 산출물은 수정 커밋이 아니라 순서표입니다. 코드보다 먼저 읽는 기록, 인터뷰에서 묻는 질문, 위험도로 줄 세우는 기준을 정리했습니다.
기술 부채를 숫자로 말하는 법
"리팩터링 해야 합니다"는 요청이 아니라 감상입니다. 부채를 이자·원금·리스크 세 숫자로 옮기면 비로소 의사결정의 언어가 됩니다.
외주 개발 계약에서 반드시 정해 두어야 할 것들
분쟁이 나는 지점은 대체로 정해져 있습니다. 계약서에 여섯 문단만 제대로 넣어도 다툼의 절반은 협의로 바뀝니다.
이 블로그를 쓰는 이유
기술 자문과 CTO 대행을 하다 보면 같은 질문을 여러 곳에서 받습니다. "이 마이그레이션 얼마나 걸립니까", "이거 왜 느립니까", "지금 쪼개는 게 맞습니까". 매번 같은 설명을 반복하는 대신, 판단의 근거를 글로 남겨 두기로 했습니다.
그래서 이 글들은 결론만 적지 않습니다. 왜 그렇게 판단했는지, 어떤 조건에서는 반대로 가야 하는지, 무엇을 미리 재 봐야 하는지를 같이 적습니다. 각자의 상황은 다르니 그대로 따라 하시라는 뜻이 아니라, 결정할 때 빠뜨리지 않도록 돕는 목록에 가깝습니다.
도구 사용법을 찾으신다면 도구 활용 가이드 쪽이 맞습니다. 이미지 · PDF · 문서 작업을 다룹니다.