개발자일지

[Flutter] GetX, 상태관리를 쉽게 만드는 라이브러리

TTH — Mon, 11 May 2026 16:38:20 +0900

Flutter로 앱을 개발하다 보면 상태관리(State Management)는 반드시 고려해야 하는 요소이다.

앱에서는 로그인 상태, 장바구니 수량, API 응답 데이터, 좋아요 여부, 테마 설정처럼 실행 중 계속 변경되는 데이터를 지속적으로 관리해야 한다. 이러한 상태를 어떻게 관리하느냐에 따라 코드 구조, 유지보수성, 개발 생산성이 크게 달라진다.

Flutter에서는 이를 위해 다양한 상태관리 방식을 제공하며, 대표적으로 Provider, Riverpod, Bloc, GetX 등이 많이 사용된다. 그중 GetX는 비교적 적은 코드로 상태관리와 라우팅, 의존성 관리까지 처리할 수 있어 빠른 개발에 강점을 가진 라이브러리로 많이 활용되고 있다.

GetX란?

GetX 는 Flutter에서 사용하는 상태관리 라이브러리이다.

단순히 상태관리만 제공하는 것이 아니라 상태관리, 라우팅, 의존성 관리 기능까지 함께 제공한다. Flutter에서 자주 사용하는 기능들을 하나의 라이브러리로 처리할 수 있다는 점이 특징이다.

GetX의 주요 기능
- 상태관리(State Management)
- 라우팅(Route Management)
- 의존성 관리(Dependency Injection)

GetX의 특징

1. 코드가 간결하다

Flutter 기본 상태관리 방식인 setState() 대비 코드량이 적다.

예를 들어 상태를 선언할 때 .obs만 붙이면 반응형 상태로 사용할 수 있다.

var count = 0.obs;

복잡한 보일러플레이트 코드가 적은 편이라 빠르게 개발하기 좋다.

2. 상태 변경 시 UI가 자동 갱신된다

GetX는 상태값 변경을 자동으로 감지한다.

상태 변경
→ UI 자동 업데이트

형태로 동작한다.

따라서 setState()를 직접 호출하지 않아도 된다.

3. 러닝커브가 낮다

문법 자체가 단순한 편이라 Flutter 입문자도 비교적 빠르게 적응할 수 있다.

특히 개인 프로젝트, MVP 개발, 프로토타입을 제작하는 것처럼 기능 구현이 빠르게 필요한 상황에서 많이 사용된다.

GetX 설치

pubspec.yaml에 패키지를 추가한다.

dependencies:
  get: ^4.6.6

이후 아래의 명령어를 실행한다.

flutter pub get

GetX 기본 사용 방법

1. Controller 생성

import 'package:get/get.dart';

class CounterController extends GetxController {

  var count = 0.obs;

  void increase() {
    count++;
  }
}

GetxController: 상태를 관리하는 클래스이다. React 기준으로 보면 store 혹은 state 관리 객체 느낌에 가깝다.

.obs: observable 상태를 의미한다. 즉 값이 변경되면 GetX가 이를 감지한다.

0.obs

2. 화면에서 사용

import 'package:flutter/material.dart';
import 'package:get/get.dart';

class HomeScreen extends StatelessWidget {

  final controller = Get.put(CounterController());

  HomeScreen({super.key});

  @override
  Widget build(BuildContext context) {

    return Scaffold(
      appBar: AppBar(
        title: const Text('GetX Example'),
      ),

      body: Center(
        child: Obx(() =>
          Text(
            '${controller.count}',
            style: const TextStyle(fontSize: 30),
          ),
        ),
      ),

      floatingActionButton: FloatingActionButton(
        onPressed: () {
          controller.increase();
        },
        child: const Icon(Icons.add),
      ),
    );
  }
}

Get.put(): Controller 객체를 등록하는 역할을 한다. 화면 어디서든 동일한 Controller를 사용할 수 있게 된다.

Get.put(CounterController())

Obx(): 상태 변경을 감지하는 위젯이다. count 값이 변경되면 해당 UI만 자동으로 rebuild 된다.

Obx(() => Text(...))

GetX의 상태 업데이트 흐름은 비교적 단순한 편이다.

사용자가 버튼을 클릭하면 Controller 내부의 상태값이 변경되고, GetX의 반응형 상태(obs)를 구독하고 있는 Obx가 해당 변경을 감지한다. 이후 변경된 상태를 기준으로 UI가 자동으로 다시 렌더링된다.

즉 전체 흐름은 다음과 같다.

사용자 액션 발생
   ↓
Controller 상태 변경
   ↓
Obx가 상태 변경 감지
   ↓
필요한 UI만 rebuild

기존 setState() 방식과 비교했을 때 명시적으로 화면 갱신 코드를 작성하지 않아도 되기 때문에 코드량이 줄어들고, 상태와 UI를 분리하기 쉽다는 장점이 있다.

폴더 구조 예시

GetX를 사용할 때는 보통 다음과 같은 구조를 많이 사용한다.

lib/
 ├── controllers/
 │    └── counter_controller.dart
 │
 ├── screens/
 │    └── home_screen.dart
 │
 ├── widgets/
 └── main.dart

GetX 장점

GetX의 가장 큰 장점은 적은 코드로 상태관리와 화면 제어를 빠르게 구현할 수 있다는 점이다.
복잡한 설정 과정이 비교적 적고 문법이 직관적인 편이라 생산성이 높은 편에 속한다.

특히 개인 프로젝트나 MVP 개발처럼 빠른 기능 구현이 중요한 상황에서 많이 활용된다.

장점	설명
코드량이 적다	문법이 단순하다
개발 속도가 빠르다	설정이 적다
입문 난이도가 낮다	빠르게 적응 가능하다
라우팅 기능 제공	화면 이동 관리 가능
의존성 관리 가능	객체 재사용 가능

GetX 단점

1. 프로젝트 규모가 커질수록 복잡해질 수 있다

GetX는 자유도가 높은 편이다.

초반에는 빠르게 개발할 수 있지만 프로젝트 규모가 커질수록 상태 흐름 추적이나, 구조통일, 유지보수 부분에서 어려움이 생길 수 있다.

2. 팀 프로젝트에서 코드 스타일 차이가 커질 수 있다

GetX는 정해진 구조를 강제하지 않는다. 그래서 팀마다 controller 구조, 상태 분리 방식, 폴더 구조가 달라지는 경우가 많다.

3. 최근에는 Riverpod 선호도가 높아지는 추세이다

최근 Flutter 생태계에서는 Riverpod, Bloc 선호도가 높아지는 분위기이다.

특히 규모가 큰 프로젝트일수록 구조적인 상태관리를 선호하는 편이다.

GetX와 Riverpod 비교

Flutter 상태관리 라이브러리 중 GetX와 Riverpod는 모두 많이 사용되는 편이지만, 추구하는 방향에는 차이가 있다.

GetX는 빠른 개발과 간결한 코드 작성에 강점이 있는 반면, Riverpod는 상태 흐름을 보다 명확하게 관리할 수 있도록 구조적인 패턴을 제공하는 편이다.

프로젝트 규모나 팀 개발 여부에 따라 선택 기준도 달라지는 경우가 많다.

	GetX	Riverpod
난이도	비교적 쉬운 편	개념 이해가 조금 더 필요하다
코드량	적은 편	상대적으로 코드가 늘어나는 편이다
자유도	높다	구조적인 패턴을 지향한다
빠른 개발	강점이 있다	가능하지만 구조 설계가 필요하다
대규모 프로젝트	관리 복잡도가 높아질 수 있다	상태 흐름 관리에 유리하다

GetX는 적은 코드로 빠르게 기능을 구현할 수 있어 개인 프로젝트나 MVP 개발에 적합한 편이다. 반면 Riverpod는 상태 의존성과 데이터 흐름을 명확하게 관리할 수 있어 규모가 있는 프로젝트나 협업 환경에서 선호되는 경우가 많다.

