이 도전 과제에 대한 브리프를 처음 읽었을 때, 제 본능은 모든 사람을 위한 무언가를 만들려고 하는 것이었습니다. 팬들은 길 안내가 필요하고, 주최 측은 감독이 필요하며, 자원봉사자들은 조정이 필요합니다. 시설 직원은 운영 데이터를 필요로 합니다. 왜 이것들을 모두 포괄하는 하나의 앱을 만들지 않을까요?

그 본능은 틀렸고, 그 이유를 파악하는 과정이 이후의 거의 모든 것을 형성했습니다.

네 가지 문제 대신 하나를 선택하기

도전 과제의 설명 세션 중 한 코멘트가 제게 깊이 남았습니다. 즉, 모든 페르소나에게 봉사하려는 앱은 결국 어느 누구에게도 제대로 봉사하지 못한다는 것입니다. 그래서 저는 범위를 좁히겠다는 의식적인 선택을 했습니다. FlowOps AI는 단 한 사람, 즉 경기장 게이트에 서서 건물 안에 8만 명의 인파 속에서 팬들이 안전하게 이동하도록 유지하려는 경기장 자원봉사자를 위해 구축되었습니다.

이 단 하나의 결정이 제품의 전체 형태를 바꾸었습니다. 일반적인 대시보드 대신, 저는 자원봉사자가 순간적으로 실제로 필요로 하는 두 가지 주제를 중심으로 초점을 맞춘 도구를 만들었습니다. 바로 군중이 어디에 모이고 있는지 아는 것과, 자신의 언어를 사용하지 않는 팬과 소통할 수 있는 능력입니다.

AI가 실제로 추론하게 만들기

'AI 기반' 앱 중 상당수는 실제로는 챗봇을 붙여 놓은 일반적인 대시보드일 뿐입니다. 저는 그 함정을 피하고 싶었기 때문에, FlowOps AI의 핵심 설계 규칙은 간단했습니다. 만약 단순한 if-else 구문으로 동일한 출력을 생성할 수 있다면, AI는 제 역할을 하고 있지 않다는 것입니다.

앱은 자원봉사자에게

이 원칙은 다국어 어시스턴트에도 동일하게 적용됩니다. 기본적인 번역 도구는 누군가 화장실 위치를 묻는지, 아니면 의료 응급 상황을 신고하는지를 전혀 신경 쓰지 않습니다. 저는 이 어시스턴트가 단순히 언어 간 단어를 바꾸는 것을 넘어, 긴급성과 톤(tone)을 파악하기를 원했습니다. 따라서 괴로워하는 팬을 돕는 자원봉사자에게 제공되는 번역 응답은, 그저 가장 가까운 음식점에 가는 길 안내만 원하는 사람을 도울 때와는 다른 종류의 응답이 되도록 설계했습니다.

심사위원(judge)이 자체 데이터를 가져오게 하기

저는 실제 경기장 센서 피드에 접근할 수 없기 때문에, 이 앱은 시간이 지남에 따라 게이트가 채워지고 비워지는 것을 모방하는 시뮬레이션된 군중 데이터 엔진을 기반으로 작동합니다. 하지만 완전히 합성된 데모는 명백한 약점을 가지고 있습니다. 평가하는 사람은 누구나 그 추론이 실제로 데이터에 반응하고 있는지, 아니면 단순히 스크립트를 읊고 있는 것인지 알 수 없습니다.

그래서 저는 '심사위원 오버라이드(Judge's Override)'라고 부른 기능을 추가했습니다. 이는 누구나 자신만의 게이트 및 시설 데이터를 업로드할 수 있게 해주는 CSV 업로드 기능입니다. 앱은 즉시 실시간 피드를 이 업로드된 데이터셋으로 교체하고, 시뮬레이터를 일시 정지한 다음, AI 추론이 방금 업로드된 무엇이든 것에 반응하도록 합니다. 이것이 설정 메뉴 깊숙한 곳에 숨겨져 있으면 안 된다는 것이 중요하다고 느꼈습니다. 왜냐하면 이 기능은 대시보드 자체에 독립적인 레이블이 붙은 제어판으로 자리 잡고 있기 때문입니다. 핵심 목적 자체가 누군가가 저의 말만 믿지 않고, 직접 추론을 테스트할 수 있어야 하기 때문입니다.

