성공했다는데 오지 않는 야속한 뉴스 알림

프로젝트 개요

pitch-feed는 KBO RSS 피드를 수집해 Spring AI로 요약하고 Discord로 발송하는 배치 시스템입니다.

RSS → @Scheduled → Spring AI(요약/태그) → PostgreSQL → Discord  

Render에 서버를 올리고 GitHub Actions로 배치를 트리거하는 구조입니다.

이슈 1 — Discord 알림 미수신 (Render IP 차단)

증상
GitHub Actions 배치 트리거 성공, 기사 DB 저장 정상, Discord 알림만 오지 않음.

원인
Render 무료 티어는 IP를 여러 고객과 공유합니다. 다른 사용자의 남용으로 인해 해당 IP가 Cloudflare에 의해 429 error code 1015로 지속 차단된 상태였습니다. 웹훅 URL을 새로 생성해도 서버 IP가 동일하므로 해결되지 않습니다.

로컬 curl 테스트로 차단 여부를 먼저 확인할 수 있습니다.

# 로컬 IP → 204 (정상)  
curl -s -o /dev/null -w "%{http_code}" \  
  -X POST $DISCORD_WEBHOOK \  -H "Content-Type: application/json" \  -d '{"content":"test"}'  
# Render IP → 429 (차단)  

해결 — Discord 호출 주체를 GitHub Actions로 이동

Before: Render → Discord webhook (직접 호출)  
After:  Render → Discord payload JSON 반환 → GitHub Actions → Discord webhook

Render는 RSS 수집·AI 요약·DB 저장만 담당하고 Discord payload를 JSON으로 반환합니다. Discord 호출은 GitHub Actions가 담당합니다. GitHub Actions 실행 IP는 차단 대상이 아닙니다.

# GitHub Actions workflow  
- name: Trigger batch  
  run: |    curl -o /tmp/discord_payload.json $RENDER_BATCH_URL  
- name: Send Discord notification  
  run: |    curl -X POST $DISCORD_WEBHOOK \         -H "Content-Type: application/json" \         -d @/tmp/discord_payload.json  

교훈: 무료 티어 공유 IP는 언제든 제3자 사유로 차단될 수 있습니다. 외부 서비스 호출은 IP를 통제할 수 있는 쪽에서 담당하도록 분리하는 것이 안전합니다.

이슈 2 — GitHub Actions curl timeout (exit code 28)

증상

Process completed with exit code 28  

--max-time 제한을 초과하면 curl이 exit code 28을 반환합니다.

원인
--max-time 180 설정이 실제 실행 시간보다 짧았습니다.

해결 (임시)

curl --max-time 360 $RENDER_BATCH_URL  

단순히 제한 시간을 늘리는 것은 임시 조치입니다. AI 직렬 호출이 근본 원인이라는 것을 확인하고, 이후 병렬화로 해결했습니다 (이슈 5 참조).

이슈 3 — GitHub Actions에서 외부 응답 처리 시 주의할 점

Discord webhook 연동 과정에서 응답 처리 방식으로 인한 오류가 두 번 발생했습니다.

3-1. invalid JSON (error code 50109)

증상

{"message": "The request body contains invalid JSON.", "code": 50109}  

원인
이슈 1(Render IP 차단) 해결 과정에서 Discord 호출을 Render에서 GitHub Actions로 이동했습니다. 이에 따라 Render 엔드포인트가 반환하는 값이 단순 문자열("Triggered")에서 Discord payload JSON으로 바뀌었는데, workflow의 step 간 데이터 전달 방식은 기존 echo 방식을 그대로 유지했습니다.

echo "key=value" 방식은 단순 문자열에는 안전하지만, 한글·이모지(⚾, 📋)가 포함된 JSON을 step outputs으로 넘기면 특수문자가 깨집니다.

# 문제가 된 방식  
- name: Get payload  
  id: batch                                          # (1) 이 step의 식별자  
  run: echo "payload=$(curl $RENDER_URL)" >> $GITHUB_OUTPUT  #          ^^^^^^^ (2)  ^^^^^^^^^^^^^ (3)    ^^^^^^^^^^^^^^^ (4)  
- name: Send to Discord  
  run: |    curl -X POST $DISCORD_WEBHOOK \         -d '${{ steps.batch.outputs.payload }}'  # (5) 특수문자 깨짐  

해결 — payload를 파일로 저장 후 전송

- name: Get payload  
  run: curl -o /tmp/discord_payload.json $RENDER_URL  #          ^^ 응답 body를 파일로 저장 (-o: output)  
- name: Send to Discord  
  run: |    curl -X POST $DISCORD_WEBHOOK \  #      ^^^^^^ HTTP 메서드 지정  
         -H "Content-Type: application/json" \  #      ^^ 요청 헤더 추가 (-H: header)         -d @/tmp/discord_payload.json  #      ^^ 요청 body 지정 (-d: data). @를 붙이면 문자열이 아닌 파일에서 읽음  

