• OS는 “있으면 좋은 것”이 아니라, 장애를 막는 안전장치다.
• 커널은 프로그램 대신 CPU·메모리·디스크·네트워크를 중재한다.
• RAM 용량보다 swap·OOM·I/O wait을 볼 줄 아는 게 더 중요하다.

1️⃣ OS가 왜 필요하냐고요? “장애가 나면” 바로 답이 나옵니다

운영체제는 평소엔 존재감이 거의 없습니다.
그런데 서버가 느려지거나, 서비스가 갑자기 죽으면 상황이 달라집니다.

제가 실제로 겪었던 케이스들입니다.

• 사이트가 갑자기 느려짐 → CPU 100% / I/O wait 증가 / swap 사용
• 잘 돌아가던 서비스가 새벽에 죽음 → OOM Killer
• 디스크 꽉 참 → 로그·백업·Docker 잔여물 폭증
• SSH는 되는데 서비스는 안 뜸 → 권한/실행 계정 문제

이때 OS는 배경이 아니라 사건 현장입니다.
커널·프로세스·메모리를 모르면 원인 추적 속도가 확실히 느립니다.

2️⃣ 한 문장 정의

운영체제(OS)는 프로그램이 하드웨어를 안전하게 쓰도록 중재하는 관리자입니다.

3️⃣ 그림 하나로 이해하기

OS를 이렇게 생각하면 편합니다.

• 프로그램 = 요청하는 사람
• 하드웨어(CPU/디스크/네트워크) = 자원
• 커널 = 자원 배분 관리자

프로그램은 직접 CPU를 잡지 못합니다.
항상 커널을 통해서만 접근합니다.

4️⃣ 커널(Kernel): 내가 모르는 사이에 다 대신 처리하는 관리자

워드프레스 기준으로 보면 흐름은 이렇습니다.

1. 브라우저 요청 도착
2. 커널이 네트워크 패킷 수신
3. 웹서버(Nginx/Apache) 프로세스에 전달
4. 디스크에서 파일 읽기
5. PHP 프로세스가 DB 접근
6. 결과를 다시 네트워크로 전송

여기서 느려지면 보통 커널이 관리하는 자원 중 하나가 병목입니다.

제가 실제로 겪은 사례 3가지

✔ CPU는 30%인데 서버가 멈춘 느낌
→ 원인은 I/O wait (디스크 대기)

✔ 트래픽 증가 후 502/504
→ 동시 연결 수 / 파일 핸들 한계

✔ systemd로 실행하면 실패
→ 실행 계정 권한 문제

앱만 보면 안 보이고, OS 자원 관점으로 봐야 잡히는 문제입니다.

5️⃣ 프로세스(Process): 범인을 찾는 출발점

실무에서 OS를 보는 가장 현실적인 이유는 단순합니다.

누가 자원을 먹고 있는지 찾는 것

제가 항상 하는 순서:

top
free -h
df -h

• CPU 100% 프로세스 → 무한 루프/계산 문제 가능성
• 메모리 계속 증가 → 누수 가능성
• 프로세스 사라짐 → OOM / 크래시 확인

그리고 경험상, 프로세스는 거짓말을 하지 않습니다.

• CPU 100% 찍는 프로세스가 있으면, 뭔가 계산/루프/대기 문제가 있고
• 메모리가 계속 늘면, 누수(Leak)거나 캐시가 풀리지 않는 구조일 가능성이 높고
• 프로세스가 죽어 있으면, 누가 죽였는지(OOM/크래시/kill)를 OS 로그에서 찾을 수 있어요.

“프로세스가 여러 개라서 더 안전해진” 경험

예전에 한 번은 웹서버+PHP가 한 덩어리처럼 꽉 묶여 있어서
하나가 죽으면 전체가 불안정해졌던 적이 있어요.
그 뒤로는 프로세스 분리/풀 관리가 되는 구조(Nginx ↔ PHP-FPM)를 선호하게 됐습니다.

• 문제가 생겨도 “부분”만 영향을 받는 구조
• 그리고 문제를 “프로세스 단위”로 좁혀서 해결이 쉬움

6️⃣ 메모리(Memory): RAM보다 swap과 OOM이 핵심

초보 때는 “RAM이 많으면 안전하다”고 생각했습니다.
운영해보니 포인트는 다르더군요.

메모리 문제의 전형적인 흐름

