infra
Platform

모듈 맵

[Infra Ops] 써드파티 API와 공공 인프라 연계 실무

0 / 52 완료

펼치기
0 / 52 완료0%

Infra-ops · 26 / 52

[Infra Ops] 써드파티 API와 공공 인프라 연계 실무

NICE 본인인증, 전자서명, SMS/메일 게이트웨이, 외부 기관 API 연계까지

🚨INCIDENT ALERT
HIGH

운영 서버에서 NICE 본인인증 연동 테스트를 하는데 "연결 거부"가 납니다. 개발 서버에서는 됐는데 운영에서만 안 됩니다. 방화벽 담당자에게 물었더니 "Outbound 오픈 요청서 작성해서 주세요"라고 합니다. 무엇을 적어야 할지, 오픈 후에도 안 된다면 어떻게 점검해야 할지 막막합니다. 또 전자서명 연동에는 JKS 파일이 필요하다고 하는데 이게 뭔지도 모르겠습니다.

이 모듈에서는 외부 기관 API 연계의 전형적인 유형과 사전 점검 순서, JKS/TrustStore 개념, SMS/PG/인증 API 연계 운영 노하우를 다룹니다.

이번 챕터에서 배울 것
  • 1외부 API 연계 전 방화벽 오픈 요청에 필요한 정보를 정확히 파악할 수 있다
  • 2nc, openssl s_client, curl을 순서대로 사용해 외부 연결 문제를 단계별로 진단할 수 있다
  • 3JKS(KeyStore)와 TrustStore의 역할 차이를 설명하고 오류를 해결할 수 있다
  • 4SMS, PG, 본인인증 API 연계 시 반복되는 운영 이슈 패턴을 설명할 수 있다
  • 5Circuit Breaker 개념과 외부 API timeout 설정이 서버 안정성에 미치는 영향을 설명할 수 있다

외부 연계 유형과 사전 준비

💡개념

외부 기관 API 연계의 대표 유형

외부 API 연계는 "우리 코드를 짜는 것"이 아니라 "우리 서버가 외부 시스템과 신뢰를 맺는 것"입니다. 방화벽 오픈, 인증서 교환, IP 화이트리스트 등록처럼 인프라 레이어에서 먼저 해결해야 할 일들이 코드 작성보다 앞서 있습니다. 유형별로 요구사항이 다르기 때문에 어떤 종류의 연계인지 먼저 파악하지 않으면 준비해야 할 것을 빠뜨리게 됩니다.

외부 기관 API 연계의 대표 유형

처음 공공기관 프로젝트에 투입됐을 때 "NICE 연동이 막혔습니다", "SignKorea JKS 파일이 필요하대요", "PG사에서 IP 화이트리스트 등록해달라고 합니다" 같은 요청이 동시에 들어옵니다. 각각 무엇을 해야 하는 작업인지, 사전에 무엇을 준비해야 하는지 모르면 연계 하나하나에서 막힙니다. 유형별로 요구사항이 다르기 때문에 먼저 어떤 종류의 연계인지 파악하는 것이 시작입니다.

공공기관이나 금융 프로젝트에서 자주 만나는 외부 연계 유형입니다. 각각 연계 방식과 준비 사항이 다릅니다. 처음 접하면 "왜 이렇게 복잡한가" 싶지만, 대부분은 보안 요구사항(신원 증명, 암호화, 감사 로그)에서 비롯됩니다.

주요 외부 연계 유형:

유형대표 서비스연계 방식특이사항
본인인증NICE, KCB, KMCHTTP API + 암복호화암호화 키 관리, IP 등록 필요
전자서명SignKorea, CrossCertHTTPS + mTLS (클라이언트 인증서)JKS 인증서 관리
PG(결제)KG이니시스, NHN KCPHTTPS API, WebhookIP 화이트리스트, 테스트/운영 키 분리
SMS/알림톡AWS SNS, 나이스정보통신, 카카오HTTPS REST APIAPI 키, 발신번호 사전 등록
공공 Open API행안부, 건강보험공단 등HTTPS + API Key서비스 신청 후 심사 과정 필요
파일 전송SFTP, AS2, VANTCP 22/4080별도 방화벽 오픈, 인증서 교환

