검색 한 번에 화면 세 개가 움직이는 서버를 준비 중입니다

지난 글에서는 주소 주변 상가를 조회하고 북마크하는 웹사이트를 만들면서 GET, POST 같은 API 요청을 따라가 보았습니다.

지난 글: 주소지 주변 상가 조회 북마크로 API 서버의 GET, POST 이해하기

버튼을 눌렀을 때 서버에 어떤 요청이 가고, 서버가 어떤 응답을 돌려주는지는 대략 알게 되었습니다. 이번에는 여러 사람이 동시에 요청을 보낼 때 그 요청이 어디로 가고, 서버에서 무슨 일이 일어났는지를 함께 볼 수 있는 구조를 만들고 있습니다.

혼자 확인하던 API 서버를 여러 사람이 참여하고 함께 관찰할 수 있는 서버로 바꾸는 중입니다.

👀 목차

1. 화면보다 먼저 만든 것들

2. 검색 한 번은 어디를 거쳐갈까

3. 같은 서버를 보는 세 가지 화면

4. 청중에게 어디까지 허용할 것인가

5. 이제 외부에 문을 열 차례

1. 화면보다 먼저 만든 것들

지난 글 이후 한 주 동안 새 화면보다는 화면 뒤쪽을 주로 만들었습니다.

서버에서 몇 번의 요청이 발생했고 처리에는 얼마나 걸렸는지, 현재 몇 개의 실시간 화면이 연결되어 있는지 확인할 수 있도록 운영 상태를 수집하기 시작했습니다. 전체 상가 수와 저장된 북마크 수도 서버에서 직접 읽을 수 있게 했습니다.

검색, 북마크 저장, 삭제처럼 서버에서 일어난 일은 하나의 ‘사건’으로 다루도록 했습니다. 서버 안에서 발생한 사건을 한곳에 모아 필요한 화면으로 나눠주는 장치가 이벤트 버스라고 합니다.

그리고 서버에서의 사건을 화면으로 바로 전달하기 위해 SSE도 연결했습니다. SSE는 화면에서 계속 새로고침하지 않아도 서버가 새로 일어난 일을 밀어주는 방식입니다.

둘 다 처음 듣는 이름이었지만 이번 프로젝트에서는 역할이 비교적 분명했습니다.

이벤트 버스: 서버 안에서 일어난 일을 모으고 나눠주는 장치
SSE: 서버의 일을 화면까지 전달하는 실시간 신호선

검색이나 저장 버튼을 누르면 결과만 돌아오는 것이 아니라, 서버 안에서 어떤 사건이 발생했는지도 다른 화면에서 확인할 재료가 생긴 것입니다.

서버를 다시 시작했을 때 무엇이 사라지고 무엇이 남는지도 확인했습니다. 요청 횟수나 최근 사건처럼 현재 실행 중에만 필요한 정보는 초기화되고, SQLite에 저장된 북마크는 서버를 다시 시작해도 유지됐습니다.

같은 Wi-Fi에 연결된 휴대전화가 노트북 서버에 실제로 접속하는 실험도 한 차례 진행했고요. 접속 성공을 확인한 뒤에는 다시 노트북 내부에서만 열리는 상태로 돌려놓았습니다.

아직 청중이 접속할 화면은 없지만, 화면에 표시할 숫자와 사건이 흐르는 신호선은 만들어진 상태입니다.

2. 검색 한 번은 어디를 거쳐갈까

다음 단계에서는 Zoom 발표를 듣는 청중이 자신의 휴대전화로 상가를 검색하고 북마크할 수 있게 하려고 합니다. 발표를 듣는 PC에서는 다른 사람들이 보낸 요청과 서버의 변화를 함께 볼 수 있게 할 생각입니다.

이를 위해 최종적으로 구성하려는 흐름은 다음과 같습니다.

[청중의 휴대전화]
상가 검색·북마크
        │
        ▼
