🎁[속보] 인프런 내 깜짝 선물 출현 중🎁

연휴 동안 쏟아지는 선물과 100% 당첨 쿠폰을 확인하세요 →

[인프런 워밍업 클럽 3기 / 백엔드 프로젝트] 1주차 정리

[인프런 워밍업 클럽 3기 / 백엔드 프로젝트] 1주차 정리

와땅깡 1개월 전

해당 글은 [입문자를 위한 Spring Boot with Kotlin - 나만의 포트폴리오 사이트 만들기: 정보근](https://www.inflearn.com/course/%EC%9E%85%EB%AC%B8%EC%9E%90-spring-boot-kotlin-%ED%8F%AC%ED%8A%B8%ED%8F%B4%EB%A6%AC%EC%98%A4/dashboard) 강의를 보고 공부한 내용입니다.

웹 이론 정리

웹서비스 구성 요소

클라이언트 -- 서버 -- 데이터 베이스

- 클라이언트 : 사용자와 상호작용하여 요청하는 주체로 일반적으로 브라우저 의미

- 서버 : 요청한 작업을 응답하는 주체. 데이터베이스 데이터의 CRUD 작업 후 결과를 클라이언트에 반환

- 데이터베이스 : 데이터의 집합

- DBMS: 데이터를 저장하고 관리하는 프로그램으로 일반적으로 데이터베이스라고 하면 DBMS를 의미

- DSN 서버: 클라이언트에서 요청을 보낸 도메인 주소를 IP주소로 매핑하여 반환해주는 서버

주소를 브라우저에 입력하면?

1. DNS에 도메인을 보낸 후 해당하는 IP주소를 받아온다.

2. 해당 IP주소로 서버에 요청을 보낸다. 이 때 필요한 데이터가 있다면 함께 전달

3. 요청을 받은 서버는 데이터베이스에 요청을 수행한다.

4. 데이터베이스는 서버에서 요청한 작업을 완료 후 결과를 반환한다. (조회의 경우 조회 데이터 전달, 삽입 수정 삭제의 경우 성공 여부 응답)

5. 서버는 받은 결과를 클라이언트에 전달

웹 프레임워크

- 웹프레임워크 : 동적 웹 서비스 개발을 편리하게 만들어주는 도구

- Spring 프레임워크 : 자바 기반 웹 프레임워크로 웹서버 개발을 편리하게 할 수 있도록 모듈화 해놓음

아키텍쳐 패턴

MVC 패턴

- 애플리케이션을 Model, View, Controller로 구분

- Model : 애플리케이션의 비즈니스 로직과 데이터

- View : 사용자에게 보여지는 화면을 담당, Model에서 데이터를 꺼내와 반영

- Controller : 요청을 받아 처리하고 결과 데이터를 Model에 넣을 수 있음

레이어드 아키텍처

- 애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어(계층)로 묶어 수평적으로 구성한 구조

- 스프링 웹개발 시 대부분 레이어드 아키텍쳐 기반으로 개발

- 프레젠테이션 (Controller) : 클라이언트의 요청을 해석하고 응답, 전달 받은 데이터를 검증하거나 가공 등의 과정을 담당하며 직접적인 비지니스 로직은 포함하지 않고 상호작용만을 담당

- 비지니스 (Service) : 애플리케이션에서 제공하는 기능을 정의하고 목적에 맞게 데이터를 처리, Repository의 다양한 처리 메소드를 호출하여 저장, 수정, 조회, 삭제 등을 수행

- 데이터 접근 (Repository) : 데이터 베이스에 직접 상호작용하여 작업을 요청

 

스프링 Bean과 의존성 주입

스프링 빈 이란?

- 빈(Bean)은 스프링 컨테이너에 의해 관리되는 재사용 가능한 소프트웨어 컴포넌트

- 스프링에서 관리되는 객체 = 자바 클래스의 인스턴스

- 빈을 사용하는 가장 큰 이유는 스프링 간 객체가 의존관계를 관리하도록 하는 것

객체가 의존관계를 등록할 때 스프링 컨테이너에서 해당하는 빈을 찾고, 그 빈과 의존성을 만든다.

의존성 주입이란?

- 한 객체 내에서 사용하는 다른 객체를 클래스 내부에서 직접 만드는 것이 아니라 외부에서 주입받아 사용하는 방식

ex) 컨트롤러에서 서비스를 사용하면 직접 컨트롤러내에서 서비스를 생성하는 것이 아니라 외부에서 서비스를 주입하는 것

#### 의존성 주입 방법

생성자 방식

- 클래스 생성자에서 주입을 하는 방식

- 다른 주입 방법에 비해 안전하므로 생성자 주입 방식 권장

- 순환 참조 예방 -> 컴파일 에러가 발생하므로 런타임단계에서 발생하는 스택오버플로우 방지

