UI5 모드
ABAP

sRFC vs aRFC — 타임아웃 원인이 다르다 #shorts #SAP #ABAP

수정: 2026년 8월 22일 👁 0 · ♥ 0
▶ YouTube에서 보기

새벽 배치가 멈춘 날 — RFC 타임아웃과의 첫 만남

새벽 2시, 물류 시스템의 재고 동기화 배치가 "TIME_OUT" 덤프를 남기고 멈췄다는 알림을 받아본 적이 있다면, 이 글이 도움이 될 것입니다. ERP에서 창고관리 시스템으로 RFC를 호출하는 커스텀 함수모듈 Z_WM_GET_BIN_STOCK이 평소 3초 만에 끝나던 것이 갑자기 10분 넘게 응답하지 않는 상황 — 실무에서 가장 자주 만나는 RFC 장애 유형입니다. 이 글에서는 SAP NetWeaver AS ABAP 7.40 이상(S/4HANA 포함) 환경을 기준으로, RFC 타임아웃이 발생하는 구조적 원인을 계층별로 분해하고, 진단 트랜잭션 활용법과 코드 수준의 해결 예제까지 다룹니다. 읽고 나면 다음을 할 수 있게 됩니다.

  • sRFC/aRFC/tRFC/qRFC의 타임아웃 특성 차이를 설명할 수 있다
  • ST22, SM59, SM21, SMGW로 끊긴 지점을 특정할 수 있다
  • 동기 호출을 비동기·백그라운드 방식으로 안전하게 전환할 수 있다

ABAP 기본 문법과 함수모듈 개념, 트랜잭션 코드 실행 정도의 경험이 있다면 충분히 따라올 수 있는 중급 난이도입니다.

RFC 통신은 어떻게 흘러가는가 — sRFC, aRFC, tRFC/qRFC

RFC 호출을 택배에 비유하면 이해가 쉽습니다. sRFC(동기)는 직접 방문 수령입니다. 호출한 워크프로세스가 상대 시스템의 응답이 올 때까지 그 자리에서 기다립니다. 문제는 이 "기다림"이 다이얼로그 프로세스를 점유한 채 이루어진다는 점입니다. 프로파일 파라미터 rdisp/max_wprun_time(기본값은 시스템마다 다르나 일반적으로 600초)을 넘기면 호출한 쪽에서 TIME_OUT 덤프가 발생합니다.

aRFC(비동기)는 등기 발송입니다. STARTING NEW TASK로 호출을 던져놓고 내 작업을 계속하다가, 콜백으로 결과를 받습니다. 호출자가 블로킹되지 않으므로 다이얼로그 타임아웃에서 자유롭지만, 상대 시스템의 다이얼로그 프로세스를 즉시 소비한다는 점은 같습니다.

tRFC/qRFC는 우체국 접수함입니다. IN BACKGROUND TASK로 호출하면 데이터가 일단 로컬 큐(ARFCSSTATE 등)에 저장되고, COMMIT WORK 시점에 전송이 시도됩니다. 상대가 다운되어 있어도 호출 자체는 실패하지 않고 재시도됩니다. 즉 "타임아웃"이 호출자 덤프가 아니라 SM58의 미처리 큐 적체로 나타나는 것이 특징입니다. 최신 환경에서는 tRFC/qRFC의 후속인 bgRFC 사용이 권장됩니다.

통신 경로는 호출자 워크프로세스 → 로컬 게이트웨이 → (네트워크/방화벽) → 원격 게이트웨이 → 원격 디스패처 → 원격 다이얼로그 워크프로세스 순으로 흐릅니다. 타임아웃은 이 사슬의 어느 고리에서든 발생할 수 있으므로, "RFC가 느리다"는 말만으로는 원인을 알 수 없습니다.

어디서 끊겼는지 찾기 — 진단 트랜잭션 활용

진단은 일반적으로 다음 순서가 효율적입니다.

  1. ST22 — 덤프 이름이 단서입니다. TIME_OUT이면 호출자 쪽 다이얼로그 제한 초과, CALL_FUNCTION_REMOTE_ERROR면 상대 시스템/통신 계층 문제일 가능성이 높습니다.
  2. SM59 — 해당 목적지의 Connection Test와 Remote Logon을 실행합니다. 여기서부터 느리다면 코드가 아니라 네트워크·게이트웨이 문제입니다.
  3. SM21 / SMGW — 시스템 로그에서 CPIC 오류 코드(예: 통신 상대의 비정상 종료)와 게이트웨이의 활성 연결 수를 확인합니다.
  4. ST05(RFC 트레이스) / STAD — 개별 호출의 소요 시간을 호출 준비, 네트워크, 원격 실행 구간으로 나눠 볼 수 있어, "상대 함수모듈 자체가 느린 것인지"를 판별하는 데 유용합니다.
  5. SM66 / SM50(상대 시스템) — 원격 시스템의 워크프로세스가 전부 점유돼 대기 큐에 쌓이는지 확인합니다.

