16. 복합 인덱스란 무엇인지 원리를 설명해주실 수 있을까요?

복합 인덱스란 두 개 이상의 컬럼을 합쳐서 인덱스를 만드는 것을 말합니다. 주로 단일 컬럼으로는 나쁜 분포도를 가지지만 여러 개의 컬럼을 합친다면 좋은 분포도를 가지고, Where절에서 AND 조건에 많이 사용되는 컬럼들을 복합 인덱스로 구성합니다. index Table에서 where에 포함된 값을 찾아옵니다. 해당 값의 table_id[PK]을 가져옵니다. 가져온 table_id [PK] 값으로 원본 테이블에서 값을 조회해옵니다.

17. 트랜잭션이란 무엇이고 원자성, 일관성, 고립성, 지속성이란 무엇인지 설명해주실 수 있을까요?

트랜잭션(Transaction 이하 트랜잭션)이란, 데이터베이스의 상태를 변화시키기 해서 수행하는 작업의 단위를 뜻한다. 데이터베이스의 상태를 변화시킨다는 것은 간단하게 말해서 질의어(SQL : SELECT, INSERT, DELETE, UPDATE)를 이용하여 데이터베이스를 접근 하는 것을 의미한다. 작업의 단위는 질의어 한문장이 아니고, 많은 질의어 명령문들을 사람이 정하는 기준에 따라 정하는 것을 의미한다.

• 원자성은 트랜잭션이 데이터베이스에 모두 반영되던가, 아니면 전혀 반영되지 않아야 한다는 것이다.
• 일관성은 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다는 것이다.
• 고립성은 둘 이상의 트랜잭션이 동시에 실행되고 있을 경우 어떤 하나의 트랜잭션이라도, 다른 트랜잭션의 연산에 끼어들 수 없다는 점을 가리킨다.
• 지속성은 트랜잭션이 성공적으로 완료됬을 경우, 결과는 영구적으로 반영되어야 한다는 점이다.

18. 정규화란 무엇이고 대표적인 장점과 단점은 무엇이 있을까요?

정규화의 기본 목표는 테이블 간에 중복된 데이터를 허용하지 않는다는 것입니다. 중복된 데이터를 허용하지 않음으로서 무결성을 유지할 수 있으며, DB의 저장 용량 역시 줄일 수 있습니다. 종속성 삭제로 데이터의 일관성과 무결성을 보장합니다. 릴레이션에서 발생 가능한 이상현상을 제거합니다. 정규화의 단점은 빈번한 join 연산 증가로 인한 시스템 실행과다 및 비효율적 검색 시간 이 있으며 과다한 검색 조건문 발생으로 부자연스러운 데이터베이스 semantics 초래가 우려됩니다.

19. HTTP에 비해 HTTPS가 더 안전한 원리를 설명해주실 수 있을까요?

HTTP란 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜입니다. 이 HTTP에는 3가지 문제가 있습니다. 첫 번째 HTTP 는 평문 통신이기 때문에 도청이 가능하다. 두 번째 통신 상대를 확인하지 않기 때문에 위장이 가능하다. 세 번째 완전성을 증명할 수 없기 때문에 변조가 가능하다. 이 3가지 문제를 해결하기 위해 HTTPS는 SSL(Secure Socket Layer) or TLS(Transport Layer Security)와 같은 프로토콜을 사용하여 공개키/개인키 기반으로 데이터를 암호화하고 있습니다. 데이터는 암호화되어 전송되기 때문에 임의의 사용자가 데이터를 조회하여도 원본의 데이터를 보는 것은 불가능하고, 완정성 또한 증명할 수 있습니다.

20. TCP 3 way handshake란 무엇인지 설명해주실 수 있을까요?

TCP 3 way handshake란 연결하고자 하는 두 장치 간의 논리적 접속을 성립하기 위해 사용하는 연결 확인 방식으로, 3번의 확인 과정을 거친다고 해서 3 way handshake라고 부릅니다. 동작 과정은

1. SYN (synchronize sequence numbers) 연결 확인을 위해 보내는 무작위의 숫자값으로 클라이언트에서 서버로 보내고

2. ACK (acknowledgements) Client 혹은 Server로부터 받은 SYN에 1을 더해 SYN을 잘 받았다는 ACK와 SYN을 같이 보냅니다.

3. ACK (acknowledgements)를 보내 연결을 확인합니다.

21. TCP 와 UDP 를 비교하여 설명해주실 수 있을까요?

TCP는 연속성보다 신뢰성 있는 전송이 중요할 때에 사용되는 프로토콜이며,UDP는 TCP보다 빠르고 네트워크 부하가 적다는 장점이 있지만 신뢰성 있는 데이터 전송을 보장하지는 않습니다.그렇기 때문에 신뢰성보다는 연속성이 중요한 실시간 스트리밍과 같은 서비스에 자주 사용됩니다.

TCP는 Transmission Control Protocol의 약자이고, UDP는 User Datagram Protocol의 약자입니다. 두 프로토콜은 모두 패킷을 한 컴퓨터에서 다른 컴퓨터로 전달해주는 IP 프로토콜을 기반으로 구현되어 있고, 데이터 오류 검사를 위한 체크섬이 존재하지만, 서로 다른 특징을 가지고 있습니다. 신뢰성이 요구되는 애플리케이션에서는 TCP를 사용하고 간단한 데이터를 빠른 속도로 전송하고자 하는 애플리케이션에서는 UDP를 사용합니다. 또한 연결이 성공해야만 통신이 가능한 TCP와는 달리 연결 없이 UDP는 연결 없이 통신이 가능합니다.

22. Base64 인코딩이란 무엇인가요?

Base64 인코딩은 바이너리 데이터를 공통 ASCII 영역의 문자(TEXT)로만 이루어지는 문자열로 바꾸는 Encoding 방식입니다. 바이너리 데이터를 6Bit씩 자른 뒤 6Bit에 해당하는 문자를 Base64 색인표에서 찾아서 치환하는 방식으로 인코딩 합니다.

