밈밍민믹

웹 서버 - Nginx와 Apache로 이해하는 요청 처리 구조

밈밍민믹 — Mon, 1 Jun 2026 12:18:23 +0900

안녕하세요. 눈 깜빡할 사이에 벌써 6월이네요.

이번 내용을 작성하고나면 확장성 있는 구축에 대해 작성해야하지만 면접이 잡혀서 목요일에 다시 재개하도록 하겠습니다. 작성했던 블로그글이랑 이것저것 다 확인하기 위해서는 조금 시간이 걸릴 것 같더라고요.

자 그럼 웹 서버 공부를 시작하겠습니다.

웹 서버

웹 서버는 클라이언트가 요청한 정적인 컨텐츠를 HTTP를 통해 제공해주는 서버입니다.

가장 기본적인 역할은 HTML, CSS, JavaScript, 이미지 파일 같은 정적 리소스를 클라이언트에게 제공하는 것입니다.

예를 들어 사용자가 웹 사이트에 접속했을 때 브라우저가 'index.html', 'style.css', 'main.js' 파일을 요청하면 웹 서버는 해당 파일을 찾아 응답합니다.

또한 웹 서버는 단순히 파일만 제공하는 것이 아니라, 요청을 애플리케이션 서버로 전달하는 리버스 프록시 역할도 할 수 있습니다.

웹서버와 WAS의 차이

웹 서버와 WAS는 모두 서버 요청 처리에 사용되지만 역할이 다릅니다.

웹 서버는 주로 정적 파일을 제공하거나 클라이언트 요청을 다른 서버로 전달하는 역할을 합니다. 반면 WAS는 비즈니스 로직을 실행하고, 데이터베이스와 연동해 동적인 응답을 생성하는 역할을 합니다.

구분	웹 서버	WAS
주요 역할	정적 파일 제공, 리버스 프록시	비즈니스 로직 처리
처리 대상	HTML, CSS, JS, 이미지	API 요청, DB 조회, 인증 처리
대표 예시	Nginx, Apache	Tomcat, Spring Boot 내장 Tomcat
응답 방식	파일 또는 요청 전달	동적 데이터 생성
사용 목적	빠른 정적 응답, 요청 분산, 보안 설정	서비스 로직 실행

웹 서버가 하는 일

웹 서버는 다음과 같은 역할을 수행할 수 있습니다.

정적 파일 제공
- HTML, CSS, JS, 이미지 파일 응답
리버스 프록시
- 클라이언트 요청을 내부 애플리케이션 서버로 전달
로드 밸런싱
- 여러 서버로 요청을 분산
SSL/TLS 처리
- HTTPS 인증서 적용 및 암호화 통신 처리

정적 파일 제공

정적 파일은 서버에서 별도의 비즈니스 로직을 실행하지 않고 그대로 응답할 수 있는 파일입니다.

예를 들어 HTML, CSS, JavaScript, 이미지 파일이 이에 해당합니다. 웹 서버는 이러한 정적 파일을 빠르게 제공하는데 적합합니다.

프론트엔드 프로젝트를 빌드하면 정적 파일이 생성됩니다. 이 파일들을 웹 서버의 특정 디렉터리에 배치하면 웹 서버는 클라이언트 요청에 따라 해당 파일을 응답할 수 있습니다.

리버스 프록시

리버스 프록시는 클라이언트 요청을 대신 받아 내부 서버로 전달하는 구조입니다.

클라이언트는 내부 애플리케이션 서버의 주소를 직접 알 필요 없이 웹 서버 주소로 요청을 보냅니다. 웹 서버는 요청 경로나 도메인에 따라 적절한 내부 서버로 요청을 전달합니다.

https://example.com/api/posts

↓

Nginx

↓

http://localhost:8080/api/posts

예를 들어 외부 사용자는 'https://example.com/api/posts'로 요청하지만, 실제 Spring Boot 애플리케이션은 서버 내부의 'localhost:8080'에서 실행될 수 있습니다. 이때 Nginx가 외부 요청을 받아 내부 애플리케이션 서버로 전달합니다.

로드 밸런싱

로드 밸런싱은 여러 서버에 요청을 분산하는 기능입니다.

트래픽이 많아지면 하나의 애플리케이션 서버가 모든 요청을 처리하기 어려울 수 있습니다. 이때 웹 서버나 로드 밸런서를 사용해 여러 서버로 요청을 나누어 보낼 수 있습니다.

이렇게 하면 특정 서버 하나에 요청이 몰리는 것을 줄이고, 서버 장애가 발생했을 때 다른 서버로 요청을 처리하도록 구성할 수도 있습니다.

Nginx란?

Nginx는 대표적인 웹 서버 중 하나로 정적 파일 제공, 리버스 프록시, 로드 밸런싱, SSL/TLS 처리 등에 사용됩니다.

Nginx는 이벤트 기반 구조를 사용해 많은 동시 연결을 효율적으로 처리하는데 강점이 있습니다. 이러한 특징 때문에 정적 파일 제공이나 리버스 프록시 서버로 많이 사용됩니다.

Apache란?

Apache HTTP Server는 오래전부터 널리 사용되어 온 대표적인 웹 서버입니다.

Apache는 모듈 기반 구조를 가지고 있어 다양한 기능을 확장하기 쉽고, 설정 방식이 유연하다는 장점이 있습니다. 'htaccess' 파일을 통해 디렉터리 단위 설정을 적용할 수 있는 점도 Apache의 특징입니다.

다만 동시 연결이 많은 환경에서는 설정 방식과 동작 모델에 따라 Nginx보다 상대적으로 많은 자원을 사용할 수 있습니다.

Nginx와 Apache의 차이

Nginx는 많은 동시 연결을 효율적으로 처리하고 리버스 프록시로 사용하기 좋아 현대적인 배포 환경에서 자주 사용됩니다. Apache는 모듈 기반 확장성과 유연한 설정이 강점이며, 오랫동안 다양한 웹 환경에서 사용되어 왔습니다.

구분	Nginx	Apache
구조	이벤트 기반	프로세스/스레드 기반 중심
강점	많은 동시 연결 처리, 리버스 프록시, 정적 파일 제공	모듈 확장성, 유연한 설정
정적 파일 처리	빠르고 효율적	가능하지만 Nginx가 자주 선택됨
동적 요청 처리	주로 백엔드 서버로 프록시	모듈을 통해 직접 처리 가능
설정 방식	중앙 설정 중심	.htaccess 등 디렉터리별 설정 가능
사용 사례	리버스 프록시, 로드 밸런서, 정적 파일 서버	전통적인 웹 서버, PHP 환경 등

오늘은 웹서버 Nginx와 Apache에 대해 간단하게 알아봤습니다. 수고하셨습니다.

실시간 통신 방식 WebSocket

밈밍민믹 — Sun, 31 May 2026 14:18:17 +0900

안녕하세요. 벌써 일요일이네요. 일주일이 정말 눈 깜빡하는 사이에 지나가는 것 같습니다.

이번에는 웹소켓에 대한 학습을 진행할 예정입니다. 실제로 웹소켓을 통한 채팅 기능을 구현해본적이 있어서 이론적으로 한번 더 학습하는게 되겠네요. 그럼 시작하도록 하겠습니다.

WebSocket

WebSocket은 클라이언트와 서버가 하나의 연결을 유지하면서 양방향으로 데이터를 주고받을 수 있도록 하는 통신 프로토콜입니다.

HTTP는 기본적으로 클라이언트가 요청을 보내야 서버가 응답할 수 있는 구조입니다. 반면 WebSocket은 최초 연결 이후 클라이언트와 서버 사이에 연결을 유지하기 때문에 서보도 필요한 시점에 클라이언트에게 데이터를 보낼 수 있습니다.

즉, WebSocket은 실시간성이 중요한 기능에서 사용하기 좋은 통신 방식입니다.

HTTP 통신 방식의 한계

HTTP는 요청-응답 방식으로 동작합니다. 클라이언트가 서버에 요청을 보내면 서버가 응답하고, 하나의 요청 흐름은 종료됩니다. 이 구조는 명확하지만, 서버에서 발생한 변경 사항을 클라이언트에게 즉시 전달하기 어렵다는 한계가 있습니다.

만약 HTTP만으로 실시간 채팅을 구현하려면 클라이언트가 일정 시간마다 서버에 새 메시지가 있는지 계속 물어봐야 합니다. 이를 Polling이라고 합니다.

Polling 방식은 구현이 단순하지만 새 데이터가 없어도 계속 요청을 보내야 하므로 불필요한 트래픽이 발생할 수 있습니다. 또한 요청 주기에 따라 실시간성이 떨어질 수 있습니다.

WebSocket의 동작 흐름

WebSocket은 처음부터 WebSocket 연결로 시작하는 것이 아니라, HTTP 요청을 통해 연결을 시작합니다.

클라이언트가 서버에 WebSocket 연결을 요청하면, 서버는 이를 승인하고 기존 HTTP 연결을 WebSocket 연결로 업그레이드합니다. 이후에는 하나의 연결을 유지하면서 양방향 통신을 수행합니다.

이때 'Upgrade' 헤더와 'Connection' 헤더가 사용됩니다. 서버가 WebSocket 연결을 허용하면 HTTP 요청-응답 방식이 아니라 WebSocket 프로토콜 기반의 지속 연결로 전환됩니다.

이후 클라이언트와 서버는 연결을 끊지 않고 필요한 시점마다 메시지를 주고받을 수 있습니다.

WebSocket과 HTTP의 차이

HTTP는 클라이언트가 필요한 데이터를 요청하는 구조에 적합하고, WebSocket은 연결을 유지하면서 실시간으로 데이터를 주고받아야하는 기능에 적합합니다.

구분	HTTP	WebSocket
통신 방식	요청-응답	양방향 통신
연결 방식	요청마다 연결 또는 응답 후 종료	연결을 유지
서버 → 클라이언트 전송	클라이언트 요청이 있어야 가능	서버가 직접 전송 가능
적합한 기능	게시글 조회, 로그인, 주문 요청	채팅, 실시간 알림, 실시간 상태 변경
실시간성	낮거나 별도 방식 필요	높음

WebSocket을 사용하는 상황

WebSocket은 서버와 클라이언트 사이에서 실시간으로 데이터가 오가야 하는 상황에서 사용할 수 있습니다.

사용 상황	설명
실시간 채팅	사용자가 보낸 메시지를 즉시 상대방에게 전달
실시간 알림	댓글, 좋아요, 주문 상태 변경 등을 즉시 알림
주식/코인 가격	가격 변동 정보를 실시간으로 전달
멀티 게임	플레이어 위치, 상태, 이벤트를 실시간 동기화

WebSocket 사용 시 주의할 점

WebSocket은 실시간 통신에 유용하지만, 운영 환경에서는 몇 가지 주의할 점이 있습니다.

연결 관리
- 사용자가 많아질수록 유지해야 하는 연결 수가 증가
인증 처리
- 연결 시점에 사용자를 식별하고 권한을 확인해야 함
재연결 처리
- 네트워크 불안정으로 연결이 끊어졌을 때 재연결 로직 필요
서버 자원
- 지속 연결이므로 메모리와 커넥션 관리 필요
프록시 설정
- Nginx 같은 웹 서버를 사용할 경우 Upgrade 헤더 설정 필요

