[디자인입문] UXUI Introduction3_UXUI 실무

[제품팀]

1. 제품 팀이란?

: 제품을 만들기 위해 각자 다른 전문적인 능력을 갖춘 사람들이 모인 팀

- 최소 조건 1명의 제품관리자 (PO나 PM), 1명의 디자이너, 2명의 엔지니어 (기획, 디자인, 개발)

- 회사에 따라 제품팀에 데이터 애널리스트, 마케터, BO(Business Operator) 등이 포함

1-1. 디자이너는 제품팀에만 속할까?

: 스타트업에서는 목적조직과 기능조직이 교차하는 매트릭스 조직으로 팀을 구성하기도 함 

1-2. 목적 조직 (= 제품팀)

: 목적조직은 특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀

EX. 핀테크 회사 : 도메인별로 대출팀, 카드팀, 예/적금팀으로 나뉨

- 일반적으로 제품팀=목적조직

- 목적조직은 스쿼드 혹은 사일로 라고 부름 

- 목적조직은 제품의 목표를 달성하기 위해 다양한 직무의 사람이 모여있는 팀 => 속도가 빠르고 효율적이라는 장점

1-3. 기능 조직

: 기능조직은 유사한 직무끼리 구성된 팀 Ex. 기획팀, 디자인팀, 개발팀 등

- 기능조직은 챕터라고 부름

- 기능조직은 비슷한 일을 하는 사람들끼리 모임 => 전문성을 높일 수 있는 장점

1-4. 매트릭스 조직 (목적+기능)

: 구성원이 기능조직과 목적조직이 교차된 형태로 소속된 조직

Ex. 프로덕트 디자이너 : 기능조직인 디자인팀에 속하면서 동시에 목적조직인 스쿼드에도 속함

- 일반적으로 많은 스타트업의 방식

2. 제품팀이 일하는 방식

2-1. 린스타트업

: 린스타트업은 빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영 방식

- 린스타트업은 불확실성이 높은 스타트업에서 제품을 빠르게 개발하기 위해 고안된 전략

- 적은 리소스(시간,돈,사람)로 제품을 만들어서 빠르게 시장에 검증해 가면서 기능을 고도화해 나가는 방법 (적은 투자 -> 최대 효율)

- 린스타트업에서는 ‘만들기 → 측정 → 학습’을 반복하면서 피드백을 받고 사용자 중심의 좋은 제품을 만드는 것이 중요

2-2. 애자일

: 제품을 만드는 방법론 중 하나 (구체적인 방법)

-  일정한 주기로 빠르게 제품을 배포해 사용자의 피드백을 받고 요구사항을 수정해 나가는 과정을 반복

- 애자일(Agile)은 사전적으로 날렵한, 민첩한이라는 뜻

- 애자일한 제품팀은 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해 나가는 과정을 반복

* 반대 의미인 폭포수(Waterfall) 방식과 비교하면 애자일을 더 쉽게 이해 

1) 폭포수 방식

- 폭포가 떨어지는 것처럼 수직적으로 각 단계를 하나씩 단계를 진행

- 각 단계가 완벽하게 완성되었을 때만 다음 단계로 넘어가고 이전 단계로는 돌아가지 x

- 요구사항 설계부터 디자인, 개발이 순서대로, 그리고 독립적으로 진행

- 단계별로 업무 분담이 명확하고 진행 상황 파악이 쉬움

- 속도가 느리고 변화하는 상황에 유연하게 대처하기 어려움 

=> 규모가 큰 대기업

2) 애자일 방식

- 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해 나가는 과정을 반복 (작은 단위, 작은 크기로 제품 제작 후 검증)

- 수평적으로 일하면서 불필요한 의사결정을 줄이고 즉각적인 계획과 실행으로 피드백을 빠르게 반영

3. 용어 정리

1) 스프린트 : 집중해서 여러 태스크를 완료하는 1~4주 정도의 짧은 기간을 의미

- 스타트업에서는 스프린트를 여러 번 반복하며 밀도 있게 작업

2) 스크럼 : 1~4주 단위의 스프린트 안에서 목표를 정하고 우선순위에 따라 제품을 개발하는 방법론

- 요구사항 설계 → 디자인 → 개발 → 테스트 → 배포의 과정으로 제품을 개발

