✅ 작업 기록

0️⃣ 단계 : API 명세 및 ERD 작성

1️⃣ 단계 : 일정 CRUD

❗ 필수 기능 가이드

• 일정을 생성, 조회, 수정, 삭제할 수 있습니다.
• 일정은 아래 필드를 가집니다.
  • 작성 유저명, 할일 제목, 할일 내용, 작성일, 수정일 필드
  • 작성일, 수정일 필드는 JPA Auditing을 활용합니다. → 3주차 JPA Auditing 참고!

2️⃣ 단계 : 일정 수정 및 삭제

❗ 필수 기능 가이드

• 선택한 일정 수정
  • 선택한 일정 내용 중 할일, 작성자명 만 수정 가능
    • 서버에 일정 수정을 요청할 때 비밀번호를 함께 전달합니다.
    • 작성일은 변경할 수 없으며,수정일` 은 수정 완료 시, 수정한 시점으로 변경합니다.
• 선택한 일정 삭제
  • 선택한 일정을 삭제할 수 있습니다.
    • 서버에 일정 수정을 요청할 때 비밀번호를 함께 전달합니다.

3️⃣ 단계 : 연관 관계 설정

❗ 필수 기능 가이드

• 작성자와 일정의 연결
  • 설명
    • 동명이인의 작성자가 있어 어떤 작성자가 등록한 ‘할 일’인지 구별할 수 없음
    • 작성자를 식별하기 위해 이름으로만 관리하던 작성자에게 고유 식별자를 부여합니다.
    • 작성자를 할 일과 분리해서 관리합니다.
    • 작성자 테이블을 생성하고 일정 테이블에 FK를 생성해 연관관계를 설정해 봅니다.
  • 조건
    • 작성자는 이름 외에 이메일, 등록일, 수정일 정보를 가지고 있습니다.
      • 작성자의 정보는 추가로 받을 수 있습니다.(조건만 만족한다면 다른 데이터 추가 가능)
    • 기존 : 고유 식별자를 통해 작성자를 조회할 수 있도록 기존 코드를 변경합니다.
      • 변경 : 작성자의 고유 식별자를 통해 일정이 검색이 될 수 있도록 전체 일정 조회 코드 수정.
    • 작성자의 고유 식별자가 일정 테이블의 외래키가 될 수 있도록 합니다.

4️⃣ 단계 : 페이지네이션

❗ 필수 기능 가이드

• 설명
  • 많은 양의 데이터를 효율적으로 표시하기 위해 데이터를 여러 페이지로 나눕니다.
    • 페이지 번호와페이지 크기`를 쿼리 파라미터로 전달하여 요청하는 항목을 나타냅니다.
    • 전달받은 페이지 번호와 크기를 기준으로 쿼리를 작성하여 필요한 데이터만을 조회하고 반환
• 조건
  • 등록된 일정 목록을 페이지 번호와 크기를 기준으로 모두 조회
  • 조회한 일정 목록에는 작성자 이름이 포함
  • 범위를 넘어선 페이지를 요청하는 경우 빈 배열을 반환
  • Paging 객체를 활용할 수 있음

5️⃣ 단계 : 예외 발생 처리

❗ 필수 기능 가이드

• 설명
  • 예외 상황에 대한 처리를 위해 HTTP 상태 코드(링크)와 에러 메시지를 포함한 정보를 사용하여 예외를 관리할 수 있습니다.
    1. 필요에 따라 사용자 정의 예외 클래스를 생성하여 예외 처리를 수행할 수 있습니다.
    2. @ExceptionHandler를 활용하여 공통 예외 처리를 구현할 수도 있습니다.
    3. 예외가 발생할 경우 적절한 HTTP 상태 코드와 함께 사용자에게 메시지를 전달하여 상황을 관리합니다.
• 조건
  • 수정, 삭제 시 요청할 때 보내는 비밀번호가 일치하지 않을 때 예외가 발생합니다.
  • 선택한 일정 정보를 조회할 수 없을 때 예외가 발생합니다.
    1. 잘못된 정보로 조회하려고 할 때
    2. 이미 삭제된 정보를 조회하려고 할 때

6️⃣ 단계 : null 체크 및 특정 패턴에 대한 검증 수행

❗ 필수 기능 가이드

• 설명
  • 유효성 검사
    1. 잘못된 입력이나 요청을 미리 방지할 수 있습니다.
    2. 데이터의 무결성을 보장하고 애플리케이션의 예측 가능성을 높여줍니다.
    3. Spring에서 제공하는 @Valid 어노테이션을 이용할 수 있습니다.
• 조건
  • 할일은 최대 200자 이내로 제한, 필수값 처리
  • 비밀번호는 필수값 처리
  • 담당자의 이메일 정보가 형식에 맞는지 확인

❓ 과제 제출시에는 아래 질문을 고민해보고 답변 작성

1. 적절한 관심사 분리를 적용하셨나요? (Controller, Service, Repository)

2. RESTful한 API를 설계하셨나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?

3. 수정, 삭제 API의 request를 어떤 방식으로 사용 하셨나요? (param, query, body)

🛠️ 문제 해결 X 회고

작업 후기

소요시간 : 아직 알 수 없음 난이도 : 상

>> Java : JDBC를 사용한 일정 관리 앱 만들기 GitHub Code 바로가기 다 만들어진 코드는 위의 깃허브에 올려놓았다.

public class CalendarCreateRequestDto {
    private String name; // 작성 유저명
    private String title; // 할일 제목
    private String description; // 할일 내용
    private String date; // 작성일
    private String modify; // 수정일

    public String getName() {
        return this.name;
    }

}

내가 작성한 코드는 이렇게 직접 작성하는 방식이었다. 이렇게 작성하면 인텔리제이에서 노란색 줄을 그어서 추천하는 코드를 제안해준다.

public class CalendarCreateRequestDto {
    @Getter
    private String name; // 작성 유저명
    private String title; // 할일 제목
    private String description; // 할일 내용
    private String date; // 작성일
    private String modify; // 수정일
}

이유에 대해 ChatGPT에게 물어보니 아래와 같은 내용을 받을 수 있었다.

직접 Getter 메서드 작성 방식

public String getName() {
    return this.name;
}

장점

• 커스터마이징 가능 : Getter 메서드를 직접 작성하면 값을 반환하기 전에 로직을 추가하거나 반환값을 변형할 수 있다. 예를 들어 name 값을 가공하거나 null 체크를 추가할 수 있다.
• 직관적이고 명시적임 : 클래스의 모든 동작을 코드로 작성하여 클래스에서 제공하는 메서드와 기능을 한 눈에 파악하기 쉽다.

단점

• 보일러플레이트 코드가 많음 : 필드가 많아질수록 Getter와 Setter 메서드를 반복 작성해야해서 코드가 길어지고 유지보수가 어려워질 수 있다.

Lombok의 @Getter 사용방식

@Getter
private String name;

장점

• 간결함 : Lombok을 사용하면 getter 메서드를 자동으로 생성하므로, 코드가 훨씬 간결해지고 유지보수가 용이합니다.
• 표준화 : 코드 작성 스타일이 일관되며, 개발 시간을 절약할 수 있습니다.
• 추가 기능 지원 : Lombok은 다양한 어노테이션 (@Setter, @Builder 등)을 제공하므로 코드 작성이 더 효율적입니다.

단점

• 의존성 필요: Lombok은 별도의 라이브러리이므로, 프로젝트에 Lombok 의존성을 추가해야 합니다. 이는 환경 설정이 제대로 되어 있지 않으면 문제가 될 수 있습니다.
• 코드 명시성 부족: Lombok이 생성한 코드는 실제로 IDE에서 숨겨지므로, 생성된 메서드를 확인하기 어렵습니다. 이를 불편하게 여기는 개발자도 있습니다.

그렇다면 어떤 방식이 더 좋을까?

Lombok을 사용하는 것이 더 효율적이다.

