IT 회사 면접 전, 기본 이론 정리해보기, 개발 직군, IT 지식

11년 경력,  오래된 만큼 인터뷰나 면접 시 경력직에게 기초적인 이론 질문을 하는 경우가 많았다. 성향상 용어를 달달 외우기보다 원리를 이해하고 업무를 수행하는 편이라 용어에 약한 편인데, 작년부터 규모가 있는 기업에 이력서가 통과되면 이런 부분에 부족하다는 것을 깨달았다. 실무 할 때 개발자와 소통하거나 고객사와 소통하는 데는 문제가 없었지만 또 다른 순간엔 필요할 수 있다는 생각이 들어 끄쩍끄적 정리해보고자 한다.

---

IaaS / PaaS / SaaS

클라우드 기반 서비스

• IaaS , AWS , infrastructure as a service
• PaaS , 미들웨어 제우스 같은 것,  Platform as a service
  • 관련 인프라를 만들고 유지보수하는 복잡함 없이 애플리케이션을 개발, 실행, 관리할 수 있게 하는 플랫폼
• SaaS , Slack, Software as a service , 타사 공급업체에서 제공하는 소프트웨어를 의미

 

RESTAPI

웹에 최적화 되어 있는 아키텍쳐. Representational State Transfer Application Program Interface의 약자입니다. 
시스템에는 데이터와 같은 자원이 있는데 이 자원들을 활용하고 싶은 여러 응용 시스템이 있을 것이고, 거기에 알맞게 제공해야합니다. 그러기 위해 이름을 정하여 정리해둔다고 생각하면 됩니다. 정리 되지 않은 것들을 정리하여 이름을 붙이고 그것을 주고 받을 수 있도록 구현한 것을 REST라고 표현합니다. (백앤드와 프론트엔드가 서로 잘 주고 받을 수 있도록 제공)

특징 
1. URI 사용
2. 무상태성 , 작업을 위한 상태 정보를 저장하고 관리하지 않음. 단순 요청 처리 → 자유도가 높아짐
3. 캐시가능 , 웹 표준을 그대로 사용, HTTP가 가진 캐싱 기능이 적용 가능.
4. 자체표현구조, REST API 메시지만 가지고 쉽게 이해할 수 있는 구조
5. Client- Server 구조로 서로 해야할 일이 명확하여 의존성이 줄어듬.
6. 계층형 구조 - REST 서버는 다중 계층으로 구성 될 수 있음. 보안, 로드밸런싱, 암호화 계층을 추가하여 구조상 유연, PROXY 및 게이트웨이 우회 가능하도록 네트워크 구성이 가능

개인적으로 5,6번은 모든 서버가 가능한게 아닌가 라는 생각을 하고 있다..

URL과 URI 차이

URL(Uniform Resource Locator)은 자원이 실제로 존재하는 위치를 가리키며, URI(Uniform Resource Identifier)는 자원의 위치뿐만 아니라 자원에 대한 고유 식별자로서 URL를 포함.

URI는 설계 시 주의할 점이 많다. 

• 마지막에는 /를 포함하지 않는다.
• _을  사용하지 않는다.
• 경로에는 소문자가 적합하다.
• 리소스 명은 동사보다는 명사를 사용

예제)

• URL : https://odaily.tistory.com 
• URI : https://odaily.tistory.com/manager/433 

 

트래픽과 대역폭

• 트래픽 : 일정 시간 동안 총 사용하는 데이터 양
• 대역폭 : 초당 처리할 수 있는 데이터 양
• 대역폭 측정 방법
  • 계산 법 : (용량 * 사용자수 * 8(bit)) / 처리 시간 = bps(bit per second)
  • 실무 : iperf3 서버와 클라이언트 각각 설치 후 명령어 사용

---

SSO(Single Sign On)

단일 로그인 

 

세션과 쿠키의 차이

• 웹 통신간 데이터 저장 공간, 클라이언트와 정보 유지를 하기 위해 사용한다.
• 가장 큰 차이는 저장 장소이다. (세션 = 서버, 쿠키 = 클라이언트)
• 세션이 쿠키에 비해 보안이 높지만, 서버에 저장되기 때문에 소모되는 자원이 크다. 효율적인 자원 관리를 위해 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여 웹 사이트 속도도 높인다.

 

