프로젝트 시작

첫날이 렌더링 기초부터 시작되는 이유

이것은 플랫폼 공개 기록의 첫날입니다. "채팅을 하면 게임이 나타나는" 플랫폼의 경우 맨 아래에서 한 가지 사실이 유지되어야 합니다. 즉, 브라우저는 진정성 있고 안정적으로 3D를 렌더링해야 합니다. 그래서 첫날은 화려한 인터페이스를 쌓는 것이 아니었습니다. 가장 어려운 부분인 렌더링 기반에 모든 노력을 기울였습니다. 기성 일반 라이브러리를 래핑하는 대신 브라우저의 차세대 그래픽 기능(WebGPU)에 직접 렌더링 파이프라인을 사내에서 구축하는 것입니다. 그 길은 처음에는 더 힘들고 느립니다. 다른 사람들이 포장해 놓은 많은 세부 사항을 스스로 살펴보고 함정을 하나씩 채워야 합니다. 그러나 업스트림 라이브러리의 장단점에 의해 제한되는 대신 이미지 품질, 성능 및 기능을 나중에 우리 손에 맡길지 여부를 결정합니다. 오늘의 결과물은 "브라우저에서 첫 번째 픽셀을 올바르게 조명하는 것"이라는 하나의 큰 일의 정말 다른 면입니다. 가장 과소평가되고 가장 타협하기 어려운 것을 먼저 견고하게 하는 것이 "대화를 통해 게임을 만드는 것"이라는 모든 이후의 꿈을 설 수 있는 자리를 제공합니다.

작동하는 셰이더 파이프라인: WGSL + 셰이더 컴파일 심 + 단순화된 PBR

렌더링의 핵심은 GPU에 "각 픽셀의 색상이 무엇인지" 알려주는 작은 프로그램인 셰이더입니다. 오늘은 브라우저 그래픽 표준의 셰이더 언어(WGSL)로 작성되고 셰이더 소스를 GPU 실행 가능 형식으로 변환하는 컴파일 심과 단순화된 PBR(물리 기반 셰이딩) 구현을 결합하여 전체 셰이더 파이프라인을 함께 연결했습니다. "물리적 기반"은 재료가 실제 규칙에 따라 빛에 반응한다는 것을 의미합니다. 즉, 금속은 금속처럼 보이고 플라스틱은 플라스틱처럼 보이며 색종이 컷아웃이 아닙니다. 이 단순화된 PBR은 의도적으로 간결한 리소스 바인딩 구조(단 3개의 바인딩 그룹)를 사용하여 이미지를 믿을 수 있게 유지하면서 가벼운 상태를 유지합니다. 즉, 이해하기 쉽고 확장하기 쉽습니다. 특히 컴파일 심이 중요합니다. WebGPU는 높은 수준의 셰이더 소스를 직접 사용하지 않으므로 그 사이에 낮은 수준의 형식으로 변환하는 단계가 필요하며 브라우저에서 이를 해결하면 "셰이더를 작성하고 즉시 결과를 확인"할 수 있습니다. 오늘부터 엔진은 더 이상 삼각형에만 색조를 입히지 않습니다. 조명이 있고 재료가 있는 개체를 렌더링합니다. "그리기 가능"에서 "올바른 그리기"까지의 주요 첫 번째 단계이며, 더 풍부한 재료와 조명을 위한 올바른 시작점이 됩니다.

렌더링 장치 계층이 끝에서 끝까지 이어집니다.

