대용량 트래픽에 대응하기 위해서는 Java Spring 애플리케이션을 최적화하고 확장 가능한 아키텍처를 구축하는 것이 중요. 아래는 대용량 트래픽에 대응하기 위한 몇 가지 주요 전략이다.

1.로드 밸런싱 (Load Balancing):

개념: 트래픽을 여러 서버로 분산시켜 부하를 분산하는 메커니즘.

• Spring에서의 적용: Spring에서는 로드 밸런싱을 위해 여러 옵션을 제공함.
• 하드웨어 로드 밸런서, NGINX, 또는 Spring Cloud의 Ribbon과 같은 소프트웨어 로드 밸런서를 활용할 수 있다.

2. 수평 확장 (Horizontal Scaling):

개념: 서버의 대수를 늘려 시스템의 성능을 향상시키는 방법.

• Spring에서의 적용: Spring Boot 애플리케이션을 여러 인스턴스로 실행하여 수평 확장을 구현할 수 있다.
• Spring Cloud와 같은 기술을 사용하여 마이크로서비스 아키텍처를 통해 서비스를 분할하고 독립적으로 확장할 수 있다.

3. 캐싱 (Caching):

개념: 자주 사용되는 데이터를 메모리에 저장하여 빠르게 응답할 수 있도록 하는 메커니즘.

• Spring에서의 적용: Spring Cache를 활용하여 메서드의 결과를 캐싱할 수 있다.
• 분산 캐싱 솔루션인 Redis 또는 Memcached를 통해 여러 인스턴스 간에 캐싱을 공유할 수 있다.

4. 비동기 처리 (Asynchronous Processing):

개념: 일부 작업을 비동기로 처리하여 응답 시간을 최적화.

• Spring에서의 적용: Spring에서는 @Async 어노테이션을 사용하여 메서드를 비동기적으로 실행할 수 있다.
• 메시지 큐를 통한 비동기 메시지 처리를 고려할 수 있다.

5. 데이터베이스 최적화:

개념: 데이터베이스 쿼리의 성능을 향상시켜 대용량 데이터 처리를 최적화.

• Spring에서의 적용: JPA의 성능 최적화 기능을 활용하거나, Hibernate의 캐시를 사용하여 데이터베이스 액세스를 최적화할 수 있다.

6. 모니터링 및 로깅:

개념: 시스템의 상태를 모니터링하고 로그를 통해 문제를 식별하는 것이 중요합니다.

• Spring에서의 적용: Spring Boot Actuator를 사용하여 애플리케이션의 상태를 확인하고, 로깅을 통해 성능 문제를 식별. 모니터링 도구나 APM(Aplication Performance Monitoring) 도구를 활용하여 시스템을 지속적으로 감시.

7. 보안 및 DDos 대응:

개념: 대규모 트래픽을 처리할 때 보안을 강화하고 DDoS(Distributed Denial of Service) 공격에 대비합니다.

• Spring에서의 적용: Spring Security를 사용하여 보안을 강화하고, WAF(Web Application Firewall)를 통해 DDoS 대응을 강화할 수 있다.

8. 성능 튜닝과 프로파일링:

개념: 애플리케이션의 성능을 지속적으로 모니터링하고 튜닝하여 최적화합니다.

• Spring에서의 적용: VisualVM, YourKit, JProfiler 등의 프로파일링 도구를 사용하여 애플리케이션의 성능을 분석하고 최적화.

대용량 트래픽에 대응하기 위해서는 이러한 전략을 조합하여 안정적이고 확장 가능한 시스템을 구축해야 합니다. 이때, Spring의 다양한 기능과 모듈을 적절히 활용하여 대응할 수 있다.

ORM 사용시 쿼리의 복잡성 문제

ORM(Object-Relational Mapping)을 사용하면 쿼리가 복잡해질 수 있다. 이러한 복잡성은 대부분은 성능, 가독성, 유지보수 등의 이유로 발생. Java Spring에서는 이러한 복잡한 쿼리에 대한 대응책으로 다양한 방법과 기술을 제공하고 있다.

1. JPQL(Java Persistence Query Language) 활용

개념: JPA(Java Persistence API)에서 제공하는 객체 지향적인 쿼리 언어로, 엔티티 객체를 대상으로 쿼리를 작성.

장점

(1) 객체 지향적이며, 엔티티 객체를 대상으로 쿼리를 작성하므로 가독성이 높아짐. (2) 엔티티 간의 관계를 쉽게 표현할 수 있다.

2. QueryDSL 사용

개념: Java로 작성된 유형 안전한 동적 쿼리를 생성하는 데 사용되는 라이브러리.

장점

(1) 컴파일 시점에 타입 검사를 제공하여 런타임 에러를 방지. (2) 코드 자동 완성 및 가독성이 향상.

3. Native Query 사용:

개념: JPA에서 제공하는 JPQL이나 HQL이 아닌 실제 SQL 쿼리를 사용.

장점

(1) 복잡한 쿼리를 작성할 때 JPQL이나 HQL보다 더 효과적일 수 있다. (2) 특정 데이터베이스에 최적화된 쿼리를 작성할 수 있다.

4. 캐싱 활용

개념: 쿼리 결과를 캐시하여 성능을 향상시키는 기술입니다.

장점

(1) 반복적으로 실행되는 쿼리의 결과를 캐시하면 데이터베이스 부하를 줄일 수 있다. (2) Spring에서는 @Cacheable 어노테이션을 통해 메서드의 결과를 캐싱할 수 있다.

5. DTO 사용

개념: Entity의 일부 속성만 필요한 경우, 전체 엔티티를 조회하는 것이 아니라 DTO(Data Transfer Object)로 필요한 데이터만 선택적으로 조회합니다.

장점

(1) 필요한 데이터만 전송하므로 네트워크 부하가 줄어듦. (2) 데이터 전송 시에 필요한 컬럼만 조회하므로 성능이 향상.

6. Batch 처리 활용:

개념: 대량의 데이터를 한 번에 처리하는 방법으로, 복잡한 쿼리를 분할하여 작은 단위로 나눠 처리합니다.

장점

(1) 대용량 데이터를 효율적으로 처리할 수 있다. (2) 트랜잭션 범위를 최소화하여 성능을 향상시킬 수 있다.

7. 프로시저 및 함수 사용:

개념: 데이터베이스에 저장된 프로시저(Stored Procedure)나 함수를 활용하여 복잡한 로직을 데이터베이스 측에서 처리합니다.

장점

(1) 데이터베이스의 기능을 최대한 활용하여 성능을 최적화할 수 있다. (2) 미리 정의된 로직을 사용하여 논리적인 처리를 간소화할 수 있다.

8. 인덱스 최적화:

개념: 적절한 인덱스를 사용하여 쿼리의 속도를 향상시키는 방법입니다.

장점

(1) 데이터베이스 엔진이 효율적으로 데이터를 찾을 수 있어 쿼리 성능이 향상됨. (2) 인덱스는 검색 및 정렬을 가속화하므로 대용량 테이블에서 유용함.

주의사항

(1) 복잡한 쿼리가 필요한 경우, 성능을 고려하여 적절한 전략을 선택해야 함. (2) JPA에서의 성능 최적화와 관련된 다양한 힌트를 사용하여 데이터베이스와의 상호작용을 조절할 수 있다. (3) 개발 초기에는 가독성을 중시하고, 성능 문제가 발생하면 프로파일링 도구를 사용하여 병목 지점을 찾아 최적화함. (4) 복잡한 쿼리에 대한 대응은 사용되는 기술, 애플리케이션의 특성, 성능 요구사항 등을 고려하여 적절한 방법을 선택하는 것이 중요함.

DI와 IoC는 스프링 프레임워크의 핵심 원칙 중 하나로, 객체 간의 결합도를 낮추고 코드의 유지 보수를 용이하게 만드는 데 중요한 역할을 한다.

IoC(Inversion of Control)

• IoC는 '제어의 역전'이라는 뜻.
• 객체의 생성과 생명주기 관리를 개발자가 아닌 프레임워크가 담당하도록 하는 원칙.
• 일반적으로, 개발자는 객체를 직접 생성하고 관리하는 데 책임이 있으나, 스프링에서는 그 책임이 스프링 컨테이너에게 넘어감.
• 개발자는 비즈니스 로직에 집중할 수 있고, 객체 간의 의존성 관리는 스프링 컨테이너가 알아서 처리해줌.
• 이런 방식으로 코드의 결합도를 낮추고 확장성을 높일 수 있음.

DI(Dependency Injection)

• DI는 위의 IoC의 원칙을 구현하는 방법 중 하나.
• DI는 '의존성 주입'이라는 뜻으로, 객체가 필요로 하는 의존성을 외부에서 주입하는 방식.
• 이를 통해 객체 간의 결합도를 더욱 낮출 수 있음.

ex) 예를 들어, A 클래스가 B 클래스의 메소드를 사용하려면, 일반적으로 A 클래스 내부에서 B 클래스의 객체를 생성해야 함. 이 경우, A 클래스는 B 클래스에 강하게 의존! 하지만 DI 사용시, B 클래스의 객체는 외부에서 A 클래스에 주입 -> A 클래스가 B 클래스의 구체적인 구현에 의존하지 않게 됨.

DI방식의 종류

• 스프링에서는 주로 세 가지 방식의 DI를 지원함 : 생성자 주입, 세터 주입, 필드 주입.
• 위의 DI들은 각각 적절한 상황에 따라 사용됨.

이러한 IoC와 DI의 원칙 덕분에, 스프링에서의 유연하고 확장성 있는 애플리케이션 개발이 가능하다. 개발자는 구체적인 객체 생성과 관리에서 해방되어 비즈니스 로직에 집중할 수 있으며, 테스트와 유지 보수도 용이해진다.

객체지향 프로그래밍

• 객체지향 프로그래밍(Object-Oriented Programming, OOP)은 프로그래밍 패러다임 중 하나로, 프로그램을 객체들의 집합으로 보고 이들이 서로 상호작용하는 방식으로 설계하고 구현하는 방법.
• 객체는 상태(state)와 행동(behavior)을 가지며, 이는 각각 객체의 속성(attribute)과 메소드(method)로 표현됨.

**< 객체지향 프로그래밍의 핵심 원칙> **

1. 캡슐화(Encapsulation): 객체의 상태와 행동을 하나의 단위로 묶는 것. 객체의 상태는 private 접근 제어자를 통해 외부로부터 보호되며, 상태 변경은 메소드를 통해서만 가능케 함.

