grep

Design

여기쏙 — Figma plugin 제작기 : 1. 프록시 서버

임수빈Melody(멜로디) / 서비스웹개발팀여기어때

2025년 12월 9일

원문에서 보기 ↗

시작하며

안녕하세요, 서비스웹개발팀의 멜로디입니다! 오늘은 디자이너의 생산성을 높여주는 Figma 플러그인 이야기를 해보려 합니다. Figma는 화면을 제작하는 디자이너와 이를 구현하는 프론트엔드 개발자 사이에서 이미 필수 협업 도구로 자리 잡았는데요. 저희 팀은 여기어때의 다양한 디자인 시안을 더 빠르고 정확하게 구현 하기 위해 ‘여기쏙’이라는 Figma 플러그인을 직접 개발했습니다. 이번 글에서는 여기쏙을 개발하며 마주했던 여러 문제들, 그리고 그것들을 해결하기 위해 어떤 방식으로 접근하고 개선해 나갔는지 공유해보려고 합니다. 이 글이 저와 같은 고민을 가진 분들께 Figma 플러그인 개발의 실전 경험과 작은 인사이트가 되기를 바랍니다.

합류하게 된 이야기

지난 여름, 여기어때 X 배달의민족 생산성 워크샵 이 열렸고 평소 관심 있던 키워드인 ‘UX’와 ‘생산성’이 모두 겹치는 자리라 주저 없이 참여 의사를 밝혔어요. 운 좋게도 참여할 수 있었고요. 워크샵이 끝난 뒤, 사내 생산성 프로젝트 중 하나였던 여기쏙 업데이트 계획을 들을 기회가 있었어요. UI/UX 개선, 워크플로우 자동화, 생산성 향상… 제가 평소 좋아하던 영역이 모두 들어있는 프로젝트라 “아, 이거다!” 싶었고, 바로 참여를 자원하게 되었습니다.

비효율적인 디자인 프로세스 : 여기쏙의 시작

디자이너가 디자인 리뷰나 사용자 테스트(UT)를 준비할 때 실제 서비스의 데이터를 하나하나 디자인에 채워 넣는 작업 은 꽤나 번거로운 일이죠. 숙소 이미지, 가격, 리뷰, 혜택, 위치 정보처럼 여기어때의 상품카드는 들어가는 정보가 많다 보니, 매번 최신 데이터를 찾아 넣고 정리하는 데 시간이 많이 든다고 해요. “이걸 자동으로 넣어주는 플러그인이 있으면 얼마나 편할까?” 라는 의견이 자연스럽게 나왔고 그렇게 작년에 여기쏙 1.0이 제작되었어요.

하지만 여기쏙 1.0은 더미 데이터를 기반으로 동작했기 때문에 여러 문제가 있었어요.

여기쏙 1.0 에서 가장 개선하고 싶었던 것은..

기존에 셀러카드, 아이템카드에 한정된 기능만 제공했어요.

실제 API와 구조가 달라 디자인 결과물이 서비스 화면과 불일치하고 데이터가 오래되다 보니 리뷰 수나 가격이 현실과 맞지 않거나, 서비스에 새로운 정책·요소가 추가되어도 플러그인은 업데이트되지 않아 디자인 검증에 오류가 생겼습니다. 결국 디자이너 입장에서는“실제 서비스와 다르게 보이는 디자인을 검증할 수 없다”는 문제로 이어졌고, 이 때문에 여기쏙 1.0의 사용 빈도는 시간이 갈수록 줄어들게 되었어요.

페이지 단위로 확장해 카테고리와 필터를 분리하고, 플러그인 안에서 직접 ‘실제 여기어때 API’를 호출해 실데이터 기반으로 UI를 검증하는 방식 , 즉 실제 서비스와 1:1로 연결된 디자인 워크플로우로 전환해 보자는 의견이 나왔어요. 그리고 이것이 바로 여기쏙 2.0 버전의 시작이 되었죠.

Figma 플러그인에서 데이터 호출시 나타난 문제들

아이디어와 기획이 어느 정도 자리 잡고, 이제 구현만 하면 되겠다 싶었는데… 생각보다 큰 장애물이 앞을 가로막고 있었어요.

  1. CORS 에러 발생 Figma 플러그인에서 여기어때 Gateway API를 직접 호출해 보면 브라우저 콘솔에 CORS 에러가 뜹니다. 요청이 막혀서 응답조차 받을 수 없는 상황이죠.

