실제 세계의 객체를 생각하면 된다 → 어떠한 상태(속성)를 갖고 특정 행위를 할 수 있는 독립적인 단위.

Class

객체의 설계도, 속성과 동작을 정의한다.

사용자 정의 자료형(user defined data type)

Object

상태(데이터)와 행동(메소드)를 함께 가지는 독립적인 단위

Class → Instantiate → Object

실제 메모리에 할당된 인스턴스

객체 지향 프로그래밍 (Object Oriented Programming)

객체 중심의 프로그래밍 패러다임.

프로그램을 여러개의 객체로 구성된 시스템으로 바라보는 방식

필요성

절차 지향 프로그래밍(Procedure Oriented Programming)

• 함수가 프로그램의 기본 단위이다.
  • 프로그램이 수행해야 할 일들을 순서대로 나열하고, 각 작업을 독립적인 함수로 분리하여 작성한다.
• 데이터와 함수가 분리되어있다.

장점

• 실행 흐름이 직관적이고 이해하기 쉽다.
• 실행 속도가 빠르다. 하드웨어 제어에 유리하다.
• 작은 규모의 프로그램 개발 / 프로토타입 개발에 유리하다.

단점

• 중복 코드가 발생하기 쉽고, 코드의 재사용성이 낮다
• 데이터 보호가 어렵다. (책임 및 권한의 분리가 어렵다.)
• 잦은 전역변수 사용으로 오류가 발생하기 쉽다.
• 유지보수가 어렵다.

객체 지향 프로그래밍

장점

• 코드의 재사용이 쉽다.
• 상속, 다형성 → 기능 확장이 쉽다.
• 프로그램을 모듈화할 수 있어 유지보수가 편리하다.
• 대규모 SW 개발에 적합하다.
• 실제 세계의 사물이나 개념을 프로그램에 표현할 수 있다.

단점

• 설계 단계가 복잡하다(요구사항 분석, 모델링).
• 추상화, 메모리 → 실행속도 느림.
• 학습곡선

특징

1. 캡슐화(Encapsulation)

데이터를 외부에서 직접 접근하지 못하게 하고, 메소드를 통해서만 접근할 수 있게 제한하는 개념.

데이터 + 메서드를 객체로 캡슐화하고, 외부에서는 객체 내부를 알 수 없도록 숨긴다.

파이썬의 캡슐화

완전히 기술적으로 막지는 않고, 관례로 구현된다. → 파이썬의 철학: “we are consenting adults here”

Protected: _ 클래스 및 하위 클래스에서 접근 가능.

class Person():
    def __init__(self, name):
        self._name = name

Private: __ (name mangling) 정의한 클래스 내에서만 접근 가능.

class Person():
    def __init__(self, name):
        self.__name = 0

@property

class User:
    def __init__(self, age):
        self._age = age

    @property
    def age(self):
        print("getter 호출")
        return self._age

    @age.setter
    def age(self, value):
        print("setter 호출")
        if value < 0:
            raise ValueError("나이는 음수 불가")
        self._age = value

u = User(20)

u.age        # getter 호출
u.age = 30   # setter 호출

u.age  ──>  getter(age) ──>  _age
u.age= ──>  setter(age) ──>  _age

접근 경로가 통제된다.

2. 추상화(Abstraction)

객체가 제공하는 행동(기능)만 드러내고, 내부 구현을 숨기는 설계 방식.

외부에서 객체의 내부 구현은 몰라도 된다. 객체 외부에서 메소드를 사용하는 사람은 구현 내용을 몰라도 사용할 수 있다.

3. 상속(Inheritance)

기존에 작성된 클래스의 속성과 메소드를 물려받아 사용할 수 있다.

기존 코드를 재사용할 수 있다. 상속을 통해 다형성을 구현할 수 있다.

class Vehicle:
    def __init__(self, name):
        self.name=name

    def move(self):
        print(f"{self.name} 이동중")

class Car(Vehicle):
    def __init__(self, name, wheels):
        super().__init__(name)
        self.wheels=wheels

    def info(self):
        print(f"{self.name} 바퀴는 {self.wheels}개")

def practice_inheritance():
    banner("3) OOP: Inheritance")

    car = Car("Taxi", 4)
    car.move()   # 예상: Taxi 이동 중
    car.info()   # 예상: Taxi 바퀴는 4개

4. 다형성(polymorphism)

하나의 메소드/클래스가 다양하게 동작할 수 있다.

오버라이딩(상속받은 메소드 재정의), 오버로딩(매개변수에 따라 여러개 정의)

# w/o polymorphism

class Dog:
        def __init__(self, name):
                self.name = name

        def bark(self):
                return f"{self.name} says Woof!"

class Cat:
        def __init__(self, name):
                self.name = name

        def meow(self):
                return f"{self.name} says Meow!"

def make_animal_speak(animal):
        if isinstance(animal, Dog):
                print(animal.bark())
        elif isinstance(animal, Cat):
                print(animal.meow())
        else:
                raise ValueError("Unknown animal")

# with polymorphism

class Animal:
        def __init__(self, name):
                self.name = name

        def speak(self):
                raise NotImplementedError

class Dog(Animal):
        def speak(self):
                return f"{self.name} says Woof!"

class Cat(Animal):
        def speak(self):
                return f"{self.name} says Meow!"

def make_animal_speak(animal):
        print(animal.speak())

dog = Dog("Buddy")
cat = Cat("Whiskers")
make_animal_speak(dog)
make_animal_speak(cat)

같은 기능을 하는 메서드 이름을 같게 → 복잡성 줄이고, 코드 재사용, 기능 확장 용이

참고자료

1.3. 절차지향 언어 vs 객체지향 언어

Amazon Cognito 도입기 Lambda Trigger와 API Gateway Proxy로 AWS 아키텍처 완성하기

목차

1. Amazon Cognito 소개
2. ALB + Cognito 연동 - 실패기
3. Lambda 트리거를 활용하여 인증 흐름 커스터마이징하기
4. 외부 API 호출 문제 NAT Gateway 없이 해결하기
5. Cognito 도입 시 고려할 점

1. Amazon Cognito 소개

Amazon Cognito는 AWS에서 제공하는 인증 플랫폼이다. 웹이나 모바일 앱에서 로그인, 회원가입, 권한 제어 같은 기능을 쉽게 구현할 수 있도록 해준다. Cognito는 크게 user pool, identity pool로 구성된다.

• User pool을 통해 앱 또는 API에 사용자를 인증하고 권한을 부여한다.
• Identity pool을 통해 사용자가 aws 리소스에 액세스 할 수 있도록 권한을 부여한다.

쉽게 말해, user pool은 사용자 인증, identity pool은 aws 리소스 권한 관리를 담당한다. 우리 프로젝트에서는 앱에 대한 사용자의 인증에 활용하고자, User Pool을 활용했다.

User pool 인증 흐름

user pool 인증 흐름은 위와 같다.

• 앱에서 로그인을 시도하면 Cognito 관리형 로그인 페이지로 연결되고, 사용자가 인증을 마치면 토큰을 앱에 전달한다.
• 이 토큰은 백엔드 서버로 전달되어 API 호출에 사용된다.

2. ALB + Cognito 연동 - 실패기

2-1. Application Load Balancer + Cognito 연동 구조 선택

ALB와 Cognito를 연동한 구조에서는 사용자가 ALB에 요청을 보내면, ALB가 인증되지 않은 사용자는 Cognito로 리디렉션하고, 인증 후에는 트래픽이 컨테이너로 전달된다. ALB가 인증을 직접 처리해주기 때문에 백엔드에서 따로 인증 로직을 구현할 필요가 없고, 따라서 인증 과정에서 외부 api 호출이 필요 없다는 점에서 이 아키텍처를 선택했다.

2-2. ALB + Cognito 연동 시도

기술적 구현 가능성 확인

ALB + Cognito 연동 구조를 구축하고, 테스트 컨테이너를 통해 인증, REST API 호출, WebSocket 통신 모두 성공적으로 수행되는 것을 확인했다.

실제 프론트 배포 단계에서 리디렉션 URL 제약

• ALB + Cognito 연동 시, Callback URL을 https://<ALB DNS>/oauth2/idpresponse 로 설정해야 한다.
• 하지만 실제 서비스는 인증 완료 후 프론트엔드 도메인으로 리디렉션되어야 한다.

⟹ 프론트가 Cognito와 직접 통신하고, 받은 토큰을 백엔드에 전달하는 구조로 변경했다.
이 과정을 통해 아키텍처 설계 시에 실제 개발 흐름도 고려해야 된다는 교훈을 얻었다. (프론트 코드가 백엔드 프로젝트 내에 위치할 것이라고 생각했지만, 실제로는 따로 배포해서 문제 발생했으니..)

3. Lambda 트리거를 활용하여 인증 흐름 커스터마이징하기

이후, Cognito를 이용한 인증 흐름을 구현하면서 Cognito 기본 기능만으로는 개발 요구사항들을 만족시키기 어려웠다. 따라서, Cognito에 Lambda Trigger를 연결하여 인증 흐름을 커스터마이징했다.

위는 최종 아키텍처 다이어그램이다. Cognito와 Lambda가 연동된 구조를 확인할 수 있다. 크게 보면 다음과 같은 구조이다.

Cognito에 두가지 Lambda trigger가 연결되어 있다. 간단히 설명하자면 다음과 같다.

• 사용자가 회원가입을 완료하면 Post Confirmation 트리거가 작동하고, 이때 updateUser 람다함수가 호출된다.
• 액세스 토큰이 발급되기 전에 Pre Token Generation 트리거가 작동해, JWT의 email 같은 클레임을 수정하는 customToken 람다함수가 실행된다.

이제 각 람다 함수와 트리거가 왜 필요한지, 어떻게 구현했는지 자세히 설명하겠다.

1. updateUser()

아키텍처 내 위치는 좌측과 같고, 람다 코드는 우측에 있다. 이 람다 함수와 트리거는 회원가입 직후, Cognito 사용자 정보를 내부 DB로 업데이트한다.

Cognito의 경우, 사용자 정보를 자체 사용자 디렉토리에 저장하지만, 우리 백엔드에도 사용자 데이터가 필요해서 이를 가져와야 했다. 따라서 람다함수를 생성하고 Cognito에 트리거를 연결하여, Dynamodb에 가입이 완료된 사용자의 정보를 저장했다.

회원가입이 발생하면 Post confirmation trigger가 발동되고, updateUser() 람다함수가 호출된다. 이 람다함수는 회원 정보를 DynamoDB에 저장한다.

2. customToken()

아키텍처 내 위치는 좌측과 같고, 람다 코드는 우측에 있다. 이 람다함수는 access token 생성시에 헤더에 email 필드를 추가한다.

실제 배포 테스트를 진행하면서, 백엔드에서는 access token에 email 헤더가 필요하지만, cognito에서는 access token에 email 필드를 제공하지 않는 이슈가 발생했다. Identity token을 발급해서 백엔드 로직을 수정할 수도 있었지만, 이미 배포가 완료된 상태였기에 백엔드를 수정하는것보다 람다 함수로 토큰을 수정하는것이 효율적이라고 판단해서 아래 흐름을 도입했다.

토큰이 생성되기 전에 Pre token generation trigger가 발동되면, 연결된 customToken() 람다가 호출되어, 토큰의 헤더에 email 클레임을 추가한다. 이를 통해 별도의 백엔드 로직 수정 없이 문제를 해결했다.

* 이외에도 다양한 람다 트리거들이 있어, 아래 공식문서를 참고하여 각자의 요구사항에 맞는 트리거를 적용하면 된다. docs.aws.amazon.com

4. 외부 API 호출 문제: NAT Gateway 없이 해결하기

4-1. Private subnet 내부에서 외부 API 호출 발생

application-cognito.yml

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://cognito-idp.ap-northeast-2.amazonaws.com/ap-northeast-2_*********

위 코드는 스프링 애플리케이션의 Cognito 설정 파일의 일부이다. Spring Security는 Cognito가 서명한 JWT를 검증할 때, 서명에 사용된 공개 키 목록(JWKS)을 Cognito의 Public Endpoint를 통해 동적으로 가져온다.

문제는 우리 애플리케이션이 보안 강화를 위해 외부 인터넷 접속이 차단된 Private Subnet 내의 ECS 컨테이너에 배포되었다는 점이었다. 초기 아키텍처 설계 시, 외부 API 호출이 필요 없다고 판단하여 비용 효율을 위해 NAT Gateway를 도입하지 않았다.

그러나 이 설계로 인해 정작 인증에 필수적인 JWKS 요청이 외부로 나가지 못하고 차단되는 문제가 발생했다. 결국 임시 조치로 NAT Gateway를 추가하여 문제를 해결했지만, 이로 인해 인프라 비용 크게 증가했다.

4-2. API Gateway + Lambda 프록시로 NAT Gateway 대체하기

이 케이스에서 외부 api 호출은 특정 시점에만, 특정 api로 발생했다. 따라서 api gateway와 lambda로 프록시를 구성하여 NAT Gateway를 대체해보고자 시도했다.

그 방법은 다음과 같다.

1. Lambda 생성

jwks를 반환하는 api를 호출하는 lambda 함수를 생성한다. jwkProxy()

import json
import urllib.request
COGNITO_JWKS_URL = "https://cognito-idp.ap-northeast-2.amazonaws.com/ap-northeast-2_*********/.well-known/jwks.json"
def handler(event, context):
    try:
        with urllib.request.urlopen(COGNITO_JWKS_URL) as resp:
            jwks_dict = json.loads(resp.read().decode("utf-8"))
        return jwks_dict
    except Exception as exc:
        return { "error": str(exc) }

2. VPC Endpoint 생성

private api gateway와 컨테이너가 배포되는 private subnet을 연결하는 vpc endpoint를 생성한다.

• 서비스: execute-api
• DNS 이름 활성화 활성화

  3. REST API Private Gateway 생성 및 Lambda 연결

1. REST API Private Gateway 생성 2번에서 만든 VPC Endpoint와 연결
2. 리소스 생성
3. 메서드 생성 + Lambda 연결 메서드 생성 시, Lambda 프록시 통합 옵션을 비활성화한다.
4. 리소스 정책 생성 리소스 정책은 다음과 같이 설정한다.

   {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "AllowAllFromThisVpce",
        "Effect": "Allow",
        "Principal": "*",
        "Action": "execute-api:Invoke",
        "Resource": "arn:aws:execute-api:{region}:{account-id}:{api-id}/*/*/*",
        "Condition": {
          "StringEquals": {
            "aws:SourceVpce": "{vpc-endpoint-id}"
          }
        }
      }
    ]
   }

   4. Spring Configuration 수정

   application-cognito.yml

   spring:
     security:
       oauth2:
         resourceserver:
           jwt:
             issuer-uri: https://{api-id}.execute-api.{region}.amazonaws.com/{stage}/jwks

• {api-id}: api gateway id

실행 확인

NAT Gateway를 제거했다. (*pingpong은 다른 팀 리소스이다.) 로그인 후 인증에 성공했다!

NAT Gateway를 제거해도 인증 흐름이 정상 작동했다. 이렇게 API Gateway와 Lambda를 통한 api 요청 프록시에 성공해서, nat gateway로 인한 비용을 줄일 수 있었다.

5. Cognito 도입 시 고려할 점

마지막으로, Cognito를 도입하며 느낀 장단점을 정리해봤다.

정리하자면, MVP 개발에는 빠르고 강력한 인증 플랫폼으로 Cognito를 추천하지만 장기적인 유연성과 관리 비용까지 고려해 선택하시는 것을 권장한다. (개인적인 생각)

Amazon Cloud Club Ewha 3기 사이드 프로젝트

기능 구현보다, 왜 이 구조를 선택했는지를 더 많이 배운 프로젝트

Amazon Cloud Club Ewha 3기 사이드 프로젝트에서 실시간 채팅 시스템 인프라를 설계하고 운영하며, 아키텍처는 “정답을 한 번에 맞히는 일”이 아니라 요구사항과 제약에 따라 선택을 계속 수정해 가는 과정이라는 점을 배웠다.

이번 프로젝트에서 가장 크게 느낀 것은, 기술은 많이 아는 것보다 어떤 기준으로 선택하고 어떤 이유로 포기하는지가 더 중요하다는 점이었다.
처음에는 “AWS 서비스를 최대한 많이 써보자”는 생각으로 접근했지만, 실제 구현과 배포를 겪으면서 점차 기준이 분명해졌다.

내가 이 프로젝트에서 아키텍처를 판단할 때 계속 확인한 기준은 아래 세 가지였다.

• 팀이 실제로 구현 가능한가
• 운영 복잡도를 감당할 수 있는가
• 비용 대비 얻는 이점이 충분한가

이 글은 그 기준이 어떻게 생겼고, 실제로 어떤 선택으로 이어졌는지 순서대로 정리한 회고다.

아키텍처 발전 과정을 순서대로 회고한다.

1. 처음에는 “가능해 보이는 구조”를 그렸고, 이후에는 “실제로 운영 가능한 구조”로 바꿨다

프로젝트 초기에 가장 먼저 떠올린 구조는 Lambda 기반 서버리스 아키텍처였다.

• API Gateway + Lambda + DynamoDB
• 실시간 채팅은 WebSocket API
• 일반 요청은 REST API

짧은 기간 안에 MVP를 빠르게 만들기에는 합리적인 선택처럼 보였다.
특히 인프라 운영 경험이 많지 않은 팀에게는 서버를 직접 관리하지 않아도 된다는 점이 매력적이었다.