3) 이터레이션 : 스프린트의 반복

[UXUI 실무 프로세스] 

1. 디자인 프로세스

1-1. 기획

1) 문제 정의 : PO/PM과 함께 제품 목표에 따라 우선순위가 높은 문제를 정함

- 회사에 따라 문제 정의 단계에서 디자이너가 참여하기도 하고, 참여하지 않고 따로 PO/PM이 문제를 선정해 공유하기도 

2) 아이데이션 : 앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그중에서 적절한 솔루션을 선택

- 필요에 따라 러프한 솔루션 스케치를 진행

-솔루션 스케치 : 보통 아이데이션 단계에서 그리는 솔루션 스케치 _ 기획과 아이디어가 잘 보이도록 와이어프레임의 형태로 스케치

3) 프로덕트 스펙 문서 작성 : 디자인에 들어가기 전, 문서에 솔루션에 대한 상세 내용을 글로 작성

- 디자인이 나오지 않아도 엔지니어가 솔루션을 미리 상상하고 준비할 수 있다는 장점

1-2. 디자인

1) 초안 디자인

- 피그마나, 스케치 등의 디자인 툴로 솔루션을 디자인

- 디테일보다는 전반적인 사용자의 여정과 UX에 집중해 보면서 프로덕트 스펙 문서에서 놓친 엣지 케이스는 없는지 확인

2) 피드백

- 기획 단계에서 논의한 대로 잘 디자인되었는지 팀원들에게 공유하고 피드백 받음

- 솔루션의 성격에 따라 피그마 프로토타이핑이나 프로토파이 같은 프로토타입 툴을 사용 (유저 플로우가 필요한 경우)

3) 최종 디자인 확정 및 핸드오프

- 피드백을 초안에 반영하여 최종 디자인을 확정

- 확정한 최종 디자인을 엔지니어에게 공유, 필요에 따라 가이드를 함께 작성해 전달(핸드오프)

*핸드오프란?

- 디자인을 개발할 수 있도록 엔지니어에게 전달하는 것

*핸드오프 공유시 들어가야 할 내용

1. 유저 플로우 : 처음 시작하는 화면은 어디이고 어떻게 연결되는지 만들려는 기능의 전체 흐름이 잘 보이도록 구성

2. 유즈 케이스 : 상황에 따른 화면 정의 (액션에 따라 달라지는 화면 등)

Ex. 회원가입 화면에서는 정상 입력, 입력값 오류, 입력 가능 시간 초과 등의 다양한 상황 존재

따라서 모든 케이스에 달라지는 화면을 놓치지 않고 정의해야 함 

3. 반응형 레이아웃 : 대부분의 회사에서는 스크린 크기를 하나 정해 디자인을 하고 반응형으로 대응

- 아주 작은 스크린 크기나 특별한 스크린 크기에 디자인이 어떻게 표현되어야 하는지 가이드를 제공해줘야 함

1-3. 개발

1) 디자인 QA

- 개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 디자인 QA 진행

- 최대한 사용자와 비슷한 환경으로 테스트 (앱이라면 적어도 안드로이드, iOS 두 환경을 모두 확인)

2) 프로덕트 스펙 문서

- 프로덕트 스펙은 제품을 만들거나 개선할 때 사용하는 문서로 기능의 사양을 정의한 가이드 문서

- 회사에 따라서 PRD(Product Requirements Document, 제품 요구사항 정의서)라고 부르기도

2-1. 프로덕트 스펙이 필요한 이유?

- 팀원 모두가 같은 생각을 갖고 제품을 만들 수 있도록 가이드하는 역할

2-2. 프로덕트 스펙에는 어떤 내용?

- 기획 배경과 솔루션, 기능 요구사항, 실험 계획 등

- 가능한 기획, 디자인, 개발에 필요한 모든 내용을 하나의 문서에 적는 것이 좋음 (문서가 여러 개로 파편화되어 있다면 URL을 첨부해서 한 곳에서 볼 수 있도록 제작) 

->기획 배경 & 문제 정의 : 기획하게 된 배경을 짧게 설명하고 사용자의 문제를 정의

- 문제 발견 과정, 문제로 정의한 이유, 문제 원인, 문제에 영향 받는 사람 

