내가 보려고 만든 블로그

Flutter Flavor 완전 정복: 개발/운영 환경 완벽 분리 가이드 (feat. .env, Android & iOS)

나나나나나나나ㅏ나난ㄴ나ㅏ나나 — Wed, 3 Sep 2025 19:43:29 +0900

정----말 오랜만에 Flutter로 사이드 프로젝트를 시작했습니다. 한동안 손 놓고 있던 사이에 Flutter 버전은 2.x대에서 3.x대로 훌쩍 업데이트되었고, 그러면서 바뀐 점들도 꽤 있더라고요.

프로젝트를 진행하며 알게 된 몇 가지를 정리해 보려고 합니다. 그 첫 번째 타자가 바로 Flavor! 그럼 시작해 볼까요?

Flavor란?

프로젝트를 진행하거나 출시하다 보면 하나의 소스 코드로 여러 환경에 맞춰 앱을 빌드해야 할 때가 많습니다. 개발, 스테이징, 운영 등등.. 각 환경은 서로 다른 API 주소나 앱 이름, 아이콘을 가져와야 하죠. 만약 이런 설정을 수동으로 변경한다면 개발 서버를 바라봐야 할 앱이 운영 서버를 본다거나 하는 크리티컬한 실수를 피하기 쉽지 않습니다.

Flutter의 Flavor는 이런 문제를 해결하기 위한 공식적인 기능입니다. 다음에 또 허둥댈 저를 위해, 처음부터 끝까지 정리해 보겠습니다!

1단계: 환경별 main 파일 및 설정 파일 생성

가장 먼저 Dart 코드 단에서 각 환경을 구분할 수 있는 파일을 만들어 줍니다.

1. 환경별 진입점, main_ 파일 만들기

lib 폴더 안에 각 환경의 시작점이 될 파일을 생성해 줍니다. 이 파일의 역할은 앱이 어떤 Flavor로 실행되어야 하는지 알려주는 것입니다.

lib/main_dev.dart

import 'package:flutter/material.dart';
import 'flavors.dart';
import 'main.dart'; // 모든 환경이 공통으로 사용할 앱 시작 로직

void main() {
  F.appFlavor = Flavor.dev; // 앱 시작 전에 'dev' Flavor라고 알려주기
  startApp();
}

(똑같이 main_production.dart 파일도 만들고 F.appFlavor = Flavor.production;으로 설정해 줍니다.)

2. 설정값 관리자, flavors.dart 만들기

환경별로 달라질 앱 제목, API 주소 등의 값을 이곳에서 중앙 관리합니다.

lib/flavors.dart

enum Flavor { dev, production }

class F {
  static late final Flavor appFlavor;

  static String get title {
    switch (appFlavor) {
      case Flavor.dev:
        return '내 앱 (개발)';
      case Flavor.production:
        return '내 앱';
    }
  }
  // ... API 주소 등 다른 설정도 여기에 추가!
}

2단계: 민감 정보는 .env로!

API 키처럼 Git에 올리면 절대 안 되는 민감 정보는 .env 파일로 따로 빼서 관리하는 게 안전하겠죠?

1. 패키지 설치 및 파일 생성

flutter pub add flutter_dotenv

프로젝트 최상단에 .env 파일을 만들고 키를 넣어줍니다.

.env

HASURA_ADMIN_SECRET="your_secret_api_key_here"

2. .gitignore에 .env 파일 추가하기 가장 중요한 단계! .gitignore 파일 맨 아래에 .env*를 추가해서 Git이 이 파일을 추적하지 못하게 막아줍니다.

3. 공통 main.dart에서 .env 파일 로드하기

모든 Flavor가 공통으로 사용할 startApp() 함수에서 앱이 실행되기 전에 .env 파일을 로드하도록 코드를 추가합니다.

lib/main.dar

import 'package:flutter/material.dart';
import 'package:flutter_dotenv/flutter_dotenv.dart';
import 'app.dart'; // MaterialApp 위젯이 있는 파일

Future<void> startApp() async {
  // .env 파일을 찾아 변수를 메모리에 로드합니다.
  await dotenv.load(fileName: ".env");
  
  // 이제 앱을 실행합니다.
  runApp(const MyApp());
}

3단계: 네이티브(Android/iOS) 설정하기

Dart 코드 설정이 끝났다고 방심하면 안 됩니다.

Flutter 앱은 결국 네이티브 앱으로 빌드되기에, Android와 iOS에게도 우리가 만든 Flavor를 알려줘야 합니다.

안그럼 그냥 실행 단축키로 실행했을때 오류가 납니다 ㅠ

실제로 봤던 오류: LateError (LateInitializationError: Field 'appFlavor' has not been initialized.)

1. Android 설정 (build.gradle.kts)

android/app/build.gradle.kts 파일을 열고 아래 내용을 추가해 주세요.