하지만 팀 회의를 거치며 이 선택을 바꾸게 됐다.
백엔드 팀원들은 웹소켓 서버를 직접 구현해보고 싶어 했고, 이번 프로젝트는 단순히 결과물을 만드는 것뿐 아니라 구조를 직접 다뤄보는 경험도 중요했다.
즉, 여기서는 “관리 부담이 적은 구조”보다 팀의 학습 목표와 구현 방식에 맞는 구조가 더 중요했다.

이 지점에서 서버리스는 제외했고, ECS 기반 아키텍처로 방향을 바꿨다.

이 과정에서 배운 점은 명확했다.
좋은 기술이냐보다, 지금 팀의 목표와 제약에 맞느냐가 먼저다.

초기에는 AWS로 인프라를 구축해본 경험이 없어, 리소스 배치나 VPC 구조를 고려하지 않았다.

1안 (MVP)

• 짧은 기간의 프로젝트이기에 개발 부담을 줄이기 위해 서버리스 Lambda로 설계했다.
• API Gateway + Lambda + Dynamodb 구조
• API Gateway는 websocket 통신을 지원한다.
• WebSocket & REST 분리 구조 실시간 채팅은 WebSocket API, 나머지는 REST API로 나누어 각각 다른 API Gateway로 연결된다.

2안 (Elasticache 도입)

• 속도 개선 요구사항을 맞추기 위해 elasticache를 추가했다.
• Lambda에서 private subnet의 elasticache를 어떻게 접근해야 하는지 몰랐다..

3안 (Cognito 도입)

• 사용자 인증/인가를 Cognito로 처리하는 구조.
• 사용자 정보를 어떻게 DynamoDB에 저장해야 할지에 대한 구조가 부족했다.

2. 아키텍처 초안 (팀 회의 후)

팀 회의 후, ECS 기반 아키텍처로 결정했다.

개발자 요구사항으로 서버리스 제외

백엔드 개발자들이 직접 웹소켓 서버를 구축해보고 싶어해서 서버리스는 제외하게 되었다.

ECS Fargate 선택 이유

• 인프라를 구성해본 경험이 없는 팀원에게 관리 부담이 적어서
• (비용을 지원해주는 프로젝트라 가격이 더 비싸도 한번 써보고 싶어서)

문제점

• ENI를 위한 별도의 private subnet 구성 → 실제로는 ECS에서 자동 할당되어 별도의 subnet이 필요 없다.
• Cognito가 어떻게 애플리케이션과 상호작용하는지 고려하지 않았다.
• Redis/SQS 가 어떻게 작동하는지 모르고 그냥 붙였다. (NAT Gateway, ALB, SQS 작동 방식 등 전반적으로 잘 몰랐다.)

3. Elasticache 선택 논의

아키텍처를 개선하는 과정에서 Redis 사용 여부에 대해 백엔드와 논의해 다음 3가지 옵션을 비교했다.

1. ElastiCache + 직접 pub/sub 구현

구현 난이도 높음. 백엔드 파트에서 불가능하다고 판단.

2. Spring의 Simple Broker 사용

구현 간단하지만, multi-AZ 미지원 (고가용성 X)

3. 외부 브로커(Amazon mq)

구현 단순, 비용 증가

경험 부족 + 짧은 개발 기간 + 비용 지원 → *Amazon MQ * 선택

4. 최종 아키텍처(과제 제출용)

• 실제 aws 콘솔에서 설정은 해보지 않은 상태에서 완성한 아키텍처이다. (현실적인 문제를 겪지 않았다.)

• ALB와 Cognito를 연동하여 인증된 요청만 백엔드에 전달하도록 설계했다. (프론트가 백엔드 레포지토리에 포함되어 배포된다고 생각해서..) 이를 위해서는 Cognito의 callback URI를 ALB 도메인으로 설정해야 했다.

• 하지만 실제로는 프론트엔드가 별도로 배포되기 때문에 callback URI를 프론트 도메인으로 지정해야 하는 충돌이 발생하게 된다...

5. 최종 아키텍처(발표용)

실제 구현을 해보며 실현 가능한 아키텍처가 되었다.

• 위에 적힌 이유로 Cognito + ALB 연동하지 않고, Cognito는 프론트와 소통하는 방식으로 바꿨다.

• 그러자, 백엔드 Spring Security에서 JWT 검증 시 외부 API 호출(JWKS) 필요.. → NAT Gateway 추가

CI/CD 파이프라인 구축

• Dockerfile에서 환경 변수 관리의 중요성 느낌.
• 테스트용 변수도 환경 변수화하면 좋을듯.
• 인프라-백엔드 소통 필요성
  • VPC endpoint로 Amazon MQ에 연결했으나, MQ ARN 전달 실수로 NAT Gateway 제거 시 연결 실패..

배포 후 이슈

• Access Token 내 이메일 누락 → Cognito Pre-sign-up Lambda 트리거 추가
• 사용자 정보 저장→ Post-confirmation Lambda 트리거로 DynamoDB 연동 단, AWS 콘솔에서 사용자 수정 시 반영되지 않는 구조적 한계 있음 (MVP 단계에서는 수용 가능..)

6. NAT Gateway 대체 성공

Lambda + Private API Gateway로 외부 JWK API 호출 대체

• 사실 원래 이 방식으로 설계했으나, API Gateway 정책 오류로 급히 NAT Gateway 붙이게 된 것임.
• API Gateway 정책과 Spring Security 설정(jwk-set-uri)을 수정하여** NAT Gateway 대체 성공!**

Amazon MQ 연결 이슈

• Amazon MQ는 VPC Endpoint로 연결돼 있었으나, 백엔드에 MQ ARN만 전달되어 있어 NAT 제거 시 접근 불가
• 환경 변수/시크릿 관리의 중요성 깨달음 → AWS Parameter Store나 Secrets Manager 사용해보고 싶음. Terraform과 같은 IaC로 관리해도 같은 실수는 발생하지 않을 것 같음.

우리 연구 Lightweight Part-Aware 3D Texture Editing via 2D-Based Methods의 목표는 2D 기반 파트 인식 기법을 활용해 3D 오브젝트의 특정 부위를 편집할 수 있는 경량화 텍스처링 파이프라인을 구현하는 것이다. 파이프라인 중 핵심 단계인 2D 텍스처 생성을 위해 어떤 모델이 적합할지 검토한 결과, 조건 기반 이미지 생성에 특화된 ControlNet-Inpaint를 실험 대상으로 선정했다. 이 글에서는 WebUI 환경에서 ControlNet-Inpaint를 활용해 실제로 특정 부위를 텍스처링할 수 있는지를 확인한 실험 과정을 담았고, 이어서 파이프라인 통합을 위해 해당 기능을 CLI 기반 스크립트로 구현한 과정까지 정리했다.

🌐 ControlNet: Adding Conditional Control to Text-to-Image Diffusion Models

🔗 GitHub | 📄 arXiv

기존 Text-to-Image 모델인 Stable Diffusion에 스케치, 윤곽선 등 시각적 가이드를 추가해 원하는 형태나 구도를 더 정밀하게 제어할 수 있도록 확장한 모델.

• Stable Diffusion에 외부 조건(condition)을 명시적으로 부여해 이미지 생성 과정을 세밀하게 조정할 수 있도록 만든 확장 네트워크 구조
• 기존에는 텍스트 프롬프트만으로 이미지를 생성했다면, ControlNet은 다음과 같은 low-level vision 정보를 함께 활영하여 결과물의 형태, 구성, 레이아웃을 더 정확하게 제어한다.
  • 윤곽선 (Edge)
  • Depth Map
  • Pose Estimation
  • Segmentation

ControlNet 아키텍처

• Base 모델: Stable Diffusion 기반 U-Net 아키텍처
• Control branch: 각 U-Net 블록에 연결된 side branch로, 입력 condition에서 추출된 feature 전달
• Zero Convolution: 초기 가중치를 0으로 설정해 pretrained weight를 손상시키지 않음

학습 시 base 모델의 weight는 freeze하고 control branch만 fine-tuning하여 학습 효율이 높고, 기존 pretrained 모델의 weight를 손상시키지 않아 성능을 유지하면서도 새로운 조건 입력에 유연하게 반응할 수 있다.

ControlNet-Inpaint

• 특정 부위를 복원하거나 새롭게 생성하는 데 특화된 Inpainting 전용 모델
• 텍스트 프롬프트 외에도 원본 이미지 + 마스크 정보를 활용하여 특정 영역만 편집 가능
• 특징
  • 마스크 기반으로 특정 부위만 변경 가능
  • 원본 구조 유지 및 context-aware 생성
  • 프롬프트로 스타일·질감·객체 제어 가능
  • Part-aware 편집에 최적화

💡 우리 파이프라인에 ControlNet-Inpaint가 필요한 이유

• 텍스트 + 이미지 + 마스크 조합으로 원하는 부위만 정확하게 텍스처링 가능
• WebUI 실험을 통해 성능 검증 완료
• 빠른 속도 (1장당 5~10초)와 낮은 VRAM 요구사항 (8GB)으로 경량화 목표와 일치

💻 Web UI로 ControlNet-Inpaint 실행하기

참고

• Guidelines for using inpaint in A1111
• sd-webui-controlnet
• stable-diffusion-webui

0. 실행 환경

• GPU: RTX 3070 Ti Laptop
• OS: Windows 11

1. Stable Diffusion Web UI 설치

1. sd.webui.zip 다운로드 후 압축 해제
2. update.bat 실행해 최신 버전으로 업데이트
3. run.bat 실행 후, 브라우저에서 http://127.0.0.1:7860 접속

2. ControlNet 확장 설치