오늘은 WebSocket에 대해 간략하게 알아보았습니다. 다음 시간에는 웹서버 : Nginx에 대해서 알아보도록 하겠습니다. 수고하셨습니다.

그래프 데이터베이스 - Neo4j

밈밍민믹 — Sat, 30 May 2026 02:24:12 +0900

안녕하세요. 오늘은 평상시와 달리 새벽에 글을 작성하네요. 22시에 잠깐 쉰다고 누웠다가 30분정도 잤나..? 더 자려고 했지만 잠이 안와서 그냥 블로그를 쓰기로 마음 먹었습니다. 저번 시간에는 GraphQL에 대해서 학습해봤습니다. GraphQL을 쓸 일이 없어서 크게 관심이 없었지만 이번 기회에 기본 구조 정도는 알게 된 것 같습니다. 이번에는 그래프 데이터베이스에 대해서 학습해보겠습니다.

그래프 데이터베이스

그래프 데이터베이스는 데이터를 Node(하나의 개체)와 Relationship(Node 사이의 관계)으로 표현하는 데이터베이스입니다.

관계형 데이터베이스가 테이블을 중심으로 데이터를 저장한다면, 그랲프 데이터 베이스는 개체와 개체 사이의 연결을 중심으로 데이터를 저장합니다.

즉, 그래프 데이터베이스는 "데이터가 무엇인가"뿐만 아니라 "데이터가 서로 어떻게 연결되어 있는가"를 중요하게 다룹니다.

위 예시에서 '지연', '민수', '제목'은 Node이고, 'FRIEND', 'LIKES'는 Relationship입니다.

'지연'은 '민수'와 친구 관계를 맺고 있고, '제목' 게시글을 좋아요한 상태입니다. 이처럼 그래프 데이터베이스는 사용자와 사용자, 사용자와 게시글처럼 여러 데이터 사이의 관계를 직관적으로 표현할 수 있습니다.

RDBMS와 그래프 데이터베이스의 차이

RDBMS에서는 데이터를 행과 열의 테이블로 저장하고, 테이블 간 관계는 외래 키로 표현합니다. 예를 들어 사용자와 친구 관계를 저장하려면 'users' 테이블과 'friendships' 같은 중간 테이블을 만들 수 있습니다.

users
- id
- name

friendships
- user_id
- friend_id

해당 구조는 많이 이용되지만 친구의 친구, 공통 친구, 여러 단계의 연결 관계를 계속 탐색해야 한다면 JOIN이 반복적으로 필요해질 수 있습니다.

반면 그래프 데이터베이스는 관계 자체를 데이터의 핵심 구조로 저장합니다. 따라서 특정 Node에서 출발해 연결된 Relationship을 따라가며 데이터를 탐색하는 방식에 적합합니다.

구분	RDBMS	그래프 데이터베이스
데이터 표현	테이블, 행, 컬럼	Node, Relationship, Property
관계 표현	외래 키, JOIN	Relationship
강점	정형 데이터 관리, 트랜잭션, 집계	관계 탐색, 경로 탐색, 연결 구조 분석
적합한 예시	주문, 결제, 회원, 재고	SNS 관계, 추천, 경로 탐색, 지식 그래프
조회 방식	SQL	Cypher 등 그래프 질의 언어

RDBMS가 데이터를 정합성 있게 저장하고 관리하는데 강점이 있다면, 그래프 데이터베이스는 데이터 사이의 연결 관계를 빠르게 탐색하는데 강점이 있습니다.

그래프 데이터베이스의 기본 구성 요소

Node

Node는 그래프 데이터베이스에서 하나의 개체를 의미합니다.

예를 들어 사용자, 게시글, 상품, 장소, 태그 등이 Node가 될 수 있습니다.

Relationship

Relationship은 Node와 Node 사이의 관계를 의미합니다.

예를 들어 사용자가 게시글을 작성했다면 'WROTE', 사용자가 다른 사용자를 팔로우했다면 'FOLLOWS', 사용자가 상품을 구매했다면 'PURCHASED' 같은 관계로 표현할 수 있습니다.

Property

Property는 Node나 Relationship이 가지는 속성입니다.

예를 들어 User Node는 이름, 이메일 같은 속성을 가질 수 있고, FOLLOWS 관계는 팔로우한 날짜를 속성으로 가질 수 있습니다.

Label

Label은 Node의 종류를 구분하는 이름입니다.

예를 들어 'User', 'Post', 'Product', 'Tag' 같은 Label을 붙여 Node의 타입을 구분할 수 있습니다.

Neo4j

Neo4j는 대표적인 그래프 데이터베이스입니다. 데이터를 Node, Relationship, Property 형태로 저장하며, 관계를 따라가는 탐색 쿼리에 강점을 가집니다. SQL 대신 Cypher라는 그래프 질의 언어를 사용해 데이터를 조회하고 생성할 수 있습니다.

Neo4j는 SNS 친구 관계, 추천 시스템, 지식 그래프, 네트워크 분석, 부정 거래 탐지처럼 관계 탐색이 중요한 분야에서 사용할 수 있습니다.

Cypher

Cupher는 Neo4j에서 사용하는 그래프 질의 언어입니다. SQL이 테이블을 기준으로 데이터를 조회한다면, Cypher는 Node와 Relationship의 패턴을 기준으로 데이터를 조회합니다.

Cypher에서는 'MATCH'로 그래프 패턴을 찾고, 'WHERE'로 조건을 지정한 뒤, 'RETURN'으로 조회 결과를 반환할 수 있습니다.

MATCH <pattern> WHERE <conditions> RETURN <expression>

그래프 데이터베이스를 사용하는 상황

그래프 데이터베이스는 데이터 사이의 관계를 중심으로 탐생해야 하는 상황에서 유용합니다.

상황	설명
SNS 친구 관계	친구, 팔로우, 공통 친구, 추천 친구 탐색
추천 시스템	사용자-상품-카테고리-태그 관계 기반 추천
경로 탐색	지도, 네트워크, 물류 경로 탐색
부정 거래 탐지	계정, 카드, 기기, IP 간의 수상한 연결 탐색
지식 그래프	개념, 문서, 인물, 사건 간 관계 표현
권한 관리	사용자, 역할, 리소스 간 접근 관계 분석

그래프 데이터베이스의 장점과 주의할 점

장점

관계 표현이 직관적
- Node와 Relationship으로 연결 구조를 자연스럽게 표현
관계 탐색에 강함
- 여러 단계의 연결 관계를 따라가는 조회에 적합
스키마 변화에 유연함
- 관계나 속성을 추가하면서 모델을 확장하기 쉬움
추천/탐색 기능에 적합
- 친구 추천, 상품 추천, 경로 탐색 등에 활용 가능

주의할 점

정형 데이터 처리에는 RDBMS가 더 적합할 수 있음
- 주문, 결제, 재고처럼 명확한 테이블 구조와 트랜잭션이 중요한 경우
운영 복잡도
- 기존 RDBMS와 함께 사용할 경우 데이터 동기화나 운영 구조 고려 필요
사용 목적이 분명해야 함
- 단순 CRUD 중심 서비스라면 도입 효과가 크지 않을 수 있음

그래프 데이터베이스는 모든 데이터를 그래프로 바꿔야 하는 기술이 아닌 관계 탐색이 핵심인 문제를 해결하기 위한 선택지로 보는 것이 좋습니다.

오늘은 그래프 데이터베이스에 대해서 학습해봤습니다. 최근 학습한 것들은 생소한것도 있고 익숙한것도 있고, 신기한 것 같습니다. 학습하면서 느낀바는 BFS, DFS, 다익스트라 같은 그래프 탐색 알고리즘을 적용하기 좋은 기반이 될 수 있겠다는 생각이 들었습니다. 실제로 사용한다면 SNS 서비스에서 친구 추천이나 공통 관심사 기반 추천 기능을 구현해보면 재밌겠네요.

이상으로 그래프 데이터베이스와 Neo4j에 대한 학습은 마치며 다음 시간에는 웹소켓과 함께 돌아오도록 하겠습니다. 수고하셨습니다.

GraphQL - REST API와 차이

밈밍민믹 — Fri, 29 May 2026 11:34:02 +0900

안녕하세요. 벌써 금요일이네요. 시간이 빨리가는 것 같습니다.

깁스 풀고 보호대 착용했으니 본격적으로 다시 운동을 시작하고 싶은데 뭐부터 시작해야할지 감이 안잡히네요. 발목 가동 범위도 줄어서 쉽지 않은 것 같아요. 조금 더 고민하고 생각해봐야겠네요. 자, 그럼 학습 시작해보겠습니다.

GraphQL

GraphQL은 메타(페이스북)가 개발한 API를 위한 오픈소스 쿼리 언어입니다. 클라이언트가 필요한 데이터를 직접 지정해서 요청할 수 있는 API 질의 언어입니다.

REST API에서는 서버가 정해둔 endpoint에 요청을 보내고, 서버가 정해둔 응답 구조를 받습니다. 반면 GraphQL에서는 클라이언트가 필요한 field를 직접 선택해서 요청할 수 있습니다.

즉, GraphQL은 "서버가 정해둔 응답을 그대로 받는 방식"이 아니라, "클라이언트가 필요한 데이터 형태를 요청하는 방식"에 가깝습니다.

GraphQL

query {
  book(id: 1) {
    title
    author
  }
}

JSON

{
  "data": {
    "book": {
      "title": "GraphQL 입문",
      "author": "user1"
    }
  }
}

위의 예시에서 클라이언트는 'book' 데이터 중 'title'과 'author'만 요청했습니다. 서버는 요청 받은 field에 맞춰 필요한 데이터만 응답합니다.

REST API의 한계

REST API는 리소스 중심으로 API를 설계하기 때문에 구조가 직관적이고 HTTP Method와 잘 어울립니다. 예를 들어 게시글 목록 조회, 게시글 상세 조회, 댓글 작성 같은 기능을 각각 endpoint로 나누어 설계할 수 있습니다.

GET /posts

GET /posts/1

GET /posts/1/comment

GET /users/1

하지만 화면이 복잡해지면 클라이언트가 원하는 데이터를 한 번에 가져오기 어려운 경우가 생길 수 있습니다.

예를 들어 게시글 상세 화면에서 게시글 정보, 작성자 정보, 댓글 목록, 좋아요 수를 모두 보여줘야 한다면 여러 API를 호출해야 할 수 있습니다.

GET /posts/1

GET /users/1

GET /posts/1/comments

GET posts/1/likes

또는 반대로 하나의 API 응답에 클라이언트가 사용하지 않는 데이터까지 포함되어 불필요한 데이터 전송이 발생할 수 있습니다. 이러한 문제를 각각 Under-fetching과 Over-fetching이라고 합니다.

Over-fetching과 Under-fetching

Over-fetching

Over-fetching은 클라이언트가 필요한 데이터보다 더 많은 데이터를 응답받는 상황입니다.

예를 들어 클라이언트는 게시글 제목과 작성자 이름만 필요하지만, 서버 API가 게시글 내용, 작성일, 수정일, 조회수, 태그, 댓글 수까지 함께 응답한다면 필요하지 않은 데이터까지 전달받게 됩니다.

{
  "id": 1,
  "title": "GraphQL이란?",
  "content": "본문 내용...",
  "createdAt": "2026-05-29",
  "updatedAt": "2026-05-29",
  "viewCount": 120,
  "author": {
    "id": 3,
    "name": "user1",
    "email": "user1@test.com"
  }
}

