CSA 1.8~1.10

1.8

1.8은 기존에 우리가 해왔던 흐름을 이제 원격에서 하는 것이다.

telnet 원격 실행을 한다고 하자 그럼 우리는 로컬에서 telnet서버에 접속하고 원격 쉘을 켜서 내 로컬 키보드로 원격 hello를 실행 telnet서버에서 결과를 전송 내 로컬 화면에서 나온다.

내 키보드 -> 내 telnet -> 원격 쉘 -> 원격 hello 실행 -> 결과 전송 -> 내 화면

 

그럼 굳이 왜 로컬에서 할 수 있는 작업을 원격에서 하는 것일까?

 

핵심은 로컬에서 할 수 없는 일이 많기 때문이다. 그리고 할 수 있더라도 원격에서 하는 편이 더 좋은 경우가 많다. 

1. 로컬에 없고 원격에만 있는 자원이 있어서

• 특정 서버에만 있는 데이터베이스
• 특정 머신에만 설치된 프로그램
• GPU가 달린 장비
• 회사 내부망에서만 접근 가능한 시스템

즉 내 컴퓨터는 입력만 하고 실제 일은 필요한 자원이 있는 곳에서 한다

 

2. 내 컴퓨터보다 훨씬 강한 컴퓨터가 있어서

• 대용량 데이터 처리
• AI 학습/추론
• 빌드/배포
• 영상 인코딩

즉 집에서 수작업하던걸 공장에 맡기는 느낌

 

3. 데이터가 이미 그쪽에 있어서

• 데이터가 서버에 있는데 굳이 전부 내 컴퓨터로 가져와서 처리하면 느리고 비효율적이다

즉 수많은 양의 데이터를 내 컴퓨터에 저장할 수 없고 그 데이터를 저장한 더 좋은 컴퓨터가 원격에 있는데 굳이 가지고 오거나 멀리서 할 이유는 없다.

 

4. 여러 사람이 함께 같은 시스템을 써야 해서

로컬은 보턴 내 컴퓨터 내 환경인데 회사에서는 여러 사람이 동시에 접근해야 하기 때문에

• 웹사이트
• 회사 메일
• 사내 ERP
• 게임 서버

이런 경우 공용 서버가 필요하다

 

5. 관리와 보안을 한 곳에서 하려고

모든 사람 pc에 프로그램과 데이터가 흩어져 있으면 관리가 어렵고 위험하다

 

6. 내 로컬 환경과 실제 실행 환경이 다르기 때문에

내 컴퓨터에서는 잘 되는데 서버에서는 안 될 수 있다. 그래서 아예 서버 환경에서 직접 돌려보는 게 더 정확할 때가 많다.

 

네트워크를 쓰는 이유는
입력하는 곳, 계산하는 곳, 데이터가 있는 곳, 결과를 보는 곳을 서로 분리할 수 있기 때문이다.

로컬에서는 이게 다 한곳에 몰려 있지만
현실 시스템은 보통

• 사용자 입력: 내 컴퓨터
• 실제 계산: 서버
• 데이터 저장: DB 서버
• 결과 표시: 다시 내 화면

여기서 더 궁금해서 찾아본게 그럼 TELNET가 뭐냐

telnet은 원격 컴퓨터에 문자 기반으로 접속해서 명령을 주고 결과를 받는 프로그램/프로토콜

즉 내가 접속하려는 대상 컴퓨터가 원격 컴퓨터이고 그 컴퓨터 안에서 telnet server 프로그램이 실행 중이어야 내가 접속할 수 있다.

 

그래서 진짜로 원격으로 다른 사람 컴퓨터를 쓰는것이다!

 

그럼 웹에서 내가 계산기 프로그램을 실행하는것은 과연 네트워크일까?

이건 비슷하다고 볼수있지만 다르다 왜냐하면 웹에서 프로그램을 실행한다는건 이런 자바스크립트만 돌아서 결과값을 주는건 네트워크라고 볼수없다 

그럼 날씨를 알려주는 사이트는 네트워크일까?

정답은 맞다

왜냐하면 브라우저에서 서버로 요청을 보내 결과값을 반환하기 때문이다

 