1. 체감상 느려짐
2. swap 사용량 증가
3. load 상승
4. OOM Killer가 프로세스 강제 종료

가장 당황스러운 순간은:

“내가 내린 적 없는데 서비스가 죽어 있음”

하지만 OS는 흔적을 남깁니다.

dmesg | grep -i oom
journalctl -xe

여기서 거의 다 나옵니다.

오해했던 부분: RAM 사용률

free -h에서 RAM이 거의 다 차 있어도
그게 반드시 문제는 아닙니다.

리눅스는 캐시를 적극 활용합니다.

진짜 위험 신호는:

• swap이 계속 증가
• OOM 로그 발생

• 리눅스면 보통 dmesg / journalctl에서 OOM 흔적을 찾을 수 있어요.

캐시는 “정상”인데, 오해하기 쉬웠던 경험

리눅스에서 free -h 보면 RAM이 대부분 사용 중으로 보이는데
그게 꼭 문제는 아니더라고요.

• OS가 캐시로 RAM을 적극 활용하는 게 정상
• 문제는 캐시가 아니라 스왑이 늘고 반응이 무너질 때입니다.

즉, “RAM 사용률”보다 “swap/oom”을 더 경계하게 됐어요.

7️⃣ 워드프레스 글 하나 열 때 OS 안에서 벌어지는 일

사용자 요청
→ 커널이 네트워크 처리
→ 웹서버 프로세스 실행
→ PHP-FPM 동작
→ DB 접근 (네트워크/디스크 I/O)
→ 응답 반환

이 중 하나라도 병목이면 체감이 바로 느려집니다.

그래서 OS를 이해하면 이런 감이 생깁니다.

“이건 코드가 아니라 I/O 같다.”
“CPU가 아니라 메모리 압박이다.”

이 감이 운영에선 정말 큽니다.

8️⃣ 제가 쓰는 3분 점검 루틴

서버가 느릴 때 저는 거의 이 순서입니다.

top
free -h
df -h
iostat
journalctl -xe

1. 누가 CPU/RAM 먹는지
2. swap 증가 여부
3. 디스크 용량
4. I/O wait
5. OOM/크래시 로그

이 루틴이 습관이 되면
OS는 시험 과목이 아니라 장애 해결 지도가 됩니다.

9️⃣ 자주 하는 실수 TOP3

1️⃣ CPU만 보고 판단
→ 실제 원인은 I/O wait

2️⃣ RAM 사용률만 보고 “메모리 부족” 단정
→ 캐시 정상 사용일 수 있음

3️⃣ 애플리케이션 로그만 보고 OS 로그 안 봄
→ OOM은 커널 로그에 남음

🔟 체크리스트

• CPU %만 보지 않는다
• swap 증가 여부 확인
• OOM 로그 확인
• 디스크 용량 주기 점검
• 프로세스 단위로 문제를 좁힌다

FAQ

Q1. OS를 알면 코딩에도 도움이 되나요?
네. 왜 느려지는지, 왜 죽는지가 보이기 시작합니다.

Q2. 커널을 직접 건드릴 일도 있나요?
직접 수정은 거의 없지만, 로그와 자원 상태를 읽는 일은 매우 많습니다.

Q3. 메모리 위험 신호는 무엇인가요?
RAM 사용률보다 swap 증가와 OOM 로그가 더 위험 신호였습니다.

게시물 운영체제(OS)는 왜 필요한가? — 장애가 나면 답은 결국 OS 안에 있다이 하우인포-IT·테크에 처음 등장했습니다.

• 느려짐 원인은 대부분 CPU / 메모리(swap) / 디스크 I/O / 프로세스 폭주 중 하나다.
• Load는 CPU 사용률이 아니라 “밀린 작업량”이다.
• wa(iowait)가 높으면 CPU 문제가 아니라 디스크 병목일 가능성이 크다.
• swap이 증가하면 체감 성능은 급격히 나빠진다.
• top → htop → 원인별 1개 명령 추가 확인이면 대부분 10분 안에 범위를 좁힐 수 있다.

1️⃣ 문제 상황

어느 날 갑자기 이런 연락이 옵니다.

• “사이트가 너무 느려요.”
• “SSH는 되는데 명령이 버벅여요.”
• “DB 쿼리가 갑자기 지연됩니다.”

이때 제 머릿속에 가장 먼저 뜨는 후보는 네 가지입니다.

