리더와 라이터는 아키텍처 규칙이 아니라 선택지다
리더·라이터와 도구 계층을 모방이 아니라 코드 규모, 도메인 거리, 레거시 제약, 팀 규칙에 따라 선택하는 기준을 설명한다.
Articles
생각과 경험을 기록합니다.
공통 모듈의 함정: 구체적인 기능으로 코드를 응집하라
소유권이 드러날 때까지 공통 모듈을 늦추고, 로깅·예외·공유 규격을 구체적인 기능과 책임 중심으로 묶는 방법을 다룬다.
바꾸기 전에 먼저 팀의 사람이 되어라
제때 묻고 진행 상황을 공유하며 빠르게 리뷰받고, 신뢰를 쌓은 뒤 근거 있는 작은 변화로 새 개발팀에 적응하는 방법을 다룬다.
거대한 서비스 클래스를 책임 단위로 나누는 법
개념 지도, 책임의 흐름, 테스트 경계, 구체적인 리팩터링 대안을 통해 비대해진 서비스 클래스를 나누는 방법을 설명한다.
운영 테이블을 지키는 별도 조회 모델 설계
운영 테이블은 비즈니스 개념에 맞게 설계하고, 복잡한 이력·어드민 검색은 별도 조회 모델에서 제공하는 방법을 다룬다.
열거형인가 코드 테이블인가: 변화 주기로 결정하라
안정적인 값은 열거형으로, 자주 바뀌는 데이터는 전용 테이블로 관리해 공통 코드 테이블이 잡동사니 저장소가 되는 일을 막는다.
하나의 DB에서도 도메인별 데이터 접근 경계를 나누는 법
같은 DB 테이블을 쓰더라도 엔티티와 저장소 경계를 나눠 외부 연동 코드로부터 핵심 규칙을 보호하는 방법을 설명한다.
덮어쓰지 말고 쌓아라: 불변 운영 데이터 설계
이력을 선명하게 하고 동기화를 단순화하는 추가 전용 상환 데이터 구조와, 그 대신 늘어나는 저장 및 조회 비용을 살펴본다.
관리비 고지서에서 연체 도메인을 발견한 순간
평범한 고지서에서 상환 모델의 빠진 개념을 발견하고, 현실의 단서를 검증 가능한 소프트웨어 경계로 바꾸는 과정을 살펴본다.
설계 자원을 쓰기 전에 핵심 개념의 우선순위를 정하라
1급 도메인 개념을 찾고 보조 흐름을 분리해, 제한된 설계 시간을 변화의 중심에 쓰는 실용적인 방법을 설명한다.
경험과 반복이 지속 성장하는 개발자를 만든다
다양한 실전 경험과 실패의 반복, 비즈니스 제약에 대한 관심이 낯선 운영 문제를 푸는 개발자를 만드는 과정을 살펴본다.
순환 참조를 고치기 전에 도메인 경계부터 바로잡기
인터페이스나 의존성 역전으로 순환 참조처럼 보이는 문제를 다루기 전에 모호한 소유권과 개념 경계를 먼저 정리한다.
코어를 깨끗하게 지키는 의도적인 오염 경계
피할 수 없는 복잡성을 명시적인 외부 경계에 가두고, 제한된 개발 시간을 시스템의 핵심 개념에 쓰는 방법을 다룬다.
널인가 0인가: 코틀린 JPA 엔티티 ID 전략
코틀린 JPA 엔티티의 숫자 ID를 nullable 또는 0으로 둘 때 신규 판별, 모호성, 검증 방법을 비교한다.
CS 지식은 실무 문제를 해결할 때 역량이 된다
실제 엔지니어링 문제를 통해 CS를 배우고, 그 지식으로 업무를 어떻게 판단하고 개선했는지 보여 주는 방법을 다룬다.
사람이 이해하고 빌드가 지키는 레이어 규칙
안정적인 레이어 역할과 선택적 상위 레이어의 조건을 정의하고, 필요할 때만 자동 검증으로 규칙을 강제하는 방법을 다룬다.
운영 이슈를 팀의 공통 도메인 지식으로 바꾸는 법
운영 이슈 리뷰, 작업 기록, 개념도, 운영 교대를 활용해 소프트웨어 팀의 도메인 지식 격차를 줄이는 방법을 다룬다.
한 프로젝트 안에서 실행 역할별 배포 경계 만들기
공개 API, 어드민, 배치, 운영 작업을 실행 앱으로 분리하되 코드가 충분히 성숙하기 전부터 별도 프로젝트로 쪼개지 않는 방법을 설명합니다.
Reader, Finder, Searcher를 행위로 구분하는 법
Reader, Finder, Searcher를 조회 건수가 아니라 직접 읽기, 추가 필터링, 복합 검색이라는 행위로 구분하는 기준을 설명한다.
아웃박스 폴링을 바꾸기 전에 측정하라
현실적인 부하로 아웃박스 폴링을 검증하고, 로그 테일링을 도입하기 전에 더 단순한 애플리케이션 전달 방식을 검토한다.
비즈니스 흐름이 보이는 곳에서 이벤트 발행하기
완료된 비즈니스 행위를 이해하는 계층에서 이벤트를 발행하되, 구현과 밀접한 예외는 명시적으로 구분하는 방법을 다룬다.
'마이' 도메인 없이 마이페이지 데이터를 조합하는 법
사용자, 주문, 상품의 책임은 각 도메인에 유지하면서 전용 조합 계층으로 마이페이지 요약 데이터를 만드는 방법을 설명합니다.
모듈, 레이어, 아키텍처는 서로 다른 결정이다
모듈 경계와 코드 레벨의 레이어, 아키텍처를 구분하고 구현에 더 강한 제약이 필요할 때만 모듈을 추출하는 기준을 다룬다.
추상화는 구현 뒤에 온다: Service와 Impl 관행 다시 보기
구체적인 구현에서 검증된 공통점을 추출하고, 구현체가 하나여도 실제 경계를 만드는 인터페이스만 남기는 설계 기준을 다룬다.
헥사고날 아키텍처를 선택하기 전에 물어야 할 것
프로토콜, 격리, 규모, 성장 가능성이 추가 구조를 정당화할 때 헥사고날 아키텍처를 선택해야 한다. 유행이나 역량의 표식은 근거가 아니다.
DB 변경 쿼리를 작업과 배포 단위로 추적하기
DB 변경을 해당 이슈와 PR에 모아 개발 환경에서 검증하고, 코드 배포 전에 릴리스에 필요한 최종 쿼리만 전달한다.
불필요한 조회 없이 권한 검증을 설계하는 법
로그인 사용자를 한 번만 확인하고 접근 검증의 책임을 좁히며, 시스템 관리자와 채널 단위 권한을 구분하는 설계.
코어 책임과 대리키로 변경에 대비하기
공유 등록 규칙을 코어에 모으고 필요할 때만 격리를 강화하며, 바뀔 수 있는 비즈니스 유일성은 기본키와 분리하는 설계를 다룬다.
'마이'는 왜 도메인이 아닌가
마이페이지는 클라이언트가 보는 화면이지 비즈니스 도메인이 아닙니다. 주문, 상품, 쿠폰은 원래 주인에게 두고 경계에서 조합합니다.
배포되기 전까지 개발은 끝나지 않는다
묵은 PR과 늦어진 배포는 리뷰, 진단, 롤백을 어렵게 만든다. 운영 반영까지의 간격을 줄이고 관찰 가능한 상태로 관리하는 법을 다룬다.
공통 집계와 사용자별 캐시 상태를 분리하라
리액션 상태를 재사용 가능한 조회로 조합하고, 한 회원의 개인 상태가 모두에게 노출되지 않도록 공통 합계만 분리해 캐시한다.
거듭된 실패가 가르쳐 준 개발자 커리어의 기준
실패를 다음 기회의 검증 기준으로 바꾸고, 신뢰할 수 있는 추천을 활용하며, 과거의 규칙도 새 경험 앞에서 다시 고치는 법을 다룬다.
회원과 비회원을 함께 다루는 조회 모델
공개 리액션 수와 회원별 상태를 하나의 조회 흐름으로 반환하되, 선택적 사용자 정보와 필수 인증의 경계는 분명히 나눈다.
재개발에서는 새 구조를 먼저 설계하라
재개발의 목적에 맞춰 새 시스템을 먼저 설계하고, 레거시 데이터는 명시적인 매핑과 폐기 조건을 둔 전환 계층으로 옮긴다.
요구사항과 규모에서 시작하는 리액션 기능 설계
모호한 좋아요 요구를 정책으로 구체화하고, 데이터 증가량과 조회 비용을 계산해 리액션 모델과 변경 시점을 설계한다.
UI 모양을 넘어서는 도메인 모델 설계
트리 모양의 API가 트리 모양의 도메인을 요구하지는 않습니다. 클라이언트 계약은 프레젠테이션 경계에 두고 내부 개념을 조합해 응답합니다.
변경 비용으로 나누는 클라이언트와 서버의 책임
표시 전용 처리는 UI 가까이에 두되, 여러 클라이언트와 배포된 앱 버전 때문에 변경이 비싸다면 의미 있는 값을 서버에 모으는 기준입니다.
테스트 편의 때문에 운영 코드의 의미를 바꾸지 마라
운영 행위가 더 명확해지거나 레거시에 테스트 경계가 필요할 때만 코드를 바꾸고, 테스트만 쓰는 값과 메서드를 억지로 노출하지 않는 기준입니다.
레거시는 점진적으로, 캐시는 운영까지 설계하라
레거시 경계를 신중히 고르고 작은 단계로 옮기며, DB 최적화와 배포 실패 조건을 이해한 뒤에만 공유 캐시를 추가하는 기준입니다.
오버엔지니어링을 막는 되돌릴 수 있는 설계
현재 요구사항을 담백하게 구현하고 조금만 앞을 보며, 추측으로 만든 구조를 쉽게 확장하거나 제거하고 다른 방향으로 바꿀 수 있게 하는 기준입니다.
의견보다 작은 실험으로 기술적 설득을 시작하라
제안이 막힌 이유를 진단하고, 작은 증명과 내 근거, 상대 논리의 이해를 준비하며, 새 기술 도입은 회사가 부담할 위험으로 다루는 방법입니다.
얼어붙은 신입 개발자 시장을 통과하는 현실적인 전략
채용이 좁아진 2024년에는 첫 회사의 범위를 넓히고, 실제 업무를 문제 해결 근거로 바꾸며, 기술 목록보다 사고 과정을 보여줘야 합니다.
REST 순수성보다 명확한 API를 설계하라
REST의 장점은 활용하되 클라이언트의 이해, 팀의 일관성, 도메인 경계와 변경 비용을 기준으로 HTTP 계약을 결정하는 방법입니다.
경계에서 검증하고 핵심 흐름은 단순하게
API 입력을 프레젠테이션 경계에서 온전한 비즈니스 값으로 바꾸고, 널을 안쪽에 넘기지 않으며, 저장 데이터는 들어올 때 검증하는 방법입니다.
SI에서 서비스 개발로: 채용 요건을 학습 계획으로 바꾸기
SI에서 서비스 팀으로 옮긴 데에는 도움과 운이 컸습니다. 반복 가능한 전략은 목표 채용 요건을 읽고 관련 역량과 경험을 만드는 것입니다.
첫 테스트는 서툴러도 된다, 나중에 리팩터링하라
지키고 싶은 행위를 검증하는 테스트부터 만들고, 실행에 필요한 만큼 목을 쓰며, 반복과 리뷰를 통해 테스트 설계를 개선하는 방법입니다.
API 요청 모델을 핵심 도메인에서 분리하라
프레젠테이션 경계에서 외부 요청을 비즈니스가 소유한 값으로 바꿔 API는 안쪽을 의존하고 코어는 바깥을 모르도록 만드는 방법입니다.
실제 트래픽 모양에서 성능 테스트를 설계하라
부하 도구를 고르기 전에 트래픽 규모와 유입 모양을 추정하고, 여유를 정하며, 실제 위험이 있는 기능에만 검증 근거를 요구하는 방법입니다.
외래키는 규칙이 아니라 운영상의 선택이다
무결성 요구, 장애 대응, 배포 절차, 운영 DB의 주체를 기준으로 외래키와 인덱스, ORM 연관관계를 각각 선택하는 방법입니다.
도메인 간 행위는 책임의 주인에게 맡겨라
호출자 쪽 인터페이스를 모듈 사이에 두기 전에 행위의 주인을 정하고, 호출자가 그 도메인의 기능을 의존하게 만드는 기준을 설명합니다.
열거형의 주인은 누구인가: 도메인 모듈 의존성 설계
비즈니스 열거형은 도메인이 소유하고 스토리지는 안쪽을 의존하게 하며, 경계가 익는 동안에만 작은 공유 열거형 모듈을 두는 방법입니다.
플랫폼 API에서 제공자 식별과 인증 경계를 나누는 법
작은 플랫폼 API가 제공자 키를 도메인 식별자로 바꾸고 데이터를 구분하며, 규모에 맞는 인증 경계를 선택하는 과정을 다룹니다.
여러 도메인을 엮는 코드는 어디에 둘까
주된 행위와 다른 도메인의 규칙을 함께 다루는 코드를 비즈니스 소유권, 응집, 임포트, 패키지 이동 실험으로 배치하는 방법입니다.
도메인 모델을 먼저 보는 보수적인 JPA 연관관계 설계
ID에서 시작하고 생명주기가 실제로 맞을 때만 연관관계를 추가하며, 비즈니스 개념은 엔티티와 독립적으로 표현하는 방법을 다룹니다.
실제 트래픽이 없어도 대용량 시스템 대응은 연습할 수 있습니다
작은 서비스를 직접 운영하고 의도적으로 부하를 만들어 병목을 찾고 고친 과정을 보여주세요. 다만 부하 테스트를 운영 경험이라고 과장해서는 안 됩니다.
공유 테스트 DB 없이 신뢰할 수 있는 데이터베이스 테스트 만들기
잡아야 할 실패에 따라 목, 인메모리 DB, Testcontainers, 실제 DB를 고르고 일반 테스트는 공유 인프라에서 격리합니다.
계층마다 DTO를 습관처럼 만들지 마세요
데이터가 서로 다른 계약을 가진 경계를 넘을 때 DTO를 사용합니다. 매핑에도 비용이 들지만 외부 요청 형태가 서비스 내부를 지배하게 두는 데도 비용이 듭니다.
Git 이력은 개인 작업일지가 아니라 팀의 자산입니다
커밋을 다듬기 전에 작업부터 나누고, 동료가 검토하기 좋은 PR과 다음 사람이 변경 이유를 추적하고 릴리스를 복구할 수 있는 이력을 남깁니다.
서킷브레이커는 실패하는 I/O 가까이에 두세요
서킷브레이커, 타임아웃, 캐시 폴백 같은 외부 호출 정책은 I/O 구현체 가까이에 두고, 도메인 코드는 그 결과가 비즈니스에서 무엇을 뜻하는지 결정합니다.
타임아웃은 클라이언트 설정이 아니라 제품의 결정입니다
모든 실패에 같은 재시도 규칙을 붙이지 말고, 사용자가 기다릴 수 있는 시간과 실패 뒤에 알 수 있는 사실을 기준으로 타임아웃과 복구 정책을 설계합니다.
도메인이 성숙하기 전에 모듈부터 나누지 마세요
도메인 성숙도는 정책과 행동, 운영 현실을 얼마나 이해했는지에서 나옵니다. 추측을 일찍 굳히지 말고 운영에서 드러난 책임으로 모듈 경계를 정해야 합니다.
소프트웨어는 경계를 한 단계씩 키워야 한다
동작하는 코드에서 시작해 실제 응집과 규모가 더 강한 경계를 요구할 때 함수, 클래스, 패키지, 모듈과 프로젝트를 단계적으로 추출합니다.
레이어는 논리적으로, 패키지는 응집도 있게
모듈, 패키지와 아키텍처 레이어는 서로 다른 문제를 풉니다. 관련 동작은 가까이 두고 레이어는 기능을 흩뜨리지 않은 채 역할을 설명해야 합니다.
의존성 격차가 프로젝트가 되기 전에 버전 올리기
우선순위에 따라 의존성을 자주 올리면 변경을 작게 유지하고 호환성 문제를 일찍 발견하며 운영 서비스에 부채가 조용히 쌓이는 일을 막을 수 있습니다.
만든 개발자가 떠나도 살아남는 소프트웨어
좋은 회사 소프트웨어는 부채를 줄이고 팀의 운영 능력에 맞으며, 처음 만든 개발자가 떠난 뒤에도 이해하고 고칠 수 있어야 합니다.
단위 테스트는 비즈니스 의도를 지켜야 한다
비즈니스 레이어 단위 테스트는 설계를 돕고, 중요한 동작을 기록하며, 다음 개발자가 위험한 변경 앞에서 한 번 더 생각하게 할 때 의미가 있습니다.
AI 에이전트가 같은 도구를 두 번 호출한다면
분산 시스템과 AI 워크플로에서 재시도는 정상입니다. DB 제약, 멱등 키, 제한된 재시도로 도구 호출의 중복 부작용을 막는 방법을 정리합니다.
너무 이른 멀티모듈은 설계를 더 어렵게 만든다
모듈은 이해하지 못한 도메인이나 아키텍처 그림을 미리 고정하는 장치가 아니라 구현에서 발견한 경계를 강제하는 수단이어야 합니다.
그래들 의존성 범위로 아키텍처 경계 세우기
Gradle의 implementation, api, runtimeOnly, compileOnly를 의도적으로 사용해 모듈 접근을 제한하고 우발적인 결합을 막는 방법을 설명합니다.
토이 프로젝트를 서비스라고 부르기 전에 운영해보기
토이 프로젝트에서 서비스 경험을 얻으려면 하나의 목표를 정하고, 출시하고, 실제 사용자를 만나며, 리텐션과 종료 시점을 봐야 합니다.
어드민을 서비스 도메인에서 격리하기
어드민 API는 조회, 수정, 릴리스 위험이 다릅니다. 운영 편의가 핵심 서비스를 바꾸지 않도록 모듈이나 저장소로 격리합니다.
리더와 라이터 컴포넌트로 비즈니스 흐름 드러내기
리더와 라이터는 저장소 세부사항과 변경 범위를 감추고 비즈니스 계층에 정책을 남깁니다. 다만 서비스 수명이 그 비용을 정당화해야 합니다.
분산 서비스 끝까지 하나의 트레이스 아이디 전달하기
민감한 정보를 노출하거나 저장소를 로그로 넘치게 하지 않으면서 HTTP 호출과 비동기 이벤트를 하나의 요청 맥락으로 추적합니다.
사용자 관점에서 문제를 정의하는 법
기술 부하와 제품 가치를 구분하고, 만든 것을 실제로 출시하며, 사용자가 왜 선택할지 계속 물어야 문제 해결 능력이 자랍니다.
유즈케이스 아래 계층에서 코드를 재사용하기
유즈케이스끼리 재사용하면 비즈니스 변경이 번지고 순환 참조가 생깁니다. 위에서 조합하거나 아래의 구현 컴포넌트를 추출합니다.
개발 용어보다 자기 생각과 운영 경험을 선택하기
이론과 패턴은 유용한 참고 자료지만, 개발자는 코드와 트레이드오프, 운영 결과를 자기 언어로 설명할 수 있어야 합니다.
거대한 서비스 클래스를 책임과 계층으로 분리하는 법
생성자 의존성과 import로 비대해진 서비스를 진단하고, 새로운 아키텍처 이름을 붙이기 전에 응집된 책임부터 분리합니다.
요구사항과 객체 관계로 정규화와 반정규화를 선택하기
정규화 수준을 점수처럼 높이기보다 값의 변경 의미, 조회 비용, 데이터가 보존해야 할 객체 관계를 기준으로 테이블을 설계합니다.