프록시가 뭔가요: 중간에 서버 하나 두는 이유

중간에 한 칸을 넣는 것이 전부입니다.

프록시는 중간에 서는 서버입니다. 내 화면이 외부 서비스를 직접 부르지 않고, 그 사이에 서버를 하나 두는 것입니다. 말은 어려워 보이지만 구조는 단순합니다.

왜 중간에 두나

가장 흔한 이유가 비밀을 감추는 것입니다.

웹페이지에서 외부 서비스를 부르려면 인증키가 필요한 경우가 많습니다. 그런데 웹페이지의 코드는 방문자에게 그대로 내려갑니다. 소스 보기만 눌러도 보입니다. 변수 이름을 바꿔도 소용없습니다. 결국 브라우저가 그 키로 요청을 보내야 하니까요.

중간에 서버를 두면 달라집니다. 키는 그 서버에만 있고, 브라우저는 서버만 부릅니다.

요청이 한 번 더 거쳐 갑니다.

덤으로 따라오는 것

중간에 자리가 생기니 할 수 있는 일이 몇 가지 늘어납니다.

• 결과를 저장해 둘 수 있습니다. 같은 요청이 여러 번 오면 저장해 둔 값을 바로 줍니다. 원본 서비스를 매번 부르지 않아도 됩니다.
• 여러 번 나눠 받는 걸 한 번으로 만들 수 있습니다. 서버가 대신 여러 번 부르고, 브라우저에는 합쳐서 한 번만 줍니다.
• 형태를 바꿔 줄 수 있습니다. 필요 없는 항목을 빼고 보내면 전송량이 줄어듭니다.

공짜로 만들 수 있나

서버를 빌려야 한다고 생각하기 쉬운데, 개인 규모라면 무료로 되는 방법이 있습니다. 구글 앱스 스크립트가 그중 하나입니다. 웹앱으로 배포하면 주소가 하나 나오고, 그게 곧 프록시가 됩니다.

// 프록시가 하는 일의 핵심은 이 정도입니다function doGet(e) {  var key  = 저장해둔_키_꺼내기();  var data = 외부서비스_호출(key);   // 키는 여기서만 쓰인다  return JSON으로_돌려주기(data);    // 브라우저는 결과만 받는다}

가려지는 것과 안 가려지는 것이 있습니다.

가려지지 않는 것

오해하기 쉬운 부분입니다. 프록시 주소 자체는 공개됩니다. 브라우저가 그 주소를 불러야 하니 당연합니다.

즉 키는 가려지지만 “누구나 그 주소를 부를 수 있다”는 건 그대로입니다. 그래서 규모가 커지면 호출 횟수를 제한하거나, 어디서 온 요청인지 확인하는 조건을 붙이게 됩니다.

느려지지 않나

한 번 더 거치니 이론상 느려집니다. 다만 결과를 저장해 두면 오히려 빨라지는 경우가 많습니다. 원본을 매번 부르는 것보다 저장된 값을 주는 게 빠르기 때문입니다.

정리

프록시는 특별한 기술이 아니라 “직접 부르지 말고 내 서버를 거쳐라”는 배치입니다. 이렇게 생각하면 어디에 쓸 수 있을지 감이 잡힙니다.

한 번 더 확인할 기준

프록시는 숨겨 주는 장치라고만 생각하기 쉽지만, 실제 역할은 요청을 대신 전달하면서 규칙을 한곳에 모으는 데 있습니다. 캐시, 접속 기록, 접근 제한, 형식 변환처럼 서비스마다 흩어질 일을 앞단에서 처리할 수 있습니다.

확인할 것	왜 보는가	바로 해 볼 일
출처와 날짜	같은 말도 기준 시점이 다르면 뜻이 달라집니다.	원문과 마지막 갱신일을 함께 적습니다.
내 작업과의 거리	일반적인 설명이 내 상황에 그대로 맞지는 않습니다.	작은 예시 하나로 먼저 시험합니다.
되돌릴 방법	편리한 선택도 실수하면 비용이 생깁니다.	원본·설정·결과를 구분해 둡니다.

이 경우에는 이렇게 판단한다

다만 프록시를 둔다고 원래 서버의 보안 책임이 사라지지는 않습니다. 암호화 연결을 끝내는 위치, 실제 접속자의 주소를 어떻게 넘기는지, 오류가 났을 때 어느 구간에서 멈췄는지를 정해야 원인 추적이 가능합니다.

작게 해 보는 예시

처음부터 중요한 일을 맡기지 않는 편이 좋습니다. 예를 들어 새 기능이나 자료를 발견했다면, 실제 결과를 바꾸지 않는 샘플 하나로 시작합니다. 입력은 짧게 정하고, 기대한 결과와 실제 결과를 나란히 적습니다. 여기서 차이가 나면 도구가 틀렸다기보다 내가 세운 조건이 모호했을 가능성도 같이 살펴볼 수 있습니다.

