IT 위키 - 사용자 기여 [ko]

깃 브랜치

2021-08-01T06:32:35Z

웹마스터: 새 문서: 분류:프로그래밍분류:프로젝트 관리 * 상위 문서: 깃 == 깃 브랜치 특징 == ;가상 폴더 * 작업 폴더를 실제로 복사하지 않고 물리적...

[[분류:프로그래밍]][[분류:프로젝트 관리]]
* 상위 문서: [[깃]]

== 깃 브랜치 특징 ==
;가상 폴더
* 작업 폴더를 실제로 복사하지 않고 물리적인 바이너리 파일 하나로 관리
* 물리적으로 복제된 폴더 형태 보다 더 효율적인 관리 및 빠르고 유연한 작업 처리 가능

;독립적 동작
* 변경 사항만 저장·관리하는 단일 파일로, 코드 비교 및 병합에 유리
** 실제 물리적인 폴더인 경우 모든 소스코드를 하나하나 비교해야 함
* 여러 브랜치를 운용하는 큰 규모의 프로젝트에 유리

;빠른 동작
* 규모가 큰 레파지토리를 전체 복사하는 것 보다 훨씬 빠른 속도로 생성 가능
* 변경내역을 관리하는 단일 파일 하나만 생성하므로 전체 소스의 규모에 무관
* 포인터와 유사한 Blob을 이용하여 빠른 브랜치 이동 가능

버전 관리 시스템

2021-08-01T06:23:31Z

웹마스터:

[[분류:소프트웨어 개발 도구]][[분류:프로젝트 관리]]
;Version Control System; VCS

== 발전 과정 ==
* 최초의 버전 관리 시스템은 유닉스 환경에서 사용되었던 [[SCCS]]

== 집중형 VCS ==
;Centralized Version Control System
모든 소스 코드가 한 곳에 집중되어 있는 형태
* 클라이언트-서버 모델이라고도 함
* 장점: 운영 관리의 효율성
* 단점: [[단일 장애점 문제]], 소스 코드 충돌

=== 장단점 ===
* 장점
** 운영 관리의 효율성
** 이해하고 사용하기 편리함
* 단점
** [[단일 장애점 문제]]
** 소스 코드 충돌 관리
=== 예시 ===
* [[SCCS]]
* [[RCS]]
* [[CVS]]
* [[서브비전]]

== 분산형 VCS ==
;Distributed Version Control System
* 여러 개의 레파지토리에 각 버전별 소스를 개별 보관
* 분산 저장소는 [[P2P|P2P 방식]]으로 소스 코드 공유
=== 장단점 ===
* 중앙 서버에 문제가 생기더라도 운영 가능
* 네트워크가 없는 환경에서도 개발 진행 가능(네트워크 연결 후 동기화)
=== 단점 ===
* 이해 및 사용법의 어려움
=== 예시 ===
* [[Git]]
* [[머큐리얼]]

버전 관리 시스템

2021-03-21T06:11:49Z

웹마스터:

[[분류:소프트웨어 개발 도구]][[분류:프로젝트 관리]]
;Version Control System; VCS

== 발전 과정 ==
* 최초의 버전 관리 시스템은 유닉스 환경에서 사용되었던 [[SCCS]]

== 집중형 VCS ==
모든 소스 코드가 한 곳에 집중되어 있는 형태
* 클라이언트-서버 모델이라고도 함
* 장점: 운영 관리의 효율성
* 단점: [[단일 장애점 문제]], 소스 코드 충돌

=== 분산형 ===
;Distributed Version Control System
* 여러 개의 레파지토리에 각 버전별 소스를 개별 보관
* 분산 저장소는 P2P 방식코드가 한 곳에 집중되어 있는 형태
* 클라이언트-서버 모델이라고도 함
=== 장단점 ===
* 장점
** 운영 관리의 효율성
** 이해하고 사용하기 편리함
* 단점
** [[단일 장애점 문제]]
** 소스 코드 충돌 관리
=== 예시 ===
* [[SCCS]]
* [[RCS]]
* [[CVS]]
* [[서브비전]]