CORS(Cross-Origin Resource Sharing)란?
  브라우저가 다른 도메인의 리소스를 요청할 때 적용되는 보안 정책입니다.
  다음 조건이 하나라도 만족하지 않으면 요청이 차단됩니다.
  - 서버가 “이 도메인에서 오는 요청을 허용한다”고 명시하지 않았거나
  - 커스텀 헤더 / 인증정보를 함께 보내는 요청인데 서버가 이를 허용하지 않거나
  - Preflight(OPTIONS) 요청에서 허용 응답을 보내지 않은 경우

그렇다면 왜 Figma 플러그인에서 CORS가 발생했을까요?

Figma 플러그인의 UI 영역은 브라우저 WebView 환경에서 실행됩니다. 즉, Figma 밖으로 나가는 모든 네트워크 요청은 브라우저 요청과 동일하게 취급됩니다. 그런데, 여기어때 Gateway API는 외부 웹에서 접근하도록 CORS 허용을 하지 않았습니다.

- 도메인 허용 목록에 Figma 플러그인 출처가 없음
- Authorization/Cookie 같은 민감 정보가 첨부될 위험이 있음
- Gateway는 내부 서비스용이기 때문에 외부에서 직접 호출하도록 설계되지 않음

그래서 Figma에서 API를 직접 호출하면 무조건 CORS에 막히게 되는 거죠.

2. HTTPS만 허용하는 Figma 플러그인

Figma에서 서버를 호출하기 위해서는 manifest.json에 allowDomains에 url 등록을 하는데, HTTP 주소를 기재하면 위와 같은 에러가 떠요. HTTPS 만 가능하기에 나온 에러였어요.

HTTP vs HTTPS

- HTTP (HyperText Transfer Protocol)
암호화 없음 (평문 전송)
누군가 네트워크를 중간에서 엿보면요청/응답 내용을 그대로 볼 수 있음
민감한 데이터를 다루면 매우 위험
요즘 서비스에서는 거의 사용하지 않음

- HTTPS (HTTP + SSL/TLS)
SSL/TLS 암호화 적용
요청/응답이 모두 암호화되어 노출 위험 없음
실제 서비스(로그인, 결제, API)는 거의 100% HTTPS
인증서가 필요하기 때문에 도메인이 꼭 있어야 함
Figma 플러그인도 HTTPS만 허용

이와 같은 이유들로 피그마에서 여기어때 API를 호출하기 위해서는 HTTPS + CORS 허용 + 외부 접근 가능한 구조를 만들어야 했어요. 프록시 서버를 만들어서 피그마와 여기어때 GATEWAY가 통신하게 해야했어요.

빠른 실행을 위해 기존 인프라를 활용

HTTPS로 외부에서 접근 가능한 프록시 서버를 만들기 위해서는 결국 어디선가 그 서버가 실제로 떠 있어야 해요.즉, 프록시를 호스팅할 EC2 인스턴스(서버 한 대)가 필요하죠. 하지만 사내에서 새 인스턴스를 받으려면 보안 검토, 네트워크 구성, 비용 승인 등이 포함된 아키텍처 리뷰 → 기안 → SRE 승인까지 요구되는 꽤 무거운 절차를 거쳐야 했어요. 단순히 CORS 처리를 위한 작은 프록시 하나를 위해 전체 인프라 절차를 열기에는 부담이 컸어요.

기존 CMS 인스턴스에 새 포트를 개방하고 Docker로 프록시 컨테이너를 함께 띄우는 방식을 택했어요. 이 방식은 기존 인프라(보안 그룹, VPC, 로드밸런서)를 그대로 재사용할 수 있어 추가 승인 절차 없이 프록시를 바로 운영할 수 있는 가장 현실적인 선택이었어요.

SRE팀과 함께 구성한 최종 인프라

프록시 서버는 회사 내부망에 두되, 외부(Figma 플러그인)에서도 안전하게 접근할 수 있어야 했어요. 이를 위해 SRE팀과 함께 아래와 같은 구조로 인프라를 정리했습니다.

중간에는 ECR 권한 문제로 Access Key를 발급받으려다 보안 정책에 걸리고,CodeDeploy에서 로드밸런서를 붙여야 하는지 아닌지 혼란이 오기도 했지만, 최종적으로는 Docker Build → ECR → CodeDeploy → ALB → EC2 이 순서로 안정적인 배포 흐름을 완성할 수 있었어요.

