소프트웨어를 만들고 운영하며 배운 것을 기록합니다.https://geminikim.github.io/ko-KRhttps://geminikim.github.io/ko/articles/use-reader-writer-patterns-as-options-not-rules/https://geminikim.github.io/ko/articles/use-reader-writer-patterns-as-options-not-rules/리더·라이터와 도구 계층을 모방이 아니라 코드 규모, 도메인 거리, 레거시 제약, 팀 규칙에 따라 선택하는 기준을 설명한다.Sat, 28 Dec 2024 00:00:00 GMTarchitecturelayeringdesign-patternshttps://geminikim.github.io/ko/articles/delay-common-modules-until-boundaries-are-clear/https://geminikim.github.io/ko/articles/delay-common-modules-until-boundaries-are-clear/소유권이 드러날 때까지 공통 모듈을 늦추고, 로깅·예외·공유 규격을 구체적인 기능과 책임 중심으로 묶는 방법을 다룬다.Sat, 21 Dec 2024 00:00:00 GMTmodulesarchitecturemaintainabilityhttps://geminikim.github.io/ko/articles/earn-trust-before-changing-a-new-team/https://geminikim.github.io/ko/articles/earn-trust-before-changing-a-new-team/제때 묻고 진행 상황을 공유하며 빠르게 리뷰받고, 신뢰를 쌓은 뒤 근거 있는 작은 변화로 새 개발팀에 적응하는 방법을 다룬다.Sun, 15 Dec 2024 00:00:00 GMTteamworkcommunicationcareerhttps://geminikim.github.io/ko/articles/split-large-service-classes-by-responsibility/https://geminikim.github.io/ko/articles/split-large-service-classes-by-responsibility/개념 지도, 책임의 흐름, 테스트 경계, 구체적인 리팩터링 대안을 통해 비대해진 서비스 클래스를 나누는 방법을 설명한다.Sun, 08 Dec 2024 00:00:00 GMTrefactoringarchitectureobject-oriented-designhttps://geminikim.github.io/ko/articles/separate-query-models-from-operational-tables/https://geminikim.github.io/ko/articles/separate-query-models-from-operational-tables/운영 테이블은 비즈니스 개념에 맞게 설계하고, 복잡한 이력·어드민 검색은 별도 조회 모델에서 제공하는 방법을 다룬다.Sun, 01 Dec 2024 00:00:00 GMTdatabasearchitecturequery-modelshttps://geminikim.github.io/ko/articles/choose-enums-or-code-tables-by-change-rate/https://geminikim.github.io/ko/articles/choose-enums-or-code-tables-by-change-rate/안정적인 값은 열거형으로, 자주 바뀌는 데이터는 전용 테이블로 관리해 공통 코드 테이블이 잡동사니 저장소가 되는 일을 막는다.Sun, 24 Nov 2024 00:00:00 GMTdata-modelingenumsdatabaseshttps://geminikim.github.io/ko/articles/separate-data-access-by-domain-boundary/https://geminikim.github.io/ko/articles/separate-data-access-by-domain-boundary/같은 DB 테이블을 쓰더라도 엔티티와 저장소 경계를 나눠 외부 연동 코드로부터 핵심 규칙을 보호하는 방법을 설명한다.Mon, 18 Nov 2024 00:00:00 GMTarchitecturedata-accessdomain-boundarieshttps://geminikim.github.io/ko/articles/design-immutable-records-with-append-only-data/https://geminikim.github.io/ko/articles/design-immutable-records-with-append-only-data/이력을 선명하게 하고 동기화를 단순화하는 추가 전용 상환 데이터 구조와, 그 대신 늘어나는 저장 및 조회 비용을 살펴본다.Mon, 11 Nov 2024 00:00:00 GMTdata-modelingdatabasesoperationshttps://geminikim.github.io/ko/articles/discover-domain-concepts-in-everyday-artifacts/https://geminikim.github.io/ko/articles/discover-domain-concepts-in-everyday-artifacts/평범한 고지서에서 상환 모델의 빠진 개념을 발견하고, 현실의 단서를 검증 가능한 소프트웨어 경계로 바꾸는 과정을 살펴본다.Mon, 04 Nov 2024 00:00:00 GMTdomain-modelingsoftware-designproblem-solvinghttps://geminikim.github.io/ko/articles/rank-domain-concepts-to-focus-design/https://geminikim.github.io/ko/articles/rank-domain-concepts-to-focus-design/1급 도메인 개념을 찾고 보조 흐름을 분리해, 제한된 설계 시간을 변화의 중심에 쓰는 실용적인 방법을 설명한다.Mon, 28 Oct 2024 00:00:00 GMTdomain-modelingarchitectureprioritizationhttps://geminikim.github.io/ko/articles/grow-as-a-developer-through-varied-experience/https://geminikim.github.io/ko/articles/grow-as-a-developer-through-varied-experience/다양한 실전 경험과 실패의 반복, 비즈니스 제약에 대한 관심이 낯선 운영 문제를 푸는 개발자를 만드는 과정을 살펴본다.Tue, 22 Oct 2024 00:00:00 GMTcareergrowthproblem-solvinghttps://geminikim.github.io/ko/articles/fix-domain-boundaries-before-circular-dependencies/https://geminikim.github.io/ko/articles/fix-domain-boundaries-before-circular-dependencies/인터페이스나 의존성 역전으로 순환 참조처럼 보이는 문제를 다루기 전에 모호한 소유권과 개념 경계를 먼저 정리한다.Tue, 15 Oct 2024 00:00:00 GMTdomain-modelingarchitecturedependencieshttps://geminikim.github.io/ko/articles/contain-messy-code-at-system-boundaries/https://geminikim.github.io/ko/articles/contain-messy-code-at-system-boundaries/피할 수 없는 복잡성을 명시적인 외부 경계에 가두고, 제한된 개발 시간을 시스템의 핵심 개념에 쓰는 방법을 다룬다.Tue, 08 Oct 2024 00:00:00 GMTarchitectureboundariesmaintainabilityhttps://geminikim.github.io/ko/articles/kotlin-jpa-new-entity-id-strategies/https://geminikim.github.io/ko/articles/kotlin-jpa-new-entity-id-strategies/코틀린 JPA 엔티티의 숫자 ID를 nullable 또는 0으로 둘 때 신규 판별, 모호성, 검증 방법을 비교한다.Tue, 01 Oct 2024 00:00:00 GMTkotlinjpapersistencehttps://geminikim.github.io/ko/articles/learn-computer-science-through-engineering-work/https://geminikim.github.io/ko/articles/learn-computer-science-through-engineering-work/실제 엔지니어링 문제를 통해 CS를 배우고, 그 지식으로 업무를 어떻게 판단하고 개선했는지 보여 주는 방법을 다룬다.Wed, 25 Sep 2024 00:00:00 GMTcomputer-sciencecareerengineering-practicehttps://geminikim.github.io/ko/articles/define-and-enforce-layering-rules/https://geminikim.github.io/ko/articles/define-and-enforce-layering-rules/안정적인 레이어 역할과 선택적 상위 레이어의 조건을 정의하고, 필요할 때만 자동 검증으로 규칙을 강제하는 방법을 다룬다.Wed, 18 Sep 2024 00:00:00 GMTarchitecturelayeringstatic-analysishttps://geminikim.github.io/ko/articles/turn-production-incidents-into-shared-domain-knowledge/https://geminikim.github.io/ko/articles/turn-production-incidents-into-shared-domain-knowledge/운영 이슈 리뷰, 작업 기록, 개념도, 운영 교대를 활용해 소프트웨어 팀의 도메인 지식 격차를 줄이는 방법을 다룬다.Wed, 11 Sep 2024 00:00:00 GMTdomain-knowledgeteam-practiceoperationshttps://geminikim.github.io/ko/articles/separate-runnable-apps-by-operational-role/https://geminikim.github.io/ko/articles/separate-runnable-apps-by-operational-role/공개 API, 어드민, 배치, 운영 작업을 실행 앱으로 분리하되 코드가 충분히 성숙하기 전부터 별도 프로젝트로 쪼개지 않는 방법을 설명합니다.Wed, 04 Sep 2024 00:00:00 GMTbackendarchitecturedeploymenthttps://geminikim.github.io/ko/articles/name-readers-finders-and-searchers-by-behavior/https://geminikim.github.io/ko/articles/name-readers-finders-and-searchers-by-behavior/Reader, Finder, Searcher를 조회 건수가 아니라 직접 읽기, 추가 필터링, 복합 검색이라는 행위로 구분하는 기준을 설명한다.Thu, 29 Aug 2024 00:00:00 GMTsoftware-designmaintainabilitybackendhttps://geminikim.github.io/ko/articles/measure-before-replacing-outbox-polling/https://geminikim.github.io/ko/articles/measure-before-replacing-outbox-polling/현실적인 부하로 아웃박스 폴링을 검증하고, 로그 테일링을 도입하기 전에 더 단순한 애플리케이션 전달 방식을 검토한다.Thu, 22 Aug 2024 00:00:00 GMTarchitectureperformanceeventshttps://geminikim.github.io/ko/articles/publish-events-where-business-flow-is-visible/https://geminikim.github.io/ko/articles/publish-events-where-business-flow-is-visible/완료된 비즈니스 행위를 이해하는 계층에서 이벤트를 발행하되, 구현과 밀접한 예외는 명시적으로 구분하는 방법을 다룬다.Thu, 15 Aug 2024 00:00:00 GMTarchitecturedomain-eventslayeringhttps://geminikim.github.io/ko/articles/compose-my-page-data-without-a-my-domain/https://geminikim.github.io/ko/articles/compose-my-page-data-without-a-my-domain/사용자, 주문, 상품의 책임은 각 도메인에 유지하면서 전용 조합 계층으로 마이페이지 요약 데이터를 만드는 방법을 설명합니다.Fri, 09 Aug 2024 00:00:00 GMTbackendarchitectureapi-designhttps://geminikim.github.io/ko/articles/modules-layers-and-architecture/https://geminikim.github.io/ko/articles/modules-layers-and-architecture/모듈 경계와 코드 레벨의 레이어, 아키텍처를 구분하고 구현에 더 강한 제약이 필요할 때만 모듈을 추출하는 기준을 다룬다.Fri, 02 Aug 2024 00:00:00 GMTarchitecturemoduleslayeringhttps://geminikim.github.io/ko/articles/interfaces-after-concrete-design/https://geminikim.github.io/ko/articles/interfaces-after-concrete-design/구체적인 구현에서 검증된 공통점을 추출하고, 구현체가 하나여도 실제 경계를 만드는 인터페이스만 남기는 설계 기준을 다룬다.Fri, 26 Jul 2024 00:00:00 GMTarchitecturedesign-patternsmaintainabilityhttps://geminikim.github.io/ko/articles/choose-hexagonal-architecture-for-a-reason/https://geminikim.github.io/ko/articles/choose-hexagonal-architecture-for-a-reason/프로토콜, 격리, 규모, 성장 가능성이 추가 구조를 정당화할 때 헥사고날 아키텍처를 선택해야 한다. 유행이나 역량의 표식은 근거가 아니다.Fri, 19 Jul 2024 00:00:00 GMTarchitecturesoftware-designhttps://geminikim.github.io/ko/articles/track-database-changes-with-releases/https://geminikim.github.io/ko/articles/track-database-changes-with-releases/DB 변경을 해당 이슈와 PR에 모아 개발 환경에서 검증하고, 코드 배포 전에 릴리스에 필요한 최종 쿼리만 전달한다.Sat, 13 Jul 2024 00:00:00 GMTdatabasedeploymentoperationshttps://geminikim.github.io/ko/articles/authorization-without-redundant-reads/https://geminikim.github.io/ko/articles/authorization-without-redundant-reads/로그인 사용자를 한 번만 확인하고 접근 검증의 책임을 좁히며, 시스템 관리자와 채널 단위 권한을 구분하는 설계.Sat, 06 Jul 2024 00:00:00 GMTauthorizationarchitecturetestinghttps://geminikim.github.io/ko/articles/core-ownership-and-surrogate-keys/https://geminikim.github.io/ko/articles/core-ownership-and-surrogate-keys/공유 등록 규칙을 코어에 모으고 필요할 때만 격리를 강화하며, 바뀔 수 있는 비즈니스 유일성은 기본키와 분리하는 설계를 다룬다.Sat, 29 Jun 2024 00:00:00 GMTarchitecturemodularitydatabasehttps://geminikim.github.io/ko/articles/my-page-is-not-a-domain/https://geminikim.github.io/ko/articles/my-page-is-not-a-domain/마이페이지는 클라이언트가 보는 화면이지 비즈니스 도메인이 아닙니다. 주문, 상품, 쿠폰은 원래 주인에게 두고 경계에서 조합합니다.Sat, 22 Jun 2024 00:00:00 GMTbackenddomain-modelingapi-designhttps://geminikim.github.io/ko/articles/software-is-not-done-until-deployed/https://geminikim.github.io/ko/articles/software-is-not-done-until-deployed/묵은 PR과 늦어진 배포는 리뷰, 진단, 롤백을 어렵게 만든다. 운영 반영까지의 간격을 줄이고 관찰 가능한 상태로 관리하는 법을 다룬다.Sun, 16 Jun 2024 00:00:00 GMTsoftware-deliverydeploymentproject-managementhttps://geminikim.github.io/ko/articles/separate-shared-and-personalized-cache-state/https://geminikim.github.io/ko/articles/separate-shared-and-personalized-cache-state/리액션 상태를 재사용 가능한 조회로 조합하고, 한 회원의 개인 상태가 모두에게 노출되지 않도록 공통 합계만 분리해 캐시한다.Sun, 09 Jun 2024 00:00:00 GMTarchitecturecachingperformancehttps://geminikim.github.io/ko/articles/developer-career-lessons-from-failure/https://geminikim.github.io/ko/articles/developer-career-lessons-from-failure/실패를 다음 기회의 검증 기준으로 바꾸고, 신뢰할 수 있는 추천을 활용하며, 과거의 규칙도 새 경험 앞에서 다시 고치는 법을 다룬다.Sun, 02 Jun 2024 00:00:00 GMTcareerlearningresiliencehttps://geminikim.github.io/ko/articles/model-guest-and-member-reaction-state/https://geminikim.github.io/ko/articles/model-guest-and-member-reaction-state/공개 리액션 수와 회원별 상태를 하나의 조회 흐름으로 반환하되, 선택적 사용자 정보와 필수 인증의 경계는 분명히 나눈다.Sun, 26 May 2024 00:00:00 GMTapiauthenticationarchitecturehttps://geminikim.github.io/ko/articles/rebuild-first-migrate-second/https://geminikim.github.io/ko/articles/rebuild-first-migrate-second/재개발의 목적에 맞춰 새 시스템을 먼저 설계하고, 레거시 데이터는 명시적인 매핑과 폐기 조건을 둔 전환 계층으로 옮긴다.Mon, 20 May 2024 00:00:00 GMTarchitecturedatabasemigrationhttps://geminikim.github.io/ko/articles/model-reactions-for-requirements-and-scale/https://geminikim.github.io/ko/articles/model-reactions-for-requirements-and-scale/모호한 좋아요 요구를 정책으로 구체화하고, 데이터 증가량과 조회 비용을 계산해 리액션 모델과 변경 시점을 설계한다.Mon, 13 May 2024 00:00:00 GMTarchitecturedatabaseperformancehttps://geminikim.github.io/ko/articles/decouple-ui-from-domain-models/https://geminikim.github.io/ko/articles/decouple-ui-from-domain-models/트리 모양의 API가 트리 모양의 도메인을 요구하지는 않습니다. 클라이언트 계약은 프레젠테이션 경계에 두고 내부 개념을 조합해 응답합니다.Mon, 06 May 2024 00:00:00 GMTbackendarchitectureapi-designhttps://geminikim.github.io/ko/articles/split-client-server-responsibility-by-change-cost/https://geminikim.github.io/ko/articles/split-client-server-responsibility-by-change-cost/표시 전용 처리는 UI 가까이에 두되, 여러 클라이언트와 배포된 앱 버전 때문에 변경이 비싸다면 의미 있는 값을 서버에 모으는 기준입니다.Tue, 30 Apr 2024 00:00:00 GMTapi-designclient-serverbackward-compatibilityhttps://geminikim.github.io/ko/articles/keep-test-convenience-from-distorting-production-code/https://geminikim.github.io/ko/articles/keep-test-convenience-from-distorting-production-code/운영 행위가 더 명확해지거나 레거시에 테스트 경계가 필요할 때만 코드를 바꾸고, 테스트만 쓰는 값과 메서드를 억지로 노출하지 않는 기준입니다.Tue, 23 Apr 2024 00:00:00 GMTtestingrefactoringlegacy-codehttps://geminikim.github.io/ko/articles/legacy-modernization-and-cache-operations/https://geminikim.github.io/ko/articles/legacy-modernization-and-cache-operations/레거시 경계를 신중히 고르고 작은 단계로 옮기며, DB 최적화와 배포 실패 조건을 이해한 뒤에만 공유 캐시를 추가하는 기준입니다.Tue, 16 Apr 2024 00:00:00 GMTlegacycacheoperationshttps://geminikim.github.io/ko/articles/reversible-design-against-overengineering/https://geminikim.github.io/ko/articles/reversible-design-against-overengineering/현재 요구사항을 담백하게 구현하고 조금만 앞을 보며, 추측으로 만든 구조를 쉽게 확장하거나 제거하고 다른 방향으로 바꿀 수 있게 하는 기준입니다.Tue, 09 Apr 2024 00:00:00 GMTsoftware-designoverengineeringdata-modelinghttps://geminikim.github.io/ko/articles/persuade-with-small-prototypes-and-evidence/https://geminikim.github.io/ko/articles/persuade-with-small-prototypes-and-evidence/제안이 막힌 이유를 진단하고, 작은 증명과 내 근거, 상대 논리의 이해를 준비하며, 새 기술 도입은 회사가 부담할 위험으로 다루는 방법입니다.Wed, 03 Apr 2024 00:00:00 GMTcommunicationteamworktechnical-decisionshttps://geminikim.github.io/ko/articles/entering-a-frozen-junior-developer-market/https://geminikim.github.io/ko/articles/entering-a-frozen-junior-developer-market/채용이 좁아진 2024년에는 첫 회사의 범위를 넓히고, 실제 업무를 문제 해결 근거로 바꾸며, 기술 목록보다 사고 과정을 보여줘야 합니다.Wed, 27 Mar 2024 00:00:00 GMTcareerhiringjunior-developerhttps://geminikim.github.io/ko/articles/design-apis-for-clarity-not-rest-purity/https://geminikim.github.io/ko/articles/design-apis-for-clarity-not-rest-purity/REST의 장점은 활용하되 클라이언트의 이해, 팀의 일관성, 도메인 경계와 변경 비용을 기준으로 HTTP 계약을 결정하는 방법입니다.Wed, 20 Mar 2024 00:00:00 GMTapi-designresthttphttps://geminikim.github.io/ko/articles/validate-at-boundaries-keep-core-flows-simple/https://geminikim.github.io/ko/articles/validate-at-boundaries-keep-core-flows-simple/API 입력을 프레젠테이션 경계에서 온전한 비즈니스 값으로 바꾸고, 널을 안쪽에 넘기지 않으며, 저장 데이터는 들어올 때 검증하는 방법입니다.Wed, 13 Mar 2024 00:00:00 GMTvalidationapi-designlayered-architecturehttps://geminikim.github.io/ko/articles/move-from-si-to-product-development/https://geminikim.github.io/ko/articles/move-from-si-to-product-development/SI에서 서비스 팀으로 옮긴 데에는 도움과 운이 컸습니다. 반복 가능한 전략은 목표 채용 요건을 읽고 관련 역량과 경험을 만드는 것입니다.Thu, 07 Mar 2024 00:00:00 GMTcareergrowthhttps://geminikim.github.io/ko/articles/start-tests-then-refactor-them/https://geminikim.github.io/ko/articles/start-tests-then-refactor-them/지키고 싶은 행위를 검증하는 테스트부터 만들고, 실행에 필요한 만큼 목을 쓰며, 반복과 리뷰를 통해 테스트 설계를 개선하는 방법입니다.Thu, 29 Feb 2024 00:00:00 GMTtestingrefactoringbackendhttps://geminikim.github.io/ko/articles/separate-api-requests-from-domain-models/https://geminikim.github.io/ko/articles/separate-api-requests-from-domain-models/프레젠테이션 경계에서 외부 요청을 비즈니스가 소유한 값으로 바꿔 API는 안쪽을 의존하고 코어는 바깥을 모르도록 만드는 방법입니다.Thu, 22 Feb 2024 00:00:00 GMTbackendarchitectureapi-designmodularityhttps://geminikim.github.io/ko/articles/performance-tests-from-traffic-and-failure-models/https://geminikim.github.io/ko/articles/performance-tests-from-traffic-and-failure-models/부하 도구를 고르기 전에 트래픽 규모와 유입 모양을 추정하고, 여유를 정하며, 실제 위험이 있는 기능에만 검증 근거를 요구하는 방법입니다.Thu, 15 Feb 2024 00:00:00 GMTperformancetestingoperationshttps://geminikim.github.io/ko/articles/choose-foreign-keys-for-operational-reality/https://geminikim.github.io/ko/articles/choose-foreign-keys-for-operational-reality/무결성 요구, 장애 대응, 배포 절차, 운영 DB의 주체를 기준으로 외래키와 인덱스, ORM 연관관계를 각각 선택하는 방법입니다.Fri, 09 Feb 2024 00:00:00 GMTdatabaseoperationsjpahttps://geminikim.github.io/ko/articles/assign-cross-domain-actions-by-ownership/https://geminikim.github.io/ko/articles/assign-cross-domain-actions-by-ownership/호출자 쪽 인터페이스를 모듈 사이에 두기 전에 행위의 주인을 정하고, 호출자가 그 도메인의 기능을 의존하게 만드는 기준을 설명합니다.Fri, 02 Feb 2024 00:00:00 GMTbackenddomain-modelingmodularityhttps://geminikim.github.io/ko/articles/keep-domain-enums-in-the-domain-module/https://geminikim.github.io/ko/articles/keep-domain-enums-in-the-domain-module/비즈니스 열거형은 도메인이 소유하고 스토리지는 안쪽을 의존하게 하며, 경계가 익는 동안에만 작은 공유 열거형 모듈을 두는 방법입니다.Fri, 26 Jan 2024 00:00:00 GMTmodularityarchitecturedependencieshttps://geminikim.github.io/ko/articles/design-provider-identity-and-auth-boundaries/https://geminikim.github.io/ko/articles/design-provider-identity-and-auth-boundaries/작은 플랫폼 API가 제공자 키를 도메인 식별자로 바꾸고 데이터를 구분하며, 규모에 맞는 인증 경계를 선택하는 과정을 다룹니다.Fri, 19 Jan 2024 00:00:00 GMTapi-designbackendarchitecturehttps://geminikim.github.io/ko/articles/place-cross-domain-work-by-business-ownership/https://geminikim.github.io/ko/articles/place-cross-domain-work-by-business-ownership/주된 행위와 다른 도메인의 규칙을 함께 다루는 코드를 비즈니스 소유권, 응집, 임포트, 패키지 이동 실험으로 배치하는 방법입니다.Sat, 13 Jan 2024 00:00:00 GMTpackagingdomain-modelingarchitecturehttps://geminikim.github.io/ko/articles/jpa-domain-modeling-without-association-overload/https://geminikim.github.io/ko/articles/jpa-domain-modeling-without-association-overload/ID에서 시작하고 생명주기가 실제로 맞을 때만 연관관계를 추가하며, 비즈니스 개념은 엔티티와 독립적으로 표현하는 방법을 다룹니다.Sat, 06 Jan 2024 00:00:00 GMTjpadomain-modelingbackendhttps://geminikim.github.io/ko/articles/high-traffic-experience-without-traffic/https://geminikim.github.io/ko/articles/high-traffic-experience-without-traffic/작은 서비스를 직접 운영하고 의도적으로 부하를 만들어 병목을 찾고 고친 과정을 보여주세요. 다만 부하 테스트를 운영 경험이라고 과장해서는 안 됩니다.Sat, 09 Dec 2023 00:00:00 GMTperformancecareerbackendhttps://geminikim.github.io/ko/articles/reliable-database-tests-with-testcontainers/https://geminikim.github.io/ko/articles/reliable-database-tests-with-testcontainers/잡아야 할 실패에 따라 목, 인메모리 DB, Testcontainers, 실제 DB를 고르고 일반 테스트는 공유 인프라에서 격리합니다.Mon, 04 Dec 2023 00:00:00 GMTtestingdatabasesbackendhttps://geminikim.github.io/ko/articles/dto-boundaries-between-layers/https://geminikim.github.io/ko/articles/dto-boundaries-between-layers/데이터가 서로 다른 계약을 가진 경계를 넘을 때 DTO를 사용합니다. 매핑에도 비용이 들지만 외부 요청 형태가 서비스 내부를 지배하게 두는 데도 비용이 듭니다.Thu, 30 Nov 2023 00:00:00 GMTbackendarchitectureapi-designhttps://geminikim.github.io/ko/articles/practical-git-commit-branch-rules/https://geminikim.github.io/ko/articles/practical-git-commit-branch-rules/커밋을 다듬기 전에 작업부터 나누고, 동료가 검토하기 좋은 PR과 다음 사람이 변경 이유를 추적하고 릴리스를 복구할 수 있는 이력을 남깁니다.Sat, 25 Nov 2023 00:00:00 GMTgitcollaborationsoftware-engineeringhttps://geminikim.github.io/ko/articles/circuit-breaker-placement/https://geminikim.github.io/ko/articles/circuit-breaker-placement/서킷브레이커, 타임아웃, 캐시 폴백 같은 외부 호출 정책은 I/O 구현체 가까이에 두고, 도메인 코드는 그 결과가 비즈니스에서 무엇을 뜻하는지 결정합니다.Tue, 21 Nov 2023 00:00:00 GMTbackendreliabilityarchitecturehttps://geminikim.github.io/ko/articles/timeouts-retries-and-failure-propagation/https://geminikim.github.io/ko/articles/timeouts-retries-and-failure-propagation/모든 실패에 같은 재시도 규칙을 붙이지 말고, 사용자가 기다릴 수 있는 시간과 실패 뒤에 알 수 있는 사실을 기준으로 타임아웃과 복구 정책을 설계합니다.Thu, 16 Nov 2023 00:00:00 GMTbackendreliabilitydistributed-systemshttps://geminikim.github.io/ko/articles/domain-maturity-and-module-boundaries/https://geminikim.github.io/ko/articles/domain-maturity-and-module-boundaries/도메인 성숙도는 정책과 행동, 운영 현실을 얼마나 이해했는지에서 나옵니다. 추측을 일찍 굳히지 말고 운영에서 드러난 책임으로 모듈 경계를 정해야 합니다.Sun, 12 Nov 2023 00:00:00 GMTarchitecturedomain-driven-designbackendhttps://geminikim.github.io/ko/articles/grow-software-in-stages/https://geminikim.github.io/ko/articles/grow-software-in-stages/동작하는 코드에서 시작해 실제 응집과 규모가 더 강한 경계를 요구할 때 함수, 클래스, 패키지, 모듈과 프로젝트를 단계적으로 추출합니다.Tue, 07 Nov 2023 00:00:00 GMTsoftware-designarchitecturemodularityhttps://geminikim.github.io/ko/articles/cohesive-packages-with-modules-and-layers/https://geminikim.github.io/ko/articles/cohesive-packages-with-modules-and-layers/모듈, 패키지와 아키텍처 레이어는 서로 다른 문제를 풉니다. 관련 동작은 가까이 두고 레이어는 기능을 흩뜨리지 않은 채 역할을 설명해야 합니다.Thu, 02 Nov 2023 00:00:00 GMTarchitecturemodularitypackaginghttps://geminikim.github.io/ko/articles/frequent-dependency-upgrades/https://geminikim.github.io/ko/articles/frequent-dependency-upgrades/우선순위에 따라 의존성을 자주 올리면 변경을 작게 유지하고 호환성 문제를 일찍 발견하며 운영 서비스에 부채가 조용히 쌓이는 일을 막을 수 있습니다.Sun, 29 Oct 2023 00:00:00 GMTdependenciesmaintenancetechnical-debthttps://geminikim.github.io/ko/articles/software-that-survives-developer-departure/https://geminikim.github.io/ko/articles/software-that-survives-developer-departure/좋은 회사 소프트웨어는 부채를 줄이고 팀의 운영 능력에 맞으며, 처음 만든 개발자가 떠난 뒤에도 이해하고 고칠 수 있어야 합니다.Tue, 24 Oct 2023 00:00:00 GMTmaintainabilityengineering-culturesoftware-designhttps://geminikim.github.io/ko/articles/unit-tests-protect-business-intent/https://geminikim.github.io/ko/articles/unit-tests-protect-business-intent/비즈니스 레이어 단위 테스트는 설계를 돕고, 중요한 동작을 기록하며, 다음 개발자가 위험한 변경 앞에서 한 번 더 생각하게 할 때 의미가 있습니다.Fri, 20 Oct 2023 00:00:00 GMTtestingarchitecturemaintainabilityhttps://geminikim.github.io/ko/articles/idempotent-ai-tool-calls/https://geminikim.github.io/ko/articles/idempotent-ai-tool-calls/분산 시스템과 AI 워크플로에서 재시도는 정상입니다. DB 제약, 멱등 키, 제한된 재시도로 도구 호출의 중복 부작용을 막는 방법을 정리합니다.Sun, 15 Oct 2023 00:00:00 GMTai-agentsbackendreliabilityhttps://geminikim.github.io/ko/articles/premature-multi-module-complexity/https://geminikim.github.io/ko/articles/premature-multi-module-complexity/모듈은 이해하지 못한 도메인이나 아키텍처 그림을 미리 고정하는 장치가 아니라 구현에서 발견한 경계를 강제하는 수단이어야 합니다.Wed, 11 Oct 2023 00:00:00 GMTarchitecturemodularitysoftware-designhttps://geminikim.github.io/ko/articles/gradle-dependency-boundaries/https://geminikim.github.io/ko/articles/gradle-dependency-boundaries/Gradle의 implementation, api, runtimeOnly, compileOnly를 의도적으로 사용해 모듈 접근을 제한하고 우발적인 결합을 막는 방법을 설명합니다.Fri, 06 Oct 2023 00:00:00 GMTgradlearchitecturemodularityhttps://geminikim.github.io/ko/articles/operate-toy-project-for-real-users/https://geminikim.github.io/ko/articles/operate-toy-project-for-real-users/토이 프로젝트에서 서비스 경험을 얻으려면 하나의 목표를 정하고, 출시하고, 실제 사용자를 만나며, 리텐션과 종료 시점을 봐야 합니다.Mon, 02 Oct 2023 00:00:00 GMTproductoperationsside-projecthttps://geminikim.github.io/ko/articles/isolate-admin-from-domain/https://geminikim.github.io/ko/articles/isolate-admin-from-domain/어드민 API는 조회, 수정, 릴리스 위험이 다릅니다. 운영 편의가 핵심 서비스를 바꾸지 않도록 모듈이나 저장소로 격리합니다.Wed, 27 Sep 2023 00:00:00 GMTarchitecturebackendadminhttps://geminikim.github.io/ko/articles/reader-writer-business-flow/https://geminikim.github.io/ko/articles/reader-writer-business-flow/리더와 라이터는 저장소 세부사항과 변경 범위를 감추고 비즈니스 계층에 정책을 남깁니다. 다만 서비스 수명이 그 비용을 정당화해야 합니다.Fri, 22 Sep 2023 00:00:00 GMTsoftware-designbackendmaintainabilityhttps://geminikim.github.io/ko/articles/trace-id-across-distributed-services/https://geminikim.github.io/ko/articles/trace-id-across-distributed-services/민감한 정보를 노출하거나 저장소를 로그로 넘치게 하지 않으면서 HTTP 호출과 비동기 이벤트를 하나의 요청 맥락으로 추적합니다.Mon, 18 Sep 2023 00:00:00 GMTobservabilitydistributed-systemsbackendhttps://geminikim.github.io/ko/articles/define-problems-from-user-perspective/https://geminikim.github.io/ko/articles/define-problems-from-user-perspective/기술 부하와 제품 가치를 구분하고, 만든 것을 실제로 출시하며, 사용자가 왜 선택할지 계속 물어야 문제 해결 능력이 자랍니다.Wed, 13 Sep 2023 00:00:00 GMTproductcareerproblem-solvinghttps://geminikim.github.io/ko/articles/reuse-below-use-case-layer/https://geminikim.github.io/ko/articles/reuse-below-use-case-layer/유즈케이스끼리 재사용하면 비즈니스 변경이 번지고 순환 참조가 생깁니다. 위에서 조합하거나 아래의 구현 컴포넌트를 추출합니다.Sat, 09 Sep 2023 00:00:00 GMTarchitecturebackendsoftware-designhttps://geminikim.github.io/ko/articles/experience-over-development-jargon/https://geminikim.github.io/ko/articles/experience-over-development-jargon/이론과 패턴은 유용한 참고 자료지만, 개발자는 코드와 트레이드오프, 운영 결과를 자기 언어로 설명할 수 있어야 합니다.Mon, 04 Sep 2023 00:00:00 GMTcareersoftware-designcollaborationhttps://geminikim.github.io/ko/articles/split-large-service-class/https://geminikim.github.io/ko/articles/split-large-service-class/생성자 의존성과 import로 비대해진 서비스를 진단하고, 새로운 아키텍처 이름을 붙이기 전에 응집된 책임부터 분리합니다.Thu, 31 Aug 2023 00:00:00 GMTbackendrefactoringarchitecturehttps://geminikim.github.io/ko/articles/normalization-from-requirements/https://geminikim.github.io/ko/articles/normalization-from-requirements/정규화 수준을 점수처럼 높이기보다 값의 변경 의미, 조회 비용, 데이터가 보존해야 할 객체 관계를 기준으로 테이블을 설계합니다.Sat, 26 Aug 2023 00:00:00 GMTdatabasebackenddesign