MINIWIKI
CareerSideProjectBook&Study
  • ⚡README
  • 😃ME
    • Review
      • 2025 OKR & 회고 - 회사 없이도 먹고살 수 있는 상태가 된다
        • 2025년 20주차
        • 2025년 19주차
        • 2025년 18주차
        • 2025년 17주차
        • 소설쓰기의 쓸모
        • 2025년 15주차
        • 2025년 14주차
        • 요즘 회사생활
        • 첫 페이지 작성!
        • 큰 코 다쳤다
        • 오랜만에 좋았던 하루
        • 악순환과 반복실패
        • 2025년 12주차
        • 2025년 11주차
        • 2025년 3월 6일
        • 2025년 3월 4일
        • 2025년 3월 1일
        • 2025년 2월 회고
        • 2025년 1-2월 책, 영화, 음악
        • 2025년 1-2월 회고 (PM)
        • 2025년 1-2월 회고 (콘제품)
          • (Merged) 2025 비즈니스
        • 2025년 1-2월 회고 (삶/사람)
        • 2025년 1-2월 회고 (기본)
        • (25.02) 고객 피드백 받기
        • 다시 전략 수정
        • 머리 속 복잡한 것들 끄적끄적
        • 변하지 않는 핵심 철학
        • 개별화 능력을 이용하는 방법
        • 파고들기
        • 예술가와 사업가
        • 강점
        • PM으로서의 전문성
        • 부동시
        • 이게 다 무슨 소용인가
        • 내가 가장 잘 전할 수 있는 메시지
        • 연말인사 타이밍
        • Attitude는 옷부터
        • 다시 시작
      • 2024 회고
        • 2024년 12월 4주차 (52/52)
        • 원한다고 생각했던 것들
        • 2024년 12월 3주차 (51/52)
        • 회사 vs. 퇴사
        • 2024년 12월 2주차 (50/52)
        • 2024년 11월 4주차 (47/52)
        • 2024년 11월 3주차 (46/52)
        • 2024년 11월 1주차 (44/52)
        • 혓바늘
        • 2024년 10월 3주차 (42/52)
        • 그냥, 요즘하고 있는 생각들
        • 2024년 10월 1주차 (40/52)
        • 2024년 9월 4주차 (39/52)
        • 2024년 9월 3주차 (38/52)
        • 2024년 9월 2주차 (37/52)
        • 2024년 9월 1주차 (36/52)
        • 2024년 8월 4주차 (35/52)
        • 잃어버린 보물창고
        • 분기별 프로젝트
        • 강점검사
        • 글쓰기
        • 이상적인 하루
        • 나와 아프리카
        • 한 때 나에게 힘이되었던 문장들
      • 2023 회고
        • 2023년 12월 5주차
        • 2023년 12월 4주차
        • 2023년 12월 3주차
        • 2023년 12월 2주차
        • 2023년 12월 3일
        • 2023년 12월 1주차
        • 2023년 11월 29일
        • 2023년 11월 28일
        • 2023년 11월 27일
        • 2023년 11월 18일
        • 2023년 11월 15일
        • 2023년 11월 12일
        • 2023년 11월 11일
        • 2023년 11월 1주차
        • 2023년 10월 3주차
        • 2023년 9월 4주차
        • 2023년 9월 3주차
        • 2023년 9월 2주차
        • 2023년 9월 1주차
        • 2023년 8월 4주차
        • 2023년 8월 2주차
        • 2023년 8월 1주차
        • 2023년 7월 4주차
        • 2023년 7월 3주차
        • 2023년 7월 2주차
        • 2023년 상반기 회고
        • 나태하고 욕심많은 인간은 어떻게 살아야 하나
        • 책 <어떻게 살아야 하는가>
        • 책 <당신은 결국 무엇이든 해내는 사람>
        • 복잡계를 살아가는 단순한 사람
        • 책 <모든것이 되는법>
        • 글로 신뢰를 얻었던 경험들
        • 기획은 나를 찾아가는 과정
        • 나는 왜 살아가는가
        • 장항준 감독으로부터 배우는 "삶을 대하는 자세"
        • 개발자가 말하는 감정에도 분석이 필요한 이유
      • 2022년 회고
        • problem map 작성하기
        • 삶에서 내가 해결하고 싶은 문제 (2)
        • 삶에서 내가 해결하고 싶은 문제 (1)
        • <삶의 문제> 지도 다시 꺼내보기
        • 지도 위의 29살
        • 매번 시간계획을 망치는 MBTI 'P형 인간'을 위한 5단계 인생관리법
        • 당신은 왜 프로그래밍을 공부하는가?
        • 아무 것도 아닌 내가 글을 쓰는 이유
        • 책 <여행의 이유>
        • 책 <붕대감기>
      • 2021년 회고
    • Career
      • [미리캔버스] AI 제품 PM
        • 선택과 집중
        • 어쩌면 내가 틀릴 수도 있다는 생각
        • 뾰족한 사람들과의 협업
        • AI기능 PPT로 온보딩
        • AI 제품에서 가장 중요한 것
      • [미리캔버스] 앱 PM
      • [미리캔버스] 소상공인 제품 PM
      • [미리캔버스] 2.0 PM
      • [홀로스탠딩] 백엔드 개발
      • [청년5.5] 안드로이드 개발
      • [가축대출사업] NGO Project PM
    • Insight
    • Interview
    • Public Writing
  • SIDE PROJECT
    • [Youtube] 메이킹필름
      • [Product] 청춘집 프로젝트
        • (v24.11) 청춘집 JTBD
          • (구) 청춘집 실행계획
          • (구) 플레이리스트 기획
            • 데이식스 전곡 타임라인
            • 챕터 구성
        • (v25.01) 청춘집 JTBD
          • 아이돌 굿즈 시장 조사 (공식)
          • 아이돌 굿즈 시장 조사 (비공식)
        • 제작 준비
          • 레퍼런스 - 오프라인 시집
          • a5 책 만들기
    • [Youtube] 마포구타자기
      • [mptw] JTBD
        • IKIGAI
      • [mptw] 채널 설정
        • 채널 이름 후보군
      • 시리즈 [읽는음악]
        • [읽는음악] 백로그
          • 노래 가사 콘텐츠 레퍼런스
        • ep1. 파노라마 - 이찬혁
          • 이찬혁 <ERROR>
        • ep2. 마지막 인사 (feat. 청하) - 이찬혁
        • ep3. 나의 바다에게 - 도영
        • ep4. Dattom - 백예린
        • ep5. REBEL HEART - IVE
        • ep6. Either way - IVE
        • ep7. 너와의 모든 지금 - 재쓰비(JAESSBEE)
        • ep8. 예뻤어 - DAY6
        • 6주차. 데이식스 시리즈
    • [IT] 공적인사적모임 플랫폼
      • 1. 우리 조직의 얼굴을 만들자
      • 2. 내 생에 첫 기획서 만들기 (feat. QA Driven Development)
    • [Meet] 공적인사적모임
    • [Youtube] 이상한나라의 개발자할무니
    • [Study] Disquiet PM 스터디 쿨피스
    • [IT] 서울 빵 맛집 잘알 테스트
    • [Meet] 얼리버드 모닝클럽
      • 홍보를 곁들인 2주일 운영후기
  • 잡학사전
    • 와인 원데이 클래스
    • 소설쓰기
      • <책> 소설쓰기의 모든 것 1 - 플롯과 구조
      • 유튜브 - 소설 쓰는 법
      • 강의들
      • 작가가 되려면 어떻게 해야해
    • AI
      • 생성형 AI
    • ComfyUI
      • Stable Diffusion
      • ComfyUI 준비, 설치, 설정
      • Module 구조에 대해 이해하기
      • ComfyUI
      • Core Node
    • 작사
      • 작사가 되는 법
    • 유튜브
      • 유튜버 스토리님의 부캐 성장기
      • 주언규 유튜브 초보편 (클래스101)
      • 주언규 유튜브 왕초보 편
    • 경제
      • 연금저축펀드
    • ChatGPT
    • 크롤링
      • Automatio
      • Octoparse
    • 노코드
      • 북마크 & 노코드 서비스 목록
  • PRODUCT&BUSINESS
    • Service Planning/Analysis
      • 브런치시리즈 <개발보단 고객개발>
      • baemin mart
        • 1. 시작
        • 2. 우아한형제들 & 배민상회
        • 3-1. [인터뷰] 포항에서 치킨집을 운영하시는 최사장님
        • 3-2. [인터뷰] 부산에서 족발 프렌차이즈를 운영하시는 이사장님
        • 4. <아프니까 사장이다> 커뮤니티 데이터 분석
        • 5. 문제정의 & 개선 가설
        • 6. 결론 - 역기획서
      • careerly
      • meetme
      • 배달의 민족 역기획 사례
      • 당근마켓 역기획 사례
      • 도그냥 님이 말하는 진짜 역기획
      • 도그냥의 역기획 스터디법
      • 책 <현업 기획자 도그냥의 서비스 기획 스쿨>
      • 기획서 작성하기
    • Business/Growth
      • Unsexy Business 뉴스레터에서 얻는 인사이트
      • 책 <원씽>
      • 책 <아프리카 스타트업>
      • 책 <유난한 도전>
      • 책 <함께자라기>
      • 책 <나는 돈 없어도 사업을 한다>
      • 책 <나는 장사의 신 은현장이다>
      • 책 <왜 사업하는가>
      • 책 <왜 일하는가>
      • 이제는 피칭도 유튜브로
      • 세컨드 브레인이 필요한 이유
      • 책 <타이탄의 도구들>
      • 책 <역행자>
        • <역행자> 역행자의 7단계 모델 복습
        • <역행자> 운명을 거스르는 역행자의 7단계 모델
      • 책 <월급쟁이로 시작한 38살 그녀는 어떻게 30억을 벌어 파이어족이 되었을까?>
      • 책 <파리에서 도시락을 파는 여자>
      • 책 <존리의 금융문맹탈출>
      • 책 <돈의 감각을 길러주는 경제 지식 첫걸음>
        • 금리
        • 환율
        • 주식
        • 채권
        • 부동산
        • 연금
        • 경제정책
        • 규제
        • 경제위기
    • Product-Market Fit
      • 브런치 북 <개발보단 고객 개발>
      • 책 <아이디어 불패의 법칙>
      • 고이장례연구소
      • 글쓰기로 PMF 검증하기
      • 연대 송도 캠퍼스의 40%가 사용한 서비스
      • 어웨이크코퍼레이션의 김민준 님
      • 드로우 마이 브랜드
      • 노코드로 PMF 찾는 방법
    • UI/UX
      • UX Writing Workshop
        • 4. 고객과의 관계형성 - 차별점 강화
        • 3. 비즈니스 임팩트를 만드는 글쓰기
        • 2. 후킹한 문장으로 고객 행동 이끌기
        • 1. 쉽고 정확한 문장으로 문제해결
        • What is UX Writing?
        • Reference
      • UX/UI 관련 유용한 사이트 모음
    • PM/PO
      • [책] 대체 뭐가 문제야
      • 오너십을 갖고 일하는 PM이 된다는 것
      • 책 <프로덕트 매니지먼트>
      • 책 <인스파이어드>
      • PM Wiki
      • 당신과 팀을 성장시킬 PM 직무가이드
      • PO 미신, 파랑새를 찾아서 - CPO 김용훈
      • 개발자가 생각하는 좋은 PM 나쁜 PM
      • 프로덕트 매니저는 뭐하는 사람인가
      • 토스 리더가 말하는 PO가 꼭 알아야할 개념 (2)
      • 토스 리더가 말하는 PO가 꼭 알아야할 개념 (1)
      • 책 <조직을 성공으로 이끄는 프로덕트 오너>
        • <프로덕트 오너> PO의 시간관리법
        • <프로덕트 오너> PO가 데이터 기반으로 일할 수 밖에 없는 이유
  • DATA
    • Database
      • 이 위키를 만드는데 참고한 자료들
      • 데이터 기반 의사결정
      • 데이터베이스의 종류
      • 트랜잭션과 무결성
      • 트랜잭션, 커밋, 롤백, 트랜잭션 전파
      • ERD, entity relationship diagram
      • 기본 3 - 관계, 키
      • 기본 2 - 필드, 레코드, 타입
      • 기본 1 - 엔티티, 릴레이션, 속성, 도메인
    • SQL
      • Sub Query
      • JOIN
      • 데이터 정렬셋과 유니코드
      • 자료형
      • DDL, DML
      • SELECT
      • SQL
    • MySQL
      • MSQL to MySQL Data Migration
      • MySQL Server 다운로드, 로그인
      • helpful commands
      • 문자열 자르기 SUBSTR(column, startIdx, length)
      • 특정 값을 ORDER BY 특정 값 우선 정렬 하기 (ORDER BY FIELD)
      • 이것이 MySQL이다
    • H2
      • ‼️h2 in-memory-db Table not found (this database is empty) 해결방법
  • Dev-General
    • Webmark
    • Open Source
      • 나의 첫 opensource contribution 경험기
    • Dev-Insight
      • Event
        • YOUTHCON 2022
        • INFCON 2022
      • 책 <누워서 읽는 알고리즘>
      • 책 <나는 LINE 개발자입니다>
      • 서비스에 대해 개발자가 가져야할 생각들
      • AI 시대에서 결국 살아남는 것
      • AI 시대에 개발자가 살아남는 방법
      • 주니어를 넘어서, 성장하는 개발자의 길 (인프런)
      • 아마추어와 프로의 차이
      • 개발자의 개발공부에 대하여
      • 서비스에 대해 개발자가 가져야할 생각들
      • 좋은 개발자와 인맥을 만든 노하우
      • 개발자 취업기/이직기 모음
        • 라인게임즈 백엔드 개발자 경선님
        • OKKY 미니세미나 <비전공 학원출신 SI개발자, 유명스타트업 들어간.ssul> 참석 후기
        • 비전공자에서 2억받는 아마존 엔지니어가 되기까지
        • IT 대기업 100% 합격하는 방법
  • 🏗️computer science
    • Algorithm & Data Structure
      • About this page
      • Test Review
        • Page 1
      • Big-O
        • 빅오표기법의 문제풀이
        • 피보나치 수열의 시간복잡도
      • Bit Operation
        • bit masking
      • Math
        • 합공식 / 누적합
        • 피보나치 수
        • 약수찾기
        • 소수찾기
          • 백준 1978 소수찾기
          • 백준4948 베르트랑 공준
          • 백준 8393 합
          • 백준 1929 소수구하기
        • 최대공약수 / 최소공배수
          • 백준 2824 최대공약수, BigInteger
          • 백준 2609 최대공약수, 최소공배수
        • 순열과 조합
          • 백준 15649 N과 M
        • 그 외 개념 정리
      • Recursion
        • N Queens problem
        • counting cells in a blob
        • recursion 응용 - 미로찾기
        • 순환 알고리즘의 설계
        • 순환적으로 사고하기
        • 백준 17478 재귀함수가 뭔가요
        • 백준 10870 피보나치수 5
      • Sort
        • java 에서의 정렬
        • radix sort
        • sorting in linear time
        • comparison sort 에서 최상의 시간복잡도
        • priority queue
        • heap sort
        • quick sort
        • merge sort
      • Array and List
        • 표준 라이브러리
      • Linked list
      • String
      • Stack
        • 백준 1874 스택수열
        • 백준 10828 스택 구현하기
      • Queue
        • 백준 10845 큐 구현하기
      • Heap
        • 백준 11298 절대값힙
        • 백준11279 최대힙
        • 백준1927 최소힙
      • Deque
      • Tree and Binary tree
        • Tries
        • Red-Black Tree
        • Binary Search Tree
      • Search
        • 완전 탐색
        • 이분탐색
      • Graph
        • 최단경로
        • MST 2 - prim 의 알고리즘
        • MST 1 - Kruskal 의 알고리즘
        • MST, minumum spanning tree
        • DAG, Directed Acyclic Graph
        • DFS, Depth First Search
        • BFS, Breadth First Search
      • Dynamic Programming
        • Knapsack problem
        • LCS, Longest Common Subsequence
        • matrix chain
        • 행렬 경로 문제
        • 백준 1003 피보나치 함수
        • 백준 9461 파도반 수열
        • 백준9251 LCS
      • Greedy
      • Implementation
      • LIS, Longest Increasing Subsequence
      • Two Pointer
      • Line Swipping
      • Fenwick tree
      • Backtracking
    • Computer Structure
      • 이 위키를 만드는데 참고한 자료들
      • 그래서 컴퓨터는 어떻게 동작하나요?
      • 컴퓨터의 구성
      • 컴퓨터의 역사
      • 컴퓨터 구성요소의 기능 및 이해
      • 중앙처리장치 - 마이크로 명령 - 입출력과 인터럽트
      • 중앙처리장치 - 기본 컴퓨터 프로그래밍
      • 중앙처리장치 - 프로그래밍 언어와 실행
      • 파이프라인과 벡터처리 - 데이터의 종속성 - 병렬처리와 파이프라인
      • 파이프라인과 벡터처리 - 파이프라인 구조 - 데이터/구조
      • 파이프라인과 백터처리 - 산술&명령어 파이프라인
      • 파이프라인과 벡터처리 - 파이프라인 CPU의 성능분석
      • 메모리 구조 - 메모리 시스템의 이해
      • 메모리 구조 - 효율적인 메모리 관리 정책
      • 메모리 구조 - 컴퓨터 성능 개선을 위한 메모리 관리
      • 입출력구조 - 시스템 BUS 구성 및 제어
      • 입출력 구조 - 입출력(I/O) 연결과 주소 지정
      • 입출력 구조 - 입출력 수행과 인터럽트
      • 병렬컴퓨터 구조와 성능분석 - 멀티 프로세서
      • 병렬 컴퓨터 구조와 성능 분석 - 시스템 성능 분석과 개선
    • This Is Coding Test 2021
      • 1. 출제 경향 & 파이썬 문법 부수기
      • 2. 그리디 알고리즘 & 구현
      • 3. BFS & DFS
      • 4. 정렬 알고리즘
      • 5. 이진탐색
      • 6. 다이나믹 프로그래밍
      • 7. 최단경로 알고리즘
      • 8. 기타 그래프 이론
      • 9. 코딩테스트에서 자주 출제되는 기타 알고리즘
      • 10. 개발형 코딩테스트
    • Operating System
      • 이 위키를 만드는데 참고한 자료들
      • 운영체제란, Introduction to Operating Systems
      • 컴퓨터 시스템의 구조, Structure of Computer System
      • 프로그램의 실행, Program Execution
      • 프로세스, Process
      • 쓰레드, Thread
      • 프로세스의 생성과 종료, Start and End of Process
      • 프로세스 시스템 콜과 프로세스간의 협력, System call and Interprocess Communication
      • CPU Scheduling
      • CPU Scheduling Algorithm
      • Process Synchronization Problem
      • Initial Attempts to Solve Process Synchronization Problem
      • semaphore 와 monitor 로 synchronization 해결하기
      • 데드락, Deadlock
      • 메모리 관리, Memory Management
      • Memory Allocation
      • Virtual Memory
      • Virtual Memory 2
      • File System
      • File Systems Implementation
      • Disk Management & Scheduling
    • Network
      • 이 위키를 만드는데 참고한 자료들
      • 대규모 트래픽으로 인한 서버 과부하 해결방법
      • 유선 LAN과 무선 LAN
      • 네트워크를 이루는 장치 (L1, L2 .. L7)
      • REST API
      • HTTP 매서드
      • HTTP 상태코드
      • 직렬화와 역직렬화
      • 로그인 구현방식 2. 토큰 기반 인증방식
      • 로그인 구현방식 1. 세션 기반 인증방식
      • 웹 브라우저의 캐시 - 공통점과 차이점
      • 웹 브라우저의 캐시 - 쿠키
      • HTTP header
      • 웹 브라우저의 캐시 - 세션 스토리지
      • 웹 브라우저의 캐시 - 로컬스토리지
      • browser rendering
      • HTTPS 와 TLS - TLS 핸드쉐이크
      • HTTPS 와 TLS - 암호화
      • HTTP History
      • www.naver.com 을 주소창에 입력하고 화면에 나타나기까지의 과정
      • IP 주소 - 공인 IP와 사설 IP
      • IP 주소 - Classless,Subnet Mask, Subnetting
      • IP 주소 - Classful IP Addressing
      • IP 주소 - IPv4, IPv6
      • IP 주소 - 이진수 이해하기
      • IP 주소, MAC 주소, ARP, RARP
      • 라우팅
      • TCP 4way handshake and TIME_WAIT
      • TCP 3way handshake
      • TCP/IP - internet layer
      • TCP/IP - Transport Layer
      • TCP/IP - Application Layer
      • TCP/IP - MTU, MSS, PMTUD
      • TCP/IP 4계층, OSI 7 layer
      • 네트워크의 분류 - LAN, MAN, WAN
      • 네트워크 토폴로지와 병목현상
      • 네트워크의 기초 3
      • 네트워크의 기초 2
      • 네트워크의 기초
    • Linux
      • reference
      • sudo apt-get install / uninstall
      • vim
      • linux basic command
    • Design Pattern
      • 이 위키를 만드는데 참고한 자료들
      • static 을 자주 사용하게 되었을 때의 단점
      • 자바스크립트의 class와 static
      • 프로그래밍 컨텍스트
      • 의존성 주입 vs. 전략패턴
      • flux pattern
      • Spring MVC 패턴 적용 사례
      • MVC, MVP, MVVM pattern
      • 프록시 패턴
      • 옵저버 패턴
      • 전략패턴
      • 의존성 주입과 의존 관계 역전 원칙
      • 이터레이션 패턴
      • 추상 팩토리 매소드 패턴
      • 팩토리 메소드 패턴
      • 싱글톤 패턴
      • 디자인 패턴, 라이브러리와 프레임워크의 차이
    • Programming Basic (Go)
      • 이 위키를 만드는데 참고한 자료들
      • 트랜지스터, Trangister
      • 논리소자, Logic Element
      • 튜링과 폰 노이만, Turing and Von Neumann
      • 컴퓨터의 원리, Computer Principle
      • 프로그래밍 언어, Programming Language
      • 컴파일러와 동적언어, Compiler and dynamic language
      • golang
      • hello, world
      • variable
      • variable 2
    • Base Knowledge
      • 이 위키를 만드는데 참고한 자료들
      • 신기술 도입시 고민해야할 점(feat. react.js vs. vue.js)
      • 정적 타입 시스템의 필요성
      • 도커, 컨테이너
      • 클라우드, Saas, IaaS, PaaS
      • SSO
      • RBAC
      • OAuth2.0
      • REST API 사용을 위한 인증 방법 4가지
      • API
      • Data Format - XML
      • Data Format - JSON
  • ☕Java/Spring
    • Java
      • Java Code Convention
      • Java 버전별 특징 (v1-v19)
      • java.lang.Math
      • List 4가지의 초기화 방법
      • HashMap 4가지의 정렬 방법
      • 어노테이션 프로세서 정리하기
      • Annotation Processor 로 없는 소스코드 생성하기
      • lombok 은 어떻게 동작하는 것일까?
      • 다이내믹 프록시 정리하기
      • 클래스의 프록시
      • 다이내믹 프록시
      • 프록시 패턴은 무엇인가
      • Spring Data JPA 는 어떻게 동작할까?
      • reflection api 정리
      • reflection api 이용하여 spring ioc container 만들기
      • reflection api
      • spring dependency injection 은 어떻게 동작할까
      • 바이트 코드 조작하기
      • java bytecode 를 조작해 테스트 코드 커버리지 확인하기 (feat.jacoco)
      • Class Loader
      • JVM 의 구조
      • java, jvm, jdk and jre
      • synchronized
      • java string.split(".") 오류
    • Java 8
      • 이 위키를 만드는데 참고한 자료들
      • Metaspace
      • Parallel 정렬
      • Annotation
      • CompletableFuture
      • Date and Time
      • Optional
      • Stream
      • interface의 default 메소드와 static 메소드
      • 인터페이스의 변화
      • 함수형 인터페이스
      • java 8 소개
    • Spring Framework
      • Spring 3.0 준비하기
      • 특정 매소드만 transaction 처리하기
      • 스프링 프로젝트 시작하기
      • 스프링이란 무엇인가
      • 스프링 핵심 기술의 응용
      • AOP 2
      • AOP 1
      • 서비스 추상화 2
      • 서비스 추상화 1
      • 예외
      • 템플릿
      • 테스트
      • 오브젝트와 의존관계
      • 스프링이란
    • Spring Boot
      • [Gradle]UncheckedIOException
      • java19 + spring 3.0.5 + gradle 7.4.1 에서 프로젝트 gradle 설정하기
      • [리뷰] Gradle 멀티 프로젝트 관리
      • [리뷰] 멀티모듈 설계 이야기 with Spring, Gradle
    • JPA/QueryDSL
      • querydsl 을 쓰는 이유
      • JPA querydsl에서 json array 로 된 컬럼에 조건 적용하기
      • querydsl 에서 mysql order by field() 사용하기
  • 🏰Infrastructure
    • InfraWorkshop
      • 이 위키를 만드는데 참고한 자료들
      • aws로 안정적인 인프라 만들기 2
      • aws로 안정적인 인프라 만들기 1
      • 어플리케이션 진단하기
      • 서버 진단하기
      • 부하 테스트
      • 웹 성능 개선하기
      • 웹 성능 진단하기
      • <aws로 그럴듯한 인프라 만들기> 회고와 피드백
      • aws로 그럴듯한 인프라 만들기 3 - 배포스크립트
      • aws로 그럴듯한 인프라 만들기 2 - 배포하기
      • aws로 그럴듯한 인프라 만들기 1 - 네트워크 망 구성
      • docker container
      • connection check
      • network segmentation
      • cloud 서비스를 사용한다는 것
    • AWS
      • AWS IAM
      • AWS CodePipeline 으로 배포 자동화하기 (1)
      • AWS CodePipeline 으로 배포 자동화하기 (2)
  • 🪄Test
    • TDD
      • 이 위키를 만드는데 참고한 자료들
      • [2주차] 로또 과제 강의를 듣고나서
      • [1주차] 자동차 경주 과제 강의를 듣고나서
      • TDD, 리팩토링이란?
      • 가장 쉽게 TDD 시작하는 방법
      • 의식적인 연습과 학습 테스트
      • TDD 에 집착해야하는 이유
      • 공부하는 자세
    • AssertJ
      • 이 위키를 만드는데 참고한 자료들
    • JUnit
      • 이 위키를 만드는데 참고한 자료들
      • Junit 기본 개념
  • 😎OTHERS
    • Helpful Command
      • Mac 에서 특정 포트 검색, 종료
      • crontab
    • Llibrary
    • IntelliJ
      • 내가 좋아하는 커스텀 세팅
    • GIT
      • Github ID/Token 한번 입력 후 저장하기
      • Github Actions
      • github organization private repository push 안될 때 (not found issue)
      • commands
      • git commit convention
    • Logging
      • logback + webfilter 로 로그설정
      • ‼️log4j 보안 이슈
    • Postman
      • postman 의 header에서 언더바(_) 변수 인식 안되는 현상
