AI 개발 작업을 맥락과 기기, 위험도에 따라 나누기
IDE 검토, 데스크톱 에이전트, 원격 모바일 흐름을 연결하되 맥락의 크기와 검토 필요성, 운영 위험에 따라 작업을 나눕니다.
Articles
생각과 경험을 기록합니다.
실제로 검증한 AI 작업 흐름으로 개발 템플릿 바꾸기
반복해서 검증한 AI 작업 흐름에 맞춰 개발 템플릿을 바꾸되, 검증은 명시적으로 남기고 프로젝트별 지침은 공통 기본값과 분리합니다.
파일 URL 대신 스토리지 키를 저장하라
안정적인 스토리지 키와 서버에서 조합하는 주소, 중복 없는 내부 이름, 별도로 보존하는 원본 파일명으로 업로드 구조를 단순화합니다.
AI 변경을 동료가 리뷰할 수 있는 PR로 쪼개기
AI가 만든 코드도 작업자가 책임질 수 있도록 범위를 줄이고, 커밋과 PR을 동료가 이해하고 검토할 수 있는 단위로 나눕니다.
AI 생산력과 엔지니어링 생산성은 같지 않다
AI 에이전트가 생산량을 높여도 복잡한 실무에는 맥락, 메모리, 판단, 좋은 동료의 자발적인 사고 확장이 왜 필요한지 살펴봅니다.
AI 버즈워드보다 실제 업무 효용으로 판단하기
유행하는 AI 용어를 좇기보다 실제 업무와 프로젝트에 적용해 보고, 직접 만든 경험으로 효용과 불안을 구분하는 법을 다룹니다.
공부 시간보다 경력 경험의 밀도를 높여라
업무와 무관한 공부 시간을 늘리기보다 실제 회사 일에서 설명할 수 있는 경험의 밀도를 높이는 커리어 원칙을 다룹니다.
프론트오피스와 백오피스는 언제 분리해야 할까
목적, 생명주기, 기능 중복, 팀의 작업 방식과 운영 비용을 비교해 프론트오피스와 백오피스의 분리 여부를 판단합니다.
부트캠프 간판보다 목적과 멘토를 검증하는 법
구체적인 학습 목표, 멘토 역량, 실제 성과와 한계, 비용의 타당성을 기준으로 부트캠프를 판단하는 방법을 다룹니다.
AI 시대의 프로젝트 구조와 기술 스택 선택 기준
AI의 생성 속도만 보지 말고 팀 규모, 기존 전문성, 리뷰 가능성, 실패 비용에 맞춰 프로젝트 경계와 기술 스택을 고르는 기준을 다룹니다.
AI와 만드는 새 프로젝트의 모듈과 계층 단순화
AI와 새 프로젝트를 만들 때 모듈·인터페이스·계층을 줄이는 가설을 검토하되, 명확성과 품질 및 레거시의 점진적 개선을 지킵니다.
과도한 업무와 리더십 문제를 조직에 드러내기
과도한 개발 업무를 작은 단위와 공동의 증거로 가시화해 자원을 협상하고, 반복되는 리더십 문제를 맥락에 맞게 드러내는 방법을 다룹니다.
임시 저장의 의미로 상태와 별도 저장소 선택하기
일반적인 생명주기 단계는 상태로, 별도 의미를 가진 준비 데이터는 버전 저장소로 다루되 도메인 의미와 호환 비용을 기준으로 선택합니다.
익명 서비스에서 순번 키의 연결 고리 끊기
신원 관련 레코드에 독립적인 무작위 식별자를 사용해 순번 키의 직접 연결을 끊되, UUID만으로 익명성이 보장되지는 않음을 짚습니다.
CSS가 아니라 서버 응답에서 미리보기 원문 숨기기
보호할 원문을 내려준 뒤 화면에서 흐리지 말고, 정직한 미리보기 형태는 유지하면서 서버 응답 경계에서 내용을 변환하는 방법을 설명합니다.
메시지 브로커 없이 회원 탈퇴 후처리 연결하기
작은 서비스에서 도메인별 정리 구현체를 모아 순회하며, 별도 메시징 인프라 없이 회원 탈퇴 흐름과 결합도를 관리하는 방법을 다룹니다.
통 라이브러리를 조합 가능한 의존성 모듈로 쪼개라
전사 통 라이브러리를 서비스가 이해하고 선택할 수 있는 모듈로 나눠 숨은 인프라 연결, 자원 낭비와 의존성 충돌을 막습니다.
앱 하위 호환성을 위한 서버 주도 API 응답 설계
구버전 앱을 위해 변하는 표시 정책과 실험은 서버가 맡되, 변환을 API 경계에 격리해 도메인 모델을 보호합니다.
애매한 개발 경력을 정직한 면접 강점으로 바꾸는 법
전체 경력은 정직하게 유지하되 지원 역할마다 프로젝트 강조점을 바꿔, 인접 경험을 채용할 만한 근거로 만듭니다.
팀이 믿을 수 있는 최소 문서만 최신화하라
정책, 핵심 개념, 시스템 흐름과 API 계약을 소수의 신뢰할 문서로 관리하고 온보딩 피드백으로 계속 최신화합니다.
신뢰와 작은 성공으로 개발 문화를 바꾸는 법
새 조직을 먼저 이해하고 일로 신뢰를 얻은 뒤, 테스트와 정책 공유의 작은 성과를 보여 개발 문화를 확산합니다.
조직 현실까지 고려한 데이터 관계 설계
단순한 관계에서 시작하되 실제 요구사항 변경, 의사결정 습관과 일정 제약을 관찰해 데이터 관계 설계에 반영합니다.
암묵지를 살아 있는 팀 컨벤션으로 만드는 법
팀원의 머릿속에만 있는 개발 규칙을 이유와 함께 기록하고, 팀별 재정의와 리뷰·온보딩으로 살아 있게 관리합니다.
모든 도메인을 삼키는 어드민 공통 모듈을 피하라
어드민 요구가 도메인 의존성을 뒤집지 않게 서비스 경계를 지키고, 요구가 계속 갈라지는 동안 작은 중복을 허용합니다.
회사 규모를 넘나들며 개발자 경험의 폭을 넓히는 법
장기 목표에 맞춰 작은 조직의 넓은 책임과 큰 조직의 깊은 전문성 중 필요한 경험의 폭을 의도적으로 선택합니다.
어댑터·듀얼 라이트·플래그로 Oracle을 MySQL로 이관하기
호환 어댑터, 사전 배포, 듀얼 라이트, 검증된 스위치와 롤백으로 Oracle 레거시를 MySQL로 점진 이관합니다.
개발자 이직은 연봉만이 아니라 다음 경험으로 고른다
현실적인 금전 제약을 존중하면서도 도메인, 운영 문제, 책임을 장기 역량으로 바꿀 수 있는지를 이직 기준에 넣습니다.
개발 리더십은 직함을 받기 전에 시작된다
리뷰, 장애, 넓은 문제와 동료의 신뢰를 먼저 책임지며 직함이 붙기 전부터 개발 리더십을 준비하는 기준입니다.
강점과 실험으로 개발자 커리어를 설계하는 법
자신의 강점을 구조화하고 여러 개발 경험을 직접 시험하며, 막연한 포부 대신 근거로 미래 방향을 계속 고치는 방법입니다.
코드 리뷰 품질은 댓글 수보다 줄어드는 추이로 본다
자동화와 드래프트 PR로 초기에 합을 맞추고, 공통 규칙이 자리 잡으며 반복 피드백이 줄어드는지를 확인합니다.
회원 탈퇴 데이터의 보관·분리·복구 설계
탈퇴 회원 데이터를 검증된 보관 기준, 분리 저장, 암호화, 만료와 취소·재가입 같은 운영 흐름에 맞춰 설계합니다.
자바 Optional은 데이터 경계에서만 쓰는 이유
값의 부재를 호출자가 실제로 결정해야 하는 반환 경계에서만 Optional을 쓰고 내부 흐름은 명확하게 유지하는 기준입니다.
긴 레거시 개편을 작은 배포로 나누는 법
지치는 레거시 개편을 작은 개발·검증·배포로 나눠 빠르게 피드백을 얻고 완벽주의의 함정을 피하는 방법입니다.
정보와 행동을 함께 보는 도메인 개념 도출법
정보와 프로세스 또는 행동을 사례별 관점에서 살펴 전송 이벤트와 도메인 개념을 구분하는 방법입니다.
도메인 개념과 데이터베이스 테이블이 일대일이 아닌 이유
모든 테이블을 도메인 객체와 리포지토리로 복제하지 않고 비즈니스 중요도, 위계와 행동을 기준으로 모델링하는 법을 설명합니다.
QA 전달 전에 개발자가 먼저 검증해야 하는 이유
QA 전달 전 개발자가 정상 동작을 검증해 반복 수정 비용을 줄이고 QA가 경계 조건과 제품 품질에 집중하도록 만드는 방법입니다.
새 프로그래밍 언어 도입의 전체 비용을 계산하는 법
기술 적합성만 보지 않고 채용, 학습, 관측성, 공통 라이브러리, 통합과 유지보수 비용으로 새 언어 도입을 판단합니다.
도메인 지식을 실무 문제 해결로 증명하는 법
운영, 정책과 부서 간 문제에서 도메인 지식을 쌓고 용어가 아니라 실제 판단과 해결 과정으로 역량을 증명하는 방법을 다룹니다.
엉망인 레거시 스키마를 코드 경계 뒤에서 개선하는 법
의미 없는 테이블과 컬럼을 리포지토리와 타입 뒤에 숨겨 코드 통제력을 회복한 뒤 데이터베이스를 점진 개선하는 전략입니다.
분산 추적과 안전한 운영 로그를 함께 설계하는 법
서비스 간 요청을 추적하면서 로그 용량, 민감정보 마스킹, 접근 권한과 보관 기간을 함께 설계하는 실무 기준을 다룹니다.
페이징 카운트 쿼리가 데이터베이스를 느리게 하는 이유
정확한 전체 건수가 제한 조회보다 비싼 이유와 슬라이스, 캐시 메타데이터, 추정치 또는 요구사항 변경을 선택할 기준을 설명합니다.
배치 재실행 비용을 줄이기 위해 수신과 가공을 분리하는 법
외부 데이터를 저장한 뒤 제공자 호출 없이 내부 가공만 재실행해 대형 배치의 트래픽과 복구 비용을 줄이는 방법입니다.
동작하는 스파게티 코드를 특성 테스트로 리팩터링하기
넓은 API 특성 테스트로 레거시 동작을 고정하고 안전망 안에서 리팩터링한 뒤 작은 가역적 변경으로 배포하는 전략을 설명합니다.
바이브 코딩 시대에도 개발자 판단력이 필요한 이유
AI 코딩을 활용하면서도 문제 정의, 코드 검토, 품질 기준과 결과를 검증할 기술 지식을 지키는 방법을 다룹니다.
애자일은 문서화를 하지 말라는 뜻이 아니다
애자일을 문서화 거부의 핑계로 삼지 않고 팀의 연속성, 보안, 규제와 운영에 필요한 문서를 판단하는 기준을 다룹니다.
회사가 아닌 개발자가 자신의 성장을 책임지는 법
회사, 책, 프로젝트와 커뮤니티의 경험을 자기 판단으로 바꾸며 개발자 성장을 스스로 책임지는 관점을 다룹니다.
계정과 프로필 연결 가능성을 낮추는 익명 설계
식별자 분리, 휘발성 매핑 키, 최소 보관과 계정 복구 제약을 통해 익명 계정 모델의 트레이드오프를 살펴봅니다.
로그인 전 데이터 마스킹을 프레젠테이션 계층에 두는 법
게스트 마스킹과 작성자 표시를 프레젠테이션 경계에 격리해 도메인 로직과 원문 데이터를 보호하는 방법을 설명합니다.
시니어 개발자가 다음 개발자에게 남겨야 할 유산
연차가 아니라 유지보수 가능한 코드, 테스트, 가이드와 팀의 지속가능성으로 시니어의 책임을 살펴봅니다.
좋아요 정렬을 위한 핵심 데이터와 집계 데이터 분리
집계 분리, 명시적인 최신성 기준, 비동기 갱신, 정합성 보정, 검색 경계로 좋아요 기반 정렬을 확장합니다.
아이디 범위를 띄워 DB 마이그레이션 롤백을 안전하게 만들기
레거시와 신규 아이디 범위를 분리해 롤백 충돌을 막고, 역마이그레이션과 운영 트래픽 추적을 단순하게 만듭니다.
모든 조회를 삼키는 만능 메서드를 목적별로 쪼개라
만능 동적 조회를 목적별 메서드로 나누고 호출부를 점진적으로 옮겨, 리팩터링의 사이드 이펙트를 줄입니다.
경력 있는 신입 개발자는 업무 경험으로 차별화하라
이전에 한 일과 문제, 접근 방식, 시도한 해법과 실제 행동을 면접에서 구체적으로 설명하는 법을 다룹니다.
레거시 개선은 죽은 코드를 안전하게 지우는 데서 시작한다
런타임 증거, 데이터 확인, API 소비자 검증을 결합해 죽은 코드를 점진적으로 삭제하고 레거시를 줄입니다.
빅뱅 대신 작은 배포로 완성하는 레거시 개편
검증 가능한 작은 배포와 롤백 경계로 개편 위험을 낮추고, 프로젝트가 멈춰도 남는 가치와 진척을 만듭니다.
작은 문제를 적은 자원으로 푸는 엔지니어링
현재 시스템의 한계를 측정하고 작은 문제를 비례 있게 해결하며, 근거가 생길 때 캐시와 분산 인프라를 추가합니다.
개념의 생명주기로 도메인 경계를 찾는 법
생성, 조회, 수정, 삭제 주기를 비교해 상품, 주문, 결제, 배송, 정산의 응집과 경계를 판단합니다.
목록 좋아요 수는 단순한 조회부터 시작하라
현재 페이지의 좋아요만 제한적으로 조회하고, 카운터 컬럼이나 Redis는 규모가 커져 필요할 때 관리 비용과 함께 검토합니다.
도메인 학습과 기술 실험을 분리하는 두 가지 트랙
도메인 프로젝트는 익숙한 기술로 출시하고, 낯선 인프라는 최소 프로젝트와 성능 테스트로 따로 검증합니다.
개발자 성장은 맡은 일을 끝내는 데서 시작한다
최소 품질선을 지키며 가치 있는 일을 완수하고, 이후 리팩터링과 학습으로 다음 성장을 준비하는 태도를 다룹니다.
주문 스냅샷을 지키는 소프트 삭제와 도메인 경계
현재 상품과 주문 스냅샷의 경계를 나누고, 환불 이력을 보존하며 파괴적 삭제 전에 상태 전환과 보관을 검토합니다.
핵심 엔티티를 가볍게 지키는 연관관계 설계
생명주기와 책임으로 ORM 연관관계를 판단하고, 검색용 부가 데이터를 분리해 핵심 엔티티를 단순하게 유지합니다.
아키텍처 규칙 자동화보다 팀의 판단이 먼저다
레이어 규칙 자동화를 리뷰 여력, 저장소 규모, 개발자 성장, 팀의 아키텍처 토론과 함께 판단합니다.
모듈 경계에서 예외를 변환하고 전파하는 법
구현 예외를 소유 모듈 안에 가두고, 상위 계층으로 의존성이 새지 않도록 변환 경계를 설계합니다.
Manager와 Processor 클래스가 리팩터링 대상이라는 신호
모호한 클래스 이름을 코드 스멜로 읽고, 과도한 책임과 레이어를 점진적으로 정리하는 기준을 설명합니다.
스웨거와 REST Docs, API 문서화 도구를 상황별로 고르는 법
테스트 강제, 코드 침투성, 문서 확장성, 레거시 API의 점진적 전환 기준으로 두 도구를 비교합니다.
리더와 라이터는 아키텍처 규칙이 아니라 선택지다
리더·라이터와 도구 계층을 모방이 아니라 코드 규모, 도메인 거리, 레거시 제약, 팀 규칙에 따라 선택하는 기준을 설명한다.
공통 모듈의 함정: 구체적인 기능으로 코드를 응집하라
소유권이 드러날 때까지 공통 모듈을 늦추고, 로깅·예외·공유 규격을 구체적인 기능과 책임 중심으로 묶는 방법을 다룬다.
바꾸기 전에 먼저 팀의 사람이 되어라
제때 묻고 진행 상황을 공유하며 빠르게 리뷰받고, 신뢰를 쌓은 뒤 근거 있는 작은 변화로 새 개발팀에 적응하는 방법을 다룬다.
거대한 서비스 클래스를 책임 단위로 나누는 법
개념 지도, 책임의 흐름, 테스트 경계, 구체적인 리팩터링 대안을 통해 비대해진 서비스 클래스를 나누는 방법을 설명한다.
운영 테이블을 지키는 별도 조회 모델 설계
운영 테이블은 비즈니스 개념에 맞게 설계하고, 복잡한 이력·어드민 검색은 별도 조회 모델에서 제공하는 방법을 다룬다.
열거형인가 코드 테이블인가: 변화 주기로 결정하라
안정적인 값은 열거형으로, 자주 바뀌는 데이터는 전용 테이블로 관리해 공통 코드 테이블이 잡동사니 저장소가 되는 일을 막는다.
하나의 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로 비대해진 서비스를 진단하고, 새로운 아키텍처 이름을 붙이기 전에 응집된 책임부터 분리합니다.
요구사항과 객체 관계로 정규화와 반정규화를 선택하기
정규화 수준을 점수처럼 높이기보다 값의 변경 의미, 조회 비용, 데이터가 보존해야 할 객체 관계를 기준으로 테이블을 설계합니다.