TIL 요약
- PM: 애자일 이론
- Figma: 오토레이아웃, 컨스트레인, 리사이징
Daily Reading
Who really owns the squad? (Spoiler...it’s not the product manager)
프로덕트의 주도권이 누구에게 있냐고 묻는다면 PM을 떠올리기 쉽다. 하지만 PM은 프로덕트 전략에 대한 주도권을 가지고 있을뿐이다. 엔지니어, 디자이너, 데이터 분석가 - 이들은 PM이 결정에 따라 일을 하는 것이 아니라 각자의 역할에 맡는 책임과 주도권을 가지고 있다.
-
엔지니어: How
- 문제에 대한 해결책을 어떻게 실현시킬 것인가에 대한 주체.
- PM은 개발자들이 가진 관성에 도전하고 더 나은 방향을 제시하는 역할
(해결하기 위한 문제 정의하고, 문제해결 방향을 검토, to push for scalable solutions)
**scalable solution : 확장가능한, 지속가능한, 변화에 유연한 솔루션
-
데이터 분석가 : Anchor to the decision
- 데이터에 의한 의사결정을 가능하게 하는 역할.
** Data Scientist 는 데이터 분석가와 다른 역할 수행. DS의 우선순위는 미래 예측 및 자동화 모델을 구축하는 것 -> under tech leadership DS의 R&R을 침범하지 않으면서 PM이 도움을 요청할 땐 어떻게 해야할까? -
디자이너 : Partner in Discovery
- 가장 먼저 문제점을 체감하는 사람들
- 그리고 솔루션을 적용하는 사람들
협업(collaboration)은 '다같이 일하는 것'이 아니다.
훌륭한 협업을 완성시키는 것은 파트너십 + Shared Vision + 공동의 우선수위.
- RACI matrix
Responsible: Design
Accountable: Product & Design
Consulted: Data & Engineering
Informed: Stakeholders & Leadership
구성원 모두가 오너십을 가지고 각자의 역할을 주도해야 한다.
디자이너는 문제 발견과 사용자 조사를 주도한다.
PM은 발견된 인사이트를 전략적 성과와 연결시키고,
데이터팀은 이러한 전략적 가설을 데이터로 검증한다.
개발자는 초기 단계부터 현실적인 기술적 현실성을 제시한다.
결국 PM은 주도권을 독점하는 것이 아니라 적재적소에 배분해야 한다.
프로덕트의 주도권이 누구에게 있는가에 대한 아티클을 읽다보니 어제 본 우아한 현제들 컨퍼런스 영상이 떠올랐다. 
결국 PM이 갖춰야할 리더십이라는 것은 'leading'보다는 오너십을 갖게 하는 것이라는 걸 깨달았다. 업무의 효율을 따진다면 문제에 대해 고민하고 분석하는 역할과 그것에 대한 해결책을 실행하는 사람의 역할이 분리 되는 것이 이득이다. 하지만 더욱 중요한 것은 함께 고민하고 준비하면서 '나의 일'로 만드는 과정이라는 걸 알 수 있었다. 공동의 목표, 도전과제를 공유하는 일 (Shared Vision)이 결국에는 구성원들이 오너십을 가져야 가능하겠구나 싶었다.
그래서 협업을 요청하는 과정도 설득이라는 생각이 들었다. 단순히 이거 필요하니까 언제까지 해주실 수 있나요? - 가 아니라, 왜 이 업무가 필요하고 왜 이런 접근을 시도했는지 데이터, 사용자, 비즈니스 측면에서 설득해야 좋은 협업이 이뤄질 수 있다는 걸 느꼈다.
입장을 바꿔서 생각해 보는 게 도움이 될 거 같다. 내가 개발자라면, 내가 디자이너라면, 이 상황이 납득이 갈까? 내가 필요한 상황이라고 느낄까? 내가 하는 일이 의미있다고 느낄까? 이런 점을 고려하면 구성원들에게 성공적으로 동기부여를 줄 수 있지 않을까.
PM 개론 Chapter. 2
PM의 실행과 전략 : 실행편
1. 이해관계자와의 협업 및 PM의 역할
PM은 단순히 기능을 전달하는 사람이 아니라, '맥락(Context)'을 전달하는 커뮤니케이션의 허브 역할을 수행해야 합니다.
주요 협업 대상
- UX 리서처: 사용자 경험 전반을 조사하고 인사이트를 발굴합니다.
- PM의 역할: 명확한 목표와 필요한 데이터를 전달하여 리서처가 유의미한 인사이트를 뽑아낼 수 있도록 서포트합니다.
- UX 라이터: 프로덕트 내의 모든 텍스트(Copy)를 담당하며 브랜드의 Tone & Manner 가이드라인을 구축합니다.
- PM의 역할: 라이팅에 필요한 배경과 맥락을 설명하여, 사용자 니즈와 비즈니스 목표(데이터)가 텍스트에 잘 반영되도록 합니다.
- CX 매니저: VOC(고객의 소리) 데이터를 기반으로 고객 경험을 총괄 관리합니다.
💡 핵심 포인트
PM은 "필요한 기능"이나 "업무안"만 던져주는 것이 아니라, 명확한 목표를 공유하고 맥락을 설명해야 합니다. 다양한 직무의 특성을 파악하는 것이 원활한 커뮤니케이션의 시작입니다.
2. IT 업무의 분류 및 프로젝트 방법론
IT 프로젝트는 크게 프로젝트성 업무와 운영 업무로 나뉩니다.
- 프로젝트 업무: 신규 기능 개발, 서비스 개선, 캠페인 등 목표 달성을 위한 단위 업무.
- 운영 업무: 시스템 유지보수, Day-to-day task 등 지속적인 관리 업무.
방법론: Waterfall vs Agile
- Waterfall: 단계별로 순차적으로 진행되는 방식.
- Agile: 짧은 주기를 반복하며 빠르게 실행하고 개선하는 방식.
cons장기적 계획 수립에 불리, 변경 및 수정사항에 대한 세심한 트래킹이 필요함
3. MVP
MVP(Minimum Viable Product): 시장에 빠르게 출시하여 고객 반응을 살피고, 이를 피드백 삼아 개선해 나가는 전략.
MVP 설정에서 가장 중요한 것은 '범위'와 '근거'입니다.
- MVP 정의하기: MVP의 기준은 주관적일 수 있으므로 시작 전 범위를 명확히 확정해야 합니다.
- 이때 반드시 데이터 기반의 객관적인 이유가 있어야 하며, 리소스를 고려한 우선순위 설정이 필수적입니다.
- 원페이저 작성: 디자이너와 개발자가 프로젝트에 빠르게 투입될 수 있도록 핵심 내용을 문서화합니다.
- 포함 내용: 배경, 개선 목표, 가설 및 검증 전략, 솔루션, KPI 및 측정 방법.
4. 실전 프레임워크: Scrum (+Kanban)
업무의 성격에 따라 적합한 관리 프레임워크를 선택하며, 주로 JIRA와 같은 툴을 활용합니다.
| 구분 | Scrum (스크럼) | Kanban (칸반) |
|---|---|---|
| 핵심 | 백로그 기반, 스프린트 단위 진행 | 지속적인 관리, 유연한 업무 흐름 |
| 특징 | 정해진 목표와 우선순위에 따라 짧은 사이클 반복 | 우선순위가 수시로 변하는 업무에 적합 |
| 장점 | 계획된 기간 내 집중도 높음 | 유연성이 높고 매일 루틴화된 업무에 유리 |
| 단점 | 기간 내 미계획 Task 대응력 낮음, 장기 계획 수립의 어려움 | 업무 트래킹이 까다로울 수 있음 |
질의응답
[2026.03.11 Wed PM 7:46 ・ 8Minutes 5seconds]
[ Key topics ]
- 스크럼 방식의 정의, 실제 실무에서의 사용되는 의미
- 스프린트를 업무 단계와 기간을 기준으로 나누는 방법
- 에자일 방식 업무 진행 시 우선순위 결정 방법
- 스크럼에 누가 참여하는가?
[ 스크럼 방식의 정의 ]
- 스크럼은 어떠한 백로그를 해결 과제로 설정했을 때 적용할 수 있는 프레임 워크
- 엄밀한 용어와 실제 실무에서 사용하는 용어 간에 간극이 있음
- 날마다 진행상황을 체크하고 피드백을 주고 받으며 '애자일 하게' 일하는 방식
[ 스프린트를 구분 짓는 기준 ]
- 프로젝트 스크럼을 진행할 때 스프린트를 기간을 기준으로 나누는지 업무 단계를 고려해서 나누는지 궁금함
- 에자일하게 일할 때 중요한 것은 짧은 주기로 소통하고 빠르게 진행 상황을 공유하는 것. 업무 단계보다는 정해진 기간에 맞춰 스프린트가 반복됨.
[ 여러 스프린트에 참여 중일 때 우선순위 설정]
FIGMA 2강
프레임과 그룹의 차이, 오토 레이아웃의 원리, 정렬 시스템
Constraint, Resizing, Position
1. 프레임
- UI 디자인 할 때 코드로 변환할 수 있는 구조.
- 프레임: 코드블록, 선택 Hierarchy 구조. → 감싸는 느낌.
- 그룹: 이미지 개체, 개발 사항 적용 X. i.e. 이미지를 만들 때 합치는 느낌.
2. 오토 레이아웃
- 컨테이너(프레임)의 내·외부 여백을 조정하는 layout 기능.
- 모든 코드 블록은 내부 개체 + 패딩으로 구성.
- i.e. UI의 크기 = 개체의 크기 + 패딩.
오토 레이아웃 생성 및 사용
- 개체를 내부 여백으로 감싸 컨테이너로 만듦.
- 개체 → 오토 레이아웃: 패딩 값을 가진 프레임 생성.
- 개체 → 프레임 선택 → 오토 레이아웃: 기존 프레임에 패딩 값 적용. 프레임이 오토 레이아웃이 됨.
- Tip: 오토 레이아웃 안에서 복제할 땐
Ctrl + D사용.
(Alt + 드래그는 프레임 밖으로 복제됨)
정렬 시스템
- (수직 정렬) 위 → 아래 방향으로 쌓임.
- 레이어상 가장 아래 = 가장 앞.
- i.e. 정렬 방향대로 앞, 뒤 순서 결정
3. Constraint
- 오토 레이아웃 안에 있는 자식 개체들이 움직이는 조건.
- 부모 컨테이너 translate → 자식 컨테이너 translate.
- 파란 점선 = Constraint pin 기준. (점선이 보이는 부분은 변하지 X)
- 정렬 → Constraint 기준으로 정렬에 맞게 변함.
4. Frame Resizing
- 오토 레이아웃 안에서 자식 개체들의 움직임 조정.
- Fixed: 고정값.
- Hug: 부모를 자식에 맞춤. i.e. 자식 변화 → 부모 변화.
- Fill: 자식을 부모에 맞춤. i.e. 부모 변화 → 자식 변화.
5. Position
- 개발에서 자주 사용되는 개념.
- Proto Type panel 에서 설정
- Static: 기본. 화면이랑 같이 움직임.
- Fixed: 고정. 화면이 움직여도 위치 변화 X (화면 전체 영역 기준).
- Absolute: 부모 컨테이너 기준 고정.
Absolute - Position panel (Auto layout 프레임 안에 있을 때만 활성화) - Sticky: Static + Fixed.
2주차 과제
- 3번
오토레이아웃 -> 하위 개체들의 크기, 패딩 일정하게
컨스트레인 -> 부모-자식 관계에 따라 인과적으로 반응
