[Note] 📝 기술면접 대비 정리 노트

---

기술면접 대비 개념 정리

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

Call by reference - 참조에 의한 호출로써, 함수가 호출될 때 메모리 공간 안에는 함수를 위한 별도의 임시 공간이 생성된다. 함수 호출 시 인자로 전달되는 변수의 레퍼런스(주소)를 전달하여 해당 변수를 가르킨다. 함수 안에서 인자의 값이 변경되면, 함수 호출 시에 있던 변수들도 값이 바뀐다. C언어에서 Swap을 구현할때 값이 아닌 주소를 전달하는 것도 같은 이유에서이다.

Call by value - 값에 의한 호출로써, 함수가 호출될 때 전달되는 변수의 값을 복사하여 함수의 인자로 전달한다. 복사된 인자는 함수 실행이 종료될 때 같이 소멸하며, 외부의 값을 복사해서 사용하기 때문에 내부에서 인자의 값이 변경되더라도 외부의 값에는 영향을 미치지 않는다.

Java에서는 primitive type(int, long, ...)이 아니라면 call-by-reference로 동작한다.

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

Override는 상속받은 클래스나 구현할 인터페이스의 메소드를 재정의하는 것을 의미합니다. Override는 재정의 하는 것이기 때문에 메소드의 이름과, 매개변수, 리턴형이 같아야 합니다.

Overload는 같은 이름의 메소드라도 매개변수를 다르게 지정하여 메소드를 정의하는것을 의미합니다. Overload는 메소드의 이름이 같아야하고, 매개변수는 달라야합니다. 리턴타입은 같거나 달라도 상관 없지만, 리턴타입만 다르다면 컴파일러 입장에서 메소드를 구분할 수 없기에 Overload가 불가능 합니다.

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

JPA는 객체지향과 RDB의 완전히 다른 두 패러다임 사이의 불일치에 의해 탄생한 ORM 입니다. 이전에는 개발자가 객체의 데이터를 한땀한땀 매핑하여 DB에 저장 및 조회처리를 하였고, 이러한 이유에서 비즈니스로직에 온전히 집중하지 못했습니다. ORM은 객체와 RDB 사이에서 sql을 직접 작성하는 번거로움을 덜어주어 개발자의 단순 작업을 줄이고 비즈니스 로직에 집중할 수 있도록 도와줍니다. 그러나 모든 쿼리를 JPA로 해결하지 못하는 순간이 발생하기도 하기 때문에 직접 쿼리문을 작성해야하는 경우도 있습니다. 개발자는 JPA를 사용하기 이전에 sql을 먼저 이해하고 있어야 하고 객체, RDB 양쪽의 특징과 동작하는 법을 잘 이해해야 합니다.

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

간단하게 말하면 JPA의 영속성 컨텍스트 내부에서 발생한 변경사항을 체크하고 트랜잭션이 끝나 flush가 될 때 변경사항을 적용시키는 쿼리문이 날아가는 것입니다.

영속성 컨텍스트는 더티체킹, 쓰기지연 저장소, 1차캐시 등의 기능들을 제공하는데, 그중 더티체킹이란 처음 데이터를 조회할 때 1차캐시에 저장해놓은 스냅샷과 이후 데이터 사이에 변경사항이 있을경우 이를 체크하고 업데이트 쿼리문을 db에 날려주는 것 입니다.

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

JVM은 Java Virtual Machine 으로 자바 프로그램을 실행시켜주는 가상 머신입니다. 일반적인 프로그램은 OS에 종속적이게 개발이 되었지만, Java는 각 OS에 맞게 제공된 JVM이 띄워질 수 있기에 같은 소스코드로 다른 OS에서 실행 할 수 있게 됩니다. JVM이 주는 이점으로는 이것 이외에도 GC를 통해 프로그램의 메모리 관리를 해준다는 점도 있습니다.

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

• 우선 자바 파일을 작성합니다.

• 작성한 자바 파일을 자바 컴파일러가 바이트 코드로 이루어진 .class파일로 컴파일 해 줍니다.

• 바이트코드(.class)를 JVM의 클래스로더가 받아 동적로딩(Dynamic Loading)을 통해 필요한 클래스들을 로딩 및 링크하여 런타임 데이터 영역, JVM의 메모리영역에 올립니다.

• 실행 엔진(Execution Engine)은 JVM 메모리에 올라온 바이트 코드들을 명령어 단위로 하나씩 가져와 실행합니다. 이때, 실행 엔진은 두가지 방식으로 변경 합니다.

  • 인터프리터 : 바이트 코드 명령어를 하나씩 읽어서 해석하고 실행합니다. 하나하나의 실행은 빠르나, 전체적인 실행 속도가 느리다는 단점을 가집니다.

  • JIT 컴파일러(Just-In-Time Compiler) : 인터프리터의 단점을 보완하기 위해 도입된 방식으로 바이트 코드 전체를 컴파일하여 바이너리 코드로 변경하고 이후에는 해당 메서드를 더이상 인터프리팅 하지 않고, 바이너리 코드로 직접 실행하는 방식입니다. 하나씩 인터프리팅하여 실행하는 것이 아니라 바이트 코드 전체가 컴파일된 바이너리 코드를 실행하는 것이기 때문에 전체적인 실행속도는 인터프리팅 방식보다 빠릅니다.

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

JVM의 메모리 영역은 크게 메소드, 스택, 힙 영역으로 나눌 수 있습니다. 그중에 Stack영역 에는 heap 영역에 생성된 Object 타입의 데이터들에 대한 참조를 위한 값들이 할당됩니다. 또한, 원시타입(primitive types) - byte, short, int, long, double, float, boolean, char 타입의 데이터들이 할당됩니다. 메소드를 호출하면 내부에 선언된 지역변수들이 스택 영역에 생성되게 되고, 메소드 호출이 끝나면 해당 지역변수들은 스택영역에서 소멸하게 됩니다.

heap영역은 개발자가 선언한 데이터의 인스턴스 정보들이 담겨있는 영역입니다. 이 데이터들은 따로 관리하지 않아도 참조하는 변수가 없어 접근이 불가능해 진다면, JVM의 GC에 의해 소멸되게 됩니다. 힙 영역은 내부가 크게는 Young 영역과 Old 영역으로 나누어져있고, Old영역은 참조가 오랬동안 유지되어 온 인스턴스들이 존재하고 young 영역에는 생성된지 얼마 되지 않은 인스턴스들이 존재합니다. young 영역은 eden영역과 servial영역으로 나누어지는데 eden영역은 새로 생성된 인스턴스들이 위치하고, GC가 일어난 후 삭제되지 않고 살아남은 인스턴스들은 servial영역으로 이동하게 됩니다.

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