두 개의 탭을 열었을 때만 나타난 버그

제가 직면했던 가장 흥미로운 문제 중 하나는 전통적인 의미의 버그가 아니었습니다. 그것은 특정 조건 하에서만 드러나는 아키텍처 격차(architecture gap)였습니다. 바로 같은 앱에 여러 개의 브라우저 탭을 동시에 열었을 때였습니다.

각 탭은 자체적인 독립적인 군중 시뮬레이션(crowd simulation)을 실행하고 그 업데이트를 공유 데이터베이스에 직접 기록했습니다. 탭 간의 조정이 없었기 때문에, 같은 레코드에 동시에 쓰기를 하던 두 개의 티커가 겹치는 순간에 값을 급격하게 변화시켰고, 때로는 몇 초 간격으로 서로 다른 게이트들이 정확히 100% 용량에 도달하는 현상이 발생했습니다. 이는 데이터 버그처럼 보였지만, 실제로는 동시성 문제(concurrency problem)였습니다.

심판이 앱을 두 개의 장치에서 열거나, 혹은 팀원과 제가 데모를 하는 동안 둘 다 앱을 켜는 시나리오를 배제할 수 없었기 때문에, 저는 증상에 임시방편으로 패치하는 대신 아키텍처 자체를 변경했습니다. 이제 시뮬레이션 티커는 완전히 클라이언트 측(client side)에서 실행되며 공유 데이터베이스에 절대 쓰지 않습니다. 데이터베이스는 오직 심판이 업로드한 데이터를 동기화(syncing)하기 위해 전용으로 예약되었으며, 이는 의도적인 사용자 행동을 통해서만 발생합니다. 작은 변화였지만, 이로 인해 라이브 데이터베이스는 모든 열린 탭의 공유 쓰기 대상이 아니라, 실제로 동기화가 필요한 단 하나의 항목에 대한 신뢰할 수 있는 동기화 지점(sync point)이 되었습니다.

배포 계획을 변경해야 했을 때

원래 계획은 Google Cloud Run에 배포하는 것이었습니다. 하지만 클라우드 결제(Cloud Billing)에서 UPI 결제 방식을 반복적으로 거부하면서 그 계획은 무산되었는데, 알고 보니 이는 인도에 있는 많은 다른 개발자들이 겪었던 문제였습니다. 몇 번의 실패한 시도와 약간의 금전적 손실 끝에, 저는 대신 Firebase Hosting으로 전환했습니다. 이 서비스는 이러한 정적 빌드(static build)에는 결제 계정이 전혀 필요하지 않았습니다.

돌이켜보면 어쩌면 이게 더 적합했을지도 모릅니다. 앱은 이미 데이터베이스로 Firebase를 사용하고 있었기 때문에, 정적 프론트엔드도 그곳에 호스팅하는 것은 구성하고 문서화해야 할 서비스가 하나 줄어든다는 의미였으며, 실제로 앱이 필요로 하는 어떤 기능도 포기하지 않았습니다.

이런 종류의 빌드를 시작하는 사람에게 해주고 싶은 말

좁고 핵심적인 문제(narrow problem)를 선택하고 깊이 파고드는 것이 좋습니다. 넓게 여러 문제를 다루기보다는요. 여러분의 AI가 단순한 스크립트로는 절대 할 수 없는 무언가를 하도록 만드세요. 평가자들이 미리 준비된 데모에 의존하기보다, 자신들의 입력값(inputs)으로 논리를 테스트할 수 있도록 빌드해야 합니다. 그리고 인프라 계획을 세우다가 통제할 수 없는 벽에 부딪힌다면, 원래의 아키텍처에 너무 집착하지 마세요. Firebase Hosting은 처음부터 계획에 포함된 것은 아니었지만, 제가 실제로 필요했던 것들을 비용 없이 처리해 주었습니다.

전체 소스 코드와 프로젝트 시작부터 빌드를 안내한 사양 파일(specification files)을 여기에서 찾을 수 있습니다: [https://github.com/adarsh52581/FlowOps-AI]

만약 FIFA 2026이나 다른 대규모 이벤트 기술 문제에 대해 비슷한 작업을 하고 있다면, 어떤 방식으로 접근하고 있는지 듣고 싶습니다.