프로세스는 운영체제로부터 자원을 할당받은 작업의 단위입니다. 스레드는 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위입니다. 둘이 가장 큰 차이는 프로세스는 메모리에 올라갈 때 운영체제로부터 시스템 자원을 할당받는데 운영체제는 프로세스마다 각각 독립된 메모리 영역을, Code/Data/Stack/Heap의 형식으로 할당해준다. 그러나 스레드는 프로세스가 할당받은 메모리 영역 내에서 Stack 형식으로 할당된 메모리 영역은 따로 할당받고, 나머지 Code/Data/Heap 형식으로 할당된 메모리 영역을 공유한다. 따라서 각각의 스레드는 별도의 스택을 가지고 있지만 힙 메로리는 서로 읽고 쓸 수 있게 됩니다. 만약 한 프로세스가 실행하다가 오류가 발생하면 프로세스가 강제종료된다면 다른 프로세스에는 영향을 주지 않지만 스레드는 오류로 종료가 된다면 메모리 영역을 공유하고있는 스레드 모두 강제로 종료된다는 중요한 차이점이 존재합니다.

24. 동기와 비동기를 비교하여 설명해주실 수 있을까요?

동기는 데이터의 요청과 결과가 한 자리에서 동시에 일어나는것을 말합니다. 사용자가 데이터를 서버에게 요청한다면 그 서버가 데이터 요청에 따른 응답을 사용자에게 다시 리턴해주기 전까지 사용자는 다른 활동을 할 수 없으며 기다려야만합니다. 비동기는 동시에 일어나지 않는다는 의미입니다. 서버에게 데이터를 요청한 후 요청에 따른 응답을 계속 기다리지 않아도되며 다른 외부 활동을 수행하여도되고 서버에게 다른 요청사항을 보내도 상관없습니다.

25. 동시성과 병렬성을 비교하여 설명해주실 수 있을까요?

동시성은 적어도 두 개의 스레드가 진행 중일 때 존재하는 조건이며, 가상 병렬 처리의 한 형태로 시간 분할(time-slicing)을 포함합니다. 우리가 흔히 ‘동시’라고 이야기 하지만 컴퓨터(코어)는 한번에 하나의 명령어만 처리할 수 있다. 즉, 두개 이상의 알고리즘이 하나의 코어내에서 스레드간에 빠르게 교차되면서 실행되기 때문에 ‘동시’라고 느끼는 것입니다. 병렬성을 이야기하려면 적어도 2개 이상의 코어가 있어야 합니다. 병렬성도 동시성을 의미하지만 동시성과의 차이는 각 코어내의 스레드가 실제로 동시에 명령어를 실행할 수 있음을 말합니다. 그러므로 두개의 알고리즘이 정확히 같은 시점에 실행될 때 이를 병렬적이라고 말할 수 있습니다.

26. JVM 이란 무엇이고 왜 필요한지 설명해주실 수 있을까요?

JVM이란 Java Virtual Machine 의 줄임말로, Java Byte Code 를 운영체제에 맞게 해석해주는 역할을 한다. 즉, 작성한 자바 프로그램의 실행 환경을 제공하는 자바 프로그램의 구동 엔진이다. Java compiler 는 .java 파일을 .class 라는 자바 바이트코드로 변환시켜주는데 Byte Code 는 기계어(Native Code)가 아니므로 OS 에서 바로 실행이 되지 않는다. 이때 JVM은 OS가 Byte Code 를 이해할 수 있도록 해석해주는 역할을 담당한다. JVM은 메모리 관리도 담당한다. 이를 '가비지 컬렉터'라고 하는데, 가비지 컬렉터는 Java7부터 힙 영역의 객체들을 관리하는 역할을 담당한다.

27. Java가 컴파일되는 과정은 어떻게 되는지 설명해주실 수 있을까요?

1. 개발자가 자바 소스코드(.java)를 작성한다.
2. 자바 컴파일러가 자바 소스코드(.java)파일을 읽어 바이트코드(.class)로 컴파일 한다. 바이트코드(.class)파일은 아직 컴퓨터가 읽을 수 없는 JVM(자바 가상 머신)이 읽을 수 있는 코드이다. (java - > class)
3. 컴파일된 바이트코드(.class)를 JVM의 클래스로더(Class Loader)에게 전달한다.
4. 클래스 로더는 동적로딩(Dynamic Loading)을 통해 필요한 클래스들을 로딩 및 링크하여 런타임 데이터 영역 (Runtime Data Area), 즉 JVM의 메모리에 올린다.
5. 실행엔진(Execution Engine)은 JVM 메모리에 올라온 바이트 코드들을 명령어 단위로 하나씩 가져와서 실행한다. 이 때 실행 엔진은 두 가지 방식(인터프리터와 JIT컴파일러)로 변경한다.

28. JVM의 스택과 힙메모리 영역에 대해 아는 만큼 설명해주실 수 있을까요?

Stack의 경우에는 정적으로 할당된 메모리 영역이다. Stack에서는 Primitive 타입 (boolean, char, short, int, long, float, double) 의 데이터가 값이랑 같이할당이 되고, 또 Heap 영역에 생성된 Object 타입의 데이터의 참조 값이 할당 된다. 그리고 Stack 의 메모리는 Thread당 하나씩 할당 된다. 만약 새로운 스레드가 생성되면 해당 스레드에 대한 Stack이 새롭게 생성되고, 각 스레드 끼리는 Stack 영역을 접근할 수 가 없다. Heap의 경우에는 동적으로 할당된 메모리 영역이다. 힙 영역에서는 모든 Object 타입의 데이터가 할당이 된다. (참고로 모든 객체는 Object 타입을 상속받는다.) Heap 영역의 Object를 가리키는 참조변수가 Stack에 할당이 된다. 어플리케이션에서의 모든 메모리 중에서 Stack에 쌓이는 애들 빼고는 전부 이 Heap 쌓인다고 보면 된다.

자바의 메모리 구조는 메소드영역, 스택영역, 힙영역으로 구성된다.