Powered by GitBook
On this page

Was this helpful?

  1. PRODUCT&BUSINESS
  2. PM/PO

[책] 대체 뭐가 문제야

2025.05.06

PreviousPM/PONext오너십을 갖고 일하는 PM이 된다는 것

Last updated 12 hours ago

Was this helpful?

요즘 내가 가지고 있는 문제에 대입해보기

문제1. 정규 배포 프로세스를 따르지 않고 비정기배포를 하는 특정 개발팀 때문에 서비스가 불안정하다.

  • 내가 문제라고 생각한 것 : 특정 개발팀이 전사 규칙을 따르지 않고 비정기배포를 하는 것

  • 바라는 상태 : 안정적인 서비스 ← → 인식하는 것 : 비정기배포로 인해 불안정한 서비스

  • 서비스가 불안정한 진짜 원인이 “비정기배포“가 맞는가?

    • 진짜 문제는

      • 업무시간 외에 배포가 이루어져서 대응할 수 있는 인력이 없다는 것

      • 배포 후 QA와 PM에게 노티가 되지 않기 때문에 배포 시점과 내용을 인지하기 어렵고, 문제 발생시 대응도 어렵다는 것

    • 그럼 비정기배포를 해도 위의 진짜 문제만 해결되면 문제없는 것 아닌가?

  • 그렇다면, 진짜 문제에 대한 해결방법은?

    • 비정기배포를 하는 개발팀이 회사 규칙에 맞춰 정기배포를 하도록 하는 것이 아니라

    • 1) 코어타임에 배포를 진행한다. - QA와 PM이 사이드이펙트를 확인하고 이에 대응할 수 있는 인력을 확보하도록

    • 2) 배포 직후 QA와 PM에게 (자동이든 수동이든) 노티를 할 수 있도록 하는 것이 아닐까.

