빠르게 학습하고 빠르게 적용하자

홈서버 Blue-Green 무중단 배포 구축하기

osoohynn — Fri, 1 May 2026 15:49:13 +0900

무중단 배포 배경

빠른 실험 전략을 선호하던 저는 Querify 서비스를 운영하며 여러 번 과감한 시도를 했습니다. Github Branch 전략을 사용하고 있었기 때문에 개발할 때는 배포 환경에서 이슈가 발생하면 빠르게 main브랜치에 올리는 방식을 이용했었습니다.

그러나 사용자가 조금씩 생기다 보니.. 배포 환경에서의 문제를 사용자가 겪는 상황이 있었고, 이 상황에서 사용할 롤백 장치가 마련되어있지 않아 곤란했습니다. 또한 새로운 기능을 추가하거나 수정하는 배포 과정에서도 서버가 일시적으로 다운되기 때문에 사용자 경험이 많이 떨어졌습니다.

그래서 기존에 알고 있던 무중단 배포 전략을 활용하여 배포할때도 서버가 다운되지 않고, 급한 이슈를 롤백으로 해결할 수 있는 환경을 마련하고자 하였습니다.

배포 전략 선택

블루 그린 방식은 리소스 두 배라는 약점이 있습니다. 하지만 홈서버에서 구축되어 있었기 때문에 클라우드 비용도 없고 남는 메모리로 충분히 감당이 되었습니다.

반대로 장점은 실험 단계에서는 실수가 잦은데, 라우팅만 수정하면 롤백되어서 빠르게 이슈를 처리하기 좋습니다. Compose + Nginx upstream 전환이면 쉽게 구현할 수도 있습니다.

마지막으로 확장성을 고려했습니다. MSA로 쪼개면 서비스마다 독립적으로 Blue-Green을 돌릴 수 있습니다.

            [ Nginx ]
                ↓
[ Blue (8082) ] or [ Green (8083) ]

블루 그린 중에서도 낮은 복잡도와 빠른 롤백의 장점을 극대화하기 위해 하나의 인스턴스(홈서버 한 대)에서 Docker compose로 앱 컨테이너를 관리하는 방식을 채택했습니다.

롤링 업데이트 방식은 교체 중에 v1과 v2가 같은 트래픽을 나눠 받는 구간이 있어서 API 호환성 문제가 생기기 쉽습니다. 롤백도 번거로워서 빠르게 롤백이 필요한 상황에 맞지 않아서 배제하였습니다.

Canary는 새 버전을 일부 트래픽에만 노출시키는 방법인데, 실제 사용자 트래픽으로 검증할 수 있다는 게 핵심 장점입니다. 그러나 모니터링을 꼼꼼하게 붙혀야하며, 롤링 방식과 마찬가지로 버전 관리가 필요하여 배제하였습니다.

구현

우선 기존 docker-compose.yml를 app과 분리하여 docker-compose.infra.yml를 새로 작성했습니다.

# docker-compose.infra.yml
services:
  mysql:
    image: mysql:8.0
    container_name: soj-mysql
    # ... 기존 그대로
    networks: [soj-network]

  redis:
    image: redis:7-alpine
    container_name: soj-redis
    # ...
    networks: [soj-network]

  mongodb:
    image: mongo:4.4
    container_name: soj-mongodb
    # ...
    networks: [soj-network]

  kafka:
    image: apache/kafka:3.7.0
    container_name: soj-kafka
    # ...
    networks: [soj-network]

  # ... ES, Logstash, Kibana, mysql-sandbox 등

networks:
  soj-network:
    name: soj-network
    driver: bridge

volumes:
  mysql_data:
  redis_data:
  mongo_data:
  es_data:
  kafka_data:

docker-compose.blue.yml과 docker-compose.green.yml 두 파일로 나누었습니다.

# docker-compose.blue.yml
services:
  app-blue:
    image: ${APP_IMAGE:-soj-backend:latest}
    container_name: soj-app-blue
    env_file: .env
    expose:
      - "8080"
    networks:
      - soj-network
    healthcheck:
      test: ["CMD", "curl", "-f", "<http://localhost:8080/actuator/health>"]
      interval: 5s
      timeout: 3s
      retries: 10
      start_period: 30s
    restart: unless-stopped

networks:
  soj-network:
    external: true

# docker-compose.green.yml
services:
  app-green:
    image: ${APP_IMAGE:-soj-backend:latest}
    container_name: soj-app-green
    env_file: .env
    expose:
      - "8080"
    networks:
      - soj-network
    healthcheck:
      test: ["CMD", "curl", "-f", "<http://localhost:8080/actuator/health>"]
      interval: 5s
      timeout: 3s
      retries: 10
      start_period: 30s
    restart: unless-stopped

networks:
  soj-network:
    external: true

Nginx upstream을 이용하도록 수정하였습니다!

