급하게 만들어야해서 완전한 바이브코딩으로 만들었으며, 제작 시간은 2시간정도 걸렸다. 현재는 window만 지원되는 상태라 정처기 시험 끝나고 나면 나중에 수정을 좀 해야겠다.

깃허브 링크를 추가해놓겠다.

https://github.com/VenyVince/CBT-Alone

이 내용들을 알고 있을 때 우리는 '멀티스레드 상태에서 CPU가 특정 변수를 동시에 수정하게되면 문제가 생기지 않는가' 하는 질문을 던져볼 수 있다.

예를 들면 이런 상황이다 만약 쇼핑몰에서 상품 데이터에 접근을 한다고 해보자. 상품 하나가 구매된다면 상품의 재고는 하나가 줄어들것이다. 그런데 사용자 2명이 동시에 상품을 하나씩 구매한다면 어떻게 될까?

우리의 생각대로라면 당연하게도 2개의 재고가 줄어드는데 맞다. 멀티 스레드를 사용하게 되면 CPU는 우리의 생각대로 행동하지 않는다. CPU는

1. 메모리에서 상품 재고 확인
2. 기존 재고에서 -1 계산
3. 재고 저장

의 세가지 단계를 가지게 된다.

그런데 이때 A와 B, 두 개의 스레드가 동시에 재고에 접근하게 되면 어떻게 될까?

사진과 같은 단계를 거치게 되어 A와 B의 결과값은 우리가 기대하는 기존 재고 -2가 아닌 기존 재고 -1의 값을 갖게 될 것이다.

이러한 문제는 동시성 문제 라고 칭하는 것들 중 하나이다. 여기서 문제가 되는 공유 자원에 접근하는 코드 영역을 임계영역(Critical Section)이라고 칭하는데 임계영역은 동시에 여러 스레드가 실행하게되면 문제를 발생시키는 영역이다.

동시성 문제

• 멀티 스레드 환경에서는 여러 스레드가 같은 자원에 동시에 접근이 가능하다. stack을 제외하면 변수나 메모리, 파일, DB 데이터 등 여러가지 자원을 공유하고 있기 때문이다.

앞서 예시든 데이터의 일관성 문제를 가진 상태를 Race Condition(경쟁상태) 라고 한다.

Race Condition의 경우 여러 스레드가 공유 자원에 접근하여 동시에 수정하기 때문에 발생한다. 그렇다면 이외에 또 다른 문제가 있을까?

대표적으로 DeadLock과 저번에 언급되었던 Starvation이 있다.

DeadLock(교착 상태) 데드락은 서로 Lock을 잡고 기다리다가 영원히 멈추는 것을 이야기한다.

• Lock은 공유 자원에 접근할 때 다른 스레드가 접근하지 못하도록 잠그는 장치이다.

만약 자원 A와 B를 필요로하는 스레드 1과 2가 있다고 해보자. 스레드1은 자원 A를 먼저 접근하고 B를 필요로 한다. 스레드2는 자원 B를 먼저 접근하고 A를 필요로 한다. 이러한 상황에서 DeadLock은 아래와 같은 단계로 벌어지게 된다. 둘은 영원히 닿을 수 없는 평행 상태에서 닿고자 계속해서 뻗어가는 상태라고 볼 수 있겠다. 이러한 문제로 인해 프로그램이 멈추게 된다.

DeadLock의 경우 네가지 조건을 동시에 만족할 때 발생한다.

1. 상호 배제: 한 번에 한 프로세스만 자원을 사용하는 것.
2. 점유 대기: 자원을 점유한 채로 다른 자원을 기다리는 것.
3. 비선점: 다른 프로세스가 점유한 자원을 강제로 빼앗을 수 없는 것.
4. 순환 대기: 프로세스들이 서로 순환하며 자원을 기다리는 것.

Starvation(기아 상태) 기아상태는 앞서 말했듯 계속해서 실행되지 않는 문제이다. 예를 들면, 저번시간에 이야기한 우선순위 스케쥴링에서 높은 우선순위 작업만 계속해서 실행되는 바람에 낮은 우선순위 작업은 영원히 대기될 수도 있는 경우를 뜻한다.

• 이외에도 LiveLock이나 Priority Inversion이라는 문제가 존재한다. 간략하게 설명하면 LiveLock은 서로 양보만 하다가 아무 작업도 진행이 안되는 것이며 Priority Inversion은 낮은 우선순위가 락을 잡고 있어서 높은 우선 순위 작업이 기다리는 문제이다. 이는 실시간 시스템에서 중요하다.

여러 스레드가 동시에 접근하고 실행 순서에 따라 결과가 달라지는 동시성 문제의 핵심이다.

이것을 해결하기 위해 우리는 저번 시간에 알아봤던 동기화라는 것을 통해 한 번에 하나에만 접근하게 할 수 있게 된다.

동기화 Lock기반 기법

Mutex

가장 기본적인 Lock을 활용한 동기화 기법이다. 단 하나의 키를 가지고있는 방에 접근한다고 생각을 하면 쉽다. A라는 사람이 방에 접근한다고 해보자. 화분 밑에서 키를 가지고 방에 들어가게 된다. 그렇다면 B라는 사람은 어떻게 방에 들어갈 수 있을까? A가 문을 열어주지 않는 이상 B는 방에 들어갈 수 없다.