*** -> 솔루션 설명 : 만들고자 하는 솔루션에 대해 UX/UI 관점에서 자세하게 설명

- 페르소나, 사용자 시나리오, 기능별 주요 특징 & 요구사항, 예외 상황 및 Edge Case (생각하지 못한 케이스)정의, 최종 시안

-> 실험 설계 : 솔루션의 효과를 검증하기 위해 어떤 순서로 실험을 진행하고 어떻게 결과를 분석할 것인지에 대한 계획 작성

- 실험 가설 : 문제 해결을 통해 만들어 내고자 하는 결과 

- 실험 방식

- 결과 평가 : 문제가 해결되었는지 판단할 수 있는 방법

- 실험 기간

*** ->  예상 일정 : 프로덕트 스펙에는 예상 일정을 꼭 포함, 작업에 필요한 시간을 추정하고 예상 일정을 잘 산정하는 것은 리소스를 효율적으로 쓰기 위한 시작점

- 프로덕트 스펙 초안 작성 완료 예상 일정

- UI/UX 디자인 최종 시안 제작 완료 예상 일정

- 개발 분야별 예상 일정 : 프론트엔드, 서버, 이벤트 설계, QA가 각각 세부적으로 작성

- 배포 목표 일정

*프로덕트 스펙 문서는 계속해서 업데이트되어야 함 

한 번 작성한 뒤 다시 보지 않는 문서 X.

기획 초기에 만들기 시작해 기능이 배포되고 실험이 종료될 때까지 끊임없이 업데이트하고 관리

3) 디자인 공유하고 피드백 받기

- 좋은 피드백을 받기 위해선 디자인을 잘 공유하는 것이 중요

- 디자이너의 업무의 대부분은 디자인과 피드백, 거듭되는 수정

- 기획 배경과 맥락을 잘 이해해야 좋은 피드백

- 피드백을 주는 사람이 전체적인 내용을 알 수 있도록 충분한 정보를 함께 전달해야 함

4) 디자인 피드백을 요청할 때 포함하면 좋을 것 

4-1. 배경 : 해당 프로젝트를 기획하게 된 배경을 설명(구체적인 데이터와 가설)

4-2. 솔루션 의도 : 가설에서 어떠한 방향성을 잡고 디자인했는지 설명, 시각적으로 강조하고 싶었던 부분이나 중요하게 생각한 부분 기재 

4-3. 필수 리뷰어 : 다수에게 디자인을 공유할 땐 꼭 피드백을 받고 싶은 사람을 지정

4-4. 참고 문서 : 프로덕트 스펙 문서를 함께 첨부하면 전반적인 프로젝트를 이해하는 데에 도움, 디자인 파일과 프로토타입도 함께 공유

4-5. 피드백 기한 : 제품 개발, 배포 일정에 영향을 주지 않도록 피드백을 받을 수 있는 충분한 여유, 일정이 촉박할시 피드백을 받고 싶은 기한 표시

[실무 프로세스1 : 협업하기] 

1. 협업이란? 

협업의 질은 곧 제품의 질

- 협업이란 각 직무의 리소스가 낭비 없이 좋은 솔루션을 만드는 데 집중적으로 쓰이는 것을 의미

- 서로가 더 좋은 퍼포먼스를 낼 수 있도록 돕고 시너지를 낼 수 있도록 하는 것 = 좋은 협업

2. PO/PM 이해하기

1) PM

- PM은 Product Manager의 약자 즉, 프로덕트 매니저

- 제품의 전략을 수립하고 아이디어의 우선순위를 정해 디자이너와 함께 솔루션을 설계, 실제 프로젝트를 수행하는 실무의 성격

- 프로덕트 매니저는 제품의 전략을 세우고, 우선순위를 결정해 실행하는 사람

2) PO

- PO는 Product Owner의 약자 (미니 CEO)

- 일반적으로 PM보다 더 많은 역할과 책임(PM보다 상위 개념)

- 제품팀을 이끌며 제품이 시장에 잘 전달될 수 있도록 관리

- 이해관계자들과 논의, 제품팀의 팀원들이 제품을 잘 만들 수 있는 환경 조성

