---
description: 개발자들 대화 혹은, 문서 등에서 나온 생소한 용어들에 대한 간단한 정리.
---

# IT 관련 용어

### **anchor(앵커)**

앵커의 원래 의미는 닻이라는 뜻이다. 앵커는 하이퍼링크(hyperlink)와 같은 의미로, 월드 와이드 웹(WWW) 상에서 밑줄이 그어진 단어나 문구로 나타나게 되며, 이를 누르게 되면 다른 화면이나 페이지로 넘어가게 된다. 앵커는 하이퍼링크보다 자주 쓰이지는 않지만 네트워크 상에서 항해한다거나 서핑(surfing)한다는 등 항해를 주제로 하는 용어를 많이 쓰므로 아직도 쓰이고 있다.

### **EP(Entry Point)**

프로그램의 시작점 또는 그 영역\
프로그램이 실행되면 가장 먼저 처리되는 부분

### **TDD(**&#x54;est Driven Development)

테스트 주도 개발

### Single Sign-On(SSO)

**하나의 아이디 및 패스워드를 통해 여러 시스템에 접근할 수 있는 통합 로그인(인증) 솔루션**

#### SSO의 구축 유형

**1) 인증 대행 모델(Delegation)**

\


![](https://1025637896-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxjso2sUUzWlyxxfqqEWu%2Fuploads%2F72dZpT3ucUyfnUaUKJkQ%2Fimage.png?alt=media\&token=929e5d02-d76f-4240-97a7-f2b8387c76e8)

\- 인증 방식을 변경하기 어려울 경우, 많이 사용

\- 시스템 접근 시, 통합 Agent가 인증 작업을 대행

\
**2) 인증 정보 전달 모델(Propagation)**

\


![](https://1025637896-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxjso2sUUzWlyxxfqqEWu%2Fuploads%2FvZOPGQGluExayTBaYv7c%2Fimage.png?alt=media\&token=efac7bb6-622f-4aa9-a4d2-a17c4dc20f06)

\- 웹 기반의 시스템에 주로 사용

\- 미리 인증된 토큰(Cookie 기능 이용)을 받아서 각 시스템 접근 시, 자동으로 전달

**참고:**[ https://toma0912.tistory.com/75](https://toma0912.tistory.com/75)

### **PoC(Proof of Concept)** <a href="#se-370436c1-f877-4a6a-966a-3e9bad0cb858" id="se-370436c1-f877-4a6a-966a-3e9bad0cb858"></a>

새로운 프로젝트가 실제로 실현 가능성이 있는가, 효과와 효용, 기술적인 관점에서부터 검증을 하는 과정을 의&#xBBF8;**.**



### RBAC(Role Based Access Control)

* **사용자에게 할당된 역할에 기반하여 접근 통제하는 기법**
* 인적자원 관리자가 특정 부서 사용자들에게 같은 직무를 수행할 수 있는 접근 권한을 할당하는 것
* 접근하려는 사용자와 자원이 어떻게 상호작용하는지 결정하여 중앙에서 집중적으로 관리한다.
* BRAC를 위해 정의된 주요 규칙은 다음과 같다.
  1. 역할 할당(Role Assignmnet)
  2. 역할 권한 부여(Role Authorizatino)
  3. 권한 부여(Permission Authorizaiont)

### **Poc(Proof of concept)** <a href="#poc-proof-of-concept" id="poc-proof-of-concept"></a>

Poc란, 새로운 프로젝트가 실제로 실현가능성이 있는지 효과와 효용, 기술적인 관점에서부터 검증을 하는 과정을 의미한다.

&#x20;

**1) 프로토 타입 및 배포**

처음 1단계로 할 것은 컨셉을 검증하기 위한 시제품을 만들어 보는 것이다. 즉, '물건 만들기'이다. 여기서 만들 수 있는 것은 단편 영화나 시용품과 같은 컨셉을 검증하기 위한 최소한의 요소를 가진 것으로, 단기간 안에 만드는 것이 중요하다.

&#x20;

**2) 검증**

두 번째 단계는 검증, 사용해 보는 것으로 관계자나 피험자로부터 피드백을 수집한다. 이것에 의해 탁상 공론으로는 알 수 없었던 문제나 수정해야 할 사항, 방향성 등을 발견할 수 있다.

&#x20;

**3) 실현 여부 판단**

마지막 단계는 이 컨셉이 실현 가능할 것인지 불가할 것인지 판단하는 단계이다. 투자에 대해서 충분한 효과를 얻을 수 있는 경우에는, 실용화나 본격 도입을 위한 Go 사인을 내고, 본격적인 프로젝트를 실시한다. 그렇지 않은 경우에는 실현을 중단해 PoC는 끝나는 것이다. 컨셉을 조정, 수정하는 것으로 실현 가능성이 높아진다고 판단되는 경우에는 컨셉의 기획 단계로 돌아가, 다시 PoC를 실시한다. 컨셉을 조정하며 몇 번이고 PoC 과정을 반복하는 일도 그렇게 드문 일도 아니다.

