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