2. 상속(Inheritance): 기존 클래스의 특성을 그대로 물려받아 새로운 클래스를 생성하는 것. 이를 통해 코드의 중복을 줄이고 재사용성을 높일 수 있음.

3. 다형성(Polymorphism): 같은 타입이나 메소드에 대해 다양한 방식으로 동작을 수행할 수 있게 하는 것을 말합니다. 이를 통해 유연성과 확장성을 높일 수 있음.

4. 추상화(Abstraction): 복잡성을 줄이고, 필요한 핵심 기능만을 표현하기 위해 객체의 공통적인 특성들을 추출하는 것.

자바 스프링에서는 위와 같은 객체지향 프로그래밍 원칙들이 깊게 적용되어 있다. 그에 따른 예시는 아래와 같다.

1) 캡슐화: 스프링의 Bean은 캡슐화 원칙을 따름. Bean의 내부 상태는 외부에서 직접 접근할 수 없고, Bean 제공 메소드를 통해서만 접근 및 변경이 가능.

2) 상속: 스프링은 상속을 통해 기능을 확장. 예를 들어, @Component, @Service, @Repository 등의 어노테이션은 모두 @Component를 상속받아 사용.

3) 다형성: 스프링은 다형성을 통해 유연성을 높임. 예를 들어, 스프링은 JdbcTemplate 클래스를 통해 다양한 데이터베이스 작업을 추상화하고, 실제 구현은 개발자가 선택한 데이터베이스에 따라 달라짐.

4) 추상화: 스프링은 복잡한 기술을 추상화하여 개발자가 보다 쉽게 사용할 수 있게 함. 예를 들어, 스프링의 JdbcTemplate는 JDBC의 복잡한 작업을 추상화하여, 개발자가 SQL 쿼리 실행에만 집중할 수 있게 도와줌.

이렇게 객체지향 프로그래밍은 스프링에서 중요한 역할을 하며, 이를 통해 개발자는 보다 유연하고 강력한 애플리케이션을 구축할 수 있다.

둘 다 인터넷 프로토콜 스위트의 핵심 프로토콜 중 하나로, 네트워크 통신에서 데이터를 전송하는 방법을 정의함.

TCP (Transmission Control Protocol)

• TCP는 연결 지향적인 프로토콜로, 데이터 전송을 시작하기 전에 먼저 두 시스템 간에 연결을 설정. 이는 '3-way handshaking' 과정으로 이루어지고, 순서는 다음과 같다:

1. 클라이언트가 서버에게 SYN 패킷을 보내 연결 요청.
2. 서버는 SYN 패킷을 받고, SYN과 ACK (Acknowledgement) 패킷을 동시에 클라이언트에게 전송.
3. 클라이언트는 ACK 패킷을 서버에게 보내 연결을 확립.

• TCP는 이런 방식으로 데이터의 순서와 신뢰성을 보장함. 패킷이 손실되면 재전송을 요청하고, 도착한 패킷의 순서가 바뀌었다면 원래의 순서대로 재배열함.

UDP (User Datagram Protocol)

• 반면, UDP는 연결이 설정되지 않은 상태에서 데이터를 전송하는 비연결형 프로토콜.
• 이는 데이터를 빠르게 전송할 수 있는 장점이 있지만, 패킷의 도착 순서나 손실에 대한 보장이 없다.
• 따라서, 신뢰성이 중요한 애플리케이션보다는 실시간성이 중요한 서비스에서 주로 사용됨.

자바 스프링에서는 TCP와 UDP 통신을 위해 java.net 패키지의 Socket과 DatagramSocket 클래스를 사용할 수 있다.

TCP에는 Socket과 ServerSocket 클래스를, UDP에는 DatagramSocket과 DatagramPacket 클래스를 사용.

이렇게 TCP와 UDP의 신뢰성 차이는 각 프로토콜의 특성과 그에 따른 처리 과정에서 비롯됨. TCP는 데이터의 신뢰성을 보장하기 위해 연결 설정과 패킷 관리 과정을 거치지만, UDP는 이러한 과정 없이 빠르게 데이터를 전송함.

http? https?

둘 다 웹 상에서 정보를 주고받는 프로토콜.

http

• HTTP는 클라이언트에서 서버로 요청을 보내고, 서버에서 클라이언트로 응답을 전달하는 방식으로 동작.
• 하지만 HTTP는 암호화되지 않은 상태로 데이터를 전송하기 때문에, 중간에서 데이터를 가로채거나 변조하는 것이 가능.

https

• 반면, HTTPS는 SSL(Secure Sockets Layer) 또는 그 후속인 TLS (Transport Layer Security) 프로토콜을 사용하여 통신 내용을 암호화함. 이로 인해 중간에서 데이터를 가로채더라도 내용을 알아볼 수 없음.

SSL인증서?

• SSL 인증서는 이러한 암호화된 통신을 가능하게 하는 도구.
• 데이터가 원본 그대로 전송되었는지 확인하는 역할.
• 인증서는 공개키 암호화 방식을 사용하는데, 이는 데이터를 암호화하는 키와 복호화하는 키가 서로 다른 방식.

SSL인증서 적용 과정

1. 서버는 공개키를 클라이언트에게 제공
2. 클라이언트는 이를 이용해 데이터를 암호화하여 전송.
3. 서버는 자신만이 가지고 있는 비밀키로 암호화된 데이터를 복호화합니다.

• 장점 I) 데이터의 기밀성: 중간에서 데이터를 가로채도 복호화할 수 없음. II) 데이터의 무결성: 데이터가 전송 중에 변조되지 않았음을 보장. III) 인증: 클라이언트는 SSL 인증서를 통해 서버의 신원을 확인할 수 있음.

• 단점 I) 처리 속도: 암호화와 복호화 과정으로 인해 HTTP에 비해 처리 속도가 느림. II) 인증서 발급 및 관리: 인증서를 발급하고 유지하기 위한 비용과 노력이 필요.

스프링 자바에서는 HttpServlet 클래스를 통해 HTTP 요청을 처리할 수 있고, java.net.http.HttpClient 클래스를 이용해 HTTP 또는 HTTPS 요청을 보낼 수 있다. 단, HTTPS 설정을 위해서는 서버 설정에 SSL 인증서를 등록해야 한다.

프로세스

1. 클라이언트 요청 브라우저에서 사용자가 웹 애플리케이션에 접속, 특정 URL을 요청. 이 요청은 HTTP 요청으로 전달.

2. DispatcherServlet DispatcherServlet은 Spring MVC 프레임워크에서 중앙 집중식 컨트롤러로 작동. 클라이언트의 요청을 받아들이고, 이를 처리하기 위해 다른 컴포넌트들과 상호작용함.

3. HandlerMapping HandlerMapping은 클라이언트 요청과 매핑된 컨트롤러(Handler)를 찾아줌. 요청된 URL에 해당하는 컨트롤러를 찾기 위해 등록된 매핑 정보를 참조함.

4. Controller 컨트롤러는 클라이언트 요청을 처리하는 데 사용됨. 요청에 맞는 비즈니스 로직을 수행하고, 데이터를 처리한 후에는 결과를 반환.

5. ViewResolver ViewResolver는 컨트롤러가 반환한 논리적인 뷰 이름을 실제 뷰로 매핑해줌. 뷰 이름을 기반으로 실제 뷰 객체를 찾아주는 역할을 함.

6. View View는 클라이언트에게 보여질 결과 화면을 생성하는 역할. 주로 JSP, Thymeleaf 등의 템플릿 엔진을 사용하여 동적인 HTML을 생성.

7. 클라이언트 응답 생성된 뷰는 HTML 형태로 렌더링되어 클라이언트에게 응답으로 전송됨. 브라우저는 이 응답을 받아서 화면에 표시함.

이러한 단계를 거쳐 Java Spring에서 브라우저의 작동 방식이 이루어짐. 이 과정을 통해 클라이언트의 요청을 처리하고, 그에 맞는 응답을 생성하여 브라우저에 전달함.

쿠키와 세션

쿠키(Cookie)

• 쿠키는 클라이언트(브라우저)에 저장되는 작은 텍스트 파일.
• 서버에서 클라이언트로 전송되어 클라이언트에 저장, 이후 해당 도메인의 요청에 함께 전송됨.
• 주로 사용자 인증, 세션 관리 등에 활용됨.
• 클라이언트가 요청을 보낼 때마다 쿠키는 자동으로 서버로 전송되어 서버에서 상태 정보를 유지함.

세션(Session)

• 세션은 서버 측에서 클라이언트의 상태 정보를 유지하기 위한 개념.
• 클라이언트가 서버에 접속하면 서버는 클라이언트에게 고유한 세션 ID를 부여함.
• 이후 클라이언트의 요청마다 세션 ID를 통해 클라이언트의 상태 정보를 식별하고 유지함.
• 세션은 일정 시간 동안 유지되며, 클라이언트가 브라우저를 닫거나 세션 만료 시간이 지나면 삭제됨.

무상태(Stateless)

• 웹은 기본적으로 무상태 프로토콜인 HTTP를 기반으로 동작.
• 무상태란 클라이언트와 서버 간의 상태 정보를 유지하지 않는 것을 의미.
• 각각의 요청은 독립적으로 처리되며, 이전 요청과의 관계를 유지하지 않음.
• 이로 인해 매 요청마다 인증 정보를 전송해야 하는 등의 불편함이 발생.

쿠키와 세션 기술이 개발된 이유

• 쿠키와 세션은 무상태 프로토콜인 HTTP의 한계를 극복하기 위해 개발됨.
• 쿠키는 클라이언트 측에서 상태 정보를 유지, 세션은 서버 측에서 상태 정보를 유지하여 무상태 프로토콜의 단점을 보완.
• 클라이언트의 상태 정보를 쿠키를 통해 유지하고, 세션은 각 클라이언트의 상태 정보를 서버에 저장하여 필요할 때 참조함.

이렇게 쿠키와 세션은 무상태 프로토콜인 HTTP의 한계를 극복하기 위해 개발된 개념이며, 각각 클라이언트와 서버에서 상태 정보를 유지하는 방식으로 동작.

HTTP 메서드는 클라이언트와 서버 간에 통신할 때 사용되는 요청 방식을 나타내는 메서드로, Java Spring에서도 HTTP 메서드를 활용하여 웹 애플리케이션을 개발할 수 있다. 주요 HTTP 메서드는 GET, POST, PUT, PATCH, DELETE이며, 기타 메서드로는 HEAD, OPTIONS, CONNECT, TRACE가 있다.

주요 메서드

