코딩은 마라톤

[Odyssey-X] 알리콘(로켓펀치) 조민희 대표님의 강연을 듣고 나서..

anxi — Thu, 14 May 2026 23:42:23 +0900

강연 후기 전, 잠깐의 일기 - "Odyssey-X를 하기까지의 여정"

2025년 11월 20일, 산업체 근무를 시작하고 모이삼도 운영하다 보니 어느새 2026년 여름이 다가왔다.

초반 3개월은 회사 -> 잠의 굴레에서 지냈다. 3개월이 지나면서 퇴근 후 여유가 생겼지만 여러 이유로 인해 개발과 잠시 멀어졌다. 가장 큰 이유는 AI의 발전이 아니었을까..

2026년 3월, 모이삼 PM 현수가 창업을 하고 싶다 했고, K-pop 라이브 실시간 자막 서비스를 만든다고 했다. 현수 얘기를 듣다가 어디에 홀렸는지 나는 Kaptik을 개발했고 어느새 현수랑 창업에 도전하고 있다. (Kaptik은 아쉽게도 하지 않지만..)

Kaptik & Odyssey-X

4월 초, 현수가 서울시립대에서 Odyssey-X 프로그램이 있다고 해서 지원해 보자 해서 우리는 Kaptik으로 지원했고 최종 선발되었다.

그리고 2주차 세션인 5월 9일, 알리콘 조민희 대표님의 강연을 들었다. 앞으로 작성할 내용은 내가 특히 인상 깊게 들었던 부분 위주로 작성한다.

(1) 이 시대의 MVP는 무엇인가?

대표님은 강연 서두에 "이 시대의 MVP는 무엇인가?" 질문을 하셨다.

질문을 들었을 때, 내가 생각했던 MVP는 '핵심 기능을 가진 프로덕트', '고객이 써볼 수 있는 최소한의 포로덕트' 였다.

대표님은 이 시대의 MVP는 '제품 개발'이 아닌, '사업 검증'이라 하셨다.

내가 생각한 MVP는 검증보다 개발에 집중한 프로덕트였다. 이에 반해, 대표님이 생각하신 MVP는 사업 검증에 집중하셨다.

제품을 오랜 시간 만들어서 출시를 해도, 고객이 쓰지 않으면 이는 실패한 아이템이다.

대표님은 사업 검증을 강조하며 개발 안된 제품도 이미 만들어있는 것처럼 생각하고, 이에 대해 먼저 고객이 구매할지를 검증해야 한다고 말씀하셨다.

특히 AI 시대에 MVP를 만들기는 매우 쉬워서 MVP는 매우 금방 만들 수 있다. 다만 사업 검증은 AI로 하기에는 한계가 있다. 그래서 사업 검증을 하고 제품을 만들어도 전혀 늦지 않다. (Kaptik도 4시간도 안 돼서 MVP는 만들었으니..)

https://blog.alicorn-space.ai/2026/01/silicon-valley-end-of-product-development/

실리콘밸리는 왜 ‘제품 개발의 종말’을 말하는가? : 10년 만의 SF 출장기

일러두기 — “알리콘은 현실 세계의 상업용 공간을 사람대신 운영하는 AI Agent다. 인구 감소 등으로 공간 운영에 어려움을 겪는 전세계 공간 운영 사업자를 돕기 위해, 세계 여러 도시를 방문하

blog.alicorn-space.ai

(2) 좋은 제품의 기준 = Less Is More

대표님은 MVP 얘기를 하시면서 사업 검증 그리고 Less Is More에 대해 말씀하셨다.

Less Is More

"적을수록 더 좋다"는 무슨 의미일까?

아마존을 예를 들어보면, 현재 아마존(Amazon)은 세계 최대 규모의 온라인 쇼핑몰이지만, 시작은 종이책을 온라인으로 판매 및 배송하는 인터넷 서점이었다.

많고 많은 물건 중, 종이책을 선택한 이유는 무엇일까?

대표님이 말씀하시기로는, 종이책은 배송사고가 터지거나, 책을 반품하거나, 수영복이 일부 시즌에 주문량이 급증하는 등 배송에 민감한 상황이 발생하지 않아서 종이책을 선택했을 거라고 하셨다.

결국 아마존의 MVP이자 Less Is More 한 핵심 가치는 "가장 팔기 쉬운 책부터 팔겠다."이다.

정리하자면, Less Is More 한 기능을 가진 MVP는 웹사이트가 될 수도, 앱이 될 수도 있지만 단지 프로덕트의 퀄리티가 아닐 수 있다.

MVP를 프로덕트에 국한하지 않고, 아마존의 예시처럼 본연의 기능을 어떻게 하면 더 쉽게 검증할 수 있을지에 포커싱 하는 게 아닐까.. 생각했다.

(3) 좋은 아이템을 찾기 전에 나 자신을 돌아보자!

대표님은 좋은 사업 아이디어는 1. 내가 좋아하는 것 + 2. 내가 잘하는 것 3. 세상이 원하는 것의 교집합을 찾으라고 하셨다.

대표님의 말씀을 듣고 나니, 좋은 사업 아이템을 발굴하기 위해선 나 자신을 들여다보는 시간이 필요함을 깨달았다.

주변에서 아이템 발굴이 능한 사람(현수)을 보면, 본인의 호불호가 명확하고 잘하는 것과 못하는 것에 대한 판단이 빠른 것 같다. 스스로의 확신이 있어야 그 교집합 내에서 다양한 아이템 후보들을 도출해 낼 수 있을 거라 생각했다.

반면, 나는 아직 내가 무엇을 좋아하고 싫어하는지, 어떤 것에 잘하고 못하지를 정의하지 못했다.

그래서 앞으로는 내가 좋아하고 싫어하는 것을 찾는 시간을 의무적으로 찾으려 한다.

사담이지만, 요새는 회사에서 점심을 빠르게 먹고 산책을 하고 있다. 햇빛을 쬐며 푸릇푸릇한 잎을 보고 자그마한 동물들을 보면서 은근히 힐링되는 것 같다. 2026년 5월, 나는 봄과 산책, 자연을 좋아합니다.

무당벌레와 계란후라이

황금사철나무와 흰머리 많이 자란 꽃

[AWS] 아침 7시, 멀쩡하던 서버가 죽었다? (ECR Lifecycle Policy 장애 회고 및 Discord 알림 구축기)

anxi — Tue, 21 Apr 2026 00:44:15 +0900

발단: 운영 서버 접근 불가