문제2. 스쿼드 내에서 일을 진행할 때, 담당자마다 요구사항을 다르게 이해하고 있어서 일정을 맞추지 못하거나 일을 다시 하는 경우가 있다.

  • 문제는 왜 발생했을까? 요구사항이 전달된 방식이 문제였던 것이 아닐까? 요구사항을 전달한 내가 문제지 않았을까?

    • 각자 다른 출근시간으로 인해 PM은 우선 슬랙으로 요구사항을 정리하여 공유를 했고 이에 대해 구두로 각 담당자들과 짧은 시간이라도 구두로 서로 얼굴을 마주보며 이야기를 나누는 시간을 갖지 않았다.

    • 피엠 리드와 스쿼드 리드가 각 스쿼드원들에게 다이렉트로 요구사항을 전달했고 종종 세부 내용에 차이가 있었다.

      • 스쿼드 리드(=나)는 이를 이후에라도 바로잡지 않았다.

    • “문제의 근원은 대부분 당신 안에 있다.“

      • PM은 요구사항과 정보를 전달했다고 임무를 완수한 것이 아니다.

      • 팀원들이 이를 제대로 이해하고 인지하고 있는지 필요하다면 개별적으로라도 계속 체크하고 정렬해야한다.

  • 그렇다면 문제에 대한 해결방법은 슬랙을 읽고 이모지를 단다, 출근시간을 맞춘다- 등의 쓸데없는 방법들이 아니라

    • 이슈 진행 전에 간단하게 각 담당자들이 모여서 라운지에서라도 함께 눈을 마주보며 요구사항을 정리하고 같은 이해도를 가질 수 있도록 정렬하는 것이 아니었을까.