- GET: 리소스를 조회하기 위해 서버에 요청하는 메서드

• 주로 데이터를 조회할 때 사용. 예를 들어, 게시글 목록을 조회하거나 상세 정보를 가져올 때 사용.

  @GetMapping("/resource")
  public ResponseEntity<Resource> getResource() {
   // GET 요청 처리 로직
  }

- POST: 서버에 새로운 데이터를 생성하기 위해 요청하는 메서드.

• 주로 데이터를 생성하거나 처리할 때 사용. 예를 들어, 새로운 게시글을 작성하거나 사용자 정보를 등록할 때 사용.

  @PostMapping("/resource")
  public ResponseEntity<Resource> createResource(@RequestBody Resource resource) {
   // POST 요청 처리 로직
  }

- PUT: 서버에 데이터를 전송하여 해당 리소스를 업데이트하는 메서드

• 전체 리소스를 업데이트하는 경우에 사용. 예를 들어, 게시글 전체 내용을 수정할 때 사용.

@PutMapping("/resource/{id}")
public ResponseEntity<Resource> updateResource(@PathVariable Long id, @RequestBody Resource resource) {
    // PUT 요청 처리 로직
}

- PATCH: 서버에 데이터를 부분적으로 업데이트하기 위해 요청하는 메서드.

• 리소스의 일부분만 수정하는 경우에 사용. 예를 들어, 게시글의 일부 내용을 수정할 때 사용.

  @PatchMapping("/resource/{id}")
  public ResponseEntity<Resource> partiallyUpdateResource(@PathVariable Long id, @RequestBody Map<String, Object> updates) {
   // PATCH 요청 처리 로직
  }

- DELETE: 서버에서 리소스를 삭제하기 위해 요청하는 메서드.

• 예를 들어, 게시글을 삭제할 때 사용.

  @DeleteMapping("/resource/{id}")
  public ResponseEntity<Void> deleteResource(@PathVariable Long id) {
   // DELETE 요청 처리 로직
  }

  기타 메서드

- HEAD: 서버에서 특정 리소스에 대한 헤더 정보만을 요청하는 메서드. 주로 리소스의 메타데이터를 확인하기 위해 사용.

- OPTIONS: 서버에서 특정 리소스에 대해 지원 가능한 HTTP 메서드들을 요청하는 메서드. 주로 CORS(Cross-Origin Resource Sharing) 정책을 확인하기 위해 사용.

- CONNECT: 클라이언트와 서버 간에 터널을 설정하기 위해 요청하는 메서드. 주로 SSL/TLS 같은 보안 계층을 설정할 때 사용.

- TRACE: 서버에게 클라이언트로부터 수신한 요청을 그대로 반환하여 테스트하는 메서드. 주로 디버깅이나 테스트 목적으로 사용.

이러한 HTTP 메서드를 적절하게 활용하여 Java Spring에서 웹 애플리케이션을 개발할 수 있다.

CORS란?

• CORS (Cross-Origin Resource Sharing)는 웹 애플리케이션에서 다른 도메인 간에 리소스를 공유하기 위한 메커니즘. 이를 이해하기 위해서는 먼저 SOP (Same-Origin Policy)의 개념을 알아야 함.

• SOP는 웹 브라우저에서 적용되는 보안 정책으로, 동일 출처 정책이라고도 함. 이 정책에 따르면, 웹 페이지에서 로드되는 리소스(HTML, CSS, JavaScript 등)는 동일한 출처(프로토콜, 호스트, 포트가 동일)에서만 로드되어야 함. 다른 출처에서 리소스를 로드하려면 SOP에 의해 제한되어 보안 상의 이유로 접근이 차단됨.

  하지만 이러한 정책은 다른 도메인 간에 리소스를 공유해야 하는 상황에서 문제를 일으킴. 예를 들어, 도메인 A에서 실행 중인 JavaScript 코드가 도메인 B에 위치한 API에 접근하여 데이터를 요청하는 경우, SOP에 의해 차단됨. 이때 CORS가 필요.

• CORS는 웹 브라우저에서 SOP를 우회하는데, 서버는 클라이언트가 CORS를 지원하는지 확인하기 위해 HTTP 헤더인 "Access-Control-Allow-Origin"을 설정. 이 헤더에는 허용된 도메인의 목록이 포함되며, 클라이언트의 Origin과 비교하여 접근을 허용하거나 차단.

• 따라서 CORS는 클라이언트가 다른 도메인의 리소스에 안전하게 접근할 수 있도록 허용하면서도 보안을 유지하는 역할. 이를 통해 웹 애플리케이션 간의 상호작용이 가능하며, 다양한 도메인 간에 리소스를 공유하고 통신할 수 있음.

RDBMS의 정규화 - 데이터베이스 설계를 최적화하는 프로세스로, 중복 데이터를 제거하고 데이터 무결성을 유지하는 데 중점을 둠.

정규화는 여러 단계로 나뉘며, 각 단계는 다음 조건들을 충족해야 함.

제1정규형(1NF)

• 모든 레코드는 '유일한 키'에 의해 식별돼야 함. 이는 중복 데이터를 방지하며, 각 레코드를 유일하게 식별할 수 있는 기본 키를 설정함으로써 달성됨.

제2정규형(2NF)

• 제1정규형을 충족하고, 부분적 함수 종속성이 없어야 함. 즉, 테이블의 모든 속성이 기본 키에 완전히 종속돼야 함. 이는 데이터 무결성을 더욱 강화함.

제3정규형(3NF)

• 제2정규형을 충족하고, 이행적 함수 종속성이 없어야 함. 즉, 키가 아닌 모든 속성이 기본 키에만 직접적으로 종속돼야 함. 이는 불필요한 데이터 종속성을 제거하여 중복을 더욱 줄임.

이 외에도 BCNF, 제4정규형, 제5정규형 등이 있지만 대부분의 경우 제3정규형까지만 적용해도 충분.

정규화는 중복 데이터를 제거함으로써 디스크 공간을 절약하고, 데이터 무결성을 향상시킴. 그러나 너무 많이 정규화하면 오히려 쿼리 성능이 저하되므로, 성능과 무결성 사이에서 적절한 균형을 찾아야 함.

Primary Key, Foreign Key

Primary Key와 Foreign Key는 Spring 프레임워크에서 데이터베이스와 상호작용할 때 중요한 역할.

1. Primary Key (기본 키)

• 기본 키는 데이터베이스 테이블에 있는 각 레코드를 유일하게 식별하는 열(또는 열의 집합). Spring에서는 JPA (Java Persistence API)를 이용해 Entity 클래스에 @Id 어노테이션을 사용하여 기본 키를 정의.

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    // ...
}

• 위의 코드에서 @GeneratedValue 어노테이션은 기본 키 생성 전략을 지정합니다. GenerationType.IDENTITY는 데이터베이스가 자동으로 ID를 생성하도록 합니다.

2. Foreign Key (외래 키)

• 외래 키는 한 테이블의 필드(또는 필드의 집합)가 다른 테이블의 기본 키를 참조하는 것. 이는 두 테이블 사이의 관계를 설정하고, 데이터 무결성을 유지하는 데 도움됨. Spring에서는 @ManyToOne, @OneToMany, @OneToOne, @ManyToMany 등의 어노테이션을 사용하여 관계를 정의.

@Entity
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne
    @JoinColumn(name = "user_id")
    private User user;
    // ...
}

• 위의 코드는 User와 Post 사이에 1:N 관계를 정의함. @ManyToOne 어노테이션은 Post와 User 사이에 다대일 관계를 정의하고, @JoinColumn 어노테이션은 외래 키로 사용할 열을 지정. 이 때, 외래 키는 레코드가 참조 무결성을 유지하도록 보장. 즉, 외래 키 값은 반드시 참조하는 테이블의 기본 키 값을 가진 레코드가 존재해야 함.

NoSQL과 RDBMS의 특징과 차이점에 대해서 장, 단점을 들어 설명하라.

1. 관계형 데이터베이스 (Relational Database): RDBMS는 데이터를 테이블 형태로 저장하며, 이러한 테이블 간의 관계를 통해 데이터를 구성함.
2. Schema (스키마): RDBMS에서는 데이터의 구조가 사전에 정의된 스키마에 따라야 합니다. 이는 데이터베이스 테이블, 열, 데이터 유형 등을 정의하는 데 사용됨.
3. Table (테이블): 데이터가 행과 열의 형태로 구성된 테이블에 저장됩니다. 각 행은 레코드를 나타내며, 각 열은 해당 레코드의 속성을 나타냄.
4. SQL (Structured Query Language): RDBMS에서 데이터를 조작하기 위한 표준화된 언어로, SQL을 사용하여 데이터 검색, 삽입, 업데이트, 삭제 등의 작업을 수행할 수 있음.

<장점>

• 데이터 일관성: RDBMS는 ACID 속성을 준수하여 데이터 일관성을 보장.
• 복잡한 쿼리 처리: 복잡한 쿼리를 처리하고 다양한 연산을 수행하는 데 효과적. <단점>
• 확장 어려움: 수평적 확장이 어려워 대규모 데이터 처리에 한계가 있음.
• 고정된 스키마: 스키마가 고정되어 있어 데이터 모델 변경이 어려울 수 있음.

NoSQL (비관계형 데이터베이스):

1. 대용량데이터 (Big Data): NoSQL은 대용량 및 분산 데이터를 처리하는 데 특화됨.
2. 비규격화 (Schema-less): NoSQL은 유연한 데이터 모델을 제공하며, 스키마가 사전에 정의되지 않아도 데이터를 저장하고 검색할 수 있음.
3. Key, Value: NoSQL 데이터베이스는 주로 Key-Value, Document, Column-family, 또는 Graph 형태의 모델을 사용하여 데이터를 저장.

<장점>

• 유연성: 스키마의 자유로움으로 데이터 모델을 쉽게 변경하고 대처할 수 있음.
• 확장성: 수평적 확장이 용이하며, 대규모 데이터 처리에 효과적. <단점>
• 일관성 보장의 어려움: NoSQL은 일관성, 가용성, 분할 허용성 중에서 선택할 수 있는데, 모든 속성을 동시에 보장하기 어려울 수 있음.
• 표준화 부족: 특정 NoSQL 데이터베이스 간에 표준화가 부족하여 개발자들이 각각의 데이터베이스에 맞게 학습해야 할 필요가 있음.

MVC패턴에 대해서 설명하라.