회사에서 일하고 있는데 디코 알림이 울렸다. 알림을 보니 모이삼(https://moisam.kr/) 접근이 되지 않는다는 오류였다..

이전에 cert-manager, nginx-ingress 충돌 났을 때랑 동일 증상이라 SSL 인증서 문제인가 했지만.. AWS ACM을 사용 중이었어서 이 경우는 아니었다.

ECR 이벤트

AWS에서 확인해 보니 이벤트가 금일 쭉 쌓여 있었고, 모든 내용이 다음과 같았다.

service <SERVICE_NAME> was unable to place a task.
Reason: CannotPullContainerError: pull image manifest has been retried 7 time(s):
failed to resolve ref <AWS_ACCOUNT_ID>.dkr.ecr.ap-northeast-2.amazonaws.com/<REPO_NAME>:<TAG>@sha256:<DIGEST>: not found.

서비스 태스크를 사용할 수 없는 문제였고 이는 ECR에서 이미지를 pull 하지 못해 발생했다.

뭐가 문제였을까? 'ECR 수명 주기 정책'

해당 이미지 태그를 확인해보니, 태그를 가진 이미지가 없었다.

이는 비용 절감을 위해 설정해둔 'ECR 수명 주기 정책'이 문제였다. 기존 정책은 최근 10개 이미지만 남기고 모두 제거하는 것이었다..

현재는 하나의 ECR 레포지토리에 운영과 개발 이미지를 태그로만 구분해서 계속 푸시하고 있었다. 운영 배포보다 개발 서버 배포가 훨씬 잦다 보니, 개발 이미지가 계속 쌓이면서 운영 이미지가 '최근 10개' 목록에서 밀려나 기계적으로 삭제되어 버린 것이다.

결국 운영 이미지가 최근 10개 이미지에서 벗어나면서.. ECS 재가동 과정에서 PULL 할 이미지가 없어 장애가 발생했다.

비용 절감을 위해 무심코 만든 정책이 04.20 07시 ~ 04.20 15시 총 8시간 동안 서버가 꺼졌으며.. 8시간 동안 장애가 발생한 사실을 알지 못했다.

해결 1. ECR 수명 주기 정책 수정

1개의 ECR에서 운영, 개발 이미지를 태그로 분리하고 있어서 최근 10개 이미지만 남기는 건 위험할 수 있다.

따라서 규칙 우선순위에 따라 3개로 나눠 정책을 추가했다.

1순위: latest 태그 이미지는 9999개 보관 (절대 삭제 안 함)
2순위: 그 외의 태그 이미지는 30개 유지
3순위: untagged 이미지는 7일 뒤 제거

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "latest 태그는 삭제하지 않음",
      "selection": {
        "tagStatus": "tagged",
        "tagPrefixList": [
          "latest"
        ],
        "countType": "imageCountMoreThan",
        "countNumber": 9999
      },
      "action": {
        "type": "expire"
      }
    },
    {
      "rulePriority": 2,
      "description": "나머지 모든 태그 이미지 최근 30개 유지",
      "selection": {
        "tagStatus": "tagged",
        "tagPatternList": [
          "*"
        ],
        "countType": "imageCountMoreThan",
        "countNumber": 30
      },
      "action": {
        "type": "expire"
      }
    },
    {
      "rulePriority": 3,
      "description": "태그 없는 이미지 7일 후 삭제",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 7
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

최신 배포된 운영 이미지는 latest 태그를 붙이고 latest 태그가 붙어 있으면 절대 삭제하지 않도록 했다. 또한 개발 이미지도 같이 올림으로 모든 태그의 이미지는 30개까지만 남기고 나머지는 제거하도록 했다. 추가로 태그 없는 이미지는 7일 후 삭제하도록 했다.

      - name: Build and push image
        id: build-image
        uses: docker/build-push-action@v6
        with:
          context: .
          file: ./deploy/Dockerfile
          platforms: linux/amd64
          push: true
          tags: |
            ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}
            // 추가
            ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max
          build-args: |
            JAR_FILE=build/libs/*.jar

운영 배포 스크립트에도 latest 태그를 추가해뒀다.

해결 2. AWS Lambda, SNS, CloudWatch를 사용해 Discord 서버 다운/복구 모니터링

현재 모이삼은 서버가 열려있는 경우에만 모니터링 시스템이 구축되어 있다. (에러 발생 시, 디스코드 알림)

다만 이번과 같이 서버가 닫혀 있으면 모니터링할 수 없다. 만약 현수가 알려주지 않았다면 저녁에나 확인할 수 있었겠지..

그래서 모니터링을 할 수 있는 방법을 찾아보던 중, 서버 다운/복구 시에만 알림 보내면 되기 때문에 AWS Lambda를 사용해서 구축할 수 있었다.

디스코드 서버 다운/복구 알림은 다음과 같이 파이프라인을 구축했다.

ALB (HealthyHostCount) ➡️ CloudWatch Alarm ➡️ AWS SNS ➡️ AWS Lambda ➡️ Discord Webhook

(참고로 Lambda 월 100만 건, SNS 월 100만 건, CloudWatch 알람 10개까지 AWS 12개월 프리티어가 끝나도 평생(Always Free) 0원이다!)

파이프라인은 아래와 같이 동작한다.

ALB에서 서버가 닫혀있음을 확인 -> 커스텀한 Cloud Watch Alarm 발생 -> SNS가 구독한 CloudWatch Alarm을 받아서 Lambda로 내용 전달 -> Lambda에서 Discord Webhook으로 알림

2.1. Lambda 디스코드 알리미 생성

디스코드 알리미 함수 생성

import json
import os
import urllib.request
from datetime import datetime, timezone, timedelta

KST = timezone(timedelta(hours=9))


def lambda_handler(event, context):
    webhook_url = os.environ["DISCORD_WEBHOOK_URL"]

    for record in event.get("Records", []):
        message = json.loads(record["Sns"]["Message"])
        payload = build_payload(message)
        send_discord(webhook_url, payload)


def build_payload(message):
    alarm_name = message.get("AlarmName", "Unknown")
    state = message.get("NewStateValue", "Unknown")
    reason = message.get("NewStateReason", "")
    state_change_time = message.get("StateChangeTime", "")

    is_alarm = state == "ALARM"
    title = f"  서버 다운: {alarm_name}" if is_alarm else f"✅ 서버 복구: {alarm_name}"
    color = 0xFF0000 if is_alarm else 0x00FF00

    timestamp = parse_kst(state_change_time)

    return {
        "embeds": [{
            "title": title,
            "color": color,
            "fields": [
                {"name": "상태", "value": state, "inline": True},
                {"name": "발생 시각 (KST)", "value": timestamp, "inline": True},
                {"name": "원인", "value": reason or "-", "inline": False},
            ],
        }]
    }


def parse_kst(iso_string):
    try:
        dt = datetime.fromisoformat(iso_string.replace("Z", "+00:00"))
        return dt.astimezone(KST).strftime("%Y-%m-%d %H:%M:%S")
    except Exception:
        return iso_string


def send_discord(webhook_url, payload):
    data = json.dumps(payload).encode("utf-8")
    req = urllib.request.Request(
        webhook_url,
        data=data,
        headers={
            "Content-Type": "application/json",
            "User-Agent": "AWS-Lambda-Moism/1.0"
        },
    )
    with urllib.request.urlopen(req, timeout=5) as resp:
        return resp.status

람다 함수 작성

AWS Lambda에 함수를 생성한 뒤, 위 코드를 작성한다. Deploy를 해서 적용한다.

※ 위 코드에 DISCORD_WEBHOOK_URL은 Lambda 환경변수에 추가하거나, 문자열로 작성한다.

{
  "Records": [
    {
      "Sns": {
        "Message": "{\"AlarmName\": \"moisam-server-down\", \"NewStateValue\": \"OK\", \"NewStateReason\": \"테스트: Task가 다시 1개 이상으로 복구되었습니다.\", \"StateChangeTime\": \"2026-04-20T22:45:00.000+0000\"}"
      }
    }
  ]
}

테스트는 Test 버튼을 누른 뒤, 위 JSON을 복사하여 Event JSON에 붙여 넣은 뒤 Invoke 하면 디스코드로 알림이 온다.

모이삼 배포봇

2.2. SNS 주제 생성

SNS 주제 생성

SNS 주제는 '표준' 유형으로 생성한다. (표준 유형만 무료)

주제 > 구독 생성

생성한 주제에서 구독을 생성한다. 이때 프로토콜은 'AWS Lambda', 엔드포인트는 2.1에서 만든 Lambda 함수를 선택한다.

2.3. CloudWatch Alarm (경보) 생성

CloudWatch 경보 생성

지표 선택

조건

지표 선택은 다양하게 선택할 수 있지만, 모이삼은 ALB > 대상 그룹(TG) 별 지표 > HealthyHostCount로 선택했다.

HealthyHostCount는 ALB에서 헬스체크 시 결과 기반이라 1 미만이면 서버가 정상적으로 뜨지 않았음을 의미한다. 그래서 조건에 1 미만으로 설정한 뒤, 다음으로 넘어간다.

트리거 설정

알림은 총 2개로 설정했다.

첫 번째 경보 상태는 HealthyHostCount가 1 미만인 오류 상황인 경우, 두 번째 경보 상태는 정상인 상황의 트리거이다.

그리고 다음으로 알림 전송... 에서는 앞서 (2.2)에서 만들어둔 SNS 주제(Topic)를 선택해 주고 경보를 생성하면 된다.

결과 및 회고

실제 알림 내용

컨테이너 개수가 1개가 되어서 더 이상 임계값(1.0) 미만이 아니므로 정상 상태 값의 디스코드 알림이 왔다.

앞으로 빨간 알림이 오지 않는 것을 바라지만.. 이전과는 달리 알림으로 받을 수 있어 빠른 처리가 가능할 것 같다.

이번을 계기로 서버가 닫힌 경우에도 모니터링이 필요함을 느꼈다.

앞으로 애플리케이션 오류, Slow API 등의 로그를 위와 같이 설정해서 비용 0원으로 AWS 모니터링 시스템을 구축해 봐야겠다.

[K3s] cert-manager 인증서 갱신 실패(ERR_CERT_DATE_INVALID) 해결해보자

anxi — Tue, 24 Mar 2026 01:29:36 +0900

문제 발생

지난주 금요일 (3/20), 친구들과 모임 이후 모이삼 어드민 페이지에서 모임 통계를 확인하려 했다.

ERR_CERT_DATE_INVALID

잘 작동하던 어드민 사이트 (백엔드 API, Thymeleaf로 구현된 SSR)가 갑자기 인증서 만료가 뜨며 먹통이 되었다..

클라이언트(`moisam.kr`)는 Vercel로 돌리고 있어 인증서 문제는 없었지만, 클라이언트 단에서 백엔드 API를 호출할 때 SSL 프로토콜 오류가 발생하여 비정상적인 리다이렉트 라우팅이 발생하고 있었다. (`moisam.kr` 로 접속 시, `moisam.kr/history` 로 이동)

/history는 가입 유저만 사용할 수 있는 기능이었고 인증서 만료 이전에 로그인 한 유저는 사용 가능했지만, 비로그인 유저는 접근조차 불가능했다.

️‍♂️ 원인 파악

1. Let's Encrypt 인증서 확인

모이삼은 K3s의 cert-manager를 사용하여 SSL/TLS 인증서를 자동으로 프로비저닝하고 관리하고 있다. cert-manager는 만료 30일 전부터 자체적으로 갱신을 시도한다. 작년 9월부터 초기 설정 이후, 인증서에 대한 문제는 없었는데 갑자기 장애가 났다는 것은 지난 30일 동안 cert-manager의 백그라운드 자동 갱신이 무언가에 막혀 계속 실패하고 있었음을 시사한다.

2. 쿠버네티스 상태 확인

$ kubectl get certificate -n prod
NAME       READY   SECRET     AGE
prod-tls   False   prod-tls   247d

운영 환경의 인증서를 확인해보니 `READY=False` 상태였다. cert-manager에서 자동 갱신이 되지 않고 있었다.

인증서 발급에 문제가 있음을 확인하여 Challenge 상태를 확인해 보았다.

$ kubectl describe challenge -n prod
...
Warning  PresentError  Error presenting challenge: Internal error occurred: 
failed calling webhook "validate.nginx.ingress.kubernetes.io": failed to call webhook: 
Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s": 
service "ingress-nginx-controller-admission" not found

kubectl describe challenge -n prod 명령어를 통해 상세 내역(Events)을 확인해 보니 에러 로그가 존재했다.

원인: ingress-nginx 불완전 삭제로 인한 잔여 데이터 존재

??? ingress-nginx ???

모이삼은 K3s에서 기본으로 제공하는 Traefik을 Ingress Controller로 사용하고 있었다. 하지만 이전에 ClientIP 로깅 과정에 `ingress-nginx`를 테스트 목적으로 설치한 적이 있었는데, 이때 설치된 `ingress-nginx`가 불완전 삭제되어 잔여 리소스가 남아있던 것이 문제였다.

️ 해결 과정

해결 방법은 K3s에 남아있는 불필요한 ValidatingWebhookConfiguration를 지워주면 된다.

1. ValidatingWebhookConfiguration 관련 잔여 데이터 조회

$ kubectl get validatingwebhookconfigurations

이 과정을 통해 Nginx와 관련된 잔여 데이터(`ingress-nginx-admission`)를 찾을 수 있다.

2. 잔여 데이터 삭제

$ kubectl delete validatingwebhookconfiguration ingress-nginx-admission

3. 결과

잔여 데이터를 삭제하자마자 cert-manager는 즉각 인증서를 새롭게 발급했고, 사이트도 정상적으로 접속 가능했다.

결론

쿠버네티스에서 어떠한 도구를 사용하든 제거는 확실하게 해야 한다. (쿠버네티스에 국한된 얘기는 아닌 듯..)
cert-manager의 인증서 갱신은 뒷단에서 조용히 실패하기 때문에, 자동으로 관리해 준다 하더라도 READY 상태나 만료일에 대한 모니터링이 필수임을 깨달았다. (참고로 4월부터 AWS ACM을 사용해서 인증서를 발급받을 예정..)

Jar를 다이어트 시켜보자 (Layered Jar)

anxi — Tue, 10 Mar 2026 23:21:24 +0900

요새 AWS로 마이그레이션을 진행하고 있다.

마이그레이션을 진행하기 앞서, 배포 과정에서의 문제점을 살펴보고 개선할 수 있는 부분은 개선하고자 했다.

40초나 걸린다고?!

서버 로그를 살피고 있던 도중, 어느샌가 스프링 애플리케이션 초기 실행 시간이 40초에 근접했다.

사실 나는 Github Actions가 돌아가는 것이 배포의 시작이자 끝이라 생각했다.

하지만 애플리케이션 초기 실행 시간, 그리고 배포된 Docker Image를 Pull 하는 과정에 대해선 간과하고 있었다.

초기 실행 시간을 줄일 순 없을까?
배포 과정에서 도커 이미지를 만들고 push, pull 과정에서 개선할 수 없을까?

그래서 나는 위 두 가지의 고민을 해결하고자 찾던 도중 "Layered Jar"를 알게 되었다.

Layered Jar

흔히 `./gradlew bulid`를 통해 만들어진 Jar은 "Fat Jar" 라고 한다.

Fat Jar

사진에서 보이는 server-0.0.1-SNAPSHOT.jar 내부에는 사용된 모든 라이브러리와 내가 짠 코드가 몽땅 들어있다.

그래서 보통은 배포할 때 `java -jar app.jar` 명령 한 줄로 어디서든 실행할 수 있다.

다만 소스 코드 한 줄만 수정해도 100MB가 넘는 Jar 파일이 새롭게 만들어진다.

"Layered Jar" 은 도커 이미지 생성 개선을 위해 Spring Boot 2.3.0에 도입된 것으로, Jar 내부에 'layers.idx'라는 인덱스 파일이 존재한다.

'layers.idx'는 의미 그대로 Jar 내부 파일이 어떤 레이어에 속하는지를 정의하는 지도 역할을 한다.

Spring Boot 는 다음 4가지 레이어를 기본으로 제공한다.

Layered Jar

dependencies: 버전에 SNAPSHOT이 포함되지 않은 일반 외부 라이브러리. (가장 안 변함)
spring-boot-loader: Jar를 실행하기 위한 로더 클래스들.
snapshot-dependencies: 버전에 SNAPSHOT이 포함된, 자주 바뀔 수 있는 내부 라이브러리.
application: 우리가 작성한 소스 코드(. class)와 리소스 파일들. (가장 자주 변함)

Fat Jar, Layered Jar를 비교하는 것만으론 Layered Jar의 장점을 이해하기 어렵다.

왜냐하면 Layered Jar는 Dockerfile로 빌드할 수 있는 최적화된 Docker 이미지를 더 쉽게 생성하기 위해 나온 것이기 때문이다.

Docker 의 이미지 구축 방식

Docker Image Layer

도커 이미지는 여러 개의 레이어를 가진다.

사진처럼 DockerFile에 작성된 명령어마다 레이어를 가지며 순서대로 차곡차곡 쌓인다.

또한 새로운 이미지가 만들어졌을 때의 레이어의 변경점이 없다면, 새 이미지의 레이어를 덮어 씌우는 것이 아닌 레이어 캐시를 사용해 레이어를 재사용한다. 레이어의 재사용은 빌드 속도를 향상할 수 있다.

따라서 Layered Jar의 4가지 레이어를 도커 레이어에 각각 배치한다. 변경될 가능성이 거의 없는 레이어(dependencies, spring-boot-loader ..)들은 도커 캐시를 통해 재사용하고, 매번 수정되는 application 레이어만 교체하는 식으로 개선할 수 있다.

결과적으로 Fat Jar 방식처럼 큰 덩어리를 전부 바꿔치기 하는 대신, 코드가 변경된 일부만 쏙 골라 배포할 수 있게 된다.

Layered Jar를 사용해서 개선해보자

FROM eclipse-temurin:21-jre-alpine AS builder
WORKDIR /app
ARG JAR_FILE=./*.jar
COPY ${JAR_FILE} app.jar
RUN java -Djarmode=layertools -jar app.jar extract

FROM eclipse-temurin:21-jre-alpine
WORKDIR /app

COPY --from=builder /app/dependencies/ ./
COPY --from=builder /app/spring-boot-loader/ ./
COPY --from=builder /app/snapshot-dependencies/ ./
COPY --from=builder /app/application/ ./

ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"]

멀티 스테이지로 DockerFile을 구성하여 builder 스테이지에서 추출한 레이어를 runner 스테이지에서 COPY 하여 사용하도록 했다.

builder 스테이지: `java -Djarmode=layertools -jar` 명령어로 JAR에서 레이어를 추출(extract)하는 과정.
runner 스테이지: 추출된 4개의 레이어를 순서대로 COPY 하는 과정.

❗️COPY 과정이 매우 중요❗️
도커 레이어는 특정 레이어에서 변경 사항이 생길 경우, 이후 모든 레이어를 전부 무효화한다.
따라서 COPY 시, 변경 사항이 가장 낮은 dependencies 순으로 진행해야 한다.

❗️Spring Boot 3.2 이상 사용 중이라면?❗️
RUN java -Djarmode=layertools -jar app.jar extract 이 Deprecated 되었다고 한다.
따라서 다음과 같이 변경한다.
RUN java -Djarmode=tools -jar app.jar extract --layers --launcher
(바꾸지 않아도 동작하지만,, 혹시 모르니 변경하기를 바란다.)

이렇게 구성한 뒤, 두 번째 배포부터 레이어의 캐싱을 확인할 수 있다.

dependencies, spring-boot-loader 가 캐싱 됨을 확인할 수 있다.

기존 Jar 방식의 Docker Image Layer

Layered Jar의 Docker Image Layer

개선 결과

Gemini야 고마워

좌측 그래프: 이미지 Pull 성능 비교 (PULL 할 경우)
- 내용: 쿠버네티스 노드가 이미지를 다운로드하는 데 걸린 시간
- 해석: 기존 Jar 방식은 전체를 다운로드해야 해서 4초가 걸렸지만, Layered Jar 방식은 변경된 소스(application) 레이어만 다운로드하므로 1초 만에 완료되었다. 현재는 도커 이미지가 크지 않아 엄청 크게 와닿지는 않지만, 도커 이미지가 커진다면 75%의 시간 단축은 꽤나 유의미한 개선일 것 같다.
우측 그래프: 초기 실행 성능 비교 (초기 실행 시간)
- 내용: 스프링 애플리케이션이 시작되어 서비스 준비가 되기까지 걸린 시간
- 해석: 기존 Jar 방식의 40초에 비해, Layered Jar 방식은 20초로 단축되었다. 기존 Jar 방식은 압축이 되어 있어 압축 해제하고 클래스 로딩하는데 시간이 소요되지만, Layered Jar 방식은 DockerFile에서 extract로 압축을 풀었기 때문에 곧장 클래스 로딩을 하여 시간이 단축된 것으로 확인된다.

결론

Layered Jar 적용 후, Github Actions 빌드가 끝난 시점부터 실제 서비스가 가동되기까지의 소요 시간을 44초에서 21초로 약 52% 단축했다. 무중단 배포가 되어 있지 않을 경우, Layered Jar을 적용하면 다운타임을 줄일 수 있으므로 용이할 것 같다. 다음에는 애플리케이션 클래스 데이터 공유(Application Class-Data Sharing)를 활용해서 시간을 더 낮출 수 있을지도 확인해 봐야겠다. Spring AOT라는 것도 있던데.. 이것도 되면 확인해 봐야겠다.

출처

[모이삼] AWS 1000달러 크레딧을 받았다. (AWS Startups)

anxi — Sun, 22 Feb 2026 20:55:40 +0900

모이삼의 서버 비용은 어떻게 처리해?

모이삼 : https://moisam.kr

나는 작년 9월부터 "모이삼"이라는 웹 서비스를 운영하고 있다.

큐시즘(한국대학생IT경영학회)에서 시작된 모이삼은 감사하게도 네이버 클라우드에서 서버 비용을 지원해 주셨다. 그 결과 서버비에 구애받지 않고 넉넉히 사용할 수 있었다.

네이버 클라우드에서 받은 크레딧

다만 달에 10만원 가까이 나가는 서버비는 올해 3월이면 고갈되었고, 서버비를 충당하기 위해 방법을 찾던 도중 "AWS Startups 크레딧 지원"을 알게 되었다.

결론부터 말하면, 우리는 AWS Startup 창업자(Founders) 티어를 신청하였고 승인되어 1,000 달러를 받았다.

AWS에서 큰 금액을 지원하는 만큼, 쉽게 승인되는 것은 아니라서 신청부터 반려된 경험과 승인까지 이뤄낸 과정을 후술 하고자 한다.

(AWS Startup Credit을 알려준 상호형에게 다시 한번 감사 인사 드리며, 상호형의 블로그 글로 많은 도움을 받았습니다!!)

AWS Activate 프로그램이란?

AWS Activate 프로그램은 AWS에서 스타트업을 위해 지원하는 프로그램이다.

AWS Activate 멤버가 되면 클라우드 크레딧, 기술 지원 및 비즈니스 멘토십을 제공받을 수 있다.

AWS Activate 크레딧

AWS Activate 크레딧은 "Activate Founders"와 "Activate Portfolio"가 있다. Portfolio는 최대 10만 달러까지 받을 수 있으나, Activate 제공업체가 있어야 한다. 모이삼은 Activate 제공업체가 없기 때문에 Activate Founders를 신청했다.

AWS Activate 크레딧의 자격 요건은 다음과 같다. (출처: Ask AWS Startups)

기업 단계: 부트스트랩(자체 자금 조달), 자기 자본 조달, 그리고 시리즈 A 단계 이하의 투자를 유치한 스타트업까지 신청 가능합니다.
설립 연도: 기업 설립일로부터 10년 이내인 스타트업이어야 합니다.
온라인 존재 여부: 스타트업의 활성화된 웹사이트 또는 공식적인 퍼블릭 프로필(링크드인 등)이 반드시 있어야 합니다.
이메일 계정: AWS Activate 프로필과 크레딧 신청 시, 스타트업의 자체 도메인과 일치하는 비즈니스 이메일 주소를 사용해야 합니다. (예: name@yourstartup.com)
지역 제한: AWS 중국 리전에서 서비스를 구축 중인 스타트업은 일반 AWS Activate 프로그램 대상에서 제외됩니다. (중국 리전은 별도의 전용 프로그램이 운영됩니다.)

신청 절차

AWS Activate Credit 신청 절차를 요약하면 다음과 같다. (출처: Ask AWS Startups)

AWS Builder ID 생성: 먼저 AWS 서비스 통합 관리를 위한 AWS Builder ID를 만드세요.
패키지 선택: 스타트업의 상황에 맞춰 다음 두 가지 중 하나를 선택하세요.
1. Founders Package(창업자 패키지): 외부 투자 없이 자력으로 운영 중인(Self-funded) 스타트업용
2. Portfolio Package(포트폴리오 패키지): 엑셀러레이터나 VC 등 파트너사로부터 투자 및 지원을 받는(Provider-backed) 스타트업용
AWS Activate 프로필 작성: 가입 후 본인의 AWS Activate 프로필 정보를 모두 입력하여 완료하세요.
상세 정보 제공: 비즈니스 세부 정보, 제품 설명, 현재 펀딩 상태(투자 단계) 등 스타트업에 관한 정확한 정보를 입력하세요.

1️⃣ AWS Builder ID 생성

https://aws.amazon.com/startups

위 사이트에 접속하여 회원가입한다. 이 계정은 AWS 계정과는 다른 Builder 계정이다.

2️⃣ 크레딧 패키지 선택

로그인 후, AWS 크레딧 탭에 진입 > "지금 신청" 클릭한다.

팀에 맞는 크레딧 패키지를 선택한다. 모이삼은 창립자 티어 (Founder)를 선택했다.

3️⃣ 프로필 작성

내 프로필

신청자의 프로필을 작성한다.

나는 모이삼의 CTO를 맡고 있다 나를 최대한 PR 하기 위해 LinkedIn 프로필도 넣어줬다.

이외 항목은 본인이 원하는 대로 기입하면 된다.

팀 프로필

아래로 스크롤하면 스타트업 프로필을 작성할 수 있다.

웹사이트 URL을 입력했고, 공개 프로필로는 PM 현수가 Product Hunt에 모이삼을 올렸어서 이를 넣어줬다. 서비스를 PR 하기 위해 공개 프로필은 꼭 넣어주는 게 좋을 것 같다. (디스콰이엇, 링크드인 등등)

4️⃣ 제품 및 자금 조달 설명 작성

제품 설명은 서비스에 맞게 작성하면 된다. 여기서 가장 중요한 부분은 서비스 소개글이다. 250자까지만 작성 가능하여 최대한 옹골지게 작성해야 한다.

모이삼은 "서비스 소개 + MAU 성장률 + 발전 가능성" 에 대해 작성했다.

이후 자금 조달 설명을 작성해야 하는데 모이삼은 투자를 받지 않아 "자금 조달 없음"으로 선택하고 넘겼다.

5️⃣ AWS 계정 연결 + 신청서 제출

AWS 계정은 크레딧 받을 계정으로 연결하면 된다. 연결 후 신청서 제출 버튼을 클릭하여 신청서를 제출한다.

6️⃣ 신청 완료

신청 메일

AWS Startups

신청이 완료되면 회사 이메일로 확인 메일이 발송되며, AWS Startups 홈페이지에서도 상태를 확인할 수 있다. (페이지 내 '신청서 제출' 항목에 체크 표시가 되어 있다.)

❌ 첫 번째 신청: 반려 (AWS 이메일과 도메인 불일치)

하루 만에 결과가 나왔다. 반려되었다.

그 이유는 AWS 계정과 서비스 도메인이 일치하지 않기 때문이었다.

모이삼 AWS 계정은 구글 메일(@gmail.com)이어서 이를 도메인(@moisam.kr)으로 바꿔야 했다.

도메인으로 메일을 만들기 위해서는 Google Workspace나 Naver Works 등을 사용하여 비즈니스 메일을 만들어야 한다.

우리는 Naver Works로 비즈니스 메일을 만들었고, AWS 계정을 비즈니스 메일로 변경하여 재신청하였다.

(AWS 계정 변경 방법은 해당 문서를 참고했다.)

❌ 두 번째 신청: 반려 (서비스 문제)

비즈니스 메일로 바꾸고도 반려되었다. 이미 위 사항들은 수정하고 나서 신청했었는데..

그래서 나는 AWS Startups 문의를 통해 우리의 상황이 자격 요건을 충족함을 나타냈고, 어떤 이유로 반려되었는지를 문의했다.

문의를 기다리던 도중, 메일이 도착했다.

파이널 리뷰 진행 중이며, 상태가 바뀌면 이메일로 연락을 준다는 것이다.

이때부터 될 거 같은 느낌이 솔솔 들었다.

✅ 두 번째 신청: 반려 (서비스 문제) -> 승인

파이널 리뷰 진행 중이라는 메일을 받은 후, 다음 날에 승인 결과를 받았다!

서버비에 대한 부담이 있었는데 메일을 받고 근심 걱정 다 날아갔다

‍↕️ 마무리

드디어 모이삼도 AWS 크레딧(1,000달러)을 사용할 수 있게 되었다!

네이버 클라우드를 떠나 AWS로 마이그레이션하면서 아키텍처도 개편할 계획인데 ECS나 ALB 등을 사용하여 개편할 생각에 설렌다.

지금까지 큰 힘이 되어준 네이버 클라우드, 그리고 기회를 주신 AWS 모두 감사합니다 ☺️

[모이삼] 한 달 만에 MAU 300% 성장 (feat. 회고)

anxi — Sun, 28 Dec 2025 15:55:23 +0900

결론

2025.12.28 기준

Thanks to. 현수, 현비 최고의 팀원들과 같이 할 수 있어 영광이었습니다 ‍↕️

최고의 사람들이 만든 서비스를 사용하고 싶다면? 아래 링크를 통해 마음껏 사용해 보세요!

모이삼 바로가기: https://moisam.kr

피드백 남기기: https://forms.gle/3GDyQcZezyMf6fi2A

발단 : 모이삼 이대로 괜찮은가?

큐시즘이 끝나고도 모이삼은 꾸준히 발전했다. SPOT에서 MOISAM으로 서비스 명 변경, UIUX 개선, 서버 장애 대응 등 각 파트에서 무던히 노력해 왔다. 다만, 다들 취업 시기가 다가왔고 취업 준비를 하면서 모이삼에 쓸 수 있는 리소스가 부족했다. 또한 리소스가 있어도 큐시즘이라는 동기부여가 사라진 이상, 팀의 활력을 불어줄 무언가 필요했다.

10월 중순, PM 현수와 1시간 넘게 이야기를 나눴다. 모이삼의 활력을 줄 수 있는 건 결국 "사용자"였다.

모이삼은 "중간지점 찾기"의 니즈가 명확해서 사용자에게 홍보만 된다면 충분히 많이 쓸 서비스라 생각했다. 그래서 우리는 2025년 남은 기간 '마케팅에 집중하자'는 목표를 잡고 나아가기 시작한다.

10월 MAU

전개 1 : GA (Google Analytics) 공부

고객을 끌어오는 구글 애널리틱스 4

본격적인 마케팅을 시작하기 전에, 우리는 GA 공부를 먼저 진행했다.

현수랑 나는 매주 하나의 챕터씩 읽고 본 회의 때 서로 가르쳐주고, 모이삼 데이터를 토대로 이야기를 나눴다.

획득, 참여도, 이벤트 등 생소한 개념도 알 수 있게 되었고, 특히 모이삼의 데이터에 적용하면서 추후 마케팅을 어떻게 해야 할지를 정할 수 있었다.

예를 들면, GA를 통해서 우리는 인스타그램 마케팅을 잠시 멈췄다. 블로그와 인스타그램에서 유입된 사용자 수가 비슷해도, 블로그에서 유입된 사용자는 대략 1분 정도 서비스에 참여했지만 인스타그램에서 유입된 사용자는 3초 이내로 이탈이 빨랐다. 그래서 우리는 인스타그램 게시물 작성 대신, 블로그 작성에 힘을 실었다.

전개 2 : 커뮤니티(에브리타임, OKKY..) 홍보

에브리타임

모이삼은 중간지점 찾기 서비스인 만큼, 동네 친구들 보단 거리의 편차가 큰 사용자들이 사용하기 적합하다. 그래서 대학생이 타겟층인데 에브리타임에 홍보를 한 적이 없었다. 그래서 12월 연말인 만큼, 모임이 많을 거라 판단하여 에브리타임에 글을 올렸다.

특히 여기서 현수가 게시글 제목에 업로드할 대학교를 넣어 작성하자고 했다. 많은 홍보 게시글 속에서 사소한 터치가 개인적으로 참 좋았다.

현수의 Okky 홍보

현수는 일회성인 에브리타임 말고도 다양한 채널을 통해 장기적으로 홍보하기를 원했다. 현수는 여러 플랫폼(OKKY, 독취사 등)에서 적극적으로 홍보를 진행했다.

디시인사이드

여담이지만, 나는 디시인사이드 커뮤니티에 올렸고 게시글과 댓글 수위가 세서 금방 접었다

전개 3 : 디스콰이엇, 유아이볼에 서비스 공유

디스콰이엇

유아이볼

디스콰이엇에 우리의 서비스를 투고했다.

디스콰이엇은 투고 이후, 이 주의 프로덕트에 2 연속 선정됐다.

기회가 된다면 업보트 한 번씩 부탁드립니다 https://disquiet.io/product/%EB%AA%A8%EC%9D%B4%EC%82%BC

모이삼 | Disquiet*

최고의 중간지점 찾기 서비스

disquiet.io

유아이볼에서는 모이삼 서비스를 좋게 봐주셔서 자체 플랫폼, 인스타그램, 브런치 게시글을 통해 모이삼 사용 후기를 남겨주셨다.

좋은 부분뿐만 아니라, 아쉬운 부분도 함께 제시해 주셔서 참 감사했다.

유아이볼 : https://uibowl.io/website/%EB%AA%A8%EC%9D%B4%EC%82%BC

https://uibowl.io/

국내 UI/UX 패턴을 담은 공간, 유아이볼

uibowl.io

전개 4 : 디자인 Threads 운영

@yogurtzzang

팔로우 부탁드려요 https://www.threads.com/@yogurtzzang

12월 초중순부터 모이삼 디자이너인 현비가 마케팅에 참여했다. 현비는 개인 스레드에서 디자인, IT 계열 사람들에게 모이삼을 홍보하고 있다. 스레드에서는 현비의 디자인 이야기나 모이삼 홍보글 등이 주기적으로 업로드될 예정이다.

위기 : 마케팅의 성과를 확인하고 싶어!

위의 과정을 토대로 사용자의 유입은 꾸준히 성장했다. 현수, 현비는 GA를, 나는 DB로 생성된 모임과 참여자 수 등을 확인했다. 그러나 GA에서 UTM으로 가져온 데이터를 확인하는 건 꽤 복잡했다. 그래서 나는 어드민 페이지를 만들어 현수, 현비도 모임 정보를 쉽게 확인할 수 있도록 했다.

모이삼 어드민 페이지

어드민 페이지를 만들면서 어디서나 확인할 수 있다는 점이 좋았다.

또한 모이삼의 상세 경로를 가져올 때, 외부 API를 사용하다 보니 경로를 못 가져오는 경우도 더러 있었는데, 이때 어드민 페이지에서 확인 후 빠르게 대처할 수 있게 되었다.

절정 : MAU 300% 증가

첫 사용자(신규 방문자)

세션 수

신규 방문자와 세션 수는 에브리타임 > okky > 네이버 블로그 > 디스콰이엇 > 구글 검색 순이다.
google / organic 이 꾸준히 늘어나고 있는데, 이는 '중간지점 찾기', '모이삼' 을 검색해서 들어온 사람이 증가했다는 점이고, 마케팅을 통해 SEO 활성화된 것이 가장 긍정적인 부분이라 생각한다.

다음은 세션 수와 첫 사용자(신규 방문자)를 비교한 서비스 참여 정도의 표와 해석이다.

유입 채널	첫 사용자 수 (A)	참여 세션 수 (B)	유입당 참여율 (B/A)
everytime.kr	123명	92건	0.75
okky.kr	70명	57건	0.81
m.blog.naver.com	67명	69건	1.03
disquiet.io	40명	35건	0.88
google	24명	26건	1.08

구글, 네이버 블로그의 참여율이 높다: 유입된 사람 수(67명, 24명) 보다 참여 세션 수(69건, 26건)가 더 많다. 이는 신규 사용자가 이탈하지 않고 재방문했음을 알 수 있다. 특히 네이버 블로그의 GA 참여율은 95.83%로 가장 높음을 알 수 있다.
에브리타임의 유입량이 높다: 가장 많은 123명의 신규 사용자를 데려왔지만, 참여율(0.75)은 타 채널 대비 낮다. 이는 호기심에 들어온 유저는 많으나, 실제 서비스 사용까지 전환이 이뤄지지는 않음을 시사한다. 개강 시즌에 단기적인 유입을 늘리는데 도움이 될 수 있을 것으로 보인다.

네이버에도 최상단에 노출

또한 마케팅 이전에는 네이버에 모이삼 검색 시, 우리 서비스가 노출되지 않았다. 하지만 마케팅 이후, 네이버 검색 시 최상단에 노출됨으로써 네이버에서 유입을 기대할 수 있다. 다만 아쉬운 점은 '중간지점 찾기'를 통한 노출은 이뤄지지 않아 좀 더 SEO를 신경 써야 할 것 같다.

결말 : 모이삼은 잘 된다. 그리고 잘 될 것이다.

마케팅을 하면서 가장 우선인 역량은 바로 '자신감'이다.

"더 개선하고 나중에..."라는 생각은 마케팅 시기를 늦출 뿐이다.

사용자는 99개의 단점이 있더라도, 자신에게 필요한 단 1개의 장점만 있더라도 기꺼이 사용할 것이라 생각한다.

따라서 마케팅을 하는 입장에서 단점에 매몰되어 소극적인 홍보가 아닌, 장점을 부각하여 적극적인 홍보가 마케팅의 시작이라는 걸 깨달았다.

MVP를 만들었다면, 일단 뛰어드는 게 어떨까?!

같이 읽으면 좋은 글

https://blog.naver.com/nanhyunsoo00/224123738686

[모이삼 마케팅 - 1] 광고 없이 한달 만에 사이드프로젝트 MAU 300% 성장

서비스 MAU 300% 성장 다시 한 번 최고의 중간지점 찾기 서비스 - 모이삼 관련 글로 찾아오게 되었다. ...

blog.naver.com

https://blog.naver.com/nanhyunsoo00/224123904644

[모이삼 마케팅 - 2] 마케팅 예산 0원. 우리가 선택한 유입 채널 4가지

이번 편에는 지난 편의 인트로에 이어 실제로 어떤 마케팅 채널을 선택했고, 어떤 효과를 보았는 지 소개하...

blog.naver.com

[Network] Loopback 루프백 (127.0.0.1, localhost)

anxi — Sat, 13 Dec 2025 20:00:48 +0900

Loopback 루프백이란?

루프백은 Loop + Back, 단어 그대로 되돌려 보내는 행위를 의미한다.

이걸 네트워크에 적용해 보면, 데이터를 자기 자신에게 다시 전송하는 메커니즘을 뜻한다.

forloop의 loop와 동일

루프백 주소란?

127.0.0.0에서 시작하여 127.255.255.255로 끝나는 예약된 IP 주소 범위를 말한다.

IPv4 루프백 주소

IPv4 범위: 127.0.0.0/8
- 브로드캐스트 주소: 127.255.255.255
일반적으로 사용되는 루프백 주소: 127.0.0.1 (로컬호스트, localhost로 알려져 있다.)

IPv6 루프백 주소

IPv6 범위: ::1

활용 예시: localhost:8080 + 동작 방식

SpringBoot를 통해 로컬에서 웹 서버를 띄우고 테스트하기 위해서 항상 접속하는 주소가 있다.

Swagger를 사용할 때도 localhost로 접속한다.

개발을 조금이라도 해봤다면 쉽게 이해할 수 있다. 바로 'localhost:8080'이다.

Nestjs, Spring Boot와 같은 프레임워크를 통해 로컬에서 웹 서버를 띄워 Swagger로 API 테스트할 때 우리는 항상 localhost:8080에 접속한다.

루프백 주소를 사용해 외부 네트워크와 연결 없이 로컬 컴퓨터가 스스로에게 요청하고 응답을 받기 위해 루프백 메커니즘을 이용한다.

루프백이 localhost:8080에서 작동하는 방식 (OSI 7 Layer)

Layer	계층	루프백 통신 과정
7	응용 (Application)	웹 브라우저(클라이언트)가 HTTP 요청 생성
6	표현 (Presentation)	데이터가 필요한 형식으로 인코딩
5	세션 (Session)	통신 세션 시작
4	전송 (Transport)	브라우저 프로세스가 목적지 포트(8080)를 지정, 데이터는 TCP 세그먼트로 캡슐화
3	네트워크 (Network)	IP 계층이 목적지 IP 주소 127.0.0.1을 확인 후 루프백 주소임을 인지하여 라우팅 테이블의 루프백 인터페이스로 경로 지정 루프백 인터페이스: 루프백 통신을 가능하게 하는 운영체제 내의 가상 네트워크 인터페이스
2	데이터 링크 (Data Link)	패킷이 외부 LAN 카드로 전달되지 않음으로 사용되지 않음
1	물리 (Physical)	물리적인 케이블을 통해 외부로 전달하지 않음

참고

https://www.geeksforgeeks.org/computer-networks/what-is-a-loopback-address/

[Security] 샌드박스(Sandbox)

anxi — Thu, 27 Nov 2025 20:51:29 +0900

내가 알고 있는 샌드박스..

나만 몰랐던 샌드박스...

최근에 샌드박스(Sandbox)라는 단어를 듣게 되었다.

내가 아는 샌드박스는 도티가 운영한다는 MCN 회사인데.. 알고 보니 보안에서도 샌드박스라는 게 쓰인다고 한다.

샌드박스를 알아보니 꽤 재밌어서 글을 작성하게 되었다.

샌드박스 (Sandbox)

놀이터

샌드박스는 단어 그대로, 모래 상자, 모래로 가득 채워진 공간을 의미한다.

모래로 가득 채워진 공간을 상상해 보자.

나 혼자 그 공간에 있다면, 땅을 온종일 파서 지하수를 구하거나, 개미집과 같이 나만의 공간을 만드는 등,

남 눈치 안 보고 상상 조차 하지 못한 일을 할 거 같다.

보안에서의 샌드박스도 마찬가지다.

모래뿐인 공간에서 개발자가 상상력을 펼치며 놀 수 있는 곳.

그래서 모래뿐인 공간에서 보안에서의 공간으로 확장되었다.

위 내용을 토대로 샌드박스가 무엇인지 어느 정도 파악할 수 있을 것이다.

보안에서의 샌드박스란

"다른 프로그램에 영향을 끼치지 않고 (외부 자원 접근 X) 프로그램을 안전하게 실행할 수 있는 격리된 환경"

을 의미한다.

예시 : iOS APP

가장 흔히 접할 수 있는 샌드박스의 예시가 바로 iOS APP이다.

보통 아이폰의 장점을 이야기할 때, 가장 많이 나오는 게 보안에 관한 내용이다. 아이폰은 해킹하기 어렵다는 말들이 많았고, 샌드박스를 알기 전에는 그 이유에 대해 알지 못했다.

iphone Sandbox

사진에서와 같이, 아이폰의 모든 앱들은 각자의 샌드박스를 갖는다. (App Sandbox)

샌드박스 내부에 앱에 대한 파일, 하드웨어(카메라, 마이크), 네트워크 등 여러 리소스를 격리하여 저장한다. 따라서 샌드박스의 외부의 데이터를 접근할 수 없게 된다.

만약 하나의 앱에서 문제가 발생하더라도, 샌드박스 외부에선 시스템 리소스와 사용자 데이터에 접근할 수 없어 보호할 수 있게 된다.

이 밖에도, 알고리즘 문제 풀 수 있는 사이트로 유명한 백준도 샌드박스에서 채점을 했다고 한다.

https://www.slideshare.net/slideshow/ss-51001155/51001155

샌드박스 vs 가상 머신 (VM)

샌드박스를 알게 되면서 유사하다고 느낀 건 바로 가상머신이다. 가상머신도 호스트와 격리된 환경을 제공하는데 과연 무슨 차이가 있을까?

Hypervisor

가상 머신에서는 단일 물리적 머신에서 여러 가상 머신을 실행하는 데 사용할 수 있는 소프트웨어인 하이퍼바이저(Hypervisor)가 필요하다. 사진에서 보면 Type1의 경우, 하이퍼바이저가 하드웨어 위에서 동작함을 볼 수 있다. 하드웨어를 하이퍼바이저를 이용해 가상화함으로써 하드웨어 수준에서 격리를 제공한다.

다만 샌드박스는 호스트 OS의 커널을 이용해 호스트 위에서 격리 환경이 구성되기 때문에, 빠르게 환경을 구성하고 있고, OS 또한 따로 설치할 필요가 없다.

Windows에서는 샌드박스(WSB)와 가상 머신(Hyper-V) 둘 다 제공하고 있다. MS에서 말하는 차이는 다음과 같다.

위 내용을 표로 정리해 봤다.

구분	Windows Sandbox (WSB)	Hyper-V 가상 머신 (VM)
목적/특징	경량 및 일시적(Lightweight & Temporary)	무겁고 영구적인 환경(Heavyweight & Persistent)
설정 시간	빠른 실행 가능 (Quickly launch)	설정에 더 많은 시간 소요 (Longer to set up)
자원 효율성	고효율적 (More resource efficient), 요구에 따라 메모리 조정, 호스트의 읽기 전용 OS 파일 재사용	고정 자원 할당 (Fixed resource allocations), 시스템 성능에 영향 가능
격리 및 보안	보안 격리 제공. 닫으면 모든 변경 사항이 폐기됨 (Disposable)	격리 제공. 수동으로 복원하지 않는 한 변경 사항이 영구적으로 저장됨 (Persistent)
사용 편의성	사용이 간단 (Simple to use), 복잡한 설정 불필요	더 많은 구성 필요 (More configuration), 가상 스위치, 네트워크 어댑터, 스냅샷 관리 등
기술적 배경	호스트 OS 커널 활용 (경량 격리 환경)	하이퍼바이저를 통한 하드웨어 가상화 (완벽한 시스템 격리)

참고

[Spring] Spring Filter로 특정 API 응답 데이터 gzip 압축 적용하기

anxi — Mon, 10 Nov 2025 21:19:53 +0900

중간지점 찾기 서비스인 모이삼에서는 중간지점 산출 및 출발지에서 중간지점까지의 상세 경로를 알려준다.

https://www.moisam.kr/

모이삼

최적의 중간장소 찾기, 약속장소 추천

www.moisam.kr

중간지점은 최대 3개까지 산출되며, 출발지마다 경로를 보여주는 만큼, 응답 데이터의 크기는 중간지점 수와 출발지 수에 비례한다.

그래서 모이삼은 응답 시간을 줄이기 위해 응답 데이터 캐싱과 멀티 스레드를 사용해 외부 API에서 경로를 가져오는 등 여러 처리를 진행했다. 위 과정을 통해 비약적으로 속도 개선을 이뤘지만, 응답 데이터의 크기는 줄이지 못했다.

줄일 수 있는 방법을 찾아보던 와중, 응답 데이터를 압축할 수 있는 포맷인 gzip을 알게 되었다.

gzip이란?

gzip은 파일 압축 및 압축 해제에 사용되는 파일 형식(file format)이다.

Deflate 알고리즘을 기반으로, 파일 크기를 줄여 네트워크 전송 속도를 향상시킬 수 있다.

gzip은 웹 서버 및 최신 브라우저에서 지원돼서, 서버는 응답을 전송 이전에 gzip으로 압축할 수 있고, 브라우저는 응답을 자동으로 압축해제 할 수 있다.

적용 근거

최범균 님의 "주니어 백엔드 개발자가 반드시 알아야 할 실무 지식"에서는

응답 시간에는 데이터 전송 시간이 포함되고, 데이터 전송 시간에는 '네트워크 속도', '전송 데이터 크기' 2가지 요인에 영향을 받는다고 한다.

위 2가지 요인 중에 서버가 핸들링할 수 있는 것은 '전송 데이터 크기' 뿐이다. '네트워크 속도'는 공유기나 통신사 등 여러 요인에 따라 영향받을 수 있지만, 전송 데이터 크기는 서버에서 압축할 수 있기 때문이다.

그래서 나는 '전송 데이터 크기'를 gzip으로 압축하여 서버에서 데이터 크기를 줄여 해결하고자 했다.

1. 브라우저 범용성이 높다.

Browser Compatibility

위 사진은 gzip뿐만 아닌 여러 압축 포맷에서의 브라우저 수용 가능성을 보여준다.

Brotli 알고리즘을 사용한 br 포맷도 Opera Android를 제외하고 대부분의 브라우저에서 사용 가능하기 때문에, 더 오래된 gzip은 더 범용성 있을 거라 생각했다.

2. 압축률이 좋다.

https://tools.paulcalvano.com/compression.php

위 사진은 gzip과 brotli, 그리고 압축 전의 응답 크기를 비교한 결과다. (중간지점 2개, 출발지 8개 기준)

level을 1로 계산했을 경우에 아래와 같다.

gzip: 1614
Brotli: 1691
비압축(Uncompressed): 2788

gzip을 사용할 경우, 원본 크기의 57% 압축을 이뤄낼 수 있다. level을 높게 설정할 경우 압축률은 더 늘릴 수 있다.

3. 적용하기 쉽다.

HTTP request의 'Accept-Encoding' 헤더를 통해 서버에 처리할 수 있는 압축 알고리즘을 알려준다.

HTTP request

HTTP response에서는 클라이언트에서 명시된 알고리즘 중에서 지원한 방식의 알고리즘을 'Content-Encoding' 헤더에 명시한다.

서버에서만 gzip으로 압축하고 'Content-Encoding'을 명시해 주면 끝이다. (br, deflate, zstd로 압축을 해도 상관없다.)

Nginx나 Traefik와 같은 웹 서버는 압축 기능을 제공하고 있어 백엔드 코드를 건드리지 않고도 해결할 수 있다.

다만 특정 경로에서의 처리는 불가능하기 때문에 나는 스프링 필터를 사용해 특정 경로에서만 gzip 압축을 하도록 구현했다.

Spring Filter를 사용하여 특정 API 응답 압축 구현기

java.util.zip에서 GZIPOutputStream을 제공하기 때문에 ServletOutputStream을 GZIPOutputStream으로 변경한다.

그리고 HttpServletResponseWrapper를 GZIPOutputStream을 사용하도록 수정하고 Filter에서 압축할 API의 엔드포인트를 검증하여 분기처리한다.

1️⃣ GzipHttpServletResponseWrapper

/** GZIP 압축 적용 응답 Wrapper */
public class GzipHttpServletResponseWrapper extends HttpServletResponseWrapper {

