little_tale.log

[짤막지식] Web

Thu, 18 Jun 2026 00:30:37 GMT

1. React 로 짜면 봇이 못읽는다 ???

React 웹은 화면을 만드는 방식에 따라 검색엔진이 내용을 볼 수도 있고 못 볼 수도 있음

서버가 빈 HTML 전달
→ 브라우저가 JS 다운로드
→ React 실행
→ 화면 생성

React 앱은 처음 HTML이 거의 비어 있고, 브라우저에서 JavaScript가 실행된 뒤에 화면이 만듬

이걸 CSR, Client-Side Rendering이라함

SSR: 서버에서 HTML을 미리 만들어서 보냄
SSG: 빌드 시점에 HTML을 미리 만들어 둠
Prerender: 크롤봇용 HTML을 미리 생성

즉 검색엔진이 JavaScript를 실행 하지 않아도 본문을 읽을 수 있게 만드는 것임

Next로 해결하면?

Next.js SSR/SSG
→ 처음부터 본문이 들어간 HTML 제공
→ 크롤봇이 JS 실행 안 해도 읽을 수 있음

요즘 검색엔진/봇 들이 발전하면서 리엑트여도 가능하다라는 말이 있음

2. React가 빠른 이유는 Virtual DOM 때문일까?

흔히 React가 빠른 이유를 Virtual DOM이라고 설명한다.

하지만 실제로는

컴포넌트 구조
상태 관리
변경된 부분만 업데이트

가 더 중요한 이유다.

Virtual DOM 자체가 무조건 빠른 것은 아니다.

3. SPA는 왜 새로고침이 빠를까?

React는 보통 SPA(Single Page Application) 구조를 사용한다.

페이지 이동 시

HTML 전체를 다시 받지 않음
필요한 데이터만 API로 요청
변경된 화면만 갱신

그래서 앱처럼 부드럽게 동작한다.

4. Next.js는 왜 React인데 SEO에 유리하다는거야?

일단 Next.js는 페이지를 만드는 방식을 선택 가능

CSR: 브라우저에서 화면 생성
SSR: 요청이 들어올 때 서버에서 HTML 생성
SSG: 빌드할 때 HTML을 미리 생성

React도 쓰면서, 처음부터 내용이 들어있는 HTML을 줄수도 있다. 즉, 봇들이 읽고 가기 좋은 환경이다

Hydration

서버 → HTML 만들어 브라우저에
화면을 빠르겐 볼 수 있음 ( 다만 껍데기 )
브라우저에서 React JS 실행

위 과정을 Hydration 이라고 함.

5. Next.js에서 "use client"는 무슨 뜻일까?

Next.js App Router에서는 기본적으로 컴포넌트가 서버에서 실행된다. 그런데 useState, useEffect, onClick 같은 브라우저 기능이 필요하면 클라이언트에서 실행해야 한다.

이때 파일 맨 위에 적는 것이 "use client" 이다.

필요 개념

CSR

서버에서 거의 빈 HTML → Browser 가 JavaScript를 실행 하여 화면 구성

SPA

페이지가 여러개 처럼 보이게만 사실 HTML 하나에서 화면만 바뀌는 웹 앱

Virtual DOM

React가 화면을 바로 고치기 전에 사용하는 가짜 화면 설계도

다시말해, 필요한 부분만 바꿔 동작하는 방식

DevOps 3편 : Terraform 해보기

Tue, 19 May 2026 07:30:15 GMT

준비물

AWS 계정
Terraform CLI 설치
AWS CLI 설치
- https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

IAM 사용자 1명 + Access Key 1개 만들어 보자

루트 에서 바로 하는 것 보단 AWS 권한 분리를 위해 분리해 보려고 한다.

루트 계정으로 AWS 콘솔에 로그인
상단 검색창에 IAM 입력 후 IAM 서비스로
왼쪽 메뉴 Users(사용자)
Create user (사용자 만들기)
Create group 5.1. AmazonS3FullAccess 활성화 5.2. SignInLocalDevelopmentAccess 활성화 (CLI 로그인) AmazonS3FullAccess: S3 권한 = S3 버킷생성, 버킷 삭제, 버킷 목록조회, 객체 업로드/다운로드/삭제, 버킷정책 일부 관리
사용자 -> 보안 자격 증명 -> 엑세스키 -> 엑세스키 만들기
aws 상태 확인해 보기 7.1 유저 정보
```
aws sts get-caller-identity
```
7.2 유저, 엑세스키, secret_key, region
```
aws configure list
```
Terraform 상태 확인 하기 ( 버전 )
```
 terraform version
```

이제 코드로 작성해보자

작업할 폴더에서 providers.tf 를 생성

# Terraform 전체 설정 블록
# 어떤 Provider를 사용할지, 버전은 몇으로 할지 정의
terraform {
  # 필수 프로파이더를 설정
  required_providers {
    # aws 변수 선언 -> asw provider를 만들겠다. 
    aws = {
      # provider source 세팅
      source = "hashicorp/aws" # hashicorp에서 제공하는 aws 프로바이더 사용하겠다

      # provider 버전 세팅
      version = "~> 5.0" # 5.x 버전 사용하겠다
    }
  }
}


# aws 프로바이더 설정
provider "aws" {
  # region 설정 서울 (ap-northeast-2)
  region = "ap-northeast-2"
}

main.tf

# 실제로 만들 AWS 리소스 정의
# 리소스 타입 ex) aws_s3_bucket
# 리소스를 테라폼 내부에서 부를 이름 example
resource "aws_s3_bucket" "example" {
  bucket = "littletale-terraform-study-001" # 주의사항: AWS 전체에서 고유해야함!!
}

현재는

providers.tf

main.tf

이 두 구조로 진행하지만 실무에서는 좀더 나눈다고 한다.

providers.tf: 버전과 provider

variables.tf: 입력값 선언

terraform.tfvars: 실제 값

main.tf: 리소스 정의

테라폼안에서의 동작 순서 (aws 안넘어감)

초기화

terraform init

required_providers 의 값을 읽고 세팅을 한다.

린트 정리 ( 포멧 )

Terraform 코드 스타일을 표준 형태로 자동 정리

terraform fmt

validate ( 컴파일 )

현재 작성한 Terraform 설정이 문법적으로 맞는가 보는 단계

terraform validate

더 자세히는

괄호/블록 문법 오류
잘못된 속성명
provider 설정 구조 문제

terraform plan

이게 진짜 신기할 것 같은데 Terraform 이 현재 코드와 실제 인프라 상태를 비교 새로 만들것, 바꿀것, 지울것들을 미리 보여준다고 함

예측 동작

현재 AWS에 이 버킷 없음
코드에는 버킷 만들라고 되어 있음
그래서 1 to add

당연한 이야기겠지만 프로젝트 파일에서 진행 해야한다.

이번엔 AWS 로그인 정보를 읽지 못했다.

terraform의 AWS provider는 보통 이런 순서로 자격 증명을 찾음

환경변수
AWS shared config/profile
credentials file
EC2 role 등

즉 aws login 값을 못 가져오는 것 같음 -> 엑세스 키가 필요

IAM 사용자에서 Access Key 생성
터미널에서: aws configure
입력:

AWS Access Key ID
AWS Secret Access Key
Default region name: ap-northeast-2
Default output format: json

terraform plan

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_s3_bucket.example will be created
  + resource "aws_s3_bucket" "example" {
      + acceleration_status         = (known after apply)
      + acl                         = (known after apply)
      + arn                         = (known after apply)
      + bucket                      = "littletale-terraform-study-20260415-01"
      + bucket_domain_name          = (known after apply)
      + bucket_prefix               = (known after apply)
      + bucket_regional_domain_name = (known after apply)
      + force_destroy               = false
      + hosted_zone_id              = (known after apply)
      + id                          = (known after apply)
      + object_lock_enabled         = (known after apply)
      + policy                      = (known after apply)
      + region                      = (known after apply)
      + request_payer               = (known after apply)
      + tags_all                    = (known after apply)
      + website_domain              = (known after apply)
      + website_endpoint            = (known after apply)

      + cors_rule (known after apply)

      + grant (known after apply)

      + lifecycle_rule (known after apply)

      + logging (known after apply)

      + object_lock_configuration (known after apply)

      + replication_configuration (known after apply)

      + server_side_encryption_configuration (known after apply)

      + versioning (known after apply)

      + website (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

여기서 말하는 핵심은 간단하다

aws_s3_bucket.example 이라는 리소스를 AWS 에 새로 하나 추가한다.

Plan: 1 to add, 0 to change, 0 to destroy. 이부분이 핵심

will be created: 아직 안 만들었고, apply 하면 만들어진다는 뜻

이제 Apply 할 차례다

terraform apply

aws s3 ls
---
2026-04-16 09:45:47 littletale-terraform-study-20260415-01

테라폼 입장에서도 확인이 가능하다.

terraform state list
---
aws_s3_bucket.example

S3란 무엇이지?

AWS의 파일 저장 서비스 Simple Storage Service 의 줄임말! 이미지, 동영상, JSON, 로그, 백업 파일등

버킷은 무엇이지?

S3 안에서 파일을 담는 최상위 저장 공간 창고 라고 생각하자.

S3 = 창고 서비스 자체
bucket = 창고 하나
버킷 안의 파일들 = 그 창고 안에 들어 있는 물건들

exam

S3
└── bucket
    ├── file1.jpg
    ├── data.json
    └── logs.txt

변수를 사용해보자

당연하겠지만 이친구도 결국 Code 이기에 변수가 있다.

variables.tf

# Terraform 입력 변수 선언
# 이 파일은 "어떤 값을 외부에서 받을지"를 정의합니다.
variable "bucket_name" {
  # 이 변수의 의미를 설명합니다.
  description = "S3 bucket name"

  # 문자열(string) 타입만 받도록 제한합니다.
  type = string
}

terraform.tfvars

# 변수에 실제 값을 넣는 파일입니다.
# variables.tf 에서 선언한 bucket_name 변수에 값을 할당합니다.
bucket_name = "littletale-terraform-study-20260415-01"

main.tf

# 실제로 만들 AWS 리소스 정의
# aws_s3_bucket = AWS S3 버킷 리소스 타입
# example = Terraform 내부에서 이 리소스를 식별하는 이름
resource "aws_s3_bucket" "example" {
  # 기존 방식: 버킷 이름을 코드에 직접 하드코딩
  # 이 방식은 간단하지만, 값 변경 시 코드 자체를 수정해야 해서 재사용성이 떨어집니다.
  # bucket = "littletale-terraform-study-20260415-01"

  # 현재 방식: 변수(variable)로 버킷 이름을 받아서 사용
  # variables.tf 에서 선언한 bucket_name 값을 참조합니다.
  bucket = var.bucket_name
}

결과를 볼 수 있게

outputs.tf는 Terraform이 작업을 끝낸 뒤, 결과로 보여줄 값을 정의하는 파일

outputs.tf

# Terraform 출력값 선언
# 이 파일은 "Terraform이 성공적으로 생성한 리소스의 정보를 외부로 보여줄지"를 정의합니다.
output "bucket_name" {
  # 이 출력값의 의미를 설명합니다.
  description = "Created S3 bucket name"

  # aws_s3_bucket.example 리소스에서 bucket 속성(attribute)의 값을 가져옵니다.
  value = aws_s3_bucket.example.bucket
}

 jaehyungkim  ~/Desktop/Terraform  terraform apply 
aws_s3_bucket.example: Refreshing state... [id=littletale-terraform-study-20260415-01]

Changes to Outputs:
  + bucket_name = "littletale-terraform-study-20260415-01"

You can apply this plan to save these new output values to the Terraform state, without changing any real infrastructure.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes


Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

bucket_name = "littletale-terraform-study-20260415-01"

와닿지 않는다.

S3 버킷 생성
그 버킷 ARN을 IAM 정책에서 써야 함
그 버킷 이름을 다른 모듈에서 써야 함
생성된 URL을 출력해서 바로 확인해야 함

이럴 때 output이 없으면 매번 AWS 콘솔 들어가서 찾아야 한다.

variable = 내가 Terraform에 넘기는 값
output = Terraform이 나에게 돌려주는 값

일단 이정도로 정리하고 다시 다루어 보면 좋을 것 같음

Destroy

(plan, apply)

생성
수정
확인

위 단계처럼 현재까지 진행했다. 이제 삭제를 진행해 보자

Destroy 이름 부터가 부셔버리겠다인데 말 그대로다. terraform에서 관리하던 인프라 전부를 부시겠다이기 때문이다. 일단 해보자

 terraform plan -destroy

 terraform destroy

 ----

 aws_s3_bucket.example: Destroying... [id=littletale-terraform-study-20260415-01]
aws_s3_bucket.example: Destruction complete after 1s

Destroy complete! Resources: 1 destroyed.

만든 버킷이 없어졌다.

전부를 없애는 거다 보니 상당히 위험하게 느껴진다.

특정 리소스만 부시려면?

특정 리소스만 없애기 위해 아래와 같이 작성한다.

terraform destroy -target=aws_s3_bucket.example

경고가 떳다 "인프라 전체를 종합적으로 보지 않고, 특정 리소스를 찝어서 처리하고 있다" "권장하지 않는다"

즉, 해당 방식도 위험이 따른다. 저걸 삭제 했을때 어떤 영향이 일어날지 미지수 이기 때문이다.

그래도 한번 해보자

이것도 마찬가지로 잘 지워진 모습이다.

그렇다면 어떻게 해야 안전하게 할까?

바로, 코드로 지우거나, 주석 처리하는 것

# resource "aws_s3_bucket" "example" {
#   # 기존 방식: 버킷 이름을 코드에 직접 하드코딩
#   # 이 방식은 간단하지만, 값 변경 시 코드 자체를 수정해야 해서 재사용성이 떨어집니다.
#   # bucket = "littletale-terraform-study-20260415-01"

#   # 현재 방식: 변수(variable)로 버킷 이름을 받아서 사용
#   # variables.tf 에서 선언한 bucket_name 값을 참조합니다.
#   bucket = var.bucket_name

#   # 태그는 key-value 형태로 작성
#   tags = {
#     Name        = "littletale-study-bucket" # 버킷의 이름
#     Environment = "dev"                     # 개발 환경
#     Project     = "terraform-study"         # 프로젝트 이름
#     Owner       = "jaehyungkim"             # 소유자
#   }
# }




# output "bucket_arn" {
#   description = "ARN of the S3 bucket"
#   value       = aws_s3_bucket.example.arn
# }

# output "bucket_name" {
#   description = "Name of the S3 bucket"
#   value       = aws_s3_bucket.example.bucket
# }

plan, apply 돌리면 또 잘 지워져 나온다.

지금까지의 과정들

provider 설정
resource 생성
variable 분리
tags 추가
plan으로 변경 확인
apply로 반영
destroy로 삭제

State

상태 Terraform 에서도 상태라는 개념이 존재하다. Terraform이 관리하는 실제 인프라의 현재 상태를 기록해 둔 파일

plan에서 무엇을 만들지 예측
apply에서 실제 반영
destroy에서 무엇을 지울지 판단
다음 plan에서 변경점을 비교

이 들이 가능한 이유가 state 가 있기 때문

*.tf 파일 = 내가 원하는 목표 상태
terraform.tfstate = Terraform이 알고 있는 현재 상태

이 두개의 값을 통해 Terraform은 판단함

What If?

예를 들어 지금 네가 이런 코드를 썼다고 하자

resource "aws_s3_bucket" "example" {
  bucket = var.bucket_name
}

처음엔 state에 아무것도 없을 수 있음 그러면 Terraform은 이렇게 판단

코드에는 버킷이 있어야 한다고 적혀 있음
그런데 state에는 없음
그럼 새로 만들어야겠다

무슨 상태값들을?

Terraform 버전
리소스 목록
각 리소스의 실제 ID
속성값
output 값

조심할 점.

state에는 리소스 정보가 많이 들어간다. 민감한 정보도 들어있다.

git에 올리지 않기
팀이 공유 가능한 원격 backend 사용
lock 고려
접근 권한 고려

공유하지 말라는건가? -> X 공유해야한다.

terraform.tfstate를 각자 노트북에 따로 들고 있으면 문제가 발생

A가 apply 해서 실제 AWS는 바뀜
그런데 B 로컬 state는 예전 상태
그러면 B가 plan/apply 할 때 잘못된 판단 가능
동시에 작업하면 state 충돌도 남

하나의 서버에 State를 넣어 관리하는게 정석

동시 접근은?

한 사람이 먼저 state lock을 잡으면 다른 사람의 작업은 대기하거나 실패 하게

AWS 기존에 있던걸 Terraform 이 알아서 인식할까?

놀랍게도 그건 무리다. 기존 AWS 리소스가 있어도 state에 없으면 Terraform은 “내가 관리 중인 리소스”로 인식하지 않는다.

이때 선택지는 보통 2개

새로 만들 수 있는 건 Terraform으로 새로 구축 기존 것을 건드리지 않고 Terraform 관리 대상은 새로 만든 것부터 시작
기존 리소스를 Terraform state에 편입 ( import )
1. 예를들어 aws애 있던 resource들은 하나 하나 적어서 반영하기

시도해보기 - import

테라폼 상태 확인해보기

terraform state list
aws_s3_bucket.example

AWS 콘솔에서 기존에 없던 S3 버킷 littletale-terraform-study-20260416-01를 만듬
Terraform은 이 버킷을 자동으로 알지 못한다 그래서 plan만으로는 “기존 버킷을 가져오기”가 아니라 “새로 만들기”로 이해할 수 있다
기존 AWS 리소스를 Terraform이 관리하게 만들려면 import가 필요하다

terraform import aws_s3_bucket.imported littletale-terraform-study-20260416-01

aws_s3_bucket.imported: Terraform 코드 안의 리소스 주소
littletale-terraform-study-20260416-01 : AWS에 이미 존재하는 실제 버킷 이름

“이미 AWS에 있는 이 버킷을, Terraform의 aws_s3_bucket.imported 리소스로 등록해라”

처음엔 aws_s3_bucket.example로 import를 시도했는데, 그 주소는 이미 다른 버킷을 관리 중이어서 충돌이 났었다.

import 후 해야할 일

바로 실제 AWS와 상태가 일치 하는가 이다.

 terraform plan                                                                
aws_s3_bucket.example: Refreshing state... [id=littletale-terraform-study-20260415-01]
aws_s3_bucket.imported: Refreshing state... [id=littletale-terraform-study-20260416-01]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

현재는 간단히 하고 있어서 바꿀게 없다고 뜨지만

0 to add인지
0 to change인지
아니면 태그나 속성 차이 때문에 1 to change가 나오는지 등

이러한 부분들을 신경써야 한다.

Locals.tf

현재는 태그가 리소스마다 직접 박혀 있음 이런 값들을 local로 묶어서 재사용해야함 Common 느낌

현재

tags = {
  Name        = "littletale-study-bucket"
  Environment = "dev"
  Project     = "terraform-study"
  Owner       = "jaehyungkim"
}

locals.tf

locals {
  common_tags = {
    Environment = "dev"             # 개발 환경
    Project     = "terraform-study" # 프로젝트 이름
    Owner       = "jaehyungkim"     # 소유자
  }
}

main.tf

# 로컬로 따로 뺴서 연결
tags = merge(local.common_tags, {
    Name = "littletale-study-bucket"
})

단순 코드 가독성 때문일까?

그렇지 않다.

코드 가독성 (중복 제거)
재사용성
통제성 -> 변경 범위가 줄고, 범위 예측이 가능

variable과 local의 차이가 뭔데?

외부에서 주입받아야 하면 variable
코드 내부에서 정해도 되면 local
재사용성이 있는가 없는가로 생각해보자

variable "bucket_name" {
  description = "S3 bucket name"
  type = string
}

variable "bucket_name2" {
  description = "S3 bucket name"
  type = string
}

버킷 이름을 변수로 두는게 맞는지 고민해보자

버킷 이름은 환경마다 달라질 수 있음
전역 유일해야 해서 매번 바뀔 수도 있음
코드에 박아두면 재사용성이 떨어짐

bucket_name = "littletale-terraform-study-20260415-01"
bucket_name2 = "littletale-terraform-study-20260416-01"

즉 변수로 두는게 맞다

locals {
  common_tags = {
    Environment = "dev"             # 개발 환경
    Project     = "terraform-study" # 프로젝트 이름
    Owner       = "jaehyungkim"     # 소유자
  }
}

Environment = "dev" 이값도 변수로 빼는게 맞아 보인다.

locals {
  common_tags = {
    Environment = var.environment   # 개발 환경
    Project     = "terraform-study" # 프로젝트 이름
    Owner       = "jaehyungkim"     # 소유자
  }
}

다음과 같이 코드를 변경 하였다.

Outputs.tf

위에서 잠깐 다루었지만 이번에 좀 더 다루어 보자.

ARN

Amazon Resource Name 의 약자

AWS 리소스를 식별하는 주소
사람에겐 버킷 이름이
AWS 시스템에선 ARN 같은 정확한 참조값 ex) 식별자 ex) arn:aws:s3:::littletale-terraform-study-20260415-01

arn: → ARN 형식 시작
aws: → AWS
s3: → S3 서비스
::~ → 리소스 이름

output

terraform이 작업을 끝낸 뒤, 밖으로 보여줄 값을 정의하는 파일

만약 버킷을 만들었다면 Terraform은 버킷의 관련 값들을 알고 있음

버킷 이름
버킷 ARN
도메인 이름 등

→ 그중 중요한 값을 output으로 선언 → apply or terraform output 명령으로 확인 가능

“다른 코드/모듈이 이 값을 쓰게 만드는 인터페이스”

그럼 지금 상태에서 추가한 리소스에 관한 output을 짠다면 어떻게 할까?

resource "aws_s3_bucket" "imported" {
  bucket = var.bucket_name2

  tags = merge(local.common_tags, {
    Name = "littletale-imported-bucket"
  })
}

output "imported_bucket_name" {
  description = "Name of the imported S3 bucket"
  value       = aws_s3_bucket.imported.bucket
}

output "imported_bucket_arn" {
  description = "ARN of the imported S3 bucket"
  value       = aws_s3_bucket.imported.arn
}

versioning

aws s3 버킷의 버전관리 기능 마치 npm, fvm, spm 등 과 같은 느낌으로 생각하면 된다.

ex) 이미지들어있음 -> 수정함 -> 버전별로 관리해서 이전 이미지도 아는

중요한 포인트

버킷 안에서 관리 X -> 별도 리소스로 다루기

aws_s3_bucket 버킷 자체
aws_s3_bucket_versioning 버킷의 versioning 설정

버킷 차제

resource "aws_s3_bucket" "imported" {
  ...
}

버킷에 Versioning 적용

resource "aws_s3_bucket_versioning" "imported" {
  bucket = aws_s3_bucket.imported.id

  versioning_configuration {
    status = "Enabled"
  }
}

오해 금물 : 버킷을 새로 하나 더파서 하는 개념 X -> 기존것에 설정을 추가한것임 즉 리소스는 추가 O 버킷추가? X

사진과 같이 버전 관리가 활성화 된 모습이다.

public acess block

이번엔 Versioning 이랑 비슷하지만 다른 거다. 목적은 보안 이다.

# S3 버킷 public access block 설정 리소스입니다.
resource "aws_s3_bucket_public_access_block" "imported" {
  bucket = aws_s3_bucket.imported.id

  # 버킷 퍼블릭 액세스 차단 설정
  block_public_acls       = true # 퍼블릭 ACL 차단
  block_public_policy     = true # 퍼블릭 정책 차단
  ignore_public_acls      = true # 퍼블릭 ACL 무시
  restrict_public_buckets = true # 퍼블릭 버킷 제한
}

