저는 두 아이들을 위한 작은 학습 앱을 만들었는데, 이 앱은 다른 두 개의 플랫폼과 같은 에이전트 인프라 위에서 실행됩니다. 이 앱은 다른 두 플랫폼에는 없던 제약 조건을 도입했습니다.

누군가 기다리고 있습니다.

오케스트레이션 플랫폼(orchestration platform)은 아무도 지켜보지 않는 새벽 4시에 실행됩니다. 만약 호출(call)이 90초가 걸린다면, 정확히 90초가 걸리며 시스템의 어떤 부분도 이를 감지하지 못합니다. 출판 플랫폼(publishing platform)에는 사람이 앞에 있지만, 그 사람은 저이고 제 스케줄에 맞춰 검토를 진행하는 것입니다.

세 번째는 연필을 들고 화면을 보는 초등학교 2학년 아이가 있습니다. 그녀의 인내심은 제가 협상할 수 있는 성능 예산이 아닙니다. 그것은 단단한 물리적 한계이며, 제가 이를 넘어서면 아이는 다른 곳으로 가버리고 제품은 가장 중요한 방식으로 실패합니다.

저는 처음에 당연한 방식으로 만들었고, 그 당연한 방식은 틀렸습니다.

콘텐츠를 질문 단위로 하나씩 생성합니다. 각 호출(call)이 작기 때문에 빠르고 잘못된 형태로 돌아올 가능성이 적으며, 아이가 현재 문제에 집중하는 동안 다음 질문을 미리 가져옵니다(prefetch). 이론적으로는 기다리는 시간이 생각하는 시간 뒤에 숨겨집니다.

하지만 실제로는 아이가 스케줄러처럼 그 공백을 채우지 않습니다. 아이들은 답하고, 그리고 앉아 있습니다. 만약 미리 가져온 내용이 도착하지 않았다면, 아이들은 스피너(spinner)를 지켜보았고, 이 행동은 질문 하나하나 사이에서 발생했습니다. 세트당 6개의 항목, 놓칠 수 있는 6번의 기회가 있었습니다.

종이 위에서는 반응성이 좋아 보였던 아키텍처가 제가 만들 수 있었던 가장 비반응적인 것이었습니다. 왜냐하면 그것이 사용자가 할 일이 없는 바로 그 순간에 기다림을 분산시켰기 때문입니다.

본능은 호출(call)을 더 빠르게 만드는 것입니다. 이 본능은 틀렸습니다.

일반적으로 에이전트를 보이지 않을 만큼 빠르게 만들 수는 없으므로, 시도하는 것을 멈추고 대신 그것이 실행되는 '때'를 변경해야 합니다.

앱은 이제 세 개의 수업을 한 번에 계획하고, 각각의 수업을 단일 호출로 완성합니다. 모든 질문과 그림, 답변이 완료되어 아이가 보기 전에 저장됩니다. 첫 번째 수업은 1~2분이 걸립니다. 아이들은 그 시간 동안 기다리게 됩니다. 그리고 이들이 수업을 진행하는 동안, 두 번째와 세 번째 수업이 백그라운드에서 구축됩니다. 그 이후부터는 수업을 여는 것이 데이터베이스 읽기 작업입니다. 제가 측정한 결과는 6밀리초였습니다.

기다리는 시간은 줄어들지 않았습니다. 위치가 바뀐 것뿐입니다. 사용자가 아직 아무것도 시작하지 않았기 때문에 참아낼 수 있는, 앞쪽의 기다림을, 실제로 몰입하고 활동하는 부분에서의 제로 대기 시간과 교환한 것입니다.

이것을 유지하게 만드는 두 가지 세부 사항이 있습니다. 수업은 반드시 진정으로 완성되어야 하며, 플레이스홀더가 포함된 계획만으로는 안 됩니다. 그렇지 않으면 시스템이 원래의 문제로 되돌아갑니다. 그리고 백그라운드 구축 과정은 서버 재시작을 견뎌내야 합니다. 왜냐하면 진행 중인 비동기(async) 작업들은 조용히 죽어버리고, 수업을 영원히 '구축 중' 상태에 갇히게 만들기 때문입니다.

전체 글에서는 에이전트가 작성하는 앱릿들을 작동하는 코드로 다루고, 생성된 퀴즈에서 제가 발견한 위치적 편향(positional bias)에 대해, 그리고 왜 제 리더가 읽을 수 없는지에 대해 다룹니다.

[https://openred.space/blog/a-seven-year-old-will-not-wait.html]