Skip to content

Commit f612ec1

Browse files
CommitTheKermitCommitTheKermit
committed
docs: 3주차 주간 보고서 수정
1 parent aa8aef9 commit f612ec1

1 file changed

Lines changed: 146 additions & 178 deletions

File tree

‎report/week3.md‎

Lines changed: 146 additions & 178 deletions
Original file line numberDiff line numberDiff line change
@@ -1,178 +1,146 @@
1-
<h1>Week 3 보고서 - ellipsis</h1>
2-
<h2>이번 주 한 일 (계획 vs 실제)</h2>
3-
<p>(개발 진도가 계획대로 갔는지)</p>
4-
<p><strong>계획</strong></p>
5-
<ol>
6-
<li>질문지 작성</li>
7-
<li>결과 칼럼 카드 개선 및 데이터 구조 변경</li>
8-
<li>태그 구조 수정 + 버그 수정</li>
9-
<li>CODEX sdk Agent</li>
10-
<li>기능추가
11-
<ol>
12-
<li>타건음 영상</li>
13-
<li>스토어 링크</li>
14-
</ol>
15-
</li>
16-
<li>피드백 받기
17-
<ol>
18-
<li>구매하기 버튼</li>
19-
<li>매칭 결과 피드백(1~5점)</li>
20-
</ol>
21-
</li>
22-
<li>추천 정확도 올리기</li>
23-
</ol>
24-
<p><strong>실제</strong></p>
25-
<ol>
26-
<li>질문지 작성</li>
27-
<li>결과 칼럼 카드 개선 및 데이터 구조 변경</li>
28-
<li>태그 구조 수정 + 버그 수정
29-
<ol>
30-
<li>이전 : 태그를 우리가 만든 데이터베이스에서 가져오는 게 아니라 AI가 만든 태그 기반으로 태그가 정의됨</li>
31-
<li>현행 : 우리 데이터베이스에 있는 속성들 기준으로 변경</li>
32-
</ol>
33-
</li>
34-
<li>CODEX sdk Agent
35-
<ol>
36-
<li>CODEX sdk Agent 콜이 아니라, Open API LLM 콜로 바꿈</li>
37-
</ol>
38-
</li>
39-
<li>기능추가
40-
<ol>
41-
<li>타건음 영상 → 플레이스 홀더로 대체</li>
42-
<li>스토어 링크 → 플레이스 홀더로 대체</li>
43-
</ol>
44-
</li>
45-
<li>피드백 받기
46-
<ol>
47-
<li>구매하기 버튼
48-
<ol>
49-
<li>MOCK으로 구현, 토스트만 출력되게</li>
50-
</ol>
51-
</li>
52-
<li>매칭 결과 피드백(1~5점)
53-
<ol>
54-
<li>MOCK으로 구현, 슈퍼베이스 연결 안됨</li>
55-
</ol>
56-
</li>
57-
</ol>
58-
</li>
59-
<li>추천 정확도 올리기
60-
<ol>
61-
<li>우리 서비스에서 제시하는 태그 모아놓기</li>
62-
<li>자연어에서 태그 추출</li>
63-
<li>태그 기반 검색</li>
64-
<li>결과 보여주기</li>
65-
</ol>
66-
</li>
67-
</ol>
68-
<hr>
69-
<h2>A. 지난주 액션 결과</h2>
70-
<h3>2주차에 정한 1가지</h3>
71-
<ul>
72-
<li>무엇이었는가: 추천 결과의 품질 고도화</li>
73-
</ul>
74-
<h3>실행 상태</h3>
75-
<ul>
76-
<li>진행 중
77-
<ul>
78-
<li>이전 : 자연어 + 키보드 데이터베이스 → LLM 콜
79-
<ul>
80-
<li>추천이 부정확했음, 사무용인데 시끄러운 키보드를 추천</li>
81-
<li>RGB 백라이트가 필요없다고 했더니 RGB 백라이트가 있는 키보드를 추천함</li>
82-
</ul>
83-
</li>
84-
<li>현행 : 자연어 → LLM 통하여 태그 추출 → 태그 기반 검색
85-
<ul>
86-
<li>추천이 정확해졌음, 사무용은 조용한 축을 가진 키보드를 추천함</li>
87-
<li>RGB 백라이트가 필요 없다고 하는 자연어를 통해 “백라이트 없음”이라는 하드 제약을 만들어서 태그 기반 검색에 활용함</li>
88-
</ul>
89-
</li>
90-
<li>정량화 기준이 없었음, 사용자 반응에 의존하는 정성적 검증 방법으로 정확한가를 거르기 어려웠음</li>
91-
</ul>
92-
</li>
93-
</ul>
94-
<h3>결과</h3>
95-
<ul>
96-
<li>효과: 추천이 좀 더 정확해짐(정성적 판단)</li>
97-
</ul>
98-
<hr>
99-
<h2>B. 개발 진행 상황</h2>
100-
<h3>이번 주에 만든 핵심 기능</h3>
101-
<ol>
102-
<li>자연어 기반 키보드 추천 기능</li>
103-
<li>스위치 특징 레벨 미터</li>
104-
</ol>
105-
<h3>진도</h3>
106-
107-
1주차 MVP 범위 | 현재 상태
108-
-- | --
109-
간소화된 워크숍 / 인터뷰 진행을 통한 신규 가설 검증 및 사용자 문제 인식 확인 | 구글 폼을 통한 설문 조사를 진행했으나, 질문지 부실과 생존자 편향이 강한 설문조사였다고 판단되어 재설문을 위한 설문지 제작
110-
설문조사 기반 기능 설정 및 Gemini Canvas로 UI 프로토타입 구현 | Gemini Canvas로 프로토타입 제작 완료
111-
키보드 카테고리 대상 약 100개 제품 데이터 크롤링 및 수집 | 다나와에서 데이터 600개 수집하여 데이터베이스로 활용
112-
수집 데이터 및 프로토타입 기반 작동 가능한 웹 페이지 구현 | Gemini Canvas로 제작한 프로토 타입을 클로드 코드로 작동하도록 구현
113-
추천 결과 정확도 개선 필요성 인지 및 최종 발표 전까지 지속적 고도화 계획 수립 | 고도화 일부 적용, 추가 태그 규칙 확장/구체화 필요함
114-
115-
116-
<h3>발표에서 보여줄 수 있는 핵심 흐름</h3>
117-
<ul>
118-
<li>자연어 기반 키보드 추천 기능, 단계별 선택지를 통한 키보드 추천</li>
119-
</ul>
120-
<h3>범위 변경 (있다면)</h3>
121-
<ul>
122-
<li>늘어난 것: 시청각 자료(타건 영상 또는 타건음성 파일)</li>
123-
<li>줄어든 것: 없음</li>
124-
<li>이유: 타건음을 의성어로 제공하려 했으나, 의성어는 주관적인 정보이기에, 텍스트로 설명하기에는 한계가 있다고 판단되었다. 따라서 시청각 자료를 위해 데이터 구조를 확장하려 한다.</li>
125-
</ul>
126-
<hr>
127-
<h2>C. 의사결정 / 막힘</h2>
128-
<h3>새로 발견한 문제</h3>
129-
<ol>
130-
<li>서비스의 문제는 전달되었지만 해결 방식과 목표가 명확하게 공유되지 않아, 리뷰어가 서비스의 방향을 다르게 이해했다.</li>
131-
</ol>
132-
<p>이로 인해 의도와 다른 피드백이 이어졌고, 이를 해석하고 조율하는 데 예상보다 많은 시간이 소요되었다.
133-
2. LLM 추천 결과가 부족하게 오거나 잘못된 인덱스를 반환할 경우, 어디까지 fallback으로 채워야 하는지 명확히 정해야 했습니다. 이 처리가 불안정하면 사용자가 빈 결과나 잘못된 추천을 받을 수 있다고 판단했습니다</p>
134-
<h3>결정 + 근거</h3>
135-
<ol>
136-
<li>외부에 피드백을 요청할 때 문제 정의뿐만 아니라 해결 방법과 서비스 목표까지 문서로 명확하게 공유하기로 했다.</li>
137-
</ol>
138-
<p>서비스의 방향을 정확히 전달해야 불필요한 오해를 줄이고, 의도에 부합하는 피드백을 받을 수 있기 때문이다.
139-
2. 추천 fallback 로직은 AI와 Claude 리뷰를 통해 놓칠 수 있는 엣지케이스를 검토한 뒤, 잘못된 인덱스나 부족한 추천 결과가 들어와도 안전하게 처리되도록 정리했습니다.</p>
140-
<p>특히 dead code를 제거하고, 추천 결과가 부족할 경우 fallback으로 채우는 기준을 명확히 하여 사용자가 빈 결과나 잘못된 결과를 받지 않도록 개선했습니다.</p>
141-
<h3>풀리지 않은 막힘 (있다면)</h3>
142-
<ul>
143-
<li>무엇이
144-
<ol>
145-
<li>출처마다 스위치 표기가 달라 별칭 테이블만으로는 모든 데이터를 매핑하기 어렵고, 일부 키보드의 걸림 정도와 소음 수준을 제공하지 못하고 있다. 기존 매핑 구조의 유지 여부와 미매핑 데이터 처리 및 별칭 수집·검증 방법에 대한 결정이 필요하다.
146-
<ol>
147-
<li>별칭 테이블: 데이터 출처마다 다르게 표기된 스위치 이름을 단일화 하기 위해 제작한 스위치 별 별칭 모음</li>
148-
<li>별칭 테이블이 정말로 필요한 구조인지 의문</li>
149-
</ol>
150-
</li>
151-
<li>다나와에서 크롤링한 데이터를 사용하고 있어서 배포시에 문제가 될 것 같은데 어떻게 해결해야할까?</li>
152-
</ol>
153-
</li>
154-
<li>언제까지 결정할지
155-
<ol>
156-
<li>MVP 일정과 데이터 완성도를 고려해 다음 주 월요일까지 결정할 예정이다.</li>
157-
<li>다음 주 화요일까지 데이터 구조를 확정짓고 결정하기</li>
158-
</ol>
159-
</li>
160-
</ul>
161-
<hr>
162-
<h2>D. 회고</h2>
163-
<h3>이번 주 가장 큰 학습 1가지</h3>
164-
<ul>
165-
<li>프로젝트가 진행되면서 새롭게 추가되는 파일의 역할을 설명하는 문서나 프로젝트의 맥락을 기록하는 문서를 미리 작성해두는 것이 중요하다는 점을 깨달았습니다. 또한 배포 방향성 역시 문서로 정리해두어야 팀원 간 이해를 맞추고, 이후 작업 과정에서 발생할 수 있는 혼선을 줄일 수 있다고 느꼈습니다.</li>
166-
<li>AI Agent에 대한 인사이트를 많이 얻을 수 있었다. 미니 프로젝트의 성격 상 AI를 많이 활용하게 됐는데 어떻게 하면 AI를 통제하면서 잘 활용할 수 있을지, AI가 만들어 낸 결과물에 내 의도를 어떻게 잘 녹여낼지, AI에게 끌려다니지 않으려면 어떻게 해야할지 여러 고민이 있었다.</li>
167-
</ul>
168-
<p>그런 상태에서 악어 크루의 AI Agent에 대한 발표를 통해 commend, skills에 대한 인사이트를 얻을 수 있었고 앞으로 AI를 사용하는 역량을 어떻게 높여야 할지 방향을 잡은 것 같다.</p>
169-
<p>AI skills 중 사용자의 의도를 구체화하고 모호성을 줄이기 위해 AI와 토론을 할 수 있는 interview라는 skill이 있다. 이를 활용해 AI에게 내 의도를 명확하게 전달하는 연습을 할 수 있을 것 같다.</p>
170-
<h3>지금 가장 의심스러운 가정</h3>
171-
<ul>
172-
<li>사용자가 원하는 키보드 후보군을 찾는 데 자연어 입력 방식이 실제로 편리한가?</li>
173-
</ul>
174-
<h3>최종 발표 흐름 초안 (1줄)</h3>
175-
<ul>
176-
<li>자연어를 입력하고 키보드 추천 결과를 보여준다.</li>
177-
</ul>
178-
<!-- notionvc: 76f37661-68e7-4ddc-9f81-b44ec2585894 -->
1+
# Week 3 보고서 - ellipsis
2+
3+
## 이번 주 한 일 (계획 vs 실제)
4+
5+
(개발 진도가 계획대로 갔는지)
6+
7+
**계획**
8+
9+
1. 질문지 작성
10+
2. 결과 칼럼 카드 개선 및 데이터 구조 변경
11+
3. 태그 구조 수정 + 버그 수정
12+
4. CODEX sdk Agent
13+
5. 기능추가
14+
1. 타건음 영상
15+
2. 스토어 링크
16+
6. 피드백 받기
17+
1. 구매하기 버튼
18+
2. 매칭 결과 피드백(1~5점)
19+
7. 추천 정확도 올리기
20+
21+
**실제**
22+
23+
1. 질문지 작성
24+
2. 결과 칼럼 카드 개선 및 데이터 구조 변경
25+
3. 태그 구조 수정 + 버그 수정
26+
1. 이전 : 태그를 우리가 만든 데이터베이스에서 가져오는 게 아니라 AI가 만든 태그 기반으로 태그가 정의됨
27+
2. 현행 : 우리 데이터베이스에 있는 속성들 기준으로 변경
28+
4. CODEX sdk Agent
29+
1. CODEX sdk Agent 콜이 아니라, Open API LLM 콜로 바꿈
30+
5. 기능추가
31+
1. 타건음 영상 → 플레이스 홀더로 대체
32+
2. 스토어 링크 → 플레이스 홀더로 대체
33+
6. 피드백 받기
34+
1. 구매하기 버튼
35+
1. MOCK으로 구현, 토스트만 출력되게
36+
2. 매칭 결과 피드백(1~5점)
37+
1. MOCK으로 구현, 슈퍼베이스 연결 안됨
38+
7. 추천 정확도 올리기
39+
1. 우리 서비스에서 제시하는 태그 모아놓기
40+
2. 자연어에서 태그 추출
41+
3. 태그 기반 검색
42+
4. 결과 보여주기
43+
44+
---
45+
46+
## A. 지난주 액션 결과
47+
48+
### 2주차에 정한 1가지
49+
50+
- 무엇이었는가: 추천 결과의 품질 고도화
51+
52+
### 실행 상태
53+
54+
- 진행 중
55+
- 이전 : 자연어 + 키보드 데이터베이스 → LLM 콜
56+
- 추천이 부정확했음, 사무용인데 시끄러운 키보드를 추천
57+
- RGB 백라이트가 필요없다고 했더니 RGB 백라이트가 있는 키보드를 추천함
58+
- 현행 : 자연어 → LLM 통하여 태그 추출 → 태그 기반 검색
59+
- 추천이 정확해졌음, 사무용은 조용한 축을 가진 키보드를 추천함
60+
- RGB 백라이트가 필요 없다고 하는 자연어를 통해 “백라이트 없음”이라는 하드 제약을 만들어서 태그 기반 검색에 활용함
61+
- 정량화 기준이 없었음, 사용자 반응에 의존하는 정성적 검증 방법으로 정확한가를 거르기 어려웠음
62+
63+
### 결과
64+
65+
- 효과: 추천이 좀 더 정확해짐(정성적 판단)
66+
67+
---
68+
69+
## B. 개발 진행 상황
70+
71+
### 이번 주에 만든 핵심 기능
72+
73+
1. 자연어 기반 키보드 추천 기능
74+
2. 스위치 특징 레벨 미터
75+
76+
### 진도
77+
78+
| 1주차 MVP 범위 | 현재 상태 |
79+
| --- | --- |
80+
| 간소화된 워크숍 / 인터뷰 진행을 통한 신규 가설 검증 및 사용자 문제 인식 확인 | 구글 폼을 통한 설문 조사를 진행했으나, 질문지 부실과 생존자 편향이 강한 설문조사였다고 판단되어 재설문을 위한 설문지 제작 |
81+
| 설문조사 기반 기능 설정 및 Gemini Canvas로 UI 프로토타입 구현 | Gemini Canvas로 프로토타입 제작 완료 |
82+
| 키보드 카테고리 대상 약 100개 제품 데이터 크롤링 및 수집 | 다나와에서 데이터 600개 수집하여 데이터베이스로 활용 |
83+
| 수집 데이터 및 프로토타입 기반 작동 가능한 웹 페이지 구현 | Gemini Canvas로 제작한 프로토 타입을 클로드 코드로 작동하도록 구현 |
84+
| 추천 결과 정확도 개선 필요성 인지 및 최종 발표 전까지 지속적 고도화 계획 수립 | 고도화 일부 적용, 추가 태그 규칙 확장/구체화 필요함 |
85+
86+
### 발표에서 보여줄 수 있는 핵심 흐름
87+
88+
- 자연어 기반 키보드 추천 기능, 단계별 선택지를 통한 키보드 추천
89+
90+
### 범위 변경 (있다면)
91+
92+
- 늘어난 것: 시청각 자료(타건 영상 또는 타건음성 파일)
93+
- 줄어든 것: 없음
94+
- 이유: 타건음을 의성어로 제공하려 했으나, 의성어는 주관적인 정보이기에, 텍스트로 설명하기에는 한계가 있다고 판단되었다. 따라서 시청각 자료를 위해 데이터 구조를 확장하려 한다.
95+
96+
---
97+
98+
## C. 의사결정 / 막힘
99+
100+
### 새로 발견한 문제
101+
102+
1. 서비스의 문제는 전달되었지만 해결 방식과 목표가 명확하게 공유되지 않아, 리뷰어가 서비스의 방향을 다르게 이해했다.
103+
104+
이로 인해 의도와 다른 피드백이 이어졌고, 이를 해석하고 조율하는 데 예상보다 많은 시간이 소요되었다.
105+
2. LLM 추천 결과가 부족하게 오거나 잘못된 인덱스를 반환할 경우, 어디까지 fallback으로 채워야 하는지 명확히 정해야 했습니다. 이 처리가 불안정하면 사용자가 빈 결과나 잘못된 추천을 받을 수 있다고 판단했습니다
106+
107+
### 결정 + 근거
108+
109+
1. 외부에 피드백을 요청할 때 문제 정의뿐만 아니라 해결 방법과 서비스 목표까지 문서로 명확하게 공유하기로 했다.
110+
111+
서비스의 방향을 정확히 전달해야 불필요한 오해를 줄이고, 의도에 부합하는 피드백을 받을 수 있기 때문이다.
112+
2. 추천 fallback 로직은 AI와 Claude 리뷰를 통해 놓칠 수 있는 엣지케이스를 검토한 뒤, 잘못된 인덱스나 부족한 추천 결과가 들어와도 안전하게 처리되도록 정리했습니다.
113+
114+
특히 dead code를 제거하고, 추천 결과가 부족할 경우 fallback으로 채우는 기준을 명확히 하여 사용자가 빈 결과나 잘못된 결과를 받지 않도록 개선했습니다.
115+
116+
### 풀리지 않은 막힘 (있다면)
117+
118+
- 무엇이
119+
1. 출처마다 스위치 표기가 달라 별칭 테이블만으로는 모든 데이터를 매핑하기 어렵고, 일부 키보드의 걸림 정도와 소음 수준을 제공하지 못하고 있다. 기존 매핑 구조의 유지 여부와 미매핑 데이터 처리 및 별칭 수집·검증 방법에 대한 결정이 필요하다.
120+
1. 별칭 테이블: 데이터 출처마다 다르게 표기된 스위치 이름을 단일화 하기 위해 제작한 스위치 별 별칭 모음
121+
2. 별칭 테이블이 정말로 필요한 구조인지 의문
122+
2. 다나와에서 크롤링한 데이터를 사용하고 있어서 배포시에 문제가 될 것 같은데 어떻게 해결해야할까?
123+
- 언제까지 결정할지
124+
1. MVP 일정과 데이터 완성도를 고려해 다음 주 월요일까지 결정할 예정이다.
125+
2. 다음 주 화요일까지 데이터 구조를 확정짓고 결정하기
126+
127+
---
128+
129+
## D. 회고
130+
131+
### 이번 주 가장 큰 학습 1가지
132+
133+
- 프로젝트가 진행되면서 새롭게 추가되는 파일의 역할을 설명하는 문서나 프로젝트의 맥락을 기록하는 문서를 미리 작성해두는 것이 중요하다는 점을 깨달았습니다. 또한 배포 방향성 역시 문서로 정리해두어야 팀원 간 이해를 맞추고, 이후 작업 과정에서 발생할 수 있는 혼선을 줄일 수 있다고 느꼈습니다.
134+
- AI Agent에 대한 인사이트를 많이 얻을 수 있었다. 미니 프로젝트의 성격 상 AI를 많이 활용하게 됐는데 어떻게 하면 AI를 통제하면서 잘 활용할 수 있을지, AI가 만들어 낸 결과물에 내 의도를 어떻게 잘 녹여낼지, AI에게 끌려다니지 않으려면 어떻게 해야할지 여러 고민이 있었다.
135+
136+
그런 상태에서 악어 크루의 AI Agent에 대한 발표를 통해 commend, skills에 대한 인사이트를 얻을 수 있었고 앞으로 AI를 사용하는 역량을 어떻게 높여야 할지 방향을 잡은 것 같다.
137+
138+
AI skills 중 사용자의 의도를 구체화하고 모호성을 줄이기 위해 AI와 토론을 할 수 있는 interview라는 skill이 있다. 이를 활용해 AI에게 내 의도를 명확하게 전달하는 연습을 할 수 있을 것 같다.
139+
140+
### 지금 가장 의심스러운 가정
141+
142+
- 사용자가 원하는 키보드 후보군을 찾는 데 자연어 입력 방식이 실제로 편리한가?
143+
144+
### 최종 발표 흐름 초안 (1줄)
145+
146+
- 자연어를 입력하고 키보드 추천 결과를 보여준다.

0 commit comments

Comments
 (0)