    public static final String GZIP = "gzip";

    private GzipServletOutputStream gzipServletOutputStream;

    public GzipHttpServletResponseWrapper(HttpServletResponse response) {
        super(response);
        // HTTP response에 Content-Encoding을 GZIP으로 설정
        response.addHeader(HttpHeaders.CONTENT_ENCODING, GZIP);
        
        // Vary: Accept-Encoding 헤더 설정
        response.addHeader(HttpHeaders.VARY, HttpHeaders.ACCEPT_ENCODING);
    }

    @Override
    public ServletOutputStream getOutputStream() throws IOException {
        if (gzipServletOutputStream == null) {
            gzipServletOutputStream = new GzipServletOutputStream(getResponse().getOutputStream());
        }
        return gzipServletOutputStream;
    }

    /** GZIP 출력 스트림 종료 */
    public void finish() throws IOException {
        if (gzipServletOutputStream != null) {
            gzipServletOutputStream.flush();
            gzipServletOutputStream.close();
        }
    }
}

HttpServletResponseWrapper를 상속받아 응답 스트림을 GZIPOutputStream으로 감싼다.
"Content-Encoding: gzip"과 "Vary: Accept-Encoding" 헤더를 추가한다.
- "Vary: Accept-Encoding"는 캐시 시스템(CDN, Proxy, Cache)에게 클라이언트의 "Accept-Encoding" 헤더 값에 따라 응답이 달라질 수 있음을 알려준다. 만약 Vary를 적용하지 않는다면, gzip으로 압축한 응답이 캐시 했다가 gzip을 지원하지 않는 클라이언트에게 그대로 전달할 수 있는 문제가 발생한다. 따라서 "Vary: Accept-Encoding"도 추가하는 게 안전하다.
getOutputStream()에서 gzip 압축 스트림(GzipServletOutputStream)을 생성한다.

