큰숲백과 - 사용자 기여 [ko]

언리얼 엔진

2026-04-01T03:38:49Z

Senouis:

[[분류: 게임 엔진]]

'''언리얼 엔진'''(Unreal Engine)은 [[에픽 게임즈]]가 개발하는 상용 게임 엔진이다.

== 개발 역사 ==
=== 1.X ===
* 1994년~1997년까지 팀 스위니를 주축으로 [[언리얼(게임)|언리얼]]과 [[언리얼 토너먼트]]를 위해 개발한 버전
* 모듈식 구조 적용, 언리얼스크립트로 레벨 및 게임 로직 디자인
=== 2.X ===
* [[언리얼 워페어]]부터 채용한 버전, 1999년부터 2005년까지 개발
* 최초로 단일 엔진 멀티 플랫폼 포팅이 가능해짐(XBox 한정, 플레이스테이션2는 별도로 분기)
=== 3.X ===
* 2002년부터 개발을 시작하여 2006년부터 채용한 버전
* 완전한 단일 엔진 멀티 플랫폼 포팅 기능 탑재
* 언리얼스크립트와 호환되는 노드 그래프 기반 비주얼 스크립트 시스템인 키스멧(Kismet) 도입
* 2009년부터 기능 제약이 있으나 무료로 개발이 가능한 UDK(Unreal Development Kit)를 제공

=== 4.X ===
* 완전한 조립식 구조의 엔진 구성을 위해 2010년부터 완전히 다시 만든 버전(하위 호환 없음)
* 레벨 단위 뿐만 아니라 게임 전체 로직을 구성할 수 있는 강화된 노드 그래프 기반 비주얼 스크립트 시스템인 블루프린트(Blueprint) 도입
** 언리얼스크립트를 폐기하고 [[C++]]와의 호환성을 갖춤
* 최신 플랫폼에 대부분 대응하며(웹 게임은 4.24를 끝으로 중단), VR을 지원
* 실시간 전역 조명 렌더링 지원
=== 5.X ===
* 나나이트 메시 시스템과 개선된 루멘 광원 및 레이트레이싱 시스템(5.0), 새로운 입력 시스템 도입(5.1)

== 언리얼 엔진을 사용한 게임 ==
* 언리얼 토너먼트, [[포트나이트]] 등 에픽 게임즈가 개발하는 모든 게임
* [[크래프톤]]의 [[PUBG]](통칭 배그, 배틀그라운드)

언리얼 엔진

2026-04-01T03:36:45Z

Senouis: /* 5.X */

언리얼 엔진

2026-04-01T03:36:18Z

Senouis: /* 5.X */

[[분류: 게임 엔진]]

'''언리얼 엔진'''(Unreal Engine)은 [[에픽 게임즈]]가 개발하는 상용 게임 엔진이다.

== 개발 역사 ==
=== 1.X ===
* 1994년~1997년까지 팀 스위니를 주축으로 [[언리얼(게임)|언리얼]]과 [[언리얼 토너먼트]]를 위해 개발한 버전
* 모듈식 구조 적용, 언리얼스크립트로 레벨 및 게임 로직 디자인
=== 2.X ===
* [[언리얼 워페어]]부터 채용한 버전, 1999년부터 2005년까지 개발
* 최초로 단일 엔진 멀티 플랫폼 포팅이 가능해짐(XBox 한정, 플레이스테이션2는 별도로 분기)
=== 3.X ===
* 2002년부터 개발을 시작하여 2006년부터 채용한 버전
* 완전한 단일 엔진 멀티 플랫폼 포팅 기능 탑재
* 언리얼스크립트와 호환되는 노드 그래프 기반 비주얼 스크립트 시스템인 키스멧(Kismet) 도입
* 2009년부터 기능 제약이 있으나 무료로 개발이 가능한 UDK(Unreal Development Kit)를 제공

=== 4.X ===
* 완전한 조립식 구조의 엔진 구성을 위해 2010년부터 완전히 다시 만든 버전(하위 호환 없음)
* 레벨 단위 뿐만 아니라 게임 전체 로직을 구성할 수 있는 강화된 노드 그래프 기반 비주얼 스크립트 시스템인 블루프린트(Blueprint) 도입
** 언리얼스크립트를 폐기하고 [[C++]]와의 호환성을 갖춤
* 최신 플랫폼에 대부분 대응하며(웹 게임은 4.24를 끝으로 중단), VR을 지원
* 실시간 전역 조명 렌더링 지원
=== 5.X ===
* 나나이트 메시 시스템(5.0)과 개선된 루멘 광원 및 레이트레이싱 시스템, 새로운 입력 시스템 도입(5.1)

에픽 게임즈

2026-04-01T03:34:47Z

Senouis: /* 언리얼 엔진 */

'''에픽 게임즈'''(Epic Games)는 팀 스위니가 1991년 창립한 비디오 게임 소프트웨어 회사다.

== 역사 ==

이 회사는 1998년 자사에서 만든 언리얼과 언리얼 토너먼트가 성공하여 [[이드 소프트웨어]]의 퀘이크와 대결하면서 FPS 게임 제작사의 루키가 된다.

2006년에는 기어즈 오브 워를 개발하였으나 후속작 개발의 어려움으로 인해 마이크로소프트에 시리즈 IP를 매각하게 된다.

그 이후 UDK 공개 등 개발자 양성에 신경을 쓰고 있으며 [[포트나이트]]의 대성공으로 인해 시장가치가 폭증하였다.

== 언리얼 엔진 ==

이 회사에서 개발한 [[언리얼 엔진]]은 이드 소프트웨어의 id Tech 엔진과 맞먹을 정도로 뛰어난 렌더링 기능과 철저한 모듈화 및 좋은 개발 편의성, 어느 정도 성능이 되기만 하면 그 이상의 성능을 내는 컴퓨터에서는 좋은 최적화 수준을 보여주고, 다양한 기능 추가로 인해 좋은 평가를 받았다.

언리얼 엔진 3부터는 조금씩 언리얼 엔진의 SDK를 배포하다 언리얼 엔진 4부터는 아예 라이센스 비용조차 조건부 무료에 엔진 소스코드 공개 및 월별 공짜 에셋 배포를 통해 초보 개발자들에게 사랑받는 게임 엔진이 되도록 노력하는 중이다. 특히 언리얼 엔진 3의 키스멧을 계승하여 언리얼 엔진 4부터 도입된 블루프린트 비주얼 스크립트 시스템은 비 프로그래머도 게임 로직 개발에 관여할 수 있도록 하여 개발 편의성을 크게 늘렸다.

스케치팹을 인수한 뒤로 다양한 게임 엔진에서 사용할 수 있는 게임 애셋을 팔 수 있게 팹(Fab)이라는 이름으로 애셋 스토어를 개편했다. 매달 3개의 애셋을 지정하여 공짜 구입 행사를 진행한다.

== 에픽 게임즈 스토어 ==
한편 비디오 게임 [[ESD]]의 대명사인 [[밸브 코퍼레이션]]의 [[스팀]]과 경쟁하기위해 에픽 게임즈 스토어를 열어 공짜 게임 이벤트 진행 및 독점작 확보 등 비디오 게임 판매 분야에서 다양한 프로모션을 진행하고 있다.

특히 [[문명 6]]을 공짜로 푼 것은 전설적인 프로모션으로 회자될 정도이다.

== TMI ==
* 중국의 [[텐센트]]가 에픽 게임즈에 대폭 투자하면서 중국으로 회사가 넘어가는 게 아니냐는 불안감이 있었으나 팀 스위니가 자신만이 경영권을 갖고 있는 과반의 주식을 소유하고 있다고 밝혀 논란은 사그라들었다.

[[분류: 비디오 게임 제작사]]

에픽 게임즈

2026-04-01T03:34:26Z

Senouis: /* 언리얼 엔진 */

'''에픽 게임즈'''(Epic Games)는 팀 스위니가 1991년 창립한 비디오 게임 소프트웨어 회사다.

== 역사 ==

이 회사는 1998년 자사에서 만든 언리얼과 언리얼 토너먼트가 성공하여 [[이드 소프트웨어]]의 퀘이크와 대결하면서 FPS 게임 제작사의 루키가 된다.

2006년에는 기어즈 오브 워를 개발하였으나 후속작 개발의 어려움으로 인해 마이크로소프트에 시리즈 IP를 매각하게 된다.

그 이후 UDK 공개 등 개발자 양성에 신경을 쓰고 있으며 [[포트나이트]]의 대성공으로 인해 시장가치가 폭증하였다.

== 언리얼 엔진 ==

이 회사에서 개발한 [[언리얼 엔진]]은 이드 소프트웨어의 id Tech 엔진과 맞먹을 정도로 뛰어난 렌더링 기능과 좋은 개발 편의성, 어느 정도 성능이 되기만 하면 그 이상의 성능을 내는 컴퓨터에서는 좋은 최적화 수준을 보여주고, 다양한 기능 추가로 인해 좋은 평가를 받았다.

언리얼 엔진 3부터는 조금씩 언리얼 엔진의 SDK를 배포하다 언리얼 엔진 4부터는 아예 라이센스 비용조차 조건부 무료에 엔진 소스코드 공개 및 월별 공짜 에셋 배포를 통해 초보 개발자들에게 사랑받는 게임 엔진이 되도록 노력하는 중이다. 특히 언리얼 엔진 3의 키스멧을 계승하여 언리얼 엔진 4부터 도입된 블루프린트 비주얼 스크립트 시스템은 비 프로그래머도 게임 로직 개발에 관여할 수 있도록 하여 개발 편의성을 크게 늘렸다.

스케치팹을 인수한 뒤로 다양한 게임 엔진에서 사용할 수 있는 게임 애셋을 팔 수 있게 팹(Fab)이라는 이름으로 애셋 스토어를 개편했다. 매달 3개의 애셋을 지정하여 공짜 구입 행사를 진행한다.

== 에픽 게임즈 스토어 ==
한편 비디오 게임 [[ESD]]의 대명사인 [[밸브 코퍼레이션]]의 [[스팀]]과 경쟁하기위해 에픽 게임즈 스토어를 열어 공짜 게임 이벤트 진행 및 독점작 확보 등 비디오 게임 판매 분야에서 다양한 프로모션을 진행하고 있다.

특히 [[문명 6]]을 공짜로 푼 것은 전설적인 프로모션으로 회자될 정도이다.

== TMI ==
* 중국의 [[텐센트]]가 에픽 게임즈에 대폭 투자하면서 중국으로 회사가 넘어가는 게 아니냐는 불안감이 있었으나 팀 스위니가 자신만이 경영권을 갖고 있는 과반의 주식을 소유하고 있다고 밝혀 논란은 사그라들었다.

[[분류: 비디오 게임 제작사]]

스팀

2026-04-01T03:32:16Z

Senouis: /* 왜 이렇게 인기가 높은가? */

[https://store.steampowered.com/ 바로가기]

'''스팀'''은 [[밸브 코퍼레이션]]이 만든 세계에서 가장 강력한 비디오 게임 [[ESD]]로 [[문명|중독성이]] [[풋볼 매니저|높은]] [[히어로즈 오브 마이트 앤 매직|게임들]]을 사서 깔게 '''만들어주는 것'''으로 유명하다. 그 인기에 관한 표현으로, 전 세계 1억 대 PC에 스팀이 설치되어 있으며, 한 번 빠지면 평균 10,000원에서 1,000,000원을 인출할 정도로 게임 구입에 열을 올리게 된다는 말이 있다.

== 왜 이렇게 인기가 높은가? ==
* 시장 선점: 스팀이 나왔을 때에는 경쟁자가 사실상 없었다. [[EA]]의 오리진과 [[에픽 게임즈]]의 에픽 게임즈 스토어는 정말 한참 뒤에 나온 탓에 후발주자로 불리한 시작을 했다. 그런 탓에 이들 ESD에서 파는 게임의 수는 스팀과 비교가 안될 정도로 적다.
* 개발자 친화적: 밸브 개발자 위키도 만들고 VAC를 공짜로 제공하는 등 인디 게임 개발자가 게임 판매에 도전하는 것을 쉽게 만들어준다. 한때는 그린라이트라는 제도를 통해 투표로 인디 게임 개발자들의 게임을 쉽게 올릴 수 있는 제도도 시행했을 정도이다.<ref>다만 그린라이트는 사기가 판을 치는 바람에 결국 제도가 폐지되었다.</ref> 다만 현재는 경쟁자들의 부상 및 스팀에서 노출되는 게임만 노출되는 문제로 인해 빛이 바랬다.
* '''엄청난 게임 가격 할인율''': 사실상 스팀이 인기를 끄는 이유로 심하면 원래 가격의 10분의 1(90% 할인)까지 가격을 주기적으로 낮추어 할인을 한다. 그래서 한번도 게임 안사본 스팀 유저는 있을 지언정 한번만 게임을 산 스팀 유저는 없다고. 찜 목록 기능을 활용해 미리 기억한 게임이 할인을 한다면 어느새 당신은 당신이 게임을 샀다는 결제 영수증을 보고 있을 것이다. 2020년대 이후 스팀이 욕을 먹어도 할인율 자체는 여전히 큰 수준으로 잡아서 아직 스팀의 ESD 점유율은 굳건하다.
** 다양하고 간편한 결제방법 제공: 아무런 플러그인 설치나 개인정보의 과도한 수집 없이 카드결제, 문화상품권 결제, 휴대폰 결제 등을 할 수 있다. 대한민국의 저열한 전자상거래 시스템과 비교하면 확실히 낫다.
* 커뮤니티 기능 제공: 각 게임마다 포럼을 만들어주는 것은 물론, 원한다면 특정 주제(예: 멀티플레이 서버 전용 커뮤니티)의 포럼을 유저가 직접 만들 수도 있다. [[에픽 게임즈|에픽 게임즈 스토어]]가 스팀을 꺾지 못하는 이유로 이걸 지적하는 PC 게이머도 있다.

상기한 이유로 나온지 20년이 다되어가는 2021년 현재에도 스팀의 위상은 여전하다. 오죽하면 영미권에서는 독과점 문제를 걱정할 정도.

== TMI ==
* 2010년대 후반 들어서 스팀에 관한 비판들이 나온다. 첫째로 밸브 코퍼레이션이 유저들과 너무 소통을 안 하고 일방적으로 스팀 내 기능을 바꿔버리는 것, 둘째로 스팀의 보안 체계에 관심이 없어서 [[중국]] 등지에서 커뮤니티 장터로 유저들의 돈을 도둑질해도 정책으로 대놓고 나몰라라 하고 있다는 것이다. 이 때문에 게이브 뉴웰이 2015년에 스팀의 유저 제작 MOD 유료화 정책을 꺼냈다가 욕만 엄청나게 먹고 철회한 이후로 스팀에 대해 좋게 보지 않는 시선이 늘어났다.

{{각주}}

[[분류:게임]]

스팀

2026-04-01T03:31:16Z

Senouis:

[https://store.steampowered.com/ 바로가기]

'''스팀'''은 [[밸브 코퍼레이션]]이 만든 세계에서 가장 강력한 비디오 게임 [[ESD]]로 [[문명|중독성이]] [[풋볼 매니저|높은]] [[히어로즈 오브 마이트 앤 매직|게임들]]을 사서 깔게 '''만들어주는 것'''으로 유명하다. 그 인기에 관한 표현으로, 전 세계 1억 대 PC에 스팀이 설치되어 있으며, 한 번 빠지면 평균 10,000원에서 1,000,000원을 인출할 정도로 게임 구입에 열을 올리게 된다는 말이 있다.

== 왜 이렇게 인기가 높은가? ==
* 시장 선점: 스팀이 나왔을 때에는 경쟁자가 사실상 없었다. [[EA]]의 오리진과 [[에픽 게임즈]]의 에픽 게임즈 스토어는 정말 한참 뒤에 나온 탓에 후발주자로 불리한 시작을 했다. 그런 탓에 이들 ESD에서 파는 게임의 수는 스팀과 비교가 안될 정도로 적다.
* 개발자 친화적: 밸브 개발자 위키도 만들고 VAC를 공짜로 제공하는 등 인디 게임 개발자가 게임 판매에 도전하는 것을 쉽게 만들어준다. 한때는 그린라이트라는 제도를 통해 투표로 인디 게임 개발자들의 게임을 쉽게 올릴 수 있는 제도도 시행했을 정도이다.<ref>다만 그린라이트는 사기가 판을 치는 바람에 결국 제도가 폐지되었다.</ref> 다만 현재는 경쟁자들의 부상 및 스팀에서 노출되는 게임만 노출되는 문제로 인해 빛이 바랬다.
* '''엄청난 게임 가격 할인율''': 사실상 스팀이 인기를 끄는 이유로 심하면 원래 가격의 10분의 1(90% 할인)까지 가격을 주기적으로 낮추어 할인을 한다. 그래서 한번도 게임 안사본 스팀 유저는 있을 지언정 한번만 게임을 산 스팀 유저는 없다고. 찜 목록 기능을 활용해 미리 기억한 게임이 할인을 한다면 어느새 당신은 당신이 게임을 샀다는 결제 영수증을 보고 있을 것이다. 2020년대 이후 스팀이 욕을 먹어도 할인율 자체는 여전히 큰 수준으로 잡아서 아직 스팀의 ESD 점유율은 굳건하다.
** 다양하고 간편한 결제방법 제공: 아무런 플러그인 설치나 개인정보의 과도한 수집 없이 카드결제, 문화상품권 결제, 휴대폰 결제 등을 할 수 있다. 대한민국의 저열한 전자상거래 시스템과 비교하면 확실히 낫다.
* 커뮤니티 기능 제공: 각 게임마다 포럼을 만들어주는 것은 물론, 원한다면 특정 주제(예: 멀티플레이 서버 전용 커뮤니티)의 포럼을 유저가 직접 만들 수도 있다. 에픽 게임즈 스토어가 스팀을 꺾지 못하는 이유로 이걸 지적하는 PC 게이머도 있다.

상기한 이유로 나온지 20년이 다되어가는 2021년 현재에도 스팀의 위상은 여전하다. 오죽하면 영미권에서는 독과점 문제를 걱정할 정도.
== TMI ==
* 2010년대 후반 들어서 스팀에 관한 비판들이 나온다. 첫째로 밸브 코퍼레이션이 유저들과 너무 소통을 안 하고 일방적으로 스팀 내 기능을 바꿔버리는 것, 둘째로 스팀의 보안 체계에 관심이 없어서 [[중국]] 등지에서 커뮤니티 장터로 유저들의 돈을 도둑질해도 정책으로 대놓고 나몰라라 하고 있다는 것이다. 이 때문에 게이브 뉴웰이 2015년에 스팀의 유저 제작 MOD 유료화 정책을 꺼냈다가 욕만 엄청나게 먹고 철회한 이후로 스팀에 대해 좋게 보지 않는 시선이 늘어났다.

{{각주}}

[[분류:게임]]

리버티게임

2026-04-01T03:28:45Z

Senouis:

{{웹사이트 정보
| 이름 = 리버티게임
| 패비콘 =
| 로고 = Libertygame_logo1.png
| 로고 설명 = 리버티게임 로고
| 그림 =
| 그림 설명 =
| 그림 크기 =
| 표어 = 리버티게임, 모두가 만들어가는 자유로운 게임
| 종류 = 유머/게임 [[위키]]
| 회원 가입 = 선택
| 언어 = [[한국어]]
| 프로그래밍 언어 = [[미디어위키]]
| 콘텐츠 라이선스 = [[ccl|CC BY-NC-SA 4.0]]
| 영리 여부 = 비영리
| 시작일 = [[2019년]] [[10월 12일]]
| 제작자 = Bd3076
| 운영자 = Senouis, BANIP, Hsl0, Js091213, Chabiytb0792
| 현재 상태 = 운영 중
| 주소 = {{url|https://libertyga.me}}(현재 서버 주소)
{{url|https://libertygame.work}}
}}

[[미디어위키]] 기반의 한국어 게임 창작 [[위키]].

== 역사 ==
[[2019년]] [[8월 11일]]의 [[백괴사전]] 데이터 소실 사태 이후 2달이 지나자 한 사용자가 2019년 5월 기준의 [[백괴게임]] 덤프 파일을 공유했고, 이를 이용한 여러 차례의 시행착오 끝에 [[2019년]] [[10월 12일]] Bd3076이라는 사용자가 만든 개인 서버에 백괴게임 미러가 만들어진다. 항상 그렇듯 처음에는 여러 오류가 있었지만 11월을 기점으로 정비가 상당부분 완료된다.

하지만 Bd3076의 학업 문제, 불안정한 개인 서버, 그리고 [[2020년]] [[1월 27일]] 백괴사전 서버관리자의 '이용자에게 쓰기 권한이 있는 사이트에는 백괴- 단어 사용을 불허한다'는 입장 표명으로 인해 사이트 명칭 변경 및 이전이 필요하다는 의견이 대두되었고, 여러 논의를 거쳐 같은 해 [[2월 17일]] [[Miraheze]]로 이전을 완료하게 된다. 한편 6월경 재정비가 완료되자 이제는 백괴게임에서 미뤄두었던 개혁을 실행해야 한다는 의견이 나왔고, 이에 구 백괴게임에서 시작된 문제점들을 고치는 작업을 진행하고 있다.

현재는 [[Miraheze]]에 있는 리버티게임, [[진실위키]], [[리버티책]], [[오사인덱스]], [[큰숲백과]]끼리 연합을 구성하고 있다.

2023년 6월 Miraheze에서 벗어나 독립 서버로 이전하는 계획이 발표되었다. AWS를 거쳐 현재는 오라클 클라우드에서 서버가 돌아가고 있다.

== 만우절 장난 ==
2024년부터 [[백괴사전]] 및 [[백괴게임]]에서 2010년대 진행하다 서버 파손 사태 이후인 2020년대 들어 중단된 만우절 장난의 전통을 계승하여 진행한다.

* 2024년: 전신이 된 백괴게임의 대문 레이아웃이 대신 송출된다.
* 2025년: 밸브 코퍼레이션의 [[스팀]] 홈페이지를 패러디한 화면이 송출되었다. 물론 비영리 서비스를 지향하는 만큼 모든 제품 가격이 0원(무료)로 나온다.
* 2026년: LLM AI의 대중화에 맞춰 AI 서비스를 패러디한 '리버티게임 2.0 AI' 화면이 송출되었다. 가짜 구독 서비스 화면까지 정교하게 패러디한 디테일이 일품이다.

== 같이 보기 ==
* [[백괴사전]]
* [[진실위키]]

{{각주}}
{{위키}}
{{퍼온문서|리브레 위키|리버티게임|1210166}}
[[분류:위키]]
[[분류:미디어위키 웹 사이트]]
[[분류:2019년 설립]]

트수

2026-03-13T09:26:48Z

Senouis:

[[트위치]]의 스트리밍 서비스를 이용하던 대한민국 유저들의 호칭. 전신은 [[다음팟 TV]] 스트리밍 서비스를 이용하던 유저들의 호칭인 팟수(다음'''팟''' + 백'''수'''의 합성어라고 보면 된다).

하루 종일 트위치를 즐겨보며 채팅은 반드시 반말로 하는 것이 주 특징이다. 스트리머의 일정에 철저하게 자기 자신을 맞추기에 낮을 밤으로 생각하고 밤을 낮으로 여기는지라, 아침 7시가 되면 "저녁 7시가 됐다!"라며 좋아하고 저녁 7시가 되면 "아침 7시가 됐다!"라며 좋아한다.

컨셉만 백수라면 그나마 다행이겠지만 진짜로 백수인 인간들이 존재한다는 게 문제라면 문제다. 매일매일 드립을 칠 궁리만 하기 때문에 채팅방에서는 별 이상한 소리가 다 튀어나온다. 개노잼일 경우도 허다하고, 이게 인간이 친 채팅이 맞나 의심스러운 것도 많다. 그래도 2010년대 후반부터 취업난이 심화되고, 시청자들의 세대교체가 되며 약해진 편이다.

[[마이 리틀 텔레비전]]을 움직이던 주 원동력이기도 하다. 그러나 다음팟이 플랫폼으로서의 매력을 상당 부분 잃어가면서, 많은 수의 백수들이 [[트위치]]로 보금자리를 옮겨갔다. 결국 원조 팟수는 다음TV팟이 카카오TV로 개편되면서 스트리밍 서비스를 포기하자 절멸해버렸고 대신 트위치 + 백수를 뜻하는 '''트수'''가 되었다.

인터넷 커뮤니티로는 [[팟수넷]]에 많이 상주하는 것으로 알려져 있었으나 그것도 이젠 옛말. 지금은 TWIP 커뮤니티나 네이버 카페, 디스코드, 디시인사이드 내 몇몇 갤러리 게시판 등으로 옮겨갔다.

이후 트위치가 국내 공식 서비스를 종료하면서 [[네이버]]의 치지직이 트위치의 시스템과 문화를 대부분 계승했기에 치지직 이용자를 치수라 부르는 경우가 있다. 하지만 팟수 문화를 온전히 이식받고 확장되는 발전사를 가진 트수의 경우와 달리 트위치코리아 서비스가 종료될 때 이세계아이돌을 비롯해 [[SOOP]](구 아프리카TV) 등지로 간 스트리머 및 시청자들이 꽤 있어 2024년부터 트수는 소멸한 것으로 간주된다.

[[분류:신조어]]

트수

2026-03-13T09:24:37Z

Senouis:

[[트위치]]의 스트리밍 서비스를 이용하던 대한민국 유저들의 호칭. 전신은 [[다음팟 TV]] 스트리밍 서비스를 이용하던 유저들의 호칭인 팟수(다음'''팟''' + 백'''수'''의 합성어라고 보면 된다).

하루 종일 트위치를 즐겨보며 채팅은 반드시 반말로 하는 것이 주 특징이다. 스트리머의 일정에 철저하게 자기 자신을 맞추기에 낮을 밤으로 생각하고 밤을 낮으로 여기는지라, 아침 7시가 되면 "저녁 7시가 됐다!"라며 좋아하고 저녁 7시가 되면 "아침 7시가 됐다!"라며 좋아한다.

컨셉만 백수라면 그나마 다행이겠지만 진짜로 백수인 인간들이 존재한다는 게 문제라면 문제다. 매일매일 드립을 칠 궁리만 하기 때문에 채팅방에서는 별 이상한 소리가 다 튀어나온다. 개노잼일 경우도 허다하고, 이게 인간이 친 채팅이 맞나 의심스러운 것도 많다.

[[마이 리틀 텔레비전]]을 움직이던 주 원동력이기도 하다. 그러나 다음팟이 플랫폼으로서의 매력을 상당 부분 잃어가면서, 많은 수의 백수들이 [[트위치]]로 보금자리를 옮겨갔다. 결국 원조 팟수는 다음TV팟이 카카오TV로 개편되면서 스트리밍 서비스를 포기하자 절멸해버렸고 대신 트위치 + 백수를 뜻하는 '''트수'''가 되었다.

인터넷 커뮤니티로는 [[팟수넷]]에 많이 상주하는 것으로 알려져 있었으나 그것도 이젠 옛말. 지금은 TWIP 커뮤니티나 네이버 카페, 디스코드, 디시인사이드 내 몇몇 갤러리 게시판 등으로 옮겨갔다.

이후 트위치가 국내 공식 서비스를 종료하면서 [[네이버]]의 치지직이 트위치의 시스템과 문화를 대부분 계승했기에 치지직 이용자를 치수라 부르는 경우가 있다. 하지만 팟수 문화를 온전히 이식받고 확장되는 발전사를 가진 트수의 경우와 달리 트위치코리아 서비스가 종료될 때 이세계아이돌을 비롯해 [[SOOP]](구 아프리카TV) 등지로 간 스트리머 및 시청자들이 꽤 있어 2024년부터 트수는 소멸한 것으로 간주된다.

[[분류:신조어]]

트수

2026-03-13T09:23:18Z

Senouis:

[[트위치]]의 스트리밍 서비스를 이용하던 대한민국 유저들의 호칭. 전신은 [[다음팟 TV]] 스트리밍 서비스를 이용하던 유저들의 호칭인 팟수(다음'''팟''' + 백'''수'''의 합성어라고 보면 된다).

하루 종일 트위치를 즐겨보며 채팅은 반드시 반말로 하는 것이 주 특징이다. 스트리머의 일정에 철저하게 자기 자신을 맞추기에 낮을 밤으로 생각하고 밤을 낮으로 여기는지라, 아침 7시가 되면 "저녁 7시가 됐다!"라며 좋아하고 저녁 7시가 되면 "아침 7시가 됐다!"라며 좋아한다.

컨셉만 백수라면 그나마 다행이겠지만 진짜로 백수인 인간들이 존재한다는 게 문제라면 문제다. 매일매일 드립을 칠 궁리만 하기 때문에 채팅방에서는 별 이상한 소리가 다 튀어나온다. 개노잼일 경우도 허다하고, 이게 인간이 친 채팅이 맞나 의심스러운 것도 많다.

[[마이 리틀 텔레비전]]을 움직이던 주 원동력이기도 하다. 그러나 다음팟이 플랫폼으로서의 매력을 상당 부분 잃어가면서, 많은 수의 백수들이 [[트위치]]로 보금자리를 옮겨갔다. 결국 원조 팟수는 다음TV팟이 카카오TV로 개편되면서 스트리밍 서비스를 포기하자 절멸해버렸고 대신 트위치 + 백수를 뜻하는 '''트수'''가 되었다.

인터넷 커뮤니티로는 [[팟수넷]]에 많이 상주하는 것으로 알려져 있었으나 그것도 이젠 옛말. 지금은 TWIP 커뮤니티나 네이버 카페, 디스코드, 디시인사이드 내 몇몇 갤러리 게시판 등으로 옮겨갔다.

이후 트위치가 국내 공식 서비스를 종료하면서 [[네이버]]의 치지직이 트위치의 시스템과 문화를 대부분 계승했기에 치지직 이용자를 치수라 부르는 경우가 있다. 하지만 팟수 문화를 온전히 이식받아 확장되는 고유한 발전사를 가진 트수의 경우와 달리 트위치코리아 서비스가 종료될 때 이세계아이돌을 비롯해 [[SOOP]](구 아프리카TV) 등지로 간 스트리머 및 시청자들이 꽤 있어 2024년부터 트수는 소멸한 것으로 간주된다.

[[분류:신조어]]

NVIDIA

2026-01-04T05:21:19Z

Senouis: /* 특징 */

'''NVIDIA''' 또는 엔비디아는 1993년 젠슨 황에 의해 창립된 그래픽 칩셋(GPU) 제조 회사이다.

2023년 5월 30일에 반도체 집적회로 제품 전문 설계 및 제작사로서 최초로 나스닥 시가총액 1조 달러를 돌파한 기업으로, 외장 그래픽 카드 제조업계와 신경망 기반 AI 개발업계, 자율주행 차량 설계업계에서 시장 지배적인 위치에 있는 국제적 규모의 대기업이다.
==역사==
1993년에 혜성처럼 나타난 NVIDIA는 1990년대 말에 내놓은 RIVA시리즈로 당시 3D 그래픽 가속 카드의 제왕이던 3dfx를 제압하여 몰락시키고 2002년에 파산시킨다.

이때 덤으로 S3 그래픽스와 PowerVR이 나가떨어지고 창립 10년만에 NVIDIA는 [[그래픽 카드]] 칩셋 시장을 장악하게 된다.

이후 다른 그래픽 칩셋 제조회사를 거의 다 인수한 ATI와 20년 가까이 경쟁하고 있으며 지포스 FX 시리즈<ref>창립자였던 [[젠슨 황]]은 이걸 출시한 직후가 엔비디아에게 가장 위험했던 순간이었다고 하며, 대한민국의 [[PC방]]들이 이걸 다 쓸어가지 않았으면 3dfx 인수 후라 재정 상황이 약해졌을 엔비디아 역시 파산했을 수 있었다고 한다.</ref>와 GTX 400 시리즈를 내놓은 때를 제외하면 항상 ATI(현 [[AMD]] Radeon Technology Group)와의 경쟁에서 우위를 점하고 있다.

===CUDA와 GPGPU ===

2008년부터 CUDA라는 병렬 연산용 라이브러리를 만들고 학계에 어필하면서 [[인공지능|신경망 AI]]에 사용할 수 있도록 투자를 많이 했는데 2022년 하반기부터 신경망 AI 기반 생성형 AI 붐이 불면서 무지막지한 떡상을 하여 고부가가치 사업이 아닌 엄연한 제조업체임에도 시가총액에서 [[페이스북]]을 능가하고 [[구글]]을 추격하는 등 엄청난 떡상을 하였다. 그래서 엔비디아에서 만드는 개발용 보드인 젯슨(Jetson) 시리즈도 그래픽 성능이 높은 특이한 ARM 기반 SBC 취급 받던 초기와 달리 지금은 임베디드 인공지능 기기 개발과 자율주행 서비스 개발의 필수품 취급을 받고 있다.

== 특징 ==
NVIDIA는 팹리스 회사로, GPU의 설계만 하고 실물 제작은 [[TSMC]] 같은 반도체 부품 제조회사에 맡긴다. 이는 반대로 독점 생산을 기획했던 3dfx를 몰락시킨 방법이기도 하다.<ref>참고로 ATI는 3dfx 망하는 꼴을 보고 레퍼런스 그래픽 카드 제조 사업부를 사실상 분리하게 되는데, 이로 인해 세워진 회사가 지금도 라데온 그래픽 카드만 전문적으로 생산하여 평이 좋은 사파이어 사다.</ref>

B2C 시장에서는 게이머들과 게임 제작사들과의 협력을 통해 독점적인 PC 그래픽 카드 솔루션을 구축했으며 B2B 시장에서는 온갖 갑질과 계약 파탄으로 인해 이미지가 좋지 않다. 하지만 신경망 AI 열풍으로 AI가 주력 사업부문이 되자 기업들에게는 적극적으로 어필하며 가속기를 주는데 반해 소비자용 그래픽 카드는 계속 가성비가 나빠져서 시장 내 이미지가 반대가 된 상황.
<ref>경쟁사인 AMD는 애플과의 관계가 나쁘지 않아 라데온 그래픽 카드를 대체재로 공급한 적이 있으며 플레이스테이션/Xbox/스팀 덱의 사례처럼 가정용 콘솔 게임기 제작사 및 핸드헬드 PC 제조사에 핵심 부품을 납품하는 등 B2B 커스텀 그래픽 칩셋 시장에서 두각을 드러내고 있다.</ref> 하지만 NVIDIA 제품의 성능이 뛰어나고 [[CUDA]]의 보급 등 시장 선점 능력이 좋다보니 엄청난 연산력을 필요로 하는 데이터센터 등지에서는 어쩔 수 없이 NVIDIA의 GPU를 사용하고 있다.

최근에는 자율주행 자동차, 인공신경망 연구 등 사업을 다각화하고 있다. 둘 다 성과가 좋아 자율 주행 차량용 칩셋은 대부분 엔비디아제이며, 2022년부터 [[ChatGPT]]와 [[NovelAI]] 이미지 제너레이터로 데이터 생성 AI에 대한 관심이 높아지며 엔비디아의 GPU가 AI 연구 개발 용도로 엄청나게 팔리고 있다.

[[ARM]] Holdings를 인수하여 자체 CPU 개발력을 확보하려고 시도하고 있으나 전술한 B2B 시장에서의 악명 때문에 인수가 늦어지다가 결국 엔비디아가 인수를 포기하게 되었다고 한다. 그래도 [[Tegra|테그라]]가 [[닌텐도 스위치]]에 들어가는 등 ARM 호환 CPU의 제조는 계속하고 있다.

==제품군==
* NV1과 NV2, RIVA 시리즈: 창업 후 초기에 개발하던 그래픽 카드 명칭
* [[Geforce 시리즈]] : 일반 사용자용 그래픽 카드. 실시간 레이트레이싱 지원 유무에 따라 Geforce RTX와 Geforce GTX로 나뉜다.
* RTX 시리즈: 2020년부터 아래 두 브랜드가 RTX 시리즈라는 이름으로 병합되었다.
** Quadro 시리즈: 그래픽 디자인 전문가용 그래픽 카드다.
** Tesla 시리즈: 데이터센터용 그래픽 카드다.
* nForce 시리즈: AMD CPU용 메인보드 칩셋, 현재는 단종되었다.
* Tegra 시리즈: 엔비디아에서 만든 [[ARM]] 호환 [[CPU]]이다.
* Geforce NOW™: 엔비디아의 클라우드 게이밍 플랫폼이다.

[[분류:IT]]
[[분류: 미국의 기업]]

NVIDIA

2026-01-04T05:14:50Z

Senouis: /* 역사 */

'''NVIDIA''' 또는 엔비디아는 1993년 젠슨 황에 의해 창립된 그래픽 칩셋(GPU) 제조 회사이다.

2023년 5월 30일에 반도체 집적회로 제품 전문 설계 및 제작사로서 최초로 나스닥 시가총액 1조 달러를 돌파한 기업으로, 외장 그래픽 카드 제조업계와 신경망 기반 AI 개발업계, 자율주행 차량 설계업계에서 시장 지배적인 위치에 있는 국제적 규모의 대기업이다.
==역사==
1993년에 혜성처럼 나타난 NVIDIA는 1990년대 말에 내놓은 RIVA시리즈로 당시 3D 그래픽 가속 카드의 제왕이던 3dfx를 제압하여 몰락시키고 2002년에 파산시킨다.

이때 덤으로 S3 그래픽스와 PowerVR이 나가떨어지고 창립 10년만에 NVIDIA는 [[그래픽 카드]] 칩셋 시장을 장악하게 된다.

이후 다른 그래픽 칩셋 제조회사를 거의 다 인수한 ATI와 20년 가까이 경쟁하고 있으며 지포스 FX 시리즈<ref>창립자였던 [[젠슨 황]]은 이걸 출시한 직후가 엔비디아에게 가장 위험했던 순간이었다고 하며, 대한민국의 [[PC방]]들이 이걸 다 쓸어가지 않았으면 3dfx 인수 후라 재정 상황이 약해졌을 엔비디아 역시 파산했을 수 있었다고 한다.</ref>와 GTX 400 시리즈를 내놓은 때를 제외하면 항상 ATI(현 [[AMD]] Radeon Technology Group)와의 경쟁에서 우위를 점하고 있다.

===CUDA와 GPGPU ===

2008년부터 CUDA라는 병렬 연산용 라이브러리를 만들고 학계에 어필하면서 [[인공지능|신경망 AI]]에 사용할 수 있도록 투자를 많이 했는데 2022년 하반기부터 신경망 AI 기반 생성형 AI 붐이 불면서 무지막지한 떡상을 하여 고부가가치 사업이 아닌 엄연한 제조업체임에도 시가총액에서 [[페이스북]]을 능가하고 [[구글]]을 추격하는 등 엄청난 떡상을 하였다. 그래서 엔비디아에서 만드는 개발용 보드인 젯슨(Jetson) 시리즈도 그래픽 성능이 높은 특이한 ARM 기반 SBC 취급 받던 초기와 달리 지금은 임베디드 인공지능 기기 개발과 자율주행 서비스 개발의 필수품 취급을 받고 있다.

== 특징 ==
NVIDIA는 팹리스 회사로, GPU의 설계만 하고 실물 제작은 [[TSMC]] 같은 반도체 부품 제조회사에 맡긴다. 이는 반대로 독점 생산을 기획했던 3dfx를 몰락시킨 방법이기도 하다.<ref>참고로 ATI는 3dfx 망하는 꼴을 보고 레퍼런스 그래픽 카드 제조 사업부를 사실상 분리하게 되는데, 이로 인해 세워진 회사가 지금도 라데온 그래픽 카드만 전문적으로 생산하여 평이 좋은 사파이어 사다.</ref>

B2C 시장에서는 게이머들과 게임 제작사들과의 협력을 통해 독점적인 PC 그래픽 카드 솔루션을 구축했으나 B2B 시장에서는 온갖 갑질과 계약 파탄으로 인해 이미지가 좋지 않다.<ref>반대로 AMD는 애플과의 관계가 좋고 콘솔 게임기 제작사에 핵심 부품을 납품하는 등 B2B 커스텀 그래픽 칩셋 시장에서 두각을 드러내고 있다.</ref> 하지만 NVIDIA 제품의 성능이 뛰어나고 [[CUDA]]의 보급 등 시장 선점 능력이 좋다보니 엄청난 연산력을 필요로 하는 데이터센터 등지에서는 어쩔 수 없이 NVIDIA의 GPU를 사용하고 있다.

최근에는 자율주행 자동차, 인공신경망 연구 등 사업을 다각화하고 있다. 둘 다 성과가 좋아 자율 주행 차량용 칩셋은 대부분 엔비디아제이며, 2022년부터 [[ChatGPT]]와 [[NovelAI]] 이미지 제너레이터로 데이터 생성 AI에 대한 관심이 높아지며 엔비디아의 GPU가 AI 연구 개발 용도로 엄청나게 팔리고 있다.

최근에는 [[ARM]] Holdings를 인수하여 자체 CPU 개발력을 확보하려고 시도하고 있으나 전술한 B2B 시장에서의 악명 때문에 인수가 늦어지다가 결국 엔비디아가 인수를 포기하게 되었다고 한다.

==제품군==
* NV1과 NV2, RIVA 시리즈: 창업 후 초기에 개발하던 그래픽 카드 명칭
* [[Geforce 시리즈]] : 일반 사용자용 그래픽 카드. 실시간 레이트레이싱 지원 유무에 따라 Geforce RTX와 Geforce GTX로 나뉜다.
* RTX 시리즈: 2020년부터 아래 두 브랜드가 RTX 시리즈라는 이름으로 병합되었다.
** Quadro 시리즈: 그래픽 디자인 전문가용 그래픽 카드다.
** Tesla 시리즈: 데이터센터용 그래픽 카드다.
* nForce 시리즈: AMD CPU용 메인보드 칩셋, 현재는 단종되었다.
* Tegra 시리즈: 엔비디아에서 만든 [[ARM]] 호환 [[CPU]]이다.
* Geforce NOW™: 엔비디아의 클라우드 게이밍 플랫폼이다.

[[분류:IT]]
[[분류: 미국의 기업]]

CUDA

2026-01-04T05:10:14Z

Senouis: /* 탄생 배경과 현황 */

[[분류: IT]]
[[분류: 컴퓨터]]

'''CUDA'''는 [[NVIDIA]] 사에서 제공하는 GPGPU 솔루션(CUDA API) 및 그 실행 주체가 되는 [[그래픽 카드]] 내의 연산부(CUDA Core)를 뜻한다. 현재 GPGPU를 잘 활용하는 신경망 [[인공지능]] 연구 분야에서 절대적인 입지를 가지고 있다

== 탄생 배경과 현황 ==
그래픽 카드는 원래 2D 및 3D [[렌더링]]을 위해 대량의 SIMD 명령어를 위주로 한꺼번에 작동하도록 특별히 설계된 IC 칩이기 때문에 CPU의 벡터 명령어 집합처럼 벡터 프로세싱에 특화되어 있다. 이때 컴퓨터공학 전문가들이 GPU를 가지고 과학적 연구를 위한 수치 연산을 시도할 것이라는 것을 예상한 NVIDIA는 2006년 발표된 G80 GPU(Geforce 8000번대)부터 MIMD 명령어도 집어넣어 최초로 그래픽스 연산이 아닌 벡터 프로세싱 연산도 지원하도록 개선하고 관련 툴 프로그램(SDK)도 제공하였다. 이에 뒤늦게 2009년에 [[Apple]]이 주도하여 개발한 [[OpenCL]]을 중심으로 [[인텔]]과 [[AMD]]가 반격을 시도했으나 이미 3년이나 벌어진 발표 시기 사이에 CUDA를 활용한 각종 라이브러리가 쏟아져 나왔고 OpenCL의 기능은 CUDA도 다 지원할 수 있었기 때문에 이 CUDA 라이브러리들을 전부 OpenCL로 포팅하는 시도는 대부분 좌절되었고 현재까지도 CUDA가 OpenCL에 비해 범용 연산에 대한 수요 측면에서 우위를 차지하는 환경이 조성되었다. 이후로 나오는 ROCm이나 OneAPI 같은 후발주자도 가뿐하게 물리치는 상황이다.

TensorFlow, Pytorch 같은 신경망 AI 프레임워크들도 모두 CUDA를 사용한 GPU 기반 AI 가속을 중점적으로 지원한다

== 사용법 ==
우선 사용자가 [[C언어|C]]/[[C++]] [[프로그래밍 언어]]를 알고 있다는 전제 하에 CPU를 Host, GPU를 Device로 서술한다.

# 먼저 드라이버와 함께 nvcc라는 프로그램이 컴퓨터에 설치되어 있는지 확인한다. nvcc는 CUDA를 사용하는 프로그램 내부의 CUDA 명령어를 활용하는 함수(Kernel이라고 한다)를 먼저 컴파일해주는 전처리를 담당한다.
# CUDA 프로그램 소스 코드의 확장자는 일반적으로 cu이다. 따라서 example.cu 같은 파일을 생성한다.
# 1.에서 다룬 Kernel을 작성한다. 이때 함수 정의 앞에 __global__ 같이 작성할 함수가 Kernel이라는 표시를 꼭 붙인다.
# 이제 Kernel을 사용하는 CPU 측 코드를 짜되 다음과 같은 순서로 작성한다.
:# 먼저 dim3 같은 데이터 형으로 GPGPU 기능을 사용하기 위한 Grid와 Block을 정의한다. 여기서 Grid는 Block 꾸러미이고, Block은 실제 Kernel의 병렬 처리 실행 단위인 Thread의 꾸러미라고 생각하자. 가령 Geforce에서는 하나의 Grid에 Block이 최대 32개까지 존재하며 하나의 Block 안에 1024개의 Thread가 존재하므로 이 중에 필요한 만큼 Grid와 Block 사이즈를 정한다.
:# cudamalloc 함수를 통해 그래픽 카드의 VRAM의 일부를 kernel에 넘길 데이터 할당 공간으로 받아온다.
:# cudamemcpy 함수에 파라미터를 VRAM 상의 데이터 공간, Host 프로그램의 데이터 공간, 복사할 데이터 크기, 데이터 복사 방향(cudaHostToDevice, cudaDeviceToHost 등) 순서로 넘긴다.
:# Kernel을 호출한다.
:# Kernel 호출이 끝나면 cudafree로 VRAM 상의 데이터 공간을 할당 해제해야 한다.
* Kernel을 호출할 때에는 <nowiki>KernelFunc<<<Grid, Block>>>(param1, ...);</nowiki> 식으로 호출한다.
* Makefile 등으로 프로그램 컴파일 순서를 지정할 때 nvcc 컴파일러->일반 컴파일러 순서로 작동하도록 작성하여 프로그램을 기계어로 바꾼다.
* 주의할 점으로, Kernel 내부에서는 if~else 구문을 사용하지 않는 것이 강력히 권장된다. 만일 Kernel 내부에 if문 같은 조건문이 나올 경우 nvcc는 GPU의 연산 자원을 반으로 갈라 조건문이 참일 경우와 거짓일 경우를 모두 계산한 뒤 맞는 연산만 취사 선택하는 식으로 비효율적인 계산을 하게 된다. 조건문이나 반복문은 CPU 상에서 실행되는 프로그램에서 처리해야 한다.

== 예제 코드 ==

== TMI ==
* 일반적으로 게임에서 활용하는 32bit 부동 소수점 연산(단정밀도 연산)은 NVIDIA의 모든 카드가 같은 GPU 클럭에서 동일한 성능을 제공하나 그래픽스 작업(영상 편집, 렌더링)에서 주로 활용하는 64bit 부동소수점 연산(배정밀도 연산)은 게이머들이 많이 사가는 Geforce보다 그래픽스 전문가용 그래픽 카드인 Quadro 및 데이터 센터에서의 수치 연산 전용 그래픽 카드인 Tesla 시리즈에서 더 빠르다. 이는 Geforce 400 시리즈에서 NVIDIA가 절대 성능 우위를 사수하기 위해 무리하게 CUDA 코어를 때려 박았다가 엄청난 발열로 혹평을 듣자 급히 하위 제품군에서 배정밀도 연산부를 크게 쳐냈기 때문이다. 그런데 이게 전화위복이 되어 Geforce 700번대부터 Geforce 10 시리즈까지 NVIDIA 그래픽 카드의 전력 소모 대비 성능 향상 폭이 매우 크게 되어 배정밀도 연산을 포기할 수 없었던 AMD의 GCN 아키텍처 기반 라데온을 Geforce가 저발열 고성능 특성으로 찍어 누르는 원동력이 되었다.

CUDA

2026-01-04T05:04:25Z

Senouis:

[[분류: IT]]
[[분류: 컴퓨터]]

'''CUDA'''는 [[NVIDIA]] 사에서 제공하는 GPGPU 솔루션(CUDA API) 및 그 실행 주체가 되는 [[그래픽 카드]] 내의 연산부(CUDA Core)를 뜻한다. 현재 GPGPU를 잘 활용하는 신경망 [[인공지능]] 연구 분야에서 절대적인 입지를 가지고 있다

== 탄생 배경 ==
그래픽 카드는 원래 2D 및 3D [[렌더링]]을 위해 대량의 SIMD 명령어를 위주로 한꺼번에 작동하도록 특별히 설계된 IC 칩이기 때문에 CPU의 벡터 명령어 집합처럼 벡터 프로세싱에 특화되어 있다. 이때 컴퓨터공학 전문가들이 GPU를 가지고 과학적 연구를 위한 수치 연산을 시도할 것이라는 것을 예상한 NVIDIA는 2006년 발표된 G80 GPU(Geforce 8000번대)부터 MIMD 명령어도 집어넣어 최초로 그래픽스 연산이 아닌 벡터 프로세싱 연산도 지원하도록 개선하고 관련 툴 프로그램(SDK)도 제공하였다. 이에 뒤늦게 2009년에 [[Apple]]이 주도하여 개발한 [[OpenCL]]을 중심으로 [[인텔]]과 [[AMD]]가 반격을 시도했으나 이미 3년이나 벌어진 발표 시기 사이에 CUDA를 활용한 각종 라이브러리가 쏟아져 나왔고 OpenCL의 기능은 CUDA도 다 지원할 수 있었기 때문에 이 CUDA 라이브러리들을 전부 OpenCL로 포팅하는 시도는 대부분 좌절되었고 현재까지도 CUDA가 OpenCL에 비해 범용 연산에 대한 수요 측면에서 우위를 차지하는 환경이 조성되었다.

== 사용법 ==
우선 사용자가 [[C언어|C]]/[[C++]] [[프로그래밍 언어]]를 알고 있다는 전제 하에 CPU를 Host, GPU를 Device로 서술한다.

# 먼저 드라이버와 함께 nvcc라는 프로그램이 컴퓨터에 설치되어 있는지 확인한다. nvcc는 CUDA를 사용하는 프로그램 내부의 CUDA 명령어를 활용하는 함수(Kernel이라고 한다)를 먼저 컴파일해주는 전처리를 담당한다.
# CUDA 프로그램 소스 코드의 확장자는 일반적으로 cu이다. 따라서 example.cu 같은 파일을 생성한다.
# 1.에서 다룬 Kernel을 작성한다. 이때 함수 정의 앞에 __global__ 같이 작성할 함수가 Kernel이라는 표시를 꼭 붙인다.
# 이제 Kernel을 사용하는 CPU 측 코드를 짜되 다음과 같은 순서로 작성한다.
:# 먼저 dim3 같은 데이터 형으로 GPGPU 기능을 사용하기 위한 Grid와 Block을 정의한다. 여기서 Grid는 Block 꾸러미이고, Block은 실제 Kernel의 병렬 처리 실행 단위인 Thread의 꾸러미라고 생각하자. 가령 Geforce에서는 하나의 Grid에 Block이 최대 32개까지 존재하며 하나의 Block 안에 1024개의 Thread가 존재하므로 이 중에 필요한 만큼 Grid와 Block 사이즈를 정한다.
:# cudamalloc 함수를 통해 그래픽 카드의 VRAM의 일부를 kernel에 넘길 데이터 할당 공간으로 받아온다.
:# cudamemcpy 함수에 파라미터를 VRAM 상의 데이터 공간, Host 프로그램의 데이터 공간, 복사할 데이터 크기, 데이터 복사 방향(cudaHostToDevice, cudaDeviceToHost 등) 순서로 넘긴다.
:# Kernel을 호출한다.
:# Kernel 호출이 끝나면 cudafree로 VRAM 상의 데이터 공간을 할당 해제해야 한다.
* Kernel을 호출할 때에는 <nowiki>KernelFunc<<<Grid, Block>>>(param1, ...);</nowiki> 식으로 호출한다.
* Makefile 등으로 프로그램 컴파일 순서를 지정할 때 nvcc 컴파일러->일반 컴파일러 순서로 작동하도록 작성하여 프로그램을 기계어로 바꾼다.
* 주의할 점으로, Kernel 내부에서는 if~else 구문을 사용하지 않는 것이 강력히 권장된다. 만일 Kernel 내부에 if문 같은 조건문이 나올 경우 nvcc는 GPU의 연산 자원을 반으로 갈라 조건문이 참일 경우와 거짓일 경우를 모두 계산한 뒤 맞는 연산만 취사 선택하는 식으로 비효율적인 계산을 하게 된다. 조건문이나 반복문은 CPU 상에서 실행되는 프로그램에서 처리해야 한다.

== 예제 코드 ==

== TMI ==
* 일반적으로 게임에서 활용하는 32bit 부동 소수점 연산(단정밀도 연산)은 NVIDIA의 모든 카드가 같은 GPU 클럭에서 동일한 성능을 제공하나 그래픽스 작업(영상 편집, 렌더링)에서 주로 활용하는 64bit 부동소수점 연산(배정밀도 연산)은 게이머들이 많이 사가는 Geforce보다 그래픽스 전문가용 그래픽 카드인 Quadro 및 데이터 센터에서의 수치 연산 전용 그래픽 카드인 Tesla 시리즈에서 더 빠르다. 이는 Geforce 400 시리즈에서 NVIDIA가 절대 성능 우위를 사수하기 위해 무리하게 CUDA 코어를 때려 박았다가 엄청난 발열로 혹평을 듣자 급히 하위 제품군에서 배정밀도 연산부를 크게 쳐냈기 때문이다. 그런데 이게 전화위복이 되어 Geforce 700번대부터 Geforce 10 시리즈까지 NVIDIA 그래픽 카드의 전력 소모 대비 성능 향상 폭이 매우 크게 되어 배정밀도 연산을 포기할 수 없었던 AMD의 GCN 아키텍처 기반 라데온을 Geforce가 저발열 고성능 특성으로 찍어 누르는 원동력이 되었다.

CUDA

2026-01-04T05:01:55Z

Senouis: /* 사용법 */

[[분류: IT]]
[[분류: 컴퓨터]]

'''CUDA'''는 [[NVIDIA]] 사에서 제공하는 GPGPU 솔루션(CUDA API) 및 그 실행 주체가 되는 [[그래픽 카드]] 내의 연산부(CUDA Core)를 뜻한다.

== 탄생 배경 ==
그래픽 카드는 원래 2D 및 3D [[렌더링]]을 위해 대량의 SIMD 명령어를 위주로 한꺼번에 작동하도록 특별히 설계된 IC 칩이기 때문에 CPU의 벡터 명령어 집합처럼 벡터 프로세싱에 특화되어 있다. 이때 컴퓨터공학 전문가들이 GPU를 가지고 과학적 연구를 위한 수치 연산을 시도할 것이라는 것을 예상한 NVIDIA는 2006년 발표된 G80 GPU(Geforce 8000번대)부터 MIMD 명령어도 집어넣어 최초로 그래픽스 연산이 아닌 벡터 프로세싱 연산도 지원하도록 개선하고 관련 툴 프로그램(SDK)도 제공하였다. 이에 뒤늦게 2009년에 [[Apple]]이 주도하여 개발한 [[OpenCL]]을 중심으로 [[인텔]]과 [[AMD]]가 반격을 시도했으나 이미 3년이나 벌어진 발표 시기 사이에 CUDA를 활용한 각종 라이브러리가 쏟아져 나왔고 OpenCL의 기능은 CUDA도 다 지원할 수 있었기 때문에 이 CUDA 라이브러리들을 전부 OpenCL로 포팅하는 시도는 대부분 좌절되었고 현재까지도 CUDA가 OpenCL에 비해 범용 연산에 대한 수요 측면에서 우위를 차지하는 환경이 조성되었다.

== 사용법 ==
우선 사용자가 [[C언어|C]]/[[C++]] [[프로그래밍 언어]]를 알고 있다는 전제 하에 CPU를 Host, GPU를 Device로 서술한다.

# 먼저 드라이버와 함께 nvcc라는 프로그램이 컴퓨터에 설치되어 있는지 확인한다. nvcc는 CUDA를 사용하는 프로그램 내부의 CUDA 명령어를 활용하는 함수(Kernel이라고 한다)를 먼저 컴파일해주는 전처리를 담당한다.
# CUDA 프로그램 소스 코드의 확장자는 일반적으로 cu이다. 따라서 example.cu 같은 파일을 생성한다.
# 1.에서 다룬 Kernel을 작성한다. 이때 함수 정의 앞에 __global__ 같이 작성할 함수가 Kernel이라는 표시를 꼭 붙인다.
# 이제 Kernel을 사용하는 CPU 측 코드를 짜되 다음과 같은 순서로 작성한다.
:# 먼저 dim3 같은 데이터 형으로 GPGPU 기능을 사용하기 위한 Grid와 Block을 정의한다. 여기서 Grid는 Block 꾸러미이고, Block은 실제 Kernel의 병렬 처리 실행 단위인 Thread의 꾸러미라고 생각하자. 가령 Geforce에서는 하나의 Grid에 Block이 최대 32개까지 존재하며 하나의 Block 안에 1024개의 Thread가 존재하므로 이 중에 필요한 만큼 Grid와 Block 사이즈를 정한다.
:# cudamalloc 함수를 통해 그래픽 카드의 VRAM의 일부를 kernel에 넘길 데이터 할당 공간으로 받아온다.
:# cudamemcpy 함수에 파라미터를 VRAM 상의 데이터 공간, Host 프로그램의 데이터 공간, 복사할 데이터 크기, 데이터 복사 방향(cudaHostToDevice, cudaDeviceToHost 등) 순서로 넘긴다.
:# Kernel을 호출한다.
:# Kernel 호출이 끝나면 cudafree로 VRAM 상의 데이터 공간을 할당 해제해야 한다.
* Kernel을 호출할 때에는 <nowiki>KernelFunc<<<Grid, Block>>>(param1, ...);</nowiki> 식으로 호출한다.
* Makefile 등으로 프로그램 컴파일 순서를 지정할 때 nvcc 컴파일러->일반 컴파일러 순서로 작동하도록 작성하여 프로그램을 기계어로 바꾼다.
* 주의할 점으로, Kernel 내부에서는 if~else 구문을 사용하지 않는 것이 강력히 권장된다. 만일 Kernel 내부에 if문 같은 조건문이 나올 경우 nvcc는 GPU의 연산 자원을 반으로 갈라 조건문이 참일 경우와 거짓일 경우를 모두 계산한 뒤 맞는 연산만 취사 선택하는 식으로 비효율적인 계산을 하게 된다. 조건문이나 반복문은 CPU 상에서 실행되는 프로그램에서 처리해야 한다.

== 예제 코드 ==

== TMI ==
* 일반적으로 게임에서 활용하는 32bit 부동 소수점 연산(단정밀도 연산)은 NVIDIA의 모든 카드가 같은 GPU 클럭에서 동일한 성능을 제공하나 그래픽스 작업(영상 편집, 렌더링)에서 주로 활용하는 64bit 부동소수점 연산(배정밀도 연산)은 게이머들이 많이 사가는 Geforce보다 그래픽스 전문가용 그래픽 카드인 Quadro 및 데이터 센터에서의 수치 연산 전용 그래픽 카드인 Tesla 시리즈에서 더 빠르다. 이는 Geforce 400 시리즈에서 NVIDIA가 절대 성능 우위를 사수하기 위해 무리하게 CUDA 코어를 때려 박았다가 엄청난 발열로 혹평을 듣자 급히 하위 제품군에서 배정밀도 연산부를 크게 쳐냈기 때문이다. 그런데 이게 전화위복이 되어 Geforce 700번대부터 Geforce 10 시리즈까지 NVIDIA 그래픽 카드의 전력 소모 대비 성능 향상 폭이 매우 크게 되어 배정밀도 연산을 포기할 수 없었던 AMD의 GCN 아키텍처 기반 라데온을 Geforce가 저발열 고성능 특성으로 찍어 누르는 원동력이 되었다.

인공지능

2026-01-04T04:58:44Z

Senouis: /* 인공지능이 가져올 미래 */

'''인공지능'''은 말 그대로 인간과 동등하거나 더 높은 지능을 인공적으로 구현해내는 것을 말한다.

크게 비신경망 AI와 신경망 AI로 나뉜다.

== 비신경망 AI ==

그냥 인간이 순수 노가다로 직접 코드를 짜서 만드는 AI이다. Prolog나 평범한 프로그래밍 언어로 만든 조건문 로직 도배는 오래 전부터 쓰였는데, 비디오게임에서 나오는 인공지능 봇도 사실 이렇게 사람이 노가다로 일일이 인공지능이 할 일을 지시해준 것이다. 베이즈 정리를 활용한 Naive Bayesian AI처럼 고등학교 확률과 통계 교과서에서 쓰는 기법을 활용한 경우도 있다. Support Vector Machine처럼 Hypercude 단위로 데이터를 분류하는 인공지능 제작 기법은 데이터 분류 측면에서 성능이 나름 잘 나오는 편이다. 그러나 XOR 문제 같은 것을 수동으로 조정하거나 사람이 실수로 만든 허점을 사람이 쉽게 분석해서 악용할 수 있고, 투입한 노동력 대비 성능이 인공신경망에 비해 잘 안나와 요즘에는 사장된 편이다.

== 신경망 AI ==

인간의 체내 신경 구조를 모방하여 데이터를 학습시켜서 만드는 AI다. 본질적으로는 선형대수학의 행렬과 벡터 개념을 응용한 연산으로 특정 종류의 데이터들은 특정 결과를 가리키도록 매칭하는 것이다. 최초의 [[퍼셉트론]] 모델을 더 발전시켜 현재 [[딥러닝]]이라 부르는 단계까지 왔다.

가령 인간의 신체적 특징을 (키, 성별, 몸무게, 머리 크기, 어깨 너비, 가슴 크기, 골반 크기, 허리 둘레, 피부색) 같이 [[벡터]] 형태로 만들어서 적절한 벡터 내적 연산과 행렬곱을 사용해 최종적으로는 몇 가지의 [[스칼라]] 값 중 하나가 나오도록 하는 작업을 진행한다. 이 스칼라 값에 '예/아니오' 나 '남자/여자' 등 인간이 이해하기 쉬운 단어 등을 매핑하면 결과 산출 끝이다. 데이터 내에서 벡터 형태로 표현하는 일종의 패턴을 찾아내서 반복적인 학습 작업을 수행하는 식으로 신경망 층(레이어, Layer)들을 변화시켜 AI 데이터 구조(모델)를 만든다. 만약 처음 학습을 시켰을 때 잘못된 결론을 내리면 역전파라는 과정을 통해 선형대수학 연산을 하는 레이어의 계수 역할을 하는 가중치를 바꾸고 다시 학습을 시킨다.

위의 비신경망 AI에 비해서는 결과가 좋지만 일상에서 쓸 수 있는 수준의 AI를 만들려면 그만큼 필요로 하는 데이터도 많고, 무엇보다 실제 사람에 비해 학습하는데 필요한 전기 소모량이 많아서 집에서 하는 간단한 기계학습 연습 따위로는 기대하는 동작 결과가 잘 나오지 않는다. 그래도 일단 엄청난 수의 하드웨어를 때려박으면 괜찮은 결과가 나오기에 대학이나 연구소 등지에서 계속 기계학습이라는 이름 하에 연구하는 중이다.

* CNN(Convolutional Neural Network): 여러 계층의 연산을 합성(Convolution)하여 결과를 도출한다. 딥러닝의 기초적인 구현이 있으며 이미지 처리에 활용된다.
* RNN(Recurrent Neural Network): 입력된 데이터가 중간에 순환하는 과정이 있는 인공신경망으로, 초기 인공신경망 연구 때 자연어 처리에 강점이 있었다.
** Transformer: 2010년대 후반 RNN을 대체하다시피 한 인공신경망 모델로, 주목(Attention) 개념을 추가해 가중치를 선형결합 연산으로 조절하며 문장 내 중요한 키워드를 선정하는 방식으로 추론 정확도를 높인다. 이후 LLM(Large Language Model) 개념으로 발전하면서 AI 시대를 개막했다.
* GAN(Generative Aggressive Network): 두 개 이상 모델을 경쟁적으로 훈련하고 비교하는 작업으로 정확도를 높인다.

== 인공지능이 가져올 미래 ==
미리미리 <s>기계어</s>[[CUDA]]를 예습해서 직접 AI를 조작할 수 있으면 좋겠지만 그건 [[폰 노이만]]급 괴수가 아니면 불가능하고, 보통은 [[C++]]나 [[Python]]를 위해 나온 인공지능 전용 라이브러리<ref>Tensorflow와 Pytorch라는 기능 모음 라이브러리가 있다.</ref>나 [[R 프로그래밍 언어]], [[MATHLAB]] 등의 특수한 고수준 언어를 익혀서 조작한다. 그리고 사실, 현재 과학자들도 신경망 기반 인공지능의 기계어에 해당하는 각 가중치 값이 인공지능 모델 내 레이어(Layer)에서 정확히 어떻게 작동하고 변화하는지 모른다. 그러니까 신경망 AI의 원리에 대한 궁금증은 이들에게 맡기고 일반인은 ChatGPT로 채팅을 치면 된다.

사실상 미래에는 진짜 핵전쟁이 일어나 지구가 통째로 망하지 않는 이상 인공지능이 어떤 형태가 되든 쓰일 수 밖에 없을 것이다. 심지어 요즘은 전쟁도 인공지능으로 수행하려는 시도가 있다. 그래서 학자들은 정부가 직접 AI 산업에 뛰어드는 것에는 부정적인 입장을 보인다. 왜냐하면 무소불위의 권력에 순종하여 사람들을 탄압하고 외부로는 전쟁을 수행하는 AI가 나오면 답이 없기 때문이다. 당장 북한 같은 나라 아닌 나라에 김씨 가문에 충성하는 AI가 나온다? 그럼 북한 인민들은 끝장난다. 실제로 [[중화인민공화국]]이 이쪽 방향을 추구한다는 증거가 나오고 있어서 미국이 신경을 쓰고 중국에 대한 경제적 제재로 RTX 4090 이상의 GPU 수출을 금지했다. 하지만 미국 역시 [[팔란티어 테크놀로지]]<ref>[[페이팔]] 창업자로 유명한 피터 틸이 현재 창업해서 운영 중인 빅데이터/AI 관련 기업이다.</ref> 같은 회사에서 군대 내 AI 활용 연구가 진행되고 미 국방부가 이런 서비스를 이용하면서 내로남불 아니냐는 이야기가 나오고 있다.

미래에는 [[국뽕]] 대신 인공지능뽕이 생겨날 것이다. 인공지능이 두 유 노우 [[알파고]]라는 질문을 던져올 때가 얼마 남지 않았다.<s>사실 지금도 이론 상으로 가능하다</s>

인공지능 학교 선생님이 나올 수도 있다. 교육 관련 시장 상황에 민감한 사교육 업계는 벌써 조금씩 관련 서비스가 나오고 있다. 공교육의 범위까지 적용되는 것은 시간 문제라 모른다고 대답해봤자 인공지능이 압도적인 사고력을 이용해 널 말빨로 강제로 답안에 다가가도록 팰지도 모른다.

역으로 이걸 이용해 숙제를 AI에게 맡기는 행위가 문제가 되고 있다. 2025년에는 무려 [[연세대학교]]에서 인공지능 관련 과목인 자연어 처리 과목에 [https://www.chosun.com/national/national_general/2025/11/09/H4NZNXFVJNHBXCBXXYXZFVWUZI/ AI를 활용한 대규모 부정 행위]가 발각되는 등 AI 관련 치팅 사례가 계속 나오고 있다. 그래서 과제물에 AI 서비스를 사용했는지 여부를 판단하는 AI 서비스도 나오는 상황이다.

그림 인공지능이 나왔으니 작가들은 필요 없다고 악플을 쓰는 악플러들이 지속적으로 출몰할 것이다. 이러한 익명의 악플러들은 남을 비웃는 것만이 목적이기 때문에 논리도 없고 유익한 정보나 휴식을 위한 힐링글을 제공하지도 않는다. 현재도 디시인사이드 특이점이 온다 갤러리 같은 곳에 가끔 이런 [[분탕]]종자들이 보인다. 이때문에 그림 커뮤니티 서비스에서는 [[픽시브]] 같은 곳처럼 AI 활용 드로잉 작품에 별도의 태그 및 분류를 달게 하는 등 사용자층 분리 조치를 취하나 언제나 그렇듯 몰래 우회해서 약관 어겨가며 올리는 문제적 사용자들로 골치를 썩인다.

이렇게 2016년 당시 [https://bigforest.a2hosted.com/w/index.php?title=%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5&direction=next&oldid=53462 큰숲백과의 전신인 오사위키에서 여기 작성되었던 장난성 내용]들은 2024년 현재 이 문서의 변화처럼 '''부분적으로 실현되어 있으며, 엄연히 학계에서 진지하게 논의되는 주제가 되었다.''' '기계의 반란'<ref>강인공지능의 출현 시기가 이미 학계의 기존 예측보다 빨라질 것이라는 걱정이 있다.</ref>이나 AI의 군사적 목적 이용<ref>[[우크라이나-러시아 전쟁]]이나 중국-대만 간 [[양안관계]] 파탄 가능성 등으로 첫 사례가 제시될 가능성이 높다.</ref>, 거짓말 등의 쓰레기 정보를 인공지능이 학습하는 문제<ref>이미 마이크로소프트의 '테이'와 국내에서 개발된 이루다 서비스가 이런 홍역을 치렀다.</ref>, 딥페이크<ref>전화로 하는 금전적 사기/선거 방해용 찌라시 영상 유포를 딥 페이크로 시도하는 사례가 발견된다.</ref> 및 기술적 실업 문제<ref>이미 사무직은 채용 TO가 대폭 줄어들기 시작했으며, 프로그램 설계가 아닌 단순 구현도 [[GitHub]] Copilot에게 보조를 받을 수 있고, ChatGPT로 숙제를 대신 하는 사례가 나왔다.</ref>는 곧 상식이 될 것이다.

[[분류:과학]]

인공지능

2026-01-04T04:57:04Z

Senouis: /* 인공지능이 가져올 미래 */

'''인공지능'''은 말 그대로 인간과 동등하거나 더 높은 지능을 인공적으로 구현해내는 것을 말한다.

크게 비신경망 AI와 신경망 AI로 나뉜다.

== 비신경망 AI ==

그냥 인간이 순수 노가다로 직접 코드를 짜서 만드는 AI이다. Prolog나 평범한 프로그래밍 언어로 만든 조건문 로직 도배는 오래 전부터 쓰였는데, 비디오게임에서 나오는 인공지능 봇도 사실 이렇게 사람이 노가다로 일일이 인공지능이 할 일을 지시해준 것이다. 베이즈 정리를 활용한 Naive Bayesian AI처럼 고등학교 확률과 통계 교과서에서 쓰는 기법을 활용한 경우도 있다. Support Vector Machine처럼 Hypercude 단위로 데이터를 분류하는 인공지능 제작 기법은 데이터 분류 측면에서 성능이 나름 잘 나오는 편이다. 그러나 XOR 문제 같은 것을 수동으로 조정하거나 사람이 실수로 만든 허점을 사람이 쉽게 분석해서 악용할 수 있고, 투입한 노동력 대비 성능이 인공신경망에 비해 잘 안나와 요즘에는 사장된 편이다.

== 신경망 AI ==

인간의 체내 신경 구조를 모방하여 데이터를 학습시켜서 만드는 AI다. 본질적으로는 선형대수학의 행렬과 벡터 개념을 응용한 연산으로 특정 종류의 데이터들은 특정 결과를 가리키도록 매칭하는 것이다. 최초의 [[퍼셉트론]] 모델을 더 발전시켜 현재 [[딥러닝]]이라 부르는 단계까지 왔다.

가령 인간의 신체적 특징을 (키, 성별, 몸무게, 머리 크기, 어깨 너비, 가슴 크기, 골반 크기, 허리 둘레, 피부색) 같이 [[벡터]] 형태로 만들어서 적절한 벡터 내적 연산과 행렬곱을 사용해 최종적으로는 몇 가지의 [[스칼라]] 값 중 하나가 나오도록 하는 작업을 진행한다. 이 스칼라 값에 '예/아니오' 나 '남자/여자' 등 인간이 이해하기 쉬운 단어 등을 매핑하면 결과 산출 끝이다. 데이터 내에서 벡터 형태로 표현하는 일종의 패턴을 찾아내서 반복적인 학습 작업을 수행하는 식으로 신경망 층(레이어, Layer)들을 변화시켜 AI 데이터 구조(모델)를 만든다. 만약 처음 학습을 시켰을 때 잘못된 결론을 내리면 역전파라는 과정을 통해 선형대수학 연산을 하는 레이어의 계수 역할을 하는 가중치를 바꾸고 다시 학습을 시킨다.

위의 비신경망 AI에 비해서는 결과가 좋지만 일상에서 쓸 수 있는 수준의 AI를 만들려면 그만큼 필요로 하는 데이터도 많고, 무엇보다 실제 사람에 비해 학습하는데 필요한 전기 소모량이 많아서 집에서 하는 간단한 기계학습 연습 따위로는 기대하는 동작 결과가 잘 나오지 않는다. 그래도 일단 엄청난 수의 하드웨어를 때려박으면 괜찮은 결과가 나오기에 대학이나 연구소 등지에서 계속 기계학습이라는 이름 하에 연구하는 중이다.

* CNN(Convolutional Neural Network): 여러 계층의 연산을 합성(Convolution)하여 결과를 도출한다. 딥러닝의 기초적인 구현이 있으며 이미지 처리에 활용된다.
* RNN(Recurrent Neural Network): 입력된 데이터가 중간에 순환하는 과정이 있는 인공신경망으로, 초기 인공신경망 연구 때 자연어 처리에 강점이 있었다.
** Transformer: 2010년대 후반 RNN을 대체하다시피 한 인공신경망 모델로, 주목(Attention) 개념을 추가해 가중치를 선형결합 연산으로 조절하며 문장 내 중요한 키워드를 선정하는 방식으로 추론 정확도를 높인다. 이후 LLM(Large Language Model) 개념으로 발전하면서 AI 시대를 개막했다.
* GAN(Generative Aggressive Network): 두 개 이상 모델을 경쟁적으로 훈련하고 비교하는 작업으로 정확도를 높인다.

== 인공지능이 가져올 미래 ==
미리미리 <s>기계어</s>[[NVIDIA|CUDA]]를 예습해서 직접 AI를 조작할 수 있으면 좋겠지만 그건 [[폰 노이만]]급 괴수가 아니면 불가능하고, 보통은 [[C++]]나 [[Python]]를 위해 나온 인공지능 전용 라이브러리<ref>Tensorflow와 Pytorch라는 기능 모음 라이브러리가 있다.</ref>나 [[R 프로그래밍 언어]], [[MATHLAB]] 등의 특수한 고수준 언어를 익혀서 조작한다. 그리고 사실, 현재 과학자들도 신경망 기반 인공지능의 기계어에 해당하는 각 가중치 값이 인공지능 모델 내 레이어(Layer)에서 정확히 어떻게 작동하고 변화하는지 모른다. 그러니까 신경망 AI의 원리에 대한 궁금증은 이들에게 맡기고 일반인은 ChatGPT로 채팅을 치면 된다.

사실상 미래에는 진짜 핵전쟁이 일어나 지구가 통째로 망하지 않는 이상 인공지능이 어떤 형태가 되든 쓰일 수 밖에 없을 것이다. 심지어 요즘은 전쟁도 인공지능으로 수행하려는 시도가 있다. 그래서 학자들은 정부가 직접 AI 산업에 뛰어드는 것에는 부정적인 입장을 보인다. 왜냐하면 무소불위의 권력에 순종하여 사람들을 탄압하고 외부로는 전쟁을 수행하는 AI가 나오면 답이 없기 때문이다. 당장 북한 같은 나라 아닌 나라에 김씨 가문에 충성하는 AI가 나온다? 그럼 북한 인민들은 끝장난다. 실제로 [[중화인민공화국]]이 이쪽 방향을 추구한다는 증거가 나오고 있어서 미국이 신경을 쓰고 중국에 대한 경제적 제재로 RTX 4090 이상의 GPU 수출을 금지했다. 하지만 미국 역시 [[팔란티어 테크놀로지]]<ref>[[페이팔]] 창업자로 유명한 피터 틸이 현재 창업해서 운영 중인 빅데이터/AI 관련 기업이다.</ref> 같은 회사에서 군대 내 AI 활용 연구가 진행되고 미 국방부가 이런 서비스를 이용하면서 내로남불 아니냐는 이야기가 나오고 있다.

미래에는 [[국뽕]] 대신 인공지능뽕이 생겨날 것이다. 인공지능이 두 유 노우 [[알파고]]라는 질문을 던져올 때가 얼마 남지 않았다.<s>사실 지금도 이론 상으로 가능하다</s>

인공지능 학교 선생님이 나올 수도 있다. 교육 관련 시장 상황에 민감한 사교육 업계는 벌써 조금씩 관련 서비스가 나오고 있다. 공교육의 범위까지 적용되는 것은 시간 문제라 모른다고 대답해봤자 인공지능이 압도적인 사고력을 이용해 널 말빨로 강제로 답안에 다가가도록 팰지도 모른다.

역으로 이걸 이용해 숙제를 AI에게 맡기는 행위가 문제가 되고 있다. 2025년에는 무려 [[연세대학교]]에서 인공지능 관련 과목인 자연어 처리 과목에 [https://www.chosun.com/national/national_general/2025/11/09/H4NZNXFVJNHBXCBXXYXZFVWUZI/ AI를 활용한 대규모 부정 행위]가 발각되는 등 AI 관련 치팅 사례가 계속 나오고 있다. 그래서 과제물에 AI 서비스를 사용했는지 여부를 판단하는 AI 서비스도 나오는 상황이다.

그림 인공지능이 나왔으니 작가들은 필요 없다고 악플을 쓰는 악플러들이 지속적으로 출몰할 것이다. 이러한 익명의 악플러들은 남을 비웃는 것만이 목적이기 때문에 논리도 없고 유익한 정보나 휴식을 위한 힐링글을 제공하지도 않는다. 현재도 디시인사이드 특이점이 온다 갤러리 같은 곳에 가끔 이런 [[분탕]]종자들이 보인다. 이때문에 그림 커뮤니티 서비스에서는 [[픽시브]] 같은 곳처럼 AI 활용 드로잉 작품에 별도의 태그 및 분류를 달게 하는 등 사용자층 분리 조치를 취하나 언제나 그렇듯 몰래 우회해서 약관 어겨가며 올리는 문제적 사용자들로 골치를 썩인다.

이렇게 2016년 당시 [https://bigforest.a2hosted.com/w/index.php?title=%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5&direction=next&oldid=53462 큰숲백과의 전신인 오사위키에서 여기 작성되었던 장난성 내용]들은 2024년 현재 이 문서의 변화처럼 '''부분적으로 실현되어 있으며, 엄연히 학계에서 진지하게 논의되는 주제가 되었다.''' '기계의 반란'<ref>강인공지능의 출현 시기가 이미 학계의 기존 예측보다 빨라질 것이라는 걱정이 있다.</ref>이나 AI의 군사적 목적 이용<ref>[[우크라이나-러시아 전쟁]]이나 중국-대만 간 [[양안관계]] 파탄 가능성 등으로 첫 사례가 제시될 가능성이 높다.</ref>, 거짓말 등의 쓰레기 정보를 인공지능이 학습하는 문제<ref>이미 마이크로소프트의 '테이'와 국내에서 개발된 이루다 서비스가 이런 홍역을 치렀다.</ref>, 딥페이크<ref>전화로 하는 금전적 사기/선거 방해용 찌라시 영상 유포를 딥 페이크로 시도하는 사례가 발견된다.</ref> 및 기술적 실업 문제<ref>이미 사무직은 채용 TO가 대폭 줄어들기 시작했으며, 프로그램 설계가 아닌 단순 구현도 [[GitHub]] Copilot에게 보조를 받을 수 있고, ChatGPT로 숙제를 대신 하는 사례가 나왔다.</ref>는 곧 상식이 될 것이다.

[[분류:과학]]

인공지능

2026-01-04T04:52:22Z

Senouis: /* 인공지능이 가져올 미래 */내용 다듬음

'''인공지능'''은 말 그대로 인간과 동등하거나 더 높은 지능을 인공적으로 구현해내는 것을 말한다.

크게 비신경망 AI와 신경망 AI로 나뉜다.

== 비신경망 AI ==

그냥 인간이 순수 노가다로 직접 코드를 짜서 만드는 AI이다. Prolog나 평범한 프로그래밍 언어로 만든 조건문 로직 도배는 오래 전부터 쓰였는데, 비디오게임에서 나오는 인공지능 봇도 사실 이렇게 사람이 노가다로 일일이 인공지능이 할 일을 지시해준 것이다. 베이즈 정리를 활용한 Naive Bayesian AI처럼 고등학교 확률과 통계 교과서에서 쓰는 기법을 활용한 경우도 있다. Support Vector Machine처럼 Hypercude 단위로 데이터를 분류하는 인공지능 제작 기법은 데이터 분류 측면에서 성능이 나름 잘 나오는 편이다. 그러나 XOR 문제 같은 것을 수동으로 조정하거나 사람이 실수로 만든 허점을 사람이 쉽게 분석해서 악용할 수 있고, 투입한 노동력 대비 성능이 인공신경망에 비해 잘 안나와 요즘에는 사장된 편이다.

== 신경망 AI ==

인간의 체내 신경 구조를 모방하여 데이터를 학습시켜서 만드는 AI다. 본질적으로는 선형대수학의 행렬과 벡터 개념을 응용한 연산으로 특정 종류의 데이터들은 특정 결과를 가리키도록 매칭하는 것이다. 최초의 [[퍼셉트론]] 모델을 더 발전시켜 현재 [[딥러닝]]이라 부르는 단계까지 왔다.

가령 인간의 신체적 특징을 (키, 성별, 몸무게, 머리 크기, 어깨 너비, 가슴 크기, 골반 크기, 허리 둘레, 피부색) 같이 [[벡터]] 형태로 만들어서 적절한 벡터 내적 연산과 행렬곱을 사용해 최종적으로는 몇 가지의 [[스칼라]] 값 중 하나가 나오도록 하는 작업을 진행한다. 이 스칼라 값에 '예/아니오' 나 '남자/여자' 등 인간이 이해하기 쉬운 단어 등을 매핑하면 결과 산출 끝이다. 데이터 내에서 벡터 형태로 표현하는 일종의 패턴을 찾아내서 반복적인 학습 작업을 수행하는 식으로 신경망 층(레이어, Layer)들을 변화시켜 AI 데이터 구조(모델)를 만든다. 만약 처음 학습을 시켰을 때 잘못된 결론을 내리면 역전파라는 과정을 통해 선형대수학 연산을 하는 레이어의 계수 역할을 하는 가중치를 바꾸고 다시 학습을 시킨다.

위의 비신경망 AI에 비해서는 결과가 좋지만 일상에서 쓸 수 있는 수준의 AI를 만들려면 그만큼 필요로 하는 데이터도 많고, 무엇보다 실제 사람에 비해 학습하는데 필요한 전기 소모량이 많아서 집에서 하는 간단한 기계학습 연습 따위로는 기대하는 동작 결과가 잘 나오지 않는다. 그래도 일단 엄청난 수의 하드웨어를 때려박으면 괜찮은 결과가 나오기에 대학이나 연구소 등지에서 계속 기계학습이라는 이름 하에 연구하는 중이다.

* CNN(Convolutional Neural Network): 여러 계층의 연산을 합성(Convolution)하여 결과를 도출한다. 딥러닝의 기초적인 구현이 있으며 이미지 처리에 활용된다.
* RNN(Recurrent Neural Network): 입력된 데이터가 중간에 순환하는 과정이 있는 인공신경망으로, 초기 인공신경망 연구 때 자연어 처리에 강점이 있었다.
** Transformer: 2010년대 후반 RNN을 대체하다시피 한 인공신경망 모델로, 주목(Attention) 개념을 추가해 가중치를 선형결합 연산으로 조절하며 문장 내 중요한 키워드를 선정하는 방식으로 추론 정확도를 높인다. 이후 LLM(Large Language Model) 개념으로 발전하면서 AI 시대를 개막했다.
* GAN(Generative Aggressive Network): 두 개 이상 모델을 경쟁적으로 훈련하고 비교하는 작업으로 정확도를 높인다.

== 인공지능이 가져올 미래 ==
미리미리 <s>기계어</s>[[NVIDIA|CUDA]]를 예습해서 직접 AI를 조작할 수 있으면 좋겠지만 그건 [[폰 노이만]]급 괴수가 아니면 불가능하고, 보통은 [[C++]]나 [[Python]]를 위해 나온 인공지능 전용 라이브러리<ref>Tensorflow와 Pytorch라는 기능 모음 라이브러리가 있다.</ref>나 [[R 프로그래밍 언어]], [[MATHLAB]] 등의 특수한 고수준 언어를 익혀서 조작한다. 그리고 사실, 현재 과학자들도 신경망 기반 인공지능의 기계어에 해당하는 각 가중치 값이 인공지능 모델 내 레이어(Layer)에서 정확히 어떻게 작동하고 변화하는지 모른다. 그러니까 신경망 AI의 원리에 대한 궁금증은 이들에게 맡기고 일반인은 ChatGPT로 채팅을 치면 된다.

사실상 미래에는 진짜 핵전쟁이 일어나 지구가 통째로 망하지 않는 이상 인공지능이 어떤 형태가 되든 쓰일 수 밖에 없을 것이다. 심지어 요즘은 전쟁도 인공지능으로 수행하려는 시도가 있다. 그래서 학자들은 정부가 직접 AI 산업에 뛰어드는 것에는 부정적인 입장을 보인다. 왜냐하면 무소불위의 권력에 순종하여 사람들을 탄압하고 외부로는 전쟁을 수행하는 AI가 나오면 답이 없기 때문이다. 당장 북한 같은 나라 아닌 나라에 김씨 가문에 충성하는 AI가 나온다? 그럼 북한 인민들은 끝장난다. 실제로 [[중화인민공화국]]이 이쪽 방향을 추구한다는 증거가 나오고 있어서 미국이 신경을 쓰고 중국에 대한 경제적 제재로 RTX 4090 이상의 GPU 수출을 금지했다. 하지만 미국 역시 [[팔란티어 테크놀로지]]<ref>[[페이팔]] 창업자로 유명한 피터 틸이 현재 창업해서 운영 중인 빅데이터/AI 관련 기업이다.</ref> 같은 회사에서 군대 내 AI 활용 연구가 진행되고 미 국방부가 이런 서비스를 이용하면서 내로남불 아니냐는 이야기가 나오고 있다.

미래에는 [[국뽕]] 대신 인공지능뽕이 생겨날 것이다. 인공지능이 두 유 노우 [[알파고]]라는 질문을 던져올 때가 얼마 남지 않았다.<s>사실 지금도 이론 상으로 가능하다</s>

인공지능 학교 선생님이 나올 수도 있다. 교육 관련 시장 상황에 민감한 사교육 업계는 벌써 조금씩 관련 서비스가 나오고 있다. 공교육의 범위까지 적용되는 것은 시간 문제라 모른다고 대답해봤자 인공지능이 압도적인 사고력을 이용해 널 말빨로 강제로 답안에 다가가도록 팰지도 모른다.

역으로 이걸 이용해 숙제를 AI에게 맡기는 행위가 문제가 되고 있다. 2025년에는 무려 [[연세대학교]]에서 인공지능 관련 과목인 자연어 처리 과목에 [https://www.chosun.com/national/national_general/2025/11/09/H4NZNXFVJNHBXCBXXYXZFVWUZI/ AI를 활용한 대규모 부정 행위]가 발각되는 등 AI 관련 치팅 사례가 계속 나오고 있다. 그래서 과제물에 AI 서비스를 사용했는지 여부를 판단하는 AI 서비스도 나오는 상황이다.

그림 인공지능이 나왔으니 작가들은 필요 없다고 악플을 쓰는 악플러들이 지속적으로 출몰할 것이다. 이러한 익명의 악플러들은 남을 비웃는 것만이 목적이기 때문에 논리도 없고 유익한 정보나 휴식을 위한 힐링글을 제공하지도 않는다. 현재도 디시인사이드 특이점이 온다 갤러리 같은 곳에 가끔 이런 [[분탕]]종자들이 보인다.

이렇게 2016년 당시 [https://bigforest.a2hosted.com/w/index.php?title=%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5&direction=next&oldid=53462 큰숲백과의 전신인 오사위키에서 여기 작성되었던 장난성 내용]들은 2024년 현재 이 문서의 변화처럼 '''부분적으로 실현되어 있으며, 엄연히 학계에서 진지하게 논의되는 주제가 되었다.''' '기계의 반란'<ref>강인공지능의 출현 시기가 이미 학계의 기존 예측보다 빨라질 것이라는 걱정이 있다.</ref>이나 AI의 군사적 목적 이용<ref>[[우크라이나-러시아 전쟁]]이나 중국-대만 간 [[양안관계]] 파탄 가능성 등으로 첫 사례가 제시될 가능성이 높다.</ref>, 거짓말 등의 쓰레기 정보를 인공지능이 학습하는 문제<ref>이미 마이크로소프트의 '테이'와 국내에서 개발된 이루다 서비스가 이런 홍역을 치렀다.</ref>, 딥페이크<ref>전화로 하는 금전적 사기/선거 방해용 찌라시 영상 유포를 딥 페이크로 시도하는 사례가 발견된다.</ref> 및 기술적 실업 문제<ref>이미 사무직은 채용 TO가 대폭 줄어들기 시작했으며, 프로그램 설계가 아닌 단순 구현도 [[GitHub]] Copilot에게 보조를 받을 수 있고, ChatGPT로 숙제를 대신 하는 사례가 나왔다.</ref>는 곧 상식이 될 것이다.

[[분류:과학]]

인공지능

2026-01-04T04:39:51Z

Senouis: /* 신경망 AI */

'''인공지능'''은 말 그대로 인간과 동등하거나 더 높은 지능을 인공적으로 구현해내는 것을 말한다.

크게 비신경망 AI와 신경망 AI로 나뉜다.

== 비신경망 AI ==

그냥 인간이 순수 노가다로 직접 코드를 짜서 만드는 AI이다. Prolog나 평범한 프로그래밍 언어로 만든 조건문 로직 도배는 오래 전부터 쓰였는데, 비디오게임에서 나오는 인공지능 봇도 사실 이렇게 사람이 노가다로 일일이 인공지능이 할 일을 지시해준 것이다. 베이즈 정리를 활용한 Naive Bayesian AI처럼 고등학교 확률과 통계 교과서에서 쓰는 기법을 활용한 경우도 있다. Support Vector Machine처럼 Hypercude 단위로 데이터를 분류하는 인공지능 제작 기법은 데이터 분류 측면에서 성능이 나름 잘 나오는 편이다. 그러나 XOR 문제 같은 것을 수동으로 조정하거나 사람이 실수로 만든 허점을 사람이 쉽게 분석해서 악용할 수 있고, 투입한 노동력 대비 성능이 인공신경망에 비해 잘 안나와 요즘에는 사장된 편이다.

== 신경망 AI ==

인간의 체내 신경 구조를 모방하여 데이터를 학습시켜서 만드는 AI다. 본질적으로는 선형대수학의 행렬과 벡터 개념을 응용한 연산으로 특정 종류의 데이터들은 특정 결과를 가리키도록 매칭하는 것이다. 최초의 [[퍼셉트론]] 모델을 더 발전시켜 현재 [[딥러닝]]이라 부르는 단계까지 왔다.

가령 인간의 신체적 특징을 (키, 성별, 몸무게, 머리 크기, 어깨 너비, 가슴 크기, 골반 크기, 허리 둘레, 피부색) 같이 [[벡터]] 형태로 만들어서 적절한 벡터 내적 연산과 행렬곱을 사용해 최종적으로는 몇 가지의 [[스칼라]] 값 중 하나가 나오도록 하는 작업을 진행한다. 이 스칼라 값에 '예/아니오' 나 '남자/여자' 등 인간이 이해하기 쉬운 단어 등을 매핑하면 결과 산출 끝이다. 데이터 내에서 벡터 형태로 표현하는 일종의 패턴을 찾아내서 반복적인 학습 작업을 수행하는 식으로 신경망 층(레이어, Layer)들을 변화시켜 AI 데이터 구조(모델)를 만든다. 만약 처음 학습을 시켰을 때 잘못된 결론을 내리면 역전파라는 과정을 통해 선형대수학 연산을 하는 레이어의 계수 역할을 하는 가중치를 바꾸고 다시 학습을 시킨다.

위의 비신경망 AI에 비해서는 결과가 좋지만 일상에서 쓸 수 있는 수준의 AI를 만들려면 그만큼 필요로 하는 데이터도 많고, 무엇보다 실제 사람에 비해 학습하는데 필요한 전기 소모량이 많아서 집에서 하는 간단한 기계학습 연습 따위로는 기대하는 동작 결과가 잘 나오지 않는다. 그래도 일단 엄청난 수의 하드웨어를 때려박으면 괜찮은 결과가 나오기에 대학이나 연구소 등지에서 계속 기계학습이라는 이름 하에 연구하는 중이다.

* CNN(Convolutional Neural Network): 여러 계층의 연산을 합성(Convolution)하여 결과를 도출한다. 딥러닝의 기초적인 구현이 있으며 이미지 처리에 활용된다.
* RNN(Recurrent Neural Network): 입력된 데이터가 중간에 순환하는 과정이 있는 인공신경망으로, 초기 인공신경망 연구 때 자연어 처리에 강점이 있었다.
** Transformer: 2010년대 후반 RNN을 대체하다시피 한 인공신경망 모델로, 주목(Attention) 개념을 추가해 가중치를 선형결합 연산으로 조절하며 문장 내 중요한 키워드를 선정하는 방식으로 추론 정확도를 높인다. 이후 LLM(Large Language Model) 개념으로 발전하면서 AI 시대를 개막했다.
* GAN(Generative Aggressive Network): 두 개 이상 모델을 경쟁적으로 훈련하고 비교하는 작업으로 정확도를 높인다.

== 인공지능이 가져올 미래 ==
미리미리 <s>기계어</s>[[NVIDIA|CUDA]]를 예습해서 직접 AI를 조작할 수 있으면 좋겠지만 그건 [[폰 노이만]]급 괴수가 아니면 불가능하고, 보통은 [[C++]]나 [[Python]]를 위해 나온 인공지능 전용 라이브러리<ref>Tensorflow와 Pytorch라는 기능 모음 라이브러리가 있다.</ref>나 [[R 프로그래밍 언어]], [[MATHLAB]] 등의 특수한 고수준 언어를 익혀서 조작한다. 그리고 사실, 현재 과학자들도 신경망 기반 인공지능의 기계어에 해당하는 각 가중치 값이 인공지능 모델 내 레이어(Layer)에서 정확히 어떻게 작동하고 변화하는지 모른다. 그러니까 신경망 AI의 원리에 대한 궁금증은 이들에게 맡기고 일반인은 ChatGPT로 채팅을 치면 된다.

사실상 미래에는 진짜 핵전쟁이 일어나 지구가 통째로 망하지 않는 이상 인공지능이 어떤 형태가 되든 쓰일 수 밖에 없을 것이다. 심지어 요즘은 전쟁도 인공지능으로 수행하려는 시도가 있다. 그래서 학자들은 정부가 직접 AI 산업에 뛰어드는 것에는 부정적인 입장을 보인다. 왜냐하면 무소불위의 권력에 순종하여 사람들을 탄압하고 외부로는 전쟁을 수행하는 AI가 나오면 답이 없기 때문이다. 당장 북한 같은 나라 아닌 나라에 김씨 가문에 충성하는 AI가 나온다? 그럼 북한 인민들은 끝장난다. 실제로 [[중화인민공화국]]이 이쪽 방향을 추구한다는 증거가 나오고 있어서 미국이 신경을 쓰고 중국에 대한 경제적 제재로 RTX 4090 이상의 GPU 수출을 금지했다.

미래에는 [[국뽕]] 대신 인공지능뽕이 생겨날 것이다. 인공지능이 두 유 노우 [[알파고]]라는 질문을 던져올 때가 얼마 남지 않았다.<s>사실 지금도 이론 상으로 가능하다</s>

인공지능 학교 선생님이 나올 수도 있다. 만일 그렇게 된다면 절대 모른다고 대답하지 말자. 인공지능이 압도적인 사고력을 이용해 널 말빨로 팰지도 모른다. 역으로 이걸 이용해 숙제를 AI에게 맡기는 행위가 문제가 되고 있다. 과제물에 AI 서비스를 사용했는지 여부를 판단하는 AI 서비스도 개발하고 있다.

그림 인공지능이 나왔으니 작가들은 필요 없다고 악플을 쓰는 악플러들이 지속적으로 출몰할 것이다. 이러한 익명의 악플러들은 남을 비웃는 것만이 목적이기 때문에 논리도 없고 유익한 정보나 휴식을 위한 힐링글을 제공하지도 않는다. 현재도 디시인사이드 특이점이 온다 갤러리 같은 곳에 가끔 이런 [[분탕]]종자들이 보인다.

이렇게 2016년 당시 [https://bigforest.a2hosted.com/w/index.php?title=%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5&direction=next&oldid=53462 큰숲백과의 전신인 오사위키에서 여기 작성되었던 장난성 내용]들은 2024년 현재 이 문서의 변화처럼 '''부분적으로 실현되어 있으며, 엄연히 학계에서 진지하게 논의되는 주제가 되었다.''' '기계의 반란'<ref>강인공지능의 출현 시기가 이미 학계의 기존 예측보다 빨라질 것이라는 걱정이 있다.</ref>이나 AI의 군사적 목적 이용<ref>[[우크라이나-러시아 전쟁]]이나 중국-대만 간 [[양안관계]] 파탄 가능성 등으로 첫 사례가 제시될 가능성이 높다.</ref>, 거짓말 등의 쓰레기 정보를 인공지능이 학습하는 문제<ref>이미 마이크로소프트의 '테이'와 국내에서 개발된 이루다 서비스가 이런 홍역을 치렀다.</ref>, 딥페이크<ref>전화로 하는 금전적 사기/선거 방해용 찌라시 영상 유포를 딥 페이크로 시도하는 사례가 발견된다.</ref> 및 기술적 실업 문제<ref>이미 사무직은 채용 TO가 대폭 줄어들기 시작했으며, 프로그램 설계가 아닌 단순 구현도 [[GitHub]] Copilot에게 보조를 받을 수 있고, ChatGPT로 숙제를 대신 하는 사례가 나왔다.</ref>는 곧 상식이 될 것이다.

[[분류:과학]]

인공지능

2026-01-04T04:35:32Z

Senouis: /* 신경망 AI */

'''인공지능'''은 말 그대로 인간과 동등하거나 더 높은 지능을 인공적으로 구현해내는 것을 말한다.

크게 비신경망 AI와 신경망 AI로 나뉜다.

== 비신경망 AI ==

그냥 인간이 순수 노가다로 직접 코드를 짜서 만드는 AI이다. Prolog나 평범한 프로그래밍 언어로 만든 조건문 로직 도배는 오래 전부터 쓰였는데, 비디오게임에서 나오는 인공지능 봇도 사실 이렇게 사람이 노가다로 일일이 인공지능이 할 일을 지시해준 것이다. 베이즈 정리를 활용한 Naive Bayesian AI처럼 고등학교 확률과 통계 교과서에서 쓰는 기법을 활용한 경우도 있다. Support Vector Machine처럼 Hypercude 단위로 데이터를 분류하는 인공지능 제작 기법은 데이터 분류 측면에서 성능이 나름 잘 나오는 편이다. 그러나 XOR 문제 같은 것을 수동으로 조정하거나 사람이 실수로 만든 허점을 사람이 쉽게 분석해서 악용할 수 있고, 투입한 노동력 대비 성능이 인공신경망에 비해 잘 안나와 요즘에는 사장된 편이다.

== 신경망 AI ==

인간의 체내 신경 구조를 모방하여 데이터를 학습시켜서 만드는 AI다. 본질적으로는 선형대수학의 행렬과 벡터 개념을 응용한 연산으로 특정 종류의 데이터들은 특정 결과를 가리키도록 매칭하는 것이다. 최초의 [[퍼셉트론]] 모델을 더 발전시켜 현재 [[딥러닝]]이라 부르는 단계까지 왔다.

가령 인간의 신체적 특징을 (키, 성별, 몸무게, 머리 크기, 어깨 너비, 가슴 크기, 골반 크기, 허리 둘레, 피부색) 같이 벡터 형태로 만들어서 적절한 벡터 내적 연산과 행렬곱을 사용해 최종적으로는 몇 가지의 스칼라 값 중 하나가 나오도록 하는 작업을 진행한다. 마치 학생들이 학교에서 지식을 배우고 집에서 부모들에게 가르침을 받는 것처럼 데이터 내에서 벡터화된 패턴을 찾아내서 반복적인 학습 작업을 수행하는 식으로 신경망 층(레이어, Layer)들을 변화시켜 AI 데이터 구조를 만든다. 만약 처음 학습을 시켰을 때 잘못된 결론을 내리면 역전파로 선형대수학 연산을 하는 레이어의 계수 역할을 하는 가중치를 바꾸고 다시 학습을 시킨다.

위의 비신경망 AI에 비해서는 결과가 좋지만 일상에서 쓸 수 있는 수준의 AI를 만들려면 그만큼 필요로 하는 데이터도 많고, 무엇보다 실제 사람에 비해 학습하는데 필요한 전기 소모량이 많아서 집에서 하는 간단한 기계학습 연습 따위로는 기대하는 동작 결과가 잘 나오지 않는다. 그래도 일단 엄청난 수의 하드웨어를 때려박으면 괜찮은 결과가 나오기에 대학이나 연구소 등지에서 계속 기계학습이라는 이름 하에 연구하는 중이다.

* CNN(Convolutional Neural Network): 여러 계층의 연산을 합성(Convolution)하여 결과를 도출한다. 딥러닝의 기초적인 구현이 있으며 이미지 처리에 활용된다.
* RNN(Recurrent Neural Network): 입력된 데이터가 중간에 순환하는 과정이 있는 인공신경망으로, 초기 인공신경망 연구 때 자연어 처리에 강점이 있었다.
** Transformer: 2010년대 후반 RNN을 대체하다시피 한 인공신경망 모델로, 주목(Attention) 개념을 추가해 가중치를 선형결합 연산으로 조절하며 문장 내 중요한 키워드를 선정하는 방식으로 추론 정확도를 높인다. 이후 LLM(Large Language Model) 개념으로 발전하면서 AI 시대를 개막했다.
* GAN(Generative Aggressive Network): 두 개 이상 모델을 경쟁적으로 훈련하고 비교하는 작업으로 정확도를 높인다.

== 인공지능이 가져올 미래 ==
미리미리 <s>기계어</s>[[NVIDIA|CUDA]]를 예습해서 직접 AI를 조작할 수 있으면 좋겠지만 그건 [[폰 노이만]]급 괴수가 아니면 불가능하고, 보통은 [[C++]]나 [[Python]]를 위해 나온 인공지능 전용 라이브러리<ref>Tensorflow와 Pytorch라는 기능 모음 라이브러리가 있다.</ref>나 [[R 프로그래밍 언어]], [[MATHLAB]] 등의 특수한 고수준 언어를 익혀서 조작한다. 그리고 사실, 현재 과학자들도 신경망 기반 인공지능의 기계어에 해당하는 각 가중치 값이 인공지능 모델 내 레이어(Layer)에서 정확히 어떻게 작동하고 변화하는지 모른다. 그러니까 신경망 AI의 원리에 대한 궁금증은 이들에게 맡기고 일반인은 ChatGPT로 채팅을 치면 된다.

사실상 미래에는 진짜 핵전쟁이 일어나 지구가 통째로 망하지 않는 이상 인공지능이 어떤 형태가 되든 쓰일 수 밖에 없을 것이다. 심지어 요즘은 전쟁도 인공지능으로 수행하려는 시도가 있다. 그래서 학자들은 정부가 직접 AI 산업에 뛰어드는 것에는 부정적인 입장을 보인다. 왜냐하면 무소불위의 권력에 순종하여 사람들을 탄압하고 외부로는 전쟁을 수행하는 AI가 나오면 답이 없기 때문이다. 당장 북한 같은 나라 아닌 나라에 김씨 가문에 충성하는 AI가 나온다? 그럼 북한 인민들은 끝장난다. 실제로 [[중화인민공화국]]이 이쪽 방향을 추구한다는 증거가 나오고 있어서 미국이 신경을 쓰고 중국에 대한 경제적 제재로 RTX 4090 이상의 GPU 수출을 금지했다.

미래에는 [[국뽕]] 대신 인공지능뽕이 생겨날 것이다. 인공지능이 두 유 노우 [[알파고]]라는 질문을 던져올 때가 얼마 남지 않았다.<s>사실 지금도 이론 상으로 가능하다</s>

인공지능 학교 선생님이 나올 수도 있다. 만일 그렇게 된다면 절대 모른다고 대답하지 말자. 인공지능이 압도적인 사고력을 이용해 널 말빨로 팰지도 모른다. 역으로 이걸 이용해 숙제를 AI에게 맡기는 행위가 문제가 되고 있다. 과제물에 AI 서비스를 사용했는지 여부를 판단하는 AI 서비스도 개발하고 있다.

그림 인공지능이 나왔으니 작가들은 필요 없다고 악플을 쓰는 악플러들이 지속적으로 출몰할 것이다. 이러한 익명의 악플러들은 남을 비웃는 것만이 목적이기 때문에 논리도 없고 유익한 정보나 휴식을 위한 힐링글을 제공하지도 않는다. 현재도 디시인사이드 특이점이 온다 갤러리 같은 곳에 가끔 이런 [[분탕]]종자들이 보인다.

이렇게 2016년 당시 [https://bigforest.a2hosted.com/w/index.php?title=%EC%9D%B8%EA%B3%B5%EC%A7%80%EB%8A%A5&direction=next&oldid=53462 큰숲백과의 전신인 오사위키에서 여기 작성되었던 장난성 내용]들은 2024년 현재 이 문서의 변화처럼 '''부분적으로 실현되어 있으며, 엄연히 학계에서 진지하게 논의되는 주제가 되었다.''' '기계의 반란'<ref>강인공지능의 출현 시기가 이미 학계의 기존 예측보다 빨라질 것이라는 걱정이 있다.</ref>이나 AI의 군사적 목적 이용<ref>[[우크라이나-러시아 전쟁]]이나 중국-대만 간 [[양안관계]] 파탄 가능성 등으로 첫 사례가 제시될 가능성이 높다.</ref>, 거짓말 등의 쓰레기 정보를 인공지능이 학습하는 문제<ref>이미 마이크로소프트의 '테이'와 국내에서 개발된 이루다 서비스가 이런 홍역을 치렀다.</ref>, 딥페이크<ref>전화로 하는 금전적 사기/선거 방해용 찌라시 영상 유포를 딥 페이크로 시도하는 사례가 발견된다.</ref> 및 기술적 실업 문제<ref>이미 사무직은 채용 TO가 대폭 줄어들기 시작했으며, 프로그램 설계가 아닌 단순 구현도 [[GitHub]] Copilot에게 보조를 받을 수 있고, ChatGPT로 숙제를 대신 하는 사례가 나왔다.</ref>는 곧 상식이 될 것이다.

[[분류:과학]]

VLIW

2026-01-04T04:31:00Z

Senouis: /* 현황 */

[[파일:Architettura Itanium 2.png|300px|thumb|VLIW ISA를 사용하는 대표 CPU인 아이태니엄 2의 내부 구조]]

'''VLIW'''(Very Long Instruction Word)는 단일한 명령어 내에 여러 개의 Opcode를 묶는 CPU 명령어 처리 기법(Instruction Set Architecture의 설계 방식)이다.

== 역사 ==
일반적으로 CPU, GPU 같은 프로세서 칩에서 하나의 명령어를 연속적으로 빠르게 처리하는 것보다 적당한 수준의 처리 속도에서 최대한 동시에 많은 명령어를 병렬적으로 처리하는 것이 더 빠르다. 그래서 앨런 튜링을 시작으로 많은 초기 컴퓨터공학자들은 하드웨어를 통해 병렬 처리가 가능한 수평적 프로그래밍을 하는 방법을 강구하고 있었다. 1980년 들어 뉴욕대 출신으로 예일대 조교수로 재임 중이던 조셉 피셔는 여기서 프로세서에 직접 명령어를 넣어줄 때부터 동시에 처리할 경우(Microcode-compaction) 훨씬 더 빠른 프로세서를 만들 수 있을 것이라고 생각하여 그의 [https://ieeexplore.ieee.org/document/1675827 박사 후 논문]에 VLIW를 처음으로 구체화시켰다. 이후 여기서 고정된 파이프라이닝의 변경이 어렵다는 단점을 완화하기 위해 [[인텔]]에서 명령어 종류 간의 파이프라이닝을 분리하는 EPIC(Explicitly Parallel Instruction Computing)을 개발하여 [[인텔 아이태니엄 시리즈]]에 적용하였고 이후 러시아의 옐브루스 프로세서 등에도 도입되면서 현대 VLIW 아키텍처는 전부 EPIC 구조를 가지고 있다.

== 특징 ==
* 위에서 서술한 대로 실제 구현된 VLIW 디코딩을 하는 프로세서 칩은 명령어가 제대로 들어온다는 전제 하에 구조적 측면에서 IPC(Instruction Per Cycle)가 폭등하여 한번에 처리 가능한 명령어 처리량이 매우 많다.
* 명령어의 앞뒤 순서(종속성)를 미리 소프트웨어적으로 재배치한 채로 디코딩을 하기 때문에 명령어 종속성을 제거하기 위해 추가적인 하드웨어를 배치할 필요가 없고 따라서 [[파이프라인 (CPU)|파이프라인]]의 단계 수를 획기적으로 줄일 수 있다. 오른쪽 위의 아이태니엄의 파이프라인 단계를 세어 보면 가장 단순한 CPU 구조인 Fetch-Decode-Execute-Write Back 4단계 파이프라인에 상당히 가깝다는 것을 알 수 있다. 즉 이상적 CPU 구조에 가장 가까운 아키텍처를 가질 수 있다.
* 종속성 제거를 하드웨어가 아닌 소프트웨어(보통 프로그램을 기계어로 바꿔주는 [[컴파일러]])가 담당하기 때문에 넣어 줄 소프트웨어 명령어를 기계어로 번역하는 '''컴파일러의 제작 난이도가 수직 상승'''한다. VLIW의 최대 단점으로 [[아이태니엄]]이 실패한 이유가 바로 이것이다. 이에 더해 그 컴파일러로 컴파일한 [[운영체제]]에서 신경 써야 하는 부분이 늘어난다.
* 명령어가 잘못 들어올 수 있는 경우 파이프라인을 통째로 비우거나 CPU의 작업을 올스톱시켜야 한다. 대표적인 경우가 캐시 미스가 발생하여 한 명령어가 메모리에서 결과를 기다리는 동안 동시에 들어온 다른 명령어가 같이 기다리는 상황, 그리고 입력에 따라 조건문 같은 분기 명령어가 다르게 작동하는 상황이 있다. 이건 [[CISC]]나 [[RISC]]에도 있는 단점이지만 VLIW 아키텍처에서는 동시에 들어온 다른 명령어도 다같이 운명 공동체가 되기 때문에 훨씬 치명적이다. 이 때문에 분기 예측을 도입하여도 예측 실패 시의 페널티가 너무 커서 분기 예측 같은 성능 올리는 기법을 도입하기 너무 어렵다.
* Read-After-Write 명령어 종속성 앞에서는 VLIW 아키텍처라도 어쩔 수 없이 직렬적인 명령어 처리를 하게 되는데, 이러면 VLIW의 장점이 가려진다. 트랜스메타 크루소의 경우 전체 명령어 중 60~70% 정도만 실행 유닛을 작동시키는 유효한 명령어였고 나머지는 NOP(CPU가 아무 것도 안 하게 하는 명령어)였다고 하니 분기 예측 기법 등으로 최대한 파이프라인을 유효한 명령어로 채울 수 있는 RISC에 비해 VLIW가 확실히 불리하다.

== 현황 ==
VLIW는 이론적인 최강 성능을 실제 상황에서 제대로 못 내는 컴퓨터과학계의 대표적인 사례다. 어찌 보면 고성능, 저전력, 범용성 특성을 모조리 만족시키지 못한다는 암묵적인 규칙을 VLIW도 피하지 못한다고 볼 수 있다. 압도적인 병렬처리 능력에 기반한 고성능 특성과 간단한 파이프라인 구성을 통한 트랜지스터 절약으로 저전력을 추구한 VLIW ISA를 사용하려면 명령어 간 종속성을 수동으로 제거하는 소프트웨어 프로그래밍의 난이도가 대단히 높아지기 때문에 제대로 된 소프트웨어 생태계가 등장하기 대단히 어려웠으며, 그로 인해 성능 하락과 전력 소모 증가를 감수하고 쉬운 설계와 범용성을 갖췄던 CISC, 거기에 고성능(IBM POWER 및 썬 마이크로시스템즈 SPARC 등)이나 저전력([[ARM]], [[RISC-V]]) 중 하나를 추가로 얻은 RISC와 비교할 때 범용 소프트웨어 확보에 불리한 상품이 나올 수밖에 없었다고 볼 수 있다.

현재 트랜스메타 [[크루소 프로세서]]나 [[인텔 아이태니엄 시리즈]] 같이 일반 소비자를 위해 기획했던 VLIW 아키텍처 프로세서는 가끔씩 중고 시장에 등장하는 [[AMD]]의 Terascale GPU 아키텍처를 사용한 라데온 [[그래픽 카드]]를 제외하면<ref>GPU는 CPU에 비해 분기 명령을 처리할 일이 매우 적고 여러 화소를 같은 방식으로 처리하는 등 병렬적으로 데이터를 처리할 일이 많기 때문에 드라이버 소프트웨어만 잘 만들면 VLIW의 단점이 잘 가려진다. 다만 그때의 라데온의 드라이버 소프트웨어는 별명이 까탈리스트였을 정도로 제 성능 안 나오기로 유명했지만...</ref> 대부분 사장된 지 오래되었고 군사용 특수 목적 CPU인 [[옐브루스 프로세서]]나 몇몇 [[DSP]] 정도에서만 근근이 명맥을 유지하고 있다. 그리고 VLIW가 장악하지 못한 일반 소비자용 칩에는 하드웨어 단계에서 동시에 실행 가능한 명령어를 끌어오는 슈퍼스칼라 기법이 대신 도입되었다.

다만 [[인공지능|신경망 AI]] 가속기와의 상성이 좋을 수 있다는 연구들도 있어 인공지능 추론 가속기인 NPU 한정으로 재평가의 여지는 남아 있다.[https://arxiv.org/abs/1904.05106 관련 논문]

대부분의 인공지능 추론 가속기들이 이 방식을 따르는 등 특수 목적 칩에는 VLIW가 유용할 수 있다.

[[분류: IT]]
[[분류: 컴퓨터]]

MongoDB

2025-10-27T09:23:03Z

Senouis: /* 특징 */

[[분류: IT]]
[[분류: 데이터베이스]]

'''MongoDB'''는 Mongo Inc에서 개발하는 NoSQL 데이터베이스다. 2009년 2월 처음 공개되었으며, 2010년대부터 시작된 NoSQL 데이터베이스 유행의 선두이자 중심 역할을 하는 DBMS다.

== 특징 ==

* SQL을 이용하지 않고, JSON 형태로 데이터를 받아 이진화 처리를 한 BSON으로 데이터를 적재한다. 이런 연유로 테이블이 아닌 도큐먼트라는 단위로 데이터를 저장한다.
** 이로 인해 나타나는 특징으로 DBMS에서 데이터를 꺼낸 다음 별다른 변환 절차 없이 바로 직렬화해 네트워크 통신으로 보내기 쉽다.
** 또한 스키마가 고정되어 있지 않아 신규로 수집한 데이터의 속성 추가/변경이 자유롭다. 대신 기존에 쌓인 데이터의 속성 추가/변경은 어려운 편이다. 이런 이유로 보통 크롤링한 데이터의 저장소로 많이 사용한다.
* 가용성 및 데이터 손실 위험 방지를 위한 레플리케이션이 쉽고, 레플리카 DB 간의 로드 밸런싱을 테이블 단위로 분리하여 DB를 분산 저장하는 샤딩(Sharding)이라는 개념으로 쉽게 구현할 수 있다. 기존 RDBMS가 Master/Slave 구조니 클러스터니 하며 레플리케이션 후 DBMS 간 동기화에 골치를 썩는 것과는 대조적이다. 지금은 아예 개발사 측에서 [https://www.mongodb.com/ko-kr/products/platform?msockid=0ecefd47b8956e05284be871b9bc6f04 MongoDB Atlas]라고, MongoDB Inc에서 직접 세계 각지의 클라우드 서비스에 샤딩을 포함한 MongoDB 클러스터 구성을 자동으로 해주는 서비스까지 냈다.
* RDBMS에서 GROUP BY 및 집계 함수(sum, max, min, count, avg)의 역할에 대응되는 고유의 집계(Aggregation) 기능을 3가지 방식으로 지원한다. 스키마의 무결성이 보장되지 않기 때문에 이런 식으로 상황에 따라 다르게 쓸 수 있도록 여러 방법을 둔 것이다.

== 에디션 ==
* 커뮤니티 에디션: 보통 공짜 MongoDB 서버라고 하면 이쪽을 가리킨다. 개인 또는 소규모 팀 프로젝트에서 쓰는 용도다.
* 엔터프라이즈 에디션: 기업용 유료 버전. MongoDB Inc 측에서 기술지원을 하고 그 대가로 큰 돈을 걷어가는 제품이다.

MongoDB

2025-10-27T09:20:32Z

Senouis: /* 특징 */

[[분류: IT]]
[[분류: 데이터베이스]]

'''MongoDB'''는 Mongo Inc에서 개발하는 NoSQL 데이터베이스다. 2009년 2월 처음 공개되었으며, 2010년대부터 시작된 NoSQL 데이터베이스 유행의 선두이자 중심 역할을 하는 DBMS다.

== 특징 ==

* SQL을 이용하지 않고, JSON 형태로 데이터를 받아 이진화 처리를 한 BSON으로 데이터를 적재한다. 이런 연유로 테이블이 아닌 도큐먼트라는 단위로 데이터를 저장한다.
** 이로 인해 나타나는 특징으로 DBMS에서 데이터를 꺼낸 다음 별다른 변환 절차 없이 바로 직렬화해 네트워크 통신으로 보내기 쉽다.
** 또한 스키마가 고정되어 있지 않아 신규로 수집한 데이터의 속성 추가/변경이 자유롭다. 대신 기존에 쌓인 데이터의 속성 추가/변경은 어려운 편이다. 이런 이유로 보통 크롤링한 데이터의 저장소로 많이 사용한다.
* 가용성 및 데이터 손실 위험 방지를 위한 레플리케이션이 쉽고, 레플리카 DB 간의 로드 밸런싱을 테이블 단위로 분리하여 DB를 분산 저장하는 샤딩(Sharding)이라는 개념으로 쉽게 구현할 수 있다. 기존 RDBMS가 Master/Slave 구조니 클러스터니 하며 레플리케이션 후 DBMS 간 동기화에 골치를 썩는 것과는 대조적이다. 지금은 아예 개발사 측에서 [MongoDB Atlas https://www.mongodb.com/ko-kr/products/platform?msockid=0ecefd47b8956e05284be871b9bc6f04]라고, MongoDB Inc에서 직접 세계 각지의 클라우드 서비스에 샤딩을 포함한 MongoDB 클러스터 구성을 자동으로 해주는 서비스까지 냈다.
* RDBMS에서 GROUP BY 및 집계 함수(sum, max, min, count, avg)의 역할에 대응되는 고유의 집계(Aggregation) 기능을 3가지 방식으로 지원한다. 스키마의 무결성이 보장되지 않기 때문에 이런 식으로 상황에 따라 다르게 쓸 수 있도록 여러 방법을 둔 것이다.

== 에디션 ==
* 커뮤니티 에디션: 보통 공짜 MongoDB 서버라고 하면 이쪽을 가리킨다. 개인 또는 소규모 팀 프로젝트에서 쓰는 용도다.
* 엔터프라이즈 에디션: 기업용 유료 버전. MongoDB Inc 측에서 기술지원을 하고 그 대가로 큰 돈을 걷어가는 제품이다.

큰숲백과:오늘의 말

2025-10-22T13:31:04Z

Senouis: /* 보이는 부분 */오늘의 말 추가

<nowiki><onlyinclude> </onlyinclude></nowiki> 태그 사이에 말을 쓰셔야 합니다. 또는 '보이는 부분' 문단의 오른쪽의 '[원본 편집]' 버튼을 눌러 편집하시면 됩니다.

다른 사람이 쓴 오늘의 말은 반달리즘이나 개인적 내용이 아니면 지우지 말아주세요. 친목 목적으로 글을 쓰는 행위는 자제해주세요. 친목 목적으로 작성을 하시면 삭제 당하실 수 있습니다.

__TOC__
<div style="background:#eee">
== 보이는 부분 ==
<onlyinclude>
{{오늘의 말/A|새 서버로 이전 완료됐습니다. 앞으로도 좋은 기여 부탁드립니다.|Bigforest|안도의 한숨을 내쉬며}}
{{오늘의 말/Q|짧은 도메인으로 접속하려고 하면 백신과 후이즈가 애써서 접속을 차단하려고 하네요……?|MondoCane|머리를 긁으며}}
{{오늘의 말/Q|네, 덤으로 여기서 메일을 보내면 지메일에서 스팸메일함으로 계속 이동시키기에 사이트 도메인 신뢰성 향상 조치가 필요한 것 같습니다.|Senouis|스팸메일함에 들어간 큰숲백과 메일을 보며}}
{{오늘의 말/A|한동안 손 놓고 있었는데 오랫만에 위키 정비할 일 생겼네요.|Bigforest|오늘의 말이 갱신된 것에 놀라면서.}}
{{오늘의 말/A|도메인 이슈랑 이메일 이슈는 해결된 듯? 확인해주세요.|Bigforest|확신이 없는 듯한 말투로}}
{{오늘의 말/A|오옹, 해결됐네요.|MondoCane|신기해 하며}}
{{오늘의 말/A|위키 오랫만에 기여하려고 보니 뭘 해야할지 막막하네요.|Bigforest|고민에 찬 표정으로}}
{{오늘의 말/Q|덤프 데이터 언제 나오나요?|사용자|공지를 보고}}
</onlyinclude>

== 설명 ==
SWEET
[[Project:대문숲|대문]]에 노출되는 틀입니다.

항목 개수가 8개를 넘어가면 앞에 있는 항목은 [[Project:오늘의 말/보존 문서]]로 이동됩니다.

== 이용방법 ==
<pre>
질문하기
{{오늘의 말/Q|(하고 싶은 말)|(작성자)}}

답변하기
{{오늘의 말/A|(하고 싶은 말)|(작성자)}}
</pre>

카카오톡 형태의 대화형 인터페이스로 바뀌었습니다.

== 기타 ==
* [[Project:오늘의 말]]

[[분류:큰숲백과 관리]]

VPN

2025-08-05T14:26:01Z

Senouis: /* 원래 개발 목적: 기업용 사설망 구축 및 재택근무 지원 */

[[분류: 인터넷]]
[[분류: IT]]

'''VPN'''(Virtual Private Network, 가상 사설망)은 통신을 위해 네트워크 망으로 패킷을 보낼 때 정해진 암호화 프로토콜로 암호화해 특정한 컴퓨터만 자신이 보낸 정보를 받고 다시 응답할 수 있는 네트워크 기술이다.

VPN에 사용되는 암호화 프로토콜로는 L2TP, IPSec 등이 있으며 이들은 OSI 7계층 중 3계층에 있다. 1~3계층은 물리적인 하드웨어 단계에서 작동하는 패킷 처리 과정이라 소프트웨어로 어떻게 보고 바꾸기가 4계층 이상에서의 단계(인터넷으로 치면 [[IP]]부터 [[HTTP]]까지 계층 범위)에선 쉽지 않은 편이다.

다만 VPN은 중계 서버 역할을 하는 고성능 컴퓨터(또는 전용 라우터)가 필요하며 송신자가 중계 서버까지 데이터를 보내는 패킷만 암호화한다. 중계 서버에서 수신자에게 보내는 패킷은 TLS 등으로 소프트웨어적인 암호화가 필요하다. '''송신자는 중계 서버를 믿을 수 있는 특별한 컴퓨터'''로 보지만, '''수신자 입장에서 중계 서버는 그냥 평범한 컴퓨터(내지는 라우터)'''이기 때문이다. 그래서 수신자에게 패킷이 도착할 때까지 아무도 못 알아보게 상위 계층에서 추가로 암호화를 걸어야 하는 것.

== 용도 ==
=== 원래 개발 목적: '''기업용 사설망 구축 및 [[재택근무]] 지원''' ===
원래 VPN의 용도는 인터넷 접근이 가능한 회선에 패킷을 뿌리되 그 안의 특정 컴퓨터만 패킷을 받아 볼 수 있도록 암호화해서 유사 [[인트라넷]]처럼 통신이 일부 컴퓨터에서만 이루어지게 하는 것이다. 괜히 이름이 '''가상''' 사설망이 아니다. 이 기술 덕분에 업무용 컴퓨터의 기본적인 보안(예: VPN 연결 유지, 다른 컴퓨터의 데이터 저장장치를 함부로 업무용 컴퓨터에 연결하지 않기, 정기적인 악성 소프트웨어 검사 등)만 개인이 잘 지키면 가정집에서 재택근무를 해도 기업의 기밀 사항이 새어나갈 구석이 없다. 원래부터 기업들이 보안을 위해 적절하게 사용하고 있었지만 [[코로나19]] 및 외국 취업 활동의 활성화로 인해 비대면 근무 상황이 늘어나며 VPN의 원래 개발 목적이 대중에게도 어느 정도 알려지게 되었다.

=== 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 ===
그러나 여기서 '회사 내 다른 수신자의 컴퓨터'를 '정부가 접근을 금지한 외국 사이트가 돌아가는 서버 컴퓨터', '회사 내 VPN 서버'를 '해외에 위치한 공용 VPN 중계 서버'로 대응하면 '''국내의 모든 컴퓨터와 라우터들이 3계층 단계의 암호화에서 막혀 내 데이터 요청 패킷을 볼 수 없는데''' 국내와 다른 법률을 적용 받는 '''해외 중계 서버 운용자는 이걸 받아도 문제 없이 복호화를 할 수 있고''', 그러면서 정작 수신자인 외국 사이트 서버가 볼 때에는 '''해외에 소재한 평범한 컴퓨터가 접속한 것처럼 보이게 된다'''. 즉, 국내 정부의 정책에 따라 TLS/SSL을 써도 소용이 없을 정도로 IP~HTTP 단계에서 접근이 제한된 해외 사이트에 접속할 수 있는 '''강력한 검열 우회 수단'''이 된다.

이에 따라 인터넷 검열이 다소 심한 편인 국가들이 그렇지 않은 국가에서 제공되는 인터넷 컨텐츠를 몰래 찾아 보기 위해 VPN을 사용하기 시작했다. 특히 자유민주주의 국가라 VPN 사용 자체을 막으려는 시도에 대해 반론이 얼마든지 가능하고 폭압적인 정책을 만들 수 없는 현대 대한민국에서는 법률 상으로 개인의 VPN 사용에 제약이 거의 없어 대한민국 인터넷 사용자들이 해외 공용 VPN 서버 이용률 1위를 찍고 있다.

다만 이보다 검열이 비교도 안 되게 빡센 [[중화인민공화국|중국]]에서는 공산당 일당 독재 체제인 정부가 기어이 개인의 허가되지 않은 VPN 사용을 불법화하는 바람에 그 어마어마한 국가 인구에 비해 VPN 사용자가 적어 대한민국에 밀려 접속자 수 2위에 그치고 있다. 그 외의 강력한 인터넷 검열 시행 국가(예: 이란, 북한 등)는 아예 인터넷 접속이 가능한 단말기 자체가 국가 내에 거의 없어 인터넷 접속 자체가 매우 어렵기에 의외로 사용자 수가 매우 낮은 편. 여기는 최소 [[Tor]] 같은 더 강력한 우회 도구를 비롯하여 그런 도구를 사용했다는 사실을 숨길 수단까지 마련하여 도저히 잡을 수 없을 정도로 온갖 방법을 동원해 신원을 감춰야 간신히 인터넷을 몰래 할 수 있는 정도다.

주의할 것은 VPN 사용 시 접속할 중계 서버가 반드시 해외에 있으며, 수신자인 외국 사이트에 접근이 가능한 국가에 위치해 있어야 한다는 것이다. 국내 VPN 중계 서버는 이용해 봤자 말짱 꽝이고, 심지어 접속 로그 기록까지 남는다.

또, 무료 VPN 서비스가 있다는 광고에 함부로 현혹되면 안 된다. 반드시 유료 결제를 하거나 아예 창립 목적부터 검열을 막을 목적으로 작정하고 설립된 몇몇 유명한 회사의 서비스가 아니면 무료 VPN 서비스는 이용하지 말고, 접근에 문제 없는 사이트 대상으로 VPN 연결을 테스트하는 용도로만 쓰자. 유료 결제를 하면 회사가 전세계 어디에서도 불법으로 인정되는 범죄 행위와 관련된 것이 아니면 회사의 서비스에 대한 신뢰성 문제 때문에 고객의 정보를 쉽게 내주지 않는다. 물론 '''대놓고 범죄 행위를 목적으로 VPN을 쓰면 인터폴을 통한 국가 간 공조 수사 크리가 뜨면서 감옥행 확정이다.'''

VPN

2025-08-05T14:25:27Z

Senouis: /* 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 */

[[분류: 인터넷]]
[[분류: IT]]

'''VPN'''(Virtual Private Network, 가상 사설망)은 통신을 위해 네트워크 망으로 패킷을 보낼 때 정해진 암호화 프로토콜로 암호화해 특정한 컴퓨터만 자신이 보낸 정보를 받고 다시 응답할 수 있는 네트워크 기술이다.

VPN에 사용되는 암호화 프로토콜로는 L2TP, IPSec 등이 있으며 이들은 OSI 7계층 중 3계층에 있다. 1~3계층은 물리적인 하드웨어 단계에서 작동하는 패킷 처리 과정이라 소프트웨어로 어떻게 보고 바꾸기가 4계층 이상에서의 단계(인터넷으로 치면 [[IP]]부터 [[HTTP]]까지 계층 범위)에선 쉽지 않은 편이다.

다만 VPN은 중계 서버 역할을 하는 고성능 컴퓨터(또는 전용 라우터)가 필요하며 송신자가 중계 서버까지 데이터를 보내는 패킷만 암호화한다. 중계 서버에서 수신자에게 보내는 패킷은 TLS 등으로 소프트웨어적인 암호화가 필요하다. '''송신자는 중계 서버를 믿을 수 있는 특별한 컴퓨터'''로 보지만, '''수신자 입장에서 중계 서버는 그냥 평범한 컴퓨터(내지는 라우터)'''이기 때문이다. 그래서 수신자에게 패킷이 도착할 때까지 아무도 못 알아보게 상위 계층에서 추가로 암호화를 걸어야 하는 것.

== 용도 ==
=== 원래 개발 목적: 기업용 사설망 구축 및 [[재택근무]] 지원 ===
원래 VPN의 용도는 인터넷 접근이 가능한 회선에 패킷을 뿌리되 그 안의 특정 컴퓨터만 패킷을 받아 볼 수 있도록 암호화해서 유사 [[인트라넷]]처럼 통신이 일부 컴퓨터에서만 이루어지게 하는 것이다. 괜히 이름이 '''가상''' 사설망이 아니다. 이 기술 덕분에 업무용 컴퓨터의 기본적인 보안(예: VPN 연결 유지, 다른 컴퓨터의 데이터 저장장치를 함부로 업무용 컴퓨터에 연결하지 않기, 정기적인 악성 소프트웨어 검사 등)만 개인이 잘 지키면 가정집에서 재택근무를 해도 기업의 기밀 사항이 새어나갈 구석이 없다. 원래부터 기업들이 보안을 위해 적절하게 사용하고 있었지만 [[코로나19]] 및 외국 취업 활동의 활성화로 인해 비대면 근무 상황이 늘어나며 VPN의 원래 개발 목적이 대중에게도 어느 정도 알려지게 되었다.

=== 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 ===
그러나 여기서 '회사 내 다른 수신자의 컴퓨터'를 '정부가 접근을 금지한 외국 사이트가 돌아가는 서버 컴퓨터', '회사 내 VPN 서버'를 '해외에 위치한 공용 VPN 중계 서버'로 대응하면 '''국내의 모든 컴퓨터와 라우터들이 3계층 단계의 암호화에서 막혀 내 데이터 요청 패킷을 볼 수 없는데''' 국내와 다른 법률을 적용 받는 '''해외 중계 서버 운용자는 이걸 받아도 문제 없이 복호화를 할 수 있고''', 그러면서 정작 수신자인 외국 사이트 서버가 볼 때에는 '''해외에 소재한 평범한 컴퓨터가 접속한 것처럼 보이게 된다'''. 즉, 국내 정부의 정책에 따라 TLS/SSL을 써도 소용이 없을 정도로 IP~HTTP 단계에서 접근이 제한된 해외 사이트에 접속할 수 있는 '''강력한 검열 우회 수단'''이 된다.

이에 따라 인터넷 검열이 다소 심한 편인 국가들이 그렇지 않은 국가에서 제공되는 인터넷 컨텐츠를 몰래 찾아 보기 위해 VPN을 사용하기 시작했다. 특히 자유민주주의 국가라 VPN 사용 자체을 막으려는 시도에 대해 반론이 얼마든지 가능하고 폭압적인 정책을 만들 수 없는 현대 대한민국에서는 법률 상으로 개인의 VPN 사용에 제약이 거의 없어 대한민국 인터넷 사용자들이 해외 공용 VPN 서버 이용률 1위를 찍고 있다.

다만 이보다 검열이 비교도 안 되게 빡센 [[중화인민공화국|중국]]에서는 공산당 일당 독재 체제인 정부가 기어이 개인의 허가되지 않은 VPN 사용을 불법화하는 바람에 그 어마어마한 국가 인구에 비해 VPN 사용자가 적어 대한민국에 밀려 접속자 수 2위에 그치고 있다. 그 외의 강력한 인터넷 검열 시행 국가(예: 이란, 북한 등)는 아예 인터넷 접속이 가능한 단말기 자체가 국가 내에 거의 없어 인터넷 접속 자체가 매우 어렵기에 의외로 사용자 수가 매우 낮은 편. 여기는 최소 [[Tor]] 같은 더 강력한 우회 도구를 비롯하여 그런 도구를 사용했다는 사실을 숨길 수단까지 마련하여 도저히 잡을 수 없을 정도로 온갖 방법을 동원해 신원을 감춰야 간신히 인터넷을 몰래 할 수 있는 정도다.

주의할 것은 VPN 사용 시 접속할 중계 서버가 반드시 해외에 있으며, 수신자인 외국 사이트에 접근이 가능한 국가에 위치해 있어야 한다는 것이다. 국내 VPN 중계 서버는 이용해 봤자 말짱 꽝이고, 심지어 접속 로그 기록까지 남는다.

또, 무료 VPN 서비스가 있다는 광고에 함부로 현혹되면 안 된다. 반드시 유료 결제를 하거나 아예 창립 목적부터 검열을 막을 목적으로 작정하고 설립된 몇몇 유명한 회사의 서비스가 아니면 무료 VPN 서비스는 이용하지 말고, 접근에 문제 없는 사이트 대상으로 VPN 연결을 테스트하는 용도로만 쓰자. 유료 결제를 하면 회사가 전세계 어디에서도 불법으로 인정되는 범죄 행위와 관련된 것이 아니면 회사의 서비스에 대한 신뢰성 문제 때문에 고객의 정보를 쉽게 내주지 않는다. 물론 '''대놓고 범죄 행위를 목적으로 VPN을 쓰면 인터폴을 통한 국가 간 공조 수사 크리가 뜨면서 감옥행 확정이다.'''

VPN

2025-08-05T14:18:51Z

Senouis: /* 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 */

[[분류: 인터넷]]
[[분류: IT]]

'''VPN'''(Virtual Private Network, 가상 사설망)은 통신을 위해 네트워크 망으로 패킷을 보낼 때 정해진 암호화 프로토콜로 암호화해 특정한 컴퓨터만 자신이 보낸 정보를 받고 다시 응답할 수 있는 네트워크 기술이다.

VPN에 사용되는 암호화 프로토콜로는 L2TP, IPSec 등이 있으며 이들은 OSI 7계층 중 3계층에 있다. 1~3계층은 물리적인 하드웨어 단계에서 작동하는 패킷 처리 과정이라 소프트웨어로 어떻게 보고 바꾸기가 4계층 이상에서의 단계(인터넷으로 치면 [[IP]]부터 [[HTTP]]까지 계층 범위)에선 쉽지 않은 편이다.

다만 VPN은 중계 서버 역할을 하는 고성능 컴퓨터(또는 전용 라우터)가 필요하며 송신자가 중계 서버까지 데이터를 보내는 패킷만 암호화한다. 중계 서버에서 수신자에게 보내는 패킷은 TLS 등으로 소프트웨어적인 암호화가 필요하다. '''송신자는 중계 서버를 믿을 수 있는 특별한 컴퓨터'''로 보지만, '''수신자 입장에서 중계 서버는 그냥 평범한 컴퓨터(내지는 라우터)'''이기 때문이다. 그래서 수신자에게 패킷이 도착할 때까지 아무도 못 알아보게 상위 계층에서 추가로 암호화를 걸어야 하는 것.

== 용도 ==
=== 원래 개발 목적: 기업용 사설망 구축 및 [[재택근무]] 지원 ===
원래 VPN의 용도는 인터넷 접근이 가능한 회선에 패킷을 뿌리되 그 안의 특정 컴퓨터만 패킷을 받아 볼 수 있도록 암호화해서 유사 [[인트라넷]]처럼 통신이 일부 컴퓨터에서만 이루어지게 하는 것이다. 괜히 이름이 '''가상''' 사설망이 아니다. 이 기술 덕분에 업무용 컴퓨터의 기본적인 보안(예: VPN 연결 유지, 다른 컴퓨터의 데이터 저장장치를 함부로 업무용 컴퓨터에 연결하지 않기, 정기적인 악성 소프트웨어 검사 등)만 개인이 잘 지키면 가정집에서 재택근무를 해도 기업의 기밀 사항이 새어나갈 구석이 없다. 원래부터 기업들이 보안을 위해 적절하게 사용하고 있었지만 [[코로나19]] 및 외국 취업 활동의 활성화로 인해 비대면 근무 상황이 늘어나며 VPN의 원래 개발 목적이 대중에게도 어느 정도 알려지게 되었다.

=== 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 ===
그러나 여기서 '회사 내 다른 수신자의 컴퓨터'를 '정부가 접근을 금지한 외국 사이트가 돌아가는 서버 컴퓨터', '회사 내 VPN 서버'를 '해외에 위치한 공용 VPN 중계 서버'로 대응하면 '''국내의 모든 컴퓨터와 라우터들이 3계층 단계의 암호화에서 막혀 내 데이터 요청 패킷을 볼 수 없는데''' 국내와 다른 법률을 적용 받는 '''해외 중계 서버 운용자는 이걸 받아도 문제 없이 복호화를 할 수 있고''', 그러면서 정작 수신자인 외국 사이트 서버가 볼 때에는 '''해외에 소재한 평범한 컴퓨터가 접속한 것처럼 보이게 된다'''. 즉, 국내 정부의 정책에 따라 TLS/SSL을 써도 소용이 없을 정도로 IP~HTTP 단계에서 접근이 제한된 해외 사이트에 접속할 수 있는 '''강력한 검열 우회 수단'''이 된다.

이에 따라 인터넷 검열이 다소 심한 편인 국가들이 그렇지 않은 국가에서 제공되는 인터넷 컨텐츠를 몰래 찾아 보기 위해 VPN을 사용하기 시작했다. 특히 자유민주주의 국가라 VPN 사용 자체을 막으려는 시도에 대해 반론이 얼마든지 가능하고 폭압적인 정책을 만들 수 없는 현대 대한민국에서는 법률 상으로 개인의 VPN 사용에 제약이 거의 없어 대한민국 인터넷 사용자들이 해외 공용 VPN 서버 이용률 1위를 찍고 있다.

다만 이보다 검열이 비교도 안 되게 빡센 [[중화인민공화국|중국]]에서는 공산당 일당 독재 체제인 정부가 기어이 개인의 허가되지 않은 VPN 사용을 불법화하는 바람에 그 어마어마한 국가 인구에 비해 VPN 사용자가 적어 대한민국에 밀려 접속자 수 2위에 그치고 있다. 그 외의 강력한 인터넷 검열 시행 국가(예: 이란, 북한 등)는 아예 인터넷 접속이 가능한 단말기 자체가 국가 내에 거의 없어 인터넷 접속 자체가 매우 어렵기에 의외로 사용자 수가 매우 낮은 편. 여기는 최소 [[Tor]] 같은 더 강력한 우회 도구를 비롯하여 그런 도구를 사용했다는 사실을 숨길 수단까지 마련하여 도저히 잡을 수 없을 정도로 온갖 방법을 동원해 신원을 감춰야 간신히 인터넷을 몰래 할 수 있는 정도다.

주의할 것은 VPN 사용 시 접속할 중계 서버가 반드시 해외에 있으며, 수신자인 외국 사이트에 접근이 가능한 국가에 위치해 있어야 한다는 것이다. 국내 VPN 중계 서버는 이용해 봤자 말짱 꽝이고, 심지어 접속 로그 기록까지 남는다.

VPN

2025-08-05T14:18:38Z

Senouis: /* 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 */

[[분류: 인터넷]]
[[분류: IT]]

'''VPN'''(Virtual Private Network, 가상 사설망)은 통신을 위해 네트워크 망으로 패킷을 보낼 때 정해진 암호화 프로토콜로 암호화해 특정한 컴퓨터만 자신이 보낸 정보를 받고 다시 응답할 수 있는 네트워크 기술이다.

VPN에 사용되는 암호화 프로토콜로는 L2TP, IPSec 등이 있으며 이들은 OSI 7계층 중 3계층에 있다. 1~3계층은 물리적인 하드웨어 단계에서 작동하는 패킷 처리 과정이라 소프트웨어로 어떻게 보고 바꾸기가 4계층 이상에서의 단계(인터넷으로 치면 [[IP]]부터 [[HTTP]]까지 계층 범위)에선 쉽지 않은 편이다.

다만 VPN은 중계 서버 역할을 하는 고성능 컴퓨터(또는 전용 라우터)가 필요하며 송신자가 중계 서버까지 데이터를 보내는 패킷만 암호화한다. 중계 서버에서 수신자에게 보내는 패킷은 TLS 등으로 소프트웨어적인 암호화가 필요하다. '''송신자는 중계 서버를 믿을 수 있는 특별한 컴퓨터'''로 보지만, '''수신자 입장에서 중계 서버는 그냥 평범한 컴퓨터(내지는 라우터)'''이기 때문이다. 그래서 수신자에게 패킷이 도착할 때까지 아무도 못 알아보게 상위 계층에서 추가로 암호화를 걸어야 하는 것.

== 용도 ==
=== 원래 개발 목적: 기업용 사설망 구축 및 [[재택근무]] 지원 ===
원래 VPN의 용도는 인터넷 접근이 가능한 회선에 패킷을 뿌리되 그 안의 특정 컴퓨터만 패킷을 받아 볼 수 있도록 암호화해서 유사 [[인트라넷]]처럼 통신이 일부 컴퓨터에서만 이루어지게 하는 것이다. 괜히 이름이 '''가상''' 사설망이 아니다. 이 기술 덕분에 업무용 컴퓨터의 기본적인 보안(예: VPN 연결 유지, 다른 컴퓨터의 데이터 저장장치를 함부로 업무용 컴퓨터에 연결하지 않기, 정기적인 악성 소프트웨어 검사 등)만 개인이 잘 지키면 가정집에서 재택근무를 해도 기업의 기밀 사항이 새어나갈 구석이 없다. 원래부터 기업들이 보안을 위해 적절하게 사용하고 있었지만 [[코로나19]] 및 외국 취업 활동의 활성화로 인해 비대면 근무 상황이 늘어나며 VPN의 원래 개발 목적이 대중에게도 어느 정도 알려지게 되었다.

=== 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 ===
그러나 여기서 '회사 내 다른 수신자의 컴퓨터'를 '정부가 금지한 외국 사이트가 돌아가는 서버 컴퓨터', '회사 내 VPN 서버'를 '해외에 위치한 공용 VPN 중계 서버'로 대응하면 '''국내의 모든 컴퓨터와 라우터들이 3계층 단계의 암호화에서 막혀 내 데이터 요청 패킷을 볼 수 없는데''' 국내와 다른 법률을 적용 받는 '''해외 중계 서버 운용자는 이걸 받아도 문제 없이 복호화를 할 수 있고''', 그러면서 정작 수신자인 외국 사이트 서버가 볼 때에는 '''해외에 소재한 평범한 컴퓨터가 접속한 것처럼 보이게 된다'''. 즉, 국내 정부의 정책에 따라 TLS/SSL을 써도 소용이 없을 정도로 IP~HTTP 단계에서 접근이 제한된 해외 사이트에 접속할 수 있는 '''강력한 검열 우회 수단'''이 된다.

이에 따라 인터넷 검열이 다소 심한 편인 국가들이 그렇지 않은 국가에서 제공되는 인터넷 컨텐츠를 몰래 찾아 보기 위해 VPN을 사용하기 시작했다. 특히 자유민주주의 국가라 VPN 사용 자체을 막으려는 시도에 대해 반론이 얼마든지 가능하고 폭압적인 정책을 만들 수 없는 현대 대한민국에서는 법률 상으로 개인의 VPN 사용에 제약이 거의 없어 대한민국 인터넷 사용자들이 해외 공용 VPN 서버 이용률 1위를 찍고 있다.

다만 이보다 검열이 비교도 안 되게 빡센 [[중화인민공화국|중국]]에서는 공산당 일당 독재 체제인 정부가 기어이 개인의 허가되지 않은 VPN 사용을 불법화하는 바람에 그 어마어마한 국가 인구에 비해 VPN 사용자가 적어 대한민국에 밀려 접속자 수 2위에 그치고 있다. 그 외의 강력한 인터넷 검열 시행 국가(예: 이란, 북한 등)는 아예 인터넷 접속이 가능한 단말기 자체가 국가 내에 거의 없어 인터넷 접속 자체가 매우 어렵기에 의외로 사용자 수가 매우 낮은 편. 여기는 최소 [[Tor]] 같은 더 강력한 우회 도구를 비롯하여 그런 도구를 사용했다는 사실을 숨길 수단까지 마련하여 도저히 잡을 수 없을 정도로 온갖 방법을 동원해 신원을 감춰야 간신히 인터넷을 몰래 할 수 있는 정도다.

주의할 것은 VPN 사용 시 접속할 중계 서버가 반드시 해외에 있으며, 수신자인 외국 사이트에 접근이 가능한 국가에 위치해 있어야 한다는 것이다. 국내 VPN 중계 서버는 이용해 봤자 말짱 꽝이고, 심지어 접속 로그 기록까지 남는다.

VPN

2025-08-05T14:18:04Z

Senouis: /* 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 */

[[분류: 인터넷]]
[[분류: IT]]

'''VPN'''(Virtual Private Network, 가상 사설망)은 통신을 위해 네트워크 망으로 패킷을 보낼 때 정해진 암호화 프로토콜로 암호화해 특정한 컴퓨터만 자신이 보낸 정보를 받고 다시 응답할 수 있는 네트워크 기술이다.

VPN에 사용되는 암호화 프로토콜로는 L2TP, IPSec 등이 있으며 이들은 OSI 7계층 중 3계층에 있다. 1~3계층은 물리적인 하드웨어 단계에서 작동하는 패킷 처리 과정이라 소프트웨어로 어떻게 보고 바꾸기가 4계층 이상에서의 단계(인터넷으로 치면 [[IP]]부터 [[HTTP]]까지 계층 범위)에선 쉽지 않은 편이다.

다만 VPN은 중계 서버 역할을 하는 고성능 컴퓨터(또는 전용 라우터)가 필요하며 송신자가 중계 서버까지 데이터를 보내는 패킷만 암호화한다. 중계 서버에서 수신자에게 보내는 패킷은 TLS 등으로 소프트웨어적인 암호화가 필요하다. '''송신자는 중계 서버를 믿을 수 있는 특별한 컴퓨터'''로 보지만, '''수신자 입장에서 중계 서버는 그냥 평범한 컴퓨터(내지는 라우터)'''이기 때문이다. 그래서 수신자에게 패킷이 도착할 때까지 아무도 못 알아보게 상위 계층에서 추가로 암호화를 걸어야 하는 것.

== 용도 ==
=== 원래 개발 목적: 기업용 사설망 구축 및 [[재택근무]] 지원 ===
원래 VPN의 용도는 인터넷 접근이 가능한 회선에 패킷을 뿌리되 그 안의 특정 컴퓨터만 패킷을 받아 볼 수 있도록 암호화해서 유사 [[인트라넷]]처럼 통신이 일부 컴퓨터에서만 이루어지게 하는 것이다. 괜히 이름이 '''가상''' 사설망이 아니다. 이 기술 덕분에 업무용 컴퓨터의 기본적인 보안(예: VPN 연결 유지, 다른 컴퓨터의 데이터 저장장치를 함부로 업무용 컴퓨터에 연결하지 않기, 정기적인 악성 소프트웨어 검사 등)만 개인이 잘 지키면 가정집에서 재택근무를 해도 기업의 기밀 사항이 새어나갈 구석이 없다. 원래부터 기업들이 보안을 위해 적절하게 사용하고 있었지만 [[코로나19]] 및 외국 취업 활동의 활성화로 인해 비대면 근무 상황이 늘어나며 VPN의 원래 개발 목적이 대중에게도 어느 정도 알려지게 되었다.

=== 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 ===
그러나 여기서 '회사 내 다른 수신자의 컴퓨터'를 '정부가 금지한 외국 사이트가 돌아가는 서버 컴퓨터', '회사 내 VPN 서버'를 '해외에 위치한 공용 VPN 중계 서버'로 대응하면 '''국내의 모든 컴퓨터와 라우터들이 3계층 단계의 암호화에서 막혀 내 데이터 요청 패킷을 볼 수 없는데''' 국내와 다른 법률을 적용 받는 '''해외 중계 서버 운용자는 이걸 받아도 문제가 없고''', 그러면서 정작 수신자인 외국 사이트 서버가 볼 때에는 '''해외에 소재한 평범한 컴퓨터가 접속한 것처럼 보이게 된다'''. 즉, 국내 정부의 정책에 따라 TLS/SSL을 써도 소용이 없을 정도로 IP~HTTP 단계에서 접근이 제한된 해외 사이트에 접속할 수 있는 '''강력한 검열 우회 수단'''이 된다.

이에 따라 인터넷 검열이 다소 심한 편인 국가들이 그렇지 않은 국가에서 제공되는 인터넷 컨텐츠를 몰래 찾아 보기 위해 VPN을 사용하기 시작했다. 특히 자유민주주의 국가라 VPN 사용 자체을 막으려는 시도에 대해 반론이 얼마든지 가능하고 폭압적인 정책을 만들 수 없는 현대 대한민국에서는 법률 상으로 개인의 VPN 사용에 제약이 거의 없어 대한민국 인터넷 사용자들이 해외 공용 VPN 서버 이용률 1위를 찍고 있다.

다만 이보다 검열이 비교도 안 되게 빡센 [[중화인민공화국|중국]]에서는 공산당 일당 독재 체제인 정부가 기어이 개인의 허가되지 않은 VPN 사용을 불법화하는 바람에 그 어마어마한 국가 인구에 비해 VPN 사용자가 적어 대한민국에 밀려 접속자 수 2위에 그치고 있다. 그 외의 강력한 인터넷 검열 시행 국가(예: 이란, 북한 등)는 아예 인터넷 접속이 가능한 단말기 자체가 국가 내에 거의 없어 인터넷 접속 자체가 매우 어렵기에 의외로 사용자 수가 매우 낮은 편. 여기는 최소 [[Tor]] 같은 더 강력한 우회 도구를 비롯하여 그런 도구를 사용했다는 사실을 숨길 수단까지 마련하여 도저히 잡을 수 없을 정도로 온갖 방법을 동원해 신원을 감춰야 간신히 인터넷을 몰래 할 수 있는 정도다.

주의할 것은 VPN 사용 시 접속할 중계 서버가 반드시 해외에 있으며, 수신자인 외국 사이트에 접근이 가능한 국가에 위치해 있어야 한다는 것이다. 국내 VPN 중계 서버는 이용해 봤자 말짱 꽝이고, 심지어 접속 로그 기록까지 남는다.

VPN

2025-08-05T14:17:46Z

Senouis: /* 원래 개발 목적: 기업용 사설망 구축 및 재택근무 지원 */

[[분류: 인터넷]]
[[분류: IT]]

'''VPN'''(Virtual Private Network, 가상 사설망)은 통신을 위해 네트워크 망으로 패킷을 보낼 때 정해진 암호화 프로토콜로 암호화해 특정한 컴퓨터만 자신이 보낸 정보를 받고 다시 응답할 수 있는 네트워크 기술이다.

VPN에 사용되는 암호화 프로토콜로는 L2TP, IPSec 등이 있으며 이들은 OSI 7계층 중 3계층에 있다. 1~3계층은 물리적인 하드웨어 단계에서 작동하는 패킷 처리 과정이라 소프트웨어로 어떻게 보고 바꾸기가 4계층 이상에서의 단계(인터넷으로 치면 [[IP]]부터 [[HTTP]]까지 계층 범위)에선 쉽지 않은 편이다.

다만 VPN은 중계 서버 역할을 하는 고성능 컴퓨터(또는 전용 라우터)가 필요하며 송신자가 중계 서버까지 데이터를 보내는 패킷만 암호화한다. 중계 서버에서 수신자에게 보내는 패킷은 TLS 등으로 소프트웨어적인 암호화가 필요하다. '''송신자는 중계 서버를 믿을 수 있는 특별한 컴퓨터'''로 보지만, '''수신자 입장에서 중계 서버는 그냥 평범한 컴퓨터(내지는 라우터)'''이기 때문이다. 그래서 수신자에게 패킷이 도착할 때까지 아무도 못 알아보게 상위 계층에서 추가로 암호화를 걸어야 하는 것.

== 용도 ==
=== 원래 개발 목적: 기업용 사설망 구축 및 [[재택근무]] 지원 ===
원래 VPN의 용도는 인터넷 접근이 가능한 회선에 패킷을 뿌리되 그 안의 특정 컴퓨터만 패킷을 받아 볼 수 있도록 암호화해서 유사 [[인트라넷]]처럼 통신이 일부 컴퓨터에서만 이루어지게 하는 것이다. 괜히 이름이 '''가상''' 사설망이 아니다. 이 기술 덕분에 업무용 컴퓨터의 기본적인 보안(예: VPN 연결 유지, 다른 컴퓨터의 데이터 저장장치를 함부로 업무용 컴퓨터에 연결하지 않기, 정기적인 악성 소프트웨어 검사 등)만 개인이 잘 지키면 가정집에서 재택근무를 해도 기업의 기밀 사항이 새어나갈 구석이 없다. 원래부터 기업들이 보안을 위해 적절하게 사용하고 있었지만 [[코로나19]] 및 외국 취업 활동의 활성화로 인해 비대면 근무 상황이 늘어나며 VPN의 원래 개발 목적이 대중에게도 어느 정도 알려지게 되었다.

=== 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 ===
그러나 여기서 '회사 내 다른 컴퓨터'를 '정부가 금지한 외국 사이트가 돌아가는 서버 컴퓨터', '회사 내 VPN 서버'를 '해외에 위치한 공용 VPN 중계 서버'로 대응하면 '''국내의 모든 컴퓨터와 라우터들이 3계층 단계의 암호화에서 막혀 내 데이터 요청 패킷을 볼 수 없는데''' 국내와 다른 법률을 적용 받는 '''해외 중계 서버 운용자는 이걸 받아도 문제가 없고''', 그러면서 정작 수신자인 외국 사이트 서버가 볼 때에는 '''해외에 소재한 평범한 컴퓨터가 접속한 것처럼 보이게 된다'''. 즉, 국내 정부의 정책에 따라 TLS/SSL을 써도 소용이 없을 정도로 IP~HTTP 단계에서 접근이 제한된 해외 사이트에 접속할 수 있는 '''강력한 검열 우회 수단'''이 된다.

이에 따라 인터넷 검열이 다소 심한 편인 국가들이 그렇지 않은 국가에서 제공되는 인터넷 컨텐츠를 몰래 찾아 보기 위해 VPN을 사용하기 시작했다. 특히 자유민주주의 국가라 VPN 사용 자체을 막으려는 시도에 대해 반론이 얼마든지 가능하고 폭압적인 정책을 만들 수 없는 현대 대한민국에서는 법률 상으로 개인의 VPN 사용에 제약이 거의 없어 대한민국 인터넷 사용자들이 해외 공용 VPN 서버 이용률 1위를 찍고 있다.

다만 이보다 검열이 비교도 안 되게 빡센 [[중화인민공화국|중국]]에서는 공산당 일당 독재 체제인 정부가 기어이 개인의 허가되지 않은 VPN 사용을 불법화하는 바람에 그 어마어마한 국가 인구에 비해 VPN 사용자가 적어 대한민국에 밀려 접속자 수 2위에 그치고 있다. 그 외의 강력한 인터넷 검열 시행 국가(예: 이란, 북한 등)는 아예 인터넷 접속이 가능한 단말기 자체가 국가 내에 거의 없어 인터넷 접속 자체가 매우 어렵기에 의외로 사용자 수가 매우 낮은 편. 여기는 최소 [[Tor]] 같은 더 강력한 우회 도구를 비롯하여 그런 도구를 사용했다는 사실을 숨길 수단까지 마련하여 도저히 잡을 수 없을 정도로 온갖 방법을 동원해 신원을 감춰야 간신히 인터넷을 몰래 할 수 있는 정도다.

주의할 것은 VPN 사용 시 접속할 중계 서버가 반드시 해외에 있으며, 수신자인 외국 사이트에 접근이 가능한 국가에 위치해 있어야 한다는 것이다. 국내 VPN 중계 서버는 이용해 봤자 말짱 꽝이고, 심지어 접속 로그 기록까지 남는다.

VPN

2025-08-05T14:17:06Z

Senouis: VPN 문서 생성

[[분류: 인터넷]]
[[분류: IT]]

'''VPN'''(Virtual Private Network, 가상 사설망)은 통신을 위해 네트워크 망으로 패킷을 보낼 때 정해진 암호화 프로토콜로 암호화해 특정한 컴퓨터만 자신이 보낸 정보를 받고 다시 응답할 수 있는 네트워크 기술이다.

VPN에 사용되는 암호화 프로토콜로는 L2TP, IPSec 등이 있으며 이들은 OSI 7계층 중 3계층에 있다. 1~3계층은 물리적인 하드웨어 단계에서 작동하는 패킷 처리 과정이라 소프트웨어로 어떻게 보고 바꾸기가 4계층 이상에서의 단계(인터넷으로 치면 [[IP]]부터 [[HTTP]]까지 계층 범위)에선 쉽지 않은 편이다.

다만 VPN은 중계 서버 역할을 하는 고성능 컴퓨터(또는 전용 라우터)가 필요하며 송신자가 중계 서버까지 데이터를 보내는 패킷만 암호화한다. 중계 서버에서 수신자에게 보내는 패킷은 TLS 등으로 소프트웨어적인 암호화가 필요하다. '''송신자는 중계 서버를 믿을 수 있는 특별한 컴퓨터'''로 보지만, '''수신자 입장에서 중계 서버는 그냥 평범한 컴퓨터(내지는 라우터)'''이기 때문이다. 그래서 수신자에게 패킷이 도착할 때까지 아무도 못 알아보게 상위 계층에서 추가로 암호화를 걸어야 하는 것.

== 용도 ==
=== 원래 개발 목적: 기업용 사설망 구축 및 [[재택근무]] 지원 ===
원래 VPN의 용도는 인터넷 접근이 가능한 회선에 패킷을 뿌리되 그 안의 특정 컴퓨터만 패킷을 받아 볼 수 있도록 암호화해서 유사 인트라넷처럼 통신이 이루어지게 하는 것이다. 괜히 이름이 '가상' 사설망이 아니다. 이 기술 덕분에 업무용 컴퓨터의 기본적인 보안(예: VPN 연결 유지, 다른 컴퓨터의 데이터 저장장치를 함부로 업무용 컴퓨터에 연결하지 않기, 정기적인 악성 소프트웨어 검사 등)만 개인이 잘 지키면 가정집에서 재택근무를 해도 기업의 기밀 사항이 새어나갈 구석이 없다. 원래부터 기업들이 보안을 위해 적절하게 사용하고 있었지만 [[코로나19]] 및 외국 취업 활동의 활성화로 인해 비대면 근무 상황이 늘어나며 VPN의 원래 개발 목적이 대중에게도 어느 정도 알려지게 되었다.

=== 의도치 않은 또 다른 기능: 정부의 인터넷 검열 우회 ===
그러나 여기서 '회사 내 다른 컴퓨터'를 '정부가 금지한 외국 사이트가 돌아가는 서버 컴퓨터', '회사 내 VPN 서버'를 '해외에 위치한 공용 VPN 중계 서버'로 대응하면 '''국내의 모든 컴퓨터와 라우터들이 3계층 단계의 암호화에서 막혀 내 데이터 요청 패킷을 볼 수 없는데''' 국내와 다른 법률을 적용 받는 '''해외 중계 서버 운용자는 이걸 받아도 문제가 없고''', 그러면서 정작 수신자인 외국 사이트 서버가 볼 때에는 '''해외에 소재한 평범한 컴퓨터가 접속한 것처럼 보이게 된다'''. 즉, 국내 정부의 정책에 따라 TLS/SSL을 써도 소용이 없을 정도로 IP~HTTP 단계에서 접근이 제한된 해외 사이트에 접속할 수 있는 '''강력한 검열 우회 수단'''이 된다.

이에 따라 인터넷 검열이 다소 심한 편인 국가들이 그렇지 않은 국가에서 제공되는 인터넷 컨텐츠를 몰래 찾아 보기 위해 VPN을 사용하기 시작했다. 특히 자유민주주의 국가라 VPN 사용 자체을 막으려는 시도에 대해 반론이 얼마든지 가능하고 폭압적인 정책을 만들 수 없는 현대 대한민국에서는 법률 상으로 개인의 VPN 사용에 제약이 거의 없어 대한민국 인터넷 사용자들이 해외 공용 VPN 서버 이용률 1위를 찍고 있다.

다만 이보다 검열이 비교도 안 되게 빡센 [[중화인민공화국|중국]]에서는 공산당 일당 독재 체제인 정부가 기어이 개인의 허가되지 않은 VPN 사용을 불법화하는 바람에 그 어마어마한 국가 인구에 비해 VPN 사용자가 적어 대한민국에 밀려 접속자 수 2위에 그치고 있다. 그 외의 강력한 인터넷 검열 시행 국가(예: 이란, 북한 등)는 아예 인터넷 접속이 가능한 단말기 자체가 국가 내에 거의 없어 인터넷 접속 자체가 매우 어렵기에 의외로 사용자 수가 매우 낮은 편. 여기는 최소 [[Tor]] 같은 더 강력한 우회 도구를 비롯하여 그런 도구를 사용했다는 사실을 숨길 수단까지 마련하여 도저히 잡을 수 없을 정도로 온갖 방법을 동원해 신원을 감춰야 간신히 인터넷을 몰래 할 수 있는 정도다.

주의할 것은 VPN 사용 시 접속할 중계 서버가 반드시 해외에 있으며, 수신자인 외국 사이트에 접근이 가능한 국가에 위치해 있어야 한다는 것이다. 국내 VPN 중계 서버는 이용해 봤자 말짱 꽝이고, 심지어 접속 로그 기록까지 남는다.

Apple

2025-08-05T13:32:42Z

Senouis: /* TMI */

Apple은 미국의 IT기기 제조업체이다. 1976년에 스티브 잡스와 스티브 워즈니악이 창립한 기업이다.

== 역사 ==
1976년 스티브 워즈니악이 디자인한 애플 I을 보고 워즈니악의 지인이 스티브 잡스를 합류시키면서 애플의 역사는 시작된다.<ref>다만 이떄는 이사회에 합류하지 않고 제품 기획을 주로 담당했다.</ref>

이후 Apple II가 발매되었고 독점적인 소프트웨어 공급 덕에 인기를 누리기 시작했다.

그러나 Apple III이 Apple II에 비해 개선된 점이 없고 단점만을 드러내자 점차 이사회가 스티브 잡스에게 엄청난 책임을 묻기 시작했고 이에 스티브 잡스는 내연녀였던 여성의 딸인 리사의 이름을 따서 애플 리사와 매킨토시를 기획하나 실패하고 모든 직무를 내려놓고 Apple을 나와 NeXT를 차리게 된다.

그러나 잡스를 쫓아낸 후에는 더욱 막장스러운 경영이 이루어졌다. 정확히는 새로운 CEO가 된 전 펩시코 사장 존 스컬리가 각종 사업을 정리하고 뉴턴 메세지 패드 등의 선구적인 제품을 기획했으나 시장에서 실패하는 바람에 물러났는데, 그 후임으로 들어온 마이클 스핀들러가 워낙 경영자 자질이 없었기 때문에 회사가 부도 직전까지 간 것.

결국 [[Microsoft Windows|윈도우]] 탑재 PC에 밀려 파산에 가까운 상태로 몰릴 대로 몰린 애플을 이끌게 된 길 아멜리오는 자사 컴퓨터의 운영체제에 문제가 있다고 생각하여 새로운 운영체제 도입을 계획했는데 마침 쫓겨났던 스티브 잡스의 NeXT에서 만든 운영체제가 채택되어 스티브 잡스가 애플로 귀환하게 된다.

돌아온 스티브 잡스는 드디어 CEO에 제대로 오르자마자 뉴턴 메세지 패드 개발팀을 제외하고 남은 사업을 정리하는 한편, 아이맥을 통해 인텔과 제휴하여 PowerPC 기반이던 맥 컴퓨터를 x86계열로 이주시켰고 아이팟과 아이튠즈를 내놓아 음원 시장에 충격을 주었다. 그리고 PDA보다 더욱 발전된 형태의 소형 전자기기를 계획하는데, 바로 아이폰이 되시겠다.

휴대폰을 완전히 재정의하다시피 한 아이폰과 뉴턴 메세지 패드 팀이 만든 아이패드를 통해 애플은 화려하게 부활하지만 곧 스티브 잡스의 사망이라는 악재를 얻게 된다.

하지만 스티브 잡스가 남긴 것이 워낙 많아서 그 후임으로 팀 쿡이 CEO가 된 이후에도 애플은 점점 성장해나가 시가 총액 1조달러를 달성한 초대형 기업이 된다.

== 제품 목록 ==
2021년 기준으로 소비자에게 팔리고 있는 제품군은 다음과 같다.

* [[iPod]]
* [[iPhone]]
* [[iPad]]
* [[Macbook]]
* [[EarPod]]
* [[iMac]] 및 [[iMac 프로]]
* [[Mac 프로]] 및 [[Mac Mini]]
* [[애플 TV]]
* [[애플 워치]]
* [[Safari]]

==TMI==
* 2020년 애플은 과거 매킨토시 컴퓨터가 [[PowerPC]]에서 [[x86]]으로 CPU 플랫폼을 옮긴 것처럼 [[x86]]에서 [[ARM]]으로 CPU를 바꿀 것이라고 선언하며 자체 제작 SoC 칩인 M1을 선보였다. M1의 압도적인 성능과 이미 PowerPC->x86으로 CPU 플랫폼 이전을 했던 작업에 대한 기술 및 노하우가 있기 때문에 조만간 맥 진영은 모든 제품군이 ARM CPU를 사용해 제품을 내놓을 것이라는 예측이 많다. 결국 후속작 M2 세대에서 마지막으로 맥 프로까지 애플의 자체 ARM 호환 CPU로 이주하면서 매킨토시 컴퓨터를 통해 ARM 데스크탑 PC 시대가 열렸다.

[[분류:IT]]
[[분류:미국의 기업]]

Apple

2025-08-05T13:32:10Z

Senouis: /* TMI */

Apple은 미국의 IT기기 제조업체이다. 1976년에 스티브 잡스와 스티브 워즈니악이 창립한 기업이다.

== 역사 ==
1976년 스티브 워즈니악이 디자인한 애플 I을 보고 워즈니악의 지인이 스티브 잡스를 합류시키면서 애플의 역사는 시작된다.<ref>다만 이떄는 이사회에 합류하지 않고 제품 기획을 주로 담당했다.</ref>

이후 Apple II가 발매되었고 독점적인 소프트웨어 공급 덕에 인기를 누리기 시작했다.

그러나 Apple III이 Apple II에 비해 개선된 점이 없고 단점만을 드러내자 점차 이사회가 스티브 잡스에게 엄청난 책임을 묻기 시작했고 이에 스티브 잡스는 내연녀였던 여성의 딸인 리사의 이름을 따서 애플 리사와 매킨토시를 기획하나 실패하고 모든 직무를 내려놓고 Apple을 나와 NeXT를 차리게 된다.

그러나 잡스를 쫓아낸 후에는 더욱 막장스러운 경영이 이루어졌다. 정확히는 새로운 CEO가 된 전 펩시코 사장 존 스컬리가 각종 사업을 정리하고 뉴턴 메세지 패드 등의 선구적인 제품을 기획했으나 시장에서 실패하는 바람에 물러났는데, 그 후임으로 들어온 마이클 스핀들러가 워낙 경영자 자질이 없었기 때문에 회사가 부도 직전까지 간 것.

결국 [[Microsoft Windows|윈도우]] 탑재 PC에 밀려 파산에 가까운 상태로 몰릴 대로 몰린 애플을 이끌게 된 길 아멜리오는 자사 컴퓨터의 운영체제에 문제가 있다고 생각하여 새로운 운영체제 도입을 계획했는데 마침 쫓겨났던 스티브 잡스의 NeXT에서 만든 운영체제가 채택되어 스티브 잡스가 애플로 귀환하게 된다.

돌아온 스티브 잡스는 드디어 CEO에 제대로 오르자마자 뉴턴 메세지 패드 개발팀을 제외하고 남은 사업을 정리하는 한편, 아이맥을 통해 인텔과 제휴하여 PowerPC 기반이던 맥 컴퓨터를 x86계열로 이주시켰고 아이팟과 아이튠즈를 내놓아 음원 시장에 충격을 주었다. 그리고 PDA보다 더욱 발전된 형태의 소형 전자기기를 계획하는데, 바로 아이폰이 되시겠다.

휴대폰을 완전히 재정의하다시피 한 아이폰과 뉴턴 메세지 패드 팀이 만든 아이패드를 통해 애플은 화려하게 부활하지만 곧 스티브 잡스의 사망이라는 악재를 얻게 된다.

하지만 스티브 잡스가 남긴 것이 워낙 많아서 그 후임으로 팀 쿡이 CEO가 된 이후에도 애플은 점점 성장해나가 시가 총액 1조달러를 달성한 초대형 기업이 된다.

== 제품 목록 ==
2021년 기준으로 소비자에게 팔리고 있는 제품군은 다음과 같다.

* [[iPod]]
* [[iPhone]]
* [[iPad]]
* [[Macbook]]
* [[EarPod]]
* [[iMac]] 및 [[iMac 프로]]
* [[Mac 프로]] 및 [[Mac Mini]]
* [[애플 TV]]
* [[애플 워치]]
* [[Safari]]

==TMI==
* 2020년 애플은 과거 매킨토시 컴퓨터가 [[PowerPC]]에서 [[x86]]으로 CPU 플랫폼을 옮긴 것처럼 [[x86]]에서 [[ARM]]으로 CPU를 바꿀 것이라고 선언하며 자체 제작 SoC 칩인 M1을 선보였다. M1의 압도적인 성능과 이미 PowerPC->x86으로 CPU 플랫폼 이전 성공 사례를 가지고 있기 때문에 조만간 맥 진영은 모든 제품군이 ARM CPU를 사용해 제품을 내놓을 것이라는 예측이 많다. 결국 후속작 M2 세대에서 마지막으로 맥 프로까지 애플의 자체 ARM 호환 CPU로 이주하면서 매킨토시 컴퓨터를 통해 ARM 데스크탑 PC 시대가 열렸다.

[[분류:IT]]
[[분류:미국의 기업]]

Wi-Fi

2025-08-05T13:29:00Z

Senouis: /* 대한민국과 와이파이 */

[[분류: IT]]
[[분류: 인터넷]]

'''Wi-Fi'''(와이파이)는 IEEE 802.11 통신 표준을 기반으로 Wi-Fi 얼라이언스에서 정의하는 무선 통신 규격이다.

== 역사와 특징 ==
1991년부터 개발되어 1997년 발표된 IEEE 802.11를 시작으로 그 개량형 형태로 무선 WLAN 통신 규격이 계속 개발되었는데, 당시에는 그저 무선랜 정도로만 호칭되다가 1999년부터 Wi-Fi라는 정식 명칭을 받았다. 이때 Wi-Fi에는 별 뜻 없이 부르기 좋은 이름을 붙였다는 황당한 작명 배경이 있다.

2007년 발표된 IEEE 802.11n에서 100Mbps 유선랜이 대부분인 21세기 가정용으로는 충분한 대역폭의 와이파이 규격이 확립되었으나, 반이중(Half-Duplex) 통신 특성에 더해 최대 40MHz에 불과한 주파수 채널 폭 등의 문제로 인해 더 통신 속도가 좋은 규격이 계속 개발되어 Wi-Fi 6(IEEE 802.11ax 기반)이 상용화되었으며, 2023년 현재 전이중(Full-Duplex) 통신으로의 개량을 목표로 한 Wi-Fi 7(IEEE 802.11be 기반)이 2024년 규격 확립을 목표로 개발 중이다.

주택가의 실내에서는 무선공유기(Wireless Router) 등의 와이파이 신호원(AP) 간의 간섭이 심해 신호를 주고받는 영역(커버리지, Coverage) 반경 5m를 넘어가기만 해도 종종 와이파이가 끊기는 일이 발생하지만 연결 기기가 적은 너른 곳에서는 100m 거리에서도 발신 신호를 감지할 수 있다. 타 무선 통신 규격 대비 고성능이기에 가정 내 PC는 물론이고 고성능 임베디드 기기부터 지하철 같은 대규모 무선 통신이 필요한 공공시설과 산업체까지 모두 와이파이 기반 무선 인터넷 서비스를 제공한다.

== IEEE 802.11 계열 표준 일람 ==
* 802.11: 다음 세대와의 구분을 위해 레거시 와이파이라고도 불린다. 최초라 그런지 최대 2Mbps 정도의 통신 속도를 나타내지만 이 당시에는 모뎀이 인터넷 접속에 쓰였다는 걸 감안하면 당대에는 고성능이었다.
* 802.11a / 802.11b: 1999년 발표된 개량형. a는 속도가 빠르나 5GHz 전파 대역으로 인해 커버리지가 좁으며 b는 2.4GHz라 상대적으로 자유로우나 속도는 느린 편이다. 최대 54Mbps(a)/11Mbps(b)의 속도로 통신 가능하다.
* 802.11g: b와 동일한 주파수 대역에 a 급의 통신 속도를 자랑하는 개량형.
* 802.11n: 최대 100Mbps의 통신 속도로 가정용으로 보통 쓰이는 100Mbps 유선LAN 인터넷의 대역폭을 완전히 감당 가능하다. 이때부터 Wi-Fi는 무선 통신 기능의 필수 탑재 사양이 되었으며 Wi-Fi 4라는 이명을 받았다.
* 802.11ac: 2013년 Wi-Fi 5라 불리며 통신 속도를 더 끌어올리기 위해 도입된 인기 규격. 위상배열 기능이 추가되었다. 속도가 크게 올라 Gbps 속도의 통신이 가능하며 저가형 공유기가 아니면 이제 Wi-Fi 4와 5는 같이 지원한다. 하지만 5GHz 주파수 단독 대역 사용이라는 단점이 있긴 하다.
* 802.11ax: Wi-Fi 6과 그 확장판 6E이다. 공공 장소나 야외 무대, 지하철 등 많은 전자기기가 존재하는 공간에서의 원활한 통신을 위해 개발되었다. 6과 6E의 주요 차이는 6GHz 주파수 대역 신규 지원 여부이다.
* 802.11be: Wi-Fi 7이라 불리며 실시간 양방향 통신을 위해 전이중 통신 규격으로 개량을 목표로 개발 중인 규격이다.

여기서부터는 부가 기술 표준이다.

* 802.11i: 와이파이의 보안에 관련된 중요한 기술이다. 기존 WEP 보안 인증이 허점이 있었기에 WPA 계열 등의 보안 통신 규격을 도입했다.
* 802.11r: Fast Roaming 기술로 이동하면서 자연스럽게 AP를 바꿔가며 인터넷 연결 상태를 유지하는 기술 표준이다.
* 802.11mc: [[사물인터넷]] 개념에 필수적인 실내 전자기기 위치 탐색(포지셔닝) 규격이다.
* 802.11ad: 와이기그라는 별도의 이름으로 불리다 2013년 Wi-Fi 규격에 통합되었다. 60GHz라는 고주파수 대역을 사용하여 속도는 빠르나 초고주파수 전파를 쓰는 만큼 회절성이 매우 약하여 커버리지 반경은 절망적이다. 보통 무선 허브 도킹스테이션에 사용한다.

== 대한민국과 와이파이 ==
대한민국에도 2000년대 들어 도입 요구가 나왔으나 통신사들이 자사의 전용 WAP 서비스 판매를 위해 휴대폰에 일부러 탑재를 방해하고 있었다. 그나마 노트북과 같이 업무용으로 쓸 목적으로는 상대적으로 와이파이 서비스에 접근이 쉬워 무선랜 PCMCIA 카드 등이 잘 팔렸다.

그러다 [[Apple]]의 iPhone을 필두로 스마트폰이 보급되기 시작할 때에야 와이파이가 휴대폰에 탑재되었고 802.11n 규격의 Wi-Fi를 지원하는 저가형 공유기가 다수 보급되며 대한민국에서도 전국 단위로 와이파이를 쓸 수 있게 되었다. 그러다 보니 [[스타벅스]] 등의 카페나 공공기관에서도 이용객에게 와이파이 서비스를 무료로 제공하는 정책을 실시했는데, 이 때문에 카페나 공공도서관에 가서 하루 종일 노트북 컴퓨터를 들여다보는 사람들(카공족 등)이 등장하였다.

그 외에 지하철에도 본래 관제실 - 전동차 간의 통신을 위해 깔아둔 통신 장치를 응용해 와이파이를 제공하기 시작했는데, 하필 LG U+만 SKT, KT와 달리 와이브로 서비스가 없었기 때문에 한동안 전동차 내에서 LG U+ 회선 이용자들만 불편을 겪었다고 한다. 다행히 LTE 기반으로 전동차 내 무선 통신 방식이 바뀌면서 LG U+가 공공 와이파이 서비스에 끼어드는 것도 모자라 오히려 서비스 제공 품질 측면에서 한동안 다른 두 통신사를 역전하는 일도 있었다.

Wi-Fi

2025-08-05T13:27:57Z

Senouis: /* 대한민국과 와이파이 */

[[분류: IT]]
[[분류: 인터넷]]

'''Wi-Fi'''(와이파이)는 IEEE 802.11 통신 표준을 기반으로 Wi-Fi 얼라이언스에서 정의하는 무선 통신 규격이다.

== 역사와 특징 ==
1991년부터 개발되어 1997년 발표된 IEEE 802.11를 시작으로 그 개량형 형태로 무선 WLAN 통신 규격이 계속 개발되었는데, 당시에는 그저 무선랜 정도로만 호칭되다가 1999년부터 Wi-Fi라는 정식 명칭을 받았다. 이때 Wi-Fi에는 별 뜻 없이 부르기 좋은 이름을 붙였다는 황당한 작명 배경이 있다.

2007년 발표된 IEEE 802.11n에서 100Mbps 유선랜이 대부분인 21세기 가정용으로는 충분한 대역폭의 와이파이 규격이 확립되었으나, 반이중(Half-Duplex) 통신 특성에 더해 최대 40MHz에 불과한 주파수 채널 폭 등의 문제로 인해 더 통신 속도가 좋은 규격이 계속 개발되어 Wi-Fi 6(IEEE 802.11ax 기반)이 상용화되었으며, 2023년 현재 전이중(Full-Duplex) 통신으로의 개량을 목표로 한 Wi-Fi 7(IEEE 802.11be 기반)이 2024년 규격 확립을 목표로 개발 중이다.

주택가의 실내에서는 무선공유기(Wireless Router) 등의 와이파이 신호원(AP) 간의 간섭이 심해 신호를 주고받는 영역(커버리지, Coverage) 반경 5m를 넘어가기만 해도 종종 와이파이가 끊기는 일이 발생하지만 연결 기기가 적은 너른 곳에서는 100m 거리에서도 발신 신호를 감지할 수 있다. 타 무선 통신 규격 대비 고성능이기에 가정 내 PC는 물론이고 고성능 임베디드 기기부터 지하철 같은 대규모 무선 통신이 필요한 공공시설과 산업체까지 모두 와이파이 기반 무선 인터넷 서비스를 제공한다.

== IEEE 802.11 계열 표준 일람 ==
* 802.11: 다음 세대와의 구분을 위해 레거시 와이파이라고도 불린다. 최초라 그런지 최대 2Mbps 정도의 통신 속도를 나타내지만 이 당시에는 모뎀이 인터넷 접속에 쓰였다는 걸 감안하면 당대에는 고성능이었다.
* 802.11a / 802.11b: 1999년 발표된 개량형. a는 속도가 빠르나 5GHz 전파 대역으로 인해 커버리지가 좁으며 b는 2.4GHz라 상대적으로 자유로우나 속도는 느린 편이다. 최대 54Mbps(a)/11Mbps(b)의 속도로 통신 가능하다.
* 802.11g: b와 동일한 주파수 대역에 a 급의 통신 속도를 자랑하는 개량형.
* 802.11n: 최대 100Mbps의 통신 속도로 가정용으로 보통 쓰이는 100Mbps 유선LAN 인터넷의 대역폭을 완전히 감당 가능하다. 이때부터 Wi-Fi는 무선 통신 기능의 필수 탑재 사양이 되었으며 Wi-Fi 4라는 이명을 받았다.
* 802.11ac: 2013년 Wi-Fi 5라 불리며 통신 속도를 더 끌어올리기 위해 도입된 인기 규격. 위상배열 기능이 추가되었다. 속도가 크게 올라 Gbps 속도의 통신이 가능하며 저가형 공유기가 아니면 이제 Wi-Fi 4와 5는 같이 지원한다. 하지만 5GHz 주파수 단독 대역 사용이라는 단점이 있긴 하다.
* 802.11ax: Wi-Fi 6과 그 확장판 6E이다. 공공 장소나 야외 무대, 지하철 등 많은 전자기기가 존재하는 공간에서의 원활한 통신을 위해 개발되었다. 6과 6E의 주요 차이는 6GHz 주파수 대역 신규 지원 여부이다.
* 802.11be: Wi-Fi 7이라 불리며 실시간 양방향 통신을 위해 전이중 통신 규격으로 개량을 목표로 개발 중인 규격이다.

여기서부터는 부가 기술 표준이다.

* 802.11i: 와이파이의 보안에 관련된 중요한 기술이다. 기존 WEP 보안 인증이 허점이 있었기에 WPA 계열 등의 보안 통신 규격을 도입했다.
* 802.11r: Fast Roaming 기술로 이동하면서 자연스럽게 AP를 바꿔가며 인터넷 연결 상태를 유지하는 기술 표준이다.
* 802.11mc: [[사물인터넷]] 개념에 필수적인 실내 전자기기 위치 탐색(포지셔닝) 규격이다.
* 802.11ad: 와이기그라는 별도의 이름으로 불리다 2013년 Wi-Fi 규격에 통합되었다. 60GHz라는 고주파수 대역을 사용하여 속도는 빠르나 초고주파수 전파를 쓰는 만큼 회절성이 매우 약하여 커버리지 반경은 절망적이다. 보통 무선 허브 도킹스테이션에 사용한다.

== 대한민국과 와이파이 ==
대한민국에도 2000년대 들어 도입 요구가 나왔으나 통신사들이 자사의 전용 WAP 서비스 판매를 위해 휴대폰에 일부러 탑재를 방해하고 있었다. 그나마 노트북과 같이 업무용으로 쓸 목적으로는 상대적으로 와이파이 서비스에 접근이 쉬워 무선랜 PCMCIA 카드 등이 잘 팔렸다.

그러다 [[Apple]]의 iPhone을 필두로 스마트폰이 보급되기 시작할 때에야 와이파이가 휴대폰에 탑재되었고 802.11n 규격의 공유기가 보급되며 대한민국에서도 와이파이를 쓸 수 있게 되었다. 그러다보니 [[스타벅스]] 등의 카페나 공공기관에서도 이용객에게 와이파이 서비스를 무료로 제공하는 정책을 실시했는데, 이 때문에 카페나 공공도서관에 가서 하루 종일 노트북 컴퓨터를 들여다보는 사람들(카공족 등)이 등장하였다.

그 외에 지하철에도 본래 관제실 - 전동차 간의 통신을 위해 깔아둔 통신 장치를 응용해 와이파이를 제공하기 시작했는데, 하필 LG U+만 SKT, KT와 달리 와이브로 서비스가 없었기 때문에 한동안 전동차 내에서 LG U+ 회선 이용자들만 불편을 겪었다고 한다. 다행히 LTE 기반으로 전동차 내 무선 통신 방식이 바뀌면서 LG U+가 공공 와이파이 서비스에 끼어드는 것도 모자라 오히려 서비스 제공 품질 측면에서 한동안 다른 두 통신사를 역전하는 일도 있었다.

Wi-Fi

2025-08-05T13:27:28Z

Senouis: /* IEEE 802.11 계열 표준 일람 */

[[분류: IT]]
[[분류: 인터넷]]

'''Wi-Fi'''(와이파이)는 IEEE 802.11 통신 표준을 기반으로 Wi-Fi 얼라이언스에서 정의하는 무선 통신 규격이다.

== 역사와 특징 ==
1991년부터 개발되어 1997년 발표된 IEEE 802.11를 시작으로 그 개량형 형태로 무선 WLAN 통신 규격이 계속 개발되었는데, 당시에는 그저 무선랜 정도로만 호칭되다가 1999년부터 Wi-Fi라는 정식 명칭을 받았다. 이때 Wi-Fi에는 별 뜻 없이 부르기 좋은 이름을 붙였다는 황당한 작명 배경이 있다.

2007년 발표된 IEEE 802.11n에서 100Mbps 유선랜이 대부분인 21세기 가정용으로는 충분한 대역폭의 와이파이 규격이 확립되었으나, 반이중(Half-Duplex) 통신 특성에 더해 최대 40MHz에 불과한 주파수 채널 폭 등의 문제로 인해 더 통신 속도가 좋은 규격이 계속 개발되어 Wi-Fi 6(IEEE 802.11ax 기반)이 상용화되었으며, 2023년 현재 전이중(Full-Duplex) 통신으로의 개량을 목표로 한 Wi-Fi 7(IEEE 802.11be 기반)이 2024년 규격 확립을 목표로 개발 중이다.

주택가의 실내에서는 무선공유기(Wireless Router) 등의 와이파이 신호원(AP) 간의 간섭이 심해 신호를 주고받는 영역(커버리지, Coverage) 반경 5m를 넘어가기만 해도 종종 와이파이가 끊기는 일이 발생하지만 연결 기기가 적은 너른 곳에서는 100m 거리에서도 발신 신호를 감지할 수 있다. 타 무선 통신 규격 대비 고성능이기에 가정 내 PC는 물론이고 고성능 임베디드 기기부터 지하철 같은 대규모 무선 통신이 필요한 공공시설과 산업체까지 모두 와이파이 기반 무선 인터넷 서비스를 제공한다.

== IEEE 802.11 계열 표준 일람 ==
* 802.11: 다음 세대와의 구분을 위해 레거시 와이파이라고도 불린다. 최초라 그런지 최대 2Mbps 정도의 통신 속도를 나타내지만 이 당시에는 모뎀이 인터넷 접속에 쓰였다는 걸 감안하면 당대에는 고성능이었다.
* 802.11a / 802.11b: 1999년 발표된 개량형. a는 속도가 빠르나 5GHz 전파 대역으로 인해 커버리지가 좁으며 b는 2.4GHz라 상대적으로 자유로우나 속도는 느린 편이다. 최대 54Mbps(a)/11Mbps(b)의 속도로 통신 가능하다.
* 802.11g: b와 동일한 주파수 대역에 a 급의 통신 속도를 자랑하는 개량형.
* 802.11n: 최대 100Mbps의 통신 속도로 가정용으로 보통 쓰이는 100Mbps 유선LAN 인터넷의 대역폭을 완전히 감당 가능하다. 이때부터 Wi-Fi는 무선 통신 기능의 필수 탑재 사양이 되었으며 Wi-Fi 4라는 이명을 받았다.
* 802.11ac: 2013년 Wi-Fi 5라 불리며 통신 속도를 더 끌어올리기 위해 도입된 인기 규격. 위상배열 기능이 추가되었다. 속도가 크게 올라 Gbps 속도의 통신이 가능하며 저가형 공유기가 아니면 이제 Wi-Fi 4와 5는 같이 지원한다. 하지만 5GHz 주파수 단독 대역 사용이라는 단점이 있긴 하다.
* 802.11ax: Wi-Fi 6과 그 확장판 6E이다. 공공 장소나 야외 무대, 지하철 등 많은 전자기기가 존재하는 공간에서의 원활한 통신을 위해 개발되었다. 6과 6E의 주요 차이는 6GHz 주파수 대역 신규 지원 여부이다.
* 802.11be: Wi-Fi 7이라 불리며 실시간 양방향 통신을 위해 전이중 통신 규격으로 개량을 목표로 개발 중인 규격이다.

여기서부터는 부가 기술 표준이다.

* 802.11i: 와이파이의 보안에 관련된 중요한 기술이다. 기존 WEP 보안 인증이 허점이 있었기에 WPA 계열 등의 보안 통신 규격을 도입했다.
* 802.11r: Fast Roaming 기술로 이동하면서 자연스럽게 AP를 바꿔가며 인터넷 연결 상태를 유지하는 기술 표준이다.
* 802.11mc: [[사물인터넷]] 개념에 필수적인 실내 전자기기 위치 탐색(포지셔닝) 규격이다.
* 802.11ad: 와이기그라는 별도의 이름으로 불리다 2013년 Wi-Fi 규격에 통합되었다. 60GHz라는 고주파수 대역을 사용하여 속도는 빠르나 초고주파수 전파를 쓰는 만큼 회절성이 매우 약하여 커버리지 반경은 절망적이다. 보통 무선 허브 도킹스테이션에 사용한다.

== 대한민국과 와이파이 ==
대한민국에도 2000년대 들어 도입 요구가 나왔으나 통신사들이 자사의 전용 WAP 서비스 판매를 위해 휴대폰에 일부러 탑재를 방해하고 있었다. 그나마 노트북과 같이 업무용으로 쓸 목적으로는 상대적으로 와이파이 서비스에 접근이 쉬워 무선랜 지원 PCMCIA 카드 등이 팔렸다.

그러다 [[Apple]]의 iPhone을 필두로 스마트폰이 보급되기 시작할 때에야 와이파이가 휴대폰에 탑재되었고 802.11n 규격의 공유기가 보급되며 대한민국에서도 와이파이를 쓸 수 있게 되었다. 그러다보니 [[스타벅스]] 등의 카페나 공공기관에서도 이용객에게 와이파이 서비스를 무료로 제공하는 정책을 실시했는데, 이 때문에 카페나 공공도서관에 가서 하루 종일 노트북 컴퓨터를 들여다보는 사람들(카공족 등)이 등장하였다.

그 외에 지하철에도 본래 관제실 - 전동차 간의 통신을 위해 깔아둔 통신 장치를 응용해 와이파이를 제공하기 시작했는데, 하필 LG U+만 SKT, KT와 달리 와이브로 서비스가 없었기 때문에 한동안 전동차 내에서 LG U+ 회선 이용자들만 불편을 겪었다고 한다. 다행히 LTE 기반으로 전동차 내 무선 통신 방식이 바뀌면서 LG U+가 공공 와이파이 서비스에 끼어드는 것도 모자라 오히려 서비스 제공 품질 측면에서 한동안 다른 두 통신사를 역전하는 일도 있었다.

ARP

2025-08-05T13:22:01Z

Senouis: ARP 스푸핑 및 대처법 추가

[[분류: 인터넷]]

'''ARP'''(Address Resolution Protocol)은 RFC 826의 규격에 따라 IP 주소를 보내어 통신을 하고자 하는 상대방의 MAC 주소를 알아오는 프로토콜이다.

송신자가 ARP Request 구조(송신자의 물리 주소, 송신자 IP주소, 00-00-00-00-00, 수신자 IP 주소 등)를 브로드캐스트 방식으로 보내면 수신자가 ARP Reply 구조로 유니캐스트 방식으로 응답하여 MAC 주소를 받으면 패킷을 교환할 경로를 인식할 수 있다.

ARP 패킷은 네트워크 접속 전 반드시 보내야 하는 패킷이기 때문에 만약 ARP 패킷을 보내는 중간에 누군가 패킷을 가로채셔 자신이 IP 주소 소유자라고 속이면 송신자 입장에서 알 방법이 없다. 이런 유형의 해킹 기법을 '''ARP 스푸핑'''(ARP Spoofing)이라고 하지만, 전역 네트워크인 WAN이 아닌 LAN 단계에서 라우터(또는 인터넷 공유기)나 상대 컴퓨터에 패킷이 도착하기도 전에 가로채야만 성공할 수 있는 근거리 공격이라는 한계가 있다.

예를 들어 평범한 [[Wi-Fi|무선공유기]]로 인터넷을 할 때 ARP 스푸핑을 하려면 무려 공유기에 패킷을 담은 신호 전파가 도착하여 응답하기도 전에 다른 컴퓨터/공유기로 가로채야 하고, 유선 인터넷이면 통신사가 동네 어딘가 설치한 집 근처 라우터보다 더 가까운 거리에서 패킷을 가로채고 응답해야 한다. 그래서 일반 가정집을 상대로 이런 공격을 하기엔 난이도가 하늘을 찌른다.

그래서 보통 ARP 스푸핑을 당했다고 하면 공공장소의 Wi-Fi 존으로 위장한 공격용 장치에 대신 연결된 경우거나, 주로 높은 가치의 데이터들이 모여있는 [[데이터센터]]에 물리적으로 침투해서 스푸핑을 위한 장치를 어딘가 숨겨두거나 데이터센터 내에 악성 소프트웨어에 감염된 다른 컴퓨터(혹은 재택근무를 시행한다고 아무 생각 없이 인터넷에 회사 사설망을 노출시킨 <s>무개념 직원의</s> 컴퓨터인 경우)가 자신이 라우터인 것처럼 속이는 형태로 성공시키는 경우가 많다. 그마저도 실제 공격 성공으로 이어지기는 다른 유형의 해킹에 비해 힘든 편이다.

이에 대한 주요 대처법으로는 ARP 테이블을 정해진 MAC을 가진 컴퓨터의 응답만 받도록 고정하거나, <s>약속된 승리의</s> [[VPN]]으로 패킷을 암호화해 원하는 상대 컴퓨터만 알아볼 수 있게 처리하는 것이 있다.

== ARP 패킷 구조==
Ethernet Layer 2 Packet 기준 Data 부분에 다음 형태의 데이터가 들어간다. IPv4 기준이고, 송수신자가 서로의 정보만 맞바꾼 동일한 구조의 패킷으로 통신한다.

{| class="wikitable" style="text-align:center;"
|+ ARP 패킷 데이터그램의 구조
|-
| colspan="2" | Hardware Type(16bit, 이더넷의 경우 1) || Protocol Type(16bit, IPv4의 경우 0x0800)
|-
| Hardware Length(8bit) || Protocol Length(8bit) || Operation(16bit, ARP Request는 1, ARP Reply는 2)
|-
| colspan="3" | Sender MAC Address(32bit)
|-
| colspan="3" | Sender IP Address(32bit)
|-
| colspan="3" | Receiver MAC Address(32bit, ARP Request의 경우 이 부분을 0으로 채운다)
|-
| colspan="3" | Receiver IP Address(32bit)
|}

ARP

2025-08-05T13:18:18Z

Senouis: ARP Spoofing 및 대처법 추가

[[분류: 인터넷]]

'''ARP'''(Address Resolution Protocol)은 RFC 826의 규격에 따라 IP 주소를 보내어 통신을 하고자 하는 상대방의 MAC 주소를 알아오는 프로토콜이다.

송신자가 ARP Request 구조(송신자의 물리 주소, 송신자 IP주소, 00-00-00-00-00, 수신자 IP 주소 등)를 브로드캐스트 방식으로 보내면 수신자가 ARP Reply 구조로 유니캐스트 방식으로 응답하여 MAC 주소를 받으면 패킷을 교환할 경로를 인식할 수 있다.

ARP 패킷은 네트워크 접속 전 반드시 보내야 하는 패킷이기 때문에 만약 ARP 패킷을 보내는 중간에 누군가 패킷을 가로채셔 자신이 IP 주소 소유자라고 속이면 송신자 입장에서 알 방법이 없다. 이런 유형의 해킹 기법을 '''ARP 스푸핑'''(ARP Spoofing)이라고 하지만, 전역 네트워크인 WAN이 아닌 LAN 단계에서 라우터(또는 인터넷 공유기)나 상대 컴퓨터에 패킷이 도착하기도 전에 가로채야만 성공할 수 있는 근거리 공격이라는 한계가 있다.

예를 들어 평범한 [[Wi-Fi|무선공유기]]로 인터넷을 할 때 ARP 스푸핑을 하려면 무려 공유기에 패킷을 담은 신호 전파가 도착하여 응답하기도 전에 다른 컴퓨터/공유기로 가로채야 하고, 유선 인터넷이면 통신사가 동네 어딘가 설치한 집 근처 라우터보다 더 가까운 거리에서 패킷을 가로채고 응답해야 한다. 그래서 일반 대중을 상대로 이런 공격을 하기엔 난이도가 하늘을 찌르므로 보통 ARP 스푸핑을 당했다고 하면 주로 높은 가치의 데이터들이 모여있는 [[데이터센터]]에 물리적으로 침투해서 스푸핑을 위한 장치를 어딘가 숨겨두거나 데이터센터 내에 악성 소프트웨어에 감염된 다른 컴퓨터(혹은 재택근무를 시행한다고 아무 생각 없이 인터넷에 회사 사설망이 노출된 <s>무개념</s> 상황인 경우)가 자신이 라우터인 것처럼 속이는 형태로 성공시키는 경우가 많다. 그마저도 실제 공격 성공으로 이어지기는 다른 유형의 해킹에 비해 힘든 편이다.

이에 대한 대처법으로는 ARP 테이블을 정해진 MAC을 가진 컴퓨터의 응답만 받도록 고정하거나, <s>약속된 승리의</s> [[VPN]]으로 패킷을 암호화해 원하는 상대 컴퓨터만 알아볼 수 있게 처리하는 것이 있다.

== ARP 패킷 구조==
Ethernet Layer 2 Packet 기준 Data 부분에 다음 형태의 데이터가 들어간다. IPv4 기준이고, 송수신자가 서로의 정보만 맞바꾼 동일한 구조의 패킷으로 통신한다.

{| class="wikitable" style="text-align:center;"
|+ ARP 패킷 데이터그램의 구조
|-
| colspan="2" | Hardware Type(16bit, 이더넷의 경우 1) || Protocol Type(16bit, IPv4의 경우 0x0800)
|-
| Hardware Length(8bit) || Protocol Length(8bit) || Operation(16bit, ARP Request는 1, ARP Reply는 2)
|-
| colspan="3" | Sender MAC Address(32bit)
|-
| colspan="3" | Sender IP Address(32bit)
|-
| colspan="3" | Receiver MAC Address(32bit, ARP Request의 경우 이 부분을 0으로 채운다)
|-
| colspan="3" | Receiver IP Address(32bit)
|}

NVIDIA

2025-06-26T11:37:47Z

Senouis: /* CUDA와 GPGPU */

'''NVIDIA''' 또는 엔비디아는 1993년 젠슨 황에 의해 창립된 그래픽 칩셋(GPU) 제조 회사이다.

2023년 5월 30일에 반도체 집적회로 제품 전문 설계 및 제작사로서 최초로 나스닥 시가총액 1조 달러를 돌파한 기업으로, 외장 그래픽 카드 제조업계와 신경망 기반 AI 개발업계, 자율주행 차량 설계업계에서 시장 지배적인 위치에 있는 국제적 규모의 대기업이다.
==역사==
1993년에 혜성처럼 나타난 NVIDIA는 1990년대 말에 내놓은 RIVA시리즈로 당시 3D 그래픽 가속 카드의 제왕이던 3dfx를 제압하여 몰락시키고 2002년에 파산시킨다.

이때 덤으로 S3 그래픽스와 PowerVR이 나가떨어지고 창립 10년만에 NVIDIA는 [[그래픽 카드]] 칩셋 시장을 장악하게 된다.

이후 다른 그래픽 칩셋 제조회사를 거의 다 인수한 ATI와 20년 가까이 경쟁하고 있으며 지포스 FX 시리즈와 GTX 400시리즈를 내놓은 때를 제외하면 항상 ATI(현 [[AMD]] Radeon Technology Group)와의 경쟁에서 우위를 점하고 있다.

===CUDA와 GPGPU ===

2008년부터 CUDA라는 병렬 연산용 라이브러리를 만들고 학계에 어필하면서 [[인공지능|신경망 AI]]에 사용할 수 있도록 투자를 많이 했는데 2022년 하반기부터 신경망 AI 기반 생성형 AI 붐이 불면서 무지막지한 떡상을 하여 고부가가치 사업이 아닌 엄연한 제조업체임에도 시가총액에서 [[페이스북]]을 능가하고 [[구글]]을 추격하는 등 엄청난 떡상을 하였다. 그래서 엔비디아에서 만드는 개발용 보드인 젯슨(Jetson) 시리즈도 그래픽 성능이 높은 특이한 ARM 기반 SBC 취급 받던 초기와 달리 지금은 임베디드 인공지능 기기 개발과 자율주행 서비스 개발의 필수품 취급을 받고 있다.

== 특징 ==
NVIDIA는 팹리스 회사로, GPU의 설계만 하고 실물 제작은 [[TSMC]] 같은 반도체 부품 제조회사에 맡긴다. 이는 반대로 독점 생산을 기획했던 3dfx를 몰락시킨 방법이기도 하다.<ref>참고로 ATI는 3dfx 망하는 꼴을 보고 레퍼런스 그래픽 카드 제조 사업부를 사실상 분리하게 되는데, 이로 인해 세워진 회사가 지금도 라데온 그래픽 카드만 전문적으로 생산하여 평이 좋은 사파이어 사다.</ref>

B2C 시장에서는 게이머들과 게임 제작사들과의 협력을 통해 독점적인 PC 그래픽 카드 솔루션을 구축했으나 B2B 시장에서는 온갖 갑질과 계약 파탄으로 인해 이미지가 좋지 않다.<ref>반대로 AMD는 애플과의 관계가 좋고 콘솔 게임기 제작사에 핵심 부품을 납품하는 등 B2B 커스텀 그래픽 칩셋 시장에서 두각을 드러내고 있다.</ref> 하지만 NVIDIA 제품의 성능이 뛰어나고 [[CUDA]]의 보급 등 시장 선점 능력이 좋다보니 엄청난 연산력을 필요로 하는 데이터센터 등지에서는 어쩔 수 없이 NVIDIA의 GPU를 사용하고 있다.

최근에는 자율주행 자동차, 인공신경망 연구 등 사업을 다각화하고 있다. 둘 다 성과가 좋아 자율 주행 차량용 칩셋은 대부분 엔비디아제이며, 2022년부터 [[ChatGPT]]와 [[NovelAI]] 이미지 제너레이터로 데이터 생성 AI에 대한 관심이 높아지며 엔비디아의 GPU가 AI 연구 개발 용도로 엄청나게 팔리고 있다.

최근에는 [[ARM]] Holdings를 인수하여 자체 CPU 개발력을 확보하려고 시도하고 있으나 전술한 B2B 시장에서의 악명 때문에 인수가 늦어지다가 결국 엔비디아가 인수를 포기하게 되었다고 한다.

==제품군==
* NV1과 NV2, RIVA 시리즈: 창업 후 초기에 개발하던 그래픽 카드 명칭
* [[Geforce 시리즈]] : 일반 사용자용 그래픽 카드. 실시간 레이트레이싱 지원 유무에 따라 Geforce RTX와 Geforce GTX로 나뉜다.
* RTX 시리즈: 2020년부터 아래 두 브랜드가 RTX 시리즈라는 이름으로 병합되었다.
** Quadro 시리즈: 그래픽 디자인 전문가용 그래픽 카드다.
** Tesla 시리즈: 데이터센터용 그래픽 카드다.
* nForce 시리즈: AMD CPU용 메인보드 칩셋, 현재는 단종되었다.
* Tegra 시리즈: 엔비디아에서 만든 [[ARM]] 호환 [[CPU]]이다.
* Geforce NOW™: 엔비디아의 클라우드 게이밍 플랫폼이다.

[[분류:IT]]
[[분류: 미국의 기업]]

도커

2025-06-07T14:40:14Z

Senouis: /* 기타 */

{{소프트웨어 정보
| 이름 = 도커 Docker
| 로고 = Docker (container engine) logo.svg
| 원작자 = 솔로몬 하익스 (Solomon Hykes)
| 개발자 = [[도커 (기업)|도커(Docker Inc.)]]
| 발표일 =
| 최신 버전 출시일 =
| 프로그래밍 언어 = [[Go (프로그래밍 언어)|Go]]<ref>{{웹 인용|url=https://github.com/docker/distribution |title=Docker source code |work=docs.docker.com |publisher=Docker, Inc. |date=2015-10-12 |accessdate=2015-10-24}}</ref>
| 운영체제 = [[리눅스]], [[마이크로소프트 윈도우|윈도우]], [[macOS]]
| 플랫폼 = 현대의 리눅스 커널이 포함된 [[x86-64]], [[ARM 아키텍처|ARM]] (실험적), 하이퍼-V 기능이 포함된 [[x86-64]] 윈도우
| 종류 = [[운영 체제 수준 가상화]]
| 라이선스 = [[아파치 라이선스]] 2.0
| 웹사이트 = {{URL|https://www.docker.com/}}
}}
'''도커'''(Docker)는 [[리눅스]]의 [[응용 소프트웨어|응용 프로그램]]들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 [[오픈 소스]] 프로젝트이다.

도커 웹 페이지의 기능을 인용하면 다음과 같다:
{{인용문|도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다.<ref>https://www.docker.com/what-docker</ref>}}

도커는 [[리눅스]]에서 [[운영 체제 수준 가상화]]의 추상화 및 자동화 계층을 추가적으로 제공한다.<ref name="SYS-CON Media">{{웹 인용
| last = O'Gara
| first = Maureen
| date = 26 July 2013
| url = http://maureenogara.sys-con.com/node/2747331
| title = Ben Golub, Who Sold Gluster to Red Hat, Now Running dotCloud
| publisher = SYS-CON Media
| accessdate = 2013-08-09
| archive-date = 2019-09-13
| archive-url = https://web.archive.org/web/20190913100835/http://maureenogara.sys-con.com/node/2747331

}}</ref> 도커는 [[cgroups]]와 커널 [[리눅스 이름공간|이름공간]]과 같은 [[리눅스 커널]]의 기능들과 OverayFS, [[aufs]]와 같은 [[유니언 마운트|유니언 가능 파일 시스템]]의 리소스 격리 기능을 사용하며,<ref>{{웹 인용|title = docker/docker|url = https://github.com/docker/docker/blob/990a3e30fa66e7bd3df3c78c873c97c5b1310486/daemon/graphdriver/driver.go#L37-L43|website = GitHub|accessdate = 2015-12-29}}</ref> 이를 통해 독립적인 "컨테이너"가 하나의 리눅스 인스턴스 안에서 실행할 수 있게 함으로써 [[가상 머신]]을 시작하여 유지보수해야 하는 부담을 없애준다.<ref>{{웹 인용
| url = http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| archiveurl = https://web.archive.org/web/20140821065734/http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| title = Docker Documentation: Kernel Requirements
| date = 2014-01-04 | accessdate = 2014-08-20 | archivedate = 2014-08-21
| website = docker.readthedocs.org
}}</ref>

리눅스 커널의 이름공간 지원은 대체적으로<ref>{{웹 인용|url=http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/|title=Yet Another Reason Containers Don't Contain: Kernel Keyrings|author=Dan Walsh|work=projectatomic.io|accessdate=13 April 2015|archive-date=2015-04-13|archive-url=https://web.archive.org/web/20150413062633/http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/}}</ref> 프로세스 트리, 네트워크 사용자 ID, 마운트된 파일 시스템을 포함한 운영 환경에 대한 응용 프로그램의 관점을 격리시키지만, 커널의 cgroup들은 CPU, 메모리, 블록 입출력, 네트워크를 포함한 리소스 제한을 제공한다. 버전 0.9부터 도커는 [[libvirt]], [[LXC]] (리눅스 컨테이너), [[systemd-nspawn]]을 통한 추상화된 가상화 인터페이스를 사용하는 것 뿐 아니라 리눅스 커널이 제공하는 가상화 기능을 직접 사용하기 위한 유일한 수단으로 libcontainer [[라이브러리 (컴퓨팅)|라이브러리]]를 포함하고 있다.<ref name="zdnet-7000030397">{{웹 인용
| url = http://www.zdnet.com/docker-libcontainer-unifies-linux-container-powers-7000030397/
| title = Docker libcontainer unifies Linux container powers
| date = 2014-06-11 | accessdate = 2014-07-30
| author = Steven J. Vaughan-Nichols | publisher = [[ZDNet]]
}}</ref><ref>{{웹 인용
| url = https://github.com/docker/libcontainer/blob/master/README.md
| title = libcontainer - reference implementation for containers
| accessdate = 2014-07-30
| website = github.com
}}</ref><ref name="docker-blog-201403">{{웹 인용
| url = http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
| title = Docker 0.9: Introducing execution drivers and libcontainer
| date = 2014-03-10
| accessdate = 2015-01-20
| website = docker.com
| archive-date = 2015-02-21
| archive-url = https://web.archive.org/web/20150221134532/http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
}}</ref>

== 개요 ==
[[파일:Docker-linux-interfaces.svg|섬네일|도커는 리눅스 커널의 가상화 기능에 접근하기 위해 각기 다른 인터페이스를 사용할 수 있다.<ref name="docker-blog-201403" />]]

도커 베이스 이미지에 액션을 취하면, 유니언 파일 시스템 계층들이 만들어지고 문서화되는데, 이렇게 함으로써 각 계층은 어떻게 액션을 재생성할지에 대해 완전하게 기술하게 된다. 이러한 전략은 이를테면 완전한 VM과 비교하면 도커의 이미지를 가볍게 만들어주며, 오직 레이어 업데이트만 전파해 주면 된다.

산업 애널리스트 기업 451 리서치에 따르면, "도커는 응용 프로그램과 그 의존성을 가상 컨테이너에 담을 수 있는 도구이며, 이 컨테이너는 어떠한 리눅스 서버에서라도 구동이 가능하다. 이것은 [[사내 소프트웨어|사내]], [[클라우드 컴퓨팅|공용 클라우드]], [[클라우드 컴퓨팅|개인 클라우드]], [[베어 메탈 서버|베어 메탈]] 등 응용 프로그램을 실행할 수 있는 곳에서는 유연성과 이식성을 적용하는데 도움을 준다.<ref name="Linux">{{웹 인용
| last = Noyes
| first = Katherine
| date = 1 August 2013
| url = http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code
| title = Docker: A 'Shipping Container' for Linux Code
| publisher = [[Linux.com]]
| accessdate = 2013-08-09
| 보존url = https://web.archive.org/web/20130808043357/http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code/
| 보존날짜 = 2013-08-08
}}</ref>

도커는 고급 [[API]]를 구현함으로써 프로세스들을 별도의 장소에서 실행할 수 있는 가벼운 컨테이너들을 제공한다.<ref name="infoq-201303">{{웹 인용
| last = Avram
| first = Abel
| date = 2013-03-27
| url = http://www.infoq.com/news/2013/03/Docker
| title = Docker: Automated and Consistent Software Deployments
| publisher = InfoQ
| accessdate = 2013-08-09
}}</ref>

[[리눅스 커널]]이 제공하는 기능들(주로 cgroups와 이름공간) 위에 빌드되기 때문에 도커 컨테이너는 가상 머신과는 달리 별도의 운영 체제를 요구하거나 포함하지 않는다.<ref name="Linux" /> 그 대신, 커널의 기능에 의존하며 리소스 격리(CPU, 메모리, 블록 입출력, 네트워크 등) 및 [[이름공간 격리|격리된 이름공간]]을 사용하여 운영 체제에 대한 응용 프로그램의 관점을 격리시킨다. 도커는 도커 0.9대부터 이용 가능한 libcontainer 라이브러리를 사용하거나 [[libvirt]], [[LXC]] (리눅스 컨테이너), 또는 [[systemd-nspawn]]을 통해 간접적으로 리눅스 커널의 가상화 기능들에 접근한다.<ref name="docker-blog-201403" /><ref name="infoq-201403">{{웹 인용
| last = Swan
| first = Chris
| date = 2014-03-13
| url = http://www.infoq.com/news/2014/03/docker_0_9
| title = Docker drops LXC as default execution environment
| publisher = InfoQ
| accessdate = 2015-01-20
}}</ref>

도커는 매우 가볍기 때문에, 하나의 서버나 가상 머신이 여러 컨테이너들을 동시에 구동할 수 있다.

컨테이너를 사용하여 리소스를 격리시키고, 서비스를 제한시키며, 프로세스를 예비할 수 있으며 이렇게 하여 자신만의 프로세스 ID 공간, 파일 시스템 구조, 네트워크 인터페이스를 갖고서 운영 체제에 대하여 거의 완전히 개인화된 관점을 갖게 한다. 여러 개의 컨테이너들은 동일한 커널은 공유하지만 각 컨테이너는 CPU, 메모리, 입출력과 같이 오직 정의된 양의 리소스에만 제한을 받을 수 있다.

도커를 사용하여 컨테이너를 만들고 관리하면 다수의 응용 프로그램, 작업자의 작업, 다른 프로세스들이 자율적으로 하나의 물리 머신이나 여러 개의 가상 머신을 통해 구동될 수 있게 되므로 고도의 [[분산 시스템]]을 생성하는 일이 단순해진다. 리소스가 사용 가능해질 때 또는 더 많은 노드가 필요할 때 노드가 배치될 수 있게 하므로 [[Apache Cassandra]], [[몽고DB]], [[Riak]]와 같은 시스템을 위한 [[PaaS]] 스타일의 배치 및 규모 증강이 가능해진다. 또, 도커는 작업이나 워크로드 큐, 기타 분산 시스템들의 생성 및 운영을 단순하게 한다.<ref name="CloudAve">{{웹 인용
| last = Hall
| first = Adron
| date = 31 July 2013
| url = http://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
| title = OSCON : Conversations, Deployments, Architecture, Docker and the Future?
| publisher = CloudAve
| accessdate = 2013-08-09
| archive-date = 2019-03-27
| archive-url = https://web.archive.org/web/20190327103543/https://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
}}</ref><ref name="Iron.io">{{웹 인용
|last = Reeder
|first = Travis
|date = 22 April 2014
|url = http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|title = How Docker Helped Us Achieve the (Near) Impossible
|publisher = Iron.io
|accessdate = 2014-07-25
|보존url = https://web.archive.org/web/20140808031809/http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|보존날짜 = 2014-08-08
}}</ref>

=== 통합 ===
도커는 다음을 포함한 다양한 인프라스트럭처 도구들에 통합될 수 있다.

* [[아마존 웹 서비스]]<ref>{{웹 인용 |url=https://docs.docker.com/installation/amazon/ |title=Amazon EC2 - Docker Documentation |website=docs.docker.com |date= |accessdate=2014-10-18 |보존url=https://archive.today/20141018090321/https://docs.docker.com/installation/amazon/ |보존날짜=2014-10-18}}</ref>
* [[Ansible]]<ref>{{웹 인용 |author=/ |url=https://github.com/ansible/ansible/blob/devel/library/cloud/docker |title=ansible/library/cloud/docker |publisher=[[GitHub]] |date= |accessdate=2014-01-20 |보존url=https://archive.today/20131227071413/https://github.com/ansible/ansible/blob/devel/library/cloud/docker |보존날짜=2013-12-27}}</ref>
* [[CFEngine]]<ref>{{웹 인용|url=http://docs.docker.com/examples/cfengine_process_management/|title=CFEngine|publisher=CFEngine|date=|accessdate=2014-06-06|보존url=https://web.archive.org/web/20140613180312/http://docs.docker.com/examples/cfengine_process_management/|보존날짜=2014-06-13}}</ref>
* [[Chef]]<ref>{{웹 인용|url=https://github.com/thoward/docker-cookbook |title=thoward/docker-cookbook |publisher=GitHub |date= |accessdate=2014-01-20}}</ref>
* [[구글 클라우드 플랫폼]]<ref>{{웹 인용|title=Containers on Google Cloud Platform|url=https://cloud.google.com/compute/docs/containers|publisher=Google Inc}}</ref>
* IBM [[블루믹스]]<ref>{{웹 인용 |url=https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/ |title=Bluemix Launches IBM Containers Beta Based on Docker |publisher=IBM |date=2014-12-04 |accessdate=2015-04-20 |archive-date=2015-04-28 |archive-url=https://web.archive.org/web/20150428181821/https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/}}</ref>
* HPE Helion Stackato
* [[Jelastic]]<ref>{{웹 인용 |url=http://www.prweb.com/releases/2014/12/prweb12361294.htm/ |title=Jelastic Announces Docker Integration to Provide the Most Advanced Orchestrated Application Delivery |publisher=PRWeb|date= |accessdate=2014-12-03}}</ref>
* [[젠킨스]]<ref>{{웹 인용|url=https://github.com/georgebashi/jenkins-docker-plugin |title=georgebashi/jenkins-docker-plugin |publisher=GitHub |date= |accessdate=2017-01-09}}</ref>
* <s>[[Kubernetes]]<ref name="containerizing-docker-on-Kubernetes">{{뉴스 인용 |last=Surana |first=Ramit |url=https://www.linkedin.com/pulse/containerizing-docker-kubernetes-ramit-surana |title=Containerizing Docker on Kubernetes |work=[[LinkedIn]] |date=2015-09-16 |accessdate=2015-11-02 }}</ref></s> Kubenetes 1.20부터 지원하지 않는다.
* [[마이크로소프트 애저]]<ref>{{웹 인용|url=https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/|title=The Docker Virtual Machine Extension for Linux on Azure|date=29 June 2015|publisher=Microsoft|accessdate=11 August 2015|archive-date=2016-03-17|archive-url=https://web.archive.org/web/20160317130223/https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/}}</ref>
* [[오픈스택]] 노바<ref>{{웹 인용 |author=Stefano Maffulli |url=http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |title=OpenStack Community Weekly Newsletter (May 31 – June 7) » The OpenStack Blog |publisher=Openstack.org |date=2013-06-07 |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20131229025044/http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |보존날짜=2013-12-29}}</ref>
* [[OpenSVC]]<ref>{{웹 인용 |url=http://docs.opensvc.com/virtualization.docker.html |title=OpenSVC Docker |publisher=OpenSVC |date= |accessdate=2014-05-29 |보존url=https://web.archive.org/web/20140531090525/http://docs.opensvc.com/virtualization.docker.html |보존날짜=2014-05-31}}</ref>
* 오라클 컨테이너 클라우드 서비스<ref>
{{웹 인용
| last = Native
| first = Cloud
| title = Oracle Container Cloud Service Explained By Oracle.com
| url = https://cloud.oracle.com/container}}
</ref>
* [[퍼핏 (소프트웨어)|퍼핏]]<ref>{{웹 인용 | author = Gareth Rushgrove | url = http://forge.puppetlabs.com/garethr/docker | title = garethr/docker | publisher = Puppet Forge | date = | accessdate = 2014-01-20 }}</ref>
* [[Salt]]<ref>{{웹 인용 |url=http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |title=saltstack/dockerio |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20140203185236/http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |보존날짜=2014-02-03}}</ref>
* [[Vagrant]]<ref>{{웹 인용 |url=https://github.com/philspitler/vagrant-docker |title=philspitler/vagrant-docker |publisher=GitHub |date= |accessdate=2014-01-20 |보존url=https://archive.today/20130809164628/https://github.com/philspitler/vagrant-docker |보존날짜=2013-08-09}}</ref>
* [[VMware vSphere|VMware vSphere Integrated Containers]]<ref>http://searchservervirtualization.techtarget.com/definition/VMware-vSphere-Integrated-Containers-VIC VMware vSphere Integrated Containers (VIC)</ref><ref>http://thenewstack.io/vmwares-photon-platform-and-how-it-treats-containers/ VMware’s Photon Platform and How it Treats Containers</ref>

클라우드 파운드리 Diego 프로젝트는 도커를 [[클라우드 파운드리]] [[PaaS]]에 통합한다.<ref>
{{웹 인용
| last = Whelan
| first = Phil
| title = Cloud Foundry: Diego Explained By Onsi Fakhouri
| url = https://community.spiceworks.com/topic/576560-cloud-foundry-diego-explained-by-onsi-fakhouri
| publisher = ActiveState
| publication-date = 2014-09-03
| accessdate = 2015-04-20
| quote = Functionality is being added to enable end-users to push Docker images directly into a Cloud Foundry cluster running Diego.
}}
</ref>

레드햇의 [[오픈시프트]] PaaS는 도커 및 관련 프로젝트(Kubernetes, Geard, Project Atomic 등)를 v3 (2015년 6월)부터 통합한다.<ref>
{{뉴스 인용
| last = Jackson
| first = Joab
| title = Red Hat to update Docker container tech for enterprises: Open source vendor plans to incorporate advanced Linux tools such as systemd and SELinux into Docker
| url = http://www.computerworld.com/s/article/9247706/Red_Hat_to_update_Docker_container_tech_for_enterprises
| publisher = Computerworld, Inc.
| publication-date = 2014-04-16
| accessdate = 2014-05-29
| quote = Red Hat has also started a second community project, called GearD, to integrate Docker into its PaaS (platform-as-a-service) hosting software, OpenShift Origin.
}}
</ref>

[[Apprenda]] PaaS는 제품 버전 6.0에 도커 컨테이너를 통합한다.<ref>
{{뉴스 인용
| last = Verge
| first = Jason
| title = PaaS and Docker Containers Work Together in Latest Apprenda Release
| url = http://www.datacenterknowledge.com/archives/2015/04/28/paas-and-docker-containers-work-together-in-latest-apprenda-release/
| publisher = Data Center Knowledge
| publication-date = 2015-04-28
| accessdate = 2015-12-06
| quote = The 6.0 release integrates Docker’s flexibility and portability with the compliance, governance and security capabilities that enterprises need from PaaS.
}}
</ref>

== 역사 ==
솔로몬 하익스는 프랑스에서 [[PaaS]] 기업인 [[닷클라우드]] 안에 내부 프로젝트로서 도커를 시작했다.<ref>{{웹 인용|url=https://www.dotcloud.com/|title=One home for all your apps|date=|website=dotcloud.com|보존url=https://web.archive.org/web/20140517031011/https://www.dotcloud.com/|archivedate=2014-05-17|accessdate=2014-05-08}}</ref>

도커는 2013년 3월 오픈 소스로 출시되었다.<ref name="infoq-201303" />

== 사용법 ==

=== CLI를 통한 이용 ===

=== GUI를 통한 이용 ===

==== 도커 데스크탑 ====
도커를 관리하는 GUI 앱으로 이미지를 검색하여 pull하거나 버튼 몇 번으로 이미지 생성, 빌드가 가능하다. 리눅스에서는 사용 불가능하다.

==== IDE/텍스트 편집기를 통한 이용 ====
[[비주얼 스튜디오 코드]]에서 확장기능을 이용하면 GUI를 통해서 도커 이미지를 빌드, 컨테이너 실행, 스택 실행 등이 가능하다. <code>docker exec -it <container> bash</code> 같이 일일이 코드를 치지 않고 버튼을 눌러 컨테이너의 쉘에 접근할 수 있다.

==== portainer 사용 ====

== 도구 ==
=== Docker Compose ===
Compose는 멀티 컨테이너 도커 애플리케이션을 정의하고 실행하는 도구이다.<ref>{{웹 인용|url=https://docs.docker.com/compose/overview/ |title=Overview of Docker Compose |accessdate=2017-07-06}}</ref> [[YAML]] 파일을 사용하여 애플리케이션의 서비스를 구성하며 하나의 명령을 가지고 모든 컨테이너의 생성 및 시작 프로세스를 수행한다. 도커 구 버전에서는 docker-compose를 설치하여야 하지만 신 버전은 docker 명령어에 통합되어 도커를 설치하기만 하면 되고 실행 명령어는 docker-compose 대신 docker compose이다. os마다 다르지만 docker를 패키지 매니저를 통해서 설치하면 구 버전이 설치될 수 있어 docker-compose를 별도로 설치해야 하는 경우가 생긴다. 공식 홈페이지에 소개된 설치 코드를 이용하여 설치하면 거의 최신 버전 설치가 된다.

=== Docker Swarm ===
Docker Swarm은 도커 컨테이너의 네이티브 [[컴퓨터 클러스터|클러스터링]] 기능을 제공하며 하나의 가상 도커 엔진으로 탈바꿈시킨다.<ref>{{웹 인용|url=https://www.linux.com/news/8-open-source-CONTAINER-ORCHESTRATION-TOOLS-KNOW|title=8 Container Orchestration Tools to Know|date=2017-04-12|accessdate=2017-07-06}}</ref>

도커 스웜은 컨테이너 오케스트레이션을 수행할 수 있게 해주며 여러 컴퓨터(노드)들을 클러스터로 구성했을 때 유용하다. 클러스터 중에서 여유 있는 컴퓨터에 자동으로 애플리케이션이 올라가 실행된다. 도커를 스웜 모드로 전환해야 하며 명령어를 통해 스웜 모드가 활성화된 노드들을 서로 연결시켜주어야 한다.

도커 1.12 이상부터 Swarm 모드가 도커 엔진에 통합되어 있다.<ref>{{웹 인용|url=https://docs.docker.com/swarm/ |title=Docker Swarm |accessdate=2017-07-06}}</ref>

비슷한 소프트웨어로는 [[kubernetes]](쿠버네티스)가 있다. 도커 스웜은 진입 장벽이 낮고 학습자나 취미 이용가들에게 적합한 반면 쿠버네티스는 학습 곡선이 가파르고 초보자에게 어렵지만 기능이 강력하고 풍부해서 상업적으로 쿠버네티스를 사용하는 프로젝트가 많다. IT 관련 직종 스펙인 기술 스택에 쿠버네티스가 있는 경우는 흔하지만 도커 스웜은 상대적으로 드문 편.

== 기타 ==
* 도커 안에서 도커를 굴릴 수 있다. 이른바 도커 인 도커(Docker in Docker). 다만 이럴 경우 호스트 도커와 게스트 도커, 그리고 그 안의 컨테이너까지 3중으로 프로세스가 돌아가면서 서버 자원이 상당히 소모된다. Docker out of Docker라고, 게스트 도커가 호스트 도커의 일부 설정을 공유하게 하는 경우도 있는데, 이 경우는 컨테이너 개념이 일부 깨지기에 보안 상으로 영 좋지 않다. 이런 일들이 대표적으로 [[Jenkins|젠킨스]] 같은 지속 통합 소프트웨어를 도커 이미지로 올렸을 때 발생한다. CI 도구로 컨테이너 이미지를 빌드하는 경우가 많기 때문.
* Docker Engine 같은 컨테이너 엔진과, 안드로이드를 비롯한 많은 임베디드 리눅스 개발 환경이 chroot를 비롯하여 많은 도구들을 공유하기 때문에, '이론상으로는' AMD64 기반 혹은 ARM64 기반 고성능 임베디드 시스템을 커스텀 도커 이미지로 만들고 도커 허브에 올린 다음, 이미지만 받아서 바로 그걸 [[Secure Digital|microSD카드]] 같은 플래시 메모리 장치의 부트 로더 파티션 뒤에 리눅스 dd 명령어 등으로 그대로 박아 넣어 부팅하는 짓이 가능하긴 하다. 문제는 AMD64 임베디드 시스템이라면 모를까, ARM64의 경우 개발 환경 및 타겟 장치 구성이 너무 심하게 파편화되어 ARM64 이미지를 커스텀하기 힘들고, RISC-V나 구형 32bit ARM CPU 및 기타 임베디드 시스템용 CPU/MCU를 도커 측에서 지원하지 않아 저걸 실현 가능한 경우의 수가 매우 한정적이라는 것. 아무리 도커 같은 리눅스 컨테이너 엔진이라도 임베디드 시스템 개발 작업까지 커버하기엔 멀어도 한참 멀었다.

== 같이 보기 ==
* [[데브옵스]]
* [[마이크로서비스]]
* [[서비스 컴포넌트 아키텍처]]
* [[Podman]]
* [[kubernetes]]
* [[위키백과:베이그런트 (소프트웨어)|Vagrant]]

== 외부 링크 ==
* {{공식 웹사이트}}
* [https://www.44bits.io/ko/post/why-should-i-use-docker-container 왜 굳이 도커(컨테이너)를 써야 하나요?]

{{각주|30em}}
{{퍼온문서|문서=도커|퍼온곳=위키백과}}
[[분류:자유 소프트웨어]]
[[분류:가상화 소프트웨어]]

도커

2025-06-07T14:39:52Z

Senouis: /* 기타 */

{{소프트웨어 정보
| 이름 = 도커 Docker
| 로고 = Docker (container engine) logo.svg
| 원작자 = 솔로몬 하익스 (Solomon Hykes)
| 개발자 = [[도커 (기업)|도커(Docker Inc.)]]
| 발표일 =
| 최신 버전 출시일 =
| 프로그래밍 언어 = [[Go (프로그래밍 언어)|Go]]<ref>{{웹 인용|url=https://github.com/docker/distribution |title=Docker source code |work=docs.docker.com |publisher=Docker, Inc. |date=2015-10-12 |accessdate=2015-10-24}}</ref>
| 운영체제 = [[리눅스]], [[마이크로소프트 윈도우|윈도우]], [[macOS]]
| 플랫폼 = 현대의 리눅스 커널이 포함된 [[x86-64]], [[ARM 아키텍처|ARM]] (실험적), 하이퍼-V 기능이 포함된 [[x86-64]] 윈도우
| 종류 = [[운영 체제 수준 가상화]]
| 라이선스 = [[아파치 라이선스]] 2.0
| 웹사이트 = {{URL|https://www.docker.com/}}
}}
'''도커'''(Docker)는 [[리눅스]]의 [[응용 소프트웨어|응용 프로그램]]들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 [[오픈 소스]] 프로젝트이다.

도커 웹 페이지의 기능을 인용하면 다음과 같다:
{{인용문|도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다.<ref>https://www.docker.com/what-docker</ref>}}

도커는 [[리눅스]]에서 [[운영 체제 수준 가상화]]의 추상화 및 자동화 계층을 추가적으로 제공한다.<ref name="SYS-CON Media">{{웹 인용
| last = O'Gara
| first = Maureen
| date = 26 July 2013
| url = http://maureenogara.sys-con.com/node/2747331
| title = Ben Golub, Who Sold Gluster to Red Hat, Now Running dotCloud
| publisher = SYS-CON Media
| accessdate = 2013-08-09
| archive-date = 2019-09-13
| archive-url = https://web.archive.org/web/20190913100835/http://maureenogara.sys-con.com/node/2747331

}}</ref> 도커는 [[cgroups]]와 커널 [[리눅스 이름공간|이름공간]]과 같은 [[리눅스 커널]]의 기능들과 OverayFS, [[aufs]]와 같은 [[유니언 마운트|유니언 가능 파일 시스템]]의 리소스 격리 기능을 사용하며,<ref>{{웹 인용|title = docker/docker|url = https://github.com/docker/docker/blob/990a3e30fa66e7bd3df3c78c873c97c5b1310486/daemon/graphdriver/driver.go#L37-L43|website = GitHub|accessdate = 2015-12-29}}</ref> 이를 통해 독립적인 "컨테이너"가 하나의 리눅스 인스턴스 안에서 실행할 수 있게 함으로써 [[가상 머신]]을 시작하여 유지보수해야 하는 부담을 없애준다.<ref>{{웹 인용
| url = http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| archiveurl = https://web.archive.org/web/20140821065734/http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| title = Docker Documentation: Kernel Requirements
| date = 2014-01-04 | accessdate = 2014-08-20 | archivedate = 2014-08-21
| website = docker.readthedocs.org
}}</ref>

리눅스 커널의 이름공간 지원은 대체적으로<ref>{{웹 인용|url=http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/|title=Yet Another Reason Containers Don't Contain: Kernel Keyrings|author=Dan Walsh|work=projectatomic.io|accessdate=13 April 2015|archive-date=2015-04-13|archive-url=https://web.archive.org/web/20150413062633/http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/}}</ref> 프로세스 트리, 네트워크 사용자 ID, 마운트된 파일 시스템을 포함한 운영 환경에 대한 응용 프로그램의 관점을 격리시키지만, 커널의 cgroup들은 CPU, 메모리, 블록 입출력, 네트워크를 포함한 리소스 제한을 제공한다. 버전 0.9부터 도커는 [[libvirt]], [[LXC]] (리눅스 컨테이너), [[systemd-nspawn]]을 통한 추상화된 가상화 인터페이스를 사용하는 것 뿐 아니라 리눅스 커널이 제공하는 가상화 기능을 직접 사용하기 위한 유일한 수단으로 libcontainer [[라이브러리 (컴퓨팅)|라이브러리]]를 포함하고 있다.<ref name="zdnet-7000030397">{{웹 인용
| url = http://www.zdnet.com/docker-libcontainer-unifies-linux-container-powers-7000030397/
| title = Docker libcontainer unifies Linux container powers
| date = 2014-06-11 | accessdate = 2014-07-30
| author = Steven J. Vaughan-Nichols | publisher = [[ZDNet]]
}}</ref><ref>{{웹 인용
| url = https://github.com/docker/libcontainer/blob/master/README.md
| title = libcontainer - reference implementation for containers
| accessdate = 2014-07-30
| website = github.com
}}</ref><ref name="docker-blog-201403">{{웹 인용
| url = http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
| title = Docker 0.9: Introducing execution drivers and libcontainer
| date = 2014-03-10
| accessdate = 2015-01-20
| website = docker.com
| archive-date = 2015-02-21
| archive-url = https://web.archive.org/web/20150221134532/http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
}}</ref>

== 개요 ==
[[파일:Docker-linux-interfaces.svg|섬네일|도커는 리눅스 커널의 가상화 기능에 접근하기 위해 각기 다른 인터페이스를 사용할 수 있다.<ref name="docker-blog-201403" />]]

도커 베이스 이미지에 액션을 취하면, 유니언 파일 시스템 계층들이 만들어지고 문서화되는데, 이렇게 함으로써 각 계층은 어떻게 액션을 재생성할지에 대해 완전하게 기술하게 된다. 이러한 전략은 이를테면 완전한 VM과 비교하면 도커의 이미지를 가볍게 만들어주며, 오직 레이어 업데이트만 전파해 주면 된다.

산업 애널리스트 기업 451 리서치에 따르면, "도커는 응용 프로그램과 그 의존성을 가상 컨테이너에 담을 수 있는 도구이며, 이 컨테이너는 어떠한 리눅스 서버에서라도 구동이 가능하다. 이것은 [[사내 소프트웨어|사내]], [[클라우드 컴퓨팅|공용 클라우드]], [[클라우드 컴퓨팅|개인 클라우드]], [[베어 메탈 서버|베어 메탈]] 등 응용 프로그램을 실행할 수 있는 곳에서는 유연성과 이식성을 적용하는데 도움을 준다.<ref name="Linux">{{웹 인용
| last = Noyes
| first = Katherine
| date = 1 August 2013
| url = http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code
| title = Docker: A 'Shipping Container' for Linux Code
| publisher = [[Linux.com]]
| accessdate = 2013-08-09
| 보존url = https://web.archive.org/web/20130808043357/http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code/
| 보존날짜 = 2013-08-08
}}</ref>

도커는 고급 [[API]]를 구현함으로써 프로세스들을 별도의 장소에서 실행할 수 있는 가벼운 컨테이너들을 제공한다.<ref name="infoq-201303">{{웹 인용
| last = Avram
| first = Abel
| date = 2013-03-27
| url = http://www.infoq.com/news/2013/03/Docker
| title = Docker: Automated and Consistent Software Deployments
| publisher = InfoQ
| accessdate = 2013-08-09
}}</ref>

[[리눅스 커널]]이 제공하는 기능들(주로 cgroups와 이름공간) 위에 빌드되기 때문에 도커 컨테이너는 가상 머신과는 달리 별도의 운영 체제를 요구하거나 포함하지 않는다.<ref name="Linux" /> 그 대신, 커널의 기능에 의존하며 리소스 격리(CPU, 메모리, 블록 입출력, 네트워크 등) 및 [[이름공간 격리|격리된 이름공간]]을 사용하여 운영 체제에 대한 응용 프로그램의 관점을 격리시킨다. 도커는 도커 0.9대부터 이용 가능한 libcontainer 라이브러리를 사용하거나 [[libvirt]], [[LXC]] (리눅스 컨테이너), 또는 [[systemd-nspawn]]을 통해 간접적으로 리눅스 커널의 가상화 기능들에 접근한다.<ref name="docker-blog-201403" /><ref name="infoq-201403">{{웹 인용
| last = Swan
| first = Chris
| date = 2014-03-13
| url = http://www.infoq.com/news/2014/03/docker_0_9
| title = Docker drops LXC as default execution environment
| publisher = InfoQ
| accessdate = 2015-01-20
}}</ref>

도커는 매우 가볍기 때문에, 하나의 서버나 가상 머신이 여러 컨테이너들을 동시에 구동할 수 있다.

컨테이너를 사용하여 리소스를 격리시키고, 서비스를 제한시키며, 프로세스를 예비할 수 있으며 이렇게 하여 자신만의 프로세스 ID 공간, 파일 시스템 구조, 네트워크 인터페이스를 갖고서 운영 체제에 대하여 거의 완전히 개인화된 관점을 갖게 한다. 여러 개의 컨테이너들은 동일한 커널은 공유하지만 각 컨테이너는 CPU, 메모리, 입출력과 같이 오직 정의된 양의 리소스에만 제한을 받을 수 있다.

도커를 사용하여 컨테이너를 만들고 관리하면 다수의 응용 프로그램, 작업자의 작업, 다른 프로세스들이 자율적으로 하나의 물리 머신이나 여러 개의 가상 머신을 통해 구동될 수 있게 되므로 고도의 [[분산 시스템]]을 생성하는 일이 단순해진다. 리소스가 사용 가능해질 때 또는 더 많은 노드가 필요할 때 노드가 배치될 수 있게 하므로 [[Apache Cassandra]], [[몽고DB]], [[Riak]]와 같은 시스템을 위한 [[PaaS]] 스타일의 배치 및 규모 증강이 가능해진다. 또, 도커는 작업이나 워크로드 큐, 기타 분산 시스템들의 생성 및 운영을 단순하게 한다.<ref name="CloudAve">{{웹 인용
| last = Hall
| first = Adron
| date = 31 July 2013
| url = http://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
| title = OSCON : Conversations, Deployments, Architecture, Docker and the Future?
| publisher = CloudAve
| accessdate = 2013-08-09
| archive-date = 2019-03-27
| archive-url = https://web.archive.org/web/20190327103543/https://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
}}</ref><ref name="Iron.io">{{웹 인용
|last = Reeder
|first = Travis
|date = 22 April 2014
|url = http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|title = How Docker Helped Us Achieve the (Near) Impossible
|publisher = Iron.io
|accessdate = 2014-07-25
|보존url = https://web.archive.org/web/20140808031809/http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|보존날짜 = 2014-08-08
}}</ref>

=== 통합 ===
도커는 다음을 포함한 다양한 인프라스트럭처 도구들에 통합될 수 있다.

* [[아마존 웹 서비스]]<ref>{{웹 인용 |url=https://docs.docker.com/installation/amazon/ |title=Amazon EC2 - Docker Documentation |website=docs.docker.com |date= |accessdate=2014-10-18 |보존url=https://archive.today/20141018090321/https://docs.docker.com/installation/amazon/ |보존날짜=2014-10-18}}</ref>
* [[Ansible]]<ref>{{웹 인용 |author=/ |url=https://github.com/ansible/ansible/blob/devel/library/cloud/docker |title=ansible/library/cloud/docker |publisher=[[GitHub]] |date= |accessdate=2014-01-20 |보존url=https://archive.today/20131227071413/https://github.com/ansible/ansible/blob/devel/library/cloud/docker |보존날짜=2013-12-27}}</ref>
* [[CFEngine]]<ref>{{웹 인용|url=http://docs.docker.com/examples/cfengine_process_management/|title=CFEngine|publisher=CFEngine|date=|accessdate=2014-06-06|보존url=https://web.archive.org/web/20140613180312/http://docs.docker.com/examples/cfengine_process_management/|보존날짜=2014-06-13}}</ref>
* [[Chef]]<ref>{{웹 인용|url=https://github.com/thoward/docker-cookbook |title=thoward/docker-cookbook |publisher=GitHub |date= |accessdate=2014-01-20}}</ref>
* [[구글 클라우드 플랫폼]]<ref>{{웹 인용|title=Containers on Google Cloud Platform|url=https://cloud.google.com/compute/docs/containers|publisher=Google Inc}}</ref>
* IBM [[블루믹스]]<ref>{{웹 인용 |url=https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/ |title=Bluemix Launches IBM Containers Beta Based on Docker |publisher=IBM |date=2014-12-04 |accessdate=2015-04-20 |archive-date=2015-04-28 |archive-url=https://web.archive.org/web/20150428181821/https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/}}</ref>
* HPE Helion Stackato
* [[Jelastic]]<ref>{{웹 인용 |url=http://www.prweb.com/releases/2014/12/prweb12361294.htm/ |title=Jelastic Announces Docker Integration to Provide the Most Advanced Orchestrated Application Delivery |publisher=PRWeb|date= |accessdate=2014-12-03}}</ref>
* [[젠킨스]]<ref>{{웹 인용|url=https://github.com/georgebashi/jenkins-docker-plugin |title=georgebashi/jenkins-docker-plugin |publisher=GitHub |date= |accessdate=2017-01-09}}</ref>
* <s>[[Kubernetes]]<ref name="containerizing-docker-on-Kubernetes">{{뉴스 인용 |last=Surana |first=Ramit |url=https://www.linkedin.com/pulse/containerizing-docker-kubernetes-ramit-surana |title=Containerizing Docker on Kubernetes |work=[[LinkedIn]] |date=2015-09-16 |accessdate=2015-11-02 }}</ref></s> Kubenetes 1.20부터 지원하지 않는다.
* [[마이크로소프트 애저]]<ref>{{웹 인용|url=https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/|title=The Docker Virtual Machine Extension for Linux on Azure|date=29 June 2015|publisher=Microsoft|accessdate=11 August 2015|archive-date=2016-03-17|archive-url=https://web.archive.org/web/20160317130223/https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/}}</ref>
* [[오픈스택]] 노바<ref>{{웹 인용 |author=Stefano Maffulli |url=http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |title=OpenStack Community Weekly Newsletter (May 31 – June 7) » The OpenStack Blog |publisher=Openstack.org |date=2013-06-07 |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20131229025044/http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |보존날짜=2013-12-29}}</ref>
* [[OpenSVC]]<ref>{{웹 인용 |url=http://docs.opensvc.com/virtualization.docker.html |title=OpenSVC Docker |publisher=OpenSVC |date= |accessdate=2014-05-29 |보존url=https://web.archive.org/web/20140531090525/http://docs.opensvc.com/virtualization.docker.html |보존날짜=2014-05-31}}</ref>
* 오라클 컨테이너 클라우드 서비스<ref>
{{웹 인용
| last = Native
| first = Cloud
| title = Oracle Container Cloud Service Explained By Oracle.com
| url = https://cloud.oracle.com/container}}
</ref>
* [[퍼핏 (소프트웨어)|퍼핏]]<ref>{{웹 인용 | author = Gareth Rushgrove | url = http://forge.puppetlabs.com/garethr/docker | title = garethr/docker | publisher = Puppet Forge | date = | accessdate = 2014-01-20 }}</ref>
* [[Salt]]<ref>{{웹 인용 |url=http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |title=saltstack/dockerio |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20140203185236/http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |보존날짜=2014-02-03}}</ref>
* [[Vagrant]]<ref>{{웹 인용 |url=https://github.com/philspitler/vagrant-docker |title=philspitler/vagrant-docker |publisher=GitHub |date= |accessdate=2014-01-20 |보존url=https://archive.today/20130809164628/https://github.com/philspitler/vagrant-docker |보존날짜=2013-08-09}}</ref>
* [[VMware vSphere|VMware vSphere Integrated Containers]]<ref>http://searchservervirtualization.techtarget.com/definition/VMware-vSphere-Integrated-Containers-VIC VMware vSphere Integrated Containers (VIC)</ref><ref>http://thenewstack.io/vmwares-photon-platform-and-how-it-treats-containers/ VMware’s Photon Platform and How it Treats Containers</ref>

클라우드 파운드리 Diego 프로젝트는 도커를 [[클라우드 파운드리]] [[PaaS]]에 통합한다.<ref>
{{웹 인용
| last = Whelan
| first = Phil
| title = Cloud Foundry: Diego Explained By Onsi Fakhouri
| url = https://community.spiceworks.com/topic/576560-cloud-foundry-diego-explained-by-onsi-fakhouri
| publisher = ActiveState
| publication-date = 2014-09-03
| accessdate = 2015-04-20
| quote = Functionality is being added to enable end-users to push Docker images directly into a Cloud Foundry cluster running Diego.
}}
</ref>

레드햇의 [[오픈시프트]] PaaS는 도커 및 관련 프로젝트(Kubernetes, Geard, Project Atomic 등)를 v3 (2015년 6월)부터 통합한다.<ref>
{{뉴스 인용
| last = Jackson
| first = Joab
| title = Red Hat to update Docker container tech for enterprises: Open source vendor plans to incorporate advanced Linux tools such as systemd and SELinux into Docker
| url = http://www.computerworld.com/s/article/9247706/Red_Hat_to_update_Docker_container_tech_for_enterprises
| publisher = Computerworld, Inc.
| publication-date = 2014-04-16
| accessdate = 2014-05-29
| quote = Red Hat has also started a second community project, called GearD, to integrate Docker into its PaaS (platform-as-a-service) hosting software, OpenShift Origin.
}}
</ref>

[[Apprenda]] PaaS는 제품 버전 6.0에 도커 컨테이너를 통합한다.<ref>
{{뉴스 인용
| last = Verge
| first = Jason
| title = PaaS and Docker Containers Work Together in Latest Apprenda Release
| url = http://www.datacenterknowledge.com/archives/2015/04/28/paas-and-docker-containers-work-together-in-latest-apprenda-release/
| publisher = Data Center Knowledge
| publication-date = 2015-04-28
| accessdate = 2015-12-06
| quote = The 6.0 release integrates Docker’s flexibility and portability with the compliance, governance and security capabilities that enterprises need from PaaS.
}}
</ref>

== 역사 ==
솔로몬 하익스는 프랑스에서 [[PaaS]] 기업인 [[닷클라우드]] 안에 내부 프로젝트로서 도커를 시작했다.<ref>{{웹 인용|url=https://www.dotcloud.com/|title=One home for all your apps|date=|website=dotcloud.com|보존url=https://web.archive.org/web/20140517031011/https://www.dotcloud.com/|archivedate=2014-05-17|accessdate=2014-05-08}}</ref>

도커는 2013년 3월 오픈 소스로 출시되었다.<ref name="infoq-201303" />

== 사용법 ==

=== CLI를 통한 이용 ===

=== GUI를 통한 이용 ===

==== 도커 데스크탑 ====
도커를 관리하는 GUI 앱으로 이미지를 검색하여 pull하거나 버튼 몇 번으로 이미지 생성, 빌드가 가능하다. 리눅스에서는 사용 불가능하다.

==== IDE/텍스트 편집기를 통한 이용 ====
[[비주얼 스튜디오 코드]]에서 확장기능을 이용하면 GUI를 통해서 도커 이미지를 빌드, 컨테이너 실행, 스택 실행 등이 가능하다. <code>docker exec -it <container> bash</code> 같이 일일이 코드를 치지 않고 버튼을 눌러 컨테이너의 쉘에 접근할 수 있다.

==== portainer 사용 ====

== 도구 ==
=== Docker Compose ===
Compose는 멀티 컨테이너 도커 애플리케이션을 정의하고 실행하는 도구이다.<ref>{{웹 인용|url=https://docs.docker.com/compose/overview/ |title=Overview of Docker Compose |accessdate=2017-07-06}}</ref> [[YAML]] 파일을 사용하여 애플리케이션의 서비스를 구성하며 하나의 명령을 가지고 모든 컨테이너의 생성 및 시작 프로세스를 수행한다. 도커 구 버전에서는 docker-compose를 설치하여야 하지만 신 버전은 docker 명령어에 통합되어 도커를 설치하기만 하면 되고 실행 명령어는 docker-compose 대신 docker compose이다. os마다 다르지만 docker를 패키지 매니저를 통해서 설치하면 구 버전이 설치될 수 있어 docker-compose를 별도로 설치해야 하는 경우가 생긴다. 공식 홈페이지에 소개된 설치 코드를 이용하여 설치하면 거의 최신 버전 설치가 된다.

=== Docker Swarm ===
Docker Swarm은 도커 컨테이너의 네이티브 [[컴퓨터 클러스터|클러스터링]] 기능을 제공하며 하나의 가상 도커 엔진으로 탈바꿈시킨다.<ref>{{웹 인용|url=https://www.linux.com/news/8-open-source-CONTAINER-ORCHESTRATION-TOOLS-KNOW|title=8 Container Orchestration Tools to Know|date=2017-04-12|accessdate=2017-07-06}}</ref>

도커 스웜은 컨테이너 오케스트레이션을 수행할 수 있게 해주며 여러 컴퓨터(노드)들을 클러스터로 구성했을 때 유용하다. 클러스터 중에서 여유 있는 컴퓨터에 자동으로 애플리케이션이 올라가 실행된다. 도커를 스웜 모드로 전환해야 하며 명령어를 통해 스웜 모드가 활성화된 노드들을 서로 연결시켜주어야 한다.

도커 1.12 이상부터 Swarm 모드가 도커 엔진에 통합되어 있다.<ref>{{웹 인용|url=https://docs.docker.com/swarm/ |title=Docker Swarm |accessdate=2017-07-06}}</ref>

비슷한 소프트웨어로는 [[kubernetes]](쿠버네티스)가 있다. 도커 스웜은 진입 장벽이 낮고 학습자나 취미 이용가들에게 적합한 반면 쿠버네티스는 학습 곡선이 가파르고 초보자에게 어렵지만 기능이 강력하고 풍부해서 상업적으로 쿠버네티스를 사용하는 프로젝트가 많다. IT 관련 직종 스펙인 기술 스택에 쿠버네티스가 있는 경우는 흔하지만 도커 스웜은 상대적으로 드문 편.

== 기타 ==
* 도커 안에서 도커를 굴릴 수 있다. 이른바 도커 인 도커(Docker in Docker). 다만 이럴 경우 호스트 도커와 게스트 도커, 그리고 그 안의 컨테이너까지 3중으로 프로세스가 돌아가면서 서버 자원이 상당히 소모된다. Docker out of Docker라고, 게스트 도커가 호스트 도커의 일부 설정을 공유하게 하는 경우도 있는데, 이 경우는 컨테이너 개념이 일부 깨지기에 보안 상으로 영 좋지 않다. 이런 일들이 대표적으로 [[Jenkins|젠킨스]] 같은 지속 통합 소프트웨어를 도커 이미지로 올렸을 때 발생한다. CI 도구로 컨테이너 이미지를 빌드하는 경우가 많기 때문.
* Docker Engine과 안드로이드를 비롯한 많은 임베디드 리눅스 개발 환경이 chroot를 비롯하여 많은 도구들을 공유하기 때문에, '이론상으로는' AMD64 기반 혹은 ARM64 기반 고성능 임베디드 시스템을 커스텀 도커 이미지로 만들고 도커 허브에 올린 다음, 이미지만 받아서 바로 그걸 [[Secure Digital|microSD카드]] 같은 플래시 메모리 장치의 부트 로더 파티션 뒤에 리눅스 dd 명령어 등으로 그대로 박아 넣어 부팅하는 짓이 가능하긴 하다. 문제는 AMD64 임베디드 시스템이라면 모를까, ARM64의 경우 개발 환경 및 타겟 장치 구성이 너무 심하게 파편화되어 ARM64 이미지를 커스텀하기 힘들고, RISC-V나 구형 32bit ARM CPU 및 기타 임베디드 시스템용 CPU/MCU를 도커 측에서 지원하지 않아 저걸 실현 가능한 경우의 수가 매우 한정적이라는 것. 아무리 도커 같은 리눅스 컨테이너 엔진이라도 임베디드 시스템 개발 작업까지 커버하기엔 멀어도 한참 멀었다.

== 같이 보기 ==
* [[데브옵스]]
* [[마이크로서비스]]
* [[서비스 컴포넌트 아키텍처]]
* [[Podman]]
* [[kubernetes]]
* [[위키백과:베이그런트 (소프트웨어)|Vagrant]]

== 외부 링크 ==
* {{공식 웹사이트}}
* [https://www.44bits.io/ko/post/why-should-i-use-docker-container 왜 굳이 도커(컨테이너)를 써야 하나요?]

{{각주|30em}}
{{퍼온문서|문서=도커|퍼온곳=위키백과}}
[[분류:자유 소프트웨어]]
[[분류:가상화 소프트웨어]]

도커

2025-06-07T14:39:01Z

Senouis: /* 기타 */ 재미있는 사실 하나

{{소프트웨어 정보
| 이름 = 도커 Docker
| 로고 = Docker (container engine) logo.svg
| 원작자 = 솔로몬 하익스 (Solomon Hykes)
| 개발자 = [[도커 (기업)|도커(Docker Inc.)]]
| 발표일 =
| 최신 버전 출시일 =
| 프로그래밍 언어 = [[Go (프로그래밍 언어)|Go]]<ref>{{웹 인용|url=https://github.com/docker/distribution |title=Docker source code |work=docs.docker.com |publisher=Docker, Inc. |date=2015-10-12 |accessdate=2015-10-24}}</ref>
| 운영체제 = [[리눅스]], [[마이크로소프트 윈도우|윈도우]], [[macOS]]
| 플랫폼 = 현대의 리눅스 커널이 포함된 [[x86-64]], [[ARM 아키텍처|ARM]] (실험적), 하이퍼-V 기능이 포함된 [[x86-64]] 윈도우
| 종류 = [[운영 체제 수준 가상화]]
| 라이선스 = [[아파치 라이선스]] 2.0
| 웹사이트 = {{URL|https://www.docker.com/}}
}}
'''도커'''(Docker)는 [[리눅스]]의 [[응용 소프트웨어|응용 프로그램]]들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 [[오픈 소스]] 프로젝트이다.

도커 웹 페이지의 기능을 인용하면 다음과 같다:
{{인용문|도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다.<ref>https://www.docker.com/what-docker</ref>}}

도커는 [[리눅스]]에서 [[운영 체제 수준 가상화]]의 추상화 및 자동화 계층을 추가적으로 제공한다.<ref name="SYS-CON Media">{{웹 인용
| last = O'Gara
| first = Maureen
| date = 26 July 2013
| url = http://maureenogara.sys-con.com/node/2747331
| title = Ben Golub, Who Sold Gluster to Red Hat, Now Running dotCloud
| publisher = SYS-CON Media
| accessdate = 2013-08-09
| archive-date = 2019-09-13
| archive-url = https://web.archive.org/web/20190913100835/http://maureenogara.sys-con.com/node/2747331

}}</ref> 도커는 [[cgroups]]와 커널 [[리눅스 이름공간|이름공간]]과 같은 [[리눅스 커널]]의 기능들과 OverayFS, [[aufs]]와 같은 [[유니언 마운트|유니언 가능 파일 시스템]]의 리소스 격리 기능을 사용하며,<ref>{{웹 인용|title = docker/docker|url = https://github.com/docker/docker/blob/990a3e30fa66e7bd3df3c78c873c97c5b1310486/daemon/graphdriver/driver.go#L37-L43|website = GitHub|accessdate = 2015-12-29}}</ref> 이를 통해 독립적인 "컨테이너"가 하나의 리눅스 인스턴스 안에서 실행할 수 있게 함으로써 [[가상 머신]]을 시작하여 유지보수해야 하는 부담을 없애준다.<ref>{{웹 인용
| url = http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| archiveurl = https://web.archive.org/web/20140821065734/http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| title = Docker Documentation: Kernel Requirements
| date = 2014-01-04 | accessdate = 2014-08-20 | archivedate = 2014-08-21
| website = docker.readthedocs.org
}}</ref>

리눅스 커널의 이름공간 지원은 대체적으로<ref>{{웹 인용|url=http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/|title=Yet Another Reason Containers Don't Contain: Kernel Keyrings|author=Dan Walsh|work=projectatomic.io|accessdate=13 April 2015|archive-date=2015-04-13|archive-url=https://web.archive.org/web/20150413062633/http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/}}</ref> 프로세스 트리, 네트워크 사용자 ID, 마운트된 파일 시스템을 포함한 운영 환경에 대한 응용 프로그램의 관점을 격리시키지만, 커널의 cgroup들은 CPU, 메모리, 블록 입출력, 네트워크를 포함한 리소스 제한을 제공한다. 버전 0.9부터 도커는 [[libvirt]], [[LXC]] (리눅스 컨테이너), [[systemd-nspawn]]을 통한 추상화된 가상화 인터페이스를 사용하는 것 뿐 아니라 리눅스 커널이 제공하는 가상화 기능을 직접 사용하기 위한 유일한 수단으로 libcontainer [[라이브러리 (컴퓨팅)|라이브러리]]를 포함하고 있다.<ref name="zdnet-7000030397">{{웹 인용
| url = http://www.zdnet.com/docker-libcontainer-unifies-linux-container-powers-7000030397/
| title = Docker libcontainer unifies Linux container powers
| date = 2014-06-11 | accessdate = 2014-07-30
| author = Steven J. Vaughan-Nichols | publisher = [[ZDNet]]
}}</ref><ref>{{웹 인용
| url = https://github.com/docker/libcontainer/blob/master/README.md
| title = libcontainer - reference implementation for containers
| accessdate = 2014-07-30
| website = github.com
}}</ref><ref name="docker-blog-201403">{{웹 인용
| url = http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
| title = Docker 0.9: Introducing execution drivers and libcontainer
| date = 2014-03-10
| accessdate = 2015-01-20
| website = docker.com
| archive-date = 2015-02-21
| archive-url = https://web.archive.org/web/20150221134532/http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
}}</ref>

== 개요 ==
[[파일:Docker-linux-interfaces.svg|섬네일|도커는 리눅스 커널의 가상화 기능에 접근하기 위해 각기 다른 인터페이스를 사용할 수 있다.<ref name="docker-blog-201403" />]]

도커 베이스 이미지에 액션을 취하면, 유니언 파일 시스템 계층들이 만들어지고 문서화되는데, 이렇게 함으로써 각 계층은 어떻게 액션을 재생성할지에 대해 완전하게 기술하게 된다. 이러한 전략은 이를테면 완전한 VM과 비교하면 도커의 이미지를 가볍게 만들어주며, 오직 레이어 업데이트만 전파해 주면 된다.

산업 애널리스트 기업 451 리서치에 따르면, "도커는 응용 프로그램과 그 의존성을 가상 컨테이너에 담을 수 있는 도구이며, 이 컨테이너는 어떠한 리눅스 서버에서라도 구동이 가능하다. 이것은 [[사내 소프트웨어|사내]], [[클라우드 컴퓨팅|공용 클라우드]], [[클라우드 컴퓨팅|개인 클라우드]], [[베어 메탈 서버|베어 메탈]] 등 응용 프로그램을 실행할 수 있는 곳에서는 유연성과 이식성을 적용하는데 도움을 준다.<ref name="Linux">{{웹 인용
| last = Noyes
| first = Katherine
| date = 1 August 2013
| url = http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code
| title = Docker: A 'Shipping Container' for Linux Code
| publisher = [[Linux.com]]
| accessdate = 2013-08-09
| 보존url = https://web.archive.org/web/20130808043357/http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code/
| 보존날짜 = 2013-08-08
}}</ref>

도커는 고급 [[API]]를 구현함으로써 프로세스들을 별도의 장소에서 실행할 수 있는 가벼운 컨테이너들을 제공한다.<ref name="infoq-201303">{{웹 인용
| last = Avram
| first = Abel
| date = 2013-03-27
| url = http://www.infoq.com/news/2013/03/Docker
| title = Docker: Automated and Consistent Software Deployments
| publisher = InfoQ
| accessdate = 2013-08-09
}}</ref>

[[리눅스 커널]]이 제공하는 기능들(주로 cgroups와 이름공간) 위에 빌드되기 때문에 도커 컨테이너는 가상 머신과는 달리 별도의 운영 체제를 요구하거나 포함하지 않는다.<ref name="Linux" /> 그 대신, 커널의 기능에 의존하며 리소스 격리(CPU, 메모리, 블록 입출력, 네트워크 등) 및 [[이름공간 격리|격리된 이름공간]]을 사용하여 운영 체제에 대한 응용 프로그램의 관점을 격리시킨다. 도커는 도커 0.9대부터 이용 가능한 libcontainer 라이브러리를 사용하거나 [[libvirt]], [[LXC]] (리눅스 컨테이너), 또는 [[systemd-nspawn]]을 통해 간접적으로 리눅스 커널의 가상화 기능들에 접근한다.<ref name="docker-blog-201403" /><ref name="infoq-201403">{{웹 인용
| last = Swan
| first = Chris
| date = 2014-03-13
| url = http://www.infoq.com/news/2014/03/docker_0_9
| title = Docker drops LXC as default execution environment
| publisher = InfoQ
| accessdate = 2015-01-20
}}</ref>

도커는 매우 가볍기 때문에, 하나의 서버나 가상 머신이 여러 컨테이너들을 동시에 구동할 수 있다.

컨테이너를 사용하여 리소스를 격리시키고, 서비스를 제한시키며, 프로세스를 예비할 수 있으며 이렇게 하여 자신만의 프로세스 ID 공간, 파일 시스템 구조, 네트워크 인터페이스를 갖고서 운영 체제에 대하여 거의 완전히 개인화된 관점을 갖게 한다. 여러 개의 컨테이너들은 동일한 커널은 공유하지만 각 컨테이너는 CPU, 메모리, 입출력과 같이 오직 정의된 양의 리소스에만 제한을 받을 수 있다.

도커를 사용하여 컨테이너를 만들고 관리하면 다수의 응용 프로그램, 작업자의 작업, 다른 프로세스들이 자율적으로 하나의 물리 머신이나 여러 개의 가상 머신을 통해 구동될 수 있게 되므로 고도의 [[분산 시스템]]을 생성하는 일이 단순해진다. 리소스가 사용 가능해질 때 또는 더 많은 노드가 필요할 때 노드가 배치될 수 있게 하므로 [[Apache Cassandra]], [[몽고DB]], [[Riak]]와 같은 시스템을 위한 [[PaaS]] 스타일의 배치 및 규모 증강이 가능해진다. 또, 도커는 작업이나 워크로드 큐, 기타 분산 시스템들의 생성 및 운영을 단순하게 한다.<ref name="CloudAve">{{웹 인용
| last = Hall
| first = Adron
| date = 31 July 2013
| url = http://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
| title = OSCON : Conversations, Deployments, Architecture, Docker and the Future?
| publisher = CloudAve
| accessdate = 2013-08-09
| archive-date = 2019-03-27
| archive-url = https://web.archive.org/web/20190327103543/https://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
}}</ref><ref name="Iron.io">{{웹 인용
|last = Reeder
|first = Travis
|date = 22 April 2014
|url = http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|title = How Docker Helped Us Achieve the (Near) Impossible
|publisher = Iron.io
|accessdate = 2014-07-25
|보존url = https://web.archive.org/web/20140808031809/http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|보존날짜 = 2014-08-08
}}</ref>

=== 통합 ===
도커는 다음을 포함한 다양한 인프라스트럭처 도구들에 통합될 수 있다.

* [[아마존 웹 서비스]]<ref>{{웹 인용 |url=https://docs.docker.com/installation/amazon/ |title=Amazon EC2 - Docker Documentation |website=docs.docker.com |date= |accessdate=2014-10-18 |보존url=https://archive.today/20141018090321/https://docs.docker.com/installation/amazon/ |보존날짜=2014-10-18}}</ref>
* [[Ansible]]<ref>{{웹 인용 |author=/ |url=https://github.com/ansible/ansible/blob/devel/library/cloud/docker |title=ansible/library/cloud/docker |publisher=[[GitHub]] |date= |accessdate=2014-01-20 |보존url=https://archive.today/20131227071413/https://github.com/ansible/ansible/blob/devel/library/cloud/docker |보존날짜=2013-12-27}}</ref>
* [[CFEngine]]<ref>{{웹 인용|url=http://docs.docker.com/examples/cfengine_process_management/|title=CFEngine|publisher=CFEngine|date=|accessdate=2014-06-06|보존url=https://web.archive.org/web/20140613180312/http://docs.docker.com/examples/cfengine_process_management/|보존날짜=2014-06-13}}</ref>
* [[Chef]]<ref>{{웹 인용|url=https://github.com/thoward/docker-cookbook |title=thoward/docker-cookbook |publisher=GitHub |date= |accessdate=2014-01-20}}</ref>
* [[구글 클라우드 플랫폼]]<ref>{{웹 인용|title=Containers on Google Cloud Platform|url=https://cloud.google.com/compute/docs/containers|publisher=Google Inc}}</ref>
* IBM [[블루믹스]]<ref>{{웹 인용 |url=https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/ |title=Bluemix Launches IBM Containers Beta Based on Docker |publisher=IBM |date=2014-12-04 |accessdate=2015-04-20 |archive-date=2015-04-28 |archive-url=https://web.archive.org/web/20150428181821/https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/}}</ref>
* HPE Helion Stackato
* [[Jelastic]]<ref>{{웹 인용 |url=http://www.prweb.com/releases/2014/12/prweb12361294.htm/ |title=Jelastic Announces Docker Integration to Provide the Most Advanced Orchestrated Application Delivery |publisher=PRWeb|date= |accessdate=2014-12-03}}</ref>
* [[젠킨스]]<ref>{{웹 인용|url=https://github.com/georgebashi/jenkins-docker-plugin |title=georgebashi/jenkins-docker-plugin |publisher=GitHub |date= |accessdate=2017-01-09}}</ref>
* <s>[[Kubernetes]]<ref name="containerizing-docker-on-Kubernetes">{{뉴스 인용 |last=Surana |first=Ramit |url=https://www.linkedin.com/pulse/containerizing-docker-kubernetes-ramit-surana |title=Containerizing Docker on Kubernetes |work=[[LinkedIn]] |date=2015-09-16 |accessdate=2015-11-02 }}</ref></s> Kubenetes 1.20부터 지원하지 않는다.
* [[마이크로소프트 애저]]<ref>{{웹 인용|url=https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/|title=The Docker Virtual Machine Extension for Linux on Azure|date=29 June 2015|publisher=Microsoft|accessdate=11 August 2015|archive-date=2016-03-17|archive-url=https://web.archive.org/web/20160317130223/https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/}}</ref>
* [[오픈스택]] 노바<ref>{{웹 인용 |author=Stefano Maffulli |url=http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |title=OpenStack Community Weekly Newsletter (May 31 – June 7) » The OpenStack Blog |publisher=Openstack.org |date=2013-06-07 |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20131229025044/http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |보존날짜=2013-12-29}}</ref>
* [[OpenSVC]]<ref>{{웹 인용 |url=http://docs.opensvc.com/virtualization.docker.html |title=OpenSVC Docker |publisher=OpenSVC |date= |accessdate=2014-05-29 |보존url=https://web.archive.org/web/20140531090525/http://docs.opensvc.com/virtualization.docker.html |보존날짜=2014-05-31}}</ref>
* 오라클 컨테이너 클라우드 서비스<ref>
{{웹 인용
| last = Native
| first = Cloud
| title = Oracle Container Cloud Service Explained By Oracle.com
| url = https://cloud.oracle.com/container}}
</ref>
* [[퍼핏 (소프트웨어)|퍼핏]]<ref>{{웹 인용 | author = Gareth Rushgrove | url = http://forge.puppetlabs.com/garethr/docker | title = garethr/docker | publisher = Puppet Forge | date = | accessdate = 2014-01-20 }}</ref>
* [[Salt]]<ref>{{웹 인용 |url=http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |title=saltstack/dockerio |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20140203185236/http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |보존날짜=2014-02-03}}</ref>
* [[Vagrant]]<ref>{{웹 인용 |url=https://github.com/philspitler/vagrant-docker |title=philspitler/vagrant-docker |publisher=GitHub |date= |accessdate=2014-01-20 |보존url=https://archive.today/20130809164628/https://github.com/philspitler/vagrant-docker |보존날짜=2013-08-09}}</ref>
* [[VMware vSphere|VMware vSphere Integrated Containers]]<ref>http://searchservervirtualization.techtarget.com/definition/VMware-vSphere-Integrated-Containers-VIC VMware vSphere Integrated Containers (VIC)</ref><ref>http://thenewstack.io/vmwares-photon-platform-and-how-it-treats-containers/ VMware’s Photon Platform and How it Treats Containers</ref>

클라우드 파운드리 Diego 프로젝트는 도커를 [[클라우드 파운드리]] [[PaaS]]에 통합한다.<ref>
{{웹 인용
| last = Whelan
| first = Phil
| title = Cloud Foundry: Diego Explained By Onsi Fakhouri
| url = https://community.spiceworks.com/topic/576560-cloud-foundry-diego-explained-by-onsi-fakhouri
| publisher = ActiveState
| publication-date = 2014-09-03
| accessdate = 2015-04-20
| quote = Functionality is being added to enable end-users to push Docker images directly into a Cloud Foundry cluster running Diego.
}}
</ref>

레드햇의 [[오픈시프트]] PaaS는 도커 및 관련 프로젝트(Kubernetes, Geard, Project Atomic 등)를 v3 (2015년 6월)부터 통합한다.<ref>
{{뉴스 인용
| last = Jackson
| first = Joab
| title = Red Hat to update Docker container tech for enterprises: Open source vendor plans to incorporate advanced Linux tools such as systemd and SELinux into Docker
| url = http://www.computerworld.com/s/article/9247706/Red_Hat_to_update_Docker_container_tech_for_enterprises
| publisher = Computerworld, Inc.
| publication-date = 2014-04-16
| accessdate = 2014-05-29
| quote = Red Hat has also started a second community project, called GearD, to integrate Docker into its PaaS (platform-as-a-service) hosting software, OpenShift Origin.
}}
</ref>

[[Apprenda]] PaaS는 제품 버전 6.0에 도커 컨테이너를 통합한다.<ref>
{{뉴스 인용
| last = Verge
| first = Jason
| title = PaaS and Docker Containers Work Together in Latest Apprenda Release
| url = http://www.datacenterknowledge.com/archives/2015/04/28/paas-and-docker-containers-work-together-in-latest-apprenda-release/
| publisher = Data Center Knowledge
| publication-date = 2015-04-28
| accessdate = 2015-12-06
| quote = The 6.0 release integrates Docker’s flexibility and portability with the compliance, governance and security capabilities that enterprises need from PaaS.
}}
</ref>

== 역사 ==
솔로몬 하익스는 프랑스에서 [[PaaS]] 기업인 [[닷클라우드]] 안에 내부 프로젝트로서 도커를 시작했다.<ref>{{웹 인용|url=https://www.dotcloud.com/|title=One home for all your apps|date=|website=dotcloud.com|보존url=https://web.archive.org/web/20140517031011/https://www.dotcloud.com/|archivedate=2014-05-17|accessdate=2014-05-08}}</ref>

도커는 2013년 3월 오픈 소스로 출시되었다.<ref name="infoq-201303" />

== 사용법 ==

=== CLI를 통한 이용 ===

=== GUI를 통한 이용 ===

==== 도커 데스크탑 ====
도커를 관리하는 GUI 앱으로 이미지를 검색하여 pull하거나 버튼 몇 번으로 이미지 생성, 빌드가 가능하다. 리눅스에서는 사용 불가능하다.

==== IDE/텍스트 편집기를 통한 이용 ====
[[비주얼 스튜디오 코드]]에서 확장기능을 이용하면 GUI를 통해서 도커 이미지를 빌드, 컨테이너 실행, 스택 실행 등이 가능하다. <code>docker exec -it <container> bash</code> 같이 일일이 코드를 치지 않고 버튼을 눌러 컨테이너의 쉘에 접근할 수 있다.

==== portainer 사용 ====

== 도구 ==
=== Docker Compose ===
Compose는 멀티 컨테이너 도커 애플리케이션을 정의하고 실행하는 도구이다.<ref>{{웹 인용|url=https://docs.docker.com/compose/overview/ |title=Overview of Docker Compose |accessdate=2017-07-06}}</ref> [[YAML]] 파일을 사용하여 애플리케이션의 서비스를 구성하며 하나의 명령을 가지고 모든 컨테이너의 생성 및 시작 프로세스를 수행한다. 도커 구 버전에서는 docker-compose를 설치하여야 하지만 신 버전은 docker 명령어에 통합되어 도커를 설치하기만 하면 되고 실행 명령어는 docker-compose 대신 docker compose이다. os마다 다르지만 docker를 패키지 매니저를 통해서 설치하면 구 버전이 설치될 수 있어 docker-compose를 별도로 설치해야 하는 경우가 생긴다. 공식 홈페이지에 소개된 설치 코드를 이용하여 설치하면 거의 최신 버전 설치가 된다.

=== Docker Swarm ===
Docker Swarm은 도커 컨테이너의 네이티브 [[컴퓨터 클러스터|클러스터링]] 기능을 제공하며 하나의 가상 도커 엔진으로 탈바꿈시킨다.<ref>{{웹 인용|url=https://www.linux.com/news/8-open-source-CONTAINER-ORCHESTRATION-TOOLS-KNOW|title=8 Container Orchestration Tools to Know|date=2017-04-12|accessdate=2017-07-06}}</ref>

도커 스웜은 컨테이너 오케스트레이션을 수행할 수 있게 해주며 여러 컴퓨터(노드)들을 클러스터로 구성했을 때 유용하다. 클러스터 중에서 여유 있는 컴퓨터에 자동으로 애플리케이션이 올라가 실행된다. 도커를 스웜 모드로 전환해야 하며 명령어를 통해 스웜 모드가 활성화된 노드들을 서로 연결시켜주어야 한다.

도커 1.12 이상부터 Swarm 모드가 도커 엔진에 통합되어 있다.<ref>{{웹 인용|url=https://docs.docker.com/swarm/ |title=Docker Swarm |accessdate=2017-07-06}}</ref>

비슷한 소프트웨어로는 [[kubernetes]](쿠버네티스)가 있다. 도커 스웜은 진입 장벽이 낮고 학습자나 취미 이용가들에게 적합한 반면 쿠버네티스는 학습 곡선이 가파르고 초보자에게 어렵지만 기능이 강력하고 풍부해서 상업적으로 쿠버네티스를 사용하는 프로젝트가 많다. IT 관련 직종 스펙인 기술 스택에 쿠버네티스가 있는 경우는 흔하지만 도커 스웜은 상대적으로 드문 편.

== 기타 ==
* 도커 안에서 도커를 굴릴 수 있다. 이른바 도커 인 도커(Docker in Docker). 다만 이럴 경우 호스트 도커와 게스트 도커, 그리고 그 안의 컨테이너까지 3중으로 프로세스가 돌아가면서 서버 자원이 상당히 소모된다. Docker out of Docker라고, 게스트 도커가 호스트 도커의 일부 설정을 공유하게 하는 경우도 있는데, 이 경우는 컨테이너 개념이 일부 깨지기에 보안 상으로 영 좋지 않다. 이런 일들이 대표적으로 [[Jenkins|젠킨스]] 같은 지속 통합 소프트웨어를 도커 이미지로 올렸을 때 발생한다. CI 도구로 컨테이너 이미지를 빌드하는 경우가 많기 때문.
* Docker Engine과 안드로이드를 비롯한 많은 임베디드 리눅스 개발 환경이 chroot를 비롯하여 많은 도구들을 공유하기 때문에, '이론상으로는' AMD64 기반 혹은 ARM64 기반 고성능 임베디드 시스템을 커스텀 도커 이미지로 만들고 도커 허브에 올린 다음, 이미지만 받아서 바로 그걸 [[Secure Digital|microSD카드]] 같은 플래시 메모리 장치의 부트 로더 파티션 뒤에 리눅스 dd 명령어 등으로 그대로 박아 넣어 부팅하는 짓이 가능하긴 하다. 문제는 AMD64 임베디드 시스템이라면 모를까, ARM64의 경우 개발 환경 및 타겟 장치 구성이 너무 심하게 파편화되어 ARM64 이미지를 커스텀하기 힘들고, RISC-V나 구형 32bit ARM CPU 및 기타 임베디드 시스템용 CPU/MCU를 도커 측에서 지원하지 않아 저걸 실현 가능한 경우의 수가 매우 한정적이라는 것. 도커로 임베디드 시스템 개발 작업까지 커버하기엔 멀어도 한참 멀었다.

== 같이 보기 ==
* [[데브옵스]]
* [[마이크로서비스]]
* [[서비스 컴포넌트 아키텍처]]
* [[Podman]]
* [[kubernetes]]
* [[위키백과:베이그런트 (소프트웨어)|Vagrant]]

== 외부 링크 ==
* {{공식 웹사이트}}
* [https://www.44bits.io/ko/post/why-should-i-use-docker-container 왜 굳이 도커(컨테이너)를 써야 하나요?]

{{각주|30em}}
{{퍼온문서|문서=도커|퍼온곳=위키백과}}
[[분류:자유 소프트웨어]]
[[분류:가상화 소프트웨어]]

도커

2025-06-07T14:25:48Z

Senouis: /* 기타 */

{{소프트웨어 정보
| 이름 = 도커 Docker
| 로고 = Docker (container engine) logo.svg
| 원작자 = 솔로몬 하익스 (Solomon Hykes)
| 개발자 = [[도커 (기업)|도커(Docker Inc.)]]
| 발표일 =
| 최신 버전 출시일 =
| 프로그래밍 언어 = [[Go (프로그래밍 언어)|Go]]<ref>{{웹 인용|url=https://github.com/docker/distribution |title=Docker source code |work=docs.docker.com |publisher=Docker, Inc. |date=2015-10-12 |accessdate=2015-10-24}}</ref>
| 운영체제 = [[리눅스]], [[마이크로소프트 윈도우|윈도우]], [[macOS]]
| 플랫폼 = 현대의 리눅스 커널이 포함된 [[x86-64]], [[ARM 아키텍처|ARM]] (실험적), 하이퍼-V 기능이 포함된 [[x86-64]] 윈도우
| 종류 = [[운영 체제 수준 가상화]]
| 라이선스 = [[아파치 라이선스]] 2.0
| 웹사이트 = {{URL|https://www.docker.com/}}
}}
'''도커'''(Docker)는 [[리눅스]]의 [[응용 소프트웨어|응용 프로그램]]들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 [[오픈 소스]] 프로젝트이다.

도커 웹 페이지의 기능을 인용하면 다음과 같다:
{{인용문|도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다.<ref>https://www.docker.com/what-docker</ref>}}

도커는 [[리눅스]]에서 [[운영 체제 수준 가상화]]의 추상화 및 자동화 계층을 추가적으로 제공한다.<ref name="SYS-CON Media">{{웹 인용
| last = O'Gara
| first = Maureen
| date = 26 July 2013
| url = http://maureenogara.sys-con.com/node/2747331
| title = Ben Golub, Who Sold Gluster to Red Hat, Now Running dotCloud
| publisher = SYS-CON Media
| accessdate = 2013-08-09
| archive-date = 2019-09-13
| archive-url = https://web.archive.org/web/20190913100835/http://maureenogara.sys-con.com/node/2747331

}}</ref> 도커는 [[cgroups]]와 커널 [[리눅스 이름공간|이름공간]]과 같은 [[리눅스 커널]]의 기능들과 OverayFS, [[aufs]]와 같은 [[유니언 마운트|유니언 가능 파일 시스템]]의 리소스 격리 기능을 사용하며,<ref>{{웹 인용|title = docker/docker|url = https://github.com/docker/docker/blob/990a3e30fa66e7bd3df3c78c873c97c5b1310486/daemon/graphdriver/driver.go#L37-L43|website = GitHub|accessdate = 2015-12-29}}</ref> 이를 통해 독립적인 "컨테이너"가 하나의 리눅스 인스턴스 안에서 실행할 수 있게 함으로써 [[가상 머신]]을 시작하여 유지보수해야 하는 부담을 없애준다.<ref>{{웹 인용
| url = http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| archiveurl = https://web.archive.org/web/20140821065734/http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| title = Docker Documentation: Kernel Requirements
| date = 2014-01-04 | accessdate = 2014-08-20 | archivedate = 2014-08-21
| website = docker.readthedocs.org
}}</ref>

리눅스 커널의 이름공간 지원은 대체적으로<ref>{{웹 인용|url=http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/|title=Yet Another Reason Containers Don't Contain: Kernel Keyrings|author=Dan Walsh|work=projectatomic.io|accessdate=13 April 2015|archive-date=2015-04-13|archive-url=https://web.archive.org/web/20150413062633/http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/}}</ref> 프로세스 트리, 네트워크 사용자 ID, 마운트된 파일 시스템을 포함한 운영 환경에 대한 응용 프로그램의 관점을 격리시키지만, 커널의 cgroup들은 CPU, 메모리, 블록 입출력, 네트워크를 포함한 리소스 제한을 제공한다. 버전 0.9부터 도커는 [[libvirt]], [[LXC]] (리눅스 컨테이너), [[systemd-nspawn]]을 통한 추상화된 가상화 인터페이스를 사용하는 것 뿐 아니라 리눅스 커널이 제공하는 가상화 기능을 직접 사용하기 위한 유일한 수단으로 libcontainer [[라이브러리 (컴퓨팅)|라이브러리]]를 포함하고 있다.<ref name="zdnet-7000030397">{{웹 인용
| url = http://www.zdnet.com/docker-libcontainer-unifies-linux-container-powers-7000030397/
| title = Docker libcontainer unifies Linux container powers
| date = 2014-06-11 | accessdate = 2014-07-30
| author = Steven J. Vaughan-Nichols | publisher = [[ZDNet]]
}}</ref><ref>{{웹 인용
| url = https://github.com/docker/libcontainer/blob/master/README.md
| title = libcontainer - reference implementation for containers
| accessdate = 2014-07-30
| website = github.com
}}</ref><ref name="docker-blog-201403">{{웹 인용
| url = http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
| title = Docker 0.9: Introducing execution drivers and libcontainer
| date = 2014-03-10
| accessdate = 2015-01-20
| website = docker.com
| archive-date = 2015-02-21
| archive-url = https://web.archive.org/web/20150221134532/http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
}}</ref>

== 개요 ==
[[파일:Docker-linux-interfaces.svg|섬네일|도커는 리눅스 커널의 가상화 기능에 접근하기 위해 각기 다른 인터페이스를 사용할 수 있다.<ref name="docker-blog-201403" />]]

도커 베이스 이미지에 액션을 취하면, 유니언 파일 시스템 계층들이 만들어지고 문서화되는데, 이렇게 함으로써 각 계층은 어떻게 액션을 재생성할지에 대해 완전하게 기술하게 된다. 이러한 전략은 이를테면 완전한 VM과 비교하면 도커의 이미지를 가볍게 만들어주며, 오직 레이어 업데이트만 전파해 주면 된다.

산업 애널리스트 기업 451 리서치에 따르면, "도커는 응용 프로그램과 그 의존성을 가상 컨테이너에 담을 수 있는 도구이며, 이 컨테이너는 어떠한 리눅스 서버에서라도 구동이 가능하다. 이것은 [[사내 소프트웨어|사내]], [[클라우드 컴퓨팅|공용 클라우드]], [[클라우드 컴퓨팅|개인 클라우드]], [[베어 메탈 서버|베어 메탈]] 등 응용 프로그램을 실행할 수 있는 곳에서는 유연성과 이식성을 적용하는데 도움을 준다.<ref name="Linux">{{웹 인용
| last = Noyes
| first = Katherine
| date = 1 August 2013
| url = http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code
| title = Docker: A 'Shipping Container' for Linux Code
| publisher = [[Linux.com]]
| accessdate = 2013-08-09
| 보존url = https://web.archive.org/web/20130808043357/http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code/
| 보존날짜 = 2013-08-08
}}</ref>

도커는 고급 [[API]]를 구현함으로써 프로세스들을 별도의 장소에서 실행할 수 있는 가벼운 컨테이너들을 제공한다.<ref name="infoq-201303">{{웹 인용
| last = Avram
| first = Abel
| date = 2013-03-27
| url = http://www.infoq.com/news/2013/03/Docker
| title = Docker: Automated and Consistent Software Deployments
| publisher = InfoQ
| accessdate = 2013-08-09
}}</ref>

[[리눅스 커널]]이 제공하는 기능들(주로 cgroups와 이름공간) 위에 빌드되기 때문에 도커 컨테이너는 가상 머신과는 달리 별도의 운영 체제를 요구하거나 포함하지 않는다.<ref name="Linux" /> 그 대신, 커널의 기능에 의존하며 리소스 격리(CPU, 메모리, 블록 입출력, 네트워크 등) 및 [[이름공간 격리|격리된 이름공간]]을 사용하여 운영 체제에 대한 응용 프로그램의 관점을 격리시킨다. 도커는 도커 0.9대부터 이용 가능한 libcontainer 라이브러리를 사용하거나 [[libvirt]], [[LXC]] (리눅스 컨테이너), 또는 [[systemd-nspawn]]을 통해 간접적으로 리눅스 커널의 가상화 기능들에 접근한다.<ref name="docker-blog-201403" /><ref name="infoq-201403">{{웹 인용
| last = Swan
| first = Chris
| date = 2014-03-13
| url = http://www.infoq.com/news/2014/03/docker_0_9
| title = Docker drops LXC as default execution environment
| publisher = InfoQ
| accessdate = 2015-01-20
}}</ref>

도커는 매우 가볍기 때문에, 하나의 서버나 가상 머신이 여러 컨테이너들을 동시에 구동할 수 있다.

컨테이너를 사용하여 리소스를 격리시키고, 서비스를 제한시키며, 프로세스를 예비할 수 있으며 이렇게 하여 자신만의 프로세스 ID 공간, 파일 시스템 구조, 네트워크 인터페이스를 갖고서 운영 체제에 대하여 거의 완전히 개인화된 관점을 갖게 한다. 여러 개의 컨테이너들은 동일한 커널은 공유하지만 각 컨테이너는 CPU, 메모리, 입출력과 같이 오직 정의된 양의 리소스에만 제한을 받을 수 있다.

도커를 사용하여 컨테이너를 만들고 관리하면 다수의 응용 프로그램, 작업자의 작업, 다른 프로세스들이 자율적으로 하나의 물리 머신이나 여러 개의 가상 머신을 통해 구동될 수 있게 되므로 고도의 [[분산 시스템]]을 생성하는 일이 단순해진다. 리소스가 사용 가능해질 때 또는 더 많은 노드가 필요할 때 노드가 배치될 수 있게 하므로 [[Apache Cassandra]], [[몽고DB]], [[Riak]]와 같은 시스템을 위한 [[PaaS]] 스타일의 배치 및 규모 증강이 가능해진다. 또, 도커는 작업이나 워크로드 큐, 기타 분산 시스템들의 생성 및 운영을 단순하게 한다.<ref name="CloudAve">{{웹 인용
| last = Hall
| first = Adron
| date = 31 July 2013
| url = http://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
| title = OSCON : Conversations, Deployments, Architecture, Docker and the Future?
| publisher = CloudAve
| accessdate = 2013-08-09
| archive-date = 2019-03-27
| archive-url = https://web.archive.org/web/20190327103543/https://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
}}</ref><ref name="Iron.io">{{웹 인용
|last = Reeder
|first = Travis
|date = 22 April 2014
|url = http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|title = How Docker Helped Us Achieve the (Near) Impossible
|publisher = Iron.io
|accessdate = 2014-07-25
|보존url = https://web.archive.org/web/20140808031809/http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|보존날짜 = 2014-08-08
}}</ref>

=== 통합 ===
도커는 다음을 포함한 다양한 인프라스트럭처 도구들에 통합될 수 있다.

* [[아마존 웹 서비스]]<ref>{{웹 인용 |url=https://docs.docker.com/installation/amazon/ |title=Amazon EC2 - Docker Documentation |website=docs.docker.com |date= |accessdate=2014-10-18 |보존url=https://archive.today/20141018090321/https://docs.docker.com/installation/amazon/ |보존날짜=2014-10-18}}</ref>
* [[Ansible]]<ref>{{웹 인용 |author=/ |url=https://github.com/ansible/ansible/blob/devel/library/cloud/docker |title=ansible/library/cloud/docker |publisher=[[GitHub]] |date= |accessdate=2014-01-20 |보존url=https://archive.today/20131227071413/https://github.com/ansible/ansible/blob/devel/library/cloud/docker |보존날짜=2013-12-27}}</ref>
* [[CFEngine]]<ref>{{웹 인용|url=http://docs.docker.com/examples/cfengine_process_management/|title=CFEngine|publisher=CFEngine|date=|accessdate=2014-06-06|보존url=https://web.archive.org/web/20140613180312/http://docs.docker.com/examples/cfengine_process_management/|보존날짜=2014-06-13}}</ref>
* [[Chef]]<ref>{{웹 인용|url=https://github.com/thoward/docker-cookbook |title=thoward/docker-cookbook |publisher=GitHub |date= |accessdate=2014-01-20}}</ref>
* [[구글 클라우드 플랫폼]]<ref>{{웹 인용|title=Containers on Google Cloud Platform|url=https://cloud.google.com/compute/docs/containers|publisher=Google Inc}}</ref>
* IBM [[블루믹스]]<ref>{{웹 인용 |url=https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/ |title=Bluemix Launches IBM Containers Beta Based on Docker |publisher=IBM |date=2014-12-04 |accessdate=2015-04-20 |archive-date=2015-04-28 |archive-url=https://web.archive.org/web/20150428181821/https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/}}</ref>
* HPE Helion Stackato
* [[Jelastic]]<ref>{{웹 인용 |url=http://www.prweb.com/releases/2014/12/prweb12361294.htm/ |title=Jelastic Announces Docker Integration to Provide the Most Advanced Orchestrated Application Delivery |publisher=PRWeb|date= |accessdate=2014-12-03}}</ref>
* [[젠킨스]]<ref>{{웹 인용|url=https://github.com/georgebashi/jenkins-docker-plugin |title=georgebashi/jenkins-docker-plugin |publisher=GitHub |date= |accessdate=2017-01-09}}</ref>
* <s>[[Kubernetes]]<ref name="containerizing-docker-on-Kubernetes">{{뉴스 인용 |last=Surana |first=Ramit |url=https://www.linkedin.com/pulse/containerizing-docker-kubernetes-ramit-surana |title=Containerizing Docker on Kubernetes |work=[[LinkedIn]] |date=2015-09-16 |accessdate=2015-11-02 }}</ref></s> Kubenetes 1.20부터 지원하지 않는다.
* [[마이크로소프트 애저]]<ref>{{웹 인용|url=https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/|title=The Docker Virtual Machine Extension for Linux on Azure|date=29 June 2015|publisher=Microsoft|accessdate=11 August 2015|archive-date=2016-03-17|archive-url=https://web.archive.org/web/20160317130223/https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/}}</ref>
* [[오픈스택]] 노바<ref>{{웹 인용 |author=Stefano Maffulli |url=http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |title=OpenStack Community Weekly Newsletter (May 31 – June 7) » The OpenStack Blog |publisher=Openstack.org |date=2013-06-07 |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20131229025044/http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |보존날짜=2013-12-29}}</ref>
* [[OpenSVC]]<ref>{{웹 인용 |url=http://docs.opensvc.com/virtualization.docker.html |title=OpenSVC Docker |publisher=OpenSVC |date= |accessdate=2014-05-29 |보존url=https://web.archive.org/web/20140531090525/http://docs.opensvc.com/virtualization.docker.html |보존날짜=2014-05-31}}</ref>
* 오라클 컨테이너 클라우드 서비스<ref>
{{웹 인용
| last = Native
| first = Cloud
| title = Oracle Container Cloud Service Explained By Oracle.com
| url = https://cloud.oracle.com/container}}
</ref>
* [[퍼핏 (소프트웨어)|퍼핏]]<ref>{{웹 인용 | author = Gareth Rushgrove | url = http://forge.puppetlabs.com/garethr/docker | title = garethr/docker | publisher = Puppet Forge | date = | accessdate = 2014-01-20 }}</ref>
* [[Salt]]<ref>{{웹 인용 |url=http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |title=saltstack/dockerio |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20140203185236/http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |보존날짜=2014-02-03}}</ref>
* [[Vagrant]]<ref>{{웹 인용 |url=https://github.com/philspitler/vagrant-docker |title=philspitler/vagrant-docker |publisher=GitHub |date= |accessdate=2014-01-20 |보존url=https://archive.today/20130809164628/https://github.com/philspitler/vagrant-docker |보존날짜=2013-08-09}}</ref>
* [[VMware vSphere|VMware vSphere Integrated Containers]]<ref>http://searchservervirtualization.techtarget.com/definition/VMware-vSphere-Integrated-Containers-VIC VMware vSphere Integrated Containers (VIC)</ref><ref>http://thenewstack.io/vmwares-photon-platform-and-how-it-treats-containers/ VMware’s Photon Platform and How it Treats Containers</ref>

클라우드 파운드리 Diego 프로젝트는 도커를 [[클라우드 파운드리]] [[PaaS]]에 통합한다.<ref>
{{웹 인용
| last = Whelan
| first = Phil
| title = Cloud Foundry: Diego Explained By Onsi Fakhouri
| url = https://community.spiceworks.com/topic/576560-cloud-foundry-diego-explained-by-onsi-fakhouri
| publisher = ActiveState
| publication-date = 2014-09-03
| accessdate = 2015-04-20
| quote = Functionality is being added to enable end-users to push Docker images directly into a Cloud Foundry cluster running Diego.
}}
</ref>

레드햇의 [[오픈시프트]] PaaS는 도커 및 관련 프로젝트(Kubernetes, Geard, Project Atomic 등)를 v3 (2015년 6월)부터 통합한다.<ref>
{{뉴스 인용
| last = Jackson
| first = Joab
| title = Red Hat to update Docker container tech for enterprises: Open source vendor plans to incorporate advanced Linux tools such as systemd and SELinux into Docker
| url = http://www.computerworld.com/s/article/9247706/Red_Hat_to_update_Docker_container_tech_for_enterprises
| publisher = Computerworld, Inc.
| publication-date = 2014-04-16
| accessdate = 2014-05-29
| quote = Red Hat has also started a second community project, called GearD, to integrate Docker into its PaaS (platform-as-a-service) hosting software, OpenShift Origin.
}}
</ref>

[[Apprenda]] PaaS는 제품 버전 6.0에 도커 컨테이너를 통합한다.<ref>
{{뉴스 인용
| last = Verge
| first = Jason
| title = PaaS and Docker Containers Work Together in Latest Apprenda Release
| url = http://www.datacenterknowledge.com/archives/2015/04/28/paas-and-docker-containers-work-together-in-latest-apprenda-release/
| publisher = Data Center Knowledge
| publication-date = 2015-04-28
| accessdate = 2015-12-06
| quote = The 6.0 release integrates Docker’s flexibility and portability with the compliance, governance and security capabilities that enterprises need from PaaS.
}}
</ref>

== 역사 ==
솔로몬 하익스는 프랑스에서 [[PaaS]] 기업인 [[닷클라우드]] 안에 내부 프로젝트로서 도커를 시작했다.<ref>{{웹 인용|url=https://www.dotcloud.com/|title=One home for all your apps|date=|website=dotcloud.com|보존url=https://web.archive.org/web/20140517031011/https://www.dotcloud.com/|archivedate=2014-05-17|accessdate=2014-05-08}}</ref>

도커는 2013년 3월 오픈 소스로 출시되었다.<ref name="infoq-201303" />

== 사용법 ==

=== CLI를 통한 이용 ===

=== GUI를 통한 이용 ===

==== 도커 데스크탑 ====
도커를 관리하는 GUI 앱으로 이미지를 검색하여 pull하거나 버튼 몇 번으로 이미지 생성, 빌드가 가능하다. 리눅스에서는 사용 불가능하다.

==== IDE/텍스트 편집기를 통한 이용 ====
[[비주얼 스튜디오 코드]]에서 확장기능을 이용하면 GUI를 통해서 도커 이미지를 빌드, 컨테이너 실행, 스택 실행 등이 가능하다. <code>docker exec -it <container> bash</code> 같이 일일이 코드를 치지 않고 버튼을 눌러 컨테이너의 쉘에 접근할 수 있다.

==== portainer 사용 ====

== 도구 ==
=== Docker Compose ===
Compose는 멀티 컨테이너 도커 애플리케이션을 정의하고 실행하는 도구이다.<ref>{{웹 인용|url=https://docs.docker.com/compose/overview/ |title=Overview of Docker Compose |accessdate=2017-07-06}}</ref> [[YAML]] 파일을 사용하여 애플리케이션의 서비스를 구성하며 하나의 명령을 가지고 모든 컨테이너의 생성 및 시작 프로세스를 수행한다. 도커 구 버전에서는 docker-compose를 설치하여야 하지만 신 버전은 docker 명령어에 통합되어 도커를 설치하기만 하면 되고 실행 명령어는 docker-compose 대신 docker compose이다. os마다 다르지만 docker를 패키지 매니저를 통해서 설치하면 구 버전이 설치될 수 있어 docker-compose를 별도로 설치해야 하는 경우가 생긴다. 공식 홈페이지에 소개된 설치 코드를 이용하여 설치하면 거의 최신 버전 설치가 된다.

=== Docker Swarm ===
Docker Swarm은 도커 컨테이너의 네이티브 [[컴퓨터 클러스터|클러스터링]] 기능을 제공하며 하나의 가상 도커 엔진으로 탈바꿈시킨다.<ref>{{웹 인용|url=https://www.linux.com/news/8-open-source-CONTAINER-ORCHESTRATION-TOOLS-KNOW|title=8 Container Orchestration Tools to Know|date=2017-04-12|accessdate=2017-07-06}}</ref>

도커 스웜은 컨테이너 오케스트레이션을 수행할 수 있게 해주며 여러 컴퓨터(노드)들을 클러스터로 구성했을 때 유용하다. 클러스터 중에서 여유 있는 컴퓨터에 자동으로 애플리케이션이 올라가 실행된다. 도커를 스웜 모드로 전환해야 하며 명령어를 통해 스웜 모드가 활성화된 노드들을 서로 연결시켜주어야 한다.

도커 1.12 이상부터 Swarm 모드가 도커 엔진에 통합되어 있다.<ref>{{웹 인용|url=https://docs.docker.com/swarm/ |title=Docker Swarm |accessdate=2017-07-06}}</ref>

비슷한 소프트웨어로는 [[kubernetes]](쿠버네티스)가 있다. 도커 스웜은 진입 장벽이 낮고 학습자나 취미 이용가들에게 적합한 반면 쿠버네티스는 학습 곡선이 가파르고 초보자에게 어렵지만 기능이 강력하고 풍부해서 상업적으로 쿠버네티스를 사용하는 프로젝트가 많다. IT 관련 직종 스펙인 기술 스택에 쿠버네티스가 있는 경우는 흔하지만 도커 스웜은 상대적으로 드문 편.

== 기타 ==
* 도커 안에서 도커를 굴릴 수 있다. 이른바 도커 인 도커(Docker in Docker). 다만 이럴 경우 호스트 도커와 게스트 도커, 그리고 그 안의 컨테이너까지 3중으로 프로세스가 돌아가면서 서버 자원이 상당히 소모된다. Docker out of Docker라고, 게스트 도커가 호스트 도커의 일부 설정을 공유하게 하는 경우도 있는데, 이 경우는 컨테이너 개념이 일부 깨지기에 보안 상으로 영 좋지 않다. 이런 일들이 대표적으로 [[Jenkins|젠킨스]] 같은 지속 통합 소프트웨어를 도커 이미지로 올렸을 때 발생한다. CI 도구로 컨테이너 이미지를 빌드하는 경우가 많기 때문.

== 같이 보기 ==
* [[데브옵스]]
* [[마이크로서비스]]
* [[서비스 컴포넌트 아키텍처]]
* [[Podman]]
* [[kubernetes]]
* [[위키백과:베이그런트 (소프트웨어)|Vagrant]]

== 외부 링크 ==
* {{공식 웹사이트}}
* [https://www.44bits.io/ko/post/why-should-i-use-docker-container 왜 굳이 도커(컨테이너)를 써야 하나요?]

{{각주|30em}}
{{퍼온문서|문서=도커|퍼온곳=위키백과}}
[[분류:자유 소프트웨어]]
[[분류:가상화 소프트웨어]]

도커

2025-06-07T14:24:45Z

Senouis: /* 통합 */ 쿠버네티스 제외

{{소프트웨어 정보
| 이름 = 도커 Docker
| 로고 = Docker (container engine) logo.svg
| 원작자 = 솔로몬 하익스 (Solomon Hykes)
| 개발자 = [[도커 (기업)|도커(Docker Inc.)]]
| 발표일 =
| 최신 버전 출시일 =
| 프로그래밍 언어 = [[Go (프로그래밍 언어)|Go]]<ref>{{웹 인용|url=https://github.com/docker/distribution |title=Docker source code |work=docs.docker.com |publisher=Docker, Inc. |date=2015-10-12 |accessdate=2015-10-24}}</ref>
| 운영체제 = [[리눅스]], [[마이크로소프트 윈도우|윈도우]], [[macOS]]
| 플랫폼 = 현대의 리눅스 커널이 포함된 [[x86-64]], [[ARM 아키텍처|ARM]] (실험적), 하이퍼-V 기능이 포함된 [[x86-64]] 윈도우
| 종류 = [[운영 체제 수준 가상화]]
| 라이선스 = [[아파치 라이선스]] 2.0
| 웹사이트 = {{URL|https://www.docker.com/}}
}}
'''도커'''(Docker)는 [[리눅스]]의 [[응용 소프트웨어|응용 프로그램]]들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 [[오픈 소스]] 프로젝트이다.

도커 웹 페이지의 기능을 인용하면 다음과 같다:
{{인용문|도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다.<ref>https://www.docker.com/what-docker</ref>}}

도커는 [[리눅스]]에서 [[운영 체제 수준 가상화]]의 추상화 및 자동화 계층을 추가적으로 제공한다.<ref name="SYS-CON Media">{{웹 인용
| last = O'Gara
| first = Maureen
| date = 26 July 2013
| url = http://maureenogara.sys-con.com/node/2747331
| title = Ben Golub, Who Sold Gluster to Red Hat, Now Running dotCloud
| publisher = SYS-CON Media
| accessdate = 2013-08-09
| archive-date = 2019-09-13
| archive-url = https://web.archive.org/web/20190913100835/http://maureenogara.sys-con.com/node/2747331

}}</ref> 도커는 [[cgroups]]와 커널 [[리눅스 이름공간|이름공간]]과 같은 [[리눅스 커널]]의 기능들과 OverayFS, [[aufs]]와 같은 [[유니언 마운트|유니언 가능 파일 시스템]]의 리소스 격리 기능을 사용하며,<ref>{{웹 인용|title = docker/docker|url = https://github.com/docker/docker/blob/990a3e30fa66e7bd3df3c78c873c97c5b1310486/daemon/graphdriver/driver.go#L37-L43|website = GitHub|accessdate = 2015-12-29}}</ref> 이를 통해 독립적인 "컨테이너"가 하나의 리눅스 인스턴스 안에서 실행할 수 있게 함으로써 [[가상 머신]]을 시작하여 유지보수해야 하는 부담을 없애준다.<ref>{{웹 인용
| url = http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| archiveurl = https://web.archive.org/web/20140821065734/http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| title = Docker Documentation: Kernel Requirements
| date = 2014-01-04 | accessdate = 2014-08-20 | archivedate = 2014-08-21
| website = docker.readthedocs.org
}}</ref>

리눅스 커널의 이름공간 지원은 대체적으로<ref>{{웹 인용|url=http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/|title=Yet Another Reason Containers Don't Contain: Kernel Keyrings|author=Dan Walsh|work=projectatomic.io|accessdate=13 April 2015|archive-date=2015-04-13|archive-url=https://web.archive.org/web/20150413062633/http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/}}</ref> 프로세스 트리, 네트워크 사용자 ID, 마운트된 파일 시스템을 포함한 운영 환경에 대한 응용 프로그램의 관점을 격리시키지만, 커널의 cgroup들은 CPU, 메모리, 블록 입출력, 네트워크를 포함한 리소스 제한을 제공한다. 버전 0.9부터 도커는 [[libvirt]], [[LXC]] (리눅스 컨테이너), [[systemd-nspawn]]을 통한 추상화된 가상화 인터페이스를 사용하는 것 뿐 아니라 리눅스 커널이 제공하는 가상화 기능을 직접 사용하기 위한 유일한 수단으로 libcontainer [[라이브러리 (컴퓨팅)|라이브러리]]를 포함하고 있다.<ref name="zdnet-7000030397">{{웹 인용
| url = http://www.zdnet.com/docker-libcontainer-unifies-linux-container-powers-7000030397/
| title = Docker libcontainer unifies Linux container powers
| date = 2014-06-11 | accessdate = 2014-07-30
| author = Steven J. Vaughan-Nichols | publisher = [[ZDNet]]
}}</ref><ref>{{웹 인용
| url = https://github.com/docker/libcontainer/blob/master/README.md
| title = libcontainer - reference implementation for containers
| accessdate = 2014-07-30
| website = github.com
}}</ref><ref name="docker-blog-201403">{{웹 인용
| url = http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
| title = Docker 0.9: Introducing execution drivers and libcontainer
| date = 2014-03-10
| accessdate = 2015-01-20
| website = docker.com
| archive-date = 2015-02-21
| archive-url = https://web.archive.org/web/20150221134532/http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
}}</ref>

== 개요 ==
[[파일:Docker-linux-interfaces.svg|섬네일|도커는 리눅스 커널의 가상화 기능에 접근하기 위해 각기 다른 인터페이스를 사용할 수 있다.<ref name="docker-blog-201403" />]]

도커 베이스 이미지에 액션을 취하면, 유니언 파일 시스템 계층들이 만들어지고 문서화되는데, 이렇게 함으로써 각 계층은 어떻게 액션을 재생성할지에 대해 완전하게 기술하게 된다. 이러한 전략은 이를테면 완전한 VM과 비교하면 도커의 이미지를 가볍게 만들어주며, 오직 레이어 업데이트만 전파해 주면 된다.

산업 애널리스트 기업 451 리서치에 따르면, "도커는 응용 프로그램과 그 의존성을 가상 컨테이너에 담을 수 있는 도구이며, 이 컨테이너는 어떠한 리눅스 서버에서라도 구동이 가능하다. 이것은 [[사내 소프트웨어|사내]], [[클라우드 컴퓨팅|공용 클라우드]], [[클라우드 컴퓨팅|개인 클라우드]], [[베어 메탈 서버|베어 메탈]] 등 응용 프로그램을 실행할 수 있는 곳에서는 유연성과 이식성을 적용하는데 도움을 준다.<ref name="Linux">{{웹 인용
| last = Noyes
| first = Katherine
| date = 1 August 2013
| url = http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code
| title = Docker: A 'Shipping Container' for Linux Code
| publisher = [[Linux.com]]
| accessdate = 2013-08-09
| 보존url = https://web.archive.org/web/20130808043357/http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code/
| 보존날짜 = 2013-08-08
}}</ref>

도커는 고급 [[API]]를 구현함으로써 프로세스들을 별도의 장소에서 실행할 수 있는 가벼운 컨테이너들을 제공한다.<ref name="infoq-201303">{{웹 인용
| last = Avram
| first = Abel
| date = 2013-03-27
| url = http://www.infoq.com/news/2013/03/Docker
| title = Docker: Automated and Consistent Software Deployments
| publisher = InfoQ
| accessdate = 2013-08-09
}}</ref>

[[리눅스 커널]]이 제공하는 기능들(주로 cgroups와 이름공간) 위에 빌드되기 때문에 도커 컨테이너는 가상 머신과는 달리 별도의 운영 체제를 요구하거나 포함하지 않는다.<ref name="Linux" /> 그 대신, 커널의 기능에 의존하며 리소스 격리(CPU, 메모리, 블록 입출력, 네트워크 등) 및 [[이름공간 격리|격리된 이름공간]]을 사용하여 운영 체제에 대한 응용 프로그램의 관점을 격리시킨다. 도커는 도커 0.9대부터 이용 가능한 libcontainer 라이브러리를 사용하거나 [[libvirt]], [[LXC]] (리눅스 컨테이너), 또는 [[systemd-nspawn]]을 통해 간접적으로 리눅스 커널의 가상화 기능들에 접근한다.<ref name="docker-blog-201403" /><ref name="infoq-201403">{{웹 인용
| last = Swan
| first = Chris
| date = 2014-03-13
| url = http://www.infoq.com/news/2014/03/docker_0_9
| title = Docker drops LXC as default execution environment
| publisher = InfoQ
| accessdate = 2015-01-20
}}</ref>

도커는 매우 가볍기 때문에, 하나의 서버나 가상 머신이 여러 컨테이너들을 동시에 구동할 수 있다.

컨테이너를 사용하여 리소스를 격리시키고, 서비스를 제한시키며, 프로세스를 예비할 수 있으며 이렇게 하여 자신만의 프로세스 ID 공간, 파일 시스템 구조, 네트워크 인터페이스를 갖고서 운영 체제에 대하여 거의 완전히 개인화된 관점을 갖게 한다. 여러 개의 컨테이너들은 동일한 커널은 공유하지만 각 컨테이너는 CPU, 메모리, 입출력과 같이 오직 정의된 양의 리소스에만 제한을 받을 수 있다.

도커를 사용하여 컨테이너를 만들고 관리하면 다수의 응용 프로그램, 작업자의 작업, 다른 프로세스들이 자율적으로 하나의 물리 머신이나 여러 개의 가상 머신을 통해 구동될 수 있게 되므로 고도의 [[분산 시스템]]을 생성하는 일이 단순해진다. 리소스가 사용 가능해질 때 또는 더 많은 노드가 필요할 때 노드가 배치될 수 있게 하므로 [[Apache Cassandra]], [[몽고DB]], [[Riak]]와 같은 시스템을 위한 [[PaaS]] 스타일의 배치 및 규모 증강이 가능해진다. 또, 도커는 작업이나 워크로드 큐, 기타 분산 시스템들의 생성 및 운영을 단순하게 한다.<ref name="CloudAve">{{웹 인용
| last = Hall
| first = Adron
| date = 31 July 2013
| url = http://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
| title = OSCON : Conversations, Deployments, Architecture, Docker and the Future?
| publisher = CloudAve
| accessdate = 2013-08-09
| archive-date = 2019-03-27
| archive-url = https://web.archive.org/web/20190327103543/https://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
}}</ref><ref name="Iron.io">{{웹 인용
|last = Reeder
|first = Travis
|date = 22 April 2014
|url = http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|title = How Docker Helped Us Achieve the (Near) Impossible
|publisher = Iron.io
|accessdate = 2014-07-25
|보존url = https://web.archive.org/web/20140808031809/http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|보존날짜 = 2014-08-08
}}</ref>

=== 통합 ===
도커는 다음을 포함한 다양한 인프라스트럭처 도구들에 통합될 수 있다.

* [[아마존 웹 서비스]]<ref>{{웹 인용 |url=https://docs.docker.com/installation/amazon/ |title=Amazon EC2 - Docker Documentation |website=docs.docker.com |date= |accessdate=2014-10-18 |보존url=https://archive.today/20141018090321/https://docs.docker.com/installation/amazon/ |보존날짜=2014-10-18}}</ref>
* [[Ansible]]<ref>{{웹 인용 |author=/ |url=https://github.com/ansible/ansible/blob/devel/library/cloud/docker |title=ansible/library/cloud/docker |publisher=[[GitHub]] |date= |accessdate=2014-01-20 |보존url=https://archive.today/20131227071413/https://github.com/ansible/ansible/blob/devel/library/cloud/docker |보존날짜=2013-12-27}}</ref>
* [[CFEngine]]<ref>{{웹 인용|url=http://docs.docker.com/examples/cfengine_process_management/|title=CFEngine|publisher=CFEngine|date=|accessdate=2014-06-06|보존url=https://web.archive.org/web/20140613180312/http://docs.docker.com/examples/cfengine_process_management/|보존날짜=2014-06-13}}</ref>
* [[Chef]]<ref>{{웹 인용|url=https://github.com/thoward/docker-cookbook |title=thoward/docker-cookbook |publisher=GitHub |date= |accessdate=2014-01-20}}</ref>
* [[구글 클라우드 플랫폼]]<ref>{{웹 인용|title=Containers on Google Cloud Platform|url=https://cloud.google.com/compute/docs/containers|publisher=Google Inc}}</ref>
* IBM [[블루믹스]]<ref>{{웹 인용 |url=https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/ |title=Bluemix Launches IBM Containers Beta Based on Docker |publisher=IBM |date=2014-12-04 |accessdate=2015-04-20 |archive-date=2015-04-28 |archive-url=https://web.archive.org/web/20150428181821/https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/}}</ref>
* HPE Helion Stackato
* [[Jelastic]]<ref>{{웹 인용 |url=http://www.prweb.com/releases/2014/12/prweb12361294.htm/ |title=Jelastic Announces Docker Integration to Provide the Most Advanced Orchestrated Application Delivery |publisher=PRWeb|date= |accessdate=2014-12-03}}</ref>
* [[젠킨스]]<ref>{{웹 인용|url=https://github.com/georgebashi/jenkins-docker-plugin |title=georgebashi/jenkins-docker-plugin |publisher=GitHub |date= |accessdate=2017-01-09}}</ref>
* <s>[[Kubernetes]]<ref name="containerizing-docker-on-Kubernetes">{{뉴스 인용 |last=Surana |first=Ramit |url=https://www.linkedin.com/pulse/containerizing-docker-kubernetes-ramit-surana |title=Containerizing Docker on Kubernetes |work=[[LinkedIn]] |date=2015-09-16 |accessdate=2015-11-02 }}</ref></s> Kubenetes 1.20부터 지원하지 않는다.
* [[마이크로소프트 애저]]<ref>{{웹 인용|url=https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/|title=The Docker Virtual Machine Extension for Linux on Azure|date=29 June 2015|publisher=Microsoft|accessdate=11 August 2015|archive-date=2016-03-17|archive-url=https://web.archive.org/web/20160317130223/https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/}}</ref>
* [[오픈스택]] 노바<ref>{{웹 인용 |author=Stefano Maffulli |url=http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |title=OpenStack Community Weekly Newsletter (May 31 – June 7) » The OpenStack Blog |publisher=Openstack.org |date=2013-06-07 |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20131229025044/http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |보존날짜=2013-12-29}}</ref>
* [[OpenSVC]]<ref>{{웹 인용 |url=http://docs.opensvc.com/virtualization.docker.html |title=OpenSVC Docker |publisher=OpenSVC |date= |accessdate=2014-05-29 |보존url=https://web.archive.org/web/20140531090525/http://docs.opensvc.com/virtualization.docker.html |보존날짜=2014-05-31}}</ref>
* 오라클 컨테이너 클라우드 서비스<ref>
{{웹 인용
| last = Native
| first = Cloud
| title = Oracle Container Cloud Service Explained By Oracle.com
| url = https://cloud.oracle.com/container}}
</ref>
* [[퍼핏 (소프트웨어)|퍼핏]]<ref>{{웹 인용 | author = Gareth Rushgrove | url = http://forge.puppetlabs.com/garethr/docker | title = garethr/docker | publisher = Puppet Forge | date = | accessdate = 2014-01-20 }}</ref>
* [[Salt]]<ref>{{웹 인용 |url=http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |title=saltstack/dockerio |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20140203185236/http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |보존날짜=2014-02-03}}</ref>
* [[Vagrant]]<ref>{{웹 인용 |url=https://github.com/philspitler/vagrant-docker |title=philspitler/vagrant-docker |publisher=GitHub |date= |accessdate=2014-01-20 |보존url=https://archive.today/20130809164628/https://github.com/philspitler/vagrant-docker |보존날짜=2013-08-09}}</ref>
* [[VMware vSphere|VMware vSphere Integrated Containers]]<ref>http://searchservervirtualization.techtarget.com/definition/VMware-vSphere-Integrated-Containers-VIC VMware vSphere Integrated Containers (VIC)</ref><ref>http://thenewstack.io/vmwares-photon-platform-and-how-it-treats-containers/ VMware’s Photon Platform and How it Treats Containers</ref>

클라우드 파운드리 Diego 프로젝트는 도커를 [[클라우드 파운드리]] [[PaaS]]에 통합한다.<ref>
{{웹 인용
| last = Whelan
| first = Phil
| title = Cloud Foundry: Diego Explained By Onsi Fakhouri
| url = https://community.spiceworks.com/topic/576560-cloud-foundry-diego-explained-by-onsi-fakhouri
| publisher = ActiveState
| publication-date = 2014-09-03
| accessdate = 2015-04-20
| quote = Functionality is being added to enable end-users to push Docker images directly into a Cloud Foundry cluster running Diego.
}}
</ref>

레드햇의 [[오픈시프트]] PaaS는 도커 및 관련 프로젝트(Kubernetes, Geard, Project Atomic 등)를 v3 (2015년 6월)부터 통합한다.<ref>
{{뉴스 인용
| last = Jackson
| first = Joab
| title = Red Hat to update Docker container tech for enterprises: Open source vendor plans to incorporate advanced Linux tools such as systemd and SELinux into Docker
| url = http://www.computerworld.com/s/article/9247706/Red_Hat_to_update_Docker_container_tech_for_enterprises
| publisher = Computerworld, Inc.
| publication-date = 2014-04-16
| accessdate = 2014-05-29
| quote = Red Hat has also started a second community project, called GearD, to integrate Docker into its PaaS (platform-as-a-service) hosting software, OpenShift Origin.
}}
</ref>

[[Apprenda]] PaaS는 제품 버전 6.0에 도커 컨테이너를 통합한다.<ref>
{{뉴스 인용
| last = Verge
| first = Jason
| title = PaaS and Docker Containers Work Together in Latest Apprenda Release
| url = http://www.datacenterknowledge.com/archives/2015/04/28/paas-and-docker-containers-work-together-in-latest-apprenda-release/
| publisher = Data Center Knowledge
| publication-date = 2015-04-28
| accessdate = 2015-12-06
| quote = The 6.0 release integrates Docker’s flexibility and portability with the compliance, governance and security capabilities that enterprises need from PaaS.
}}
</ref>

== 역사 ==
솔로몬 하익스는 프랑스에서 [[PaaS]] 기업인 [[닷클라우드]] 안에 내부 프로젝트로서 도커를 시작했다.<ref>{{웹 인용|url=https://www.dotcloud.com/|title=One home for all your apps|date=|website=dotcloud.com|보존url=https://web.archive.org/web/20140517031011/https://www.dotcloud.com/|archivedate=2014-05-17|accessdate=2014-05-08}}</ref>

도커는 2013년 3월 오픈 소스로 출시되었다.<ref name="infoq-201303" />

== 사용법 ==

=== CLI를 통한 이용 ===

=== GUI를 통한 이용 ===

==== 도커 데스크탑 ====
도커를 관리하는 GUI 앱으로 이미지를 검색하여 pull하거나 버튼 몇 번으로 이미지 생성, 빌드가 가능하다. 리눅스에서는 사용 불가능하다.

==== IDE/텍스트 편집기를 통한 이용 ====
[[비주얼 스튜디오 코드]]에서 확장기능을 이용하면 GUI를 통해서 도커 이미지를 빌드, 컨테이너 실행, 스택 실행 등이 가능하다. <code>docker exec -it <container> bash</code> 같이 일일이 코드를 치지 않고 버튼을 눌러 컨테이너의 쉘에 접근할 수 있다.

==== portainer 사용 ====

== 도구 ==
=== Docker Compose ===
Compose는 멀티 컨테이너 도커 애플리케이션을 정의하고 실행하는 도구이다.<ref>{{웹 인용|url=https://docs.docker.com/compose/overview/ |title=Overview of Docker Compose |accessdate=2017-07-06}}</ref> [[YAML]] 파일을 사용하여 애플리케이션의 서비스를 구성하며 하나의 명령을 가지고 모든 컨테이너의 생성 및 시작 프로세스를 수행한다. 도커 구 버전에서는 docker-compose를 설치하여야 하지만 신 버전은 docker 명령어에 통합되어 도커를 설치하기만 하면 되고 실행 명령어는 docker-compose 대신 docker compose이다. os마다 다르지만 docker를 패키지 매니저를 통해서 설치하면 구 버전이 설치될 수 있어 docker-compose를 별도로 설치해야 하는 경우가 생긴다. 공식 홈페이지에 소개된 설치 코드를 이용하여 설치하면 거의 최신 버전 설치가 된다.

=== Docker Swarm ===
Docker Swarm은 도커 컨테이너의 네이티브 [[컴퓨터 클러스터|클러스터링]] 기능을 제공하며 하나의 가상 도커 엔진으로 탈바꿈시킨다.<ref>{{웹 인용|url=https://www.linux.com/news/8-open-source-CONTAINER-ORCHESTRATION-TOOLS-KNOW|title=8 Container Orchestration Tools to Know|date=2017-04-12|accessdate=2017-07-06}}</ref>

도커 스웜은 컨테이너 오케스트레이션을 수행할 수 있게 해주며 여러 컴퓨터(노드)들을 클러스터로 구성했을 때 유용하다. 클러스터 중에서 여유 있는 컴퓨터에 자동으로 애플리케이션이 올라가 실행된다. 도커를 스웜 모드로 전환해야 하며 명령어를 통해 스웜 모드가 활성화된 노드들을 서로 연결시켜주어야 한다.

도커 1.12 이상부터 Swarm 모드가 도커 엔진에 통합되어 있다.<ref>{{웹 인용|url=https://docs.docker.com/swarm/ |title=Docker Swarm |accessdate=2017-07-06}}</ref>

비슷한 소프트웨어로는 [[kubernetes]](쿠버네티스)가 있다. 도커 스웜은 진입 장벽이 낮고 학습자나 취미 이용가들에게 적합한 반면 쿠버네티스는 학습 곡선이 가파르고 초보자에게 어렵지만 기능이 강력하고 풍부해서 상업적으로 쿠버네티스를 사용하는 프로젝트가 많다. IT 관련 직종 스펙인 기술 스택에 쿠버네티스가 있는 경우는 흔하지만 도커 스웜은 상대적으로 드문 편.

== 기타 ==
* 도커 안에서 도커를 굴릴 수 있다. 이른바 도커 인 도커(Docker in Docker). 다만 이럴 경우 호스트 도커와 게스트 도커, 그리고 그 안의 컨테이너까지 3중으로 프로세스가 돌아가면서 서버 자원이 상당히 소모된다. Docker out of Docker라고, 게스트 도커가 호스트 도커의 일부 설정을 공유하게 하는 경우도 있는데, 이 경우는 보안상으로 영 좋지 않다. 이런 일들이 발생하는 경우가 대표적으로 [[Jenkins|젠킨스]] 같은 지속 통합 소프트웨어를 도커 이미지로 올렸을 때 발생한다. CI 도구로 컨테이너 이미지를 빌드하는 경우가 많기 때문.
== 같이 보기 ==
* [[데브옵스]]
* [[마이크로서비스]]
* [[서비스 컴포넌트 아키텍처]]
* [[Podman]]
* [[kubernetes]]
* [[위키백과:베이그런트 (소프트웨어)|Vagrant]]

== 외부 링크 ==
* {{공식 웹사이트}}
* [https://www.44bits.io/ko/post/why-should-i-use-docker-container 왜 굳이 도커(컨테이너)를 써야 하나요?]

{{각주|30em}}
{{퍼온문서|문서=도커|퍼온곳=위키백과}}
[[분류:자유 소프트웨어]]
[[분류:가상화 소프트웨어]]

도커

2025-06-07T14:23:32Z

Senouis:

{{소프트웨어 정보
| 이름 = 도커 Docker
| 로고 = Docker (container engine) logo.svg
| 원작자 = 솔로몬 하익스 (Solomon Hykes)
| 개발자 = [[도커 (기업)|도커(Docker Inc.)]]
| 발표일 =
| 최신 버전 출시일 =
| 프로그래밍 언어 = [[Go (프로그래밍 언어)|Go]]<ref>{{웹 인용|url=https://github.com/docker/distribution |title=Docker source code |work=docs.docker.com |publisher=Docker, Inc. |date=2015-10-12 |accessdate=2015-10-24}}</ref>
| 운영체제 = [[리눅스]], [[마이크로소프트 윈도우|윈도우]], [[macOS]]
| 플랫폼 = 현대의 리눅스 커널이 포함된 [[x86-64]], [[ARM 아키텍처|ARM]] (실험적), 하이퍼-V 기능이 포함된 [[x86-64]] 윈도우
| 종류 = [[운영 체제 수준 가상화]]
| 라이선스 = [[아파치 라이선스]] 2.0
| 웹사이트 = {{URL|https://www.docker.com/}}
}}
'''도커'''(Docker)는 [[리눅스]]의 [[응용 소프트웨어|응용 프로그램]]들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 [[오픈 소스]] 프로젝트이다.

도커 웹 페이지의 기능을 인용하면 다음과 같다:
{{인용문|도커 컨테이너는 일종의 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싼다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다.<ref>https://www.docker.com/what-docker</ref>}}

도커는 [[리눅스]]에서 [[운영 체제 수준 가상화]]의 추상화 및 자동화 계층을 추가적으로 제공한다.<ref name="SYS-CON Media">{{웹 인용
| last = O'Gara
| first = Maureen
| date = 26 July 2013
| url = http://maureenogara.sys-con.com/node/2747331
| title = Ben Golub, Who Sold Gluster to Red Hat, Now Running dotCloud
| publisher = SYS-CON Media
| accessdate = 2013-08-09
| archive-date = 2019-09-13
| archive-url = https://web.archive.org/web/20190913100835/http://maureenogara.sys-con.com/node/2747331

}}</ref> 도커는 [[cgroups]]와 커널 [[리눅스 이름공간|이름공간]]과 같은 [[리눅스 커널]]의 기능들과 OverayFS, [[aufs]]와 같은 [[유니언 마운트|유니언 가능 파일 시스템]]의 리소스 격리 기능을 사용하며,<ref>{{웹 인용|title = docker/docker|url = https://github.com/docker/docker/blob/990a3e30fa66e7bd3df3c78c873c97c5b1310486/daemon/graphdriver/driver.go#L37-L43|website = GitHub|accessdate = 2015-12-29}}</ref> 이를 통해 독립적인 "컨테이너"가 하나의 리눅스 인스턴스 안에서 실행할 수 있게 함으로써 [[가상 머신]]을 시작하여 유지보수해야 하는 부담을 없애준다.<ref>{{웹 인용
| url = http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| archiveurl = https://web.archive.org/web/20140821065734/http://docker.readthedocs.org/en/v0.7.3/installation/kernel/
| title = Docker Documentation: Kernel Requirements
| date = 2014-01-04 | accessdate = 2014-08-20 | archivedate = 2014-08-21
| website = docker.readthedocs.org
}}</ref>

리눅스 커널의 이름공간 지원은 대체적으로<ref>{{웹 인용|url=http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/|title=Yet Another Reason Containers Don't Contain: Kernel Keyrings|author=Dan Walsh|work=projectatomic.io|accessdate=13 April 2015|archive-date=2015-04-13|archive-url=https://web.archive.org/web/20150413062633/http://www.projectatomic.io/blog/2014/09/yet-another-reason-containers-don-t-contain-kernel-keyrings/}}</ref> 프로세스 트리, 네트워크 사용자 ID, 마운트된 파일 시스템을 포함한 운영 환경에 대한 응용 프로그램의 관점을 격리시키지만, 커널의 cgroup들은 CPU, 메모리, 블록 입출력, 네트워크를 포함한 리소스 제한을 제공한다. 버전 0.9부터 도커는 [[libvirt]], [[LXC]] (리눅스 컨테이너), [[systemd-nspawn]]을 통한 추상화된 가상화 인터페이스를 사용하는 것 뿐 아니라 리눅스 커널이 제공하는 가상화 기능을 직접 사용하기 위한 유일한 수단으로 libcontainer [[라이브러리 (컴퓨팅)|라이브러리]]를 포함하고 있다.<ref name="zdnet-7000030397">{{웹 인용
| url = http://www.zdnet.com/docker-libcontainer-unifies-linux-container-powers-7000030397/
| title = Docker libcontainer unifies Linux container powers
| date = 2014-06-11 | accessdate = 2014-07-30
| author = Steven J. Vaughan-Nichols | publisher = [[ZDNet]]
}}</ref><ref>{{웹 인용
| url = https://github.com/docker/libcontainer/blob/master/README.md
| title = libcontainer - reference implementation for containers
| accessdate = 2014-07-30
| website = github.com
}}</ref><ref name="docker-blog-201403">{{웹 인용
| url = http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
| title = Docker 0.9: Introducing execution drivers and libcontainer
| date = 2014-03-10
| accessdate = 2015-01-20
| website = docker.com
| archive-date = 2015-02-21
| archive-url = https://web.archive.org/web/20150221134532/http://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
}}</ref>

== 개요 ==
[[파일:Docker-linux-interfaces.svg|섬네일|도커는 리눅스 커널의 가상화 기능에 접근하기 위해 각기 다른 인터페이스를 사용할 수 있다.<ref name="docker-blog-201403" />]]

도커 베이스 이미지에 액션을 취하면, 유니언 파일 시스템 계층들이 만들어지고 문서화되는데, 이렇게 함으로써 각 계층은 어떻게 액션을 재생성할지에 대해 완전하게 기술하게 된다. 이러한 전략은 이를테면 완전한 VM과 비교하면 도커의 이미지를 가볍게 만들어주며, 오직 레이어 업데이트만 전파해 주면 된다.

산업 애널리스트 기업 451 리서치에 따르면, "도커는 응용 프로그램과 그 의존성을 가상 컨테이너에 담을 수 있는 도구이며, 이 컨테이너는 어떠한 리눅스 서버에서라도 구동이 가능하다. 이것은 [[사내 소프트웨어|사내]], [[클라우드 컴퓨팅|공용 클라우드]], [[클라우드 컴퓨팅|개인 클라우드]], [[베어 메탈 서버|베어 메탈]] 등 응용 프로그램을 실행할 수 있는 곳에서는 유연성과 이식성을 적용하는데 도움을 준다.<ref name="Linux">{{웹 인용
| last = Noyes
| first = Katherine
| date = 1 August 2013
| url = http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code
| title = Docker: A 'Shipping Container' for Linux Code
| publisher = [[Linux.com]]
| accessdate = 2013-08-09
| 보존url = https://web.archive.org/web/20130808043357/http://www.linux.com/news/enterprise/cloud-computing/731454-docker-a-shipping-container-for-linux-code/
| 보존날짜 = 2013-08-08
}}</ref>

도커는 고급 [[API]]를 구현함으로써 프로세스들을 별도의 장소에서 실행할 수 있는 가벼운 컨테이너들을 제공한다.<ref name="infoq-201303">{{웹 인용
| last = Avram
| first = Abel
| date = 2013-03-27
| url = http://www.infoq.com/news/2013/03/Docker
| title = Docker: Automated and Consistent Software Deployments
| publisher = InfoQ
| accessdate = 2013-08-09
}}</ref>

[[리눅스 커널]]이 제공하는 기능들(주로 cgroups와 이름공간) 위에 빌드되기 때문에 도커 컨테이너는 가상 머신과는 달리 별도의 운영 체제를 요구하거나 포함하지 않는다.<ref name="Linux" /> 그 대신, 커널의 기능에 의존하며 리소스 격리(CPU, 메모리, 블록 입출력, 네트워크 등) 및 [[이름공간 격리|격리된 이름공간]]을 사용하여 운영 체제에 대한 응용 프로그램의 관점을 격리시킨다. 도커는 도커 0.9대부터 이용 가능한 libcontainer 라이브러리를 사용하거나 [[libvirt]], [[LXC]] (리눅스 컨테이너), 또는 [[systemd-nspawn]]을 통해 간접적으로 리눅스 커널의 가상화 기능들에 접근한다.<ref name="docker-blog-201403" /><ref name="infoq-201403">{{웹 인용
| last = Swan
| first = Chris
| date = 2014-03-13
| url = http://www.infoq.com/news/2014/03/docker_0_9
| title = Docker drops LXC as default execution environment
| publisher = InfoQ
| accessdate = 2015-01-20
}}</ref>

도커는 매우 가볍기 때문에, 하나의 서버나 가상 머신이 여러 컨테이너들을 동시에 구동할 수 있다.

컨테이너를 사용하여 리소스를 격리시키고, 서비스를 제한시키며, 프로세스를 예비할 수 있으며 이렇게 하여 자신만의 프로세스 ID 공간, 파일 시스템 구조, 네트워크 인터페이스를 갖고서 운영 체제에 대하여 거의 완전히 개인화된 관점을 갖게 한다. 여러 개의 컨테이너들은 동일한 커널은 공유하지만 각 컨테이너는 CPU, 메모리, 입출력과 같이 오직 정의된 양의 리소스에만 제한을 받을 수 있다.

도커를 사용하여 컨테이너를 만들고 관리하면 다수의 응용 프로그램, 작업자의 작업, 다른 프로세스들이 자율적으로 하나의 물리 머신이나 여러 개의 가상 머신을 통해 구동될 수 있게 되므로 고도의 [[분산 시스템]]을 생성하는 일이 단순해진다. 리소스가 사용 가능해질 때 또는 더 많은 노드가 필요할 때 노드가 배치될 수 있게 하므로 [[Apache Cassandra]], [[몽고DB]], [[Riak]]와 같은 시스템을 위한 [[PaaS]] 스타일의 배치 및 규모 증강이 가능해진다. 또, 도커는 작업이나 워크로드 큐, 기타 분산 시스템들의 생성 및 운영을 단순하게 한다.<ref name="CloudAve">{{웹 인용
| last = Hall
| first = Adron
| date = 31 July 2013
| url = http://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
| title = OSCON : Conversations, Deployments, Architecture, Docker and the Future?
| publisher = CloudAve
| accessdate = 2013-08-09
| archive-date = 2019-03-27
| archive-url = https://web.archive.org/web/20190327103543/https://www.cloudave.com/30655/oscon-conversations-deployments-architecture-docker-and-the-future/
}}</ref><ref name="Iron.io">{{웹 인용
|last = Reeder
|first = Travis
|date = 22 April 2014
|url = http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|title = How Docker Helped Us Achieve the (Near) Impossible
|publisher = Iron.io
|accessdate = 2014-07-25
|보존url = https://web.archive.org/web/20140808031809/http://blog.iron.io/2014/04/how-docker-helped-us-achieve-near.html
|보존날짜 = 2014-08-08
}}</ref>

=== 통합 ===
도커는 다음을 포함한 다양한 인프라스트럭처 도구들에 통합될 수 있다.

* [[아마존 웹 서비스]]<ref>{{웹 인용 |url=https://docs.docker.com/installation/amazon/ |title=Amazon EC2 - Docker Documentation |website=docs.docker.com |date= |accessdate=2014-10-18 |보존url=https://archive.today/20141018090321/https://docs.docker.com/installation/amazon/ |보존날짜=2014-10-18}}</ref>
* [[Ansible]]<ref>{{웹 인용 |author=/ |url=https://github.com/ansible/ansible/blob/devel/library/cloud/docker |title=ansible/library/cloud/docker |publisher=[[GitHub]] |date= |accessdate=2014-01-20 |보존url=https://archive.today/20131227071413/https://github.com/ansible/ansible/blob/devel/library/cloud/docker |보존날짜=2013-12-27}}</ref>
* [[CFEngine]]<ref>{{웹 인용|url=http://docs.docker.com/examples/cfengine_process_management/|title=CFEngine|publisher=CFEngine|date=|accessdate=2014-06-06|보존url=https://web.archive.org/web/20140613180312/http://docs.docker.com/examples/cfengine_process_management/|보존날짜=2014-06-13}}</ref>
* [[Chef]]<ref>{{웹 인용|url=https://github.com/thoward/docker-cookbook |title=thoward/docker-cookbook |publisher=GitHub |date= |accessdate=2014-01-20}}</ref>
* [[구글 클라우드 플랫폼]]<ref>{{웹 인용|title=Containers on Google Cloud Platform|url=https://cloud.google.com/compute/docs/containers|publisher=Google Inc}}</ref>
* IBM [[블루믹스]]<ref>{{웹 인용 |url=https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/ |title=Bluemix Launches IBM Containers Beta Based on Docker |publisher=IBM |date=2014-12-04 |accessdate=2015-04-20 |archive-date=2015-04-28 |archive-url=https://web.archive.org/web/20150428181821/https://developer.ibm.com/bluemix/2014/12/04/ibm-containers-beta-docker/}}</ref>
* HPE Helion Stackato
* [[Jelastic]]<ref>{{웹 인용 |url=http://www.prweb.com/releases/2014/12/prweb12361294.htm/ |title=Jelastic Announces Docker Integration to Provide the Most Advanced Orchestrated Application Delivery |publisher=PRWeb|date= |accessdate=2014-12-03}}</ref>
* [[젠킨스]]<ref>{{웹 인용|url=https://github.com/georgebashi/jenkins-docker-plugin |title=georgebashi/jenkins-docker-plugin |publisher=GitHub |date= |accessdate=2017-01-09}}</ref>
* [[Kubernetes]]<ref name="containerizing-docker-on-Kubernetes">{{뉴스 인용 |last=Surana |first=Ramit |url=https://www.linkedin.com/pulse/containerizing-docker-kubernetes-ramit-surana |title=Containerizing Docker on Kubernetes |work=[[LinkedIn]] |date=2015-09-16 |accessdate=2015-11-02 }}</ref>
* [[마이크로소프트 애저]]<ref>{{웹 인용|url=https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/|title=The Docker Virtual Machine Extension for Linux on Azure|date=29 June 2015|publisher=Microsoft|accessdate=11 August 2015|archive-date=2016-03-17|archive-url=https://web.archive.org/web/20160317130223/https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-docker-vm-extension/}}</ref>
* [[오픈스택]] 노바<ref>{{웹 인용 |author=Stefano Maffulli |url=http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |title=OpenStack Community Weekly Newsletter (May 31 – June 7) » The OpenStack Blog |publisher=Openstack.org |date=2013-06-07 |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20131229025044/http://www.openstack.org/blog/2013/06/openstack-community-weekly-newsletter-may-31-june-7/ |보존날짜=2013-12-29}}</ref>
* [[OpenSVC]]<ref>{{웹 인용 |url=http://docs.opensvc.com/virtualization.docker.html |title=OpenSVC Docker |publisher=OpenSVC |date= |accessdate=2014-05-29 |보존url=https://web.archive.org/web/20140531090525/http://docs.opensvc.com/virtualization.docker.html |보존날짜=2014-05-31}}</ref>
* 오라클 컨테이너 클라우드 서비스<ref>
{{웹 인용
| last = Native
| first = Cloud
| title = Oracle Container Cloud Service Explained By Oracle.com
| url = https://cloud.oracle.com/container}}
</ref>
* [[퍼핏 (소프트웨어)|퍼핏]]<ref>{{웹 인용 | author = Gareth Rushgrove | url = http://forge.puppetlabs.com/garethr/docker | title = garethr/docker | publisher = Puppet Forge | date = | accessdate = 2014-01-20 }}</ref>
* [[Salt]]<ref>{{웹 인용 |url=http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |title=saltstack/dockerio |accessdate=2014-01-20 |보존url=https://web.archive.org/web/20140203185236/http://docs.saltstack.com/ref/modules/all/salt.modules.dockerio.html#module-salt.modules.dockerio |보존날짜=2014-02-03}}</ref>
* [[Vagrant]]<ref>{{웹 인용 |url=https://github.com/philspitler/vagrant-docker |title=philspitler/vagrant-docker |publisher=GitHub |date= |accessdate=2014-01-20 |보존url=https://archive.today/20130809164628/https://github.com/philspitler/vagrant-docker |보존날짜=2013-08-09}}</ref>
* [[VMware vSphere|VMware vSphere Integrated Containers]]<ref>http://searchservervirtualization.techtarget.com/definition/VMware-vSphere-Integrated-Containers-VIC VMware vSphere Integrated Containers (VIC)</ref><ref>http://thenewstack.io/vmwares-photon-platform-and-how-it-treats-containers/ VMware’s Photon Platform and How it Treats Containers</ref>

클라우드 파운드리 Diego 프로젝트는 도커를 [[클라우드 파운드리]] [[PaaS]]에 통합한다.<ref>
{{웹 인용
| last = Whelan
| first = Phil
| title = Cloud Foundry: Diego Explained By Onsi Fakhouri
| url = https://community.spiceworks.com/topic/576560-cloud-foundry-diego-explained-by-onsi-fakhouri
| publisher = ActiveState
| publication-date = 2014-09-03
| accessdate = 2015-04-20
| quote = Functionality is being added to enable end-users to push Docker images directly into a Cloud Foundry cluster running Diego.
}}
</ref>

레드햇의 [[오픈시프트]] PaaS는 도커 및 관련 프로젝트(Kubernetes, Geard, Project Atomic 등)를 v3 (2015년 6월)부터 통합한다.<ref>
{{뉴스 인용
| last = Jackson
| first = Joab
| title = Red Hat to update Docker container tech for enterprises: Open source vendor plans to incorporate advanced Linux tools such as systemd and SELinux into Docker
| url = http://www.computerworld.com/s/article/9247706/Red_Hat_to_update_Docker_container_tech_for_enterprises
| publisher = Computerworld, Inc.
| publication-date = 2014-04-16
| accessdate = 2014-05-29
| quote = Red Hat has also started a second community project, called GearD, to integrate Docker into its PaaS (platform-as-a-service) hosting software, OpenShift Origin.
}}
</ref>

[[Apprenda]] PaaS는 제품 버전 6.0에 도커 컨테이너를 통합한다.<ref>
{{뉴스 인용
| last = Verge
| first = Jason
| title = PaaS and Docker Containers Work Together in Latest Apprenda Release
| url = http://www.datacenterknowledge.com/archives/2015/04/28/paas-and-docker-containers-work-together-in-latest-apprenda-release/
| publisher = Data Center Knowledge
| publication-date = 2015-04-28
| accessdate = 2015-12-06
| quote = The 6.0 release integrates Docker’s flexibility and portability with the compliance, governance and security capabilities that enterprises need from PaaS.
}}
</ref>

== 역사 ==
솔로몬 하익스는 프랑스에서 [[PaaS]] 기업인 [[닷클라우드]] 안에 내부 프로젝트로서 도커를 시작했다.<ref>{{웹 인용|url=https://www.dotcloud.com/|title=One home for all your apps|date=|website=dotcloud.com|보존url=https://web.archive.org/web/20140517031011/https://www.dotcloud.com/|archivedate=2014-05-17|accessdate=2014-05-08}}</ref>

도커는 2013년 3월 오픈 소스로 출시되었다.<ref name="infoq-201303" />

== 사용법 ==

=== CLI를 통한 이용 ===

=== GUI를 통한 이용 ===

==== 도커 데스크탑 ====
도커를 관리하는 GUI 앱으로 이미지를 검색하여 pull하거나 버튼 몇 번으로 이미지 생성, 빌드가 가능하다. 리눅스에서는 사용 불가능하다.

==== IDE/텍스트 편집기를 통한 이용 ====
[[비주얼 스튜디오 코드]]에서 확장기능을 이용하면 GUI를 통해서 도커 이미지를 빌드, 컨테이너 실행, 스택 실행 등이 가능하다. <code>docker exec -it <container> bash</code> 같이 일일이 코드를 치지 않고 버튼을 눌러 컨테이너의 쉘에 접근할 수 있다.

==== portainer 사용 ====

== 도구 ==
=== Docker Compose ===
Compose는 멀티 컨테이너 도커 애플리케이션을 정의하고 실행하는 도구이다.<ref>{{웹 인용|url=https://docs.docker.com/compose/overview/ |title=Overview of Docker Compose |accessdate=2017-07-06}}</ref> [[YAML]] 파일을 사용하여 애플리케이션의 서비스를 구성하며 하나의 명령을 가지고 모든 컨테이너의 생성 및 시작 프로세스를 수행한다. 도커 구 버전에서는 docker-compose를 설치하여야 하지만 신 버전은 docker 명령어에 통합되어 도커를 설치하기만 하면 되고 실행 명령어는 docker-compose 대신 docker compose이다. os마다 다르지만 docker를 패키지 매니저를 통해서 설치하면 구 버전이 설치될 수 있어 docker-compose를 별도로 설치해야 하는 경우가 생긴다. 공식 홈페이지에 소개된 설치 코드를 이용하여 설치하면 거의 최신 버전 설치가 된다.

=== Docker Swarm ===
Docker Swarm은 도커 컨테이너의 네이티브 [[컴퓨터 클러스터|클러스터링]] 기능을 제공하며 하나의 가상 도커 엔진으로 탈바꿈시킨다.<ref>{{웹 인용|url=https://www.linux.com/news/8-open-source-CONTAINER-ORCHESTRATION-TOOLS-KNOW|title=8 Container Orchestration Tools to Know|date=2017-04-12|accessdate=2017-07-06}}</ref>

도커 스웜은 컨테이너 오케스트레이션을 수행할 수 있게 해주며 여러 컴퓨터(노드)들을 클러스터로 구성했을 때 유용하다. 클러스터 중에서 여유 있는 컴퓨터에 자동으로 애플리케이션이 올라가 실행된다. 도커를 스웜 모드로 전환해야 하며 명령어를 통해 스웜 모드가 활성화된 노드들을 서로 연결시켜주어야 한다.

도커 1.12 이상부터 Swarm 모드가 도커 엔진에 통합되어 있다.<ref>{{웹 인용|url=https://docs.docker.com/swarm/ |title=Docker Swarm |accessdate=2017-07-06}}</ref>

비슷한 소프트웨어로는 [[kubernetes]](쿠버네티스)가 있다. 도커 스웜은 진입 장벽이 낮고 학습자나 취미 이용가들에게 적합한 반면 쿠버네티스는 학습 곡선이 가파르고 초보자에게 어렵지만 기능이 강력하고 풍부해서 상업적으로 쿠버네티스를 사용하는 프로젝트가 많다. IT 관련 직종 스펙인 기술 스택에 쿠버네티스가 있는 경우는 흔하지만 도커 스웜은 상대적으로 드문 편.

== 기타 ==
* 도커 안에서 도커를 굴릴 수 있다. 이른바 도커 인 도커(Docker in Docker). 다만 이럴 경우 호스트 도커와 게스트 도커, 그리고 그 안의 컨테이너까지 3중으로 프로세스가 돌아가면서 서버 자원이 상당히 소모된다. Docker out of Docker라고, 게스트 도커가 호스트 도커의 일부 설정을 공유하게 하는 경우도 있는데, 이 경우는 보안상으로 영 좋지 않다. 이런 일들이 발생하는 경우가 대표적으로 [[Jenkins|젠킨스]] 같은 지속 통합 소프트웨어를 도커 이미지로 올렸을 때 발생한다. CI 도구로 컨테이너 이미지를 빌드하는 경우가 많기 때문.
== 같이 보기 ==
* [[데브옵스]]
* [[마이크로서비스]]
* [[서비스 컴포넌트 아키텍처]]
* [[Podman]]
* [[kubernetes]]
* [[위키백과:베이그런트 (소프트웨어)|Vagrant]]

== 외부 링크 ==
* {{공식 웹사이트}}
* [https://www.44bits.io/ko/post/why-should-i-use-docker-container 왜 굳이 도커(컨테이너)를 써야 하나요?]

{{각주|30em}}
{{퍼온문서|문서=도커|퍼온곳=위키백과}}
[[분류:자유 소프트웨어]]
[[분류:가상화 소프트웨어]]

Kubernetes

2025-06-07T14:18:59Z

Senouis:

[[분류: IT]]
[[분류: 클라우드 서비스]]

'''Kubenetes'''(쿠버네티스) 또는 k8s는 다수의 리눅스 컨테이너 이미지를 여러 개의 노드 서버에서 자동으로 분배하여 배포 및 실행할 수 있는 환경을 제공하는 오픈 소스 클라우드 구축 시스템이다. 현재는 리눅스 재단이 관리하고 있다.

== 개발 배경 및 쓰임 ==
쿠버네티스는 구글이 자사의 수많은 서비스(지메일, 유튜브, 구글 드라이브 및 구글 독스, 구글 맵 및 기타)를 많은 서버에 적절히 분배하여 관리하기 위해 사내 엔지니어들이 만든 서비스 배포 시스템을 2014년 오픈 소스 프로젝트로 공개한 프로젝트다. 이후 수많은 대형 IT 회사들이 자사의 서비스들을 쉽게 관리하기 위한 사내 클라우드(On-premise Cloud) 시스템을 구축하기 위해 쿠버네티스를 채용하면서 2020년 이후 조금씩 파이가 커지고 있다.

구글이 만든 프로젝트인 만큼 [[구글 클라우드 플랫폼]](GCP)에서는 GKE(Google Kubenetes Engine)이란 이름으로 자사 클라우드 서비스를 사용하는 회사들을 위해 각종 서비스들을 통합해서 관리하는 쿠버네티스 시스템 관리 서비스를 제공하고 있다.

리눅스의 운영체제 수준 가상화(컨테이너)를 활용한 기술인 만큼 리눅스에서만 지원되고 [[마이크로소프트 윈도우|윈도우]]에서는 지원되지 않는다.

== 주요 개념 ==
* 마스터 노드와 워커 노드 
쿠버네티스는 컴퓨터들의 묶음인 클러스터들 위에서 돌아가며, 클러스터 내 각 컴퓨터는 클러스터 별 작업 분배를 담당하는 마스터 노드와 실제로 작업 단위들을 받아 실행하는 워커 노드들로 이루어져 있다. 보통 쿠버네티스를 제대로 사용한다면 마스터 노드 2개 이상, 그리고 각 마스터마다 2~3개 이상의 워커는 있어야 한다. 그리고 이게 개인 및 소규모 회사들이 k8s를 공부하고 사용하기 어렵게 만드는 첫 번째 요인이다. 즉 대형 프로젝트를 굴리는 게 아니면 k8s가 쓸모가 없다는 것. 그나마 이 문제점을 개선한다고 k3s나 minikube 같은 파생 프로젝트들이 나왔긴 하나, 후술할 두 번째 이유로 여전히 공부하고 쓰기 어렵다...

* 파드 
컨테이너의 기본 작업 단위이다. 파드를 배포하기 위해 배포 유형별로 정해진 양식의 [[YAML|yml]] 파일을 만들어 가져올 컨테이너 이미지를 설정하고, 볼륨과 환경변수, 실행 커맨드들을 설정한다는 개념 측면에서는 도커 컴포즈로 배포하는 상황이랑 비슷하나, 도커 컴포즈에서 설정할 법한 옵션들은 spec이란 키 안에 전부 잡아 넣고 그 외에도 훨씬 많은 옵션들을 설정한다. 그리고 이 옵션들이 k8s를 개인 및 소규모 회사 내 직원들이 공부하고 채용하기 어렵게 만드는 두 번째 원인이다(...)

아예 설정용 YAML 양식을 자기 업무용 컴퓨터에 미리 써 놓고 복붙하며 배포하는 게 편하긴 하다. 그것도 귀찮으면 ChatGPT가 만든 기본 양식을 적당히 맞게 수정하여 쓰는 일도 있는듯...

다행히도 파드 별로 저런 설정을 넣는 것이 아니라, 보통 다음에 소개할 스테이트풀 셋이나 디플로이먼트에서 설정한 옵션을 파드가 대부분 상속받는 구조로 사용하게 설정된 것이 그나마 위안...

* 데몬 셋, 리플리카 셋, 스테이트풀 셋 
동일하게 복제된 여러 파드의 묶음인 작업 단위를 의미한다. 리플리카셋은 보통 후술할 디플로이먼트에 귀속된 경우가 많으며, 배포를 시작할 때 파드 배포 순서가 정해져 있지 않다. 스테이트풀 셋은 파드 배포 순서가 정해져 있으며, 보통 '(파드 배포 이름)-0'부터 뒤의 숫자가 올라가는 방식으로 파드 별 이름이 결정된다. 데몬 셋은 '반드시 모든 워커 노드에서 동일한 파드 하나씩' 실행하는 특수한 경우에 사용하는데, 보통 워커 노드들에 기능을 추가하는 쿠버네티스용 플러그인(예: Calico 같은 CNI, Longhorn 같은 볼륨 관련 플러그인)을 설치할 때 데몬셋 형태로 파드가 배포된다.

DBMS를 굳이 k8s로 배포하겠다고 하겠다면 스테이트풀 셋이 적당하다. 리플리케이션 순서를 정하게 하기 쉽다. 그러나 보통 DBMS는 k8s로 배포하는 경우가 많지 않는데, 어쩌다 워커 노드가 하나 맛이 갔는데 그 안에 DBMS 파드가 들어있었다면 데이터 동기화가 개판이 되기 때문. 특히 시스템의 규모가 클 수록 그 피해의 크기는 상상을 초월한다... 그래서 k8s 클러스터에서 DBMS는 보통 따로 분리해 별도의 물리 컴퓨터들에 설치하는 편이다.

* 디플로이먼트 
보통 웹 서비스를 개발하고 k8s에 컨테이너 이미지로 배포한다면 디플로이먼트 단위로 배포한다. 여기에 옵션들을 주고 컨테이너 이미지를 배포하면 리플리카 셋이 생성되고, 거기에 다시 파드들이 붙는다.

* 서비스 
어쨌든 k8s는 컴퓨터들의 클러스터에서 여러 프로젝트들이 돌아가는 구조이므로, 최소한의 네트워크 통신으로 파드로 올려진 컨테이너 간의 네트워크 통신이 필요하다. k8s는 이런 파드 간 네트워크 통신 관련 정보를 배포할 때에 '서비스'라는 단위로 배포한다. 서비스에서는 네트워크 통신을 위한 포트 설정이 필수적이다. 기본적으로 Kubenet이라는 내장 플러그인이 있긴 하나, 기능이 턱없이 부족해 Flannel, Calico 같은 서드 파티 CNI 플러그인이 많이 사용된다.
:* ClusterIP, NodePort, LoadBalancer: 보통 대형 IT 프로젝트가 k8s를 사용한다면 대부분의 서비스, 특히 백엔드 서비스는 보안을 위해 외부에 노출시키지 않는다. 그래서 보통 서비스들은 ClusterIP 타입으로 내부망에서 서비스 이름으로만 통신하도록 되어 있다. 그러나 이렇게만 하면 디버깅도 어렵고, 프론트엔드 서버처럼 외부 네트워크에 노출시켜야 하는 서버가 있을 것이다. 보통 서비스의 작동 여부를 확인할 때에는 NodePort 타입의 서비스를 설정하며, 영구적으로 외부에 노출시킬 때에는 CNI 플러그인을 설치해서 LoadBalancer 타입으로 적절한 파드(또는 복수의 파드)가 노출되도록 한다.

* 퍼시스턴트 볼륨 및 퍼시스턴트 볼륨 클레임 
도커 엔진을 쓸 때 볼륨으로 특정 디렉토리를 호스트에 마운트하여 원하는 파일을 컨테이너 내에 추가하고 수정할 수 있는 것처럼, k8s에도 퍼시스턴트 볼륨(Persistent Volume)이라는 개념으로 컨테이너 내에서 변화된 데이터를 노드에 영구적으로 저장할 수 있다. 문제는 클러스터 단위로 움직이는 k8s답게 어느 워커 노드에 어느 볼륨이 들어갈 지는 k8s 마스터 노드 마음대로이며, 파드를 잠시 내렸다 다시 마운트하려면 워커 노드를 찾아다니면서 수동으로 마운트/언마운트를 해야 하는 불편이 있다.

그래서 워커를 찾아다니며 볼륨 할당을 일일이 하는 것은 귀찮기 때문에, Longhorn 같은 볼륨 관리 플러그인과 연계해 퍼시스턴트 볼륨을 디플로이먼트/스테이트풀 셋 배포 단계에서 설정하는 퍼시스턴트 볼륨 클레임(PVC) 기능이 있다.

* 메타데이터: 타입과 네임스페이스 
이렇게 복잡한 k8s 배포 구조 때문에 종종 디플로이먼트/스테이트풀셋 등을 배포할 때 이름이 겹치거나 혼동하기 쉬운 이름들을 가진 여러 서비스들이 생길 수 있다. 이를 완화하기 위해 모든 k8s 작업 단위에는 메타데이터가 있으며, 그 안에서 작업 단위의 타입(예: frontend, backend)를 임의로 지정하거나 네임스페이스라는 단위로 아예 특정 서비스들을 위한 여러 작업 단위를 한꺼번에 분리할 수 있다.

k8s에 설치되는 플러그인들도 각기 네임스페이스로 격리되기 때문에, 운 나쁘게 배포한 디플로이먼트 내 파드 이름이 플러그인의 파드 이름과 겹쳐 배포가 실패하는 일은 일반적으로 없다. 기본적으로 k8s 클러스터 내에 생성되는 기본 네임스페이스의 이름은 'default'다.

* 컨피그맵과 시크릿
도커 컴포즈로 컨테이너 이미지의 환경설정을 하는 것처럼 컨피그맵과 시크릿이란 단위로 특정 값 또는 데이터를 배포하여 디플로이먼트에 각각 'envFrom' 및 'secret' 키로 연결하게 할 수 있다. 주 용도는 컨테이너 이미지 내 환경 변수 설정 및 SSL 인증서 키 등록.

* 인그레스
k8s는 일반적으로 대형 IT 회사의 웹 서비스 프로젝트에 사용한다고 하는데, 보통 이런 서비스는 마이크로서비스 아키텍처(Microservice Architecture, MSA) 형태를 가지고 있는 경우가 거의 전부라고 해도 좋다. 이 경우 별 다른 설정이 없다면 외부 사용자가 원하는 기능을 사용하기 위해서는 각 마이크로서비스가 k8s LoadBalancer 서비스 형태로 외부로 노출된 IP 및 포트를 클라이언트가 다 알고 찾아가야 한다.

이런 경우를 대비해 여러 IP 및 포트를 외부에 노출시키는 대신, 하나의 게이트웨이 IP 주소를 만들고 그 아래의 URI만 알면 클라이언트가 URI를 따라 k8s 서비스를 알아서 찾아가게 할 수 있는데, 이 기능을 인그레스(Ingress)라고 한다. MSA와 찰떡궁합이라는 특성이 있으며, SSL 설정이 필용할 때 인그레스가 설정된 경우 그 게이트웨이 IP 주소에만 TLS 설정을 걸면 끝난다! 다만 이 경우 시크릿으로 SSL 인증서 데이터를 업로드해야 하지만...

반대로 모든 서비스의 응답을 하나의 주소로 모아 클라이언트로 반환하는 이그레스(Egress)도 있긴 한데, 이건 나가는 트래픽까지 특정 포트로 강요해야 하는 아주 특별한 경우가 아니면 보통 잘 건드리지 않는다. 대부분의 공개 클라우드 서비스(AWS, Azure, GCP 및 기타) 위 퍼블릭 가상 네트워크가 방화벽 단에서 아웃바운드 트래픽을 무제한으로 허용하는 설정이 기본값인 것과 비슷하다.

== [[도커]]와 쿠버네티스 ==
도커와 쿠버네티스는 모두 리눅스 컨테이너 기술을 활용해 이미지를 만들어 배포할 때 사용하는 기술이다. 그러나 도커는 쿠버네티스와 같은 역할을 하지 않는다.

도커는 주로 컨테이너 이미지를 만드는 데에 초점이 맞추어져 있으며, 도커 엔진으로 그 이미지를 배포할 때에는 순전히 도커 사의 고유 엔진을 활용할 뿐, 쿠버네티스처럼 여러 엔진 중에 골라서 배포하지 않는다. 반면 쿠버네티스는 리눅스 컨테이너 이미지를 배포하는 데에 초점을 맞추며, containerd를 비롯한 여러 컨테이너 엔진을 활용하는 소프트웨어다.

심지어 쿠버네티스는 도커 엔진을 사용할 수 없다! 도커 사가 자꾸 자사만의 고유 규격을 추가한다고 쿠버네티스 1.20부터 도커 엔진 지원을 중단하였기 때문이다. 현재 k8s의 기본 컨테이너 엔진은 containerd인데, 한국에는 도커 엔진에 비해 많이 알려지지 않은 데다가 사용자가 대형 IT 회사 위주로 한정되어서, 소규모 회사들이 컨테이너 기술을 활용한다면 아직 도커 및 도커 엔진(+도커 컴포즈) 정도만 쓰고 있다.

한편 도커 사는 k8s에 대응하는 솔루션으로 도커 스웜(Docker swarm)을 보유하고 있다.

== 같이 보기 ==
* [[도커]]
* [[리눅스]]

Kubernetes

2025-06-07T14:18:35Z

Senouis: /* 도커와 쿠버네티스 */

[[분류: IT]]
[[분류: 클라우드 서비스]]

'''Kubenetes'''(쿠버네티스) 또는 k8s는 다수의 리눅스 컨테이너 이미지를 여러 개의 노드 서버에서 자동으로 분배하여 배포 및 실행할 수 있는 환경을 제공하는 오픈 소스 시스템이다. 현재는 리눅스 재단이 관리하고 있다.

== 개발 배경 및 쓰임 ==
쿠버네티스는 구글이 자사의 수많은 서비스(지메일, 유튜브, 구글 드라이브 및 구글 독스, 구글 맵 및 기타)를 많은 서버에 적절히 분배하여 관리하기 위해 사내 엔지니어들이 만든 서비스 배포 시스템을 2014년 오픈 소스 프로젝트로 공개한 프로젝트다. 이후 수많은 대형 IT 회사들이 자사의 서비스들을 쉽게 관리하기 위한 사내 클라우드(On-premise Cloud) 시스템을 구축하기 위해 쿠버네티스를 채용하면서 2020년 이후 조금씩 파이가 커지고 있다.

구글이 만든 프로젝트인 만큼 [[구글 클라우드 플랫폼]](GCP)에서는 GKE(Google Kubenetes Engine)이란 이름으로 자사 클라우드 서비스를 사용하는 회사들을 위해 각종 서비스들을 통합해서 관리하는 쿠버네티스 시스템 관리 서비스를 제공하고 있다.

리눅스의 운영체제 수준 가상화(컨테이너)를 활용한 기술인 만큼 리눅스에서만 지원되고 [[마이크로소프트 윈도우|윈도우]]에서는 지원되지 않는다.

== 주요 개념 ==
* 마스터 노드와 워커 노드 
쿠버네티스는 컴퓨터들의 묶음인 클러스터들 위에서 돌아가며, 클러스터 내 각 컴퓨터는 클러스터 별 작업 분배를 담당하는 마스터 노드와 실제로 작업 단위들을 받아 실행하는 워커 노드들로 이루어져 있다. 보통 쿠버네티스를 제대로 사용한다면 마스터 노드 2개 이상, 그리고 각 마스터마다 2~3개 이상의 워커는 있어야 한다. 그리고 이게 개인 및 소규모 회사들이 k8s를 공부하고 사용하기 어렵게 만드는 첫 번째 요인이다. 즉 대형 프로젝트를 굴리는 게 아니면 k8s가 쓸모가 없다는 것. 그나마 이 문제점을 개선한다고 k3s나 minikube 같은 파생 프로젝트들이 나왔긴 하나, 후술할 두 번째 이유로 여전히 공부하고 쓰기 어렵다...

* 파드 
컨테이너의 기본 작업 단위이다. 파드를 배포하기 위해 배포 유형별로 정해진 양식의 [[YAML|yml]] 파일을 만들어 가져올 컨테이너 이미지를 설정하고, 볼륨과 환경변수, 실행 커맨드들을 설정한다는 개념 측면에서는 도커 컴포즈로 배포하는 상황이랑 비슷하나, 도커 컴포즈에서 설정할 법한 옵션들은 spec이란 키 안에 전부 잡아 넣고 그 외에도 훨씬 많은 옵션들을 설정한다. 그리고 이 옵션들이 k8s를 개인 및 소규모 회사 내 직원들이 공부하고 채용하기 어렵게 만드는 두 번째 원인이다(...)

아예 설정용 YAML 양식을 자기 업무용 컴퓨터에 미리 써 놓고 복붙하며 배포하는 게 편하긴 하다. 그것도 귀찮으면 ChatGPT가 만든 기본 양식을 적당히 맞게 수정하여 쓰는 일도 있는듯...

다행히도 파드 별로 저런 설정을 넣는 것이 아니라, 보통 다음에 소개할 스테이트풀 셋이나 디플로이먼트에서 설정한 옵션을 파드가 대부분 상속받는 구조로 사용하게 설정된 것이 그나마 위안...

* 데몬 셋, 리플리카 셋, 스테이트풀 셋 
동일하게 복제된 여러 파드의 묶음인 작업 단위를 의미한다. 리플리카셋은 보통 후술할 디플로이먼트에 귀속된 경우가 많으며, 배포를 시작할 때 파드 배포 순서가 정해져 있지 않다. 스테이트풀 셋은 파드 배포 순서가 정해져 있으며, 보통 '(파드 배포 이름)-0'부터 뒤의 숫자가 올라가는 방식으로 파드 별 이름이 결정된다. 데몬 셋은 '반드시 모든 워커 노드에서 동일한 파드 하나씩' 실행하는 특수한 경우에 사용하는데, 보통 워커 노드들에 기능을 추가하는 쿠버네티스용 플러그인(예: Calico 같은 CNI, Longhorn 같은 볼륨 관련 플러그인)을 설치할 때 데몬셋 형태로 파드가 배포된다.

DBMS를 굳이 k8s로 배포하겠다고 하겠다면 스테이트풀 셋이 적당하다. 리플리케이션 순서를 정하게 하기 쉽다. 그러나 보통 DBMS는 k8s로 배포하는 경우가 많지 않는데, 어쩌다 워커 노드가 하나 맛이 갔는데 그 안에 DBMS 파드가 들어있었다면 데이터 동기화가 개판이 되기 때문. 특히 시스템의 규모가 클 수록 그 피해의 크기는 상상을 초월한다... 그래서 k8s 클러스터에서 DBMS는 보통 따로 분리해 별도의 물리 컴퓨터들에 설치하는 편이다.

* 디플로이먼트 
보통 웹 서비스를 개발하고 k8s에 컨테이너 이미지로 배포한다면 디플로이먼트 단위로 배포한다. 여기에 옵션들을 주고 컨테이너 이미지를 배포하면 리플리카 셋이 생성되고, 거기에 다시 파드들이 붙는다.

* 서비스 
어쨌든 k8s는 컴퓨터들의 클러스터에서 여러 프로젝트들이 돌아가는 구조이므로, 최소한의 네트워크 통신으로 파드로 올려진 컨테이너 간의 네트워크 통신이 필요하다. k8s는 이런 파드 간 네트워크 통신 관련 정보를 배포할 때에 '서비스'라는 단위로 배포한다. 서비스에서는 네트워크 통신을 위한 포트 설정이 필수적이다. 기본적으로 Kubenet이라는 내장 플러그인이 있긴 하나, 기능이 턱없이 부족해 Flannel, Calico 같은 서드 파티 CNI 플러그인이 많이 사용된다.
:* ClusterIP, NodePort, LoadBalancer: 보통 대형 IT 프로젝트가 k8s를 사용한다면 대부분의 서비스, 특히 백엔드 서비스는 보안을 위해 외부에 노출시키지 않는다. 그래서 보통 서비스들은 ClusterIP 타입으로 내부망에서 서비스 이름으로만 통신하도록 되어 있다. 그러나 이렇게만 하면 디버깅도 어렵고, 프론트엔드 서버처럼 외부 네트워크에 노출시켜야 하는 서버가 있을 것이다. 보통 서비스의 작동 여부를 확인할 때에는 NodePort 타입의 서비스를 설정하며, 영구적으로 외부에 노출시킬 때에는 CNI 플러그인을 설치해서 LoadBalancer 타입으로 적절한 파드(또는 복수의 파드)가 노출되도록 한다.

* 퍼시스턴트 볼륨 및 퍼시스턴트 볼륨 클레임 
도커 엔진을 쓸 때 볼륨으로 특정 디렉토리를 호스트에 마운트하여 원하는 파일을 컨테이너 내에 추가하고 수정할 수 있는 것처럼, k8s에도 퍼시스턴트 볼륨(Persistent Volume)이라는 개념으로 컨테이너 내에서 변화된 데이터를 노드에 영구적으로 저장할 수 있다. 문제는 클러스터 단위로 움직이는 k8s답게 어느 워커 노드에 어느 볼륨이 들어갈 지는 k8s 마스터 노드 마음대로이며, 파드를 잠시 내렸다 다시 마운트하려면 워커 노드를 찾아다니면서 수동으로 마운트/언마운트를 해야 하는 불편이 있다.

그래서 워커를 찾아다니며 볼륨 할당을 일일이 하는 것은 귀찮기 때문에, Longhorn 같은 볼륨 관리 플러그인과 연계해 퍼시스턴트 볼륨을 디플로이먼트/스테이트풀 셋 배포 단계에서 설정하는 퍼시스턴트 볼륨 클레임(PVC) 기능이 있다.

* 메타데이터: 타입과 네임스페이스 
이렇게 복잡한 k8s 배포 구조 때문에 종종 디플로이먼트/스테이트풀셋 등을 배포할 때 이름이 겹치거나 혼동하기 쉬운 이름들을 가진 여러 서비스들이 생길 수 있다. 이를 완화하기 위해 모든 k8s 작업 단위에는 메타데이터가 있으며, 그 안에서 작업 단위의 타입(예: frontend, backend)를 임의로 지정하거나 네임스페이스라는 단위로 아예 특정 서비스들을 위한 여러 작업 단위를 한꺼번에 분리할 수 있다.

k8s에 설치되는 플러그인들도 각기 네임스페이스로 격리되기 때문에, 운 나쁘게 배포한 디플로이먼트 내 파드 이름이 플러그인의 파드 이름과 겹쳐 배포가 실패하는 일은 일반적으로 없다. 기본적으로 k8s 클러스터 내에 생성되는 기본 네임스페이스의 이름은 'default'다.

* 컨피그맵과 시크릿
도커 컴포즈로 컨테이너 이미지의 환경설정을 하는 것처럼 컨피그맵과 시크릿이란 단위로 특정 값 또는 데이터를 배포하여 디플로이먼트에 각각 'envFrom' 및 'secret' 키로 연결하게 할 수 있다. 주 용도는 컨테이너 이미지 내 환경 변수 설정 및 SSL 인증서 키 등록.

* 인그레스
k8s는 일반적으로 대형 IT 회사의 웹 서비스 프로젝트에 사용한다고 하는데, 보통 이런 서비스는 마이크로서비스 아키텍처(Microservice Architecture, MSA) 형태를 가지고 있는 경우가 거의 전부라고 해도 좋다. 이 경우 별 다른 설정이 없다면 외부 사용자가 원하는 기능을 사용하기 위해서는 각 마이크로서비스가 k8s LoadBalancer 서비스 형태로 외부로 노출된 IP 및 포트를 클라이언트가 다 알고 찾아가야 한다.

이런 경우를 대비해 여러 IP 및 포트를 외부에 노출시키는 대신, 하나의 게이트웨이 IP 주소를 만들고 그 아래의 URI만 알면 클라이언트가 URI를 따라 k8s 서비스를 알아서 찾아가게 할 수 있는데, 이 기능을 인그레스(Ingress)라고 한다. MSA와 찰떡궁합이라는 특성이 있으며, SSL 설정이 필용할 때 인그레스가 설정된 경우 그 게이트웨이 IP 주소에만 TLS 설정을 걸면 끝난다! 다만 이 경우 시크릿으로 SSL 인증서 데이터를 업로드해야 하지만...

반대로 모든 서비스의 응답을 하나의 주소로 모아 클라이언트로 반환하는 이그레스(Egress)도 있긴 한데, 이건 나가는 트래픽까지 특정 포트로 강요해야 하는 아주 특별한 경우가 아니면 보통 잘 건드리지 않는다. 대부분의 공개 클라우드 서비스(AWS, Azure, GCP 및 기타) 위 퍼블릭 가상 네트워크가 방화벽 단에서 아웃바운드 트래픽을 무제한으로 허용하는 설정이 기본값인 것과 비슷하다.

== [[도커]]와 쿠버네티스 ==
도커와 쿠버네티스는 모두 리눅스 컨테이너 기술을 활용해 이미지를 만들어 배포할 때 사용하는 기술이다. 그러나 도커는 쿠버네티스와 같은 역할을 하지 않는다.

도커는 주로 컨테이너 이미지를 만드는 데에 초점이 맞추어져 있으며, 도커 엔진으로 그 이미지를 배포할 때에는 순전히 도커 사의 고유 엔진을 활용할 뿐, 쿠버네티스처럼 여러 엔진 중에 골라서 배포하지 않는다. 반면 쿠버네티스는 리눅스 컨테이너 이미지를 배포하는 데에 초점을 맞추며, containerd를 비롯한 여러 컨테이너 엔진을 활용하는 소프트웨어다.

심지어 쿠버네티스는 도커 엔진을 사용할 수 없다! 도커 사가 자꾸 자사만의 고유 규격을 추가한다고 쿠버네티스 1.20부터 도커 엔진 지원을 중단하였기 때문이다. 현재 k8s의 기본 컨테이너 엔진은 containerd인데, 한국에는 도커 엔진에 비해 많이 알려지지 않은 데다가 사용자가 대형 IT 회사 위주로 한정되어서, 소규모 회사들이 컨테이너 기술을 활용한다면 아직 도커 및 도커 엔진(+도커 컴포즈) 정도만 쓰고 있다.

한편 도커 사는 k8s에 대응하는 솔루션으로 도커 스웜(Docker swarm)을 보유하고 있다.

== 같이 보기 ==
* [[도커]]
* [[리눅스]]

Kubernetes

2025-06-07T14:05:09Z

Senouis: /* 주요 개념 */

Kubernetes

2025-06-07T14:04:50Z

Senouis: /* 주요 개념 */

[[분류: IT]]
[[분류: 클라우드 서비스]]

'''Kubenetes'''(쿠버네티스) 또는 k8s는 다수의 리눅스 컨테이너 이미지를 여러 개의 노드 서버에서 자동으로 분배하여 배포 및 실행할 수 있는 환경을 제공하는 오픈 소스 시스템이다. 현재는 리눅스 재단이 관리하고 있다.

== 개발 배경 및 쓰임 ==
쿠버네티스는 구글이 자사의 수많은 서비스(지메일, 유튜브, 구글 드라이브 및 구글 독스, 구글 맵 및 기타)를 많은 서버에 적절히 분배하여 관리하기 위해 사내 엔지니어들이 만든 서비스 배포 시스템을 2014년 오픈 소스 프로젝트로 공개한 프로젝트다. 이후 수많은 대형 IT 회사들이 자사의 서비스들을 쉽게 관리하기 위한 사내 클라우드(On-premise Cloud) 시스템을 구축하기 위해 쿠버네티스를 채용하면서 2020년 이후 조금씩 파이가 커지고 있다.

구글이 만든 프로젝트인 만큼 [[구글 클라우드 플랫폼]](GCP)에서는 GKE(Google Kubenetes Engine)이란 이름으로 자사 클라우드 서비스를 사용하는 회사들을 위해 각종 서비스들을 통합해서 관리하는 쿠버네티스 시스템 관리 서비스를 제공하고 있다.

리눅스의 운영체제 수준 가상화(컨테이너)를 활용한 기술인 만큼 리눅스에서만 지원되고 [[마이크로소프트 윈도우|윈도우]]에서는 지원되지 않는다.

== 주요 개념 ==
* 마스터 노드와 워커 노드 
쿠버네티스는 컴퓨터들의 묶음인 클러스터들 위에서 돌아가며, 클러스터 내 각 컴퓨터는 클러스터 별 작업 분배를 담당하는 마스터 노드와 실제로 작업 단위들을 받아 실행하는 워커 노드들로 이루어져 있다. 보통 쿠버네티스를 제대로 사용한다면 마스터 노드 2개 이상, 그리고 각 마스터마다 2~3개 이상의 워커는 있어야 한다. 그리고 이게 개인 및 소규모 회사들이 k8s를 공부하고 사용하기 어렵게 만드는 첫 번째 요인이다. 즉 대형 프로젝트를 굴리는 게 아니면 k8s가 쓸모가 없다는 것. 그나마 이 문제점을 개선한다고 k3s나 minikube 같은 파생 프로젝트들이 나왔긴 하나, 후술할 두 번째 이유로 여전히 공부하고 쓰기 어렵다...

* 파드 
컨테이너의 기본 작업 단위이다. 파드를 배포하기 위해 배포 유형별로 정해진 양식의 [[YAML|yml]] 파일을 만들어 가져올 컨테이너 이미지를 설정하고, 볼륨과 환경변수, 실행 커맨드들을 설정한다는 개념 측면에서는 도커 컴포즈로 배포하는 상황이랑 비슷하나, 도커 컴포즈에서 설정할 법한 옵션들은 spec이란 키 안에 전부 잡아 넣고 그 외에도 훨씬 많은 옵션들을 설정한다. 그리고 이 옵션들이 k8s를 개인 및 소규모 회사 내 직원들이 공부하고 채용하기 어렵게 만드는 두 번째 원인이다(...)

아예 설정용 YAML 양식을 자기 업무용 컴퓨터에 미리 써 놓고 복붙하며 배포하는 게 편하긴 하다. 그것도 귀찮으면 ChatGPT가 만든 기본 양식을 적당히 맞게 수정하여 쓰는 일도 있는듯...

다행히도 파드 별로 저런 설정을 넣는 것이 아니라, 보통 다음에 소개할 스테이트풀 셋이나 디플로이먼트에서 설정한 옵션을 파드가 대부분 상속받는 구조인 것이 그나마 위안...

* 데몬 셋, 리플리카 셋, 스테이트풀 셋 
동일하게 복제된 여러 파드의 묶음인 작업 단위를 의미한다. 리플리카셋은 보통 후술할 디플로이먼트에 귀속된 경우가 많으며, 배포를 시작할 때 파드 배포 순서가 정해져 있지 않다. 스테이트풀 셋은 파드 배포 순서가 정해져 있으며, 보통 '(파드 배포 이름)-0'부터 뒤의 숫자가 올라가는 방식으로 파드 별 이름이 결정된다. 데몬 셋은 '반드시 모든 워커 노드에서 동일한 파드 하나씩' 실행하는 특수한 경우에 사용하는데, 보통 워커 노드들에 기능을 추가하는 쿠버네티스용 플러그인(예: Calico 같은 CNI, Longhorn 같은 볼륨 관련 플러그인)을 설치할 때 데몬셋 형태로 파드가 배포된다.

DBMS를 굳이 k8s로 배포하겠다고 하겠다면 스테이트풀 셋이 적당하다. 리플리케이션 순서를 정하게 하기 쉽다. 그러나 보통 DBMS는 k8s로 배포하는 경우가 많지 않는데, 어쩌다 워커 노드가 하나 맛이 갔는데 그 안에 DBMS 파드가 들어있었다면 데이터 동기화가 개판이 되기 때문. 특히 시스템의 규모가 클 수록 그 피해의 크기는 상상을 초월한다... 그래서 k8s 클러스터에서 DBMS는 보통 따로 분리해 별도의 물리 컴퓨터들에 설치하는 편이다.

* 디플로이먼트 
보통 웹 서비스를 개발하고 k8s에 컨테이너 이미지로 배포한다면 디플로이먼트 단위로 배포한다. 여기에 옵션들을 주고 컨테이너 이미지를 배포하면 리플리카 셋이 생성되고, 거기에 다시 파드들이 붙는다.

* 서비스 
어쨌든 k8s는 컴퓨터들의 클러스터에서 여러 프로젝트들이 돌아가는 구조이므로, 최소한의 네트워크 통신으로 파드로 올려진 컨테이너 간의 네트워크 통신이 필요하다. k8s는 이런 파드 간 네트워크 통신 관련 정보를 배포할 때에 '서비스'라는 단위로 배포한다. 서비스에서는 네트워크 통신을 위한 포트 설정이 필수적이다. 기본적으로 Kubenet이라는 내장 플러그인이 있긴 하나, 기능이 턱없이 부족해 Flannel, Calico 같은 서드 파티 CNI 플러그인이 많이 사용된다.
:* ClusterIP, NodePort, LoadBalancer: 보통 대형 IT 프로젝트가 k8s를 사용한다면 대부분의 서비스, 특히 백엔드 서비스는 보안을 위해 외부에 노출시키지 않는다. 그래서 보통 서비스들은 ClusterIP 타입으로 내부망에서 서비스 이름으로만 통신하도록 되어 있다. 그러나 이렇게만 하면 디버깅도 어렵고, 프론트엔드 서버처럼 외부 네트워크에 노출시켜야 하는 서버가 있을 것이다. 보통 서비스의 작동 여부를 확인할 때에는 NodePort 타입의 서비스를 설정하며, 영구적으로 외부에 노출시킬 때에는 CNI 플러그인을 설치해서 LoadBalancer 타입으로 적절한 파드(또는 복수의 파드)가 노출되도록 한다.

* 퍼시스턴트 볼륨 및 퍼시스턴트 볼륨 클레임 
도커 엔진을 쓸 때 볼륨으로 특정 디렉토리를 호스트에 마운트하여 원하는 파일을 컨테이너 내에 추가하고 수정할 수 있는 것처럼, k8s에도 퍼시스턴트 볼륨(Persistent Volume)이라는 개념으로 컨테이너 내에서 변화된 데이터를 노드에 영구적으로 저장할 수 있다. 문제는 클러스터 단위로 움직이는 k8s답게 어느 워커 노드에 어느 볼륨이 들어갈 지는 k8s 마스터 노드 마음대로이며, 파드를 잠시 내렸다 다시 마운트하려면 워커 노드를 찾아다니면서 수동으로 마운트/언마운트를 해야 하는 불편이 있다.

그래서 워커를 찾아다니며 볼륨 할당을 일일이 하는 것은 귀찮기 때문에, Longhorn 같은 볼륨 관리 플러그인과 연계해 퍼시스턴트 볼륨을 디플로이먼트/스테이트풀 셋 배포 단계에서 설정하는 퍼시스턴트 볼륨 클레임(PVC) 기능이 있다.

* 메타데이터: 타입과 네임스페이스 
이렇게 복잡한 k8s 배포 구조 때문에 종종 디플로이먼트/스테이트풀셋 등을 배포할 때 이름이 겹치거나 혼동하기 쉬운 이름들을 가진 여러 서비스들이 생길 수 있다. 이를 완화하기 위해 모든 k8s 작업 단위에는 메타데이터가 있으며, 그 안에서 작업 단위의 타입(예: frontend, backend)를 임의로 지정하거나 네임스페이스라는 단위로 아예 특정 서비스들을 위한 여러 작업 단위를 한꺼번에 분리할 수 있다.

k8s에 설치되는 플러그인들도 각기 네임스페이스로 격리되기 때문에, 운 나쁘게 배포한 디플로이먼트 내 파드 이름이 플러그인의 파드 이름과 겹쳐 배포가 실패하는 일은 일반적으로 없다. 기본적으로 k8s 클러스터 내에 생성되는 기본 네임스페이스의 이름은 'default'다.

* 컨피그맵과 시크릿
도커 컴포즈로 컨테이너 이미지의 환경설정을 하는 것처럼 컨피그맵과 시크릿이란 단위로 특정 값 또는 데이터를 배포하여 디플로이먼트에 각각 'envFrom' 및 'secret' 키로 연결하게 할 수 있다. 주 용도는 컨테이너 이미지 내 환경 변수 설정 및 SSL 인증서 키 등록.

* 인그레스
k8s는 일반적으로 대형 IT 회사의 웹 서비스 프로젝트에 사용한다고 하는데, 보통 이런 서비스는 마이크로서비스 아키텍처(Microservice Architecture, MSA) 형태를 가지고 있는 경우가 거의 전부라고 해도 좋다. 이 경우 별 다른 설정이 없다면 외부 사용자가 원하는 기능을 사용하기 위해서는 각 마이크로서비스가 k8s LoadBalancer 서비스 형태로 외부로 노출된 IP 및 포트를 클라이언트가 다 알고 찾아가야 한다.

이런 경우를 대비해 여러 IP 및 포트를 외부에 노출시키는 대신, 하나의 게이트웨이 IP 주소를 만들고 그 아래의 URI만 알면 클라이언트가 URI를 따라 k8s 서비스를 알아서 찾아가게 할 수 있는데, 이 기능을 인그레스(Ingress)라고 한다. MSA와 찰떡궁합이라는 특성이 있으며, SSL 설정이 필용할 때 인그레스가 설정된 경우 그 게이트웨이 IP 주소에만 TLS 설정을 걸면 끝난다! 다만 이 경우 시크릿으로 SSL 인증서 데이터를 업로드해야 하지만...

반대로 모든 서비스의 응답을 하나의 주소로 모아 클라이언트로 반환하는 이그레스(Egress)도 있긴 한데, 이건 나가는 트래픽까지 특정 포트로 강요해야 하는 아주 특별한 경우가 아니면 보통 잘 건드리지 않는다. 대부분의 공개 클라우드 서비스(AWS, Azure, GCP 및 기타) 위 퍼블릭 가상 네트워크가 방화벽 단에서 아웃바운드 트래픽을 무제한으로 허용하는 설정이 기본값인 것과 비슷하다.

== [[도커]]와 쿠버네티스 ==
도커와 쿠버네티스는 모두 리눅스 컨테이너 기술을 활용해 이미지를 만들어 배포할 때 사용하는 기술이다. 그러나 도커는 쿠버네티스와 같은 역할을 하지 않는다.

도커는 주로 컨테이너 이미지를 만드는 데에 초점이 맞추어져 있으며, 도커 엔진으로 그 이미지를 배포할 때에는 순전히 도커 사의 고유 엔진을 활용할 뿐, 쿠버네티스처럼 여러 엔진 중에 골라서 배포하지 않는다. 반면 쿠버네티스는 리눅스 컨테이너 이미지를 배포하는 데에 초점을 맞추며, containerd를 비롯한 여러 컨테이너 엔진을 활용하는 소프트웨어다.

심지어 쿠버네티스는 도커 엔진을 사용할 수 없다! 도커 사가 자꾸 자사만의 고유 규격을 추가한다고 쿠버네티스 1.20부터 도커 엔진 지원을 중단하였기 때문이다. 현재 k8s의 기본 컨테이너 엔진은 containerd인데, 한국에는 도커 엔진에 비해 많이 알려지지 않은 데다가 사용자가 대형 IT 회사 위주로 한정되어서, 소규모 회사들이 컨테이너 기술을 활용한다면 아직 도커 및 도커 엔진(+도커 컴포즈) 정도만 쓰고 있다.

== 같이 보기 ==
* [[도커]]
* [[리눅스]]