'전체 글'에 해당되는 글 186건

에러노트는 직접 경험했던 에러를 적어보고,

그 당시 해결법이 무엇이었는지 기록하여, 스스로 참고하기 위해 작성합니다.

저의 경험 사례가 다른 분들에게도 도움이 될 수 있으므로, 공개 포스팅으로 작성합니다.

에러의 발생 원인과 정확한 해결법을 알려주는 포스팅이라기보다는,

전적으로 제 경험에 의존하다보니 완벽한 해결법이 아닐 수 있다는 점 이해 바랍니다.

ImportError: libGL.so.1: cannot open shared object file: No such file or directory 해결법

에러 메시지

ImportError: libGL.so.1: cannot open shared object file: No such file or directory

에러 발생 지점

import cv2[opencv 관련 라이브러리]

해결법

OpenCV를 분명히 깔았음에도, 계속적으로 발생할 경우, 아래 메시지를 통해 필요한 파일을 다운받아서 정상적으로 실행이 되는 것을 확인할 수 있다.

sudo apt install libgl1-mesa-glx

에러노트는 직접 경험했던 에러를 적어보고,

그 당시 해결법이 무엇이었는지 기록하여, 스스로 참고하기 위해 작성합니다.

저의 경험 사례가 다른 분들에게도 도움이 될 수 있으므로, 공개 포스팅으로 작성합니다.

에러의 발생 원인과 정확한 해결법을 알려주는 포스팅이라기보다는,

전적으로 제 경험에 의존하다보니 완벽한 해결법이 아닐 수 있다는 점 이해 바랍니다.

RuntimeError : Only one  file(not dir) is allowed in the zipfile 해결법

에러 메시지

RuntimeError: Only one file(not dir) is allowed in the zipfile

에러 발생 지점

state_dict = model_zoo.load_url(url, map_location="cpu", progress=True)

해결 방안

필자의 경우, pytorch에서 ViT 모델인 DeiT를 timm 라이브러리를 통해 불러오는 과정에서 에러가 발생하였으며, pretrained weight를 불러오는 과정에서 계속 저 에러가 발생했었다.

DeiT 개발팀은 파이토치 버전을 1.7.0으로 맞춰줄 것을 강력히 권고하였으며, 이로 인해 torch버전을 개발자가 권고하는 버전으로 업데이트 한 결과, 에러가 해결되었다.

에러 메세지가, 오직 한 파일만 사용이 가능하다는 내용을 가지고 있어서 토치 버전 문제일거라고는 쉽게 짐작이 되지 않아 해결에 오랜 시간이 소요되었다.

Docker Volume에서 삭제한 파일을 복구하는 방법

저번 포스팅에서 언급했던 .Trash 파일의 존재를 저도 잘 몰랐고, 대부분의 유저들이 잘 모르실 것 같아 추가로 포스팅을 작성합니다.

2021.07.03 - [각종 Tips/Ubuntu] - [Docker / Linux] 도커 볼륨의 용량이 너무 클 때 해결법

Docker Root Directory 찾기

docker info | grep "Docker Root Dir"

위 명령어를 통해 먼저 Host에서 Docker Root Dir를 찾아냅니다.

해당 디렉터리에 접근하면 다음과 같은 파일들이 존재합니다.

$ ls
buildkit    image    overlay2  runtimes  tmp    volumes
containers  network  plugins   swarm     trust

해당 디렉터리중, volumes에 들어가면 컨테이너가 사용하고 있는 볼륨정보가 나타나게 된다.

이 때, 볼륨 내부를 확인해보면,

_data 디렉터리가 존재한다.

해당 디렉터리 내부에 접근 한 후, ls -al 커맨드를 사용하면 모든 .Trash-0과 같은 디렉터리를 발견할 수 있다.

Trash-0는 숨김파일이기 떄문에, ls -al 명령어를 통해서 확인할 수 있으며,