이 중 클라이언트가 실제로 사용하는 값이 'title'과 'author.name'뿐이라면 나머지 데이터는 불필요하게 전달된 것입니다.

Under-fetching

Under-fetching은 하나의 API 호출만으로 필요한 데이터를 충분히 가져오지 못해 여러 API를 추가로 호출해야 하는 상황입니다.

예를 들어 게시글 상세 화면에서 게시글 정보뿐 아니라 작성자 정보와 댓글 목록도 필요하다면 REST API에서는 여러 endpoint를 호출해야 할 수 있습니다.

GET /posts/1

GET /users/3

GET /posts/1/comments

이 경우 클라이언트는 화면 하나를 구성하기 위해 여러 번 서버와 통신해야 하고, API 호출 흐름도 복잡해질 수 있습니다.

GraphQL의 기본 구조

GraphQL은 보통 하나의 endpoint를 사용합니다.

POST /graphql

REST API가 여러 endpoint를 리소스별로 나누는 것과 달리, GraphQL은 하나의 endpoint에 Query를 전달하고 서버는 Query에 맞는 데이터를 응답합니다.

query {
  post(id: 1) {
    title
    author {
      name
    }
    comments {
      content
      writer {
        name
      }
    }
  }
}

위 요청을 게시글 제목, 작성자 이름, 댓글 내용, 댓글 작성자 이름을 한 번에 요청합니다. 클라이언트가 필요한 데이터 구조를 직접 작성하기 때문에 여러 API를 호출하지 않고도 화면에 필요한 데이터를 가져올 수 있습니다.

Query, Mutation, Schema

Query

Query는 데이터를 조회할 때 사용합니다. REST API의 GET 요청과 비슷한 역할을 합니다.

query {
  user(id: 1) {
    id
    name
    email
  }
}

Mutation

Mutation은 데이터 생성, 수정, 삭제할 때 사용합니다. REST API의 POST, PUT, PATCH, DELETE와 비슷한 역할을 합니다.

mutation {
  createPost(input: {
    title: "GraphQL 정리"
    content: "GraphQL은 필요한 데이터를 직접 요청할 수 있습니다."
  }) {
    id
    title
  }
}

Schema

Schema는 GraphQL API에서 어떤 데이터를 요청할 수 있고, 어떤 타입을 반환하는지 정의하는 구조입니다. GraphQL 서버는 Schema를 기준으로 클라이언트의 요청이 유효한지 확인하고, 요청된 데이터의 형태에 맞게 응답합니다.

type Post {
  id: ID!
  title: String!
  content: String!
  author: User!
}

type User {
  id: ID!
  name: String!
}

type Query {
  post(id: ID!): Post
}

위 Schena는 'post'라는 Query를 통해 특정 게시글을 조회할 수 있고, 게시글 'id', 'title', 'content', 'author' 정보를 가진다는 것을 정의합니다.

GraphQL의 장점과 단점

장점

필요한 데이터만 요청 가능
- 클라이언트가 필요한 field만 선택해 요청할 수 있음
여러 데이터를 한 번에 조회 가능
- 하나의 Query로 연관된 데이터를 함께 요청할 수 있음
API 응답 구조 예측 가능
- 요청한 구조와 비슷한 형태로 응답이 내려옴
클라이언트 변화에 유연함
- 화면마다 필요한 데이터가 달라도 Query를 조정해 대응 가능
타입 기반 Schema
- 요청 가능한 데이터 구조를 명확히 정의할 수 있음

단점

서버 구현 복잡도 증가
- Schema, Resolver, 타입 정의 등을 설계해야 함
복잡한 Query 문제
- 클라이언트가 너무 깊거나 무거운 Query를 요청할 수 있음
캐싱이 REST보다 까다로움
- REST처럼 URL 단위 캐싱을 적용하기 어려울 수 있음
N+1 문제 가능성
- 연관 데이터를 Resolver에서 반복 조회하면 성능 문제가 생길 수 있음

REST API와 GraphQL 비교

REST API는 리소스 중심으로 단순하고 명확하게 API를 설계하기 좋습니다. 반면 GraphQL은 클라이언트가 필요한 데이터 구조를 직접 요청할 수 있어 화면별 데이터 요구사항이 다양한 서비스에서 유리할 수 있습니다.

구분	REST API	GraphQL
요청 방식	여러 endpoint 사용	보통 하나의 endpoint 사용
데이터 응답	서버가 정한 구조로 응답	클라이언트가 요청한 구조로 응답
데이터 조회	필요한 데이터에 따라 여러 API 호출 가능	하나의 Query로 연관 데이터 조회 가능
Over-fetching	발생할 수 있음	줄일 수 있음
Under-fetching	발생할 수 있음	줄일 수 있음
캐싱	HTTP 캐싱과 잘 어울림	별도 캐싱 전략 필요
설계 기준	리소스 중심	Schema와 타입 중심

Apollo란?

Apollo는 GraphQL을 더 쉽게 사용할 수 있도록 도와주는 도구입니다.

클라이언트에서는 Apollo Client를 사용해 GraphQL Query를 보내고, 응답 데이터를 캐싱하거나 상태 관리와 함께 사용할 수 있습니다. 서버에서는 Apollo Server를 사용해 GraphQL Schema와 Resolver를 구성할 수 있습니다.

즉, Apollo는 GraphQL 자체가 아니라 GraphQL을 실제 애플리케이션에서 더 편하게 사용할 수 있도록 도와주는 라이브러리 도구 모음에 가깝습니다.

오늘은 GraphQL과 REST API와의 차이에 대해 정리했습니다. 간략하게 알아간 정도라서 추가적인 학습이 필요한 경우 다른 블로그를 더 참조하는게 좋을 것 같습니다. GraphQL을 사용하게 될지는 모르겠지만, 만약 사용하게 된다면 포스팅하도록 하겠습니다. 수고하셨습니다.

컨테이너화 VS 가상화 - Docker란 무엇인가

밈밍민믹 — Thu, 28 May 2026 16:01:17 +0900

안녕하세요. 오늘은 병원가서 깁스 풀고 재활 치료 받느라서 블로그 작성이 늦어졌네요. 정말이지 병원에 갔다오면 오전이 순식간에 지나가는 것 같네요. 그럼 컨테이너화와 가상화에 대한 학습 시작해보도록 하겠습니다.

가상화

가상화는 하나의 물리 서버 위에서 여러 개의 독립된 가상 환경을 실행하는 기술입니다.

일반적으로 하이퍼바이저라는 소프트웨어가 물리 서버의 CPU, 메모리, 디스크 같은 자원을 나누어 여러 가상 머신을 실행합니다. 각 가상 머신은 자신만의 운영체제를 가지고 있으며, 실제 서버처럼 독립적으로 동작합니다.

예를 들어 하나의 물리 서버 위에 Linux 가상 머신, Windows 가상 머신을 각각 실행할 수 있습니다. 각 VM은 독립된 운영체제를 가지기 때문에 격리 수준이 높다는 장점이 있습니다. 하지만 VM마다 운영체제를 포함해야 하므로 상대적으로 무겁고, 실행 속도나 자원 사용량 측면에서 부담이 커질 수 있습니다.

컨테이너화

컨테이너화는 애플리케이션과 실행에 필요한 의존성, 설정 파일 등을 하나의 실행 단위로 묶어 격리된 환경에서 실행하는 방식입니다. 가상 머신처럼 운영체제 전체를 각각 포함하는 것이 아니라, 호스트 운영체제의 커널을 공유하면서 애플리케이션 실행에 필요한 부분만 독립적으로 구성합니다.

컨테이너는 VM보다 가볍고 빠르게 실행될 수 있습니다. 운영체제 전체를 새로 띄우는 것이 아니라, 애플리케이션 실행에 필요한 환경만 묶어 실행하기 때문입니다. 따라서 같은 서버에서 더 많은 애플리케이션을 효율적으로 실행할 수 있고, 개발 환경과 배포 환경의 차이도 줄일 수 있습니다.

가상화와 컨테이너화의 차이

가상화는 운영체제까지 포함한 독립된 서버 환경을 만드는 방식에 가깝고, 컨테이너화는 애플리케이션 실행 환경을 가볍게 격리하는 방식에 가깝습니다. 따라서 완전히 독립된 운영체제 환경이 필요하다면 가상화가 적합할 수 있고, 애플리케이션을 빠르고 일관되게 배포하고 싶다면 컨테이너화가 유리할 수 있습니다.

구분	가상화	컨테이너화
실행 단위	가상 머신	컨테이너
운영체제	VM마다 Guest OS 포함	Host OS 커널 공유
무게	상대적으로 무거움	상대적으로 가벼움
실행 속도	비교적 느림	비교적 빠름
격리 수준	높음	프로세스 단위 격리
자원 사용량	많음	적음
대표 기술	VMware, VirtualBox, Hyper-V	Docker, containerd

Docker

Docker는 컨테이너 기반으로 애플리케이션을 실행하고 배포할 수 있도록 도와주는 플랫폼입니다.

Docker를 사용하면 애플리케이션 코드뿐 아니라 실행에 필요한 라이브러리, 설정, 런타임 환경을 이미지로 묶을 수 있습니다. 그리고 이 이미지를 기반으로 컨테이너를 싱행하면 어느 환경에서든 비교적 일관된 방식으로 애플리케이션을 실행할 수 있습니다.

Docker 기반 컨테이너 실행 구조

해당 그림은 Docker 기반으로 컨테이너화된 애플리케이션이 실행되는 구조를 보여줍니다.

출처 : https://www.docker.com/resources/what-container/

가장 아래에는 실제 서버나 클라우드 환경에 해당하는 Infrastructure가 있고, 그 위에 Host Operating System이 실행됩니다. Docker는 Host OS 위에서 동작하며, 여러 개의 컨테이너를 실행하고 관리합니다.

각 컨테이너 안에는 App A, App B 처럼 서로 다른 애플리케이션이 실행될 수 있습니다. 이때 컨테이너는 가상 머신처럼 운영체제 전체를 각각 포함하지 않고, Host OS의 커널을 공유하면서 애플리케이션 실행에 필요한 환경만 격리합니다.

따라서 컨테이너는 가상 머신보다 상대적으로 가볍고 빠르게 실행될 수 있으며, 하나의 서버 위에서 여러 애플리케이션을 효율적으로 운영할 수 있습니다.

Docker Engine의 구성

Docker Engine은 Docker에서 컨테이너를 생성하고 실행하며 관리하는 핵심 실행 환경입니다.

사용자는 Docker CLI를 통해 명령어를 입력하고, Docker API를 통해 Docker Engine과 통신할 수 있습니다. Docker Engine은 이미지를 빌드하고, 컨테이너를 실행하며, 네트워크와 볼륨 같은 실행 환경을 관리합니다.

출처 : https://www.docker.com/products/container-runtime/

구성 요소	설명
Docker CLI	사용자가 Docker 명령어를 입력하는 도구
Docker API	Docker CLI나 외부 도구가 Docker Engine과 통신하는 인터페이스
Docker Engine	컨테이너 생성, 실행, 이미지 관리 등을 담당하는 핵심 실행 환경
Containerd	컨테이너 실행을 관리하는 런타임 계층
Docker Build	Dockerfile을 기반으로 이미지를 빌드하는 기능
Networking	컨테이너 간 통신과 외부 연결을 관리
Volumes	컨테이너 데이터 저장 공간을 관리
Distribution	이미지를 저장소에 push/pull하는 기능

