IPFS 성능: 파일 검색 및 게이트웨이 응답 시간 개선 방법

“IPFS는 느리다”는 말은 개발자들 사이에서 가장 흔한 불만 중 하나입니다 — 그리고 동시에 가장 쉽게 해결할 수 있는 문제이기도 합니다. 원인은 거의 항상 프로토콜이 아닌 접근 방식에 있습니다. 이 가이드는 프로덕션에서 IPFS 레이턴시를 제거하는 네 가지 기법을 다룹니다.

빠른 참조: 속도별 IPFS 접근 방식#

프로덕션에서 퍼블릭 게이트웨이를 사용하고 있다면, 전용 게이트웨이로 전환하는 것만으로 대부분의 레이턴시가 즉시 사라집니다.

퍼블릭 게이트웨이가 느린 이유#

퍼블릭 게이트웨이는 최근에 본 적 없는 모든 CID에 대해 DHT(Distributed Hash Table) 조회를 수행합니다. DHT 조회란 콘텐츠를 보유한 피어를 찾기 위해 네트워크 전체의 수십 개 피어에 쿼리하는 것을 의미합니다 — 이 왕복 과정은 콜드 요청에서 2~15초가 소요됩니다.

캐시 히트 시에도 퍼블릭 게이트웨이는 수백만 명의 사용자에게 서비스를 제공합니다. 최근에 핀 고정한 파일은 캐시 우선순위가 낮아 요청 사이에 제거될 수 있습니다.

해결책 1: 전용 게이트웨이#

전용 게이트웨이는 계정에 비공개로 할당됩니다. 핀 고정한 파일은 해당 게이트웨이에 즉시 캐시됩니다 — 콜드든 웜이든 어떤 요청에서도 DHT 조회가 발생하지 않습니다.

# 변경 전: 퍼블릭 게이트웨이, 느리고 불안정
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# 변경 후: 전용 게이트웨이, 빠르고 안정적
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

IPFS.NINJA 대시보드에서 게이트웨이를 생성하고 프로젝트에 맞게 슬러그를 설정하세요. 게이트웨이 슬러그는 제한 접근 모드(토큰 필요) 또는 퍼블릭 정적 에셋을 위한 오픈 모드를 지원합니다.

해결책 2: 읽기 시점이 아닌 쓰기 시점에 핀 고정#

파일이 생성되는 즉시 핀 고정하여 어떤 사용자 요청이 오기 전에 게이트웨이가 파일을 보유하도록 합니다. 가장 빠른 요청은 캐시 미스를 전혀 발생시키지 않는 요청입니다.

# 한 단계로 업로드와 핀 고정 실행
curl -X POST https://api.ipfs.ninja/upload/new \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "content": {
      "data": "BASE64_ENCODED_CONTENT",
      "type": "image/png"
    },
    "description": "Product hero image v2"
  }'

# 응답 — CID를 저장하고 url을 즉시 서빙
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

다른 노드나 핀 고정 서비스의 기존 CID가 있다면 재업로드 없이 재핀 고정할 수 있습니다:

curl -X POST https://api.ipfs.ninja/pin \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{"cid": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi"}'

전체 업로드 API 참조는 IPFS에 파일 업로드하는 방법을 참고하세요.

해결책 3: 게이트웨이 앞에 CDN 배치#

전용 게이트웨이는 고정된 리전에서 서비스를 제공합니다. 사용자가 여러 대륙에 걸쳐 있다면 가장 가까운 거점에서 서비스하기 위해 CDN 엣지 레이어를 추가하세요.

IPFS는 콘텐츠 주소 지정 방식을 사용하기 때문에 — 특정 CID는 항상 동일한 바이트로 해석됩니다 — 영구적으로 캐시할 수 있습니다:

Cache-Control: public, max-age=31536000, immutable

Cloudflare 예시 (무료 플랜으로 대부분의 정적 에셋 워크로드 처리 가능):

1. 게이트웨이 서브도메인(my-app.gw.ipfs.ninja)을 Cloudflare 프록시 CNAME으로 추가합니다.
2. Page Rule을 생성합니다: my-app.gw.ipfs.ninja/ipfs/* → Cache Everything, Edge Cache TTL: 한 달.
3. 첫 번째 요청이 게이트웨이에 도달하고 가장 가까운 엣지 PoP에 캐시됩니다. 이후 모든 요청은 Cloudflare에서 서비스됩니다.

결과: 글로벌 TTFB가 50200 ms에서 1050 ms로 감소합니다.

해결책 4: 이미지 최적화 API#

원본 해상도로 서비스되는 IPFS 이미지는 페이지를 느리게 하고 Core Web Vitals에 악영향을 미칩니다. 엣지에서 리사이징하고 모던 포맷으로 서비스하기 위해 이미지 최적화 엔드포인트를 사용하세요:

# 원본 (게이트웨이를 통한 전체 해상도)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# 너비 800px로 리사이즈, WebP로 변환
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# 정사각형 썸네일
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=cover

React에서:

function IPFSImage({ cid, width }) {
  return (
    <img
      src={`https://api.ipfs.ninja/image/${cid}?w=${width}&format=webp`}
      width={width}
      loading="lazy"
      decoding="async"
    />
  );
}

최적화 엔드포인트는 각 (cid, width, format) 조합을 캐시합니다 — 동일한 파라미터를 사용하는 이후 요청은 오리진을 완전히 건너뜁니다.

체크리스트#

• 퍼블릭 게이트웨이에서 전용 게이트웨이로 전환
• 읽기 시점이 아닌 쓰기 시점(업로드 시)에 콘텐츠 핀 고정
• 게이트웨이 응답에 Cache-Control: immutable 설정
• 글로벌 트래픽을 위해 게이트웨이 앞에 CDN 추가
• 원본 게이트웨이 URL 대신 최적화 엔드포인트를 통해 이미지 서비스

속도뿐만 아니라 가용성을 위해 핀 고정이 중요한 이유에 대한 배경은 IPFS 핀 고정이란을 참고하세요.

핀 고정을 시작할 준비가 되셨나요? 무료 계정 만들기 — 파일 50개, 스토리지 1 GB, 대역폭 2 GB/월. 신용카드 불필요.

이 글에 대하여: 이 글은 IPFS.NINJA의 콘텐츠 생성 워크플로를 사용해 AI 어시스턴트가 초안을 작성하고 Nacho Coll이 검토 및 승인했습니다. 모든 코드 예시는 라이브 IPFS.NINJA API를 대상으로 검증되었습니다. 부정확한 내용을 발견하면 https://github.com/ipfs-ninja/feedback 에 이슈를 열어주세요. 콘텐츠에 AI를 활용하는 방법과 IPFS.NINJA를 만드는 사람들을 만나보세요.