클래스는 간단히 말해서 붕어빵 틀 같이 인스턴스를 생성하는 설계도이고, 인스턴스는 붕어빵 자체 즉, 실존하는 객체를 의미합니다.

9. Garbage Collector의 역할, 원리, 알고리즘에 대해 아는 만큼 설명해주실 수 있을까요?

GC는 메모리 관리 기법중 하나로, 프로그램이 동적으로 할당했던 메모리 영역 중에서 필요 없게 된 영역을 해제해 줍니다.

GC는 JVM의 메모리 영역중 Heap 영역에서 일어나게 되는데, Heap영역은 Young,Old 두가지 영역으로 나누어지게 됩니다. 이렇게 영역이 나누어지게 된 이유는 객체는 대부분 일회성이고, 메모리에 오래 남아있는 경우가 드물기 때문입니다. 새롭게 생성된 객체는 Young 영역에 저장되고, Young 영역에서 일어나는 GC를 Minor GC라고 하기도 합니다. Young영역은 Eden 영역과 2개의 survival영역으로 나누어집니다. MinorGC는 eden영역이 가득 차면 실행되게 되고, GC이후 살아남은 객체들은 age가 늘어나면서 survival영역을 번갈아가며 이동하게 됩니다. 어느정도 age가 쌓이게 되면 해당 객체들은 old영역으로 넘어가게 됩니다.

Old영역도 마찬가지로 가득 차게되면 GC가 일어나게 되고 이 GC를 Major GC라고 합니다. GC가 일어나는 과정은 크게 두가지로 나눌 수 있는데,

1. Stop the World

• GC를 실행하기 위해서 시스템의 기능을 잠시 멈추는 시간을 의미합니다. Stop the world가 짧을 수록 좋은 성능의 GC라고 할 수 있습니다.

2. Mark and Sweep

• Mark - 삭제대상이되는 가비지 데이터들을 체크합니다.

• Sweep - 체크했던 가비지 데이터들을 삭제합니다.

두가지 과정으로 이루어집니다.

10. Java Map의 내부 구현은 어떻게 이루어져 있을지 추측해보실 수 있을까요?

Hash Map

HashMap은 Hash Table 을 이용하여 만들어졌습니다.

Hash Table은 key 와 value를 저장하며, key를 이용하여 빠르게 데이터를 찾기 위한 자료구조를 가지고 있습니다.

특정 key는 해시 함수를 통하여 bucket에 접근할 수 있는 index로 변환합니다. index를 통하여 bucket에 접근하고, bucket에 맞는 index에 key와 value를 저장합니다.

Tree Map

TreeMap은 Node들의 연결로 이루어져 있습니다. 루트라는 최상위 Node가 존재하고, 부모 Node 와 자식 Node 로 구성되어 있습니다. Node 마다 key 와 value 가 같이 저장되며, key 값을 기준으로 좌측 우측으로 구분하여 저장됩니다.

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

DI는 Dependency Injection로, 하나의 객체가 필요로하는 요소들을 외부에서 주입해주는 것을 의미합니다. 스프링에서 제공하는 DI로는 필드주입, 생성자주입, 수정자 주입, 메소드 주입 등이 있습니다.

IoC는 제어의 역전을 의미합니다. 객체가 내부 변수를 직접 생성하게 된다면 객체가 해당 변수를 제어하고 있게 되지만, 만약 해당 내부 변수를 외부에서 제공해준다면, 제어의 방향이 외부에서 내부로 역전이 일어나게 됩니다. 이것을 IoC라고 합니다.

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

MVC 모델이란 Model View Controller로 어떤 특정한 역할들에 대해 역할분담을 할 때 가이드라인을 제시하는 방법 중 하나입니다.

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

자바 애너테이션(Java Annotation)은 자바 소스 코드에 추가하여 사용할 수 있는 메타데이터의 일종입니다. 보통 @ 기호를 앞에 붙여서 사용하고, JDK 1.5 버전 이상에서 사용 가능하다. 자바 애너테이션은 클래스 파일에 임베디드되어 컴파일러에 의해 생성된 후 자바 가상머신에 포함되어 작동합니다.

어노테이션도 종류가 존재합니다.

• 표준(내장) 어노테이션 : 자바가 기본적으로 제공해주는 어노테이션

  • @Override - 오버라이딩할 때, 메서드의 이름을 잘못적는 실수를 방지해주는 어노테이션
  • @Deprecated - 앞으로 사용하지 않을 것을 권장하는 필드나 메서드에 붙이는 어노테이션
  • @SuppressWarnings- 컴파일러의 경고메세지가 나타나지 않게하는 어노테이션

• 메타 어노테이션 : 어노테이션을 위한 어노테이션

  • @Taget - 어노테이션을 정의할 때, 적용대상을 지정하는데 사용
  • @Retention - 어노테이션이 유지되는 기간을 지정할 때 사용

    • SOURCE : 소스 파일에만 존재.

    • RUNTIME : 클래스 파일에 존재. 실행시에 사용가능

• 사용자정의 어노테이션 : 사용자가 직접 정의하는 어노테이션

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

Spring Security는 기본적으로 여러개의 필터가 이어져 인증 및 인가를 처리하는 구조로 되어있습니다.

Spring Security의 인증 구조는 이런 형태로 이루어져 있습니다.

1.Http request (인증요청)
2. AuthenticationFilter를 거침(여기서는UsernamePasswordAuthenticationFilter).
HttpServletRequest를 인터셉트하여 AuthenticationManager에 Authentication 객체를 만들어 (UsernamePasswordAuthenticationToken) 전달
3. AuthenticationFilter로부터 인증객체 전달 받음.
4. 해당 인증 객체를 통해 인증을 진행하는 AuthenticationProvider를 찾아 인증 객체(UsernamePasswordAuthenticationToken)를 전달하고 인증을 요청
5. 6. 7 Provider에서 Service를 호출하여 UserDetails를 통해 인증을 진행( DB 데이터 조회 및 검증 )
8. 9 .10 인증 성공시 사용자 데이터가 담긴 Authentication 객체를 SecurityContextHolder에 저장하고 AuthenticationSuccessHandle를 실행. (실패시 AuthenticationFailureHandler 실행)

JWT가 발급되는 과정은 아래와 같습니다.

처음 로그인을 시도하고 유저정보 인증에 성공하면, 서버에서 사용자가 인증토큰을 관리하도록 JWT를 쿠키나 헤더에 담아 반환해줍니다.

JWT를 발급해주는 서버는 JWT Secretkey를 가지고 있습니다. 해당 키를 가지고 있어야 JWT를 생성하고, 인증할 수 있게 됩니다.