- 의존하는 빈 누락 방지 -> 이 또한 컴파일 에러 발생

필드 주입 방식같은 경우 어노테이션을 누락했지만 넘어가 런타임 에러가 발생할 수도 있음

수정자(setter) 방식

- 클래스의 세터 메서드를 통해 의존성을 주입

- 객체가 생성된 후 언제든지 호출될 수 있기때문에 lateinit 키워드를 사용하여 나중에 초기화할 수 있도록하며, @Autowired를 파악해 setter를 감지하고 주입할 수 있도록 함

필드(Field) 방식

- 클래스의 필드에 바로 의존성을 주입

- 필드에 @Autowired 어노테이션을 사용하면 Spring은 해당 필드에 맞는 Bean을 자동으로 주입함

- 가장 간단하지만 안정성을 보장하지 못하고 테스트가 어려움

 

HTTP와 REST API

HTTP

- 네트워크로 통신하는 두 컴포넌트간의 통신 규약

- 요청과 응답을 통해 작동함, 즉 어떻게 요청하고 응답할지에 대한 약속

- 각 요청과 응답은 StartLine, Header, Body로 구성되어있음

HTTP 요청 메서드

  • GET (Read), POST(Create), PUT, PATCH(Update), DELETE(Delete)

  • PUT : 리소스의 모든 것을 업데이트 /

    PATCH : 리소스의 일부를 업데이트

     

HTTP 상태 코드

1. 2xx : 정상 처리 의미

2. 3xx : 추가 행동 요구

3. 4xx: 클라이언트측 에러

4. 5xx : 서버측 에러

 

REST API

- HTTP 통신으로 동작하는 애플리케이션 기능을 정의하는 규칙, 즉 API를 구축하기 위한 방법에 대한 약속

핵심

1. URL만으로도 어떤 자원에 대한 요청인지 이해할 수 있어야함

2. HTTP메서드를 통해 어떤 행위를 할 것인지 파악 가능해야함

3. HTTP 응답에 링크를 포함하여 클라이언트가 다음에 할 행동 가이드를 제시

클라이언트에서 서버에 데이터를 보내는 방식

1. Query Parameter : URL에 ? 로 연결된 데이터들, @RequestParam 어노테이션 사용

2. Path Variable: URL에 / 를 통해 추가적으로 전달되는 데이터들, @PathVariable 어노테이션 사용

3. Request Body: URL을 통해 전달하지 못함, @RequestBody 어노테이션 사용

 

데이터 베이스

데이터 베이스 = 데이터의 집합, 일반적으로 데이터관리시스템인 DBMS 를 지칭

데이터베이스 종류

  1. 관계형 데이터 베이스 : 테이블로 이루어짐 (열과 행), 각 행은 1개의 데이터 각 열은 데이터의 필드

    1. 후보키 : 데이터를 식별할 수 있는 컬럼의 최소 조합

    2. 기본키 : 후보키 중 대표로 정한 것


      즉 각 데이터들을 구별하는 요소들이기에 겹칠 수 없음 -> 유일성을 가짐

  2. 비관계형 데이터베이스, NoSQL

    1. 키-값 형태, 문서형 등 존재

    2. 대표적으로 MongoDB, Redis

    3. 기본적으로 관계형에 데이터를 저장하고 속도가 빠른 비관계형의 이점을 살려 캐시용도로 비관계형 디비 사용

       

 

데이터 베이스 설계

데이터 베이스 관계 종류

1:1 관계 (One-to-One)

한 개의 레코드가 다른 테이블의 오직 하나의 레코드와 연결되는 관계.

예시: User (사용자) 테이블과 UserProfile (사용자 프로필) 테이블

  • 한 사용자는 한 개의 프로필만 가질 수 있음.

  • UserProfile에서 user_id (FK, Unique)를 사용하여 관계 유지.

1:N 관계 (One-to-Many)

한 개의 레코드가 다른 테이블의 여러 레코드와 연결되는 관계.

부모(1) 테이블과 자식(N) 테이블이 존재하며 자식 테이블은 부모 테이블을 참조하는 외래 키(FK) 를 가짐.

예시: User (사용자) ↔ TimeCapsule (타임캡슐)

  • 한 사용자가 여러 개의 타임캡슐을 생성할 수 있음.

  • TimeCapsule 테이블이 user_id (FK) 를 포함함.

N:M 관계 (Many-to-Many)

여러 개의 레코드가 다른 테이블의 여러 개의 레코드와 연결되는 관계.

중간 테이블(Bridge Table, Join Table)이 필요함. -> 다대다 관계를 직접 설정할 수 없으므로 1:N + 1:N의 형태로 변환됨.

