서비스 중 하나인 IAM 은 사용자를 생성하고 그룹에 배치하는 기능을 제공한다. IAM은 글로벌 서비스이기 때문에 region을 따로 선택하지 않아도 된다.

AWS에서 계정을 생성할 때 루트 계정이 기본으로 생성된다. 이후에 루트 계정은 더이상 사용하거나 공유해서는 안 되고, 루트 계정으로 생성한 사용자를 이용하는 것!

이렇게 생성된 사용자들을 필요에 따라 그룹으로 묶어 관리한다. 그룹에는 사용자만 배치할 수 있다. (그룹에 그룹 포함은 불가) 한 사용자가 다수의 그룹에 속하는 것은 가능하다 (⬇️ 아래 이미지 참고)

1-1. 🤔 이렇게 사용자와 그룹을 생성하는 이유는 뭘까?

-> 계정을 가진 사용자들이 AWS 계정을 사용하도록 허용하기 위함! -> 허용하기 위해서는 이들에게 권한을 부여해야 함!

#

1-2. ✅ Permissions - 권한을 부여하는 방법

• 사용자 or 그룹에게 'IAM 정책'이라는 JSON 문서를 지정
  • JSON 문서에는 사용자 or 그룹에 속한 사용자들이 어떤 작업에 권한을 가지는지 설명되어 있음

⬆️ 위 이미지와 같은 JSON 문서를 사용자에게 지정함으로서 'AWS 서비스를 이용하도록 허용'

-> 최소 권한의 원칙 적용: 모든 사용자에게 모든 것을 허용하지 않는다. -> 사용자에게 필요 이상의 권한을 주지 않음으로서, 보안이나 큰 비용 발생 등의 문제를 막을 수 있다.

2. IAM Policies

특정 권한을 부여하는 것을 정책(policy)라고도 할 수 있다.

어떤 그룹에 적용된 정책이 있다면, 해당 정책이 그룹의 모든 구성원에게 적용된다. 이를 '정책의 상속 = IAM Policies Inheritance' 이라고도 한다.

사용자가 그룹에 속해 있든 아니든, 특정 사용자에게 인라인 정책을 적용하는 것도 가능하다.

2-1. 정책 구조

• Version: 정책의 언어 버전 (보통 2012-10-17)

• Id: 정책 식별 아이디 (optional)

• Statement: 하나 이상의 statements 로 구성 (Required)

  • Sid: statement의 id(=식별자) (optional)

  • Effect: statement가 특정 API에 접근하는걸 허용할지 거부할지 -> Allow 혹은 Deny 값을 가짐

  • Principal: 정책이 적용될 유저/계정/역할

  • Action: effect에 기반하여 허옹 혹은 거부되는 API 호출 목록

  • Resource: action이 적용될 리소스 목록

  • Condition: statement가 언제 적용될지 결정 (optional)

#

3. Password Policy - 비밀번호 정책

사용자와 그룹이 손상되지 않도록 보호해야 하는데, 두가지 방어 메커니즘을 사용할 수 있다.

1. 패스워드 설정

• 비밀번호 정책을 정의하여 방어할 수 있다!
• 비밀번호가 강력할수록 계정 보안이 강화됨

#

2. MFA - 다중 인증

Multi Factor Authentication 의 약자로, AWS에서 필수로 사용해야 하는 방어 메커니즘이다.

사용자가 기억하는 비밀번호와 사용자가 소유하는 실물 보안 장치를 모두 사용하는 방식으로, 단순히 비밀번호만 사용하는 것보다 보안이 강화된다!

📱MFA devices options in AWS

1. 가상 MFA 장치 - Virtual MFA device

    : 모바일로 발급된 번호로 인증
   단일 장치에서 여러 토큰을 지원하기 떄문에, 원하는 만큼 많은 유저와 계정을 보유할 수 있음

2. U2F 보안키 - Universal 2nd Factor Security Key

    : 물리적인 장치
   이를 보안 토큰에 달면 사용 가능
   단일 보안키를 사용하여 여러 루트 & IAM 사용자 지원

Hardware Key Fob MFA Device, Hardware Key Fob MFA Device for AWS GovCloud(us) 등의 하드웨어 보안 토큰도 사용 가능!

4. AWS에 엑세스 하는 방법

AWS에 액세스하는 방법은 3가지가 있다.

1. AWS Management Console

: 지금까지 살펴본 '비밀번호 + MFA' 방식

2. AWS CLI(Command Line Interface)

: 액세스 키에 의해 보호되는 방식으로, 컴퓨터에서 설정할 수 있음

🤔 CLI란? -> 명령줄 인터페이스 -> AWS CLI 는 명령줄 셸에서 명령어를 사용하여, AWS 서비스들과 상호작용할 수 있도록 하는 도구 -> CLI를 사용하면 AWS 서비스의 공용 API로 직접 액세스 가능

⬇️ CLI에서 명령줄을 입력하면 아래 이미지와 같이 결과가 반환됨.

🤔 액세스 키란? -> 자격 증명으로, 터미널에서의 AWS 액세스를 가능하게 해줌 -> 액세스 키는 관리 콘솔에서 생성할 수 있음 -> 사용자들이 자신들의 액세스 키를 직접 관리 -> 사용자 입장에서 액세스 키는 비밀번호와 같은 암호이니, 공유해선 안 됨!

3. AWS SDK(Software Developer Kit)

: AWS로 부터 애플리케이션 코드 내에 API를 호출할 때 사용하는 방식 CLI와 동일한 액세스 키로 보호됨.