server {
    server_name api.querify.dev;
    location / {
        proxy_pass http://soj_backend;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Connection "";
    }
    listen [::]:443 ssl;
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/api.querify.dev/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.querify.dev/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
server {
    if ($host = api.querify.dev) {
        return 301 https://$host$request_uri;
    }
    listen 80;
    listen [::]:80;
    server_name api.querify.dev;
    return 404;
}

upstream soj_backend {
    server 127.0.0.1:8082;
    keepalive 32;
}

deploy.sh파일로 배포 자동화를 구현하였습니다.

#!/bin/bash
# 무중단 배포 스크립트
set -euo pipefail

cd "$(dirname "$0")"

NEW_IMAGE="${1:-soj-backend:latest}"
UPSTREAM_FILE="/etc/nginx/conf.d/soj-upstream.conf"

# 색상 출력
log()   { echo -e "\\033[0;32m[$(date +%H:%M:%S)]\\033[0m $1"; }
warn()  { echo -e "\\033[1;33m[$(date +%H:%M:%S)] WARN:\\033[0m $1"; }
error() { echo -e "\\033[0;31m[$(date +%H:%M:%S)] ERROR:\\033[0m $1"; exit 1; }

# === 1. 현재 색깔 확인 ===
[ -f .current_color ] || echo "blue" > .current_color
CURRENT=$(cat .current_color)

if [ "$CURRENT" = "blue" ]; then
    NEW="green"
    NEW_PORT="8083"
else
    NEW="blue"
    NEW_PORT="8082"
fi

log "배포 시작: $CURRENT → $NEW (port $NEW_PORT, image: $NEW_IMAGE)"

# === 2. 새 컨테이너 띄우기 ===
log "$NEW 컨테이너 시작..."
export APP_IMAGE="$NEW_IMAGE"
docker compose -f docker-compose.$NEW.yml up -d

.
.
.

# === 6. 외부 검증 ===
sleep 3
EXTERNAL=$(curl -sf -o /dev/null -w "%{http_code}" <https://api.querify.dev/actuator/health> || echo "000")
if [ "$EXTERNAL" != "200" ]; then
    warn "외부 응답 비정상 ($EXTERNAL), 롤백 검토 필요"
fi

# === 7. 드레이닝 ===
log "$CURRENT 드레이닝 (15초 대기)..."
sleep 15

# === 8. 구버전 종료 ===
docker compose -f docker-compose.$CURRENT.yml down
echo "$NEW" > .current_color
log "✅ 배포 완료: $CURRENT → $NEW ($NEW_IMAGE)"

후기

무중단 배포를 구현할 때는 여러 개의 인스턴스를 돌려야만 하는 줄 알았는데, Docker Compose와 Nginx만으로도 구현할 수 있어서 간편했습니다. 배포시 다운타임을 없애는 것과 롤백할 수 있는 환경을 모두 만족했기 때문에 현재는 이 정도로 충분하고 나중에 트래픽이 커지거나 가용성이 진짜로 필요해지는 시점에 같은 Blue-Green 패턴을 로드 밸런스와 여러 대의 서버로 옮기고자 합니다.

다른 관점이나 잘못된 판단이 보이면 댓글 부탁드립니다!!

JSON 문자열을 RDB에 넣었다가... MySQL→MongoDB 메타데이터 마이그레이션기

osoohynn — Tue, 31 Mar 2026 22:22:20 +0900

배경

데이터 저장을 전부 RDB에 저장했습니다. 문제마다, 각 테스트 케이스마다 카디널리티와 애트리뷰트 수가 다르다보니 각각 데이터를 저장할 수 없었습니다. 따라서 우선적으로 메타데이터 라는 이름으로 Json 형식으로 저장했었습니다.

하지만 서비스가 커지고 문제가 발생했었습니다. 이미 등록한 문제를 풀어보니 메타데이터에서 수정이 필요한 부분이 있었습니다. NULL값이 들어가야하는데 공백이 들어가있어 문제를 급하게 수정해야하는 상황이였습니다. 그런데 데이터 베이스에 JSON형태로 들어가 있다보니 수정이 필요한 부분만 딱 찝어서 수정이 어려웠고 결국 하나하나 읽은 후 새 데이터로 덮어써야했습니다.

이러한 문제를 겪다보니.. 역시 JSON데이터를 문자열로 저장하는 것은 아니라고 판단했습니다. 따라서 NoSQL로 이전하는것이 바람직하다고 생각했습니다.

저장 구조

Problem 테이블

컬럼 타입 내용

schema_sql	TEXT	SqlGenerator가 생성한 CREATE TABLE SQL
schema_metadata	JSON	SchemaMetadata 객체 그대로

TestCase 테이블

컬럼 타입 내용

init_sql	TEXT	생성된 INSERT SQL
init_metadata	JSON	InitMetadata 객체 그대로
answer	TEXT	탭 구분 TSV
answer_metadata	JSON	AnswerMetadata 객체 그대로

metadata에서 SQL이나 TSV는 SqlGenerator로 언제든 재생성할 수 있습니다. 그런데 metadata와 SQL/TSV를 둘 다 저장하고 있었습니다. 만약 SQL만 수동으로 수정하거나, 한쪽만 업데이트되면 metadata와 SQL 간 내용이 어긋나게 됩니다. 단일 진실 공급원(Single Source of Truth)이 깨지는 거죠.

또한 텍스트 데이터에서 데이터 자체에 탭(\\t)이나 개행(\\n)같은 파싱 방법이 불안정했습니다.

마지막으로 컬럼마다 ObjectMapper 인스턴스가 새로 생성되고 있었습니다. ObjectMapper는 스레드 세이프하므로 싱글턴으로 공유하는 것이 맞는데, 불필요한 인스턴스가 계속 만들어지고 있었던 거죠.

NoSQL

구조가 유동적인 데이터를 문자열로 직렬화해서 RDB에 억지로 끼워 넣는 것 자체가 문제였습니다. NoSQL, 그중에서도 MongoDB로 이전하면 JSON 데이터를 네이티브 도큐먼트로 저장할 수 있습니다. 필드 단위 조회와 수정이 가능해지고, 타입 정보도 보존되며, 중복 저장의 필요성도 사라집니다.

Redis로 문제를 한 번 조회하고 전체를 Redis에 저장하기 때문에 성능상으로도 큰 문제는 없을 거라고 생각했습니다.

개선 과정이 너무 재밌을 것 같네요!!

아키텍처 결정: Service-Level

MongoDB를 도입한다고 해서 MySQL을 버리는 건 아닙니다. 문제의 제목, 설명, 난이도 같은 정형 데이터는 여전히 MySQL이 적합합니다. 옮겨야 할 건 구조가 유동적인 메타데이터 세 가지뿐이었습니다.

대상 원래 위치 이전 후

SchemaMetadata	problems.schema_metadata (JSON)	MongoDB problem_metadata 컬렉션
InitMetadata	test_cases.init_metadata (JSON)	MongoDB testcase_metadata 컬렉션
AnswerMetadata	test_cases.answer_metadata (JSON)	MongoDB testcase_metadata 컬렉션

여기서 핵심적인 설계 결정이 하나 필요했습니다.

MySQL 데이터와 MongoDB 데이터를 어디서 조합할 것인가?

선택지는 크게 두 가지였습니다. 하나는 Repository 레벨에서 두 저장소를 모두 알게 하는 방법, 다른 하나는 Service 레벨에서 조합하는 방법입니다.

Service-Level Joining을 선택했습니다. 이유는 Repository는 자기가 담당하는 저장소만 알아야 합니다. MySQL Repository가 MongoDB의 존재를 알게 되는 순간, 저장소 간 의존이 생기고, 테스트할 때 두 저장소를 동시에 모킹해야 하는 번거로움이 따라옵니다. 각 Repository는 자기 저장소만 책임지고, Service에서 양쪽 결과를 copy()로 조합하는 게 훨씬 깔끔합니다.

조회 흐름을 정리하면 이렇습니다.

MySQL에서 Problem 조회 → MongoDB에서 SchemaMetadata 조회 → problem.copy(schemaMetadata = ...) → 완전한 도메인 객체 → Redis 캐싱

기존에 Redis 캐싱이 이미 걸려 있었기 때문에, 조합된 완전한 도메인 객체를 캐싱하면 두 번째 조회부터는 MongoDB에 요청조차 가지 않습니다. 즉, 저장소가 두 개로 늘어났지만 캐시 히트 시 성능 영향은 거의 없을 것으로 예상됩니다.

MongoDB Document 설계

MongoDB 쪽 도큐먼트 구조는 최대한 단순하게 가져갔습니다.

@Document(collection = "problem_metadata")
data class ProblemMetadataDocument(
    @Id val id: String? = null,
    @Indexed(unique = true) val problemId: Long,
    val schemaMetadata: SchemaMetadata
)

@Document(collection = "testcase_metadata")
data class TestCaseMetadataDocument(
    @Id val id: String? = null,
    @Indexed(unique = true) val testCaseId: Long,
    val initMetadata: InitMetadata?,
    val answerMetadata: AnswerMetadata?
)

설계할 때 고민했던 포인트가 몇 가지 있습니다.

problemId / testCaseId에 unique index를 걸었습니다. MongoDB의 _id는 ObjectId로 자동 생성되기 때문에, MySQL의 PK와 매핑하려면 별도 필드가 필요합니다. 이 필드에 유니크 인덱스를 걸어두면 중복 삽입을 DB 레벨에서 막을 수 있고, findByProblemId() 같은 조회도 인덱스 스캔으로 처리됩니다.

TestCase 조회 시 배치 조회를 고려했습니다. 문제 하나에 딸린 테스트 케이스가 여러 개이기 때문에, findByTestCaseIdIn(testCaseIds) 메서드를 만들어서 N+1 문제를 방지했습니다. testCaseId 목록을 한 번에 넘기면 MongoDB에서 $in 쿼리로 한 번에 가져옵니다.

Service 레이어 변경

// ProblemService.kt
class ProblemService(
    private val problemRepository: ProblemRepository,           // MySQL
    private val problemMetadataMongoRepository: ProblemMetadataMongoRepository  // MongoDB
) {
    fun findById(id: Long): Problem {
        val problem = problemRepository.findById(id)        // MySQL 조회
        val metadata = problemMetadataMongoRepository
            .findByProblemId(id)                             // MongoDB 조회
        return problem.copy(
            schemaMetadata = metadata?.schemaMetadata         // 조합
        )
    }
}

MySQL Repository에서는 메타데이터 관련 파라미터를 전부 제거했습니다. save()에서 schemaMetadata 세팅 라인 삭제, update()에서 schemaMetadata 파라미터 삭제. Repository가 알아야 할 게 줄어든 거죠. 대신 Service의 create()와 update()에서 MongoDB 저장을 별도로 호출합니다.

TestCase 쪽도 같은 패턴입니다만 findAll()에서는 앞서 만들어둔 배치 조회를 활용합니다.

fun findAll(problemId: Long): List<TestCase> {
    val testCases = testCaseRepository.findAllByProblemId(problemId)
    val testCaseIds = testCases.map { it.id }
    val metadataMap = testCaseMetadataMongoRepository
        .findByTestCaseIdIn(testCaseIds)
        .associateBy { it.testCaseId }    // Map으로 변환하여 O(1) lookup

    return testCases.map { tc ->
        val meta = metadataMap[tc.id]
        tc.copy(
            initMetadata = meta?.initMetadata,
            answerMetadata = meta?.answerMetadata
        )
    }
}

FlywayMigrationStrategy

Spring Boot가 제공하는 FlywayMigrationStrategy를 오버라이드해서, Flyway migrate() 호출 직전에 데이터를 먼저 MongoDB로 옮겼습니다.

@Configuration
class MetadataMigrationConfig(
    private val mongoTemplate: MongoTemplate,
    private val jdbcTemplate: JdbcTemplate
) {
    @Bean
    fun flywayMigrationStrategy(): FlywayMigrationStrategy =
        FlywayMigrationStrategy { flyway ->
            migrateMetadataToMongo()   // 1) JSON 컬럼 살아있을 때 읽어서 이전
            flyway.migrate()            // 2) 이제 컬럼 DROP해도 안전
        }
}

실행 순서를 정리하면 이렇습니다.

앱 시작 → DataSource 초기화 → FlywayMigrationStrategy 실행
  └→ migrateMetadataToMongo() (JSON 컬럼 아직 살아있음 ✅)
  └→ flyway.migrate() (컬럼 DROP ✅)

JdbcTemplate을 직접 쓴 이유는, 이 시점에서 Exposed나 JPA가 완전히 초기화됐다는 보장이 없어서입니다. JdbcTemplate은 DataSource만 있으면 동작하니까 가장 안전했습니다.

멱등성 보장

앱 재시작할 때마다 중복 삽입되면 안 되니까, collectionExists()로 이미 컬렉션이 있으면 통째로 건너뛰게 했습니다.

private fun migrateMetadataToMongo() {
    if (mongoTemplate.collectionExists("problem_metadata")) return

    jdbcTemplate.queryForList(
        "SELECT id, schema_metadata FROM problems WHERE schema_metadata IS NOT NULL"
    ).forEach { row ->
        val doc = Document("problemId", row["id"])
            .append("schemaMetadata", parseJson(row["schema_metadata"] as String))
        mongoTemplate.insert(doc, "problem_metadata")
    }

    jdbcTemplate.queryForList(
        "SELECT id, init_metadata, answer_metadata FROM test_cases " +
        "WHERE init_metadata IS NOT NULL OR answer_metadata IS NOT NULL"
    ).forEach { row ->
        val doc = Document("testCaseId", row["id"])
        row["init_metadata"]?.let { doc.append("initMetadata", parseJson(it as String)) }
        row["answer_metadata"]?.let { doc.append("answerMetadata", parseJson(it as String)) }
        mongoTemplate.insert(doc, "testcase_metadata")
    }
}

MySQL 쪽 정리

데이터가 MongoDB로 넘어간 뒤, Flyway가 JSON 컬럼을 제거합니다.

-- V6__remove_json_metadata_columns.sql
ALTER TABLE problems DROP COLUMN schema_metadata;
ALTER TABLE test_cases DROP COLUMN init_metadata;
ALTER TABLE test_cases DROP COLUMN answer_metadata;

이 시점에서 MySQL에는 정형 데이터만, MongoDB에는 메타데이터만 남습니다.

느낀 점

자동화된 마이그레이션은 수작업 대비 시간을 크게 단축시켰습니다. 데이터의 성격을 무시하고 하나의 DB에 모든 걸 맡기면, 결국 그 대가는 운영할 때 돌아온다는 점을 느꼈습니다..

SQL 채점 서비스의 문제 추천 성장기

osoohynn — Thu, 19 Mar 2026 09:01:11 +0900

SQL 채점 서비스 기획 배경

저는 마이스터고 학생으로, 백엔드 개발자를 목표로 공부하고 있습니다. 평소 SQL에 관심이 많아 꾸준히 학습해왔지만, 생각보다 SQL 실력을 체계적으로 향상시키는 것이 쉽지 않다는 것을 느꼈습니다.

또한 주변 동기나 후배들을 보면 API 개발에 집중하면서 ORM을 주로 사용하다 보니, 기본적인 JOIN 쿼리조차 직접 작성해본 경험이 부족한 경우가 많았습니다.

이러한 모습을 보며 “SQL을 직접 연습할 수 있는 환경이 조금 더 쉽게 제공된다면 좋지 않을까?”라는 생각이 들었습니다. 그래서 별도의 환경 설정 없이 바로 SQL을 실행하고 채점까지 받을 수 있는 학습 서비스를 만들게 되었습니다.

서비스가 궁금하다면? https://querify.dev

다른 블로그가 궁금하다면? https://osoohynn.tistory.com/14

SQL 실력을 향상시키려면

SQL 실력을 향상시키려면 어떻게 해야할까요?

알고리즘 공부를 예로 들어보겠습니다. 알고리즘 실력을 키우기 위해서는 자신의 실력보다 약간 어려운 문제를 반복적으로 푸는 과정이 중요합니다. 이는 알고리즘뿐 아니라 대부분의 학습 영역에서 공통적으로 적용되는 방식입니다.

문제 추천 시스템을 고민하게 된 이유

제가 알고리즘 문제를 풀면서 항상 느꼈던 고민이 하나 있습니다.

“지금 내 실력에 맞는 문제를 어떻게 찾지?”

너무 쉬운 문제는 실력 향상에 도움이 되지 않고, 너무 어려운 문제는 해결까지 시간이 오래 걸려 학습 흐름이 끊어집니다.

SQL 학습에서도 비슷한 문제가 발생할 것이라 생각했습니다. 사용자가 자신에게 적절한 난이도의 문제를 찾는 데 시간을 쓰기보다는, 문제 풀이 자체에 집중할 수 있는 환경이 필요했습니다.

그래서 사용자의 수준에 맞는 문제를 추천해주는 시스템을 서비스에 도입해보자는 아이디어가 떠올랐습니다. 궁극적인 목표는 단순히 문제를 푸는 것이 아니라, 사용자가 꾸준히 SQL을 연습하며 실력을 향상시키는 것입니다.이를 위해 사용자가 고민 없이 다음 문제를 풀 수 있도록 하여 문제 풀이 흐름을 끊지 않는 학습 경험을 제공하고자 했습니다.

우선 문제 추천 전에 유저 데이터를 분석했습니다. 우선 제가 예상했던 것처럼 유저 몇명의 행동 추적을 진행한 결과 문제를 연속적으로 풀지 않는 비율이 31%였고, 난이도가 비슷비슷한 문제만 계속 풀었습니다.

그럼 문제 추천 기능을 만들어서 이 가설을 검증해보려고 합니다! 너무 재밌을 것 같지 않나요?

구현 과정

단순히 난이도순으로 다음 문제를 보여주는 건 너무 단순하고, 유저마다 실력도 다르고 문제를 얼마나 쉽게 풀었는지도 다릅니다. 그래서 유저의 실력을 판단하는 요소로 지금까지 어떤 문제들을 풀었는가(제출 전체 조회)와 이번 문제를 얼마나 수월하게 풀었는가(풀이에 걸린 시간과 틀린 횟수) 둘을 블렌딩해서 지금 이 유저에게 가장 적절한 난이도를 추정하고, 거기에 가까운 문제를 찾습니다.

그리고 처음에는 문제를 맞춘 경우만 추천 문제를 보여주려 했으나 문제를 포기했을 경우에도 보여주면 새로 도전할 동기가 생길 것 같다고 생각했습니다. 따라서 문제를 맞혔을 때는 비슷하거나 더 어려운 난이도의 문제들을, 못 풀고 나가려 할 때는 비슷하거나 더 쉬운 문제들을 추천해주고자 하였습니다.

유저 실력 추정

전체 히스토리에서 가중 평균 난이도를 계산합니다. 우선 기존 문제의 난이도는 1~5였는데요, 이는 실제 실력은 분별하기에는 너무 좁은 범위였기에 추천 시스템이 잘 동작하지 않을 경우를 우려했습니다. 따라서 기존에 들어있던 문제의 난이도를 Claude 에게 분석하여 1~20으로 재정비하였습니다.

핵심은 분모의 1 + ln(wrongCount + 1)입니다. 틀린 횟수의 영향이 선형이 아니라 로그 스케일로 체감되기 때문에, 극단적인 케이스에서도 안정적으로 동작합니다.

난이도 5 문제 기준

	틀린 횟수	기여도
한 번에 정답	0회	5.0
어느 정도 시행착오	3회	3.6
많이 틀림	10회	2.7

또한 전체 제출이 아닌 최근 100건으로 제한한 이유는 응답 속도 확보와 함께, 최근 풀이 맥락이 실력을 더 잘 반영하기 때문입니다.

타겟 난이도 계산

현재 문제 난이도 D, 이번 문제 틀린 횟수 W를 기준으로 조정값 Δ를 계산합니다.

정답 시 (SOLVED)

W	Δ	의미
0	+2	완벽하게 풀었으니 두 단계 위로
1~2	+2	완벽하진 않지만 잘 풀었기에 두 단계 위로
3~5	+1	살짝 힘들었으니 한 단계만
6+	+0	많이 버벅였으니 같은 레벨

포기 시 (LEAVING)

전체 실력과 블렌딩해서 최종 타겟 난이도를 구합니다.

0.3 × (skill - D) 항이 현재 문제가 유저 실력 대비 너무 쉽거나 어려웠을 때를 보정합니다. 예를 들어 실력이 10인데 난이도 3짜리를 풀었다면 타겟이 위로 당겨집니다.

후보 문제 점수화

이미 맞춘 문제를 제외한 모든 문제에 대해 점수를 매깁니다.

난이도 적합도: 타겟과 가까울수록 높은 점수. 지수 1.5를 적용하여 거리가 멀어질수록 급격히 감소
인기도 보정: 다른 사용자가 많이 푼 문제에 약간의 가산점 (로그 스케일, 상한 20점)
재시도 패널티: 이전에 시도했다 실패한 문제는 후순위로 밀림 (완전 제외는 하지 않음)

상위 3문제를 단순 점수순으로 반환하지 않고, 타겟 난이도 근처 문제 2개 + 타겟보다 1~3단계 높은 도전 문제 1개로 구성합니다. 같은 난이도 내에서 동점인 후보들은 랜덤으로 선택하여 매번 다른 문제가 추천되도록 합니다. 도전 문제를 포함한 이유는 자신의 수준보다 약간 어려운 문제를 풀어야 실력이 향상된다는 심층 연습 원리에 기반합니다.

트리거 시점

GET /problems/{problemId}/recommendations?trigger=SOLVED
GET /problems/{problemId}/recommendations?trigger=LEAVING

SOLVED에는 채점 결과 정답을 받은 직후. 비슷하거나 더 어려운 문제를 추천
LEAVING에는 유저가 문제 페이지를 벗어나려 할 때. 비슷하거나 더 쉬운 문제를 추천

LEAVING은 문제를 구경만 하고 나가는 경우를 제외하기 위해, 1분 이상 체류한 경우에만 호출합니다.

복잡한 ML 없이 세 가지 직관적인 신호(전체 실력, 현재 퍼포먼스, 문제 인기도)를 수식으로 조합했습니다. 실력 추정에 로그 스케일 페널티를 쓴 게 핵심인데, 틀린 횟수의 영향이 선형이 아니라 체감되도록 설계해서 극단적인 케이스(100번 틀리고 맞춤)에도 안정적입니다.

며칠 후 구축해둔 로그 인프라를 통해 확인해보니 이탈율이 31% -> 21%로 감소하였습니다~!!

느낀 점 및 회고

문제 추천 같은 경우에는 제 스스로 정말 좋다라고 느끼는 공식을 적용해서 만들었습니다. 이후에는 유저를 더 수집해보고 A/B테스트 환경을 구축하고 어떤 공식과 어떤 문제들이 실력향상에 유의미한 영향을 주는지 통계를 낼 것입니다. 이 통계는 유저에게 전달해주어도 동기부여 요소로서 흥미로운 포인트가 될 것 같네요!!

꾸준히 운영하고 데이터를 수집하여 성과가 나오거나 재미있는 사실을 발견한다면 블로그 업데이트 하겠습니다. :) 저는 얼른 홍보 자료도 제작을 해서 SQL에 관심있는 더 많은 분들이 서비스를 통해 성장할 수 있었으면 좋겠습니다!

SQL 채점 서비스 부하 테스트로 발견한 Deadlock과 성능 병목 해결기

osoohynn — Tue, 17 Mar 2026 08:54:02 +0900

서비스: https://querify.dev

기존 서비스 아키텍처

운영 중인 Querify 서비스는 저희 집에 직접 구축한 미니PC 기반 온프레미스 서버에서 운영되고 있었습니다.

조금 어지럽긴 하지만.. 서비스 아키텍처입니다!

Spring Boot API 서버가 클라이언트 요청을 받으면, 일반 조회는 메인 MySQL에서 처리하고, 채점 요청은 별도의 Sandbox MySQL에서 사용자 SQL을 실행하는 구조입니다. Sandbox DB는 채점마다 테이블을 생성하고 테스트 데이터를 삽입한 뒤, 사용자 쿼리를 실행하여 정답과 비교합니다.

설계하면서 가장 많이 고려한 점이 채점 로직입니다. 사용자가 제출한 SQL을 메인 DB에서 직접 실행하면 실제 서비스 데이터를 훼손할 수 있고, 무거운 쿼리가 다른 API의 응답 시간에 영향을 줄 수 있습니다.

채점 SQL 격리 및 위험 쿼리 제한

Sandbox DB를 분리함으로써 채점용 SQL 실행이 서비스 데이터에 영향을 주지 않도록 격리하고, 메인 DB의 커넥션 풀을 채점 요청이 점유하지 않도록 부하를 분산했습니다.
또한 Sandbox DB에 접근하기 이전에 JsqlParser를 이용해 SELECT문만 가능하도록 필터링했습니다.

fun validate(query: String) {
    val statement = try {
        CCJSqlParserUtil.parse(query)
    } catch (e: Exception) {
        throw BusinessException(GradingErrorCode.INVALID_SQL_SYNTAX)
    }

    if (statement !is Select) {
        throw BusinessException(GradingErrorCode.FORBIDDEN_SQL_STATEMENT)
    }
}

Sandbox권한은 readonly로 설정하여 SELECT 요청만 허용하도록 했습니다.

CREATE USER 'sandbox_readonly'@'%' IDENTIFIED BY 'sandbox_readonly';
GRANT SELECT ON sandbox.* TO 'sandbox_readonly'@'%';
FLUSH PRIVILEGES;

마지막으로 기존 존재하던 ELK 스택에서 채점 요청만 모아서, 매일 정해진 시간에 SQL Injection 의심 쿼리를 디스코드로 발송하는 n8n 워크플로우를 만들었습니다. 이를 통해 지속적으로 의심 쿼리를 제출하는 사용자를 탐지하고 제재할 수 있습니다.

부하테스트 배경

사용자가 늘어난다면 채점 요청에 병목이 발생하지 않을까?

SQL 채점 서비스는 여러 사용자가 동시에 문제를 풀고 쿼리를 실행하는 환경입니다. 사용자가 제출 버튼을 눌렀는데 채점이 늦게 되거나 서비스가 멈춘다면 학습 경험이 크게 떨어질 수 있습니다.

특히 SQL 채점은 단순 요청이 아니라 DB 실행, 결과 비교, 채점 로직 처리까지 포함되기 때문에 동시에 많은 요청이 들어올 경우 서버와 데이터베이스에 큰 부하가 발생할 수 있습니다.

따라서 실제 사용자들이 동시에 문제를 제출하는 상황을 가정하여 부하테스트를 진행했고, 이를 통해 병목이 발생하는 지점을 미리 파악하고 개선하고자 했습니다.

부하테스트

부하테스트 환경

부하테스트는 AWS EC2 + k6 환경에서 진행했습니다. 기존 미니PC에서는 다른 프로그램도 동작하고 있었고, 부하테스트 중 서버가 다운되더라도 빠르게 복구할 수 있는 EC2 환경이 더 적합하다고 판단했습니다.

인스턴스는 미니PC와 비슷한 스펙의 t4g.medium을 고려했으나, 더 작은 환경에서도 버틸 수 있다면 프로덕션에서의 안정성을 더 높은 수준으로 보장할 수 있을 것 같아 t4g.small(vCPU 2개, 메모리 2GB)을 선택했습니다.

첫 부하테스트는 퍼블릭 IP를 통해 요청을 보냈기 때문에 측정된 latency에 네트워크 구간이 포함되어 있습니다. 이번 부하테스트의 목적은 서버 내부 병목을 더 정확히 측정하는 것이였기 때문에, 같은 VPC 내 프라이빗 IP로 요청하는 것이 적절하다는 것을 알게되었습니다. 다음부터는 부하 테스트 목적에 맞게 적절한 네트워크 환경을 구축해야겠다는 점을 알게 되었습니다.

EC2에 데이터를 마이그레이션한 후, Prometheus + Grafana로 모니터링 대시보드를 구성했습니다. Spring Boot Actuator + Micrometer를 통해 HTTP 응답 시간(p95/p99), RPS, 에러율과 함께 HikariCP 커넥션 풀 상태(active/pending)를 수집했습니다.

1차 부하테스트: 고부하 (초당 30~100 요청)

k6 스크립트는 두 가지 시나리오로 구성했고 타깃 API는 문제 전체 조회와 제출, 제출 조회입니다.

export const options = {
  scenarios: {
    // 시나리오 1: 평상시 트래픽 (3분)
    normal_load: {
      executor: 'constant-arrival-rate',
      rate: 30,            // 초당 30 요청
      timeUnit: '1s',
      duration: '3m',
      preAllocatedVUs: 50,
      maxVUs: 100,
    },
    // 시나리오 2: 스파이크 (3분)
    exam_end_spike: {
      executor: 'ramping-arrival-rate',
      startRate: 30,
      timeUnit: '1s',
      stages: [
        { duration: '30s', target: 100 },  // 30초간 3배 급증
        { duration: '2m', target: 100 },   // 2분간 피크 유지
        { duration: '30s', target: 30 },   // 정상화
      ],
      preAllocatedVUs: 200,
      maxVUs: 300,
      startTime: '3m',
    },
  },
};

평상시 초당 30 요청을 3분간 유지한 뒤, 초당 100 요청으로 급증시키는 시나리오입니다. 총 6분간의 테스트를 진행하려는 도중 스파이크 구간에서 서버가 다운되었습니다.

지표	측정값
p95 latency	4,901ms
p99 latency	10,000ms (타임아웃)
Error rate	26.28%
RPS	41.8/s
총 처리 건수	8,072건 (중간에 다운)

부하테스트 결과 분석

실행계획 분석

가장 먼저 의심한 것은 DB 쿼리입니다. 채점 결과 조회는 가장 자주 호출되는 API 중 하나이므로, 이 쿼리에 EXPLAIN ANALYZE를 실행해보았습니다.

기존 인덱스 현황은 다음과 같았습니다.

인덱스명	구성
PRIMARY	id
idx_user_id	user_id
idx_problem_user	problem_id, user_id
idx_deleted_at	deleted_at

(다른 용도로 만든 인덱스) idx_problem_user(problem_id, user_id)로 problem_id 필터는 성공했지만, created_at 정렬을 커버하지 못했습니다.

자세히 살펴보면, 채점 결과 조회 요청에 페이지네이션을 적용하여서 최신 20건만 가져오면 되는데 인덱스에 정렬 정보가 없으니까 일단 전부(6,933행) 읽고 → 정렬하고 → 20개 자르는 비효율적인 방식으로 동작했습니다. 이는 데이터가 쌓일수록 느려지는 구조였습니다.

커넥션 풀 포화

Grafana를 확인해보니, HikariCP의 pending(커넥션 대기 수)이 180건 이상으로 치솟는 것이 보였습니다. 기본 커넥션 풀 크기인 10개로는 동시 요청을 감당하기 어려웠고, 커넥션을 얻지 못한 스레드가 기본 타임아웃 30초 동안 묶이면서 톰캣 스레드 풀까지 연쇄적으로 고갈되면서 최종적으로 서버가 다운되었습니다.

max-pool-size 기본값 10개에 동시 요청이 몰리면, 10개의 커넥션이 전부 사용 중일 때 나머지 요청은 대기합니다. 이때 connection-timeout 기본값이 30초이므로, 커넥션을 못 얻은 스레드가 30초 동안 묶이면서 톰캣 스레드 풀까지 연쇄적으로 고갈, 최종적으로 서버가 다운된 것이었습니다.

인덱스, 커넥션 풀 튜닝

Index 추가

최신 20건을 판단하는 방법이 created_at이였기 때문에 해당 컬럼에 인덱스가 필요했습니다. 따라서 문제와 제출 시점을 순서로 idx_submission_problem_created 복합 인덱스를 생성했습니다.

추가로 커버링 인덱스도 검토했으나 현재 조회가 전체 컬럼을 반환하기 때문에 커버링 인덱스를 구성하려면 모든 컬럼을 인덱스에 포함해야 하며, 이는 인덱스 크기가 테이블과 거의 동일해져 오히려 INSERT 성능을 저하시킨다고 판단하고 배제했습니다.

커넥션 풀 사이즈와 타임아웃 수정

DB 커넥션 풀 사이즈는 HikariCP wiki의 풀 사이징 가이드라인 connections = ((core_count * 2) + effective_spindle_count)을 참고하여 튜닝했습니다. vCPU 2개 기준으로 약 5개가 권장값이지만, 채점 요청이 sandbox DB에서 SQL을 실행하는 동안 커넥션을 오래 점유하는 I/O 바운드 특성을 감안하여 20으로 설정했습니다.
한편 커넥션을 획득하지 못한 요청이 장시간 대기하며 톰캣 스레드를 점유하지 않도록 connectionTimeout을 3초로 설정해 빠르게 실패하도록 구성했습니다. 이를 통해 커넥션 풀 고갈 상황이 전체 요청 처리 지연으로 확산되는 것을 방지했습니다.

결과

인덱스 추가로 쿼리 실행 시간이 26.2ms에서 0.05ms로 99.8% 단축되고, 스캔 행 수 6,933행에서 20행으로 감소하였습니다.

RPS는 41.8/s에서 84.7/s로 103% 향상, 총 처리 건수도 8,072건에서 15,351건으로 90% 증가하였으며,
p95 latency는 4,901ms에서 3,536ms로 28% 개선, p99는 10,000ms(타임아웃)에서 4,830ms로 52% 개선되었습니다.

SubmissionCount 증가 문제 해결

인덱스 추가와 커넥션 풀 튜닝을 적용한 뒤, 동일한 시나리오로 부하테스트를 재진행했습니다.

지표	Before	After (인덱스+풀)
p95 latency	4,901ms	3,536ms
p99 latency	10,000ms (타임아웃)	4,830ms
median	92ms	888ms
성공 요청 median	45ms	596ms
Error rate	26.28%	31.02%
RPS	41.8/s	84.7/s
처리 건수	8,072건 (다운)	15,351건 (생존)

서버가 다운되지 않고 끝까지 생존했고, RPS가 41.8에서 84.7로 약 2배 향상되었습니다. 에러율이 31%로 오히려 높아진 것처럼 보이지만, Before에서는 서버가 중간에 다운되어 이후 요청이 집계되지 않은 반면 After에서는 끝까지 살아남아 2배 많은 요청을 처리한 결과입니다.

그러나 에러율 31%는 여전히 높았습니다. 인덱스와 커넥션 풀 외에 다른 병목이 있다는 의미입니다.

앱 에러 로그를 분석한 결과, Deadlock이 다수 발생하고 있었습니다.

MySQLTransactionRollbackException: 
Deadlock found when trying to get lock; try restarting transaction

at ProblemRepositoryImpl.incrementSubmittedCount()

원인은 채점 제출 시 호출되는 incrementSubmittedCount()에 있었습니다. 이 메서드는 매 요청마다 problem 테이블의 동일 행에 UPDATE SET submissionCount = submissionCount + 1을 실행합니다.

원인은 InnoDB의 FK 제약 체크 메커니즘에 있었습니다. INSERT INTO submissions 실행 시, InnoDB는 FK로 참조하는 problem 행의 존재를 확인하기 위해 해당 행에 S Lock(공유 락)을 자동으로 설정합니다. S Lock끼리는 호환되므로 동시에 여러 트랜잭션이 같은 problem 행에 S Lock을 획득할 수 있습니다. 문제는 그 다음입니다. 각 트랜잭션이 UPDATE problem SET submissionCount = submissionCount + 1을 실행하려면 같은 행에 X Lock(배타 락)이 필요한데, 상대방이 이미 잡고 있는 S Lock이 해제될 때까지 기다려야 합니다. 두 트랜잭션이 서로의 S Lock 해제를 기다리는 순환 대기가 형성되면서 Deadlock이 발생한 것입니다.

Deadlock 시퀀스 다이어그램

트랜잭션 A:
  1. INSERT INTO submissions
     → FK 제약 체크를 위해 problem 행에 S Lock 획득 ✅
  2. UPDATE problem SET submissionCount = submissionCount + 1
     → 같은 problem 행에 X Lock 요청 → B의 S Lock 때문에 대기

트랜잭션 B:
  1. INSERT INTO submissions
     → FK 제약 체크를 위해 같은 problem 행에 S Lock 획득 ✅
     (S Lock끼리는 호환되므로 둘 다 성공)
  2. UPDATE problem SET submissionCount = submissionCount + 1
     → 같은 problem 행에 X Lock 요청 → A의 S Lock 때문에 대기

A는 B의 S Lock 해제를 기다리고, B는 A의 S Lock 해제를 기다림
→ 순환 대기 발생 → Deadlock

단위 테스트나 코드 리뷰에서는 발견하기 어려운 문제였습니다. 실제로 동시 요청이 몰리는 환경에서만 드러나는 동시성 버그였고, 부하 테스트를 하지 않았다면 프로덕션에서 처음 마주쳤을 것으로 예상합니다.

Dead Lock 해결

처음엔 실시간 COUNT 쿼리로 대체하는 방법을 고려했습니다. submissionCount 컬럼을 제거하고 필요할 때마다 SELECT COUNT(*)로 직접 계산하는 방법입니다. UPDATE 자체가 사라지므로 Deadlock은 해결이 됩니다. 다만 제출 데이터가 쌓일수록 COUNT 비용이 증가하고, 문제 목록에서 문제 20개의 문제에 제출 수를 보여주려면 COUNT를 20회 실행해야 한다. 데이터가 수십만 건 이상 쌓이면 목록 조회 한 번에 수 초가 소요될 수 있어 장기적으로는 좋지 않은 판단이라고 생각했습니다.

Kafka 등 메시지 큐를 이용해 비동기 처리 하는 방법도 있었습니다. Deadlock 없이 정확한 카운트를 유지할 수 있지만, 정수 하나를 증가시키기 위해 메시지 브로커를 경유하는 것은 현재 상황에선 오버엔지니어링이라고 생각했습니다.

채택된 방법은 Redis입니다. Redis의 INCR는 원자적으로 처리되므로, 동일 키에 대한 동시 증가 요청을 안전하게 누적할 수 있었습니다. 부가적으로 응답 시간이 1ms 미만이라 사용자 체감 지연도 없으며, 구현도 기존 UPDATE문 한 줄을 Redis INCR 한 줄로 교체하는 수준이어서 변경 범위가 최소화됩니다.

제출 수 증가 방식 비교

특히 제출 건수는 실제 제출 레코드에서 언제든 정확한 값을 복구할 수 있는 통계성 데이터이므로, 강한 정합성 대신 최종 정합성으로 충분하다고 판단했습니다.

Redis로 제출 횟수를 저장하는 구조 설계

누적된 카운트는 스케줄러가 1분 주기로 DB에 동기화합니다.
이때 get → DB 반영 → decrement 순서로 처리하여, DB 업데이트가 실패하더라도 Redis에 값이 남아 다음 주기에 재시도되도록 설계했습니다.
getAndDelete로 한 번에 가져오고 삭제하는 방식도 검토했으나, Redis에서 삭제 후 DB 반영 전에 서버가 다운되어있다면 카운트가 유실되는 문제가 예상되어 배제했습니다.

Redis INCR 적용 후 동일 시나리오로 부하테스트를 재진행했는데요, Deadlock이 제거되어 에러율이 31%에서 19%로 감소했습니다. 성공한 요청의 median latency는 596ms에서 18ms로 97% 개선됐습니다.

테이블 이름 중복 문제 해결

Deadlock 해결 후에도 에러율이 19%로 남아있어 앱 에러 로그를 다시 확인했습니다. Deadlock 예외는 사라졌지만, sandbox DB 관련 에러가 발생하고 있었습니다. QueryExecutor 코드를 확인한 결과, 모든 채점 요청이 같은 sandbox DB에서 동일한 테이블명으로 DROP → CREATE → INSERT → SELECT를 실행하는 구조였습니다. 동시에 채점 A가 테이블을 생성하고 데이터를 삽입하는 사이에 채점 B가 같은 테이블을 DROP하면서 충돌이 발생한 것입니다.

문제는 에러 뿐만 아니라 데이터 정합성이였습니다. 기존 구조에서는 동시 채점 시 다른 사용자의 데이터가 섞여 채점 결과가 틀릴 수 있는 치명적 문제가 존재한 것입니다.

MySQL의 DDL은 일반 DML과 달리 implicit commit을 유발하거나 트랜잭션 원자성을 깨뜨릴 수 있어, 단순 트랜잭션 처리만으로는 동시 채점 간 DDL 충돌을 안전하게 제어하기 어려웠습니다.

해결 방안 탐색

락을 도입하기에는 채점 자체가 SQL 실행과 결과 비교를 포함하는 무거운 작업이라 직렬화 시 대기 시간이 크게 증가하여 부하 테스트의 개선 의미가 사라진다고 판단했습니다

채점 요청마다 새 Docker 컨테이너를 띄워 완전히 격리하는 방법도 고려했으나, 컨테이너 기동 오버헤드가 수 초 단위로 발생하고 메모리 점유량도 커서 현재 인프라에서는 적합하지 않았습니다. 다만 컨테이너 기반 샌드박스는 보안 격리 측면에서 장점이 있으므로, 향후 스키마 분리 방식과 장단점을 비교하여 도입을 검토할 계획입니다.

최종적으로 채점 요청마다 고유한 스키마를 동적으로 생성하여 물리적으로 격리하는 방식을 선택했습니다. 각 채점은 자신만의 스키마에서 테이블 생성, 데이터 삽입, SQL 실행을 수행하고 완료 후 스키마를 삭제합니다. 서로 다른 공간에서 작업하므로 동시 100명이 채점해도 충돌이 구조적으로 발생하지 않습니다.

수정 후 마지막으로 부하테스트를 진행하였습니다.

지표	Before	After
median	92ms	26ms
성공 요청 median	45ms	17ms
Error rate	26.28%	15.13%
RPS	41.8/s	48.5/s
Deadlock	다수	0건
sandbox 충돌	발생	0건
서버 상태	다운	생존

수치만 비교하자면 첫 결과에서 드라마틱한 차이는 보이지 않습니다. 이는 첫 부하테스트에는 스파이크 테스트 직후 다운되어 처리되지 못한 요청이 많다는 점을 감안해야합니다. 인덱스, 커넥션 풀, 원자적 증가, schema 분리 등의 튜닝 후 정확성과 안정성 모두 확보하면서, 성능까지 개선된 성과가 있습니다.

스키마 풀

지금까지의 개선을 통해 서버 다운, Deadlock, sandbox 충돌 문제는 해결할 수 있었고 성공 요청 latency도 크게 개선되었습니다. 하지만 최종 부하 테스트에서도 에러율은 15%가 남아 있었습니다.

남아 있던 에러율의 주요 원인은 채점 작업의 동시 실행 수가 제어되지 않는 점에 있었습니다. 지금 방식에서는 적당한 동시 실행 개수를 구하는 공식이 따로 없기 때문에 확인해야할 부분이였습니다.

또한 기존 방식은 DDL 비용이 매 채점마다 반복된다는 한계가 있었습니다. 따라서 동시 실행 수를 제한하는 것만으로는 남아 있던 오버헤드를 줄이기 어렵다고 판단했고, 이를 해결하기 위해 미리 생성한 sandbox 스키마를 재사용하는 pool 구조를 선택했습니다. 따라서 Kafka consumer 측에서 동시 실행 가능한 채점 수를 sandbox 개수와 동일하게 제한했습니다.

스키마 풀 구조

val schemaName = "sandbox_${Thread.currentThread().id}_${System.nanoTime()}"
...
try {
    adminDataSource.connection.use { conn ->
        conn.createStatement().execute("DROP DATABASE IF EXISTS `$schemaName`")
    }
}

val schemaName = schemaPool.acquire()
...
try {
    schemaPool.release(schemaName)
}

앱 기동 시 sandbox_pool_0 ~ sandbox_pool_N 스키마를 미리 생성해두고 ArrayBlockingQueue로 관리합니다. 채점 요청이 들어오면 acquire()로 유휴 스키마를 빌려 채점을 수행하고, 완료 후 release()로 반납합니다. CREATE/DROP DATABASE는 기동 시 1회만 수행되며, 이후 채점은 이전 테이블을 DROP하고 새로 생성하는 테이블 레벨 초기화만 수행합니다. 또한 Kafka consumer의 concurrency를 풀 사이즈와 동일하게 설정해, 풀이 고갈될 상황 자체를 구조적으로 차단했습니다.

그 결과 채점 실패율이 15% → 4.64% 로 감소했고, 전체 처리 건수도 무려 21,231으로 증가했습니다.

지표	스키마 생성 방식	스키마 풀 방식
Error rate	15.13%	4.64%
RPS	48.5/s	70.31/s

느낀 점 & 회고

우선 부하테스트를 할 때 같은 VPC내에서 진행하지 못한 점이 아쉬웠습니다. 이 경험을 통해 다음에는 부하테스트 목적에 맞게 환경을 구성할 수 있도록 노력할 예정입니다. 커넥션 풀 사이즈도 테스트해보고 개선이 되었다고 느꼈는데, 공식을 적용해보거나 임의의 숫자로 조정해보며 공식이 의미가 있는지 그리고 몇개가 가장 최적값인지 확인해보았더라면 더 좋을 것 같습니다!

코드만으로는 발견하기 어려운 운영 환경의 문제들을 간접적으로 경험할 수 있어 의미 있는 경험이었습니다. 문제를 발견했을때, 해결 방법을 가설로 세우고 여러 가지 시도를 해보며 어떤 방법이 가장 최선이였는지를 판단하는 과정들이 뿌듯했습니다.

아직 많이 부족하지만 읽어주셔서 감사합니다! 어색한 부분이나 더 좋은 의견이 있다면 편하게 댓글 남겨주세요. :)

