✨ ft_transcendance: 풀스택 웹 애플리케이션 아키텍처의 완성

드디어 대단원에 도착했다. 42서울의, 소위 공통과정이라고 하는 프로젝트의 모음, 그 중 가장 끝 자리에 있는 프로젝트. ‘초월자’ 라는 이름이 걸맞게 가장 진보된, 동시에 가장 현재의 사용되는 기술들을 총체적으로 배우고 적용해보는 것이 바로 본 프로젝트이다.

ft_transcendance는 42 과정에서 배운 모든 지식을 총동원하여, 현대적인 기술 스택 위에서 실시간 상호작용이 가능한 풀스택(Full-stack) 웹 애플리케이션을 처음부터 끝까지 설계하고 구축하는 프로젝트다. SPA 기반이며 stateless 지만, 일정하게 state 를 소지하도록 해야하고, 동시에 내부적으로 단순히 RESTful API 사용만이 아니라, Socket.IO를 다시 활용하여, 실시간 렌더링에 가까운 방식으로 멀리 떨어진 유저들 사이에서 게임이 구동 될 수 있게 만들어야 한다. 특히 이를 위한 ‘프레임워크’를 각 분야별로 사용한다는 지점은 단순히 개발을 쌓아올리는게 아니라는 점을 의미한다.

단순히 특정 프레임워크 사용법을 익히는 것을 넘어, 분리된 프론트엔드와 백엔드, 데이터베이스를 컨테이너 기술로 묶어 하나의 유기적인 서비스로 조율하는 현대 웹 아키텍처에 대한 깊은 이해, 그리고 그런 모습을 머릿속에서 실제 현실로 구현해낼 수 있는가?를 묻는, 그런 기념비적 ‘실전형’ 프로젝트이다. 특히나 현대적 패턴이 포함된 각 프레임워크는 개발의 형태를 지배하고 있고, 효율적이거나 효과적인 개발을 하려면 단순히 하겠다- 라는 표현이 아니라 ‘어떻게-‘ 라는 접미사를 잘 붙여야 한다.

채팅과 실시간 PING-PONG 게임이라는 요구사항은, 일반적인 CRUD(Create, Read, Update, Delete) 애플리케이션의 한계를 넘어 실시간 양방향 통신(WebSocket), 상태 동기화(State Synchronization), 서버 권위적(Server-Authoritative) 로직과 같은 고수준의 엔지니어링 과제를 해결하도록 이끌었고, 본 과재를 통해 비즈니스 로직을 포함하는 WAS 를 어떻게 구축하고, 여기서 가지게 되는 실전 같은 현실 문제들을 마주하게 됨은 개발자로의 진짜 본격적 시작점이 어떤 수준인가를 느끼게 해주었다.

특히나 webserv에서 단련되고 알게된 사람들을 기준으로, 보다 적응된 상황에서 협업을 고도화 할 수 있었던 점에서, 정말로 ‘초월자’ 라는 키워드는 잘 어울리는 프로젝트라 할 수 있겠다.

📜 1. 기술 스택과 아키텍처 설계 철학