1. Extensions → Install from URL
2. URL 입력 (https://github.com/Mikubill/sd-webui-controlnet.git) → Install 설치 완료 메시지 확인
3. Installed > Check for updates > Apply and restart UI 클릭
4. 터미널 포함 전체 재시작

3. ControlNet-Inpaint 모델 다운로드

• 📥 Safetensors 다운로드
• 저장 경로: sd.webui\webui\extensions\sd-webui-controlnet\models

4. Inpaint 실행

1. img2img > Generation > Inpaint Upload
   

2. 원본 이미지, 마스크 이미지 업로드

3. ControlNet 활성화 스크롤을 내려보면 ControlNet 패널이 보인다. 확장한 뒤 Enable을 눌러서 활성화해주고, Preprocessor와 Model을 설정해준다.

4. 텍스트 프롬프트 입력 후 Generate 클릭

5. 실행결과 이미지와 텍스트 조합을 통한 특정 부위 수정 생성 로그는 터미널에서 확인 가능

🛠️ CLI 기반 ControlNet-Inpaint 스크립트 구현

WebUI는 실험에는 적합하지만, 반복 실험과 파이프라인 통합에는 비효율적이다. → 따라서 CLI 방식으로 ControlNet-Inpaint를 실행할 수 있는 스크립트를 별도로 구현했다.

환경 설정

• OS: Ubuntu 22.04
• Python: 3.10
• GPU: RTX Titan
• Cuda: 11.8
• Pytorch: 2.1.0

# conda 환경 생성
conda create -n controlnet python=3.10 -y
conda activate controlnet

# PyTorch 2.1.0 + CUDA 11.8
conda install pytorch==2.1.0 torchvision==0.16.0 torchaudio==2.1.0 pytorch-cuda=11.8 -c pytorch -c nvidia

pip install --upgrade diffusers transformers accelerate safetensors \
             pillow opencv-python tqdm

pip install xformers==0.0.25 triton==2.2.0

프로젝트 구조

controlnet-inpaint-cli/
├── assets/
│   ├── init.png          # 원본 이미지
│   └── mask.png          # 마스크 이미지, 흰색 수정
├── outputs/
│   └── result.png        # 결과물 저장 폴더
├── controlnet_inpaint_cli.py
└── README.md

스크립트

controlnet_inpaint_cli.py

#!/usr/bin/env python
import argparse, torch
from diffusers import ControlNetModel, StableDiffusionControlNetInpaintPipeline
from diffusers.utils import load_image

# === 내부 고정 파라미터 ===
NUM_STEPS      = 40      # 샘플링 횟수
GUIDANCE_SCALE = 7.5     # CFG
COND_SCALE     = 1.0     # ControlNet 영향력
BASE_MODEL     = "runwayml/stable-diffusion-v1-5"
CN_MODEL       = "lllyasviel/control_v11p_sd15_inpaint"

def parse_args():
    p = argparse.ArgumentParser()
    p.add_argument("--prompt", required=True, help="텍스트 프롬프트")
    p.add_argument("--image",  required=True, help="원본 이미지 경로")
    p.add_argument("--mask",   required=True, help="마스크 이미지 경로")
    p.add_argument("--out",    required=True, help="결과 이미지 경로")
    return p.parse_args()

def main():
    args   = parse_args()
    device = "cuda" if torch.cuda.is_available() else "cpu"
    dtype  = torch.float16 if device == "cuda" else torch.float32

    # 1) 모델 로드
    controlnet = ControlNetModel.from_pretrained(CN_MODEL, torch_dtype=dtype)
    pipe = StableDiffusionControlNetInpaintPipeline.from_pretrained(
        BASE_MODEL, controlnet=controlnet, safety_checker=None, torch_dtype=dtype
    ).to(device)
    pipe.enable_model_cpu_offload()
    try: pipe.enable_xformers_memory_efficient_attention()
    except: pass

    # 2) 이미지 로드
    init_img = load_image(args.image).convert("RGB")
    mask_img = load_image(args.mask).convert("L")

    # 3) 추론
    result = pipe(
        prompt=args.prompt,
        image=init_img,
        mask_image=mask_img,
        num_inference_steps=NUM_STEPS,
        guidance_scale=GUIDANCE_SCALE,
        controlnet_conditioning_scale=COND_SCALE,
    ).images[0]

    result.save(args.out)
    print(f"Saved → {args.out}")

if __name__ == "__main__":
    main()

• ControlNetModel + StableDiffusionControlNetInpaintPipeline 조합.
• pipe.enable_model_cpu_offload() → 8 GB VRAM에서도 동작.
• --cond-scale (0 ~ 2)로 ControlNet 영향력 조정.

실행방법

# conda 환경 활성화 후 프로젝트 루트에서
python controlnet_inpaint_cli.py \
  --prompt "a chair with white chair legs" \
  --image  assets/init.png \
  --mask   assets/mask.png \
  --out    outputs/tiger_inpaint.png \

Amazon Cloud Club Ewha 3기 사이드 프로젝트

Infra 파트를 맡았다. 이번주는 채팅 시스템 위한 Websocket 스터디, 유저 시나리오 작성, 아키텍처 초안 작성을 진행했다.

0. 주제 및 요구사항

주제 채팅 시스템 설계

요구사항

• 보안적으로 안전하도록 구성한다.
• 캐시(ElastiCache) 사용 권장
• 가용성 및 안정성을 높인다.
• AWS의 서비스들을 최대한 활용하여 운영비용을 절감한다.
• $40 ~ $60 사이의 비용을 사용한다.
• 최소한의 기능을 완성도 있게 구현한다.

인프라 요구사항

• 평균적으로 약 1000명의 유저가 해당 서비스를 사용
  • 최대 동시 접속 사용자 수 500명 예상
• 초당 약 50건의 메시지 전송 처리 필요
• 최대 6개월간 메시지 내역 보관 필요
• 메시지 전송 지연 시간은 2초 이내

심화 요구사항

• 그룹 채팅 지원: 최대 100명까지 참여 가능한 그룹 채팅방 제공
• 첨부 파일: 채팅에서 최대 10MB 크기의 파일 첨부 기능 지원
• 오프라인 메시지 처리: 사용자가 오프라인 상태일 때 메시지 저장 및 재접속 시 동기화
• 멀티 디바이스 지원: 동일 계정으로 최대 3개 기기 동시 접속 지원 (동일 계정 접속 수 제한)

1. Websocket 스터디

inpa.tistory.com

필요성

• HTTP는 클라이언트의 요청이 있어야 서버가 응답 → 새로운 정보를 얻기 위해 항상 새로운 URL 요청
  • Polling 방식으로 채팅 구현할 수 있지만, 단방향 통신의 한계
• 웹이 발전하며 더 동적인 표현과 상호작용이 필요해짐
• “실시간 양방향 통신” 필요

웹소켓이란?

• HTML5 표준 기술
• 클라이언트(브라우저)와 서버 사이 동적인 양방향 채널 구성
• Websocket API 로 사용
• 최초 연결은 HTTP로 연결, 그 후로 지속적인 양방향 통신 가능

AWS Websocket API

API Gateway의 WebSocket API 개요 - Amazon API Gateway

자습서: WebSocket API, Lambda 및 DynamoDB를 사용하여 WebSocket 채팅 앱 생성 - Amazon API Gateway

자습서: AWS 통합을 통해 WebSocket API 생성 - Amazon API Gateway

WebSocket API, Lambda 및 DynamoDB를 사용하여 AWS 서비스만을 통해 서버리스 WebSocket 채팅을 구현할 수 있다.

2. 유저 시나리오

이때는 프론트엔드가 없었기에, 백엔드 관점에서 작성했다.

회원가입 및 로그인 - REST API
- 사용자 A는 이름, 이메일, 비밀번호 등 최소한의 정보를 입력하여 회원가입을 진행한다.
- 클라이언트는 사용자 정보를 `POST /signup` API로 서버에 전송하고, 서버는 이를 저장 후 성공 응답을 반환한다.
- 이후, A는 로그인 화면에서 이메일과 비밀번호를 입력하고 `POST /login` API를 통해 인증 요청을 보낸다. 이때 비밀번호는 해싱하여
- 서버는 인증이 성공하면 JWT 토큰 또는 세션 토큰을 발급하며, 클라이언트는 이를 저장해 이후 요청에 인증 헤더로 포함한다.
- 로그인 후 사용자 A는 인증 토큰을 기반으로 WebSocket 연결을 시작하거나, REST API를 통해 채팅 이력을 조회할 수 있다.

1:1 채팅 - WebSocket

- 사용자 A는 서버와 WebSocket 연결을 수립한다.
- 사용자 B도 별도로 WebSocket 연결을 수립해 있는 상태다.
- A가 메시지를 작성하고 WebSocket을 통해 메시지를 전송한다.
- 서버는 메시지를 저장한 뒤, B의 WebSocket 세션을 확인해 2초 이내에 메시지를 푸시(PUSH)한다.
- B가 실시간 응답을 보내면 동일한 흐름으로 A에게 전송된다.

그룹 채팅 - WebSocket

- 사용자 A는 WebSocket을 통해 그룹 채팅방을 만든다.
- 그룹 생성 후, A가 메세지를 전송한다.
- 서버는 해당 메시지를 저장한 뒤, 그룹 참가자(B, C)의 연결된 WebSocket 세션을 찾아 동시에 브로드캐스팅한다.
- 각 수신자는 동일한 시간 내 (2초 이내)에 메시지를 수신한다.

메시지 이력 조회 - REST API

- 사용자 A가 채팅방에서 이전 대화를 확인하고자 할 때, `GET /chat/history?chat_type=group&chat_id=g123&limit=50` 형태의 API를 호출한다.
- 서버는 캐시 저장소 또는 백업된 저장소(DB)에서 해당 채팅방 ID에 대응하는 메시지를 역순으로 페이징 조회한다.
- 클라이언트는 받은 메시지를 타임스탬프 기준으로 정렬해 사용자에게 출력한다.
- 이 API는 WebSocket 세션이 종료된 상태에서도 호출 가능하며, 과거 6개월 이내 데이터가 반환된다.

네트워크 불안정 대응

- 사용자 A가 메시지를 보내는 도중 연결이 끊기면, WebSocket 클라이언트는 자동으로 재연결을 시도한다.
- 재연결 후, 미확인 메시지를 다시 서버에 전송한다 (`message_id` 포함).
- 서버는 `message_id` 또는 타임스탬프를 기준으로 중복 메시지를 식별하고, 중복 없이 저장 및 전송한다.
- 메시지는 수신자에게 정상적으로 도착한다.

최종 유저 시나리오

팀원들이 작성해준 최종 유저 시나리오는 다음과 같다.

1. 회원가입
    - 사용자는 이메일, pw로 회원가입

2. 로그인/로그아웃
    - 사용자는 이메일, pw로 로그인
    - 사용자는 이메일, pw로 로그아웃

3. 일대일 채팅
    - 사용자는 프로필 목록에서 채팅할 상대를 선택
    - 혹은 채팅방 목록에서 채팅방을 선택
    - 실시간으로 메시지 전송 및 수신
    - 읽음 확인 및 타이핑 중 표시 기능 제공

4. 다대다 채팅
    - 사용자는 여러 참가자를 초대하여 그룹 채팅방 생성
    - 혹은 채팅방 목록에서 채팅방을 선택
    - 모든 참가자는 참가자 추가/제거 가능
    - 모든 참가자는 메시지를 보내고 받을 수 있음

5. 이전 메세지 조회
    - 채팅방 입장 후, 해당 채팅방의 이전 메세지들 확인 가능
    - (추가 기능) 이미지/파일 첨부 및 공유기능
    - 이전 메세지 검색기능

6. (추가 기능) 브라우저 푸시 메세지
    - 브라우저에 접속해 있을 때 채팅 송신 시 푸시 메세지 팝업

7. (추가 기능) 파일 전송/조회
    - 사용자는 일대일 채팅으로 파일을 전송할 수 있음
    - 사용자는 다대다 채팅으로 파일을 전송할 수 있음

3. 아키텍처 초안

aws 서비스를 최대한 활용하고, 비용을 줄이기 위해 Lambda를 이용한 심플한 아키텍처를 설계했다.

최소 아키텍처

가장 간단한 아키텍처이다. API gateway, Lambda, DynamoDB만을 이용하여 채팅을 구현한다.

캐싱 추가

ElastiCache를 추가했다. ElastiCache를 사용하기 위해 VPC의 private subnet 안에 배치했지만, 서버리스 아키텍처에 안어울린다고 생각했다.

aws.amazon.com 찾아보니 이렇게 서버리스로도 사용할 수 있다고 한다.

Cognito 추가

Cognito를 사용하면 jwt를 사용하지 않아도 되는줄 알고 잘못 그린 것같다.

회의 결과, 백엔드 파트가 직접 서버를 구성하고 WebSocket을 구현해보고 싶어해서 함수단위로 실행하는 Lambda는 사용하지 않기로 했다. 대안은 EC2, ECS등이 있다. ECS Fargate의 경우 서버리스지만, 컨테이너 기반이라 스프링부트 앱을 컨테이너화해서 그대로 올리면 백엔드 입장에선 달라지는게 없는 것 같아서 괜찮은 대안이다.

최종 아키텍처 초안

draw.io에서 aws 2025를 추가하면 쉽게 그릴 수 있다.

네트워크 구성

• ALB HTTPS · WebSocket 트래픽을 Fargate 컨테이너로 분산
• CloudFront CDN 캐시 배포
• Route53 도메인 관리, DNS 라우팅
• NAT Gateway(필요 시) 프라이빗 서브넷의 Fargate가 외부와 통신

컨테이너 실행 및 배포

• ECS 컨테이너 오케스트레이션(서비스, 배포, 헬스체크)
• Fargate Spring Boot 채팅 컨테이너를 서버리스로 실행
• ECR 백엔드 도커 이미지 저장소

인증/보안

• IAM ECS/CI/CD/Secrets 권한 제어
• Secrets Manager 애플리케이션 설정·DB 자격증명·JWT 서명 키 같은 비밀(Secrets), 파라미터 중앙 관리
• Cognito 사용자 인증 및 JWT 발급 *클라이언트가 인터넷에서 직접 호출, 백엔드는 JWT 검증만 수행 (인터넷 X)

데이터 저장/전송

• DynamoDB Message, RoomMeta, User(TTL 6개월) 저장
• SQS(or MQ) DynamoDB 비동기 쓰기 대기열
• ElastiCache for Redis 실시간 메시지 fan‑out, WebSocket 세션 관리
• S3 정적 파일, 프론트 자산 저장소

메세지 쓰기 시나리오 1. 클라이언트로 메시지 전송 (실시간) 서버는 먼저 ElastiCache Redis Stream에 메시지를 XADD하여 WebSocket 구독 클라이언트에게 바로 fan-out. 2. 비동기 저장 처리 동시에 메시지를 Amazon SQS에 큐잉 → 백그라운드에서 스프링부트 서버가 읽어 DynamoDB에 영구 저장. 메시지 유실 방지를 위해 XADD 성공 후 SQS 전송까지 완료된 후에만 ACK 처리.

로깅/모니터링

• CloudWatch 로그 수집·메트릭·알람

-1

더 공부해야 할 주제

• ECS Fargate를 선택한 이유
• ECS Fargate는 서버리스인데, private subnet에 tasks가 생성되어서 어떻게 작동하는지
• ElastiCache와 ECS Fargate Task는 동일 vpc에 있으니까 nat gateway가 필요 없는지
• cognito, cloudfront, route53는 언제 어떻게 구성해야 할지
• 현재의 multi-az 구조가 필요한지
• cloud watch 사용법
• sqs/mq를 추가할지 말지, 어떻게 dynamodb와 연결하는지
• 비용 계산

적다보니 너무 많다..

1.6 TCP 커넥션

"HTTP는 애플리케이션 계층 프로토콜이다. HTTP는 네트워크 통신의 핵심적인 세부사항에 대해서 신경 쓰지 않는다. 대신 대중적이고 신뢰성 있는 인터넷 전송 프로토콜인 TCP/IP 에게 맡긴다."

TCP Connection Identifier

• IP 주소: 서버의 위치를 나타내는 네트워크 주소
• 포트 번호: 해당 서버 내에서 실행 중인 애플리케이션을 식별 (HTTP: 80, HTTPS: 443)

Telnet, NetCat(nc)

HTTP 요청을 직접 테스트하거나 커넥션을 점검할 때 유용한 도구

1.8 웹의 구성요소

프록시

클라이언트-서버 중개자

• 포워드 프록시 클라이언트(Front-end)에게 미리 저장해둔 정적 데이터 반환

• 리버스 프록시 다수의 서버를 프록시 서버 하단부에 배치, 조건에 맞는 요청을 적절한 서버에게 전달(분산) jcdgods.tistory.com

항목 | Forward Proxy | Reverse Proxy |-|-|-| 대리하는 쪽 | 클라이언트 (사용자) | 서버 (서비스 제공자) 주 사용 목적 | - 사용자의 익명성 보호
- 방화벽 우회
- 접근 제어
- 캐싱 | - 서버 IP 숨김
- 로드 밸런싱
- SSL 종료
- 캐싱 접속 대상 | 여러 외부 서버 (인터넷 등) | 여러 내부 서버 (서비스 서버 등) 요청 흐름 | 사용자가 프록시에 요청 → 프록시가 외부 서버에 요청 | 사용자가 프록시에 요청 → 프록시가 내부 서버에 전달 사용 예시 | - 회사에서 사내 직원들이 인터넷 접속
- VPN, Tor
- 웹 필터링 | - Nginx를 웹서버 앞에 둠
- AWS CloudFront
- Netlify, Vercel 같은 플랫폼 IP 숨김 대상 | 사용자의 IP 주소 | 서버의 IP 주소 클라이언트 입장 | 실제 서버를 모름 (프록시 통해서만 접속) | 실제 서버가 어디 있는지 모름 (프록시 주소로만 접속)

캐시

일종의 프락시 서버 HTTP 헤더의 Cache-Control, ETag, Last-Modified 등을 통해 동작

프락시 = 캐시 라고 알고 있었는데, 캐시는 캐싱 기능을 하는 일종의 프락시였다. 프락시는 캐싱외에도 보안, 로드발란싱, 접근 제어 등으로 사용된다.

게이트웨이

서로 다른 프로토콜/네트워크와 HTTP 사이를 중개하는 서버 클라이언트 입장에서는 일반 HTTP 서버처럼 보임 e.g., NAT 게이트웨이, 인터넷 게이트웨이(IGW)

여러 게이트웨이를 배우면서 게이트웨이가 무엇인지는 몰랐는데, 다른 네트워크/프로토콜과 http를 중개한다는 걸 알게되면서 내가 알고있던 게이트웨이들의 공통점이 그것인걸 깨달았다.. NAT 게이트웨이 - 사설 망과 인터넷 중개 IGW - VPC와 인터넷 중개

터널

데이터 내용을 열어보지 않고 그대로 전달만 하는 중개자

에이전트

사용자 대신 HTTP 요청을 생성하고 전송하는 클라이언트 프로그램 HTTP 요청 시 User-Agent 헤더를 통해 자신을 식별함 e.g., 웹 크롤러

2.1 인터넷의 리소스 탐색하기

URL이 있기 전

"ftp.joes-hardware.com에 FTP로 접속해. 익명 사용자로 로그인한 다음 비밀번호로 네 이름을 입력해. pub 디렉터리로 이동한 다음, 바이너리 형식으로 전환해. 이제 complete-catalog.xls란 이름의 파일을 너의 로컬 파일 시스렘에 내려 받은 다음 보면 될 거야" -> “ftp://ftp .lots-o-books . com/pub/complete-catalog.xls를 열어봐”

• URL을 사용하면 이런 애플리케이션들에서 하나의 인터페이스를 통해 일관된 방식으로 많은 리소스에 접근 가능

2.2 URL 문법

<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>

• 중요 컴포넌트: 스킴, 호스트, 경로
• localhost http://localhost:8080, http://127.0.0.1:8080

  The IP address 127.0. 0.1 is called the loopback address and is used by a computer to refer to itself. It is also known as localhost. When a server is running on your local PC, it will be accessible at 127.0. 0.1.

  스킴

  어떤 프로토콜? 대소문자 구분x

호스트와 포트

리소스 호스팅 장비, 서버 위치 호스트-> 도메인 이름 또는 IP 주소 포트 -> 생략 시 기본 포트 사용 (HTTP는 80, HTTPS는 443)

ACC 스터디에서 HTTP 완벽 가이드를 읽고 정리하는 글

1부 HTTP: 웹의 기초
├── 1장 HTTP 개관
│   ├── 1.3 리소스
│   ├── 1.4 트랜잭션
│   ├── 1.5 메세지

"HTTP는 신뢰성 있는 프로토콜을 사용하기 때문에"

• HTTP/3는 UDP인데? 라고 생각이 들었지만 QUIC이 UDP위의 전송 계층 프로토콜이고 신뢰성을 보장한다.

MIME(Multipurpose Internet Mail Extensions)

• Content-type: image/jpg
• HTTP/3에서도 쓰나?하는 의문이 들었다. 챗지피티에 따르면 HTTP의 핵심 메시지 포맷과 콘텐츠 타입 표현 방식은 유지된다고 한다.

URI vs. URL vs. URN

• URI(Uniform Resource Identifier)의 종류로 URL(Uniform Resource Locator), URN(Uniform Resource Name), URC 등이 있다.
• URI, URL 는 사실상 동의어처럼 쓰이고 있다. 하지만 URL은 URI의 일종이고, URL이 광범위하게 쓰이고있기 때문에 동일하게 인식되는 것이다. (URL은 파일의 위치를 정확히 가르키고 있기 때문에 당연히 Identifier가 되니까 URI의 일종)
• URN은 상용화되지 않아서 많은 사람들이 개념에 대해 헷갈려한다. 결론은 URI와 URL만 알아도 괜찮을 듯.

RFC3986 1.1.3. URI, URL, and URN A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name. An individual scheme does not have to be classified as being just one of "name" or "locator". Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305].

트랜잭션

• Request, Response를 주고받는것을 트랜잭션이라고 한다.
• 웹페이지는 여러 객체로 되어있기 때문에, 하나의 웹페이지를 가져올 때 여러번의 트랜잭션이 일어난다.
• 컴퓨터네트워크 수업에서 HTTP가 (base HTML + 웹페이지 내의 객체들)을 전송하는 여러 방식들을 배웠다. 뒷장에 자세히 나올듯
• Persistent, Non-Persistent, Non-Persistent with parallel, Pipelining*

Amazon Cloud Club Ewha 3기 핸즈온 세션 이론 정리 Week 2 - 데이터베이스 - RDS, DynamoDB

1. RDS

1-1. 데이터베이스

개요

구조화된 정보 또는 데이터의 조직화된 모음. DBMS에 의해 제어된다.

종류

Relational Database의 종류

1-2. AWS RDS

aws.amazon.com

개요

*Relational Database Service *AWS 클라우드에서 관계형 데이터베이스를 쉽게 설치, 운영 및 확장할 수 있도록 지원하는 완전관리형 서비스.

장점

• 간편한 관리
• 가용성(Availability) 및 안정성(Durability) 자동 백업, 스냅샷, Multi-AZ
• 보안성(Security)
• 확장성(Scalability) Read Replica 지원
• 비용 효율성(Cost Effective)

Multi-AZ

aws.amazon.com

• 다른 가용영역(AZ)에 자동으로 복제본 생성 및 동기화
• 복제본은 대기 데이터베이스(Standby) 역할
• 장애 발생 시 자동으로 대기 인스턴스로 페일오버(Failover)
• 성능 향상이 아닌 가용성 확보 목적

Read Replica

aws.amazon.com

• 읽기 전용 복제본 생성
• 읽기 쿼리의 성능 향상 및 분산 처리 가능 (Scale Out) 읽기 중심의 데이터베이스 워크로드 처리량 향상
• 비동기 복제
• 읽기 성능 분산 및 Scale Out

SAA Example Q: RDS를 사용하고 있는 회사에서 하루/한달에 한 번씩 통계용 으로 데이터를 읽어오는 데 성능에 문제가 생기는 것을 발견 했다. 이때의 솔루션은? A: RDS Read Replica를 사용한다.

Multi-AZ vs. Read Replica

2. DynamoDB

2-1. SQL

SQL vs. NoSQL

NoSQL

• 비관계형 데이터베이스에서 사용
• 가용성과 확장성이 높고 고성능에 최적화
• Instagram, facebook등에서 사용

2-2. Amazon DynamoDB

개요

• 10ms 미만 응답 속도의 서버리스 NoSQL 완전관리형 DB
• 고가용성 및 내구성 보장
  • 10ms 내 응답
  • SSD 저장 + 다중 AZ 복제
• Auto Scaling 지원

핵심구성요소

• Table: 데이터 저장 단위
• Items(항목): 테이블의 한 행 People 테이블에서 각 항목은 한 사람 Cars 테이블의 경우 각 항목은 차량 한 대
• Attributes(속성): 아이템의 속성 각 항목은 하나 이상의 속성으로 구성 People 테이블의 항목: PersonID, LastName, FirstName