Spring에서의 MVC 패턴은 Model, View, Controller 세 가지 구성 요소로 이루어져 있음. 이러한 패턴은 소프트웨어를 구조화하고 각 역할을 분리하여 유지보수성을 향상시키는 데 도움이 됨.

Model (모델)

1. 역할: 비즈니스 로직과 데이터 처리를 담당.

2. 특징 1) 데이터의 상태를 나타내는 객체 또는 클래스로 구성. 2) 데이터베이스와의 상호 작용, 데이터의 가공 및 처리 등을 담당. 3) View나 Controller에 대한 정보를 포함하지 않아야 함. ex. 예시(Spring) - JPA 엔터티 클래스, 비즈니스 로직을 담당하는 서비스 클래스 등.

View (뷰)

1. 역할: 사용자에게 보여지는 화면을 담당.

2. 특징 1) 사용자 인터페이스를 나타내는 부분으로, HTML, JSP, Thymeleaf 등을 통해 구현. 2) 사용자에게 정보를 표시하고 사용자의 입력을 받아 Controller에 전달. 3) Model의 데이터를 표시하기 위해 Model과 상호 작용할 수 있습니다. ex. 예시(Spring) - Thymeleaf, JSP, HTML 등의 템플릿 엔진을 사용하여 구현된 뷰 페이지가 해당.

Controller (컨트롤러)

1. 역할: 사용자의 입력을 받아 해당 요청에 대한 처리를 진행하고, 그 결과를 Model 또는 View에 전달합니다.

2. 특징: 1) 클라이언트로부터 요청을 받아 그에 따른 비즈니스 로직을 호출하고, Model에 데이터를 전달합니다. 2) 사용자의 입력을 검증하고 필요한 서비스를 호출하여 비즈니스 로직을 수행합니다. 3) 처리 결과를 View에 전달하여 사용자에게 응답합니다. ex. 예시(Spring) - Controller 어노테이션을 사용한 컨트롤러 클래스가 해당. 사용자의 요청을 처리하고, 비즈니스 로직을 호출하여 결과를 Model에 담아 View에 전달.

이러한 MVC 패턴은 각각의 역할을 분리함으로써 시스템을 모듈화하고 유연성을 높이며, 유지보수 및 확장이 쉽도록 구조화하는데 도움을 줌.

• 왜 ORM 의 탄생 배경을 알아야 하나?

1. 내가 입사할 회사에 JPA 가 적용안된 프로젝트가 있을 수 있다!
   • DB가 탄생한 후 수십년 후에야 ORM 이 나왔고 그뒤로 수년 후에야 JPA 그리고 SpringData JPA가 나왔다.
   • 따라서 모든 회사의 모든 프로젝트가 JPA 또는 SpringData JPA 가 적용되어 있는 것이 아님!
   • 프로젝트에 따라 QueryMapper를 쓰기도 한다.(대기업 및 금융)
2. ORM 은 갑자기 나타난것이 아니라 점차 발전해온 DB 연동 기술이론이다.
   • JDBC > ( QueryMapper > ORM(JPA)) 는 포함/개선 관계.
   • 이전 기술의 문제점을 개선하기 위해서 탄생하였기 때문에 이전 기술의 기능을 포함한다.
   • 그렇기 때문에 ORM 이 어떤 문제를 해결하고자 했는지 알아야 기능을 제대로 사용할 수 있다.

1. DB 탄생 후 Java 앱과 연동을 위해 JDBC 이 탄생했다.

JDBC

• Java Database Connectivity

  • 문장 그대로 Java 앱과 DB 를 연결시켜주기 위해 만들어진 기술이다.
  • 그렇기 때문에 JPA 도 이 기술을 사용하여 구현되어 있다.

• JDBC Driver 는 여러타입의 DB 와 연결할 수 있는 기능을 제공한다.

• JDBC Driver Manager 는 런타임 시점에
  • Connection(연결) 을 생성하여 쿼리를 요청할 수 있는 상태를 만듦
  • Statement(상태) 를 생성하여 쿼리를 요청!
  • ResultSet(결과셋) 을 생성해 쿼리 결과를 받아올 수 있게 해줌. 🚫 사용 후엔 각각 close()를 호출해 자원 해제를 시켜줘야 한다! 🚫

2. JDB 의 여러 문제로 QueryMapper이 탄생.

• JDBC 로 직접 SQL을 작성했을때의 문제

  • SQL 쿼리 요청시 중복 코드 발생
  • DB별 예외에 대한 구분 없이 Checked Exception (SQL Exception) 처리
  • Connection, Statement 등.. 자원 관리를 따로 해줘야 함
    • 안 해주면 메모리 꽉 차서 서버가 죽음

• 이 문제 해결을 위해 처음으로 Persistence Framework 등장!

  • 2가지의 Persistence Framework
    • SQL Mapper : JDBC Template, MyBatis 👈 이게 먼저 등장!
    • ORM : JPA, Hibernate

• SQL Mapper (QueryMapper)

  • SQL ↔ Object
  • SQL 문과 객체(Object)의 필드를 매핑하여 데이터를 객체화

JDBC Template

• SQL Mapper 첫번째 주자로 JDBCTemplate 탄생

  • 쿼리 수행 결과와 객채 필드 매핑
  • RowMapper 로 응답필드 매핑코드 재사용
  • Connection, Statement, ResultSet 반복적 처리 대신 해줌
  • But, 결과값을 객체 인스턴스에 매핑하는데 여전히 많은 코드가 필요함

  

MyBatis

• SQL Mapper 두번째 주자로 MyBatis 탄생

  • 반복적인 JDBC 프로그래밍을 단순화
  • SQL 쿼리들을 XML 파일에 작성하여 코드와 SQL 을 분리!
  • But, 결국 SQL을 직접 작성하는것은 피곤하다…(DB 기능에 종속적)
  • But, 테이블마다 비슷한 CRUD 반복, DB타입 및 테이블에 종속적이다.

  

3. QueryMapper 의 DB의존성 및 중복 쿼리 문제로 ORM 이 탄생!

• ORM은 DB의 주도권을 뺏어왔다고 표현해도 과언이 아님.
• ORM은 DAO 또는 Mapper를 통해서 조작하는것이 아니라, 테이블을 아예 하나의 객체(Object)와 대응시킨다!
• 객체지향(Object)을 관계형 데이터베이스(Relation)에 매핑(Mapping)하는 것에는 정말 많은 난관이 있다.

자바의 시작

• 자바는 객체지향 프로그래밍이라는 소프트웨어 엔지니어링적인 이점을 가지고 있었고, jvm만 설치되어있다면, 어디서 나 실행시킬 수 있다는 장점 때문에 크게 사랑 받았다.
• 초기 C언어의 이식성을 닮아서 자바 역시 jvm이 설치되어있는 환경이라면 프로그램을 실행 시킬 수 있었다.

자바가 직면한 요구사항

병렬 처리

• 빅데이터를 처리할 필요성이 늘어났고, 멀티코어 컴퓨터와 같은 병렬 프로세싱이 가능한 장비들 이 보급되면서 새로운 요구사항들이 생겨남.
• 병렬처리 모델은 크게 2가지 모델로 구분 됨.

-- 여기서 이 2가지 모델이 무엇인지 궁금해져 한 번 알아보았다.

Data 병렬 처리 모델

숫자 100개가 들어 있는 배열의 각 숫자의 제곱을 구하는 작업이 있다고 가정하자.

위 그림과 같이 100개의 데이터를 처리하는데 loop 100번을 돌아야 한다. 그럼, 1회당 4개의 데이터를 병렬 처리할 수 있다고 가정해보자. 100개의 데이터를 처리하는데 loop 25번이면 처리할 수 있다. 이를 Data 병렬 처리 모델이라 한다. 위와 같은 처리 기술로는 대표적으로 다음과 같은 기술들이 있다.

▶ CPU SSE (Streaming SIMD Extensions)

• SIMD (Single Instruction Multiple Data)라고도 함.

• 단일 명령어로 복수의 데이터를 처리.

• xmm이라는 8개의 128 bit 레지스터(샌드브릿지 아키텍처부터는 256 bit 레지스터) 존재하여 해당 레지스터를 통해 복수 데이터를 처리하는 기술

▶ OpenMP (Open Multi-Processing)

• 공유 메모리 다중 처리 프로그래밍 API

• 특정 구간을 병렬화 시켜주는 기술

▶ Intel TBB (Threading Building Blocks)의 Generic Parallel Algorithms

• parallel_for, parallel_do, parallel_while, parallel_reduce, parallel_scan 등등

▶ CUDA

• NVIDIA 사 GPGPU의 매니코어 사용할 수 있는 라이브러리

▶ OpenCL (Open Computing Language)

• CUDA 보다 좀 더 확장된 개념으로 CPU, GPU, FPGA 등등의 멀티/매니코어 플랫폼을 이용하기 위한 표준 기술 등이 있다.

▶ SDAccel

• Xilinx 사의 FPGA 기반 프로그램을 보다 손쉽게 작성할 수 있도록 하는 개발 플렛폼으로 OpenCL, C, C++등의 언어로 작성할 수 있다.

Task 병렬 처리 모델 (Task : 작업 단위)

자동차를 만드는 공장이라고 가정해 보자. Task 병렬 처리 모델에서는 가중치가 필요한데, 예제에서는 가중치를 작업 시간으로 정했다.

해당 각각의 Task를 3개의 PE(Processing Element, 실행의 기본 단위가 되는 하드웨어 유닛)로 나누어보자. 어려우니 3 core로 나눈다고 가정한다.

소요 시간이 24시간에서 12시간으로 줄었는데, 언뜻 보기에도 이상하다. 위의 예제는 Task를 잘못 분할한 예제다.

그럼, 각각의 Task의 작업 시간을 고려해서 바르게 분할해 보자.

소요시간 12시간 작업이 8시간으로 줄면서, 보기 좋게 분할되었지요. 그러나, 현실 세계에서 위의 예제처럼 예쁘게 분할하기는 쉽지 않다. 많은 테스트를 통해 경험치를 쌓아야 한다. 이런 걸, Task 병렬 처리 모델이라고 한다.

실제 프로그램을 구현함에 있어서는 Data 병렬 처리 모델과 Task 병렬 처리 모델을 골고루 잘 활용하여 써야 한다.

또한, Task 병렬 처리 모델에서 제일 중요한 것은 서로 독립적인 Task(즉, 타 Task에 영향을 적게 주는)를 잘 분리해서 분할해야 한다는 것이다. 여러 개의 Task에서 하나의 데이터를 갱신하는 구조에 병렬 처리를 사용하려면 데이터 동기화부터 시작해서 매우 복잡해지기 때문이다.

