chore(wiki): Topics/Thinking 신설 (Reasoning ADR 3건) + 회의록 a/b/e wiki화 + YouTube 1건
- 10_Wiki/Topics/Thinking/ — ASTRA 추론·메모리·검색 강화 논의 3개 ADR (제2뇌 추론 단계, 기억 관리 시스템화, 지식 발굴 의미 연결성) - 10_Wiki/Topics_meeting/ — 회의록 a (롯데월드 이머시브) / b (스포티앤리치 개선) / e (Net 이슈대응) - 00_Raw/_youtube/ — "AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀" 분석 + transcript - 00_Raw/ — 회의록 e 원본 - chronicle 자동 갱신 (architecture, scan-cache, timeline)
This commit is contained in:
@@ -0,0 +1,33 @@
|
||||
[위키] 롯데월드 신규 어트랙션 이머시브 커머스 제안 검토
|
||||
|
||||
📋 개요
|
||||
|
||||
- 날짜: 2026년 05월 08일
|
||||
- 주제: 3D 파노라마 기반 콘텐츠 기획 및 개발 구현 방안 논의
|
||||
- 핵심 키워드: #이머시브_커머스 #모바일_First #유니티_웹포팅
|
||||
|
||||
🚀 핵심 요약 (P-Reinforce Insight)
|
||||
|
||||
본 회의는 단순한 기능 구현을 넘어, 사용자의 '경험'을 어떻게 비즈니스(예매)로 연결할 것인가에 대한 전략적 결정을 포함함. 3D 파노라마라는 고사양 콘텐츠를 웹 환경에서 얼마나 가볍고 안정적으로 구동하느냐가 프로젝트 성패의 핵심임.
|
||||
|
||||
🔍 주요 논의 및 추론
|
||||
|
||||
1. 콘텐츠 전략: 체험에서 전환으로
|
||||
|
||||
- 현황: 3D 탐험(70%)과 미니 게임(20%)의 결합 구조.
|
||||
- 추론: 단순 정보 전달형 페이지는 이탈률이 높을 것으로 예상됨. 따라서 '미션 수행 $\rightarrow$ 보상 $\rightarrow$ 예매 페이지 랜동'으로 이어지는 유기적 플로우 설계가 필수적임.
|
||||
|
||||
2. 기술적 제약과 대응
|
||||
|
||||
- 환경: 모바일 접속 비중(95%)이 압도적이므로, 저사양 기기에서도 끊김 없는 웹 렌더링 성능 확보가 최우선 과제임.
|
||||
- 리스크: 유니티 웹 포팅 시 발생하는 로딩 속도 및 메모리 점유율 이슈에 대한 사전 테스트 필요.
|
||||
|
||||
⚠️ 리스크 및 대응 방안
|
||||
|
||||
- 리소스 공급망 리스크: 롯데월드 측의 영상/이미지 리소스 제공 지연 시 개발 일정 차질 불가피 $\rightarrow$ 대응: 샘플 에셋을 활용한 선행 개발 진행.
|
||||
- 보안 및 유출: 신규 어트랙션 정보 사전 노출 우려 $\rightarrow$ 대응: 런칭 전까지 보안 가이드라인 준수.
|
||||
|
||||
✅ 액션 아이템
|
||||
|
||||
- [ ] 개발팀: 스포티 니치 성능 테스트 및 피드백 (즉시)
|
||||
- [ ] 제안팀: 롯데월드 측 상세 요구사항 확정 (차기 미팅)
|
||||
@@ -0,0 +1,33 @@
|
||||
[위키] 스포티앤리치 서비스 개선 및 롯데온 피드백 대응
|
||||
|
||||
📋 개요
|
||||
|
||||
- 날짜: 확인 불가 (피드백 대응 회의)
|
||||
- 주제: 롯데온 요구사항 반영 및 UI/UX 최적화
|
||||
- 핵심 키워드: #UI_개선 #iOS_최적화 #데이터_정합성
|
||||
|
||||
🚀 핵심 요약 (P-Reinforce Insight)
|
||||
|
||||
기존 서비스의 안정성을 유지하면서, 외부 플랫폼(롯데온)의 요구사항을 어떻게 기술적으로 수용할 것인가에 대한 논의임. 특히 사용자 경험(UX)의 파편화를 막기 위한 데이터 유지 전략이 중요함.
|
||||
|
||||
🔍 주요 논의 및 추론
|
||||
|
||||
1. UI/UX 최적화: 가시성 확보
|
||||
|
||||
- 현황: 가격 표기 방식 변경 및 버튼 위치 조정.
|
||||
- 추론: 구매하기 버튼을 상단으로 이동시키는 것은 텍스트 겹침 방지뿐만 아니라, 모바일 사용자의 '한 손 조작' 편의성을 극대화하려는 의도임.
|
||||
|
||||
2. 기술적 가이드라인: 성능 한계 명시
|
||||
|
||||
- 현황: 특정 iOS 기기에서의 속도 저하 이슈 대응.
|
||||
- 추론: 무조건적인 최적화는 개발 공수를 폭증시키므로, '최소 사양 가이드'를 통해 기술적 책임 범위를 명확히 설정하는 전략이 필요함.
|
||||
|
||||
⚠️ 리스크 및 대응 방안
|
||||
|
||||
- 데이터 휘발성: 뒤로가기 시 스타일링 숍 세팅값 초기화 문제 $\rightarrow$ 대응: 쿠키 또는 LocalStorage를 활용한 상태 유지 로직 검토.
|
||||
- 개발 부하: 360도 회전 등 고사양 기능 도입 시 비용 상승 $\rightarrow$ 대응: 현재는 AI 이미지 샷 기반의 가벼운 방식으로 대응 범위를 제한함.
|
||||
|
||||
✅ 액션 아이템
|
||||
|
||||
- [ ] 개발팀: 구매하기 버튼 위치 및 문구 수정 (차주 초)
|
||||
- [ ] 개발팀: 채널 코드 확보 및 QA 진행 (다음 주 중)
|
||||
@@ -0,0 +1,34 @@
|
||||
[위키] .Net 이슈 대응 및 운영 프로세스 점검
|
||||
|
||||
📋 개요
|
||||
|
||||
- 날짜: 2026년 05월 27일
|
||||
- 주제: 라이브 빌드 QA 현황 및 패치 노트 관리 체계 수립
|
||||
- 핵심 키워드: #라이브_QA #패치노트 #운영_프로세스
|
||||
|
||||
🚀 핵심 요약 (P-Reinforce Insight)
|
||||
|
||||
단순한 버그 수정을 넘어, 개발팀의 기술적 성과를 어떻게 '유저가 이해할 수 있는 언어'로 변환하여 전달할 것인가에 대한 운영 체계(Governance) 확립이 목적임.
|
||||
|
||||
🔍 주요 논의 및 추론
|
||||
|
||||
1. 라이브 업데이트 전략
|
||||
|
||||
- 현황: 일본 지역 로그인/칼리브레이션 오류 해결을 위한 코드 수정 중.
|
||||
- 추론: '오늘 QA 완료 $\rightarrow$ 내일 반영'이라는 타이트한 일정을 유지하기 위해서는, 개발팀의 검증 데이터가 즉시 기획팀으로 공유되는 파이프라인이 필수적임.
|
||||
|
||||
2. 운영 프로세스 정립: 정보의 재구성
|
||||
|
||||
- 현황: 패치 노트 작성 시 '개발자 초안 $\rightarrow$ 기획자 수정' 절차 도입.
|
||||
- 추론: 기술적인 용어(Technical terms)를 유저 친화적인 언어로 변환함으로써, 업데이트에 대한 사용자의 심리적 저항을 줄이고 서비스 신뢰도를 높일 수 있음.
|
||||
|
||||
⚠️ 리스크 및 대응 방안
|
||||
|
||||
- 보안 취약점: 서버 팀장의 비밀번호 관리 방식 등 보안 이슈 $\rightarrow$ 대응: 주기적인 정책 변경 및 AI 기반 해킹 대응 체계 고려.
|
||||
- 글로벌 이슈: 일본 법인 내 특정 오류 지속 발생 $\rightarrow$ 대응: 테스트 플라이트 등록을 통한 신속한 재검증.
|
||||
|
||||
✅ 액션 아이템
|
||||
|
||||
- [ ] 개발팀: 라이브 빌드 QA 완료 및 업데이트 요청 (오늘 중)
|
||||
- [ ] 김원일 이사: 홍 실장 대상 테스트 플라이트 지원 (즉시)
|
||||
- [ ] 성혜(기획): 운영 툴 관리 및 강제 업데이트 여부 판단 (상시)
|
||||
Reference in New Issue
Block a user