echo 방식은 단순 문자열에만 안전합니다. 한글·이모지가 포함된 JSON은 파일 경유가 표준입니다.

3-2. jq parse error (exit code 5)

증상

jq: parse error: Invalid numeric literal at EOF at line 1, column 9  

원인
/tmp/discord_payload.json에 유효한 JSON 대신 문자열("Triggered")이 담겨 있었습니다. Render 재배포 완료 전에 workflow를 실행해 구버전 코드가 응답한 것이 원인이었고, jq는 입력 전체가 유효한 JSON이어야 하므로 즉시 실패합니다.

해결 — 유효성 확인은 grep으로

# Before — jq로 파싱 시도  
cat /tmp/discord_payload.json | jq .  
  
# After — 문자열 탐색으로 대체  
grep -q '"embeds"' /tmp/discord_payload.json || { echo "Invalid payload"; exit 1; }  

파싱이나 추출이 필요 없다면 grep 문자열 탐색이 더 견고합니다.

정리: 두 오류 모두 GitHub Actions에서 외부 서비스 응답을 다룰 때의 패턴에서 비롯됐습니다.

이슈 4 — @WebMvcTest에서 Spring Security 403 Forbidden

증상
AuthControllerTest 전체가 기대 상태코드(200/401) 대신 403 반환.

세 가지 원인이 겹쳐 있었습니다.

원인 1 — @MockBean deprecated (Spring Boot 3.4+)

// Before  
import org.springframework.boot.test.mock.mockito.MockBean;  
@MockBean AuthService authService;  
  
// After  
import org.springframework.test.context.bean.override.mockito.MockitoBean;  
@MockitoBean AuthService authService;  

원인 2 — @WebMvcTest가 SecurityConfig를 로드하지 않음

@WebMvcTest는 웹 레이어 빈(@Controller, Filter 등)만 로드하는 슬라이스 테스트입니다. SecurityConfig는 자동 스캔 대상이 아니므로 Spring Boot 기본 보안(CSRF 활성화)이 적용되어 모든 POST 요청이 403이 됩니다.

@WebMvcTest(AuthController.class)  
@Import(SecurityConfig.class)  // 실제 보안 설정 명시 로드  
class AuthControllerTest { ... }  

원인 3 — JwtAuthenticationFilter mock이 필터 체인을 끊음

@MockitoBean으로 등록한 필터는 기본적으로 chain.doFilter()를 호출하지 않아 필터 체인이 끊깁니다.

@MockitoBean JwtAuthenticationFilter jwtAuthenticationFilter;  
  
@BeforeEach  
void setUp() throws Exception {  
    doAnswer(inv -> {        ((FilterChain) inv.getArgument(2))            .doFilter(inv.getArgument(0), inv.getArgument(1));        return null;    }).when(jwtAuthenticationFilter).doFilter(any(), any(), any());  
}  

이슈 5 — AI 직렬 호출로 인한 배치 시간 초과

증상
이슈 2에서 --max-time 360으로 늘렸음에도 배치가 지속 실패.

원인
RssFetchService에서 기사별 AI 요약이 순차 실행됩니다.

피드 1개 × 기사 5건 × AI 응답 ~30초 = 총 ~150초  
(Render 콜드 스타트 ~100초 포함 시 ~250초+)  

타임아웃을 아무리 늘려도 직렬 실행이 근본 원인이므로 한계가 있습니다.

해결 — invokeAll() + Virtual Thread로 병렬화

처리 흐름을 3단계로 분리했습니다.

// 1단계: URL 중복 필터링 (DB 조회)  
List<RssItem> newItems = filterDuplicates(fetchedItems);  
  
// 2단계: AI 병렬 호출 (병목 구간)  
List<SummaryResult> results;  
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {  
    List<Callable<SummaryResult>> tasks = newItems.stream()        .map(item -> (Callable<SummaryResult>) () -> summaryService.summarize(item))        .toList();    results = executor.invokeAll(tasks).stream()        .map(f -> {            try { return f.get(); }            catch (Exception e) { throw new RuntimeException(e); }        })        .toList();}  
  
// 3단계: 순차 저장 (DB write는 순서 보장)  
results.forEach(articleRepository::save);  

5건이 동시 실행되어 가장 느린 1건만 기다리면 됩니다. 총 AI 호출 시간이 5 × 30초 → ~30초로 줄었습니다.

이 리팩터링 과정에서 ArticleSummaryService 내부 record였던 SummaryResult를 별도 클래스로 분리했습니다. 내부 record는 해당 클래스에서만 쓸 때 적합하지만, RssFetchService에서도 타입을 참조하게 되어 분리하는 것이 명확했습니다.

마치며