Omnilude를 만들기 위해 이런 백엔드를 만들고 있습니다

이 글은 기능 하나를 소개하는 글이 아닌, Omnilude라는 프로젝트가 어떤 구조 위에서 만들어지고 있는지, 그리고 왜 저는 이런 식으로 백엔드를 조직하고 있는지를 정리하는 글입니다.

제가 지금 하고 있는 일은 두 가지가 겹쳐 있습니다. 하나는 코딩 에이전트의 한계를 실험하는 일입니다. 바이브 코딩과 의식의 흐름에 가까운 지시만으로 어디까지 구현이 가능한지, 그 방식이 실제 프로덕션 수준의 개발까지 이어질 수 있는지를 계속 확인하고 있습니다. 다른 하나는 그 실험을 단지 실험으로 끝내지 않고, 결국 하나의 서비스로 이어지게 만드는 일입니다. 그 서비스의 중심에는 Omnilude가 있고, 저는 이 구조 위에서 가장 먼저 이전에 만들어보고 싶었던 게임 개발을 통해 이 실험을 진행하고 싶습니다.

그래서 이번 글은 구현 자랑보다 구조 소개에 가깝습니다. 다만 단순히 서비스 이름을 나열하는 식으로 설명하고 싶지는 않았습니다. 이 백엔드는 여러 모듈로 나뉘어 있지만, 제가 실제로 바라보는 방식은 조금 다릅니다. 저는 이 전체를 하나의 제품 백엔드로 봅니다. 인증, AI 실행, 콘텐츠 관리, 실시간 연결, 파일 저장, 이벤트 스트림이 모두 하나의 목표를 향해 묶여 있기 때문입니다.

지루하고 어려운 포스트가 될 수 있겠지만, 가능한 한 구체적으로 설명해보겠습니다.

Omnilude는 무엇을 하려는 프로젝트인가#

Omnilude는 제게 두 가지 의미를 동시에 갖습니다.

첫 번째 의미는 실험입니다. 지금 같은 시기에 개발자는 단순히 새 도구를 써보는 정도로는 충분하지 않다고 생각합니다. AI를 잘 쓰는 사람과 그렇지 않은 사람의 차이는 점점 더 커질 가능성이 높고, 그 차이는 곧 구현 속도보다 문제 정의, 구조 설계, 검증 방식에서 더 크게 벌어질 것이라고 보고 있습니다. 저는 그 변화를 관찰만 하지 않고, 실제 제품을 만들면서 몸으로 통과해보고 싶었습니다.

두 번째 의미는 아주 현실적인 제품 목표입니다. 저는 오래전부터 게임을 만들고 싶었습니다. 그리고 이제는 그 목표를 예전 방식으로만 접근하고 싶지 않습니다. AI를 적극적으로 활용하는 제작 도구, 콘텐츠 생성 파이프라인, 운영 가능한 백엔드, 그리고 실시간 경험까지 하나의 흐름으로 묶는 방식으로 접근해보고 싶습니다. Omnilude는 바로 그 방향 위에 놓인 프로젝트입니다.

즉, 이 프로젝트는 AI를 최대한 활용하기 위한 AI 에이전트 실험이면서도, 동시에 결국 출시 가능한 서비스로 수렴해야 하는 제품 개발 프로젝트입니다.

여러 서비스지만 하나의 제품 백엔드처럼 본다#

이 글을 작성하는 현재를 기준으로 Omnilude 백엔드는 아직 하나의 모놀리식 서비스입니다. 다만 저는 이 모놀리식을 단순히 큰 서버 하나로 보지 않고, 내부에 여러 책임 경계가 공존하는 구조로 보고 있습니다. 이 글에서 등장하는 auth-service, ai-service, blog-service, game-service, storage-service, backbone-service, mmorpg-service, 그리고 공통 기반인 common(jspring)은 지금 당장의 배포 단위라기보다, 제가 이 시스템을 이해하고 확장하는 기준에 더 가깝습니다. 이 글에서는 이 내부 공통 계층을 편의상 common이라고 부르겠습니다.

