[면접 준비] - 공통

🤗 모든 질문은 '아는대로 설명해주세요'가 베이스~!

 

🔔 Restful API에 대해 설명해주세요.

• Restful API는 HTTP 통신을 Rest 설계 규칙을 잘 지켜서 개발한 API를 Restful한 API라고 합니다.
• Rest 설계 규칙은 URI는 정보의 자원만 표현해야 하며, 자원의 상태와 행위는 HTTP Method에 명시하는걸 말합니다.
  REST란? REST API 와 RESTful API의 차이점?

 

---

🔔 프레임워크와 라이브러리의 차이에 대해 설명해주세요.

• 이 둘의 차이점은 제어 흐름에 대한 주도권이 누구에게/어디에 있는가에 있습니다.
• 프레임워크는 전체적인 흐름을 쥐고 있고, 개발자는 그 안에서 라이브러리에 대한 흐름을 쥐고 있습니다.
• 여기서 개발자의 제어권을 프레임워크에게 넘김으로써 신경써야할 것을 줄일 수 있는데,
  이를 제어의 역전(Inversion of Control)이라 합니다.

---

🔔 Call By Value와 Call By Reference의 차이에 대해 설명해주세요.

• Call By Value(값에 의한 호출) - 인자로 받은 값을 복사하여 처리하는 방식입니다. 
  • 장점 - 값을 복사하여 처리하기 때문에 원래의 값이 보존된다.
  • 단점 - 복사하기 때문에 메모리 사용량이 증가한다.
• Call By Reference(참조에 의한 호출) - 인자로 받은 값의 주소를 참조하여 직접 저장해 값에 영향을 주는 방식 입니다. 
  • 장점 - 복사하지 않고 직접 참조하기에 빠르다.
  • 단점 - 직접 참조를 하기에 원래의 값이 영향을 받는다.

 

🔔 그럼 Java에서 어느 부분이 call by value이고 어느 부분이 call by reference에 해당하나요?

• Java는 기본적으로 모든 전달 방식이 Call by Value 입니다.
• 참조형의 경우 객체의 '주소값'을 매개변수로 전달하니 call by reference가 아니냐는 의문을 가질 수 있지만,
• 정확하게 말하면 '주소값'이 아니라, '주소를 가리키는 참조값'이다.
• 또한, 주소값 자체를 '복사 없이' 인자로 전달하는게 아니라 자기 자신이 갖고 있는 값을 복사해서 전달한다.
• 결국 기본형 변수나 참조형 변수 모두 자기 자신이 갖고 있는 값을 복사해서 전달하기 때문에 Call by value이다.

 

---

🔔 CORS(교차 출처 리소스 공유, Cross-Origin Resource Sharing)에 대해 설명해주세요.

• CORS란 도메인이 서로다른 2개의 사이트가 데이터를 주고 받을 때 발생하는 문제입니다.
• 예를 들어 domain-a.com ↔ domain-b.com으로 데이터를 주고받을시 따로 설정 하지 않으면 CORS 에러를 만나게 됩니다. ※ 브라우저는 보안 상의 이유로, 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다.

 

• 따라서 다른 서버의 리소스를 불러오기 위해서는, 그 출처에서 CORS에 대한 내용을 Response의 헤더에 추가해줘야 합니다.
• Access-Control-Allow-Orgin : 요청을 보내는 페이지의 출처 [ *, 도메인 ]
• Access-Control-Allow-Methods : 요청을 허용하는 메소드. Default : GET, POST
• Access-Control-Max-Age : 클라이언트에서 preflight 요청 (서버의 응답 가능여부에 대한 확인) 결과를 저장할 시간
• Access-Control-Allow-Headers : 요청을 허용하는 헤더

---

🔔 절차지향 프로그래밍과 객체지향 프로그래밍의 차이점에 대해 설명해주세요.

• 절차지향 프로그래밍
  • 물이 위에서 아래로 흐르는 것처럼 순차적인 처리를 중요시하는 프로그래밍 기법이다.
  • 대표적인 언어로 C언어가 있다.
  • 컴퓨터의 처리구조와 유사해 실행속도가 빠르다.
  • 코드의 순서가 바뀌면 동일한 결과를 보장하기 어렵다.
• 객체지향 프로그래밍
  • 실제 세계의 사물들을 객체로 모델링하여 개발을 진행하는 프로그래밍 기법이다.
  • 대표적인 언어로 Java가 있다.
  • 캡슐화, 상속, 다형성 등과 같은 기법을 이용할 수 있다.
  • 절차지향 언어보다 실행속도가 느리다.

