StoryToys는 모든 연령대의 아이들에게 교육용 앱을 제공한다는 사명 아래 2008년에 설립되었습니다. 지난 17년 동안 이들은 Hungry Caterpillar Play School, LEGO® DUPLO® World, Disney Coloring World, LEGO® DUPLO® Peppa를 포함한 앱들을 출시해 왔습니다. 이들의 최신 타이틀인 LEGO® Bluey는 2025년 8월 14일에 출시되었습니다. LEGO Group 및 BBC Studios와의 협업을 통해 개발된 이 앱은 2세에서 4세 사이의 아이들을 대상으로 하며, 재미와 초기 학습을 결합했습니다. 우리는 StoryToys의 수석 엔지니어(Principal Engineer)인 Devon Wolfgang 및 이 앱의 리드 개발자(Lead Developer)인 Ryan Dykes와 함께 다양한 연령과 운동 기술(Motor skills), 정서 지능(Emotional intelligence), 문제 해결 능력(Problem-solving), 유머 감각을 가진 아이들을 위한 앱을 설계할 때 겪었던 어려움과 이정표에 대해 이야기를 나누었습니다.

앱을 구축할 때 가장 큰 기술적 과제는 무엇이었나요?

Ryan Dykes: 2세와 4세 모두를 위해 설계하는 것은 독특한 도전이었습니다. 그 정도로 어린 아이들은 앱과 상호작용하는 방식이 매우 다릅니다. 2세 아이들은 종종 메커니즘을 완전히 이해하지 못한 채 탭(Tapping)을 통해 탐색하는 반면, 4세 아이들은 메커니즘을 숙달하는 것을 목표로 합니다. 예를 들어, 서핑 활동에서 어린 플레이어들은 Bluey가 움직이고 반응하는 것을 보기 위해 탭을 할 수 있지만, 더 큰 아이들은 모든 조개를 모으고 장애물을 피하려고 노력할 것입니다.

Devon Wolfgang: 우리는 그러한 발달 범위를 지원하도록 앱을 설계했습니다. 2+ LEGO DUPLO 경험에서는 브릭(Brick) 쌓기가 2D로 제한됩니다. 4+ LEGO 플레이 팩에서는 완전한 3D 쌓기를 도입하여, 아이들이 브릭을 자유롭게 회전하고 배치할 수 있게 함으로써 모두에게 재미를 유지하면서도 난이도를 높였습니다.

Ryan: 단계적 발전이 핵심입니다. 2+ LEGO DUPLO 모드는 2.5D 평면을 사용하는 반면, 4+ LEGO 플레이 팩은 등각 투영 3D(Isometric 3D) 공간으로 이동합니다. 우리는 기술이 자연스럽게 쌓이기를 원했습니다. 아이들이 더 단순한 모드에서 배우는 것은 모순 없이 고급 모드로 이어집니다.

이것은 Unity의 물리 기반 침투 테스트(Physics-based penetration testing)를 사용하여 완전한 3D 브릭 쌓기를 구현한 우리의 첫 사례였습니다. 이전에는 폴리곤 콜라이더(Polygon colliders)가 있는 2D 매트릭스를 사용했습니다. 이제 브릭은 회전하거나, 쌓거나, 심지어 가장자리에 걸쳐 있을 수도 있습니다.

이는 연령이 높은 아이들에게 특히 중요합니다. 주요 과제 중 하나는 고정된 브릭 배치에서 유연한 시스템으로 전환하는 것이었습니다. 이로 인해 미니피겨 (minifigs)가 다른 미니피겨 위에 서 있는 동안 브릭을 잡고 있거나, 역동적인 더미가 사방으로 던져지는 것과 같은 복잡한 상호작용 (interactions)이 도입되었습니다. 이는 플레이어에게 자유를 주었지만, 혼란을 방지하기 위해 펙 (pegs), 홀 (holes), 그리고 스냅 메커니즘 (snapping mechanics)에 대한 정밀한 제어가 필요했습니다.

