AI야, 기획 아이디어 줄래?

페이지 넘기면 초기화되는 데이터? 기획 단계에서 잡는 글로벌 상태 체크리스트 페이지 넘기면 초기화되는 데이터? 기획 단계에서 잡는 글로벌 상태 체크리스트 개발자와 회의하다 보면 이런 말을 듣곤 합니다. “그건 전역 상태(Global State)로 관리해야 해서 공수가 좀 들어요.” 혹은 “페이지 이동하면 데이터가 날아가는 게 기본 동작입니다.” 기획자 입장에서는 “당연히 유지돼야 하는 정보”인데, 개발에서는 왜 별도 설계가 필요할까요? 결론부터 말하면, 유지 범위를 정의하지 않으면 서비스는 “기억력 3초짜리 금붕어 모드”가 됩니다 🐟 오늘은 React 기반 프로젝트에서 데이터 유실 버그를 미리 차단하는 글로벌 상태 체크리스트 를 핵심만 정리합니다. 📚 목차 전역 상태(Global State), 왜 기획자가 알아야 할까? 기획자가 챙겨야 할 3대 글로벌 상태 체크리스트 “유지 범위”를 한 줄로 못 박는 프레임 전역 상태 설계에서 자주 터지는 함정 6가지 마치며: 기획이 탄탄하면 버그가 줄어듭니다 FAQ 1. 전역 상태(Global State), 왜 기획자가 알아야 할까? React는 기본적으로 컴포넌트 단위 로 상태가 존재합니다. 특정 페이지(화면)에서만 쓰는 데이터는 그 페이지를 떠나는 순간 “자연 소멸”이 기본값입니다. 그래서 페이지 이동/라우팅이 일어나면, 개발 관점에서는 상태를 어디에 둘지 를 다시 결정해야 합니다. 하지만 서비...

그림 말고 '로직'을 그리세요: 개발자가 한 번에 이해하는 피그마 유저 플로우 작성법 그림 말고 '로직'을 그리세요: 개발자가 한 번에 이해하는 피그마 유저 플로우 작성법 기획서에 화면 수십 장을 나열했는데 개발자에게 이런 질문을 받나요? “그래서 이 버튼 누르면 정확히 어떤 조건에서 어디로 가나요?” “로그인 안 되어 있으면요? 네트워크 실패면요?” 단순히 화면을 선으로 잇는 건 ‘그림’입니다. 진짜 기획서는 사용자 행동 과 시스템 판단 이 얽힌 로직(Logic) 이 보여야 합니다. 오늘은 피그마 생태계(특히 FigJam )를 활용해 개발자가 질문할 틈이 없는 살아있는 유저 플로우 를 만드는 방법을 정리합니다. 🗺️ 📚 목차 ‘화면 나열’과 ‘유저 플로우’의 결정적 차이 피그마에서 로직을 시각화하는 3가지 도구(Section, Connector, Label) 개발자가 감동하는 유저 플로우 표기 규칙(라벨 문법) 의사결정 다이아몬드(Decision)로 “시스템 판단”을 그리는 법 예외 케이스(Empty/Error)를 플로우에 포함하는 방법 10분 루틴: 살아있는 유저 플로우 작성 순서 예시: 결제 플로우(로그인·잔액·성공/실패) 텍스트 모델 개발 전달 체크리스트 FAQ 1) ‘화면 나열’과 ‘유저 플로우’의 결정적 차이 주니어 기획에서 흔한 실수는 해피 패스(Happy Path)만 따라 화면을 줄 세우는 것입니다. 하지만 서비스는 대부분 갈림길(Condition) 로 만들어집니다. 화면 나열(그림) A 화면 → B 화면 → C 화면 유저 플로우(로직) A 화면 ...

주니어와 시니어의 차이, '예외 케이스' 기획의 한 끗: 데이터 없음과 에러 화면 설계 주니어와 시니어의 차이, '예외 케이스' 기획의 한 끗: 데이터 없음과 에러 화면 설계 신입 기획자와 숙련된 기획자의 기획서를 비교하면, 가장 눈에 띄는 차이는 대개 “잘 되는 화면(Happy Path)”이 아닙니다. 데이터가 없거나 문제가 생긴 순간 을 얼마나 촘촘하게 설계했느냐가 진짜 차이를 만듭니다. 사용자가 서비스에서 가장 크게 불쾌감을 느끼는 순간은 “막혔다”를 체감하는 때입니다. 이 위기의 순간을 이탈 이 아니라 다음 행동 으로 바꾸는 방법, 오늘은 Empty와 Error 상태를 “기획자의 언어”로 정리해봅니다. 📚 목차 왜 Empty와 Error가 ‘시니어의 한 끗’인가? 사용자를 방치하지 않는 Empty State 설계 당황한 사용자를 달래는 Error State 설계 피그마에서 예외 화면을 ‘재사용 가능한 시스템’으로 만드는 법 개발 전달용: Empty/Error 스펙 템플릿(복붙용) 실무 체크리스트(검색 없음/첫 진입/시스템 오류) 결론 FAQ 1) 왜 Empty와 Error가 ‘시니어의 한 끗’인가? Happy Path는 대부분 팀이 “자연스럽게” 그립니다. 문제는 예외 상황입니다. 예외는 보통 다음과 같이 방치됩니다. “데이터가 없습니다” 한 줄로 종료 “알 수 없는 오류”로 사용자를 미궁에 봉인 404/500에 버튼 없이 벽만 세움 시니어의 기획은 여기서 갈립니다. 빈 화면을 “공백”으로 보지 않고 가이드 영역 으로 보고, 에러를 “사과문”이 아니라 복구 동선 으로 설계합니다. 핵심...

