감 1도 없는 개발자

감 1도 없는 개발자

여행을 꿈꾸는 개발자

인터뷰 질문 대비

Updated:

인터뷰

1. 19년도에는 한게 없는가?

  • 19년도에는 IDC 이전으로 인해서 프로젝트가 없었다.
  • 16년도 초에도 IDC 이전.

2. Back Office 담당이란?

  • 상품 등록, 주문관리, 제휴사, 회원 관리등 고객센터와 상품MD 분들이 이용하는 Back office를 개발 및 운영
  • 그 외 주문 라이브러리, 쿠폰 생성 데몬, 배치

2.1 데몬 vs 배치?

  • 배치
    • 일반 프로세스의 일종으로 일련의 작업을 지정한 특정 시간에 실행한다.
    • 지정한 시간 이후에는 자원을 거의 소비하지 않는 것이 특징
    • cron(스케쥴)으로 보통 관리 및 실행
    • 특정시간에 돌아가는 프로세스
  • 데몬
    • 특정 서비스를 위해 백그라운데 상태에서 계속 실행되는 서버 프로세스
    • 자원을 계속해서 잡고 있기 때문에 많은 데몬이 실행되면 자원 소비가 크다.
    • 윈도우에서는 서비스라 불림
    • 리스너.
2.1.1 프로그램 vs 프로세스 vs 쓰레드
  • 프로그램 : 일련의 명령 집합으로 하드 디스크에 저장된 파일 중 실행가능한 파일
  • 프로세스 : 실행 중인 일련의 명령 집합으로 메모리에 로딩된 프로그램. 즉 실행된 프로그램
    • code, date, stack heap 구조로 되어 있는 독립된 메모리 영역
  • 쓰레드 : 프로세스 내에서 실행되는 흐름들의 단위
    • 스레드는 프로세스 내에서 stack만 따로 할당받고 나머진 공유
    • 자바 쓰레드도 큰 차이는 없고 JVM이 운영체제 역할
  • 자바로 따지면 .jar를 실행하는 것이 프로세스고 .jar 안에 메소드들이 실행되는 것이 thread

3. 업무 프로세스 간편화 및 자동화가 프로젝트인가?

  • 개인 KPI 프로젝트 명으로 업무 프로세스를 간편하게 하거나 자동화 할 수 있는 것이 목표.

3.1 제휴사 외부 상품 등록 페이지 개발은 뭐?

  • 한 두개 제휴사 상품을 관리하기 위해서 등록 페이지가 없었다.
  • 상품 등록 시 상품MD가 연락이 오면 개발자가 직접 등록해주는 프로세스였다.
  • 그러나 상품이 점차 늘어나자 관리 필요성을 느낌
  • 그래서 상품MD가 직접 상품을 관리하기 위해 페이지 개발

3.2 상품 대략 엑셀 등록 개발

  • 상품을 한 개씩만 등록 할 수 있게 페이지가 개발
  • 그러나 대량 상품을 등록 할 경우 같은 작업을 여러 번 작업하게 되어 작업 능률이 떨어짐
  • 그래서 예를 들어 쉽게 엑셀로 100개를 작성한 후 업로드하면 자동으로 상품이 등록되도록 개발
3.2.1 엑셀 파싱은?
  • backoffice는 xplatform으로 개발되었다.
  • 그 안에 엑셀 관련 라이브러리들이 제공되었다.
3.2.2 xplatform?
  • 투비소프트에서 제공하는 UI/UX 개발 툴

3.3 배송지 입력 CS가 무엇인가?

  • 배송 상품의 경우 주소지를 입력하는데 신규 주소로 DB에 없어서 발생하는 CS
  • 그래서 고객센터에서 주소지 입력을 해달라고 많이 옴. 고객응대 시간이 길어짐
  • 고객센터에서 직접 주소를 입력할 수 있도록 Back office에 페이지 개설
  • 신규 주소지 정확성을 위해 행정안전부에서 제공하는 주소 API를 연동