[임시 HTTPS 터널]
발표 시간에만 여는 외부 통로
        │
        ▼
[접근 권한 확인]
시연 토큰·세션·요청 횟수 제한
        │
        ▼
[Express API 서버]
요청 처리
   │           │
   ▼           ▼
[SQLite]    [이벤트 버스]
데이터 저장   사건 분배
                 │
        ┌────────┴────────┐
        ▼                 ▼
[청중의 PC]          [제 노트북]
라이브 현황판         운영자 관제실
요약된 변화 조회      상세 상태·오류 확인

예를 들어 청중 한 명이 휴대전화에서 상가를 검색하면 요청은 임시 터널을 지나 제 노트북의 API 서버에 도착합니다. 서버는 이 사람이 발표에 참여할 수 있는 세션인지, 너무 많은 요청을 반복해서 보내고 있지는 않은지 먼저 확인합니다.

허용된 요청이면 상가 검색 결과를 휴대전화에 돌려주고, 동시에 ‘검색이 발생했다’는 사건을 만듭니다. 이 사건은 이벤트 버스를 거쳐 청중의 라이브 현황판과 제 관제실에 각각 필요한 형태로 전달됩니다.

마음에 드는 상가를 북마크하면 SQLite에 데이터가 저장됩니다. 라이브 현황판의 북마크 수도 바뀌고, 제 관제실에서는 저장이 성공했는지와 서버 상태를 조금 더 자세히 확인할 수 있습니다.

여기서 터널은 외부 사용자가 제 서버에 도착할 수 있도록 길을 연결하는 역할만 합니다. 누가 무엇을 할 수 있는지는 터널이 아니라 API 서버에서 따로 정해야 합니다.

이번에는 Express 앱 하나만 임시로 공개할 예정이라 Caddy 같은 별도의 리버스 프록시는 추가하지 않으려고 합니다. 여러 서비스를 주소별로 안내해야 하는 상황이 아니기 때문에, 우선은 아래처럼 단순하게 구성하는 편이 확인하기 쉽다고 판단했습니다.

임시 터널 → Express API 서버 → SQLite

ALT

한국 사업 계획의 스크린샷

3. 같은 서버를 보는 세 가지 화면

이번 시연에서 만들 화면은 세 종류입니다.

① 휴대전화 참여 화면

청중이 직접 상가를 검색하고 북마크하는 화면입니다.

주소와 반경을 입력해 주변 상가를 조회하고, 마음에 드는 상가를 북마크할 수 있습니다. 작은 휴대전화 화면에서 사용하므로 검색과 저장에 필요한 기능만 남기려고 합니다.

② PC 라이브 현황판

Zoom을 듣는 PC에서 선택적으로 열어볼 수 있는 화면입니다.

현재 몇 명이 참여하고 있는지, 검색과 북마크가 몇 번 발생했는지, 어떤 지역이나 상가가 관심을 받고 있는지를 요약해서 보여줄 예정입니다.

이 화면에서는 데이터를 바꾸지 못하고 변화만 볼 수 있습니다. 그래서 ‘관제판’보다는 라이브 현황판이나 참여 현황판이라는 이름이 더 정확할 것 같습니다.

Zoom 화면 공유만 봐도 발표를 따라갈 수 있지만, PC에서 현황판을 함께 열어두면 자신의 휴대전화 검색이 실제 서버에 도착해 반영되는 모습을 직접 확인할 수 있습니다.

③ 제 노트북의 운영자 관제실

ALT

보라색 배경의 웹사이트 스크린샷

서버를 운영하는 제가 보는 화면입니다.

요청 수와 평균 처리 시간, 현재 연결 수, 저장 성공 여부와 오류 같은 정보를 확인합니다. 문제가 생겼을 때 원인을 확인하거나 시연 데이터를 정리하는 기능도 이쪽에 둘 예정입니다.

이 화면은 청중에게 공개하지 않고 제 노트북의 localhost에서만 열리게 합니다.

