[강동7기 전Z전능 AI PM] 코멘토 청년취업사관학교 DAY 11

DAY 08 | IT 프로덕트 관리의 이해 — 기능 정의부터 PRD까지

디자인 스프린트에서 솔루션의 방향을 검증했다면, 오늘은 실제 프로덕트를 만들기 위해 화면 뒤에서 벌어지는 일들을 논리적으로 명세화하는 법을 배웠다. 기능 정의부터 정책 수립, 예외처리, AC 작성, PRD까지 — PM의 실제 업무 루프를 처음으로 제대로 들여다본 하루였다.

기능, 정책, 규칙의 명확한 구분

가장 먼저 배운 기본기는 **기능(Feature), 정책(Policy), 규칙(Rule)**을 명확히 구분해서 기록하는 습관이다.

기능: 사용자가 할 수 있는 일 (주로 동사로 표현)
정책: 회사의 사업적 선택에 의해 결정되는 것. 상황에 따라 바뀔 수 있는 수치나 조건이며, 변경 시 고객에게 공지가 필요함
규칙: 항상 지켜야 하는 제약 조건. 깨지면 시스템 버그로 이어지며, 위반 시 오류가 발생해야 함

게임으로 비유하면 이렇다.

기능: 사용자가 플레이할 수 있는 행동 (예: 점프할 수 있다)
정책: 패치노트로 바뀔 수 있는 수치 (예: 검 공격력 10% 하향)
규칙: 절대로 깨질 수 없는 게임의 물리 법칙 (예: 벽은 통과할 수 없다)

예외처리: 감이 아니라 카테고리로 해결하기

좋은 PM은 사용자의 해피 패스(Happy Path)뿐 아니라, 예측 불가능한 예외 상황까지 통제할 수 있어야 한다. 예외를 점검할 때는 두 가지 극단적인 페르소나를 떠올리면 유용하다.

원시인: 악의는 없지만 예상 밖의 실수를 연발하는 사용자 (예: 결제 버튼 연타, 이메일 칸에 전화번호 입력)
해커: 의도적으로 시스템의 취약한 경계를 찌르는 사용자 (예: 음수 수량 주문, 만료된 링크 재사용)

감에 의존하지 않고 예외를 촘촘하게 걸러낼 수 있도록 예외처리의 6대 카테고리를 배웠다.

카테고리	정의	회원탈퇴 적용 예시
입력검증실패	입력한 값이 형식이나 조건에 맞지 않음	비밀번호 입력 오류
상태충돌	현재 상태에서 수행 불가 또는 동시 요청 충돌	진행 중인 주문이 있는데 탈퇴 시도
외부의존실패	연동된 외부 시스템의 실패	본인인증 문자 발송 실패
권한·인증	자격이 없는 부적절한 요청	세션 만료 상태에서 탈퇴 버튼 클릭
빈 상태·경계값	데이터가 0개이거나 최대치 혹은 경계선일 때	잔여 포인트가 0원이거나 한도 초과 상태
되돌리기	진행한 작업을 무르거나 복구하는 경로	탈퇴 직후 복구를 원하는 사용자 발생

또 흥미로웠던 건, 예외 상황도 시대의 변화를 따른다는 점이다. 3G 시대에는 ‘인터넷 연결 끊김’이 최우선 예외였다면, 지금은 외부 API 타임아웃이나 LLM 응답 지연·환각·토큰 한도가 1급 예외 상황으로 다뤄진다.

Acceptance Criteria: 판정 가능한 완료 기준

**인수기준(AC, Acceptance Criteria)**은 “이 기능이 제대로 작동했다”고 판정할 수 있는 조건을 명확하게 적은 것이다. 핵심은 하나다. 통과 혹은 실패를 명확히 판정할 수 있는가. “빠르게 로딩된다”가 아니라 “3초 내 첫 화면 렌더”처럼 수치화되고 구체적이어야 한다.

AC 작성의 두 가지 포맷

Given-When-Then (시나리오형): 특정 상황이 주어지고(Given), 사용자가 행동을 취했을 때(When), 시스템이 보여주는 결과(Then)를 기술하는 방식
체크리스트형: 기능에 적용해야 할 정책적 제약 조건들을 직관적으로 나열하는 방식

피해야 할 AC 실패 패턴 4가지

제목 반복: “사용자는 회원탈퇴를 할 수 있다”처럼 개발 대상을 그대로 반복하는 형태
구현 지정: 개발 스키마나 DB의 기술적 처리를 지시하는 형태
판정 불가능: “탈퇴 과정이 매끄럽게 진행된다”처럼 모호하고 정성적인 조건
부정 케이스 누락: 정상 흐름만 적고 예외·실패 상황에 대한 조건을 적지 않은 형태

결정과 근거를 남기는 버전관리와 문서화

PM에게 버전관리란 단순한 코드 관리가 아니라 무엇을, 왜, 누가, 언제 결정했는지에 대한 근거를 남기는 일이다. 이 맥락을 보존하는 대표적인 도구가 **ADR(Architecture Decision Record)**이다.

문서화의 3대 원칙

단일진실공급원(SSOT): 모든 사실은 단 한 곳의 원본만 존재하며, 다른 곳에서는 링크로만 참조
독자를 위한 문서: 미래의 나와 협업하는 팀원을 중심에 두고 명확하게 작성
살아있는 문서 vs 동결(Freeze): 배포 전까지 수정을 반복하다가, 배포 시점에 내용을 동결하고 이후 변경은 체인지로그로 관리

토스의 사내 지식 플랫폼 ‘토독(todoc)’ 사례를 통해, 논의와 결정을 시스템적으로 누적하고 AI가 문서 초안을 작성한 뒤 사람이 검증하는 구조를 분석해볼 수 있었다.

PRD 작성과 NFR

**PRD(Product Requirement Document)**는 기획 단계의 생각과 정책들을 하나로 조립하는 팀 전체의 정렬 도구다. “분량만 가득한 20페이지보다 명확한 2페이지가 훨씬 강력하다”는 원칙으로 작성된다.

PRD의 핵심 구조

배경/문제: 왜 지금 이 문제를 해결해야 하는가에 대한 데이터와 근거
목표 & 성공 지표: 출시 후 성공을 판정할 정량적 기준
업무 범위(Scope): 무엇을 만들고, 특히 무엇을 만들지 않을 것인지(Out-of-Scope) 를 명시해 스코프 크립을 방지
기능 + 정책 + 예외: 앞서 정리한 서비스 상세 스펙
Acceptance Criteria: 완료 판정을 내릴 구체적 인수기준
NFR(비기능 요구사항) / 결정로그: 성능, 가용성, 보안, 법·규제(예: 개인정보 30일 내 파기), 접근성, 호환성 등 시스템의 품질 기준

오늘의 한 줄

개발할 때는 예외 케이스나 빈값 처리를 몸으로 익혀왔는데, 그걸 문서로 정리하는 건 또 다른 일이었다. 아는 것과 쓸 수 있는 것 사이에 생각보다 큰 간격이 있다는 걸 오늘 느꼈다.

취업 부트캠프 청년취업사관학교 새싹 aipm dx교육 ai교육 실무프로젝트 실무경험 취업포트폴리오 포트폴리오 전z전능 코멘토 모비니티

🐻

Recent Notes

기록