즉, 이 클래스는 기존 HttpServletResponse를 gzip 응답용으로 감싸는 역할을 한다.

2️⃣ GzipServletOutputStream

/** GZIP 출력 스트림 */
public class GzipServletOutputStream extends ServletOutputStream {

    private final GZIPOutputStream gzipOutputStream;

    public GzipServletOutputStream(OutputStream outputStream) throws IOException {
        this.gzipOutputStream = new GZIPOutputStream(outputStream);
    }

    @Override
    public boolean isReady() {
        return true;
    }

    @Override
    public void setWriteListener(WriteListener writeListener) {
    }

    @Override
    public void write(int b) throws IOException {
        gzipOutputStream.write(b);
    }

    @Override
    public void flush() throws IOException {
        gzipOutputStream.flush();
    }

    @Override
    public void close() throws IOException {
        gzipOutputStream.close();
    }
}

ServletOutputStream을 상속받아 내부적으로 GZIPOutputStream을 사용한다.
write(), flush(), close() 모두 java.util.zip의 GZIPOutputStream을 적용한다.

즉, 이 클래스는 실제 gzip 압축을 수행하는 역할을 한다.

3️⃣ CompressFilter

/** 응답 데이터 압축 필터 */
@Component
public class CompressFilter extends OncePerRequestFilter {

