웹훅 vs 폴링: 올바른 통합 접근 방식 선택

우리가 동기화를 통해 해결하려는 문제는 무엇인가요?

동기화(sync)는 ‘업데이트가 빠르게 보이게 한다’처럼 들리지만, 실제 목표는 더 어렵습니다: 메시지가 늦게 오거나 중복되거나 누락되더라도 두 시스템이 동일한 사실에 동의하도록 만드는 것입니다.

웹훅과 폴링의 차이는 변경 사실을 어떻게 알게 되는지에 있습니다.

웹훅은 푸시입니다. 시스템 A가 이벤트가 발생하면(예: “청구서 결제됨”) 당신의 엔드포인트로 호출합니다. 폴링은 풀입니다. 당신의 시스템이 일정에 따라 시스템 A에 "지난번 이후에 새로 생긴 게 있나요?"라고 묻습니다.

시스템을 동기화하려면 보통 이벤트와 상태 둘 다 추적해야 합니다. 이벤트는 무슨 일이 있었는지 알려주고, 상태는 현재 레코드가 어떻게 보이는지를 알려줍니다. 타이밍이 중요합니다. 통합은 거의 완벽한 순서로 실행되지 않기 때문입니다. "업데이트" 이벤트가 "생성"보다 먼저 도착하거나, 두 번 도착하거나, 아예 도착하지 않을 수 있습니다.

목표는 단지 최신성만이 아니라 정확한 데이터입니다. "정확하다"는 것은 변경을 놓치지 않고, 같은 변경을 두 번 적용하지 않으며, 다운타임 후 수동 정리 없이 복구할 수 있고, 무엇을 언제 처리했는지 증명할 수 있다는 뜻입니다.

실용적인 예: 결제 제공자가 "payment_succeeded" 같은 웹훅을 보냅니다. 당신의 앱은 주문을 만들고 결제 완료로 표시합니다. 만약 웹훅 엔드포인트가 잠시 다운되면 해당 이벤트를 보지 못할 수 있습니다. "어제 이후에 업데이트된 결제"를 묻는 폴링 작업은 이런 간극을 조정해 주문 상태를 수정할 수 있습니다.

대부분의 실제 통합은 둘 다 사용합니다: 속도를 위해 웹훅, 백필과 검증을 위해 폴링. 방법 자체보다 중요한 것은 그 방법을 둘러싼 안전장치입니다.

지연 시간과 최신성: 업데이트는 실제로 얼마나 빨리 도착하는가

사람들이 웹훅 vs 폴링을 비교할 때 보통 한 가지를 말합니다: 다른 곳의 변경을 당신의 앱이 얼마나 빨리 알아차리느냐. 최신성은 단순한 옵션이 아닙니다. 고객 지원 건수, 중복 작업, 사용자가 보이는 정보를 신뢰하는지에 영향을 줍니다.

폴링은 스케줄에 맞춰 묻기 때문에 본질적으로 지연이 있습니다. 5분마다 폴링하면 업데이트는 몇 초 후부터 거의 5분 뒤까지 도착할 수 있고, 여기에 API 응답 시간이 더해집니다. 폴링을 더 자주 하면 최신성은 좋아지지만, API 호출과 비용이 늘고 속도 제한에 걸릴 확률이 커집니다.

웹훅은 제공자가 이벤트를 즉시 푸시하기 때문에 거의 실시간처럼 느껴질 수 있습니다. 하지만 즉시성이나 보장이 있는 것은 아닙니다. 제공자는 이벤트를 배치로 보내거나 나중에 재시도하거나 전달을 일시중지할 수 있습니다. 당신의 시스템 또한 지연을 추가할 수 있습니다(큐 백로그, DB 락, 배포 등). 더 정확한 기대치는: 상태가 정상이면 빠르고, 그렇지 않으면 결국 일관성을 이루는 정도입니다.

트래픽 형태도 중요합니다. 폴링은 일정하고 예측 가능한 부하를 줍니다. 웹훅은 버스티합니다: 바쁜 시간에 분당 수백 개의 이벤트가 오고, 그다음엔 아무것도 없을 수 있습니다. 웹훅을 수용한다면 스파이크를 가정하고 이벤트를 큐에 넣어 제어된 속도로 처리할 계획을 세우세요.

설계 전에 목표 최신성 창(window)을 정하세요:

• 몇 초: 사용자 알림, 채팅, 결제 상태
• 몇 분: 지원 도구, 관리자 뷰, 가벼운 보고
• 몇 시간: 야간 정합, 우선순위 낮은 분석

영업 팀이 새 리드를 1분 이내에 봐야 한다면 웹훅이 그 요구를 충족합니다. 몇 시간 간격의 안전 폴링은 놓친 이벤트를 잡고 최종 상태를 확인할 수 있습니다.

운영 환경에서 실제로 보게 될 실패 모드

대부분의 통합 실패는 지루하고 반복 가능한 방식으로 발생합니다. 놀라운 건 뭔가가 고장난다는 사실 자체가 아니라, 조용히 고장난다는 점입니다. 속도 논쟁은 쉽지만, 신뢰성 확보가 진짜 작업입니다.

폴링 실패는 보통 "업데이트를 보지 못했다"처럼 보입니다. 타임아웃으로 요청이 중간에 끊길 수 있고, HTTP 200만 검사하고 본문 검증을 하지 않으면 부분 응답이 슬쩍 통과할 수 있습니다. 페이지네이션 규칙 변경도 흔합니다: API가 정렬 순서를 바꾸거나 페이지 규칙을 바꾸거나 페이지 번호에서 커서 기반으로 전환하면 항목을 건너뛰거나 다시 읽게 됩니다. 또 흔한 실수는 로컬 클럭을 사용해 "updated_since"를 필터링했다가 시계가 맞지 않거나 제공자가 다른 타임스탬프 필드를 사용하면 업데이트를 놓치는 경우입니다.

웹훅은 다르게 실패합니다. 전달은 보통 "적어도 한 번(at least once)"이므로 제공자는 네트워크 오류 시 재시도하고 당신은 중복을 보게 됩니다. 엔드포인트가 10분 동안 다운되면 나중에 오래된 이벤트가 버스트로 올 수 있습니다. 서명 검증 문제도 자주 발생합니다: 시크릿이 교체되거나 잘못된 원시 페이로드를 검증하거나 프록시가 헤더를 변경하면 유효한 이벤트가 잘못된 것으로 보일 수 있습니다.

양쪽 방식에서 공통적인 실패 모드는 중복과 순서 뒤섞임입니다. 동일한 이벤트를 여러 번 받거나, 늦게 도착하거나, 순서가 바뀌어 도착하고, 예상하던 필드가 없는 페이로드를 받는 것을 가정하세요.

거의 절대 "정확히 한 번(exactly once)"을 얻지 못합니다. "적어도 한 번"을 가정하고 안전하게 처리하도록 설계하세요. 아이덴포턴시(idempotency) 키(이벤트 ID 또는 제공자 오브젝트 버전)를 저장해 중복을 무시하고, 저장된 것보다 최신인 경우에만 업데이트를 적용하세요. 또한 받은 것과 처리한 것을 기록해 추적과 재실행이 가능하도록 하세요.

요율 제한과 비용: API 사용량을 통제하기

요율 제한(rate limits)은 웹훅 vs 폴링 논쟁이 이론에서 예산과 신뢰성 문제로 바뀌는 지점입니다. 추가 요청마다 시간과 비용이 들고, 제공자와의 관계에 악영향을 줄 수 있습니다.

폴링은 아무것도 바뀌지 않았을 때도 확인하는 비용이 들기 때문에 할당량을 빨리 소모합니다. 특히 제한이 사용자별 또는 토큰별일 때 문제가 됩니다: 고객 1,000명이 매분 폴링하면 각 고객은 "잘 행동하는" 것처럼 보여도 전체로는 공격처럼 보일 수 있습니다. 폴링은 또한 호출이 곱해지기 쉽습니다(목록 엔드포인트를 호출한 뒤 각 항목의 상세를 가져오는 식), 그래서 예기치 않게 한도에 걸리게 됩니다.

웹훅은 보통 API 호출을 줄이지만 버스트 압력을 만듭니다. 제공자가 중단 후 대량으로 이벤트를 전달하거나, 대량 수입이나 제품 출시로 인해 수천 건의 이벤트를 한꺼번에 보낼 수 있습니다. 일부는 429로 트래픽을 제한하고 일부는 공격적으로 재시도하며, 일부는 엔드포인트가 느리면 이벤트를 버립니다. 당신 쪽은 역압력(backpressure)을 준비해야 합니다: 빠르게 수락하고, 작업을 큐에 넣고, 안전한 속도로 처리하세요.