ft_transcendance의 기술 스택은 각 계층의 역할을 명확히 분리하고, 유지보수성과 확장성을 극대화하는 방향으로 선택되었다.

  • 백엔드 - NestJS (Node.js):
    • 설계 철학: 제어의 역전(IoC)과 의존성 주입(DI) 패턴을 프레임워크 수준에서 적극적으로 활용하여, 모듈 기반의 확장 가능한 아키텍처를 제공한다. 이는 각 기능(사용자, 채팅, 게임)을 독립적인 모듈로 개발하고 테스트하기 용이하게 만들어, 대규모 애플리케이션의 복잡성을 효과적으로 관리하게 한다. TypeScript를 기본으로 사용하여 정적 타입의 안정성을 확보한 것 또한 중요한 선택 이유이다. 물론, 돌아보면 알 수 있는 것은 Java Spring 을 사용해도 괜찮지 않을까? 하는 의구심은 있었다. 단순히 싱글 스레드의 비동기 비봉쇄 이벤트 방식만으론 한계가 있다. 실제 NestJS 로도 워커를 활용한 스레드로 독자적인 게임의 실시간 처리를 가능하게 하지만, NestJS 는 기본 이 방식을 지원하진 않다보니, 서버의 상황에 상당히 영향을 받는다. 이런 점에서 다 만들고 느끼는 바, 기본으론 Spring 을 했다면? 하는 생각은 남는다.
    • ORM - TypeORM: 데이터베이스와의 상호작용을 객체 지향적으로 처리하기 위해 ORM(Object-Relational Mapper)을 사용한다. SQL 쿼리를 직접 작성하는 대신 TypeScript 클래스와 데코레이터를 통해 데이터베이스 스키마와 관계를 정의하고 조작함으로써, 개발 생산성과 코드의 안정성을 높인다. 그저 단순히 백엔드를 DB 와 연결하는 방식을 사용할 수도 있었다. 하지만 ORM 을 사용함으로써 자연스럽게 백엔드에서 보안을 분리해내는게 가능해졌으며, 백엔드 개발자의 DB 조작 역시 편리하다. 이점은 상당한 이점이라는 것을 볼 수 있었다.
  • 프론트엔드 - Next.js (React):
    • 설계 철학: 사용자 경험(UX)과 검색 엔진 최적화(SEO)를 고려하여 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)을 지원한다. 초기 페이지 로딩 시 서버에서 완성된 HTML을 전달하여 클라이언트 측 렌더링(CSR) 방식의 단점인 긴 초기 로딩 시간을 개선한다. React의 컴포넌트 기반 개발 방식은 복잡한 UI를 재사용 가능한 조각으로 나누어 관리하는 데 효과적이다. 컴포넌트 단위이기 때문에 동일한 환경을 구현하는데, 혹은 부분만 개발하는게 가능해지고, 이때의 상태관리, 훅과 같은 개념은 프론트엔드 개발이 반복작업이 많다는 점을 개선할 수 있다는 사실을 깨닫게 해주고, 특히나 웹 환경이라는 다소 독특한 지점을 어떻게 다루는지 이해하게 해주었다.
  • 인프라 - Docker & Docker Compose:
    • 설계 철학: 개발, 테스트, 프로덕션 환경의 차이로 인해 발생하는 문제를 원천적으로 차단하기 위해 컨테이너화(Containerization)를 채택한다. 백엔드, 프론트엔드, 데이터베이스를 각각 격리된 컨테이너로 패키징하여, 어디서든 동일한 환경에서 애플리케이션을 실행할 수 있도록 보장한다. docker-compose.yml은 이 모든 서비스의 구성과 관계를 정의하는 선언적(Declarative) 명세서 역할을 한다. 이를 통해 필요시엔 어떤 환경에서든 도커 기반으로 펼치는게 가능하며, 추가로 볼륨 등을 별도로 지정하는 방식을 통해, 저장해둬야 하거나, 테스트시 필요한 데이터 등을 그대로 유지하는 것도 가능해진다.

🎯 2. 핵심 기능의 심층 분석

가. 사용자 인증 (Authentication & Authorization)

  • 42 Intra OAuth 2.0: 인증(Authentication)의 시작점으로, 신뢰할 수 있는 제3자(42 Intra)에게 인증을 위임하는 OAuth 2.0 프로토콜을 구현한다. 이를 통해 서비스는 사용자의 민감한 크리덴셜을 직접 저장할 필요 없이 안전하게 사용자를 식별할 수 있다.
  • JWT (JSON Web Token) 기반의 무상태(Stateless) 세션: 인증 성공 후, 서버는 사용자의 정보를 담아 암호학적으로 서명된 JWT를 발급한다. 클라이언트는 이 토큰을 저장해두고, 이후 모든 API 요청의 Authorization 헤더에 담아 전송한다. 서버는 데이터베이스 조회 없이 토큰의 서명만으로 사용자를 검증할 수 있으므로, 세션 상태를 서버에 저장할 필요가 없는 무상태(Stateless) 인증을 구현할 수 있다. 이는 서버의 수평적 확장에 매우 유리한 구조이다. 본 프로젝트에서는 사용하지 않았으나, 이러한 구조의 인증과 DB와의 연결 구성을 통해, 스케일 확장을 수평적 진행 시 이론적으로도 바로 적용 & 어떤 서버로 로드 벨런싱이 되도 문제가 없다.
  • 2단계 인증 (2FA): 보안 강화를 위해 TOTP(Time-based One-Time Password) 알고리즘을 기반으로 한 2단계 인증을 구현한다. 사용자는 인증 앱(Google Authenticator 등)을 통해 생성된 일회용 비밀번호를 추가로 입력해야만 로그인이 완료되어야 하나, 해당 부분은 선택항목이었기에 간소화하여 이메일로 인증번호를 제공하였다.