15. N+1 문제의 발생 이유와 해결 방법에 대해 설명해주실 수 있을까요? 해결 방법은 3가지 이상 말씀해주시면 좋습니다.

N+1 문제는 1개의 데이터를 조회했을 때, 그 개수만큼(N) 쿼리가 날아가 데이터를 조회해 오면서 발생하는 문제입니다. 보통 즉시로딩으로 일대다 관계의 데이터를 조회하거나, 지연로딩으로 조회한 데이터와 연관된 데이터를 사용할 때 추가적으로 조회해오면서 발생하게 됩니다.

해결방법으로는

1. Fetch Join 사용

JPQL (Java Persistence Query Language)로 쿼리를 작성할 때, JOIN FETCH를 사용하면 관련 엔터티를 함께 가져올 수 있습니다.

관련된 테이블 간의 조인을 사용해서 필요한 모든 데이터를 한 번의 질의로 가져올 수 있습니다. 이 방법을 사용하면 복잡한 질의가 필요할 수 있지만 질의의 수를 크게 줄일 수 있습니다.

2. @EntityGraph 어노테이션 사용

@EntityGraph 의 attributePaths에 쿼리 수행시 바로 가져올 필드명을 지정하면 Lazy가 아닌 Eager 조회로 가져오게 됩니다. Fetch join과 동일하게 JPQL을 사용하여 query 문을 작성하고 필요한 연관관계를 EntityGraph에 설정하면 됩니다.

3. BatchSize 설정

application.yml에서 Batchsize를 설정해주거나, @BatchSize 어노테이션을 이용하여 설정해주면, 연관된 엔티티를 조회할 때 지정된 size 만큼 SQL의 IN절을 사용해서 조회하게 됩니다.

16. 즉시로딩과 지연로딩은 각각 언제 사용하면 좋은지 설명해주실 수 있을까요?

즉시로딩 (Eager Loading)

• 즉시로딩은 조회시 관련된 모든 데이터를 한 번에 로드하는 방식입니다. JPA에서는 일대일, 다대일관계일 경우 기본적으로 즉시로딩을 수행합니다. 주로 관련된 데이터가 항상 함께 사용되는 경우 유용합니다.

• 그러나 프로젝트의 규모가 커지면서 데이터들의 연관관계가 복잡해 질 경우 쿼리가 예상하지 못한 형태로 날아갈 수 있기에 주의해야 합니다.

지연로딩 (Lazy Loading)

• 지연로딩은 조회시 해당 객체와 연관된 데이터들을 프록시 객체로 가져와 임시로 담아두고, 해당 데이터를 호출할 경우 추가적으로 쿼리문을 DB에 날려 데이터를 가져오는 방식입니다.

• 많은 양의 데이터를 로드하지 않고 필요한 데이터만 로드하므로, 메모리 사용을 최적화할 수 있습니다.

• 일대다 또는 다대다 관계에서는 지연로딩이 기본적으로 사용됩니다.

• 지연로딩은 N+1 문제를 발생시킬 수 있기에 즉시로딩이 더 좋은 방법으로 보이지만, 지연로딩으로 데이터를 불러오고, 추가적으로 사용될 데이터는 fetch join을 사용해 함께 불러오는것이 더 나은 방법이라고 알고 있습니다.

17. Spring bean container 생성부터 스프링 종료까지의 사이클에 대해 알려주실 수 있을까요? @PostConstruct, @PreDestroy 어노테이션의 역할도 함께 알려주시면 좋습니다.

스프링이 시작되어 스프링 컨테이너가 생성되면 크게 아래와 같은 흐름으로 흘러갑니다.

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용(메소드 호출) -> 소멸전 콜백 -> 스프링 종료

1. 스프링 IoC 컨테이너가 생성되고, @Component, @Bean을 통해 스프링 빈들을 생성합니다.

2. 스프링 빈들의 의존관계에 맞게 의존관계를 주입해 줍니다.

3. 이후 스프링 빈들마다 지정해두었던 초기화 코드가 실행됩니다.

4. 스프링이 종료되기 전에 스프링 빈들은 소멸전 코드를 실행시키고 소멸하며 스프링이 종료됩니다.

초기화 콜백, 소멸전 콜백 지정 방법 3가지

1. 인터페이스(InitiallizingBean, DisposableBean) -비추천
2. @Bean(initMethod, DestroyMethod) - 외부 라이브러리의 경우 사용
3. @PostConstruct, @PreDestory - 추천

@PostConstruct - 스프링 빈 생성 이후, 의존관계 주입 이후 호출할 초기화 코드를 지정할 수 있습니다.

@PreDestroy - 스프링 빈 소멸 직전에 호출할 코드들을 지정할 수 있습니다.

• 위의 콜백 방식은 스프링에서 가장 권장하는 방법입니다.
• 자바 표준 기술이어서 스프링이 아닌 다른 컨테이너에서도 동작합니다.
• 컴포넌트 스캔과 잘 어울립니다.
• 유일한 단점은 외부 라이브러리에는 적용하지 못합니다. 외부라이브러리의 경우 @Bean(initMethod ="", destory="")설정정보 기능을 사용해서 처리 가능합니다.

18. AOP, Interceptor, Filter 의 차이점, Request가 들어올때 거치는 순서, 각 역할들의 장점을 설명해주실 수 있을까요?

Filter와 Interceptor는 서블릿 단위에서 실행되고, AOP는 메소드 앞에서 proxy의 형태로 수행한다는 차이점이 있습니다.

Request가 들어온다면 Filter -> Interceptor -> AOP -> Interceptor -> Filter 순으로 거치게 됩니다.

각 역할들의 장점

Filter- 스프링 컨텍스트 외부에 존재하여 스프링과 무관한 자원에 대해 동작합니다. 필터는 DispatcherServlet 이전에 실행이 되는데 필터가 동작하도록 지정된 자원의 앞단에서 요청내용을 변경하거나, 인증, 인가 등의 여러가지 체크를 수행할 수 있습니다. 또한 자원의 처리가 끝난 후 응답내용에 대해서도 변경하는 처리를 할 수 있습니다.

Interceptor- 인터셉터는 스프링의 DistpatcherServlet이 컨트롤러를 호출하기 전, 후로 끼어들어 스프링 영역 내부에서 Controller에 관한 요청과 응답에 대해 처리합니다. 인터셉터를 활용하여 인증, 인가 , 프로그램 수행 시간 등을 체크할 수 있습니다.

