Linux Container
- chroot : root 디렉토리 변경
- cgroup : 자원에 대한 제어
- namespace : 독립적 공간 제어
Kernel : 자원을 할당하고 제어해주는 기능을 담당
물리자원 : cpu / mem / net / disk
1️⃣ System Call (시스템 콜)
운영체제(OS)의 커널(kernel) 에 직접 요청을 보내는 인터페이스
🔹 개념
- 응용 프로그램이 OS 커널의 서비스를 요청하는 통로
- 즉, 사용자 영역(user mode) → 커널 영역(kernel mode)으로 권한을 전환하는 함수 호출
- 하드웨어 접근, 파일 I/O, 메모리 관리, 프로세스 제어 등은 시스템 콜 없이는 불가능
🔹 예시 (Linux 기준)
read(), write(), open(), close(), fork(), exec(), wait(), mmap()
🔹 특징
항목설명
| 위치 | 운영체제 내부 (커널) |
| 역할 | 하드웨어나 시스템 자원 접근 |
| 호출 주체 | 사용자 프로그램 |
| 예시 | read(), write(), fork() |
| 성능 | 느림 (모드 전환 발생) |
🧰 2️⃣ API (Application Programming Interface)
응용 프로그램끼리 또는 라이브러리와 프로그램 간의 인터페이스
🔹 개념
- 어떤 기능을 사용하기 위한 “함수의 집합”
- 반드시 커널과 직접 통신하지는 않음 (→ 시스템 콜을 내부적으로 쓸 수도, 안 쓸 수도 있음)
🔹 예시
printf(), fopen(), fclose(), malloc(), strcpy()
→ 이 중 fopen()은 내부적으로 open() 시스템 콜을 호출함
→ 하지만 strcpy()는 단순히 메모리 복사로 시스템 콜 없이 동작함
🔹 특징
항목설명
| 위치 | 라이브러리 / 사용자 영역 |
| 역할 | 프로그램 간 기능 제공 |
| 호출 주체 | 개발자 (응용 프로그램) |
| 예시 | printf(), fopen(), strcpy() |
| 성능 | 빠름 (커널 모드 전환 없음) |
🧠 3️⃣ 관계 요약
[응용프로그램] ↓ (API 호출) [라이브러리(glibc 등)] ↓ (System Call 발생) [운영체제 커널] ↓ [하드웨어]
즉,
- API는 개발자가 쉽게 쓰도록 만든 함수 묶음
- System Call은 그 중에서 실제 OS 기능(파일, 프로세스, 네트워크 등) 을 수행할 때 커널에 요청하는 단계
📍 예를 들어볼게요
printf("Hello");
- printf() → API (C 표준 라이브러리 함수)
- 내부에서 write() → System Call
- 커널이 실제로 “문자열을 화면(표준 출력 장치)”에 씀
🌐 REST API란?
REST(Representational State Transfer) 원칙을 따르는 API(Application Programming Interface)
즉, 웹에서 데이터를 주고받기 위한 규칙(약속) 이라고 보면 됩니다.
🧩 1️⃣ REST의 핵심 개념
REST는 HTTP 프로토콜 위에서 자원을 다루는 방식을 정의합니다.
개념설명예시
| 자원(Resource) | 서버가 제공하는 데이터나 서비스 | 사용자(user), 게시글(post), 상품(product) 등 |
| 표현(Representation) | 자원을 표현하는 형태 | JSON, XML, HTML 등 |
| 상태전달(State Transfer) | 요청을 통해 자원의 상태를 변경 | POST로 생성, PUT으로 수정 등 |
⚙️ 2️⃣ RESTful하게 만든 API의 특징
원칙설명
| ① 클라이언트-서버 구조 | 클라이언트는 UI 담당, 서버는 데이터 처리 담당 |
| ② 무상태(Stateless) | 각 요청은 독립적 — 이전 요청 상태를 서버가 기억하지 않음 |
| ③ 캐시 가능(Cacheable) | HTTP 캐시 기능을 활용해 성능 향상 |
| ④ 일관된 인터페이스(Uniform Interface) | 같은 규칙으로 모든 자원 접근 (/users, /posts 등) |
| ⑤ 계층화(Layered System) | 중간 서버(프록시, 로드밸런서 등) 가능 |
| ⑥ 자체 표현(Self-descriptive) | 요청만 봐도 무슨 동작인지 명확해야 함 (HTTP 메서드, URL로 표현) |
🧠 3️⃣ REST API의 구성
REST API는 HTTP 메서드 + URL + 상태코드로 구성됩니다.
메서드의미사용 예시
| GET | 데이터 조회 | GET /users → 모든 사용자 조회 |
| POST | 데이터 생성 | POST /users → 새 사용자 추가 |
| PUT | 데이터 수정(전체) | PUT /users/1 → ID 1번 사용자 수정 |
| PATCH | 데이터 일부 수정 | PATCH /users/1 → 이름만 수정 |
| DELETE | 데이터 삭제 | DELETE /users/1 → 사용자 삭제 |
💬 4️⃣ 예시로 보기
🎯 요청
GET /users/1 HTTP/1.1 Host: api.example.com Accept: application/json
📦 응답
{ "id": 1, "name": "장경진", "email": "kjjang@example.com" }
🔍 5️⃣ REST API vs 일반 API vs System Call
구분위치통신 방식예시
| System Call | OS 내부 | 커널 호출 | open(), read() |
| API (Library API) | 프로그램 내부 | 함수 호출 | printf(), fopen() |
| REST API | 네트워크(웹) | HTTP 요청/응답 | GET /users, POST /login |
🚀 한 줄 요약
REST API = HTTP를 이용해 자원을 주고받는 규칙이 잘 정의된 웹 통신 방식
container : 커널이 없음
Monoithic SOA CBD MSA 차이
🧱 1️⃣ Monolithic Architecture (모놀리식 아키텍처)
📘 개념
- 하나의 거대한 애플리케이션으로 구성된 구조.
- 모든 기능(프론트, 비즈니스 로직, 데이터 접근)이 하나의 코드베이스, 하나의 프로세스 안에서 동작.
✅ 장점
항목설명
| 단순성 | 구조가 단일하므로 설계와 배포가 단순함. |
| 성능 | 내부 호출이 메모리 내에서 처리되어 빠름 (네트워크 오버헤드 없음). |
| 초기 개발 속도 | 작은 규모에서는 빠르게 개발 가능. |
| 디버깅 용이 | 로그와 상태 추적이 한 프로세스 내에서 쉬움. |
❌ 단점
항목설명
| 유지보수 어려움 | 규모가 커질수록 코드 의존성이 복잡해짐. |
| 배포 부담 | 일부 기능만 바꿔도 전체 시스템 재배포 필요. |
| 확장성 제한 | 특정 기능만 확장하는 게 어려움. |
| 기술 스택 고정 | 한 서비스 내에서 여러 기술을 혼용하기 힘듦. |
🧩 2️⃣ SOA (Service-Oriented Architecture, 서비스 지향 아키텍처)
📘 개념
- 시스템을 “서비스” 단위로 분리하지만, 각 서비스는 ESB(Enterprise Service Bus) 같은 중앙 통신 허브를 통해 상호작용.
- 보통 SOAP 기반 웹서비스(WSDL, XML 등)를 사용.
✅ 장점
항목설명
| 재사용성 | 각 서비스가 독립적이어서 다른 시스템에서도 재사용 가능. |
| 유연성 | 서비스 단위로 개발 및 배포 가능. |
| 이기종 통합 | 다양한 언어, 플랫폼 간 통신 가능 (예: Java ↔ .NET). |
❌ 단점
항목설명
| 복잡한 통신 | ESB나 중앙 관리 시스템이 복잡하고 병목 가능. |
| 오버헤드 | SOAP/XML 기반 통신은 무겁고 느림. |
| 관리 부담 | 서비스 수가 많아질수록 중앙 버스 관리가 어려움. |
🧰 3️⃣ CBD (Component-Based Development, 컴포넌트 기반 개발)
📘 개념
- 시스템을 재사용 가능한 “컴포넌트” 단위로 분리하여 조립하듯 개발.
- 컴포넌트는 내부적으로 독립적이지만, 일반적으로 동일 애플리케이션 내부에서 동작.
✅ 장점
항목설명
| 재사용성 | 공통 컴포넌트를 여러 프로젝트에서 활용 가능. |
| 유지보수성 | 특정 기능 변경 시 컴포넌트 단위로 수정 가능. |
| 생산성 향상 | 검증된 컴포넌트로 개발 시간 단축. |
❌ 단점
항목설명
| 의존성 관리 | 컴포넌트 간 인터페이스 변화 시 전체 영향 가능. |
| 배포 단위 제한 | 전체 시스템 배포와 연결된 경우가 많음. |
| 성능 저하 | 추상화 계층이 많아질수록 성능 저하 가능. |
☁️ 4️⃣ MSA (Microservice Architecture, 마이크로서비스 아키텍처)
📘 개념
- SOA의 진화된 형태로, 각 서비스를 완전히 독립적인 마이크로서비스로 구성.
- 각 서비스는 별도 DB, 별도 배포 파이프라인, REST/gRPC 통신 등으로 완전히 분리.
✅ 장점
항목설명
| 독립 배포 | 서비스별로 독립 개발·배포 가능. |
| 확장성 | 필요한 서비스만 개별적으로 스케일 아웃 가능. |
| 기술 다양성 | 각 서비스마다 다른 언어/프레임워크 사용 가능. |
| 장애 격리 | 하나의 서비스 장애가 전체 시스템에 영향 제한. |
❌ 단점
항목설명
| 운영 복잡성 | 수십~수백 개 서비스 관리 필요. |
| 분산 트랜잭션 문제 | 여러 서비스 간 데이터 일관성 유지 어려움. |
| 통신 비용 | 네트워크 호출 증가로 성능 부담 가능. |
| 배포·모니터링 도구 필요 | CI/CD, Service Mesh, API Gateway 등 인프라 필요. |
📊 요약 비교표
항목MonolithicCBDSOAMSA
| 구조 단위 | 하나의 애플리케이션 | 컴포넌트 | 서비스 (중앙 ESB) | 독립 마이크로서비스 |
| 통신 방식 | 내부 호출 | 내부 호출 | ESB / SOAP | REST / gRPC / Message Queue |
| 배포 단위 | 전체 | 전체 | 서비스별 | 서비스별 |
| 확장성 | 낮음 | 보통 | 중간 | 높음 |
| 복잡도 | 낮음 | 중간 | 높음 | 매우 높음 |
| 기술 다양성 | 제한적 | 일부 가능 | 가능 | 매우 유연 |
| 적합한 규모 | 소형 프로젝트 | 중형 | 대규모 엔터프라이즈 | 클라우드 네이티브 대규모 |
💡 정리 포인트
상황추천 아키텍처
| 스타트업 초기 MVP | Monolithic (빠르게 개발, 유지보수 쉬움) |
| 공통 기능 재사용 많은 사내 시스템 | CBD |
| 기업 내부 여러 시스템 통합 | SOA |
| 대규모 트래픽 / 독립적 서비스 / 클라우드 환경 | MSA |
도커 3단계
- build
- ship
- run
4단계로 구성하면
- dev
- build
- ship
- run
CI [dev] : dev -> build
CD [ops] : ship -> run