백엔드 Push 한 번에 프론트 PR이 날아옵니다: 백엔드 개발자가 도전한 Claude+Git Action 웹 개발 자동화

osoohynn — Wed, 11 Mar 2026 20:25:59 +0900

개발 중인 프로젝트 소개

제가 개발하고 있는 SQL 학습자가 직접 쿼리를 작성하고 즉시 채점받을 수 있는 온라인 저지 서비스 Querify입니다.

기존 SQL 학습은 로컬 DB를 직접 세팅해야 하거나, 정답 확인이 수동으로 이루어지는 불편함이 있었습니다. Querify는 문제별로 격리된 sandbox DB 환경을 제공하여 별도 환경 구축 없이 브라우저에서 SQL을 실행하고, 정답 결과셋과 비교하여 즉시 결과를 받을 수 있도록 설계했습니다.

SQL 실행 환경을 안전하게 분리하는 구조를 직접 설계해보고 싶었습니다.
또한 평소 관심이 있던 SQL 학습 도메인으로 프로젝트를 만들고, 실제 데이터를 기반으로 사용자 경험을 개선해보고 싶었습니다.

자동화의 배경

웹 개발 자동화가 왜 필요했을까요?

저는 백엔드를 주로 하고 있는 개발자입니다. 웹개발보다는 백엔드를 위주로 집중해서 프로젝트를 개발해나가고 있었고, 웹의 경우에는 Claude Code를 사용하여 디자인 및 개발을 진행했습니다.