특히 DTO 클래스처럼 Getter와 Setter만 필요한 간단한 객체에는 Lombok을 사용하는 것이 코드 작성하는데 속도를 높이고 유지보수를 쉽게 만들어준다.

하지만, Getter 메서드에 추가적인 로직이 필요하거나 팀에서 Lombok 사용이 금지된 경우 직접 작성하는 방식을 선택해야한다고 한다.

ChatGPT 답변

일반적으로 Lombok을 사용하는 방식이 더 권장되고 이를 통해 코드를 간결하게 유지하며 유지보수 시간도 줄어든다. 하지만 Lombok 설정과 사용 규칙이 프로젝트에서 합의된 경우에 사용하는 것이 좋다.

Lombok 공식문서 바로가기

이전 과제와 작은 변화가 있다면 데이터베이스 연결을 처음으로 시도해보았고 이전보다 시작을 해볼 수 있었음에 조금 기쁘면서도, 해내지 못한 부분이 더 많다는 좌절감이 크게 남았다. 큰 이슈 없이, 입문과제도 못해냈다는 좌절감에 오랜시간 패닉을 겪은 것 같다. 이번 숙련과제는 단순히 내 자신감 부족과 이미 늦어버린게 아닐까 하는 생각으로 내려놓은 내 잘못된 패턴으로 인해 작업을 마무리하지 못했다.

수요일부터 목요일까지 하나씩 마주하며 다시 살펴보고 강의노트를 살펴보며 따라해보니, 크게 어려워하지 않아도 되었던 일임을 깨달았고, 잘못된 생각들로 시간을 낭비했다는 생각이 들었다.

스스로 해내는 것만이 뿌듯한 일이 아니라는 것을 알게 되었고 답이 안나올 때에는 Google이나 ChatGPT에 의존하는 것이 아니라 튜터님들께 여쭤보는 것이 좋다는 것을 깨달았다.

점심을 먹다가 알고리즘으로 인해 보게된 성실한데 성과 못 내는 개발자 특징 Youtube 영상을 보고 확실하게 깨달았다.

✅ 작업 기록

0️⃣ 단계 : API 명세 및 ERD 작성

1️⃣ 단계 : 일정 CRUD

❗ 필수 기능 가이드

• 일정을 생성, 조회, 수정, 삭제할 수 있습니다.
• 일정은 아래 필드를 가집니다.
  • 작성 유저명, 할일 제목, 할일 내용, 작성일, 수정일 필드
  • 작성일, 수정일 필드는 JPA Auditing을 활용합니다. → 3주차 JPA Auditing 참고!

CalendarCreateRequestDto을 생성하는 과정에서 Getter 형식이 2가지가 있어서 어떤 형식이 더 좋은지 궁금해져서 알아보았다.

내가 처음 작성한 Getter는 아래와 같았고

public class CalendarCreateRequestDto {
    private String name; // 작성 유저명
    private String title; // 할일 제목
    private String description; // 할일 내용
    private String date; // 작성일
    private String modify; // 수정일

    public String getName() {
        return this.name;
    }

}

인텔리제이에서 추천해준 Getter는 아래와 같았다.

public class CalendarCreateRequestDto {
    @Getter
    private String name; // 작성 유저명
    private String title; // 할일 제목
    private String description; // 할일 내용
    private String date; // 작성일
    private String modify; // 수정일
}

밤에는 조언을 구하기 어려워서 chatGPT에게 어떤 형식이 좋은 형식인지 질문해보았다. Getter 관련 내용 정리로 따로 작성해놓았는데 상황에 따라 적재적소에 사용해야하는 메소드라는 생각이 들었다.

2️⃣ 단계 : 일정 수정 및 삭제

❗ 필수 기능 가이드

• 선택한 일정 수정
  • 선택한 일정 내용 중 할일, 작성자명 만 수정 가능
    • 서버에 일정 수정을 요청할 때 비밀번호를 함께 전달합니다.
    • 작성일은 변경할 수 없으며,수정일` 은 수정 완료 시, 수정한 시점으로 변경합니다.
• 선택한 일정 삭제
  • 선택한 일정을 삭제할 수 있습니다.
    • 서버에 일정 수정을 요청할 때 비밀번호를 함께 전달합니다.

3️⃣ 단계 : 연관 관계 설정

❗ 필수 기능 가이드

• 작성자와 일정의 연결
  • 설명
    • 동명이인의 작성자가 있어 어떤 작성자가 등록한 ‘할 일’인지 구별할 수 없음
    • 작성자를 식별하기 위해 이름으로만 관리하던 작성자에게 고유 식별자를 부여합니다.
    • 작성자를 할 일과 분리해서 관리합니다.
    • 작성자 테이블을 생성하고 일정 테이블에 FK를 생성해 연관관계를 설정해 봅니다.
  • 조건
    • 작성자는 이름 외에 이메일, 등록일, 수정일 정보를 가지고 있습니다.
      • 작성자의 정보는 추가로 받을 수 있습니다.(조건만 만족한다면 다른 데이터 추가 가능)
    • 기존 : 고유 식별자를 통해 작성자를 조회할 수 있도록 기존 코드를 변경합니다.
      • 변경 : 작성자의 고유 식별자를 통해 일정이 검색이 될 수 있도록 전체 일정 조회 코드 수정.
    • 작성자의 고유 식별자가 일정 테이블의 외래키가 될 수 있도록 합니다.

4️⃣ 단계 : 페이지네이션

❗ 필수 기능 가이드

• 설명
  • 많은 양의 데이터를 효율적으로 표시하기 위해 데이터를 여러 페이지로 나눕니다.
    • 페이지 번호와페이지 크기`를 쿼리 파라미터로 전달하여 요청하는 항목을 나타냅니다.
    • 전달받은 페이지 번호와 크기를 기준으로 쿼리를 작성하여 필요한 데이터만을 조회하고 반환
• 조건
  • 등록된 일정 목록을 페이지 번호와 크기를 기준으로 모두 조회
  • 조회한 일정 목록에는 작성자 이름이 포함
  • 범위를 넘어선 페이지를 요청하는 경우 빈 배열을 반환
  • Paging 객체를 활용할 수 있음

5️⃣ 단계 : 예외 발생 처리

❗ 필수 기능 가이드

• 설명
  • 예외 상황에 대한 처리를 위해 HTTP 상태 코드(링크)와 에러 메시지를 포함한 정보를 사용하여 예외를 관리할 수 있습니다.
    1. 필요에 따라 사용자 정의 예외 클래스를 생성하여 예외 처리를 수행할 수 있습니다.
    2. @ExceptionHandler를 활용하여 공통 예외 처리를 구현할 수도 있습니다.
    3. 예외가 발생할 경우 적절한 HTTP 상태 코드와 함께 사용자에게 메시지를 전달하여 상황을 관리합니다.
• 조건
  • 수정, 삭제 시 요청할 때 보내는 비밀번호가 일치하지 않을 때 예외가 발생합니다.
  • 선택한 일정 정보를 조회할 수 없을 때 예외가 발생합니다.
    1. 잘못된 정보로 조회하려고 할 때
    2. 이미 삭제된 정보를 조회하려고 할 때

6️⃣ 단계 : null 체크 및 특정 패턴에 대한 검증 수행

❗ 필수 기능 가이드

• 설명
  • 유효성 검사
    1. 잘못된 입력이나 요청을 미리 방지할 수 있습니다.
    2. 데이터의 무결성을 보장하고 애플리케이션의 예측 가능성을 높여줍니다.
    3. Spring에서 제공하는 @Valid 어노테이션을 이용할 수 있습니다.
• 조건
  • 할일은 최대 200자 이내로 제한, 필수값 처리
  • 비밀번호는 필수값 처리
  • 담당자의 이메일 정보가 형식에 맞는지 확인

❓ 과제 제출시에는 아래 질문을 고민해보고 답변 작성