• 메소드(Method) 영역 : Static 영역이라고도 하며 전역 변수와 정적 멤버변수(static 변수)가 저장되는 영역이다.
• 스택(Stack) 영역 : 지역변수, 인자값, 리턴값이 저장되는 영역이고 메소드 안에서 사용되는 기본형 변수들이 값과 함께 저장되고 Heap 영역에 생성된 객체들을 참조하는 주소값이 할당된다.
• 힙(Heap) 영역 : 자바 프로그램에서 사용되는 모든 인스턴스 변수(객체)들이 저장되는 영역이며 자바에서는 new를 사용하여 객체를 생성하면 힙 영역에 저장된다. 힙 영역은 메모리 공간이 동적으로 할당되고 해제되며 메모리의 낮은 주소에서부터 높은 주소로 할당이 이루어진다.

29. 클래스와 인스턴스의 차이에 대해 설명해주실 수 있을까요?

클래스는 객체를 만들어 내기 위한 설계도 혹은 틀이라고 할 수 있으며, 연관되어 있는 변수와 메서드의 집합입니다. 인스턴스는 클래스를 바탕으로 구현된 구체적인 실체이며, 하나의 클래스를 통해서 다양한 인스턴스들을 만들 수 있습니다. 다양한 인스턴스가 만들어진다한들, 서로 다른 행동을 할 수 있게되니 재활용성을 더욱 높일 수 있습니다.

30. Spring Security의 구조와 JWT 발급 과정에 대해 설명해주실 수 있을까요?

Spring Security란 Spring 기반의 어플리케이션의 보안(인증과 권한, 인가 등)을 담당하는 스프링 하위 프레임워크 입니다. Spring Security는 '인증'과 '권한'에 대한 부분을 Filter 흐름에 따라 처리 하고 있습니다. Filter는 Dispatcher Servlet으로 가기 전에 적용되므로 가장 먼저 URL 요청을 받지만, Interceptor는 Dispatcher와 Controller 사이에 위치한다는 점에서 적용 시기의 차이가 있습니다. JWT가 발행되면, 발급된 JWT의 구성은 header에는 토큰타입,해시 암호화 알고리즘을 담고 Paylaod는 토큰의 정보를 담 고, Signature에는 시크릿 키를 담습니다. 사용자가 요청에 JWT를 보내면 서버에서 시크릿키 만을 활용해서 JWT 토큰의 유효성을 체크하고, 유효한 토큰이라면 사용자인증을 거칩니다. 이후 토큰의 만료기간을 체크하고, 토큰의 권한을 체크 합니다.

Spring Security의 대표적인 보안 구성으로는 인증(Authentication)과 인가(Authorization)를 들 수 있다. 이 인증과 인가를 위해 Principal을 아이디로, Credential을 비밀번호로 사용하는 Credential 기반의 인증 방식을 사용한다. 이러한 이유로 Spring Security는 대부분의 유저 정보와 인증 인가를 위한 정보를 얻어내기 위한 인터페이스 명세와 그 구현체를 미리 정의해놓고 사용할 수 있도록 정의해 놓았고 우리는 사용하기만 하면 된다. 또한 http 요청 사이에 처리해야 하는 인증처리를 위해 스프링은 필터를 구현하고 있는데, JWT 토큰 방식을 사용하기 위해선 해당 필터 앞단에서 JWT 토큰의 생성과 발급이 위치하도록 해야하고, 반드시 Spring Security의 인증시스템에 등에 JWT로 인증한 사용자의 정보를 포함시켜야 한다. 이 인증 및 인가 사용자 정보는 SecurityContextHolder에 위치한다.

1. 배열, 링크드리스트를 비교하여 설명해주실 수 있을까요?

  배열은 입력된 데이터들이 메모리 공간에서 연속적으로 저장되어 있는 자료구조이며 메모리상에서 연속적으로 저장되어 있는 특징을 갖기 때문에 index를 통한 접근이 용이하다는 장점이 있으나 삽입/삭제가 오래 걸리고 배열 중간의 데이터가 삭제 되면 공간 낭비가 발생할 수 있는 단점이 존재합니다. 

  링크드리스트(연결리스트)는 여러 개의 노드들이 순차적으로 연결된 형태를 갖는 자료구조이며 각 노드는 데이터와 다음 노드를 가리키는 포인터로 이루어져 있는 트리(tree)구조의 근간이 되는 자료구조입니다. 배열과 달리 메모리를 연속적으로 사용하지 않아 삽입/삭제에 용이하다는 장점이 있습니다. 그러나 index로 임의 접근이 불가하며 처음부터 탐색을 해야하는 단점이 있습니다.

  따라서 배열은 빠른 접근이 요구되고, 데이터의 삽입과 삭제가 적을 때 사용하고 링크드리스트는 삽입과 삭제 연산이 잦고, 검색 빈도가 적을 때 사용합니다.

2. CORS란 무엇이고 어떻게 허용할 수 있나요?

한 출처에 있는 자원에서 다른 출처에 있는 자원에 접근하도록 하는 것으로 교차되는 출처 자원들의 공유입니다. 다른 출처의 리소스를 가져오는 상황에서 SOP는 이 접근을 차단합니다. 하지만 CORS 설정을 통하여 Access-Control-Allpw-Origin을 서버의 응답헤더에 작성하게 되면 접근 권한을 얻을 수 있습니다.

3. 시간복잡도와 공간복잡도가 무엇인지 설명해주실 수 있을까요?

시간 복잡도란 특정 크기의 입력을 기준으로 할 때 필요한 연산의 횟수를 나타냅니다. 시간 복잡도에는 빅오 표기법이라는 복잡도를 나타내는 점근 표기법 중 가장 많이 사용되는 표기법을 사용합니다. 공간 복잡도는 프로그램 실행과 완료에 얼마나 많은 공간(메모리)가 필요한지를 나타냅니다. 알고리즘을 실행시키기 위해 필요한 공간, 고정 공간과 가변 공간이 있습니다.

4. 사용자 패스워드를 전송하고 보관하는 방법을 설명해주실 수 있을까요?