안전한 Proxy Server 구조 설계

Figma 플러그인에서 내부 API에 접근해야 했지만, 외부 요청을 직접 허용하는 것은 보안적으로 위험했어요.

그래서 프록시 서버 자체에 여러 보안·안정성 정책을 넣어 게스트 전용 읽기 전용 구조로 설계했습니다.

1. 게스트 전용 구조

프록시에서 인증을 운영하면 보안 리스크가 커지기 때문에 로그인, 세션, 쿠키 없이 누구나 동일한 권한으로 접근하는 게스트 구조를 택했어요. 즉, 플러그인에서 필요한 데이터만 제공하고 어떤 형태의 “사용자 정보 연동”도 하지 않는 완전한 게스트 모드로 만들어 프록시 사용 자체의 위험도를 최대한 낮췄어요.

2. GET-only 읽기 전용 정책

플러그인이 필요한 작업은 “데이터 조회(READ)” 뿐이었기 때문에 프록시 서버는 아예 GET만 허용하도록 설계했어요. 플러그인이 CRUD를 모두 다룰 필요는 없으므로, “읽기 전용 API Proxy” 형태로 위험도를 아주 낮춘 구조입니다.

3. 서비스 라우팅 단순화

내부 API가 굉장히 많기 때문에, 프록시에서 마음대로 모든 API를 호출할 수 있게 두면 위험해요. 그래서 아예 허용된 서비스만 지정해서 호출 가능하게 만들었습니다. 덕분에 프록시가 “전체 내부 API의 통로”가 되는 위험을 막을 수 있었어요.

4. 응답 최소화 및 보안 정책

응답을 그대로 외부로 전달하면 내부 시스템 정보가 노출될 수 있기 때문에 프록시에서 응답을 가공해 최소화했습니다. 즉, 프록시는 내부 시스템을 외부에 그대로 드러내는 관문이 아니라 철저히 정제된 데이터만 전달하는 필터 역할을 하도록 만들었어요.

5. Docker 기반 배포 구조

프록시 서버는 NestJS 기반으로 개발했으며, 운영 환경과 동일한 이미지를 유지하기 위해 Dockerize했어요. 덕분에 새로운 서버 생성 없이도 안정적으로 프록시를 운영할 수 있었고, 기존 모니터링·배포 체계를 그대로 활용할 수 있었어요.

결국 이 프록시의 목적은 “내부 API를 외부에 안전하게 노출하되, 아무것도 새로 만들지 않고, 최소 권한으로, 읽기 전용으로 제공하는 것”이었어요.

이 5가지 원칙을 기반으로 안전한 Figma 플러그인용 프록시 서버를 설계하고 운영할 수 있었습니다.

팀과 함께 맞춰간 기술 이해

프록시 서버를 구축하면서 평소 프론트 개발자에게 익숙하지 않은 영역을 다루다 보니 팀원들과 지식을 함께 맞춰가는 과정도 필요했어요. 그래서 테크 미팅시간을 통해 ‘Express vs NestJS’, ‘Docker 기본 구조’, ‘여기어때 서비스별 배포 흐름’, ‘CodeDeploy 구조’ 같은 내용을 정리해 공유했어요.

실제로 우리팀이 가지고 있는 다양한 서비스들의 서버 구성과 배포 방식이 각각 다른데, 그 부분을 함께 이해하며 논의할 수 있는 시간도 가질 수 있어서 매우 좋았어요.

프록시를 개발하면서..

인프라 구성부터 프록시 서버 구축까지, 평소 프론트엔드 개발 업무에서는 직접 다룰 일이 많지 않은 영역들이지만이번 기회에 하나하나 깊게 파고들며 실전으로 경험할 수 있었어요. HTTPS, CORS, ALB, Docker, ECR, CodeDeploy 등 서비스를 실제로 외부에 안전하게 연결시키기 위해 필요한 개념들을 직접 설계하고 구성해보며 확실히 이해할 수 있었습니다.

여기까지가 프록시 서버 구축기의 전부예요. 여러 시행착오 끝에 안정적으로 동작하는 구조를 만들 수 있었고, 덕분에 여기쏙 2.0을 본격적으로 개발할 수 있는 기반이 완전히 갖춰졌습니다. 다음 편에서는 이 프록시를 기반으로 플러그인 기능이 어떻게 구현됐는지 풀어볼게요!