1. CPU 과부하
2. 메모리 부족(swap)
3. 디스크 I/O 병목
4. 프로세스 폭주

2️⃣ 내 환경 (예시 기준)

• Ubuntu 22.04
• 4 vCPU / 8GB RAM
• Nginx + PHP-FPM + MariaDB
• Docker 일부 사용

※ 코어 수에 따라 Load 해석이 달라지므로 환경은 항상 먼저 확인합니다.

nproc

3️⃣ 1차 가설

처음엔 대부분 “CPU가 문제인가?”부터 의심합니다.

하지만 경험상 절반 이상은 CPU가 아니었습니다.

특히:

• Load 높음 + CPU idle 많음 → 디스크 병목
• 체감 심한 느려짐 + swap 증가 → 메모리 압박

그래서 1차 스냅샷은 반드시 OS 레벨에서 봅니다.

4️⃣ 1분 스캔: top으로 상태 스냅샷

top

1️⃣ Load average

Load는 CPU 사용률이 아닙니다.
“대기 중인 작업 수”에 가깝습니다.

4코어 서버 기준:

• 0~4 → 정상 범위
• 6~10 → 병목 의심
• 10 이상 → 거의 확실히 무언가 막힘

2️⃣ CPU 라인 해석

• id 낮고 us 높음 → 연산/쿼리/압축 등 CPU 사용
• sy 높음 → 커널/네트워크/컨텍스트 스위칭
• wa 높음 → 디스크 기다리는 중 (I/O 병목)

⚠ wa가 15~20% 이상이면 디스크 문제 가능성 높음

3️⃣ 메모리 / Swap

• Swap 사용 증가 = 체감 성능 급락 시작
• RAM 사용률만 보고 판단하면 안 됨

5️⃣ 3분: htop으로 범인 찾기

htop

• F6 → CPU% 정렬
• F6 → MEM% 정렬
• 필요 시 “Show threads” 활성화

확인 포인트:

• 특정 프로세스가 계속 튀는가?
• 같은 서비스가 여러 개 과도하게 생성되는가?
• 사용자 계정이 예상과 다른가?

6️⃣ 원인별 다음 확인 (한 번만 더 본다)

① CPU 과부하 (us/sy 높음)

ps -eo pid,user,ppid,cmd,%cpu,%mem --sort=-%cpu | head

확인:

• 배치 작업인가?
• 쿼리 폭주인가?
• 무한 루프인가?

운영 팁:
재시작은 임시 해결일 뿐.
로그를 먼저 확인해야 재발 방지 가능.

② 메모리 부족 (swap 증가)

free -h

확인:

• swap 사용량
• 캐시 vs 실제 사용 메모리

운영 팁:

• 도커 메모리 제한 설정 점검
• 자바/DB 힙 설정 확인
• OOM 로그 확인

dmesg | grep -i oom

③ 디스크 I/O 병목 (wa 높음)

df -h

90% 이상이면 위험 구간.

sudo du -h -d 1 /var | sort -h | tail

로그/도커 파일 폭증 확인.

가능하면:

iostat -xz 1 3

I/O wait가 높고 await 값이 크면 디스크 병목.

운영 경험상:

• /var/log 폭증
• Docker json 로그 무제한 증가
• 백업 파일 미정리

이 세 가지가 단골입니다.

④ 프로세스 폭주 / 좀비

ps -eLf | wc -l

좀비 프로세스:

ps aux | awk '$8 ~ /Z/ { print }'

systemd 실패 확인:

systemctl --failed

크래시 루프는 CPU보다 더 체감 성능을 떨어뜨립니다.

7️⃣ 실제 원인 패턴 (운영 경험)

제가 겪은 실제 비율 체감:

• 디스크 I/O 병목: 35%
• 메모리(swap) 문제: 30%
• CPU 과부하: 20%
• 프로세스/크래시 루프: 15%

의외로 CPU는 가장 흔한 원인이 아니었습니다.

8️⃣ 해결 후 반드시 하는 것 (재발 방지)

✔ 로그 보존 및 원인 기록
✔ swap 사용률 모니터링 추가
✔ 디스크 80% 이상 알림 설정
✔ Docker 로그 제한 설정
✔ 주기적 용량 점검 자동화

임시 재시작만 하고 끝내면, 같은 장애가 반복됩니다.

9️⃣ 10분 진단 루틴 정리