🤔 SDK란? : 소프트웨어 개발 키트로, 특정 언어로 된 라이브러이의 집합이다. (-> 프로그래밍 언어에 따라 개별 SDK가 있음) -> SDK를 사용해서도 AWS 서비스와 API에 액세스할 수 있음

but! CLI와 달리 터미널 내에서 사용하는 것이 아니라, 애플리케이션 내에 자체적으로 존재

✔️ 서버의 기본 구조 – CPU, RAM, 스토리지, 데이터베이스, 네트워크 ✔️ 클라우드 도입 이전의 IT 환경 – 데이터센터의 한계와 유지보수 비용 ✔️ 클라우드 컴퓨팅이란? – 언제든 원하는 만큼 사용하는 IT 리소스 ✔️ 클라우드의 3가지 서비스 모델 – IaaS, PaaS, SaaS ✔️ AWS 리전과 가용 영역(AZ) – 데이터 보호와 지연 시간 최소화 전략 ✔️ 공동 책임 모델(Shared Responsibility Model) – AWS와 사용자의 보안 역할

AWS는 어느 날 갑자기 하늘에서 떨어진 기술이 아니다. 필요에 의해 만들어진 기술이다.

그럼 도대체 왜 AWS가 생겨난걸까? 🤔

본격적으로 AWS를 알아보기 전에, 기본적인 서버의 구조와 기존의 IT는 어떤 모습이었을지 한 번 훑어보고 가자!

1. 서버의 구성

서버는 크게 5가지로 이루어져 있다.

1. Compute: CPU (계산을 담당)

2. Memory: RAM

    -> CPU와 RAM이 합쳐지면 마치 두뇌와 같다. 
       연산한 결과를 기억하고, 기억한 정보로 또 다른 연산을 해내니까!

3. Storage: 데이터가 저장되는 곳

4. Database: 구조적으로 데이터를 저장하는 곳. like 컴퓨터의 파일.

         데이터베이스에 저장된 데이터는 검색하여 쉽게 찾을 수 있고, 쿼리가 가능하다. 

5. Network: 라우터(Routers), 스위치(Switch), DNS 서버 등

        라우터: 컴퓨터 네트워크 간의 데이터 패킷을 전달하는 기기. 
              like 배달 서비스. 어디로 정보를 보낼지 파악하고, 실제로 전송까지 
   
        스위치: 라우터로 부터 받은 패킷을 네트워크 내의 정확한 서버 or 클라이언트에게 전송

2. 클라우드가 도입되기 전 IT는 어땠을까?

서비스가 사랑을 받고 유저가 많아질수록, 저장해야 하는 데이터의 양이 늘어난다.

-> 데이터 센터와 서버 구매 비용 증가 -> 쿨링, 고장 등 유지 보수 비용 증가 -> 데이터 센터 확장이 어려움 (서버 추가 구매하고, 기존 서버와 연결해야 함. 늘어난 만큼 유지보수도 추가로!) -> 최악의 상황으로 재난이라도 일어난다면? .. 감당 불가..

이런 문제들의 해결책으로 나타난 것이 바로 👉 클라우드 👈 이다!

3. 클라우드 컴퓨팅이란?

컴퓨팅 성능, 데이터베이스 스토리지, 애플리케이션, 기타 IT 리소스들을 원할 때 원하는 만큼 (= on-demand) 제공하는 서비스

-> 이메일, iCould같은 클라우드 스토리지 서비스, 넷플릭스 등이 클라우드 컴퓨팅을 바탕으로 설계되었다.

4. 클라우드 컴퓨팅의 종류

1. IaaS(Infrastructure as a Service) - 서비스형 인프라

   • 네트워킹, 컴퓨터, 데이터 스토리지 공간 등 클라우드 IT의 구성 요소를 원시 형태로 제공

   • 이 블록들을 사용해 자유롭게 조립할 수 있음 (like 레고)

   • 유연성이 높아짐 (기존 IT(on-premise)에서 클라우드로 이동하며 생긴 변화와 유사)

   • 클라우드에서 가상화, 서버, 스토리지, 네트워킹을 관리해줌.

   • 사용자는 애플리케이션, 데이터, 런타임, 미들웨어, 운영체제를 관리

2. PaaS(Platform as a Service) - 서비스형 플랫폼

   • 기본 인프라를 관리하지 않아도 됨

   • 배포와 애플리케이션 관리에만 집중할 수 있음

   • 사용자는 애플리케이션, 데이터만 관리

3. SaaS(Service as a Service) - 서비스형 소프트웨어

   • 서비스 제공 업체가 온전히 운영하고 관리하는, 완성된 제품.

     • 사용자가 관리해야 하는 것이 없음! (like 메일, 아이클라우드, 줌 등..)

5. AWS Regions

AWS 서비스를 사용할 때 대부분의 서비스들은 특정 region에 연결 및 국한된다. 따라서 한 region에서 사용되던 서비스를 다른 region에서 사용하려고 하면, 그 서비스를 처음 사용하는 셈!

🧐 _How to choose an AWS Region? _

새로운 애플리케이션을 출시할 때, 어떤 AWS 리전을 선택해야 할까? -> 아래의 4가지 요인들을 고려해 결정할 수 있다.

1. 법률 준수(Compliance with data governance and legal requirements)

   애플리케이션이 출시될 나라의 법률을 준수해야 한다. ex) 정부가 관련 데이터가 대상 국가 내에 보관되기를 원한다면, 해당 region에서 출시해야 함.