문제3. AI생성 고객들은 어떤 상황에 어떤 프리셋을 이용하면 어느 정도의 퀄리티를 얻을 수 있음을 알기 어렵다.

  • 왜 고객들은 이를 알기 어렵다고 하는 걸까?

    • 1. 프리셋 개수가 너무 많아서

    • 2. 프리셋 이름, 썸네일, 예시 이미지로는 정보가 충분하지 않아서

    • 3. 프롬프트를 어떻게 써야할지 몰라서

    • 4. 어떤 경우에 이 프리셋을 이용할 수 있을지 가늠하기 어려워서 (실제 사용 케이스를 상상하기 어려워서)

  • …

가지고 갈 몇 개의 문장들

  • 문제의 해결책보다는 문제를 제대로 정의하는데 시간을 쓰자.

  • 문제란 바라는 것과 인식하는 것 간의 차이다.

  • 잘못될 수 있는 경우를 적어도 세 가지 이상 생각해 내지 못한다면 당신은 문제를 이해하지 못한 것이다.

  • 만약 그것이 그들의 문제라면 그들의 문제가 되도록 하라

  • 잠시라도 좋으니 변화를 위해 당신 자신에게 책임을 물어라

  • 문제의 근원은 대부분 당신 안에 있다.

  • 최종 분석에 다르면 정말로 자신의 문제를 풀고 싶은 사람은 그렇게 많지 않다.