셰이더를 실행하려면 GPU 리소스 요청, 캔버스 표면 관리, 각 프레임의 그리기 명령 구성 및 GPU에 제출 등 모든 것을 처리하는 "렌더링 장치 레이어"가 있어야 합니다. 이날은 해당 레이어를 처음부터 끝까지 완전히 덮어 초기 설정부터 프레임 이후 안정적인 생산까지 일련의 이정표가 모두 완료되는 전체 체인을 단계별로 검증했습니다. 플레이어는 이 레이어를 볼 수 없지만 모든 렌더링의 관리자입니다. 레이어가 솔리드이면 그 위에 있는 게임도 솔리드입니다. 구멍이 있으면 가장 아름다운 효과라도 무작위로 꺼지거나 충돌합니다. 많은 렌더링 문제는 표면의 깨진 효과처럼 보이지만 실제로는 이 레이어가 정리되지 않은 것이 근본 원인입니다. 이를 단계적으로 검증 가능하게 만드는 것은 장기적인 이점도 있습니다. 향후 프레임이 잘못되면 검은 화면을 무기력하게 쳐다보는 대신 이러한 이정표를 추적하여 어떤 링크가 끊어졌는지 확인할 수 있습니다. 튼튼하게 만드는 것은 먼저 앞으로 나올 모든 렌더링 기능에 대해 신뢰할 수 있는 트랙을 마련하는 것입니다.

첫 번째 교차 환경 장애물: GPU 메모리 수명 주기 핫픽스

다양한 환경에서 WebGPU를 실행하는 GPU 메모리 버퍼는 "사용 가능한 시기, 반환 시기"에 대한 엄격한 수명 주기 규칙을 따릅니다. 타이밍이 잘못 정렬되면 더티 데이터가 절반만 읽혀지거나 완전히 충돌이 발생합니다. 오늘은 "매핑된 읽기/쓰기" 단계에서 버퍼 수명주기를 핫픽스하여 완전히 다른 두 가지 환경에서 규칙을 따르도록 했습니다. 하나는 개별 GPU 없이 렌더링이 순수하게 소프트웨어에서 시뮬레이션되는 환경이고, 다른 하나는 브라우저가 시스템의 기본 그래픽을 직접 호출하는 환경입니다. 동일한 코드가 두 경로 모두에서 정확하려면 GPU 메모리의 모든 할당 및 반환 타이밍이 정확히 맞아야 합니다. 이러한 수정 사항은 "눈에 보이는 새로운 기능"을 제공하지 않지만 엔진이 "가끔 내 컴퓨터에서 실행되는 장난감"인지 "다른 컴퓨터 및 다른 환경에서도 실행되는 기반"인지를 정확하게 결정합니다. 내부 렌더러 비용의 상당 부분은 환경 간 불확실성을 한 번에 한 구멍씩 연결하는 작업에 사용됩니다. 각각 연결하면 플랫폼이 안정적으로 처리할 수 있는 장치의 범위가 넓어집니다.

안전한 동시성: 에이전트별 수명 주기 잠금

플랫폼의 다른 측면은 귀하와 채팅하고 작업을 수행하는 에이전트입니다. 처음부터 이 플랫폼은 "한 번에 작업하는 에이전트 팀"을 구상합니다. 즉, 한 번에 한 명의 어시스턴트와 대화하는 대신 리드가 작업을 전달하고 하위 에이전트가 각각 한 조각씩 가져가는 것입니다. 그러나 여러 에이전트가 동시에 실행되는 순간 고전적인 "경합 조건"이 나타납니다. 즉, 두 가지 작업이 보장된 순서 없이 거의 동일한 순간에 동일한 에이전트의 상태에 닿아 간헐적으로 손상되거나 중단되는 현상이 발생합니다. 오늘은 각 에이전트의 수명 주기 관리를 전용 "비동기 잠금" 구성 요소로 추출했습니다. 동일한 에이전트에 대한 작업(시작, 중지, 전환)은 해당 잠금을 통해 대기열로 직렬화되어 언제든지 단 하나의 작업만 해당 상태에 닿도록 보장합니다. 이를 통해 많은 에이전트를 실행하는 것은 더 이상 서로 밟는 것을 의미하지 않으며 동작을 예측할 수 있게 됩니다. "다중 에이전트 협업"을 핵심 약속으로 취급하는 플랫폼의 경우 이 잠금 장치는 데모에만 머무르지 않고 청사진이 실제로 착륙할 수 있도록 하는 핵심 요소입니다.