2. 지연 시간(Proximity to customers)

   사용자들이 많은 지역과 가까운 region에서 출시해야 지연 시간이 줄어듦.

   만약 미국 사용자들을 위한 애플리케이션을 호주에서 출시한다면? -> 사용자들이 랙을 경험하게 될 것

3. region에서 사용 가능한 서비스인지 (Available services within a Region)

   region마다 사용 가능한 서비스에 차이가 있음.

   특정 서비스를 활용하여 개발된 애플리케이션을 출시하려면, 해당 서비스를 가지고 있는 region인지 확인해야 함.

4. 요금(Pricing)

   Region 마다 요금이 다르기 때문에 서비스 요금 페이지를 참고하여 결정해야 함.

🌐 AWS Availability Zones - 가용 영역

재난 상황 같이 혹시 모를 상황에 대비하여 가용 영역(AZ)들이 분리 되어 있다.

각각의 region은 일반적으로 3개의 AZ를 가지고 있다. (최소 2개/최대 6개) 각각의 가용 영역(AZ)은 여분의 전원, 네트워킹, 통신 기능을 갖춘 1-2개의 개별적인 데이터 센터로 이루어져 있다.

가용 영역들은 서로 단절되어 있기 때문에, 하나의 AZ에 문제가 발생해도, 다른 AZ에 영향을 미치지 않는다.

⬆️ 이러한 데이터 센터들과 AZ들은 높은 대역폭의 초저지연 네트워킹으로 서로 연결되어 region을 형성한다.

🌐 AWS Points of Presence (Edge Locations) - 전송 지점

AWS는 전세계에 200개 이상의 전송지점을 가지고 있다. -> 최소 지연 시간으로 최종 사용자에게 컨텐츠를 전달!

6. 공동 책임 모델 - Shared Responsibility Model

클라우드를 사용할 때, 사용자와 AWS가 책임져야 하는 부분이 따로 존재한다. 결국 공동으로 책임 지는 것!

• 사용자의 책임 "Responsibility for the security in the cloud"

-> 클라우드에서 무엇을 사용할지, 어떻게 구성할지 -> 보안, 데이터, 운영체제, 네트워크, 방화벽 구성 등에 대한 책임이 있음. (= 클라우드 내의 보안 책임)

• AWS의 책임 "Responsibility for the security of the cloud"

-> 모든 인프라, 하드웨어, 소프트웨어, 자체 내부 보안에 대한 책임이 있음. (= 클라우드에 관한 보안 책임)

Entity 사이의 관계는 크게 3가지로 나눌 수 있는데, 각각 1:1(일대일), 1:N(일대다), N:M(다대다) 이다.

1:1

하나의 엔티티가 다른 엔티티와 관계를 맺는 경우. 예를 들어 유저 엔티티와 유저 프로필 엔티티가 서로 1:1 관계를 맺을 수 있음.

그런데 대부분의 경우, 그냥 하나의 테이블에 쓰면 되기 때문에, 굳이 1:1로 연관관계를 매핑하지 않아도 ㄱㅊ!

1:N / N:1

하나의 엔티티가 여러 개의 다른 엔티티와 관계를 맺는 경우. 예를 들어, 게시글 엔티티와 댓글 엔티티는 1:N 관계를 갖는다.

게시글 하나에 여러개의 댓글이 달릴 수 있는 경우이기에 1:N 관계이고, @ManyToOne, @JoinColumn(name = "board_id") 어노테이션으로 댓글 엔티티가 게시글의 고유 식별자를 필드로 가지게 된다.

아래에서 볼 N:M 관계에서도 @ManyToOne 을 각 엔티티에 더해주면 연관관계 관리하는데 오류가 현저하게 줄어들기 떄문에, 사실상 가장 많이 사용되는 연관관계임!

N:M

두 엔티티가 서로 여러개의 관계를 맺는 경우 책과 작가 같은 관계. (책은 여러명의 저자를 가질 수 있고(공동저자), 한 저자는 여러명의 책을 쓴 경우가 있음)

주의할 점! N:M 관계를 1:N + N:1 로 풀어서 중간 엔티티를 생성하여 연관관계를 관리하는 편이 안전함

1. 일단 구현에 앞서, 어떤 객체/테이블이 필요한지 결정해야 한다.

예를 들어, 유저가 스케줄을 저장하는 스케쥴러를 만든다면, 유저 객체(테이블)과 스케쥴 객체(테이블)이 필요할 것이다. 각 객체(테이블)이 어떤 필드를 가져야 하는지도 결정해야 한다.

ex)

객체(테이블) 간의 연관관계도 결정해야 한다. 예를 들어, 한 명의 유저가 여러개의 스케쥴을 작성할 수 있다는 식으로. 이 경우 단방향 연관관계를 가진다.

2. BaseEntity 설계 및 적용

베이스 엔티티(Base Entity)는 여러 엔티티(데이터 객체)에서 공통으로 쓰이는 속성(예: 생성 날짜, 수정 날짜 등)을 모아둔 기본 클래스이다. 베이스 엔티티가 가지고 있는 속성을 필요로 하는 테이블이 있다면, 베이스 엔티티를 상속하여 사용함으로서, 중복 코드 없이 공통 속성을 쉽게 관리할 수 있다. 즉, 여러 엔티티가 같은 기능을 공유하도록 도와주는 틀이라고 이해하면 된다.

유저 테이블과 스케쥴 테이블 모두 공통적으로 '생성일, 수정일'을 가지기 때문에, 해당 필드를 베이스 엔티티로 구현하여 관리할 수 있다.

아래의 예시처럼, 베이스엔티티 기능을 할 수 있도록 적절한 어노테이션을 사용해주고, 각각의 필드들도 특징에 맞게 어노테이션을 추가하여 관리가 쉽도록 한다.

