Rocky 's Blog

회고를 시작하며

이번 주는 어떻게 보냈는가?

일주일 동안 지속적으로 회의를 진행했다. 이번 주는 개발에 집중하기보다 기획과 설계에 중점을 두었으며, 이후 프로토타입을 진행했다. 처음에는 주어진 기간 안에 모든 팀원들이 기술을 충분히 이해하고 개발을 이어갈 수 있을지 걱정이 있었다. 그러나 이번 프로토타입을 통해 그 가능성을 확인했고, 이제 기획 방향에 따라 더욱 확신을 가지고 나아가고자 한다.

다시 한번 기획을 돌아볼까요?

1 주차의 기획 진행 내용

1 주차에는 테오님의 템플릿을 기반으로 팀 내에서 다양한 의견을 나누며 기획 회의를 진행했다. 서로 여러 아이디어를 제안하고, 각 아이디어를 구체화하는 과정을 거쳤다. 이후 아이디어들을 점차 수렴해 하나의 방향으로 결정했으며, 선정된 아이디어를 구체화해 나갔다. 그렇게 점차 아이디어가 다듬어지며 기획의 틀이 잡혀갔다.

1 주차를 회고하며

팀의 목표는 하나의 방향을 설정하고, 모두가 그 목표를 향해 함께 나아가는 것이었다. 이에 따라 팀의 공통 목표와 프로젝트 목표를 구체적으로 설정했다. 그러나 1 주차를 회고하며 문득 의문이 들었다. 과연 우리는 지금 같은 방향성을 가지고 나아가고 있는 걸까?

기획 과정이나 기획 문서를 살펴보니 아직 구체적으로 정리된 부분이 많지 않았다. 기능 측면에서도 세부적인 내용이 부족했고, 기능을 떠올릴 때마다 내 개인적인 해석이 더해진다는 생각이 들었다. 그렇다면 다른 팀원들도 비슷하지 않을까? 결국 우리는 조금씩 다른 방향을 바라보고 있는 건 아닐까? 하는 걱정이 들었다.

왜 그런 문제가 생겼을까?

템플릿을 충분히 활용하지 못한 부분도 있었을 것이다. 하지만 무엇보다도 템플릿에 나의 생각과 판단을 맡긴 채, 흐름에 따라 그대로 넘어간 것이 가장 큰 원인이라 느꼈다. 또한 눈에 보이는 부분만을 중심으로 논의한 경우가 많았다. 내부적인 구조나 흐름을 깊이 고민하기보다는 이런 기능이 있으면 좋겠다, 이런 요소가 필요하겠다 정도의 논의에 그쳤던 것 같다.

2 주차를 시작하며

2 주차가 시작되자, 이런 고민을 팀원들에게 솔직히 이야기했다. 사실 그냥 지나쳐도 되는 문제일 수도 있었다. 어쩌면 팀원들 모두 같은 생각일 수도 있었고, 다시 설정하다 보면 시간이 지체되는 우려도 있었다.

그럼에도 불구하고, 앞으로 발생할 수 있는 충돌을 생각했을 때는 지금 분명히 짚고 넘어가야 한다고 느꼈다. 부스트캠프 이전을 돌아보면 이런 문제를 늘 그냥 지나쳤고, 그 때문에 이후 팀 내에서 충돌이 잦았다. 서로의 생각이 다를 때 누군가의 의견은 결국 접혀야만 한다. 그 과정에서 감정 소모가 뒤따르곤 했고, 이번 팀에서는 그런 상황을 되풀이하고 싶지 않았다.

어떻게 해결하고자 했는가?

단순히 의견을 제시하는 것만으로는 누군가를 설득하기 어렵다고 생각했다. 그래서 어떻게 하면 모두가 같은 방향을 바라볼 수 있을지 고민했고, 그 결과 팀원 모두가 함께 하나의 기획서를 작성하는 방안을 떠올렸다. 이에 대해 팀원분들께 제안드렸고, 다행히 모두 동의해주셨다. 속도는 다르더라도, 같은 방향을 바라보며 모두가 같은 이해를 바탕으로 함께 나아가고자 했다.

