0. 트래픽 병목을 해결하는 9가지 구조적 해법트래픽은 한순간에 몰린다. 공지 하나, 이벤트 하나로 수만 명의 사용자가 동시에 접속하고, 시스템은 예고 없이 한계에 도달한다. 대부분의 장애는 “예상보다 빠르게” 발생한다. 그래서 트래픽은 터진 뒤에 대응하는 것이 아니라, 터지기 전에 설계로 준비해야 한다.문제는 “어디부터, 무엇을 바꿔야 하는가”다. 단순히 서버를 늘리는 것만으로는 해결되지 않는다. 시스템의 병목은 대개 하드웨어의 한계가 아니라, 구조의 제약에서 시작된다.서비스가 성장할수록 시스템은 단지 더 많은 요청을 처리하는 것뿐 아니라, 더 빠른 응답, 지속적인 가용성, 예상치 못한 부하에도 견디는 복원력까지 요구받는다. 따라서 시스템은 확장성(Scalability)만이 아니라, 가용성(Availa..

CPU 스케줄링을 학습하던 중, 대규모 언어 모델에도 유사한 자원 분배 로직이 적용될 수 있음을 직관적으로 느꼈습니다. ChatGPT 응답 지연 현상을 단순한 연산 지연이 아닌, 시스템 레벨의 스케줄링 이슈로 해석할 수 있는지 살펴보고자 했습니다. GPT의 내부 구조는 공개되어 있지 않지만, 운영체제의 스케줄링 이론과 공개된 AI 서빙 인프라 사례를 바탕으로 추론 가능한 수준의 구조적 유사성을 정리했습니다. 입력했는데, 왜 아무 반응이 없을까ChatGPT를 쓰다 보면 가끔 응답이 늦을 때가 있다. 입력은 했는데, 아무 반응 없이 멈춰 있는 것처럼 보이는 순간. 모델이 복잡한 답변을 구성하느라 시간이 걸리는 걸까? 실제로는 그렇지 않다.이런 지연은 대부분 서버 측의 처리 대기 때문이며, 리소스를 어떻게 분..

들어가며 - 단순한 웹앱 뒤에 숨어 있던 복잡한 구조이번 주 CS 스터디 주제는 ‘가상 메모리와 페이징’이었다. 교과서처럼 정리된 개념도 중요하지만, 나는 실전에서 어떻게 쓰이는지가 궁금했다. 그러다 문득 이런 의문이 들었다.내 웹앱은 그냥 버튼을 눌러 GPT API를 호출하고 결과를 보여줄 뿐인데… 이 간단한 작업에도 운영체제는 뭔가 거대한 걸 하고 있지 않을까? 그래서 이번 글에선 내가 직접 만든 사주 웹앱을 출발점으로 삼아, 운영체제 안에서 실제로 어떤 일이 벌어지는지—특히 가상 메모리와 페이징 구조가 어떻게 작동하는지를 하나씩 살펴본다. 버튼 한 번 눌렀는데, 메모리가 열린다고요? 웹앱 사용자 입장에선 “버튼 누르기 → 결과 확인”이 전부지만, 서버 입장에선 그 순간 하나의 요청을 처리하는 작은..

이 글은 컴퓨터 과학(CS)을 공부하면서 생긴 질문을 정리하고, 스스로 답을 찾아가는 과정을 담았습니다. 읽기 쉽게 풀어 썼으니, 비전공자나 개발자가 아니어도 편하게 읽어주시면 좋겠습니다. 본문에는 참고하거나 인용한 출처도 함께 명시했습니다. 시스템 콜(System Call)을 처음 배웠을 때 가장 먼저 떠오른 생각은 하나였다. "왜 이렇게 불편하게 만들어놨지?" 파일 하나를 열거나 저장할 때도 프로그램은 운영체제(OS)를 통해 일일이 허락을 받아야 했다. 컴퓨터는 빠르고 효율적으로 움직이게 설계된 줄 알았던 내게, 이 절차는 너무 번거롭게 느껴졌다. 왜 이렇게 복잡하게 만든 걸까? 레퍼런스rebugs.tistory, [운영체제] 운영체제의 큰 그림시스템은 왜 자유를 포기했을까처음에는 이해할 수 없었다...