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

그림 말고 '로직'을 그리세요: 개발자가 한 번에 이해하는 피그마 유저 플로우 작성법 그림 말고 '로직'을 그리세요: 개발자가 한 번에 이해하는 피그마 유저 플로우 작성법 기획서에 화면 수십 장을 나열했는데 개발자에게 이런 질문을 받나요? “그래서 이 버튼 누르면 정확히 어떤 조건에서 어디로 가나요?” “로그인 안 되어 있으면요? 네트워크 실패면요?” 단순히 화면을 선으로 잇는 건 ‘그림’입니다. 진짜 기획서는 사용자 행동 과 시스템 판단 이 얽힌 로직(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년 달라지는 핵심: ‘사외적립 의무화’와 ‘기금형’ 사...

개발자가 자꾸 물어본다면? 피그마 기획서에 '컴포넌트 상태(State)' 정의하는 법 개발자가 자꾸 물어본다면? 피그마 기획서에 '컴포넌트 상태' 정의하는 법 기획안을 넘기고 나면 끝날 줄 알았는데, 개발자에게 이런 질문을 자주 받나요? “이 버튼 누르면 로딩 중 일 때 어떻게 보여요?” “값 입력 안 했을 때 비활성화 되나요?” “ 에러 메시지 는 어디에 떠요?” 이 질문들이 반복된다면, 기획서에 빠진 건 기능이 아니라 상태(State) 입니다. 오늘은 피그마에서 컴포넌트 상태를 ‘한 번만’ 제대로 정의 해서, 질문은 줄이고 완성도는 올리는 방법을 정리합니다. (버튼 박스 밀기 대신 퇴근을 밀어봅시다. ✅) 📚 목차 상태(State) 정의, 왜 기획자가 해야 할까? 기획자가 챙겨야 할 5가지 필수 상태 피그마로 상태 정의하는 법: Variants + 조건(Logic) 텍스트 바로 복붙 가능한 상태 정의 템플릿(버튼/인풋) 예외 케이스(Edge Case) 체크리스트 개발자가 감동하는 구성: ‘공통 컴포넌트 가이드’ 섹션 FAQ 1) 상태(State) 정의, 왜 기획자가 해야 할까? 디자인이 ‘심미성’을 다듬는다면, 기획은 ‘논리’를 설계합니다. 즉, 사용자의 액션에 따라 화면이 어떻게 변해야 하는지 를 가장 정확히 아는 사람은 기획자일 때가 많습니다. 누락 방지 : 상태를 적어두면 개발 시 예외 처리(Disabled/Loading/Error)가 빠질 확률이 낮아집니다. 해석 비용 절감 : “그때그때 맞추죠”는 대개 재작업으로 돌아옵니다. 품질 상승 : 동일한 컴포넌트가 ...