android {
    ...
    flavorDimensions += "app"

    productFlors {
        create("dev") {
            dimension = "app"
            // 앱 패키지명에 .dev를 붙여 운영 버전과 같이 설치할 수 있게 함
            applicationIdSuffix = ".dev" 
            // 안드로이드 앱 이름을 변경
            resValue("string", "app_name", "내 앱 (개발)")
        }
        create("production") {
            dimension = "app"
            resValue("string", "app_name", "내 앱")
        }
    }
}

2. iOS 설정 (Xcode Schemes)

iOS는 Xcode에서 Scheme을 이용해 Flavor를 설정합니다. 조금 복잡하지만 차근차근 따라 해보세요.

Xcode 실행: 터미널에서 open ios/Runner.xcworkspace 명령어로 Xcode를 엽니다.
Configuration 복제: Project 'Runner' > Info > Configurations에서 Debug와 Release를 각각 복제하여 Debug-dev, Release-dev를 만듭니다.
Scheme 복제: 상단 메뉴 Product > Scheme > Manage Schemes...에서 Runner를 복제하여 Runner-dev를 만듭니다.
Scheme과 Configuration 연결: Runner-dev의 Edit Scheme... > Build 탭에서 각 단계의 Configuration을 위에서 만든 Debug-dev, Release-dev로 바꿔줍니다.
앱 이름, 번들 ID 설정:
- Build Settings에서 + 버튼을 눌러 User-Defined Setting을 추가하고 APP_NAME과 BUNDLE_ID_SUFFIX 변수를 만듭니다.
- Debug-dev 환경에 맞춰 APP_NAME은 내 앱 (개발), BUNDLE_ID_SUFFIX는 .dev로 값을 설정합니다.
- Info.plist 파일을 열어 Bundle display name의 값을 $(APP_NAME)으로, Bundle identifier의 값을 $(PRODUCT_BUNDLE_IDENTIFIER)$(BUNDLE_ID_SUFFIX)로 수정합니다.

## 4단계: VS Code에서 편하게 실행하기 (launch.json)

마지막으로, 매번 긴 명령어를 치는 대신 F5 키로 편하게 디버깅하기 위해 VS Code를 설정해 줍니다.

.vscode/launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "  DEV",
            "request": "launch",
            "type": "dart",
            "program": "lib/main_dev.dart",
            "args": ["--flavor", "dev"]
        },
        {
            "name": "✅ PRODUCTION",
            "request": "launch",
            "type": "dart",
            "program": "lib/main_production.dart",
            "args": ["--flavor", "production"]
        }
    ]
}

VS Code의 'Run and Debug' 탭에서 원하는 Flavor를 선택하고 실행하면 끝!

이제 하나의 코드로 여러 환경을 테스트 해볼 수 있는 프로젝트가 되었어요! 역시 버전이 업데이트 되면서 이런저런 기능이 추가되네요. 늘 공부해야되는게 힘들기도 하지만 결론적으로 공식적으로 개발자를 편하게 해주려고 하는거니 열심히 따라가야겠어요 앞으로의 나 화이팅

SSR 과 CSR, 서버사이드 렌더링과 클라이언트 사이드 렌더링 그리고 SPA

나나나나나나나ㅏ나난ㄴ나ㅏ나나 — Tue, 12 Aug 2025 19:44:09 +0900

어렴풋이 알고만 있던 SSR과 CSR, 그리고 SPA 알고는 있지만, 이걸 정의해보라고 시키면 말하기는 어려운 친구들...

하나 둘씩 정리해보자

SSR (Server Side Rendering) 란?

이름 그대로 서버에서 페이지를 모두 렌더링해서 브라우저에 전달하는 방식이다. 브라우저는 렌더링이 거의 끝난 HTML 문서를 전달받기 때문에, 초기 화면을 매우 빠르게 표시할 수 있다는 장점이 있다.

SSR의 동작 과정

SSR의 동작 순서를 간단히 나타내면 이렇다.

사용자가 브라우저를 통해 웹사이트에 접속을 요청한다.
서버는 요청을 받고, 페이지를 렌더링할 준비를 마친 완전한 형태의 HTML 파일을 생성한다.
브라우저는 서버로부터 이 HTML 파일을 받아 즉시 화면에 표시한다. 사용자는 콘텐츠를 바로 볼 수 있지만, 아직 상호작용에 필요한 JavaScript가 적용되지 않아 버튼 클릭 등은 동작하지 않는다. (이 시점을 TTV, Time To View라고 부른다)
브라우저는 이어서 페이지 상호작용에 필요한 JavaScript 파일을 다운로드한다.
다운로드한 JavaScript를 HTML 문서(DOM)에 적용하는 'Hydration(하이드레이션)' 과정을 거친다.
Hydration이 완료되면 비로소 페이지의 모든 기능이 활성화되고, 사용자는 정상적으로 상호작용할 수 있다. (이 시점이 바로 TTI, Time To Interact이다)

