#product
노트 24개
Frontend › Mobile
모바일 앱 출시 과정모바일 앱은 스토어 심사를 거쳐야 사용자에게 닿기 때문에 웹 배포와 절차가 다르다. 개발자 등록, 빌드와 테스트, 내부·외부 베타와 회귀 테스트, 내부 승인과 정책 준수, 스토어 최적화(ASO), App Store Connect·Google Play Console 제출, 단계적 출시까지의 흐름을 정리한다.
Frontend › UI Design
와이어프레임, 목업, 프로토타입: 충실도에 따른 화면 설계 산출물화면 설계는 정보 구조와 유저 플로우에서 시작해, 구조와 우선순위만 담은 와이어프레임, 실제 생김새를 입힌 정적인 목업, 클릭해 볼 수 있는 프로토타입 순으로 충실도를 높여 가며, 단계마다 답하려는 질문과 버려도 되는 비용이 다르다. 와이어프레임은 클릭되게 만들고, 도구는 공통 요소 관리·화면 전환·리뷰·산출물 기준으로 고른다.
AI & Data
예측형 AI와 생성형 AI예측형 AI는 과거 데이터에서 분류·회귀·추천·이상 탐지 같은 좁은 답을 내고, 대개 직접 학습한 모델로 만든다. 생성형 AI는 사전 학습된 큰 모델 위에 프롬프트·컨텍스트를 얹어 열린 출력을 만든다. 두 방식의 개발 루프, 평가 방법, 흔한 함정과 대응을 비교한다.
AI & Data
책임 있는 AI: 윤리, 프라이버시·공정성·신뢰AI의 판단은 데이터와 설계자의 선택이 담긴 산출물이라는 관점에서, AI 거버넌스의 세 축인 프라이버시·공정성·신뢰와 투명성을 데이터·지능·UX 세 층에 나눠 무엇을 할지 정리한다. 덜 모으고 PII를 지우고, 데이터 편향(COMPAS, 하위 집단 누락)을 점검하고 신고 경로를 열고, 사용자를 '보정된 신뢰'로 이끌며, 트롤리 딜레마·모럴 머신처럼 정답 없는 판단은 명시하고 공론화한다.
AI & Data
프로덕트 데이터 분석: 지표, 로그, 실험서비스에 쌓이는 사용자 데이터로 제품을 계속 고치는 일. 서비스를 보는 틀(AARRR) → 로그를 지표로 → 지금 가장 중요한 지표(OMTM) → 쪼개서 들여다보기의 순서로 진행한다. 지표의 조작적 정의, 저량과 유량, 허무 지표, 선행 지표, 로그가 분석의 전제인 이유, 심슨의 역설·코호트·퍼널, A/B 테스트와 밴딧, 결과를 행동으로 옮기는 법을 정리한다.
AI & Data
AI 기능 기획: 시스템 블루프린트와 유스케이스 발굴웹 서비스에 AI 기능을 넣기 전에 기회(유스케이스·가치) → 솔루션(데이터·지능·UX) → 거버넌스의 세 관점으로 지도를 그린다. 가치 범주로 아이디어를 내고, 사용자 여정에 배치하고, 데이터 준비도·비용·실패 모드를 따져 우선순위를 정한 뒤 끝에서 끝까지 이어지는 프로토타입으로 검증한다.
AI & Data
AI 기능의 UX 패턴: 배경형·제한형·개방형AI 기능은 사용자에게 드러나는 정도에 따라 배경형(조용히 기존 경험을 돕는다), 제한형(버튼으로 정해진 작업을 부른다), 개방형(자유 입력)으로 나뉜다. 노출이 클수록 유연하지만 위험도 커진다. 유형별 예와 모범 사례, 둘 중 고르는 기준, 투명성·안내·제어·신뢰 보정·실패 관리 패턴 표를 정리한다.
Career
개발자로 일하며 성장하는 법, 협업, 의사결정, 제품 관점과 리더십, 구직 준비, 그리고 분야별 읽을 책 목록을 모은 커리어 메모.
Career › Product
공감하는 제품 만들기: 경청 세션과 스트레스 케이스공감은 친절이 아니라 상대의 사고 흐름을 이해하는 기술이다. 표면 의견 밑의 이유와 망설임을 듣는 경청 세션 진행법, 엣지 케이스를 스트레스 케이스로 바꿔 보는 관점, 사전 부검으로 해로운 시나리오를 미리 찾는 법을 정리했다.
Career › Product
기능 공장: 출시량이 아니라 결과를 보는 팀기능을 많이 내보내는 것을 성과로 착각하는 팀을 기능 공장이라 부른다. 측정·회고·사후 점검이 없고 로드맵이 기능 목록인 12가지 신호로 진단하고, 출력(output) 대신 결과(outcome)와 학습을 기준으로 일하도록 바꾼다.
Career › Product
기술 부채기술 부채는 지금 빠른 길을 택한 대가로 나중에 치르는 추가 작업이다. 원금(고치는 비용)과 이자(고치지 않아 매번 더 드는 비용)로 생각하고, 파울러의 사분면으로 원인을 나누며, 백로그 항목으로 보이게 만든 뒤 이자가 큰 곳부터 갚는다.
Career › Product
디자이너와 함께 일하기: 역할·채용·협업그래픽·인터랙션·UX 디자인의 차이, 디자이너를 뽑기 전에 정할 권한과 성공 기준, 서로 다른 관점을 섞는 팀 구성(경쟁가치모형), 디자이너·개발자·고객·브랜드 에이전시가 함께 일하는 원칙을 정리했다.
Career › Product
백로그와 추정: 에픽·사용자 스토리·스토리 포인트큰 목표를 에픽과 사용자 스토리로 쪼개고(3C, INVEST, 인수 기준), 스토리 포인트와 플래닝 포커로 상대 크기를 추정하고, 속도와 번다운·번업 차트로 진척을 본다. 각 도구는 계획을 돕는 설명 지표이지 성과 지표가 아니라는 점이 핵심이다.
Career › Product
사용자 리서치: 방법 고르기, 페르소나·시나리오, 사용성 평가더블 다이아몬드의 단계마다 맞는 리서치 방법이 다르다. 사용자를 직접 못 만나면 리뷰·상담 기록·포럼을 쓰고, 조사 결과는 근거 있는 페르소나와 사용 전·중·후 UX 시나리오로 정리해 UX 전략으로 잇는다. 화면은 닐슨의 10가지 휴리스틱 평가와 5명 단위 사용성 테스트로 검증하고, 큰 조직에서는 정기 세션으로 학습 문화를 만든다. 급할수록 맥락·분석 시간·자기 디자인에 대한 애착을 경계하고, 참가자 보호를 위한 윤리 절차를 갖춘다.
Career › Product
새 서비스 개발 프로젝트 진행 순서기획 → 개발 기반 구축 → 개발 진행 → 서비스 진화의 기승전결로 정리한 서비스 개발 절차.
Career › Product
애자일과 스프린트애자일의 핵심은 만들고-보여주고-피드백 받고-방향을 맞추는 주기를 모두가 함께 짧게 만드는 것이다. 스프린트는 목표를 쳐내는 마감 장치가 아니라 정해진 주기마다 속도와 방향을 점검하는 장치이며, 일정은 미리 예측하지 말고 만들어 보며 측정한다. 구글 스프린트 5일 구성과 장치들, 폭포수와 애자일을 고르는 기준도 함께 정리했다.
Career › Product
유스케이스 다이어그램UML 유스케이스 다이어그램으로 시스템이 누구에게 어떤 기능을 제공하는지 한 장에 그려 범위를 합의하는 법. 액터·유스케이스·시스템 경계, 연관·일반화·include·extend 관계, 작성 4단계, 정상·대안·예외 흐름과 시나리오를 담는 유스케이스 명세, 흔한 실수를 정리한다.
Career › Product
제품 중심 개발자 (Product-Minded Engineer)기획을 구현만 하지 않고 제품의 이유를 묻고, 제품·엔지니어링 트레이드오프를 함께 제안하며, 출시 후 데이터까지 책임지는 개발자의 9가지 특징과 성장 방법. 목적 조직에서 개발자가 맡는 역할과 OKR·애자일의 관계까지.
Career › Product
조직의 디지털 전환과 웹 거버넌스디지털 전환은 기술 도입이 아니라 고객 행동 변화에 조직을 맞추는 일이다. 디지털 성숙도 5단계, 웹 거버넌스의 네 영역(전략·관리·실행·측정), 권한 없는 실무자가 변화를 이끄는 방법을 정리했다.
Career › Product
초기 스타트업과 창업: 개발자가 빠지기 쉬운 함정초기 스타트업 엔지니어는 아키텍처부터 고객 대화·온콜·채용까지 맡는다. 개발자가 창업할 때는 기술 중심 피벗, 복잡한 사업 모델, 장인 정신이라는 세 함정을 피하고, 작은 제품을 빨리 내서 검증 횟수를 늘린다.
Career › Product
콘텐츠 전략과 핵심 모델콘텐츠는 목적·핵심 메시지·다음 궁금증·운영 계획을 갖춰야 전략이 된다. 메인 페이지가 아니라 사업 목표와 사용자 작업이 겹치는 핵심 페이지부터 설계하는 핵심 모델(core model)과 워크숍 진행법을 정리했다.
Career › Product
투자자가 보는 IR 자료: 시장·비즈니스 모델·숫자스타트업이 기관 투자를 받을 때 거치는 실사에서 투자자가 듣고 싶은 것. 회사 소개보다 시장(TAM)과 성장, 좁혀 말한 비즈니스 모델, 경영진이 보는 지표와 숫자로 표현한 고객, 유닛 이코노믹스와 성장 요인을 쪼갠 브리지 분석, 고정비·변동비와 재무 계획, 약점의 솔직한 공개, ESG를 숫자로 설명하는 법을 정리한다.
Career › Product
BDD·SDD로 기획서를 태스크로 나누기기획·디자인·개발·QA가 같은 문서를 보도록 기획을 사용자 행동(BDD의 given-when-then)과 데이터 구조(SDD)로 정리해 태스크를 만드는 방법. then 하나가 태스크 하나가 되어 진척도·일정·테스트 범위가 함께 보이고, Figma에 디자인과 기획을 합쳐 두면 최신 화면까지 한곳에서 관리된다.
Career › Product
Shape Up: 6주 사이클 제품 개발 방식Basecamp가 만든 제품 개발 방식. 견적 대신 투입할 시간의 상한(appetite)을 먼저 정하고, 거칠지만 위험을 제거한 형태(shape)로 다듬은 피치를 베팅 테이블에서 골라 6주 동안 팀에 맡긴다. 백로그를 두지 않고, 시간이 다 되면 범위를 줄여서라도 끝낸다.