나. 실시간 양방향 통신 (Real-time Bidirectional Communication)

  • WebSocket의 채택: 채팅이나 실시간 알림과 같이 서버와 클라이언트 간의 즉각적인 양방향 통신이 필요했다. 이러한 필요 기능을 위해 WebSocket을 사용하지만 단순한 socket 통신 자체를 이용하진 않는다. 기존의 HTTP 폴링(Polling) 방식이 가지는 불필요한 요청 오버헤드와 지연 시간 문제를 해결하고, 하나의 TCP 연결 위에서 양방향으로 데이터를 전송하는 효율적인 통신 채널을 구축한다. 이때 핵심 중에 핵심이 Socket.IO 라이브러리이다. 본 라이브러리는 WebSocket을 기반으로, 필요시 HTTP Long-Polling으로 자동 전환되는 기능과 Room, Namespace 같은 편리한 추상화 계층을 제공한다. 이를 활용해 자동 연결, 연결 복원, 실시간 게임의 핵심 데이터 동기화 등 다양한 지점에서 사용되어 서비스들의 핵심적인 역할을 수행한다. 핑퐁 게임은 단순하지만 고려할 사항들이 다소 있다. 이벤트가 단위로 정해지며, 시작할 때, 종료 시에는 소켓이 필요하지 않다. 하지만 게임이 일단 성립되면 Room으로 같은 공간에 유저들이 세션으로 접속하게 되며, 해당 세션을 기반으로 점수 데이터나, 공의 좌표, 키보드 입력에 따른 피드백(핸들의 이동)이 함께 들어간다. 이에 대한 내용이 하단의 내용이다.

다. 실시간 게임 플레이 (Real-time Gameplay)

  • 서버 권위적(Server-Authoritative) 아키텍처: 온라인 게임의 공정성과 보안을 보장하기 위한 표준적인 설계 패턴이다. 게임의 모든 핵심 상태(예: 공의 위치, 속도, 플레이어 점수)는 오직 서버만이 계산하고 변경할 수 있는 권한을 가진다. 이러한 아키텍처는 클라이언트 측 조작(Client-side manipulation)을 통한 어뷰징(Abusing) 및 치팅(Cheating) 행위를 원천적으로 방지하며, 각 클라이언트 간의 네트워크 지연(Network Latency) 및 시스템 환경 차이로 인한 불일치(Desynchronization) 문제를 서버가 중재하고 보정함으로써 일관된 게임 경험을 제공한다. 서버는 데이터 검증 및 상태 동기화의 중심 역할을 수행한다.

  • 동작 방식: 클라이언트는 사용자의 입력(예: 패들 이동 명령)만을 서버에 전송한다. 서버는 이 입력을 수신하여 게임 물리 엔진(Game Physics Engine)을 통해 게임 상태를 갱신하고, 갱신된 게임 상태를 모든 클라이언트에게 주기적으로 브로드캐스팅(Broadcasting)한다. 클라이언트는 서버로부터 수신한 상태 데이터를 기반으로 화면을 렌더링하는 ‘덤 클라이언트(Dumb Client)’ 역할을 수행한다. 이 구조는 클라이언트 측에서 게임 데이터를 조작하는 행위를 방지하고, 모든 플레이어가 동기화된 게임 경험을 하도록 보장한다.

  • 네트워크 및 입력 지연 보정 (Latency & Input Compensation): 프로젝트 과정에서 네트워크 환경(유선/무선) 및 하드웨어(키보드 폴링 레이트) 차이가 게임 플레이에 상당한 영향을 미친다는 점을 인지했다. 서로의 좌표가 틀어지는 큰 요인이었다. 이러한 사용자 경험(UX) 저해 요소를 해결하기 위해 다음과 같은 보정 전략을 고안해 실현시켰다.

    • 가변 프레임 렌더링 (Adaptive Frame Rate Rendering): 네트워크 송수신 상황을 실시간으로 모니터링하여, 가장 낮은 네트워크 성능을 가진 사용자에게 최적화된 좌표 검증 및 프로세싱 주기를 가변적으로 설정했다. 핵심은 유저의 단순히 일방으로 들어올 때의 시간이 아닌, 데이터가 다시 전달되는 왕복시간을 고려하고, 인간이 인지하기 편안한 24, 30, 60 프레임 단위로 렌더링 단위를 지정. 좌표를 추적하고 전달하며, 특정 클라이언트에서 스로틀링(Throttling)이 감지되면 다음 좌표 제공 이벤트 수를 자동으로 조정한다. (이와 함께 핵심인 공의 좌표 보간(Interpolation) 기능은 구현 목표였으나, 해당 단계까지는 시간 관계로 달성하지 못했다.)
    • 키 입력 처리 로직 고안 (Refined Input Handling Logic): 단순한 키 입력 수신 및 반영 방식은 네트워크 환경과 키보드 폴링 레이트(Polling Rate) 차이로 인해 사용자 경험을 저해했다. 빨리 오고 감의 차이, 누를 때마다 움직일 시 폴링 레이트에 따라 핸들의 수직 이동의 폭이 다른 점은 심각한 이슈였다. 이를 개선하기 위해 시간 및 키 입력 횟수를 비율적으로 인식하여 입력의 강도를 결정하는 로직을 독립적으로 구현했다. 이 방식은 가변적인 폴링 레이트 환경에서도 일관된 키 입력 처리를 가능하게 하며, 가변 프레임 렌더링과 함께 동작하여 모든 사용자에게 프레임은 다를 지라도 동일한 조작감을 제공해 주었다. 또한, 향후 추가적인 게임 플레이 기믹(Gimmick) 구현에도 결과적으로 추상화된 입력값의 변환은 유연성을 제공해주었다. 최종 결과로 통일된 키보드 입력 수치를 얻고, 그 얻은 것에 따라 환전된 수치가 있으니 디버깅 과정에서의 동일한 조건에서의 디버깅도 가능해진 것이었다.