조금 더 간소화 해서 보면

서버가 렌더링된 HTML 파일을 보내고 브라우저가 받음
브라우저가 페이지를 화면에 띄워주고 JS 파일을 다운 받는다
브라우저가 프레임워크 (React)를 실행한다.
페이지 작동!

정리하자면, 서버 사이드 렌더링은 사용자의 요청이 있을 때마다 서버에서 페이지를 새로 만들어 제공하는 방식이다. 즉, 화면을 그리는(렌더링) 주체가 서버! 과거의 웹은 대부분 이 방식을 사용했지만, 웹에서 제공되는 정보의 양이 많아지면서 문제가 발생했는데, 페이지를 이동할 때마다 전체 페이지를 새로고침하므로 화면 깜빡임(flicker)이 발생하고, 서버에 계속해서 부담을 주는 성능 저하의 원인이 되었다.

SSR의 장점과 단점

장점
- 빠른 초기 로딩 속도: 사용자가 첫 화면을 보기까지의 시간이 짧다.
- 검색엔진 최적화(SEO) 유리: 서버가 콘텐츠가 모두 채워진 HTML을 전달하므로 검색엔진 크롤러가 사이트 정보를 수집하기 용이하다.
단점
- 느린 페이지 전환: 다른 페이지로 이동할 때마다 서버에 새로운 페이지를 요청하고 받아오는 과정을 반복하므로 화면 전체가 새로고침되어 깜빡인다.
- 서버 부하: 사용자의 요청이 있을 때마다 서버가 페이지를 새로 렌더링해야 하므로, 트래픽이 많은 서비스의 경우 서버에 부하가 갈 수 있다.
- TTV와 TTI의 간극: 사용자가 화면을 보고 나서 실제로 조작할 수 있을 때까지 지연 시간이 존재한다.

SPA (Single Page Application) 란?

SPA는 Single Page Application의 약자로, 하나의 HTML 페이지만으로 전체 서비스를 운영하는 애플리케이션을 뜻한다. 최초 접속 시에만 전체 페이지를 로드하고, 그 이후에는 사용자의 행동에 따라 필요한 데이터만 서버에서 받아와 화면의 일부만 동적으로 교체한다.

이 방식 덕분에 페이지 이동 시 SSR처럼 화면 전체가 깜빡이며 새로고침되지 않고, 마치 데스크톱 앱처럼 부드러운 사용자 경험을 제공할 수 있다. 이 SPA를 구현하는 대표적인 렌더링 방식이 바로 다음에 설명할 CSR이다.

CSR (Client Side Rendering)

SSR과 반대로 렌더링의 책임이 클라이언트(브라우저)에게 있다. 서버는 거의 텅 빈 HTML 뼈대와 렌더링에 필요한 JavaScript 파일만 보내주고, 브라우저가 이를 받아 동적으로 페이지를 그려나간다.

CSR의 동작 과정

사용자가 웹사이트 접속을 요청한다.
서버는 내용이 거의 없는 최소한의 HTML 파일과 화면 구성에 필요한 JavaScript 파일 링크를 전달한다.
브라우저는 이 파일들을 다운로드한다. 이 시간 동안 사용자는 빈 화면 혹은 로딩 스피너를 보게 된다.
다운로드가 완료된 JavaScript 파일이 실행되며 화면을 동적으로 구성한다.
페이지에 필요한 데이터가 있다면, JavaScript가 서버에 API를 호출해 데이터를 요청한다.
서버로부터 데이터를 수신하면, 그제야 빈 페이지의 적절한 위치에 데이터를 채워 넣어 사용자에게 완전한 화면을 보여준다

SSR 과 달리 CSR은 화면이 띄워지는 타이밍이 확실히 늦다. 브라우저가 HTML 파일, JS 파일 까지 모두 다 읽은 뒤 프레임워크까지 실행하고 난 뒤에 페이지가 노출되고, 상호작용이 가능해진다.

정리하자면 클라이언트 사이드 렌더링은 클라이언트인 브라우저가 렌더링을 도맡아 처리하는 방식이다. 서버에서 필요한 데이터를 한 번에 받아오고 받은 데이터를 브라우저가 주체가 되어 그린다.

CSR은 SPA 트랜드와 CPU 성능 상승 +JS 표준화(리액트, 뷰, 앵귤러 등 프레임워크의 발전)와 함께 본격적으로 시작되었다.

클라이언트사이드렌더링은 서버에서 데이터를 받아 모두 읽고 다시 화면에 전체 페이지를 바꿔서 보여주는 것보다 훨씬 빠르게 화면을 그릴 수 있는 것이다. 이는 성능적으로도 페이지를 새로 렌더링하지 않아 서버자원을 덜 사용하고, 새로고침이 발생하지 않기 때문에 화면이 바뀔때 화면 깜빡임도 없어 우수한 사용자 경험을 제공한다.

CSR의 장점과 단점

