5동9층9호

spring boot 와 Opentelemetry

bj-lee — Mon, 12 Jan 2026 21:48:04 +0900

Spring Boot 4.0.1 OpenTelemetry Integration Guide

개요 (Overview)

이 글은 Spring Boot 4.0.1 환경에서 OpenTelemetry (OTel) 를 활용하여 Observability(가시성)를 확보하기 위한 아키텍처 및 구현 가이드를 다루려고 합니다.

Spring Boot 4.0부터는 spring-boot-starter-opentelemetry가 공식 도입되어, 기존 Spring Boot 3.x에서 여러 의존성(micrometer-tracing-bridge-otel, opentelemetry-exporter-otlp 등)을 조합하던 방식이 단일 Starter 의존성으로 대폭 간소화되었습니다. 특히 4.0.1 버전에서는 OTLP 로그 내보내기(Log Export) 관련 버그가 수정되어 더욱 안정적인 통합을 지원합니다.

주요 목표

Simplified Setup: 단일 Starter로 Tracing, Metrics, Logging 자동 구성.
Distributed Tracing: 마이크로서비스 간 요청 흐름 시각화.
Standardization: OTLP(OpenTelemetry Protocol) 기반의 데이터 전송 표준화.

1. 아키텍처 설계 (Architecture)

프로덕션 레벨의 아키텍처는 애플리케이션이 직접 백엔드(Jaeger, Prometheus 등)로 데이터를 전송하는 것이 아니라, OpenTelemetry Collector를 경유하는 것을 권장합니다.

OTEL 구성

2. 의존성 설정 (Dependencies)

Spring Boot 4.0.1에서는 spring-boot-starter-opentelemetry 하나만 추가하면 필요한 Micrometer Tracing Bridge와 OTLP Exporter가 모두 자동으로 구성됩니다.

build.gradle

plugins {
    id 'java'
    id 'org.springframework.boot' version '4.0.1'
    id 'io.spring.dependency-management' version '1.1.7'
}

dependencies {
    // 1. Web & Actuator (Health check, Metrics endpoint)
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-actuator'

    // 2. OpenTelemetry Official Starter (New in Spring Boot 4)
    // Tracing, Metrics, Logging via OTLP are auto-configured.
    implementation 'org.springframework.boot:spring-boot-starter-opentelemetry'

    // 3. AOP (For @NewSpan annotation support if needed)
    implementation 'org.springframework.boot:spring-boot-starter-aop'
}

3. 애플리케이션 설정 (Configuration)

Spring Boot 4에서는 management.opentelemetry.* 네임스페이스를 통해 통합 설정이 가능합니다.

application.yml

spring:
  application:
    name: payment-service

management:
  endpoints:
    web:
      exposure:
        include: health, info, metrics, prometheus

  # Spring Boot 4 OpenTelemetry Configuration
  opentelemetry:
    tracing:
      export:
        enabled: true
        # endpoint: http://localhost:4318/v1/traces (기본값)
    logging:
      export:
        enabled: true # 4.0.1에서 안정화됨
        # endpoint: http://localhost:4318/v1/logs (기본값)

  # Sampling 설정 (기존 tracing 네임스페이스 유지)
  tracing:
    sampling:
      probability: 1.0 # 개발환경 1.0, 운영환경 0.1 이하 권장
    propagation:
      type: w3c # W3C TraceContext 표준 사용

logging:
  pattern:
    # 콘솔 로그에 TraceID/SpanID 표시 (디버깅용)
    level: "%5p [${spring.application.name:},%X{traceId:-},%X{spanId:-}]"

4. 커스텀 추적 구현 (Custom Tracing)

비즈니스 로직 내부의 세부 구간을 추적하기 위한 방법은 기존과 동일하게 Micrometer Tracing API를 사용합니다.

방법 A: 어노테이션 기반 (@NewSpan)

가장 간결한 방식입니다.

import io.micrometer.tracing.annotation.NewSpan;
import io.micrometer.tracing.annotation.SpanTag;
import org.springframework.stereotype.Service;

@Service
public class PaymentService {

    @NewSpan("process-payment") // Span 이름
    public void processPayment(@SpanTag("payment.id") String paymentId) {
        // 비즈니스 로직 수행
        validate(paymentId);
    }
}

방법 B: 프로그래매틱 방식 (Tracer Bean)

io.micrometer.tracing.Tracer를 주입받아 사용합니다. (OTel API를 직접 쓰지 않고 Micrometer 파사드를 쓰는 것이 Spring Boot의 권장 사항입니다.)

import io.micrometer.tracing.Span;
import io.micrometer.tracing.Tracer;
import org.springframework.stereotype.Component;

@Component
public class ManualTracer {

    private final Tracer tracer;

    public ManualTracer(Tracer tracer) {
        this.tracer = tracer;
    }

    public void complicatedLogic() {
        Span newSpan = this.tracer.nextSpan().name("complex-calculation");

        try (Tracer.SpanInScope ws = this.tracer.withSpan(newSpan.start())) {
            newSpan.tag("calculation.type", "tax");
            doCalculations();
        } finally {
            newSpan.end();
        }
    }
}

5. 로컬 테스트 환경 (Docker Compose)

OTLP 데이터를 수신할 Collector와 백엔드 서비스를 구성합니다.

version: "3"
services:
  # 1. OpenTelemetry Collector
  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
      - ./otel-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "4317:4317" # OTLP gRPC
      - "4318:4318" # OTLP HTTP (Spring Boot Default)

  # 2. Jaeger (Tracing)
  jaeger:
    image: jaegertracing/all-in-one:latest
    ports:
      - "16686:16686"

  # 3. Prometheus (Metrics)
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"

6. 마이그레이션 가이드 (From 3.x to 4.x)

의존성 삭제: micrometer-tracing-bridge-otel, opentelemetry-exporter-otlp 제거.
의존성 추가: spring-boot-starter-opentelemetry 추가.
프로퍼티 변경: management.otlp.tracing.* -> management.opentelemetry.tracing.export.*.

7. TraceId 이용하기

방법 1: Tracer 빈을 이용한 추출 (가장 권장)

Spring Boot가 자동 설정해준 Tracer 빈을 주입받아 현재 Span의 컨텍스트에서 직접 추출합니다.

import io.micrometer.tracing.Tracer;
import org.springframework.stereotype.Service;

@Service
public class BusinessService {

    private final Tracer tracer;

    public BusinessService(Tracer tracer) {
        this.tracer = tracer;
    }

    public String getTraceId() {
        // 현재 활성화된 Span이 없을 수 있으므로 null 체크가 필요합니다.
        if (tracer.currentSpan() != null) {
            return tracer.currentSpan().context().traceId();
        }
        return "no-trace-id";
    }
}

방법 2: MDC(Mapped Diagnostic Context)에서 추출

Micrometer Tracing은 로그 연동을 위해 자동으로 traceId를 SLF4J의 MDC에 넣어줍니다. 별도의 빈 주입 없이 빠르게 가져올 때 유용합니다.

import org.slf4j.MDC;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class TestController {

    @GetMapping("/trace")
    public String trace() {
        // application.yml 설정에 의해 "traceId" 키로 자동 저장됨
        return MDC.get("traceId");
    }
}

8. 결론

혹시 잘못된 내용이 있으면 댓글 부탁드립니다.

[Python] 내 주식 전략, 진짜 돈이 될까? Pandas로 초간단 백테스팅 구현하기

bj-lee — Sun, 4 Jan 2026 14:50:34 +0900

주식 자동매매 봇을 만들기 전 가장 중요한 단계는 백테스팅(Backtesting)입니다. "지난달에 이 전략을 썼다면 얼마를 벌었을까?"를 검증하지 않고 실전에
투입하는 것은 도박과 같습니다. 오늘은 복잡한 라이브러리 없이, Python Pandas만으로 이동평균선(MA) 전략을 검증하는 방법을 소개합니다.

백테스팅, 왜 필수인가?

많은 초보자가 "황금 전략"을 떠올리고 바로 매매 봇부터 만듭니다. 하지만 막상 돌려보면 수수료와 슬리피지(Slippage) 때문에 계좌가 녹아내리는 경우가
태반입니다.
백테스팅은 과거 데이터(Historical Data)를 통해 내 전략의 승률, 최대 낙폭(MDD), 수익률을 미리 확인하여 '맷집'을 키우는 과정입니다.

데이터 준비 (yfinance)

미국 주식 데이터는 yfinance 라이브러리를 쓰면 무료로, 아주 쉽게 구할 수 있습니다.

1 import yfinance as yf  
2  
3 # 애플(AAPL)의 2024년 데이터 가져오기  
4 df = yf.download("AAPL", start="2024-01-01", end="2024-12-31")  
5 print(df.head())

전략 구현: 골든크로스 (Golden Cross)

가장 기초적인 전략인 '골든크로스'를 코드로 구현해 봅시다.
* 매수: 5일 이동평균선이 20일 이동평균선을 뚫고 올라갈 때
* 매도: 5일 이동평균선이 20일 이동평균선 아래로 내려갈 때