• People 테이블에서 기본 키(PK)는 한 개의 속성(PersonID)으로 구성
• 기본 키를 제외하고, People 테이블에는 스키마가 없다. : 속성이나 데이터 형식을 미리 정의할 필요가 없다
• 각 항목에는 자체의 고유 속성이 있을 수 있다
• 일부 항목에는 중첩된 속성(Address)도 가질 수 있다

테이블구조

• Primary key + Attributes
• Primary Key = Partition Key (+ Sort Key)
  • Partition Key: 데이터 분산 기준 (Equal 조건만 가능)
  • Sort Key: 파티션 내 정렬 기준 (범위 쿼리 가능)

Partition Key

• 기본 키. 데이터 분산 기준
• 파티션 결정 DynamoDB는 테이블의 크기가 10G를 초과하면 데이터에 대한 Partition을 나눈다(Sharding) 같은 Partition Key를 가지면 같은 Partition에 저장되는 것(Hash Function)

  Sort Key

• Partition Key로 저장할 파티션 공간을 결정하고 나서, 같은 Partition이라면 Sort Key 값을 기준으로 정렬되어 저장됨
• 일치, 부등호, 포함 등의 범위를 지정할 수 있는 검색을 지원한다
• Partion Key는 일치검색(Equal)만 지원

AWS Lambda

• DynamoDB에서는 Batch 쓰기 지원 Lambda를 이용해서 batch.put_item으로 여러번의 데이터 추가를 하나의 함수로 한 번에 진행할 수 있다 BatchWriteItem API: 한 번에 최대 25개의 항목까지 DynamoDB 테이블에 삽입할 수 있는 API CloudWatch Events : 특정 시간 또는 주기적으로 Lambda 함수를 실행하도록 설정
• DynamoDB의 특성상 (NoSQL) Join 지원 X Join이 부득이하게 필요한 경우 Lambda로 구현 가능

Amazon Cloud Club Ewha 3기 핸즈온 세션 이론 정리 Week 2 - 스토리지 - S3 & CloudFront

1. Storage

1-1. Cloud Storage란?

: 클라우드 컴퓨팅 제공업체를 통해 데이터와 파일을 인터넷에 저장할 수 있는 클라우드 컴퓨팅 모델 사용자는 Public 인터넷 또는 Private 네트워크로 스토리지 접근

1-2. Storage 유형 비교

2. Amazon S3

2-1. 개요

: AWS의 대표 Object Storage 서비스 데이터를 버킷 내의 객체로 저장

2-2. 구성

구성: 버킷 + 객체 (버킷: 최상위 디렉토리, 객체: 디렉토리 내에 저장되는 파일)

📁 버킷 (Bucket)

: 객체 저장을 위한 컨테이너

• 객체 무제한으로 저장 가능
• 전역적으로 고유한 이름 필요
• 계정당 최대 100개 생성 가능

📚 객체 (Object)

: S3에 실제로 저장되는 기본 단위 데이터 개체

특징

• 하나 이상의 버킷에 저장
• 최대 크기: 5TB

  구성

  데이터 + 메타데이터
• 데이터: 저장하려는 실제 콘텐츠 (임의의 바이트 시퀀스)
• 메타데이터: 객체 정보 저장용 이름-값 쌍 (사용자 지정 가능)

  식별 방식

  버킷 + 키 + 버전 ID 조합으로 객체를 유일하게 식별
• 키: 객체의 이름, 버킷 내 고유 ID
• 버전 ID: 객체 저장 시 S3가 자동 생성하는 고유 문자열

  태그

  객체 분류 및 관리에 사용되는 키-값 형태의 메타정보

  액세스 제어 정보

  객체 접근 권한 관리 리소스 기반(ACL, 버킷 정책) + 사용자 기반 권한 제어 모두 지원

2-3. 보안

🔑 데이터 암호화

서버측 암호화 (Server-Side Encryption, SSE)

• 데이터를 받은 애플리케이션/서비스 서버가 해당 데이터 암호화
• 사용자가 S3에 데이터를 업로드하면 AWS가 해당 데이터를 서버에서 자동으로 암호화하여 저장하고, 사용자가 데이터를 요청할 때 자동으로 복호화하여 제공
• 현재 S3는 서버 측 암호화(SSE-S3)를 S3 내 모든 버킷 암호화의 기본 수준으로 적용

  클라이언트측 암호화 (Client-Side Encryption)

• 전송 및 저장시 보안을 보장하기 위해 로컬에서 데이터 암호화 -> AWS를 포함한 제3자에게 객체 노출 방지 높은 보안 보장, 관리 및 구현 복잡성 증가
• S3 암호화 클라이언트 S3 암호화 클라이언트가 객체를 암호화하고 버킷에 업로드 사용자와 S3간 중재자 역할

🪬 액세스 제어 방식

• IAM (Identity and Access Management) AWS에서 사용자, 그룹, 역할에게 적절한 권한을 부여하고 접근을 제어하는 서비스

2-4. 스토리지 관리

버전 관리

• 한 버킷에 여러버전의 객체 보관 -> 실수로 삭제/수정된 객체 복구 가능
• 버킷 버전관리 활성화 -> 저장되는 객체에 버전id 자동 생성
• 한 번 활성화하면 비활성화 불가(중단 가능)

객체 복제

스토리지 클래스

수명 주기 (Lifecycle)

3. Amazon CloudFront

3-1. 개요

: AWS의 CDN (Content Delivery Network) 서비스 사용자 가까운 위치(Edge Location)에서 콘텐츠 캐싱 및 전송

3-2. 주요 구성 요소

3-3. 동작 흐름

1. 사용자가 콘텐츠 요청
2. DNS가 가장 가까운 Edge Location으로 라우팅
3. Cache Hit → 바로 제공
   Cache Miss → REC 확인 → 없으면 Origin 요청
4. 콘텐츠 수신 후 Edge Location에 캐싱

3-4. Origin 보안

3-5. 기능

3-6. 장점

• 지연 시간 감소 → 빠른 응답 제공
• 트래픽 증가 대응 → 로드 밸런싱 기반 확장성
• 보안 강화 → HTTPS, 접근 제어 정책, OAI/OAC

Amazon Cloud Club Ewha 3기 핸즈온 세션 이론 정리 Week 1 - 네트워크 구성 - VPC, Route53

1. Route53

1-1. Route53 개요

: AWS의 DNS 서비스

주요 기능

• 도메인 등록
• DNS 라우팅
• 리소스 상태 확인

1-2. IP(Internet Protocol)

인터넷에 연결되어 있는 모든 장치를 식별할 수 있도록 각각의 장비에게 부여되는 고유 주소

• state ↔ dynamic
• public ↔ private
  • cmd ipconfig → private ip 주소

1-3. DNS(Domain Name System)

DHCP(L3 ip주소 할당) → ARP(L4 mac주소 조회) → DNS(L3 ip 주소 조회) → TCP(L2 연결) → HTTPS(L5 통신)

• Forwarding DNS 도메인 네임(aws.amazon.com)을 네트워크 주소(192.168.1.0)으로 변환

• Reverse DNS

• 분산형 데이터베이스 시스템 Root DNS로부터 .com DNS(TLD DNS) 를 찾고, .com DNS로부터 amazon.com DNS(Authoritative DNS)를 찾아, amazon.com DNS에서 aws.amazon.com의 IP주소 획득(계층적)

• DNS Routing

• DNS 레코드 Request 패킷을 받았을때, 어떻게 처리할지 정해둔 지침으로, RR(Name, Value, Type, TTL)의 형식 AWS 는 alias 레코드 제공 → AWS 리소스로 라우팅 가능

1-4. 라우팅 정책

docs.aws.amazon.com

• 단순 라우팅 정책(Simple routing policy)
• 장애 조치 라우팅 정책(Failover routing policy)
• 지리 위치 라우팅 정책(Geolocation routing policy)
• 지리 근접 라우팅 정책
• 지연 시간 라우팅 정책
• IP 기반 라우팅 정책
• 다중 응답 라우팅 정책(Multivalue answer routing policy)
• 가중치 기반 라우팅 정책(Weighted routing policy)

2. VPC

2-0. 배경지식

💡 IP 주소(revisit)

• 32비트(IPv4)
• 8비트씩 표현
• 255.255.255.255(11111111.11111111.11111111.11111111)

  💡 CIDR(Classless Inter-Domain Routing)

  aws.amazon.com
• 라우팅 효율성을 향상시키는 ip주소 할당 방식
• ip 주소 = 네트워크주소 + 호스트주소
  • 이 네트워크 주소와 호스트 주소가 특정 개수의 비트로 할당되지 않고(Classless), 가변 길이 서브넷 마스킹(Variable Length Subnet Mask, VLSM)에 의해 결정됨
• 장점
  • IP 주소 낭비 감소
  • 데이터를 빠르게 전송
  • Virtual Private Cloud 생성
  • 슈퍼넷을 유연하게 생성
• AWS의 CIDR Block

  💡 AWS 구조

  aws.amazon.com
• Region(리전)
  • AWS가 전 세계에서 데이터 센터를 클러스터링하는 물리적 위치
  • AWS의 데이터센터들을 지리적으로 나눈 단위
  • 각 AWS 리전은 지리적 영역 내에서 격리되고 물리적으로 분리된 최소 3개의 AZ로 구성
• AZ(Availability Zone, 가용 영역)
  • 여러 데이터 센터들을 묶은 단위
  • 논리적 데이터 센터의 각 그룹
  • AWS 리전의 중복 전력, 네트워킹 및 연결이 제공되는 하나 이상의 개별 데이터 센터로 구성

2-1. VPC (Virtual Priavate Cloud)

docs.aws.amazon.com medium.com/harrythegreat *: 나만의 독립된 가상 네트워크 망 * ⬆️ VPC 이전 ⬆️ VPC 등장 -> VPC별로 네트워크 구성, 설정 가능. 각각의 VPC는 완전히 독립된 네트워크처럼 작동.

• 리전당 5개 설계 가능(리전 단위로 생성)
• VPC당 5개의 CIDR 설정 가능
• 사설 IPv4 범위만 할당 가능
• VPC CIDR는 다른 VPC나 네트워크와 범위가 겹치면 안됨
• 계정을 만들면 Default VPC 생성됨

✅ Subnet

*: IP 네트워크 논리적인 영역을 쪼개서 만든 하위 네트워크망 *

• Public Subnet ↔ Private Subnet
• VPC의 IP 범위 안에서 서브넷의 IP 범위 지정. 상위 네트워크보다 subnet mask 더 길고, ip 범위 작음.
• VPC가 하나의 리전에 존재하는 것처럼, 서브넷은 하나의 AZ에만 존재

Why subnetting?

• 더 많은 네트워크망을 만들기 위해서.
• 필요한 host 개수만큼만 host ip 배정하고, subnetting을 통해 더 많은 네트워크 망 생성

✅ Internet Gateway(IGW)

: VPC와 인터넷을 연결해주는 관문

• VPC의 리소스를 인터넷에 연결하도록 허용하는 EC2 인스턴스나 람다 함수
• VPC 기본적으로 격리된 네트워크 환경 → VPC 리소스들은 기본적으로 인터넷 연결 X
• IGW와 Subnet 연결해야 인터넷 연결 가능, 이를 위해 Subnet의 Routing Table 설정 필요

✅ Routing Table

• ⬆️ Routing table
  • 모든 ip → IGA A
  • private subnet ip → Local(IGA A로 안감, longest prefix match)
• A는 private subnet, B는 public subnet

private subnet 내부의 리소스(e.g., RDS)가 인터넷 연결이 필요한 상황

• private subnet 내부에서 조건적으로 외부와 통신할 수 있는 방법?
  • NAT Gateway
  • Bastion Host

✅ NAT Gateway

• public subnet 내에 NAT Gateway 설정
• private subnet이 외부 라우팅이 필요할 때, NAT Gateway를 거치도록 라우팅테이블 설정
• Private Subnet의 AWS 리소스 → Public Subnet의 NAT Gateway → IGW → 외부 연결
• 특정 AZ에서 생성, Elasic IP 사용(: 고정 public ip)
• 여러 개의 AZ에 생성해 내결함성(fault torelance) 강화 가능: 다중 NAT Gateway

✅ Bastion Host

• Public Subnet에 위치해 외부에서 Private Subnet으로의 통신을 도와주는 대리인(Public Subnet 내부의 EC2 Instance)

• Bastion Host 설정

  1. Bastion Host Security Group Bastion Host의 보안 그룹은 제한된 CIDR(외부)로부터 Private Subnet으로의 접근을 허용해야 함.

  2. EC2 instance Security Group private subnet의 instance의 보안 그룹은 Bastion Host의 보안 그룹 혹은 Bastion Host의 개인 ip에 대해 SSH 연결을 허용해야 함.

✅ Security Group(보안 그룹)

• 인스턴스 단위로 적용할 수 있는 네트워크 보안 기술
• 인스턴스 inbound, outbound 트래픽 허용(Allow) 규칙 모음집
• 기본 설정 → 모든 허용 차단

✅ NACL(Network ACL)

• Subnet을 오고가는 모든 트래픽에 대해 허용(allow)하거나 거부(deny)
• 기본 NACL(Default NACL) → 모든 요청 허용
• 직접 NACL 설정 → inbound, outbound 요청 모두 거부된 상태로 설정
• 우선순위
  • 규칙마다 숫자(1~32766) 부여하여 우선순위 지정
  • 숫자가 낮을수록 우선순위 높음
  • 보통 100단위로 설정

네트워크ACL과 보안그룹이 충돌 → *보안그룹이 우선**

✅ VPC Peering

: Private IPv4/v6 주소를 사용해 두 VPC 간 트래픽을 라우팅 → 두 VPC 간 통신을 가능하게 하는 서비스

• AWS 네트워크를 통해 연결되므로 안전
• VPC의 CIDR가 서로 겹치면 안됨
• VPC 피어링 관계는 전이되지 않음
• 피어링을 활성화하고 싶다면 VPC 서브넷의 라우팅 테이블도 통신이 가능하도록 업데이트 필요
• 서로 다른 계정, 서로 다른 리전에서도 가능

✅ VPC Endpoint

: VPC 내부 리소스가 외부 AWS 서비스와 통신할 때, 외부 인터넷을 거치지 않고 AWS 백본 네트워크를 통해 서비스에 도달할 수 있도록 지원하는 서비스 → Public IP 없어도 AWS 서비스 사용 가능

초록색 → public ip를 가진 인스턴스만 IGW를 통해 인터넷에 연결되어 AWS 서비스 사용 가능 파란색 → public ip가 없는 인스턴스도 VPC Endpoint를 통해 AWS 서비스 사용 가능

-1. 정리

Route53: AWS의 DNS 서비스 AWS 구조 - 리전, AZ VPC

• Subnet
• Internet Gateway
• Routing Table
• NAT Gateway & Bastion Host
• Security Group & NACL
• VPC Peering
• VPC Endpoint

개념 까먹었을 땐 -> medium.com/harrythegreat

xoft.tistory.com를 참고하여 Diffusion model 이해에 필요한 기본 개념을 정리했다.

목차

Probability vs. Likelihood MLE(Maximum Likelyhood Estimation) Markov Process(MP)(=Markov Chain) Baysian Rule KL Divergence VAE CLIP SDS Diffusion

Probability vs. Likelihood

Probability

확률분포 $p(x)$가 고정된 상태에서 관측 사건 $x$가 변화할 때의 확률.

일상적으로 쓰이는 확률의 의미. "어떤 일이 일어날 가능성"

Likelihood

관측된 데이터 $x$가 고정된 상태에서, 이를 설명할 수 있는 확률분포 $p_θ(x)$가 변화할 때의 값. 주어진 데이터 ${x_1, x_2, ..., x_n}$가 특정 확률분포 $p_θ(x)$에서 생성되었을 가능성 주어진 데이터가 특정 확률분포를 따를 가능성

Likelihood가 크다는 것은, 관측된 데이터가 해당 확률분포로부터 생성되었을 가능성이 크다는 것.

관측된 데이터를 잘 설명하는 확률분포를 찾는 MLE에서 쓰인다.

이산 Likelihood

$$ L(θ; x) = P(x | θ) = ∏_{i=1}^n p_θ(x_i) $$

$p_{\theta}$: PMF(확률질량함수), $\theta$: 확률분포, x: 관측값

연속 Likelihood

$$ L(θ; x) = P(x | θ) = ∏_{i=1}^n f_θ(x_i) $$

$f_{\theta}$: PDF(확률밀도함수)

log likelihood

log는 증가함수이므로, 최대 최소를 구할 때 log likelihood를 써도 상관없다.

$$ ℓ(θ; x) = log L(θ; x) = ∑_{i=1}^n log p_θ(x_i) $$

$$ ℓ(θ; x) = log L(θ; x) = ∑_{i=1}^n log f_θ(x_i) $$

Probability는 사건 x의 확률을 계산하며, Likelihood는 특정 사건이 관측되었을 때 해당 사건을 잘 설명할 수 있는 확률분포를 찾는 데 사용됨.

MLE(Maximum Likelyhood Estimation)

(gmm - em algorithm에서 봤던 개념) 관측된 데이터를 가장 잘 설명하는 확률분포의 파라미터를 추정하는 방법.

