Topic
백엔드 엔지니어링
유지보수 가능한 백엔드 시스템을 위한 애플리케이션 서비스, 프레임워크와 구현 패턴을 다룹니다.
AI 개발 작업을 맥락과 기기, 위험도에 따라 나누기
IDE 검토, 데스크톱 에이전트, 원격 모바일 흐름을 연결하되 맥락의 크기와 검토 필요성, 운영 위험에 따라 작업을 나눕니다.
실제로 검증한 AI 작업 흐름으로 개발 템플릿 바꾸기
반복해서 검증한 AI 작업 흐름에 맞춰 개발 템플릿을 바꾸되, 검증은 명시적으로 남기고 프로젝트별 지침은 공통 기본값과 분리합니다.
파일 URL 대신 스토리지 키를 저장하라
안정적인 스토리지 키와 서버에서 조합하는 주소, 중복 없는 내부 이름, 별도로 보존하는 원본 파일명으로 업로드 구조를 단순화합니다.
AI 생산력과 엔지니어링 생산성은 같지 않다
AI 에이전트가 생산량을 높여도 복잡한 실무에는 맥락, 메모리, 판단, 좋은 동료의 자발적인 사고 확장이 왜 필요한지 살펴봅니다.
AI 버즈워드보다 실제 업무 효용으로 판단하기
유행하는 AI 용어를 좇기보다 실제 업무와 프로젝트에 적용해 보고, 직접 만든 경험으로 효용과 불안을 구분하는 법을 다룹니다.
AI 시대의 프로젝트 구조와 기술 스택 선택 기준
AI의 생성 속도만 보지 말고 팀 규모, 기존 전문성, 리뷰 가능성, 실패 비용에 맞춰 프로젝트 경계와 기술 스택을 고르는 기준을 다룹니다.
AI와 만드는 새 프로젝트의 모듈과 계층 단순화
AI와 새 프로젝트를 만들 때 모듈·인터페이스·계층을 줄이는 가설을 검토하되, 명확성과 품질 및 레거시의 점진적 개선을 지킵니다.
메시지 브로커 없이 회원 탈퇴 후처리 연결하기
작은 서비스에서 도메인별 정리 구현체를 모아 순회하며, 별도 메시징 인프라 없이 회원 탈퇴 흐름과 결합도를 관리하는 방법을 다룹니다.
통 라이브러리를 조합 가능한 의존성 모듈로 쪼개라
전사 통 라이브러리를 서비스가 이해하고 선택할 수 있는 모듈로 나눠 숨은 인프라 연결, 자원 낭비와 의존성 충돌을 막습니다.
앱 하위 호환성을 위한 서버 주도 API 응답 설계
구버전 앱을 위해 변하는 표시 정책과 실험은 서버가 맡되, 변환을 API 경계에 격리해 도메인 모델을 보호합니다.
모든 도메인을 삼키는 어드민 공통 모듈을 피하라
어드민 요구가 도메인 의존성을 뒤집지 않게 서비스 경계를 지키고, 요구가 계속 갈라지는 동안 작은 중복을 허용합니다.
자바 Optional은 데이터 경계에서만 쓰는 이유
값의 부재를 호출자가 실제로 결정해야 하는 반환 경계에서만 Optional을 쓰고 내부 흐름은 명확하게 유지하는 기준입니다.
분산 추적과 안전한 운영 로그를 함께 설계하는 법
서비스 간 요청을 추적하면서 로그 용량, 민감정보 마스킹, 접근 권한과 보관 기간을 함께 설계하는 실무 기준을 다룹니다.
페이징 카운트 쿼리가 데이터베이스를 느리게 하는 이유
정확한 전체 건수가 제한 조회보다 비싼 이유와 슬라이스, 캐시 메타데이터, 추정치 또는 요구사항 변경을 선택할 기준을 설명합니다.
바이브 코딩 시대에도 개발자 판단력이 필요한 이유
AI 코딩을 활용하면서도 문제 정의, 코드 검토, 품질 기준과 결과를 검증할 기술 지식을 지키는 방법을 다룹니다.
계정과 프로필 연결 가능성을 낮추는 익명 설계
식별자 분리, 휘발성 매핑 키, 최소 보관과 계정 복구 제약을 통해 익명 계정 모델의 트레이드오프를 살펴봅니다.
로그인 전 데이터 마스킹을 프레젠테이션 계층에 두는 법
게스트 마스킹과 작성자 표시를 프레젠테이션 경계에 격리해 도메인 로직과 원문 데이터를 보호하는 방법을 설명합니다.
모든 조회를 삼키는 만능 메서드를 목적별로 쪼개라
만능 동적 조회를 목적별 메서드로 나누고 호출부를 점진적으로 옮겨, 리팩터링의 사이드 이펙트를 줄입니다.
목록 좋아요 수는 단순한 조회부터 시작하라
현재 페이지의 좋아요만 제한적으로 조회하고, 카운터 컬럼이나 Redis는 규모가 커져 필요할 때 관리 비용과 함께 검토합니다.
모듈 경계에서 예외를 변환하고 전파하는 법
구현 예외를 소유 모듈 안에 가두고, 상위 계층으로 의존성이 새지 않도록 변환 경계를 설계합니다.
순환 참조를 고치기 전에 도메인 경계부터 바로잡기
인터페이스나 의존성 역전으로 순환 참조처럼 보이는 문제를 다루기 전에 모호한 소유권과 개념 경계를 먼저 정리한다.
널인가 0인가: 코틀린 JPA 엔티티 ID 전략
코틀린 JPA 엔티티의 숫자 ID를 nullable 또는 0으로 둘 때 신규 판별, 모호성, 검증 방법을 비교한다.
한 프로젝트 안에서 실행 역할별 배포 경계 만들기
공개 API, 어드민, 배치, 운영 작업을 실행 앱으로 분리하되 코드가 충분히 성숙하기 전부터 별도 프로젝트로 쪼개지 않는 방법을 설명합니다.
Reader, Finder, Searcher를 행위로 구분하는 법
Reader, Finder, Searcher를 조회 건수가 아니라 직접 읽기, 추가 필터링, 복합 검색이라는 행위로 구분하는 기준을 설명한다.
'마이' 도메인 없이 마이페이지 데이터를 조합하는 법
사용자, 주문, 상품의 책임은 각 도메인에 유지하면서 전용 조합 계층으로 마이페이지 요약 데이터를 만드는 방법을 설명합니다.
'마이'는 왜 도메인이 아닌가
마이페이지는 클라이언트가 보는 화면이지 비즈니스 도메인이 아닙니다. 주문, 상품, 쿠폰은 원래 주인에게 두고 경계에서 조합합니다.
UI 모양을 넘어서는 도메인 모델 설계
트리 모양의 API가 트리 모양의 도메인을 요구하지는 않습니다. 클라이언트 계약은 프레젠테이션 경계에 두고 내부 개념을 조합해 응답합니다.
첫 테스트는 서툴러도 된다, 나중에 리팩터링하라
지키고 싶은 행위를 검증하는 테스트부터 만들고, 실행에 필요한 만큼 목을 쓰며, 반복과 리뷰를 통해 테스트 설계를 개선하는 방법입니다.
API 요청 모델을 핵심 도메인에서 분리하라
프레젠테이션 경계에서 외부 요청을 비즈니스가 소유한 값으로 바꿔 API는 안쪽을 의존하고 코어는 바깥을 모르도록 만드는 방법입니다.
외래키는 규칙이 아니라 운영상의 선택이다
무결성 요구, 장애 대응, 배포 절차, 운영 DB의 주체를 기준으로 외래키와 인덱스, ORM 연관관계를 각각 선택하는 방법입니다.
도메인 간 행위는 책임의 주인에게 맡겨라
호출자 쪽 인터페이스를 모듈 사이에 두기 전에 행위의 주인을 정하고, 호출자가 그 도메인의 기능을 의존하게 만드는 기준을 설명합니다.
열거형의 주인은 누구인가: 도메인 모듈 의존성 설계
비즈니스 열거형은 도메인이 소유하고 스토리지는 안쪽을 의존하게 하며, 경계가 익는 동안에만 작은 공유 열거형 모듈을 두는 방법입니다.
플랫폼 API에서 제공자 식별과 인증 경계를 나누는 법
작은 플랫폼 API가 제공자 키를 도메인 식별자로 바꾸고 데이터를 구분하며, 규모에 맞는 인증 경계를 선택하는 과정을 다룹니다.
도메인 모델을 먼저 보는 보수적인 JPA 연관관계 설계
ID에서 시작하고 생명주기가 실제로 맞을 때만 연관관계를 추가하며, 비즈니스 개념은 엔티티와 독립적으로 표현하는 방법을 다룹니다.
실제 트래픽이 없어도 대용량 시스템 대응은 연습할 수 있습니다
작은 서비스를 직접 운영하고 의도적으로 부하를 만들어 병목을 찾고 고친 과정을 보여주세요. 다만 부하 테스트를 운영 경험이라고 과장해서는 안 됩니다.
공유 테스트 DB 없이 신뢰할 수 있는 데이터베이스 테스트 만들기
잡아야 할 실패에 따라 목, 인메모리 DB, Testcontainers, 실제 DB를 고르고 일반 테스트는 공유 인프라에서 격리합니다.
계층마다 DTO를 습관처럼 만들지 마세요
데이터가 서로 다른 계약을 가진 경계를 넘을 때 DTO를 사용합니다. 매핑에도 비용이 들지만 외부 요청 형태가 서비스 내부를 지배하게 두는 데도 비용이 듭니다.
서킷브레이커는 실패하는 I/O 가까이에 두세요
서킷브레이커, 타임아웃, 캐시 폴백 같은 외부 호출 정책은 I/O 구현체 가까이에 두고, 도메인 코드는 그 결과가 비즈니스에서 무엇을 뜻하는지 결정합니다.
타임아웃은 클라이언트 설정이 아니라 제품의 결정입니다
모든 실패에 같은 재시도 규칙을 붙이지 말고, 사용자가 기다릴 수 있는 시간과 실패 뒤에 알 수 있는 사실을 기준으로 타임아웃과 복구 정책을 설계합니다.
도메인이 성숙하기 전에 모듈부터 나누지 마세요
도메인 성숙도는 정책과 행동, 운영 현실을 얼마나 이해했는지에서 나옵니다. 추측을 일찍 굳히지 말고 운영에서 드러난 책임으로 모듈 경계를 정해야 합니다.
의존성 격차가 프로젝트가 되기 전에 버전 올리기
우선순위에 따라 의존성을 자주 올리면 변경을 작게 유지하고 호환성 문제를 일찍 발견하며 운영 서비스에 부채가 조용히 쌓이는 일을 막을 수 있습니다.
AI 에이전트가 같은 도구를 두 번 호출한다면
분산 시스템과 AI 워크플로에서 재시도는 정상입니다. DB 제약, 멱등 키, 제한된 재시도로 도구 호출의 중복 부작용을 막는 방법을 정리합니다.
그래들 의존성 범위로 아키텍처 경계 세우기
Gradle의 implementation, api, runtimeOnly, compileOnly를 의도적으로 사용해 모듈 접근을 제한하고 우발적인 결합을 막는 방법을 설명합니다.
어드민을 서비스 도메인에서 격리하기
어드민 API는 조회, 수정, 릴리스 위험이 다릅니다. 운영 편의가 핵심 서비스를 바꾸지 않도록 모듈이나 저장소로 격리합니다.
리더와 라이터 컴포넌트로 비즈니스 흐름 드러내기
리더와 라이터는 저장소 세부사항과 변경 범위를 감추고 비즈니스 계층에 정책을 남깁니다. 다만 서비스 수명이 그 비용을 정당화해야 합니다.
분산 서비스 끝까지 하나의 트레이스 아이디 전달하기
민감한 정보를 노출하거나 저장소를 로그로 넘치게 하지 않으면서 HTTP 호출과 비동기 이벤트를 하나의 요청 맥락으로 추적합니다.
유즈케이스 아래 계층에서 코드를 재사용하기
유즈케이스끼리 재사용하면 비즈니스 변경이 번지고 순환 참조가 생깁니다. 위에서 조합하거나 아래의 구현 컴포넌트를 추출합니다.
거대한 서비스 클래스를 책임과 계층으로 분리하는 법
생성자 의존성과 import로 비대해진 서비스를 진단하고, 새로운 아키텍처 이름을 붙이기 전에 응집된 책임부터 분리합니다.
요구사항과 객체 관계로 정규화와 반정규화를 선택하기
정규화 수준을 점수처럼 높이기보다 값의 변경 의미, 조회 비용, 데이터가 보존해야 할 객체 관계를 기준으로 테이블을 설계합니다.