- 프로덕트 오너는 제품에 대한 오너십을 갖고 제품이 시장에 잘 전달될 수 있도록 관리하는 사람

3) PM과 PO, 차이점

PM

- 실무 중심 프로젝트 관리

- 요구사항 분석, 전략 설계, 지표 관리 및 분석 등의 업무를 수행

PO 

- 제품 전반의 로드맵을 그리고 제품을 관리

- 로드맵과 전략 설계, 지표 관리 및 분석 등의 업무를 하며 동시에 제품팀의 조직 관리

3. 엔지니어 이해하기

왜 엔지니어를 이해해야 할까

1) 프론트엔드 엔지니어

: 프론트엔드 엔지니어는 앱/웹의 페이지, 화면 안의 각종 컴포넌트 즉, UI를 코드로 구현

- 단순히 그래픽을 구현하는 것을 넘어서 화면 간의 이동, 컴포넌트의 모션, 사용자의 인풋에 따른 반응까지 구현하기 때문에 사용자의 경험을 만드는 UX와도 깊게 관련

- 사용자가 만나는 지점, 특히 눈에 보이는 영역의 기능을 구현하는 사람

2) 백엔드 엔지니어

: 정보를 저장, 전송, 제품 전체를 효율적으로 운영할 수 있도록 구조를 고민하는 역할

Ex. 제품에서 특정 정보를 가져와 사용자에게 보여주는 기능이 있다면 저장된 정보를 가져오는 것 => 백엔드 엔지니어의 의견이 중요

- 제품에 필요한 정보를 저장하거나 전송하고, 관리하는 영역을 담당하는 사람

3) QA 엔지니어

- QA 엔지니어는 기능이 개발되면 배포하기 전에 테스트 (제품 퀄리티의 테스트)

- 지속해서 제품을 모니터링 -> 서비스의 안정성과 품질을 지키기 위해 노력

- QA 테스트를 계획, 진행하고 제품 전반적인 품질을 높이는 역할을 하는 사람

4) 데이터 애널리스트

- 데이터베이스에서 SQL 같은 언어를 사용해 필요한 데이터를 추출하고, 파이썬 등을 활용해 여러 방면으로 분석하는 일

- 데이터를 보기 좋은 형태로 가공하고 시각화하여 제품팀의 의사결정을 도움

 - 데이터 애널리스트는 수집하고 분석해서 인사이트를 제공하는 사람

=> 엔지니어는 디자이너가 그린 화면을 실제 동작하는 화면으로 만들어 주는 사람

**엔지니어와의 소통이 원활할수록 디자인이 더 정확하고 완성도 높은 수준으로 사용자에게 전달 가능

4. UX/UI 직무 이해하기

1) BX 디자이너

- Brand eXperience의 줄임말로, 브랜드 경험과 관련된 전반적인 디자인을 하는 사람

- 로고나 심볼처럼 기본적인 것부터 앱/웹에 들어가는 그래픽, 대외에 노출되는 이미지, 각종 인쇄물 등 브랜드를 나타내는 모든 부분을 담당

2) UX writer 

- 제품 내의 문구를 담당하는 사람

- 브랜드의 보이스앤톤을 문구로 전달하고, 명확한 메시지를 통해 제품의 사용성을 높이는 일을 함 

[실무 프로세스2 : 실험문화] 

1. 실험이란?

제품의 개선이 실제로 사용자에게 더 나은 경험으로 이어지는지 데이터로 검증하는 것

1-1. 실험을 하는 이유 

- 사람은 편향적이기 때문에 만드는 사람의 주관이 제품에 반영되기 쉬움 (사용자가 원하는 제품이 아닌 공급자가 만들고 싶은 제품을 제작할 가능성)

- 데이터로 사용자의 데이터를 확인하면, 객관적으로 의사결정 가능 (데이터로 증명)

2. 실험 환경 이해하기 

- 실험은 대부분 A/B 테스트로 진행

- A/B 테스트 설계를 할 수 없을 때, 특정한 상황에서 전/후 비교 테스트

* 전/후 비교 테스트 : 실험 기간 전후로 지표가 어떻게 달라졌는지를 비교

Ex. 커머스에서 상품 리스트 페이지를 개선하고 상품 구매율의 변화를 보는 상황이라고 가정