유저의 패스워드를 받은 클라이언트는 평문으로 서버로 전송합니다. 평문을 받은 서버는 패스워드를 단방향 해시 함수로 암호화하여 보관합니다. 단방향 해시함수는 수학적 연산에 의해 원본 데이터를 완전히 다른 암호화된 데이터(다이제스트)로 변환하는 것을 말합니다. 원본 데이터로는 다이제스트를 구할 수 있지만 다이제스트로는 원본데이터를 구할 수 없어야 합니다. 이것을 단방향이라 합니다. 단방향 해시함수는 브루트포스 공격으로 쉽게 당할 수 있기 때문에 이를 보완하기 위해 입력된 다이제스트를 N번 반복해서 생성하는 것인 key stretching과 원문 패스워드에 임의의 문자열을 추가하여 해싱하는 것인 salting을 이용해 보안의 강도를 높힐 수 있습니다.

5. 스택, 큐에 대해 설명해주실 수 있을까요?

- 스택은 쌓여있는 접시와 같다. 먼저들어온 자료가 나중에 나간다. FILO(First In Last Out.)
- 스택은 접근성에 제한이 있는 자료구조. 오직 맨 위에 추가(push)할 수 있고, 맨 위에 것만 나갈(pop) 수 있다.
- 큐는 놀이공원에 줄 서있는 사람들과 같다. 먼저 온 사람이 먼저 나간다. FIFO(First In First Out.) 
- 큐는 두가지 동작만 허용된 자료구조. Enqueue(들어옴)과 Dequeue(나감).
- Stack과 Queue의 가장 큰 차이점은 item을 삭제할 때 있다. 아이템을 삭제할 때, Stack은 가장 마지막에 추가되 있던 item을 삭제하고, Queue는 가장 처음으로 들어와 있던 item을 삭제한다.

6. DI와 IoC에 대해 아는 만큼 설명해주실 수 있을까요?

DI(Dependency Injection)란 스프링이 다른 프레임워크와 차별화되어 제공하는 의존 관계 주입 기능으로, 객체를 직접 생성하는 게 아니라 외부에서 생성한 후 주입 시켜주는 방식이다. DI(의존성 주입)를 통해서 모듈 간의 결합도가 낮아지고 유연성이 높아진다. IoC(Inversion of Control)란 "제어의 역전" 이라는 의미로, 말 그대로 메소드나 객체의 호출작업을 개발자가 결정하는 것이 아니라, 외부에서 결정되는 것을 의미한다. IoC는 제어의 역전이라고 말하며, 간단히 말해 "제어의 흐름을 바꾼다"라고 한다. 객체의 의존성을 역전시켜 객체 간의 결합도를 줄이고 유연한 코드를 작성할 수 있게 하여 가독성 및 코드 중복, 유지 보수를 편하게 할 수 있게 한다.

7. Call by reference란 무엇이고 보통 어떻게 쓰이나요?

Call by reference - 참조에 의한 호출로써, 함수가 호출될 때 메모리 공간 안에는 함수를 위한 별도의 임시 공간이 생성된다. 함수 호출 시 인자로 전달되는 변수의 레퍼런스를 전달하여 해당 변수를 가르킨다. 함수 안에서 인자의 값이 변경되면, 함수 호출 시에 있던 변수들도 값이 바뀐다.

Call by Value - 값에 의한 호출로써, 함수가 호출될 때 메모리 공간 안에는 임시의 공간이 생성된다. 함수 호출 시 전달되는 변수의 값을 복사하여 함수의 인자로 전달한다. 복사된 인자는 함수 안에서 지역적으로 사용하는 변수이다. JAVA 는 오직 Call by Value 로만 동작하고, Reference 의 값을 넘기는 것만 가능하다.

8. Override 와 Overload 를 설명해주실 수 있을까요?

- 오버로드(Overload) : 메서드의 이름은 같고 파라메터의 갯수나 타입이 다른 함수를 정의하는 것을 의미한다. (리턴값만을 다르게 갖는 오버로드는 작성 할 수 없다.)
- 오버라이드(Override) : 상위 클래스의 메서드를 재정의 하는 것이다.
메서드의 이름은 물론 파라메터의 갯수나 타입도 동일해야 하며, 주로 상위 클래스의 동작을 상속받은 하위 클래스에서 변경하기 위해 사용된다.
- 오버로딩(Overloading)은 기존에 없던 새로운 메서드를 정의하는 것이고, 오버라이딩(Overriding)은 상속 받은 메서드의 내용만 변경 하는 것이다.

오버로딩(Overload)은 메소드의 이름은 같고 매개변수의 개수나 타입이 다른 함수를 정의하는 것을 의미하며 여러개의 서브프로그램 생성을 가능하게 합니다. 오버라이딩(Overriding)은 상위 클래스의 메소드를 하위 클래스가 재정의 하는 것 의미하며 메소드 이름의 절약과 예상을 가능하게 합니다. 두 기능으로 JAVA에서 다형성을 구현하고, SOLID - OCP, LSP 원칙을 지킬 수 있습니다.

9. MVC 모델이란 무엇인지 설명해주실 수 있을까요?

- MVC 는 Model, View, Controller의 약자 입니다. 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴입니다. 
- 사용자가 controller를 조작하면 controller는 model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 됩니다.
- 이러한 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시작적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있게 됩니다.

10. JPA는 언제 필요하고 언제 필요하지 않은지 설명해주실 수 있을까요?

JPA는 java 진영의 표준 ORM으로 관계형DB와 객체지향 언어인 java 와의 관계에서 쿼리문 작성 없이 편하게 데이터 다룰 수 있게 해주는 도구입니다. 쿼리문을 직접 작성할 필요가 없어 생산성이 향상되고 오류의 여지가 적어지는 장점이 있지만 통계를 내는 등의 복잡한 쿼리의 작성이 필요한 경우 적절하지 않을수 있습니다. 일반적으로 많이 사용하지만 기술의 장단점을 인지하고 장점이 발휘될수 있는 환경에서 적절하게 사용하는게 좋습니다.