S3에서 공개 여부를 제어하는 대표수단

ACL
Bucket Policy

ACL - Access Control List

private
public-read
public-read-write

ex) 어떤 객체에 public-read -> 인터넷 누구나 읽을 수 있음

Bucket Policy

버킷에 붙는 Json ACL보다 더 구조적, 세밀하게 권한 제어

특정 IAM 사용자만 접근 허용
특정 VPC에서만 접근 허용
특정 prefix 경로만 읽기 허용
모든 사람(*)에게 읽기 허용

간단 정리

ACL = 리소스 권한 Bucket Policy = 버킷 권한 규칙 문서

  block_public_acls       = true # 퍼블릭 ACL 차단
  -> 버킷에 퍼블릭 AWS가 ACL 설정 차단

  block_public_policy     = true # 퍼블릭 정책 차단
  /*
      Principal *
    Action s3:GetObject
    Resource 버킷 객체 전체

    이런 퍼블릭 버킷 정책을 붙이려는 시도를 막음
  */

  ignore_public_acls      = true # 퍼블릭 ACL 무시
  -> 이미 퍼블릭 ACL이 있더라도, 그 ACL을 무시함

  restrict_public_buckets = true # 퍼블릭 버킷 제한

참고링크: restrict_public_buckets

Amazon S3에서 이 버킷에 대한 공개 버킷 정책을 제한할지 여부입니다. 기본값은 false
이 설정을 활성화해도 이전에 저장된 버킷 정책에는 영향을 미치지 않지만, 공개 버킷 정책 내의 공개 및 계정 간 액세스(특정 계정에 대한 비공개 위임 포함)는 차단됩니다.

문서: aws_s3_bucket_public_access_block

경로는 하나가 아니다.

위에서 4개의 값을 true 둔 것을 이해하면 알 듯이 S3가 공개되는 경로가 하나가 아니다.

ACL 로 공개
Bucket Policy
이전 설정값에 의한

Data source

테라폼이 기존에 있는 정보 리소스 조회만 하는 방법

resource = 만들고 관리함
data = 읽기만 함

다시 정리하면

지금 Terraform이 어떤 AWS 계정/사용자로 인증되어 있는지 그 정보를 읽어오는 것

** “Terraform이 만들지는 않지만, 알아야 하는 정보를 읽어오는 장치” ** "기존 AWS 정보도 Terraform에서 참조할 수 있다"

main.tf

# 데이터 소스
# 현재 로그인된 AWS 계정 정보를 가져옵니다.
data "aws_caller_identity" "current" {}
# 현재 사용 중인 AWS 리전을 가져옵니다.
data "aws_region" "current" {}

output.tf

# 데이터 소스 출력값
output "current_account_id" {
  description = "AWS account ID currently used by Terraform"
  value       = data.aws_caller_identity.current.account_id
}

# 데이터 소스 출력값
output "current_region" {
  description = "AWS region currently used by Terraform"
  value       = data.aws_region.current.name
}

Plan 출력 값

data.aws_caller_identity.current: Reading...
data.aws_region.current: Reading...
data.aws_region.current: Read complete after 0s [id=ap-northeast-2]
data.aws_caller_identity.current: Read complete after 0s [id=xxxxxxxxxx]

locals.tf

locals {
  common_tags = {
    Environment = var.environment   # 개발 환경
    Project     = "terraform-study" # 프로젝트 이름
    Owner       = "jaehyungkim"     # 소유자
    Region      = data.aws_region.current.name
  }
}

위와 같이 적용해보고 plan

 ...
 + "Region"      = "ap-northeast-2"
 ...
 + "Region"      = "ap-northeast-2"
...
Plan: 0 to add, 2 to change, 0 to destroy.

잘 반영 된 것을 확인 할 수가 있습니다.

잠깐 정리하기

provider
resource
variable
local
output
data
import
plan/apply/destroy

Module

프로그래밍을 해본사람들은 지겹게 들은 단어 모듈 즉, 재사용 단위로 묶는것을 뜻함

상황

예를들어 아래와 같이 상황을 두어보자

버킷 여러 개
VPC 여러 개
환경 여러 개
프로젝트 여러 개

이때 매번 코드를 새로 쓰면 중복, 실수 가능성 이 커짐

-> 공통 패턴을 모듈로 묶자

S3 구성법을 모듈화 하자

main.tf

# 이 모듈 안에서 공통으로 쓰는 태그 맵을 만듭니다.
# 루트 모듈에서 받은 environment, owner, project_name, region 값을 한 번 묶어서
# 여러 리소스에서 반복 사용하기 쉽게 정리합니다.
locals {
  common_tags = {
    # 배포 환경 구분용 태그입니다.
    Environment = var.environment

    # 리소스 소유자 식별용 태그입니다.
    Owner       = var.owner

    # 프로젝트 식별용 태그입니다.
    Project     = var.project_name

    # 현재 AWS 리전 태그입니다.
    Region      = var.region
  }
}

# 이 모듈의 핵심 리소스인 S3 버킷 본체입니다.
resource "aws_s3_bucket" "this" {
  # 루트 모듈에서 전달받은 실제 버킷 이름을 그대로 사용합니다.
  bucket = var.bucket_name

  # 공통 태그(local.common_tags)에 버킷별 Name 태그를 추가해서 최종 tags 맵을 만듭니다.
  # 이렇게 하면 Environment/Owner/Project/Region은 공통 유지,
  # Name만 버킷마다 다르게 줄 수 있습니다.
  tags = merge(local.common_tags, {
    Name = var.name_tag
  })
}

# versioning 설정은 선택적으로 생성합니다.
# enable_versioning이 true면 count = 1이 되어 리소스가 생성되고,
# false면 count = 0이 되어 이 설정 리소스가 아예 생기지 않습니다.
resource "aws_s3_bucket_versioning" "this" {
  # 필요할 때만 리소스를 생성하기 위한 count 조건입니다.
  count = var.enable_versioning ? 1 : 0

  # versioning 설정이 적용될 대상 버킷 ID입니다.
  bucket = aws_s3_bucket.this.id

  versioning_configuration {
    # 객체를 덮어써도 이전 버전을 남기도록 버전 관리를 활성화합니다.
    status = "Enabled"
  }
}

outputs.tf

# 이 파일은 모듈 내부에서 만든 버킷의 주요 값을 모듈 밖으로 내보냅니다.
# 루트 모듈은 이 output들을 받아 다시 자신의 output으로 노출할 수 있습니다.

# 이 모듈이 만든 버킷의 ARN입니다.
output "bucket_arn" {
  description = "ARN of the S3 bucket"
  value       = aws_s3_bucket.this.arn
}

# 이 모듈이 만든 버킷의 실제 이름입니다.
output "bucket_name" {
  description = "Name of the S3 bucket"
  value       = aws_s3_bucket.this.bucket
}

valiable.tf

# 이 파일은 s3_bucket 모듈이 루트 모듈로부터 받아야 하는 입력값들을 정의합니다.

# 실제 S3 버킷 이름입니다.
variable "bucket_name" {
  description = "Name of the S3 bucket"
  type        = string
}

# versioning 설정을 생성할지 여부입니다.
variable "enable_versioning" {
  description = "Whether to enable S3 bucket versioning"
  type        = bool
  default     = false
}

# 공통 태그에 들어갈 배포 환경값입니다.
variable "environment" {
  description = "Deployment environment"
  type        = string
}

# 공통 태그와 별도로 버킷별 Name 태그에 들어갈 값입니다.
variable "name_tag" {
  description = "Value for the Name tag"
  type        = string
}

# 공통 태그에 들어갈 Owner 값입니다.
variable "owner" {
  description = "Owner tag value"
  type        = string
}

# 공통 태그에 들어갈 Project 값입니다.
variable "project_name" {
  description = "Project tag value"
  type        = string
}

# 공통 태그에 들어갈 AWS 리전 값입니다.
variable "region" {
  description = "AWS region tag value"
  type        = string
}

위 사진과 같이 모듈화를 해놓았다

main.tf 변경점 1. module

# example 버킷용 S3 모듈 호출입니다.
# 루트 모듈은 "어떤 값을 넘길지"만 결정하고,
# 실제 버킷 리소스, 태그 조합, versioning 구현은 modules/s3_bucket 안에 둡니다.
module "example" {
  # 이 모듈 코드가 있는 로컬 경로입니다.
  source = "./modules/s3_bucket"

  # 실제 S3 버킷 이름입니다.
  bucket_name = var.bucket_name

  # example 버킷은 versioning을 켜지 않도록 false를 전달합니다.
  enable_versioning = false

  # 공통 태그에 들어갈 환경값입니다.
  environment = var.environment

  # 버킷별 Name 태그 값입니다.
  name_tag = "littletale-study-bucket"

  # 공통 태그에 들어갈 Owner 값입니다.
  owner = var.owner

  # 공통 태그에 들어갈 Project 값입니다.
  project_name = var.project_name

  # data source로 읽어온 현재 AWS 리전을 태그 값으로 넘깁니다.
  region = data.aws_region.current.name
}

# imported 버킷용 S3 모듈 호출입니다.
# 이 모듈은 example 모듈과 같은 구현을 재사용하지만,
# versioning을 켜고 Name 태그만 다르게 넘겨서 동작 차이를 만듭니다.
module "imported" {
  # 같은 모듈을 재사용합니다.
  source = "./modules/s3_bucket"

  # imported 버킷의 실제 S3 이름입니다.
  bucket_name = var.bucket_name2

  # imported 버킷은 versioning을 활성화하도록 true를 전달합니다.
  enable_versioning = true

  # 공통 태그에 들어갈 환경값은 example과 동일하게 사용합니다.
  environment = var.environment

  # imported 버킷 전용 Name 태그 값입니다.
  name_tag = "littletale-imported-bucket"

  # 공통 태그에 들어갈 Owner 값입니다.
  owner = var.owner

  # 공통 태그에 들어갈 Project 값입니다.
  project_name = var.project_name

  # data source로 읽어온 현재 AWS 리전을 태그 값으로 넘깁니다.
  region = data.aws_region.current.name
}

위에서 재사용 가능한 방식으로 변경 했었기 때문에 그들을 사용하기 위해 resource -> module 로 변경하였다.

main.tf 변경점 2. moved

테라폼이 갖고 있는 즉 state 에서 이미 예전 리소스를 물고 있기 때문에 새로 만든 모듈 것을 쓰도록 옮기기 위해서

main.tf

# 예전에 루트 모듈에서 직접 관리하던 example 버킷을,
# 이제는 module.example 안의 aws_s3_bucket.this로 옮겼다고 Terraform state에 알려줍니다.
# 이 선언이 없으면 Terraform은 "기존 리소스를 삭제하고 module 안 리소스를 새로 만든다"고 오해할 수 있습니다.
moved {
  from = aws_s3_bucket.example
  to   = module.example.aws_s3_bucket.this
}

# 예전에 루트 모듈에서 직접 관리하던 imported 버킷을,
# 이제는 module.imported 안의 aws_s3_bucket.this로 옮겼다고 Terraform state에 알려줍니다.
moved {
  from = aws_s3_bucket.imported
  to   = module.imported.aws_s3_bucket.this
}

# imported 버킷의 versioning 설정도 루트 리소스에서 module 내부 리소스로 주소를 이전합니다.
# count가 켜져 있으므로 module 쪽 주소는 this[0] 형태가 됩니다.
moved {
  from = aws_s3_bucket_versioning.imported
  to   = module.imported.aws_s3_bucket_versioning.this[0]
}

outputs.tf

# 루트 모듈에서 확인하고 싶은 값들을 밖으로 노출하는 파일입니다.
# 각 output은 module 내부 리소스를 직접 보는 대신, module이 내보낸 값을 다시 노출합니다.

# example 모듈이 만든 버킷의 ARN입니다.
output "bucket_arn" {
  description = "ARN of the S3 bucket"
  value       = module.example.bucket_arn
}

# example 모듈이 만든 버킷의 실제 이름입니다.
output "bucket_name" {
  description = "Name of the S3 bucket"
  value       = module.example.bucket_name
}

# imported 모듈이 관리하는 버킷의 ARN입니다.
output "imported_bucket_arn" {
  description = "ARN of the imported S3 bucket"
  value       = module.imported.bucket_arn
}

# imported 모듈이 관리하는 버킷의 실제 이름입니다.
output "imported_bucket_name" {
  description = "Name of the imported S3 bucket"
  value       = module.imported.bucket_name
}

# 현재 Terraform이 인증된 AWS 계정 ID입니다.
# data source에서 읽은 값을 output으로 확인할 수 있게 노출합니다.
output "current_account_id" {
  description = "AWS account ID currently used by Terraform"
  value       = data.aws_caller_identity.current.account_id
}

# 현재 provider가 사용 중인 AWS 리전입니다.
# data source에서 읽은 값을 output으로 확인할 수 있게 노출합니다.
output "current_region" {
  description = "AWS region currently used by Terraform"
  value       = data.aws_region.current.name
}

outputs 에서도 이젠 모듈에 있는 값을 쓸 수 있도록 변경

variables.tf

# 루트 모듈에서 관리하는 첫 번째 버킷의 실제 이름입니다.
# 전역 유일해야 하므로 보통 terraform.tfvars에서 환경별로 다르게 넣습니다.
variable "bucket_name" {
  # 이 값이 어떤 의미인지 Terraform 문서/에러 메시지에 함께 보여줍니다.
  description = "S3 bucket name for the example bucket"

  # S3 버킷 이름은 문자열이므로 string 타입을 사용합니다.
  type = string
}

# 루트 모듈에서 관리하는 두 번째 버킷(imported)의 실제 이름입니다.
variable "bucket_name2" {
  # 이 값이 어떤 의미인지 Terraform 문서/에러 메시지에 함께 보여줍니다.
  description = "S3 bucket name for the imported bucket"

  # S3 버킷 이름은 문자열이므로 string 타입을 사용합니다.
  type = string
}

# 공통 태그에 넣을 배포 환경값입니다.
# 예: dev, staging, prod
variable "environment" {
  description = "Deployment environment"
  type        = string
}

# 공통 태그에 넣을 Owner 값입니다.
# 이 프로젝트에서는 버킷 둘 다 같은 소유자 태그를 사용합니다.
variable "owner" {
  description = "Owner tag value"
  type        = string
}

# 공통 태그에 넣을 Project 값입니다.
# 이 프로젝트에서는 버킷 둘 다 같은 프로젝트 태그를 사용합니다.
variable "project_name" {
  description = "Project tag value"
  type        = string
}

위 같이 모듈화를 진행 하였다. 상당히 난이도가 복잡한 이야기 들이다.

Backend

프론트엔드, 백엔드 할때 그 백엔드.....가 아니다. Terraform state를 어디에 저장할지 정하는 저장 방식

Provider Vs Backend

provider = Terraform이 어느 서비스와 통신할지 선택
backend = 어디에 저장할지 (state 를 어디에?)

BackEnd의 중요성

본인이 가진 state와 동료의 state가 불일치

state를 S3에 저장
lock은 DynamoDB로 분리 관리

# state를 팀원과 공유 목적 (Backend)
terraform {
  backend "s3" {
    bucket = "terraform-state-bucket"
    key    = "study/terraform.tfstate"
    region = data.aws_region.current.name
  }
}

이렇게 작성해보았었다. 다만 지적 사항이 존재한다.

data.aws_region.current.name를 쓰면 안 됩니다.

이유는 좀 재미있다.

backend는 Terraform이 data source를 읽기 전에 먼저 초기화

bucket = "terraform-state-bucket"는 실제로 존재하는 S3 버킷이어야

생성하는게 아니기 때문에 존재 하여야만 한다.

 backend "s3" {
    bucket = "terraform-state-bucket"
    key    = "study/terraform.tfstate"
    region = "ap-northeast-2"
  }

다음과 같이 하드하게 작성하도록 수정하였다.

2번째 문제를 해결하고자 resouce를 선언하면 어떻게될까 고민을 해보았다. 결론은 안된다.

Terraform 시작
먼저 backend 초기화 필요
state를 어디서 읽고 쓸지 결정
그다음에야 리소스들을 해석하고 plan/apply 가능

그럼 이 문제를 해결하려면 단순히 aws에 직접 생성하면 될까?

빠르게 해결은 됨 다만 유지보수 애매

-> backend 전용 Terraform을 구성하면 될듯

Backend 프로젝트 따로 만들고 연결

# Terraform state를 로컬 파일 대신 S3에 저장하는 backend 설정입니다.
  # bucket은 state 파일이 저장될 S3 버킷 이름입니다.
  # key는 그 버킷 안에서 state 파일이 놓일 경로입니다.
  # region은 backend 버킷이 존재하는 AWS 리전입니다.
  #
  # 주의:
  # backend 블록은 Terraform 초기화 단계에서 먼저 읽히므로
  # data.aws_region.current.name 같은 data source 참조를 사용할 수 없습니다.
  # 따라서 region은 문자열로 직접 적어야 합니다.
  backend "s3" {
    bucket         = "littletale-terraform-state-20260419"
    key            = "study/terraform.tfstate"
    region         = "ap-northeast-2"
    dynamodb_table = "terraform-state-lock"
  }

  bucket: state 파일 저장 버킷
  key: 그 버킷 안의 state 경로
  region: backend 버킷 리전
  dynamodb_table: state lock 테이블

메인 프로젝트 루트에서 마이그레이션을 진행해야 함.

terraform init -migrate-state

위 사진 처럼 정상적으로 State에 올라간 것이 보인다

명령어 로도 가능하다

> aws s3 ls s3://littletale-terraform-state-20260419/study/
2026-04-21 10:34:31       8793 terraform.tfstate

DynamoDB란?

AWS의 NoSQL 완전관리형 데이터 베이스

서버 직접 설치/운영 안 함 (AWS가 관리)
키-값 형태나 문서 형태처럼 빠르게 읽쓰 가능

DynamoDB Lock?

지금 State 작업중인지 기록
lock 흭득
작업 끝내면 lock 해제

--- 먼저 시도 ---

Terraform Apply
DynamoDB 테이블에 내가 지금 lock 기록 시도
성공시 작업 진행
끝나면 lock 삭제

--- 후에 시도 ---

Terraform Apply
이미 lock 있어서 실패
대기 혹은 실패

환경 분리 (Dev, Prod)

이유는 뭐... 실제 운영중인 곳에 영향이 없어야 겠죠?

폴더 방식과, 워크스페이스 방식이 있다. 흥미로운 사실은 폴더 방식을 주로 사용하다는것 (실수방지) ex)

envs/
  dev/
  prod/
modules/
  s3_bucket/

사진과 같이 변경 구조를 바꾸었다.

흐름

Root

envs/dev
envs/prod

cd /Users/jaehyungkim/Desktop/Terraform/envs/dev
terraform plan

File Load

envs/dev/terraform.tf (line 1)
envs/dev/providers.tf (line 1)
envs/dev/main.tf (line 1)
envs/dev/locals.tf (line 1)
envs/dev/outputs.tf (line 1)

Backend Load

Provider Load

local load ( locals.tf )

버킷 이름
환경 이름
owner
project_name
Name 태그
versioning on/off

# dev 환경 값을 한 객체로 묶어 관리합니다.
# 이렇게 하면 env 루트가 "환경 설정 파일"처럼 보이고,
# 비슷한 변수 선언 파일을 환경마다 반복해서 둘 필요가 줄어듭니다.
locals {
  config = {
    bucket_name                = "littletale-terraform-study-20260415-01"
    imported_bucket_name       = "littletale-terraform-study-20260416-01"
    environment                = "dev"
    owner                      = "jaehyungkim"
    project_name               = "terraform-study"
    example_name_tag           = "littletale-study-bucket"
    imported_name_tag          = "littletale-imported-bucket"
    example_enable_versioning  = false
    imported_enable_versioning = true
  }
}

main.tf 가 상위 환경 모듈 호출

module "environment" {
  source = "../../modules/s3_environment"
  config = local.config
}

modules/s3_environment를 호출하고
dev용 설정 객체를 넘깁니다

현재 AWS 계정/리전 조회

data "aws_caller_identity" "current" {}
data "aws_region" "current" {}

버킷 2개 조립

module "example" { ... }
module "imported" { ... }

output 준비

# dev example 버킷의 ARN입니다.
output "bucket_arn" {
description = "ARN of the dev example bucket"
value       = module.environment.bucket_arn
}

dev example 버킷의 실제 이름입니다.

output "bucket_name" { description = "Name of the dev example bucket" value = module.environment.bucket_name }

dev imported 버킷의 ARN입니다.

output "imported_bucket_arn" { description = "ARN of the dev imported bucket" value = module.environment.imported_bucket_arn } ...


## 요약 흐름

1. envs/dev/terraform.tf
   backend/state 결정
2. envs/dev/providers.tf
AWS 연결 결정
3. envs/dev/locals.tf
dev 환경값 준비
4. envs/dev/main.tf
modules/s3_environment 호출
5. modules/s3_environment
환경 단위 조립
6. modules/s3_bucket
실제 S3 버킷 리소스 구현
7. output이 다시 위로 올라와 최종 노출





### 마치며
> 오우 너무 길었어요
> 잘라서 가겠습니다.

DevOps 의 과정 2편 - 네트워크

Tue, 21 Apr 2026 00:55:44 GMT

들어가기에 앞서

이제 Terraform을 제대로 이해하기 위해 가장 먼저 필요한 네트워크 개념을 정리해보자.

Terraform은 인프라를 코드로 정의하는 도구지만, 실제로 만들게 되는 것은 결국 네트워크 + 서버 구조다.

VPC를 만들고
Subnet을 나누고
서버를 배치하고
외부와 통신을 설계하는 것

이 모든 것이 결국 네트워크 위에서 이루어진다.

그래서 Terraform을 배우기 전에 "이 리소스들이 왜 필요한지"를 이해하는 것이 훨씬 중요하다.

What VPC

AWS 안에서 내가 쓰는 네트워크 영역

AWS 내부에서 직접 만드는 가상의 네트워크 공간 다시말해 AWS 라는 큰 건물이 있다면 내가 따로 쓸 전용 공간

서버들이 배치될 공간 생성
IP 대역 정하기
subnet 분할
외부 인터넷 연결할지 & 내부끼리만 통신할지
핵심은 가장 바깥쪽 틀*

What Subnet

VPC 내부의 또 나뉜 구역 서버를 한 공간에 다 넣었을때 보안과 관리가 어려워진다.

외부에서 접근이 가능한 서버 (Web Server)

내부에서 접근 가능한 서버 (DB)

등 이와 같은 것들을 한 곳이 아닌 여러 구역을 나눠서 관리하려는 목적 즉 Subnet 이다.

🌍 Public Subnet / Private Subnet

Public Subnet

인터넷과 직접 통신이 가능한 영역
ALB, Bastion Host 같은 것 들이 위치하다.

( ALB: 외부 요청을 받아 내부 서버로 분산 하는 로드밸런서 ) ( Bastion Host: 외부에서 내부 서버에 안전 접속위한 중간 서버 )

Private Subnet

인터넷 직접 접근 X
내부 서비스 (App Server, DB ...)

핵심 포인트

단순 분리가 X = 접근 가능 범위를 분리!

🔗 Terraform에서의 의미

Terraform에서는 VPC 안에 Subnet을 생성해서 서버를 어디에 둘지 결정한다.

다시말해,

VPC = 나라 전체
Subnet = 행정구

자 우리는 지금 나라와 행정구를 나누었다. 이제 나라간 소통을 하려면 인터넷이 필요하고 인터넷은 과연 어떻게 연결되는 것일까?

What Internet Gateway