cd를 통해 접근해볼 경우 삭제된 파일의 원본을 저장한 files와 메타데이터인 info를 가지고 있으며,

files 내부에는 삭제했던 파일들이 원본 그대로 존재하는 것을 확인할 수 있다.

내부에 존재하는 파일들은 단순히 mv나 cp와 같은 명령어를 통해서 복원이 가능하다.

도커(Docker) 볼륨 용량 초과 이슈

Docker를 사용하면서, 볼륨에서 실제 사용하고 있는 크기보다 더 용량을 많이 잡아먹는 경우가 있다.

이러한 경우에 가장 우선적으로 확인해야하는 사항에 대해 알아보았다.

용량 현황 확인

docker info | grep "Docker Root Dir"

위 명령어를 사용하면, Docker의 루트 디렉터리를 알 수 있다.

해당 디렉터리로 접근한 뒤,

du -sh *을 사용하여 어떤 파일의 용량이 가장 큰지 확인해야한다.

Overlay2가 가장 용량이 클 경우

일반적으로 overlay2의 용량이 가장 큰 경우, 

가장 먼저 의심해 볼 사항은 백업과 같은 역할을 수행하기 위해서, 컨테이너 내부 파일 구조의 변경 사항을 기록하는 /diff/tmp 폴더에 용량이 매우 큰 파일들이 존재하는 경우가 많다.

du -sh */diff/tmp |sort -nr

위 명령어를 통해, 

용량을 가장 많이 차지하고 있는 컨테이너 디렉터리를 찾은 후, 

내부에 있는 diff/tmp 파일에서 비정상적으로 용량이 큰 파일을 삭제하는 방법을 취할 수 있다.

일반적으로 삭제했을 때, 동작에 문제가 생기지는 않았으나

만약의 경우를 대비해서 우선은 백업을 해둔 뒤, 삭제 후 정상작동 여부를 살피는 것을 추천한다.

Image와 컨테이너의 용량이 클 경우

docker image prune -all

위 명령어를 통해 사용하지 않는 컨테이너와 이미지 정보를 정리할 수 있다.

대부분의 경우 이를 통해 용량이 줄어드는 것을 확인할 수 있다.

Volumes의 용량이 클 경우

docker Volume은 일반적으로 컨테이너 내부에서 사용되는 파일들이 그대로 저장되어있는 장소이다.

이 때, 대부분의 유저들이 잘 모르고 있는 사항이 있는데,

리눅스와는 별도로, docker volume은 자체적으로 "휴지통"개념을 가지고 있어서,

파일을 삭제 했을 때 자동으로 Volumes 디렉터리 내부에 있는 .Trash 디렉터리로 옮기게 된다.

숨김파일이라서 확인이 어렵지만,

삭제한 파일들의 용량이 그대로 저 안에서 차지되고 있어서 실제로 내가 사용하는 파일의 용량은 700GB인데 

볼륨의 용량은 1.4TB가 넘어가는 상황이 발생할 수 있다.

이를 방지하기 위해서, .Trash 파일을 삭제해주어야 한다.

Volumes 폴더 내부의 모습, .Trash-0라는 파일이 존재한다.

du -h --max-depth=1

위 명령어를 통해 숨김파일을 포함한 모든 파일의 용량을 확인할 수 있는데,

.Trash-0 파일안에 무려 505G나 되는 용량의 파일이 존재함을 확인할 수 있다.

내부를 보게 되면, 삭제된 원본 파일이 저장된 files 디렉토리와 메타데이터를 담고있는 info 디렉터리가 있는데, files 내부를 보면 여태까지 삭제했던 온갖 데이터들이 그대로 저장되어 있는 것을 확인할 수 있다.

필자는 머신러닝 학습용 데이터를 삭제하는 일이 빈번하였으므로, 용량을 많이 차지할 수 밖에 없다.

rm -rf .Trash*

위 명령어를 통해 모든 .Trash 디렉터리를 삭제할 수 있고, 용량을 확보할 수 있다.

