저번 글에서 GET과 POST를 이해하기 위해 주소지 주변의 상가를 검색하고 북마크하는 API 서버를 만들었습니다.
이번 24시간 AI 서버 스터디에서는 이 서버를 Docker로 실행하고, AI 에이전트와 휴대전화 원격 접속, 실시간 관제 화면까지 연결해보려고 합니다.
아직 계획 단계라 실제로 만들면서 달라지는 부분도 있겠지만, 4주 동안 무엇을 만들고 어떤 내용을 확인해보고 싶은지 먼저 정리해보았습니다.
목차
지금까지 만든 것
4주 뒤 만들고 싶은 모습
이번 스터디에서 적용할 내용
그 밖에 배우고 싶은 것
이번에는 하지 않을 것
완성 조건
잡담: 24시간 돌릴 것도 없으면서 서버를 만들려는 이유
1. 지금까지 만든 것
이전 글: [주소지 주변 상가 조회 북마크로 API 서버의 GET, POST 이해하기]
현재는 도로명 주소와 반경을 입력하면 주변의 서울 상가를 조회하고, 마음에 드는 상가에 메모와 북마크를 남길 수 있습니다. 서울 상가 데이터 약 53만 건을 SQLite에 넣었고, 검색·북마크·삭제 요청이 어떤 JSON으로 오가는지도 화면에서 확인할 수 있게 만들었습니다.
지금까지는 제 노트북에서 요청과 응답을 확인하는 데 집중했다면, 이번에는 이 서버를 계속 실행하고 다른 기기에서 부를 수 있는 형태로 확장해보려고 합니다.
2. 4주 뒤 만들고 싶은 모습
최종적으로 생각하고 있는 흐름은 아래와 같습니다.
text
[휴대전화]
상가 검색 또는 자연 어 요청
│
▼
[Tailscale]
제 노트북까지 연결
│
▼
[Docker의 API 서버]
Express + Agent SDK
│
├─ OpenRouter 모델 호출
├─ 상가 검색 도구 실행
├─ 북마크 도구 실행
▼
[SQLite]
상가 데이터와 북마크 저장
│
▼
[노트북 관제 화면]
검색·저장·서버 상태를 실시간으로 표시
소셜 라이브 예산 지도
예를 들어 휴대전화에서 “시청역 주변 50m 안에 있는 카페를 찾아줘”라고 입력하면, 에이전트가 기존 상가 검색 기능을 도구로 실행합니다.
검색 결과 중 마음에 드는 곳을 북마크하면 SQLite에 저장하고, 노트북의 별도 관제 화면에는 검색 요청이 들어온 순간부터 DB 저장이 끝난 시점까지 실시간으로 표시되게 만들 생각입니다.
관제 화면에는 검색, 북마크 요청, DB 저장 완료를 서로 다른 파동과 신호로 표현하는 시각 언어를 적용해보려고 합니다. 단순히 화면을 화려하게 만드는 장식이라기보다, 서버 구조를 모르는 사람도 요청이 도착하고 처리되는 순서를 눈으로 따라갈 수 있게 하는 것이 목표입니다.
(말없이 시연해도 대충 무슨 일이 일어나고 있는지 보이는 화면을 만들고 싶습니다.)
3. 이번 스터디에서 적용할 내용
1주차: API 서버 점검
기존 Express 서버의 GET·POST·DELETE 요청과 health API를 다시 점검하고, 이후 기능을 추가해도 기존 검색과 북마크가 깨지지 않도록 테스트 기준을 만들려고 합니다.
API 서버는 이미 어느 정도 만들어져 있으므로, 1주차에는 처음부터 다시 만들기보다 현재 상태를 기준선으로 정리할 예정입니다.
2주차: Docker와 Agent SDK
Express 서버를 Docker 컨테이너로 실행하고, 컨테이너를 다시 만들어도 SQLite의 북마크가 남도록 데이터 경로를 분리합니다.
Agent SDK에는 우선 아래와 같은 기존 기능을 도구로 연결하려고 합니다.
주변 상가 검색
저장한 북마크 조회
상가 북마크 저장
서버 상태 확인
처음부터 복잡한 에이전트를 만들기보다 자연어 요청이 실제 도구 호출과 DB 저장으로 이어지는 것부터 확인할 생각입니다.
3주차: OpenRouter와 Tailscale
제 노트북은 8GB RAM과 내장 그래픽 환경이라 Docker, 브라우저, 발표 화면과 로컬 LLM을 동시에 실행하기에는 부담이 있을 것 같았습니다.
그래서 이번에는 Ollama 대신 강의에서 대체 방법으로 안내한 OpenRouter를 모델 백엔드로 사용하려고 합니다. 에이전트 서버와 상가 데이터는 제 노트북에서 실행하고, 문장을 해석하고 응답을 만드는 모델만 OpenRouter를 이용하는 구조입니다.
Tailscale도 연결해 같은 와이파이가 아닌 휴대전화에서 제 노트북의 서버를 직접 호출해보려고 합니다.
4주차: 전체 연결과 발표
마지막 주에는 휴대전화 요청, Agent SDK의 도구 호출, SQLite 저장, 실시간 관제 화면을 하나의 흐름으로 연결합니다.
컨테이너를 재생성해도 북마크가 남는지도 직접 보여주고, 로컬에서 직접 운영하는 방식과 Vercel 같은 관리형 서비스를 이용하는 방식이 어떻게 달랐는지 정리해볼 예정입니다.
주차
만들 내용
확인할 것
1주차
기존 API 점검
검색·북마크와 테스트
2주차
Docker + Agent SDK
컨테이너 실행과 도구 호출
3주차
OpenRouter + Tailscale
모델 연결과 휴대전화 접속
4주차
전체 통합
요청·저장·관제·데이터 유지
4. 그 밖에 배우고 싶은 것
서버에서 실제로 무슨 일이 일어나는지 보기
사용자 화면과 별도로 관제 화면을 만들고, SSE를 이용해 검색·북마크 이벤트를 실시간으로 받아보려고 합니다.
서버가 켜져 있다는 것만 확인하는 게 아니라 요청 수, 응답 시간, 오류 여부, DB 상태처럼 서버가 제대로 일하고 있는지도 화면에서 확인해보고 싶습니다.
컨테이너와 데이터의 생명주기 구분하기
Docker 컨테이너는 지웠다가 다시 만들 수 있지만, 사용자가 저장한 북마크까지 같이 사라지면 안 됩니다.
북마크를 저장한 뒤 컨테이너를 삭제하고 다시 생성했을 때 같은 북마크가 조회되는지 직접 확인하려고 합니다. 시간이 허락하면 SQLite를 백업하고 다시 복원하는 과정도 해보고 싶습니다.
외부에 공개할 때 권한 나누기
발표 중 다른 사람이 접속하게 된다면 검색과 발표용 북마크만 허용하고, 삭제 기능과 관제 화면은 발표자만 사용할 수 있도록 구분할 생각입니다.
주소 원문과 메모 내용, OpenRouter API 키가 로그나 Docker 이미지에 들어가지 않는지도 확인하려고 합니다.
자체 운영과 관리형 서비스 비교하기
직접 서버를 운영하면 자유롭게 로컬 파일과 SQLite를 사용할 수 있지만, 재시작·백업·보안·절전 상태까지 제가 신경 써야 합니다.
반대로 관리형 서비스는 이런 일을 많이 대신해주지만 실행 방식이나 파일 저장에는 제약이 있을 수 있습니다. 이번에는 두 방식 중 무엇이 더 좋다는 결론을 미리 정하지 않고, 직접 운영해본 뒤 프로젝트에 따라 판단할 기준 을 만들어보고 싶습니다.
5. 이번에는 하지 않을 것
하다 보면 새로운 기능을 계속 붙이고 싶어질 것 같아서, 이번에 하지 않을 것도 미리 정했습니다.
AI 맛집 추천
RAG와 벡터 DB
전국 상가 데이터
회원가입과 다중 사용자 관리
Kubernetes
Prometheus·Grafana 전체 구성
영구적인 공용 인터넷 서비스
실제 사업 서비스 수준의 고가용성
Ollama를 이용한 로컬 LLM 운영
AI 맛집 추천을 넣으면 좀 더 AI 서비스처럼 보일 수는 있겠지만, 이번에는 추천 품질보다 API 서버, 에이전트 도구, Docker, 원격 접속이 실제로 연결되는 과정을 끝까지 확인하는 데 집중하려고 합니다.
로컬 LLM도 아주 작은 모델이라면 실행 자체는 가능할 수 있지만, 발표 중 Docker와 여러 화면을 함께 켜놓아야 해서 OpenRouter를 선택했습니다. 안 그래도 8GB RAM이 열심히 일하고 있어서 더 시키면 노트북이 먼저 시위를 할 것 같아요.
6. 완성의 기준
4주 뒤 아래 내용을 실제로 확인하면 이번 프로젝트를 완성으로 보려고 합니다.
Docker Compose 명령으로 서버를 실행할 수 있다.
휴대전화에서 제 노트북의 서버에 접속할 수 있다.
자연어 요청이 실제 상가 검색 도구를 호출한다.
북마크 저장 후 SQLite에서 같은 데이터가 조회된다.
휴대전화의 요청이 노트북 관제 화면에 실시간으로 표시된다.
컨테이너를 삭제하고 다시 만들어도 북마크가 유지된다.
OpenRouter 연결에 실패했을 때 정상 응답인 것처럼 표시하지 않는다.
API 키와 사용자 입력 원문이 Git, Docker 이미지, 로그에 들어가지 않는다.
최종 발표에서는 아래 흐름을 짧게 보여주고 싶습니다.
text
휴대전화에서 상가 검색
→ 관제 화면에 검색 신호 표시
→ 마음에 드는 상가 북마크
→ DB 저장 완료 상태 표시
→ Docker 컨테이너 재생성
→ 저장한 북마크 다시 확인이 장면들이 실제로 이어진다면, 단순히 화면만 만든 것이 아니라 API, 에이전트, 모델, 데이터, 네트워크가 연결된 전체 흐름을 한 번 경험한 셈이 될 것 같습니다.
7. 잡담: 24시간 돌릴 것도 없으면서 서버를 만들려는 이유
사실 처음에는 제가 원래 하던 프로젝트에서 적용하고 싶 었는데 지금 당장 24시간 돌아가야 하는 것이 제겐 없었습니다...
스터디의 많은 멤버 분들은 텔레그램 봇으로 업무를 자동화하거나 새벽에도 작업이 돌아가야 하는 실제 이유가 있는데, 저는 아직 “이걸 꼭 상시 서버로 운영해야 한다”는 프로젝트가 있는 것은 아니거든요.
다행히 GET과 POST를 이해하려고 만든 상가 검색 API가 있었고, SQLite와 검색·북마크 기능까지 들어가 있으니 서버 운영을 실험해보기에는 적당해 보였습니다.
저는 지금까지 Vercel 같은 관리형 서비스와 직접 서버를 운영하는 방식의 차이를 머리로만 이해하고 있었습니다. 관리형 서비스가 편하다는 건 알지만, 구체적으로 무엇을 대신 맡아주고 있는지는 직접 운영해보지 않으면 잘 와닿지 않더라고요.
그래서 이번 프로젝트의 목적은 “자체 서버가 더 좋다”는 결론을 내리는 것이 아닙니다.
직접 Docker로 서버를 띄우고, 데이터가 사라지지 않게 만들고, 휴대전화로 접속하고, 오류와 재시작을 경험해본 뒤에야 어떤 프로젝트를 직접 운영할 가치가 있는지 조금은 판단할 수 있을 것 같습니다.
4주 뒤에는 자체 서버가 생각보다 재미있어서 계속 운영하고 있을 수도 있고, 관리형 서비스가 괜히 편한 게 아니었다며 돌아갈 수도 있습니다. 둘 중 어느 쪽이든 직접 겪고 내린 결론이라면 이번 스터디에서 얻은 것이 있다고 생각합니다.
일단 지금 가장 궁금한 것은 이겁니다.
제 노트북은 4주 동안 무사할 수 있을까요...?
