이 글에서 다루는 내용
AirClass첫 프로토타입을 어떤 기준으로 설계하려 했는지- 왜
Spring + React대신FastAPI + Svelte를 선택했는지 DB,Redis같은 구성 요소를 어떻게 우선순위 뒤로 미뤘는지- 왜 교사 노트북 기반 로컬 네트워크 배포를 먼저 생각했는지
1편에서 적었듯 AirClass는 태블릿 수업의 실제 불편에서 출발했다. 그렇다면 다음 질문은 자연스럽다. 그 문제를 어떤 형태의 프로토타입으로 먼저 확인할 것인가?
이번 글에서는 그 첫 설계를 정리해 보려 한다.
학생들이 익숙한 스택과 내가 고른 스택은 달랐다
부산소프트웨어마이스터고 학생들은 대체로 백엔드에서는 Spring, 프론트엔드에서는 React를 많이 사용한다. 실제 취업 시장에서도 이 조합을 요구하는 경우가 많다. 그래서 처음에는 나 역시 익숙한 산업 표준에 더 가까운 방향으로 가야 하나 잠깐 고민했다.
하지만 AirClass는 취업 포트폴리오용 팀 프로젝트가 아니라, 내가 실제 수업에 쓰기 위해 빠르게 만들고 고쳐야 하는 도구였다. 이 프로젝트에서 가장 중요한 기준은 시장에서 많이 쓰이는 조합인지보다, 내가 가장 빠르게 읽고, 고치고, 디버깅하고, 다시 실험할 수 있는 조합인지였다.
그래서 결론은 분명했다. 이 프로젝트는 취업 시장의 기준보다 내 의도와 운영 방식에 맞는 스택을 선택하는 편이 맞았다.
백엔드는 왜 FastAPI로 시작하려 했는가
첫 번째 선택은 FastAPI였다.
이유는 단순하다. 실제로 내가 가장 많이 다뤘고, 업무 자동화에서도 가장 자주 활용했던 API 프레임워크이기 때문이다. 낯선 도구를 새로 익히면서 수업 도구를 만드는 것보다, 이미 손에 익은 도구로 빠르게 프로토타입을 돌려 보는 쪽이 훨씬 현실적이었다.
FastAPI를 고른 이유를 조금 더 풀면 세 가지다.
1. 가장 많이 써 본 도구였다
FastAPI는 내 작업 맥락에서 이미 검증된 도구였다. 간단한 API부터 실서비스 성격의 도구까지 여러 번 다뤄 봤기 때문에, 수업용 프로토타입을 빠르게 세우기에도 부담이 적었다.
2. 속도가 빠르고 구조가 단순했다
AirClass의 첫 버전은 거대한 복합 서비스가 아니라, 수업 중 빠르게 반응하는 작은 앱이어야 했다. 이때는 장기적인 기업형 구조보다, 필요한 API를 빠르게 세우고 동작을 확인할 수 있는 단순함이 더 중요했다.
3. 무엇보다 코드가 읽기 쉬웠다
이번 프로젝트에서 내가 계속 중요하게 본 것은 가독성이었다. 특히 바이브 코딩에서는 내가 직접 다시 읽을 수 있는 코드인지가 정말 중요하다. 코드를 빠르게 생성하는 것보다, 나중에 다시 봤을 때 수정 가능하고 디버깅 가능한지가 더 중요하기 때문이다.
그 점에서 FastAPI는 내가 작성한 코드도, AI가 보조해서 만든 코드도 비교적 읽기 쉬웠다. 그래서 첫 프로토타입의 백엔드로는 가장 자연스러운 선택이었다.
프론트엔드는 왜 React 대신 Svelte를 택했는가
프론트엔드는 학생들에게도 익숙하고 업계에서도 널리 쓰이는 React가 아니라 Svelte로 가 보기로 했다. 이 선택도 결국 같은 기준에서 나왔다.
내게 중요한 것은 "어떤 프레임워크가 더 널리 쓰이는가"보다, 어떤 프레임워크가 더 적은 코드로 더 분명한 화면을 만들 수 있는가였다.
1. 더 적은 코드량
바이브 코딩에서는 코드량이 곧 비용과 연결된다. 코드가 길어질수록 읽어야 할 양이 많아지고, 수정 포인트도 늘고, AI가 만들어 낸 결과를 검토하는 부담도 커진다. 그래서 첫 프로토타입 단계에서는 같은 화면을 더 적은 코드로 만들 수 있는지가 중요했다.
2. 내가 읽었을 때 바로 이해되는 구조
Svelte는 적어도 내 기준에서는 화면 코드가 더 직관적으로 읽혔다. 상태와 화면이 떨어져 보이지 않고, 내가 원하는 동작을 비교적 짧게 표현할 수 있었다. 결국 중요한 것은 세련된 추상화보다, 내가 수업 준비 중에도 다시 열어 보고 바로 고칠 수 있는가였다.
3. 디버깅 가능한 단순함
AirClass의 첫 버전은 프론트엔드 아키텍처를 뽐내는 프로젝트가 아니라, 실제 수업에서 바로 써 볼 수 있어야 하는 프로젝트였다. 그래서 복잡한 패턴보다 빠르게 확인 가능한 단순함이 우선이었다. Svelte는 그런 점에서 내가 원하는 방향과 잘 맞았다.
결국 React가 나쁜 선택이어서가 아니라, 이 프로젝트의 목적에 더 잘 맞는 선택이 Svelte였기 때문에 그렇게 정한 것이다.
DB와 Redis는 처음부터 고정하지 않으려 했다
처음 설계할 때부터 DB나 Redis를 반드시 넣어야 한다고 생각하지는 않았다. 오히려 이 부분은 필요가 생기면 붙이고, 아직 필요하지 않으면 최대한 늦추는 쪽이 맞다고 봤다.
이유는 분명했다. 첫 프로토타입에서 가장 먼저 확인해야 하는 것은 화려한 인프라가 아니라, 수업 흐름이 실제로 성립하는가였기 때문이다.
예를 들면 이런 질문이 더 앞에 있었다.
- 교사가 화면을 넘기면 학생 화면이 안정적으로 따라오는가
- 학생이 직전 자료를 다시 보는 흐름이 실제로 도움이 되는가
- 짧은 응답이나 인터랙션이 수업 안에서 자연스럽게 돌아가는가
- 같은 교실 네트워크 안에서 반응 속도와 일관성이 충분한가
이 질문에 답하기 전부터 저장소와 캐시 구조를 크게 설계하면, 정작 중요한 문제보다 주변 구성이 더 커질 수 있다. 그래서 DB, Redis는 "필요하면 붙인다"는 방향으로 두고, 첫 단계에서는 프로토타입의 핵심 흐름을 먼저 확인하는 쪽을 택하려 했다.
가장 중요한 배포 형태는 교사 노트북 기반 로컬 네트워크였다
이 설계에서 가장 중요하게 본 것은 의외로 프레임워크보다 배포 형태였다. AirClass를 어디에서 어떻게 실행할 것인가가 실제 수업 경험을 크게 바꾸기 때문이다.
내가 가장 먼저 생각한 형태는 교사 노트북에서 앱을 실행하고, 같은 교실 로컬 네트워크 안에서 학생들이 접속하는 방식이었다.
이 방식을 먼저 떠올린 이유는 크게 세 가지였다.
1. 학생 데이터가 외부로 나갈 가능성을 줄일 수 있다
수업 도구는 교육용 서비스라고 해도 학생 데이터와 접점이 있다. 아주 민감한 개인정보를 많이 주고받는 구조는 아니더라도, 가능한 한 외부 서비스 의존을 줄이고 교실 안에서 데이터를 처리하는 쪽이 더 안심되는 선택이라고 봤다.
2. 반응 속도가 빠르고 일관성이 좋다
수업 도구는 "언젠가 응답하면 되는 서비스"가 아니다. 교사가 화면을 바꾸고, 학생이 바로 반응하고, 다시 수업이 이어져야 한다. 이때 외부 서버를 거치는 구조보다 같은 네트워크 안에서 바로 붙는 구조가 훨씬 빠르고 일관적이다.
특히 교실에서는 평균 성능보다 한두 번의 버벅임이 수업 흐름을 끊는 문제가 더 크다. 그래서 첫 프로토타입에서는 화려한 클라우드 구조보다 로컬 네트워크에서의 안정적인 반응성을 더 우선했다.
3. 운영 주체가 교사라는 점에 잘 맞는다
이 프로젝트는 학교 전산 시스템이 아니라, 교사가 자기 수업을 위해 직접 운영하는 도구에 가깝다. 그렇다면 배포 방식도 거대한 중앙 서비스보다, 교사가 자신의 노트북에서 열고 같은 교실 안에서 바로 사용할 수 있는 쪽이 더 잘 맞았다.
HTTPS 제약은 있지만 감당 가능한 문제라고 봤다
물론 교사 노트북 기반 로컬 배포에는 제약도 있다. 대표적인 것이 HTTPS와 인증서 문제다. 브라우저 기능에 따라서는 보안 컨텍스트가 필요하고, 로컬 환경에서는 인증서 구성이 번거로울 수 있다.
하지만 이 문제는 초기에 감당 불가능한 수준이라고 보지 않았다. 내부 인증서 설치 같은 방식으로 어느 정도 극복할 수 있고, 무엇보다 수업 특성상 은행 서비스처럼 아주 민감한 데이터를 대규모로 주고받는 구조는 아니라고 판단했다.
즉 "완벽한 인터넷 서비스 환경"을 먼저 만드는 것보다, 교실 안에서 실제로 잘 돌아가는 안전한 도구를 먼저 확보하는 쪽이 더 중요하다고 본 것이다.
그래서 첫 프로토타입은 이렇게 생각했다
정리하면, 첫 프로토타입은 아주 거창한 구조가 아니었다.
- 백엔드:
FastAPI - 프론트엔드:
Svelte - 저장소/캐시: 필요가 확인되면
DB,Redis도입 검토 - 배포: 교사 노트북에서 실행하고 교실 로컬 네트워크에서 학생 접속
핵심은 최신 스택을 자랑하는 것이 아니라, 내가 가장 잘 읽고 빠르게 고칠 수 있는 도구들로 실제 수업 문제를 먼저 확인해 보는 것이었다.
마치며
AirClass의 첫 설계에서 중요했던 것은 업계 표준을 그대로 따르는 일이 아니었다. 오히려 내 수업에서 실제로 써 보고, 내가 직접 고치고, 필요하면 바로 구조를 바꿀 수 있는 선택을 하는 일이 더 중요했다.
그래서 FastAPI, Svelte, 로컬 네트워크 배포라는 조합은 취업 시장 기준의 정답이라기보다, 이 프로젝트의 목적에 맞춘 첫 선택이었다.
다음 글에서는 이 선택 위에서 실제 프로토타입 화면과 흐름을 어떻게 나누어 볼지 더 구체적으로 적어 보겠다.
💬 댓글
이 글에 대한 의견을 남겨주세요