타임아웃을 만드는 다섯 가지 범인

  • 장시간 실행 함수모듈 — 상대 시스템의 Z_WM_GET_BIN_STOCK이 인덱스 없는 조건으로 대량 테이블을 풀스캔하는 경우. 가장 흔하고, 해결도 상대 코드 튜닝이 우선입니다.
  • 다이얼로그 프로세스 부족 — RFC는 원격에서 다이얼로그 프로세스로 실행됩니다. 상대 시스템에 RFC 폭주가 오면 rdisp/rfc_max_wait_time 등 리소스 제어 파라미터에 걸려 대기가 길어집니다.
  • 게이트웨이/CPIC 계층 — gw/reg_timeout, gw/gw_disconnect 같은 게이트웨이 파라미터, 또는 CPIC 타임아웃으로 유휴 연결이 끊기는 경우입니다.
  • 네트워크·방화벽 — 방화벽이 일정 시간 무통신 TCP 세션을 조용히 끊어버리면, 오래 걸리는 호출의 응답이 돌아올 길이 사라집니다. "짧은 호출은 되는데 긴 호출만 실패"하는 전형적 패턴입니다.
  • 호출자 쪽 설계 문제 — 다이얼로그 세션에서 대량 데이터를 sRFC로 동기 처리하는 구조 자체가 원인인 경우. 이때는 파라미터 조정이 아니라 아키텍처 전환이 답입니다.

SM59 목적지와 게이트웨이 파라미터 다듬기 — 1단계 실전

먼저 호출 코드에서 통신 예외를 반드시 잡아 로그를 남기는 기본기부터 갖춥니다. 예제 시나리오는 ERP가 창고 시스템 목적지 WMS_PRD_RFC로 재고를 조회하는 구조입니다.

DATA: lt_stock TYPE STANDARD TABLE OF zwm_s_bin_stock,
      lv_msg   TYPE c LENGTH 220.

CALL FUNCTION 'Z_WM_GET_BIN_STOCK'
  DESTINATION 'WMS_PRD_RFC'
  EXPORTING
    iv_warehouse = 'W001'
    iv_max_rows  = 5000          " 무제한 조회 금지: 페이징 필수
  TABLES
    et_stock     = lt_stock
  EXCEPTIONS
    communication_failure = 1 MESSAGE lv_msg
    system_failure        = 2 MESSAGE lv_msg
    OTHERS                = 3.

IF sy-subrc NE 0.
  " 통신 오류는 반드시 원문 메시지와 함께 애플리케이션 로그(BAL)에 적재
  zcl_wm_log=>write( iv_dest = 'WMS_PRD_RFC' iv_text = lv_msg ).
  RAISE EXCEPTION TYPE zcx_wm_rfc_error.
ENDIF.

MESSAGE lv_msg 구문이 핵심입니다. 이것이 없으면 "왜 끊겼는지"가 로그에 남지 않아 진단이 원점으로 돌아갑니다. SM59에서는 해당 목적지의 Special Options 탭에서 타임아웃 관련 설정을, 유니코드/직렬화 탭에서 전송 방식을 점검합니다. 게이트웨이 쪽에서는 gw/reg_timeout(등록 프로그램 응답 대기)과 방화벽 유휴 차단 시간보다 짧은 주기의 TCP keepalive 설정을 Basis 팀과 함께 검토하는 것이 일반적으로 권장됩니다. 파라미터를 무작정 늘리는 것은 장애를 "더 늦게 발견"하게 만들 뿐이므로, 근본 원인 제거와 병행해야 합니다.

동기 호출을 비동기로 바꾸는 실전 코드 — 2단계

창고 5곳을 순차 sRFC로 조회하면 소요 시간이 합산되지만, aRFC로 병렬화하면 가장 느린 한 건의 시간으로 줄고, 호출자 레벨의 타임아웃 제어도 가능해집니다.

CLASS zcl_wm_stock_collector DEFINITION.
  PUBLIC SECTION.
    METHODS: collect IMPORTING it_wh TYPE zwm_t_warehouse,
             on_done IMPORTING p_task TYPE clike.  " 콜백
  PRIVATE SECTION.
    DATA: mv_open  TYPE i,
          mt_stock TYPE zwm_t_bin_stock.
ENDCLASS.