그다음에는 예외 하나를 일부러 넣어 봅니다. 빈칸, 오래된 날짜, 예상과 다른 형식처럼 현실에서 자주 만나는 조건입니다. 정상적인 경우만 통과한 방법은 다음 단계에서 쉽게 흔들립니다. 반대로 예외를 어떻게 처리할지 정해 두면, 나중에 문제가 생겼을 때 다시 처음부터 찾지 않아도 됩니다.

기록을 남기면 달라지는 점

새 방법을 쓴 날에는 “무엇을 넣었고 무엇이 나왔는지”를 두세 줄로 남겨 보세요. 다음에 결과가 달라져도 기억에 기대지 않고 비교할 수 있습니다. 특히 외부 자료나 서비스의 정책이 바뀌는 일은 눈에 잘 띄지 않습니다. 같은 입력을 다시 확인할 수 있는 작은 기록이 있으면, 변화가 도구 때문인지 내 조건 때문인지 구분하기 쉬워집니다.

이 기록은 긴 보고서일 필요가 없습니다. 날짜, 사용한 자료의 제목 또는 버전, 기대한 결과, 실제 결과, 다음에 고칠 한 가지면 충분합니다. 잘된 결과만 적기보다 애매했던 사례를 남겨 두는 쪽이 나중에 더 큰 도움이 됩니다. 비슷한 선택을 할 때 감으로 다시 시작하지 않아도 되기 때문입니다.

단계	확인하는 질문	다음 행동
1. 목표	무엇을 줄이거나 알아내려는가	한 문장으로 적습니다.
2. 표본	작은 사례에서 같은 결과가 나오는가	입력과 결과를 보관합니다.
3. 예외	모르는 값이나 실패는 어떻게 보이는가	멈춤·알림·재확인 중 하나를 정합니다.
4. 적용	사람에게 영향을 주는 부분이 있는가	확인 단계를 남긴 뒤 범위를 넓힙니다.

짧은 점검표

• 목적을 한 문장으로 적었는가 — 필요한 기능과 멋있어 보이는 기능을 구분합니다.
• 작은 범위에서 확인했는가 — 처음부터 중요한 자료나 많은 사람에게 적용하지 않습니다.
• 바뀔 수 있는 부분을 표시했는가 — 요금·정책·지원 범위는 공식 안내를 다시 확인합니다.
• 결과를 사람이 읽어 봤는가 — 자동으로 나온 값도 맥락과 예외를 마지막에 확인합니다.
• 원래 상태를 되돌릴 수 있는가 — 바꾸기 전의 기록을 남겨 두면 비교와 복구가 쉬워집니다.

공식 문서가 나누는 두 종류의 프록시

MDN(Mozilla 개발자 문서)은 프록시를 어느 쪽을 대신하느냐에 따라 둘로 나눕니다. 정방향 프록시(forward proxy)는 클라이언트, 곧 사용자 쪽을 대신해 요청을 보내는 프록시이고, 대역폭을 줄이고 관리하려고 웹 페이지 같은 내용을 저장해 두었다가 전달하기도 합니다. 역방향 프록시(reverse proxy)는 서버 쪽을 대신해 요청을 받는 프록시이고, 서버의 정체를 숨기는 데 쓸 수 있습니다. 문서가 드는 쓰임새는 부하 분산, 정적 콘텐츠 저장, 압축이며 접근 제어와 인증, 암호 해독도 언급합니다.

이 글에서 말한 “인증키를 숨기려고 내 서버를 거치게 하는 구조”는 서버 쪽에 서서 요청을 대신 처리한다는 점에서 역방향에 가까운 모양입니다. 다만 이것은 이 글의 설명이며, MDN이 이 용도를 직접 예로 든 것은 아닙니다.

구분	누구를 대신하나	문서에 나온 쓰임새
정방향 프록시	클라이언트(사용자 쪽)	대역폭 절감과 관리, 클라이언트 IP 주소 숨기기
역방향 프록시	서버 쪽	부하 분산, 정적 콘텐츠 저장, 압축, 서버 정체 숨기기

프록시를 거치면 원래 요청자는 어떻게 알까

요청이 프록시를 지나면 받는 서버에는 프록시의 주소만 보입니다. MDN은 이런 정보를 잃지 않게 전달하는 방법으로 표준 헤더 Forwarded와 사실상 표준으로 쓰이는 X-Forwarded-For(클라이언트의 원래 IP 주소), X-Forwarded-Host(클라이언트가 요청한 원래 호스트), X-Forwarded-Proto(클라이언트가 쓴 프로토콜, HTTP 또는 HTTPS)를 소개합니다. Via 헤더는 클라이언트가 아니라 프록시 자신을 설명하며, 정방향과 역방향 프록시 모두 요청과 응답 헤더에 붙일 수 있습니다.

그래서 접속 기록이나 호출 횟수 제한을 프록시 뒤의 서버에서 하려면, 이 헤더를 어떻게 넘기고 어떻게 읽을지 미리 정해 두어야 합니다. 정하지 않으면 모든 요청이 같은 주소에서 온 것처럼 보입니다.

HTTPS 요청은 어떻게 프록시를 지나나