== 분산형 VCS ==
;Distributed Version Control System
* 여러 개의 레파지토리에 각 버전별 소스를 개별 보관
* 분산 저장소는 [[P2P|P2P 방식]]으로 소스 코드 공유
=== 장단점 ===
* 중앙 서버에 문제가 생기더라도 운영 가능
* 네트워크가 없는 환경에서도 개발 진행 가능(네트워크 연결 후 동기화)
=== 단점 ===
* 이해 및 사용법의 어려움
=== 예시 ===
* [[Git]]
* [[머큐리얼]]

버전 관리 시스템

2021-03-21T06:11:18Z

웹마스터: 새 문서: 분류:소프트웨어 개발 도구분류:프로젝트 관리 ;Version Control System; VCS == 발전 과정 == * 최초의 버전 관리 시스템은 유닉스 환경에서...

[[분류:소프트웨어 개발 도구]][[분류:프로젝트 관리]]
;Version Control System; VCS

== 발전 과정 ==
* 최초의 버전 관리 시스템은 유닉스 환경에서 사용되었던 [[SCCS]]

== 분류 ==
집중형과 분산형으로 구분

=== 집중형 ===
모든 소스 코드가 한 곳에 집중되어 있는 형태
* 클라이언트-서버 모델이라고도 함
* 장점: 운영 관리의 효율성
* 단점: [[단일 장애점 문제]], 소스 코드 충돌

=== 분산형 ===
;Distributed Version Control System
* 여러 개의 레파지토리에 각 버전별 소스를 개별 보관
* 분산 저장소는 P2P 방식코드가 한 곳에 집중되어 있는 형태
* 클라이언트-서버 모델이라고도 함
=== 장단점 ===
* 장점
** 운영 관리의 효율성
** 이해하고 사용하기 편리함
* 단점
** [[단일 장애점 문제]]
** 소스 코드 충돌 관리
=== 예시 ===
* [[SCCS]]
* [[RCS]]
* [[CVS]]
* [[서브비전]]

=== 분산형 ===
;Distributed Version Control System
* 여러 개의 레파지토리에 각 버전별 소스를 개별 보관
* 분산 저장소는 [[P2P|P2P 방식]]으로 소스 코드 공유
=== 장단점 ===
* 중앙 서버에 문제가 생기더라도 운영 가능
* 네트워크가 없는 환경에서도 개발 진행 가능(네트워크 연결 후 동기화)
=== 단점 ===
* 이해 및 사용법의 어려움
=== 예시 ===
* [[Git]]
* [[머큐리얼]]

P2P

2021-03-21T06:06:30Z

웹마스터:

;Peer to peer
중앙 서버 없이 각 단말 또는 사용자가 직접 데이터·정보를 교환하는 형태

== 분산 P2P ==
1:1로 주고 받는 기존의 P2P와 달리 각자에게 필요한 데이터를 수요·공급하는 많은 사용자들로부터 데이터를 송·수신하는 구조
* 예시) [[토렌트]], [[블록체인]]

P2P

2021-03-21T06:06:13Z

웹마스터: 새 문서: ;Peer to peer 중앙 서버 없이 각 단말 또는 사용자가 직접 데이터·정보를 교환하는 형태 == 분산 P2P == 1:1로 주고 받는 기존의 P2P와 달리 각자...

;Peer to peer
중앙 서버 없이 각 단말 또는 사용자가 직접 데이터·정보를 교환하는 형태

== 분산 P2P ==
1:1로 주고 받는 기존의 P2P와 달리 각자에게 필요한 데이터를 수요·공급하는 많은 사용자들로부터 데이터를 송·수신하는 구조
* 예시) [[토렌트]]

단일 장애점 문제

2021-03-21T06:01:36Z

웹마스터:

