[2주차] Git & Github, 스프링부트

---

Git

:(소프트웨어 개발에서 코드의 변경 사항을 기록,관리) 분산 버전 관리 시스템

Github 

: git을 사용하는 프로젝트를 지원하는 웹 호스팅 서비스

---

repository(저장소)

- local repository(로컬 저장소) ; 내 컴퓨터 안에 저장소

: 네트워크 연결없이 작업 내용을 커밋하거나 과거 기록 조회 가능. 커밋들이 영구적으로 저장되는 영역

 

- remote repository(원격 저장소) ; 외부 서버(gitbub 등)에 위치한 저장소

: 여러사람이 공유 가능

 

- upstream : 소스 원형이 기록된 서버 저장소

- origin : 원형을 복제하여 만든 나의 서버 저장소(기본 원격 저장소)

---

용어정리

- 기본 구조

• Working Directory : 작업 디렉토리. Git이 관리하지만 추적하지 않음
• Staging Area : 작업 내용이 올라가는 임시 저장 영역(=index)

- 작업 흐름

• commit : 프로젝트의 현재 상태를 나타내는 체크포인트 또는 스냅샷(과거 모든기록이 타임라인으로 남음)
• add : 파일을 working directory에서 staging area로 옮기는 작업
• push : 로컬의 commit을 원격 저장소로 업로드
• pull : 원격 저장소의 변경 사항을 로컬에 저장하는 과정
• fetch : 원격 저장소의 변경 사항을 로컬 저장소에 pull하기 전에 미리 확인만 하는 기능
• clone : 원격 저장소의 모든 데이터를 나의 로컬 저장소로 복제해오는 기능

- 협업 관련

• branch : 독립적 작업흐름을 위한 가지치기. 작업은 현재 상태를 복사한 브랜치에서 해야함
• merge : 분리된 브랜치에서의 작업을 다시 메인 브랜치로 합치기(브랜치 간 충돌 주의)
• head : 현재 내가 작업 중인 브랜치의 가장 최신 커밋을 가리키는 포인터
• switch : 작업중인 브랜치를 변경
• checkout : 특정 커밋 시점으로 이동
• conflict : 같은 파일의 같은 부분을 두명이 동시에 수정했을 때 git이 자동으로 합치지 못해 발생. 개발자가 직접 해결해야 함

 

- Github 및 오픈소스 관련 용어

• fork : 다른 사람의 원격 저장소를 내 원격 저장소로 복제
• pull request : 내가 작업한 내용을 원본 저장소에 반영해달라고 요청
• issue : 프로제트의 버그, 건의사항, 할 일 등을 기록하고 논의하는 게시판

 

• .gitignore : Git 버전 관리에서 제외할 파일 목록을 지정하는 파일

 

+) fork한 repository: 원본 변화시 상태 변화없음. 반영 시키려면 github에서 'Sync Fork'

clone된 로컬: 원본 변화시 상태 변화없음. 반영 시키려면 터미널에서 git pull 또는 fetch 실행

---

스프링부트

: 스프링 프레임 워크를 기반으로 한, 스프링을 더 쉽게 이용하기 위한 도구

 

+) 프레임 워크: 개발 과정을 수월하게 하기 위해 공통적 기능을 라이브러리 형태로 제공하는 것

+) 스프링 프레임 워크: Java를 기반으로 한 웹 어플리케이션 프레임 워크

 

핵심특징

- 단독 실행 가능

- 자동 설정: 자바 설정 코드 등을 직접 작성하지 않아도 필요한 설정을 자동으로 구성

- 스타터 의존성: 스타터 라이브러리를 통해 특정 목적에 필요한 라이브러리 묶음 간편 관리

- 운영 준비 완료: 운영 환경에서 필요한 기능 기본 제공

 

---

MVC 아키텍처 패턴

: 애플리케이션의 역할을 세가지로 나누어 관리하는 디자인 패턴 ( 코드의 재사용성을 높이고 유지보수를 용이하게 함)

+) 디자인 패턴: 효율적으로 코드를 작성하기 위한 코딩 규칙 or 프로젝트 구조 및 규약

• model: 데이터와 비즈니스 로직 담당. 데이터베이스와 상호작용하며 데이터를 정의, 처리
• view:사용자에게 보여지는 화면(UI) 담당. 모델로부터 받은 데이터를 출력
• controller: 사용자의 요청을 받아 처리 흐름을 제어. 모델에 데이터를 요청하고 그 결과를 뷰에 전달

---

스프링부트의 폴더 구조

 

 

• controller

- 클라이언트로부터 요청을 받고, 해당 요청에 대한 처리 수행

- HTTP 요청 처리(GET, POST, PUT, DELETE 등의 메서드를 가짐)

@RestController  // 이 클래스가 HTTP 요청을 처리하는 컨트롤러임을 선언
public class HelloController{

	@GetMapping("/hello")  // 클라이언트가 브러우저 주소창에 "/hello" 경로로 HTTP GET요청을 보내면 아래의 메서드와 연결
	public String hello(){   // 요청이 들어왔을 때 실행될 메서드
		return "Hello, world!";  // 클라이언트에게 다음의 문장을 보냄
		}
}

 