즉, Docker Engine은 단순히 컨테이너를 실행하는 것만 담당하는 것이 아니라, 이미지 빌드, 컨테이너 실행, 네트워크 연결, 데이터 저장 공간, 이미지 배포까지 컨테이너 운영에 필요한 여러 기능을 관리합니다.

Docker를 사용하는 이유

1. 실행 환경 일관성

Docker를 사용하면 애플리케이션 실행 환경을 이미지로 묶을 수 있습니다. 따라서 개발 환경, 테스트 환경, 배포 환경에서 동일한 이미지를 사용해 실행할 수 있습니다. 이럴 경우 "내 컴퓨터에서는 됏는데 서버에서는 안된다"와 같은 환경 차이 문제를 줄일 수 있습니다.

2. 배포 편의성

Docker 이미지를 만들어두면 서버에서는 해당 이미지를 받아 컨테이너로 실행하면 됩니다. 기존 방식처럼 서버에 Java, Node.js, 라이브러리, 설정 파일을 하나씩 설치하고 맞추는 과정이 줄어들기 때문에 배포 과정이 단순해질 수 있습니다.

3. 격리된 실행 환경

컨테이너는 서로 독립된 환경에서 실행됩니다. 하나의 서버에서 여러 애플리케이션을 실행하더라도 각 애플리케이션의 실행 환경을 분리할 수 있습니다.

예를 들어 서로 다른 Java 버전이나 라이브러리 구성이 필요한 애플리케이션도 컨테이너를 통해 분리해서 실행할 수 있습니다.

4. 확장과 운영에 유리

Docker는 컨테이너 단위로 애플리케이션을 실행하기 때문에 인스턴스를 추가하거나 교체하는 방식이 비교적 단순합니다. 또한 Kubernetes 같은 컨테이너 오케스트레이션 도구와 함께 사용하면 여러 서버에 걸쳐 컨테이너를 배포하고 관리할 수 있습니다.

Docker를 처음에는 단순히 애플리케이션을 컨테이너화하는 도구로만 생각했습니다. 하지만 이번에 컨테이너화와 Docker의 구조를 정리하면서 Docker가 단순한 실행 도구를 넘어 배포 환경을 일관되게 도움을 주는 기술이라는 점을 알 수 있었습니다.

특히 여러 프로젝트를 각각 컨테이너로 분리해 현재 사용 중인 Ubuntu 서버에서 독립적으로 실행할 수 있다는 점이 흥미로웠습니다. 하나의 서버 안에서도 프로젝트별 실행 환경을 분리하고, 포트와 Nginx 설정을 통해 여러 서비스를 함께 운영할 수 있다는 점에서 Docker의 활용 가능성을 더 구체적으로 이해하게 되었습니다. 다음 시간에는 GraphQL에 대해 알아보겠습니다. 감사합니다.

메시지 브로커 - RabbitMQ와 Kafka

밈밍민믹 — Wed, 27 May 2026 13:52:55 +0900

안녕하세요. 벌써 수요일이네요. 드디어 내일 깁스를 풀기위해 병원을 갑니다. 이전에는 아마 이후에는 보호대로 재활을 하는게 좋다고 했는데...내일 병원가서 상태가 괜찮으면 좋겠네요. 그래도 완전한 여름이 되기 전에 깁스를 풀 수 있어서 다행이네요. 자 그럼 메시지 브로커에 대한 학습 시작해보겠습니다.

메시지 브로커

메시지 브로커는 시스템 간에 주고받는 메시지를 중간에서 전달해주는 역할을 하는 소프트웨어입니다. 일반적으로 요청을 보내는 쪽을 Producer, 메시지를 처리하는 쪽을 Consumer라고 합니다. Producer는 Consumer를 직접 호출하지 않고 메시지 브로커에 메시지를 전달합니다. 이후 Consumer는 메시지 브로커에서 메시지를 가져와 필요한 작업을 처리합니다.

Producer → Message Broker → Consumer

예를 들어 주문이 완료되었을 때 주문 서비스가 알림 서비스, 배송 서비스, 재고 서비스를 직접 호출할 수 있습니다. 하지만 이 경우 각 서비스의 장애나 응답 지연이 주문 처리 흐름에 영향을 줄 수 있습니다.

메시지 브로커를 사용하면 주문 서비스는 "주문 완료" 메시지만 브로커에 전달하고, 알림 서비스·배송 서비스·재고 서비스는 각자 필요한 메시지를 받아 처리할 수 있습니다.

주문 서비스 → 메시지 브로커 → 알림 서비스

주문 서비스 → 메시지 브로커 → 배송 서비스

주문 서비스 → 메시지 브로커 → 재고 서비스

즉, 메시지 브로커는 시스템 사이의 중간 전달자 역할을 하며, 서비스 간 결합도를 낮추고 비동기 처리를 가능하게 합니다.

메시지 브로커가 필요한 이유

메시지 브로커를 사용하는 이유는 크게 세 가지로 볼 수 있습니다.

1. 비동기 처리

사용자의 요청 중에는 응답 전에 반드시 끝나야 하는 작업도 있지만, 응답 이후에 처리해도 되는 작업도 있습니다. 예를 들어 회원가입 자체는 즉시 완료되어야 하지만, 환영 이메일 발송은 나중에 처리되어도 됩니다.

이처럼 핵심 요청과 분리할 수 있는 작업을 메시지 브로커로 넘기면, 서버는 사용자에게 더 빠르게 응답하고 부가 작업은 Consumer가 비동기로 처리할 수 있습니다.

2. 서비스 간 결합도 감소

주문 서비스가 알림 서비스, 배송 서비스, 재고 서비스의 API를 직접 호출하면 각 서비스의 장애나 변경이 주문 서비스에 직접적인 영향을 줄 수 있습니다. 그렇기에 메시지 브로커를 사용하면 각 서비스는 메시지를 기준으로 느슨하게 연결할 수 있습니다.

3. 장애 대응

Cosumer가 일시적으로 장애가 나더라도 메시지 브로커에 메시지가 남아 있다면, Consumer가 복구된 후 다시 메시지를 처리할 수 있습니다.

메시징 모델

메시지 브로커는 메시지를 전달하는 방식에 따라 여러 모델로 나누어 볼 수 있습니다.
대표적으로 점대점 모델(Point-to-Point) 과 게시/구독 모델(Publish/Subscribe) 이 있습니다.

두 모델은 모두 Producer가 메시지를 보내고 Consumer가 메시지를 처리한다는 공통점이 있지만, 하나의 메시지를 누가 소비하는지에서 차이가 있습니다.

1. 점대점 모델

점대점 모델은 하나의 메시지를 하나의 Consumer가 처리하는 방식입니다.

Producer가 메시지를 Queue에 넣으면, Consumer는 Queue에 쌓인 메시지를 가져가 처리합니다. 여러 Consumer가 같은 Queue를 바라보고 있더라도, 하나의 메시지는 보통 하나의 Consumer에게만 전달됩니다.

Producer → Queue → Consumer

여러 Consumer가 있는 경우 다음과 같이 작업을 나누어 처리할 수 있습니다.

Producer → Queue → Consumer A
→ Consumer B
→ Consumer C

예를 들어 이메일 발송 작업이 1,000건 쌓여있다고 가정해보겠습니다. 하나의 Consumer가 모든 이메일을 처리하면 시간이 오래 걸릴 수 있습니다. 이때 여러 Consumer가 같은 Queue에서 메시지를 하나씩 가져가 처리하면 작업을 분산해서 처리할 수 있습니다.

즉, 점대점 모델은 "해야 할 작업을 Queue에 쌓고, 가능한 Consumer가 하나씩 가져가 처리하는 구조"에 가깝습니다.

2. 게시/구독 모델

게시/구독 모델은 하나의 메시지를 여러 Consumer가 받아 처리할 수 있는 방식입니다.

Producer는 메시지를 특정 Topic에 발행합니다. 그리고 해당 Topic을 구독하고 있는 Consumer들이 메시지를 받아 각자의 작업을 처리합니다

Producer → Topic → Consumer A
→ Consumer B
→ Consumer C

예를 들어 주문이 완료되었을 때 "주문 완료" 이벤트가 발생했다고 가정해보겠습니다. 이 이벤트는 알림 서비스, 배송 서비스, 통계 서비스가 모두 필요로 할 수 있습니다.

주문 완료 이벤트
→ 알림 서비스: 주문 완료 알림 발송
→ 배송 서비스: 배송 준비 요청
→ 통계 서비스: 매출 통계 반영

이때 게시/구독 모델을 사용하면 주문 서비스는 "주문 완료" 이벤트를 한 번만 발행하면 됩니다. 이후 해당 이벤트를 구독하는 여러 서비스가 각자 필요한 작업을 처리합니다.

즉, 게시/구독 모델은 "하나의 이벤트를 여러 시스템이 각자의 목적에 맞게 소비하는 구조"에 가깝습니다.

동기 처리와 비동기 처리

메시지 브로커를 이해하기 위해서는 동기 처리와 비동기 처리의 차이를 먼저 이해하는 것이 좋습니다.

동기 처리는 요청을 보낸 뒤 결과가 돌아올 때까지 기다리는 방식입니다. 반면 비동기 처리는 요청을 보낸 뒤 결과를 기다리지 않고 다음 작업을 진행할 수 있는 방식입니다.

구분	동기 처리	비동기 처리
처리 방식	결과가 올 때까지 기다림	요청 후 다음 작업 진행 가능
장점	흐름이 단순하고 결과 확인이 쉬움	응답 시간을 줄이고 작업 분리가 쉬움
단점	처리 시간이 길어질 수 있음	처리 결과 추적이 필요함
예시	결제 승인 결과 확인	이메일 발송, 알림 발송, 로그 저장

모든 작업을 비동기로 처리하는 것이 좋은 것은 아닙니다. 결제 승인, 좌석 예약, 재고 차감처럼 즉시 결과가 중요하고 데이터 정합성이 필요한 작업은 동기적으로 처리하는 것이 더 적절할 수 있습니다. 반면 알림 발송, 로그 저장처럼 요청의 핵심 결과에 직접 영향을 주지 않는 작업은 비동기 처리로 분리하기 좋습니다.

RabbitMQ란?

RabbitMQ는 메시지를 Queue에 저장하고 Consumer에게 전달하는 방식에 강점이 있는 메시지 브로커입니다. RabbitMQ에서는 Producer가 메시지를 보내면 Exchange가 메시지를 어떤 Queue로 보낼지 결정하고, Consumer는 Queue에 쌓인 메시지를 가져가 처리합니다. 그렇기에 작업 큐, 알림 발송, 이메일처럼 메시지를 안정적으로 전달하고 작업을 분산 처리해야 하는 상황에서 자주 사용됩니다.

Producer → Exchange → Queue → Consumer

RabbitMQ의 특징은 메시지를 Consumer에게 전달하고, Consumer가 처리 완료를 알리면 메시지를 제거하는 방식에 가깝습니다. 따라서 특정 작업을 안정적으로 처리해야 하는 작업 큐 구조에 적합합니다.

Kafka란?