12월 1일에 실험이 시작되어 3주간 진행

12월 1일 이전 3주의 데이터와 이후 3주의 데이터를 추출하여 상품 구매율이 달라졌는지 확인

3. A/B 테스트 

: A/B 테스트란 두 가지 이상의 버전을 각각 다른 사용자에게 보여주고 성과를 측정하는 실험

- 대조군(Control_원안)과 실험군(Treatment_개선안), 두 집단으로 나누고 서로 다른 안을 보여준 다음 어느 집단이 더 좋은 지표를 보이는지 측정하여 평가

4. A/B 테스트 방법

- 기존 화면은 대조군(Control_효과 검증을 위한 비교 대상), 테스트하고 싶은 안을 실험군(Treatment)으로 정함

- A/B 테스트의 효과를 정확히 파악하기 위해 테스트하는 변수는 가능한 1개로 제한 (=1개의 변화 =1개의 개선)

5. A/B 테스트를 하는 이유?

제품에 어떤 변화를 줬을 때 사용자가 어떻게 반응하고 행동하는지 정보를 얻기 위함

- 변화를 주었을 때 행동이 달라졌다면, 그 안에서 상관관계와 인과관계 도출 가능 

- 거듭된 실험을 통해 제품팀은 사용자에 대한 이해도가 높아지고, 더 나은 의사결정 가능

Ex. A 집단과 B 집단에게 똑같은 장바구니 화면에서 결제하기 버튼 하나만 다르게 해서 보여줌

A 집단의 결제하기 버튼은 검정, B 집단의 결제하기 버튼은 빨강

실험 결과 A 집단보다 B 집단의 결제율이 2배 더 높게 나타남 

=> A/B 테스트로 제품팀은 빨간색 결제하기 버튼이 결제율에 긍정적인 영향을 준다는 결과

5. 실험을 위한 제품 분석 도구

데이터를 쌓고 분석하는 도구

1) 앰플리튜드

https://amplitude.com

 

- 제품 안에서 일어나는 특정 행동에 이벤트를 심어두면 해당 행동이 일어났을 때를 기록해 데이터를 쌓고 보여줌

- 이벤트별 분석, 화면별 퍼널 분석, 리텐션 그래프, 유저 구성 등의 기능이 있어서 제품에 관한 다양한 데이터를 얻고 분석 가능

2) 구글 애널리틱스 (GA4)

https://developers.google.com/analytics?hl=ko

- 구글에서 제공하는 무료 분석 툴로, 대중적인 인지도가 높고 많이 쓰이는 분석 도구

- 구버전인 Universal Analytics에서 Google Analytics 4로 버전 변경 => 잘 구분해야 함 

- GA4는 이벤트 중심으로 데이터를 수집하고 특정 페이지 조회, 링크나 버튼 클릭, 스크롤 내리기 등 사용자 상호작용을 기록

3) 플리튜드와 구글 애널리틱스의 차이

앰플리튜드

- 유료(가격이 비쌈) 대신 제품에 관한 대부분의 데이터를 추적하고 분석 가능

- 제품 분석 도구 중에 가장 기능이 다양하고 인지도가 높음

- 주로 PO/PM이 많이 사용

구글 애널리틱스

- 일정 이벤트 수까지는 무료라는 강점

- 구글의 마케팅 플랫폼과의 연계성이 좋아 주로 마케터들이 많이 사용

[실무 프로세스3 : 디자인 QA] 

1. QA란?

*** QA는 Quality Assurance의 약자로, 제품이 출시되기 전에 기능을 테스트하는 것

- 제품이 처음 기획한 대로 잘 구현이 되었는지, 회사에서 생각하는 품질 기준이 충족되었는지를 확인하는 과정

- 규모에 따라 별도로 QA 팀이 있기도 하고 제품팀에서 QA를 수행하기도

- QA 팀이 있더라도 기능을 만든 담당자라면 대부분 직접 QA를 진행

1-1. QA 목적

- 사용자가 제품을 이용할 수 없을 만큼의 치명적인 결함은 없는지 확인

- 조직 전체에서 기대하는 수준의 품질이 갖춰졌는지 확인

- Product Spec 문서에서 작성했던 명세대로 잘 구현되었는지 확인