그래서 이 글에서 말하는 '여러 서비스지만 하나의 제품 백엔드처럼 본다'는 표현은 현재 구조를 과장해서 포장하려는 문장이 아닙니다. 오히려 하나로 붙어 있는 시스템 안에서 어떤 책임이 이미 분리되어 있고, 앞으로 어떤 방향으로 더 선명해질 수 있는지를 설명하는 관점에 가깝습니다. 중요한 것은 서비스의 개수 자체가 아니라, 각 책임이 어떤 공통 규약 위에서 하나의 제품을 향해 묶여 있는가입니다.

저는 지금의 Omnilude를 거대한 서버 하나로만 보기보다, 하나의 제품 백엔드 안에 여러 경계가 공존하는 구조로 보고 있습니다. 나중에 이 경계가 저장소와 배포 단위로 실제 분리되는 과정은 별도의 포스트로 남기려고 합니다. 이번 글에서는 현재의 모놀리식 구조 안에 이미 들어 있는 책임 분리를 현재 기준 용어로 다시 펼쳐서 설명해보겠습니다.

아래 그림은 현재의 비레거시 백엔드를 하나의 제품 백엔드처럼 다시 묶어서 본 오버뷰입니다.

이 그림에서 제가 중요하게 보는 포인트는 세 가지입니다.

첫째, common이 전체의 바닥을 이루고 있다는 점입니다. 각 서비스는 독립적으로 존재하지만, 인증 규약, 내부 HTTP 호출 방식, 이벤트 발행 방식, 스토리지 처리 방식, 분산 작업 처리 방식이 공통 기반 위에서 반복됩니다. 그래서 구조가 흩어지지 않습니다.

둘째, 제품 도메인과 운영형 인프라가 분리되어 있다는 점입니다. auth, ai, game, mmorpg, blog는 제품 기능을 대표하고, storage, backbone은 그 제품 기능이 실제 운영되기 위해 필요한 공통 기반을 맡고 있습니다.

셋째, 이 분리가 곧 AI를 쓰기 좋은 구조라는 점입니다. 코딩 에이전트는 아무 맥락 없이 거대한 코드베이스를 잘 다루지 못합니다. 반대로 역할이 나뉘고 규약이 선명한 구조에서는 훨씬 안정적으로 작동합니다. 저는 이 구조를 단지 사람이 유지보수하기 좋게 만들기 위해서만이 아니라, AI에게도 더 좋은 작업 환경을 주기 위해 설계하고 있습니다.

이 구조의 중심에는 common이 있습니다#

이 프로젝트를 이해할 때 가장 먼저 설명해야 하는 것은 common입니다. 왜냐하면 이 전체가 하나의 제품처럼 움직이는 이유가 결국 여기에 있기 때문입니다.

common은 단순한 유틸 모음이 아닙니다. 저는 이것을 내부 플랫폼 SDK에 더 가깝게 봅니다. 실제로 서비스 간 연결을 보면, 많은 것이 이미 common 안에서 표준화돼 있습니다.

• common-core는 JWT, 공통 예외, 기본 유틸 같은 가장 낮은 기반을 제공합니다.
• common-web은 내부 HTTP 클라이언트와 공통 웹 레이어 규약을 제공합니다.
• common-data는 JPA, QueryDSL, 공통 데이터 액세스 기반을 묶습니다.
• common-messaging은 이벤트 발행 경로를 통일합니다.
• common-cloud는 스토리지 커밋, 접근 URL 같은 파일 처리 연계를 표준화합니다.
• common-dte는 분산 작업과 워크플로우, Job Event 흐름을 제공합니다.

이 계층이 중요하다고 생각하는 이유는 명확합니다. 지금 같은 AI-First 개발에서는 코드를 얼마나 빨리 작성하느냐보다, 시스템이 얼마나 반복 가능한 패턴을 가지고 있느냐가 더 중요해집니다. 사람이든 에이전트든 새로운 기능을 붙일 때마다 완전히 새로운 구조를 이해해야 한다면 생산성은 금방 꺾입니다. 반대로 공통 기반이 강하면, 문제를 더 작은 단위로 나누어 맡길 수 있고, 리뷰 포인트도 명확해집니다.

예를 들어 game-service가 AI 기능을 호출할 때는 무작정 외부 모델을 직접 붙는 것이 아니라 내부적으로 ai-service를 호출합니다. 파일 저장도 각 서비스가 제각각 S3를 다루기보다 storage-service를 경유하는 방식으로 정리되어 있습니다. 이벤트는 필요한 경우 backbone-service를 중심으로 흘러갑니다. 이런 식의 일관성이 있기 때문에, 저는 AI에게도 더 정확한 지시를 줄 수 있고 결과 검증도 더 빠르게 할 수 있습니다.