3. 각 객체(테이블) 설계 및 구현

공통 속성을 베이스엔티티로 구현하였다면, 이제 각각의 테이블을 구현해주면 된다.

스케줄러 예시에서는 1. 유저 테이블과 2. 스케쥴 테이블을 만들어야 할 것이다.

베이스엔티티를 상속받는 유저 객체:

PK인 id는 데이터베이스가 직접 관리하며 자동증가 하여 값을 저장하도록 적절한 어노테이션을 붙여주고 필수값, 중복되면 안되는 값들도 적절한 어노테이션으로 처리

베이스엔티티를 상속받는 스케쥴 객체:

4. 연관관계 설정

스케줄러 예시에서 한명의 회원이 여러개의 일정을 등록할 수 있는데, 이 경우 연관관계는 N:1 단방향이다.

위와 같이, N인 객체에 @ManyToOne, @JoinColumn 어노테이션을 추가하여 연관관계를 설정할 수 있다. 조인된 컬럼이 foreign key 가 된다!

JPA를 사용하는 이유

1. 객체지향과 RDB의 패러다임 불일치가 해결 된다!

개발자는 자바를 가지고 객체 중심으로 개발을 하지만, RDB에 데이터는 테이블로 저장된다. JPA가 객체와 데이터베이스를 매핑하는 역할을 해주는 덕에 DB의 활용이 쉬워워짐..!

2. SQL 문제 해결

JPA에서 객체를 저장하면 SQL이 자동 생성되기 때문에 데이터를 CRUD하기 위해 SQL문을 직접 작성할 필요가 없게 되고, 그 대신 비즈니스 로직에 집중할 수 있게 된다는 장점이 있다! (JDBD를 사용할 때 SQL문 계속 수정하고 어쩌구 하느라 힘들었는데,, JPA쓰면 훨씬 쉬워짐!)

3. 생산성 및 유지보수성 향상

JPA에서 Entity 클래스를 수정하면 자동으로 변경 사항들이 반영되기 때문에, 테이블에 컬럼이 추가되거나 내용을 바꿀때마다 SQL을 일일이 수정할 필요가 없이 JPA가 알아서 쳐리해준다!

JPA 사용 시 고려해야 하는 사항

1차 캐시 & 영속성 컨텍스트

동일한 데이터를 반복해서 조회하는 경우, 조회할 때마다 데이터베이스에서 데이터를 가져오면 메모리 효율이 떨어질 것이다. (쓸데없이 같은 일 반복하면 효율이 떨어진다는건 당연한 소리) JPA는 엔티티를 영속성 컨텍스트에 저장하며 이런 문제를 해결한다! 처음에 데이터를 가져온 다음 그 객체를 영속성 컨텍스트에 저장하고, 동일 트랙잭션 내에서 만일 같은 요청이 들어온다면 해당 객체를 계속 재사용한다. 같은 엔티티를 여러번 조회하더라도 데이터베이스에 같은 쿼리를 반복해서 날리지 않고도 데이터를 가져올 수 있는 것! -> 성능 최적화

Spring Boot Validation 기본 구조

1. DTO에 유효성 검사 어노테이션 적용

DTO(Data Transfer Object)에 유효성 검사 어노테이션을 추가하여, 필드별로 검증을 수행할 수 있다.

@NotBlank // 공백 및 빈 문자열 허용 X @Email // 이메일 형식 검사 @NotNull
@Min // 최소값 설정 @Max // 최대값 설정

위와 같은 어노테이션을 사용할 수 있다. 괄호 안에 검증에 대한 메시지를 추가할 수도 있다.

예)

@NotBlank(message = "이름은 필수 입력값입니다.")
private String name;

2. Controller에서 @Valid 또는 @Validated 사용

Controller에서는 @Valid 또는 @Validated 어노테이션을 활용하여 DTO 검증할 수 있다.

@Valid @Valid

예시 코드)

@PostMapping("/create")
public ResponseEntity<String> createUser(@Valid @RequestBody UserDTO userDTO) {
        return ResponseEntity.ok("회원 생성 성공!");
    }

3. 전역 예외 처리로 검증 오류 관리

컨트롤러에서 직접 에러 메시지를 관리하는 대신, 전역 예외 처리 (@RestControllerAdvice)를 활용하여 한 곳에서 처리.

1. 문제 상황

일정 관리 서비스를 구현하는 과정에서, deleteTaskById() 메서드는 id를 파라미터 값으로 받아서 task 테이블에서 해당 id의 행을 삭제하는 기능을 수행한다. 기존 코드는 아래와 같이 작성되어 있었다.

이 코드의 문제점은, _존재하지 않는 id가 입력되었을 때 예외 처리가 없어 사용자에게 적절한 피드백을 제공하지 못한다는 것_이었다.

이로 인해 사용자는 일정이 정상적으로 삭제되었는지 여부를 알 수 없었고, 시스템의 신뢰성이 떨어지는 문제가 발생할 수 있었다.

2. 문제 원인

jdbcTemplate.update() 메서드는 반환 타입으로 int를 갖는다. SQL 문을 실행한 다음, 이 메서드의 영향을 받은 행(row)의 수를 반환하는 것.

기존 코드에서는 삭제된 행의 개수를 반환하도록 되어있었는데, 이 반환값을 활용하지 않았기 때문에, 삭제할 행이 존재하지 않아도 별도의 예외를 발생시키지 않았다. 이로 인해 사용자는 삭제가 실패했는지 여부를 알 수 없었다.

