오늘 벌어진 일
1. 질문 vs. 기획을 배움
Problem: '이게 가능한 것인지'를 팀 내에서 가늠할 수 없어서 기능 튜터님께 먼저 질문을 하고, 2차 기능명세서를 작성했음.
Try: 튜터님 피드백에 따르면,
실무에서 '가능한지'의 여부는 회사의 역량, 리소스, 시간 등에 따라 매번 달라지므로 일단 기획해서 요청하면 됨.
= MVP 프로젝트의 경우 수정 내용을 질문할 게 아니라, 2차 기능명세서로 전달드리면 되는 것이었다.
로그를 심을 수 있지만 분석은 알아서 해야 하므로 로그는 안 심었음.
2. 1차 MVP를 받음
Problem1: 태깅 품질 최악임!!!!
Problem:
1) 키워드와 연관된 내용이 포함된 리뷰임에도, 태깅이 안 되어서(추정) 버튼 선택 시 노출이 안 되거나,
2) 키워드와 연관된 내용이 아닌데도, 태깅되어 버튼 선택 시 노출되어버림(e.g. 시간 의미하는 명사 "때"를 '청결' 속성으로 인식함)
Why? 1차 정의했던 배치 처리는 백엔드 관련 QA를 할 수 없어서, 실시간 처리로 처리 방식을 바꿨음;;
Solution: 기능명세서 상세히 수정함(seed 키워드 사전 포함, 사전 기반 태깅 후 AI 자체 맥락 판단하는 방식으로 변경)
Try: 금요일부터 느낀 문제임. 근본적으로 기능명세서를 처음부터 AI 활용해서 작성하고, AI에게 입력할 프롬프트까지 작성했었어야 함. 다음부터는 기능명세서처럼 예시를 많이 보지 않은 문서는 예시를 많이 찾아보고, AI 도움을 처음부터 받아서 초안 작성하자!
(아예 모를 땐 뇌피셜이 더 위험함)
Problem2: 리뷰 출력이 오래 걸림!!!! 리뷰 노출 전까지 로딩 스피너 10초 이상 돌아감
Problem: 구현된 MVP에서 필터링한 리뷰 출력이 오래 걸리는 문제가 발생!!!!
Why? 1차 정의했던 배치 처리는 백엔드 관련 QA를 할 수 없어서, 실시간 처리로 처리 방식을 바꿨음;;
Solution: 3차 기능명세서에서는 배치 처리로 롤백.
Try: 캠프에서는 구현 횟수가 2회로 적으므로, 더더 신중을 기했어야 함. 뒷단을 모르면 오히려 단어 하나에도 더 신중을 기하자.
(몰라서 마지막까지 상세히 안 읽어봤던 것 같음.)
Problem3: 키워드 검색 버튼 우측의 해당 리뷰 개수가 실제 노출되는 리뷰 개수와 안 맞음!!!!
Problem: 키워드 검색 버튼 우측의 해당 리뷰 개수 'n'개라면, 리뷰 영역의 실제 노출되는 리뷰 개수는 'n-1'개인 경우가 발생.
1st Why? 이 숙소의 경우 블라인드된 리뷰가 추가됨
2 nd Why? 기능명세서 블라인드 리뷰 내용을 예외 케이스에는 추가했으나, 동작 기준 및 결과에 작성하지 않아서 AI가 알아서 만들어준 것으로 추정.(정확하지는 않음.가장 유력 후보임)
Solution: 3차 기능명세서에서는 블라인드 리뷰 추가하지 않는다고 명시.
Try: 특히나 AI로 구현 시, 예외 케이스나 엣지 케이스 등 보이지 않는 경우를 MVP 구현 범위에 포함할지 여부를 기능명세서에 명시하자. QA도 마찬가지.
(홈 화면, 숙소 선택 화면, 숙소 상세페이지는 고려했는데, 예외 케이스와 엣지 케이스는 고려를 못함. 안 보여서 미처 생각 못했음.)
오늘 느낀 점
오늘 문제의 주요 원인은 기능명세서를 비교적 뇌피셜로 작성했기 때문이다..
팀원들이 기능명세서 작성 경험이 없었으므로 다같이 레퍼런스를 찾거나, AI 도움을 처음부터 받았어야 했음.
큰 배움이었다!
사랑스러운 사람들이 예의 있게 싸워서 정말 평화롭다! 감사하다!
------
메모
궁금증
1-2단계 구분 vs. 분기 처리 - 뭐가 적절한지
사전의 유사도 판단은 어떻게 하는지