today I learned
2025/2/5 TIL "갱신"
나는 서비스 기획자이다.
오늘 배웠던걸 공유하려고 한다.
사건의 발단은 이러하다.
프론트의 배너관리를 위한 어드민 페이지 기획을 하고 있는데, 프론트 엔드 개발자가 내 기획서를 보더니 한마디 했다.
기획서에는 "리스트영역 : 페이지 조회 시점 기준 리스트 갱신, 노출 기간 배너는 '비노출' 처리"이라고 적혀있었다.
대략적인 상황을 얘기하자면, 백엔드 리소스가 적어서 API 작업보다는, 최대한 프론트에서 할 수 있는 부분들은 프론트에서 처리하고 백엔드 리소스를 작게 쓰고 있는 상황이었다. 그리고 백엔드 분은 연차가 많은 시니어 개발자, 프런트 엔드는 3년 차 개발자였다. (그리고 백엔드 개발자 분은 재택 중..) 그리고 팀장님(벡엔드 개발자)이 PRD(요구사항 명세서) 보다 화면 기획을 먼저 하길 원해서, 화면 기획을 하고 디스크립션을 작성했다. (일반적으로 나는 PRD(요구사항 명세서)를 먼저 작업하고, 화면기획 후 디스크립션을 작성한다.)
FE : 예은 님, FE에서 이 배너 노출 리스트를 갱신하는 건 비효율적이에요. 왜냐하면, 이렇게 하려면 API 호출을 건마다 해야 해요. 아마 API 너무 호출 많이 해서 부하 걸릴 거예요. 예시로 기획서에는 10개가 있는데, 그러면 API를 10번 호출해야 해요.
나 (PM) : 아 저는 이 페이지 진입 할 때 노출 중인 상태 필터해서 리스트를 뿌린다고 생각하고 작성한 문장이에요.
FE : 그러면 백엔드에서 처리해줘야 하는데, 그렇게 해 주실지 잘 모르겠어요. 백엔드가 바빠서, 제가 해야 할 수도 있을 것 같아서 그렇게 말씀드린 거였어요.
나 (PM) : (백엔드에서 당연히 해준다고 생각하고 기획서에 그렇게 작성했는데...) 네. 그러면 벡엔드에서 처리해 주는 걸로 설득해 볼게요. (내가 이 부분까지 조율하고 관여하는 게 맞나?!) 그리고 다음부터는 FE, BE 명확히 구분해서 디스크립션 작성하겠습니다.
FE : 네 알겠습니다.
이렇게 일단락되긴 했는데, 처음에는 당연히 백엔드가 하는 거 아니야?라고 생각했다가, 아 이런 부분은 PRD 먼저 써서 정확하게 짚고 넘어가야 R&R 구분이 더 명확해질 거 같다는 생각을 했다. 그리고 오해의 소지 없게 기획서를 작성해야겠다고 생각했다.
내 의도는 데이터 안 건드리고, 페이지 갱신 (=페이지 로드)의 개념으로 "페이지 조회 시점 기준 리스트 갱신"이라고 썼다. 근데 디스크립션을 보고 FE는 자기가 처리해줘야 하는 부분으로 오해했다. 돌아보니, 오해의 소지가 다분한 문장이긴 했다. (다만 나도 할 말이 있는데.. 아니 근데 페이지 조회 시점으로만 리스트가 갱신되면 그게 맞겠냐고요..ㅠㅠ.. 당연히 백엔드에서 노출기간이 지난 배너는 비노출 상태로 바꿔주는 로직을 추가해야죠...)
그리고 다음부터는 "페이지가 로딩되며 리스트 노출"이라고 쓸 예정이다. (페이지 로딩 부분은 빼도 될 거 같은데..? 당연한 얘기를 괜히 한번 더 명시했나.. 하ㅏ하하....)
열심히 해야지!