1️⃣ top → Load / id / wa / swap
2️⃣ htop → CPU% / MEM% 정렬
3️⃣ 원인별 명령 1개만 추가
4️⃣ 임시 조치 + 로그 확인
5️⃣ 재발 방지 설정

🔟 자주 하는 실수

• Load만 보고 CPU 문제로 단정
• wa를 안 보고 CPU%만 보는 실수
• swap 증가를 정상으로 넘김
• 디스크 95%인데 방치
• 재시작만 하고 원인 기록 안 남김

📌 교훈

느려짐은 대부분 “OS 자원 병목”입니다.
애플리케이션부터 의심하기보다,
커널이 관리하는 CPU/메모리/I/O 상태를 먼저 보는 습관이
장애 대응 속도를 가장 빠르게 올려줍니다.

게시물 서버가 갑자기 느려질 때: TOP/HTOP로 10분 안에 범위 좁히는 방법이 하우인포-IT·테크에 처음 등장했습니다.

• **프로세스(Process)**는 서로 독립된 메모리 공간을 가진 실행 단위입니다.
• **스레드(Thread)**는 같은 프로세스 안에서 메모리를 공유하는 실행 흐름입니다.
• 프로세스는 격리(안전성)가 강점, 스레드는 속도와 자원 효율이 강점입니다.
• 실무에선 보통 “프로세스 여러 개 + 스레드”를 혼합합니다.
• 장애/성능/자원 관점에서 이해하면 튜닝 포인트가 보입니다.

1️⃣ 먼저 상황부터: “왜 갑자기 서버가 전체로 죽었지?”

운영하다 보면 이런 순간이 옵니다.

• 특정 서비스 하나만 느린 게 아니라 전체가 버벅임
• 워커 하나가 죽었는데 전체 서비스가 영향을 받음
• CPU는 널널한데 응답이 밀림

이럴 때 원인을 좁히려면
“이게 프로세스 문제인가? 스레드 문제인가?”를 구분할 줄 알아야 합니다.

2️⃣ 핵심 정의 3개 (딱 필요한 만큼만)

• 프로세스: 운영체제가 관리하는 독립 실행 단위 (주소 공간 분리)
• 스레드: 하나의 프로세스 안에서 실행되는 경량 실행 단위 (메모리 공유)
• 컨텍스트 스위칭: 실행 대상을 바꿀 때 드는 전환 비용 (프로세스가 더 큼)

3️⃣ 한 장으로 보는 차이

4️⃣ 실무에서 가장 많이 보는 구조

예시 A) 웹서버 구조

보통 구조는 이렇습니다.

프로세스 여러 개(워커) + 각 워커 내부 스레드

이유:

• CPU 코어 활용을 위해 프로세스를 여러 개 띄움
• 각 프로세스 안에서 스레드로 동시 요청 처리

예:

• Nginx → 마스터 + 워커 프로세스 구조
• Java 서버 → 프로세스 1개 + 스레드풀 다수
• PHP-FPM → 여러 워커 프로세스

실무 포인트:

• 워커 하나 죽어도 전체는 유지 → 프로세스 격리 효과
• 워커 내부는 스레드로 효율 확보

예시 B) 배치/크롤러

CPU 집중 작업:

• 이미지 처리
• 암호화
• 압축

→ 프로세스가 유리한 경우 많음 (코어 분산 + 격리)

I/O 중심 작업:

• HTTP 요청
• DB 조회
• 파일 읽기

→ 스레드/비동기가 효율적

이 차이를 모르고 구조를 설계하면 CPU를 못 쓰거나, 메모리 폭주가 발생합니다.

예시 C) 워드프레스 + DB 장애

디스크가 꽉 찼던 사례를 보면:

• mysqld → 별도 프로세스
• PHP-FPM → 여러 프로세스
• 웹서버 → 별도 프로세스

그런데 디스크가 100% 차니 전부 오류.

여기서 중요한 교훈:

프로세스 격리는 메모리 관점이고,
디스크/CPU는 공용 자원이다.

프로세스 구조만 믿으면 안 됩니다.
자원 모니터링이 핵심입니다.

예시 D) Docker는 프로세스인가?

Docker는 VM이 아닙니다.

• 호스트 커널 공유
• 내부에서 일반 프로세스/스레드 실행

컨테이너가 죽는다는 건 보통
“그 안의 메인 프로세스가 죽었다”는 뜻입니다.