🤔 성찰 및 배운 점

ft_transcendance는 웹 기술의 파편적인 지식들을 하나의 완성된 아키텍처로 엮어내는 종합적인 설계 능력을 길러준 프로젝트였다. 이 프로젝트의 끝은 그저 단순히 ‘끝’ 이 아니라, 이제는 ‘가능하다’ 라는 수식어를 쓸 수 있다는 종합적 사고의 확장이었다. 자신감, 확신이라고 해도 좋을지 모르겠다.

  • 풀스택 개발의 전체적인 시야: 데이터베이스 스키마 설계부터 백엔드 API 및 소켓 로직 구현, 그리고 프론트엔드의 상태 관리와 UI 렌더링에 이르기까지, 웹 애플리케이션 개발의 전 과정을 관통하는 경험을 통해 각 기술 요소가 어떻게 상호작용하는지에 대한 거시적인 시각을 느낄 수 있었다.
  • 실시간 시스템의 복잡성 이해: 실시간 애플리케이션은 상태 동기화, 지연 시간(Latency) 보정, 비동기 이벤트 처리 등 일반적인 웹사이트와는 차원이 다른 복잡성을 가진다는 것을 체감했다. 서버와 클라이언트 간의 수많은 메시지 흐름을 디버깅하며 문제 해결 능력을 크게 향상시킬 수 있었고, 그 결과물의 동작을 볼 땐 짜릿함을 제대로 느낄 수 있었다.
  • 컨테이너 기반 개발 워크플로우의 체화: Docker를 통한 환경 격리와 docker-compose를 이용한 서비스 오케스트레이션은, 이제는 현대적인 개발 환경에서 너무나 중요했고, 개발 협업의 효율성을 극대화하고, “내 컴퓨터에선 되는데…“라는 고질적인 문제를 해결하는 가장 확실한 방법이었고, 협업 과정에서 어디서든 어떻게든 진행한다고 할때 날개 역할을 해줌을 느낄 수 있었다.

이 프로젝트를 마침으로 나의 42서울에서의 항해기는 끝날 수 있었다. 끝은 아니었다. 여기서 보고 들은 것들, 만난 사람들은 정말로 ‘인연’이라고 생각할 수 있을 만큼 매력적인 것들이었고, 그 매력적인 것들을 묶어준 개발이라는 것은 나름의 특별한 무언가가 내 안에 되어 있었다.

1년 하고도 8개월이라는 시간을 42서울에서 보냈고, 여기서 대학 학부 과정에서 배워야할 개발의 정수를 압축해서 배우는 이 과정. 그 과정 사이사이 있었던 여러 일들 하나 하나가 나를 성장시키고, 나의 부족과, 나의 꿈, 기쁨 같은 것들을 보다 선명하게 만들어 주었다.

이제는 AI가 이러한 개발을 주도하고 있으며, 개발의 과정이나, 개발의 한계가 AI를 통해 실질 한계를 뚫는 것조차 가능해진 이 시대지만. 그럼에도 그 전의 마지막, 한땀한땀 코드와 논리를 짜는 작업은 다음 시대를 준비하는데 얼마나 큰 일을 해주었는지 모르겠다. 감사할 일이다.