1. 적절한 관심사 분리를 적용하셨나요? (Controller, Service, Repository)

2. RESTful한 API를 설계하셨나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?

3. 수정, 삭제 API의 request를 어떤 방식으로 사용 하셨나요? (param, query, body)

🛠️ 문제 해결 X 회고

작업 후기

소요시간 : 아직 알 수 없음 난이도 : 상

>> Java : JDBC를 사용한 일정 관리 앱 만들기 GitHub Code 바로가기 다 만들어진 코드는 위의 깃허브에 올려놓았다.

🚀 오늘의 공부기록 한 눈에 보기

01. 바뀐 밤낮 돌려내고 80% 건강 회복!

과제 제출 기간에 밤샘하느라 밤낮이 바뀌어 수요일까지 고생하다가 드디어 완벽하게 돌려냈다. 앞으로는 더 일찍 일어나서 오전에 헬스장에 다녀오고 점심시간과 수업이 끝났을 때 가벼운 산책을 하는 루틴을 가져야겠다고 절실하게 느꼈다. 나 자신의 스트레스는 없다고 생각하더라도 신체가 느끼는 스트레스는 남다른 것 같았고, 러닝도 못한지 3주가 되어 몸이 아파진게 아닐까? 하는 생각도 들었다. (글루텐 알레르기가 있는데 밀가루를 조금 섭취한 것도 문제가 되었을 듯..)

지금까지의 내 건강 루틴에서 어떤 것을 추가하고 어떻게 시간을 배분하면 좋을지 조금 더 고민해보는 시간을 가져야겠다고 느꼈다.

공부를 하면서도 내 몸에 대해 더 잘알아가야만 취직해서도 걱정없이 살아갈 수 있을 것 같다. 회사를 다니고 있지 않을 때 나에 대해 더 알아가고 방법을 찾아간다면 분명 취업할 시기에는 건강도 지키고 일도 잘하는 인재가 될 수 있지 않을까 하며 작은 상상도 해보았다 😁

🔥 한줄 요약

건강관리도 정말 중요한 부분이라고 생각한다. 뭐랄까, 갑작스럽게 건강하지 못해서 하고자 하는 일을 다해내지 못하거나 팀에 영향을 끼치게 된다면 그건 매우 끔찍한 일인 것을 알고 있기에 이 기간동안 반드시 건강해져야하고, 유지하는 법을 알아내야만 한다고 생각한다

02. 공부방식을 바꾸자! (선 노트 후 블로그)

지금까지는 강의를 들으며 듣는 동시에 모르면 멈추고 구글링, 즉시 블로그에 정리를 하다보니 블로그에 정리하며 키보드로 타자를 치고 있는 내 손만 기억하고 뇌는 기억하지 못한다고 느꼈다. 그래서 우선 아날로그하게 손으로 적으며 공부해보려고 한다. 이해하지 못한 포인트들은 따로 기재해서 튜터님들을 찾아뵈어보려고 한다.

잘못된 공부방식이었기 때문에 머릿속에 남는게 없는 것 같다는 느낌을 받은 것 같다. 이번 과제가 끝나면 프로젝트 진행인데 팀에 민폐를 끼칠 수 없고 취업은 반드시 해야하기 때문에 생존형은 물론, 기술력도 반드시 키워내야만 살아남을 수 있다.

시간을 최대한 쪼개고 쪼개서 지식을 안착시키는데에 집중해봐야겠다. 물론 이전에도 집중을 했지만, 지금와서보니, 두루뭉실하게 계획하고 지내온 것 같다고 느꼈기에 지금이라도 바꾸고 제대로 다시 공부하자고 느꼈다.

2월부터는 실업급여도 종료되서 삶이 약간 퍽퍽해지고 아르바이트와 병행하거나 다른 쪽에서 일정 수입을 가져와야만 하기 때문에 앞으로 최소 2달간 기초를 다지고 제대로 공부해놓아야 2월 중순부터 고생하지 않을 것 같았다. 여러모로 노력해야할 것이 산더미인 것을 다시 한 번 깨달으며 마음을 다져보았다.

🔥 한줄 요약

지금 제대로 바꿔놓지 않는다면 나중에 반드시 크게 후회할 것 같다고 생각이 들었다

02. 스탠다드반이지만 베이직을 듣는다

각 수준별 학습반의 설명을 듣고 베이직이 아니라 스탠다드가 적합하다는 생각에 들어갔지만.. 베이직이 조금 더 이해하기 쉬운 강의와 차근차근 배우는 느낌이 있어서 베이직반의 강의를 올라올 때마다 들어보기로 했다.

우선 최애 튜터님이 강의하시기에.. 안들을 수 없다.. 언제나 최고 ! ! 베이직반은 OT 때부터 Spring 강의가 시작되어서 영상의 30분부터 집중해서 듣기 시작했다.

인텔리제이 안에서 추가하고 프로젝트 시작은 해보았지만, 이런 방법은 처음이라 그대로 따라하면서 기억하고 싶은 부분은 노트에 적어놓았다. 공부는 아무래도 적어놓고 복습하면서 블로그 정리하는 방법이 좋을 것 같았다. (선 노트 후 블로그)

의존성 파일들이 받아지느라 빌드하는데에 시간이 조금 소모되지만, 그건 이전의 방법에서도 동일했기에 괜찮았고 새로운 방법도 나쁘지 않고 오히려 편하게 느껴졌다!

한가득 다운로드된 것을 확인해볼 수 있다! 앞으로 신경쓸일이 거의 없는 부분이지만 캡쳐해서 기록해보았다.

내가 집중해야할 부분은 main과 test 폴더인데 벌써 두근두근하다.

기본적으로 생성해야하는 패키지 구조! (암기해야한다고 하셨다) 보통 이 구조에서 확장하거나 변경하지만 대부분 이 구조로 실무에서 사용된다고 한다.

🚀 오늘의 추천 트렌딩 Top3

오늘 읽은 트렌딩 글 중에 추천하고 싶은, 기억하고 싶은 글을 5개로 추려보았다.

내가 다니는 곳에서 진행한 취업설명회는 아니었지만, 생각보다 의외인 부분들을 알게되고 이력서를 어떻게 작성하면 좋을지 감이 와서 정말 유익하고 좋은 시간이라고 생각이 들었다.

익명으로 질문을 받기도 하셨는데 하나하나 전부 답변해주셔서 질문과 답변도 정리해놓았다. 강의해주신 강사님은 처음엔 작은 기업에 계시다가 야놀자, 우아한 형제들에서 근무하셨다고 이력서를 공개해주셨다. 대강 이렇게 작성하면 됩니다~ 라는 느낌으로 보여주셨는데 어떻게 정리하면될지 감을 잡을 수 있게 해준 포인트가 되었다!

노션에 이렇게 한 페이지로 정리를 해놓았고 이력서를 준비하며 조금씩 매일 수정해보려고 한다! 이전에 만들어놓은 퍼블리셔, 프론트엔드 포트폴리오는 다신 쓸 일이 없을 것 같았다 ㅎㅎ..

🔥 한줄 요약

목표를 잊은 것 같다면 다시 되새기기

과제 관련해서 공부를 제대로 하거나 실습을 제대로 끝마치지 못했어서 2일동안 잠 못자고 계속 강의 다시보면서 실습과 과제를 진행했다. 결국 시간이 부족해 0단계만 해서 제출했다..다음 과제는 반드시 발제 당일에 시작해볼 것이다.

출석은 오전6시부터 가능해서 밤샘 공부하다가 인증했다. 내일부터는 상큼하게 시작하기 위해 밤낮을 바꾸려고 오늘은 일찍 잠들 예정이다!

몸이 한 번 안좋아지면 되돌리는데에만 최소 3일이 걸려서 곤란하고 힘들지만.. 이것도 경험이겠지 하는 마음으로 앞으로 이런 습관을 없애보려고 노력해야겠다.