최근 Flutter 생태계에서는 유지보수성과 확장성을 고려해 Riverpod를 선택하는 사례도 점차 증가하는 추세이다.

GetX는 Flutter에서 빠르게 상태관리를 구현할 수 있는 라이브러리이다.

특히 빠른 MVP 개발, 개인 프로젝트, 간단한 서비스에서 생산성이 좋은 편이다.

다만 프로젝트 규모가 커질수록 상태 흐름 관리와 구조 설계가 중요해지기 때문에, 상황에 따라 Riverpod나 Bloc 같은 구조적인 상태관리 방식도 함께 고려하는 것이 좋다.

[Flutter] 개념 정리 및 시작하기(window 설치, 프로젝트 생성)

TTH — Fri, 8 May 2026 14:41:57 +0900

Flutter란?

Flutter는 Flutter에서 개발한 크로스플랫폼 UI 프레임워크이다.
한 번 코드를 작성하면 Android, iOS, Web, Windows, macOS까지 여러 플랫폼에서 실행할 수 있고, Dart 라는 언어를 사용해서 구현한다.

[ Flutter 구조 ]

Flutter
├─ Dart 언어
├─ Widget(UI)
├─ Rendering Engine(Skia)
└─ 플랫폼(Android/iOS/Web 등)

Flutter 설치하기

먼저 Flutter를 설치하기 위해서는 Git과 VS Code가 설치되어 있어야 한다.

먼저 해야할 일은 VS Code에 Flutter 확장 프로그램을 추가해야한다.

마켓 플레이스 페이지에서 설치를 진행한다.

VS Code에서 Control + shift + P 를 클릭해서 명령 팔레트를 열고 flutter를 입력한다.

그러면 아래와 같이 Flutter: New Project라고 나오는데 이걸 클릭한다.

오른쪽 하단에 아래와 같은 창이 뜨면 Download SDK를 클릭한다.

Flutter를 설치할 폴더를 선택하고 다운로드를 진행하면 된다.

그 다음에 SDK를 PATH에 추가한다.

lutter SDK 경로가 환경변수(PATH)에 등록되지 않으면 아래와 같은 오류가 발생한다.

Windows에서 터미널에 flutter 명령어를 입력하면 운영체제는 PATH(Environment Variables)에 등록된 경로 목록에서 실행 파일을 찾는다.

flutter : 'flutter' 용어가 cmdlet, 함수, 스크립트 파일 또는 실행할 수 있는 프로그램 이름으로 인식되지 않습니다.

( Flutter뿐 아니라 Node.js, Python, Git 등의 CLI 기반 개발 도구들도 동일한 방식으로 PATH 환경변수를 통해 실행 파일 위치를 관리한다)

윈도우 키를 누르고 환경변수를 검색하여 "시스템 환경 변수 편집"을 클릭한다.

시스템 속성에서 맨 하단에 있는 환경 변수를 클릭한다.

사용자 변수에서 "편집" 을 클릭한다.

새로 만들기 버튼 클릭 후 경로를 추가한다.

저장하고 VS Code를 종료한 뒤 재실행하고, 터미널에서 flutter --version 를 입력해서 아래 이미지와 같이 버전이 뜨면 뜨면 flutter 설치가 완료된 것이다.

Flutter 프로젝트 생성하기

터미널에 아래와 같이 입력한다.

flutter create my_app

프로젝트가 생성하면 아래 명령어로 방금 전 만든 프로젝트 폴더로 이동한다.

cd my_app

아래 명령어를 입력하면 웹으로 프로젝트가 실행된다.

크롬에서 실행하라고 명령했기 때문에 크롬 브라우저에서 flutter 앱이 실행된다.

flutter run -d chrome

* -d의 의미는 device의 약자

아래는 크롬으로 실행한 flutter 앱의 모습이다.

[ReactJS] useState - 상태(state)를 관리하기 위한 Hook

TTH — Thu, 16 Apr 2026 09:34:12 +0900

useState란?

useState는 컴포넌트 내부 상태(state)를 관리하기 위한 Hook이다.

상태(state)란 다음과 같은 데이터를 의미한다.

시간이 지나면서 변경되는 값
값이 변경되면 화면(UI)도 함께 업데이트됨

useState는 값이 변경되면 화면도 함께 업데이트되도록 만드는 React의 상태 관리 기능이다.

useState 기본 사용법

useState의 기본 사용법은 함수형 컴포넌트 내부에서 상태를 선언하고, 해당 상태를 변경하는 함수를 함께 사용하는 구조이다. useState를 호출하면 배열 형태로 값이 반환되며, 첫 번째 요소는 현재 상태 값이고 두 번째 요소는 상태를 변경하는 함수이다. 초기값은 useState(초기값) 형태로 전달한다. 이후 상태를 변경할 때는 직접 값을 수정하는 것이 아니라 반드시 setter 함수를 사용해야 하며, 이 함수가 호출되면 React는 상태 변화를 감지하고 컴포넌트를 재렌더링하여 변경된 값이 화면에 반영되도록 처리한다.

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount(count + 1)}>증가</button>
    </div>
  );
}

- useState(0) → 초기값을 0으로 설정하는 함수

- count → 현재 상태 값

- setCount → 상태를 변경하는 함수

버튼 클릭 시 setCount가 실행되며, 상태가 변경되고 컴포넌트가 재렌더링된다.

배열 구조를 사용하는 이유

const [state, setState] = useState(initialValue);

자바스크립트의 배열 구조 분해는 순서 기반으로 값 할당이 가능하다.

React는 항상 1번째는 상태값, 2번째는 상태 변경 함수를 사용하기 때문에 이 규칙을 유지하기 때문에 배열이 자연스럽다.

const arr = [10, 20]; // [상태값, 상태변경함수]
const [a, b] = arr;

useState 동작 원리

useState의 동작 흐름은 간단하게 “값이 바뀌면 화면도 다시 그려진다”라고 이해하면 된다.

컴포넌트가 처음 실행될 때 useState로 설정한 초기값이 상태로 저장되고 화면에 표시된다. 이후 어떤 이벤트(예: 버튼 클릭)로 인해 상태 변경 함수(setState)가 호출되면, React는 기존 상태와 변경된 상태를 비교하여 값이 달라졌음을 인식한다. 그러면 해당 컴포넌트를 다시 실행(재렌더링)하여 새로운 상태 값을 기반으로 UI를 다시 그린다. 그 결과, 변경된 값이 화면에 반영된다.

즉, 상태가 바뀌는 순간 React가 자동으로 다시 렌더링을 수행하고, 최신 상태가 UI에 표시되는 구조이다.

[ useState의 동작 흐름 정리 ]
1) 컴포넌트 최초 렌더링 시 상태가 초기화된다
2) setState 함수가 호출된다
3) React가 상태 변화를 감지한다
4) 컴포넌트가 다시 렌더링된다
5) 변경된 값이 UI에 반영된다

잘못된 사용 방식과 올바른 사용방법

잘못된 예)

이 방식은 React가 상태 변화를 감지하지 못하기 때문에 사용하면 안 된다.

count = count + 1;

올바른 예)

반드시 상태 변경 함수(setter)를 통해 값을 변경해야 한다.

setCount(count + 1);

React는 내부적으로 언제 다시 렌더링 해야하는지 판단하는데, 그 기준이 setter 함수(setCount)가 호출되었는지의 여부이다.

count는 단순한 변수처럼 보이지만 실제로는 react가 관리하는 값이다. 그런데 count = count + 1처럼 직접 값을 바꾸면 react 입장에서는 값이 바뀌었는지 알 방법이 없다.

setCount를 호출하는건 단순히 값을 바꾸는 것이 아니라 react에게 상태가 변경되었다는 신호를 보내는 행위이다.

실무에서 자주 하는 실수, 이전 상태 기반 업데이트

잘못된 예, 연속 업데이트 문제)

아래와 같이 하면 2가 아니라 1만 증가할 수 있다.