+) @RestController: @Controller와 @ResponseBody를 합친것. 데이터를 응답 본문에 직접 담아 반환

 

 

• domain

- 데이터베이스 테이블과 매핑되는 클래스들

- 어플리케이션의 도메인 모델

- 엔티티 클래스와 DTO 클래스를 포함

+) DTO: 데이터 전달을 담당하는 객체

public class User{		// User 정보를 담기 위한 클래스 선언
	private Long id;	// 각 사용자를 고유하게 식별하기 위한 ID
	private String username;		// 사용자의 이름이나 아이디를 저장하기 위한 문자열 필드
	private String email;		// 사용자의 이메일 주소를 저장하기 위한 문자열 필드
}

 

 

• repository

- 데이터베이스와 상호작용 담당. 데이터베이스에서 데이터를 읽고 쓰는 작업을 수행

- CRUD 작업 수행

save(), findByld(), findAll()과 같은 메서드를 자동으로 제공 -> Spring Data JPA

@Repository		// 이 인터페이스가 데이터 접근 계층임을 스프링에 알림
public interface UserRepository extends JpaRepository<User, Long>{	//JpaRepository를 상속받음
	User findbyUsername(String username); 	// 쿼리 메소드 기능
}

 

+) <User, Long> : 이 리포지토리가 다룰 엔티티 클래스(User)와 그 엔티티의 PK타입(Long)

JpaRepository를 상속받으면 save(), delete() 같은 기본 CRUD기능 바로 사용 가능

+) 메서드 이름을 규칙에 맞게 지으면 스프링이 이를 분석해 자동으로 SQL 쿼리를 생성

-> 내부적으로 "SELECT * FROM user WHERE username = ?" 같은 쿼리가 실행

 

 

• service

- 비즈니스 로직 수행 (트랜잭션 관리, 예외 처리 등) 

- 여러 저장소를 조합하거나 데이터 가공을 담당

@Service // 이 클래스가 비즈니스 로직을 수행하는 서비스 계층임을 스프링에 알림
public class UserService{
	@Autowired		// 스프링이 관리하는 UserRepository 객체를 자동으로 이 자리에 주입
	private UserRepository userRepository;  
	public User getUserByUsername(String username){   // 사용자의 이름을 통해 유저 정보를 가져오는 비즈니스 메서드
		return userRepository.findByUsername(username);  // 주입받은 리포지토리의 메서드를 호출해 실제 DB조회를 수행 후 결과 반환
	}
}

 

+) @Autowired : 개발자는 직접 new UserRepository() 등을 할 필요 없이 바로 사용 가능

 

 

+) @~~: 어노테이션(Annotation). 코드에 추가하는 메타데이터(데이터에 대한 데이터).

컴파일러나 프레임워크(스프링)에게 "이 클래스나 메서드는 이런 역할을 하니까 이렇게 처리해줘!"라고 내리는 특수 지시어

 

---

사용자가 로그인을 시도하는 경우(요청 처리흐름)

 

1단계: 클라이언트의 요청 (Client Request)

• 상황: 사용자가 브라우저(UI)에서 아이디와 비밀번호를 입력하고 로그인
• 동작: 입력된 데이터가 HTTP 요청 메시지에 담겨 서버로 전송됨 (보통 보안을 위해 POST 방식을 사용)

2단계: DispatcherServlet의 요청 처리

• 상황: 서버에 요청이 도착하면 가장 먼저 DispatcherServlet이 이를 받음
• 동작: 공통적인 전처리 작업을 수행한 후, 이 요청을 처리할 수 있는 적절한 Controller를 호출

3단계: Controller가 요청 처리

• 상황: @RestController 또는 @Controller가 요청을 넘겨받음
• 동작: HTTP 요청 본문에 담긴 로그인 정보(ID, PW)를 DTO(Data Transfer Object) 객체로 변환하여 읽어들임

4단계: Service에 데이터 전달 및 비즈니스 로직 요청

• 상황: 컨트롤러는 직접 DB에 접근하지 않고, 해당 기능을 담당하는 Service 계층에 데이터를 넘김
• 동작: userService.login(dto)와 같은 메서드를 호출하여 "이 정보로 로그인이 가능한지 확인해줘"라고 요청

5단계: JPA Repository를 통한 데이터베이스 조회

• 상황: 서비스는 실제 사용자의 정보가 DB에 있는지 확인하기 위해 Repository를 호출합니다.
• 동작: Repository는 Spring Data JPA를 사용하여 SELECT * FROM user WHERE username = ?과 같은 쿼리를 실행하고, 결과를 Entity 객체로 반환

6단계: Service의 로직 처리 (검증)

• 상황: DB에서 가져온 Entity와 사용자가 입력한 DTO 정보를 비교
• 동작: 비밀번호가 일치하는지, 계정이 정지되지는 않았는지 등의 비즈니스 로직을 수행한 후, 로그인 성공 여부(성공/실패)를 결정하여 컨트롤러에 반환

7단계: Controller 응답 생성 및 반환 (Response)

• 상황: 서비스로부터 결과를 받은 컨트롤러가 최종 응답 생성
• 동작: 성공 시에는 메인 화면으로 이동하거나 토큰(JWT 등)을 발급하고, 실패 시에는 에러 메시지를 담아 클라이언트(브라우저)에게 전송