JPA란 Java Persistence API의 약어로 Java ORM 기술에 대한 표준 명세로 자바 어플리케이션에서 관계형 RDB를 사용하는 방식을 정의한 인터페이스이다. 데이터베이스가 바뀔 가능성이 있는 경우 JPA를 권장합니다. JPA는 추상화한 데이터 접근 계층을 제공하기 때문에 설정 파일에 사용할 데이터베이스를 등록하기만 하면 얼마든 데이터베이스를 변경할 수 있습니다. 하지만 통계처리나 동적 쿼리 같은 복잡한 쿼리를 사용하거나 관계 맵핑이 어려울 때에는 직접 쿼리문을 작성하는 것이 좋을 수 있다. (JPQL도 JPA이다. 하지만 Querydsl은 JPA가 아니다 -> 의존성을 따로 주입)

11. JPA의 더티 체킹이란 무엇인가요?

12. Annotation이란 무엇이고 구체적으로 어떤 것이 있는지 예시를 들어 설명해주실 수 있을까요?

Annotation은 코드 사이에 주석처럼 쓰이며 특별한 의미, 기능을 수행하도록 하는 기술입니다. Annotation을 활용하면 코드가 깔끔해지고 재사용에 용이합니다. Spring framework에서 제공하는 @ComponentScan는 하위 @Component 또는 직접 등록할 Bean 예를 들면 @Controller, @Service, @Repository 등을 스캐닝하여 Bean 등록합니다. @Autowired 같은 Annotation은 또 달리 등록 된 Bean을 찾아 의존성 주입을 위해 사용 됩니다. 또 다른 예로 Lombok 라이브러리에서 제공하는 Annotaion @Setter, @Getter 등은 코드를 줄여 가독성을 높여주는 역할을 합니다.

13. 인덱스란 무엇이고 일반적인 원리는 어떠한지 설명해주실 수 있을까요?

인덱스란 데이터와 데이터의 위치를 포함한 자료 구조이며, 이로써 DB 테이블의 검색 속도가 향상되어 데이터를 빠르게 조회할 수 있게 됩니다. 만약 인덱스를 사용하지 않고 조회를 할 시에는, 테이블 전체를 탐색하는 Full Scan이 수행됨으로써 처리 속도가 떨어지게 됩니다.

인덱스는 데이터베이스 테이블에 대한 검색 성능의 속도를 높여주는 자료 구조입니다. 특정 컬럼에 인덱스를 생성하면, 해당 컬럼의 데이터들을 정렬하여 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장합니다. 인덱스가 생성 되었다면 생성한 인덱스의 컬럼을 Where 조건으로 쿼리하면 옵티마이저에서 판단하여 생성된 인덱스를 타게 됩니다. 그러면 인덱스에 저장되어 있는 데이터의 물리적 주소로 가서 데이터를 가져오게 됩니다.

14. 이분탐색이 무엇이고 시간복잡도는 어떻게 되며 그 이유는 무엇인가요?

이분 탐색은 내가 찾고자 하는 값이 정렬된 배열의 중간 값보다 크면 중간값을 포함한 하위 값들은 탐색 대상에서 제외된시키고, 반대로 찾고자 하는 값이 배열의 중간 값보다 작으면 중간 값을 포함한 상위 값들은 탐색에서 제외 시킵니다. 정리하면 중간값과 찾으려는 값의 대소를 비교한 뒤 탐색 범위를 반으로 줄여가며 값을 찾는 탐색 알고리즘입니다. 이런 방식은 한번 탐색을 하고나면 탐색의 범위가 절반으로 줄기 때문에 logN의 시간복잡도를 보장합니다. 하지만 정렬되어 있는 자료에서만 사용할수 있다는 단점이 있습니다.

15. 모든 요소에 인덱스를 걸지 않는 이유는 무엇일까요?

인덱스를 사용하면 테이블을 검색하는 속도와 성능이 향상되는 장점이 있지만 인덱스를 관리하기 위한 추가 작업이 필요하며, 추가 저장 공간 또한 필요합니다. 잘못 사용하는 경우 오히려 성능이 저하될 수 있으며 인덱스가 적용된 칼럼에 삽입, 삭제, 수정이 잦다면 인덱스 또한 수정해야 하기 때문에 성능이 낮아지며. 또한 인덱스는 제거되는 것이 아니라 '사용하지 않음'으로 남겨 두기 때문에 인덱스가 과도하게 커질 수 있기 때문에 모든 요소에 인덱스를 걸지 않는다고 생각합니다.

오늘 드디어 항해99 수료를 했다. 45명으로 시작해 22명만 남은 우리 B반. 그만큼 쉽지 만은 않은 여정이었다.

정말 0부터 시작했던 지라, 많이 벅차고, 포기하고 싶고, 주변 사람들을 보면서 '난 개발에 소질이 없는 건가?' 라는 생각도 많이했던 지난 99일. 마지막 프로젝트 마치고 마음이 많이 뒤숭숭 했는데, 오늘 수료식에서 '성장속도 상상 그 이상'을 받았다.

난 항상 내가 많이 부족하다고 생각했는데, 같은 반 사람들이 뽑아줘서 더 의미가 있는 상이다. 그동안 같은 반 분들한테 많이 물어보고 귀찮게 했었는데 그럴때마다 다들 친절하게 알려줘서 너무 고마웠다. 이 말을 꼭 전하고 싶었는데, 정말 기대도 안하다 갑자기 상을 받아서 그냥 감사합니다 라는 짧은 말밖에 못 전한게 너무 아쉽다.

수료식이 끝나고 항해99에서 잡아준 모의 면접에 참가했다. 유진호 멘토님이 담당해 주셨는데, 이력서를 보시자 마자 '이력이 특이하네요?' 라고 물으시면서 왜 개발자가 되고 싶은지, 그리고 지금 지원한 곳이 있는지 여쭤보셨다. 

그래서 지금 PM직무로 지원을 했고, 상황을 말씀 드렸더니 원래 기술 면접을 연습하는 자리지만, 그냥 선배입장으로 조언을 주는게 좋을 것 같다고 정말 위로가 되는 여러 조언들을 많이 해주셨다. 금요일밤 쉬고 싶으실 텐데, 원래 20분인 모의 면접 시간을 넘어 40분이 넘도록 진심으로 여러 조언을 해주시고, 책도 추천해 주시고, 혼자 어떻게 공부하고 어떻게 취업을 준비하면 좋을지, 그리고 채용 사이트를 같이 봐주시면서 내 수준에서 지금 지원할 수 있는 회사들을 하나하나 다 같이 봐주셨다.