세 화면은 모두 같은 API 서버를 바라보지만, 보이는 정보와 할 수 있는 일은 다릅니다.

휴대전화 참여 화면: 검색하고 저장한다
PC 라이브 현황판: 정리된 변화를 본다
운영자 관제실: 서버 상태를 확인하고 관리한다

화면마다 별도의 서버가 있는 것은 아닙니다. 같은 서버에서 역할에 따라 데이터와 권한을 나눠주는 구조입니다.

4. 청중에게 어디까지 허용할 것인가

청중에게 허용할 기능은 상가 검색과 북마크 저장입니다. 삭제, 전체 초기화, 운영 상태 원문 확인 같은 기능은 허용하지 않습니다.

PC 라이브 현황판에서도 전체 검색어, IP 주소, 세션 정보나 오류 원문을 보여주지 않을 예정입니다. 참여 인원, 검색 횟수, 북마크 수처럼 발표 흐름을 이해하는 데 필요한 정보만 정리해서 보여줍니다.

화면에서 삭제 버튼을 숨기는 것만으로는 부족합니다. 버튼이 보이지 않아도 주소를 직접 호출할 수 있기 때문에, 서버가 요청을 받을 때마다 해당 사용자의 역할을 확인해야 합니다.

참여자
- 상가 검색: 허용
- 북마크 저장: 허용
- 관리·삭제 기능: 거부

현황판 관찰자
- 요약 정보 조회: 허용
- 검색·저장·삭제: 거부

운영자
- 상세 상태 확인과 관리: 허용

발표할 때는 이 흐름을 색으로도 구분해보려고 합니다.

청중이 상가를 검색하면 파란 신호가 들어오고, 북마크를 저장하면 붉은 신호가 남습니다. SQLite에 데이터가 반영되고 전체 상태가 바뀌는 과정은 보라색 변화로 표시합니다.

기술 구조를 모르는 사람도 색의 이동만 보면 다음 흐름을 따라갈 수 있게 만드는 것이 목표입니다.

검색 요청
→ 서버 도착
→ 북마크 저장
→ 데이터베이스 반영
→ 세 화면의 상태 변화

서버가 보내는 숫자를 관제 화면에 나열하는 것보다, 청중이 방금 한 행동이 어떤 과정을 거쳐 결과로 남았는지를 보여주고 싶습니다.

이 구조를 만들면서 공개와 권한은 서로 다른 문제라는 것도 알게 됐습니다.

터널은 서버까지 들어오는 길을 열어주지만, 그 사람이 검색만 할 수 있는지 삭제까지 할 수 있는지는 결정하지 않습니다. HTTPS도 통신 내용을 암호화할 뿐, 사용자의 역할까지 정해주지는 않습니다.

결국 외부 접속을 연다는 것은 서버 전체를 보여주는 일이 아니라, 누구에게 어떤 기능을 얼마나 오래 허용할지 정하는 일이었습니다.

5. 이제 외부에 문을 열 차례

다음에는 임시 HTTPS 터널을 만들고 세 화면을 실제 데이터에 연결할 예정입니다.

걱정되는 점도 있습니다. 여러 명이 동시에 검색했을 때 서버와 현황판이 안정적으로 움직일지, Zoom에 공유한 링크가 밖으로 전달돼도 허용하지 않은 기능을 막을 수 있을지 확인해야 합니다. 사용하는 터널에서 실시간 연결이 안정적으로 동작하는지도 실제 LTE 환경에서 시험해봐야 합니다.

(과연 Zoom과 서버 실험을 사양 낮은 제 컴퓨터가 버텨줄지...)

발표가 끝난 뒤에는 터널과 접근 권한을 닫고, 서버가 다시 노트북 내부 전용 상태로 돌아왔는지도 확인하려고 합니다.

검색 한 번에 정말 화면 세 개가 움직이는지, 정말 기대가 됩니다.