모두가 함께 기획서를 작성하면서 서로 다르게 생각한 부분들을 마주할 때마다 논의하고 조율해 나가기로 했다. 또한 다른 팀들의 기획서를 참고해 핵심 요소들을 종합하고, 우리 팀만의 구체적인 기획서 양식을 만들어갔다.

결과적으로 어떻게 바뀌었나?

처음 걱정했던 것처럼 일정이 다소 지체된 것은 사실이다. 하루를 온전히 기획에 쏟으면서 다른 팀보다 속도가 늦어졌다. 그러나 그만큼 지난주보다 기획이 훨씬 더 구체적이고 명확해졌다는 점은 분명했다.

특히 회의 라는 단어를 강의 로 바꾸는 단순한 수정만으로도 서비스의 목적과 타겟이 뚜렷해졌다. 이전에는 회의 라는 포괄적인 개념 속에서 고려 범위를 정하기 어려웠고, 기능 하나하나마다 방향성을 다시 고민해야 했다. 하지만 강의 를 중심으로 설정하자, 어떤 기능이 불필요한지, 무엇을 우선해야 하는지가 명확히 드러났다.

다른 팀원들의 생각은 다를 수도 있겠지만, 개인적으로는 걱정보다 훨씬 큰 효과를 얻은 과정이었다고 느낀다. 모두가 같은 방향을 바라보게 되면서 이후 설계와 디자인 단계에서도 고민이 줄고, 한층 수월하게 진행할 수 있었다.

기획을 바탕으로 한 설계

어떤 과정으로 설계가 진행되었는가?

월요일에 문득 팀원들에게 내일 뭐하세요? 라고 물었다. 설계 과정을 진행할 때에는 짧은 시간 안에 늘어지지 않으면서도 높은 집중력과 원활한 의사소통이 필요하다고 생각했기 때문이다. 그렇게 갑작스럽게 다음날 대면으로 모여 설계 과정을 진행하게 되었다.

하나의 설계 문서를 완성하기까지 짧은 시간 안에 여러 과정이 빠르게 이루어졌다. 우선 화상 강의 라는 낯선 기술을 어떻게 접근하고 적용할지 논의했고, 각자 설계 시간을 가지며 우선적으로 고려해야 할 부분을 정리했다. 이후 각자의 내용을 공유하며 설명하는 시간을 가진 뒤, 기획서와 개별 설계 내용을 AI 에 전달해 하나의 통합 설계 문서를 작성하도록 했다.

이때 기획서를 미리 잘 정리해 두었기에 AI 가 서비스의 흐름을 잘 파악했다고 생각한다. 종합된 문서를 바탕으로 단계별로 함께 검토하며, 흐름을 다듬고 전체 구조를 이해하려 노력했다.

설계 중 논의했던 문제점이 있었는가?

주어진 시간 안에서 메인 기능에 집중하다 보니 로그인 기능을 제외하기로 결정했다. 그러나 이로 인해 강의자를 인증할 수 있는 방법이 사라지는 문제가 발생했다. 강의자와 청중을 구분 해야 하는데, 이를 어떻게 판별할지에 대한 고민이 많았다.

강의실에 입장할 때 강의자임을 어떻게 인증할 것인가? 단순한 장치를 도입하자니 청중이 손쉽게 우회할 수 있을 것 같았고, UX 측면에서도 좋은 흐름이라 보기 어려웠다. 비밀번호를 설정하는 방법도 고려했지만, 과연 이것이 최선인지 의문이 들었다.

팀의 최종 결론은, 강의자가 강의를 생성하면 곧바로 입장하도록 하고, 이를 통해 자동으로 강의자를 판별하는 방식이었다. UX 를 저해하지 않으면서도 추가적인 검증 절차 없이 자연스럽게 구분할 수 있는 최선의 방법이라 판단했다.

설계 과정에서의 아쉬운 점이 있다면?

강의자 판별 방식에 대한 논의가 예상보다 길어졌다. 대면 회의에서 다른 플로우를 설계해야 했지만, 이 주제에 많은 시간이 소요되었다. 실제로 주간 팀 회고 시간에도 한 팀원이 이 점을 언급했다. 다른 기능이나 고려해야 할 사항들에 비해 우선순위가 낮았음에도 시간이 많이 투입된 것이 아쉬웠다.