VPC 와 인터넷은 바로 연결하는 것은 불가능하다. 외부 인터넷과 완전 분리된 사설 네트워크 공간이기에 즉, 보안과 격라를 위해 인터넷과 바로 연결하기는 힘들다.

VPC가 외부 인터넷과 통신할 수 있는 문지기가 있으면 되겠다! 그것이 IGW Internet Gateway

🤔 왜 필요한지 좀 더 고민해보자.

서버를 생성하였다. 외부에서 접근이 불가하고, 반대로 외부로 나가는 것도 불가하다.

이는 매우 안전한 상태가 되었다. 다만 실서비스를 지원하려면 결국 Internet으로 사용자에게 제공해야 한다. 그렇다고 하여도 모든것을 Open 해줄 수 있는것도 아니다 일정 부분 공개 하지 말아야 할 것들이 있을것이다.

필요한 경우에만 외부와 소통할 수 있는 장치가 필요하다.

🌍 어디에 연결되는걸까?

Internet Gateway는 VPC에 연결된다. 즉, 이말은 하나 하나 Subnet에 연결하는 것이 아닌 그들을 관리하는 전체 VPC 가 연결 된다는 것이다.

다만, 전체에 연결 되었다고 하여서 모든 Subnet이 바로 인터넷과 통신하는 것이 아니다.

VPC에 IGW를 연결하는 것은 단순히 인터넷으로 나가는 출입문 만들기를 한 것 그래서 Subnet 쪽에서 어떤 출입문을 사용할지는 지정이 필요하게 된다. 이때 필요한 개념이 Route Table 이다.

VPC 생성
Subnet 생성
Internet Gateway 연결
Route Table에 경로 설정

해당 과정을 거치면 Public Subnet이 동작!

🔗 Terraform에서의 의미

Terraform에서는

VPC를 만듬
aws_internet_gateway 리소스로 IGW를 연결

What Route Table

"어디로 가야 하는지" 를 알려주는 경로 정보가 필요하다. 네트워크의 길안내판 같은 개념이라고 생각해 보자

Subnet 안의 서버가 외부와 통신하려고 할 때, 그 요청이 어디로 나가야 하는지 정해져 있지 않다면 패킷은 목적지를 찾지 못한다.

인터넷으로 나갈지?
다른 내부 네트워크로 갈지?
NAT Gateway 쪽으로 보낼지?

이런 경로를 미리 정해줘야 한다. 즉 "이 Subnet의 트래픽이 어디로 향할지 결정하는 규칙표"

🌍 어떻게 동작하는가?

Route Table은 보통 Destination(목적지) 과 Target(대상) 으로 구성된다.

10.0.0.0/16 → local
0.0.0.0/0 → Internet Gateway

같은 VPC 내부 주소로 가는 트래픽은 내부에서 처리하고 그 외 모든 외부 요청은 Internet Gateway로 보내라는 뜻이다.

0.0.0.0/0 = 모든 외부 주소

🌍 Public Subnet / Private Subnet 차이

Public Subnet

Route Table에 0.0.0.0/0 → Internet Gateway 경로가 있음
외부 인터넷과 통신 가능

Private Subnet

Internet Gateway로 직접 가는 경로가 없음
외부에서 직접 접근 불가능

정리하기

IGW만 있으면 문만 있는 상태
Route Table까지 연결해야 실제로 그 문을 사용할 수 있음

🔗 Terraform에서의 의미

Terraform에서는 aws_route_table 로 경로 규칙을 만들고, aws_route_table_association 으로 특정 Subnet에 연결한다.

VPC에 인터넷 출입문을 만들고 어떤 Subnet이 그 출입문을 사용할지 정하는 것

What NAT GateWay

private subnet은 보안때문에 외부 인터넷 직접 접근이 불가하게 구성한다.

하지만, private subnet도 외부 인터넷과 통신해야 할 때가 있다. 예를들어

서버 패키지 설치
보안 업데이트 다운로드
외부 API 호출
Docker 이미지 다운로드

이럴 때 사용하는 것이 NAT Gateway

다만, 외부에서 직접 들어올 수 없게 하는 것 이게 핵심

외부에서는 직접 접근 불가
내부 서버는 필요할 때 외부로 나갈 수 있음

🌍 어떻게 동작하는가?

NAT Gateway는 보통 Public Subnet에 생성된다.

Private Subnet의 Route Table에서 외부로 가는 경로(0.0.0.0/0)를 NAT Gateway로 설정

Private Subnet의 서버가 외부 요청을 보냄
그 요청이 NAT Gateway를 거쳐 인터넷으로 나감
응답은 다시 NAT Gateway를 통해 돌아옴

흠 왜 Public 한 Subnet이지?

외부 인터넷과 연결된 상태여야 역할을 할 수 있는데, Internet Gateway와 연결 가능한 Public Subnet에 위치에 있어야 인터넷 통신이 가능하기 때문

NAT Gateway는 인터넷과 연결된 곳에 있고
Private Subnet은 NAT를 통해서만 외부와 통신하는 구조

다시말해

Public Subnet = 외부와 직접 통신 가능
Private Subnet = 외부에서 직접 접근 불가
NAT Gateway = Private Subnet이 필요할 때만 외부로 나갈 수 있게 해줌

🔗 Terraform에서의 의미

Terraform에서는 Public Subnet에 NAT Gateway를 생성하고, Private Subnet의 Route Table에서 외부 경로를 NAT Gateway로 연결한다.

즉, NAT Gateway는 "Private Subnet 서버의 아웃바운드 인터넷 통신을 위한 구성요소" 라고 이해하면 된다.

Security Group

인스턴스에 붙는 상태 기반 방화벽 EC2 앞에서 트래픽을 허용/차단 하는 필터

인스턴스 단위로 동작
네트워크 레벨이라기 보단 서버 바로 앞

[인터넷]
   ↓
[Internet Gateway]
   ↓
[VPC]
   ↓
[Subnet]
   ↓
[Security Group]
   ↓
[EC2]

그래서 역활이 ... 👀

이 요청을 받아도 되는지 판단!

규칙 구조 Rule

port ( 어디로? )
protocol (TCP/UDP...)
source / destination ( who? )

💡 예시

TCP / 22 / 내 IP → “내 컴퓨터만 SSH 접속 허용” TCP / 80 / 0.0.0.0/0 → “모든 사람이 웹 접속 가능”

Allow only

허용 규칙만 있음

나머지는 전부 자동 차단

Stateful 하다.

❌ Stateless (예: NACL)

요청 따로
응답 따로 허용해야 함

✅ Stateful (SG)

요청 허용하면
응답은 자동 허용

Inbound / Outbound

Inbound (들어오는 것)

👉 외부 → EC2

SSH 접속
HTTP 요청
DB 접속
🔼 Outbound (나가는 것)

👉 EC2 → 외부

API 호출 패키지 설치 (apt, yum) DB 외부 연결

기본적으론 기본값: 전부 허용 이다.

문제 생기면:

SG inbound 확인
포트 확인
Source 확인

마무리 하면서

네트워크를 이번에 조금더 다루면서 다음편 부터는 Terraform 을 직접 사용해보려고 합니다.

DevOps 의 과정 1편 - 훑어 보기 + 리눅스

Mon, 13 Apr 2026 06:20:41 GMT

Terraform 들어가기 전에 먼저 깔아야 할 기초

리눅스 명령어 (기본 정도)
네트워크 기초

VPC, Subnet, Route, NAT, Security Group/Firewall

클라우드 기초

IAM, Compute, Storage, Load Balancer

Git 기초

branch, PR, revert

JSON/YAML 읽기 능력

** 이중에서 4번 같은 경우는 생략 **

Terraform은 인프라를 코드로 만들지만, 실제로 다루는 대상은 결국 리눅스 서버다.

그래서 최소한의 리눅스 명령어를 모르면 인프라를 만들고도 디버깅, 로그 확인, 서버 접근 자체가 어려워진다.

리눅스 기본 명령어

Terraform은 인프라를 코드로 만들지만, 운영하게될 대상은 리눅스 서버/컨테이너/VM

📂 파일/디렉토리 관련

pwd: 현재 위치 확인
ls: 현재 디렉토리 파일 목록
cd: 디렉토리 이동
mkdir: 디렉토리 생성
cp: 파일/디렉토리 복사
mv: 파일 이동/이름 변경
rm: 파일 삭제

📄 파일 내용 확인

cat: 파일 전체 출력
less: 스크롤하면서 보기
head: 앞부분 확인
tail: 뒷부분 확인 (로그 볼 때 많이 씀)
grep: 특정 문자열 검색

🔐 권한 관련

chmod: 권한 변경
chown: 소유자 변경

⚙️ 프로세스/시스템 상태

ps: 실행 중인 프로세스 확인
top / htop: CPU, 메모리 상태 확인

🌐 네트워크/요청

curl: HTTP 요청 보내기 (API 테스트할 때 자주 사용)

🧪 환경 변수

echo $PATH
env
💡 예시

# 로그 실시간 보기
tail -f app.log

# 로그에서 error만 찾기
grep "error" app.log

# 로그 실시간 + 필터
tail -f app.log | grep "ERROR"

👉 실제 서버 장애 확인할 때 거의 이 조합을 사용한다.

Mac을 쓰는 경우에도 위 같은 경우를 사용하다 보니 가볍게 다루어 보고 가려고 한다.

pwd   
/Users/jaehyungkim/Desktop/Swift/TuistGoolbitg/Real2/goolbitg-iOS

ls
현재 폴더 내부 파일들

cd
경로 이동

cat
concatenate 줄임말 -> 합치다  ->  여라 파일 내용 하나로 합치기

cat filename.txt                         : 파일 내용 출력
cat file1.txt file2.txt                 : 파일 내용 이어서 출력
cat -n filename.txt                     : 행 번호 붙여서 출력 
cat file1.txt file2.txt > new_file.txt : 파일 여러개 합쳐서 새로운 파일
...

less = 보여지는 만큼만 출력
head = 앞부분 부터 확인하는 명령어
tail = 뒷부분 부터 확인하는 명령어
grep = 특정 문자열 순환탐색
cp = 디렉토리 또는 파일 복사 명령어
cp_r = [복사 디렉토리] [대상 디렉토리]
mv = 파일 이동
rm = 파일 삭제
mkdir = 디렉토리 생성
chmod = 권한 변경 (파일, 디렉토리 권한)
chown = 권한 변경 (파일, 디렉토리 소유권 변경 ex: Group)
ps = 활성프로세스 출력
top or htop = OS 상태 하단 사진 참고

curl = Network Protocol 를통한 데이터 송수신 명령어
curl http://example.com
curl -O http://example.com/file.zip
curl -X POST -H "Content-Type: application/json" -d '{"name": "user", "age": 25}' 
curl -F "file=@/path/to/file.txt" 

환경 변수 확인
echo $PATH, env

@참고 자료 : https://monkeybusiness.tistory.com/645

네트워크 기초

좀 중요하다 결국 인프라이기에 보안, 통신 에 대한 이야기 이게 때문에 이를 좀 어느정도 잡아놔야 한다. VPC, subnet, route table, internet gateway, NAT gateway, security group 를 다루어 보고자 한다.

간단한 큰 그림

VPC: 네트워크 전체 땅
Subnet: 그 땅을 나눈 구역
Route Table: 이 구역의 트래픽이 어디로 갈지 정한 안내판
Internet Gateway: 인터넷과 직접 연결되는 출입문
NAT Gateway: 내부 서버가 바깥으로 나갈 때만 쓰는 대리 출구
Security Group / Firewall: 누가 들어오고 나갈지 통제하는 문지기

@참고자료 : https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html?utm_source=chatgpt.com

subnet 은 VPC 안의 IP주소 범위 route table 은 해당 subnet이나 gateway에서 나가는 트래픽 경로 결정 규칙들 InternetGateway 는 VPC와 인터넷 사이 통신 가능케 NAT Gateway는 private subnet 인스턴스가 외부로 나갈 수 있게 하되 외부에서 먼저 들어오는 연결 차단 Security Group은 연결된 리소스의 인바운드/아웃바운드 트래픽을 제어하는 가상 방화벽

VPC 란? (Virtual Private Cloud)

클라우드 안에 가상 네트워크 공간

IP 대역을 정한다
subnet을 할당한다.
route 연결
gateway 연결

InternetGateWay

VPC의 구성요소로써 VPC와 인터넷간에 통신을 할 수 있게 만들어주는 역할 출입문

외부 사용자가 접근해야 하는 리소스가 있을 때 필요함!
subnet의 route table에도 인터넷 방향 경로가 있어야 함

subnet 이란?

네트워크 안에 네트워크
VPC 안에서 나눈 작은 IP 주소 범위 why? -> 바로 옆으로 전달해도 될때 구지 구지 큰 범위 벗어난후 전달할 필요가 없음 ex) 배송: 도봉구 -> 노원구

서울시 도봉구 배송 출발 -> 서울 중앙 센터 -> 노원구 센터
서울시 도봉구 배송 출발 -> 노원구 센터

Public Subnet?

인터넷에서 직접 접근 가능한 리소스
외부에서 접근이 가능한 네트워크영역
subnet -> RoutingTable(인터넷 게이트웨이로)

Private Subnet?

인터넷에서 직접 접근되면 안 되는 리소스
외부에서 다이렉트로 접근이 불가능한 네트워크 영역
해당 서브넷에 위치한 리소스들은 외부와의 연결이 불가능

why?

public subnet에는 internet gateway 경로를, private subnet에는 NAT gateway 경로
즉 보안

Route Table 이란

말 그대로 “이 subnet에서 나가는 패킷을 어디로 보낼지” 정한 규칙표 AWS는 route table을 VPC의 traffic controller라고 표현한다. 서브넷 혹은 게이트웨이를 통해서 네트워크 트래픽이 어디로 향하는지에 대해 결정

라우팅 규칙은 목적지 주소에 따른 Next Hop을 지정
10.0.0.0/16 -> local 같은 VPC 내부 통신
0.0.0.0/0 -> igw 인터넷으로 보냄
0.0.0.0/0 -> nat NAT를 통해 외부로 보냄

서브넷 5개, 기본 라우팅 테이블 1개, 사용자 지정 라우팅 테이블 3개가 포함된 VPC

네트워크 문제의 절반은 route에서 난다.

통신이 안 될 때는 거의 항상 아래 순서로 보자

같은 VPC/대역인가?
route가 맞나?
보안 정책이 막고 있나?

NAT Gateway ( 주소 변환 NAT )

NAT: 사설 네트워크에 속한 여러 개의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위함
- 기본적으로 내부에서 시작한 연결의 응답만 돌아오게 하는 구조

private subnet 안의 서버가 외부 인터넷이나 외부 서비스로 나갈 수만 있게 해 주는 장치 즉 외부에서 먼저 연결 시도 불가

Firewall이 뭔가 (방화벽)

정의된 규칙에 따라 네트워크 트래픽을 허용하거나 차단하는 보안 시스템 Cloudflare는 이를 신뢰 영역과 비신뢰 영역 사이에 놓여 트래픽을 통제하는 장치

Security Group은 뭐가 다른가

AWS Security Group은 VPC 리소스에 붙는 가상 방화벽 인바운드와 아웃바운드 규칙을 설정하고, 소스/대상, 포트 범위, 프로토콜을 지정 허용된 연결의 응답 트래픽은 별도 규칙 없이도 돌아온다. 어떤 계층의 어떤 서버끼리 말하게 할지 정하는 정책

과정

VPC 하나 생성
public subnet 2개 생성
private subnet 2개 생성
Internet Gateway 연결
public subnet route table은 IGW로 연결
NAT Gateway는 public subnet에 둠
private subnet route table은 NAT로 연결
ALB는 public subnet
App 서버는 private subnet
DB는 private subnet
Security Group으로 ALB → App, App → DB만 허용

로드 밸런서가 뭘까?

들어오는 요청을 여러 서버로 나누자

예시 Example.com 접속! -> 서버가 1대가 아닌 3대로

why?

서버 한대가 죽어도 동작
사용자 수가 많아져도 나눠 처리
서비스 앞단을 하나의 점으로 통일

온프레미스는 뭘까?

회사가 소유한 물리적인 서버실, 네트워크 장비, 스토리지 같은 자체 인프라 환경 그럼 AWS는..? -> 클라우드

서버를 public subnet에 두면 인터넷인가?

떙

route table은 VPC의 traffic controller

route 규칙이 subnet이나 gateway의 트래픽이 어디로 갈지 결정

인터넷 게이트웨이는 VPC route table에서 인터넷으로 향하는 트래픽의 대상(target) 이 됨

라우팅 규칙으로 결정되는거지 public subnet의 유무가 아님!

서버가 어떤 subnet에 있든, 그 subnet이 연결된 route table에 인터넷 방향 경로가 있어야 인터넷으로 나갈 수 있다.

VPC에 Internet Gateway가 연결되어 있어야 함
그 subnet의 route table에 0.0.0.0/0 -> Internet Gateway 경로가 있어야 함

subnet의 route table에도 인터넷 방향 경로가 있어야 함

0.0.0.0/0 -> igw-xxxx

목적지가 어디든(0.0.0.0/0)
모르면 인터넷 게이트웨이로 보내라

ALB 가 뭐지?

Application Load Balancer 클라이언트의 단일 진입점 역할 애플리케이션 계층 트래픽을 여러 대상, AZ(가용영역)으로 분산 웹 서비스 앞에서 HTTP/HTTPS 요청을 받아서 뒤쪽 서버들로 나눠주는 로드밸런서

사용자가 브라우저로 https://myservice.com 접속
ALB가 요청을 받음
뒤에 있는 앱 서버 여러 대 중 하나로 전달

ALB는 public subnet App 서버는 private subnet DB는 private subnet

CIDR 이란

IP 주소 범위를 표현하는 방법 10.0.0.0/16 처럼 적음 10.0.0.0 이 주소 /16 은 앞 16비트가 네트워크 구간

IPv4 주소는 총 32bit

/16이면 앞 16비트가 네트워크
/24면 앞 24비트가 네트워크
남은 비트는 호스트에

VPC = 큰 땅
CIDR = 땅의 주소 범위
subnet CIDR = 땅을 잘라 나눈 구획 주소 범위

공인 IP / 사설 IP

공인 IP

전 세계적으로 유일하게 식별되는 주소 인터넷에서 직접 라우팅될 수 있는 주소

사설 IP

내부망용 주소 인터넷 공용 라우팅에 직접 쓰이지 않는다. 사설 IP는 내부 네트워크에서만 쓰는 주소다. RFC 1918에서 대표적인 사설 IPv4 대역은 아래 3개다.

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

왜 사설 IP를 쓰냐

인터넷에 연결되는 모든 장비에 공인 IP를 다 줄 수는 없다. IPv4 주소는 한정되어 있고, 내부 시스템은 인터넷에서 직접 접근될 필요가 없는 경우도 많다. 내부 시스템은 사설 IP를 쓰고, 외부와 통신이 필요할 때는 NAT 같은 방식으로 나가게 만든다.

VPC 에선?

VPC 내부 EC2는 기본적으로 사설 IP를 가진다. public subnet에 있는 인스턴스는 경우에 따라 공인 IP를 추가로 받을 수 있지만 내부 통신 자체는 여전히 사설 IP 중심으로 이뤄진다

App ↔ DB 통신: 사설 IP
외부 사용자 ↔ ALB: 공인 IP 또는 퍼블릭 엔드포인트

Port란 무엇인지

한 컴퓨터 안에서 어떤 서비스/프로세스에게 트래픽을 보낼지 구분하는 번호 네트워크 연결이 시작되고 끝나는 가상 지점

IP 주소 = 어느 집인지
포트 번호 = 그 집의 몇 번 방인지

예를 들어 서버 IP가 10.0.1.15여도,

22: SSH
80: HTTP
443: HTTPS
3306: MySQL
5432: PostgreSQL
6379: Redis
8080: 웹 애플리케이션

한눈으로 봐보자

[사용자 브라우저]
        |
        |  HTTPS 443
        v
   [ALB / Load Balancer]
        |
        |  HTTP 80 or HTTPS 443
        v
   [App Server 1]
   [App Server 2]
        |
        |  DB Port 3306 or 5432
        v
      [DB]

VPC (10.0.0.0/16)
├─ Public Subnet A (10.0.1.0/24)
│   ├─ ALB
│   └─ NAT Gateway
│
├─ Public Subnet B (10.0.2.0/24)
│   └─ ALB
│
├─ Private Subnet A (10.0.10.0/24)
│   └─ App Server 1
│
├─ Private Subnet B (10.0.20.0/24)
│   └─ App Server 2
│
└─ Private DB Subnet (10.0.30.0/24)
    └─ DB

App Server (Private Subnet)
   -> Route Table
   -> NAT Gateway (Public Subnet)
   -> Internet Gateway
   -> Internet

마무리 하면서

자자 네트워크 아직 끝이 아니에욧

WebView로 이미지를 보내야 할 때, 어떤 방식이 제일 괜찮을까?

Tue, 31 Mar 2026 06:19:39 GMT

WebView로 이미지를 보내야 할 때, 어떤 방식이 제일 괜찮을까?

Base64에서 시작해서 Blob, 청크 분할, 그리고 256KB까지 이번에 WKWebView 안으로 이미지를 전달해야 하는 일이 있었다.

처음엔 단순하게 생각했다.

"Swift에서 이미지 고르고, WebView로 넘기면 끝 아닌가?" 그런데 막상 구현을 시작해보니 생각보다 고려할 게 많았다.

어떤 방식이 제일 단순한가
보안상 부담이 없는가
이미지가 많아지면 버틸 수 있는가
웹이 앱 구현에 너무 강하게 묶이지는 않는가

이번 글은 그 과정을 정리한 기록이다.

결론부터 말하면, 이번 조건에서는 Base64 data URL로 시작해서, 최종적으로는 base64 청크 분할 전송 + 웹에서 Blob 재조립 방식으로 정리했고, 청크 크기는 256KB가 가장 적절했다.

문제 상황

출발점은 아주 단순했다. 지인에게서 이런 질문을 받았다.

*"WebView로 이미지를 보내야 하는데, 어떤 방식이 좋을까?"*

즉, 네이티브(iOS/Swift)에서 이미지 선택 그 이미지를 WebView 안의 웹으로 전달 웹에서 렌더링하거나, 이후 서버 업로드에 활용 즉 핵심은 네이티브 -> 웹 이미지 전달 방식이다.

가장 먼저 떠오른 방법: Base64

이건 구조가 단순하다.

Swift에서 이미지를 Data로 읽고 base64EncodedString()으로 문자열로 바꾸고 웹에 전달해서 img src="data:image/...;base64,..."로 붙이면 된다 Swift 쪽 흐름은 대략 이랬다.

guard let data = try? await item.loadTransferable(type: Data.self) else {
    continue
}

let contentType = item.supportedContentTypes.first?.preferredMIMEType ?? "image/jpeg"
let base64 = data.base64EncodedString()
let dataURL = "data:\(contentType);base64,\(base64)"

window.receivePickedImages = function(images) {
  images.forEach((image, index) => {
    const img = document.createElement("img");
    img.src = image.dataUrl;
    img.alt = `picked-${index}`;
    grid.appendChild(img);
  });
};

이 방식의 장점은 명확하다.

구현이 제일 쉽다
디버깅이 쉽다
적은 수의 이미지 테스트에는 충분하다

단점...

base64는 원본보다 크기가 커진다
data: URL 문자열이 너무 길어진다
긴 문자열이 JS 상태나 DOM 쪽에 남는다
이미지 수가 많아질수록 부담이 커진다

즉, 작게 테스트할 땐 좋지만, 대량 이미지 전달 구조로는 불안하다는 느낌이었다.