3.2.1 Restfull API란?

  • REST (REpresentational State Transfer)

    • Resource Oriented Architecture

    • 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식
    • 자원(리소스)을 정의하고 자원에 대한 주소(URI)를 지정하는 방법론

  • Restfull

    • REST의 기본 형식을 따른 시스템

  • API (Application Programming Interface)

    • 응용 프로그램 프로그래밍 인터페이스

    • 응용 프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스

  • Restfull API

    • HTTP URI 를 통해 자원을 명시하고 HTTP Method를 통해 해당 자원을 처리하도록 적용

  • 구성요소

    • 자원 , URI
    • 행위, 메소드 : GET, POST, PUT, DELETE,
      • HEAD : 문서 정보 요청. body 없이 http 헤더만 보냄
      • OPTION : 웹 서버측 제공 메서드에 대한 질의
      • TRACE : 요청 리소스가 수신되는 경로를 보여줌
      • CONNECT : 프록시 같은 중간 서버 경유. SSL(HTTPS)를 사용하는 웹사이트에 접속하는 사용
    • 표현 : JSON, XML 등

  • 특징

    • 클라이언트/ 서버 구조
    • 무상태(stateless) : 웹 서버가 사용자의 작업을 기억하지 않음.
      • 캐슁이 용이 : 클라이언트는 응답을 캐싱할 수 있어야 한다.
      • 로드 밸런싱이 용이
      • 스캐일 아웃이 용이
      • 단점은 요청시마다 상태 정보를 전달해야하기 때문에 그 만큼 네트워크 리소스를 소모해야 하고 서버쪽에서는 이 정보를 사전 처리하기 위한 작업이 필요하다는 것
    • 캐쉬 처리 가능 : 웹 표준 HTTP 프로토콜을 사용하므로 웹 인프라 활용 가능
    • 계층화 : API 서버는 순수 비즈니스 로직을 수행하고 그 앞단에 사용자 인증, 암호화, 로드밸런싱 등을 하는 계층을 추가하여 구조상의 유연성을 줄 수 있다.
    • 인터페이스 일관성
    • 자체 표현 구조 : 동사 + 명사로 이루어져 있음. API 메시지만 봐도 이해 가능

  • 현실

    • 사실상 REST 규칙을 다 따르지 않음 그러나 REST API라고 부름
    • 제약조건(규칙) 중 uniform interface (self-descriptive, hateoas)를 만족하지 않음
    • uniform interface : 자원은 유일하게 식별가능해야하고, HTTP Method로 표현을 담아야 하고, 메세지는 스스로를 설명(self-descriptive)해야하고, 하이퍼링크를 통해서 애플리케이션의 상태가 전이(HATEOAS)되어야 한다.
    • 이런 이유는 많은 API들이 JSON 같은 포맷들을 사용하기 때문
    • JSON으로 위의 제약조건을 지키기 어려움
    • self-descriptive는 custom media type이나 profile link relation 등으로 만족시킬 수 있다.
    • HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족시킬 수 있다.

3.2.2 scale in, out, up

  • scale up
    • 서버의 자체 성능을 증가 시키는 것
    • 즉, 기존의 서버에서 고성능 서버로 변경
    • 수직 스케일
    • 마이그레이션 비용 발생
  • scale out
    • 서버 대수를 늘리는 것
    • 수평 스케일
    • 다소 유연함
    • 병렬적 설계와 구현이 어려움
    • 대역폭, 동기화 문제
    • 코어가 늘어남에 따라 성능이 증가하지 않고, 대역폭이 증가해 지연이 발생
    • scale in은 반대
  • 결론
    • 웹사이트 접속자 증가로 트래픽이 발생할 경우 scale-out
    • 데이터베이스의 빈번한 갱신인 경우 scale-up

3.2.3 HTTP, TCP, 소켓

  • TCP는 전송 계층에서 동작
  • HTTP는 어플리케이션 계층에서 동작
  • 즉, HTTP는 TCP 위에서 동작
  • HTTP는 비동기 통신을 기본으로 하기에 stateless
  • HTTP는 클라이언트 요청이 있을 때만 서버가 응답하여 해당 정보 전달하고 연결을 종료
  • 소켓은 http와 반대. 실시간 양방향 통신
  • HTTP은 연결지향 방식 프로토콜인 TCP기반임에도 불구하고 대표적인 비연결 지향 프로토콜임
  • 쿠키, 세션은 http의 단점을 해결하기 위해 만듬

