네이버 부스트캠프 웹・모바일 10기 멤버십 18주차 회고

• 기술적인 도전 정리

• 와이어프레임 설계

• 프로젝트 게시 동의

• 백로그 도출

• 회의록 관리 전략

1️⃣ 기술적인 도전 정리

• 우리 팀은 3주차가 시작되자마자 우리 프로젝트 주제에서 어떤 기술적인 도전 요소들이 있을지를 정리했다.

우리 팀은 왜 기술적인 도전 요소들을 먼저 정리했나?

• 2주차 시니어 리뷰어 피드백에서 조은님께서는 “문제 의식은 명확하지만, 커뮤니티 서비스의 특성상 단순 CRUD 수준에서 끝날 가능성이 있어 보인다” 라는 코멘트를 주셨다.

• 문제 정의는 잘했지만, 기술적인 난이도가 낮기 때문에 면접관의 입장에서 프로젝트의 차별성을 못 느낄 수 있다는 현실적인 피드백이었다.

• 그래서 우리는 기능 구현에 앞서 프로젝트에서 반드시 가져가야 할 기술적인 고민과 도전 요소를 먼저 정의하는 것이 필요하다고 판단했다.

어떻게 기술적인 도전 요소들을 정의했나?

• 인터 미션 기간(2주)동안 프론트엔드. 백엔드, DevOps 관점에서 어떤 기술적인 어려움이 있을지 최대한 발산해보기로 했다.

• 이때 기술적 도전을 위한 “기능 확장” 보다는, 우리에게 꼭 필요한 기능을 깊이 있게 설계하는 “깊이 확장”에 집중하기로 했다.

우리에게 필요한 기술적인 도전 요소는?

• 인터미션 기간 동안 생각해온 의견들을 발산했고, 이후 모든 아이디어를 가져가기보다는 서비스의 본질과 직접적으로 연결되는 요소들만 남기는 방향으로 수렴했다.

• 그 결과, 우리 팀은 다음과 같은 기술적인 도전 요소들을 프로젝트의 핵심으로 정의했다.

1. 사용자 경험을 고려한 디자인 사용 흐름과 맥락을 고려한 UI/UX 설계가 필요하다고 판단했다.

2. SEO 커뮤니티 서비스인 만큼, 검색 엔진 노출이 중요하다고 판단했다.

3. RSS 수집 시스템 외부 콘텐츠를 안정적으로 수집하고 관리하는 과정에서 데이터 정합성과 확장성을 함께 고려해야 한다.

4. 검색 시스템 사용자가 원하는 정보를 빠르게 찾을 수 있어야 한다.

5. 빠른 응답 속도 커뮤니티 서비스에서 체감 성능은 곧 사용자 경험으로 이어진다.

6. 서버 비용 절감 수료 후에도 서비스가 지속적으로 운영될 수 있도록 서버 비용을 절감해야 한다.

의견 수렴 과정에서 느낀 점은?

• 의견을 수렴하는 과정에서 각자 중요하다고 생각하는 포인트가 달랐기 때문에, 합의 과정이 쉽지는 않았다.

• 예를 들어, 보수적인 성향이 강한 나는 기술적인 도전을 개발 주차 후반에 시도하는 편이 낫다고 생각했다.

• 반면, 일부 팀원들은 초반부터 난이도 있는 기술을 구현해서 리스크를 빠르게 확인하는 것이 중요하다는 의견을 냈다.

• 논의를 거치며 기술적인 도전 역시 미루는 것이 안전한 선택이 아닐 수 있고, 오히려 초반에 부딪혀보는 것이 더 합리적일 수 있다는 생각을 하게 됐다.

2️⃣ 와이어프레임 설계

• 기술적인 도전을 정의하고 나서 Figma Make로 만들었던 데모 사이트를 참고해서 와이어프레임을 재설계했다.

우리 팀은 왜 와이어프레임을 재설계했나?

• Figma Make로 만든 데모 사이트는 빠르게 결과물을 도출해 공유하는 데에는 유용했지만, 실제 서비스에 바로 적용하기에는 UI 완성도와 사용자 경험 측면에서 아쉬움이 있었다.

• 그래서 우리 팀은 시간이 조금 더 걸리더라도 사용자 시나리오를 바탕으로 와이어프레임을 재설계하기로 했다.

• 이 과정에서 많은 논의가 있었고 UI/UX를 책임지는 June이 고생을 많이 해주었다.

랜딩 페이지가 필요한가? 필요하지 않은가?

• 가장 기억에 남는 논의 중 하나는 랜딩 페이지가 필요한가에 대한 고민이었다.