AOP - 메소드 전후의 지점에 자유롭게 설정이 가능하고, 포인트 컷을 활용하여 원하는 모듈을 원하는 메소드에 지정해줄 수 있습니다. 또한 여러개의 메소드에 공통적으로 사용되는 기능을 하나의 모듈로 묶어 코드의 중복을 줄일 수 있습니다.

19. NoSQL과 RDBMS의 특징과 차이점에 대해서 장, 단점을 들어 설명해주세요.

RDBMS는 관계형 데이터베이스 관리 시스템을 의미합니다. 이름과 같이 RDBMS는 RDB를 관리하는 시스템이며 RDB는 관계형 데이터 모델을 기초로 두고 모든 데이터를 여러개의 속성(column)을 가진 2차원 테이블 형태로 표현하는 데이터베이스입니다. RDBMS는 SQL(Structured Query Language)를 통해 데이터를 관리합니다.

NoSQL(Not Only SQL)은 RDB와 다른 형태로 데이터를 저장합니다.RDBMS와는 다르게 테이블 간 관계를 정의하지 않습니다.데이터 테이블은 그냥 하나의 테이블이고, 일반적으로 테이블간 Join도 불가능 합니다.

빅데이터의 등장으로 데이터와 트래픽이 기하급수적으로 증가함에 따라 RDBMS의 단점인 성능을 향상시키기 위해 등장했습니다. 데이터의 일관성은 포기하되, 비용을 고료하여 여러대의 데이터에 분산하여 저장하는 Scale-Out을 목표로 등장했습니다.

RDBMS와 NoSQL의 장단점

RDBMS

장점

• 정해진 스키마에 따라 데이터를 저장하여야 하므로 명확한 데이터 구조를 보장.
• 또한 각 데이터를 중복없이 한 번만 저장할 수 있음.

단점

• 테이블 간 관계를 가지고 있어 시스템이 커질경우 Join문이 많은 복잡한 쿼리가 만들어 질 수 있음.
• 스키마로 인해 데이터가 유연하지 못하다. 나중에 스키마가 변경 될 경우 번거롭고 어렵다.

NoSQL

장점

• 스키마가 없기 때문에 유연하고 자유로운 데이터 구조를 가진다.
• 언제든 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있다.

단점

• 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경 될 경우 수정을 모든 컬렉션에서 해야함.
• 스키마가 존재하지 않아 명확한 데이터 구조를 보장하지 않는다.

RDBMS, NoSQL 언제 사용해야 할까?

RDBMS는 데이터 구조가 명확하여 변경될 여지가 없고, 관계를 맺고있는 데이터가 자주 변경이 이루어지는 시스템에 적합합니다.

NoSQL은 정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우 사용하는 것이 좋습니다. 중복된 데이터를 변경할 때에는 모든 컬렉션에서 수정을 해야 하기에 Update 가 많이 이루어지지 않는 시스템에 좋습니다.

20. mvc 패턴에 대해서 설명해주세요.

MVC 란

MVC 는 Model, View, Controller의 약자 입니다. 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴입니다.

MVC에서 모델은 애플리케이션의 정보(데이터)를 나타내며, 뷰는 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, 컨트롤러는 데이터와 비즈니스 로직 사이의 상호동작을 관리합니다.

21. RDBMS의 정규화에 대해 설명해주세요.

DB를 잘못 설계하면 불필요한 데이터 중복이 발생하여 릴레이션에 대한 데이터의 삽입,삭제,수정 연산을 수행할 때 부작용이 발생할 수 있습니다. 이러한 부작용을 이상(anomaly)현상이라고 하고, 이러한 이상 현상을 제거하면서 데이터베이스를 올바르게 설계해 나가는 과정이 정규화 입니다.

22. Primary Key, Foreign Key에 대해 설명해주세요.

릴레이션에서 튜플을 구분하기 위해 후보키들중 하나를 선택해야하는데 이것이 기본키 입니다. 후보키가 1개라면 이것을 기본키로 선택해야겠지만, 여러개라면 환경을 고려하여 적합한 것을 기본키로 선택하면 됩니다.

외래키는 다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합입니다. 외래키는 릴레이션들 사이의 관계를 올바르게 표현하기 위해 필요합니다. 외래키는 반드시 다른 릴레이션의 기본키를 참조해야하며, 외래키의 도메인은 참조되는 기본키와 같게 정의되어야 합니다.

23. HTTP 메서드에 대해 설명해주세요.

HTTP 메서드란 클라이언트와 서버 사이에 이루어지는 요청(Request)과 응답(Response) 데이터를 전송하는 방식을 말합니다. 서버에 주어진 리소스에 수행하길 원하는 행동, 서버가 수행해야 할 동작을 지정하는 요청을 보내는 방법이다.

HTTP 메소드에는 9가지 종류가 존재합니다. 5개는 익숙하지만 4개는 써보지 않은 메소드들 입니다.

주요 메소드

GET : 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT : 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성
PATCH : 리소스 부분 변경 (PUT이 전체 변경, PATCH는 일부 변경)
DELETE : 리소스 삭제

기타 메소드

HEAD : GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

24. CORS(Cross Origin Resource Sharing)에 대해 설명해주세요.

브라우저에서는 보안적인 이유로 다른 사이트에 요청을 보내는 cross-origin HTTP 요청들을 제한합니다. 그래서 cross-origin 요청을 하려면 서버의 동의가 필요합니다. 만약 서버가 동의한다면 브라우저에서는 요청을 허락하고, 동의하지 않는다면 브라우저에서 거절합니다.

이러한 허락을 구하고 거절하는 메커니즘을 HTTP-header를 이용해서 가능한데, 이를 CORS(Cross-Origin Resource Sharing)라고 부릅니다.

cross-origin

cross-origin이란 다음 중 한 가지라도 다른 경우를 말합니다.

프로토콜 - http와 https는 프로토콜이 다르다.
도메인 - domain.com과 other-domain.com은 다르다.
포트 번호 - 8080포트와 3000포트는 다르다.

25. 브라우저의 작동방식에 대해서 설명해주세요.

브라우저는 상단 주소 표시줄에 접속하기 원하는 서버의 도메인에 요청을 보내게 되면, DNS에서 도메인이 가지는 IP주소를 알려주고 IP주소에 해당하는 물리적 서버에 요청이 날아간 후 응답이 브라우저로 도착하면 브라우저는 해당 응답을 렌더링해서 클라이언트에게 보여주게 됩니다.

26. 쿠키, 세션의 개념과 차이를 설명해보세요

쿠키

• 클라이언트로컬에 저장되는 키와 값이 들어있는 데이터 파일

• 사용자 인증이 유효한 시간을 명시 가능, 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징

• 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Header에 넣어서 자동으로 서버에 전송

세션

• 쿠키를 기반으로 하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 다르게, 서버 측에서 세션을 관리

