코딩하는오후

`@InjectMocks`를 사용하면 필드 주입에 대하여 `@Mock`을 사용하게 된다. 그런데, `@Mock`이 아니라 실제 객체를 주입해야할 때까 있는데 이때 `@Mock` 대시 `@Spy`를 사용하면 된다. ```java @Spy SomePort somPort = new DefaultRepository(); ```

# 5-Step Architecture Spec (Revised v3.1) 이 문서는 헥사고날 아키텍처와 DDD 전략적 설계를 실무적으로 결합하고, 바이브 모델링을 통해 도출된 도메인 자아를 소프트웨어 제조 공정으로 치환한 표준 지침입니다. ## Core Philosophy Service는 도메인 모델이라는 Category와 유스케이스라는 Category를 연결하는 Functor입니다. 모델은 비즈니스 규칙의 정적 보존 처인 Brain이며, Policy는 그 규칙이 환경에 따라 발현되는 방식인 Law입니다. Service는 이들 사이의 Morphism(사상)을 조율하여 유스케이스의 맥락으로 데이터를 전이시키는 역할을 수행합니다. 따라서 Service는 로직을 소유하지 않고 오직 흐름만을 관장함으로써 요구사항의 변화에 모델을 수정하지 않고도 대응할 수 있는 유연성을 확보합니다. --- ## The 5-Step Standard Process ### [Step 1] 도메인 자아 확립 (Domain Model Discovery) 비즈니스의 핵심 상태와 행위를 관리하는 Aggregate Root(AR)를 정의합니다. 모든 AR은 시스템의 공통 명세인 BaseEntity를 상속받아 정체성과 생애 주기를 관리합니다. 1. BaseEntity 기반의 자아 증명 - 정체성(Identity) 계승: AR은 BaseEntity 를 상속받음으로써 기술적 식별자가 아닌 도메인 식별자를 통해 스스로를 증명합니다. - Auditing의 내재화: createdAt, createdBy 등의 정보는 인프라(JPA 등)에 맡기는 부가 정보가 아니라, 모델이 생성되고 수정된 비즈니스 이력으로서 모델의 필드에 명시적으로 보존됩니다. 2. Reconstitution (복원 능력)의 이원화 AR은 상황에 따라 두 가지 방식의 생성 전략을 소유합니다. - 신규 생성(Creation): protected BaseEntity(I id, String operator)를...

## SQL은 백엔드 개발자의 필수 과목인가? ### 부제: 사수 부재의 시대 ### 1. 글로벌 개발 생태계 지표 (2025) - **Stack Overflow (2025):** JavaScript(66%) 대비 SQL(58.6%)의 학습 우선순위 밀림. PostgreSQL의 높은 심리적 진입장벽 확인. - **JetBrains (2025):** 풀스택의 비대칭성 및 프론트엔드 중심의 AI 코드 생성 도구 활용도 증가. ### 2. 주니어의 프론트엔드 선택: 심리적·학습적 요인 - **성공 경험의 경로:** 가시적인 UI 컴포넌트가 주는 즉각적 보상과 학습 동기. - **리스크의 체감 농도:** 데이터 무결성 파괴에 대한 심리적 압박(BE) vs 복구가 용이한 UI 에러(FE). - **생태계의 확신:** 거대 커뮤니티와 라이브러리가 주는 "이것만으로도 충분하다"는 안도감. ### 3. 구조적 결핍: '도제식 전수'가 끊긴 백엔드의 비극 - **암묵지의 영역과 사수의 부재:** 인덱스, 락(Lock) 제어 등 책에 없는 '현장 지식'을 전수해 줄 선임의 고갈. - **피드백 루프의 차이:** AI가 답을 주는 UI 영역 vs 회사의 고유한 '맥락(Context)'이 없으면 해석 불가능한 DB 설계. - **현장의 고립감:** 사수 없이 실무에 투입된 주니어가 느끼는 설계의 공포와 도피성 직무 선택. ### 4. 핵심 가치: 기술보다 중요한 '시스템 히스토리' ‘히스토리’란 - **데이터의 계보학:** 단순 쿼리 문법이 아닌, 데이터가 쌓여온 과정과 그 뒤에 숨은 의사결정을 이해하는 것. - **과거와의 대화:** 과거의 비정규화나 임시 로직이 당시에는 '최선의 타협'이었음을 이해해야 현재의 리스크를 피할 수 있음. - **기술적 겸손함:** 선배들의 설계를 비난하기보다 맥락을 파악하여 시스템의 '실패의 역사'를 자산화하는 태도. ###...