서문

서문 내용이 흥미로웠다. “아무도 서문을 읽지 않는다.“는 점이 문제로 정의되었고 이에 대한 해결책에 대해 적혀있었는데, 재미있었다.

엘리베이터의 속도가 느린 문제-에 대한 해결

  1. 누구의 문제인가?

    1. 엘리베이터 사용자들

  2. 무엇이 문제인가?

    1. 풋내기 문제 해결사들은 해결해야 할 문제를 정의하는 데 시간을 보내기보다는 거의 대부분 성급하게 해결안을 찾아내는 데에 매달린다.

    2. 남의 문제를 해결해주는 문제 해결사가 되고자 할 때 .. 최선의 방법은 문제를 단수에서 복수로 보는 사고의 전환을 시도하는 것이다. 문제 해결사가 아니라 문제들 해결사로 여러분 자신을 변화시키라는 것이다.

조금 기대하고 있던 책이었는데 너무 고전적인 이야기가 나와서 사실 살짝 실망스러웠다.

문제가 무엇인가

  • 문제란 바라는 것과 인식하는 것 간의 차이다.

콘생스쿼드가 가진 문제는 무엇인가

  • 활성사용자 중 30%의 사람들이 AI도구를 쓰길 바라지만, 현실은 18%정도인 것이 문제이다.

  • 다른 곳에서 제공하는 최소한의 수준으로 AI기능을 제공하고 있지 못하다.

  • 문제가 해결된 뒤에라도, 정확한 정의를 내력다고 결코 확신하지는 말라.

  • 성급하게 결론에 도달하지 말라. 그러나 처음 느낌을 무시해서도 안 된다.

  • 정확히 정의 내렸다고 결코 확신하지 말라. 그러나 그것을 얻기 위한 노력은 계속 해야한다.