count는 현재 랜더링 기준 값이고, 두 번 모두 같은 값을 기준으로 계산된다.

setCount(count + 1);
setCount(count + 1);

올바른 예)

setCount(prev => prev + 1);
setCount(prev => prev + 1);

이 방식은 React는 상태 업데이트를 비동기적으로 처리하고, 여러 번 상태를 변경할 때 안전하기 때문에 권장되는 방식이다.

다양한 데이터 타입 저장

useState는 다양한 타입의 데이터를 저장할 수 있다.

숫자

const [count, setCount] = useState(0);

문자열

const [name, setName] = useState("");

객체

const [user, setUser] = useState({ name: "홍길동", age: 20 });

setUser({ ...user, age: 21 });

객체를 업데이트할 때는 반드시 불변성 유지를 위해 spread 문법을 사용해야 한다.

핵심정리

useState는 React에서 상태를 관리하기 위한 Hook이다. 상태 값이 변경되면 React는 해당 컴포넌트를 자동으로 재렌더링하여 변경된 내용을 UI에 반영한다. 이때 상태는 직접 수정하는 것이 아니라 반드시 setter 함수를 통해 변경해야 하며, 특히 이전 상태를 기반으로 값을 업데이트하는 방식(prev => ...)을 사용하는 것이 안전하다. 또한 useState는 숫자, 문자열, 객체, 배열 등 다양한 타입의 데이터를 상태로 저장하고 관리할 수 있다.

[ 핵심 정리 ]
useState는 상태를 관리하는 Hook이다
상태가 변경되면 컴포넌트가 자동으로 재렌더링된다
상태는 반드시 setter 함수를 통해 변경해야 한다
이전 상태 기반 업데이트 방식이 안전하다
모든 타입의 데이터를 저장할 수 있다

개발자가 꼭 알아야 할 Vim 최소 명령어 5가지

TTH — Wed, 25 Mar 2026 10:27:49 +0900

Vim을 처음 접하면 “왜 아무것도 입력되지 않는 것인가?”라는 당황스러운 상황을 마주하게 된다. 일반적인 에디터와 달리 Vim은 실행하자마자 바로 글을 입력할 수 있는 구조가 아니라, ‘모드’라는 개념을 기반으로 동작하기 때문이다. 이 차이를 이해하지 못하면 키를 눌러도 반응이 없는 것처럼 느껴지고, 오히려 더 복잡하고 어렵게 느껴질 수 있다.

하지만 Vim의 핵심은 생각보다 단순하다. 입력 모드와 명령 모드라는 기본 개념만 이해하고, 자주 사용하는 최소한의 명령어 몇 가지만 익히면 Git 커밋 메시지 작성, 서버 환경에서의 파일 수정, CLI 기반 작업 등 다양한 개발 상황에서 막힘 없이 사용할 수 있게 된다. 결국 Vim은 어려운 도구가 아니라, 사용 방식이 조금 다를 뿐인 효율적인 에디터이다.

[ 핵심요약 ]
입력 안 되면 > i
이상해지면 > Esc
끝낼 때 > :wq
취소 > :q!

1. 입력 모드 진입 — i

Vim은 실행하자마자 바로 글을 입력할 수 있는 일반적인 에디터와 달리, 기본적으로는 ‘명령 모드(Normal Mode)’ 상태로 시작한다. 이 상태에서는 키보드를 눌러도 글자가 입력되는 것이 아니라, 커서 이동이나 삭제와 같은 명령이 실행된다. 그래서 처음 사용하는 경우 “왜 아무것도 안 써지지?”라는 혼란을 느끼기 쉽다.

이때 필요한 것이 바로 입력 모드(Insert Mode)이다. 입력 모드로 전환해야만 우리가 익숙하게 사용하는 텍스트 입력이 가능해진다.

입력 모드로 들어가는 가장 기본적인 방법은 i 키를 누르는 것이다. i는 현재 커서 위치에서 바로 입력을 시작할 수 있게 해주며, 가장 자주 사용되는 명령어이다.

즉, Vim에서 글을 작성하기 위한 흐름은 다음과 같다. 먼저 i를 눌러 입력 모드로 전환한 뒤 내용을 작성하고, 입력이 끝나면 Esc를 눌러 다시 명령 모드로 돌아온다.

이 과정을 이해하는 것이 Vim 사용의 첫걸음이며, 사실상 가장 중요한 핵심 개념이라고 할 수 있다.

i

// i 누르면 바로 글 작성 가능

입력 모드 종료 — Esc

Vim에서 글을 입력하는 동안에는 ‘입력 모드(Insert Mode)’ 상태에 있게 된다. 이 상태에서는 우리가 일반적으로 사용하는 에디터처럼 키보드를 누르면 그대로 글자가 입력된다. 하지만 이 상태에서는 저장, 종료, 삭제와 같은 다양한 명령어를 사용할 수 없다.

Vim의 대부분 기능은 ‘명령 모드(Normal Mode)’에서 동작하기 때문에, 원하는 작업을 수행하려면 반드시 입력 모드에서 빠져나와야 한다. 이때 사용하는 키가 바로 Esc이다.

Esc 키를 누르면 현재 어떤 입력 상태에 있든지 즉시 명령 모드로 돌아가게 된다. 이 상태에서는 파일 저장(:wq), 종료(:q), 강제 종료(:q!), 줄 삭제(dd) 등 다양한 명령어를 실행할 수 있다.

특히 Vim을 사용할 때 문제가 생겼다고 느껴질 경우, 가장 먼저 눌러야 할 키도 Esc이다. 잘못된 모드에 들어가 있거나 예상과 다른 동작이 발생할 때, Esc를 누르면 기본 상태로 돌아가기 때문에 대부분의 상황을 안정적으로 정리할 수 있다.

따라서 Esc는 단순히 입력을 끝내는 키가 아니라, Vim을 사용하는 전체 흐름에서 중심이 되는 매우 중요한 키라고 할 수 있다.

Esc

// 모든 문제의 시작과 끝 (막히면 무조건 Esc)

저장하고 종료 — :wq

Vim에서 작업한 내용을 파일에 반영하고 편집기를 종료하려면 반드시 저장 명령어를 사용해야 한다. 이때 가장 많이 사용되는 명령어가 바로 :wq이다.

:wq는 두 가지 동작을 한 번에 수행하는 명령어이다. 먼저 w(write)는 현재까지 작성한 내용을 파일에 저장하는 역할을 하고, q(quit)는 Vim을 종료하는 역할을 한다. 즉, :wq는 “저장하고 종료한다”는 의미를 가진다.

이 명령어는 반드시 명령 모드(Normal Mode)에서 입력해야 한다. 따라서 먼저 Esc를 눌러 입력 모드에서 빠져나온 뒤, :를 입력하면 화면 하단에 명령어를 입력할 수 있는 영역이 나타난다. 그 다음 wq를 입력하고 Enter를 누르면 저장과 동시에 Vim이 종료된다.

Git에서 merge나 commit을 수행할 때 자동으로 Vim이 열리는 경우가 많은데, 이때도 동일하게 :wq를 입력하면 메시지가 저장되면서 작업이 정상적으로 완료된다. 만약 이 과정을 모르고 창을 닫아버리면 작업이 취소될 수 있기 때문에 반드시 알아두어야 한다.

따라서 :wq는 Vim을 사용하는 과정에서 가장 자주 사용되는 핵심 명령어이며, 사실상 Vim 사용의 마무리를 담당하는 필수 명령어라고 할 수 있다.

:wq

// 저장 + 종료 한 번에 처리
// Git merge, commit 할 때 필수

저장 없이 종료 — :q!

Vim을 사용하다 보면 파일을 수정했지만 그 내용을 저장하지 않고 종료해야 하는 상황이 발생할 수 있다.

예를 들어, 실수로 파일을 열었거나 변경 내용을 적용하고 싶지 않을 때가 그렇다. 이때 사용하는 명령어가 바로 :q!이다.