1 import pandas as pd  
2 import numpy as np  
3  
4 # 1. 이동평균선 계산  
5 df\['MA5'\] = df\['Close'\].rolling(window=5).mean()  
6 df\['MA20'\] = df\['Close'\].rolling(window=20).mean()  
7  
8 # 2. 매매 신호 생성 (1: 매수 유지, 0: 현금 보유)  
9 # MA5가 MA20보다 크면 주식을 보유한다고 가정  
10 df\['Signal'\] = np.where(df\['MA5'\] > df\['MA20'\], 1, 0)  
11  
12 # 3. 포지션 변화 확인 (1이면 매수 진입, -1이면 매도 청산)  
13 df\['Position'\] = df\['Signal'\].diff()

수익률 계산 (누적 수익률)

이제 이 신호대로 매매했을 때의 수익률을 계산해 봅니다.
(단순화를 위해 수수료는 제외했습니다. 실전에서는 0.25% 정도를 차감해야 합니다.)

1 # 내일의 수익률을 미리 계산 (오늘 신호 보고 내일 시가에 산다고 가정하거나, 종가 매수 가정)  
2 # 여기서는 간단히 '보유 기간 동안의 변동폭'을 수익률로 계산  
3 df\['Daily\_Return'\] = df\['Close'\].pct\_change()  
4  
5 # 전략 수익률 = 주가 등락률 × 내 포지션(1 or 0)  
6 # shift(1)은 '어제 나온 신호로 오늘 수익을 먹는다'는 의미 (미래 참조 방지)  
7 df\['Strategy\_Return'\] = df\['Daily\_Return'\] \* df\['Signal'\].shift(1)  
8  
9 # 누적 수익률 계산  
10 df\['Cumulative\_Strategy\_Return'\] = (1 + df\['Strategy\_Return'\]).cumprod()  
11 df\['Cumulative\_BuyHold\_Return'\] = (1 + df\['Daily\_Return'\]).cumprod()  
12  
13 print(f"전략 최종 수익률: {df\['Cumulative\_Strategy\_Return'\].iloc\[-1\]:.2f}")  
14 print(f"존버(Buy&Hold) 수익률: {df\['Cumulative\_BuyHold\_Return'\].iloc\[-1\]:.2f}")

[Backtest Report] AAPL Golden Cross Strategy (2024)


    1 [INFO] 백테스팅 시작: AAPL (Apple Inc.)
    2 [INFO] 기간: 2024-01-01 ~ 2024-12-31
    3 [INFO] 초기 자본: $10,000
    4 [INFO] 데이터 수집 중... 완료.
    5
    6 --------------------------------------------------
    7 [SIGNAL] 2024-01-18: GOLDEN CROSS 발생
    8 >> 매수 진입 | 가격: $188.63
    9
   10 [SIGNAL] 2024-04-12: DEAD CROSS 발생
   11 >> 매도 청산 | 가격: $176.55 | 수익률: -6.40%
   12
   13 [SIGNAL] 2024-05-08: GOLDEN CROSS 발생
   14 >> 매수 진입 | 가격: $182.74
   15
   16 [SIGNAL] 2024-08-05: DEAD CROSS 발생
   17 >> 매도 청산 | 가격: $209.27 | 수익률: +14.52%
   18
   19 [SIGNAL] 2024-08-28: GOLDEN CROSS 발생
   20 >> 매수 진입 | 가격: $226.49
   21 --------------------------------------------------
   22
   23 [FINAL PERFORMANCE REPORT]
   24 - 최종 자산: $12,450.32
   25 - 누적 수익률: +24.50%
   26 - 단순 보유(Buy & Hold) 수익률: +31.18%
   27 - 전략 승률: 66.7% (2승 1패)
   28 - 최대 낙폭(MDD): -12.45%
   29 - 총 매매 횟수: 3회
   30
   31 [분석 결과]
   32 2024년 애플(AAPL)의 경우, 단순 골든크로스 전략보다는 사서 들고 있는 전략이 더 높은 수익률을 기록했습니다.
   33 이는 주가가 박스권을 횡보할 때 발생하는 잦은 손절(Whipsaw) 때문으로 분석됩니다.
   34 수익률 개선을 위해 변동성 필터를 추가할 필요가 있습니다.

"코드를 실행하면 위와 같은 리포트가 출력됩니다. 결과를 보니 단순히 보유하는 것보다 수익률이 낮게 나왔네요. 왜 그럴까요?" ...
계속 확인해보고 포스팅할 예정입니다.

결론 및 시사점

직접 돌려보면 놀라운 사실을 알게 됩니다. "그냥 사서 들고 있는 게(Buy & Hold) 더 수익률이 좋을 때가 많다"는 것입니다.
이처럼 백테스팅은 대박을 꿈꾸기보다는, 내 전략의 허점을 찾고 MDD(최대 낙폭)를 관리하는 데 그 목적이 있습니다. 다음 편에서는 이 결과에 '변동성 돌파
전략'을 섞어 수익률을 개선하는 방법을 다뤄보겠습니다.

[DevOps] Sonarqube로 코드 품질과 커버리지, 두 마리 토끼 잡기 (실무 적용 가이드)

bj-lee — Sun, 4 Jan 2026 14:45:03 +0900

코드 품질의 확보

흔히 지속적인 코드 품질을 확보하기 위해서는 시큐어 코딩(Secure Coding) 이란 명명아래 소스 코드에 존재할 수 있는 잠재적인 불안요소(보안 취약점)를 제거하나, 그런 것들을 고려하여 기능을 설계 및 구현하는 등의 행위가 확보되어야 합니다.

미국은 일찍이 시큐어 코딩을 의무화했고, 우리나라도 2012년부터 의무제로 시행되어 공공기관의 정보화 사업 중 일부를 대상으로 시행되고 있습니다.

왜 Sonarqube인가? (단순한 린트 툴이 아닙니다)

많은 분이 Sonarqube를 단순히 "조금 더 깐깐한 린트(Lint) 도구" 정도로 생각합니다. 하지만 Sonarqube의 진가는 '시각화'와 '추이 관리'에 있습니다.

코드 스멜(Code Smell)의 시각화: 잠재적인 버그 가능성이 있는 코드를 직관적으로 보여줍니다.
Quality Gate (품질 관문): "테스트 커버리지 80% 미만이면 배포 금지!"와 같이 강력한 품질 정책을 파이프라인에 심을 수 있습니다.

핵심 기능 1: 정적 분석 (Static Analysis)

Sonarqube는 코드를 실행하지 않고도 버그를 찾아냅니다. (NullPointerException 가능성, 자원 해제 누락 등)

실무 활용 팁:
처음 도입하면 수천 개의 'Code Smell'이 떠서 팀원들이 좌절할 수 있습니다. 이때 중요한 것은 '선택과 집중'입니다.

New Code(신규 코드) 정책: "기존 코드는 건드리지 말고, 오늘부터 작성하는 새 코드만큼은 깨끗하게 유지하자"는 정책으로 시작하세요. Sonarqube
대시보드에서 'Leak Period' 설정을 통해 이를 쉽게 관리할 수 있습니다.
핵심 기능 2: 코드 커버리지 (Coverage) 측정JaCoCo와 연동:
Java/Spring 환경이라면 JaCoCo 플러그인과 연동이 필수입니다. 빌드 시 생성된 jacoco.xml 리포트를 Sonarqube가 읽어가서 그래프로 그려줍니다.
Sonarqube 도입 후 달라진 점
(이 부분에 JaCoCo 설정 Gradle/Maven 코드를 살짝 넣어주면 좋습니다)
"테스트 코드 작성해 주세요"라고 백번 말하는 것보다, PR(Pull Request) 화면에 "커버리지 70% (통과 실패 ❌)" 딱지를 붙이는 게 훨씬 효과적입니다.

코드 리뷰 시간 단축: 띄어쓰기나 단순한 문법 오류는 봇(Bot)이 잡아주니, 리뷰어는 비즈니스 로직에만 집중할 수 있게 되었습니다.
테스트 작성의 생활화: Quality Gate 통과를 위해 개발자들이 스스로 테스트 코드를 챙기기 시작했습니다.
심리적 안정감: 배포 전, 최소한의 안전장치를 거쳤다는 확신이 생깁니다.

    1 plugins {
    2     id 'jacoco'
    3     id 'org.sonarqube' version '4.4.1.3373'
    4 }
    5
    6 jacoco {
    7     toolVersion = "0.8.11"
    8 }
    9
   10 tasks.named('test') {
   11     useJUnitPlatform()
   12     finalizedBy 'jacocoTestReport' // 테스트 끝나면 리포트 생성
   13 }
   14
   15 jacocoTestReport {
   16     reports {
   17         xml.required = true // 소나큐브는 XML 리포트를 읽습니다
   18     }
   19     dependsOn test // 리포트 생성 전 테스트 필수
   20 }
   21
   22 sonarqube {
   23     properties {
   24         property "sonar.projectKey", "my-project-key"
   25         property "sonar.host.url", "http://your-sonarqube-server:9000"
   26         property "sonar.login", "your-token"
   27         property "sonar.coverage.jacoco.xmlReportPaths", "build/reports/jacoco/test/jacocoTestReport.xml"
   28     }
   29 }