🔥 한줄 요약

건강하자

학교에서도 캘린더를 보내줬지만 학교 캘린더는 사이즈가 너무 크고 부담스러운데 오늘 도착한 커밋 캘린더는 딱 좋은 아담한 사이즈였다! 항해99에서 문자가 와서 확인했더니 선착순이라길래 후다닥 신청했던 개발자 전용 달력!

깃허브 잔디 심은 날, 하루를 마무리하며 잔디 테이핑도 해주면 된다. (So cute) 오늘은 10일인데 20일에 당당하게 잘못 붙였다. 2일 밤새고나니 제정신이 아닌 듯 하다.

처음부터 보여드리자면 이런 뽁뽁이와 겉에는 단단한 박스로 감싸서 도착했다.

뒷면에는 글이 적힌 카드와 잔디 마스킹테이프가 있었다!

좋은 말과 달력 안에 있는 약간의 오류에 대한 내용이 적혀있다.

정말 왜 20일까지로 붙였을까?..사람은 역시 잠이 중요하고 필요한 것 같다.

🔥 한줄 요약

처음부터 다시 공부해야한다고 느껴서 다시 공부하고 있다. 이게 맞나 싶지만 모르니 반복해야한다고 생각이 들었다

이번 과제는 발제 때부터 기대를 많이 했고 더욱 재미있는 과제라고 생각되어 이전과 다르게 차근차근 이해하며 작업하고 싶었다. 하지만 강의를 다 듣고나서 시작하기 위해 맘먹었을 때 남은 시간은 넉넉하지 못했다. 그래서 이번 과제물은 다음 과제가 나와도 취업해도.. 도전과제를 해낼 때까지 계속 수정을 진행해보려고 한다!

미래를 기약하는 말을 적은데에는 작은 이유가 있었다. 이번 과제는 급성 위경련으로 인해 남은 시간동안 입원해있었다 ^^.. 기말고사, 겨울계절학기, 자격증 공부, 영어 공부가 스트레스 스택을 가득 쌓았었나보다. 그래서 12월 9일 월요일부터 제출하는 순간까지 실습 강의를 되돌려보며 다급하게 작업했고 지금도 수정중이다..!😵 (주말을 반납하고 올인하자! 했던 과거의 나를 반성하고 있다)

화면 구현하는 부분이 필수는 아니지만 생겼다는 점에서 정말 많이 신났었는데.. 괜한 설레발이었다. 내가 유일하게 가장 자신있고 잘하는 부분이 포함되는데 구현은 커녕..레벨 1도 못하고 있다 🫠

다음 과제는 반드시 발제 당일에 도전하리라.

✅ 작업 기록

그래도 하나하나 꼼꼼하게 작업하려고 최대한 노력해보았다.

0️⃣ 단계 : API 명세 및 ERD 작성

👀 API 명세서 작성하기

일정 조회는 다건 조회 와 단건 조회 로 나누었어야하는데 처음 작성할 때에는 단순하게 일정 조회만 작성해서 추가되어있지 않다. 아래에 변경한 API 명세를 추가해보려고 한다!

💡 변경한 API 명세서

👀 ERD 작성하기

+-------------------+
|   Schedule        |
+-------------------+
| id                |
| title             |
| date              |
| time              |
| description       |
| password          |
+-------------------+

ERD는 빈약하지만 현재 상태를 남겨놓은거라 작업하며 추가해보려고 한다.

💡 변경한 ERD

👀 SQL 작성하기

CREATE TABLE Schedule (
id INT AUTO_INCREMENT PRIMARY KEY,
title VARCHAR(100) NOT NULL,
date DATE NOT NULL,
time TIME NOT NULL,
description TEXT,
password VARCHAR(255) NOT NULL
);

1️⃣ 단계 : 일정 생성 및 조회

❗ 필수 기능 가이드

• 일정 생성(일정 작성하기)
  • 일정 생성 시, 포함되어야할 데이터
    • 할일, 작성자명, 비밀번호, 작성/수정일을 저장
    • 작성/수정일은 날짜와 시간을 모두 포함한 형태
  • 각 일정의 고유 식별자(ID)를 자동으로 생성하여 관리
  • 최초 입력 시, 수정일은 작성일과 동일
• 전체 일정 조회(등록된 일정 불러오기)
  • 다음 조건을 바탕으로 등록된 일정 목록을 전부 조회
    • 수정일 (형식 : YYYY-MM-DD)
    • 작성자명
  • 조건 중 한 가지만을 충족하거나, 둘 다 충족을 하지 않을 수도, 두 가지를 모두 충족할 수도 있습니다.
  • 수정일 기준 내림차순으로 정렬하여 조회
• 선택 일정 조회(선택한 일정 정보 불러오기)
  • 선택한 일정 단건의 정보를 조회할 수 있습니다.
  • 일정의 고유 식별자(ID)를 사용하여 조회합니다.

2️⃣ 단계 : 일정 수정 및 삭제

❗ 필수 기능 가이드

• 선택한 일정 수정
  • 선택한 일정 내용 중 할일, 작성자명 만 수정 가능
    • 서버에 일정 수정을 요청할 때 비밀번호를 함께 전달합니다.
    • 작성일은 변경할 수 없으며,수정일` 은 수정 완료 시, 수정한 시점으로 변경합니다.
• 선택한 일정 삭제
  • 선택한 일정을 삭제할 수 있습니다.
    • 서버에 일정 수정을 요청할 때 비밀번호를 함께 전달합니다.

3️⃣ 단계 : 연관 관계 설정

❗ 필수 기능 가이드

• 작성자와 일정의 연결
  • 설명
    • 동명이인의 작성자가 있어 어떤 작성자가 등록한 ‘할 일’인지 구별할 수 없음
    • 작성자를 식별하기 위해 이름으로만 관리하던 작성자에게 고유 식별자를 부여합니다.
    • 작성자를 할 일과 분리해서 관리합니다.
    • 작성자 테이블을 생성하고 일정 테이블에 FK를 생성해 연관관계를 설정해 봅니다.
  • 조건
    • 작성자는 이름 외에 이메일, 등록일, 수정일 정보를 가지고 있습니다.
      • 작성자의 정보는 추가로 받을 수 있습니다.(조건만 만족한다면 다른 데이터 추가 가능)
    • 기존 : 고유 식별자를 통해 작성자를 조회할 수 있도록 기존 코드를 변경합니다.
      • 변경 : 작성자의 고유 식별자를 통해 일정이 검색이 될 수 있도록 전체 일정 조회 코드 수정.
    • 작성자의 고유 식별자가 일정 테이블의 외래키가 될 수 있도록 합니다.

4️⃣ 단계 : 페이지네이션

❗ 필수 기능 가이드

• 설명
  • 많은 양의 데이터를 효율적으로 표시하기 위해 데이터를 여러 페이지로 나눕니다.
    • 페이지 번호와페이지 크기`를 쿼리 파라미터로 전달하여 요청하는 항목을 나타냅니다.
    • 전달받은 페이지 번호와 크기를 기준으로 쿼리를 작성하여 필요한 데이터만을 조회하고 반환
• 조건
  • 등록된 일정 목록을 페이지 번호와 크기를 기준으로 모두 조회
  • 조회한 일정 목록에는 작성자 이름이 포함
  • 범위를 넘어선 페이지를 요청하는 경우 빈 배열을 반환
  • Paging 객체를 활용할 수 있음

5️⃣ 단계 : 예외 발생 처리

❗ 필수 기능 가이드

• 설명
  • 예외 상황에 대한 처리를 위해 HTTP 상태 코드(링크)와 에러 메시지를 포함한 정보를 사용하여 예외를 관리할 수 있습니다.
    1. 필요에 따라 사용자 정의 예외 클래스를 생성하여 예외 처리를 수행할 수 있습니다.
    2. @ExceptionHandler를 활용하여 공통 예외 처리를 구현할 수도 있습니다.
    3. 예외가 발생할 경우 적절한 HTTP 상태 코드와 함께 사용자에게 메시지를 전달하여 상황을 관리합니다.
