내가 한 작업

• 5개 인터페이스 분해, 의존성 방향, 계층 구조, 워크 플로우
• 수집 → 분류 → 백로그 → 수정 → MR의 파이프라인 설계
• 2단계 분류 게이트, 캐싱 전략, 메서드 단위 추출 등 기능과 목적 정의
• "수정 정확도를 높여라", "토큰 비용을 줄여라" 같은 목적을 제시하고 최신 연구를 찾아 적용하도록 지시
• 테스트 결과 분석 및 개선점 도출
• 자동화 범위 설정
• 목적 정리 및 이유

AI가 한 작업

• 목적에 맞는 최신 연구/논문을 찾아서 설계에 반영 (Meta-Harness, 토큰 최적화 등)
• 설계 명세에 따라 인터페이스, 구현체, 비즈니스 로직, 테스트 코드 작성
• 스택트레이스를 보고 실제 운영 코드의 버그 수정
• 실패한 수정 시도를 분석해 다음 전략 제안 (Counterfactual Diagnosis)

설계 문서를 작성하고, 테스트 결과를 분석하고, 아키텍처 방향을 잡는 것은 사람의 몫이다. AI는 그 설계대로 구현하고, 정해진 범위 안에서 코드를 수정하는 도구다.

왜 만들었는가

이전에 Notion 백로그를 파싱해서 스펙과 프롬프트를 자동 생성하는 파이프라인을 만들어 봤다. 결과는 실패였다. 트레이드오프나 비즈니스 로직이 요구사항대로 반영이 잘 안 됐고, human review 단계에서 결국 매번 수정 요청을 다시 해야 했다.

그 경험에서 하나 배운 게 있다. AI 자동화가 통하려면 "정답이 하나인 영역"이어야 한다.

신규 기능 구현이나 비즈니스 로직 변경은 정답이 하나가 아니다. 왜 이 방향으로 만드는지, 어떤 트레이드오프가 있는지, 기획자와 개발자가 함께 고민해야 한다.

반면 서비스 운영 중 발생하는 오류(NullPointerException, NumberFormatException 등)와 N+1 쿼리 문제는 다르다. 문제가 명확하고, 테스트 케이스가 분명하다. 스택트레이스가 정확히 어디서 문제가 발생했는지 가리키고, 오류 메시지가 무엇이 잘못됐는지 알려준다. 수정 방향에 트레이드오프가 없다.

그런데 이 작업에도 개발자가 매번 같은 절차를 반복한다.

1. Datadog 알림 확인 (슬랙 또는 이메일)
2. Error Tracking 화면에서 스택트레이스 열기
3. 해당 코드 찾기 — IDE에서 클래스명 검색, 메서드 위치 특정
4. 원인 분석 — 왜 NPE가 났는지, 어떤 경로에서 null이 들어왔는지
5. 코드 수정 — Optional 처리, null 체크, @EntityGraph 추가 등
6. 테스트 작성 또는 기존 테스트 수정
7. PR 작성 — 변경 사유, 스택트레이스, Datadog 링크 첨부
8. 리뷰 요청 → 머지

Datadog, Sentry 같은 관측 도구는 오류를 발견해 준다. 하지만 수정까지 해 주지는 않는다.

반대로 GitHub Copilot, Cursor 같은 AI 코딩 도구는 코드를 수정해 준다. 하지만 "무엇을 수정해야 하는지"를 사람이 판단해서 알려줘야 한다.

발견과 수정 사이의 빈 공간을 메우는 파이프라인을 만들었다. 이전 시도에서 실패한 "기능 구현 자동화"가 아니라, 문제가 명확한 오류 수정 자동화다.

자동화 범위를 먼저 정했다

모든 오류를 자동으로 고칠 수 있다는 뜻이 아니다. 자동화가 통하는 영역은 다음 세 조건을 동시에 만족하는 경우로 한정했다.

1. 증거가 있다 — 스택트레이스가 정확한 위치를 가리킨다
2. 수정 패턴이 정형화되어 있다 — Optional.get() → ifPresent(), N+1 → @EntityGraph 등
3. 비즈니스 판단이 필요 없다 — "이 로직을 어떻게 바꿀 것인가"가 아니라 "이 버그를 어떻게 고칠 것인가"의 문제다

이 조건을 벗어나는 작업 — 신규 기능, 비즈니스 로직 변경, DB 스키마 수정 — 은 처음부터 자동화 범위에서 제외했다. 이전 시도에서 배운 교훈이다.

AI에게 최신 연구를 찾아서 적용하라고 했다

이 프로젝트는 AI(Claude Code)로 개발했다. 내가 한 것은 기능과 목적을 정의한 것이고, 구현은 AI가 했다.

구현을 시키면서 두 가지를 요구했다.

첫 번째는 하네스 엔지니어링 적용이다. 나는 하네스 엔지니어링의 기능과 목적 — AI 수정이 실패했을 때 같은 실수를 반복하지 않도록 매 시도마다 접근 방식을 개선하는 것 — 을 알고 있었고, 이걸 적용하라고 지시했다. AI가 Stanford IRIS Lab의 Meta-Harness 연구를 참고해서 실패-학습 루프를 구현했다.

두 번째는 AI 토큰 비용 절감이다. 이쪽은 구체적인 방법론을 지정하지 않고, "토큰 비용을 줄여라, 최신 연구와 논문을 찾아서 적용해라"라고 지시했다. AI가 토큰 효율에 관한 연구들을 참고해서 메서드 단위 소스코드 추출, 캐싱 전략 등을 구현했다.

논문을 내가 직접 읽고 이해해서 설계에 반영한 것이 아니다. 내 역할은 기능과 목적을 정의하고, AI가 구현한 결과가 그 목적에 맞는지 검증하는 것이었다.

전체 워크플로우

Datadog에서 오류를 읽는 것부터 GitLab MR을 여는 것까지 사람 손이 닿지 않는다. 개발자가 개입하는 시점은 MR 검토 한 번뿐이다.

① Datadog REST API로 오류와 N+1을 수집한다

• Error Tracking API로 NPE, SQL 예외 수집
• Spans Analytics API로 N+1 쿼리 탐지
• 수집된 오류를 서비스별, 유형별로 정리

② 수정할 가치가 있는 이슈만 분류한다

1차 — 규칙 필터

• FE 서비스, HTTP 4xx, Business/Validation 예외 → 스킵
• NPE/SQL → HIGH, N+1 → MEDIUM

2차 — AI 사전 검증

• 소스코드를 함께 보고 실제 코드 버그인지 판단
• NEEDS_FIX → 수정 진행 / NOT_CODE_ISSUE, BUSINESS_EXCEPTION → 스킵

③ Notion 백로그를 발행한다

• 등록된 Notion DB 템플릿 속성을 읽어 포맷에 맞춰 title과 body만 채워서 생성
• 백로그 ID 발급

④ git-flow 브랜치를 생성한다

• fix/{service}-{error_type}-{date}-{attempt}
• 예: fix/order-service-NPE-20260418-1

⑤ 로컬 프로젝트에서 AI가 코드를 수정한다

• 스택트레이스에서 메서드 단위 소스코드 추출
• CLAUDE.md에서 프로젝트 코딩 컨벤션 로딩
• Datadog MCP Server로 추가 트레이스/로그 탐색 (스택트레이스만으로 부족할 때)
• AI 수정안 생성 → 커밋 → CI 파이프라인 실행
• PASS → ⑥으로
• FAIL → 실패 원인 분석 → 전략 변경 → 재시도 (Meta-Harness 루프, 최대 5회)

⑥ MR을 올린다

• GitLab MR 자동 생성
• 개발자가 MR을 검토하고 머지한다 ← 유일한 사람 개입 지점

아키텍처

인터페이스로 분리한 이유

Datadog을 Sentry로, Notion을 Jira로, GitLab을 GitHub으로 바꿔도 비즈니스 로직은 안 바뀌어야 한다. 모든 외부 연동을 5개의 인터페이스(ABC)로 추상화했다.

예를 들어 AIAgent는 세 가지 메서드만 정의한다.

class AIAgent(ABC):
    @abstractmethod
    def fix_code(self, context: ErrorContext) -> FixResult: ...

    @abstractmethod
    def propose_harness(self, traces: List[ExecutionTrace]) -> Harness: ...

    @abstractmethod
    def validate_issue(self, context: ErrorContext) -> ValidationResult: ...

비즈니스 로직(MetaHarnessLoop, Classifier 등)은 이 인터페이스들에만 의존한다. 구체 구현체는 CLI 조립 시점에서 주입한다. 드라이런 모드에서는 LocalVCSClient를, 실전에서는 GitLabClient를 넣는데, 비즈니스 로직 쪽은 어떤 구현체가 들어왔는지 모른다.

의존성 방향

• CLI / Hook → FullRunner / StepRunner → 비즈니스 로직 → 인터페이스 ← 구현체

상위 계층은 하위 인터페이스에만 의존한다. 구현체가 인터페이스를 구현할 뿐, 비즈니스 로직이 구현체를 직접 참조하는 경우는 없다.

도메인 모델

시스템을 흐르는 데이터는 16개의 dataclass와 6개의 enum으로 정의했다. 흐름은 다음과 같다.

• Datadog API 응답 → ErrorEvent (서비스, 예외 클래스, 스택트레이스, 발생 횟수)
• Classifier → Issue (ErrorEvent + 계층, 심각도, 레포 정보)
• MetaHarnessLoop → ErrorContext (Issue + 메서드 단위 소스코드 + 이전 실패 전략 + 프로젝트 컨벤션)
• AIAgent → FixResult (수정 성공 여부, 변경 파일, diff)

각 단계에서 필요한 데이터만 담아서 넘긴다.

Datadog 연동

오류 수집 — Error Tracking API

Datadog Error Tracking은 운영 중 발생한 예외를 그룹화해 관리한다. Error Tracking API로 최근 7일 오류를 수집한다. 스택트레이스, 예외 클래스명, 발생 횟수, 최초 발생 시각이 함께 반환된다.

N+1 수집 — Spans Analytics API

Datadog APM Recommendations에서 N+1 패턴을 UI로 확인할 수 있지만, 해당 데이터는 공개 REST API로 직접 접근이 불가능하다.

Spans API로 동일한 데이터를 구성했다.

N+1 스코어 = count(DB 스팬) / cardinality(@trace_id) 트레이스당 평균 동일 쿼리 호출 횟수. 5 이상이면 N+1로 판정.

2단계 분류 — AI에게 다 넘기지 않는다

AI에게 모든 오류를 넘기면 비용과 시간 모두 낭비된다. 수정할 가치가 있는 이슈만 골라내는 게 먼저다.

1단계: 규칙 필터