더 견고한 터미널: 붙여넣기가 충돌하지 않음 + 협업 지침

동시성 안전성 외에도 채팅 에이전트는 두 가지 "일상적인 느낌" 수정 사항을 얻었습니다. 첫째, 터미널 입력: 이전의 "두 번째 붙여넣기 정지" 버그가 수정되어 명령줄에 긴 요구 사항 텍스트를 붙여넣는 것이 더 탄력적으로 만들어졌습니다. 전체 설정 블록이나 긴 사양을 붙여넣으면 중단되지 않습니다. 둘째, 협업 커뮤니케이션: 에이전트가 서로 메시지를 보내는 데 사용하는 도구에는 구체적인 사용 시나리오와 응답 지침이 있으므로 "누가 누구에게, 언제, 어떻게 메시지를 보내야 하는지" 구조가 있고 다중 에이전트 협업 중 커뮤니케이션이 임시적이지 않습니다. 이것이 "사용하기 어색하지 않은" 핵심 세부 사항입니다. 요구 사항을 붙여넣을 때 충돌이 발생하거나 협업할 때 옹알이가 떨어지는 어시스턴트는 아무리 똑똑해도 신뢰할 수 없습니다. 이러한 거친 가장자리를 하나씩 다듬어야만 실제 작업을 할 수 있는 작업이 됩니다.

낭비되는 캐시 없음: 동적 알림이 새 메시지를 추가합니다.

대규모 모델과 대화할 때 안정적인 컨텍스트를 미리 "캐싱"하여 시간과 비용을 절약할 수 있습니다. 그러나 매번 맨 앞 부분을 다시 작성하면 해당 캐시가 무효화되고 전체 재계산이 강제됩니다. 이날은 "동적 알림"(모델에 전달되는 임시 대화 전환 정보)을 "앞면 다시 작성"에서 "끝 부분에 새 메시지 추가"로 변경하여 접두사 캐시를 유지했습니다. 당신을 위한 직접적인 느낌: 긴 대화에 대한 더 빠른 응답과 더 낮은 비용. 이러한 최적화는 그 자체로는 작아 보이지만 AI와의 장기간의 앞뒤 협업을 기반으로 구축된 플랫폼에서는 부드러움과 지출에 실질적인 차이가 생기고 대화가 길어질수록 초기의 올바른 호출은 더 많은 성과를 거두게 됩니다. 또한 전체 프로젝트에 걸쳐 실행되는 입장을 보여줍니다. 즉, "모델과 대화하는 방법"을 변덕스러운 프롬프트가 아닌 실제 개선할 가치가 있는 엔지니어링으로 취급하는 것입니다.

오늘의 의미

첫 번째 작품을 함께 살펴보면 그 중 어느 것도 의도적으로 "과시하기 위한 기능"이 아니라는 것을 알 수 있습니다. 예쁜 홈페이지도 없고 화려한 데모도 없습니다. 이는 렌더링, 엔진, 동시성, 대화 등 네 가지 관통 라인 각각의 첫 번째 초석입니다. 그 뒤에는 명확한 판단이 있습니다. "채팅을 통해 게임 생성"이 궁극적으로 작동하는지 여부는 처음에 트릭을 시연할 수 있는지 여부에 달려 있는 것이 아니라 기반이 충분히 견고한지(브라우저에서 그릴 수 있는지, 여러 환경에서 안정적인지, 싸우지 않는 에이전트, 돈을 낭비하지 않는 긴 대화)에 달려 있습니다. 이 네 가지 파운데이션을 한 번에 부어주면 나중에 그 위에 꾸준히 쌓일 수 있습니다. 이는 또한 이 변경 로그가 향후 개발을 위해 남기고 싶은 첫 번째 모델이기도 합니다. 즉, 가장 어렵고, 가장 덜 매력적이며, 가장 타협할 수 없는 것을 먼저 얻으십시오.