3. 해결 방법

이 문제를 해결하기 위해, jdbcTemplate.update() 메서드의 반환값인 영향을 받은 행의 수를 체크하고, 삭제할 행이 없는 경우(affectedRows == 0) 예외를 발생시키도록 코드를 수정하였다. 수정된 코드는 다음과 같다.

4. 해결 결과

이제 deleteTaskById() 메서드는 삭제할 행이 없는 경우 IllegalArgumentException을 발생시키면서 사용자에게 적절한 피드백을 제공할 수 있게 되었다.

이를 통해 시스템의 신뢰성이 향상되었고, 사용자는 삭제 작업의 성공 여부를 명확히 알 수 있게 되었다.

5. 결론

이번에 deleteTaskById() 메서드의 예외 처리 부족 문제를 해결한 방식으로 데이터베이스 작업 시 반환값을 적극 활용하여 예외 처리를 강화하면 시스템의 안정성과 사용자 경험을 개선할 수 있다. 앞으로도 비슷한 문제가 발생할 경우, 이와 같은 접근 방식을 활용하여 문제를 해결할 예정이다.

6. 추가 개선 가능성

1. 예외 처리의 세분화: 현재는 IllegalArgumentException을 사용하고 있지만, 더 구체적인 예외 클래스를 정의하여 사용하면 더욱 명확한 에러 처리가 가능할 것이다. 예를 들어, TaskNotFoundException과 같은 커스텀 예외 정의
2. 로깅: 예외 발생 시 로그를 남겨, 문제 발생 시 원인을 더 쉽게 추적할 수 있도록 할 수 있을 것이다.
3. 테스트 코드 작성: 수정된 코드에 대한 테스트 코드를 작성하여, 예외가 정상적으로 발생하는지 확인한다.

이와 같은 추가 개선 사항을 통해, 더욱 견고하고 유지보수하기 쉬운 코드를 작성할 수 있을 것이라 기대된다.

백엔드와 프론트엔드 간에 데이터 교환 형식 (key : value 형식)

JSON의 직렬화와 역직렬화

직렬화: 외부 시스템에서도 데이터를 사용할 수 있게 바이트(byte) 형식으로 변환하는 기술 역직렬화: 직렬화의 반대

예를 들어 프론트엔드에서 "Hello World" 라고 입력했을 때 백엔드가 해당 데이터(String 타입)을 DB로 넘겨줄 때 데이터 형식을 바꿔줄 필요가 있다. 이것을 역직렬화라고 하며, JSON.parse()로 사용

키-밸류 타입으로 { "content" : "Hello World" } 위와 같은 JSON 형태로 바꿔서 백엔드로 넘겨줘야 백엔드가 저 데이터를 가공해서 데이터베이스로 넣어줄 수 있음

반대로 DB에서 데이터를 가져와서 프론트엔드에 찍어줄 때에도 JSON으로 보내줘야 함.

• 문자열을 객체로 바꿀 때, 프론트엔드의 문자열이 백엔드로 넘어왔을 때 역직렬화
• 객체를 문자열로 바꿀 때 JSON.stringify(), 백엔드에서 다시 프론트엔드로 넘겨줄 때 직렬화

HTTP의 특징

1. 무상태(stateless)

   무상태(stateless) 프로토콜은 각 요청이 독립적으로 처리되며, 서버가 클라이언트의 요청을 기억하지 않는다.

   따라서 클라이언트가 서버에 요청할 때마다, 이전 요청들을 함께 보내줘야 한다.

   로그인 등 상태 유지가 필요한 경우 cookie, token, session등을 활용해야 한다

2. 비연결성(connectionless)

   요청이 끝나면 더이상 연결을 유지하지 않는다.

HTTP 메시지 구조

• HTTP Method: 클라이언트의 의도를 표현하는 명령어로 GET, POST, PUT, PATCH, DELETE 등이 있다
• 상태코드: 서버의 응답 상태를 나타낸다.

      1**(정보), 2**(성공), 3**(리다이렉션), 4**(클라이언트 에러), 5**(서버 에러)

• HTTP Header: Request와 response에 대한 부가 정보를 담고 있다.

HTTP API 설계

HTTP API는 Restful하게 설계해야 사용성과 확장성이 높아진다. 최소 성숙도 레벨 2(리소스와 메서드의 명확한 분리)를 지켜줘야 한다.

Servlet, WAS

• Servlet은 자바에서 요청과 응답을 처리하는데 사용되는 객체이다.
• Servlet Container에서 Servlet객체를 싱글톤(singleton)으로 관리해 자원을 효율적으로 사용한다
• 웹 어플리케이션 서버(WAS)는 여러 사용자의 요청을 Multi Thread로 처리하여 높은 성능을 유지할 수 있다

SSR과 CSR

• SSR(Server-Side Rendering): 서버에서 완성된 HTML 페이지를 브라우저로 보내주는 방식

• CSR(Client-Side Rendering): 브라우저에서 HTTP API 통신으로 데이터를 받아 동적으로 화면을 구성하는 방식

문제 상황

Kiosk 클래스의 start 메서드에서 printMenu 메서드를 호출할 때, 프로그램은 전체적으로 실행되었지만, 원치 않는 출력이 추가로 표시되는 문제가 있었습니다.

원인 분석

• printMenu 메서드가 실행 중 애플리케이션의 상태를 제어할 수 있는 매개변수를 고려하지 않았습니다.
• start 메서드에서 루프 내 조건 없이 printMenu를 호출했기 때문에, 불필요한 출력이 계속해서 생성되었습니다.
• 실행 흐름 제어를 위한 boolean isRunning 변수가 제대로 전달되지 않아, 불필요한 출력이 반복적으로 발생한 것입니다.