주어진 데이터 ${x₁, x₂, ..., xₙ}$에 대해, 확률분포 $p_θ(x)$의 Likelihood를 최대화하는 $θ$를 찾음.

$$ \hat{\theta} = \arg\max_{\theta} \prod_{i=1}^n p_\theta(x_i) = \arg\max_{\theta} \sum_{i=1}^n \log p_\theta(x_i) $$

Gaussian Distribution MLE

Gaussian Distribution의 log likelihood를 각각 $μ$, $σ$에 대해 미분하고, 0이 되는 지점을 찾는다.

• 가우시안 분포 파라미터: 평균 $μ$, 표준편차 $σ$

• 가우시안 분포 확률분포함수

$$ p(x | \mu, \sigma) = \frac{1}{\sigma \sqrt{2\pi}} \exp\left(-\frac{(x - \mu)^2}{2\sigma^2}\right) $$

• log likelihood

  $$ \ell(\mu, \sigma; x) = -\frac{n}{2} \log(2\pi) - n \log(\sigma) - \frac{1}{2\sigma^2} \sum_{i=1}^n (x_i - \mu)^2 $$

평균 $μ$의 MLE: 데이터의 평균

$$ \hat{\mu} = \frac{1}{n} \sum_{i=1}^n x_i= \frac{x_1 + x_2 + \dots + x_n}{n} $$ 표준편차 $σ$ 의 MLE: 데이터의 표준편차

$$ \hat{\sigma} = \sqrt{\frac{1}{n} \sum_{i=1}^n (x_i - \hat{\mu})^2}= \sqrt{\frac{(x_1 - {\mu})^2 + (x_2 - \hat{\mu})^2 + \dots + (x_n - \hat{\mu})^2}{n}}

$$

Markov Process(MP)(=Markov Chain)

Markov Property를 갖는 discrete time stochastic process.

• Markov Property: 현재 상태가 오직 바로 이전(n-1) 상태에 의해서만 결정됨.

$$ P(X_t | X_{t-1}, X_{t-2}, \dots, X_0) = P(X_t | X_{t-1}) $$

• discrete time: 시간이 이산적으로 표현됨(t=n, n-1, n-2, …)

• stochastic process: 시간에 따라 어떤 사건이 발생할 확률이 변화하는 과정; 시간에 따라 상태가 확률적으로 변화

Baysian Rule

조건부 확률을 계산하는 공식으로, 관측된 데이터 $D$를 기반으로 모델 $H$의 사후 확률을 계산함.

$$ P(H | D) = \frac{P(D | H) P(H)}{P(D)} $$

• $P(H|D)$: 관측된 데이터를 기반으로 $H$가 참일 확률 (사후 확률).
• $P(D|H)$: $H$가 참일 때 데이터를 관측할 확률 (Likelihood).
• $P(H)$: 사전 확률.
• $P(D)$: 관측된 데이터를 기반으로 한 전체 확률.

KL Divergence

두 확률분포 $p$와 $q$ 간의 차이를 측정하는 지표.

분포 $p$가 $q$에 비해 얼마나 "다르게" 분포되어 있는지를 나타내는 척도.

정보량의 차이를 수치화하며, Loss 함수로 자주 사용됨.

Diffusion model에서 Forward process와 Reverse process의 분포 차이를 줄이는 데 활용됨.

공식

이산 확률 분포

$$ D_{\text{KL}}(p || q) = \sum_{x} p(x) \log \frac{p(x)}{q(x)} $$

연속 확률 분포
$$ D_{\text{KL}}(p || q) = \int p(x) \log \frac{p(x)}{q(x)} dx $$

특징

$D_{KL}(p || q) ≥ 0$.

$D_{KL}(p || q) ≠ D_{KL}(q || p$ (거리개념이 아님).

분포 $p$와 $q$가 동일하면 $D_{KL}(p || q) = 0$.

엔트로피

엔트로피는 확률 분포가 가지는 "불확실성"의 양을 나타내며, KL Divergence는 두 분포의 엔트로피 차이를 측정하는 방식.

$$ D_{KL}(p \parallel q) = H(p, q) - H(p)

$$

• $H(p)$: 분포$p$의 엔트로피(정보량)
• $H(p, q)$: 분포 $p$와 $q$가 함께 발생할 때의 합동 엔트로피($p$와 $q$가 동시에 발생할 때 얻을 수 있는 정보량) 이때 정보량이란 질문의 정보량!

VAE

Variational Auto Encoder

Autoencoder 기반의 모델로, 특정 데이터의 잠재 공간(latent space)을 확률분포로 학습.

데이터를 단일 점으로 학습하는 기존 Autoencoder와 달리, 잠재 변수를 확률분포 $z ~ p(z)$로 모델링.

$$ \mathcal{L} = \mathbb{E}{q(z|x)}[\log p(x|z)] - D{\text{KL}}(q(z|x) || p(z)) $$

• 첫 번째 항: reconstruction loss
• 두 번째 항: 잠재 분포 $q(z|x)$와 $p(z)$ 간의 KL Divergence.

CLIP

Contrastive Language-Image Pretraining

OpenAI에서 2021년 개발한 텍스트와 이미지를 연결하는 모델

텍스트와 이미지 데이터를 동일한 잠재 공간(shared latent space)에 매핑하여 서로 간의 관련성을 학습함.

Contrastive Learning

입력 샘플 간의 비교를 통해 학습을 하는 것

입력 쌍(positive, negative)을 비교하여 학습.

관련 있는 쌍은 가까이, 관련 없는 쌍은 멀리 배치.

SDS

Score Distillation Sampling

DreamFusion에서 Text-to-3D 모델 학습에 처음 제안된 Loss 방식.

이미지-텍스트 모델(CLIP)을 활용하여 텍스트 조건에 맞는 3D 생성 모델을 학습.

Diffusion

Forward process

데이터를 점점 노이즈로 변환하는 과정. 데이터 $x₀$에서 시작하여 시간 $t$에 따라 점진적으로 노이즈를 추가:

$$ q(x_t | x_{t-1}) = \mathcal{N}(x_t; \sqrt{\alpha_t} x_{t-1}, (1 - \alpha_t)I) $$

Reverse process

노이즈 데이터를 점진적으로 복원하는 과정. 학습 대상 분포는 $p_θ(x_{t-1} | x_t)$.

$$ \mathcal{L} = D_{\text{KL}}(q(x_{t-1}|x_t) || p_\theta(x_{t-1}|x_t)) $$

Forward process에서 관찰된 데이터로 Reverse process 분포를 학습하여 MLE를 최대화.

학습 대상: $P_{\theta}(X_{t-1}|X_{t})$; 확률분포 $q$에서 관측한 값으로 확률분포 $p_\theta$의 likelihood를 구했을 때 MLE.

Spring Security Authentication & Authorization Spring Filter Spring Security Architecture 기타 특징

Spring Security

인증, 권한 부여, 보호 기능을 제공하는 프레임워크.

Spring Security is a framework that provides authentication, authorization, and protection against common attacks. docs.spring.io

Authentication & Authorization

Authentication is how we verify the identity of who is trying to access a particular resource. docs.spring.io Authorization is determining who is allowed to access a particular resource. docs.spring.io

Authentication(인증)

리소스에 접근하려는 사용자의 신원을 증명하는 것.

Authorization(권한 부여)

리소스에 대한 사용자의 접근 권한을 확인하는 것.

geeksforgeeks.org

Spring Filter

Spring Security’s Servlet support is based on Servlet Filters docs.spring.io

Servlet

Java 기반의 웹 애플리케이션에서 클라이언트의 요청을 처리하고, 그에 대한 응답을 생성하는 서버 측 프로그램. 스프링 MVC에서 Servlet이란 DispatcherServlet의 인스턴스.

Servlet Filter

Servlet 요청 및 응답을 가로채고 처리하는 기능을 한다. 요청이 서블릿에 도달하기 전에, 또는 서블릿에서 응답이 클라이언트로 전달되기 전에 특정 로직을 실행한다.

Filter vs Interceptor

Filter	Interceptor
DispatcherServlet 전/후 로직 처리	Dispatcher Servlet이 Controller를 호출하기 전/후에
웹 컨테이너(Web Container)가 관리	스프링 컨테이너(Spring Container)가 관리
스프링 외부 기술	스프링 내부 기술
mangkyu.tistory.com

Spring Security 아키텍처

FilterChain

클라이언트가 애플리케이션에서 요청을 받으면 웹 컨테이너는 FilterChain를 생성한다. FilterChain는 여러개의 Filter와 단일 Servlet 인스턴스로 구성된다. 필터의 순서는 보안 로직 처리에 영향을 미치므로 매우 중요하다.

DelegatingFilterProxy

Spring provides a Filter implementation named DelegatingFilterProxy that allows bridging between the Servlet container’s lifecycle and Spring’s ApplicationContext. docs.spring.io

스프링은 Filter의 구현체인 DelegatingFilterProxy를 제공한다. 이는 Servlet Container와 Spring의 IOC Container를 연결해주는 다리 역할을 하는 필터이다. Servlet Container는 Spring Bean을 직접 사용할 수 없으므로, DelegatingFilterProxy가 Spring Bean에게 작업을 위임한다. 즉, DelegatingFilterProxy는 보안 작업을 수행하지 않고, Spring 컨테이너에 작업을 위임하는 역할만 하는 Servlet Filter이다.

FilterChainProxy

Spring Security에서 제공하는 특별한 Filter로, 이를 통해 여러 Filter 인스턴스를 SecurityFilterChain을 통해 관리할 수 있다. DelegatingFilterProxy로 감싸져 있으며, 요청을 적합한 SecurityFilterChain으로 위임한다. SecurityFilterChain의 URL 패턴이 겹칠 경우, 가장 먼저 매칭되는 필터 체인만 호출된다.

SecurityFilterChain

• SecurityFilterChain은 FilterChainProxy가 현재 요청에 대해 호출해야 할 Spring Security Filter 인스턴스를 결정하는 데 사용된다.
• SecurityFilterChain 내부의 Security Filter들은 일반적으로 Bean이지만, DelegatingFilterProxy가 아닌 FilterChainProxy에 등록된다. FilterChainProxy를 사용하는 것은 직접 Servlet 컨테이너나 DelegatingFilterProxy에 등록하는 것과 비교하여 다음과 같은 여러 가지 이점을 제공한다.
  1. Spring Security Servlet 지원의 시작점 제공
  2. 중앙 집중화된 필터 관리
  3. 유연한 필터 체인 호출 조건
• 여러개의 SecurityFilterChain 인스턴스 URL과 매치되는 첫번째 SecurityFilterChain만 호출된다. 따라서, 필터 체인의 선언 순서가 매우 중요하다. 각 SecurityFilterChain은 독립적이며, 여러개 또는 0개의 Filter 인스턴스를 가질 수 있다. (0개의 경우 특정 요청을 무시할 때 사용된다.)

Security Filters

Security Filter는 SecurityFilterChain API와 함께 FilterChainProxy에 삽입된다. Security Filter는 일반적으로 HttpSecurity 인스턴스를 이용하여 선언된다.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(Customizer.withDefaults())
            .httpBasic(Customizer.withDefaults())
            .formLogin(Customizer.withDefaults())
            .authorizeHttpRequests(authorize -> authorize
                .anyRequest().authenticated()
            );

        return http.build();
    }

}

위의 Configuration은 다음과 같은 순서의 Filter를 설정한다. CsrfFilter(.csrf) > UsernamePasswordAuthenticationFilter(.formLogin) > BasicAuthenticationFilter(.httpBasic) > AuthorizationFilter(.authorizeHttpRequests) 이렇게 특정 순서로 수행되며, 순서는 github에서 확인할 수 있다.

기타 특징

1. Spring MVC와 독립적인 관리
   REST API에서 JWT 또는 OAuth 2.0을 활용해 스프링 MVC와 독립적으로 동작.

2. Java Config 기반 설정
   @EnableWebSecurity를 통해 보안 설정을 활성화. 주로 SecurityFilterChain과 AuthenticationManager를 활용.

3. 어노테이션 지원
   Spring Security 3.2 이후로 XML 설정 없이 어노테이션으로 간단히 설정 가능. @PreAuthorize, @PostAuthorize

4. 기본 인증 방식

   • 기본적으로 세션과 쿠키 기반 인증.
   • REST API에서는 토큰 기반 인증 방식(OAuth 2.0, JWT) 권장.

참고자료

velog.io/@eileen0379 docs.spring.io

GDG on Campus Backend-Spring 스터디 WIL Week 08 - 스프링 시큐리티 및 OAuth2 통합

Spring Security 기초

velog.io/@jiu-jung

Access Control

RBAC(Role Based Access Control, 역할 기반 접근 제어)

정보에 대한 접근 권한을 역할에 따라 결정.

장점

• 보안 강화 & 데이터 보호
• 그룹화 통해 권한 관리 간소화
• 다수의 사람에 대해 유연하고 직관적이며 효율적인 통제 가능

  기본 규칙

• Role Assignment (역할 할당)
• Role Authorization (역할 기반 권한 부여)
• Permission Authorization (권한 승인)

구현 예시

geeksforgeeks.org

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
                .authorizeRequests()
                .requestMatchers("/admin/**").hasRole("ADMIN")
                .requestMatchers("/user/**").hasRole( "USER")
                .anyRequest().authenticated()
                .and()
                .formLogin()
               // Specify the URL for the registration page

                .and()
                .logout().logoutSuccessUrl("/").permitAll();

        return http.build();
    }

}

@Configuration
public class UserDetailsConfig {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public UserDetailsManager userDetailsManager() {
        InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
        manager.createUser(
                User.withUsername("admin")
                        .password(passwordEncoder().encode("admin"))
                        .roles("ADMIN")
                        .build()
        );
        manager.createUser(
                User.withUsername("user")
                        .password(passwordEncoder().encode("user"))
                        .roles("USER")
                        .build()
        );
        return manager;
    }
}

메소드 수준 보안 (Method-Level Security)

RBAC를 서비스 계층으로 확장한 방식.

• @Configuration 클래스에서 @EnableMethodSecurity 활성화 필요

  @Configuration
  @EnableMethodSecurity
  public class SecurityConfig { 
      // Other security configurations here 
  }

• @PreAuthorize : 메소드 실행 전 권한 체크

  @PreAuthorize("hasRole('ROLE_ADMIN') or (hasRole('ROLE_USER') and #userId == principal.userId)") 
  public void updateUser(int userId) { 
  // Method logic here 
  }

• @PostAuthorize : 메소드 실행 후 반환값에 따라 접근 제어

• @Secured : 특정 역할 기반으로 접근 제어

  @Secured("ROLE_ADMIN") 
  public void deleteUser(int userId) { 
  // Method logic here 
  }

ACL(Access Control List, 액세스 제어 목록)

개별 리소스에 대한 접근을 세분화하여 정의 및 관리

장점

• 리소스 단위 권환 관리 -> 리소스(도메인 객체)에 사용자/그룹별 권한 부여
• hasPermission()을 통해 접근성 관리 DB화
• Spring security는 spring-security-acl 라이브러리 제공)

단점

• 도메인 객체가 갖는 접근성에 대한 정보 활용 X -> ACL 테이블 별도로 관리
• 사용자/도메인 객체가 많아지면 접근 권한에 대한 경우의 수가 기하급수적으로 증가
• 기술 난이도가 높아 유지보수 어려움

기본 구조

• Sid(Security Identity) - 사용자/그룹
• Permission - 객체에 대한 권한
• Domain Object - 보호할 객체

ACL 도메인 모델

ACL_CLASS : 도메인 객체의 종류 ACL_SID : 권한의 주체가 되는 사용자 정보 & Role 정보 ACL_OBJECT_IDENTITY : 보안의 대상이 되는 정보 객체 ACL_ENTRY : 접근 권한 정보

OAuth 2.0 (Open Authorization)

docs.spring.io

인터넷 사용자가 애플리케이션에 직접 비밀번호를 제공하지 않고, 권한을 위임하여 리소스에 접근하도록 하는 프로토콜

• 개방형 표준 프로토콜로, third-party 프로그램에게 리소스 소유자를 대신해 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식으로 작동
• third-party 프로그램(구글, 카카오 등)에게 로그인 및 개인정보 관리에 대한 권한을 위임하여 third-party 프로그램이 가지고 있는 사용자에 대한 리소스 조회 가능

주요 구성 요소

• Resource Owner(리소스 소유자) : 보호된 자원에 접근할 수 있는 자격을 부여해주는 객체. OAuth 2.0 프로토콜 흐름에서 클라이언트 인증하는 역할 수행
• Client(애플리케이션) : 보호된 자원을 사용하기 위해 접근을 요청하는 애플리케이션
• Authentication Server : 사용자의 보호된 자원을 호스팅하는 서버
• Resource Server : Authentication Server로 인증/인가 수행. Client의 접근 자격을 확인하고 Access Token을 발급하여 권한을 부여한다.

인증 방식

Authorization Code Grant

기본이 되는 방식 간편 로그인에서 많이 사용 권한 부여 승인을 위해 자체 생성한 Authorization Code 를 전달하는 방식으로 많이 쓰임

Implicit Grant

자격증명을 안전하게 저장하기 힘든 클라이언트(ex. 자바스크립트 등의 스크립트언어 없이 사용한 브라우저)에게 최적화된 방식 권한 부여 승인 코드 없이 바로 Access Token 발급 응답성과 효율성은 높아지지만 Access Token이 URL로 전달된다는 단점 존재