Querify를 활발하게 개발하다보니 백엔드 API가 자주 변경되었고, 그때마다 프론트 코드를 반복적으로 수정해야 했습니다.

API 변경 → Claude 프롬프트 작성 → Claude 계획 & 실행 → 프론트 Code Push

서버에서 API 사용흐름을 변경하게 된다면, 변경이 된 부분을 찾아서 다시 웹코드를 열고, Claude Code를 통해 수정해야한다는 번거로움이 있었습니다. 같은 작업을 10번 정도 반복하고 나니, “이 부분은 자동화를 해도 되겠는데?” 라는 생각이 들었습니다. 실제로 Git API를 사용해본 경험이 있었기에 충분히 가능할 것이라고 생각했습니다.

계획

우선 전체적인 흐름을 먼저 정의해보았습니다. n8n과 Git Actions로 CI/CD 파이프라인을 설계하던 경험을 살려, 다음과 같이 구성해보았습니다.

[백엔드 커밋 & 푸쉬] → [Claude: API 변경 내용 탐지]
→ [변동사항 있다면 Claude 계획 수립 및 개발] → [웹 코드 Branch Push 및 변경 내용 알림]
→ [개발자 수락] → [Branch Merge]

백엔드에서 main Branch에 Push가 일어나면 Claude를 이용해 API 변경 내용이 있는지 탐지하고 Pull Request를 생성하고 개발자에게 검토 요청을 보냅니다. 그다음 제가 그 요청을 수락하면 브랜치에 머지되는 구조로 생각했습니다.