• 서버에서는 클라이언트를 구분하기 위해 세션ID를 부여하여 쿠키를 통해 이를 인증

27. TCP/UDP에 대해서 설명해주세요.

TCP, UDP 는 TCP/IP 모델의 전송 계층 에서 사용하는 프로토콜 입니다.

TCP, UDP 모두 패킷을 한 컴퓨터에서 다른 컴퓨터로 전달해주는 IP 프로토콜을 기반으로 구현되어있습니다.

TCP는 Transmission Control Protocol의 약자입니다. 네트워크에 연결된 컴퓨터에서 실행되는 프로그램 간의 데이터를 안정적으로, 순서대로 교환하게 해줍니다. TCP는 연속성보다 신뢰성이 있는 전송이 중요할 때 사용하는 프로토콜입니다.

UDP는 User Datagram Protocol의 약자입니다.여기서 Datagram은 독립적인 관계를 지니는 패킷을 뜻합니다.즉, 각각의 패킷이 독립적이기 때문에 패킷마다 서로 다른 경로로 독립적으로 처리하게 됩니다. UDP는 신뢰성보다 연속성이 있는 전송이 중요할 때 사용하는 프로토콜입니다.

28. http, https 차이점에 대해 설명해주세요

HTTP(Hypertext Transfer Protocol)는 클라이언트와 서버 간 통신을 위한 통신 규칙 세트 또는 프로토콜입니다. 사용자가 웹 사이트를 방문하면 사용자 브라우저가 웹 서버에 HTTP 요청을 전송하고 웹 서버는 HTTP 응답으로 응답합니다. 웹 서버와 사용자 브라우저는 데이터를 일반 텍스트로 교환합니다. 간단히 말해 HTTP 프로토콜은 네트워크 통신을 작동하게 하는 기본 기술입니다. 이름에서 알 수 있듯이 HTTPS(Hypertext Transfer Protocol Secure)는 HTTP의 확장 버전 또는 더 안전한 버전입니다. HTTPS에서는 브라우저와 서버가 데이터를 전송하기 전에 안전하고 암호화된 연결을 설정합니다.

HTTPS 웹 사이트는 독립된 인증 기관(CA)에서 SSL/TLS 인증서를 획득해야 합니다. 이러한 웹 사이트는 신뢰를 구축하기 위해 데이터를 교환하기 전에 브라우저와 인증서를 공유합니다. SSL 인증서는 암호화 정보도 포함하므로 서버와 웹 브라우저는 암호화된 데이터나 스크램블된 데이터를 교환할 수 있습니다.

29. DI, IoC에 대해 설명해주세요.

DI(Dependency Injection)란 객체를 직접 생성하는 게 아니라 외부에서 생성한 후 주입 시켜주는 방식입니다.

DI(의존성 주입)를 통해서 모듈 간의 결합도가 낮아지고 유연성이 높아집니다.

스프링 컨테이너에서 DI를 하는 방법은 여러가지가 있는데, 대표적으로 생성자 주입, 메소드 주입, 필드 주입 등이 있습니다.

IoC(Inversion of Controll)는 구현체를 직접 생성해서 사용하고 있었다면, 외부로부터 구현체를 입력 받는 것 입니다.

30. 객체지향 프로그래밍이란 무엇이고 어떻게 활용할 수 있나요?

객체 지향 프로그래밍은 컴퓨터 프로그래밍 패러다임 중 하나로, 프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체를 만들고 그 객체들 간의 유기적인 상호작용을 통해 로직을 구성하는 프로그래밍 방법이다.

31. 대용량 트래픽 발생 시 어떻게 대응해야 하나요?

• 로드 밸런서를 이용하여 여러대의 서버가 분산 처리하도록 합니다.

• 클라우드 서비스 제공 업체의 오토 스케일링 기능(서버의 부하를 체크하여 서버를 생성하는 방식)을 사용해 봅니다.

• 데이터 베이스 샤딩을 적용(DB 테이블을 수평 분할하여 물리적으로 서로 다른곳에 분산 저장)

• 데이터베이스 레플리카 적용

• 서버를 스케일 업합니다.

• 정적 컨텐츠에 대해 CDN 서비스를 이용하여 컨텐츠 다운 시간을 단축시킵니다.

• API의 응답속도를 단축시키위해 코드를 리팩토링해봅니다.

32. ORM을 사용하면서 쿼리가 복잡해지는 경우에는 어떻게 해결하는게 좋을까요?

• 일단 JPA 자체는 정적인 상황에서 사용하는걸 권장하기 때문에 복잡한 쿼리와 동적인 쿼리에 대한 문제가 발생하게 되는데, 그럴때는 JPQL과 Querydsl을 사용할 것을 권장하고 있습니다.

33. GET, POST의 개념과 함께 데이터 흐름에 대해서 설명해주세요.

GET 메서드:

• GET 메서드는 정보를 서버로부터 요청하는 데 사용됩니다. 주로 데이터의 조회 및 검색과 관련이 있습니다.

• 데이터는 URL 파라미터를 통해 전송됩니다. 예를 들어, https://example.com/resource?param1=value1¶m2=value2와 같은 형태로 데이터가 전달됩니다.

• 데이터는 URL의 일부이므로 브라우저 히스토리에 저장되며 북마크할 수 있습니다.

• GET 요청은 캐싱할 수 있으며, 요청이 반복될 때 동일한 결과를 반환하기 때문에 멱등(idempotent)한 특성을 가집니다.

POST 메서드:

• POST 메서드는 데이터를 서버로 제출하는 데 사용됩니다. 주로 데이터의 생성, 업데이트 및 삭제와 관련이 있습니다.

• 데이터는 HTTP 요청 본문(body)에 포함되며, URL에 직접 노출되지 않습니다. 이로써 데이터는 안전하게 전송됩니다.

• POST 요청은 데이터의 길이나 형태에 제한이 없으며, 파일 업로드와 같이 큰 데이터를 전송할 때 사용됩니다.

• POST 요청은 캐싱할 수 없으며, 요청이 반복될 때 다른 결과를 반환하기 때문에 멱등하지 않은(non-idempotent) 특성을 가집니다.

데이터 흐름

• 클라이언트(웹 브라우저 또는 다른 클라이언트 애플리케이션)는 HTTP GET 또는 POST 요청을 생성합니다.

• GET 요청의 경우, 데이터는 URL에 쿼리 문자열로 포함됩니다. POST 요청의 경우, 데이터는 HTTP 요청 본문에 포함됩니다.

• 요청된 데이터와 함께 요청 헤더와 메서드(GET 또는 POST) 등의 메타데이터가 포함된 HTTP 요청이 서버로 전송됩니다.