연계 전 체크리스트:

로컬 터미널
# 외부 기관에서 확인해야 할 정보
# - 운영 서버 IP/도메인 및 포트
# - 프로토콜 (HTTP/HTTPS, TCP)
# - 인증 방식 (API Key, 클라이언트 인증서, IP 화이트리스트)
# - 테스트 환경 계정/엔드포인트 별도 제공 여부

# 방화벽 오픈 요청 시 필요한 정보
# - 출발지: 우리 운영 서버 IP (WAS 서버들)
# - 목적지: 외부 API 서버 IP 또는 도메인
# - 목적지 포트: 443 (HTTPS), 80 (HTTP), 22 (SFTP) 등
# - 방향: Outbound (내부 → 외부)
# - 프로토콜: TCP

외부 API 연결 사전 점검 순서

💡개념

nc → openssl → curl — 단계별 진단

외부 API 연결이 안 될 때 무작정 앱 로그만 보면 원인을 찾기 어렵습니다. 네트워크 계층부터 단계적으로 점검하면 어느 지점에서 막히는지 빠르게 특정할 수 있습니다.

nc → openssl → curl — 단계별 진단

3단계 점검 순서:

로컬 터미널
# ── 1단계: TCP 연결 가능 여부 (nc) ─────────────────
# 방화벽이 열렸는지, 서버가 포트를 열고 있는지 확인
nc -zv external-api.example.com 443
# 성공: Connection to external-api.example.com 443 port [tcp/https] succeeded!
# 실패: nc: connect to external-api.example.com port 443 (tcp) failed: Connection refused
#      → 방화벽 미오픈 또는 서버가 포트를 닫은 상태

# 1단계 실패 시 → 방화벽 오픈 요청 또는 외부 기관에 서버 상태 확인
# 1단계 성공 시 → 2단계 진행

# ── 2단계: SSL/TLS 인증서 검증 (openssl s_client) ──
# SSL 핸드셰이크가 정상인지, 인증서 체인이 완전한지 확인
openssl s_client -connect external-api.example.com:443 2>/dev/null \
  | grep -E "Verify return code|issuer|subject|expire"
# 정상: Verify return code: 0 (ok)
# 실패 예: Verify return code: 21 (unable to verify the first certificate)
#         → 중간 CA 인증서 누락, truststore 업데이트 필요

# 서버 인증서 만료일 확인
openssl s_client -connect external-api.example.com:443 2>/dev/null \
  | openssl x509 -noout -dates
# notAfter=Nov 30 23:59:59 2026 GMT

# 2단계 실패 시 → SSL 인증서 문제 (아래 TroubleCase 참고)
# 2단계 성공 시 → 3단계 진행

# ── 3단계: HTTP 응답 확인 (curl) ────────────────────
# 실제 API 응답 코드와 내용 확인
curl -m 10 -s -o /dev/null -w "%{http_code}" https://external-api.example.com/health
# 200: 정상
# 403: IP 화이트리스트 미등록 또는 API Key 오류
# 401: 인증 실패
# 000: 연결 자체 실패 (1단계로 되돌아가기)

# 응답 본문까지 확인
curl -m 10 -s https://external-api.example.com/health
# {"status":"ok"} 또는 에러 메시지

# 응답 시간 측정 (timeout 설정 기준)
curl -m 30 -w "\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTotal: %{time_total}s\n" \
  -s -o /dev/null https://external-api.example.com/health

JKS와 TrustStore — Java SSL 인증서 관리

💡개념

KeyStore vs TrustStore — 헷갈리는 개념 정리

전자서명 API 연동 중 javax.net.ssl.SSLHandshakeException: PKIX path building failed 오류가 납니다. "TrustStore에 CA를 추가해야 한다"는 말을 들었는데, 이미 JKS 파일을 설정했습니다. KeyStore와 TrustStore가 다른 것인지 처음 접하면 혼란스럽습니다. 두 개념은 방향이 달라서, 어느 쪽이 문제인지 구분하지 못하면 엉뚱한 곳을 고치게 됩니다.