Resource Owner Password Credential Grant(자원 소유자 자격증명 승인 방식)

username, password로 Access_Token을 받는 방식 권한서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 있을 때 사용

Client Credential Grant(클라이언트 자격증명 승인 방식)

클라이언트의 자격증명만으로 Access Token 획득하는 가장 간단한 방식 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용

Spring Security & Oauth 2.0 통합

1. `application.property``파일에 Oauth2.0 클라이언트 설정 추가
2. build.gradle에 의존성 추가
3. SecurityConfig 클래스에서 리소스 서버의 보안 구성 정의

장점

• 복잡한 인증 및 인가 요구사항을 효과적으로 관리 가능
• OAuth 2.0 -> 사용자 데이터에 대한 안전한 접근 권한 부여 가능
• Spring Security -> 프로세스를 간소화하여 구현할 수 있는 풍부한 기능 제공
• 개발자는 보안이 강화된 애플리케이션을 쉽고 빠르게 구축 가능

참고자료

velog.io/@eileen0379 techdocs.broadcom.com

스프링 GCP 배포 온라인 도서 관리 프로그램을 Google Cloud Platform로 배포해보자.

배경지식

GCP

Google에서 개발한 클라우드 컴퓨팅 플랫폼. 사용자가 클라우드 환경에서 애플리케이션을 개발, 배포 및 관리할 수 있도록 돕는 플랫폼.

VM 인스턴스

Google 인프라에서 호스팅되는 가상 머신(VM) (Compute Engine 인스턴스, 가상 머신 인스턴스 , VM 인스턴스, VM은 모두 같은 동의어) cloud.google.com

GCP의 VM 인스턴스를 생성한 후, 로컬 컴퓨터와 연결할 것이다.

SSH(Secure Shell Protocol)

네트워크 프로토콜로, 안전한 통신을 위해 암호화를 사용하여 데이터와 명령을 전송 이 프로토콜은 RSA 보안 방식을 기반으로 하며, 공개 키(Public Key)와 개인 키(Private Key)를 활용하여 인증과 보안을 유지한다.

로컬 pc에서 Public Key를 생성하고 이를 GCP에 등록하여, 로컬 pc와 GCP의 VM 인스턴스 간 연결을 설정할 것이다.

스프링 GCP 배포 개요

1. GCP 준비
2. VM 인스턴스 생성 및 설정
3. 고정 IP 및 방화벽 설정
4. SSH key 생성 및 등록
5. 로컬 pc에서 원격 VM 연결
6. 배포

1. GCP 준비

Google Cloud 가입 및 새 프로젝트 생성

1. Google Cloud 가입 https://cloud.google.com

2. 새 프로젝트 생성

2. VM 인스턴스 생성 및 설정

VM 인스턴스 생성

1. 생성한 프로젝트로 진입하기.

2. Computer Engine > VM 인스턴스 > 인스턴스 만들기

3. 머신 구성 설정

   이름: 원하는 이름 (ex. instance) 리전: 지역 (ex. 서울) 머신 유형: e2-micro (용도에 맞게)

4. OS 및 스토리지 설정

   운영체제: Ubuntu

5. 네트워킹 설정

   방화벽: HTTP 트래킹 허용, HTTP 트래킹 허용

6. 보안 설정

   액세스 범위: 모든 Cloud API에 대한 전체 액세스 허용

7. 생성된 VM 인스턴스 확인 외부 IP는 배포에 쓰이므로 메모해둔다.

VM 인스턴스 생성 완료!

VM 인스턴스 설정

1. VM 인스턴스 > SSH
2. root 계정 설정 및 Java 환경 설치 Spring 프로젝트의 java 버전에 맞는 Java 환경 설치

   sudo passwd
   sudo su
   sudo apt update
   sudo apt-get install openjdk-21-jre
   sudo apt-get install openjdk-21-jdk
   java --version

3. 고정 IP 및 방화벽 설정

고정 IP 설정

인스턴스가 재시작돼도 동일한 ip로 접속할 수 있도록 고정 IP를 설정하자.

1. VPC 네트워크 > IP 주소 > 외부 고정 IP 주소 예약

2. 고정 주소 예약

   이름: 원하는 이름 (ex. static-ip) 네트워크 서비스 계층: 표준 연결대상: 이전에 생성한 VM 인스턴스 선택

3. 생성된 외부 고정 IP 확인

고정 IP 설정 완료!

방화벽 규칙 생성

spring boot의 기본 포트인 8080포트를 열어주기 위해 방화벽 규칙을 생성하자.

1. VPC 네트워크 > 방화벽 > 방화벽 규칙 만들기

2. 방화벽 규칙 만들기

   이름: 원하는 이름 (ex. springboot-8080) 소스 IPv4 범위: 0.0.0.0/0 프로토콜 및 포트: TCP 포트 8080

   모든 IP주소에서 오는, TCP 프로토콜을 사용하고 목적지 포트 번호가 8080인 트래픽을 허용한다는 의미이다.

3. 생성된 방화벽 규칙 확인

방화벽 규칙 생성 완료!

4. SSH key 생성 및 등록

로컬 PC에서 SSH Key 생성

로컬 pc에서 VM 인스턴스에 접근하기 위해 로컬 pc에서 SSH key를 생성하자.

1. Windows Powershell 관리자 모드로 실행

2. 사용자 계정으로 이동

   PS C:\WINDOWS\system32> cd ..
   PS C:\WINDOWS> cd ..
   PS C:\> cd Users
   PS C:\Users> cd [username]

   3. .ssh 폴더 생성

      PS C:\Users\[username]> mkdir .ssh
      PS C:\Users\[username]> cd .ssh

3. SSH key 생성

    PS C:\Users\[username]\.ssh> ssh-keygen -t rsa -f [key name] -C [GCP account]
    예) PS C:\Users\[username]\.ssh> ssh-keygen -t rsa -f gcp_key -C abcd@gmail.com    

4. 생성된 public key 확인

   PS C:\Users\[username]\.ssh> type [key name].pub

   생성된 public key가 출력된다. 출력된 값은 다음 단계에서 필요하니 메모해둔다.

GCP Console에서 SSH Key 등록

1. Compute Engine > 메타데이터 > 수정 > SSH 키

2. 로컬 pc에서 생성한 SSH public key 입력

3. 로컬 pc Windows powershell에서 등록 확인

   ssh -i /Users/[user name]/.ssh/[key name] [GCP 계정 앞부분]@[VM 외부 IP]
   예)
   ssh -i /Users/[user name]/.ssh/[key name] abcd@10.20.30.40

   

5. 로컬 pc에서 원격 VM 연결

VSCode를 통한 SSH 연결

1. VS Code에서 확장프로그램 Remote - SSH 설치

2. Remote Explorer 아이콘 > + 버튼 좌측 패널에 생성된 Remote Explorer 아이콘 클릭 (생성되지 않으면 우클릭해서 선택)

3. ssh [GCP 계정 앞부분]@[VM 외부 ip] 입력 후 엔터

4. config 파일 열기

5. config 파일 수정

   Host: 원하는 이름 HostName: VM 외부 IP User: GCP 계정 앞부분 IdentityFile: 키 파일 경로

6. Remote Explorer > SSH > VM 외부 IP > Connect > SSH key 비밀번호 입력

7. 연결 확인 터미널을 열어서 VM 인스턴스에 연결되면 연결 성공

6. 배포

.jar 생성 및 이동

1. IntelliJ > 우측 패널 gradle 로고 > 프로젝트명 > Tasks > build > bootJar 프로젝트 폴더 build > libs 경로에 .jar 파일 생성 확인

2. VSCode > (SSH 연결 후) > EXPLORER > Open Folder

3. .jar 파일 이동

Spring boot 실행

1. VS code 터미널에서 스프링 실행

   nohup java -jar [파일명].jar

   Java로 작성된 애플리케이션을 실행하면서 터미널 세션 종료와 무관하게 계속 실행되도록 설정하는 명령어. 표준 출력과 표준 에러 출력이 nohup.out 파일에 저장된다.

   

2. 실행 확인 nohup.out을 열면 스프링 부트가 실행된 것을 확인할 수 있다.

서비스 확인

브라우저에서 http://[VM외부IP주소]:8080 으로 접속

배포 완료!

참고자료

developerkkyu37.tistory.com developerkkyu37.tistory.com velog.io/@hyeri_hello velog.io/@hyeri_hello velog.io/@chaejm55

GDG on Campus Backend-Spring 스터디 WIL Week 07 - JPA 및 Hibernate를 사용한 ORM 통합

ORM(Object-Relational Mapping) 이란?

객체 지향 프로그래밍에서, 객체와 관계형 데이터베이스의 테이블 간 데이터를 자동으로 매핑하는 기술

JPA(Java Persistence API) 란?

• 자바 표준 ORM 명세로, 애플리케이션과 데이터베이스 간 데이터 처리 로직을 추상화.
• 자바의 ORM(Object-Relational Mapping) 기술 표준으로 사용되는 인터페이스의 모음.
• SQL 중심적인 개발 -> 객체 중심적인 개발
  • 생산성 증가 : 반복적인 SQL 작성에서 벗어나 객체 중심으로 개발
  • 유지보수 수월 : 데이터베이스 변경에 따른 영향 최소화
  • Object와 RDB간의 패러다임 불일치 해결 : 객체와 관계형 데이터베이스 간의 구조적 차이를 매핑으로 해결

Hibernate 란?

• 자바 진영의 다양한 ORM 프레임워크 중 가장 많이 사용되는 프레임워크
• JPA(Java Persistence API) 표준의 구현체 중 하나로, JPA의 명세를 따르면서도 자체적인 추가 기능을 제공
  • ORM 기능 : 객체와 관계형 데이터베이스 간의 매핑
  • JDBC 추상화 : 데이터베이스 연결과 명령 처리를 간소화.
  • JPQL(Java Persistence Query Language), 네이티브 SQL, Querydsl 등 다양한 쿼리 언어 지원
  • 캐싱 기능 : 1차 및 2차 캐싱으로 성능 최적화
  • 데이터베이스 독립성
• SessionFactory를 사용해서 session을 만들어 DB와 커뮤니케이션

Hibernate 사용 방법

1. 엔티티 클래스 작성
2. entity manager 작성
3. crud 작업 수행

2차 캐싱

• 영속성 컨텍스트의 1차 캐싱을 넘어, 애플리케이션 전체에서 데이터를 캐싱하여 성능 최적화하는 방식
• 1차 캐싱(영속성 컨텍스트 내 캐싱)이 개별 세션에 국한된 반면, 2차 캐싱은 애플리케이션 전역에서 공유됨

지연 로딩 (<-> 즉시 로딩)

• 필요한 시점에 데이터를 로딩하는 방식
• 동작 원리
  • 엔티티를 조회할 때, 연관된 데이터를 프록시(Proxy) 객체로 대신 설정
  • 연관(JOIN)된 데이터에 접근하면 Hibernate가 데이터베이스에서 필요한 데이터를 실시간으로 조회

Batch Fetching 전략

• JPA에서 지연 로딩(Lazy Loading)으로 인해 발생하는 N+1 문제를 해결하기 위한 전략

  • N+1 문제: 하나의 엔티티를 조회한 후 연관된 데이터를 개별적으로 가져오면서 N번의 추가 쿼리가 발생하는 문제 예) 부모 엔티티 1개를 조회한 후 자식 엔티티를 10개 조회하면, 총 1 + 10 = 11개의 쿼리가 발생

• 동작 원리

  • 연관된 데이터를 개별적으로 조회하는 지연로딩과 달리,
  • 연관된 데이터의 ID를 모아서 한 번에 조회하여 쿼리 호출 횟수를 줄인다

JPA vs Hibernate vs Spring Data JPA

lealea.tistory.com

JPA: 객체-관계 매핑(ORM)을 위한 표준 명세인 인터페이스 Hibernate: JPA의 구현체. JPA의 다른 구현체도 존재 Spring Data JPA: JPA 기반 애플리케이션 개발을 보다 간편하게 만드는 라이브러리/프레임워크

Spring Data JPA로 구현하면 로그에 Hibernate 구동이 뜬다. 이는 Spring Data JPA는 내부적으로 Hibernate를 이용하기 때문이다!

참고자료

codingbyjhyunn.tistory.com

LGM: Large Multi-View Gaussian Model for High-Resolution 3D Content Creation

Project page Github Paper Demo

Colab으로 LGM 실행하기 Colab 링크

서론

우리팀은 연구 주제로 Single view 3D reconstruction을 잡았다. 현재 어떤 연구들이 있는지 찾아보고 직접 돌려보며 개선점을 파악했다. 먼저 DreamGaussian과 One-2-3-45를 돌려봤다. DreamGaussian은 3DGS 기반이고, One-2-3-45은 NeRF 기반이다. 결과적으로 3DGS 기반이 성능도 더 좋았고, 시간과 리소스 측면에서도 효율적임을 발견했다. 이후 3DGS 기반 모델을 찾아보다가, LGM이라는 논문을 발견했다. LGM을 돌렸을 때, DreamGaussian에서는 이상했던 형태가 엄청나게 개선되어서 놀랐다. 그리고 texture와 geometry 측면에서 개선할 점을 발견했다. 자세한 설명은 실행 파트에서 설명하겠다.

논문 리뷰

간단하게만 LGM 논문을 정리하겠다.

Pipeline

Image Input의 경우)

1. Single image 를 입력받아서, ImageDream을 통해 multi-view(4가지 카메라 위치) images를 생성한다.
2. Large Multi-View Gaussian Model을 통해 3D Gaussian을 생성한다
3. Mesh Extraction

Architecture

Assymetric U-Net

• Input 생성된 multi-view image들과 카메라 위치(Camera Ray Embeddings)
• Output 4개의 feature map(Multi-view Gaussian Features)

Fusing

Assymetric U-Net의 output인 각 feature map은 Gaussian의 집합으로 transform된다.이 Gaussian들이 합쳐져 최종 3D Gaussian이 생성된다.

Mesh Extraction Pipeline

3D Gaussian -> Instant-NGP -> NeRF -> NeRF2Mesh -> Mesh

실행

github.com/3DTopia/LGM github.com/camenduru/LGM-jupyter

위 깃허브 코드들을 참고해서 코랩을 만들어서 돌려봤다. -> Colab 링크

* 구글 드라이브 마운트 후 LGM/data_test에 입력 이미지 업로드(배경 제거 후 .png 형식) * Xformer 페이지에 들어가서 버전 확인 후 torch와 cuda 버전 확인

Trouble Shooting

1. Xformer 설치 !pip install ./diff-gaussian-rasterization 에서 오류가 계속 발생했다. torch, cuda, xformer등의 버전이 맞지 않아서 생긴 오류였다. github 페이지대로 torch 버전을 설치하면, xformer가 제대로 설치되지 않는 것 같았다. 그래서 xformer 페이지에 들어가서 버전을 확인하고 재설치 후 해결됐다.

2. pretrained weights 다운로드 깃헙 페이지대로 실행하면 저장한 pretrained 이름이 달라서 오류가 난다. 왜 model_fp16이 아닌 다른 파일명으로 해놨는지 이해가 안된다. 어쨌든 밑 코드를 보고 model_fp16_fixrot -> model_fp16로 수정해서 해결되었다.

3. gradio 이걸 40분을 기다렸다.. ^^ app.py의 마지막 코드에서 share=True로 바꿔야 public url이 생기고, 거기로 접속해서 gradio에서 실행하는거다… gradio를 몰랐던 내 잘못.. 코랩이 일을 안하는데 계속 실행되면 항상 점검해보자... gradio보다는 직접 test하는게 정확할테니 이 코드는 그냥 빼버렸다.

4. local gui Colab에서 위의 local gui는 되지 않았다. 코랩에서는 실행이 불가능한 코드라 뺐다. 대신 LGM/workspace_test에 저장되는 결과물을 다운받아서 확인하면 된다.

5. ** mesh conversion** github에 제공된 코드로는 실행이 되지 않고 계속 에러가 뜬다. github issue와 Github - LGM-jupyter를 참고해보니, --force_cuda_rast 옵션을 주면 해결된다.

실행 결과

여러 샘플을 입력했을 때, DreamGaussian보다 성능이 훨씬 좋았다. 지금부터 가장 차이가 컸던 샘플에 대한 DreamGaussian과 LGM의 결과를 비교해보겠다.

Input image

이 이케아 인형은 정면도 측면도 아닌 애매한 각도에서 찍어서 사실 제대로 reconstruction하기 어려울 것이다. 이 single image를 input으로 넣어서 돌려보았다.

DreamGaussian

.obj

Geometry

Vertex: 30,841, Edge: 84,652, Face: 53,958, Triangle: 53,958

내부에 불필요한 geometry가 존재한다.

강아지 형태가 전혀 아니다.

LGM

.ply

.obj

Texture

edge를 바탕으로 텍스쳐를 예측하는 것인지, 예측한 뒷면의 텍스쳐의 색이 너무 어두웠다.

Geometry

Vertex: 26,770, Edge: 73,519, Face: 46,924, Triangle: 46,924

내부에 불필요한 geometry가 있지만, DreamGaussian보단 적고 작다.

아래쪽에 hole이 있다.전체적으로 표면이 울퉁불퉁하다.

결과 분석

두 모델을 비교해서 정리해보면,

• LGM이 전체적인 형태를 훨씬 잘 예측했다.

• Geometry 측면에서는 LGM의 Vertex 수가 적었다.
• Texture 측면에서는 DreamGaussian이 잘 예측했다.

DreamGaussian과 LGM의 방식은 굉장히 다르다. 이 둘을 결합하여 장점만 가져올 수 있을지 궁금하다.

부록

귀여워서 huggingface demo로 돌려본 햄스터

demo로 하면 직접 돌렸을때보다 결과가 안좋긴 한데, 감안해도 말도 안되는 결과가 나왔다. 어이가 없다. 화질이 안좋아서 그런가...

특정 비즈니스 로직을 위한 사용자 정의 롤백 규칙을 가진 트랜잭션 관리 통합

지난주 과제에선 jpa를 써서 jdbc template을 쓰는 코드로 수정했다.

schema.sql

CREATE TABLE IF NOT EXISTS member (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(255) NOT NULL
);

jdbc는 jpa와 달리 자동으로 데이터베이스 설정을 해주지 않는다. resources폴더에 schema.sql 파일을 만들어준다.

TransactionConfig

package com.example.demo.config;


import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.jdbc.datasource.DataSourceTransactionManager;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.annotation.EnableTransactionManagement;

import javax.sql.DataSource;

@Configuration
@EnableTransactionManagement
public class TransactionConfig {

    @Bean
    public PlatformTransactionManager txManager(DataSource dataSource){
        return new DataSourceTransactionManager(dataSource);
    } // spring boot의 경우에는 자동으로 설정되어있어서 따로 설정 필요 없음.
}

@EnableTransactionManagement

Member

package com.example.demo.domain;

public class Member{
    private Long id;
    private String username;

    // Constructor
    // Getters and Setters
}

MemberRepository

package com.example.demo.repository;

import com.example.demo.domain.Member;

import java.util.List;
import java.util.Optional;

public interface MemberRepository{
    List<Member> findAll();
    Optional<Member> findById(Long id);
    Optional<Member> findByUsername(String username);
    void deleteById(Long id);
    void save(Member member);
}

//public interface MemberRepository extends JpaRepository<Member, Long> { }

MemberService

package com.example.demo.service;

import org.springframework.stereotype.Service;
import com.example.demo.domain.Member;
import com.example.demo.repository.MemberRepository;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;
import java.util.Optional;

@Service
public class MemberService {

    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    public List<Member> getAllMembers() {
        return memberRepository.findAll();
    }

    public Optional<Member> getMemberById(Long id) {
        return memberRepository.findById(id);
    }

    @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
    public Member join(Member member) {
        if ("error".equals(member.getUsername())) {
            throw new IllegalArgumentException("username == error");
        }
        memberRepository.save(member);
        return member;
    }

    public Optional<Member> update(Long id, Member updatedMember) {
        Optional<Member> memberOptional = getMemberById(id);
        memberOptional.ifPresent(member -> member.setUsername(updatedMember.getUsername()));
        return memberOptional;
    }


    public void deleteById(Long id) {
        getMemberById(id); // id 존재 여부 확인하면서 예외 처리
        memberRepository.deleteById(id);
    }
}

join() 메서드의 전파 속성은 REQUIRED로 설정한다. 테스트를 위해 username이 "error"이면 예외가 발생하게 한다.

MemberServiceRequiredNew

package com.example.demo.service;

import com.example.demo.domain.Member;
import com.example.demo.repository.MemberRepository;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;

@Service
public class MemberServiceRequiredNew {

    private final MemberRepository memberRepository;

    public MemberServiceRequiredNew(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void joinNew(Member member) {
        if ("error".equals(member.getUsername())) {
            throw new IllegalArgumentException("username == error");
        }
        memberRepository.save(member);
    }
}

전파 속성이 REQUIRES_NEW일 때를 테스트하기 위해 Service 클래스를 새로 만들어줬다.

MemberDao

package com.example.demo.repository;

import com.example.demo.domain.Member;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.dao.EmptyResultDataAccessException;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.core.RowMapper;
import org.springframework.stereotype.Repository;

import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.List;
import java.util.Optional;

class MemberRowMapper implements RowMapper<Member>{
    @Override
    public Member mapRow(ResultSet rs, int rowNum) throws SQLException{
        Member member = new Member();
        member.setId(rs.getLong("id"));
        member.setUsername(rs.getString("username"));

        return member;
    }
}

@Repository
public class MemberDao implements MemberRepository{
    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Override
    public List<Member> findAll() {
        String sql = "SELECT * FROM member";
        return jdbcTemplate.query(sql, new MemberRowMapper());
    }

    @Override
    public Optional<Member> findById(Long id) {
        String sql = "SELECT * FROM member WHERE id = ?";
        try {
            return Optional.ofNullable(jdbcTemplate.queryForObject(sql, new MemberRowMapper(), id));
        } catch (EmptyResultDataAccessException e) {
            return Optional.empty();
        }
    }

    @Override
    public Optional<Member> findByUsername(String username) {
        String sql = "SELECT * FROM member WHERE username = ?";
        try {
            return Optional.ofNullable(
                    jdbcTemplate.queryForObject(sql, new MemberRowMapper(), username)
            );
        } catch (EmptyResultDataAccessException e) {
            return Optional.empty(); // null 대신 Optional.empty() 반환
        }
    }


    @Override
    public void deleteById(Long id) {
        String sql = "DELETE FROM member WHERE id = ?";
        jdbcTemplate.update(sql, id);
    }

    @Override
    public void save(Member member) {
        String sql = "INSERT INTO member (username) VALUES (?)";
        try {
            jdbcTemplate.update(sql, member.getUsername());
        } catch (Exception e) {
            throw new RuntimeException("Failed to save member: " + member.getUsername(), e);
        }
    }

    public void clearDb(){
        String sql = "DELETE FROM member";
        jdbcTemplate.update(sql);
    }

}

RowMapper를 상속하여 데이터를 객체로 변환하는 클래스를 정의했다. JdbcTemplate을 이용하여 MemberRepository의 클래스를 구현했다.

테스트 코드

TestMemberData

package com.example.demo.service;

import com.example.demo.domain.Member;
import com.example.demo.repository.MemberDao;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Test;
import org.springframework.aop.support.AopUtils;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;

import static org.junit.jupiter.api.Assertions.assertTrue;


@SpringBootTest
public class TestMemberData {
    @Autowired
    private MemberService memberService;

    @Autowired
    private MemberServiceRequiredNew memberServiceRequiredNew;

    @Autowired
    private MemberDao memberRepository;

    @AfterEach
    public void afterEach(){
        memberRepository.clearDb();
    }

    @Test
    public void requiredTest() {
        // Given
        Member member1 = new Member("user1");
        Member member2 = new Member("error"); // 오류를 유발할 사용자

        try {
            // 트랜잭션이 시작된 상태에서 두 번의 join 호출
            memberService.join(member1); // 트랜잭션에 참여
            memberService.join(member2); // 예외 발생 → 전체 트랜잭션 롤백
        } catch (Exception e) {
            e.printStackTrace();
        }

        // Then
        // 트랜잭션 롤백 여부 확인
        boolean isUser1Present = memberRepository.findByUsername("user1").isPresent();
        boolean isErrorPresent = memberRepository.findByUsername("error").isPresent();
        System.out.println("MemberService is proxied: " + AopUtils.isAopProxy(memberService));

        System.out.println("User1 present after rollback: " + isUser1Present);
        System.out.println("Error present after rollback: " + isErrorPresent);

        assertTrue(memberRepository.findByUsername("user1").isEmpty(), "User1 should be rolled back");
        assertTrue(memberRepository.findByUsername("error").isEmpty(), "Error should be rolled back");
    }

    @Test
    public void requiredNewTest() {
        // Given
        Member member1 = new Member();
        member1.setUsername("user2");

        Member member2 = new Member();
        member2.setUsername("error");

        try {
            memberServiceRequiredNew.joinNew(member1);
            memberServiceRequiredNew.joinNew(member2);

        } catch (Exception e) {
            e.printStackTrace();
        }

        // Then
        // member2는 롤백되었지만, member1은 커밋되어야 함
        assertTrue(memberRepository.findByUsername("user2").isPresent());
        assertTrue(memberRepository.findByUsername("error").isEmpty());
    }


}

• requiredTest() member2를 join할 때 예외가 발생해서 전체 트랜잭션이 롤백될 것이다. 따라서 member1과 member2 모두 memberRepository에 저장되지 않았을 것이다.

• requireNewTest() member2를 join할 때 예외가 발생한다. 하지만 트랜잭션 속성이 REQUIRES_NEW이기 때문에 member1의 join의 트랜잭션이 아닌 새로운 트랜잭션이 롤백된다. 결과적으로 member1은 커밋되고, member2는 롤백된다.

테스트 결과

requredTest() 테스트가 실패했다. 디버그를 위해서 로그도 확인하고 프록시 객체인지 확인해봤다.

MemberService is proxied: true
User1 present after rollback: true
Error present after rollback: false

이유를 모르겠지만 전체 롤백이 되지 않았다... 좀 더 찾아보고 고쳐야겠다..

GDG on Campus Backend-Spring 스터디 WIL Week 06 - 스프링 DAO와 JDBC 템플릿 및 트랜잭션 관리

스프링 DAO

Data Access Object(데이터 접근 객체)

실제로 데이터베이스에 접근하는 객체 서비스와 데이터베이스를 연결하는 역할을 하며, 실제로 DB에 접근하여 데이터 CRUD 작업(삽입, 삭제, 조회, 수정)을 수행한다.

• 캡슐화 DAO는 데이터베이스 작업을 추상화하고 캡슐화하여 데이터 소스 접근과 비즈니스 로직을 분리한다.
• 재사용성 DAO 패턴은 코드의 재사용을 도와준다. 다양한 데이터 소스에 대해 일관된 인터페이스를 제공한다.
• 유지보수성 데이터 접근 로직에 한 곳에 모여 있어 유지보수에 유리하다. 변경사항을 쉽게 적용할 수 있다.

스프링 DAO의 필요성

• 코드 간소화 반복적인 JDBC 코드 간소화. 개발자는 비즈니스 로직에 집중 가능
• 예외처리 개선 checked 예외를 unchecked 예외로 변환하여 예외 처리의 유연성을 높인다.
• 테스트 용이성 의존성 주입을 통해 DAO를 쉽게 모의 객체로 대체할 수 있다. 이는 단위테스트를 용이하게 한다.

Chcked, Unchocked Exception

Checked exception: RuntimeException의 하위 클래스가 아니면서 Exception 클래스의 하위 클래스들. 반드시 에러 처리를 해야 한다. Unchecked exception: RuntimeException의 하위 클래스들. 실행 중에(runtime) 발생할 수 있는 예외를 의미. 에러 처리를 강제하지 않는다.

JDBC 템플릿

• 템플릿 메서드 패턴 JDBC 템플릿은 템플릿 메서드 패턴을 구현하여 반복적인 코드를 추상화한다.
• 콜백 사용 RowMapper, ResultSetExtractor 등의 콜백을 통해 결과 매핑을 커스터마이즈할 수 있다.
• 배치 작업 지원 batchUpdate 메서드로 대량 데이터 처리를 효율적으로 처리한다.

템플릿 메서드 패턴

메소드의 구조를 정의하고, 일부 단계를 하위 클래스에서 구현하도록 하는 디자인 패턴. 이를 통해 메소드의 구조 변경 없이 특정 단계를 재정의할 수 있다. 이는 반복적인 코드를 효과적으로 추상화하고 재사용성을 높이는데 도움이 된다.

JDBC 템플릿 관련 의존성

• spring-jdbc JDBC 및 데이터소스 지원을 위한 핵심 의존성. 이는 JDBC 템플릿을 사용하기 위해 필요하다.
• spring-tx 트랜잭션 관리를 위한 의존성. 선언적 트랜잭션 관리를 사용할 때 필요하지만, spring 4.3.3 버전부터 spring-tx가 spring-jdbc에 포함.
• 데이터베이스 드라이버 사용하는 데이터베이스에 맞는 JDBC 드라이버를 추가. (MySQL을 사용한다면 mysql-connector-java 추가)

JDBC 템플릿 사용법

1. 의존성 추가
2. DataSource 설정 데이터베이스 연결 정보를 포함한 DataSource를 구성한다.
3. JdbcTemplate 생성 DataSource를 이용해 JdbcTemplate 객체를 생성한다.

데이터베이스 설정 - DataSource

1. DataSource 빈 정의 xml 또는 java 설정으로 DataSource 빈을 정의한다. 이는 데이터베이스 연결 정보를 포함한다.
2. Connection Pool 설정 HikariCP와 같은 연결 풀을 사용하여 성능을 최적화하여 데이터베이스 연결을 효율적으로 관리한다.
3. property 외부화 데이터베이스 연결 정보를 properties 파일로 분리한다.

JDBC 사용시 문제점

1. 자원 관리 부담 Connection, Statement, ResultSet 등의 자원을 수동으로 관리해야 한다. 이는 메모리 낭비의 위험이 있더,
2. 예외 처리 복잡성 JDBC의 checked 예외는 처리가 번거롭다. 이는 코드를 복잡하게 만든다.
3. 코드 중복 연결, 명령문 생성, 결과 처리 등의 코드가 반복되기 때문에 코드의 가독성을 떨어뜨린다.

JDBC 템플릿 장점

1. 자원 관리 자동화 JDBC 템플릿이 연결 열기와 닫기를 관리.
2. 예외 변환 JDBC 예외를 스프링의 DataAccessException으로 변환한다. 이는 예외 처리를 일관되게 만든다.
3. 코드 간소화 반복적인 코드를 제거하여 핵심 로직에 집중할 수 있다.

JPA와 JDBC

JPA(Java Persistent API)

객체 지향 데이터 모델링 및 영속성 관리를 제공하는 표준 API. 복잡한 SQL 쿼리 작성을 자동화하고 객체지향적 프로그래밍 방식을 지원한다.

JDBC(Java Database Connectivity)

데이터베이스와 직접 통신하는 Java API. SQL 쿼리를 직접 작성하고 실행해야 하며, 개발자가 데이터베이스 관련 코드를 직접 관리해야 한다.

트랜잭션

ACID

트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질.

Atomicity(원자성)

트랜잭션의 모든 연산이 성공하거나 모두 실패해야 한다. 이는 데이터의 일관성을 유지한다.

Consistency(일관성)

트랜잭션 전후로 데이터베이스가 일관된 상태를 유지해야 한다. 이는 데이터 무결성을 보장한다.

Isolation(고립성)

동시에 실행되는 트랜잭션들이 서로 영향을 주지 않아야 한다. 이는 동시성 문제를 방지한다.

Durability(지속성)

성공적으로 완료된 트랜잭션의 결과는 영구적으로 반영되어야 한다. 이는 데이터의 안정성을 보장한다.

트랜잭션 관리의 중요성

데이터 일관성

트랜잭션은 여러 데이터베이스 작업을 하나의 논리적 단위로 묶어 데이터의 일관성을 보장한다.

에러 복구

문제 발생 시 롤백을 통해 데이터 무결성을 유지하여 시스템의 안정성을 높인다.

동시성 제어

여러 사용자의 동시 접근을 관리하여 데이터의** 정확성과 일관성**을 보장한다.

선언적 트랜잭션 관리

*1. 트랜잭션 관리자 설정 *DataSourceTransactionManager 빈 정의. 이는 JDBC 기반 트랜잭션을 관리한다.

*2. @EnableTransactionManagement *설정 클래스에 어노테이션 추가하여 선언전 트랜잭션 관리 활성화

3. @Transactional *트랜잭션이 필요한 *메서드나 클래스에 @Transactional`을 붙여 해당 범위에 트랜잭션을 적용한다.