이처럼 뮤텍스 기법은 Lock을 통해 오직 하나만 접근 가능한 상호 배제(Mutual Exlusion) 하는 기법이다.

그러나 스레드가 Lock을 얻지 못하면 대기상태로 들어가기 때문에 OS가 스케쥴링과 Context Switching을 수행해야한다. 이러한 이유로 Lock은 비용이 존재한다.

Semaphore

Mutex의 확장 버전이다. Mutex는 단 하나의 키를 가지고 있는 방이라면 Semaphore은 여러 개의 키를 가지고 있는 방이다.

Semaphore는 Binary와 Counting 방식이 있다.

Binary 방식은 값을 0과 1만 가지고 있어 사실상 Mutex와 동일하게 동작한다. 공유 자원에 오직 하나의 스레드만 접근해야 할 때 다른 스레드를 완전히 차단하기 위해 사용된다. Counting 방식은 값을 0부터 N까지 여러개 가질 수 있어 N개의 스레드가 동시 접근을 허용한다. Counting 방식의 경우 DB에서 최대 연결 수를 제한하거나 스레드 풀에서 동시 실행 가능한 작업 수를 제한할 때 등에서 사용하게 된다.

• Binary Semaphore vs Mutex: Mutex는 소유권의 개념이 존재하고 Binary Semaphore은 소유권의 개념이 존재하지 않는다. 그래서 Mutex의 경우 Lock을 건 스레드가 Lock을 해제할 수 있고 Binary Semaphore의 경우 Lock을 걸지 않은 다른 스레드가 Lock을 해제할 수 있다.
• Counting Semaphore은 Mutex나 Binary Semaphore방식이 데이터 일관성을 보호하기 위한 목적을 가지고 있는 것과 달리 시스템 자원의 고갈을 방지하기 위해 사용된다. 예를들어, DB서버가 감당하지 못할 1억개의 요청이 동시에 들어오게 되면 서버는 다운된다. 그러나 DB서버가 감당할 수 있는 1000개의 요청만 먼저 처리하도록 하게 된다면 서버가 다운되지 않고 순차적으로 처리된다.

Synchronized

Java에서 가장 기본적이고 많이 사용하는 동기화 방식이다.
여러 스레드가 동시에 같은 데이터에 접근할 때, 한 번에 한 스레드만 작업하도록 막아준다.

예를 들어 은행 계좌에 동시에 입금이 일어난다고 가정해보자.
두 사람이 동시에 같은 계좌 금액을 수정하면 계산이 꼬일 수 있다.

Synchronized는 이런 상황에서 “지금 이 작업은 한 사람만 사용 가능합니다.”라고 문 앞에 잠금장치를 거는 느낌이다.

Java에서는 아래처럼 간단하게 사용할 수 있다.

public synchronized void income() {
    balance += 500000;
}

메서드가 실행되면 Java가 자동으로 Lock(잠금)을 걸고,
작업이 끝나면 자동으로 Lock을 해제한다.

그래서 사용법이 매우 간단하고 실수할 가능성이 적다.

다만 단점도 있다.

누군가 작업 중이면 다른 스레드는 기다려야 하기 때문에,
동시에 요청이 많아지면 성능 비용이 발생할 수 있다.

즉, 안전하지만 사람이 많아지면 줄 서서 기다리는 방식이다.

ReentrantLock

ReentrantLock도 역할 자체는 비슷하다.
여러 스레드가 동시에 데이터를 수정하지 못하도록 막는다.

하지만 Synchronized보다 조금 더 “직접 제어”하는 방식이다.

lock.lock();

try {
    balance += 500000;
} finally {
    lock.unlock();
}

여기서는 개발자가 직접:

• Lock을 걸고
• 작업이 끝나면
• Lock을 풀어줘야 한다.

조금 더 복잡하지만 대신 기능이 더 많다.

예를 들어:

• 일정 시간만 기다렸다가 포기하기
• 먼저 기다린 스레드부터 처리하기(Fairness)
• Lock 획득 실패 시 다른 작업 수행하기

같은 고급 기능들을 지원한다.

Reentrant는 '같은 스레드가 이미 가진 Lock을 다시 획득할 수 있다'는 뜻이다.

쉽게 말하면

• 내가 이미 회의실 열쇠를 가지고 있는데
• 잠깐 다시 문을 열어도
• “너 이미 사용 중이니까 괜찮아”

라고 허용해주는 개념이다.

내부적으로는 '이 스레드가 몇 번 Lock을 걸었는지'를 숫자로 관리한다.

그리고 마지막까지 unlock 해야 완전히 해제된다.

지금까지 Lock 기반 기법을 살펴보았다. 이번엔 Lock을 사용하지 않는 방식을 알아보자.

동기화 Lock-Free기반 기법

1. Atomic(원자적) 동시성 문제를 CPU 명령 자체를 원자적으로 처리하는 기법이다.

   AtomicInteger count = new AtomicInteger();
   count.incrementAndGet();

   의 형식으로 사용된다.