    /** GZIP 압축이 허용된 API 엔드포인트의 정규식 패턴 목록 */
    private static final List<Pattern> ALLOWED_COMPRESS_ENDPOINT_PATTERNS = List.of(
            Pattern.compile("^/events/[^/]+$")
    );

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        /** 압축 허용된 API가 아닐 경우 미압축 응답을 반환 */
        if (!shouldCompress(request)) {
            filterChain.doFilter(request, response);
            return;
        }

        /** Gzip 압축 응답 생성 Wrapper를 사용하여 필터 체인 실행 */
        GzipHttpServletResponseWrapper gzipResponse = new GzipHttpServletResponseWrapper(response);
        try {
            filterChain.doFilter(request, gzipResponse);
        } finally {
            gzipResponse.finish();
        }
    }

    /** 주어진 요청이 GZIP 압축 대상인지 검증 */
    private boolean shouldCompress(HttpServletRequest request) {
        String acceptEncoding = request.getHeader(HttpHeaders.ACCEPT_ENCODING);
        String uri = request.getRequestURI();
        String method = request.getMethod();

        boolean isGet = HttpMethod.GET.name().equalsIgnoreCase(method);

        return acceptEncoding != null
                && acceptEncoding.contains(GZIP)
                && isGet
                && matchesAllowedUri(uri);
    }

    /** 요청 URI가 허용된 압축 엔드포인트 패턴과 일치하는지 검사 */
    private boolean matchesAllowedUri(String uri) {
        return ALLOWED_COMPRESS_ENDPOINT_PATTERNS.stream()
                .anyMatch(pattern -> pattern.matcher(uri).matches());
    }
}