새롭게 느낀 부분이 있다면?

하루 단위의 계획을 세우는 데에는 익숙해졌다. 팀 내에서는 매일 스크럼을 마치며 그날의 목표와 할 일을 계획하고 있다. 그러나 전체적인 흐름을 구분 짓는 부분에서는 아직 부족함이 있었다. 회의가 진행되는 중간에도 남은 시간 안에 반드시 결정해야 할 일과 이후로 미뤄도 되는 작업을 구분하는 과정이 필요하다고 느꼈다.

프로토타입 검증 과정

프로토타입을 어떻게 이해하고 접근했는가?

프로토타입은 최소한의 기능을 구현해 우리가 구상한 아이디어가 실제로 작동하는지를 검증하는 과정이라고 생각했다. 따라서 명확한 가설 설정이 필요했다. 우리 팀이 진행한 프로토타입 과정은 다음과 같다.

1. 프로젝트 내부 메인 기능의 요구사항 분석
2. 가설 설정
3. 프로토타입 설계 및 구축
4. 가설 검증
5. 결과를 통한 피드백

팀에서 설정한 가설은?

지난주 계획에서는 제스처 인식이 정확히 작동하는가 와 다수의 사용자가 참여할 때 화상 강의가 원활히 진행될 수 있는가 를 주요 목표로 설정했다. 이번 주에는 이 두 기능뿐만 아니라, 두 기능이 동시에 원활하게 작동하는가 를 추가로 검증하기로 결정했다.

1. 제스처 인식이 실시간으로 작동할 것이다.
2. 여러 사용자가 동시에 영상과 음성을 안정적으로 공유할 수 있을 것이다.
3. 영상·음성 공유와 동시에 실시간 제스처 인식이 원할히 수행될 것이다.

어떤 과정으로 프로토타입을 검증하였는가?

기획과 핵심 기능, 그리고 가설이 명확했기 때문에 검증해야 할 대상도 분명했다. 우리의 목표는 어떻게 최적화할 것인가 가 아니라, 실제 화상 강의 상황에서 제스처 인식이 원활하게 작동하는지 를 확인하는 것이었다. 따라서 기술적인 가능성만 판별하면 된다고 판단했고, 이를 AI 를 활용해 검증하기로 했다.

우리가 선정한 기술 스택과 라이브러리를 기반으로 원하는 동작이 구현되도록 프롬프트를 작성했다. 비교적 짧은 시간 안에 코드를 완성할 수 있었고, 일부 수정만으로도 원하는 결과를 얻을 수 있었다. 이전에 팀 내에서 라이브러리 학습과 공유를 진행한 덕분에 코드 이해와 수정도 수월했다.

어떤 결과가 도출되었는가?

검증은 두 단계로 나누어 진행했다. 먼저 첫 번째 가설을 검증하기 위해 제스처 인식이 제대로 작동하는지를 시험했으며, 높은 인식률로 무사히 검증을 마쳤다. 구글에서 이미 인체 인식을 지원하는 모델을 제공하고 있었기에 높은 정확도를 보일 수 있었다고 판단했다.

이후 여러 사용자가 동시에 영상과 음성을 공유할 수 있는지를 검증한 결과, 이 또한 안정적으로 수행됨을 확인했다. 실제로 AI 가 작성한 코드를 통해 모든 가설을 검증할 수 있었으며, 그 결과 웹 환경에서 실시간 영상 / 음성 공유와 제스처 인식이 충돌 없이 안정적으로 병행될 수 있다 는 결론을 도출했다.

추가적으로 검증이 필요한 부분이 있다면?

우선 메인 기능에 대한 검증이 이루어졌고, 그 결과 성공적으로 결론을 내릴 수 있었다. 이후 팀 내 피드백 과정을 통해 추가적으로 고려해야 할 사항들을 정리했다.