장점
- 뛰어난 사용자 경험(UX): 초기 로딩 이후에는 페이지 전체를 새로고침할 필요 없이 필요한 부분만 빠르게 업데이트하므로, 매우 부드러운 화면 전환이 가능하다.
- 서버 부하 감소: 렌더링은 대부분 브라우저가 처리하므로 서버는 데이터 제공 역할에 집중할 수 있다.
단점
- 느린 초기 로딩 속도: 모든 스크립트 파일이 다운로드되고 실행될 때까지 사용자는 기다려야 한다.
- 검색엔진 최적화(SEO) 불리: 대부분의 검색엔진 크롤러는 텅 빈 HTML 문서를 보고 내용을 수집하지 못하는 경우가 많다. (최근 구글 등은 JS를 실행시켜주기도 하지만, 여전히 SEO에는 보완이 필요하다)

그래서 뭐가 다른데? SSR VS CSR 한눈에 보기

구분	SSR	CSR
초기 로딩 속도	빠름	느림
페이지 전환 속도	느림 (전체 새로고침)	빠름 (부분 업데이트)
SEO	유리	불리
서버 부하	높음	낮음
사용자 경험	페이지 이동 시 깜빡임 발생	부드럽고 쾌적함

결론

SSR과 CSR은 어느 하나가 무조건 좋은 '은 탄환(Silver Bullet)'이 아니다. 각자 명확한 장단점을 가지고 있어, 서비스의 성격에 따라 적절한 방식을 선택해야 한다.

SSR이 유리한 경우: SEO가 매우 중요하거나, 콘텐츠 중심의 정적인 페이지(뉴스 기사, 블로그 등), 혹은 사용자와의 상호작용이 적은 웹사이트에 적합하다.
CSR이 유리한 경우: 복잡한 상호작용과 빠른 인터랙션이 중요한 서비스(대시보드, 관리자 페이지 등), 혹은 SEO의 중요도가 낮은 서비스에 적합하다.

최근에는 Next.js(React 기반)나 Nuxt.js(Vue 기반) 같은 프레임워크가 등장하며 이 문제를 해결하고 있다. 이런 프레임워크들은 첫 페이지 로딩은 SSR 방식으로 처리해 SEO와 초기 로딩 속도를 잡고, 이후의 상호작용은 CSR 방식으로 처리해 부드러운 사용자 경험을 제공하는 하이브리드 방식을 채택했다.

더 나아가 빌드 시점에 페이지를 미리 만들어두는 SSG(정적 사이트 생성)나, 필요할 때만 페이지를 다시 렌더링하는 ISR(점진적 정적 재생성) 같은 고급 전략도 등장했다. (공부할게 왜이렇게 많은건지,, 이것도 정리한번 하는게 좋을거같다)

결국 중요한 것은 각 렌더링 방식의 원리를 정확히 이해하고, 만들고자 하는 서비스의 성격에 맞는 최적의 방식을 선택하고 조합하는 능력이다.

Next.js vs Nuxt.js ?

나나나나나나나ㅏ나난ㄴ나ㅏ나나 — Mon, 11 Aug 2025 16:47:30 +0900

요즘 웹개발 시장을 보면 서버사이드 렌더링 (SSR) 과 정적 사이트 생성 (SSG)는 필수적인 기술이다.

이와 관련하여 React와 Vue.js 를 기반으로 한 대표 프레임워크인 Next.js 와 Nuxt.js 를 정리해보자.

현대 웹 개발에서 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)은 더 이상 선택이 아닌 필수 기술로 자리 잡았다. 뛰어난 사용자 경험(UX)과 검색 엔진 최적화(SEO)를 모두 잡기 위해 많은 개발자가 React와 Vue.js 기반의 대표 프레임워크인 Next.js와 Nuxt.js를 사용하고 있다.

두 프레임워크는 파일 기반 라우팅, 코드 분할 등 유사한 기능을 제공하지만, 기반이 되는 라이브러리의 철학과 최신 업데이트 방향성에 따라 뚜렷한 차이를 보이고 있는데, 프로젝트를 시작할때 어떤 프레임워크가 더 적합할지, 핵심적인 특징부터 최신 업데이트 내용까지 상세히 비교해 보자!

Next.js란?

Next.js는 React 기반의 프레임워크로, Vercel이 주도적으로 개발하고 있다. React의 방대한 생태계와 유연성을 그대로 활용하면서, App Router와 React Server Components(RSC) 같은 최신 기능을 통해 서버와 클라이언트의 경계를 허무는 혁신적인 개발 패러다임을 제시한다.

주요 특징:

하이브리드 렌더링: SSR, SSG, ISR(점진적 정적 재생성) 뿐만 아니라, 컴포넌트 단위로 서버 렌더링과 클라이언트 렌더링을 조합할 수 있다.
App Router: 폴더 구조가 곧 URL이 되는 직관적인 라우팅 시스템으로, layout.js, page.js 등 정해진 파일명을 통해 중첩된 레이아웃을 손쉽게 구현함.
React Server Components (RSC): 서버에서만 렌더링되는 컴포넌트로, 클라이언트의 자바스크립트 번들 크기를 획기적으로 줄여 초기 로딩 성능 극대화.
풍부한 생태계: React의 인기를 바탕으로 검증된 라이브러리와 자료가 풍부하여 복잡하고 규모 있는 애플리케이션 개발에 유리함.

Nuxt.js란?

Nuxt.js는 Vue.js를 기반으로 한 프레임워크로, '컨벤션 중심(Convention over Configuration)' 철학을 바탕으로 직관적이고 생산성 높은 개발 경험을 제공한다.. 특히 Nuxt 3 버전부터 도입된 Nitro 서버 엔진과 Vue 3 Composition API는 강력한 성능과 유연성을 더했다.

주요 특징:
- Nitro 서버 엔진: 코드 분할, 서버리스 환경 지원, 하이브리드 렌더링 등 최신 기술을 내장하여 API 엔드포인트 생성부터 렌더링까지 전반적인 성능 크게 향상.
- Auto-imports: 컴포넌트나 유틸리티 함수를 별도의 import 구문 없이 자동으로 불러와 코드의 간결함 유지
- 타입스크립트 완벽 지원: 강력한 타입 추론과 자동 완성 기능으로 안정적이고 예측 가능한 개발을 도움.
- 모듈 생태계: SEO, 이미지 최적화, 인증 등 자주 사용되는 기능들을 잘 만들어진 모듈을 통해 손쉽게 추가할 수 있어 빠른 속도로 개발을 할 수 있음.

장단점 비교

Next.js

장점:

높은 자유도와 확장성: React의 유연함과 RSC를 활용해 복잡한 대규모 아키텍처 설계 가능
압도적인 생태계: 방대한 라이브러리와 커뮤니티, 풍부한 학습 자료
점진적 채택 용이: 기존 React 프로젝트에 점진적으로 도입하기 용이함

단점:

다소 높은 학습 곡선: App Router, RSC 등 최신 개념에 대한 학습 필요
복잡한 설정: 자유도가 높은 만큼 프로젝트가 복잡해지면 설정 관리가 까다로워질 수 있음

Nuxt.js

장점:

탁월한 개발자 경험(DX): Auto-imports, 규약 기반 설정 등 간결하고 빠른 개발에 초점
강력한 내장 기능: Nitro 엔진 기반의 뛰어난 성능과 최적화된 모듈 생태계
쉬운 학습 곡선: Vue.js의 직관성과 잘 정돈된 문서 덕분에 입문자에게 친화적

단점:

상대적으로 작은 생태계: React 생태계에 비해 특정 고급 기능 구현 시 선택지가 적을 수 있음
높은 규약 의존도: 정해진 규칙을 벗어나는 커스터마이징 시 더 많은 노력이 필요할 수 있음

주요 사용 사례 및 추천

Next.js

대규모, 데이터 중심의 복잡한 애플리케이션을 구축할 계획이 있을 때
팀이 React와 그 생태계에 대한 깊은 이해도를 가지고 있을 때
최고 수준의 성능 최적화와 서버-클라이언트 간 유연한 아키텍처가 필요할 때

Nuxt.js

콘텐츠 중심의 웹사이트(블로그, 마케팅 사이트 등)나 중소규모 애플리케이션을 빠르게 개발해야 할 때
팀이 Vue.js에 익숙하며, 높은 생산성을 중요하게 생각할 때
뛰어난 개발자 경험(DX)과 잘 갖춰진 모듈 시스템을 선호할 때

결론

과거에는 '대규모는 Next.js, 중소규모는 Nuxt.js'라는 인식이 있었지만, Next.js 13+와 Nuxt 3의 등장으로 이러한 구분은 많이 흐려진 상황이다. 두 프레임워크 모두 현대적인 웹 애플리케이션이 요구하는 대부분의 모두 수행할 수 있다.

따라서 기술 선택의 핵심은 "어떤 프레임워크가 우리 팀의 개발 철학과 더 잘 맞는가?"에 있습니다. React의 자유로운 생태계 속에서 최신 기술을 탐구하고 싶다면 Next.js를, Vue.js의 직관적인 문법과 생산성을 바탕으로 빠르게 결과물을 만들고 싶다면 Nuxt.js를 선택하여 프로젝트를 시작하면 될거같다!

vuejs input keyup.enter

나나나나나나나ㅏ나난ㄴ나ㅏ나나 — Wed, 16 Jul 2025 18:51:58 +0900

vuejs 에서 input 내 키보드로 enter 쳤을때 함수 실행하기

둘중 아무거나 쓰면된다.

v-on:keyup.enter="login()"

@keyup.enter="login()"

사용자 여정지도 (Journeymap)은 무엇일까?