Kafka는 대량의 이벤트 데이터를 빠르게 저장하고 처리하는 데 강점이 있는 분산 이벤트 스트리밍 플랫폼입니다. Kafka에서는 메시지를 Topic에 저장하고, Consumer는 자신이 읽은 위치인 Offset을 기준으로 메시지를 가져갑니다. 메시지는 Consumer가 읽었다고 바로 삭제되지 않고, 설정된 보관 기간 동안 저장될 수 있습니다. 이러한 특징 때문에 Kafka는 로그 수집, 사용자 행동 이벤트 처리, 실시간 데이터 파이프라인, 대규모 이벤트 처리에 많이 사용됩니다.

Producer → Topic → Partition → Consumer

Kafka는 메시지를 단순히 전달하는 것보다 이벤트를 일정 기간 저장하고 여러 Consumer가 각자의 속도에 맞게 읽을 수 있다는 점이 특징입니다.

RabbitMQ와 Kafka의 차이

RabbitMQ는 "해야 할 작업을 Queue에 넣고 Consumer가 처리하는 구조"에 가깝고, Kafka는 "발생한 이벤트를 Topic에 기록하고 여러 Consumer가 필요한 시점에 읽는 구조"에 가깝습니다.

구분	RabbitMQ	Kafka
중심 개념	Queue 기반 메시지 전달	Topic 기반 이벤트 스트리밍
메시지 처리 방식	Consumer가 처리하면 메시지 제거	메시지를 일정 기간 저장
강점	작업 큐, 안정적인 메시지 전달	대량 이벤트 처리, 로그/스트리밍
Consumer 방식	메시지를 전달받아 처리	Offset 기준으로 메시지를 읽음
적합한 상황	이메일 발송, 알림 처리, 작업 분산	로그 수집, 실시간 분석, 이벤트 파이프라인
관점	메시지 브로커	이벤트 스트리밍 플랫폼

어떤 상황에서 사용할까?

메시지 브로커는 다음과 같은 상황에서 사용할 수 있습니다.

상황	설명
이메일 발송	회원가입 후 환영 이메일을 비동기로 발송
알림 처리	주문 완료, 댓글 작성, 좋아요 발생 시 알림 전송
이미지 처리	이미지 업로드 후 썸네일 생성 작업 분리
로그 수집	사용자 행동 로그, 서버 로그를 모아 분석
주문 후속 처리	주문 완료 후 재고, 배송, 알림 작업 분리
이벤트 기반 구조	서비스 간 직접 호출 대신 이벤트로 연결

예를 들어 SNS 서비스에서 사용자가 댓글을 작성했을 때, 댓글 저장은 즉시 처리되어야 하지만 알림 발송은 비동기로 분리할 수 있습니다. 댓글 저장이 성공한 뒤 "댓글 작성 이벤트"를 메시지 브로커에 전달하고, 알림 서비스가 해당 메시지를 소비해 알림을 보내는 방식입니다.

다음 시간에는 컨테이노화와 가상화 그리고 Docker에 대해서 얘기해보도록 합시다. 수고하셨습니다.

만보기 API 연동하기(1)

밈밍민믹 — Tue, 26 May 2026 22:03:21 +0900

안녕하세요. 요즘 개발하는게 다시 재밌어져서 이전에는 생각하지 못했던 것에 대한 기획이나 계획 등 재미를 다시 느끼는 것 같습니다. 이번에는 저의 프로젝트에서 필요한 만보기와 지도의 현재 위치, 마커 표시 등에 대해서 API를 가져오는 과정을 얘기해보고자 합니다. 그럼 시작해봅시다.

프로젝트 구조

현재 제 프로젝트의 구조는 백엔드는 Java/Spring Boot, 프론트엔드는 Flutter(Dart), 서버 및 데이터베이스는 Ubuntu + Nginx/MySQL로 구성되어 있습니다. 안드로이드 앱을 기준으로 개발을 시작했지만, 포트폴리오 목적으로 웹을 먼저 배포했습니다. 이후 기능이 어느 정도 완성되면 원스토어 배포까지 진행하는 것이 목표입니다.

그렇기 때문에 API를 추가하기 전에 먼저 고민해야 할 부분이 있었습니다.

첫 번째는 웹에서는 만보기 기능이 필요하지 않다는 점입니다.
만보기는 사용자가 실제로 휴대폰을 들고 이동할 때 의미가 있는 기능이기 때문에, 웹 환경에서는 직접적인 만보기 측정 기능을 구현할 필요가 없습니다.

다만 웹에서도 앱과 완전히 분리된 화면이 아니라면, 서버에 저장된 오늘 걸음 수나 캐릭터 상태를 조회하는 정도는 필요할 수 있습니다. 즉, 측정은 앱에서만 수행하고, 조회는 웹에서도 가능하도록 구성하는 방식이 적절하다고 판단했습니다.

Flutter에서는 kIsWeb 등을 이용해 실행 환경을 구분할 수 있기 때문에, 만보기 센서 연동은 앱 환경에서만 동작하도록 분기 처리할 수 있습니다.

if (!kIsWeb) {
  // Android 앱에서만 만보기 센서 실행
}

두 가지로 나뉜 만보기 기능

처음에는 "만보기 기능" 하나로 생각했지만, 실제로는 성격이 다른 두 기능으로 나눌 필요가 있었습니다.

캐릭터 페이지의 오늘 걸음 수
지도 페이지의 러닝/산책 경로 기록

캐릭터 페이지의 만보기는 오늘 하루 동안 얼마나 걸었는지를 보여주는 기능입니다.

반면 지도 페이지의 러닝 기록은 특정 시간 동안 어디를 걸었고, 그 경로와 당시 걸음 수가 어땠는지 보여주는 기능입니다.

그래서 같은 만보기처럼 보여도 저장 방식과 API 구조를 분리하는 것이 더 적절하다고 판단했습니다.

앞으로 추가할 API

앞서 언급했듯이 만보기에 대해서 외에도 지도 ..뭐뭐를 위해서 추가할 예정이며 이번 편은 캐릭터 페이지의 오늘 걸음 수에 대한 글만을 정리할 예정입니다.

기능	추천 패키지	역할
만보기/걸음 수	pedometer 또는 health	걸음 수 측정
현재 위치/이동 경로	geolocator	GPS 좌표 수집
지도 표시	google_maps_flutter	지도, 마커, Polylien 표시
백그라운드 기록	flutter_foreground_task 또는 flutter_background_geolocation	앱이 내려가도 위치/걸음 기록 유지

캐릭터 페이지용 일일 만보기 API

캐릭터 페이지에서는 오늘 걸음수를 보여줘야 합니다.

오늘의 걸음 수 / 목표 걸음수(보통 10,000으로 설정 예정)

해당 기능은 하루 단위로 관리하는 것이 좋기에 DailyStep 구조를 사용하겠습니다.

DailyStep
- user_id
- step_date
- step_count
- goal_steps
- created_at
- updated_at

여기서 중요한 점은 매일 00시에 DB 값을 직접 0으로 초기화하지 않는다는 점입니다. 대신 날짜 기준으로 조회합니다.

2026-05-26 → 2026-05-26의 DailyStep 조회
2026-05-27 → 2026-05-27의 DailyStep 조회

즉, 날짜가 바뀌면 자연스럽게 오늘 걸음 수가 0부터 시작하는 구조입니다.

구현하기

저는 안드로이드 앱을 기준으로 만보기 기능을 구현할 예정이기에 바로 백엔드 API부터 만들기보다는 Flutter에서 실제 기기 센서값이 정상적으로 들어오는지 먼저 확인하기로 했습니다.

만보기 기능은 일반적인 CRUD 기능과 달리 사용자의 기기 센서, 권한, 실행 환경에 영향을 많이 받습니다. 따라서 백엔드에 저장 구조를 먼저 만들기 전에 프론트엔드에서 다음 항목들을 먼저 검증할 필요가 있습니다.

1. 실제 Android 기기에서 걸음 수가 측정되는가?
2. 신체 활동 권한 요청이 정상적으로 동작하는가?
3. 위치 좌표가 정상적으로 수집되는가?
4. 수집된 좌표를 리스트 형태로 관리할 수 있는가?
5. 이후 서버로 전송할 데이터 형태를 만들 수 있는가?

이 과정을 통해 실제 앱 환경에서 만보기 기능이 동작하는지 확인한 뒤, 그 결과를 바탕으로 백엔드 API와 DB 구조를 설계하고 프론트엔드에 적용하는 순서로 진행했습니다.

프론트엔드 테스트 → 백엔드 API 구현→ 서버 배포 및 API 확인→캐릭터 페이지 연동

프론트엔드 테스트하기

먼저 Flutter에서 만보기와 위치 정보가 정상적으로 수집되는지 확인하기 위해 임시 데이터 페이지를 만들었습니다. 이 테스트 페이지의 목적은 최종 UI를 만드는 것이 아닌 실제 Android 기기에서 센서 데이터가 들어오는지 확인하는 것이었습니다.

1. pubspec.yaml 설정하기

pedometer: 4.1.1 #기기의 걸음 수 센서 값 수신
geolocator: 10.1.1 # 현재 위치 및 위치 변환 감지
google_maps_flutter: 2.3.0 # 지도 표시 및 경로 시각화 테스트
permission_handler: 10.4.5 #신체 활동 권한 요청

2. AndroidManifest.xml에 권한 요청

  <uses-permission android:name="android.permission.ACTIVITY_RECOGNITION" />
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

3. 테스트 페이지 작성

추후 지도에서의 만보기도 같이 추가할 예정이기에 테스트 페이지에서는 다음 정보를 화면에 표시했습니다.

현재 걸음 수
현재 위치 위도/경도
수집된 좌표 개수
측정 상태

처음에는 지도까지 함께 표시하려고 했지만, Google Map 발급과 함께 초기화 과정에서 문제가 발생할 수 있기에 일단은 제거하고, 걸음 수와 좌표가 들어오는지 먼저 확인했습니다.

신체 활동 권한 요청

Future<bool> requestActivityPermission() async {
  final status = await Permission.activityRecognition.status;

  if (status.isGranted) {
    return true;
  }

  final result = await Permission.activityRecognition.request();

  if (result.isGranted) {
    return true;
  }

  return false;
}

이 코드는 사용자가 이미 권한을 허용했다면 바로 true를 반환하고, 아직 허용하지 않았다면 권한 요청 창을 띄웁니다.

이 과정을 추가한 뒤에야 Pedometer.stepCountStream에서 걸음 수가 정상적으로 들어오는 것을 확인할 수 있었습니다.

걸음 수 측정

StreamSubscription<StepCount>? _stepSubscription;

int? startStepCount;
int currentSteps = 0;

_stepSubscription = Pedometer.stepCountStream.listen(
  (StepCount event) {
    startStepCount ??= event.steps;

    setState(() {
      currentSteps = event.steps - startStepCount!;
    });

    debugPrint('시작 기준 걸음 수: $startStepCount');
    debugPrint('현재 운동 걸음 수: $currentSteps');
  },
  onError: (error) {
    debugPrint('걸음 수 측정 오류: $error');
  },
);

권한 확인 후 Pedometer.stepCountStream을 구독했습니다.

여기서 중요한 점은 event.steps가 "이번 측정에서 걸은 걸음 수"가 아니라, 거기 기준 누적 걸음 수처럼 들어올 수 있다는 점입니다.

