외부 API 통합 시 데이터 제어 범위 설계 질문

상황 정리

저희가 매장 관리자용 통합 예약 관리 시스템을 개발하고 있습니다.

현재 시스템 구조

[외부 예약 플랫폼 (네이버 같은)]
         ↓ 자동 연동
[매장 POS 시스템 (티오더 같은)]
         ↓ API 폴링
[우리 통합 관리 시스템]

• 고객이 외부 플랫폼에서 예약하면 POS에 자동으로 들어옴

• 우리는 POS API를 폴링해서 예약 데이터를 가져옴

• 우리 어드민에서 직접 예약 등록 기능도 곧 추가 예정

문제 상황

POS 업체에 확인해보니:

1. API에서 외부 플랫폼 예약 구분이 안 됨 → 구분값 추가 예정

2. 외부 예약은 원칙적으로 수정 불가

   • 현재는 수정이 되지만 플랫폼 API 키가 연결 안 되어 사실상 불가능

   • DB만 바꿔서는 의미 없고, 외부 플랫폼 API 재호출이 필요

3. POS와 외부 플랫폼 간 연동이 아직 불완전한 상태

논의된 두 가지 방향

A안 (readonly 방식)

- 우리 어드민 생성 예약 → POS 직접 등록 (수정 가능)
- 외부 플랫폼 예약 → POS에서 폴링해서 조회만 (수정 불가)
- UI에서 "외부 예약" 표시하고 수정 버튼 비활성화
- 수정 필요시 원본 플랫폼 바로가기 링크 제공

B안 (통합 수정 방식)

- 모든 예약을 우리 시스템에서 직접 수정 가능하게
- 외부 예약 수정 시 POS API → 외부 플랫폼 API 호출까지 처리

장단점 분석

A안 장점

• 각 시스템의 책임 범위가 명확함

• 동기화 정합성 이슈 없음

• 외부 플랫폼 정책 변경에 영향 안 받음

• 여러 플랫폼을 한 곳에서 조회만 해도 관리자 리소스 절감 효과

A안 단점

• 수정은 여전히 각 플랫폼에서 해야 함

• "진정한 통합 관리"는 아님

B안 장점

• 완전한 통합 관리 경험

• 관리자가 한 곳에서 모든 예약 제어

B안 단점

• 외부 플랫폼 API 직접 연동 불가 (계약 주체가 매장)

• POS가 외부 플랫폼 제어 API를 제공해야 하는데 현재 없음

• POS-외부 플랫폼 양쪽 동기화 복잡도 높음

• 외부 플랫폼 정책(취소규칙 등) 변경 시 계속 대응 필요

• 문제 발생 시 책임 소재 애매

질문

이런 다중 오리진 데이터를 통합하는 시스템에서:

1. readonly로 가는 게 맞을까요, 아니면 수정까지 구현해야 할까요?

2. 단계적으로 접근한다면 어떤 순서가 좋을까요?

   • 1단계: 통합 조회만

   • 2단계: POS가 API 제공하면 그때 수정 추가

비슷한 사례에서 일반적으로 어떻게 접근하나요?

현재 상황에서는 A안(readonly)이 합리적이라고 판단됩니다.

하지만 시간이 지나서 다음 조건들이 충족된다면:

• POS에서 외부 예약 플랫폼 식별값을 제공

• 외부 예약 플랫폼 API를 저희가 제공받을 수 있음

그때는 어떤 아키텍처로 가야 할까요?

옵션 1: 직접 호출 방식

[우리 시스템] → [외부 플랫폼 API] (직접 호출)
             → [POS API] (동기화용)

• 우리가 외부 플랫폼 API를 직접 호출

• POS는 조회 + 동기화 확인용으로만 사용

옵션 2: POS Proxy 방식

[우리 시스템] → [POS API] → [외부 플랫폼 API]

• POS가 외부 플랫폼 제어 API를 제공하도록 요청

• 우리는 POS API만 호출하면 POS가 내부적으로 플랫폼 API 처리

• 외부 플랫폼 변경사항은 POS가 책임

옵션 3: readonly 유지

[우리 시스템] → [POS API] (조회만)

• 기술적으로 가능해져도 readonly 유지

• 각 플랫폼 바로가기만 제공

어떤 방식이 일반적이고, 각 옵션의 trade-off는 무엇인가요?

특히 옵션 1 vs 옵션 2에서:

• 우리가 직접 여러 외부 API를 관리하는 게 나을까요?

• 아니면 POS가 Proxy/Gateway 역할을 하게 하는 게 나을까요?