이쯤에서 지인이 이런 이야기를 했다.

"보안 때문에 Base64는 어렵지 않나?"

정확히 말하면, Base64는 암호화가 아니라 단순 인코딩이다. 즉 그 자체가 보안을 제공하는 방식은 아니다.

하지만 실제 구현 관점에서는 충분히 부담이 생긴다.

원본 이미지가 긴 문자열 형태로 남고
data: URL로 그대로 DOM에 들어가고
디버깅이나 로깅 과정에서 노출되기 쉬워지기 때문이다
그래서 여기서부터 생각이 바뀌었다.

"그렇다면 최종적으로 웹에서는 문자열이 아니라 이미지 객체를 다루게 하면 어떨까?"

Blob

핵심 아이디어는 단순하다.

웹이 최종적으로 필요한 건 이미지 데이터, 웹 안에서 Blob을 만들고 URL로 렌더링하면 되지 않을까?

웹 쪽 개념은 이런 형태다.

const blob = new Blob(chunks, { type: mimeType });
const blobUrl = URL.createObjectURL(blob);
img.src = blobUrl;

최종 렌더링은 data: URL이 아니라 blob: URL
긴 문자열을 그대로 DOM에 박지 않아도 됨
웹이 최종 표시 책임을 갖게 됨

하지만 여기서 바로 다음 질문이 생긴다.

"Blob을 만들기 위한 원본 바이트를 Swift에서 웹으로 어떻게 넘길 것인가?"

즉 Blob은 좋은데, 결국 Swift -> WebView 전달 경로를 설계해야 했다.

사실 커스텀 스킴도 생각했다 여기서 한 번쯤은 WKURLSchemeHandler 같은 커스텀 스킴 방식도 떠오른다.

예를 들면 웹에는 이런 URL만 넘기고

app-image://image/123/original

실제 이미지 바이트는 네이티브가 직접 공급하는 구조다.

이 방식은 성능만 놓고 보면 상당히 매력적이다.

웹에서는 그냥 URL처럼 다룰 수 있고 JS 브리지로 큰 바이너리를 직접 넘길 필요가 적고 구조적으로 효율적이다 하지만 이번에는 이 방향을 최종 선택지로 두고 싶지 않았다.

이유는 하나였다.

웹이 이미지 URL 해석 자체를 앱 구현에 의존하면 안된다.

커스텀 스킴은 결국 앱 쪽 구현에 강하게 묶인다. 즉 웹만 따로 떼어놓고 생각했을 때 독립성이 떨어진다.

그래서 이번엔 커스텀 스킴 대신, 웹이 최종적으로 Blob을 만들고, 앱은 그걸 위한 운반 역할만 하는 구조로 정리하기로 했다.

[UInt8] 배열 JSON 방식도 해봤다 Blob으로 가는 중간 단계에서 처음엔 Data를 [UInt8] 배열로 바꿔서 JSON으로 넘기는 방식도 생각했다.

예를 들면 이런 느낌이다.

{
  "bytes": [137, 80, 78, 71, ...]
}

바이트 배열을 넘기고 웹에서 Uint8Array로 복원하면 끝 그런데 이 방식은 생각보다 비효율적이었다.

이유는 간단하다.

원래 바이트 하나는 그냥 1바이트인데, JSON에서는 숫자 문자열로 표현된다.

예를 들어:

[137, 80, 78, 71] 이 경우 실제 바이너리는 4바이트지만, JSON 표현은 숫자 문자열 + 쉼표 때문에 훨씬 커진다.

즉:

바이트 하나가 숫자 문자열이 되고 구분자까지 붙고 전체 payload 크기가 크게 불어난다 그래서 이 방식은 버리고, 그 대신 base64 청크를 웹으로 넘긴 뒤, 웹에서 Blob을 재조립하는 방식으로 바꾸었다.

base64 청크 분할 전송 + 웹 Blob 재조립

현재 샘플에서 최종적으로 정리한 방식은 이렇다.

Swift에서 이미지 원본을 Data로 읽는다
한 번에 통째로 보내지 않는다
일정 크기로 청크를 나눈다
각 청크를 base64 문자열로 인코딩한다
JSON payload로 WebView에 전달한다
웹에서 청크를 다시 Uint8Array로 복원한다
모든 청크를 모아 Blob을 만든다
최종적으로 blob: URL로 렌더링한다

struct BlobTransferChunker {
    struct Payload: Sendable {
        let jsonString: String
    }