class Classifier:
    def _classify_error(self, event: ErrorEvent) -> Optional[Issue]:
        if service_info.get("layer") == "FE":
            return None                          # FE → BE 코드 수정 불가
        if event.http_status in {400, 401, 403, 404, 422}:
            return None                          # 4xx → 클라이언트 문제
        if any(kw in event.exception_class for kw in ("Business", "Validation", "Domain")):
            return None                          # 의도된 예외
        # NPE → HIGH, SQL → HIGH, N+1 → MEDIUM

2단계: AI 사전 검증

규칙을 통과한 이슈에 대해 AI가 소스코드를 함께 보고 최종 판단한다.

결과는 캐시에 저장된다. 스킵 판정은 7일, 수정 판정은 24시간 TTL로 분리했다. 수정 판정의 TTL이 짧은 이유는 코드가 바뀌면 판단도 바뀌어야 하기 때문이다.

Meta-Harness — 실패할 때마다 접근을 바꾼다

AI 코드 수정의 가장 큰 과제는 정확도다.

단순 재시도(Naive Retry)는 동일한 실패를 반복한다. 사람이 프롬프트를 수정하면 새로운 실패 유형에 다시 사람이 개입해야 한다. Meta-Harness는 이 문제를 풀기 위해 AI에게 무엇을 줄 것인가(하네스)를 매 시도마다 개선한다.

메서드 단위 추출

파일 전체를 AI에게 주면 비용이 폭증하고, 관련 없는 메서드를 "개선" 대상으로 오인하는 문제가 있었다. 스택트레이스에서 클래스와 메서드명을 파싱하고, 메서드 경계를 특정한 뒤, 해당 블록만 잘라서 AI에게 넘긴다. 수정 결과가 돌아오면 원본의 해당 영역만 교체한다. 500줄짜리 파일에서 46줄만 뽑아서 넘기는 식이다.

실패-학습 루프

1. AI가 코드를 수정한다
2. CI 파이프라인을 돌린다
3. 실패하면 — 어떤 컨텍스트로 접근했는지, 왜 실패했는지 트레이스를 저장한다
4. Counterfactual Diagnosis — 이전 시도의 어떤 결정이 실패를 유발했는지 AI가 분석한다
5. 다음 시도의 전략을 갱신하고, 개선된 하네스로 재시도한다 (최대 5회)

단순 재시도와 다른 점은 접근 방식 자체가 바뀐다는 것이다.

def _improve_context(self, issue, related_code) -> ErrorContext:
    """이전 실패를 분석해 개선된 컨텍스트를 만든다."""
    previous_runs = self._store.load_runs()
    failed_traces = [r.execution_trace for r in previous_runs
                     if r.test_result == TestResult.FAIL]

    if failed_traces:
        improved = self._agent.propose_harness(failed_traces)
        # Counterfactual Diagnosis 결과를 다음 시도의 컨텍스트에 주입
        additional = "\n\n".join([
            "## Counterfactual Diagnosis — 이전 실패 분석",
            improved.description,
            "## 다음 시도 구체적 전략\n" + improved.code,
        ])

    return ErrorContext(issue=issue, related_code=related_code,
                        additional_context=additional)

처음엔 메서드 단위로 수정하다가, 실패하면 호출부까지 범위를 넓히고, 그래도 안 되면 해당 패턴의 다른 사례를 참고해 전략을 바꾸는 것이 실제로 관찰됐다.

Rate Limit 페일오버

Claude가 rate limit에 걸리면 자동으로 다음 에이전트(Cursor 계정 1 → 2 → 3)로 전환하는 라우터를 만들었다. 모든 에이전트가 소진되면 작업을 중단한다. 무한히 재시도하지 않는다.

실제 드라이런 결과

로컬 git 브랜치에만 커밋하는 드라이런 모드로 실제 운영 코드를 대상으로 검증했다.

N+1 수정

• 입력 — N+1 query detected: ExhibitionRepository.findAllByStatusCodeAndOperationTypeAndAutoType (트레이스당 평균 8회 반복)
• AI 판단 — Spring Data JPA 연관 엔티티를 lazy로 가져오면서 N+1 발생
• 수정 — 리포지토리 메서드에 @EntityGraph(attributePaths = {...}) 추가. 수정 diff 2줄.

NPE 수정

• 입력 — java.util.NoSuchElementException: No value present at Optional.get(...)
• 수정 — optional.get() → optional.ifPresent(::method) 리팩터링

"수정 안 할 것"도 정확히 걸러낸다

PriceCacheService.expire:22 스택트레이스를 넣어보았다. @AllArgsConstructor로 의존성 주입을 받는 Spring Bean이라 코드 자체에 null 가능성이 없다. AI는 NOT_CODE_ISSUE로 판정하고, "Spring 컨텍스트 초기화 실패나 빈 등록 누락 등 DI 설정 문제로 판단됩니다"라고 사유를 남겼다.

수정하지 않아야 할 것을 수정하지 않는 능력이 이 시스템의 신뢰성을 결정한다.

테스트

618개 테스트, Phase별 검증

인터페이스 → 도메인 모델 → 구현체 → 비즈니스 로직 순서로 개발했고, 테스트도 같은 순서로 쌓았다. 각 Phase 테스트가 100% 통과해야 다음 Phase로 넘어갔다.

Phase 1 — 인터페이스 계약 (45개)

5개 인터페이스에 대해 추상 클래스 직접 인스턴스화 불가, 불완전 구현 불가, 완전 구현 시 올바른 타입 반환을 검증한다.

Phase 2 — 도메인 모델 (33개)

6개 enum 전수 검사, dataclass 필드 검증, 경계값(score 범위, occurrence_count 임계값) 검증.

Phase 3 — 구현체 (137개)

외부 API를 Mock으로 교체하고 각 구현체의 입출력을 검증한다. 가장 많은 테스트가 집중된 Phase다.

Phase 4 — 비즈니스 로직 (58개)

Phase 5 — 유틸리티 + 스킬 + Runner (345개)

통합 테스트 — Mock 없이 실제 API 호출

환경변수 미설정 시 자동 스킵. 실제 Datadog API, Notion API, Claude Code CLI를 호출한다.

설계 결정

왜 파일시스템에 트레이스를 쌓는가

대안은 DB 또는 벡터 저장소였다. 파일시스템을 선택한 이유는 세 가지다.

1. 투명성 — 어떤 시도가 왜 실패했는지 바로 볼 수 있다
2. Meta-Harness 원 논문이 증명한 패턴 — filesystem 자체가 AI 컨텍스트로 들어가는 설계
3. 교체 가능 — HarnessStore 인터페이스 뒤에 있으므로 DB로 바꿔도 비즈니스 로직은 안 바뀐다

상태 관리 — 중간에 죽어도 처음부터 다시 하지 않는다

각 단계 완료 시 결과를 파일로 저장한다. 네트워크 끊김이나 rate limit이 발생해도 직전 완료 지점부터 재개할 수 있다. CLI가 단계별 실행을 지원하는 것도 이 구조의 연장선이다.

Claude Code CLI — 왜 API가 아닌 subprocess인가

1. 사용자 계정 기반 인증 — API 키를 별도 관리하지 않는다
2. 스킬 시스템 접근 — CLI는 Claude Code의 스킬/도구 생태계와 연동된다
3. 프로세스 격리 — AI의 상태가 메인 프로세스를 오염시키지 않는다

토큰 사용량 측정이 세밀하지 않고, API 대비 호출 오버헤드가 크다. 하지만 운영 관점의 단순성이 훨씬 컸다.

MCP 연동 — AI가 외부 데이터에 직접 접근한다

Datadog MCP Server를 Claude Code에 연결하면, AI가 코드를 수정하는 시점에 트레이스, 로그, 메트릭을 직접 조회할 수 있다. 파이프라인이 가져온 스택트레이스만으로 부족할 때, AI가 추가 맥락을 스스로 탐색하는 것이 가능해진다.

수집은 REST API로, 수정 시 탐색은 MCP로 — 역할이 분리되어 있다.

기술 스택

Claude Code를 쓰기 시작하면서 자동화 못하나 고민을 했다.

그 답을 찾기 위해 두 가지 방식을 직접 만들어서 써봤다. 실제 사용하고 ai 한테 물어본 결론은 한쪽은 특정 상황에서만 의미 있었고, 나머지는 팀 단위에서나 진짜 가치가 있었다.

질문 내용 워크플로우 개선 시도 각 개선 시도에 대해 상세하게 분석하고 내가 말한 장점과 문제점에 대해 상세히 분석

1. 코드가 있는경우 최대한 코드 전체를 분석한다.
2. 엔지니어링 기법을 사용한경우 해당 엔지니어링 기법에 대해 조사를 최대한 자세하게 한다.
3. 절대적으로 아래 시도 작업이 옳다는건 아니다. 실제 사실관계도 파악한다.
4. 관련 혹은 ai관련 최신 논문, 연구결과 등도 같이 비교 분석 한다.
5. 해당 모든 내용들을 문서로 정리한다.

   시도 작업

6. 노션, 피그마 링크를 ai 로 넘겨 interface, 설계, 프롬프트 생성해서 claude code 요청 - /Users/tpirates/workspace/workflow (local) 1.1 장점

     GUI 로 지원 노션, 피그마 링크로 좀 더 편하다.

   1.2 문제점

   - 개발자가 직접 interface, 설계, 프롬프트 생성해서 하는게 더 명확하다.
   - 실제 요구사항과 개발자가 원하는 방식을 맞추기 위해서는 많은 수정 요청을 한다.
   - 수정 사항에 대해 매버 프롬프트로 다시 요청을 하는데 claude code로 하는거랑 뭐가 다른가.

7. 하네스엔지니어링 2.1 장점

     테스트로 좀 더 안정적인 개발 가능

   2.2 문제점

    - 기존에 레거시 프로젝트의 경우 테스트가 없는 경우도 있는데 이거는 커버가 안됨
    - 실제 개발입장에서는 레거시 프로젝트를 유지보수 하는 경우가 많은데 해당 방식에 적용이 어려움

8. ai skills interface 등록 - https://github.com/jaemyeong-hwnag/common-ai-skill 3.1 장점

    기능만 명세하고 ai 가 직접 프로젝트에 맞는 구현을 개발

   3.2 문제점

    - 이게 진짜 효용성이 있는지 잘 모르겠다.
    - 기능별로 너무 명확하게 한계가 있어 보인다.

시도한 것들

시도 1. Notion/Figma → AI → Spec → Claude Code

Notion 백로그 URL을 넣으면 코드 스캐닝, 스펙 생성, 프롬프트 생성까지 자동으로 처리하고 Claude Code를 실행하는 파이프라인을 만들었다.

흐름은 이렇다:

Notion URL
→ 레포 코드 스캔 (메서드 시그니처만, 구현 코드 제외)
→ spec-draft (AI가 인터페이스 + 요구사항 초안)
→ [개발자가 아키텍처 결정 입력]
→ spec-refine
→ Claude Code 실행 프롬프트 생성
→ claude --dangerously-skip-permissions