그래서 측정을 시작한 순간의 값을 startStepCount로 저장하고, 이후 값에서 빼는 방식으로 현재 측정 중 걸음 수를 계산했습니다.

현재 측정 걸음 수 = 현재 센서 걸음 수 - 시작 시점 센서 걸음 수

위치 좌표 수집

StreamSubscription<Position>? _positionSubscription;

Position? currentPosition;
final List<LatLng> routePoints = [];

const LocationSettings locationSettings = LocationSettings(
  accuracy: LocationAccuracy.high,
  distanceFilter: 5,
);

_positionSubscription = Geolocator.getPositionStream(
  locationSettings: locationSettings,
).listen(
  (Position position) {
    final point = LatLng(
      position.latitude,
      position.longitude,
    );

    setState(() {
      currentPosition = position;
      routePoints.add(point);
    });

    debugPrint('위치: ${position.latitude}, ${position.longitude}');
  },
  onError: (error) {
    debugPrint('위치 측정 오류: $error');
  },
);

distanceFilter: 5는 사용자가 약 5m 정도 이동했을 때 위치 업데이트를 받도록 설정한 값입니다.

이렇게 수집한 좌표들은 이후 지도 페이지에서 마커와 선으로 경로를 표시할 때 사용할 수 있습니다.

백엔드 API 구현

프론트엔드 테스트를 통해 실제 Android 기기에서 걸음 수와 위치 좌표를 수집할 수 있음을 확인했습니다. 이후에는 이 데이터를 서버에 저장하고, 캐릭터 페이지에서 다시 조회할 수 있도록 백엔드 API를 구현했습니다.

필요한 데이터 구조

캐릭터 페이지의 만보기는 사용자별로 하루에 하나의 기록만 있으면 됩니다. 따라서 DailStep 엔티티는 다음 정보를 갖도록 설계했습니다.

DailyStep
- user
- stepDate
- stepCount
- goalSteps
- createdAt
- updatedAt

여기서 stepDate를 둔 이유는 매일 00시에 데이터를 직접 초기화하지 않고, 날짜 기준으로 오늘의 데이터를 조회하기 위해서입니다.

또한 한 사용자에게 같은 날짜의 데이터가 여러 개 생기면 오늘 걸음 수가 중복될 수 있기 때문에, user_id + step_date 조합은 유니크하게 관리하는 것이 좋습니다.

DTO는 크게 두 개만 필요했습니다.

StepUpdateRequest
→ 앱에서 서버로 현재 걸음 수를 보낼 때 사용

TodayStepResponse
→ 캐릭터 페이지에 오늘 걸음 수와 목표 걸음 수를 내려줄 때 사용

서비스 로직 작성

해당 서비스 로직에서는 담당하는 역할은 크게 두 가지입니다.

1. 앱에서 전달한 오늘 걸음 수를 저장하거나 갱신한다.

2. 캐릭터 페이지에 표시할 오늘 걸음 수를 조회한다.

@Service
@RequiredArgsConstructor
public class DailyStepService {

    private final DailyStepRepository dailyStepRepository;
    private final UserRepository userRepository;

    @Transactional
    public TodayStepResponse updateTodaySteps(
            StepUpdateRequest request,
            Authentication authentication
    ) {
        String email = authentication.getName();

        User user = userRepository.findByEmail(email)
                .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 사용자입니다."));

        LocalDate today = LocalDate.now();

        DailyStep dailyStep = dailyStepRepository
                .findByUserIdAndStepDate(user.getId(), today)
                .orElseGet(() -> DailyStep.create(user, today, 0));

        dailyStep.updateStepCount(request.getStepCount());

        DailyStep saved = dailyStepRepository.save(dailyStep);

        return new TodayStepResponse(
                saved.getStepCount(),
                saved.getGoalSteps()
        );
    }

    @Transactional(readOnly = true)
    public TodayStepResponse getTodaySteps(Authentication authentication) {
        String email = authentication.getName();

        User user = userRepository.findByEmail(email)
                .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 사용자입니다."));

        LocalDate today = LocalDate.now();

        return dailyStepRepository.findByUserIdAndStepDate(user.getId(), today)
                .map(dailyStep -> new TodayStepResponse(
                        dailyStep.getStepCount(),
                        dailyStep.getGoalSteps()
                ))
                .orElseGet(() -> new TodayStepResponse(0, 10000));
    }
}

로그인한 사용자를 확인한 후 → 오늘 날짜 기준 DailyStep 조회 → 있으면 걸음 수 갱신 → 없으면 새 DailyStep 생성 → 캐릭터 페이지에 필요한 todaySteps, goalSteps 반환

이후 프론트엔드와 연동하면서 캐릭터 페이지에서 실제 걸음수가 표시되고, 사용자가 걸을 때마다 숫자가 증가하는 것을 확인할 수 있었습니다.

이번 시간에는 만보기 API를 연동하고 직접 센서가 작동하는지 확인하는 시간을 가졌습니다. 원래라면 현재 언급한 모든 기능을 넣은 후에 다음 기능으로 넘어갈 예정이였습니다만 그렇게되면 앱스토어에 배포하는데까지 오랜 시간이 걸릴 것으로 판단되어 만보기 API는 초기 기획했던 현재의 정도로만 넣은 후 앱스토어에 배포한 다음 추가할 예정입니다.

아마 다음 기능으로 친구 추가를 통해 웹소켓 기능을 더욱 편하게 만들도록 할 것 같아요. 몇 가지 오류나 UI/UX측면에서 불편한 점까지 수정하면 앱스토어에 배포도 할 것 같습니다. 다음 시간에는 또 다른 주제의 개발일지로 돌아오며 만보기 API도 꼭 끝마치도록 하겠습니다. 감사합니다.

검색 엔진 - Elasticsearch

밈밍민믹 — Tue, 26 May 2026 09:49:20 +0900

안녕하세요. 좋은 아침입니다. 오늘부터 천천히 아침 일찍 일어나다가 깁스를 풀고나면 그때부터 미라클 모닝을 하려고 합니다. 최근 오전 5시에 일어나게 된 이유라는 영상을 보게되었는데, 결국 일찍 자면 일찍 일어나게 된다는게 당연하면서도 여태 이걸 하지 못했구나 싶더라고요? 저도 과거에 미라클 모닝했던 기억이 생각나면서 다시 도전하려고 합니다.

오늘도 일찍 수면에 취한 덕분에 알림 없이 잘 일어났네요. 그럼 검색엔진에 대한 학습 시작하도록 하겠습니다.

검색 엔진

검색 엔진(Search Engine)은 대량의 데이터에서 사용자가 원하는 정보를 빠르게 찾을 수 있도록 도와주는 시스템입니다.

일반적으로 검색이라고 하면 구글이나 네이버 같은 웹 검색을 떠올릴 수 있지만, 서비스 내부에서도 검색 엔진을 자주 사용합니다.

예를 들어 쇼핑몰에서 상품명을 검색하거나, 커뮤니티에서 게시글을 검색하거나, 운영자가 서버 로그에서 특정 에러 메시지를 찾는 경우가 있습니다.

즉, 검색 엔진은 단순히 데이터를 저장하는 것이 아니라 사용자가 입력한 검색어와 가장 관련 있는 데이터를 빠르게 찾아주는 역할을 합니다.

검색 엔진의 주요 작동 원리 3단계

1. 크롤링

검색 대상이 되는 데이터를 수집하는 단계입니다.

웹 검색 엔진이라면 웹 페이지를 수집하고, 서비스 내부 검색이라면 게시글, 상품, 사용자 데이터, 로그 데이터 등을 검색 대상으로 가져올 수 있습니다.

즉, 크롤링은 꼭 웹 페이지에만 한정되기보다 검색에 사용할 원본 데이터를 모으는 과정으로 이해할 수 있습니다.

2. 인덱싱

수집한 데이터를 검색하기 좋은 형태로 가공하고 저장하는 단계입니다.

단순히 원본 데이터를 그대로 저장하는 것이 아니라 텍스트를 추출하고, 단어를 나누고, 불필요한 요소를 정리한 뒤 검색에 적합한 인덱스를 생성합니다.

검색 엔진이 빠르게 검색할 수 있는 이유는 이 인덱싱 과정에서 미리 검색용 자료구조를 만들어두기 때문입니다.

3. 결과 제공

사용자가 검색어를 입력하면 검색 엔진은 미리 만들어둔 인덱스를 기준으로 관련 문서를 찾습니다.

이후 단순히 포함 여부만 보는 것이 아니라, 검색어와 문서의 관련도, 문서의 중요도, 사용자 행동 데이터 등을 고려해 결과의 순위를 매기고 사용자에게 제공합니다.

DB 검색과 검색 엔진의 차이

데이터베이스에서도 검색 기능을 구현할 수 있습니다. 예를 들어 MySQL에서는 'LIKE' 검색을 사용해 특정 문자열이 포함된 데이터를 조회할 수 있습니다.

SELECT * FROM posts WHERE title LIKE '%검색어%;

하지만 이러한 방식은 데이터가 많아질수록 성능 문제가 발생할 수 있습니다. 특히 앞뒤로 %가 붙는 검색은 인덱스를 효율적으로 사용하기 어렵고, 전체 데이터를 훑어보는 방식에 가까워질 수 있습니다.

또한 일반적인 DB 검색은 사용자가 입력한 검색어의 유사도, 형태소 분석, 오타 보정, 관련도 점수 계산 같은 검색 특화 기능을 처리하기 어렵습니다.

따라서 DB는 데이터를 정확하게 저장하고 조회하는데 강점이 있고, 검색 엔진은 대량의 텍스트에서 관련성 높은 결과를 빠르게 찾는 데 강점이 있습니다.

Elasticsearch란?

Elasticsearch는 대량의 데이터를 실시간으로 저장, 검색 및 분석하기 위해 사용되는 오픈소스 분산형 검색 엔진입니다. Apache Lucene을 기반으로 만들어졌으며, REST API를 통해 데이터를 저장하고 검색할 수 있습니다. 검색 기능뿐만 아니라 로그 분석, 모니터링, 통계 분석 등 다양한 상황에서도 사용됩니다.

대표적으로 기본 백엔드로 사용하거나 로그 및 지표 분석, 엔터프라이즈 검색, 보안 인텔리전스에 자주 사용됩니다.

Apache Lucene

Apache Lucene은 Java로만 작성된 무료 오픈 소스 검색 엔진 라이브러리입니다. Lucene은 주로 검색 엔진 구현 기능으로 유명합니다.

Lucene은 문서를 검색 및 인덱스의 기본 단위로 활용합니다. 모든 문서 콘텐츠를 키워드 중심 데이터 구조로 인덱싱하고 저장하기 때문입니다. 또한 매우 빠른 검색 응답 시간을 달성할 수 있습니다. Lucene에 저장된 콘텐츠는 웹 사이트, 파일 시스템 및 Postgre SQL과 같은 데이터베이스를 비롯한 다양한 소스에서 가져올 수 있습니다.

Apache Lucene의 장점

수평적 확장성
여러 코딩 언어 지원
자동 완성
플러그인 및 통합 지원

Elasticsearch의 특징