워크플로우 환경 구축

가장 크게 파이프라인을 구축하는 툴을 선택해야했습니다. 만약 팀 프로젝트였다면 팀원 모두 유지보수가 가능하게 팀원간 상의가 필요했겠지만, 1인 프로젝트였기 때문에 기술 선택에 있어 다른 관점의 판단이 필요했습니다.

GitHub관련 자동화 파이프라인을 구축하는 방법으로 세가지를 생각했습니다.

n8n, Git Actions, 코드 방식

우선 n8n은 자동화를 할 때 가장 많이 사용하는 툴이였습니다. 기본으로 제공되는 API도 많고 GUI이기 때문에 편리하게 이용할 수 있습니다. n8n을 사용한다면 저희 집에 On-Premise Server에서 돌아갈 것이라 큰 위험은 없었지만 다운될 수 있다는 우려는 있었습니다.

Git Actions는 GitHub에서 공식적으로 제공하는 CI/CD 툴입니다. 따라서 별도의 인프라가 불필요하고, 처음 구축하는 시간이 단축된다는 장점이 있었습니다.

직접 코드를 짜는 방식도 생각해보았습니다. API서버와 분리해야한다고 생각하여, 만약 구축한다면 별도의 프로젝트와 인프라가 필요하다고 판단했습니다. 커스텀하기에는 가장 좋은 방법이지만 workflow 자체가 비동기처리나 병렬처리 없이 순차적으로 실행하는 구조이기에 커스텀의 장점이 크게 매력적으로 다가오지 않았습니다.

따라서 n8n과 GitHub Actions 두 개 중에 고민하였습니다. GitHub Actions는 백엔드 레포에 만든다 가정했을때, 프론트 코드에 접근하는 방법이 안전하지 않고, 프론트에게 트리거를 주는 이중 트리거를 구성하기에는 코드 방식과 불편한 정도가 비슷하다고 느꼈습니다. 자주 사용하는 툴임도 고려했을 때 n8n이 가장 적합하다고 생각하여 n8n workflow를 구성하기로 정했습니다.

워크플로우 설계

워크플로우를 설계하면서 막혔던 부분이 있습니다. 백엔드의 API가 어떤게 변경이 되었는지는 알겠는데 프론트에서 어디를 수정해야할지 모른다는 문제가 있었습니다. 매번 GitHub API로 코드베이스를 탐색하는 것은 무겁고, 대신 프론트 구조 요약을 해두자니, 바뀔 때마다 업데이트를 해야하고 정확한 파일내용까지는 읽을 수 없다는 문제가 예상됐습니다.

GitHub API로 트리 조회 후 변경 필요해보이는 파일만 열어볼까? 라는 방법도 생각했는데 변경 필요해보이는 부분만 고르는 데에 또 한 스텝 더 생기고 정확도가 떨어진다고 판단했습니다. 그렇다면 모든 코드를 읽을 수 있으면서도 매번 API호출을 하지 않아도 되게 n8n내에 프로젝트를 클론해두기로 결정했습니다.

n8n 시도

결론적으로는 n8n을 사용하지 못했습니다.

Claude를 통해 수정 또는 생성할 내용을 찾아 파일 목록을 추출하는 데까지는 성공했으나 n8n에서 제공하는 GitHub 노드가 Edit 또는 Create file만 제공하였고, 한 번에 한 파일만 다룰 수 있다는 한계가 있었습니다.

구체적으로는 다음과 같습니다

Claude API 응답 파싱이 까다로웠다

n8n의 Claude 노드 응답은 { content: [{ type: "text", text: "..." }] } 구조로 감싸져 있어서, 순수 JSON을 요청해도 한 번 벗겨내야 했습니다. 거기에 Claude가 마크다운 코드블록이나 설명을 붙이면 파싱이 깨졌고, 이걸 처리하는 Code 노드를 따로 만들어야 했습니다.