CLASS zcl_wm_stock_collector IMPLEMENTATION.
  METHOD collect.
    LOOP AT it_wh INTO DATA(lv_wh).
      CALL FUNCTION 'Z_WM_GET_BIN_STOCK'
        STARTING NEW TASK lv_wh
        DESTINATION 'WMS_PRD_RFC'
        CALLING on_done ON END OF TASK
        EXPORTING iv_warehouse = lv_wh
        EXCEPTIONS
          system_failure        = 1
          communication_failure = 2
          resource_failure      = 3.   " 로컬 리소스 부족 시 대비
      IF sy-subrc EQ 0.
        mv_open = mv_open + 1.
      ENDIF.
    ENDLOOP.

    " 60초 상한: 전체 병렬 호출에 대한 애플리케이션 레벨 타임아웃
    WAIT FOR ASYNCHRONOUS TASKS UNTIL mv_open EQ 0 UP TO 60 SECONDS.
    IF mv_open GT 0.
      zcl_wm_log=>write( iv_text = |미응답 태스크 { mv_open }건| ).
    ENDIF.
  ENDMETHOD.

  METHOD on_done.
    DATA lt_part TYPE zwm_t_bin_stock.
    RECEIVE RESULTS FROM FUNCTION 'Z_WM_GET_BIN_STOCK'
      TABLES et_stock = lt_part
      EXCEPTIONS OTHERS = 4.
    IF sy-subrc EQ 0.
      APPEND LINES OF lt_part TO mt_stock.
    ENDIF.
    mv_open = mv_open - 1.
  ENDMETHOD.
ENDCLASS.

WAIT ... UP TO 60 SECONDS가 이 패턴의 백미입니다. 시스템 파라미터에 의존하지 않고 비즈니스 요건에 맞는 타임아웃을 코드로 선언할 수 있습니다. resource_failure 예외 처리도 잊지 마세요. 병렬 태스크가 로컬 리소스를 소진하면 발생합니다.

3단계, 응답을 기다릴 필요조차 없는 쓰기성 인터페이스(예: 출고 확정 전송)는 bgRFC로 전환해 타임아웃 자체를 구조적으로 제거합니다.

DATA(lo_dest) = cl_bgrfc_destination_outbound=>create( 'WMS_PRD_RFC' ).
DATA(lo_unit) = lo_dest->create_trfc_unit( ).

CALL FUNCTION 'Z_WM_POST_GOODS_ISSUE'
  IN BACKGROUND UNIT lo_unit
  EXPORTING iv_delivery = lv_delivery.

COMMIT WORK.   " 커밋 시점에 큐 적재 → 스케줄러가 재시도 포함 전송

이 방식은 상대 시스템이 일시 다운돼도 데이터 유실 없이 자동 재시도되며, 실패 건은 SBGRFCMON에서 모니터링합니다. 다만 "결과를 즉시 화면에 보여줘야 하는" 조회성 로직에는 맞지 않으므로, 읽기=aRFC 병렬화, 쓰기=bgRFC라는 역할 분담이 일반적으로 권장됩니다.

재발을 막는 운영 체크리스트와 자주 받는 질문

Q1. 타임아웃 파라미터를 크게 늘리면 해결되나요? — 증상만 가려집니다. 워크프로세스 점유 시간이 늘어나 오히려 시스템 전체가 함께 느려지는 2차 장애로 번지기 쉽습니다. 상대 함수모듈 튜닝과 페이징 도입이 먼저입니다.

Q2. SM59 Connection Test는 성공하는데 실제 호출만 실패합니다. — Connection Test는 짧은 핑 성격의 확인이라, 방화벽의 장시간 세션 차단이나 상대 함수모듈의 처리 지연은 잡아내지 못합니다. ST05 RFC 트레이스로 실제 호출의 구간별 시간을 봐야 합니다.

Q3. aRFC로 바꿨더니 상대 시스템이 더 힘들어합니다. — 병렬화는 부하를 이전하는 것입니다. 서버 그룹(RZ12) 기반 리소스 제어와 병렬도 상한을 함께 설계해야 합니다.

운영 체크리스트: (1) 모든 RFC 호출에 통신 예외 + MESSAGE 절 + 로그 적재, (2) 조회성 인터페이스에 max_rows 페이징 강제, (3) SM58/SBGRFCMON 적체 건수 주기 점검, (4) 방화벽 유휴 차단 시간과 keepalive 주기 문서화, (5) 인터페이스별 예상 응답시간 기준선(STAD 기반) 관리.

정리, 그리고 더 파볼 주제

RFC 타임아웃은 단일 원인이 아니라 워크프로세스, 게이트웨이, 네트워크, 상대 시스템이라는 4개 계층의 문제가 같은 증상으로 나타나는 것입니다. ST22 덤프 이름으로 계층을 좁히고, sRFC 블로킹 구조 자체를 aRFC/bgRFC로 전환하는 것이 파라미터 조정보다 근본적인 해법입니다.

  • RFC 서버 그룹(RZ12) 기반 병렬 처리 설계
  • bgRFC 인바운드 큐 모니터링과 오류 재처리 전략
  • 대량 데이터 전송 시 IDoc/OData 등 대안 통신 방식과의 비교

댓글 0

아직 댓글이 없습니다.