논문도 뒤졌다. Lost-in-the-Middle 방지를 위해 핵심 제약을 메시지 하단에 반복하고, Claude는 XML이 YAML보다 성능이 높다는 연구(arXiv:2411.10541)를 반영해 AI 내부 통신 포맷을 잡았다. LLM-as-Judge도 달았다.

꽤 공들였는데 — 결과가 좋지 않았다.

시도 2. AI Skills Interface

기능 명세만 작성하면 AI가 프로젝트에 맞는 구현을 알아서 한다는 개념이다.

핵심은 이 철학이다:

"Skills define what must be achieved, never how. You are the implementation: read the skill → inspect this project → fulfill the contract"

Interface-First Development를 AI에 적용한 버전으로 보면 된다. 구현 방법을 지시하는 게 아니라 계약을 정의하면 AI가 프로젝트 맥락에 맞게 해석해서 구현한다.

시도 1은 왜 실패했나

실행 로그를 보면 솔직하게 드러난다.

날짜: 2026-04-02 하루
실행 횟수: 30회
실행 시간: 약 3시간 42분
spec.md 상태: human_review (완료 안 됨)
ai_prompts.md: 비어 있음

파이프라인이 human review 단계에서 멈췄다. spec-refine, 프롬프트 생성은 실행되지 않았다. 결국 직접 프롬프트를 써서 Claude Code를 30회 실행해 작업했다.

스펙 생성 레이어는 작동했지만 실제 작업에 쓰이지 않았다. 우회된 것이다.

아키텍처 결정은 이미 머릿속에 있었다

워크플로우가 생성한 프롬프트의 제약 조건 섹션 내용:

스케쥴러는 없고 일단 api로 비즈니스 로직만 구현
외부 메시지 발송은 core에 구현

AI가 Notion에서 읽어온 게 아니라 개발자가 GUI에서 직접 타이핑한 것이다. Claude Code에 직접 쓰는 것과 차이가 없다.

Notion 백로그에는 비즈니스 언어로 쓰여 있었고, 어떤 패키지에 넣을지, 어떤 레이어에서 처리할지는 본인이 이미 알고 있었다. AI가 그걸 대신 결정해주는 게 아니라 본인이 입력한 것을 XML로 감싸줬을 뿐이다.

런타임 오류는 스펙이 막지 못한다

run_0의 첫 번째 오류:

RSA Private Key가 없어서 loadPrivateKey() IOException 발생.
signing-key에 Webhook secret을 넣었는데 이건 RSA 키가 아님.

이런 오류는 실행해봐야 안다. 스펙이 아무리 잘 만들어져도 잡을 수 없다. 30회 반복은 워크플로우 때문이 아니라 원래 일어날 수밖에 없는 디버깅 사이클이었다.

"Claude Code에 직접 오류 던져줘, 고쳐줘"가 똑같다.

Claude Code가 이미 탐색을 한다

워크플로우 코드 스캐너가 하는 일:

• 레포 파일 트리 추출
• 클래스/메서드 시그니처 추출
• 아키텍처 패턴 감지
• XML로 압축해서 AI에 주입

Claude Code의 Plan Mode에서 Claude Code가 직접 파일을 읽는 것이 중간 압축보다 정확하다. 시그니처만 추출하면 구현 맥락이 빠지지만, Claude Code는 실제 코드를 읽는다.

MCP로 대체 가능

워크플로우가 Notion/Figma를 파싱해서 주입하는 작업:

claude mcp add notion
claude mcp add figma

이걸로 끝이다. Claude Code가 직접 Notion/Figma를 읽는다. 별도 서버, GUI, 파이프라인이 필요 없다.

그래도 의미 있는 경우가 있다

완전히 쓸모없는 건 아니다. 아래 조건이 맞을 때는 워크플로우 서버가 실제로 차별점이 있다:

• 여러 레포(frontend + backend + infra)에 동시 반영해야 할 때
• 팀 전체가 같은 스펙을 공유해야 할 때
• Notion 백로그가 수십 개고 각각 Claude Code 실행이 필요할 때

병렬 실행, 실행 이력 영속화, 스펙 버전 관리 — 이 세 가지가 필요한 상황이면 의미가 있다. 레포 하나에 혼자 작업하는 경우라면 CLI 직접 쓰는 게 더 빠르다.

AI Skills Interface는 어땠나

레포: https://github.com/jaemyeong-hwnag/common-ai-skill

장점: 기능만 명세하면 AI가 프로젝트에 맞게 구현한다

기존에 AI에게 뭔가를 시킬 때 보통 이렇게 된다. "이 파일에 이 메서드 추가해줘. 패턴은 이렇게 하고, 테스트는 이렇게 해줘." 구현 방법을 같이 설명한다.

스킬 방식은 반대다. "이 기능이 있어야 한다"는 계약만 정의하고, 어떻게 구현할지는 AI가 레포를 보고 판단하게 한다.

예를 들어 hexagonal-development 스킬은 이런 식이다:

모든 신규 기능은 헥사고날 아키텍처를 따른다.
Port 인터페이스를 먼저 정의하고, Adapter가 구현한다.
도메인 로직은 외부 의존성에 대해 알지 못한다.

이걸 한 번 등록해두면 AI가 코드를 추가할 때마다 프로젝트 구조를 스스로 파악해서 기존 패턴대로 맞춰준다. 매번 "우리 프로젝트는 헥사고날이야, 포트 먼저 만들어야 해"를 설명하지 않아도 된다.

delivery-workflow 스킬은 구현 → 테스트 → 커버리지 확인 → 커밋 사이클 전체를 하나의 명세로 정의한다. 이것도 한 번 등록하면 "구현하고 테스트까지"를 별도로 말하지 않아도 된다.

팀에서 쓸 때 실용성이 있다. 새 팀원이 합류했을 때 "이 스킬들 읽고 써"가 되고, 구현 방식에 대한 반복 설명을 줄일 수 있다.

문제점 1: 효용성이 불확실하다

쓰다 보면 이게 실제로 효과가 있는 건지 확신이 서지 않는다.

스킬이 마크다운 텍스트인 이상 AI가 해석하는 방식이 매번 다를 수 있다. 동일한 스킬 명세가 Claude 3에서 하던 것을 Claude 4에서 다르게 할 수 있다. 스킬 자체가 잘 작동하는지 테스트할 방법이 없다.

워크플로우 코드에서 내부 구현과 비교하면 차이가 분명하다. 내부에서 스킬은 Python 추상 클래스로 만들었다:

class Skill(ABC):
    @abstractmethod
    async def execute(self, input_: SkillInput) -> SkillOutput:
        """스킬 실행."""

타입 강제가 되고 단위 테스트를 붙일 수 있다. 반면 마크다운 명세는 AI가 읽고 해석하는 것이기 때문에 "이 스킬이 정확히 실행됐다"를 확인할 수단이 없다.

Chain-of-Thought 연구(Wei et al. 2022)에서도 비슷한 맥락이 있다. 같은 지시어도 모델 크기와 컨텍스트에 따라 일관성이 크게 달라진다. 스킬이 텍스트인 한 이 문제는 피하기 어렵다.

문제점 2: 프로젝트 구조를 가정한다

스킬들이 Best Practice를 전제로 만들어져 있어서, 그 전제가 맞지 않는 프로젝트에서는 오히려 방해가 된다.

hexagonal-development 스킬은 헥사고날 아키텍처를 가정한다. MVC 레거시 프로젝트에서 이 스킬을 쓰면 AI가 없던 레이어를 만들려고 한다.

coverage 스킬은 80% 커버리지를 목표로 강제한다. 레거시에서 80%는 비현실적인 숫자다.

finalize 스킬은 작업 후 자동으로 커밋까지 한다. 프로젝트마다 커밋 정책이 다른데 이게 충돌한다.

스킬이 Best Practice를 가정하는데, 실제 프로젝트는 Best Practice를 따르지 않는 경우가 많다. 그래서 기능별로 한계가 명확하다. 신규 프로젝트에서 아키텍처를 처음부터 잡는 경우에는 맞지만, 기존 프로젝트에 얹으려 하면 프로젝트마다 스킬을 별도로 만들어야 한다.

결국 혼자 쓰는 상황에서는 CLAUDE.md에 직접 프로젝트 컨벤션을 쓰는 것과 효과가 다르지 않다.

실제로 잘 작동한 것들

검증 기준을 프롬프트에 포함

Claude Code 공식 문서에서 "single highest-leverage thing"이라고 표현한 것이다.

# 나쁜 요청
"알림 발송 기능 구현해줘"

# 좋은 요청
"POST /api/notify 구현해줘.
구현 후 curl -X POST http://localhost:8080/api/notify?date=2025-01-01 
실행해서 HTTP 200 나오면 성공. 테스트도 작성하고 실행해."

Claude Code는 스스로 결과를 확인할 수 있을 때 훨씬 낫다.

CLAUDE.md 한 번 쓰고 반복 활용

매 실행마다 컨텍스트를 주입하는 것보다 레포 루트에 CLAUDE.md를 한 번 잘 써두는 게 낫다. 200줄 미만으로 유지하고, Claude가 코드에서 알 수 있는 것은 쓰지 않는다. 틀린 행동이 반복될 때만 추가한다.

# CLAUDE.md

## Architecture
- Hexagonal pattern (ports/adapters)
- 외부 API 호출은 core 패키지에서만

## Commands
- 빌드: ./gradlew build
- 테스트: ./gradlew test

## Do NOT
- git add -A 사용 금지
- .env 파일 수정 금지
- 기존 인터페이스 시그니처 변경 금지

레거시 프로젝트 접근법

테스트 없는 레거시에 AI가 코드를 추가하면 검증 방법이 없다. 이 경우 Characterization Test를 먼저 요청한다:

"YourService.findByDate() 메서드의 현재 동작을 
 Characterization Test로 캡처해줘.
 실제 실행해서 현재 반환값을 확인하고, 
 그 값을 expected로 하는 테스트 작성.
 내 의도가 아니라 현재 코드가 실제로 하는 일을 테스트해야 함."

Michael Feathers의 "Working Effectively with Legacy Code"에서 나온 패턴인데, AI 코딩에 그대로 쓸 수 있다.

정리

SWE-bench 기준으로 Claude 3.7 Sonnet이 ~62%를 해결한다. 38%는 항상 실패한다. 워크플로우가 좋든 나쁘든 AI가 완전히 틀릴 가능성은 항상 있다. 검증 단계와 사람 개입을 빼는 건 이 맥락에서 좋지 않다.

Aurora MySQL의 binlog를 실시간으로 캡처하여 S3에 구조화된 데이터로 저장하는 서버리스 CDC(Change Data Capture) 파이프라인

🏗️ 아키텍처 설계

