[네이버부스트캠프 웹･모바일 10기] 멤버십 17주차 회고

들어가며

일주일 내내 회의가 이어졌다. 이번 주는 개발보다 기획과 설계에 무게를 두었고, 그 뒤에 프로토타입으로 검증까지 진행했다. 처음에는 주어진 기간 안에 모든 팀원이 낯선 기술을 충분히 이해하고 개발을 이어갈 수 있을지 걱정이 컸다. 하지만 이번 프로토타입으로 그 가능성을 확인했고, 이제는 정리한 기획 방향을 따라 확신을 가지고 나아가려 한다.

템플릿에 판단을 맡긴 기획을 다시 쓰다

1주차에는 테오님의 템플릿을 바탕으로 기획 회의를 진행했다. 여러 아이디어를 제안하고 구체화하며 하나의 방향으로 수렴했고, 모두가 같은 곳을 향해 나아갈 수 있도록 팀의 공통 목표와 프로젝트 목표도 구체적으로 세웠다.

그런데 1주차를 돌아보다 의문이 들었다. 과연 지금 같은 방향을 보고 있는 걸까. 기획 문서를 다시 보니 구체적으로 정리된 부분이 많지 않았고, 기능을 떠올릴 때마다 개인적인 해석이 더해지고 있었다. 가장 큰 원인은 템플릿에 생각과 판단을 맡긴 채 흐름대로 넘어간 것이었다. 내부 구조나 흐름을 깊이 고민하기보다 '이런 기능이 있으면 좋겠다' 정도의 눈에 보이는 논의에 그친 경우가 많았다.

2주차가 시작되자 이 고민을 팀원들에게 솔직히 꺼냈다. 일정이 밀릴 우려도 있었지만, 부스트캠프 이전에 이런 문제를 넘겼다가 의견 충돌과 감정 소모를 겪은 일이 잦았기에 지금 짚고 넘어가야 한다고 느꼈다. 의견을 말하는 것만으로는 설득이 어렵다고 보고 팀원 모두가 함께 하나의 기획서를 작성하자고 제안했고, 다행히 모두 동의해줬다. 다른 팀들의 기획서를 참고해 우리 팀만의 양식을 만들었고, 서로 다르게 생각한 부분을 마주칠 때마다 논의하고 조율했다.

걱정대로 하루를 온전히 기획에 쏟으면서 다른 팀보다 속도가 늦어졌다. 하지만 그만큼 기획은 훨씬 구체적이고 명확해졌다. 특히 회의라는 단어를 강의로 바꾼 것만으로 서비스의 목적과 타깃이 뚜렷해졌다. 회의라는 포괄적인 개념 안에서는 기능마다 방향을 다시 고민해야 했지만, 강의를 중심에 두자 어떤 기능이 불필요하고 무엇을 우선해야 하는지가 바로 드러났다. 모두가 같은 방향을 보게 되면서 이후 설계와 디자인 단계의 고민도 눈에 띄게 줄었다.

로그인 없이 강의자를 가려내다

설계는 짧은 시간 안에 높은 집중력과 원활한 소통이 필요하다고 봐서, 월요일에 갑작스럽게 팀원들에게 제안해 다음 날 대면으로 모였다. 화상 강의라는 낯선 기술에 어떻게 접근할지 논의한 뒤 각자 설계 내용을 정리해 공유했고, 이를 기획서와 함께 AI에 전달해 하나의 통합 설계 문서로 묶었다. 기획서를 미리 잘 정리해둔 덕분에 AI도 서비스 흐름을 잘 파악했고, 완성된 문서는 단계별로 함께 검토하며 다듬었다.

메인 기능에 집중하려고 로그인 기능을 빼자, 강의자와 청중을 구분할 방법이 사라졌다. 단순한 장치는 청중이 쉽게 우회할 것 같았고, 비밀번호 방식도 UX 면에서 최선인지 확신이 서지 않았다. 결국 강의자가 강의를 생성하면 곧바로 입장하게 해서, 생성한 사람을 자동으로 강의자로 판별하는 방식을 택했다. 추가 검증 절차 없이도 자연스럽게 구분되는 방법이었다.