트랜잭션 전파

어떤 트랜잭션이 동작 중인 과정에서 다른 트랜잭션을 실행할 경우 어떻게 처리하는가에 대한 개념

필요성

• 메서드 호출 한 메서드가 다른 메서드를 부를 때, 트랜잭션이 함께 이어져서 호출된다.
• 안전한 데이터 처리 작업이 하나로 묶여 처리되므로, 문제가 생기면 모든 작업이 취소되어 안전하게 처리가 가능하다.
• 쉬운 설정 스프링에서 제공하는 기능으로 복잡한 코드 없이 간단하게 설정 가능하다.
• 실무 활용 여러 데이터 작업을 안전하게 처리해야할 때 유용하다.

트랜잭션 전파 속성

전파 속성
REQUIRED	기존 트랜잭션이 있으면 참여하고, 없으면 새로 생성. 가장 흔히 사용되는 기본 설정.
REQUIRES_NEW	항상 새로운 트랜잭션 시작. 기존 트랜잭션은 일시중단됨.
NESTED	기존 트랜잭션 내에서 중첩 트랜잭션 실행. 부분적 롤백 가능.
SUPPORT	트랜잭션이 있으면 참여하고, 없어도 비트랜잭션으로 실행.

에러 처리

1. 전파 설정

@Transactional의 propagation 속성으로 트랜잭션 전파 방식을 지정한다.

2. 예외 처리

트랜잭션 내에서 발생한 예외를 적절히 처리한다. RuntimeException은 기본적으로 롤백을 유발한다.

3. 롤백 규칙

rollbackFor, noRollbackFor 속성으로 롤백 규칙을 세밀하게 조절할 수 있다.

예시

CREATE 연산

