Retrospect - 100-hours-a-week/6-nemo-wiki GitHub Wiki

4Ls (Liked, Learned, Lacked, Longed for)

• Liked: 좋았던 점
• Learned: 배운 점
• Lacked: 부족했던 점
• Longed for: 더 바랐던 점

---

스프린트1(기획), 스프린트2(설계) 회고

ray

Liked	Learned	Lacked	Longed for
프로젝트를 A부터 Z까지 경험할 수 있어서 스타트업 개발 과정을 알 수 있었다.	기술적인 내용이나 방법론에서 충분히 아는 내용이라 생각했지만 깊은 고민을 하다보면 많이 부족한 부분을 알게 되었다. (애자일, 프론트엔드 기술)	부족한 시간적 여유로 개인적으론 완벽하지 못한 설계 단계에 있어 아쉬운 부분이 있다.	매 스프린트마다 시간적 여유를 가졌으면 하는 바램이 있었다.

daniel

Liked	Learned	Lacked	Longed for
항상 “왜”를 생각하는 습관을 기른 점이 좋았습니다. 어떤 기능을 구현하고자 할 때 미리 설계하니 “왜”라는 생각으로 인해 더 많은 것을 배울 수 있었습니다.	설계를 하기 전 기획부터 진행하니 기획의 중요성과 통찰력을 배웠습니다. 특히 화면설계서 내의 기능정의서를 만들며 어떤 부분이 부족하고 어떤 부분까지 작성해야하는지 세부적으로 체크할 수 있었고 이를 설계와 연계할 수 있었습니다.	wiki에 작성한 일정들을 잘 지키지 못했던 것 같습니다.	기획을 처음 경험해보아서 비교적 오래 걸리게 되었고 일정이 조금 타이트하다고 느꼈습니다.

glenn

Liked	Learned	Lacked	Longed for
그저 이런 서비스가 있으면 좋겠다에서 끝나는 기획이 아닌 해당 문제를 더 깊게 들어가 실제로 수요가 있는지, 시장성이 있는지 등 프로젝트 수준보다 더 나아가 실제 서비스 관점에서 기획을 할 수 있는 기회가 있어서 좋았습니다.	이번 기획을 통해 추후 기획자와의 소통 시 더 좋은 커뮤니케이션을 할 수 있을 것이라고 생각합니다.	기획하는 과정이 길어질수록 지치다보니 어느 시점에선 그냥 빨리 넘어가고 싶다라고 생각해 조금 기획을 등한시한 점도 있었다.
사실 처음 설계 당시에는 구축도 안해봤는데 어떻게 설계를 하는지에 대한 의문이 있었다. 하지만 자세한 건 구축 때 맡기고 구축에 대한 큰 그림만 그리고 들어가니 확실히 설계 없이 구축들어갔을 때와는 눈에 띄게 트러블 슈팅이나 병목 지점이 사라짐을 느꼈습니다.	설계에 대한 중요성과 리소스 하나하나 왜 이게 필요하지 다른 더 좋은 방법은 없을지 고민하다보니 생각할 수 있는 범위가 넓어졌다.

sean

Liked	Learned	Lacked	Longed for
설계 과정에서 팀원들과의 커뮤니케이션과, 그 과정에서 목표했던 기능을 정해진 기간내에 대부분 구현할 수 있었다는 점에 서 좋았습니다.	깃허브 플로우와 협업 프로세스에 대해서 배우고, 팀 내에서 주어진 업무에 대해서 어떻게 분배하고 효율적으로 관리할 수 있는지에 대해 배우게 되었습니다.	일정 관리 측면에서 다소 타이트하고 촉박했다고 생각합니다. 기초지식이 부족해서 공부하는 시간까지 고려하다보니 팀원한테 많이 의존할 수 밖에 없었다.	프로젝트 후반부 설계에서 클라우드 개념에 완벽하게 이해하고 습득하여 , 이후에도 프로젝트 아키텍쳐에 대한 설명을 자신있게 얘기하고싶습니다.

lillian