나나나나나나나ㅏ나난ㄴ나ㅏ나나 — Sat, 6 Jan 2024 18:21:42 +0900

사용자 여정지도란?

'여정지도'란 말 그대로 사용자가 생활 맥락에서 제품/서비스와 만나는 지점을 살펴보고 기록해야 한다는 의미입니다. 인터뷰 결과물과 페르소나 활동으로 만든 가상의 사용자를 고려하여, 그 사용자가 실제 제품/서비스에서 겪는 경험을 시각화 하는것을 말합니다.

일반적으로 여정지도를 작성하는 방버은 사용자가 제품 및 서비스를 접하기 전부터 사용중, 사용 후까지 행동들을 시간 순서대로 나열을 하고 그 행동들에 따르는 사용자의 생각과 감정을 채워서 정리해놓습니다. 경험을 행동, 감정, 생각으로 추출하고 그 속에서 이슈와 인사이트를 얻어내어 향후 제품 개선 및 새로운 개발을 위한 재료로 사용됩니다.

사용자 여정지도 구조

상단: 특정 사용자 (User) + 시나리오 + 기대되는 행동 및 목표 (Expectations)
중간: 구체적인 사용자의 행동 (Action) + 생각 (Thoughts) + 감정 (Feelings)
하단: 문제점 (Painpoints) + 기회요소 (Opportunities)

사용자 여정지도를 통해 꼭 도출해야할것

제품/서비스 사용전, 사용중, 사용후를 모두 작성해야합니다.
경험하는 모든 과정에 대해 접점 (Touchpoint)를 확인합니다.
작성 후에는 포스트잇이 많이 붙어있는 곳을 다시 보며 이야기를 나눕니다.
여정지도를 사무실 벽에 붙여놓으세요. 앞으로 알게되는 사실들을 덧붙여 발전시킵니다.

사용자(User)

사용자는 여정지도에서 특정 행동을 하는 대상으로 페르소나(Persona)라고 부르기도 합니다. 수집한 데이터를 기반해서 사용자와 행동들을 선정합니다. 또한 필요시 저니맵을 두개 이상 제작할 수 있는데, 서비스를 사용하는 관계자가 두명 이상일 수도 있기 때문입니다. 그렇기 때문에 사용자를 선정할 때는 애매모호하고 여러 목표를 가진 페르소나가 아닌 명확하고 뚜렷한 행동을 취할 수 있는 페르소나로 정하고 필요시 로드맵의 개수를 늘리는 것이 좋습니다.

시나리오 (Scenario) + 목표 (Expectations)

사용자의 현재 상황을 묘사하고 행동을 통해 어떤 목적을 달성하려는지 적습니다. 현재 존재하는 서비스여도 되고 아직 디자인이 나오지 않은 서비스를 사용하는 상황이어도 좋습니다.

행동단계 (Journey Phase)

행동단계는 사용자의 일련의 행동들이 전반적으로 어떤 과정인지 보여주는 상위단계입니다. 서비스의 성격에 따라 행동단계의 용어는 달라질 수 있는데 그 예를 들자면

이커머스앱: 탐색 - 체험 - 구입 - 사용 - 문의
B2B 서비스: 구입 - 채택 - 유지 - 확장 - 신뢰

행동, 생각, 감정 (Actions, Thoughts, Feelings)

행동(Actions): 사용자가 제품, 서비스를 사용하면서 취하는 행동들입니다. 자잘한 모든 세부적 행동들을 적는 것이 아니라 단계별로 사용자가 어떤 행동을 취하는지에 집중해서 적으면 됩니다.
생각(Thoughts): 행동을 하면서 사용자가 머릿속으로 떠오른 생각, 동기, 니즈같은 것들을 말합니다. 리서치 과정에서 사용자들이 했던 말들을 적어도 좋습니다.
감정(Feelings): 감정은 하나의 곡선으로 보여지는데 만족스럽거나 즐거운 것처럼 긍정적인 감정이 들면 위로 올라가고 불만족스럽거나 실망스러운 부정적인 감정이 들면 아래로 내려갑니다. 선으로 표현하기 때문에 사용자가 어디 부분에서 만족스럽고 불만족스러웠는지를 한눈에 볼 수 있습니다.

문제점(Painpoints)

행동, 생각, 감정들을 보았을때 시나리오(처한 상황)와 목표를 달성하는데 사용자가 불쾌하게 느낀 경험의 문제점들을 정리합니다.

기회요소(Opportunities)

사용자의 시나리오, 행동, 감정, 생각 등을 정리했으면 그 속에서 사용자가 좀 더 나은 경험을 누리기 위한 인사이트들을 뽑아내는 것을 말한다. 이 과정에서 디자이너의 통찰력과 다방면의 지식과 사고가 필요합니다.

어떤 방향으로 개선할 수 있을까?
어떤 것이 가장 큰 기회요소일까?
여정지도로 알게 된 것들로 무엇을 할 수 있을까?