:q!는 강제로 종료하는 명령어로, 현재까지의 변경 사항을 모두 무시하고 Vim을 종료한다. 여기서 q(quit)는 종료를 의미하고, !는 강제 실행을 의미한다. 즉, 저장 여부를 묻지 않고 바로 종료하겠다는 뜻이다.

이 명령어 역시 명령 모드(Normal Mode)에서 입력해야 한다. 먼저 Esc를 눌러 입력 모드에서 빠져나온 뒤, :를 입력하고 q!를 입력한 후 Enter를 누르면 즉시 Vim이 종료된다.

특히 Git 작업 중 커밋 메시지 작성 화면이나 merge 메시지 입력 화면에서 “이 작업을 취소하고 싶다”는 경우에도 :q!를 사용하면 해당 작업을 저장하지 않고 빠져나올 수 있다. 잘못된 메시지를 입력했거나, 작업을 다시 진행하고 싶을 때 유용하게 사용할 수 있다.

따라서 :q!는 단순한 종료 명령어가 아니라, 실수를 되돌리고 안전하게 작업을 취소할 수 있도록 도와주는 중요한 명령어라고 할 수 있다.

:q!

// 변경 내용 무시하고 강제 종료

한 줄 삭제 — dd

Vim에서 코드를 수정하다 보면 특정 줄을 통째로 삭제해야 하는 경우가 자주 발생한다. 이때 사용하는 가장 기본적인 명령어가 바로 dd이다.

dd는 현재 커서가 위치한 한 줄 전체를 삭제하는 명령어이다. 단순히 글자를 하나씩 지우는 것이 아니라, 줄 단위로 빠르게 제거할 수 있기 때문에 코드 정리나 수정 작업에서 매우 효율적이다.

이 명령어는 명령 모드(Normal Mode)에서 사용해야 하므로, 먼저 Esc를 눌러 입력 모드에서 빠져나온 뒤 dd를 입력하면 된다. 입력과 동시에 해당 줄이 즉시 삭제된다.

또한 dd는 단순 삭제뿐만 아니라 “잘라내기(cut)” 개념으로 동작한다. 삭제된 내용은 Vim 내부 버퍼에 저장되기 때문에, 이후 p 명령어를 사용하면 해당 내용을 다시 붙여넣을 수도 있다. 즉, dd는 줄 삭제와 동시에 이동까지 가능한 강력한 명령어이다.

추가로, 숫자와 함께 사용하면 여러 줄을 한 번에 삭제할 수도 있다. 예를 들어 3dd를 입력하면 현재 줄부터 아래로 3줄이 한 번에 삭제된다.

따라서 dd는 단순하지만 활용도가 매우 높은 명령어로, Vim에서의 코드 수정 속도를 크게 높여주는 핵심 기능 중 하나라고 할 수 있다.

dd

// 현재 줄 통째로 삭제

Google Search Console TXT 인증 오류 해결 방법

TTH — Mon, 29 Dec 2025 17:02:29 +0900

Google Search Console TXT 인증 오류 해결 방법

Google Search Console에서 도메인을 인증하려고 할 때 아래와 같은 오류가 발생하는 경우가 있다.

확인 방법:
도메인 이름 공급업체

실패 이유:
도메인의 TXT 레코드에서 인증 토큰을 찾을 수 없습니다. 변경된 DNS가 표시되는 데는 시간이 소요될 수 있습니다. 몇 시간 정도 기다린 후 Search Console에서 속성을 다시 열어 보세요. 인증에 다시 실패하면 다른 DNS TXT 레코드를 추가해 보시기 바랍니다.

이 오류는 Search Console이 도메인 DNS에 등록된 TXT 레코드를 아직 찾지 못했을 때 발생하는 일반적인 현상이다.
아래는 이 오류가 발생하는 이유와 해결 방법이다.

TXT 레코드가 루트 도메인에 추가되지 않은 경우

Google Search Console의 도메인 속성 인증은 항상 루트 도메인(예: my-domain.com) 의 TXT 레코드를 검사한다.
서브도메인(test.my-domain.com)에 TXT를 추가하면 절대 인증되지 않는다.

해결 방법
DNS 설정에서 TXT 레코드의 이름(Host)을 반드시 아래 중 하나로 설정해야 한다.

@
my-domain.com

TXT 레코드가 이미 존재해 추가할 수 없는 경우

도메인 업체에 따라 동일한 이름의 TXT 레코드를 여러 개 생성하지 못하는 경우가 있다. 이때는 기존 TXT 레코드를 수정하여 값만 추가해야 한다.

예시

기존 값 예시:
v=spf1 include:_spf.google.com ~all

Google 인증 값을 추가한 형태

v=spf1 include:_spf.google.com ~all
google-site-verification=JRbzFIhxsxPrxM117cMZN6g4_nVd3ZlwHBmkmHD7yIo

DNS 전파가 완료되지 않은 경우

DNS 변경 사항이 전 세계 DNS 서버에 반영되는 데는 시간이 필요하다.

도메인 업체 및 TTL 값에 따라 다르지만 보통 다음과 같은 시간이 걸린다.

상황	소요 시간
평균 전파	5분 ~ 1시간
늦을 경우	6시간 ~ 24시간
최악의 경우	최대 48시간

TXT 값이 정상적으로 등록되었더라도 Google이 아직 해당 값을 조회하지 못했기 때문에 오류가 나타날 수 있다.

DNS에 TXT가 제대로 들어갔는지 확인하는 방법

DNS가 제대로 적용되었는지 확인하기 위해서는 Google Admin Toolbox의 DIG 도구를 사용하는 것이 가장 정확하다.

확인 순서

1. https://toolbox.googleapps.com/apps/dig 접속
2. 검색 창에 my-domain.com 입력
3. Record Type을 TXT로 선택
4. 결과에서 google-site-verification=... 값이 보이는지 확인

만약 해당 TXT 값이 보이지 않는다면 DNS가 아직 반영되지 않은 것이고, 보이는데도 Search Console 인증이 실패한다면 약간 더 기다리면 된다.

그래도 인증이 안 되는 경우

아래 문제들이 있을 수 있다.

- TXT 값에 공백이나 오타가 있음
- TXT 값에 따옴표를 넣어 입력해야 하는데 넣지 않았거나 반대의 경우
- TTL 값이 지나치게 길게 설정됨
- Cloudflare를 사용하는 경우 “프록시”가 활성화된 상태

이 경우 설정을 다시 확인하거나 오류 부분을 수정해야 한다.

결론

이 오류는 대부분 DNS 반영 지연, 잘못된 TXT 위치, 기존 TXT 레코드 오입력 때문에 발생하는 문제이다.

DNS 조회 도구로 값이 실제로 확인되는지 체크한 뒤, 몇 시간 후 다시 인증을 시도하면 대부분 해결된다.

프론트엔드 개발자가 알아야 할 회원가입 시 이메일 대소문자 처리 기준

TTH — Wed, 24 Dec 2025 16:28:23 +0900

회원가입과 로그인 기능을 구현하다 보면 한 번쯤 고민하게 되는 문제가 있다.

이메일은 대소문자를 구분해야 할까?

결론부터 말하면, 프론트엔드에서는 이메일을 항상 소문자로 통일해서 처리하는 것이 실무적으로 가장 안전한 선택이다. 이 글에서는 그 이유와 프론트엔드에서의 올바른 처리 방법을 정리해보겠다.

이메일 대소문자에 대한 이론적 기준

이메일 주소는 RFC 표준에 따라 @ 기호를 기준으로 두 부분으로 나뉜다. 앞부분인 local-part는 이론적으로 대소문자를 구분할 수 있도록 정의되어 있으며, 뒷부분인 domain-part는 대소문자를 구분하지 않는 것이 원칙이다. 즉, 표준 문서만 놓고 보면 이메일 주소의 구조상 대소문자 구분 가능성이 일부 존재한다.