정말로 무엇이 문제인가

  • 컴퓨터 프린트 용지에 8인치 간격으로 표식을 새겨 넣거나 표시할 수 있는 도구를 개발한 내용

    • 한 문제에 대한 해결책은 다른 문제의 근원이 될 수 있다.

    • “문제대치“

  • 어떤 문제들에 접근할 때 가장 어려운 부분은 일단 문제의 존재를 인식하는 것이다.

  • 문제를 이해할 때, 잘못될 수 있는 경우를 적어도 세 가지 이상 생각해 내지 못한다면 당신은 문제를 이해하지 못한 것이다.

  • 면도를 하지 않는다 → 면도날의 날카로움 때문에 타인이 다치는 사례 → 구급상자의 홈에 다쓴 면도날을 넣도록 해결 → 낱개 포장지에 다쓴 면도날을 넣도록 유도

  • 대부분의 부적합은 일단 인식되기만 하면 쉽게 해결된다.

  • 해결책에 대해 외국인, 장님, 어린이를 통해 검증하라. 혹은 스스로가 외국인, 장님, 어린이가 되어보자.

    • 매일 사용하는 물건들을 외국인 관점에서 보는 연습을 해본다.

  • 각각의 새로운 관점은 새로운 부적합을 야기한다.

    • 그래도 해결안을 실행하기 전에 이런 관점들을 찾아보는 것이 나중에 그것이 문제가 된 후 깨닫는 것보다 낫다.

  • 내가 무엇을 해결하려고 하는지 명확하게 인지해야한다.

  • 헨리 8세가 왜 자기 아내들을 죽였는지에 대한 여러분의 의견을 기술하고, 살해할 때 어떤 방법들을 사용했는지 설명하라.

    • → 헨리 8세가 왜 자기 아내들을 죽였는지, 그리고 살해할 때 어떤 방법들을 사용했는지에 대해 강의에서 내가 어떻게 이야기했는가?