    static func makePayloads(
        id: String,
        mimeType: String,
        data: Data,
        width: Int,
        height: Int,
        chunkSize: Int
    ) -> [Payload] {
        let totalChunks = max(1, Int(ceil(Double(data.count) / Double(chunkSize))))
        var payloads: [Payload] = []
        payloads.reserveCapacity(totalChunks)

        for chunkIndex in 0..



이 payload를 반복해서 웹으로 넘긴다.

let payloads = BlobTransferChunker.makePayloads(
    id: id,
    mimeType: mimeType,
    data: data,
    width: width,
    height: height,
    chunkSize: chunkSize
)

for payload in payloads {
    let script = "window.receiveImageChunk(\(payload.jsonString));"

    _ = try await webView.callAsyncJavaScript(
        script,
        arguments: [:],
        in: nil,
        contentWorld: .page
    )
}

웹에서는 청크를 받아서 다시 조립한다.

function decodeBase64ToUint8Array(base64) {
  const binary = atob(base64);
  const bytes = new Uint8Array(binary.length);

  for (let i = 0; i < binary.length; i += 1) {
    bytes[i] = binary.charCodeAt(i);
  }

  return bytes;
}

그리고 모든 청크가 모이면 Blob을 만든다.

const blob = new Blob(entry.chunks, { type: mimeType });
const blobUrl = URL.createObjectURL(blob);
img.src = blobUrl;
이 방식의 장점과 단점
장점

[UInt8] 숫자 배열 JSON보다 payload 효율이 좋다
최종 렌더링은 blob: URL이라 data: URL보다 낫다
커스텀 스킴 없이도 동작한다
mixed content를 민감하게 보는 상황에서도 시도할 수 있다

단점

여전히 JS 브리지로 큰 payload를 여러 번 넘긴다
base64 인코딩/디코딩 비용이 있다
구조가 Base64 직행보다 복잡하다
커스텀 스킴보다 효율적인 구조는 아니다
즉, 이 방식은 “가장 빠른 방식”이라기보다
이번 제약 안에서 가장 현실적인 타협점에 가깝다.


그럼 청크는 몇 KB로 자르는 게 좋을까?

너무 작으면:

payload 수가 너무 많아진다
JS 호출 횟수가 늘어난다

너무 크면:

한 번에 넘기는 문자열이 무거워진다
브리지 부담이 커진다
그래서 여기서는 말로만 판단하지 않고
아예 테스트 코드를 추가해서 비교해보기로 했다.

비교 대상은 아래 세 개였다.

128KB
256KB
512KB

그리고 기준값(base)은 256KB로 잡았다.
테스트 코드 작성

핵심은 100장의 synthetic image data를 기준으로
payload 생성 비용을 비교하는 것이다.

@Test func benchmarkBase64BlobChunkSizesFor100Images() async throws {
    let imageCount = 100
    let syntheticImageSize = 1 * 1024 * 1024
    let imageData = Self.makeSyntheticImageData(byteCount: syntheticImageSize)
    let images = Array(repeating: imageData, count: imageCount)
    let chunkSizes = [128, 256, 512].map { $0 * 1024 }
    let baselineChunkSize = 256 * 1024

    let results = chunkSizes.map { chunkSize in
        Self.runBenchmark(images: images, chunkSize: chunkSize)
    }

    guard let baseline = results.first(where: { $0.chunkSize == baselineChunkSize }) else {
        Issue.record("Missing 256KB baseline result")
        return
    }

    print("=== Blob Chunk Benchmark (100 images) ===")
    print("Synthetic image size per item: \(syntheticImageSize) bytes")
    print("Base chunk size: \(baseline.chunkSize / 1024)KB")
}
테스트 조건은 아래와 같다.
이미지 수: 100
이미지 크기: 장당 1MB
비교 대상: base64 청크 -> JSON payload 생성 비용
측정 결과
=== Blob Chunk Benchmark (100 images) ===
Synthetic image size per item: 1048576 bytes
Base chunk size: 256KB
chunk=128KB elapsed=320.24ms payloads=800 jsonChars=139888800 vsBase=1.02x
chunk=256KB elapsed=313.60ms payloads=400 jsonChars=139850000 vsBase=1.00x
chunk=512KB elapsed=395.63ms payloads=200 jsonChars=139829800 vsBase=1.26x
결과 해석
이 결과를 보면 꽤 재미있다.

128KB
payload 수가 많다 (800)
시간은 나쁘지 않다
하지만 기준값인 256KB보다 아주 약간 느리다
256KB
payload 수와 브리지 부담 사이 균형이 가장 좋았다
이번 테스트에서는 가장 빠른 값이었다
512KB
payload 수는 가장 적다 (200)
그런데 한 번에 넘기는 문자열이 너무 커진다
결과적으로 오히려 더 느렸다

즉, 이번 조건에서는

"청크를 크게 잡으면 더 빠를 것이다"

라는 생각은 X
브리지 호출 수만 줄인다고 해결되는 게 아니라,
각 payload가 너무 커지면 오히려 손해라는 걸 확인할 수 있었다.

Base64 data: URL

가장 단순함
적은 수의 이미지에는 괜찮음
하지만 보안/대량 전송 관점에서는 부담


커스텀 스킴

성능상으로는 매력적임
다만 앱 의존도가 커짐




[UInt8] 숫자 배열 JSON
아이디어는 단순했지만 payload 효율이 나빴음




base64 청크 분할 전송
웹에서 Blob 재조립
청크 크기는 256KB




마무리 해보시면서

처음엔 그냥
"이미지를 WebView에 전달하면 되겠네"

정도로 생각했던 문제였는데,
실제로는 단순 전달 문제가 아니라 아래가 한꺼번에 걸려 있었다.


성능
보안
앱 의존도
웹 구조
대량 이미지 처리

이번에 정리한 방식이 절대적인 정답은 아니다.
하지만 이번 조건에서는 충분히 납득 가능한 선택지였다.
다음엔 이 흐름을 바탕으로 아래도 비교해보면 재미있을 것 같다.


웹이 직접 



로 파일을 가지는 구조
네이티브가 이미지 소유권을 계속 갖는 구조... 이방식이 결국 최종 채택되었지만
오늘은 여기까지



Image Cache - Disk, Memory Storage
Thu, 15 Jan 2026 10:50:48 GMT
시작하기에 앞서

이번시간엔 Disk, Memory 캐시에 핵심 포인트를 정리해 보려고 합니다.

목표


네트워크 요청 횟수를 줄이기
이미지 로딩 체감을 개선하기
앱 종료 이후에도 캐시를 유지
메타데이터를 갱신하여 회신화 하기


Memory Storage

NSCache 기반의 인메모리 캐시 방식
앱 종료 시 사라지며, 가장 빠른 조회 경로 사용
I/O 비용이 매우 적기 때문에 디코딩 이후 이미지를 바로 반환하기에 적합
totalCostLimit 기준으로 시스템에서 자동 제거 -> 메모리 압박 상황관리
NSCache`는 LRU에 가까운 방식으로 정리됨
비용 기준으로 메모리 압박을 완화

public init(totalCostLimit: Int = 64 * 1024 * 1024) {
    self.cache = NSCache()
    self.cache.totalCostLimit = totalCostLimit
}
Disk Storage

FileManager 기반의 디스크 캐시
앱 종료 후에도 유지됨 -> 재실행 시에도 캐시가 남음.
I/O가 상대적으로 부담됨 -> 메모리 캐시 miss 시의 2차 레이어로 사용
디스크 용량 / 유통기한 기준으로 정리하여 캐시의 용량 관리

private struct LastPath {
    static let data = ".data" // 이미지 데이터
    static let metadata = ".meta.json" // 갱신정보들
}
public var filenameSafeHash: String {
    let data = Data(rawValue.utf8)
    let digest = SHA256.hash(data: data)
    return digest.map { String(format: "%02x", $0) }.joined()
}
디스크 저장 구조

baseURL 하위에 SHA256 해시 파일명으로 저장
이름에서 "/" 등과같은 문자에 의한 경로 손상 방지, 길이 제한 등의 의한 이유


.data는 이미지 원본 데이터
.meta.json은 CacheMetadata를 JSON으로 저장

Metadata
public struct CacheMetadata: CacheSerializer {
    public let originalUrlString: String
    public let createdDate: Date
    public var eTag: ETagCache?
    public var accessCount: Int
    public var lastAccessTime: Date
    public var lastModified: Date?
}

디스크 캐시에서 접근 정보를 기록하여 pruning 기준으로 사용됩니다.
마지막 접근 시간과 접근 횟수는 LRU, 유통기한을 통해 정리할때 활용됩니다.

접근 정보 갱신

디스크에서 읽어올 때마다 touch()를 호출합니다.
횟수를 통해 덜 썻는지 구분하기 위함.


accessCount와 lastAccessTime을 최신화하여 LRU 기준을 유지합니다.public mutating func touch() {
  accessCount += 1
  lastAccessTime = Date()
}


Disk Read/Write 포인트

read 시 metadata.touch()로 접근 정보를 갱신합니다.
write 시 data + metadata를 함께 기록합니다.
요청마다 접근시간/횟수를 업데이트하여 LRU 판단 근거로 사용합니다.

private func readEntry(for key: CacheKey) -> CacheEntry? {
    // ... load data/metadata
    metadata.touch()
    // ... re-save metadata
    return CacheEntry(data: data, metadata: metadata)
}
메모리 히트 시 메타데이터 업데이트

메모리 히트는 디스크를 즉시 쓰지 않고, DiskAccessRecorder에 쌓아둡니다.
기본 5초 디바운스로 모아서 disk.touch(keys)를 호출합니다.
앱이 백그라운드로 가는 시점에는 즉시 flush()로 반영합니다.

public func get(_ key: CacheKey) async -> CacheEntry? {
    if let entry = await memory.get(key) {
        Task { await accessRecorder.record(key) }
        return entry
    }
    // ...
}
func record(_ key: CacheKey) {
    pending.insert(key)
    scheduleFlushIfNeeded()
}
Pruning (가지치기)

오래된 항목 제거 후, 크기 제한 초과 시 LRU 순으로 제거합니다.

if now.timeIntervalSince(item.lastAccessTime) > ageLimit {
    try? fileManager.removeItem(at: item.dataURL)
    try? fileManager.removeItem(at: item.metaURL)
}

...

for item in items where totalSize > diskLimit {
    try? fileManager.removeItem(at: item.dataURL)
    try? fileManager.removeItem(at: item.metaURL)
    totalSize -= item.size
    removed += 1
}
캐시 저장 시점

Memory hit: 즉시 반환합니다.
Disk hit: 메모리에 올려둔 뒤 반환합니다.
Network hit: 메모리와 디스크에 모두 기록합니다.

캐시 흐름

1차로 메모리 캐시를 조회합니다.
메모리 miss일 경우 디스크 캐시를 조회합니다.
디스크 hit면 메모리에 다시 올립니다. ( 승격 ) 그 후 반환합니다.
디스크 miss이면 네트워크 요청 후 두 캐시에 모두 저장합니다.
메모리 hit는 디스크 메타데이터를 즉시 쓰지 않고 모아둔 후 정리합니다.

다이어그램

마치며

이번엔 저번편에 이어서
좀더 구현쪽에 가깝게 정리를 해보았습니다.
전체를 설명하기 보단 핵심 설명과, 흐름을 다시한번 자세히 정리하는게
좋을 것 같다는 생각이 들었어서 이번편은 여기서 마무리 지어보오록 하겠습니다.
모두 고생 하셨습니다.




Image Cache - 개념편
Thu, 01 Jan 2026 17:17:40 GMT
들어가기에 앞서

해당 편은 이미지 캐시에 대한 이야기를 다루고자 합니다.

Cache

자주 사용하는 데이터, 값을 복사해 놓는 임시 장소 


iOS 에서 캐싱 방식
- Disk

구현: FileManager로 파일 저장/읽기, (메타데이터 JSON/DB로 관리 가능)

특징


( Caches / Documents / App Group )에 저장 → 앱 종료/재실행 후에도 유지
용량이 비교적 크고 대용량 데이터에 유리
I/O 비용이 꽤 큼 -> Memory보다 느림



장점


재실행 후에도 캐시가 남아서 네트워크/처리 비용 절감
메모리 압박과 무관하게 비교적 안정적으로 유지
이미지/비디오 등 큰 데이터 캐싱에 적합
App Group 쓰면 앱+위젯 / 익스텐션 공유 가능



단점


읽기/쓰기 시 디스크 I/O → 빈번하면 성능 저하(스크롤 끊김 등)
정리 정책 필요(용량 제한, 만료 시간, LRU prune) 안 하면 계속 쌓임
메타 갱신(접근 시간 기록 등)을 자주 하면 write 폭증 가능
암호화/백업 제외 등 고려




- Memory

구현: NSCache, URLCache(HTTP 캐시), 또는 직접 메모리 딕셔너리(+eviction)

특징


RAM에 저장 → 앱 종료 시 휘발
접근이 빠름(디스크 대비) → UI 유리
시스템이 메모리 압박 상황이 발생하면 자동으로 비울 수 있음



장점


빠른 캐시
스크롤/재사용 뷰에서 유리
NSCache는 시스템이 필요하면 알아서 지움 (크래시 위험 감소)




단점


앱 꺼지면 사라짐
메모리 용량이 작고 변동적이라 항상 남아있다는 보장 없음
큰 데이터(원본 이미지 Data)를 많이 올리면 메모리 폭증 위험


NSCache


key-value 형태
시스템 메모리 자동관리
딕셔너리 처럼 Key 값을 복사해서 가져오는 형태가 아님
Key 객체 참조를 그대로 사용
Value 가 사라지면 알아서 사라짐




만들어볼 캐싱 그림

                    싱글톤 구조인 매니저
                           ↓
            사용자 요구 (메모리, 디스크, 둘다, 안함)
                           ↓
                     둘다에 경우 승격구조 
     ( 메모리 탐색 없으면 -> 디스크 탐색 -> 적중시 메모리 승격 )
( 승격후 디스크 메타 데이터 반영 ( 일정시간 지난 후 혹은 백그라운드 진입 )
                           ↓
                      리사이징 여부
                           ↓
                         이미지
승격에 대한 이야기

메모리에 캐싱을 하게 되면 일단, 시스템에서 공간이 부족하거나 하였을때
알아서 제거를 해줍니다. 이는 사용자가 다른 앱으로 활동을 할때에
메모리 할당 용량이 줄어들게 되는 구조인거죠. ( 앱을 껏을때도 )


만약, 메모리에 올린후 디스크에 반영하지 않았다면
찾지 못하여 새로 API 를 요청해야 합니다.


그렇다면, 디스크에서 찾았다면요?
사용자가 UI에서 유리할 수 있도록 메모리로 승격을 하는 구조가 되죠.

디스크 비움에 대한 기준

고려해봐야 할 사항중
디스크 이야기를 뺄 수가 없을것 같군요


메모리에서 내려온 이미지를 위해 디스크를 활용하게 될텐데
그렇다면 디스크는 언제 제거해야 할까요?

LRU - Least Recently Used

여러가지 방법이 존재하겠으나
이번 시간에는 LRU 방식을 사용해 보려고 합니다.


이름을 해석하면
가장 오래 안쓴것 이죠.
오래 참조하지 않았으니 그만큼 사용자에겐 관심이 없다는 뜻 즉
그 기준으로 제거해 보려고 합니다.

메모리로 승격후 디스크반영

위에서 언급했듯이 결국 디스크에 사용했음을 기록해야합니다.
고민해 봐야 할 부분이죠. 왜냐...


I/O 부담이 있으니 디스크 기록 타이밍을 생각해봐야 하기 때문이죠.

시간 방식

이 부분은 이번 파트에선
사용자가 사용한 시점 기준 특정초까지 담아두었다
한번에 반영하는 구조를 구성해보려 합니다.

ETag

모든 서버는 아니지만, 서버 입장에서도 리소스를 아끼기 위해
Etag 라는것을 응답헤더에 달아준다는 사실을 알고 계셨나요?

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"

위와 같은 형태로 값을 서버에서 내려주게 되는데
이 값을 저장해 두었다가 서버에게

If-None-Match: ""

같은 형태로 보내게 된다면
304 - Not Modified 값을 주게 됩니다.
즉 저희는 캐시값을 그대로 쓸 수 있으며, 서버도 리소스를 아낄수 있게 되죠.

[참조문헌-1_ETag] (https://developer.mozilla.org/ko/docs/Web/HTTP/Reference/Headers/ETag)
last-modified

모든 서버가 ETag를 주지 않듯이 이친구도 마찬가지 입니다만
Etag 대신 last-modified를 사용하는 서버도 있답니다.

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

위와 같은 형태로 서버가 값을 주는데
날짜 형식이 서버마다 다를까 조사해 보았으나

GMT
그리니치 표준시. HTTP 날짜는 현지 시각이 아닌, 언제나 GMT로 표현합니다

라고 적혀 있기에 충분히 활용해 보면 좋을 것 같습니다.

참조문헌-2_last-modified
파일명 고려사항

/, ?, :, &, %, 유니코드 등 일부 파일명으로써 문제가 발생할 수 있는 상황
파일이름이 무지막지하게 긴 경우
파일명 유출

SHA256

해시함수
길이가 고정된 256비트 -> 32바이트 구조


특징
고정 길이
해시함수니 같은 인풋은 같은 아웃풋 형태
역으로 해석 불가
이름 충돌 방지 ( 아예 안나는건 아님 확률이 극악 )






위 SHA256 해싱을 통해 이름을 16진수 형태로 바꾸어 연결하여
사용해 보겠습니다.

GitHub

참고로 이미 프로젝트는 만들어 놓은 상태입니다.
계속 디벨롭 해봐야 할 것 투성이지만
미리 보고 싶으신분들은 아래 링크를 타시면 되겠습니다.

GitHub 먼저 볼래요 - SimpleImageCacheSwift
마무리하면서

이번시간은 개념 뼈대와 흐름을 적어 보었습니다.
고려 사항들을 꼭 같이 고민해 주셨으면 합니다.
생각보다 생각할 부분들이 많더라구요.
특히 메모리 승격 부분이 저에게 있어선 좀 난제 였던 것 같습니다.
디스크 I/O 부담을 줄여보겠다고 고민을 많이 했어서


아무튼 오늘도 고생하셨습니다.
새해복 많이 받으세요 다들!




AlarmKit 
Tue, 23 Dec 2025 14:26:36 GMT
들어가기에 앞서

사실 해당 API 는 문서에서 제공하는 데모코드 마저도
삭제된 메서드가 존재하는 만큼 불안정한 API라
언제 다루어 볼까 싶었는데
iOS 26.1 이 넘어가면서 부턴 괜찮아지는 것 도 같아서 다루어 볼까 합니다.

AlarmKit Docs
AlarmKit_LittleTale

AlarmKit

알람킷 이름부터가 네. 알람을 울릴수 있는 도구이죠.
중요한 부분은 알람은 현재상태(예를들어 무음)를 무시하고 실행 된다는 점이 중요하죠
아이폰에서 전부터 사용하던 시계의 알람 생태계를 접근할 수 있다가
좀 더 맞는 표현인 것 같습니다.

NSAlarmKitUsageDescription

알람킷도 권한이 필요합니다.
알람 예약 기능이 필요한 이유에 대해서 NSAlarmKitUsageDescription 키를 추가해야 합니다.

NSAlarmKitUsageDescription
Alarm Manager

모든 알림을 중앙에서 관리하는 객체입니다.


권한관리
알림관리 (stop, start)

// 스케줄 등록
let _ = try await AlarmManager.shared.schedule(id: id, configuration: config)

// 알람 관리
if (isCancelled) {
    try AlarmManager.shared.cancel(id: alarmID) // 취소
} else {
    if (isResumed) {
        try AlarmManager.shared.resume(id: alarmID) // 재게
   } else {
        try AlarmManager.shared.pause(id: alarmID) // 중단
   }
}

// 권한 관리
private func checkAndAuthorize() async throws -> Bool {
    var currentValue = false
    switch AlarmManager.shared.authorizationState {
    case .notDetermined:
        let status = try await AlarmManager.shared.requestAuthorization()
        currentValue = status == .authorized
    case .denied:
        currentValue = false
    case .authorized:
        currentValue = true
    @unknown default:
        fatalError()
    }

    return currentValue
}
AlarmConfiguration

알람의 스케줄, 속성, Intent 를 정의하는 하나의 구조체 입니다.

let attributed = AlarmAttributes(
    presentation: presentation,
    metadata: MyAlarmMetaData(method: .wakeUp),
    tintColor: .orange
)

let schedule = Alarm.Schedule.fixed(store.state.scheduleDate)

let config = AlarmManager.AlarmConfiguration(
    schedule: schedule,
    attributes: attributed,
    secondaryIntent: OpenAppIntents(id: id)
)
AlarmPresentation

알람의 상태에 따른 UI 구성을 제어합니다.

문서
let alert = AlarmPresentation.Alert(title: "Eggs are ready!",
stopButton: AlarmButton(text: "Stop", textColor: .blue, systemImageName: "stop.circle"),
secondaryButton: AlarmButton(text: "Repeat", textColor: .blue, systemImageName: "repeat"),
secondaryButtonBehavior: .countdown)

let countdown = AlarmPresentation.Countdown(title: "Eggs are cooking")

let paused = AlarmPresentation.Paused(title: "Timer paused",
resumeButton: AlarmButton(text: "Resume", textColor: .blue, systemImageName:"play.circle"))

let presentation = AlarmPresentation(alert: alert, countdown: countdown, paused: paused)
실사용시
 /// The appearance of the stop button.
@available(*, deprecated, message: "This property is not used anymore and will be removed.")
public var stopButton: AlarmButton

/// Creates an alert for an alarm.
/// - Parameters:
///   - title: The title of the alert.
///   - stopButton: The end button for an alarm.
///   - secondaryButton: The customizable second button for an alarm.
///   - secondaryButtonBehavior: The defined behavior of the secondary button.
@available(iOS, deprecated: 26.1, message: "stopButton is deprecated and will no longer be used")
public init(title: LocalizedStringResource, stopButton: AlarmButton, secondaryButton: AlarmButton? = nil, secondaryButtonBehavior: AlarmPresentation.Alert.SecondaryButtonBehavior? = nil)
 let alert = AlarmPresentation.Alert(
     title: "일어나",
     secondaryButton: AlarmButton(
     text: "Go To App",
        textColor: .blue,
        systemImageName: "app.fill"
    ),
    secondaryButtonBehavior: .custom
)
// 위는 UI 구성 요소
let presentation = AlarmPresentation(alert: alert)
Alert

알림:
간단한 알림 기능을 제공합니다.

WWDC25 Code
 func  scheduleAlertOnlyExample () { 
    let alertContent =  AlarmPresentation.Alert ( title: "Wake Up" , stopButton: .stopButton) 

    let attributes =  AlarmAttributes  ( presentation : AlarmPresentation (alert: alertContent), 
                                                  tintColor: Color.accentColor ) 

    let alarmConfiguration =  AlarmConfiguration (schedule: .twoMinsFromNow, attributes: attributes) 

    scheduleAlarm(id: UUID (), label: "Wake Up" , alarmConfiguration: alarmConfiguration) 
}
카운트 다운 알람의 경우

반복 알림 기능이 존재합니다.

 // 시작값 10 초 -> 다시하기 하면 10
let countDownDuration = Alarm.CountdownDuration(preAlert: 10, postAlert: 10)

let countDownPresentation = AlarmPresentation.Countdown(
    title: "10Sec",
    pauseButton: AlarmButton(
        text: "pause",
        textColor: .red,
        systemImageName: "pause.fill"
    ),
)

let pausedPresentation =  AlarmPresentation.Paused(
    title: "Paused",
    resumeButton: AlarmButton(
        text: "resume",
        textColor: .green,
        systemImageName: "Play.fill"
    )
)

let presentation = AlarmPresentation(alert: alert, countdown: countDownPresentation, paused: pausedPresentation)

// 위는 UI 구성 요소        
let attributed = AlarmAttributes(presentation: presentation, metadata: MyAlarmMetaData(method: .wakeUp), tintColor: .orange)

let id = UUID()

let config = AlarmManager.AlarmConfiguration(
    countdownDuration: countDownDuration,
    attributes: attributed,
    secondaryIntent: OpenAppIntents(id: id)
)
MetaData

앱과 위젯 확장 간에 공유되는 활동 속성의 메타데이터 
즉, 앱에서 특정 데이터를 실어 보내주고 싶을때 담아서 보내줄 수 있습니다.

 import AlarmKit

// 앱과 위젯 확장 간에 공유되는 활동 속성의 메타데이터 구조.
struct MyAlarmMetaData: AlarmMetadata {

    let createdAt: Date
    let method: Method?

    init(method: Method? = nil) {
        self.createdAt = Date.now
        self.method = method
    }

    enum Method: String, Codable {
        case wakeUp

        var icon: String {
            switch self {
            case .wakeUp: "flame.fill"
            }
        }
    }
}

// 위젯에서
    func getIcon(attributes: AlarmAttributes) -> some View {
        Group {
            if let icon = attributes.metadata?.method?.icon {
                Image(systemName: icon)
            } else {
                EmptyView()
            }
        }
    }
현재 알람상황 추적

앱측에서 알람 상태를 감시할 수가 있습니다.
다만, 앱이 실행중 일 때만 알림을 받을 수가 있습니다.

    private func observeAlarms() {
        Task {
            for await incomingAlarms in alarmManager.alarmUpdates {
                updateAlarmState(with: incomingAlarms)
            }
        }
    }

    private func updateAlarmState(with remoteAlarms: [Alarm]) {
        Task { @MainActor in

            // Update existing alarm states.
            remoteAlarms.forEach { updated in
                alarmsMap[updated.id, default: (updated, "Alarm (Old Session)")].0 = updated
            }

            let knownAlarmIDs = Set(alarmsMap.keys)
            let incomingAlarmIDs = Set(remoteAlarms.map(\.id))

            // Clean-up removed alarms.
            let removedAlarmIDs = Set(knownAlarmIDs.subtracting(incomingAlarmIDs))
            removedAlarmIDs.forEach {
                alarmsMap[$0] = nil
            }
        }
    }



Alarm Setting
Timer Setting







마무리 하며

핵심적인 부분을 정리 해 본 시간인 것 같습니다.
사실 말로만 쓱 보면 이해가 잘 안되는 스타일이라 저는
Git Hub에다가 어떻게 하면 커스텀 할 수 있는지 


라이브 엑티비티 처음해보는데 어떻게 사용하는지 간단하게 다루어 놓았습니다.
한번 사용해보시길 바라면서
다음시간에 뵙겠습니다. 감사합니다. :)




iOS 26 SwiftUI UIWindow 터치문제
Sun, 07 Dec 2025 07:40:02 GMT
Passthrough UIWindow using SwiftUI in iOS 26

한참 SwiftUI에서 발생한 이슈중 하나
UIWindow를 통해 SwiftUIView를 또 하나 띄었을때 위로 띄운 윈도우의
View가 터치가 되지 않는 이슈가 있었습니다.

관련 링크 - stackoverflow

저도 이글을 보고 문제를 해결했었는데
꽤 재밌는 문제가 생겨서 공유해 보고자 합니다.

Custom 한 Path 를 사용하면 문제가 재발

네. 제목 그대로 직접만든 Path를 clipShap를 하게 되면
다시 터치가 되지 않는 이슈가 발생합니다.

Window 코드 살펴보기
final class UIPassthroughWindow: UIWindow {

    private var encounteredEvents = Set()

    override final func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
        // If we don't have a root controller or it does not have a view we are done and can exit
        guard let rootViewController, let rootView = rootViewController.view else { return nil }

        guard let event else {
            assertionFailure("hit testing without an event is not supported at this time")
            return super.hitTest(point, with: nil)
        }

        // We next check the base implementation for a hitView, if none is found we are done
        guard let hitView = super.hitTest(point, with: event) else {
            // defensive clearing of encountered events
            encounteredEvents.removeAll()
            return nil
        }
        defer {
            print (encounteredEvents)
            print(rootView.layer.hitTest(point)?.name)
        }
        if encounteredEvents.contains(event) {
            encounteredEvents.removeAll()
            return hitView
        } else if #available(iOS 26, *), rootView.layer.hitTest(point)?.name == nil {

            encounteredEvents.insert(event)
            return hitView
        } else if hitView == rootView {
            return nil
        } else if #available(iOS 18, *) {
            encounteredEvents.insert(event)
            return hitView
        } else {
            return hitView
        }
    }
}

iOS 26 코드만 요약하면
터치 좌표의 뷰중에서 Layer에 이름이 달려 있지 않다면, 터치할 뷰다. 
라는 이야기 입니다.


네, 현재 SwiftUI 에서 UIWindow를 다루는 행위는 사실 도박에 가깝습니다.
왜일까요?

DTS 엔지니어 - Apple 답변

 A couple people have asked what implementation details were being depended on which has now resulted in broken behavior in the implementation.


Mainly, the assumption that, when you embed a SwiftUI view in a UIHostingController, the SwiftUI Views are represented as a UIView hierarchy. That behavior is not guaranteed for any particular SwiftUI View type, and should not be depended on.


There are also assumptions about how UIHostingController's view implements hitTest, which is also not guaranteed.


So, again, my recommendation for anyone interested in implementing this sort of behavior is to please file an enhancement request using Feedback Assistant.
--Greg

번역본

 몇몇 분들이 구현 세부 사항에 의존한 결과 현재 구현에서 오류가 발생하고 있다고 문의하셨습니다.
주요 원인은 SwiftUI 뷰를 UIHostingController에 임베드할 때 SwiftUI 뷰가 UIView 계층 구조로 표현된다는 가정입니다. 


이 동작은 특정 SwiftUI 뷰 유형에 대해 보장되지 않으며, 의존해서는 안 됩니다.
 또한 UIHostingController의 뷰가 hitTest를 구현하는 방식에 대한 가정도 존재하는데, 이 역시 보장되지 않습니다.


따라서, 이러한 동작을 구현하려는 분들께 다시 한번 권고드립니다: Feedback Assistant를 통해 기능 개선 요청을 제출해 주시기 바랍니다.

즉, 현재 방식은 도박입니다.

그렇다면 다른 대안이 있을까요?
저도 찾아보고 있지만 현재 마땅한 방법이 없어서
아래와 같은 방법으로 문제를 일단 막을 수는 있습니다.

1. Background 에 눈에 안보이는 정도의 색을 입힌다.
func asRoundedCorner(radius: CGFloat, corners: UIRectCorner) -> some View {
        self
            .clipShape(RoundedCornerShape(corners: corners, radius: radius))
            .background {
                Color.black.opacity(0.000001)
            }
위와같이 직접만든 Shape등 터치가 안될때 컬러를 뒤에 두어주면 터치가 또 됩니다. 놀랍죠?
2. UIView 를 가정하지말고 달아주자...
struct WindowTouchView: UIViewRepresentable {

    func makeUIView(context: Context) -> UIView {
        let view = UIView()
        view.backgroundColor = .clear
        return view
    }

    func updateUIView(_ uiView: UIView, context: Context) {
        guard let layer = uiView.layer.sublayers?.first else { return }
        layer.frame = uiView.bounds
    }
}

func asRoundedCorner(radius: CGFloat, corners: UIRectCorner) -> some View {
        self
            .clipShape(RoundedCornerShape(corners: corners, radius: radius))
            .background(WindowTouchView())

} 
위와 같이 UIView를 달아주니 또 정상동작 합니다.
다만, SwiftUI 에서 UIKit 를 이런 경우에도 달아주는게 성능상이나, 구조적으로
보기 않좋은 부분이라 생각이 듭니다.
마무리 하며

한참 이슈가 많은 우리 iOS26 참 재밌는 것 같습니다.
하루 빨리 다른 대안이나, 새로운 API 라도 iOS 측에서 제공해주길 바랄 뿐입니다.


여담 - Reactor Kit + AlarmKit 과, WebRTC 중에 무엇이 먼저 나갈지 고민입니다.
감사합니다.




WebRTC - 개념- 1편
Sun, 30 Nov 2025 13:20:10 GMT
OSI 7 Layer


네트워크 구조를 학습하신 분이라면 지겨운 계층인
OSI 7계층입니다.


이중에서 3번째 계층인 네트워크 계층에 집중해보도록 하겠습니다.

Network Layer

물리계층부터 간단히 올라가 보죠


물리계층

리피터, 같은 장비들의 물리적인 계층
전기적인, 빛 등의 선로


데이터 링크 계층

브릿지 같은 ( 물리적이긴 해요 )
Mac 주소할당, 약간 허브라고 생각하시면 됩니다.




대망의 네트워크 계층
쉽게 라우터 계층이라고 전 부르기도 하는데요
아래서부터 회선 깔고 주소, 오류 잡고, 그 신호들이 결국
멀리 멀리 중계가 가야 합니다.


문제는 뭐냐? 회선들을 여러개 깔았을때 어디가 최단 루트인지,
멀리 신호를 보낼때 손실을 어떻게 해결하는지 알아야 겠죠?


이때 라운터가 중폭(신호)도 하고, 어디 어디 라우터를 찍어야 최단 루트이다.
같은 작업을 합니다. 이정도 아시면 사실 개념은 완벅합니다.
즉, 라우팅이 핵심이다.

라우팅

전기적 신호를 결정하는것이 라우팅


IP를 가지고 경로를 결정하는데, IP는 MAC주소와는 다르게 변경이 가능

즉 고유한 IP를 부여해서 고정해야 함


다만 보안에 있어서, 유출되면 위험해지기 때문에 이를 숨겨서 관리해야함 - private
공유기같은 것들은 public IP를 통해 관리를 하지만, 
폰, 컴퓨터같은 경우 고유의 IP를 가지게됨.

WebSocket

서버와, 클라이언트가 있을때 3-way-handshaking 을 통해 소통하는 HTTP의 TCP 통신 방식에선
요청 → 요청확인 → 전송준비(받을 수 있는 상태인지 체크) → 전송 → 받음을 확인하게 flag 과정
UDP: 요청 → 전송


TCP vs UDP
서버 상태 체크, 받을수 있는 상태인지 체크 등의 체크 과정이 있는걸 TCP
없는걸 UDP


TCP 기반으로 웹소켓을 만듬
매번 요청/응답의 대한 방식을 매번 하는 것이 아닌 한번만 이루어 지도록 함
HTTP 헤더가 여러번 생기는 방식이 아니다보니, 즉 포장이 여러개가 아니니 무게가 줌
요청할때만 보낼 수 있는게 아닌 서버에서 먼저 푸시가 가능한 형태




포장이 가벼워 짐이 이해가 안갈 수도 있기에 보충설명
HTTP 는 무상태성이죠 즉, 매번 상태를 달아서 요청을 보냅니다.


누가 보낸 건지 → Cookie, Authorization
어떤 형식으로 받고 싶은지 → Accept, Accept-Language
이 리소스가 어디인지 → Host, 요청 라인(GET /something)
캐시, 압축, 인코딩 등 옵션 → Cache-Control, Content-Encoding …
브라우저 정보 → User-Agent

즉:

일반 HTTP 방식

매 요청마다: HTTP 헤더 + TCP 헤더 + IP 헤더 + ...



WebSocket 방식

처음 1번: HTTP 헤더 + TCP 헤더 + IP 헤더

이후 계속: WebSocket 프레임 헤더(작음) + TCP 헤더 + IP 헤더





WebRTC 개념

중간에 존재하는 서버가 없는 개념
peer - to - peer 통신 방식 ( 단말간 통신 )
클라이언트 쪽에서 어떤 통신을 원하는지 서버에 알려줘야함 ex) VoiceCall, Video
처음에는 서버 중개자가 존재
서로다른 공유기, 통신망(유플,kt 등), 사내망 등에 의해 직접적인 IP를 모름
NAT 를 뚫어야 함
외의 네트워크는 밖에서 못 들어오도록 막음
서로의 IP를 직접 교환하면 보안에 취약함으로, signaling Server 가 관리해야함
PeerConnection 이라고 함 이를 → 끝나면 진짜 서버없이 연결되는 구조



NAT (Network Address Translation)

Router 는 퍼블릭 IP와 각각의 단말 Private IP를 가짐
단말들에게 Public IP를 알려주는 것을 말하는 용어

Stun Server

Stun Server
Public IP 를 저장하고 있고, Peer간 직접 연결을 막는 등의 라우터의 제한을 결정하는 프로토콜
클라 → StunServer 에게 접근 가능한지 요청하는 구조



Turn Server

돌려주는 서버
P2P연결 시도후 실패한 경우 Turn 서버에서 중개하여 다시 연결할 수 있도록 하는 역활

signaling Server

누가 누구랑 어떻게 연결할지에 대한 정보(offer/answer/ICE 등)를 전달해주는 중간 서버
단순 시작전 매칭 연결 도와주는 서버


마치면서

이번편은 개념적인 부분을 다루었습니다.
다음편은 핵심 API들 간단히 살펴보고
그 다음편은 WebRTC 를 통해 통신하는 작업을 해보도록 하겠습니다.
감사합니다.




Match Zoom Transition - 3 - Navigation
Mon, 17 Nov 2025 10:44:29 GMT
들어가기에 앞서

1편부터 보고오셔야 합니다.

전편에서 빠진 이야기

정작 트렌지션을 만들어 놓고, 적용을 안했더라구요....
어떻게 해야 저 트랜지션을 적용할 수 있는지 간단하게
정리 해보도록 하겠습니다....!

modalPresentationStyle

ViewController는 모달 프레젠테이션 스타일을 정의할 수 있습니다.
이중에서 저희는 .custom으로 적용하겠습니다.

vc.modalPresentationStyle = .custom

커스텀이라고 하였으니 저희가 만든 트랜지션을 적용해야 합니다.

testDelegate = CustomZoomTransition(referenceView: testButton) { [weak self] in
    guard let self else { return }
    testDelegate = nil
}

vc.transitioningDelegate = self.testDelegate

마지막으로 모달로 프레젠트하면 됩니다.

self.present(vc, animated: true)
네비게이션에서도 동작하게..!

저번에 구성하였던 애니메이터로 돌아가 봅시다.

CustomDismissalTransitionAnimator: UIViewControllerAnimatedTransitioning

...

func animateTransition(using ctx: UIViewControllerContextTransitioning)
...

위 함수는 저희가 구성을 하지 않았었는데 구성해보겠습니다.

/// 인터랙티브 디스미스(모달방식)를 사용하므로 이 메서드에서는 별도 애니메이션을 수행하지 않습니다. 단, 네비게이션 방식에선 사용됩니다.
    func animateTransition(using ctx: UIViewControllerContextTransitioning) {
        // 네비 pop일 때 호출되는 곳
        guard
            let fromVC = ctx.viewController(forKey: .from),
            let toVC   = ctx.viewController(forKey: .to)
        else {
            ctx.completeTransition(false)
            return
        }

        let container = ctx.containerView
        // pop일 땐 toVC를 아래에 깔아야 함
        container.insertSubview(toVC.view, belowSubview: fromVC.view)

        // referenceView의 최종 위치
        let targetFrame = container.convert(referenceView.bounds, from: referenceView)

        let duration = transitionDuration(using: ctx)

        UIView.animate(withDuration: duration,
                       delay: 0,
                       options: [.curveEaseInOut],
                       animations: { [weak self] in
            guard let self else { return }
            // fromVC.view를 버튼 위치만큼 줄이기
            fromVC.view.frame = targetFrame
            fromVC.view.layer.cornerRadius = self.referenceView.layer.cornerRadius
        }, completion: { finished in
            // 끝나면 pop 완료
            let cancelled = ctx.transitionWasCancelled
            if !cancelled {
                fromVC.view.removeFromSuperview()
            }
            ctx.completeTransition(!cancelled)
        })
    }
UINavigationControllerDelegate 적용
final class CustomZoomTransition: NSObject, UINavigationControllerDelegate
 ...
 func navigationController(_ navigationController: UINavigationController, animationControllerFor operation: UINavigationController.Operation, from fromVC: UIViewController, to toVC: UIViewController) -> (any UIViewControllerAnimatedTransitioning)? {
        switch operation {
        case .push:
            return presentingTransitionAnimator
        case .pop:
            return dismissalTransitionAnimator
        default:
            return nil
        }
    }

    deinit {
        print("** DEAD \(Self.description())")
    }
// 만약 네비게이션 으로 진행하려면
        self.navigationController?.delegate = self.testDelegate
        self.navigationController?.pushViewController(vc, animated: true)

마무리 하며

다음 시간은 WEB RTC 입니다.
얏호 얏호
다음시간에 뵙겠습니다. 감사합니다.




Match Zoom Transition - 2 : dismiss
Thu, 06 Nov 2025 15:34:07 GMT
들어가기에 앞서

이전편을 보고 오셔야 합니다.

뒤로가기에 대한 애니메이션
/// 디스미스 시 사용할 애니메이터 객체를 반환
    func animationController(
        forDismissed dismissed: UIViewController
    ) -> UIViewControllerAnimatedTransitioning? {
        print("\(#function)")
        return dismissalTransitionAnimator
    }

위의서 반환하는 뒤로가기 애니메이터를 제작하겠습니다.

초기화 구성
final class CustomDismissalTransitionAnimator: NSObject {
    private let config: CustomZoomTransitionConfiguration
    private let referenceView: UIView

    // MARK: - 초기화
    init(config: CustomZoomTransitionConfiguration, referenceView: UIView) {
        self.config = config
        self.referenceView = referenceView
    }
}

주입 받아야 하는 멤버는 다음과 같습니다.


컨피규레이션 
돌아갈 타겟 뷰


구성해야 하는 것은 다음과 같습니다.


UIViewControllerContextTransitioning

UIViewControllerContextTransitioning

전편에서도 잠깐 나왔었는데 이번편에서 설명하겠습니다.


UIViewControllerAnimatedTransitioning 를 채택한 클래스 즉 객체에게
지금 전환 상황이 어떤지 알려주는 객체입니다. 프로토콜로 구성되있습니다.

-- 구성 --
@MainActor public protocol UIViewControllerAnimatedTransitioning : NSObjectProtocol {

    func transitionDuration(using transitionContext: (any UIViewControllerContextTransitioning)?) -> TimeInterval

    func animateTransition(using transitionContext: any UIViewControllerContextTransitioning)

    /// A conforming object implements this method if the transition it creates can
    /// be interrupted. For example, it could return an instance of a
    /// UIViewPropertyAnimator. It is expected that this method will return the same
    /// instance for the life of a transition.
    @available(iOS 10.0, *)
    optional func interruptibleAnimator(using transitionContext: any UIViewControllerContextTransitioning) -> any UIViewImplicitlyAnimating

    optional func animationEnded(_ transitionCompleted: Bool)
}

-- 집중 --
func animateTransition(using transitionContext: UIViewControllerContextTransitioning)

위 메서드를 통해 해당 객체를 받아올 수 있습니다.

지금 뷰컨과 다음 뷰컨을 알수가 있다. (Optional)
let fromVC = transitionContext.viewController(forKey: .from)
let toVC   = transitionContext.viewController(forKey: .to)
애니메이션을 올릴 뷰를 반환 받을 수 있다.
let containerView = transitionContext.containerView


디스미스 전환시 소요되는 시간 적용
func transitionDuration(
        using transitionContext: UIViewControllerContextTransitioning?
    ) -> TimeInterval {
        print("\(#function)")
        return config.transitionDuration
    }
모달 방식에서의 인터렉티브 애니메이션
이해해보기

사용자가 뷰를 제스처를 통해서 이전 뷰 위치로 돌아가는 형태입니다.
햇갈리시면 않되는 것이 제스처 도중에는 Dismiss가 된 상황이 아닙니다.
즉 시작하는순간 해당 함수에서 최종으로 내릴건지 다시 원위치 할지를 판단해야 합니다.

UIViewControllerInteractiveTransitioning 구현
startInteractiveTransition( _:) 을 통해
func startInteractiveTransition(_ transitionContext: UIViewControllerContextTransitioning) {
    print(#function)

    // 1. 전환에 참여하는 뷰컨을 가져온다.
    //   사라질(from) 쪽을 기준으로 (사용자가 드래그 하는 뷰)
    guard let fromVC = transitionContext.viewController(forKey: .from) else {
        return
    }

    // 2. 원래 뷰는 숨김 -> 안하면 돌아가는 애니메이션 중 기존뷰도 잠깐 보이다 사라짐
    fromVC.view.isHidden = true

    // 3. 전환은 항상 containerView 위에서 일어나야 함.
    let containerView = transitionContext.containerView

    // 4. 애니메이션이 시작될 위치/크기 = 현재 from 뷰의 프레임
    let startPoint = CGPoint(x: fromVC.view.frame.minX,
                             y: fromVC.view.frame.minY)
    let startSize = fromVC.view.frame.size

    // 5. 실제로 움직일 임시 뷰(transitionView)를 만든다.
    //    - 시작 프레임은 from 뷰와 동일
    //    - 색상도 from 뷰와 맞춰서 자연스럽게
    //    - cornerRadius는 일단 0에서 시작
    let transitionView = UIView(frame: CGRect(origin: startPoint, size: startSize))
    transitionView.backgroundColor = fromVC.view.backgroundColor
    transitionView.layer.masksToBounds = true
    transitionView.layer.cornerRadius = 0
    containerView.addSubview(transitionView)

    // 6. 애니메이션이 끝났을 때 도달해야 하는 최종 프레임을 구한다.
    //    기준 뷰(referenceView)의 bounds를
    //    containerView 좌표로 변환해서 해당 위치로 가게 하는 구조.
    let finalFrame = containerView.convert(referenceView.bounds, from: referenceView)

    // 7. 스프링 애니메이션으로 뷰를 최종 위치로 늘리면서
    //    cornerRadius도 대상 뷰와 동일하게 맞춰준다.
    UIView.animate(withDuration: config.transitionDuration,
                   delay: 0,
                   usingSpringWithDamping: config.springWithDamping,
                   initialSpringVelocity: config.initialSpringVelocity,
                   options: [.beginFromCurrentState]) { [weak self] in
        guard let self else { return }

        transitionView.frame = finalFrame
        transitionView.layer.cornerRadius = referenceView.layer.cornerRadius
    } completion: { _ in
        // 8. 전환이 끝났다고 시스템에 알려준다.
        // transitionContext.completeTransition(!transitionContext.transitionWasCancelled)
        //    처럼 취소 여부를 반영해주는 게 안전하다.
        transitionContext.completeTransition(true)
    }
}
제스처에 따른 뷰 크기 위치 조작
// MARK: - 제스처 처리
    /// 프레젠트된 화면에서 팬 제스처를 감지해 이동/알파/디스미스를 제어
    @objc
    private func handlePanGesture(_ gesture: UIPanGestureRecognizer) {
        guard let presentedVC = presentationController?.presentedViewController,
              let container = presentedVC.view.superview else {
            return
        }

        guard let targetView = presentedVC.view else { return }

        switch gesture.state {
        case .began:
            targetView.layer.cornerRadius = 45
            // 1) 기존 뷰의 중앙, 포인트를 저장
            originalCenter = targetView.center
            originalAnchor = targetView.layer.anchorPoint

            // 2) 터치 지점을 뷰 좌표로
            let touchInView = gesture.location(in: targetView)

            // 3) anchorPoint로 바꿀 비율 (0~1)
            let newAnchor = CGPoint(
                x: touchInView.x / targetView.bounds.width,
                y: touchInView.y / targetView.bounds.height
            )
            // 0.5, 0.5 (중심) --> 드래그 앵커
            targetView.layer.anchorPoint = newAnchor

            // 4) anchorPoint를 바꾸면 position이 바뀌어버리니, 그만큼 보정
            let oldPos = targetView.layer.position
            print("began - oldPos: ", oldPos) // began - oldPos:  (220.0, 478.0)
            print("began - originalAnchor", originalAnchor) // began - originalAnchor (0.5, 0.5)
            print("began - newAnchor", newAnchor) // began - newAnchor (0.02727272727272727, 0.3158995815899582)

            let moveX = (newAnchor.x - originalAnchor.x) // 기준점x 0.47..만큼 왼쪽으로
            let moveY = (newAnchor.y - originalAnchor.y) // 기준점y 0.19..만큼 위로

            // px 로 전환
            let moveXPx = moveX * targetView.bounds.width
            let moveYPx = moveY * targetView.bounds.height

            let newPos = CGPoint(
                x: oldPos.x + moveXPx,
                y: oldPos.y + moveYPx
            )

            targetView.layer.position = newPos

        case .changed:
            let translation = gesture.translation(in: container)
            let dx = translation.x
            let dy = translation.y

            // 전체 이동 거리 (피타고라스)
            let distance = hypot(dx, dy)

            // 얼마나 줄일지
            let maxDrag: CGFloat = 300
            let progress = min(distance / maxDrag, 1)

            let minScale: CGFloat = 0.4
            let scale = 1 - (1 - minScale) * progress

            let scaleTransform = CGAffineTransform(scaleX: scale, y: scale)
            let translateTransform = CGAffineTransform(translationX: dx, y: dy)
            targetView.transform = scaleTransform.concatenating(translateTransform)

            // 투명도도 전체 거리 기준
            targetView.alpha = 1 - 0.4 * progress

        case .ended, .cancelled:
            // 원래대로
            let shouldDismiss = targetView.transform.ty > 150
            if shouldDismiss {
                presentedVC.dismiss(animated: true)
            } else {
                UIView.animate(withDuration: 0.2, animations: { [weak self] in
                    guard let weakSelf = self else { return }
                    targetView.transform = .identity
                    targetView.alpha = 1
                    // anchorPoint도 원래대로
                    targetView.layer.anchorPoint = weakSelf.originalAnchor
                    targetView.center = weakSelf.originalCenter
                    targetView.layer.cornerRadius = 0
                })
            }

        default:
            break
        }
    }

GitHub
Little-tale/SwiftAnimations

ZoomTransition 4번째 폴더

마치면서

이번 편은 정말 꽤 흥미로운 내용이였다고 생각합니다.
아직 끝이 아닌게
네비게이션 방식일땐 지금 같이 해두어도 동작을 안합니다.
다음편은 네비게이션 방식에서도 해보는것, 그리고, 그 다음편은 WebRTC 편을 다루어 보도록 하겠습니다.
감사힙니다.




Match Zoom Transition - 1 _ 개념 + 등장
Mon, 03 Nov 2025 13:25:02 GMT
Match Transition

WWDC2024-Match_Zoom_Transition
오늘은 아래와 같은 전환 애니메이션을 구성해 볼겁니다.
SwiftUI 에서도 가능합니다. 다만, SwiftUI는 자료가 많으니 UIKit를 통해 이를 구현해 보겠습니다.


iOS 18+

WWDC 영상의 방법은 iOS 18이상에 대한 이야기 입니다.
아직은 iOS 16이상인 기종이 꽤 존재 하기 때문에
간단히 다루고 미만 버전을 다루어 보겠습니다.

   private func nextView() {
        let vc = TestZoomNextViewController()
        if #available(iOS 18.0, *) {
            vc.preferredTransition = .zoom { [weak self] context in
                guard let self else { return nil }
                return testButton
            }
        }

        self.present(vc, animated: true)
    }

보시는 거와 같이
preferredTransition 의 zoom을 이용하여 간단하게 
UIKit 에서도 해당 애니메이션을 구현할 수 있습니다.


iOS 18 under

자 그럼 iOS 18 이하는 못하는 걸까요?
아뇨 구현은 가능합니다.



위 gif 처럼 비슷하게 구현이 가능합니다.

UIViewControllerTransitioningDelegate

A set of methods that vend objects used to manage a fixed-length or interactive transition between view controllers.
뷰 컨트롤러 간의 고정 길이 또는 대화형 전환을 관리하는 데 사용되는 객체를 벤더하는 일련의 방법입니다.


말이 참 어렵단 말이죠.
"이 뷰컨을 모달로 띄울 때, 어떤 애니메이션·제스처·레이아웃을 쓸지 정할께요"

Methods
animationController _presented
func animationController(
    forPresented presented: UIViewController,
    presenting: UIViewController,
    source: UIViewController
) -> UIViewControllerAnimatedTransitioning?

모달을 등장할때에 애니메이터를 반환합니다.

interactionControllerForPresentation
func animationController(
    forDismissed dismissed: UIViewController
) -> UIViewControllerAnimatedTransitioning?

프렌젠트에서 제스처를 제공할 애니메이터 반환 합니다.

animationController _dismiss
func animationController(
    forDismissed dismissed: UIViewController
) -> UIViewControllerAnimatedTransitioning?

dismiss 시에 사용할 애니메이터를 반환 합니다.

interactionControllerForDismissal
func interactionControllerForDismissal(
    using animator: UIViewControllerAnimatedTransitioning
) -> UIViewControllerInteractiveTransitioning?

드래그를 통한 제스처에 대한 뒤로가기 애니메이션 반환

presentationController
func presentationController(
    forPresented presented: UIViewController,
    presenting: UIViewController?,
    source: UIViewController
) -> UIPresentationController?

뷰 계층/딤뷰/코너/시트 높이 같은 레이아웃 관리 컨틀롤러를 반환합니다.


위의 메소드들을 통해서 위와 같은 Zoom Transition 을 구성해 보도록 하겠습니다.

CustomZoomTransitionConfiguration

기본제공되는 그런건 아닙니다.
애니메이션을 만들때에 사용할 기본적인 구조를 만들어 보겠습니다.

/// ZOOM 전환(프레젠트/디스미스) 시 사용되는 설정 값 모음
/// - 전환 시간, 스프링 파라미터
/// - 팬 제스처(양축) 기반 알파/디스미스 임계값 계산
struct CustomZoomTransitionConfiguration {
    // MARK: - 애니메이션 기본 파라미터
    /// 전환(프레젠트/디스미스)에 걸리는 총 시간
    let transitionDuration: TimeInterval
    /// 스프링 애니메이션의 감쇠 비율 --> (작을수록 더 출렁임)
    let springWithDamping: CGFloat
    /// 스프링 애니메이션의 초기 속도
    let initialSpringVelocity: CGFloat

    // MARK: - 팬 제스처 관련 파라미터
    /// 이 거리(픽셀) 이상 이동하면 디스미스 처리
    let panGestureDismissThreshold: CGFloat
    /// 팬 제스처 중 최소 알파 값
    let minAlphaDuringPan: CGFloat
    /// 이 거리까지 선형으로 알파가 감소 (0 → minAlphaDuringPan)
    let alphaRangeDistance: CGFloat

    init(
        transitionDuration: TimeInterval = 0.5,
        springWithDamping: CGFloat = 0.85,
        initialSpringVelocity: CGFloat = 0.8,
        panGestureDismissThreshold: CGFloat = 120,
        minAlphaDuringPan: CGFloat = 0.6,
        alphaRangeDistance: CGFloat = 160
    ) {
        self.transitionDuration = transitionDuration
        self.springWithDamping = springWithDamping
        self.initialSpringVelocity = initialSpringVelocity
        self.panGestureDismissThreshold = panGestureDismissThreshold
        self.minAlphaDuringPan = minAlphaDuringPan
        self.alphaRangeDistance = alphaRangeDistance
    }
}
CustomPresentingTransitionAnimator

자 이번엔 뷰가 등장할때에 대한 애니메이션을 정의 보고자 합니다.

final class CustomPresentingTransitionAnimator: NSObject {
    private let config: CustomZoomTransitionConfiguration
    private let referenceView: UIView
    private var transitionContext: UIViewControllerContextTransitioning?

    // MARK: - 초기화
    init(config: CustomZoomTransitionConfiguration, referenceView: UIView) {
        self.config = config
        self.referenceView = referenceView
    }
}
extension CustomPresentingTransitionAnimator: UIViewControllerAnimatedTransitioning {

    /// 프레젠트 전환에 소요되는 총 시간을 반환
    func transitionDuration(
        using transitionContext: UIViewControllerContextTransitioning?
    ) -> TimeInterval {
        print("\(#function)")
        return config.transitionDuration
    }

    /// 버튼 위치/ 크기에서 시작해 화면 전체로 확대되는 프레젠트 애니메이션.
    func animateTransition(
        using transitionContext: UIViewControllerContextTransitioning
    ) {
        print("\(#function)")
        guard let presentedViewController = transitionContext.viewController(forKey: .to) else {
            return
        }

        self.transitionContext = transitionContext

        let containerView = transitionContext.containerView

        // 배경 디밍 뷰를 준비하고 컨테이너에 추가
        let backgroundView = makeBackgroundView(in: containerView)

        // 최종 프레임과 버튼(referenceView)의 시작 프레임을 계산
        let finalFrame = containerView.bounds
        let refFrameInContainer = containerView.convert(referenceView.bounds, from: referenceView)

        // 프레젠트될 뷰를 초기 상태(작게/버튼 위치)로 설정
        let presentedView = presentedViewController.view!
        preparePresentedView(presentedView,
                             finalFrame: finalFrame,
                             refFrameInContainer: refFrameInContainer)

        // 컨테이너에 프레젠트 뷰를 추가합니다(디밍 뷰 위).
        containerView.addSubview(presentedView)

        // 확대 애니메이션
        animatePresentation(backgroundView: backgroundView,
                            presentedView: presentedView,
                            finalFrame: finalFrame,
                            transitionContext: transitionContext)
    }

    /// 프레젠트 애니메이션 종료 시 호출됩니다.
    func animationEnded(_ transitionCompleted: Bool) {
        print("\(#function)")
        transitionContext = nil
    }
}

private extension CustomPresentingTransitionAnimator {

    /// 컨테이너에 디밍(배경) 뷰를 생성/추가하고 반환
    func makeBackgroundView(in containerView: UIView) -> UIView {
        let backgroundView = UIView(frame: containerView.bounds)
        backgroundView.backgroundColor = containerView.backgroundColor
        backgroundView.alpha = 0
        containerView.addSubview(backgroundView)
        return backgroundView
    }

    /// 프레젠트될 뷰를 버튼 위치/크기에서 시작하도록 초기 상태를 설정
    /// - 최종 프레임, 버튼 프레임을 기반으로 스케일/센터/코너 라운드를 구성
    func preparePresentedView(_ presentedView: UIView,
                              finalFrame: CGRect,
                              refFrameInContainer: CGRect) {
        // 최종 프레임을 기준으로 레이아웃 설정
        presentedView.frame = finalFrame

        // 확대/축소 중 코너 라운드가 잘 보이도록 마스킹 활성화
        presentedView.layer.masksToBounds = true
        let referenceCorner = referenceView.layer.cornerRadius

        // 버튼 대비 전체 화면의 스케일 비율 계산
        let minScale: CGFloat = 0.001 // 0 스케일 방지
        let scaleX = max(refFrameInContainer.width / max(finalFrame.width, 1), minScale)
        let scaleY = max(refFrameInContainer.height / max(finalFrame.height, 1), minScale)

        // 스케일 상태에서 버튼 코너와 유사하게 보이도록 초기 코너 보정
        let effectiveScale = max(min(scaleX, scaleY), 0.001)
        let initialCorner = referenceCorner / effectiveScale
        presentedView.layer.cornerRadius = initialCorner

        // 버튼 중심 위치에서 작게 시작하도록 설정
        presentedView.transform = CGAffineTransform(scaleX: scaleX, y: scaleY)
        presentedView.center = CGPoint(x: refFrameInContainer.midX, y: refFrameInContainer.midY)
    }

    /// 디밍 알파/스케일/센터/코너 라운드를 애니메이션하여 화면 전체로 확대
    func animatePresentation(backgroundView: UIView,
                             presentedView: UIView,
                             finalFrame: CGRect,
                             transitionContext: UIViewControllerContextTransitioning) {
        UIView.animate(
            withDuration: config.transitionDuration,
            delay: 0,
            usingSpringWithDamping: config.springWithDamping,
            initialSpringVelocity: config.initialSpringVelocity,
            options: [.beginFromCurrentState]
        ) {
            backgroundView.alpha = 1
            presentedView.transform = .identity
            presentedView.center = CGPoint(x: finalFrame.midX, y: finalFrame.midY)
            presentedView.layer.cornerRadius = 0
        } completion: { _ in
            backgroundView.removeFromSuperview()
            transitionContext.completeTransition(transitionContext.transitionWasCancelled == false)
        }
    }
}
전환될 뷰컨을 반환받기
guard let presentedViewController = transitionContext.viewController(forKey: .to) else {
      return
 }

1편을 마치며

기본적인 개념과, 등장 애니메이션을 만들어 보았습니다.
다음 편은 사라질때에 대한 애니메이션을 구성해보겠습니다.




UITest
Mon, 27 Oct 2025 16:06:48 GMT
들어가기에 앞서

이전편 Unit Test를 보신후 참고하시면 좋습니다.

UITest

말 그래도 UI가 정상 동작하는가 즉
예측한 대로 동작하는가에 관한 자동화 테스트를 말함

Syntax
.accessibilityIdentifier(<#T##identifier: String##String#>)
   --- or ---
   accessibilityIdentifier = "Identifier"

위 같은 식별자를 통해 UI가 정상 동작하는지 테스트 하는 원리

XCTAssert

let app = XCUIApplication()

// okay button이 있는 경우 성공
XCTAssert(app.buttons["okay"].exists)

// "Hello World" 라는 문자열이 있는 경우 성공
XCTAssert(app.staticTexts["Hello World"].exists)

// 2초 내로 "TEST2" 라는 문자열이 보여지는 경우 성공
XCTAssert(app.staticTexts["TEST2"].waitForExistence(timeout: 2))

// image1 이라는 이미지가 있는 경우 성공
XCTAssert(app.images["image1"].exists, "There is no image1 image")

// 실패
XCTFail()
Action
let app = XCUIApplication()
app.buttons["button"].tap()
app.buttons["doubleTapButton"].doubleTap()

식별자를 통해 버튼을 찾고 액션을 준다.

let pointX = app.frame.width/2
let pointY = app.frame.height/2

let pointLocation = CGVector(dx: pointX, dy: pointY)
let normalizedLocation = app.coordinate(withNormalizedOffset: CGVector(dx:0, dy: 0))

let tapLocation = normalizedLocation.withOffset(pointLocation)
tapLocation.tap()

좌표를 통해 특정 지점을 탭 해도록 한다.

예시
import XCTest
@testable import Testable

@MainActor
final class TestableUITests: XCTestCase {

    override func setUpWithError() throws {
        // Put setup code here. This method is called before the invocation of each test method in the class.

        // In UI tests it is usually best to stop immediately when a failure occurs.
        continueAfterFailure = false

        // In UI tests it’s important to set the initial state - such as interface orientation - required for your tests before they run. The setUp method is a good place to do this.
    }

    override func tearDownWithError() throws {
        // Put teardown code here. This method is called after the invocation of each test method in the class.
    }

    func testTappedStartButton() {
        let app = XCUIApplication()
        let id = TestIdentifiers.contentViewStartButton.identifier
        let startButton = app.buttons[id]

        guard startButton.exists else {
            XCTFail("Lost Start Button")
            return
        }

        startButton.tap()
    }

    func testStartButtonExistsAndTap() {
        let app = XCUIApplication()
        app.launch()
        let startButton = app.buttons[TestIdentifiers.contentViewStartButton.identifier]
        XCTAssertTrue(startButton.waitForExistence(timeout: 3), "Start button should exist")
        startButton.tap()
    }

    func testSumTextExists() {
        let app = XCUIApplication()
        app.launch()
        let sumText = app.staticTexts[TestIdentifiers.contentViewSumText.identifier]
        XCTAssertTrue(sumText.waitForExistence(timeout: 3), "Sum label should exist")
    }

    func testStartThenSumChanges() {
        let app = XCUIApplication()
        app.launch()
        let startButton = app.buttons[TestIdentifiers.contentViewStartButton.identifier]
        let sumText = app.staticTexts[TestIdentifiers.contentViewSumText.identifier]

        XCTAssertTrue(startButton.waitForExistence(timeout: 3), "Start button should exist")
        XCTAssertTrue(sumText.waitForExistence(timeout: 3), "Sum label should exist")

        let initialValue = sumText.label
        startButton.tap()

        let predicate = NSPredicate { _, _ in sumText.exists && sumText.label != initialValue }
        let exp = expectation(for: predicate, evaluatedWith: nil, handler: nil)
        wait(for: [exp], timeout: 5.0)

        XCTAssertNotEqual(sumText.label, initialValue, "Sum label should change after loading numbers")
    }
}

추가설명
let p = NSPredicate { _, _ in sumText.exists && sumText.label != initialValue }

참 거짓 구분위한 객체 구성

expectation -> XCTestExpection

비동기 조건이 충족될 때가지 가디리는 방식
일정 시간 동안 재시도

let exp = expectation(for: predicate, evaluatedWith: nil, handler: nil)

Expection 정의

wait(for: [exp], timeout: 5.0)

5초까지 비동기(expectation) 종료를 대기

마무리 하며

이번엔 UITest를 다루어 보았습니다. 
사실 이것 외에도 더 많은 메서드나 방식이 존재하는데
그런 부분은 찾아보면서 하는게 더 맞는 방법인 것 같아
여기까지 정리 해보도록 하겠습니다.
아직 Testable 에 대해서 다루지 않아서 다시 다루긴 할 겁니다.

예고

다음 시간은 아마 Transition Animation 에 대해서 다루어 보도록 하겠습니다.
WWDC 2024 글을 참고할 예정이니 많은 관심 부탁 드립니다.




Unit Test
Mon, 20 Oct 2025 13:20:31 GMT
Unit Test

단위 테스트
특정 유닛이 정상 동작하는지 체크하기 위한 테스트

FIRST
- F ast

여러 테스트를 빠르게 동작하도록- I solated

독립적으로 진행되도록- R epeatable

반복적으로 가능하게- S elf-Automation

자동화- T imely

수정사항 발생시 수정사항에 대한 여파 확인


Given, When, Then
- Given

테스트 목적의 상황 설명 ex) 3 을 받고 난수 생성

- When

테스트 발생 시점 ex) 버튼 클릭 이벤트

- Then

예상결과, 결과 그 후이 처리



XCTest 메서드들

XCTAssertTrue(:) / XCTAssertFalse(:)
XCTAssertTrue(isEnabled)
XCTAssertFalse(items.isEmpty == false)

XCTAssertEqual(::) / XCTAssertNotEqual(::)
(Float/Double은 accuracy: 지원)


XCTAssertEqual(user.name, "Lee")
XCTAssertEqual(distance, 1.0, accuracy: 0.0001)

XCTAssertNil(:) / XCTAssertNotNil(:)
XCTAssertNil(cache["missing"])
XCTAssertNotNil(image)

XCTAssertGreaterThan(::) / XCTAssertLessThan(::)
> =, <= 도 각각 제공
XCTAssertGreaterThan(score, 80)
XCTAssertLessThan(latency, 100)

XCTAssertIdentical(::) / XCTAssertNotIdentical(::)
(두 객체 참조가 같은 인스턴스인지)
XCTAssertIdentical(a as AnyObject, b as AnyObject)

XCTFail(_:)
(명시적으로 실패 처리)
if unsupported { XCTFail("미지원 경로") }

XCTUnwrap(_:)
(옵셔널이 nil이면 즉시 실패)
let data = try XCTUnwrap(response.data)



테스트 해보기
NumberHelper (비즈니스 로직)
import Foundation

protocol NumberService: Sendable {
    func fetchNumbers() async throws -> [Int]
    func sumEvenNumbers(_ numbers: [Int]) -> Int
}

extension NumberService {
    func sumEvenNumbers(_ numbers: [Int]) -> Int {
        numbers.filter { $0 % 2 == 0 }.reduce(0, +)
    }
}

enum NumberServiceError: Error, LocalizedError {
    case network
    case malformed

    var errorDescription: String? {
        switch self {
        case .network: return "네트워크 오류가 발생했습니다."
        case .malformed: return "데이터 형식 오류가 발생했습니다."
        }
    }
}

final class TestableHelper: NumberService {

    // 임의의 딜레이
    private let delay: UInt64 = 700_000_000

    func fetchNumbers() async throws -> [Int] {
        try await Task.sleep(nanoseconds: delay)

        return (1...10).map{ _ in Int.random(in: 1...30) }
    }
}
XCTest 타겟 생성 및 연결, 코드

테스트 하고자할 프로젝트나 모듈에 AddTarget 을 진행후
아래와 같이 테스트 해보겠습니다.

import XCTest
@testable import Testable // 현재 프로젝트 ( 만약 Tuist 같은 멀티모듈 환경시 해당 모듈 ).

@MainActor
final class TestableTests: XCTestCase {
    // Test 대상
    private var service: NumberService!

    // 테스트에 필요한 설정값
    override func setUpWithError() throws {
        // Put setup code here. This method is called before the invocation of each test method in the class.
        try super.setUpWithError()
        self.service = TestableHelper()
    }

    // Test 마치며 정리할 것들 정리 -> 격리성 보장
    override func tearDownWithError() throws {
        try super.tearDownWithError()
        service = nil
    }


    /// func fetchNumbers() async throws -> [Int] Test Code
    func testFetchNumber() async throws {
        // given : 필요한 값 세팅
        // -> 현재는 없음

        // when : 테스트 코드 실행
        let number = try await service.fetchNumbers()

        // then : 결과 비교
        XCTAssertEqual(number.count, 10, "The number Count should be 10")
    }

    // sumEvenNumbers(_ numbers: [Int]) -> Int TestCode
    func testSumEvenNumbers() {
        // given None

        // when
        let result = service.sumEvenNumbers([1,2,3,4,5,5,6,7,8,9,10,20])

        // then
        XCTAssertEqual(result, 50, "The sum of even numbers should be 50")
    }

}
비동기 테스트
expectation(), fulfill(), wait()

충족되거나 시간 초과 까지, 둘 중 먼저 발생하는 시점까지 계속 진행
func testFetchCallBack() throws {
      let manager = FakeNetworkManager(mode: .success([1,2,3,4,5,6]), delay: 100_000) // much smaller
      let exp = expectation(description: "fetch Done") // 뭘 충족할지

      manager.fetchNumbers { result in
          let nums = try? result.get()
          XCTAssertEqual(nums, [1,2,3,4,5,6])
          exp.fulfill() // 충족함 
      }

      wait(for: [exp], timeout: 2.0)
  }


마무리 하며

오랜만에 다시 글을 올립니다.
개인사정으로 인해... 몇일간 맥북을 못 만지는 상황이 발생해서..!
다음시간에는 UITest 로 찾아 뵙겠습니다. 감사합니다.




RIBs - 뷰가 없는 RIB (3)
Wed, 01 Oct 2025 11:40:00 GMT
들어가기에 앞서

이번시간에는 저번시간에 이어서 프로젝트를 이어가 보곘습니다.
저번시간에 로그인 기능을 가지고 뷰를 가진 RIB 을 구성하였습니다.
이번에는 HomeRIB 과 RandomRIB 이 둘을 중계하는 Flow RIB을 구성 해보겠습니다. 

Home RIB

빠른 진행을 위해 UI는 간단하게 진행합니다.

HomeViewController
final class HomeViewController: UIViewController, HomePresentable, HomeViewControllable {

    weak var listener: HomePresentableListener?
    /// Root -> Login -> Name Label
    private let nameLabel = UILabel().after {
        $0.font = .systemFont(ofSize: 20, weight: .bold)
        $0.textColor = .black
        $0.translatesAutoresizingMaskIntoConstraints = false
    }

    private let backLoginButton = UIButton().after {
        $0.setTitle("Go Back", for: .normal)
        $0.setTitleColor(.red, for: .normal)
        $0.translatesAutoresizingMaskIntoConstraints = false
    }

    private let randomColorMoveButton = UIButton().after {
        $0.setTitle("NEXT", for: .normal)
        $0.setTitleColor(.black, for: .normal)
        $0.translatesAutoresizingMaskIntoConstraints = false
    }

    override func loadView() {
        super.loadView()
        self.view.backgroundColor = .blue
        setViewHierarchy()
        setUI()
        subscribe()
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        nameLabel.text = listener?.getName()
    }

    func pushViewController(_ viewController: ViewControllable) {
        self.navigationController?.pushViewController(viewController.uiviewController, animated: true)
    }

    func popViewController(animated: Bool) {
        self.navigationController?.popViewController(animated: animated)
    }
}

extension HomeViewController {

    private func setViewHierarchy() {
        view.addSubview(nameLabel)
        view.addSubview(backLoginButton)
        view.addSubview(randomColorMoveButton)
    }

    private func setUI() {
        NSLayoutConstraint.activate([
            nameLabel.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            nameLabel.centerYAnchor.constraint(equalTo: view.centerYAnchor),

            backLoginButton.topAnchor.constraint(equalTo: nameLabel.bottomAnchor, constant: 10),
            backLoginButton.widthAnchor.constraint(equalToConstant: 120),
            backLoginButton.heightAnchor.constraint(equalToConstant: 40),

            randomColorMoveButton.topAnchor.constraint(equalTo: backLoginButton.bottomAnchor, constant: 10),
            randomColorMoveButton.centerXAnchor.constraint(equalTo: backLoginButton.centerXAnchor)
        ])
    }
}

extension HomeViewController {

    private func subscribe() {
        backLoginButton.rx.tap
            .bind(with: self) { owner, _ in
                owner.listener?.goBackToLogin()
            }
            .disposed(by: rx.disposeBag)

        randomColorMoveButton.rx.tap
            .bind(with: self) { owner, _ in
                owner.listener?.moveToRandomView()
            }
            .disposed(by: rx.disposeBag)
    }
}

PresentableListener
protocol HomePresentableListener: AnyObject {
    func getName() -> String

    func goBackToLogin()

    func moveToRandomView()
}
Home Router
protocol HomeInteractable: Interactable, RandomListener {
    var router: HomeRouting? { get set }
    var listener: HomeListener? { get set }
}

protocol HomeViewControllable: ViewControllable {
    // TODO: Declare methods the router invokes to manipulate the view hierarchy.
    func pushViewController(_ viewController: ViewControllable)

    func popViewController(animated: Bool)
}

final class HomeRouter: ViewableRouter, HomeRouting {

    private let randomColorBuilder: RandomBuilder
    private var randomRouting: RandomRouting?

    // TODO: Constructor inject child builder protocols to allow building children.
    init(interactor: HomeInteractable,
         viewController: HomeViewControllable,
         randomColorBuilder: RandomBuilder
    ) {
        self.randomColorBuilder = randomColorBuilder
        super.init(interactor: interactor, viewController: viewController)
        interactor.router = self
    }

    func routeToRandomColorView() {
        let child = randomColorBuilder.build(withListener: interactor)
        attachChild(child)
        self.randomRouting = child
        viewController.pushViewController(child.viewControllable)
    }

    func backToHome() {
        guard let child = randomRouting else { return }
        viewController.popViewController(animated: true)
        detachChild(child)
        randomRouting = nil
    }
}

Home Interactor
protocol HomeRouting: ViewableRouting {
    // TODO: Declare methods the interactor can invoke to manage sub-tree via the router.
    func routeToRandomColorView()

    func backToHome()
}

protocol HomePresentable: Presentable {
    var listener: HomePresentableListener? { get set }
    // TODO: Declare methods the interactor can invoke the presenter to present data.
}

protocol HomeListener: AnyObject {
    // TODO: Declare methods the interactor can invoke to communicate with other RIBs.

    func didRequestLogin()
}

final class HomeInteractor: PresentableInteractor, HomeInteractable, HomePresentableListener {

    weak var router: HomeRouting?
    weak var listener: HomeListener?
    private let name: String

    // TODO: Add additional dependencies to constructor. Do not perform any logic
    // in constructor.
    init(presenter: HomePresentable, name: String) {
        self.name = name
        super.init(presenter: presenter)
        presenter.listener = self
    }

    override func didBecomeActive() {
        super.didBecomeActive()
        // TODO: Implement business logic here.
    }

    override func willResignActive() {
        super.willResignActive()
        // TODO: Pause any business logic.
    }

    func getName() -> String {
        return self.name
    }

    func goBackToLogin() {
        listener?.didRequestLogin()
    }

    func moveToRandomView() {
        router?.routeToRandomColorView()
    }

    func randomBack() {
        router?.backToHome()
    }
}

HomeBuilder
protocol HomeDependency: Dependency {
    // TODO: Declare the set of dependencies required by this RIB, but cannot be
    // created by this RIB.
}

final class HomeComponent: Component {

    // TODO: Declare 'fileprivate' dependencies that are only used by this RIB.

    let name: String

    init(dependency: HomeDependency, name: String) {
        self.name = name
        super.init(dependency: dependency)
    }
}

extension HomeComponent: RandomDependency {

}

// MARK: - Builder

protocol HomeBuildable: Buildable {
    func build(withListener listener: HomeListener, name: String) -> HomeRouting
}

final class HomeBuilder: Builder, HomeBuildable {

    override init(dependency: HomeDependency) {
        super.init(dependency: dependency)
    }

    func build(withListener listener: HomeListener, name: String) -> HomeRouting {
        let component = HomeComponent(dependency: dependency, name: name)
        let viewController = HomeViewController()
        let interactor = HomeInteractor(presenter: viewController, name: name)

        let randomBuilder = RandomBuilder(dependency: component)

        interactor.listener = listener
        return HomeRouter(interactor: interactor, viewController: viewController, randomColorBuilder: randomBuilder)
    }
}

자 저번 시간에 각각의 역활을 다루면서 하였기에 설명은 생략하겠습니다.
중요한 핵심은 뷰 이동을 수행하는 역활은 이친구가 하긴 합니다.
그 판단은 여기서 하지 않습니다. 

Random RIB

Rib 구성은 길어짐으로 생략하고 UI 만 작성해 놓겠습니다.
한번 직접 구성해 보시는 것을 추천합니다.

import UIKit
import RxSwift
import RxCocoa

final class RandomView: UIView {

    private let colorChangeButton = UIButton().after { b in
        b.setTitle("색상 바꾸기", for: .normal)
        b.setTitleColor(.cyan, for: .normal)
        b.backgroundColor = .lightGray
        b.titleLabel?.font = .boldSystemFont(ofSize: 24)
        b.translatesAutoresizingMaskIntoConstraints = false
    }

    private let backButton = UIButton().after {
        $0.setTitle("BACK", for: .normal)
        $0.backgroundColor = .lightGray
        $0.setTitleColor(.red, for: .normal)
        $0.translatesAutoresizingMaskIntoConstraints = false
    }

    // MARK: Internal
    enum RandomViewEvent {
        case colorChange
        case backButtonTapped
    }

    let viewEventStream = PublishRelay ()

    override init(frame: CGRect) {
        super.init(frame: frame)
        setUI()
        subscribeUIEvent()
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

// MARK: UI
extension RandomView {

    private func setUI() {
        self.backgroundColor = .random
        self.addSubview(backButton)
        self.addSubview(colorChangeButton)

        NSLayoutConstraint.activate([
            colorChangeButton.centerYAnchor.constraint(equalTo: centerYAnchor, constant: -40),
            colorChangeButton.centerXAnchor.constraint(equalTo: centerXAnchor),
            colorChangeButton.heightAnchor.constraint(greaterThanOrEqualToConstant: 44),

            backButton.topAnchor.constraint(equalTo: colorChangeButton.bottomAnchor, constant: 20),
            backButton.centerXAnchor.constraint(equalTo: centerXAnchor),
        ])
    }
}

// MARK: UI Event
extension RandomView {

    private func subscribeUIEvent() {
        colorChangeButton.addAction(UIAction(handler: { [weak self] _ in
            guard let owner = self else { return }
            owner.viewEventStream.accept(.colorChange)
        }), for: .touchDown)

        backButton.rx.tap
            .bind(with: self) { owner, _ in
                owner.viewEventStream.accept(.backButtonTapped)
            }
            .disposed(by: rx.disposeBag)
    }
}
Flow RIB (핵심)

지금은 뷰 구조가 단순하니까 Flow RIB 형태가 필요 하지 않습니다.
다만 뷰가 많다고 가정해 보겠습니다.
뷰 이동 관련해서 저희는 복잡한 뷰이동은 다른 파일에서 관리 했었을 겁니다.


코디네이터 패턴을 쓰거나, 라우터 패턴을 쓰거나 해서 관리를 하였는데
이것도 비슷한 방법이다 라고 생각하시면서
핵심은 뷰를 가지고 있는 않는 RIB을 통해 관리할 예정이니 집중 바랍니다.

Home Flow ViewController? -> X

없습니다.!!

Home Flow Interactor

뷰가 없는데 뷰모델이 존재합니다 만 거의 안씁니다.
하지만 각 하위의 리스너를 감지하게 해야 합니다.

final class HomeFlowInteractor: Interactor, HomeFlowInteractable {

    weak var router: HomeFlowRouting?
    weak var listener: HomeFlowListener?

    // TODO: Add additional dependencies to constructor. Do not perform any logic
    // in constructor.
    override init() {}

    override func didBecomeActive() {
        super.didBecomeActive()
        // TODO: Implement business logic here.
    }

    override func willResignActive() {
        super.willResignActive()
    }
}

extension HomeFlowInteractor: HomeListener {
    func didRequestLogin() {
        listener?.moveToLogin()
    }
}

extension HomeFlowInteractor: RandomListener {
    func randomBack() {
        router?.routeToRandomColor()
    }
}

protocol HomeFlowRouting: Routing {
    func start(name: String)
    func routeToRandomColor()
    func routeBackToHome()
}

protocol HomeFlowListener: AnyObject {
    // TODO: Declare methods the interactor can invoke to communicate with other RIBs.

    func moveToLogin()
}
Home Flow Router

RIB이 직접 뷰컨트롤러를 가지진 않지만 주입을 받을 겁니다.

protocol HomeFlowInteractable: Interactable, HomeListener, RandomListener {
    var router: HomeFlowRouting? { get set }
    var listener: HomeFlowListener? { get set }
}

final class HomeFlowRouter: Router, HomeFlowRouting {

    // MARK: - Private
    private let rootVc: RootViewControllable
    private let homeBuilder: HomeBuildable
    private let randomColorBuilder: RandomBuildable

    private var homeRouting: HomeRouting?
    private var randomColorRouting: RandomRouting?

    init(interactor: HomeFlowInteractable, rootVc: RootViewControllable, homeBuilder: HomeBuildable, randomColorBuilder: RandomBuildable, homeRouting: HomeRouting? = nil, randomColorRouting: RandomRouting? = nil) {
        self.rootVc = rootVc
        self.homeBuilder = homeBuilder
        self.randomColorBuilder = randomColorBuilder
        self.homeRouting = homeRouting
        self.randomColorRouting = randomColorRouting
        super.init(interactor: interactor)
        interactor.router = self
    }

    func start(name: String) {
        let home = homeBuilder.build(withListener: interactor, name: name)
        attachChild(home)

        homeRouting = home
        rootVc.setRoot(home.viewControllable, animated: false)
    }

    func routeToRandomColor() {
        guard homeRouting != nil else { return }
        let random = randomColorBuilder.build(withListener: interactor)
        attachChild(random)
        randomColorRouting = random
        rootVc.push(random.viewControllable, animated: true)
    }

    func routeBackToHome() {
        guard let random = self.randomColorRouting else { return }
        rootVc.pop(animated: true)
        detachChild(random)
        randomColorRouting = nil
    }

}
Home Flow Builder
protocol HomeFlowDependency: Dependency {
    var rootVC: RootViewControllable { get }
    var homeBuilder: HomeBuildable { get }
    var randomBuilder: RandomBuildable { get }
}

final class HomeFlowComponent: Component {

}

// MARK: - Builder
protocol HomeFlowBuildable: Buildable {
    func build(withListener listener: HomeFlowListener) -> HomeFlowRouting
}

final class HomeFlowBuilder: Builder, HomeFlowBuildable {

    override init(dependency: HomeFlowDependency) {
        super.init(dependency: dependency)
    }

    func build(withListener listener: HomeFlowListener) -> HomeFlowRouting {
        let component = HomeFlowComponent(dependency: dependency)
        let interactor = HomeFlowInteractor()
        interactor.listener = listener

//        return HomeFlowRouter(interactor: interactor, viewController: component.HomeFlowViewController)
        return HomeFlowRouter(interactor: interactor, rootVc: dependency.rootVC, homeBuilder: dependency.homeBuilder, randomColorBuilder: dependency.randomBuilder)
    }
}

다음과 같이 의존성을 두어서 진행하겠습니다.

Root Builder
final class RootBuilder: Builder, RootBuildable {

    override init(dependency: RootDependency) {
        super.init(dependency: dependency)
    }

    func build() -> LaunchRouting {
        let viewController = RootViewController()
        // 이부분에서 
        let component = RootComponent(dependency: dependency, rootVc: viewController)

        let interactor = RootInteractor(presenter: viewController)

        let loginBuilder    = LoginBuilder(dependency: component)
        let homeFlowBuilder = HomeFlowBuilder(dependency: component)

        return RootRouter(
            interactor: interactor,
            viewController: viewController,
            loginBuilder: loginBuilder,
            homeFlowBuilder: homeFlowBuilder
        )
    }
}

RootViewController 에서 push, pop만 구성해놓으면 (프로토콜에 의해서)
구조가 잡히게 됩니다.

마무리 하면서

RIBs 편이 마무리가 되었습니다.
글이 조금 부실하게 느껴질거라 생각합니다.
코드로 설명할게 많다 보니 오히려 말로 풀어내기가 애매하다고 생각을 합니다.


제가 작성한 코드를 복붙 하지 마시고 하나하나  적으면서 생각하시면 좋지 않을까 생각이 듭니다.
사실 말로 설명은 1편에서 개념편에서 한번에 정리한게 끝입니다.
어떻게 활용하냐에서는 코드가 많은게 더 좋을 것 같아서 순서 정도만 잡으면서 작성한 것 같구요


RIBs 도 상당히 아이디어는 좋은 아키텍처라고 생각합니다.
하지만 난이도와 ASAP 한 환경을 생각해본다면 비추가 되는 아키텍처라고 생각을 합니다.


정말 고생많으셨고 다음시간은 
XCTest 를 다루어 볼까 합니다. ( 다룬줄 알았는데 아니더라구요 ) 
XCTest -> TCA 와 Testable 형태로 작성할 수도 있고
Unity 여정 을 작성할 수도 있습니다....!


Unity도 공부해보면 좋을 것 같아서...!
댓글로 원하시는거 적으시면 반영 하겠습니다...!




RIBs - 프로젝트 구성편 - 2,  간단 로그인 뷰 연결
Mon, 22 Sep 2025 12:05:41 GMT
들어가기에 앞서

꼭 1편과 2편을 보고 글을 읽어주시면 좋겠습니다.

Login RIBs 세팅



이전 시간에 배운 방법으로 똑같이 템플릿을 통해서
Login Ribs를 세팅해주시면 됩니다.
View가 존재하는 Rib이기 때문에 첫번째를 체크하고 진행 하셔야 합니다.

UI 세팅

빠른 진행을 위해 간단하게 설계 했습니다.

import UIKit

final class LoginView: UIView {
    // 시작 버튼
    let button = UIButton().after { // after 는 Then 라이브러리 같이 설계되어 있습니다.
        var config = UIButton.Configuration.filled()
        config.title = "로그인"
        config.contentInsets = NSDirectionalEdgeInsets(top: 12, leading: 20, bottom: 12, trailing: 20)
        $0.configuration = config
        $0.translatesAutoresizingMaskIntoConstraints = false
    }

    override init(frame: CGRect) {
        super.init(frame: frame)
        setUI()
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

// MARK: UI Layer
extension LoginView {

    private func setUI() {
        self.addSubview(button)

        NSLayoutConstraint.activate([
            button.centerXAnchor.constraint(equalTo: self.centerXAnchor),
            button.centerYAnchor.constraint(equalTo: self.centerYAnchor),
        ])
    }
}
UI Event 연결해보기

UI 를 구성했으니 위와같은 버튼을 Interactor 에게 알려주어야 하겠죠?
RIBs 내부에 RxSwift가 있어서 RxSwift 를 사용해 보겠습니다.

Listener Setting
protocol LoginPresentableListener: AnyObject {
    // TODO: Declare properties and methods that the view controller can invoke to perform
    // business logic, such as signIn(). This protocol is implemented by the corresponding
    // interactor class.

      // 로그인 버튼 클릭
    func touchToLogin(name: String)
}
ViewController Setting
final class LoginViewController: UIViewController, LoginPresentable, LoginViewControllable {

    private let baseView = LoginView()

    weak var listener: LoginPresentableListener?

    override func loadView() {
        super.loadView()
        self.view = baseView
        subscribe()
    }
}

extension LoginViewController {

    private func subscribe() {
        baseView.button.rx.tap
            .bind(with: self) { owner, _ in
                owner.listener?.touchToLogin(name: "테스트를 위함")
            }
            .disposed(by: rx.disposeBag)
    }
}
Interactor Setting

자 프로토콜을 통해 저희는 저런 이벤트를 구성하겠다고 약속을 한거죠?
그것을 구현해야 합니다.

Interactor Listener Setting

로그인이 완료 되면 상위에게 뷰를 옮겨달라 라는 메시지를 전달하고자 합니다.
일단은요. -> 다음편에서는 구조가 바뀔 예정입니다.

protocol LoginListener: AnyObject {
    // TODO: Declare methods the interactor can invoke to communicate with other RIBs.

    func didLogin(name: String)
}

final class LoginInteractor: PresentableInteractor, LoginInteractable, LoginPresentableListener {

    weak var router: LoginRouting?
    weak var listener: LoginListener?

    // TODO: Add additional dependencies to constructor. Do not perform any logic
    // in constructor.
    override init(presenter: LoginPresentable) {
        super.init(presenter: presenter)
        presenter.listener = self
    }

    override func didBecomeActive() {
        super.didBecomeActive()
        // TODO: Implement business logic here.
    }

    override func willResignActive() {
        super.willResignActive()
        // TODO: Pause any business logic.
    }

    // 로그인 버튼 클릭시
    func touchToLogin(name: String) {
        let name = name
        // 비즈니스 로직 거친후 (생략) -> Root 에게 Home으로 가라고 명령
        listener?.didLogin(name: name)
    }
}
LoginBuilder Setting

자 이제 구성한 이벤트들이나, 의존성등을 구성하는 친구를 구현을 해야합니다.
그래야 Init() 을 해서 사용할 수 있겠죠?

protocol LoginBuildable: Buildable {
    func build(withListener listener: LoginListener) -> LoginRouting
}

final class LoginBuilder: Builder, LoginBuildable {

    override init(dependency: LoginDependency) {
        super.init(dependency: dependency)
    }

    func build(withListener listener: LoginListener) -> LoginRouting {
        let component = LoginComponent(dependency: dependency)
        let viewController = LoginViewController()
        let interactor = LoginInteractor(presenter: viewController)
        interactor.listener = listener
        return LoginRouter(interactor: interactor, viewController: viewController)
    }
}
Root에서 Login 이벤트 감지하기

자 위에서 말했듯이 상위에게 이벤트를 전달하고자
Listener를 세팅했죠?
상위가 바로 루트이기 때문에 다음과 같이 이벤트를 감지 하고자 합니다.

protocol RootInteractable: Interactable, LoginListener { // <- 이부분
    var router: RootRouting? { get set }
    var listener: RootListener? { get set }
}
final class RootInteractor: PresentableInteractor, RootInteractable, RootPresentableListener {

    weak var router: RootRouting?
    weak var listener: RootListener?

    // TODO: Add additional dependencies to constructor. Do not perform any logic
    // in constructor.
    override init(presenter: RootPresentable) {
        super.init(presenter: presenter)
        presenter.listener = self
    }

   ...

    func didLogin(name: String) { // <- 이부분
        router?.routToHome(name: name)
    }

}
Root Route Setting
protocol RootRouting: ViewableRouting {
    // TODO: Declare methods the interactor can invoke to manage sub-tree via the router.
    func routToLogin()
}
final class RootRouter: LaunchRouter, RootRouting {

    private let loginBuilder: LoginBuildable
    private let homeBuilder: HomeBuildable

    private var currentChild: ViewableRouting?
    private var loginRouter: LoginRouting?
    private var homeRouter: HomeRouting?

    init(interactor: RootInteractable,
         viewController: RootViewControllable,
         loginBuilder: LoginBuildable,
         homeBuilder: HomeBuildable) {
        self.loginBuilder = loginBuilder
        self.homeBuilder = homeBuilder
        super.init(interactor: interactor, viewController: viewController)
        interactor.router = self
    }

    override func didLoad() {
        super.didLoad()

        routToLogin()
    }

    func routToLogin() {
        if let child = currentChild {
            detachChild(child)
        }

        let login = loginBuilder.build(withListener: interactor)

        attachChild(login)
        currentChild = login
        loginRouter = login

        viewController.setRoot(login.viewControllable, animated: true)
    }

    func routToHome(name: String) { // 다음 시간에 
        if let child = currentChild {
            detachChild(child)
        }

        let home = homeBuilder.build(withListener: interactor, name: name)

        attachChild(home)
        currentChild = home
        homeRouter = home

        viewController.setRoot(home.viewControllable, animated: true)
    }
}
Root ViewController 수정
final class RootViewController: UIViewController, RootPresentable, RootViewControllable {

    private let container = UIView()
    private weak var current: UINavigationController?

    weak var listener: RootPresentableListener?

    init() {
        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    override func loadView() {
        super.loadView()
        view = container
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .white
    }

    func setRoot(_ vc: ViewControllable, animated: Bool) {
        let rootVC = vc.uiviewController
        let nav = UINavigationController()
        nav.setViewControllers([rootVC], animated: false) // 초기 세팅은 false 권장

        // 기존 제거
        if let current {
            current.willMove(toParent: nil)
            current.view.removeFromSuperview()
            current.removeFromParent()
        }

        addChild(nav)
        container.addSubview(nav.view)
        nav.view.frame = container.bounds
        nav.view.autoresizingMask = [.flexibleWidth, .flexibleHeight]
        nav.didMove(toParent: self)
        current = nav

        // 페이드 인
        if animated {
            container.alpha = 0
            UIView.animate(withDuration: 0.2) { [weak self] in
                self?.container.alpha = 1
            }
        }
    }
}

마치면서

이번편은 자식 RIBs가 하나 생겨서 연결하는 작업을 했습니다.
사실 Home뷰도 만들어서 왔다갔다 하는거 까지를 이번편으로 하려 했는데
사실 Home같은 경우는 Home 안에서도 뷰가 많겠죠? 이동하는 뷰들이


그래서 HomeFlow 라고 해서 View가 없는 RIB을 생성해서 Home의 뷰들을 통제하는
중계소? 같은 것으로 구성을 또 하게 되서 루즈해지니
Login만 설명을 했구요 다음편은 HomeView 빠르게 뷰와 라우터 만 설명을 한후
FlowRIB 설명을 끝으로 RIBs 편을 마무리 할까 고민중입니다.


궁금하신 사항 있으시면 꼭 말씀 부탁드립니다.
감사합니다.

github
Little-Tale/HowRibs



RIBs - 프로젝트 구성편 - 1
Tue, 16 Sep 2025 08:15:36 GMT
들어가기에 앞서

이전 개념편에 이어서
프로젝트 구성편으로 넘어 왔습니다.
이전편을 보지 않고 해당 편을 보아도 프로젝트는 구성이 가능합니다...만
개념을 알고 보시는게 도움이 되니 꼭 이전 개념편을 봐주시길 권장합니다.

템플릿 세팅

빈 폴더 하나를 만들어 두세요
해당 폴더에 RIBs 을 클론 해주세요
터미널을 열어주세요
cd RIBs/ios/tooling 으로 이동합니다.
/install-xcode-template.sh 을 통해 쉘을 실행 시켜주세요
아래 사진과 같이 RIB 템플릿이 설치 되었는지 확인해주세요


시작
Root 구성


위 사진처럼 Root를 구성해 보려고 합니다.
템플릿을통해 Root를 구성해 봅시다.



위 사진처럼 알아서 만들어 줄거에요
템플릿 세팅하실때 체크 박스중 View 여부에 따라 템플릿이 달라지는 체크박스가 있습니다.
View가 있음을 체크하고 만들어 주세요!

Routing 변경

ViewableRouter 
아마 라우터가 해당 프로토콜을 채택하고 있을거에요
이는 루트 라우터에서는 사용하지 않을 것이기에
LaunchRouter로 변경해주세요!

// 바꾸신후 RootBuilder 에서도 변경작업이 필요합니다.

// MARK: - Builder
protocol RootBuildable: Buildable {
    func build() -> LaunchRouting
}

final class RootBuilder: Builder, RootBuildable {

    override init(dependency: RootDependency) {
        super.init(dependency: dependency)
    }

    func build() -> LaunchRouting {
        let viewController = RootViewController()
        let component = RootComponent(dependency: dependency, rootVc: viewController)

        let interactor = RootInteractor(presenter: viewController)

        // MARK: 이부분은 무시하셔도 됩니다.
        // 후에 하게 되요... ㅎㅎ
        let loginBuilder    = LoginBuilder(dependency: component)
        let homeFlowBuilder = HomeFlowBuilder(dependency: component)

        return RootRouter(
            interactor: interactor,
            viewController: viewController,
            loginBuilder: loginBuilder,
            homeFlowBuilder: homeFlowBuilder
        )
    }
}
AppComponent
import RIBs

class AppComponent: Component, RootDependency {

    init() {
        super.init(dependency: EmptyComponent())
    }
}
SceneDelegate 세팅
class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?
    // 런치라우터를 변수선언
    private var launchRouter: LaunchRouting?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let scene = (scene as? UIWindowScene) else { return }
        let _window = UIWindow(windowScene: scene)
        self.window = _window

        // _window.makeKeyAndVisible() // 해당 함수를 실행하지 않아도 됩니다.

        let appComponent = AppComponent()
        let _launchRouter = RootBuilder(dependency: appComponent).build()
        self.launchRouter = _launchRouter
        _launchRouter.launch(from: _window)
    }


// MARK: RIBs LaunchRouter 내부 코드중

/// The application root router base class, that acts as the root of the router tree.
open class LaunchRouter: ViewableRouter, LaunchRouting {

    /// Initializer.
    ///
    /// - parameter interactor: The corresponding `Interactor` of this `Router`.
    /// - parameter viewController: The corresponding `ViewController` of this `Router`.
    public override init(interactor: InteractorType, viewController: ViewControllerType) {
        super.init(interactor: interactor, viewController: viewController)
    }

    /// Launches the router tree.
    ///
    /// - parameter window: The window to launch the router tree in.
    public final func launch(from window: UIWindow) {
        window.rootViewController = viewControllable.uiviewController
        window.makeKeyAndVisible()

        interactable.activate()
        load()
    }
}


func launch(from window: UIWindow) 함수를 통해
내부에서 window.makeKeyAndVisible() 함수를 실행시키기 때문에
위와 같은 방식으로 SceneDelegate 를 구성합니다.


실행 시켜 보시면 넵 빈화면이 나오겠죠..?
이번시간에는 하지 않겠지만
로그인RIB 과 HomeRIB을 구성해서 로그인 화면으로 시작하여 Home으로 
그 반대로도 구성해 보겠습니다.


마무리 하며

이번시간에는 Root를 구성하는 과정을 글로 옮겨 보았습니다.
다음 시간부터 좀더 머리가 아파지기 시작합니다.


Login을 먼저 구성을 하구요
Root와 통신을 해서 Home으로 이동시키고
Home에선 로그아웃 버튼을 만들어서 Login 화면으로 이동하게 구성해보겠습니다.
오늘도 고생 하셨습니다.

프로젝트 코드 미리보기
git-hub - LittleTale_HowRibs



RIBs - 개념편
Wed, 10 Sep 2025 14:20:46 GMT
들어가기에 앞서

이번편을 작성하는데 있어서
좀 시간이 필요했습니다.... 
Pin + Flex Layout 편을 작성하고 있었는데
Ribs 라는 친구가 생각보다 재밌어 보이드라구용
그래서 중간에 갈아타는 바람에 걸린 것두 있고
사용법 보다는 개념을 좀더 집중해서
이해도를 높히고 들어가고 싶은 마음도 컷기에
좀더 확실하게
알아보고 시도해보고 적용해보면서 시간이 걸렸던 것 같습니다...
자 시작해보죠.

RIBs가 왜 나온 것인가

MVC 를 유지보수 할때에 새로운 기능이 늘어날때마다 복잡성이 증가


모듈 증가할 수록 테스트 복잡
ViewController 평균 코드 줄이 3000줄

VIPER 아키텍처란 무엇인가

View              : UI
Interactor        : 비즈니스 로직 + Network + Data Layer 수행
Presenter         : UI의 상호작용 -> Interactor의 Data를 요청후 View 반영 담당
Entity            : UI에 사용할 모델
Router            : 화면 전환 로직

Viper 장점

MVC 대비 추상적
각각의 책임 분담으로 인한 유지보수 도움
테스트 용이 단 Presenter, Interactor 한

Ribs는 왜?

View, Business 트리와 밀접 -> 한쌍을 이루어야 함이 거슬림 -> 단독 노드 구성 가능하게
View 트리가 중심인점

VIPER 아키텍처
View <-> Presenter <-> Interactor -> Entity
            |-> Router
RIBs
Builder <-> Component
   ↓
┌──────────────────────────────────────────────┐
│ Router <- Interactor <-> Presenter <-> View  │
└──────────────────────────────────────────────┘
RIBs 의 정의

UI가 중심이 아닌 Business Logic 중심으로 하겠다!
State 변화 감지는 Business 단에서 관리 하겠다!
L "" 는 Scope ( 격리된거죠 ) 를 통해 관리 하겠다!
하나의 화면엔 여러 VC 가 이루어질 수 있다!

RIBs 필수적 요소

Router: Attach (뷰 추가) Detach (뷰 제거)
Interactor: 비즈니스 로직 -> Rib 들을 Attach, Detach할지 명령
Builder: Rib 생성

옵션 적인 요소

UI:          Layout, Animation
Presenter:   Translation Logic - Interactor <-> View

Scope

상속처럼 자식에서 부모의 내용을 받아서 사용 가능
AuthToken 같은거 생각
State관리는 이친구가 관리


Child Rib에서는 Parent Rib의 내용을 이미 가지고 있다고 가정

RIBs Life cycle

Attach, Detach 상태가 존재하는데
Router에서 애니메이션 설정이 필요함
Router에 Will, did 라이프 사이클을 추가하여 사용하면 편리

RIBs 단점

하나의 기능에 많은 클래수 수와 하나의 파일에 여러가지 클래스가 존재
Ribs를 하나의 프로젝트에 전체를 종속 시켜야 하는 문제
Ribs 내부에 RxSwift가 내장되어 있는데 이것 또한 문제

Parent 와 자식 간의 데이터 교환시

Interface Listener 사용하여 소통함

RIBs 생성 방법

Rib 생성

부모의 Router에 프로퍼티 적용: 생성된 Child Builder 프로퍼티 추가

Dependency적용: Builder를 만들떄에 Componenet 주입
           컴포넌트는 부모의 컴포넌트 속성을 따름
Builder 에 변경된 Router 내용 적용
RIBs 구성 상세
Interactor

비즈니스 로직을 포함
해당 클래스에서 Rx 구독을 수행해야함
상태를 변경하는 결정을 수행
그외에 다른 Rib을 자식으로 연결할지 결정함

Router

Interactor의 요청을 수신 받음
자식 Rib의 연결 혹은 분리


라우터는 자식 Interactor를 모의하거나 그 존재에 신경 쓸 필요 없이
복잡한 Interactor 논리를 쉽게 테스트할 수 있게 해주는
Humble Objects 역할을 합니다.
라우터는 부모 인터랙터와 자식 인터랙터 사이에 추가적인 추상화 계층을 생성합니다.
이로 인해 인터랙터 간의 동기식 통신이 다소 어려워지고,
RIB 간의 직접 결합 대신 반응형 통신을 채택하는 것이 용이해집니다.
라우터는 인터랙터에서 구현해야 하는 간단하고 반복적인 라우팅 로직을 포함합니다.
이러한 보일러플레이트 코드를 제거하면 인터랙터의 크기를 줄이고
RIB에서 제공하는 핵심 비즈니스 로직에 더 집중할 수 있습니다.



Router 종류

Router

기본 라우터
뷰가 존재 하지 않는 경우에 사용

ViewableRouter

뷰가 존재할 경우에 사용해야하는 라우터
즉 이 RIB이 ViewController를 가지고 있어야 함
자식의 화면을 Present/ Dismiss 하거나 교체 하여야 함

LaunchRouter

앱 시작 지점 전용
AppDelegate 에서 Launch 로 앱을 띄울때 쓰이는 루트 라우터



Builder

RIB의 모든 구성 클래스, 각 자식에 대한 빌더를 인스턴스화

Presenter

비즈니스 모델을 뷰 모델로 변환 혹은
반대로 변환하는 상태를 저장하지 않는 클래스
해당 클래스는 생략이 가능하며 뷰모델 변환은 뷰컨트롤러 혹은 인터랙터 책임

View(Controller)

UI 업데이트 혹은 빌드

Component

Rib 종속성 관리
Rib을 구성하는 다른 유닛들을 인스턴스화 할 수 있도록 지원
외부 종속성에 대한 접근을 제공
부모 Rib의 컴포넌트는 일반적으로 자식 RIB의 빌더에 주입되어 자식 RIB이
부모 Rib의 종속성에 접근하도록 함

마무리 하면서

개념을 다루면서 제가 궁금했던 점을 정리한 내용입니다.
TCA 편을 보셨다면 꽤 비슷한 흐름이 보이실 겁니다.
어느 부분이냐 바로 트리 구조라는 흐름이 포인트일 것 같습니다.


TCA도 상위 Reducer 가 하위 리듀서를 감지할 수 있듯이
RIBs 도 그런 형태를 취합니다.


다만 RIBs는 제가 개인적으로 느끼기에는
많이 복잡한 구조를 가지고 있습니다.
다음편인 프로젝트 작성하기 편에서 느끼실 수 있을 것 같아요
모두 고생하셨구 다음편에서 뵙겠습니다....
감사합니다.


바로 프로젝트 코드를 보고싶다면
https://github.com/Little-tale/HowRIbs
를 참고해주세용 스타도 주시면 감사합니당




깜작 스낵 알고리즘! - 백트래킹
Tue, 19 Aug 2025 11:38:57 GMT
들어가기에 앞서

사실 알고리즘을 블로그 글을 
핀 레이아웃편을 준비 하고 있었는데
준비하면서 알고리즘도 같이 공부 하고 있었습니다.
이때 백트래킹이 정말 인상 깊었어서 잠깐 다루는 시간을 갖도록 하겠습니다.

백트래킹

사전적으로는
"가능한 해를 점진적으로 찾다가 해가 아니라면 되돌아가는 깊이 우선 탐색 + 가지치기 기법이다."
라고 정의가 되어 있기는 합니다.
사실 말로만 들으면 뭔말인지 저어어언혀 이해가 안갔어요 저는
저는 이정의를 좀더 심플하게 정의 해보고자 합니다.
반복해서 해를 찾는데 아니다 싶으면 되돌리기

예시 문제

백준 문제에서 괜찮다 싶은 문제 2개를 가져와 보았습니다.

N과 M 6번째 문제

문제: N개의 자연수와 자연수 M이 주어졌을 때, 아래 조건을 만족하는 
길이가 M인 수열을 모두 구하는 프로그램을 작성하시오. 


N개의 자연수는 모두 다른 수이다.

N개의 자연수 중에서 M개를 고른 수열은 오름차순이어야 한다.

예시 입력
3 1
4 5 2

예시 출력
2
4
5



위에서 언급했다 싶이 조건을 만들고 조건이 맞다 싶으면 결과를 쌓을것이며 아니다 싶으면 돌아 가겠습니다.

let nm = readLine()!.split(separator: " ").map{ Int($0)! }
let n = nm[0] // 총 갯수
let m = nm[1] // 고를수있는 갯수

let numbers = readLine()!.split(separator: " ").map { Int($0)! }.sorted()
var visited = Array(repeating: false, count: n)
var temp: [Int] = []
var answer: String = ""


func solution(start: Int) {
    if temp.count == m {
        answer += temp.map{ String($0) }.joined(separator: " ") + "\n"
        return
    }

    for i in start..


코드를 유심히 보시면
솔류션 함수에서 숫자를 검사합니다. 길이가 m과 같은지 
같다면 돌아가는 형태죠?


그아래에 for문을 보시면
솔류션 함수를 다시 호출하고 있습니다.
재귀 함수구나! 를 접근이 가능하죠


이말은 즉 1,2,3,4,5 가 있다면 1,2,3,4,5 - 1,2,3,5,4.... 같이 모오든 경우의 수를 다 보겠다 라는 의미입니다.

로또 문제

독일 로또는 {1, 2, ..., 49}에서 수 6개를 고른다.
로또 번호를 선택하는데 사용되는 가장 유명한 전략은 

49가지 수 중 k(k>6)개의 수를 골라 집합 S를 만든 다음 그 수만 가지고 번호를 선택하는 것이다.


예를 들어, k=8, S={1,2,3,5,8,13,21,34}인 경우 
이 집합 S에서 수를 고를 수 있는 경우의 수는 총 28가지이다. 


([1,2,3,5,8,13], [1,2,3,5,8,21], [1,2,3,5,8,34], [1,2,3,5,13,21], ..., [3,5,8,13,21,34])


집합 S와 k가 주어졌을 때, 수를 고르는 모든 방법을 구하는 프로그램을 작성하시오.

해당 문제는 위 문제보다 좀더 백트래킹에 대해 이해 할수 있을것 같아서 가져와 보았습니다.

var text: String = ""

while true {
    let numbers = readLine()!.split(separator: " ").map { Int($0)! }
    let k = numbers[0]
    if k == 0 {
        break
    } else if !text.isEmpty {
        text += "\n"
    }
    let lottoNumbers = Array(numbers[1...])
    var temp: [Int] = []
    solution(originalNumbers: lottoNumbers, current: &temp, start: 0, text: &text)
}

func solution(originalNumbers: [Int], current: inout [Int], start: Int, text: inout String) {
    if current.count == 6 {
        text += current.map { String($0) }.joined(separator: " ") + "\n"
        return
    }

    for i in start..


반복문을 잘 보시면
넣었다가 빼고 하는 과정이 있습니다.


이 부분이 햇갈려 하실 수 도 있으신데
넣으면 1 -> 넣고 2 -> 쭉 가서 조건인 6개까지 모였는가 모이면 결과를 쌓고 돌아가는 형태죠?

마무리 하며

간단히 짤막한 스낵 알고리즘 - 백트래킹 편이였습니다.
처음엔 상당히 이해가 안되었는데 계속 하다보면 이해가 되드라구요
모두 수고 하셨습니다.

little_tale.log

[짤막지식] Web

1. React 로 짜면 봇이 못읽는다 ???

Next로 해결하면?

2. React가 빠른 이유는 Virtual DOM 때문일까?

3. SPA는 왜 새로고침이 빠를까?

4. Next.js는 왜 React인데 SEO에 유리하다는거야?

Hydration

5. Next.js에서 "use client"는 무슨 뜻일까?

필요 개념

CSR

SPA

Virtual DOM

DevOps 3편 : Terraform 해보기

준비물

IAM 사용자 1명 + Access Key 1개 만들어 보자

이제 코드로 작성해보자

테라폼안에서의 동작 순서 (aws 안넘어감)

초기화

린트 정리 ( 포멧 )

validate ( 컴파일 )

terraform plan

terraform의 AWS provider는 보통 이런 순서로 자격 증명을 찾음

여기서 말하는 핵심은 간단하다

이제 Apply 할 차례다

테라폼 입장에서도 확인이 가능하다.

S3란 무엇이지?

버킷은 무엇이지?

변수를 사용해보자

결과를 볼 수 있게

와닿지 않는다.

tags

태그 Name은 관리용 라벨이라 더 자유롭게 쓸 수 있습니다.

이름 헷갈리지 말기

이제 적용해 보자

Destroy

특정 리소스만 부시려면?

그렇다면 어떻게 해야 안전하게 할까?

지금까지의 과정들

State

What If?

무슨 상태값들을?

조심할 점.

공유하지 말라는건가? -> X 공유해야한다.

동시 접근은?

AWS 기존에 있던걸 Terraform 이 알아서 인식할까?

시도해보기 - import

import 후 해야할 일

Locals.tf

단순 코드 가독성 때문일까?

variable과 local의 차이가 뭔데?

Outputs.tf

ARN

output

그럼 지금 상태에서 추가한 리소스에 관한 output을 짠다면 어떻게 할까?

versioning

중요한 포인트

public acess block

S3에서 공개 여부를 제어하는 대표수단

ACL - Access Control List

Bucket Policy

간단 정리

경로는 하나가 아니다.

Data source

잠깐 정리하기

Module

상황

S3 구성법을 모듈화 하자

main.tf 변경점 1. module

main.tf 변경점 2. moved

Backend

Provider Vs Backend

BackEnd의 중요성

DynamoDB란?

DynamoDB Lock?

환경 분리 (Dev, Prod)

흐름

Root

File Load

Backend Load