이러한 규칙에 따르면 Test@Example.com과 test@example.com은 기술적으로 서로 다른 이메일 주소가 될 수 있다. local-part인 Test와 test가 대소문자가 다르기 때문이다. 하지만 이는 어디까지나 표준상의 이론적인 해석에 가깝다.

실제 서비스 환경에서는 대부분의 이메일 제공자가 local-part 역시 대소문자를 구분하지 않으며, 사용자 또한 이를 동일한 이메일로 인식한다. 그 결과, RFC 표준에서 허용하는 이론적 가능성과 달리 실무에서는 이메일 대소문자를 구분하지 않는 것이 사실상의 기준으로 자리 잡았다.

local-part@domain-part

local-part (@ 앞 부분): 이론적으로 대소문자 구분 가능
domain-part (@ 뒤 부분): 대소문자 구분 불가

하지만 실무에서는 다르다

현실적으로는 Gmail, Naver, Kakao, Outlook 등 대부분의 이메일 서비스가 대소문자를 구분하지 않는다. 사용자 역시 대소문자가 다르면 다른 계정이라고 인식하지 않는다. 이로 인해 이메일 대소문자를 구분하게 되면 다음과 같은 문제가 발생할 수 있다.

만약 회원가입은 Test@email.com으로 하고, 로그인은 test@email.com으로 한다면 “존재하지 않는 계정”으로 오류 발생하고 실무에서는 이런 동작을 버그로 본다.

프론트엔드에서의 권장 처리 방식

이메일은 항상 소문자로 정규화(normalize)하기

프론트엔드에서는 이메일을 사용자 입력값 그대로 서버에 전달하기보다, 항상 소문자로 정규화(normalize)한 뒤 전송하는 것이 좋다. 이렇게 하면 사용자가 대소문자를 섞어 입력하더라도 시스템 내부에서는 일관된 기준으로 이메일을 처리할 수 있어, 회원가입과 로그인 과정에서 발생할 수 있는 오류를 예방할 수 있다.

이메일 정규화 과정에서는 두 가지 처리가 핵심이다. 먼저 trim()을 사용해 앞뒤에 포함된 불필요한 공백을 제거하고, 이어서 toLowerCase()를 적용해 모든 문자를 소문자로 변환한다. 이 과정을 거친 이메일 값은 인증과 식별을 위한 기준값으로 사용되며, 데이터의 일관성과 안정성을 높이는 데 중요한 역할을 한다.

const normalizedEmail = email.trim().toLowerCase();

trim() : 불필요한 공백 제거

toLowerCase() : 대소문자 통일

회원가입 / 로그인 / 중복 체크 모두 동일한 규칙 사용

이메일 처리 규칙은 특정 기능에만 적용해서는 안 되며, 회원가입·로그인·이메일 중복 체크·비밀번호 재설정 등 이메일을 사용하는 모든 흐름에서 동일하게 적용되어야 한다. 한 기능에서는 소문자로 처리하고 다른 기능에서는 원본 값을 그대로 사용한다면, 계정은 존재하지만 접근할 수 없는 상황과 같은 문제가 발생할 수 있다.

따라서 모든 요청에서 이메일을 동일한 방식으로 정규화한 뒤 서버에 전달해야 한다. 예를 들어 중복 체크 역시 회원가입이나 로그인과 동일하게 소문자로 변환된 값을 기준으로 수행해야 한다. 이처럼 규칙을 일관되게 유지하지 않으면 사용자는 시스템이 불안정하다고 느끼게 되며, 전반적인 사용자 경험에도 부정적인 영향을 미치게 된다.

await checkEmail(email.trim().toLowerCase());

규칙이 하나라도 다르면 사용자 경험에 문제가 생긴다.

UI 표시와 인증 로직은 분리

UX 측면에서는 두 가지 선택이 가능하다.

입력창에 바로 소문자로 변환하거나, 입력값은 그대로 두고 전송 시점에만 변환하는 방법이다. 실무에서는 보통 전송 직전에만 소문자로 변환하는 방식을 많이 사용한다.

React + TypeScript 기준 추천 유틸 함수
여러 곳에서 동일한 처리를 하기 위해 유틸 함수로 분리하는 것이 좋다.

export const normalizeEmail = (email: string) =>
  email.trim().toLowerCase();

const payload = {
  email: normalizeEmail(email),
  password,
};

프론트엔드와 백엔드 역할 분리

구분	프론트엔드	백엔드
이메일 소문자 처리	전처리	최종 검증
중복 계정 방지	X	UNIQUE 제약
보안 책임	X	O

프론트엔드에서 처리하더라도, 백엔드에서도 반드시 동일한 처리가 필요하다.

프론트엔드는 UX 개선이 목적이고, 백엔드는 데이터 무결성 보장이 목적이다.

주의해야 할 포인트

이메일을 사용자 ID로 사용하는 경우에는 이메일 컬럼이 대소문자를 구분하지 않는 유니크 값으로 관리되어야 한다. 사용자가 어떤 형태로 이메일을 입력하더라도 동일한 계정으로 인식되도록, 프론트엔드와 백엔드 모두 이메일을 소문자로 통일한다는 전제를 기반으로 설계하는 것이 중요하다. 이 기준이 명확하지 않으면 중복 가입이나 로그인 오류와 같은 문제가 발생할 수 있다.

또한 이메일은 인증을 위한 값과 화면에 표시되는 값의 역할을 구분해서 다루는 것이 좋다. 인증 로직에서는 이메일을 항상 소문자로 변환해 일관된 기준으로 처리하고, 화면에 표시할 때는 사용자가 입력한 원래 형태의 이메일을 그대로 보여줄 수 있다. 이렇게 역할을 분리하면 시스템 안정성을 유지하면서도 사용자 경험을 해치지 않을 수 있다.

이메일 대소문자 처리는 이론적인 표준보다 실무 기준을 우선하는 것이 중요하다. RFC 표준상으로는 이메일의 일부가 대소문자를 구분할 수 있지만, 실제 서비스 환경에서는 대부분의 이메일 제공자가 이를 구분하지 않고 사용자 역시 동일한 주소로 인식한다. 따라서 대소문자를 구분하는 로직은 사용자 혼란과 인증 오류를 유발할 가능성이 크다.

이런 이유로 프론트엔드에서는 이메일을 입력값 그대로 신뢰하기보다, 항상 소문자로 정규화(normalize) 해서 처리하는 것이 안전하다. 공백을 제거하고 소문자로 변환한 뒤 서버에 전달하면, 사용자가 어떤 형태로 입력하더라도 동일한 기준으로 계정을 식별할 수 있다.

또한 이 규칙은 회원가입에만 적용해서는 안 된다. 로그인, 이메일 중복 체크, 비밀번호 재설정 등 이메일을 사용하는 모든 흐름에서 동일한 규칙을 일관되게 적용해야 한다. 한 단계라도 다른 기준을 사용하면 “가입은 됐는데 로그인이 안 되는” 문제와 같은 버그로 이어질 수 있다.

마지막으로, 프론트엔드에서 이메일을 소문자로 처리하더라도 백엔드에서도 반드시 동일한 로직으로 다시 한 번 검증해야 한다. 프론트엔드는 사용자 경험과 입력 보정을 담당하고, 백엔드는 데이터 무결성과 보안을 책임진다. 이 두 영역이 같은 기준을 공유할 때, 안정적인 회원 시스템을 만들 수 있다.

웹사이트 관리자라면 꼭 알아야 할 Google Admin Toolbox 기능 정리

TTH — Sun, 14 Dec 2025 21:50:16 +0900

구글 관리 콘솔 도구 상자란?

구글 관리 콘솔 도구 상자(Google Admin Toolbox)는 Google에서 제공하는 네트워크·DNS·메일·도메인 관련 문제를 진단하기 위한 공식 기술 도구 모음이다. 개발자나 서버 관리자가 DNS 오류, 메일 전송 문제, SPF/DKIM/DMARC 설정, 도메인 소유권 문제 등을 해결할 때 아주 자주 사용하는 툴이다.