Atomic은 CAS(Compare And Swap)을 통해 이루어진다. CAS는 현재 값이 내가 예상한 값이면 변경하는 형태로 동작한다. 처음 들었던 예시로 보자면 아래와 같다.

1. A가 재고 확인
2. B가 재고 확인
3. A가 -1 연산
4. B가 -1 연산
5. A가 결과값을 예상 값과 비교 (맞아서 저장)
6. B가 결과값을 예상 값과 비교 (틀려서 다시 시도)
7. B가 재고 재확인
8. B가 -1 재연산
9. B가 결과값을 예상 값과 비교 (맞아서 저장)

예시만 보아도 알겠지만 CAS를 사용하는 Atomic은 복잡한 작업에서는 사용하기 어려워진다. 여러 연산을 하나의 원자적 작업으로 묶기 어렵기 때문이다.

대신 Lock이 없고, Context Switching이 적으며, 빠르다는 장점을 가진다.

• Lock방식의 경우 대기상태와 컨텍스트 스위칭/스케쥴링이 계속해서 발생하고, CAS방식은 블로킹 없이 재시도하기 때문에 문맥교환 비용이 없어 빠르다.

마무리

결국 동시성 문제는 멀티 스레드 환경에서 공유 자원을 안전하게 관리하기 위한 문제이며 이를 해결하기 위해서는 Lock 기반 또는 Lock Free 기반의 다양한 동기화 기법이 사용된다.

요즘 하고 있는 것은

1. 정처기 딸 준비 / 면접 준비 겸해서 CS개념 복습
2. Re:View 프로젝트 리팩토링
3. Cosider 프로젝트 진행(설계 및 구현)
4. 개인적인 운동 이정도이다. 1,2에서 각각 하루에 23시간정도를 사용하고 3,4에서 각각 하루 12시간정도를 사용하는데 정말 하루가 눈코뜰새 없이 바쁘다.

본론으로 돌아와서 오늘은 내가 진행중인 리팩토링에 대해 간단하게 이야기해보고자 한다.

개요

Re:View프로젝트는 사용자 후기를 중심으로한 쇼핑 플랫폼이다. 멀티캠퍼스 부트캠프에서 최종 팀프로젝트로 했던 것이다.

개인적으로 가장 시간을 많이 들인 프로젝트인데 아쉬움이 많이 남고 문제점도 많아서 리팩토링을 하고자 했다.

리팩토링 단계를 여러 개로 나누어서 진행중이고 진행 예상 기간은 5월초~6월초 정도로 약 한 달의 시간을 잡았다.

내가 잡은 리팩토링 단계는 3단계이다.

1. 안정화 단계
2. 최적화 단계
3. 문서화 단계

현재는 안정화 단계를 끝내고 최적화 단계로 진입한 상태이다. 아마 최적화 단계도 이번 주에서 다음주 안으로 끝나지 않을까 싶다.

문서화 단계가 끝나고 나서 할 일이 딱히 없다면 아마 확장성을 조금 더 챙기거나 기존에 도입하려 했지만 시간적인 압박으로 하지 못했던 것들을 구현하는 방향으로 리팩토링을 진행하지 않을까 싶다.

안정화

Re:View프로젝트는 상당히 불안정한 상태의 플랫폼이었다. 내가 팀장을 맡으면서 빠뜨린 부분이 많게 된 것 같다. 주먹구구식으로 2달 정도의 시간동안 처음보는 언어와 체계로 진행을 하다보니 아쉬운 점이 많이 남았다.

안정화 부분에서 아쉬운 점은 아래와 같다.

1. 환경 변수 값들이 여기저기 흩어져있다.
2. 예외 처리 응답이 엉망이다.
3. Spring security와 관련된 보안적 측면 또한 많이 아쉽게 되어있었다.

이러한 점들을 개선하기 위해서 지난 2주동안 프로젝트를 다시 파악하고 세가지 부분을 보완했다.

최적화

기본적으로 Re:View프로젝트는 테스트가 이루어지지 못한 프로젝트이다. 프로젝트를 진행하면서 잠깐잠깐 콘솔과 API Dog정도로 간략한 테스트만 했었기에 서비스의 성능 자체가 좋지 못할 것 같다는 생각이 들어서 이 단계를 채택했다.

최적화 단계에서 진행할 것은 아래과 같다.

1. 주요 API의 현재 성능 측정
2. 데이터 규모와 상태에 따른 성능 변화 측정
3. 실측 결과 기반 이미지, 페이징, 검색등의 부하 분리
4. 병목점 파악 후 개선

현재는 성능 측정을 위해 도구를 선택하고 기본적인 성능 측정을 기입하기 위한 문서를 만들어놓은 상태이다. 해당 내용은 필자의 Github(Re-view-personal)에서 확인할 수 있다.

마무리