그럼 웹에서 몽고DB를 사용해 데이터를 저장하고 불러오는것은 과연 네트워크일까?

정답은 네트워크다 왜냐하면브라우저에서 서버로 요청을 보내고 서버는 몽고DB서버에 요청을 보내 데이터를 받아온다 이과정이 네트워크이다.

 

그럼 유튜브는 어떤 흐름으로 네트워크가 이뤄질까?

1. 유튜브 사이트에 들어감
네가 브라우저에 유튜브 주소를 입력해요.

그러면 브라우저가 네트워크를 통해 유튜브 서버에 요청을 보내요:

• HTML
• CSS
• JavaScript
• 썸네일
• 영상 정보

를 받아옵니다.

비유:

• 영화관에 가서
• 상영표, 좌석표, 안내문부터 받는 단계예요

2. 영상 하나를 클릭함
브라우저가 또 서버에 물어봐요.

• 이 영상 제목 뭐야?
• 재생 가능한 화질 뭐 있어?
• 자막 있나?
• 댓글 데이터 있나?
• 광고 붙나?

이런 메타데이터를 받아와요.

즉 아직 영상 전체를 다 받은 게 아니라,
이 영상을 어떻게 재생할지에 대한 설명서를 먼저 받는 거예요.

3. 영상 파일을 한 번에 다 받지 않음
이게 중요해요.

유튜브는 보통 영상을 통째로 한 번에 다 내려받지 않고,
잘게 조각난 데이터(chunk)를 조금씩 받아요.

예:

• 처음 몇 초 분량 먼저 받음
• 재생 시작
• 재생하는 동안 다음 조각 계속 요청

비유:

• 영화 파일 전체를 택배로 한 번에 받는 게 아니라
• 상영 중에 다음 릴을 계속 받아오는 느낌이에요

이 방식이 좋은 이유:

• 기다리는 시간이 줄고
• 중간에 멈추면 전체를 다 안 받아도 되고
• 화질도 상황에 따라 바꿀 수 있어요

4. 네트워크 상태에 따라 화질 조절
유튜브는 네 인터넷 속도를 계속 보면서:

• 빠르면 고화질
• 느리면 저화질

로 바꿔요.

즉 브라우저가 서버에
"지금은 1080p 말고 480p 조각 보내줘"
처럼 다른 품질의 데이터를 요청할 수 있어요.

이걸 적응형 스트리밍처럼 이해하면 돼요.

비유:

• 길이 막히면 큰 트럭 대신 작은 차로 자주 보내는 느낌

5. 브라우저가 받은 조각을 재생
브라우저는 받은 영상 조각들을 메모리에 잠깐 쌓아두고 재생해요.
이게 우리가 말하는 버퍼링이에요.

• 네트워크로 데이터 받기
• 메모리에 잠깐 저장
• 화면/스피커로 출력

이 흐름이 계속 반복돼요.

6. 영상 말고도 같이 오가는 것들
유튜브에서 네트워크로 오가는 건 영상만이 아니에요.

같이 오갈 수 있는 것:

• 댓글
• 좋아요 수
• 자막
• 추천 영상 목록
• 광고 데이터
• 시청 기록
• 재생 위치 저장

그럼 유튜브는 과연 CPU성능이 중요할까요 아님  네트워크 속도가 더 중요할까요?

정답은 네트워크가 더 중요합니다. 유튜브에서 CPU와 네트워크의 역할은

• CPU 역할: 받아온 영상을 해석하고 화면에 뿌리기
• 네트워크 역할: 볼 영상 자체를 계속 가져오기

그래서 아무리 영상이 잘 재생 되어도 네트워크가 느려서 다음 데이터가 안 오면 멈추기때문에 

 

 

1.9.1 Amdahl’s Law

이 법칙은 쉽게 말하면 전체 속도를 올리고 싶으면 전체 중 가장 큰 비중을 차지하는 부분을 개선해야 한다

여러 예시를 들건대

시험공부를 하는데

• 수학이 성적의 60%
• 영어가 20%
• 국어가 20%