DIG, DNS 상태를 확인하는 도구

DIG는 Google DNS 서버(8.8.8.8)를 기준으로 도메인의 DNS 정보를 실시간으로 조회할 수 있는 도구이다.
DNS 관련 문제를 해결할 때 가장 많이 사용되는 핵심 도구이다.

DIG로 확인할 수 있는 정보

A / AAAA 레코드
CNAME 레코드
TXT 레코드
MX 레코드
NS, SOA 정보
DNS 전파 여부

DIG가 필요한 상황

Search Console 소유권 인증이 실패할 때
TXT 레코드가 제대로 들어갔는지 확인할 때
DNS 설정이 정상적으로 전파되고 있는지 체크할 때

Check MX, 이메일 설정 오류를 점검하는 도구

Check MX는 도메인의 메일 시스템 구성을 검사해 주는 도구이다.
이메일 발송 오류, 수신 불가, 스팸 분류 등 메일 문제를 해결할 때 유용하다.

Check MX로 확인할 수 있는 항목

MX 레코드 구성
SPF 레코드 정상 여부
DKIM 설정 여부
DMARC 정책 여부
이메일 인증 오류 원인 분석

Messageheader, 메일 전달 경로를 분석하는 도구

Messageheader 도구는 이메일 헤더 정보를 분석하여 메일이 어떤 서버를 거쳐 전달되었는지, 인증은 제대로 되었는지 등을 보여준다.

확인 가능한 정보

SPF 통과 여부
DKIM 서명 여부
DMARC 적용 여부
중간 SMTP 서버 경로
지연된 지점 및 문제 발생 위치
이메일이 스팸함으로 가거나 전달되지 않을 때 원인을 파악하는데 사용

HAR Analyzer, 웹사이트 문제를 분석하는 도구

HAR Analyzer는 브라우저에서 저장한 HAR(Network Log) 파일을 분석해
HTTP 요청 및 응답을 시각적으로 보여주는 도구이다.

HAR Analyzer가 유용한 상황

웹사이트 로딩 시간이 비정상적으로 느릴 때
이미지·API 요청이 실패할 때
CORS 문제나 인증 문제를 확인할 때
리디렉션 루프가 있는지 확인할 때

마치며

구글 관리 콘솔 도구 상자에는 위의 주요 도구 외에도 보안 설정 점검, 계정 관련 문제 분석 등 다양한 관리 도구들이 포함되어 있다.

정리하면 구글 관리 콘솔 도구 상자는 DNS 문제, 이메일 문제, 도메인 인증 문제를 해결하기 위해 반드시 알아야 하는 필수 진단 도구 모음이다. DNS가 잘못됐는지 확인하고 싶다면 DIG, 이메일 발송·수신 문제가 있다면 Check MX, 메일 인증이나 경로 문제를 분석하고 싶다면 Messageheader, 웹사이트 네트워크 오류를 분석하고 싶다면 HAR Analyzer, 이렇게 목적에 맞게 사용하면 대부분의 기술 문제를 효율적으로 해결할 수 있다.

React Server Components(RSC) 보안 취약점 발견 및 공식 패치 발표 정리 (2025)

TTH — Tue, 9 Dec 2025 15:27:22 +0900

2025년 12월, React 생태계에 큰 영향을 미치는 중대 보안 취약점이 공개되었다. 특히 React Server Components(RSC)를 사용하는 프로젝트에서 인증 없이 원격 코드 실행(Remote Code Execution, RCE)이 가능해질 수 있는 치명적인 문제였다.

React 팀은 즉시 패치를 배포했고, 전 세계 개발자들에게 빠른 업데이트를 권고하고 있다. 이 글에서는 해당 취약점의 원인, 영향 범위, 해결 방법을 쉽게 이해할 수 있도록 정리해보았다.

RSC에서 어떤 취약점이 발생했나?

문제는 RSC가 서버와 클라이언트 사이에서 데이터를 교환할 때 사용하는 “Flight 프로토콜”의 페이로드 검증 부족이 원인이었다.

그 결과 인증 없이도 공격자가 서버에 악의적인 요청을 보낼 수 있고, 그 요청이 서버에서 바로 **임의의 JavaScript 코드 실행(RCE)**로 이어질 수 있었다.

즉, 로그인이나 토큰이 없어도 서버에 침투가 가능한 최악의 보안 시나리오가 현실화될 수 있었던 것이다.

왜 이렇게 심각한가?

이 취약점은 CVSS 10.0점(최고 위험 등급)을 받을 만큼 심각한 문제로, 단순한 정보 유출을 넘어 서버 자체가 공격자에게 장악될 수 있는 수준이며, 일부 보안업체는 클라우드 환경의 약 40%가 잠재적으로 영향권에 있다고 분석하고 있다. 또한 이미 공개된 개념증명(PoC)을 바탕으로 실제 공격 시도가 보고되고 있는 상황이어서, 즉각적인 패치 적용이 필수적이다.

어떤 환경이 영향을 받았나?

React Server Components(RSC) 기반 패키지인 react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack의 19.0.0, 19.1.0–19.1.1, 19.2.0 버전에서 심각한 보안 취약점이 발견되었으며, RSC를 사용하는 Next.js 14.x(카나리 포함)와 Next.js 15.x·16.x의 일부 버전 또한 동일한 취약점의 영향을 받은 것으로 확인되었다. 따라서 서버 사이드 렌더링 구조를 사용하는 프로젝트, 특히 App Router 기반의 Next.js 프로젝트는 대부분 위험에 노출되었을 가능성이 높아, 즉각적인 버전 점검과 업데이트가 필요하다.

다음 취약한 버전으로 분류된 React RSC 패키지들은 다음과 같다.

취약 버전

react-server-dom-webpack

react-server-dom-parcel

react-server-dom-turbopack
→ 19.0.0, 19.1.0–19.1.1, 19.2.0

RSC 기반으로 동작

Next.js 14.x (Canary 포함)

Next.js 15.x / 16.x 일부 버전

따라서 App Router를 사용하는 Next.js 프로젝트는 대부분 위험에 노출되었을 가능성이 있다.

React 팀이 발표한 보안 패치 내용

React 팀은 이번 취약점을 공개함과 동시에 react-server-dom-* 패키지의 19.0.1, 19.1.2, 19.2.1 버전을 포함한 보안 패치를 즉시 배포했으며, RSC를 사용하는 Next.js 역시 취약 버전 사용자를 대상으로 최신 안정 버전으로 즉시 업데이트할 것을 강력히 권고했다. 또한 단순히 패키지만 업데이트하는 것으로는 충분하지 않기 때문에, 업데이트 후 반드시 프로젝트를 다시 빌드하고 재배포해야 패치가 실제로 적용되어 보안 위험을 완전히 해소할 수 있다.

react-server-dom-* 패키지:
→ 19.0.1, 19.1.2, 19.2.1

패치된 안전 버전

react-server-dom-* 패키지:
→ 19.0.1, 19.1.2, 19.2.1

Next.js

→ 취약 버전 사용자에게 최신 안정 버전으로 즉시 업데이트 권고

단순히 패키지를 업데이트하는 것 뿐만 아니라, 업데이트 후 반드시 빌드와 재배포를 다시 해야 패치가 실제로 적용된다.

패치 적용이 어려울 때의 임시 대응책

만약 즉시 업데이트가 어려운 경우에는 RSC 관련 엔드포인트(예: /_flight)에 대한 접근을 제한하거나, WAF(웹 방화벽)를 이용해 비정상적인 Flight 요청을 차단하고, 미들웨어에서 페이로드 구조를 강화하는 방식으로 위험을 최소화할 수 있지만, 이러한 방법들은 어디까지나 임시 대응에 불과하며 근본적인 해결책은 보안 패치를 적용하고 시스템을 재빌드·재배포하는 것이라는 점을 반드시 고려해야 한다.