아마 최적화 단계가 끝나고 나면 문서화를 통해 포트폴리오를 조금 더 강화시키게 될 것 같다. 추후에 Cosider프로젝트까지 끝이 나게된다면 내 포트폴리오와 이력서도 공개하면서 피드백을 받아보고 싶다. 피드백에서 신랄하게 비판하거나 지적할 부분이 많을 것 같아 조금 두렵긴 하다. 학생 신분을 가졌을 때 너무 느긋하게 살지 않았나 싶기도 하다... 물론 학생때에 공부와 알바를 병행하느라 내 나름대로는 바쁘게 살긴 했다만 사실 알바보다는 공부에 더 비중을 두는게 맞지 않았나 싶기도 하다. 그러나 다시 그때로 돌아간다고 해서 내가 알바보다 공부를 더 중하게 생각하진 않았을 것 같다. 결국 그때의 난 자취를 하기 위해서 목표를 잡았고 그 목표를 향해서는 달려가고 있었기 때문이다. 그리고 백앤드 개발자라는 직업에 진정으로 관심을 가지기까지는 꽤나 오랜 시간이 걸렸기 때문이다. 그래서 그때의 선택을 엄청나게 후회하진 않는다. 그저 아쉬움이 조금 남았을 뿐이지... ㅠ 오늘은 여기까지 하고 앞으로는 리팩토링과 관련된 내용도 간략하게 올려보겠다. 시간이 날 때 올릴 것 같은데. 자주 쓴다고 장담하진 못할 것 같다.

컨트롤러를 끊는 방식은 크게 4가지로 나뉜다.

1. 자원 중심(URL의 명사)
2. 행위 중심(사용자의 행위)
3. 화면 중심(프론트 페이지)
4. CRUD 통합(없음)

자원 중심

/workspaces        → WorkspacesController
/workspaces/members → WorkspaceMembersController
/tasks             → TasksController

URL의 명사를 기준으로 자른다. Rest원칙이 가장 가까우면서, API의 태그 분류가 명확해진다. 도메인이 많을 때 적합하다. 그러나 컨트롤러의 수가 많아진다.

행위 중심

LoginController    → 로그인, 로그아웃, 토큰 갱신
InviteController   → 멤버 초대, 수락, 취소
AssignController   → 이슈 담당자 지정, 변경

사용자의 행동을 기준으로 자른다. 요구사항 문서와 1:1 대응에 용이하다. 이는 기획자와의 소통이 쉽다는 장점을 가질 수 있겠다. 그러나 자원이 여러 컨트롤러에 분산되어 유지보수가 어렵고, URL 설계가 Rest답지 않을 수 있다.

화면 중심

DashboardController   → 대시보드 화면에 필요한 모든 데이터
ProjectDetailController → 프로젝트 상세 화면용 API 묶음

FE를 위한 BE방식이라고 보면 된다. 페이지 단위를 기준으로 자른다. FE 개발자가 한 컨트롤러만 보면 되어서 협업이 쉽다. 그러나 화면이 변경되면 BE도 변경될 수 있고, 로직의 중복이 생긴다.

CRUD 통합 중심

AuthController → login, logout, signup, withdraw, oauth, refresh 전부

작은 프로젝트나 초기 프르토 타입에서 용이하다. 그러나 파일이 커지면서 수정할 때 어디를 건드려야할지 파악이 어려워지고 Guard 선언이 메서드마다 달라진다.

• Guard: NestJS에서 요청 통과를 결정하는 관문이다.

실제 작업 순서

① ERD 보고 테이블군 파악
        ↓
② FK 방향 + 라이프사이클로 모듈 결정
        ↓
③ 자원/Guard/변경이유 기준으로 컨트롤러 분리
        ↓
④ 컨트롤러에 엔드포인트 배치
        ↓
⑤ 각 엔드포인트에 API 명세 작성

필자는 위와 같은 작업 순서로 먼저 큰 모듈을 정리하고 컨트롤러에 엔드포인트를 배치하는 형식을 사용했다.

쉽게 이야기하면 기능요구사항을 참고하여 각 기능과 사용 자원에 따라 모듈을 정리하고 해당 모듈에 컨트롤러들을 배치하는 형식이다.

이러한 방식은 한 번에 큰 단위의 초기작업을 진행하다보니 초기 작업 속도가 느려진다. 하지만 큰 틀이 잡혀 후속 작업이 금방금방 진행될 수 있다.

일반적으로 필자는 위와같이 큰 틀을 잡아놓고 후속 작업을 진행하는 탑바텀 방식을 선호한다. 큰 그림을 먼저 그리고 세부적인 디테일을 잡아가는게 필자의 스타일이기 때문이다. 그러나 카카오톡과 같은 서비스를 제공한다고 하면 너무너무 큰 대용량 작업이기 때문에 큰 틀을 잡는 것 자체가 너무 비효율적이어진다. (카카오톡은 단순 메신저라고 생각할 수도 있지만 실제로 우리가 사용하는 카카오톡의 기능은 너무나도 많다. 예를들면 최근 화제가 되었던 인스타와 같은 피드 기능, 숏츠 기능, 선물 기능 등의 부가 기능이 정말 많다.)

그러한 경우에는 먼저 핵심적인 흐름을 잡아내어 작업을 하는 것이 편할 것 같다.

마무리

이상으로 필자가 사용하는 방식의 API 명세서 작성 방법에 대해 알아보았다. 항상 느끼는 바이지만 이 세상에는 완벽한 방법, 완벽한 무언가라는건 존재하지 않는 것 같다. 그래서 언제나 체크하고 의심하며 살아가는게 참 중요한 것 같다. 지금 내가 사용하는 방식이 과연 지금 상황에 맞는 방식인지. 이 방식이 최선인지를 생각하는게 완벽에 가장 가까워질 수 있는 방법인 것 같다.