위와 같은 처리 기술 종류에는 대표적으로 아래와 같은 기술들이 있다.

▶ Intel TBB (Threading Building Blocks)의 Flow Graph 와 Task Scheduler

▶ CUDA

: NVIDIA 사 GPGPU의 매니코어 사용할 수 있는 라이브러리

▶ OpenCL (Open Computing Language)

: CUDA 보다 좀 더 확장된 개념으로 CPU, GPU, FPGA 등등의 멀티/매니코어 플랫폼을 이용하기 위한 표준 기술

▶ SDAccel

: Xilinx 사의 FPGA 기반 프로그램을 보다 손쉽게 작성할 수 있도록 하는 개발 플랫폼. OpenCL, C, C++등의 언어로 작성할 수 있다.

지금까지 병렬 처리의 개념적인 2가지 모델에 대하여 살펴보았는데, 여기서 짚고 넘어가야 하는 중요한 법칙이 하나 있다. 바로 “암달의 법칙”이다.

암달의 법칙

진 암달이라는 연구자가 시스템의 어느 한 부분이 향상될 때 전체 시스템은 최대 얼마큼 향상될 수 있는지 예측하는 연구를 진행했다.

그의 주장은 이러하다.

• 시스템 전체를 2배 빠르게 수행하면, 실제 2배가 향상된다고 볼 수 있다. 그러나, 시스템의 절반만 2배 빠르게 수행하면, 시스템 전체는 1.33배가 향상된다"

아래 그림을 보자.

위와 같은 작업이 있다고 했을 때 어느 특정 구간을 병렬 처리를 진행합니다.

더 향상시켜

더 향상시켜

결국, 암달의 법칙이란 '아무리 많은 core를 가지고 특정 구간을 0에 가깝게 병렬화한다고 해도, 전체 수행 시간은 직렬화 구간의 실행 속도보다 더 빨라질 수는 없다'는 것. 마치, CUDA를 통해 병렬 프로그램을 할 때 GPU의 수많은 core를 활용하여 병렬 처리한다고 하더라도 cache memory에 있는 데이터를 GPU 메모리에 복사하고 GPU의 수행 결과를 cache memory에 복사하는 시간보다 빨라질 수는 없다는 얘기이다.

그 후 20년이 지난 요즘 암달의 법칙을 새롭게 해석한 연구자가 있다.

존 구스타프슨

기존에 암달의 법칙에 하드웨어 기술이 급속하게 향상된다는 것을 추가한 내용이다.

위의 그림에서 보는 것과 같이 하드웨어 기술의 발달로 동일 소요 시간당 작업량이 늘어날 수 있고 그로 인해 작업량을 기준으로 속도가 향상된다는 이야기이다.

-- 병렬처리에 관한 굉장히 흥미로운 고찰이다.

함수형 프로그래밍

• 함수형 프로그래밍은, 객체 지향 프로그래밍처럼 프로그래밍의 패러다임의 한 종류.

  객체 지향 프로그래밍의 핵심 아이디어?

  1. 객체 지향 프로그래밍의 핵심 아이디어 자체는 간단하다. a. '프로그램을 객체들의 협력과 상호작용으로 바라보고 구현한다'
     2. 그 객체들을 정의하기 위해서 추상화와 같은 개념들을 사용하는 것.
     3. 핵심 개념을 통해서 달성하는 효용은 다음과 같다. a. 코드의 재사용성이 높아진다. b. 코드를 유지보수, 확장 하기 쉬워진다. c. 코드를 신뢰성 있게 사용하기 쉬워진다.

함수형 프로그래밍의 핵심 아이디어?

1. 함수형 프로그래밍의 핵심 아이디어 역시 간단합니다. a. “수학의 함수처럼, 특정한 데이터에 의존하지 않고, 관련없는 데이터를 변경하지도 않으며, 결과값이 오직 입력 값에만 영향을 받는 함수를 순수함수라고 합니다”

• 순수한 함수와 순수하지 못한 함수들

  // 수학의 함수
  f(x, y) = x + 2xy
  
  // 순수한 메서드
  // input에 따라 output은 항상 일정!
    public int someMethod(int x, int y) {
  return x + 2y;
  }
  
  class notFunc {
  private int y = 0;
  private int result;
  
  // 순수 메서드가 아닌 메서드
  // 메서드 안에서 제어할 수 없는 y라는 값에 의해 output이 바뀔 수 있다
  public int anotherMethod(int x) {
  return x + this.y * 2;
  }
  
  // 순수 메서드가 아닌 메서드 2
  // 메서드 내에서 this.result 값을 변경하고 반환하기 때문에
  // 순수 메서드라고 보기는 어렵습니다!
  public int otherMethod(int x, int y) {
  int result = x + 2 * y;
  this.result = result;
  return result;
  }
  }

  b. '프로그램을 순수한 함수의 모음으로 바라보고 구현한다'.

2. 핵심 개념을 통해서 달성하는 효용은 다음과 같다. a. 검증이 쉽다 (검증이 필요한 부분만 검증 할 수 있음) b. 성능 최적화가 쉽다 (특정 input에 대한 output을 재사용 할 수 있음 - 캐싱) c. 동시성 문제를 해결하기 쉽다 (함수는 다른 값의 변경을 야기하지 않음)

결론 - 자바함수의 변화

자바 함수형 프로그래밍의 기능들을 추가하기로 결정!

• 함수형 프로그래밍 아이디어 1 : 함수를 일급 값으로

  1. 우리가 지금까지 배웠던 자바에서 “조작할 수 있는”값은 다음과 같다. a. 기본값 (int, long, bollean, …) b. 객체
  2. 1-a, 1-b 와 같은 값들은 다음과 같은 특징을 갖는다. a. 함수에 인자로 넘길 수 있다. b. 함수의 결과로 반환 할 수 있다. c. 값을 수정할 수 있다 d. 값을 변수에 대입할 수 있다.
  3. 사실상 프로그래밍에서 지원하는 모든 연산을 지원하고 있고, 이러한 연산을 모두 지원하는 “값”들을 일급 시민, 또 는 일급 객체라고 한다.
  4. 그러나 메서드는 어떤가? a. 메서드에 인자로 메서드를 넘길 수 있는가? b. 메서드의 결과로 메서드를 반환 할 수 있는가? c. 메서드를 변수에 대입 할 수 있는가?
  5. 특정한 연산을 지원하지 않는 값이기 때문에 메서드는 이급 시민으로 볼 수 있다.
  6. 그렇지만 함수를 값으로 취급 할 수 있다면 매우 많은 것들을 할 수 있고, 함수형 프로그래밍에서는 이를 적극 이용 해 오고 있었다.

• 결론 : Java 8에 메서드 참조 기능이 도입!

자바 코딩을 하다보면 결코 피할 수 없는 두 가지가 바로 오류와 예외이다.

오류(Error)

• 일반적으로 회복이 불가능한 문제.
• 보통 시스템 레벨, or 환경적인 이유로 발생.
• 코드 문제도 있지만 회복 불가능.
• 에러가 발생한 경우 우리는 어떠한 에러로 프로그램이 종료되었는지를 확인하 고 대응.

예외(Exception)

• 일반적으로 회복이 가능한 문제.
• 회복 가능하다 함은, 예외가 발생할 수 있다는 것을 인지하고 대응할 수 있다는 뜻.
• 코드레벨에서 문제상황 대응은 '예외처리'에 속함.

컴파일 에러

• .java 파일을 .class 파일로 컴파일할때 발생하는 에러.
• 대부분 여러분이 자바 프로그래밍 언어의 규칙을 지키지 않았기 때문에 발 생.
• 존재하지 않는 클래스를 호출한다거나, 접근이 불가능한 프로퍼티나 메소드에 접근한다거나 하는 경우에 발생.
• 해결방법 : 문법에 맞게 다시 작성!

런타임 에러

• 코딩시 자주 접하게 될 에러(예외).
• 문법적인 오류는 아니라서, 컴파일은 잘 되었지만 “프로그램”이 실행 중 생기는 예외.

미확인된 예외

• 런타임 시점에 확인되는 예외.
• 예외 처리가 반드시 필요하지 않은 예외.

throws와 throw

예외에 관한 자바문법 중에 헷갈리는 문법이 있는데, 대표적인 문법이 바로 throw이다.

아래의 표는 어떤 차이점이 있는지 정리해놓은 표이다.

클래스 및 메서드를 만들며 우리의 메서드의 위험성 알리기(throw, throws)

처음에 위험성이라는 말이 선뜻 와닿지 않았다. 위험성이라는 말은 곧 오류가 발생할 가능성을 내포하고 있다는 뜻이 된다. 그것을 미리 알고 코딩으로 상황을 가정해 대처하는 것이 곧 '예외처리'이다.

• 예측이 될 때, 바로 이 throw로 이 메서드가 위험함을 알린다.

예외 Handling

1. 위험 감지하기

특정한 클래스의 메서드를 사용할 때, 특히 우리가 작성한 코드가 아니 라면 더더욱, 이 메서드가 위험한지 알아봐야 한다.

2. try-catch(finally) 키워드 이용하기

• try - catch 는 각각 중괄호 {} 를 통해 실행할 코드들을 담는다.
• try : 중괄호 {} 안에는 예외가 발생할 수 있지만 실행을 시도할 코드!
• catch : 중괄호 {} 안에는 try 안에있는 코드를 실행하다가 예외가 났을때 실행할 코드!
• • catch 는 소괄호 () 를 통해 어떤 예외클래스를 받아서 처리할지 정의해 주어야 함!
• • catch 로 모든 예외를 다 받고 싶으면 Exception 을 넣어주면 된다.
• • catch 로 일부 예외만 받아서 처리하고 싶으면 해당 예외 클래스명을 넣어 주면 된다!
• • 1개의 try 문에 catch 문은 여러개 사용할 수 있습니다. ex) 1 try : 4 catch
• 기존 try - catch 의 맨 마지막에 finally 를 붙여서 마지막에 반드시 실행할 코드를 넣을 수 있음

객체지향성을 가지는 자바언어답게, 위와 같이 “문제”를 추상화해서 객체와 상속관계를 이용해 구현할 수 있다.

java의 throwable class?

• 시작은 모든 객체의 원형인 Object 클래스에서부터!
• “문제 상황”을 뜻하는 Throwable 클래스가 Object 클래스를 상속한다.
• Throwable 클래스의 자식으로 앞서 배운 에러( Error )와 예외( Exception ) 클래스가 있다.
• 에러( Error ) 클래스와 예외( Exception ) 클래스는 각각 IOError 클래스, RuntimeException 클래스와 같이 구분하여 처리.