해결 방법

1. 매개변수 추가 printMenu 메서드에 boolean isRunning 매개변수를 추가하여, 프로그램의 실행 상태를 기반으로 출력 로직을 제어할 수 있도록 수정했습니다.

2. 호출부 수정 start 메서드에서 isRunning 변수를 적절히 갱신하면서, 이를 printMenu에 전달하도록 업데이트했습니다.

수정된 코드

기존 코드

public void start() {
    while (true) {
        printMenu(cart, scanner);
    }
}

private void printMenu(Cart cart, Scanner scanner) {
    System.out.println("Menu options...");
    // 잘못된 상태에서 불필요한 출력 발생
}

수정 후

결과

• isRunning 변수를 통해 실행 흐름을 명확히 제어하면서 불필요한 출력이 발생하지 않도록 개선되었습니다.
• 프로그램이 의도한 대로 동작하며, 사용자 경험이 향상되었습니다.

배운점

이 문제를 해결하면서 프로그램 실행 흐름 제어의 중요성을 깨달았습니다. 특히, 상태를 관리하는 변수를 명확히 정의하고, 이를 적절히 활용하는 것이 프로그램의 안정성과 유지보수성을 크게 높인다는 점을 배웠습니다.

또한 불필요한 출력을 제어하는 과정에서 로직 설계 단계에서의 매개변수 선정이 얼마나 중요한지를 실감했습니다. 이 경험을 바탕으로, 앞으로는 메서드 설계 시 매개변수로 전달해야 할 상태나 조건을 사전에 꼼꼼히 고려할 것입니다.

클래스를 만들고, 메인 메서드에서 해당 클래스의 필드와 메서드를 사용하려 할 때 Class.feild; Class.method(); 이러한 방식으로 호출할 수 없는 이유는, 인스턴스화 되지 않은 클래스는 실체가 없어서 해당 클래스가 메모리에 올라오지 않았기 때문이다. 클래스가 메모리에 없기 때문에, 해당 클래스의 필드와 메서드도 사용할 수 없는 것은 당연한 일 일거다.

클래스를 사용하려면 Class class = new Class(); 와 같이 먼저 인스턴스화 시켜줘야 한다.

객체로 만들어진 클래스는 메모리로 올라오고, 메모리에 있기 때문에 사용할 수 있다. class.feild;
이렇게 말이다.

그렇다면 System.out.print() 이런 경우는 어떻게 가능할까??

해당 클래스가 static인 경우 인스턴스화 시킬 필요 없이 사용할 수 있다.

static 키워드가 붙어있는 경우, 실행될 때 바로 메모리에 올라간다. 따라서 객체를 만들 필요 없이 바로 사용 가능!

그럼 전부 static으로 만들지, 왜 굳이 힘들게 인스턴스화 시키고 어쩌구 저쩌구 복잡하게 하냐고?? -> static 은 정적이라는 뜻을 가지고 있다. 즉 한 번 메모리에 올라가서 변하지 않는다.

Human human1 = new Human(); Human human2 = new Human();

human1.name = 장원영; human2.name = 차은우;

이렇게 만들어진 객체별로 다른 이름을 가질 수 있어야 하는데, static으로 메모리에 올라간 경우에는 위의 경우 human1, human2 모두 차은우 이름을 가지게 된다.

따라서 의도적으로 static을 사용하는 경우를 제외하고, 대부분의 경우 static을 사용하지 않는다.

모든 메뉴가 출력되었던 이유는 menuItemX.getMenuItem()을 호출했을 때 선택한 메뉴만 출력하는 대신, getMenuItem이 반환하는 문자열을 그대로 출력하기 때문이었음! 문제는 getMenuItem 메서드가 메뉴 이름, 가격, 설명을 전부 포함한 문자열을 반환하도록 설계되어 있다는 점에 있었다.

아래 두가지를 수정할 필요가 있었다.

1. 각 데이터에 접근할 메서드를 별도로 추가하여 필요한 정보만 가져오도록
2. switch 구문에서 getMenuItem() 대신 필요한 데이터만 출력하도록 변경

MenuItem 클래스에서 getMenuItem 대신, 이름/가격/설명의 정보를 가져오는 get메서드를 각각 생성했다.

main메서드 에서는 선택된 메뉴의 이름/가격/설명을 각각 가져와 출력하게 했다.

MenuItem 클래스의 getMenuItem 메서드는 this 객체를 반환하고 있다. 그래서 System.out.println(menuItem.getMenuItem());이 실행될 때 menuItem 객체의 메모리 주소가 출력되고 있다.

이를 수정하려면, MenuItem 클래스에 toString 메서드를 오버라이딩 하거나 getMenuItem 메서드를 수정해 메뉴 이름, 가격, 설명을 반환하도록 해야 할 것이다.

따라서 아래와 같이 수정해보았다.

getMenuItem() 메서드에서 MenuItem의 내용들을 String타입으로 반환하도록 수정하였고, main메서드에서 menuItems 리스트에 저장된 menuItme의 getMenuItem() 메서드를 호출하도록 수정하여 문제를 해결할 수 있었다.

1. Scanner로 입력받을 때 예외 발생

현상: 피연산자, 연산자, 데이터 조회 여부, 저장 여부, 삭제 여부 등등 사용자로 부터 여러 입력을 받아 계산기가 구동하도록 코드를 짰기 때문에, 적절하지 않은 입력이 들어왔을 때 예외가 발생하며 프로그램이 비정상적으로 종료되었다. 이로 인해 예외 이후의 코드가 실행되지 못하고 사용자는 프로그램을 재실행해야만 하는 문제가 있었다.