다만 이 논의가 길어져 다른 플로우를 설계할 시간이 줄었고, 주간 팀 회고에서도 우선순위에 비해 시간이 많이 들었다는 이야기가 나왔다. 매일 스크럼으로 하루 단위 계획에는 익숙해졌지만, 전체 흐름을 구분 짓는 데는 아직 부족했다. 회의 도중에도 남은 시간 안에 반드시 정할 일과 뒤로 미뤄도 되는 일을 가르는 과정이 필요하다고 느꼈다.

세 가지 가설로 프로토타입을 검증하다

프로토타입은 최소한의 기능으로 아이디어가 실제로 작동하는지 확인하는 과정이라 보고, 요구사항 분석, 가설 설정, 설계와 구축, 검증, 피드백 순서로 진행했다. 지난주에 목표로 잡은 제스처 인식과 다수 사용자 화상 강의에, 두 기능이 동시에 원활히 도는지까지 더해 세 가지 가설을 세웠다.

1. 제스처 인식이 실시간으로 작동한다
2. 여러 사용자가 동시에 영상과 음성을 안정적으로 공유할 수 있다
3. 영상과 음성을 공유하면서 실시간 제스처 인식도 원활히 수행된다

목표는 최적화가 아니라 기술적 가능성을 판별하는 것이었기에 검증용 코드는 AI에게 맡겼다. 선정한 기술 스택과 라이브러리를 기준으로 프롬프트를 작성해 짧은 시간 안에 코드를 완성했고, 앞서 팀 내에서 라이브러리를 학습하고 공유해둔 덕분에 코드를 이해하고 고치기도 수월했다.

검증은 두 단계로 나눴다. 제스처 인식은 구글이 제공하는 인체 인식 모델 덕분인지 높은 인식률로 통과했고, 여러 사용자의 영상과 음성 공유도 안정적으로 동작했다. 세 가설을 모두 검증하며 웹 환경에서 실시간 영상, 음성 공유와 제스처 인식이 충돌 없이 함께 돌아갈 수 있다는 결론을 얻었다.

다만 팀 피드백에서 확인할 거리도 남았다. 어두운 조명이나 낮은 네트워크 품질, 피부색이나 옷 색상에 따른 인식률 차이, 동시 접속자가 50명, 100명 단위로 늘어날 때의 문제 등이다. 시간 여유가 있었다면 검증 결과로 새 가설을 세우고 다시 검증하는 과정을 반복하며 이런 부분까지 체계적으로 짚어봤을 것 같아 아쉬움이 남는다.

데모 발표에서 무엇을 전해야 했을까

데모 발표를 돌아보면 충분히 잘 설명했는지 확신이 서지 않는다. 기술 설명에 집중하면 서비스의 전체 흐름이 흐려지고, 기획 과정을 중심으로 하면 기술적 깊이가 부족해질 것 같았다. 15분 안에 둘 다 담기는 어렵다고 보고, 이번 주가 기획을 다지는 주였던 만큼 '왜 기획을 다시 하게 되었는가'를 주제로 삼았다.

하지만 돌아보면 그 선택이 맞았는지 다시 생각하게 된다. 데모 시간은 각 팀이 같은 주제에 어떻게 접근했고, 그것을 각자의 서비스에 어떻게 녹여냈는지 공유하는 자리였다. 프로토타입 주간이었던 만큼 사용한 기술과 검증 과정을 좀 더 구체적으로 보여줬어야 했다. 다음 데모에서는 그 주에 어떤 논의가 오갈지 미리 짐작해보고 그에 맞춰 준비하려 한다.

정리하며

캠퍼들과 의견을 나누다 보면 미처 생각하지 못한 시각을 자주 발견한다. 부스트캠프 이전에는 늘 익숙한 방식대로만 진행했기에 다른 방식을 보면 '저게 잘 될까' 하는 의문부터 들었다. 하지만 여러 접근법을 직접 보고 들으며 몰랐던 장점이 많다는 걸 알게 됐고, 이제는 새로운 방식을 만나면 먼저 궁금해진다.

이번 주에 기획서를 함께 다시 쓴 것도 결국 같은 이야기였다. 각자 머릿속에 있던 서로 다른 그림을 꺼내 한곳에 모으자, 일정은 조금 늦어졌어도 설계와 검증은 오히려 빨라졌다. 같은 방향을 보는 데 들인 하루는 지연이 아니라 투자였다. 앞으로도 방향이 흐려진다고 느껴지면 망설이지 않고 멈춰서 다시 맞춰보려 한다.