진짜 너무 감동 ㅠㅠ 

마지막 프로젝트를 하면서, 그리고 프로젝트가 끝나고 나서 내가 정말 최선을 다 했었나? 라는 의문을 갖기도 하고, 개발 직무에 대한 자신감이 많이 떨어졌었는데, 마지막 날 동료들과 멘토님 덕분에 용기도 많이 얻고 힐링한 하루 였다. 내가 본 항해99 10기 b반 사람들 중 누구도 열심히 안 한 사람이 없다. 다들 진짜 좋은 개발자가 될 것 같다. 다들 많이 벌고 적게 일하는 개발자가 되기를 !! 

OAuth 2.0

• OAuth 2.0을 사용한다면 대부분의 로그인, 개인정보 관리 책임을 서드파티 애플리케이션 (Google, Facebook, Kakao 등)에게 위임할 수 있다. (단, 사용자가 기존에 서드파티 서비스에 회원가입이 되어있어야 함) 뿐만아니라 각 서드파티가 가지고 있는 사용자의 리소스를 조회 등을 내 애플리케이션에서 수행할 수 있다.

• Resource Owner : 리소스의 권한을 가진 사용자. 사용자 혹은 유저(User)라고도 한다. ex) 나몰닭 유저
• Client : 리소스 서버에 접근을 요청하는 어플리케이션 혹은 웹 사이트. 즉, 서비스를 제공자이며 Third Party Application 라고도 한다. ex) 나몰닭이 여기에 해당
• Authorization Server : 액세스 토큰(Access Token)을 클라이언트에게 발급해주는 서버. 인가의 주체. ex) 카카오톡, 구글, 네이버 등
• Resource Server : Authorization Server가 발급한 액세스 토큰(Access Token)을 확인하고 리소스를 제공. API 서버. ex) 이름, 나이 등 아이디 관련 정보(리소스)를 제공하는 서버. 카카오톡, 구글, 페이스북, Github 등

· Authorization Code Grant Type

•   클라이언트가 사용자 대신 특정 리소스에 접근을 요청할 때 사용된다. 클라이언트는 Access Token을 발급 받기 전, 인가코드(Authorization Code)를 사용자에 의해 받게 되고, 그 인가코드(Authorization Code)를 가지고 인가 서버(Authorization Server)에 요청을 보내면 리소스에 대한 Access Token을 발급 받을 수 있다.

Redis Refresh Token 

• JWT는 발급한 후 삭제가 불가능하기 때문에, 접근에 관여하는 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대해 대응을 하여야 한다.
• 이처럼 토큰 유효기간을 짧게하면 토큰 남용을 방지하는 것이 해결책이 될 수 있지만, 유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편하다는 단점이 있다. 그렇다고 무턱대고 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 된다.
• 이때 “그러면 유효기간을 짧게 하면서  좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 Refresh Token이다. 이름이 다르지만 형태 자체는 Refresh Token은 Access Token과 똑같은 JWT다.
• 단지 Access Token은 접근에 관여하는 토큰이고, Refresh Token은 재발급에 관여하는 토큰 이므로 행하는 역할이 다르다고 보면 된다.

Redis 사용 이유

1) In Memory DB의 장점인 빠른 액세스 속도로 사용자 로그인시 (리프레시 토큰 발급시) 병목이 되지 않는다.

2) Refresh Token은 발급된 후 일정 시간 이후 만료되어야 한다. Refresh Token을 RDB인 MySQL에 저장하면, 스케줄러 등을 사용하여 주기적으로 만료된 토큰을 만료 처리하거나 제거해야한다. 하지만, 레디스는 기본적으로 데이터의 유효기간(time to live)을 지정할 수 있어서 보다 쉽게 구현이 가능하다.

AWS S3 이미지 업로드

• putObject 메소드를 이용하여 지정된 버켓에 파일이름과 이미지파일을 저장해주고
• return값으로 이미지 url을 String 타입으로 반환하다.
• S3에 저장될 파일이름을 fileName 에 담아준다.
• 다음, 이미지 파일과 파일 이름을 아래 putS3 메소드를 이용하여 S3에 업로드해준다.
• 다음 아아래에 있는 removeNewFile 메소드를 이용해 로컬에 저장된 이미지파일을 삭제한다.
• 1개 이상의 이미지가 담겨있는 multipartFileList를 for문을 돌려 이미지가 있을 시 convert 메소드를 통해 파일을 전환시켜 준다.
• 그리고, new ImagFile 안에서 아래의 upload 메소드를 사용해 이미지 파일과, 폴더명, 유저 정보, 룸 정보를 담아준다. 
• 다음 imageFileRepository에 저장한다.

Enum

• Enum이란 enumerated type의 줄임말로 열거형이라고 불리며 서로 연관된 상수들의 집합을 의미한다.
• 흔히 상수를 정의할 때 final static string 과 같은 방식으로 상수를 정의한다. 하지만 이렇게 상수를 정의해서 코딩하는 경우 다양한 문제가 발생하는데, 이러한 문제점들을 보완하기 위해 자바 1.5버전부터 새롭게 추가된 것이 바로 "Enum" 이다.
• 코드가 단순해지며, 가독성이 좋다.
• 인스턴스 생성과 상속을 방지하여 상수값의 타입안정성이 보장된다.
• enum class를 사용해 새로운 상수들의 타입을 정의함으로 정의한 타입이외의 타입을 가진 데이터값을 컴파일시 체크한다.
• Enum을 사용하는데 있어 가장 큰 허들은 "변경이 어렵다"란 점
• 코드를 추가하거나 변경해야 하는 일이 빈번하다면, 매번 Enum 코드를 변경하고 배포하는것보다 관리자 페이지에서 관리자가 직접 변경하는 것이 훨씬 편리할 수 있다.
• 위와 같은 경우 테이블로 관리함으로써 얻는 장점이 정적언어를 활용함으로써 얻는 장점을 버릴정도로 더 큰지 고민해봐야 한다.