3.2.4 쿠키 vs 세션 (feat. 캐쉬)

  • 쿠키
    • 클라이언트가 서버에 request 보냈을 때 서버가 쿠키를 생성
    • 쿠키는 서버가 클라이언트에 respose할때 같이 전송
    • 서버가 보낸 쿠키를 클라이언트는 저장하고 있다가 다시 request할 때 함께 전송
    • 서버는 받은 쿠키에 대해서 업데이트 해야한다면 업데이트 후 다시 재전송
  • 세션
    • 클라이언트가 서버에 요청하면 서버는 요청에 세션 ID가 있는지 확인
    • 세션ID가 없으면 세션 ID 쿠키를 생성하고 response할 때 전송
    • 쿠키와 같이 세션ID를 저장하고 있다고 요청시 보냄
  • 캐쉬
    • 캐시는 이미지나, css, js파일등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것
    • 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있다.
    • 이런 경우 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 header에 캐시 만료기간을 명시하면 됨

  • 쿠키 세션 차이점

    • 쿠키는 클라이언트, 세션은 서버에 저장(세션ID는 클라이언트)
    • 쿠키는 브라우저가 꺼져도 만료기간안에 저장되어 있다. (라이프사이클)
    • 세션은 만료기간이 남아있어도 브라우저가 꺼지면 사라짐. (라이프사이클)
    • 세션이 보안에 더 좋음. 하지만 서버에서 처리하므로 접속자가 많을 경우 부하가 걸림
    • 사실 가장 중요한 차이점은 라이프사이클이다.
    • 세션은 사용자 수 만큼 서버 메모리를 차지하는데 이런 문제를 보완하기 위해 토큰 기반 인증방식 사용 (ex : JWT)

  • JWT를 최근 많이 사용

    • 매 http 요청마다 본인이 누구인지를 인증해야 함. 이때 요청의 어딘가에 포함시켜야 한다.

    • 사용자 인증을 위해서 쿠키헤더, request body, 쿼리 파라미터도 사용할 수있다.
    • 그러나 인증이라는 맥락으로 Authorizaton 헤더를 더 많이 사용
    • Authorizaton 헤더에 JWT, OAuth등이 사용
    • 여기엔 대부분 비대칭 암호화 방식이 사용

3.2.5 JWT

  • 클라이언트와 서버, 서비스와 서비스 사이 통신 시 권한 인가(Authorization)를 위해 사용하는 토큰

  • 구조

    • HEADER : JWT를 어떻게 검증(Verify)하는가에 대한 내용
    • PAYLOAD : 클라이언트와 서버 간 주고 받기로 한 값
    • SIGNATURE : 점(.)을 구분자로 해서 헤더와 페이로드를 합친 문자열을 서명한 값
    • 위의 세게를 합치면 JWT가 완성

  • 비대칭 암호화 방식을 사용

  • 단점

    1. 이미 발급된 JWT에 대해서는 돌이킬 수 없다. 세션/쿠키의 경우 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지우면 된다.
    • 그러나 JWT는 한 번 발급되면 유효기간이 완료될 때까지는 계속 사용이 가능
    • 이를 위해 유효기간을 짧게 하고 새로운 토큰을 발급해야 함
    1. payload 정보가 제한적.
    2. JWT 길이가 짧음

4. 의사소통에 어려움이 어떤 것이 있을까?

  • API 개발 문서가 영어로 되어 있었다.
  • 본사에 직접 질문을 해야했기 때문에 시간차이로 인해서 의사소통이 원활하지 못했다.
  • 그래서 우리가 해석한 부분대로 일단 개발을 진행해놓고 차후 다르면 수정하는 방향으로 진행

5. 망취소 데몬 개발이라는게 정확히 어떤 건지?

  • 인컴 서버가 미국에 있어서 응답 시간이 지는 경우가 있었다.
  • 이때 인컴의 응답지연 가능 시간이 30초였는데 우리 회사 정책은 3초였다.
  • 우리 정책을 바꿀 수는 없어서 3초안에 이뤄지지 않는 경우 실패처리 후 따로 데몬을 통해 응답이 늦은 주문에 대해서 취소처리 함.