이외에도 서비스 특성에 맞춰 여러 요소들로 사용자의 경험을 분석해볼 수 있습니다. 이커머스 어플이면 타임세일과 같은 이벤트 적인 요소가 들어갈 수도 있겠죠?

WHY. 왜 사용자 여정지도가 필요한가요?

01. 복잡한 사용자여정을 쉽게 이해할 수 있습니다.

복잡한 프로세스를 시각적으로 표현함으로서, 정보의 명확성과 이해를 실천할 수 있습니다. 사용자 여정을 말로만 설명하려고 하는 것이 아니라, 이 지도를 통해 팀 전원이 사용자 체험 전체를 시각적으로 파악할 수 있습니다. 대부분의 고객 여정의 터치 포인트는 타임라인을 따라 매핑되어 프로세스의 각 단계에서 사용자의 요구를 시계열로 이해할 수 있습니다.

기업내 각 부서의 특성에 따라 서로 다른 고객 여정이 존재하기 때문에 프로젝트와 관련된 모든 멤버가 고객 여정을 이해하는 프레임 워크를 준비하는 것이 매우 중요합니다. 예를들어, 이상적인 사용자 경험을 얻으려면 마케팅, 판매, 고객 서비스, 기술 지원 등 모든 부서가 참여해야 할 수 있습니다. 각 부서의 담당자는 사용자 여정이 어떻게 기능하고, 어디에서 핸드오프가 이루어지고, 어떻게하면 사용자 체험을 향상할 수 있는지를 명확하게 할 필요가 있습니다. 하나의 다이어그램을 사용하여 부서간에 정보를 공유함으로써보다 효과적인 의사결정을 내릴 수 있습니다.

02. 사용자 관점에서 계획을 설계할 수 있습니다.

여정지도는 사용자의 행동뿐만 아니라 사용자가 제품과 어떻게 관련되어 있는지 알 수 있는 유용한 도구입니다. 또한 사용자를 감정 수준에서 이해하여, 무엇이 사용자에게 불만, 기쁨, 감동을 주는지 알 수 있습니다.

사용자의 관점에서 자사 제품과 브랜드를 이해하면 현재 마케팅 및 브랜딩 캠페인의 효과를 분석할 수 있습니다. 이를 통해 사용자의 과제나 자사 제품을 선택한 이유 등 깊은 인사이트를 얻을 수도 있습니다. 이러한 분석을 바탕으로 새로운 마케팅 전략과 영업 전략을 수집함으로써, 페르소나를 기반으로 타겟팅한 고객층의 구매의욕을 높이는 캠페인을 실시할 수 있습니다.

사용자 여정지도를 간단하게 보여주기 위해 템플릿을 만들어 보았습니다. 템플릿에는 정답이 없습니다. 서비스 성격에 맞게 그리고 누가 보아도 이해가 쉽게 만들면 되고, 들어가는 구성요소도 서비스에 맞게 변경하셔서 만들면됩니다.

[javascript] DOMException: Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported. 해결하기

나나나나나나나ㅏ나난ㄴ나ㅏ나나 — Fri, 15 Sep 2023 16:00:09 +0900

이미지 파일을 만든후 사용하려고 할때

DOMException: Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported.

이 발생한다면?

해결방안

외부 이미지를 가져올때 cross origin 문제로 발생한 오류이기때문에 이미지에 cross origin 을 "Anonymous" 로 지정해주면 된다

const image = new Image();
image.src = image_src;
image.crossOrigin = 'Anonymous';
image.onload = () => {
   consoel.log(image)
}

간단하게 해결완료

✋ 잠깐 crossOrigin 추가 이후 갑자기 이미지 CORS 문제가 생긴다면?

2022.11.23 - [WEB/JS] - 이미지 가져올때 CORS 오류가 발생한다....!!!!! [AWS S3+CDN]

순수 css로 tooltip 만들기(with tailwind)

나나나나나나나ㅏ나난ㄴ나ㅏ나나 — Thu, 8 Jun 2023 18:59:00 +0900

툴팁이란?

해당 요소에 마우스를 올리면 추가적인 정보가 나타나게 하는 효과

생각보다 툴팁을 사용할 일이 많은데 따로 js 없이 순수하게 툴팁을 사용해보자

tailwind를 이용한 tooltip 예제

<div class="relative group">
	<img :src="require('@/assets/icons/ico_report_problem.svg')"
		class="w-[20px] h-[20px] cursor-pointer"
		alt="problem" />
	<div class=" group-hover:flex hidden hover:flex flex-col absolute top-[-150%] left-[50%] translate-x-[-50%] items-center justify-center text-center z-[20]">
		<div class="bg-[rgba(0,0,0,0.7)] text-white w-[140px] p-[8px] rounded-[6px] ">Tooltip!</div>
		<div class="h-0 w-0" style="border-bottom: 5px solid transparent;border-top: 5px solid rgba(0,0,0,0.7);border-left: 5px solid transparent;border-right: 5px solid transparent;" />
	</div>