비관적 락

• 자원 요청에 따른 동시성문제가 발생할것이라고 예상하고 락을 걸어버리는 방법론
• 트랜잭션의 충돌이 발생한다고 가정 = 사용자들이 같은 데이터를 동시에 수정 할 것이라고 가정
• 하나의 트랜잭션이 자원에 접근시 락을 걸고, 다른 트랜잭션이 접근하지 못하게 하는 방식 = 한사용자가 데이터를 읽는 시점에 Lock을 걸고 조회 또는 갱신 처리가 완료될 때 까지 유지

장점

• 충돌이 자주 발생하는 환경에 대해서는 롤백의 횟수를 줄일 수 있으므로 성능에서 유리
• 데이터 무결성을 보장하는 수준이 매우 높다.

단점

• 데이터 자체에 락을 걸어버리므로 동시성이 떨어져 성능 손해를 많이 보게 된다. 특히 읽기가 많이 이루어지는 데이터베이스의 경우에는 손해가 더 두드러짐.
• 첫번째 사용자가 트랜잭션을 완료하기 전까지 다른 사용자들이 데이터를 수정할수 없기때문에 제어를 잘못하면 동시성을 저해 받게 된다.
• 서로 자원이 필요한 경우에, 락이 걸려있으므로 데드락이 일어날 가능성이 있다.

낙관적 락 

• 자원에 락을 걸어서 선점하지말고, 동시성 문제가 발생하면 그때 가서 처리 하자는 방법론 
• 낙관적 동시성 제어는 사용자들이 동시에 데이터를 수정하지 않을 것이라고 가정한다. = 트랜잭션의 충돌이 발생하지 않을것이라고 기대
• 일단 충돌이 나는것을 막지 않고, 충돌이 난것을 감지하면 그때 처리

장점

• 충돌이 안난다는 가정하에, 동시 요청에 대해서 처리 성능이 좋다.

단점

• 잦은 충돌이 일어나는경우 롤백처리에 대한 비용이 많이 들어 오히려 성능에서 손해를 볼 수 있다.
• 롤백 처리를 구현하는게 복잡할 수 있다.

• 비관적락 은 데이터의 무결성이 중요하고, 충돌이 많이 발생하여 잦은 롤백으로 인한 효율성 문제가 발생하는것이 예상되는 시나리오에서좋다.
• 비관적 동시성 제어는 동시성이 저하 되지만 데이터를 일일이 검사하지 않아도 된다. 만약 데이터 정합성이 중요한 업무(금융) 라면 비관적 동시성 제어로 동시성이 저하 되더라도 for update 문으로 예외처리를 하여 오히여 동시성을 높이면서 좋은 데이터 정합성을 가질 수 있다.
• 낙관적락 은 실제로 데이터 충돌이 자주 일어나지 않을것이라고 예상되는 시나리오에서 좋다.
• 낙관적 동시성 제어는 크게 경합이 벌어지지 않는 업무 ( 쇼핑몰) 등에서 사용하고, Lock이 짧아져 동시성을 높이는것이 좋다.
  하지만 상품 조회시점과 결제 시점에 가격이 다를 수 있으므로 반드시 데이터 수정시 일관성 검사를 거쳐야만 한다.

Spring Security

• 인증(Authentication) : 해당 사용자가 본인인지 확인하는 절차
• 인가(Authorization) : 인증된 사용자가 요청한 자원에 접근 가능한지 결정하는 절차
• 접근 주체(Principal) : 보호받는 Resource에 접근하는 대상
• 비밀번호(Credential) : Resource에 접근하는 대상의 비밀번호
• 권한 : 인증된 주체가 어플리케이션의 동작을 수행할 수 있도록 허락되어 있는지 결정
  • 인증 과정을 통해 주체가 증명된 이후 권한을 부여할 수 있다.
  • 권한 부여에 두 가지 영역이 존재하는데 웹 요청 권한과 메서드 호출 및 도메아ㅣㄴ 인스턴스에 대한 접근 권한 부여가 있다.

Spring Security는 기본적으로 인증 절차를 거친 후 인가 절차를 진행하게 되며, 인가 과정에서 해당 리소스에 대한 접근 권한이 있는지를 확인한다. 이러한 인증과 인가를 위해 Principal을 아이디로, Credential을 비밀번호로 사용하는 인증 방식을 사용한다.
spring security 에서는 기본적으로 세션 - 쿠키 방식을 사용하고 있다.

일반적인 Form Login 절차

1. 요청 수신

• 사용자가 form을 통해 로그인 정보가 담긴 Request를 보낸다.

1. 토큰 생성

• AuthenticationFilter가 요청을 받아서 UsernamePasswordAuthenticationToken토큰(인증용 객체)을 생성
• UsernamePasswordAuthenticationToken은 해당 요청을 처리할 수 있는 Provider을 찾는데 사용

1. AuthenticationFilter로 부터 인증용 객체를 전달 받는다.

• Authentication Manager에게 처리 위임
• Authentication Manager는 List형태로 Provider들을 갖고 있다.

1. Token을 처리할 수 있는 Authentication Provider 선택

• 실제 인증을 할 AuthenticationProvider에게 인증용 객체를 다시 전달한다.

1. 인증 절차

• 인증 절차가 시작되면 AuthenticationProvider 인터페이스가 실행되고 DB에 있는 사용자의 정보와 화면에서 입력한 로그인 정보를 비교

1. UserDetailsService의 loadUserByUsername메소드 수행

• AuthenticationProvider 인터페이스에서는 authenticate() 메소드를 오버라이딩 하게 되는데 이 메소드의 파라미터인 인증용 객체로 화면에서 입력한 로그인 정보를 가져올 수 있다.