근데 영어만 과외를 받아 기존의 3배의 성적을 내도 전체 성적의 3배가 좋아지진 않는다

 

컴퓨터도

• 프로그램 실행 시간의 60%가 어떤 느린 계산에서 발생
• 그 계산을 3배 빠르게 만듦

즉 팩토리얼 프로그램을 실행하는데 그중에 60%를 계산하는데 쓰고 나머지 40퍼센트는 출력하는데 쓴다. 근데 이 프로그램 시간을 3배를 늘리고 싶어서  팩토리얼 계산하는 코드를 최적화해 3배 더 빠른 코드를 만들어도 팩토리얼 프로그램에서 계산은 60%만 차지하기 때문에 실제로 프로그램은 3배가 아닌 1.67배밖에 안 빨라진다.

 

즉 아무리 한 부분을 무한히 빠르게 만들어도 나머지 느린 부분이 전체 한계를 정한다.

 

그래서 팩토리얼 계산속도를 0초로 만들어도 출력하는 40퍼센트 때문에 기존의 2.5배가 속도 증가의 한계다

 

이게 프로그래밍에서 중요한 이유는 개발자들이

• 눈에 띄는 한 함수만 최적화하거나
• 사소한 코드 미세 튜닝에 집착하거나
• 병목이 아닌 곳을 고치기 때문이다

그래서 병목이 아닌 곳을 열심히 고쳐봤자 전체는 거의 안 빨라진다

 

즉 성능 향상은 열심히가 아닌 정확히다.

 

그럼 병목은 정확히 뭘까?

말하자면 시간을 가장 많이 쓰는 부분이다.

• DB 조회: 7초
• 파일 읽기: 2초
• 문자열 가공: 1초

전체 실행시간이 10초가 걸리는 프로그램이 있는데 여기서 문자열 가공하는데 코드가 지저분하고 비효율적일 수 있어서 그걸 열심히 고쳐 1초에서 0.2초로 줄여서 전체시간을 10초에서 9.2초로 단축할 수 있다 하지만 사용자는 별 체감을 못 느낄 가능성이 크다 그래서 병목인 DB조회 7초를 줄이려고 해야 한다.

 

그럼 우리는 왜 병목 보다 비효율적인 부분이 먼저 눈에 들어올까?

이유는 사람은 전체 시스템 보다 내가 눈앞에서 이해할 수 있는 작은 문제를 먼저 보기 쉽기 때문이다.

 

1. 눈에 잘 보이는 건 작은 코드고, 병목은 시스템 전체에 숨어 있어서
비효율은 보통 코드 한 줄, 함수 하나, 중복 루프처럼 눈에 딱 보여요.

예:

• "어? 여기 같은 계산 두 번 하네"
• "이거 for문 비효율적인데?"
• "객체를 너무 많이 만드네"

이런 건 바로 보인다.

반면 병목은:

• DB
• 네트워크
• 디스크
• 락 대기
• 캐시 미스
  같이 코드 바깥까지 봐야 드러나는 경우가 많다.

2. 사람이 직접 고칠 수 있는 부분에 끌리기 때문에
작은 비효율은 당장 손댈 수 있어요.
고치면 성취감도 바로 와요.

반면 병목은 종종:

• 구조를 바꿔야 하고
• 측정을 해야 하고
• 다른 팀과 연결돼 있고
• 원인이 복잡해요

즉,
작은 비효율은 "내가 지금 해결할 수 있는 문제"라서 더 먼저 눈에 들어와요.

 

3. 코드의 모양과 실행시간은 다르기 때문에
사람은 코드의 "보기 싫음"을 성능 문제처럼 착각하기 쉬워요.

예:

• 긴 함수
• 중복된 계산
• 복잡한 조건문

이건 읽기에 비효율적일 수 있어요.
그런데 실제 실행시간은 거의 안 잡아먹을 수도 있어요.

반대로:

• 겉보기엔 단순한 DB 쿼리 1줄
• 외부 API 호출 1번
• 락 하나

이런 게 실제 병목일 수 있어요.

즉,
사람은 읽기 불편한 코드를 과대평가하고
겉보기 단순한 느린 작업을 과소평가하기 쉬워요.

 