절차지향 프로그래밍은 기능중심으로 바라보는 방식으로 "무엇을 어떤 절차로 할 것인가?"가 핵심이 되며,

어떤 기능을 어떤 순서로 처리하는가에 대해 초점을 맞추고, 

객체지향 프로그래밍은 기능이 아닌 객체 중심으로 바라보는 방식으로 "누가 어떤 일을 할 것인가?"가 핵심이며,

객체를 도출하고 각각의 역할을 정의해 나가는 것에 초점을 둔다.

---

🔔 OAuth 2.0의 흐름에 대해 간단히 설명해주세요.

1. 사용자가 클라이언트(이하 클라)에게 사용 요청을 보낸다.
2. 클라는 권한 서버에 권한 부여 승인 코드 요청(response_type=code로 지정하여 요청)을 보낸다.
3. 이후 클라는 권한 서버에서 제공하는 로그인 페이지를 띄워 사용자에게 보여준다.
4. 사용자가 로그인 하면 권한 서버는 (2)권한 부여 승인 코드 요청에 전달받은 redirect_url로 Authorization Code를 전달한다.
5. Authorization Code는 권한 서버에서 제공하는 API를 통해 Access Token으로 교환된다.

---

🔔 동적 쿼리란 무엇이고 언제 동적 쿼리를 사용하나요?

• 동적 쿼리란 실행시에 특정 조건이나 상황에 따라 쿼리 문장이 변경되어 실행되는 쿼리문을 말합니다.
• 컴파일시에 SQL 문장을 확정할 수 없는 경우에 사용합니다. 실행 시점에 따라 where절에 조건이 달라질 때 사용합니다.
• 쿼리문이 변하냐 변하지 않느냐에 따라 정적쿼리/동적쿼리가 됩니다.

---

🔔 CSRF(Cross-site request forgery)에 대해 설명하고, 이를 막기 위한 방법에 대해 설명해주세요.

• 사이트 간 요청 위조의 약자로 웹 어플리케이션 취약점 중 하나로 공격자가 의도한대로 사용자가 행동하게 하여 특정 웹페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격 방법을 의미합니다.

 

1. 사용자의 요청에 referrer를 확인하여 도메인이 일치하는지 확인하는 방법으로 공격을 방어
   1. ※ 요청 헤더(request header)에서 referrer 정보를 확인할 수 있음
   2. ※ 같은 도메인에서 들어오는 접속은 허용하나 다른 도메인에서 호출할 때는 차단하는 개념
2.  상태를 변화시키는 POST, PUT 등의 요청에 대해 csrf 토큰이 포함되어야만 요청을 처리하여 공격을 방어

CSRF 공격과정

- 2008년도에 있었던 옥션 해킹 사고도 CSRF 공격을 했다고 한다.
(해커가 옥션 운영자에게 CSRF 코드가 포함된 이메일을 보내서 관리자 권한을 얻어냈다)

	...
	<img src="http://auction.com/changeUserAcoount?id=admin&password=admin" width="0" height="0">
	...

1. 옥션 관리자 중 한 명이 권한을 가진채 회사 내에서 작업을 하던 중 메일을 조회한다.
   (로그인이 되어있으니 관리자로서의 유효한 쿠키를 가지고 있음)
2. 해커는 위와 같이 태그가 들어간 코드가 담긴 이메일을 보낸다.
3. 관리자가 이메일을 열어볼 때, 이미지 파일을 받아오기 위해 위 URL이 열린다.
4. 해커가 의도한 대로 관리자 계정 id와 pw가 admin으로 변경된다.

---

🔔 대칭키, 비대칭키 암호화 방식에 대해 설명해주세요.

대칭키와 비대칭키는 양방향 암호화 방식입니다.

대칭키는 암호화와 복호화에 같은 암호 키를 쓰는 알고리즘입니다.
이는 중간에 누군가 암호키를 가로채면 정보가 유출될 수 있다는 단점이 있는데 이런 문제를 보완한 방식이 바로 비대칭키 입니다.

비대칭키는 암호화와 복호화할 때 서로 다른 키를 쓰는 알고리즘입니다.
타인에게 절대 노출되어서는 안되는 개인키와 공개적으로 개방되어 있는 공개키를 쌍으로 이룬 형태입니다.

---

🔔 TDD(Test-Driven-Development)의 개념에 대해 설명해주세요.

• TDD란 작은 단위의 테스트 케이스를 작성하고 그에 맞는 코드를 작성하여 테스트를 통과한 후에
  상황에 맞게 리팩토링하는 테스트 주도 개발 방식을 말합니다.