호환성과 정확성을 잃지 않으면서 호출을 줄이려면 몇 가지 실용 패턴에 집중하세요:

• "updated since" 타임스탬프나 변경 토큰을 이용한 증분 동기화
• 서버 측 필터링(필요한 이벤트 타입만 구독)
• 읽기/쓰기 배치 처리(상세 조회를 청크 단위로, 쓰기도 묶어서)
• 안정적인 참조 데이터 캐싱(플랜, 상태 목록, 사용자 프로필)
• "실시간"과 "리포팅" 요구 분리(빠른 경로 vs 야간 작업)

피크를 미리 계획하세요. 전용 백필 모드를 만들어 느리게 실행하고 쿼터를 존중하며 일시 중지 및 재개가 가능하게 하세요.

올바른 접근법 선택: 간단한 의사결정 가이드

웹훅 vs 폴링 선택은 보통 이렇게 귀결됩니다: 속도가 필요한가, 아니면 공급자가 신뢰할 수 없을 때에도 간단하고 예측 가능한 방식이 필요한가?

제3자가 웹훅을 제공하지 않거나 워크플로가 지연을 허용할 수 있으면 폴링이 기본값으로 더 나은 경우가 많습니다. 또한 API에 명확한 "updated since" 필터가 있고 하루나 시간 단위 동기화만 필요하면 폴링이 이해하기 쉽습니다.

시간이 중요하면 웹훅이 기본값으로 더 낫습니다: "새 주문 수신", "결제 실패", "티켓 할당" 같은 경우입니다. 웹훅은 불필요한 API 호출을 줄이고 즉시 작업을 트리거할 수 있습니다.

정확성이 중요한 경우 실용 규칙은 둘 다 쓰는 것입니다. 웹훅으로 속도를 확보하고 폴링으로 놓친 것을 정리하세요. 예를 들어, 웹훅을 빠르게 처리한 뒤 15분(또는 몇 시간)마다 예약 폴링을 실행해 누락된 이벤트나 일시적 장애로 인한 간극을 확인합니다.

간단 가이드:

• 지연이 몇 분이라도 괜찮다면 폴링으로 시작하세요.
• 몇 초 내에 업데이트가 보여야 한다면 웹훅으로 시작하세요.
• 공급자가 불안정하거나 이벤트가 중요하면 웹훅+폴링을 계획하세요.
• API가 강하게 속도 제한되어 있다면 웹훅과 가벼운 폴링을 선호하세요.
• 데이터 양이 많으면 잦은 전체 폴링을 피하세요.

결정하기 전에 공급자에게 몇 가지 질문을 하고 명확한 답을 받으세요:

• 어떤 이벤트 타입이 있고, 생성/업데이트/삭제가 모두 포함되나?
• 웹훅을 재시도하나, 재시도 기간은 얼마나 되나?
• 이벤트를 재생(replay)하거나 시간 범위별로 이벤트 기록을 가져올 수 있나?
• 웹훅 요청에 서명해 인증을 검증할 수 있나?
• 효율적인 폴링을 위한 "updated since" 쿼리를 지원하나?

단계별: 올바르게 유지되는 동기화 설계하기

"올바른(correct)" 동기화는 단순히 "데이터가 보이는 것"이 아닙니다. 올바른 레코드가 일치하고 최신 변경이 우선하며 문제가 생겼을 때 무엇이 언제 일어났는지 증명할 수 있어야 합니다.

테스트하고 모니터링할 수 있는 계획으로 시작하세요:

1. 진실의 출처(source of truth)와 규칙 정의. 각 필드를 어느 시스템이 소유하는지 정하세요. 예: CRM은 고객 이름을 소유하고 청구 도구는 구독 상태를 소유한다. 무엇이 "충분히 최신"인지(예: "5분 이내")와 허용 가능한 오류를 정하세요.
2. 안정적인 식별자 선택. 서드파티의 고유 ID를 내부 ID 옆에 저장하세요. 이메일이나 이름 같은 변경 가능한 값으로 키를 쓰지 마세요. 가능하면 버전이나 "updated_at" 타임스탬프를 저장해 더 최신 데이터를 감지하세요.
3. 초기 가져오기와 이후 증분 업데이트 계획. 첫 가져오기는 체크포인트를 둔 별도 작업으로 취급해 재개 가능하게 하세요. 그 다음에는 이벤트나 "since" 쿼리 등으로 변경만 처리하고 "마지막 성공 동기화 시간" 같은 커서를 기록하세요.
4. 삭제와 병합은 의도적으로 처리. 삭제 시 레코드를 삭제할지, 보관(archive)할지, 비활성 표시할지 결정하세요. 병합의 경우 어떤 ID가 살아남을지 정하고 감사 로그를 남기세요.
5. 모니터링 신호 설정. 동기화 지연(sync lag), 실패한 호출, 멈춘 큐를 추적하세요. 무언가 충족하지 못할 때(예: 지연 임계값 초과) 경고하도록 하세요.

구현할 때 이런 선택들을 데이터 모델에 가시적으로 남기세요: 외부 ID, 타임스탬프, 상태 필드, 동기화 체크포인트 저장소. 이 구조가 실제 환경이 복잡해져도 동기화를 올바르게 유지하게 합니다.

아이덴포턴시와 순서: 신뢰할 수 있는 통합의 핵심

웹훅과 폴링 통합을 오래 만들다 보면 하나의 규칙이 반복됩니다: 중복, 재시도, 순서 뒤섞임을 보게 됩니다. 동일한 메시지를 안전하게 재처리할 수 없으면 시스템은 시간이 지남에 따라 어긋납니다.

아이덴포턴시(idempotency)는 "같은 입력은 같은 결과"를 의미합니다. 들어오는 모든 이벤트를 "다시 올 수 있다"고 가정하고 처리기를 안전하게 설계하세요. 일반적인 패턴은: 중복 제거 키를 계산하고 이미 처리했는지 확인한 뒤 변경을 적용하는 것입니다.

중복 키에는 트레이드오프가 있습니다. 제공자가 이벤트 ID를 주면 그게 최선입니다. 그렇지 않다면 객체 버전(증가하는 리비전)을 쓰거나, 10분 단위처럼 타임스탬프 윈도우로 반복을 무시하는 것은 늦은 도착 이벤트 때문에 취약합니다.

순서는 다른 절반입니다. 전역적인 정렬은 드물기 때문에 객체별 정렬을 목표로 하세요. 티켓, 청구서, 고객 등 단일 객체에 대한 업데이트는 저장된 것보다 버전이 최신일 때만 적용하세요. 버전이 없다면 최신 updated_at가 승리한다는 명확한 규칙을 쓰고, 시계 오차(clock skew)가 여전히 엣지 케이스를 만들 수 있다는 점을 수용하세요.

복구와 재실행을 추측 없이 할 수 있도록 충분히 저장하세요:

• 객체별 "마지막 본 버전" 또는 updated_at
• 폴링 작업의 마지막 처리된 커서 또는 체크포인트
• 처리된 이벤트 ID 테이블(빠르게 커지면 보존 정책 적용)
• 짧은 기간 동안의 원시 페이로드(raw payload) 저장, 수정 재실행에 사용

예: Stripe 결제 웹훅이 두 번 도착하고, 그 뒤에 "paid" 업데이트가 "created" 이벤트보다 먼저 도착한 경우, 인보이스의 최신 상태 버전을 저장하고 오래된 업데이트는 무시하면 정확한 상태를 유지할 수 있습니다.

묵시적 데이터 이탈을 막는 재시도와 재실행 패턴

대부분의 통합은 조용히 실패합니다. 웹훅이 늦게 도착하거나 폴링 작업이 한도에 걸리거나 앱이 저장 중 타임아웃이 발생할 수 있습니다. 재시도와 재실행 없이는 시스템이 서서히 어긋나 고객 불만으로 드러납니다.

웹훅 재시도: 빠르게 수락하고 안전하게 처리하세요

제공자는 보통 당신이 빠르게 성공(2xx) 코드를 반환하지 않으면 재시도합니다. 웹훅 요청을 무거운 작업을 하는 장소로 보지 말고 전달 알림(delivery notification)으로 취급하세요.

실용적인 웹훅 패턴:

• 기본 검증(서명, 스키마, 타임스탬프) 후 빠르게 2xx로 응답하세요.
• 고유 ID로 이벤트를 저장하고 상태를 보류(pending)로 표시하세요.
• 워커에서 비동기 처리하고 시도 횟수를 추적하세요.
• 일시적 오류는 나중에 재시도하고, 영구 오류는 중단하고 알림을 보냅니다.
• 잘못된 데이터는 4xx로, 실제 서버 문제만 5xx로 응답하세요.

이 접근은 흔한 함정을 피합니다: "웹훅을 받았다"가 곧 "데이터가 동기화되었다"는 착각입니다.

폴링 재시도: API에 공손하게 행동하세요

폴링은 다른 방식으로 실패합니다. 짧은 중단 후 모든 클라이언트가 재시도하면 한꺼번에 몰려들어 한도를 악화시킵니다. 지수 백오프(exponential backoff)와 지터(jitter)를 사용하고, 전체를 다시 스캔하지 않도록 "since" 커서를 유지하세요.

지금 처리할 수 없는 항목은 데드레터 큐(또는 테이블)에 넣어 원인을 기록하세요. 그러면 무엇이 손실되었는지 추측하지 않고 안전하게 검사하고 재실행할 수 있습니다.

재실행은 놓친 이벤트를 치유하는 방법입니다. 간단한 재실행 전략:

• 시간 창(예: 지난 24시간)이나 영향받은 레코드 집합을 선택합니다.
• 제공자로부터 현재 상태를 다시 가져옵니다.
• 다시 적용할 때는 아이덴포턴시를 지켜 불일치를 수정합니다.
• 무엇이 왜 변경되었는지 기록합니다.

예: 청구 제공자의 "invoice.paid" 웹훅이 왔지만 데이터베이스가 30초 동안 락되어 있었다면 해당 이벤트를 데드레터에 넣고, 인보이스와 결제 상태를 다시 가져와 레코드를 갱신하면 됩니다.

자주 하는 실수와 회피 방법

대부분의 동기화 버그는 "큰 아키텍처" 문제가 아닙니다. 작은 가정들이 쌓여 조용한 이탈, 중복 레코드, 또는 누락 업데이트를 만듭니다.

자주 보이는 실수들:

• 증분 필터 없이 너무 잦은 폴링. 커서(updated_at, 이벤트 ID, 페이지 토큰)를 추적하고 마지막 성공 실행 이후의 변경만 요청하세요.
• 웹훅을 보장된 전달로 취급. 최근 이력(예: 지난 24-72시간)을 재확인하는 백필 작업을 유지하세요.
• 중복을 무시. 모든 쓰기는 아이덴포턴트하게 만드세요. 제공자 이벤트 ID(또는 안정적인 외부 ID)를 저장하고 동일 변경을 두 번 적용하지 마세요.
• 검증 없이 웹훅 수용. 제공자가 제공하는 서명 토큰이나 검증 방법을 검증하세요.
• 동기화 상태를 모니터링하지 않음. 지연, 백로그 크기, 마지막 성공 실행 시간, 오류율을 추적하세요. 지연이 임계값을 넘으면 경고를 보내세요.

많은 "웹훅 vs 폴링" 논쟁은 잘못된 포인트를 봅니다: 신뢰성은 어느 방법 주변에 놓인 안전장치에서 옵니다. 결제 웹훅이 두 번 오거나 늦게 오면, 웹훅만으로 레코드를 직접 만들고 아이덴포턴시를 고려하지 않으면 고객에게 메시지를 두 번 보내거나 과금할 수 있습니다.

건강한 통합을 위한 빠른 점검표

일상 점검 항목은 웹훅이든 폴링이든 비슷합니다. 데이터가 최신인지, 오류가 쌓이고 있는지, 그리고 깔끔하게 복구할 수 있는지를 알고 싶습니다.

몇 분 안에 할 수 있는 빠른 체크리스트:

• 최신성: "마지막 이벤트 수신" 또는 "마지막 폴 완료"를 기대 지연과 비교하세요.
• 실패: 재시도가 계속 증가하거나 오랫동안 움직이지 않는 작업이 없는지 확인하세요. 오류 수와 "마지막 성공" 타임스탬프를 쌍으로 보세요.
• 쿼터: 사용한 API 호출 수와 남은 호출 수를 확인하세요. 한도에 가깝다면 폴링을 늦추고 요청을 배치하세요.
• 정확성: 시스템 간 합계를 샘플링(예: "오늘 주문 수")하고 최근 레코드 몇 건을 점검하세요.
• 복구 준비성: 중복이나 누락 없이 최근 창을 안전하게 재처리할 수 있는지 확인하세요.