여러 파일을 GitHub에 올리는 게 복잡했다

Claude가 반환한 files 배열을 개별 아이템으로 쪼개는 Split 노드, 기존 파일의 sha를 가져오는 Get 노드, 실제로 수정하는 Edit 노드 파일 하나 올리는 데 노드가 3개씩 필요했습니다. 특히 GitHub API의 sha(파일의 버전 해시로, 수정 시 충돌 방지를 위해 필요) 때문에 빠르게 진행하기가 어려웠습니다.

Shell 명령어를 쓸 수 없었다

결정적이었습니다. Clone으로 저장한 프론트엔드 코드를 읽으려면 grep이나 fs.readFileSync 같은 걸 써야 하는데, n8n에선 불가능했습니다. 모든 파일 접근을 GitHub API의 HTTP Request로 해야 했고, 파일 트리 조회 → 필터링 → 각 파일 내용 가져오기를 전부 노드로 만들면 10개가 넘어갔습니다.

Github Actions로 전환

n8n workflow가 적합할 것이라 생각했으나 막상 구현을 하니 까다로운 부분이 있었습니다. 만약 여러 방법으로 시도를 하더라도 유지보수 측면에서 적절치 않을 듯 하여 차선안이였던 GitActions를 도전하기로 했습니다. 막상 도입을 해보니 단점이라고 우려했던 오히려 장점이 된듯하여 편리함과 개발 속도에서 좋은 느낌을 받았습니다.

우선 백엔드 Push Trigger를 설정했습니다. main Branch에 Push가 일어나면 github.event.before 과 github.event.after로 변경점을 찾아 프론트엔드에게 전달했습니다. 처음에 구상했던 개발자 수락 -> 머지 부분은 제외했는데요, 직접 코드리뷰를 하는게 간단하고 정확할 것 같아서 제외했습니다.

name: Notify Frontend
on:
  push:
    branches: [main]

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Send to frontend
        env:
          GH_TOKEN: ${{ secrets.FRONTEND_DISPATCH_TOKEN }}
        run: |
          DIFF=$(git diff ${{ github.event.before }} ${{ github.event.after }})
          MSG=$(git log --oneline ${{ github.event.before }}..${{ github.event.after }} | tr '\n' ' ')
          gh api repos/sql-onlinejudge/soj-frontend/dispatches \
            -f event_type="backend-updated" \
            -f "client_payload[diff]=$DIFF" \
            -f "client_payload[commit_message]=$MSG"

그다음은 프론트엔드에서 backend-updated Trigger를 수신하여 이를 실행합니다. 해당 프로젝트에서는 repository_dispatch를 사용했습니다. repository_dispatch는 외부 시스템이 GitHub에 이벤트 보내서 실행하는 구조인인데요, 다른 자동화에서도 적용시켜보고 싶은 부분입니다.

name: Sync Frontend from Backend Changes
on:
  repository_dispatch:
    types: [backend-updated]
    # payload: { commit_message, diff, repo }

jobs:
  update:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4

      - name: Analyze & Update
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          BACKEND_DIFF: ${{ github.event.client_payload.diff }}
          COMMIT_MSG: ${{ github.event.client_payload.commit_message }}
        run: node scripts/sync-backend.js

      - name: Save commit msg
        run: echo "COMMIT_MSG=${{ github.event.client_payload.commit_message }}" >> $GITHUB_ENV

      - name: Create PR
        id: cpr
        uses: peter-evans/create-pull-request@v5
        with:
          branch: ai/update-api-${{ github.run_number }}
          title: "AI: 백엔드 API 변경 반영"
          body: |
            백엔드 변경에 따른 프론트엔드 자동 업데이트
            
            **커밋:** ${{ env.COMMIT_MSG }}
          commit-message: "feat: backend API 변경 반영"
            
      - name: Save PR URL
        if: ${{ steps.cpr.outputs.pull-request-url }}
        run: echo "PR_URL=${{ steps.cpr.outputs.pull-request-url }}" >> $GITHUB_ENV
            
      - name: Notify Discords
        if: ${{ env.PR_URL != '' }}
        run: |
          curl -H "Content-Type: application/json" \
            -d "{\"content\": \"  **프론트엔드 자동 업데이트 PR 생성됨**\n커밋: ${{ github.event.inputs.commit_message }}\nPR: ${PR_URL}\n\n리뷰 후 머지해주세요.\"}" \
            ${{ secrets.DISCORD_WEBHOOK_URL }}

처음 구조는 workflow 내부에서 Claude API호출과 프롬프트 텍스트를 전부 저장하는 구조였습니다.

하지만 두가지 문제가 있었습니다.

첫번째로는 GitHub Actions에서 인라인 스크립트가 ESM/CommonJs 호환 문제를 겪어서 별도 스크립트 파일로 분리하는 게 깔끔하다고 생각했습니다.

두번째로는 사소하지만 Git Actions 파일에 모든 내용을 넣다보니 파일이 길어져서 가독성이 안 좋아졌고 유지보수하기에 어려움을 겪을 것으로 예상했습니다.

그래서 scripts/sync-backend.js 파일을 제작했습니다. 백엔드에서 API 수정이 아닌 ‘생성’의 경우에는 그에 맞는 페이지와 디자인이 필요했기 때문에 이 파이프라인에서는 수정만 다루기로 결정했습니다.

function findMatchingBrace(text, startIndex) {
  let depth = 0;
  let inString = false;
  let escape = false;
  for (let i = startIndex; i < text.length; i++) {
    const ch = text[i];
    if (escape) { escape = false; continue; }
    if (ch === '\\' && inString) { escape = true; continue; }
    if (ch === '"') { inString = !inString; continue; }
    if (inString) continue;
    if (ch === '{') depth++;
    if (ch === '}') { depth--; if (depth === 0) return i; }
  }
  return -1;
}

import fs from 'fs';
import path from 'path';

try {
  console.log('=== START ===');
  console.log('COMMIT_MSG:', process.env.COMMIT_MSG);
  console.log('DIFF length:', process.env.BACKEND_DIFF?.length);

  function getFiles(dir) {
    let results = [];
    for (const f of fs.readdirSync(dir, { withFileTypes: true })) {
      const full = path.join(dir, f.name);
      if (f.isDirectory() && !f.name.includes('node_modules')) {
        results = results.concat(getFiles(full));
      } else if (f.name.endsWith('.ts') || f.name.endsWith('.tsx')) {
        results.push(full);
      }
    }
    return results;
  }

  const files = getFiles('src');
  console.log('Found files:', files.length);

  const fileContents = files.map(f =>
    `--- ${f} ---\n${fs.readFileSync(f, 'utf-8')}`
  ).join('\n\n');

  console.log('Total content length:', fileContents.length);
  console.log('Calling Claude API...');
    
  const prompt = `당신은 시니어 프론트엔드 개발자입니다.
백엔드 API가 변경되었습니다. 아래 diff를 분석하고 프론트엔드 코드를 수정하세요.

## 백엔드 커밋 메시지
${process.env.COMMIT_MSG}

## 백엔드 코드 변경사항 (git diff)
${process.env.BACKEND_DIFF}

## 현재 프론트엔드 코드
${fileContents}

## 분석 순서
1. diff에서 변경된 API 엔드포인트, 요청/응답 필드, 파라미터를 파악하세요
2. 프론트엔드 코드에서 해당 API를 사용하는 파일을 찾으세요
3. 타입 정의, API 호출 코드, 컴포넌트 순서로 수정하세요

## 규칙
- 기존 파일만 수정하세요. 새 파일을 만들지 마세요
- 기존 코드 스타일과 패턴을 그대로 유지하세요
- 사용자에게 노출되는 Page 파일도 수정이 필요한 경우 UX를 고려하여 수정합니다
  - 새로운 필드가 추가되었다면 사용자에게 보여주어야할 가능성이 있으니 검토하세요
- 외에도 변경이 필요한 부분은 찾아서 함께 수정하되 절대 오류를 범하지 마세요
- 변경이 필요 없는 파일은 포함하지 마세요
- API 변경과 무관한 코드는 절대 건드리지 마세요
- .github, 설정 파일, package.json 등은 절대 수정하지 마세요
- diff가 API 변경이 아니면 (CI 설정, 문서, 리팩토링 등) 빈 배열을 반환하세요
- 파일의 content는 해당 파일의 전체 내용이어야 합니다 (부분 수정 아님)

## 반환 형식 (순수 JSON만, 설명 없이)
{"files": [{"path": "src/...", "content": "전체 파일 내용"}]}

API 변경이 없으면:
{"files": []}`;

  const res = await fetch('https://api.anthropic.com/v1/messages', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'x-api-key': process.env.ANTHROPIC_API_KEY,
      'anthropic-version': '2023-06-01',
    },
    body: JSON.stringify({
      model: 'claude-sonnet-4-5-20250929',
      max_tokens: 8192,
      messages: [{ role: 'user', content: prompt }],
    }),
  });

  console.log('API status:', res.status);
  const data = await res.json();
  console.log('API response keys:', Object.keys(data));

  if (data.error) {
    console.error('API error:', JSON.stringify(data.error));
    process.exit(1);
  }

  let text = data.content[0].text;
  console.log('Response length:', text.length);
  console.log('Response preview:', text.substring(0, 300));

  text = text.replace(/```json\s*/g, '').replace(/```/g, '');
  const start = text.indexOf('{');
  const end = findMatchingBrace(text, start);
  const result = JSON.parse(text.substring(start, end + 1));
    
  console.log('Files to update:', result.files.length);

  if (result.files.length === 0) {
    console.log('No frontend changes needed. Skipping.');
  }

  for (const file of result.files) {
    fs.mkdirSync(path.dirname(file.path), { recursive: true });
    fs.writeFileSync(file.path, file.content);
    console.log('Updated:', file.path);
  }

  console.log('=== DONE ===');
} catch (e) {
  console.error('=== ERROR ===');
  console.error(e.message);
  console.error(e.stack);
  process.exit(1);
}

백엔드 action 파일, 프론트 action 파일, 스크립트 파일 총 세개의 파일로 구성을 완료하였습니다.

통합 테스트

물론 구현하면서 테스트를 진행했지만 실제로 적용이 얼마나 잘 되는지 궁금했습니다. 만약 몇몇 파일이 누락된다거나, 코드 수정 도중 문제가 생긴다면 직접 처리해야하고 결국 수동으로 진행하는 것과 마찬가지이기 때문입니다.

우선 백엔드 API에서 문제를 조회하면 submissionCount, solvedCount를 반환했습니다. 프론트에서는 이 두 정보를 표시하지만, 정답률 정보도 표시하면 좋을 것 같다고 생각했습니다. 백엔드와 프론트엔드 중에서는 백엔드에서 계산하는 편이 좋을 것 같아서 백엔드 작업으로 남겨두었었는데요, API변경이 필요한 부분이라 지금 시도하면 좋을 것 같아서 acceptanceRate를 response에 포함시켰습니다.

main Branch에 Push 후 프론트로 알림하는 트리거가 성공하고, 업데이트도 성공했습니다.

적절한 File들이 수정이 된 것을 확인했습니다.

로컬에서 브랜치 이동하여 실행했습니다. 브랜치 이름 뒤에 숫자는 Actions의 번호입니다.

정답률이 잘 표시되는 것을 확인하고 프론트 코드를 머지했습니다.