오늘은 여기까지.

이번에 진행하는 프로젝트는 NestJS와 Nuxt를 이용한 프로젝트이다. TypsScript 기반 프로젝트라고 이해하면 편하겠다.

프로젝트 명은 Cosider로 프로젝트 가이드 방식의 협업툴이다. 현재 내가 활동중인 Croffledev팀에서 진행중이다. 서비스 자체가 비즈니스로 전환될 가능성이 높다고 생각하여 Private으로 설정해놓고 프로젝트를 진행중이다.

프로젝트를 Private으로 진행하는 만큼 따로 기록을 남겨놓는게 더욱 중요하다고 생각하여 앞으로 프로젝트에 대한 글을 쓸 예정이다.

앞으로 글의 개요는 프로젝트의 전반적인 진행 상황, 프로젝트에서 내가 한 것, 비고의 형식으로 이루어질 것이다.

추가로 Croffledev에서는 매년마다 팀원 각자 아이디어를 구상하여 발표를 하고 회의를 통해 각 아이디어를 구현하고 있다고 한다. 난 올해들어 처음 들어왔고 들어온지 이제 3~4개월정도 밖에 되지 않았다.

현황

아이디어 발표 이후 2개월 정도가 지났는데, 그동안은 아이디어에 대한 구현 우선순위를 정하고 올해 첫 프로젝트에 대한 기획과 설계를 진행했다.

진행이 늦어진 것은 아이디어를 구상한 팀장의 개인적인 이슈로 한 달간 탈주하다시피 했기 때문에 어쩔 수 없이 늦어진 감이 없다고 생각한다.

이번 프로젝트는 사용자 요구사항 정의부터 시작되었다. 사용자 요구사항 정의란 이 프로젝트가 완성되었을 때 사용자가 무엇을 요구하는지에 대해 간략하게 정리해보는 것이다.

사용자 A: 30세, 비개발자, 개발에 대한 관심을 가지고 있으나 개발적 지식이 거의 없어 제품 개발(프로젝트 진행)에 어려움을 겪음.
- 개발 가이드 제시

위와 같은 요구사항 정의를 통해 MVP에 대한 개요를 짰다.

• MVP(Minimum Viable Product)란 최소한의 기능을 가진 제품이라는 뜻이다.

사용자가 ~~하기위해, ~~를 도입 / 구현 요구사항 정의 이후에는 요구분석이라는 틀을 통해 위와 같이 한 번 더 정제해주었다. 그리고 요구분석을 하며 어떤 식으로 구현할 것인가에 대해 정리해보는 절차를 가졌다.

이후 기술 스택을 정하고 기능 요구사항 및 예외 정책서를 작성하였다. 각 기능을 기준으로 요구사항들을 정리하고 요구사항이나 기능에 대한 예외를 정리하는 절차이다.

• 일반적으로 기능 요구사항을 먼저 정리하고 예외 정책의 경우 API 명세서와 함께 작성하는 것으로 알고 있다.

기능 요규사항과 예외 정책서를 바탕으로 페이지 구성리스트와 ERD를 먼저 작성하게 되었다.

• 'API 명세서는 미리 API Endpoint를 파악하고 Convention(경로 형태)를 일관성 있게 해야할 것 같다.'라는 팀장의 말로 API명세서의 우선순위가 변경.

이후 페이지 구성리스트 작성과 함께 ERD 작성을 하고 현재는 API명세서 작성을 진행중이다.

아마 금주나 차주 내에 API 명세서와 DataFlow 및 Sequence설계, UI 디자인등이 완료될 예정이다.

목차

• Summary
• CPU Scheduling
• Scheduling 두가지 범위
• 동기/비동기(Synchronous/Asynchronous - Sync/Async)
• 블로킹/논블로킹(Blocking/non-Blocking)
• 동기/블로킹&비동기/논블로킹
• 마무리

그 전에 저번 시간에 이야기했던 CPU에서 Thread까지의 내용을 되짚어보자

Summary

1. CPU는 기계어의 명령어를 실행하는 컴퓨터의 연산장치이다.
2. 프로그램은 기계어의 명령어와 그 외의 것들로 구성된다.
3. 프로세스는 Code, Data, Heap, Stack으로 이루어져있으며 메모리에서 실행되는 프로그램의 독립적인 실행 단위이다.
4. 스레드는 프로세스의 구성에서 Stack을 제외한 나머지 자원을 공유하는 프로그램의 최소 실행 단위이다.
5. CPU는 프로세스 단위로 프로그램을 메모리에 올려놓고 실행하는데 기존 작업이 끝났을 때 PCB를 확인하여 문맥교환을 한다.

저번 시간에 이야기했던 내용을 간략하게 줄이면 이정도가 되겠다. 그럼 CPU는 어떤 기준으로 프로세스의 스케쥴을 짤까?

CPU Scheduling

여기서 중요한건 CPU는 직접 프로세스의 스케쥴을 짜지 않는다. CPU는 단순히 작업 공간이라고 이해하면 된다. 우리가 일터에 갔을 때 일터 자체가 스케쥴을 짜진 않지 않는가? 이와 같이 CPU는 '작업 공간' 그 자체이다.