특정 API 요청만 gzip으로 압축하도록 필터링한다.
정규식으로 URI를 매칭하여 일치할 경우에만 압축한다.
request의 "Accept-Encoding" 헤더에 gzip이 포함된 경우에만 처리한다.

즉, 이 클래스는 클라이언트의 요청을 확인하고 gzip으로 반환 가능한지 검증 후 Wrapper를 사용해 응답을 압축하는 역할을 한다.

적용 결과

gzip 압축 전

gzip 압축 후

위 두 사진은 중간지점 1개, 출발지 8개 기준으로 압축 전후의 결과이다.

응답 시간: 약 27% 단축
응답 크기: 약 83% 감소

앞서 언급한 적용 근거처럼, 네트워크 속도가 느릴수록 압축 전후의 응답 시간 차이는 더 크게 나타날 것이다.

참고

최범균 - "주니어 백엔드 개발자가 반드시 알아야 할 실무 지식"
https://developer.mozilla.org/en-US/docs/Glossary/gzip_compression
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Encoding
https://tools.paulcalvano.com/compression.php
https://bepoz-study-diary.tistory.com/434

[PostgreSQL] FATAL: remaining connection slots are reserved for roles with privileges of the "rds_reserved" role 해결하기

anxi — Tue, 21 Oct 2025 20:40:07 +0900