완성된 시점에서 정리해보니, 흐름 자체는 처음 계획대로 진행되었고 몇몇 부분은 진행해보며 상황에 따라 유동적으로 진행했습니다. 앞으로 더 개선한다면 변경될 수 있을 것 같아요.

[백엔드 커밋 & 푸쉬] → [Git log로 백엔드 변경사항 프론트로 전송]
→ [Trigger 발동] → [Claude 개발 및 PR오픈]
→ [변경 내용 디스코드 알림] → [개발자 코드 리뷰 및 머지]

앞으로의 계획 및 회고

지금처럼 간단한 수정에는 깔끔하게 동작하지만 대량의 API수정이 있는 상황에서는 변경이 적절하지 않을 가능성이 있습니다. 프롬프트 고도화나 분기 처리를 통해 처리할 수 있도록 디벨롭하려 합니다.

기능 개발을 진행하며 알게 되었는데, OpenAPI codegen으로 타입 정의까지는 자동화가 가능하단 것을 알게 되었어요. 제 프로젝트에 둘을 결합하는 방향으로 보완하여 타입 정의까지는 OpenAPI를 이용하고, 보여지는 것에 대한 수정은 Claude에게 시키도록 하면 토큰 절약이 될 것 같다고 생각이 듭니다. 만약 비슷한 자동화를 하게 된다면 다음에는 설계부터 잡고 가는 것도 좋겠습니다.

또한 기능을 사용하는 지금까지는 실패나 부자연스러운 수정이 0건이였지만 앞으로 이용하며 문제나 개선점을 찾아나가고 싶습니다.

결과적으로 제가 집중하고 싶은 부분에 더 집중할 수 있어서 좋았습니다. 프론트엔드 코드 작성에 드는 시간을유저 데이터 분석이나 서비스 고도화, 비지니스 목표 탐색에 사용할 수 있어서 만족스럽습니다.

[Quarkusio/Quarkus] 첫 오픈소스 기여

osoohynn — Thu, 15 Jan 2026 18:14:59 +0900

Quarkus란?

Quarkus는 Java 기반 클라우드 네이티브 애플리케이션을 빠르고 가볍게 만들기 위한 프레임워크입니다.

마이크로서비스
컨테이너/Kubernetes 환경
서버리스(Lambda 등)
빠른 스타트업과 리소스 효율이 중요한 서비스

위와 같은 서비스에서 주로 사용합니다.

저는 이 프레임워크를 사용해보진 않았지만, JVM 언어가 주력이기 때문에 첫 기여 리포지포리로 선정해보았습니다!!

제가 오픈소스 기여 리포지토리/이슈를 선정했을 때 기준을 공유하자면,

1. 주로 사용하는 언어로 고르려고 했습니다. AI가 코드를 작성해주더라도, 본인이 이해할 수 있어야 메인테이너분께 해를 안 끼칩니다!!

2. 메인테이너가 (이슈, PR이) 활발한 리포지토리를 선택하려 했습니다. 체계가 있으면 배울 점이 많을 것 같았습니다.

3. 도전하기 쉬운 issue를 고르려고 했습니다. 너무 어렵거나 큰 기능은 오래 걸리고 신경써야할 부분이 많습니다. 저는 그래서 데이터베이스 이름이 길어졌을 때 단축하는 정도의 쉬운 이슈를 선택했습니다!

이슈 분석

DB2는 데이터베이스 이름을 8자로 제한합니다. Quarkus Dev Services는 datasource 이름을 그대로 DB 이름으로 사용하는데, "additional" 같은 8자 초과 이름을 쓰면 컨테이너 기동이 실패하는 문제였습니다.

해결 과정

8자를 초과하는 이름을 단순히 잘라내면 서로 다른 datasource 이름이 같은 DB 이름으로 충돌할 수 있습니다. 그래서 prefix(4자) + SHA-224 해시(4자) 방식을 선택했습니다. 원래 이름의 앞 4글자로 가독성을 유지하면서, 해시 4자로 unique를 보장하는 구조입니다.

사용자가 db-name을 직접 설정한 경우에는 truncation 없이 그대로 사용하도록 했고, 자동 truncation이 발생하면 경고 로그를 남겨 사용자가 인지할 수 있게 했습니다.

PR 리뷰 과정

메인테이너(yrodiere)가 3차례 리뷰를 진행했습니다.

첫 번째 리뷰에서 해시 알고리즘과 로그 메시지, 테스트 방식에 대한 피드백을 받았습니다. 두 번째 리뷰에서는 테스트를 별도 파일에서 기존 integration-tests로 옮기는 제안을 받아 반영했습니다.

가장 까다로웠던 부분은 테스트였습니다. 처음에는 경고 로그를 검증하려 했으나, CI가 실패했습니다. 원인을 추적해보니 StartupLogCompressor가 Dev Services 기동 성공 시 로그를 의도적으로 숨기고 있었습니다. 이 내부 동작을 파악한 뒤, 로그 검증 대신 REST 엔드포인트 호출로 테스트 방식을 변경하여 CI를 통과했습니다.

첫 기여인데, 어떠셨나요?

우선 제가 염려한 바와 달리 메인테이너 분께서 친절하게 알려주시고 확인도 빨리 해주시는 편이였습니다.

좋은 제안도 해주셔서 배울 점이 있었습니다.

내 코드가 너무 불만족스러우면 어떡하지 하는 걱정도 있었는데 꽤 많은 부분이 그대로 반영되었습니다.

처음 CI가 한 번 실패했는데, 빌드가 성공하면 로그를 숨기는 코드가 있어서 실패했었습니다.ㅎㅎ

메인테이너께서 REST 테스트로 변경을 제안해주셔서, 수정하고 CI 성공했습니다.

CI 성공 알림을 확인하고 PR에 들어가봤는데

Merged, thank you!

이렇게 쿨하게 남겨주시고 머지해주셨습니다.

머지까지의 과정이 복잡할 것이라 걱정했는데, 메인테이너가 활발하게 활동하는 리포지토리임에도 불구하고

엄청 복잡한 과정없이 순조롭게 끝났습니다.

이번 일을 계기로 오픈소스 기여에 장벽이 허물어진 것 같습니다.

다음에는 꼭 제가 사용하는 라이브러리나 프레임워크의 오픈소스 기여도 도전해보고 싶네요!

참고: https://github.com/quarkusio/quarkus/pull/51913(Merge된 PR)

배운 점

1. 작은 이슈였지만, 얻을 게 많았습니다.
- "8글자 제한 처리" 단순해 보였는데
- 해시 알고리즘 선택, 테스트 방법, 로그 메시지 문구까지 신경 쓸 게 많았습니다.

- 특히 로직은 괜찮았는데, 테스트가 처음 기여해보니 생소하더라고요!

2. 리뷰어 피드백을 정확히 이해하고 커밋하면 좋습니다
- 이해가 안 갈 땐, 추측하지 말고 질문하는 편이 좋습니다.

3. 프레임워크 내부 이해가 중요합니다.
- StartupLogCompressor가 로그 숨기는 거 몰랐으면 계속 헤맸을 것입니다.
- 테스트 실패 원인 찾으려면 내부 동작 파악이 필요합니다.

- Claude Code같은 AI 툴을 잘 활용하면 좋아요!

[Spring Boot] 헥사고날 아키텍처에 관한 고찰

osoohynn — Sun, 30 Nov 2025 16:40:22 +0900

이 내용은 소규모 프로젝트를 개발하며 느꼈던 아키텍처에 대한 저의 생각입니다. 여러 선택을 번복하며 느낀 점을 기록하고자 작성하였습니다.

저는 학교에서 사용하는 출석 서비스를 개발하는 동아리에 가입했고, 2024년 말부터 개발에 참여할 수 있었습니다. 처음 개발에 투입돼어 온보딩할 때 프로젝트 구조는 UseCase를 중심으로 개발된 '클린 아키텍처'에 가까웠습니다. 그리고 백엔드 개발을 주도하며, 이 코드가 UseCase와 Service의 불명확한 책임 분리, 도메인 로직의 비독립성이 문제가 된다고 느꼈습니다.

바꾸는 김에 완벽하게 해보자

그렇게 저는 2개월이라는 시간동안 팀원들과 헥사고날 아키텍처로 리팩토링하였습니다. 그 당시에는 자주 변경되는 요구사항에 빠르게 대응하기 위한 아키텍처라고 생각했고 적용해보고자 팀원들을 설득하였습니다.

그럼 이제부터 문제를 서술하겠습니다.

실제로 도메인 로직과 기술의 분리는 성공적이였습니다.

그럼 무엇이 문제였나? ->

비지니스 로직 인터페이스를 설계하고 구현하지 않는 실수가 반복되었습니다. 비슷한 로직을 두번이나 구현해야하다보니까 시간이 오래 걸렸고 비효율적이였습니다.

이건 진짜 부끄러운 실수이긴한데 JPA의 더티 체킹 기능을 자주 이용하던 저인데, 서비스 코드에서 @Transactional 달아놓고 save() 메서드를 호출을 하는 걸 안 해서 여러 번 문제가 생겼습니다.....ㅎ.. (DB 독립적이라 기능 작동 안 함)

기능 수정 한 번에도 adapter까지 두 번 바꿔야하는 1+1이벤트 같았습니다. 정말 대규모 프로젝트에선 이 구조가 어떤식으로 도움이 될진 모르겠으나, 빠르게 개발해야하는 학생들에게는 독약같았습니다.

그리고는 레이어드 아키텍처로 다시 돌아왔습니다. 팀원 모두가 편하게 빨리 개발할 수 있는 구조로 말이죠. 실제로 이렇게 변경하는데에 하루밖에 안 걸렸습니다. 그리고 그 이후의 기능 수정은 더욱 빠르게 이루어졌고요.

느낀 점

이번 계기를 통해서 이론적인 사실들이 모두 맞는게 아니라는 사실을 깨달았습니다. 나의 상황과 팀의 상황 모두를 고려한 선택을 해야한다는 것을 체감했습니다. 다음부턴 이론적인 면보다 실제 상황에 합리적인 기술 선택을 할 것이라고 다짐했습니다.

스프링 개념 정복하기 - DI/IoC

osoohynn — Sun, 7 Sep 2025 15:00:01 +0900

1️⃣ 스프링과 스프링부트

✔ 스프링(Spring)

자바 기반 엔터프라이즈 애플리케이션을 효율적으로 개발하기 위한 프레임워크

대규모 서비스 개발에 적합
서버 성능, 안정성, 보안 등을 높은 수준으로 제공

✔ 스프링부트(Spring Boot)

스프링을 더 쉽게 사용할 수 있도록 만들어진 도구

프로젝트 설정 자동화 & 의존성 관리 간소화 (starter 제공)
내장 WAS(Tomcat 등) → 별도 서버 설치 없이 실행 가능
비즈니스 로직에 집중할 수 있도록 반복 설정 최소화

2️⃣ IoC (Inversion of Control, 제어의 역전)

기존 자바: 개발자가 직접 객체 생성 (new 키워드)
IoC: 객체의 생성과 생명주기를 스프링 컨테이너가 관리

// 기존 방식
public class A {
	B b = new B(); // 직접 생성
}

// IoC 적용
public class A {
	private B b; // 생성은 컨테이너가 담당
}

3️⃣ DI (Dependency Injection, 의존성 주입)

IoC를 구현하는 방법
외부에서 객체(빈)를 주입받아 사용

의존성 주입 방법

1. 필드 주입

@Service
public class MyService {
    @Autowired
    private MyRepository myRepository;
}

2. 생성자 주입 (권장)

@Service
public class MyService {
    private final MyRepository myRepository;