그래서 PID 1 관리가 중요합니다.

5️⃣ 리눅스에서 바로 확인하는 법

프로세스 보기

ps aux | head

스레드까지 보기

ps -eLf | head

특정 PID 스레드 수

ps -o nlwp= -p <PID>

nlwp = 스레드 수

top에서 스레드 모드

top -H

실무에서는 nlwp가 갑자기 늘어나면
스레드 폭주를 의심합니다.

6️⃣ 선택 기준 (운영 관점)

✔ 안정성이 더 중요하다 → 프로세스 비중 ↑
✔ 처리량/공유 데이터가 중요하다 → 스레드 비중 ↑
✔ 대부분은 “혼합 구조”가 정답

튜닝할 때는 이렇게 봅니다:

• 워커 수 = CPU 코어 활용
• 스레드풀 크기 = 동시성 제한
• 메모리 한계 = 프로세스 수와 직결

7️⃣ 자주 하는 오해

❌ 스레드는 무조건 빠르다
→ 동기화/락 경쟁 심하면 오히려 느려짐

❌ 프로세스면 무조건 안전하다
→ 디스크/CPU는 공유 자원

❌ 컨테이너면 완전 격리다
→ 커널은 공유

8️⃣ 장애 대응 체크리스트

• 특정 프로세스만 죽었나, 전체인가?
• 스레드 수(NLWP)가 비정상적으로 늘었나?
• CPU 코어 대비 워커 수 적절한가?
• 스레드풀 제한 설정했는가?
• 디스크/메모리 같은 공용 자원 병목은 아닌가?

9️⃣ 실무에서 얻은 교훈

프로세스 vs 스레드는 시험 문제가 아니라
“격리와 효율의 균형” 문제입니다.

장애가 났을 때:

• 메모리 격리 문제인가?
• 동기화 문제인가?
• 공용 자원 병목인가?

이 질문이 바로 나오면, 대응 속도가 훨씬 빨라집니다.

FAQ

Q1. 프로세스가 무조건 더 안전한가요?
메모리 격리는 강하지만, 디스크/CPU 병목은 같이 영향을 받습니다.

Q2. 스레드는 왜 위험하다고 하나요?
메모리를 공유하기 때문에 동기화 실수나 메모리 오염이 전체 장애로 번질 수 있습니다.

Q3. 요즘은 비동기가 대세 아닌가요?
맞습니다. 하지만 내부적으로는 여전히 스레드/이벤트 루프 구조 이해가 필요합니다.

게시물 프로세스 vs 스레드 — 실무에서 헷갈림이 줄어드는 기준이 하우인포-IT·테크에 처음 등장했습니다.

Linux 명령어에 익숙해졌다면, 이제 한 단계 올라갈 차례입니다.
요즘 서버 운영, AI, 자동화, NAS 환경에서 빠지지 않는 기술이 바로 Docker입니다.

Docker를 이해하면:

✔ 서버 세팅이 빨라지고
✔ 환경 충돌이 사라지고
✔ 자동화 구성이 쉬워지고
✔ 이식성이 극대화됩니다

이번 글에서는 직접 설치 → 실행 → 컨테이너 운영까지 실습해봅니다.

1️⃣ Docker란 무엇인가?

Docker는 컨테이너 기반 가상화 플랫폼입니다.

기존 가상머신(VM)은 OS를 통째로 올리지만,
Docker는 필요한 실행 환경만 분리해서 올립니다.

👉 가볍고 빠릅니다
👉 서버 운영에 최적화되어 있습니다

2️⃣ Docker 설치 실습 (Ubuntu 기준)

📌 1단계: 패키지 업데이트

sudo apt update

📌 2단계: Docker 설치

sudo apt install docker.io -y

📌 3단계: Docker 실행 확인

docker --version

📌 4단계: Docker 서비스 활성화

sudo systemctl enable docker
sudo systemctl start docker

상태 확인:

sudo systemctl status docker

3️⃣ 첫 번째 컨테이너 실행해보기

📌 Hello World 실행

sudo docker run hello-world

정상이라면 테스트 메시지가 출력됩니다.

👉 이 순간 Docker 엔진이 동작한 것입니다.

4️⃣ Nginx 웹서버 컨테이너 실행 실습

📌 Nginx 실행

sudo docker run -d -p 8080:80 nginx

설명:

• -d : 백그라운드 실행
• -p 8080:80 : 포트 연결
• nginx : 이미지 이름

브라우저에서 접속:

http://서버IP:8080

👉 웹서버가 바로 실행됩니다.

5️⃣ 컨테이너 관리하기

📌 실행 중 컨테이너 확인

docker ps

📌 전체 컨테이너 보기

docker ps -a

📌 컨테이너 중지

docker stop 컨테이너ID

📌 컨테이너 삭제

docker rm 컨테이너ID

6️⃣ Docker 이미지 관리

📌 이미지 목록 확인

docker images

📌 이미지 삭제

docker rmi 이미지ID

7️⃣ 실제 운영 감각 익히기 (중요)

Docker는 단순 실행이 목적이 아닙니다.

운영에서 중요한 개념:

🔹 포트 매핑

외부포트:내부포트

-p 3000:3000

🔹 볼륨 연결 (데이터 보존)

docker run -d -p 8080:80 -v /home/data:/usr/share/nginx/html nginx

👉 컨테이너 삭제해도 데이터 유지

🔹 재부팅 시 자동 실행

docker run -d --restart=always nginx

8️⃣ Docker Compose 기초 (실무 핵심)

Docker를 여러 개 운영하면 docker-compose가 필요합니다.

설치:

sudo apt install docker-compose -y

예시 docker-compose.yml

version: '3'
services:
  web:
    image: nginx
    ports:
      - "8080:80"

실행:

docker-compose up -d

👉 실무에서는 거의 이 방식으로 운영합니다.

📌 Docker를 배우면 생기는 변화

✔ 서버 세팅 시간이 획기적으로 단축
✔ 개발/운영 환경 동일화
✔ 자동화 구성 쉬워짐
✔ NAS 활용도 상승
✔ AI 모델 배포 쉬워짐

Docker는 이제 선택이 아니라 기본입니다.

게시물 Docker 기초 실습 가이드이 하우인포-IT·테크에 처음 등장했습니다.

운영체제를 이해했다면, 이제는 직접 만져볼 차례입니다.
Linux는 “읽는 것”보다 “직접 입력해보는 것”이 훨씬 중요합니다.

이 글에서는 실제로 가장 많이 사용하는 명령어 위주로 실습을 진행해보겠습니다.

👉 실습 환경: Ubuntu / NAS / Orange Pi / 가상머신 모두 가능

1️⃣ 현재 시스템 상태 확인하기

📌 현재 위치 확인

pwd

현재 내가 있는 디렉토리 경로를 보여줍니다.

📌 파일 목록 보기

ls
ls -al

• -a : 숨김 파일 포함
• -l : 상세 정보 표시

👉 서버 운영에서 가장 기본이 되는 명령어입니다.

2️⃣ 디렉토리(폴더) 다루기

📌 디렉토리 이동

cd /home
cd ..
cd ~

• .. → 상위 폴더
• ~ → 내 홈 디렉토리

📌 디렉토리 생성

mkdir test_folder

📌 디렉토리 삭제

rm -r test_folder

⚠ -r 옵션은 하위 폴더까지 삭제
⚠ 서버에서 매우 조심해야 합니다

3️⃣ 파일 다루기 실습

📌 파일 생성

touch test.txt

📌 파일 내용 확인

cat test.txt

📌 파일 편집 (nano 사용)

nano test.txt

• 수정 후 → Ctrl + X
• Y → 저장

📌 파일 복사

cp test.txt copy.txt

📌 파일 이동 / 이름 변경

mv copy.txt newname.txt

4️⃣ 권한(Permission) 이해하기

파일 상세 보기:

ls -l

출력 예시:

-rwxr-xr--

구조:

[소유자][그룹][기타 사용자]

📌 권한 변경

chmod 755 test.txt

755 의미:

• 7 → 읽기+쓰기+실행
• 5 → 읽기+실행
• 5 → 읽기+실행

👉 서버 보안의 기본입니다.

5️⃣ 프로세스 확인하기

📌 실행 중인 프로세스 보기

ps aux

📌 실시간 모니터링

top

종료: q

👉 CPU 사용률, 메모리 확인 가능

6️⃣ 서비스 관리 (서버 운영 핵심)

Linux는 대부분 systemd 기반입니다.

📌 서비스 상태 확인

systemctl status nginx

📌 서비스 시작

systemctl start nginx

📌 부팅 시 자동 실행 설정