RSC 관련 엔드포인트(예: /_flight)에 대한 접근 제한
WAF(웹 방화벽)에서 비정상적인 Flight 요청 차단
미들웨어에서 페이로드 구조 검증 강화

물론, 이는 일시적 조치일 뿐이며 근본 해결은 패치 적용이다.

개발자가 반드시 해야 할 것

개발자는 이번 취약점에 대응하기 위해 React 및 Next.js 패키지를 최신 보안 패치 버전으로 업데이트한 뒤, 프로젝트를 반드시 재빌드하고 재배포해야 하며, 배포 이후에는 서버 로그를 점검하고 비정상적인 Flight 요청 여부를 지속적으로 모니터링해야 한다. 또한 향후 유사한 보안 문제에 신속히 대응하기 위해 공식 보안 공지를 구독하거나 자동 보안 업데이트 설정을 적용해두는 것이 권장된다.

1. React 및 Next.js 패키지를 최신 버전으로 업데이트

2. 프로젝트 재빌드 → 재배포
3. 배포 후 서버 로그 확인, 비정상 Flight 요청 모니터링

4. 보안 공지 구독 또는 자동 보안 업데이트 설정

마치며

이번 이슈는 RSC를 기반으로 한 최신 웹 개발 방식이 생각보다 복잡한 보안 구조 위에 있다는 사실을 다시 한번 보여준 사건이었다. React 팀이 빠르게 대응해 패치를 내놓으면서 큰 문제는 막을 수 있었지만, 실제 프로젝트를 운영하는 개발자 입장에서는 직접 업데이트를 적용하고 점검하는 일이 가장 중요하다.

만약 React Server Components나 Next.js App Router를 사용하고 있다면, 지금 한 번 버전과 설정을 점검해보는 것이 좋을 듯 싶다. 작은 업데이트 하나가 전체 서비스의 안전을 지켜줄 수 있기 때문이다.

프론트(React)에서 안전하게 AWS S3에 직접 업로드하기, Presigned URL

TTH — Tue, 18 Nov 2025 10:32:53 +0900

Presigned URL을 사용하는 이유

일반적인 파일 업로드 방식은 프론트에서 백엔드로 파일을 보내고, 백엔드가 다시 S3로 업로드하는 구조라서 파일이 클수록 서버 부하가 커지고, 다중 파일 업로드에서는 백엔드가 모든 스트림을 처리해야 해 비효율적이다. 반면 Presigned URL 방식은 프론트가 백엔드에 업로드용 URL 생성만 요청하고, 백엔드는 이를 반환한 뒤 파일 데이터는 전혀 받지 않으며, 프론트가 해당 URL로 직접 S3에 업로드하기 때문에 백엔드 부하 없이 더 빠르고 안정적인 업로드가 가능해진다.

일반적인 업로드 방식	Presigned URL
1. 프론트가 백엔드로 파일 전송 2. 백엔드가 S3로 파일 어볼드 3. 업로드 성공 후 URL 반환	1. 프론트가 백엔드에 업로드 URL 생성 요청 2. 백엔드가 Presigned URL 반환 3. 프론트가 S3에 직접 업로드

Presigned URL 업로드의 기본 원리

“S3가 업로드를 허용하는 비밀 링크를 백엔드에서 생성하고 프론트에 던져주는 것”

Presigned URL은 S3가 일정 시간 동안만 유효한 업로드 전용 임시 인증 링크를 발급하는 방식으로, 백엔드가 이 비밀 링크를 생성해 프론트에 전달하면 프론트가 해당 URL로 직접 PUT 요청을 보내 S3에 곧바로 파일을 저장할 수 있게 해주는 구조이다.

해당 URL은 일정 시간 동안만 유효하며, 이 URL로 PUT 요청을 보내면 곧바로 S3에 저장된다.

단일 파일 업로드 구현 (프론트 코드 예시)

단일 파일 업로드의 흐름은 아래와 같다.

1. 서버에 presigned URL 발급 요청
2. 서버가 URL 반환
3. 해당 URL로 PUT 요청하여 파일 업로드
4. 업로드된 S3 경로 반환

async function uploadToS3UsingPresignedURL(file) {
  const res = await fetch("https://api.softlanders.com/api/test-s3-upload4", {
    method: "POST",
    headers: {"Content-Type": "application/json"},
    body: JSON.stringify({
      filename: file.name,
      folder: "test_folder",
      content_type: file.type
    })
  });

  const result = await res.json();
  if (result.status !== "success") {
    console.error("Presigned URL 생성 실패:", result.error);
    return;
  }

  const { upload_url, s3_key } = result;

  const uploadRes = await fetch(upload_url, {
    method: "PUT",
    headers: {
      "Content-Type": file.type
    },
    body: file
  });

  if (uploadRes.ok) {
    console.log(`업로드 성공! S3 경로: ${s3_key}`);
  } else {
    console.error("S3 업로드 실패:", uploadRes.status);
  }
}

다중 파일 업로드 구조 설계

다중 파일 업로드의 핵심은 프론트에서 파일 자체가 아니라 파일 이름 목록만 백엔드로 전달하면, 백엔드가 이 이름들을 기준으로 여러 개의 Presigned URL을 생성해 배열 형태로 반환하고, 프론트는 해당 배열을 순회하면서 각 URL로 파일을 직접 S3에 업로드하는 구조라는 점이다.

프론트	백엔드
백엔드로 파일 이름 목록만 전달	프론트로 URL 배열 반환
백엔드는 이 이름 기준으로 Presigned URL을 여러 개 발급한다.	프론트는 이 배열을 돌면서 각각 S3 업로드를 실행한다.

즉, 두 단계 요청을 반드시 분리해야 한다.

실제 다중 파일 업로드 코드

1차 요청, presigned URL 요청

const res = await fetch("https://api.softlanders.com/api/admin_dashboard_quote_write", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    ID1: id1,
    ID2: id2,
    business_register_number: brn,
    currency: currency,
    quotes: JSON.stringify(quotes),
    quote_description: desc,
    files: files.map(f => f.name) // 파일 이름만 전송
  })
});

2차 요청, Presigned URL에 실제 업로드

for (const { upload_url, s3_key } of result.presigned_urls) {
  const file = files.find(f => s3_key.endsWith(f.name));
  const uploadRes = await fetch(upload_url, {
    method: "PUT",
    body: file
  });

  if (!uploadRes.ok) {
    console.error("S3 업로드 실패:", s3_key);
  } else {
    console.log("업로드 성공:", s3_key);
  }
}

개발 중 마주친 문제와 해결 방법

문제 1: PUT 요청에 Content-Type 헤더를 넣으면 실패함
AWS S3 Presigned URL 중 v4 방식은 Content-Type이 사전에 지정된 경우에만 허용된다.
서버에서 Content-Type을 지정하지 않은 상태라면 프론트에서 넣지 말아야 한다.

문제 2: 파일 이름이 겹치면 덮어쓰임
파일 이름을 통일해 저장하면 충돌이 발생한다.
그래서 보통은 백엔드에서 다음과 같은 방식을 사용한다.

UUID + 원본 파일명
timestamp + filename
사용자 ID 기반 디렉토리 분리

문제 3: CORS 오류
S3 버킷 CORS 설정에 반드시 아래 항목이 있어야 한다

PUT
Content-Type

마무리하며

Presigned URL 방식은 프론트와 백엔드 모두에게 이점이 많다. 특히 다중 파일 업로드에서는 이 방식이 거의 정석이다.

백엔드 서버 부하 감소
업로드 속도 향상
대용량 파일 처리 가능
구조적으로 안전함

프로젝트를 진행하면서 느낀 점은, Presigned URL 구조만 잘 설계해두면 나머지는 매우 단순하고 직관적으로 구현된다는 점이다.
앞으로 대용량 파일 업로드가 필요한 다른 기능에도 적극적으로 적용해 볼 생각이다.

