API Key 노출 이슈와 BFF 아키텍처로의 발전
레거시 PHP 환경으로 구성된 리조트 웹사이트에 React를 부분 도입하는 프로젝트를 진행했습니다. 예약과 결제 등 사용자 인터랙션이 많은 구간의 UX를 동적으로 개선하는 성공적인 작업이었지만, 그 과정에서 SPA 생태계에 대한 이해 부족으로 아찔한 실수를 경험했습니다.
이 글은 브라우저 네트워크 탭에 API Key를 노출했던 부끄러운 실수와, 이를 수습하며 깨달은 아키텍처적 인사이트에 대한 기록입니다.
The Problem: 보이지 않던 것이 보이기 시작했다
서버 중심 사고의 함정 PHP 시절에는 모든 데이터 Fetching과 렌더링이 서버에서 이루어졌습니다. 외부 API를 호출할 때 사용하는 Secret Key나 인증 헤더는 서버 내부에 안전하게 감춰져 있었죠.
하지만 React를 도입하면서, 저는 컴포넌트 마운트 시점에 프론트엔드에서 직접 파트너사의 외부 API를 호출하도록 로직을 작성했습니다. 기능은 완벽하게 동작했지만, 개발자 도구의 네트워크 탭을 열어본 순간 아차 싶었습니다. Request Header에 외부 API 통신을 위한 인증 키가 고스란히 노출 되고 있었기 때문입니다. 클라이언트 코드는 누구에게나 공개된다는 SPA의 가장 기본적인 특성을 간과한 결과였습니다.
The Solution: PHP Proxy 서버를 통한 긴급 우회
보안 취약점을 확인한 즉시 핫픽스 작업에 들어갔습니다. 해결책은 단순했습니다. 브라우저가 외부 API를 직접 찌르지 못하게 막고, 우리 서버를 한 번 거쳐 가도록 우회로를 뚫는 것이었습니다.
- PHP Proxy 계층 생성: 클라이언트의 요청을 받아 외부 API로 전달만 해주는 간단한 PHP 파일을 구축했습니다.
- 인증 정보의 서버 사이드 은닉: API Key와 Secret 값은 PHP 서버의 환경 변수로 숨기고, React는 오직 우리 내부 서버의 Proxy 엔드포인트만 호출하도록 변경했습니다.
이 긴급 조치를 통해 클라이언트 단에서 API Key가 노출되는 보안 이슈는 즉시 해결할 수 있었습니다.
The Result & Retrospective: Proxy를 넘어 BFF(Backend For Frontend)로
급하게 불은 껐지만, 단순히 요청을 '전달'만 하는 현재의 프록시 구조는 백엔드 개발자로서 묘한 찝찝함을 남겼습니다. 이 시행착오를 통해 저는 SPA 아키텍처에서 백엔드의 역할이 어떻게 변해야 하는지 깊이 깨달았습니다.
다음 프로젝트에서 동일한 요구사항을 마주한다면, 단순 프록시가 아닌 BFF(Backend For Frontend) 패턴을 정식으로 도입할 것입니다.
- 보안 통제: 모든 외부 통신은 서버가 전담하여 클라이언트에는 어떠한 민감 정보도 내리지 않습니다.
- 데이터 정제: 외부 API의 방대한 응답 데이터 중 프론트엔드 화면(UI/UX)에 필요한 데이터만 서버에서 조립하고 가공하여 전달합니다.
- 통신 횟수 최적화: 프론트엔드가 여러 번 API를 호출해야 하는 상황을, BFF 서버에서 취합하여 단일 응답으로 내려줍니다.
단순한 실수였지만, 이 경험은 저를 '기능만 구현하는 개발자'에서 '클라이언트와 서버 사이의 안전하고 효율적인 계약을 설계하는 아키텍트' 로 한 단계 성장시켜 주었습니다.