systemctl enable nginx

👉 NAS, AI 서버 자동 실행 시 필수 개념

7️⃣ 로그 확인하기 (장애 분석 기본)

tail -f /var/log/syslog

실시간 로그 확인

👉 장애 발생 시 가장 먼저 보는 영역

8️⃣ 패키지 설치 (Ubuntu 기준)

sudo apt update
sudo apt install htop

설치 후 실행:

htop

top보다 보기 편한 시스템 모니터링 도구

9️⃣ 네트워크 확인

📌 IP 확인

ip addr

📌 포트 확인

netstat -tulnp

👉 어떤 서비스가 어떤 포트를 사용하는지 확인 가능

🔟 실습 루틴 추천

매일 10분씩 아래를 반복해보세요:

1. 폴더 만들기
2. 파일 생성/수정
3. 권한 변경
4. 프로세스 확인
5. 서비스 재시작
6. 로그 확인

2주만 해도 서버 감각이 생깁니다.

📌 Linux 실습을 하면 생기는 변화

✔ 서버가 무섭지 않습니다
✔ NAS 관리가 쉬워집니다
✔ 자동화가 이해됩니다
✔ 장애 분석이 가능해집니다
✔ Docker 구조가 이해됩니다

Linux는 “암기”가 아니라 “반복 실습”입니다.

게시물 Linux 기초 실습 가이드이 하우인포-IT·테크에 처음 등장했습니다.

가볍고 빠르면서도 확장성이 뛰어나,
파이썬·웹·서버 관리까지 폭넓게 사용할 수 있어 우분투 사용자에게 특히 인기가 많습니다.

이번 글에서는 우분투(Ubuntu)에서 VS Code를 설치하는 가장 쉬운 방법을 정리해보겠습니다.

🐧 왜 우분투에서 VS Code를 많이 쓸까?

• 마이크로소프트 공식 지원
• 터미널·SSH·Docker 연동에 강함
• 확장 프로그램으로 IDE급 활용 가능
• 서버·홈서버·개발 환경에 잘 어울림

CLI 중심인 우분투와 VS Code는 궁합이 아주 좋은 조합입니다.

✅ 방법 1. 스냅(Snap)으로 설치하기 (가장 간단)

우분투 기본 패키지 관리자인 Snap을 이용하면 한 줄로 설치할 수 있습니다.

sudo snap install code --classic

장점

• 설치가 매우 간단
• 자동 업데이트 지원
• 공식 패키지

설치가 끝나면 앱 메뉴에서 Visual Studio Code를 바로 실행할 수 있습니다.

✅ 방법 2. 공식 .deb 패키지로 설치하기 (권장)

마이크로소프트에서 제공하는 공식 저장소를 등록해 설치하는 방법입니다.

1️⃣ 필수 패키지 설치

sudo apt update
sudo apt install wget gpg -y

2️⃣ 마이크로소프트 GPG 키 추가

wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > packages.microsoft.gpg
sudo install -o root -g root -m 644 packages.microsoft.gpg /usr/share/keyrings/

3️⃣ VS Code 저장소 추가

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/packages.microsoft.gpg] \
https://packages.microsoft.com/repos/code stable main" | \
sudo tee /etc/apt/sources.list.d/vscode.list

4️⃣ 설치

sudo apt update
sudo apt install code -y

👉 이 방식은 apt 업데이트와 함께 관리할 수 있어 안정적입니다.

▶ 설치 확인 및 실행

터미널에서 아래 명령어를 입력해보세요.

code

정상적으로 실행되면 설치 성공입니다 🎉

🔧 설치 후 꼭 해볼 설정

• 한글 입력 문제 → ibus 설정 확인
• 확장 추천
  • Python
  • Remote – SSH
  • Docker
  • GitLens
• 테마 변경으로 가독성 개선

VS Code는 설치 후 설정에 따라 생산성이 크게 달라집니다.

✨ 마무리

우분투에서 VS Code를 설치하는 방법은 여러 가지가 있지만,
Snap 또는 공식 저장소 방식만 알아도 충분합니다.

개발, 서버 관리, 홈서버 운영까지
우분투 환경에서 VS Code 하나면 대부분의 작업을 커버할 수 있습니다.

게시물 우분투에서 비주얼 스튜디오 코드 설치 방법 (초보자도 OK)이 하우인포-IT·테크에 처음 등장했습니다.