원인: Scanner.nextInt() 메서드는 입력값이 정수형이 아닌 경우 InputMismatchException을 발생시킨다. 사용자가 잘못된 입력을 하는 경우는 그래도 예외의 원인을 찾기 쉽지만, 입력 버퍼에 개행 문자(\n)이 남아있는 경우에는 이유도 모른채 예외가 발생하곤 한다. 또한 해당 예외를 처리하지 않으면 프로그램이 강제로 종료된다.

해결 과정: 1. 예외 처리 추가 try-catch 블럭을 추가하여 예외가 발생했을 때 프로그램이 종료되지 않고 사용자에게 재입력을 요청하도록 했다.

2. 남은 입력값 제거 입력 버퍼에 남아 있는 잘못된 입력값을 제거하지 않으면 무한 루프에 빠질 위험이 있다. 이를 방지하기 위해 catch블럭에서 Scanner.nextLine()을 호출하여 잘못된 입력을 제거했다.

3. 예외 테스트 다양한 잘못된 입력값(문자, 특수문자, 공백 등)을 입력하여 예외처리가 제대로 작동하는지 확인하였고, 테스트 결과, 오류가 발생했을 때 프로그램이 종료되지 않고 정상적으로 재입력을 받을 수 있음을 확인했다.

결과: 이러한 수정 작업을 통해 사용자 입력 오류가 발생하더라도 프로그램이 종료되지 않고 안정적으로 작동하도록 개선되었으며, 잘못된 입력값으로 인한 무한 루프 문제가 해결되어 프로그램의 사용성을 높였다.

2. List 조회 시 IndexOutOfBoundsException

현상: 저장된 연산결과가 없는 상태에서 사용자가 결과를 조회하려고 getList() 메서드를 호출하면 IndexOutOfBoundsException이 발생하며 프로그램이 종료되었다.

원인: getList() 메서드는 내부적으로 리스트의 마지막 요소를 가져오기 위해 list.get(list.size() - 1)을 호출한다. 그러나 리스트가 비어 있는 경우 list.size()는 0이 되고, 인덱스가 -1로 계산되어 예외가 발생한다. 이는 비어 있는 리스트에 접근하려는 시도가 문제의 핵심

해결 과정: getList() 메서드에 리스트가 비어 있는지 확인하는 조건문을 추가했다. 만약 리스트가 비어 있다면 예외를 발생시키는 대신 사용자에게 "저장된 연산 결과가 없습니다."라는 메시지를 출력하고 null을 반환하도록 수정

결과: 리스트가 비어 있을 때 발생하던 예외를 방지하고, 사용자에게 결과가 없음을 명확히 알릴 수 있도록 프로그램의 안정성과 사용자 경험을 개선. 이는 이후 다른 메서드(removeResult 등)에서도 동일한 문제가 발생하지 않도록 기본적인 방어 코드를 추가하였다.

Enum(열거형)은 여러 상수 값을 하나의 데이터 타입으로 정의할 수 있는 클래스이다. 고정된 값들을 안전하게 다룰 수 있다는 장점이 있고, 클래스처럼 생성자, 메서드 등을 정의할 수 있어서 다양한 기능을 포함할 수 있다.

enum 키워드를 사용하여 정의하며, 기본적으로 아래와 같은 형식을 가진다.

public enum EnumName {
    CONSTANT1,
    CONSTANT2,
    CONSTANT3;
}

과제로 만들고 있는 '사칙연산 수행하는 계산기' 에서 연산자로 받는 문자 종류에 따라 문제가 발생할 수 있어서, 연산자를 Enum으로 정의하여 활용해보았다. 아래와 같다.

기존에 String 타입으로 연산자를 받았을 때 지정된 연산자 이외의 String 값이 실수로 입력되는 경우 문제가 되었는데, 이렇게 enum을 사용하여 해당 문제를 개선할 수 있었다.

그래서 필요한 것이 예외 처리, exception handling 이다.

Exception

발생하는 대부분의 예외들은 이미 예외 처리 방법이 정리 되어 있다. 따라서 이미 있는 예외 클래스를 활용해서 예외 처리를 하면 된다.

예외 클래스로 정리되어 있지 않은 예외라고 해도, 직접 해당 예외를 정의하여 사용하면 된다.

오늘은 이미 구현체가 있는 예외를 처리하는 방법에 대해 먼저 정리해보겠다.

try {} catch {}

try 문에 예외가 발생할 가능성이 있는 코드를 적고 catch 블럭 내에는 예외가 발생했을 때 구현되어야 하는 코드를 적는다.

전체 구조는 아래와 같다.

try {

} catch (Exception1 e1) {

} catch (Exception2 e2) {

}

숫자 2개와 연산자 1개를 받아 사칙연산을 수행하는 계산기를 만드는 과제를 진행하고 있는데, try ~ catch 를 사용하여 예외처리를 해보았다.

if 에서 적합하지 않은 연산자가 확인되면, 예외를 발생 시켜서 throw 하고, 아래 catch 문들 중 해당 예외 조건에 맞는 catch문이 실행된다.

switch에서도 마찬가지로 분모에 0이 들어왔을 때 예외를 발생시켜 throw 하고, catch 문들 중 해당 예외에 맞는 catch 문이 실행된다.

예외를 발생 시켜 throw하지 않는 방식으로도 try ~ catch 를 활용할 수 있다.

