🧑🏻💻 Session과 Cookie
• Session
- 저장위치 : 웹 서버
- 브라우저를 종료하거나, 서버에서 세션을 삭제했을 때 삭제된다.
- 각 클라이언트에 고유 Session ID를 부여하고, 이 Session ID로 클라이언트를 구분한다.
- 동작순서
1. 클라이언트가 페이지를 요청한다.
2. 서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하고, 클라이언트가 해당 Session ID를 보냈는지 확인한다.
3. Session ID가 존재하지 않는다면, 서버는 Session ID를 생성한 후 클라이언트에게 전달한다.
4. 서버에서 클라이언트로 돌려준 Session ID를 쿠키로 사용하여 서버에 저장한다.
5. 클라이언트 접속 시, 세션 쿠키를 이용하여 Session ID 값을 서버에 전달한다.
• Cookie
- 저장위치 : 클라이언트(=접속자 PC)
- 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다.
- 동작순서
1. 클라이언트가 페이지를 요청한다.
2. 웹 서버는 쿠키를 생성하고 정보를 담은 후 HTTP 화면을 돌려줄 때 같이 클라이언트에게 반환한다.
3. 클라이언트가 이후 서버에 요청할 때 요청과 함께 쿠키를 전송한다.
4. 동일 사이트 재방문 시, 클라이언트의 PC에 해당 쿠키가 있을 경우 요청 페이지와 함께 쿠키를 전송한다.
🧑🏻💻 TCP(Transmission Control Protocol) vs UDP(User Datagram Protoco)
• TCP
- 연결형 서비스를 제공한다.
- 높은 신뢰성을 보장한다.
- 3-way handshaking(연결의 설정), 4-way handshaking(연결의 해제)
• UDP
- 비연결형 서비스를 제공한다.
- 신뢰성이 낮다.
- 데이터의 전송 순서를 보장하지 않는다.
- TCP보다 전송속도가 빠르다.
🧑🏻💻 SSR(Server Side Rendering) vs CSR(Client Side Rendering)
• SSR
- 서버에서 렌더링 후, Data가 결합된 HTML파일을 클라이언트에 전달하는 방식이다.
• CSR
- SSR과 반대로 클라이언트에서 렌더링을 하는 방식이다.
🧑🏻💻 SPA(Single Page Application)
SPA란 서버로부터 새로운 페이지를 불러오지 않고, 현재의 페이지 중 필요한 부분만 동적으로 렌더링 하는 방식이다.
• 장점
- 페이지 로딩속도가 빠르다.
- 사용자 경험이 우수하다.
• 단점
- 최초 페이지 로딩속도가 느리다.
- SEO에 적합하지 않을 수 있다.
🧑🏻💻 MVC1 vs MVC2
• MVC1
- 모든 요청과 응답을 JSP가 담당하는 구조이다.
- JSP페이지 안에서 모든 정보를 표현(View), 저장(Model), 처리(Control)한다.
- 쉽게 구현 가능하나 복잡해지면 유지보수 문제가 발생한다.
• MVC2
- 클라이언트의 요청을 하나의 Servlet이 받아 알맞게 처리한 후 그 결과를 JSP 페이지로 전달한다.
- 클라이언트의 요청, 응답, 비즈니스 로직 처리 부분을 모듈화한 구조이다.
- 처리작업의 분리로 유지보수와 확장에 용이하지만, 구조 설계를 위한 시간 필요하다.
🧑🏻💻 AJAX
• JavaScript의 라이브러리중 하나이며 전체 페이지를 새로 고치지 않고도 페이지의 일부만을 위한 데이터를 로드하는 기술이다.
🧑🏻💻 Spring Framework
자바 엔터프라이즈 개발을 편하게 해주는 경량급 애플리케이션 프레임워크.
• 경량 컨테이너로서 자바 객체를 직접 관리
- 각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다.
• POJO(Plain Old Java Object) 방식의 프레임워크
- 객체지향 원리에 충실하면서, 특정 환경이나 규약에 종속되지 않는 방식으로 설계된 객체를 뜻한다.
- 일반적인 J2EE 프레임워크에 비해 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없어 가볍다.
• DI(Dependency Injection) 지원
- 각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜 준다.
• IoC(Inversion of Control) 지원
- 컨트롤의 제어권이 사용자가 아니라 프레임워크에 있으며, IoC를 통해 애플리케이션의 느슨한 결합을 도모한다.
• AOP(Aspect-Oriented Programming) 지원
- 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능을 분리하여 관리한다.
🧑🏻💻 Spring 처리 과정
- 요청받은 URL을 dispatcher-servlet으로 전달한다.
- 핸들러 매핑은 해당 URL에 매핑된 컨트롤러가 있는지 검사 후 컨트롤러에 전달한다.
- 해당 컨트롤러가 로직을 처리한다.
- ModelAndView 객체 생성 후, 결과를 담아서 dispatcher-servlet에 전달한다.
- dispatcher-servlet은 전달받은 뷰가 있는지 검사하기 위해 ViewResolver로 보낸다.
- ViewResolver는 받은 뷰가 있는지 검사 후 뷰로 보낸다.
- 모델과 같이 뷰를 그린 후에 dispatch-servlet으로 보낸다.
- 최종적으로 콘텐츠를 클라이언트에게 전달한다.
🧑🏻💻 AOP(Aspect-Oriented Programming)
애플리케이션의 핵심적인 기능과 부가적인 기능을 분리해 Aspect라는 모듈로 만들어 설계하고 개발하는 프로그래밍 기법이다.
• Aspect
- 여러 핵심 기능에 적용될 관심사 모듈.
- Aspect는 구체적인 기능을 구현한 Advice와 Advice가 어디에서 적용될지를 결정하는 PointCut의 포괄적인 개념이다.
• Advice
- 공통 기능을 담고 있는 모듈.
• Target
- Aspect를 부여할 대상.
• JointPoint
- Advice가 적용될 위치.
- 애플리케이션의 어떤 지점에 AOP를 사용하여 추가적인 로직을 삽입할지 정의한다.
• PointCut
- 필터링된 JointPoint.
- 정규표현식을 사용하여 Advice를 적용할 타깃의 메서드를 선별.
🧑🏻💻 Spring AOP Advice 종류
• @Around
- 메서드 호출 전후에 실행된다.
• @Before
- JointPoint가 실행되기 이전 시점에 실행된다.
• @AfterRetruning
- JointPoint가 정상 완료된 후 실행된다.
• @AfterThrowing
- 메서드가 예외를 던지는 경우 실행된다.
• @After
- JointPoint의 정상 완료 여부에 상관없이 항상 실행된다.
🧑🏻💻 Spring AOP VS AspectJ
• Spring AOP
- 런타임 위빙(다이나믹 프록시)을 사용한다.
• AspectJ
- AspectJ는 위빙 시점에 따라 Compile Time Weaving(CTW), Post Compile Weaving(PCW), Load Time Weaving(LTW)로 분류된다.
- Compile Time Weaving(CTW) : AJC(AspectJ Compiler)를 이용해서, 소스 코드가 컴파일할 때 위빙
- Post Compile Weaving(PCW) : 이미 컴파일된 바이너리 클래스에 위빙
- Load Time Weaving(LTW) : Class Loader가 클래스를 로딩할 때 위빙
🧑🏻💻 PSA(Portable Service Abstraction)
• 환경의 변화와 관계없이 일관된 방식의 기술 접근 환경을 제공하려는 추상화 구조를 뜻한다.
• 예를 들면, 트랜잭션 처리를 위해 Platform TransactionManager의 구현체들인 JpaTransactionManager, DatasourceTransactionManager, HibernateTransactionManager을 사용하는데 구현체가 바뀌어도 트랜잭션을 처리하는 코드는 변경되지 않는다.
🧑🏻💻 JSP vs Servlet
• JSP
- html 내에 자바코드를 블록화하여 삽입한 것.
- JAVA in Html.
• Servlet
- Container가 이해할 수 있도록 구성된 자바코드로 이루어진 것.
- Html in JAVA.
🧑🏻💻 Framework vs Library
• Framework
- 뼈대가 되는 부분을 미리 구현한 클래스, 인터페이스, 메서드 등의 집합체이다.
• Library
- 자주 쓰일 만한 기능들을 따로 구현하여 모아 놓은 클래스의 집합체이다.
🧑🏻💻 Spring Filter vs Interceptor
• Filter
- DispatcherServlet 이전에 실행된다.
- 보통 web.xml에 등록된다.
- 일반적으로 인코딩 변환 처리, XSS방어 등에 대한 처리로 사용된다.
• Interceptor
- Dispatcher servlet에서 Handler(Controller)로 가기 전에 정보를 처리한다.
- 로그인 체크, 권한 체크, 프로그램 실행시간 계산, 로그 확인 등에 대한 처리로 사용된다.
🧑🏻💻 빈 스코프(Bean Scope)
스프링이 관리하는 빈이 생성되고, 존재하고, 적용되는 범위를 뜻한다.
• Singleton
- 스프링 컨테이너 내에 단 하나의 객체만 존재하며, 컨테이너가 사라질 때 제거된다.
• Prototype
- 모든 요청에 대해 새로운 객체를 생성하며, 참조가 사라지면 GC에 의해 제거된다.
• Request
- HTTP 요청이 들어올 때마다 생성된다.
• Session
- HTTP 세션이 만들어질 때마다 생성된다.
🧑🏻💻 REST(Representational State Transfer)
자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미한다.
HTTP URI를 통해 자원을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD 수행한다.
• 구성 요소
- 자원(Resource) : HTTP URI
- 자원에 대한 행위(Verb) : HTTP Method
- 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load
• REST에서의 CRUD Operation
- Create : 데이터 생성(POST)
- Read : 데이터 조회(GET)
- Update : 데이터 수정(PUT)
- Delete : 데이터 삭제(DELETE)
🧑🏻💻 RESTful
REST의 원리를 따르는 시스템을 의미한다.
• 클라이언트-서버(Client-Server)
- 관심사의 명확한 분리가 선행되면 서버의 구성요소가 단순화되고, 확장성이 향상되어 여러 플랫폼을 지원할 수 있다.
• 무상태성(Stateless)
- 서버에 클라이언트의 상태 정보를 저장하지 않는 것을 말한다. 단순히 들어오는 요청만 처리하여 구현을 더 단순화시킨다.
• 캐시 가능(Cacheable)
- 클라이언트의 응답을 캐시 할 수 있어야 한다.
• 계층화 시스템(Layered System)
- 서버는 중개서버나 로드 밸런싱, 공유 캐시 등의 기능을 사용하여 확장성 있는 시스템을 구성할 수 있다.
• 코드 온 디맨드(Code on demand)
- 클라이언트 서버에서 자바 애플릿, 자바스크립트 실행 코드를 전송받아 기능을 일시적으로 확장할 수 있다.
• 인터페이스 일관성(Uniform interface)
- URI로 지정된 리소스에 균일하고 통일된 인터페이스를 제공한다. 아키텍처를 단순하게 분리하여 독립적으로 만들 수 있다.
🧑🏻💻 @Value VS @ConfigurationProperties
스프링의 properties나 yaml에 있는 값들을 사용하기 위한 어노테이션이다.
• @Value
- 단일 값 주입만 할 수 있다.
- RelaxedBinding이 불가능하다.
- spEL 적용이 가능하다.
• @ConfigurationProperties
- 복수의 값을 바인딩할 수 있다.
- RelaxedBinding이 가능하다.
- spEL 적용이 불가능하다.
🧑🏻💻 @Transactional
트랜잭션 처리를 위한 어노테이션이다. 선언적 트랜잭션이라고도 부른다.
• 적용 대상
- 클래스
- 메서드 (단, public에서만 적용된다. public이 아닌 메서드에 적용할 경우, 예외는 발생하지 않으나 트랜잭션 적용이 무시된다.)
- 인터페이스 (단, 스프링 공식 매뉴얼에서 권장하지 않는 방식이다. AOP를 적용하는 방식에 따라서 트랜잭션 어노테이션이 적용되지 않을 때가 있다.)
• 트랜잭션 AOP 주의사항
- 내부호출(프록시를 거치지 않고 호출)의 경우 트랜잭션이 적용되지 않는다.
- 초기화 시점에는 적용되지 않는다.(예시로 @PostConstruct를 사용한 메서드에서 트랜잭션을 시작할 경우, 올바르게 동작하지 않는다.)
• TransactionlManager 옵션
- Transaction Manager가 다수일 경우, 설정한 Bean의 id 혹은 qualifier 값을 아래와 같이 옵션 값으로 사용하여 트랜잭션 매니저를 설정할 수 있다.
- Ex) @Transactional("subDbTx")
- Ex) @Transactional(value = "subDbTx")
- Ex) @Transactional(transactionManager = "subDbTx")
• 전파 설정 옵션
- REQUIRED(기본값) : 기존 트랜잭션이 존재한다면 기존 트랜잭션으로 참여하고, 없다면 새로 생성한다.
- REQUIRES_NEW : 항상 새로운 트랜잭션을 생성한다.
- MANDATORY : 기존 트랜잭션에 참여하며, 기존 트랜잭션이 없다면 예외를 발생시킨다.
- SUPPORTS : 기존 트랜잭션이 존재한다면 참여하고, 없다면 생성하지 않는다.
- NOT_SUPPORTED : 기존 트랜잭션이 존재하면 보류시키고, 없다면 생성하지 않는다.
- NEVER : 트랜잭션을 허용하지 않는다. 기존 트랜잭션이 존재하면 예외를 발생시킨다.
- NESTED : 기존 트랜잭션이 없다면 생성하고, 있다면 중첩 트랜잭션을 생성한다.
🧑🏻💻 PRG(POST-Redirect-GET) 패턴
웹 디자인 패턴 중 하나로 POST요청에 대한 응답으로 리다이렉트를 통해 GET요청을 할 수 있도록 처리하는 패턴이다.
• 상세 순서
- 클라이언트는 HTTP POST 요청을 한다.
- 서버는 클라이언트에게 'URL'과 'GET요청으로 Redirect 할 수 있는 응답코드(302)'를 응답한다.
- Redirection을 통해 서버에게 응답받은 URL로 GET 요청을 한다.
• 적용하지 않았을 시 문제점
- 데이터를 POST요청으로 보낸 후 클라이언트가 새로고침을 할 경우, 중복 요청이 발생하여 예기치 않은 문제점이 발생할 수 있다.
🧑🏻💻 PRG(POST-Redirect-GET) 패턴
Gradle은 그루비(Groovy)를 이용한 빌드 도구로써, Ant와 Maven과 같은 이전 세대의 빌드 도구의 단점을 보완하고 장점을 취합하여 만들어졌다.
• 특징
- Ant처럼 매우 유연한 범용 빌드 도구이다.
- 멀티 프로젝트 빌드를 지원한다.
- 빌드 스크립트를 간단하게 작성할 수 있다.
🧑🏻💻 CI/CD
CI/CD란 지속적 통합과 지속적 배포가 통합된 방식을 일컫는다.
• CI(Continuous Integration)
- 애플리케이션에 대한 새로운 코드 변경사항이 주기적으로 빌드 및 테스트되어 공통 저장소에 통합되는 개념이다.
- 다수의 개발자가 형상관리 툴을 공유하는 경우라면, 자동화된 빌드 및 테스트는 원천 소스코드의 충돌을 방어할 수 있는 장점을 가지고 있다.
• CD(Continuous Delivery 또는 Continuous Deployment)
- 배포 자동화 과정을 뜻한다.
- CI가 새로운 소스코드의 빌드, 테스트, 병합을 의미한다면 CD는 개발자의 변경 사항을 넘어 고객의 환경까지 릴리즈 되는 것을 의미한다.
참고문헌
1. 망나니개발자 - [기술면접] CS 기술면접 질문 - 개발 언어 (7/8)
'Interview' 카테고리의 다른 글
| [기술면접] Database(데이터베이스) (0) | 2023.03.29 |
|---|---|
| [기술면접] Java(자바) (0) | 2023.03.29 |