## 서버 한 대 뚝딱? '프로비저닝'이 뭔가요? CI/CD를 공부하다 보면 '프로비저닝(Provisioning)'이라는 단어를 자주 접하게 됩니다. 왠지 어려워 보이지만, 사실 개발자들에게는 아주 밀접해야할 개념입니다 --- ### 1. 프로비저닝, 한 마디로 정의하면? 프로비저닝은 쉽게 말해 "사용자의 요구에 맞춰 IT 자원을 준비하고, 즉시 사용할 수 있는 상태로 만드는 과정"을 의미합니다. 과거에는 서버 한 대를 준비하려면 물리적인 하드웨어를 사고, 케이블을 꽂고, 운영체제(OS)를 직접 설치해야 했죠. 하지만 지금은? 클릭 몇 번이나 코드 한 줄이면 모든 준비가 끝납니다. 이처럼 '무대를 세팅하는 전 과정'을 프로비저닝이라고 부릅니다. ### 2. 프로비저닝에도 '종류'가 있다! 어떤 자원을 준비하느냐에 따라 이름이 조금씩 달라집니다. * 서버 프로비저닝: 서버를 설치하고 OS와 소프트웨어를 설정해 서비스 준비를 마치는 과정 * 사용자(계정) 프로비저닝: 신입 사원에게 이메일, 그룹웨어 접근 권한을 자동으로 부여하는 것 * 네트워크 프로비저닝: IP 할당, 방화벽 설정 등 통신 통로를 만드는 작업 * 스토리지 프로비저닝: 데이터를 저장할 공간을 확보하고 관리하는 과정 --- ### 3. 왜 다들 '프로비저닝 자동화'를 외칠까? 예전처럼 수동으로 하지 않고 자동화를 선택하는 데는 명확한 이유가 있습니다. 1. 압도적인 속도: 며칠 걸릴 서버 세팅을 단 몇 분 만에 끝낼 수 있어요. 2. 실수 방지: 사람이 일일이 입력하다 생기는 '휴먼 에러'를 획기적으로 줄여줍니다. 3. 유연한 확장성: 사용자가 몰릴 때 자동으로 서버를 늘려주는 '오토 스케일링'도 이 자동화 기술 덕분입니다. --- ### 4. 프로비저닝 vs 배포, 헷갈리지 마세요! 💡 많은 분이 배포(Deployment)와 헷갈려하시는데요, 이렇게 ...

## [생산성] Be Focused 앱 완벽 활용 가이드: 18 인터벌 집중 루틴 집중력 향상을 위해 포모도로 기법을 사용하시는 분들이 많죠? 오늘은 그중에서도 직관적인 UI로 사랑받는 **'Be Focused'** 앱을 활용해 하루 18인터벌(약 7시간 30분 집중)을 소화하는 효율적인 설정법과 시뮬레이션을 공유합니다. --- ### 1. 'Target per day' 설정의 핵심 Be Focused 앱에서 **Target per day**는 단순한 목표 수치가 아니라, 내 하루의 **생산성 기준점**입니다. - **진행률 시각화:** 앱 상단의 원형 차트는 `현재 완료 인터벌 / Target per day`로 계산되어, 내가 오늘 목표의 몇 %를 달성했는지 실시간으로 보여줍니다. - **성취감 지표:** 목표를 18개로 설정했다면, 9개를 마쳤을 때 "오늘 절반을 해냈다"는 시각적 피드백을 통해 동기부여를 얻을 수 있습니다. - **분석 데이터:** 리포트 탭에서 일간/주간 생산성을 확인할 때, 이 타겟 수치 달성 여부가 내 성적표가 됩니다. --- ### 2. 200% 활용을 위한 꿀팁 - **태스크(Task)별 인터벌 배분:** 할 일마다 'Estimated Intervals'를 설정해 보세요. (예: 보고서 4회, 메일 1회) 예상 수치가 다 찬다고 태스크가 자동 완료되지는 않으니, 작업 종료 후 직접 체크 표시를 눌러 성취감을 느껴보세요! - **자동 전환(Auto-start) 활성화:** 의지가 약해질 때 가장 유용한 기능입니다. 'Auto-start next interval'을 켜면 작업-휴식-작업이 알람과 함께 자동으로 이어져 흐름을 강제로 유지해 줍니다. - **커스텀 알림:** 집중 시 백색소음이 필요하다면 'Tick-tock' 소리를 켜고, 고요한 환경을 선호한다면 끄는 등 본인에게 맞게 설정하세요. --- ### 3. 추천 설정...

  알고리즘의 제1원리: 반복문(Loop)을 넘어 구조적 사고(Recursion)로 대부분의 개발자가 가장 먼저 배우는 제어문은 for 또는 while 이다. 명령형 패러다임에서 '반복'은 가장 직관적인 해결책이기 때문이다. 하지만 복잡한 비즈니스 로직과 기하급수적으로 늘어나는 데이터를 다루다 보면, 단순 루프만으로는 해결하기 어려운 '구조적 복잡성'의 벽에 부딪히곤 한다. 일론 머스크의 제1원리 사고(First Principles Thinking)를 빌려, 반복문을 넘어 재귀(Recursion)와 분할 정복(Divide & Conquer)이라는 본질적인 접근법을 익혀야 하는 이유를 심도 있게 고찰해 본다. 1. 사고의 추상화: 관행적 코딩 vs 본질적 설계 일론 머스크는 스페이스X를 설립할 때 기존 로켓 산업의 '관행'을 거부했다. "로켓은 원래 비싸다"는 통념 대신, 로켓을 구성하는 원자재(탄소 섬유, 알루미늄, 리튬 등)의 가격을 분석하는 제1원리 사고 를 택했다. 그 결과 비용의 98%가 비효율적인 조립 공정과 하청 구조에서 발생한다는 본질을 파악했다. 프로그래밍도 마찬가지다. 복잡한 요구사항 앞에서 습관적으로 for 문을 중첩하는 것은 '관행적인 요리'를 하는 것과 같다. 반면, 문제를 더 이상 쪼갤 수 없는 **최소 단위(Atomic Unit)**로 분해하고 그 본질을 재정의하는 것은 '식재료의 분자 구조를 설계하는 요리'와 같다. "프로그래머의 제1원리는 Base Case(기저 조건)를 찾는 것에서 시작된다." 2. 수학적 통찰: 소인수분해와 데이터 구조화의 힘 복잡한 숫자를 분석할 때 '소인수분해'를 사용하는 이유는 숫자의 본질을 파악하기 위해서다. 나열된 데이터: 1,048,576 (크기 가늠이 어렵고 연산이 선형적임) 구조화된 데이터:  2^20 (2를 20번 곱했다는 본질이 즉시 파악됨) 이러한 구조화된 사고...