</div>

tailwind에서 부모 hover시 자식 엘리먼트에게 무언가 옵션을 주고 싶다면?

1. 부모요소에 group 클래스를 추가

2. 자식 요소에 group-hover:flex 로 hover 관련 옵션을 추가

이렇게 하면 끗!

[javascript] 자바스크립트로 방금/몇초전/몇분전/몇시간전/몇달전/몇년전 출력하기

나나나나나나나ㅏ나난ㄴ나ㅏ나나 — Wed, 17 May 2023 13:39:31 +0900

  const today = new Date();
    const timeValue = new Date(date);


    const betweenTime = Math.floor((today.getTime() - timeValue.getTime()) / 1000 / 60);
    if (betweenTime < 1) return '방금전';
    if (betweenTime < 60) {
        return `${betweenTime}분전`;
    }

    const betweenTimeHour = Math.floor(betweenTime / 60);
    if (betweenTimeHour < 24) {
        return `${betweenTimeHour}시간전`;
    }

    const betweenTimeDay = Math.floor(betweenTime / 60 / 24);
    if (betweenTimeDay < 365) {
        return `${betweenTimeDay}일전`;
    }

    return `${Math.floor(betweenTimeDay / 365)}년전`;

ckeditor에서 youtube url 입력시 iframe으로 출력하기

나나나나나나나ㅏ나난ㄴ나ㅏ나나 — Tue, 21 Feb 2023 14:02:02 +0900

ckeditor에서 유튜브를 embeded 했는데,

embeded 태그로 입력되서 출력이 되지않는다ㅠㅠ

유튜브는 iframe으로 출력해야되서 그런데,

간편하게 변경할 수 있는 방법이 있다!

editor config에 넣어주면 된다!

editorConfig = {
    toolbar: [....],
    mediaEmbed: {
        previewsInData: true
    }
}

[vue 전체 코드]

<template>
    <div>
        <ckeditor
            :editor="state.editor" @ready="onReady" @input="$emit('input', String(state.changeEditorData))" v-model="state.changeEditorData" :config="state.editorConfig"/>
    </div>

</template>

<script>
import UploadAdapter from '@/utils/CkEditorUploadAdapter';
import ClassicEditor from "@ckeditor/ckeditor5-build-classic";
import CKEditor from '@ckeditor/ckeditor5-vue';
import {ref, watch} from "vue";


export default {
    components: {
        ckeditor: CKEditor.component
    },
    name: "CkEditor",
    props: ['editorData'],
    setup(props) {
        const state = ref({
            editor: ClassicEditor,
            changeEditorData: props.editorData,
            editorConfig: {
                // The configuration of the editor.
                mediaEmbed: {
                    previewsInData: true
                }
            }
        });

        const onReady = (editor) => {
            editor.plugins.get('FileRepository').createUploadAdapter = (loader) => {
                return new UploadAdapter(loader);
            }
        }
        watch(
            () => props.editorData, (value) => {
                state.value.changeEditorData = value;
            }
        )
        return {
            state,
            onReady,
        }
    },
}
</script>

누구나 할 수있는 자바스크립트에서 이미지 다운로드하기

나나나나나나나ㅏ나난ㄴ나ㅏ나나 — Wed, 28 Dec 2022 18:56:14 +0900

AWS S3에 올려둔 이미지를 다운로드해보자!

우선 코드 먼저

let image = new Image();
image.onload = function() {
    const canvas = document.createElement("canvas");
    canvas.width = image.width;
    canvas.height = image.height;
    const ctx = canvas.getContext("2d");
    ctx.drawImage(image, 0, 0);

    let dataURL = canvas.toDataURL();
    
    const element = document.createElement('a');
    element.setAttribute('href', dataURL);
    element.setAttribute('download', '이미지 다운로드 완료');
    element.style.display = 'none';
    document.body.appendChild(element);
    element.click();
    document.body.removeChild(element);

}

image.crossOrigin = "Anonymous";
image.width = 1500
image.height = 1500;
image.src = `${image_url}?not-from-cache-please`;

간단하게 설명하면

1. AWS URL 로 이미지 파일 만들기

2. 이미지 파일에서 BASE 64 추출하기

3. a 태그의 element 만들어서 다운로드 사용하기

이렇게 하면

짜잔 다운로드 완료 !

지금까지는 귀찮아서 그냥 해당 URL 로 이동하게 했는데,
생각보다 간단하게 완료할 수 있었다

앞으로는 URL 이동말고 다운로드 폴더에 조심스레 넣어줘야겠다

✋잠깐 혹시 AWS 파일 만들때 CORS 오류가 발생한다면?

2022.11.23 - [WEB/JS] - 이미지 가져올때 CORS 오류가 발생한다....!!!!! [AWS S3+CDN]