폰트 수치 일일이 적지 마세요: 개발자가 감동하는 기획자의 타이포그래피 가이드 폰트 수치 일일이 적지 마세요: 개발자가 감동하는 기획자의 타이포그래피 가이드 화면 하나 만들 때마다 “16px, Bold, 행간 140%…”를 텍스트 옆에 적고 있나요? 화면이 수십 장이 되면 기획자는 숫자에 흔들리고, 개발자는 매번 캡처해서 확인합니다. 결국 폰트는 커지고, 일정은 작아집니다. 🫠 해결책은 단순합니다. 수치로 소통하지 말고, ‘이름(스타일)’으로 소통 하세요. 피그마의 텍스트 스타일(Text styles) 을 “타이포그래피 규칙(디자인 토큰)”으로 시스템화하면, 기획서에서 폰트 수치 기입 노동이 거의 사라지고 개발 전달도 깔끔해집니다. 📚 목차 수치가 아닌 ‘이름’으로 소통하기 기획자가 잡아야 할 타이포그래피 핵심 3요소 실무 바로 적용: 텍스트 스타일 5종 세트(추천 수치 포함) 실무 네이밍 규칙(Body-1, Title-Large) 정하기 피그마에서 텍스트 스타일 등록하는 법 개발자가 감동하는 Typography Guide 페이지 구성 자주 터지는 실수 체크 FAQ 1) 수치가 아닌 ‘이름’으로 소통하기 개발은 보통 “16px Bold”를 화면마다 다시 읽지 않습니다. 대신 Body-1 , Title-Large 같은 스타일 이름 을 코드에 한 번 선언하고 계속 재사용합니다. 기획자: “본문은 Body-1, 섹션 제목은 Title-Medium” 개발자: .typo-body-1 같은 클래스(또는 토큰)를 만들어 반복 적용 결론 : 숫자는 “매번 확인”, 이름은 “한 번만 합의”입니다. 2) 기획자가 잡아야 할 ...

퇴직연금 의무화 언제부터? 2026년 달라지는 제도와 사업장 규모별 도입 시기 총정리 퇴직연금 의무화 언제부터? 2026년 달라지는 제도와 사업장 규모별 도입 시기 총정리 직장인에게는 노후의 생명줄, 사업주에게는 운영의 큰 축인 퇴직금 . 이제는 “회사 금고에 쌓아두는 방식”에서 벗어나 퇴직연금(퇴직급여 사외적립) 으로 옮겨가는 흐름이 본격화되고 있습니다. 퇴직금이 월급보다 빨리 사라지는 마법(…)을 막고, 오래 굴려서 노후에 제대로 쓰게 하자는 취지죠. 🧙‍♂️💸 [업데이트] 이 글은 2026-02-08 기준으로 작성했으며, 2026-02-06 발표된 노사정 공동선언(퇴직연금 사외적립 의무화·기금형 활성화) 흐름을 반영했습니다. 단, 세부 시행 시점/단계는 법 개정 및 후속 절차에 따라 달라질 수 있습니다. 서론: “퇴직금, 이제는 ‘내 계좌’로 굴리는 시대” 기존 퇴직금 제도는 회사가 내부적으로 적립하다 보니, 기업 경영이 흔들릴 때 수급권이 불안 해질 수 있다는 지적이 이어졌습니다. 반면 퇴직연금은 외부 금융기관(사외) 에 적립·운용되는 구조라 제도 설계만 잘 되면 “떼일 위험을 줄이고(체불 방지)” “장기 운용(노후소득 강화)”에 유리합니다. 그래서 2026년을 기점으로 ‘단계적 의무화’가 현실적인 과제가 됐습니다. 이 글에서는 도입 시기(확정 vs 논의) , DB/DC 차이 , 미도입/미납 리스크 , 그리고 직장인·사업주 체크리스트 까지 한 번에 정리합니다. 📚 목차 퇴직연금 의무화, 왜 추진하나요? 2026년 달라지는 핵심: ‘사외적립 의무화’와 ‘기금형’ 사...