• 여기서 랜딩 페이지란, 메인 페이지 진입 이전에 서비스의 목적과 기능들을 소개하는 화면을 의미한다.

• 찬성 측의 의견은 서비스의 타겟이 캠퍼뿐만 아니라 부스트캠프에 관심 있는 예비 지원자들까지 포함되므로, 이들에게 서비스를 소개하는 화면이 있었으면 좋겠다는 의견이었다.

• 반대 측의 의견은 오히려 접속 전에 버튼을 한 번 더 눌러야 하기 때문에 사용자 경험에 독이 될 수 있다고 생각했다.

• 우리 팀은 장시간 토론 끝에 다음과 같이 결정했다.
• 첫 방문자에게는 랜딩 페이지를 보여주되, 이후 방문자에게는 로컬 스토리지의 플래그를 확인해서 바로 메인 페이지로 진입하게 하는 방식을 채택했다.
• Rooney의 좋은 의견으로, 추후에 사용자가 페이지에 얼마나 머무는지, 스크롤을 어디까지 내리는지 등의 통계를 집계해서 랜딩 페이지가 정말 필요할지 확인해보기로 했다.

• “일단 만들고 판단하자”가 아니라, 데이터로 검증할 수 있는 여지를 남겨둔 결정이라는 점에서 팀의 의사결정 방식이 더 나은 쪽으로 선택되고 있다는 느낌을 받았다.

팀원으로부터 배웠던 점은?

• 이번 주 데모 시간에 UI와 관련해서 June이 발표를 준비해주었는데, 결과만 보여주는 방식이 아니라 의사결정 과정 자체를 설명해주신점이 가장 인상 깊었다.

• 피그마의 버전 히스토리를 활용해 팀원들의 피드백이 어떻게 반영되었고, 디자인이 어떤 이유로 바뀌어 왔는지를 타임라인처럼 풀어서 설명해주셨다.

• 동료들의 피드백을 빼먹지 않고 잘 기억해두셨기 때문에 이와 같은 발표가 가능했다고 생각한다.

• 또 June은 UI/UX에 대한 기준을 분명하게 가지고 있었다.

• 대시보드 형태의 메인 페이지 구성이나 더보기 버튼 위치처럼, 사용자 입장에서 왜 이 구조가 좋은지를 설명하는 방식이 인상적이었다.

• 나는 확실한 근거보다는 느좋(느낌이 좋은지) 여부로 판단해왔던 부분이 많았는데, June의 설명을 들으면서 많이 배웠다.

3️⃣ 백로그 도출

• 백로그도 3주차에 모두 정리했다.

• 백로그 관리는 Github Project로 관리하고, Epic/Story/Task 별로 issue를 계층화해서 관리하기로 했다.

• 같이 백로그를 도출하면서 새로 생겨난 의문과 기능에 대해서 토론하고 결정했다.

프로젝트에 조회수를 보여줘야 할까? 보여주지 말아야 할까?

• 가장 기억에 남는 논의는 프로젝트에 조회수를 노출할지 여부에 대한 고민이었다.

• 조회수는 사용자에게 어떤 프로젝트가 인기있는지 전달할 수 있다는 장점이 있는 반면, 의도치 않은 조회수 경쟁이 발생할 수 있다는 우려도 있었다.

• 조회수를 공개 하는 것에 찬성 1표, 반대 4표가 나왔는데, 찬성 입장을 낸 Tom이 강하게 의견을 표했다.

• Tom은 다수결의 의견에도 불구하고 데모 시간에 다른 팀원들에게 의견을 다시 한번 물어본 뒤에 결정하는 것이 어떻겠냐고 의견을 냈다.

• 그래서 우리는 금요일 데모 시간에 조회수 공개에 대한 다른 팀의 의견을 구하기로 했다.

다른 팀의 생각은?

• 결과는 충격적이게도 조회수를 공개하는 것에 찬성 10표, 반대 0표가 나왔다. (캠퍼 12명을 대상으로 투표 진행했다.)

• 이 과정에서 배운 점은 우리 팀의 생각과 실제 사용자(다른 팀)의 의견은 다를 수 있다는 점을 깨달았다.

• 결과적으로 용기 있는 Tom의 제안 덕분에 우리 팀이 더 나은 방향의 의사결정을 하도록 했다.

4️⃣ 프로젝트 게시 동의

• Tom의 하드 캐리로 부스트캠프 10기의 38팀 모두에게 프로젝트 게시 동의 여부를 얻었던 것도 기억에 남는다.

