안녕하세요! 그로스로그 입니다!😊 🌱
추상화가 왜 인간의 가장 강력한 능력인지, 현실을 데이터로 옮기는 세 단계, CPU가 순서를 정하는 규칙들입니다.
5기 1회차 두 번째 묶음입니다. 앞의 두 편이 아키텍처 경계를 다뤘다면, 이번 세 편은 복잡한 것을 다룰 수 있는 크기로 줄이는 일을 각각 다른 높이에서 이야기합니다.
01
🧠 개발자처럼 사고하기: 시작하기 전에 '이것'만 알아두세요
홍범영 님
"코드를 잘 치는 법"이 아니라 코드 전에 알아야 할 사고방식을 다룬 글입니다. 부제가 "전공 서적보다 의외로 쓸모 있을지도?"예요.
첫 질문이 이렇습니다 — 인간의 가장 강력한 지적 능력은 무엇인가. 창의력도 상상력도 언어도 아니라고 답합니다.
답은 추상화(Abstraction)입니다. 그리고 그 추상화를 표현하는 궁극의 언어가 수학이라는 데까지 이어집니다.
개발을 막 시작했거나 시작하려는 사람을 위해 쓴 글인데, 출발점이 남다릅니다.
조금 더 들어가 보면
퀴즈로 시작합니다. "인간의 가장 강력한 지적 능력은 뭘까요? 창의력? 상상력? 언어?"
그리고 답을 냅니다.
정의도 붙입니다 — 복잡한 현실에서 핵심만 뽑아내 단순한 구조로 만드는 능력.
🍎 일상에서 이미 하고 있는 일
설명이 좋은 건 예시를 멀리서 찾지 않아서입니다.
추상화가 특별한 기술이 아니라 이미 쓰고 있는 능력이라는 걸 먼저 보여줍니다. 그래야 그다음이 받아들여지니까요.
➗ 추상화의 언어는 수학
여기서 한 층 올라갑니다.
"의미를 제거하고 구조만 남긴다" — 수학을 이렇게 설명한 문장이 인상적입니다. 계산 도구가 아니라 덜어내는 언어로 본 것이죠.
그리고 예시가 F = ma입니다.
떨어지는 사과와 도는 행성과 나는 로켓이 세 글자로 줄어드는 장면입니다. 추상화가 무엇인지 설명하는 데 이보다 나은 예가 드뭅니다.
큐레이터 노트
코드 이전의 이야기를 코드 없이 쓴 글이라 뽑았습니다.
개발 입문 글은 대개 언어나 도구에서 시작합니다. 이 글은 "코드를 잘 치는 법이 아니라, 코드 전에 알아야 할 사고방식"이라고 범위를 먼저 정하고 들어가요. 그래서 코드가 한 줄도 없는데 개발 이야기가 됩니다.
독자를 정확히 잡은 것도 좋았습니다. 부제의 "전공 서적보다 의외로 쓸모 있을지도?"는 전공 서적을 펼쳤다가 막힌 사람을 향한 말이에요. 그런 사람에게 필요한 건 문법이 아니라 왜 이렇게 생각하는가니까요.
그리고 이 글이 놓인 자리가 특별합니다. 5기 1회차, 기수가 막 시작하던 무렵에 올라온 글이에요. 앞으로 배울 것들 앞에 "이걸 먼저 알아두면 나머지가 이해된다"를 놓은 셈입니다. 실제로 이 회차의 다른 글들 — 아키텍처 레이어, 데이터 모델, 스케줄링 알고리즘 — 이 전부 추상화의 사례이기도 하고요.
02
🗃️ [정처기 실기] 데이터베이스 입출력 구현
엄수현 님
정보처리기사 실기의 데이터베이스 입출력 구현 파트를 통째로 정리한 글입니다. 분량이 상당합니다.
데이터 모델 → 논리 데이터 모델 → 물리 데이터 모델로 내려가는 세 단계를 각각 다루고, 데이터베이스 종류까지 이어집니다.
시작 문장이 정직해요. "이번주에 너무 공부가 하기 싫을 때, 데이터베이스 부분이 가장 쉬웠기 때문에(나에게) 손이라도 움직이자 싶어 정리해둔 내용이다."
시험 정리 글인데, 정리한 이유가 먼저 적혀 있습니다.
조금 더 들어가 보면
데이터 모델의 정의부터 봅시다. 여기에 추상화라는 단어가 그대로 나옵니다.
앞의 홍범영 님 글이 말한 그 능력이 데이터베이스 설계의 정의 안에 들어 있는 것입니다. 복잡한 현실을 인간도 기계도 다룰 수 있는 형태로 줄이는 일이요.
그리고 데이터 모델에 표시해야 할 요소를 셋으로 나눕니다.
· 구조(Structure) — 논리적으로 표현될 대상으로서의 개체 타입과 개체 타입 간의 관계. 데이터 구조 및 정적 성질
· 연산(Operation) — 데이터를 처리하는 작업
· 제약 조건(Constraint) — 지켜야 할 규칙
무엇이 있고 · 무엇을 할 수 있고 · 무엇을 하면 안 되는가. 이 셋이면 모델이 됩니다.
🪜 개념에서 물리로 내려가는 세 단계
글의 뼈대가 이 세 층입니다.
| 단계 | 무엇을 정하는가 |
|---|---|
| 개념 데이터 모델 | 현실 세계를 인간이 이해할 수 있는 형태로 — 개체와 관계 |
| 논리 데이터 모델 | 특정 DBMS 방식에 맞춰 — 테이블·키·정규화 |
| 물리 데이터 모델 | 실제 저장 구조로 — 인덱스·파티션·성능 |
같은 대상을 세 번 그리는데 매번 다른 것을 버립니다. 개념 단계에서는 저장 방식을 신경 쓰지 않고, 논리 단계에서는 성능을 미루고, 물리 단계에서 비로소 디스크를 봅니다.
이게 왜 필요하냐면 — 한 번에 다 정하려 하면 아무것도 못 정하기 때문입니다. 현실은 복잡하고 고려할 게 너무 많으니, 층을 나눠 한 번에 한 종류의 결정만 내리는 것이죠.
큐레이터 노트
공부가 안 되는 날의 대처법을 같이 적은 글이라 뽑았습니다.
시험 정리 글은 많지만, 대개 정리 결과만 있습니다. 이 글은 첫 문단에 왜 하필 이 파트를 정리했는지를 적어요.
하기 싫은 날에 가장 쉬운 것부터 손대는 것. 의욕이 없을 때 제일 어려운 걸 붙잡으면 그날은 통째로 날아갑니다. 쉬운 것부터 시작하면 최소한 뭔가는 남고요. 시험 준비를 하는 회원이라면 이 한 줄이 정리 내용만큼 쓸모 있을 겁니다.
분량도 그 자체로 기록입니다. "손이라도 움직이자"로 시작한 것이 데이터 모델 세 단계를 전부 훑는 글이 됐어요. 시작할 때의 마음과 끝난 뒤의 결과가 이만큼 벌어지는 게 공부의 흔한 모습이기도 합니다.
정보처리기사를 준비하는 회원이 많은 기수라, KNOU CS 스터디 자료로 바로 쓸 수 있는 정리이기도 합니다.
03
⏱️ [혼자 공부하는 컴퓨터구조 운영체제] 11장 - CPU 스케줄링
정지은 님
『혼자 공부하는 컴퓨터구조 + 운영체제』 11장을 정리한 글입니다. 프로세스 우선순위 · 스케줄링 큐 · 선점형과 비선점형을 먼저 짚고 알고리즘 일곱 가지를 하나씩 다룹니다.
그런데 여기서 끝나지 않아요. 마지막 장이 「백엔드 Java 개발자 관점의 추가 고려 사항」입니다. JVM 스레드와 OS 스케줄링의 관계를 따로 봅니다.
시작이 이렇습니다 — "작년에 지인들과 스터디로 시작했던 책을 아직도 다 못 뗐다는 게 슬퍼지는 요즘이다."
책 요약에서 멈추지 않고 자기 분야로 한 걸음 더 간 글입니다.
조금 더 들어가 보면
CPU 스케줄링이 무엇인지부터 한 줄로 잡습니다.
그리고 왜 필요한지를 답니다 — 다중 프로그래밍 환경에서 CPU 이용률을 극대화하고 프로세스들을 공평하고 효율적으로 처리하기 위해서라고요.
여기에 이미 긴장이 하나 들어 있습니다. 효율과 공평이 늘 같은 방향은 아니라는 것. 뒤에 나오는 알고리즘들이 전부 이 둘 사이 어디쯤에 놓입니다.
🔀 알고리즘 일곱 개가 놓인 자리
글이 다루는 알고리즘 목록입니다.
· FCFS (First-Come, First-Served) — 온 순서대로
· SJF (Shortest Job First) — 짧은 것부터
· 라운드 로빈 — 정해진 시간만큼씩 돌아가며
· SRT (Shortest Remaining Time) — 남은 시간이 짧은 것부터
· 우선순위 스케줄링 — 중요한 것부터
· 다단계 큐 — 성격별로 줄을 나눠서
· 다단계 피드백 큐 — 줄 사이를 오갈 수 있게
단순한 것에서 복잡한 것으로 순서가 짜여 있습니다. FCFS는 규칙이 하나뿐이라 이해하기 쉽지만 긴 작업이 앞에 오면 뒤가 다 기다립니다. SJF는 그걸 고치는데 긴 작업이 영원히 밀릴 수 있고요. 각 알고리즘이 앞 알고리즘의 약점에 대한 답인 셈입니다.
마지막의 다단계 피드백 큐가 그 끝인데, 줄을 나눈 것도 모자라 줄 사이를 오갈 수 있게 만든 겁니다. 규칙 하나로 안 되니 규칙을 계층으로 쌓은 것이죠.
그리고 스케줄링 성능 척도를 따로 다룹니다. 무엇을 좋다고 할 것인가를 정의하지 않으면 알고리즘을 비교할 수 없으니까요.
🧵 자기 분야로 연결한 마지막 장
이 글의 값어치가 여기 있습니다. 책 요약 뒤에 「백엔드 Java 개발자 관점의 추가 고려 사항」을 붙였어요. 첫 항목이 JVM 스레드와 OS 스케줄링의 관계입니다.
도입부에 그 의도가 적혀 있습니다.
요약과 확장을 나눠서 적은 것이 정확합니다. 어디까지가 책 내용이고 어디부터가 자기 질문인지 구분되니까요.
큐레이터 노트
흩어진 스터디를 혼자 이어간 기록이라 뽑았습니다.
시작 문단이 이 글의 성격을 정합니다.
스터디가 흐지부지되는 건 흔한 일입니다. 대개 거기서 그 책도 끝나고요. 이 글은 모임이 없어져도 진도를 이어가는 방법을 보여줍니다 — 성장일지에 정리해서 올리는 것으로요.
괄호 안의 솔직함도 좋았습니다. "(겸사겸사 이번회차 성장일지를 채우기도...^^;;)" 성장일지가 공부를 끌고 가는 장치로 실제로 작동한 사례입니다.
책 요약에서 한 걸음 더 간 것이 이 글을 다른 정리 글과 가릅니다. 11장을 읽고 끝내는 대신 "내 분야에서는 이게 어떻게 걸리나"를 물었어요. JVM 스레드와 OS 스케줄링의 관계는 책에 없는 질문이고, 그 질문이 있어야 배운 게 자기 것이 됩니다.
💡 세 편을 겹쳐 읽으며
사고방식 이야기 한 편, 자격증 정리 한 편, 전공서 정리 한 편입니다. 그런데 세 편이 같은 일을 다른 높이에서 하고 있습니다.
복잡한 것을 다룰 수 있는 크기로 줄이기
홍범영 님이 추상화란 무엇인가를 말합니다. "복잡한 현실에서 핵심만 뽑아내 단순한 구조로 만드는 능력." 사과 품종을 "사과"로 묶고, 물리 현상들을 F = ma로 줄이는 일이요.
엄수현 님 글의 데이터 모델 정의가 그 말을 그대로 반복합니다 — "현실 세계의 정보를 인간과 컴퓨터가 이해할 수 있도록 추상화하여 표현한 모델." 개념 → 논리 → 물리로 내려가면서 매번 다른 것을 버립니다.
정지은 님 글의 스케줄링 알고리즘도 같습니다. 수십 개 프로세스가 뒤섞인 상황을 "온 순서대로" 나 "짧은 것부터" 같은 규칙 하나로 줄이는 일이니까요.
추상화는 개념이 아니라 이 셋이 전부 하고 있는 작업입니다.
한 번에 다 정하지 않는다
두 번째 공통점은 층을 나눈다는 것입니다.
엄수현 님 글의 세 단계가 명시적입니다. 개념 단계에서는 저장 방식을 신경 쓰지 않고, 논리 단계에서는 성능을 미룹니다. 한 번에 한 종류의 결정만 내리는 구조예요.
정지은 님 글의 다단계 피드백 큐도 마찬가지입니다. 규칙 하나로 모든 상황을 감당하려다 실패하니 줄을 나누고, 그 줄 사이를 오갈 수 있게 만들었습니다.
홍범영 님의 F = ma도 그렇습니다. 뉴턴이 사과와 행성과 로켓을 각각 설명하려 했다면 세 글자가 안 나왔을 거예요. 공통된 것만 남기고 나머지를 버렸기 때문에 가능했습니다.
공부를 이어가는 장치를 각자 찾았다
세 번째는 태도입니다. 셋 다 공부가 끊길 수 있는 상황을 지나고 있었어요.
엄수현 님은 공부가 하기 싫은 주였고, 그래서 가장 쉬운 파트부터 손댔습니다. 정지은 님은 스터디가 흩어진 뒤였고, 그래서 성장일지에 정리해 올리기로 했습니다. 홍범영 님은 전공 서적이 어려운 사람을 위해 그 앞에 놓을 것을 썼고요.
의욕이 있을 때 공부하는 건 누구나 합니다. 이 세 편은 의욕이 없거나 함께 하던 사람들이 사라진 뒤에도 이어가는 방법에 관한 기록입니다.
이번 회차에서 가져갈 것
1. 추상화는 특별한 기술이 아니라 이미 쓰는 능력.
사과 품종을 "사과"로 묶는 게 추상화입니다. 코드에서 하는 일도 결국 같은 일이라는 걸 알면 클래스나 함수를 나누는 기준이 달라집니다.
2. 모델을 정의하려면 세 가지가 필요하다.
구조(무엇이 있는가) · 연산(무엇을 할 수 있는가) · 제약(무엇을 하면 안 되는가). 이 셋을 적어보면 설계가 됩니다.
3. 개념 → 논리 → 물리를 한 번에 하려 하지 않기.
개념 단계에서 인덱스를 고민하면 아무것도 못 정합니다. 각 층에서 무엇을 미룰지를 정하는 게 층을 나누는 이유입니다.
4. 스케줄링 알고리즘은 앞 알고리즘의 약점에 대한 답.
FCFS → SJF → RR → 다단계 피드백 큐로 가는 흐름이 그렇습니다. 외우지 말고 무엇을 고치려 한 것인지를 따라가면 순서가 이해됩니다.
5. 공부가 하기 싫은 날은 가장 쉬운 것부터.
그날 제일 어려운 걸 붙잡으면 하루가 통째로 날아갑니다. "손이라도 움직이자"로 시작한 정리가 결국 한 파트를 다 덮기도 합니다.
6. 스터디가 흩어져도 진도는 이어갈 수 있다.
정리해서 올리는 것 자체가 장치가 됩니다. 성장일지처럼 제출 기한이 있는 곳에 쓰면 더 잘 굴러갑니다.
7. 책을 요약했으면 "내 분야에서는?"을 한 줄 붙이기.
JVM 스레드와 OS 스케줄링처럼요. 그 한 줄이 있어야 요약이 자기 지식이 됩니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.
좋은 글 남겨주신 홍범영 님, 엄수현 님, 정지은 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.
'성장일지' 카테고리의 다른 글
| [GL 5기 2회차 ②] 빨라진 만큼 방향이 무거워진다 — 바이브 코딩 이후 · 개발자의 자리 · GPU 스케줄러 보상 설계 🌱 (0) | 2026.08.11 |
|---|---|
| [GL 5기 2회차 ①] 조용히 틀리는 것들 — MQTT QoS · 브라우저 자동완성 · 기다리며 움직이기 🌱 (0) | 2026.08.11 |
| [GL 5기 1회차 ①] 약속 대신 구조가 지키게 — CQRS와 의존성 주입 · FSD 아키텍처 🌱 (0) | 2026.08.11 |
| [GL 5기 1회차] 약속 대신 구조가 지키게 — CQRS와 의존성 주입 · FSD 아키텍처 🌱 (0) | 2026.08.11 |
| [GL 4기 10회차 ①] 결론을 미루는 설계 — 현대사 검색 앱, 이벤트 기반 아키텍처, 점심 메뉴 투표 🌱 (0) | 2026.08.11 |