1. AuthenticationProvider 인터페이스에서 DB에 있는 사용자의 정보를 가져오려면, UserDetailsService 인터페이스를 사용한다.
2. UserDetailsService 인터페이스는 화면에서 입력한 사용자의 username으로 loadUserByUsername() 메소드를 호출하여 DB에 있는 사용자의 정보를 UserDetails 형으로 가져온다. 만약 사용자가 존재하지 않으면 예외를 던진다. 이렇게 DB에서 가져온 이용자의 정보와 화면에서 입력한 로그인 정보를 비교하게 되고, 일치하면 Authentication 참조를 리턴하고, 일치 하지 않으면 예외를 던진다.
3. 인증이 완료되면 사용자 정보를 가진 Authentication 객체를 SecurityContextHolder에 담은 이후 AuthenticationSuccessHandle를 실행한다.(실패시 AuthenticationFailureHandler를 실행한다.)

JWT

• JWT(JSON Web Token)란 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다.
• JWT(Json Web Token)란 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token이다. JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달한다. 
• JWT는 Header, Payload, Signature의 3 부분으로 이루어지며, Json 형태인 각 부분은 Base64Url로 인코딩 되어 표현된다. 또한 각각의 부분을 이어 주기 위해 . 구분자를 사용하여 구분한다. 추가로 Base64Url는 암호화된 문자열이 아니고, 같은 문자열에 대해 항상 같은 인코딩 문자열을 반환한다.

단점 

• Self-contained: 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다. 
• 토큰 길이: 토큰의 페이로드(Payload)에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다. 
• Payload 인코딩: 페이로드(Payload) 자체는 암호화 된 것이 아니라, BASE64Url로 인코딩 된 것이다. 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, JWE로 암호화하거나 Payload에 중요 데이터를 넣지 않아야 한다. 
• Stateless: JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능하다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 한다. 
• Store Token: 토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 한다.

[서버 기반 vs 토큰 기반]

서버(세션) 기반 인증 시스템
서버의 세션을 사용해 사용자 인증을 하는 방법으로 서버측(서버 램 or 데이터베이스)에서 사용자의 인증정보를 관리하는 것을 의미한다.
그러다 보니, 클라이언트로부터 요청을 받으면 클라이언트의 상태를 계속에서 유지해놓고 사용한다.
(Stateful) 이는 사용자가 증가함에 따라 성능의 문제를 일으킬 수 있으며 확장성이 어렵다는 단점을 지닌다.

토큰 기반 인증 시스템
이러한 단점을 극복하기 위해서 "토큰 기반 인증 시스템"이 나타났다.
인증받은 사용자에게 토큰을 발급하고, 로그인이 필요한 작업일 경우 헤더에 토큰을 함께 보내 인증받은 사용자인지 확인한다.
이는 서버 기반 인증 시스템과 달리 상태를 유지하지 않으므로 Stateless 한 특징을 가지고 있다.

RESTful 한 API 란?

RESTful API(=REST API)란, REST한 방식으로 클라이언트와 서버간 상호 데이터 교환을 하는 API이며, 서로간에 stateless한 특징을 가지는 API입니다. -> HTTP를 잘사용하기위해, URI와 HTTP메소드를 사용해서, URL로 어떤 자원에 접근할 것인지, 메소드로 어떤 행위를 할것인지 표현하여 설계된 API를 말합니다.

또한 API가 RESTful로 간주되기 위해서는 몇가지 조건이 있는데 그 중 가장 중요한 건,

• 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음
• Stateless(무상태)입니다.

클라이언트와 서버간 종속적이지 않다는 말입니다.

즉, 서버는 클라이언트의 정보를 저장-유지하고 있지않아, 같은 사람이보낸 정보도, 같은사람이 보냈는지 정보를 유지하고있지 않다는 말입니다.

이말은 즉, 클라이언트가 요청시 마다, 자기 정보를 보내야하고, 서버는 받은 정보로 클라이언트의 정보를 확인합니다.

따라서,  

• 멀티플랫폼 지원이 용이하고,
• Stateless한 RESTful API는 Client의 요청(호출)을 어느 Server라도 동일하게 처리할 수 있고
• 즉, 어떤 Server라도 Client들의 요청에 응답할 수 있다는 것은, 서버 환경이 분산되었든 아니든, Client쪽에서는 Server쪽에 신경 쓸 필요 없이 API 호출만 하면 원하는 결과를 받을 수 있다는 점에서 RESTful API가 활용되는 것입니다.

오늘 아침 [KB국민은행 IT's Your Life 3기] SW역량평가 시험이 있었다.

10시 30분 부터 시작인데, 9시 55분까지 메일로 받은 줌 링크로 접속하여 오리엔테이션을 진행하고, 줌을 킨 상태로 시험을 보는 형식이었다.

총 문제는 40문제, 1시간 안에 풀어야 했다. 

몇몇 부트 캠프나 개발 교육 프로그램들은 사전 시험이 있다고 들어봤지만, 직접 참여해본 건 처음이다. 

이번이 3기라 그런지 별로 시험에 대한 후기가 없어서 대략 알고리즘 문제겠지? 라고 추측 했는데, 결론은 아니었다.

내용을 포스팅 해도 되는지 확실히 몰라서 대략 설명하자면, 공기업 NCS 문제가 반 그리고 알고리즘 사고를 해야하는 문제가 반 정도 된 것 같다. 공학용 계산기 혹은 일반 계산기 사용이 가능했다. 도구가 있어도 쓸 줄 알아야 .... ㅎ 엄청 찍고 나옴 ^^ ㅎ .....................

이런 시험 잘푸시는 분들 너무 신기하다. 좋은 경험이었다. 

( + 추가 )

분명히 시험 망했다고 생각했는데 오늘 서류 전형 합격 문자를 받았다.

알고리즘 사고 문제가 주관식이었고 마지막 두 문제는 풀지도 않고 찍어서 기대를 안 했는데, 아무래도 예전에 잠깐 취준한다고 공부 했던 NCS문제를 잘 찍은 것(?) 같다. 일단 서류 전형 통과해서 역량 테스트를 본 사람은 대략 300명이 넘었던 것 같은데, 면접 전형은 몇 명을 붙여 준 건지 잘 모르겠다. 총 75명이 선발 되는 걸로 아는데, 시험에 통과한 것 만으로도 기분이 좋음 : )