그렇다면 누가 프로세스의 스케쥴을 짤까?

그건 바로 운영체제라고 부르는 Operating System(OS)이다.

어제도 얼굴을 비추었던 OS는 여러가지 일을 하는데 그 중 하나가 바로 CPU Scheduling이다.

왜 OS는 프로세스의 스케쥴을 짤까?

이유는 아래와 같이 여러가지로 구성된다.

CPU를 가만히 있도록 내비두기 싫어서. CPU의 능률을 올려주기 위해서. 작업의 대기 시간을 줄이기 위해서. 특정 작업만 돌아가게 하지 않기 위해서.

위와 같은 이유들은 우리가 사장님이라고 생각해보면 바로 느낄 수 있다. 만약 내가 돈을 주고 고용한 직원이 오늘 해야할 일을 모른 채로 가만히 있는다면 어떻겠는가? 또 직원이 잘 안되는 일만 막 붙잡고 계속 가만히 있으면? 또는 컴퓨터로 5분걸리는 작업량을 가진 직원과 3시간걸리는 작업량을 가진 직원중 3시간 걸리는 직원이 사내에 한 대 있는 컴퓨터를 쓰고있는다고 한다면?

생각만해도 비효율적이고, 화가 난다.

이처럼 OS는 효율을 위해서 CPU의 스케쥴을 짠다.

Scheduling 두가지 범위

Scheduling은 크게 선점과 비선점 두가지의 범위를 가진다. 이름에서 알 수 있듯 비선점 스케쥴링(non-preemptive scheduling)은 프로세스가 종료되거나 스스로 자리를 양보하기 전에는 다른 프로세스가 그 자리를 뺏았지 못한다. 선점 스케쥴링(Preemptive scheduling)은 비선점과 반대로 OS가 강제로 CPU를 강탈한다.

그로 인해 구현이나 문맥교환에 대한 비용이 낮아진다거나 CPU의 응답률이 올라간다거나 하는 각각의 특징들을 갖는다.

스케쥴링의 종류는 여러가지가 있다. 그중에 우리는 대표적인 5가지에 대해 알아보고자 한다.

FCFS 'First Come First Served'라고도 불리는 FCFS는 들어온 순서대로 먼저 처리하는 순차적인 실행 상태를 가진다. 가장 단순하며, 긴 작업이 발생할 때에는 다른 일이 모두 지연되는 호위효과(Convoy Effect)가 발생할 수 있다.

SJF 'Shortest Job First'라고 불리는 SJF는 이름에서 알 수 있듯 실행시간이 짧은 것부터 먼저 실행한다. 그 대신 실행시간을 매번 파악해야하고, 긴 작업이 계속 밀려나는 기아상태(Starvation)이 발생할 수 있다.

Round Robin 'RR'이라고도 불리는 Round Robin은 프로세스가 일정 시간(Time Quantum)만큼 CPU를 사용할 수 있게 한다. 그로 인해 보편적으로 응답성이 향상된다. 그러나 문맥교환이 잦아지고 FCFS와 비슷하게 동작할 수도 있다.

Priority Schduling 우선순위 스케쥴링은 우선순위가 높은 것부터 실행하는 방식이다. SJF와 동일하게 Starvation이 일어날 수 있다. 그러나 프로세스의 기다림에 따라 우선순위가 상승하는 Aging이라는 절차를 통해 이를 어느정도 해소시키기도 한다.

SRTF Shortest Remaing Time First라고 불리는 SRTF는 SJF의 선점 버전이라고 봐도 무방하다. 남은 실행 시간이 적은 프로세스를 먼저 실행시키며 더 짧은 프로세스가 오면 CPU를 강탈당한다.

위와 같은 스케쥴링을 통해 한 번에 하나만 실행하는 CPU는 대기 작업을 다시 실행 가능한 상태로 바꿔가며 처리한다. 이때 블로킹/논블로킹, 동기/비동기에 따라 기다림과 실행 방식, 그리고 스케줄링과 CPU 활용이 달라진다.

동기/비동기(Synchronous/Asynchronous - Sync/Async)

• tmi 여기서 말하는 동기와 '동기화를 한다고 할 때'의 동기화는 데이터적 관점에서의 개념이고 '동기/비동기'의 동기는 제어 흐름 관점에서의 개념으로 이해하는 게 좋다.

동기는 작업완료 전까지 대기를 했다가 순차적으로 실행해 나가는 것을 이야기한다. 비동기는 작업 완료를 기다리지 않고 다른 작업을 이어가며, 완료되면 결과를 처리하는 방식이다

우리가 라면을 할 때를 생각해보자.

1. 물을 끓인다.
2. 면과 스프를 넣는다.
3. 라면을 먹는다. 이런 세가지 절차를 가만히 서서 기다리며 한다면 우리는 동기라고 이야기한다.

그러나 우리는 라면을 끓일 때 보통 가만히 있지 않는다. 최소한 나는 그렇다.

1. 물을 끓인다. - '물이 끓는 동안 대파를 썰고 김치를 꺼내온다.'
2. 면과 스프를 넣는다. - '면이 익는 동안 계란을 풀어서 준비해놓고 테이블을 닦는다.'
3. 라면을 먹는다. - '영화를 본다'

