컨테이너를 잘 다루는 것과, 컨테이너로 만든 시스템을 잘 운영하는 것은 완전히 다른 이야기다.docker run은 쉽다. docker-compose up도 쉽다. 그런데 운영 환경에 올리는 순간 사람이 손으로는 도저히 감당이 안 되는 문제들이 갑자기 쏟아진다.이 글은

"도커 쓰면 되는 거 아닌가요?"Spring Boot 프로젝트를 인프라에 올리면서 자연스럽게 들었던 질문이다. 그런데 성원튜터님 강의를 들으며 자연스러운 인사이트를 얻게되었다.. EC2(가상머신) 위에 ECS(컨테이너)를 띄운다. 컨테이너가 그렇게 좋다면 왜 굳이 VM

ㅇㅇ

AI에게 문서를 맡길 때 무너지는 건 정확성이 아니라 소유권(ownership) 과 결정의 날카로움이다.Doc-driven workflow를 ThirdTool에 적용하면서, 같은 도메인 모델링 문서를 두 가지 방식으로 작성해봤다.처음엔 "어느 쪽이 더 나은가" 식으로

일당백 백오피스 프로젝트(com.ildang100.backoffice) 회고 시리즈의 첫 글.도메인: admin / customer / product / order / review (Bounded Context별 분담)담당: product 도메인 + 재고 자동화 플로우

예비군 일정과 겹쳐서 우선 임시 페이지로 제출하겠습니다!

LearningFacade BC에서 AxisAction의 coverage_status는 연결된 ActionMaterial의 상태에 따라 결정된다.NO_MATERIAL — 자료 없음PARTIAL (학습중) — 자료는 있으나 일부만 완료COVERED (마스터) — 자료가

캐시가 답이 되는 상황은 분명히 존재합니다. 하지만 그게 언제인지 알려면 명확한 기준이 필요합니다. 이 글에서는 캐시 도입을 결정할 때 쓰는 4가지 조건, 4가지 부적합 케이스, 그리고 실전 도입 순서를 정리해보겠습니다\~~! 핵심 질문: "이 데이터는 얼마나 자주 읽

스파르타 코딩클럽 일정 관리 과제를 진행하면서,Bean Validation을 사용하지 않는 조건 하에 Schedule·Comment 서비스의 검증 로직을 어떻게 설계할지 고민했던 과정을 정리한다.과제 제약 조건은 두 가지였다.Bean Validation 사용 금지 (@

"JPA가 알아서 해준다"는 말을 믿기 전에, 무엇을 어떻게 해주는지는 알아야 한다.JPA에서 엔티티를 관리하는 논리적인 저장 공간이다.EntityManager가 이 컨텍스트를 통해 엔티티의 생명주기를 제어하며,Spring Data JPA 환경에서는 @Transacti

처음엔 그냥 만들었다(- 흔들리기 시작한 순간들(- 자각의 과정 — 4축이라는 언어를 얻다(- 그래서 문서를 쓰기 시작했다(- 문서를 관리하면서 달라진 것들(- 아직 남은 것들(- 마치며( ThirdTool을 개발하면서 처음으로 테이블이 "살아있는 것"처럼 느껴졌다.

ThirdTool을 개발하면서내린 설계 결정 중 하나가CascadeType.REMOVE와 orphanRemoval을 제거하는 것이었다.이유는 명확했다. Soft Delete 구조에서 JPA의 물리 삭제 캐스케이드는오히려 독이 된다. orphanRemoval = true

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)(