Liked	Learned	Lacked	Longed for
기존에 하지 않았던 역할을 맡아보며 스스로에게 신선한 도전이 되었다는 점이 마음에 들었습니다. 좋은 팀원들도 잘 만나서 좋습니다.	기획과 설계의 중요성을 배우고, 세세한 문서화와 비용, 효율성 등을 고려하며 프로젝트를 준비하는 과정이 개발만큼 어렵다는 것을 깨달았습니다.	기초 지식이 부족해 모든 것을 처음부터 학습해야 했고, 많은 지식을 팀원들에게 의존할 수밖에 없었습니다.	프로젝트가 문제없이 완성되기를 가장 바라고, 추가로 AI 기능 확장을 희망합니다. 근데 아직 생각한 기능이 없어서 보류입니다.

romi

Liked	Learned	Lacked	Longed for
‘여행’이라는 기획 분야만 주어지고 팀원들과 아이디에이션하여 하나의 전반적인 서비스를 기획하기까지 기획 전 과정에 참여할 수 있어서 좋았다.	만들면 편하고 좋을 것 같다고 생각한 하나의 기능을 구현해내기 위해 많은 디테일적인 부분들이 필요하다는 것을 자주 느꼈다.	팀원들과 같이 의논했을 때 분명 이해했다고 생각했던 부분들이 동기화가 되지 않은 부분이 있어 수정이 필요했다.AI 뿐만 아니라 백엔드, 클라우드와 소통하려면 어느 정도 이해가 필요한데 많이 부족했다.	부족한 부분이 많아 이해가 많이 더딥니다.. 하지만 이 부분은 제가 더 노력해야 하는 부분입니다. 자세히 설명해주시면 감사합니다..ㅎㅎ

스프린트3(MVP) 회고

ray

항목	내용
Keep	팀: 모두가 열심히 노력하는 환경, 배려하는 마음, 공유를 통한 협업 프로세스가 잘 진행되고 있다고 생각했습니다.개인: 서비스의 퀄리티를 위한 노력, 서비스에 대한 애정과 발전을 위한 지속적인 노력과 고민이 지속되었으면 좋겠습니다.
Problem	팀: 더 나은 팀 문화를 위해 가볍게라도 피드백을 전해주면 좋겠다는 생각이 들었습니다. 아젠다가 있다면 기록하는 습관을 들이면 더 좋을 것 같습니다.개인: MVP 구현 진행 마감일을 못 지켰습니다. 하나의 스프린트가 느려질 때마다 다음 스프린트 때 영향이 있는 것 같습니다.
Try	팀: 스스로 먼저 피드백하는 습관 들이기, 스스로 먼저 기록하여 팀 문화 개선시키기개인: 스프린트 작업 목표를 깊게 고민해보기, 현업 생각이라 생각하고 개인적인 욕심을 반영하지 않기

---

daniel

항목	내용
Keep	팀: 문제가 있으면 빠르게 소통하고 반영한다.개인: 작업 전 PL과 일정을 공유하고 조율한다.
Problem	팀: issue를 작성하는 단위가 달라서 서로의 진행상황을 알아보기 어렵다?개인: issue에 트러블 슈팅 작성을 최신화하지 못했다.
Try	팀: issue 작성 기준을 조율하고 잘 지키기개인: issue를 꾸준히 신경쓰고 최신화 잘하기

---

glenn

항목	내용
Keep	팀: 팀 전체에 피해를 주면 안된다는 생각이 서로 열심히 하는 동기가 되는 것 같습니다.개인: 변경사항 생길 때 PL, PM과 공유, 팀 전체 문서화 공유 및 파트 간 공유
Problem	팀: 공유는 했지만 전달이 안된 경우도 존재 / 같은 파트 간 작업 공유 / 기획적인 부분에 대한 논의가 적음개인: 바로바로 트러블 슈팅 로그 작성을 못하는 경우도 존재 / 마일스톤 종료 후 동기부여 저하
Try	팀: 스크럼 때 바로바로 구두로 공유 / 주기적으로 계속 소통하며 작업 공유 / 주기적으로 회의하는 시간