bash, 쉘스크립트에서 숫자 연산하기(string to int)

기본적으로 쉘 스크립트는 모든 값을 문자열로 처리한다.

또한 데이터타입을 미리 정의하고 사용하는 방식이 아니기 때문에,

10이라는 값이 저장된 변수 a에 단순히 $a+10을 하게 될경우, "10+10"이 출력되는 경우가 종종 발생한다.

이를 해결하기 위한 방법을 알아본다.

expr을 사용하는 방식

expr을 앞에 붙여주면 자동적으로 수를 기반으로 한 사칙연산으로써 값이 표현된다.

다음 예시를 보자.

a=10
echo $a+10

# 실행 결과 : 10+10

echo 뒤에 `expr을 활용할 경우, 정상적으로 20이 출력된다.

a=10
echo `expr $a + 10`

# 실행결과 : 20

이 때, 반드시 유의해야할점은 + 연산을 반드시 띄어쓰기와 함께 사용해야 한다는 것이다.

필자는 이 사소한 차이로 인해, 왜 안되는걸까를 한참을 고민해야했다.

a=10
echo `expr $a+10`

# 실행결과 : 10+10

a=10
echo `expr $a + 10`

# 실행결과 : 20

예시 ) 하위 디렉터리별로 파일 세고 총 합 구하기.

이전 포스팅에서 다뤘던, 쉘 스크립트에 약간의 연산을 추가하여 하위 디렉터리에 총 몇개의 파일이 있는지 계산해보는 쉘 스크립트를 예시로 작성해보았다.

sum=0
for x in `find . -maxdepth 1 -mindepth 1 -type d -print`
do
num = `find $x -type f|wc -l`
echo $x, num;
done
echo $sum

Ubuntu, Linux에서 디렉토리별로 파일 개수 세기

쉘 스크립트를 사용하여 디렉토리별로 파일의 개수를 출력해주는 방법에 대해 소개한다.

쉘 스크립트

for x in `find . -maxdepth 1 -mindepth 1 -type d -print`
do
echo $x, `find $x -type f|wc -l`
done

위와 같은 쉘 스크립트를 통해 디렉터리 별 파일 개수를 계산할 수 있으며,

depth를 적절히 조정하여 사용할 수 있다.

실행결과

위와 같이 디렉터리 별로 파일의 개수가 출력된다.

XP(eXtreme Programming)

• 수시로 발생하는 고객의 요구사항에 유연하게 대처하기 위해 고객의 참여와 개발 과정 반복 극대화
• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 빠르게 개발하는것을 목적으로 함
• 릴리즈의 기간을 짧게 반복하면서 고객 요구사항 반영에 대한 가시성을 높임
• 비교적 소규모 인원의 개발 프로젝트에 효과적
• XP의 5가지 핵심 가치 : 의사소통, 단순성, 용기, 존중, 피드백

XP 개발 프로세스

• 사용자 스토리(User Story) 도출
  - 고객의 요구사항을 간단한 시나리오로 표현한 것
  - 내용은 기능 단위로 구성하며 필요할 경우, 간단한 테스트 케이스를 기재
• 릴리즈 계획 수립(Release Planning)
  
• 스파이크(Spike)
  - 요구사항의 신뢰성을 높이고, 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
  - 처리할 문제 외의 조건은 모두 무시하고 작성
• 이터레이션(Iteration)
  - 하나의 릴리즈를 더 세분화 한 단위
  - 일반적으로 1~3주 정도 기간 진행
  - 새로운 스토리가 작성될 수 있으며, 작성된 스토리는 현재 혹은 다음 이터레이션에 포함 가능
  
• 승인 검사(Acceptance Test)
  - 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행되는 테스트
  - 스토리 작성 시 함께 기재한 테스트 사항에 대해 고객이 직접 수행
  - 발견된 오류 사항은 다음 이터레이션에 반영
  - 테스트가 완료되면 다음 이터레이션 진행
• 소규모 릴리즈(Small Release)
  - 릴리즈를 소규모로 하여 기능 별로 고객의 반응을 확인하고 요구사항에 좀 더 유연하게 대응
  - 이터레이션이 모두 완료되면 고객에 의한 최종 테스트 수행 후 최종 릴리즈를 전달
  - 최종 완제품이 아닌 경우 다음 릴리즈 일정에 맞게 개발을 계속 진행

XP 주요 실천 방법

• Pair Programming(짝 프로그래밍) : 다른 사람과 함께 프로그래밍을 수행하여 책임을 공동으로 가지는 환경 조성
• Collective Ownership(공동 코드 소유) : 개발 코드에 대한 권한과 책임을 공동으로 소유
• TDD(Test Driven Development): 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성, 자동화 된 테스트 프레임워크 사용
  
• Whole Team : 모든 구성원은 각자 자신의 역할에 책임을 가짐
• Continuous Integration(지속적 통합) : 모듈 단위로 나눠서 개발된 코드들은 마무리될 때 마다 지속적으로 통합
• Design Improvement, Refactoring : 프로그램 기능의 변경 없이 단순화, 유연성 강화 등을 통해 시스템 재구성
• Small Release : 릴리즈 기간을 짧게 반복하여 고객의 요구 변화에 신속히 대응

현행 시스템 파악 절차

• 1단계
  - 시스템 구성 파악 : 현행 시스템의 구성은 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술, 각 업무에 속하는 단위 업무 정보시스템들의 명칭, 주요 기능들을 명시
  - 시스템 기능 파악 : 현재 제공하고 있는 기능들을 주요 기능과 하위 기능, 세부 기능으로 구분하여 계층형으로 표시
  - 시스템 인터페이스 파악 : 단위 업무 시스템 간에 주고 받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기등을 명시
  ex) 통신규약, 데이터 형식, 연계 유형
• 2단계
  - 아키텍처 구성 파악 : 어떠한 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성
  - 소프트웨어 구성 파악 : 단위 업무 시스템별로 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시
• 3단계
  - 하드웨어 구성 파악 : 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 이중화의 적용 여부 명시
  - 네트워크 구성 파악 : 업무 시스템들의 네트워크 구성을 파악할 수 있도록 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도 작성, 물리적인 관계 표현, 장애 발생 시 복구에 도움

개발 기술 환경 파악

• 개발하고자 하는 소프트웨어와 관련된 운영체제, DBMS, 미들웨어 등을 선정할 때 고려해야 할 사항 기술, 오픈 소스 사용 시 주의해야 할 내용을 제시
• 운영체제(OS) 고려사항
  - 가용성 : 장시간 운영으로 인해 발생할 수 있는 고유의 장애 발생 가능성, 메모리 누수, 보안 허점, 운영체제 결함 등등
  - 성능 : 대규모 동시 사용자 요청에 대한 처리, 지원 가능한 메모리 크기 등등
  - 기술 지원 : 제작 업체의 안정적인 기술 지원, 오픈 소스 여부(Linux)
  - 주변 기기 : 설치 가능한 하드웨어, 주변 기기 지원 여부
  - 구축 비용 : 지원 가능한 하드웨어 비용, 라이선스 정책 및 비용, 유지관리 비용, 총 소유 비용(TCO) 등등
• DBMS 고려사항
  - DBMS란 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템
  - 가용성 : 장시간 운영으로 인해 발생할 수 있는 고유 장애, 백업과 복구 편의성, DBMS 이중화 및 복제 지원 등등
  - 성능 : 대규모 데이터 처리 성능(분할 테이블 지원 여부), 대용량 트랜잭션 처리 성능, 질의 최적화 지원 여부
  - 기술 지원 : 제작업체의 안정적인 기술지원, 오픈 소스 여부 등등
  - 상호 호환성 : 설치 가능한 OS의 종류, JDBC, ODBC와의 호환 여부 등등
  - 구축 비용 : 라이선스 정책 및 비용, 유지관리 비용, TCO
  
• 웹 애플리케이션 서버(WAS) 고려사항
  - WAS는 정적인 콘텐츠 처리를 하는 웹 서버와 달리 사용자의 요청에 따라 변하는 동적인 컨텐츠를 처리하기 위해 사용되는 미들웨어
  - 가용성 : WAS 이중화 지원, 자체 결함으로 인한 장애 발생 가능성, 안정적인 트랜잭션 처리 등등
  - 성능 : 대규모 트랜잭션 처리 성능, 가비지 컬렉션의 다양한 옵션
  - 기술 지원 : 위와 동일
  - 구축 비용 : 위와 동일

이번에 정보처리기사를 준비하면서, 필기 내용이 방대하다보니, 

제가 다시 공부하기 위한 목적으로 요점정리를 업로드합니다.

아무래도, 공부 목적으로 업로드하는 것이다보니, 내용이 조금 부족할 수 있다는 점 양해 부탁드립니다.

소프트웨어 생명 주기 (Software  Life Cycle)

• 소프트웨어 개발 방법론의 바탕
• 개발하기 위해 정의하고, 운용, 유지보수 등의 과정을 단계별로 나눈 것
• 소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형, 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임이라고 칭함
• 대표적인 소프트웨어 생명 주기 모형에는 폭포수 모형(Waterfall), 프로토타입 모형(Prototype), 나선형 모형(Spiral), 애자일 모형(Agile) 등이 있다.
  
  

소프트웨어 공학 기본 원칙

• 현대적인 프로그래밍 기술을 계속적으로 적용
• 개발된 소프트웨어의 품질이 유지되도록 지속적인 검증
• 개발 관련 사항 및 결과에 대한 명확한 기록 유지
  
  

폭포수 모형(Waterfall Model)

• 가장 오래되고 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형, 고전적 생명 주기 모형이라고도 함
• 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형(Linear Sequential Model)
• 제품의 일부가 될 메뉴얼을 작성해야 함
• 타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현 -> 시험 -> 유지보수 순으로 진행
  
  

프로토타입 모형(Prototype Model)

• 사용자의 요구사항이 명확하지 않을 때 활용
• 실제 개발될 소프트웨어에 대한 프로토타입을 만들어 최종 결과물을 예측
• 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
• 개발이 다 끝난 후에 오류가 발견되는 Waterfall 방식의 단점을 보완
  
  

나선형 모형(Spiral Model)

• Boehm(보헴)이 제안한 것으로, Waterfall과 Prototype의 장점에 위험 분석 기능 추가
• 나선처럼 여러 번이 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 소프트웨어를 개발, 점진적 모형
• 소프트웨어 개발시 발생하는 위험을 관리하고 최소화 하는 것이 목적
• 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가 순으로 반복 진행하며 유지보수 과정 필요 X
  

애자일 모형(Agile Model)

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하며 개발과정 진행
• 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 모든 방법론을 통칭
• Sprint또는 Iteration이라고 불리는 짧은 개발 주기를 반복하며, 주기마다 고객에게 평가와 요구를 적극 수용
• 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합
• Scrum, XP, 칸반, Lean, 크리스탈, ASD, 기능 중심 개발(FDD), DSDM,  DAD등이 애자일 모형 기반
  

Scrum(스크럼)

• 팀원 스스로가 스크럼 팀을  구성(Self-Organizing)해야 하며 개발 작업에 관한 모든 것을 스스로 해결(Cross-functional)할 수 있어야 한다.
• 제품 책임자(PO; Product Owner), 스크럼 마스터(SM; Scrum Master), 개발팀 (DT; Development Team) 구성
• 제품책임자?
  - 이해관계자들 중 개발될 제품에 대한 이해도가 높고 요구사항을 책임지고 의사결정할 사람
  - 이해관계자들의 의견을 종합하여 제품에 대한 요구사항 작성을 진행하는 주체
  - 요구 사항이 담긴 백로그(Backlog)를 작성하고 우선순위를 지정
  - 주기적으로 요구사항의 우선순위를 갱신
  
• 스크럼 마스터?
  - 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할, 통제가 아님
  - 일일 스크럼 회의를 주관하여 진행 사항 점검 및 문제 발생 시 공론화하여 처리 진행
  
• 개발팀?
  - PO와 SM을 제외한 모든 팀원으로 개발자 뿐만 아니라 디자이너, 테스터등이 모두 포함된다.

스크럼 개발 프로세스

• 제품 백로그(Product Backlog)
  - 제품 개발에 필요한 모든 요구사항(User Story)을 우선 순위에 따라 나열한 목록
  - 개발 과정에서 새롭게 도출되는 요구사항으로  지속적 업데이트
  - 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 계획 수립
• 스프린트 계획 회의(Sprint Planning Meeting)
  - 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정 수립
  - 스프린트에서 처리할 User Story를 개발자들이 나눠서 작업할 수 있도록 Task라는 단위로 분할, 개발자 별로 수행할 작업 목록인 Sprint Backlog를 작성
  
• 스프린트(Sprint)
  - 실제 개발 작업을 진행하는 과정, 2~4주 정도 기간
  - 스프린트 백로그에 작성된 태스크를 대상으로 작업 시간을 추정한 후 개발자에게 할당
  - 할당된 Task는 할 일(To Do), 진행 중 (In Progress), 완료 (Done)의 상태를 지님
• 일일 스크럼 회의(Daily Scrum Meeting)
  - 모든 팀원이 매일 약 15분 정도의 짧은 시간동안 진행상황을 점검
  - 남은 작업 시간은 소멸 차트(Burn-Down Chart)에 표시
• 스프린트 검토 회의(Sprint Review)
  - 스프린트 산출물이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅 수행
  - 제품 책임자(PO)는 개선할 사항에 대한 피드백 정리 후 반영하여 제품 백로그 업데이트
• 스프린트 회고(Sprint Retrospective)
  - 스프린트 주기를 되돌아보며 규칙 준수 여부, 개선점 확인 및 기록
  - 스프린트 마치고 수행하거나 일정 주기로 수행

맥북 캡쳐해서 바로 클립보드에 복사하기

윈도우에서 캡쳐도구를 사용하셨던 분들은, 캡쳐하자마자 Ctrl+V로 붙여넣기가 가능한 이점을 잘 활용하셨을겁니다.

맥북도 마찬가지로 비슷한 기능이 있는데, 단축키로 편리하게 캡쳐가 가능합니다.

Command + Shift + 숫자4를 함께 입력하시면 마우스 커서가 좌표값을 나타내는 모양으로 변경됩니다.

이 때 마우스 드래그를 진행해주시면, 캡쳐가 가능합니다.

하지만, 이렇게 캡쳐된 경우 기본으로 바탕화면에 저장되고, 1회성으로 붙여넣기를 하기 위해서는 직접 클립보드로 복사 옵션을 선택해주어야 하는 번거로움이 있습니다.

파일 저장은 필요없고 단순히 1회성 복사 붙여넣기가 필요한 경우, 

Command + Shift + 숫자4를 함께 입력하여 마우스 커서를 캡쳐 모드로 변경 한뒤,

드래그를 할때 Ctrl키를 누르고 캡쳐를 진행하시면 자동으로 클립보드로 저장됩니다.

이렇게 캡쳐할 경우, 윈도우 캡쳐보드처럼 즉시 Command + V로 붙여넣기가 가능합니다.

운영체제 2탄 프로세스 영역입니다.

면접 부분에서 오히려 더 자주 나오는 파트이기도 한 것 같습니다.

프로세스란?

• 컴퓨터에서 실행되고 있는 프로그램들은 모두 프로세스
• 운영체제 프로세스와 사용자 프로세스로 분류
• 프로세스는 각각 독립된 메모리 영역(Code, Data, Stack, Heap의 구조)을 할당받음
• 기본적으로 프로세스당 최소 1개의 스레드를 가지고 있음
• 각 프로세스는 별도의 주소 공간에서 실행, 한 프로세스는 다른 프로세스의 변수나 자료구조에 직접 접근 불가
• 다른 프로세스의 자원에 접근하려면 IPC(Inter-Process Communication)을 사용해야 함
  (파이프, 파일, 소켓 등을 이용한 통신 방법)

프로세스 메모리 구조

• 코드 영역 : 실행할 프로그램의 코드가 저장되는 영역으로 텍스트 영역이라고도 함
  CPU는 코드 영역에 저장된 명령어를 하나씩 처리
• 데이터 영역 : 메모리의 데이터 영역은 프로그램의 전역 변수와 정적변수가 저장되는 영역
  프로그램 시작과 함꼐 할당되고, 종료되면 소멸
• 힙 영역 : 사용자가 직접 관리할 수 있고, 관리 해야만 하는 메모리 영역
  사용자에 의해 동적으로 할당되고 해제됨
  낮은 주소에서 높은 주소의 방향으로 할당
• 스택 영역 : 함수의 호출과 관련된 지역 변수와 매개변수가 저장
  함수의 호출과 함께 할당, 함수 호출 완료 후 소멸
  스택 영역에 저장되는 함수 호출 정보를 스택 프레임이라고 함

Thread란?

• CPU 사용의 기본 단위
• 프로세스 내에서 실행되는 여러 흐름의 단위
• Thread ID, PC, 레지스터 세트 및 스택으로 구성
• Thread는 프로세스 내에서 각각 Stack만 따로 할당받고 Code, Data, Heap 영역은 공유
• 한Thread가 프로세스 자원을 변경하면 다른 Thread도 그 결과가 반영됨

Thread vs Process

• 프로세스는 운영체제로부터 자원을 할당받는 작업의 단위
• 스레드는 프로세스가 할당받은 자원을 이용하는 실행의 단위
• 프로세스는 운영체제로부터 독립된 메모리, 주소 공간을 할당받음
• 스레드는 할당받은 자원들을 내부 스레드끼리 공유하며 실행
• 스레드는 일종의 경량화된 프로세스 개념
• 스레드간의 자원 공유는 전역 변수를 이용하므로, 동기화 문제에 주의 필요

멀티쓰레딩의 특징

• 하나의 프로세스를 다수의 스레드를 통해 실행하는 것
• 하나의 프로세스 내에 다수의 실행 단위가 존재하여, 작업의 수행에 필요한 자원을 공유하기 때문에 자원의 생성과 관리가 중복되는 것을 방지
• 교착 상태(DeadLock) 발생 가능, 동기화 주의 필요
• 프로세스 간의 통신 IPC보다 효율적으로 통신이 가능, Context Switch 속도 빠름(Stack만 처리하므로)

멀티프로세싱 VS 멀티프로그래밍

• 멀티프로세싱은 여러 개의 처리장치를 장착하여 동시에 여러 작업을 병렬로 실행하는 방법
• 멀티프로그래밍은 다수 개의 프로그램이 같이 주기억장치에 있도록 한 방식
  
  

프로세스의 상태

• 생성(New) : 프로세스가 막 생성된 상태
• 준비(Ready) : 프로세스가 CPU에 실행되기 위해 대기하는 상태
• 실행(Running) : 프로세스에 포함된 명령어가 CPU에서 실행되고 있는 상태
• 대기(Waiting) : 프로세스가 특정 자원이나 이벤트를 기다리고 있는 상태
• 종료(Terminated) : 프로세스가 실행을 완료한 상태
  
  

프로세스 상태 전이 동작

PCB(Process Control Block)

• PCB는 특정한 프로세스를 관리할 때 필요한 정보를 저장하는 운영체제 커널의 자료구조
• 프로세스가 생성될 때마다 고유의 PCB 생성