• Tom은 실행력이 정말 뛰어나서, 먼저 연락 문구를 정리하고 각 팀에 직접 빠르게 컨택을 시도했다.

• 생각해보면 프로젝트 아카이빙 기능을 만들어놨는데 다른 팀의 동의가 없다면 무슨 의미가 있나 싶다.

• Tom은 매번 미래에 발생할 수 있는 문제를 미리 고민하고 해소하려는 모습을 보여주었다. 이런 점에서 본받을 점이 정말 많은 동료라고 느꼈다.

5️⃣ 회의록 관리 전략

• 팀에서 ‘회의록 관리’를 담당하는 직책을 새롭게 맡게 되었다.

• 나는 프로젝트 기획 단계에서부터 ‘회의록 기록과 요약 자동화’를 아이디어로 제안했을 만큼 회의록 관리에 진심이다.

• 기록이 남지 않으면 팀의 의사 결정 과정 자체가 쉽게 휘발될 수 있다고 생각했다.

• 그래서 회의가 끝날 때마다, 슬랙 허들 스크립트 대본과 사전에 정의한 팀 회의록 포맷을 AI에게 전달해 회의 내용을 요약하도록 했다.

• 하지만, 이 방식에는 명확한 한계가 있었다.
1. AI의 장기 기억 문제로, 회의가 길어지면 주요 회의 아젠다나 결정 사항이 누락되는 문제가 발생했다.
2. 발언자가 함께 기록되지 않아, 어떤 맥락에서 나온 의견인지 추적하기 어려웠다.
3. 자연어 기반 검색이 불가능하고 키워드 검색에 의존해야 했다.

NotebookLM + Slack 허들 스크립트를 활용한 회의록 관리

• 그래서 주말 동안 회의록을 어떻게 하면 더 효율적으로 관리할 수 있을지에 대한 고민을 많이 했다.

• 그러다 내가 찾은 아주 좋은 해답이 바로 NotebookLM과 Slack 허들 스크립트를 함께 활용하는 방식이었다.

• 방법은 아주 간단하다. 회의가 끝날 때마다 Slack 허들 스크립트를 복사해 NotebookLM의 소스로 추가해주기만 하면 끝이다.

• 그리고 내가 궁금한 회의 내용을 자연어로 질문하면 NotebookLM은 회의 맥락을 기반으로 답변을 제공해준다.

• 단순히 회의 내용을 요약해주는 수준이 아니라, 어떤 논의 끝에 해당 결론이 나왔는지까지 함께 설명해준다는 점이 인상적이었다.

• 덕분에 “이 기능을 왜 하기로 했지?”, “이때 반대 의견은 뭐였지?”처럼 잊기 쉬운 질문에도 빠르게 답을 얻을 수 있었다.

• 다만, NotebookLM에 추가할 수 있는 소스의 한도와 하루 최대 쿼리 수가 50개이기에 이를 어떻게 보완할지는 조금 더 고민해봐야겠다.

6️⃣ 다음 주 액션 플랜

• 내 의사결정 과정을 더 잘 드러낼 수 있도록, 결정의 배경과 이유를 문서로 꼼꼼히 남긴다.

• 완성되지 않은 생각이라도 “정리 중인 의견”임을 밝히고 먼저 말해본다.

• 중요한 결정은 팀 내부 판단으로 끝내지 않고, 데모 시간을 활용해 외부 의견으로 한 번 더 검증한다.

• 기술 선택이나 일정 판단에서 ‘내가 안전하다고 느끼는 선택’과 ‘프로젝트에 더 나은 선택’을 의식적으로 구분해 생각한다.

• 필요하다면 초반에 리스크를 감수하더라도, 차별성 있는 프로젝트를 만들기 위해 더 열린 태도를 가져본다.

7️⃣ 마무리하며

• 다른 팀들은 벌써 개발에 들어갔는데, 우리 팀만 기획 과정에 머물러 있는건 아닌지 걱정이 많이 됐다.

• 하지만 돌이켜보면 우리 팀의 목표가 “완성도 높은 서비스를 만들고, 팀이 항상 잘 동기화된 상태로 협업하는 것” 이었기에 이 시간은 꼭 필요하다고 생각한다.

• 단순히 기능 목록을 정리하는 데서 끝나는 기획이 아니라, 어떤 선택을 중요하게 여겼고 어떤 선택을 의도적으로 하지 않았는지까지 함께 정리할 수 있었기 때문이다.

• 이제는 충분히 고민한 만큼, 판단한 내용을 코드로 옮기는 단계로 넘어가려 한다.