본문으로 건너뛰기
GGemini Kim
  • Home
  • Articles
  • About
KO/EN

Articles

생각과 경험을 기록합니다.

  1. 2024년 12월 28일

    리더와 라이터는 아키텍처 규칙이 아니라 선택지다

    리더·라이터와 도구 계층을 모방이 아니라 코드 규모, 도메인 거리, 레거시 제약, 팀 규칙에 따라 선택하는 기준을 설명한다.

    • 아키텍처
    읽기 ↗
  2. 2024년 12월 21일

    공통 모듈의 함정: 구체적인 기능으로 코드를 응집하라

    소유권이 드러날 때까지 공통 모듈을 늦추고, 로깅·예외·공유 규격을 구체적인 기능과 책임 중심으로 묶는 방법을 다룬다.

    • 아키텍처
    • 테스트와 품질
    읽기 ↗
  3. 2024년 12월 15일

    바꾸기 전에 먼저 팀의 사람이 되어라

    제때 묻고 진행 상황을 공유하며 빠르게 리뷰받고, 신뢰를 쌓은 뒤 근거 있는 작은 변화로 새 개발팀에 적응하는 방법을 다룬다.

    • 커리어와 학습
    • 협업
    읽기 ↗
  4. 2024년 12월 8일

    거대한 서비스 클래스를 책임 단위로 나누는 법

    개념 지도, 책임의 흐름, 테스트 경계, 구체적인 리팩터링 대안을 통해 비대해진 서비스 클래스를 나누는 방법을 설명한다.

    • 아키텍처
    • 테스트와 품질
    읽기 ↗
  5. 2024년 12월 1일

    운영 테이블을 지키는 별도 조회 모델 설계

    운영 테이블은 비즈니스 개념에 맞게 설계하고, 복잡한 이력·어드민 검색은 별도 조회 모델에서 제공하는 방법을 다룬다.

    • 아키텍처
    • 데이터와 영속성
    읽기 ↗
  6. 2024년 11월 24일

    열거형인가 코드 테이블인가: 변화 주기로 결정하라

    안정적인 값은 열거형으로, 자주 바뀌는 데이터는 전용 테이블로 관리해 공통 코드 테이블이 잡동사니 저장소가 되는 일을 막는다.

    • 도메인 모델링
    • 데이터와 영속성
    읽기 ↗
  7. 2024년 11월 18일

    하나의 DB에서도 도메인별 데이터 접근 경계를 나누는 법

    같은 DB 테이블을 쓰더라도 엔티티와 저장소 경계를 나눠 외부 연동 코드로부터 핵심 규칙을 보호하는 방법을 설명한다.

    • 아키텍처
    • 도메인 모델링
    • 데이터와 영속성
    읽기 ↗
  8. 2024년 11월 11일

    덮어쓰지 말고 쌓아라: 불변 운영 데이터 설계

    이력을 선명하게 하고 동기화를 단순화하는 추가 전용 상환 데이터 구조와, 그 대신 늘어나는 저장 및 조회 비용을 살펴본다.

    • 데이터와 영속성
    • 신뢰성과 운영
    읽기 ↗
  9. 2024년 11월 4일

    관리비 고지서에서 연체 도메인을 발견한 순간

    평범한 고지서에서 상환 모델의 빠진 개념을 발견하고, 현실의 단서를 검증 가능한 소프트웨어 경계로 바꾸는 과정을 살펴본다.

    • 아키텍처
    • 도메인 모델링
    • 커리어와 학습
    읽기 ↗
  10. 2024년 10월 28일

    설계 자원을 쓰기 전에 핵심 개념의 우선순위를 정하라

    1급 도메인 개념을 찾고 보조 흐름을 분리해, 제한된 설계 시간을 변화의 중심에 쓰는 실용적인 방법을 설명한다.

    • 아키텍처
    • 도메인 모델링
    • 커리어와 학습
    읽기 ↗
  11. 2024년 10월 22일

    경험과 반복이 지속 성장하는 개발자를 만든다

    다양한 실전 경험과 실패의 반복, 비즈니스 제약에 대한 관심이 낯선 운영 문제를 푸는 개발자를 만드는 과정을 살펴본다.

    • 커리어와 학습
    읽기 ↗
  12. 2024년 10월 15일

    순환 참조를 고치기 전에 도메인 경계부터 바로잡기

    인터페이스나 의존성 역전으로 순환 참조처럼 보이는 문제를 다루기 전에 모호한 소유권과 개념 경계를 먼저 정리한다.

    • 아키텍처
    • 백엔드 엔지니어링
    • 도메인 모델링
    읽기 ↗
  13. 2024년 10월 8일

    코어를 깨끗하게 지키는 의도적인 오염 경계

    피할 수 없는 복잡성을 명시적인 외부 경계에 가두고, 제한된 개발 시간을 시스템의 핵심 개념에 쓰는 방법을 다룬다.

    • 아키텍처
    • 테스트와 품질
    읽기 ↗
  14. 2024년 10월 1일

    널인가 0인가: 코틀린 JPA 엔티티 ID 전략

    코틀린 JPA 엔티티의 숫자 ID를 nullable 또는 0으로 둘 때 신규 판별, 모호성, 검증 방법을 비교한다.

    • 백엔드 엔지니어링
    • 데이터와 영속성
    읽기 ↗
  15. 2024년 9월 25일

    CS 지식은 실무 문제를 해결할 때 역량이 된다

    실제 엔지니어링 문제를 통해 CS를 배우고, 그 지식으로 업무를 어떻게 판단하고 개선했는지 보여 주는 방법을 다룬다.

    • 커리어와 학습
    읽기 ↗
  16. 2024년 9월 18일

    사람이 이해하고 빌드가 지키는 레이어 규칙

    안정적인 레이어 역할과 선택적 상위 레이어의 조건을 정의하고, 필요할 때만 자동 검증으로 규칙을 강제하는 방법을 다룬다.

    • 아키텍처
    • 테스트와 품질
    읽기 ↗
  17. 2024년 9월 11일

    운영 이슈를 팀의 공통 도메인 지식으로 바꾸는 법

    운영 이슈 리뷰, 작업 기록, 개념도, 운영 교대를 활용해 소프트웨어 팀의 도메인 지식 격차를 줄이는 방법을 다룬다.

    • 도메인 모델링
    • 신뢰성과 운영
    • 협업
    읽기 ↗
  18. 2024년 9월 4일

    한 프로젝트 안에서 실행 역할별 배포 경계 만들기

    공개 API, 어드민, 배치, 운영 작업을 실행 앱으로 분리하되 코드가 충분히 성숙하기 전부터 별도 프로젝트로 쪼개지 않는 방법을 설명합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • 배포와 진화
    읽기 ↗
  19. 2024년 8월 29일

    Reader, Finder, Searcher를 행위로 구분하는 법

    Reader, Finder, Searcher를 조회 건수가 아니라 직접 읽기, 추가 필터링, 복합 검색이라는 행위로 구분하는 기준을 설명한다.

    • 아키텍처
    • 백엔드 엔지니어링
    • 테스트와 품질
    읽기 ↗
  20. 2024년 8월 22일

    아웃박스 폴링을 바꾸기 전에 측정하라

    현실적인 부하로 아웃박스 폴링을 검증하고, 로그 테일링을 도입하기 전에 더 단순한 애플리케이션 전달 방식을 검토한다.

    • 아키텍처
    • 도메인 모델링
    • 성능과 확장성
    읽기 ↗
  21. 2024년 8월 15일

    비즈니스 흐름이 보이는 곳에서 이벤트 발행하기

    완료된 비즈니스 행위를 이해하는 계층에서 이벤트를 발행하되, 구현과 밀접한 예외는 명시적으로 구분하는 방법을 다룬다.

    • 아키텍처
    • 도메인 모델링
    읽기 ↗
  22. 2024년 8월 9일

    '마이' 도메인 없이 마이페이지 데이터를 조합하는 법

    사용자, 주문, 상품의 책임은 각 도메인에 유지하면서 전용 조합 계층으로 마이페이지 요약 데이터를 만드는 방법을 설명합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • API 설계
    읽기 ↗
  23. 2024년 8월 2일

    모듈, 레이어, 아키텍처는 서로 다른 결정이다

    모듈 경계와 코드 레벨의 레이어, 아키텍처를 구분하고 구현에 더 강한 제약이 필요할 때만 모듈을 추출하는 기준을 다룬다.

    • 아키텍처
    읽기 ↗
  24. 2024년 7월 26일

    추상화는 구현 뒤에 온다: Service와 Impl 관행 다시 보기

    구체적인 구현에서 검증된 공통점을 추출하고, 구현체가 하나여도 실제 경계를 만드는 인터페이스만 남기는 설계 기준을 다룬다.

    • 아키텍처
    • 테스트와 품질
    읽기 ↗
  25. 2024년 7월 19일

    헥사고날 아키텍처를 선택하기 전에 물어야 할 것

    프로토콜, 격리, 규모, 성장 가능성이 추가 구조를 정당화할 때 헥사고날 아키텍처를 선택해야 한다. 유행이나 역량의 표식은 근거가 아니다.

    • 아키텍처
    읽기 ↗
  26. 2024년 7월 13일

    DB 변경 쿼리를 작업과 배포 단위로 추적하기

    DB 변경을 해당 이슈와 PR에 모아 개발 환경에서 검증하고, 코드 배포 전에 릴리스에 필요한 최종 쿼리만 전달한다.

    • 데이터와 영속성
    • 신뢰성과 운영
    • 배포와 진화
    읽기 ↗
  27. 2024년 7월 6일

    불필요한 조회 없이 권한 검증을 설계하는 법

    로그인 사용자를 한 번만 확인하고 접근 검증의 책임을 좁히며, 시스템 관리자와 채널 단위 권한을 구분하는 설계.

    • 아키텍처
    • API 설계
    • 테스트와 품질
    읽기 ↗
  28. 2024년 6월 29일

    코어 책임과 대리키로 변경에 대비하기

    공유 등록 규칙을 코어에 모으고 필요할 때만 격리를 강화하며, 바뀔 수 있는 비즈니스 유일성은 기본키와 분리하는 설계를 다룬다.

    • 아키텍처
    • 데이터와 영속성
    읽기 ↗
  29. 2024년 6월 22일

    '마이'는 왜 도메인이 아닌가

    마이페이지는 클라이언트가 보는 화면이지 비즈니스 도메인이 아닙니다. 주문, 상품, 쿠폰은 원래 주인에게 두고 경계에서 조합합니다.

    • 백엔드 엔지니어링
    • 도메인 모델링
    • API 설계
    읽기 ↗
  30. 2024년 6월 16일

    배포되기 전까지 개발은 끝나지 않는다

    묵은 PR과 늦어진 배포는 리뷰, 진단, 롤백을 어렵게 만든다. 운영 반영까지의 간격을 줄이고 관찰 가능한 상태로 관리하는 법을 다룬다.

    • 배포와 진화
    읽기 ↗
  31. 2024년 6월 9일

    공통 집계와 사용자별 캐시 상태를 분리하라

    리액션 상태를 재사용 가능한 조회로 조합하고, 한 회원의 개인 상태가 모두에게 노출되지 않도록 공통 합계만 분리해 캐시한다.

    • 아키텍처
    • 성능과 확장성
    읽기 ↗
  32. 2024년 6월 2일

    거듭된 실패가 가르쳐 준 개발자 커리어의 기준

    실패를 다음 기회의 검증 기준으로 바꾸고, 신뢰할 수 있는 추천을 활용하며, 과거의 규칙도 새 경험 앞에서 다시 고치는 법을 다룬다.

    • 신뢰성과 운영
    • 커리어와 학습
    읽기 ↗
  33. 2024년 5월 26일

    회원과 비회원을 함께 다루는 조회 모델

    공개 리액션 수와 회원별 상태를 하나의 조회 흐름으로 반환하되, 선택적 사용자 정보와 필수 인증의 경계는 분명히 나눈다.

    • 아키텍처
    • API 설계
    읽기 ↗
  34. 2024년 5월 20일

    재개발에서는 새 구조를 먼저 설계하라

    재개발의 목적에 맞춰 새 시스템을 먼저 설계하고, 레거시 데이터는 명시적인 매핑과 폐기 조건을 둔 전환 계층으로 옮긴다.

    • 아키텍처
    • 데이터와 영속성
    • 배포와 진화
    읽기 ↗
  35. 2024년 5월 13일

    요구사항과 규모에서 시작하는 리액션 기능 설계

    모호한 좋아요 요구를 정책으로 구체화하고, 데이터 증가량과 조회 비용을 계산해 리액션 모델과 변경 시점을 설계한다.

    • 아키텍처
    • 데이터와 영속성
    • 성능과 확장성
    읽기 ↗
  36. 2024년 5월 6일

    UI 모양을 넘어서는 도메인 모델 설계

    트리 모양의 API가 트리 모양의 도메인을 요구하지는 않습니다. 클라이언트 계약은 프레젠테이션 경계에 두고 내부 개념을 조합해 응답합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • API 설계
    읽기 ↗
  37. 2024년 4월 30일

    변경 비용으로 나누는 클라이언트와 서버의 책임

    표시 전용 처리는 UI 가까이에 두되, 여러 클라이언트와 배포된 앱 버전 때문에 변경이 비싸다면 의미 있는 값을 서버에 모으는 기준입니다.

    • API 설계
    • 배포와 진화
    읽기 ↗
  38. 2024년 4월 23일

    테스트 편의 때문에 운영 코드의 의미를 바꾸지 마라

    운영 행위가 더 명확해지거나 레거시에 테스트 경계가 필요할 때만 코드를 바꾸고, 테스트만 쓰는 값과 메서드를 억지로 노출하지 않는 기준입니다.

    • 테스트와 품질
    • 배포와 진화
    읽기 ↗
  39. 2024년 4월 16일

    레거시는 점진적으로, 캐시는 운영까지 설계하라

    레거시 경계를 신중히 고르고 작은 단계로 옮기며, DB 최적화와 배포 실패 조건을 이해한 뒤에만 공유 캐시를 추가하는 기준입니다.

    • 신뢰성과 운영
    • 성능과 확장성
    • 배포와 진화
    읽기 ↗
  40. 2024년 4월 9일

    오버엔지니어링을 막는 되돌릴 수 있는 설계

    현재 요구사항을 담백하게 구현하고 조금만 앞을 보며, 추측으로 만든 구조를 쉽게 확장하거나 제거하고 다른 방향으로 바꿀 수 있게 하는 기준입니다.

    • 아키텍처
    • 데이터와 영속성
    읽기 ↗
  41. 2024년 4월 3일

    의견보다 작은 실험으로 기술적 설득을 시작하라

    제안이 막힌 이유를 진단하고, 작은 증명과 내 근거, 상대 논리의 이해를 준비하며, 새 기술 도입은 회사가 부담할 위험으로 다루는 방법입니다.

    • 아키텍처
    • 협업
    읽기 ↗
  42. 2024년 3월 27일

    얼어붙은 신입 개발자 시장을 통과하는 현실적인 전략

    채용이 좁아진 2024년에는 첫 회사의 범위를 넓히고, 실제 업무를 문제 해결 근거로 바꾸며, 기술 목록보다 사고 과정을 보여줘야 합니다.

    • 커리어와 학습
    읽기 ↗
  43. 2024년 3월 20일

    REST 순수성보다 명확한 API를 설계하라

    REST의 장점은 활용하되 클라이언트의 이해, 팀의 일관성, 도메인 경계와 변경 비용을 기준으로 HTTP 계약을 결정하는 방법입니다.

    • API 설계
    읽기 ↗
  44. 2024년 3월 13일

    경계에서 검증하고 핵심 흐름은 단순하게

    API 입력을 프레젠테이션 경계에서 온전한 비즈니스 값으로 바꾸고, 널을 안쪽에 넘기지 않으며, 저장 데이터는 들어올 때 검증하는 방법입니다.

    • 아키텍처
    • API 설계
    읽기 ↗
  45. 2024년 3월 7일

    SI에서 서비스 개발로: 채용 요건을 학습 계획으로 바꾸기

    SI에서 서비스 팀으로 옮긴 데에는 도움과 운이 컸습니다. 반복 가능한 전략은 목표 채용 요건을 읽고 관련 역량과 경험을 만드는 것입니다.

    • 커리어와 학습
    읽기 ↗
  46. 2024년 2월 29일

    첫 테스트는 서툴러도 된다, 나중에 리팩터링하라

    지키고 싶은 행위를 검증하는 테스트부터 만들고, 실행에 필요한 만큼 목을 쓰며, 반복과 리뷰를 통해 테스트 설계를 개선하는 방법입니다.

    • 백엔드 엔지니어링
    • 테스트와 품질
    읽기 ↗
  47. 2024년 2월 22일

    API 요청 모델을 핵심 도메인에서 분리하라

    프레젠테이션 경계에서 외부 요청을 비즈니스가 소유한 값으로 바꿔 API는 안쪽을 의존하고 코어는 바깥을 모르도록 만드는 방법입니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • API 설계
    읽기 ↗
  48. 2024년 2월 15일

    실제 트래픽 모양에서 성능 테스트를 설계하라

    부하 도구를 고르기 전에 트래픽 규모와 유입 모양을 추정하고, 여유를 정하며, 실제 위험이 있는 기능에만 검증 근거를 요구하는 방법입니다.

    • 테스트와 품질
    • 신뢰성과 운영
    • 성능과 확장성
    읽기 ↗
  49. 2024년 2월 9일

    외래키는 규칙이 아니라 운영상의 선택이다

    무결성 요구, 장애 대응, 배포 절차, 운영 DB의 주체를 기준으로 외래키와 인덱스, ORM 연관관계를 각각 선택하는 방법입니다.

    • 백엔드 엔지니어링
    • 데이터와 영속성
    • 신뢰성과 운영
    읽기 ↗
  50. 2024년 2월 2일

    도메인 간 행위는 책임의 주인에게 맡겨라

    호출자 쪽 인터페이스를 모듈 사이에 두기 전에 행위의 주인을 정하고, 호출자가 그 도메인의 기능을 의존하게 만드는 기준을 설명합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • 도메인 모델링
    읽기 ↗
  51. 2024년 1월 26일

    열거형의 주인은 누구인가: 도메인 모듈 의존성 설계

    비즈니스 열거형은 도메인이 소유하고 스토리지는 안쪽을 의존하게 하며, 경계가 익는 동안에만 작은 공유 열거형 모듈을 두는 방법입니다.

    • 아키텍처
    • 백엔드 엔지니어링
    읽기 ↗
  52. 2024년 1월 19일

    플랫폼 API에서 제공자 식별과 인증 경계를 나누는 법

    작은 플랫폼 API가 제공자 키를 도메인 식별자로 바꾸고 데이터를 구분하며, 규모에 맞는 인증 경계를 선택하는 과정을 다룹니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • API 설계
    읽기 ↗
  53. 2024년 1월 13일

    여러 도메인을 엮는 코드는 어디에 둘까

    주된 행위와 다른 도메인의 규칙을 함께 다루는 코드를 비즈니스 소유권, 응집, 임포트, 패키지 이동 실험으로 배치하는 방법입니다.

    • 아키텍처
    • 도메인 모델링
    읽기 ↗
  54. 2024년 1월 6일

    도메인 모델을 먼저 보는 보수적인 JPA 연관관계 설계

    ID에서 시작하고 생명주기가 실제로 맞을 때만 연관관계를 추가하며, 비즈니스 개념은 엔티티와 독립적으로 표현하는 방법을 다룹니다.

    • 백엔드 엔지니어링
    • 도메인 모델링
    읽기 ↗
  55. 2023년 12월 9일

    실제 트래픽이 없어도 대용량 시스템 대응은 연습할 수 있습니다

    작은 서비스를 직접 운영하고 의도적으로 부하를 만들어 병목을 찾고 고친 과정을 보여주세요. 다만 부하 테스트를 운영 경험이라고 과장해서는 안 됩니다.

    • 백엔드 엔지니어링
    • 성능과 확장성
    • 커리어와 학습
    읽기 ↗
  56. 2023년 12월 4일

    공유 테스트 DB 없이 신뢰할 수 있는 데이터베이스 테스트 만들기

    잡아야 할 실패에 따라 목, 인메모리 DB, Testcontainers, 실제 DB를 고르고 일반 테스트는 공유 인프라에서 격리합니다.

    • 백엔드 엔지니어링
    • 데이터와 영속성
    • 테스트와 품질
    읽기 ↗
  57. 2023년 11월 30일

    계층마다 DTO를 습관처럼 만들지 마세요

    데이터가 서로 다른 계약을 가진 경계를 넘을 때 DTO를 사용합니다. 매핑에도 비용이 들지만 외부 요청 형태가 서비스 내부를 지배하게 두는 데도 비용이 듭니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • API 설계
    읽기 ↗
  58. 2023년 11월 25일

    Git 이력은 개인 작업일지가 아니라 팀의 자산입니다

    커밋을 다듬기 전에 작업부터 나누고, 동료가 검토하기 좋은 PR과 다음 사람이 변경 이유를 추적하고 릴리스를 복구할 수 있는 이력을 남깁니다.

    • 배포와 진화
    • 커리어와 학습
    • 협업
    읽기 ↗
  59. 2023년 11월 21일

    서킷브레이커는 실패하는 I/O 가까이에 두세요

    서킷브레이커, 타임아웃, 캐시 폴백 같은 외부 호출 정책은 I/O 구현체 가까이에 두고, 도메인 코드는 그 결과가 비즈니스에서 무엇을 뜻하는지 결정합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • 신뢰성과 운영
    읽기 ↗
  60. 2023년 11월 16일

    타임아웃은 클라이언트 설정이 아니라 제품의 결정입니다

    모든 실패에 같은 재시도 규칙을 붙이지 말고, 사용자가 기다릴 수 있는 시간과 실패 뒤에 알 수 있는 사실을 기준으로 타임아웃과 복구 정책을 설계합니다.

    • 백엔드 엔지니어링
    • 신뢰성과 운영
    읽기 ↗
  61. 2023년 11월 12일

    도메인이 성숙하기 전에 모듈부터 나누지 마세요

    도메인 성숙도는 정책과 행동, 운영 현실을 얼마나 이해했는지에서 나옵니다. 추측을 일찍 굳히지 말고 운영에서 드러난 책임으로 모듈 경계를 정해야 합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • 도메인 모델링
    읽기 ↗
  62. 2023년 11월 7일

    소프트웨어는 경계를 한 단계씩 키워야 한다

    동작하는 코드에서 시작해 실제 응집과 규모가 더 강한 경계를 요구할 때 함수, 클래스, 패키지, 모듈과 프로젝트를 단계적으로 추출합니다.

    • 아키텍처
    읽기 ↗
  63. 2023년 11월 2일

    레이어는 논리적으로, 패키지는 응집도 있게

    모듈, 패키지와 아키텍처 레이어는 서로 다른 문제를 풉니다. 관련 동작은 가까이 두고 레이어는 기능을 흩뜨리지 않은 채 역할을 설명해야 합니다.

    • 아키텍처
    읽기 ↗
  64. 2023년 10월 29일

    의존성 격차가 프로젝트가 되기 전에 버전 올리기

    우선순위에 따라 의존성을 자주 올리면 변경을 작게 유지하고 호환성 문제를 일찍 발견하며 운영 서비스에 부채가 조용히 쌓이는 일을 막을 수 있습니다.

    • 백엔드 엔지니어링
    • 배포와 진화
    읽기 ↗
  65. 2023년 10월 24일

    만든 개발자가 떠나도 살아남는 소프트웨어

    좋은 회사 소프트웨어는 부채를 줄이고 팀의 운영 능력에 맞으며, 처음 만든 개발자가 떠난 뒤에도 이해하고 고칠 수 있어야 합니다.

    • 아키텍처
    • 테스트와 품질
    • 협업
    읽기 ↗
  66. 2023년 10월 20일

    단위 테스트는 비즈니스 의도를 지켜야 한다

    비즈니스 레이어 단위 테스트는 설계를 돕고, 중요한 동작을 기록하며, 다음 개발자가 위험한 변경 앞에서 한 번 더 생각하게 할 때 의미가 있습니다.

    • 아키텍처
    • 테스트와 품질
    읽기 ↗
  67. 2023년 10월 15일

    AI 에이전트가 같은 도구를 두 번 호출한다면

    분산 시스템과 AI 워크플로에서 재시도는 정상입니다. DB 제약, 멱등 키, 제한된 재시도로 도구 호출의 중복 부작용을 막는 방법을 정리합니다.

    • 백엔드 엔지니어링
    • 신뢰성과 운영
    읽기 ↗
  68. 2023년 10월 11일

    너무 이른 멀티모듈은 설계를 더 어렵게 만든다

    모듈은 이해하지 못한 도메인이나 아키텍처 그림을 미리 고정하는 장치가 아니라 구현에서 발견한 경계를 강제하는 수단이어야 합니다.

    • 아키텍처
    읽기 ↗
  69. 2023년 10월 6일

    그래들 의존성 범위로 아키텍처 경계 세우기

    Gradle의 implementation, api, runtimeOnly, compileOnly를 의도적으로 사용해 모듈 접근을 제한하고 우발적인 결합을 막는 방법을 설명합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    읽기 ↗
  70. 2023년 10월 2일

    토이 프로젝트를 서비스라고 부르기 전에 운영해보기

    토이 프로젝트에서 서비스 경험을 얻으려면 하나의 목표를 정하고, 출시하고, 실제 사용자를 만나며, 리텐션과 종료 시점을 봐야 합니다.

    • 신뢰성과 운영
    • 커리어와 학습
    읽기 ↗
  71. 2023년 9월 27일

    어드민을 서비스 도메인에서 격리하기

    어드민 API는 조회, 수정, 릴리스 위험이 다릅니다. 운영 편의가 핵심 서비스를 바꾸지 않도록 모듈이나 저장소로 격리합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    읽기 ↗
  72. 2023년 9월 22일

    리더와 라이터 컴포넌트로 비즈니스 흐름 드러내기

    리더와 라이터는 저장소 세부사항과 변경 범위를 감추고 비즈니스 계층에 정책을 남깁니다. 다만 서비스 수명이 그 비용을 정당화해야 합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • 테스트와 품질
    읽기 ↗
  73. 2023년 9월 18일

    분산 서비스 끝까지 하나의 트레이스 아이디 전달하기

    민감한 정보를 노출하거나 저장소를 로그로 넘치게 하지 않으면서 HTTP 호출과 비동기 이벤트를 하나의 요청 맥락으로 추적합니다.

    • 백엔드 엔지니어링
    • 신뢰성과 운영
    읽기 ↗
  74. 2023년 9월 13일

    사용자 관점에서 문제를 정의하는 법

    기술 부하와 제품 가치를 구분하고, 만든 것을 실제로 출시하며, 사용자가 왜 선택할지 계속 물어야 문제 해결 능력이 자랍니다.

    • 커리어와 학습
    읽기 ↗
  75. 2023년 9월 9일

    유즈케이스 아래 계층에서 코드를 재사용하기

    유즈케이스끼리 재사용하면 비즈니스 변경이 번지고 순환 참조가 생깁니다. 위에서 조합하거나 아래의 구현 컴포넌트를 추출합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    읽기 ↗
  76. 2023년 9월 4일

    개발 용어보다 자기 생각과 운영 경험을 선택하기

    이론과 패턴은 유용한 참고 자료지만, 개발자는 코드와 트레이드오프, 운영 결과를 자기 언어로 설명할 수 있어야 합니다.

    • 아키텍처
    • 커리어와 학습
    • 협업
    읽기 ↗
  77. 2023년 8월 31일

    거대한 서비스 클래스를 책임과 계층으로 분리하는 법

    생성자 의존성과 import로 비대해진 서비스를 진단하고, 새로운 아키텍처 이름을 붙이기 전에 응집된 책임부터 분리합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • 테스트와 품질
    읽기 ↗
  78. 2023년 8월 26일

    요구사항과 객체 관계로 정규화와 반정규화를 선택하기

    정규화 수준을 점수처럼 높이기보다 값의 변경 의미, 조회 비용, 데이터가 보존해야 할 객체 관계를 기준으로 테이블을 설계합니다.

    • 아키텍처
    • 백엔드 엔지니어링
    • 데이터와 영속성
    읽기 ↗

© 2026 Gemini Kim

RSSGitHubLinkedInXYouTube