---

sean

항목	내용
Keep	팀: 문제에 대한 빠른 소통 및 협업 프로세스개인: 협업 프로세스
Problem	팀: 논의가 필요한 사항에 대해서 각자의 지식이나 아는 부분이 다르다 보니 동기화 오류 발생개인: 각자 맡은 분야에 대해서 트러블슈팅 및 하는 과정에서 시간을 많이 잡아먹어서 기간 내에 끝내지 못한 경우가 있었음 / 트러블슈팅 관련 이슈/로그 작성 부재
Try	팀: 문제가 생기거나 issue에 대해서 즉시 최신화 및 공유

---

lillian

항목	내용
Keep	팀: 문서화 공유가 잘 이루어짐개인: 이슈에 민감하게 반응하고 빠르게 대응함
Problem	팀: 상황공유개인: 트러블 슈팅
Try	팀: 합의가 필요한 사안은 확인 절차 명확히 하기개인: 문제와 대면하기 / 위키 이슈 비고란 상세히

---

romi

항목	내용
Keep	팀: 문서화개인: 회의록/피드백/멘토링 문서화
Problem	팀: 각 파트간 진행상황 확인개인: 내가 맡은 부분의 wiki에 작성한 설계 부분에서 성능 관련한 문제와 같은 이슈로 다시 모델 선정해야 하는 일이 있었다. / 트러블 슈팅 로그 작성
Try	팀: 버전 2 논의 후 업무 분담 진행개인: 좀 더 꼼꼼한 테스팅과 명확한 성능 지표로 진행해야 한다. / 작은 부분이라도 한 줄이라도 매일 트러블 슈팅 로그 작성하기

스프린트5,6 (V2)

좋았던 점

• 배포 일정을 맞추기 위해 노력했다
• 분위기
• 팀 담합
• 테크 스펙 작성

---

아쉬운 점

• 서버 상태에 대한 이해 부족
• 인프라 전환 시 충분한 테스트를 하지 못해 배포가 느려지는 점
• 챗봇 속도가 느림 (개발, 추론)
• 소통 아쉬움 / 협업 분배 어려움
  • 서로의 일정을 공유는 하지만 잘 인지하고 있지는 못하다
• 기한 내에 마무리하지 못함

---

개선/지속할 점

• 같은 파트 간 공유 필요
• AI - 성능 리소스 아끼기 / 배포 일정 미흡
• 서로의 일정을 간단하게 나마 인지하고 있기 (각 파트 별로)

→ 데일리 스크럼 개선이 필요할 수도 있을 것 같다.

• 마감일이 불명확하다 보니 서로의 파트에 영향을 줌
• FE가 BE를 통해 상황 공유를 주로 받다 보니 AI에게서 좀 더 직접적으로 받는다면 좀 더 소통하기 수월할 것 같다
• 같은 파트 간 코드 리뷰 / 작업 리뷰 필요

개선 진행

1. 데일리 스크럼

• 목표 컬럼 제거: 작업 진행률에 대해 추상적인 느낌이 강하고, 전날과 비교한 진행률 상황 파익이 안 된다는 단점. 또한 이상적인 목표치에 가까워지는 느낌 존재.
• 아직 칼럼 추가: 전날 데일리스크럼에 작성한 작업 중 끝내지 못한 작업을 기입하고 전날과 비교해 어떠한 작업 진행 상황이 있는지 이해하기 위함
• 마감일 -> 금일로 국한 X / 작업을 완료하는 시점으로 작성 (e.g.목요일 오전까지)
• 다른 챕터에서 이해할 수 있도록 기술 중점이 아닌 기능 중점의 작업 내용 작성: ex) Websocket 도입 X -> 모임 추천을 위한 AI 챗봇과 실시간 통신을 위해 WebSocket을 도입

2. 17:50 공유 진행

• 데일리스크럼 때 계획했던 일 중 완료하지 못한 일을 가볍게 공유합니다