Java에서 SSL 인증서 관련 오류가 나면 KeyStore와 TrustStore 개념 혼동이 원인인 경우가 많습니다. 두 개념은 방향이 다릅니다. KeyStore는 "나의 인증서"(클라이언트가 서버에 제시), TrustStore는 "신뢰하는 CA 목록"(서버 인증서를 검증하기 위한)입니다.

KeyStore vs TrustStore:

항목KeyStore (JKS)TrustStore
역할나의 인증서와 개인키 보관신뢰할 CA 인증서 목록
언제 필요mTLS (클라이언트 인증서 요구)자체 서명 인증서, 사설 CA
Java 옵션-Djavax.net.ssl.keyStore-Djavax.net.ssl.trustStore
기본값없음JDK의 cacerts (공인 CA 기본 포함)

JKS 관련 자주 쓰는 명령어:

로컬 터미널
# JKS 파일 내용 확인 (어떤 인증서가 들어있는지)
keytool -list -keystore client-cert.jks -storepass 비밀번호
# 출력: Alias name, Entry type, Certificate fingerprint

# PEM 인증서를 JKS로 변환 (외부 기관에서 PEM 발급 시)
# 1단계: PEM + 개인키 → PKCS12 변환
openssl pkcs12 -export \
  -in client.crt \
  -inkey client.key \
  -out client.p12 \
  -name myalias \
  -passout pass:임시비밀번호

# 2단계: PKCS12 → JKS 변환
keytool -importkeystore \
  -srckeystore client.p12 \
  -srcstoretype PKCS12 \
  -srcstorepass 임시비밀번호 \
  -destkeystore client.jks \
  -deststoretype JKS \
  -deststorepass jks비밀번호

# TrustStore에 외부 CA 인증서 추가 (사설 CA 또는 중간 CA)
keytool -importcert \
  -keystore truststore.jks \
  -storepass trustpass \
  -alias external-ca \
  -file external-ca.crt \
  -noprompt

# Java 앱 실행 시 JKS 사용 설정
java \
  -Djavax.net.ssl.keyStore=/etc/ssl/client.jks \
  -Djavax.net.ssl.keyStorePassword=비밀번호 \
  -Djavax.net.ssl.trustStore=/etc/ssl/truststore.jks \
  -Djavax.net.ssl.trustStorePassword=trustpass \
  -jar app.jar

Circuit Breaker — 외부 API 장애 격리

💡개념

timeout 설정과 Circuit Breaker의 필요성

외부 API가 갑자기 느려지거나 응답을 하지 않을 때, 우리 서버가 함께 장애로 빠지는 것을 방지해야 합니다. timeout만으로는 부족하고, Circuit Breaker 패턴이 필요합니다.

timeout 설정의 중요성:

로컬 또는 서버
# 잘못된 예: timeout 없음 → 스레드 무기한 대기
curl https://external-api.example.com/payment

# 올바른 예: 적절한 timeout 설정
curl -m 10 https://external-api.example.com/payment
# 10초 내 응답 없으면 포기

# Java HttpClient timeout 설정 예시
# connection-timeout: 3초 (TCP 연결 수립)
# read-timeout: 10초 (응답 본문 수신)

Circuit Breaker 동작 원리:

[CLOSED 상태]  정상 동작, 모든 요청 통과
      │
      │ 실패율 임계치 초과 (예: 5초 내 5회 실패)
      ▼
[OPEN 상태]    모든 요청 즉시 실패 반환 (외부 API 호출 없음)
              → 스레드 블로킹 없음, 빠른 실패
      │
      │ 일정 시간 후 (예: 30초)
      ▼
[HALF-OPEN]   일부 요청만 통과시켜 복구 확인
      │
      ├─ 성공 → CLOSED로 복구
      └─ 실패 → 다시 OPEN

Resilience4j (Spring Boot) 설정 예시:

YAML
# application.yml
resilience4j:
  circuitbreaker:
    instances:
      smsService:
        failure-rate-threshold: 50          # 50% 실패 시 OPEN
        wait-duration-in-open-state: 30s    # 30초 후 HALF-OPEN 시도
        sliding-window-size: 10             # 최근 10개 요청 기준
        permitted-number-of-calls-in-half-open-state: 3

실습 — 외부 API 연결 사전 점검

1외부 API 3단계 연결 점검

TCP 연결부터 단계적으로 점검합니다. 실제 외부 API 서버 주소로 교체하여 사용합니다.