위 그림의 RuntimeException을 상속한 예외들은 UncheckedException, 반대로 상속하지 않은 예외들은 CheckedException으로 구현되어 있다.

• 즉 NullPointException, ArrayIndexOutOfBoundsException 등의 예외 구현체들은 명시적인 에러처리를 하지 않아도 컴파일 에러가 발생하지는 않는다.

• Checked Exception에 속하는 에러 구현체들은 핸들링 하지 않으면 컴파일 에러가 발생하는 대신, 컴파일이 됐다면 100% 복구가 가능한 에러인 셈이다!

• 자바의 에러 구현체들 예시

Chained Exception, 실제 예외 처리하는 방법

연결된 예외 (Chained Exception)

• 예외는 다른 예외를 유발할 수 있다!
• 예외 A가 예외 B를 발생시켰다면, 예외 A는 B의 원인 예외.
• 원인 예외를 새로운 예외에 등록한 후 다시 새로운 예외를 발생시키는데, 이를 예외 연결이라 한다.

예외 연결하는 이유?

• 여러 가지 예외를 하나의 큰 분류의 예외로 묶어서 다루기 위함!

• checked exception은 unchecked exception으로 포장(wrapping) 하는데 유용하게 사용되기도 한다.

• 원인 예외를 다루기 위한 메소드

• • initCause() : 지정한 예외를 원인 예외로 등록하는 메소드
• • getCause() : 원인 예외를 반환하는 메소드

Q1. 정수 배열 numbers가 매개변수로 주어집니다. numbers의 원소의 평균값을 return하도록 solution 함수를 완성해주세요.

R. 제한사항

0 ≤ numbers의 원소 ≤ 1,000 1 ≤ numbers의 길이 ≤ 100 정답의 소수 부분이 .0 또는 .5인 경우만 입력으로 주어집니다.

A. 풀이

class Solution {
    public double solution(int[] numbers) {
        double answer = 0;
        int total=0;                             
        for(int i=0; i<numbers.length; i++) {   
            total+=numbers[i];                   
        }
        answer=(double)total/numbers.length;    
        return answer;
    }
}

T. 시행착오

결과적으로는 위와 같이 굉장히 간단한 코드로 끝나지만, 처음에는 i++와 ++i의 차이점을 구별하는 것이 꽤나 헷갈렸다. 우변의 결과값을 다시 좌변에 더한다는 의미의, 코딩에서 자주 사용하는 기호인 '+='표시도 생소했다. 알고리즘에 가장 많이 쓰이는 함수 중 하나가 for 구문이므로, 제대로 익숙해질 필요가 있음을 느꼈다.

평균값은 정수가 아닐 수 있으므로 double로 변수명을 선언해준 뒤, 배열의 total은 배열의 길이와 관련된 변수명이므로 반드시 정수이므로 int로 선언해주는 것도 중요한 포인트였다.

또한, 제한사항을 내가 지정해줘야 하고 생각했는데, 팀원들과 이야기를 나누다 보니 제한사항은 문제에서 어떤 값을 대입할 것이냐는 부분이라 내가 고려할 부분이 아니라고 해서 그 부분은 코딩에서 뺐다.

변수명 선언시 괄호() 표시를 통해 계산식과 같은 좁은 영역에서 변수명 선언을 할 수 있다는 것도 새롭게 알았다.

Q2. 함수 solution은 정수 x와 자연수 n을 입력 받아, x부터 시작해 x씩 증가하는 숫자를 n개 지니는 리스트를 리턴해야 합니다. 다음 제한 조건을 보고, 조건을 만족하는 함수, solution을 완성해주세요.

R. 제한사항

x는 -10000000 이상, 10000000 이하인 정수입니다. n은 1000 이하인 자연수입니다.

A. 풀이

class Solution {
  public long[] solution(int x, int n) {
      long[] answer = new long[n];
      for(int i=0; i<n; i++){
         answer[i] = (long)x * (i+1);
      }
      return answer;
  }
}

T. 시행착오

문제가 길고 복잡해보여서 풀기 전부터 어렵겠다는 생각을 했으나, 막상 풀고 보니 의외로 간단히 끝나는 문제였다.

• x씩 증가하는 숫자이다 => for 구문을 사용한다
• n개 지니는 리스트를 리턴한다 => 배열을 사용한다

라고 생각하는 것이 키포인트였다.

역시 어떤 시행을 반복할 때 단골 함수인 for 구문이 활용된다.

x와 n은 각각 정수와 자연수이므로 int로 선언해줌을 볼 수 있다.

자연수는 1부터 시작이므로, i<n이라는 조건식을 쓰기 위해서는 i=1이 아닌 i=0이라는 것을 주의해야 한다.

본격적인(?) java의 느낌이 드는, new를 통한 객체의 인스턴스화로 결과를 return할 수 있었다.

(long)x* (i+1)이라는 계산식이 처음에는 선뜻 떠오르지 않아서 한참을 헤맸다.

x가 10000000라는 큰 수이므로, 위에서 나왔듯 계산식에서 제한적으로 long으로 선언해주는 것이 포인트다. i는 처음에 0이고 계속해서 증가하므로, 배열에 i+1을 곱해서 리턴해야 한다.

Lombok이란?

코드 절약!

• Lombok(이하 롬복)은, 자바 프로젝트를 진행하는데 거의 필수적으로 필요한 메서드/생성자 등을 자동 생성해줌으로써 코 드를 절약할 수 있도록 도와주는 라이브러리.

사용

Memo.java

• [코드스니펫] Memo

• Memo 클래스 @Getter

• 클래스 위에 롬복 @Getter를 추가한 후 컴파일된 코드를 확인해보면 이처럼 직접 작성하지 않은 getUsername(), getContents() 메서드가 자동으로 추가되어있음을 확인할 수 있다.

• Memo 클래스 @Setter

@Setter public class Memo { private String username; private String contents; } ... public void setUsername(String username) { this.username = username; } public void setContents(String contents) { Spring Master - 1주차 49 this.contents = contents; }

• set…() 메서드를 만들어 줌.

• Memo 클래스 @AllArgsConstructor, NoArgsConstructor

• 기본 생성자와 모든 필드를 파라미터로 가진 오버로딩된 생성자를 만들어 줌.

• Memo 클래스 @RequiredArgsConstructor

• final 제어자가 붙은 필드를 파라미터로 가진 오버로딩된 생성자를 만들어 줌

application.properties

• application.properties는 Spring과 관련된 설정을 할 때 사용되는 파일.
• Spring과 SpringBoot의 차이에 대해 학습할 때 SpringBoot를 사용하면 개발에 필요한 설정 정보들이 자동으로 설정된다.
• 이 파일을 사용하면 자동으로 설정되고 있는 설정 값을 쉽게 수정할 수 있다.
• 뿐만 아니라 DB 연결 시 DB의 정보를 제공해야하는데 이러한 경우에도 이 파일을 이용하여 쉽게 값을 전달할 수 있다.
• Apache Tomcat을 사용하여 서버를 실행하면 기본 port 설정이 8080으로 되어 있다.

• application.properties 파일에서 server.port=8081 이렇게 설정을 하면 서버의 port 번호를 ‘8080’에서 ‘8081’로 바꿔서 실행시킬 수 있다.

오늘은 기존의 자바프로젝트 팀 외에 알고리즘 공부팀이 새로 편성되었다. 사실 그동안 알고리즘 및 코테(코딩테스트) 강의는 몇 번 들어봤으나, 다른 강의들을 듣거나 팀프로젝트를 하는데 치중했기에, 본격적으로 제대로 시작하는 것은 이번이 처음이다. 아무래도 비전공자이다 보니 아주 기초적인 것부터 차근차근 시작할 수밖에 없었다. 그래도 기존에 자바용어를 써서 어느 정도 용법이 익숙해졌다 보니, 초반 테스트들은 그렇게 어렵지만은 않았다. 알고리즘 공부를 해보니 벌써부터 모르는 부분 및 새로 알게된 부분이 생겨서 정리해본다.

자바에서 나머지, 몫 구하기

덧셈, 뺄셈은 워낙 기초적인 부분이라 다른 방법이랄 게 없었으나, 몫과 나머지를 구하는 방법은 기존의 int 명령어를 이용하는 것 말고도 색다른 방법이 있었다. 바로 java의 기능을 쓰는 것이다.

일반적으로 몫은

• int a = 33/10;
• 결과는 3.

나머지는

• int b = 26%10;
• 결과는 6.

라고 구하는 것이 일반적이다. 양수일 때는 int를 쓰더라도 상관없겠으나, 음수의 나머지를 구하는 경우에는 달라진다.

• -26%10 => -6

나머지는 양수로 구하는 것이 수학적으로 옳은데, 음수가 나와버렸다.

그러나 다음과 같은 Math.로 시작되는 기능을 쓰면 더 엄밀하게 구할 수 있게 된다.

• 나머지 : Math.floorMod(-26,10) => 4

몫을 구하는 명령어도 있다.

• 몫 : Math.floorDiv(33,10) = 3

HTTP(HyperText Transfer Protocol)란?

• 데이터를 주고 받는 양식을 정의한 "통신 규약"중 하나.
• 매우 범용적인 양식을 가지고 있어 전 세계에서 제일 널리 쓰이는 통신 규약.
• 통신 규약 : 컴퓨터끼리 데이터를 주고 받을 때 정해둔 약속.

• 위와 같이 모국어 대신 중국어 등 외국어로 말한다면 알아들을 수 없게 된다.
• 마찬가지로 컴퓨터끼리 데이터를 주고 받을 때 정해진 규칙없이 매번 요청하는 방식이 다르다면 소통에 큰 문제가 발생한다.
• 현재 이용되는 대부분의 웹 서버가 HTTP를 기반으로 정해준 규칙에 맞게 데이터를 주고 받는다.
• 모든 브라우저는 HTTP 프로토콜을 기본으로 지원하므로 우리는 HTTP를 매일 이용하는 셈이다.

HTTP로 어떻게 데이터를 주고 받는가

HTTP엔 Request, Response라는 개념이 존재.

• 예시로 서버와 브라우저는 아래와 같이 동작한다.