• 서버는 요청을 수신하고, 해당 요청을 처리합니다.

• GET 요청의 경우, 서버는 데이터를 응답의 일부로 다시 클라이언트로 전송합니다. POST 요청의 경우, 서버는 요청에 대한 응답을 생성하고 다시 클라이언트로 보냅니다.

• 클라이언트는 서버로부터 받은 데이터를 해석하고 원하는 방식으로 표시하거나 처리합니다.

34. OSI 7계층에 대해 아는대로 설명해주세요.

1. 물리 계층 (Physical Layer):

물리적인 데이터 전송을 담당합니다. 케이블, 스위치, 허브 등의 하드웨어 디바이스와 관련이 있습니다.

데이터 비트를 전송하고 신호를 변환하는 역할을 합니다.

2. 데이터 링크 계층 (Data Link Layer):

물리 계층에서 송수신된 데이터를 프레임(frame)으로 분할하고, 오류 검출 및 수정을 수행합니다.

MAC 주소를 사용하여 로컬 네트워크 내에서의 데이터 전송을 관리합니다.

스위치 등의 장비가 이 계층에서 동작합니다.

3. 네트워크 계층 (Network Layer):

데이터 패킷(packet)의 경로 선택 및 라우팅을 담당합니다.

IP 주소를 사용하여 패킷을 목적지까지 전달하며, 서브넷 간의 통신을 지원합니다.

라우터가 이 계층에서 동작합니다.

4. 전송 계층 (Transport Layer):

데이터 전송의 신뢰성과 정확성을 관리하며, 데이터의 오류 복구와 흐름 제어를 수행합니다.

포트 번호를 사용하여 프로세스 간의 통신을 지원하며, TCP와 UDP 프로토콜이 이 계층에서 동작합니다.

5. 세션 계층 (Session Layer):

세션의 설정, 유지, 종료를 관리하며, 데이터 교환을 동기화합니다.

다른 시스템 간의 다중 작업 및 동시성을 관리합니다.

6. 표현 계층 (Presentation Layer):

데이터를 응용 프로그램이 이해할 수 있는 형식으로 변환하고, 데이터 압축, 암호화, 인코딩 등의 작업을 수행합니다.

데이터 형식 및 문법 변환을 제공합니다.

7. 응용 계층 (Application Layer):

최종 사용자와 응용 프로그램 간의 상호 작용을 지원합니다.

프로토콜, 데이터 전송 및 응용 프로그램 인터페이스를 포함하여 다양한 응용 프로그램 서비스를 제공합니다.

각 계층은 그 자체로 독립적이며, 상위 계층은 하위 계층의 서비스를 활용하여 데이터를 처리하고 전달합니다. 이러한 계층화 구조를 통해 서로 다른 하드웨어 및 소프트웨어 시스템 간의 통신을 효과적으로 관리하고, 상호 운용성을 확보할 수 있습니다. 이 모델은 컴퓨터 네트워크 및 통신 시스템의 설계와 이해에 중요한 도구로 사용됩니다.

35. 세션 기반 인증과 토큰 기반 인증의 차이에 대해 설명해주세요.

세션 기반 인증(Session-Based Authentication):

1. 서버 측 저장: 세션 기반 인증은 사용자 인증 정보(예: 로그인 상태)를 서버 측에 저장하고 관리합니다. 일반적으로 서버는 사용자 세션을 유지하기 위해 메모리나 데이터베이스에 정보를 저장합니다.

2. 쿠키 사용: 일반적으로 세션 ID가 쿠키를 통해 클라이언트에게 전달됩니다. 클라이언트는 이 세션 ID를 요청 헤더에 포함하여 서버에 요청을 보냅니다. 서버는 세션 ID를 확인하고 해당 세션에 연결된 사용자 정보를 검색합니다.

3. 서버 측 유지: 세션은 서버 측에서 유지되므로 클라이언트는 세션에 대한 관리나 저장을 하지 않습니다. 이는 클라이언트에게 상대적으로 덜 부담을 주는 장점일 수 있습니다.

4. 로그아웃 및 세션 관리: 로그아웃은 서버 측에서 관리되며, 세션의 만료 시간을 설정하여 세션 관리가 가능합니다.

토큰 기반 인증(Token-Based Authentication):

1. 서버 측 저장 없음: 토큰 기반 인증에서는 서버 측에 사용자 정보를 저장하지 않습니다. 사용자 정보는 토큰 자체에 포함되어 있거나, 토큰이 서버 측에서 검증될 수 있는 정보를 가지고 있습니다.

2. 토큰 사용: 사용자는 인증 후 서버로부터 토큰을 받습니다. 이 토큰은 일반적으로 클라이언트 측에 저장됩니다(로컬 저장소, 쿠키, 브라우저 메모리 등).

3. 클라이언트 측 유지: 토큰은 클라이언트 측에서 유지되며, 클라이언트는 토큰을 서버에 제공하여 자격 증명을 확인합니다.

4. 로그아웃 및 토큰 관리: 로그아웃 및 토큰 만료는 클라이언트와 서버 간의 상호작용으로 이루어집니다. 토큰에는 유효 기간을 설정할 수 있어서 클라이언트 측에서 관리됩니다.

차이점 요약:

• 세션 기반 인증은 서버 측에서 사용자 정보를 관리하고, 클라이언트는 세션 ID만 가지고 있습니다. 토큰 기반 인증은 클라이언트가 사용자 정보를 가지고 있으며, 서버는 토큰의 유효성을 확인합니다.
• 세션은 서버 측에서 유지되고 관리되며, 로그아웃 및 세션 관리는 서버가 처리합니다. 토큰은 클라이언트 측에서 유지되며, 로그아웃 및 토큰 관리는 클라이언트와 서버 간의 협력으로 이루어집니다.
• 토큰 기반 인증은 RESTful API 및 분산 시스템에서 더 유용하며, 클라이언트가 다양한 서버로 분산되는 경우에도 잘 동작합니다. 세션 기반 인증은 전통적인 웹 응용 프로그램에서 더 일반적으로 사용됩니다.

36. JWT, Refresh, Access Token에 대해서 설명해주세요.

1. JWT (JSON Web Token):

   • JWT는 웹 및 네트워크 보안에서 토큰 기반 인증을 구현하는 데 사용되는 컴팩트하고 자체 수용 가능한 방식의 토큰입니다.
   • JWT는 JSON 형식으로 인코딩되며, 주로 사용자 인증 정보와 클레임(claim) 정보(예: 사용자 ID, 만료 시간, 권한 등)를 포함합니다.
   • JWT는 서버에서 서명되어 있어 변경되지 않도록 보장되며, 클라이언트에서 서버로 전달됩니다.
   • JWT는 주로 웹 애플리케이션 및 API에서 사용자 인증 및 권한 부여에 활용됩니다.