JWT(JSON Web Token)  - OIDC(OpenID Connect)

웹 표준의 토큰 생성 방식으로 필요한 정보를 자기 토큰 값에 가지고 있다. 보통 json으로 데이터 주고받을 때 사용하며 구성 형태는 header, payload, signature 형태이다.

JWT는 토큰 자체에 유저 정보를 담고 있기 때문에 HTTP 헤더에 실어 전달함으로써 유저 세션을 유지할 필요가 없고 가볍게 데이터를 주고받을 수 있다는 장점이 있다. JWT는 발급 후 Verify Signature로 검증만 하면 되기 때문에 추가 저장소가 필요가 없다. 추가 저장소가 필요하지 않기 때문에, 유지 보수 및 서버 확장에 훨씬 유리하다

사용하는 서비스 예
- 네이버 OPEN API에서 사용 (링크 : 비로그인 방식)

단점 

1. 이미 발급된 JWT 토큰은 돌이킬 수 없다. 세션/쿠키는 악의적 활용 시 지우면 되지만, JWT는 한 번 발급될 경우 유효기간까지 사용할 수 있다. 악용될 경우 유효기간 지나기 전까지 정보 사용이 가능하다.
2. payload 정보가 암호화되지 않아 디코딩이 쉽고, 그 정보는 누구나 확인할 수 있다.
3. 데이터가 많아질수록 서버의 자원 낭비가 발생한다.

JWT와 다른 것의 차이 

• 세션/쿠키는 세션 저장소에 유저의 정보를 넣는 반면, JWT는 토큰 안에 유저의 정보들이 들어간다는 점이 가장 큰 차이점이다.
• JWT는 토큰의 종류이고, OAuth는 토큰을 발급하고 인증하는 표준 프로토콜. 즉 OAuth랑 비교 시 OpenID랑 비교해야 한다

 

반응형

---

인증(Authentication)과 승인(Authorization)의 차이

신원 확인과 권한 받는 것

OAuth란?

비밀번호 입력 필요 없이 타 API 서비스를 이용하여 로그인할 때 사용하는 프로토콜. 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로써 사용되는 접근

등장 배경

STEP 1. ID/PW 사용자 로그인 → 비밀번호 노출 이슈
STEP 2. OpenID 사용 → 계정 하나로 모든 서비스를? 제3의 서비스를 가입해야 하는 부담
STEP 3. 사용자가 인증 권한을 컨트롤할 수 있도록 OAuth 제공

장점

1. 보안, 비밀번호 미노출
2. 인증과 API 관련 권한 동시에 가능

OAuth 2.0의 4가지 방식

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

1.  권한 부여(Authorization code Grant)

• 자신만의 서버를 가지고 동작하는 서비스 일 경우 사용
• 3rd-party를 위한 인증방식을 제공 
• 보통 기업들 API 서비스 제공 시 사용하는 것으로 보여짐

로그인 시에 페이지 URL에 response_type=code로 넘김