1. 다양한 CDC 구현 방식 vs Lambda 기반 직접 파싱

고려했던 대안 방식들

🎯 방식 ①: Debezium → MSK(Serverless) → S3(Iceberg) → Athena

• 구성: Debezium 커넥터 → MSK Serverless → S3 Iceberg 테이블 → Athena
• 장점: 완전한 CDC 솔루션, 다중 싱크 지원
• 단점: 상시 비용 발생, 복잡한 운영

🎯 방식 ②: Aurora Native CDC → EventBridge Pipes → Lambda → S3(Iceberg)/Dynamo

• 구성: Aurora CDC → EventBridge Pipes → Lambda → S3/DynamoDB
• 장점: AWS 네이티브 서비스 활용
• 단점: 중간 서비스 의존성, 비용 증가

🎯 방식 ③: CDC(DMS/Debezium) → EventBridge Pipes → DynamoDB

• 구성: DMS/Debezium → EventBridge Pipes → DynamoDB
• 장점: 단건 조회 최적화
• 단점: 분석 기능 제한, DynamoDB 비용 폭증 위험

🎯 방식 ④: Debezium Server on Fargate(Spot) → S3(Iceberg) → Athena

• 구성: Debezium Server → Fargate Spot → S3 Iceberg → Athena
• 장점: MSK 없이 구현 가능
• 단점: Fargate 상시 실행 비용

왜 Lambda 기반 직접 binlog 파싱을 선택했는가?

🤖 GPT-5 기반 비용 분석: 이 비교 분석은 GPT-5를 활용하여 5가지 CDC 구현 방식의 상세한 비용 계산과 의사결정 과정을 수행했습니다.

월간 RDS CUD 이벤트 현황 (Datadog CSV 기반)

*2025-08 데이터는 수집 중 일부 기간만 포함됨

🎯 비용 효율성 비교 (월간 비용):

현재 구현 (Lambda 직접 파싱):     $30.58
방식 ④ (Fargate Spot):           $90    (+196%)
방식 ① (MSK Serverless):         $160   (+423%)
방식 ② (Aurora CDC + Pipes):     $260   (+751%)
방식 ③ (DMS + Dynamo):           $303   (+892%)

연간 절약 효과: $2,754-3,274 (70-90% 절약)

🎯 기술적 우위:

• 완전한 제어: binlog 파싱부터 저장까지 모든 과정 제어
• 운영 단순성: 최소 서비스 구성 (Lambda, DynamoDB, S3)
• 에러 처리: 1236 에러 처리, S3 저장 실패 시 롤백 등 세밀한 제어

🎯 성능 최적화:

• 파티션 프루닝: 쿼리 비용 절약
• 체크포인트: 중간 체크포인트로 데이터 무결성 보장

🎯 확장성:

• 서버리스: Lambda 자동 스케일링
• 무제한 저장: S3 기반 무제한 확장
• 선형적 비용: 사용량에 비례한 비용 증가

2. 서버리스 우선 설계 (Serverless-First Architecture)

왜 서버리스로 설계했는가?

🎯 비용 효율성

• 사용량 기반 과금: 실제 데이터 변경이 있을 때만 비용 발생
• 인프라 관리 불필요: 서버 프로비저닝, 패치, 모니터링 오버헤드 제거
• 자동 스케일링: 데이터 볼륨에 따라 자동으로 리소스 조정

🎯 운영 단순화

• 이벤트 기반 실행: CloudWatch Events로 주기적 실행 (1분마다)
• 무상태 처리: 각 실행이 독립적이며 재시작 가능
• 장애 격리: 개별 실행 실패가 전체 시스템에 영향 없음

graph TB
    A[CloudWatch Events<br/>1분마다 트리거] --> B[AWS Lambda<br/>aurora-cdc-parser]
    B --> C[Aurora MySQL<br/>Binlog 스트림]
    B --> D[DynamoDB<br/>체크포인트 관리]
    B --> E[S3 Bucket<br/>JSONL + Parquet]

    style A fill:#ff9999
    style B fill:#99ccff
    style C fill:#99ff99
    style D fill:#ffcc99
    style E fill:#cc99ff

3. 체크포인트 기반 재시작 메커니즘

왜 체크포인트 패턴을 선택했는가?

🎯 데이터 무결성 보장

• 중간 체크포인트: 10건마다 진행 상황 저장으로 부분 실패 시에도 데이터 손실 방지
• 최종 체크포인트: Lambda 실행 완료 시 최종 위치 저장
• 자동 재시작: 장애 발생 시 마지막 체크포인트에서 자동 재개

🎯 처리 효율성

• 증분 처리: 이미 처리된 데이터 재처리 방지
• 병렬 실행 안전성: 동일한 binlog 위치에서 중복 처리 방지

sequenceDiagram
    participant L as Lambda
    participant D as DynamoDB
    participant A as Aurora
    participant S as S3

    L->>D: 체크포인트 조회
    D-->>L: 마지막 위치 반환
    L->>A: Binlog 스트림 생성
    A-->>L: 이벤트 스트림

    loop 10건마다
        L->>D: 중간 체크포인트 저장
        L->>S: JSONL/Parquet 저장
    end

    L->>D: 최종 체크포인트 저장

🔄 핵심 처리 플로우

1. Binlog 스트림 처리 플로우

flowchart TD
    A[Lambda 시작] --> B[환경 감지]
    B --> C[DB 연결 및 설정 검증]
    C --> D[체크포인트 조회]
    D --> E[서버 ID 생성]
    E --> F[Binlog 스트림 생성]

    F --> G[이벤트 수집 루프]
    G --> H{이벤트 존재?}
    H -->|Yes| I[이벤트 변환]
    I --> J[스키마 매핑]
    J --> K[기본키 추출]
    K --> L[10건마다 체크포인트]
    L --> M[S3 저장]
    M --> G

    H -->|No| N[최종 체크포인트]
    N --> O[Lambda 종료]

    style A fill:#ff9999
    style O fill:#99ff99

2. 데이터 변환 파이프라인

graph LR
    A[Raw Binlog Event] --> B[이벤트 타입 분류]
    B --> C[INSERT Event]
    B --> D[UPDATE Event]
    B --> E[DELETE Event]

    C --> F[after_values 추출]
    D --> G[before_values + after_values]
    E --> H[before_values 추출]

    F --> I[스키마 매핑]
    G --> I
    H --> I

    I --> J[기본키 추출]
    J --> K[구조화된 이벤트 데이터]
    K --> L[JSONL 변환]
    K --> M[Parquet 변환]

    style A fill:#ffcc99
    style K fill:#99ff99
    style L fill:#99ccff
    style M fill:#cc99ff

🛠️ 기술적 설계 결정사항

1. S3 저장 경로 설계 및 비용 최적화

Parquet 경로 구조 (Athena 파티션 최적화)

s3://aurora-history-binlog/
└── env=dev/db=db-name/schema=schema-name/date=2025-01-15/
    └── PUSH_LOG_20250115_143022.parquet

왜 이렇게 설계했는가?

🎯 Parquet 경로: Athena 파티션 최적화

