Card와 ReviewSession을 왜 나눴는가, 그리고 그 대가는 무엇인가도메인 트레이드오프 기록(- 도메인 구조 한눈에 보기(- 장점( - 1. 관심사가 명확하게 분리된다( - 2. 같은 Card를 여러 세션에서 독립적으로 다룰 수 있다( - 3. CardR

커머스 플랫폼에 관리자 모드를 추가하면서문제점을 만났다. 예외 처리를 어디서, 어떻게 해야 하는가 였다.코드는 결국 동작했지만, 그 과정에서 생각보다 많은 것을 고민했다.(항상 Exception , 에러코드들을 관리하는 것은 복잡한 것 같다.)요구사항을 처음 읽었을 때

시작은 단순했다(- Deck을 추가했을 때(- Review가 붙으면서 확신이 생겼다(- 문제를 테스트로 확인해봤다(- 중첩 클래스로 바꿔봤다(- 테스트를 다시 작성했다(- 파일 크기 문제는 분리 기준으로 해결했다(- 바꾸고 나서 달라진 것(- 정리(Third Tool

개인 문서화 project\~~!AI가 코드를 짜주고, 아키텍처를 제안하고, 심지어 PR 리뷰까지 해주는 시대가 왔다.그렇다면 개발자에게 남는 핵심 역량은 무엇일까?나는 그게 "읽고, 구조화하고, 판단하고, 책임지는 것" 이라고 생각한다.그리고 이 모든 것의 가장 기본

자료구조를 기준으로 function을 찾을 때는 문제"스택은 이럴 때, 큐는 저럴 때..." 무엇보다 공통점, 단조로움에 대해서 처음에 관통이 어려움문제는 연산을 요구한다."어떤 자료구조를 쓰지?" 가 아니라"어떤 연산이 필요하지?" 로 먼저 반응하는 순간패턴이 보이기

들어가며(- 기존 구조의 한계(- 설계 결정 — Card와 CardStatusHistory의 책임 분리(- 도메인 모델 — CardStatusHistory(- CardStatusHistoryAppender — 이력 기록 전담 도메인 서비스 - 도메인 서비스의 활용(-

이 글은 개인 프로젝트 Third Tool(Cornell Notes 기반 학습 카드 시스템)에 Spring 애플리케이션 이벤트를 도입하면서 겪은 고민의 흔적입니다."왜 이벤트를 써야 하는가"보다 "이 프로젝트의 어느 지점에 이벤트가 필요했는가" 에 집중했습니다.도입 전

JPA 낙관적 락 vs 비관적 락 — 트레이드오프와 선택 기준( - 왜 락이 필요한가? — Lost Update 문제( - 한눈에 비교( - 낙관적 락 (Optimistic Lock)( - 동작 원리( - 구현(실제 사용 예시\_ spring)(

Calculator 클래스를 만들고 App에서 인스턴스를 생성했는데, 막상 main()을 보니 연산 로직이 Calculator가 아닌 App에 그대로 남아 있었다.(연산의 책임은 Calculator의 객체가 지고 io의 책임은 App이 지고 있는 상황)Calculato

ThirdTool 프로젝트에서 CardRepository, CardRepositoryAdapter, CardRepositoryCustom, CardJpaRepositoryImpl 4계층 구조를 채택한 배경과, 단순한 JpaRepository 직접 주입 방식과의 트레이드

"코드는 Git으로 관리하면서, 왜 DB 스키마는 기억에 의존하고 있었을까?"Spring Boot 프로젝트를 처음 시작할 때, 대부분의 개발자는 application.yml에 이 한 줄을 아무 고민 없이 추가한다.토이 프로젝트 수준에서는 이게 사실 최고의 선택처럼 느껴

1\. 문제 인식: 왜 캐시가 필요했나( - 속도 격차 문제 (Speed Gap)( - 어떤 데이터가 문제였나(- 2. 첫 번째 선택: 왜 Redis가 아닌 Caffeine이었나(이게 중요하다.)( - 바로 Redis를 도입하지 않은 이유( - 순차적 검증의 원

N+1 문제 — 가장 먼저 확인하는 것(2. Pagination — 전체 조회 차단(3. Projection — 필요한 컬럼만 조회(4. 읽기 전용 트랜잭션 분리(5. Bulk Insert / Update(6. 캐싱 계층 도입 순서(7. 비동기 처리 — 핵심 로직과 부

먼저 짚고 가자 — Test Double의 종류(- Classist와 Mockist — 두 철학의 차이(- Case A — 순수 클래스로 Card 도메인을 테스트해야만 했던 이유(- Case B — Mock을 도입해봤더니 생긴 트레이드오프(- 두 접근의 트레이드오프 정

1\. 코드는 개발자(사람)가 읽으라고 만들어진 것이다.(- 2. 패키지 나누기 = 코드의 정보 조직화(정보 조직화체계의 시작)(- 3. 사고의 depth 줄이기 = 레이어를 줄이는 것이 아니라, 추론의 단계를 줄이는 것(- 4. 부정어 줄이기 = 뇌가 한 번 더 뒤집

1\. 왜 이 비교를 하게 되었는가(- 2. A 방식: BusinessException 하나로 통일하는 방식( - A의 특징( - A의 장점( - A의 단점( - A가 잘 맞는 상황(- 3. B 방식: 도메인별 예외 클래스로 분리하는 방식( - B의 특징(

단순한 CRUD를 넘어, 그날 먹고 싶은 마음에 가까워지는 방향으로들어가며(> - 1. 초기 미션의 시작: 맛집 리스트 CRUD 구현(> - 2. 처음 맞닥뜨린 어려움: React와 JavaScript에 대한 낯섦(> - \[2-1 새로운 도구의 활용: Mock A

문제는 방식이 아니라, 받아들이는 사람의 속도였다(- 팀원은 기능이 아니라, 관성을 가진 사람이다(- 중요한 것은 ‘새로움’이 아니라 ‘익숙한 새로움’이었다(- 앞으로는 이렇게 해보고 싶다(- 마무리(팀 프로젝트, 도메인 팀의 경험을 거치면서 점점 강하게 느끼게 된 것

Part 1. 왜 바꿨는가 — Card 시스템을 고쳐야 했던 배경1\. 기존 시스템이 잘 작동하던 이유 — Score 기반의 장점(> 2. 문제 ① 개인화의 한계 — 알고리즘으로 메울 수 없는 간극(> 3. 문제 ② UX의 한계 — 중요한 것이 눈에 안 보인다(> 4.

1\. 들어가며(- 2. 이번 미션의 배경(- 3. 처음에는 기능이 아니라 해야 할 것의 덩어리로 보였다(- 4. 크게 만들고 싶을수록 더 잘게 나눠야 한다(- 5. Sprint 1 — 최소 운영 흐름부터 닫기(- 6. Sprint 2 — 구조를 확장하되 기존 흐름은