아래는 계산 관련 필드와 메서드가 선언되어 있는 클래스를 실행해보는 메인 메서드의 모습 중 일부이다.

계산할 숫자, 연산자 등 Scanner를 통해 입력받는 값이 많아, 오류가 많을 것으로 예상 된다.

따라서 기존에 작성했던 모든 코드들을 try {} 에 넣고, catch (Exception) {} 을 추가하여, 예상치 못한 예외가 발생하였을 때, 비정상 종료 없이 계산기를 계속 실행할 수 있도록 하였다.

그러나 접근제어자로 보호된 데이터를 사용해야 하는 경우도 있지 않겠는가!

이때 필요한 기능이 바로 getter와 setter이다.

Getter

: 외부에서 객체의 private한 필드를 읽어올 필요가 있을 때, getter 메서드를 사용할 수 있다.

ex,

private String model;
private double price;

public String getModel() {
    return model;
}

public double getPrice(){
    return price;
}

getter 메서드의 이름은 카멜케이스를 기초로 하며, 'get + 필드명'으로 짓는 것이 원칙이다.

인스턴스를 생성한 후 인스턴스명.getPrice(); 로 호출하여 getter 메서드를 사용할 수 있다.

Setter

: 외부에서 객체의 private한 필드를 수정/저장해야 할 때, setter 메서드를 사용하면 된다.

ex,

public void setModel(String model){
    this.model = model;
}

public void setPrice(double Price){
    this.price = price;
}

Setter의 이름 짓는 법과 호출 방법은 getter와 동일하다.

실제 사용 예시

계산기 과제를 하다가, 계산 결과를 저장하는 컬랙션을 private으로 캡슐화하고, 해당 데이터를 조회 및 추가 저장 할 수 있도록 getter, setter 메서드를 활용해보았다.

처음에 아래와 같이 코드를 작성해서 체점을 해보니

이런 오류 문구가 떴다.

알아보니, 인덱스의 크기가 배열의 크기보다 크게 나온 경우 혹은 마이너스로 나오는 경우 위와 같은 에러가 난다고 한다.

다시 코드를 보니, 문제를 켰을 때 자동으로 선언되는 배열을 그대로 쓰느라 길이도 제대로 선언하지 않은 것 확인..

이번엔 배열을 제대로 선언했는데,

배열에 들어가는 값을 잘못 계산하도록 한 문제도 있었음!

제대로 계산하도록 바꿨는데도??

테스트 13,14는 계속 오류..ㅠㅠ

다시 찬찬히 살펴보니,

x 크기가 커서 int로 감당할 수 없는 것이었던 것!

프로그래머스에서 기본으로 세팅할 때 왜 long[]이라고 했는지 눈치를 챘었어야 함!

long으로 형변환을 한 뒤에야 마참내 정답!

주어지는 자연수 N의 각 자릿수를 array로 만들고 for문으로 array의 모든 값을 더해주면 되겠다는 생각은 했지만, 문제는 !그래서 그걸 어케 하는 건지! 모르겠었음

1. int를 String으로 형변환 하는 법
2. String을 String Array로 만드는 법
3. String Array를 int Array로 변환하는 법

위 3가지 방법을 하나하나 구글링해서, 숫자의 각 자연수를 array로 만들고 문제를 풀었다..!

1. int를 String으로 형변환

    String str = new String(n + "");

n의 모든 자릿수를 각각 string으로 만들어준다.

2. String을 String Array로

    String strArr[] = str.split("");

strArr이라는 문자 배열을 선언하고 문자열 str의 모든 글자를 쪼개 준다

3. String Array를 int Array로

      int answer[] = new int[strArr.length];
   
    for (int i=0; i<strArr.length; i++) {
        answer[i] = Integer.parseInt(strArr[i]);
    }    

for문을 활용하여 strArr[]의 원소 하나하나를 int로 형변환해줍니다.

이렇게 자연수 N을 int Array로 만들어주었으면, for문으로 array의 요소를 모두 더해주면 끝!

import java.util.*;

public class Solution {
    public int solution(int n) {
        String str = new String(n + "");
        String strArr[] = str.split("");

          int answer[] = new int[strArr.length];

        for (int i=0; i<strArr.length; i++) {
            answer[i] = Integer.parseInt(strArr[i]);
        }        

        int sum = 0;
        for (int i =0; i<answer.length;i++){
            sum = sum +answer[i];
        }

        return sum;
    }
}

원소의 평균값을 리턴해야 하므로, 원소를 다 더하고, 원소의 개수만큼 나눈 값을 리턴하도록 아래와 같이 코딩했는데 실패가 떴다.

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

그 이유는, 자바에선 나누기로 '/'기호를 쓰면 몫만 결과값으로 가지게 되기 때문!

나누기할 때에 소수점까지 결과로 가져오고 싶다면, 나누는 수 혹은 나누어지는 수를 double로 형변환(형 설정?)을 해주어야 한다.

    answer = sum / (double)numbers.length;

    answer = (double)sum / numbers.length;

    answer = (double)sum / (double)numbers.length;

위의 세가지 경우 모두 정답으로 처리 되었다..!

다만 아래와 같이 (double)(sum / numbers.length); 이라고 작성하는 경우에는 정답이 아니게 된다.

자바의 나누기(/) 연산이 끝난 시점에서 이미 소수점 정보를 잃어버린 int로 결과값을 가지게 되어버린 상태이고, 그 이후에 double로 바꿔줘봤자 잃어버린 소수점을 되찾을 수 없어서 라고 해석할 수 있을 것이다.