AI Native 시대 기획적인 부분에선 어떤 걸 얻어볼 수 있을까...

최근 코딩테스트에 에이전트를 껴서 볼 수 있다는 걸 보고 어떻게 코딩테스트를 진행해볼 수 있을까 싶어서 

진행 방식이 궁금하여 다른 사람들의 정보를 보고 좋은 인사이트라고 생각하여 까먹기 싫어 작성해본다. 

 

https://github.com/musinsatech/2026-musinsa-rookie/blob/main/PROBLEM.md

과제 요구사항을 동시에 깃허브에 공개하였다.

1. "기획팀 메모"가 왜 부족한지가 곧 좋은 PRD의 체크리스트

기획팀 메모에 나와있는 내용을 보면 성공 기준은 정성적 (서버가 다운되면 안 된다) 인데, 실제 요구사항 으로 번역 될 때 "정원 1명에 100명이 동시에 신청해도 정확히 1명만 성공해야 한다." 처럼 정량적/검증 가능한 형태로 바뀌게 된다. 

기획자가 요구사항을 작성할 때 "안정적으로", "빠르게" 같은 형용사 대신에 측정 가능한 성공 조건으로 바꿔서 쓰는 습관을 가져야함.

필요한 기능 목록에 나와있는 항목들은 이미지에 보는 대로 작성되어 있다. 하지만 요구사항 밑에를 찾아보자.

기획 요구사항 메모에는 인증/인가, 수강신청 정책, 추가 제약사항, 기타 비즈니스 규칙 및 예외 처리가 들어가 있지 않다.

사실 기획자 입장에서 반대로 생각해보면 이런 로그인, 권한 관리, 선수 과목, 학년별 제한 같은 부분들은 미리 정의해둬서 개발자가 임의로 결정하게 만들지 않는 상황을 만들어주는게 제일 중요한 거 같다. 

명시되지 않은 요구사항 같은 부분이 작성되어 있다는게 애초에 도메인 적인 부분에서도 이런 부분을 빼먹게 되는 상황이
실제 현업에서 일어난다는 뜻 아닐까? 

 

사실 수강신청 사이트 같은 곳에서 도메인 적인 지식이 없었다면 애초에 학점 분포 및 강의당 학점 범위나 복수전공 인원 허용 인원, 선수과목, 학년별 제한, 재수강 허용 여부 이런 세부적인 부분을 빼먹을 수 밖에 없는 상황이라고 생각했다. 

 

기획자에게 도메인 지식이 강조되는 이유를 더더욱 느낄 수 있는 부분인 거 같다. 

"화면은 프론트팀에서 따로 작업할 예정이니 서버 쪽만 부탁한다" 는 멘트와 "API 문서를 잘 만들어 주시면 프론트팀에서 연동하기 편하다"

스코프 경계를 명확하게 긋는 방식이다.  

기획서를 쓸 때 이렇게 담당 범위와 인터페이스 (API 문서로 연동)을 명확하게 해주면, 각 팀이 서로 영역을 침범당하지 않고 병렬로 잘 일할 수 있다!

사실 개발에 대한 지식이 있는 기획자가 이점을 가져갈 수 있는 부분인 거 같다. 스코프 경계를 명확하게 긋고 개발팀이 병렬적으로 잘 일할 수 있게 기획 요구사항 문서를 설계할 수 있다는 것.

근데 개인적으로 사실 개발자들에게 프론트팀에서 따로 작업할 거니까 API 문서를 잘 만들어주시면 프론트팀에서 연동하기 편하겠죠? 라는 멘트 너무 개발자를 무시하는 멘트아닌가 라는 생각을 했다.. 내가 개발하는 입장에서 저런 기획서 받으면 뭔가 엥? 싶을 거 같다 ㅜㅜ

 

동작 > 핵심 기능 > 사고의 깊이 3단계 순으로 비중을 매긴 구조이다 MoSCoW나 Value-vs-Effort 같은 우선순위 프레임워크인 거 같다.

리소스가 제한된 상황에서 무엇을 먼저 살리고 무엇을 문서로만 남겨도 되는지 구분하는 감각은 기획자에게도 굉장히 중요한 요소이다. 

 

그냥 기능 리스트를 나열한 것이 아니라, 시간이 부족하면 어떤 것을 포기해도 되는지, 뭘 절대 포기하면 안 되는지 확실하게 못박아뒀다.

서로 독립적인 관계가 아니라 의존적인 부분도 잘 확인해야 한다.

 

서버가 안 뜨면 (1단계) 핵심이 기능(2단계)이 잘 됐는지 확인하지 못하고 사고의 깊이(3단계) 부분까지 역시 확인할 수 없다.

 그래서 먼저 "작동하게 하라" 가 1단계에 올라가있는 것이다. 

 

단순히 중요한 것이 아니라, 무엇이 가능하게 하는지를 파악해서 순서를 매긴 것이다.

 

먼저 무엇을 위한 우선순위인지 목표/성공지표를 정의해야 한다.

기준이 없으면 "중요하다"는 말이 사람마다 달라진다.

그 다음 후보 작업들을 나열하고 각각의 임팩트(사용자/비즈니스에 미치는 영향)와 비용(개발 리소스, 리스크, 시간)을 추정해야 한다.

 

이걸 비교 가능한 형태로 만드는 게 RICE, MoSCoW, Kano, Value-vs-Effort 매트릭스 같은 프레임워크의 역할이고.

여기서 한 단계 더 나아가 의존관계 파악까지 해야한다. — A가 안 되면 B, C가 아무 의미 없어지는 관계를 찾아서, 그 A를 최우선 바닥선(baseline)으로 설정하는 것.

 

(위에 작성한 내용이 굉장히 중요한 거 같다)

 

예전에 개발자 지인이 PM이 우선순위를 잘 설정하지 못하는게 굉장히 소통에 힘들고 불편하다는 이야기를 해줬었는데 

우선순위를 정말 잘 확인할 줄 아는 기획자/PM이 참 힘들면서 중요하다고 생각하게 되는 부분이다. 

 

그리고 이 우선순위와 트레이드오프의 근거를 문서로 남기고 팀에 공유할 때, "왜 이건 뒤로 밀었는지"를 말로 설명 못 하면 그건 우선순위가 아니라 감인 것이다. 마지막으로 상황이 바뀌면(새 정보, 일정 변경) 재점검하고 조정하는 것도 포함된다.

 

개발을 해볼 때 어떻게 시작할지도 생각해보았다. 

주요 요구사항

주요 요구사항을 보면서 내가 어떤 기술을 선택했고 왜 그 기술을 채택했는지 확실하게 설명할 수 있어야 할 거 같다.