1. 브라우저는 서버에게 자신이 원하는 페이지(URL 등의 정보)를 요구(Request).
2. 서버는 브라우저가 원하는 페이지가 있는지 확인하고, 있다면 해당 페이지에 대한 데이터를 실어 응답(Response). 없다면 없는 페이지에 대한 데이터를 반환.
3. 브라우저는 서버에게 전달 받은 데이터를 기반으로 브라우저에 그려줌. ※ "데이터"는 어떠한 데이터든 가능.

브라우저에서의 HTTP 동작 확인

1. 개발자 도구와 네트워크 탭 열어보기

1) 원하는 웹 페이지 방문하기. 2) 브라우저에서 F12를 누르면 아래와 같은 창이 뜸. 이를 DevTool 혹은 개발자 도구라고 부름.

3) 네트워크탭을 누름.

4) 새로고침. 5) 아래 나오는 항목들이 브라우저가 지금 페이지를 보여주기 위해 서버에서 받아온 데이터 목록.

• 웹 개발을 진행하면서 문제가 생겼을 때 문제에 대한 분석을 위해 개발자 도구와 네트워크 탭을 사용하면 좋다.

2. 네트워크(Network) 탭 좌측 Name 목록 아래 요청 클릭하기

3. Headers 탭 살펴보기

General

• 브라우저에서 서버로 보낸 일종의 Request 데이터.

• Status Code 200은 ‘요청이 성공했다’라는 뜻을 의미.

• HTTP 상태 코드(Status Code)를 통해 브라우저와 서버간의 요청, 응답 과정에서 발생할 수 있는 상황들을 표현할 수 있 다.

• • HTTP 상태 코드는 3자리 숫자로 이루어짐.
• • 첫 번째 자리 숫자는 상태 코드의 분류를 나타내는 용도로 사용되며, 나머지 두 자리는 세부적인 정보를 나타냄.

• 1xx (Informational)

• • 1xx 상태 코드는 요청이 수신 되었으며 처리가 계속되고 있음을 나타냄.
• • 주로 웹 브라우저와 같은 클라이언트가 서버와의 연결 상태를 확인하기 위해 사용.

• 2xx (Successful)

• • 2xx 상태 코드는 클라이언트의 요청이 성공적으로 처리 되었음을 나타냄.
• • 가장 많이 사용되는 상태 코드는 200.
• • 이는 요청이 성공적으로 처리 되었으며 클라이언트가 요청한 데이터가 서버에서 제공됨을 의미.

• 3xx (Redirection)

• • 3xx 상태 코드는 클라이언트가 추가적인 조치를 취해야 함을 나타냄.
• • 이 상태 코드는 주로 페이지 이동, 리다이렉션 등에 사용.

• 4xx (Client Error)

• • 4xx 상태 코드는 클라이언트에 오류가 있음을 나타냄.
• • 이 상태 코드는 주로 클라이언트의 잘못된 요청, 인증 오류 등에 사용.
• • 가장 많이 사용되는 상태 코드는 404입니다. 이는 클라이언트가 요청한 페이지나 리소스를 서버에서 찾을 수 없 음을 의미.

• 5xx (Server Error)

• • 5xx 상태 코드는 서버에 오류가 발생했음을 나타냄.
• • 이 상태 코드는 주로 서버의 오류, 서버 과부하 등에 사용.
• • 가장 많이 사용되는 상태 코드는 500. 이는 서버 내부 오류가 발생함을 의미.

Request Headers

-- 이것도 브라우저에서 서버로 보낸 Request 데이터라고 보면 쉽다!

Response Headers

-- 서버가 웹페이지 데이터와 함께 보낸 추가 데이터.

4. Response 탭 살펴보기

• Headers 탭에서 Response 탭으로 바꾸자.
• 서버에서 내 브라우저로 반환해준 웹 페이지를 그려주기 위한 데이터이다.

데이터? 추가 데이터? 뭐가 다른가?

• Headers 탭에서는 추가 데이터라고 많이 말했었고, Response 탭에서는 그냥 데이터라고 말했다. 차이점을 알아보자.
• HTTP 구성 요소는 크게 다음과 같다.

  Method (호출/요청 방식)

• GET : 서버에 요청을 보냅니다.
• POST : 웹 서버에 데이터를 게시할 때 사용하는게 일반적. (ex. 회원가입, 게시글 작성, 댓글 작성)
• 그 외 DELETE 등의 여러 요청 방식이 존재.
• 가장 대표적인 요청 방식이 GET 과 POST.

Header (추가 데이터. 메타 데이터)

• 브라우저가 어떤 페이지를 원하는지
• 요청 받은 페이지를 찾았는지
• 요청 받은 데이터를 성공적으로 찾았는지
• 어떤 형식으로 데이터를 보낼지
• 이러한 사례 외에도 아주 다양한 의사 표현을 위한 데이터를 모두 Header 필드에 넣고 주고 받음. 위에서 설명 된 메서드도 사실은 헤더에 포함되어 서버로 보내짐.

Payload (데이터. 실제 데이터)

• 서버가 응답을 보낼 때에는 항상 Payload를 보낼 수 있다.

• 클라이언트(브라우저)가 요청을 할 때에도 Payload를 보낼 수 있다.

• "GET method를 제외하곤 모두 Payload를 보낼 수 있다" 는게 HTTP에서의 약속.

• HTML

• JSON

• HTTP의 Payload를 통해 위와 같은 데이터들을 요청하고 응답 받을 수 있다.

비전공자인 나로서는 자바도 새로 익히는 것이 어려웠으나, Java가 조금은 눈에 익을 때쯤, 이번에는 Spring이라는 도전과제가 업그레이드 되었다. 다행히 기초적인 부분부터 다시 한 번 짚어주는 느낌이었다. 그동안 인텔리J를 쓰면서도 특별한 생각없이 썼던 터미널부터 그 개념을 짚어보았다.

터미널

• 사람은 프론트엔드(인터페이스)인 마우스로 컴퓨터에 명령을 내리지만, 컴퓨터가 익숙한'명령어'를 쓸 수 있는 창이다.

• 다만 홈브루는 처음 봤는데, 맥 유저를 위한 편의기능인 듯하다. 집에서 Spring훈련 중이라 지금은 데스크탑을 쓰지만, 감사하게도 맥 에어가 있긴 해서 집 외에 코딩을 하거나 작업을 할 때 유용한 툴일 듯 하다.

홈브루(Homebrew)

• 맥의 편리함 중 하나. '다운로드 패키지'를 관리할 수 있는 툴이다. 'brew install 프로그램이름'을 입력하면, 프로그램을 자동으로 다운로드 받아 설치해줌.

깃 설정도 설명이 돼있었으나, 다행히 그간 개인프로젝트와 팀프로젝트로 이미 많이 해와서 기초적인 부분은 어느 정도 숙지가 돼있어서 넘어가기로 한다.

서버란 무엇인가

네트워크

• 네트워크는 여러대의 컴퓨터 또는 장비가 서로 연결되어서 정보를 주고 받을 수 있게 도와주는 기술.
• 컴퓨터, 라우터, 스위치, 허브 등의 장비들이 각각의 역할을 수행하여 정보를 주고 받는다.
• 서로 정보를 주고 받기 위해서는 IP 주소, 서브넷 마스크, 게이트웨이 등의 정보를 설정하고 네트워크 프로토콜을 이용 하여 통신을 하게 된다.
• 사용자의 요청에서 시작하여 우리가 만든 서버에 도착하고 다시 사용자에게 까지 되돌아가는 흐름을 잘 파악하고 있어야 서버 개발이 용이하다.

• Client 즉, 브라우저에서 서버에 정보를 요청하는 과정을 간략하게 표현했다.
• 사용자는 브라우저를 이용하여 서버에 정보를 요청 후 응답을 받는다.
• 이때 사용자의 요청이 서버에 도달하기 위해서는 해당 서버의 정보가 필요. 그 요청이 해당 서버에 정확하게 도달할 수 있게 제공되는 정보가 IP 주소!
• 거대한 네트워크망에서 여러분의 컴퓨터를 식별하기 위한 위치 주소 입니다.
• 네트워크상에서의 데이터 송/수신은 이 주소를 기준으로 이루어지고 있습니다.

• 위와 같이 우리가 택배를 받기 위해서는 택배를 받을 실제 주소와 받는 사람을 알려줘야 한다.
• 네트워크에서도 정보를 요청 받고 전달하려면 주소에 해당하는 IP와 받는 사람에 해당하는 포트번호를 알려줘야 한다.

그동안 컴퓨터 및 인터넷을 오래 사용하기도 했고 게임, 웹서핑 등으로 IP 주소에 대해서는 굉장히 익숙했는데, 네트워크의 개념으로 의미를 엄밀히 살펴 보니 확실히 개념을 정립할 수 있었다.

웹 서버

• 인터넷을 통해 HTTP를 이용하여 웹상의 클라이언트의 요청을 응답해주는 통신을 하는 일종의 컴퓨터.
• 이메일이나 SNS 등 대부분의 서비스는 웹 서버를 통해 사용 가능.
• 웹 서버의 기본 동작 원리는 다음과 같다.
  1. 브라우저를 통해 HTTP Request로 웹사이트를 웹서버에 요청.
  2. 이후 웹서버는 요청을 승인하고 HTTP Response를 통해 웹사이트 데이터를 브라우저에 전송.
  3. 마지막으로 브라우저는 서버에서 받아온 데이터를 이용해 웹사이트를 브라우저에 그려냄.
• 기본적으로 브라우저가 웹서버에 요청을 할때는 항상 GET method로 요청하게 됩니다.

GET method는 그간 코딩을 통해 꽤나 익숙해진 방식이다. 웹 서버 설명에서 보니 왠지 반가웠다. 핵심적인 기능을 이미 알고 있는 거 같아 왠지 더 자신감이 생긴다.

API

• API : Application Programming Interface
• 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의함.
• 개발자는 '다른 애플리케이션'이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거 나 생성함.
• 인터페이스(interface)는 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점 이나 경계면을 의미함. 즉, 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템을 의미합니다.

코딩하는 동안 굉장히 자주 보았던 API에 대해 드디어 본격적으로 배우게 되었다. 그 전에는 전공자 및 이미 협업이나 코딩에 익숙한 팀원들의 도움을 받아 API 관련 코딩을 구현했다면, 이번에는 그 역량을 스스로 갖출 기회가 온 것이다. ✔ 쉽게 표현해보자면 API는 하나의 '약속'이라고 한다. ✔ 서로 다른 애플리케이션이, 약속한 방식의 API 요청을 수행하면 정해진 결과물을 반환. ✔ 주문을 받으면 해당 주문의 음식을 가져다 주는 식당의 점원이라 보면 된다.