탁월한 검색 성능
- 역인덱스 구조를 사용하여 방대한 양의 데이터에서도 초고속 풀텍스트 검색을 제공합니다.
수평적 확장성
- 데이터를 여러 조각(샤드)으로 나누어 분산 저장 및 처리하므로 서버를 추가하여 용량과 성능을 손쉽게 늘릴 수 있습니다.
RESTful API
- JSON 기반의 HTTP 요청을 통해 데이터를 간편하게 색인하고 쿼리할 수 있습니다.
ELK 스택의 중심
- 데이터 수집 및 시각화 도구인 Logstash, Kibana와 결합하여 시스템 모니터링, 로그 분석 등 다양한 분야에 활용됩니다.

Elasticsearch 구조

논리적 구조

논리적 구조는 데이터를 어떻게 저장하고 표현하는지를 설명합니다.

Index

Index는 Document들이 저장되는 논리적인 공간입니다. 관계형 데이터베이스에 비유하면 테이블과 비슷하게 볼 수 있습니다.

예를 들어 게시글 검색 기능을 만든다면 posts라는 Index를 만들 수 있습니다.

Index : posts

다만 Elasticsearch의 Index는 RDBMS의 테이블과 완전히 같은 개념은 아닙니다.

Document

Document는 Elasticsearch에 저장되는 데이터 한 건입니다. Elasticsearch에서는 데이터가 JSON 형태의 Document로 저장됩니다.

예를 들어 게시글 하나는 다음과 같이 Document가 될 수 있습니다.

{
  "title": "Elasticsearch란?",
  "content": "Elasticsearch는 대량의 데이터를 빠르게 검색하기 위한 검색 엔진입니다.",
  "author": "user1",
  "createdAt": "2026-05-26"
}

Field

Field는 Document 안에 있는 각각의 속성입니다.

위 예시에서는 다음 값들이 Field입니다.

title
content
author
createdAt

각 Field는 검색 방식에 따라 다르게 다룰 수 있습니다.

예를 들어 title과 content는 문장을 분석해서 검색해야 하므로 전문 검색 대상이 될 수 있고, author는 정확히 일치하는 값으로 검색하는 것이 더 적합할 수 있습니다.

Mapping

Mapping은 각 Field가 어떤 타입을 가지며, 어떻게 인덱싱될지를 정의하는 설정입니다.

{
  "title": "text",
  "content": "text",
  "author": "keyword",
  "createdAt": "date"
}

여기서 text는 문장을 분석해서 검색할 때 사용하고, keyword는 정확한 값 비교에 사용합니다.

예를 들어 title이 text라면 "Elasticsearch란?"이라는 문장이 분석되어 검색 가능한 단어 단위로 처리될 수 있습니다.

반면 author가 keyword라면 "user1"이라는 값 전체를 기준으로 정확히 일치하는 데이터를 찾는 데 적합합니다.

물리적 구조

실제로 데이터를 어떻게 저장하고 분산 처리하는지를 설명합니다.

Cluster

Cluster는 하나 이상의 Node가 모여 구성된 Elasticsearch 전체 시스템입니다.

서비스 규모가 작다면 하나의 Node로도 Elasticsearch를 실행할 수 있지만, 데이터가 많아지고 안정성이 중요해지면 여러 Node를 하나의 Cluster로 구성할 수 있습니다.

Cluster
 ├─ Node 1
 ├─ Node 2
 └─ Node 3

Node

Node는 Elasticsearch가 실행되는 하나의 서버입니다. 하나의 Cluster 안에는 여러 Node가 존재할 수 있습니다.

각 Node는 데이터를 저장하거나, 검색 요청을 처리하거나, Cluster 상태를 관리하는 역할을 할 수 있습니다.

즉, Node는 Elasticsearch 시스템을 구성하는 개별 서버 단위입니다.

Shard

Shard는 한의 Index를 나누어 저장하는 단위입니다.

예를 들어 posts Index에 게시글 데이터가 매우 많아졌을 때, 이 데이터를 하나의 서버에만 저장하면 저장 공간과 검색 처리에 부담이 생길 수 있습니다. 그래서 Elasticsearch는 하나의 Index를 여러 Shard로 나누어 저장할 수 있습니다.

posts Index
 ├─ Shard 0
 ├─ Shard 1
 └─ Shard 2

Replica

Replica는 Shard의 복제본입니다.

예를 들어 Shard 0의 원본이 Node 1에 저장되어 있다면, 그 복제본을 Node 2에 저장할 수 있습니다.

Node 1: Shard 0
Node 2: Shard 0 Replica

Replica를 두는 이유는 크게 두 가지입니다.

첫 번째는 장애 대비입니다.

Primary Shard가 있는 Node에 문제가 생겨도 Replica Shard를 통해 데이터를 유지할 수 있습니다.

두 번 째는 검색 성능 향상입니다.

검색 요청은 Primary Shard 뿐만 아니라 Replica Shard에서도 처리할 수 있기에 요청을 분산해서 처리할 수 있습니다.

역색인 구조란?

Elasticsearch가 빠르게 검색할 수 있는 핵심 이유 중 하나는 역색인 구조를 사용하기 때문입니다.

일반적인 데이터 저장 방식은 문서 안에 어떤 단어가 있는지 확인합니다. 반면 역색인은 단어를 기준으로 해당 단어가 어떤 문서에서 등장하는지 미리 정리해둡니다.

예를 들어 다음과 같이 게시글이 있다고 가정해보겠습니다.

문서 ID	제목
1	Spring Boot 검색 기능 구현
2	Elasticsearch 검색 엔진 학습
3	Spring Security

이를 역색인 구조로 정리하면 다음과 같이 볼 수 있습니다.

단어	등장한 문서
Spring	1, 3
Boot	1
검색	1, 2
Elasticsearch	2
Security	3

이렇게 단어별로 어떤 문서에 등장했는지 미리 정리해두면 사용자가 "검색"이라는 단어를 입력했을 때 모든 문서를 처음부터 끝까지 확인하지 않아도 됩니다. 이미 만들어진 역색인에서 "검색"이라는 단어가 등장한 문서 목록을 바로 찾을 수 있기 때문입니다.

Elasticsearch가 사용되는 상황

Elasticsearch는 다음과 같은 상황에서 사용할 수 있습니다.

상황	설명
상품 검색	상품명, 카테고리, 브랜드, 설명 등을 기준으로 검색
게시글 검색	제목, 내용, 작성자, 태그 기반 검색
로그 검색	서버 로그, 에러 로그, 사용자 행동 로그 분석
자동 완성	사용자가 입력하는 검색어에 맞춰 추천어 제공
필터 검색	가격, 지역, 날짜, 카테고리 조건을 함께 적용

예를 들어 제 개인 프로젝트인 커뮤니티 서비스에서는 게시글 제목과 내용을 기준으로 검색 기능을 제공할 수 있겠네요. 단순한 규모에서는 RDBMS 검색으로도 충분할 수 있지만, 게시글 수가 많아지고 검색 정확도나 속도가 중요해진다면 Elasticsearch 같은 검색 엔진을 고려할 수 있습니다.

오늘은 검색 엔진과 Elasticsearch에 대해 학습해보았습니다.

역색인 구조가 단순하지만 색인 구조가 아닌 역색인을 통해 검색 효율을 높인점이 굉장히 인상깊었던 것 같습니다. 다음 시간에는 메시지 브로커와 함께 돌아오도록 하겠습니다. 수고하셨습니다.

아키텍처 패턴(2) - CQRS, 이벤트 소싱, 서버리스란 무엇인가?

밈밍민믹 — Mon, 25 May 2026 22:23:43 +0900

안녕하세요. 좋은 밤입니다. 오늘은 쉬려고 했으나 블로그라도 쓰자라는 생각으로 늦게라도 돌아왔습니다. 그럼 바로 시작하겠습니다.

CQRS

CQRS(Command Query Responsbility Segregation)는 명령과 조회의 책임을 분리하는 패턴입니다. 여기서 Command는 데이터를 생성, 수정, 삭제하는 작업을 의미하고, Query는 데이터를 조회하는 작업을 의미합니다.

일반적인 CRUD 구조에서는 하나의 모델이나 서비스에서 생성, 수정, 삭제, 조회를 함께 처리하는 경우가 많습니다. 하지만 서비스가 커지면 쓰기 작업과 읽기 작업의 요구사항이 달라질 수 있습니다. 예를 들어 주문 생성은 데이터 정합성이 중요하고, 주문 조회는 빠른 응답 속도와 다양한 조회 조건이 중요할 수 있습니다.

CQRS가 필요한 상황

CQRS는 읽기와 쓰기의 요구사항이 크게 다를 때 유용할 수 있습니다.

상황	설명
조회가 매우 많을 때	읽기 전용 모델을 따로 두어 조회 성능을 최적화할 수 있음
쓰기 로직이 복잡할 때	Command 쪽에서 검증과 도메인 규칙을 명확히 관리할 수 있음
조회 화면이 다양할 때	Query 모델을 화면에 맞게 구성할 수 있음
데이터 변경 이력이 중요할 때	이벤트 소싱과 함께 사용할 수 있음

하지만 CQRS는 구조가 단순하지 않습니다. Command와 Query를 분리하면 코드와 데이터 흐름이 늘어나기에 작은 서비스에서는 오히려 복잡도가 커질 수 있습니다.

이벤트 소싱이란?

이벤트 소싱은 현재 상태만 저장하는 것이 아닌 상태가 변경된 이력을 이벤트로 저장하는 방식입니다. 즉, 데이터의 최종 상태가 아닌 그 상태가 만들어진 변경 과정을 기록한다고 볼 수 있습니다.

예를 들어 장바구니 기능에서는 장바구니 생성, 상품 추가, 상품 제거, 배송 정보 입력과 같은 이벤트를 순서대로 저장할 수 있습니다. 이후 이 이벤트들을 다시 적용하면 현재 장바구니 상태를 재구성할 수 있습니다.

CQRS와 이벤트 소싱의 관계

CQRS와 이벤트 소싱은 서로 다른 개념이지만 함께 사용되는 경우가 많습니다.

CQRS는 읽기와 쓰기 책임을 분리하는 패턴이고, 이벤트 소싱은 상태 변경 이력을 이벤트로 저장하는 방식입니다.

구분	역할
CQRS	Command와 Query 분리
이벤트 소싱	상태 변경 이력을 이벤트로 저장
함께 사용할 때	Command와 이벤트를 저장하고, Query 모델은 이벤트를 기반으로 조회용 데이터를 구성

아래 그림은 이벤트 소싱이 CQRS와 함께 사용되는 구조 예시입니다. Command 측에서 발생한 이벤트를 저장하고, 이를 기반으로 조회용 저장소나 외부 시스템을 갱신하는 흐름을 보여줍니다.

https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

서버리스

서버리스는 개발자가 직접 서버를 관리하지 않고 클라우드 제공자가 실행 환경을 관리해주는 방식입니다. 서버가 없다는 의미가 아닌 서버의 생성, 확장, 운영을 개발자가 직접 관리하지 않아도 된다는 의미에 가깝습니다.

대표적으로 AWS Lambda 같은 서비스를 생각할 수 있습니다. 개발자는 특정 이벤트가 발생했을 때 실행될 함수 코드를 작성하고, 서버 프로비저닝이나 확장 관리는 클라우드 플랫폼에 맡길 수 있습니다.

예를 들어 이미지가 업로드되면 썸네일을 생성하고, 결제가 완료되면 알림을 발송하며, 정해진 시간마다 데이터를 정리하는 작업을 실행할 수 있습니다.