프론트엔드 개발자가 업무할 때 자주 쓰는 자바스크립트 내장 함수 10개

TTH — Wed, 5 Nov 2025 16:03:52 +0900

프론트엔드 개발을 하다 보면 수많은 내장 함수를 마주하게 된다.

그중에서도 업무에서 자주 쓰이고, 꼭 알아두면 유용한 함수 10가지를 정리해보았다.

이 함수들은 React, Vue, 바닐라 JS 어디에서든 자주 등장한다.

console.log()

가장 기본적이지만, 가장 많이 쓰이는 함수이다.
디버깅을 하거나 값이 제대로 들어왔는지 확인할 때 사용한다.

console.log('현재 상태:', state);

코드 중간중간에 로그를 찍어두면 문제를 찾기 훨씬 쉽다.

document.querySelector()

HTML 요소를 선택할 때 사용하는 함수이다.

CSS 선택자 문법을 그대로 쓸 수 있어서 직관적이다.

const button = document.querySelector('#submitBtn');
button.addEventListener('click', () => alert('제출 완료!'));

getElementById()보다 더 유연하게 쓸 수 있다.

addEventListener()

이벤트를 등록할 때 쓰는 함수이다.
버튼 클릭, 입력 변화, 스크롤 등 다양한 이벤트를 감지할 수 있다.

window.addEventListener('scroll', () => console.log('스크롤 중'));

프론트엔드 인터랙션을 구현할 때 자주 사용된다.

setTimeout() / setInterval()

시간 관련 함수로, 일정 시간 뒤 실행하거나 반복 실행할 때 사용한다.

setTimeout(() => console.log('3초 후 실행'), 3000);
setInterval(() => console.log('반복 실행'), 1000);

애니메이션, 알림, 자동 갱신 기능 등에 자주 사용된다.

JSON.stringify() / JSON.parse()

객체와 JSON 문자열 간 변환을 할 때 사용하는 함수이다.
서버 통신이나 localStorage 저장 시 반드시 거쳐가는 과정이다.

const user = { name: '민준', age: 30 };
localStorage.setItem('user', JSON.stringify(user));
const storedUser = JSON.parse(localStorage.getItem('user'));

프론트엔드 데이터 관리의 기본 중 기본이다.

fetch()

서버와 통신할 때 사용하는 함수이다.

GET, POST 등 HTTP 요청을 보낼 수 있으며, 비동기 처리에 자주 쓰인다.

fetch('/api/data') .then(res => res.json()) .then(data => console.log(data));

React나 Vue에서 데이터를 불러올 때 거의 항상 등장하는 함수이다.

localStorage / sessionStorage

브라우저에 데이터를 저장할 때 쓰는 객체이다.
토큰, 로그인 정보, 사용자 설정값 등을 유지할 때 자주 사용된다.

localStorage.setItem('theme', 'dark'); const theme = localStorage.getItem('theme');

localStorage는 브라우저를 꺼도 유지되고, sessionStorage는 탭을 닫으면 사라진다.

Array.map() / filter() / forEach()

배열을 다룰 때 가장 자주 쓰이는 내장 함수들이다.
리스트 데이터를 렌더링하거나 가공할 때 필수적이다.

const users = ['준혁', '민준', '아라']; 
users.map(name => console.log(name)); // 각각 출력 
const filtered = users.filter(name => name !== '민준');

특히 React에서 .map()은 JSX 반복 렌더링에 자주 사용된다.

Object.keys() / Object.entries()

객체의 키나 값, 혹은 전체를 순회할 때 사용된다.

const user = { name: '세희', age: 30 }; 
console.log(Object.keys(user)); // ['name', 'age'] 
console.log(Object.entries(user)); // [['name', '세희'], ['age', 30]]

API 응답으로 받은 데이터를 다룰 때 유용하다.

Math.random() / Math.floor()

랜덤 값 생성이나 반올림, 올림, 내림 계산에 사용된다.

const randomNum = Math.floor(Math.random() * 10);
console.log(randomNum); // 0~9 사이의 정수

게임, 추첨, 랜덤 추천 등 다양한 기능에 쓰인다.

이 10가지 내장 함수는 프론트엔드 개발에서 거의 매일 쓰인다고 해도 과언이 아니다.
단순히 문법을 외우기보다는, “어떤 상황에서 어떤 함수를 쓰면 효율적인가”를 이해하는 것이 중요한 것 같다.

이 함수들만 잘 다뤄도 프론트엔드 코드의 70% 이상은 훨씬 깔끔해진다. 기본기지만, 결국 가장 강력한 무기이다.

개발자일지

[Flutter] GetX, 상태관리를 쉽게 만드는 라이브러리

GetX란?

GetX의 특징

GetX 설치

GetX 기본 사용 방법

폴더 구조 예시

GetX 장점

GetX 단점

GetX와 Riverpod 비교

[Flutter] 개념 정리 및 시작하기(window 설치, 프로젝트 생성)

Flutter란?

Flutter 설치하기

Flutter 프로젝트 생성하기

[ReactJS] useState - 상태(state)를 관리하기 위한 Hook

useState란?

useState 기본 사용법

배열 구조를 사용하는 이유

useState 동작 원리

잘못된 사용 방식과 올바른 사용방법

실무에서 자주 하는 실수, 이전 상태 기반 업데이트

다양한 데이터 타입 저장

핵심정리

개발자가 꼭 알아야 할 Vim 최소 명령어 5가지

1. 입력 모드 진입 — i

입력 모드 종료 — Esc

저장하고 종료 — :wq

저장 없이 종료 — :q!

한 줄 삭제 — dd

Google Search Console TXT 인증 오류 해결 방법

Google Search Console TXT 인증 오류 해결 방법

TXT 레코드가 루트 도메인에 추가되지 않은 경우

TXT 레코드가 이미 존재해 추가할 수 없는 경우

DNS 전파가 완료되지 않은 경우

DNS에 TXT가 제대로 들어갔는지 확인하는 방법

그래도 인증이 안 되는 경우

결론

프론트엔드 개발자가 알아야 할 회원가입 시 이메일 대소문자 처리 기준

이메일 대소문자에 대한 이론적 기준

하지만 실무에서는 다르다

프론트엔드에서의 권장 처리 방식

이메일은 항상 소문자로 정규화(normalize)하기

회원가입 / 로그인 / 중복 체크 모두 동일한 규칙 사용

UI 표시와 인증 로직은 분리

프론트엔드와 백엔드 역할 분리

주의해야 할 포인트

웹사이트 관리자라면 꼭 알아야 할 Google Admin Toolbox 기능 정리

구글 관리 콘솔 도구 상자란?

DIG, DNS 상태를 확인하는 도구

Check MX, 이메일 설정 오류를 점검하는 도구

Messageheader, 메일 전달 경로를 분석하는 도구

HAR Analyzer, 웹사이트 문제를 분석하는 도구

마치며

React Server Components(RSC) 보안 취약점 발견 및 공식 패치 발표 정리 (2025)

RSC에서 어떤 취약점이 발생했나?

왜 이렇게 심각한가?

어떤 환경이 영향을 받았나?

React 팀이 발표한 보안 패치 내용

패치 적용이 어려울 때의 임시 대응책

개발자가 반드시 해야 할 것

마치며

관련기사

프론트(React)에서 안전하게 AWS S3에 직접 업로드하기, Presigned URL

Presigned URL을 사용하는 이유

Presigned URL 업로드의 기본 원리

단일 파일 업로드 구현 (프론트 코드 예시)

다중 파일 업로드 구조 설계

실제 다중 파일 업로드 코드

개발 중 마주친 문제와 해결 방법

마무리하며

프론트엔드 개발자가 업무할 때 자주 쓰는 자바스크립트 내장 함수 10개

console.log()

document.querySelector()

addEventListener()

setTimeout() / setInterval()

JSON.stringify() / JSON.parse()

fetch()

localStorage / sessionStorage

Array.map() / filter() / forEach()

Object.keys() / Object.entries()