(예전 글)
앞서 말한 시큐어코딩은 IDE 제품별 저마다의 플러그인을 지원하여 쉽게 확인할 수 있다. 여기에서는 그 결과를 UI 적으로 확인하여 정보를 공유할 수 있도록 하는 가시화 툴인 sonarqube 에 대해 설명합니다.

sonarqube 는 지속적인 코드 품질을 확보하기 위한 UI 기반의 가시화 툴이다.

[주요기능]

지속적인 코드의 Inspection
다양한 언어의 지원으로 단일 Point에서 확인(UI)
다양한 빌드 시스템 지원(Jenkins 등)
품질 요구사항 반영 가능(Test Coverage 비율, Bug 레벨 등)

이 글에서는 Java(11) + gradle(6.6. + jenkins(일부) 를 활용하여 SonarQube 를 이용하는 케이스에 대해 설명한다.

https://www.sonarqube.org/downloads/

[Download | SonarQube

Maximum Application Security Maximum value across branches & PRs Download License key will be needed to activate docker pull sonarqube:8.5.1-developer

www.sonarqube.org](https://www.sonarqube.org/downloads/)

기본적으로 SonarQube 는 elasticsearch, Embedded database 를 사용하며 안정적인 사용을 위해 DB 는 별도의 엔진을 사용하도록 권고된다. 그리고 안정적인 사용을 위해 LTS 버전으로 테스트를 했고, 다운로드 후 아래의 순서에 따라 준비할 수있다.

InstallNTService.bat > StartNTService.bat > StartSonar.bat 순서로 실행한다.

연결정보는 http://localhost:9000 이고 admin/admin 으로 접속한다.

기본 접속화면이고 로그인 후 새로운 프로젝트를 생성하면 튜토리얼에 따라 몇가지 작업(토큰생성 등) 을 진행한 후에 ready 상태가 된다. 해당 토큰은 추후 연동을 위한 값으로 사용되므로 기억해야한다.(재발급 가능)

새로운 프로젝트를 생성하고 `Set Up` 이 되면 token 을 생성하고, 프로젝트의 언어 및 build 기술을 선택한다.

해당 진행결과에 따라 gradle 설정 방법이 나오고 해당 부분을 프로젝트에 적용해야 한다.

gradle 에서 sonarqube 플러그인 사용을 위한 선언 추가

# build.gradle 파일의 내용
plugins {
    id "org.sonarqube" version "2.7"
}

플러그인을 통한 sonarqube 에 결과 올리는 명령어

./gradlew sonarqube \ -Dsonar.projectKey=sonarqube_test_project \ -Dsonar.host.url=http://localhost:9000 \ -Dsonar.login=위에서 발급받은 token 값 입력

build.gradle 을 통해 sonarqube 플러그인을 실행하는 경우의 gradle task

sonarqube { properties { property "sonar.host.url", "http://localhost:9000" property "sonar.login", "token 설정값" property "sonar.projectKey", "sonarqube_test_project" // optional property "sonar.sourceEncoding", "UTF-8" } }

sonarqube 실행

IDE 에 있는 sonarqube 플러그인은 품질측정을 위해 upload 하는게 아닌 sonarqube 의 체크 룰을 local 에 적용하기 위한 기능을 제공한다.

해당 플러그인 이나 명령어를 실행하면 UI 를 통해 결과를 확인할 수 있는데 아래와 같다.

gradle task 를 실행시킨 모습

기본적으로 gradle task 를 타고 실행하게 되어 있고 main/test 에 대한 java, resources 에 대한 compile, process, classes task 를 실행한다. 그 이후 Coverage 를 위한 test Task 를 수행하여 sonarqube 에 반영하게 되는 절차를 거친다.

아래는 실행 결과가 반영된 sonarqube 화면이다.

실제로 해당 프로젝트의 상세화면에서 New Code, Overall Code 를 확인할 수 있는데 이는 지속적인 품질관리를 위해 기존과 달리 새로 반영된 Code 에 대한 측정결과에 전체 코드에 대한 측정결과를 확인할 수 있게 해준다.

전체코드 품질 측정 결과 화면

'Overall Code' 에서는 각 항목별 내용에 대한 결과를 전체적으로 확인할 수 있고 각 항목의 내용은 아래와 같이 구성된다.

Bugs(버그) - 코드의 신뢰성. 코드에서 잘못된 것을 나타냄
Vulnerabilities(취약점)
Security Hotspots(보안 핫스팟) - 취약성이 존재하는지 여부를 평가하기 위해 수동 검토가 필요한 보안에 민감한 코드에 대한 정보
Code Coverage 비율 및 전체 단위 테스트 수
전체 라인중 중복된 라인 및 블럭에 대한 비율
Code Smells - 유지관리에 관련해서 코드에서 더 심오한 문제를 일으킬 가능성이 있는 프로그램 소스 코드

Issues

Issues 메뉴는 현재 프로젝트 기준으로 모든 issue 를 확인할 수 있는데 Filter 를 통해 원하는 항목에 대한 품질을 확인할 때 사용할 수 있다.

이중 Bug, Code Smell 등의 항목은 IDE 에서 지원하는 FindBug, SonarLint 등의 inspection 도구를 통해도 확인할 수 있는데 각 Inspection 도구마다 필수체크 룰 외의 항목은 상이할 수 있으니, 프로젝트의 기준에 맞게 설정하여 진행하여야 한다. 보통 Major 이상의 이슈는 없이 가는게 보통이다.

위의 화면은 Issues 항목 중 하나이며 Code Smell 기준 Blocker 로 측정된 항목이다. 해당 화면에 표출된 분석 지표를 통해서 코드의 품질을 확보해야 하며 위의 예는 test case 에서의 assertion 이 없을 경우에 나타난다.

실제 코드의 추적(Coverage)

spring-boot 기준으로 간단한 컨트롤러를 작성한다. 아래의 코드 작성 후 sonarqube 를 수행하면 위에 설명한 각종 정보를 확인할 수 있는데 신뢰성이나 보안 역시 중요하지만 커버리지는 branch coverage 를 우선하여 품질을 검토한다.

Sonarqube 에서는 Branch coverage 를 Condition coverage 라 표현한다.

@RestController
@RequestMapping("/sample")
public class SampleController {

    @GetMapping("test")
    public String test1(@RequestParam String param1) {
        if("test".equals(param1)) {
            return "test";
        } else {
            return "no test";
        }
    }
}

위의 경우 2건의 conditions cover 가 필요한데 하나는 param1 이 "test" 인 경우와 또 하나는 그렇지 않은 경우이다. 해당 2건의 조건에 대한 Test 가 작성되어 있으면 Cover 가 되었다고 판단되며 커버율이 올라간다.

아래는 위의 조건 중 if("test".equals(param1)) 에 대한 Cover Test 케이스이다.

class SampleControllerTest {

    @Test
    void whenParam1Equal_Test_ThenReturn_Test() {
        SampleController sampleController = new SampleController();
        Assertions.assertEquals("test", sampleController.test1("test"));
    }
}

해당 결과를 sonarqube 에 반영하기 위해서는 추가로 jacoco 라는 플러그인을 사용해야 하며 build.gradle 에 관련 정보를 추가하여 아래처럼 구성해야 한다.

plugins { id 'org.springframework.boot' version '2.4.0' id 'io.spring.dependency-management' version '1.0.10.RELEASE' id 'java' // sonarqube 플러그인 지정 id 'org.sonarqube' version '2.7' // jacoco 플러그인 지정 id 'jacoco' } // jacoco의 기본설정은 html 만 생성하게 되어있으나 xml 추가를 위한 설정 jacocoTestReport { dependsOn tasks.test reports { xml.enabled(true) html.enabled(true) xml.destination(new File("build/reports/jacoco.xml")) } } sonarqube { properties { property "sonar.host.url", "http://localhost:9000" property "sonar.projectKey", "sonarqube_test_project" property "sonar.login", "b933f78a65f288ecbd7a159a41dd2eb205594685" // jacoco 에서 생성된 xml 을 report 로 올리기 위한 설정 property "sonar.coverage.jacoco.xmlReportPaths", "build/reports/jacoco.xml" } } // sonarqube task 수행시 clean, jacocoTestReport 를 우선 실행하기 위한 설정 tasks["sonarqube"].dependsOn(clean, jacocoTestReport)

구성 후에 sonarqube task 를 실행하면 clean, jacocoTestReport 를 선 수행한 후 해당 결과로 생성된 jacoco.xml 파일이 sonarqube 에 반영되어 아래와 같은 결과를 확인할 수 있다.

앞서 실행한 단위 테스트 결과에 따라 Coverage 가 50.0% 로 변경되었고 상세화면은 아래처럼 확인 가능하다. 아래화면은 Coverage 중 Condition Coverage(Branch coverage) 의 상세 화면이며 앞서 작성한 Test 코드가 커버한 main 의 소스코드가 표현되어 어느 condition 이 테스트가 되었는지 확인할 수 있다.

화면상에 라인별 색을 통해 판단된 내용을 확인할 수 있는데 녹색은 테스트가 된 항목, 빨간색은 테스트가 되지 않은 항목, 빗금으로 섞인 색은 여러 건의 조건에 대해 일부 통과된 것을 나타낸다.

이처럼 조건절에 대한 커버리지 우선으로 확인하되 조건에 대한 커버리지가 확보되면 자연스레 라인커버리지도 올라가는데 라인 커버리지나 클래스 커버리지 같은 항목은 우선순위가 낮다.

정리

코드의 품질을 확보하는 과정은 개발자의 지속적인 노력이 필요하며 이 노력은 개발팀의 전체적인 규약이나 약속에 따라 방향성이 좌우된다. Test 코드를 작성하는 과정은 일반적인 개발 과정의 배수만큼 노력이 들지만 이를 일반적인 개발 과정의 일부로 받아들여야 그 만큼의 코드 품질이 확보된다고 생각한다. 리펙토링이나 클린코드나 결국 코드 품질 이슈에 대한 대응을 위한 방법들이며 Sonarqube 의 공식 홈페이지에 따르면 아래와 같은 방법으로 Clean Code 를 권고하고 있다. (Clean as You Code | SonarQube Docs)

Focus on New Code - 새로 추가된 코드 기준으로 우선 검증
Personal Responsibility - 개인의 책임. 개인이 현재 작업 중인 새로운 코드의 품질 확보
Quality Gate - 출시할 준비가 되었을 경우
Pull Request Analysis - 풀 리퀘스트 분석 및 데코레이션을 사용하여 병합하기 전에 코드가 표준을 충족하는지 확인

코드 품질은 프로젝트 마무리 때에 몰아서 하면 프로젝트의 실패로 이어질 수 있으니 초기부터 지속적인 관리가 필요하다.

[AWS] EC2 대신 Fargate를 도입해야 할까? 비용 분석 및 실무 사용기

bj-lee — Sun, 4 Jan 2026 14:40:08 +0900

AWS에서 컨테이너 서비스를 구축할 때 가장 큰 고민은 "EC2 모드로 할 것인가, Fargate 모드로 할 것인가?"입니다. 직접 서비스를 운영하며 느꼈던 장단점과, 많은 분이 오해하고 있는 비용 효율성에 대해 정리해 드립니다.

Fargate란 무엇인가? (EC2와 차이점)

가장 쉽게 설명하면 "서버 관리의 주도권"이 누구에게 있느냐의 차이입니다.
- EC2 Launch Type: 내가 직접 서버(Node)를 띄우고, 그 위에 컨테이너를 올립니다. OS 패치, 오토 스케일링 설정, 보안 그룹 관리 등을 직접 해야 합니다.
- Fargate Launch Type: AWS가 서버를 관리해 줍니다. 나는 "CPU 2GB, 메모리 4GB 주세요"라고 주문만 하면 컨테이너가 뜹니다.

비용 분석: Fargate는 정말 비싼가?

"Fargate는 편한 대신 비싸다"는 인식이 있습니다. 반은 맞고 반은 틀립니다.
- 24시간 풀로 돌아가는 대규모 클러스터: EC2(Reserved Instances/Savings Plans)가 더 저렴합니다.
- 트래픽이 들쭉날쭉하거나, 개발/테스트 환경, 배치 작업: Fargate가 유리할 수 있습니다.
실제 경험상 Fargate가 비용 효율적인 구간:
1. 유휴 자원(빈 공간)이 많은 경우: EC2는 꽉 채워 쓰지 않아도 인스턴스 비용을 다 내지만, Fargate는 딱 쓴 만큼만 냅니다.
2. 운영 인건비: 서버 관리(OS 업데이트, 에이전트 관리)에 들어가는 엔지니어의 시간을 돈으로 환산하면 Fargate가 압도적으로 저렴합니다.

실무 도입 시 겪었던 이슈와 해결 팁

Fargate를 처음 도입할 때 가장 당황했던 포인트들과 해결책입니다.

A. 로그 확인이 어렵다?
EC2는 접속해서 로그 파일을 까보면 되지만, Fargate는 서버에 접속할 수 없습니다(기본적으로).
- 해결: awslogs 드라이버를 사용하여 CloudWatch Logs로 로그를 쏘는 설정이 필수입니다. 최근에는 ECS Exec 기능을 통해 Fargate 컨테이너 내부로 쉘 접속도 가능해져 디버깅이 쉬워졌습니다.
B. 이미지가 너무 크면 느리다
Fargate는 매번 새로운 VM 위에서 컨테이너를 띄우는 방식이므로, 도커 이미지를 다운로드(Pull)하는 시간이 곧 부팅 시간입니다.
- 해결: 이미지를 최대한 경량화(Alpine 리눅스 사용 등)하고, 불필요한 레이어를 줄여야 빠른 스케일 아웃이 가능합니다. 그렇지만 대비시간은 늦기는 합니다..^^;;
C. Timezone 설정
기본적으로 UTC 시간을 따릅니다. 한국 시간(KST)이 필요하다면 Dockerfile에서 설정하거나, 환경 변수 TZ=Asia/Seoul을 주입해야 합니다.

결론: 언제 Fargate를 써야 할까?

이런 경우 Fargate를 강력 추천합니다.
- 인프라 전담 엔지니어(DevOps)가 따로 없는 소규모 팀
- 트래픽 예측이 어렵거나 급격히 변하는 서비스
- CI/CD 파이프라인용 일회성 빌드 에이전트
이런 경우 EC2를 고려하세요.
- GPU가 필요한 고성능 컴퓨팅 작업 (Fargate GPU는 제한적/비쌈)
- 이미 예약 인스턴스(RI)를 많이 구매해 둔 경우
- 커널 레벨의 튜닝이 필요한 특수 목적 애플리케이션

아래는 제가 만든건 아니지만, 실제 적용되어 있던 json 의 형태입니다.

    1 {
    2   "family": "alpha-squad-api-task",
    3   "networkMode": "awsvpc",
    4   "requiresCompatibilities": [
    5     "FARGATE"
    6   ],
    7   "cpu": "256",
    8   "memory": "512",
    9   "containerDefinitions": [
   10     {
   11       "name": "api-container",
   12       "image": "YOUR_ACCOUNT_ID.dkr.ecr.ap-northeast-2.amazonaws.com/alpha-squad:latest",
   13       "portMappings": [
   14         {
   15           "containerPort": 8080,
   16           "hostPort": 8080,
   17           "protocol": "tcp"
   18         }
   19       ],
   20       "environment": [
   21         {
   22           "name": "TZ",
   23           "value": "Asia/Seoul"
   24         },
   25         {
   26           "name": "SPRING_PROFILES_ACTIVE",
   27           "value": "prod"
   28         }
   29       ],
   30       "logConfiguration": {
   31         "logDriver": "awslogs",
   32         "options": {
   33           "awslogs-group": "/ecs/alpha-squad-api",
   34           "awslogs-region": "ap-northeast-2",
   35           "awslogs-stream-prefix": "ecs"
   36         }
   37       },
   38       "essential": true
   39     }
   40   ]
   41 }

cpu & memory: Fargate는 CPU와 메모리 조합이 정해져 있습니다. 위 설정(256, 512)은 가장 저렴한 최소 사양 조합입니다.
networkMode: Fargate는 반드시 awsvpc 모드를 사용해야 합니다. 각 태스크가 고유한 ENI(탄력적 네트워크 인터페이스)를 할당받아 보안 그룹 제어가 정교해집니다.
logConfiguration: 서버에 접속할 수 없는 Fargate 특성상, awslogs 드라이버를 통해 CloudWatch Logs로 로그를 보내는 작업은 필수입니다.
environment (TZ): 본문에서 언급한 대로 시스템 타임존을 한국 시간으로 맞추기 위해 환경변수를 주입한 예시입니다.

[Java/Spring] 인터페이스/추상클래스 JSON 변환이 안될 때? Jackson 다형성(Polymorphism) 완벽 해결법

bj-lee — Sun, 4 Jan 2026 14:11:46 +0900

API 개발을 하다 보면 추상 클래스나 인터페이스를 상속받은 여러 하위 클래스를 하나의 리스트로 주고받아야 할 때가 있습니다. 하지만 이를 아무 설정 없이
JSON으로 변환하고 다시 객체로 받으려 하면, Jackson 라이브러리는 하위 클래스 중 어떤 것으로 변환해야 할지 몰라 에러를 발생시킵니다.

오늘은 실무에서 반드시 마주하게 되는 Jackson의 다형성 처리 방법을 정리해 보겠습니다.

왜 에러가 발생할까?

자바에서는 상속 관계가 명확하지만, JSON은 단순한 텍스트 구조입니다.

예를 들어, 알림(Notification)이라는 추상 클래스를 이메일과 SMS 알림이 상속받고 있다고 가정해 봅시다. 이를 리스트로 만들어 JSON으로 변환하면 다음과 같이
보입니다.

  \[  
    { "receiver": "userA", "content": "이메일 내용", "subject": "제목" },  
    { "receiver": "userB", "content": "SMS 내용", "phoneNumber": "010-0000-0000" }  
  \]

이 데이터를 다시 자바 객체로 역직렬화하려고 하면, Jackson은 각 요소가 이메일인지 SMS인지 구별할 방법이 없습니다. 결과적으로 에러가 발생하거나, 데이터가
누락된 채 변환되어 버립니다.

해결 방법: 타입 힌트 제공

Jackson에서 제공하는 어노테이션을 사용하면 JSON 데이터에 "이 객체는 어떤 클래스다"라는 표식을 남길 수 있습니다.

상세 코드 예시

  import com.fasterxml.jackson.annotation.JsonSubTypes;  
  import com.fasterxml.jackson.annotation.JsonTypeInfo;  
  import lombok.Getter;  
  import lombok.NoArgsConstructor;  

  @JsonTypeInfo(  
      use = JsonTypeInfo.Id.NAME,  
      include = JsonTypeInfo.As.PROPERTY,  
      property = "type",  
      visible = true  
  )  
  @JsonSubTypes({  
      @JsonSubTypes.Type(value = EmailNotification.class, name = "EMAIL"),  
      @JsonSubTypes.Type(value = SmsNotification.class, name = "SMS")  
  })  
  @Getter  
  @NoArgsConstructor  
  public abstract class Notification {  
      private String receiver;  
      private String content;  
      private String type;  
  }  

  @Getter  
  @NoArgsConstructor  
  public class EmailNotification extends Notification {  
      private String subject;  
  }  

  @Getter  
  @NoArgsConstructor  
  public class SmsNotification extends Notification {  
      private String phoneNumber;  
  }

변환된 JSON 결과물

이제 Jackson은 자동으로 type 필드를 추가하며, 이를 통해 정확한 하위 클래스를 찾아냅니다.

  {  
    "type": "EMAIL",  
    "receiver": "userA",  
    "content": "이메일 내용",  
    "subject": "제목"  
  }

실무자를 위한 보안 팁

주의할 점은 전체 패키지 경로를 노출하는 설정을 피하는 것입니다.

* 패키지 경로 노출의 위험성: JSON에 실제 클래스 경로가 포함되면 보안상 취약할 수 있습니다.
* 해결책: 해커가 클래스 경로를 조작하여 공격하는 것을 방지하기 위해 별칭 방식을 사용해야 합니다.

권장 사항: 별칭을 사용하는 방식을 선택하고, 허용할 클래스 리스트를 명시하는 화이트리스트 방식을 사용하시기 바랍니다.

요약 및 결론

Jackson의 다형성 처리는 유연한 API 설계를 위해 필수적인 기술입니다.

* 구분 필드 지정: 어떤 필드명으로 타입을 구분할지 결정합니다.
* 클래스 매핑: 실제 하위 클래스들과 별칭을 연결합니다.
* 보안 강화: 전체 클래스 경로 노출보다는 별칭 사용을 적극 권장합니다.

[CES 2026 프리뷰] 생성형을 넘어 '행동'하는 AI로

bj-lee — Thu, 1 Jan 2026 22:04:40 +0900

서론: 2026년, AI 패러다임의 거대한 전환

2026년 새해가 밝았다.

IT 업계의 시선은 이미 다음 주, 미국 라스베이거스에서 개최될 세계 최대 가전·IT 전시회 **'CES 2026'**으로 쏠려 있다. 매년 CES는 그 해의 기술 트렌드를 관통하는 키워드를 제시해 왔다. 2024년과 2025년이 '생성형 AI(Generative AI)'의 가능성을 탐색하고 확산하는 시기였다면, 2026년은 명확히 **'에이전틱 AI(Agentic AI, 에이전트 AI)'**가 주인공이 될 전망이다.

단순히 텍스트나 이미지를 만들어내는 것을 넘어, 스스로 판단하고 도구를 사용하여 물리적·디지털 과업을 완수하는 '행동하는 AI'. 이번 포스팅에서는 CES 2026의 핵심 화두인 에이전틱 AI의 개념과 이를 구현하는 기술, 그리고 우리가 주목해야 할 관전 포인트를 심층 분석한다.

1. 정의: 에이전틱 AI(Agentic AI)란 무엇인가?

우리는 지난 2년간 거대언어모델(LLM)의 비약적인 발전을 목격했다. 하지만 기존의 LLM은 챗봇 창 안에서 답변을 생성하는 수동적인 역할에 머무는 경우가 많았다.

에이전틱 AI는 기존 AI의 한계를 뛰어넘는 개념이다. 사용자가 모호한 목표를 제시하더라도, AI가 스스로 세부 계획을 수립하고(Planning), 필요한 도구(API, 소프트웨어, 로봇 팔 등)를 선택하여(Tool Use), 최종 결과를 수행하는(Execution) 자율적인 시스템을 의미한다.

기존 AI (Chatbot): "비행기 표 예매 사이트 알려줘." (정보 제공)
에이전틱 AI: "다음 주 도쿄 출장 일정 잡아줘." → 사용자의 캘린더 확인, 항공권 최저가 검색 및 결제, 호텔 예약, 현지 교통편 어레인지까지 스스로 수행. (행동 및 완결)

전문가들은 이번 CES 2026이 '대화형 AI(Chat AI)'에서 '행동형 AI(Action AI)'로 넘어가는 변곡점이 될 것으로 보고 있다.

2. CES 2026의 핵심 전장: 한국 기업 약진과 기술 격전

CES 2026 혁신상 수상 결과는 한국 기업들의 기술적 우위를 증명했다. 전체 혁신상 수상 기업 중 약 60%가 한국 기업이라는 점은 고무적이다. 특히 삼성전자, LG전자 등 대기업뿐만 아니라 딥테크 스타트업들이 에이전틱 AI 생태계의 주도권을 잡기 위해 나섰다.

① 삼성전자와 LG전자: 'AI 집사'의 완성

가전 업계의 화두는 단연 '초개인화된 AI 에이전트'다.

삼성전자: 자사의 AI 플랫폼 '스마트싱스'에 고도화된 에이전트 기능을 탑재, 기기 간 연결을 넘어 사용자의 생활 패턴을 예측하고 선제적으로 가전을 제어하는 기술을 선보인다.
LG전자: '공감지능(Affectionate Intelligence)'을 앞세워, 사용자의 감정과 맥락을 이해하는 AI 에이전트 로봇을 공개할 예정이다. 이는 단순한 명령 수행을 넘어 정서적 교감까지 가능한 단계로의 진화를 의미한다.

② 모빌리티(SDV): 움직이는 AI 에이전트

현대차그룹을 비롯한 모빌리티 기업들은 자동차를 '소프트웨어 중심 자동차(SDV)'로 정의하고, 차량 자체를 하나의 거대한 AI 에이전트로 탈바꿈시켰다. CES 2026에서는 차량 내 인포테인먼트 시스템이 운전자의 스케줄 관리, 차량 상태 진단, 자율주행 경로 최적화를 능동적으로 수행하는 기술이 대거 시연될 것이다.

3. 기술적 기반: 온디바이스 AI와 로보틱스의 결합

에이전틱 AI가 실생활에 적용되기 위해서는 두 가지 핵심 기술의 뒷받침이 필수적이다.

① 온디바이스 AI (On-Device AI)의 필수화

AI가 실시간으로 판단하고 행동하기 위해서는 클라우드를 거치지 않고 기기 자체에서 연산을 처리하는 '온디바이스 AI'가 필수적이다. 인터넷 연결 없이도 보안성을 유지하며 빠른 응답 속도를 보장해야 하기 때문이다. 이에 따라 인텔, 퀄컴, 삼성전자 등이 선보일 차세대 NPU(신경망처리장치) 칩셋 성능 경쟁도 이번 CES의 주요 관전 포인트다.

② 휴머노이드 로봇의 실용화

에이전틱 AI의 '물리적 신체'가 될 휴머노이드 로봇 기술도 비약적으로 발전했다. 테슬라의 옵티머스, 현대차의 보스턴 다이내믹스 등이 선보일 로봇들은 이제 걷거나 춤추는 퍼포먼스를 넘어, 설거지를 하거나 물건을 정리하는 등 인간의 노동을 대체하는 '유틸리티' 기능을 강조할 것이다. 에이전틱 AI가 두뇌라면, 로보틱스는 그 손발이 되어 물리적 세계에 개입하게 된다.

4. 시사점 및 전망: '편리'를 넘어 '위임'의 시대로

CES 2026을 기점으로 우리는 AI에게 업무를 '보조'받는 단계를 지나, 업무를 완전히 **'위임(Delegation)'**하는 시대로 진입하게 된다.

이는 기업에게는 엄청난 생산성 향상을, 개인에게는 시간의 자유를 의미한다. 하지만 동시에 해결해야 할 과제도 명확하다. AI가 자율적으로 행동할 때 발생할 수 있는 오작동(Hallucination)에 대한 안전장치, 그리고 AI의 행동에 대한 책임 소재를 명확히 하는 법적·윤리적 논의가 기술 발전 속도에 맞춰 진행되어야 한다.

결론적으로, CES 2026은 AI 거품론을 잠재우고 '돈이 되는 AI', '실질적 효용을 주는 AI'를 증명하는 자리가 될 것이다. 투자자라면 에이전틱 AI를 구현하는 소프트웨어 기업뿐만 아니라, 이를 구동할 하드웨어(반도체, 로봇 부품) 밸류체인에 주목할 필요가 있다.

[마무리 요약]

CES 2026 에 대표 주제들

CES 2026의 핵심: 생성형 AI를 넘어 자율적으로 행동하는 '에이전틱 AI'의 대두.
주요 플레이어: 혁신상을 휩쓴 한국 기업(삼성, LG, 스타트업)들의 기술 리더십 주목.
기술 트렌드: 온디바이스 AI와 로보틱스의 결합으로 AI의 물리적 영향력 확대.
전망: 보조(Assistant)에서 위임(Agent)으로의 패러다임 시프트 본격화.

이 글은 CES 2026 프리뷰 분석글이며, 특정 종목에 대한 투자 권유가 아닙니다.

나 대신 주식 매매하는 AI 군단(Alpha Squad) 만들기

bj-lee — Thu, 1 Jan 2026 00:58:30 +0900

DAY 1

주식 매매하는 AI 군단(Alpha Squad)

프롤로그: 왜 우리는 모니터 앞에서 늙어야 하는가

2026년이 찾아왔습니다.

그래서 올해는 다를꺼야!! 라며 시작한게 있습니다. 그 내용을 공유할까 합니다.

직장인 투자자에게 '단타(Day Trading)'는 금단의 영역입니다.

상사는 업무를 지시하고, 회의는 끊이지 않는데, 주식 시장은 나를 기다려주지 않습니다.

특히 밤새 열리는 미국 시장(Nasdaq)을 보려면 잠을 포기해야 합니다.

미국장 하는 아저씨

"내가 일할 때 나 대신 차트를 보고, 내가 잘 때 나 대신 매매하는

'지능형 에이전트'가 있다면?"

나름 개발자인 나인데 말이야..

그런데, 단순한 매수 봇을 만들고 싶지는 않았습니다.

뉴스를 읽고(News Reader), 차트를 분석하며(Analyst), 리스크를 계산하고(Risk Manager), 서로 토론하여 의사결정을 내리는(Leader) 그런 팀을 만들고 싶었습니다.

아무래도 저의 업무가 개발영역이다보니 AI 를 접할 일이 많았고 -나도 모르는 사이- 이미 저의 삶에 깊게 관여하고 있었습니다.

그래서 시작했습니다.

코드명 Azrael Project입니다.

Azreal 은 제가 게임에서 주로 사용하는 케릭터명이기도 합니다. ^^

프로젝트 준비 (Setup & Configuration)

이 프로젝트는 Python 기반이며,

LLM(Google Gemini)의 추론 능력과 한국투자증권(KIS)의 Open API 로 설계를 했습니다.

디렉토리 구조는 깔끔한 monorepo 형태로 구성하고자 했습니다.

사실 실제는 아래보다 더 많은 구성이 되어 있지만 아래가 핵심입니다.

Azrael/
├── config/                 # 설정 파일 (API Key, 페르소나 정의)
│   ├── config.yaml         # KIS API 및 Gemini Key
│   └── personas.yaml       # 전담분야별 전문가들의 성격 및 역할 정의
├── common/                 # 공통 유틸리티 (로거, Gemini 클라이언트)
├── trading_system/         # 핵심 트레이딩 엔진
│   ├── agents/             # 투자팀 고유 영역별 판단 시스템 (Leader, Screener, Sniper...)
│   ├── broker_api/         # 증권사 연동 Agent (KIS Agent)
│   └── core/               # 가상 장부(PaperTrader), 리포터
├── main.py                 # 실행 진입점 (CLI)
└── requirements.txt        # 의존성 패키지

핵심 설정 파일은 보안이 생명이므로 ..!!

kis_api:
  app_key: "YOUR_KIS_APP_KEY"
  base_url: "https://openapi.koreainvestment.com:9443" # 실전투자용, 모의투자는 주소 다름
  is_simulation: false  # 실전/모의 투자 선택

google_api_key: "YOUR_GEMINI_API_KEY"

common:
  timezone: "Asia/Seoul"

가상 환경은 python 을 이용하여 venv 로 했고 아래와 같은 lib 들을 사용했습니다

pandas
numpy
pyyaml
yfinance
requests
google-generativeai
matplotlib
mplfinance

시스템 아키텍처: "The Alpha Squad"

그래서 최종 시스템 아키텍처는 대략 아래와 같습니다.

처음에는 단일 LLM 으로 구성해서 테스트 코드를 돌려봤습니다.

동일한 종목으로 시도했고, 결과는 매번 새로웠(?) 습니다..

AI 의 할루시네이션

넌 대체 왜그러니? 너 똑똑하다며! 이래서 믿고 투자를 맡기겠어!?

이제는 공공연하게도 아시는 것 처럼 모든 AI는 환각(Hallucination)이 발생합니다.

fator 수치가 AI 마다 있어서 질문할때마다 여러 후보군 중 하나를 선택하는 알고리즘과

이를 조절하는 하이퍼파라미터라 하는 설정값 때문입니다.

즉, 한놈에게 시키면 계속 변덕을 부리거나 두루뭉술한 답변만 내놓습니다.

그래서 대안을 마련해야 했고, 저는 단일 LLM이 아닌 팀으로 하면 되겠네? 였습니다.

마치 어벤져스 어셈블 처럼요!!

AI 투자팀 어셈블~!!

짜짠~!!!

Azrael 프로젝트는 그렇게 역할을 쪼개어 **9명의 전문가 팀(Alpha Squad)**을 구성했고,

추가로 나중에 한명이 더 추가됐습니다. ^_^

알파스쿼드의 주요 페르소나를 몇 소개해 드릴께요.

이들은 `config/personas.yaml`에 정의되어 있으며,

각자 다른 AI Temperature(창의성 지수)를 가집니다.

1. ️ News Scout (뉴스 정찰병)

* 임무: 장 시작 전 Google Search를 통해 시장 분위기(Sentiment)를 파악합니다.

* Instruction: "Fed 금리 결정, 전쟁 이슈 등 거시적 악재를 찾아라."

2. ️ Gatekeeper (문지기 / Ticker Screener)

* 성격: 냉소적, 보수적 (Temp: 0.0)

* 임무: 거래량 부족, 동전주, 관리종목 등 '위험한 놈'들을 입구컷합니다.

* 대사: "이 종목은 거래량이 너무 적어. 탈락."

3. Sniper (저격수 / Trade Planner)

* 성격: 침착함, 정밀함 (Temp: 0.1)

* 임무: 살아남은 종목의 차트를 현미경처럼 분석하여 '진입가', '손절가', '목표가'를 1원 단위로 제시합니다.

* 대사: "187.50불에 지정가 매수. 추격 매수는 금지한다."

4. Leader (CIO)

* 임무: 이들의 보고를 취합하여 자금을 배분하고, 최종 매수 버튼을 누릅니다.

Workflow: Azreal 의 하루

AI 투자팀 어셈블~!!

Azrael은 다음과 같은 흐름으로 하루를 보냅니다.

1.  **09:00 (Start Day):**
    *   Leader 기상.
    *   News Scout가 "오늘 기술주 분위기 안 좋음" 보고.
    *   Kis Agent가 관심 종목(NVDA, MSFT 등) 데이터 수집.
2.  **09:05 (Analysis):**
    *   Gatekeeper가 거래량 부족 종목 필터링.
    *   Sniper가 남은 종목의 매수 타점 계산.
    *   Leader가 가상 장부(Paper Ledger)에 매수 기록.
3.  **09:10 ~ 15:20 (Monitoring):**
    *   **Watcher Mode** 진입. 1분마다 시세 확인.
    *   목표가 도달 시 익절, 손절가 이탈 시 손절.
4.  **15:20 (EOD Judgement):**
    *   장 종료 10분 전, 아직 안 팔린 종목에 대해 **"종가 심판"** 진행.
    *   Leader가 Gemini에게 묻습니다. **"지금 수익률 0%인데 뉴스도 없어. 가져갈까(HOLD) 팔까(SELL)?"**
    *   AI 판단에 따라 오버나잇(Swing) 하거나 전량 매도(Day Trading) 처리.

물론, 오버나잇 전략이나 매도 전략은 미리 개별 페르소나들의 구현에 정의되어 있습니다.

초기 전략이라 구멍이 많을 수 밖에 없을 거라고 생각합니다.

그래서, 매일 기록을 쌓아가면서 수정계획을 갖고 있습니다.

시뮬레이션 결과 (Simulation Log)

개발하면서 시뮬레이션 결과는 엣지 케이스가 생각보다 많아서 멀구나..였습니다.

아래는 구현된 프로젝트에서 남긴 log 의 일부이고

시험 대상은 2025년 12월 31일 프리마켓이였습니다.

[Gatekeeper Report]

NVDA: 거래량이 평소보다 적지만(193만 주), 시총을 고려할 때 통과(Pass). MSFT: 거래량 극히 저조. 탈락(Fail).

출처 입력

[Sniper Report]

NVDA 분석: 상승 추세이나 볼린저 밴드 상단 터치. 눌림목 매수 유효. 진입가: $187.26 목표가: $193.98 손절가: $181.30

출처 입력

[Execution]

[PaperTrade] Signal Detected: Buy NVDA @ 187.26 [PaperTrade] BOUGHT NVDA : 5 shares @ 187.26 (TP: 193.98, SL: 181.3)

[PaperTrade] BOUGHT NVDA : 5 shares @ 187.26 (TP: 193.98, SL: 181.3)

보시는 것 처럼, 장초반에 당연히 적을 수 밖에 없는 거래량을 생각하지 못했습니다.

Gatekeeper 는 정확한 판단으로 탈락시켰지만 이러면 살 종목이 ....

그래서 최근 거래일의 거래량 정보를 반영하도록 수정도 하고

또 다른 문제가 계속 생겼습니다. 하지만!! 시작이 반이라 했죠.

이제 시작일 뿐입니다.

존버는 승리한다. (응??) 계속 지켜보고 고치다 보면 잘 되겠죠? 훗

- 내 마음 中

단순하게 실행은 dry-run 과 live 모드로 구분을 했습니다.

당분간은 paper 모드로 시도해보면서 결과를 축적할 생각입니다.

마치며

처음엔 "파이썬으로 주식이나 사볼까?"로 시작했지만, 결과물은 나만의 투자 철학을 대변하는 AI 팀이 되었습니다.

이 시스템의 가장 큰 장점(사람의 가장 큰 단점이죠.)은 **"뇌동매매를 하지 않는다"**는 것입니다.

AI는 감정에 휘둘리지 않고, 정해진 원칙(Persona)대로만 움직입니다.

2026년, Azrael 과 함께 시장을 이겨보겠습니다.

다들 2026년 새해 복 많이 받으세요!!

산타 랠리의 역설: 거래량이 말랐을 때 주가가 폭발하는 진짜 이유

bj-lee — Sat, 27 Dec 2025 20:23:10 +0900

"미국도 연말엔 세금 정산하느라 바쁘고, 휴가 가서 거래량도 없을 텐데 주가가 오를까요?"

많은 투자자분들이 연말 '산타 랠리(Santa Claus Rally)'에 대해 갖는 합리적인 의구심입니다. 상식적으로 생각하면, 시장 참여자가 줄어드는 휴가 시즌에는 증시가 조용해야 맞습니다. 하지만 월스트리트의 역사는 정반대의 결과를 보여줍니다.

오늘은 오로지 저의 시각으로, 악조건 속에 숨겨진 산타 랠리의 구조적 비밀을 파헤쳐 봅니다.

1. 매도 압력의 실종 (Selling Exhaustion)

많은 분이 "세금 때문에 주식을 팔 것"이라고 걱정합니다. 맞습니다. 미국 투자자들은 절세(Tax-loss harvesting)를 위해 손실 난 주식을 팝니다. 하지만 그들은 12월 말까지 기다리지 않습니다.

스마트 머니와 기관들은 보통 11월 말부터 12월 중순 사이에 매도 처리를 완료합니다. 즉, 산타 랠리 기간(한 해의 마지막 5거래일 + 새해 첫 2거래일)이 도래했을 때는 **'팔 사람은 이미 다 팔고 떠난 상태'**가 됩니다. 누르는 힘(매도)이 사라지니, 작은 힘(매수)으로도 주가가 튀어 오르는 것입니다.

2. 텅 빈 호가창의 마법 (Thin Market)

"유동성이 적다"는 것은 양날의 검입니다. 거래량이 풍부할 때는 100억 원을 사야 주가가 1% 오르지만, 모두가 휴가를 떠나 호가창이 얇아진(Thin Liquidity) 상태에서는 10억 원만 들어와도 주가가 1% 급등할 수 있습니다.

기관들은 휴가를 떠났지만, 연말 보너스를 받은 개인 투자자들의 낙관적인 매수세가 텅 빈 시장에 들어오면 시세는 평소보다 훨씬 가볍고 빠르게 반응합니다. 이것이 유동성 부족이 만드는 역설적인 급등입니다.

3. 기관의 성적표 관리 (Window Dressing)

펀드 매니저들은 연말 결산 보고서에 자신들의 포트폴리오를 '예쁘게' 보여주고 싶어 합니다. 수익률이 저조한 종목은 숨기고, 시장을 주도한 인기 종목(예: 엔비디아, 테슬라 등)을 보유한 것처럼 보이기 위해 연말 직전에 해당 종목들을 집중 매수합니다.

이를 **윈도우 드레싱(Window Dressing)**이라고 합니다. 이 인위적인 막판 매수세가 지수를 견인하는 강력한 동력이 됩니다.

데이터는 거짓말을 하지 않습니다

역사적으로(1950년 이후), S&P 500 지수는 산타 랠리 기간(7거래일) 동안 약 79%의 확률로 상승했습니다. 평균 수익률은 1.3%입니다. 이는 단순한 우연이라기보다, 위에서 언급한 수급 공백과 심리가 만들어낸 구조적인 패턴입니다.

투자자를 위한 Action Plan

산타 랠리는 크리스마스 선물이 아닙니다. 철저한 확률 게임입니다.

진입 적기: 크리스마스 전후, 거래량이 줄어들며 시장이 소강상태를 보일 때가 기회입니다.
경고 신호: 만약 이 기간에 산타 랠리가 오지 않고 주가가 하락한다면? 월가 격언을 기억하십시오. "산타가 오지 않으면, 곰(하락장)이 찾아온다." 이는 내년 시장이 어려울 수 있다는 강력한 선행 지표가 됩니다.

결론

최근 10년(2014년~2024년)간 S&P 500 지수 기준, '산타 랠리(Santa Claus Rally)' 기간의 등락률을 AI를 이용하여 뽑았습니다.

7년의 파티, 그리고 숙취: 미장의 지난 7년간 산타는 매년 선물을 주고 갔지만, 작년(23-24 시즌)에는 빈손으로 돌아갔습니다. 이는 올해(2025년) 시장에 대한 일종의 '경고'였을 수도 있습니다.
작지만 확실한 수익: 상승한 해의 평균 수익률은 약 +0.9% 내외입니다. "대박"이라기보다는 **"짧은 기간 동안 높은 확률로 얻는 보너스"**에 가깝습니다.
역발상 투자: 그래프에서 보시다시피, 2년 연속 하락(14, 15년) 후에는 긴 상승장이 찾아왔습니다. 작년의 하락이 오히려 올해 산타 랠리의 기대감을 높이는 요소가 될 수도 있습니다.

참고: 산타 랠리 기간은 매년 마지막 5거래일 + 새해 첫 2거래일, 총 7거래일을 기준으로 산출했습니다.

산타랠리 조선일보 기사 중

시장이 조용하다고 해서 기회가 없는 것은 아닙니다. 오히려 모두가 방심한 그 '고요함' 속에 수익의 기회가 숨어 있습니다.

체감온도 영하 20도? 이 노래 하나면 바로 '인간 핫팩' 등극!

bj-lee — Fri, 26 Dec 2025 22:48:22 +0900

추운 겨울 따뜻한 실내 분위기

와, 오늘 진짜 역대급 추위 아니었나요?!

여러분! 오늘 출근길, 등굣길 다들 무사하셨나요? 저는 문밖을 나서는 순간 '아, 이건 그냥 추운 게 아니라 아픈 거다' 싶더라고요. 뉴스 보니까 체감 온도가 영하 20도까지 떨어졌다는데, 정말 롱패딩을 뚫고 들어오는 칼바람에 정신이 하나도 없었습니다. 다들 꽁꽁 얼어붙은 몸 녹이느라 고생 많으셨어요!

하지만 우리가 누구입니까? 이깟 추위에 질 수 없죠! 몸은 추워도 마음만은 뜨겁게 불태워야 하지 않겠어요? 이렇게 뼛속까지 시린 날에는 분위기를 확 바꿔줄 강력한 음악 처방이 필요합니다. 그래서 제가 오늘 여러분의 언 마음을 순식간에 녹여버릴, 성능 확실한 '음악 보일러' 하나를 들고 왔습니다! 준비되셨나요?

오늘의 강력 추천곡: 아이유 (IU) - '겨울잠 (Winter Sleep)'

오늘 같은 날, 제가 자신 있게 꺼내든 카드는 바로 '국힙원탑' 아니죠, '감성원탑' **아이유의 '겨울잠'**입니다! "에이, 활기차게 가자더니 웬 잔잔한 발라드?" 하시는 분들 계시죠? 천만의 말씀! 이 노래가 가진 내공은 상상 이상이거든요.

이 곡은 아이유가 20대를 마무리하며 발표한 [조각집] 앨범의 첫 번째 트랙인데요. 화려한 악기 소리 다 빼고, 오직 담백한 피아노 선율과 아이유의 목소리만으로 꽉 채웠습니다. 그런데 그 힘이 얼마나 대단한지, 첫 소절 듣는 순간 차가웠던 공기가 따뜻하게 바뀌는 마법을 경험하게 된다니까요?

왜 하필 이 추운 날 '겨울잠'이어야 할까요?

첫째, 밖은 시베리아지만 내 귀는 따뜻한 온돌방이니까요! 밖에서 오들오들 떨다가 따뜻한 실내에 들어왔을 때의 그 노곤한 느낌 아시죠? 이 노래가 딱 그렇습니다. 아이유 특유의 숨소리 섞인, 약간은 쓸쓸한 듯하면서도 한없이 다정한 목소리가 얼어붙은 우리 마음을 포근한 이불처럼 감싸줍니다. 듣고 있으면 마치 성능 좋은 난로 옆에 앉아있는 것처럼 마음의 온도가 1도, 2도 올라가는 게 느껴지실 거예요.

둘째, '혼자가 아니다'라는 강력한 위로의 메시지 때문입니다. 추운 겨울은 유독 사람을 외롭게 만들잖아요. 이 곡은 아이유가 먼저 떠난 소중한 존재들을 그리워하며 직접 쓴 곡이에요. 가만히 가사를 곱씹어 보면, 차가운 계절 속에 홀로 남겨진 것 같은 외로움을 다독여주는 힘이 있습니다. "네가 깊은 잠을 자는 동안, 내가 곁을 지킬게" 같은 가사는 이 혹독한 추위 속에서 나를 지켜주는 든든한 지원군을 만난 기분이 들게 하죠. 겉으로는 잔잔해 보여도, 그 안에 담긴 감정의 에너지는 엄청나게 뜨겁습니다!

오늘 이 노래, 200% 즐기는 꿀팁!

그냥 들어도 좋지만, 오늘 같은 날엔 이렇게 한번 들어보세요!

가장 편한 옷으로 갈아입고, 극세사 이불 속에 파고듭니다. (전기장판 필수!)
따뜻한 핫초코나 김이 모락모락 나는 차를 한 잔 준비합니다. ☕
방 불을 끄고 무드등이나 캔들만 켜서 아늑한 분위기를 만듭니다.
창밖의 살벌한 풍경을 한번 쓱 봐주고, 이어폰을 꽂고 '겨울잠'을 재생합니다.

이 코스면 오늘 추위 때문에 쌓인 스트레스? 바로 녹아내립니다. 장담해요!

자, 서론이 너무 길었네요. 백문이 불여일청! 제가 정말 좋아하는, 뮤직비디오보다 더 따뜻한 감성이 느껴지는 라이브 클립 버전을 준비했습니다. 귀 호강할 준비 되셨죠? 바로 재생 버튼 눌러보세요!

여러분! 내일도 엄청 춥다고 하니까 옷장 속에 있는 가장 두꺼운 옷 꺼내 입으시고요! 목도리, 장갑, 핫팩 완전 무장 필수인 거 아시죠? 감기 절대 걸리지 마시고, 오늘 밤은 아이유의 따뜻한 목소리와 함께 세상에서 가장 포근한 밤 보내시길 바랍니다! 우린 다음 포스팅에서 더 건강한 모습으로 만나요! 안녕!

당신이 몰랐던 크리스마스의 '이교도적' 기원: 동지, 로마, 그리고 오딘

bj-lee — Thu, 25 Dec 2025 00:18:17 +0900

"우리가 몰랐던 크리스마스의 이면: 로마의 태양신과 북유럽의 오딘"

[인문학 산책] 당신이 몰랐던 크리스마스의 '이교도적' 기원: 동지, 로마, 그리고 오딘

거리마다 캐럴이 울려 퍼지고, 구세군 냄비의 종소리가 들리는 12월 24일입니다. 우리는 오늘을 아기 예수의 탄생일로 기념하며 축복을 나눕니다. 하지만 시간을 거슬러 올라가면, 이 날짜에는 예수의 탄생보다 훨씬 더 오래된 인류의 두려움과 희망, 그리고 신화가 얽혀 있다는 사실을 알고 계신가요?

오늘은 우리가 당연하게 여기는 크리스마스의 풍경 속에 숨겨진, 조금은 낯설고 매혹적인 고대의 이야기를 꺼내보려 합니다.

1. 12월 25일은 원래 '태양'의 생일이었다

사실 성경 그 어디에도 예수가 12월 25일에 태어났다는 기록은 없습니다. 목자들이 양을 치고 있었다는 묘사로 미루어 보아, 오히려 따뜻한 봄이나 가을이었을 것이라는 추측이 지배적이죠. 그렇다면 왜 하필 12월 25일일까요?

크리스마스와 고대 신화

그 답은 고대 로마에 있습니다. 로마인들에게 12월 말은 '사투르날리아(Saturnalia)'라는 거대한 축제 기간이었습니다. 농경의 신 사투르누스에게 제사를 지내며, 노예와 주인이 자리를 바꾸고 선물을 교환하며 먹고 마시는, 일종의 '해방구'였던 셈입니다.

그리고 12월 25일은 로마의 태양신 '솔 인빅투스(Sol Invictus, 정복되지 않는 태양)'의 탄생일이었습니다. 이날은 일 년 중 밤이 가장 긴 동지(冬至) 무렵입니다. 고대인들에게 해가 가장 짧아지는 동지는 곧 '빛의 죽음'과 같았습니다. 하지만 동지가 지나면 태양은 다시 길어지며 부활합니다. 즉, 12월 25일은 태양이 다시 살아나는 날, 어둠을 이기고 빛이 승리하는 날이었던 것입니다.

기독교가 로마에 공인되면서, 교회는 이교도들의 가장 큰 축제인 동지 축제를 배척하기보다 포용하는 전략을 택했습니다. "세상의 빛"으로 오신 예수의 의미를 태양의 부활과 중첩시킨 것이죠. 그렇게 태양신의 생일은 성탄절이 되었습니다.

2. 산타클로스의 원형은 '애꾸눈 신' 오딘이다?

우리가 아는 빨간 옷의 산타클로스는 1930년대 코카콜라 마케팅이 정립한 이미지라는 것은 널리 알려진 사실입니다. 성 니콜라오 주교라는 실존 모델도 있지만, 산타가 '하늘을 나는 썰매'를 타고 '굴뚝'으로 들어와 '선물'을 준다는 설정은 북유럽 신화에서 기원합니다.

크리스마스와 고대 신화2

북유럽의 바이킹들은 12월 중순부터 1월 초까지 '율(Yule)'이라는 축제를 즐겼습니다. 이 시기 북유럽의 겨울은 춥고 어두웠습니다. 사람들은 밤하늘을 가로지르는 거대한 폭풍과 유령들의 행진, 즉 '와일드 헌트(The Wild Hunt)'가 일어난다고 믿었습니다.

이 행진을 이끄는 존재가 바로 북유럽 최고의 신, 오딘(Odin)입니다.

긴 흰 수염을 휘날리는 노인
다리가 여덟 개 달린 말 '슬레이프니르'를 타고 밤하늘을 비행
사람들은 오딘의 말이 쉴 수 있도록 장화나 나막신에 당근과 건초를 넣어두었고(양말의 기원), 오딘은 그 보답으로 사탕이나 선물을 남겼습니다.

크리스마스와 고대 신화3

굴뚝을 타고 내려오는 전설 또한 고대 게르만족이 집의 난로(Hearth)를 신성시하던 풍습에서 유래했습니다. 무시무시한 전쟁의 신 오딘이 아이들에게 선물을 주는 인자한 할아버지로 변모한 과정, 흥미롭지 않나요?

3. 크리스마스 트리: 죽지 않는 생명에 대한 경외

집 안에 나무를 들여놓고 장식하는 풍습 역시 기독교 이전의 것입니다. 고대인들에게 겨울은 모든 생명이 죽어가는 공포의 시간이었습니다. 하지만 전나무나 소나무 같은 상록수(Evergreen)는 한겨울에도 푸른 잎을 유지했습니다.

북유럽과 게르만족 사람들은 이 상록수에 신비한 생명력이 깃들어 있다고 믿었습니다. 동지 축제 기간인 '율'에 이 나무를 집 안으로 들여오거나 숲에서 장식을 달며, 다가올 봄을 기원하고 악귀를 쫓으려 했습니다.

결국 크리스마스 트리는 '죽음(겨울) 속에서도 결코 사라지지 않는 생명'을 상징하는 고대의 토템이었던 셈입니다.

크리스마스와 고대 신화4

4. 마치며: 어둠 속에서 불을 밝히는 마음

크리스마스의 기원이 이교도의 축제였다고 해서 그 의미가 퇴색되는 것은 아닙니다. 오히려 더 깊은 울림을 줍니다.

수천 년 전 로마인이든, 북유럽의 바이킹이든, 2025년의 우리든, 인간은 본능적으로 '어둠'을 두려워하고 '빛'을 갈구합니다. 일 년 중 가장 밤이 긴 시간에, 서로의 체온을 나누고 불을 밝히며 "우리는 아직 살아있고, 곧 봄이 올 거야"라고 확인하는 의식. 그것이 크리스마스의 본질 아닐까요?

종교를 떠나, 오늘 밤 켜진 트리와 조명들을 보며 생각해보셨으면 좋겠습니다. 저 불빛들은 아주 먼 옛날부터 인류가 추위와 어둠에 맞서 쏘아 올린 희망의 신호탄이라는 것을요.

모두 따뜻하고, 의미 있는 크리스마스 보내시길 바랍니다. 메리 크리스마스!!