6. 11번가 기프티콘 주문 라이브러리 프로세스 변경이란?

  • 기프티콘 모든 채널에서는 주문 라이브러리를 공통으로 사용
  • 결제 모듈이 안에 탑재
  • 그러나 11번가의 경우 결제 주체가 우리가 아닌 11번가에서 진행
  • 그래서 오버로딩을 통해 결제 모듈을 제거하여 따로 진행
    • 여기서 후회하는 점은 상속구조 리팩토리을 통해 만들었으면 더 좋았을텐데 그 당시는 시간, 실력, 경험이 부족하다는 이유로 진행을 못한 핑계가 아쉽다.

7. 리팩토링과 클린코드는 어떻게 학습했나?

  • 마틴 파울러 리팩토링과 로버트 마틴의 클린 코드 책으로 학습했다.
    • 실제 연습을 위해서 코드 워즈나 프로그래머스 문제를 풀고 리팩토링을 해왔다.

8. 리팩토링과 클린코드를 왜 했는가?

  • 전 회사에서 맡았던 프로젝트들의 경우 거의 10년 가까이된 코드들이었다.
  • 코드 작성에 마땅한 기준도 없고 여러 사람을 거치다보니 코드가 길어지고 변수명부터 일치하지 않는 것이 많았다.
  • 내가 했으면 됐으나 잘못되면 책임지라는 식의 분위기와 경험 미숙, 개인적인 핑계로 안하게 됌.
  • 내가 작성한 부분만 나름 하려고 노력함.
  • 그러나 이번 책을 읽으면서 무조건 해야한다고 느낌

9. 짝 프로그래밍 이면, 짝 프로그래밍을 하면 한개의 일을 2명이 하게되서 생산성이 하락된다라는 얘기도 항간에 있는데 이것에 대해서 어떻게 생각하시고 실제 경험은 어떠했나요?

  • 짝 프로그래밍의 장점은 두명이 1개 task를 처리하는것이고, 개발에만 집중했을 때 볼 수 없는 것들을 조금 멀리 떨어져서 봄으로써 실수없이 코드를 객관적으로 판단하고 볼 수 있음
  • 그리고 혼자 개발하는 것보다 훨씬 긴장된 상태로 진행하기 때문에 집중도 더 잘되고, 생산성이 낮아질 수 있을지 언정 혼자 개발할 때 보다 안정성 측면에서는 더 좋은 장점을 취할 수 있음

10. 코드리뷰는 어떻게 했나?

  • 이전 회사에서는 코드 리뷰가 없었다.
  • 그래서 내 코드가 좋게 짠건지 판단하기 힘들었다.
  • 현재 같이 학습하는 친구 2명과 함께 매주 정해놓은 문제에 대해서 해결 후 주말에 모여서 리뷰를 진행하고 있다.

10.1 확인

  • 기능 정상여부
  • 가독성, 유지보수 편의성
  • 자바 컨벤션
  • 테스트 코드에 대해서도

10.2 주의점

  • 코드 맥락을 이해할 수있는 설명

  • 하나의 이슈에 하나의 리뷰

  • 코드리뷰는 한번에 할 때 400라인 이하로 하는게 효율이 좋았다 라는 논문 발표가 실제 있었고, 구글에서 쓴 코드리뷰 문서가 있는데 거기에도 400라인 으로 나와 있음

11. GIT이 뭔가요?

  • 형상관리 툴. 분산 버전 관리 시스템. 스냅샷으로 관리
  • 전 회사에서는 SVN을 사용하다가 git으로 변경 (도구는 비트버킷을 사용)
  • git에 대해서 잘 몰라서 다들 git을 사용하지만 svn처럼 중앙 버전 관리 시스템처럼 사용
  • 프로젝트마다 보통 1명이고 많아야 2, 3명이라서 굳이 병렬 사용 필요성을 못 느껴 다들 그냥 사용.
  • 그러다 이번 기회에 공부를 하면서 제대로 공부함

11.1 흐름

  • feature > develop > release > hotfix > master

  • feature : 새로운 기능을 추가하는 브런치
  • release : 이번 출시 버전를 위한 브런치
  • hotfix : 현재 출시한 버전에서 발생한 버그 수정
  • develop : 다음 버전을 개발하는 브랜치
  • master : 출시된 버전 브랜치

