구독 중인 기술 블로그 RSS 피드 목록 이 블로그는 다양한 기술 소식을 RSS 피드로 구독하여 콘텐츠를 생성하고 있습니다. 토스 기술 블로그: https://toss.tech/rss.xml 카카오 기술 블로그: https://tech.kakao.com/feed/ 당근(Daangn) 미디엄 블로그: https://medium.com/f...

서론: URL 모양보다 행동의 의미 REST API 설계 논의는 복수형 명사나 하이픈 규칙에 머물기 쉽다. 더 중요한 것은 클라이언트가 메서드·상태 코드·헤더만 보고 요청의 안전성, 재시도 가능성, 캐시 조건을 예측할 수 있는가다. HTTP의 의미를 지키면 프록시·브라우저·SDK와 자연스럽게 협력할 수 있다. 1. 리소스는 업무 개념이다 좋은 후...

서론: 전체 재작성은 아키텍처 전략이 아니다 기존 Service와 JPA Entity가 얽힌 시스템을 한 번에 헥사고날 구조로 바꾸면 오랜 기간 기능 개발이 멈추고 회귀 위험이 커진다. 가장 많이 변하고 테스트가 어려운 업무 흐름 하나를 골라 경계를 만들고, 새 기능부터 그 경계를 따르게 하는 방식이 현실적이다. 1. 전환 대상 선택 좋은 첫 후...

서론: 테스트 속도는 구조의 결과다 업무 규칙 하나를 검증하는데 Spring Context와 실제 DB가 항상 필요하다면 의존성 경계가 안쪽까지 들어온 신호다. 헥사고날 구조는 테스트를 위해 만든 것은 아니지만, Port를 기준으로 외부를 바꿔 끼울 수 있어 빠른 테스트와 현실적인 통합 테스트를 분리하기 쉽다. 1. Domain 테스트 @Test...

서론: 변환 코드는 낭비가 아니라 방화벽이다 DTO를 Domain으로, Domain을 JPA Entity로 바꾸는 매핑은 반복처럼 보인다. 그래서 하나의 객체를 모든 계층에서 쓰고 싶어진다. 하지만 외부 계약과 DB 스키마가 바뀔 때 그 변환 경계가 안쪽 모델을 보호한다. 1. Web Adapter @RestController class Orde...

서론: Service가 모든 일을 하지 않게 하기 헥사고날 구조를 적용해도 Use Case 구현 안에 검증·계산·상태 변경이 모두 조건문으로 쌓이면 이름만 바뀐 거대한 Service가 된다. Use Case는 작업 순서를 조율하고, Domain은 자신의 상태와 규칙을 지키게 한다. 1. Use Case의 책임 입력 Command 해석 필요...

서론: Controller-Service-Repository만으로 부족할 때 계층형 구조는 시작하기 쉽지만 규모가 커지면 Service가 JPA Entity, HTTP Client, 메시지 발행을 모두 알게 되기 쉽다. 비즈니스 규칙을 테스트하려 해도 Spring Context와 DB가 필요해진다. 헥사고날 아키텍처의 핵심은 폴더 모양이 아니라 의존...

서론: CPU가 높다는 것은 원인이 아니다 성능 사고에서 “GC 같다”, “DB 같다”는 가설일 뿐이다. 먼저 증상을 시간축에 고정하고, 비용이 낮은 지표에서 시작해 thread dump·JFR·heap dump처럼 더 깊은 증거로 내려간다. 도구는 많이 쓰는 것보다 질문에 맞는 것을 고르는 것이 중요하다. 1. 증상을 정확히 적기 언제: 14:...

서론: 가상 스레드는 요청을 빠르게 만들지 않는다 가상 스레드는 많은 동시 I/O 작업을 thread-per-request 스타일로 표현할 수 있게 한다. 블로킹 I/O 중 가상 스레드는 carrier 플랫폼 스레드에서 내려오고, carrier는 다른 작업을 실행한다. 장점은 개별 요청의 latency 감소보다 같은 하드웨어에서 기다리는 요청을 더 ...

서론: 동시성은 속도가 아니라 대기열 관리다 스레드를 늘리면 동시에 더 많은 요청을 시작할 수 있지만 CPU·DB 연결·외부 API 용량이 늘어나는 것은 아니다. 처리 능력보다 입력이 많으면 어디엔가 대기열이 생긴다. 좋은 동시성 설계는 그 대기열의 위치·크기·거부 정책을 명시한다. 1. 스레드 풀의 네 요소 worker 수: 동시에 실...