<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on philipjkim</title><link>https://philipjkim.cc/tags/architecture/</link><description>Recent content in Architecture on philipjkim</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Thu, 16 Jul 2026 17:33:09 +0900</lastBuildDate><atom:link href="https://philipjkim.cc/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>HTTP REST(JSON) vs. gRPC(Protocol Buffers): 언제 무엇을 쓸까</title><link>https://philipjkim.cc/posts/20260716-http-rest-vs-grpc/</link><pubDate>Thu, 16 Jul 2026 17:33:09 +0900</pubDate><guid>https://philipjkim.cc/posts/20260716-http-rest-vs-grpc/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;백엔드 서버를 설계할 때 거의 항상 마주치는 갈림길이 있습니다. &amp;ldquo;이 API 를 JSON 기반 HTTP REST 로 열까, 아니면 gRPC 로 열까?&amp;rdquo; 하는 질문입니다. 팀 컨벤션에 따라 별생각 없이 한쪽으로 정해지는 경우도 많지만, 두 방식은 성능·개발 경험·운영 부담·클라이언트 호환성 등 여러 축에서 뚜렷하게 다른 트레이드오프를 가집니다.&lt;/p&gt;
&lt;p&gt;이 글은 웹 백엔드를 다루는 중급 이상 개발자를 대상으로, 두 방식의 작동 원리와 장단점을 정리하고 &lt;strong&gt;&amp;ldquo;어떤 상황에서 무엇을 고르는 것이 합리적인지&amp;rdquo;&lt;/strong&gt; 를 구체적인 예시와 함께 설명합니다. 결론부터 말하면 &amp;ldquo;무조건 하나가 낫다&amp;quot;는 답은 없으며, &lt;strong&gt;통신의 상대가 누구인지(외부 클라이언트 vs. 내부 서비스)&lt;/strong&gt; 가 선택의 가장 강력한 기준이 됩니다.&lt;/p&gt;</description></item><item><title>웹서비스 내부 구조 아키텍처 가이드 Part 2: EDA, VSA, Modular Monolith</title><link>https://philipjkim.cc/posts/20260312-web-service-architecture-guide-02/</link><pubDate>Thu, 12 Mar 2026 10:07:30 +0900</pubDate><guid>https://philipjkim.cc/posts/20260312-web-service-architecture-guide-02/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;a href="https://philipjkim.cc/posts/20260312-web-service-architecture-guide-01/"&gt;Part 1&lt;/a&gt;에서는 Layered Architecture, Ports &amp;amp; Adapters 계열(Hexagonal/Onion/Clean), CQRS를 다뤘습니다. Part 2에서는 나머지 세 아키텍처와 전체 비교를 다룹니다.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="4-event-driven-architecture-eda"&gt;4. Event-Driven Architecture (EDA)&lt;/h2&gt;
&lt;h3 id="개요"&gt;개요&lt;/h3&gt;
&lt;p&gt;Event-Driven Architecture는 &lt;strong&gt;시스템 구성 요소 간의 통신을 이벤트를 통해 수행&lt;/strong&gt; 하는 설계 패턴입니다. 컴포넌트가 서로 직접 호출하는 대신, &amp;ldquo;무언가가 발생했다&amp;quot;는 사실을 이벤트로 발행하면, 관심 있는 컴포넌트가 이를 구독하여 반응합니다.&lt;/p&gt;
&lt;p&gt;이 글의 전제가 Kafka/RabbitMQ 같은 메시지 브로커를 포함하는 환경이므로, EDA를 내부 구조 패턴으로 다루는 것은 매우 자연스럽습니다. 메시지 브로커가 있다는 것 자체가 이미 이벤트 기반 통신의 인프라를 갖추고 있다는 뜻이기 때문입니다.&lt;/p&gt;</description></item><item><title>웹서비스 내부 구조 아키텍처 가이드 Part 1: Layered, Ports &amp; Adapters, CQRS</title><link>https://philipjkim.cc/posts/20260312-web-service-architecture-guide-01/</link><pubDate>Thu, 12 Mar 2026 10:07:29 +0900</pubDate><guid>https://philipjkim.cc/posts/20260312-web-service-architecture-guide-01/</guid><description>&lt;p&gt;&lt;em&gt;이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.&lt;/em&gt;&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;이 글은 웹서비스를 전제로 합니다. 구체적으로는 HTML/CSS/JS 프런트엔드, REST/gRPC 기반 백엔드, RDB/Redis/NoSQL 저장소, Kafka/RabbitMQ 같은 메시지 브로커가 있는 환경을 상정합니다.&lt;/p&gt;
&lt;p&gt;비교 대상은 &amp;ldquo;배포 아키텍처&amp;quot;가 아닙니다. 마이크로서비스냐 모놀리스냐의 문제가 아니라, &lt;strong&gt;애플리케이션 내부 코드를 어떻게 나누고, 의존성을 어느 방향으로 흐르게 하며, 변경을 어떤 단위로 흡수할 것인가&lt;/strong&gt; 에 관한 내부 구조 아키텍처입니다. Microsoft도 논리적 계층(layer)과 물리적 계층(tier)을 구분하며, 논리적 계층 분리가 반드시 별도 서버 분리를 의미하지는 않는다고 설명합니다.&lt;/p&gt;</description></item><item><title>아키텍처 비교: VSA vs. Hexagonal Architecture</title><link>https://philipjkim.cc/posts/20250922-vsa-vs-hexagonal/</link><pubDate>Mon, 22 Sep 2025 14:14:05 +0900</pubDate><guid>https://philipjkim.cc/posts/20250922-vsa-vs-hexagonal/</guid><description>&lt;p&gt;이 포스트는 Vertical Slicing Architecture와 Hexagonal Architecture의 개념과 특징을 단순히 나열하는 것을 넘어, 두 아키텍처의 근본적인 설계 철학, 해결하고자 하는 핵심 문제, 그리고 실제 프로젝트에 적용했을 때 발생하는 트레이드오프를 심층적으로 분석하는 것을 목표로 합니다. 각 아키텍처의 태동 배경, 장단점, 이상적인 적용 시나리오를 비교 분석하고, 실제 적용 사례를 통해 이론이 현실에서 어떻게 구현되는지 살펴볼 것입니다. 최종적으로는 독자들이 자신의 프로젝트 맥락과 당면 과제에 가장 적합한 아키텍처를 정보에 입각하여 선택할 수 있도록 실질적인 통찰과 가이드를 제공하고자 합니다.&lt;/p&gt;</description></item></channel></rss>