누구의 문제인가

  • 흡연자 1명과 비흡연자 10명, 그리고 유능한 교수로 구성된 문제해결에 대한 강의 시간

    • 해결 : 교수님이 늦은 시간을 활용하여 학생들끼리 토론하여 우스꽝스러운 해결책들을 도출. 이를 흡연자에게 받아들일 수 있는지 제안

      • 아무도 흡연자를 공격하지 않았고, 그도 자신을 방어하지 않는 평화로운 분위기에서 이 제안을 수용하게 됨

    • 그들 스스로 문제를 완벽하게 풀 수 있을 때에는 그들의 문제 해결에 끼어들지 않는다.

    • 만약 그것이 그들의 문제라면 그들의 문제가 되도록 하라

  • 주차장이 부족한 캠퍼스

    • 어떤 사람이 문제에 대해서 무언가를 할 수 있는 위치에 잇으나, 문제를 느끼지 못할 때에는 그가 행동할 수 있도록 무언가 조치를 취한다.

    • 나의 문제라는 관점은 우리 문제라는 관점과 결코 상반된 것이 아니다.

    • 교수들이 주차 문제를 내문제라는 관점으로 보았을 때, 문제는 충분한 주차공간이 없다 → 나의 문제로 전환되었다.

    • 일부 교수는 먼 거리를 걸어다니는 것을 몸에 좋은, 일종의 운동이라는 시각으로 바라보기로 했다.

    • 잠시라도 좋으니 변화를 위해 당신 자신에게 책임을 물어라

  • 터널 끝에서 전조등 끄기, Are Your Lights On?

    • 문제 : 터널이 어두워서 터널 입구에는 “전조등을 켜시오“ 안내판을 통해 잘 켰는데, 사람들이 터널 끝에서 이를 다시 끄지 않아서 자동차 베터리가 방전되고, 경찰들을 불러 이를 해결하게 되고, 관광객들은 시간을 낭비하고 불만을 호소하게 되었다.

    • 누구의 문제인가 : 터널 설계자 or 엔지니어의 문제 → 터널 이용객들의 문제

      • 운전자들은 문제를 풀려는 강한 동기가 있다고 가정.

      • 운전면허를 딸 정도라면 완전한 멍청이는 아니라고 가정.

    • 해결방법 후보들

      • 1. 전조등을 끄세요-라는 안내판을 놓는다. → 밤에도 등을 꺼버리게 된다.

      • 2. 어차피 벌어진 일이니 상황을 무시한다.

      • 3. 전망대에 베터리 교환소를 설치한다. → 유지비, 운영비

      • 4. 개인사업자에게 베터리 충전소 운영권을 준다. → 전망대가 상업화 될 것이다.

      • 5. 터널 끝에 좀 더 명확한 설명이 담긴 표지판을 설치한다.

        • 낮인데 전조등이 켜져 있으면 전조등을 끄시오.

        • 밤인데 전조등이 꺼져 잇으면 전조등을 켜시오.

        • 낮이고 전조등이 꺼져있으면 그냥 놔두시오.

        • 밤인데 전조등이 켜져있으면 그냥 놔두시오.

        • → 읽느라 사고가 더 나겠다…. → 장례식 많아지는 이슈…

    • 해결책 : “전조등이 켜 있습니까?“라는 질문형 안내문구 한줄만 표시

      • 만약 사람들이 전조등을 켜고 있다면, 간결한 경고문이 복잡한 안내 문구보다 훨씬 효과가 좋을 것이다.