[[분류:소프트웨어 품질]][[분류:소프트웨어 개발]][[분류:보안]]
;Single Point of Failure Problem
중앙 집중화된 시스템 등에서 [[단일 장애점]]이 생겨 시스템의 안정성·안전성에 치명적인 문제가 발생하는 문제

== [[단일 장애점]] ==
* 시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 중요 요소
* 어느 한 요소가 공격 받을 경우 시스템 전체의 가용정, 보안성 등에 문제가 생길 수 있는 지점

== 문제 ==
* 중앙에서 집중하여 통제를 수행하는 아키텍처를 관리의 큰 효율성을 제공하나 보안적으로나 안정성 측면에서 취약
* 효율적 관리를 위한 중앙 시스템의 에러는 모든 시스템의 문제를 야기함

== 해결법 ==
* 시스템 이중화 등 [[고가용성]] 구성 사용
* 분산 아키텍처 구성

== 같이 보기 ==
* [[단일 장애점]]
* [[고가용성]]
* [[장애 허용]]
* [[이중화]]

단일 장애점 문제

2021-03-21T06:00:04Z

웹마스터: 새 문서: 분류:소프트웨어 품질분류:소프트웨어 개발분류:보안 ;Single Point of Failure Problem 중앙 집중화된 시스템 등에서 단일 장애점이...

[[분류:소프트웨어 품질]][[분류:소프트웨어 개발]][[분류:보안]]
;Single Point of Failure Problem
중앙 집중화된 시스템 등에서 [[단일 장애점]]이 생겨 시스템의 안정성·안전성에 치명적인 문제가 발생하는 문제

== [[단일 장애점]] ==
* 시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 중요 요소
* 어느 한 요소가 공격 받을 경우 시스템 전체의 가용정, 보안성 등에 문제가 생길 수 있는 지점

== 문제 ==
* 중앙에서 집중하여 통제를 수행하는 아키텍처를 관리의 큰 효율성을 제공하나 보안적으로나 안정성 측면에서 취약
* 효율적 관리를 위한 중앙 시스템의 에러는 모든 시스템의 문제를 야기함

== 해결법 ==
* 시스템 이중화 등 [[고 가용성]] 구성 사용
* 분산 아키텍처 구성

== 같이 보기 ==
* [[단일 장애점]]
* [[고가용성]]
* [[장애 허용]]
* [[이중화]]

이중화

2021-03-21T05:58:24Z

웹마스터: 새 문서: 분류:소프트웨어 품질 시스템의 장애를 대비하는 등 안정성을 강화하기 위해 같은 시스템을 두 벌 또는 그 이상으로 만들어 두고 로...

[[분류:소프트웨어 품질]]
시스템의 장애를 대비하는 등 안정성을 강화하기 위해 같은 시스템을 두 벌 또는 그 이상으로 만들어 두고 [[로드 밸런싱]]하거나 하나의 시스템에 장애가 생겼을 때 즉시 다른 시스템으로 전환되도록 만들어진 [[고가용성]] 구조

== 동작 방식 ==
=== 액티브-액티브 ===
;Active-active; [[고가용성|Concurrent Access]]
* 동일한 두 벌의 시스템을 같이 운영하는 형태
* 하나의 시스템에 장애가 생기면 장애가 발생하지 않은 나머지 하나의 시스템으로만 가동
** 하나의 시스템으로 버티는 동안 장애가 생긴 시스템 복구
* 장애 대응 뿐만 아니라 시스템의 부하를 줄이거나 개발·테스트의 편의를 위해서도 사용
* 액티브-스탠바이 보다 효율적이나 초기 구성과 운영의 복잡성 및 비용이 높음

=== 액티브-스탠바이 ===
;Active-standby; Hot-standby
* 동일한 두 벌의 시스템을 만들어 두되, 하나의 시스템으로만 운영
** 운영 시스템에 장애가 발생할 경우 다른 시스템으로 즉시 전환
* 전환 시 순단 현상이 발생할 수 있음
* 한 벌의 시스템이 대기 상태로 있어 자원의 비효율성 발생
** [[고가용성|Mutual Takeover]] 방식을 이용해 활용성을 높일 수 있음

