엔지니어링

엔지니어링

Mythex를 어떻게 만들고 운영하는지, 무엇이 고장 났고 어떻게 고쳤는지까지.

• 재배포가 실패해도 작동 중인 백엔드는 삭제되지 않습니다 — 실패한 재배포가 앱의 실제 운영 API를 삭제하거나, 고장 난 새 버전을 그대로 남겨둘 수 있었습니다. Mythex가 잘못된 배포를 되돌리는 방식을 고친 세 가지 수정 사항을 소개합니다.
• 서버마다 울리지 않고 한 번만 울리는 알림 — 하루에 한 번만 가야 할 알림이 한 오후에 다섯 번 도착했습니다. 서버 두 대와 배포 환경에서 메모리 기반 중복 제거가 왜 깨지는지, 공유 상태로 어떻게 고쳤는지 설명합니다.
• 아무도 기다리지 않도록 더 큰 워크스페이스로 옮기기 — 2GB로 옮긴 뒤에도 워크스페이스의 4분의 1이 1GB에 머물러 있었습니다. 첫 번째 수정은 한 사용자를 7분 동안 기다리게 했습니다. 무엇을 바꾸었고 다시 바꾸었는지 설명합니다.
• 실제 사용량에 따라 데이터베이스 요금을 청구합니다 — 예전에는 앱마다 데이터베이스 비용을 추정했는데, 그 추정은 양방향으로 틀렸습니다. 이제 모든 데이터베이스는 측정된 사용량에 따라 한 시간 단위로 청구됩니다.
• 게시 직후 크래시하는 앱을 잡아내기 — 세 번의 게시가 헬스 체크를 통과했지만, API는 부팅할 때마다 몇 초 만에 크래시했습니다. 원인은 다섯 개 항목으로 제한된 목록에서 크래시를 세고 있었기 때문입니다.
• 이미지가 많은 에이전트 턴을 메모리 안에 담아 두기 — 카탈로그 스캔을 계속 들여다보던 에이전트 턴이 952MB에서 메모리를 모두 썼습니다. 이미지를 너무 오래 붙들고 있던 세 가지 원인과 그 해결 방법입니다.
• 긴 에이전트 턴을 컨텍스트 윈도우 안에 담아 두기 — 우리 서브 에이전트는 모델이 요청을 거부할 때까지 커지거나, 공간을 아끼려고 일찍 멈추거나, 러시아어 토큰을 잘못 셌습니다. 긴 AI 작업을 끝까지 가게 한 세 가지 수정입니다.
• 휴대폰이 잠들어도 채팅이 살아 있도록 하기 — 휴대폰은 잠들고, 탭을 바꾸고, 네트워크가 끊깁니다. 빌드 도중에 채팅이 멈추거나 답변이 절반만 보이던 두 가지 버그를 찾아 고친 과정입니다.
• 하나의 무거운 채팅이 우리 API를 멈출 수 있었던 이유 — 9월 28일 두 API 서버가 동시에 메모리를 모두 썼습니다. 첫 대응은 메모리 증설이었고, 진짜 해결은 채팅 기록을 개수가 아니라 크기로 불러오는 것이었습니다.
• Publish를 두 번 눌러도 이제 한 번만 발행됩니다 — 같은 앱에 대한 발행 요청 세 개가 84ms 간격으로 도착해 각각 전체 배포를 실행했습니다. 누가 발행할지 데이터베이스가 결정하고, 나머지에게는 사실을 알리도록 바꿨습니다.
• 우리 사이트를 고치며 얻은 SEO 교훈 — 중복된 FAQ 마크업, Google에 잘못 표시된 썸네일, 아무도 클릭하지 않은 템플릿 페이지, 그리고 우리 엣지가 거부한 경로까지. mythex.ai에서 발견해 고친 여섯 가지입니다.
• 정적 사이트, 재게시하는 동안에도 계속 열려 있습니다 — 정적 사이트를 다시 게시할 때 예전에는 새 빌드를 업로드하기 전에 라이브 파일을 모두 비웠습니다. 이제는 새 사이트가 자리를 잡을 때까지 기존 사이트가 계속 제공되고, 변경 사항은 몇 초 안에 반영됩니다.
• 진행 상태 레이블에 숨어 있던 메모리 부족 충돌 — AI 에이전트가 큰 파일 하나를 쓰는 도중 메모리 부족으로 충돌했습니다. 원인은 모델도, 병렬 서브 에이전트도 아니었습니다. 상태 레이블이 41,000번 다시 전송되고 있었던 것입니다.
• 서버를 멈추게 한 누락된 스왑 파일 — 프로덕션 서버가 충돌하지 않은 채 응답을 멈췄습니다. 메모리 부족 종료는 없었고, 스왑이 없는 머신에서 페이지 캐시 스래싱만 있었습니다. 무슨 일이 있었고 무엇을 바꿨는지 설명합니다.
• 죽은 연결 없이 데이터베이스 깨우기 — 절전에서 깨어나는 게시된 앱은 잠든 동안 죽은 데이터베이스 연결을 붙잡고 첫 요청을 10~12초 동안 붙잡고 있었습니다. 이를 2.3초로 줄인 방법을 소개합니다.
• 우리 자신의 서비스에 속도 제한을 걸고 있었습니다 — API의 IP별 속도 제한은 우리 서비스를 한 명의 바쁜 사용자처럼 취급했고, 프로덕션에서 우리 서비스가 429 응답을 받기 시작했습니다. 원인을 찾아 고친 과정을 설명합니다.
• Mythex 서버를 ARM으로 옮긴 이유 — 무거운 작업을 프로젝트별 샌드박스로 옮기고 나자, 우리 서버는 메모리의 3분의 1만 사용했습니다. 더 작은 ARM 인스턴스로 월 서버 비용을 약 30% 줄였습니다. 방법을 설명합니다.
• 배포 시 502 오류를 0개로 줄인 방법 — 배포와 충돌하던 워치독, 그리고 서버가 듣기를 멈춘 뒤에도 로드 밸런서가 너무 늦게 알아챈 문제. 둘을 찾아 고치고 배포당 502를 10개에서 0개로 줄인 과정입니다.