• 쿼리 성능: 파티션 프루닝으로 쿼리 성능 향상
• 비용 절약: 필요한 파티션만 스캔하여 비용 절약```

파티션 키 구조:

1. env = 'prod'           # 환경별 분리 (dev/stage/prod)
2. db = 'database_name'        # 데이터베이스별 분리
3. schema = 'schema_name'    # 스키마별 분리
4. date = '2025-09-15'    # 날짜별 분리 (가장 세밀한 파티션)

Athena 쿼리 비용 최적화

파티션 프루닝 효과:

-- 비효율적인 쿼리 (전체 테이블 스캔)
SELECT * FROM binlog_event 
WHERE table_name = 'table_name' AND pk_value = '32811'

-- 최적화된 쿼리 (파티션 프루닝)
SELECT * FROM binlog_event
WHERE env = 'prod'                    -- 파티션 1: 환경
  AND database_name = 'database_name'      -- 파티션 2: 데이터베이스
  AND schema_name = 'schema_name'        -- 파티션 3: 스키마
  AND event_date BETWEEN '2025-09-01' AND '2025-09-30'  -- 파티션 4: 날짜
  AND table_name = 'table_name'
  AND pk_value = '32811'

env=prod/db=database_name/schema=table_name/date=2025-09-01/  ← 스캔됨
env=prod/db=database_name/schema=table_name/date=2025-09-02/  ← 스캔됨
...
env=prod/db=database_name/schema=schema_name/date=2025-09-30/  ← 스캔됨
env=prod/db=database_name/schema=schema_name/date=2025-10-01/  ← 스캔 안됨 (범위 밖)
env=dev/db=database_name/schema=schema_name/date=2025-09-15/   ← 스캔 안됨 (환경 다름)

관련 링크: Datadog Summit Seoul 후기(velog)

핸즈온 내용

Datadog Learn(무료) 코스에서 SLI를 정의하고 SLO를 설정한 뒤, SLO 위반 시 알림 전파와 담당자 자동 할당까지 구성했다.

• SLI 정의

  • APM 기반: HTTP 상태코드(2xx/5xx)를 기준으로 요청 성공률/오류율 측정
  • RUM 기반: 실제 사용자 모니터링(RUM)의 페이지/리소스 지연시간(latency) 측정

• SLO 구성: 위 SLI들을 대상으로 기간(예: 28일 롤링), 목표 비율(예: 성공률 99.9%), 대상(엔드포인트/서비스)를 명확히 설정

• 알림/할당: SLO 위반 시 Datadog monitor 으로 알림을 보내고, 담당자에게 할당까지 할 수 있도록한다.

내가 느낀 점

• Log/APM을 통해 Slack 알림까지 보내는 부분은 실무에서 많이 사용해 봤지만, SLI/SLO로 기준을 두고 운영해 본 것은 처음이라 좋은 경험이었다.
• 이번 구성은 특정 지표에 임계값을 두고 도달 시 알림을 보내는 형태였기 때문에, 기존 에러 알림은 병행해야 한다고 느꼈다.
• 특히 이벤트·연휴처럼 트래픽 변동이 큰 시기에 이런 체계를 갖춰 두면 더 빠르게 대응할 수 있을 것 같다.

아래부터는 핸즈온 중 다룬 이론 정리입니다.

이론 정리

왜 SRE 관점이 필요한가

• Ops 팀 확장성 문제: 서비스 규모·복잡도가 커질수록 운영 인력을 선형적으로 늘리는 방식은 한계가 있음.

• 해결 우선순위

  1. 자동화: 반복 작업, 배포 검증, 롤백, 런북/자가치유(auto-remediation)
  2. 가시성 확보: 메트릭·로그·트레이스 상관분석으로 원인→영향을 빠르게 좁힘

SLI (Service Level Indicator)

• 정의: 사용자가 체감하는 품질을 분자/분모가 명확한 수식으로 정의한 지표.

• 예시

  • 지연시간(latency): p95/p99 응답시간
  • 오류율(error rate): 5xx 수 / 전체 요청 수
  • 성공률(success rate): 2xx 수 / 전체 요청 수
  • 비즈니스 품질: 결제 성공 / 결제 시도 등

SLO (Service Level Objective)

• 정의: 특정 기간 동안 SLI가 만족해야 하는 목표.

• 좋은 문장 예시

  • "지난 28일 롤링 윈도우 기준, 성공률 99.9% 이상"
  • "p95 응답시간 100ms 이하 요청이 28일 동안 99% 이상"

기간·대상·퍼센트가 빠지면 SLO로 불완전하다.

에러 버짓(Error Budget)

• 정의: (1 − SLO)만큼 허용되는 실패 여유. 예) SLO 99.9% → 0.1%가 버짓.
• 연간 허용 중단시간(감 잡기)

• 운영 정책 예시: 버짓 소진 시 배포 일시 중단, 회고/개선 액션, 위험 실험 제한

임계값보다 버짓 소모율(Burn Rate) 기반 알림

• 공식: Burn rate = (현재 오류율) / (1 − SLO)

• 운영 팁: 다중 윈도우로 빠른/느린 소모를 함께 감지

  • 예: 1시간/6시간 두 창에서 기준 초과 시 알림
  • 단발성 스파이크와 장기 악화를 모두 포착하고 알림 피로도를 낮춤

골든 시그널(Golden Signals)

• Latency(지연시간): p95/p99, 타임아웃 비율
• Errors(오류): 5xx·애플리케이션 예외, 비즈니스 실패율
• Traffic(트래픽): RPS/QPS, 동시 사용자, 메시지 처리량
• Saturation(포화도): CPU·메모리·스레드풀·큐 길이·DB 커넥션 등 리소스 여유

실무 적용 체크리스트

• SLI 정의: 사용자 여정별로 분자/분모를 문장화하고 대시보드 메트릭과 1:1 매핑
• SLO 문장화: 기간·대상·퍼센트를 명시(엔드포인트/서비스/리전 단위)
• 알림 설계: 버짓 소모율 기반 다중 윈도우, 온콜 할당

마무리

이번 핸즈온은 기존의 단순 에러 알림을 넘어, 사용자 체감 품질을 수치로 정의(SLI) → 기간 목표(SLO) → 버짓 기반 운영으로 연결하는 SRE 운영의 뼈대를 체감하게 해 주었다. 이벤트·연휴 등 변동 구간에 특히 효과적이며, 팀의 확장 가능한 운영을 위한 기본기를 갖추는 데 큰 도움이 된다.

AI와 Observability, 두 가지가 가장 큰 주제였다.

이중에서도 AI 관련 내용이 가장 크게 다뤄졌다. 요즘 대세인 AI에 맞춰 많은 내용에 AI가 포함되어 있었다. 실제 핸즈온에서도 "작은 LLM 애플리케이션 개발부터 관측까지"가 있었는데, 신청할 때 인원이 다 차 있어서 아쉽게도 참여하지 못했다.

기조연설 및 외부 부스

기조연설과 외부 부스의 내용이 일맥상통했고, 주로 신규 서비스 소개가 중심이었다.

AI 활용 서비스

AI를 통해 이슈 트래킹부터 추정 서비스 트리 제공 등 다양한 기능을 제공하며, 실제 담당자에게 연락까지 이어지도록 되어 있었는데 이러한 기능을 외부 부스에서 시연하고 있어 어느 정도 확인할 수 있었다.

자세히는 AI가 자동으로 모니터링하고, Datadog 안에서 이전 이슈와 컨텍스트를 학습해 이를 기반으로 이슈 추정·정리, 오류가 발생한 서비스와 연관된 서비스 트리 등을 제공한다.

클라우드 시큐리티

IDE에 MCP Server를 연동해 사용 중인 라이브러리/패키지의 보안 이슈 여부와 코드 레벨의 취약점을 확인해 준다.

AI 기반 로그 보안 탐지, ISMS, IdP 보안 취약점 관리 등 보안 관련 내용도 많았지만, AI 기반 내용이 특히 두드러졌다.

아모레퍼시픽의 AI + 통합 Observability 혁신 사례

B2C용 AI 챗을 도입한 내용이 주였다. Datadog LLM 대시보드를 활용해 Observability를 확보했다.

보통 기업은 AI를 도입할 때 사내 서비스부터 차근차근 시작하지만, 여기는 곧바로 B2C AI 서비스를 오픈한 것이 특징이었다. 오픈 과정에서 발생한 이슈와 고려했던 점을 공유했는데, 이 부분이 매우 도움이 되었다.

이슈

AI 서비스를 운영하면서 발생한 문제들.

품질 - Response Quality

AI 특성상 비동기 요청이 많아 품질 이슈가 생기기 쉬운데, 속도, AI 답변 품질, 응답 실패 등이 주요 포인트였다. 각 케이스도 다른 API와 유사하게 LLM 대시보드를 활용해 개선했다고 한다.

안전/안정성

이 이슈는 실제 보안 문제뿐 아니라 프롬프트 인젝션, AI 사용 시 고객이 받는 답변의 적절성 문제도 포함된다고 했다. 정치·사회 등 민감 주제에 대해선 부적절한 표현이 포함되지 않도록 한 차례 검증한다고 한다. 또한 유사한 방식으로, 다른 기업과의 계약 기간이 만료되었음에도 해당 기업 관련 내용이 포함되는지 여부도 검증한다고 한다.

비용

비용 측면에서는 토큰 비용이 주요 이슈였다. Datadog LLM 대시보드를 통해 토큰 사용량이 많은 스팬과 호출 빈도가 높은 스팬을 파악해 캐싱하는 방식을 사용했다고 한다.

SRE Hands-on

https://velog.io/@banana-wuyu/Datadog-Summit-Seoul-hands-on

마무리

아쉬운 부분

1. 핸즈온과 다른 기업들의 세션이 각각 진행되어, 핸즈온 때문에 다른 기업 세션을 듣지 못한 게 매우 아쉽다. 핸즈온을 포기하고 세션을 들을걸 후회할 정도로 아쉬웠다. 오전에 아모레퍼시픽의 개발 경험을 듣고 인사이트를 많이 얻었는데, 다른 사례들도 들었으면 더 많은 인사이트를 얻을 수 있었을 텐데 아쉽다.
2. 외부 행사는 인프런 행사가 처음이었고, 이번 Datadog Summit Seoul 2025가 두 번째라 사진을 많이 찍지 못한 게 아쉽다. 나중에 영상도 찾아봐야겠다.
3. 내용을 충분히 정리하지 못했다.

좋았던 부분

1. 들었던 다른 기업의 실제 후기가 매우 좋았다. 만약 AI 관련 서비스를 도입한다면, 여기서 얻은 인사이트들은 최소한 고려할 것 같다.
2. 앞으로 다른 행사나 세션이 있으면 무엇을 들어야 하는지, 사진 촬영과 정리를 어떻게 해야 하는지 배웠다.

사진들

• 기존 RDS(MySQL) 환경에서는 여러 테이블의 히스토리성 데이터(감사 이력, 변경 로그 등)를 각각 별도의 테이블에 저장해 관리하고 있었습니다.
• 감사 로그(히스토리 데이터)는 저장 빈도는 높고, 조회 빈도는 낮아 RDS의 저장/운영 비용과 성능 측면에서 비효율적이었습니다.
• 데이터 관리 일관성과 운영 효율성을 위해 DynamoDB 기반 이력 관리 시스템으로 구조를 개선했습니다.
• SQS 및 AWS EventBridge 등 이벤트 기반 아키텍처를 적용하여, 다양한 모듈(관리자/유저 앱 등)과 멀티 컨테이너 환경에서도 서비스 무중단, 확장성을 보장할 수 있게 설계했습니다.

기존 구조의 문제점

1. 저장 및 운영 비용 증가
   • RDS는 읽기·쓰기 부하 모두 가격이 높고, 히스토리 테이블을 별도로 관리하면 스토리지/성능/백업 오버헤드가 큽니다.
2. I/O 부하 및 트랜잭션 병목
   • join이 많은 쿼리와 이력 insert가 동시에 발생하면, 메인 서비스 트랜잭션에도 영향을 주는 구조적 한계가 있습니다.
3. 확장성 한계
   • 모놀리식/멀티모듈 환경에서 여러 컨테이너가 동시에 이력 insert를 하면 RDS 커넥션 풀, 락, 확장성 이슈에 노출됩니다.
4. 운영 관리의 복잡성
   • 감사 테이블이 서비스별로 분산되어 있어 신규 테이블 추가, 이력 정책 변경, 마이그레이션 등 관리 포인트가 많아집니다.

개선 방향 및 솔루션

• 비동기/이벤트 기반 파이프라인 도입
  • 각 모듈에서 발생하는 이력 데이터는 컨테이너 내 메모리 큐(Heap)에 임시 저장 후,
  • 일정 주기·사이즈마다 SQS로 배치 전송
  • SQS에 저장된 메시지는 AWS Batch, EventBridge, Lambda 등을 활용해 비동기로 DynamoDB에 적재
• SQS 선택 이유
  • 감사/히스토리 데이터는 엄격한 순서 보장이 불필요
  • SQS는 저렴한 비용, 수평 확장성, AWS 서비스 연계성이 우수
  • RabbitMQ 등 타 메시지큐 대비 운영·모니터링 편의성(콘솔 UI/UX)도 장점

구현 상세

1. 메모리 큐(Heap) 적재 & 안전한 종료 처리

• 컨테이너 내 각 인스턴스에서 이력 데이터를 Thread-safe 메모리 큐에 임시 저장
• shutdown: graceful, timeout-per-shutdown-phase: 360s, @PreDestroy 등으로 서버 종료 시 안전하게 잔여 데이터 flush

    server:
      shutdown: graceful
    spring:
      lifecycle:
        timeout-per-shutdown-phase: 360s

    @PreDestroy
    public void flushQueueBeforeShutdown() {
        eventQueue.flushAll(); // 큐에 남은 데이터 안전하게 SQS로 전송
    }

2. 배치 전송 트리거

• 일정 시간 간격(예: 10초), 또는 큐 크기가 특정 임계치 도달 시 SQS로 배치 전송
• 전송 실패 시 재시도/예외 로깅 등 장애 대응 설계

3. SQS → DynamoDB 비동기 적재

• AWS Lambda, Batch, EventBridge로 SQS 메시지 폴링/수신
• 각 이력 데이터는 PK+SK 구조, GSI 인덱싱 등 확장 가능하게 설계
  • 신규 테이블/로그 타입 추가 시 구조 변경 없이 확장 가능

아키텍처 및 데이터 모델 상세

시스템 아키텍처 흐름

[서비스] ─▶ [메모리 큐] ─▶ [SQS] ─▶ [Lambda/Batch] ─▶ [DynamoDB]
   ↑                                  │
(여러 인스턴스,                      │
  확장 가능)                        │
                                      ▼
                          [운영자/조회 서비스/분석 등]

DynamoDB 단일 테이블 설계

• PK(Partition Key): {database}#{table}#{id}

• SK(Sort Key): {timestamp}#{uuid}
  → 시간순 이력 정렬, 중복 방지, 범위 쿼리 지원

• GSI(Global Secondary Index):

  • 예) target_type_id-index, target_type_id_record_type-index 등
  • 다양한 조회 패턴(타입별, 엔티티별, 날짜별 등)에 최적화

• Map 구조 필드(AuditingField)

  • key: "tableName.fieldName"
  • value: 필드명/값/사용자표시명 등
  • 신규 필드/테이블 추가에도 구조 변경 없이 확장

DynamoDB 감사 이력 Item 예시

{
  "pk": "sampledb#sample_table#1001",
  "sk": "2024-07-30T10:15:20.123456#d24f2e67-xxxx-xxxx-xxxx-xxxxxx",
  "actionType": "UPDATE",
  "targetType": "sample_table",
  "targetId": "1001",
  "fields": {
    "sample_table.name": { "name": "이름", "value": "데모상품", "value_name": "데모상품" },
    "sample_table.status": { "name": "상태", "value": "ACTIVE", "value_name": "활성" }
  },
  "createdAt": "2024-07-30T10:15:20.123456"
  // ... 기타 조회/색인 필드 ...
}

Java 데이터 모델 예시

public class AuditingField {
    private final Map<String, AuditingFieldInfo> fields = new ConcurrentHashMap<>();
    public static class AuditingFieldInfo {
        String name;       // 필드명
        String value;      // 실제 값
        String valueName;  // 사용자용 표시값
    }
}

public class AuditingHistory {
    // PK, SK, actionType 등 주요 메타데이터
    private String pk;
    private String sk;
    private String actionType;
    // ... 생략 ...
    private AuditingField fields;
}

public class AuditingFieldConverter implements AttributeConverter<AuditingField> {
    @Override
    public AttributeValue transformFrom(AuditingField input) {
        // Map<String, AttributeValue>로 변환
    }
    @Override
    public AuditingField transformTo(AttributeValue input) {
        // AttributeValue에서 Map 복원
    }
}

주요 효과 및 개선점

• RDS 부하 감소 및 저장 비용 최적화
• 메인 트랜잭션 경량화, 장애 시 서비스 영향 최소화(Fail-safe)
• 운영 편의성: 테이블 추가/이력 정책 변경 시 구조 변경 최소화
• 트래픽 급증, 컨테이너 수평 확장에도 무중단 운영
• 새로운 로그 타입/이력 테이블 추가도 구조적 유연성 보장

한 줄 요약

RDS에 분산 저장하던 감사 이력(로그) 데이터를 메모리 큐, SQS, DynamoDB 기반의 비동기 이벤트 파이프라인으로 이관해
저장/운영 효율, 시스템 확장성, 장애 내성을 크게 개선한 실전 사례입니다.

참고/심화 (기술스택·운영 경험)

• Spring Boot, AWS SQS, Lambda, DynamoDB, Java
• Spring Batch, Virtual Thread, Hibernate Listener 등도 유연하게 조합 가능
• 실제 적용시 RDS 비용 절감, 서비스 latency 감소, 무중단 배포 및 장애 복구 경험 보유

Dockerfile에서 apt-get update && apt-get install -y curl 실행 중 아래와 같은 오류가 발생했다:

E: The repository 'http://deb.debian.org/debian buster Release' does not have a Release file.
E: The repository 'http://deb.debian.org/debian buster-updates Release' does not have a Release file.
E: The repository 'http://security.debian.org/debian-security buster/updates Release' does not have a Release file.

1. Debian 10 (buster) 레거시 환경에서 해결 방법

Debian 10 (buster)은 2024년 기준으로 EOL(지원 종료)되어 공식 저장소에서 제거되었기 때문에, apt-get update 시 404 오류가 발생한다.

해결 방법: 아카이브 저장소로 변경

Dockerfile에 아래 내용을 추가하여 저장소 URL을 archive 주소로 바꾼다:

RUN sed -i 's|http://deb.debian.org/debian|http://archive.debian.org/debian|g' /etc/apt/sources.list && \
    sed -i 's|http://security.debian.org/debian-security|http://archive.debian.org/debian-security|g' /etc/apt/sources.list && \
    apt-get update && apt-get install -y curl

2. Debian 11 (bullseye)로 버전 변경 시 발생한 의존성 오류 해결

기존 buster 이미지를 대체하여 아래와 같이 bullseye 기반의 openjdk 이미지를 사용한 경우:

FROM openjdk:11-jre-slim-bullseye

apt-get install이 일부 GUI/폰트 관련 라이브러리를 포함하지 않아 실행 중 오류 발생.

해결 방법: 필요한 라이브러리 명시적 설치

RUN apt update && apt install -y --no-install-recommends \
    curl \
    libfreetype6 \
    libfontconfig1 \
    libx11-6 \
    libxext6 \
    libxrender1 \
    && rm -rf /var/lib/apt/lists/*

1. 왜 이런 생각을 하게 되었는가

최근 코딩테스트를 준비하면서 아래와 같은 문제를 자주 느꼈다:

• 문제를 보고도 접근 방식이 떠오르지 않음
• AI가 짜준 코드는 동작하지만, 왜 그렇게 구현되는지 모름
• 비슷한 문제를 다시 풀려고 하면 스스로 구현하지 못함
• 기본 개념이 부족하니 디버깅도 어려움

이 과정에서 AI 자동완성을 그대로 사용하는 것이 내 실력을 갉아먹고 있다는 문제의식을 갖게 되었고, 학습 방향을 다시 잡기로 했다.

2. 문제의 핵심

3. AI 사용 범위 제한

효율적인 학습을 위해 AI 사용을 다음 범위로 제한한다:

4. AI 사용 금지 영역

5. 실천 방법

• 문제를 만나면 직접 설계 → 직접 코드 작성
• 막히면 AI에게 개념 또는 구조 질문을 하여 보완
• 코딩 후에는 AI에게 코드 리뷰 및 개선 포인트 요청
• 문제 풀이/회고는 정리해서 학습 로그 남기기

6. 예시로 보는 올바른 사용

7. 핵심 문장

AI는 내 코드를 도와주는 리뷰어이지, 코드를 대신 짜주는 개발자는 아니다.

8. 앞으로의 목표

• 문제 해결 능력 강화
• 자료구조/알고리즘 개념 복습 및 정리
• 회고 중심의 학습 습관 정착
• AI를 도구로 활용하되, 절대 의존하지 않기

9. 이 글도 AI가 정리했다...

Kotlin Coroutine 환경에서 대량의 FCM Push 메시지를 처리할 때, 많은 예제나 문서에서는 Dispatchers.IO를 사용하는 것을 기본으로 제시합니다. 그러나 실무에서는 다음과 같은 이유로 커스텀 ThreadPoolTaskExecutor를 Coroutine Dispatcher로 wrapping 하여 사용하는 경우도 많습니다:

• OutOfMemoryError 방지
• Push 트래픽이 시스템 전체에 영향을 주는 것을 방지

이 글에서는 Dispatchers.IO와 커스텀 디스패처 각각의 장단점을 비교하고, 어떤 상황에서 어떤 선택이 더 합리적인지를 다룹니다.

Dispatchers.IO 특징

장점

• 사용이 간단하다 (withContext(Dispatchers.IO)만 쓰면 됨)
• 대부분의 I/O 작업에 적절한 성능

단점

• 공용 풀이라서 Push 트래픽 폭주 시 다른 작업까지 영향을 받을 수 있음
• 최대 스레드 수는 제한되지만 강제로 증가 가능 → 메모리 압박 발생

커스텀 Dispatcher (ThreadPoolTaskExecutor 기반)

목적

Push 트래픽이 많아졌을 때 전체 시스템에 영향을 주지 않도록 격리

예시 코드

@Bean
fun firebasePushExecutor(): ThreadPoolTaskExecutor {
    return ThreadPoolTaskExecutor().apply {
        corePoolSize = 4
        maxPoolSize = 8
        setQueueCapacity(3000)
        setThreadNamePrefix("FirebasePush-")
        setRejectedExecutionHandler(ThreadPoolExecutor.CallerRunsPolicy())
        initialize()
    }
}

val firebaseDispatcher = firebasePushExecutor.asCoroutineDispatcher()

장점

• 스레드 풀을 격리해서 Push 실패가 다른 기능에 영향을 주지 않음
• core/max/thread queue 제어 가능
• Micrometer, Prometheus 등을 통한 모니터링 가능
• 큐가 꽉 찼을 때 reject 정책 설정 가능

단점

• 코드가 복잡해지고 관리 부담 증가

실전 비교 요약

결론

Dispatchers.IO는 단순하고 강력하지만, 격리와 안정성 측면에서 커스텀 디스패처가 더 안전한 선택일 수 있다.

• Push 트래픽이 시스템 전체를 마비시킬 위험이 있다면 → 커스텀 Dispatcher 사용
• 단순한 비동기 처리라면 → Dispatchers.IO 사용

최종 요약 표

부록: FCM Push 처리 구조 예시 (코루틴 기반)

val scope = CoroutineScope(firebaseDispatcher + coroutineContext)

val jobs = chunk.map { pushMessage ->
    val fcmMessage = pushMessage.toFcmMessage()
    pushMessage to scope.async {
        try {
            pushMessage to firebaseHttp2Client.send(...)
        } catch (e: Exception) {
            pushMessage to e
        }
    }
}

jobs.forEach { (pushMessage, job) ->
    val result = job.await()
    if (result.second is Throwable) {
        // 실패
    } else {
        // 성공
    }
}

실제로 의도적으로 푸시 트래픽을 커스텀 풀로 분리해두면, 장애 전파를 차단하고 운영 안정성을 크게 높일 수 있습니다.

"자동으로 잘 관리된다고 해서, 모든 상황에 안전한 건 아니다." → 이게 핵심입니다.

※ 이 글은 개발자에 의해 작성되었으며, 일부 정리 및 요약 과정에서 OpenAI GPT의 도움을 받았습니다.

Note: This document was authored and reviewed by a developer, with the assistance of OpenAI's GPT to accelerate summarization and clarity.

메시지 서버를 설계하면서 처음에는 HTTP 기반의 요청 처리를 고려했습니다. 하지만 HTTP는 클라이언트의 요청 수에 따라 서버가 직접 응답해야 하므로, 서버의 처리 능력과 상관없이 부하가 한순간에 몰릴 수 있는 위험이 있습니다.

이에 따라 대안으로 떠오른 것이 큐 기반 아키텍처입니다. Queue를 사용하면 메시지를 먼저 받아 저장한 후, 서버의 처리 능력에 맞게 정량적으로 메시지를 소비할 수 있어 전체 시스템의 안정성과 확장성을 높일 수 있습니다. 특히 AWS ECS와 같은 컨테이너 오케스트레이션 환경에서는, 컨테이너 수를 조절하면서 손쉽게 수평 확장이 가능하다는 점도 큰 장점이었습니다.

RabbitMQ vs Amazon SQS: Spring 환경에서의 메시징 처리 방식 비교

Spring을 사용하는 백엔드 시스템에서 메시지 큐를 도입할 때 흔히 비교하는 두 가지 기술은 RabbitMQ와 Amazon SQS입니다. 각각의 특징과 처리 방식, 재시도, 중복 처리, 성능에 대해 자세히 정리해봅니다.

주요 비교 요약

재시도 및 중복 가능성

RabbitMQ

• 재시도: nack 및 requeue로 직접 제어 가능.
• 중복 가능성: 존재. 예외 발생 시 재전송될 수 있음.
• Exactly-once 보장 불가 → idempotent 처리 권장.

SQS

• 재시도: Visibility Timeout 이후 자동 재전송.
• 중복 가능성: Standard는 중복 가능. FIFO는 exactly-once 보장.
• Dead Letter Queue(DLQ) 설정 가능.

메시지 처리 방식 (Push vs Pull)

RabbitMQ Push 방식의 안정성

우려: Push가 과도하게 밀어주면 과부하 위험 있음

해결: Back-pressure 설정

• prefetchCount: Consumer가 동시에 받을 수 있는 메시지 수 제한
• ackMode: 수동 ack 설정으로 처리 후 메시지 제거
• concurrency: 동시 처리 스레드 수 조절

@RabbitListener(queues = ["my.queue"], ackMode = "MANUAL")
fun handleMessage(message: Message, channel: Channel) {
    try {
        // 처리 로직
        channel.basicAck(message.messageProperties.deliveryTag, false)
    } catch (e: Exception) {
        channel.basicNack(message.messageProperties.deliveryTag, false, true)
    }
}

제대로 구성하면 Push 방식도 안정적으로 처리량 제어 가능.

결론 정리

마지막 요약

RabbitMQ는 Push 기반이지만, prefetch, ack, concurrency 설정을 통해 안정적으로 처리량 제어 가능.
SQS는 Pull 기반으로 구조가 단순하고 서버리스에 적합.
두 방식 모두 idempotent 처리 필수!

1. 문제 상황

기존 시스템에서는 Firebase Admin SDK를 사용해 FCM Push 알림을 발송

• vCPU: 1
• Memory: 2GB 하루 수차례에 걸쳐 대량의 Push 메시지를 처리해야 했고, 약 4만 건의 Push 발송에 10분 이상 소요

2. 원인 분석

2.1 firebase-admin-java SDK 구조 변경

FCM SDK의 구조 변경으로 인해 발송 처리 방식에 근본적인 차이가 발생한 것이 성능 저하의 주요 원인이었다.

• firebase-admin-java 9.2.0 이전

  • sendAll 메서드로 batch API(https://fcm.googleapis.com/batch)를 사용
  • 다수의 메시지를 1회의 HTTP 요청으로 처리

• firebase-admin-java 9.2.0 이후

  • sendAll은 Deprecated
  • 대체 메서드인 sendEachForMulticast는 메시지 1건당 HTTP 요청 1건을 수행
  • 예: 4만 건 발송 시 4만 건의 HTTP 요청 발생 → 과도한 연결 및 리소스 사용

3. 개선 작업

3.1 HTTP/2 적용을 통한 병렬 전송 최적화

• SDK 버전을 9.4.3으로 업그레이드하고, ApacheHttp2Transport를 통해 HTTP/2 기반 전송을 적용함.
• FCM 서버는 HTTP/2를 지원하며, multiplexing 기능을 활용하면 하나의 커넥션에서 다수의 요청을 동시에 처리할 수 있어 성능 개선에 효과적.

설정 예시

val client = HttpAsyncClients.createHttp2System()

val options = FirebaseOptions.builder()
    .setHttpTransport(ApacheHttp2Transport(client))

FirebaseApp.initializeApp(options)

의존성 (Kotlin)

implementation("org.apache.httpcomponents.core5:httpcore5-h2:5.3")
implementation("org.apache.httpcomponents.core5:httpcore5:5.3")
implementation("org.apache.httpcomponents.client5:httpclient5:5.4")

개선 결과

• 6만 건 발송 기준, 약 4분 소요
• 기존 대비 처리 속도 약 2.5배 향상

3.2 WebClient + 비동기 방식으로 재구현

HTTP/2 적용만으로도 성능은 개선되었지만, 그 이상의 개선을 위해 다음과 같은 추가 조치를 진행함:

• 기존 firebase-admin-java는 APM(Datadog) trace가 정상적으로 기록되지 않음
• 완전한 비동기 처리를 위해 Spring WebClient를 활용하여 직접 HTTP 요청을 구현

고려 사항

과거 비동기 방식 시도 당시 OOM(Out Of Memory) 이슈가 있었기 때문에, 다음과 같은 제한을 추가로 적용함:

• ThreadPoolTaskExecutor를 사용하여 스레드 자원 제어
  • 최대 스레드 수: CPU * 2 (실환경 기준 2개)
  • 대기 큐 크기: 최대 3,000건
• 현재 사용 중인 스레드 수와 큐 잔여량을 고려하여 청크 단위로 분할 요청 처리

개선 결과

• 6만 건 기준 약 1분 59초 소요
• SDK 방식 대비 약 2배 이상 빠름

4. 운영 중 발생한 문제 및 대응

에러 발생

운영 환경에서 전체 6만 건 중 약 400건에서 다음과 같은 오류가 발생하며 발송 실패:

Error while acquiring from reactor.netty.internal.shaded.reactor.pool.SimpleDequePool

원인 분석

• 최초에는 HTTP connection pool 부족 문제로 판단했지만, 실제로는 커넥션 수는 충분했음
• 문제는 HTTP/2의 stream 수 제한에 의해 발생함
  • 여러 요청이 특정 커넥션에 집중될 경우, 해당 커넥션의 최대 stream 수를 초과할 수 있음
  • 이 경우 요청이 block되거나, pool acquire 실패 발생

조치

• Http2AllocationStrategy 설정을 통해 connection pool의 요청 분산 처리
• 각 커넥션에 균등하게 요청이 분산되도록 구성
• Reactor Netty의 connection 관련 설정을 최적화

재처리

• 실패한 약 400건은 별도의 큐에 저장
• 재전송 로직을 통해 순차적으로 재시도하여 모두 정상 발송 완료

5. 최종 성능 비교

e-commerce 도메인에 기존 PHP 레거시 코드를 kotlin으로 변환하는 작업 변환 작업을 최우선으로 생각해서 각각 다른 팀에 팀원이 모여서 작업을 한다.

목표

팀의 목표는 결제를 제외한 모든 페이지 전환이다. 그 중에 제일 먼저 배포되는 인증 첫 번째 작업을 성공적으로 배포하는 것을 목표로 합니다.

작업 자체가 모든 페이지를 PHP->Kotlin 으로 한번에 변환하는 것이 아닌, 부분 부분 변환을 하는 작업이다. 그 중에 제일 선행되어야 하는 작업은 인증이다. 모든 페이지에서 필요한 작업이기 때문이다.

스펙

FE: next, typescript, react, graphql, rest api BE: kotlin, spring boot, graphql, rest api

과제

1. 기존에 사용자들은 어떠한 영향도 없어야 한다.
2. 1 기존에 로그인한 사용자 유지
3. 0부터 시작하는 백엔드 개발
4. 1 모니터링 시스템
5. 2 git 전략
6. 개발
7. 배포
8. 트러블 슈팅
9. 1 NAVER 인증시 일부 유저의 약관동의 정보 가져오기 404 오류
10. 2 JWT 브라우저 쿠키 만료시간 설정 오류

기존에 사용자들은 어떠한 영향도 없어야 한다.

달리는 차 바퀴를 교체 하기 이미 운영되는 도메인이기 때문에 어떠한 영향도 없어야 한다. 기존 사용자는 어떠한 변경점을 느끼지 못 해야한다.

kotlin에는 PHP 에 대한 어떠한 종속성도 가지면 안된다. 모든 페이지가 kotlin으로 전환시에 또 다른 추가작업이 필요하고 그에 따라 더 많은 리소스가 낭비되기 때문이다. 또한, 굳이 레거시 시스템을 신규 작업에 넣어야할 필요성이 없다.

기존에 로그인한 사용자 유지

문제

사용자의 첫 진입점은 PHP , next(kotlin) 두 곳중에 1곳이다. 사용자가 PHP 페이지에 첫 진입 후 next(kotlin)에 접근하면 로그인이 유지되지 않는다.

PHP의 경우 CI_SESSION 이라는 키로 세션 아이디를 쿠키에 저장하고 있다. kotlin 의 경우 JWT 토큰을 쿠키에 저장하고 있다.

매번 PHP 진입 할때도 JWT 토큰을 쿠키에 저장하면 되지 않는가? 그렇다면 문제가 발생한다. kotlin 으로 변환된 페이지에서 로그아웃을 하더라도, PHP에 로그인이 유지되면서 JWT 토큰을 쿠키에 저장하는 문제가 생긴다.

해결

1. 전환 작업 운영 배포전 3개월간 PHP에 USER ID 기준으로 JWT 토큰을 생성하는 작업을 먼저 배포한다.
2. PHP에도 JWT가 없으면 로그아웃 시킨다.
3. PHP JWT가 있고 CI_SESSION(PHP 인증 정보)가 없는 경우 CI_SESSION(PHP 인증 정보)를 새로 생성한다.
4. 전환 작업 운영 배포시에 2, 3번 작업도 PHP도 같이 배포한다.

모든 인증 기준은 JWT 로 통일한다.

Git-Flow Git-Flow 전략을 사용하는 방식 채택

1. 러닝커브가 높지않다.
2. 기존 도메인에서도 사용하는 사람이 다수라 해당 전략 사용

   모니터링 시스템

   익셉션 처리

   목적
   • 프론트엔드에서 익셉션 별로 처리하기 쉽도록
   • 모니터링시 명확하게 확인 가능하도록

도메인 별로 익셉션 처리

• 각각 도메인 별로 익셉션을 처리 할 수 있도록 open class BusinessException : RuntimeException 클래스 추가
• 각각 도메인 별로 위에 BusinessException 을 상속 받아 익셉션 코드, 메시지를 만들 수 있도록 한다.

프론트에서 익셉션 정보를 확인 가능하도록 처리

• https://netflix.github.io/dgs/error-handling/#the-typederror-interface
• 익셉션 별로 각각 메시지와 코드를 맵핑해서 프론트엔드에서 확인가능
• BusinessException, AccessDeniedException 와 같이 정의된 익셉션 처리 및 정의 되지 않은 RuntimeException 익셉션을 가공하여 response 생성

DataDog 사용

datadog monitor 에 error 에 대한 모니터링을 추가해서 slack 으로 알림 오도록 추가

https://docs.datadoghq.com/ko/monitors/

개발

1. 로그인 및 회원가입 구조 설계
   • Delegate를 사용해 각 역할(Role)에 특화된 검증 로직을 위임하여 재사용성을 높이고 유지보수성을 개선.
   • 로그인 공통 기능 Façade 및 OAuth Service 공통 인터페이스로 구현하도록 설계

배포

각각 종속성이 강하기 때문에 배포전에 순서를 정하고 배포한다.

배포는 아래 순서로 배포한다.

1. kotlin -> 배포 후 postman 혹은 기타 다른 툴로 api 동작 운영에서 확인
2. PHP -> 배포 후 기존 로그인 사용자 유지 확인
3. next -> 프론트 배포 후 모니터링 시작

조금 더 시간이 있었더라면 카나리 배포 처럼 운영 환경에서 리스크를 줄이는 방법을 적용했었어야 했다.

트러블 슈팅

NAVER 인증시 일부 유저의 약관동의 정보 가져오기 404 오류

확인

1. 배포 직후 로그에 naver 인증시에 404 오류 발생 확인
2. 내부직원중에 일부가 로그인 안된다는 내용 전파

원인

외부 API 라서 원인 확인이 어려웠으나, 동일한 케이스가 다른 곳에서도 발생했다는 것을 확인 naver api 에 문제가 있어 정확한 원인 확인이 어려웠습니다.

https://developers.naver.com/forum/posts/34228 https://developers.naver.com/forum/posts/34684

해결

naver 인증시에 마켓팅 동의 선택 항목의 정보를 가져와야하기문에 해당 플로우를 생략할 수 없었습니다. 하지만, OAuth를 활용한 로그인이 아닌 ID/PW의 경우 따로 마켓팅 동의를 받고 있는 로직이 있어 해당 부분을 약관동의 정보를 가져올때 404 오류 발생시 따로 동의를 받을 수 있도록 플로우 추가 후 핫픽스 배포

JWT 브라우저 쿠키 만료시간 설정 오류

확인

로그인이 안된다는 내용의 슬랙을 전파 받고 확인

BE, FE 각각 로그 확인 BE 확인 내용에서는 로그인에 JWT가 제대로 반환된부분 확인

원인

FE 에서 JWT 쿠키 생성시 만료시간을 설정할때 빌드 시점기준으로 시간을 더해 주는 방식으로 되어 이미 만료된 쿠키를 생성하여 쿠키가 제대로 생성되지 않아 오류 발생

해결

1차 배포 - FE 에서 JWT 쿠키 만료시간 하드코딩 후 핫픽스 배포 2차 배포 - JWT 쿠키 생성시점에 만료시간 생성하도록 로직 수정 후 배포

테스트하는 모듈에 @SpringBootApplication 이 없어서 발생

해결

테스트 패키지에 아래 추가

@SpringBootApplication
public class TestApplication {
}

핫픽스 건으로 배포할때 실제 개발 수정시간은 1분이더라도 배포하는데 5분이 걸리면 실제 운영까지 적용되는 시간은 최소 6분이다.

크리티컬 이슈의 경우 무엇보다 속도가 중요한데 이럴때 배포 버튼만 누르고 기다리면 답답했던 경우가 있었다

해결 방법은 배포 플로우중에 테스트 부분을 병렬로 진행하는 방법으로 배포 시간을 단축했던 경험이 있다.

참조

• https://techblog.woowahan.com/2553/

말 그대로 베이스를 재배치 브랜치의 시작점을 재설정 branch의 변경사항을 최신 상태로 유지가 가능 커밋 라인을 정리하여 히스토리를 깔끔하게 유지

사용

리베이스 사용법

최근 3개의 커밋을 interactive rebase 한다

git rebase -i head~3

p, pick - 커밋 내역

r, reword - 커밋 코멘트 수정

wq 로 저장 종료

현재 “0번 feature - 커밋 1” 메세지를 “0번 feature - 커밋 1 (수정)“ 으로 변경

wq 로 저장 종료

e, edit - 커밋 수정

2번째 커밋인 9ad336b 커밋의 내용 수정

wq 로 저장 종료

IDE 에서 수정할 내용 수정 후

git add . 수정 내용 추가

git commit --amend

wq 로 저장 종료

git rebase --continue 로 진행

s, squash - 여러 커밋 합치기

커밋 2, 커밋 3 을 커밋 1로 합치기

충돌이 난경우 충돌 부분 수정 후 git rebase --continue 로 진행

d, drop - 커밋 삭제

커밋 2 삭제

리베이스 취소

⚠️ 로컬에서 리베이스 작업한 경우만 사용가능합니다.

reflog로 이전내역 확인 후 git rest 커밋번호로 해당 커밋으로 초기화

참조

• https://www.tugberkugurlu.com/archive/resistance-against-london-tube-map-commit-history-a-k-a--git-merge-hell

적용해도 문제 없나? 쿼리 자체가 개별적으로 동작하는 쿼리라 이슈 없음

왜 느린가? 외부 서비스에 요청해서 결과값을 가져오는데 이때 속도가 이슈

결과 운영에서 평균 80ms

참고 : https://velog.io/@banana-wuyu/spring-osiv

결과 샘플 코드

@DgsComponent
class SampleQuery(
    private val dgsAsyncTaskExecutor: Executor,
) {
    @Async
    @DgsData
    fun sample1(): CompletableFuture<Sample> {
        return CompletableFuture.supplyAsync({
        // 로직
        }, dgsAsyncTaskExecutor)
    }

    @Async
    @DgsData
    fun sample2(): CompletableFuture<Sample> {
        return CompletableFuture.supplyAsync({
        // 로직
        }, dgsAsyncTaskExecutor)
    }

작업중 오류

이슈

1. Apparent connection leak detected

해결

Apparent connection leak detected

누수 확인 로그 추가

logging:
  level:
    com: trace
    org.springframework.transaction.interceptor: trace
spring:
  datasource-main:
    hikari:
      leak-detection-threshold: 2000

인증 처리를 하는 Resolver에서 오류 발생 유저 정보 조회 후 DB 커넥션이 제대로 닫히지 않아서 오류 발생

해결방법

osiv off로 수정 - https://kth990303.tistory.com/427 - 현재 코드에서는 lazy-load 가 있는 entity를 밖에서 사용하는 경우가 있어서 해당 방법 사용시 영향범위 파악도 어렵고, 테스트가 어려워 해당 방법은 사용 불가능 (해당 방법 사용) - 다른 방법 확인중 - async용 userResolver 따로 만들어서 사용 가능한지 확인중 - 해당 resolver에서 db 커넥션 강제로 끊어서 사용 (이런식으로 해도 되는지 모름)

// JPAQuery 확장 함수로, 페이징 처리를 하면서 전체 개수를 함께 조회하는 기능을 제공
fun <T> JPAQuery<T>.listWithTotalCountFetch(pageable: Pageable, countEntity: EntityPathBase<T>): ListWithTotalCount<T> {
    // 현재 쿼리를 복제하여 총 개수를 가져오는 쿼리 생성
    val query = this
    val totalCnt = query.clone()
        .select(countEntity, countEntity.countDistinct()) // countDistinct()를 사용하여 중복 없는 개수를 계산
        .fetchOne() // 결과를 단일 값으로 가져옴

    // 페이징 처리: Pageable 객체가 unpaged인 경우 전체 데이터를 가져오고, 그렇지 않으면 페이징 처리된 데이터를 가져옴
    val list = if (pageable.isUnpaged) {
        query.fetch() // 페이징 없이 전체 데이터를 조회
    } else {
        query.offset(pageable.offset) // 시작 위치 설정
            .limit(pageable.pageSize.toLong()) // 페이지 크기 설정
            .fetch() // 페이징된 데이터를 조회
    }

    // 조회된 데이터와 전체 개수를 포함하는 ListWithTotalCount 객체 반환
    return ListWithTotalCount(
        list,
        totalCnt?.get(1, Long::class.java)!!.toInt() // totalCnt의 두 번째 값(Long)을 Int로 변환하여 반환
    )
}

// 페이징 처리된 데이터와 전체 개수를 함께 담는 데이터 클래스
data class ListWithTotalCount<T>(
    val items: List<T>, // 조회된 데이터 리스트
    val totalCount: Int // 전체 데이터 개수
)

// 데이터 리스트와 마지막 키를 함께 담는 데이터 클래스 (Key 기반 페이징 용도)
data class ListWithLastKey<T>(
    val items: List<T>, // 조회된 데이터 리스트
    val lastKey: String?, // 마지막 키 (없으면 null)
)

1. 명시적이지 않다. 필수 값인지 그냥 사용해도 되는지
2. 휴먼 에러 만약 실수로라도 값을 입력하지 안은경우 오류 발생 가능

같이 일하는 동료의 오류를 찾으면서 경험했던 내용이다.

상품 정보가 정상적으로 나오지 않았던 오류였다. 원인은 프론트엔드에 리턴값을 모델링하는 부분에서 사용한는 객체 인자중에 디폴트값이 설정되어 있어서 값이 없는데 빈 문자열을 반환해서 오류가 발생

해당 오류에 원인 파악하는데에도 운영에 read DB를 연동해서 디버그 모드로 코드를 1개씩 실행하며 원인을 파악했다.

개인적인 생각을 먼저 말하면 false 로 사용하는게 좋을것 같다. false -> true 변경은 크게 이슈가 없지만, true -> false 변경시 프로젝트에서 어떤 사이드 이펙트가 발생할지 모른다.

이전에 프로젝트를 진행했을때 비동기를 사용하려고 했을때 Apparent connection leak detected이 발생했다. 이때문에 true -> false 로 변경하려고 했을때 LazyInitializationException이 발생

LazyInitializationException 원인은 lazy loding을 사용한 entity의 컬럼을 트랜젝션 밖에서 사용하고 있어서 발생

osiv false 로 사용하면 명시적으로 트랜젝션이 걸린 부분만 DB 커넥션을 유지하는데 이때 트랜젝션 밖에서 lazy 로딩한 entity를 사용하면 이미 커넥션을 끊기 상태에서 DB 요청을해서 오류 발생

원인

entity가 트랜젝션 밖에서 사용한는 것 부터 잘 못되었다. 모델링 후 사용하는게 정상적이다.

해결

osiv off 설정 후 entity를 밖에서 사용하는 코드 모든 부분 수정