- 특수한 상황에서 예상하지 못한 대로 동작하지는 않는지 확인

- 전반적인 UX가 사용하기 편리한지 확인

2. QA 문서

1) 체크리스트

- 예/아니요, 혹은 Pass/Fail로 답변할 수 있는 확인 성격의 항목을 나열한 목록

- 기능이나 개선 범위가 넓지 않을 때 사용

Ex. 버튼을 눌렀을 때 색상이 변하나요?

Ex. 버튼을 눌렀을 때 A 페이지로 이동하나요?

2) 테스트 시나리오 (TS)

- 기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서

- 사용자가 기능을 사용하면서 경험하게 되는 과정을 상세하게 기재

Ex. 회원가입 flow를 테스트하는 상황

1. 회원가입은 카카오톡, 네이버, 일반 회원가입 3가지

2. 일반 회원가입의 경우 이메일, 비밀번호, 이름을 입력

3. 올바르지 않은 정보를 입력할 경우 텍스트 필드 아래에 얼럿 메시지가 노출

4. CTA 버튼을 누르면 회원가입 요청

*** 3) 테스트 케이스 (TC)

- 특정 조건에서 요구 사항을 충족하는지 확인하기 위해 모든 케이스를 작성한 문서

- 특정 조건 아래의 환경을 테스트하는 것이기 때문에 특정 조건, 테스트 범위, 케이스, 기댓값, 테스트 환경 등을 상세하게 기재

Ex. 회원가입 flow를 테스트하는 상황

화면	조건	테스트 케이스	입력값	기댓값	테스트 환경
일반 회원가입	정상	모든 텍스트 필드에 정상 값 입력	email: ‘test@gmail.com’ name: ‘김땡땡’ password: ’test123’	회원가입 완료 화면으로 이동	iOS/Android/Web
일반 회원가입	에러	형식에 맞지 않은 이메일 입력	email: ‘testgmail.com’	텍스트 필드 아래에 얼럿 메시지가 노출	iOS/Android/Web

3. 디자인 QA

디자인이 정확하게 개발되었는지 확인하는 절차

3-1. 디자인 QA에서 발견한 이슈 공유하기 

- 디자인과 다른 부분을 발견했다면 팀원들과 내용을 공유하고 수정을 요청해야 함

- 어디가 잘못되었는지 엔지니어가 정확하게 알 수 있도록 작성

- 잘못 개발된 화면과, 원래의 디자인 화면을 기획 의도와 함께 전달

 - 지라나 트렐로 같은 프로젝트 관리 툴을 사용하여 관리하기 좋게 발견한 이슈를 업무 티켓 형태로 전달하는 것 추천 (구두 논의 -> 기억하기 어려움) 

https://www.atlassian.com/software/jira

https://trello.com

- 실패 포인트 설명 -> 원래 의도 작성 후 전달

3-2. 이슈의 중요도 정의하기 

- 중요한 것부터 해결할 수 있도록 중요도 표시하기

- 배포 일정이 촉박한 경우 QA에서 발견한 모든 이슈를 수정하지 못하고 배포해야 하는 경우 존재

1) Highest

- 당장 대응이 필요할 정도로 주요 기능에 문제가 있는 경우

2) High

- 사용자가 행동을 완수할 수 없는 이슈

- 기능상 사용성에 치명적인 문제가 될 수 있는 것

3) Medium

- 사용자가 행동을 완수하는 데 어려움을 겪을 수 있는 문제

- 단계를 넘어가는 데에 어려움이 없으나 기획이나 피그마 디자인 화면과 다르게 적용된 것

- 사용자가 상황을 제대로 이해하기에 어려움이 있는 것

Ex. 네트워크 오류로 팝업이 떠야 하는 상황에서 알 수 없는 오류 팝업이 뜨는 이슈

- 시각적으로 오류가 난 것처럼 보이는 것

4) Low

- 기능상 문제가 없는 것

- 피그마 화면과는 다르지만, 맥락상 과정을 이해하기에 어려움이 없는 것

- 오픈 후 수정되어도 문제없는 디테일한 부분

5) Lowest

- 단순 의견 정도의 레벨로 급하게 반영되지 않아도 될 이슈