2. Access Token:

   • Access Token은 사용자를 대표하여 API 또는 서비스에 접근하는 데 사용되는 토큰입니다.
   • 주로 OAuth 2.0 및 OpenID Connect와 같은 프로토콜에서 사용되며, 사용자가 자원에 접근할 권한을 부여하고 인증하는 데 사용됩니다.
   • Access Token은 일반적으로 JWT 또는 다른 형식의 토큰일 수 있으며, 일반적으로 짧은 유효 기간을 갖습니다.

3. Refresh Token:

   • Refresh Token은 Access Token을 갱신하거나 재발급하는 데 사용되는 특수한 토큰입니다.
   • Access Token은 일반적으로 유효 기간이 짧기 때문에, Refresh Token을 사용하여 Access Token을 주기적으로 갱신할 수 있습니다.
   • Refresh Token은 주로 보안을 강화하고, 만료된 Access Token을 대체하기 위해 사용됩니다.
   • Refresh Token은 일반적으로 Access Token과는 별도로 저장 및 보호되며, 더 긴 유효 기간을 가질 수 있습니다.

37. OAuth에 대해서 설명해주세요.

OAuth(Open Authorization)는 인터넷을 통해 다른 웹 서비스 또는 애플리케이션에 대한 제한된 액세스 권한을 부여하기 위한 권한 부여 프레임워크입니다. OAuth는 사용자 또는 서비스 소유자의 동의를 기반으로 다른 서비스 또는 애플리케이션에 대한 인증 및 권한 부여를 가능하게 합니다. OAuth는 다양한 웹 서비스 및 API에서 사용자 인증 및 권한 부여를 구현하는 데 널리 사용됩니다.

OAuth의 핵심 요소와 개념은 다음과 같습니다:

1. 인증 서버(Authentication Server): OAuth 프로토콜을 사용하는 애플리케이션은 사용자 인증을 위해 인증 서버에 의존합니다. 인증 서버는 사용자를 식별하고 인증을 수행합니다.

2. 클라이언트(Client): OAuth를 사용하는 웹 애플리케이션 또는 서비스를 클라이언트라고 합니다. 클라이언트는 사용자의 데이터에 액세스하려는 애플리케이션을 나타냅니다.

3. 리소스 서버(Resource Server): 사용자 데이터 또는 서비스에 대한 액세스가 필요한 서버 또는 API를 리소스 서버라고 합니다.

4. 리소스 소유자(Resource Owner): 리소스 서버의 데이터를 소유하거나 제어하는 사용자를 리소스 소유자라고 합니다.

5. 액세스 토큰(Access Token): OAuth 프로세스를 통해 클라이언트가 리소스 서버에 액세스하기 위한 권한을 부여하는 토큰입니다. 이 토큰은 제한된 권한을 가지며, 유효 기간이 제한되어 있습니다.

OAuth 프로세스는 다음과 같은 단계로 진행됩니다:

1. 애플리케이션 등록: 클라이언트 애플리케이션은 OAuth 프로토콜을 사용하기 위해 인증 서버 및 리소스 서버와 등록합니다.

2. 사용자 인증 및 권한 부여: 클라이언트는 사용자를 인증하기 위해 인증 서버로 리다이렉트하고, 사용자는 자신의 자격 증명으로 인증합니다. 그러면 사용자가 액세스할 수 있는 리소스의 범위를 선택하고, 권한을 부여합니다.

3. 액세스 토큰 요청: 인증이 성공하면 클라이언트는 액세스 토큰을 요청합니다. 이 요청은 권한 코드(authorization code)나 리소스 소유자의 자격 증명(비밀 번호)을 사용하여 이루어질 수 있습니다.

4. 액세스 토큰 발급: 인증 서버는 클라이언트에게 액세스 토큰을 발급합니다.

5. 액세스 토큰을 사용한 리소스 서버 액세스: 클라이언트는 액세스 토큰을 사용하여 리소스 서버에 액세스하고, 사용자의 데이터나 서비스를 요청합니다.

OAuth는 클라이언트가 사용자의 비밀 정보를 저장하거나 전달하지 않도록 하며, 사용자가 클라이언트 애플리케이션에 대한 제어를 유지하면서 다른 서비스와 상호작용할 수 있는 표준 방법을 제공합니다. 이것은 많은 웹 및 모바일 애플리케이션에서 소셜 미디어 로그인, API 액세스 및 권한 부여 등에 사용됩니다.

38. HTTP 상태코드에 대해서 설명해주세요.

HTTP(하이퍼텍스트 전송 프로토콜) 상태 코드는 웹 서버가 클라이언트에게 반환하는 3자리 숫자 코드입니다. 이 코드는 클라이언트에게 현재 요청의 결과를 나타내며, 클라이언트와 서버 간의 통신에서 중요한 역할을 합니다. HTTP 상태 코드는 요청이 성공했는지, 실패했는지, 그리고 실패한 경우 그 이유를 알려줍니다.

HTTP 상태 코드는 다음 세 가지 범주로 나눌 수 있습니다:

1. 1xx (Informational - 정보): 요청이 받았으며 처리 중임을 나타내는 상태 코드입니다. 실제 응답은 아직 도착하지 않은 상태이며, 클라이언트는 기다려야 합니다.

2. 2xx (Successful - 성공): 요청이 성공적으로 처리되었음을 나타내는 상태 코드입니다. 가장 흔한 상태 코드는 200(OK)이며, 요청이 성공했고 클라이언트는 응답을 받습니다.

3. 3xx (Redirection - 리디렉션): 추가 조치가 필요한 경우를 나타내며, 요청을 다른 위치로 리디렉트해야 합니다.

4. 4xx (Client Error - 클라이언트 오류): 요청에 오류가 있거나 요청을 처리할 수 없는 경우를 나타내는 상태 코드입니다. 예를 들어, 404(Not Found)는 요청한 리소스를 찾을 수 없음을 의미합니다.

5. 5xx (Server Error - 서버 오류): 서버가 요청을 처리하는 동안 오류가 발생한 경우를 나타내는 상태 코드입니다. 예를 들어, 500(Internal Server Error)는 서버에서 내부 오류가 발생했음을 의미합니다.

39. CI/CD에 대해서 설명해주세요.