주요 논의 내용은 주어진 환경이 달라질 때도 동일하게 작동할 수 있는가 였다. 예를 들어 조명이 어둡거나 네트워크 품질이 낮은 환경에서도 제스처 인식이 원활히 작동하는지를 확인할 필요가 있었다. 또한 사용자마다 피부색이나 옷의 색상이 다르기 때문에, 이러한 요인에 의해 인식률이 달라질 가능성도 검증해야 한다고 판단했다.

아울러 동시 접속자가 소수 수준을 넘어 50 명, 100 명 단위로 늘어났을 때 발생할 수 있는 문제에 대한 점검도 필요하다고 보았다.

프로토타입을 진행해보며

사실 이번 프로토타입은 매우 간단한 내용만 다뤘던 것 같다. 핵심 기능들만 검증했기에 다소 아쉬움이 남는다. 만약 시간적 여유가 있었다면, 한 번의 검증으로 끝내는 것이 아니라 반복적인 프로토타입 과정을 거쳤을 것 같다. 검증 단계를 한 번 수행한 뒤, 그 결과를 바탕으로 새로운 가설을 세우고 다시 검증하는 절차가 이어졌다면 더 체계적으로 진행할 수 있지 않았을까 하는 생각이 든다.

회고를 마무리하며

다양한 의견 공유의 중요성

캠퍼분들과 다양한 의견과 생각을 나누다 보면, 미처 생각하지 못했던 시각을 발견하곤 한다. 데모 시간에 프로젝트에 대해 이야기를 나눌 때뿐만 아니라, 개인적으로 의견을 주고받을 때에도 그런 점을 자주 느낀다.

하나의 프로젝트 안에는 기획, 설계, 디자인, 구현 등 여러 세부 주제가 있다. 그리고 각 영역마다 다양한 접근 방식이 존재한다. 부스트캠프 이전까지만 해도 늘 익숙한 방식대로만 진행했기 때문에, 내 방법과 다른 방식들을 접하면 과연 그 방법이 잘 작동할까? 하는 의문이 생기곤 했다.

하지만 부스트캠프를 진행하면서 여러 가지 접근법을 직접 보고 들어보며, 그 안에 몰랐던 장점이 많다는 것을 깨달았다. 그래서 새로운 방식들을 접할 때마다 궁금해지고, 그 과정을 통해 꾸준히 배우고 있다. 여러 캠퍼들과의 대화를 통해 정말 많은 것을 배우고 있음을 느낀다.

더 나아가서

데모 발표를 돌이켜보며 과연 충분히 잘 설명했을까? 하는 생각이 들었다. 전달하고 싶은 내용은 많았지만, 제한된 시간 안에서 집중도를 유지하며 핵심을 전하는 것이 쉽지 않았다. 그래서 내용을 간소화하는 과정에서 꼭 전달해야 할 부분을 정리하는 일이 중요하다고 느꼈다.

특히 이번 주 진행 내용 과 다소 생소할 수 있는 프로젝트에 적용된 개념들 을 어떻게 균형 있게 설명할지가 고민이었다. 기술 설명에 집중하다 보면 서비스의 전체 흐름이 희미해질 것 같았고, 반대로 기획 과정을 중심으로 이야기하자니 기술적 깊이가 부족할 수 있었다.

15 분이라는 짧은 시간 안에 기술을 소개하고 녹여낸 과정을 설명하다 보면, 시간이 모두 지날지도 모른다는 걱정이 들었다. 또한, 우리 팀은 이번 주를 기획을 다지는 주로 삼았기에, 그 과정을 설명한다면 왜 기획을 다시 하게 되었는가 라는 주제로 새롭고 의미 있는 이야기를 나눌 수 있을 것이라 생각했다.

하지만 돌아보면 그런 접근이 과연 적절했을까? 하는 생각도 든다. 프로토타입 주간답게 사용된 기술과 과정을 조금 더 구체적으로 발표했어야 하지 않았을까 싶다. 다시 생각해보니, 데모 시간은 각 팀이 같은 주제를 어떻게 접근했고, 이를 각자의 서비스에 어떻게 녹여냈는지를 공유하는 자리라고 느껴졌다. 다음 데모에서는 어떤 부분에서 논의가 이루어질지 미리 고민하고, 그에 맞춰 준비해보고자 한다.