질문: 연령대별로 입력 (input)에 대한 커뮤니케이션을 어떻게 처리했나요?

Ryan: 저희는 빛나는 프롬프트 (prompts)나 완전한 가이드와 같은 직접적인 지시를 피합니다. 대신, 흔들림이나 애니메이션 (animations)과 같은 미묘한 시각적 신호 (visual cues)를 사용하여 상호작용을 유도합니다. 목표는 아이들이 스스로 무언가를 발견하도록 하는 것입니다. 예를 들어, 자동차 위에 브릭을 쌓을 때 브릭을 탭 (tapping)하면 미니피겨가 그것을 집어 들고, 자동차를 탭하면 그 자리에 놓게 됩니다. 시간이 지나면서 아이들은 브릭을 직접 드래그 (drag)할 수 있다는 것을 깨닫게 됩니다. 이는 실험을 통해 이해를 구축하는 과정이며, 바로 이 지점에서 시각적 커뮤니케이션이 필수적이 됩니다.

Devon: 저희는 또한 '텍스트 금지'라는 확고한 규칙을 세웠습니다. 저희 사용자들은 아직 글을 읽을 수 없기 때문에, 모든 상호작용은 시각적으로 또는 애니메이션을 통해 전달되어야 합니다. 신호 (cues)는 정답을 강조하는 것이 아니라, 무엇이 상호작용 가능한지만 보여줍니다.

Ryan: 그리고 경험의 일관성을 유지하기 위해, Unity의 드래그 (drag), 탭 (tap), 클릭 (click) 이벤트 주변에 커스텀 터치 입력 래퍼 (touch input wrapper)를 만들었습니다. 이를 통해 팀 전체에서 입력 처리 (input handling)를 표준화했으며, 프로토타이핑 (prototyping)을 더 빠르고 신뢰성 있게 만들 수 있었습니다. 한 활동에서 탭하기를 가르쳤다면, 다른 모든 곳에서도 동일하게 작동해야 합니다.

질문: 시스템 브릭과 LEGO DUPLO 브릭을 동일한 앱 내에서 결합할 때 어떤 어려움이 있었나요?

Devon: 기술적인 문제보다 디자인적인 과제가 더 어려웠습니다. 예를 들어, LEGO DUPLO 캐릭터를 사용하는 것이 시스템 브릭과 어울리지 않았기 때문에 로딩 화면을 재설계해야 했습니다. 공유된 시스템을 사용하면서도 시각적 언어 (visual language)를 뚜렷하게 유지하는 데에는 많은 반복 작업 (iteration)이 필요했습니다.

Ryan: 저희는 LEGO DUPLO와 미니피겨 시스템을 동일한 핵심 코드베이스 (core codebase) 아래 통합했습니다. 오직 비주얼 (visuals)만 다를 뿐입니다.

이를 통해 별도의 앱을 구축하지 않고도 시스템을 재사용할 수 있었으며, 이는 지속 가능성 (sustainability) 측면에서 핵심적이었습니다.

Unity가 8주의 개발 기간을 맞추는 데 어떻게 도움이 되었나요?

Ryan: 프리팹 (Prefabs)이 결정적이었습니다. LEGO DUPLO 브릭의 경우, 각 개발자가 런타임 (runtime)에 로드되는 별도의 씬 (scenes)에서 작업했습니다. 4+ LEGO 플레이 팩의 경우, 프리팹 덕분에 여러 팀원이 자동차나 애니메이션 같은 서로 다른 부분에서 씬 충돌 없이 협업할 수 있었습니다.

개발 과정에서 어드레서블 (Addressables)이 어떤 역할을 했나요?

Devon: 저희는 어드레서블 (Addressables)에 크게 의존했습니다. 각 플레이 팩은 어드레서블 번들 (Addressable bundles)의 그룹이며, 대부분 원격으로 로드됩니다.

