오픈AI, 초당 7천만 요청을 파이썬으로 버텼다

첫 판단은 라이브러리를 서비스로 떼어낸 거예요. 2024년 중반 해비탯은 챗GPT 본 서버에 붙은 작은 파이썬 라이브러리였고, 제품 엔지니어가 스키마 조회나 라우팅, 권한, 암호화를 몰라도 되게 해 주는 게 전부였어요. 그런데 2025년 중반에 이르자 클라이언트 쪽 구현으로는 한계에 닿았어요. 저자들은 "클라이언트 라이브러리를 고치려면 수십 개 서비스에 걸친 복잡한 조율이 필요했고, 그 과정은 갈수록 깨지기 쉽고 비효율적이며 운영 사고에 취약해졌습니다"라고 적었어요.

실제 사고가 그 결론을 밀었어요. 한 지역이 멈춰도 피해가 번지지 않게 핵심 데이터를 여러 지역의 Azure Cosmos DB 계정으로 나누려던 작업이었는데, 클라이언트에 라우팅 논리를 넣고 기능 스위치 뒤에 숨긴 뒤 모든 서비스에 배포하는 데만 며칠이 걸렸어요. 검증용 그림자 실행을 붙이는 데 또 며칠, 잘못된 부분을 고치는 데 또 며칠이 갔고요. 스위치를 켜기 직전에 한 팀이 다른 이유로 옛 버전으로 되돌렸고, 막으려던 바로 그 장애가 일어났어요.

두 번째 판단은 파이썬을 당장 버리지 않은 거예요. 회사는 파이썬으로 서비스를 돌리면 네트워크 지연이 늘고 CPU와 메모리 비용이 크게 불어난다는 걸 알면서도 그대로 갔어요. 저자들은 "당시 우리의 주된 목표는 비용이나 자원 최적화가 아니라, 제품 개발자의 발을 풀어 주고 플랫폼을 안정시키는 것이었습니다"라고 설명했어요. 대신 이 선택을 의도적으로 진 기술 부채라고 못 박았고, 100배 규모에서는 통하지 않을 것이라 언젠가 다시 쓸 수밖에 없다고 적었어요.

파이썬으로 버티는 동안 이 팀이 가장 오래 씨름한 건 꼬리 지연이에요. 저자들은 "평균적인 사용자 요청 하나가 수백 번의 데이터베이스 호출로 이어지기 때문에, 사용자가 체감하는 건 가장 느린 호출 하나입니다"라고 적었어요. 파이썬의 asyncio는 입출력을 겹쳐 처리하지만 CPU를 나눠 쓰지는 못해서, 압축과 암호화, 체크섬 같은 CPU 작업이 쌓이면 응답이 이미 도착해 있어도 그걸 읽어 줄 차례가 오지 않아요. 회사는 이 밀림이 수백 밀리초, 심한 경우 몇 초까지 벌어졌다고 밝혔어요. 그래서 프로세스 하나가 맡는 동시 요청 수를 아주 작게 유지하고 대신 프로세스 수를 대규모로 늘리는 쪽을 골랐어요.

원인을 찾아낸 방식은 구체적이에요. 서비스를 처음 띄웠을 때 CPU 프로파일링으로 잡아낸 범인은 기능 스위치 설정 파일이었어요. 스위치 도구가 기본값으로 1분마다, 그것도 흔들림 없이 정확히 같은 순간에, 모든 서비스의 운영 규칙이 다 들어 있는 큰 설정을 다시 읽었거든요. 파드 하나에 파이썬 프로세스를 최대 여덟 개까지 띄워 두었으니 1분마다 모든 일꾼이 동시에 하던 일을 멈추고 그 큰 파일을 해석했어요. 설정을 잘게 자르고 갱신 주기를 늘리고 시각을 흩뜨리는 것으로 끝났어요.

