Conversation
📝 WalkthroughWalkthroughA new Markdown documentation article on OS concepts is introduced, explaining processes, threads, their relationship to programs, internal structures (PCB), resource sharing, context switching, concurrency vs parallelism, synchronization mechanisms (mutex, semaphore, locks), and practical guidance on when to use each approach. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@OS/MatchaKim/2026-01-14-THREAD_VS_PROCESS.md`:
- Around line 1-151: 문서에 PR 가이드 요구사항인 "추가 학습 필요사항" 섹션이 없으니 문서 끝부분의 요약("한 줄로
마무리하면") 바로 앞에 "## 추가 학습 필요사항" 제목을 추가하고, 짧은 항목들로 앞으로 더 깊게 공부해야 할 주제를 나열하세요(예:
프로세스 간 통신(IPC) 종류와 비용, 스레드 동기화 primitives(뮤텍스/세마포어/모니터)와 데드락 회피, 문맥 전환 비용과 캐시
영향, 멀티코어에서의 병렬성 vs 동시성, 안전한 상태 공유 패턴). 또한 각 항목마다 한두 문장으로 왜 추가 학습이 필요한지 간단히 덧붙여
PR 요구사항을 충족시키세요.
🧹 Nitpick comments (2)
OS/MatchaKim/2026-01-14-THREAD_VS_PROCESS.md (2)
29-34: Consider breaking up the long sentence for clarity.The historical motivation is accurate, but line 33 packs multiple concepts into one sentence. For better readability, consider splitting it into separate sentences.
📝 Suggested improvement for readability
-요즘에는 파일을 다운받으면서 다른 멀티 작업이 당연한데 과거에는 기다리기만 해야했어. 근데 동일 프로그램에대해 여러 프로세스를 만들면 자원이 중복할당되거든 그걸 해결하려고 스레드가 탄생했어 +요즘에는 파일을 다운받으면서 다른 멀티 작업이 당연한데 과거에는 기다리기만 해야했어. + +동일 프로그램에 대해 여러 프로세스를 만들면 자원이 중복 할당되는 문제가 있었어. 이 문제를 해결하려고 스레드가 탄생했어
105-126: Consider expanding on synchronization mechanisms.The section identifies the problem (race conditions) and lists solutions (mutex, semaphore, locks, monitors), but doesn't explain what these tools are or how they work.
According to the PR description, you learned that "뮤텍스는 상호 배제를 위한 동기화 객체로 한 번에 하나의 스레드만 접근하도록 한다." Consider adding brief explanations of each synchronization mechanism to make this section more educational.
💡 Suggested addition
After line 117, consider adding explanations like:
- 세마포어(Semaphore) 같은 동기화 도구들을 쓰는 거야 **뮤텍스(Mutex)**: 상호 배제를 위한 동기화 객체로, 한 번에 하나의 스레드만 공유 자원에 접근하도록 보장해 **세마포어(Semaphore)**: 동시에 접근 가능한 스레드 개수를 제한할 수 있는 카운터 기반 동기화 도구야 **락(Lock)과 모니터(Monitor)**: 임계 영역을 보호하기 위한 메커니즘으로, 모니터는 락과 조건 변수를 함께 제공해 하지만 락도 잘못 쓰면...
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
OS/MatchaKim/2026-01-14-THREAD_VS_PROCESS.md
🔇 Additional comments (8)
OS/MatchaKim/2026-01-14-THREAD_VS_PROCESS.md (8)
1-5: LGTM! Metadata follows the required format.The YAML front matter correctly includes date, user, and topic fields as required by the PR checklist.
7-28: Clear and accurate foundational concepts.The definitions of process, thread, and program are technically correct. The conversational tone makes complex concepts approachable while maintaining accuracy.
39-57: Excellent explanation of structural differences.The breakdown of process structure (memory regions + PCB) and thread structure (shared vs. private resources) is technically accurate and sets up the synchronization discussion nicely.
58-75: Strong comparison with excellent real-world example.The trade-off analysis between multi-process (stability) and multi-thread (efficiency) is well-balanced. The Chrome browser example effectively demonstrates how modern systems combine both approaches.
76-93: Clear explanation of context switching mechanics.The explanation accurately describes what context switching is, what state gets saved/restored, and why process context switches are more expensive than thread context switches.
94-104: Excellent clarification of a commonly confused distinction.The explanation clearly differentiates concurrency (task interleaving) from parallelism (simultaneous execution). The note that synchronization issues exist even on single-core systems is an important insight.
127-144: Practical guidance with clear criteria.The section provides concrete criteria for choosing between processes and threads, with relevant examples. The recommendation to combine both approaches in real systems is valuable practical advice.
145-151: Effective summary that reinforces key concepts.The summary clearly recaps the fundamental relationship between programs, processes, and threads, and shows how advanced concepts build upon these foundations.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| --- | ||
| date: 2026-01-14 | ||
| user: MatchaKim | ||
| topic: 쓰레드 vs 프로세스 | ||
| --- | ||
|
|
||
| # 프로세스가 뭐야? | ||
|
|
||
| 운영체제로부터 자원을 할당받은 작업 단위야 | ||
|
|
||
| # 쓰레드가 뭐야? | ||
|
|
||
| 프로세스가 할당받은 자원을 이용하는 실행 흐름 단위야 | ||
|
|
||
| # 프로그램은 뭐야? | ||
|
|
||
| exe나 dmg처럼 실행할 수 있는 파일을 정적 프로그램이라고 불러 | ||
|
|
||
| 프로그램은 단순히 코드 덩어리일 뿐인거야 | ||
|
|
||
| # 프로세스와 프로그램의 차이는 뭔데? | ||
|
|
||
| 프로그램이 그냥 코드덩어리 이면 프로세스는 정적인 프로그램이 동적으로 변해서 작업중인 프로그램을 의미해 | ||
|
|
||
| 모든 프로그램은 실행되기 위해서는 메모리공간이 할당되어야해 | ||
|
|
||
| 프로그램 실행순간 컴퓨터 메모리위에 올라가고 CPU를 할당받아서 우리가 이용가능한거거든 | ||
|
|
||
| # 프로세스 | ||
|
|
||
| 과거에는 프로그램 실행할때 프로세스 하나만 사용해서 이용했어 근데 프로세스 작업 하나만 사용해서 프로그램 실행은 한계가 생긴거야 | ||
|
|
||
| 요즘에는 파일을 다운받으면서 다른 멀티 작업이 당연한데 과거에는 기다리기만 해야했어. 근데 동일 프로그램에대해 여러 프로세스를 만들면 자원이 중복할당되거든 그걸 해결하려고 스레드가 탄생했어 | ||
|
|
||
| # 스레드는 뭔데? | ||
|
|
||
| 하나의 프로세스에서도 여러 작업 흐름들이 있어서 크롬에서도 우리는 파일도 다운로드하면서 온라인쇼핑을 하면서 게임을 할 수 도 있는거야 | ||
|
|
||
| # 프로세스 구조를 조금만 더 보자 | ||
|
|
||
| 프로세스 하나를 딱 찍어서 보면 안에 메모리 공간이 여러 구역으로 나뉘어 있어 | ||
| 코드가 올라가는 코드 영역, 전역변수 같은 게 있는 데이터 영역, 동적으로 잡았다가 쓰는 힙(Heap), 그리고 함수 호출하면서 쌓이는 스택(Stack) 이런 식으로 | ||
|
|
||
| 그리고 OS 입장에서는 프로세스를 관리하려고 `PCB(Process Control Block)`라는 걸 따로 들고 있어 | ||
| 여기 안에는 이 프로세스가 지금 어디까지 실행됐는지(레지스터 값, 프로그램 카운터), 어떤 상태인지(실행중, 대기중), 어떤 자원들 쓰고 있는지 이런 메타 정보들이 들어가 | ||
|
|
||
| # 스레드 구조는 어떻게 다르냐면 | ||
|
|
||
| 스레드는 프로세스 안에서 돌아가는 실행 흐름이라고 했잖아 | ||
| 그래서 하나의 프로세스 안에 스레드가 여러 개 있을 수 있는데, 이 친구들이 **공유하는 것**과 **각자 들고 있는 것**이 달라 | ||
|
|
||
| - **공유하는 것**: 코드 영역, 데이터 영역, 힙, 열린 파일 디스크립터 같은 자원들 | ||
| - **각자 따로 들고 있는 것**: 스택, 레지스터 값, 스레드 컨텍스트 정보들 | ||
|
|
||
| 그래서 같은 프로세스 안 스레드끼리는 전역변수나 힙에 있는 객체를 그대로 같이 건드릴 수 있어 | ||
| 이게 편하긴 한데, 동시에 여러 스레드가 같은 걸 만지기 시작하면 동기화 이슈가 생기는 거지 | ||
|
|
||
| # 멀티프로세스 vs 멀티스레드 | ||
|
|
||
| 이제 실제로 프로그램 설계할 때 많이 나오는 얘기가 멀티프로세스로 갈까 멀티스레드로 갈까야 | ||
|
|
||
| - **멀티프로세스** | ||
|
|
||
| - 프로세스끼리는 기본적으로 메모리를 안 공유해 (완전 다른 집이라고 보면 돼) | ||
| - 그래서 한 프로세스가 죽어도 다른 프로세스는 비교적 안전해 → **안정성** 좋음 | ||
| - 대신 서로 통신하려면 IPC(파이프, 소켓, 공유 메모리 등)를 써야 해서 구조가 조금 복잡해지고 비용도 더 들어 | ||
|
|
||
| - **멀티스레드** | ||
| - 같은 프로세스 안에서 스레드 여러 개가 돌아가니까 메모리 공유가 자연스러워 | ||
| - 문맥 전환 비용도 프로세스끼리 바꾸는 것보다 더 싸고, 자원도 덜 먹어 → **효율** 좋음 | ||
| - 대신 하나의 스레드가 메모리 잘못 건드리거나 데드락 걸리면 프로세스 전체가 같이 위험해져 | ||
|
|
||
| 그래서 크롬 같은 브라우저도 탭을 아예 프로세스로 분리해서 안정성을 챙기고, | ||
| 각 프로세스 안에서는 또 스레드를 활용해서 효율을 올리는 식으로 섞어서 써 | ||
|
|
||
| # 문맥 전환(Context Switching)은 뭐야? | ||
|
|
||
| CPU는 사실 한 번에 한 작업(한 스레드/프로세스)만 제대로 실행할 수 있는데, | ||
| 우리가 보기에는 여러 가지가 동시에 돌아가는 것처럼 느껴지잖아? | ||
| 이게 바로 문맥 전환 덕분이야 | ||
|
|
||
| 문맥 전환이란 간단히 말하면 | ||
|
|
||
| > 지금 실행하던 애의 상태를 저장해 두고, | ||
| > 다른 애의 상태를 다시 불러와서 이어서 실행하는 것 | ||
|
|
||
| 여기서 저장/복원하는 상태가 아까 말한 레지스터 값, 프로그램 카운터 같은 것들이고 | ||
| 프로세스끼리 바꿀 때가 스레드끼리 바꿀 때보다 더 비싸 | ||
| 왜냐면 메모리 맵, 캐시 같은 것도 더 크게 갈아엎어야 해서 | ||
|
|
||
| 그래서 OS 입장에서는 너무 자주 문맥 전환이 일어나도 오버헤드가 커지고, | ||
| 너무 안 바꿔줘도 특정 작업만 계속 CPU를 차지하게 되니까 적당히 스케줄링을 조절하는 거야 | ||
|
|
||
| # 멀티코어, 동시성, 병렬성 | ||
|
|
||
| 예전에는 코어가 하나라서 진짜로는 한 번에 하나만 실행하고 빠르게 번갈아가면서 돌리는 **동시성(concurrency)** 위주였는데, | ||
| 지금은 코어가 여러 개라서 진짜로 물리적으로 동시에 여러 일을 하는 **병렬성(parallelism)**도 가능해졌어 | ||
|
|
||
| - **동시성**: 실제로는 한 번에 하나씩 처리하지만, 빠르게 번갈아 해서 동시에 하는 것처럼 보이게 만드는 것 | ||
| - **병렬성**: 물리적으로 코어 여러 개가 있어서 진짜로 동시에 여러 일을 처리하는 것 | ||
|
|
||
| 스레드는 특히 멀티코어 시대에 코어를 더 잘 활용하기 위해 등장한 개념이라고 봐도 돼 | ||
| 하지만 동시성 이슈는 코어 하나만 있어도 이미 발생한다는 거 잊으면 안 돼 (번갈아가면서 같은 메모리에 접근해도 꼬일 수 있으니까) | ||
|
|
||
| # 스레드의 진짜 문제: 공유 자원과 동기화 | ||
|
|
||
| 스레드가 좋은 이유는 자원을 쉽게 공유해서 데이터 주고받기가 편하다는 건데 | ||
| 이게 동시에 가장 큰 문제를 만든다 | ||
|
|
||
| 예를 들어서 은행 계좌 잔고를 업데이트 하는 코드가 있다고 해보자 | ||
| 두 스레드가 동시에 같은 계좌 잔고를 읽고, 둘 다 더해서 저장해버리면 중간 업데이트가 날라갈 수 있어 (race condition) | ||
|
|
||
| 그래서 이런 걸 막으려고 | ||
|
|
||
| - 뮤텍스(Mutex) | ||
| - 세마포어(Semaphore) | ||
| - 락(lock)과 모니터(monitor) | ||
|
|
||
| 같은 동기화 도구들을 쓰는 거야 | ||
| 하지만 락도 잘못 쓰면 데드락(서로 서로 기다리다가 영원히 안 끝나는 상황)이 터져서 프로그램이 멈춰버릴 수 있어 | ||
|
|
||
| 정리하면 | ||
|
|
||
| - 스레드는 **공유** 때문에 편하고 빠르지만 | ||
| - 그 공유 때문에 **동기화 이슈**라는 새로운 난이도가 생긴다 | ||
|
|
||
| # 언제 프로세스를 쓰고 언제 스레드를 써? | ||
|
|
||
| 대략 이런 기준으로 생각하면 좋아 | ||
|
|
||
| - **프로세스가 더 나은 경우** | ||
|
|
||
| - 서로 완전히 분리된 서비스, 한쪽이 죽어도 다른 쪽은 안전해야 할 때 | ||
| - 보안적으로 메모리를 확실히 분리하고 싶을 때 | ||
| - 서버에서 서로 다른 역할을 하는 큰 단위 서비스를 나눌 때 (마이크로서비스 구조 등) | ||
|
|
||
| - **스레드가 더 나은 경우** | ||
| - 같은 데이터/자원을 공유하면서 여러 작업을 쪼개서 병렬 처리하고 싶을 때 | ||
| - UI 스레드 + 백그라운드 작업 스레드처럼, 하나의 프로그램 안에서 역할을 나누고 싶을 때 | ||
| - I/O 기다리는 동안 다른 일을 시키고 싶을 때 (예: 네트워크 요청 여러 개 동시에) | ||
|
|
||
| 실제 서비스에서는 둘 중 하나만 쓰기보다는 | ||
| **프로세스로 큰 덩어리를 나누고, 내부에서 스레드/이벤트 루프 등으로 세부 동시성을 관리하는 식**으로 섞어서 쓰는 경우가 많아 | ||
|
|
||
| # 한 줄로 마무리하면 | ||
|
|
||
| - 프로그램은 그냥 코드 덩어리 | ||
| - 프로세스는 그 코드가 메모리를 할당받고 실제로 돌아가는 작업 단위 | ||
| - 스레드는 그 프로세스 안에서 돌아가는 실행 흐름 단위 | ||
|
|
||
| 그리고 우리는 이 기본 개념 위에 멀티프로세스, 멀티스레드, 동시성, 병렬성, 동기화 같은 개념들을 하나씩 쌓아가면 돼 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for PR template files and contribution guidelines
find . -type f \( -name "pull_request_template.md" -o -name "CONTRIBUTING.md" -o -name "README.md" \) | head -20Repository: DongChyeon/CSteroid
Length of output: 227
🏁 Script executed:
# Check the directory structure and find this file
git ls-files | grep -i "OS/MatchaKim\|thread\|process" | head -20Repository: DongChyeon/CSteroid
Length of output: 187
🏁 Script executed:
# Look for any GitHub workflow or template files
find .github -type f 2>/dev/null | head -20Repository: DongChyeon/CSteroid
Length of output: 45
🏁 Script executed:
# Read the main README to understand repository requirements
cat -n README.md | head -100Repository: DongChyeon/CSteroid
Length of output: 3067
🏁 Script executed:
# Read OS/README.md for specific OS section requirements
cat -n OS/README.mdRepository: DongChyeon/CSteroid
Length of output: 493
🏁 Script executed:
# Check one of the other files to see what structure is being used
cat -n OS/MatchaKim/2025-09-05-MINI_OS_JVM.md | head -80Repository: DongChyeon/CSteroid
Length of output: 2305
🏁 Script executed:
# Read the full file to check if "추가 학습 필요사항" section exists
cat -n OS/MatchaKim/2026-01-14-THREAD_VS_PROCESS.md | tail -30Repository: DongChyeon/CSteroid
Length of output: 979
Add "추가 학습 필요사항" section to the document.
According to the PR guidelines in the README, each submission should include a section listing additional learning areas that need deeper study. This is missing from your document. Add it at the end before the summary to complete the PR requirements.
Regarding the reviewer's question at the end of the original comment: that's part of the normal review process where reviewers ask clarifying questions in the comments—you don't need to add a "리뷰어에게 질문" section to your document itself.
🤖 Prompt for AI Agents
In `@OS/MatchaKim/2026-01-14-THREAD_VS_PROCESS.md` around lines 1 - 151, 문서에 PR
가이드 요구사항인 "추가 학습 필요사항" 섹션이 없으니 문서 끝부분의 요약("한 줄로 마무리하면") 바로 앞에 "## 추가 학습 필요사항"
제목을 추가하고, 짧은 항목들로 앞으로 더 깊게 공부해야 할 주제를 나열하세요(예: 프로세스 간 통신(IPC) 종류와 비용, 스레드 동기화
primitives(뮤텍스/세마포어/모니터)와 데드락 회피, 문맥 전환 비용과 캐시 영향, 멀티코어에서의 병렬성 vs 동시성, 안전한 상태 공유
패턴). 또한 각 항목마다 한두 문장으로 왜 추가 학습이 필요한지 간단히 덧붙여 PR 요구사항을 충족시키세요.
1 participant
✨ 학습 주제
📄 학습 내용 요약
멀티프로세스, 멀티스레드, 동시성, 병렬성, 동기화의 기본개념을 위한 프로세스와 스레드
🔍 추가 학습 필요사항
💡 리뷰어에게 질문
✅ PR 체크리스트
과목/YYYY-MM-DD-username-topic.md형태로 업로드했습니다.📝 PR 규칙 요약
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.