11.2 rebase vs merge 차이

  • merge는 branch를 통합하는 것
  • rebase는 branch의 base를 옮긴다는 개념
  • 여러 개발자들이 같은 브랜치를 공유할 때는 pull & rebase가 히스토리를 깔끔하게 유지
  • 완료된 기능 브랜치를 다시 합칠 때는 merge
  • 기능 브랜치에 부모 브랜치의 변경 내용을 반영하고 싶을 때 merge를 함
    • 그러나 기능 브랜치를 다른 곳에 푸시 한적 없으면 rebase

11.3 fork와 clone 차이

  • fork
    • 다른 사람의 github repo(original)에 기여하고 싶을 때 나의 repo로 복제하는 것
    • original에 변경이 생기면 fetch나 rebase의 과정이 필요하다.
    • push를 하면 fork된 repo에 되고 pull request로 original에 요청
    • original 권한자가 승인하면 pull request가 반영
  • clone
    • 특정 repo(original)를 local에 복사하여 새로운 저장소를 만든다.
    • clone한 original remote 저장소 origin을 가지고 있다.
    • 권한이 없으면 push 못함

11.4 fetch와 pull

  • 결론적으로는 pull = fetch + merge다
  • pull은 original repo에서 내용을 가져와 자동으로 병합 작업을 실행
  • 그럼 fetch는 왜 씀?
    • 로컬 데이터와 병합은 하고 싶지 않은 경우
    • 바뀐 내용 확인

11.5 reset과 revert 차이

  • 둘다 특정 커밋으로 돌아갈 수 있다.
  • reset은 이전 커밋 히스토리가 삭제됨
  • revert는 이전 커밋 히스토리가 남아 있음

11.6 reset의 hard, soft, mixed

  • hard
    • 파일 내용까지(working directory) 다 되돌림
  • soft
    • 파일 내용 유지. staging area까지 적용. 커밋 이력은 삭제
  • mixed (옵션 안 적은 경우)
    • 파일 내용 유지. staging area에는 적용안됨. 커밋 이력만 삭제

12. WEB 서버와 WAS차이

  • web 서버
    • 하드웨어 개념 : web 서버가 설치된 컴퓨터
    • 스프트웨어 개념 : 웹 브라우저 클라이언트로부터 요청받은 컨텐츠를 제공하는 프로그램
  • web 서버 기능
    • http 프로토콜을 기반으로 하여 웹 브라우저의 요청을 서비스하는 기능을 담당한다.
    • 정적인 컨텐츠(html, css) 제공
    • 동적인 컨텐츠는 was에게 요청 전달. was가 보낸 응답을 클라이언트에 전달
  • was
    • 동적인 컨텐츠(ex: DB 조회) 를 제공
    • 웹 컨테이너 or 서블릿 컨테이너라고 불림
    • 컨테이너란 jsp, servlet을 실행시킬 수 있는 소프트웨어를말함
    • 서블릿이란 웹기반의 요청에 대한 동적인 처리가 가능한 서버 사이드에서 돌아가는 자바 프로그램
    • jsp란 자바 언어를 기반으로 하는 서버 사이드 스크립트 언어. html 안에 있는 자바 코드
    • 즉, jsp, servlet 구동환경을 제공하는 것
  • was 기능
    • web 서버 + web 컨테이너
    • web 기능들을 구조적으로 분리하여 처리
    • 분산 트랜잭션, 보안, 메시징, 쓰레드 처리등의 기능을 처리하는 분산환경에서 사용

13. DML, DDL, DCL

  • DML : DELETE, UPDATE, INSERT, SELECT
  • DDL : ALTER, DROP, CREATE
  • DCL : GRANT, REVOKE
  • DQL : SELECT
  • TCL : COMMIT, ROLLBACK

15. 동기 vs 비동기

  • 동기 : call하고 응답이 올 때까지 기다렸다가 다음 로직을 실행한다.
    • 장점 : 안전성이 보장된다. 순서가 보장된다.
    • 단점 : 느리다.
  • 비동기(병행, 병렬이라고 봐야할듯) : call하고 응답이 오지 않아도 다음 로직을 실행한다.
    • 장점 : 빠르다
    • 단점 : 처리 하기가 까다롭다. 순서가 보장이 되지 않는다.
    • 비동기를 쓰는 이유는 빠르기 때문에 쓴다.
  • 쓰레드 동기화를 한다는 이야기는 쓰레드간 race condition을 통제한다는 의미