‍♂️ 문제 : 외부에서 DB 접속이 되지 않음

DB 연결 시, 발생한 문제

최근 모이삼 프로젝트 git이 꼬여 제거하고 다시 clone 하여 로컬 환경 설정을 진행했다.

IDE에서 DB를 연결하는 도중, 위와 같은 에러가 발생했다.

RDS를 사용하고 있어 확인해 보니 "현재 활동"의 연결 수가 72개였다. 현재 활동이란 Connection 연결 수를 의미한다.

로그를 확인해 보니 위 에러가 반복적으로 발생했음을 알 수 있었다.

DB가 허용하는 최대 연결 수(Max Connections)가 완전히 꽉 찼으며, 일반 사용자를 위한 연결 슬롯은 0개입니다. 이제 남은 연결 자리는 AWS가 DB 관리를 위해 확보해 둔 비상용 슬롯뿐입니다.

즉, AWS가 아닌 우리(사용자)는 DB 연결을 할 수 없음을 의미한다.

왜 이런 문제가 발생했을까?

Client와 RDS를 중개하는 EC2 서버가 존재

모이삼 시스템 아키텍처

메인 서버는 Naver Cloud Server를 사용하고 있다. 그리고 DB는 AWS의 RDS를 사용한다.

메인 서버에서 DB의 연결은 AWS의 EC2로 중개하여 구축했다.