• 이렇게 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고, 코드는 간결해진다는 장점이 있습니다.
• TDD는 레드 그린 사이클이라는 3가지 과정을 거칩니다.

1. Red : 어떠한 기능을 검증하는 테스트가 실패하는 코드를 작성하고, 실제로 실패하는지 확인한다.
2. Green : 어떠한 기능을 검증하는 테스트가 통과하는 코드를 작성하고, 실제로 성공하는지 확인한다.
3. Refactor : 앞에 실패하는 테스트와 성공하는 테스트를 모두 검증했다면, 작성한 코드를 깨끗하고 가독성 좋게 고친다.
4. Repeat : 이 세 가지 과정을 반복하여 프로그램을 완성한다.

🔔 테스트 코드를 작성 해야하는 이유에 대해 아는대로 설명해주세요.

1. 기능의 추가, 변경, 삭제로 인한 영향도를 쉽게 파악 가능
2. 예상하지 못한 오류에 대한 피드백을 위해
3. 좋은 설계로 작성되게끔 코드를 유도
4. 기능 정의의 문서의 역할
5. 실수를 줄여준다.

---

🔔 DDD(Domain-Driven-Design)에서 얘기하는 계층과 각각의 역할에 대해 설명해 주세요.

• 표현 계층(Presentation layer) : 사용자의 요청에 대해 해석하고 응답하는 일을 책임지는 계층 (Controller)
  • Client로부터 request를 받고 response를 return 하는 API 정의
• 응용 계층(Application layer) : 비즈니스 로직을 정의하고 정상적으로 수행될 수 있도록 도메인 계층과 인프라스트럭처 계층을 연결해주는 역할을 하는 계층 (Service)
  • transaction 관리, DTO 변환, 모듈간의 연계를 진행
• 도메인 계층(Domain layer) : 비즈니스 규칙, 정보에 대한 실질적인 도메인에 대한 정보를 가지고 있으며 이 모든것을 책임지는 계층 (Entity)
  • Entity를 활용하여 도메인 로직이 진행된다.
  • 업무 상황을 반영하여 상태를 제어하는 역할에 집중하는 계층
• 인프라스트럭처 계층(Infrastructure layer) : 외부와의 통신(ORM, DB, NoSQL)을 담당하는 계층 (Repository)
  • 해당 계층에서 얻어온 정보를 응용 계층 또는 도메인 계층에 전달하는 것을 주 역할로 담당

---

🔔 MSA(Microservice Architecture)가 뭔지 설명해주세요.

• MSA는 1개의 시스템을 독립적으로 배포 가능한 각각의 서비스로 분할합니다. 각각의 서비스는 API를 통해 데이터를 주고 받으며 1개의 큰 서비스를 구성합니다.
• 모든 시스템의 구성요소가 한 프로젝트에 통합되어 있는 Monolithic Architecture(모놀리식 아키텍쳐)의 한계점을 극복하고자 등장하게 되었습니다.

https://mangkyu.tistory.com/88

• 장점
  • 일부 서비스에 장애가 발생해도 전체 서비스에 영향을 끼치지 않는다.
  • 각각의 서비스들은 서로 다른 언어와 프레임워크로 구성될 수 있다.
  • 서비스의 확장이 용이하다.
• 단점
  • 서비스가 분리되어 있어 테스트나 트랜잭션 처리 등이 어렵다.
  • 서비스 간에 API로 통신하기 때문에 그에 대한 비용이 발생한다.
  • 서비스 간의 호출이 연속적이기 때문에 디버깅 및 에러 트레이싱이 어렵다.

 

 

💡 최근에 읽은 기술 관련 책 이름이 무엇이고 인상 깊었던 부분을 얘기해주세요.

 

💡 본인이 사용했던 기술들과 그 기술을 사용했던 이유에 대해 설명하고, 대체 기술도 알고 있다면 얘기해주세요.

 

💡 하나의 비지니스 로직을 작성할 때 어느 수준으로 작성하는지, 무엇을 중요하게 생각하는지 얘기해주세요

 

💡 신규 기술을 도입해본 사례가 있으면 얘기해주세요.

 

💡 초당 100만개 씩 들어오는 요청에 대해 10000번째로 들어온 요청의 사용자를 어떻게 찾을 것인지 설명해주세요.

 

💡 프로젝트를 진행하면서 어려웠던 점이 있었다면 설명해주세요.

 

💡 앞으로 쌓거나 경험하고 싶은 개발자 커리어가 있다면 얘기해주세요.

 

 

참고

https://dev-coco.tistory.com/164 [슬기로운 개발생활:티스토리]