개발자 입장에서도 이 구조는 중요합니다. 서비스가 많아 보이더라도, 실제로는 같은 언어와 같은 프레임워크, 같은 규약과 같은 내부 플랫폼을 공유하기 때문에 사고의 단위가 완전히 끊어지지 않습니다. 저는 이 점이 Omnilude 구조의 가장 큰 장점이라고 생각합니다.

제품 도메인은 왜 이렇게 나뉘어 있는가#

이제 각 서비스가 맡고 있는 역할을 조금 더 구체적으로 설명해보겠습니다. 단순히 서비스 이름을 나열하기보다, 왜 그렇게 나누었는지를 중심으로 보는 편이 더 중요합니다.

auth-service: 신뢰의 시작점#

auth-service는 로그인과 계정, 디바이스, 권한, 크레딧, 활동 로그를 담당합니다. 겉으로는 비교적 익숙한 인증 서버처럼 보일 수 있지만, 저는 이 서비스를 단순한 로그인 API로 생각하지 않습니다. 이 서비스는 제품 전체의 신뢰 경계를 담당합니다.

사용자가 누구인지, 어떤 세션을 가지고 있는지, 어떤 권한이 있는지, 어떤 크레딧이나 사용 이력이 있는지는 대부분 여기서 출발합니다. 다른 서비스가 더 빠르게 기능을 실험하고 붙일 수 있으려면, 이런 기초 신뢰 계층은 오히려 더 보수적이고 명확해야 합니다.

그리고 흥미로운 점은 이 서비스가 완전히 고립돼 있지 않다는 것입니다. 기동 시점에는 backbone-service와 플랫폼 설정을 동기화하고, 전체 백엔드의 공통 JWT 규약을 함께 형성합니다. 즉, 인증은 독립된 기능이면서 동시에 전체 시스템의 연결 언어이기도 합니다.

ai-service: AI 실행의 허브#

ai-service는 이 프로젝트에서 가장 상징적인 서비스입니다. LLM 호출, 멀티 에이전트 워크플로우, 미디어 생성, 상품 에이전트, 롤플레잉, 각종 시스템성 AI API가 여기에 모여 있습니다.

중요한 것은 이 서비스가 단순히 외부 모델 API를 프록시하는 역할이 아니라는 점입니다. 저는 이 서비스를 AI 실행 허브로 보고 있습니다. 즉, 어떤 모델을 부를지, 어떤 워크플로우를 거칠지, 어떤 이벤트를 발생시킬지, 어떤 결과물을 저장할지, 어떤 진행 상황을 외부에 스트리밍할지를 결정하는 중심 계층입니다.

이 구조는 앞으로 더 중요해질 것이라고 생각합니다. AI를 적극적으로 활용하는 프로젝트일수록 외부 모델 호출이 여기저기 퍼지면 금방 통제가 어려워집니다. 비용, 실패 처리, 프롬프트 규약, 실행 기록, 결과 저장, 제공자 교체 전략까지 생각하면 오히려 AI는 한 곳에서 조율되는 편이 낫습니다. ai-service는 바로 그 역할을 맡고 있습니다.

game-service: 제가 가장 먼저 현실화하고 싶은 도메인#

game-service는 이 프로젝트의 핵심 제품 도메인입니다. 시나리오, 스토리 퀴즈, 게임 세션, 공통 게임 메타, 에셋 스튜디오 같은 기능이 이곳에 모여 있습니다.

이 서비스가 중요한 이유는 단순합니다. 저는 Omnilude에서 가장 먼저 출시하고 싶은 것이 결국 이 영역과 이어져 있기 때문입니다. 그래서 이 서비스는 단순한 데이터 저장소가 아니라, AI와 가장 많이 상호작용하는 도메인으로 설계되고 있습니다. 시나리오를 만들고, 자산을 생성하고, 세션을 만들고, 플레이 흐름을 운영하는 과정이 모두 이쪽에 모입니다.

특히 game-service가 ai-service와 직접 맞닿아 있다는 점이 중요합니다. 콘텐츠 생성과 검수, 보조 작업, 에셋 제작, 일부 자동화 흐름은 결국 AI를 통해 가속될 수밖에 없습니다. 저는 이 연결을 억지로 숨기기보다, 아예 구조적으로 드러내는 편이 더 좋다고 봤습니다.