위와 같이 구축한 이유는 다음과 같다.

AWS 프리티어의 이점을 살리기 위함.
Naver Cloud의 DB 인스턴스 비용이 비쌈.
Naver Cloud와 AWS 멀티 클라우드 환경에서의 연결이 가능하지만 비용 발생.

구축 이유를 요약하자면, 비용을 들이지 않고 구축하기를 바랐다.

그래서 에러 원인을 찾기 위해 중개 서버인 EC2를 확인했고, 그 결과..

수많은 socat 프로세스가 존재했고, 이는 RDS에서 보았던 현재 활동의 수와 일치함을 확인했다.

기존 EC2, RDS 연결 방식 : socat을 이용하여 포트포워딩

메인 서버에서 RDS를 접속하기 위해서 EC2가 포트포워딩을 해줘야 했다. EC2를 포트포워딩 하기 위해 나는 socat을 사용했다.

socat은 소켓(Socket) 생성 및 소켓 간 데이터 전송 등의 데이터 송신 등의 기능을 제공하는 프로그램이다.

# EC2
$ nohup socat TCP-LISTEN:{EC2_PORT},fork TCP:{RDS_ADDRESS}:{RDS_PORT} &

EC2의 특정 포트로 들어온 연결을 RDS의 특정 포트로 연결하여, 메인 서버에서 EC2 IP를 사용해 RDS에 접근하도록 했다.

앞의 nohup은 터미널 세션이 끝나도 동작하도록, 뒤에 ampersand(&)는 백그라운드에서 실행 가능하기 위해 설정했다.

하지만 fork 옵션에서 문제가 발생한다.

fork 옵션은 자식 프로세스를 생성하기 때문에 다수의 connection을 만들기 위해 필수적인 옵션이다. 그러나 프로세스가 계속 누적되고, 누적된 프로세스를 청소하질 않아 위의 문제가 발생했다.

그래서 임시방편으로 누적된 프로세스를 제거하기 위해 killall socat을 사용하여 socat의 모든 프로세스를 제거했다.

해결 방법 : PgBouncer를 이용

1시간마다 프로세스를 클린업 하도록 자동화 스크립트를 작성하면 socat을 사용하더라도 괜찮을 수 있다. 다만 단순히 프로세스를 클린업 하는 건 좋지 않다고 생각했다.

예를 들면, 정각에 클린업 이후 다수의 db connection이 발생했을 경우에 초기 연결 비용이 발생할 수 있다. 또한 현재 사용하고 있는 프로세스가 db 트랜잭션 연결 중인지, idle 상태인지 구분하기 어렵다고 보았다.

그러던 중 PostgreSQL 프로세스 연결을 도와주는 도구인 PgBouncer를 알게 되었다.

https://postgresql.kr/blog/pgbouncer.html

그리고 PgBouncer 관련 글을 읽던 와중, 세 번째 방식인 전용 호스트를 두는 방법이 중개 서버 EC2와 유사하다고 느껴 적용하게 되었다.

적용 과정

적용 방식은 https://postgresql.kr/blog/pgbouncer.html을 참고했습니다.

1. PgBouncer 설치하기

$ sudo apt update
$ sudo apt install pgbouncer

2. /etc/pgbouncer/pgbouncer.ini 설정하기

/etc/pgbouncer 하위에 pgbouncer.ini와 userlist.txt가 존재한다.

pgbouncer.ini는 응용 프로그램 설정 파일, userlist.txt는 사용자 인증 파일이다.

값 설정은 위 링크를 참고하여 서비스에 맞게 설정하면 된다.

모이삼은 다음과 같이 설정했다.

$ sudo vi pgbouncer.ini

[databases] # PgBouncer가 RDS 인스턴스에 접속할 때 사용할 정보
<RDS 별칭> = host=<RDS 엔드포인트> port=5432 dbname=<RDS 이름> user=<RDS 사용자 이름>
ex) mydb = host=mydb.xxxx.rds.amazonaws.com port=5432 dbname=app user=admin

[pgbouncer]
listen_addr = * # 모든 IP 허용
listen_port = 5432

;; any, trust, plain, md5, cert, hba, pam
auth_type = md5 # 암호 방식
auth_file = /etc/pgbouncer/userlist.txt # 사용자 인증 파일 위치 

;; When server connection is released back to pool:
;;   session      - after client disconnects (default)
;;   transaction  - after transaction finishes
;;   statement    - after statement finishes
;; 트랜잭션이 끝날 때마다 풀에 반납하도록 함
pool_mode = transaction

;; Comma-separated list of parameters to ignore when given in startup packet.
;; 최신 JDBC 드라이버가 PgBouncer가 지원하지 않는 시작 파라미터를 보낼 때 연결이 거부되는 오류를 방지
ignore_startup_parameters = extra_float_digits 

;; PgBouncer가 RDS로 유지하는 connection 수
default_pool_size = 40

;; 풀에 들어있는 최소 connection 수
min_pool_size = 10

;; RDS connection 슬롯 부족을 방지하기 위해 default_pool_size와 동일하게 설정
max_db_connections = 40

;; PgBouncer와 RDS 간의 연결을 1시간마다 주기적으로 재생성
;; 장기 연결로 인한 DB 서버의 메모리 누수 방지
server_lifetime = 3600

;; 사용되지 않고 풀에 남아 있는 RDS 연결을 10분 후 자동으로 정리
;; 불필요한 DB 연결 슬롯 낭비 방지
server_idle_timeout = 600

;; PgBouncer에 연결한 클라이언트가 1분 동안 아무 활동이 없으면 연결을 강제로 끊음.
client_idle_timeout = 60

3. /etc/pgbouncer/userlist.txt 설정하기

"사용자이름" "비밀번호"로 작성하면 되고, 비밀번호는 DB 암호를 사용하면 된다. (AWS RDS PostgreSQL 17 기준)

$ sudo vi userlist.txt

# "사용자 이름" "비밀번호"
"admin" "1234"

비밀번호를 scram-sha-256 방식으로 바꿔서 넣어야 한다고 하는데, pgbouncer가 동작하지 않았다.
만약 AWS RDS PostgreSQL 17 버전을 사용한다면, 비밀번호를 평문으로 넣어서 실행하면 될 것이다.

4. PgBouncer 재시작하기

$ sudo systemctl restart pgbouncer

5. AWS EC2 IP를 사용해 RDS 접속하기

# application.yml
spring:
  datasource:
    # EC2 인스턴스의 IP 주소 사용
    url: jdbc:postgresql://<EC2 IP 주소>/<Database>

Spring Boot는 위와 같이 변경하면 되고, Data Grip을 사용할 경우에도 EC2 IP 주소를 통해 접속 가능하다.

마무리

FATAL: remaining connection slots are reserved for roles with privileges of the "rds_reserved" role

AWS RDS 연결 과정에서 마주한 에러를 PgBouncer를 사용해 해결했다.

이전에는 socat을 사용했고, 이번에는 PgBouncer를 사용하는 방식으로 변경했다.

돈을 내지 않기 위해 이런저런 방법을 사용해 봤는데, 나름대로 괜찮은 방법인 거 같다.

RDS의 Public Access를 키더라도, 비용 발생할 뿐만 아니라 보안적으로도 좋지 않고,, Naver Cloud의 DB를 사용하기엔 비용이 너무 비싸다. 메인 서버 내부의 파드로 띄울 수도 있긴 하지만, RDS에서 제공하는 기능을 사용할 수 있음 좋으니까..!

➕ Unable to commit against JDBC Connection 발생

PgBoucer를 적용한 뒤, 종종 위 에러를 확인할 수 있었다.

예전엔 발견하지 못했던 에러라서 PgBouncer 적용 과정에서 발생한 문제가 확실했다.

위 에러는 지도 조회 페이지에서 오랜 시간 있었을 경우 발생했다.

내 생각에는 pool_mode를 transaction으로 설정했기 때문에 트랜잭션이 끝나면 PgBouncer가 커넥션풀에 커넥션을 반환한다.

기존 커넥션을 반환한 후에 다시 사용할 수 없어 위 에러가 발생했다고 판단한 뒤, pool_mode를 session으로 설정했다.

session 모드는 커넥션이 세션 단위로 유지되기 때문에 웹 페이지에서 오랜 시간 있더라도 문제가 발생하지 않았다.

만약 Unable to commit against JDBC Connection이 발생한다면,
pool_mode를 session으로 변경해보자!