4. 병목은 측정해야 보이는데, 비효율은 추측만으로도 보이기 때문에
병목은 보통 측정 없이는 확신하기 어려워요.

• 어디서 시간이 가장 오래 걸리는지
• 어떤 요청에서 느린지
• CPU를 쓰는지, I/O를 기다리는지
• 동시성 때문에 막히는지

이런 건 직접 재야 해요.

반면 비효율은 그냥 눈으로 보고 말할 수 있죠.
그래서 사람은 측정보다 직관에 먼저 의존해요.

 

5. 인간은 '부분 최적화'에 심리적으로 끌리기 때문에

작은 부분을 반짝반짝 다듬으면 "좋아졌다"는 느낌이 강해요.

비유하면:

• 집 전체 난방이 안 되는데
• 책상 위 물건 정리부터 하게 되는 느낌이에요

정리 자체는 좋은 일이지만,
추운 문제를 해결하진 못하죠.

그래서 우리는 종종 고치기 쉬운 문제를 중요한 문제로 착각해요.

 

6. 병목은 자주 움직이기 때문에
더 어려운 점은 병목이 항상 고정돼 있지 않다는 거예요.

예:

• 처음엔 DB가 병목
• DB 고치고 나니 네트워크가 병목
• 네트워크 고치니 락 경쟁이 병목

즉 병목은 시스템 상태에 따라 계속 달라질 수 있어요.
반면 비효율적인 코드는 늘 그대로 눈앞에 있으니까 더 신경 쓰이죠.

 

1.9.2 Concurrency and Parallelism

여기서 용어가 두 개가 나온다

Concurrency (동시성) : 여러 일이 동시에 진행되는 것처럼 다루는 개념

Parallelism (병렬성) : 여러 일을 실제로 동시에 처리해서 더 빨라지는 개념

이 둘은 비슷하지만 확실히 다른 게

동시성은 1,2,3이라는 일을 할 수 있는 능력이 있지만 하나씩 하는 것이고

병렬성은 진짜로 같은 순간에 1,2,3을 동시에 처리

 

1. 스레드 수준 병렬성
가장 큰 단위예요.

• 여러 프로그램을 동시에 실행
• 한 프로그램 안에서도 여러 스레드 실행

예전에는 CPU하나가 빠르게 번갈아 처리해서 동시성을 흉내

요즘은 아예 코어가 여러 개라 실제 병렬처리가 가능해졌다

 

하지만 하드웨어에 코어가 많아도 프로그램이 스레드 구조로 잘 짜여 있지 않으면 빨라지지 않는다.

 

그럼 어떤 구조가 잘 짜인 구조일까?

핵심은 일을 여러 조각으로 나눠서 동시에 해도 결과가 안 꼬이게 만들었냐 이다.

잘 안 짜인 구조

1. 일이 전부 한 줄로 이어져 있는 구조

앞 작업이 끝나야 다음 작업을 할 수 있는 경우

• 1번 계산 결과가 나와야 2번 가능
• 2번 결과가 나와야 3번 가능
• 3번 결과가 나와야 4번 가능

 

• 요리사 4명이 있어도
• 반죽 끝나야 굽고
• 굽기 끝나야 자르고
• 자르기 끝나야 포장 가능하면 한 명씩 순서대로 할 수밖에 없다.

2. 모든 스레드가 같은 데이터 하나를 계속 건드리는 구조
공유 자원이 너무 많으면 락(lock) 때문에 기다리느라 느려져요.

• 스레드 8개가 모두 같은 전역 변수 카운터만 증가
• 스레드 8개가 같은 리스트에 계속 동시에 쓰기

즉 직원이 8명 있는데 계산대가 1개뿐이라 다 줄 서는 상황

 

3. 일을 너무 잘게 쪼갠 구조
스레드 만드는 비용, 작업 분배 비용, 합치는 비용이 더 커질 수 있어요.

• 숫자 100개 더하는데 스레드 50개 생성

즉 쿠키 10개를 포장하는데 직원 20명 부르는 구조

 

4. 한쪽만 바쁘고 나머지는 노는 구조