문제는 어디에서 비롯되는가

  • 문제 : 폴란드 할머니를 방문하려는 손녀가 제출한 입국 서류 중 1개가 누락되어 입국이 저지당했다.

  • 문제의 원인은 무엇인가

    • 1. 직원이 서류를 분실했다.

    • 2. 그녀가 깜빡하고 가져오지 않았다.

    • 3. 그녀를 저지한 공무원이 무능력하다.

    • 4. 그 공무원은 다른 목적을 가지고 그녀를 입국하지 못하도록 하고 있다.

    • 5. 그 공무원은 그냥 상사의 말을 따랐을 뿐이다. 상사로부터의 지시이다.

  • 만약 문제를 “폴란드의 관료주의“ 라고 정의해보자.

    • 그 공무원은 왜 무례하게 그녀를 대하는가?

    • 어쩌면 그 공무원을 대하는 손녀의 태도가 무례했던 것은 아닐까. (“내가 문제의 근원일지도?“)

    • 공무원에게 예의 바르게, 인간성과 권능에 대해 존경심을 가지고 대할 때, 그들도 같은 태도로 사람을 대한다.

  • 문제의 근원은 대부분 당신 안에 있다.

  • 문제를 해결하기 전에 떠올려보자.

    • 누가 이 문제를 만들었는가? 그의 출제 의도는 무엇인가?

정말로 그것을 해결하고 싶은가 (or 해결할 가치가 있는가)

  • 학교에서 제대로 된 문제 해결사들을 배출하지 못하는 이유는 아마도 학생들에게 무엇이 문제인지 찾을 수 있는 기회를 주지 않기 때문일 것이다. 학교에서는 선생님들이 문제라고 말하는 것이 그냥 문제인 것이다.

  • “눈 가리고 무작정 두 발로 뛰어넘기“

  • 해결책의 문제화

    • 이 컴퓨터쟁이들은 컴퓨터에서 요구하는 방식에 자신들의 문제를 맞추기 위해 끊임없이 노력한다.

  • 표면적 문제 : 어중간 장난감 회사가 거래하는 도매상들에게 나오는 주문을 어떻게 각 공장에 적절히 할당해서 전체 비용(생산과 운영)을 최소화할 수 있는가?

    • 진짜 문제 : 비용을 최소화하는 것이 아니라 사장님과 회장님의 기쁘게 해드리는 것

    • 겉으로 어떻게 드러나든, 사람들은 자신이 필요로 하는 것을 갖기 전까지는 자신들이 뭘 원하는지 거의 알지 못한다.

  • 정확한 세금계산을 하는 프로그래밍 문제

  • 비용 지출 내역에 대한 암호 메시지 해독 문제 → 여기에 시간을 쏟을 가치가 있는가

  • 최종 분석에 다르면 정말로 자신의 문제를 풀고 싶은 사람은 그렇게 많지 않다.

  • 많은 문제가 일찍 해결되어야 하지만, 여러분에게 해결을 서둘도록 종용하는 사람이 있다면 주의할 필요가 있다. 성급하게 해서 잘못된 결과를 얻는 것보다는 차라리 의사결정이 지연되는 것이 낫다.

  • 물고기는 물을 보지 못한다.

    • 사람들의 습관화 경향 - 반복되는 자극에 대해서 반응이 점차로 줄어드는 현상

🤔
💡