Ryan: 이전에는 플레이 팩당 모든 에셋을 번들로 묶었기 때문에 크고 중복된 다운로드가 발생했습니다. 어드레서블 (Addressables)을 사용하면 Bluey 모델과 같은 공유 에셋을 한 번만 저장하고 재사용할 수 있어, 다운로드 크기를 200MB에서 60MB로 줄일 수 있었습니다. 변경된 파일만 다시 다운로드하기 때문에 업데이트도 더 빠릅니다.

Devon: 빌드 (Builds) 시간이 예전에는 8시간이 걸렸습니다. 하지만 이제 어드레서블 (Addressables) 덕분에 작은 앱은 20분, 큰 앱은 약 1시간 정도로 단축되었습니다.

이 프로젝트에서 Unity Navigation은 어떻게 사용되었나요?

Ryan: 기존의 2D 내비게이션 (navigation) 시스템도 잘 작동했지만, 새로운 시스템은 더 복잡한 구현을 가능하게 합니다. 이제 미니피겨 (minifigs)가 좁은 다리를 올라가는 것처럼 평면을 벗어나 이동할 수 있어, 깊이감과 유연성이 더해졌습니다.

성능 관련하여 어떤 문제들을 겪었나요?

Ryan: 주요 과제 중 하나는 드로우 콜 (draw calls)이었습니다. 셰이더 (shader) 변경으로 인해 배칭 (batching)이 깨지면서 드로우 콜이 500개를 넘어섰습니다. Unity의 프로파일러 (Profiler)와 프레임 디버거 (Frame Debugger)를 사용하여 빠르게 문제를 추적했고, 재질 (materials)이 제대로 배칭되도록 셰이더를 수정했습니다. 또한 배경을 정적 (static)으로 표시하여 최적화했습니다.

저희는 덤불과 같은 배경 요소들이 아틀라스 (atlased) 처리되지 않아 불필요한 드로우 콜이 발생하는 것을 발견했습니다. Unity의 스프라이트 아틀라스 (sprite atlas) 시스템을 사용하여 Photoshop 없이도 이들을 그룹화할 수 있었고, 드로우 콜을 약 200개까지 낮추었습니다.

다양한 연령대와 발달 단계의 아이들을 위한 앱을 만들고자 하는 개발자에게 어떤 조언을 해주고 싶나요?

Devon: 플레이테스트 (Playtest)를 빠르고 자주 진행하세요.

대상 연령대의 아이들이 가능한 한 빨리 여러분의 작업물과 상호작용하게 만드세요. 가설에 의존하지 말고, 아이들의 반응을 즐기세요. 그 반응은 가치 있으면서도 재미있습니다.

Ryan: 결과물 (Deliverables)의 기준을 조기에 설정하세요. 저희는 P1/P2/P3 시스템을 사용합니다. P1은 필수 요소 (코어 루프, Core loop)이고, P2는 완성도를 높이는 요소 (예: 축하 효과, 보조 애니메이션), P3는 있으면 좋은 요소 (예: 물고기가 뛰어오르는 것과 같은 것)입니다. 이렇게 하면 작업량을 줄여야 할 때 집중력을 유지할 수 있습니다.

명확한 프로젝트 구조도 그만큼 중요합니다. LEGO DUPLO의 경우, 4개의 장면과 마스터 장면(Master scene)으로 구성된다는 것을 알고 시작합니다. 4+ LEGO 플레이 팩의 경우, 박스 영역 내의 아이소메트릭 (Isometric) 방식입니다. 이러한 제약 사항은 창의성을 집중시키고 범위 확장 (Scope creep)을 방지하는 데 도움이 됩니다.

마지막으로, 재사용성 (Reusability)이 핵심입니다. 터치 입력과 같은 공유 시스템과 DUPLO 및 시스템 브릭 (System bricks)을 위한 통합 코드를 통해, 저희는 모든 플레이 팩 전반에 걸쳐 에셋 (Assets)과 동작을 재사용합니다. 이는 시간을 절약하고 사용자 경험 (User experience)을 더욱 일관되게 만듭니다.

Unity로 제작된 프로젝트에 대해 더 자세히 알고 싶다면, 리소스 (Resources) 페이지를 방문하세요.