== 예시 ==
* [[서버 이중화]]
* [[회선 이중화]]
* [[스위치 이중화]]
* [[방화벽 이중화]]
* [[멀티클라우드]]

== 같이 보기 ==
* [[고가용성]]
* [[장애 허용]]

단일 장애점

2021-03-21T05:46:05Z

웹마스터:

[[분류:보안]]

;Single Point of Failure; SPF; SPOF

== 개요 ==

*시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 중요 요소
*어느 한 요소가 공격 받을 경우 시스템 전체의 가용정, 보안성 등에 문제가 생길 수 있는 지점
*[[단일 장애점 문제]]를 유발한다.

[[파일:단일 장애점 예시 라우터.png]]

== 예시 ==

* 키 관리 시스템
* SSO
* 집중형 레파지토리

==같이 보기==

*[[단일 장애점 문제]]

파일:단일 장애점 예시 라우터.png

2021-03-21T05:45:51Z

웹마스터:

출처: https://ko.wikipedia.org/wiki/단일_장애점

단일 장애점

2021-03-21T05:43:40Z

웹마스터: 새 문서: 분류:보안 ;Single Point of Failure; SPF; SPOF * 시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 중요 요소 * 어느 한 요소가...

[[분류:보안]]
;Single Point of Failure; SPF; SPOF
* 시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 중요 요소
* 어느 한 요소가 공격 받을 경우 시스템 전체의 보안성에 문제가 생길 수 있는 지점

== 같이 보기 ==
* [[단일 장애점 문제]]

SPF

2021-03-21T05:43:28Z

웹마스터: 단일 장애점 문서로 넘겨주기

#넘겨주기 [[단일 장애점]]

버전 관리

2021-03-21T05:39:12Z

웹마스터: 새 문서: Version Control 소스 코드와 콘텐츠의 변화를 관리하고 추적하는 업무·과정 == 형상 관리와의 차이 == * 형상 관리가 버전 관리를 포함하는...

Version Control

소스 코드와 콘텐츠의 변화를 관리하고 추적하는 업무·과정

== 형상 관리와의 차이 ==

* 형상 관리가 버전 관리를 포함하는 개념
* 소스 코드와 컨텐츠의 버전을 관리하던 것에서 더 광범위하게 프로젝트 형상을 관리하는 것으로 확장
* 하지만 많은 형상 관리 도구가 버전 관리 도구와 큰 차이를 가지고 있지 않음<ref>버전 관리 도구의 기능이 꾸준히 발전하며 형상 관리 도구라고 출시된 도구들의 기능을 거의 포함한다. </ref>

== 같이 보기 ==

* [[형상 관리]]
* [[버전 관리 시스템]]

== 각주 ==

OAuth

2019-10-16T15:07:08Z

웹마스터: /* OAuth1.0과 OAuth2.0의 차이 */

[[분류:보안]]
;제3의 신뢰 서비스에서 인증 결과를 토큰 기반으로 공유받아 활용하는 개방형 표준 프로토콜

== 프토토콜 종류 ==
{| class="wikitable"
! 종류
! 설명
|-
| 권한 부여 코드 승인
(Authorization Code Grant Type)
|
* 클라이언트가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용
* 리스소 접근을 위한 사용자 명과 비밀번호, 권한 서버에 요청해서 받은 권한 코드를 함께 활용하여 리소스에 대한 엑세스 토큰을 받는 방식
|-
| 암시적 승인
(Implicit Grant Type)
|
* 권한 부여 코드 승인 타입과 다르게 권한 코드 교환 단계 없이 엑세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식
|-
| 리소스 소유자 암호 자격 증명
(Resource Owner Password Credentials Grant Type)
|
* 클라이언트가 암호를 사용하여 엑세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식
|-
| 클라이언트 자격 증명
(Client Credentials Grant Type)
|
* 클라이언트가 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식
|}

== 인증 절차 ==
* 권한 부여 코드 승인
[[파일:Authorization Code Grant Type.png]]