작업 분배가 불균형하면 일부 코어만 일하고 끝난다.

• 스레드 1개는 데이터 90%
• 나머지 3개는 10%만 처리

조별과제에서 한 명이 거의 다 하고 나머지는 잠깐만 하는 상황

 

2. Instruction-Level Parallelism

이건 CPU내부 수준

• 한 요리사가 요리 하나만 완전히 끝내고 다음 요리로 가는 게 아니라
• A 요리의 재료 손질, B 요리의 팬 예열, C 요리의 접시 준비를 겹쳐서 처리하는 것

 CPU도 명령 하나를 처음부터 끝까지 완전히 마친 뒤 다음 명령으로 가는 게 아니라 여러 명령의 여러 단계를 겹쳐서 처리한다

프로그래머가 쓴 코드의 모양에 따라 CPU가 이런 병렬성을 잘 활용할 수도 못 할수도 있기 때문이다.

즉 좋은 코드는 단순히 맞는 코드가 아니라 CPU가 겹쳐서 처리하기 쉬운 코드

 

3. SIMD Parallelism

이건 다 낮은 수준

• 사과 8개를 하나씩 씻는 대신
• 8칸짜리 세척판에 한 번에 넣고 같이 씻는 것

하나의 명령으로 여러 데이터를 동시에 처리하는 방식

특히 이미지, 영상, 소리 같은 동일한 연산을 반복하는 분야에서 강하다.

• 픽셀 8개 색값 동시에 더하기
• 음성 샘플 여러 개 동시에 처리하기

컴퓨터는 동시에 더 많이 처리하려는 방향으로 발전했다.

• 운영체제 수준: 여러 프로세스/스레드
• CPU 수준: 여러 명령 동시 처리
• 데이터 수준: 여러 데이터 동시 처리

즉 더 빠른 컴퓨터는 단순히 클럭만 빠른 컴퓨터가 아니라 더 많은 일을 겹쳐서 처리할 수 있는 컴퓨터

 

1.9.3 The Importance of Abstractions in Computer Systems

추상화는 복잡한 내부를 숨기고 바깥에서는 단순한 규칙만 보이게 하는 것

자동차 운전할 때

• 엔진의 연소 과정
• 기어 내부 톱니
• 전기 신호 흐름

전부 몰라도 핸들, 브레이크, 액셀만 알면 운전할 수 있다.

• Instruction Set Architecture
  실제 복잡한 CPU를 "명령어를 순서대로 실행하는 기계"처럼 보이게 함
• File
  여러 I/O 장치를 "바이트의 흐름"처럼 보이게 함
• Virtual Memory
  복잡한 물리 메모리를 "내가 가진 연속된 주소 공간"처럼 보이게 함
• Process
  복잡한 실행 환경을 "실행 중인 프로그램 하나"처럼 보이게 함
• Virtual Machine
  컴퓨터 전체를 또 하나의 가짜 컴퓨터처럼 보이게 함

장점:

• 배우기 쉽다
• 쓰기 쉽다
• 이식성이 좋아진다
• 내부 구현이 바뀌어도 바깥 코드는 유지된다

대가:

• 내부를 몰라도 되지만, 성능 문제나 버그를 만났을 때는 내부를 알아야 한다
• 추상화는 단순화를 주지만, 완벽한 진실은 감춘다

예를 들어

C 코드에서는 메모리가 그냥 커다란 배열처럼 보이지만,
실제로는 캐시, 페이지, 디스크, TLB, 커널 보호가 얽혀 있다.

즉, 프로그래머는 추상화 덕분에 편하게 일하지만,
더 잘하려면 가끔 그 추상화 아래를 들여다봐야 한다.

이게 사실 CSAPP 전체 철학

추상화를 사용할 줄 아는 것도 중요하지만
추상화 아래에서 실제로 무슨 일이 일어나는지 아는 것이 더 강한 프로그래머를 만든다

 

한 줄 요약:

추상화는 복잡함을 숨겨서 시스템을 다루기 쉽게 만든다

하지만 성능, 오류, 보안을 이해하려면 추상화 아래도 알아야 한다