서버리스의 장점과 한계

서버리스는 짧고 독립적인 작업을 처리할 때 유용합니다. 하지만 모든 백엔드 애플리케이션을 서버리스로 만드는 것이 항상 좋은 선택은 아닙니다. 실시간 연결이 오래 유지되어야 하거나, 복잡한 상태 관리가 필요한 경우에는 전통적인 서버 구조가 더 적합할 수 있습니다.

장점

서버 관리 부담 감소
사용한 만큼 비용 지불 가능
트래픽에 따라 자동 확장 가능

단점

콜드 스타트가 발생할 수 있음
클라우드 제공자에 대한 의존성이 생길 수 있음
복잡한 장기 실행 작업에는 적합하지 않을 수 있음

CQRS, 이벤트 소싱, 서버리스 비교

구분	핵심 개념	적합한 상황	주의할 점
CORS	읽기와 쓰기 분리	조회와 변경 요구사항이 크게 다를 때	구조가 복잡해질 수 있음
이벤트 소싱	상태 변경 이력을 이벤트로 저장	이력 추적과 감사 로그가 중요할 때	이벤트 설계와 복구 로직이 어려움
서버리스	서버 관리를 클라우드에 위임	이벤트 기반의 짧은 작업 처리	클라우드 의존성과 콜드 스타트 고려 필요

모든 프로젝트에 필요한 구조는 아니다

CQRS, 이벤트 소싱, 서버리스는 모두 유용한 아키텍처 방식이지만 모든 프로젝트에 필요한 것은 아닙니다.

개인 프로젝트나 초기 서비스에서는 일반적인 CRUD 구조와 모놀리식 애플리케이션만으로도 충분한 경우가 많습니다. 오히려 처음부터 복잡한 구조를 도입하면 개발 속도가 느려지고 문제를 해결하기보다 구조 자체를 관리하는 데 더 많은 시간이 들어갈 수 있습니다.

이번편을 마무리로 아키텍처 패턴을 마치도록 하겠습니다.

이제 정말 백엔드 로드맵에 해당하는 부분이 얼마 남지 않았네요. 8챕터 정도 남은 것 같습니다. 다음 시간에는 검색 엔진과 함께 돌아오도록 하겠습니다. 수고하셨습니다.

아키텍처 패턴(1) - 모놀리식, MSA, SOA란 무엇인가?

밈밍민믹 — Sun, 24 May 2026 13:22:27 +0900

안녕하세요. 벌써 일요일이네요. 주말은 정말 빨리 지나가는 것 같아요. 실제로 짧기도 하지만 유독 하루가 더 짧은 느낌? 그래도 다들 월요일날 대체 공휴일고 쉬시니 월요병은 안오실거라고 생각이 드네요! 대신 화요병..?아무튼 아키텐처 패턴에 대한 학습 시작해보도록 하겠습니다.

아키텍처 패턴을 학습하는 이유

지난 시간에는 개발 설계 원칙으로 DRY와 리팩토링에 대해 학습했습니다. 개발 설계 원칙이 클래스, 메서드, 코드 구조를 더 유지보수하기 쉽게 만드는 기준이라면 아키텍처 패턴은 애플리케이션 전체 구조를 어떻게 나눌지 고민하는 기준이라고 볼 수 있습니다.

서비스가 작을 때는 하나의 애플리케이션 안에서 모든 기능을 처리해도 큰 문제가 없을 수 있습니다. 하지만 기능이 많아지고 사용자 수가 늘어나면 배포 방식, 장애 영향 범위, 팀 간 협업 방식까지 함께 고려해야 합니다.

이번 시간에는 대표적인 아키텍처인 모놀리식 애플리케이션, MSA, SOA에 대해 정리해보겠습니다.

아키텍처 패턴이란?

아키텍처 패턴은 애플리케이션의 전체 구조를 설계하는 방식입니다. 단순히 코드를 어떻게 작성할지에 대한 문제가 아닌 기능을 어떤 단위로 나눌지, 각 기능이 어떻게 통신할지, 배포와 운영을 어떻게 할지까지 포함하는 구조적 설계 방식입니다.

즉, 아키텍처 패턴은 서비스의 규모와 목적에 맞게 시스템 구조를 나누기 위한 설계 기준입니다.

모놀리식 애플리케이션

모놀리식 애플리케이션은 전통적인 방식으로 개발된 소프트웨어 애플리케이션 형태를 나타내며, 하나의 애플리케이션 안에 여러 기능이 함께 포함된 구조입니다.

예를 들어 회원, 게시글, 댓글, 주문, 결제 기능이 하나의 프로젝트 안에 들어 있고, 하나의 서버 애플리케이션으로 빌드되고 배포된다면 모놀리식 구조에 가깝습니다.

모놀리식 애플리케이션의 특징

단일 코드베이스
- 애플리케이션의 모든 기능과 모듈이 하나의 코드베이스에서 관리됩니다.
단일 실행 가능한 단위
- 전체 애플리케이션이 하나의 실행 가능한 단위로 패키징되어 배포되며 주로 모노리틱 서버에서 실행됩니다.
서버 사이드 렌더링(SSR)
- 주로 서버 사이드 렌더링 방식으로 사용자 인터페이스를 처리합니다.
개발과 배포의 단순함
- 하나의 코드베이스를 다루기 때문에 개발 및 배포가 상대적으로 간단할 수 있습니다.
쉬운 로컬 개발
- 개발자는 애플리케이션의 전체 기능을 로컬 환경에서 쉽게 테스트할 수 있습니다.
모듈 간 직접 호출
- 서로 다른 모듈 간의 호출이 함수 호출 또는 메소드 호출과 같은 직접적인 방식으로 이루어집니다.

모놀리식은 단순하고 빠르게 시작하기 좋지만 규모가 커질수록 유지보수와 배포 단위가 무거워질 수 있는 구조입니다.

MSA

MSA(Microservice Architecture)는 기존의 모놀리식 아키텍처에서 벗어나 서비스를 작은 단위의 독립적인 서비스로 나누는 아키텍처입니다. 각 서비스는 독립적으로 개발, 배포, 확장될 수 있으며, 보통 HTTP API, 메시지 큐, gRPC 같은 방식으로 서로 통신합니다.

예를 들어 커머스 서비스를 MSA로 나눈다면 회원 서비스, 상품 서비스, 주문 서비스, 결제 서비스, 알림 서비스처럼 도메인 단위로 분리할 수 있습니다.

MSA의 특징

독립적인 서비스 개발 및 배포
- 각 서비스는 독립덕으로 개발 및 배포할 수 있어 특정 기능을 변경할 때 전체 시스템을 재배포할 필요가 없습니다.
비즈니스 도메인 중심 설계
- 애플리케이션을 비즈니스 도메인별로 나누어 설계합니다. 예를 들어 커머스 서비스에서는 상품 서비스, 주문 서비스, 결제 서비스로 나눌 수 있습니다.
다양한 기술 스택 사용 가능
- 각 서비스는 다른 기술 스택(Java, Python, Node.js 등)을 사용할 수 있어 최적화된 기술을 적용할 수 있습니다.
확장성과 장애 격리
- 트래픽이 몰리는 특정 서비스만 별도록 확장할 수 있으며, 한 서비스에 장애가 발생해도 전체 시스템이 중단되지 않습니다.

반면 MSA는 구조가 복잡합니다. 서비스 간 통신, 데이터 정합성, 장애 전파, 로그 추적, 모니터링, 배포 자동화 등 고려해야할 요소가 많습니다. 단순히 서비스를 나누는 것만으로 MSA가 되는 것이 아니라 운영 환경까지 함께 준비되어야 합니다.

즉, MSA는 확장성과 독립 배포에 강점이 존재하지만, 그만큼 운영 복잡도가 크게 증가하는 구조입니다.

SOA

SOA(Service-Oriented Architecture)는 서비스 지향 아키텍처를 의미합니다. 시스템을 여러 서비스 단위로 나누고, 각 서비스가 재샤용 가능한 기능을 제공하도록 설계하는 방식입니다.

SOA도 서비스를 나누다는 점에서는 MSA와 비슷하지만 일반적으로 MSA보다 더 큰 단위의 서비스의 서비스와 중앙화된 통합 구조를 가지는 경우가 많습니다. SOA에서는 여러 서비스가 공통된 규칙이나 중앙 통합 계층을 통해 연결되는 경우가 많고, 기업 내부 시스템 간 연동이나 대규모 업무 시스템에서 자주 언급됩니다.

예를 들어 기업 내부에 인사, 회계, 결제, 고객 관리 시스템이 있고, 각 시스템이 공통 서비스나 통합 계층을 통해 서로 데이터를 주고받는 구조를 생각할 수 있습니다.

즉, SOA는 여러 업무 시스템을 서비스 단위로 나누고, 공통된 방식으로 연결해 재사용성과 통합을 높이는 구조입니다.

모놀로식, MSA, SOA 비교

세 구조는 어떤 것이 무조건 더 좋다고 말하기 어렵습니다. 서비스 규모,팀 규모, 배포 방식, 운영 역량에 따라 적합한 구조가 달라질 수 있습니다.

구분	모놀리식	MSA	SOA
구조	하나의 애플리케이션에 기능이 모여 있음	작은 서비스 단위로 분리	업무 서비스 단위로 분리
배포	전체를 한 번에 배포	서비스별 독립 배포	서비스 또는 통합 단위 배포
장점	개발과 배포가 단순함	독립 확장과 배포에 유리함	시스템 간 통합과 재사용에 유리함
단점	규모가 커지면 복잡해짐	운영 복잡도가 높음	구조가 무거워질 수 있음
적합한 경우	개인 프로젝트, 초기 서비스	대규모 서비스, 팀 분리, 높은 트래픽	기업 내부 시스템, 업무 시스템 통합

작은 프로젝트에서는 어떤 구조가 적합할까?

개인 프로젝트나 초기 서비스에서는 무조건 MSA를 적용하기보다 모놀리식 구조로 시작하는 것이 더 현실적일 수 있습니다. MSA는 서비스별 독립 배포와 확장이라는 장점이 있지만 그만큼 서비스 간 통신, 인증, 로깅, 모니터링, 데이터 정합성 등 고려해야 할 요소가 많습니다. 이러한 운영 기반이 충분하지 않은 상태에서 서비스를 지나치게 많이 나누면 오히려 개발과 유지보수가 어려워질 수 있습니다.

제가 진행한 Spring Boot 기반 프로젝트들도 대부분 하나의 애플리케이션 안에서 회원, 게시글, 댓글, 좋아요 같은 기능을 함께 관리하는 모놀리식 구조에 가깝습니다. 다만 내부 구조까지 모두 섞어두는 것이 아니라 Controller, Service, Repository, Domain, DTO처럼 계층과 역할을 분리하면 모놀리식 구조 안에서도 충분히 유지보수성을 높일 수 있습니다.

중요한 것은 처음부터 복잡한 구조를 선택하는 것이 아니라 현재 서비스 규모에 맞는 구조를 선택하고 이후 필요에 따라 확장 가능한 방향으로 개선하는 것입니다.

이상으로 아키텍처에 대한 학습 1편을 끝내도록 하겠습니다. 다음 시간에는 CQRS, 이벤트 소싱, 서버리스에 대해 학습해보도록 하겠습니다. 수고하셨습니다.