인프런 커뮤니티 질문&답변
작성한 질문수
외부 API 통합 시 데이터 제어 범위 설계 질문
작성
·
8
0
상황 정리
저희가 매장 관리자용 통합 예약 관리 시스템을 개발하고 있습니다.
현재 시스템 구조
[외부 예약 플랫폼 (네이버 같은)]
↓ 자동 연동
[매장 POS 시스템 (티오더 같은)]
↓ API 폴링
[우리 통합 관리 시스템]
고객이 외부 플랫폼에서 예약하면 POS에 자동으로 들어옴
우리는 POS API를 폴링해서 예약 데이터를 가져옴
우리 어드민에서 직접 예약 등록 기능도 곧 추가 예정
문제 상황
POS 업체에 확인해보니:
API에서 외부 플랫폼 예약 구분이 안 됨 → 구분값 추가 예정
외부 예약은 원칙적으로 수정 불가
현재는 수정이 되지만 플랫폼 API 키가 연결 안 되어 사실상 불가능
DB만 바꿔서는 의미 없고, 외부 플랫폼 API 재호출이 필요
POS와 외부 플랫폼 간 연동이 아직 불완전한 상태
논의된 두 가지 방향
A안 (readonly 방식)
- 우리 어드민 생성 예약 → POS 직접 등록 (수정 가능)
- 외부 플랫폼 예약 → POS에서 폴링해서 조회만 (수정 불가)
- UI에서 "외부 예약" 표시하고 수정 버튼 비활성화
- 수정 필요시 원본 플랫폼 바로가기 링크 제공
B안 (통합 수정 방식)
- 모든 예약을 우리 시스템에서 직접 수정 가능하게
- 외부 예약 수정 시 POS API → 외부 플랫폼 API 호출까지 처리
장단점 분석
A안 장점
각 시스템의 책임 범위가 명확함
동기화 정합성 이슈 없음
외부 플랫폼 정책 변경에 영향 안 받음
여러 플랫폼을 한 곳에서 조회만 해도 관리자 리소스 절감 효과
A안 단점
수정은 여전히 각 플랫폼에서 해야 함
"진정한 통합 관리"는 아님
B안 장점
완전한 통합 관리 경험
관리자가 한 곳에서 모든 예약 제어
B안 단점
외부 플랫폼 API 직접 연동 불가 (계약 주체가 매장)
POS가 외부 플랫폼 제어 API를 제공해야 하는데 현재 없음
POS-외부 플랫폼 양쪽 동기화 복잡도 높음
외부 플랫폼 정책(취소규칙 등) 변경 시 계속 대응 필요
문제 발생 시 책임 소재 애매
질문
이런 다중 오리진 데이터를 통합하는 시스템에서:
readonly로 가는 게 맞을까요, 아니면 수정까지 구현해야 할까요?
단계적으로 접근한다면 어떤 순서가 좋을까요?
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 역할을 하게 하는 게 나을까요?
답변