RESTful API

• Representational State Transfer(REST)는 'API 작동 방식에 대한 조건을 부과하는' 소프트웨어 아키 텍처.
• REST는 처음에 인터넷과 같은 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어짐.
• REST 아키텍처 스타일을 따르는 API를 REST API라고 한다.
• REST 아키텍처를 구현하는 웹 서비스를 RESTful 웹 서비스라고 한다.

API면 API지, RESTful은 또 뭐란 말인가? 잠시 쉬어갈 수 있게 만든 인터페이스인가? 싶었는데 REST가 대문자인 이유가 있었다. Representational State Transfer의 약자였던 것.

• 위와 같은 구성요소에 따라 API의 리소스 식별자를 중복 없이 고유하게 잘 만들고, 해당 API에 적절하게 HTTP 메서드를 사용했다면, RESTful하게 설계했다고 볼 수 있다.

Apache Tomcat

Web Server 와 Web Application Server(WAS)

• 브라우저에서 URL을 입력하여 어떠한 페이지를 요청했을 때 HTTP의 요청을 받아들여 HTML 문서와 같은 정적인 콘텐츠를 사용자에게 전달해주는 역할을 하는 것이 Web Server.

웹 서버의 역할 2가지

1. 정적인 콘텐츠 즉, 이미 완성이 되어있는 HTML과 같은 문서를 브라우저로 전달.
2. 브라우저로부터 ‘로그인하여 MyPage를 요청’과 같은 동적인 요청이 들어왔을 때, 웹 서버 자체적으로 처리하기 어렵기 때문에 해당 요청을 WAS에 전달.

• 종류로는 Apache, Nginx 등이 있음.
• WAS는 웹 서버와 똑같이 HTTP 기반으로 동작.
• 웹 서버에서 할 수 있는 기능 대부분을 WAS에서도 처리 가능.
• WAS를 사용하면 로그인,회원가입을 처리하거나 게시물을 조회하거나 정렬하는 등의 다양한 로직들을 수행하는 프로그램을 동작시킬 수 있다.
• 종류로는 Tomcat, JBoss 등이 있음.

Apache Tomcat이란?

• Tomcat은 동적인 처리를 할 수 있는 웹 서버를 만들기 위한 웹 컨테이너.
• Apache Tomcat이란 Apache와 Tomcat이 합쳐진 형태로 정적인 데이터 처리와 동적인 데이터 처리를 효율적으로 해줄 수 있다.

본격적으로 웹서버에 대해 배우게 됐다. 그동안 인터넷을 하며 이미 친숙한 단어이긴 하지만, 어떠한 원리와 방식으로 구동되는지에 대해 더 구체적으로 알 수 있었다.

SpringBoot와 Spring

• Spring 프레임워크는 2004년에 1.0이 등장한 이후 20년가까이 사랑받으며 계속해서 업그레이드 해온 현재는 Spring 6.0이 등장한 아주 오래되고 강력한 프레임워크.
• Spring 프레임워크는 AOP, IoC/DI 등과 같은 아주 강력한 핵심 기능들을 가지고 있다.
• 하지만 이러한 핵심 기능들을 사용하기 위해서는 너무나도 많은 xml 설정들이 필요했다.
• 이러한 불편한 점들을 개선하기 위해 2014년 SpringBoot가 등장.

• SpringBoot는 기존의 xml 설정 대신 Java의 애너테이션 기반의 설정을 적극적으로 사용하고 있기 때문에 무겁고 작성하기 힘들던 xml 대신에 애너테이션을 사용하여 아주 간편하게 설정할 수 있다.
• 기본적으로 개발에 필요한 설정 정보들을 일반적으로 많이 사용하는 설정 값을 default로 하여 자동으로 설정해주고 있다.
• 외부 라이브러리나 하위 프레임워크들의 의존성 관리가 매우 쉬워졌다.

• 기존에는 외부 라이브러리와 프레임워크를 사용하기 위해서 각각의 버전들의 호환성을 직접 확인해가면서 의존성들을 설정함.
• 반면 SpringBoot에서는 spring-boot-starter-web 처럼 필요한 외부 라이브러리들과 프레임워크들을 의존성에 맞게 starter로 묶어서 제공.
• 이전처럼 각각의 버전 호환성을 직접 확인할 필요가 없어짐.
• 마지막으로 SpringBoot의 강력한 점 중 하나가 바로 내장 Apache Tomcat.
• Spring 프레임워크에서는 서버를 실행시키기 위해 Apache Tomcat을 직접 다운로드 받고 설정하고 프로젝트에 삽입 했어야 했다.

• 이러한 불편함을 해결하기 위해 SpringBoot에서는 기본적으로 starter-web dependency를 설정하면 자동으로 내장형 Apache Tomcat을 제공해 줌.
• 말 그대로 Apache Tomcat이 내장되어 있기 때문에 개발자가 따로 다운로드 받고 설정하고 삽입할 필요없이 바로 사용가능.

드디어 스프링의 개념에 대해 배우게 되었다. 실질적으로 '스프링'이라 함은, 그냥 스프링이 아니라 개선된 버전인 스프링부트를 일컫는다는 것 또한 알게 됐다.

그동안 자바훈련이 기초라고 했던 것이 이해가 된다. 이제 제대로 스프링을 배워볼 시간이 온 것 같다.

와이어프레임(Miro) 추가 수정 후 코딩 시작.

준영님이 메인페이지 전반적 디자인 및 관리자 페이지 모달팝업 연결, 파이어베이스 담당

승준님이 메인페이지 헤드 가시성 코딩 및 팝업 여러 필요한 부분 코딩 지원.

해인님이 디자인 및 방명록 위주로 코딩.

건우님이 관리자페이지 디자인 및 입력 기능 추가.

내가 멤버 디자인페이지를 맡음.

• 문제점 봉착

1. 원 모양이 찌그러짐

-> CSS를 통해 최대한 비슷한 디자인을 구현하려다 보니 div별로 margin, padding을 자주 썼고, 그로 인해 원이 타원으로 찌그러지게 됨. margin 및 padding의 비율을 줄이거나 아예 없애고 혹은 비율을 고정하는 방법을 생각해봤으나, 오히려 코드가 꼬여서 기존 디자인까지 망가짐. 아직 완벽히 해결되지 않음. 간격을 줄이는 다른 태그 등 명령어를 공부해봐야할 듯.

2. 모달팝업 연결이 어려움

-> 최대한 와이어프레임 구상에 근접하게 css코딩으로 디자인하고 보니, 디자인을 모달팝업에 이식하는 것이 생각보다 난이도가 높음. -> 처음엔 모달팝업 외에 다른 명령어로 새 창이 뜨는 효과를 구현할 수 있다고 생각해서 디자인부터 했으나, 애초에 모달팝업을 생각했다면 '디자인 -> 모달팝업 구현'이 아니라, '모달팝업 디자인 -> 실행'으로 하는 것이 더 수월한 작업이었을 것이라는 것이 결론.

• 작업진행율 전체적으로 팀원들이 코딩에 능숙해서 첫날 약 70~80%의 완성도 달성. 추후 디테일 및 기능적인 부분을 추가하는 과정을 거치면 마감기한 내에 충분히 제출가능할 것이라 예상함.

// GIT //

오전은 GIT 및 Github에 관하여 배웠다.

• GIT이란 : 버전 관리 도구

  • 코드 변경점 기록

• GIT의 사용목적? : 하나의 폴더 내에서 코드의 변경점을 기록하기 위함.

• Github란 : 온라인 저장소

  • 내 코드를 온라인 백업 및 타인과 협업 가능

• Github의 장점? 1) 내 코드를 온라인 저장소에 백업 가능 2) 협업시 팀원간 코드 공유 가능 3) 동시에 작업 가능

*필수 git 명령어 리스트(리눅스에서 유래)

1. git init
   • 프로그래밍을 git으로 관리하기 위해 딱 한 번만 입력하면 되는 명령어
2. git add <파일명> 혹은 git add .
   • 저장하고 싶은 파일을 지정하는 것
   • add 뒤에 점(.)은 현재 폴더(디렉토리)에 있는 모든 파일들을 의미
3. git commit -m "기능 개발과 관련된 기록"
   • 실제로 저장하는 명령어
4. git status
   • 어떤 파일이 add 됐는지, 어떤 파일이 변경됐는지, 현재 브랜치명 확인 등 확인 가능한 명령어
5. git log
   • 내가 저장한 커밋 내역 확인
6. git push
   • github에 코드를 업로드할 때 git push origin <브랜치명>의 형태로 쓰인다.
7. git clone
   • github에 있는 프로젝트를 복제해오는 명령어
8. git pull
   • 온라인 저장소에서 변경된 코드를 적용

• 컨플릭트(Conflict) 해결법 git pull 시 발생하는 conflict를 해결하는 법

1. <<<<<<<< HEAD 삭제
2. ======= 삭제
3. >>>>>>> 4182…. 삭제
4. 원하는 코드로 수정
   • 코드를 변경한 팀원과 상의하는 것을 추천

오후는 팀명 '개발자취'를 정하고 팀원끼리 소개하는 시간을 가졌으며, 파이어베이스를 중심으로 한 개발자 기초강의를 듣고 첫 팀프로젝트(프로젝트명 '개발자국')인 팀원 소개 페이지를 위한 와이어프레임을 함께 구상하였다.

<< 과제 세부사항 >>

• 프로젝트 주제 및 포함 내용
  1. [팀]과 [자신]에 대한 설명 및 MBTI
  2. 객관적으로 살펴본 자신의 장점
  3. 자신의 스타일 협업 스타일 소개
  4. 우리 팀만의 특징과 추구하는 궁극적인 목표
  5. 우리 팀의 약속
  6. 팀원들의 블로그 주소
• 최종 제출 : 10/11 (수) 11:00
• 발표 : 10/11 (수) 14:00

// 팀플 - 와이어프레임 //

• Miro라는 와이어프레임도구를 사용.
• 프로젝트 포함 내용을 중심으로 전체적인 틀과 세부디자인을 정했다.
• 팝업창의 연동 및 구상을 했다.
• 협업 및 실제 코드 작성은 다음날부터 하기로.

// 알고리즘 공부 //

• 코딩테스트 및 코드 언어의 능숙함을 위하여 팀원끼리 매일 알고리즘 공부하는 시간을 짧게 가지기로 했다. 첫날이고 와이어프레임에 시간을 많이 쏟은 관계로 기초 알고리즘만 맛보기로 확인했다.