* 암시적 승인
[[파일:Implicit Grant Type.png]]

* 리소스 소유자 암호 자격 증명
[[파일:Resource Owner Password Credentials Grant.png]]

* 클라이언트 자격 증명
[[파일:Client Credentials Grant Type.png]]

== 구성 ==
{| class="wikitable"
! 구분
! 설명
! 비고
|-
| 자원 소유자
| 요청하고자 하는 자원의 소유자이자, 인증 주체
| 이용자
|-
| 클라이언트
| 자원을 필요로 하는 서비스
자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청
| 쇼핑몰 등
|-
| 권한 서버
| 인증을 처리하고 권한을 부여하는 서버
| rowspan="2" | 페이스북
네이버
구글 등
|-
| 자원 서버
| 자원을 가지고 있는 서버
|-
| 접근 토큰
| 자원 서버에 자원을 요청할 수 있는 토큰
| 유효기간 존재
|-
| 재발급 토큰
| 권한 서버에 접근 토큰을 요청할 수 있는 토큰
| 접근 토큰 유효기간 만료 시 사용
|}

== OAuth1.0과 OAuth2.0의 차이 ==
{| class="wikitable"
! 비교
! [[OAuth1.0]]
! [[OAuth2.0]]
|-
| 참여자 구분
|
* 이용자
* 소비자
* 서비스 제공자
|
*자원 소유자
* 클라이언트
* 권한 서버
* 자원 서버
|-
| 토큰
|
* 요청 토큰(Request Token)
* 접근 토큰(Access Token)
|
* 접근 토큰(Access Token)
* 재발급 토큰(Refresh Token)
|-
| 유효기간
|
* 접근 토큰의 유효기간 없음
|
* 접근 토큰 유효기간 부여
* 만료 시 재발급 토큰 이용
|-
| 클라이언트
|
* 웹 서비스
|
* 웹, 앱 등
|}

== 문제점 ==
* 신뢰된 서비스(권한 서버, 자원 서버)에 개인의 행태 정보가 지나치게 축적되는 문제
** 국가 기관이 아닌 신뢰된 서비스가 과연 신뢰할 수 있는가?

OAuth

2019-10-16T15:06:27Z

웹마스터:

[[분류:보안]]
;제3의 신뢰 서비스에서 인증 결과를 토큰 기반으로 공유받아 활용하는 개방형 표준 프로토콜

== 프토토콜 종류 ==
{| class="wikitable"
! 종류
! 설명
|-
| 권한 부여 코드 승인
(Authorization Code Grant Type)
|
* 클라이언트가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용
* 리스소 접근을 위한 사용자 명과 비밀번호, 권한 서버에 요청해서 받은 권한 코드를 함께 활용하여 리소스에 대한 엑세스 토큰을 받는 방식
|-
| 암시적 승인
(Implicit Grant Type)
|
* 권한 부여 코드 승인 타입과 다르게 권한 코드 교환 단계 없이 엑세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식
|-
| 리소스 소유자 암호 자격 증명
(Resource Owner Password Credentials Grant Type)
|
* 클라이언트가 암호를 사용하여 엑세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식
|-
| 클라이언트 자격 증명
(Client Credentials Grant Type)
|
* 클라이언트가 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식
|}

== 인증 절차 ==
* 권한 부여 코드 승인
[[파일:Authorization Code Grant Type.png]]

* 암시적 승인
[[파일:Implicit Grant Type.png]]

* 리소스 소유자 암호 자격 증명
[[파일:Resource Owner Password Credentials Grant.png]]

* 클라이언트 자격 증명
[[파일:Client Credentials Grant Type.png]]