mmorpg-service: 실시간 런타임은 별도 축으로 본다#

mmorpg-service는 같은 게임 영역 안에 있지만, 성격이 많이 다릅니다. 이 서비스는 HTTP 기반 관리 API만 있는 것이 아니라 별도 게이트웨이 포트에서 실시간 WebSocket 런타임을 운영합니다.

왜 이걸 같은 서비스로 섞지 않았느냐고 물으면 대답은 분명합니다. CRUD 중심의 콘텐츠 API와 실시간 게임 서버는 실패 방식도, 성능 요구도, 상태 관리 방식도 완전히 다르기 때문입니다. 저는 이 둘을 같은 사고 단위로 다루지 않는 편이 더 맞다고 생각했습니다.

실제로 인증 방식도 흥미롭습니다. 실시간 연결 시점에는 auth-service가 발급한 JWT 규약을 mmorpg-service 내부 게이트웨이에서 로컬 검증합니다. 즉, 런타임에서 매번 인증 서비스를 HTTP로 재호출하지 않습니다. 이런 구조는 실시간 시스템이 일반 비즈니스 API와 어디서 갈라져야 하는지를 잘 보여줍니다.

blog-service: 프로젝트의 외부 기억 장치#

blog-service는 상대적으로 덜 복잡해 보일 수 있지만, 저에게는 중요한 위치를 갖습니다. 이 서비스는 단지 블로그를 운영하기 위한 CMS가 아닙니다. 지금 무엇을 만들고 있고, 어떤 판단을 했고, 어떤 실험을 하고 있는지를 외부에 축적하는 통로입니다.

Omnilude가 단지 내부에서만 돌아가는 프로젝트가 아니라면, 구조와 실험과 시행착오가 외부에 설명 가능해야 합니다. blog-service는 그 기록을 담당합니다. 포스트, 댓글, 번역, SEO, 정적 자산 연결 같은 기능이 이곳에 모여 있는 이유도 결국 제품의 외부 커뮤니케이션 계층이 필요하기 때문입니다.

운영형 인프라는 왜 따로 세웠는가#

제품 기능만으로 서비스는 운영되지 않습니다. 결과물을 저장하고, 파일 생명주기를 관리하고, 진행 상태를 스트리밍하고, 이벤트를 흘리고, 장시간 실행 작업을 추적하고, 실시간 연결을 유지하는 계층이 반드시 필요합니다.

Omnilude에서는 그 역할을 주로 storage-service와 backbone-service가 맡고 있습니다.

storage-service: 파일의 진짜 수명은 여기서 관리된다#

많은 프로젝트에서 파일 저장은 나중에 덧붙여지는 기능처럼 다뤄집니다. 하지만 실제 제품 운영에서는 파일 업로드, 임시 상태, commit/cancel, 접근 URL, 썸네일 URL, 정적 객체 메타가 모두 중요합니다. 파일은 단순히 올리고 끝나는 것이 아니라 수명주기를 갖습니다.

그래서 저는 storage-service를 별도로 두었습니다. 블로그의 이미지든, AI가 만든 결과물이든, 게임 자산이든 가능한 한 이 경로로 통합하려고 했습니다. 이렇게 하면 어떤 서비스가 파일을 다루더라도 공통된 규칙 위에서 동작할 수 있습니다. 나중에 접근 정책이나 저장소 전략이 바뀌더라도 영향 범위를 좁힐 수 있다는 장점도 있습니다.

backbone-service: 운영과 비동기의 중심#

backbone-service는 이름 그대로 백본에 가깝습니다. 이벤트 허브, SSE, WebSocket, 플랫폼 설정, DTE Job 이벤트 흐름이 이쪽에 모입니다.

이 서비스가 특히 중요한 이유는 AI 실행과 잘 맞물리기 때문입니다. 지금 만들고 있는 기능 중 상당수는 단순한 동기 API 하나로 끝나지 않습니다. 사용자가 작업을 시작하면, 중간 진행 상태가 필요하고, 완료 시점 이벤트가 필요하고, 경우에 따라 실시간 연결이나 알림이 필요합니다. 이런 요구를 매번 각 도메인 서비스가 개별적으로 해결하기 시작하면 구조가 빠르게 지저분해집니다.