• UPDATE() 메서드 사용 JdbcTemplate의 update()메서드로 INSERT쿼리를 실행하여 데이터를 삽입할 수 있다.
• 파라미터 바인딩 ? 플레이스홀더를 사용하여 악의적인 SQL Injection을 방지할 수 있다.
• KeyHolder 사용 자동 생성된 키 값을 얻기 위해 사용할 수 있다. 특히 KeyHolder는 새로 삽입된 데이터의 기본 키 값을 편리하게 가져올 수 있도록 도와준다.

READ 연산

• queryForObject()
• 단일 결과*를 조회할 때 사용. RowMapper를 통해 결과를 객체로 매핑한다.
• query()
• 여러 결과*를 리스트로 조회할 때 사용한다. 복잡한 객체 매핑에 유용하다.
• RowMapper 구현 ResultSet의 데이터를 객체로 변환하는 로직을 정의함으로써 재사용 가능한 매핑 전략을 제공한다.

  UPDATE 연산

• update() 메서드 CREATE 연산과 비슷하게 UPDATE 쿼리 실행에도 update()메서드를 사용한다.
• 다중 파라미터 여러개의 파라미터를 순서대로 전달한다. 복잡한 UPDATE문을 실행할 때 유용하다.
• 배치 업데이트 batchUpdate()메서드로 여러 레코드를 한번에 업데이트할 수 있다. 대량 데이터 처리 시 성능을 향상시킨다.

  DELETE 연산

• ** update() 사용** DELETE쿼리도 update()메서드를 실행한다. 영향받은 행의 수를 반환받아 삭제 여부를 확인할 수 있다.
• 조건부 삭제 WHERE절을 사용하여 특정 조건에 맞는 데이터만 안전하게 삭제한다.
• 예외처리 DataAccessException을 catch하여 삭제 중 발생할 수 있는 오류를 처리한다.

H2 데이터베이스 설치 순수 JDBC 스프링 통합 테스트

H2 데이터베이스 설치

1. 다운로드 및 설치

https://www.h2database.com h2 데이터베이스 버전은 스프링 부트 버전에 맞춘다.

2. h2.bat 실행

h2/bin/h2.bat 실행

3. 데이터베이스 파일 생성

최초 실행 시 데이터베이스 파일을 생성해야 한다. JDBC URL: jdbc:h2:~/test를 입력하고 연결 클릭 C:\Users\jung에 test.mv.db 파일 생성 확인 이후부터는 JDBC URL: jdbc:h2:tcp://localhost/~/test 로 연결한다. 파일에 직접 접근하지 않고 소켓을 통해 접근하는 것.

데이터베이스가 꼬이면 서버 연결을 완전히 끊고, test.mv.db 삭제하고 다시 생성하는 것도 방법이다.

데이터베이스 생성

DDL(Data Definition Language)를 h2 콘솔에 입력하여 데이터베이스를 생성한다.

drop table if exists member CASCADE;
create table member
(
 id bigint generated by default as identity,
 name varchar(255),
 primary key (id)
);

• spring에서 Long이 sql 문법에서는 bigint
• generated by default as identity: db가 자동으로 값 채워줌

데이터 삽입

DML(Data Manipulation Language)를 h2 콘솔에 입력하여 데이터베이스에 데이터를 삽입한다. insert into member(name) values('spring')

• id는 데이터베이스에서 자동으로 생성해준다.

SQL 폴더

프로젝트 루트에 sql 디렉토리 생성 후, ddl.sql에 위의 ddl문을 저장해두면 github에 업로드할 수 있고 관리도 편하다.

순수 JDBC

JdbcMemberRepository 작성

package com.jiu.spring_basic.repository;

import com.jiu.spring_basic.domain.Member;
import org.springframework.jdbc.datasource.DataSourceUtils;
import javax.sql.DataSource;
import java.sql.*;
import java.util.ArrayList;
import java.util.List;
import java.util.Optional;

public class JdbcMemberRepository implements MemberRepository {
    private final DataSource dataSource;

    public JdbcMemberRepository(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Override
    public Member save(Member member) {
        String sql = "insert into member(name) values(?)";

        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;

        try {
            conn = getConnection();
            pstmt = conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS);

            pstmt.setString(1, member.getName());

            pstmt.executeUpdate();
            rs = pstmt.getGeneratedKeys(); // Statement.RETURN_GENERATED_KEYS 와 매칭

            if (rs.next()) {
                member.setId(rs.getLong(1));
            } else {
                throw new SQLException("id 조회 실패");
            }
            return member;
        } catch (Exception e) {
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }

    @Override
    public Optional<Member> findById(Long id) {
        String sql = "select * from member where id = ?";

        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;

        try {
            conn = getConnection();
            pstmt = conn.prepareStatement(sql);

            pstmt.setLong(1, id);

            rs = pstmt.executeQuery();

            if(rs.next()) {
                Member member = new Member();
                member.setId(rs.getLong("id"));
                member.setName(rs.getString("name"));
                return Optional.of(member);
            } else {
                return Optional.empty();
            }
        } catch (Exception e) {
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }

    @Override
    public List<Member> findAll() {
        String sql = "select * from member";
        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        try {
            conn = getConnection();
            pstmt = conn.prepareStatement(sql);
            rs = pstmt.executeQuery();
            List<Member> members = new ArrayList<>();
            while(rs.next()) {
                Member member = new Member();
                member.setId(rs.getLong("id"));
                member.setName(rs.getString("name"));
                members.add(member);
            }
            return members;
        } catch (Exception e) {
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }

    @Override
    public Optional<Member> findByName(String name) {
        String sql = "select * from member where name = ?";
        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        try {
            conn = getConnection();
            pstmt = conn.prepareStatement(sql);
            pstmt.setString(1, name);
            rs = pstmt.executeQuery();
            if(rs.next()) {
                Member member = new Member();
                member.setId(rs.getLong("id"));
                member.setName(rs.getString("name"));
                return Optional.of(member);
            }
            return Optional.empty();
        } catch (Exception e) {
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }

    private Connection getConnection() {
        return DataSourceUtils.getConnection(dataSource); // DataSourceUtils를 통해서 getConnection
    }

    private void close(Connection conn, PreparedStatement pstmt, ResultSet rs) {
        try {
            if (rs != null) {
                rs.close();
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
        try {
            if (pstmt != null) {
                pstmt.close();
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
        try {
            if (conn != null) {
                close(conn);
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    private void close(Connection conn) throws SQLException {
        DataSourceUtils.releaseConnection(conn, dataSource); // DataSourceUtils를 통해서 releaseConnection
    }
}

• DataSourceUtils를 통해서 get, release Connection

SpringConfig 변경

@Configuration
public class SpringConfig {

    private DataSource dataSource;

    @Autowired
    public SpringConfig(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Bean
    public MemberRepository memberRepository() {
//        return new MemoryMemberRepository();
        return new JdbcMemberRepository(dataSource);
    }
}

• Configuration 파일에서 MemberRepository를 반환하는 코드만 변경해주면 된다.
• DataSource DataSource는 데이터베이스 커넥션을 획득할 때 사용하는 객체다. 스프링 부트는 데이터베이스 커넥션 정보를 바탕으로 DataSource를 생성하고 스프링 빈으로 만들어둔다. 그래서 DI를 받을 수 있다.

실행

꼭 h2 database를 실행시킨 후, spring application을 실행시켜야 한다. http://localhost:8080 에 접속하면 h2 데이터베이스에 생성했던 회워 목록을 조회할 수 있다. 회원 가입을 하면, 가입된 회원을 h2 콘솔에서도 확인할 수 있다.

설명

• 개방-폐쇄 원칙(OCP, Open-Closed Principle) 확장에는 열려있고, 수정, 변경에는 닫혀있다.
• 다형성
• 스프링의 DI (Dependencies Injection)을 사용하면 기존 코드를 전혀 손대지 않고, 설정만으로 구현 클래스를 변경할 수 있다.
• 데이터를 DB에 저장하므로 스프링 서버를 다시 실행해도 데이터가 안전하게 저장된다.

스프링 통합 테스트

기존 테스트는 순수 자바 테스트코드. 스프링 컨테이너와 DB까지 연결한 통합 테스트를 진행해보자.

MemberServiceIntegrationTest

@SpringBootTest
@Transactional // 테스트 후 rollback
class MemberServiceIntegrationTest {

    // test 시 간단하게 field injection
    @Autowired MemberService memberService;
    @Autowired MemberRepository memberRepository;

    @Test
    void join() {
        //given
        Member member = new Member();
        member.setName("spring");

        //when
        Long saveId = memberService.join(member);

        //then
        Member findMember = memberService.findOne(saveId).get();
        assertThat(member.getName()).isEqualTo(findMember.getName());

    }

    @Test
    void Dup_Member_join(){
        //given
        Member member1 = new Member();
        member1.setName("dup");

        Member member2 = new Member();
        member2.setName("dup");

        //when
        memberService.join(member1);
        IllegalStateException e = assertThrows(IllegalStateException.class, () -> memberService.join(member2));
        assertThat(e.getMessage()).isEqualTo("이미 존재하는 회원입니다.");
    }
}

• @SpringBootTest 스프링 컨테이너와 테스트를 함께 실행한다.
• @Transactional 테스트 케이스에 이 애노테이션이 있으면, 테스트 시작 전에 트랜잭션을 시작하고, 테스트 완료 후에 항상 롤백한다. 이렇게 하면 DB에 데이터가 남지 않으므로 다음 테스트에 영향을 주지 않는다.
• 순수 자바 단위 테스트가 더 좋은 테스트일 확률이 높다.

실행

• 테스트를 위해 h2 콘솔에서 데이터를 지운다. delete from member
• 실행 시 통합 테스트이므로 테스트 로그에 spring 로그도 뜬다.

** HATEOAS와 커스텀 예외 처리를 포함한 REST API 구축**

프로젝트 구조

📂 controller      
│  └─ MemberController.java
📂 domain         
│  └─ Member.java
 📂 exception        
│  └─ MemberNotFoundException.java
│  └─ MemberNotFoundExceptionHandler.java
📂 repository     
│  └─ MemberRepository.java
📂 service          
│  └─ MemberService.java
└─ Week5Application.java

HATEOAS 없이 구현

h2 database와 spring jpa 사용

build.gradle

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'com.h2database:h2'
}

application.properties

// h2 database
spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.username=sa
spring.jpa.database-platform=org.hibernate.dialect.H2Dialect

// jpa
spring.h2.console.enabled=true
spring.jpa.hibernate.ddl-auto=create
// jpa log
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

spring.jpa.hibernate.ddl-auto=create: 엔티티를 보고 자동으로 데이터베이스 생성

Member

package com.example.demo.domain;

import jakarta.persistence.*;
import org.springframework.hateoas.RepresentationModel;

@Entity
@Table(name = "Members")
public class Member extends RepresentationModel<Member> {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;

    // Constructor
    public Member() {}

    public Member(String username) {
        this.username = username;
    }

    // Getters and Setters
}

• @Entity 이 클래스가 JPA 엔티티임을 선언 데이터베이스 테이블과 매핑되며, JPA가 이 클래스를 사용하여 데이터베이스 작업(저장, 조회, 수정, 삭제)을 수행
• @Table(name = "Members") 이 엔티티 클래스가 데이터베이스의 어떤 테이블과 매핑될지 지정.
• @Id 이 필드가 Primary Key(기본 키)임을 지정.
• @GeneratedValue(strategy = GenerationType.IDENTITY) id 필드가 자동으로 생성되도록 설정.
• private Long id; 엔티티의 Primary Key로, 데이터베이스에서 자동으로 생성되는 필드.
• private String username; 엔티티의 username 속성으로, 데이터베이스 테이블의 열(column)에 매핑.

MemberRepository

package com.example.demo.repository;

import com.example.demo.domain.Member;
import org.springframework.data.jpa.repository.JpaRepository;

import java.util.Optional;
public interface MemberRepository extends JpaRepository<Member, Long> { }

• JpaRepository<Entity 클래스, PK 타입>

• JpaRepository는 PagingAndSortingRepository, QueryByExampleExecutor 인터페이스를 상속

• PagingAndSortingRepository는 CrudRepository 인터페이스를 상속

• CrudRepository 인터페이스는 기본적인 CRUD 메소드 제공 : save(), findById(), existsById(), count(), deleteById(), delete(), deleteAll()

• QueryByExampleExecutor 인터페이스는 더 다양한 CRUD 메소드 제공 : findOne(), findAll(), count(), exists()

MemberService

package com.example.demo.service;

import com.example.demo.exception.MemberNotFoundException;
import org.springframework.stereotype.Service;
import com.example.demo.domain.Member;
import com.example.demo.repository.MemberRepository;

import java.util.List;
import java.util.Optional;

@Service
public class MemberService {

    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    public List<Member> getAllMembers() {
        return memberRepository.findAll();
    }

    public Member getMemberById(Long id) {
        return memberRepository.findById(id)
                .orElseThrow(() -> new MemberNotFoundException("No member found with ID " + id));
    }

    public Member createMember(Member member) {
        return memberRepository.save(member);
    }

    public Member updateMember(Long id, Member updatedMember) {
        Member member = getMemberById(id);
        member.setUsername(updatedMember.getUsername());
        return memberRepository.save(member);
    }

    public void deleteMember(Long id) {
        getMemberById(id); // id 존재 여부 확인하면서 예외 처리
        memberRepository.deleteById(id);
    }
}

• getMemberById()에서 id에 해당하는 멤버가 존재하지 않을 때, 커스텀 예외 처리

MemberController

package com.example.demo.controller;

import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;
import com.example.demo.domain.Member;
import com.example.demo.service.MemberService;

import java.util.List;
import java.util.Optional;

@RestController
@RequestMapping("/api/members")
public class MemberController {

    private final MemberService memberService;

    public MemberController(MemberService memberService) {
        this.memberService = memberService;
    }

    // GET /api/members
    @GetMapping
    public ResponseEntity<List<Member>> getAllMembers(){
        return ResponseEntity.ok(memberService.getAllMembers());
    }

    // GET /api/members/{id}
    @GetMapping("/{id}")
    public ResponseEntity<Member> getMemberById(@PathVariable Long id) {
        return ResponseEntity.ok(memberService.getMemberById(id));
    }

    // POST /api/members
    @PostMapping
    public ResponseEntity<Member> createMember(@RequestBody Member member) {
        Member createdMember = memberService.createMember(member);
        return ResponseEntity.status(201).body(createdMember);
    }

    // PUT /api/members/{id}
    @PutMapping("/{id}")
    public ResponseEntity<Member> updateMember(@PathVariable Long id, @RequestBody Member member) {
        return ResponseEntity.ok(memberService.updateMember(id, member));
    }

    // DELETE /api/members/{id}
    @DeleteMapping("/{id}")
    public ResponseEntity<String> deleteMember(@PathVariable Long id) {
        memberService.deleteMember(id);
        return ResponseEntity.noContent().build();
    }
}

• ResponseEntity를 이용하여 반환

  MemberNotFoundException

  package com.example.demo.exception;
  

public class MemberNotFoundException extends RuntimeException { public MemberNotFoundException(String message) { super(message); } }

#### MemberNotFoundExceptionHandler
```java
package com.example.demo.exception;

import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;

import java.time.LocalDateTime;
import java.util.HashMap;
import java.util.Map;

@RestControllerAdvice
public class MemberNotFoundExceptionHandler {

    @ExceptionHandler(MemberNotFoundException.class)
    public ResponseEntity<Object> handleMemberNotFound(MemberNotFoundException ex) {
        Map<String, Object> response = new HashMap<>();
        response.put("error", "Member Not Found");
        response.put("message", ex.getMessage());
        response.put("timestamp", LocalDateTime.now());
        return ResponseEntity.status(HttpStatus.NOT_FOUND).body(response);
    }
}

• Object를 반환해서 에러 종류, 메세지, 타임스탬프를 반환해준다.

TroubleShooting

• h2 콘솔 잘못 들어감 -> localhost:8080/h2-console/로 들어가야 한다!
• id를 넘겨줘야하는 메소드들에서 오류가 났다. 찾아보니, (@PathVariable("id") Long id) 이렇게 "id"까지 명시해주면 해결된다. Gradle로 빌드하면 안그래도 된다고 한다. velog.io/@ghwns9991

실행 결과

POST

GET

PUT

DELETE

Custom Exception

• 에러 종류, 메세지, 타임스탬프가 잘 반환되었다.

HATEOAS 구현

build.gradle

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-hateoas'
}

MemberController

1. HATEOAS 모델 적용 EntityModel 또는 CollectionModel을 사용하여 링크 추가. 2. 링크 생성 WebMvcLinkBuilder를 사용해 관련 메서드와 리소스를 연결.

    // GET /api/members/{id}
    @GetMapping("/{id}")
    public ResponseEntity<EntityModel<Member>> getMemberById(@PathVariable("id") Long id) {
        Member member = memberService.getMemberById(id);

        // HATEOAS 링크 추가
        EntityModel<Member> memberModel = EntityModel.of(member,
                WebMvcLinkBuilder.linkTo(WebMvcLinkBuilder.methodOn(MemberController.class).getMemberById(id)).withSelfRel(),
                WebMvcLinkBuilder.linkTo(WebMvcLinkBuilder.methodOn(MemberController.class).getAllMembers()).withRel("all-members")
        );

        return ResponseEntity.ok(memberModel);
    }

HATEOAS 구현

1. EntityModel 또는 CollectionModel 사용
2. RepresentationModel 사용

실행 결과