이와 같이 무언가 하나의 일만 하지 않고 계속해서 다른 일을 병행하고 있다고 보면 된다. 이것을 우리는 비동기라고 이야기하는 것이다.

블로킹/논블로킹(Blocking/non-Blocking)

동기와 비동기가 결과를 어떻게 처리할 것인지에 대한 내용이라면, 블로킹과 논블로킹은 실행 흐름에 대한 내용이다.

블로킹은 실행 흐름을 끊고 기다리는 것이고, 논블로킹은 기다리는 것 자체를 하지 않고 실행 흐름을 지속하는 것이다.

동기/블로킹&비동기/논블로킹

앞에서 간단하게 동기와 비동기, 블로킹과 논블로킹에 대해 알아보았다.

여기서 필자는 *"동기와 블로킹은 같고 비동기와 논블로킹은 같은게 아닌가? 왜 이걸 굳이 둘로 나눈거지?"*라는 개인적인 의문이 들었다.

그 이유는 “기다림” 개념에는 실행 흐름 문제와 결과 처리 구조 문제가 섞여 있어서, 이를 분리해야 시스템을 정확하게 설계하고 최적화할 수 있었기 때문이다.

그래서 동기와 비동기는 결과 처리 구조를, 블로킹과 논블로킹은 실행 흐름을 다루는 개념이라고 앞서 설명한 것이다.

그래서 블로킹/논블로킹은 현재 실행 흐름이 멈추는지 여부를 기준으로 하고, 동기/비동기는 결과를 현재 제어 흐름에서 기다려 처리할지 또는 분리된 방식으로 처리할지를 기준으로 한다.

그래서 이러한 동기와 블로킹, 비동기와 논블로킹으로 아래와 같은 조합을 만들어낼 수 있다.

마무리

오늘은 CPU 스케줄링부터 시작해서 동기/비동기, 블로킹/논블로킹까지 꽤 긴 여정을 달려왔다. 사실 처음에는 "그냥 기다리면 동기고 안 기다리면 비동기 아니야?"라고 생각했는데, 파고들수록 실행 흐름이냐 결과 처리 구조냐로 개념이 갈린다는 게 꽤 흥미롭지 않았는가? 그렇다면 여기서 한 가지 질문을 던져보겠다.

**"여러 스레드가 같은 자원에 동시에 접근하면 어떤 일이 벌어질까?" ** 다음 시간에는 바로 이 지점에서 시작한다. 동시성 문제가 왜 발생하는지, 그리고 이를 해결하기 위한 동기화 기법에는 어떤 것들이 있는지 알아볼 예정이다. 스포일러를 조금 하자면, 우리가 오늘 배운 블로킹 개념이 거기서도 아주 중요하게 등장한다. 댓글로 위 질문에 대한 생각을 남겨줘도 좋다. 틀려도 괜찮으니 한번 생각해보자.

오늘은 CPU를 중심으로, 실제 운영체제 안에서 어떤 일이 벌어지는지를 이야기해보겠다.

목차

• CPU는 무엇을 하는가
• 프로세스의 등장
• OS가 프로세스를 기억하는 방법
• 스레드의 등장
• 마무리

CPU는 무엇을 하는가

CPU는 '기계어의 명령어를 하나씩 순서대로 처리하는 연산 장치'이다. 우리가 계산기에서 1+1을 입력하고 실행하면 2라는 결과가 나오는 것처럼 프로그램을 실행하게 한다.

위 문장을 통해서 우리는 프로그램이란 *"기계어의 명령어로 이루어져있거나 기계어의 명령어 그 자체이겠구나"* 라는 사실을 유추할 수 있다.

여기서 우리는 궁금증이 들 수 있다. 계산기는 1+1 또는 2x2+3 정도로 한 번에 하나의 실행을 가진다. 그러나 컴퓨터는 동시에 여러 개의 프로그램을 돌려도 사용이 가능한 것처럼 보인다.

사실 컴퓨터에 있는 CPU는 하나의 작업만 처리할 수 있다. 그러나 운영체제는 CPU를 "너 잠깐 썼다가 쟤 줘."라고 하며 아주 빠르게 여러 프로그램에게 번갈아가면서 나눠준다.

그래서 우리는 마치 여러 프로그램이 동시에 실행되는 것처럼 느낄 수 있는 것이다.

그렇다면 운영체제. 즉, OS는 "어떻게 CPU에게 프로그램을 나눠줄까?"

프로세스의 등장

OS는 실행 중인 프로그램 하나하나를 프로세스(Process)라는 단위로 관리한다.

프로세스는 단순히 하나의 프로그램이 아니라, 실행을 위해 운영체제가 할당한 자원을 포함한 각각 독립된 실행 환경이다. 예를 들자면, 프로그램은 요리책. 프로세스는 재료 손질, 재료 볶기 등의 요리책을 보고 실행하는 것이라고 보면 된다.

가상 메모리 관점에서의 프로세스는 위와 같이 코드 / 데이터 / 힙 / 스택으로 나뉜다. 코드: 프로그램의 명령어 데이터: 정적 변수 힙: 동적 변수 스택: 함수 호출 스택