• 조건
  • 수정, 삭제 시 요청할 때 보내는 비밀번호가 일치하지 않을 때 예외가 발생합니다.
  • 선택한 일정 정보를 조회할 수 없을 때 예외가 발생합니다.
    1. 잘못된 정보로 조회하려고 할 때
    2. 이미 삭제된 정보를 조회하려고 할 때

6️⃣ 단계 : null 체크 및 특정 패턴에 대한 검증 수행

❗ 필수 기능 가이드

• 설명
  • 유효성 검사
    1. 잘못된 입력이나 요청을 미리 방지할 수 있습니다.
    2. 데이터의 무결성을 보장하고 애플리케이션의 예측 가능성을 높여줍니다.
    3. Spring에서 제공하는 @Valid 어노테이션을 이용할 수 있습니다.
• 조건
  • 할일은 최대 200자 이내로 제한, 필수값 처리
  • 비밀번호는 필수값 처리
  • 담당자의 이메일 정보가 형식에 맞는지 확인

❓ 과제 제출시에는 아래 질문을 고민해보고 답변 작성

1. 적절한 관심사 분리를 적용하셨나요? (Controller, Service, Repository)

2. RESTful한 API를 설계하셨나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?

3. 수정, 삭제 API의 request를 어떤 방식으로 사용 하셨나요? (param, query, body)

🛠️ 문제 해결 X 회고

작업 후기

소요시간 : 아직 알 수 없음 난이도 : 상

>> Java : JDBC를 사용한 일정 관리 앱 만들기 GitHub Code 바로가기 다 만들어진 코드는 위의 깃허브에 올려놓았다.

기말고사와 겨울 계절학기 시작으로 인해 2일 연달아 밤샘하는 경우가 하루 건너 일어나고 있다. 순간적으로 내가 나중에 뭐가 되고 싶어서 이렇게 노력하는걸까? 하는 생각이 많이 들면서도 결국 알아낸 것이나 해낸 것이나 진득하게 알고 있는 것이 없어서 정말 괴로웠다.

금요일부터 토요일까지 밤샘하다가 일요일 새벽 1시에 아주 심하게 아픈 복통과 함께 구토를 4번이나 했다. 정말 갑작스러워서 나조차도 너무 당황스러웠다. 편입학도 고려하면서 여러모로 준비하는게 많아서 스트레스가 심했는지 스트레스로 인한 급성 위경련이라는 진단을 받았다.

하하하하. 여기에 아팠던 것도 적는게 맞는지 모르겠지만 기록해놓으면 밤샘을 조금 더 조심한다거나 신체적 스트레스 해소하는 방법에 대해 고민해보는 것을 잊지 않을 것 같았다.

여러모로 노력해야할 부분이 한 둘이 아닌 것 같다. 스프링 입문과제를 시작도 못해서 지금 굉장히 초조하고 조급하다. 당장 시작하기엔 실습조차도 다 마무리하지 않은 상황이라 조금 울고 싶지만 최대한 작업해보려고 한다..!

🔥 한줄 요약

울지마 박지안

🚀 오늘의 공부기록 한 눈에 보기

>> Spring : MVC 패턴

01. 생소한 용어가 많아서 무한 복습

공부방식을 계속 변경하다보니 조금 적응하는데 시간이 걸리는 것 같다. 더군다나, 스프링 강사님의 강의는 너무나도.. 준비된 프린트물 읽기 형식이며.. 흥미를 잃게 만드는 특유의 말투와 목소리가 있어서 배울 때 조금씩 지루해진다.

구매한 책을 읽으며 공부하면 그렇게 재미있을 수가 없는데 왜 이러는걸까 ㅠㅠ

🔥 한줄 요약

생소한 용어가 많아서 더 어려운 편이지만, 그래도 열심히 해보자!

동적인 웹 페이지를 생성하기 위해 사용되는 도구이며 템플릿을 기반으로 정적인 부분과 동적인 데이터를 결합하여 HTML, XML 등의 문서를 생성하는 역할을 수행함

(우리가 흔히 말하는 UI를 만들며 SSR에 사용됨)

템플릿 엔진이 나온 이유

• 자바 코드로 HTML을 만들어내는 것이 아닌 HTML 문서에 동적으로 변경해야하는 부분만 자바 코드를 넣을 수 있다면 더 편리하기 때문

대표적인 템플릿 엔진

• Thymeleaf : Spring과 통합이 잘되어있고 다양한 기능을 포함하고 있음
• JSP : 예전에는 많이 사용했으나 현재는 사용하지 않는 추세
• FreeMarker
• Velocity
• Mustache

MVC 패턴

Servlet이나 JSP만으로 비즈니스 로직과 View Redering까지 모두 처리하면 너무 많은 역할을 하게 되고 책임이 너무 많기 때문에 유지보수가 굉장히 어려워져서 고안된 패턴 Web Appliction은 일반적으로 MVC(Model View Controller) 패턴을 사용함

Servlet 예시

@WebServlet("/hello-world")
public class HelloWorldServlet extends HttpServlet {

        // User 저장소
    private UserRepository repository = new UserRepository();

    public HelloWorldServlet() {
        super();
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
        throws ServletException, IOException {

        response.setContentType("text/html;charset=utf-8");
        PrintWriter out = response.getWriter();

        try {
            // 비지니스 로직을 처리하는 코드
            // 파라미터 조회 
            String userIdParam = request.getParameter("userId");
            Long userId = null;
            if (userIdParam != null) {
                userId = Long.parseLong(userIdParam);
            }

            // 회원 조회 
            String userInfo = repository.findById(userId);

            // 화면을 그리는 코드 START
            out.println("<h1>Hello World!</h1>");
            out.println("<div>조회한 회원의 정보: " + userInfo + "</div>");
            // 화면을 그리는 코드 END


        } catch (NumberFormatException e) {
            // parsing 에러가 발생한 경우
            out.println("<div>Invalid user ID format</div>");
        } finally {
            out.close();
        }
    }

    protected void doPost(HttpServletRequest request, HttpServletResponse response) 
        throws ServletException, IOException {        
        doGet(request, response);
    }
}

Servlet 문제점

• 화면을 그리는 View 영역과 비즈니스 로직이 Servlet 하나에 모두 섞여있음
• 책임을 너무 많이 가지고 있음

Servlet 동작 순서

1. 사용자가 Client(브라우저)를 통해 서버에 HTTP Request 즉, API 요청을 한다.
2. 요청을 받은 Servlet 컨테이너는 HttpServletRequest, HttpServletResponse객체를 생성한다.
3. 설정된 정보(URL, HTTP Method)를 통해 어떠한 Servlet에 대한 요청인지 찾는다.
4. 해당 Servlet에서 service 메서드를 호출한 뒤 브라우저의 요청 Method에 따라 doGet() 혹은doPost() 등의 메서드를 호출한다.
5. 서버에서 응답을 생성한 뒤 HttpServletResponse객체에 응답을 담아 Client(브라우저)에 반환한다.
6. 응답이 완료되면 생성한 HttpServletRequest, HttpServletResponse객체를 소멸한다.

JSP 예시

Servlet 코드에서 HTML을 만드는 부분인 View가 분리되었음

<%@ page language="java" contentType="text/html; charset=UTF-8"
    pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title></title>
</head>
<body>
        <!-- HTML 코드... -->
        <!-- <%...%> 영역에는 Java 코드를 사용할 수 있다. -->
    <%
            // 게시글 저장소 싱글톤으로 인스턴스 생성
            BoardRepository boardRepository = BoardRepository.getInstance();

            // 게시글 제목, 내용 
        String title = request.getParameter("title");
        String content = request.getParameter("content");