저는 그래서 비동기 전달과 운영형 실시간 계층을 backbone으로 모았습니다. 이벤트 발행의 기본 경로를 HTTP -> backbone -> Kafka/RabbitMQ 식으로 정리하고, DTE 관련 진행 상황은 SSE로 흘리도록 묶는 접근이 더 관리 가능하다고 보고 있습니다.

아래 플로우는 AI 생성 작업이 실제로 어떤 식으로 이어지는지를 단순화해서 보여줍니다.

이 구조를 좋아하는 이유는 명확합니다. 생성의 책임은 ai-service가 가지고, 결과 저장은 storage-service가 맡고, 진행 상태의 외부 전달은 backbone-service가 맡습니다. 책임이 분리돼 있기 때문에 각각을 더 명확하게 검증할 수 있습니다.

데이터 저장소와 메시징 계층은 이렇게 쓴다#

구조를 더 입체적으로 보려면 저장소와 메시징 계층도 함께 봐야 합니다. 현재 Omnilude의 비레거시 백엔드는 인프라를 마구 섞어서 쓰지 않습니다. 각 계층이 맡는 역할이 꽤 분명합니다.

• PostgreSQL은 거의 모든 서비스의 기본 영속 저장소입니다. auth, ai, blog, game, storage, backbone, mmorpg가 모두 이 축을 공유합니다.
• Redis는 단순 캐시보다 Pub/Sub와 세션성 이벤트 전달 비중이 더 큽니다. 그래서 여러 서비스에 넓게 깔려 있지만 사용 목적은 꽤 전략적입니다.
• Cassandra는 현재 auth-service와 backbone-service 쪽의 활동 로그, 이벤트성 쓰기 계층에 더 가깝습니다. 모든 서비스가 무분별하게 붙지 않도록 경계가 있습니다.
• Kafka와 RabbitMQ는 실질적으로 backbone-service가 중심에서 다룹니다. 다른 서비스가 직접 메시지 브로커에 달라붙기보다, 우선 backbone으로 이벤트를 보내고 backbone이 이를 외부 메시징 계층으로 전파하는 구조입니다.
• S3는 storage-service가 직접 다루고, 다른 서비스는 가능하면 이를 경유합니다. 파일을 다루는 규칙을 한 곳에 묶기 위한 선택입니다.

이 접근은 처음에는 다소 돌아가는 것처럼 보일 수 있습니다. 하지만 저는 오히려 이런 분리가 장기적으로 훨씬 중요하다고 생각합니다. 기능 서비스가 직접 저장소와 메시징을 모두 떠안기 시작하면, 시간이 지날수록 책임 경계가 빠르게 흐려지기 때문입니다. 반대로 지금처럼 인프라 접근을 어느 정도 관문 서비스로 정리해두면, 나중에 운영 정책이 바뀌거나 장애 지점을 좁혀야 할 때 훨씬 유리합니다.

AI를 활용하는 입장에서도 이 구조는 장점이 큽니다. 에이전트에게 어떤 기능을 맡길 때, 이 기능이 어디까지 직접 처리하고 어디서 공통 경로를 써야 하는지만 명확하면 결과가 훨씬 안정적입니다.

인증된 요청과 실시간 연결은 왜 다른 방식으로 가는가#

Omnilude의 구조를 더 구체적으로 이해하려면, 동기 요청과 실시간 연결을 따로 보는 편이 좋습니다.

일반적인 콘텐츠 조회나 관리 작업은 대부분 auth-service에서 로그인한 뒤, 도메인 API를 호출하는 흐름을 따릅니다. 이 경우 중요한 것은 공통 JWT 규약과 권한 체계가 유지되는가입니다. blog-service, game-service, ai-service는 이 공통 규약을 공유하기 때문에 사용자는 서비스가 나뉘어 있어도 상대적으로 일관된 경험을 갖게 됩니다.

반면 실시간 연결에서는 요구사항이 달라집니다. 특히 mmorpg-service는 별도 게이트웨이 포트인 :9088/ws를 사용합니다. 사용자는 이미 auth-service에서 발급된 토큰을 가지고 있고, 게이트웨이는 이를 로컬에서 검증합니다. 매번 인증 서버에 왕복하지 않고도 세션을 빠르게 수립하기 위한 구조입니다.

아래 흐름은 그 차이를 보여줍니다.