사용하는 서비스 예
- Slack API (링크 :  https://api.slack.com/authentication/oauth-v2)
- 티스토리 OPEN API (링크 : https://tistory.github.io/document-tistory-apis/)

< 인증 → 인증 코드 → 인증 코드 및 기타 정보 → 접근 가능한 token 제공 → 정보 및 token 으로 데이터 요청 → 보호된 데이터 전달 >

2.  암시적 승인 (Implicit Grant)

• 백엔드 서버 없이 순수 클라이언트로 동작하는 앱 일 경우 사용, 즉 모바일과 같이 클라이언트에서 사용하는 flow에 적합
• 주로 read only 서비스에 사용
• client ID가 하드코딩되어 있어 다른 방법에 비해 보안상 단점.
• refresh 토근이 발급되지 않음.

로그인 시 페이지 URL에 response_type=token으로

사용하는 서비스 예
- 과거 티스토리 Open API (링크 : Tistory API )
- Microsoft  (링크 : 마이크로소프트  Azure )

3. 클라이언트 자격 증명 타입(Client Credentials Grant)

앱이나 서비스 자체에 인증 및 권한 부여하는 방식입니다.

앱 아이디와 시크릿을 https로 직접 전달해 토큰을 받습니다. 물론 javascript 앱이나 모바일일 같이 같이 시크릿이 노출되는 환경에서 쓰면 안 됩니다.  폐쇄망에서 사용하는 것을 추천한다고 한다.

로그인 시에 API에 POST로 grant_type=client_credentials 

사용하는 서비스 예

• IBM Cloud Identity Portal  (링크 :  https://www.ibm.com/docs/ko/cip?topic=api-managing-keys )
• Spotify (링크 : https://developer.spotify.com/documentation/general/guides/authorization/client-credentials/)
  
  

4. 리소스 소유자 암호 자격 증명 타입(Resource Owner Password Credentials Grant)

• 서비스의 가입자가 자신의 ID/PW를 가지고 접근하는 방식에 적합. 앱 로그인을 위한 주 용도로 사용
• 사용자와 앱 사이에 높은 신뢰가 형성된 경우에 적합
• 인증코드 없이 id와 password를 사용해서 access token을 발급받음
• Authorization Server(권한 서버)에 접속해서 인증하기 때문에 client id와 secret을 하드코딩하게 됨
• 그렇기 때문에 보안상 위험이 있을 수 있으나, access token을 발급받기 위해서 사용자 id와 password도 동시에 필요하기 때문에 보안상 위험을 상호 보안 가능
• access token을 발급받은 이후에 id와 password를 삭제할 것을 권고하고 있습니다.
• 로그인 시에 API에 POST로 grant_type=password

사용하는 서비스 예 (찾는 중..)

참고

* access token : 보호된 리소스에 접근할 때 권한 확인용
* 예시 중 Spotify 서비스는 다양한 인증 방식 제공하고 있다.

---

OAuth와 OpenID의 차이

OAuth는 권한을 목표로 설계, OpenID는 인증을 목표로 설계한 툴이다

	SAML	OAuth 2.0	OIDC
포맷	XNL	JSON	JSON
권한(authorization)	O	O	X
인증(authentication)	O	O	O
생성년도	2001	2005	2006
사용 용도	SSO for Enterprise * 모바일은 적합하지 않음	API Service authorization	SSO for cunsumer apps

 

표준 인증 스킴

• Bearer : OAuth 2.0, 사용자 인증이 아닌 인가를 위한 인증 방식
• Basic : ID/PW를 헤더에 Base64 인코딩하여 전송, 보안에 취약하며 HTTPS가 필수
• Mutual : 인증서를 이용한 인증 방식
• AWS4-HMAC-SHA256 : 아마존에서 제공하는 인증 방식

---

NAT ( Network Address Translation) 

네트워크 주소 변환하는 기능. 동적, 정적이 있지만 보통 사용하는 건 dynamic NAT라고 생각한다.

공인 IP 1개 ↔ 사설 IP N개  분배하여 사용하는 시스템 , NAT를 쓰는 이유는 여러 대의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위한 경우가 대부분이다. NAT는 내부 네트워크에서 사용하는 IP 주소와 외부에 드러나는 주소를 다르게 유지할 수 있기 때문에 내부 네트워크에 대한 어느 정도의 보안이 가능하다.

 

SSL(Secure Sockets Layer)

보안 계층에 사용하는 프로토콜, 보안된 HTTP 통신을 함
SSL 암호화 통신은 브라우저와 서버가 보안이 향상된 통신을 하는 것으로 아래 단계로 이뤄진다.

1. 핸드셰이크 Handshake (https://blog.naver.com/PostView.nhn?blogId=ucert&logNo=222083739966)
2. 전송
3. 종료

단계로 이뤄집니다. 보통 핸드 셰이크 에러가 발생하는 경우가 있습니다

STEP 1. 클라이언트 → 서버에게 메시지 전송(암호화 방식 전송)
STEP 2. 서버 → 클라이언트에게 메시지 전송(암호화 방식 및 인증서 전달, 공개키 포함)
STEP 3. 클라이언트에서 키를 생성한 후 → 서버에게 전달 이때 서버에서 준 공개키로 암호화
STEP 4. 클라이언트 ↔ 서버 종료 메시지 전달

1. 브라우저(=클라이언트)가 서버로 최초 연결 시도 (암호화 방식 전송)
2. 서버는 공개키(인증서)를 브라우저에게 넘겨줌 (암호화 방식 및 공개키 포함)
3. 브라우저는 인증서 유효성을 검사하여 세션 키 발급 및 보관 후 추가로 공개키로 세션키 암호화하여 서버로 전송
4. 서버는 개인키로 암호화된 세션 키를 복호화 하여 세션키를 얻음
6. 브라우저와 서버는 동일한 세션키를 공유했으므로 데이터 전달 시 세션 키로 암/복호화 진행

TLS ( Transport Layer Security)  : SSL의 더 향상된 버전으로, tls 인증서를 발급받을 수 있다.

 

HTTP와 HTTPS 차이 ( Hyper Text Transfer Protocol (Secure))

웹 브라우저와 웹 서버가 ISO Latin1 영문자를 사용하여 서로 '통신'할 수 있도록 하는 프로토콜. HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고받을 수 있다. 

* HTTPS 발급 과정

인증된 기관(Certificate Authority)에 공개키를 전송하여 인증서를 발급

• Comodo(Sectigo) - https://www.comodo.com/ (+ PositiveSSL, EssentialSSL, InstantSSL ...)
• Thawte by DigiCert - https://www.thawte.com/
• GeoTrust by DigiCert - https://www.geotrust.com/ (+ RapidSSL)
• Verisign - https://www.verisign.com/ 
• GoDaddy - https://godaddy.com/
• GlobalSign - https://www.globalsign.com/ (+ AlphaSSL)
• DigiCert - https://www.digicert.com/

---

FCM 

구글에서 제공하는 서버와 클라이언트 APP 간에 PUSH 메시지를 보낼 수 있는 서비스이다. 과거에는 GCM이었으나 새로운 버전으로 Firebase Cloud Messaging으로 변경되며, 무료로 메시지를 안정적으로 전송할 수 있는 크로스 플랫폼이다.

개선된 점은
1. 모바일 웹까지 확장되어 지원되었다.
2. 클라이언트 app 단에서 구현하던 등록 & 구독 로직이 FCM 라이브러리에 포함되어 간결화되었다.
3. PUSH 전송을 위한 서버 구현 역시 간결해졌다. 과거에는 특정 패키지를 import를 해서 구현하였지만, 지금은 직접 소켓 통신을 통해 구글 서버에 요청할 수 있다. 

 

SEO

SEO는 Search Engine Optimization의 약어로 검색 엔진 최적화라는 뜻이다. 웹사이트가 검색 결과에 더 잘 보이도록 최적화하는 과정을 말한다.

최적화하는 3가지 방법

1. 기술적
콘텐츠 마크업을 작성할 때 시맨틱 HTML을 사용.  색인하길 원했던 콘텐츠만 크롤러가 긁어갈 것입니다.

2. 콘텐츠 작성
방문자층에 맞는 언어로 콘텐츠를 작성. 이미지와 더불어 텍스트를 사용해, 크롤러가 주제를 이해할 수 있도록 도우세요.

3. 인기도
다른 유명한 사이트에서 여러분의 사이트로 링크를 했다면 더 많은 트래픽을 받아 올릴 수 있습니다. 

 

---

마지막으로 네트워크 기초 개념을 알기 위해

나의 집 PC에서 naver.com에 접근 과정

1. 웹 페이지에 naver.com 입력
2. 사용자가 입력한 naver.com을 DNS 서버에서 검색함
3. DNS 서버에서는 도메인 네임에 해당하는 IP주소를 찾아 사용자가 입력한 URL 정보와 함께 전달
4. IP 주소는 HTTP 프로토콜을 사용하여 웹 페이지 URL 정보로 변환 요청
5. 요청받은 데이터를 HTTP 응답으로 데이터를 전송한다.

너무 간략하게 적었나 싶지만 오늘은 여기까지 하겠습니다. 많은 사이트를 검색하며 찾아보고 쉽게 정리해보려고 노력하였는데, 지나가던 분이 이 글을 보고 도움이 되길 바랍니다.

 

IT회사 면접 기초 이론 공부하기 2단계