17. GET, POST 비교

  • GET 방식
    • 요청하는 데이터가 Header 부분의 url 에 담겨서 전송된다.
    • url 이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적

  • POST 방식

    • Body 부분에 데이터가 담겨서 전송된다.

    • 데이터 크기가 GET 방식보다 크고 보안면에서 낫다. (물론 암호화를 하지 않으면 차이 없음)

  • GET 방식의 요청은 브라우저에서 Caching 할 수 있다.

  • 때문에 POST 방식으로 요청해야할 내용을 데이터 크기가 작고 보안 문제가 상관없다는 이유로 GET 방식으로 요청한다면 기존에 caching 되었던 데이터가 응답될 가능성이 있다.

18. TCP, UDP

  • UDP
    • 비연결형 프로토콜
    • 흐름제어, 오류제어, 손상된 것들에 대해서 재전송 하지 않음
    • 속도가 빠름.
    • 실시간 서비스에 사용
  • TCP
    • 신뢰성, 순차적인 전달(연결형)
    • 고의적 지연이 존재 (패킷 수신 순서가 중요하므로)
    • 전송단위가 바이트
    • 3 way 핸드쉐이킹 과정으로 연결 설정
    • 4 way 핸드쉐이킹 과정으로 연결 해제

18.1 TCP의 연결 설정 과정(3단계)과 연결 종료 과정(4단계)이 단계가 차이나는 이유

  • Client가 데이터 전송을 마쳤다고 하더라도 Server는 아직 보낼 데이터가 남아있을 수 있기 때문에 일단 FIN에 대한 ACK만 보내고, 데이터를 모두 전송한 후에 자신도 FIN 메시지를 보내기 때문이다.

18.2 만약 Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까?

  • 이러한 현상에 대비하여 Client는 Server로부터 FIN 플래그를 수신하더라도 일정시간(Default: 240sec)동안 세션을 남겨 놓고 잉여 패킷을 기다리는 과정을 거친다. (TIME_WAIT 과정)

19. round robin 방식

  • 동일한 크기의 시간을 할당 받아서 실행
  • 할당 시간이 끝나면 다른 프로세스 실행
  • 대기 시간이 프로세스의 CPU 사용시간에 비례

19.1 SJF(shortest job first)

  • 가장 짧은 프로세스를 제일 먼저 실행

20. 비대칭 암호화

  • 대칭키 방식
    • 동일한(대칭키) 키도 암호화 복호화 모두 가능
    • 단점은 대칭키를 알면 누구나 암복호화가 가능
  • 공개키 방식 (비대칭키 방식)
    • 대칭키의 단점을 극복하기 위해 개발
    • 누구나 공개된 공개키
    • 자신만 갖고 있는 개인키(다른 말로 비공개키 or 비밀키)를 가지고 있음
    • 공개키로 암호화하면 데이터 보안에 중점
    • 개인키로 암호화하면 인증 과정에 중심
  • 공개키로 암호화하는 경우
    • A가 B의 공개키로 암호화
    • B는 A가 공개키로 암호화한것을 개인키로 복호화
  • 개인키로 암호화하는 경우
    • A가 자신의 개인키로 암호화하고 공개키와 함께 B에게 전달
    • B는 전달받은 암호문을 같이 받은 공개키로 복호화
    • 그럼 누구나 데이터를 볼 수 있는거 아니냐?
    • 이거는 그래서 데이터 보안이 문제가 아닌 보낸 사람이 A라는 것이 맞다고 확인시켜주기 위해서 사용하는 것.
    • 따라서 이것은 JWT나, 공인인증체계에서 사용되는 전자서명, 블록체인 같은 곳에서 사용되는 것

21. OTA

  • 부킹홀딩스 : 부킹닷컴, 아고다, 카약
  • 익스피디아 : 익스피디아, 호텔스닷컴, 트리바고
  • 씨트립 : 트립닷컴, 스카이스캐너
  • 에어비앤비

You may also enjoy