• tmi. 왜 하필 스택일까? 함수의 동작을 생각해보면 답이 나온다.

  만약 바깥에 있는 함수의 답을 내려고 하는데 안에 있는 함수가 답이 안나와있으면 어떻게할까?
  바깥에 있는 함수도 답이 당연히 나오지 않을 것이다.
  그래서 나중에 들어간 게 먼저 끝나는 LIFO(Last In First Out)구조를 가진 스택을 사용하게 된다.
  스택에 대해선 추후 알고리즘 시간에 자세히 다뤄보도록 하겠다.

OS가 프로세스를 기억하는 방법

하지만 CPU는 계속 다른 프로세스를 ADHD마냥 왔다갔다 거리기 때문에, "내가 아까 어디까지 했더라...?"를 기억하고 있어야한다.

그래서 OS는 각 프로세스마다 하나의 메모장을 만들어둔다. 우리는 그걸 PCB(Process Control Block)이라고 부른다.

PCB에는 CPU의 레지스터 상태, 프로세스 상태, 메모리 정보, 파일이나 입출력 정보, 현재 실행 위치같이 '내가 어디서 무슨 일을 어떻게 이어나가야하는지' 에 대한 정보가 정리되어있다.

그덕분에 프로세스를 기억하고 CPU는 왔다갔다 거리면서 멀티태스킹을 조질 수 있는거다.

CPU가 프로세스 A을 실행하다가 B로 넘어가는 순간에 OS는

1. A의 현재 상태를 PCB에 저장하고
2. B의 PCB를 꺼내서 확인하고
3. B의 상태를 CPU에 복원하고
4. B를 실행한다.

우리는 이 과정을 Context Switching(문맥교환) 이라고 한다.

여기서 문제가 생긴다.

운영체제에 있는 프로세스는 하나만 존재하지 않고 동시에 여러 개로 존재한다. 이를 멀티 프로세스라고 이야기한다. 이러한 멀티 프로세스 구조는 마치 각자 독립된 방을 쓰는 것과 같아서, 방 자체가 많아질수록 공간을 많이 차지하고, 방을 옮길 때마다 짐을 싸고 새 방으로 이동하는 시간이 필요하다는 단점을 가진다.

그래서 사람들은 스레드라는 개념을 창안해냈다.

스레드의 등장

스레드는 'CPU가 실제로 실행하는 최소 단위'이다.

스레드는 프로세스 내부에서 힙과 코드, 데이터를 공유하며 각자의 스택을 가진다. 즉 각자 어디서 일하고 있었는지를 나눠 가진다는 것이다.

이를 통해 힙과 코드를 공유하는 스레드는 바로바로 필요한 자원에 접근이 가능해졌고, 공간을 변경할 필요 없이 스택만 변경하면 되게 되었다. 또한 다른 스레드에서 새로운 힙, 코드, 데이터를 생성하지 않아도 되기에 저장 공간역시 확보가 되었다.

앞서 언급되었던 멀티 프로세스와 동일하게 멀티스레드라는 개념이 확립이 되었따.

마무리

오늘은 이렇게 CPU부터 스레드까지에 대한 개념을 가볍게 알아보았다. 다음에는 여러 프로세스와 스레드가 CPU에게 어떻게 선택되는지에 대해 알아보는 시간을 가질 것이다.

가기 전에 개인적으로 생각해보면 좋을 간단한 질문을 던져보겠다.

1. 멀티 프로세스와 멀티 스레드의 장단점은 무엇일까?
2. 멀티 프로세스와 멀티스레드 두 개념은 언제 사용하는게 좋을까?
3. 스레드가 많아질 때 오히려 느려지는 경우가 생기는데 이러한 경우는 왜 생기는걸까?

그럼 오늘은 여기까지.

기존에 네이버 블로그를 사용했었는데 이번에 어찌저찌 기회가 되어서 이리로 넘어오게 되었다.

아마 나 혼자 보는 블로그가 될 것 같다.

흠 뭐부터 이야기하는게 좋을까?

일단 간단한 내 소개부터 하자면, 26세 백앤드 개발자를 지향하고 있는 쉬었음 청년이다. 졸업한지는 대략 3개월차가 되고 있다.

아직 쉬었음 청년이라고 하기엔 애매한가 싶긴 한데 부모님은 나에게 숨고르기 청년이라는 별명을 벌써 붙여주셨기 때문에 당당하게 쉬었음 청년이라고 이야기하겠다.

요즘은 기존에 했던 프로젝트 리팩토링을 진행중이다. 기존에 했던 프로젝트가 마음에 들지 않는 부분이 상당히 많이 있고, 시간적으로 압박을 좀 많이 받았던 프로젝트라 여차저차 수정을 좀 해 나아가고 있다.

리팩토링 진행사항을 앞으로 이 곳에 쓰면서 다시 한 번 복습할 CS도 이 곳에 정리하고자 한다.

원래는 글 쓸 때 이렇게 짜임새 없이 무지성을 쓰진 않는데 첫 글이고 좀 자유롭게 쓸 글이다보니 이래저래 되어버린 느낌이다.

일단 이번 글은 여기서 마치겠다.