== 구성 ==
{| class="wikitable"
! 구분
! 설명
! 비고
|-
| 자원 소유자
| 요청하고자 하는 자원의 소유자이자, 인증 주체
| 이용자
|-
| 클라이언트
| 자원을 필요로 하는 서비스
자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청
| 쇼핑몰 등
|-
| 권한 서버
| 인증을 처리하고 권한을 부여하는 서버
| rowspan="2" | 페이스북
네이버
구글 등
|-
| 자원 서버
| 자원을 가지고 있는 서버
|-
| 접근 토큰
| 자원 서버에 자원을 요청할 수 있는 토큰
| 유효기간 존재
|-
| 재발급 토큰
| 권한 서버에 접근 토큰을 요청할 수 있는 토큰
| 접근 토큰 유효기간 만료 시 사용
|}

== OAuth1.0과 OAuth2.0의 차이 ==
{| class="wikitable"
! 비교
! [[OAuth1.0]]
! [[OAuth2.0]]
|-
| 참여자 구분
|
* 이용자
* 소비자
* 서비스 제공자
|
*자원 소유자
* 클라이언트
* 권한 서버
* 자원 서버
|-
| 토큰
|
* 요청 토큰(Request Token)
* 접근 토큰(Access Token)
| 접근 토큰(Access Token)
재발급 토큰(Refresh Token)
|-
| 유효기간
|
* 접근 토큰의 유효기간 없음
|
* 접근 토큰 유효기간 부여
* 만료 시 재발급 토큰 이용
|-
| 클라이언트
| 웹 서비스
| 웹, 앱 등
|}

== 문제점 ==
* 신뢰된 서비스(권한 서버, 자원 서버)에 개인의 행태 정보가 지나치게 축적되는 문제
** 국가 기관이 아닌 신뢰된 서비스가 과연 신뢰할 수 있는가?

파일:Implicit Grant Type.png

2019-10-16T15:05:04Z

웹마스터: 출처: https://cheese10yun.github.io/oauth2/

출처: https://cheese10yun.github.io/oauth2/

파일:Authorization Code Grant Type.png

2019-10-16T15:04:41Z

웹마스터: 출처: https://cheese10yun.github.io/oauth2/

출처: https://cheese10yun.github.io/oauth2/

파일:Client Credentials Grant Type.png

2019-10-16T15:03:57Z

웹마스터: 출처: https://cheese10yun.github.io/oauth2/

출처: https://cheese10yun.github.io/oauth2/

OAuth

2019-10-16T14:50:06Z

웹마스터:

[[분류:보안]]
;제3의 신뢰 서비스에서 인증 결과를 토큰 기반으로 공유받아 활용하는 개방형 표준 프로토콜

== 인증 절차 ==
* OAuth2.0의 프토코톨은 3가지 종류가 있음
** Implicit Grant
** Resource Owner Password Credentials Grant
** Client Credentials Grant Type
* 아래는 이해가 쉬운 Resource Owner Password Credentials Grant 방식의 인증 절차
[[파일:Resource Owner Password Credentials Grant.png]]

== 구성 ==
{| class="wikitable"
! 구분
! 설명
! 비고
|-
| 자원 소유자
| 요청하고자 하는 자원의 소유자이자, 인증 주체
| 이용자
|-
| 클라이언트
| 자원을 필요로 하는 서비스
자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청
| 쇼핑몰 등
|-
| 권한 서버
| 인증을 처리하고 권한을 부여하는 서버
| rowspan="2" | 페이스북
네이버
구글 등
|-
| 자원 서버
| 자원을 가지고 있는 서버
|-
| 접근 토큰
| 자원 서버에 자원을 요청할 수 있는 토큰
| 유효기간 존재
|-
| 재발급 토큰
| 권한 서버에 접근 토큰을 요청할 수 있는 토큰
|
|}

== 문제점 ==
* 신뢰된 서비스(권한 서버, 자원 서버)에 개인의 행태 정보가 지나치게 축적되는 문제
** 국가 기관이 아닌 신뢰된 서비스가 과연 신뢰할 수 있는가?

파일:Resource Owner Password Credentials Grant.png

2019-10-16T14:46:21Z

웹마스터: 출처: https://cheese10yun.github.io/oauth2/

출처: https://cheese10yun.github.io/oauth2/