이 차이는 생각보다 중요합니다. 저는 이 구조를 통해 일반 비즈니스 API, 장시간 AI 작업, 실시간 게임 세션이 모두 다른 무게중심을 가져야 한다는 점을 명확하게 드러내고 싶었습니다. 모든 것을 하나의 방식으로 통일하는 것이 단순해 보일 수는 있어도, 실제 운영에서는 오히려 문제를 키우는 경우가 많기 때문입니다.

이 구조가 AI-First 개발과 어떻게 연결되는가#

여기까지 읽으면 이런 질문이 생길 수 있습니다. 결국 왜 이런 구조가 AI를 잘 쓰는 것과 연결되는가 하는 질문입니다.

저는 이 질문이 아주 중요하다고 생각합니다. 왜냐하면 지금 많은 개발자들이 AI를 단순히 코드를 대신 써주는 도구 정도로만 보고 있기 때문입니다. 하지만 실제로 생산성이 큰 폭으로 좋아지는 구간은, 단순히 더 많은 코드를 생성하는 시점이 아니라 AI가 이해하기 좋은 구조를 시스템 차원에서 갖추기 시작할 때라고 생각합니다.

예를 들어 생각해보면,

• 역할이 모호한 거대한 서비스 하나보다 책임이 나뉜 서비스 묶음이 프롬프트 분할에 유리합니다.
• 공통 규약이 없는 코드베이스보다 common처럼 내부 플랫폼이 있는 구조가 에이전트에게 훨씬 안정적인 맥락을 제공합니다.
• 파일 처리, 이벤트 처리, AI 실행, 실시간 연결이 분리돼 있으면 어떤 문제가 어느 경계에서 발생했는지 추적하기 쉽습니다.
• 사람이 마지막에 검토해야 할 포인트도 더 선명해집니다.

결국 AI-First 개발은 AI를 많이 붙이는 개발이 아니라, AI가 더 일관되게 일할 수 있도록 시스템을 정리하는 개발에 가깝습니다. 저는 Omnilude를 만들면서 바로 그 지점을 실험하고 있습니다.

이 점에서 저는 지금 개발자들에게 필요한 것이 새 모델 소식 자체보다 훈련이라고 생각합니다. 더 좋은 프롬프트를 쓰는 훈련만이 아니라, 더 나은 구조를 만들고, 더 좋은 기준으로 검토하고, AI가 일할 수 있는 맥락을 설계하는 훈련 말입니다. 저는 이 프로젝트가 결국 그런 훈련의 결과물이어야 한다고 보고 있습니다.

결국 목적지는 Omnilude 출시입니다#

이 글이 구조 소개에 머무르지 않았으면 하는 이유가 하나 있습니다. 이 구조는 설명을 위한 구조가 아니라, 결국 실제로 출시할 무언가를 만들기 위한 구조이기 때문입니다.

제가 지금 하고 있는 일은 AI 기반 제작 도구를 만들고, 그 위에서 게임 플랫폼을 구현하는 일입니다. 이 백엔드는 그 두 흐름이 만나도록 설계되고 있습니다. AI가 콘텐츠 제작을 밀어주고, 게임 도메인이 그것을 제품 경험으로 바꾸고, 운영형 인프라가 그 전체를 실제 서비스 수준으로 끌어올리는 방향입니다.

저는 만들어진 게임을 출시하고 싶습니다. 그리고 그 과정이 단지 감각과 열정만으로가 아니라, 더 나은 구조와 더 빠른 실험, 더 정확한 검증 위에서 가능해질 수 있는지를 직접 확인해보고 싶습니다. Omnilude는 제게 그런 기대가 모이는 프로젝트입니다.

그래서 앞으로 이 블로그에서는 단순히 아키텍처만 이야기하지 않을 생각입니다. 어떤 기능이 실제로 붙고 있는지, 어디까지 AI가 밀어주고 있는지, 사람은 어디서 판단해야 하는지, 그리고 이 구조가 정말 출시 가능한 제품으로 이어지는지를 계속 기록해보려고 합니다.

지금의 저는 백엔드 구조를 소개하고 있지만, 마음속에서 더 중요하게 보고 있는 질문은 하나입니다. 이 방식으로 정말 끝까지 갈 수 있는가.

저는 그 답을 말로만 하지 않고, Omnilude를 실제로 만들면서 확인해보려고 합니다.