예시: User (사용자) ↔ User_Capsule (사용자-타임캡슐 관계) ↔ TimeCapsule (타임캡슐)

  • 한 사용자는 여러 개의 타임캡슐에 참여 가능.

  • 하나의 타임캡슐도 여러 사용자가 참여 가능.
    => 따라서 사용자와 타임캡슐간의 중간테이블 사용자-타임캡슐 관계를 생성

  • User_Capsule이 user_id (FK) & capsule_id (FK) 를 가짐.

 

식별관계 vs 비식별관계

테이블 간 관계를 설정할 때, 부모 테이블의 PK를 자식 테이블이 직접 사용하느냐에 따라 나뉨.

 

식별관계 (Identifying Relationship)

자식 테이블이 부모 테이블의 PK를 포함하여 복합키(PK)로 사용하는 관계.

  • 부모 테이블이 삭제되면 자식 테이블도 삭제됨 (ON DELETE CASCADE 가능).

  • 자식 테이블이 부모 테이블의 존재 없이는 의미가 없음.

  • 보통 N:M 관계를 관리하는 중간 테이블에서 많이 사용됨.

예시: User_Capsule이 user_id & capsule_id를 PK로 포함하는 경우 (복합키 사용).

 

비식별관계 (Non-Identifying Relationship)

부모 테이블의 PK를 자식 테이블이 PK로 포함하지 않고, FK로만 유지하는 관계.

  • 부모 테이블이 없어도 자식 테이블이 독립적으로 존재 가능.

  • 데이터 확장성이 높아지고 관리가 용이함.

  • 자식 테이블이 자체적인 ID(PK) 를 가지므로, 유지보수성이 높아짐.

예시: User_Capsule 테이블이 별도의 id (PK) 를 가지면서 user_id (FK), capsule_id (FK) 를 유지하는 경우,

InviteCode 테이블이 capsule_id (FK) 를 가지지만 id (PK) 를 별도로 유지하는 경우.

 

트러블 슈팅1 - 식별 관계 VS 비식별 관계

문제 상황

초기 ERD 설계에서 User_Capsule(사용자-타임캡슐 관계) 테이블을 만들 때,

• user_id와 capsule_id를 복합 PK(식별관계) 로 설정할지,

• 별도의 id를 PK로 두고 user_id & capsule_id를 FK(비식별관계) 로 설정할지 고민이 발생.

 

✔ 만약 식별관계를 선택하면?

• User_Capsule의 PK가 (user_id, capsule_id)가 되며, User 또는 TimeCapsule이 삭제되면 해당 관계도 삭제됨.

• 하지만, 추가적인 필드를 넣거나 관계를 수정하기 어려움 (예: role 같은 필드 추가 시 관리 복잡).

 

✔ 만약 비식별관계를 선택하면?

• User_Capsule이 별도의 id 필드를 PK로 가지며, user_id & capsule_id는 FK로만 존재.

• 데이터 확장이 용이하고, 관계의 독립성이 보장됨 (예: 나중에 role 변경 가능).

 

해결 방법 (비식별관계 선택)

• 결론적으로 User_Capsule에 별도의 id 필드를 PK로 설정하고, user_id & capsule_id를 FK로 두는 방식(비식별관계)을 채택!

• InviteCode(초대 코드)도 TimeCapsule과 비식별관계로 설정하여 독립적인 관리 가능.

 

비식별관계를 선택한 이유:

1. 확장성 용이 → 추가적인 필드(예: 역할 정보) 추가 가능.

2. 데이터 무결성 유지 → 관계 삭제 시에도 유연한 처리가 가능.

3. 관리 편리성 증가 → 식별자로 인해 불필요한 제약을 없애고, 독립적인 테이블 관리 가능.

 

1주차 회고

이번 주에는 백엔드 프로젝트의 기본 개념부터 시작해서 실제로 환경을 세팅하고 엔티티를 개발하는 과정까지 진행했다.

✅ 스스로 칭찬하고 싶은 점

  1. 백엔드 실습이 처음인데도 적극적으로 따라갔다.


    iOS 개발을 주로 해왔기 때문에 백엔드 실습이 낯설었지만, 처음부터 하나하나 차근차근 따라가면서 익히려고 노력했다.

  2. 기본 이론의 경우 전공 공부에서 배운 내용들이 많아 비교적 수월하게 이해할 수 있었다.

     

❌ 아쉬웠던 점

  1. 실습에서 예상보다 시간이 걸렸다.
    특히 환경 세팅 과정에서 iOS에서는 Xcode 중심이기에 처음부터 세팅을 했어야했는데 예상치 못하게 시간을 많이 잡아먹었었다.

  2. 데이터베이스 설계 실습을 하면서 생각보다 모르는 개념들이 많다는 것을 깨달았다.

     

🎯 다음 주 학습 목표

  1. 강의를 들으면서 내 프로젝트에 응용하기 위해 궁금한 내용들을 찾아 공부하고 기록하기

  2. JPA와 데이터베이스 개념을 더 깊이 공부하기

댓글을 작성해보세요.


채널톡 아이콘