CI/CD는 소프트웨어 개발 및 배포 프로세스를 자동화하고 향상시키기 위한 개념과 방법론을 나타내는 용어입니다. CI는 "지속적인 통합(Continuous Integration)"의 약자이며, CD는 "지속적인 전달(Continuous Delivery)" 또는 "지속적인 배포(Continuous Deployment)"의 약자입니다. 이 두 가지 개념은 소프트웨어 개발 및 배포의 효율성과 품질을 향상시키는 데 중요한 역할을 합니다.

1. 지속적인 통합(CI - Continuous Integration):

   • CI는 개발자가 코드를 작성하고 변경 사항을 공유 코드 저장소(예: Git)에 푸시할 때 자동으로 통합 및 테스트되는 개발 프로세스를 나타냅니다.
   • CI 시스템은 코드 통합 후 자동화된 빌드 및 테스트를 실행하여 코드 변경 사항의 품질을 확인합니다.
   • 이로 인해 개발자는 빈번한 코드 통합과 품질 향상을 달성할 수 있으며, 잠재적인 버그 및 충돌을 조기에 발견하게 됩니다.

2. 지속적인 전달(CD - Continuous Delivery):

   • CD는 소프트웨어를 프로덕션 환경으로 자동으로 전달하고, 프로덕션 배포를 수동으로 승인하는 프로세스를 나타냅니다.
   • CI와 함께 CD는 빌드, 테스트, 패키징 및 프로덕션 환경으로 배포를 자동화합니다.
   • CD를 통해 개발된 소프트웨어는 프로덕션 준비 상태로 계속 전달되므로, 릴리즈 버전의 배포를 언제든 수행할 수 있습니다.

3. 지속적인 배포(CD - Continuous Deployment):

   • CD의 한 단계로, 소프트웨어 변경 사항이 테스트 및 스테이징 환경을 통과하면 자동으로 프로덕션 환경으로 배포됩니다.
   • 사용자의 승인 없이 프로덕션 배포가 이루어집니다.
   • 이 방식은 클라우드 환경 및 웹 기반 서비스에서 많이 사용되며, 지속적인 혁신과 배포 속도를 향상시킵니다.

40. TDD에 대해서 설명해주세요.

TDD(Test-Driven Development)는 소프트웨어 개발 방법론 중 하나로, 개발자가 소프트웨어를 개발할 때 테스트를 먼저 작성하고, 그 다음에 코드를 작성하는 접근 방식을 강조하는 방법론입니다. TDD는 다음 세 가지 주요 단계를 따릅니다:

1. 테스트 작성 단계 (Red - 빨강):

   • 먼저, 새로운 기능 또는 모듈을 개발하기 전에 해당 기능 또는 모듈에 대한 테스트 케이스를 작성합니다. 이 단계에서 작성된 테스트 케이스는 아직 구현되지 않은 기능 또는 모듈을 검사하는 역할을 합니다.
   • 이로 인해 테스트는 실패합니다(빨간 불) because the functionality is not yet implemented.

2. 코드 작성 단계 (Green - 초록):

   • 이 단계에서 목표는 테스트를 통과하도록 최소한의 코드를 작성하는 것입니다. 코드 작성은 주로 테스트를 통과시키기 위한 코드 작성에 초점을 맞춥니다. 코드가 아직 완벽하지 않아도 됩니다. 주요 목표는 테스트를 통과하는 것(초록 불)입니다.

3. 리팩터링 단계 (Refactor):

   • 성공한 테스트를 통과한 후, 코드를 개선하고 리팩터링하는 단계입니다. 리팩터링은 코드의 가독성, 효율성 및 유지보수성을 향상시키는 작업을 수행합니다. 이 과정에서 코드의 품질을 높이고 중복을 제거하는 등의 작업을 수행할 수 있습니다.

TDD를 따르면 테스트 케이스는 개발 중에 코드의 예상 동작을 정의하고, 코드 변경 사항이 예상한 대로 동작하는지 확인하는 데 사용됩니다. TDD를 통해 소프트웨어의 안정성과 신뢰성을 향상시키며, 코드 변경에 대한 자신감을 제공하고 버그를 조기에 발견하는데 도움이 됩니다.

TDD는 소프트웨어 개발 프로세스를 단순화하고 개발자들 간의 협업을 촉진하며, 변경 사항이 코드에 영향을 미칠 때 이를 감지하는 데 도움을 줍니다.

41. 프로세스와 쓰레드에 대해서 설명하고 그 차이에 대해서 설명해주세요.

프로세스는 실행중인 프로그램이라고 할 수 있습니다. 그리고 쓰레드는 프로세스 내에서 실행되면서 자원을 공유하는 작은 실행 단위입니다.
예를 들어 라면을 끓이는 프로세스가 돌아가고 있다고 가정하면, 그 내부에서는 물을 받아오는 쓰레드, 라면을 가져오는 쓰레드, 불을 켜는 쓰레드 등 여러개의 쓰레드가 존재할 수 있습니다.

요약하자면, 프로세스는 독립적이고 자체적인 실행 환경을 가지며, 스레드는 같은 프로세스 내에서 실행되면서 자원을 공유하는 작은 실행 단위입니다.

42. 멀티프로세스와 멀티쓰레드의 특징에 대해 설명해주세요.

멀티 프로세스

멀티 프로세스는 각 프로세스들이 독립된 메모리 공간을 가지고 실행되기에 하나의 프로세스에 장애가 발생하더라도 다른 프로세스들에 영향을 미치지 않아 안정적입니다. 또한 프로세스간 통신은 쓰레드간의 통신과 다르게 비용이 많이들고 복잡합니다. 그리고 프로세스는 생성과 소멸하는데 쓰레드보다 상대적으로 많은 시간과 자원이 소요됩니다.

멀티쓰레드

멀티쓰레드는 각 쓰레드들이 하나의 프로세스 안에서 메모리를 공유하며 실행되기 때문에 하나의 쓰레드가 장애가 발생하면, 프로세스 전체가 영향을 받을 수 있습니다. 쓰레드는 프로세스의 자원을 공유하기 때문에 쓰레드들간의 통신이 비교적 간단하지만 동기화 문제 등을 고려해야 합니다. 쓰레드는 생성과 소멸이 프로세스보다 시간과 자원이 적게 듭니다.

43. 쿼리 최적화에 대해 설명해주시고 방법에 대해 설명해주세요.

44. DB 로직 최소화를 하려면 어떻게 해야 할까요?

45. 테스트코드에 대해서 아는대로 설명해주시고 활용 경험에 대해서 답변해주세요.

46. Array, LinkedList에 대해 설명해주시고 각각 어떻게 사용하는지 말씀해주세요.

47. AWS S3, EC2를 사용하는 이유와 사용 경험에 대해서 답변해주세요.

48. 정렬 알고리즘에 대해서 아는대로 설명해주세요.