MDN에 따르면 HTTP 터널링은 상위 프로토콜(HTTP)로 하위 프로토콜(TCP)을 감싸서 전달하는 방식입니다. CONNECT 메서드는 요청한 대상과 양방향 통신을 시작해 터널을 열고, 이를 통해 HTTP 프록시 뒤에 있는 클라이언트가 HTTPS(TLS, 443번 포트) 사이트에 접속할 수 있습니다. 모든 프록시가 CONNECT를 지원하는 것은 아니고, 일부는 443번 포트로만 제한합니다.

또 브라우저가 어떤 요청은 직접, 어떤 요청은 프록시를 거쳐 보낼지 정하는 프록시 자동 설정(PAC) 파일도 소개합니다. PAC 파일은 .pac 확장자와 application/x-ns-proxy-autoconfig MIME 형식을 쓰는 자바스크립트 파일이고, FindProxyForURL(url, host) 함수가 “DIRECT” 또는 “PROXY 주소:포트” 형태의 값을 돌려줍니다.

앱스 스크립트로 만든 프록시가 하는 일

Google Apps Script 공식 문서에 따르면 스크립트를 웹 앱으로 게시하려면 doGet 또는 doPost 함수가 있어야 합니다. GET 요청은 doGet을, POST 요청은 doPost를 실행하고, 이 함수는 HTML 출력이나 텍스트 출력 객체를 돌려줘야 합니다. 요청 정보는 이벤트 매개변수 e의 e.parameter, e.parameters, e.postData로 전달됩니다. 앞의 의사 코드에서 doGet(e)가 하는 일이 바로 이것입니다.

실행 주체는 배포할 때 고릅니다. “나로 실행”이면 접속자가 누구든 스크립트는 소유자의 권한으로 실행되고, “접속한 사용자로 실행”이면 접속자가 권한 승인 화면을 보게 됩니다. 키를 서버 쪽에 두고 방문자에게는 결과만 주려는 구조라면 앞쪽 선택이 일반적인 모양입니다.

키는 어디에 저장하나

같은 문서 모음의 Properties Service 안내는 값을 문자열 키-값 쌍으로 저장한다고 설명합니다. 스크립트 속성(getScriptProperties())은 스크립트, 부가기능, 웹 앱의 모든 사용자가 공유하는 설정에 맞고, 문서가 드는 예가 “개발자의 외부 데이터베이스 인증 정보”입니다. 사용자 속성(getUserProperties())은 현재 사용자별 설정에 맞습니다. 값은 setProperty로 저장하고 getProperty로 읽으며, 읽은 값은 복사본이라 바꾸려면 다시 저장해야 합니다. 프로젝트 설정 화면에서는 스크립트 속성을 50개까지 직접 추가할 수 있습니다. 앞의 코드에서 “저장해둔_키_꺼내기”가 가리키는 자리가 이 속성 저장소입니다.

위치	방문자에게 보이나	비고
웹페이지 코드(자바스크립트)	소스 보기로 보임	브라우저로 내려가는 코드는 모두 공개
앱스 스크립트 스크립트 속성	웹페이지로는 내려가지 않음	스크립트 편집 권한이 있는 사람은 볼 수 있음
프록시 주소 자체	보임	누구나 호출할 수 있으므로 횟수 제한 등을 검토

직접 만들기 전에 정할 것

• 키를 둘 곳 — 웹페이지 코드가 아니라 서버 쪽 저장소에 둡니다.
• 실행 주체 — 누구의 권한으로 외부 서비스를 부르는지 배포 화면에서 확인합니다.
• 요청자 정보 — 접속 기록이나 횟수 제한이 필요하면 원래 요청자를 어떻게 알아낼지 정합니다.
• 저장해 둘 결과 — 같은 요청에 같은 답이 나가도 되는 것만 저장합니다.

정리하면 프록시는 요청을 대신 전달하는 자리이고, 그 자리에서 키 보관, 저장, 제한, 기록을 한곳에 모을 수 있습니다. 어떤 기능을 어디에 둘지는 위 표처럼 “누가 볼 수 있는가”를 기준으로 정하면 실수를 줄일 수 있습니다.

업데이트

이 글의 기본 설명은 원문 발행 당시 공개 자료를 바탕으로 합니다. 기능, 약관, 제공 범위와 수치는 바뀔 수 있으므로 실제 적용 전에는 아래 자료의 최신 안내를 확인하세요. 이 글의 출처는 2026-10-18 기준으로 열어 본 공식 문서입니다.

확인 자료

• MDN: 프록시 서버와 터널링 (열어 본 날: 2026-10-18)
• Google Apps Script: 웹 앱 (열어 본 날: 2026-10-18)
• Google Apps Script: 속성 서비스 (열어 본 날: 2026-10-18)
• CISA 보안 기본 수칙 (자료 목록에만 두었고 본문에서 직접 인용한 내용은 없습니다)

함께 읽기

• 캐시가 뭔가요: 한 번 받아온 것을 다시 쓰는 법
• 서버 안 빌리고 주소 하나 얻는 법: 구글 앱스 스크립트
• 헤드리스 브라우저가 뭔가요: 창이 안 뜨는 브라우저의 쓸모