        // 게시글 객체 생성
        Board board = new Baord(title, content);

        // 게시글 객체 저장
        repository.save(board);

    %>
    <div>
        ID : <input type ="text" name = "id" value="<%=id %>">
    </div>
        <!-- JSP 코드... -->
        <!-- HTML 코드... -->
    <jsp:forward page="<%=url %>" />
</body>
</html>

Servlet, JSP 방식의 문제점

1. Servlet만을 사용한 경우 View를 위한 코드와 비지니스 로직을 처리하는 코드가 Servlet에 모두 존재하여 유지보수가 어려워진다.
2. JSP를 사용하여 View를 분리하였지만 비지니스 로직의 일부가 JSP 파일안에 존재한다. 여전히 책임이 많아 유지보수가 어렵다.

MVC 패턴

하나의 Servlet이나 JSP로 처리하던 것들을 Model, View, Controller 영역으로 나눈것

MVC패턴의 핵심

• View가 분리된 이유의 핵심은 변경이다.
• 기획이 변하지 않는 이상 비지니스 로직과 View의 수정 원인은 별개로 발생한다.
  • 화면 구성에 수정이 발생하면 View만 변경
  • 요구사항에 수정이 발생하는 경우 비지니스 로직 변경
• 즉, 서로 연관이 없는 코드끼리 함께 존재할 필요가 없다. 완전히 분리하자

Controller

1. HTTP Request를 전달받아 파라미터를 검증
2. 비지니스 로직을 실행
   • 비지니스 로직을 Controller에 포함하게되면 Controller가 너무 많은 역할을 담당하게 되어 일반적으로 Service Layer를 별도로 만들어서 처리
   • Database와 상호작용 하는 Layer를 따로 구분하여 Repository Layer를 추가로 구성함
   • Controller도 비지니스 로직을 포함할 수 있지만 일반적으로 Service Layer를 호출하는 역할을 담당함
3. View에 전달할 결과를 조회하여 Model 객체에 임시로 저장

Model

1. View에 출력할 Data를 저장하는 객체
2. View는 비지니스 로직이나 Data 접근을 몰라도 되고 View Rendering에만 집중(책임 분리)

View

• 예시 코드에서 JSP에 해당하는 영역

1. Model 객체에 담겨져 있는 Data를 사용하여 화면을 Rendering함

날씨가 추워서 무기력해진 몸을 이끌고 공부를 하다가 잠깐 쉬었다가 할까? 하면 1시간이 순식간에 사라진다. 그 후, 잃은 1시간을 매꾸겠다며 다시 공부하기를 반복하면 어느새 다음날 새벽 5시가 되어있다.

그래서 요즘 TIL도 반나절 ~ 하루씩 밀려쓰게 되는 것 같다.

다시 감기에 걸려서 힘내기 어렵지만 그래도 다시 한 번 힘내서 다음주는 꼭 제대로 집중하고 정규 시간에 맞춰 지내고 싶다. 더이상 밤낮이 바뀌고 면역력이 약해지는 건 사절이다.

🔥 한줄 요약

평균 수면시간만 지킨다고 건강을 지킬 수 있는 것은 아니었다

파이썬 프로그래밍 과목에서 기말고사 대체 과제를 받게 되어 작업했던 팩맨게임 기반의 게임!

파이썬은 학교에서 배우면서 처음 사용해보았는데 재미를 먼저 느끼도록 도와주신 교수님의 커리큘럼과 과제 주제에도 자율도를 높여주신 덕에 시간이 촉박해도 정말 재미있게 작업했다고 느꼈다. 2일동안 밤을 새도 즐거운 마음으로 코딩하고 자료도 만들었어서 대학생활 3년 중 가장 뿌듯하고 행복했다!

그 결과 100점을 받았다! 교수님을 이번 과목에서 처음 뵌게 아닌데 과제를 100점 맞아본 것은 정말 처음이었다! 호다닥 교수님의 피드백도 살펴보았는데 만들어놓은 게임을 확장하는 과정에서 어려움이 있다면 언제든지 메일을 줘도 괜찮다며 한 학기동안 열심히 해주어 고맙다는 글을 남겨주셨다! 내가 더 감사한 일이지만.. 너무너무 기쁘고 행복했다 🥹

과제 관련 글도 남겨놓고 싶은데 그건 티스토리에 작성하게될 것 같다. 산타팩맨게임도 조금 더 확장하면 블로그에 연동해볼 생각을 하고 있다 ㅎㅎ

🔥 한줄 요약

과제 성적을 확인하고나니 한결 마음이 놓인다. 올해도 전액장학 가능하려나..?! 두근두근

MBTI의 I가 100%라서 그런지 누군가에게 먼저 다가가는 일이 조금 많이 어려운 편에 속했다. 궁금한 것이 있어도 최대한 구글링과 챗GPT에게 물어보았는데 이번에는 직접 찾아뵈어야만 한다는 생각이 들었기에 용기를 내서 찾아뵙는 시뮬레이션만 2일동안 10번 정도 돌린 것 같다.

이런 어려움을 이해하는 이전 팀원 분들이 굉장히 많이 응원해주시고 본인만의 방법들을 많이 공유해주셨다..! 그 덕에 내가 직접 찾아뵈어 진행되는 튜터링을 경험해볼 수 있었다!

튜터님께 가보았기에 알 수 있는 것들에 대해 열심히 필기했다! 그 중 캡쳐해서 남긴 부분은 이 파트인데 가시성이 떨어지는 코드를 작성했어서 가급적이면 어떻게 표기하면 좋을지에 대해 공유해주셨다!

이 이미지는 이전 팀원분이 찍어준 것인데 다같이 기뻐해주고 축하해주고 격려해주는 분위기이었기에 힘을 내서 어려움을 이겨낼 수 있었던 것이 아니었을까 싶었다.

현재 함께 팀원인 분도 굉장히 반겨주시고 격려를 많이 해주셔서 너무너무 감사하고 기쁜 날이었다!

🔥 한줄 요약

따뜻한 사람들의 도움 덕에 가장 어려운 관문을 한 번 넘어보았고 마음이 몽글몽글 따뜻해졌다

🚀 오늘의 공부기록 한 눈에 보기

>> 궁금증 해소 : 왜 메이븐(Maven)보다 그레이들(Gradle)을 더 많이 사용하게 되었을까?

01. 메이븐(Maven)과 그레이들(Gradle)의 차이

인텔리제이(InteliJ)의 IDEA를 사용하다보면 아래 이미지와 같은 부분을 볼 수 있는데 이 부분의 차이를 오늘에서야 알게 되었다! 이 부분에 대해 진작 궁금했지만, 제대로 알아볼 생각은 미처 하지 못했었다. Spring으로 넘어오면서 이들에 대해 알게 되었는데 아래에 정리해보았다.

새 프로젝트를 생성할 때 Build system 을 선택하도록 되어있는 부분을 확인해볼 수 있다. 메이븐과 그레이들, 이 둘은 모두 자바 생태계에서 사용하는 빌드 관리 도구이다.

우리가 사용하는 소스 코드는 사용자가 바로 사용할 수 없는 형태이기 때문에 사용자가 애플리케이션 형태로 사용할 수 있는 모습을 갖추려면 빌드라는 과정을 거쳐야한다고 한다. 이런 빌드 과정에서 필요한 것들을 관리하고 자동화하는 도구를 빌드 관리 도구 라고 한다.

이 과정에는 의존성 내려받기, 코드 패키징, 컴파일, 테스트 실행 등이 포함되어 있다. 그리고 예전에는 메이븐을 많이 사용했지만, 요즘은 그레이들을 많이 사용하는 추세라고 한다.

그레이들(Gradle)의 특징

• 메이븐에 비해 가독성이 좋고 설정이 간단하다.
• 자바, 코틀린, 그루비 등 다양한 언어를 지원하며 원하는대로 빌드 스크립트를 작성할 수 있다.
• 빌드와 테스트 속도가 메이븐에 비해 더 빠르다.

메이븐에 비해 가독성이 좋고 설정이 간단하다는 이유에서 그레이들을 많이 사용하는 추세로 바뀌었던걸까? 이 3가지만으로 변경했다면 왜 이전에는 메이븐을 더 많이 사용했을까? 안정성이 보장되지 않았던걸까? 더욱 궁금해졌다.

이렇게 상세하게 궁금해지는 궁금증은 그 때 그 때 해소하는 것이 제 맛!

그레이들을 더 많이 사용하게 된 계기를 알려면 메이븐에 대해서 정확하게 짚고 이해하는 편이 좋겠다는 생각이 들어 메이븐에 대해 먼저 알아보았다.

음 내용이 길어져서 오늘의 공부기록 한 눈에 보기로 게시물을 따로 만들었다! 궁금한 점을 해소하다가 추가적으로 알게된 것은 빌드 관리 도구에 `Maven과 Gradle만 있었던 것이 아닌, 초창기에는 Ant도 있었다는 것이다!

>> 궁금증 해소 : 왜 메이븐(Maven)보다 그레이들(Gradle)을 더 많이 사용하게 되었을까? 보러가기

🔥 한줄 요약

공부할 시간이 부족하더라도 짚고 넘어가고 싶다는 생각이 들면 알아보는 것이 좋지 않을까 싶었다

02. 도전 Spring Boot

원래는 Spring을 먼저 차근차근해야하지만, Spring 입문 강의를 모두 들었고, 강의가 조금 미흡한 면이 있어서 (도저히 해당 강의만으로 과제를 할 자신이 없었음) 구매해놓았던 책을 보며 따라해보기로 결정했다.

개발환경 구축 과정에서 일어난 몇가지 문제 기록!

스프링부트 기본서를 보며 똑같이 잘 따라했는데도 왜? 오류가 발생하고 컴파일 에러는 왜 발생하지? 라는 생각에 1분 정도 고민하다가 모르겠어서 ChatGPT에게 물어보게 되었다.

자동 완성 기능으로 인한 오타 발생

추천으로 나오는 영문이 비슷하다는 생각에 Tab을 눌러 자동완성했다가 잘못 입력된 것을 뒤늦게 확인하고 수정하게 되었다. 하지만 이 한가지로 해결되지 않았고 오류메세지는 build.Gradle 을 바라보았기에 해당 부분도 도움을 받아보았다.

두번째도 오타로 인한 오류 발생

r을 빼먹은 나.. 정말 멋지다.. 그래도 수정하고 나니 정상적으로 작동해서 다행이라고 느꼈다. 앞으로는 눈을 더 크게 뜨고 꼼꼼히 살펴봐야겠다고 느꼈다.

build.Gradle 을 수정한 후 다시 임포트 했다. (새로고침!)

생성했던 클래스를 다시 실행해보니 이렇게 성공한 콘솔창을 확인해볼 수 있었다! (30초 동안 박수치며 기뻐함)

책을 읽어보니 맨 아래에 있는 이 부분을 확인해보라고 했다. 스프링 애플리케이션이 시작되었음을 의미하는 코드라고 한다!

제대로 실행됬다는 것을 알 수 있다!

404에러페이지인데 뭐가 제대로 실행됬느냐 물으신다면, localhost:8080을 요청함면 index.html을 찾도록 설정되어 있는데 index.html 파일이 없기 때문!

index.html 파일을 넣고 나면 오류 페이지가 나오지 않고 연결한 파일이 잘 나오는 것을 확인해볼 수 있었다!

🔥 한줄 요약

냅다 도전했을 때 가장 큰 즐거움을 느껴서 조금 당황했다

🚀 오늘의 추천 트렌딩 Top3

오늘 읽은 트렌딩 글 중에 추천하고 싶은, 기억하고 싶은 글을 5개로 추려보았다. 01. Spring Framework?? 그게 뭔데? 02. IoC? DI? 그게 뭔데? 03. 스프링 Bean, IoC Container, DI가 뭔데!!

새 프로젝트를 생성할 때 Build system 을 선택하도록 되어있는 부분을 확인해볼 수 있다. 메이븐과 그레이들, 이 둘은 모두 자바 생태계에서 사용하는 빌드 관리 도구이다.

우리가 사용하는 소스 코드는 사용자가 바로 사용할 수 없는 형태이기 때문에 사용자가 애플리케이션 형태로 사용할 수 있는 모습을 갖추려면 빌드라는 과정을 거쳐야한다고 한다. 이런 빌드 과정에서 필요한 것들을 관리하고 자동화하는 도구를 빌드 관리 도구 라고 한다.

이 과정에는 의존성 내려받기, 코드 패키징, 컴파일, 테스트 실행 등이 포함되어 있다. 그리고 예전에는 메이븐을 많이 사용했지만, 요즘은 그레이들을 많이 사용하는 추세라고 한다.

그레이들(Gradle)의 특징

• 메이븐에 비해 가독성이 좋고 설정이 간단하다.
• 자바, 코틀린, 그루비 등 다양한 언어를 지원하며 원하는대로 빌드 스크립트를 작성할 수 있다.
• 빌드와 테스트 속도가 메이븐에 비해 더 빠르다.

하지만 이런 간단한 특징 3가지만으로 메이븐에서 그레이들로 이동한 이유를 납득하지 못했다. 내가 사용하는 모든 도구와 행동에는 이유가 명확해야한다고 생각하기 때문에 우선, 메이븐이 무엇인지에 대해 알아보기로 했다.

Maven

앞서 설명한 것과 동일하게 Java프로젝트를 위한 빌드 자동화 도구로 빌드, 패키징(jar 또는 war 생성), 테스트, 외부 라이브러리 관리 및 배포 등을 한 번의 명령으로 간편하게 처리할 수 있다.

과거에는 필요한 라이브러리를 직접 다운로드하고 프로젝트 폴더에 수동으로 배치해 관리해야 했기에 라이브러리의 버전이 변경될 때마다 다시 다운로드하고 업데이트해야하는 번거로움이 많았다고 한다.

Maven이 등장하기 이전에는 Ant라는 빌드 관리 도구를 사용했지만, Ant에는 외부 라이브러리 관리 기능이 부족해서 부족한 점을 보완해 나온 것이 Maven 이 등장한 것이었다. 단점을 보완하는 동시에 표준화된 프로젝트 구조와 빌드 방식을 지원해 빌드 작업을 더욱 간소화하고 효율적으로 만들어주었다고 한다.

메이븐 간단 정리

자동으로 빌드 및 테스트, 패키징을 자동으로 수행해주어 개발 생산성 향사! Maven은 POM.xml(Project Object Model) 파일을 사용해 빌드 설정을 관리함 다양한 프로젝트를 빠르게 생성하기 위한 아키타입(archeType)을 제공함 단점 : XML기반의 빌드 파일을 사용해 가독성이 떨어짐

Gradle

2007년 JetBrains 회사의 Hans Docter가 개발한 오픈 소스 빌드 자동화 도구로 Apache Ant와 Apache Maven의 장점을 결합하여 만들어졌다. Groovy 기반 스크립트 방식을 사용하여 build.gradle 이라는 빌드 파일을 만들기 때문에 가독성이 좋고 스크립트를 통해 여러가지 상황에 적합한 빌드를 만들어낼 수 있다. (유연함!)

이러한 유연성 덕에 빌드 과정에서 병렬 처리와 캐싱을 활용해 Maven보다 10~100배까지 향상된 성능을 구현할 수 있게 되었다. 이런 장점 덕에 안드로이드 개발을 위한 공식 빌드 도구로 지정되었고 안드로이드 애플리케이션을 빌드하고 관리할 때 많이 사용되고 있다고 한다.

그레이들(Gradle) 간단정리

• 메이븐에 비해 가독성이 좋고 설정이 간단하다.
• 자바, 코틀린, 그루비 등 다양한 언어를 지원하며 원하는대로 빌드 스크립트를 작성할 수 있다.
• 빌드와 테스트 속도가 메이븐에 비해 더 빠르다.

Gradle User Manual

Maven과 Gradle 차이점 총정리!

Maven과 Gradle은 어떤 프로젝트에 적합할까?

Maven과 Gradle을 알아보니, 보완하여 나온 관계이지만 각각의 장점과 특성이 명확하한 빌드 도구라는 생각이 들었다. 그렇다면 이 둘을 어떨 때 사용해야 효율적으로 쓸 수 있을지 고민해보았다!

Maven : 간단한 프로젝트 or 명확한 구조와 표준화가 요구되는 프로젝트

Maven은 단순하고 일관된 빌드 생명 주기를 제공하고 표준화된 프로젝트 관리에 뛰어나기 때문

Gradle : 성능 최적화가 필요하거나 복잡한 빌드 프로세스를 관리해야하는 경우

Gradle은 유연한 구성과 뛰어는 성능을 제공하기에 Groovy 스크립트 언어를 사용해 복잡한 빌드 요구사항을 효과적으로 처리할 수 있기 때문

각각 최적의 용도에 맞춰 프로젝트에 활용한다면 프로젝트 관리와 빌드 프로세스의 효율성을 크게 향상시킬 수 있을 것 같아서 반드시 기억해두어야할 것 같다고 생각이 들었다.

강의 1.5배속으로 다시 들으며 자바 문법 기본서를 읽으며 실습해보는 사이에 8시가 되었다. 8시부터는 학교 기말고사가 있어서 시험에 집중을 했고 9시 30분부터 다시 기본서를 살펴보며 실습했다.

TIL이 상당하게 빈약해지고 있지만, 내일부터 다시 열심히 적어보려고 한다.

내일은 베이직반 OT가 열리는데 솔직히.. 스탠다드보다 베이직이 맞지 않나 라는 생각을 하고 있어서 꼼꼼히 들어보려고한다..!

🔥 한줄 요약

내가 정말 잘 하고 있는건지 의심스러운 요즘

Java를 사용합 웹 개발의 시초로 서버에서 동적으로 콘텐츠를 생성하기 위해 사용되었고 클라이언트의 요청을 받고 그에 대한 응답을 생성하는 기본적인 구조를 제공했다

Servlet의 단점

코드의 복잡성이 증가하고 유지보수가 어려워졌음

JSP(Java Server Pages) 도입(1999)

JSP는 HTML 내에 Java 코드를 삽입할 수 있는 기술로 웹페이지를 더 쉽게 동적으로 생성할 수 있도록 도와주었음

JSP의 단점

JSP 내에 비즈니스 로직을 분리할 수 없음

Servlet, JSP 기반의 MVC 패턴 도입

• MVC 패턴이 도입되면서 UI, 비즈니스로직, 데이터를 분리하여 개발하는 방식이 등장함
• Servlet은 주로 컨트롤러(비즈니스 로직)으로 사용되었고 JSP는 뷰(UI)를 담당하게 되었음

MVC패턴의 장점

웹 애플리케이션의 유지보수성과 확장성을 크게 향상시킴

MVC패턴의 단점

개발자가 중복적으로 설정해줘야 하는 부분들이 다수 발생함

MVC 프레임워크의 등장과 발전(2000~2010)

• Struts, Spring 등의 MVC 프레임워크가 등장하며 웹 애플리케이션 개발이 더욱 구조화되고 효율적으로 변했다.
• 그 중 Spring MVC는 단순하면서도 강력한 기능을 제공하여 Java 웹 개발의 표준으로 자리 잡게 되었다.
• 중복적으로 설정해야하는 부분들을 프레임워크로 자동화했다

MVC패턴의 단점

• 여전히 애플리케이션 개발 관련 설정이 복잡했다.

Annotation 기반의 Spring MVC(2007~현재)

Annotation을 통해 애플리케이션 설정의 복잡함을 줄여주었다

Annotation 기반의 Spring MVC 장점

더 직관적이고 간결한 방식으로 웹 애플리케이션을 개발할 수 있게 되었다

Spring Boot의 등장(2014~현재)

Spring 프레임워크를 보다 쉽게 사용하도록 만든 도구로 설정과 복잡한 초기 설정 작업을 자동하 함

Spring Boot 장점

개발자들이 빠르게 애플리케이션을 개발할 수 있도록 도와줌

최신기술 동향

Web Servlet

Spring MVC - 안정적이고 동기식 프로그래밍 모델을 기반으로 한 웹 애플리케이션 개발에 널리 사용됨

Web Reactive

Spring WebFlux - 비동기 및 넌블로킹 모델을 기반으로 한 웹 프레임워크로 높은 동시성을 요구하는애플리케이션에서 효율적인 성능을 제공한다. 함수형 프로그래밍 스타일을 지원하며 서블릿 기술 대신 Netty 등의 비동기 서버를 사용한다. - 서블릿 기술을 사용하지 않으며 실시간 데이터를 처리하거나 높은 동시성을 요구하는 애플리케이션에 적합하다 - RDBMS 지원 부족과 높은 기술적 난이도 등으로 인해 아직은 MVC 모델이 많은 실무에서 더 많이 사용되고 있다.

🚀 오늘의 공부기록 한 눈에 보기

>> Spring 기초 : Spring Framework, Spring Boot >> Spring 기초 : 빌드 관리 도구 Gradle >> Spring 기초 : Java의 역사

01. 강의를 듣고 있지만 아직 어려운 Spring

Spring 강의를 2배속으로 1회차 수강 완료했다. 이제 2번째로 수강할 때는 실습을 하며 1.5배속으로 진행해보고자 한다. 이 방법은 한 튜터님의 추천 방법으로 내게 맞는지 확인해보는 과정이라고 볼 수 있다!

아직은 이해가 잘 안되지만 반복해서 공부하다보면 이해하고 눈으로 보이는 부분들이 있지 않을까 싶다. TIL에 투자하는 시간이 점점 더 적어져서 조금 걱정이 되지만, 우선 강의 수강과 실습에 조금 더 투자하면 좋을 것 같다는 생각이 더 큰 것 같다. 내일도 화이팅!

🔥 한줄 요약

TIL 작성 시간이 20분 정도였지만 5분으로 줄어들어버린 요즘

Java와 유사한 문법 구조를 가진 Groovy 기반의 스크립트 언어를 사용하며 다양한 소프트웨어를 빌드할 수 있는 유연한 빌드 자동화 도구

빌드(Build)

• 소스 코드를 컴퓨터가 실행 가능한 파일로 변환해주는 작업

• 빌드에 필요한 과정

Gradle의 특징

1. 유연성 복잡한 빌드 시나리오를 처리할 수 있는 유연한 시스템 제공 빌드 스크립트를 통해 다양한 빌드 작업을 정의하고 필요한 경우 커스터마이징할 수 있음

2. 성능

• Build Cache 빌드 결과물을 캐싱하여 재사용 함 라이브러리 의존성을 캐싱하여 재사용 함

• 점진적 빌드 마지막 빌드 호출 이후 변경된 부분만 빌드함 변경되지 않은 부분은 캐시 결과를 검색해 재사용함

• 데몬 프로세스 다음 빌드 작업을 위해 백그라운드에서 대기하는 프로세스 초기 빌드 이후부터는 빌드 실행 시 초기화 작업을 거치지 않음

3. 멀티 프로젝트 빌드 지원

공통으로 사용하는 클래스를 모듈로 만들어 독립적인 각 프로젝트에서 사용할 수 있도록 함

4. 설정 주입 방식 필요한 설정을 직접 프로젝트에 주입하는 방식 공통되는 정보는 묶어서 한 번에 주입이 가능함 프로젝트 별로 설정을 다르게 주입할 수 있음