    @Autowired
    public MyService(MyRepository myRepository) {
    	this.myRepository = myRepository;
    }
}

3. 메서드(setter) 주입

@Service
public class MyService {
    private MyRepository myRepository;
    
    @Autowired
    public void setMyRepository(MyRepository myRepository) {
    	this.myRepository = myRepository;
    }
}

4️⃣ 스프링 컨테이너 & 빈

스프링 컨테이너: 빈을 생성하고 관리하는 주체
빈 등록 방법
- @Component (가장 간단, 클래스 직접 수정 가능할 때)
- @Configuration + @Bean (외부 라이브러리 객체 등록 시 사용)

5️⃣ AOP (Aspect Oriented Programming)

관점 지향 프로그래밍
핵심 로직과 부가 기능(로깅, 보안, 트랜잭션 등)을 분리 → 유지보수성 향상

6️⃣ PSA (Portable Service Abstraction)

이식 가능한 추상화
다양한 기술을 추상화하여 하나의 인터페이스로 사용 가능
- DB: JDBC, JPA, MyBatis
- 실행: WAS (Tomcat, Jetty 등)

7️⃣ 핵심 코드 예제

✔ 의존성 주입

@Component
public class Chef { } 

@Component
public class Restaurant {
    private final Chef chef;
    
    public Restaurant(Chef chef) {
    	this.chef = chef;
    }
}

✔ 편집 불가 클래스 빈 등록

public class Chef { } // 수정 불가

@Configuration
public class ChefConfig {
    @Bean
    public Chef chef() {
    	return new Chef();
    }
}

✔ 테스트 코드

@SpringBootTest
class SampleTest {
    @Autowired private Restaurant restaurant;

    @Test void test() {
    	System.out.println(restaurant);
    }
}

자바 개념 정복하기 - Stream 편

osoohynn — Sun, 7 Sep 2025 13:58:43 +0900

1️⃣ 스트림 개념

다양한 데이터 소스(컬렉션, 배열 등)를 표준화된 방식으로 다루기 위한 API

특징

읽기 전용(Read-only) → 데이터 소스를 변경하지 않음
일회용 → 한 번 닫으면 재사용 불가 (다시 생성 필요)
지연 연산(Lazy) → 최종 연산 전까지 중간 연산은 실행되지 않음
순차적 or 병렬 처리 가능 → stream() / parallelStream()

기본형 스트림

IntStream, LongStream, DoubleStream
오토박싱/언박싱 비용 절감 (Stream<Integer> 대신 IntStream)
숫자 전용 메서드(sum, average, max, min) 제공

2️⃣ 중간 연산 vs 최종 연산

중간 연산 (Intermediate Operation)

반환값이 스트림인 연산
여러 번 연결해서 사용 가능
예: filter(), map(), distinct(), sorted(), limit(), skip()

최종 연산 (Terminal Operation)

반환값이 스트림이 아닌 값
실행 시점에 스트림이 소비됨 → 재사용 불가
예: forEach(), collect(), count(), sum(), reduce()

3️⃣ 다양한 스트림 & Collector 함수

중간 연산

자르기: skip(n), limit(maxSize)
필터링: filter(Predicate), distinct()
정렬: sorted(), sorted(Comparator)
변환: map(), mapToInt(), mapToObj()
평탄화: flatMap()
엿보기: peek(Consumer)

최종 연산

소비: forEach(), forEachOrdered()
변환: toArray()
조건 검사: allMatch(), anyMatch(), noneMatch()
요소 찾기: findFirst(), findAny()
통계: count(), sum(), average(), max(), min(), summaryStatistics()
리듀싱: reduce()

Collector (수집)

변환: toList(), toSet(), toMap()
통계: counting(), summingInt(), averagingInt(), summarizingInt()
문자열 결합: joining(", ")
리듀싱: reducing()
분할/그룹화: partitioningBy(), groupingBy()

4️⃣ 핵심 코드 예제

✔ 필터링 + 변환

List<String> names = Arrays.asList("홍길동", "김철수", "이영희", "박민수");

List<String> filteredNames = names.stream()
    .filter(name -> name.startsWith("김"))
    .map(String::toUpperCase)
    .collect(Collectors.toList());
    
System.out.println(filteredNames); // [김철수]

✔ IntStream 활용

int[] numbers = {1,2,3,4,5,6,7,8,9,10};

int sum = Arrays.stream(numbers)
    .filter(n -> n % 2 == 0)
    .sum();
    
System.out.println("짝수의 합: " + sum); // 30

✔ 문자열 처리

List<String> fruits = Arrays.asList("사과", "바나나", "딸기", "오렌지", "포도");

// 글자수 < 3 필터링 후 정렬
List<String> shortFruits = fruits.stream()
    .filter(f -> f.length() < 3)
    .sorted()
    .collect(Collectors.toList());

// 평균 길이
double avgLength = fruits.stream()
    .mapToInt(String::length)
    .average()
    .orElse(0);

System.out.println(shortFruits); // [딸기, 사과]
System.out.println(avgLength); // 평균 길이

자바 개념 정복하기 - Optional/Lambda편

osoohynn — Sat, 6 Sep 2025 15:11:55 +0900

자바 개념을 확실히 다잡고 진짜 제대로 알고쓰자는 의미에서 기록을 시작합니다.

내용은 학교 수업시간에 배운 내용을 바탕으로 저의 추가 지식을 더하고 검색을 통해 작성했습니다.

목차 (배운 내용)

Optional 정의
Optional 사용 예제
Lambda 사용 예제
함수형 인터페이스
참조 메서드

Optional - Null 안정성 확보

Optional(옵셔널)

자바에서 흔히 발생하는 NullPointerException을 줄이기 위해 만들어진 클래스.
값이 있을 수도, 없을 수도 있는 객체를 감싸는 래퍼(Wrapper) 역할을 함.

Optional이란?
- T 타입 객체를 감싸는 클래스
- null 안정성을 제공 (안전한 null 처리)
- 마치 값을 담는 상자(Box) 같은 개념

// 값이 있을 때
Optional<String> opt1 = Optional.of("Hello");

// 값이 없을 수도 있을 때
Optional<String> opt2 = Optional.ofNullable(null);

// 아예 빈 값
Optional<String> opt3 = Optional.empty();

Optional<String> opt = Optional.of("Java");

// 1) 값 직접 꺼내기
System.out.println(opt.get()); // "Java" (값 없으면 예외 발생)

// 2) 값이 있으면 꺼내고, 없으면 기본값
System.out.println(opt.orElse("기본값"));

// 3) 값이 있으면 실행하기
opt.ifPresent(v -> System.out.println("길이: " + v.length()));

주요 메서드
- Optional.of(value): null이 아닌 값을 감쌈
- Optional.ofNullable(value): null일 수도 있는 값을 감쌈
- isPresent(): 값 존재 여부 확인
- ifPresent(consumer): 값이 존재할 경우 동작 수행
- orElse(defaultValue): 값 없을 경우 기본값 반환
- get(): 값 직접 반환 (없으면 예외 발생)

Lambda - 간결한 코드 작성

Lambda Expression (람다식)

함수를 간단한 식(Expression) 으로 표현하는 방법.
이름이 없는 함수 → 익명 함수(Anonymous Function).
간결하게 코드를 작성하고 함수형 프로그래밍을 지원.

함수형 인터페이스 (Functional Interface)

람다식이 구현할 수 있는 대상
추상 메서드가 하나만 있는 인터페이스
@FunctionalInterface 어노테이션으로 명시 가능

자바 제공 주요 함수형 인터페이스 (java.util.function):

인터페이스설명

Runnable	매개변수 없음, 반환값 없음
Supplier<T>	매개변수 없음, 반환값 T
Consumer<T>	매개변수 T, 반환값 없음
Function<T, R>	매개변수 T, 반환값 R
BiConsumer<T, U>	매개변수 T, U, 반환값 없음
BiFunction<T, U, R>	매개변수 T, U, 반환값 R

기본 문법

(매개변수) -> { 실행문 }

매개변수가 1개 → 괄호 생략 가능
실행문이 한 줄 → {}와 return 생략 가능

// 람다식
Calculator calculator1 = (int a, int b) -> { return a + b; };

// 더 간결하게
Calculator calculator2 = (a, b) -> a + b;

// 함수형 인터페이스
@FunctionalInterface interface Calculator {
	int calculate(int a, int b); 
}

메서드 참조 (Method Reference)

메서드 참조

하나의 메서드만 호출하는 람다식 → 더 간결하게 표현 가능.

종류람다식메서드 참조

static 메서드 참조	(x) → ClassName.method(x)	ClassName::method
인스턴스 메서드 참조	(obj, x) → obj.method(x)	ClassName::method
특정 객체 메서드 참조	(x) → obj.method(x)	obj::method

// static 메서드 참조
result.ifPresent(System.out::println);

// 인스턴스 메서드 참조
MyFunction myFunction1 = String::equals;

// 특정 객체 메서드 참조
String s = "Java";
MyFunction myFunction2 = s::equals;

핵심 실습 코드

함수형 인터페이스 & 람다식

@FunctionalInterface interface Calculator {
	int calculate(int a, int b);
}

public class Main {
    public static void main(String[] args) {
        // 익명 클래스 
        Calculator calculator = new Calculator() { 
            public int calculate(int a, int b) {
                return a + b;
            } 
        }; 

        // 람다식 
        Calculator calculator1 = (int a, int b) -> { return a + b; };

        // 더 간결하게
        Calculator calculator2 = (a, b) -> a + b; 
    }
}

자바 기본 제공 함수형 인터페이스

import java.util.function.Supplier;

public class D {
    Calculator add = (a, b) -> a + b;

    public static void main(String[] args) {
    	test((a, b) -> a + b);
    }

    public static void test(Calculator calculator) {
        int result = calculator.calculate(1, 2);
        System.out.println(result);
        Supplier<Integer> s = () -> 1;
    } 

    public static Calculator calculate() {
    	return (a, b) -> a + b;
    }
}

메서드 참조 & Optional

import java.util.Optional;

@FunctionalInterface
interface MyFunction {
	boolean method(String s);
}

class MyClass {
    String name;
    
    public MyClass(String name) {
    	this.name = name;
    } 

    public boolean eqName(String name) {
    	return this.name.equals(name);
    }
} 

public class E {
    public static void main(String[] args) {
        MyClass myClass = new MyClass("Java");
        
        MyFunction myFunction = myClass::eqName;
        
        Optional<String> result = Optional.ofNullable("Java");
        result.ifPresent(System.out::println);
        
        Optional<Integer> result2 = result.map(String::length);
        result2.ifPresent(System.out::println);
    } 
}

트러블 슈팅

Optional 1: get()을 바로 사용해 예외 발생 → orElse, ifPresent 사용
Optional 2: orElse()는 항상 실행, orElseGet()은 필요할 때만 실행 → 비용 큰 연산 시 orElseGet() 권장
Lambda 1: 람다식 타입 추론 오류 → 함수형 인터페이스 타입을 명확히 지정 필요

배운 점

Null 안정성의 중요성
- Optional 활용으로 NullPointerException 방지 가능
함수형 프로그래밍의 이점
- 람다식으로 간결하고 가독성 높은 코드 작성 가능
- 함수형 인터페이스(Function, Consumer, Supplier 등) 활용법 학습
- 메서드 참조(::)를 통한 더 간결한 표현 가능

➡ 이를 통해 더 모던하고 안전한 Java 코드 작성 가능.
특히, Java에 함수형 프로그래밍 패러다임이 통합된 방식 이해에 큰 도움을 얻음.