요즘 CS 관련해서 프로세스와 스레드를 설명하는 여러 글들을 읽었는데, 좀 추상적인 개념이다보니 단박에 이해되지 않았다.
프로세스는 "운영체제가 시스템의 자원을 할당하는 작업의 단위"이고, 스레드는 이처럼 "프로세스를 구성하며, 프로세스가 할당 받은 자원을 활용하는 실행 흐름의 단위"라고 한다. 우리가 프로그램이라고 알고 있는 것이 실행되어 운영 체제에 의해 메모리 공간이 할당되면 프로세스가 생성되고 동적인 상태가 된다고 한다. 끙.
사실 여기에서 뭘 더 설명해야 하냐고 하면 할말이 없지만 좀 더 구체적인 정보가 필요했다. 프론트엔드 개발을 하면서 이 개념과 가장 밀접하게 관련이 있을 것 같은 브라우저를 통해 프로세스와 스레드를 이해하는 게 낫겠다 싶었다. 그러다가 NAVER D2에서 "최신 브라우저의 내부"라는 제목의 시리즈를 발견했고 너무 재미있게 읽어버렸다. 벌써 3년도 더 된 글이지만 프로세스와 스레드를 이해하는 데 충분했다.
아래는 이 시리즈에서 1, 2편을 읽고 아주 간략하게 프로세스와 스레드를 중심으로 요약한 내용이다. 혹시라도 이 글을 읽으시는 분이 있다면 아래 문장들에는 내가 이해한대로 아주 자의적으로 표현한 부분이 있으니 정확한 내용은 꼭 해당 시리즈를 읽으시는 것을 추천드린다.
크롬 브라우저 아키텍처: 다중 프로세스
1편에서는 크롬 브라우저의 아키텍처를 다룬다. 브라우저 프로세스, 렌더러 프로세스, 플러그인 프로세스, GPU 프로세스 등 기본적으로 "다중 프로세스" 구조를 취한다. 이 중 브라우저 프로세스가 컨트롤 타워처럼 다른 프로세스를 조정하는 역할을 맡고, 나머지 프로세스는 이름에 맞게 각 기능을 제어한다.
장점
이러한 다중 프로세스의 장점은 "프로세스"의 성격과 맞물린다. 이를테면 탭 내부에서 웹 사이트가 표시되는 모든 것을 제어하는 렌더러 프로세스의 경우, 각 탭 마다 실행되고 하나의 탭이 응답하지 않을 때 다른 탭 들에 영향을 주지 않는다. 이는 프로세스가 전용 메모리 공간을 사용하며 다른 프로세스와 공유하지 않기 때문에 가능하다.
또한 브라우저 프로세스와 렌더러 프로세스가 분리되었다는 것은 웹 페이지의 화면을 그리는 렌더러 프로세스에서 오류가 발생하더라도 브라우저 프로세스와는 분리되어 있기 때문에 브라우저 전체가 종료되거나 같이 문제가 생기지 않는다는 것을 의미한다. 그 외에도 보안과 격리 면에서도 다중 프로세스 아키텍처는 이점을 갖는다.
단점
동전의 양면처럼 단점 역시 프로세스의 특징에서 비롯하는데, 각 프로세스가 전용 메모리 공간을 사용하므로 공통으로 사용해야하는 부분도 각자 복사하여 갖고 있으므로 메모리 사용량이 많아진다는 점이다.
서비스화
위 글에서는 이에 대한 해결책까지 설명되는데, 브라우저의 각 부분을 서비스로 실행할 수 있게 하는 서비스화이다. 성능이 좋은 하드웨어 환경 혹은 반대로 리소스가 제한된 환경 등 상황과 조건에 맞게 여러 프로세스로 분할하거나 하나의 프로세스로 통합할 수 있도록 유동적으로 적응 가능한 아키텍처로 변경할 수 있도록 한 것이다.
내비게이션
2편에서는 사용자가 주소 입력줄에 URL을 타이핑하고 요청하여 페이지 렌더링이 되기까지의 과정인 내비게이션이 실행될 때 각 프로세스가 어떠한 역할을 하는지 설명한다.
브라우저 프로세스가 시작
탭 영역 밖을 제어하는 브라우저 프로세스에서 UI 스레드, 네트워크 스레드, 스토리지 스레드 등이 실행된다. 사용자의 주소 입력은 UI 스레드가, 네트워크 요청에 대한 처리와 응답은 네트워크 스레드가 처리한다.
네트워크 스레드가 요청에 대해서 HTML 파일로 응답을 받으면 데이트가 준비 완료되었음을 UI 스레드에게 알리고, UI 스레드는 이 데이터를 웹 페이지로 렌더링할 렌더러 프로세스를 찾는다.
렌더러 프로세스로 토스
이 상태에서 브라우저 프로세스가 렌더러 프로세스로 네비게이션을 실행하라고 IPC 메세지(Inter Process Communication)를 전송한다. 앞서 말했듯이 프로세스 간에는 메모리 공간을 공유하지 않기 때문에 이처럼 IPC 메세지를 통해 통신한다. 그러면 렌더러 프로세스가 데이터 스트림을 이어 받아서 데이터를 계속 수신한다. 렌더러 프로세스에서 네비게이션이 실행되었다고 브라우저 프로세스에서 확인되면 내비게이션이 완료되고, 주소 표시줄 업데이트, 탭 세션 기록 업데이트, 세션 기록 저장 등의 작업이 이루어진다.
3편, 4편에서는 각각 렌더러 프로세스의 아키텍처에 관련된 내용이 이어진다. HTML 문서를 받아서 화면을 구성하고 그리는 작업과 렌더러 프로세스의 컴포지터 스레드가 사용자 입력을 처리하는 방식이 설명된다.
마무리
결국 크게 보면 프로세스와 스레드 개념은 어떤 프로그램이 실행되는데 필요한 가장 기본적인 단위들로 이해된다. 마치 큰 회사의 각 팀, 각 부서처럼 제 역할과 기능을 하는 어떤 것들처럼 보인다. 중간중간 이런 아키텍처를 설계, 고안하고 구현한 개발자들에 대한 경외감도 들었다.
프로세스와 스레드를 이해하려고 읽기 시작한 글이긴 한데 생각보다 그 외에 알게 된 중요한 정보들이 많아서 큰 도움이 되었다. 2022년에는 또 크게 달라지고 발전한 부분이 분명 있을 것 같아서 얼른 알아서 업데이트 해야할 것 같다. 아무튼 당연한 이야기지만 프론트엔드 개발자로서 결국 퍼포먼스와 유저 경험을 위해서는 브라우저를 이해하는 게 중요하다는 생각이 든다.
댓글