로컬 터미널
# 1단계: TCP 포트 연결 확인
nc -zv external-api.example.com 443

# 2단계: SSL 인증서 검증
openssl s_client -connect external-api.example.com:443 2>/dev/null \
  | grep "Verify return code"

# 3단계: HTTP 응답 확인 (응답 코드 + 시간)
curl -m 10 -s -o /dev/null -w "%{http_code} (%{time_total}s)\n" \
  https://external-api.example.com/health
nc -zv external-api.example.com 443
🔍실행 후 확인할 것
  • nc 명령이 'succeeded!'를 출력하는가 (TCP 연결 성공)
  • openssl 결과에 'Verify return code: 0 (ok)'가 있는가
  • curl 응답 코드가 200인가
  • 응답 시간이 timeout 설정보다 충분히 짧은가
2JKS 인증서 내용 확인

mTLS 연계 시 사용하는 JKS 파일의 인증서 정보를 확인합니다.

로컬 터미널
# JKS 파일 목록 및 만료일 확인
keytool -list -v -keystore /etc/ssl/client.jks -storepass 비밀번호 \
  | grep -E "Alias|Valid|until"

# TrustStore에 등록된 CA 목록 확인
keytool -list -keystore /etc/ssl/truststore.jks -storepass trustpass \
  | grep -E "Alias|trustedCertEntry"

# 인증서 만료 여부 빠른 확인
keytool -list -v -keystore /etc/ssl/client.jks -storepass 비밀번호 \
  | grep "until" | while read line; do
    echo "$line"
  done
keytool -list -keystore /path/to/client.jks -storepass 비밀번호
🔍실행 후 확인할 것
  • JKS 파일 내 alias가 연계 기관과 협의한 이름과 일치하는가
  • 인증서 만료일이 현재 날짜 이후인가
  • TrustStore에 외부 기관의 CA 인증서가 등록됐는가
  • privateKeyEntry가 있는가 (클라이언트 인증서 정상 포함)

트러블슈팅

원인: 우리 서버의 Outbound 방화벽이 막혀 있습니다. 개발 서버는 방화벽이 느슨하고 운영 서버는 엄격한 경우가 많아 개발에서는 됐는데 운영에서는 안 되는 전형적인 패턴입니다.

로컬 터미널
# 우리 서버에서 외부 API 서버로 직접 연결 테스트
nc -zv external-api.example.com 443
# 실패: nc: connect to external-api.example.com port 443 failed: Connection timed out
# → Outbound 방화벽 미오픈 확인 필요

# 방화벽 오픈 요청 정보 수집
dig +short external-api.example.com    # 도메인 → IP 조회
# 여러 IP가 나오면 모두 화이트리스트 등록 요청

# 라우팅 경로 확인
traceroute external-api.example.com
# 어느 홉에서 막히는지 확인

# 방화벽 오픈 후 재테스트
nc -zv external-api.example.com 443
# 성공하면 다음 단계(SSL, HTTP) 점검

해결: 보안팀 또는 방화벽 담당자에게 Outbound 오픈 요청서를 제출합니다. 요청서에 포함해야 할 내용: 출발지 서버 IP, 목적지 IP(외부 API IP), 목적지 포트(443), 프로토콜(TCP), 방향(Outbound), 오픈 사유(서비스명 및 연계 목적).

원인: 외부 API 서버의 인증서 체인에서 중간 CA(Intermediate CA) 인증서가 변경됐는데 우리 서버의 TrustStore(cacerts 또는 커스텀 truststore.jks)가 업데이트되지 않았습니다. 외부 기관이 인증서를 갱신하면서 중간 CA가 달라진 경우에 자주 발생합니다.

로컬 터미널
# 현재 외부 서버의 인증서 체인 확인
openssl s_client -connect external-api.example.com:443 \
  -showcerts 2>/dev/null | grep -E "BEGIN CERTIFICATE|subject|issuer"

# 출력에서 중간 CA 인증서 확인
# 체인이 완전하지 않으면: Chain: End Entity → (중간 CA 없음) → Root CA
# 정상 체인: End Entity → Intermediate CA → Root CA