연결을 다시 쓰는 순서를 바꾼 대목은 더 흥미로워요. 어느 날 과부하를 일으키던 클라이언트를 껐는데도 일부 프로세스만 계속 나빠졌고, 재시작하기 전까지 요청이 오히려 더 몰렸어요. 파이썬 aiohttp의 연결 관리자가 가장 최근에 반납된 연결을 먼저 다시 쓰도록 되어 있었던 게 원인이었어요. 느린 서버일수록 연결을 늦게 반납하니 그 연결이 다음 차례로 뽑혔고, 힘든 프로세스에 일이 더 쌓이는 되먹임이 생긴 거예요. 반납된 순서대로 쓰도록 바꾸자 그 고리가 끊겼고 평소의 편차까지 줄었어요.

설계에서 일부러 뺀 것도 있어요. 해비탯은 클라이언트가 아무 SQL이나 짜서 던지게 두지 않고 단순한 NoSQL API만 열어 둬요. 저자들은 "강력한 API가 없다는 점은 해비탯 설계에서 의도한 맞바꿈입니다"라고 적었어요. Postgres를 쓰던 시절에는 비싼 질의 하나가 뜨거운 경로에 올라와 데이터베이스를 통째로 넘어뜨리는 일이 잦았다고 회사는 인정했고, 지금은 비싼 질의가 클라이언트 쪽에서 눈에 띄도록 만들어 두었다고 설명했어요.

회사가 스스로 적어 둔 한계는 그래프예요. 객체와 그 객체에 붙은 연결선은 같은 저장 구획에 두지만, 연결선이 가리키는 반대편 객체까지 같이 두려는 노력은 하지 않아요. 수평으로 늘리기는 쉬워지는 대신, 연결을 한 칸 건널 때마다 다른 지역의 다른 계정에서 데이터를 꺼내야 할 수 있어요. 복잡한 질의가 필요한 팀에게는 변경 기록을 흘려보내 만든 별도의 분석용 사본을 주는데, 회사는 이 방식이 쓰는 팀에게 추가 부담을 준다고 인정했어요.

그리고 올해 2분기에 파이썬을 접었어요. 엔지니어 두 명이 코덱스와 GPT-5.5를 붙여 서비스 전체를 러스트로 다시 썼고, 지금 운영 요청의 95%를 러스트가 받으며 파이썬은 몇 주 안에 완전히 내린다고 회사는 밝혔어요. 회사 데이터로는 러스트 쪽이 CPU 6배, 메모리 15배 더 효율적이고 평균과 꼬리 지연 모두 뚜렷하게 낮아요. 파이썬이 버틴 최고치는 초당 2천만 건이 넘는 요청이었어요. 메탈은 오픈AI가 코덱스를 돌리는 하네스를 API로 열었다고 보도한 바 있으며, 이번 글은 그 도구를 회사가 자기 인프라를 갈아엎는 데 먼저 썼다는 기록이에요.

메탈이 확인한 발표문에서 가장 눈에 띄는 문장은 그 결정을 내릴 때의 계산이에요. 저자들은 "전면 이전이 필요해질 무렵이면 코덱스와 GPT가 그 이전을 해낼 수 있으리라 걸었고, 그 내기는 결국 맞았습니다"라고 적었어요. 기술 부채를 일부러 지면서, 그 부채를 갚아 줄 도구를 자기들이 만들고 있다는 사실까지 변수로 넣었다는 뜻이에요. 해비탯은 지금 오픈AI에서 코어 수 기준 두 번째로 큰 서비스이고, 엔보이 사용량으로는 네 번째예요.

이 글이 남기는 교훈은 언어 선택이 아니에요. 회사는 예측 가능하고 일정한 양의 일만 하는 요청에 맞춰 설계하는 편이 확장하기 훨씬 쉽고 잘못 쓰이기도 어렵다고 적었어요. 해비탯이 파이썬으로 초당 2천만 건 넘게 갈 수 있었던 이유도 API를 좁게 잡아 둔 덕분이고요. 규모를 감당하는 힘은 더 좋은 재료가 아니라 무엇을 하지 않을지 미리 정해 둔 목록에서 나와요.