2025/2/5 TIL "갱신"

today learned

나는 서비스 기획자이다.
오늘 배웠던걸 공유하려고 한다.
사건의 발단은 이러하다.

프론트의 배너관리를 위한 어드민 페이지 기획을 하고 있는데, 프론트 엔드 개발자가 내 기획서를 보더니 한 마디 했다.

기획서에는 "리스트영역 : 페이지 조회 시점 기준 리스 트 갱신, 노출 기간 배너는 '비노출' 처리" 이라고 적혀 있었다.

대략적인 상황을 얘기하자면, 백엔드 리소스가 적어서 API 작업 보다는, 최대한 프론트에서 할 수 있는 부분 들은 프론트에서 처리하고 백엔드 리소스를 작게 쓰고 있는 상황이였다. 그리고 백엔드 분은 연차가 많은 시 니어 개발자, 프론트 엔드는 3년차 개발자였다. (그리 고 백엔드 개발자 분은 재택중..) 그리고 팀장님(벡엔드 개발자)이 PRD(요구사항 명세서) 보다 화면 기획을 먼저 하길 원해서, 화면 기획을하고 디스크립션을 작성 했다. (일반적으로 나는 PRD(요구사항 명세서)를 먼저 작업하고, 화면기획 후 디스크립션을 작성한다.)

FE : 예은님, FE에서 이 배너 노출 리스트를 갱신하는 건 비효율적이에요. 왜냐하면, 이렇게 하려면 API 호출 을 건마다 해야해요. 아마 API 너무 호출 많이해서 부 하걸릴거에요. 예시로 기획서에는 10개가 있는데, 그 러면 AP를 10번 호출해야해요.

나 (PM) : 아 저는 이 페이지 진입 할 때 노출중인 상태 필터해서 리스트를 뿌린다고 생각하고 작성한 문장이에요.

FE : 그러면 백엔드에서 처리해줘야하는데, 그렇게 해 주실지 잘 모르겠어요. 백엔드가 바빠서, 제가 해야할 수도 있을 것 같아서 그렇게 말씀드린거였어요.

나 (PM) : (백엔드에서 당연히 해준다고 생각하고 기 획서에 그렇게 작성했는데....) 네. 그러면 벡엔드에서 처리해 주는걸로 설득해볼게요. (내가 이부분 까지 조 율하고 관여하는게 맞나?!) 그리고 다음 부터는 FE, BE
명확히 구분해서 디스크립션 작성하겠습니다.

FE: 네 알겠습니다.

이렇게 일단락 되긴 했는데, 처음에는 당연히 백엔드가 하는거아니야? 라고 생각했다가, 아 이런 부분은 PRD 먼저 써서 정확하게 짚고 넘어가야 R&R 구분이 더 명 확해 질거 같다는 생각을 했다. 그리고 오해의 소지 없 게 기획서를 작성해야겠다고 생각했다.

내 의도는 데이터 안건드리고, 페이지 갱신 (=페이지 로드)의 개념으로 "페이지 조회 시점 기준 리스트 갱신
" 이라고 썼다. 근데 디스크립션을 보고 FE는 자기가 처리해줘야하는 부분으로 오해했다. 돌아보니, 오해의 소지가 다분한 문장이긴 했다. (다만 나도 할말이 있는 데.. 아니 근데 페이지 조회 시점으로만 리스트가 갱신 되면 그게 맞겠냐구요..ㅠㅠ .. 당연히 백엔드에서 노출 기간이 지난 배너는 비노출 상태로 바꿔주는 로직을 추 가해야죠...)
그리고 다음 부터는 페이지가 로딩되며 리스트 노출" 이라고 쓸 예정이다. (페이지 로딩 부분은 빼도 될거같 은데...?당연한 얘기를 괜히 한번 더 명시했나.. 하하 하....)

열심히 해야겠다!