유용한 습관은 바쁜 기간을 통제된 방식으로 주기적으로 재실행하여 결과가 프로덕션과 일치하는지 확인하는 것입니다.

예시: 현실적인 워크플로를 위해 웹훅과 폴링 혼합하기

소규모 SaaS 팀이 CRM(연락처와 딜), Stripe 결제(청구와 환불), 지원 도구(티켓 상태) 세 시스템을 동기화해야 한다고 가정해 보세요.

이들은 빠른 반응이 필요한 항목에 대해 웹훅 우선 설정을 사용합니다. CRM 이벤트는 고객 레코드를 갱신하고 내부 작업을 트리거합니다. Stripe 웹훅은 인보이스를 생성하고 결제 후 기능을 잠금 해제하며 실패한 결제 시 계정을 연체로 표시합니다. 지원 도구는 가능하면 웹훅을 사용하지만, 티켓 상태가 대량으로 변경될 수 있으므로 예약 폴링도 유지합니다.

그들은 폴링을 메인 엔진이 아닌 안전망으로 취급합니다. 매일 밤 정합 작업이 지난 24시간의 변경을 끌어와 앱에 저장된 것과 비교합니다.

현실에서 장애가 발생해 웹훅 엔드포인트가 배포 중 20분간 다운되었습니다.

• CRM과 Stripe는 일정 기간 재시도합니다.
• 일부 이벤트는 늦게 도착하고 일부는 순서가 바뀌며 일부는 만료될 수 있습니다.
• 정합 폴링은 간극(누락된 이벤트 ID나 불일치 합계)을 감지하고 누락된 변경을 백필합니다.

그들이 로그에 남기는 항목: 수신한 이벤트 ID, 제공자 타임스탬프, 내부 레코드 ID, 최종 결과(생성, 업데이트, 무시). 경고를 트리거하는 조건: 반복되는 웹훅 실패, 재시도 급증, 또는 정합에서 작은 임계값 이상의 누락 발견 등입니다.

다음 단계: 구현하고, 모니터링하고, 반복하세요

대부분의 팀에 대한 실용적인 기본은 단순합니다: 즉시성을 위해 웹훅을 사용하고 정합을 위해 작은 폴링 작업을 유지하세요. 웹훅은 변경을 빠르게 전달하고, 폴링은 장애나 잘못된 구독, 제공자가 가끔 이벤트를 놓칠 때 놓친 부분을 보완합니다.

먼저 빠르게 만들기보다 올바르게 만드는 것을 우선하세요. 들어오는 모든 변경을 여러 번 안전하게 적용할 수 있게 처리하세요.

처음 할 세 가지 작업:

• 공급자의 이벤트와 필드를 내부 모델에 매핑하고, "삭제", "환불", "상태 변경"이 당신에게 무엇을 의미하는지 정의하세요.
• 처음부터 아이덴포턴시를 설계하세요: 외부 이벤트 ID나 버전을 저장하고 각 업데이트를 중복 재실행해도 문제가 없게 만드세요.
• 의도적인 재실행을 추가하세요: "마지막으로 본 이후" 커서나 시간 창 폴링을 유지하고, 문제가 생기면 범위를 다시 실행할 수 있는 관리자 도구를 만드세요.

실행 후에는 모니터링이 계속 작동하게 합니다. 웹훅 전달률, 원인별 실패(타임아웃, 4xx, 5xx), 정합 폴이 얼마나 뒤처져 있는지 추적하세요. "이벤트가 전혀 수신되지 않음"과 "이벤트가 너무 많이 수신됨" 모두 경고하도록 하세요.

만약 처음부터 완전한 백엔드를 직접 작성하지 않고 시각적 도구로 빠르게 만들고 싶다면, AppMaster (appmaster.io)는 데이터 모델링, 웹훅 엔드포인트 생성, 재시도/재실행 흐름을 시각적으로 디자인할 수 있는 노코드 옵션입니다. 필요할 때 실제 소스 코드를 생성해 배포도 가능합니다.