# 중간 CA 인증서 추출 (2번째 인증서가 보통 중간 CA)
openssl s_client -connect external-api.example.com:443 \
  -showcerts 2>/dev/null | awk '/BEGIN CERT/,/END CERT/' | \
  awk 'BEGIN{n=0} /BEGIN CERT/{n++} n==2' > intermediate-ca.crt

# 추출한 중간 CA를 TrustStore에 추가
keytool -importcert \
  -keystore /etc/ssl/truststore.jks \
  -storepass trustpass \
  -alias intermediate-ca-new \
  -file intermediate-ca.crt \
  -noprompt

# Java 기본 cacerts에 추가 (sudo 필요)
sudo keytool -importcert \
  -keystore $JAVA_HOME/jre/lib/security/cacerts \
  -storepass changeit \
  -alias intermediate-ca-new \
  -file intermediate-ca.crt \
  -noprompt

# WAS 재시작 후 연결 테스트
sudo systemctl restart tomcat
curl -v https://external-api.example.com/health 2>&1 | grep -E "verify|Verify"
💼
실무 맥락
현업 패턴

실제 업무에서 이 지식이 쓰이는 상황:

공공기관이나 금융 프로젝트에서 외부 연계 오류는 오픈 전에 가장 많이 발생하는 장애 유형입니다. 대부분은 방화벽 오픈 누락과 SSL 인증서 문제입니다.

새 외부 연계 추가 시 표준 절차:

로컬 터미널
# 1. 외부 기관에서 받아야 할 정보 목록 작성
# - 운영/테스트 엔드포인트 URL
# - IP 화이트리스트 등록 (우리 서버 IP 전달 필요)
# - API Key 또는 클라이언트 인증서 발급
# - 테스트 계정 (SMS 발송 수신번호, 결제 테스트 카드 등)

# 2. 방화벽 오픈 요청 (개발→운영 환경 모두)
# 3. 연결 사전 점검 (3단계: nc → openssl → curl)
nc -zv api.external.com 443
openssl s_client -connect api.external.com:443 2>/dev/null | grep "Verify return code"
curl -m 10 -s -o /dev/null -w "%{http_code}" https://api.external.com/health

# 4. 앱 연동 테스트 (테스트 환경 → 운영 환경 순서)
# 5. Circuit Breaker 및 timeout 설정 검토

SMS 발송 실패 시 빠른 점검:

로컬 또는 서버
# API 직접 호출로 응답 코드/메시지 확인
curl -X POST https://sms-api.example.com/send \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to":"01012345678","message":"테스트"}'
# 응답: {"result":"error","code":"E401","message":"Invalid API Key"}
# → API Key 만료 또는 IP 화이트리스트 미등록 확인

외부 API 연계는 우리가 통제할 수 없는 외부 시스템에 의존하는 구간입니다. Circuit Breaker와 적절한 timeout으로 외부 장애가 내부 시스템으로 전파되는 것을 막는 것이 운영 안정성의 핵심입니다. 다음 모듈에서는 SAML과 OAuth 기반 SSO 연계 구성과 장애 분석을 다룹니다.

지식 확인

퀴즈 — 4문제

Q1

외부 API 연계 전 방화벽 오픈 요청 시 반드시 확인해야 할 사항이 아닌 것은?

Q2

Java KeyStore(JKS) 인증서 파일이 외부 API 연계에 필요한 이유는?

Q3

SMS 발송이 갑자기 실패할 때 가장 먼저 확인해야 할 로그는?

Q4

외부 API timeout을 너무 길게(예: 60초) 설정하면 우리 서버에 생기는 문제는?

0 / 4 답변

🧪 실습으로 확인하기

Nginx 설치 및 기동

초급

Linux 서버에 Nginx를 설치하고 systemd 서비스로 등록하여 80포트에서 응답하는 상태까지 만든다.

30📋 3단계💻 직접 환경
실습 시작하기 →

이것도 배워보세요

infra-ops입문 · 50
[Infra Ops] SMTP 메일과 SMS 게이트웨이 운영 실무
인프라 서비스 운영 트랙 계속
linux입문 · 30
[Linux] 개발자가 왜 리눅스 서버와 커맨드라인을 반드시 배워야 하는가
Linux 트랙 시작점